写作比代码更接近思考

这段时间以来，我和 Matt Pocock 一直在讨论规范驱动开发的最佳做法，几乎算是在辩论。I’ve been having an almost-debate with Matt Pocock for a while about the best way to do spec driven development.

Matt 是一位才华横溢的老派开发者：一位真正的软件工程师。他一直在利用 AI，将自己的能力提升到非凡的程度。他的开发技能令人惊叹，在 GitHub 上获得的星标数超过了几乎所有其他技能仓库。2Matt is a brilliant old-school developer: a true software engineer. And he’s been using AI to enhance his capabilities to an extraordinary degree. His development skills are spectacular, and have been starred more than almost any other skills repo on GitHub.2

那么，我的异议是什么呢？So what’s my disagreement?

基本上，我觉得他是传统做事方式的巅峰代表。他掌握了大量技能，也有一大堆他鼓励大家手动运行的命令。让人类参与整个流程是他非常看重的一点，而我认为这现在已经成了一种反模式。Basically I think he is at the top of the mountain for the old way of doing things. He’s got tons of skills and tons of commands that he encourages people to run manually. Having a human in the loop is a major theme for him, which I think is now an anti-pattern.

但他最近的核心观点是，开发项目中最重要的是代码本身。规格说明固然有用，但代码本身才是主要产物，是一切的事实来源。1But his central idea lately has been that the most important thing in a development project is the code itself. That specs are useful and everything, but the code itself is the main artifact. The source of truth for everything.1

我强烈不同意。我认为，清晰阐述你正在打造什么以及为什么要打造它，要重要得多。归根结底，重要的是这个想法，是你的意图。I disagree strongly. I think the articulation of what you’re building, and why, is far more important. Basically, the idea. Your intent.

我认为，无论是用 AI（甚至不用 AI）开发任何项目——从构建 Web 应用、创办企业，到管理一个行星联邦——最重要的都是你能否完整、准确地阐明自己究竟想要什么。I think the most important thing in any project you’re building with AI (and even without it), from building a web app, to starting a business, to managing a federation of planets, is how completely and accurately you articulate exactly what you want.

说清楚一点，我并不是说你必须先把想法完美、清晰地表达出来才能开始。没人能做到这一点。我们都是人，随着不断构建，想要什么也会变得越来越清楚。我的观点在于，这种反复迭代应该发生在哪里：应该围绕理想状态的表达展开，而不是围着代码兜圈子。而且这里有两个循环，不是一个。你在厘清自己真正想要什么时，意图和文字会来回调整；而在构建过程中，文字和实现也会来回调整。To be clear, I’m not saying you need a perfect, crystallized articulation before you start. Nobody has that. We’re human, and what we want gets clearer as we build. My argument is about where that iteration happens: inside the articulation of the ideal state, not in circles around the code. And there are two loops, not one. Your intent and the writing go back and forth as you figure out what you actually want, and the writing and the implementation go back and forth as you build.

真正的问题在于表达清晰度。The real problem is articulation

我认为，我们在2026年看到的大多数 AI 问题都归错了因。AI 在执行方面表现非凡，越来越擅长按我们的要求做事，甚至好得令人难以置信。如今越来越多的问题在于：它完美地完成了任务，但结果却和我们心里想的不一样。I think most of the problems we see with AI in 2026 are misattributed. AI is extraordinary at execution. It’s getting unbelievably great at doing what we ask it to do. More and more of the problems at this point are it executing the job perfectly, and having the result be different than what was in our mind.

但这是一个沟通问题，也是一个表达问题。But this is a communication problem. It’s an articulation problem.

作者也有同样的问题。这通常被称为“写作者盲区”。你以为自己完美地表达了脑海中的想法，但实际上并没有。因此，接收者或读者最终可能会遗漏信息，或者产生与作者本意截然不同的解读。Authors have this same problem. It’s commonly called Writer’s Blindness. It’s where you think you’re perfectly capturing what’s in your brain, but you’re not. And so the receiver, or the reader, ends up missing information or getting a completely different review than the author intended.

代码是一种表征，而非源头Code is a representation, not the source

