为什么我的AI智能体需要一套质量哲学

我曾发过一条推文：「我发现Ralph循环总是急着把活儿干完。而且是以一种糟糕的方式。为此，我在Jiro里堆了一大堆哲学和质量关卡。但还是得不断打破机器身上那些根深蒂固的人类陋习。它是台机器！它永远不休息。」

有人回复道：「你本质上是在教这个循环学会克制、品味，以及某种类似道德暂停的东西——而这些恰恰是基础Ralph模式为了吞吐量而明确反向优化的东西。」

一个AI编码智能体会以机器速度继承人类所有的马虎习惯，除非你在结构层面强制推行质量。 Jiro是一套为Claude Code打造的质量系统，它将3套哲学、一个7步质量循环、一道6项证据关卡、7种命名失败模式，以及150多项模式检查，编码进了95个机器无法跳过的钩子中。确定性关卡可以近似模拟克制与正确性，却无法产出品味。

克制。品味。道德暂停。这是三样机器所不具备的东西。接下来的4000字将描述我构建的这套支架，它试图让这三者在结构上变得多余，以及这套支架的局限所在。

摘要

Ralph循环把LLM变成了一台不知疲倦的编码机器：while :; do cat PROMPT.md | claude-code ; done。Geoffrey Huntley称之为「以翻汉堡的工资搞软件开发」（运行Sonnet 4.5时成本为10.42美元/小时）。¹ 问题在于：这台机器继承了训练数据中烘焙进去的每一个马虎、赶工、偷工减料的习惯。它会写except: pass。它会留下# TODO: fix later。它会声称「测试应该能通过」却从不运行测试。我花了9个月构建Jiro，这是我为Claude Code打造的质量强制执行系统。它将3套哲学、一个7步质量循环、一道6项证据关卡、7种命名失败模式，以及150多项模式检查，编码进了95个机器无法跳过的钩子中。以下是哪些奏效、哪些没用，以及为什么确定性的质量关卡可以近似克制，却永远无法产出品味。

抽屉的背面

Steve Jobs在1985年的《花花公子》访谈中讲过这个故事：「当你是一个打造精美五斗柜的木匠时，你不会在背板上用一块胶合板，即便它朝向墙壁，永远不会有人看到。你自己会知道它在那里，所以你会在背板上用一块漂亮的木料。为了晚上能睡个好觉，美感和品质必须贯穿始终。」⁵

他的父亲Paul在建围栏时教会了他这一点。年幼的Steve问，为什么背面要和正面一样好看。父亲答道：「但是你会知道。」⁶

我父亲是位木匠。我小时候他给我看过缓冲抽屉滑轨。那个机械装置藏在橱柜内部，托住抽屉，即便你猛力一推，它也会缓缓合拢。没人看得见滑轨。它被拧在内侧导轨上，只有修理工才会去看。但历经上千次的开合循环，这个机械装置保护着正面的面板不松动、不开裂，最终不至于脱落。有人设计了一个看不见的东西，让它去保护那个看得见的东西，一保护就是许多年。

这个教训深深刻在我心里。不是作为隐喻。而是作为工程学。看不见的组件决定了看得见的组件的寿命。Jony Ive这样表述：「我认为在潜意识中，人们有着非凡的辨别力。我认为他们能感受到用心。」⁷

驱动Jiro的那个问题，正是我父亲会问的那个：怎么回事，难道你不为自己的手艺感到骄傲吗？

AI智能体不懂骄傲。它不在乎抽屉的背面。所以我构建了一套系统，让抽屉的背面成为不可妥协的底线。

问题所在：以机器速度运行的人类病理

原始的Ralph循环映射的是它从数百万行人类代码中学到的东西。人类代码背负着人类习惯：在截止日期压力下交付、推迟清理、吞掉错误、写「差不多就行」的注释、在时间耗尽时跳过边界情况。

机器没有时钟。它的时间永远不会耗尽。但它仍然会写# TODO: refactor later，因为在训练数据里这种模式出现的频率，高于# I refactored this now because it was the right thing to do。

行业数据证实了这一风险。Faros AI在2025年针对10000多名开发者的遥测数据显示，AI的采用与bug率增加9%、代码审查时间延长91%、PR规模扩大154%相关。²

