vet-feedback

Vet Feedback

将审查反馈视为需要评估的技术主张，而不是必须照做的命令，也不是需要回报的善意。正确比迎合更重要。

流程

1. 阅读每条意见，读完后再做回应。完成标准：掌握完整清单。
2. 理解——用自己的话重述每条意见。任何无法重述的意见都说明不清楚：立即停下来，先询问所有不清楚的意见，再实施任何一条。意见之间会相互影响；理解不完整会导致自信满满地做出错误实现。完成标准：每条意见都已重述或提出疑问。
3. 验证主张，依据实际代码库核实每项主张。审查者说某个函数忽略了错误？打开函数查看。审查者说某条路径已失效？审查调用者的调用轨迹。完成标准：每条意见都已确认、驳回或标记为无法核实。
4. 评估——这条建议适合这个代码库吗？会破坏现有行为、平台支持或用户已做出的决策吗？是否适用 YAGNI：审查者说“把这个正确地实现出来”时，先搜索实际用法——如果没有任何调用者，正确的修复方式就是移除，并提出移除方案。完成标准：每条意见都有明确立场：同意、反驳或改为移除。
5. 回应，给出技术依据。同意时引用证据；反驳时指出具体细节——代码、测试、约束，并提出有针对性的问题。如果无法核实某项主张，就明确说明这一点，并询问如何继续。如果某项建议与用户先前的架构决策冲突，先告知用户，再采取行动。完成标准：每条意见都有明确立场。
6. 实施，一次处理一条意见，按以下顺序：阻塞性问题（破坏性问题、安全问题）→ 简单修正（拼写错误、导入）→ 复杂变更（逻辑、重构）。每项修复都必须是生产代码——必需子技能：使用 test-first。 完成标准：每项修复都有各自通过的测试运行，且没有回归问题。

禁止的回应

绝不要写：“你完全正确”“好建议”“发现得好，谢谢”，任何形式的“谢谢”，或其他带有表演性质的赞同或感谢开场白。说明修复内容，而不是表达感受：“已修复——parseRange 现在会拒绝边界顺序颠倒的情况（parser.ts:88）。”差异就是认可。

来源校准

• **用户：**可信——在主张核实范围内核实后，即可行动。仍然不要做表演性质的赞同。
• **审查子 Agent：**不享有任何特殊校准——其主张与其他主张一样，按相同的核实步骤处理。
• **外部审查者：**需要更加审慎——他们不了解完整上下文。检查建议是否适用于这个技术栈、兼容性底线和架构。但不要未经核实就驳回：审慎意味着核实，而不是条件反射地说“不”。

你曾反驳，但后来发现自己错了

直截了当地说明并修正：“已核实——你说得对，10.x 上的 API 确实要求使用旧签名。正在修复。”不要长篇道歉，也不要为最初的反驳辩解。

似是而非的借口

想法	现实
“快速同意能让审查气氛更友好”	未经核实的同意，会以你的名义发布审查者的错误。
“我先修复理解的条目，剩下的以后再问”	条目之间会相互影响；分批处理会导致误读后直接实施。先澄清所有问题。
“审查者资历深，肯定是对的”	资历不能代替阅读代码。验证主张。
“与其争论，不如直接实现建议”	把未使用的功能“正确地”实现出来，是双重浪费。先搜索。
“快速说句‘谢谢，发现得好！’没什么成本”	这会消耗你的信誉：带有赞美意味的回复会让人觉得你根本没核实。
“反驳显得很防御”	有证据支持的反驳，正是审查发挥作用的体现。沉默才是问题。

危险信号 — 停下并重新开始整个流程

• 你还没打开任何文件，就先输入了表示感谢或赞同的话。
• 第 5 项仍有歧义，你却已经在编辑第 2 项的代码。
• 你在“正确地实现”某项功能，却从未确认是否有调用方。
• 你没有在代码中核实，就驳回了外部审查者提出的问题。
• 你把所有修复都合并到一个提交中，最后才运行一次测试。