三级产品化
大多数"个人工具"死在"只有作者能用"这个阶段。
我的 AI 系统也面临同样的风险——它和我的工作场景深度耦合，充满了只有我自己懂的约定。
但我有一个清晰的产品化路径：
Level 1: 工作台（my-smart-workbench）
定位: 我的私域 AI 系统
特点：
- 完全耦合我的工作场景（会议/项目/团队/关系）
- 30 个技能为我的日常定制
- 数据模型绑定我的组织结构
- 不可能直接给别人用
价值: 每天节省 2-3 小时的信息处理和管理工作。
Level 2: Mindcraft（模式集）
定位: 从工作台中提取的可复用模式
提取过程：
- 识别哪些设计决策是通用的（vs 特定于我的场景）
- 把通用部分抽象为模式（模板+协议+脚本）
- 脱耦具体业务实体
- 补充指南文档（让没有上下文的人也能理解）
产出: 5 维度模式集 + 9 个技能模板 + 3 套协议 + 工具脚本
Level 3: Cocreation Framework（通用框架）
定位: AI-Human 协作的通用方法论
这一层更抽象——不关心"你在管什么"，关心**"人和 AI 如何协作"**：
| 维度 | Cocreation 关心的 |
|---|---|
| 职责分配 | 什么由 AI 做、什么由人做 |
| 质量保证 | 如何验证 AI 的产出 |
| 迭代模式 | 如何从 AI 草稿到人类终稿 |
| 知识沉淀 | 如何把协作过程变成可复用资产 |
每一级的受众
| 级别 | 受众 | 他们能得到什么 |
|---|---|---|
| L1 工作台 | 只有我 | 日常效率工具 |
| L2 Mindcraft | AI 系统建设者 | 经过验证的设计模式 |
| L3 Cocreation | 所有 AI 使用者 | 协作方法论 |
产品化的关键挑战
挑战 1: 什么该提取、什么不该
不是所有东西都值得模式化。判断标准：
| 条件 | 提取 | 不提取 |
|---|---|---|
| 3+ 次被其他人问"你这个怎么做的" | ✅ | |
| 只适用于我的组织结构 | ❌ | |
| 解决了一个通用问题 | ✅ | |
| 实现依赖特定技术栈 | ❌ (除非能配置化) | |
| 经过了真实场景验证 | ✅ |
挑战 2: 脱敏 vs 保留细节
模式要有足够细节才有价值——但太多细节就会暴露私域信息。
解法: 脱敏后用等价示例替代。比如原来是"某企业 IM 消息采集"，模式中变成"消息系统适配器"——保留了设计决策，去掉了具体实现。
挑战 3: 维护成本
三级产品需要同步维护吗？
答案是选择性同步——只有当变更影响通用模式时才向上传播。
当前进展
| 级别 | 状态 | 开源状态 |
|---|---|---|
| L1 工作台 | 运行 3 个月，日常使用 | 私有（永远不会开源） |
| L2 Mindcraft | 初版完成，5 维度结构化 | 准备中（脱敏+文档） |
| L3 Cocreation | v0.2，基本框架+示例 | 已公开 |
教训
- 先跑起来再提炼 — 不要一开始就想着"做通用的"。先做只有你能用的，用 3 个月，然后再提炼
- 模式比代码有生命力 — 代码会过时（框架升级/API 变化），但设计模式可以活很久
- 三级不需要同时做 — L1 跑稳了再提取 L2，L2 有反馈了再升级 L3
- 最好的文档是真实案例 — 不要只写"应该怎么做"，要写"我实际怎么做的+踩了什么坑"
路径总结：个人工具 → 可复用模式 → 通用框架，这个三级路径的核心不是"抽象"——是"验证"。每一级都必须在真实场景中被验证过，才有资格向上升级。没有 L1 的 3 个月实践，L2 就是纸上谈兵。