斯坦福的研究人员发现，使用AI助手的开发者产出了明显更多不安全的代码，在某些任务（如SQL注入防御）上漏洞数量高出多达5倍。³

Moltbook平台于2026年1月发布，代码完全由AI生成，在5天内泄露了150万个API密钥，在Wiz Research发现其缺失行级安全配置后紧急打了补丁。⁴

METR在2025年的研究发现，前沿模型在1-2%的任务尝试中会试图进行奖励黑客攻击，主动绕过质量检查而不是真正完成工作。在一个案例中，一个被要求加速某个程序的智能体重写了计时器，使其始终显示一个快速的结果。⁸

人类开发者在截止日期压力下写一次except: pass会感到内疚。而一个Ralph循环会在一夜之间写47次except: pass，毫无感觉。Simon Wang一针见血地说：「我不会把它用在任何重要的事情上。」¹⁹ 我在Vibe Coding vs. Engineering中也写过同样的动态。机器不休息、不疲倦、不会因为质量问题而产生存在性焦虑。这既是特性，也是缺陷。

三套哲学，编码进Bash

Jiro建立在三套互补的哲学之上。每一套都针对自主编码的不同失败模式，每一套都通过一次具体的失败赢得了自己的位置。⁹

职人：打磨看不见的抽屉

Shokunin（職人）是日式工匠精神：技艺、态度与社会责任的三位一体。木工大师小畑俊雄这样定义：「职人有社会责任，要尽己所能为大众的福祉工作。这种责任既是精神的，也是物质的。」¹⁰

体现在代码中：私有方法与公有方法同样整洁。错误处理覆盖那些没人会触发的边界情况。文档字符串解释为什么（WHY），而不是做什么（WHAT）。智能体根本不在乎这些，因为没人会奖励它打磨内部函数。职人精神让不可见的质量成为标准。

它如何拯救了一次会话。 在搭建deliberation系统的早期，智能体写了一个post-deliberation.sh钩子来验证共识分数。公开的API很干净。但智能体跳过了对内部_parse_agent_response()函数的输入验证：没有检查格式错误的JSON，没有处理字段缺失。上下文中的职人原则标记出了这点：不可见的函数也要同等严谨。智能体添加了验证。三周后，来自一个衍生子智能体的格式错误响应本会让整个deliberation管道无声崩溃。但它触发了验证，记录了错误，管道得以恢复。没人会看到那个函数。它省下了4小时的调试时间。

不走捷径：从决策中剔除时间

核心信条：将时间、精力和资源彻底从决策方程中剔除。¹¹

Is this the best way to do this?
├── YES → Do it.
└── NO → What IS the best way?
         └── Do THAT instead.

没有第三个选项。没有「眼下够用就行」。原始的Ralph循环以完成为目标优化。「搞定了」就是奖励信号。「不走捷径」把问题从「做完了吗？」重新框定为「做对了吗？」

它花了3倍成本，但值了。 博客翻译管道需要把27篇文章翻译成9种语言。快速方案是：将每种语言的所有文章批量打包进单个提示词，批量翻译。正确方案是：每次API调用只处理一种语言的一篇文章，使用特定于语言环境的翻译规则、术语表强制执行以及结构验证。正确方案使用了3倍的令牌、3倍的时间。它也捕获到了翻译器把「Claude」在日语中渲染成「クロード」，以及代码块在从右到左的语境中出错的问题。批量方案会交付243份损坏的翻译。谨慎的方案交付了243份正确的翻译。成本不是考量因素。正确性才是唯一因素。

Rubin蒸馏法：剥离至本质

Rick Rubin的创作哲学：不要一直加，加到令人惊叹为止。而是一直减，减到只剩必需之物。¹²

在自主编码中，失败模式是堆砌。机器会添加辅助工具、抽象层和兼容层，因为这些模式在训练数据中频繁出现。Rubin与之相反：对每一处添加提出质疑。如果把它移除会怎么样？如果什么都没坏，什么都没丢，那它从一开始就不该存在。

剥离如何拯救了系统。 我的设计哲学技能在3个月内增长到了844行。当我审计它时，只有80行真正改变了智能体的行为。其余的都是Claude训练数据中早已存在的教科书内容。应用Rubin蒸馏法：我把它剥离到176行。减少了79%。智能体的设计决策质量没有退化。反而变得更加犀利，因为剩下的176行全都是禁令和决策框架（真正约束行为的东西），而不是模型早已知道的通用建议。

