跨国深谈← 返回←DevOps 之父 Patrick Debois：AI 时代组织比技术更难成熟

DevOps 之父 Patrick Debois：AI 时代组织比技术更难成熟

关联

人物 Guy Pajani · Patrick Debois · Simon Maple

概念 暗工厂 · 智能体 · vibe coding · harness · 循环工程 · 上下文 · 评估 · 可观测性 · 智能体平台 · DevOps · 持续学习

这一集是 DevOps 运动的发起人 Patrick Debois(被称为 DevOps 的“继兄弟”)在 AI Engineer 大会现场与主持人的对谈。他做了一个叫 agentic patterns 的研究项目(tesle.io/patterns)，把 AI 编码浪潮里的实践分类整理成五大板块。

他最扎眼的判断是：暗工厂(dark factory，完全无人化的软件生产)在技术上完全可行，今天挡住它的不是技术，而是组织——「当你提到暗工厂这个词时，就像在说亵渎神灵，它行不通。我认为技术上它行得通，但你们没有围绕它进行组织」。

AI 编码的五个板块：一条渐进线

Patrick 把行业实践分成五个类别，索引是手工建的(因为社交媒体上命名混乱，每个人都有不同的说法)。第一类是 agentic development，主要是独立开发者的事：从 vibe coding(凭感觉让 AI 写代码)到 spec coding(先写规范再让 AI 实现)，再到暗工厂——这是一条渐进线：你从提示词开始，发现需要更好的 spec，需要更多 context(给智能体的背景材料)、更多 harness(驾驭智能体的脚手架)。第二类是平台：可复用组件——context、harness、集中管道——他相信这会由平台团队或开发者体验团队作为中心件提供，今天已见雏形：MCP proxy(一种智能体接入外部工具的代理层)、集中的 eval(评估)、registry(注册表)。

主持人指出平台这块在大组织里采纳度最不成熟，但恰恰是解锁规模化的一环；Patrick 补充说这并非全新事物——产品内的 AI 比编码用 AI 在组件上领先约两年，平台团队早就有评估系统和可观测性，只是「评估的对象不是模型，而是编码智能体」这一点是新课题。

第三类是质量与安全。他纠结要不要单列，最终单列是因为：agentic development 关注的是把代码搞对，而 QA 测试、代码安全这些非功能性需求自成一体。

他预测瓶颈会从生成转移到输出验证：「在你做完事情之后，智能体的工作是说服你它做了正确的事」，不只是给你 PR 看代码，还要给你截图、智能体点击的记录。一个有意思的判断：写代码的 IDE 已经搬进了 CLI(命令行)，但 IDE 正以审查界面的身份回归——审查者要看截图、录制、API 行为，这些视觉交互终端里的清单给不了。

后两类是角色变化和扩展组织，下面展开。

技术在堆叠，组织在掉队

主持人问：我们到底在成熟曲线上哪个位置？Patrick 的回答分两层。

技术栈层面，不是一直在变，而是在堆叠:prompts、specs、harnesses、loops 都是保留项，一层层加在栈上，loop craft、loops of loops(循环套循环，即智能体编排智能体)也是可预测的演进。但组织层面完全是另一回事：很多组织还在用旧的补全版本，觉得「对我不起作用」，并据此做出错误决策——就像当年 DevOps 时代说「持续交付对我们不管用」的人，「基本上是在说我们还没准备好。不是技术用不了，是组织没准备好」。

大组织平均成熟度不高，因为扩展的摩擦和五人小队完全不同。典型模式是：先有一个团队带头冲锋，再变成多个团队，再逐步解决摩擦。

角色往哪走：不想写 spec 的人，去做 harness

行业里一个真实的抵抗是：「我们是冲着写代码来的，不是冲着做一个光鲜的提示词规范编写者」。Patrick 的回应：harness 工程和 loop 工程是有技术含量的构建工作，给仍想做技术的人留了出口——他们可以去建 harness、搭 loop、做审查工具。

而且 harness 是共享组件，组织里只需要一部分人做这件事。这和 DevOps 时的争论一模一样：DevOps 会不会自动化到让自己失业？结果是他们做到了以前无法想象的规模，人又被拉回来。

对付怀疑者的办法很具体：别辩论，让他们去写 context、建 harness——「以前感觉它不管用，我们能做的只有不用它。但现在可以说，你投入努力就能让它变好」。

团队主管的新职责：推动大家从 solo 模式走向 shared 再到 multiplayer(多人协作)模式——就像当年建共享库而不是每人发明自己的库。一个团队优化了共享组件，所有团队都受益，这是复利效应。

招工程师：要系统思考者，不要语言原教旨主义者

今天招人，Patrick 找的是系统思考者：关心代码之外的一切，不一定要资深，初级但对系统感兴趣也行。协作和改进能力比独门手艺重要。

一个具体的探针问题：「你怎么跟上行业？关注哪些社区？

」如果对方只提自己的语言、自己的技术栈，那就是危险信号。他观察到与 DevOps 类似的规律：适应得最好的是三四十岁、伤疤攒够了的人；工作方式僵化的人不会被雇。

扩展组织：别在消极面上花时间

被问最多的就是「怎么让组织更快」。Patrick 说有两部分：有些没法加速——你必须亲身经历过提示词工程，才知道自己缺 spec、缺 context、缺 harness,这个学习阶段绕不过。

