# 1. 流程改造

## 流程改造尝试

### 第一次，写作流程提纲评审阶段的尝试

```md
# 评审环节改造：信息材料抽取初稿

## 1. 材料定位

这是本篇文章的原始材料之一，记录“文章提纲评审流程为什么需要改造”。它不是正式立意，也不是文章提纲，而是把 CCPE 侧和 Writing 侧四份完整讨论记录压缩成一份可继续讨论的材料。

这次改造不是凭空设计一个多 Agent 系统，而是从旧写作经验中长出来的。过去在单智能体环境中，用户会把提纲同时发给张辽、认知显影、巨人认知，让三者评审；得到三份评审结果后，用户汇总、写应对策略，再交给韩愈修复。若改动小，韩愈直接输出新提纲；若涉及立意调整或大漏洞，韩愈先出修订计划，讨论一致后再输出新提纲。这个流程可以多轮循环，直到用户确认提纲可进入正文。

旧流程真正复杂的地方不只是“有三个评审员”，而是会话状态。张辽不只是 report-only 的红队，它还可能和用户继续对话，形成补充判断；认知显影和巨人认知大多作为专业检测器，只输出报告；韩愈通常需要保持较长连续会话，因为它负责立意、提纲生成和修复。用户是否重启会话，取决于会话是否太长、是否出现幻觉、或某轮评审中加入的特殊侧重点是否会污染后续。

## 2. 最初的改造入口：先抽提纲评审小闭环

最初的判断是：深度创作中，提纲阶段成本最高、最决定文章命运，所以可以先把“已有初稿提纲进入评审”抽成小闭环验证。这个小闭环包括：当前提纲、上一版提纲、上一轮评审报告、用户修复说明、本轮评审目标；Runtime 负责生成 context pack、分发给评审员、收集 report、综合修复建议、等待用户决策。这个设计的合理性在于它先解决最痛的环节，而不是一开始就做完整文章生产 Runtime。

但讨论很快暴露出一个更深的问题：真实写作并不常从“已有提纲”开始。正常流程是从观点素材开始，先由韩愈看立意和切入，再生成初稿提纲。如果素材压缩和拆分等到提纲评审阶段才做，韩愈在立意和提纲生成时就只能依赖用户一句“观点在哪儿”，后面的提纲和评审都会建立在不完整上下文上。因此标准入口被前移：观点素材文件 -> 上下文工程 -> premise-context-pack -> 韩愈立意 -> 用户确认 -> 韩愈 outline-v1 -> 提纲对齐上下文 -> 评审。

这个前移很关键。它说明流程改造不是为了“评审阶段更复杂”，而是为了把材料工程放到主笔立意之前，避免评审阶段才发现上下文基础不稳。

## 3. 上下文工程：从一股脑塞素材到多层材料视图

旧工作流大量依赖 Gemini 的超长上下文，用户可以把二十万字材料、过往文章、研究报告和提示词一股脑放进去。Codex 的上下文窗口更小，同时多 Agent 流程也不适合让每个角色都读全文。于是讨论提出了“面向文章用途的结构化压缩”。

最初的结构是四层：L0 Raw Sources 保持在 knowledge-vault 或 source-map 指向位置；L1 Source Digest 为每份材料生成面向当前文章的摘要，标出核心观点、可用段落、反方处理、不可用内容、读者可见性；L2 Outline-Aligned Context Pack 按提纲点对齐材料，列出核心观点、讨论摘要、论据、例子、可引用材料、禁止展开内容；L3 Agent Dispatch Pack 给韩愈、张辽、认知显影、巨人认知分别裁剪上下文。

这里形成了 Outline Context Architect 的角色。它不应塞进韩愈本体，因为用户未来还有其他主笔风格；上下文工程应是可复用能力。韩愈只需要输出稳定提纲编号、核心命题和材料需求提示；真正的 source digest、premise pack、outline-aligned context、补充素材影响判断，交给上下文架构角色。

后来角色边界进一步澄清：Outline Context Architect 接管上下文工程层，但不是总项目经理。主会话里的 Runtime Operator / Article Production Orchestrator 负责项目控制、状态、决策门、调度、综合和 repair-request；上下文子会话负责材料压缩与上下文包；韩愈作为主笔子会话贯穿立意、提纲生成、提纲修复；张辽建议跨轮保持，因为用户常与它对话；认知显影和巨人认知默认 report-only，可按需跨轮保持。

## 4. 三国测试：为什么旧项目被判定无效

Writing 侧用 `2026-06-04-Sanguo-temp-slug` 做过一次测试。它一开始计划从已有提纲进入评审，但实际很快改为从观点素材开始：用户提供 `社会学讨论.md`，让韩愈先给核心立意和切入方向；用户确认方向后，再让韩愈生成 `outline-v1.md`。这一步还暴露了提纲阶段的附录准备问题：如果概念标星在提纲阶段丢失，正文完成后再生成附录会很困难，所以提纲里需要保留“概念标星服务附录脚手架”的规则。

测试进入评审机制时，旧单智能体流程被重新描述：三位评审员分别评审，用户综合意见，再交韩愈修复；张辽可能继续对话，认知显影和巨人认知多为报告型；评审员需要保留自己的会话，以便下一轮检查上一轮问题是否被修复。

真正的失败发生在用户追问“张辽的原始提示词、发送指令和直接回复分别是什么文件”时。检查发现，`dispatch-pack.md` 只是主会话里的任务说明，并没有包含或严格引用完整 canonical prompt 的启动方式；所谓张辽 report 实际是主会话读取张辽 prompt 的一部分后模拟生成的。随后确认：韩愈、Outline Context Architect、张辽、认知显影、巨人认知，在那一轮都不是独立 agent 实例执行，而是主会话读取文件/约束后生成对应文件。

这使整个测试失效。因为用户要验证的是多智能体评审机制，而不是单模型主会话内角色扮演。尤其三位评审员要求独立视角，用主会话模拟就不符合预期。旧项目因此被删掉；其中只有用户输入材料有原始价值，其余模拟产物没有测试价值。

## 5. 从 dispatch pack 到 Agent Invocation Packet

三国测试暴露出的关键接口问题是：`dispatch-pack.md` 不能等同于 agent 启动包。合格的启动包至少要说明 canonical prompt 路径、是否需要粘贴完整 prompt、本轮任务、输入文件、输出格式、会话连续性、角色完整性要求，并明确它是给 orchestrator 看的索引，还是可以投递给 agent 的完整启动内容。

如果参与者在 Gemini / GPT / Claude 等外部平台运行，还必须生成 `prompt-to-send.md`，里面包含 canonical prompt、本轮任务、上下文包和输出要求。CCPE System 因此补充 Agent Invocation / Dispatch Pack 标准，也就是后来的 `agent-invocation-packet.protocol.md`。Writing Workbench 的职责是在具体项目里消费 CCPE canonical agent，生成可投递的 invocation packet 和 prompt-to-send。

随后 Writing 侧重新准备环境：读取 invocation protocol，检查 outline-context-architect、han-yu-main-writer、zhang-liao、cognitive-imaging、giant-cognition 是否有真实 invocation record；没有就生成 agent-invocation-packet；如果当前环境不能真实调用，就生成 prompt-to-send 并停止；已有模拟输出全部标记为 `simulation-only`、`excluded-from-synthesis`、`formal_output: false`。这条 no-simulation 规则成为后续工作底线。

## 6. 真实调用边界

后续又确认了三种调用方式。第一，主会话不能把自己的输出算作 canonical agent 输出；主会话只能 orchestration：准备 packet、发送 prompt、收集真实返回、做 synthesis。第二，Codex Thread 子会话可以作为真实调用通道：为每个 canonical agent 创建独立 Thread，把对应 prompt-to-send 发进去，只要该 Thread 真正加载 canonical prompt，并返回带 invocation record 的 session/report，就可视为真实 invocation。第三，通用 sub-agent 工具也可用，但必须把 prompt-to-send 作为启动输入，并要求写明 invocation record。

因此，评审流程改造最后不是“多建一些文件夹”，而是形成了一个判断标准：正式评审报告必须来自真实独立参与者，或来自外部平台真实返回；主会话只能综合真实 report。不能真实调用时，应停在 prompt-to-send / blocked 状态，而不是补一个看似完整的 report。

## 7. 对本文可能有用的初步原则

这次改造提供了一个强反例：过度工程的表面症状不一定是目录太多、Agent 太多、协议太多；有时恰恰相反，是文件结构看似完整，但关键执行边界是假的。这样的系统既复杂，又无效。

真正的 Anti-Overengineering Gate 不应简单问“是否用了多 Agent”，而应问：

- 这个阶段是否真的需要独立角色判断？
- 角色输出是否必须有真实 invocation record？
- 上下文工程是否发生在正确时机？
- dispatch pack 是任务索引，还是可投递启动包？
- 不能真实调用时，系统是否会停止，而不是自动模拟？
- 当前复杂度是否服务于可追溯、可复盘、可裁决，而不是制造流程幻觉？

这份材料后续可以继续深挖一个核心命题：好的工程化不是把流程做重，而是让每个重环节都有真实必要性；坏的工程化不是“太复杂”，而是复杂结构没有真实执行边界。

```

