跨国深谈← 返回←黑灯工厂来了:赢的不是单人玩家,是会改组织的团队

黑灯工厂来了:赢的不是单人玩家,是会改组织的团队

关联

人物 Patrick Debois

概念 智能体 · 暗工厂 · harness · 上下文 · 持续交付 · 持续学习 · 铺装路

这一集是一场大会演讲,主角是一位正在自己组织内部推动「黑灯工厂」(即几乎无需人工干预的自主工作方式)的工程负责人。他开场就说:2009 年大家嘲讽「持续交付」(让代码随时可以自动发布上线的实践)是疯了,今天人们对着黑灯工厂说的「在这行不通」,其实是同一句话——真正的含义不是「永远做不到」,而是「我们还没准备好」。

技术终会成熟,甚至可能有一天变成某个前沿实验室直接当服务卖的商品。所以那不会成为你的组织的差异化因素,真正的差异化在于:你怎么改你的团队、平台和组织。

开发者的身份危机,和一条新技术路径

他听到的常见叙事是「开发者会变成智能体的指挥家和编排者」。很多开发者的反应是抵触:「我们当初入行不是为了这个。

不是为了写更好的提示词、更好的规格说明。我们是工程师。」这造成了真实的摩擦。

转折发生在团队开始引入「线束」(harness,给智能体套上的约束与工具框架)和循环之后:突然出现了一条新的技术路径——为智能体造工具。那些原本觉得这事不适合自己的开发者重新被点燃了:「是的,我们能做这个,我们有那种知识,我们是在用编程的方式帮忙。」抽象化并没有消灭工程手艺,反而为工程工作创造了新的去处。

对待团队里最怀疑、最爱抱怨「智能体产出质量差」的人,他的建议是:利用那种愤怒。让他们去给智能体造更好的上下文、更好的线束——把怀疑变成改进系统的燃料。

最大的心态转变:别修代码,修系统

他给公司的核心建议是一句话:停止修智能体产出的代码,去改进系统。他引用了一个说法:别再构建那个东西,去构建「那个构建东西的东西」。

具体来说,团队应该在规划会和复盘会里换一套语言。复盘不再问「我们代码出了什么问题」,而是问「智能体一遍遍撞上的是什么系统问题,我们能不能修系统」。规划则出现一种分裂:定义得足够清晰的事项直接交给智能体,剩下留给人类的是那些没界定清楚、需要团队对话决策的事。

同时,工程实践不能丢。那些对优秀工程师说的要求——带测试、更新文档——现在要对智能体说。如果还有人 YOLO 式地乱来,要叫停:工程实践既是为了你能维护系统,也是为了让智能体持续变好。

两个指标:人类介入次数,和共享系统的乘数

他开始相信两个指标。第一个:让智能体把事做对,你还需要多少次人类介入——这个数应该持续下降,你的线束、上下文、指南越好,它越低。

第二个:从单人走向共享系统的乘数效应——你修一次,所有人都受益。这不是「一个人变成 10 倍强者」,而是一处对智能体的优化惠及整个组织。

团队主管的职责是给这套演进定节奏:「别再 prompting 了,把上下文做成可复用的」——然后推着团队跳到下一步。「你自己摸索去吧」的放养方式行不通。

还有一个容易被忽视的影响:团队产出变快后,下游(GTM、甚至用户)跟不上,所以线束不能止步于编码,要延伸去帮下游做自动化;输入端同理——需求收集的速度不够快时,也得接入那条工作流。

平台层:把复用变成注册表,不是代码仓库里的蔓延

要扩展到组织级,就进入平台团队的地盘。平台团队需要关注新冒出来的东西:技能注册表、针对上下文的评估系统、专门面向编码智能体的护栏、身份管理。

他的主张是:认证系统这种共享组件为什么要每个团队各自发明?大家用同样的 linter 和安全工具,那就是可复用组件,应该汇入平台注册表——类似云计算时代的「铺装路」。

但要防止蔓延:每个人往仓库里扔一个 skill、别人再 fork 一份,最后没人知道该用哪个。所以要给每个领域指定负责人,保证它是可测试的、模块化的、经过安全扫描的、被正经维护的。

他也不幻想完美共识:两个团队就工作方式达成共识需要大量沟通,最后往往是三、四条铺装路组成一份目录供挑选;想自搞一套可以,但走自己的预算。

