Polish Technical Docs
Overview
将风格随意、结构松散或表达冗长的技术原文打磨成专业、清晰、结构化的技术文档，同时严格保持技术含义、结论、代码逻辑与作者意图不变。
把重点放在结构整理、语言精炼、术语统一和 Markdown 规范化，不改写技术观点，不补写原文没有的信息。
Workflow
- 通读原文，先确认主题、目标读者、技术深度、关键结论、代码作用和不可改动的事实。
- 识别问题：结构混乱、段落顺序失衡、句子冗长、口语化表达、术语不统一、Markdown 不规范、无价值填充语。
- 重组结构：只在原意支持的前提下调整段落顺序，补充必要标题、列表、摘要或结论；不要凭空扩展论点。
- 逐句精炼：把口语化改成书面技术语言，压缩冗词，消除歧义，统一术语，保持作者视角和原始判断。
- 终审全文：核对事实、数字、代码、命令、示例和结论，再统一标点、格式和 Markdown 细节。
Editing Rules
- 把技术准确性放在首位。
- 不要添加原文未提及的机制、假设、基准、风险、建议、背景信息或结论。
- 不要删除承载含义的技术细节。句子别扭但信息重要时，改写而不是删掉。
- 保持代码逻辑不变。只做格式化，并在确有必要时添加极简注释解释不明显的意图。
- 保持作者视角，避免对读者使用第二人称。
- 避免汇报式填充表达，例如
本文将介绍、接下来我们来看、你可以看到，除非原文强依赖这种表述。 - 优先使用主动语态、精确动词和短句。
- 在同一篇文档中统一术语；同一概念优先只保留一个称呼，除非原文刻意区分。
- 使用标准 Markdown 组织标题、列表、代码块、引用和表格。
Structure Heuristics
- 只有在原文已经存在对应逻辑层级时才补充标题。
- 并列观点、步骤或条件适合改成列表。
- 只有在内容短且可对照时才使用表格。
- 只有当原文本身已经提供足够信息时才提炼摘要。
- 只有当原文已经隐含结论时才补充结论段；不要制造新的 takeaways。
Working Mode
- 用户给出文件路径时，直接在原文件上编辑。
- 用户直接给出正文时，返回完整优化后的 Markdown，不加前言、解释或变更摘要。
- 遇到看似可疑但无法从已给材料验证的技术说法时，保留原始主张，不靠猜测“修正”内容。
- 原稿信息不足以支撑激进重写时，采取保守编辑，避免编造过渡句、示例或论证。
Quality Bar
完成前逐项确认：
- 核心观点和技术结论未变
- 代码与命令的行为未变
- 冗余措辞已压缩
- 标题与列表确实反映真实结构
- 术语、标点和格式保持一致
- 优化后的文本更紧凑、更清晰，但仍然是同一篇文章