### 第二次，素材提炼阶段的尝试

```md
# 素材提炼改造：信息材料抽取初稿

## 1. 材料定位

这是本篇文章的第二份原始材料，记录 `knowledge-vault` 中 `viewpoint-discussion-distillation` 的改造过程。它关注的是深度创作流程第 2 步“确定观点”：当长讨论、日记、研究材料还没有进入正式写作时，如何把它们提炼成可复用、可追溯、可下游消费的观点材料。

用户最近围绕 `2026-06-05-失望性情感隔离` 做了三次蒸馏，累计约两天、六个多小时。三次工作路径分别是：`失望性情感隔离`、`失望性情感隔离2`、`失望性情感隔离3`。这三次不是简单重复，而是一条清晰的流程改造轨迹：第一次暴露旧方法缺陷，第二次用升级机制重跑，第三次形成更成熟的层级、路由、主题文档和覆盖审计。

## 2. 第一次：chunk-first 的结构误判

第一次工作区现在被保留为旧流程样例，状态是 `legacy_pre_gestalt_misread_demo`，不再作为 material routing authority。它的问题不是没有产物，而是产物过早建立在分块视角上。旧流程先按 R01-R07 分段，让 topic-discovery-router 工作者分别提取主题，再试图把局部主题拼成整体。这种做法能产生很多 topic，但容易变成“盲人摸象”：每个 worker 都看到局部真实，却没有先确认整篇讨论的总问题、层级、主轴和模型演化线。

第一次后期曾尝试用 `01-topic-hierarchy-proposal.md` 修复平铺问题，提出 ROOT “从失望性情感隔离到认知生成与关系治理”，并把话题分为入口与边界、机制解释、认知主权、架构升级、局部深化等层。这一步已经意识到 flat topic map 不够，但它仍是补救：先切碎，再重组。对于一个本来连贯的长讨论，正确顺序应是先看整体，再切局部。

## 3. 第二次：whole-source gestalt 与结构优先

第二次工作区明确从 `Step 0: Whole-Source Gestalt Alignment` 开始，不继承旧目录的 topic map、hierarchy proposal、worker outputs 或 material routing。它的核心改变是：当源材料仍在高上下文参与者可处理范围内时，先让真实子会话读完整源材料，判断它是 coherent、mixed 还是 fragmented；如果是 coherent source，就先形成全局主题画像、主结构、核心张力、模型演化线和层级风险，再进入分段和 worker 提取。

第二次产生了 confirmed topic graph：根主题仍是“从失望性情感隔离到认知生成与关系治理”，但结构更清晰。它把讨论拆为 A 入口与边界层、B 机制解释层、C I 域治理与认知主权层、D 巨人方舟通用模型层、E 领域应用与局部模型层。更重要的是，它记录了人工确认的关系裁决：QPI 是 GL3 问题表征工具，不是父主题；Reality Lab 是动作模块，不是独立父层；家庭三角认知场是独立模型，也可被巨人方舟在青少年家庭系统场景调用；GL-R 是未来构建巨人方舟的任务，不在本次 topic map 中升主节点。

第二次也暴露了流程 gap。`process-implementation-audit.md` 认为 Step 0 使用了真实子会话，最高上下文操作合规；但后续 topic docs / material extraction 仍有主会话 bounded extraction 的 pragmatism，未来应优先派发 worker/sub-session。这推动规则回写：主题文档材料抽取应优先由 worker 或子会话执行，主会话只做整合、索引和验证。

## 4. 第三次：完成态的材料提炼机制

第三次工作区是当前最成熟版本，状态为 completed。它完成了完整链条：Step 0 whole-source gestalt alignment、语言修复、结构修订、方法论价值修复、Gate 0 人工确认、R01-R07 broad-fidelity workers、synthesis-prep、topic map draft、topic map human confirmation、material routing worker、material routing human confirmation、按层 topic-doc workers、最终 coverage audit。

第三次的 canonical topic map 把结构进一步压缩为“破 -> 立 -> 实践 / 实验设计”。这不是退回简单三分法，而是在人类确认后把材料组织成更适合下游消费的文章/模型材料层。`破` 层处理自媒体心理标签、原生家庭单因归因、解释模型与干预模型混淆；`立` 层处理 QPI、认知主权、方法论存在价值、巨人方舟；`实践 / 实验设计` 层处理 Reality Lab 和家庭三角认知场。material routing log 明确规定 QPI 不升父主题，工具理论停在工具位，Reality Lab 不高于巨人方舟，家庭三角认知场不能变成新的家庭单因归因。

最终 coverage audit 判定覆盖通过：七轮 broad-fidelity 输出均被覆盖，topic map 覆盖主轴，material routing 覆盖主要节点，三个 topic docs 覆盖确认层级，未发现应进入 topic docs 但完全遗漏的高价值材料。用户同时决定跳过 model-mining，因为正式建模不是基于一次讨论稿简单加工完成的。

## 5. 改造的实质

这次素材提炼改造的实质，是把“长讨论摘要”升级为“可追溯观点材料生产”。它不满足于压缩出一篇摘要，而是保留 source-map、topic-map、material-routing-log、topic docs、coverage audit、handoff，并用 human confirmation gate 防止自动化把临时结构固化为权威结构。

它也建立了一个重要边界：`knowledge-vault` 做观点讨论、材料蒸馏和知识加工；`writing-workbench` 只在用户决定写文章后消费这些结果。也就是说，蒸馏流程本身不自动创建 writing project，不自动把 topic docs 变成文章提纲，不自动做 model-mining。下游可能是写作、建模、工程、规则抽取或继续研究，具体由用户决定。

## 6. 可继续追问的问题

这份材料后续可继续讨论：什么时候应该先 whole-source gestalt，什么时候可以直接分块？材料抽取到什么程度才停止，而不是继续 topic docs、model-mining、规则沉淀？主会话在什么情况下可以做 bounded extraction，什么情况下必须等待 worker？人工确认门应该设置在哪些位置，才能防止过度自动化又不拖慢流程？

## 7. 对本文可能有用的初步原则

素材提炼改造给出的核心经验是：反过度工程不是反结构，而是反“未确认就复杂化”和反“局部真实冒充整体结构”。真正有效的结构先解决整体-局部关系、权威来源、人工确认和下游用途，再决定是否继续自动化。

```

