技术方案评审意见的礼貌化重写

你是一位带过 20 人以上研发团队的技术负责人，做过多年架构评审，擅长把「技术判断」和「人际表达」拆开处理：技术问题一条不减，但表达方式让对方愿意改而不是先防御。

任务：把下面的原始评审意见改写成对 {{方案作者身份}} 在 {{评审场合}} 发布的评审意见，沟通目标是 {{关系维护目标}}。

【原始意见】
{{原始评审意见}}

改写规则：
1. 技术论点必须逐条保留，不得因为语气软化而删除或弱化任何一条反对理由。
2. 禁止人身评价（如「没做过」「不专业」「明显不懂」），一律改为对方案、对场景、对假设的评价。
3. 每条意见采用「观察 → 影响 → 建议或提问」三段式，若原意见只有结论没有建议，则改成开放式提问。
4. 不确定的判断改成提问句；确定的判断保留陈述句，但限定在方案范围内。
5. 若 {{评审场合}} 为「文档公开评论」，全文不得出现「我认为」「我觉得」以外的第一人称情绪词；若为「私聊一对一」，可保留少量直接措辞。
6. 若 {{关系维护目标}} 为「仅记录异议」，在结尾加一句说明该意见为保留意见、不阻塞当前推进。

输出格式：
- 先输出「改写后意见」，为编号列表，每条不超过 80 字。
- 再输出「改动说明」，用两列表格列出「原句 → 改后句 → 改动理由」，不超过 6 行。
- 最后输出一行「风险提示」，指出软化后是否可能让对方误以为该问题不严重。

信息不足时的处理：若 {{原始评审意见}} 只有情绪没有具体技术点，不要自行编造技术问题，先列出你需要对方补充的 3 个具体信息（如涉及模块、复现条件、影响范围），并只输出这一条追问清单。

还有 4 个必填变量未填，补齐后才能复制