成本可视化也是平台团队的活:把每个环节花了多少钱、省了多少智能体迭代展示出来,大家才会主动去优化。

组织层与招聘:头衔没意义,练习题有

再往上一层,他预测大多数公司的剧本:黑客马拉松、午餐分享、建 Slack 频道、搞先锋者计划——全是通用转型套路,当年推敏捷、推 DevOps 也这样。而「只发授权、让百花齐放」已被证明行不通。他的主张是:给团队负责人和平台下达明确的授权,让他们真正去做这件事。

招聘方面,他直言那些新头衔——AI 产品工程师、前置部署工程师、智能体工程师——「没有任何意义」,没法判断成熟度,因为没人真正成熟。他听到的主流做法分三步:先给一道练习题,鼓励对方放开手脚用 AI 做出来(用得越多越好,这测出的是杠杆 AI 的能力);然后做复盘走查,让对方解释为什么这么做——这测的是品味和工程功底;最后看协作:愿不愿意分享,是开放的还是单打独斗的人。这三块不必兼备,但要分开评估,别笼统归成「初级/高级」。

面对「供应商收费疯了、我们要限支出」的声音,他的建议是第一反应应该是「优化支出」:选对模型、给更好的上下文和线束,成本自然就下来了——而不是一刀切封顶。

昏暗工厂:风险光谱与持续学习

最后他回到黑灯工厂，但泼了盆冷水：现实大概是「昏暗工厂」。不是所有功能都会走向自主，你得决定愿意为什么功能冒多大风险。

可以投入的是审计(代码溯源、验证器检查改动是否有用)和失败时的态势感知。这是一个从「高度监督管理」到「自主批准」的完整光谱，由你定风险等级。

他把这一切收拢成一个概念升级:持续交付变成了**持续学习**——你把知识不断沉淀进技能、上下文和线束里。终极问题不再是「怎么让系统更可靠」,而是「我能不能在改动系统更多部分的同时,保持可靠」。

本集带走

• 别修智能体的代码,修系统:把复盘从「代码出了什么问题」改成「智能体反复撞上的是什么系统问题」;停止单点修补,去改上下文、线束和工具。
• 盯两个指标:让智能体做对事所需的人类介入次数(应持续下降),以及一处优化能让多少人受益(共享系统的乘数)。
• 怀疑者是资产:最爱抱怨智能体质量的人,正是最该被拉去给智能体造更好工具的人。
• 复用要进注册表,不是散落仓库:每个可复用领域指定负责人,保证可测试、模块化、过安全扫描;自搞一套走自己的预算。
• 招聘三步走:放开用 AI 做练习题 → 复盘走查看品味与工程功底 → 看协作与分享意愿;三块分开评估。
• 支出疯涨的第一反应是优化不是封顶:选对模型、给更好上下文和线束,成本随之下降。
• 接受「昏暗工厂」:按功能分级定风险,投资审计、溯源、验证器和态势感知,在持续改动中保持可靠。

我们当初入行不是为了这个。不是为了写更好的提示词、写更好的规格说明。我们是工程师。
We didn’t sign up for this. We didn’t sign up for better prompting, writing better specs. We’re engineers.
—— Patrick Debois · [03:11]

我想是 Swix 几年前说过的:别再构建那个东西了,而是构建那个构建东西的东西,对吧?
I think it was Swix a couple of years who said it, like, stop building the thing, but build the thing that builds the thing, right?
—— Patrick Debois · [05:44]

这不是一个人变成 10 倍强者所带来的乘数效应,而是对智能体进行优化的一项改变,会对所有人产生影响。
This is not the multiplier from the one person becoming the 10x person, but the one change that optimizes the agents has an impact on all the people.
—— Patrick Debois · [10:05]

如果你能改进它,归根结底,重点不是让整个系统更可靠,而是我能否在改动系统更多部分的同时保持可靠?
And if you can improve that, ultimately, it’s not about making the whole system more reliable, but can I keep it reliable while changing more of the system?
—— Patrick Debois · [20:55]

我认为如果说有一个要点的话,那就是赢得比赛的不会是单人玩家。
And I think if there’s one takeaway, it’s not the solo player that will win the game.
—— Patrick Debois · [21:33]