OpenSpec：让AI构建正确且无误的软件
OpenSpec – A lightweight and configurable AI spec framework
OpenSpec是一个轻量级且可配置的软件规范框架，旨在帮助团队和AI编码代理在开发过程中保持对齐。它不仅能帮你梳理需求、验证目标是否正确，还能确保最终实现与规范一致。通过探索问题、起草提案、实施任务、验证结果到归档变更的完整工作流，OpenSpec让Claude Code、Cursor、GitHub Copilot等主流工具都能高效协作。无论是验证需求还是检查代码，它都致力于实现‘构建正确的事物’和‘正确地构建事物’这一核心理念。
OpenSpec帮助你构建正确的事物，并确保正确地构建它。
HN 评论区
81- cg-enterprise
看到大家对这些框架的看法出现分歧很有意思，而且至少从轶事来看，很多人都在他们最喜欢的 SDD 框架之上自行开发了定制化的工作流管理方案。
我自己最终也走上了自研之路，主要是为了解决现有框架中的几个缺失（对于 SDD，我更喜欢使用 Superpowers 和/或 Matt Pocock 的技能）：
1. 工件陈旧与追踪问题——如果你有一套围绕 ADR（架构决策记录）起步、涵盖整个仓库通用模式的架构体系，那么要持续追踪并保持其更新是非常困难的。你在 ADR 中做出了一个早期的强决策，后来却意识到必须更改或偏离它。这些变更很少被妥善记录。
2. 评审循环——单一模型的评审不够用，我想要多个模型相互碰撞，同时还能利用我的订阅而非直接调用 API。
3. 功能蔓延与延期追踪——在评审或某个验证阶段，经常遇到需要实现某个 x 功能的情况，而该功能并未包含在原始规格中。处理这种情况有几种方案，关键在于所有此类决策都需要被追踪，并在某个时间点由人类做出决定。
4. 带治理的自定义工作流——我有自己偏好的 SDLC（如果这能被称为 SDLC 的话），其中包括多轮代理对规格的评审，之后是人工审批关卡，再根据代码库、功能规模和延期规则进行特定规格的评审循环。
5 […]
- sheepscreek
我们不是已经超越这些东西了吗？最近的 LLM 在长上下文任务上接受了足够的训练，已经变得非常擅长规划。或许这还得益于 harness 的贡献。无论如何，如果我使用的是 Codex 或 Claude Code，我根本不会为此费心。
- wyum
这是我第一次见到 OpenSpec，它的理念似乎与我今年一直在做的事情很相似。
如果你喜欢这个 / SDD，我很欢迎你的反馈：
https://github.com/spekk-ai/spekk-cli
我们同样秉持迭代式规格的理念。我们的方案略有不同，因为我们专注于声明式规格和可安装的代理技能。我们选择 Go 是为了简单和最低要求（单个二进制文件）。
- chandlerklein
希望能看到一个独立的二进制文件，全局 Node 安装太烦人了。
- gps372
对于许多组织来说，这恐怕很难推行，因为它们已经在为 JIRA、SharePoint、GitHub 等平台上爆炸式增长的工件而挣扎。此外，大多数组织在过去 6-8 个月内已经大致确定了生成 AI 优先规格并与其协作的方式。
另外，这看起来像是需要领导层率先采用，然后以某种方式渗透到 PI 规划和冲刺规划中的东西。很想听听有人分享他们在组织中推行这一做法的经验。