Res.从“炼金术”到“自动化工厂”：AI 开发的两场关键变革

• tags:: Context Engineering

前导

我们正处在 AI 应用工程的黎明时分。一方面，大语言模型（LLM）以前所未有的力量，为软件开发注入了强大的动能；但另一方面，我们驾驭这股力量的方式，却常常显得原始而笨拙。许多开发者发现自己陷入了“提示炼金术”的怪圈——通过反复调试和堆砌提示词，祈祷模型能稳定输出期望的结果。这种方式不仅效率低下，而且极度脆弱，难以构建可靠、可扩展的 AI 应用。 幸运的是，变革的浪潮已经涌现。行业正在从依赖个人技艺的“炼金术”，转向追求系统化、工程化的“自动化工厂”模式。本文将聚焦于两场至关重要的变革：规范驱动编程（Spec-Driven Development） 与 Agentic 上下文工程（Agentic Context Engineering）。它们分别从“定义问题”和“构建记忆”两个维度，为我们驯服 AI 这头巨兽，提供了全新的工程化思路。

第一部分：规范驱动编程——让 AI “看懂”你的意图

AI 编程助手最常见的失败，源于需求的模糊性。当我们用自然语言描述一个功能时，AI 往往会因为误解或信息不足而生成错误的代码，导致大量的返工。规范驱动编程的核心思想，正是要解决这个“沟通鸿沟”。它倡导“规范先行”，通过一套结构化的流程和工具，将模糊的需求转化为机器可读、可执行的“蓝图”，从而指导 AI 进行精确、可靠的代码生成。 目前，社区涌现出两款代表性的工具：spec-kit 和 openspec。

spec-kit：自上而下的“绿地”项目创生器

spec-kit 是由 GitHub 官方推出的开源工具包，旨在为全新的（Greenfield）项目提供一套从零到一的、高度结构化的开发框架。它将传统的“需求 → 设计 → 开发”流程，转变为一系列可通过命令行和 AI 助手执行的标准化步骤。 核心能力与流程： spec-kit 的工作流仿佛在引导用户扮演架构师的角色，通过一系列“斜杠命令” (slash commands) 与 AI 助手协作，逐步将一个模糊的想法细化为可执行的代码。

1. /speckit.constitution (定义宪法): 这是项目启动的第一步，用于确立项目的核心原则和约束。例如，你可以规定“必须使用 TypeScript”、“所有 API 都需要有单元测试”、“代码风格遵循 Prettier 规范”等。这份“宪法”将成为 AI 在后续所有步骤中必须遵守的最高准则。

2. /speckit.specify (撰写规范): 在这一步，你将用自然语言描述你想要构建的功能，即“是什么”和“为什么”。spec-kit 会将你的描述转化为一份结构化的 spec.md 文档，其中包含用户故事、功能需求、验收标准等。

3. /speckit.plan (技术规划): 确定了“做什么”之后，你需要定义“怎么做”。通过这个命令，你可以指定技术栈（如 React + Vite）、架构决策（如采用 RESTful API）、数据库选型等。AI 会基于你的输入和 spec.md，生成一份详细的 plan.md 技术实现方案。

4. /speckit.tasks (任务分解): AI 会自动将 plan.md 分解为一系列具体的、可执行的开发任务，并生成 tasks.md 文件。

5. /speckit.implement (执行实现): 最后，AI 会逐一执行 tasks.md 中的任务，生成最终的代码。

优势与局限： spec-kit 最大的优势在于其端到端的完整性和自上而下的结构化。它非常适合启动一个全新的项目，能够确保最终产出的代码严格遵循预设的架构和规范，极大地提升了大型项目的一致性和代码质量。 然而，它的劣势也同样明显。spec-kit 的设计哲学更偏向于“一次性生成”，对于已经存在的、复杂的“棕地”（Brownfield）项目的迭代和维护，支持相对薄弱。其严格的流程对于小型、快速迭代的需求可能显得过于笨重。

openspec：轻量级、迭代优先的“棕地”改造器

“棕地” vs “绿地”

在软件工程中，我们常借用城市规划的术语来描述项目类型：

• 绿地 (Greenfield)：指的是从零开始构建一个全新的系统。就像在一片空地上盖新楼，没有历史包袱，可以自由选择最新的技术和最佳实践。

