感谢@DistilleryTech和@React_BA今晚邀请我做分享！

这是我的演讲文章版本：https://t.co/tkOPeVDv76

你决定结果：AI时代的产品工程

来源：https://kentcdodds.com/blog/you-own-the-outcome 我最近做了一场演讲，在没有亲自编写实现代码的情况下，将一个真实功能部署到了生产环境。我也没有逐行审查代码差异——是一个智能体编写了代码。我把时间都花在了其他事情上，我想告诉你们那是什么，因为我认为这是当前最重要的一项技能。

不久前我写过《最后的软件工程师》（https://www.epicproduct.engineer/the-last-software-engineer）作为思想实验：如果AI持续接管更多实现工作，我们还能做什么？我的答案是判断力。这篇文章将从实践层面阐述这个答案——不是“未来某天”，而是我现在如何与智能体协作来构建产品。

输出与结果的区分 (https://kentcdodds.com/blog/you-own-the-outcome#output-vs-outcome)

这是我反复强调的区别：

• 输出是代码本身：文件、函数、代码差异
• 结果是这些代码为用户带来的价值

在我们职业生涯的大部分时间里，这两者是紧密绑定的。想要获得结果，就必须亲自生成输出，而生成输出既缓慢又昂贵。所以我们精于产出，并用产出衡量自己：交付的代码行数、关闭的工单数、合并的拉取请求数。

这种绑定关系正在被打破。智能体现在非常擅长生成输出，而且进步迅速。但它们不擅长的是从一开始就判断哪些输出值得生成。

智能体产出输出。而你决定结果。

这不是安慰奖。决定结果一直是有价值的部分——只不过它过去被淹没在无数的编码工作中了。

用真实产品来思考 (https://kentcdodds.com/blog/you-own-the-outcome#a-real-product-to-think-with)

我将结合自己正在构建的产品来具体说明，因为关于AI的抽象建议太廉价了。Kody (https://kody.codes/) 是我在多年主要制作教育产品之后构建的第一个真正的SaaS应用，它的构建过程迫使我实践本文的所有内容。

Kody的存在源于我全身心投入智能体开发后遇到的两个问题。

问题一：智能体处理重复性工作成本太高。 我曾让一个智能体控制家中的百叶窗——它确实能工作！但每次开窗都要支付推理费用就太荒谬了。这种任务适合用一小段确定性软件来完成，而不是让大语言模型费力思考窗帘的事。更好的模式是只花一次推理成本创建持久化软件，然后让这段软件以极低成本持续运行。Kody就是存放这类软件的地方。

问题二：你的自动化会被困住。 每个智能体平台都想成为你集成、记忆和自动化服务的“大本营”。在单一平台设置所有功能后，你就被锁定了；或者不得不在新平台重新设置所有内容。在Kody中，Kody才是“家”，而智能体只是访客。它不与Claude、Cursor、Devin或OpenAI竞争，而是让所有这些平台都能共享和复用同一套持久化软件。

坦白说：第二点很难解释。我最初的定位非常混乱。最终简化的版本很简单：你的智能体可以共享和复用持久化软件，且无需锁定。想明白这点不是编码问题——没有任何智能体会直接给你答案，这是结果层面的工作。

无需编写代码即可交付功能 (https://kentcdodds.com/blog/you-own-the-outcome#shipping-a-feature-without-writing-it)

这是我现场构建的功能。Kody的软件包可以声明webhook，当你构建一个webhook时，会在真实流量到来之前先测试其功能。人们一直用笨拙的变通方法测试webhook——这个现象值得关注（稍后详述）。

我没有打开编辑器开始编码，而是像与熟悉代码库的资深队友协作那样，与智能体一起工作。

首先，建立共同理解 (https://kentcdodds.com/blog/you-own-the-outcome#first-build-shared-understanding)

在提出任何要求前，我确保我们已就问题达成共识：谁会使用它、用户试图解决什么问题、以及“完成”的标准是什么。如果跳过这一步，智能体会很开心地解决一个与你实际需求略有不同的问题，而且它会做得令人信服。

然后，要求提供选项而非答案 (https://kentcdodds.com/blog/you-own-the-outcome#then-ask-for-options-instead-of-an-answer)

我要求提供几个方案，并对每个方案评估：

• 大致需要多少工作量
• 有什么权衡取舍
• 这是单向门（难以撤销）还是双向门（后续易于调整）
• 智能体推荐哪个方案及理由

这种“门”的区分非常重要。双向门可以快速穿过，让智能体放手去做；而单向门（如公共API名称、数据结构、定价策略）则需要你放慢脚步、谨慎思考。

接着，做出决策 (https://kentcdodds.com/blog/you-own-the-outcome#then-make-the-calls)

以下是我们确定的方案（请注意这些决策与代码无关）：

• 交付最小可用切片。 通过Kody的MCP和API进行合成调度：用你提供的固定测试数据直接调用webhook处理器。这解决了智能体场景下“我的处理器是否正常工作”的核心问题——大部分测试都发生在此场景。
• 推迟UI测试按钮。 虽然有用，但不是当前用户急需的功能。后期易于添加（双向门）。
• 推迟完整的端到端流量预演。 很有价值，但工程量大得多，而最小切片已能解答大部分实际问题。
• 不承诺无法兑现的特性。 我最初想称之为“dry run”（预演），但处理器是调用真实服务的真实代码，我们无法诚实地承诺完全无副作用，因此命名不应产生误导。
• 合成调度需计入用量。 它消耗真实计算资源。免费提供看似友好，但会悄然破坏单位经济模型。
• 谨慎命名。 webhookDispatch听起来像是发送真实webhook；webhookSyntheticDispatch则准确描述了其功能。能力名称属于公共API，这是单向门。

智能体编写了实现、测试和拉取请求。自动化流水线和AI审查员完成了代码审查。该功能在问答环节结束前就已部署到生产环境：kody#2594 (https://github.com/kentcdodds/kody/pull/2594)。

我没有逐行审查代码差异，而是检查结果：它是否实现了我们商定的功能？我信任的自动化门禁是否通过？这之所以合理，是因为我事先搭建了完善的机制——而这正是让整个模式得以运作的关键。

如何成为智能体的优秀协作者 (https://kentcdodds.com/blog/you-own-the-outcome#how-to-be-a-good-collaborator-for-agents)

以下模式为我带来了最大改善：

• 始终优先建立共同理解。 先明确上下文，再下达指令。
• 要求提供带权衡分析的选项和推荐。 你需要的是智能体的思考过程，而不仅仅是它的编码输出。
• 用提问代替微观管理。 “如果我们做X会出什么问题？”比十步操作指南更有效。如果你在指挥每个步骤，那你是在替智能体工作，而不是在做自己该做的事。
• 保持技能专精。 一个能出色完成单个任务的专注技能，胜过一个试图覆盖所有场景的臃肿技能。智能体执行简短明确的指令时可靠得多。

人类工作的真正内涵 (https://kentcdodds.com/blog/you-own-the-outcome#what-the-human-work-actually-is)

如果智能体处理输出工作，你的时间应该用在哪里？我认为可以分为三类：

决定什么应该存在 (https://kentcdodds.com/blog/you-own-the-outcome#decide-what-should-exist)

• 将变通方法视为产品信号。 当人们（或智能体）不断用变通方案绕过某个问题时，那就是一个未被记录的功能需求。webhook功能正是由此产生。
• 不要做工单翻译员。 如果你的工作是将产品需求转写为开发指令，智能体现在就能做到。真正有价值的是判断这个需求是否应该被实现，以及它实际应该是什么样子。

设计游戏场 (https://kentcdodds.com/blog/you-own-the-outcome#design-the-playground)

• 构建良好的原语。 智能体的能力取决于你提供的构建模块。当原语设计得当时，你可以移交任务而非庞大规约。我在演讲《以原语思考：如何让智能体以更宽松的规约产出更好的结果》(https://kentcdodds.com/talks/thinking-in-primitives-how-to-make-your-agents-produce-better-results-with-looser-specs) 中深入探讨了这一点。
• 在风险较低或中等的场景自动化交付流程。 结构化的拉取请求、测试和AI审查员能让许多变更无需你中间介入即可部署。将注意力留给高风险的单向门决策。
• 隔离密钥凭证。 智能体应该能够使用凭证，但永远不应看到它们。一旦智能体代表你行动，这就是不可协商的底线。

监控结果 (https://kentcdodds.com/blog/you-own-the-outcome#watch-the-outcomes)

• 构建自我修复的自动化流程。 系统总会出错。要设置机制确保故障能被发现并分级处理（通常由另一个智能体完成），而不是静默腐坏。
• 掌握你的指标和单位经济模型。 “能用”不是及格线。它的成本是否合理？关于合成调度的用量决策就是微小案例。

你可能注意到这个清单上没有什么。选择哪个框架不如以往重要。针对特定任务使用前沿模型还是本地模型是实际权衡，而非身份认同——这些都是输出层面的选择，而智能体正越来越擅长与你共同应对这些选择。

对你职业生涯的影响 (https://kentcdodds.com/blog/you-own-the-outcome#where-this-leaves-your-career)

如果你在思考应该提升哪些能力，我的建议是：投资于判断力和结果意识。 靠近使用你构建产品的用户。练习公开权衡取舍并解释原因。习惯对结果负责——不仅仅是是否交付，更要关注是否真正有效。

智能体编写代码。最有价值、最“人性化”的工作是：决定什么应该存在、系统应如何行为、哪些权衡值得做，以及设计什么样的原语能让未来所有事情更简单。

选择一个本周正在开发的功能尝试这个方法：与你的智能体建立共同理解，要求提供带权衡的选项，自己做出决策，然后让智能体处理输出。我想你会惊讶于有多少时间被释放出来，用于真正重要的工作。

附言：本文源于我在Distillery (https://distillery.com/) 与React布宜诺斯艾利斯社区共同举办的Tech Night上的演讲。如果你还在犹豫是否要参加聚会分享，请去做吧。向满屋子的人解释你所知的内容会让你学到很多，这也是厘清自己真实想法的好方法。