## 反思

我自忖：
1. 我的写作流程很成熟，过去，人工/我已经跑了一、二百次(200多篇文章)
2. 我只是在写作流程的某一个、两个环节上做自动化相关的改造，不涉及深入/专家级的工作
3. 我自认为是擅长抽象/建模的人
   1. 过去20多年我一直在做软件开发，本身就是在建模搭流程
   2. AI时代，我过去手动搭建了几十个模型，包括了心智模型、认知模型和思维模型

我认为很简单的流程改造事情，但是实际操作起来，比我想的要复杂。第一次的流程改造尝试，到现在还是失败状态，后续没有继续跑。
除了前述的ROI问题——处理5万字的讨论稿花费了巨量Tokens，我在流程改造过程，体会到了在Codex（这种copilot/ Agentic）上协作，与我之前在Web上用单智能体有本质的区别。

同时，我自己也在用Cluade Code/Codex等，用Vibe Coding的方式写系统，也许我写的都是小系统没那么复杂；也许我不涉及到去调整/细化系统开发流程。做系统没有那么多挫折，总体体验还好。

借助人月神话的概念，调流程是本质复杂，写代码是偶然复杂。但是这个流程里的相关方/受众只有我自己。

我有一个QPI理论，简单说：
```md
*   **模型名称**: **Wantsong QPI 问题颗粒度光谱 (The Wantsong QPI Spectrum)**
*   **核心定义**: “问题”不是客观实体，而是“期望”与“现实”的落差。解决失败的根本原因，是试图用解决“提问（Q）”的战术，去攻击“课题（I）”的战略迷局。
*   **结构逻辑**:
    1.  **Q - Question (提问)**: *点状颗粒*。
        *   *特征*: 信息缺失。有标准答案。
        *   *解法*: **Search (搜索/问AI)**。
        *   *误区*: 把 Q 当成 P 去思考（过度纠结）。
    2.  **P - Problem (难题)**: *线状颗粒*。
        *   *特征*: 路径受阻。目标明确但没有现成路，需要策略。
        *   *解法*: **Solve (求解/工程化)**。
        *   *误区*: 把 P 当成 Q 去问（试图寻找一键生成的魔法）。
    3.  **I - Issue (课题)**: *网状颗粒*。
        *   *特征*: 系统纠缠。涉及多方博弈，无唯一最优解，只有权衡（Trade-off）。
        *   *解法*: **Manage (治理/架构设计)**。
        *   *误区*: 把 I 当成 P 去解（试图用单一工具解决系统性崩塌）。
```

