Agentic Coding 的最小工作流

核心概念

Agentic Coding 不是“让 AI 一直写”。它是一个闭环：明确目标，限制范围，执行改动，用客观信号验证，再把经验写回项目规则。

最小工作流只有四步：

Plan -> Patch -> Verify -> Learn

这四步缺一不可。只做 Patch，AI 会变成一个不可控的改文件机器；只做 Plan，不跑验证，就只是聊天。

适合什么任务

这个工作流适合 1-3 小时内可以验收的小任务：

给网页增加一个组件或页面区块。
修一个明确的构建错误。
把一组文档迁移到新目录。
给脚本补错误处理。
把重复操作沉淀成项目规则或 Skill。

不适合一上来就做“重构整个系统”“重新设计全部架构”“把所有内容都优化一下”。这些需求要先拆成多个小切片。

操作步骤

计划：写清楚要改哪些文件、不能改什么、如何验收。
改动：一次只做一个可审查的切片。
验证：优先跑最快相关检查，再跑完整构建。
复盘：把失败原因写入 README、AGENTS 或 Skill。

第一步：Plan

计划不是长篇方案，而是把风险提前说清楚。一个合格计划应该包含：

目标：这次到底要改变什么用户可见行为。
文件范围：预计会读哪些文件、改哪些文件。
禁区：哪些文件、配置、账号、密钥不能碰。
验收：用什么命令、页面或人工检查确认完成。
回滚：如果失败，怎么知道改动可以安全撤回。

可复制模板：

请先不要改文件。先给我一个计划：

- 你会读哪些文件？
- 你预计改哪些文件？
- 这次最小可交付结果是什么？
- 不能改哪些内容？
- 需要跑哪些验收命令？

计划控制在 3-6 条。

第二步：Patch

执行阶段要限制切片大小。一个实用标准是：你能在 5 分钟内看懂这次 git diff。

如果 diff 已经大到你不想看，说明任务切得太大。此时应该让 AI 停下来总结当前改动，而不是继续往前堆。

推荐约束：

现在只做第一个切片。保持改动小，不做顺手重构。
改完后请列出：
1. 改了哪些文件。
2. 每个文件为什么要改。
3. 下一步应该跑什么检查。

第三步：Verify

验证要优先使用客观信号，而不是问 AI “你完成了吗”。常见验证顺序：

语法检查或类型检查。
单元测试或相关测试。
构建命令。
本地页面预览。
人工检查关键页面或 diff。

前端项目常见命令：

npm run build
npm run lint
npm test

并不是每个项目都有这些命令。真正的规则是：先看 package.json、README、CI 配置，再决定跑什么。

第四步：Learn

复盘是 Agentic Coding 和普通聊天最大的区别。你要把一次失败变成下一次的规则。

复盘可以写进三个地方：

项目规则：AGENTS.md、CLAUDE.md、README。
知识库：Obsidian 项目笔记。
Skill：当流程重复出现时，写成可复用能力。

复盘模板：

## 本次失败
发生了什么？

## 根因
是需求不清、上下文缺失、命令没跑，还是权限过大？

## 下次规则
一句能改变下一次行为的规则是什么？

常见错误

没有计划就开始大规模重构。
把测试失败解释成“小问题”，没有追到具体文件。
只问模型“是否完成”，不跑真实命令。
让 AI 同时处理设计、数据、部署、文案，导致无法定位问题。
复盘只写感受，不写可执行规则。

实战案例

给文档站加组件时，先只实现 SourceCard 和 VideoCard，跑一次构建，再继续填内容。这样能更早发现 MDX 或 Astro 语法问题。

更完整的切片可以这样拆：

切片	目标	验收
1	新增组件文件	构建通过，页面能引用
2	替换一篇教程里的来源说明	MDX 不报错，页面显示正常
3	批量迁移剩余教程	搜索旧写法，构建通过
4	更新 README 和 PR 说明	新人能知道怎么预览

这个拆法的好处是：任何一步失败，都能快速知道问题在哪个层级。

最小验收清单

每次结束前问自己：

我有没有看过 git diff？
我有没有跑过至少一个真实检查？
我能不能解释这次改动为什么必要？
如果明天继续做，我知道下一步是什么吗？