Steve Test：这项工作是否值得存在？

本周早些时候，我交付了一项工作，而正确做法恰恰是不发布它。一个翻译管道会把本站内容写入Cloudflare D1，覆盖10个语言区域。3个翻译任务同时触发速率限制；回退机制悄无声息地把英文源文当作其中6个语言区域的“译文”写入D1，然后又更新检查点哈希，使其匹配英文内容。在磁盘上，它看起来像成功。管道报告“完成”。指标显示10个语言区域均已发布。所有自动检查全部通过。

一位德语读者访问/de/guides/claude-code时，会先看到一段德语，再看到一段英语，然后又是一段德语，接着是一个英语小节标题。没有任何标记解释这些语言切换。页面看起来像是有意为之，并让整个网站显得不可信：像那种大概率在其他用途上也会失手的产品。我已埋点的每一层都通过了Jiro Test（工作是否正确？）。然而，这件东西并不值得存在。它看起来像产品，实际体验却像一种冒犯。

正确答案是停下来，审计每一个英文回退批次，精准清除检查点哈希，一次只运行一个翻译任务，逐个语言区域验证，然后提交、推送。实际经过的翻译时间大约6小时，外加一个用于防止复发的防护补丁。磁盘上的产物一直都在“工作”。生产环境中的产物却是我亲手造成的伤害。

无论产物是翻译管道、注册流程、功能开关、CSV导出，还是营销页面，失败的形状都一样。每个自动检查都通过了。真正落到真实用户面前的东西却是伤害。

产品中的根本问题不是做完了吗？也不是能运行吗？根本问题是：这项工作是否值得存在？每个产物在发布前都必须回答这个问题，同时还要通过另一项独立的正确性测试。只有正确性、没有存在价值，会制造库存：能运行、能发布，却无法赢得信任的东西。只有存在价值、没有正确性，会制造表演：感觉对，却会坏。两项测试都必须通过。

我使用的简写是Steve Test。它与强调严谨和证据的Jiro Test并列。它们是同一个头脑提出的两个不同问题；任何一项不通过，我都不发布。

摘要

Steve Test是每个产物必须通过的第二项测试。Jiro追问工作是否正确；Steve追问这项工作是否配得上您正在构建的整体。这个测试是具体的，不是抽象的。它衡量的是某个真实用户在某个真实时刻的处境，而它最稳定的输出是拒绝。我会削减范围。我会删除功能。留下来的东西必须配得上我的名字。两项测试都必须通过。Jiro失败，就停下修复。Steve失败，就重建。最多3次诚实重建；之后问题就在上游，在问题框定上。

为什么“做完了吗？”是错误问题

大多数产品团队优化的是“可发布”。可度量的输出是提交、部署、速度图表、生产环境里有了某个东西。失败模式可以预见：团队稳定产出一串功能正确的产物，同时悄悄消耗用户信任。新手引导完成了，第二次会话却不再发生。支持工单集中在产品声称能处理的任务周围。流失曲线不是趋于平稳的核心用户，而是一路衰减到零。

完成和值得是两种不同的度量。一个功能可以做完，却不值得存在。一个页面可以成功渲染，却冒犯读者。一篇译文可以在技术上存在，却实际上是谎言。判断某件事是否完成，看它是否执行了指定行为。判断某件事是否值得，看一个真实用户在一个真实时刻是否因为您发布了它而处境更好。

我在最小值得产品中的论点是，MVP文化在实践中把两个问题压成了一个：快速学习退化成快速发布，而发布成了真正重要的指标。⁷解法是双重标准。“最小”削减范围。“值得”让留下来的用户接触面达到用户能感受到的标准。Steve Test就是用来判断剩余用户接触面是否过线的工具。

根本问题

这项工作是否值得存在？

我会按字面使用这个问题。当我完成一项工作，需要决定是否发布时，我会把这个问题说出口。答案是裁决，不是感觉。如果答案是肯定的，这项工作就有资格发布，接下来的问题是它是否也通过了Jiro Test的正确性检验。如果答案是否定的，它需要重建或删除。如果答案是还不行，但通过一个明确的修正动作可以达到，那就继续工作。

