1. 先把“10轮提示做完项目”这件事说清楚最近社区里关于 DeepSeek Harness 的讨论明显变多了尤其是“10轮提示完成工业级项目”“11阶段从零开发 LLM Wiki”这类标题很容易让人觉得只要会聊天就能自动写出一个完整项目。我的实际体验是这个说法有真实成分但需要拆开看。它真正解决的问题是把“AI 辅助开发”从零散的对话提问变成一套有阶段、有标准、有产物、可复查的工程流程。这篇内容适合谁看想用 DeepSeek 在本地搭建项目、又不想每次都从空白提示词开始的人对 LLM Wiki 这种知识库范式感兴趣、想用 Preset 和 Skills 管理提示词的人以及已经接触过 Claude Code、Codex 或类似命令行 AI 工具想进一步了解 DeepSeek Harness 生态的开发者。先说结论。如果你把它当成“AI 自动写代码神器”大概率会失望。如果你把它当成“把需求、设计、实现、测试、文档串成一整条流程的脚手架”那 10 轮提示确实能达到工业级项目的基本要求。这里的“工业级”不是在夸它生成代码的质量有多高而是说它有阶段划分、有验收标准、有产物留存能让一个 AI 驱动的项目从想法变成可维护、可交接、可继续迭代的状态。我自己实测下来最值得关注的三个能力是Preset 让提示词模板可复用Skills 让模型具备特定领域的方法论插件机制让 Harness 可以接入更多工作流。这三个能力叠加才是“10 轮完成项目”的真正底层逻辑。单纯靠模型本身的能力在长任务里很容易跑偏有了这些约束和工具才能让每一轮输出都对齐目标。2. 为什么单靠提示词不够必须引入 Harness 这类框架2.1 长对话的失控问题从哪来先还原一个典型场景。你用 DeepSeek 对话上来就说“帮我写一个 Wiki 系统”。模型会给你一个基础代码结构看起来像模像样。然后你继续说“加用户权限”模型改了文件。再说“加全文搜索”模型又改了。五轮之后你发现它忘了最早的表结构登录逻辑和权限判断对不上搜索结果返回的字段和数据库模型不一致。这不是 DeepSeek 的问题。任何大模型在长上下文里都会出现注意力漂移越到后面越容易只盯着最近的对话内容忽略前面已经确定的约束。普通聊天窗口没有“项目状态”没有“文件清单”没有“哪些决定已经不可变”的机制。你嘴上说的“保持之前的设计”模型并不一定能真正做到。Harness 这类框架解决的核心问题就是把“对话”变成“项目工程”。它不是让模型更聪明而是给模型一个结构化的操作界面当前项目处在哪个阶段、有哪些文件、下一步要做什么、完成标准是什么这些信息在每一轮开始时都被重新注入。这样即使模型上下文很长也能通过结构化的状态信息拉回主线。2.2 Preset 是“提示词模板”的高级形态很多人第一次接触 Preset 会以为就是预设回复模板。确实有点类似但关键差别在于 Preset 在 DeepSeek Harness 里承载的是角色、流程和产出标准的组合。举个例子。你不是简单地对模型说“你是一个后端工程师”而是定义一套完整的行为规范遇到需求先拆分接口返回代码时附带改动文件列表每轮结束前给出下一步建议只输出可运行的代码不输出解释性废话。这些规范打包成一个 Preset之后每次启动项目都可以复用。我通常会把 Preset 分成三个层次通用型 Preset适合大多数编程任务强调代码质量、测试覆盖、文档规范。场景型 Preset针对特定任务比如“Wiki 开发”“数据分析脚本”“接口文档生成”。项目型 Preset固定在某个特定项目里包含该项目独有的技术栈、目录结构和编码约定。如果你是第一次使用先从通用型开始跑通流程后再细调自己的场景 Preset。不要一上来就追求完美的 Preset 配置因为你还没踩过坑根本不知道哪些规则对当前项目是真正重要的。2.3 Skills 让模型拥有“领域方法论”Skills 是 DeepSeek Harness 里另一个容易被忽略但实际作用很大的组件。它和 Preset 的区别在于Preset 约束的是行为方式Skills 注入的是专业方法。如果用 Wiki 项目举例一个“LLM Wiki 构建 Skill”会包含类似这样的内容Wiki 的知识结构如何分层条目与条目之间的链接关系如何维护搜索索引应该基于哪些字段权限模型在 Wiki 场景下怎么设计内容版本历史是否需要保留离线阅读和在线编辑如何共存这些内容本质上不是“提示词”而是一份领域知识手册。模型本身可能知道一些通用知识但它不会主动按照这套完整方法论去执行。Skills 的作用就是把这些方法论喂给模型让它按照约定好的方式思考。很多人把 Skills 理解成“技能包”或“插件”这个类比不完全准确。技能包通常是一段固定功能的代码而 Skills 更接近“思维模板”。它不直接执行动作而是改变模型处理问题的方式。我在实际使用中发现好的 Skills 有三个特征有明确的决策流程。有可操作的检查清单。有边界说明告诉模型什么情况下不要继续扩展。如果你将来想写自己的 Skills这三个特征就是最基本的验收入口。3. 实测准备环境、安装方式和第一个 Demo3.1 安装前先确认环境状态DeepSeek Harness 在本地运行依赖 Node.js 和 pnpm 这类前端工具链。我在安装时最常遇到的问题不是 Harness 本身而是环境里已有的 Node 版本、包管理器缓存、权限设置和网络条件。按常见实践安装前先确认这几项Node.js 版本不要太旧建议不低于 18pnpm 已经安装并且版本与项目锁文件兼容网络可以正常访问 npm 源或镜像源磁盘有足够空间存放依赖。原始材料里没有给出明确版本号所以落地时最好先执行node -v和pnpm -v看当前状态再对照项目文档确认要求。这里有一个容易踩的坑很多人直接用系统全局的 pnpm 安装结果依赖装到一半因为权限不足或 registry 配置不对导致失败。更稳妥的方式是先建一个独立的工作目录在里面初始化项目然后安装依赖。这样即使中间出问题也不会污染全局环境。3.2 安装过程的关键节点按照社区里常见的安装路径大致会经历这几个步骤准备一个工作目录比如~/dsh-project。克隆或下载 Harness 项目源码。在项目根目录执行pnpm install安装依赖。执行pnpm dsh web启动桌面端或 Web 界面。首次启动时确认配置、API Key 和模型连接状态。如果你卡在pnpm dsh web这一步先不要急着怀疑代码有问题。最常见的原因是依赖没有完整安装或者端口被占用或者配置文件里的模型地址不可达。这时候先看终端输出再检查配置不要盲目重装。对于第一次跑通的人我的建议是不要跳过最小 Demo。先把 Harness 启动起来确认界面能打开能用它发起一轮简单的对话再逐步引入 Preset 和 Skills。很多人跳过这一步直接上复杂项目一旦出问题连是环境问题还是流程问题都分不清。3.3 连接 DeepSeek 模型时的注意事项DeepSeek Harness 自然支持 DeepSeek 模型作为后端。配置时需要注意模型名称、API 地址和上下文长度这些参数。不同版本的 Harness配置项名称可能略有差异但核心结构相似。一个常被忽略的细节是上下文长度。DeepSeek 模型的不同版本支持的上下文窗口不同如果你在 Preset 或 Skills 里塞入了大量背景材料再加上多轮对话历史很容易触发上下文超限。这时候不是模型能力不够而是你没有管理好输入内容。我一般会在 Preset 里加一条规则“对话超过一定轮次后自动总结已完成内容并在新轮次开始时重新注入关键状态。”这样既能减少上下文占用又能保持项目主线不丢。4. 从零开发 LLM Wiki11 个阶段怎么拆4.1 为什么不是“一口气生成”而是“分阶段开发”如果你看过 Andrej Karpathy 提出的 LLM Wiki 相关讨论会发现核心思路不是让 AI 一次把项目写完而是让它像真实工程师一样分阶段推进。每个阶段有输入、有输出、有验收点。这种方式的优点在于每个阶段的产物都相对简单不容易出错如果中间出现问题可以定位到具体阶段每一阶段的输出可以保存下来后续可追溯。我之前用直聊方式生成过一个小型博客系统前三轮看着很好到第五轮时发现前端组件引用了后端不存在的方法整个项目跑不起来。后来改用分阶段方式十几轮下来反而更稳定因为每一轮都在前一轮已经验证过的基础上继续扩展不会出现“全盘推翻”的风险。11 个阶段并不是固定的模板它取决于项目的复杂度。但 Wiki 项目本身功能边界清晰确实适合这样拆。下面按实际开发顺序给出一套可执行的拆分方式。4.2 阶段拆分参考以“从零开发 LLM Wiki”为例我会拆成 11 个阶段需求确认明确 Wiki 的目标用户、核心功能、非功能需求。技术选型确定前端框架、后端语言、数据库、部署方式。项目初始化创建目录结构配置基础依赖。数据模型设计设计用户、文档、标签、目录、权限相关表结构。后端 API 开发实现文档增删改查、用户认证、搜索接口。前端页面框架搭建页面路由、布局、状态管理。核心功能联调前端调用后端接口跑通主流程。搜索与全文检索接入搜索能力处理索引和结果排序。权限与多用户支持细分角色权限保护私有文档。测试与修复补充关键测试修复问题。部署与文档编写部署说明、使用文档准备上线。每个阶段在 Harness 里都可以是一次或多次对话但核心是阶段之间不能跳。前一个阶段没有验收通过就不要进入下一个阶段。4.3 LLM Wiki 和普通 Wiki 的区别LLM Wiki 和传统 Wiki 项目最大的区别在于内容组织方式更贴合语言模型的知识表达习惯。传统 Wiki 强调人工分类和层级结构而 LLM Wiki 会更多考虑语义关联、双链引用、自动标签和内容块粒度。用 Harness 开发这类项目时需要在需求阶段就明确这些设计取向。比如文档是否支持双链、是否自动生成相关条目推荐、内容块是否需要独立检索。这些需求会影响数据模型和 API 设计如果前期不明确后面改起来成本很高。我会把“LLM Wiki 范式”理解成一种更适合 AI 协作的知识库结构内容可以被拆成小块块与块之间通过引用建立关系搜索结果不只匹配标题也匹配内容块语义。这个范式在 Harness 里开发核心挑战不是功能复杂而是让模型始终理解这种结构不被传统 Web 开发套路带偏。5. 10 轮提示的实战拆解每轮到底在干什么5.1 第一轮到第三轮锁定需求和数据模型第一轮不需要让模型写代码。它的任务是让模型复述你对项目的理解输出一份需求文档。很多人一上来就写“开始开发”结果模型自己脑补了需求后面的阶段全乱了。正确做法是在第一轮要求模型输出完整需求清单并标注哪些功能是必须的、哪些是可选的、哪些默认不做。第二轮让模型基于需求文档输出技术选型建议。这里要注意模型会倾向于给出“标准答案”比如推荐 React Node.js PostgreSQL。你需要追问为什么选这个组合如果我只有一台 2 核 4G 的服务器这个方案还合适吗这样能逼着模型给出更贴合实际条件的回答。第三轮进入数据模型设计。这是整条链路里最重要的一环。如果表结构设计错了后面所有代码都是在错误地基上盖房子。我会要求模型不仅给出字段列表还要补充每个字段的用途、索引策略、关联关系以及未来可能出现的扩展点。5.2 第四轮到第七轮从接口到页面第四轮开始写后端 API。这里不要要求模型一次性写完所有接口而是先写核心的增删改查跑通后再补认证和搜索。每写完一组接口就让它输出接口文档包括请求参数、返回结构和错误码。第五轮做前端页面框架。可以先让模型生成一个最小的页面骨架确认路由能跳转、布局正常再逐步填充功能。很多新手在这一步喜欢让模型直接写完整页面结果 CSS 冲突、状态缺失、接口地址不一致问题一大堆。第六轮进入联调阶段。前端调用后端接口验证主流程用户创建文档、编辑文档、保存文档、查看文档。这里一定要让模型输出验证清单比如“用 curl 测试创建接口”“通过页面创建一篇新文档”等。只有验证通过的代码才允许继续扩展。第七轮处理搜索。Wiki 项目没有搜索就是死路一条但搜索实现方式很多。对于早期版本不必立即接入复杂搜索引擎可以先实现基于数据库 LIKE 查询的简单搜索确认流程可用后再升级为全文索引或向量检索。5.3 第八轮到第十轮权限、测试和部署第八轮加入权限和多用户支持。要确保普通用户只能看公开文档登录用户能创建和编辑自己的文档管理员能有删除和用户管理权限。权限这块最容易出漏洞所以我会特意要求模型输出“越权测试用例”比如普通用户尝试删除管理员文档时系统应返回 403。第九轮做测试和修复。让模型为关键模块编写测试并明确测试通过的标准。同时把前几轮可能出现的问题汇总逐项修复。这里要留意模型写的测试可能过于简单你需要加一句“测试需要覆盖正常流程、异常输入、边界条件三种情况”。第十轮做部署和文档。要求模型输出部署步骤、环境变量清单、启动命令和常见问题说明。一个项目如果只有代码没有部署文档等于没有完成。LLM Wiki 项目在这一步还要额外考虑数据备份和迁移策略因为知识库内容一旦丢失很难找回。从我的实测经验看10 轮确实能覆盖以上内容。前提是每一轮都要有明确的输入、输出和验收标准。如果某一轮内容特别庞大也可以拆成多轮但整体阶段不要乱。6. Preset、Skills 和插件在 Wiki 项目里的真实用法6.1 为 Wiki 项目定制 Preset我建议在启动 LLM Wiki 开发前先编写一个专属 Preset。基础结构可以包含项目名称LLM Wiki。核心技术栈比如 React、Node.js、SQLite 或 PostgreSQL。编码规范组件文件命名、接口返回格式、错误处理方式。每轮输出格式代码、变更文件列表、验证方法、下一步建议。禁止行为不一次性修改全部文件不在没有验证的情况下增加功能。这个 Preset 会在每一轮对话开始前注入让模型每轮都处于同一个项目语境里。相比每次都重新说明项目背景这样省下大量上下文空间也减少了理解偏差。6.2 编写一个 Wiki 领域 Skill如果想让模型在开发 Wiki 时更专业可以写一个名为llm-wiki-builder的 Skill。它的核心内容应该包括 Wiki 架构设计的判断标准比如文档用树形结构还是网状结构。文档明细、版本历史、标签索引如何存储。搜索建议的排序依据。双链引用的数据表设计。内容块是否支持单独检索。是否支持导入 Markdown 和导出 PDF。Skills 不是固定代码更像一份领域专家手册。它让模型在每轮回答前先按照这套方法论思考再生成输出。我会在 Skill 里专门加一个“决策原则”部分当需求不明确时优先选择结构简单、易于迁移、扩展成本低的方案。这一条在真实项目中非常有用能防止模型为了展示能力而把架构做复杂。6.3 插件生态的作用DeepSeek Harness 支持插件机制插件能扩展工作流、编辑器集成、外部服务对接等能力。社区里常见的插件类型包括代码格式化插件、日志增强插件、Git 集成插件、文档生成插件还有一些场景化的“大国工匠”风格模板插件。插件在 Wiki 项目里的实际价值不只是加功能而是把重复性工作自动化。比如写完代码后自动生成变更清单、启动服务后自动打开调试页面、完成一轮任务后自动保存项目快照。使用插件时要克制。一次不要启用太多插件插件之间可能存在依赖冲突或行为竞争。我通常先启用和业务流程直接相关的插件等项目稳定后再逐步增加辅助类。插件的本质是杠杆不是越多越好。6.4 一个完整轮次的提示结构参考在实际操作中我每一轮向 Harness 输入的内容通常包含四部分当前阶段例如“阶段 4后端 API 开发”。阶段目标例如“完成文档的增删改查接口”。已完成状态例如“数据模型已确定表结构见 database.sql”。本轮要求例如“只实现文档 CRUD不碰用户权限输出代码和验证步骤”。这种结构看起来简单但它保证了模型不会跑偏。状态信息让模型知道当前全局阶段目标不给自己加戏本轮要求控制模型的工作边界。7. 测试与验证如何判断每一轮算不算通过7.1 验证不只看“有没有报错”很多人的验证方式非常粗糙代码没有报错就认为完成了。实际上没有报错只说明编译或启动通过不代表业务逻辑正确。在 Harness 驱动的开发流程里每一轮都要有更具体的验证标准。以 Wiki 为例后端 API 开发完成后验证标准应该包括用 curl 创建一篇文档返回 200 和文档 ID。用该 ID 查询文档字段完整无缺失。修改文档后查询内容已更新。删除文档后查询返回 404。创建空标题文档返回 400 错误。未登录用户调用受保护接口返回 401 或 403。这些都是可以在命令行里快速执行的操作。Harness 的意义就在于让模型输出这些验证命令而不是让你凭空设计测试用例。7.2 给模型加“输出验证结果”的要求在我的实测里如果只是让模型写代码它写完就停了。但如果你在 Preset 里加上“每一轮输出必须附带验证结果”模型会主动给出测试命令和预期结果。这一步看起来不起眼实际上能把开发质量拉高一个档次。比如模型在输出文档创建接口后我可以在下一轮让它执行 curl 命令并解释返回结果。如果返回结构不对它会发现问题并修复。如果没有这个要求模型会默认自己写的代码没问题直到你手动运行才发现 bug。7.3 使用 LLM Wiki 项目自身作为测试载体当你在开发 LLM Wiki 时你其实可以用它来测试“LLM Wiki 范式”本身。比如让 Harness 生成一份项目需求文档然后把这份文档作为 Wiki 的初始内容尝试在系统里编辑、链接、搜索。这样做的好处是你一边开发系统一边验证系统的核心使用场景能尽早发现产品层面的问题。如果开发出来的 Wiki 连 AI 生成的内容都管理不好那说明设计还有问题。反过来如果 AI 生成的多粒度内容能在系统里被灵活组织和检索证明这个范式是可行的。8. 容易踩的坑从项目卡住到提示词失控8.1 项目怎么跑着跑着就卡住了卡住分两种。一种是 Harness 本身卡住比如界面无响应、命令执行超时。这时候先看任务管理器里的内存占用、网络是否正常、日志有没有输出。多数情况下重启服务或者清理缓存就能解决。另一种是业务开发逻辑卡住比如模型某一轮输出的代码和上一轮不兼容导致测试一直失败。这时候不要硬刚回到上一个已验证的阶段把状态重新注入再让模型基于该状态继续。不要在新代码里修补旧问题重构的成本往往更小。8.2 提示词越来越长导致上下文超限长任务最容易出现上下文失控。你不断往对话里添加新要求模型越来越“忘本”。解决方式是通过 Preset 注入项目状态摘要而不是把所有历史对话都保留。我会在 Preset 里强制要求“每轮开始时先输出当前项目状态不超过 200 字。内容包括已完成的阶段、正在进行的阶段、当前依赖的关键决定。”这样即使上下文很长模型也能快速进入正确的上下文。8.3 Preset 和 Skills 之间发生冲突有时你设置了严格的 Preset又加载了一个很激进的 Skill模型会不知道听谁的。比如 Preset 说“只在验证后修改代码”Skill 却说“优化现有接口并主动重构”。这种冲突轻则影响输出质量重则导致逻辑混乱。处理方法明确优先级。在 Preset 里写清楚“Preset 中的行为规范优先于 Skills 中的建议除非有关键需求变更”。同时不要一次性加载多个通用 Skill尽可能把职责边界设计清晰。8.4 不要迷信“10 轮”这个数字10 轮提示能完成项目不代表你的项目也只能用 10 轮。10 轮是一个理想化的划分实际开发中任何一个阶段都可能需要多轮迭代。项目复杂度、模型能力、Preset 质量、你对需求的清晰程度都会影响轮次数量。更合理的预期是用阶段划分控制风险让每一阶段的轮次都花在有效产出上。哪怕最终用了 30 轮只要没有大的返工也比 10 轮但反复推倒重来要强得多。9. 从个人测试走向项目交付生产环境要注意的边界9.1 本地能跑通过不等于适合部署我在测试时通常专注于验证功能部署时才会考虑性能、安全、稳定性。开发 Wiki 项目也是一样本地跑通只是一个开始生产环境还有几个问题必须想清楚。数据备份知识库内容有没有定期备份策略。身份认证用户密码如何存储Token 如何管理。接口限流公共部署时要不要限制请求频率。日志监控系统出问题后能不能快速定位。存储容量文档数量和用户增长后磁盘和数据库会不会成为瓶颈。这些问题不会在本地开发时暴露但一旦上线就会变成真实压力。9.2 哪些功能适合依赖 AI 生成哪些不适合AI 生成能力很适合快速搭建原型、生成常规 CRUD 代码、编写配置文件、生成模板文档。但涉及复杂权限体系、高并发场景、数据一致性要求极高的模块绝不能只依赖 AI 生成的结果必须有人工审查和完整测试。以 Wiki 项目为例权限模块我建议人工重点审查。AI 能写出常见的权限判断代码但越权路径、角色升级、Token 失效等细节很容易考虑不周。这类安全相关的问题在测试阶段要专门设计恶意用例。9.3 维护成本项目交付后你还要继续用Harness 开发出的项目最容易被项目交付后的维护成本绊倒。你让 AI 写代码很快但接手的人不一定知道代码逻辑。所以项目文档、部署手册、模块说明缺一不可。我通常会在收尾阶段让 Harness 生成一份“项目演进指南”包括后续如果要增加功能应该从哪里入手、数据模型怎么扩展、哪些文件是核心、哪些文件可以替换。这份文档的价值比多写几个功能点更高。9.4 社区生态还在快速变化DeepSeek Harness、Skills、插件机制都还在快速迭代中。今天能用的插件可能明天要适配新版本今天写的 Skill可能下个版本有了更好的写法。这意味着脚本、配置和依赖版本不要固定在旧版本上最好记录当前使用的版本以便后续迁移。如果你准备把 Harness 引入团队工作流建议先选一个小项目试点跑通并文档化流程后再推广到核心项目。不要一上来就把所有项目都切换到 AI 驱动开发团队的学习成本和项目风险都会成倍放大。10. 资源、文档和下一步行动建议如果你已经跑通了基础流程接下来可以按这个路线继续深入第一整理自己的 Preset 库。把经常使用的角色、行为规范、输出格式整理成模板按类型分存放。以后开新项目时直接套用并微调。第二尝试编写一个自己的 Skill。从最熟悉的领域开始把决策流程、检查清单、边界条件写清楚然后在项目里测试效果。你会发现好 Skill 的迭代过程本身就是成长最快的过程。第三观察社区热门的 Skills 和插件。有些确实有参考价值比如前端开发、学术研究、代码审查等方向。但要注意甄别质量不要看到新插件就装。多问一句它解决什么问题会不会和现有流程冲突。第四把一次完整项目的所有产物归档包括需求文档、数据模型、接口文档、Preset、Skills、测试用例和部署手册。这份归档会成为你以后快速开启新项目的资产。我自己的做法是每个项目结束都保存一份“项目复盘”记录哪些阶段顺利、哪些阶段卡住、原因是什么。如果你准备从零开始试这个流程建议从一个小知识库项目入手按阶段拆解每完成一个阶段都记录验证结果。先跑通一次再优化效率。等你自己能熟练使用 Preset 和 Skills 时再挑战更复杂的工业级项目那时候你才能真正理解 10 轮提示的价值不在数量而在每一轮的质量控制。