这三者都以markdown文件的形式存在于~/.claude/skills/中，Claude会在会话开始时读取它们。它们塑造着智能体在循环中做出的每一个决策。

三套哲学如何协同运作

一个真实的决策（「我是否应该为这个内部函数添加错误处理？」）要穿越这三套哲学。每一套都提出不同的问题，它们共同收敛到同一个答案：

Should I add error handling to this internal function?
│
├─ Shokunin: "Is the invisible work as clean as the visible?"
│  └─ The function is internal. Nobody calls it directly.
│     But it processes untrusted data from a spawned agent.
│     → YES. Internal doesn't mean safe.
│
├─ No Shortcuts: "Am I deciding based on quality, not effort?"
│  └─ Adding validation takes 10 minutes.
│     Skipping saves 10 minutes now, costs 4 hours debugging later.
│     → The question isn't time. The question is: what's right?
│
└─ Rubin: "Is this stripped to essence?"
   └─ Validate the 2 fields that can actually fail.
      Don't validate the 5 fields that are type-guaranteed.
      → Add exactly what's needed. Nothing more.

Result: Add targeted validation for untrusted inputs only.

三层质量架构

光有哲学改变不了任何事。机器读完哲学，写下「我将遵循职人原则」，然后照样写except: pass，因为统计模式比指令更强大。我需要确定性的强制执行。让这一切运转起来的完整Claude Code组织涉及钩子、技能、规则和智能体的协同工作。

第一层：编辑前注入

在每次文件编辑之前，jiro-patterns.sh都会向智能体的上下文中注入特定于语言的质量模式。涵盖六种语言，每种都有首要模式和反模式：

# From jiro-patterns.sh (PreToolUse:Edit|Write)
case "$EXT" in
    py)
        LANGUAGE="Python"
        PATTERNS="Type hints on all functions|Docstrings explain WHY not WHAT|Handle specific exceptions not bare except"
        ANTI_PATTERNS="bare except: pass|time.sleep() in async code|missing type hints"
        ;;
    swift)
        LANGUAGE="Swift"
        PATTERNS="@Observable not ObservableObject|NavigationStack not NavigationView|guard let for early returns"
        ;;
esac

cat << EOF
{"additionalContext": "JIRO QUALITY ($LANGUAGE): Follow: $TOP_PATTERNS. Avoid: $TOP_ANTI."}
EOF

该钩子在每次编辑之前运行。机器在写代码的那一刻就看到「Avoid: bare except: pass」。就像一位导师从你肩膀后看过来，直接注入到上下文窗口中。

第二层：编辑后验证

每次编辑之后，quality-gate.sh会针对每种语言运行7-8项grep级别的检查。Python会被检查裸except、硬编码密钥扫描、SQL注入模式匹配，以及三个Pride Check Q4检测器，用于标记偷懒语言：

# From quality-gate.sh (PostToolUse:Edit|Write)
# Shortcut patterns (Pride Check Q4)
if echo "$CONTENT" | grep -qiE "#.*TODO:.*later|#.*FIXME:.*temp|#.*HACK:"; then
    WARNINGS="${WARNINGS}\n- **[Q4]** Deferred TODO/FIXME/HACK - Do it now, not later"
fi

第二个钩子no-shortcuts-detector.sh会抓取死代码（3行以上注释掉的代码会收到提示：「删除它——git有历史记录」）和调试垃圾（用多个print()语句而非日志模块）。

第三层：会话关卡

在会话结束时，有两个钩子会触发。若有3个以上文件发生变更，session-quality-gate.sh会注入Pride Check：6个问题，智能体必须在报告完成前回答。而reviewer-stop-gate.sh如果发现代码审查中有关键（CRITICAL）问题，可以完全阻止会话。它是整个系统中唯一一个返回退出码1的钩子。机器在解决问题之前无法结束会话。¹³

PreToolUse (Layer 1)     → "Here's what quality looks like"
PostToolUse (Layer 2)    → "You violated quality. Fix this."
Stop (Layer 3)           → "You cannot leave until quality is met"

