架构规划写作（Architecture Plan Authoring）

把复杂的业务背景、技术判断和合作诉求组织成一条听众能跟随、作者能直接讲、合作方愿意参与的因果链，并在思想稳定后用图压缩关键关系。完整不等于把所有材料放进正文；主文档负责建立共识，证据与执行细节负责承接追问。

先确认讲述者、主笔和文种

写作前必须确认五件事：

1. 谁会听或读；
2. 这次汇报希望对方最终理解、认同、决定或投入什么；
3. 实际可用于连续讲述的时长是多少；
4. 最终由谁现场讲述；
5. 用户希望亲自主笔，还是授权 Agent 起草主文档。

只要当前对话尚未明确其中任何一项，就先向用户反问缺失项，再设计文档。一次性、简短地问完，不重复询问已经给出的信息。不要替用户推断汇报对象或汇报目的。

最终讲述者必须拥有故事线。若用户是讲述者并选择亲自主笔，Agent 默认切换为“研究与编辑辅助”：负责检索证据、澄清问题、提出备选结构、检查逻辑和按明确指令做局部修改；未经再次授权，不代写整篇正文、不主动重排主线，也不直接修改在线文档。不能因为 Agent 能快速生成一版完整文档，就跳过用户亲自形成判断和表述的过程。

若用户授权 Agent 主笔，也要先通过提问和简短 Proposal 让用户确认核心判断与故事线，再展开正文。文档是否成功，不以 Agent 产出是否完整为标准，而以讲述者能否脱离文档复述主线、解释判断并回答质疑为标准。

“会议时长”和“有效讲述时长”必须分开。若会议包含问答、讨论或现场决策，文字预算只使用预留给正式讲述的分钟数，而不是整场会议时长。

根据真正用途选择文种。面向组内汇报、方向对齐或资源争取时，默认采用“架构提案”，而不是低层设计稿或项目治理合同。需要判断其它文种时，读取 交付物模式。

按时长冻结正文预算

在列提纲和画图前，先把有效讲述时长换算成正文目标与硬上限。中文技术汇报按以下默认值规划；用户提供了自己的语速或文稿比例时，以用户口径为准。

• 有效技术讲述速度：每分钟 180—220 个汉字；默认规划值为 200 个汉字；
• 文档正文占口头内容的比例：默认 60%；
• 口头内容区间 = 有效讲述分钟数 × 180—220；
• 正文目标 = 有效讲述分钟数 × 200 × 60%；
• 正文硬上限 = 有效讲述分钟数 × 220 × 60%，可取便于执行的向上整百数。

例如，有效讲述时长为 30 分钟：口头内容约 5,400—6,600 字，正文目标约 3,600 字，正文硬上限约 4,000 字。正文不应主动写满上限。

正文预算包括主流程中的段落、项目符号和承载完整句子的表格单元格；不包括标题、简短图注、图中的节点标签、必要的 Schema / 代码、引用链接和附件。不得通过把大段文字塞进图或表来规避预算。

建立故事主线后，先给每个关键问题分配讲述分钟数，再按同一公式分配章节字数。重要章节获得更多时间和文字，不要平均分配。默认语速已经包含正常停顿、翻图和转场；复杂图若需要详细解读，应单独预留讲述时间。

建立唯一故事主线

架构提案默认沿以下因果链展开，具体章节数可随项目调整：

1. **业务变化与机会：**为什么现在需要建设这项能力；
2. **当前能力缺口：**现有方案为什么不足，真实痛点是什么；
3. **核心技术判断：**调研和已有事实让我们形成了什么关键认识；
4. **目标架构：**各层如何分工，稳定接口和变化组件如何解耦；
5. **路线与阶段：**第一期做什么、不做什么，为什么这样排序；
6. **成功验证：**用什么实验和业务验收证明方向成立；
7. **合作与决策：**需要哪些团队以什么方式参与，本次希望确认什么。

这条主线不是固定目录，而是最低限度的因果关系。每一项技术选择都应能向前追溯到业务问题，向后落到实验、验收或合作动作。

先串清文字主线，最后再做图

图表是对稳定思想的压缩，不是替代思考的工具。架构规划默认按以下顺序推进：

