---
name: chatgpt-subject-purify
description: WHAT：把 ChatGPT App 与 Sider 对话拉取到 ai-workspace/cpu-matrix 的 chats 资产区，围绕一个特定 subject 做分类、筛选、索引更新，并调用 info-purify 把该主题整理成完整、可追溯、可维护、可继续讨论的核心上下文体系。WHEN：用户要求“拉取 ChatGPT/Sider 聊天并整理到某个主题”“为某个 subject 补充聊天材料”“筛选 ai-workspace 中某主题相关问题”“用 info-purify 定义清楚某主题完整内容”“像成长与人生决策那样重建主题核心上下文”时使用。
---

# chatgpt-subject-purify

把一组散落在 ChatGPT App、Sider 与 `cpu-matrix/public/chats/` 中的对话，收束成一个 subject 的完整知识体系。这个 Skill 的终点不是“写一个大纲”，也不是把原始问答流水账搬进核心文件，而是把材料净化成可继续讨论、可联合其他已确定内容使用的高质量上下文资产。默认生成或更新：

- `cpu-matrix/public/subjects/<主题>/核心上下文.md`
- `cpu-matrix/public/subjects/<主题>/索引.md`
- 必要时的底层概念定义文件，例如 `成长.md`
- 审计模式、长期维护、高风险或用户明确要求时的净化日志记录文件，例如 `净化日志.md` 或 `工作记录.md`

这个 Skill 与 `$info-purify` 共同构成一条流水线：本 Skill 承担“拉取、分类、筛选、归档路径和主题资产编排”，`info-purify` 承担“信息体系降熵的方法、校验和必要追溯”。主题主入口天然面向读者消费，承载核心上下文；台账、筛选细节和过程审计属于净化日志记录，不属于主题正文，只有被目标读者直接使用的风险、限制或来源锚点才会转译进入主入口。

## 工作流总览

本 Skill 只有两个阶段：

| 阶段 | 执行单元 | 目标 | 阶段输出 |
| --- | --- | --- | --- |
| 1. 拉取阶段 | 独立 Subagent | 获取 ChatGPT / Sider / 本地聊天候选材料，保持原始聊天资产不被改写 | 拉取阶段总结 |
| 2. 整合阶段 | 主控 Agent + `$info-purify` | 消费拉取阶段总结和源文件，完成主题筛选、结构归属、核心上下文、索引与必要日志更新 | `核心上下文.md`、`索引.md`、必要概念文件、必要时的净化日志记录 |

两阶段之间通过“拉取阶段总结”交接。拉取阶段只负责把材料拉齐、记录范围、暴露认证或覆盖缺口，并给出轻量候选清单；整合阶段才进行主题归属、信息块拆分、判断分层和正文写作。

拉取阶段默认由独立 Subagent 执行。若当前运行环境无法启动 Subagent，先停止并说明拉取阶段未按标准隔离完成；只有用户明确允许主控代跑时，才用主控执行拉取，并在交付中标记该偏离。

## 产物心智

本 Skill 的产物分为三层：

| 层级 | 默认文件 | 职责 |
| --- | --- | --- |
| 主题产物本体 | `核心上下文.md`、必要概念文件 | 面向目标读者的最终正文和概念扩展，可直接用于继续讨论、判断、应用和维护。 |
| 主题导航资产 | `索引.md` | 说明材料边界、主题入口和粗粒度来源导航，不承载正文判断或过程审计。 |
| 净化日志记录 | `净化日志.md` / `工作记录.md`，或仅保留在交付说明中 | 记录拉取阶段总结、候选筛选、结构诊断、旧新映射、台账、事实概念关系核查、专项交接、升级候选和校验结果。 |

`核心上下文.md` 是主题产物本体和主入口：它承载的是可阅读、可推理、可复用、可继续讨论的正文，不承担维护台账、原始问答索引、候选筛选记录或强行给出终局判断的职责。

若既有 subject 目录中已经存在 `核心判断.md`，它是历史主入口和高权重输入材料：读取并吸收其有效内容；新建或重写主入口时，当前主入口落在 `核心上下文.md`。旧 `核心判断.md` 默认保留，只有用户明确要求迁移或删除时才处理。

分工如下：

| 文件 | 职责 |
| --- | --- |
| `核心上下文.md` | 净化后的主题正文：按内容结构聚合事实、观点、已确认判断、待讨论命题、边界、关系和使用方式。 |
| `索引.md` | 主题导航资产：说明本主题引用材料的边界，哪些来源算入本主题、哪些一定不算、几块来源大致承担什么角色，并提供粗粒度来源入口。 |
| 其他概念文件 | 当某个底层概念是全文评价轴时，单独承载定义、边界、非范围和关系约束。 |
| `净化日志.md` / `工作记录.md` | 可选过程记录：只在审计、长期维护、高风险或用户明确要求时落盘；默认不作为主题消费入口。 |