马特立场的问题在于，他认为代码具有权威性。实际上，代码是一种抽象，就像一幅画是画家想要传达之物的一种抽象。它是一次执行、一份摹本、一种表征。The problem with Matt’s position is that he thinks code is authoritative. It’s actually an abstraction, the same way a painting is an abstraction of what the painter was wanting to convey. It’s an execution. A facsimile. A representation.

但这还有更高的形式，那就是文字，还有图像。But there’s a higher form of this, and that’s writing. And images.

写作是我们最接近人类思维的东西。正如我常对人说的，对我而言，写作就是思考。它远远胜过其他任何事物，是我们所拥有的最接近思维的东西。Writing is the closest thing we have to human thought. As I like to tell people all the time, for me writing IS thinking. It’s the closest thing we have, by a wide margin.

准确性胜过精确度Accuracy beats precision

但我明白马特为什么会迷恋代码。代码确实比写作更具备某种特质，那就是精确性。不过，写作的准确性更高。所以这其实是在准确性和精确性之间权衡。But I get why Matt is enamored with code. It does have more of something than even writing, which is precision. Writing has more accuracy, though. So it’s a tradeoff between accuracy and precision.

显然我们两者都想要，但在用 AI 构建东西时，我认为准确性重要得多。对此最经典的示例，就是一名弓箭手试图射中靶心。We obviously want both, but when it comes to building stuff with AI I think accuracy is far more important. The classic illustration of this is an archer trying to hit a bullseye on a target.

因此，缺乏精确度的准确性，就像一连串射击都落在靶心附近，但每一发的位置各不相同。缺乏准确性的精确度则恰恰相反：每一发都集中在一个很小的区域内，却远在靶纸边缘附近，离你原本想击中的地方很远。So accuracy without precision is a bunch of shots that all land right around the bullseye, but each in a different spot. Precision without accuracy is the opposite: every shot packed into one tight group, but way out near the edge, far from what you were trying to hit.

当我们借助 AI 构建东西时，我们希望最终结果符合脑海中的设想。这就是准确性。而要精准捕捉人类脑海中的目标，没有比文字更好的方式了。When we build with AI we want the outcome to match what was in our brains. That’s accuracy. And there’s no closer way to capture the bullseye of what’s in our human brains than with writing.

理想状态制品The Ideal State Artifact

那么这是什么意思？So what does that mean?

这意味着，对于任何 AI 项目来说，把你想要的东西用文字表达出来，是你能做的最重要的事。我指的不只是采用严格的规格说明或 PRD 格式，还包括更全面、更有创意的方式。It means articulating what you want, in written form, is the most important thing you can do for any AI project. And I don’t mean just in a rigid spec format, or a PRD format, but in much more holistic and creative ways.

我在 2025 年底弄明白了这一点，并把自己所做的一切都转向了一种叫作理想状态产物（Ideal State Artifact，ISA）的东西。这是一种用于与 AI 交互的新文档和新方法。它能更深入地记录我们试图打造的内容，并通过多个章节分别阐述不同类型的内容。I figured this out at the end of 2025 and switched everything I do over to something called an Ideal State Artifact (ISA), which is a new document and approach for interacting with AI. It’s a much deeper capture of what we’re trying to build, and it uses multiple sections for the different types of articulation.

还有一种是用散文形式阐述的理想状态，内容可能很多。我的运行框架（LifeOS）会使用 Discuss 技能（类似于 Matt 的 /grill-me 技能），帮助我按需尽可能充分地补充内容。它可以是几段文字，也可以是围绕某个主题写下的 4,000 字意识流和深度自省。There is the articulated Ideal State, which is prose. Potentially lots of it. My harness (LifeOS) uses a Discuss skill (similar to Matt’s /grill-me skill) to help fill this in as much as needed. This can be a few paragraphs, or it could be 4,000 words of stream of consciousness and deep introspection on some topic.

