2026/9/1 1:35:44
FEATURED · 精选文章 
1. 为什么选择 DeepSeek Harness 做 LLM 项目1.1 LLM 项目开发的真正痛点现在做 LLM 应用很多开发者会遇到一个共同的问题单次对话很聪明但多轮下来就开始“失忆”。今天让模型写好了用户模块过三小时后追加一个需求它可能把之前的接口规范全部推翻今天调好的系统提示词换了一个新任务后又要重新整理项目里的工具调用、搜索逻辑、文档解析规则全都散落在几十段对话里无法统一沉淀。传统开发里面有 Git、有模块化、有设计模式但在“用自然语言驱动开发”这件事上很多人的流程还停留在“打开对话窗口想到什么问什么”。这不是模型能力的问题而是缺少一个把提示词、工具、配置、上下文“工程化”的框架。DeepSeek Harness 之所以能在最近被高频讨论就是因为它把“AI 辅助开发”从聊天式协作往前推进到了“可配置、可复用、可插拔”的工程模式。1.2 Preset Skills 插件三件套解决什么DeepSeek Harness 的核心设计可以拆成三个关键词Preset一套可复用的预设配置把模型参数、系统提示词、任务目标、工具开关统一放进配置文件。不同项目使用不同 Preset避免每次对话前都要把背景信息重复贴一遍。Skills可注入给 LLM 的能力包。你可以把文档解析、代码评审、数据库 Schema 生成、前端组件规范等能力封装成一个个 Skill。模型在需要时会自动加载对应技能而不是全靠对话里的零散描述。插件在 Harness 外层扩展能力边界比如接入本地文件系统、调用外部 API、挂载知识库、对接 CI/CD 流程。插件让 Harness 不只是“对话工具”而更像是一个可编程的开发底座。这三个词组合起来解决的是同一个问题让 LLM 的智力能够稳定、持续、可控地作用于一个完整项目而不是只作用于某一次对话。在实测中这套组合比“把需求写进聊天框然后等结果”靠谱得多。1.3 什么是 LLM WikiLLM Wiki 是 Andrej Karpathy 提出的一种知识库组织范式。传统的 Wiki 是人工维护的网页集合而 LLM Wiki 是由 LLM 辅助生成、整理、检索和动态更新的知识库。它的核心特征有三个知识条目以 Markdown 等纯文本形式存在方便 LLM 读取和生成。检索不依赖固定的目录结构而是通过语义检索把最相关的内容找出来。内容的增删改可以由自然语言驱动普通用户可以用对话的方式维护 Wiki。这篇文章里要实战开发的正是这样一个项目一个带语义检索、支持自然语言问答、可自动生成摘要的 LLM Wiki 系统。接下来我会拆解用 DeepSeek Harness 在 10 轮左右提示下、分 11 个阶段完成这个项目的完整路径。2. 环境准备与前置知识2.1 本地环境要求在开始之前先把环境梳理清楚。DeepSeek Harness 本身是一个跨平台的开发工具界面侧是 Web 形态命令侧通过 npm/pnpm 工具链安装。下面是实测环境的基本要求操作系统Windows 10/11、macOS、主流 Linux 发行版均可。Node.js建议使用 18 LTS 或更高版本这是运行 Harness 管理端和插件系统的基础。包管理器建议安装 pnpm理由稍后说明。大模型 API Key准备好可用的 DeepSeek API 或其他兼容 OpenAI 协议的 Key用于运行 LLM 任务。Git用于项目初始化和版本管理。版本说明由于 Harness 迭代速度较快不同版本的命令和配置字段可能有差异。下面的示例以常见环境为背景重点演示配置思路和操作路径。安装时请以你的实际版本为准遇到报错优先查看官方文档的更新日志。2.2 安装 DeepSeek Harness安装步骤并不复杂整体流程是先安装依赖和 CLI再启动管理端界面。# 使用 pnpm 全局安装 dsh 命令行工具包名以官方为准 pnpm add -g dsh # 检查安装结果 dsh --version # 启动 Web 管理界面 dsh web如果安装过程中卡在pnpm dsh web这一步多半是网络源或依赖锁版本问题可以尝试切换到国内镜像源pnpm config set registry https://registry.npmmirror.com再重新执行启动命令。启动成功后浏览器访问http://localhost:3000端口以实际提示为准即可打开 Harness 控制台。2.3 项目目录结构为了能让 LLM 在多次对话中稳定理解项目状态推荐在项目根目录维护一个清晰的工程结构。LLM Wiki 项目的目录规划如下llm-wiki/ ├─ .dsh/ │ ├─ presets/ │ │ └─ default.yaml │ ├─ skills/ │ │ ├─ code-review/ │ │ └─ wiki-summary/ │ └─ plugins/ │ └─ file-search/ ├─ docs/ │ └─ specs/ │ ├─ 01-requirements.md │ └─ 02-architecture.md ├─ server/ │ ├─ src/ │ └─ package.json ├─ web/ │ ├─ src/ │ └─ package.json └─ README.md.dsh目录专门存放 Harness 相关的 Preset、Skills 和插件配置。docs/specs目录保存阶段性设计文档这是让 LLM 在后续轮次中“快速恢复上下文”的关键手段。3. Preset用配置预设统一项目行为3.1 Preset 的核心概念Preset 翻译成“预设”本质是一份声明式配置文件。它把以下内容固化下来当前项目的技术栈说明。LLM 的角色设定和系统提示词。模型名称、温度、最大 Token 等参数。默认启用的 Skills 和插件。输出格式要求比如代码风格、文件命名规范。有了 Preset 之后每一轮新对话都不需要重新解释“这是 Vue3 FastAPI 项目”“代码评审要注意安全边界”这些背景信息。模型启动时会自动读取对应的 Preset从第一句对话开始就处于“懂项目”的状态。这也是“10 轮提示完成一个完整项目”能成立的重要原因之一——大量上下文被固化到了配置里而不是占用了每轮提示的额度。3.2 一个最小 Preset 配置示例下面是一份示意配置字段名可能因版本不同而调整但结构思路是通用的# 文件路径.dsh/presets/default.yaml name: llm-wiki-default description: LLM Wiki 项目开发预设 model: provider: deepseek name: deepseek-chat temperature: 0.3 max_tokens: 4096 system_prompt: | 你是一个资深的全栈工程师负责开发 LLM Wiki 项目。 技术栈为 FastAPI Vue 3 SQLite。 所有代码必须遵循项目规范 1. Python 代码使用类型注解核心函数必须有 docstring。 2. 前端组件使用 Composition API样式使用 Tailwind CSS。 3. 数据库操作必须通过 Repository 层禁止在路由中直接写 SQL。 4. 涉及删除操作时必须提示风险并建议软删除。 skills: - code-review - wiki-summary plugins: - file-search output: code_style: pep8 commit_message_convention: conventional这份配置的价值在于把“优秀工程师的默认约束”写进了模型的上文里。温度设为 0.3 是为了让开发任务输出更稳定不要过于发散system_prompt 中明确了技术栈和规范skills 和 plugins 则直接挂载了后续要讲解的两类扩展能力。3.3 Preset 与直接写提示词的区别有人会觉得Preset 不就是把提示词放到文件里吗不同点在于两点。第一Preset 是分项目隔离的。你可以在.dsh/presets下同时存放default.yaml、api-dev.yaml、frontend-dev.yaml在开始不同任务时切换侧重点而不是在一个超长提示词里把规则全部堆进去。第二Preset 是结构化的可以被 Harness 当作配置解析也能被插件读取。比如插件可以根据system_prompt中的规则自动检查生成代码的命名是否符合规范。这类能力是纯文本提示词无法做到的。4. Skills让 LLM 拥有领域技能4.1 什么是 AI SkillsSkills 可以理解为一组“可复用的专业能力包”。一个 Skill 通常由一个包含详细指令的 Markdown 文件和若干辅助资源组成。当模型遇到的任务与某个 Skill 匹配时Harness 会把 Skill 中的指令注入上下文模型就“学会”了这项能力。以开发 LLM Wiki 项目为例我们用到的 Skills 包括code-review生成代码时自动附带评审意见和潜在风险。wiki-summary根据知识库内容自动生成摘要和标签。schema-designer根据需求生成数据表结构同时生成迁移脚本。这些 Skill 不是模型本身就有的而是你为了让项目质量更高而“外挂”上去的。这解决了 LLM 开发的另一个痛点模型知道代码怎么写但不知道你团队里的代码规范、目录约定和验收标准。4.2 如何编写一个 Skill一个 Skill 通常以一个目录为单位存在核心文件是SKILL.md。下面给出一个用于自动生成数据库 Schema 的 Skill 示例--- name: schema-designer description: 根据需求文档生成 SQLite 数据表结构和迁移 SQL when_to_use: 当需要设计数据库表结构或修改实体模型时 version: 1.0.0 --- # Schema Designer Skill ## 职责 根据需求描述生成以下内容 1. SQLite 的 CREATE TABLE 语句。 2. 表之间的外键关系说明。 3. 必要的索引建议。 4. 通用字段id、created_at、updated_at统一使用 snake_case 命名。 ## 约束 - 所有表必须包含主键 id INTEGER PRIMARY KEY AUTOINCREMENT。 - 时间字段统一使用 DATETIME DEFAULT CURRENT_TIMESTAMP。 - 涉及用户内容时必须有 is_deleted INTEGER DEFAULT 0 软删除标记。 - 输出 SQL 之前必须用一段话说明设计思路不得直接给出代码。 ## 示例输出模板 ### 表wiki_pages | 字段 | 类型 | 说明 | | --- | --- | --- | | id | INTEGER | 主键 | | title | TEXT | 页面标题 | | content | TEXT | Markdown 内容 | | tags | TEXT | 逗号分隔的标签 | | created_at | DATETIME | 创建时间 | | updated_at | DATETIME | 更新时间 |要注意的是SKILL.md 里面的“约束”和“示例输出模板”会直接影响模型的行为。写得越具体模型越稳定。比如上面明确要求“输出 SQL 之前必须说明设计思路”这能防止模型直接甩出一大段代码而不解释原因。4.3 Skills 的命名与组织在.dsh/skills目录下每个 Skill 独占一个子目录。推荐的组织方式.dsh/skills/ ├─ code-review/ │ ├─ SKILL.md │ └─ rules/ │ └─ python-security.md ├─ schema-designer/ │ ├─ SKILL.md │ └─ templates/ │ └─ table-template.sql └─ wiki-summary/ ├─ SKILL.md └─ examples/ └─ summary-sample.mdSkill 目录里还可以放辅助文件比如规则清单、SQL 模板、示例文档LLM 在需要时会读取这些文件来补充细节。这些辅助资源不参与对话只在对应场景被加载既节省 Token又让指令更聚焦。实际开发时建议每写完一个 Skill就用几个典型场景测试一下输出质量并根据结果迭代 SKILL.md 的描述。5. 插件系统扩展 Harness 的能力边界5.1 插件解决什么问题Preset 和 Skills 解决了“模型怎么想”的问题插件解决的是“模型能做什么”。默认情况下LLM 只能生成文本不能直接读取你电脑上的文件、不能调用数据库、不能发送 HTTP 请求。插件体系就是把这些能力桥接进来。在 LLM Wiki 开发过程中有几个场景必须依赖插件让模型读取已有的项目文件理解当前代码状态。让模型执行测试命令并读取输出结果。让模型把生成的 Markdown 文档自动写入到docs/specs目录。这些能力如果都靠人工复制粘贴会严重打断开发节奏11 个阶段不可能在 10 轮提示内完成。插件让模型具备了“操作环境”的权限这也是 Harness 被称为“开发工具”而不是“聊天工具”的关键原因。5.2 插件的基本结构插件常见的结构是一个目录加一个清单文件。下面是一个简化示例用于读取项目中指定文件的内容// 文件路径.dsh/plugins/file-search/manifest.json { name: file-search, version: 1.0.0, description: 读取项目目录中的文件内容, permissions: [fs:read], entry: index.js }对应的入口代码逻辑可以很简单// 文件路径.dsh/plugins/file-search/index.js export async function readProjectFile(filePath, context) { const fs await import(node:fs/promises); const root context.projectRoot; const resolvedPath ${root}/${filePath}; try { const content await fs.readFile(resolvedPath, utf-8); return content; } catch (error) { return 读取失败${error.message}; } }需要注意这里给出的是插件机制的示例思路不同版本的 Harness 对插件 API 的定义方式不同。实际开发时以官方文档的插件开发指南为准重点理解“manifest 声明能力、入口函数执行逻辑”这个模式。5.3 常用插件方向从实践来看以下几类插件对项目开发最有帮助文件读写插件让模型可以查看和修改项目文件。终端命令插件让模型可以运行测试、构建和代码检查。检索插件让模型可以从项目文档或知识库中检索相关内容。HTTP 客户端插件让模型可以调用外部 API比如联调接口或访问模型服务。这些插件组合使用相当于给 LLM 装上了“手”和“眼睛”。它可以在项目里做端到端的操作这也是“工业级”流程得以压缩到 10 轮提示的另一个重要原因。6. 11 阶段实战从零开发 LLM Wiki6.1 阶段一需求澄清与项目范围这个阶段只做一件事把需求边界说清楚。用一次提示完成项目的高层定义。提示词示例请根据 LLM Wiki 这个项目帮我完成需求澄清 1. 核心用户是谁 2. 核心功能有哪些 3. 第一版需要完成哪些功能哪些功能可以放到 v2 4. 非功能性需求有哪些性能、安全、可维护性 输出为 docs/specs/01-requirements.md格式包含背景、用户画像、功能列表、优先级、验收标准。这个阶段的重点是让 LLM 输出一份结构化的需求文档并存放到docs/specs目录。因为 Preset 中已经注入了技术栈信息LLM 会自然地考虑 FastAPI Vue3 SQLite 的合理边界不会提出明显离谱的功能范围。6.2 阶段二架构设计需求确定后第二轮到架构设计。架构文档建议包含系统模块划分、前后端交互协议、数据流向、关键目录结构、部署方式。基于 01-requirements.md完成 LLM Wiki 的架构设计 - 模块划分后端 API、向量检索服务、前端管理界面、知识库解析任务。 - 前后端交互RESTful API认证使用 JWT。 - 数据流Markdown 文件录入 - 解析为正文和元数据 - 存入 SQLite - 生成向量索引 - 查询时召回 - LLM 生成摘要。 - 输出到 docs/specs/02-architecture.md。这一轮输出的架构文档是后面所有代码生成的“总依据”。后续每一轮如果模型出现偏离我只需要让它重新参考 02-architecture.md 里的约束即可。这也是多轮开发中防止“跑偏”的关键手段。6.3 阶段三数据模型设计数据模型阶段调用schema-designerSkill 生成 SQLite 表结构。此时 Skill 会自动约束字段命名、软删除、索引规范。提示词示例根据 02-architecture.md 中定义的数据流设计 SQLite 数据表。 需要覆盖用户表、Wiki 页面表、页面版本表、标签表、检索记录表。 调用 schema-designer 技能输出 SQL 和设计说明。这里模型会依据 SKILL.md 中的规则生成完整的建表 SQL同时附带设计思路说明。我们把这轮输出的 SQL 保存到server/schema.sql后续建表和初始化都基于这个文件。6.4 阶段四后端工程骨架与核心 API进入实际编码阶段。这一轮提示主要集中在三个任务初始化 FastAPI 项目、配置数据库连接、实现页面 CRUD API。按照 02-architecture.md初始化 FastAPI 项目 - 目录结构api/、models/、repositories/、services/。 - 使用 SQLAlchemy 连接 SQLite读取 schema.sql 完成建表。 - 实现 Wiki 页面的列表、详情、创建、编辑、软删除 API。 - 遵循 Preset 中的代码规范。 完成后检查 server/ 是否可运行。借助文件读写插件和终端插件模型可以直接创建目录、写文件、运行测试命令。这个阶段会生成大量代码文件但不需要每段代码都靠对话逐行生成插件已经把“生成代码 - 写入文件 - 检查语法”的闭环自动化了。6.5 阶段五知识库解析与索引模块LLM Wiki 的核心能力之一是从 Markdown 文件中解析知识内容并建立索引。新增知识库解析模块 - 支持读取 docs/ 目录下的 Markdown 文件。 - 解析 frontmatter 中的 title、tags、summary 字段。 - 将正文按标题拆分为 chunks。 - 为每个 chunk 生成向量并存入本地索引表中。 - 提供重解析命令python -m server.ingest --docs-dir ./docs。这一轮的关键是让模型实现一个独立的可执行脚本而不是把解析逻辑藏在 API 路由中。这样一来用户可以随时手动触发知识库更新。6.6 阶段六语义检索接口有了索引接下来需要把“搜得到”做成 API。实现语义检索接口 /api/search - 输入查询文本。 - 处理把查询文本向量化与知识库 chunk 向量做余弦相似度排序。 - 输出Top 5 结果包含标题、片段、相似度、来源文件。 - 同时提供 /api/search?typekeyword 关键词检索模式作为兜底。这个阶段需要插件有访问模型 Embedding 接口的能力。向量维度、相似度阈值都可以在前序 Preset 或配置文件中定义避免在每轮对话中重复说明。6.7 阶段七LLM 摘要与问答生成LLM Wiki 的“智能”体现在能基于检索结果生成答案和摘要。这一阶段给模型增加一个调用链用户提问 - 召回相关 chunks - 组装上下文 - 调用 LLM 生成回答。新增 LLM 问答服务 - 服务名server/services/llm_service.py。 - 输入用户问题。 - 流程调用语义检索接口拿到 Top 3 片段拼接到 Prompt 中要求模型基于片段回答禁止编造。 - 输出回答文本 引用片段来源。 - 新增 POST /api/ask 接口。这里要特别强调 Prompt 中“禁止编造、基于片段回答、注明引用来源”的约束。这部分约束也可以沉淀到wiki-summarySkill 里避免每次都要临时写。6.8 阶段八前端基础框架与页面后端能力成型后进入前端开发。前端采用 Vue 3 Tailwind CSS页面包括 Wiki 列表、详情页、问答页、编辑页。初始化 Vue 3 Vite 前端项目 - 页面列表页 /、详情页 /page/:id、问答页 /ask、编辑页 /edit/:id。 - 路由使用 vue-router状态管理使用 Pinia。 - 调用后端 API 的封装放在 src/api/index.js。 - 列表页展示 Wiki 页面卡片包含标题、标签、更新时间。由于前一轮已经把 API 接口定义清楚前端页面可以基于接口文档直接生成不需要再额外设计数据结构。6.9 阶段九Preset 与 Skills 的迭代优化到此为止系统已经具备基本功能。这一轮做一次“元层面的复盘”检查开发过程中模型表现不稳定的环节把这些经验回写到 Preset 和 Skill 中。比如如果发现 LLM 生成的 SQL 经常缺少索引可以在schema-designerSkill 的约束里补一句“所有查询频繁的字段必须设计索引”如果发现模型回答问题时偶尔引用不存在的来源可以在llm_service的 Prompt 中增加“如果返回的片段与问题无关请直接说明无法回答”。这个过程是整个方法论的精华每一轮项目开发都在沉淀下一次开发的资产。Preset 和 Skills 不是写一次就固定不变的它们应该随项目推进持续迭代。6.10 阶段十插件扩展与联调功能完整后的集成测试阶段。检查插件是否能正常完成文件读取、命令执行等任务并把联调过程中发现的问题统一修复。现在进入集成自测阶段 1. 启动后端服务验证五个核心 API 均返回 200。 2. 启动前端开发服务器确认三个页面可正常访问。 3. 运行知识库解析脚本确认 docs/ 下测试文档可被正确索引。 4. 用 curl 调用 /api/ask验证问答链路。 将发现的问题列表输出为 docs/specs/03-issues.md。如果因为插件权限配置导致模型无法读取某些文件需要检查插件的permissions配置确保包含了fs:read、fs:write、terminal:run等必要权限。6.11 阶段十一README、配置打包与项目交付最后一个阶段做项目收尾。让模型生成 README整理配置模板把.dsh目录的配置固化到模板库中。完成项目交付准备工作 1. 编写 README.md项目简介、安装步骤、启动命令、API 文档入口。 2. 检查 .dsh/presets 和 .dsh/skills 是否包含任何敏感信息。 3. 输出一份 .env.example 文件列出所有需要配置的环境变量。 4. 整理项目交付清单 docs/specs/04-final-checklist.md。到这里一个 LLM Wiki 项目从需求到交付的 11 个阶段全部完成。整个过程约 10 轮提示每一轮都有明确的产出物核心代码由模型生成但架构决策、规范约束和验收检查由 Preset、Skills 和插件体系共同保证。这种开发方式不再是“让 AI 写代码”而是“按工程方法使用 AI 写代码”。7. 常见问题与排查思路7.1 安装与启动类问题问题现象常见原因解决思路安装卡在 pnpm 阶段网络源不稳定或依赖锁版本冲突切换 npmmirror 镜像源删除 node_modules 后重装dsh web启动后页面空白管理端依赖未正确构建检查 Node 版本是否满足要求执行依赖重建命令浏览器无法访问管理界面端口被占用或防火墙拦截检查终端输出中的实际端口更换端口后重试安装类问题的排查顺序建议是先看 Node 版本再查镜像源最后看端口占用。不要一上来就重装系统大部分问题集中在依赖安装环节。7.2 Preset 与 Skill 加载异常如果发现模型的行为完全无视你写的 system_prompt优先检查Preset 文件是否被正确命名为.yaml格式Harness 是否读取了当前项目的.dsh目录。Skill 的when_to_use条件是否覆盖了当前场景。如果描述的是“当需要设计数据库时”那么在问答生成阶段它不会被加载。多个 Skill 之间是否存在指令冲突。比如code-review要求所有代码必须附带评审意见而另一个 Skill 要求输出精简代码两者可能同时生效导致模型行为混乱。7.3 多轮开发中模型偏离设计多轮对话最容易出现的问题是第 5 轮生成的代码与第 2 轮的架构设计不一致。解决办法是“用文档锚定上下文”。实践中推荐在每一轮提示的开头加上一句话请先阅读 docs/specs/02-architecture.md 中的约束再开始本次开发任务。这句话虽然简单但能显著降低模型偏离设计文档的概率。根本原因在于架构文档是静态的、完整的而对话历史是动态的、会被截断的。把核心约束资源化到文件里比反复在对话中强调更可靠。8. 最佳实践与工程建议在几个完整项目的开发中我沉淀了下面这些值得长期使用的经验。8.1 把约束写进配置而不是写进对话每一个你反复对 LLM 强调的规则都值得固化到 Preset、Skill 或规格文档中。如果同样的话在对话里说了三次以上说明它应该被结构化。比如“所有时间字段用 created_at 和 updated_at”这种规则只需要写进 schema-designer 的 SKILL.md后面所有表设计都会自动遵守不用每次重新说。8.2 用规格文档管理长项目上下文对话历史一长模型的注意力就会分散。最有效的缓解方式是为项目建立docs/specs目录每个阶段生成一份规格文档。下一阶段开始时让模型先读取对应文档再开始编码。规格文档回答了三类问题项目要做什么、当前做到哪一步、有哪些硬性约束。这三类信息恰恰是对话历史中最容易丢失的。8.3 插件权限遵循最小授权原则插件的权限越大模型能做的事越多但风险也越高。在配置permissions时只开放当前任务必需的权限。比如知识库解析阶段只需要fs:read就不要同时给fs:write和terminal:run。特别是涉及生产环境或敏感文件时要保证所有操作都在项目目录内完成并且执行破坏性命令之前在对话中向用户确认。8.4 定期刷新模型的状态认知即使有文档锚定模型在连续多轮后也可能对当前文件状态产生错误判断。建议每个阶段开始时用一条消息让模型“列出项目当前的文件结构并说明自上次文档以来是否有新增文件”确认状态后再继续。这一步能避免大量重复生成或覆盖已有代码的问题。8.5 把 Skill 当作团队知识沉淀的载体当团队里沉淀了一套代码规范、评审清单、数据库设计约定后把这些内容做成一个 Skill整个团队的 AI 辅助开发就会站在同一个基准线上。新成员加入时不需要背诵规范文档只要配置好 Harness 环境模型就会在编码过程中自动遵守。Skill 的维护频率可以是一周一次在团队复盘后更新。8.6 版本管理不要放松AI 生成的代码同样需要 Git 管理。11 个开发阶段中每个阶段完成时都建议做一次提交提交信息遵循 Angular 规范。这样即使某个阶段的生成结果不符合预期也可以用git revert干净地回退不需要靠对话把代码“改回去”。9. 总结与下一步方向这篇文章围绕 DeepSeek Harness把 Preset、Skills、插件三件套的机制拆开讲了一遍并用一个 LLM Wiki 项目的 11 个开发阶段串起了完整流程。你可能已经注意到这套实践的核心并不复杂把项目背景放入 Preset把专业能力放入 Skills把操作权限交给插件再用规格文档锚定每一轮开发的上文。下一步你可以从三个方向继续深入一是把自己常用的开发规范整理成 Personal Skills 集合二是给现有项目写一套可复用的 Preset观察迭代速度是否明显提升三是尝试用同样的方法做一个不同类型的项目比如 API 服务或数据分析工具检验这套工作流的通用性。AI 开发工具还在快速演进Preset、Skills、插件这些概念的具体实现可能会变但“把上下文结构化、把能力模块化、把流程工程化”的思路不会过时。如果你正在尝试用 LLM 驱动完整项目建议从这篇文章里的最小结构开始先搭建一份自己的 Preset再慢慢积累 Skill 和插件几轮迭代后会发现项目开发方式已经发生了明显变化。
DeepSeek Harness实战：用Preset、Skills与插件工程化开发LLM项目
1. 为什么选择 DeepSeek Harness 做 LLM 项目1.1 LLM 项目开发的真正痛点现在做 LLM 应用很多开发者会遇到一个共同的问题单次对话很聪明但多轮下来就开始“失忆”。今天让模型写好了用户模块过三小时后追加一个需求它可能把之前的接口规范全部推翻今天调好的系统提示词换了一个新任务后又要重新整理项目里的工具调用、搜索逻辑、文档解析规则全都散落在几十段对话里无法统一沉淀。传统开发里面有 Git、有模块化、有设计模式但在“用自然语言驱动开发”这件事上很多人的流程还停留在“打开对话窗口想到什么问什么”。这不是模型能力的问题而是缺少一个把提示词、工具、配置、上下文“工程化”的框架。DeepSeek Harness 之所以能在最近被高频讨论就是因为它把“AI 辅助开发”从聊天式协作往前推进到了“可配置、可复用、可插拔”的工程模式。1.2 Preset Skills 插件三件套解决什么DeepSeek Harness 的核心设计可以拆成三个关键词Preset一套可复用的预设配置把模型参数、系统提示词、任务目标、工具开关统一放进配置文件。不同项目使用不同 Preset避免每次对话前都要把背景信息重复贴一遍。Skills可注入给 LLM 的能力包。你可以把文档解析、代码评审、数据库 Schema 生成、前端组件规范等能力封装成一个个 Skill。模型在需要时会自动加载对应技能而不是全靠对话里的零散描述。插件在 Harness 外层扩展能力边界比如接入本地文件系统、调用外部 API、挂载知识库、对接 CI/CD 流程。插件让 Harness 不只是“对话工具”而更像是一个可编程的开发底座。这三个词组合起来解决的是同一个问题让 LLM 的智力能够稳定、持续、可控地作用于一个完整项目而不是只作用于某一次对话。在实测中这套组合比“把需求写进聊天框然后等结果”靠谱得多。1.3 什么是 LLM WikiLLM Wiki 是 Andrej Karpathy 提出的一种知识库组织范式。传统的 Wiki 是人工维护的网页集合而 LLM Wiki 是由 LLM 辅助生成、整理、检索和动态更新的知识库。它的核心特征有三个知识条目以 Markdown 等纯文本形式存在方便 LLM 读取和生成。检索不依赖固定的目录结构而是通过语义检索把最相关的内容找出来。内容的增删改可以由自然语言驱动普通用户可以用对话的方式维护 Wiki。这篇文章里要实战开发的正是这样一个项目一个带语义检索、支持自然语言问答、可自动生成摘要的 LLM Wiki 系统。接下来我会拆解用 DeepSeek Harness 在 10 轮左右提示下、分 11 个阶段完成这个项目的完整路径。2. 环境准备与前置知识2.1 本地环境要求在开始之前先把环境梳理清楚。DeepSeek Harness 本身是一个跨平台的开发工具界面侧是 Web 形态命令侧通过 npm/pnpm 工具链安装。下面是实测环境的基本要求操作系统Windows 10/11、macOS、主流 Linux 发行版均可。Node.js建议使用 18 LTS 或更高版本这是运行 Harness 管理端和插件系统的基础。包管理器建议安装 pnpm理由稍后说明。大模型 API Key准备好可用的 DeepSeek API 或其他兼容 OpenAI 协议的 Key用于运行 LLM 任务。Git用于项目初始化和版本管理。版本说明由于 Harness 迭代速度较快不同版本的命令和配置字段可能有差异。下面的示例以常见环境为背景重点演示配置思路和操作路径。安装时请以你的实际版本为准遇到报错优先查看官方文档的更新日志。2.2 安装 DeepSeek Harness安装步骤并不复杂整体流程是先安装依赖和 CLI再启动管理端界面。# 使用 pnpm 全局安装 dsh 命令行工具包名以官方为准 pnpm add -g dsh # 检查安装结果 dsh --version # 启动 Web 管理界面 dsh web如果安装过程中卡在pnpm dsh web这一步多半是网络源或依赖锁版本问题可以尝试切换到国内镜像源pnpm config set registry https://registry.npmmirror.com再重新执行启动命令。启动成功后浏览器访问http://localhost:3000端口以实际提示为准即可打开 Harness 控制台。2.3 项目目录结构为了能让 LLM 在多次对话中稳定理解项目状态推荐在项目根目录维护一个清晰的工程结构。LLM Wiki 项目的目录规划如下llm-wiki/ ├─ .dsh/ │ ├─ presets/ │ │ └─ default.yaml │ ├─ skills/ │ │ ├─ code-review/ │ │ └─ wiki-summary/ │ └─ plugins/ │ └─ file-search/ ├─ docs/ │ └─ specs/ │ ├─ 01-requirements.md │ └─ 02-architecture.md ├─ server/ │ ├─ src/ │ └─ package.json ├─ web/ │ ├─ src/ │ └─ package.json └─ README.md.dsh目录专门存放 Harness 相关的 Preset、Skills 和插件配置。docs/specs目录保存阶段性设计文档这是让 LLM 在后续轮次中“快速恢复上下文”的关键手段。3. Preset用配置预设统一项目行为3.1 Preset 的核心概念Preset 翻译成“预设”本质是一份声明式配置文件。它把以下内容固化下来当前项目的技术栈说明。LLM 的角色设定和系统提示词。模型名称、温度、最大 Token 等参数。默认启用的 Skills 和插件。输出格式要求比如代码风格、文件命名规范。有了 Preset 之后每一轮新对话都不需要重新解释“这是 Vue3 FastAPI 项目”“代码评审要注意安全边界”这些背景信息。模型启动时会自动读取对应的 Preset从第一句对话开始就处于“懂项目”的状态。这也是“10 轮提示完成一个完整项目”能成立的重要原因之一——大量上下文被固化到了配置里而不是占用了每轮提示的额度。3.2 一个最小 Preset 配置示例下面是一份示意配置字段名可能因版本不同而调整但结构思路是通用的# 文件路径.dsh/presets/default.yaml name: llm-wiki-default description: LLM Wiki 项目开发预设 model: provider: deepseek name: deepseek-chat temperature: 0.3 max_tokens: 4096 system_prompt: | 你是一个资深的全栈工程师负责开发 LLM Wiki 项目。 技术栈为 FastAPI Vue 3 SQLite。 所有代码必须遵循项目规范 1. Python 代码使用类型注解核心函数必须有 docstring。 2. 前端组件使用 Composition API样式使用 Tailwind CSS。 3. 数据库操作必须通过 Repository 层禁止在路由中直接写 SQL。 4. 涉及删除操作时必须提示风险并建议软删除。 skills: - code-review - wiki-summary plugins: - file-search output: code_style: pep8 commit_message_convention: conventional这份配置的价值在于把“优秀工程师的默认约束”写进了模型的上文里。温度设为 0.3 是为了让开发任务输出更稳定不要过于发散system_prompt 中明确了技术栈和规范skills 和 plugins 则直接挂载了后续要讲解的两类扩展能力。3.3 Preset 与直接写提示词的区别有人会觉得Preset 不就是把提示词放到文件里吗不同点在于两点。第一Preset 是分项目隔离的。你可以在.dsh/presets下同时存放default.yaml、api-dev.yaml、frontend-dev.yaml在开始不同任务时切换侧重点而不是在一个超长提示词里把规则全部堆进去。第二Preset 是结构化的可以被 Harness 当作配置解析也能被插件读取。比如插件可以根据system_prompt中的规则自动检查生成代码的命名是否符合规范。这类能力是纯文本提示词无法做到的。4. Skills让 LLM 拥有领域技能4.1 什么是 AI SkillsSkills 可以理解为一组“可复用的专业能力包”。一个 Skill 通常由一个包含详细指令的 Markdown 文件和若干辅助资源组成。当模型遇到的任务与某个 Skill 匹配时Harness 会把 Skill 中的指令注入上下文模型就“学会”了这项能力。以开发 LLM Wiki 项目为例我们用到的 Skills 包括code-review生成代码时自动附带评审意见和潜在风险。wiki-summary根据知识库内容自动生成摘要和标签。schema-designer根据需求生成数据表结构同时生成迁移脚本。这些 Skill 不是模型本身就有的而是你为了让项目质量更高而“外挂”上去的。这解决了 LLM 开发的另一个痛点模型知道代码怎么写但不知道你团队里的代码规范、目录约定和验收标准。4.2 如何编写一个 Skill一个 Skill 通常以一个目录为单位存在核心文件是SKILL.md。下面给出一个用于自动生成数据库 Schema 的 Skill 示例--- name: schema-designer description: 根据需求文档生成 SQLite 数据表结构和迁移 SQL when_to_use: 当需要设计数据库表结构或修改实体模型时 version: 1.0.0 --- # Schema Designer Skill ## 职责 根据需求描述生成以下内容 1. SQLite 的 CREATE TABLE 语句。 2. 表之间的外键关系说明。 3. 必要的索引建议。 4. 通用字段id、created_at、updated_at统一使用 snake_case 命名。 ## 约束 - 所有表必须包含主键 id INTEGER PRIMARY KEY AUTOINCREMENT。 - 时间字段统一使用 DATETIME DEFAULT CURRENT_TIMESTAMP。 - 涉及用户内容时必须有 is_deleted INTEGER DEFAULT 0 软删除标记。 - 输出 SQL 之前必须用一段话说明设计思路不得直接给出代码。 ## 示例输出模板 ### 表wiki_pages | 字段 | 类型 | 说明 | | --- | --- | --- | | id | INTEGER | 主键 | | title | TEXT | 页面标题 | | content | TEXT | Markdown 内容 | | tags | TEXT | 逗号分隔的标签 | | created_at | DATETIME | 创建时间 | | updated_at | DATETIME | 更新时间 |要注意的是SKILL.md 里面的“约束”和“示例输出模板”会直接影响模型的行为。写得越具体模型越稳定。比如上面明确要求“输出 SQL 之前必须说明设计思路”这能防止模型直接甩出一大段代码而不解释原因。4.3 Skills 的命名与组织在.dsh/skills目录下每个 Skill 独占一个子目录。推荐的组织方式.dsh/skills/ ├─ code-review/ │ ├─ SKILL.md │ └─ rules/ │ └─ python-security.md ├─ schema-designer/ │ ├─ SKILL.md │ └─ templates/ │ └─ table-template.sql └─ wiki-summary/ ├─ SKILL.md └─ examples/ └─ summary-sample.mdSkill 目录里还可以放辅助文件比如规则清单、SQL 模板、示例文档LLM 在需要时会读取这些文件来补充细节。这些辅助资源不参与对话只在对应场景被加载既节省 Token又让指令更聚焦。实际开发时建议每写完一个 Skill就用几个典型场景测试一下输出质量并根据结果迭代 SKILL.md 的描述。5. 插件系统扩展 Harness 的能力边界5.1 插件解决什么问题Preset 和 Skills 解决了“模型怎么想”的问题插件解决的是“模型能做什么”。默认情况下LLM 只能生成文本不能直接读取你电脑上的文件、不能调用数据库、不能发送 HTTP 请求。插件体系就是把这些能力桥接进来。在 LLM Wiki 开发过程中有几个场景必须依赖插件让模型读取已有的项目文件理解当前代码状态。让模型执行测试命令并读取输出结果。让模型把生成的 Markdown 文档自动写入到docs/specs目录。这些能力如果都靠人工复制粘贴会严重打断开发节奏11 个阶段不可能在 10 轮提示内完成。插件让模型具备了“操作环境”的权限这也是 Harness 被称为“开发工具”而不是“聊天工具”的关键原因。5.2 插件的基本结构插件常见的结构是一个目录加一个清单文件。下面是一个简化示例用于读取项目中指定文件的内容// 文件路径.dsh/plugins/file-search/manifest.json { name: file-search, version: 1.0.0, description: 读取项目目录中的文件内容, permissions: [fs:read], entry: index.js }对应的入口代码逻辑可以很简单// 文件路径.dsh/plugins/file-search/index.js export async function readProjectFile(filePath, context) { const fs await import(node:fs/promises); const root context.projectRoot; const resolvedPath ${root}/${filePath}; try { const content await fs.readFile(resolvedPath, utf-8); return content; } catch (error) { return 读取失败${error.message}; } }需要注意这里给出的是插件机制的示例思路不同版本的 Harness 对插件 API 的定义方式不同。实际开发时以官方文档的插件开发指南为准重点理解“manifest 声明能力、入口函数执行逻辑”这个模式。5.3 常用插件方向从实践来看以下几类插件对项目开发最有帮助文件读写插件让模型可以查看和修改项目文件。终端命令插件让模型可以运行测试、构建和代码检查。检索插件让模型可以从项目文档或知识库中检索相关内容。HTTP 客户端插件让模型可以调用外部 API比如联调接口或访问模型服务。这些插件组合使用相当于给 LLM 装上了“手”和“眼睛”。它可以在项目里做端到端的操作这也是“工业级”流程得以压缩到 10 轮提示的另一个重要原因。6. 11 阶段实战从零开发 LLM Wiki6.1 阶段一需求澄清与项目范围这个阶段只做一件事把需求边界说清楚。用一次提示完成项目的高层定义。提示词示例请根据 LLM Wiki 这个项目帮我完成需求澄清 1. 核心用户是谁 2. 核心功能有哪些 3. 第一版需要完成哪些功能哪些功能可以放到 v2 4. 非功能性需求有哪些性能、安全、可维护性 输出为 docs/specs/01-requirements.md格式包含背景、用户画像、功能列表、优先级、验收标准。这个阶段的重点是让 LLM 输出一份结构化的需求文档并存放到docs/specs目录。因为 Preset 中已经注入了技术栈信息LLM 会自然地考虑 FastAPI Vue3 SQLite 的合理边界不会提出明显离谱的功能范围。6.2 阶段二架构设计需求确定后第二轮到架构设计。架构文档建议包含系统模块划分、前后端交互协议、数据流向、关键目录结构、部署方式。基于 01-requirements.md完成 LLM Wiki 的架构设计 - 模块划分后端 API、向量检索服务、前端管理界面、知识库解析任务。 - 前后端交互RESTful API认证使用 JWT。 - 数据流Markdown 文件录入 - 解析为正文和元数据 - 存入 SQLite - 生成向量索引 - 查询时召回 - LLM 生成摘要。 - 输出到 docs/specs/02-architecture.md。这一轮输出的架构文档是后面所有代码生成的“总依据”。后续每一轮如果模型出现偏离我只需要让它重新参考 02-architecture.md 里的约束即可。这也是多轮开发中防止“跑偏”的关键手段。6.3 阶段三数据模型设计数据模型阶段调用schema-designerSkill 生成 SQLite 表结构。此时 Skill 会自动约束字段命名、软删除、索引规范。提示词示例根据 02-architecture.md 中定义的数据流设计 SQLite 数据表。 需要覆盖用户表、Wiki 页面表、页面版本表、标签表、检索记录表。 调用 schema-designer 技能输出 SQL 和设计说明。这里模型会依据 SKILL.md 中的规则生成完整的建表 SQL同时附带设计思路说明。我们把这轮输出的 SQL 保存到server/schema.sql后续建表和初始化都基于这个文件。6.4 阶段四后端工程骨架与核心 API进入实际编码阶段。这一轮提示主要集中在三个任务初始化 FastAPI 项目、配置数据库连接、实现页面 CRUD API。按照 02-architecture.md初始化 FastAPI 项目 - 目录结构api/、models/、repositories/、services/。 - 使用 SQLAlchemy 连接 SQLite读取 schema.sql 完成建表。 - 实现 Wiki 页面的列表、详情、创建、编辑、软删除 API。 - 遵循 Preset 中的代码规范。 完成后检查 server/ 是否可运行。借助文件读写插件和终端插件模型可以直接创建目录、写文件、运行测试命令。这个阶段会生成大量代码文件但不需要每段代码都靠对话逐行生成插件已经把“生成代码 - 写入文件 - 检查语法”的闭环自动化了。6.5 阶段五知识库解析与索引模块LLM Wiki 的核心能力之一是从 Markdown 文件中解析知识内容并建立索引。新增知识库解析模块 - 支持读取 docs/ 目录下的 Markdown 文件。 - 解析 frontmatter 中的 title、tags、summary 字段。 - 将正文按标题拆分为 chunks。 - 为每个 chunk 生成向量并存入本地索引表中。 - 提供重解析命令python -m server.ingest --docs-dir ./docs。这一轮的关键是让模型实现一个独立的可执行脚本而不是把解析逻辑藏在 API 路由中。这样一来用户可以随时手动触发知识库更新。6.6 阶段六语义检索接口有了索引接下来需要把“搜得到”做成 API。实现语义检索接口 /api/search - 输入查询文本。 - 处理把查询文本向量化与知识库 chunk 向量做余弦相似度排序。 - 输出Top 5 结果包含标题、片段、相似度、来源文件。 - 同时提供 /api/search?typekeyword 关键词检索模式作为兜底。这个阶段需要插件有访问模型 Embedding 接口的能力。向量维度、相似度阈值都可以在前序 Preset 或配置文件中定义避免在每轮对话中重复说明。6.7 阶段七LLM 摘要与问答生成LLM Wiki 的“智能”体现在能基于检索结果生成答案和摘要。这一阶段给模型增加一个调用链用户提问 - 召回相关 chunks - 组装上下文 - 调用 LLM 生成回答。新增 LLM 问答服务 - 服务名server/services/llm_service.py。 - 输入用户问题。 - 流程调用语义检索接口拿到 Top 3 片段拼接到 Prompt 中要求模型基于片段回答禁止编造。 - 输出回答文本 引用片段来源。 - 新增 POST /api/ask 接口。这里要特别强调 Prompt 中“禁止编造、基于片段回答、注明引用来源”的约束。这部分约束也可以沉淀到wiki-summarySkill 里避免每次都要临时写。6.8 阶段八前端基础框架与页面后端能力成型后进入前端开发。前端采用 Vue 3 Tailwind CSS页面包括 Wiki 列表、详情页、问答页、编辑页。初始化 Vue 3 Vite 前端项目 - 页面列表页 /、详情页 /page/:id、问答页 /ask、编辑页 /edit/:id。 - 路由使用 vue-router状态管理使用 Pinia。 - 调用后端 API 的封装放在 src/api/index.js。 - 列表页展示 Wiki 页面卡片包含标题、标签、更新时间。由于前一轮已经把 API 接口定义清楚前端页面可以基于接口文档直接生成不需要再额外设计数据结构。6.9 阶段九Preset 与 Skills 的迭代优化到此为止系统已经具备基本功能。这一轮做一次“元层面的复盘”检查开发过程中模型表现不稳定的环节把这些经验回写到 Preset 和 Skill 中。比如如果发现 LLM 生成的 SQL 经常缺少索引可以在schema-designerSkill 的约束里补一句“所有查询频繁的字段必须设计索引”如果发现模型回答问题时偶尔引用不存在的来源可以在llm_service的 Prompt 中增加“如果返回的片段与问题无关请直接说明无法回答”。这个过程是整个方法论的精华每一轮项目开发都在沉淀下一次开发的资产。Preset 和 Skills 不是写一次就固定不变的它们应该随项目推进持续迭代。6.10 阶段十插件扩展与联调功能完整后的集成测试阶段。检查插件是否能正常完成文件读取、命令执行等任务并把联调过程中发现的问题统一修复。现在进入集成自测阶段 1. 启动后端服务验证五个核心 API 均返回 200。 2. 启动前端开发服务器确认三个页面可正常访问。 3. 运行知识库解析脚本确认 docs/ 下测试文档可被正确索引。 4. 用 curl 调用 /api/ask验证问答链路。 将发现的问题列表输出为 docs/specs/03-issues.md。如果因为插件权限配置导致模型无法读取某些文件需要检查插件的permissions配置确保包含了fs:read、fs:write、terminal:run等必要权限。6.11 阶段十一README、配置打包与项目交付最后一个阶段做项目收尾。让模型生成 README整理配置模板把.dsh目录的配置固化到模板库中。完成项目交付准备工作 1. 编写 README.md项目简介、安装步骤、启动命令、API 文档入口。 2. 检查 .dsh/presets 和 .dsh/skills 是否包含任何敏感信息。 3. 输出一份 .env.example 文件列出所有需要配置的环境变量。 4. 整理项目交付清单 docs/specs/04-final-checklist.md。到这里一个 LLM Wiki 项目从需求到交付的 11 个阶段全部完成。整个过程约 10 轮提示每一轮都有明确的产出物核心代码由模型生成但架构决策、规范约束和验收检查由 Preset、Skills 和插件体系共同保证。这种开发方式不再是“让 AI 写代码”而是“按工程方法使用 AI 写代码”。7. 常见问题与排查思路7.1 安装与启动类问题问题现象常见原因解决思路安装卡在 pnpm 阶段网络源不稳定或依赖锁版本冲突切换 npmmirror 镜像源删除 node_modules 后重装dsh web启动后页面空白管理端依赖未正确构建检查 Node 版本是否满足要求执行依赖重建命令浏览器无法访问管理界面端口被占用或防火墙拦截检查终端输出中的实际端口更换端口后重试安装类问题的排查顺序建议是先看 Node 版本再查镜像源最后看端口占用。不要一上来就重装系统大部分问题集中在依赖安装环节。7.2 Preset 与 Skill 加载异常如果发现模型的行为完全无视你写的 system_prompt优先检查Preset 文件是否被正确命名为.yaml格式Harness 是否读取了当前项目的.dsh目录。Skill 的when_to_use条件是否覆盖了当前场景。如果描述的是“当需要设计数据库时”那么在问答生成阶段它不会被加载。多个 Skill 之间是否存在指令冲突。比如code-review要求所有代码必须附带评审意见而另一个 Skill 要求输出精简代码两者可能同时生效导致模型行为混乱。7.3 多轮开发中模型偏离设计多轮对话最容易出现的问题是第 5 轮生成的代码与第 2 轮的架构设计不一致。解决办法是“用文档锚定上下文”。实践中推荐在每一轮提示的开头加上一句话请先阅读 docs/specs/02-architecture.md 中的约束再开始本次开发任务。这句话虽然简单但能显著降低模型偏离设计文档的概率。根本原因在于架构文档是静态的、完整的而对话历史是动态的、会被截断的。把核心约束资源化到文件里比反复在对话中强调更可靠。8. 最佳实践与工程建议在几个完整项目的开发中我沉淀了下面这些值得长期使用的经验。8.1 把约束写进配置而不是写进对话每一个你反复对 LLM 强调的规则都值得固化到 Preset、Skill 或规格文档中。如果同样的话在对话里说了三次以上说明它应该被结构化。比如“所有时间字段用 created_at 和 updated_at”这种规则只需要写进 schema-designer 的 SKILL.md后面所有表设计都会自动遵守不用每次重新说。8.2 用规格文档管理长项目上下文对话历史一长模型的注意力就会分散。最有效的缓解方式是为项目建立docs/specs目录每个阶段生成一份规格文档。下一阶段开始时让模型先读取对应文档再开始编码。规格文档回答了三类问题项目要做什么、当前做到哪一步、有哪些硬性约束。这三类信息恰恰是对话历史中最容易丢失的。8.3 插件权限遵循最小授权原则插件的权限越大模型能做的事越多但风险也越高。在配置permissions时只开放当前任务必需的权限。比如知识库解析阶段只需要fs:read就不要同时给fs:write和terminal:run。特别是涉及生产环境或敏感文件时要保证所有操作都在项目目录内完成并且执行破坏性命令之前在对话中向用户确认。8.4 定期刷新模型的状态认知即使有文档锚定模型在连续多轮后也可能对当前文件状态产生错误判断。建议每个阶段开始时用一条消息让模型“列出项目当前的文件结构并说明自上次文档以来是否有新增文件”确认状态后再继续。这一步能避免大量重复生成或覆盖已有代码的问题。8.5 把 Skill 当作团队知识沉淀的载体当团队里沉淀了一套代码规范、评审清单、数据库设计约定后把这些内容做成一个 Skill整个团队的 AI 辅助开发就会站在同一个基准线上。新成员加入时不需要背诵规范文档只要配置好 Harness 环境模型就会在编码过程中自动遵守。Skill 的维护频率可以是一周一次在团队复盘后更新。8.6 版本管理不要放松AI 生成的代码同样需要 Git 管理。11 个开发阶段中每个阶段完成时都建议做一次提交提交信息遵循 Angular 规范。这样即使某个阶段的生成结果不符合预期也可以用git revert干净地回退不需要靠对话把代码“改回去”。9. 总结与下一步方向这篇文章围绕 DeepSeek Harness把 Preset、Skills、插件三件套的机制拆开讲了一遍并用一个 LLM Wiki 项目的 11 个开发阶段串起了完整流程。你可能已经注意到这套实践的核心并不复杂把项目背景放入 Preset把专业能力放入 Skills把操作权限交给插件再用规格文档锚定每一轮开发的上文。下一步你可以从三个方向继续深入一是把自己常用的开发规范整理成 Personal Skills 集合二是给现有项目写一套可复用的 Preset观察迭代速度是否明显提升三是尝试用同样的方法做一个不同类型的项目比如 API 服务或数据分析工具检验这套工作流的通用性。AI 开发工具还在快速演进Preset、Skills、插件这些概念的具体实现可能会变但“把上下文结构化、把能力模块化、把流程工程化”的思路不会过时。如果你正在尝试用 LLM 驱动完整项目建议从这篇文章里的最小结构开始先搭建一份自己的 Preset再慢慢积累 Skill 和插件几轮迭代后会发现项目开发方式已经发生了明显变化。 
