编码 Agent 实战 5 条：PR 先交证据，决策写回工单
用编码 Agent 久了，很多团队会碰到同一类问题：代码写得越来越快，返工和扯皮却没少。毛病大多出在流程上，模型本身没那么大锅。下面这 5 条是最近业内用 Claude Code、Codex 一类工具时反复被提到的做法，每条都能直接搬进团队规范。本文是经验整理，未实测。
前置条件
- 团队已经在用 Claude Code、Codex 或 Cursor 这类编码 Agent，有工单系统（Jira、Linear、GitHub Issues 都行）。
- 代码托管在 GitHub 或 GitLab，能改 PR 模板。
- 能接触到不止一个模型（订阅或 API 都可以），第 4 条要用。
1. 计划里拍板的事，要写回工单
让 Agent 先出计划再动手，几乎是现在的标配。问题是，工单本来写得含糊，计划里会顺手把这些空白填上：接口返回什么字段、边界情况怎么处理、哪个旧逻辑可以删。这些决定只活在计划文件或聊天记录里，过两周就没人找得到了。
做法很简单：计划定稿后，让 Agent 把「本次做出的决定」整理成一段，追加回工单描述或评论。工单就成了这件事唯一的决策记录，以后排查问题、交接、写复盘，都只看一个地方。
计划确认后，请把计划中补充或改变了原需求的决定，
按「决定 / 原因 / 影响范围」三列整理成表格，
追加到工单 #1234 的描述末尾，不要改动原有内容。2. 没有截图或录屏的 Agent PR，先别审
Agent 提 PR 很快，人审 PR 很慢，评审时间就成了新瓶颈。一条很有效的规矩：Agent 提的 PR 必须附上改动生效的证据，前端给截图或录屏，后端给命令输出或测试结果。没有证据的直接打回，不进人工评审队列。
有了这道门槛，「代码看着对」和「功能能用」就分开验了。很多 Agent PR 的问题不在代码风格，而在压根没跑起来过。把这一步交给 Agent 自己完成，比再加一层 CI 检查更省评审者的时间。
<!-- .github/pull_request_template.md -->
## 验证证据（必填，缺失将不予评审）
- [ ] 截图 / 录屏（UI 改动）
- [ ] 关键命令输出或测试结果（非 UI 改动）
- [ ] 复现步骤GitHub 支持在仓库里放 pull_request_template.md，新开 PR 时会自动带出这段模板。
3. 跨团队联调，开一个会话装下几个仓库
跨团队联调最耗时的是来回对文档：你发接口文档，我回字段说明，再约个会。如果你同时有几个相关仓库的读权限，可以在一个 Claude Code 会话里把它们都加进来，让 Agent 直接对照两边的代码查调用链。
Claude Code 官方的 --add-dir 参数就是干这个的：给会话额外加工作目录，Agent 可以读写这些目录里的文件。想长期生效，可以写进设置里的 permissions.additionalDirectories。要注意，官方文档写明，加进来的目录里大部分 .claude/ 配置不会被自动发现，各仓库自己的规则不会自动生效。
cd ~/work/order-service
claude --add-dir ../payment-service ../web-checkout联调时让 Agent 直接读对方的代码，比互相发文档快得多，也少了很多误会。
前提是权限要合规：只加你本来就有权限看的仓库，涉及密钥的目录别加进来。
4. 合并前，让几个模型互相挑刺
单个模型审自己写的代码，容易对同一类错误视而不见。有人的做法是写一个「评审会」式的 Skill：合并前把 diff 分别交给两三个不同厂商的模型，各自给出问题清单，再让主 Agent 汇总分歧，只有分歧都处理掉才允许合并。
这类流程没有统一的开源实现，下面是一个可以照着改的思路：
- 主 Agent 生成 diff 和改动说明。
- 分别调用 2–3 个不同模型做评审，要求只列问题，不改代码。
- 主 Agent 合并清单，按「多数模型都提到」「只有一个模型提到」分级。
- 前一类必须修；后一类由人决定。
成本要算清楚：每次合并多花几次模型调用，适合核心模块和高风险改动，不必每个小 PR 都跑。
5. 额度「变少」时，先看是哪一层限制
Claude 付费订阅有两层限制：每 5 小时重置一次的会话额度，以及每周重置一次的周额度，官方帮助文档写明这两层额度在 Claude 和 Claude Code 之间共用。最近不少重度用户觉得额度变少了。研究机构 SemiAnalysis 公开说法是检测到部分账号在做额度 A/B 测试：5 小时窗口变大、周额度变小。Anthropic 没有公开确认这项测试，具体幅度这里不引用。
SemiAnalysis 10 月 5 日的报告里也写过，他们曾在一家未点名的厂商那里碰到额度 A/B 测试，三个相同订阅里有一个额度明显偏低，厂商事后确认是一项很小范围的测试。对团队来说，能做的有这几件：
- 重活集中在周初跑，周额度见底时把杂活切到便宜模型或 API。
- 团队里有人额度明显偏低，可能是测试分组，不一定是用法问题。
- 关键任务别只押一个订阅，留一条按量付费的后路。
常见坑
| 坑 | 表现 | 怎么避 |
|---|---|---|
| 决策只留在计划文件 | 两周后没人知道为什么这么改 | 计划定稿即回写工单 |
| 验证证据是 Agent 编的 | 截图对不上当前分支 | 要求录屏带分支名或提交号 |
| --add-dir 加了无权限仓库 | 合规风险、密钥泄露 | 只加本来就有读权限的目录 |
| 每个 PR 都跑多模型评审 | 成本和等待时间翻倍 | 只对核心模块启用 |
完成标准
- 团队 PR 模板里有「验证证据」必填项。
- 最近 3 张由 Agent 完成的工单，描述里都有回写的决策表。
- 至少跑通一次多仓库会话联调，并记录省下的沟通时间。
- 团队知道自己的订阅额度先撞的是 5 小时线还是周线。
想给 Agent 再加一道自动护栏，可以看 Claude Code Hooks 护栏教程；想了解官方的自动代码评审，看 Claude Code Review 正式上线；选工具可以先读 Claude Code 怎么买、怎么用。
最后
5 条里最容易落地的是第 2 条：今天就把 PR 模板改掉，下周看评审时间有没有降下来。
