AI 写代码已经不稀奇，难的是让它每次都按你想要的方式写。OpenSpec 想解决的正是这个问题。
发生了什么
Hacker News 上出现了一个名为 OpenSpec 的开源项目，定位是“轻量且可配置的 AI spec 框架”。从命名和定位看，它并不直接提供模型或补全能力，而是围绕“规格（spec）”这一层做文章：把开发者对代码的意图、约束和验收标准，抽象成可配置、可复用的规格描述，再交给 AI 去执行。项目在 HN 上获得了一定关注度，讨论集中在它是否比提示词堆砌更可靠。
为什么重要
过去两年，AI 编码工具的进化路径基本是“更强的模型 + 更长的上下文”。但开发者很快发现，模型能力提升并不能自动解决意图对齐问题：同一句提示，不同时间、不同仓库跑出来的结果可能完全不同。于是行业开始从“提示工程”转向“规格工程”——用结构化的文档、规则和约束来定义任务，而不是靠临场发挥的 prompt。
OpenSpec 的价值在于它把这件事做成了一个框架，而不是一套个人习惯。轻量意味着它不要求你重写整个工作流；可配置意味着团队可以把编码规范、目录约定、测试要求写进 spec，让 AI 在不同项目里表现一致。这与近期围绕 AGENTS.md、规则文件、任务描述格式的讨论是同一脉络：大家都在寻找“人机协作的接口标准”。
影响与看点
对开发者而言，这类框架的直接影响是降低重复沟通成本。当规格成为仓库里的一等公民，代码审查、测试生成、重构都可以复用同一份定义，AI 产出的可预测性会明显提升。对团队而言，spec 还能充当一种轻量文档，把隐性约定显性化。
值得关注的点有三个：一是 spec 的表达能力边界——太简单约束不住模型，太复杂又回到写代码本身；二是它与现有工具链（编辑器、CI、代码托管平台）的集成深度；三是生态能否形成可共享的 spec 模板，而不是每个团队各写一套。
我的判断是：规格层不会取代模型能力，但会成为 AI 编码工具差异化的关键战场。谁先把“意图表达”这件事做得足够轻、足够通用，谁就更可能成为开发者工作流里的默认入口。OpenSpec 目前还只是一个早期信号，但它指向的方向值得持续跟踪。
