分析写作工作流

术-内容 · 术层 skill 全文

本页是 <code>rules/skills/workflow_analytical_writing.md</code> 的逐字投影（仅隐私清洗，零改写）。

分析写作工作流

元数据

• 类型: Workflow
• 适用场景: 将调研素材转化为有判断力的 external-facing 分析文章
• 前置依赖: 深度调研工作流（workflow_deep_research_survey.md）的 Phase 1-3 产出
• 创建日期: 2026-04-28
• 最后更新: 2026-04-28

何时使用

当深度调研完成（Phase 1-3 的事实采集和验证已结束），需要从"已验证的素材"走到"有判断力的文章"时，加载本 skill。本 skill 解决的核心问题是：调研素材充分但写出来像 AI 汇总，缺乏作者的分析视角和判断框架。

与深度调研 skill 的关系：深度调研 skill 管信息采集和验证（Phase 1-3），本 skill 管判断合成和写作（Phase A-E）。深度调研 skill 的 Phase 3.5-4 中关于 reader mode 和写作的内容已迁移到本 skill，调研 skill 在 Phase 3 完成后指向这里。

internal mode 文章（面向自己或共享上下文的协作者）通常不需要完整执行本 skill。internal mode 的价值是帮对方更快做判断，不需要叙事重构和族谱追溯。直接从 Phase D 开始，写清结论、依据和未决问题即可。

Thesis Catalog：核心分析视角

以下是作者反复使用的判断框架。写 external 文章时，先扫描这个列表，识别哪些视角与当前话题相关。通常一篇文章会用到 1-3 个视角的组合。

L1: 反馈闭环判断

一个系统的能力天花板取决于它能否感知自身输出并自我修正。AI 系统中最关键的不是模型智能，而是模型能否看到自己行为的后果。闭环完整的系统可以自我迭代，闭环缺失的系统只能依赖人类补位。

对应 axioms: A02（放大器）、A04（可靠性是管理问题）、M01（闭环校准）

典型应用: 创意 AI 三代演化（Generation 1 无法看到渲染结果，Generation 3 通过截图闭环）、Agentic AI 部署危机（代码能跑但不知道对不对）、UE-bridge 设计（核心是 viewport screenshot feedback）

触发条件: 分析对象涉及 AI 系统的可靠性、自动化程度、或"为什么 demo 很好但实际用不了"

L2: 瓶颈迁移判断

当某个环节的成本急剧下降时，系统瓶颈会转移到下一个最慢的环节。优化已经不是瓶颈的环节没有意义。在 AI 领域，代码生成成本趋零后，瓶颈转移到验证、判断和品味。

对应 axioms: X03（效率由瓶颈决定）、T05（认知是资产，代码是消耗品）

典型应用: AI 编程范式转变（编码便宜后测试成为瓶颈）、创意 AI 结论（执行摩擦消除后竞争优势转向品味）、Context infrastructure（模型智能跨过门槛后 context 成为瓶颈）

触发条件: 分析对象声称"让 X 变得更快/更便宜/更容易"时，追问瓶颈转移到了哪里

L3: 共识天花板判断

LLM 的默认输出是共识（consensus）。训练机制（next token prediction + RLHF 安全对齐）决定了 LLM 回归均值。差异化和深度来自注入非共识的个人上下文，不来自换更好的模型。Deep Research 其实是 Wide Research。

对应 axioms: context infrastructure 博客的核心论点、A10（熟悉度胜过原始智能）

典型应用: Context infrastructure（两份报告的对比实验）、harness engineering 调研（有 context 和没 context 的对比）、对 Deep Research 产品的批判

触发条件: 分析对象涉及"AI 能不能做 X"的能力边界讨论，或者任何 AI 产出质量的评估

L4: 技术族谱追溯

任何新发布都不是凭空出现的。追溯它的前几代可以定位它在演化轨迹上的真实位置，区分"真正的新东西"和"已有路径的产品化"。通常分成 2-4 代，每代解决了前一代留下的核心问题。

对应 axioms: M06（连接胜过孤立知识）、A13（技术采用三阶段）

典型应用: 创意 AI 三代（脚本 → 协议 → 闭环）、MCP 演化（研究协议 → 工程现实碰撞 → 方言分裂）、CLI-Anything 定位（第二代到第三代的桥梁）

触发条件: 分析对象是一个新发布的产品/技术/标准，需要定位它在演化中的位置

操作方法: 第一步，识别前几代：这个东西要解决什么问题？在它之前人们怎么解决？前一代的核心局限是什么？第二步，画出代际演化线：每代解决了什么、留下了什么。第三步，定位当前对象：它解决了哪一代遗留的问题？它本身又留下了什么新问题？第四步，判断演化的下一步：基于当前遗留问题，下一代可能长什么样？

