写作比代码更接近思考：AI 开发中意图表达比代码更重要

我和 Matt Pocock 就规格驱动开发的最佳方式已经进行了一场近乎辩论的讨论，持续了一段时间。

Matt 是一位才华横溢的老派开发者：一位真正的软件工程师。他一直在用 AI 将自己的能力提升到非凡的程度。他的开发技能非常出色，在 GitHub 上获得的星标数几乎超过任何其他技能仓库。2

那么我的分歧在哪里？

基本上，我认为他在旧有做事方式上已经登峰造极。他拥有大量技能和大量命令，并鼓励人们手动运行它们。让人类留在循环中是他的一个主要理念，而我认为这在如今是一种反模式。

但他最近的核心观点是，开发项目中最重要的东西是代码本身。规格是有用的，诸如此类，但代码本身才是主要产物。是一切的事实来源。1

我强烈反对。我认为，清晰地表达你在构建什么以及为什么构建，要重要得多。基本上，就是那个想法。你的意图。

我认为，在你用 AI（甚至不用 AI）构建的任何项目中，从构建一个 Web 应用，到创办一家企业，再到管理一个行星联邦，最重要的事情是你如何完整而准确地表达你究竟想要什么。

需要明确的是，我并不是说你在开始之前就需要一个完美、清晰的表达。没有人能做到。我们是人类，我们想要的东西会随着构建过程而变得更清晰。我的论点在于这种迭代发生在哪里：发生在对理想状态的表达之中，而不是围绕着代码打转。而且有两个循环，不是一个。你的意图和写作在你弄清楚自己真正想要什么的过程中来回往复，而写作和实现则在你构建的过程中来回往复。

真正的问题在于表达 ​

我认为我们在 2026 年看到的 AI 相关问题大多被错误归因了。AI 在执行方面非常出色。它在做我们要求它做的事情上正变得难以置信地强大。到现阶段，越来越多的问题在于它完美地执行了任务，但结果却与我们心中的设想不同。

但这是一个沟通问题。这是一个表达问题。

作家也有同样的问题。这通常被称为作者盲区。你以为自己完美地捕捉到了脑海中的内容，但其实并没有。于是接收者，或者说读者，最终会遗漏信息，或者得到一个与作者意图完全不同的理解。

代码是一种表示，而非源头 ​

Matt 观点的问题在于，他认为代码是权威的。它实际上是一种抽象，就像一幅画是画家想要传达之物的抽象一样。它是一种执行。一种摹本。一种表示。

但还有一种更高的形式，那就是写作。以及图像。

写作是我们最接近人类思维的东西。正如我一直喜欢告诉人们的，对我来说写作就是思考。这是我们拥有的最接近的东西，而且遥遥领先。

准确胜过精确 ​

但我理解 Matt 为什么迷恋代码。它确实比写作多拥有某种东西，那就是精确。不过，写作拥有更多的准确。所以这是在准确与精确之间的权衡。

我们显然两者都想要，但在用 AI 构建东西时，我认为准确性要重要得多。关于这一点的经典例证是弓箭手试图射中靶心。

所以，没有精确性的准确性是一堆都落在靶心附近的箭，但每一支都落在不同的位置。没有准确性的精确性则相反：每一箭都紧密地扎成一团，但远在边缘附近，离你试图命中的目标很远。

当我们用 AI 构建时，我们希望结果与我们大脑中的想法相匹配。这就是准确性。而没有什么比写作更能精准捕捉我们人类大脑中那个靶心了。

理想状态工件 ​

那么这意味着什么呢？

这意味着，以书面形式清晰表达你想要的东西，是你能为任何 AI 项目做的最重要的事情。我指的不只是僵化的规格格式或 PRD 格式，而是更加整体化、更有创意的方式。

我在 2025 年底发现了这一点，并把我所做的一切都切换到了所谓的 理想状态工件（ISA），这是一种用于与 AI 交互的新文档和方法。它更深入地捕捉了我们试图构建的东西，并使用多个部分来承载不同类型的表述。

其中有经过清晰表述的理想状态，它是散文式的。可能篇幅很大。我的 harness（LifeOS）使用一个 Discuss 技能（类似于 Matt 的 /grill-me 技能）来帮助按需填充这部分内容。这可以是几个段落，也可以是 4,000 字的意识流，以及对某个主题的深度内省。

然后是约束，即我们不想构建的东西等等。接着是随着我们更新项目理想状态而做出的决策。我们很少一开始就有完美的理想状态。有时只有当我们开始构建时它才变得清晰，这没关系。这正是决策部分存在的意义。当构建过程教会了你一些东西，或者重读 ISA 改变了你对想要什么的想法时，你就把它连同日期和原因写回 ISA，这样迭代就发生在表述中，而不是在代码中丢失。

然后最重要的部分（仅次于顶部的理想状态定义）是我们所谓的理想状态标准（ISC）。这些是我们在应用中实际构建和测试的东西。它们是极其原子化且可测试的功能单元。每一个都有自己的评估与之关联，复杂度可以从基本的 assert 到多阶段的 code → assert → System 1 question set → Rubric / Tournament / LLM as a Judge 不等。

以这种方式定义理想状态标准，并将它们的评估直接定义在 ISA 旁边，真正强大的地方在于：ISC 同时是我们构建的依据，也是测试 harness！

这里有一个小例子，一个家庭膳食规划器的 ISA。这里只展示了其中一部分。真正的 ISA 还包含完整的理想状态表述、测试策略、评估本身以及运行状态。

