cognitive-reorganize

name	cognitive-reorganize
description	从整个工作区出发，系统性地重组认知结构并整理全局文档归属。适用于首次建立认知结构、或积累了大量散落文档需要批量归档时。基于三大闭环框架（Loop1 Skill体系 / Loop2 思维体系 / Loop3 场景投射）做全工作区分类路由。触发词：「系统整理」「重组认知结构」「从文档构建认知结构」「整合文档」「全量梳理」「认知结构乱了」「全工作区整理」「文档归属梳理」「如何加入认知结构」「怎么加入认知结构」「按规范加入」「未更新的文档怎么处理」「这些文档要怎么整理」「有没有关于X的已有文档」。注意：若用户仅询问流程而非执行重组，执行 Step 0.5（检查分类清单现状）后，先向用户展示已有文档状态和分类建议，再确认是否执行完整重组。

认知结构重组 Skill（Cognitive Reorganize）

这个 Skill 编码了「如何从一组散落文档出发，构建完整自洽的认知结构」的完整方法论。 基于 2026-03-19 实际执行过程提炼，见过程记录：认知结构/L3_原始记录/对话记录/认知结构整理过程记录_20260319.md

---

与其他 Skill 的区别

Skill	适用场景
cognitive-capture-fragment	捕捉单个新碎片
cognitive-integrate-fragments	处理积压的待整合碎片
cognitive-reorganize	从零/从大量散落文档构建/重构整个认知结构
cognitive-consistency-check	验证已有认知结构是否自洽

---

激活后立即执行

第零步：创建外部记忆工作草稿

Write: 认知结构/工作草稿_知识图谱构建.md（见文件格式）
作用：AI多轮阅读之间的持久化记忆，不写草稿=信息丢失

---

第零点五步：检查认知结构现有状态（F3修复，2026-03-19）

在扫描任何外部文档之前，先检查 认知结构/ 目录本身：

Step a  枚举 认知结构/ 一级子目录
        → 对照 C11 合法目录列表（见维护协议）
        → 发现任何游离目录 → 立即标记，纳入本次整理范围

Step b  枚举 认知结构/技术架构/（如存在这类特殊目录）
        → 检查其中每个文档是否有对应的 L1/L2 归类
        → 未归类的 → 加入本次 Round A 扫描范围

Step c  检查现有分类清单的 ◑ PENDING 项
        → 这些文档在本次整理中应被处理或主动标记为 ⏸️ DEFERRED

Step d  ⚠️【单文件询问时执行】若触发来源是对「某具体文件」的询问（用户提供了文件名或路径）：
        对该被询问文件执行快速四轴分类，输出推荐结论：

        轴一（Loop归属）判断：
          「这个文件是关于『如何执行某类任务』的规范/指南吗？」
            → 是 = Loop1（.cursor/ 或 _内部总控/开发规范/，不迁入认知结构）
          「这是某个具体工作任务的输入或输出吗？」
            → 是 = Loop3（项目群/ 或 _内部总控/ 工作区，不迁入认知结构）
            → 若含有认知价值段落 → 建议：提取碎片 → cognitive-capture-fragment
          上述均否 → Loop2（认知结构）→ 继续轴二判断

        轴二（认知层次）判断（Loop2 文档）：
          含原创观点/洞见/框架？→ L1（系统性文档）或 L2（碎片化思考）
          外部调研/参考资料？→ REF-EXT（轻量写入协议）
          提炼了底层行为规律？→ L1.5（候选原则）

        轴三（领域维度）判断（L1/REF-EXT 文档）：
          产品机会/用户需求/商业模式 → 产品理论维度
          团队/组织/协作/分工 → 组织理论维度
          科研方法/实验设计/学术 → 研究范式维度
          大脑认知/学习/记忆/神经科学 → 认知科学基础维度
          工程/代码/架构/部署/系统 → 系统架构思维维度
          写作/表达/传播/个人方法 → 个人方法论维度
          自我反思/行为模式 → 自我认知维度
          跨多个领域 → 选主要领域，备注关联

        输出推荐结论（格式）：
        「📍 分类建议：
          Loop归属：[Loop1 / Loop2 / Loop3]
          层次：[L1 / L1.5 / L2 / REF-EXT / Loop1-规范 / Loop3-工作产物]
          维度：[具体维度名]（Loop2-L1/REF-EXT 时填写）
          目标路径：[具体建议路径]
          写入方式：[完整迁移8步（L1）/ 轻量写入3步（REF-EXT）/ cognitive-capture-fragment（L2）/ 保持原位（Loop1/Loop3）]
          
          是否现在执行？[执行] [留待后续]」

        → 用户选「执行」→ 按写入方式执行，或启动完整重组流程
        → 用户选「留待后续」→ 将该文件添加到分类清单中（状态：◑ PENDING，含建议路径备注）

