先校准数字：同一场访谈的三组口径
Shopify 创始人兼首席执行官 Tobi Lütke 在播客 The Knowledge Project 中与主持人 Shane Parrish 谈到公司内部的智能体实践。这套实践在中文语境里被转述得很广，但数字口径已经出现分歧，引用前需要分开看。
公司今年 5 月披露的口径是：约八分之一的已合并变更请求有 River 参与。后续公开的实习项目材料显示，一个月内有约 5,938 名员工在 4,450 个公开 Slack 频道中使用 River，其变更请求的合并率在两个月里从 36% 提升到 77%。而在本次播客的转述中，出现了「约三分之一」与「最多约 50%」两种说法——后者指的是变更请求源自与人工智能的对话，而不是全部由智能体自动生成。
三组数字量级不同，含义也不同：参与、共同参与、源于对话、自动生成，是四种不同的归因强度。要引用，应回到原始访谈与公司披露材料，而不是二手转述。
River 的三条设计
真正可迁移的是设计选择，不是那些百分比。
它拒绝私聊。想让它干活，必须在公开频道里提出。Lütke 自己所在的频道有一百多名观察者。这条规则表面上牺牲效率，实际上把「一个人学会了怎么用」变成「所有人看得见怎么用」：别人可以观察他怎么提问、怎么看它犯错、怎么纠正、怎么拆任务、怎么验证结果。
它有名字、有头像，被明确允许在恰当的时候带一点讽刺，并且在需求本身有问题时可以直接指出来。这条设计的意图是反向的：多数团队把模型调成温顺谦和的客服口吻，而这里要避免的是「有求必应」的附和倾向。
它可以访问公司的代码与系统，在沙箱与安全约束之下。
公司在总结合并率提升时，把绝大部分改善归因于组织不断把经验写回技能与规范，而不是底层模型升级。这句话才是重点：能力增长落在了组织身上，不是落在了模型身上。
夜间复盘：把学到的东西写成文件
在非工作时段，系统会把 River 当天参与过的 Slack 对话记录整体喂回给它，让它复盘哪些技能包上遇到了挫折或犯了错误，产物是更新后的文本技能文件。
这条机制的价值不在「自我训练」这个说法，而在产物的形态。对话结束就蒸发了，文件会一直在，还能被比对、被回滚、被交给别人。材料里提到，一个团队为结账数仓写的技能包后来被另外 12 个团队复用——只有写进文件、进入版本管理，复用才可能发生。
由此可以带出一条直接的工程结论：规范要写在系统里，不要写在文档里。「请在公开频道提问」写进规范文档，几周后就没人记得；让智能体直接拒绝私聊，规则才真正成立。
垃圾手榴弹：过度产出成了新的怠工
Lütke 给出的反向观察是这次访谈里最有价值的部分：过去怠工的表现是产出不足，现在的失败模式变成了过度产出。
典型场景有两个。一个是代码：让智能体生成上千行变更，没有仔细看过就提交，本来为这个人省下两小时，却让另外三名评审多花几个小时。另一个是邮件：原本三百字能说清的事，用模型扩写成两千字，接收方为了省时间再把邮件丢给模型压缩。中间增加了大量词元与认知成本，却没有增加任何价值。公司内部把这种行为叫做垃圾手榴弹。
这不是 Shopify 一家的现象。2026 年有一项研究专门分析了 1,154 条 Reddit 与 Hacker News 上的开发者讨论，结论是：人工智能可以提高单个开发者的局部产出，同时把成本转嫁给整个系统——生成变多、变更请求变多、评审工作量增加、理解成本上升、长期维护成本上升。研究者用公地悲剧来概括这个结构：对个人而言多生成一点几乎没有成本，但这些产出最终必须由组织共同维护。
瓶颈没有消失，只是向下游移动
软件工程几十年来的主要瓶颈是写代码，整个产业都在优化这一环：高级语言、集成开发环境、框架、库、问答社区、补全工具、编码智能体。这一环正在被迅速打穿。
系统不会没有瓶颈。新的瓶颈正在变成理解、验证、评审与决策。相关研究也指出，代码生成速度提升之后，需要评审的代码量同步增长，人工代码评审越来越可能成为流水线上的堵点。工程师的角色因此发生迁移：从代码生产者，逐渐变成人工智能生产系统的质量控制者。
这也解释了为什么度量体系会先失效。过去衡量知识工作的方式本就粗糙——程序员看提交数、咨询顾问看演示稿页数。当模型可以轻易制造十倍数量的代码、文档、邮件与会议纪要时，继续按产出量考核就会触发一个经典的管理陷阱：指标一旦成为目标，它就不再是好指标。每个人看起来都更忙，活动量全面上涨，而公司的真实决策速度反而下降，因为所有人都在评审人工智能生成的东西。
机器不担责，这条边界没有被工具改变
访谈里被引用最多的一句话是：机器无法承担责任，人可以。
Lütke 描述自己处理重大决策的方式：让多个智能体分别扮演数据、学术研究、商业与工程视角，跨不同模型独立分析，再做随机化的综合对抗，最终输出一份尽量中立的简报。但按下按钮的必须是人——公司亏损了，模型不会被董事会问责；系统泄露用户数据，模型不承担法律责任。
由此得到一个不那么直觉的判断：智能体越强，人的执行价值可能下降，而人的责任价值会上升。与之配套的稀缺能力也从生产转向判断——生成正在趋势性变便宜，真正的问题是这些东西里面什么值得做。他把这种能力称为品味，指的不是审美水平，而是知道什么重要、什么不重要、什么时候该继续优化、什么时候应该删掉。
还有一条技术侧的佐证值得一提。Shopify 把移动端从推行了五年的 React Native 迁回 Swift 与 Kotlin 双原生开发，先完成迁移的是 Shop App，核心团队 6 人、12 周、从概念验证直接到正式发布。公司明确表示，改变这道经济账的不是语言本身变简单了，而是编码智能体改变了开发软件的成本结构。推倒重来的成本一旦下降一个数量级，很多既有的软件工程最佳实践都需要重新计算。
这份实践里真正可搬走的部分
如果只取三条：把智能体的交互放在公开可检索的地方，让组织学习替代个人技巧；把规范写进系统强制生效，而不是写成文档等人自觉；在度量上放弃产出量，转而去度量产出被采用的比例——一张图有没有进入测试、一段文案有没有被采用、一份方案有没有被讨论，没有任何一条被采用的产出就是无效产出。
需要说明的是，以上均为公司高管在公开访谈中的自述与内部材料口径，未经独立审计；合并率的变化也缺少对照设计，无法排除同期其他变量的影响。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。