我最近开始用 OpenSpec 管理自己的小项目。第一次看到“规格驱动开发”这个说法时，我以为它只是给大型团队准备的重型流程。真正用起来之后，反而觉得它解决了一个很个人化的问题：我经常在没有想清楚要做什么之前，就开始写代码。
聊天记录不是规格
和 AI 协作写项目时，最舒服的状态是不断对话：这里改一点，那里补一块。问题在于，对话是流动的，需求也是流动的。几天后回头看，已经很难说清当初为什么选择了这个结构，哪些行为是约定，哪些只是临时妥协。
OpenSpec 把这些内容拆成几个有先后关系的文件：提案说明为什么做、规格描述系统必须表现出什么行为、设计记录技术选择、任务把实现拆成可验证的步骤。它们不是文档洁癖，而是一组检查点。
openspec new change build-personal-blog
openspec validate build-personal-blog --strict规格应该写行为，而不是实现
一开始我很容易把“使用 Astro 构建”写进规格里。它看起来很明确，实际上却把答案提前锁死了。真正需要被约束的是：读者能否在手机上顺畅阅读，文章是否按时间排序，搜索无结果时是否有反馈。至于用 Astro 还是别的框架，属于设计层可以替换的决定。
当规格只描述外部行为时，它就有了更长的寿命。实现可以升级，依赖可以更换，但“这个系统应该怎样对待使用者”不会因为一次重构全部消失。
小项目也需要边界
个人项目最容易失控的地方，不是技术复杂度，而是边界不断膨胀。今天想加评论，明天想做 Newsletter，后天又觉得应该有一个后台。每次增加都只需要一句“顺便”，最后却没有一个明确的停止点。
把变更写成提案，并不会让开发变慢。它只是把“我到底在做什么”从脑内默会变成了纸面共识。完成之后再归档，下一次打开项目时，至少知道自己是从哪里出发的。
工具不会替我做判断。但它让我在动手之前，先有机会诚实地看一眼：这件事真的值得做吗？