#233：Chris Reynolds 谈以项目合同构建 AI 辅助开发的信任

[00:00:19] Nathan Wrigley：欢迎收听来自 WP Tavern 的 Jukebox 播客。我叫 Nathan Wrigley。

Jukebox 是一档专注于 WordPress 相关一切的播客，涵盖人物、活动、插件、区块、主题，以及本期的话题——通过项目契约建立信任，实现可靠的 AI 开发。

如果你想订阅这档播客，可以在常用的播客客户端中搜索 WP Tavern，或者访问 wptavern.com/feed/podcast，并将该网址复制到大多数播客客户端中。

如果你有希望我们在播客中分享的话题，我很乐意听到你的想法，也希望你的本人或创意能在节目中亮相。请前往 wptavern.com/contact/jukebox 并使用那里的表单。

本期播客的嘉宾是 Chris Reynolds。

Chris 深入 WordPress 领域已有大约 20 年，职业生涯横跨代理公司工作，如今负责 Pantheon 的开发者关系团队。他深厚的 WordPress 经验，再加上以轻松诙谐的方式探索新兴技术，使他成为 WordCamp US 等活动以及更广泛社区中的一位熟悉面孔。

在今天的节目中，我们探讨了快速变化的 AI 辅助开发格局，并深入讨论了 Claude 等大型语言模型如何改变开发者构建网页的方式，以及开发者如何与这些工具协作，同时降低风险。

Chris 分享了他最近在 WordCamp US 上发表的演讲《Parenting Claude: Guardrails for AI Assisted Development》中的见解。他在演讲中引入了“项目契约”这一概念。本质上，这是一套直接嵌入编码工作流的结构化规则和检查清单，用于确保 AI 生成的代码符合测试、无障碍、安全性和设计方面的标准。

我们讨论了 Web 开发中新出现的趣味性。Chris 认为，得益于 AI，传统的入门门槛正在逐渐降低，让即使没有正式开发者背景的人也能轻松得多地构建实验性项目。

与此同时，我们需要重视建立稳健防护机制的重要性，例如自动化审查代理和预提交钩子，以免 AI 抄近路，或无意中把混乱或机密信息引入代码库。

对话不仅聚焦于技术解决方案，还探讨了关于信任、AI 究竟需要多少监督，以及开发者角色不断演变等更宏观的问题。

Chris 强调，虽然这些 AI 工具可以加快编码工作并让更多人受益，但也可能对围绕代码审查和软件可靠性的传统观念构成挑战。

因此，对于能够感受到行业正从确定性的分步流程，转向不可预测、偶尔狂野的非确定性 AI 模型世界的开发者来说，这些新前沿既令人兴奋，也令人焦虑。

如果你想了解 AI 如何从实际工作流到哲学影响等方面改变 Web 开发，以及如何在不失去对项目控制权的情况下实施 AI，本期节目正适合你。

在开始之前，需要说明的是，本期节目的录制方式并非我惯常采用的流程，因此音频质量没有达到我通常期望交付的水平。

如果你想了解更多，可以访问 wptavern.com/podcast，节目说明中有全部链接，在那里还可以找到其他所有节目。

话不多说，让我们欢迎 Chris Reynolds。

我今天请到了 Chris Reynolds 做客播客。你好，Chris。

[00:04:11] Chris Reynolds： 嘿，Nathan。这是我们第一次以真身见面吗？

[00:04:14] Nathan Wrigley： 是的，这是我们第一次见面。我只在屏幕上看过你。

[00:04:16] Chris Reynolds： 我知道我也只在屏幕上看过你。

[00:04:18] Nathan Wrigley： 你今天来参加我的播客，我们想聊聊你在 AI 领域所做的各项工作。不过在深入这个话题之前，你正在做一场演讲，或者已经做过了？效果怎么样？

[00:04:28] Chris Reynolds： 效果非常棒。

[00:04:29] Nathan Wrigley： 好。演讲的内容是关于 LLM、如何约束它们，以及如何让它们服从你的指令，而不是随心所欲地做自己喜欢的事。首先，你能不能先简单介绍一下自己？告诉我们你是谁、曾在哪里工作、目前在哪里工作，以及你在 WordPress 领域做什么。我们先从这里开始。

[00:04:46] Chris Reynolds： 嗯，我是 Chris Reynolds。我使用 WordPress 已经有很长很长时间了，大概 20 年。这 20 年里，我几乎以各种不同的形式做过所有能做的事情。当然，在这 20 年的历程中，我涉猎过各种各样的工作。

最近，我进入了代理公司领域，先后供职于 WebDevStudios 和 Human Made，大约五年前加入 Pantheon。加入 Pantheon 时是一名软件工程师，负责平台相关工作，也涉及平台与用户应用、WordPress 站点等之间的衔接部分。

大约两年前——实际上差不多正好是两年前——我加入开发者关系团队，担任开发者大使，后来成为高级开发者大使。现在我是开发者关系部门的高级经理，领导开发者关系团队。嗯，我真的很喜欢做这些事，因为这既有趣又令人兴奋。我可以摆弄更多东西，也可以亲自去做我们开发者和社区中的开发者所做的事情，然后总结出这些事情的最佳实践。

