开头 · 从一个老问题到一个新问题

记得刚入行时，我在知乎上关注了一个问题：

“互联网已经杀成了红海，制造业智能制造却还寥寥无几，为什么 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 时代所需要的一切基础设施

DevOps 留下的东西 对 AI 意味着什么
Git 仓库 + commit history 可追溯的演化轨迹和训练语料
Issue / PR / Code Review 带标注的人类决策数据
单元测试 / CI 自动判分器，AI 改完能立刻验证
README / API 文档 / Design Doc 结构化上下文
日志 / Trace / Metrics 运行时反馈信号
灰度 / 回滚 安全的试错机制

换句话说，软件行业花了二十年时间，把自己的生产过程变成了一个对外部智能体（无论是新员工、外包团队，还是 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 不通过。流程逼着你把知识吐出来。

这背后其实是两种截然不同的组织形态。

互联网、开源社区围绕产品、系统、协作和可复用性展开，形成的是产品型组织。

而很多传统行业是专家型组织。

维度 产品型组织 专家型组织
代码 / 工作成果 代码要别人能读 谁懂谁说了算
接口 / 使用方式 接口要别人能用 谁资历老谁拍板
文档作用 文档要新人能看 文档服务于审计，不服务于协作
问题处理 Bug 要别人能复现 谁踩过坑谁有权威
模块设计 模块要可以替换 谁掌握设备、数据、流程，谁有话语权
知识流动 知识要能跨团队流动 新人靠跟人，不靠系统
新人成长 依赖文档、流程、系统和社区沉淀 依赖师傅、前辈、经验传递
权威来源 来自产品质量、系统能力和协作效率 来自经验、资历、资源掌握和历史积累

专家型组织表面上"更安全"——因为关键能力锁在少数人手里，不会失控。但它有一个致命的副作用：它是一个对外部封闭的系统（不论是对新人还是agent）。

于是造成了一个尴尬的局面：AI 进不去，是因为新人也进不去。

所以，到底卡在哪里？

回到开头的问题：为什么大多数行业接不住 AI？

因为它们在过去几十年里，始终没有建立起一个"对外部友好"的内部系统。这不是"AI 进不去"的问题，这是"任何系统化的力量都进不去"的问题。AI 只是把这件事重新照亮了一遍。

而真正讽刺的是——很多行业现在投资 AI 的方式，仍然是在第一层（工具层）继续堆叠更多“名为智能体”看板，而不是去补第二层和第三层的债。

ROI 的陷阱

大多数企业在算 AI 这笔账的时候，用的是一套上个时代的算法。这套算法决定了它们最多只能看见 AI 的一小部分价值，也决定了它们的 AI 转型注定停留在"更便宜的人"这个层面。

三种 ROI

这里引用 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 里的对应物
被控对象 线上软件系统、基础设施、用户体验
目标状态 SLO、业务指标、可靠性目标、交付目标
传感器 日志、指标、追踪、监控、告警、用户反馈
控制器 CI/CD 流水线、发布策略、平台规则、团队决策
执行器 部署、回滚、扩容、限流、熔断、Feature Flag
扰动 流量突增、代码缺陷、依赖故障、用户行为变化
反馈回路 监控 → 判断 → 调整 → 再观察
学习机制 事故复盘、持续改进、自动化测试补强

所以 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 共同运行的系统。

否则，所谓智能化，最后只会变成另一种电子化官僚主义。