如何避免「垃圾手榴弹」
· Matt Senter
我给客户的建议很直接：没有 AI 的协助，你无法竞争；靠生产 AI 垃圾内容，你同样无法竞争。 用好这些工具，同时保留正确使用它们所需的专业能力。
Shopify 首席执行官 Tobi Lütke 最近把未经审阅就丢给同事的 AI 产出称为「垃圾手榴弹」。他举的例子包括那些臃肿的邮件，逼着收件人自己去把有用的信息挑出来。有人因此觉得自己很高效，而另一个人却继承了收拾残局的活儿。
这个描述很贴切。但当这种事发生在一个组织内部时，我首先会问：管理层决定奖励什么，它保留了哪些专业能力，以及有没有人在衡量某人点下「完成」之后才真正开始的那部分工作。
我大量使用 AI 来构建软件。我没有兴趣回到那个需要我手敲每一行代码的世界。我推荐的组合是经验丰富的人加上强大的 AI 工具，而人的贡献在智能体动笔之前就已经开始了。总得有人来选择方案、设定约束，并判断哪个解法值得去做。
管理问题排在第一位
Shopify 在 2022 年 7 月裁掉了约 10% 的员工，Lütke 承认自己高估了疫情期间电商繁荣的持久性。2023 年 5 月，他宣布了另一轮约 20% 的裁员，同时出售 Shopify Logistics。第二次公告还强调了新兴 AI 时代带来的机会。这些都是关于公司方向、人员配置和优先级的领导决策。
2025 年 4 月，Lütke 把使用 AI 变成了基本要求，将其纳入绩效考核和同事评议，并要求申请增加人手或资源的团队先解释为什么 AI 无法满足这个需求。他的备忘录也明确主张用 AI 放大人的能力。这个原则我是认同的。
这些事实并不能证明 Shopify 的裁员导致了它的垃圾手榴弹，也不能证明有经验的工程师被大批换成了不懂技术的提示词操作员。但它们确实说明了为什么管理层这个问题重要。制定人员政策和 AI 使用预期的人，同样要为让这套组合真正跑通负责。
我反对的是这样一种运营模式：要求员工证明自己在用 AI，却不给予同等分量的判断力、验证和维护——而正是这些把生成出来的产出变成有用的工作。在问 AI 能不能做某件事之前，管理层应该先问：要正确交付这个结果需要什么。这不是同一个问题。
智能体能产出一个 pull request 吗？很好。谁知道它解决的是不是对的问题？谁来检查架构上的影响？出问题时谁负责？另一位员工要花掉一天中的多少时间来审阅和修补它？
员工仍然要为自己提交的东西负责。但当人们反复把自己无法评估的工作丢给彼此时，我看到的是组织设计问题，而不仅仅是一群令人失望的员工。领导层不能一边把生产力提升的功劳收下，一边把收拾残局当成人才问题。
按回车不是工程
不懂技术的人用 AI 造东西，本身没有任何问题。降低试验的门槛，是这项技术最令人兴奋的部分之一。以前连草图都推进不下去的人，现在可以探索一个能跑起来的原型，我觉得这非常棒。
不过，原型和生产系统是两种不同的责任。总得有人理解到底构建了什么、它依赖哪些假设，以及什么样的证据能说明这些假设是错的。
在智能体和部署按钮之间放一个人，并不会自动带来有意义的监督。这个人需要有知识去质疑智能体，有时间去核查它的工作，还要有权否决结果。否则，审批这一步只是走个过场。
这并不只是 AI 怀疑者的顾虑。GitHub 自己的指引就警告说，它的智能体可能产出错误或不安全的代码，建议对其输出进行审阅和测试，并指出 AI 代码审查应当是人工审查的补充，而不是替代。
盲目批准是一个「垃圾进、垃圾出」的问题，但垃圾未必只出在提示词里。它可能是一条不完整的需求、一个缺失的约束、一种催你走得太快的激励，或者一个本质上是在问同一个系统「你干得好不好」的审查流程。解决办法是雇用那些知道什么时候该说不的人。
工程是知道怎么做，而不只是提出要什么
告诉智能体产品应该做什么，和知道这个产品应该怎么实现，两者差别巨大。「给我做一个能处理这些记录的系统」描述的是结果。它几乎没有说明架构、预期负载、内存预算、安全边界，或者出错时的行为。
一位优秀的 AI 辅助工程师会补上这些缺失的方向。他可以让智能体遵循项目既有的编码范式、复用现成的抽象、选择合适的数据结构，或者避开那种随着输入增长而代价高得离谱的算法。写仓库指引只有在有人知道这些指引该写什么的时候才有价值。
这并不意味着要规定每一个实现细节，也不意味着假定人的第一个想法就一定更好。我希望智能体提出替代方案并质疑假设。但总得有人理解得足够深，才能评估这些方案，而不是接受听上去最自信的那个解释。
「把它写高效点」替代不了对效率的理解。「把它写安全点」也不是一个安全模型。在有人把它们翻译成具体需求、并验证实现确实满足这些需求之前，它们都只是愿望。
大 O 并没有消失
看一个简单的例子：用唯一标识符在两个集合之间匹配记录。一种实现可能会为第一个集合中的每条记录反复扫描第二个集合。当两个集合各有 n 条记录时，这可能需要 n² 次比较。另一种做法是，对固定长度的标识符构建基于哈希的查找结构，可以把匹配降到期望 O(n) 的时间，代价是额外 O(n) 的内存。这是时间与空间的权衡，不是格式偏好的问题。
在小规模演示里，两种实现都可能给出正确答案。工程上的问题是：在产品真正需要承受的负载下会发生什么。它要处理多少数据？可用内存有多少？这是偶尔执行一次的操作，还是每个请求都会发生？
有经验的操作者可以给智能体有用的方向：「不要为每条记录重新扫描整个集合。构建一个查找结构，考虑它的内存开销，并用我们预期的输入规模做基准测试。」这样的指令来自对问题的理解，而不是发现了什么神奇的提示词。
同样的理解也应该防止不必要的优化。我不希望智能体因为有人让它「把性能做到极致」，就把一个微不足道的操作变成一套繁复的框架。我希望操作者对时间复杂度、空间复杂度和真实需求理解得足够透彻，从而选出合适的方案。
计算机科学并没有因为指令现在用中文来写就变成可选项。我们改变的是请求软件的方式。我们没有改变那些让软件正确、高效、可维护的性质。
有时候你得告诉它去写一个状态机
假设我在做一个后台导入流程，它可能处于排队中、运行中、已完成、已失败或已取消。一种看似合理的实现会用一堆彼此独立的标志位来跟踪进度。但这种设计必须防止出现相互矛盾的组合，比如一个任务同时处于运行中和已完成。
有限状态机给这个流程一组明确的状态，以及它们之间已定义的转换。与其把「接下来允许发生什么」的判断散落在整个应用里，我可以建模哪些事件可以把流程从一个状态推到另一个状态。这就是状态机表示法背后的基本概念：状态、事件和转换。
智能体也许会自己提出这个方案。那很好。但它也可能不会，而指挥它的人需要认出什么时候这个问题需要它。有时候有用的指令是：「把这个实现为有限状态机。定义合法的转换，显式处理取消，并测试当完成事件在取消之后到达时会发生什么。」这是在为系统的行为选择一个模型。
有限状态机、状态图以及其他自动机，属于人类操作者的技术工具箱。不是因为每个功能都需要形式化模型，而是因为操作者应该能认出什么时候引入它能澄清问题，什么时候只会徒增复杂度。知道一个模式的名字还不够。你需要理解它适用于哪里、能保证什么，以及它没有解决什么。
而且「用状态机」不是一句能让实现自动变正确的咒语。我仍然要检查那些转换并测试行为。它的价值在于，我给了智能体一个我能据以推理的结构，而不是因为某段条件判断通过了顺利路径的测试就接受它。
人机交互同样不是可选项
计算机科学不是我们仍然需要的唯一专业能力。人机交互同样重要，我不打算因为智能体生成一个界面和生成背后的代码一样快，就把它当成可有可无的收尾工作。
我预计互联网会有越来越多的部分变成以智能体为先。但我仍然在做需要人去理解和使用的产品。这些人需要知道正在发生什么、他们的选择意味着什么、某个操作是否成功，以及出错时如何挽回。可见性、一致性、用户控制和错误预防是公认的交互设计原则，不是装饰性的偏好。
「做一个好界面」的有用程度，大概和「把算法做高效」差不多。一位称职的专业人士可以给智能体精确得多的方向：围绕用户的任务组织信息，保留熟悉的导航，区分主要操作和破坏性操作，让进行中和失败的状态清楚可懂。无障碍还补上了具体的实现要求，包括键盘操作、可见的焦点、有意义的标签和可访问的状态提示。
拿状态机那个例子里的后台导入流程来说。把内部状态理清楚只是工作的一部分。我还希望界面能区分等待开始、正在导入、部分完成、已取消和已失败。使用它的人不应该只能从一个转圈的图标去猜这些差别。
我给智能体的指令可能是：「失败之后保留用户的选择。说明哪些记录导入成功、哪些没有。在操作真正完成之前不要显示成功提示。标明是否仍可取消，并把重试行为讲清楚。」
这是实现层面的指导，不是在要更好看的配色。我仍然要亲自用这个界面、测试相关状态，并观察人们是否看得懂。一张精致的截图不足以证明交互是成立的。
同样的道理也适用于智能体自身的界面。用对话替代菜单，并不能免除沟通范围、进度、不确定性和后果的必要。我甚至认为，一个跨多个系统行动的智能体让这些设计决策更重要，而不是更不重要。人仍然需要一条途径去理解、中断、纠正和批准这些工作。
以智能体为先的互联网，不等于与人无关的互联网。只要还是人在指挥工作并承担后果，就需要有人来设计这层关系。
按回车不是安全策略，也不是隐私策略
代码质量只是责任的一部分。智能体还可以请求访问文件、执行命令、与服务交互，并生成含有漏洞的代码。GitHub 自己的指引明确警告了错误或不安全的输出，以及仔细审阅和测试的必要性。
在批准一个动作之前，我希望操作者会问：它能访问什么，它能改动什么，数据可能流向哪里。这个任务真的需要生产环境凭据吗？那些调试日志里会不会包含客户信息？一个只需要读取数据的操作，为什么会有修改或删除的权限？
这些不是等演示跑通之后再操心的细节。OWASP 把过度的功能、权限和自主性列为智能体系统的风险来源。它的建议包括限制能力、执行最小权限、对高影响操作要求审批，以及在模型之外实现授权，而不是指望模型自己判断什么是允许的。
一个盲目批准每一个请求的人，并没有在真正评估这些风险。但答案也不是简单地雇一个有经验的人，然后指望他什么都能发现。要给这个人一个边界被真正强制执行的环境、恰当的访问控制，以及一个不依赖完美警觉的审查流程。
这就是我为什么在意操作者的理解力。他需要参与设计这些防护措施，而不只是坐在审批按钮前面的那把椅子上。
合规是工程的一部分
一个在演示里能跑的产品，未必是一个组织能负责任地运营的产品。还得有人理解它处理什么信息、谁能访问这些信息、适用哪些义务，以及组织需要什么证据来证明自己的控制措施确实有效。
视业务而定，这可能包括 SOC 2、PCI DSS 和 HIPAA。它们是不同类型的义务和保证机制，而不是三枚可以互换的徽章：
- SOC 2 是依据适用的 Trust Services Criteria 对控制措施进行的独立检查。这些准则包含变更管理：对系统变更进行授权、记录、测试、批准和实施。智能体产出一次成功的构建，并不能证明组织遵循了这个流程。
- PCI DSS 为支付账户数据确立了技术与运营安全要求。它的适用范围可能涵盖影响持卡人数据环境安全的系统和服务提供商，而不只是直接存储卡号的数据库。理解这个范围，是负责任地设计和运营系统的一部分。
- HIPAA 在适用于受保实体及其业务伙伴时，带来保护电子受保健康信息的要求。它的安全规则包括风险分析、访问控制、审计控制，以及与业务伙伴签订适当协议。这些责任不会因为有 AI 助手参与编写应用就消失。
我不指望每个开发者都是合规律师或审计师。我指望一个有经验的团队能认出这些要求何时会影响设计，并在上线前引入合适的专业力量。「没人告诉智能体」是需求上的失败，不是一种豁免。
对于影响重大的生产变更，我希望有一条审计轨迹，把请求与实现、测试、审查、批准和部署连起来。改了什么？为什么改？审查的是哪个版本？谁批准的，依据什么权限？最终真正进入生产的是什么？
这份记录应当在工作发生的同时产生，而不是事后靠某人的记忆和智能体那份欢快的总结拼凑出来。一条写着「已批准」的记录，只能证明有人点了一个按钮。它本身并不能证明发生过有意义的审查。
批准是一个决定，不是一次按键
不看清后果就按回车，可能让组织、它的客户以及批准这个动作的人都陷入风险。设想一个智能体提议把生产日志上传到外部服务去排查问题。在批准这个请求之前，得有人弄清楚这些日志里有什么，以及那个目的地是否被允许。所谓方案很方便，回答不了这两个问题中的任何一个。
绕过必需防护措施的员工也可能面临后果。例如，美国卫生与公众服务部关于 HIPAA 处罚政策的指引讨论了从警告到解雇的各种后果，同时把恰当的处理方式留给组织和具体情形去判断。这并不是说每一次误批都该让人丢掉工作。它提醒的是，一次批准可能承载着职业责任。
但管理层不能在不提供行使这份责任所需的知识、时间、信息和权限的情况下，就公平地把它分派出去。给一个人一堆他无法评估的待批事项，用他清空队列的速度来考核他，然后再为结果责怪他，这不是负责任的授权。
审批界面本身也得支撑这个决定。对于一次部署，我希望审查者能看到真实的改动、目标环境、相关测试结果、尚未解决的风险和回退方案。我不希望用一句「继续？Y/n」来代替对即将发生之事的说明。
我同样不想要一套对每个无害操作都要求人工批准的流程。我的目标是在既定边界内自动化低风险的工作，把人的注意力留给需要判断的决定。增加按钮不等于增加监督。
福特不得不重建它丢掉的专业能力
彭博社在 2026 年 6 月报道，福特在此前三年里招聘了 350 名资深工程师，其中包括前员工和来自供应商的工程师。他们在帮助解决质量问题、培训更年轻的员工，并改进那些没能达到预期的 AI 工具。这是一则关于整车工程和质量体系的报道，并不是说福特重新雇了 350 名软件开发者来清理生成出来的应用代码。
这是我会带进一家软件公司的教训。在把一位昂贵的工程师从表格里划掉之前，先搞清楚这个人在可见产出之外贡献了什么。问问他避免了什么、提前发现了什么，以及团队其他人依赖他理解哪些事。然后再想想，更好的工具能帮他做成什么。
别再把更低的薪水和更低的成本混为一谈
管理层想压低人力成本。我理解。我也经营企业，并不是在建议公司花钱不求回报。但我会拿这个回报去对照交付和维护一个有用产品的成本，而不是简单对照每个参与者身上贴着的薪水数字。
一个朋友最近给我发了一份纽约市现场办公的软件工程师职位描述。它要求硕士学位和六年行业经验，开价 20 万美元。这个组合在我看来说不通。对于我希望用来主导有实际后果的 AI 辅助开发的那种工程师，我会用另一种方式来设计这个岗位。
首先，除非这是一个那种训练确实重要的研究岗位，否则我会去掉硕士学位的要求。我想知道这个人造过什么、承担过哪些艰难的决定，以及他是否理解这些决定的后果。要求具备计算机科学知识，和要求某一张特定文凭，不是一回事。
他能解释为什么选择这种架构而不是那一种吗？他能识别一条安全边界、对性能做出推理、设计一个在出错时表现合理的系统吗？他能把智能体引向一个好的实现，并否决一个看上去成功却不满足真实需求的方案吗？
这些才是我会据以招聘的能力。然后我会按年薪约 35 万美元、每月最多 2000 美元用于 AI 协助来做预算，并期望招聘流程能证明这位候选人配得上这笔投入。
这是我为一个高影响岗位提出的预算，并不是说每个工程岗位都该拿同样的钱。开出更高的薪水，也不能免除管理层认真评估候选人的责任。重点是为战略所依赖的专业能力积极竞争，而不是假定一份 AI 订阅会让这种能力变得不那么值钱。
给工程师一份认真的工具预算
每月 2000 美元的额度是 AI 工具的总预算，不是某一份订阅的价格，也不是必须花光的指标。对于经批准的用途，我想到的是类似报销一份 Claude Max 方案再加上额外用量。Anthropic 提供超出方案包含额度的付费用量，并带有支出控制。
账户和部署方式仍然要符合组织的安全、隐私和合同要求。报销一份个人订阅并不能解决这些问题。团队需要为所涉及的信息和系统选择合适的安排。
按满额算，这是每年 2.4 万美元的 AI 支出，加上 35 万美元的薪水，也就是在福利、雇主税、奖金、股权和其他管理成本之前，薪酬加工具共 37.4 万美元。工具的花费不到薪水的 7%。我会根据它让这位工程师交付出什么来评判这笔开销。
在一个刻意简化的、只看薪水和工具的比较里，37.4 万美元是 20 万美元的 1.87 倍。如果更贵的那套组合交付出超过 1.87 倍的、可比的有用工作，那么它每单位工作的成本反而更低。这是对经济账的一种说明，不是预测。真正的比较需要把两边的完整成本都算进去。
我的野心是把一个 10 倍开发者变成 100 倍开发者。这些数字描述的是我想追求的目标，不是保证的生产力倍数。我会预期一位精挑细选、工具强大的工程师，胜过一种「找个更便宜的人、再假定 AI 会补上缺失判断力」的招聘策略，但我会用交付出来的工作去验证这个预期。
这一切都不意味着初级开发者可有可无。我希望他们在有经验的人身边学习，一边用 AI，一边培养出质疑它的知识。昂贵的错误是撤掉他们的导师，又因为管理层认定智能体会提供经验，就把他们还没准备好承担的责任压上去。
一个容纳人与智能体的组织
这就是我用 Orgabot 所围绕构建的组合：人和 AI 智能体在一个组织里担任明确的角色，工作流则规定责任、权限、检查和审批。目的是把组织的工作方式写得足够明确，让自主工作能够在真正有意义的边界内发生。
我在意的区分是：哪些东西允许智能体去推理，哪些东西必须由周围的软件来强制执行。灵活的规划和实现，应当与工具访问控制、必需的审批、测试结果和审计证据并存。「必须取得批准」这件事，不应该只是提示词里一条智能体可以自行重新解释的建议。
对于一次影响重大的生产变更，我想要的工作流以一位合格的人确立目标和约束作为起点。智能体可以调研、提出方案、实施变更，并协助测试与审查。随后，负责的人依据与风险相称的证据做出评估，获批的变更才进入生产。
我希望批准与真正被审查的那个版本绑定。如果实现在那之后发生了实质性变化，它就应该重新经过必要的审查。我还希望有一份清晰的记录，涵盖请求、所做的工作、执行过的检查、做出的决定和部署结果。
这就是我所说的「带着合规意识设计 Orgabot」的含义：把责任和证据做成流程的一部分。它不意味着装上一个工具就宣布组织已经合规。组织仍然要确定自己的义务、配置恰当的控制措施，并证明它们确实有效。
人的贡献贯穿始终。总得有人认出这里需要一个状态机、质疑一个昂贵的算法、守住一条隐私边界、识别出一项适用的合规要求，或者解释为什么某个界面会让人困惑。这些责任可能分属几位有经验的专业人士。组织架构图应该让这份归属清清楚楚。
我会怎样避免垃圾手榴弹
按担责去配置人手，而不是按审批去配置。 把有后果的工作交给能够评估结果、并在部署之后继续为它负责的人。按展现出来的理解力去招聘，而不只是看学位、看长长的简历，或者看对最新模型的热情。给经验较少的人配上指导，以及一条培养这种理解力的路径。
在生成方案之前先定义成功。 写下你需要的行为、不可违背的约束，以及验收这份工作所需的证据。把失败场景也写进去。智能体先产出代码、再产出与这段代码相互印证的测试，这远远不够；验证必须回到最初的需求。
让审查真实发生，并为此配足资源。 为检查改动、质疑假设、测试集成、核对真实用户体验留出时间预算。可以用 AI 协助这些活动，但不要把另一个模型的认可当成信任结果的唯一依据。负责的人必须能够叫停流程，而不会被当成生产力的绊脚石。
衡量整件事的成本。 把澄清、生成、审查、修补、部署和支持所花的时间连同工具成本一起算进去，再拿它和交付出来的结果作比较。一项任务并不会因为一个人更快收工、而三位同事吸收了差额，就变得更高效。
这些都不要求拒绝 AI，也不要求刻意放慢。它们要求的是，对「完成」到底意味着什么保持诚实。
条件由管理层决定
Lütke 反对那种给别人制造更多工作的做法，这是对的。我反对的是把这种行为，与围绕它的人员配置、激励机制和标准割裂开来看待。一家公司的 AI 战略，包含谁在用这些工具、这些人理解什么，以及管理层期望他们去验证什么。
我理解想要压低人力成本。我会通过「每一美元换来更好的结果」来追求这一点，哪怕这意味着在某一位工程师身上花得更多。按展现出来的专业能力招聘，出得起争夺它的价钱，并提供让这种能力真正发挥作用的工具和工作条件。
一边削减评估工作的能力，一边扩张生成工作的能力，是一种非常高效的垃圾手榴弹生产方式。没有 AI 的协助，你无法竞争；靠生产 AI 垃圾内容，你同样无法竞争。 决定最终得到哪种结果的那些条件，掌握在管理层手里。