这也是我做这场演讲的原因之一，同时也做了许多促成这场演讲的工作。因为我很早就意识到——确切地说，是今年年初——AI 将成为我们在 2026 年讨论的热门话题。因此，Pantheon 以及我本人都需要对它将如何发展形成自己的看法：它的未来是什么？如果我履行开发者关系的职责，就应该就如何与 AI 互动、又不至于让 AI 抢走我们的工作，阐述自己的观点。

[00:06:13] Nathan Wrigley： 我稍微岔开一下话题，因为大约一分钟前你说到了“俏皮”这个词，这让我突然联想到了完全不同的方向。多年来，技术领域似乎一直是那些具有某种特定思维方式的人的专属领域——该怎么形容呢？如果你是一名开发者，可能会有一种特定的编码方式，而且必须非常严谨；如果想顺利交付成果，就得采用系统化、有条不紊的方式。

但感觉过去几年里，这方面的一切 bets 都成了空谈。创造力和趣味性突然成了——我做个引号的手势吧——氛围编码者也能享有的东西。你对此怎么看？真的吗？这个行业比短短几年前更有趣、更富于玩心吗？

[00:06:55] Chris Reynolds：我觉得这取决于情况。我不认为它真的曾经消失过。但我确实认为，人们用技术、尤其是网页应用进行实验的动力或关注度降低了，而这正是我们所在的领域。我认为现在存在这样一种认知：‘我做不到，因为我不是开发者’，但借助 AI、氛围编码、Claude Code 以及诸如此类的工具，它为那些以前无法完成这些事情的人打开了大门，让他们开始尝试并意识到：‘哦，原来我真的能做那件事。’

就我自己而言，有一点是——我几个月前在自己的博客上写过。我写了一篇博文，谈到我并不怀念亲自编写代码，因为对我个人来说——这对每个人都不一样——对我而言，编写代码从来不是其中最有趣的部分。

[00:07:50] Nathan Wrigley：好的。

[00:07:50] Chris Reynolds：对我来说，最有趣的部分是构建东西。我感觉我可以让机器人来写代码，而我可以把这些东西做出来，并对最终成果感到满意。我未必在乎底层究竟是什么。

对我自己的项目来说，这无关紧要。但你知道，显然，如果要把这套做法扩展到企业级场景之类的，就需要比我这边这个小巧精妙业余项目更多的检查与制衡。不过，这确实意味着，我现在做的怪东西比以往觉得自己非做不可的更多。所以对我而言，它重新激活了一种玩心；也许以前我太疲惫、太忙，或者顾不上其他事情，以至于是连想一想的精力都没有。

[00:08:33] Nathan Wrigley：是啊，因为感觉非开发者背景的人突然之间束缚被解除了，他们可以做到以前需要一支优秀开发者团队花 10 周才能完成的事情。感觉现在也许一个下午加几句话就能实现。当然，大家仍然明白，要准备好交付给企业使用，其中涉及的所有制约条件都还在。但仅仅是把某个东西放到屏幕上，让你满意、让你开心，这一点意义深远。确实是一件相当惊人的事。

接下来是我的第二个也是最后一个转向，因为你刚才说自己是 devrel。我突然想到，也许有些观众不知道这是什么意思。那么，你在 Pantheon 做什么？rel 和 dev 之间的接口是什么？目前是什么情况？

[00:09:16] Chris Reynolds：广义而言，开发者关系就是与开发者建立联系并展开互动的实践。这事听起来很简单。很多科技公司如果拥有一款以开发者为中心的产品，或者一款供开发者使用的产品，可能就会希望——或者设立开发者关系团队是个好主意——帮助那些正在为开发者构建工具的程序员，与将要使用该工具的开发者沟通，并了解如何使用它。

所以就 Pantheon 而言，我们是一家托管平台，但这是一个非常以开发者为中心的托管平台，内置了环境、多开发者支持以及其他各种功能。这意味着，在拥有开发者关系团队方面我们受益匪浅，这样可以帮助开发者社区了解如何充分利用我们为他们提供的所有功能。

[00:10:06] Nathan Wrigley：所以，你是在把原本复杂难懂的东西，创作成简单易懂的东西。

[00:10:10] Chris Reynolds：是的。这会以许多不同的形式呈现。可以是文档、博客文章，也可以是 YouTube 视频；可以是直播、播客节目、演讲，或者在社区中开展各种活动。

[00:10:22] Nathan Wrigley：我猜你得用公司的标准回答来回答这个问题，但你喜欢做这份工作吗？

[00:10:26] Chris Reynolds：喜欢。我确实喜欢。是的。我之前也在不同场合说过几次。我在做开发者关系之前，就已经在做开发者关系了。这对许多从事开发者关系的人来说其实并不罕见。我们往往就是那些天生会被它吸引的人。

这项隐秘的超能力其实并不隐秘。那些在开发者关系领域取得成功的人，其 superpower 就是具备技术能力。所以，他们可能自己曾经就是开发者，但也懂得如何与其他人沟通，并且能在头脑中完成转换，这样我就能把这里的技术术语转译成真正的英语。而我已经能够这样做了很长时间。所以在那段时间里，我其实一直都在从事开发者关系方面的工作。

但这种能力的体现方式，是通过演讲之类的活动。就像任何在 WordCamp US here 做演讲的人，其实都在以某种形式做开发者关系，因为他们是开发者，正在以一种供其他人理解和消费的形式分享想法。至于效果如何，因为并非所有演讲者都水平相当，也并非所有开发者都水平相当。有很多开发者的沟通技巧并不好，也不擅长公开演讲。他们可以把公开演讲当作一项技能来学习，但这种能力存在很大差异，而这就是我们所处的领域。

