文章参考来源：B 站-AI 林湛星的系列视频 + 网络实践补充 + 个人探索思考。
本文梳理当前 AI coding 的几种实践方案，以及它们各自该用在哪，给你提供AI编程治理的思路，希望对你有所帮助～
为什么AI编程越写越乱？
AI 目前是概率模型，不是因果链模型。它靠概率生成内容，所以一定会出错------不是偶尔出错，是结构性的、不可消除的出错。
这决定了用 AI 写代码的核心矛盾：AI 能快速产出大量代码，但你没法完全信任它。这篇文档梳理的就是怎么解这个矛盾------在不同项目阶段，用不同手段把 AI 的不确定性约束在可控范围内。从 Vibe Coding 的"放手跑"，到 Spec 的"写清楚再动手"，再到 Harness 的"用流程锁死"，本质上都是在回答同一个问题：怎么让 AI 出错时能被发现、被兜住。
AI 编码整体框架：三个阶段
项目从 0 到 100，治理手段跟着变：
-
0→1（MVP 阶段）：Vibe Coding，少约束，让模型自由发挥跑出原型。前期最重要的是速度和验证想法。
-
1→10（初期运行）：引入 Spec，把意图、边界、决策沉淀成文档，让 AI 在有约束的上下文里干活。
-
10→100（长期稳定运行）：引入 Harness，把规范变成 AI 绕不过去的物理锁。
| 阶段 | 核心手段 | 约束强度 | 适用场景 | 升级信号 |
|---|---|---|---|---|
| 0→1 | Vibe Coding | 几乎无约束 | 探索、验证想法 | MVP 跑通，要长期运行 |
| 1→10 | Spec | 文档引导，靠 AI 自觉 | 已稳定、需长期运行 | 文档管不住，AI 不听话 |
| 10→100 | Harness | 流程强制，绕不过去 | 复杂项目、关键功能不能错 | --- |
MVP = Minimum Viable Product，最小可行产品。Spec = 规格说明书。Harness = 治理框架/护栏系统。
判断什么时候升级，标准很直接：当文档的引导型限制已经管不住项目了，就该升级。 项目变复杂了，光靠写文档告诉 AI 该怎么做、不该怎么做，AI 开始不听话或者听了也做不对，这时候就需要更强制的手段。反过来，项目还没跑稳就急着上 Harness，只会拖慢反馈，像早期瀑布------Thoughtworks 特别提醒过这一点。
第一部分：MVP 阶段（0→1）Vibe Coding
Vibe Coding：放手让 AI 跑原型
小项目、项目初期、探索阶段，优先 Vibe Coding。别急着堆规则，提前写太多反而限制聪明模型发挥，模型在没约束时往往能给出更贴合的解法。Karpathy（前 Tesla AI 总监、OpenAI 创始成员）造"vibe coding"这个词时，本意就是放手让 AI 跑原型。
但"放手"不等于"放羊"。MVP 阶段有两件事值得在最开头就做，花不了多少时间，但后面省大量返工。
开局第一步：跟 AI 讨论清楚项目因果链
在写第一行代码之前，先跟 AI 把整个项目的因果链聊清楚：
-
为什么要有这个项目？ 解决什么问题，不解决什么问题。
-
项目是什么？ 大概是个什么东西，核心功能有哪些。
-
要达到什么效果？ 用户用完之后应该是什么体验。
-
不做什么？ 哪些功能明确不在这一版范围内。
这些信息不一定要写成正式文档，但一定要在对话里讲清楚，让 AI 建立起项目的整体认知。后面不管 AI 怎么换会话、怎么重新开始，这套因果链都是它的"入职培训材料"。
一句话：spec 不写百科，写因果链。 你可以不懂代码，但要懂业务和约束。把"是什么、为什么、要什么效果、边界在哪、禁止做什么"讲清楚，比写一堆技术细节有用得多。
定义 AI 协同规范
除了项目本身的信息，还有一件事建议在最前期就定下来：你的 Agent 应该以什么方式辅助你工作。
这不是项目规范，是协同规范------定义的不是"这个项目要怎么做"，而是"AI 和人怎么配合做"。比如：
-
遇到不确定的地方，是直接给一个方案还是先问你？
-
改代码之前，要不要先说明改了什么、为什么改？
-
做完一个功能，要不要主动跑一遍测试告诉你结果？
-
哪些操作需要你确认才能执行？
这些东西写在 AGENTS.md 或项目根目录的协同文档里就行。定义清楚之后，AI 的行为风格就稳定了，不用每次开会话都重新教。
MVP 之后的工程化治理：先重构打地基
前期用 Vibe Coding 快速建出 MVP 功能没问题，但当你判断要进入工程化治理阶段了，别在烂摊子上硬补规范。先对项目做一次重构------理清结构、拆好边界、补上测试骨架------地基打稳了，后面的 Spec 和 Harness 才挂得住。在乱码堆上写规范，AI 照样会被带跑偏。
判断是否要进入工程化治理，还有一个维度：这个项目要不要稳定、长期地运行。 一次性脚本、演示 demo，跑通就行；要长期维护、多人协作、面向用户的生产代码，治理的投入才划得来。BCMS 的说法是，成熟的工程师对原型"氛围编程"，对一切要上线的代码"规范驱动"。
第二部分：初期运行（1→10）+ Spec Coding
项目跑起来了，MVP 验证了想法，接下来要让它稳定运行。这个阶段的信号很明确：改 A 错 B、逻辑冲突、改完引发新问题。AI 协作开始拖效率了，就该引入 Spec。Thoughtworks 把 SDD（Spec-Driven Development，规格驱动开发）列为 2025 年最关键工程实践，理由是 AI 让原型太容易，反而让人忽视工程规范，产出一堆不可维护的一次性代码。
上面这张图概括了 Spec 阶段的核心------把意图、上下文、流程三层信息拼成一条清晰路径，让 AI 知道往哪走。
1. 准确表达意图，并把意图文档化
一开始就用语言把意图讲清楚：改了什么、为什么改。意图模糊是 AI 跑偏的根因。行业里把这点推到极致的做法是 "spec 即 prompt" ------写代码前先写规格，代码只是规格的产物（BCMS）。Microsoft 的表述是"先对齐，再让 AI 加速执行"，spec 贯穿整个生命周期。
这里要补一层：意图不只是"要做什么"，还要包括"明确不做什么"和"为什么这么决策"。
-
明确要做的点 和明确不做的点，都写成文字放进项目规范里。不做的边界画不清，AI 就会自作主张往外扩，给你塞一堆你没要的功能。
-
重大决策及原因也要落成文字。比如你做了一个架构选择，可能会影响后续功能走向，就把这个决策和背后的原因写进文档告诉 AI。否则后续迭代时，AI 不理解当时的取舍，很可能"优化"掉你刻意保留的设计。
这一层行业里叫"项目长记忆"------AGENTS.md、知识图谱、ADR（Architecture Decision Record，架构决策记录）都是载体。经验是：知识必须沉淀成版本控制下的文档或代码注释，AI 才能"看见"；口头约定没用（CSDN 实践总结）。
2. 控制上下文
让 AI 能顺着项目结构和框架，快速定位到要改的地方，以及改动可能波及的地方。这对应流程图的第一个判断节点 "位置明确？"：
-
位置明确 → 直接动手改。
-
位置不明确 → 先定位（排查 bug、分析参数），别让 AI 在错的上下文里一本正经地胡说。
落地手段：
-
别把整个仓库喂给 AI。 用
@Files或专门的docs/目录，只给必要的"知识切片"，避免长文本导致注意力弥散。 -
用 MCP（Model Context Protocol，模型上下文协议）消除信息断层。 得物团队 接两个 MCP：一个直连接口文档，一个直读飞书云文档，让 AI 不靠人转述就能拿到真实上下文。
-
AGENTS.md当目录，不当百科。 它只告诉 AI 去哪找更深层信息------架构文档在哪、设计原则在哪、执行计划在哪。大约一百行就够，不是塞满知识（36氪）。 -
spec 本身就是上下文管理工具，让 AI 在"有约束的上下文"里干活，而不是全局自由发挥。
3. 上下文治理：该换会话就换
AI 对这个项目永远是第一天上班。 每次新会话，它都是从零开始。
当一个对话的上下文已经比较混乱，或者特别长、快要触发自动压缩的时候，别硬撑------切换一个新的对话。在新的干净上下文里，通过 Spec（或其他文档）重新告诉它：
-
项目是什么 ------ 当前项目的目标和范围。
-
当前要做什么 ------ 这次的任务是什么。
-
决策规范 ------ 之前做了哪些关键决策，为什么。
-
行为边界 ------ 什么该做，什么不该做。
这就是上面那张图说的------Spec 就是 AI 的入职培训。 每次新会话，拿 Spec 给它做一次干净的 onboarding（入职引导），生成质量会比在一个污染过的长对话里硬聊高得多。
4. 建立固定流程
流程稳定且重复执行的，别每次重发 prompt，而是写 skill / 脚本，让 AI 稳定做同一件事，降低不一致和出错概率。
工业化的版本是 SDD 四阶段循环，每个阶段都有人工检查点：
-
Specify（写什么、为什么）------最慢也最重要，这里花的时间下游 10 倍回报。
-
Plan （怎么做）------产出
plan.md，架构、数据模型、选型。 -
Tasks（按什么顺序）------拆成可独立交付的原子任务，清单要做到"初级工程师能照着执行"。
-
Implement （去做）------agent 逐个任务执行，每个任务结束验收，不达标就在 spec 边界内迭代，不自由跑（BCMS）。
关键在人审每个阶段边界：spec 审过才进 plan，plan 审过才拆任务，任务审过才实现。这就是它"可预测"的来源。GitHub Spec Kit 把这套流程固化成 slash 命令：/constitution、/specify、/clarify、/plan、/tasks、/implement、/checklist，模型无关。
5. 制定规范与验收标准
给 AI 明确编码标准 + 验收标准，别让它自己定义"做完"。
得物团队 落地的是 "约束 + 示范 + 视觉"三层规范体系：
| 层 | 载体 | 作用 |
|---|---|---|
| 约束 | CLAUDE.md |
硬规则，不可违反 |
| 示范 | Rules | 给样板代码，照着写 |
| 视觉 | 视觉稿 | 对齐 UI（用户界面），防走样 |
光说"要规范"没用，得给样板。
验收标准要可执行。BCMS 推荐 EARS 记法 （Easy Approach to Requirements Syntax，需求简易语法），五种句式把模糊需求变成无歧义、可测试的声明，AI 能照着生成代码再生成测试。配合 AI 版 TDD （Test-Driven Development，测试驱动开发）：先让 AI 按 spec 写测试用例，再写业务代码。Microsoft 把验收这步叫 Validate------验证产出是否匹配 spec。
6. 做好最终审查，关键功能上回归测试
最后必须有收尾流程：跑测试 + 人审 AI 产出是否符合需求。人在回路不是可选项，是 SDD 的地基（Thoughtworks）。
审查重点防 AI 的失效模式。得物团队 复盘总结了几类：
| 失效模式 | 表现 | 防御手段 |
|---|---|---|
| 意图偏移 | 代码跑得通但偏离需求 | Spec 明确意图 + 人审 |
| API 幻觉 | 编不存在的接口 | MCP 直连真实文档 |
| 规模化衰变 | 项目一大就失控 | 工程化重构 + Harness |
BCMS 也提醒两个坑：别让 agent 自由运行不设边界，别跳过 clarify 阶段------消歧省的时间比返工省得多。
对于项目里核心、关键、稳定不能出错的内容，单独加一道：每次修改相关功能后，让 AI 跑回归测试。 这不是全量测试，是针对关键路径的专项回归------支付、鉴权、核心数据流这类一出事就致命的功能，每次改动都自动验证没被改坏。这比等最后人工审查才发现问题省太多事。
7. 持续迭代，把规范当活文档
规范、文档、工程化体系不是写一次就完了。在持续迭代过程中，不断优化、沉淀、整理、更新它们：
-
每次发现 AI 反复犯的错，就补一条规则或一个 skill。
-
每次做完一个重大功能，把踩的坑、做的决策回写到规范和 ADR 里。
-
工程化体系（测试、CI（持续集成）、lint、hook）随项目演进持续加固。
规范是活文档，跟代码一起进版本控制、一起迭代。写完就扔的规范等于没有。
Spec 阶段工具
| 工具 | 核心特点 | 适合谁 |
|---|---|---|
| Cursor | Plan Mode + AGENTS.md, inline diff 审 PR 快 |
轻量路线，快速迭代 |
| Claude Code | Plan Mode + claude.md |
已在 Claude 生态里 |
| GitHub Spec Kit | 开源、模型无关、slash 命令全套 | 想跨工具统一流程、不锁厂商 |
| Superpowers | 系列结构化 skill，强制 RED-GREEN-REFACTOR（依靠测试驱动开发 TDD ） | 用 Claude Code，要强工程纪律 |
| OpenSpec | 轻量、框架无关 | 独立开发者 |
Superpowers 是 Jesse Vincent（obra）创建的开源框架，强制"先写失败测试，再写代码，没测试会被框架删掉"。核心一句话------"不让 AI 更聪明，让 AI 更有纪律"（Emelia.io、Marc Nuri、Datawhale）。
第三部分：长期稳定运行（10→100）+ Harness Engineering
什么时候引入 Harness
项目从 1 到 10 的阶段，Spec 能管住大部分问题。但当项目继续长大，复杂度到了一个临界点------仅仅依靠文档的引导型限制，已经没办法让整个项目好好运行了。
信号是这样的：Spec 写了，AI 也读了，但该犯的错还是犯；文档越来越长，AI 却越来越不听话；有些功能出了问题就是灾难性的，光靠"告诉 AI 别搞砸"已经不够了，你需要的是"AI 搞不砸"。
这时候就该引入 Harness。原则是：项目里有一些功能是必须要保证绝对没问题的，就用强制的规范和流程去做，而不是靠 AI 自觉。
什么是 Harness
Phodal 把 AI coding 的控制面画成四层逐层外扩：
| 层级 | 名称 | 管什么 | 约束强度 |
|---|---|---|---|
| 第 1 层 | Rule（规则） | AI 的默认行为 | 最弱，靠自觉 |
| 第 2 层 | Spec（规格） | 单次变更的范围和边界 | 中，文档引导 |
| 第 3 层 | Loop（循环） | 动态执行机制 | 较强，流程约束 |
| 第 4 层 | Harness（治理） | 组织级治理 | 最强，物理锁 |
Harness 是最外层，把前面三层汇总进可执行的治理。一句话定义它：Harness 回答的不是"AI 多强"，而是"这次变更为什么足够可信"。
它被叫作 AI 编程的"治理操作系统"和"护栏系统"------通过"规则即代码"和自动化反馈，把 AI 的创造力圈在可信边界内（CSDN）。
核心机制
光有规范是"软约束"，Harness 把它变成"硬执行"：
| Spec（软约束） | Harness（硬执行） | |
|---|---|---|
| 约束方式 | 文档引导，靠 AI 自觉 | 流程和工具强制，绕不过去 |
| AI 能否忽略 | 能 | 不能 |
| 典型手段 | AGENTS.md、规范文档、ADR |
CI、pre-commit hook、agent 职责隔离 |
| 适用阶段 | 1→10 | 10→100 |
具体机制有这几条：
-
生成器-评估器循环。 AI 写代码 → 另一个 AI（或校验器）审查 → 不通过打回重写 → 直到通过。传统 code review 是人审人，Harness 里变成 agent 审 agent（腾讯云、菜鸟教程）。
-
CI 作为 Harness。 Carlini 的实战复盘 里，Claude 在项目后期频繁破坏现有功能，解法不是换更强的模型，而是更严格的 CI------"用 harness 层的方案解模型层的问题"。lint、typecheck、tests、pre-commit 这些检查前移到 hook 里，违反就过不了（Phodal）。
-
职责隔离。 负责调研的 agent 只能读不能写，负责规划的不能碰文件只能出方案，负责编码的只管写，负责验证的只管查。每个角色的工具权限出厂就定死（36氪、AI 小圈）。
-
自动化验证回路。 AI 编写 → 自动测试 → 自动分析日志/监控 → 自动修复，人只在关键决策点介入（CSDN）。
-
防"虚标完成"。 用 JSON 结构追踪 feature 状态（机器可读，AI 不易乱改），干活 agent 只能标"通过/不通过"，必须真测过才能标 passing。Markdown 只当路标，不当严格流程（36氪）。
为什么这层不可省
前面三层（Rule/Spec/Loop）没建起来，Harness 最多在末端捡垃圾；前面三层立住了，Harness 才有组织级治理意义（Phodal）。它不是替换规范，是把规范变成 AI 绕不过去的物理锁。OpenAI 总结 Codex 长任务经验时也点明：长任务更可靠，不靠更长的 prompt，而靠 harness 提供的结构化上下文和清晰的"done when"例程。
Harness 阶段工具
这层工具 2026 年初才成型。"harness engineering" 这个词普遍归因于 Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 创造者）2026 年 2 月的博客，LangChain 随后把它形式化为一个公式："Agent = Model + Harness"------决定 AI 靠不靠谱的，不是模型多强，是你套在外面的那层壳（Augment Code）。
| 工具 | 核心特点 | 适合谁 |
|---|---|---|
| Claude Agent SDK | Claude Code 背后的 harness，自动压缩长会话；原生 hooks（PreToolUse 拦截危险操作、PostToolUse 跑 lint/test、Stop 防虚标完成）把规则从"靠 AI 自觉"变"绕不过去的强制执行"（官方文档） | 在产品里嵌 agent |
| Codex CLI | 开源终端 agent，长任务可靠 | OpenAI 生态、CLI 工作流 |
| LangGraph + Deep Agents | 有状态编排 + 子 agent 委派 | 多 agent 管线 |
| Composio | 250+ SaaS API 封装成 agent action | 对接大量外部服务 |
| CI/CD | lint/typecheck/tests 前移到 hook | 所有项目都该有 |
CI 是性价比最高的 harness。Carlini 的实战复盘 证明：模型后期频繁搞坏功能，解法不是换更强模型，是把 CI 拧紧。
总结：从哪开始
一句话概括全文：AI 一定会出错，你的工作不是消灭错误，是让错误在发生时能被发现、被兜住。
三个阶段，三套手段，按项目成熟度递进：
-
0→1 ：Vibe Coding，少约束，跑通原型。唯一要提前做的是跟 AI 讲清楚项目因果链------是什么、为什么、要什么效果、不做什么。不用着急挑工具，用你手边最顺手的 IDE，把精力放在跟 AI 讨论清楚项目因果链上。堆工具是在给自己找活干。
-
1→10 ：引入 Spec，把意图、上下文、流程固化成文档，让 AI 在有约束的轨道里干活 。Spec 工具选的是"怎么写清楚"。想跨工具不锁厂商选 GitHub Spec Kit；用 Claude Code 且要强纪律选 Superpowers；独立开发者轻量起步选 OpenSpec；已在某个 IDE 深耕就用原生 Plan Mode +
AGENTS.md。先试水的话，挑一个这周要上的小功能，花 30 分钟写成带 EARS 验收标准的 spec，跑一遍对比平时 vibe coding 的结果，差距自己就出来了（BCMS）。 -
10→100 ：叠一层 Harness，**把规范变成 AI 绕不过去的物理锁。**Spec 工具继续用，上面叠一层 Harness。Harness 选的是"怎么锁"------已有 CI 就先把 lint/typecheck/tests/pre-commit 拧紧（零成本第一步）；要嵌 agent 选 Claude Agent SDK 或 Codex CLI；多 agent 管线选 LangGraph + Deep Agents；要对接大量外部 API 选 Composio。别一上来搭全套，哪疼治哪（Faros.ai）。
升级信号很简单：当前手段管不住 AI 了，就升级。 别提前堆，也别拖着不升。
总之，先判断，再执行。 面对复杂项目，别让 AI 直接上手写代码，先做任务路由------判断这是简单修改，还是要走 spec + harness 的固定流程。判断对了，后面事半功倍。
参考阅读
本文编写时参考的资料：