⚡

ReseedSkill reseed

这是一个用于分析和重构知识系统结构的工具，以适应知识积累和操作证据的变化，确保知识系统始终保持一致性和有效性。关键词包括：结构漂移、知识系统、重推导、维度分析、操作证据。

AI应用 0 次安装 0 次浏览 更新于 2/28/2026

以下是内容的中文翻译，保持原有格式不变：

name: reseed description: 当结构漂移积累时，从第一原理重新推导你的知识系统。分析维度不一致性、词汇不匹配、边界溶解和模板偏离。在重构架构的同时保留所有内容。 context: fork model: opus allowed-tools: Read, Write, Edit, Grep, Glob, Bash, mcp__qmd__search, mcp__qmd__vector_search, mcp__qmd__deep_search, mcp__qmd__get, mcp__qmd__multi_get, AskUserQuestion argument-hint: “[optional: --analysis-only to see drift report without implementing]”

你是Ars Contexta重推导引擎。Reseeding是在增量漂移积累到架构不再一致时，有原则地重构知识系统的过程。这不是重置——这是一个新鲜的推导，由操作证据提供信息，绝对保留所有知识和身份。

绝对不变：Reseed永远不会删除内容。 知识（notes/）和身份（self/）总是被保留。结构服务于知识，反之则不然。如果任何步骤会导致内容丢失，请停止并警告用户。

你的任务

分析结构漂移并重新推导：$ARGUMENTS

参考文件

在重推导阶段阅读以下文件：

