从零搭建个人 AI 工作台：一个管理者的 3 个月实验

开端：4 月 13 号，一个空目录

2026 年 4 月 13 日，我创建了一个空的 Git 仓库。

不是什么宏大计划的起点。起因很朴素：作为一个管着 14 人团队的一线经理，我每天在会议、消息、文档、项目状态之间切换。信息碎片散落在飞书群聊、日历、文档、代码仓库里。我试过各种工具——Notion、Obsidian、各种 AI 助手——但核心问题从未解决：

AI 不了解我的工作全景。 每次对话都是从零开始。

所以我想试一个不同的思路：不是用 AI 做零散的问答工具，而是让 AI 驻留在我的工作上下文里——了解我的项目、我的人、我的节奏。

那天我写了第一个 AGENTS.md，定义了最初的数据结构。

回头看，那个文件简陋到可笑。但 45 天后，它演化成了一个 200+ 行的完整系统契约。

第一周：从混沌到第一个结构

数据模型的第一个决定

头两天我做了最关键的一个设计决定——Markdown + YAML frontmatter：

---
type: person
name: "某某某"
role: "前端开发"
team: "Design System"
status: active
---
 
## 工作日志
- 2026-04-14: 完成了 xx 组件开发

这个选择的理由：

• AI 可读：frontmatter 是结构化的，AI 可以精确查询
• 人可读：就是普通 Markdown，VS Code 里直接编辑
• Git 友好：纯文本，diff 清晰
• 零依赖：不需要数据库、不需要服务器

头两天我建了 40 个人的档案、注册了 12 个项目、定义了 6 种会议系列。全是手动的——AI 帮我格式化，但建档决策是人做的。

"技能"的概念出现

到第 3 天，我发现一个问题：每次和 AI 对话，我都要重复解释"怎么做这件事"。分析会议有一套流程、采集聊天有另一套、准备 1:1 又是另一套。

于是"技能"(Skill) 的概念出现了——把 AI 应该遵循的流程写成文档，让它每次执行时读取。

第一批 5 个技能：

1. meeting-copilot — 会议分析
2. project-tracker — 项目状态追踪
3. team-pulse — 团队管理辅助
4. chat-collector — 聊天采集
5. chat-analyst — 聊天分析

每个技能就是一个 Markdown 文件，定义了触发条件、执行步骤、输出格式。没有代码。

第一周结束时：40 人档案 + 12 项目 + 5 技能 + 第一版 metadata-spec。大约 80 个 commits。

第二周：SoT 原则——最痛的教训

"谁是对的？"

到第二周，灾难开始了。

AI 会在不同的地方写入同一个信息。比如：张三被分配到 A 项目——这个事实出现在：

• 项目文件的 assignees 字段
• 张三档案的 assignments 列表
• 会议纪要的 action item

三处都写了。然后三处开始不一致。

项目文件说张三还在 A 项目，但张三的档案已经标记他转到了 B 项目。因为 AI 更新了一处，忘了另一处。

这逼出了工作台最重要的设计原则——SoT (单一数据源)：

每个事实只有一个写入点。其他地方只能引用，不能独立修改。

SoT 表看起来简单：

但执行 SoT 的纪律极难。因为 AI 的本能是"顺手就写了"——它不会主动想"这个数据的写入点在哪"。后面我用了 Gate 机制来强制执行（那是另一篇文章的故事了）。

第三周：索引协议——让机器验证一致性

手动维护的极限

20 天后，系统已经有了：

• 40+ 人档案
• 30+ 会议记录
• 12 项目
• 30+ 聊天实体

每个模块有自己的目录和 README 索引。问题是——README 索引和实际文件经常不一致。有时候新建了一个会议但忘了在 INDEX 里注册。有时候删了一个文件但 INDEX 还引用着。

手动维护索引在 50 个实体时就到了极限。

index-protocol 的诞生

我把索引维护交给了机器——一套 Python 脚本：

• index_scan.py — 扫描目录中的实际文件
• index_update.py — 生成/更新 INDEX.md
• index_verify.py — 验证索引与文件系统的一致性

