企业官网建设流程全解析

“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 Wiki：11 个阶段到底是怎么拆的

项目标题里的“11阶段”不是随便列出来的。它对应着从想法到可运行项目的一次完整演进。拆解得好，每一轮提示都有明确目标；拆得不好，10轮提示就会变成10次漫无目的的聊天。

3.1 LLM Wiki 到底是个什么项目

“LLM Wiki”这个词听起来很简单，但不同人对它的理解差异很大。在 Andrej Karpathy 提出的 wiki 范式里，重点在于用 LLM 辅助构建和维护一个知识系统。它不只是一个静态文档站，而是一个能持续收纳、整理、生成、更新知识条目的基础结构。

具体到这个项目，可以把它理解为一个以 Markdown 文件为主的知识仓库，带索引、搜索、标签和 wiki 页面渲染。LLM 的作用是辅助内容生成、结构调整和信息整合。人的作用则是定义内容范围、审核生成结果、决定知识如何组织。

这类项目很适合用来验证 Harness 的工作流，因为它天然是文档驱动、结构清晰、可以批量处理内容的项目，而且边界不像业务系统那样模糊复杂。但它也有自己的难点：内容质量判断、结构一致性维护、批量生成时的去重和引用管理，都需要额外设计。

3.2 11 个阶段的演进路径

下面按我在实测中建议的顺序列出这 11 个阶段。每个阶段并不是简单的“顺序执行”，而是“完成一个里程碑、验证一次、再进入下一个”。

1. 需求定义：先让模型帮助你写出项目说明书，明确目标用户、核心功能、非目标、验收标准。这一轮不是为了写代码，而是为了确认双方理解一致。
2. 技术选型：根据需求选择技术栈，包括框架、文档方案、索引方案、部署方式。选型要给出理由，避免“因为某框架流行”的模糊判断。
3. 项目骨架：生成目录结构、配置文件、入口文件、环境变量模板。这里可以先不写业务逻辑，只看结构是否合理。
4. 数据模型设计：定义 wiki 条目、标签、索引、引用关系的结构。尤其要设计好元信息字段，比如创建时间、更新时间、状态、来源。
5. 页面与组件：生成页面模板、路由、布局和基本交互。重点看页面能否正确读取数据模型。
6. 核心 API 与读写逻辑：实现条目的增删改查、文件读写、目录扫描。这是最容易出问题的环节，要设计清晰的接口边界。
7. 内容生成流程：接入 LLM，实现“根据主题生成 wiki 条目”的能力。这一步要控制好输出质量、长度和格式。
8. 检索与索引：实现关键词检索、标签过滤、相关条目推荐。Wiki 的核心是信息组织，索引做不好，内容再多也难用。
9. 审核与编辑流程：加入“草稿 → 审核 → 发布”的状态流转，保证生成内容不会未经确认就进入正式知识库。
10. 部署与运行：配置本地运行和生产部署方案。这个阶段要验证不是“在我的机器上能跑”，而是“按文档跑能成功”。
11. 复盘与文档化：让模型根据整个开发过程生成项目文档、维护指南和后续迭代建议。这一步也会沉淀出后续可复用的 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，结果自然起不来。

排查顺序建议这样做：

1. 先确认 Node 和 pnpm 版本，是否在项目要求范围内。
2. 清掉 pnpm 缓存，重新执行依赖安装。
3. 执行命令时留意是否有报错日志，是网络超时、版本冲突还是权限问题。
4. 检查目标端口是否被占用，必要时换端口。

提醒：任何安装类问题，第一步永远是看完整报错日志。不要一上来就重装、换源、清缓存。日志通常已经把原因写清楚了。

5.2 提示轮次控制：为什么输出会截断、跑飞或前后不一致

用多轮提示开发项目时，最容易出现的问题不是“模型不懂”，而是“模型跑着跑着忘了之前约定”。常见表现有：第二轮还在用第一轮定的目录结构，第四轮就突然换了一种写文件的方式；或者某轮生成过长，超出上下文限制被截断。

这个问题要从两个方向解决。

第一，不要在同一轮塞太多任务。每一轮只做一个阶段，阶段之间保留检查点。比如生成完项目骨架，就停一下，确认文件结构和约定都符合预期，再进入下一轮。

第二，把关键约定写进 Preset，而不是依赖模型记忆。目录结构、文件命名规范、元信息字段这些内容，一旦写进 Preset，每一轮都会被重新注入上下文，模型就不会跑飞。

如果已经出现前后不一致的情况，不要硬着头皮继续追问。回到上一个检查点，修正方向，再继续。多轮提示的优势恰恰就是你不需要一次做对。