然后是约束，也就是我们不想构建的东西等。接下来是决策，记录我们在更新项目理想状态时所做的决定。一开始，我们很少能有一个完美的理想状态。有时，只有在开始构建后，事情才会变得清晰，这没关系。决策部分正是为此而设。当构建过程让你有所领悟，或者重读 ISA 后改变了你对目标的想法，就把这些内容连同日期和原因一起补充到 ISA 中，这样迭代就会体现在阐述中，而不会在代码里丢失。Then there are Constraints, things we don’t want to build, etc. Then there are Decisions that were made as we updated the ideal state for the project. We rarely start off with a perfect ideal state in the beginning. Sometimes it only becomes clear as we start building, and that’s ok. That’s exactly what the Decisions section is for. When building teaches you something, or rereading the ISA changes your mind about what you want, you write it back into the ISA with the date and the reason, so the iteration happens in the articulation instead of getting lost in the code.

接下来是最重要的部分（仅次于顶部对理想状态的定义）：我们称之为理想状态标准（ISC）。这些是我们实际上要在应用中构建和测试的内容。它们都是极其细化且可测试的功能单元。每一项都有与之关联的评估，其复杂程度各不相同，从基本的断言，到多阶段的“代码 → 断言 → System 1 问题集 → 评分标准 / 锦标赛 / 由 LLM 担任评判者”。And then the most important section (behind the ideal state definition at the top) are what we call Ideal State Criteria (ISCs). These are things we’re actually building and testing for in the application. They are extremely atomic and testable pieces of functionality. Each one of them has its own eval associated with it as well, which can range in complexity from a basic assert to a multi-phase code → assert → System 1 question set → Rubric / Tournament / LLM as a Judge.

以这种方式定义理想状态标准（ISC），并在 ISA 中同时定义相关评测，真正强大之处在于：ISC 既是我们据以构建的基础，也是测试框架！What’s really powerful about the Ideal State Criteria being defined this way, with their evals defined along side them right in the ISA, is that the ISCs are simultaneously what we build from AND the testing harness!

这里有一个小例子：一个家庭膳食规划器的 ISA。这只展示了其中一部分。真正的 ISA 还包含完整的理想状态描述、测试策略、评估本身以及持续更新的状态。Here’s a small example, an ISA for a family meal planner. This shows only a piece of it. A real ISA also carries the full ideal state articulation, a test strategy, the evals themselves and a running status.

餐食规划器 ISA 的一部分：理想状态、约束条件、标准和决策Part of the meal planner ISA: the ideal state, constraints, criteria and decisions

绘制猫头鹰Drawing the owl

以下是我所说的三个例子。每个例子都包含一个想法、对这个想法的阐述，以及对这种阐述的实现。而每个例子中的错误都一样：跳过中间步骤，把实现当成事实。Here are three examples of what I mean. Each one has an idea, an articulation of that idea, and an implementation of the articulation. And in each one the mistake is the same: skipping the middle step and treating the implementation as the truth.

这些例子都不需要一开始就表述得完美。你尽可能写下来，然后动手构建；草稿会让你发现自己漏说了什么。读自己写下的内容，也会改变你想要的东西。不同之处在于，这两类经验教训都会回到 ISA 中。下面每个 ISA 也只展示了一部分：理想状态和判断标准。实际的 ISA 包含的内容要多得多。None of these examples needs a perfect articulation on day one. You write down what you can, you build, and the drafts teach you what you forgot to say. Reading what you wrote also changes what you want. The difference is that both kinds of lesson go back into the ISA. Each ISA below is also just a slice, the ideal state and the criteria. The real ones carry much more.

猫头鹰The owl

假设你想画一幅完美的猫头鹰图画。你的脑海中浮现出一幅美丽的猫头鹰图像。但你不太会画画，而在这个比喻中，画作就是代码。于是，最后画出来的只是一个简笔画猫头鹰，几乎认不出来是只猫头鹰。Say you want to draw a perfect picture of an owl. You have this beautiful image of it in your mind. But you can’t draw very well, and in this analogy the drawing is the code. So what comes out is a stick-figure owl that’s barely recognizable as an owl.

在“代码即事实来源”的版本中，那个火柴人如今成了权威产物。我们分析它、为它编写文档、记录它的比例，还花了大把时间反复迭代。我们只是在围着一幅糟糕的画打转。In the code-is-the-source-of-truth version, that stick figure is now the authoritative artifact. We analyze it, document it, take notes on its proportions, and spend a whole bunch of time iterating on it. We’re running in circles around a bad drawing.

