别再让 AI 从零开始了

11 天前，我跟 AI 的协作方式和大多数人一样：打开对话，说需求，拿结果，关掉。每次都从零开始。

现在，当我说"帮我看看某项目最近什么情况"，AI 给我的不是一段通用摘要，而是：

"上周部门会提到该项目预算需要确认（你的行动项，截止明天）。本周团队周会上负责人汇报了技术方案变更。同时技术群里有 3 次架构讨论但尚无结论。建议你先拍板预算，再确认技术方案是否需要同步调整。"

这个回答的每一句话都有数据来源。 不是 AI 在猜，是它读了项目档案、最近三场会议的结构化记录和群聊采集数据后，做出的关联推理。

这篇文章讲的是支撑这种能力的底座——我是怎么设计的、跑出了什么可验证的效果、以及你怎么做一个自己的版本。

我搭了什么

技术方案很朴素：Markdown 文件 + Git 仓库 + AI 对话。没有数据库，没有后端，没有界面。

11 天里做了 219 次 Git 提交。到今天为止：

每个文件遵循统一格式：结构化字段（AI 读来做查询和关联）+ 叙事记录（AI 读来理解上下文）。

28 个技能做什么

我给 AI 写了 28 个"技能说明书"——每个说明书定义这个技能在什么场景下被触发、执行什么步骤、产出什么结果。

按职责分五层：

领域层（直接干活的）：

• meeting-collector 从飞书日历和妙记自动采集会议原始材料
• meeting-copilot 从转写中提取决策、待办、发现，回写到会议记录和关联的人员/项目档案
• project-tracker 追踪项目状态、里程碑和风险
• team-pulse 聚合成员信号、评估团队健康度
• relationship-radar 追踪 41 人的互动频率和关系冷热
• chat-collector + chat-analyst 采集群聊/私聊消息并提取信号
• action-hub 管理所有来源产出的待办（分级、确认、追踪）

核心流程层（编排工作流的）：

• reality-sync 每日全景同步——扫描项目 + 人员 + 会议 + 风险，生成晨报
• entry-router 识别用户意图，把请求路由到对应技能

基座层（连接外部系统的）：

• lark 飞书 API 适配——通讯录、消息、日历、文档、妙记
• repo-scanner Git/代码仓库活跃信号采集
• index-librarian 索引自动扫描、验证、修复

质量层（防止退化的）：

• verification-curator 多维度检查自动扫描数据一致性
• crystallization 把验证通过的方案从实验区搬到事实区
• knowledge-check 检查知识沉淀是否完成
• spec-audit-surface + review-validation-surface 执行前审查 + 执行后验证

治理层（让系统自己变强的）：

• skill-scout 发现新的能力需求，评估外部参考，生成新技能
• skill-squadron 批量审视已有技能，协同优化

这不是一开始就设计好的。最初只有 6 个技能。其余的 22 个是在使用过程中被发现需要、然后逐个搭建的。这个增长过程本身就是证据——系统在自己发现自己需要什么。

它怎么在使用中变强

知识在自动积累

我制定了一个简单的协议：AI 在处理任何内容（会议、聊天、文档）时，遇到不认识的术语就自动在知识库建"待确认"条目。我确认后变正式条目。

证据链：Git 日志 knowledge: add 5 entries (3 company terms + 2 methodology) 和 knowledge: add 3 methodology entries from verification-curator session——这是两次不同会话中知识库自动增长的记录。11 天从 0 增长到 36 条。

每条术语不只是一个定义，而是结构化的：

### T-003: CBU (Cell Business Unit / 基本经营单元)
- 定义: NIO 运营的原子级单元，分 12 大类，三个价值层次
- 来源: 公司官方文档 | 2026-04-16
- 置信度: confirmed ✅
- 交叉引用: domains/active/mytime/, T-040, T-041, T-042

为什么这重要：AI 第一次在会议纪要里看到"CBU"时完全不认识。建了条目后，之后所有涉及 CBU 的分析都自动带上正确的上下文。知识积累是有复利的——每多一条，后续所有分析都更准确。

能力从 6 个增长到 28 个

Git 日志里可以追踪到完整的能力增长线：

