# HTML 报告规范 [返回总入口](../../SKILL.md) · [协同地图](../README.md) · [输出路由](../routing/output-mode-routing.md) · [构建规则](./report-build-rules.md) ## 一、定位 这个文件只规定一件事： - 当用户已经选择 `HTML 报告` 后，怎样把前面分析得到的内容组织成一份可视化、可保存、可分享的最终单文件交付物。 它不是另一套分析流程。 `HTML 报告` 只是最终呈现层，前面的内容仍然来自下面这些公开规则文件： - `clarification/`：判断是否需要澄清、怎样补信息、怎样做问题重述 - `categories/`：判断主领域、复杂度、方法标签 - `scenarios/`：判断从哪个现实场景入口进入 - `methods/`：决定方法链怎么走 - `risks/`：处理误用风险和翻译风险 - `routing/`：决定什么时候确认交付形式、什么时候进入 HTML 同目录 [visual-report-template.html](./visual-report-template.html) 是默认模板。 默认做法是把这份模板复制到目标输出文件后再填充内容，而不是临时重写另一份新 HTML。 除非用户明确要求换风格，否则应保留模板中的视觉系统、类名骨架、响应式布局、关系图结构和交互外壳。 具体占位填充、模块删改和编号重排规则，看 [report-build-rules.md](./report-build-rules.md)。 ### 默认构建顺序 - 先读本文件，确认固定骨架、按需模块和去重原则 - 再读 [report-build-rules.md](./report-build-rules.md)，确认占位替换、模块删改和默认不要动的壳子 - 再读 [visual-report-template.html](./visual-report-template.html) - 把模板复制到目标输出文件 - 只替换占位内容、删除不需要的按需模块、补齐关系图和表格数据 - 交付前确认没有占位残留，且页面仍是自包含单文件 HTML ## 二、进入 HTML 之前，必须先满足什么 只有下面这些前置工作已经完成，才进入 HTML： - 输入已经通过 `ambiguity-gate.md`，不再严重依赖猜测 - 该补的澄清已经补过 - 问题已经重述成可分析版本 - 主领域、复杂度、方法标签已经大致成形 - 场景入口和方法链已经选定 - 风险边界已经看过，至少没有明显误用 - 用户已经明确要 `HTML 报告` 如果这些前提还没成立，先不要硬做 HTML。 也不要为了安抚用户，先生成一份占位式、半成品或“后面再补内容”的 HTML；只要关键结构还没看清，就绝不生成报告。 ## 三、什么时候更适合 HTML 满足下面任一情况，通常更适合建议 `HTML 报告`： - 关键人物较多，关系结构复杂 - 关键事项较多，彼此之间存在明显牵制、依赖、冲突或传导 - 时间线较长，阶段变化明显 - 需要比较多条路线 - 同时涉及关系、资源、执行、阶段、沟通、控制点或接管结构 - 用户明确需要一份可保存、可分享、可视化的成品 如果问题简单、结构单一、重点只是直接给判断和下一步动作，通常文字版就够了。 ## 四、固定骨架 每一份 HTML 报告都必须包含下面四块。 固定骨架优先级高于一切可选模块。 ### 1. 报告标题区 至少包含： - 标题 - 一句话案例摘要 - 生成日期 - 主场景 - 复杂度 这一块解决的是“这份报告在看什么”。 不要在标题区塞太多分析正文。 ### 2. 核心判断区 至少包含： - 用户目标 - 当前阶段 - 核心问题或主要矛盾 - 当前最需要先解决的一件事 推荐补充： - 服务对象 - 当前关键控制点 这一块解决的是“当前局面最关键的判断是什么”。 如果这一块写不稳，后面的图和模块越多越像堆砌。 ### 3. 建议路线区 至少包含： - 当前推荐路线 - 这条路线成立的前提 - 最关键的 1 到 3 个动作 推荐补充： - 当前支点 - 底盘供给 这一块解决的是“为什么当前应走这条路，而不是别的路”。 ### 4. 下一步行动区 至少包含： - 近期动作 - 观察点 - 风险提醒 这一块解决的是“看完之后立刻能做什么、该看什么、最容易踩什么坑”。 ## 五、按需模块 下面这些模块不是每次都要保留。 只有当对应结构真实存在时，才加入。 ### 1. 关系图模块 这是复杂人物、复杂事项、复杂组织关系场景下的优先模块。 适用条件： - 关键节点达到 3 个及以上 - 判断是否成立，明显依赖“谁影响谁、谁卡谁、谁依赖谁、谁与谁联盟或冲突” - 问题不只是人物列表，而是存在关系网络、传导链、结构卡点 - 只看纯文字，很难一眼看清全局 节点可以是： - 人物 - 组织 - 事项 - 资源 - 阶段性事件 至少包含： - 节点名称 - 节点类型 - 节点在局面中的角色 - 节点之间的关系线 - 每条关系线的一句话说明 推荐补充： - 关系方向 - 关系强弱 - 当前状态，例如合作、依赖、冲突、观望、误解、阻断 - 哪个节点是当前主导矛盾的中心点 交互要求： - 节点应可点击或可点按 - 关键关系线也应可点击或可点按 - 点击后应弹出信息层、侧边信息板或浮动详情框 - 弹出信息至少要说明：对象是谁、在局面中扮演什么角色、当前关系意味着什么、这条关系为什么重要 - 如果使用少量内联 JS，应保证 HTML 仍然是自包含单文件 - 即使交互没有触发，页面上也应保留一份静态关系索引或关系说明，避免信息只藏在弹层里 展示要求： - 优先使用自包含的 SVG 或纯 HTML/CSS 结构，不依赖外部图库 - 图不是装饰，必须能帮助读者一眼看出关键中心、关键阻断和关键传导 - 节点不要堆满整页；宁可只画关键 5 到 9 个节点，也不要把次要噪音全部塞进去 - 如果关系结构是本案理解重点，关系图应放在固定骨架之后、建议路线之前或附近的高优先级位置 ### 2. 证据链模块 适用条件： - 判断高度依赖事实链、程序链、授权链 - 需要说明某个结论不是凭感觉，而是由几组证据逐步支撑 - 局面中存在“真假和平”“是否共决”“是否真正接管”“是否合法”的争议 至少包含： - 关键结论 - 支撑该结论的 2 到 5 条证据 - 每条证据对应的来源、时间点或对象 - 当前仍未确认的缺口 推荐补充： - 证据强度 - 证据之间的衔接关系 - 哪一条证据最可能被推翻 ### 3. 控制点/权力点分布表 适用条件： - 纸面关系和现实控制点不一致 - 问题核心在于谁掌握信息、预算、客户、审批、节奏、对外口径 - 需要比较名义负责人与现实控制者 至少包含： - 控制点名称 - 名义归属 - 现实掌握方 - 当前状态 - 对局面的影响 ### 4. 人物与关系清单模块 适用条件： - 关系图已经出现，但仍需要逐项补清人物角色、诉求、态度、误解点或边界 - 关系图只能看结构，仍需要一个更适合逐项阅读的说明清单 至少包含： - 人物名称 - 角色 - 诉求或在意点 - 关系类型 可选字段： - 影响力 - 当前态度 - 依赖点 - 误解点 - 边界判断 这块是“补细节”的，不是把关系图重新用文字再画一遍。 ### 5. 时间线模块 适用条件： - 阶段变化明显 - 事件顺序会影响判断 至少包含： - 阶段或时间点 - 发生了什么 - 局面因此如何变化 可选字段： - 谁受影响最大 - 哪个判断因此被修正 ### 6. 结构拆解模块 适用条件： - 表层问题和深层问题不同 - 同时存在主要矛盾和次要矛盾 至少包含： - 核心问题 - 次级问题 - 表层与深层的区分 可选字段： - 哪些问题暂时不优先处理 ### 7. 路线比较模块 适用条件： - 存在两条及以上可行路线 - 用户需要比较“最稳 / 最快 / 止损”等不同选择 至少包含每条路线的： - 路线名称 - 适用前提 - 关键动作 - 主要风险 - 预期结果 ### 8. 资源与约束模块 适用条件： - 资源配置、支点、底盘供给、承受能力是关键因素 至少包含： - 关键资源 - 当前支点 - 当前约束 - 主要风险 可选字段： - 资源缺口 - 可调配资源 - 不可碰边界 ### 9. 分区推进矩阵 适用条件： - 同一套动作不能对所有对象、区域、团队同步展开 - 明显存在成熟区/新区、老团队/新团队、旧容器/新容器 - 需要同时说明“哪里先推、哪里先稳、哪里先观察” 至少包含： - 分区名称 - 当前状态 - 适用动作 - 节奏安排 - 风险边界 ### 10. 沟通与协商模块 适用条件： - 关键突破点在表达、协商、口径设计 至少包含： - 沟通对象 - 目标 - 核心信息 - 时机建议 可选字段： - 不建议说的话 - 顺序安排 ### 11. 谈判底线/程序检查表 适用条件： - 判断高度依赖条款、程序、授权、留痕 - 需要判断所谓合作、和解、接管、授权是否真实成立 至少包含： - 要检查的条款或程序点 - 当前状态 - 底线要求 - 缺口 - 触发升级或止损的信号 ### 12. 执行计划模块 适用条件： - 重点不是理解局面，而是推进落地 至少包含： - 第一步做什么 - 近期节奏怎么安排 - 如何观察反馈并调整 可选字段： - 24 小时 / 7 天 / 30 天拆分 ### 13. 组织换挡/接管前后对照表 适用条件： - 重点在于组织换挡、承接、接管、新旧系统转换 - 需要看清旧规则、旧口径、旧分工和新安排之间的差异 至少包含： - 维度，例如目标、规则、角色、控制点、口径、节奏 - 换挡前状态 - 换挡后状态 - 当前风险 ### 14. 方法出处模块 适用条件： - 本次分析实际调用了明确方法 - 展示出处确实有助于用户理解，而不是增加负担 展示方式： - 用接近“参考文献”的轻量列表，不用大块卡片 - 建议控制在 1 到 5 条 - 同一篇文章如果贡献了多个点，尽量合并到同一条里 - 统一放在最末尾，不抢正文层级 至少包含： - 原文标题 - 一句话说明这篇文章在本次分析中贡献了什么方法 推荐格式： ```text [1] 《实践论》：用于说明判断必须回到具体事实与检验。 [2] 《矛盾论》：用于界定当前主导问题与主次关系。 ``` ## 六、内容来源对齐 HTML 不是凭空写出来的。 不同模块的信息来源，应尽量和前面的分析链路保持对齐： - 标题区、核心判断区： 主要来自 `problem-restatement.md`、`problem-taxonomy.md` - 建议路线区： 主要来自 `methods/` 的方法链与 `scenarios/` 的场景入口判断 - 关系图模块、人物与关系清单模块： 主要来自澄清阶段、场景判断、方法分析里沉淀出来的关键对象关系 - 证据链模块、控制点/权力点分布表、谈判底线/程序检查表： 主要来自 `investigation.md`、`core-contradiction.md`、`alliance-boundaries.md`、`communication-calibration.md` - 分区推进矩阵、组织换挡/接管前后对照表、执行计划模块： 主要来自 `stage-judgment.md`、`forces-resources.md`、`execution-routes.md`、`review-loop.md` - 时间线模块： 主要来自澄清阶段拿到的事件顺序与阶段变化 - 风险提醒： 主要来自 `risks/` 和运行期误用检查 - 是否进入 HTML： 由 `output-mode-routing.md` 决定 ## 七、模块去重规则 这是必须严格遵守的规则。 加入关系图、证据链和控制点表后，更要防止信息重复。 统一遵守下面原则： - 固定骨架先写清，再决定需不需要额外模块 - 每个模块都应承担不同职责，不能只是换个样子重复同一句话 具体去重要求： - `核心判断区` 已经说明目标、阶段、核心问题、第一要务后，`结构拆解模块` 不要逐字再写一遍；它应补“表层/深层、主/次”的层次差异 - `关系图模块` 负责看全局结构；`人物与关系清单模块` 只补角色、诉求、态度、边界，不要把每一条关系线再完整复述一遍 - `证据链模块` 负责说明“为什么这样判断”；`控制点/权力点分布表` 负责说明“关键控制点落在哪”；两者不要把同一批事实重复抄写 - 如果某个事件已经在 `关系图模块` 里作为节点出现，`时间线模块` 不必再次长篇介绍它本身，而应重点写“它如何改变局面” - `建议路线区` 负责当前主路线；`路线比较模块` 负责比较备选路线，二者不要把同一条路线的介绍写两次 - `资源与约束模块` 负责支点、底盘和约束；`分区推进矩阵` 负责不同分区怎么推，不要把同一组资源说明重复写两遍 - `谈判底线/程序检查表` 负责条款、程序、授权、底线；如果这些信息已经在 `证据链模块` 里被完整展开，就只保留更适合落地的一种 - `下一步行动区` 负责近期动作和观察点；`执行计划模块` 负责更长节奏的拆分，二者不要简单复制同样的动作列表 - `组织换挡/接管前后对照表` 负责新旧系统对照；如果 `控制点/权力点分布表` 已经能完整承担这件事，就不要两张表都把同一字段列一遍 - `方法出处模块` 只交代来源，不再复述正文已经讲过的全部方法逻辑 删除规则： - 如果某个可选模块里的信息，全部都能被固定骨架覆盖，就删掉这个模块 - 如果 `关系图模块` 已经足够清楚，且人物清单只是在重复图上已有信息，可以不保留人物清单 - 如果 `证据链模块` 已经能说明授权、程序和底线，且不涉及正式协商场景，可以不再额外保留程序检查表 - 如果只调用了 1 条方法来源，就只保留 1 条出处，不要机械保留多个占位项 ## 八、展示规则 - 必须是自包含 HTML，方便直接打开和分享 - 优先保证结构清楚，再考虑视觉效果 - 先给判断，再给结构，再给行动 - 适配桌面和移动端 - 文字必须清楚可读，不能靠过轻颜色或过浅底色硬撑风格 - 可以有红专风，但不能为了“气氛”牺牲可读性 - 模块边界要清楚，不要所有卡片都做成同一种圆润小块 - 报告的用户可见层文案必须跟随正文语言；正文是中文时，封面标识、`section-index`、模块名、表头、按钮、提示语、通用字段名默认全部使用中文 - 不要在中文报告里保留 `Fixed Core`、`Relation Graph`、`Rollout Matrix`、`Communication` 这类模板英文壳层文案 - 案例本身的专有名词、职位缩写、方法缩写可按实际需要保留，例如 `CEO`、`CFO`、`COO`、`MVP`；但它们不应替代通用模块标题 - 关系图、控制点表、程序检查表都要保证移动端可读 - 如果启用关系图交互，移动端点击区域也要足够大 ## 九、输出文件规则 默认输出位置： - 用户当前工作目录 - 如果用户明确指定目录或文件名，按用户指定路径输出 - 不要把最终用户报告写回本目录 - 最终用户报告应来自模板副本，而不是直接覆盖 `visual-report-template.html` 建议文件名采用： ```text YYYY-MM-DD-topic.html ``` 命名要求： - 日期在前 - 主题在后 - 名称简短、可检索 ## 十、交付前自查 正式交付前，至少检查下面这些点： - 固定骨架是否完整 - 是否只保留了真正相关的可选模块 - 默认模板骨架是否仍然完整，没有被无意改成另一套页面 - 关系图是否真的能帮助理解，而不是装饰 - 如果关系图可点击，节点和关系线是否都能正常弹出信息 - 证据链、控制点表、程序检查表之间是否存在明显重复 - 方法出处是否已经改成轻量参考文献式 - 是否删掉了所有占位文字 - 是否删掉了所有 `可删` 提示，并把编号顺序调直 - 是否仍然是自包含单文件 HTML ## 十一、不要这样写 - 不要把所有案例都写成同一份长模板 - 不要要求每份报告都有人物图、时间线、路线比较 - 不要在事实不清时硬做可视化 - 不要绕开默认模板，从空白文件重新拼另一套大而全页面 - 不要把模板中的整体 CSS、类名骨架和交互壳子随手重写掉 - 不要把关系图画成只有节点、没有关系含义的装饰图 - 不要把人物清单做成关系图的重复抄写 - 不要把证据链、控制点表、程序检查表三张都写成同一套事实的重复排列 - 不要把方法出处做成抢戏的大块说明卡 - 不要用视觉复杂度掩盖判断不清