目的： 避免「游离目录」在整理完成后仍游离（F3 漏洞根因）；并确保单文件询问能给出具体可执行的分类推荐，而非仅展示认知结构现状。

---

第一步：建立分类框架（先做这个，再扫描）

在扫描之前，先确认四轴分类框架：

轴一：三大闭环归属（主要路由轴，2026-03-19新增）

Loop 2 — 思维体系（认知结构）
  → 你的原创思考、洞察、手稿、原则
  → AI 调研/综合产出的外部参考资料（REF-EXT）
  → 验证通过的高价值技术发现文档
  测试：「如果被问到『我对X是怎么想的』，这个文档会被检索进来吗？」→ 是 = Loop2

Loop 1 — Skill体系（.cursor/ 固定路径）
  → Skill/Rule/Agent 文件本身（不迁移，固定在 .cursor/）
  → Skill 执行指南、踩坑速查（在 .cursor/skills/*/knowledge/）
  → 开发规范、基础设施手册（在 _内部总控/开发规范/）
  → 引用模板（若有设计价值 → 迁入对应 L1 维度知识库）
  测试：「这是关于『如何执行某类任务』的规范或指南吗？」→ 是 = Loop1

Loop 3 — 场景投射/工作产物（项目群/ 或 _内部总控/）
  → 项目代码、项目工作文档（产品定义、开发计划、DEPLOY_ARCH 等）
  → 工作产物（公众号 HTML、图片、报告输出）
  → 任务日志、运营记录
  测试：「这是某个具体工作任务的输入或输出吗？」→ 是 = Loop3

⚠️ 核心路由原则（来自三大闭环蓝图文档 [3L]）：
  思维方式和原则规范更本质，工作任务空间是其投射。
  「根」放认知结构；「投射」放工作空间。
  公众号 HTML 和项目代码本质一样，都是 Loop3 工作产物。

轴二：认知层次轴（适用于已确认进入 Loop2 的文档）

L0 / L1.5 / L1 / L2 / L3 / REF-EXT / OUT

轴三：领域维度轴（适用于 L1 文档和 REF-EXT 的知识库归属）

产品理论维度      → 产品机会/用户需求/商业模式/产品框架
组织理论维度      → 团队协作/组织结构/分工
研究范式维度      → 科研方法/实验设计/学术
认知科学基础维度  → 大脑认知/学习/记忆/神经科学
技术架构思维维度  → 工程技术/代码/架构/部署/工具（默认技术类归这里）
个人方法论维度    → 写作/表达/传播/个人方法
自我认知维度      → 自我反思/行为模式（待建）
跨维度             → 选使用频率最高的，文档头部注明关联其他维度

轴四：版本状态轴

★CURRENT / ○DUPLICATE / ◑PENDING / ⏸️DEFERRED / ✗OUT

---

REF-EXT 轻量写入协议（v1.1新增）

写入 L1 维度 知识库/ 目录的 REF-EXT 文件，不需要 L1 write-guard 的全套流程，只需三步：

1. 直接写入对应维度的知识库目录（不需要历史备份，REF-EXT 本身不需版本控制）
2. 可选：在知识图谱追加 REF-EXT 节点（若该文档被 L1 文档显式引用则必须追加）
3. 不需要：L0 更新、系统日志、变更记录
原因：REF-EXT 是参考材料，不是认知体系的「真相层」

---

第二步：Round A 浅扫描（全量，快速）

目标：建立所有候选文档的节点表和显式引用边骨架

方法：
  → 读每个文档的：标题+前15行+最后5行+所有显式引用其他文档的句子
  → 每读完一个，立即写入工作草稿（实时追加，不要等全部读完）
  → 不要深读，不要判断关系，只收集事实

每个节点记录：
  节点ID | 文档名 | 来源路径 | 日期 | 性质自述 | 关键主题词 | 显式引用的文档

完成后识别：
  → 同主题文档群（候选聚类）
  → 显式引用边（文档A说「参见文档B」）
  → 版本关系线索（同名不同版本）
  → 三大闭环归属初判（Loop1/2/3 + 层次）

扫描范围（v1.1 扩展为全工作区，按优先级）：
  0. 认知结构/ 现有状态（第零步扫描结果）
  1. _内部总控/产品定义/
  2. _内部总控/AI思维碎片/ 和 AI思维锻炼/ 和 AI思维问题复盘/
  3. _内部总控/论文/
  4. _内部总控/开发规范/（Loop1 文档，不迁移，但记录）
  5. _内部总控/skill-system-design/（Loop1 设计工件，记录归属）
  6. 项目群/*/docs/（只看文档，不看代码）
  7. .cursor/skills/*/templates/ 和 .cursor/skills/*/knowledge/（引用模板，判断是否有REF-EXT价值）
  8. doc/ docs/ profiles/ reference/ web/ 等杂散目录