核心文件与 `索引.md` 天然分工：核心文件不重复来源清单，也不逐轮列出原始问答事实。涉及“问过什么/回应过什么”时，它们会被净化成对应内容模块下的必要事实、观点来源或待讨论命题；原始问答回看路径由 `索引.md` 的粗粒度来源入口承担。

核心文件与净化日志记录也必须分工：核心文件只写目标读者消费主题时需要的正文内容；结构诊断、目标结构、旧新映射、候选筛选表、事实承诺表、关系表、专项交接和升级候选表默认进入净化日志记录。若某项风险会影响读者使用主题，先转译成正文中的“使用限制、待确认命题或当前不可用判断”，再在日志中保留完整追溯。

核心文件的注意力中心是高质量维护每个内容结构下的具体内容：定义清楚、边界清楚、事实/观点/推断/待确认分层清楚、关系清楚、可继续讨论。顶层结构只服务这些内容，不作为自我证明；“已经有结论”也不是它的默认姿态。

### 上层使用目标校准

`chatgpt-subject-purify` 调用 `info-purify` 时，`info-purify` 的角色不是直接产出一个名为“核心判断”的终态文件，而是提供降熵流程，把聊天材料转化为 subject 级上下文资产。两层职责这样区分：

| 层级 | 目标 | 默认产物 |
| --- | --- | --- |
| `chatgpt-subject-purify` | 管理主题资产边界、主入口、来源入口和长期维护方式 | 主题产物本体、主题导航资产、必要时的净化日志记录 |
| `info-purify` | 提供结构诊断、目标结构、来源追溯、事实分层、关系显式化、升级候选等净化机制 | 其“最终正文”映射为 `核心上下文.md` 的内容来源；其余表格和校验映射为净化日志记录 |

因此，主题主入口的成功状态是“读者拿到足够上下文后能继续判断、提问、应用和维护”，而不是“所有材料被压成一组最终判断”。稳定结论只在主题已经阶段性闭环或已定型时上提为当前判断；未闭环主题的主体材料是事实、观点、命题、边界和待确认。

### 索引边界

`索引.md` 不是主题正文、不是判断摘要、不是候选材料审计表，也不是可替代 `核心上下文.md` 的使用入口。它只承担“材料边界说明 + 粗粒度导航”的职责，避免读者误以为可以仅凭索引完成判断、复盘或二次创作。

索引的固定形态：

- 一个原始对话目录通常只形成一行来源引用，链接到该对话目录或必要入口；即使目录下有 `001.md`、`002.md` 等多轮文件，也不逐轮展开完整清单，除非某一轮本身是唯一需要精确定位的例外来源。
- 每块来源只记录大致角色，例如“核心材料”“补充案例”“边界反例”“相邻主题材料”“明确排除材料”；它与 `核心上下文.md` 的细粒度关系、单块判断、结论、推理链和详细摘要属于净化日志记录或核心正文，不属于索引。
- 纳入/排除/暂缓只表达边界理由，服务“哪些是、哪些不是”；索引不是内容分析表、事实承诺表、关系表、行动建议表或完整阅读指南。
- 细粒度来源回溯、逐轮问答梳理和模块级关系分析属于净化日志记录、自检记录或 `核心上下文.md` 的净化正文，不进入 `索引.md`。

### 闭环成熟度

开始写核心文件前，先判断主题闭环成熟度：

| 状态 | 特征 | 核心文件写法 |
| --- | --- | --- |
| 未闭环 | 主命题仍在生长，关键判断会被后续材料改变 | 核心上下文优先：事实、观点、命题、待确认和当前可用判断分层写，不做终局裁决。 |
| 阶段性闭环 | 主判断稳定，后续主要是补充细节和来源追溯 | 可以上提当前可用判断，但仍要保留必要事实、边界、关系和待确认。 |
| 已定型 | 规则、SOP、方法论已经明确，过程价值较低 | 可写成操作手册或稳定方法论，过程下沉到索引/来源。 |

无论哪一档，核心文件的下限都不是“来源清单 + 原始问答摘要”。未闭环主题同样有内容结构，只是结论状态会被标清楚。

### 主题归属与结构分配判据

本 Skill 把“新对话成为新主题、进入既有主题、拆给多个主题，还是只作为来源补充”作为分类命题本身。标题相似、关键词相似、聊天发生时间和当前用户关注点只是线索；真正的分类依据来自 `info-purify` 的消费路径、结构归属、信息块状态和显式关系。

核心判断句：

```text
先判断新材料改变的是哪一层：
- 改变判断对象和长期消费路径 -> 新主题
- 改变既有主题内的稳定子问题 -> 新内容模块
- 只改变已有子问题里的事实、观点、边界或关系 -> 归入已有模块
- 只提供例子、背景、反例或相邻信息 -> 补充 / 暂缓 / 排除
```

分类粒度固定为四层：

