# 输出模式路由规则

[返回总入口](../../SKILL.md) · [协同地图](../README.md) · [轮次结构](../clarification/round-response-structure.md) · [模糊输入识别](../clarification/ambiguity-gate.md) · [防漂移规则](../clarification/focus-anchor.md) · [HTML 规范](../html-output/visual-report-spec.md)

## 一、文件作用

这个文件只规定四件事：

1. 什么时候不能直接进入正式输出
2. 什么时候仍处在澄清阶段，不能问用户要文字版还是 HTML 版
3. 在正式输出前，什么时候需要先确认交付形式
4. 用户选择 `深度分析` 或 `HTML 报告` 后，应该怎么落地

定位提醒：

- 这是最后一公里，不是另一层分析入口。
- 进入这里之前，默认已经完成澄清、问题重述、场景选择、方法判断和必要的风险检查。
- 不要在这里回头重做场景判断、方法展开或澄清追问，除非前面明显失效。

## 二、基本规则

- `澄清` 是前置流程，不是正式输出模式。
- 这个 skill 一旦触发，所有任务都先走澄清，不存在跳过澄清直接正式分析的入口。
- 这个 skill 的正式输出模式只保留两种：
  - `深度分析`
  - `HTML 报告`
- 在正式输出完整内容前，统一确认一次用户要哪种形式。
- 正式输出前后的轮次回复，仍默认沿用 `背景信息 / 主体结构 / 当前进度` 三段骨架；到正式输出时，主体应转为完整分析本身。
- `当前进度` 默认只写 `当前阶段 / 当前关注 / 下一步`，不把内部场景/方法路由当成固定外显字段。
- `深度分析` 和 `HTML 报告` 使用同一套内容骨架，区别主要在呈现形式。
- 内容骨架以 [visual-report-spec.md](../html-output/visual-report-spec.md) 的固定骨架和按需模块为准。
- 默认交付的是拆局分析本身，而不是微信措辞、聊天回复、温和版/强硬版等表达细节。
- 如果用户后来明确要这些表达细节，也只能作为正式分析之后的附加模块，不能反过来替代分析本身。
- 如果问题还没有澄清闭合，就还没有资格进入“输出模式选择”。
- 如果用户已经提到 `HTML`，或当前问题天然容易让用户期待最终会出 `HTML 报告`，那么只要还在澄清阶段，每轮回复都要做简短预期管理，明确说明“当前信息仍不足以生成 HTML，补齐关键结构后再进入正式输出”。
- 如果问题偏长、偏复杂、用户一次问了多个问题，正式输出前还必须回扣 `主问题锚点`，不要只按当前叙事惯性写成长文。
- 如果问题偏长、偏复杂、用户一次问了多个问题，正式输出前还必须补过 `原始问题对照 + 案件工作单 + 输出前答题校验`。

## 三、标准路由顺序

按下面顺序执行：

1. 先确认用户目标。
2. 再进入 `clarification/`，按轮次逐步把关键结构问开。
3. 每轮答完后，重新判断是否还缺关键结构。
4. 只有在问题已经能稳定重述后，才进入方法、场景、风险分析。
5. 先完成内容判断，但先不要把完整成品直接输出。
6. 如果问题偏长或多问并行，先回看 [focus-anchor.md](../clarification/focus-anchor.md)，确认目标、主问题、原始问题对照和案件工作单没有漂移。
7. 先做一次 `输出前答题校验`，确认没有漏题、串题或把传闻写成定论。
8. 在澄清已经闭合的前提下，再确认用户要 `深度分析` 还是 `HTML 报告`。
9. 如果用户要 `HTML 报告`，按 `visual-report-spec.md` 在用户当前工作目录输出 HTML，并在关系结构复杂时优先考虑关系图模块。
10. 如果用户要 `深度分析`，用文字方式输出同一套内容骨架。

## 四、什么时候不能直接正式输出

出现下面任一情况，先不要进入正式输出：

- 目标不清楚
- 关键事件不清楚
- 关键人物不清楚
- 时间线严重混乱
- 如果直接分析，会大量依赖猜测
- 关键权利、信息、资源、对外主体或并行容器仍不清楚
- 问题属于复杂多方问题，但结构还没展开
- 目标还没锁

这时先走澄清流程。

## 五、什么时候还不能问用户要文字版还是 HTML 版

下面这些情况，即使已经问过一两轮，也还不能进入“正式输出前确认形式”：

- 关键人物还没问齐
- 关键事件链还没对齐
- 共同决策、信息流、客户、合同、现金流、对外主体等关键结构还没问清
- 已经出现新容器、新公司、新系统的信号，但关系还没展开
- 当前仍说不清用户到底要推进、修复、止损、退出还是只是判断局面
- 当前输出正在滑向聊天措辞、微信表达、强硬版/温和版等细节，而主分析还没成形

这时正确动作只有两种：

1. 继续澄清
2. 先给出“目前已确认的结构 + 仍待确认的关键缺口”，明确说明现在还不能正式展开深度分析或 HTML

不要在这种状态下说“我已经把正式分析内容整理好了，请问你要文字版还是 HTML”。
也不要说“我下一条就给你出 HTML”或任何会让用户误以为报告已具备生成条件的话。

如果 `原始问题对照` 还是空的，或 `案件工作单` 还主要靠猜，也同样不能进入正式输出。

## 六、正式输出前，先确认交付形式

默认规则是：