04/13  feat: meeting-copilot skill + 6 meeting series        ← 第一批
04/14  feat: project-tracker + team-pulse skills              ← 第二批
04/16  feat: 新增工时管理助手技能                              ← 使用中发现需要
04/18  feat: repo integration + repo-scanner skill            ← 使用中发现需要
04/19  feat: action-hub skill (待办治理中枢)                  ← 使用中发现需要
04/22  feat: add verification-curator skill (L0 meta-capability) ← 数据量大了要自检

不是我一开始就规划了 28 个技能——是用的过程中发现"这里也需要一个技能"。工时要自动填报、代码仓库活跃度要追踪、聊天消息也需要结构化采集——这些需求是在日常使用中自然浮现的。

方案在验证后固化

和 AI 磨合出的有效方案（比如"项目状态同步应该交叉引用哪些数据源"）不能只停留在某次对话里。

我用了一个三区分离的设计：

• specs/20_evolution/active/ = 正在实验的方案
• specs/10_reality/ = 验证通过、已确认的方案
• specs/90_archive/ = 历史归档

只升不降——一旦方案结晶到 10_reality/，新的 AI 会话默认从这个更高的基线启动。不会因为开一个新对话窗口而丢失已验证的方法。

错误在被自动检测

41 人 + 16 个项目 + 51 场会议——数据量大了以后，任何一次编辑都可能引入不一致。

证据链：

04/22  feat(verification): populate catalog.yaml              ← 建立验证目录
04/22  feat(verification): first validate + pilot contracts   ← 首次验证，发现问题
04/23  fix: resolve all INDEX verification issues (88%→100%)  ← 修复到 100%
04/24  docs(verification): 100% achievement report            ← 达成全覆盖

从建立验证体系到全面修复，Git 里有完整的过程记录。检查覆盖字段规范、引用完整性、索引一致性等多个维度，首次全量扫描发现 154 个数据点中有 15 个问题。AI 发现问题并报告，由我决定怎么修。

实际效果（脱敏案例）

案例一：晨报全景

每日启动时，reality-sync 技能自动扫描所有数据域，生成全景晨报。来源可追溯——每条信息标注来自哪个会议/哪个人员档案/哪条待办。

以今天的晨报为例（脱敏）：

