我花了 11 天，做了 204 次提交，写了 24 万字的结构化内容。
不是在写文档。是在教一个 AI 系统如何理解我的工作全景——然后让它自己变得越来越强。
起因：管理者的认知困境
作为一个一线工程管理者，我每天面对的不是"某个问题怎么解"，而是"20 个不同域的信息怎么拼成一张图"。
14 个直属成员的状态。13 个在管项目的健康度。每周 15+ 场会议的行动项追踪。向上、横向、跨部门的关系维护。还有不断涌入的聊天消息、文档更新、审批流。
这些信息分散在飞书消息、日历、妙记、文档、项目管理工具里。没有任何一个产品能把它们拼在一起给我看。
我试过 Notion、Obsidian、飞书文档、各种笔记工具。问题不在于记录——问题在于关联。人和项目的关系、会议和行动项的追踪、关系的冷热变化——这些靠手工维护根本不可持续。
所以我做了一个不一样的尝试：不是用工具记录信息，而是建一个能理解这些信息的 AI 系统。
基本架构：Markdown + YAML + AI 技能
技术上其实很朴素：
- 数据层：YAML frontmatter（结构化字段）+ Markdown body（叙事内容），所有实体统一格式
- 技能层：27 个专用 AI 技能，每个有明确的触发条件、步骤协议和输入输出规范
- 集成层：通过飞书 API 直连企业通讯录、消息、日历、文档、妙记
没有数据库，没有后端服务，没有前端界面。整个系统就是一个 Git 仓库，通过 AI 对话驱动所有操作。
people/ → 40 人的结构化档案（关系类型、互动信号、1:1 记录）
domains/ → 13 个项目的健康追踪
meetings/ → 42 场会议的完整记录（转写 + 纪要 + 行动项）
knowledge/ → 公司术语、组织架构、领域知识（带确信度分级）
.agents/skills/ → 27 个 AI 技能的定义
整体架构长这样：
到这里为止，它只是一个"结构化知识库"。有意思的部分在下面——图里那两块紫色和蓝色区域。
暗线：七个自成长机制
在搭建这个系统的过程中，我逐渐嵌入了一组让它能自己变强的机制。不是刻意设计的宏大架构——而是在解决一个个具体问题时，自然生长出来的。
机制 1：验证策展（Verification Curator）
最先出现的需求是"怎么知道数据对不对"。
当你有 40 个人的档案、13 个项目的记录、42 场会议的索引——任何一次编辑都可能引入不一致。字段缺失、引用断裂、索引过期。
于是我建了一个验证系统：30 个验证点，覆盖字段规范、引用完整性、索引一致性。它能检测到"某个会议的行动项指向了一个不存在的人员"这样的问题，并自动修复。
有意思的是，这个验证系统也对自身施加同样的契约。它的 SKILL 定义和所有被验证的技能遵循相同的 verification block 格式——R8 原则。但要注意：最终的验证人始终是人类（R9 原则）。AI 检测异常、报告偏差，但所有架构级判定都升级到人做最终裁决。
机制 2：技能侦察与巡逻（Skill Scout）
第二个需求是"怎么发现需要新能力"。
最初设计了 6 个新技能。但在实际使用中，不断冒出新场景：聊天消息也需要采集和分析、Git 仓库的活跃信号也应该被追踪、工时需要从日总结映射到提交系统……
于是"技能侦察"机制自然形成了：在外部资源中搜索参考方案 → 评估适配度 → 私域化改造 → 注册到治理清单。11 天内，从设计的 6 个新技能增长到了 12 个以上——翻倍。
巡逻模式则是定期审视已有技能，看看外部有没有更好的做法。它产出的"技能缺口清单"记录了什么能力还缺失、优先级如何、当前用什么替代。
机制 3：知识发现协议（KDP）
第三个需求是"怎么让系统越用越懂我的公司"。
我制定了一个简单但有效的协议：在处理任何内容时（会议、聊天、文档），AI 都执行四条规则：
- 遇到未知术语 → 查知识库 → 不存在则创建待确认条目
- 遇到组织描述 → 查知识库 → 不一致则标记争议
- 用户陈述新事实 → 确认后写入知识库
- 每次分析结束 → 报告新增/修改的知识条目
关键设计：知识条目有五级确信度和分级时间衰减规则。每条知识记录"最近验证"日期和衰减期（confirmed 180 天，verified 90 天，tentative 30 天），超期则应降级。AI 绝不自行解决知识矛盾——只报告，由人裁决。
坦白说：衰减目前是一个协议而非自动化机制——规则写在文档里，AI 被期望在查询时遵循，但没有脚本强制执行。这是后续需要补的自动化。
这意味着每次使用系统，它的知识基底都在单调递增。
机制 4：结晶（Crystallization）
第四个需求是"怎么把探索成果固化为永久能力"。
在演进过程中，很多设计从"尝试"走向"验证通过"。但如果不做显式的"固化"动作，下次启动新会话时，AI 不知道哪些是已确认的事实、哪些还是实验。
结晶机制解决这个问题：
一旦结晶，新的会话默认从更高的基线开始。这确保了只升不降——你不会因为换了一个 AI 会话而丢失已验证的能力。
机制 5-6：质量门（双门验证）
第五和第六是输入审查和输出验证：
- 执行前：需求定义是否足够清晰？是否可执行？是否可验证？
- 执行后：交付是否符合规范？是否有遗漏？质量指标如何？
这两道门形成了一个"质量棘轮"——通过的标准会随着系统成熟逐步提高。
机制 7：数据自愈（Index Librarian）
最后一个是索引系统的自我修复。4 个 Python 脚本负责扫描、验证、更新、初始化索引。它们有独占写入权限——包括 AI 在内的任何角色都不能直接编辑 INDEX.md。
这个设计看起来保守，但解决了一个关键问题：防止 AI 在"有用"的意图下引入不一致。
七个机制形成的闭环
这七个机制不是孤立的，它们形成了一个完整的循环：
每一轮循环后，系统从更高的基线开始下一轮。知识更丰富、技能更精准、索引更完整。
从系统论的角度，这个设计包含了自组织系统的四个核心属性：
- 负反馈（稳态维持）：验证系统检测漂移并修正
- 正反馈（能力放大）：技能侦察发现新能力并注册
- 涌现（整体大于部分之和）：跨技能链推理产生单个技能无法提供的洞察
- 自指（系统观察自身）：验证系统对自身施加同样的契约标准，但最终裁决权始终在人类手中（R9 原则）
我把它叫做 Homeostatic Evolution——在稳定运行的同时持续进化。
与 Hermes Agent 的对话
在评估这个设计时，我发现了一个非常有趣的开源项目：Nous Research 的 Hermes Agent。
Hermes Agent 也具备自成长能力，而且在某些维度上做得更好：
- 它的进化是全自动的——每 10-15 次工具调用，GEPA（遗传帕累托进化算法）自动优化 prompt 和工具描述，不需要人工触发
- 它的技能生态是开放的——100+ 社区技能，agentskills.io 开放标准
- 它支持多平台交互——Slack、Telegram、Discord，随时随地
但对比之后，我发现两者的本质差异：
Hermes 优化"怎么做事"——让同一件任务执行得更快更好。 我的系统优化"看什么"——让管理者看到的全景图越来越完整和准确。
如果用大脑来类比：Hermes 是小脑（程序记忆，越做越顺），我的系统是前额叶（工作记忆，关联推理）。
它们不是替代关系，而是互补关系。理想的架构可能是：用 Hermes 做执行引擎，用这套知识系统做领域层。
11 天后的坦诚审视
在经过审计后，这个系统的实际评分是 7.5/10。
做得好的地方：
- 统一的实体模型和 SoT（单一数据源）原则
- 5 层技能架构和 47+ 技能间关系映射
- 知识发现协议让知识基底单调递增
- 7 个自成长机制中 5 个有明确运行证据
做得不好的地方：
- 循环不是全自动的——每个环节仍需用户主动触发
- 没有量化进化指标——无法回答"上周比这周强了多少"
- 上手门槛极高——只有我自己能用
- 依赖 AI 模型质量——模型升级/切换可能导致行为漂移
最诚实的评价是：蓝图很完整，运转还不够自动。
给想做类似尝试的人
如果你也想建一个"越用越懂你"的 AI 系统，这是我 11 天学到的几个关键点：
- 先定实体模型，再做 AI。YAML frontmatter 的统一格式比任何 prompt 工程都重要
- SoT 原则必须从第一天执行。每个字段只有一个写入者，否则 AI 会制造矛盾
- 知识需要生命周期。确信度 + 衰减 + 冲突检测是正确的方向——但要注意"写了规则"和"自动执行规则"的差距。我的衰减规则目前还只是协议，没有脚本强制
- 结晶是必需的。如果不显式区分"实验"和"已验证事实"，AI 会混淆两者
- 人类是终止节点。系统可以自检、自修复，但所有架构级判定必须升级到人。AI 的角色是发现异常并报告，不是裁决
最后一点体会：
这个系统最大的价值不在于任何单个技能或机制。而在于每次使用都让它更好用这个事实本身。
在一个所有工具都是"用了就丢"的世界里，一个"越用越懂你"的系统，本身就是一种不同的存在方式。
本文描述的系统是一个个人实验项目，基于 Markdown + YAML + Git + AI 技能构建。核心理念（Homeostatic Evolution、知识发现协议、验证自指性）是可迁移的——你可以用 Obsidian、Tana、甚至 Notion 实现类似的思路，只是深度和自动化程度会有差异。