以事实驱动开发：简化智能体工作流

软件开发领域正在不断演变，AI 智能体在从代码生成到维护的各个阶段都发挥着越来越重要的作用。然而，将这些智能体有效地集成到传统的开发范式（特别是规范驱动的方法）中，带来了独特的挑战。facts 项目引入了一个新颖的概念：事实驱动开发，旨在通过剥离规范的复杂性并专注于纯粹的可验证事实，来简化智能体工作流。

这种转变源于观察到的 AI 智能体在与冗长或复杂的规范交互时表现出的低效率。智能体容易产生不必要的“废话”，而且大型项目中规范的庞大数量和相互关联性往往会导致“一致性税”，即智能体难以在整个文档中保持连贯性。facts 的核心前提是，每一份规范在本质上都仅仅是事实的集合；通过隔离并直接呈现这些事实，开发过程对于 AI 智能体来说可以变得更加高效且更不易出错。

智能体在传统规范驱动开发中的问题

传统的规范文档虽然对于人类的理解和协作至关重要，但往往包含叙述性元素、程序性指令和隐性上下文，这些对于 AI 智能体来说可能难以高效处理。 facts 的创建者 everlier 强调了几个关键问题：

• 废话生成：当给予智能体宽泛的规范时，它们可能会生成无关的细节或解释，从而偏离核心意图，增加噪声而非信号。
• 一致性税：在大型项目中，规范可能会变得庞大且相互关联。在这些文档中保持一致性，特别是在发生变更时，会成为沉重的负担，导致智能体出错并需要人类不断监督。
• 维护开销：保持详细规范的实时更新并与不断演进的代码库保持一致所需的精力可能非常巨大，消耗宝贵的开发资源。

这些问题表明，旨在澄清人类理解的结构可能会在无意中使智能体操作复杂化。

什么是“事实”以及它们如何与“规范”不同？

从核心来看，facts 方法认为规范最终是原子化、可验证陈述的集合。区别在于它们的结构和意图：

• 规范 (Specs)：通常是冗长的、叙述性的，并且可以包含程序性步骤、设计选择和上下文信息。它们是为全面的人类理解而设计的，可能包含冗余或隐性依赖。
• 事实 (Facts)：简洁、声明式的、原子化的真理陈述。它们剥离了叙述，纯粹专注于可验证的信息。例如，与其用一段话描述用户流程，一个“事实”可能会陈述：“用户身份验证需要有效的电子邮件和密码。”或者“API 端点 /users 返回一个 JSON 数组的用户对象。”

正如一位评论者 @bgsesr42 所询问的，“规范与事实列表有什么区别？”区别主要在于粒度和焦点。规范包含事实，但它也包含更多内容。facts 旨在提取仅有的核心、可验证的真理，使智能体更容易消费和执行，而无需解析无关信息或推断意图。

使开发对智能体更友好

通过将规范提炼为离散事实的集合，facts 项目旨在创建一个本质上对 AI 智能体更友好的环境。这种方法提供了几个潜在的益处：

• 减少歧义：原子化的事实为智能体误解留下的空间更小，从而产生更精确的输出。

• 更易于一致性检查：验证一组离散事实的一致性比交叉引用复杂的叙述性规范要简单得多。

• 聚焦智能体行动：可以引导智能体直接基于这些事实进行操作，执行诸如代码生成、测试或文档更新等任务，并具有对所需结果更清晰的理解。

• 更低的维护成本：更新特定的事实通常比修改传统规范的大量章节要简单得多，从而降低了智能体的“一致性税”。

为了促进这一点，facts 项目提供了一套专门为智能体与这些事实进行交互和管理而设计的技能 (skills) 和命令行界面 (CLI)。这些工具允许智能体以一种实际且集成的方式利用事实驱动开发。

前行之路：证明概念

虽然从规范到事实的概念转变呈现了一个引人注目的愿景，但这种方法的实际有效性将是其能否被采用的关键。正如 @sminchev 正确指出的，需要具体的证据：

我很乐意看到一些证明这行得通的证据。一个启动并运行的项目。一个更友好的规范看起来是什么样的，以及为什么智能体能更好地理解它。

通过现实世界的项目来演示这种范式，展示“更友好”的规范（即事实的集合）是如何构建的，并展示智能体如何处理并从其过程中获益的清晰示例，将是至关重要的。这种验证将有助于说明事实驱动开发所承诺的在智能体性能、一致性以及整体开发效率方面的切实改进。

结论

facts 项目代表了我们如何构建开发流程的一种有趣的演变，特别是在 AI 智能体日益深入地集成到我们的工作流中时。通过挑战对冗长规范的传统依赖，转而倡导一种精简化的、事实驱动的方法，它试图解决诸如智能体生成的废话和高昂的一致性税等常见痛点。随着项目的成熟和现实世界的实现方案出现，看到这种范式转变如何重新定义智能体辅助开发中的效率将会是非常令人兴奋的。