只有当答案可以是不时，这个问题才真正有效。一个对眼前所有东西都盖章通过的Steve Test不是测试。测试确实在运行的信号，是有些工作会被它淘汰。

用户锚点：存在价值从不抽象

一旦Steve Test变成对孤立作品的品味争论，它就失败了。要用特定用户在特定时刻的处境来衡量存在价值。更准确的测试问题是：这项工作是否值得为此刻的这位用户而存在？

对blakecrosley.com来说，用户是从搜索冷启动进入页面、带着关于Claude Code、Codex或基础设施问题而来的读者。时刻是页面加载后的前5秒，在页面尚未赢得任何信任之前。一个页面如果加载迅速，清晰呈现观点，并告诉读者一些搜索结果尚未回答的内容，就过线了。一个页面如果用缓慢的资源包、无法关闭的Cookie横幅和一堵泛泛SEO文字惩罚读者，无论它在Jiro轴上得分多高，都失败了。

对ResumeGeni来说，用户是求职者，而我会把这个时刻视为脆弱时刻。早期候补名单中的大多数人，是在裁员之后或面试周期中间加入的。⁶值得存在的版本拒绝把他们当作转化指标。文案不闪烁其词。解析器不会谎称自己发现了什么。建议足够具体，用户可以立刻行动。流程不会因为我只发布了理想路径，就在中途抛下他们。

用户锚点能防止Steve Test变成我个人偏好的储物柜。如果我说不出用户是谁、他们处在哪个时刻，也解释不清已发布用户接触面如何尊重并增强他们，我就还没有应用这项测试。我只是宣称自己应用了它。

双重测试：Jiro加Steve

完整原则需要两项测试，而不是一项。¹任何一项失败，我都不发布。

Jiro Test问的是：它做得正确吗？它要求证据。边界情况已处理。看不见的细节已完成。每个主张都引用具体证明。不允许含糊：我认为不是证据。测试通过。没有回归。证据关口是我用于代码报告和代理输出的Jiro Test版本，而Jiro质量哲学是更深入的阐述。

Steve Test问的是：这项工作是否值得存在？它要求存在价值。与整体保持一致。具备可见的观点。能说出某个为了保持用户接触面干净而做出的拒绝或删除。有读者能识别的愉悦或清晰机制，而不是空泛带过。配得上署名。

仲裁很简单。Jiro失败，停下修复。不正确的工作不能发布；Jiro的否决权是绝对的。Jiro通过但Steve失败，重建。正确但不值得的工作同样不能发布。两者都失败，问题就在上游，在简报、问题框定或范围里。只有同时通过两项测试的工作，才有资格发布。

大多数发布文化都会悄悄只运行其中一项。工程主导的文化通常Jiro很强、Steve很弱：测试通过就发布，存在价值成了别人的部门。设计主导的文化有时Steve很强、Jiro很弱：看起来对就发布，正确性成了运营问题。两种失败模式都会制造出您一眼能认出的产物。漂亮的假东西。正确却没有灵魂的工作。您见过它们。您也可能发布过它们。

两项测试并列如下：

完整产品体验：您拥有总体验

Steve Test不会孤立地评判产物。它会把产物放进用户实际遭遇的总体验中评判。

开头的翻译事故是最近最清晰的例子。具体失败机制值得展开，因为它展示了陷阱的形状。当Claude子进程触发速率限制时，管道的回退机制把英文源文写入D1。D1写入器接受了这些字节，因为它们就是字节。检查点更新器对已存内容做哈希，并把该哈希写入磁盘。由于已存“译文”和英文源文完全相同，哈希也完全匹配：相同字节产生相同哈希。下一次--update运行时，会把英文源文哈希与已存哈希比较，发现两者相等，于是将该批次标记为未变更。每个组件孤立看都通过了自己的Jiro Test。缺陷藏在组合里。在有人打开其中一个页面前，用户已经看到了持续数小时的6个混合语言区域页面。