| 层级 | 判定问题 | 处理动作 |
| --- | --- | --- |
| 原始对话 | 这个对话是否只是来源资产？ | 保留在 `public/chats/`，不修改。 |
| 信息块 | 单个事实、观点、假设、问题、例子、边界或关系分别服务哪里？ | 可拆入不同模块或不同主题，不被原始对话标题绑死。 |
| 内容模块 | 是否围绕一个稳定子问题形成完整结构？ | 在主题内单列二级模块，写清定义、边界、关系、使用方式和待确认。 |
| 主题 | 是否围绕一个长期判断对象形成独立上下文系统？ | 新建或更新 subject，维护独立 `索引.md` 和 `核心上下文.md`。 |

判断为新主题的标准：

- 有独立消费路径：读者使用它是为了判断另一类问题，而不是补充旧主题。
- 有独立核心对象：它讨论的是另一套判断对象、方法对象、关系对象或系统对象。
- 需要自己的底层概念、边界、非范围、关系表或应用入口。
- 未来会持续围绕它新增材料，维护生命周期不同于既有主题。
- 强行塞进旧主题会改变旧主题的总定位、评价轴、一级结构或边界。

判断为既有主题内新内容模块的标准：

- 它仍服务同一个主题的消费路径。
- 它提出稳定子问题，而不是零散例子或单条事实。
- 它内部能形成完整信息结构：定义、边界、事实、观点、关系、应用、待确认。
- 后续材料可能继续追加到这个子问题下。
- 它与主题内其他模块存在明确关系，例如 `grounds / constrains / supports / depends_on / complements / resolves / modifies`。

判断为归入已有模块的标准：

- 它只给已有判断增加来源、反证、边界、例子或低置信修正。
- 它不改变主题总定位，也不改变模块结构。
- 它的价值主要是补强已有事实承诺、状态分层、概念边界或关系表。

判断为拆分到多个主题的标准：

- 同一个对话中存在多个信息块，分别服务不同消费路径。
- 前半段是具体领域应用，后半段上提为元方法、人生治理、身体/应激、职业、关系或其他主题。
- 某些内容只作为当前主题的案例背景，另一些内容会改变相邻主题的结构。
- 原始对话标题覆盖面过大，不能代表全部信息块的真实归属。

遇到这种情况时，材料不会为了整洁被整段压进一个主题。原始对话目录在索引中只形成一行来源入口；执行过程按信息块拆分归属，各自主题只吸收服务本主题的信息结构。核心正文的“主题边界”默认只说本主题自身，不借其他主题解释边界；其他主题没有被本主题正文实际使用时，就不进入核心正文。

### 多因成因栈写法

当一个领域问题不是单一原因导致，而是多个独立因素叠加时，核心正文显式呈现“成因栈 / 约束栈”。这类问题的结构是多因叠加，不是单因果链。

成因栈最小字段：

| 字段 | 说明 |
| --- | --- |
| 因素 | 例如复杂内心、关系偏好、身体/应激、经验技能、对象匹配、现实关系场、人生治理等。 |
| 来源主题或来源材料 | 这个因素来自哪个上游主题、哪段对话或哪条事实。 |
| 独立性 | 它是否独立于其他因素存在，还是由其他因素派生。 |
| 对当前主题的作用 | 它 `grounds / constrains / modifies / triggers / amplifies` 了什么问题。 |
| 处理归属 | 在当前主题处理，还是只作为来源追溯；无关主题不用于说明边界。 |

成因栈的固定写法：

- 上游主题只解释其职责内的机制，不承担完整应用问题。
- 当前派生主题负责把多因因素组合成可执行的关系、行动、判断或治理系统。
- 若某个独立因素暂时没有成熟上游主题，它先在当前主题中作为模块或待确认因素处理，不硬塞进不合适的主题。
- “需要改变上游主题定义、边界或权威结构”的情况进入升级候选，而不是直接扩大主题。
- 当前主题未实际引用某上游主题内容时，不写“相关主题”“相邻主题”或“未来接口”来解释本主题；默认就是没有引用。

## 固定工作区

项目相关命令不要在工作区根目录直接执行。

| 用途 | 目录 |
| --- | --- |
| ChatGPT / Sider CLI | `/Users/a1111/Desktop/ai-workspace/cpu-cli-tool` |
| 知识库项目 | `/Users/a1111/Desktop/ai-workspace/cpu-matrix` |
| 聊天资产区 | `/Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats` |
| 主题资产区 | `/Users/a1111/Desktop/ai-workspace/cpu-matrix/public/subjects` |
| info-purify | `/Users/a1111/Desktop/ai-workspace/.cursor/skills/info-purify/SKILL.md` |

进入具体项目迭代前，先检查对应项目是否存在 `AGENTS.md`；存在则读取并遵守。不要回滚用户已有改动。

## 输入与完成标准

典型输入包括主题名、ChatGPT / Sider URL 或 id、对话标题关键词、时间范围、既有 subject 目录、主题边界和底层概念文件。若主题名或目标目录可从用户话语和现有路径唯一推断，直接执行；只有在无法确定主题目录或拉取目标时才简短询问。

完成状态由两个阶段共同定义：