膳食规划器 ISA 的一部分：理想状态、约束、标准和决策

画猫头鹰 ​

这里有三个例子来说明我的意思。每一个都有一个想法、对该想法的表述，以及该表述的实现。而在每一个例子中，错误都是一样的：跳过中间步骤，把实现当作真相。

这些例子都不需要在第一天就做到完美表达。你写下你能写的，动手构建，而草稿会教会你遗漏了什么。阅读你写下的内容也会改变你想要的。区别在于，这两种教训都会回到 ISA 中。下面的每个 ISA 也只是一个切片，即理想状态和标准。真实的 ISA 承载的内容要多得多。

猫头鹰 ​

假设你想画一幅完美的猫头鹰图。你脑海中有一幅美丽的画面。但你画得不太好，在这个类比中，画就是代码。所以画出来的是一只勉强能认出是猫头鹰的火柴人猫头鹰。

在“代码即真相来源”的版本中，那只火柴人现在成了权威产物。我们分析它、记录它、记下它的比例，并花大量时间在它上面反复迭代。我们围着一幅糟糕的画打转。

我们跳过的是从大脑到捕获状态的干净翻译，用我们为此拥有的最精确工具——写作。那段书面描述才是画作试图实现的东西。

猫头鹰 ISA 的一部分，对照第一版火柴人检查：四项标准仍全部未通过

现在每幅画都要对照 ISA 检查，而不是对照上一幅画。火柴人四项标准全部未通过，而下一次尝试清楚知道自己瞄准的是什么。如果某份草稿让你意识到你其实想要飞行中的猫头鹰，那会作为一项 Decision 进入 ISA。它不会被埋没在第 7 号画作里。

Web 应用 ​

一位朋友经营一家小型瑜伽工作室，她希望老顾客不用给她发短信就能预约课程。有人给 AI 一句提示词，它构建了一个预约应用，带有登录墙、在手机上难以阅读的日历网格、没人要求的确认邮件，以及一个只能容纳 12 人的房间却设了 20 人的课程容量。

如果代码是真相来源，那么这个应用现在就是规格说明。人们为日历网格编写测试。登录流程被记录成文档。有人重构了邮件系统。第一版中的每一个意外都因为存在于代码中而变成了需求，很快没人能说清哪些部分才是任何人真正想要的。

工作室预约 ISA 的一部分，对照应用第一版检查

有了 ISA，登录墙未通过 ISC-1，错误的容量未通过 ISC-2，所以两者都被去掉。没人再为日历网格编写测试，因为没有标准要求它。代码变得可丢弃。如果第一版足够糟糕，你就把它扔掉，按照同一个 ISA 重建，同样的评估会检查新构建。当代码是你想要之物的唯一记录时，你做不到这一点。

厨房 ​

这在软件之外也适用。假设你在改造厨房。想法是关于周日早晨：你们两人做饭，朋友们坐在吧台凳上，所有人都在同一个对话里。你给承包商一张粗略的草图，他们建造时把炉灶面向墙壁，于是做饭的人背对着所有人。

实现优先的版本是花接下来三个月调整已经建好的东西。你移动一个橱柜，换掉抽油烟机，测量一切并记录房间的现状。现在你们争论的是橱柜，而不是周日早晨。

厨房 ISA 的一部分，对照承包商的第一版方案检查

把这些写下来之后，炉子靠墙的方案在纸面上就无法通过 ISC-1，甚至还没等任何人锯一块木板。承包商从来都不是问题所在。他们是出色的执行者，和 AI 一模一样。他们缺的是一个写下来的目标，供他们照着执行。

在这三种情况下，都有两个有用的循环，而 ISA 位于两者中间。在第一个循环中，你的意图和 ISA 相互塑造：你写下你想要的东西，读回来让你看到自己实际想表达什么，ISA 随之改变。在第二个循环中，实现会对照你写下的内容接受检查，而每当你写下的内容还不够明确时，草稿就会让你看到，于是你写下的内容也变得更精确。在这两个循环中，迭代都是正常且有益的。ISA 正是迭代被记录下来的地方——在理想状态下，就是标准与决策日志。

整个理念浓缩在一份文档里 ​

所以我们最终为每个正在构建的项目都准备了一份单一文档，它尽可能贴近地表达了我们脑海中的想法。我们称之为理想状态工件（Ideal State Artifact），因为顶部的理想状态表述是最重要的部分，但实际上整份文档代表的是我们脑海中关于想构建之物的想法所能达到的最接近的呈现。

为什么随着 AI 变得更聪明，这一点更重要 ​

现在回到 Matt，应该更清楚了：这个项目实现的源代码——用 TypeScript、Python 之类的计算机友好语言写的——作为原始想法的呈现，其保真度远不及理想状态工件。

所以这就是为什么我一直和 Matt 来回争论，并试图把 ISA 体系作为一种替代方案提出来。我认为他只是在把出色的开发者头脑浪费在优化旧的编程思维方式上。4

我们都应该从 Richard Sutton 的《苦涩的教训》 中领悟到：AI 越聪明，就越能完全按照我们想要的方式去做，并以一种绝对让我们欣喜的方式实现。

过度执着于遗留的规格驱动开发，以及代码在某个特定日子或时刻所呈现的确切形式，恰恰是把精力用错了地方。3

AI 越聪明，我们就越应该把精力投入到确保它确切知道我们想要什么上。而更少投入到微观管理实现这一目标的步骤上。