5.3 通用排查链路：先看输入，再看环境，再看参数，最后看工具边界

不管是在安装、生成、还是插件调用阶段出错，都可以按同一个链路排查：

1. 输入是否有问题：路径对不对、文件格式对不对、字段名是否正确、是否缺少必要参数。
2. 环境是否有问题：版本、权限、进程、端口、环境变量、依赖是否完整。
3. 参数是否有问题：批量数、超时时间、输出目录、模型选择、Prompt 长度是否合理。
4. 工具边界是否有问题：当前版本是否支持该功能、插件权限是否不够、项目设计本身是否超出 Harness 的能力范围。

这条链路看起来像套话，但它确实能解决大部分问题。因为很多报错表面上指向代码，但根因往往是输入路径不存在、权限目录不可写、或者参数配置和实际环境不匹配。

6. 从“10轮跑通”到“长期工程化”：判断标准、适用边界与可复用框架

6.1 什么样的项目适合用这种多轮方式开发

不是所有项目都适合“10轮提示 + Harness”的开发方式。从这次实测来看，适合的项目通常具备几个特征：

• 边界清晰：目标用户、核心功能、交付物都比较明确，不需要和多个外部系统深度集成。
• 文档/内容驱动：项目产物以文件、文档、知识条目、代码结构为主，便于分阶段生成和验收。
• 输出可校验：生成结果可以通过目录结构、编译运行、内容格式等方式检查，而不是只能靠主观判断。
• 规模可控：单机可运行、可测试，不涉及大规模分布式部署和复杂权限设计。

按照这个标准，LLM Wiki 非常合适。一个团队内部的知识管理工具、一个文档站点、一个脚手架项目、一个学习用的小系统，也都合适。

相反，如果你要构建一个需要复杂网络、安全审计、多团队协作、实时数据同步的大型系统，那 10 轮提示只能完成早期骨架或部分模块，不可能替代完整的工程和治理流程。这不是 Harness 的缺陷，而是工具适用边界的自然限制。

6.2 一个可复用的开发框架：运行前、运行中、运行后

这次跑通之后，我沉淀了一个可以复用的三阶段框架，不一定只适用于 DeepSeek Harness，也可以用在其他 LLM 编码工具上。

运行前：定义验收标准，准备最小样本。

不要直接开跑。先在 Preset 里定义清楚项目目标、技术栈、输出规范和禁止事项。再准备一个最小测试样本，比如只有两三个条目的 Markdown 目录，先验证检索、渲染、编辑核心链路。

运行中：逐阶段检查，保留产物。

每一轮提示完成后，都要检查该阶段的产物是否符合退出标准。可以维护一个简单的进度清单，记录每个阶段的完成状态、遗留问题、需要人工修复的地方。产物不只是代码，还包括生成过程中的关键 Prompt、Skills 和 Preset 版本。后面出现问题，才能追溯是哪一轮引入的。

运行后：沉淀经验，补齐工程能力。

项目跑通后，不要急着收工。把这个过程中有效的 Prompt 固化成 Skills，把项目上下文整理成 Preset，把踩过的坑写进文档。然后补上测试、日志、错误处理和部署脚本。这些内容会让一个“能跑的雏形”逐渐变成“能长期维护的系统”。

表格对比一下不同阶段的重点：

6.3 这套流程真正改变的是什么

回到开头那个判断。DeepSeek Harness、Preset、Skills、插件这套组合，最值得关注的不是“10轮能生成一个项目”，而是它为 LLM 参与软件工程提供了一个更接近真实协作的模型。

在传统对话式开发里，模型是“问答工具”，它是被动的，你问一句它答一句。到了 Harness 这种模式里，模型变成了“流程参与者”，它在 Preset 定义的上下文里工作，按 Skills 规定的流程执行，通过插件和真实环境互动。这个转变看起来只是工具形态的变化，但它真正改变的是：LLM 参与开发的方式从“随机建议”变成了“可复用流程”。

如果你也准备尝试这类工作流，我的建议是：不要追求“一轮写出所有代码”，也不要幻想模型能独立完成整个系统。先选一个边界清晰的工具型项目，把 Preset 写好，把一个核心 Skills 定义清楚，跑通一遍再逐步扩展。等这一遍走完，你会对一个此前容易忽略的问题有更实际的理解：判断模型输出能不能用，最终靠的不是模型，而是人的工程判断力。工具负责把生成过程变得可控，但你依然要为项目的边界、质量和长期维护负责。