能做的是团队主管控制节奏的「强制功能」：比如宣布「大家都懂提示词了，现在把所有 context 和 skills 放进仓库」，于是突然发现需要测试、需要互信，团队就被推着跳到下一级。「如果主管不发出跳的信号，每个人都会继续用老办法——还在用补全，不用规则」。

推广策略是经典转型打法：一开始别在抵抗者身上花时间，先找到成功案例——「如果成功案例做不出来，其他的都不会成。他们会展示可能性、展示收益，吸引其他人来问：你们怎么做到的？

」等采纳度上来了再去问抵抗者：是什么在阻碍你？配套动作是黑客马拉松、午餐学习会、表扬做得最好的团队——「这是 DevOps,是云，是开发者安全，全是同一套打法」。

新指标：贡献共享组件，而不是 token 亿万富翁

度量采纳的指标也在演进：先是「大家用没用工具」，然后是「token 用量」——但那只是代理指标，用得多只说明热情高，不说明高效。Patrick 认为现在最好的单一指标是：这个人为共享组件贡献了多少、修了多少系统问题，以及「为了让智能体做对事，人类还需要碰多少次」。

因为一次共享 context 的改进会让所有团队的数字一起变好。真正在旅程中帮你的，是推动这个指标的人，「不是那些 token 亿万富翁」。

成本：砍预算是最糟的反应

第一年 AI 出现时没有 AI 预算，Patrick 当过 VP，知道这种挣扎，何况供应商还在涨价、改定价模式。直接砍预算的问题是断了学习之旅：人们额度不够就退回手动干。

正确的姿势是把预算约束当成优化循环的驱动力——很多人在盲目烧 token,用最大的模型，反复做同样的事，其实一次 context 或 harness 的改动就能省下大量 token。类比云计算早期：每个系统都开一台 VM,后来学会共用实例才降下成本。

具体做法：给 FinOps(云成本管理)和编码智能体上可观测性，研究遥测数据，安排一个团队专门做优化，而不是一刀切关预算。和 CFO 的博弈上，他的打法不是「最好的团队拿预算」，而是「把最好的智能体团队放到最重要的商业项目上，把回报做出来」。

护城河：持续学习的速度

收在他的核心主张上：如果持续交付把部署自动化了，AI 又把编码自动化了，那么知识复利的地方就只剩持续学习——「这正在成为一家公司的护城河：你能学多快？换一个新东西、哪怕重写整个代码库，你能多快？

」而没有反馈循环帮你改进，就做不到这一点。危险也要防：正反馈循环里一条被接受的错误规则会不断放大，所以 harness 和你放进去的任何东西都要有回归测试，不能「改完祈祷它跑得通」。

本集带走

• 别用成熟度当借口：说“持续交付/暗工厂对我们不管用”，多半是组织没准备好，不是技术不行。
• 收编怀疑者：让最怀疑 AI 的人去写 context、建 harness——投入努力确实能把它变好。
• 留住技术人的出口：不想写 spec 的人，去做 harness 工程、loop 工程、审查工具——这些是有技术含量的共享组件。
• 招聘探针：问“你怎么跟上行业、关注哪些社区”，只答自己技术栈的是危险信号；要系统思考者。
• 团队主管的强制功能：控制节奏节点，比如“现在把所有 context 和 skills 收进仓库”，推动全组从 solo 跳到 shared。
• 推广顺序：先打造成功案例再说，别在抵抗者身上花时间；黑客马拉松、午餐学习会、表扬最优团队。
• 换掉 token 指标：改看“人类还要为智能体碰多少次”和“共享组件贡献量”，token 用量只是热情的代理指标。
• 成本管理：砍预算断学习；上可观测性、看遥测、组优化团队，把预算约束当优化驱动。

就像如果我只是让它生成，那将是垃圾。如果我把我自己的上下文给它，像我的策展、我的品味、我的 harness，它就会说，嗯，不要供应商之类的东西，或者它必须有四个声音。
Like if I would just have it generate, it will be rubbish. If I had like my own context to it, like my curation, my taste, my harness, it would be say, well, not vendors or kind of like things or like it has to have four voices.
—— Patrick Debois · [12:35]

就像产品内的 AI，大概比在组件上进行 AI 编码领先两年。他们已经有了评估系统，已经有了可观测性系统。
Like AI product, AI inside the product is probably two years ahead from AI coding on components. They already have the eval system, they already have an observability system.
—— Patrick Debois · [17:13]

我们是冲着写代码来的，不是冲着做一个光鲜的提示词规范编写者来的。
We signed up for the coding, we didn’t sign up for a glorified prompter as specification.
—— Patrick Debois · [23:53]

我认为不管是现在的 AI 还是敏捷或任何变化，听起来很难，但在开始时不要在消极的事情上花时间。找到成功的故事。如果你不能让它成功，其余的都不会起作用。
I think regardless whether this is now AI or like agile or any change, um, as hard as it sounds, do not spend time on the negatives in the beginning. Find the success story. If you can’t make that work, the rest will not work.
—— Patrick Debois · [33:58]

如果我现在要提出一个衡量指标，那就是这些人有多少在为共享组件做贡献、在修复系统，而不是使用更多或拥有一个工具。
If I were to put one measurement right now is how much these people are contributing to the shared components and they’re fixing the system instead of kind of using more or having a tool.
—— Patrick Debois · [36:51]