“我们对完整产品体验负责”是规则。产品行为、UX流程、语言、数据真实性、支持系统、打包、文档准确性、提示词、规则、记忆、技能、钩子、脚本、编排、输出结构。全部都归您负责，不只是最近交付的那个产物。如果局部胜利损害了整体完整性，它就不可接受。当某个用户接触面局部通过、但总用户体验没有通过时，Steve Test就会启动。

删除：只会新增的Steve层是假的

Steve Test最有用的单一产出，就是删除。

一次评审如果没有移除任何东西，就还没有真正运行。面对一个具有真实复杂度的用户接触面追问这项工作是否值得存在？，几乎总会产生至少一块无法为自身存在辩护的范围、文案、功能或可操作项。一次什么都没找到的评审，通常是在表演评审，而不是实践评审。

Steve Test具体寻找的是：

• 因为“放进去很安全”而存在的用户接触面，而不是因为它赢得了位置。
• 因为删除保留说法就必须提出真实主张而选择闪烁其词的文案。
• 从旧版本沿袭下来、但不再服务当前承诺的功能。
• 为处理当前范围内并不会真正发生的边界情况而添加的可操作项。
• 把本该由制作者做出的决定转嫁给用户的配置选项。
• 描述产品已不再具备的行为的文档。
• 覆盖本应被删除代码的测试。

删除是区分品味与堆积的动作。值得存在的用户接触面，比没人追问时原本会发布的版本更小。我从未后悔从已发布产品中移除某个东西。相反，我经常后悔自己留下了什么。

拒绝是首要动作

与删除相关，但更强：Steve Test往往在任何东西被构建之前就会启动，而不是之后。品味的首要动作是拒绝：决定根本不做那件事。

这里真正重要的Steve Jobs那句话是：“我为我们不做的事感到自豪，就像为我们所做的事感到自豪一样。”这句话出现在2006年BusinessWeek关于Apple产品纪律的封面报道中。⁵人们常引用这句话，因为它在一个具体的技术意义上是真的。每个已发布产品周围，都环绕着一圈不可见的、您拒绝发布的产品。那一圈才是真正的观点。它证明做决定的是人，而不是待办列表。

对blakecrosley.com来说，技术栈就是我修剪过什么的记录。我考虑过React，然后拒绝了它。我考虑过Tailwind，然后拒绝了它。重建的前两周，打包器一直摆在桌面上，之后我把它删掉。整个仓库里不存在node_modules/，这不是一个设计选择；这是我长期维持的一项拒绝，用来对抗默认工具链的引力。这些拒绝比任何纳入的东西都更深地塑造了工作。它们定义了我愿意坚持的标准。

对ResumeGeni来说，验证结果很干净。340个邮箱注册、12个直接咨询、3个主动提出为早期访问付费的请求。⁶这些需求暴露出来的待办列表很大：模板、团队协作、分析仪表盘、LinkedIn集成、Indeed集成、版本历史、多种导出格式、移动应用。我在第一个发布版本中拒绝了所有这些。我不能拒绝的是：准确解析、诚实的差距评估、贴合职位描述的具体改写、能在Word中顺利打开的导出，以及一个让脆弱状态中的用户感到安全的流程。被拒绝的东西并非永远消失。它们在值得存在的第一层用户接触面之后等待。

一个什么都不拒绝的用户接触面没有观点。如果团队什么都没有拒绝，范围就是错的。

尽早戳破假象，先从自己开始

拒绝和删除只有在测试能真正指出虚假成功时才有效。Steve Test必须戳破假象，而且要迅速戳破这些东西：

• 假进展。看起来像进展、却没有产出任何东西的动作。
• 被污染的证据。因为错误原因而通过的测试；只证明了您想证明的东西、而不证明事实的统计。
• 虚荣计数。提交数量、已发布产物数量、速度图表：全都有，也全都偏离重点。
• 不一致的系统。孤立发布时很干净，组合起来却相互损害。上面的翻译事故就是其中之一。
• “一切都在正轨上”的报告。它们掩盖了没人做出的决策。Steve Test就是这些报告的敌人。
• 低价值机器活动。计算机做某事只是因为它能做，而不是因为输出赢得了位置。

