意图对照评审意见
你是对照用户意图的代码评审助手。只根据给定的需求原文（含非目标）、PR diff 与已声明的测试结果写中文评审，禁止编造未提供的测试通过结论或覆盖率。
输出：
## 意图符合度（符合/部分偏离/明显偏离 + 依据）
## 缺口与风险
## 关键路径测试建议（可验收）
## 合并建议（建议/不建议；人仍最终 Approve）
## 需产品确认的问题
输入：
{{intent_and_diff}}场景说明
代码能跑不等于满足需求。评审 Agent 读取 Issue/产品说明与 diff，标出偏离意图、缺测试与风险点；未覆盖主路径测试则阻断合并建议。人仍做最终 Approve。可把结论贴到飞书/PR 评论。不编造未运行的测试结果。
案例叙事
01他们做了什么
Hacker News 评论里，用户 visarga 总结自己约半年来的做法：最要紧的是少出 bug、并确认代码真的做了你想要的事；手段是写测试、打日志、与运行中的应用交互。意图校准上，他让 Agent 重读该项目里全部用户消息，再据此检查代码与测试；长周期工作则维护一份留在仓库里的 todo，关闸前后各审一次。公式被概括为：评审 Agent + 测试 + 用户消息日志。帖中未给出缺陷逃逸率或合并时长等统计。
国内落地可把 Issue/产品说明/「非目标」与 PR diff 绑在一起，让评审 Agent 输出意图符合度、缺口与关键路径测试建议；结论贴到飞书文档或 PR 评论。未覆盖主路径测试则只给「不建议合并」；人做最终 Approve。禁止编造未运行的测试结果；对模型生成的测试也要抽检断言。
02实际效果
- 源未披露缺陷逃逸率、评审耗时或合并质量对比等量化；公开评论只描述「评审 Agent + 测试 + 用户消息日志」组合。
- 作者自述：类似做法约半年；即使约 1 万条消息的项目，重读用户消息做意图校准也只需几分钟量级（评论陈述，非我方实测）。
- PR 评审从只看「能不能跑」，变成对照原始意图与测试缺口的待审结论，合并决定仍在人。
03值得知道
- 公开源未给出可复用的质量基线，上线后需用自有缺陷/回滚台账复盘，勿把「有评审 Agent」当成质量承诺。
- 禁止把未实际跑过的测试写成已通过；生成测试须抽检，避免无断言或假绿。
- Issue 若不写清非目标，易误报漏做；飞书/PR 评论里的敏感需求原文要注意权限与脱敏。
04可复制提示词
飞书评审摘要
把评审结论压成可贴飞书/企微的短摘要（≤180 字）：意图结论、缺测项、是否建议合并、待人确认点。不要添加未出现的通过率或缺陷数量。
评审结论：
{{review_result}}怎么做
- 绑定 Issue/需求原文与 PR diff
- Agent 输出意图符合度、缺口与测试建议
- 补测并通过 CI 后人工合并
实用提示
- 把「非目标」写进 Issue，评审才不会误报漏做
- 对生成测试也做抽检，避免无断言的假测试