1. 用普通文字列出这次必须回答的关键问题；
2. 针对每个问题写清事实、判断、理由和仍待决定的部分；
3. 把这些判断串成一条可以口头复述的因果链；
4. 由最终讲述者 Review 并用自己的语言重述主线；
5. 先形成可读的文字骨架和必要证据；
6. 只有在主线、关键结论和章节关系稳定后，才规划哪些信息值得画图。

只要核心概念仍在变化、章节顺序尚未确认、关键技术判断仍有争议，或讲述者还不能简短复述故事，就暂停正式画图。此时可以使用简单文本框、ASCII 草图或临时示意帮助讨论，但不要投入正式配色、排版和成品画板制作，也不要让已经画好的图反过来绑架方案。

文字主线确认后，再列出整篇文档的视觉骨架。关系、流程、层级、演进、因果、阶段和边界能用图明显提升理解效率时才画图；单一判断、尚未稳定的观点或本来就适合代码/表格的内容，不强行转成画板。

同一组画板必须锁定同一套三色体系，不能每张图自行发明配色。用户或所在团队有品牌色时以品牌色为准；没有时使用本技能的默认配色：

• 底色 #FFFFFF：画布与绝大多数卡片；
• 主色 #0055A4（深蓝）：标题、正文、边框、主链路和每张图唯一的核心焦点；
• 强调色 #DCF4A2（浅绿）：编号、短标签、分隔线和少量高亮。

无论用哪套色，比例规则不变：底色占据大部分画面，主色建立视觉层级，强调色只做少量强调。不要加入无语义的红、橙、粉、紫或大面积灰底。

根据项目内容选择视觉主题，通常包括：

• 业务变化、用户问题与能力缺口；
• 技术发展脉络及关键判断形成过程；
• 目标架构、组件职责和端到端数据流；
• 任务、数据、模型、评测之间的闭环；
• 路线分期、能力边界和演进关系；
• 实验设计、因果归因和验收体系；
• 合作方的输入、产出与衔接关系。

一份需要现场讲述的完整架构提案，通常可以有 4—7 张承担核心叙事的图，但数量不是目标。只有在文字主线已确认且图确实缩短理解时间时才制作；不要为了视觉覆盖率提前画图。图应共同组成一条可以被顺序讲述的故事，而不是互不关联的插图集合。

每张图必须满足：

1. 标题直接表达这张图希望听众记住的结论；
2. 假设听众只看到画板截图，单独展示时仍能理解问题、关系、方向与结论；
3. 正文只解释阅读方式和结论，不逐项复述图中内容；
4. 能在目标文档平台保持可编辑时，优先使用可编辑图形而非整图截图。

主线稳定后，若内容包含三项以上主体关系、三步以上流程、多个分支或多层边界，应优先评估图示是否能显著降低理解成本。表格适合精确比较，不应用来替代架构图、流程图、闭环图或路线图。

画板必须独立说清楚

画板是主要阅读入口，不能假设听众认真读过前文。自包含不等于堆满解释文字，而是用清楚的标题、短句、箭头、分组、例子和必要定义，让画板自己完成表达。

• 禁止放入没有被良好定义的内部黑话、缩写、阶段编号、工作包代号或英文复合术语；
• 一个术语只有在正文此前已定义、目标听众确实需要复用时才可进入画板；即使如此，首次出现时仍优先补充最短的中文解释；
• 若术语不可避免，使用“术语（它实际做什么）”或在图内增加一句短定义，不把解释责任推给正文；
• 优先使用动作和结果命名，例如“理解图片内容”“生成编辑方案”“把方案转换为模型输入”，不要只写抽象组件名；
• 对混合受众，按知识最少但必须参与决策的听众设计语言；算法准确性通过括号术语、附录或正文补充；
• 每张图只引入完成当前结论所需的最少术语，不把完整系统词典搬上画板。

完成后做“截图测试”：只看这一张图，目标听众应能说出它在回答什么问题、关键关系是什么、结论是什么，并且不需要询问任何节点名称的含义。若做不到，先改语言与结构，不靠增加更多黑话解决。

分离三层信息

同一项目至少区分三层，不要在正文中平铺全部细节：