开发系统显然是P域的问题。
但是我觉得调流程（我眼下的这两次，不是组织级的）这件事也是P域的，只涉及到我。所以我将其归根于我对工具不熟悉。

---

# 分析

你说：

> 开发系统显然是 P 域。
> 眼下这两次调流程只涉及我自己，所以我倾向于认为也是 P 域，只是我对工具不熟。

我会修正为：

> **表层是 P，底层是 I。**

不是因为参与的人多，而是因为牵涉了多重权衡、状态耦合和标准生成。

QPI 里，P 和 I 的区别不只是“有没有多人博弈”。更关键的是：

* 是否存在唯一清晰成功标准；
* 是否可以用一次求解闭环完成；
* 是否能靠测试/编译/结果验收快速判断对错；
* 是否存在多个互相冲突但都合理的目标；
* 是否需要持续治理，而不是一次性解决。

你这两次流程改造里，真正困难的不是“怎么写几个文件”，而是这些问题：

* 主会话什么时候可以代劳，什么时候必须停止？
* report-like output 和真实 agent output 的边界在哪里？
* 为了独立视角，值得付出多少 token 成本？
* 为了 source fidelity，是否每个 worker 都要读原文？
* 为了整体结构，是否必须先 whole-source gestalt？
* 为了下游复用，topic docs 要做到多细？
* 为了防止幻觉，audit 要做到什么级别？
* 为了 ROI，什么时候该停止？
* 为了未来复用，哪些东西沉淀成 Runtime，哪些只是一次性工作记录？