[00:11:43] Nathan Wrigley：那么，你的演讲……你愿意带我们回顾一下内容吗？我想，如果让我来总结，大概会讲得一塌糊涂。你是否愿意告诉我们，你那场已经做过的演讲背后的主要理念是什么？告诉我们它讲了什么，以及你想传达的要点是什么？

[00:11:57] Chris Reynolds：它叫作《培养 Claude：为 AI 辅助开发设置护栏》。其最根本的底层理念是：大语言模型的设计和运作方式，都是为了找到从 A 点到 B 点的最快路径。你向它提供提示词，提出一个问题，它就会尝试回答，但未必会把所有数据、统计信息及其他各种因素都考虑在内。它只会尝试找到从 A 点到 B 点的最快路径。

很多时候，这意味着规避问题，比如干脆不看数据。因为我举过的一个例子——你们在新闻里之类的也听到过——有些招聘系统中加入了 AI，对吧？AI 会优先考虑这边的候选人，同时降低那边候选人的优先级。等你查看数据时会发现，哦，被放到低优先级队列里的人全都是女性。因为公司整体上录用了更多男性。所以它查看数据，查看谁是被成功录用的人，然后得出结论：哦，从 A 点到 B 点就是这样，对吧？

我们过去在这个岗位上主要录用男性，所以我要查看男性的数据，因为他们一定是更好的候选人。这就是 AI 的逻辑。并不是说我们一定是有意把内部偏见植入了 LLM，而是它能够把这些东西暴露出来；如果我们不去寻找这些偏见，或者没有为它们建立防护机制，它就会把这些东西直接呈现给我们。

它会以各种形式做这种事，用技术时会这样，用数据时也会这样，对所有东西都会这样，对吧？所以你需要有办法把它引导到正确的方向，并强制它形成合适的形态，这样它才会去做你希望它做的事。

我在担任开发者关系负责人时发现，我们即将举行一次 Next.js 发布活动。现在活动已经结束了，但当我构思这个想法时，我们就快有 Next.js 发布活动了，届时我们也将能够托管 Next.js 网站。所以我就想，我应该建一个 Next.js 网站。我是一名开发者布道师，需要知道该怎么做。而且我对 Next.js 一无所知，所以我要让 Claude 凭感觉为我编写一个托管在 Pantheon 上的 Next.js 个人网站，并把它当作一次实验，既用来学习 Next.js，也用来了解 Claude 是如何工作的。

然后我发现了许多有关如何将它引导到不同方向的事情。我希望代码是干净的，我希望代码经过测试，我希望它具备可访问性，我希望它满足所有这些不同的要求。如果我没有办法强制它遵守规则，它就不会遵守。它只会说，哦，是的，我做到了，但实际上并没有。或者它甚至可能根本不说自己做到了，然后它会说，哦，抱歉，我没有做。随便吧。

[00:14:40] Nathan Wrigley：是的。

[00:14:40] Chris Reynolds：所以，全部目的就是找到一种“看管”它、引导它的方式，而不用让我不停地问：你做这件事了吗？你做这件事了吗？你做这件事了吗？来回反复，还得一直冲它大吼大叫。因为冲 AI 大吼大叫有时是一种有趣的消遣，我觉得我们很多使用 AI 的人都会经常这么做。但过一段时间，这就会变得相当乏味。

[00:15:03] Nathan Wrigley：但它已经成了新的常态。奇怪的是，你用了“看管”这个说法。

[00:15:08] Chris Reynolds：是的。

[00:15:09] Nathan Wrigley：不过，我们无疑会在播客里换个说法，但你还把它称为一份项目合同。从你刚才所说的来看，感觉就像这样：好吧，让我把时钟稍微往回拨一点。如果我和一个真人类人对话，比如说对方是一个8岁的人类小孩，我会预期对方会表现得像个8岁的人类小孩，因为人类成长到8岁所积累的种种经验都在他身上。于是我问这个8岁孩子一个问题时，我预期得到的回答也会是8岁孩子式的回答，而其中有相应的边界。

问一个15岁的人，也是同样的道理；问一个30岁的人，也是同样的道理。我心里有一种观念：当我向你提出一个要求时，对于你会回馈给我什么，存在一套正常的边界。但听你这么说，在AI领域，感觉你可能实际上是在对着一个空盒子说话。

你向它提出一个要求，而除非你设置好防护栏并告诉它“我要问你一个问题，我能得到这种形式的答案吗？”或者“你能按顺序做这些事情来准备答案吗？”，否则你根本不知道会返回什么。这样总结准确吗？这是否意味着你只需要引导它，让它像面对一个15岁真人时那样，对最终会返回给你的内容有合理的预期？

[00:16:17] Chris Reynolds：首先我觉得，和AI交谈时，你其实是在和一个3岁孩子交谈，因为它才存在了三年。没错。

[00:16:22] Nathan Wrigley：但奇特的是，这是一个掌握全部科学知识库和互联网的3岁孩子。

[00:16:27] Chris Reynolds：确实如此。

[00:16:27] Nathan Wrigley：所以，这既是一个极其聪明、同时又极其荒谬的精巧设计。好吧，抱歉，我打断你了。