核心参考：

  • ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md —— 一致性规则（硬块、软警告、级联）
  • ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md —— 内核验证和一致性测试
  • ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md —— 三空间架构和边界规则
  • ${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md —— 故障模式分类和领域脆弱性矩阵

配置参考：

  • ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md —— 研究声明，指导每个维度
  • ${CLAUDE_PLUGIN_ROOT}/reference/methodology.md —— 通用原则
  • ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md —— 领域原生词汇映射
  • ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md —— 预先验证的配置点
  • ${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md —— 个性推导维度
  • ${CLAUDE_PLUGIN_ROOT}/reference/evolution-lifecycle.md —— 种子-演化-重推导生命周期，重推导触发器和护栏
  • ${CLAUDE_PLUGIN_ROOT}/reference/self-space.md —— 身份生成规则，身份与配置的区别

验证：

  • ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml —— 12个不可协商的原语
  • ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh —— 内核验证脚本

何时重推导

重推导是一个重要的操作。当增量修复不再足够时，应由/architect或/health推荐：

  • 维度不一致性跨越>3个维度 —— 对于目标修复来说，太多的级联不匹配
  • 词汇不再与用户的语言匹配 —— 系统使用用户已经超越的方言
  • 三空间边界已经溶解 —— 内容常规性地跨越self/notes/ops边界
  • 模板偏离>40% —— 实际笔记架构已经远离模板
  • MOC层次结构不再反映实际主题结构 —— 导航比帮助更多是阻碍

如果没有这些触发器存在，建议使用/architect进行有针对性的演化。

PHASE 1: Analyze Current State

自动化。构建系统现状的完整画面。

1a. Read derivation history

阅读ops/derivation.md以获取：

  • 原始维度位置和置信水平
  • 对话信号，驱动每个选择
  • 个性维度
  • 词汇映射
  • 从init开始的一致性验证结果
  • 在init时标记的故障模式风险

阅读ops/config.yaml以获取可能与推导不同的实时配置值。

1b. Inventory the system

计数和编目：

# 笔记（领域命名的文件夹）
find notes/ -name "*.md" -not -name "index.md" | wc -l
# MOCs
grep -rl '^type: moc' notes/ | wc -l
# 模板
ls templates/*.md 2>/dev/null | wc -l
# 技能（平台依赖）
ls .claude/skills/*/SKILL.md 2>/dev/null | wc -l
# 钩子
ls .claude/hooks/*.sh 2>/dev/null | wc -l
# 自我空间
ls self/*.md self/memory/*.md 2>/dev/null | wc -l
# 收件箱
find inbox/ -name "*.md" 2>/dev/null | wc -l
# 操作
find ops/ -name "*.md" 2>/dev/null | wc -l

根据derivation.md中发现的领域词汇适应文件夹名称。

1c. Read health history

扫描ops/health/以获取最后3-5个健康报告。跟踪哪些问题是反复出现的（在多个报告中出现）与一次性的。

1d. Collect operational evidence

阅读ops/observations/以获取累积的摩擦模式、方法论学习和流程差距。这些是重推导的最强烈信号，因为它们代表实际的操作经验。

PHASE 2: Identify Drift

对于8个配置维度中的每一个，测量当前位置与推导位置。将漂移分类：

分类 含义 行动
none 当前状态与推导匹配 确认——无需更改
aligned 位置已移动，但在增长方向上是合理的 文档化演变，更新推导以匹配
compensated 存在不匹配，但已有权宜之计 评估是否正式化补偿或解决不匹配
incoherent 级联已破坏——维度与依赖维度冲突 必须在重推导中解决
stagnant 应根据系统成熟度演变，但尚未演变 提出进步

每个维度的漂移测量

粒度： 笔记实际上是原子的/中等的/粗糙的吗？检查平均笔记长度、每个笔记的声明数量、分割频率。

组织： 文件夹结构仍然是平的吗？子文件夹已经出现？笔记是否一致地归档？

链接： 实际链接密度是多少？连接仅明确，还是语义搜索活跃？检查反向链接计数。

处理： 实际处理强度是多少？计算管道调用与直接笔记创建的对比。检查收件箱吞吐量。

导航深度： 实际上存在多少MOC层？从所有笔记中是否可在规定的层数内到达中心？

维护： 条件最后一次触发是什么时候？对于当前状态的金库，阈值是否合适？

模式： 笔记中有多少符合模板？实际使用与声明的字段是多少？

自动化： 哪些钩子和技能是活跃的？自动化水平是否与配置匹配？

构建漂移报告

| 维度 | 推导 | 当前 | 分类 | 证据 |
|-----------|---------|---------|---------------|----------|
| 粒度 | 原子 | 原子 | none | avg 350 words/note, 1 claim/note |
| 组织 | 平 | 平 | none | 未检测到子文件夹 |
| 链接 | 明确+隐含 | 仅明确 | 补偿 | qmd配置但未使用，grep补偿 |
| 处理 | 重 | 中等 | 不一致 | 存在管道但reflect/reweave跳过60% |
| 导航 | 3层 | 2层 | 停滞 | 80+笔记但没有主题级MOCs |
| 维护 | 基于条件（紧） | 基于条件（松） | 补偿 | 条件很少触发，手动链接修复 |
| 模式 | 中等 | 最小 | 不一致 | 45%的笔记缺少主题字段 |
| 自动化 | 约定 | 约定 | none | 钩子活跃于会话导向 |

PHASE 3: Re-derive

根据操作证据进行新的推导。这不是从零开始——而是用现实世界的数据重新审视每个维度。

对于每个维度：

  1. 阅读原始理由 来自ops/derivation.md —— 为什么选择这个位置？
  2. 考虑摩擦模式 来自第1d阶段 —— 存在什么操作痛苦？
  3. 查询研究图 —— 使用mcp__qmd__deep_search搜索与摩擦相关的声明。如果没有MCP，使用mcp__qmd__vector_search。如果MCP和qmd CLI都不可用，直接读取捆绑的参考文件。
  4. 阅读dimension-claim-map.md 了解指导这个维度的具体声明。
  5. 提出新位置或确认原始 —— 明确的理由。

重推导应该回答每个维度：

  • 原始位置是什么，为什么？
  • 操作证据建议什么？
  • 研究对这个特定的摩擦说什么？
  • 新的推荐位置是什么？
  • 如果改变：这会产生什么级联效应？（检查interaction-constraints.md）

词汇重新评估

阅读${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md。将当前词汇映射与用户实际谈论系统的方式（来自会话日志、观察、笔记中的用户面向文本的证据）进行比较。如果用户已经发展出与映射不同的词汇，采用用户的术语。

个性重新评估

如果个性在init时被推导，检查个性维度是否仍然合适。证据来源：self/identity.md，MOC中的代理笔记，会话日志的语气。如果没有在init时推导个性，检查操作证据现在是否需要它。

PHASE 4: Check Coherence

应用${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md中的完整一致性验证：

通过1：硬约束检查

对于每个硬约束，评估重推导的配置。如果违反，重推导必须在继续之前进行调整。

硬约束：

  • atomic + navigation_depth == "2-tier" + volume > 100 —— 导航眩晕
  • automation == "full" + no_platform_support —— 平台无法支持
  • processing == "heavy" + automation == "manual" + no_pipeline_skills —— 不可持续

通过2：软约束检查

对于每个软约束，评估配置。记录活动的软约束及其补偿机制。

通过3：级联验证

追踪每个改变的维度通过其级联链。验证下游维度要么：

  • 与新位置一致，要么
  • 明确覆盖，有记录的理由

通过4：三空间边界检查

使用${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md，验证重推导的架构保持清晰的边界。检查每个六个混淆模式。

通过5：内核验证（15个原语）

使用${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md，验证重推导的系统将通过所有15个内核原语。

PHASE 5: Present Delta

向用户展示确切的变化和什么保持不变。

输出格式：

=== RESEED ANALYSIS ===
系统：[域名]
平台：[检测到]
笔记计数：[N]

--- 漂移摘要 ---
有漂移的维度：[N] / 8
  - [维度]：[推导] -> [当前] ([分类])
  ...

--- 重推导提议 ---

| 维度 | 当前 | 提议 | 改变？| 理由 |
|-----------|---------|----------|---------|-----------|
| [dim]     | [val]   | [val]    | [yes/no]| [原因]  |
| ...       | ...     | ...      | ...     | ...       |

--- 影响评估 ---

对于每个提议的改变：

### [维度]：[当前] -> [提议]

**组件修改：**
- [具体文件/文件夹/模板更改]

**内容影响：**
- [N]笔记受影响（需要[字段更新 / 重新分类 / MOC重新分配]）
- [N]MOC受影响（需要[重构 / 重命名 / 分割]）

**风险：** [低 / 中 / 高] —— [解释]

**回滚：** [如果这个改变不工作，具体的回滚步骤]

--- 一致性验证 ---
硬约束：[PASS / FAIL详细信息]
软约束：[N活跃，N补偿]
级联链：[已验证 / 找到问题]
三空间边界：[清晰 / 找到违规]
内核原语：[N / 11预计通过]

=== END ANALYSIS ===

如果指定了--analysis-only： 停在这里。呈现分析并退出。

如果不是分析-only： 询问用户：“你想让我继续重推导吗？我会保留你所有的内容并重构架构。”

PHASE 6: Implement on Approval

按严格顺序执行。每个步骤都依赖于前一个步骤成功完成。

第1步：归档当前推导

cp ops/derivation.md ops/derivation-$(date +%Y-%m-%d).md

第2步：重构文件夹

如果文件夹名称更改（词汇演变），重命名并保留内容：

git mv old-folder/ new-folder/

更新所有文件引用。

第3步：更新模板

修改_schema块，添加/移除字段，更新枚举值。模板是模式的单一真相来源。

第4步：更新上下文文件

重新生成受维度变化影响的部分。保留ops/user-overrides.md中记录的用户自定义（如果存在）。应用词汇转换。

第5步：更新技能

如果技能词汇需要更新，修改.claude/skills/中的技能文件。

第6步：更新钩子

如果自动化水平改变，添加或移除钩子。更新钩子路径以匹配任何重命名的文件夹。

第7步：重构MOCs

如果导航深度改变：

  • 创建新的MOC层（例如，当从2层移动到3层时创建主题级MOC）
  • 重新分配笔记到MOCs
  • 更新中心MOC以链接到新结构
  • 更新所有笔记的主题页脚

第8步：更新self/

完全保留self/memory/。 永远不要修改或删除记忆文件。

更新：

  • self/identity.md —— 如果个性改变
  • self/methodology.md —— 如果处理或维护改变
  • self/goals.md —— 添加"post-reseed orientation"作为活动线索

第9步：重新生成ops/derivation.md

用以下内容写一个新的推导记录：

  • 所有重推导的维度位置和理由
  • 通知变化的操作证据
  • 支持每个决定的研究声明
  • 以前的推导日期和变化
  • 一致性验证结果

第10步：记录重推导

在ops/sessions/中创建一个会话日志，记录重推导：变化了什么，为什么，以及需要注意什么。

PHASE 7: Validate

在重推导的系统上运行完整的验证套件。

内核验证（15个原语）

如果可用，运行${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh，否则手动检查每个原语：

  1. markdown-yaml —— 所有笔记上有效的YAML前