- 拉取阶段已经由独立 Subagent 完成，并产出可被整合阶段消费的“拉取阶段总结”；若未使用 Subagent，交付中明确标记偏离原因和用户授权。
- 整合阶段已经消费拉取阶段总结、原始聊天文件、既有 subject 文件和 `$info-purify` 方法，完成主题结构归属、核心上下文、索引和必要概念文件更新。
- `核心上下文.md` 作为主题产物本体，可以继续讨论、判断、应用和维护。
- `索引.md` 作为主题导航资产，只承担材料边界和粗粒度来源导航，不替代核心正文。
- 净化日志记录已经按风险决定是否落盘；未落盘时，关键偏离、覆盖缺口、升级候选和剩余风险必须在交付说明中汇报。
- 校验已覆盖链接、完整性、污染、结构归属、依赖关系、多因成因栈、完结主题和工作区状态。

用户可能给出以下输入中的一部分：

- 主题名：如 `成长与人生决策`、`复杂内心`。
- ChatGPT 对话 URL 或 conversation id：形如 `https://chatgpt.com/c/<id>`。
- Sider 对话 URL 或 conversation id：Sider 对话 URL 或列表中的 id。
- 对话标题关键词：如“机会处理方法论”“成长系统优化方法”。
- 时间范围：如“今天”“一天内”“最近 7 天”“2026-05-29 到 2026-05-31”。
- 既有 subject 目录：如 `cpu-matrix/public/subjects/成长与人生决策/`。
- 主题边界：哪些纳入，哪些不纳入。
- 底层概念定义：如 `成长.md`。

## 阶段一：拉取阶段

### 拉取阶段调度

主控 Agent 先确定主题名、目标目录、数据源范围和时间窗口，然后把拉取任务交给独立 Subagent。Subagent 在 `cpu-cli-tool` 项目根执行命令，负责：

- 检查 `cpu-cli-tool/AGENTS.md` 与 `cpu-matrix/AGENTS.md`，并遵守其中约束。
- 按用户输入拉取指定 ChatGPT / Sider 对话，或按默认窗口筛选本地聊天候选。
- 拉取多个对话时先建立候选清单，再逐个拉取。
- 保持 `public/chats/` 下原始聊天文件不被修改。
- 输出“拉取阶段总结”，交给主控进入整合阶段。

Subagent 不产出主题正文，不更新 `public/subjects/<主题>/`，也不替整合阶段做最终纳入判断。它可以记录轻量边界线索，但不能把线索写成主题结论。

在 `cpu-cli-tool` 项目根执行。优先使用已安装的 `chatgpt` / `sider` 命令；若不可用，再使用对应的 `node dist/commands/.../index.js`。

### ChatGPT 数据源

列出 ChatGPT 对话：

```bash
chatgpt list --all
```

按标题关键词检索列表后，确认候选对话的 id、更新时间和标题。若用户已经给了 id 或 URL，可跳过列表检索。

拉取单个 ChatGPT 对话：

```bash
chatgpt pull "<conversation-id-or-url>" -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats
```

### Sider 数据源

默认拉取 Sider 最近 30 个对话列表，并把候选对话纳入同一轮主题筛选。若用户指定次数，用用户指定值覆盖 30。

```bash
sider list -l 30
```

如需 JSON 便于筛选，可用：

```bash
sider list -l 30 --json
```

拉取单个 Sider 对话：

```bash
sider pull "<conversation-id-or-url>" -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats
```

Sider 的 `pull` 也有兼容别名：

```bash
sider chat "<conversation-id-or-url>" -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats
```

### 时间筛选本地聊天

拉取完成后，或用户要求从本地 `public/chats` 中筛选材料时，默认只筛选最近 2 天内创建的聊天 Markdown。时间以本地文件创建时间为准，不等同于远端对话更新时间。

`chatgpt filter` 与 `sider filter` 都筛选同一个聊天资产目录，输出字段一致；任选其一即可，除非需要验证两个命令入口都可用。

默认筛选最近 2 天：

```bash
chatgpt filter -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats --days 2 --json
```

筛选一天内：

```bash
chatgpt filter -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats --days 1 --json
```

筛选明确时间范围：

```bash
sider filter -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats --since "2026-05-29T00:00:00+08:00" --until "2026-05-31T23:59:59+08:00" --json
```

只需要候选对话目录时：

```bash
chatgpt filter -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats --days 2 --dirs
```

### 拉取阶段输出约定

两个数据源的拉取结果都会按对话标题写入：

```text
cpu-matrix/public/chats/<对话标题>/001.md
cpu-matrix/public/chats/<对话标题>/002.md
...
```

约束：

- 不修改拉取出的原始聊天文件；它们是来源资产。
- ChatGPT 认证失败时，说明需要用户登录 ChatGPT、切换 Chrome profile，或提供 `CHATGPT_ACCESS_TOKEN` / `--token`。
- Sider 认证失败或遇到 Cloudflare challenge 时，说明需要用户在 Chrome 中保持 Sider 登录；必要时切换 `--profile` 或提供 `--token`。Sider 当前单对话消息接口默认最多拉取 200 条，超长对话要在剩余风险中记录。
- 拉取多个对话时，先建立候选清单，再逐个拉取，避免把无关大批量材料直接混进主题。
- 没有明确指定历史范围时，候选聊天必须先经过 `filter --days 2 --json` 缩小；不要默认全量扫描 `public/chats`。
- 当用户要求“两个数据源都用上”时，不能只看 ChatGPT；至少要拉取或检查 Sider 最近 30 条，并在筛选表中记录纳入/排除/暂缓理由。