• **汇报主文档：**讲清问题、判断、架构、路线、验证和合作价值；
• **技术证据附件：**论文证据、方案比较、任务清单、实验矩阵、数据口径和失败案例；
• **执行合同附件：**Gate、RACI、Owner、资源上限、时间表、回滚和签字条件。

除非用户明确要写执行规划，不要让 Gate、RACI、工作包编号或资源签字条件占据主叙事。它们用于证明方案可执行，不应替代方案本身。

写每一节

每节只回答一个听众问题，并尽量遵循：

1. 用一句普通人能懂的判断开场；
2. 用一个案例、关键事实或一张关系图建立直觉；
3. 给出支撑该判断的必要技术内容；
4. 说明它对下一节或当前决策意味着什么。

优先解释“为什么”，再引入名词。缩写、编号体系和新框架只在后文确实会复用时引入。标题应能作为作者的现场提词器，而不是数据库目录或项目管理索引。

Theory of Mind：文档不能借用对话记忆

对话是作者与 Agent 的工作记忆，文档是交给零上下文读者的独立接口。作者知道、对话里说过、旧版本写过，都不等于当前文档已经告诉读者。默认读者只能看到当前正文和正文明确链接的附件，不能访问聊天记录、作者意图、中间草稿或被删除的章节。

写作和每次结构性修改都遵守以下硬规则：

• 项目专有概念、缩写、阶段名、坐标轴和分类标签必须先定义、后使用；常识不需要重复解释。
• 信息按依赖顺序出现：基本前提 → 概念与评分规则 → 分类或阶段映射 → 分析方法 → 结果 → 结论与行动。不能先展示 P0/P1/P2、比例或交集，再在后文解释它们。
• 数字首次出现时，正文或紧邻内容必须能回答分母、数据来源、计算方法和证据性质；区分实测事实、模型判断、提案与待验证假设。
• 表格和图不能承担未在自身或前文定义的语义。读者只看标题、表头、图例和前置定义，也应知道每个标签是什么意思、数字该如何解释。
• 删除、移动或压缩内容后必须做一次依赖检查：被删块是否承载了后文仍在使用的定义、前提、单位、来源或映射关系。若承载，先把必要定义迁移到首次使用之前，再删除旧块。
• 每完成一次章节重排、统计替换或大段删除，都立即从零上下文读者视角顺读受影响区间；不要等全文交付时才发现定义倒置。

正文可以通过明确的前文定义或可点击附件避免重复，但不能用“我们之前讨论过”“见聊天记录”或作者心里的默认理解补洞。

处理证据、不确定性和合作诉求

• 区分已核事实、技术判断、提案和待验证假设；不要用精密流程掩盖尚未确认的事实。
• 每个关键决策都应有论文、实验、业务材料或历史数据支撑，但证据服务于判断，不主导行文顺序。
• 不虚构负责人、资源额度、日期或模型边界。需要协作方确认的内容，明确写成待对齐项并放在合适层级。
• 合作诉求先解释“为什么需要这位合作方”，再说明其输入、产出和成功标准。避免一上来分配责任或要求签字。
• 面向新团队或跨团队场景时，语气应专业、明确而开放：展示充分准备，也给合作方留下共同设计空间。

使用表格、代码和文字

• 精确映射和方案比较使用表，避免把整篇文档表格化；
• 单一判断使用短段落，不强行制表；
• Schema、协议或伪代码若本身是讨论对象，应保留代码示例；
• 图负责关系和整体，文字负责判断与过渡，表格负责精确对照，代码负责不可替代的协议细节。

交付前复核

先确认汇报合同和正文预算，再由讲述者确认故事主线，形成文字骨架与正文，最后才规划和制作视觉材料并补附件；不要从材料堆积直接长成正文，也不要从画板反推尚未想清楚的故事。交付前至少做一次“讲述者复述测试”、一次“时长与字数核对”、一次“现场讲述测试”、一次“视觉必要性检查”和一次“零上下文读者测试”。复杂或高风险方案读取 审查量表。

发现正文更像审计合同、百科全书或低层设计文档时，不要继续局部删字。回到故事主线和视觉骨架重建主文档，再把可复用细节迁到附件。