夜雨聆风开头 · 从一个老问题到一个新问题
记得刚入行时，我在知乎上关注了一个问题：
"互联网已经杀成了红海，制造业智能制造却还寥寥无几，为什么 BAT 不去涉足智能制造？"
5 年多过去了，这个问题没有标准答案，但时代变了。
当年的潜台词是，技术是稀缺的，行业是等待被改造的，只要顶级玩家肯下场，事情就会发生。这个假设几乎被现实反着证伪了一遍。而到了今天，大模型把"技术稀缺"这个前提又往前推了一大步。但如果去问任何一个在传统行业里推动 AI 落地的人，他大概率会告诉你：没那么容易。
于是这个老问题，在 AI 时代换了一种新的问法：
"AI 都已经这么强了，为什么这些行业还是转不动？"
最近 FDE（Forward Deployed Engineer）这个词在 AI 大厂之间突然火起来，本质上就是对这个问题的一种回应——既然模型已经足够强，那么"最后一公里"的瓶颈一定在客户现场、在数据、在流程、在组织。
这篇文章，是我结合过去几年的观察和实践，对这个老问题的一次尝试作答。
先把结论写在前面：
绝大多数行业现在缺的不是 AI，而是 X-Ops。
也就是说，问题从来不在"要不要上 AI"，而在于这个行业、这家公司、这条产线、这套流程，有没有被改造成一个 AI 可以接入、理解、参与和反馈的系统。
为什么软件行业被 AI 冲击最猛？
不是因为 AI，而是因为 DevOps。
如果观察过去两年 AI 真正"杀进去"的领域，似乎冲击最大就是软件行业本身。软件行业之所以被 AI 冲击最猛，并不是因为它的从业者最聪明，也不是因为模型偏爱代码，而是因为它在过去二十年里，无意中把自己改造成了一个 AI 最容易接入的行业。
AI 友好并不是天生的
如果罗列软件行业的几个特征，能让AI如鱼得水，我会选择：
• 语料开源、易获取： github • 反馈周期短：写完代码，编译、跑测试、看结果，秒级或分钟级就能拿到反馈 • 上下文对 AI 友好： 代码有注释、模块有接口、变更有 diff，几乎所有东西都是文本化、结构化的 • 正确性可验证： 单元测试、集成测试、CI 流水线，提供了一套"AI 写完之后能自动判分"的机制
这四点合在一起，迭代飞轮就转起来了：生成 → 验证 → 反馈 → 修正 → 再生成。
但回到 2000 年前后，软件行业其实更像今天的传统行业。发布周期以"年"为单位，一个版本要打磨好几个月，刻成光盘卖出去。真正改变这一切的，是互联网带来的交付模式变革。软件不再需要被"制造—复制—运输—安装"，而是变成了"开发—发布—反馈—更新—再发布"。这个闭环一旦形成，整个行业的组织方式就被倒逼着重构：
• 因为要频繁发布，所以需要 版本控制（Git） • 因为要频繁集成，所以需要 CI/CD • 因为要跨团队协作，所以需要 代码评审、issue 跟踪、API 文档 • 因为线上随时可能出问题，所以需要 日志、监控、告警、可观测性 • 因为发布风险高，所以需要 灰度、回滚、A/B 测试 • 因为协作规模变大，所以需要 敏捷、DevOps、SRE
这一整套东西，今天我们统称为 DevOps。但 DevOps 的本质，不是某种工具组合，而是一种把"软件如何被生产、交付、运行、改进"这件事，全流程显性化、版本化、自动化、可观测化的工程文化。
DevOps 留下的"副产品" 成为了AI的食物
这件事最有意思的地方在于：DevOps 当年并不是为了 AI 设计的。它解决的是人和人之间协作的问题、是质量和速度的平衡、是规模化交付的工程难题。
但它的副产品，几乎完美命中了 AI 时代所需要的一切基础设施
换句话说，软件行业花了二十年时间，把自己的生产过程变成了一个对外部智能体（无论是新员工、外包团队，还是 AI）都极度友好的系统。
当 coding-agent 出现的时候，它不需要软件行业为它做任何额外的适配，它只是顺势接入了一个早已为它准备好的协作基础设施。
知识沉淀被"内嵌"进了生产流程
这是软件行业最值得其他行业借鉴的一点。
在很多行业里，"知识管理"是一件需要单独立项、单独投入、单独考核的事情——你得有人去整理文档、维护 wiki、做培训。但因为它和业务产出没有直接挂钩，所以永远是优先级最低的事，永远做不好。
而在软件行业，知识沉淀不是一件"额外的事"，它是生产过程的副产物。
工程师不需要"额外努力"去做知识管理，只要他按规矩做事，知识就被自动结构化地沉淀下来了。
反过来看大多数传统行业，知识可能在脑子里、在某份 Excel 的某个 sheet 里、在微信聊天记录里。知识不是没有产生，而是散落在各处、以各种各样的形式存在、难以被找到、难以被读懂。
这件事的另一面是：AI 之所以暂时还进不去其他行业，并不是因为模型不够强，而是因为那些行业还没有为任何"外部智能体"做好接入准备——无论这个智能体是 AI，还是一个新来的员工。
为什么大多数行业接不住 AI？
没有 source of truth 的世界。
脏脏脏脏
只要在传统行业做过一两个 AI 落地项目，就会非常熟悉下面这些场景
• 数据脏：不同系统的数据对不上，系统和实际数据对不上，没有人知道这个数据字段的含义 • 流程脏： SOP和手册写的很详细，但实际跑起来不是按流程图走的 • 系统脏：十几个系统，来自不同年代、不同厂商，接口要么没有，要么是 SOAP，要么是导出 Excel 再导入 • 知识脏： 核心 know-how 在老师傅脑子里，微信聊天记录，在某份没人维护的 Excel 里
这四个"脏"叠加在一起，AI 想要发挥作用，几乎不可能。
但更深的问题不在于"现状脏"，而在于——过去这十几年的数字化转型，并没有真正解决这件事，反而在很多地方加重了它。
大多变成了看板
过去十年，几乎每一个稍微像样的工业企业，都做过"数字化转型"、"工业互联网"、"智能工厂"、"数据中台"。但今天去看这些项目的最终交付物，绝大多数是同一种东西：一块大屏，几个看板，几张报表。
各种几个英文单词缩写命名的系统，听起来都很对，立项书写起来都很顺，验收的时候也都能演示。但它们有一个共同特征：它们不改变企业的运行方式，只是把企业已有的运行结果"显示"出来。
于是最后都变成了面向老板的大屏看板。显示，不等于改变。变成了一种数字化官僚主义。
工具、流程、组织
尝试把企业里"可以被数字化/智能化"的东西，分成三层。
工具层
这一层做的事情，本质上是：把"人已经知道该做什么"的事情，做得更快、更稳、更便宜。
绝大多数"AI 项目"和"数字化项目"，做的都是这一层。原因很简单——好立项、好验收、好讲故事。（也被我称为边缘智能）
流程层
把过去靠人协调、靠会议推动、靠经验判断的环节，变成系统驱动的、有反馈的、可优化的链路。
这一层的价值远高于工具层，但它要求数据是通的、系统是连的、流程是显性的、责任是清晰的。绝大多数企业在这里就卡住了——因为它要求你把"四个脏"先清理干净。
组织层
企业本身作为一个复杂系统，如何被描述、被运行、被改进。
人可以凭经验处理局部问题，但很难实时处理一个高维、动态、多目标、强约束的系统。第三层要做的，是把这个复杂系统本身变成可以被建模、被监控、被调优的对象。
这一层才是 AI-Native 真正应该发挥作用的地方。但它有一个尴尬的特点：它很难卖。
如果你接受上面这个三层框架，就会理解一件事：AI 转型真正难的，不是模型，而是脏活。
而问题是：这些脏活在过去几十年里没人愿意做，将来也很难有人愿意做。因为它们不出彩、不立功、不出 PPT、不评职称。
真假 tacit knowledge
一个流传很广的说法："我们这行很多东西是隐性知识，AI 学不会的。"
这话一半对，一半错。
真正的 tacit knowledge 确实存在。但伪 tacit knowledge 更多
• 本可以写下来，但没人写 • 本可以结构化，但组织不奖励 • 本可以共享，但分享出去就失去了个人话语权
垂直行业里大量被称为"经验"的东西，其实属于后者。把伪 tacit knowledge 当成真 tacit knowledge 来供着，结果有两个：第一，新人入行成本巨大，只能靠"跟人、看人、熬年头"；第二，AI 落地困难，因为 AI 最吃的就是可访问、可结构化、可验证的上下文。
而软件行业之所以新人能快速上手、AI 能快速接入，正是因为它把本来可以显性化的东西，制度性地显性化了——你不显性化，PR 过不了、CI 跑不通、code review 不通过。流程逼着你把知识吐出来。
这背后其实是两种截然不同的组织形态。
互联网、开源社区围绕产品、系统、协作和可复用性展开，形成的是产品型组织。
而很多传统行业是专家型组织。
专家型组织表面上"更安全"——因为关键能力锁在少数人手里，不会失控。但它有一个致命的副作用：它是一个对外部封闭的系统（不论是对新人还是agent）。
于是造成了一个尴尬的局面：AI 进不去，是因为新人也进不去。
所以，到底卡在哪里？
回到开头的问题：为什么大多数行业接不住 AI？
因为它们在过去几十年里，始终没有建立起一个"对外部友好"的内部系统。这不是"AI 进不去"的问题，这是"任何系统化的力量都进不去"的问题。AI 只是把这件事重新照亮了一遍。
而真正讽刺的是——很多行业现在投资 AI 的方式，仍然是在第一层（工具层）继续堆叠更多“名为智能体”看板，而不是去补第二层和第三层的债。
ROI 的陷阱
大多数企业在算 AI 这笔账的时候，用的是一套上个时代的算法。这套算法决定了它们最多只能看见 AI 的一小部分价值，也决定了它们的 AI 转型注定停留在"更便宜的人"这个层面。
三种 ROI
这里引用 The Three Layers of ROI for AI Agents 【https://www.henrypray.com/writings/the-three-layers-of-roi-for-ai-agents】 的观点
第一层 ROI：AI 替代了多少人，节省了多少时间，降低了多少成本。
这是绝大多数企业最容易理解的 AI 价值。它的优点是直观，缺点是天花板低。
因为它的本质，是让旧流程更便宜、更快，并没有改变企业的运行方式。AI 在这里扮演的角色，就是一个"更便宜的人"。
第二层 ROI： AI 让人做到了过去做不到、或做不好的事
价值远高于第一层，但门槛也高得多。它要求企业愿意为"看不见的基础设施"花钱。绝大多数企业卡在这一层。不是因为算不清账，而是因为这笔账要求 CEO 有 3-5 年的耐心，而大多数管理者只有 6-12 个月的视野。
第三层 ROI： agent是组织的一部分
它的核心问题不是"AI 能帮我做什么"，而是：Agent 在组织里，拥有什么权限？此时不再只是一个"工具"，而成为组织运行中的一种新行动者，甚至企业的工作方式必须围绕它重新设计。
这才是 AI-Native 真正的含义。不是"用了 AI"，而是"组织围绕 AI 重新设计了工作方式"，其回报是非线性的、复利型的、长期的。
为什么钱总是流向第一层？
不是企业看不见第二层和第三层的价值，而是它们的决策机制只能为第一层买单。
这是 AI 转型最尴尬的地方。第二层和第三层 ROI 之所以高，恰恰是因为它们建立在"还债"之上——把脏数据洗干净，把烂流程梳理顺，把散落的知识沉淀下来，把孤立的系统连接起来。
而这些"债"，是过去几十年里，每一任管理者为了自己的短期 KPI 而欠下的。
所以最终大家达成了一种低水平共识：
做一个不改变权力结构、不改变业务流程、不挑战既有 KPI、能验收、能展示、能写材料的 AI 系统。
看起来"用上了 AI"，但企业的运行方式没有任何实质改变。
所以，绝大多数企业只会算第一层的账，它们天然会把 AI 用成更便宜的人。但这里有一个致命的问题——当所有人都把 AI 用成更便宜的人，AI 的价值就会被市场迅速抹平。降本带来的优势是短期的、可被复制的、对手很快就能跟上的。
AI 转型的本质不是技术问题
一个有点扎心的结论：
AI 转型越往深处走，越不是技术问题，而是授权问题、流程问题和组织问题。
X-Ops的思想
Ops 化的本质，就是把一个复杂系统改造成可反馈、可调节、可学习的控制系统。
到这里，前面三节其实已经把问题铺得很清楚了：
• 软件行业被 AI 冲击最猛，不是因为它最懂 AI，而是因为它在过去二十年里建成了 DevOps • 大多数传统行业接不住 AI，不是因为 AI 不够强，而是因为它们没有 source of truth • 大多数企业的 AI 转型停留在第一层，不是因为算不清账，而是因为决策机制只能为看得见的 ROI 买单
如果一个行业想要真正接住 AI，它需要的不是"AI"，而是属于它自己的那套 Ops。我把这件事叫做 X-Ops，这里的 X 可以是任何一个想被 AI 真正改造的行业。
但 X-Ops 并不是简单地"把 DevOps 复制到其他行业"。它是一种更底层的思维方式——关于一个组织如何把自己变成一个可以被持续观察、持续反馈、持续改进的系统。
控制论的视角：组织是一个反馈系统
控制论的核心思想，其实非常简单：任何一个系统想要在不确定的环境中持续运行并改进自己，它必须有一个闭环——感知、决策、行动、反馈，然后回到感知。
其实DevOps 很像一个控制系统。
把 DevOps 拆开看，几乎可以直接映射到控制论结构：
所以 DevOps 不是单纯“自动化部署”。
传统开发模式的问题是反馈太慢：需求几个月后才上线，事故发生后才知道，运维接手后开发才发现代码不可运维。
DevOps 的改造就是缩短反馈链路：
代码提交 → 自动测试 → 自动部署 → 线上观测 → 用户反馈 → 快速修正。
这和控制论里的负反馈很像：发现偏差，修正偏差，让系统回到目标范围内。
同时，DevOps 里的“稳定”不是静止，而是动态稳定。这点很关键。传统管理喜欢追求“不要变化”，以为少变更就稳定。DevOps 的逻辑更接近控制论：稳定不是没有变化，而是在持续变化中保持可控。或者换句话说：
小步变更、快速检测、快速回滚、快速恢复、持续学习。
再反观组织层面，绝大多数公司其实不是一个闭环系统。它们更像是一个开环的管道：领导拍板 → 下达指令 → 执行 → ……然后没有然后了
而 AI 的真正价值，恰恰建立在闭环之上。模型最适合的工作方式，是小步迭代：提出修改、运行、看结果、修正、再来一遍。如果一个组织本身没有"可运行、可验证、可回滚"的机制，AI 就找不到自己的位置——它没法知道自己做得对不对，也没法知道下一步该往哪儿走。
所以 X-Ops 的第一层含义是：把组织从一个开环系统，改造成一个闭环系统。
基石
控制论提供的是一个抽象视角，真正落到实处，我认为有3座基石。
事实层
系统有没有可见性？Source of Truth，不是所有数据都要先进数仓，也不是所有知识都要变成知识图谱，但必须有一些东西被确认为“事实源”。可以用“数据血缘”、或者“Ontology” 来形容，但其核心都是为了解决AI-ready 的组织上下文问题。这一层解决AI应该相信什么。
变更记录
系统有没有可调节性？AI没有手，物理真实世界和网络世界天生是隔离开的，为了避免两者之间存在越来越大的差异，关键变更需要可追溯。这部分可以类比 Git，但并非是直接上“Git”，重点是“变更”这件事要被制度化。谁改了？为什么改？影响范围是什么？这一层解决AI 能不能理解组织的演化过程。
评价反馈体系
系统有没有可学习性？对于绝大多数Deep-learing或者AI落地项目，我一直坚持的是评测先行：构建测试集-定义评价指标-设计评价方法-评测-优化方法-评测… 的思路，这一套方法本身是数据科学上通用的方法论，用于解决一个复杂系统优化问题所采用的，同样可以推广到更多的地方。
建立短反馈闭环
有人会说："我们这个行业，安全要求高、质量要求高、客户要求高，没法像互联网那样快速迭代。"
但越是高风险的系统，越应该有更强的版本管理、更严格的测试、更完善的自动化验证、更细致的变更记录。换句话说，越是不能"快速迭代"的行业，越需要 Ops——不是为了快，而是为了可控。
DevOps 的本质从来不是"快"，而是"在快的同时仍然可控"。建立属于自己的反馈节奏——可能是按月、按季度、按年，但必须是闭环的。
人有人的用处
X-Ops 最深的一层含义，是重新定义人在组织中的角色。
过去，组织里的人主要扮演两种角色：执行者（做事的人）和判断者（拍板的人）。前者负责把事情做出来，后者负责决定做什么、怎么做。AI 时代之前，这两种角色都是稀缺的——执行需要技能，判断需要经验。
AI 改变了这个结构。执行越来越廉价，判断也开始被 AI 部分接管。
反观过去的几次技术变革，技术很少直接消灭人的价值，它更多是在改变价值所在的位置。从工业革命到 AI，人的角色不断从“直接操作对象”转向“设计、监控、调节一个会操作对象的系统”。
这时候，人的价值并不是消失了，而是上移了。
P vs NP 给了一个隐喻：找答案可能很难，验答案可能相对容易。就像一年前还在古法编程，而现如今，大家讨论的是harness engineering，从“我亲手把东西做出来” -> “我定义目标、约束、测试、验收标准和反馈回路，让机器在可控范围内生成结果。” 人的关键位置不再是每个具体输出的生产者，而是更高层的 evaluator、goal-setter、constraint-designer、feedback-loop builder。
当然，人们对于“自动化”的恐惧，更多是控制权和分配的问题，甚者在AI时代，更加深恐惧的是其碰到了“评价者”的位置。当然这些都是后话了。
X-Ops 的三个危险
X-Ops 听起来像是一套很正确的方法论：显性化、版本化、反馈闭环、持续改进。但越是正确的东西，越容易在组织里变形。尤其是在大公司和传统行业里，任何一种方法论最后都有可能变成新的流程、新的系统、新的表格，甚至新的官僚主义。
第一个危险，是 工具崇拜。
X-Ops 不是"买一套 Ops 工具"。如果以为引入 Git、CI/CD就等于做了 X-Ops，那大概率只是套了一层新的官僚主义外壳。
第二个危险，是 指标异化。
一旦建立了度量体系，组织里就一定会有人开始优化指标本身，而不是指标背后的目标（reward hacking）。Goodhart's Law：当一个度量变成目标，它就不再是好的度量。X-Ops 的目标是用度量驱动改进，而不是用度量惩罚人。一旦度量被用来追责，组织就会本能地开始造数据、藏问题，于是又回到"电子化官僚主义"的老路。
第三个危险，是 控制幻觉。
最危险的一种走偏，是把工程化等同于一切——一切都要可度量、一切都要可自动化、一切都要可回归测试。真正成熟的 X-Ops，是知道什么可以工程化、什么不应该工程化的那种克制。
结尾
回到开头的问题。
因为问题不只是有没有 AI，而是行业本身有没有变成一个 AI 能理解、能参与、能优化的系统。
否则，AI 只是更先进的外壳，包着一套老旧的运行方式。
真正的 AI 转型，不是把 AI 放到企业里，而是让企业变成一个能和 AI 共同运行的系统。
否则，所谓智能化，最后只会变成另一种电子化官僚主义。
