Spec-驱动开发并不是一种新的概念，但是在基于代理的软件开发领域变得更加相关。

对于较小规模的项目，引入这种流程可能是不必要的。但是当项目规模越来越大且越来越久远时，保持上下文、决策和开发输出的一致和结构化方式变得越来越难以维护，特别是在与人工智能系统合作时，上下文会变得 短暂，并且决策容易漂移或重新计算。

在这种情况下，Spec-驱动开发就显得尤其有效了。通过作为一个持久层为上下文、决策和系统边界提供持久性帮助稳定开发过程，并且随着时间的推移逐渐减少不确定性。

-建立在这一基础上，.Frame现在已经内置了Spec-驱动开发。

每个规范都存储成四个文件在磁盘上：

.frame/specs/<slug>/

spec.md 我们要做什么
plan.md 我们如何做
task.md 分解的工作
outcome.md 实际投放

您描述了您想做什么；AI就会为规范草写。从那里 onwards，/spec.plan生成实现计划，/spec.tasks将其分解为一个个的任务并将其同步到tasks.json中，而/spec.implement执行它们一步步地。

在每个任务之后，代理程序都会附加一个短用的结束：投放的结果，分歧点，以及需要的跟踪情况。

最重要的是后面这部分，对不对。

计划捕捉了意图。代码反映了现实。成果解释了差距。

六个月后，当您 wondered 为什么一个文件看起来像这样的情形，那么答案一定是在outcome.md中，当代理程序的记忆还新鲜的时候写的。

两条原则指引了设计：

文件过数据库。Markdown是源代码的来源。任何AI工具都可以不经过Frame阅读它，而任何 teammate 都能利用grep进行 review，它是用Git作为版本管理进行review的，并且它是可移植的。

添加SQLite会是一个满足感，但却是错误的决定。

可选、从不强制。规范驱动开发没有成为每个项目的形状。Frame从未假设该规范应该这样。
在 Specs 面板首次打开时，它仅仅问您是否要激活它。已有(tasks.json) workflow 副本保持不变。

.Frame是开源的，并且目前在Github上星星有300颗，32个分叉，11个贡献者。您可以通过只使用它、给予反馈以及点赞来表达您的支持。
在Github上可以获得： https://github.com/kaanozhan/Frame