我们跳过的是从大脑到被记录下来的状态之间的清晰转译，而我们拥有的最精确工具就是写作。那段书面描述，正是绘画试图实现的东西。What we skipped was the clean translation from the brain to a captured state, using the most precise tool we have for that, which is writing. That written description is the thing the drawing is trying to implement.

Owl ISA 的一部分，已对照第一个简笔人像进行检查：四项标准仍全部待处理。Part of the owl ISA, checked against the first stick figure: all four criteria still open

现在，每幅图都会根据 ISA 进行检查，而不是拿来和上一幅图比较。简笔小人不符合全部四项标准，而下一次尝试则明确知道目标是什么。如果草稿让你意识到，其实想要的是一只飞翔的猫头鹰，这一点就会作为一项决策记录在 ISA 中，而不会被埋没在第七幅图里。Now every drawing gets checked against the ISA instead of against the last drawing. The stick figure fails all four criteria, and the next attempt knows exactly what it’s aiming at. And if a draft makes you realize you actually want the owl in flight, that goes into the ISA as a Decision. It doesn’t get buried in drawing number seven.

Web 应用The web app

一位朋友经营着一家小型瑜伽馆，想让老会员不用给她发短信就能预约课程。有人只给 AI 一句提示，它就搭建出一个预约应用：设有强制登录页面，日历网格在手机上根本看不清，还会发送没人要求的确认邮件，而且把课程人数上限设成了 20 人，尽管教室只能容纳 12 人。A friend runs a small yoga studio and wants her regulars to book classes without texting her. Someone gives an AI a one-line prompt, and it builds a booking app with a login wall, a calendar grid that’s unreadable on a phone, confirmation emails nobody asked for, and a class capacity of 20 for a room that holds 12.

如果代码是真实依据，那么那个应用如今就成了规范。有人会为日历网格编写测试，有人会记录登录流程，还有人会重构邮件系统。第一版中的每个意外之处都会变成一项需求，因为它们已经写进了代码。很快，就没人说得清哪些部分才是大家真正想要的了。If the code is the source of truth, that app is now the spec. Tests get written for the calendar grid. The login flow gets documented. Somebody refactors the email system. Every accident in version one becomes a requirement because it’s in the code, and soon nobody can say which parts anyone actually wanted.

工作室预订 ISA 的一部分，已对照该应用的第一个版本进行检查Part of the studio booking ISA, checked against version one of the app

有了 ISA，登录墙未通过 ISC-1，容量错误未通过 ISC-2，所以两者都会被淘汰。没人会为日历网格编写测试，因为没有任何标准要求这样做。于是代码就变得可以随意舍弃。如果第一版糟糕到一定程度，你就把它扔掉，基于同一份 ISA 重新构建，而同一套评估也会检查新版本。要是代码是你想要什么的唯一记录，你就做不到这一点。With the ISA, the login wall fails ISC-1 and the wrong capacity fails ISC-2, so both go. Nobody writes tests for the calendar grid, because no criterion asks for one. And the code becomes disposable. If version one is bad enough, you throw it out and rebuild against the same ISA, and the same evals check the new build. You can’t do that when the code is the only record of what you wanted.

厨房The kitchen

这在软件领域之外也同样适用。比如说，你要翻新厨房。你的设想是：周日早上，你们两个人一起做饭，朋友坐在吧台边的高脚凳上，大家都能参与同一场聊天。你给承包商一张大致的草图，他们却把厨房建成炉灶面朝墙的样子，这样一来，无论谁在做饭，都会背对着大家。This works outside software too. Say you’re remodeling your kitchen. The idea is Sunday mornings: two of you cooking, friends on stools at the counter, everyone in one conversation. You give the contractor a rough sketch, and they build it with the stove facing the wall, so whoever is cooking has their back to everyone.

先实施再说的做法，接下来三个月都在调整已经建好的东西。你挪动一个柜子，换掉抽油烟机，把所有东西都量一遍，并记录房间目前的样子。现在你们争论的是橱柜，而不是周日早晨。The implementation-first version is spending the next three months adjusting what got built. You move a cabinet, swap the hood, measure everything and document the room as it stands. Now you’re arguing about cabinets instead of Sunday mornings.