- 只有在澄清已经闭合、内容判断已经成形后，才确认用户要不要 `HTML 报告`。
- 如果问题偏长、偏复杂或多问并行，还要先通过 `输出前答题校验`。

推荐问法：

```text
我先把局面和判断基础梳理清楚了。正式展开前我确认一下：你要我直接给你文字版深度分析，还是整理成一份 HTML 报告？
```

补充规则：

- 如果用户之前已经明确说过要 `HTML`，这一轮可视为已确认。
- 如果用户没有明确说过，就在最终输出前补这一次确认。
- 如果用户明确指定了输出目录或文件名，按用户指定路径输出；否则默认输出到用户当前工作目录。

## 七、用户选择 `深度分析` 时怎么输出

用户如果不要 `HTML`，就输出 `深度分析`。

这里的 `深度分析` 不是另一套内容框架。它应当：

- 使用与 `HTML 报告` 相同的内容骨架
- 仍沿用 `背景信息 / 主体结构 / 当前进度` 三段结构
- 保留固定骨架
- 按问题结构启用需要的模块
- 用纯文字形式完成表达

换句话说：

- `深度分析` 是文字版
- `HTML 报告` 是可视化版
- 内容逻辑应保持一致

如果用户原始输入里有编号问题，默认沿用原编号回答。  
如果某些题仍只能部分回答，要明确标出“部分回答”或“仍待确认”，不要写成一篇看似完整、却没有逐项回应的长文。

如果用户没有明确要求，不要默认把 `深度分析` 降成：

- 微信消息草稿
- 聊天回复润色
- 温和版/强硬版措辞
- 单句发言模板

如果问题偏长或多问并行，正文开头最好先补两句：

- 这轮先回答哪 `1` 到 `2` 个问题
- 哪些问题暂不展开或仍待确认

正式输出时，三段结构保持完整，推荐做法是：

- `背景信息`：继续作为结构底稿，但不要写成长摘要
- `主体结构`：转为正式分析
- `当前进度`：继续写阶段、当前关注和下一步

## 八、用户选择 `HTML 报告` 时怎么输出

用户如果要 `HTML`，就输出 `HTML 报告`。

进入 HTML 时：

- 按 [visual-report-spec.md](../html-output/visual-report-spec.md) 的固定骨架组织内容
- 再按问题结构选择需要的模块
- 如果判断高度依赖人物、事项、组织之间的关联，优先加入关系图模块
- 保持自包含，方便直接打开和分享
- 默认文件名使用 `YYYY-MM-DD-topic.html`，默认输出到用户当前工作目录，而不是写回 skill 模板目录

如果问题事实仍不够清楚，先不要硬做 HTML，先回澄清或补判断。

## 九、对用户的表达口径

内部可以先完成分类、场景、方法、风险判断，但默认不要把内部路由语言直接写给用户，例如：

- `按这个 skill 的框架`
- `主入口会落在……`
- `次入口是……`
- `起手方法会是……`
- 一串 reference 文件名

正式对用户输出时，更好的顺序是：

1. 先说目前已经确认的局面结构
2. 再说哪些关键位置还没问清，或已经足够进入正式分析
3. 如果用户提过 `HTML` 或明显在等待成品，补一句预期管理：当前还不能生成 `HTML 报告`，等关键缺口补齐后再做
4. 如果问题偏长，先交代“这轮先回答哪些问题”
5. 再给正式判断和路线
6. 只有用户明确追问 skill 机制时，才补内部路由解释

如果用户给了聊天记录、会议话术、微信片段等细节材料，更好的默认处理是：

1. 先把它们当证据材料，而不是立刻当交付目标
2. 先回到目标、结构、角色、控制点和路线
3. 只有在正式分析后，用户明确要表达版本时，再下沉到措辞层

例如，不要在 `主体结构` 里直接说：“按这个 skill 的框架，主入口会落在关系边界，次入口是团队治理，起手方法会是……”。
更自然的做法是：

- 在 `当前进度` 里写：`当前阶段：澄清；当前关注：先看清共同决策、信息流和外部主体是不是已经分开；下一步：补齐这些结构位后再决定是否进入正式分析`
- 在 `主体结构` 里直接说人话：“现在最需要先看清的是共同决策、信息流和外部主体是不是已经分开。如果这几件还没问清，我先继续补问题；如果已经看清，再正式给你判断和路线。”

## 十、什么时候更适合建议 HTML

下面情况通常更适合建议 `HTML 报告`：

- 关键人物较多，关系结构复杂
- 关键事项较多，彼此之间存在依赖、冲突、卡点或传导链
- 时间线较长，阶段变化明显
- 需要比较两条及以上行动路线
- 问题同时涉及关系、资源、策略、执行等多层结构
- 用户需要一个可保存、可分享、可视化的交付物

如果局面简单、结构单一、重点只是给出判断和下一步动作，通常文字版就够了。

## 十一、出处展示规则

无论是 `深度分析` 还是 `HTML 报告`，都可以在答案末尾附“方法出处”或“相关原文”，但要满足：

- 出处和本次实际调用的方法有关
- 数量受控，不堆砌
- 放在最末尾，不打断主体分析

## 十二、最终判断原则

如果拿不准，就按下面优先级处理：

1. 先保证问题被澄清
2. 再保证内容判断完整
3. 再保证 `输出前答题校验` 已通过
4. 然后确认用户要文字版还是 HTML 版
5. 最后按用户选择交付

换句话说：

- 先把局面问清楚
- 再把内容想清楚
- 再确认没有漏答和跑偏
- 最后再决定交付形式