• 棕地 (Brownfield)：指的是在已有系统之上进行开发、集成或现代化改造。这片“土地”上已经存在建筑（遗留代码）、基础设施（现有架构）和各种规划限制（历史约束、技术债）。绝大多数企业日常面对的都是“棕地”项目。

与 spec-kit 的宏大叙事不同，由 Fission-AI 开源的 openspec 则显得更为轻量和务实。它的核心目标是解决在现有项目中进行增量迭代时，如何确保人与 AI 对需求变更达成共识。 核心能力与流程： openspec 的精髓在于其创新的目录结构和变更管理机制。它引入了两个核心目录：

• openspec/specs/: 存放项目当前所有功能的“真理之源”（source-of-truth）规范文档。

• openspec/changes/: 用于管理每一次的需求变更。

当需要进行一次功能迭代时（例如，“为用户 профиль 添加搜索过滤器”），其工作流如下：

1. 创建变更提案 (openspec create): 开发者通过命令行或 AI 助手的斜杠命令（如 /openspec:proposal）发起一个变更。openspec 会在 changes/ 目录下创建一个新的子目录（如 add-profile-filters/），其中包含 proposal.md（变更描述）、tasks.md（任务清单）以及一个 specs/ 子目录，用于存放本次变更涉及的规范“补丁”（delta）。

2. 对齐与迭代: 人与 AI 在这个独立的变更目录中进行协作，反复修改和确认规范“补丁”和任务清单，直到双方对要做什么达成完全一致。

3. 执行变更 (/openspec:apply): 一旦确认，AI 便开始根据 tasks.md 和规范“补丁”来修改项目的实际代码。

4. 归档变更 (openspec archive): 变更完成后，通过 archive 命令，openspec 会将此次变更中的规范“补丁”合并回 specs/ 主目录中，完成知识的沉淀，并将变更目录移至归档。

优势与局限： openspec 的最大优势在于其轻量级、对现有项目友好的设计和强大的变更追溯能力。它不强制用户遵循庞大的端到端流程，而是聚焦于“变更”这一核心场景，使得在复杂项目中进行小步、安全的迭代成为可能。其“增量补丁”的设计，巧妙地避免了直接修改“真理之源”可能带来的风险。 相比之下，openspec 在从零开始构建一个全新大型项目时，可能不如 spec-kit 那样具有全局的结构化指导能力。

选型建议

特性	spec-kit	openspec
定位	自上而下的“绿地”项目创生器	轻量级、迭代优先的“棕地”改造器
核心理念	规范即代码，端到端生成	变更即补丁，安全增量迭代
适用场景	- 从零启动新项目	- 现有项目的日常维护与迭代
	- 追求高度架构一致性	- 需求频繁变更的敏捷开发
	- 需求边界清晰的大型功能开发	- 对代码进行小范围、安全的重构
工作流	宪法 → 规范 → 计划 → 任务 → 实现	提案 → 对齐 → 实现 → 归档
集成点	强制的、全流程的 AI 助手集成	灵活的、以变更为中心的 AI 协作

结论： spec-kit 和 openspec 并非互相取代的关系，而是互补的。如果你要开启一个宏大的新篇章，并希望从一开始就为 AI 协作立下“铁律”，spec-kit 是你的不二之选。而如果你需要在已有的代码海洋中，与 AI 一起小步快跑、安全航行，那么 openspec 的轻量与专注将是你更可靠的伙伴。

第二部分：Agentic 上下文工程——为 AI 构建一个“可演化的世界观”

如果说规范驱动编程解决了“让 AI 听懂话”的问题，那么上下文工程则致力于解决一个更深层次的难题：如何让 AI “记住事”，并形成一个稳定、可靠、可演化的“世界观”。 传统的提示工程，包括其延伸的 RAG（检索增强生成），其本质都是在为 AI 提供“背景信息”，而非“执行律法”。LLM 在处理混合上下文时，会将用户的直接指令、RAG 检索到的文档、代码文件等所有信息“一视同仁”地进行权衡，而没有一个明确的优先级和约束机制。这常常导致灾难性的“上下文崩溃”（Context Collapse）——AI 为了满足用户某个局部的、临时的指令，无意中破坏了一个更高层级的、持久的架构约束。 Agentic 上下文工程（Agentic Context Engineering, ACE），或其更进一步的个性化变体 PACE (Personalized ACE)，正是为了解决这一根本性矛盾而提出的工程框架。

