# spec 才是源。prompt 只是用完即弃的边角料。 在一份由 agent 编写的代码库里，什么才是“源代码”？不是生成出来的代码——那现在只是构建产物，就像编译出来的二进制文件。也不是 prompt——那只是你划着用来启动构建、然后随手丢掉的一根火柴。真正持久、由你撰写、拥有、版本化并审查的东西，是 spec。这个层级关系已经翻转，而大多数人还在打磨那个本该扔掉的部分。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, specs, methodology - **Source:** https://fedorthinks.com/zh/blog/the-spec-is-the-source --- 有个问题听上去简单，可一旦 AI agent 开始替你写绝大部分代码，它就不简单了：现在什么才是 _源代码_？请指出那个真正的、权威的、由你亲手编辑的项目产物。大多数人指向 agent 生成的代码。有些人指向 prompt。两者都错了，而正确答案与这两者之间的落差，正是值得理解的整个转变。 我[之前写过](/blog/specs-are-the-artifact)，你应该去推敲的产物是 spec（规格），而不是 prompt。这成为一个行业的一年里，只让这个论断更加锋利。问题不只是 spec 是 _一个_ 产物。问题在于，spec 如今就是 **那个源** ——而你本能伸手去抓的两样东西，代码和 prompt，都被降级到了它之下。 ## 旧的层级：代码就是真理 在软件的整个历史里，源代码一直是真理之源。它是你亲手撰写、拥有、纳入版本控制、逐行审查、为之争论的那个持久之物。文档和注释是次要的——它们是 _对_ 代码的描述，允许漂移，从来不是权威。当文档和代码不一致时，代码胜出，因为代码是真实的，而文档只是关于它的一个说法。 这个层级正在翻转，而且它有了名字。 ## 翻转：spec 是源，代码是构建产物 **规格驱动开发（spec-driven development）**——每一个主流 AI 编码工具都在 2025–26 年发布了自己的一版——[把一份书面的、纳入版本控制的规格当作唯一的真理之源，并把代码视为生成出来的产物](https://thebcms.com/blog/spec-driven-development)。你写 spec——系统做什么、为什么这么做——推导出一份计划，把它拆成任务，agent 再据此生成代码。spec 是人类编辑的产物；代码是构建吐出来的东西。 这个领域一再援引的类比恰恰就是对的那个：[spec 之于代码，就像 .c 文件之于二进制——它是源，代码是它编译出来的二进制文件](https://www.augmentcode.com/guides/what-is-spec-driven-development)。你不会手动去改一个编译好的二进制文件；你改的是源，然后重新构建。在规格驱动开发里，[生成出来的代码就是那个二进制文件](https://www.morphllm.com/spec-driven-development)——你同样不会手动去打补丁，因为你一动手，它就和本该定义它的源失了同步。你改的是 spec，然后重新生成。 这早已不是边缘想法。GitHub 的 [Spec Kit](https://www.marktechpost.com/2026/05/08/meet-github-spec-kit-an-open-source-toolkit-for-spec-driven-development-with-ai-coding-agents/) 跨过了 9 万星，支持 29+ 个 agent；AWS Kiro 是一个完全围绕它打造的 IDE；Cursor、OpenSpec、Tessl 等等也都发布了各自的版本。甚至有人把它称为[第五代编程](https://medium.com/google-cloud/spec-driven-development-54cdf7e0b088)。整个工具世界一下子收敛到了同一个翻转上。 ## 为什么它是对的，而不只是赶时髦 它之所以管用，原因和从源代码编译之所以管用是同一个：你在 _意图_ 这个层级上推敲和改动，让构建去产出产物。规格驱动开发[正是作为“vibe coding”的解药而出现的](https://thebcms.com/blog/spec-driven-development)——给 agent 喂个 prompt，它就堆出一坨看似合理、却偏离你本意、凭空捏造 API、随着规模增长而腐烂的代码。把构建锚定在一份书面的意图上，漂移就有了可以被衡量的参照。 而且它有回报。GitHub 报告说，使用 Spec Kit 的团队交付功能时，[“从头重新生成”的循环次数大约比随手 prompt 少一个数量级](https://www.fundesk.io/spec-driven-development-github-spec-kit-guide)；AWS 记录了在 spec 优先撰写时，[原本需要 40 小时的功能在不到 8 小时的人力时间里就交付了](https://www.morphllm.com/spec-driven-development)。这不是什么小幅的效率提升——这就是当你不再手动编辑二进制文件、而开始真正拥有源时所发生的事。 ## 那么 prompt 又算什么？ 这一部分会重新框定一切。如果 spec 是源、代码是构建产物，那 prompt 甚至都不在你保留的那套层级里。**prompt 是用完即弃的边角料**——你发出来用以触发一次生成的临时命令，就像你敲下去运行 `make` 的那一行 shell。你不会把自己的 `make` 调用纳入版本控制、在 pull request 里审查它；你版本化的是 Makefile 和源，而那行命令只是你那一次启动构建的方式而已。 这也正是为什么纠结 prompt 的措辞从一开始就瞄错了靶子——这和我主张[prompt engineering 已死](/blog/prompt-engineering-is-dead)时讲的是同一个点。团队打磨着一个用完就扔的东西的遣词造句，却对 spec 投入不足，而 spec 才是他们该下苦功、该版本化、该审查的那个东西。他们在校对火柴，却无视了蓝图。 ## 实际中它是什么样子 我就是这么构建的。spec 是我真正动手的产物——我起草它、跟自己争论它、把它纳入版本控制、把它当回事地审查，因为它就是那个起作用的部分。agent 据它生成代码。如果代码错了，我几乎从不去打补丁；我修 spec 然后重新生成，因为手动改产物就是在编辑二进制文件、就是在和源失同步。至于驱动了某次生成的那个 prompt？第二天就没了。我再也不会去看它，因为它是边角料——是你划着用来启动构建的东西，不是你保留的东西。 所以我开篇提的那个问题，现在有了一个干净的答案。一个 AI 构建的系统，它的源代码是 spec。代码是构建从中吐出来的东西。prompt 是你划着然后丢掉的那根火柴。把 spec 当成源来写吧——因为它恰恰已经变成了源。