五、测试与重构场景：低风险迭代的操作手册
为什么这一篇特别重要
很多团队一说到 AI，第一反应都是“让它帮我写新功能”。
但真到日常开发里，AI 最容易帮上大忙的，反而是这些场景：
- 补测试
- 做小步重构
- 清理坏味道
- 给老代码加边界保护
这些活本来就容易枯燥、重复，还要求很稳。
而 AGENTS.md 正好可以把“怎么稳”写清楚。
为什么测试和重构特别容易翻车
因为它们有一个共同问题：
你经常不是在“创造新行为”，而是在“尽量不改变旧行为”。
这就要求规则特别清楚。
不然 AI 很容易这样做：
- 重构时顺手改了行为。
- 补测试只测最顺的那条正常流程。
- 修 bug 时没补回归用例。
- 看到重复代码就大范围抽象，结果越改越乱。
这些都是典型的“出发点对，动作过头”。
测试和重构类 AGENTS.md 最该先写什么
1. bug 修复必须补回归
这一条建议直接写硬：
- 修 bug 必须补回归测试
因为如果连这条都不写，AI 很容易只修症状，不补保护网。
2. 重构默认不改行为
这条也要写清楚：
- 没特别说明时，重构默认不改对外行为
这句话的意义非常大，它会直接影响 AI 是“大胆改”还是“保守拆”。
3. 小步重构优先
- 优先做小步、可验证的整理，不要上来就大改
这条看起来普通，但它能明显减少“大刀阔斧改完再一起验证”的风险。
4. 汇报时说明行为是否变化
- 最终汇报里要说清行为有没有变
这对 review 特别友好。
一个很常见的现场
假设你接手一段订单价格计算逻辑，代码长这样：
public decimal Calc(decimal price, decimal discount, bool vip)
{if (vip){return price * 0.85m - discount;}return price - discount;
}
这段当然能跑，但读起来不够清楚。
如果你让 AI 直接“帮我优化一下”，它可能会做很多超出预期的事。
比如：
- 改名字
- 改参数顺序
- 顺手把
bool vip换成枚举 - 再顺手拆一个新类出来
其中有些改动本身没错，但对一个重构任务来说，动作就太大了。
更稳的任务描述应该怎么写
AGENTS.md 可以帮你把这种任务收口。
比如：
## 重构规则
- 没特别说明时，不要改对外行为
- 动核心逻辑之前，先补测试或者把现有测试补完整
- 重构范围尽量收窄，不要顺手扩成大改
- 最终说明方法签名和输出行为有没有变化
这样 AI 收到任务时，思路会更偏向“先保护、后整理”，而不是“看哪都想重新设计”。
一个更合理的重构方向
public decimal CalculateFinalPrice(decimal price, decimal discount, bool isVip)
{var discountRate = isVip ? 0.85m : 1m;var discountedPrice = price * discountRate;return discountedPrice - discount;
}
这个改动的重点不是“更高级”，而是：
- 名字更清楚。
- 逻辑更容易读。
- 行为没有偷偷改掉。
对应测试也要一起补
[Theory]
[InlineData(100, 10, true, 75)]
[InlineData(100, 10, false, 90)]
public void CalculateFinalPrice_ReturnsExpected(decimal price, decimal discount, bool isVip, decimal expected)
{var result = CalculateFinalPrice(price, discount, isVip);Assert.Equal(expected, result);
}
这就叫“锁住行为再整理代码”。
为什么很多团队补测试总是补不到点上
因为规则没写清“补什么样的测试”。
很多时候 AI 会只补一个最基础的正常流程，然后任务表面上也算完成了。
如果你们想让补测更有质量，可以在 AGENTS.md 里加类似规则：
- 回归测试要覆盖这次真实出错的路径
- 不要补那种只涨数量、不保行为的空测试
- 优先测行为结果，不要把测试绑死在实现细节上
这样就能避免“测试数量变多了，但保护能力没变强”。
重构类任务为什么特别需要限定范围
因为 AI 一旦在老代码里看到重复逻辑，很容易往“顺手再整理一下”走。
人也会这样。
所以这类任务最好在 AGENTS.md 里写明：
- 没明确确认前，不要把重构范围越做越大
这条是防止从“清理一个方法”一路膨胀成“重构半个模块”。
一个很实用的输出格式
测试和重构类任务，我很建议固定成这三句：
- 行为有没有变化
- 这次补了哪些测试
- 还剩哪些地方需要人工多看一眼
这样 reviewer 一眼就能抓重点。
什么时候值得在子目录里单独放测试规则
如果你们仓库有下面这些情况，单独放一份会更舒服：
- 单元测试和集成测试分得很开。
- 某个模块测试特别慢。
- 某些目录里存在老旧测试约束。
比如：
services/api/AGENTS.md
services/api/tests/AGENTS.md
根目录讲通用规则。
测试目录补更细的，比如：
- fixture 怎么放
- 慢测怎么标
- flaky test 怎么处理
小结
测试和重构类任务最怕的，不是慢一点，而是改着改着把行为改歪了。
AGENTS.md 在这里最大的作用，就是强制把“先补保护、再做整理、最后说明行为有没有变”写成默认流程。