L5: 叙事与现实的偏差

媒体/厂商叙事通常聚焦在错误的维度上。文章的核心工作是把读者的注意力从叙事聚焦的维度重定向到真正重要的维度。这个重定向本身就是文章的 thesis。

对应 axioms: T04（数据优于观点）、V02（可验证性是信任的地基）

典型应用: 几乎每篇 external 文章都有这个动作。创意 AI（叙事聚焦"AI 能做设计了"，实际瓶颈是反馈闭环）、Manus（叙事聚焦"全自动 AI agent"，实际问题是验证和可靠性）、Claude Design vs Figma（叙事聚焦"竞争"，实际是两个不同用户群）

触发条件: 几乎总是需要。问自己：关于这个话题，大多数人的第一反应是什么？这个第一反应遗漏了什么？

操作方法: 第一步，提取主流叙事：媒体/社交网络/厂商对这个事件的主要解读是什么？第二步，识别叙事聚焦的维度：这个解读把注意力放在了哪个维度上？第三步，识别被忽略的维度：这个解读遗漏了什么？哪些维度对判断实际影响更关键？第四步，构造重定向：文章的 thesis 就是这个重定向——"你以为重点是 X，其实关键是 Y"

L6: 执行摩擦消除后的价值重分配

当工具消除了执行层面的摩擦，竞争优势从"谁执行得快"转移到"谁的判断更好"。工具掌握的价值下降，品味和方向感的价值上升。这是 L2 在人的维度上的具体应用。

对应 axioms: T05（认知是资产）、A02（AI 是放大器不是替代品）

典型应用: 创意 AI 结论段（执行摩擦消除后创意方向和审美品味成为核心）、AI 编程成本结构分析、Context infrastructure 博客（context 的价值上升，模型智能的价值下降）

触发条件: 分析对象涉及"AI 让某类工作变简单了"时，追问价值转移到了哪里

Phase A: 视角匹配

输入: 调研 Phase 1-3 的产出（scratchpad、验证过的 claim、来源索引）

操作:

1. 扫描 Thesis Catalog（上面的 L1-L6），逐个检查与当前话题的相关性。标注为：强相关（将成为论证主线）、辅助（支撑某个论点但不是主线）、不相关。
2. 搜索作者已有的相关写作。在 contexts/blog/、contexts/survey_sessions/、rules/axioms/ 中查找与当前话题直接相关的已有文章、调研和公理。记录具体的文件路径和相关段落。
3. 检查作者在对话中是否提到了自己的相关思考或已有文章。如果有，这些是 thesis 的最强锚点。

输出: 写入 scratchpad 的 ## Analytical Lens Selection：

## Analytical Lens Selection

主线视角: L4（技术族谱） + L5（叙事偏差）
辅助视角: L1（反馈闭环）、L2（瓶颈迁移）
不相关: L3（共识天花板）、L6（价值重分配）

已有相关写作:
- contexts/blog/content/agentic-ai-crisis.md — 反馈闭环论点的原始阐述
- axioms/x03 — 瓶颈迁移的通用框架
- 用户在对话中提到：[具体引用]

Phase B: 技术族谱追溯

触发条件: Phase A 中 L4（技术族谱）被标注为强相关或辅助时执行。如果不相关，跳过。

操作:

1. 基于调研素材，识别当前事件之前的 2-4 代前身。每一代需要回答：它解决了什么问题？它的核心局限是什么？它和下一代之间的断裂点在哪里？
2. 画出代际演化线，确认每代之间的因果链：前一代的局限直接催生了下一代的核心设计。
3. 定位当前事件在演化线上的位置：它解决了哪一代遗留的问题？它本身又会遗留什么？

输出: 写入 scratchpad 的 ## Genealogy，包含代际表格和演化判断。

Phase C: 叙事重构

操作:

1. 提取主流叙事: 基于 Tier 1-2 来源和媒体报道，总结大多数人对这个事件的第一反应。用一句话写出来。
2. 识别叙事聚焦的维度: 这个主流叙事把注意力放在了哪里？它隐含的假设是什么？
3. 识别被忽略的维度: 基于调研中的 Tier 3-4 证据和 Phase A 选中的分析视角，哪些维度对判断实际影响更关键但被主流叙事忽略了？
4. 构造 thesis: 文章的核心论点就是这个重定向。用一句话写出来：大多数人认为 [X]，但实际的关键在于 [Y]，因为 [证据/机制]。

注意: 不是每篇文章都需要"反驳"主流叙事。有时主流叙事是对的但不够深，文章的工作是"把它推深一层"而不是"翻转方向"。thesis 的形式可以是重定向、深化、补充缺失维度，不必一定是对立。