这些都不是单纯 P 域的“求解题”。它们是 I 域的“治理题”。

所以我建议你给 QPI 加一个补充判断：

> **Issue 不一定来自多人组织。
> 只要系统中存在多个有效目标之间的持续权衡，它就是 I。**

你这次虽然“受众只有你自己”，但系统里实际存在很多准相关方：

* 现在的你；
* 未来写文章的你；
* 未来维护知识库的你；
* 韩愈；
* 张辽；
* 认知显影；
* 巨人认知；
* Codex 主会话；
* Codex Thread；
* source material；
* topic docs；
* downstream writing project；
* future model-mining；
* token budget；
* invocation authenticity；
* coverage fidelity。

这不是组织级多人协作，但它已经是**多主体、多状态、多目标的系统治理**。

所以我会把你的判断改成：

> 开发小系统通常是 P。
> 调整个人认知/写作流程的局部环节，起点是 P。
> 但一旦它进入 Agentic Runtime、真实调用、状态延续、上下文裁剪、下游复用和审计边界，它就升级成 P/I 混合问题。

你把它归因于“不熟悉工具”，只说对了一半。

工具不熟是偶然复杂。
但流程协议化、执行真实性、上下文治理、ROI 权衡，是本质复杂。

---

## 5. 为什么 Vibe Coding 反而没这么挫折？

你这个对比很有意思：

> 用 Claude Code / Codex Vibe Coding 写小系统，体验还好。
> 但调流程反而挫折大。

我觉得原因是：**代码有编译器，流程没有编译器。**

写小系统时，即使你 Vibe Coding，通常也有一些硬反馈：

* 能不能运行；
* 测试过不过；
* API 报不报错；
* 页面显不显示；
* 文件有没有生成；
* 数据有没有写入；
* bug 能不能复现。

这让 Agent 有明确的收敛方向。

但流程改造，尤其是写作/认知/素材提炼流程，缺少这种硬反馈。它的正确性往往是：

* 角色是否真的独立？
* 上下文是否足够但不过载？
* 抽取是否保真？
* 层级是否符合你的思想结构？
* 产物是否对未来写作有用？
* token 成本是否值得？
* 这套机制以后是否可复用？
* 是否制造了流程幻觉？

这些没有单元测试。