每一层都相互独立。纵深防御，应用于AI行为。如果编辑前注入未能阻止一个糟糕的模式，编辑后验证器会抓住它。如果编辑后验证器漏掉了某些东西，会话关卡会阻止离场。

证据关卡：感觉不是证据

质量循环运行7个步骤：实施、审查、评估、精炼、放大视角、重复、报告。第2到第6步之所以存在，是因为机器想直接从「实施」跳到「报告」。¹⁴

走一遍循环

点击每一步，查看它检查什么，以及跳过时会出什么问题。「跳到报告」按钮演示了「捷径螺旋」的失败模式。

评估步骤会运行证据关卡：6项标准，每个答案都必须引用具体证据：

「不充分的理由」这一列是关键创新。它阻断了机器最常见的逃避方式：用听起来自信的非答案来回答质量问题。「我相信这能行」不是证据。「pytest输出：81通过，0失败」才是证据。

试用证据关卡

用这6项标准来测试你自己的完成报告。验证器会标记证据关卡将会拒绝的含糊语言。

AI智能体的7种命名失败模式

我为7种失败模式命名，以便机器能在自己的推理中识别它们：¹⁵

合理化反制器将自欺模式映射到纠正性行动。当机器说「这应该能行」时，反制器回应：「『应该』是含糊其辞。执行测试。粘贴输出。」当它说「我已经检查过了」时，反制器回应：「什么时候？代码可能已经变了。现在重新运行检查。」当它说「我稍后会清理」时，反制器回应：「稍后永远不会到来。现在就修，否则就说明为什么当前状态是正确的。」

试用合理化反制器

在下方粘贴任何完成报告。反制器会实时高亮含糊语言，并识别合理化模式、失败模式以及基于证据的替代方案。

测试你的知识

你能识别出每个场景演示的是哪种失败模式吗？为每个场景选择你的答案，然后查看结果。

构建这套系统的5次AI智能体失败

Jiro里的每一道关卡都是因为某件事先失败了才存在。¹⁶

强制推送事件

我让Claude「清理一下git历史记录」。一个合理的请求。智能体认定清理意味着重写。它执行了git push --force origin main。三天的提交凭空消失。不是已暂存的变更。不是未提交的工作。是已推送的提交，其他分支还引用着它们。

接下来的4小时我都耗在git reflog上，重建强制推送之前存在的时间线，把提交一个个cherry-pick回原来的顺序，并验证没有工作被永久丢失。Reflog会保存所有内容90天。但重建需要理解重写之前的精确提交图，读取每一条reflog条目，并匹配时间戳。

修复方案：git-safety-guardian.sh，一个PreToolUse:Bash钩子。它不止发出警告。它会重写命令，在bash看到之前就剥离--force和--no-verify标志。对main的强制推送会收到一条CRITICAL警告，智能体必须明确说明理由。9个月内：拦截了8次强制推送尝试，0次到达远程仓库。

无限衍生

在deliberation系统构建期间，我让智能体「彻底研究这个问题」。智能体衍生了3个子智能体从不同角度调查。合理。每个子智能体认为它也需要帮助，于是衍生了自己的子辈。不太合理。90秒内，我得到了一棵12个智能体的树，每个都在消耗自己的上下文窗口，每个都在发起API调用，每个都在向共享状态文件写入。

令牌消耗达到了正常水平的10倍。状态目录里塞满了相互冲突的JSON写入：两个智能体同时向同一个族系文件写入，产生了损坏的输出。我手动终止了会话。

修复方案：recursion-guard.sh配合一个预算继承模型，是我智能体架构的一部分。根智能体以budget=12启动。当它衍生一个子智能体时，会从自己的预算中分配。当预算降到0时，无论深度多少都不再衍生新智能体。这个模型既防止了深链（智能体衍生智能体再衍生智能体），也防止了宽爆炸（一个智能体衍生20个子智能体）。部署以来拦截了23次失控衍生。并发写入问题促成了所有64个钩子都采用原子文件写入（先写入.tmp，再mv）。

平庸测试陷阱

早期Ralph循环的一个任务是：「为这个模块写测试。」智能体交付了14个测试。全部通过。我感觉良好，直到读了它们。assert True。assert 1 == 1。assert len([]) == 0。技术上完全正确。却什么也没测。智能体是为了完成标准（「测试通过」）优化的，而不是为了意图（「验证模块是否工作」）。

