AI 编程 · 工程效率

AI Coding Workflow：如何减少 AI 反复修改代码？

发布于 2026.08.08 约 10 分钟阅读

Plan → Scoped Edit → Verify / Cursor Rules / 小步 diff / 验收清单 / 死循环排查

用 Cursor、Claude Code 或 Copilot Workspace 写功能时，你是否经历过这样的夜晚：AI 改了 A 文件，测试挂了；修 B 文件，A 又坏了；你说「再试一次」，它把昨天能跑的代码也改没了。这不是模型「不够聪明」，而是缺少可重复的 AI Coding Workflow——没有把「规划、改动范围、验收」拆成独立阶段，Agent 就会在同一个错误假设上无限打转。

本文给出一套在 2026 年团队里实测有效的流程：先 Plan 再动刀，每轮只改一小块，改完必须 Verify 才进入下一步。配合 Cursor Rules 与 Git 小提交，我们把「同一 bug 改 8 轮」压到 2 轮以内。若你同时在搭云端 Mac 上的 MCP Server 或选型 GitHub AI Agent 开源项目，这套工作流同样适用。

为什么 AI 会陷入「改不完」的循环？

Agent 模式的本质是：在不确定的环境里试错。当你只说「修一下登录 bug」，模型不知道你指的是 OAuth 回调、Session 过期还是前端路由——它会猜一个最像的答案，改完跑测试，失败后再猜另一个方向。每一轮都推翻上一轮的部分假设，diff 越来越大，上下文里堆满互相矛盾的修改记录，最终进入「越改越乱」的状态。

三个根因

目标模糊——没有写清「成功长什么样」，AI 只能用测试报错反推，而报错信息往往指向症状而非根因
范围失控——一次任务跨 10+ 文件，改 auth 时顺手 refactor 了 utils，引入新回归
缺少验收门禁——没有「通过才继续」的硬规则，失败时默认策略是「再生成一版」而非「回滚并重定范围」

经验法则：如果你连续三轮都在说「不对，再改一下」，问题不在模型，而在任务没有重新 Plan。

三阶段工作流：Plan → Scoped Edit → Verify

把每次 AI 协作拆成三个不可跳过的阶段，比换更强的模型更有效：

AI Coding Workflow 三阶段：Plan、Scoped Edit、Verify — 先定范围再动刀，Verify 不过就回到 Plan，而不是在同一 diff 上叠加补丁。

Plan（规划）——用 Plan 模式或纯对话，列出要改的文件、不动什么、验收命令（如 npm test -- auth）。产出一段可粘贴的「任务规格」，~~不要直接让 Agent 开改~~ 应先确认规格
Scoped Edit（受限改动）——明确写「只改 src/auth/login.ts，禁止动其他文件」。每轮目标：1–3 个文件、<200 行净变更
Verify（验收）——跑测试、lint、手动冒烟。通过 → 提交并进入下一任务；失败 → 带着完整错误日志回到 Plan，而不是说「再试一次」

阶段	推荐工具/模式	产出物	常见错误
Plan	Cursor Plan / 对话-only	任务规格 + 文件清单	规格太长仍含糊
Scoped Edit	Agent + `@file` 引用	小 diff PR	顺手 refactor 无关代码
Verify	终端 / CI / `Cmd`+测试快捷键	绿测试 + commit	跳过测试直接下一任务

提示词结构：一次说清目标、边界与验收

可复制模板（把括号换成你的项目）：

text

## 目标
（一句话：用户点击登录后 3 秒内进入 dashboard）

## 范围
- 只改：src/auth/login.ts, src/auth/session.ts
- 禁止改：路由、样式、其他模块

## 验收
- npm test -- --grep "login"
- 手动：错误密码显示「账号或密码错误」，不泄露用户是否存在

## 上下文
- 当前错误：（粘贴完整 stack trace）
- 相关约定：Session 存 Redis，见 docs/auth.md