排除：.git/ node_modules/ *.py *.ts *.tsx *.js *.json *.yml *.dockerfile *.css 等代码文件
排除：*.html（工作产物，Loop3，归档而非迁入）
排除：已经在认知结构★CURRENT 状态的文档（不重复扫描）

工程注意： 使用 Glob 工具列文件，不用 cmd dir（中文路径编码问题）

---

第三步：Round B 聚类精读（分组，深度）

目标：解决Round A发现的聚类内部关系，尤其是DUPLICATE对的版本差异

对每个候选聚类：
  → 同时加载该聚类所有文档的关键段落
  → 精确判断关系类型：
      is_version_of：B是A的迭代版（同主题，B更新）
      extends：B在A基础上增加新内容
      instantiates：B是A的具体应用
      contradicts：B与A对同一事项结论不同
      depends_on：B的论证依赖A的前提
      summarizes：B是A的精华提炼
      cross_references：同一现象的不同视角

对DUPLICATE文档对（v1.1 增加精确对比协议）：
  步骤1  比较文件字节数和修改时间（快速判断哪个可能更新）
  步骤2  同时读取「第一章节」和「最后章节」全文
         → 比较核心主张、结构层次、版本号/日期标注
  步骤3  搜索差异：用 Grep 查找仅在其中一个文件出现的关键词/章节名
  步骤4  明确判断：
         → 若 A 是 B 的子集（B包含更多内容且更新）→ B 为权威版本，A 为旧版
         → 若两者有独立的不重叠内容 → 需要合并，不能简单取一
         → 若结论矛盾 → 标记为 CONFLICT，提交用户决策
  步骤5  确定处理方式：
         → 权威版本 → 迁入认知结构（★CURRENT）
         → 旧版本 → 放入目标位置的 历史版本/ 目录（不是删除）
         → 原始位置 → 添加 redirect 标注

Round B只需AI自己判断，以下情况才提交郑总：
  ✗ 两文档结论矛盾，无法从更高层原则推导谁对
  ✗ 一个文档的「意图」不清楚（郑总为什么写这个）
  ✗ 确实无法区分两个版本的权威性
  ✗ 需要合并两个文档（涉及内容创作决策）

---

第四步：Round C 跨聚类分析

目标：识别跨聚类的关系边和桥梁文档

→ 找到引用了多个聚类的「桥梁文档」（精读这些文档）
→ 确认跨聚类关系类型
→ 判断这些桥梁文档的层次归属（往往是综合类的L1文档）