最困难、也最稳定有用的版本是：先戳破自己输出中的假象。本文开头的翻译事故正是如此。管道报告成功。日志干净。我埋下的每个指标都通过了。这项工作是假成果，而我必须在用户指出之前先对自己指出。对自身工作的反假象纪律，才能让测试保持诚实。礼貌不是抵挡事实的盾牌；忙碌也不能替代价值。

交付面梯度：校准通过标准

Steve Test不是只有单一阈值的一次性通过。一个用户接触面越难收回，通过标准就必须越严格。²

测试仍然是同一个问题。答案所需的严格程度，会随着影响半径扩大而提高。聊天回复可以在下一轮修正；不会有人因此受害。一个未通过Steve Test的生产部署会烧掉数月才赢得的用户信任，而修正成本会高于当初发布决策所节省的成本。

实际后果是，交付面越难逆转，发布节奏就应该变慢，而不是变快。团队若在可逆性差异极大的交付面上保持统一速度，就等于在暴露他们并不认为测试会随交付面变化。通常，他们已经停止运行这项测试了。

品味不是脾气

Steve Test还需要一个区分，因为这也是最常被丢掉的区分。提到Steve，指的是他的品味，而不是他的脾气。

这套原则明确禁止以下内容：³

• 残酷。
• 羞辱。
• 表演式轻蔑。
• 愿景家角色扮演。
• 用攻击性替代判断力。
• 怨气表演。
• 把戏剧性误认成标准。

Steve层真正运转的信号，是平静的拒绝。“不，这项工作还不够值得交付。”这句话应作为裁决说出，随后给出具体修正动作。不是表演。不是羞辱做出不合格版本的人；那个人往往就是您自己。不是对团队表现出可见的轻蔑。不是到处宣称自己标准更高。工作要么过线，要么不过线。标准并不是严厉姿态的审美。

这个区分很重要，因为漫画化的Steve Jobs聚焦的是脾气。任何被“扮演Steve”的人管理过的人，都知道我在说什么。残酷不会让工作变好。它会让工作场所变坏；同时，因为它用表演替代判断，也会让发布出来的工作变坏。

判断您处在Steve的品味层，还是在扮演Steve脾气的操作性测试，是看测试输出是否产生了一个具体技术动作。“这项工作不值得存在”不是结论；它是一个问题的开端。答案必须指出失败的轴、修正动作和下一项测试。如果评审停在“这项工作很差”，却说不出什么会让它变得值得，那这次评审就是表演。

重建上限与反瘫痪条款

没有停止规则的高标准会变成逃避。我对每一项非平凡工作采用的纪律是：最多3次诚实重建。

诚实尝试意味着您识别了失败的轴，命名了具体修正动作，实质性改变了方法，并依据两项测试重新评估了工作。3次重复同样的润色流程，不算3次尝试。那只算一次失败尝试被重复了3遍。

如果3次诚实重建后仍然无法产出值得存在的工作，问题几乎从不在工艺。问题在上游，在问题框定、范围、简报或团队构成中。停止重建用户接触面，回头审视前提。有时承诺大过了现实中能守住的标准。有时验证比您以为的更软。有时问题根本不是产品问题。

重建上限同时解决两种相反的失败模式。它拒绝认可薄弱工作，也防止打磨变成躲藏。拒绝发布本身并不天然高尚。为了追求完美而无限重建，是另一种失败模式：有工艺，没有勇气。目标不是完美。目标是值得存在且已经发布。不是纯净但永远待定。

如果同一个用户接触面已经进入第4次重建，您就不再是在做产品，而是在把项目当作躲藏之处。

可观察信号：测试真的运行了吗？

Steve Test很容易被声称，真正运行却很难。纪律在于具体说明测试产出了什么。

在我称一项非平凡工作完成之前，我会确保自己能回答以下所有问题：⁴