这种结构对应 Anthropic 的 Claude Code 最佳实践里强调的「明确边界」——模型不需要猜你的意图，回归面也可控。

Rules / Skills：把项目约束写进仓库

每次对话重复「我们用 pnpm、不用 class 组件、测试放 __tests__」会浪费 token，也让 AI 时而遵守、时而忘记。把约定写进 .cursor/rules 或项目级 AGENTS.md：

Rules（规则）: 持久约束：命名风格、禁止模式、提交前必须跑哪些命令。Cursor 会在每次 Agent 调用时自动注入。
Skills（技能）: 可复用的任务剧本，例如「添加新 API 端点」分步清单。减少 AI 每次从零摸索项目结构。
User Rules vs Project Rules: 个人偏好（如「回复用中文」）放 User；团队共识（如「不改 backend 除非明确要求」）放 Project，避免协作时各说各话。

参考 Cursor Skills 文档，把高频流程固化后，反复修改同一类错误的次数会明显下降。

小步 diff 与 Git 纪律

AI 擅长一次生成大块代码，但人类审查大 diff 的能力有限。建议：

每轮 Agent 任务对应一个 commit——message 写清「Plan 摘要」，方便 git revert
改乱了就 reset——不要在大 diff 上继续 patch；git checkout -- . 回到绿测试点，用更小的范围重开任务
用分支做实验——尤其在云端 Mac 或 CI 环境试 Agent 时，git worktree 或独立分支隔离「AI 乱改」风险

上下文管理：别让 Agent 淹没在文件海里

把整个 monorepo 丢给 Agent，等于让它在噪声里找信号。更有效的方式：

用 @filename 精确引用 3–5 个相关文件，而不是「扫描整个项目」
大重构拆成多个 Plan：先接口、再实现、再测试，每步 Verify
长对话到 15 轮以上时，开新对话并粘贴「任务规格 + 当前状态」，比带着历史包袱继续改更干净

深入了解：Plan 模式和 Agent 模式何时切换？

需求不清晰、涉及架构取舍时用 Plan；规格已写好、文件清单明确时用 Agent。在 Cursor 里可主动 SwitchMode 到 Plan——很多死循环是因为在 Agent 里边想边改，应退回 Plan 重定范围。

四种常见死循环与破局法

现象	根因	破局
修 A 坏 B，修 B 坏 A	范围太大、缺少单元测试隔离	缩小到单文件；补 mock；分两个 Plan
同一错误改五遍仍失败	错误日志不完整，AI 在猜	粘贴完整 stderr；指定「先读 X 再改」
代码风格每次都不一样	Rules 未配置	加 .cursor/rules；引用现有文件作范例
「完成了」但功能不对	验收标准未写入提示词	Plan 阶段写清手动验收步骤

若你正在用 Agent 编排复杂流水线（例如批量文档处理或 MCP 工具链），把「路由 → 执行 → 校验」分层的设计思路，与我们在 PDF 批量识别流水线里讲的分流架构是同一类模式：先判断再动手，避免所有任务走最慢、最易出错的路径。

常见问题

是不是模型越强越少反复？——强模型减少「语法级」错误，但范围失控导致的回归与模型档位无关，Workflow 才是主因
团队怎么统一？——把 Rules、PR 模板、验收清单放进仓库；Code Review 时检查「是否小步提交」
可以完全交给 Agent 吗？——可以自动化执行，但 Plan 和 Verify 仍建议人工门禁，尤其是支付、鉴权、数据迁移
和 TDD 怎么配合？——先让 AI 写失败测试（Plan），再实现（Scoped Edit），绿了再 refactor——天然契合三阶段

回到标题：减少 AI 反复修改代码，靠的不是「多试几次」，而是 Plan → Scoped Edit → Verify 的纪律、清晰的提示词、仓库里的 Rules，以及敢于 git revert 的勇气。把流程固定下来之后，你会把时间花在「定义问题」上，而不是「第 N 轮补丁」上。