Round C完成后输出：
  → 完整的知识图谱草稿（写入工作草稿）
  → 所有文档的最终分类清单草稿（层次/领域/版本状态/目标位置）

---

第五步：生成正式分类清单

Write: 认知结构/文档分类清单.md

格式（每个文档一行，v1.1 扩展为全工作区）：
| 文档路径 | 闭环归属 | 层次 | 领域 | 状态 | 目标位置 | 备注 |

闭环归属列：Loop2-认知结构 / Loop1-Skill体系 / Loop3-工作产物 / 暂无法判断

向郑总展示：
→ 所有需要确认意图的UNCLEAR项（不应超过10%）
→ 所有 Loop1/Loop3 中发现的混入认知结构的「误放」文档
→ 所有发现的重复文件及建议处理方式
→ 等郑总确认后继续执行

---

第六步：Phase 1 — 建立目录结构

根据分类清单中出现的新维度，创建所需目录：
  认知结构/L1_系统性文档/[新维度名]/
  认知结构/L1_系统性文档/[新维度名]/历史版本/
  认知结构/L2_碎片化思考/[新类型]/
  认知结构/L3_原始记录/[新类型]/

---

第七步：Phase 2 — 迁移（原子协议，每次一个文档）

每个文档的迁移严格执行8步：

Step a  读取源文档全文，确认分类正确
Step b  在文档开头添加认知结构元数据头：
        ---
        认知层次：[L1/L2/...]
        领域维度：[产品理论/...]
        文档关系：[依赖/被依赖/cross_ref]
        L1.5约束：[P1/P2/无]
        原始来源：[原始路径]
        迁入时间：YYYY-MM-DD
        版本状态：★ CURRENT
        ---
Step c  检查内容是否与L1.5原则（P1/P2）有明显矛盾，有则标注⚠️
Step d  Write: 将文档写入认知结构目标位置
Step e  Write: 在原始文件开头添加redirect标注：
        > ⚠️ 权威版本已迁入认知结构：`[目标路径]`
Step f  创建v1.0版本快照：`目标位置/历史版本/[文档名]_v1.0_YYYYMMDD.md`
Step g  创建变更记录文件：`目标位置/[文档名]_变更记录.md`
        初始条目：[日期] [create] 全文 | 初次迁入认知结构 | [触发原因]
Step h  更新 认知结构/L2_碎片化思考/碎片整合索引.md（L2文档）
        或 认知结构/文档分类清单.md（更新状态 ◑→★）

任何一步失败 → 立即停止，不要继续下一个文档

---

第七点五步：Phase 2.5 — 非认知结构文档的归位（v1.1新增）

对分类清单中 Loop1 和 Loop3 的文档执行归位（不迁入认知结构，但清理误放位置）：

