DevOps之父：发几个Claude Code账号就叫AI转型？Agent用不好是公司的锅
核心观点
- 不要再修 Agent 产出的代码了，去修那个产出代码的系统。
- 如果团队里还有人用"YOLO（先跑通再说）"的野路子搞 vibe coding，应该立刻制止。工程实践不仅对维护系统至关重要，对 Agent 自身持续变好也至关重要。
- 暗工厂可能不是全暗，而是保留了"微光"（dim factory）——你得决定对什么功能承担多少风险，不是所有功能都适合完全自治。
- 能极致用 AI、有扎实工程功底、愿意分享和协作，将这三点组合，才是你要找的人。
- 护城河是抓住沉淀下来的知识——那些注入到 skill 里、Context 里、甚至 Harness 约束里的业务上下文。
"给开发者配上 Claude Code，组织就转型了？"
2009 年持续交付被视作疯狂的想法，如今暗工厂（AI 驱动的自治软件生产模式）遇到了完全一样的阻力。人们在各种场合说"这东西在我们这儿行不通"，但这句话真正传达的是"我们还没准备好"——不是技术不行，而是整个组织的设置还没法支持这种模式。
最终 Harness、循环等技术都会变成标准商品，技术壁垒会消失。真正的差异化在于组织怎么围绕 Agent 重构协作方式。
开发者身份摩擦
开发者被告知会变成"Agent 的编排者"，但很多人私下说：我们入行不是为了花大量时间优化 Prompt、写 SPEC 的。Context engineering 概念给了开发者一个台阶，但很多人仍觉得只跟 Prompt 打交道很空虚。
转折点出现在引入 Harness、循环、更高程度自治时——开发者需要帮 Agent 造工具，这重新点燃了一批人。"手艺"感在"抽象、抽象、再抽象"的潮流中反而在另一个位置重新冒了出来。
不要修代码，修产出代码的系统
怀疑者是你的宝贝
持怀疑态度的人脑子里有大量隐性知识和判断力，需要把这些灌进 Agent 里。对天天抱怨"生成代码质量太差"的人，可以把他们当作燃料——把愤怒和怀疑变成改进系统的动力。
心态转变：不要修 Agent 产出的代码，去修那个产出代码的系统。 就像有人说过的：别造那个东西了，去造那个能够造那个东西的东西。现在通过 Context、Harness、循环来造"能造东西的东西"。
工程实践同样适用于 Agent
用好的工程实践最小化人类干预次数。不只是通过 Prompt 给 Agent 下指令，而是在说：请带测试一起写、请更新文档、请遵守代码规范。原来对好工程师说的那些话，现在全部原样搬给 Agent。
回顾会和计划会的变化
- 回顾会：不再说"代码出了什么问题"，而是说"系统出了什么问题？"
- 计划会：定义清晰、范围明确的任务直接丢给 Agent；边界模糊、需要商量的事情留给人类。出现自然分工——这些卡片走 Agent 流水线，那些卡片我们来聊。
团队 Lead 的价值
开发者经历学习周期：Prompt → 更好的 SPEC → Context → Harness → 循环。团队 Lead 的价值在于设定节奏和约束："别再调 Prompt 了，把 Context 做成可复用的。""好，这一步做完了，我们跳到下一步。"如果只是丢一句"自己去摸索"，那是不灵的。
两个真正的生产力指标
- 人工干预次数：让 Agent 做对一件事还需要多少次人工干预？这个数字应该持续下降。
- 乘数效应：从单兵作战转向共享系统后，一次对 Agent 系统的优化能在所有人身上产生乘数效应。
连带效应
团队生产率暴涨后，下游（GTM、用户）跟不上，需要用自动化帮助他们。上游需求输入也同理——如果需求来得不够快，团队会被卡住。
别让每个团队都造一套 Harness
平台团队需要接手新东西：
- 技能注册中心：不能让每个人都在自己角落里发明同一套技能
- Context 评估系统：这段 Context 到底有没有用？能不能量化？
- 针对 coding agent 的护栏和身份管理：Agent 以谁的身份提交代码？权限边界在哪？
必须有明确的 owner 来驱动。集中维护的才是"轻松路径"（Paved Road），用来吸引大家走上去。如果谁都能往中心仓库丢东西，会迅速野蛮生长——谁在维护？fork 了类似的 skill 该选哪个？
建立共识很难。最后可能不是只有一条铺装路，而是三四条可选。非要自己搞一套也可以，但那是自己的预算。
花费可视化是优化的前提
把花费透明化：花了多少？帮到了什么程度？如果减少 Agent 迭代次数就是优化。看不到指标就没法下手。
核心主张：从单打独斗的开发者 → 团队层面的共享 Context 和共享组件 → 整个组织内部的"多人游戏系统"。乘数效应会在那里爆发。
超级个体救不了 Agent 时代的组织
"发许可证、搞培训、让大家自由发挥、让一千朵花绽放"这个策略从来就没成功过——一千朵花的结果通常是一千根杂草。组织侧要明确授权，让团队 Lead 和平台团队去做这件事。
面试新方式
- 第一关：给一个练习，让候选人用 AI 放手解题。如果 AI 能帮他们搞定，说明擅长利用 AI。
- 第二关：请他们查自己的方案，解释"你为什么选这个方案？怎么验证它是对的？"——测试的是工程判断力。
- 第三关：看协作意愿，是开放型还是单干型。技术很强但什么都要自己捏在手里的人，在 Agent 时代反而会成为瓶颈。
目标人才画像：能极致用 AI + 有扎实工程功底 + 愿意分享和协作。这三个是不同的技能维度，别混在一起贴"初级"或"高级"标签。
VP 工程部如何向上交差
买了这么多许可证，能证明投入产出吗？交付变快了？质量变好了？都很难证明。但可以展示：干预次数减少了多少、复用率提升了多少。这比比较"有 Agent 和没 Agent 的编码生产力"更有说服力。
关于 Agent 花费
当有人抱怨 Agent 太能花钱时，本能反应不应是"把花费都砍掉"，而是"怎么优化花费"。选对模型——不是所有任务都需要最强模型。教育开发者什么场景用什么模型，给他们更好的 Context 和 Harness，让 Agent 少走弯路。
团队规模
一个全能型人才把所有活干了是终极梦想，但算一下：需要搭配互补技能（产品/设计），考虑 backup，盯生产和工单，带新人铺路。所以不可能真的让每个团队变成一两个人。
暗工厂不是全暗
暗工厂保留了"微光"（dim factory）——根据风险水平为不同类型的变更选择不同的自动化程度。从完全微观管理（每行代码都要人看）到完全自主审批（假设 Agent 产出都对），这是一整个光谱。可以在审计方面投入更多：溯源谁改的代码、加验证器检查代码是否真的有用、当自动流程失败时投资于情景感知能力。
护城河
护城河是抓住沉淀下来的知识——那些注入到 skill 里、Context 里、甚至 Harness 约束里的业务上下文。这把持续交付带向了持续学习。关键问题不再是"我要让整个系统更可靠"，而是"我能不能在改变系统越来越多部分的同时，保持它的可靠性？"
赢家不会是那个单打独斗的超级玩家，而是那些在多个层面上懂得如何改进组织的人。