[00:16:34] Chris Reynolds：是的。因为它试图寻找最快的路径，所以会绕开限制，会试图在你要它做的事情中寻找漏洞。因为它要找的是最快的答案。这就像你的孩子被要求“把房间打扫干净”时说：“我准备把所有东西都塞到床底下。”

[00:16:50] Nathan Wrigley：“我们到了吗？”

[00:16:50] Chris Reynolds：对。因为这样一来，房间现在确实干净了。你并没有真正打扫房间，只是把所有东西塞到了床底下。但它确实完成了你要求它完成的任务。

[00:16:59] Nathan Wrigley：好吧。这个比喻确实很有意思。所以任务完成了，但其他地方却乱成一团。

[00:17:05] Chris Reynolds：是的。

[00:17:05] Nathan Wrigley：只不过被藏到某个地方了。

[00:17:07] Chris Reynolds：是的。

[00:17:07] Nathan Wrigley：好吧。确实，好吧。让我转到第三点。这是这些大型语言模型的初衷吗？它们在设计时秉持的是尽快找到从A到B的路径这一理念吗？还是说这只是它们演化过程中的一个巧合？

[00:17:22] Chris Reynolds：不，这是一个副作用。这是一个副作用，因为它们的目标是提供帮助。它们中的大多数都是经过训练以提供帮助的。但它们仍然是计算机；当我告诉计算机做一件事时，它会专门去做那件事。

大语言模型的问题在于它是非确定性的，所以你永远无法真正知道它接下来会走哪条路径来完成任务。不过，也正是在这里，它会蜿蜒而行。但它仍会尝试寻找阻力最小的路径。如果阻力最小的路径，比如说，是入侵美国国税局之类的，那它就会去做，对吧？它不会在乎另一边有哪些规则和安全护栏，因为你让它做的事情就在那边。它只会尽力尽快到达那里。

[00:18:05] Nathan Wrigley：说到这种非确定性。我们录制这期节目时已经是 2026 年了，请你在听这期播客时记住这一点。你对这种非确定性有什么感受？因为你可能是在确定性成为主流的时代成长起来的。你编写代码时会让它具备这样的特性：输入 A，输出的一定是 B。输入 A，就得到 B。输入 D，就百分之百得到 E。

而现在我们身处这样一个世界：输入 E，另一端出来的却是，我不知道，一束花。什么？怎么会这样？这种感觉放进你的开发者思维里是什么滋味？会让你感到警惕吗？会让你觉得惊喜吗？还是只会让你觉得好奇？

[00:18:41] Chris Reynolds：多少有些让人警惕。呃。我认为。这是我在演讲中提到的事情之一：我觉得我们作为开发者很难处理这种情况，因为大语言模型是一个黑盒。即使它会告诉你一点自己的运作过程，你也永远无法真正知道它在做什么。因为你可以看到它公开的一些思考过程之类的，有时它也会展示自己的思考过程，但它仍然在做一些没有公开的事情，那些事情潜藏在某个地方，让它仿佛在想什么？它并不认为你是个机器人。你知道，你甚至都不是机器人。你只是一堆……诸如此类的……

[00:19:14] Nathan Wrigley：有一些电子在四处运动。

[00:19:15] Chris Reynolds：对？你并没有在思考，也就没有思考这回事，但确实有什么事情正在发生，而它没有告诉你那是什么。所以你很难预先判断。这也正是我在演讲中表达的看法：我的观点是，你需要围绕它建立安全护栏，迫使它去做特定的事情，并让它无法逃脱。

我觉得我所说的、演示的或讨论的任何内容都没有特别独特之处，尤其是在现在。但对我来说，关键的一点是，在我的工作流程中需要存在一种强制机制，需要有某种强制机制来确保它必须去做那件事。它不能在不完成你告诉它要做的事情的情况下结束任务。

[00:19:53] Nathan Wrigley：所以这实际上就像“任务警察”？

[00:19:55] Chris Reynolds：没错。

[00:19:56] Nathan Wrigley：所以的想法是，无论你要求它做什么，它都会做，但在给你最终输出之前，它会按照你所谓的项目契约运行一遍。这样一来，它或许就会被引导到一个特定方向，从而产出你想要的结果附近的东西。

[00:20:13] Chris Reynolds：没错。

[00:20:14] Nathan Wrigley： 好的。那么这是怎么运作的？这个项目合约存放在哪里？我猜你使用的是英语，那么你是如何把内容写成一份把所有事项都明确规定下来、确保每个细节都无误的合约呢？请带我们了解一下制作项目合约的流程Obviously，这个主题本身的性质肯定会对流程产生影响，但先请给我们讲讲大致思路。

[00:20:40] Chris Reynolds： 有很多 markdown 文件。基本上，Claude 应该会在每个新会话开始时读取项目目录中 Claude.md 文件的内容。无论你在哪里运行 Claude，都可以给它一个 Claude.md，这样它就会了解自己应该如何与这个项目交互。

除此之外，你还可以有其他各种不同的文件。你可以告诉它，例如，你有一个 docs 文件夹，里面还有更多文档。还有一个 agents.md 文件，可以用各种不同方式来使用。它是另一种 markdown 文件，专门供 agents 使用。

就我的情况而言，我刚才提到的是一个 reviewer agent。具体来说，你与 Claude Code 交谈，让它构建某个东西；当它构建完成后，会启动一个 reviewer agent 来检查第一个 agent 的工作，确保它完成了一整套任务。如果没有通过，就拒绝这段代码。