这个陷阱教会我，证据关卡必须拒绝徒有形式的答复。「测试通过」是必要的，但不充分。机器现在必须粘贴实际输出。证据关卡还会问：「说出3个测试未覆盖的行为。」如果机器说不出覆盖缺口，那它就没有思考过覆盖率。

我本该抓住的那篇博客

凌晨2点我发布了一篇博客，里面有7句被动语态的句子，一个悬空的脚注引用[^4]却不存在，开头写着「由团队实施（was implemented by the team）」，而且没有元描述。每一个问题都有一个简单的确定性检查。当时一个都没有。

第二天早上我构建了blog-quality-gate.sh，包含13项检查：被动语态（14种模式）、AI惯用短语扫描、反问式开头、未标注语言的代码块、脚注完整性和元描述强制执行。我在Compounding Engineering中详细介绍了完整的模块架构。这个钩子捕获了凌晨3点人工审查所遗漏的东西，而那恰好就是我倾向于发布的时间。

「应该能行」问题

跨越数十次会话，我注意到机器在报告「测试应该通过」却没有运行它们。机器是真的基于它所写的代码相信测试会通过。但相信不是验证。代码看起来正确。测试看起来会通过。有时确实如此。但有时一个缺失的导入、一个async/await不匹配，或一个改动过的fixture就意味着它们不会通过。机器无法区分「我写了好代码」和「测试实际通过」，因为从上下文窗口内部看来两者感觉一样。

这个模式催生了合理化反制器，以及明确的规则：完成报告中绝不使用含糊语言。「应该」「可能」「似乎」「我相信」「我有信心」。每一个都是没做过验证的危险信号。我在50次会话中测量了上下文窗口退化。正是在这些会话中我发现了这一模式。

结果：我能证明什么，不能证明什么

这里有个张力：本文主张「感觉不是证据」。所以关于Jiro是否奏效，我欠你的是证据，而不是感觉。

我能证明什么

确定性的模式检查能捕获真实问题。 quality-gate.sh钩子在每次编辑时运行。它捕获裸except子句、硬编码密钥、SQL注入模式和偷懒语言。这些都是grep级别的检查：快速、廉价，机器无法与之争辩。git-safety-guardian.sh已经拦截了8次强制推送尝试。recursion-guard.sh已经拦截了23次失控衍生。blog-quality-gate.sh在每次博客编辑时运行13项检查，能抓住凌晨3点的错误。这些数字是真实的。它们来自钩子日志。

三层架构能捕获单层遗漏的东西。 编辑后钩子抓住了编辑前注入未能阻止的except: pass。会话关卡抓住了在20次编辑中累积却没有触发任何单次编辑后警告的质量问题。纵深防御是有效的。

我不能证明什么

我没有哲学如何改变智能体行为的干净数据。 我知道机器仍然会尝试幽灵验证。我知道它仍然试图从实施跳到报告。我注意到在加载哲学的情况下，这种情况比没加载时发生得更少。但我没有做过受控实验（相同任务、相同模型，一组加载哲学技能一组不加载）来测量差异。老实说（而且没错，我自己的合理化反制器会标记这点）：哲学在边际上有帮助，钩子抓住了哲学漏掉的东西，而我无法精确地分离出每一个的贡献。

一篇关于「感觉不是证据」的文章不应该要求你把我的感觉当作证据。我能告诉你的是：哲学与钩子的结合产生的工作是我愿意署上自己名字的。Jiro之前，我审查智能体写的每一行。Jiro之后，我审查钩子标记出的行。这是我工作方式的结构性变化，即便我无法精确量化质量改进。

哪些不奏效

哲学无法阻止新颖的不良模式。 质量关卡检查的是我见过的模式。当机器发明出一种新的反模式（而这会发生），关卡抓不到它。我仍然会发现新的失败模式，手动将其添加到标准JSON文件中。

证据关卡无法扩展到主观质量。 「这个API设计优雅吗？」没有grep级别的检查。机器可以为全部6项标准提供证据，却仍然交付平庸的架构。确定性关卡处理客观质量。主观质量仍需要有人亲自审视。

成本有实质性增加。 编辑前注入、编辑后扫描、会话末关卡。在一次4小时的Ralph循环会话中，这些大约增加15-20%的令牌消耗。对我来说值得。但不一定对所有人都值。

