少发货，多测量

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您将其翻译成简体中文，同时保持原有的格式、Markdown 语法以及代码块和 URL 不变。

介绍

代码变得前所未有的便宜。原型可以在数小时内出现，曾经需要数周才能完成的复杂系统现在可以在几天内组装完成。这听起来像是进步，但在许多团队中，它却产生了一种新的失效模式：更快地交付错误的东西，并把表面的动作误认为是实际的影响。

这就是陷阱所在。

当实现成本降低时，决策质量变得更为重要，而不是不重要。如果一个团队并不清楚自己到底在解决什么问题以及成功将如何衡量，AI 就会成为混乱的倍增器。它会帮助你产生更多的代码、更多的架构、更多的内部工具，以及更多的维护负担，却没有提升这些工作实际价值的概率。

我一直坚持的原则很简单：

• 围绕一个可衡量的目标进行构建。
• 交付以消除歧义。

这两条规则听起来几乎是微不足道的。但在实践中，它们能够削减大量出乎意料的浪费。

AI 让过度工程更容易

大多数工程师并不鲁莽。问题比这更深层。

优秀的工程师通常以系统为导向。他们喜欢连贯的设计、可扩展的抽象、优雅的机制以及看起来面向未来的解决方案。这些都是有用的直觉，但当目标仍不明确时，AI 会把这些直觉变成负担。

一旦实现成本下降，过度工程就会成为默认选项。构建以下内容变得轻而易举：

• 针对仍然是假设性的问题构建 AI 流水线
• 在狭窄的使用案例得到验证之前就搭建通用系统
• 创建难以进行清晰评估的自适应体验
• 添加比用户价值更增加运维负担的自动化层

问题不再是 “我们能构建它吗？”，因为现在答案几乎总是 是。

真正需要问的问题是：

1. 这会推动关键指标吗？
2. 我们能证明它真的推动了指标吗？
3. 演示之后我们还能运营该系统吗？

如果这些答案不明确，提速并没有帮助——它只会把错误隐藏到后期。

规则 1：围绕单一可衡量目标构建

A team needs one scoreboard.

• Not “improve onboarding.”
• Not “make the product smarter.”
• Not “invest in AI capabilities.”

单一可衡量的目标。

示例：

Activation = percentage of new users who reach the first success moment within 10 minutes.

这个定义立即完成了大量工作。它强制保持清晰。每个想法现在都必须回答一个简单的问题：这如何提升激活率？ 如果答案模糊，就不应立即构建。

该规则还消除了常见的失败模式：将多个想法捆绑在一次发布中。当团队一次性更改太多内容时，因果关系会消失。若结果改善，没人知道原因；若结果恶化，没人知道该撤销什么。团队最终用故事取代了证据。

重要提示： 工程团队不应单独定义目标。业务、产品或任何负责结果的方需要对指标进行批准。这种对齐不是官僚主义，而是防止团队陷入技术上炫目的、但实际上没人需要的工作的一种保护。

Source: …

规则 2：通过发布消除模糊性

交付常被描述为交付价值。但在项目早期，这种说法并不完整。

早期发布主要是为了获取信息。

每个产品团队都在模糊性中工作。人们对用户想要什么、摩擦点在哪里、以及何种体验能驱动增长都有自己的看法。这些看法大多只部分正确。唯一可靠的降低不确定性的方式是发布足够小的东西，使结果能够教会你具体的东西。

这就是第二条规则重要的原因：发布以消除模糊性。

发布应当被设计成回答一个问题，而不是满足所有人的愿望清单。

示例： 如果团队认为用户流失是因为账户创建出现得太早，那么第一次发布应当尽可能直接地检验这个想法——不是一次重新设计，也不是一个跨多个季度的入职计划，而是能够确认或否定假设的最小干预。

代码在那个时刻并不是产品。 代码是你购买信息的收据。

一个具体例子

想象一个团队面临增长问题。安装量健康，但新用户无法达到第一次成功时刻。他们打开应用，犹豫后便消失。

目标：

Activation = reaching the first success moment within 10 minutes.

团队发现最大的流失点：在用户获得任何价值之前就强制创建账户。

路径 1 – 乏味的修复

• 添加 “Continue without account.”（继续而不创建账户）。
• 缩短通往首次有价值操作的路径。
• 将注册推迟到价值可见之后。

