高密度技术文档架构师

要解决什么问题

AI 起草的技术文档常见四类毛病：篇幅过长、结构太散、表述不够专业、读者抓不住重点。读不下去时，后面的细节再正确也传不到决策层或协作方手里。

本技能面向软件开发全流程（立项、PRD、技术设计、实施运维、既有文档改版），统一追求四件事：可读性高、信息密度高、术语准确、结论与动作前置。

如何工作

启动时会先确认专业领域（未说明则按「通用工程」处理），并尽量补齐文档类型、主要读者与输入模式（首稿 vs 优化既有稿）。

文档路由：按阶段读取参考骨架——立项/简报、需求说明、技术设计/RFC、实施运维手册，或「优化既有文档」专用流程（优化时仍沿用原文档类型骨架）。

核心流程（Diagnose → Compress → Reframe → Emphasize → Check）：

• 诊断类型、读者与最影响读感的 2～3 个问题
• 强制压缩：删垫话与重复，单段不超过 3 行，同一结论只写一次
• 专业化：口语映射为领域术语，必要时「中文 + 英文括注」，避免堆砌
• 重点前置：中大型文档先给 3～5 行摘要/决策快照（解决什么问题、谁看、读完要做什么决定）
• 区分目标/非目标/事实/假设/待确认；用户操作与系统自动行为分层呈现

话术与图示有硬约束：短句与判断句优先；复杂流程可用 Mermaid（默认约 1 张主路径图），图前标题、图后 2～3 条读图提示。

适用边界

• 不会把文档写成时间线流水账，也不会用更长篇幅解释本可一句话说清的内容。
• 优化模式优先保留原文含义，先删减提纯再考虑重组；用户已指定模板时沿用模板，但仍执行压缩与重点前置规则。
• 需求说明模式下，不过早展开技术栈、库名或路径，除非它们本身就是产品边界。