两个 2 人团队。一个把设备测机效率拉到 3-5 倍，另一个直接跑出了一条新产品线，80-90% 代码由 Agent 自动生成。同一栋楼里，另外 18 个人配齐了 AI 工具，培训搞了三场，三个月过去——什么都没变。
工具一样，结果天差地别。为什么？
你在打一场错误的仗
管理学上著名的”鲶鱼效应”是个假故事——北大西洋根本没有咸水鲶鱼。一句话带过，因为这不是重点。
重点是：你的团队用错了打仗的方法。
Dave Snowden 的 Cynefin 框架把问题空间分成四个域：
| 域 | 因果关系 | 应对方式 |
|---|---|---|
| Simple（简单域） | 清晰，可重复 | 感知 → 分类 → 响应 |
| Complicated（繁杂域） | 需要专家分析 | 感知 → 分析 → 响应 |
| Complex（复杂域） | 只在事后可见 | 试探 → 感知 → 响应 |
| Chaotic（混乱域） | 无法预测 | 行动 → 感知 → 响应 |
我们做了个调研，18 个人覆盖后端、前端、产品、测试、实施、运维。所有人都在用 AI，所有人都有一个共同的循环：
后端让 AI 生成代码，AI 自信说”完成”实际跑不通，自己再查一遍。前端让 AI 输出页面，样式对不上平台规范，自己改一版。产品让 AI 生成 PRD，业务规则写错流程分支漏写，自己补细节。实施让 AI 生成脚本，平台语法不兼容，自己重写。测试让 AI 生成用例，质量参差边界遗漏，自己逐条审核。
AI 不够好 → 我来改 → 希望 AI 下次更好 → 继续做同样的活儿。
这些全是 Simple 域的工作。而”AI 能不能改变这个流程本身”，属于 Complex 域——因果关系只有事后才知道，答案不是规划出来的，是试出来的。
成立 AI 委员会、做行业调研、制定转型规划、分阶段落地，每一步都很专业，每一步都在做”感知 → 分析 → 响应”。这是 Simple 域的打法。你用 Simple 域的方法去打 Complex 域的仗，团队当然什么都没变。
那两个 2 人团队做了什么
测机流程：3-5 倍提效
制造业设备测机，厂商设备、测机服务、EAP 三端联调。传统做法：多人分工，靠老员工经验逐端排查，运气不好耗几小时，经验全在人脑子里，同样的坑反复踩。
团队先走了”正规路线”：成立专项组、做调研、定规划、配 AI 工具，让大家”用 AI 提效”。结果——AI 加速了文档撰写速度，错误还是靠人查，效率没变。
后来换了做法。两个人，一个技术一个业务，组成 AI Pod。不写方案不等审批，直接上手。用 Agent 编排测试步骤，自动判定通过或失败，Fail 时秒级定位是设备端、EAP 端还是 MES 端的问题。错了就调，调不通就换思路。
几个迭代，设备对接效率提升 3-5 倍。不是规划出来的，是试出来的。
LiteMES 新产品线：80-90% 代码自动化
同一个组织，另一个 2 人 AI Pod 做了更激进的事：直接启动一条全新产品线，面向中小工厂的轻量 MES。
没有委员会论证可行性，没有写报告。Spec 定义需求，Agent 生成代码，自动化测试收口。非业务细节的功能实现，80-90% 的代码由 Agent 自动编码和测试。跑通之后，把通用开发模式沉淀为可复用的 Skill，后续客户二次开发直接调用。
交付团队可以把精力集中在客户业务差异化上，Skill 直接用于交付。
方法论：AI Pod 模式
两个案例背后是同一个模式，可以复制：
配置：2 人 AI Pod，1 个技术 + 1 个业务
流程：Spec 定义 → Agent 执行 → 测试收口 → Skill 沉淀
原则：
- 试探代替规划 —— Complex 域的应对方式，先动手再校准
- 闭环 —— 每一步有明确输入和验证，保证可靠
- 演进 —— 跑通的模式沉淀为 Skill，下次直接复用
不需要全员转型，不需要委员会审批，不需要三个月调研。找一个不影响主业务的小方向，配两个对的人，给他们空间和容错度，让他们直接试。
怎么选场景：哪些业务适合上 Agent
不是所有业务都适合直接上 Agent。回头看两个成功案例和 18 人的调研数据，有一条很清楚的分界线。
适合 Agent 的三个信号
信号一：经验是瓶颈。 这个活儿只有特定的人能做，人走了活儿就断了。测机流程就是典型——错误定位靠老员工脑子里的经验，同样的坑在不同项目反复踩。Agent 能做的事：把人的经验结构化成知识库，变成可复用的诊断流程。
信号二：结果可判定。 对不对一眼能看出来，不需要人主观判断。测机的 Pass/Fail，代码能不能编译通过，测试用例覆盖率够不够——都有客观标准。Agent 最擅长的事，就是在可验证的边界内高速执行。
信号三：重复但模式相同。 每次具体内容不同，但底层模式一样。LiteMES 就是典型——不同客户需求不同，但非业务细节的代码模式高度重复。重复性让 Skill 沉淀成为可能：跑通一次，后续直接复用。
三个信号满足两个以上，就值得试。
不适合的场景，调研里也有答案
平台知识是硬门槛。 实施工程师想让 AI 基于内部平台生成脚本，AI 对平台特性不熟，语法不兼容，复制就报错。问题不是 Agent 不行，是知识基座没建起来。这种场景得先做知识沉淀，再上 Agent。
测机 Agent 能做到秒级定位错误，前提是知识库里已经有了接口协议和设备画像。先有知识，再有 Agent。
输入本身就模糊。 产品经理想让 AI 从零散沟通记录生成 PRD，但输入本身就是模糊的——需求没想清楚，AI 再怎么生成也”太空、不落地”。问题不在 AI，在于喂给 AI 的东西质量不够。
一次性任务。 偶尔做一次的事，投入 Agent 的开发成本不如直接人做。Agent 的价值在于复用——Skill 沉淀、知识库积累，都是靠重复喂出来的。一个项目只做一次的定制需求，不是 Agent 的菜。
一个简单的判断方法
看你们团队的工作，问三个问题：
- 这个活儿是不是只有某几个人能做？ → 经验瓶颈
- 做完之后能不能自动验证对不对？ → 结果可判定
- 这类活儿是不是经常重复出现？ → 模式可复用
三个”是”，上 Agent。两个”是”，可以试。一个或没有，先把知识基座打好再说。
你的团队里谁是鲶鱼
每个团队都有那么一两个人：用 AI 不是为了把手上的活儿做得更快，而是质疑这个活儿该不该存在。
当所有人都在用 AI 加速写接口的时候，这个人问：“80% 的接口是 CRUD，为什么不能从数据模型直接生成？”
当所有人都在用 AI 生成更好的 PRD 的时候，这个人问：“能不能跳过中间文档，从需求直接到可运行的功能原型？”
找到这个人。给他一个小方向、两个月的容错空间，让他跑通一个闭环。
跑通了，模式自然会被复制。跑不通，损失有限。
这就是 AI 转型里最该投入精力去做的事。不是配工具，不是搞培训，不是写转型战略报告——是找到那条鲶鱼，让他跑通一个小闭环。
如果你也想在自己的团队试 AI Pod 模式但不知道怎么开始，可以聊聊。