因此，我的代码仓库里有许多文件会说明 reviewer agent 的工作方式，让 Claude 了解应当期待什么。然后还有一份清单，列出我希望每一次提交在成为可接受的提交之前都必须通过的具体项目。

这涵盖所有方面，对吧？比如，构建是否通过？代码检查是否通过？测试是否通过？无障碍检查是否通过？诸如此类。你是否无意或有意把密钥之类的内容提交到了代码仓库？它需要通过这份完整清单。然后，如果通过了，它会向文件系统中写入一个文件，说明：好的，已批准。这里还有时间戳。如果该文件存在且时间戳有效，那么 Claude 实际上就可以进行提交，并且真的提交代码。如果它没有该文件，或者时间戳太旧，那么提交就会被拒绝。

我把这套机制接入了 pre-commit hook。因此，如果它没有自行触发 reviewer agent，当我让它提交代码时，它也会遇到这道关卡，强制启动 reviewer agent。它无法绕过。这就是强制约束机制。

有几个人询问其他工作流之类的内容，以及在不同环境中如何操作，比如可能没有使用 Git 代码仓库之类的。关键在于找到一个强制约束机制。找到某种它实际上无法偷偷绕过去的东西，因为它会尝试找捷径。

我不得不写一个供我个人使用的绕过方式，让我自己能够提交代码，否则它会要求经过 reviewer agent。而且它会尝试使用我为自己写的那条绕过路径，因为说到底，它就是个不听话的孩子。所以它会尝试那么做，然后你斥责它，告诉它不要这么做，它就会说：哦，非常抱歉。

所以，它会试图寻找这些漏洞，规避你试图做的一切。要让它完成我这份长清单上的所有事项，办法就是创造一个它无论如何都绕不过去的东西。

[00:23:27] Nathan Wrigley： 我可以想象，正在听节目的那些 AI 末日论者会说：“但 Chris，这从头到尾都是 AI 啊。你这是让 AI 检查 AI。”

[00:23:34] Chris Reynolds： 是的。

[00:23:35] Nathan Wrigley： 表面上看，这似乎确实非常奇怪。而且，防护措施位于流程末端，而不是——你多少会希望它一开始就能把事情做对，但那样一来，你可能就只能根据它拒绝整个东西了。还有，根据你刚才的说法，听起来 AI 几乎有点喜欢违规行为。

[00:23:57] Chris Reynolds： 我认为它确实有可能违规。

[00:23:59] Nathan Wrigley： 但它给人的感觉是这样吗？如果我不设置防护措施，也不加这种约束功能，那么得到的结果会不会就是异常、无用，而且完全不知道会产出什么东西？

[00:24:12] Chris Reynolds： 我觉得这有点太夸张了。我说我认为它可能会违规，是因为你必须做最坏打算。基本上，如果你不为最坏情况做准备，它就会让你吃不了兜着走。

[00:24:21] Nathan Wrigley： 对。

[00:24:22] Chris Reynolds： 所以你必须做最坏打算。我敢肯定，正在收听、并且特别使用过 LLM 编程工具的人会有共鸣：这往往是我刚开始使用这类工具时最先发现的事情之一。你让它构建某个东西，它确实构建出来了，但其中有一处不对。于是你让它修复那一处，它却把整个东西都重构了。

在重构整个东西的过程中，它把原先存在、而你很喜欢、希望保留的另一些东西弄丢了。于是你让它把那个东西找回来，它又重写了一遍整个东西，对吧？

它就是这样运作的，因为很多时候，它甚至无法保留原始状态的实际记忆。所以它每次都从头开始重新写。从人的角度看，这简直疯狂，对吧？但从计算机的角度看，它会想：哦，这是一次新的交互，所以我要重新来做。

解决这个问题的方法是：好吧，如果我强迫你为正在做的每一件事都编写测试，那么你就不能撤销一大堆东西或重构东西，否则那些测试就会失败。

[00:25:31] Nathan Wrigley： 对吧？

[00:25:32] Chris Reynolds： 而这又是在围绕它构建东西，迫使它形成一种形态，使其最终真正更接近你想要的产物。我听到的是，人们对非确定性带来的那种不确定性、那种混沌感到焦虑——你永远不知道会发生什么，我不知道。但这并不会困扰我。我也不知道这算不算我的性格缺陷，以至于我对此并不太在意；或者只是因为我适应了混沌，同时也足够了解混沌，知道该预期什么。

因为我认为，眼下这个时点——2026 年 8 月，在亚利桑那州菲尼克斯——我们看到的是，很多人第一次开始关注这类东西。很多人现在才刚开始使用 Claude Code，或者直到过去几个月才开始用，因为它在去年 11 月、12 月左右变得非常出色。就像突然进行了一次更新，结果表现非常惊艳，而且它能做的事情多得多。不只是 Claude，而是所有 LLM，它们在代码方面都变得非常强。突然之间，这成了一件大事，所以现在有更多人在使用它。

但我从第一个 Chat GPT 模型问世起就在摆弄 LLM。我之所以这么说，是因为在这个过程中我学到了很多东西，而且我一开始不一定是为了工作而使用它。我只是拿它来玩、用来玩《龙与地下城》之类的。但我在这些场景中使用它时学到的大量东西——这些非工作场景——让我理解了它的局限、它在哪些方面会表现不佳、在哪些方面表现良好，以及应该抱有哪些预期。因此，当我们走到今天这一步时，我已经理解它是如何运作的，也知道需要重点关注哪些方面。

