六十人公司的 AI 运行体系

1. 全图：两个位置、四个执行者、一次会话
2. 安装：每台机器装一次，每人存一个地址
3. 开工：每次会话先确认项目
4. 事实：一个项目只有一份
5. 衔接：技能声明输入，程序检查输入
6. 分工：机械事实归程序，内容归模型，判断归人
7. 规则：按适用范围分层
8. 沉淀：经验回流，越用越强
9. 造能力：成员自己造新技能
10. 行动：接在协作平台上，直接做事
11. 发布与归属：新东西放哪
12. 演化：五个月，两次收窄
13. 现状：分三档说

全图：两个位置、四个执行者、一次会话

每样东西放在两个位置之一，判别标准只有一条：换一家公司，它还成立吗。

• 成立的放插件仓库。插件仓库公开，每台机器装一次。
• 不成立的放项目云盘。每个项目一份。
• 两个位置之间只有一个接口：技能声明自己要读什么，项目档案登记这些东西在哪。

四个执行者各做一类事，职责不重叠。

技能分三类。

• 平台技能，七件：管这套系统自己怎么运转。
  • 会话入口
  • 项目就绪检查
  • 材料提炼
  • 三个造东西的技能
  • 一个记录插件问题的技能
• 工作技能，十六件：对应业务里的一个环节。判定标准：一个动词短语能说清，换一个客户还会发生。
• 方法技能，四件：不对应任何环节，是多个环节共用的判断标准，被工作技能引用。

安装：每台机器装一次，每人存一个地址

项目的事做一次，个人的事各做一次。

• 项目立项时，全部事实放进项目云盘，一份项目档案登记每样东西的地址。
• 每个成员的机器上只存一个配置文件，记项目档案的地址。有多少成员就有多少份配置，项目档案只有一份。
• 档案改一处，下次干活时自动拿到新的，不用互相通知。
• 新成员加入只做个人侧的几步，项目侧不用重做。

本机不保存检查结论，每次会话重新读。

• 配置文件只有三项：
  • 结构版本
  • 项目档案的地址
  • 个人初始化完成日期
• 本机另有一份只读缓存，每次会话重新拉取；拉不到就清空，只留一行失效说明。
• 不做「一次检查管一天」。理由：
  • 授权几小时就过期。
  • 表格会被挪走。
  • 存下来的结论坏了没有提示。
• 每次花几秒重读，换来 AI 永远不拿过期地址干活。

开工：每次会话先确认项目

成员打开 AI 不需要记命令，启动脚本和入口技能替他把项目找到。

• 启动脚本在每次会话开始时，把入口技能的全文加载给 AI。
• 入口技能做三步：
  • 确认当前项目。
  • 调用程序做判定。
  • 按判定结果引导下一步。
• 判定由程序完成，入口技能只读程序输出的几行结果。

常驻说明是每次会话都必须在场的一段文字。

• 内容有两部分：
  • 这家公司做事的几条基本原则。
  • 一条记录规矩：每个判断当场记三项，判断是什么、依据是什么、赌注是什么。
• 位置：
  • 模版在插件仓库。
  • 实例在本机，写在项目目录里 AI 说明文件的一个标记区内。
  • 系统只改标记区内，区外一字不动。
• 更新：改模版并推送，更新插件即得新版。

已知缺口：入口技能只覆盖已经在项目里的成员。不在任何项目里的成员会被要求确认项目，却没有项目可确认。2026-08-20 实测暴露，见演化一节。

事实：一个项目只有一份

项目云盘里有三层东西。

• 原始材料：转成机器可读的格式，逐件登记。
• 项目事实文件：从原始材料提炼出的结构化事实，一组基础文件，每条标注出处。提炼四步：
  • 并行抽取
  • 装配成台账
  • 逐条对照原文核对
  • 独立评审
• 规则：对产出的约束。规则一节单讲。

三条纪律区分「适合 AI 读的知识库」和「一堆文档」。

事实文件分两层，新文件先按最小范围放，被第二个技能用到时自动升格。

• 共享层：对所有技能开放，技能要用哪一份就在自己的输入清单里点名。
• 专用层：只有声明它的那一个技能能读。
• 升格规则：一份专用文件出现第二个读者，当天就升为共享文件。文件和链接不动，只在共享文件的索引里补一行。

