11
6
08｜一套可复制的 AI Coding 流程：从需求到提交怎么走
2026-10-12 11:23:53
0点赞
1收藏
0评论
本篇是《从头重新学 AI 编程》系列第 8 篇。这篇作为中场总结篇，主要是教大家怎么把之前学会的东西在整个流程里串起来。
到这一篇，前面七篇我们各自聊了一个独立的能力。
角色转变、写 Spec、写 AGENTS.md、冷启动旧项目、上下文管理、MCP、Subagent。
你现在大概知道了怎么给 AI 划边界，怎么把需求写清楚，怎么让它一进项目就了解背景，怎么在它变笨之前换会话，怎么给它接外部工具，怎么把活分出去。
但我得坦率的讲一句，这些东西单独拿出来用，威力是有限的。
就好比你健身，练了胸、练了背、练了腿，每块肌肉都还行，但你上场打球的时候，真正决定你表现的不是某一块肌肉有多强，而是这些肌肉能不能协调地配合成一个动作。
代码也是一样。
前七篇是七个零件。这一篇，我想把它们拼成一台能跑的机器。
我自己现在的 Vibe Coding 工作流，跑下来差不多是八步。我先一口气过一遍，你心里有个整体的形状，后面我再用一个真实功能跑给你看。
第一步，写 Spec，或者确认 Spec。
这个第 2 篇讲透了。在让 AI 动手之前，先把意图、约束、验收标准写清楚。如果是你自己发起的功能，你来写。如果是别人甩给你的需求，你先确认这份 Spec 清不清楚，不清楚的地方先问明白再说。
这一步要是跳了，后面全是白费功夫。
第二步，让 Agent 先出计划。
拿到 Spec，别急着让它写代码。先让它说说打算怎么干。
读一下 specs/csv-export.md。先不要写代码，
告诉我你打算怎么实现，分几步，改哪些文件，
有没有你看到的问题或风险。
它会给你一个方案。你看看它理解得对不对，有没有漏掉什么，有没有过度设计，搞了一堆你根本不需要的东西。
第三步，人工确认计划。
这一步是你把关最关键的地方。
AI 出的计划可能选了一个你不想要的方案，可能漏了某个约束，可能把一件简单的事想复杂了。你在这一步拦住它，成本最低。等它哗哗哗写完一大堆代码你才发现方向不对，那回滚的成本就高了。
怎么确认？很简单，看它的计划有没有覆盖 Spec 里所有的验收标准，有没有踩到 AGENTS.md 里的红线。
第四步，让 Agent 小步实现。
计划确认了，开始写。但别让它一口气全写完，让它小步走。
先实现 CSV 导出的核心逻辑，不要动 UI 部分。写完告诉我。
每完成一小块你检查一次。这比让它一口气写完整个功能再回头看，风险小太多了。
第五步，看 diff。
AI 说「写完了」不算数。你自己看 diff。
先让它列一下改了哪些文件、每个文件改了什么，然后你自己 git diff 再过一遍。重点看三样，有没有改不该改的文件，有没有偷偷引入新依赖，逻辑跟 Spec 对不对得上。
这一点第 1 篇就反复强调过，解释得通不等于跑得通。
第六步，跑测试。
跑一下测试，告诉我结果。
AI 说「应该没问题」不算数，测试跑过了才算数。有 lint 的话也一起跑。这一步是验证的底线，测试过了，你才敢有那么一点信心。
第七步，更新文档。
如果这次改动碰到了 AGENTS.md 里的内容，比如加了新目录、改了命令、踩了个新坑，这一步顺手更新掉。
这次改动有没有需要更新到 AGENTS.md 的地方？
AGENTS.md 是活的，这话我在第 3 篇说过，每次改动都该让它保持最新。
第八步，提交。
确认没问题，提交。
commit message 写清楚这次改了什么、为什么改。
不要写 fix bug 这种废话。
好，八步过完了。
你可能已经看出来了，这八步根本不是我凭空编的，每一步背后都是前面讲过的某个能力。
写 Spec，是第 2 篇的意图加约束加验收标准。让 Agent 出计划、人工确认，是第 1 篇讲的先说计划再动手、审查引导修正。小步实现，是第 5 篇按任务拆上下文的思路。看 diff，还是第 1 篇，看 diff 而不是看总结。更新文档，是第 3 篇 AGENTS.md 是活的。最后提交能放心，是因为第 4 篇讲过你手里得有个能回退的基线。
至于跑测试这一步，第 11 篇我会专门展开讲，怎么搭护栏让 AI 没法蒙混过关。
所以你看，前七篇是零件，这八步是把零件组装成机器。一个功能从需求走到提交，每一步都有地方落脚，不是凭感觉瞎撞。
聊到这我想插一个很多人会忽略的小问题，它其实贯穿这整套流程。
你跟 AI 对话的时候，有些话应该写在 AGENTS.md 里每次自动加载，有些话应该写在当前对话里每次手动说。这两种话到底怎么分？
我自己的分法是这样的。
写在 AGENTS.md 里的，是项目规则。就是第 3 篇你写的那些东西，项目简介、目录结构、常用命令、编码规范、红线。这些信息每次会话都用得上，写一次，AI 启动自动读，你不用反复念。
比如这种，
这是一个待办事项应用，前端 React + TypeScript，
后端 Node.js + Express，数据库 SQLite。
不引入新依赖，不改 migration，所有 API 变更必须有测试。
写在对话里的，是这次具体要干什么。这部分不需要重复项目背景，因为 AGENTS.md 已经替你交代过了。
比如这种，
基于现有待办列表组件，增加 CSV 导出功能。
Spec 见 specs/csv-export.md。
你看，这句话很短。它短是因为它不用解释项目是什么、用什么技术栈、有什么规矩，那些全在 AGENTS.md 里待着呢。
判断标准也特别简单，如果你发现自己每次对话都在重复同一段话，那这段话就该挪进 AGENTS.md。
说了这么多步骤和原则，我直接用我们这个待办事项应用，把整套流程完整跑一遍给你看。
需求很简单，给待办列表加一个 CSV 导出功能。
第一步，写 Spec。
# CSV 导出功能
## 目标
在待办列表上方增加导出 CSV 按钮，点击后下载当前筛选后的数据。
## 约束
- 不改后端接口，前端处理
- 不引入新依赖
- 文件名包含日期
## 验收标准
- [ ] 列表上方显示导出按钮
- [ ] 点击后下载 CSV 文件
- [ ] 导出的是当前筛选后的数据
- [ ] 文件名格式 todos-2026-06-27.csv
第二步，让它出计划。
读 specs/csv-export.md。先不要写代码，告诉我你打算怎么实现。
它回我，在 TodoList 组件里加一个按钮，点击的时候把当前列表数据转成 CSV 格式，用 Blob 生成下载链接触发下载，文件名用 todos 加日期。不改后端，不引入新依赖。
第三步，确认计划。我看了一眼，方案没问题，继续。
第四步，小步实现，先让它写核心的导出逻辑，UI 先不动。
第五步，看 diff，确认它只改了该改的那几个文件。
第六步，跑测试，过了。
第七步，问它要不要更新 AGENTS.md，这次没动到项目级的东西，不用更新。
第八步，提交。
八步走完，一个功能从一句话需求到一次干净的提交，全程每一步你都知道自己在哪、下一步去哪。
这就是我说的可复制。可复制的意思不是说每次结果都一样，而是说不管这次做的是导出功能还是别的什么，这套流程的骨架是不变的。你不用每次都重新发明一遍工作方式。
我自己最大的感受是，有了这套固定流程之后，用 AI 写代码这件事，从「碰运气」变成了「有手感」。
以前是聊一轮看一眼，觉得不对再聊一轮，整个过程像在赌。现在是每一步都有一个明确的检查点，错了就在那个点上拦下来，不会让错误一路滚到最后。
给你一个小练习。
下次你用 AI 做一个功能，别凭感觉聊，试着照这八步走一遍。哪怕功能很小，也完整走一遍，写 Spec、出计划、确认、小步实现、看 diff、跑测试、更新文档、提交。走完你会发现，慢的是前面那几步，但后面省下来的返工时间，远比前面多。
到这里，这个系列的上半场就结束了。你手里已经有了一套完整能跑的工作流。
后面几篇会在这个基础上，聊一些更进阶的玩法，怎么让多个 Agent 并行干活互不打架，怎么把你反复说的话固化成自己的工具，怎么搭测试和 CI 的护栏，以及哪些坑是真的能把项目搞崩的。
下一篇，我们聊 Git worktree，怎么让多个 Agent 同时写代码，但谁也不污染谁。
作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～
