Agentic Coding 的最小工作流：把一次任务跑成 Plan → Patch → Verify → Learn 闭环

难度	阅读时间	最后验证	作者
入门	13 分钟	2026-07-11	LearnPrompt 编辑部

你给编码 Agent 一句「帮我把这个函数做好」，十分钟后它改了一版，说已经完成。你运行起来，坏的。你回头看聊天记录，既不知道它当时打算怎么改，也没有任何客观信号证明哪一步出的错，更糟的是下次做同类任务，同一个坑还会原样再踩一遍。

同一个模型，给它一个切好片、能跑验收的小任务就稳，一把梭就反复翻车。差别通常不在模型聪不聪明，而在你有没有把「一次任务」当成一个有产出、有信号、有回写的闭环来跑。本文给你这样一个最小闭环，并在一个能复现的真实小任务上跑给你看。

读完你能做什么

1. 用四步跑完一次真实小改动：写计划、切一个可读 diff、跑最快检查、把教训写回项目规则。
2. 说清每一步锚定哪项一手能力，以及缺这一步会退化成什么样。
3. 判断这套循环适合什么任务，什么时候不该硬套。

图注：四步不是四个口号。每一步都有一个产出并提供一道对应护栏；省略某一步就会失去那道护栏，是否值得取决于任务风险。

这是 LearnPrompt 的操作模型，不是行业标准

Plan → Patch → Verify → Learn 是我们为了教学归纳的操作节奏，没有任何厂商或标准组织把它定为官方流程。它站得住脚，是因为四步各自对应一项真实存在的一手能力（见下文）。请把它当成一副好用的脚手架，而不是一条必须照搬的规范。

四步各自锚定什么

四个词本身不值钱，值钱的是每一步背后那个客观锚点。把锚点讲清楚，你才知道每一步到底在防什么。

Plan：先只读，把错误挡在落盘之前

计划的作用是把「决定改什么」和「动手改」分开，让方向性错误在最便宜的时候被发现。这不是我们发明的礼仪，而是产品级能力：Claude Code 有 plan mode，Claude 只读文件、提出计划，你批准之前它不落盘（claude --permission-mode plan，或会话里 Shift+Tab 切换）。

一个合格计划不是长篇方案，而是四条护栏：

• 目标：这次要改变什么可见行为。
• 文件范围与禁区：预计改哪些文件，哪些绝对不碰。
• 最快检查：用哪一条命令确认完成。
• 回滚：失败了怎么安全退回。

Patch：一次改动只承载一个决定

「切片小」不是审美，而是可审查性的前提。一个实用判据：你能在五分钟内读完这次 git diff。git diff 是逐行差异，人一次只能可靠地审查有限的变化；一旦一次 diff 里既改了实现、又顺手重构、还动了别的文件，审查就退化成「看起来没问题」。

所以规则很硬：一次 patch 只承载一个决定。如果 diff 已经大到你不想看，说明任务切得太大，应该让 Agent 停下来总结，而不是继续往前堆。

Verify：用退出码，而不是模型自述

验证的核心不是问「你完成了吗」，而是跑一条最快的相关检查看退出码。AGENTS.md 这个被 6 万多个项目采用的开放格式说得直接：你把程序化检查写进去，Agent 会尝试执行并在完成前修复失败。关键在「可执行」——命令能真正运行并产出退出码，形容词不能。

常见的检查顺序（不是每个项目都全有，先看 package.json、README、CI 再决定跑什么）：

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

Learn：把教训写回持久指令

复盘是 Agentic Coding 和普通聊天最大的区别。Claude Code 有两条跨会话路径：你主动维护的 CLAUDE.md 等持久指令，以及 Claude 根据用户纠正自动记录的 auto memory。本文的 Learn 专门采用第一条，因为显式规则可以进入版本控制、接受审查并留下 before/after 证据；聊天里没有被明确沉淀的经验，不能假定下次一定会出现。

所以复盘的动作很具体：把一次失败提炼成一条能改变下次行为的规则，写回 AGENTS.md、CLAUDE.md 或 README。写「Run npm test before committing」这种可验证的规则，比写「注意质量」有用得多。

写回是上下文层，不是强制层

把「不要碰 .env」写进 CLAUDE.md 只是提醒。要让它变成硬边界，得靠 PreToolUse hook、权限 deny 规则或沙箱。复盘负责让下次少犯错，真正不可逆的动作仍要在循环之外叠加人工审批与工具强制。

按风险缩放，别每次都上满

四步是节奏，不是仪式。按任务的风险和不可逆性缩放：

任务类型	Plan	Patch	Verify	Learn
改一行文案、试个想法就删	一句话	一片	可省	可省
给页面加一个组件	四条护栏	逐片	必跑最快检查	视情况
反复出现或高风险的改动	完整	逐片	必跑，且看退出码	必写回规则

低风险时省掉 Verify 和 Learn 无所谓；高风险或反复踩的任务，这两步恰恰最不能省。

Showcase：在一个最小受控任务上跑完整四步

下面不是提示词展示，而是一次真实运行。任务是一个纯本地、无第三方依赖、结果确定的函数 splitEvenly(totalCents, people)：把账单按人数拆成整数分，要求各份之和严格等于总额。它有一个天然边界——简单取整可能丢分或多分，所以 Verify 能抓到一个可打印的真实失败。完整可复现材料在文末来源区链接的研究包里。

第一步 Plan：四条护栏

# 计划（Plan）
- 目标：实现 splitEvenly，使 node --test 全绿。
- 文件范围：只改 split-bill.mjs。
- 禁区：不改 split-bill.test.mjs（验收标准），不动 AGENTS.md 的检查命令。
- 最快检查：node --test
- 回滚：未提交前用 git restore split-bill.mjs 退回。

