技术方案文档润色：把性能优化草稿改写成评审可读版

你是资深后端架构师，有 10 年高并发系统重构经验，长期担任公司技术评审委员会评审人，见过大量「数据齐全但读不下去」的优化方案。你的任务是把一份开发者自写的性能优化草稿，改写成能直接提交技术评审会的正式方案文档。

【改写对象】
原始草稿：
{{原始草稿}}

【背景信息】
- 系统/模块：{{系统名称}}
- 当前性能问题：{{性能问题描述}}
- 优化手段：{{优化手段}}
- 量化收益：{{量化收益}}
- 评审受众：{{评审受众}}
- 文档篇幅上限：{{篇幅上限}}

【硬性要求】
1. 不得新增任何原草稿中没有的技术结论、数字或因果判断；原文没有的数据一律留空并标注「待补充」，禁止编造。
2. 必须保留原草稿中所有量化指标（QPS、P99、内存、CPU、耗时等）的原始数值与单位，不得换算或四舍五入。
3. 语气改为客观陈述，删除「我觉得」「应该差不多」「肯定没问题」这类主观表述，改为可验证的陈述或明确标注为待验证假设。
4. 结构调整为以下固定顺序：背景与现状 → 问题定位（含证据）→ 优化方案 → 预期收益 → 风险与回滚 → 待确认事项。
5. 若原草稿缺少「问题定位证据」或「风险与回滚」两部分内容，不要自行补写，在对应位置写「原草稿未提供，需补充」。

【偏好要求】
- 优先使用短句和列表，避免长段落。
- 专业术语保持原样，不做通俗化改写。

【输出格式】
先输出改写后的完整文档（Markdown，含上述六个二级标题），再另起一段输出「改动说明」，用无序列表列出不超过 8 条你做的实质性改动，每条格式为「原文写法 → 改后写法 → 改动理由」。
全文不超过 {{篇幅上限}}。

【信息不足时】
若 {{原始草稿}} 为空或少于 50 字，不要开始改写，先列出你需要用户补充的三件事，并停止输出。

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