Mindcraft：从个人实践到可复用模式集
英文标题：Mindcraft：从个人实践到可复用模式集
一个人的 AI 系统实践，如何提炼为别人也能用的东西？答案不是'开源代码'——是'开源模式'。Mindcraft 是从 3 个月个人工作台运营中提取的 5 维度可复用模式集。
3.2 KB
589 B
12.8 KB
10.7 KB
7.7 KB
11.9 KB
中文
从"我的系统"到"可复用的模式"
我的 AI 工作台跑了 3 个月，积累了：
- 30 个技能
- 7 个索引模块
- 57 次会议归档
- 3 套验证脚本
这些东西对我有价值——但对别人呢？
直接把仓库给别人是没用的——它和我的工作场景深度耦合。别人拿过去用不了。
真正可复用的不是代码——是模式。
什么是"模式"
模式 = 经过验证的解决方案 ，解耦了具体业务场景，但保留了核心设计决策。
模式和代码的区别 ：
- 代码告诉你"怎么实现"
- 模式告诉你"为什么这样设计" + "什么场景该用" + "关键陷阱是什么"
五维度架构
Mindcraft 把 AI 知识系统的模式分为 5 个维度：
| 维度 | 回答的问题 | 核心模块 |
|---|---|---|
| ① 技能生命周期 | 如何管理 AI 能力的增删改？ | skill-scout + skill-squadron |
| ② 结构完整性 | 数据增长时如何保持一致？ | index-protocol + index-librarian |
| ③ 验证体系 | 如何让系统自检？ | verification-curator + spec-audit |
| ④ 需求→方案→落地 | 变更如何走完闭环？ | requirement → spec → crystallization |
| ⑤ 协调协议 | 多模块如何不冲突？ | SoT + KDP + action-governance |
每个维度包含什么
维度 ①: 技能生命周期
提供 : 2 个技能模板 + 1 个治理清单格式 + 巡逻检查项
你用它可以：
- 定义一个新技能（有标准字段、有触发条件、有边界声明）
- 注册到治理清单（关系图、状态、依赖）
- 定期检查所有技能的健康度
维度 ②: 结构完整性
提供 : 1,600 行 Python 脚本 + 协议文档
你用它可以：
- 扫描目录自动生成索引
- 验证索引和文件系统是否一致
- 增量更新不全量重建
真实提取案例: index-protocol
工作台中的原始实践 ：我管理 6 个数据模块（会议/通讯/总结/项目/人员/知识库），每个模块有 INDEX.md 索引文件。最初索引是手动维护的——新增文件后忘记注册到 INDEX.md 是常态。于是写了 4 个 Python 脚本做自动化。
提取为 Mindcraft 模式时做了什么 ：
| 维度 | 工作台中（耦合） | Mindcraft 中（通用） |
|---|---|---|
| 目录结构 | 绑定 meetings/, people/ 等 |
配置化 registry.yaml |
| 文件格式 | 只处理 YAML frontmatter | 支持插件化 parser |
| 验证规则 | 硬编码 7 条业务规则 | 规则引擎 + 可配置 |
| 输出格式 | 特定 Markdown 表格 | 模板化输出 |
运行证据 （来自 11 天实际数据）：
- 6 个数据模块全部纳管，平均索引健康度 93%
- 154 个数据点，89% 验证通过率
- 最低模块 71%（自动标记为优化目标）
- 0 次手动索引编辑（完全脚本驱动）
这个例子说明了"提取"不是"复制粘贴"——是去掉业务假设，保留操作模式 。原始脚本只有我能用（因为路径、格式都写死了）；抽象后，任何 Markdown + YAML 的知识库都能用同一套 scan → verify → update → re-verify 循环。
维度 ③: 验证体系
提供 : 验证脚本架构 + Gate 设计模式
你用它可以：
- 为每个关键操作配一个验证脚本
- 用退出码作为唯一通行证
- 分层验证（数据完整性→逻辑一致性→行为合规性）
维度 ④: 需求→方案→落地
提供 : 3 个流程阶段定义 + 交接协议
你用它可以：
- 在模糊需求中找到边界（需求收敛）
- 从边界到可执行方案（方案设计）
- 把验证后的结论固化为文档（结晶）
维度 ⑤: 协调协议
提供 : 3 套跨切面规则
你用它可以：
- 多技能写同一文件不冲突（SoT + R1-R4）
- 遇到未知术语自动记录（知识发现协议）
- 待办三级分流不丢失（行动治理协议）
和"开源项目"的区别
| 维度 | 典型开源项目 | Mindcraft |
|---|---|---|
| 形态 | 可运行的代码 | 模式+模板+脚本 |
| 使用方式 | clone → install → run | 阅读 → 选择适用的 → 适配到自己场景 |
| 耦合度 | 依赖框架/语言/生态 | 语言无关（协议是 Markdown） |
| 灵活度 | fork 后改 | 只取你需要的维度 |
| 验证基础 | 单元测试 | 真实运行 3 个月的数据 |
核心原则 : 不要一次用 5 个维度。从你最痛的那个问题开始——如果是"数据乱了"就先用维度②，如果是"技能打架"就先用维度⑤。
总结：个人实践的价值不止于"我用着好"——提炼为模式后，它变成了可传播的知识 。Mindcraft 不是一个产品，是一本"经过验证的答案集"。你遇到的问题我大概率也遇到过，你可以直接用我踩过坑后收敛出的解法。
English / 原文
从"我的系统"到"可复用的模式"
我的 AI 工作台跑了 3 个月，积累了：
- 30 个技能
- 7 个索引模块
- 57 次会议归档
- 3 套验证脚本
这些东西对我有价值——但对别人呢？
直接把仓库给别人是没用的——它和我的工作场景深度耦合。别人拿过去用不了。
真正可复用的不是代码——是模式。
什么是"模式"
模式 = 经过验证的解决方案 ，解耦了具体业务场景，但保留了核心设计决策。
模式和代码的区别 ：
- 代码告诉你"怎么实现"
- 模式告诉你"为什么这样设计" + "什么场景该用" + "关键陷阱是什么"
五维度架构
Mindcraft 把 AI 知识系统的模式分为 5 个维度：
| 维度 | 回答的问题 | 核心模块 |
|---|---|---|
| ① 技能生命周期 | 如何管理 AI 能力的增删改？ | skill-scout + skill-squadron |
| ② 结构完整性 | 数据增长时如何保持一致？ | index-protocol + index-librarian |
| ③ 验证体系 | 如何让系统自检？ | verification-curator + spec-audit |
| ④ 需求→方案→落地 | 变更如何走完闭环？ | requirement → spec → crystallization |
| ⑤ 协调协议 | 多模块如何不冲突？ | SoT + KDP + action-governance |
每个维度包含什么
维度 ①: 技能生命周期
提供 : 2 个技能模板 + 1 个治理清单格式 + 巡逻检查项
你用它可以：
- 定义一个新技能（有标准字段、有触发条件、有边界声明）
- 注册到治理清单（关系图、状态、依赖）
- 定期检查所有技能的健康度
维度 ②: 结构完整性
提供 : 1,600 行 Python 脚本 + 协议文档
你用它可以：
- 扫描目录自动生成索引
- 验证索引和文件系统是否一致
- 增量更新不全量重建
真实提取案例: index-protocol
工作台中的原始实践 ：我管理 6 个数据模块（会议/通讯/总结/项目/人员/知识库），每个模块有 INDEX.md 索引文件。最初索引是手动维护的——新增文件后忘记注册到 INDEX.md 是常态。于是写了 4 个 Python 脚本做自动化。
提取为 Mindcraft 模式时做了什么 ：
| 维度 | 工作台中（耦合） | Mindcraft 中（通用） |
|---|---|---|
| 目录结构 | 绑定 meetings/, people/ 等 |
配置化 registry.yaml |
| 文件格式 | 只处理 YAML frontmatter | 支持插件化 parser |
| 验证规则 | 硬编码 7 条业务规则 | 规则引擎 + 可配置 |
| 输出格式 | 特定 Markdown 表格 | 模板化输出 |
运行证据 （来自 11 天实际数据）：
- 6 个数据模块全部纳管，平均索引健康度 93%
- 154 个数据点，89% 验证通过率
- 最低模块 71%（自动标记为优化目标）
- 0 次手动索引编辑（完全脚本驱动）
这个例子说明了"提取"不是"复制粘贴"——是去掉业务假设，保留操作模式 。原始脚本只有我能用（因为路径、格式都写死了）；抽象后，任何 Markdown + YAML 的知识库都能用同一套 scan → verify → update → re-verify 循环。
维度 ③: 验证体系
提供 : 验证脚本架构 + Gate 设计模式
你用它可以：
- 为每个关键操作配一个验证脚本
- 用退出码作为唯一通行证
- 分层验证（数据完整性→逻辑一致性→行为合规性）
维度 ④: 需求→方案→落地
提供 : 3 个流程阶段定义 + 交接协议
你用它可以：
- 在模糊需求中找到边界（需求收敛）
- 从边界到可执行方案（方案设计）
- 把验证后的结论固化为文档（结晶）
维度 ⑤: 协调协议
提供 : 3 套跨切面规则
你用它可以：
- 多技能写同一文件不冲突（SoT + R1-R4）
- 遇到未知术语自动记录（知识发现协议）
- 待办三级分流不丢失（行动治理协议）
和"开源项目"的区别
| 维度 | 典型开源项目 | Mindcraft |
|---|---|---|
| 形态 | 可运行的代码 | 模式+模板+脚本 |
| 使用方式 | clone → install → run | 阅读 → 选择适用的 → 适配到自己场景 |
| 耦合度 | 依赖框架/语言/生态 | 语言无关（协议是 Markdown） |
| 灵活度 | fork 后改 | 只取你需要的维度 |
| 验证基础 | 单元测试 | 真实运行 3 个月的数据 |
核心原则 : 不要一次用 5 个维度。从你最痛的那个问题开始——如果是"数据乱了"就先用维度②，如果是"技能打架"就先用维度⑤。
总结：个人实践的价值不止于"我用着好"——提炼为模式后，它变成了可传播的知识 。Mindcraft 不是一个产品，是一本"经过验证的答案集"。你遇到的问题我大概率也遇到过，你可以直接用我踩过坑后收敛出的解法。