Zc Review Response And Resolution

审查响应与问题收敛

zmice Updated

File contents

审查响应与问题收敛

何时使用

  • 已收到 reviewer、同事或代理给出的审查意见之后
  • 一轮 review 结束,需要把问题分类并安排修复顺序时
  • 修复完成后,需要补充回归验证并回复 reviewer 时
  • 需要判断哪些意见必须立即处理,哪些可以延后时

输入前提

  • 已有明确的 review 结论或问题清单
  • 已知道这次变更的规格、计划或原始目标
  • 愿意对每条反馈给出处理结果,而不是只回一句“已看”

执行步骤

  1. 先把反馈分类:
    • 阻塞合并的问题
    • 应在本轮修复的重要问题
    • 可延后的建议项
    • 需要澄清或不同意的点
  2. 回到原始规格或任务,确认每条反馈是否真会影响需求、正确性、可维护性或风险边界
  3. 按顺序处理:
    • 先修 Critical
    • 再处理会影响当前发布质量的 Important
    • Suggestion 明确采纳、暂缓或拒绝,并说明原因
  4. 每完成一类修复,都补最小必要的回归验证:
    • 受影响测试
    • 构建或 lint
    • 需要时补充人工验证
  5. 回复 reviewer 时逐条说明:
    • 已修复什么
    • 用什么验证证明成立
    • 哪些未采纳以及理由
  6. 重新提交前确认:
    • 没有遗留未回应的阻塞问题
    • 新改动没有引入额外漂移
    • 反馈闭环对外可读、可核验

成功标准

  • 每条 review 意见都有明确处理状态
  • 修复顺序由风险和合并门槛驱动,而不是按回复方便程度排列
  • 回复 reviewer 时包含具体改动和验证依据
  • 延后项被显式记录,不伪装成“已处理”
  • 重新提交后,reviewer 能快速判断这一轮是否真正收敛

相关原则

  • 先消除阻塞,再处理优化项
  • 不把“不同意”写成情绪表达,要写成技术理由
  • 回复必须附验证证据,不能只有态度
  • review 响应是收敛过程,不是辩论过程

与其他技能的衔接

  • 通常接在 code-review-and-quality 之后
  • 回归验证依赖 verification-before-completion
  • 如果反馈暴露出规格缺口,可回到 spec-driven-developmentplanning-and-task-breakdown
  • 如果反馈聚焦安全或性能,可转给对应专项 skill 深挖

zmice/zc-qwen-extension/tree/main/skills/zc-review-response-and-resolution commit 2b3ff7636a

Frequently asked questions

npx skillmds@latest add zmice/zc-review-response-and-resolution