📌 今日重点
- [待办 #act-xxx] 某评估截止（今天）——来源: 4/21 会议 actions[2]
- 2 个需求明天到期——来源: domains/active/ deadline 字段
- 重点待办一览（只显示我关注的，不是全量倾倒）——来源: issues/ + meetings/ 聚合

⚠️ 关注信号
- 与某跨部门同事最后互动 14 天前——来源: people/xxx/ last_interaction
- 某项目上周会议的 3 个行动项无更新——来源: meetings/xxx actions[].status

关键区别：不是 AI 凭感觉总结的，是从结构化数据中聚合的，每条都能回溯到具体文件和字段。

案例二：跨源信号发现

chat-analyst 技能从 14 个人的群聊/私聊消息中提取了 70 个信号（Git 记录: feat(chat-analyst): complete P2P signal extraction — 14 entities, 70 signals）。

这些信号被写回到对应人员的档案，和会议记录中的行为观察交叉验证。AI 在做人员分析时可以说：

"这个人最近在 XX 群的发言频率上升（聊天信号），但在 YY 周会中连续沉默（会议记录），建议确认是否有角色偏好变化。"

两个独立数据源的交叉验证——这种洞察不是靠"聪明的 prompt"做出来的，是靠足够丰富的结构化上下文做出来的。

案例三：数据健康度检查

verification-curator 首次全量验证时发现索引健康度还不够理想——部分人员索引缺失字段、会议索引条目与实际文件不一致。

修复过程完全可追踪：Git 里有对应的 fix commit，记录了每次修复了什么、修复到什么程度。目前主要的数据模块健康度都在 95% 以上，但仍有持续优化的空间。

如果没有自动检测，这些"小毛病"会让 AI 输出悄然变差——但你不知道为什么。

案例四：一周 8 场会议，怎么不让信息散掉

这是我感受最深的痛点。

我每周固定的系列会有团队周会、部门周会、跨部门周会、项目例会等，再加上临时的需求宣讲、技术评审、专项沟通——一周轻松 8 场以上。以前的状态是：周一的会上说了什么，到周三已经模糊了；同一个项目在三个会上分别聊了不同维度，但我脑子里串不起来。

我的会议结构长这样——同一个项目和同一个人会反复出现在不同会议里：

同一个项目的信息从三个层级的会议汇聚到一处；同一个人的待办也从不同会议写入同一份档案。

现在的做法：每天结束后说一句"采集今天的会议"，AI 自动从飞书拉取转写文本归档。然后让它分析，每场会议提取两种东西——决策和待办（具体到谁、做什么、什么时候截止），以及六类与我相关的信号（需要我拍板的、机会点、风险、项目进展等）。

22 场会议分析下来，产出了 94 条决策、125 条待办。

但真正改变我工作方式的不是这些数字，是关联。

同一个项目被自动串联。比如某个项目，在部门周会上讨论了资源问题，在项目例会上讨论了技术方案，在团队周会上汇报了进度。以前这三个信息散落在不同会议的笔记里，我要手动拼。现在，三场会议的决策和待办都自动关联到同一个项目档案，我看项目状态时就能看到完整的全景。

同一个人的承诺被自动追踪。比如某成员在上周部门会上被指派了一个任务，这周团队周会上又新增了一个待办。这两条信息都写入了他的档案。当我需要了解他的工作负荷时，不需要回忆"他最近有什么在做"——档案里有完整的、来自不同会议的待办清单。

我缺席的会议也不会断档。有一次我请假没参加团队周会，结果某个项目被跳过没讨论、几个需要我决策的事也搁置了。这些信息全部在分析后出现在"需要我支持"的清单里，回来后我第一时间就知道要补位什么。

证据链：Git 里 feat(meeting-copilot): step-03 writeback for 2 analyzed meetings 记录了信息回写到人员和项目的过程。

这套流程的额外工作量几乎为零——每天两句话。但它解决的是一个日积月累的信息熵增问题：会议越多，散落的信息越多，传统做法下你的信息管理开销呈指数增长。结构化采集 + 自动关联把这个增长拉平了。

和你在用的 AI 工具有什么不同

最接近的是微软 365 Copilot 和 Glean——也在做跨源关联和知识管理。开源方面 Hermes Agent 有自动化的执行优化（GEPA 算法每 10-15 次调用自动优化），但它优化的是"怎么做事更快"，这里优化的是"看到的全景更完整"。两者方向不同，有互补可能。

你怎么做一个自己的版本

不需要搭 28 个技能。你可以从最简单的方式开始：

Level 1：AI 备忘录（5 分钟起步）

创建一个文档，写下你的工作上下文和 AI 常犯的错：

## 关于我
- XX 部门，管 N 个人
- 目前关注 A、B、C 三个项目
- 上级是 YY，每周三有周会
 
## AI 请注意
- "CBU"是基本经营单元，不是某个系统名
- XX 项目已经决定用方案 B
- 我偏好结论先行的沟通方式

每次对话时贴进去。你会明显感觉到 AI "听懂了"。

Level 2：结构化会议记录（每次 2 分钟）

每次重要会议后写下三样：决策、待办、发现。

积累 10 次后让 AI 帮你找矛盾和关联。你会看到"上月说的和这周说的矛盾了"这种靠记忆力抓不到的东西。

Level 3：人员档案

给关键协作者建简单文档：在做什么、最近观察、沟通中的关键结论。需要和某人对齐前贴给 AI——输出会从"通用建议"变成"知道上下文的具体准备"。

Level 4：知识标确信度

给知识加标签：✅ 已确认、🟡 待确认、🔴 有争议。告诉 AI 区分这些级别。你的 AI 就不会再"自信地说错话"了。

核心公式：

结构化记录 × 持续写回 × 每次对话都带上 = AI 越来越懂你

坦诚的不足

1. 初始录入花了两天。第一次结构化 41 个人和 16 个项目需要耐心
2. 不是全自动的。多数环节仍需我主动触发
3. 有些设计还只是协议。比如知识衰减规则写了但没有脚本自动执行
4. 依赖 AI 模型质量。换模型可能导致行为差异

但——每次使用，它都比上次更好用。而且这个"变好"是可以在 Git 日志里看到的。

邀请

如果你想试，最小的起步：

今天跟 AI 对话后，把你纠正的事实写进一份备忘录。下次对话带上它。

你会感受到差距。如果有兴趣聊更多，找我——完整模板、踩过的坑、哪些设计值得投入，都可以分享。

P.S. 技术细节版（28 个技能的架构设计、验证系统完整 Mermaid 图、知识发现协议规范）另有一篇，感兴趣找我。