作者该怎么响应意见
Google 作者指南对响应意见的要求很朴素：每一条都要给出结论。改了就说清改法，不打算改就解释理由，没看懂就直接问。已读不回是评审效率最大的敌人——评审者不知道自己的意见是否被采纳，只能靠再问一遍确认，来回轮次由此增加。
基本信息
| 回复要求 | 每条意见给出结论：已改说明改法，不改说明理由 |
|---|---|
| 回应节奏 | 能当场处理就当场处理，需要时间就说明预计时间 |
| 升级路径 | 两轮未收敛即约语音或当面沟通，结论回写到评论 |
| 更新说明 | 重发新版本时说明本轮改了哪些、哪些意见未采纳 |
逐条响应的做法
- 改了就写清怎么改的，别只留一句「已优化」让评审者再翻 diff。
- 不打算改就说明理由：约束条件、性能考量、与既有约定一致。
- 没看懂就直接问，不要猜测评审者意图硬改，改错方向更费时间。
- 讨论超过两轮仍未收敛：转语音或当面沟通，把结论写回评论。
- 意见之间互相冲突时先澄清分歧点，再决定采纳哪一条。
常见情形与处理
| 情形 | 建议做法 |
|---|---|
| 意见是对的 | 修改并回复改法，必要时补测试 |
| 意见基于误解 | 先补充上下文，再说明为何不改 |
| 意见属于偏好 | 说明现有约定的来源，或标注为后续改进 |
| 暂时无法处理 | 说明原因与计划时间，避免无限期挂着 |
| 多人意见冲突 | 列出分歧点，请负责人或架构师定夺 |
回复写法示例
回复写法示例
# 已修改：说明改法而不是只写「已优化」
已把两次读取合并进同一个事务，并补了并发场景用例。
# 不修改：给出理由与依据
这里保留默认值是为了兼容旧配置，改动会破坏已有部署；
可以在下个版本按弃用流程处理。
# 未理解：直接问，不要硬猜
我理解你想说的是缓存失效时机，能具体指一下哪一行吗？已读不回最伤评审积极性：评审者也需要知道自己的意见是否被采纳。
把结论写进评论而不是只写在聊天工具里：后来人翻提交历史时，能看懂当时的取舍。