“你这里写得太差了”不利于讨论；“这里也许还可以更好”又可能让人不知道该改什么。评审意见的目标是让对方能定位、理解并验证问题，而不是在尖锐和含糊之间二选一。
把一条意见拆成观察、影响、建议，通常比堆叠礼貌词更有用。AI 可以协助改写，原始代码和证据却不能退出视野。
用一个具体问题检验改写
原意见：“请求失败也返回成功，这逻辑不对。”
更可执行的版本：“这条分支在 HTTP 500 时仍返回 true，调用方会把失败当成完成。建议仅在确认响应成功后返回 true，并为 500 与超时各加一个失败用例。这里还没有验证重试是否会重复提交。”
后者没有替作者判断能力，也没有承诺“加上重试就完全解决”。讨论指向代码行为和验证方法。
先验证意见是否齐全
保存为 review.py。它检查的是意见结构与引用位置，不理解程序是否真的存在该缺陷。
feedback = {
"location": "client.py:42",
"observation": "HTTP 500分支返回true",
"impact": "调用方可能把失败记为完成",
"suggestion": "区分成功与失败，并补500/超时用例",
"unknown": "尚未验证服务端是否已接收请求",
}
def render(item):
required = ("location", "observation", "impact", "suggestion", "unknown")
if any(not isinstance(item.get(k), str) or not item[k].strip()
for k in required):
raise ValueError("缺少可执行的评审信息")
return "\\n".join(f"{k}: {item[k]}" for k in required)
text = render(feedback)
assert "HTTP 500" in text and "尚未验证" in text
try:
render({**feedback, "observation": ""})
except ValueError:
pass
else:
raise AssertionError("空意见被接受")
print(text)
真实应用要把代码片段、行号与版本绑定。改动后行号会漂移，脱离版本的一条“温柔建议”仍可能指错位置。安全或正确性缺陷也不应被语气优化降成可有可无的偏好。
给改写工具定一个小任务
提示词可以要求保留观察事实、可能影响和未测项，只调整称呼与句式，不添加性能收益。输出后对照原意见人工阅读，尤其看否定、条件和严重程度是否变化。
2026 年 10 月 22 日 Agent Skills 的公告体现了把程序性知识整理成可复用流程的方向。评审改写也适合成为一个窄流程：输入证据、生成建议、人工核对，而不是给模型一把自动合并的钥匙。公告
本文只实跑了意见协议，没有调用模型或审查真实仓库。体贴不必削弱判断；把问题讲准确，本身就是对协作者时间的尊重。
