最近刷抖音、公众号经常看到 DeepSeek Harness 开源，于是我也好奇的打开了它的仓库看了一眼，结果太开心了，没想到这个项目也是 Vibe Coding 做的，这让我特别兴奋。AI Coding 在2026已经一点儿不稀奇了，开源项目很多，但是很多时候我只能看到别人做好的最终产品，实现过程中的提示词，决策权衡，Agent工作的时候的约束文档，流程，记忆管理等等这些并没有开源出来。
如今的模型已经非常强大了，Codex、Claude Code等各种Agent也已经非常强大了。明明已经技术工具平权了，可这些工具在有些人手里可以做到几天甚至几小时做出来一个高质量的产品，而在我手里却总是出错，换个会话忘记东西，做个大点的项目，复杂一点的立马失控。我在去年年底体验了Claude Code之后就得出了结论，如今的时代，技术工具平权，瓶颈在我不在AI。虽有此觉悟，但是一直以来我也只是胡乱摸索，没有看到过这样优秀的案例去模仿。
DeepSeek Harness 吸引我的，是它对 AGENTS.md、架构文档、Agent Notes、Skills 和验证脚本的组织方式。看得越深入，我越觉得：不同的人使用同样的工具，却能产生巨大差距，关键可能不只在工具，也不只在于谁更会写 Prompt，而在于谁能为 AI 设计一套更完整的工作环境。
前两年我们谈 AI Coding，往往是在谈“怎么让 AI 写出更好的代码”。但如果把时间尺度拉长，把任务从一个函数扩大到一个项目，问题就会发生变化：AI 是否知道这个项目真正要解决什么？是否理解现有架构和模块边界？是否知道一个设计为什么存在？是否能判断这次修改需要同步哪些文档和测试？换一个会话之后，它还能不能继续？
如果这些问题没有答案，那么再强的模型，也只能在一次次临时聊天里重新猜测。
我越来越确定，AI Coding 的下一阶段不是继续雕琢一段更长、更精巧的提示词，而是从“使用 AI”走向“设计 AI 的工作系统”。
一、聊天式 Vibe Coding 的问题，不是自然语言
自然语言会继续成为人与 AI 协作的主要接口。它足够灵活，也最接近人表达意图的方式。因此，Vibe Coding 的局限并不在于“用口语和 AI 聊天”。真正的问题是，聊天中的意图、决策、约束和教训没有被转化成项目资产。
在一个短任务里，我可以告诉 AI：“帮我加一个登录功能，记得处理异常，再补几个测试。”模型也许能一次完成。但项目变大以后，很多信息并不适合永远重复在对话里：
- 哪些目录不能修改？
- 当前系统的真实调用链是什么？
- 为什么当初选择这种数据结构？
- 这次需求明确包含什么，又明确不包含什么？
- 哪些测试是完成前必须通过的？
- 如果会话中断，下一个 Agent 从哪里继续？
聊天记录不是可靠的项目状态。它会被压缩、截断，也会随着新会话消失。更危险的是，聊天里经常混合事实、计划、猜测和已经过时的信息。模型上下文看似很多，真正可用的内容却很少。
所以，Vibe Coding 不是不能用，而是不能只停留在 Vibe。自然语言适合表达意图，却不能独自承担项目治理、状态维护和质量验证。
二、AI Nature：把 AI 当作能力很强、但有局限的同事
我理解的 AI Nature，是承认 AI 已经具备很强的分析和执行能力，并愿意把适合它的工作真正交出去；与此同时，也不把它想象成一个无所不知、永不遗忘、一定会自觉遵守流程的完美员工。
如果把 AI 当作同事，我们不会只在入职第一天对他说一句“好好干”，然后期待他永远做对。一个真实的同事需要了解组织规则、系统架构、当前任务、历史决策和验收标准，也需要在行动后接受测试和审查。
AI 也是一样。它需要的不是一份无限膨胀的说明书，而是一套清晰的上下文加载顺序：
用户本次目标→ 项目全局规则→ 目标模块的局部约束→ 当前架构与系统事实→ 本次变更的规格和验收标准→ 相关决策记录→ 对应的执行流程→ 源码与测试→ 验证结果这个顺序很重要。根目录规则负责稳定、全局、每次都不能忘记的内容；模块规则提供局部事实；架构文档解释系统现在是什么样；决策记录解释为什么走到今天；任务规格说明这一次究竟要改变什么；代码和测试则提供最新证据。
上下文不是越多越好。错误、陈旧和相互冲突的信息，比信息不足更加危险。成熟的上下文工程追求的不是“把所有文档都塞给模型”，而是在正确的时刻，加载正确的事实。
三、真正的上下文工程，是给每类信息安排唯一的位置
一个项目的 AGENTS.md 很容易越写越长。今天遇到一个问题，就往里面加一条规则；明天换一个工具，再复制一份 CLAUDE.md；架构说明同时出现在 README、设计文档和提示词里。短期看似完整，长期一定会产生冲突。
DeepSeek Harness 给我最大的启发，是“一条事实只有一个家”。它没有让根 AGENTS.md 变成项目百科全书，而是把不同信息放在不同生命周期中：
AGENTS.md 稳定边界、入口和导航模块 AGENTS.md 局部约束architecture.md 当前系统结构Agent Notes / ADR 决策理由、替代方案和后果Skills 可复用的操作流程scripts / CI 可以被机器判断的检查postmortems 事故经过和修复经验根规则只负责告诉 Agent“应该去哪里找”，不重复抄写其他文档的正文。不同工具需要不同入口时，优先使用软链接或导入，让 CLAUDE.md、AGENTS.md 等入口指向同一份事实，而不是维护多个内容相似、迟早不一致的文件。
这件事表面上是在写约束文档，本质上是在管理信息的所有权和生命周期：
- 架构现状改变时，更新架构文档。
- 设计选择改变时，新增或更新决策记录。
- 工作步骤反复出现时，把它做成 Skill。
- 事故发生并被修复后，把教训放进 Postmortem。
- 已经过时的任务上下文及时归档，不继续污染当前事实。
只有每类信息有明确归属，Agent 才能知道应该相信什么，人也才知道发生变化时应该更新哪里。
四、规则不等于系统，能执行和验证才算
有时候项目已经有几十条 AI 规则，但实际效果仍然不稳定。原因在于，自然语言规则本质上只是提醒。
“完成前必须运行测试”是一条规则；测试失败时，Stop Hook 直接拒绝 Agent 结束，才是一种机制。
“修改核心模块后同步架构文档”是一条规则；CI 检测到核心代码改变而文档没有更新，并阻止合并，才是一种机制。
我现在很认同一个判断：凡是能够被程序判定的要求，就不应该只写成自然语言。
适合写进上下文的，是需要理解和权衡的内容，例如架构边界、设计原则、风险偏好和任务路由。适合交给脚本、Hook 和 CI 的，是格式化、lint、类型检查、测试、死链检查、生成文件同步和敏感文件保护。
这也是 Agent Harness 和普通 Prompt 集合的真正区别。Prompt 告诉 AI“最好怎么做”，Harness 则让项目具备一条可运行的工作链：
研究事实→ 明确规格→ 形成计划→ 拆分原子任务→ 执行修改→ 运行验证→ 同步文档与决策→ 归档变更每一步都有明确输入、输出和停止条件。即使换一个模型、换一个会话，甚至换一个人，工作仍然可以继续。
五、成熟项目已经在从“对话”走向“产物”
我用hv-analysis去调研了大家都是如何设计AI工作流的。这次调研里，我看到的不同项目虽然形式各异，却在向同一个方向收敛。
GitHub Spec Kit 把项目宪法、功能规格、技术计划和任务清单连接起来，让模糊需求逐步变成可审查的工程产物。OpenSpec 更轻量，它把内容分成“当前有效规格、正在发生的变更、已经完成的归档”，很适合在已有项目中逐步建立上下文。
Superpowers 把头脑风暴、计划、TDD、Review 和完工验证拆成按需加载的 Skills，避免把所有流程都塞进根规则。GSD 和 Ralph 一类方法则强调把状态写入磁盘，让新的上下文也能从任务账本和 Git 历史继续执行。
这些项目给我的共同启发是：聊天不再是真相源，阶段产物才是。
研究阶段输出被确认的事实，规格阶段输出需求和验收标准，计划阶段输出技术选择，执行阶段输出代码，验证阶段输出证据。下一阶段读取上一个阶段经过压缩和审查的产物，而不是背着整段聊天历史继续向前。
这样做还有一个重要好处：它把人的注意力放在了杠杆最高的位置。一个错误的研究结论，可能带来一份错误计划；一份错误计划，又可能让 AI 快速生成几百行方向完全错误的代码。与其等代码全部生成后逐行补救，不如在研究、规格和计划阶段及时介入。
六、人的价值不会消失，而是向上移动
我曾经把 AI Nature 简单理解为“人负责下达指令和做决策，AI 负责执行”。现在我觉得还需要补充一句：人的决策必须进入可审查的规格和验证机制，否则所谓决策仍然只是一次口头指令。
当 AI 写代码越来越快，人的价值会更多集中在三个位置：
- 研究事实：系统现在到底怎样运行，真正的问题在哪里。
- 选择方向：这次应该解决哪一层问题，接受什么代价，放弃什么方案。
- 判断结果：功能是否真的满足目标，而不只是测试变绿或任务被打勾。
未来人与人之间的差距，可能越来越少来自敲代码的速度，越来越多来自认知、问题定义、上下文组织、约束设计和验收能力。
只提出一个问题让 AI 完成，是一种使用；把重复有效的协作方式沉淀成规格、Skill、脚本和 Gate，让 AI 可以持续稳定地完成，是另一种使用。后者才更接近真正的生产力杠杆。
七、不要一开始就造一座“AI 官僚系统”
上下文工程也有自己的陷阱：看到成熟项目的目录之后，复制几十个文件，生成大量 PRD、Spec、Plan、Task 和总结，最后维护文档的时间比开发还多。
流程不是越完整越好，它应该与任务的不确定性、影响范围和失败代价匹配。
小修复读取局部规则 → 修改 → 最小测试 → 检查 diff
中型功能研究 → 规格 → 计划 → 任务 → 实现 → 验证 → 归档
架构迁移或高风险任务项目宪法 → 研究 → 规格 → 架构决策 → 任务图→ 分阶段执行 → CI / 人工验收 → 复盘对个人项目而言，最小可行的 Harness 可能只需要四样东西：
- 一份短小的
AGENTS.md，只保存边界、入口和导航。 - 一套轻量的
proposal / spec / plan / tasks变更目录。 - 一个聚合 lint、测试和构建的
verify脚本。 - 一份能让新会话继续工作的任务状态记录。
先用它完成一个小修复、一个中型功能和一次跨模块变更，记录上下文缺失、误解、返工和验证失败。只有反复出现的问题，才值得沉淀进规则、Skill 或脚本。
真正有价值的 Harness，不是从别人仓库里复制出来的漂亮目录，而是在真实协作中不断暴露问题、修复问题，最后长出来的一套工作制度。
八、从使用工具，到设计生产力系统
AI 时代已经到来，但它还没有真正进入大多数人的工作方式。很多人已经开始使用 AI，却仍然把它当作一个更聪明的搜索框或代码补全工具。真正用得好的人，正在把 AI 组织成产品、流程和可以反复运行的能力。
计算机背景让我更容易理解模型和工程工具，但也可能让我陷入技术细节。框架会变化，工具会更新，真正值得长期积累的，是如何定义问题、组织事实、设计约束、安排反馈，并让一个复杂任务在不依赖单次灵感的情况下持续向前。
我还没有完全想清楚，两年后的 AI 工作方式会变成什么样。但我已经看见一个值得长期验证的方向：把有效的 AI 协作流程做成模板，在不同项目中复用，再用真实结果不断修正它。
从 Prompt 到 Context，从对话到流程，从规则到 Gate，从一次成功到稳定复现——这可能就是从“会使用 AI”走向“会设计 AI 工作系统”的过程。