让只看 diff 的 Agent 反推设计意图

做完一组改动后，我会让另一个没有参与实现的 Agent 做一次 Code Review。第一轮先不给它 PRD（产品需求文档）和实现过程，只提供这次的 diff，让它反推：这次要解决什么问题，预期行为是什么，几处修改为什么需要一起出现。

如果它还原出的设计意图与我的预期一致，说明改动至少表达出了预期方向；如果不同，就检查差异来自实现、表达，还是需求本身没有说清。参与实现的 Agent 已经知道背景，独立推断则能看到改动本身传达了什么。

先让它独立推断

让它回答的也不只是“改了哪些文件”。我想知道的是：

• 这次改动在解决谁的什么问题。
• 用户能观察到哪些行为变化，哪些行为仍然保持原样。
• 几处修改为什么需要一起出现。
• 哪些地方仅凭 diff 还无法确定。

最后一项很必要。代码可以显示一个条件，却不一定显示这个条件的业务原因。读不出来时留出疑问，比替我补上一个听起来合理的需求更有用。

可以把第一轮要求写成这样：

你没有参与这次实现。只根据下方 diff，反推这次改动的需求与设计意图。

说明要解决的问题、用户可见的变化、兼容范围，以及几处修改之间的关系。
每个判断给出对应的改动依据。无法确定的地方单独列出，不补造业务背景。
先提交这份推断，不进行修改，也不读取其他需求材料。

先保留这一轮输出，再给原始需求作对照。否则，Agent 看过答案以后补写一份一致的解释，就失去了独立推断的意义。

用反推结果核对设计

我主要看反推结果能否解释这组改动为什么成立。新增的接口服务于什么操作，界面为什么需要增加一个状态，几处修改是否共同解决了同一个问题——这些关系应该能从实现中读出来。

当一个没有参与讨论的 Agent 还原出了相同的目标和设计思路，我就多了一份独立的判断依据：这组代码表达的方向与我的预期是一致的。参与实现的 Agent 已经知道我要什么，很容易沿用讨论中的解释；换一个只看 diff 的 Agent，才能检查实现本身传达出的意思。

随后再把原始需求交给它，核对反推结果。没有完整 PRD 时，就由我补充最初要解决的问题、预期效果和必须保留的行为。对不上的地方需要逐项确认：是少做了一部分需求，还是改动引入了额外行为，或者设计依赖一个 diff 里没有体现的前提。

有些业务原因确实无法从代码中恢复，Agent 应当把疑问留下来。它不必猜中所有背景，但需要区分已经有改动依据的判断和无法确定的部分。这样我才能判断要补实现、补说明，还是先把需求说清楚。

按 P0–Px 整理审查结果

确认设计方向后，再围绕这份预期检查实现，把问题按 P0–Px 排序。此时审查既包括功能是否符合需求，也包括实现方式有没有因为不断追加局部修补而变得难以维护。

每条问题需要写出触发条件、影响和代码依据。优先级应当反映问题对这次交付的影响：正常操作会丢失数据，和某个边界状态显示不准确，处理顺序显然不同。项目已有的分级标准可以直接沿用，但报告里仍要说明为什么给出这个等级。

需求歧义单独列出来让我确认。一个行为如果尚未确定要不要支持，直接把它列为缺陷，就会让后续修改建立在错误前提上。缺少验证的部分也应当写明具体场景，例如某种旧数据是否检查过，而不只是留一句“需要补测试”。

第二轮可以接着这样要求：

以下是这次改动的原始预期。请与刚才独立反推的设计逐项核对。

列出符合预期的部分、实现偏差和需要我确认的歧义。
在已确认的需求范围内做 Code Review，问题按 P0–Px 排序，说明触发条件、影响和代码依据。
同时检查局部修补是否增加了不必要的复杂度，列出尚未验证的具体场景。
报告保持简洁，不进行修改。

整理审查报告

最后留下两部分：一份从 diff 还原、经对照后确认的需求说明，以及一份按优先级整理的问题清单。前者可以用来补充 issue 或 PR，后者决定接下来先修改什么、验证什么。需要我回答的问题独立列出，确认后再交给实现 Agent 处理。

设计方向符合预期后，关键操作和边界场景的运行结果仍然需要测试与实际使用来确认。