### 拉取阶段总结

Subagent 返回给主控的总结是整合阶段的唯一交接入口，包含：

| 字段 | 说明 |
| --- | --- |
| 拉取任务 | 用户原始要求、主题名、目标 subject 目录、时间范围、指定 URL / id / 标题关键词。 |
| 执行环境 | 实际工作目录、读取到的 `AGENTS.md` 约束、使用的 CLI 入口。 |
| 命令记录 | 关键 `chatgpt` / `sider` / `filter` 命令、成功或失败状态、失败原因。 |
| 候选来源清单 | 数据源、标题、路径、远端 id 或 URL、拉取状态、时间信息、轻量边界线索。 |
| 资产写入 | 新增或确认存在的 `public/chats/...` 目录。 |
| 覆盖缺口 | 认证失败、Sider 200 条限制、未能访问的数据源、用户需要补充的信息。 |
| 进入整合阶段的建议 | 哪些文件应被主控读取，哪些材料明显暂缓或需要谨慎处理。 |

候选来源清单只做材料交接，不替代整合阶段的结构动作判断。整合阶段可以推翻拉取阶段的轻量边界线索。

## 阶段二：整合阶段

整合阶段由主控 Agent 执行，并同时调用 `$info-purify` 的信息降熵方法。它的输入是拉取阶段总结、原始聊天资产、既有 subject 文件和用户给出的主题边界；它的输出是主题资产更新。

### 整合步骤 1：主题盘点与候选筛选

在 `cpu-matrix` 项目根执行。先读取：

- `public/subjects/<主题>/索引.md`，如果存在。
- `public/subjects/<主题>/核心上下文.md`，如果存在。
- `public/subjects/<主题>/核心判断.md`，如果存在，将其作为历史主入口输入读取，不默认继续写入。
- `public/subjects/<主题>/*.md` 中明显属于底层概念定义的文件。
- 拉取阶段总结中列出的候选聊天 `*.md` 文件；默认范围是最近 2 天，用户明确给出时间范围时按用户范围执行。

候选范围规则：

- 默认候选范围：`chatgpt filter -o /Users/a1111/Desktop/ai-workspace/cpu-matrix/public/chats --days 2 --json` 的 `items`。
- 用户说“一天内 / 最近 N 天 / 某日期区间”时，改用对应的 `--days` 或 `--since/--until`。
- 用户给出具体对话 URL、id 或明确本地路径时，该对话可直接进入候选，不受 2 天默认窗口限制。
- 只有用户明确要求“全量”“历史所有聊天”或当前任务必须做历史回溯时，才扫描整个 `public/chats`，并在交付中说明扫描范围扩大。

候选聊天会形成一份轻量筛选记录，用于执行过程判断和最终交付摘要；完整筛选记录默认属于净化日志记录，不写入 `索引.md` 或 `核心上下文.md`。记录至少包含：

| 字段 | 说明 |
| --- | --- |
| source_id | 稳定编号，如 `S01` |
| 数据源 | ChatGPT / Sider / 既有本地文档 |
| 路径 | 相对 `public/subjects/<主题>/` 的粗粒度链接路径；对话目录优先，不逐轮展开 |
| 标题 | 聊天目录名或文档名 |
| 边界理由 | 为什么属于、相邻于、不属于或暂不属于该 subject |
| 归入状态 | 纳入 / 排除 / 暂缓 / 相邻主题 |
| 来源角色 | 核心材料 / 补充案例 / 边界反例 / 相邻主题材料 / 明确排除材料 |
| 结构动作 | 新主题 / 新模块 / 归入已有模块 / 拆分归属 / 历史案例 / 升级候选 |
| 必要依赖来源 | 若本主题当前判断必须依赖其他主题或文件，列出；没有实际引用则留空 |

筛选机制：

- 保留强相关和能改变主题结构的材料。
- 每个候选对话先获得结构动作判断：新主题、新模块、归入已有模块、拆分归属、历史案例或升级候选；“纳入/排除”只是后续状态，不是完整判断。
- 允许同一个原始对话被拆成多个信息块，分别归入不同主题或模块；但原始对话目录只保留一个来源资产，不复制、不改写。
- 当候选材料依赖多个既有主题且消费路径独立时，它更接近派生 / 桥接主题，而不是最相似上游主题的附属内容。只有当前正文判断实际依赖这些主题内容时，才记录依赖来源。
- 当候选材料暴露既有主题边界需要调整时，处理落在必要边界升级或升级候选；既有主题不因此扩成无限泛化的总主题。
- 用户声明已完结的主题只作为历史案例、验证来源或边界材料，不继续写入新正文。
- ChatGPT 和 Sider 两个数据源进入同一份轻量筛选记录，用 `数据源` 字段区分；主题结构不按数据源拆成两套。
- 相邻主题材料只保留它对本主题的作用，不搬运整个相邻主题；“相关但未引用”的材料不进入本主题。
- 纯案例只有在能提炼出模型、边界、流程或判断规则时才进入核心上下文入口；否则只在索引中作为补充/暂缓来源一行记录，或直接暂缓。
- 医疗、法律、财务、职业终局等高风险结论不能被写成普遍建议，只能保留为来源材料中的方法论或待验证判断。
- 原始问答的逐轮导航和详细分析不进入 `索引.md`；`核心上下文.md` 只吸收这些问答净化后的信息块，不维护“Q01/Q02...”流水账。