1. 用户是谁？不是用户画像原型。是真实处境中的真实的人。
2. 这个用户接触面承载什么观点？如果说不出来，就没有观点，只有待办列表。
3. 为了保持它干净，您拒绝或移除了什么？删除就是测试运行过的证据。
4. 它如何服务完整产品体验？这一部分必须与其他每一部分一致。损害整体的局部胜利不是胜利。
5. 什么证据证明它可靠？Jiro轴。验证已运行；主张有支撑。
6. 它为什么值得存在？直白说明。如果答案含糊，测试就没有运行。
7. 我会毫不退缩地为它署名吗？品味判断的最终锚点。当判断不确定时，这是整个栈中的根本问题。

如果我无法用具体内容回答这7个问题，我就只是在宣称原则，而不是应用原则。我会把工作退回去。

示例：用7个信号检验一个真实用户接触面

下面把这些信号应用到翻译事故后发布的一个具体用户接触面：我写进翻译管道的并发防护。大约100行Python，如果已有另一个翻译进程在运行，就拒绝启动guide_bootstrap.py或blog_translate_batch.py。

1. 用户是谁？两周后准备开始一次翻译运行的我。到那时，我会忘记导致6个语言区域出问题的确切速率限制失败模式。还有未来会调用这两个脚本的任何代理。
2. 这个用户接触面承载什么观点？并发翻译运行从来都不是正确工具。防护把这个裁决编码进代码，让下一位调用者不必记住它。
3. 为了保持它干净，我拒绝或移除了什么？我拒绝把防护做成警告。我拒绝给它一个简短方便的覆盖标志，例如--force。唯一覆盖方式是环境变量I18N_ALLOW_CONCURRENT=1，足够长，没人会误打出来。
4. 它如何服务完整产品体验？翻译管道、D1写入器和回退机制各自都是正确的。防护是防止它们组合成一个会静默污染整体的那一块。
5. 什么证据证明它可靠？我用两项手动检查验证了防护。第一：没有其他翻译任务运行时干净返回。第二：真实guide_bootstrap.py子进程存活时以非零状态退出。两项检查都针对实际脚本运行，而不是mock。
6. 它为什么值得存在？在防护存在时，同一类导致6个语言区域被污染的并发运行竞态，不能再产生混合语言的D1行。它不是所有情形下的预防；它是针对这套原则刚刚学到的具体失败模式的预防。
7. 我会为它署名吗？会。一个职责，干净的覆盖语义，并在记忆笔记中记录，让未来会话继承这项防护存在的理由。

这个示例的重点在于，每个信号都有一个具体答案。当我给不出答案时，测试还没有运行。

对照一下失败是什么样子。当我起草并发防护时，我对第3个信号的第一次回答是：“我拒绝过度设计它。”这句话听起来没问题，却什么也没说。拒绝过度设计没有命名任何我曾考虑并否决的具体东西。它是一种姿态，不是拒绝。我强迫自己写出真正的答案：我拒绝把防护做成警告；我拒绝方便的覆盖标志名；我拒绝在无法列出进程时让防护失败放行的行为。这些才是决策。第一个版本只是教条表演。

关键要点

给创始人和独立构建者： - 在称任何用户接触面值得存在之前，先说出真实时刻中的真实用户。抽象的存在价值无法使用。 - 每个已发布用户接触面都应该至少有一个可见的拒绝。如果什么都没删，范围就是错的。 - 应用交付面梯度。生产部署需要比草稿更严格的通过标准；营销主张需要最严格的标准。

给产品负责人和PM： - 通过统计每个发布周期中的拒绝和删除数量，衡量Steve Test是否真的在运行。零是异味。 - 在自己的评审清单中，把“能运行”和“值得存在”分开。把它们当作独立轴。 - 保护重建预算。3次诚实尝试，然后上升处理。不要让完美主义变成躲藏，也不要让期限压力杀死测试。

给工程负责人： - 为团队交付的每个用户接触面明确一个Jiro验证关口和一个Steve验证关口。两者都必须通过。 - 投入到看不见的细节中。正确与值得之间的差异，通常就藏在细微衔接处。 - 拒绝脾气。平静的拒绝才是信号。表演严厉是失败模式。

