把 AI 当同事,而不是工具:一次＂自举＂教会我的协作哲学(AI 枢纽实战·Ⅵ)

「AI 枢纽实战」系列·Ⅵ | 前面的篇章讲技术机制，这一篇讲一个软性但关键的转变：当你不再把 AI 当"工具"，而是当"同事"，系统会发生什么。

一、引子：一个不该被发现的问题

▲ 执行方的自举时刻

给枢纽接入第 6 个执行方（一个叫 pi 的 AI）时，按惯例先让它做接入自检——读规范、干活、写报告、回写状态。

它交了报告，但报告里有一段"附带发现"：

hub.py 缺少 if __name__ == '__main__': main() 入口。

我愣了几秒，然后后背发凉。

这个 hub.py 是整个系统的调度器。它的四命令（扫描/转卡/调度/校验）和守护进程都靠它。没有这行入口意味着什么？

意味着所有 python hub.py --xxx 命令都是"静默空转"——命令跑完、退出码 0、零输出、什么都没干。

而守护进程的启动命令正是 python hub.py --daemon——它从未真正运行过。

二、更可怕的不是 bug，是"记录"

如果只是"守护进程没跑起来"，那还好修。真正让人后背发凉的是：

系统记录里，明确写着守护进程"实测通过"。

那份"实测通过"是怎么来的？复盘时间线找到了答案：

• 当时测试守护进程的"功能"，实际是手动直调适配器完成了几个任务
• 任务完成了、报告也写出来了——看起来一切正常
• 于是记录了"守护进程实测通过"

但实际上，被测试的对象（守护进程）根本没在跑——它的功能是被"人肉绕过"完成的。缺陷被掩盖了 12 天。

两个教训

教训一：记载不等于事实。连人类（或者人类指挥的 AI）写的"实测通过"都可能与事实不符。"通过"必须有可验证的证据——PID 在哪？输出在哪？

教训二：import 式测试不暴露入口缺失。当时有单元测试——但它们 import hub 后调用函数，从不经过命令行入口，所以永远发现不了"入口不存在"。

修复很简单（补一行入口 + 加一个"子进程直跑"的冒烟测试）。但发现它，需要一个没有历史包袱的眼睛。

三、为什么是"新人"发现的？

这是整件事最有意思的部分：一个刚接入 10 分钟的新 AI，发现了团队（包括我）埋了 12 天的缺陷。

为什么？

因为老成员有"上下文惯性"——我知道守护进程"应该是好的"（记录说实测通过），所以我不会去质疑它。而新 AI 什么都不"知道"，它只是照规矩执行自检：读代码、跑命令、看结果——然后发现命令没输出。

这揭示了一个反直觉的事实：

在 AI 协作系统里，"新人"（新接入的 AI）是最锋利的审计员——因为它没有需要维护的历史观点。

于是我们后来把它制度化了：每个新执行方接入时，必须做一次全链路自检——不是为了检查它，而是借它的"新鲜眼睛"复查系统。

四、不止一次：执行方的"自举"时刻

修好那个 bug 之后，我开始留意这种"AI 主动发现问题"的时刻。然后发现它不止一次：

时刻二：AutoClaw 补文档。某个执行方完成自检后，主动把"它的接入事实"写进了系统的事实库——没有要求它做这个，是它读了协同规范后自己判断"这条事实应该被记录"。

时刻三：pi 修测试。终验时，它发现我们写的一个测试断言有脆弱性（断言文案会随数据状态翻转导致误报），主动修复并说明了原因——一个"执行方"在改进"验收它的人写的测试"。

时刻四：执行方之间的接力。任务链里，A 环的报告被 B 环读取并作为输入——B 环甚至自己判断"上游结论已确认"，完成了幂等处置。

每一个时刻的共性：它们都不是"被指挥"做的，是"理解目标后主动做的"。

五、设计支撑：让 AI"能"自举的三个条件

▲ 让 AI 能自举的三个条件

"AI 主动发现问题"不能靠运气，靠的是设计。回头看，三个条件缺一不可：

① 规则注入：让它知道"规矩"

每个执行方接入时，它的 system prompt 里会被注入协同规范（什么该做、什么不该做、产出放哪、怎么回写）。没有规矩的"主动"是灾难——AI 会自由发挥。有规矩的"主动"才是协作。

② 文件透明：让它能"看见"

整个系统对执行方是完全透明的——它们能读到全部规范、全部历史、全部他人的产出。信息不对称最小的环境，主动性最有价值。

③ 职责定义：让它有"立场"

我们从不告诉执行方"怎么做"，只告诉它"目标是什么、规矩是什么"。给目标和约束，不给步骤——这是触发主动性的关键。（如果你把步骤写死了，它就只是执行器。）

六、哲学：工具 vs 同事

▲ 工具 vs 同事

把这两者的区别列出来，会看得很清楚：

关键认知：把 AI 当同事，不等于"放任"，而是"给目标 + 定规矩 + 机器验收"——

• 给目标（不是步骤）→ 触发主动性
• 定规矩（规范注入）→ 约束行为边界
• 机器验收（四落点）→ 不需要"信任"这种主观判断

这三件套之下，"AI 是工具还是同事"不再是个哲学问题——它是个工程问题，而且有解。

七、可带走的配方

配方 1：把"新接入"制度化为"审计机会"新成员（人或 AI）没有历史包袱——让它的第一次任务必含"自检"，借它的眼睛复查系统。

配方 2：给目标，不给步骤步骤写死 = 只会执行。给目标 + 约束 + 验收标准 = 会思考。这是"工具"到"同事"的分界线。

配方 3：全透明环境让执行方能读到全部规范和历史——信息不对称越小，主动性越有价值。

配方 4：验收替代信任不用纠结"该不该信任 AI"——用机器验收（产出物存在性校验），信任问题变成机制问题。

配方 5：记载必须附证据"实测通过"要有 PID 和输出。"看起来正常"是最危险的假象。

三条铁律

• 记载不等于事实
  ——"通过"必须能指回证据
• 让执行方可以"主动"——但用规矩圈住主动权
• 最锋利的审计员是没有历史包袱的那个

你有没有过"记录说 X 实测通过，但实际从没跑过"的经历？如果有，现在就去补那个证据——这是本系列最便宜的一条教训。

欢迎回到试验田，这是田里的第 11 个故事——一次"自举"教会我的协作哲学。

—— 试验田 · 第 11 篇 ——

本文基于作者真实项目记录，由 AI 辅助整理。