Software 2.0

停止闲聊，开始编写规范

admin -

你打开 AI 编码助手，输入："帮我构建一个任务管理应用，包含登录页面和仪表盘。"

它生成了大量代码。你粘贴进去，运行后，结果大致像你想象的那样，但又不完全正确。登录页面看起来有问题，于是你让它修复登录。现在仪表盘又坏了，于是你让它修复仪表盘。它重写了半个文件。三个小时过去了，应用看起来和你想象的大致一样，但你已经无法清楚地理解代码库中到底有什么了。

这是 AI 编码工具初学者的典型经历。最初几分钟感觉很有成效，但接下来的几个小时揭示了代码库变得多么难以理解。

这不是 AI 的错，也不是你的错。问题在于结构。

1、真正的问题：没有共享的地图

当你和 AI 通过聊天共同构建时，每个新会话都是一个全新的开始。AI 不记得你的意图、你的约束条件，也不记得你在之前对话中做出的决定。你不是在逐步建立共同的理解。每次打开新的聊天窗口，你都在从零开始。

"任务管理器"对你来说到底意味着什么？它有团队功能吗？截止日期？标签？周期性任务？AI 在猜测。有时它猜对了。通常它没有，而当你注意到时，那个猜测已经成为代码中的承重墙。

缺失的不是更聪明的 AI，而是一个共享的唯一真相源：一份轻量级的文档，在写下任何一行代码之前，就能捕获你正在构建什么、为什么构建以及如何构建。

2、规范驱动开发：一个不断增长的运动

业界已经开始认识到这个问题。围绕"AI 辅助编码从书面规范而非聊天消息出发效果更好"这一理念，出现了一类新的工具和方法。这个术语被称为规范驱动开发（spec-driven development），今天它以许多不同的形式出现。

这些方法在所需结构化程度和工作流集成紧密程度上有所不同，但它们都共享同一个核心理念：在开始生成代码之前，先就你要构建的内容达成一致。

以下是目前可用的代表性工具概览。

  • Kiro 是亚马逊推出的代理式 IDE，它使用 EARS 语法将你的提示转换为结构化需求，然后在编写任何代码之前生成设计文档和有序的任务分解。
  • GitHub Copilot Workspace 是一个基于云的环境，它从 GitHub issue 或提示中生成"建议规范"和可编辑的计划，允许你在实施开始之前审查和调整两者。
  • GitHub Spec Kit 是一个开源工具包，提供模板和 CLI 命令，用于在引入任何 AI 代理之前定义项目章程、规范、技术计划和原子任务。
  • Cursor Rules 是持久化配置文件（.cursor/rules），在每次请求时将你的编码准则注入模型上下文，使 AI 始终与你的标准保持一致，而无需手动重新提示。
  • OpenSpec 是一个轻量级框架，在你的项目中引入 specs/ 目录和 changes/ 文件夹，其中每个变更都从提案和增量规范开始，然后再进行实施。
  • SPARC 是一种方法论，定义了五个明确的阶段（规范、伪代码、架构、细化、完成），可以由专门的 AI 代理按顺序执行。

这些工具存在于一个光谱上。一端是 Cursor Rules，它本质上是一种持久化编码约定的方式，使 AI 不会在会话之间遗忘。另一端是 Kiro 和 Devin，它们是完整的代理式环境，以最少的人工干预进行规划、实施和迭代。中间是 OpenSpec 和 GitHub Spec Kit 等工具，它们专注于人类意图和 AI 执行之间的交接，而不替换你现有的编辑器或工作流。

对于初学者来说，最实用的入门点是一个不需要切换工具的轻量级框架。你需要一个适合你当前工作流的东西，教会你在编码之前先编写规范的习惯，而不是一个将整个过程完全抽象化的平台。

3、不过度形式化，也不走瀑布流

这里是大多数开发者停止阅读的地方。"形式化"听起来像是触摸键盘之前要写 40 页的需求文档。听起来像是企业软件开发中最糟糕的部分。OpenSpec 是一个开源框架，它引入了恰到好处的结构，使 AI 辅助编码变得连贯。它给你一个 specs/ 目录作为你的唯一真相源，和一个 changes/ 文件夹，用于存放拟议的修改，直到它们准备好合并。这就是整个模型。

你在项目中安装它：

npm install -g openspec
openspec init

生成的脚手架如下所示：

specs/
  auth.md
  dashboard.md
changes/
  add-task-tagging/
    proposal.md
    delta-specs.md
    tasks.md

提案（proposal） 捕获意图和范围。增量规范（delta specs） 描述正在添加、修改或删除的内容，而不是整个系统。任务（tasks） 是实施清单。你的 AI 在编写代码之前读取这些文件，因此它清楚地知道自己要构建什么。

4、一个真实的例子

假设你正在构建一个简单的支出跟踪器。你从 openspec init 开始，在 AI 助手中运行 /opsx:propose 来启动第一个功能：添加支出。

你的 proposal.md 看起来像这样：

## Intent
Allow users to log individual expenses with a category, amount, and date.

## Scope
- A form to submit a new expense
- A list view showing all expenses, sorted by date
- No editing or deletion in this iteration

## Out of scope
- Budget limits
- Charts or analytics
- Multi-user support

三句话的范围描述就足够了。当你告诉你的 AI "实现支出表单"时，它知道没有编辑功能，没有图表，也没有多用户复杂性。它不需要猜测；它构建你描述的东西。

当你后来想添加编辑功能时，你不会修改现有的规范。你创建一个新的变更：changes/add-expense-editing/。增量规范说："MODIFY: 支出列表以包含编辑和删除操作。"你的决策历史保持完整。

5、为什么这对初学者有效

经验丰富的开发者在脑海中携带了大量这样的上下文。他们本能地知道该推迟什么、该排除什么范围、该明确什么假设。初学者还没有这种能力。

OpenSpec 将这种思考外化。撰写提案迫使你回答 AI 本来会猜测的问题。因为规范存在于文件中而非聊天历史中，所以它可以跨会话、跨工具、跨团队成员持久保存。

你也学得更快。当出现问题时，你将其追溯到模糊的规范，就能理解为什么会出错。这比"AI 又幻觉了"是更深刻的教训。

核心要点：

  1. 基于聊天的 AI 编码存在结构性缺陷：每条消息都是无状态的，AI 没有关于你意图的记忆。
  2. 解决之道不是更聪明的 AI，而是共享规范：一份在开始之前就捕获你要构建内容的轻量级文档。
  3. OpenSpec 面向存量项目：它不仅适用于新项目，也适用于现有项目。
  4. 增量规范胜过全量重写：描述变化的部分，而不是整个系统。
  5. 规范使你成为更好的开发者：撰写规范的训练构建了与经验丰富的工程师在脑海中携带的相同直觉。

6、结束语

AI 编码工具确实强大。但如果没有方向，这种力量会产生不一致的结果。从这些工具中获得最多收益的开发者不是那些输入最长提示的人，而是那些花十分钟写下他们真正想要构建什么的人。

OpenSpec 为你提供了实现这一目标的脚手架，而没有正式流程的繁文缛节。它符合真实软件的构建方式：迭代地、在现有代码库中、由不断摸索的人来完成。

你可以从 openspec init 开始，写一份提案，然后观察你的 AI 在生成代码之前拥有这些上下文时的行为。

原文链接: Stop Chatting, Start Specifying: Build Better with AI Coding Tools

汇智网翻译整理，转载请标明出处