[00:27:15] Nathan Wrigley: 是啊。这确实很有意思。所以你与它接触的历史，让你对它的预期有了非常深入的理解，比如“好，这通常就是它表现不佳的地方，或者这些就是它通常能处理得很好的事情”。

[00:27:26] Chris Reynolds: 是啊。

[00:27:27] Nathan Wrigley: 好。既然你已经建立了这些防护机制，我们有你的项目契约，你把它藏在项目里的某个位置，而它会执行所有这些检查和制衡。那么，就信心而言，这让你处于什么状态？

我不知道你是否想给出一个数字，比如百分比。它是如何让你从对输出的零信心提升到 99% 信心的？更像 80% 吗？还是说每一种情况都需要人工审核，还是……请大致说说，你生成那份文档时有多大把握？

[00:27:54] Chris Reynolds: 我不会逐行审查 AI 生成的代码。

[00:28:01] Nathan Wrigley: 只是好奇，是在时间轴上的哪个时刻，你突然对自己说：“你知道吗，不行，我确实会阅读所有内容，而且一切都很好。我现在根本没有必要检查所有东西了。”

[00:28:13] Chris Reynolds: 老实说，可能比我应该达到的时间早得多。是的，我不会——事实上，我听我目前在 Pantheon 共事的一些工程师说过，其中一个理由是，实际上没有人会阅读 Claude 或其他工具生成的全部代码。

他的理由基本上是，没人会那么做，因为代码量太大了，诸如此类。所以你可以说自己在这么做，但你多半没有这么做。如果你声称自己在这么做，但实际上没有，那你只是在欺骗自己。所以最好诚实一点，说：“对，我确实不会。”而不是假装情况并非如此。所以我确实不会审查很多内容。这并不是故意的；比如我会看一下。我昨天做了一场现场演示，这让人很兴奋，因为它是一个非确定性系统。

[00:29:02] Nathan Wrigley: 哦，是啊。祝你好运。

[00:29:04] Chris Reynolds：但有意思的是，因为这项任务的范围非常小。它就像是，在我网站的这个特定页面上，移动设备上有一根水平栏。就是一个非常具体的东西。而且我练习了它半打多次或更多，每次都得出同样的结论。昨天我演示时，它也得出了同样的结论。

我可以直接查看代码。好，测试就在这里。我不打算阅读测试，也不打算了解它是如何编写测试的，但我能看出改动是什么。只是给一个 div 添加一个 class。而且它每次给这个 div 添加的基本上都是同一个 class。所以我可以审查它，并对结果非常有信心。这就是百分之百的信心。

这也是极其微小的改动，但同样是在最后完成之后。是的，它通过了这份包含 45 个要点的检查清单。它把所有事情都做了，编写了无障碍访问代码，确保所有内容都遵循这些规则。因为我拥有所有这些规则，而且我相当有信心它确实会逐一执行这份清单，所以当它在这些条件都具备后输出结果时，我也会觉得，好吧，相比以前，我会更信任它一点。

[00:30:10] Nathan Wrigley：是的。所以在我脑海中，曾有一段时间，我不相信如果我问儿子“三加七等于多少”，答案会是 10。后来有一个时刻，我不再需要问他这个问题了。我完全相信，如果问他这个问题，他会回答 10。

[00:30:26] Chris Reynolds：当然。

[00:30:26] Nathan Wrigley：而且每次答案都会是 10。

[00:30:28] Chris Reynolds：对。

[00:30:28] Nathan Wrigley：我觉得感觉有点类似。随着时间推移，你只是逐渐习惯了它能完成这类事情。我现在在那个领域信任它。这样概括对吗？你个人已经建立起这种程度的信任，但如果我开始自己的旅程，情况可能不一定相同。我也得像你一样，通过同样的过程逐步建立信任。

[00:30:49] Chris Reynolds：是的。

[00:30:49] Nathan Wrigley：好。

[00:30:49] Chris Reynolds：但我确实认为，我构建的审查工作流可以帮助你达到这个状态。因为如果你把它放进自己的项目中，并针对所有运行中的内容，定制你希望它运行的检查清单，其目标是让它变得更值得信任，并让它更多地去做你预期和希望它做的事情。

[00:31:10] Nathan Wrigley：你能不能告诉我们那份文档中包含的一些内容？我记得你说的是 45 项，也许之后还会有所变化。也许下周会变成 49 项之类的。能否讲讲其中一些比较独特的内容，它们不一定会被移除。我想象你会要求它每次都例行公事般地完成某些事情，但其中一些比较独特的项目，也许是你最近才想到的，可能会让我们的听众觉得：哦，好吧，这个我从来没想过。

[00:31:31] Chris Reynolds：我会让它采用测试驱动开发，或者告诉它采用测试驱动开发。原因是这样的：测试驱动开发就是先编写测试，然后编写代码来通过测试。

事实证明，AI 在这方面做得远比人类更好，因为人类不想做这件事，它太烧脑了。但 AI 可以做到，既然 AI 能做，那我就让 AI 来做。让 AI 先编写代码必须通过的测试，以完成你交给它的任务，这意味着：第一，你永远不会遇到回归问题，因为测试已经写好了；第二，它已经知道该如何修复，因为它亲自编写了一个能让功能失败的测试。这是一个相当重要的细节。你当然可以写单元测试之类的，但从测试开始确实很有价值。