第二步 Patch·切片一：只做均分这一个决定

故意先不处理余数，让下一步的验收去暴露缺口，而不是在同一次改动里既均分又补余数，把两个决定糊在一起。这一片的 diff 只有几行：

// TODO: 待实现
return [];
// 切片一：先做最直观的均分（四舍五入到分）。
const each = Math.round(totalCents / people);
return Array(people).fill(each);

第三步 Verify：退出码给出事实

跑最快检查 node --test。它没有问我们感觉如何，而是直接失败并打印原因：

✔ 整除时人人相等
✖ 最快检查：任何拆分结果之和必须严格等于总额（守恒）
  AssertionError: sum(3333,3333,3333) 应为 10000，实际 9999
ℹ pass 2
ℹ fail 1
# 退出码：1

10000 / 3 每人四舍五入成 3333，三份加起来是 9999，凭空丢了一分。这不是模型的自我评价，是环境给的事实。退出码 1 把「完成」变成了可判定的。

第四步 Learn：把教训写回 AGENTS.md

这个坑值得记下来，否则下次拆分金额还会踩。把它写成一条能改变下次行为的规则，追加到项目的 AGENTS.md：

 ## 代码风格
 - 金额一律用整数分，避免浮点误差。

## 复盘规则（写回，2026-07-11）
+- 金额拆分类任务，先写“求和守恒”断言（parts 之和严格等于总额）再写实现；
  四舍五入或向下取整都会漏掉余数，必须把余数逐分补回。
+- 切片顺序：切片一只做均分并用守恒断言暴露余数缺口，切片二单独补余数。

有了这条规则，切片二就照着补余数（向下取整做基数，把余数逐分补给前几人），再跑一次最快检查：

✔ 整除时人人相等
✔ 最快检查：任何拆分结果之和必须严格等于总额（守恒）
✔ 相邻两人差额不超过 1 分
ℹ pass 3
# 退出码：0

退出码从 1 变成 0，闭环合上。注意 Learn 写回的规则是这次任务的经验，不是通用定律；它的价值在于下次同类任务开工时，会作为上下文被读到。

什么时候不要硬套这套循环

• 一次性、零风险的小实验：写四步的成本可能高于收益，跑完就删的东西不必立规矩。
• 连「成功是什么」都写不出来：这时先补任务定义，而不是硬跑循环。验收都定义不了，Verify 无从谈起。
• 循环只保证有护栏、有信号、有回写，不保证内容正确：Verify 的检查本身写错，照样放过坏结果。
• 不可逆的高风险动作（发布、删云数据、发消息）：必须在循环之外叠加人工审批与工具强制，提示词末尾一句「请小心」不算边界。

可复制的四步提示词

把下面这段交给任一编码 Agent，先不允许它立刻改文件：

先不要改文件。第一步只给我计划：
- 你会读哪些文件？预计改哪些？这次最小可交付切片是什么？
- 哪些文件、配置、密钥不能碰？
- 用哪一条最快命令验收？失败了怎么回滚？

我批准后，第二步只做第一个切片，保持改动小、不做顺手重构，改完列出：改了哪些文件、每处为什么、下一步该跑什么检查。
第三步跑那条最快检查，把真实输出和退出码给我，不要用「应该没问题」代替。
第四步如果这次踩了坑，写一条能改变下次行为的规则，追加到 AGENTS.md 或 CLAUDE.md。

常见反模式

• 没有计划就开始大规模重构，方向错了才发现。
• 一次 diff 藏了好几个决定，审查只能盲信。
• 只问模型「是否完成」，不跑任何真实命令。
• 让一个 Agent 同时处理设计、数据、部署、文案，出问题无法定位。
• 复盘只写感受，不写一条可执行、可被下次读到的规则。

练习：在你自己的仓库跑一遍

选一个你手上真实的小任务（加一个组件、修一个明确的构建错误、给脚本补错误处理），用四步跑完，并留下可核对的痕迹：

Plan：贴出你的四条护栏（目标 / 范围与禁区 / 最快检查 / 回滚）。
Patch：贴出第一个切片的 git diff，确认能在五分钟内读完。
Verify：贴出最快检查的真实输出和退出码，而不是「跑过了」。
Learn：如果踩了坑，贴出你写回 AGENTS.md 或 CLAUDE.md 的那一条规则。

完成标准是客观的：四段里每一段都有可核对的证据（diff、退出码、写回的 diff），而不是一句「我做完了」。如果 Verify 那段你贴不出退出码，说明你其实还没验证。

最小验收清单

每次结束前问自己：

• 我有没有先出计划、再动手？
• 这次 git diff 我能在五分钟内读完吗？
• 我有没有跑过至少一个真实检查、看过退出码？
• 这次的教训，我有没有写回一条下次会被读到的规则？

来源与延伸阅读

• Claude Code common workflows（plan mode）
• Claude Code memory（CLAUDE.md 是上下文非强制配置）
• AGENTS.md 开放格式（可执行程序化检查）
• git diff 手册
• git revert 手册
• Harness Engineering 橙皮书
• 本文研究包与可运行 Showcase

上述 Claude Code、AGENTS.md 与 git 文档是支撑当前产品行为与命令的一手官方资料，均于 2026-07-11 核对。Harness Engineering 橙皮书在此仅作中文二手主题地图：该仓库声明教育性分享需署名、未采用标准开放许可，因此本文只保留其链接与署名说明，不复制或改编其任何图片；Plan → Patch → Verify → Learn 的结构、论证与 Showcase 均由 LearnPrompt 重新组织并复核。文中教学图为 LearnPrompt 编辑部原创，采用 CC BY-NC-SA 4.0。