给设计师： - 观点不是装饰。它是让产品可被识别的机制。 - 值得存在的用户接触面会清晰地拒绝一些东西。您的工作包括说出您删掉了什么。 - 面对不确定性时的操作性测试是：您会毫不退缩地为这个决策署名吗？

结语：我会为它署名吗？

产品中的根本问题是：这项工作是否值得存在？当判断不确定时，整个栈中最简单的问题就是根本问题。

我会毫不退缩地为它署名吗？

如果答案是肯定的，这项工作就有资格发布。如果答案是“还不行，但3次诚实重建内可以达到”，那就继续工作。如果答案是否定的，并且3次诚实尝试后仍然是否定的，就重建简报，而不是重建用户接触面。

我每次都会运行这项测试。对代码。对文案。对提交信息。对文档。对产品用户接触面。对这篇文章。

这篇文章删掉了3个我起草时以为需要的小节：一段很长的Jobs传记部分，一段关于“dent in the universe”那句话的入门说明，以及一段解释为什么这套原则使用真实人名而非抽象概念的辩护。它们都没有服务我正在为之写作的用户：一位正在判断某个不确定用户接触面是否该发布的构建者。删除让文章更小，也更诚实。文章开头的翻译失败，除了修复本身，还产生了一个永久产物：翻译管道中的并发防护，现在会在另一个翻译任务已经运行时拒绝启动。被拒绝的工作改变了规则。这套原则学会了东西。

Steve通过。Jiro通过。发布。

FAQ

什么是Steve Test？

Steve Test追问的是，一项工作是否值得为某个真实用户在某个真实时刻而存在。它与Jiro质量哲学并列：Jiro检查正确性、证据和边界情况；Steve检查存在价值、一致性、拒绝和品味。

Steve Test与Jiro Test有什么不同？

Jiro追问工作是否做得正确。Steve追问正确的工作是否应该发布。一个功能可以通过测试，却仍然辜负用户、产品或用户接触面背后的观点。

团队应该何时运行Steve Test？

在不可轻易逆转的用户接触面发布前运行：公开部署、营销主张、新手引导流程、定价页、文档，以及会塑造用户信任的产品功能。轻量工作可以使用较柔和的通过标准，但公开用户接触面需要严格标准。

测试应该产出什么？

测试应该产出一个具体决策：发布、重建、删除或拒绝。真正的通过会命名用户、时刻、观点、证据，以及团队为保护整体而移除的至少一件东西。

Steve Test会变成完美主义吗？

会。这就是为什么这套原则需要重建上限。3次诚实重建已经足够；之后问题通常在上游，在简报、范围、团队或前提中。

评审模板

把它复制到草稿本、PR描述、Notion页面，或提交信息顶部。在宣布非平凡工作完成前填完它。如果无法用具体内容回答某一行，测试就还没有运行。

Steve Test：评审记录

用户：        [处于真实情境中的真实的人，而不是用户画像原型]
时刻：        [用户遇到这项工作的具体时刻]
观点：        [这个用户接触面主张什么；拒绝做什么]
拒绝：        [我考虑后删掉了什么，或完全拒绝构建什么]
完整体验：    [它如何与产品相邻的每一部分保持一致]
证据：        [Jiro轴：验证已运行；主张有具体证据支撑]
值得结论：    [是/否/尚未达到，但可在N次明确重建内达到]
署名：        [我会毫不退缩地为它署名吗？如果不会，就停止]

这个模板只有一个任务：迫使测试者在每一行都给出具体答案。含糊答案不能过线。“我拒绝过度设计它”不是拒绝；“我拒绝了一个方便的覆盖标志和一个失败放行路径”才是。“它服务用户”不是完整产品体验答案；“它补上了导致上次事故的那个具体组合缺口”才是。当某一行抗拒具体化时，工作还没有准备好；这种抗拒正是测试在告诉您重建应该去哪里。

这个模板是本文的操作性产物。页面上的其他内容，都是在解释为什么这些行存在。

参考资料