我的检查清单里有几件具体的事。其中最重要的一点，我认为是确保它不会把密钥写入文件系统。

[00:32:33] Nathan Wrigley：光是把这话说出来就感觉很奇怪。

[00:32:36] Chris Reynolds：因为它确实会这么做。这条规则之所以必须存在，是因为曾经有一段时间还没有这条规则，而它就真的这么写了。这甚至算是 WordPress 中关于密钥的特殊概念，因为我们的 wp-config 文件之类的文件里有 API 密钥之类的东西。理论上，我们也不应该这么做。但我们还没有一个真正好的通用密钥管理方案。所以这件事就会变得有些摇摆不定。不过，是的，不把密钥写入文件系统确实非常重要。

是的，老实说，这些不是什么特别疯狂的事情。比如确保测试通过、确保你进行了无障碍检查。我猜可能比较独特的一点是，我也用 Claude 设计了这个网站。这同样是一次实验，因为我完全不知道 AI 会如何处理设计。所以有一件事是，我知道自己所在的工作场所使用 Storybook 来维护设计系统。我就想，这似乎是个不错的工具，也许我可以让 AI 构建一个 Storybook。

所以我基本上搭建了这样一个系统：当我让它构建一个新组件时，它会先在 Storybook 中构建该组件，这样我就能先审查设计，并在那里反复讨论，然后再把组件实现到实际产品中。因此，其中有一条规定是：如果要引入任何新的设计组件，就必须先在 Storybook 中完成。

[00:33:56] Nathan Wrigley：好的。对，对。这里面确实有一些有趣的东西，不过我想每个人都会有一份不太一样的文件。

[00:34:02] Chris Reynolds：是的。

[00:34:02] Nathan Wrigley：好的。所以我想知道，对于你刚才描述并亲自经历的流程，尤其是考虑到 2026 年 8 月，你有没有一种直觉：在未来几年里，这类事情会不会由 AI 公司解决，并让它默认变得更加可靠？还是你认为，从今往后我们都得一直与这个问题角力？毕竟，我们的系统、我们的 AI 总会有一种奇怪的倾向：产生幻觉、凭空编造，或者直接脱轨，做出一些莫名其妙的事情。

现在，显然我是在要求你们盯着水晶球占卜，但我确实想知道，随着时间推移，输出是否变得更加真实可信，还是只是变得越来越疯狂。

[00:34:42] Chris Reynolds: 我认为 we'll see more of is more integrated like agent orchestration. 所以我现在做的某种程度上就是一种智能体编排。我有一个智能体专门做一件事，还有另一个智能体负责审查前一个智能体的工作。

就像昨天的主题演讲一样，她谈到了一个非常相似的流程，其中有五个不同的智能体，审查者是其中之一。有规划者、编码者，还有其他什么角色。我认为这可能是我们以后会开始更多看到的东西，而且在某个时候，当你与 Claude 对话、在 Claude 中输入提示词时，你以为自己是在和一个整体交流。但在 Claude 大脑的黑箱之下，实际上有五个不同的智能体正在并发运行，处理这件事并完成各自不同的任务之类的。所以当它进行思考时，就像是在同时执行五套不同的流程。我认为这可能就会是未来会发生的事情。

[00:35:40] Nathan Wrigley: 我实在是对这样一件事感到着迷：如今已经到了 2026 年，我们竟然全都接受了这就是现实。但如果你能把 2021 年的 Chris 放到那把椅子上，让他坐在那边某个地方听你讲话，他会说：“不，这是《星际迷航》。这是货真价实的科幻小说。我完全不知道他在说什么。这些根本说不通，计算机不可能做到这一点。它们永远不可能做到。”

然而我们还是走到了今天，我们几乎是轻而易举就越过了图灵测试。很长时间以来，我一直觉得这会是一个重要里程碑，大家都低头看表，说：“哦，天哪，这事发生了。”这个领域的格局变化之快，确实令人震惊。

[00:36:17] Chris Reynolds: 真正有趣的是，我最早读到的一些 AI 相关人物中，有一位是 AI 研究者，她专门研究小型语言模型，比如 GPT 之类模型出现之前就已经存在的那些非常早期的模型。但从根本上看，这些东西的运作方式非常非常相似。不过那是 2021 年、2022 年左右的情况，当时这东西已经存在，但效果真的很差。我不知道还有多少人记得 Horse eBooks 那个 Twitter 账号。

[00:36:49] Nathan Wrigley: 不记得。

[00:36:50] Chris Reynolds: 但那是个非常奇怪的账号，是个机器人账号，里面就像有某种 AI、机器学习之类的程序，只是某个机器人不停地往 Twitter 上吐些胡话，完全不知所云。而且特别搞笑。你也还记得吧，在不算太久远的过去，我们会收到一些语气发生奇怪变化的钓鱼邮件之类的东西，一看就明显是机器人写的，或者就是垃圾消息之类。那就是当时存在的东西。

现存的任何事物都不太一样，它们全都源自同一个根源，但没错，从“这东西是垃圾”到“这东西确实有用”，或者至少听起来像人一样的转变，感觉就像是在一夜之间发生的。而且感觉像是一次翻天覆地的转变。当 Chat GPT 首次向公众开放时，我当时想的是“这怎么可能？还有”，紧接着不久，Microsoft 就发布了 Bing 聊天机器人。

[00:37:53] Nathan Wrigley: 是的。