衔接：技能声明输入，程序检查输入

环节之间的交接由程序校验，不靠人沟通。

• 原来的问题：上游做完发到群里，下游自己找，找到的常常是旧版本。
• 技能侧：每个技能的说明里带一份输入清单，写明要读哪些输入，只写类型和可用条件，不写地址。
• 项目侧：项目档案登记这些输入在本项目里的地址。
• 开工前：跑一条检查命令。程序把输入清单逐项对照档案登记，逐个地址检查存在与可打开。
  • 通过：输出全部地址。
  • 不通过：输出缺什么、谁能补。
• 结果：每一步读到的东西就是上一步的输出，每一步都能点出名字。

输入只有三条出路。

两条附带规矩。

• 替换已登记地址的文件，必须在原文件上就地改内容，不许新建文件替代。理由：新建文件会换掉链接，别人登记的地址就断了。
• 副产品是一张依赖图：登记进档案的输入有三十九种，哪份事实被最多技能要读，图上能直接看出来。

分工：机械事实归程序，内容归模型，判断归人

有一类判定既不该人做，也不该 AI 做：文件在不在、打不打得开、版本对不对、登记齐不齐。

• 交给 AI 做：同样的输入两次可能得到不同结果。
• 写死成程序做内容判定：不灵活。
• 所以定一条判别标准，任何新逻辑出现时用它决定归哪边：
  • 结果不依赖内容理解、两次运行必然同一个答案的，进程序。
  • 需要读内容、问人、权衡的，写进技能说明，由 AI 执行。

程序只有一份，只判定，不修复，不归任何技能。

• AI 看不到程序本身，只看到它输出的几行结果。
• 程序只判定四类机械事实。输入清单里的可用条件由 AI 在技能开跑时逐条判定。
• 不归任何技能的理由一：每个技能都要用它。归了某个技能，其他技能就要引用别人的内部路径，那个技能一改目录，全部断链。
• 理由二：修改判定规则等于修改程序并发布，任何技能都不用改。
• 这条分工 2026-08-14 决定，08-17 一天做完。
• 改造时发现，原来散在各技能说明里的判定逻辑有几处互相矛盾。原因：同一条规矩写在一个具体场景里，读起来像通则。程序化把这些矛盾一次性暴露出来。

人在七个点上出手，分三类。系统的进度就是这张表上划掉了几行。

守线的三条规矩。

规则：按适用范围分层

规则不写进技能说明，按项目标签逐层加载。

• 一条判断被外化之后，形式是一条 AI 能执行的规则。
• 不写进技能说明的理由：「产出必须是什么、不许是什么」随客户变、随产出类型变。
• 技能只声明自己运行时要加载哪几层；规则按项目标签加载，多层叠加。

分层里最重要的动作是把新规则放进正确的层，「越用越强」指的就是它。

• 一个项目里学到一条新规则，先判断适用范围，再放进对应的层。
• 适用于一类客户的放进那一层，同类所有客户立即受益；只对一个客户成立的留在它自己的层。
• 结果：下一个同类客户接入时，自动继承这一层已积累的全部规则。

沉淀：经验回流，越用越强

复盘的作用是把人做过的判断变成规则，归处用两个问题连续判定。

方法技能单独成一类，因为另外两种放法都不可行。

• 抄进每个用到它的技能：改一处要改多处，各份副本必然不一致。
• 做成某一个技能的附件：其他技能要引用别人的内部路径，和程序不归任何技能的理由相同。
• 立不立方法技能只看两个条件：换一个客户还成立，不止一个环节要用。两个都满足才立。

沉淀回路还有两个部件。

造能力：成员自己造新技能

三个「造东西的技能」让成员不经过我就能加新能力。

• 问题：每加一个能力都要经过我，公司只是把对老师傅的依赖换成对我的依赖，判断从一个人脑子搬进另一个人脑子。
• 做法：成员直接调用造东西的技能，技能带着成员走完每一道需要判断的关口。「造能力」这件事本身也外化了。

看板那条规矩的两点理由。

• 一块没有人会因它改变动作的看板不只是白做，它还会让人以为「我们在看数据」，而这个印象是假的。
• 看板上的数分三类，分类标准是机器能不能自己重算出同一个答案：
  • 直接取到的。
  • 机器能算出的。
  • 需要人判断的。