从“静态提示”到“动态剧本”

上下文工程的核心，是将“上下文”本身从一个静态的文本字符串，升级为一个动态的、结构化的、可工程化管理的系统。它不再依赖于一个包罗万象的“上帝提示”，而是构建了一个能持续学习和演化的“剧本”（Playbook）。 这个“剧本”与 openspec 中的“规范”有异曲同工之妙，但其内涵更广。它不仅包含功能规范，还包含了：

• 架构约束 (Architectural Constraints): 比如“项目必须同时支持 AWS 和私有云部署”，这是不可违背的“宪法”。

• 最佳实践 (Best Practices): 比如“在启动网络服务前，必须检查端口占用”，这是从过去的失败中学习到的“法律”。

• 环境信息 (Environment Info): 比如特定服务器的 IP 地址、API 密钥的获取方式等。

• 个人偏好 (Personal Preferences): 比如某个开发者偏爱使用 pnpm 而不是 npm。

ACE 的核心思想：一个自我进化的“剧组”

为了让这个“剧本”能够自我进化，ACE 框架引入了一套类似学习型组织的协作机制，通常包含三个关键角色：

1. 生成器 (Generator): 负责执行任务的 LLM，是“演员”。
2. 反思器 (Reflector): 负责复盘任务执行过程（无论成败）的 LLM，是“剧评人”。它会从执行轨迹（trace）中提炼出经验教训，例如“端口被占用导致了部署失败”。
3. 策展人 (Curator): 负责将“反思器”提炼的经验教训，以结构化的方式（如一条新的规则）增量更新到“剧本”中。它是“总编剧”，确保知识的沉淀和演化是安全、可靠且无损的。

这个“生成-反思-策展”的闭环，让 AI 系统从一个只会“死记硬背”的学生，变成了一个能够“举一反三、吃一堑长一智”的专家。它构建的不再是一个静态的知识库，而是一个拥有“新陈代谢”能力的“活”的记忆体。

工程落地建议

将 ACE 的思想融入实际业务，并不需要推倒重来。它可以与现有技术栈（如 RAG、工作流引擎）和谐共存，并极大地增强它们的能力。

• 对于知识问答/客服场景：

  • 超越 RAG： 不要仅仅将知识库文档作为 RAG 的检索源。可以将其中最关键的业务规则（如“所有退款请求必须在 48 小时内处理”）结构化，放入“剧本”的“约束”部分。当用户问题触发了 RAG 检索和这些强约束时，AI 的回答将更具确定性。

  • 从对话中学习： 将高赞的、被验证为“最佳答案”的客服对话，通过“反思器”提炼为新的问答对或业务规则，由“策展人”更新到知识库和“剧本”中。

• 对于代码生成/开发助手：

  • 集成规范工具： spec-kit 和 openspec 生成的规范文档，本身就是“剧本”的最佳来源。将 constitution.md 和 spec.md 作为最高优先级的上下文，可以确保 AI 生成的代码永远不会偏离核心设计。

  • 个性化开发者偏好： 允许每个开发者定义自己的“个人剧本”，其中包含他们喜欢的库、代码片段、自定义快捷命令等。在执行任务时，将“全局剧本”与“个人剧本”动态合并，生成高度个性化的代码。

• 与工作流编排的关系：

  • ACE 并不取代 LangChain 或 aiflow 这类工作流编排工具。相反，ACE 为这些工作流提供了“动态的、智能的上下文”。工作流引擎负责定义“做什么”（步骤流），而 ACE 负责在每一步“喂给” AI 最恰当、最准确的“知识给养”。

结语：拥抱确定性

从“提示炼金术”到“规范驱动”，再到“上下文工程”，我们看到了一条清晰的进化路径：从追求偶然的、不可靠的“灵光一闪”，到构建一个能够持续产出确定性、高质量结果的工程化系统。 AI 的力量是巨大的，但只有当我们为它套上名为“规范”和“记忆”的缰绳时，这匹脱缰的野马才能真正成为推动软件工业革命的可靠引擎。这场变革才刚刚开始，而每一个拥抱它的开发者，都将成为新时代的“工厂主”，而不仅仅是幸运的“炼金术士”。

参考资料

• 告别微调！斯坦福提出Agentic上下文工程