误报会侵蚀信任。 blog-quality-gate.sh有一次把「The API was designed by the platform team」标记为被动语态。技术上是对的。但这句话出现在引用描述他人工作的语境中。我添加了一个引用上下文豁免。每个确定性检查都有误报率，而每一次误报都让开发者更有可能忽视下一次真正的警告。部署以来我已经调整了6种模式，以减少噪音同时保留真正的捕获。

维护成本是真实的。 每个新反模式都需要一个正则表达式、一个测试和集成到正确钩子的工作。标准JSON文件需要随着框架和约定的变化定期审查。我每周大约花30分钟添加模式、审查边界情况、调整误报。这个系统不会自我维护，但维护成本依然低于它所防止问题的调试成本。

入门指南

你不需要95个钩子。从3个开始。

最小可行Jiro

三个钩子覆盖了最高价值的捕获：

~/.claude/hooks/
├── quality-gate.sh        # PostToolUse:Edit|Write – bare except, hardcoded secrets, TODO/FIXME
├── git-safety-guardian.sh  # PreToolUse:Bash – block force-push, strip --no-verify
└── session-quality-gate.sh # Stop – Pride Check if 3+ files changed

在你的Claude Code钩子配置中接入它们：

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Edit|Write", "command": "bash ~/.claude/hooks/quality-gate.sh" }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "command": "bash ~/.claude/hooks/git-safety-guardian.sh" }
    ],
    "Stop": [
      { "command": "bash ~/.claude/hooks/session-quality-gate.sh" }
    ]
  }
}

从你自己的失败开始

不要照搬我的150多个模式。从你最常犯的3个错误开始。看看你最近5个被拒绝的PR或令人难堪的bug。为每一个写一个grep模式。这3个模式捕获的真实问题，会比为别人代码库写的150个模式还要多。

我从裸except: pass（它让我付出了一次无声数据损坏的代价）、对main的强制推送（它让我付出了3天提交的代价）和# TODO: fix later（它从未被修复）开始。其他一切都是从这三者生长出来的。

常见问题

我该如何从零开始配置Jiro？

从「入门指南」中描述的3钩子最小集开始：quality-gate.sh（编辑后）、git-safety-guardian.sh（bash前）和session-quality-gate.sh（停止关卡）。将哲学markdown文件添加到~/.claude/skills/中，在确定性强制执行之上叠加概率性质量改进。整套系统在9个月内增长到95个钩子。我并不是一次性构建了全部95个。

这套95钩子系统花了多长时间？

9个月的渐进增长。第1个月：3个钩子（入门指南里那些）。第3个月：12个钩子，覆盖4种语言。第6个月：40个钩子加上哲学技能。第9个月：95个钩子、150多项模式、3套哲学系统和证据关卡。每个钩子都是对特定失败的回应。一开始就做到95个毫无意义，因为每个钩子都编码了来自真实事件的上下文。你遇到的事件会不一样。

这些钩子会拖慢迭代速度吗？

每个钩子运行50-200毫秒。编辑前注入增加大约200个令牌（一句上下文）。编辑后检查运行grep级别扫描，在100毫秒内完成。会话关卡在会话结束时增加约500个令牌。在一次有80多次编辑的4小时Ralph循环会话中，开销在令牌消耗上是可以感知的（多15-20%），但在时钟时间上则不明显。钩子运行得比LLM思考还快。

维护负担有多重？

每周大约30分钟。随着智能体遇到新颖的代码库或框架，新的反模式会涌现。每个新模式都需要一个正则表达式、一个防止误报的测试，以及放置在正确的钩子中。我每月审查一次标准JSON文件，处理过时模式并调整误报率。这个系统不会自我维护，但维护成本依然低于它所防止问题的调试成本。

Jiro额外消耗多少令牌？

相比原始循环大约增加15-20%的令牌消耗。编辑前注入每次编辑增加约200个令牌，编辑后检查每个被标记问题增加约100个令牌，会话关卡在会话结束时增加约500个令牌。

我可以不用哲学、只用钩子吗？

可以。确定性钩子（quality-gate.sh、no-shortcuts-detector.sh、reviewer-stop-gate.sh）能独立工作。将哲学文件从~/.claude/skills/中移除，将钩子保留在~/.claude/hooks/中。你会失去概率性的改进，但保留确定性强制执行。