这并不光鲜。它狭窄、缺乏吸引力，且容易被忽视。但它是对“价值之前的摩擦抑制激活”这一假设的干净测试。

路径 2 – 诱人的 AI 修复

“给我三天时间，我会构建一个 AI 入职礼宾服务。”

系统将会：

• 推断用户意图
• 个性化流程
• 动态重写文案
• 根据角色适配体验

听起来现代、具战略性，像是雄心勃勃的团队应该做的事。这也是许多团队陷入困境的地方。

三天 AI 承诺

危险不在于 AI 的概念不可能实现。危险在于它 在被验证为真正产生影响之前，就看似已经产生了影响。

AI 入职系统并不是单独出现的。它会带来隐藏的运营负担：

• 评估复杂性
• 模型漂移
• 延迟
• 监控
• 隐私审查
• 成本不确定性
• 版本管理问题
• 支持负担
• 值班责任

在演示中看似快速的解决方案，往往会悄然演变为长期的维护税。

如果激活后没有提升，团队往往会 学到的东西比采用笨办法时更少。部件太多，解释太多，合理化的空间太大。

关键点： AI 让创建看起来很酷的系统变得更容易，但这些系统可能永远无法推动关键指标的提升。坚持两条规则——一个可衡量的目标和交付以消除歧义——以确保进展真实且可持续。

简单更改 vs. 复杂 AI 系统

简单的更改会干净地失败。复杂的 AI 系统会嘈杂地失败。

为什么组织仍然走错路

如果逻辑如此直白，团队为什么仍然会过度构建？

因为大多数组织并未针对 clarity（清晰度）进行优化，而是针对 ownership（所有权）、visibility（可见性）和 perceived impact（感知影响）进行优化。

人们不仅仅想帮助业务，他们想拥有看起来最重要的东西。而现在，几乎没有比 AI 项目更重要的了。

这就产生了可预测的系统效应：

• Leadership（领导层）希望在路线图上加入 AI。
• Performance systems（绩效体系）奖励可见的 AI 工作。
• Ambitious people（有抱负的人）倾向于选择 AI 方向的项目。
• Skepticism（怀疑）被误认为是缺乏远见。

在这种环境下，乏味的修正不仅仅是乏味——它在政治上也很弱。

主张进行小规模、可衡量实验的人很容易被贴上“想得太小”或“没有拥抱 AI”的标签。与此同时，提出构建大型 AI 平台的人则显得具有战略性、雄心勃勃，并且符合高层的兴奋点。

这就是为什么问题不仅仅是技术判断；它是 incentive design（激励设计）。人们往往是在对周围系统做出理性的响应。

困难之处

没有人能对此保持绝对的个人免疫。

我也陷入了同样的陷阱——并非因为无能，而是出于同样的野心、好奇心、激励以及真诚的信念：更大的 AI 方案或许能解决比狭窄修补更广泛的问题。

正是这点让这个问题值得认真对待。它不仅涉及粗心的团队，也涉及那些想要做有意义工作的有能力的人。

AI 并没有产生错误判断，它放大了判断不清晰的代价。

更好的标准

在构建更大的系统之前，团队应当 获得构建它的权利。

这通常意味着：

1. 挑选一个重要的指标。
2. 确定与该指标相关的最窄假设。
3. 交付能够检验它的最小改动。
4. 测量结果。
5. 仅在简单版本证明存在真实提升空间时才增加复杂性。

• 如果简单的修复有效，太好了——你以低成本解决了问题。
• 如果简单的修复部分有效，也许可以考虑更高级的解决方案。
• 如果简单的修复失败，这同样有价值。你在不引入大型系统的情况下排除了一个假设。

这就是有纪律的速度的体现：不是更快地构建所有东西，而是 更快地降低不确定性。

多衡量，少交付

这个说法在一个痴迷产出的文化中听起来颠倒，但正因为如此，它才重要。

• 多衡量。
• 少交付。

并不是说交付本身不好，而是未衡量的交付是昂贵的表演。

AI 并没有改变什么会成功；它加速了什么会失败。

因此，当实现成本降低时，标准应当提升：

• 更清晰的目标
• 更小的测试
• 更紧密的反馈回路
• 少叙事，多证据

速度只有在你有地图时才有用。没有地图，你并不是在更快地走向成功——而只是加速驶向更复杂的失败。