### 整合步骤 2：定义主题入口与底层概念

先判断该 subject 是否已有底层概念文件，例如：

```text
public/subjects/<主题>/成长.md
public/subjects/<主题>/自由.md
public/subjects/<主题>/机会.md
```

如果有，按最高权威来源处理，并执行“架构位置检查”：

1. 这个概念只是某一模块的定义，还是全文评价轴？
2. 它是否约束机会、风险、行动、关系、职业节点等后续模块？
3. 它是否改变原有章节顺序、权威来源优先级或关系表？
4. 它的“非范围”是否能防止把相近概念误写成主题核心？
5. 若当前主题实际依赖多个上游主题，这些底层概念分别提供机制、元治理、应用边界还是历史案例？
6. 是否存在多个独立成因被误写成某个底层概念的派生问题？

关键经验：底层概念不是正文某一节里的补充说明。若它定义的是主题核心对象，它会同时出现在总定位、总结构、概念表、权威来源表、关系表和领域检查项中。

若发现某个既有主题被新材料要求升级一个维度，先判断这是“必要边界升级”还是“主题泛化风险”：

- 必要边界升级：补一句边界声明或转入规则即可，例如“本主题解释某机制，但完整应用问题由某派生主题承接”。
- 主题泛化风险：如果升级后会让该主题承包关系、成长、身体、职业、人生治理等所有问题，应停止合并，改建派生主题。
- 真实结构升级：如果用户明确确认主题要重定义核心对象，再按 `info-purify` 审计模式重构该主题，不在当前分类步骤中顺手改。

### 整合步骤 3：运行 info-purify

读取 `/Users/a1111/Desktop/ai-workspace/.cursor/skills/info-purify/SKILL.md`，按其阶段执行。若当前环境没有 `TodoWrite` 或用于复核的 Subagent，则使用普通待办和主控自检替代，并在剩余风险中记录；这不改变拉取阶段默认由独立 Subagent 执行的要求。

对 subject 级知识体系，默认使用标准模式；当主题会长期维护、材料多、概念边界复杂时使用审计模式。

`info-purify` 当前采用“产物本体 / 净化日志记录”两层结构。映射到本 Skill 时：

- `info-purify` 的产物本体映射为 `核心上下文.md` 的主题正文，必要时拆出概念文件。
- `info-purify` 的净化日志记录映射为本 Skill 的净化日志记录，不默认进入 `核心上下文.md` 或 `索引.md`。
- `索引.md` 由本 Skill 维护，是主题导航资产，不等同于 `info-purify` 的日志记录。

`核心上下文.md` 的产物形态是完整可消费的主题上下文，不是大纲、原始材料清单、审计表集合或只剩结论的判断摘要。它的正文结构从主题内容本身长出来，用二级标题划分稳定内容范围；每个范围内部再按需要写定义、事实、观点、边界、关系、应用、当前可用判断和待确认。

`info-purify` 要求的结构诊断、目标结构、旧新映射、事实承诺、概念、关系、专项交接和升级候选，会在执行过程中形成并完成自检。默认情况下，这些表格和过程记录进入净化日志记录；进入 `核心上下文.md` 的只有被读者消费路径需要的正文内容。对长期维护、高风险或用户明确要求可追溯审计的主题，另行生成或更新 `净化日志.md` / `工作记录.md`；不要把完整审计表塞进主入口正文末尾。

`核心上下文.md` 默认结构建议：

```markdown
# <主题>：核心上下文

## 主题定位与使用方式
说明本主题处理什么、目标读者如何使用它，以及当前闭环成熟度。这里是任务基本性质的正文转译，不粘贴 info-purify 过程记录。

## 主题边界
直接说：如何判断特定内容是否属于这个主题；这个判断方法不要直接引用其他主题的上下文内容。

## 1..N. 主题内容模块
## 应用入口：后续讨论或具体问题时怎么用
## 当前可用判断与不可用判断
## 待讨论命题与研讨接口
```

若存在会影响读者使用的低置信、冲突、升级候选或剩余风险，在对应内容模块、当前不可用判断或待讨论命题中表达；完整专项审查交接、升级候选和剩余风险表进入净化日志记录。

净化日志记录建议结构：