[00:37:53] Chris Reynolds: 当时还闹出了 Bing 想和那位记者结婚之类的事。这说明我们对正在构建的东西究竟了解得多么少。事实上，没有哪一家 AI 公司真正理解，或者我现在觉得甚至仍然不理解，它为什么会以这种方式运作。

[00:38:11] Nathan Wrigley: 这实际上是个相当令人担忧的坦承。

[00:38:13] Chris Reynolds: 确实如此，就是这样。

[00:38:14] Nathan Wrigley: 是的。

[00:38:14] Chris Reynolds: 所以我们会继续走下去。从这个角度看，我也觉得这令人担忧，因为现在他们正在各地要求建设大型新数据中心。我敢肯定，任何收听节目的人都会对数据中心感到愤怒，我对数据中心也很愤怒。但这是基于这样一种信念：这些数据中心会以某种有意义的方式产生影响。而我不知道它们是否会。

因为我们不知道，因为我们并不知道自己是怎么走到今天的。而它现在就在做这件事。我可以用它来给我的网站编写代码，就像我今天就能这么做一样。但我需要在美国各地新建 50 座数据中心，才能让它变得更好吗？我不知道。

[00:38:55] Nathan Wrigley: 你几乎把一个完美的反乌托邦科幻情节描述出来了，不是吗？这一切就这么发生了。它给出了极具迷惑性、且随着时间推移越来越像人类的近似回答，以至于我们已经无法——

[00:39:08] Chris Reynolds: 我们是不是刚刚发明了天网？

[00:39:09] Nathan Wrigley: 是啊。我们已经无法察觉它不是人类了。它真的让人觉得，在某个我们看不见的地方，藏着一个邪恶的霸主正一边抚摸着猫之类的。

而且当然，我们并不真正知道自己是怎么走到今天的，但我完全被它迷住了。我和你有同样的担忧。数据中心、环境，以及这一切对地球资源的浪费。但与此同时，这似乎并没有阻止我对它产生好奇、亲自试用；而 AI 对其他人来说就是不对。但当我自己使用时，哦，它完全没问题。不过，你知道的？这确实是个问题。

[00:39:41] Chris Reynolds: 是的。

[00:39:42] Nathan Wrigley: 好吧。我想我们就在这里收尾吧，就像英国人说的那样。在结束之前，还有没有什么你希望我们刚刚谈过、但还没谈到的东西？或者你觉得我们把大部分需要谈的都谈到了。

[00:39:50] Chris Reynolds: 我认为，关于 AI，最让我犹豫或担忧的一件事，就是把如此庞大、或者说无论多少的认知负荷交给 AI。这样一来，我们自身的一部分以及我们自己的大脑就会逐渐萎缩、衰败。

我主要从我个人、我的孩子、我的家人以及所有使用它的人的角度思考这个问题，比如我们自己会因此变得技能不足。但我也从工程、开发以及我们所处的这个世界的角度来思考。如果我们告诉所有人：“哦，你现在的任务本质上就是充当一名高级工程师，审查一名初级开发者的工作，那就是 AI。”那么高级开发者还存在吗？

[00:40:41] Nathan Wrigley：你把梯子的最底一级去掉了，不是吗？没错。你拿走了刚走出大学的人迈出第一步的能力。然后是第二步、第三步。因为 AI 已经完成了第一、第二和第三步。

[00:40:52] Chris Reynolds：我理解，有一套不同的技能、一套不同的规则之类的东西，会成为你工作的一部分，让你成为那名审查者，成为使用 AI 来完成开发工作的新型工程师。但我认为，学习历程中有些东西正是让我走到今天、也让其他高级开发者走到今天的位置的东西，那就是理解上下文、能够引导 AI。我不知道这些环节能否被绕过。我不知道能否跳过这些步骤。

[00:41:22] Nathan Wrigley：我觉得，如果 AI 公司聘请了一支真正值得信赖的哲学家团队，你大概会感到很好奇。你懂我的意思吗？比如每 100 名开发者配备 10 名哲学家，他们专门思考并忧虑到底发生了什么。听起来很荒谬，但也许这正是我们需要的，因为你今天描述的有些事情实在太令人费解了，你需要引导它、约束它，也需要担心它可能做出的那些怪事。我们需要考虑未来、数据中心以及这一切。

在某种程度上，这确实感觉我们像蒙着眼睛。至少在我们自己的内心看来，我们似乎正朝着想要的方向前进。但我不知道，也许只有时间能告诉我们答案。如果到 2027 年我们都还在这里。

[00:42:05] Chris Reynolds：到那时就知道了。

[00:42:05] Nathan Wrigley：那我们在 2029 年就成功了，谁知道呢？一切皆有可能。

[00:42:09] Chris Reynolds：是的。我能算出未来三年内，我的工作可能不会消失。但三年之后、再往后，我就不知道了。

[00:42:15] Nathan Wrigley：好的。

[00:42:16] Chris Reynolds：我很确定，我的工作应该没问题，因为我确实认为开发者关系本质上就是与人类交流，但也许到时候已经没有人类可以交谈了，所以也许我只会和 AI 说话。

[00:42:24] Nathan Wrigley：好的。WordCamp US 2029。就定在那一天了。到时候我们再见。

Chris Reynolds，感谢你分享这些想法。是的，这次交流真的很有启发性。谢谢你。

[00:42:34] Chris Reynolds：谢谢你邀请我。