Coding Agent 标准工作流 SOP：从需求到交付的六步法
最后更新：2026-09-01
架构看 我们的技术栈，提问写法看 Prompt 方法论。本篇是操作手册：不管你用 Cline、Roo-Code、OpenCode 还是 Claude Code，照着这六步走，就能把"让 AI 改代码"从碰运气变成稳定产出。
很多人用 Agent 效果差，不是模型不行，而是流程错了：一上来就说"帮我重构一下"，不开 Plan、不看 diff、不跑测试，最后在一堆 AI 改的代码里救火。这套 SOP 就是把高手的习惯固化成六个步骤。
一、六步法总览
| 步骤 | 你做什么 | 常见错误 |
|---|---|---|
| 0 准备 | 提交/stash 当前工作区，确认规则文件就位 | 不留快照，改坏了回不去 |
| 1 下任务 | 说清做什么、在哪、约束 | "优化一下"这种模糊指令 |
| 2 计划 | 切 Plan/Architect 模式，先审方案 | 直接让它开干 |
| 3 执行 | 小步走，逐条审批 | 开自动批准，放任批量改 |
| 4 观察 | 盯输出，发散就打断 | 不管它，跑十几轮烧额度 |
| 5 验收 | 编译 + 测试 + 通读 diff | 信它说的"已完成" |
| 6 沉淀 | 把规则/坑写回项目 | 同一个坑反复踩 |
二、第 0 步：动手前准备（30 秒，省两小时）
在让 Agent 改任何代码之前，做三件事：
- 打 git 快照：当前工作区先
git commit或git stash。Agent 改坏了git reset --hard一键回滚，这是最便宜的保险； - 确认 CLAUDE.md / 规则文件就位：技术栈版本、构建命令、测试命令、项目禁忌是否写清。没有就先补，Agent 才不会瞎猜命令（怎么写见 CLAUDE.md 指南）；
- 选对客户端和模式：高风险大改动用 Cline（逐步审批）；要并行探索用 Roo-Code；终端批量任务用 Claude Code
-p。
大项目额外建议：挂好 CodeGraph，Agent 定位符号从"grep 碰运气"变成"查图谱直达"，能显著减少无效读文件的循环。
三、第 1 步：用三要素下任务
一条合格的任务指令必须包含三要素（详见 Prompt 方法论）：
| 要素 | 含义 | 好例子 | 坏例子 |
|---|---|---|---|
| What | 要做什么 | "给 calc_cpu_usage() 加缓存，避免每 200ms 读一次 /proc" | "优化一下 CPU 计算" |
| Where | 在哪做 | 指明文件/函数，或用 @file、@folder 贴进来 | "在我项目里" |
| Constraint | 约束 | "保持现有接口不变，缓存 TTL 用 5 秒" | 什么都不说 |
配合两个习惯：
- 主动指路：用
@file/@folder把相关代码喂给它，别让它在大库里漫无目的地 grep（既省 token 又少幻觉）； - 任务拆到中等粒度：一个任务最好能在几步到二十几步内完成。"重构整个认证模块"太大，先拆成"梳理现有认证调用链"→"抽离 token 校验"→"补测试"。
四、第 2 步：先 Plan，后 Act
这是新手和高手最大的区别。 不要一上来就让它改代码：
- 切到 Plan 模式（Roo-Code 的 Architect 模式、Claude Code 的 plan mode、Cline 也可先让它"只分析不改"）；
- 让它先输出：要改哪些文件、分几步、怎么验证；
- 你审一遍方案：文件范围对不对、有没有漏、思路有没有跑偏，确认后再切执行模式。
先 Plan 的好处：把错误拦在"还没动代码"的阶段。方案错了改一句话，代码改了再回滚是十分钟。
五、第 3–4 步：小步执行 + 持续观察
进入执行阶段，守住两条：
- 逐条审批，不开放自动：每次文件改动看 diff（是不是只改了该改的）、每条命令确认（尤其
rm、git push、安装包）。生产环境永远不要开 terminal 自动批准； - 盯循环，发散就打断：Agent 陷入反复改同一处、或连续报错绕不出来时，立即中断，用一句话纠偏（"别再动 X 文件，问题在 Y"），而不是让它空烧几十轮额度。
六、第 5 步：验收——别信"已完成"
Agent 说"任务完成"不等于真的完成。必须自己过三件事：
- 编译 / 构建通过：让它跑构建，你亲自确认无 error；
- 测试通过：跑单元测试 / 回归。没有测试的改动，至少手动验证关键路径；
- 通读 diff：
git diff从头到尾看一遍，揪出它夹带的"顺手改动"、误删的注释、写死的调试代码。
Agent 会幻觉——编造不存在的文件路径、函数名，或"自信地"调用一个没有的接口。测试是唯一的事实来源。
七、第 6 步：沉淀——让下一次更快
任务做完，把过程中暴露的问题固化下来：
- Agent 搞错了项目约定？→ 写进 CLAUDE.md / 规则文件；
- 某类任务有固定打法（如"每次发版前的检查清单"）？→ 做成 Skill 或子 Agent（见 Agent vs Skill）；
- 反复要用的外部能力？→ 封装成 MCP Server（见 MCP 协议）。
沉淀一次，整个团队之后所有 Agent 会话都受益——这是把"个人技巧"变成"团队资产"的关键动作。
八、四类任务的不同打法
六步是通用骨架，不同任务类型侧重点不同：
| 任务类型 | 推荐客户端/模式 | 打法要点 |
|---|---|---|
| 写新功能 | Cline / Roo-Code | 先让它 Plan 出接口与文件结构；新代码容错高，可适当放快步子 |
| 重构跨文件 | Roo-Code（子 Agent 并行梳理）+ CodeGraph | 最需要先 Plan；小步重构、每步编译，绝不一刀切大改 |
| 调试 / 修 bug | Cline（逐步可控） | 先让它"只定位不改"，复现→假设→验证；改动范围锁死在根因附近 |
| 写文档 / 读代码 | Ask / Plan 模式 | 用只读模式，避免它顺手改代码；大库探索挂 CodeGraph |
重构和调试是 Agent 最容易"帮倒忙"的两类：重构容易过度改动，调试容易改错地方。对策都是缩小授权范围 + 小步验证。
九、高频翻车点对照表
| 现象 | 根因 | 对策 |
|---|---|---|
| 改了一堆文件，越改越乱 | 任务粒度太大、没先 Plan | 回滚快照，拆小任务，先出计划 |
| 反复改同一处 / 死循环 | 上下文里错误信息误导，发散了 | 立即中断，一句话指出正确方向 |
| 调了不存在的函数 / 编不过 | 幻觉 | 强制编译 + 测试，用 @file 提供真实定义 |
| 套餐额度掉得飞快 | 循环轮次太多、无效 grep | 挂 CodeGraph、主动指路、任务拆小 |
| 夹带无关改动 / 删注释 | 长任务里 Agent"顺手"发挥 | 验收时通读 git diff，逐条审批 |
| 误删文件 / 跑了危险命令 | 开了自动批准 | 关闭自动审批；动手前必有 git 快照 |
十、一页纸检查清单
每次派任务前 / 中 / 后过一遍：
- [ ] 前：工作区已 commit/stash，有回滚点
- [ ] 前：CLAUDE.md 写清了命令、版本、禁忌
- [ ] 前：任务含 What / Where / Constraint，粒度适中
- [ ] 中：先出 Plan 并经你确认
- [ ] 中：自动批准关闭，diff / 命令逐条确认
- [ ] 中：发散即中断纠偏
- [ ] 后：编译通过
- [ ] 后：测试通过（或手动验证关键路径）
- [ ] 后：通读
git diff，无夹带改动 - [ ] 后：踩坑沉淀回 CLAUDE.md / Skill
相关文档
| 文档 | 内容 |
|---|---|
| 我们的技术栈与系统架构 | 这套系统四层分别用什么（本文的架构背景） |
| Coding Agent 工作原理 | 为什么会有 Plan-Act 循环、审批这些机制 |
| Prompt 方法论 | 三要素框架与场景化提问技巧 |
| VSCode 三剑客实战手册 | Cline/Roo-Code/OpenCode 的具体操作与模式 |
| Claude Code 教程 | CLI 的命令、快捷键、plan/-p 模式 |
| 接入指南 | 客户端怎么连上 Coding-Plan |
一句话总结
用 Coding Agent 的标准姿势是六步：先打 git 快照 → 用三要素下任务 → 先 Plan 审方案 → 小步执行逐条审批 → 编译测试通读过 diff → 把坑沉淀回规则。 核心心法就一句：你是审批人和验收人，不是旁观者——方案你审、命令你批、结果你测，Agent 负责跑腿，你负责掌舵。