Loop1 文档（开发规范/踩坑速查/Skill模板等）：
  → 若在认知结构内 → 迁出到 _内部总控/开发规范/ 或 .cursor/skills/*/knowledge/
  → 若已在正确位置 → 标注 ✅ 无需迁移
  → 若是「引用模板有REF-EXT价值」→ 在对应 L1 维度知识库里放一份（保持 .cursor/ 里的原本）

Loop3 文档（项目工作文档）：
  → 若在 _内部总控/ 根目录下 → 确认归属项目，迁入 项目群/{项目名}/
  → 若已在 项目群/ 里 → 标注 ✅ 无需迁移
  → 工作产物（HTML/图片/报告输出）→ 保持原位或迁入 项目群/{项目}/outputs/

Loop3 项目文档中「有认知价值的段落」处理：
  → 不整体迁移，但提取核心洞见写入 L2 碎片
  → 原始文档保持在 Loop3 位置不动

⚠️ 所有移动操作都必须在源文件开头添加 redirect 标注，确保可追溯

---

第八步：Phase 3 — 更新L0和知识图谱

更新L0大脑总地图：
  [必须包含框架图！！！— 这是铁律，见维护协议 0.1条]
  → 更新各维度的文档列表
  → 更新框架关系图（如果有新文档改变了关系结构）

更新知识图谱_正式文档.md：
  → 添加新节点（新迁入的L1文档）
  → 添加新关系边（Round B/C确认的关系）

追加系统日志：每次迁移操作一条记录

---

第九步：运行一致性验证

触发 cognitive-consistency-check Skill（现为 C1-C11）
→ 输出 C1-C11 验证报告
→ 修复所有不通过的条件
→ 验证通过后，进入第十步

---

第十步：Post-task Cleanup（F4修复，2026-03-19）

所有验证通过后，必须执行以下收尾操作：

Step a  归档工作草稿
        → Copy: 认知结构/工作草稿_知识图谱构建.md
              → 认知结构/L3_原始记录/对话记录/工作草稿_知识图谱构建_YYYYMMDD.md
        → 原工作草稿可保留（供未来翻阅）或删除（由用户决定）

Step b  处理所有剩余 ◑ PENDING 文档
        → 对每个仍是 ◑ PENDING 的文档，必须做出明确决策：
            - 现在迁移 → 迁移并更新状态为★
            - 主动推迟 → 更新状态为 ⏸️ DEFERRED（附原因和计划时间）
        → 不允许 ◑ PENDING 在整理完成后仍大量存在（超过5个视为未完成）

Step c  更新 L0 大脑总地图（全面，不是局部补丁）
        → 如有新增维度或文档，重写 L0 相关章节
        → 确认 L0 框架图仍然准确（铁律：L0 必须有框架图）
        → 更新「最后更新时间」

Step d  追加系统日志（最终汇总条）
        → [LOG-YYYYMMDD-NN] cognitive-reorganize | 整理完成 | 新增L1N篇/L2N个/L3N个，C1-C11全部通过

本步骤完成 = 本次重组正式结束

---

工作草稿文件格式

# 工作草稿：知识图谱构建

## Round A：节点表
| ID | 文档名 | 路径 | 日期 | 主题词 | 显式引用 |
...

## Round A：显式引用边
| 来源 | 关系 | 目标 | 依据 |
...

## Round B：聚类精读结果
[聚类1名称]
...

## Round C：跨聚类关系
...

## 分类决策摘要
| 文档 | 最终层次 | 判断依据 |
...

---

关键教训（来自2026-03-19实际执行，已编码为规范）

1. 先建分类框架，再扫描：不能一边扫一边改框架，会乱
2. AI自主读文档判断，不问郑总：UNCLEAR项应 <10%，其余都能自己判断
3. 多轮阅读缺一不可：单次顺序阅读无法发现文档间的深层关系
4. 工作草稿是必须的：AI在多次读取之间没有记忆，草稿就是外部记忆
5. 原子迁移协议的8步全部执行：任何一步省略都会导致系统不自洽
6. L0必须有框架图：这是用户恢复上下文最核心的东西，删了等于拆掉地图（已写入铁律）
7. 迁移后必须立即更新分类清单：否则无法通过C5验证（已写入write-guard强制4）
8. 整理前先检查认知结构现有游离目录：避免「孤岛」（已写入Phase 0.5）
9. 整理后必须处理所有◑PENDING：要么迁移，要么标为⏸️DEFERRED附原因（已写入Step 10）
10. 规范是在问题发生后补充的：每次整理都应在结束时审视「有没有新发现的规范漏洞」，并记录和修复

---

与维护协议的关系

本 Skill 实现了 维护协议_自洽规范.md 中「批量操作后必须执行完整验证」的规定。 执行完本 Skill 后，系统应处于完全自洽状态（C1-C10全部通过）。

---

变更记录

2026-03-19 — v1.0 → v1.1 — 全工作区重组增强

根因：原 Skill 只覆盖「把候选文档迁入认知结构」，不处理：全工作区 Loop1/2/3 路由归属、REF-EXT 写入协议、重复文件精确版本对比、工作产物归档分类。用户要求按三大闭环框架做全工作区整理。

修改内容：

• 修改：description → 扩展为全工作区重组，新增触发词
• 新增：Step 1 三大闭环路由框架（四轴分类框架的主轴）+ REF-EXT 轻量写入协议
• 修改：Step 2 扫描范围 → 从局部扩展到全工作区8个区域，明确排除规则
• 修改：Step 3 Round B → 新增精确版本对比5步协议（Grep比较差异、历史快照保留、合并触发用户决策）
• 修改：Step 5 分类清单格式 → 新增「闭环归属」列，新增展示 Loop1/Loop3 误放文档
• 新增：Step 7.5 Phase 2.5 Loop3 归位 → 处理非认知结构文档

验证结果：

• 正向验证：本次执行该 Skill 即为验证（待执行）
• 负向验证：原有 Step 7 Phase 2 的 8 步迁移协议完整保留，不受影响

验证状态：🔵 待验证（执行中验证）

---

2026-03-21 — v1.1.1 → v1.2 — Step 0.5 新增 Step d：单文件询问时执行四轴快速分类

根因：CS-009 沙盘发现：用户问「这个文件怎么加入认知结构」时，Step 0.5 的三个子步骤（a/b/c）均针对现有认知结构状态检查，不对被询问的具体文件执行四轴分类，导致 AI 输出的是「认知结构现状」而非「这个文件应该去哪」。description 承诺「展示分类建议」，但缺少生成建议的步骤——是声明与实现之间的 Gap。

修改内容：

• 新增：Step 0.5d「单文件询问时执行四轴快速分类」——当触发来源是对具体文件的询问时，依次执行 Loop归属判断 → 认知层次判断 → 领域维度判断，输出标准化推荐结论（含目标路径 + 写入方式），并提供「执行 / 留待后续」两个选项
• 修改：Step 0.5「目的」说明 → 补充「单文件询问能给出具体可执行的分类推荐」
• 备份路径：.cursor/skills/cognitive-reorganize/history/SKILL_v1.1.1_20260321.md

验证结果（CS-009 修复后状态）：

• 正向验证：用户说「这个文件 X 怎么加入认知结构」→ AI 执行 Step 0.5d → 输出含目标路径的标准化分类建议（待真实场景验证）
• 负向验证：不带具体文件的「如何整理认知结构」查询 → Step 0.5 只执行 a/b/c，不触发 d，行为与 v1.1.1 完全相同

已知风险：Step d 的「外部参考资料」vs「含原创观点」判断依赖 AI 对文件内容的理解，精度取决于文件前15行的信息密度。文件标题明确时（如「调研_」前缀）可高置信判断；标题模糊时需读取内容才能准确分类。

验证状态：🔵 待真实场景验证

---

2026-03-21 — v1.1 → v1.1.1 — 扩展触发词覆盖自然语言"加入认知结构"类问题

根因：2026-03-21 真实事件——用户问"按照规范，要如何加入？"（指将文档加入认知结构），AI 未加载本 Skill，直接以聊天回复代替 Skill 执行流程（Rule 13 违反）。根本原因：触发词列表不包含"如何加入认知结构""按规范加入"等自然语言表达，导致 Step 0.5（读取文档分类清单）未执行，已有相关文档（组织介绍——三大技术体系详述.md）未被发现。

修改内容：

• 修改：description 中的触发词列表 → 新增「如何加入认知结构」「怎么加入认知结构」「按规范加入」「未更新的文档怎么处理」「这些文档要怎么整理」「有没有关于X的已有文档」六个自然语言变体
• 新增：description 末尾注意事项——若用户仅询问流程，执行 Step 0.5 后先展示已有文档状态，再确认是否执行完整重组（防止过度触发重型流程）

验证结果：

• 正向验证：用户说"这些文档按规范如何加入认知结构"→ AI 应加载本 Skill → Step 0.5 读分类清单 → 提示相关已有文档（待真实场景验证）
• 负向验证："如何加入购物车""如何加入群聊"等非认知结构语境不触发（依赖 Rule 13 上下文判断）

已知风险：触发词扩展后，AI 在边界语境（"加入"一词出现在非认知结构上下文中）需依赖 Rule 12（上下文优先级规则）正确判断意图，不得被 IDE 文件状态劫持。