当所有人都有 AI 后，公司为什么什么都没学到
今天看到一篇写得很好的文章，301 分，讲的是企业 AI 落地中一个被严重低估的问题。
一家公司可能给所有开发者买了 GitHub Copilot 许可证，给销售团队买了 ChatGPT Enterprise，在后台部署了 Claude 或 Gemini。每个团队都有那么几个人在悄悄用 AI 做着远超官方培训材料设想的事情。
但公司本身几乎什么都没学到。
文章作者引用了 Ethan Mollick 的一个框架：领导力设定方向，群众发现用例，实验室把发现转化为共享实践。但关键问题是——学习怎么从个人传播到团队，再传播到整个组织？
这个问题比"有多少人用 AI"要难得多。
看看一家典型公司里的情况。一个团队把 Copilot 当作自动补全工具就满足了。另一个团队在用 Claude Code 做紧密的编码循环——写代码、跑测试、审查、迭代。一个产品经理突然开始用 AI 做真实原型，不再需要画 Figma 线框图。一个高级工程师让 agent 做根因分析，一个小时就拿到了有效结果——不用 AI 的话要两周。一个初级工程师写出了漂亮的代码，但不知道有哪些架构假设被偷偷塞进了系统。一个支持团队把重复工单变成了工作流自动化，因为他们是真正知道工作痛点的人。
所有这些都在同一家公司里同时发生。
这就是"混乱的中间"。AI 的采纳单位不再是组织，甚至不是团队，而是每个人工作中的"循环"。
而公司现有的变革机制，太慢了。
社区实践、棕色包会议、冠军网络、月度演示、调查、仪表盘——这些东西本身不错，但真正有意思的 AI 工作不会等下一次社区会议。它出现在代码审查里、销售提案里、产品原型里、生产事故里。当故事被整理成最佳实践幻灯片时，真正有价值的学习已经流失了。
嗯，文章里有一个观点我觉得特别重要。
敏捷开发本质上是为"昂贵的迭代"设计的。Sprint 规划、估算、站会、用户故事、梳理、交接——所有这些仪式都是为了减少浪费的迭代次数。当一次迭代需要几天或几周时，你需要这些结构来降低风险。
但 agentic engineering 改变了这个经济学。它让从意图到原型到验证的速度大幅提升。约束不再在"实现"上，而在"意图定义、验证、判断和反馈"上。
可大多数公司花了二十年自称"敏捷"，却保留了敏捷本应消除的组织反射。现在 AI 让真正的敏捷成为可能，系统仍然要求两周的 Sprint 承诺、交接文档和所有假设迭代稀缺的东西。
所以真正的测量指标不是"token 花掉了多少"或"生成了多少代码"，而是"哪些循环跑得更快了"、"哪些决策变得更好了"、"哪些团队学到了可复用的模式"、"哪些产品想法因为原型暴露了弱点而被更早放弃"。
token-to-output 是旧测量惯性的新装束。token-to-learning 才更接近真正重要的东西。
最后文章提出了三个企业需要具备的能力：
- Agent 运维——哪些 agent 在运行、能访问什么系统、能看到什么数据、哪些操作需要审批
- 循环智能——哪些 AI 辅助循环真正产生了学习、哪些停留在原地、哪些团队准备好更松散的委托
- 能力分布——如何让有用的能力流动到工作发生的地方，而不是假装三个大型 agent 就能解决所有人的问题
这篇文章没有给出简单答案，但提出的问题比大多数"AI 转型路线图"要诚实得多。
真正的障碍不在技术，在组织的代谢速度。AI 的循环跑得比组织消化学习的能力要快。而在这个速度差里，公司花了很多钱买许可证，却几乎什么都没学到。
