这篇可以当作"工作台产品线"的总览入口。它不先展开某一个具体管道，而是先回答：为什么我要搭一个让 AI 驻留在工作上下文里的工作台，以及这个系统是怎么在三个月里一步步长出来的。
开端：4 月 13 号，一个空目录
2026 年 4 月 13 日，我创建了一个空的 Git 仓库。
不是什么宏大计划的起点。起因很朴素：作为一个管着 14 人团队的一线经理，我每天在会议、消息、文档、项目状态之间切换。信息碎片散落在飞书群聊、日历、文档、代码仓库里。我试过各种工具------Notion、Obsidian、各种 AI 助手------但核心问题从未解决：
AI 不了解我的工作全景。 每次对话都是从零开始。
所以我想试一个不同的思路：不是用 AI 做零散的问答工具，而是让 AI 驻留在我的工作上下文里------了解我的项目、我的人、我的节奏。
那天我写了第一个 AGENTS.md，定义了最初的数据结构。
回头看，那个文件简陋到可笑。但 45 天后，它演化成了一个 200+ 行的完整系统契约。
第一周：从混沌到第一个结构
数据模型的第一个决定
头两天我做了最关键的一个设计决定------Markdown + YAML frontmatter：
yaml
---
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 个技能：
meeting-copilot--- 会议分析project-tracker--- 项目状态追踪team-pulse--- 团队管理辅助chat-collector--- 聊天采集chat-analyst--- 聊天分析
每个技能就是一个 Markdown 文件，定义了触发条件、执行步骤、输出格式。没有代码。
第一周结束时：40 人档案 + 12 项目 + 5 技能 + 第一版 metadata-spec。大约 80 个 commits。
第二周：SoT 原则------最痛的教训
"谁是对的？"
到第二周，灾难开始了。
AI 会在不同的地方写入同一个信息。比如：张三被分配到 A 项目------这个事实出现在：
- 项目文件的
assignees字段 - 张三档案的
assignments列表 - 会议纪要的 action item
三处都写了。然后三处开始不一致。
项目文件说张三还在 A 项目，但张三的档案已经标记他转到了 B 项目。因为 AI 更新了一处，忘了另一处。
这逼出了工作台最重要的设计原则------SoT（Source of Truth，单一事实来源）：
每个事实只有一个写入点。其他地方只能引用，不能独立修改。
SoT 表看起来简单：
| 数据 | 写入点 | 只读副本 |
|---|---|---|
| 人员分配 | 项目 requirements 文件 | 人员档案 |
| 成员状态 | 人员 README.md | 无 |
| 会议待办 | 会议 README.md | 人员 log |
| 项目健康 | 项目 _snapshot.yaml | 无 |
但执行 SoT 的纪律极难。因为 AI 的本能是"顺手就写了"------它不会主动想"这个数据的写入点在哪"。后面我用了 Gate 机制来强制执行（那是另一篇文章的故事了）。
第三周：索引协议------让机器验证一致性
手动维护的极限
20 天后，系统已经有了：
- 40+ 人档案
- 30+ 会议记录
- 12 项目
- 30+ 聊天实体
每个模块有自己的目录和 README 索引。问题是------README 索引和实际文件经常不一致。有时候新建了一个会议但忘了在 INDEX 里注册。有时候删了一个文件但 INDEX 还引用着。
手动维护索引在 50 个实体时就到了极限。
index-protocol 的诞生
我把索引维护交给了机器------一套 Python 脚本：
index_scan.py--- 扫描目录中的实际文件index_update.py--- 生成/更新 INDEX.mdindex_verify.py--- 验证索引与文件系统的一致性
现在全部 7 个模块的索引都由脚本管理：
| 模块 | 实体数 | 自动化程度 |
|---|---|---|
| meetings | 57 | 100% |
| comms | 35 | 100% |
| summaries | 13 | 100% |
| domains | 18 | 100% |
| people | 48 | 100% |
| knowledge | 60 条目 | 100% |
| learning | 1 | 100% |
关键原则：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 小时）：
| 活动 | 工时 | 占比 |
|---|---|---|
| 工作台建设 | 41.4h | 36.3% |
| 项目管理 | 26.7h | 25.4% |
| 会议 | 13.0h | 12.4% |
| 培训/发展 | 8.4h | 8.0% |
| 其他 | 15.7h | 14.9% |
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 没有你的上下文。
你不需要搭和我一样复杂的系统。但你可以尝试：
- 一个结构化的人员目录 --- 让 AI 知道你的团队是谁、在做什么
- 一个 SoT 规则 --- 每个事实只写在一个地方
- 一个每日日志 --- 给 AI 积累时间序列数据
这三样东西加起来，可能比任何 AI 产品的升级都更有效。
这个系统仍在演化中。每周都有新的技能被添加、旧的规则被修正。它不完美------但它比我试过的所有现成工具都更接近"AI 真的了解我的工作"的理想状态。
本文首发于 www.gaofeiyu.com/ai-workbenc...，外部平台同步发布。