“10轮提示完成工业级项目”我第一次看到这个说法时下意识觉得它多半是标题党。但真正在 DeepSeek Harness 里跑完一遍从零开发 LLM Wiki 的流程后我的判断发生了一些变化这句话不是完全不可能但它成立的前提和很多人理解的“多问模型几句就能拿到完整项目”完全不同。真正有价值的不是“10轮”这个数字而是在这10轮背后模型从一次只会吐代码的对话窗口变成了一个能被 Preset 约束上下文、被 Skills 固化经验、被插件扩展能力的工作流节点。换句话讲DeepSeek Harness 这类工具要解决的根本问题不是“让模型更聪明”而是“让模型在开发项目时更可控、更可复用、更接近工程协作”。这篇文章我想从一次完整实测出发拆解这个判断。我会先讲清楚 Harness 和普通聊天式 LLM 使用的本质区别然后回到“10轮提示”这个争议点再按 11 个阶段复盘从零开发 LLM Wiki 的过程最后落到 Preset、Skills、插件这套机制怎么用以及在真正落地时最容易踩的坑和排查链路。1. 先搞清楚 DeepSeek Harness 到底解决的是哪一类问题很多人第一次接触 DeepSeek Harness会把它理解成“又一个模型调用工具”。这个理解不算错但会让人错过它最有价值的部分。1.1 Harness 不是模型而是跑在模型外层的执行框架在常见的对话式开发里你会打开聊天窗口粘贴需求得到回答然后继续追问。整个过程是线性的、松散的、完全依赖模型临场发挥的。Harness 的思路不是这样。它更像是在模型外面套了一层执行系统你定义任务、约束、步骤、预设和技能Harness 负责按流程把任务拆给模型再收集输出、校验结果、决定下一步。模型仍然是那个模型但驱动方式变了。打个比方。普通对话式 LLM 使用像你直接和一位顾问聊天每句话都从零开始理解上下文Harness 的使用更像你给团队发了一份项目简报里面包含角色、岗位职责、交付格式、验收标准然后团队按流程开工每完成一个阶段就汇报一次。同样是一个人面对同样的任务产出稳定性会差很多。所以这里要先有一条明确的主判断DeepSeek Harness 真正解决的不是“模型能力不足”而是“模型使用方式太依赖临场发挥”。它把一次性对话变成了可重复、可约束、可审阅的执行流程。1.2 Preset、Skills、插件这“三件套”怎么分工项目标题里反复出现 Preset、Skills、插件这三个词是理解 Harness 工作方式的关键但它们的分工和作用经常被混在一起。Preset 解决的是“模型每轮开始前应该知道什么”。它是一组预置上下文里面可以写清楚项目角色、技术栈、目录结构、输出格式、禁止事项。它的作用不是提示模型“你是一个助手”而是告诉模型“你当前在哪个项目里、按什么规则工作”。Skills 解决的是“某类任务应该怎么做”。它把一类高频操作固化成技能单元比如“生成 wiki 条目”“检查文档链接”“生成项目骨架”。Skills 本质上是一套标准动作让模型不必每次都重新理解任务而是按既定流程执行。插件解决的是“模型自己做不到的事”。比如读取本地文件、调用外部搜索、执行命令、操作数据库。插件把外部能力接入 Harness让模型能真正作用于环境而不是只输出文本。三者的关系很像工程团队里的三层机制Preset 是项目章程Skills 是 SOP 手册插件是工具箱。少了任何一环Harness 都会退化成普通的聊天窗口三者配合好才能把一次项目开发变成一条稳定流水线。2. “10轮提示”这个说法到底哪里对、哪里不对2.1 单轮大 Prompt 和分阶段多轮提示的差距我见过很多“一次把所有需求写进一个超长 Prompt”的尝试。结果往往比较尴尬输出很容易到一半开始偏离需求或者前面写得比较具体、后面就不自觉地开始偷懒。原因不难理解。一个超大 Prompt 里塞进需求、技术栈、页面结构、数据模型、目录规范、部署要求模型在注意力分配上很难做到全程不偏。越到后面越容易把早先约束忘掉。这不是模型“笨”而是上下文权重天然会向后偏移。分阶段多轮提示则不同。每一轮只解决一个阶段的问题比如第一轮只做需求拆解第二轮只搭骨架第三轮只实现数据模型。每个阶段之间人可以检查一次输出发现问题随时纠正再进入下一轮。这种方式牺牲了一点“一次对话搞定”的爽快感但换来了可控性。回到“10轮完成工业级项目”这个说法。从实测经验看如果项目边界清晰、规模适中10轮提示确实可以完成从需求到可运行原型的全过程。但这个“完成”有边界它完成的是一个结构完整、能本地跑起来、可以通过人工验收去补测的项目雏形而不是一个交付后就不需要维护的工业级系统。2.2 所谓“工业级”差的不只是代码生成这里我想把“工业级”拆一下。一个系统要称得上工业级至少需要满足几类条件代码结构可维护、测试覆盖关键路径、日志和错误处理完整、部署可重复、权限和配置可管理、文档能支撑团队接手。用 10 轮提示生成这些内容理论上是可以的但前提是每一轮都必须为人机协作设计。模型负责生成初稿人负责确认边界、补测试用例、审查安全风险。如果幻想模型自动完成所有事那结果多半停留在“看起来像项目”的阶段而不是“真正能上线维护”的项目。在 LLM Wiki 这个例子里“工业级”我理解为三个层面第一项目结构清晰可以继续扩展而不是一次性生成的死代码第二生成的内容不依赖某一次奇怪输出重新跑流程也能得到一致结果第三后续维护时新需求能通过修改 Preset 和 Skills 快速迭代而不是从头再问一遍。这三点才是“10轮提示”真正的价值。它不是一个“少干活”的捷径而是一条把开发过程可视化、可控化、可持续化的路径。3. 从零开发 LLM Wiki11 个阶段到底是怎么拆的项目标题里的“11阶段”不是随便列出来的。它对应着从想法到可运行项目的一次完整演进。拆解得好每一轮提示都有明确目标拆得不好10轮提示就会变成10次漫无目的的聊天。3.1 LLM Wiki 到底是个什么项目“LLM Wiki”这个词听起来很简单但不同人对它的理解差异很大。在 Andrej Karpathy 提出的 wiki 范式里重点在于用 LLM 辅助构建和维护一个知识系统。它不只是一个静态文档站而是一个能持续收纳、整理、生成、更新知识条目的基础结构。具体到这个项目可以把它理解为一个以 Markdown 文件为主的知识仓库带索引、搜索、标签和 wiki 页面渲染。LLM 的作用是辅助内容生成、结构调整和信息整合。人的作用则是定义内容范围、审核生成结果、决定知识如何组织。这类项目很适合用来验证 Harness 的工作流因为它天然是文档驱动、结构清晰、可以批量处理内容的项目而且边界不像业务系统那样模糊复杂。但它也有自己的难点内容质量判断、结构一致性维护、批量生成时的去重和引用管理都需要额外设计。3.2 11 个阶段的演进路径下面按我在实测中建议的顺序列出这 11 个阶段。每个阶段并不是简单的“顺序执行”而是“完成一个里程碑、验证一次、再进入下一个”。需求定义先让模型帮助你写出项目说明书明确目标用户、核心功能、非目标、验收标准。这一轮不是为了写代码而是为了确认双方理解一致。技术选型根据需求选择技术栈包括框架、文档方案、索引方案、部署方式。选型要给出理由避免“因为某框架流行”的模糊判断。项目骨架生成目录结构、配置文件、入口文件、环境变量模板。这里可以先不写业务逻辑只看结构是否合理。数据模型设计定义 wiki 条目、标签、索引、引用关系的结构。尤其要设计好元信息字段比如创建时间、更新时间、状态、来源。页面与组件生成页面模板、路由、布局和基本交互。重点看页面能否正确读取数据模型。核心 API 与读写逻辑实现条目的增删改查、文件读写、目录扫描。这是最容易出问题的环节要设计清晰的接口边界。内容生成流程接入 LLM实现“根据主题生成 wiki 条目”的能力。这一步要控制好输出质量、长度和格式。检索与索引实现关键词检索、标签过滤、相关条目推荐。Wiki 的核心是信息组织索引做不好内容再多也难用。审核与编辑流程加入“草稿 → 审核 → 发布”的状态流转保证生成内容不会未经确认就进入正式知识库。部署与运行配置本地运行和生产部署方案。这个阶段要验证不是“在我的机器上能跑”而是“按文档跑能成功”。复盘与文档化让模型根据整个开发过程生成项目文档、维护指南和后续迭代建议。这一步也会沉淀出后续可复用的 Preset 和 Skills。每个阶段结束我都建议做一次“退出检查”确认这一轮的产物是否达成交付标准。只有上一阶段完成才进入下一轮提示。3.3 每一轮提示中人和模型的分工是什么很多人在使用多轮生成时会陷入两个极端要么完全放手让模型自由发挥要么每轮都逐字审查、把多轮提示变成多人问答。更有效的做法是每一轮明确模型负责什么、人负责什么。在需求定义阶段模型负责生成初稿和可能遗漏的边界情况人负责判断这个需求和真实目标是否一致。在技术选型阶段模型负责列出方案和对比人负责根据团队熟悉度和长期维护成本拍板。在代码生成阶段模型负责按照既定结构补全实现人负责检查接口和关键逻辑是否符合预期。在内容生成阶段模型负责初稿人负责审核质量和事实准确性。简单说模型负责“生成”人负责“决策”。这个分工写在 Preset 里能让每一轮提示的目的更清晰。4. Preset、Skills、插件在实操里怎么编写和使用只理解概念还不够实际开发时要能写出可用的 Preset 和 Skills才能真正跑通流程。4.1 一个可复用的 Preset 应该包含哪些内容Preset 的本质是上下文预设。它的目标不是写一篇长篇大论而是用最精简的语言让模型在每一轮都清楚现在在哪个项目、用什么技术栈、输出什么风格、必须避免什么。我一般会把它组织成几个区域项目身份一句话说明项目是什么比如“这是一个基于 Markdown 的 LLM Wiki 知识管理系统”。角色设定让模型以什么身份工作比如“资深全栈工程师”“技术文档作者”。技术约束明确语言、框架、样式方案、依赖管理方式避免模型自由发挥选型。输出规范要求输出 Markdown 格式、代码带注释、文件路径清晰、不输出无关内容。禁止事项声明“不要生成虚构数据”“不要修改未指定文件”“不要使用未安装依赖”。举个例子一个常见的 Preset 片段可以长这样项目角色资深全栈工程师与技术文档作者 项目目标构建一个基于 Markdown 文件的 LLM Wiki 知识管理系统 技术栈Node.js TypeScript Vite Markdown 解析器 输出规范 - 所有文件使用相对路径引用 - 代码关键处添加中文注释 - 不在未授权目录创建文件 - 文档内容使用中文技术术语保留英文原文 禁止事项 - 不要虚构条目 ID 和统计数据 - 不要引用不存在的页面或文件 - 不要引入额外依赖除非先说明理由这段内容会出现在每一轮提示前让模型始终记得自己在哪个项目里。这个步骤看起来简单但实际对输出稳定性的影响非常大。4.2 一个可用的 Skills 文件应该怎么设计Skills 的价值在于把“某类任务怎么做”固化成标准流程。它和 Preset 的区别是Preset 描述的是“项目是什么”Skills 描述的是“任务怎么做”。写 Skills 时我建议按四段式结构来写触发条件什么情况下会使用这个技能。输入要求模型做这个任务时需要哪些输入。处理步骤任务拆解后的标准动作有哪些。输出格式最终结果应该以什么格式交付以及验收标准。例如写一个“生成 wiki 条目”的 Skills技能名称生成 wiki 条目 触发条件 - 用户要求新增知识条目时 - 检索发现已有条目缺失时 输入要求 - 条目主题 - 目标标签列表 - 是否需要关联已有条目 处理步骤 1. 先搜索知识库中是否已有类似条目 2. 如已有输出合并建议并停止生成 3. 如无按“定义、背景、核心要点、参考资料”结构生成 4. 生成完成后添加元信息字段包括状态为 draft、创建时间、来源标识 输出格式 - Markdown 文件放置在 /content/wiki 目录下 - 文件命名小写英文连字符 - 每条内容控制在 300 到 800 字避免空泛这样设计之后当你在 Harness 里发起“新增一条关于 xxx 的 wiki 条目”任务时模型就不会自由发挥而是按这个流程执行。一次写好的 Skills可以反复使用这也是这个方案能走向工程化的基础。4.3 插件什么时候该接、什么时候不该接插件可以扩展 Harness 的能力边界但插件并不是越多越好。在 LLM Wiki 这个项目里比较自然的插件场景包括本地文件读写插件、目录扫描插件、检索索引插件、Markdown 渲染插件。不过接入插件时要特别注意三个问题来源和权限安装前先确认插件来源是否可信、需要哪些权限、会不会访问敏感目录。无论是从插件市场安装还是手动加载都要先看它的代码逻辑。边界测试接到项目里之后先用一条最小样例验证它能正确读取、写入、返回结果而不是直接跑完整流程。失败处理插件不是永远可靠的文件路径错误、权限不足、编码异常都可能发生。在流程里要设计好插件调用失败时的降级策略。实测经验不要一上来就装一堆插件。先跑通核心流程再按需扩展。插件装多了排查问题时会很难定位是哪一步出的错。5. 从安装到跑通 LLM Wiki 全流程最容易踩的坑和排查链路即使理解了上面的概念实际跑起来也大概率会遇到不少问题。这一部分我按最常见的问题顺序梳理一下。5.1 安装环节为什么会在 pnpm dsh web 这里卡住从热搜词里可以看到很多人会在pnpm dsh web这个环节卡住。这个问题我自己也遇到过常见原因有几类。Node 版本不匹配Harness 这类工具通常对 Node 版本有明确要求。如果你本机的 Node 版本过旧或过新依赖安装阶段就容易报错。pnpm 依赖源问题不同网络环境下依赖下载速度差异很大。有时是某个依赖包下载失败有时是缓存冲突。端口占用dsh web一般会启动本地 Web 服务如果端口被其他进程占用启动就会失败但提示信息不一定直接指向端口冲突。依赖没有完整安装有人会跳过pnpm install直接执行dsh web结果自然起不来。排查顺序建议这样做先确认 Node 和 pnpm 版本是否在项目要求范围内。清掉 pnpm 缓存重新执行依赖安装。执行命令时留意是否有报错日志是网络超时、版本冲突还是权限问题。检查目标端口是否被占用必要时换端口。提醒任何安装类问题第一步永远是看完整报错日志。不要一上来就重装、换源、清缓存。日志通常已经把原因写清楚了。5.2 提示轮次控制为什么输出会截断、跑飞或前后不一致用多轮提示开发项目时最容易出现的问题不是“模型不懂”而是“模型跑着跑着忘了之前约定”。常见表现有第二轮还在用第一轮定的目录结构第四轮就突然换了一种写文件的方式或者某轮生成过长超出上下文限制被截断。这个问题要从两个方向解决。第一不要在同一轮塞太多任务。每一轮只做一个阶段阶段之间保留检查点。比如生成完项目骨架就停一下确认文件结构和约定都符合预期再进入下一轮。第二把关键约定写进 Preset而不是依赖模型记忆。目录结构、文件命名规范、元信息字段这些内容一旦写进 Preset每一轮都会被重新注入上下文模型就不会跑飞。如果已经出现前后不一致的情况不要硬着头皮继续追问。回到上一个检查点修正方向再继续。多轮提示的优势恰恰就是你不需要一次做对。5.3 通用排查链路先看输入再看环境再看参数最后看工具边界不管是在安装、生成、还是插件调用阶段出错都可以按同一个链路排查输入是否有问题路径对不对、文件格式对不对、字段名是否正确、是否缺少必要参数。环境是否有问题版本、权限、进程、端口、环境变量、依赖是否完整。参数是否有问题批量数、超时时间、输出目录、模型选择、Prompt 长度是否合理。工具边界是否有问题当前版本是否支持该功能、插件权限是否不够、项目设计本身是否超出 Harness 的能力范围。这条链路看起来像套话但它确实能解决大部分问题。因为很多报错表面上指向代码但根因往往是输入路径不存在、权限目录不可写、或者参数配置和实际环境不匹配。6. 从“10轮跑通”到“长期工程化”判断标准、适用边界与可复用框架6.1 什么样的项目适合用这种多轮方式开发不是所有项目都适合“10轮提示 Harness”的开发方式。从这次实测来看适合的项目通常具备几个特征边界清晰目标用户、核心功能、交付物都比较明确不需要和多个外部系统深度集成。文档/内容驱动项目产物以文件、文档、知识条目、代码结构为主便于分阶段生成和验收。输出可校验生成结果可以通过目录结构、编译运行、内容格式等方式检查而不是只能靠主观判断。规模可控单机可运行、可测试不涉及大规模分布式部署和复杂权限设计。按照这个标准LLM Wiki 非常合适。一个团队内部的知识管理工具、一个文档站点、一个脚手架项目、一个学习用的小系统也都合适。相反如果你要构建一个需要复杂网络、安全审计、多团队协作、实时数据同步的大型系统那 10 轮提示只能完成早期骨架或部分模块不可能替代完整的工程和治理流程。这不是 Harness 的缺陷而是工具适用边界的自然限制。6.2 一个可复用的开发框架运行前、运行中、运行后这次跑通之后我沉淀了一个可以复用的三阶段框架不一定只适用于 DeepSeek Harness也可以用在其他 LLM 编码工具上。运行前定义验收标准准备最小样本。不要直接开跑。先在 Preset 里定义清楚项目目标、技术栈、输出规范和禁止事项。再准备一个最小测试样本比如只有两三个条目的 Markdown 目录先验证检索、渲染、编辑核心链路。运行中逐阶段检查保留产物。每一轮提示完成后都要检查该阶段的产物是否符合退出标准。可以维护一个简单的进度清单记录每个阶段的完成状态、遗留问题、需要人工修复的地方。产物不只是代码还包括生成过程中的关键 Prompt、Skills 和 Preset 版本。后面出现问题才能追溯是哪一轮引入的。运行后沉淀经验补齐工程能力。项目跑通后不要急着收工。把这个过程中有效的 Prompt 固化成 Skills把项目上下文整理成 Preset把踩过的坑写进文档。然后补上测试、日志、错误处理和部署脚本。这些内容会让一个“能跑的雏形”逐渐变成“能长期维护的系统”。表格对比一下不同阶段的重点阶段核心动作关键产物容易犯的错运行前定义边界与规范Preset、验收清单需求不清就开跑运行中逐轮检查与修正阶段产物、进度记录让模型自由发挥到底运行后沉淀与工程化Skills、文档、测试跑通就结束不补工程能力6.3 这套流程真正改变的是什么回到开头那个判断。DeepSeek Harness、Preset、Skills、插件这套组合最值得关注的不是“10轮能生成一个项目”而是它为 LLM 参与软件工程提供了一个更接近真实协作的模型。在传统对话式开发里模型是“问答工具”它是被动的你问一句它答一句。到了 Harness 这种模式里模型变成了“流程参与者”它在 Preset 定义的上下文里工作按 Skills 规定的流程执行通过插件和真实环境互动。这个转变看起来只是工具形态的变化但它真正改变的是LLM 参与开发的方式从“随机建议”变成了“可复用流程”。如果你也准备尝试这类工作流我的建议是不要追求“一轮写出所有代码”也不要幻想模型能独立完成整个系统。先选一个边界清晰的工具型项目把 Preset 写好把一个核心 Skills 定义清楚跑通一遍再逐步扩展。等这一遍走完你会对一个此前容易忽略的问题有更实际的理解判断模型输出能不能用最终靠的不是模型而是人的工程判断力。工具负责把生成过程变得可控但你依然要为项目的边界、质量和长期维护负责。