写作比代码更接近思考:AI 开发应以理想状态文档(ISA)为源头
Writing Is Closer to Thought Than Code
Ideal State Artifact(ISA)方法主张,在 AI 开发中以书面理想状态和可测试标准为源头,而非把代码当作唯一真相。ISA 包含理想状态、约束、决策和 Ideal State Criteria(ISCs),每项标准配套评测,同时作为实现依据和测试框架。实现暴露出的新认识会回写至 ISA,使意图与写作、写作与实现形成两个持续迭代的闭环,代码则可按同一标准丢弃并重建。
文章把 AI 开发中的偏差归因于表达问题,并用 ISA 将意图、决策、实现和评测串成可迭代闭环。
关于规格驱动开发的最佳方式,我一直在和Matt Pocock进行一场准辩论,而且已经持续了一阵子。
Matt 是一位才华横溢的老派开发者:真正的软件工程师。他一直在利用 AI 将自己的能力提升到非凡程度。他的开发技能令人叹为观止,在 GitHub 上获得的星标数几乎超过任何其他技能仓库。2
那么,我的分歧是什么?
基本上,我认为对于旧式做法,他已经站在了山顶。他掌握着大量技能和大量命令,还鼓励人们手动运行它们。让人类参与其中是他理念的核心,而我认为,如今这已经成了一种反模式。
但他近来的核心观点是,开发项目中最重要的东西是代码本身。规格当然有用,诸如此类,但代码本身才是主要产物,是所有事务的真实依据。1
我强烈不同意。我认为,把你要构建什么以及为什么要构建表述清楚,远比什么都重要。归根结底,是那个想法。你的意图。
我认为,在任何借助 AI 构建的项目中(即便不使用 AI),无论是开发 Web 应用、创办一家公司,还是管理一个星球联邦,最重要的是你能否完整而准确地表述清楚自己究竟想要什么。
先说清楚,我并不是说你在开始之前就必须有一个完美且完全成形的表述。没人能做到。我们是人类,而随着我们构建,我们想要的东西会变得更清晰。我的论点关乎这种迭代发生在哪里:应发生在对理想状态的表述之内,而不是围着代码打转。而且有两个循环,而非一个。在你弄清自己真正想要什么时,你的意图与写作来回迭代;在你构建时,写作与实现来回迭代。
真正的问题在于表述
我认为,我们在 2026 年看到的绝大多数 AI 问题都被错误归因了。AI 在执行方面非同凡响。它在按照我们的要求做事方面,正变得强得难以置信。如今越来越多的问题在于,它把工作执行得完美无缺,但结果却与我们心中的设想不同。
但这是一个沟通问题。这是一个表述问题。
作者也会遇到同样的问题。这通常被称为作者盲点。你以为你已经完整捕捉了脑中的内容,实际上却没有。于是,信息接收者,也就是读者,最终会遗漏信息,或者得到一份与作者意图完全不同的评价。
代码是一种表征,而非源头
Matt 这一立场的问题在于,他认为代码具有权威性。但代码实际上是一种抽象,就像一幅画是画家想要传达之物的抽象一样。它是一次执行。一份摹本。一种表征。
但还有一种更高级的形式,那就是写作和图像。
写作是我们拥有的、最接近人类思维的东西。正如我一直喜欢告诉人们的,对我来说,写作就是思考。而且,它以极大的优势成为我们最接近的东西。
准确性胜过精确性
但我理解 Matt 为什么迷恋代码。代码确实比写作更擅长某件事,那就是精确。不过,写作在准确性上更胜一筹。所以这是一种准确性与精确性之间的权衡。
我们当然希望两者兼得,但说到用 AI 构建东西,我认为准确性远比精确性重要。一个经典例子是:一名弓箭手试图射中靶心。
准确性而没有精确性,就是所有箭都落在靶心附近,但每一箭的位置各不相同。精确性而没有准确性则恰恰相反:所有箭紧密聚集在一起,却远在靶纸边缘,离你想射中的目标很远。
当我们用 AI 构建时,我们希望结果与自己脑中的想法一致。这就是准确性。而要捕捉人类脑中的靶心,没有什么方式比写作更贴近目标。
理想状态工件
这意味着什么?
这意味着,以书面形式阐明你想要什么,是你能为任何 AI 项目做的最重要的事。我说的不只是采用僵化的规格说明或 PRD 格式,而是要以更全面、更富创意的方式进行表达。
我在 2025 年末想明白了这一点,并把自己所做的一切都切换到一种称为理想状态工件(ISA)的方式上。这是一种用于与 AI 交互的新文档和方法。它能更深入地呈现我们试图构建的东西,并通过多个章节来表达不同类型的内容。
其中包括经过明确表述的理想状态,采用散文形式,而且可能篇幅很长。我的框架(LifeOS)使用 Discuss 技能(类似 Matt 的 /grill-me skill),帮助尽可能完整地填写这部分内容。它可以只有几段,也可以是围绕某个主题、长达 4,000 字的意识流和深度内省。
接下来是约束条件,例如我们不想构建的东西等。然后是决策,记录我们在更新项目理想状态时作出的决定。我们很少一开始就拥有完美的理想状态。有时只有开始构建后,目标才会逐渐清晰,这也没关系。决策部分正是为此而设。当构建过程给你带来启发,或者重读 ISA 改变了你对目标的看法时,你就连同日期和原因一起写回 ISA,让迭代体现在清晰的表述之中,而不会迷失在代码里。
然后是最重要的部分(位于顶部的理想状态定义之后),也就是我们所谓的理想状态标准(ISC)。这些是我们在应用中实际构建并进行检验的目标。它们是极其原子化、可测试的功能单元。每一项还都关联着自己的评测,复杂度可以从基础的 assert 到多阶段的 code → assert → System 1 question set → Rubric / Tournament / LLM as a Judge。
理想状态标准以这种方式定义,而且评测就与其一起直接写在 ISA 中,真正强大之处在于:这些 ISC 同时既是我们的构建依据,也是测试框架!
下面是一个小例子:一份用于家庭膳食规划器的 ISA。这里只展示了其中一部分。真正的 ISA 还会包含完整的理想状态表述、测试策略、评测本身以及最新的运行状态。
膳食规划器 ISA 的一部分:理想状态、约束条件、标准与决策
画出猫头鹰
下面举三个例子来说明。每个例子都包含一个想法、对这个想法的表述,以及该表述的实现。而每个例子中的错误都相同:跳过中间这一步,把实现本身当作真相。
这些例子没有一个需要在第一天就表达得完美无缺。你把能写下来的写下来,然后动手构建,而草稿会让你发现自己忘了表达哪些内容。重读自己写下的东西也会改变你的想法。不同之处在于,这两种经验都会反馈到 ISA 中。下面每个 ISA 也都只是一个切片,即理想状态和各项标准。真正的 ISA 承载的内容要多得多。
猫头鹰
假设你想画出一幅完美的猫头鹰。你脑海中有一幅美妙的图像。但你画得不太好,在这个类比中,画作就是代码。因此最终画出来的是一只火柴人猫头鹰,几乎认不出是猫头鹰。
在“代码即事实来源”的版本中,这幅火柴人画现在就是权威产物。我们分析它、记录它,记下它各部分的比例,并花上一大段时间不断迭代。我们只是围着一幅糟糕的画原地打转。
我们略过的,是借助我们为此掌握的最精确工具——写作——把脑海中的东西干净地转成记录下来的状态。那份书面描述,正是这幅画试图实现的东西。
猫头鹰 ISA 的一部分,以第一幅火柴人画为基准核对:四项标准均未通过
现在,每幅画都要对照 ISA 检查,而不是对照上一幅画。火柴人画未通过全部四项标准,下一次尝试便清楚知道自己要瞄准什么。如果某一版草稿让你意识到自己其实想画一只展翅飞行的猫头鹰,这一点也要作为一项决策写入 ISA,而不是被埋没在第七幅画中。
网页应用
一位朋友经营一家小型瑜伽馆,希望常客无需给她发短信就能预约课程。有人给 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 之类的计算机友好语言编写的项目实现源代码,无论如何,其对原始想法的呈现保真度都远不及 Ideal State Artifact。
所以,这就是我一直就这件事与 Matt 反复交锋,并试图将 ISA 系统作为一种替代方案的原因。我觉得,他不过是在用自己卓越的开发者才智,去优化编程的旧有思考方式。4
我们所有人都应该从 Richard Sutton 的《苦涩教训》 中汲取的一点是:AI 越聪明,就越能以令我们无比欣喜的方式,准确地做到我们想要的事情。
过度纠缠于传统的规格驱动开发,以及代码在任何特定日子或时刻所呈现的具体形式,恰好把努力放在了错误的地方。3
AI 越聪明,我们就越应该把精力转向确保它确切知道我们想要什么,而少花精力去事无巨细地管理实现这一点的各个步骤。
来源:Hacker News · danielmiessler.com