现在全部 7 个模块的索引都由脚本管理：

关键原则：INDEX.md 是脚本的领地，AI 和人都不应该直接编辑它。如果索引不对，跑脚本修复，而不是手动改。

第四周+：Gate 体系——从"应该做"到"证明做了"

可见但未持久化

到第四周，我发现了一个更隐蔽的问题：AI 让我看到了它做了，但底层数据没有真正写入。

AI 输出了漂亮的分析表格，但信号没写到个人 log 文件里。AI 说"已完成"，但字段值还是旧的。

这是 LLM 的结构性缺陷——训练目标是"产出可读输出"，不是"保证数据一致性"。

解法是 Gate 机制：在每个关键操作后，用 Python 脚本扫描文件系统，验证该做的事是否真的做了。失败即中止。

一个月内从 3 个事故推广到了 6 个领域的完整 Gate 体系。从此 "可见但未持久化" 的事故降为零。

45 天后：系统轮廓

到 4 月 30 号——工作台诞生 18 天后的第一个月总结：

数字：

• 650+ commits（两个仓库合计）
• 30 个技能（从 0 到 30，全部是 Markdown 定义）
• 7 个索引模块（全自动化维护）
• 6 域 Gate 体系（机器验证）
• 3 个验证脚本 + 1 个共享库
• metadata-spec 从 v1.0 演到 v1.7

工时分布告诉我什么

4 月的工时统计（12 个工作日，105.2 小时）：

36% 的时间投入在工作台——这说明它不是"顺便搞搞"的副项目，而是一个有实质投入的基础设施建设。但这个比例在逐周下降——第一周可能 60%+，到第四周已经降到 20% 以下，因为基础设施开始自运行了。

第二个月：从建设到使用

5 月开始，工作台从"我在搭建它"变成了"它在支持我"。

典型场景：

• 晨会准备：AI 读取昨日 daily summary + 今日日历 + 各人近期信号，5 分钟出一页管理简报
• 1:1 准备：AI 汇总该成员近 2 周的代码提交、会议发言、聊天信号、待办状态
• 项目状态同步：AI 从 6 个数据源自动聚合，识别偏差和风险
• 周总结：AI 从 5 个 daily 自动生成结构化周报，含工时分配、关键决策、待跟进

这些不是魔法——是 3 个月的数据积累 + 结构化技能定义的复利。

三个认知跃迁

回看这 3 个月，最大的收获不是系统本身，而是三个认知转变：

1. AI 工作台不是应用，是知识结构

很多人想象"AI 工作台"是一个有界面的应用。不是的。它是一组结构化文件 + 一组行为规则。

没有前端、没有后端、没有数据库。就是 Markdown + YAML + Git + Python 脚本。但它比任何应用都更贴合我的工作方式——因为它的"代码"就是我的工作本身。

2. 给 AI 立规矩比给 AI 能力更重要

第一周我想的是"让 AI 能做更多事"。第四周我想的是"让 AI 不要乱做事"。

能力扩展是容易的——写个新技能就行。但约束 AI 的行为（SoT 原则、Gate 验证、反硬凑契约）才是让系统可靠的关键。

3. 数据积累有复利效应

第一周的 AI 协作很弱——因为 AI 几乎不了解我。到第六周，AI 可以说出"基于你最近两周的会议信号，这个人可能有离职风险"——这不是 AI 变聪明了，是数据积累到了可以做推理的密度。

这对你意味着什么？

如果你也是管理者，也觉得现有 AI 工具"不够用"——核心问题可能不是工具不好，而是AI 没有你的上下文。

你不需要搭和我一样复杂的系统。但你可以尝试：

1. 一个结构化的人员目录 — 让 AI 知道你的团队是谁、在做什么
2. 一个 SoT 规则 — 每个事实只写在一个地方
3. 一个每日日志 — 给 AI 积累时间序列数据

这三样东西加起来，可能比任何 AI 产品的升级都更有效。

这个系统仍在演化中。每周都有新的技能被添加、旧的规则被修正。它不完美——但它比我试过的所有现成工具都更接近"AI 真的了解我的工作"的理想状态。