造技能要过五道关。

进库前过二十三条标准，二十条机械可查，三条需要人评审。

• 机械可查的二十条：读一份技能说明就能按字面判定过或不过。
• 需要人评审的三条，能机械判定的条目全部归入前一块：
  • 只做一件事
  • 记录了关键决定
  • 形式和用途匹配
• 标准本身测试过：植入八组问题，全部被具体条目抓住；应该通过的十条仍然通过。
• 造技能的技能只负责「造」，不负责「审」。审核细则等真正评审过一次成员自建的技能之后再固化。

行动：接在协作平台上，直接做事

AI 接在公司的协作平台上，读的是公司的上下文，做的是真实的动作，不停留在会议纪要。

• 项目云盘、项目档案、文档、表格都在公司用的协作平台飞书里。AI 通过命令行工具读写这些东西，不另建一套。
• AI 能直接做的事：
  • 把决定写成任务，按排期安排到人。
  • 从后台和表格自动获取数据，汇总成报表。
  • 按日、周、月生成进展报告。
• 对外写入要人放行。AI 先列出要写什么，人确认后才写。

自动化有四种触发方式，成员用「造自动化」技能自己声明。

• 按时间：到点自动跑。
• 盯文件：某个位置的文件变了就跑。
• 常驻监听：协作平台有新事件或新邮件就跑。
• 会话内捎带：成员开会话时顺便跑一遍到期的活。

定期洞察给的是建议，不只是数字。

• 看板和报告对照目标：当前进度能不能达成目标，差距在哪。
• 差距出现时给出带依据的调整建议，并说明代价。
• 每条自动化和报告都要先回答：它跑错一次，谁会在什么时候发现。答不出就不许无人值守。

发布与归属：新东西放哪

新东西出现时按顺序问四个问题，问到哪一层就放哪一层。

插件仓库是公开的，加新技能不用改插件的其他部分。

• 插件仓库里没有客户事实，没有密码和密钥，没有公司专属内容。
• 新技能自带输入清单，项目档案登记地址，判定逻辑只有程序一份，新技能不含判定代码。
• 推送即发布。结构升级时旧结构不断链，由程序就地迁移。

做成插件而不是一套文档，理由有两条。

• 文档交付出去就会被复制；能留在公司里的，只有必须持续连着工作流程才有效的接口。
• 文档要靠人读进去、再带到下一个环节；AI 应该直接读的东西不应该经过人的转述。

演化：五个月，两次收窄

插件从 0.4 发到 0.12，三十三次提交，两次收窄：判定从提示词收进程序，范围从三个项目收成一个。

最后一次判断推翻了起点的假设：公司不能先把自己写全再装进系统，配置只能在工作中逐步产生。

• 起点的假设：先画图、提炼事实、立规则，然后开工。
• 五个月后的做法：
  • AI 干活时碰到公司没有说明过的东西，不编造，记下缺口，问一句，经人确认后放进该去的层。
  • 一条知识被问三次，就建一页。
  • 一件事做过五次没有流程，就起草流程。
• 没变的是目标：判断外化。
• 变的是顺序：从先外化再干活，改为边干活边外化。

现状：分三档说

写这一页的日期是 2026-09-14。我已经交付离开，插件的现役版本在项目组同事的机器上。

在跑，有真实使用记录

• 插件装在项目组的机器上，会话入口、程序判定、常驻说明在每次会话中生效。
• 一个审核环节的技能用真实产出做过多轮验证，规则之间的冲突逐条写明。
• 一条数据线用真实台账回放，定出了下个月的策略。

建了，没走通

• 经验沉淀回插件的回路一次没有真实走通。
• 运行前的检查链没有真实使用者走过。
• 入口技能对不在任何项目里的人无从下手。
• 另外两个项目没有迁移。「换客户零改动」只在一个项目上成立过，等于没有验证。

目标，未测得

三条线各有一个项目组定的验收目标，由项目组统计。我不替他们报数。

数字只报能证明系统真实存在的。

插件仓库开源在 GitHub。这套方法先在我自己身上跑了一年，见作品一。它背后的想法怎么来的，见思考。