```markdown
# <主题>：净化日志

## 拉取阶段总结
## 候选筛选记录
## 任务基本性质记录
## 原结构诊断与目标结构判断记录
## 旧新映射与信息块台账记录
## 事实、概念、权威与关系核查记录
## 专项审查交接记录
## 升级候选记录
## 主控校验记录
## 剩余风险与补充信息请求记录
```

净化日志是否落盘的判断：

- 轻量任务：默认不单独落盘，只在交付说明中汇报关键风险和覆盖缺口。
- 标准任务：若主题会持续维护、候选材料较多或后续需要复核，可落盘 `净化日志.md`。
- 审计任务：必须落盘 `净化日志.md` 或 `工作记录.md`。
- 用户明确要求可追溯、可审计、保留过程记录时，必须落盘。

正文模块的成立条件：

- 每个内容模块都有二级标题，并且标题表达内容范围，而不是“来源清单”“问答台账”这类维护任务。
- 每个模块都会把材料真正收拾聚合出来：把散落问答整理成定义、事实、观点、边界、关系、待确认和可用入口，而不是照搬原始顺序。
- `主题边界` 只写本主题自身：本主题处理什么、不处理什么、当前使用方式是什么；其他主题不用于解释本主题边界。
- 核心正文不写来源清单、来源角色、上游依赖清单、候选筛选记录、旧新映射表或“相关主题”清单；来源入口由 `索引.md` 承担，过程追溯由净化日志记录承担，正文只保留读者理解强事实时必须知道的来源锚点。
- 如果主题是派生 / 桥接主题，只在正文中写清本主题自己的消费路径和结构对象；只有当上游主题内容已经成为当前正文判断的必要依据时，才在必要追溯或关系表中记录依赖关系。
- 如果主题问题由多个独立成因叠加，正文会单列“成因栈 / 约束栈”，并标注每个因素的独立性、来源主题、作用关系和处理归属。
- 多因问题不是单因果链；应用领域中的全部困难不归因到最相似的上游主题。
- 已完结主题只作为历史案例或验证来源引用，新行动策略不写回其正文。
- 每个当前可用判断或事实承诺能回溯来源；具体链接优先由 `索引.md` 承载，核心文件可用 `Sxx` 或模块名引用。
- 强规则、推断、待确认、升级候选分开写；完整升级候选表进入净化日志记录，正文只保留会影响使用的限制或待讨论命题。
- 不把索引条目改写成“看起来完整但没有内容承接”的大纲。
- 对每个高频场景给出可执行入口。
- 对跨材料关系显式写出 `grounds / constrains / supports / depends_on / complements / resolves / modifies` 等关系。
- 来源边界、相关主题入口和粗粒度来源入口属于索引或净化日志记录，不属于核心文件正文；候选筛选细节、原始问答逐轮路径和逐块关系分析默认不进入主题产物本体。
- 若主题未闭环，核心文件仍提供高质量上下文，而不是只列事实账。可以写“当前可用判断 / 不可用判断 / 待讨论命题”，但未确认命题不写成结论。

正文模块生成时，按 `$info-purify` 的约束做局部净化：

1. 先为该模块确认消费动作：后续讨论、联合其他主题判断、直接应用、维护复核中的哪一种。
2. 将材料拆成信息块：原始事实、观点性结论事实、命题、反证、边界、候选方案、待确认。
3. 只把能服务模块主题的内容写入正文；原始顺序和逐轮问答不写入核心正文，索引只保留粗粒度来源入口。
4. 写出模块内关系：哪些事实 `grounds` 哪个判断，哪些观点 `modifies/overrides` 旧观点，哪些边界 `constrains` 使用方式。
5. 未闭环部分呈现为“待讨论命题/使用限制”，不为了文档完整感强行收束。
6. 检查该模块是否应当拆分到别的主题、上提为新主题，或只作为历史案例；若是，回退修正结构归属。
7. 最后检查该模块是否像“成长与人生决策”一样把内容收拾聚合出来，而不是只把材料梳理出来。

### 整合步骤 4：更新索引

更新 `public/subjects/<主题>/索引.md`：

- 顶部写明职责边界：`索引.md` 只说明引用内容边界和粗粒度来源导航，不承担主题正文、核心上下文、详细摘要、逐轮回溯或行动建议职责。
- 保留或补充主题归入标准：哪些材料算本主题，哪些一定不算。
- 增加 `主题入口`：`核心上下文.md` 是完整上下文入口，`索引.md` 只负责来源边界。
- 底层概念文件存在时，列入主题入口或“底层概念”分组，只说明其入口身份。
- 若本主题实际引用其他主题作为来源，在 `来源范围` 中列出它的来源角色；“相关主题”不为了说明边界而出现。
- 若某个既有主题已完结且被实际引用，它在来源范围中标为“历史案例 / 验证来源”，不列成活跃承接入口。
- 来源列表按“核心来源 / 补充来源 / 相邻主题来源 / 排除或暂缓来源”等粗粒度角色分组即可；每个原始对话目录通常只写一行引用。
- 对暂不纳入材料只写边界说明或排除理由，避免展开成详细内容判断；未引用的其他主题不写入索引。

