用途
本技能用于协助评审者起草、改写、归类和改进代码评审意见。其核心目标是让评审意见既改善代码质量，也提升开发者未来的判断力：意见需明确严重程度、基于工程推理、针对代码而非个人。
主要能力
- 意见结构：对非琐碎的评论建议使用统一结构——先写严重程度与对代码的观察，再说明“为何重要”（工程理由、用户影响、可维护性影响或违反的项目规则），最后给出“请求动作”（具体修复、待答问题或需作者做出的决策）。微小评论保持简短，仅在意图可能被误解时使用完整结构。
- 严重程度标签：
- BLOCKER：批准前必须修改，因正确性、可维护性、安全、数据、测试或运维风险不可接受；
- IMPORTANT：批准前应当修改，仅在有明确理由时可豁免；
- QUESTION：评审者需先获得信息才能决定；
- NIT：细节打磨，不阻塞批准；
- OPTIONAL 或 CONSIDER：作者可拒绝的建议；
- FYI：教育性背景或未来考虑，不期望采取动作。
- 写作规则：评论代码、设计、测试或行为，而不评价作者；要求超出明显风格或机械清理的改动时须解释原因；用“这使 X 更难，因为……”替代“我不喜欢 X”；若理解普通行为需借助评审线程解释，则应要求更简单的代码；仅在代码本身无法合理表达“为什么”时才保留代码注释；仅在比让作者自行推断更快或更安全时给出直接代码或具体设计，否则描述问题并让作者选择实现；可指出好的工程选择并说明好在哪。
- 措辞范式：技能给出可直接套用的示例，如 BLOCKER 示例指出“该路径可能在写入持久化之前返回成功”，并说明进程崩溃后调用方会误以为操作完成，请求将成功响应移到持久写入之后或改为显式异步且可观测；QUESTION 示例询问“什么保证这个回调不会并发执行”，并说明若可并行则
pending可能被同一值减两次；NIT 示例指出助手名看似校验负载实则只规范化空白，建议重命名为normalizePayloadText；OPTIONAL 示例建议将分支提取为具名助手以便扫描三个策略分支。 - 处理反驳：作者不同意时，先重新评估其论点（他们可能更了解代码或拥有被忽略的上下文）；若对方正确则直接承认并解决评论；若仍不同意，先复述其观点，再解释代码健康方面的理由；区分强制请求与偏好；若讨论停滞，转到更高带宽的讨论并将结论总结回评审中；不因自己先写了评论就持续争论，目标是得到最好的代码而非捍卫初始措辞。
- 常见错误提示：留下未标注严重程度的评论使作者误以为必须处理；批评内容正确但语气损害协作；只在评审工具中要求作者解释令人困惑的代码；把每条评论都变成完整的设计任务；把教育性说明当作阻塞项。
使用方式
在评审者需要撰写、润色或分类代码评审意见时触发使用，包括面对粗略的评审笔记、需要让评论更清晰等请求。可按上述结构、标签和措辞范式组织意见，并在作者反驳时按给定流程处理。
适用场景
适用于代码评审过程中的意见撰写与沟通，尤其是需要区分阻塞项与建议、减少误解、处理评审分歧的场合。
限制与来源
内容改编自 Google 工程实践文档（尤其是《How to write code review comments》和《Handling pushback in code reviews》），来源为 https://google.github.io/eng-practices/review/reviewer/comments.html ，许可为 CC-BY 3.0；同一作者也在 agentara/skills 中以 MIT 许可发布，完整声明见 NOTICE.md。技能本身未提供收费、平台或效果方面的信息。