厨房 ISA 的一部分，已与承包商的首份方案进行核对Part of the kitchen ISA, checked against the contractor’s first plan

把这一点写下来后，炉灶靠墙的方案在纸面上就不符合 ISC-1，无须等到有人锯下第一块木板。问题从来不在承包商身上。他们是出色的执行者，和 AI 如出一辙。他们缺少的是一个明确写下来的执行目标。With this written down, the stove-against-the-wall plan fails ISC-1 on paper, before anyone cuts a single board. The contractor was never the problem. They’re an excellent executor, exactly like AI. What they were missing was a written target to execute against.

在这三种情况下，都存在两个有用的循环，而 ISA 处于这两个循环的中心。第一个循环中，你的意图与 ISA 相互塑造：你写下自己的期望，回头阅读时会发现自己真正想表达的是什么，于是 ISA 随之改变。第二个循环中，实施方案会根据你写下的内容接受检查；而每当草稿让你发现还有尚未表达的内容时，你写下的内容也会变得更加明确。在这两个循环中，反复迭代都很正常，也很有益。理想情况下，ISA 就是记录这些迭代的地方，包括标准和决策日志。In all three cases there are two useful loops, and the ISA sits in the middle of both. In the first, your intent and the ISA shape each other: you write down what you want, reading it back shows you what you actually meant, and the ISA changes. In the second, the implementation gets checked against what you wrote, and what you wrote gets sharper every time a draft shows you something you hadn’t said yet. Iterating is normal and good in both. The ISA is simply where the iteration gets recorded, in the ideal state, the criteria and the Decisions log.

将整个构想汇集于一份文档中The whole idea in one document

最终，我们为正在构建的每个项目都形成一份文档，尽可能准确地表达我们脑海中的想法。我们称之为“理想状态产物”，因为位于文档顶部的理想状态表述最为重要；但实际上，整份文档都尽可能贴切地呈现了我们心中想要构建的东西。So what we end up with is a single document for every project we’re building that represents the closest possible articulation of what’s in our mind. We call it an Ideal State Artifact because the ideal state articulation at the top is the most important thing, but really the entire document represents the closest possible representation of the idea we have in our mind of what we wanted to build.

随着 AI 越来越智能，这一点为何变得更加重要Why this matters more as AI gets smarter

现在回到马特，你应该已经更清楚地明白，为什么用 TypeScript、Python 之类便于计算机处理的语言编写的项目实现源代码，远不如「理想状态工件」那样忠实地呈现原始构想。Now, returning to Matt, it should be much clearer now why source code for the implementation of this project, in some computer-friendly language like Typescript or Python or whatever, is nowhere near as high-fidelity of a representation of the original idea as an Ideal State Artifact.

所以这就是我一直在和 Matt 就此来回争论，并试图把 ISA 系统作为替代方案的原因。我认为，他只是在把自己出色的开发者才智浪费在优化那套陈旧的编程思维方式上。4So this is why I have been sparring back and forth with Matt about this, and trying to offer the ISA system as an alternative. I think he’s simply wasting his brilliant developer mind on optimizing the old way of thinking about programming.4

我们都应该从理查德·萨顿的《苦涩的教训》中领会到：人工智能越聪明，就越能以一种让我们无比欣喜的方式，准确做到我们想要它做的事。What we should all take from Richard Sutton’s Bitter Lesson is that the smarter AI gets the more it’ll be able to do exactly what we want in a way that will absolutely delight us.

过度执着于传统的规范驱动开发，以及代码在任何特定日期或时刻的具体形态，都是把精力用错了地方。3Over-rotating on legacy spec-driven development, and the exact form that code takes on any given day or moment, is putting the effort in precisely the wrong place.3

AI 越聪明，我们就越应该把精力放在确保它准确理解我们的需求上，而不是事无巨细地管控实现这些需求的步骤。The smarter the AI gets the more we should move our effort into making sure it knows exactly what we want. And less into micromanaging the steps to make that happen.