推荐的索引骨架：

```markdown
# <主题>：索引

> 本索引只说明本主题引用材料的内容边界和来源入口：哪些算入、哪些不算、每块来源大致承担什么角色。它不提供完整上下文、详细摘要、逐轮问答导航或行动建议；需要使用主题内容时，以 `核心上下文.md` 为入口。

## 主题入口
- [核心上下文](./核心上下文.md)：完整上下文入口。
- [底层概念](./<概念>.md)：如存在，只列必要入口。

## 纳入边界
- 算入：
- 不算：

## 来源范围
### 核心来源
- S01：[对话标题](../../chats/<对话标题>/)：一句话说明来源角色。

### 补充或边界来源
- S02：[对话标题](../../chats/<对话标题>/)：一句话说明来源角色。

### 相邻、排除或暂缓
- S03：[对话标题](../../chats/<对话标题>/)：一句话边界理由。
```

禁止写入 `索引.md` 的内容：

- 每个对话目录下 `001.md`、`002.md`、`003.md` 等逐轮完整清单。
- 每块材料与核心上下文的详细关系分析、逐条事实承诺、推理链、结论拆解。
- 可直接用于行动或判断的正文内容；这些应进入 `核心上下文.md`。
- 候选筛选过程中的完整审计表、info-purify 的旧新映射、事实承诺表、关系表、专项交接表和主控校验表；这些属于净化日志记录。

不要删除用户原来精心维护的链接；除非明确替换，默认合并和重排。

### 整合步骤 5：校验

完成后至少执行这些校验：

1. Markdown 链接检查：确认 `索引.md` 和 `核心上下文.md` 中的相对链接都能解析；若保留了历史 `核心判断.md`，也检查其指向新入口或不与新入口冲突。
2. 完整性检查：确认 `核心上下文.md` 不只是大纲、事实流水账、问答台账或结论清单，正文模块已经展开到“定义、边界、事实、观点、关系、应用、待确认、当前可用判断”。
3. 架构检查：确认底层概念的权威位置、非范围、关系约束已进入配套表格。
4. 污染检查：确认没有把排除材料、相邻主题、维护建议写成既定正文结论。
5. 分工检查：确认 `索引.md` 只承担边界说明和粗粒度来源入口，没有逐轮展开原始问答、没有写成详细摘要或判断正文；同时确认 `核心上下文.md` 没有重复索引来源清单。
6. 结构归属检查：确认每个关键候选对话已判断为新主题、新模块、归入已有模块、拆分归属、历史案例或升级候选；没有只按标题相似度归类。
7. 依赖关系检查：若本主题依赖多个上游主题，确认必要追溯与索引已写清依赖关系；没有把派生主题强行合并进单一上游主题；也没有把“相关但未引用”的主题写成边界或依赖。
8. 多因成因栈检查：若主题问题由多个独立因素叠加，确认已单列成因栈 / 约束栈；没有把独立因素误写成某一上游主题的派生问题。
9. 完结主题检查：确认用户声明完结的主题只作为历史案例或验证来源，没有继续写入新策略正文。
10. 产物/日志边界检查：确认 `核心上下文.md` 是主题产物本体，`索引.md` 是导航资产，候选筛选、旧新映射、完整事实承诺表、专项交接和主控校验没有混入二者；若需要保留，已进入 `净化日志.md` / `工作记录.md` 或交付说明。
11. 日志落盘检查：确认本次任务属于轻量、标准还是审计；若达到审计或用户要求可追溯，已经落盘净化日志记录；若未落盘，已说明理由和保留的关键风险。
12. 工作区检查：用 `git -C /Users/a1111/Desktop/ai-workspace/cpu-matrix status --short` 汇报相关变更，忽略无关用户改动。

可用 Node 快速检查相对链接；脚本只读文件，不要修改内容。

## 交付口径

最终回复只汇报高信号内容：

- 拉取阶段是否由独立 Subagent 完成；拉取阶段总结中的范围、命令、写入资产和覆盖缺口。
- 拉取了哪些 ChatGPT 对话，写入或确认了哪些 `public/chats/...` 文件。
- 检查或拉取了哪些 Sider 对话；默认最近 30 条中哪些进入整合阶段候选、哪些因缺口暂缓。
- 主题目录中更新了哪些文件。
- `核心上下文.md` 是否已经可以作为主题主入口；若旧 `核心判断.md` 仍存在，说明它是保留、迁移还是暂未处理。
- `索引.md` 是否只作为主题导航资产更新。
- 是否生成或更新了 `净化日志.md` / `工作记录.md`；若没有，说明本次为何只在交付说明中保留关键日志。
- 是否有底层概念改变了架构位置。
- 校验是否通过，以及剩余风险。

如果拉取阶段未由独立 Subagent 完成，要明确说明偏离原因和用户授权；如果整合阶段没有运行独立复核 Subagent，要明确说“已按同一标准主控自检，独立性弱于理想流程”。