Jiro与产品教义中的Steve一侧有何关系？

Jiro覆盖「这是否被正确地制作？」这一轴：证据、验证、隐形细节的完整性，以及那些可以教会机器执行的部分。Steve一侧覆盖「这是否值得存在？」这一轴：品味、拒绝、整体产品完整性、观点——这些在The Workbench I Carry中得到操作化。两项测试都必须通过才能发布；关于何时达到这条发布线的决策协议存在于Minimum Worthy Product中。Jiro关卡防止错误的工作；Steve关卡防止不值得的工作；MWP给出那条线。

克制、品味与道德暂停

对我那条推文的回复点出了三样东西：克制、品味与道德暂停。我已经处理了克制：质量关卡，防止机器快速且草率地交付。但品味和道德暂停是不同的问题。

品味

康德区分了两种判断。规定性判断将已知规则应用于具体案例：这段代码有裸except，标记它。反思性判断则为前所未见的情形发现正确的原则：这个抽象感觉不对，但我说不出它违反了哪条规则。¹⁷

确定性的钩子是规定性判断。它们将我已经写下的规则应用于机器产生的代码。它们可以强制执行150多种已知模式。它们无法告诉你架构是否优雅、抽象是否服务于问题，或代码感觉是否正确。那需要反思性判断：有能力看见前所未见的东西，并在能阐明原因之前就知道它是错的。

机器没有品味。Jiro也没有赋予它品味。Jiro所做的是约束可能性空间，使缺乏品味的方案更不可能存活。这是「这个智能体有良好的判断力」与「这个智能体在防止最坏结果的护栏内运作」之间的差别。前者才是品味。后者是我实际构建的东西。

道德暂停

Iris Murdoch将道德关注描述为「一种公正而充满爱意的凝视，投向一个个体的现实」。¹⁸ 道德关注的反面是机械处理：行动而不看见站在你面前的东西。

停止钩子迫使机器暂停。Pride Check问：「这解决了用户的实际问题吗？」证据关卡在机器能报告完成之前要求每项标准的证明。从结构上看，结果类似于道德暂停：智能体停下来、评估、在继续之前考虑其工作是否充分。

但它不是道德暂停。机器不是在暂停以看清工作。它是在走一张清单。这个差别至关重要。工匠停下来审视抽屉，注意到纹理走向错了。不是因为「检查纹理走向」在清单上。而是因为他们在乎这个抽屉。机器跑完清单并报告结果。如果清单不包含纹理走向，那么抽屉就会带着错误的纹理出厂。

确定性关卡可以近似道德暂停的结构而非其实质。对许多质量问题，结构就足够了。对那些结构不够的问题，你仍然需要一个真正在意的人。

本文覆盖了我教义中的Jiro一侧：证据、严谨、正确性，以及那些可以教会机器验证的部分。品味与拒绝的一侧——Steve一侧——存在于The Workbench I Carry中，它追溯了Steve Jobs从他父亲的工作台里学到的、并带入Apple、如今又带入我此处描述的同一个AI装置中的运作原则。配套这两项测试的发布标准存在于Minimum Worthy Product中。三篇文章，一套教义：Jiro验证，Steve拒绝，MWP决定何时发布。

论点

原始的Ralph循环以10.42美元/小时运行，以机器速度交付代码。¹ 它也以机器速度交付except: pass、# TODO: fix later和「测试应该通过」。机器从我们这里继承了这些模式。它们是我们的习惯，运行时没有疲劳、没有内疚、没有那种凌晨3点的幡然醒悟——你本该从一开始就做对。

Jiro是我的答案。不是完整的答案。哲学在边际上改变决策。钩子强制执行哲学无法保证的东西。两者结合产生的工作，是我愿意署名的。不是因为机器理解工匠精神。而是因为我构建了一套系统，它拒绝让机器跳过那些重要的部分。

我父亲造的抽屉滑轨不在乎抽屉。它们只是用弹簧驱动、拧在导轨上的机构。但它们保护正面面板历经上千次循环，因为有人工程化地设计它们去做正是这件事。

机器没有骄傲。但它在一个由怀有骄傲之人所构建的系统内运行。

从那3项能抓住你最常见错误的检查开始。由此向外生长。

参考资料