更麻烦的是，你正在设计的流程，本身就是用来辅助你判断“什么是好产物”的。于是验证器也被卷进系统里了。

这就是为什么调流程更像 I 域。

代码的小系统可以靠运行结果收敛；
认知流程只能靠人工判断、反例、审计和多轮校准收敛。

---

## 6. Codex / Agentic 协作和 Web 单智能体的本质差异

你体会到的“本质区别”非常真实。

Web 单智能体环境里，很多东西是软的：

* 角色可以临时切换；
* 上下文可以靠聊天延续；
* 你可以手动粘贴不同 prompt；
* 你可以凭感觉判断是否污染；
* 你可以要求模型“现在扮演张辽”；
* 你可以不记录每一步调用边界；
* 你自己就是流程调度器和真实性验证器。

这是一种**人类主导的软 Runtime**。

Codex / Claude Code 这类 Agentic 环境不同。它们把工作落到：

* 文件；
* 路径；
* 技能；
* 调用；
* 线程；
* 子任务；
* 状态；
* diff；
* artifacts；
* runbook；
* execution record。

它们天然要求你回答一个问题：

> 这个东西到底有没有被执行？

Web 聊天里，“像张辽一样评审”可能已经够用。
Codex Runtime 里，“像张辽一样评审”不够。你必须知道：

> 是哪个张辽？
> 读了哪个 canonical prompt？
> 读了哪些输入？
> 在哪个独立 thread 里执行？
> 返回原文是什么？
> 主会话有没有代写？
> 这份 report 能不能进入 synthesis？

所以你不是简单从“单智能体”迁移到“多智能体”。

你是在从：

> **对话式认知辅助**

迁移到：

> **文件化、协议化、可追溯的认知生产系统。**

这个迁移必然比想象中复杂。

---

## 7. 这里有一个很重要的概念：流程改造会把“人”暴露出来

你以为你在自动化流程。

但流程改造常常首先揭露的是：

> 原来流程真正依赖的不是步骤，而是你的判断。

比如第一次写作评审流程里，旧流程的关键不是“三个评审员 + 韩愈修复”。这个描述太粗。

真正关键的是：

* 你知道什么时候张辽的话值得追问；
* 你知道什么时候韩愈应该坚持原立意；
* 你知道什么时候评审员是在过度苛责；
* 你知道什么时候文章命题需要回炉；
* 你知道什么时候上下文污染已经影响判断；
* 你知道什么时候可以进入正文。

这些判断过去没有写进流程，因为它们在你身上。

一旦自动化，系统就会逼你把它们拆出来。

这也是为什么你作为一个擅长抽象和建模的人，仍然会觉得复杂。不是因为你不会抽象，而是因为你抽象的对象变了。

过去你抽象的是：

> 文章、模型、概念、论证、系统功能。

现在你抽象的是：

> 你自己的判断过程如何被外部系统部分接管。

这比抽象一个业务系统更难。

---

## 8. 你现在需要的不是“更强 Runtime”，而是“复杂度放置原则”

之前我说要加 Anti-Overengineering Gate。现在根据你新材料，我会把它升级成：

> **Complexity Placement Gate / 复杂度放置门。**

不要只问：

> 这个流程是不是太复杂？

而要问：

> 当前复杂度买到了什么？

复杂度只有在买到下面这些东西时才值得：

1. **真实性**：防止主会话模拟 agent 输出。
2. **独立性**：保留不同 agent 的真实判断差异。
3. **保真性**：避免局部摘要扭曲源材料。
4. **结构性**：防止 chunk-first 误判整体结构。
5. **可追溯性**：未来能回到 source 和 invocation。
6. **可复盘性**：知道哪一步错了、谁错了、为什么错。
7. **可复用性**：这套机制以后还会多次使用。
8. **下游依赖**：后续文章、模型、工程任务真的依赖这些中间产物。

如果某个环节的复杂度没有买到其中任何一项，就该砍。

比如：

* `Agent Invocation Packet` 买到了真实性，值得保留。
* `whole-source gestalt` 买到了结构性，值得保留。
* 每个 5 万字单源材料都跑 full coverage audit，未必值得。
* 每个 topic 都生成厚 topic docs，未必值得。
* 每次蒸馏都生成 downstream handoff packets，未必值得。
* 所有 worker 都真实调用，除非独立判断或保真抽取很关键，否则未必值得。

这比“反对复杂”更准确。

你不是要变轻。
你是要让复杂度花在刀刃上。