输出: 写入 scratchpad 的 ## Narrative Reframe。

Phase D: Thesis 成型与骨架

操作:

1. 综合 Phase A-C 的产出，写出完整的 thesis statement（2-3 句话）。这个 thesis 必须满足：能被一个不了解细节的聪明人理解，包含具体的判断（不是"这很复杂需要关注"），指向一个读者可以在其他场景复用的判断框架。

1. 决定 reader mode 和时间维度（从深度调研 skill 迁移过来的判断）：
• mode: internal 或 external
• 目标读者是谁
• 时间维度判断：短期相关性 / 长期意义 / relevance 判定

1. 设计论证骨架：用 3-5 个要点列出论证路径。每个要点标注它使用了哪个分析视角（L1-L6）以及它的证据来源（哪些 Tier 3-4 证据支撑这个论点）。

1. 做穿透检查：
• 每个主要正面判断是否至少有一个 Tier 3+ 的独立证据源？
• 时间维度判断是否会在 opening 中被正面表达？
• demo 和实际使用场景是否被区分了？
• 骨架读起来像"作者基于自己框架写的分析"还是"AI 搜了一圈写的摘要"？

输出: scratchpad 的 ## Thesis & Skeleton。

Phase E: 写作

动笔前必读: rules/COMMUNICATION.md。不是写完回来对照检查，是动笔前把规则装进来。事后补丁只能抓字面关键词（破折号、"结构性"），抓不到居高临下推荐语、英文 metaphor 直译、"很+形容词+冒号"句式。动笔前装进来，句子从一开始就是对的。如果产出包含中英文两个版本，英文版翻译完成后必须回头逐段自查 COMMUNICATION.md 中的译文体规则（被动语态直译、expensive/cheap 的抽象用法、model/framework 的狭义错位、承接词缺失等）。翻译是译文体最高发的场景，写完中文版觉得"风格已经对了"不代表翻译后仍然对。

控制 cognitive burden（参见 axiom M11）。读者在任何一段里同时接收的新概念不超过两个。如果一段需要引入新术语或新框架，先用一个读者已有的场景或体感把它接住，再给名字。不要连续三段都在引入新概念而不给读者消化的空间。判断标准：把文章读给目标读者画像里的人听，如果他在某一段开始走神或回翻，大概率是那一段的新概念密度太高了。

共享格式要求:

• 中文 Markdown
• 所有引用用绝对链接（https:// 开头），不用相对链接
• 关键引用保留原文摘录
• 重要来源直接进入正文的 inline Markdown links，不只堆在文末

External mode 写作要点:

1. 先让陌生读者知道"它是什么，以及为什么和我相关"。opening 从读者能直接感知的现象切入，不从技术术语入手。判断标准：把 opening 读给非本领域的聪明人听，如果第一段就皱眉"这是什么"，换切入点。

1. 如果 Phase D 的时间维度判断是"短期不太相关，长期可能重要"，opening 必须正面传达这个判断，不要用案例堆叠制造虚假紧迫感。

1. 优先传达直觉而不是技术细节。文章目标是让读者带走一个可复用的判断框架，不是记住具体数据。技术细节只在三种情况值得展开：(a) 它是直觉的关键证据，没有它读者会怀疑判断；(b) 读者本来就熟悉这个技术语言，展开比抽象更省理解成本；(c) 它本身就是文章主题。判断标准：把文章读给一个行业相邻但不在这个技术栈里的从业者听，如果他能复述核心直觉但记不住具体数字，说明比例对了。

1. 分析框架是 internal 工具，不进入成品。 Thesis Catalog（L1-L6）、axiom 编号、Phase 名称、"叙事重构"这类术语，全部属于写作过程的脚手架，不能出现在最终文章里。读者应该感受到的是一个有自己思考方式的人在做分析，不是一个框架在被套用。具体来说：不要写"从技术族谱的角度看"，直接写三代演化的事实；不要写"这里的瓶颈发生了迁移"，直接写代码变便宜之后验证成了最慢的环节；不要引用 axiom 编号或名称。框架指导你怎么想，但读者看到的只有想出来的结果。

Internal mode 写作要点:

• 让读者更快做判断
• 先把最影响决策的结论和依据显出来
• 把仍未确认的点与下一步动作留清楚

Survey report 与博客文章的区别：本 workflow 的默认产出是 survey report，存放在 contexts/survey_sessions/。不是博客文章，不要加 Pelican frontmatter 或 Kit 订阅 script。如果用户要求发布到博客，单独复制到 contexts/blog/content/ 并加 frontmatter。

交付终点：写完最终 MD 文件即为交付终点。不要自动执行发布流程。只有用户显式要求时，才按对应的 skill 流程执行。

常见失败模式