16个框架，同一个盲区

凌晨三点的灵感被AI忠实地执行成一份精美规范——然后变成一堆垃圾。这是当前所有智能体框架的默认剧本。

GitHub在2025年9月发布Spec-Kit后，这个领域瞬间膨胀出16个框架。它们都擅长做同一件事：把模糊想法转化为结构完整的产物。但没有一个会问：这个想法本身值得存在吗？

框架们的真实工作流

作者拆解了这些工具的标准流程。用户输入想法后，框架自动推进四步：规格说明、架构设计、实现编码、测试验证。问题藏在第一步之前——那里是空白。

Spec-Kit作为安装量最高的规格驱动开发（SDD）工具之一，运行specify init后会自动生成九条宪法、规格模板、计划模板和任务模板。但这份宪法只约束实现质量，不约束想法质量。

如果代码违反第三条测试标准，合并会被阻断。但如果整个功能本身就是个坏主意？不在审查范围内。

审查者到底在审查什么

「框架有审查机制」——技术上没错，实质上有坑。作者以两个具体工具为例，展示审查的真实边界。

Superpowers是目前Claude Code安装量最高的插件之一。实现完成后，它会启动两个审查子智能体：规格合规审查和代码质量审查。各自返回通过或失败。任一失败则任务不标记完成。

这确实解决了一个常见故障模式：智能体宣布胜利但代码实际跑不通。但注意审查问题的措辞——

规格合规审查问：代码是否符合规格？

代码质量审查问：代码写得是否漂亮？

没人问：规格本身是否合理？

MUSUBI是作者见过的最严谨的开源SDD工具。它内置@traceability-auditor技能，需求到测试的覆盖率低于100%就阻断合并；@constitution-enforcer技能逐条检查九项宪法条款。但同样，审查对象是执行过程，而非初始假设。

坏想法的工业化生产

作者直言这个领域的「脏秘密」：用户带来的大多数想法都是未经审视的。不是恶意，只是半成品——解决的问题是错的，建立在三十秒压力测试就会崩塌的假设上。

而框架们正快乐地燃烧算力，把这些想法转化为可交付的工件。

这引出一个结构性问题。当工具链把「从想法到代码」的摩擦降到趋近于零，我们实际上在批量制造什么？更高效的错误实现，还是更隐蔽的资源浪费？

作者预告第二部分将展示如何填补这个缺口——在智能体、提示词和终止条件层面具体怎么做。但第一部分已经抛出一个足够尖锐的观察：当前所有框架都在优化执行效率，却系统性地回避了价值判断。

这是设计选择，还是能力盲区？如果是后者，谁来定义「好想法」的标准——用户、市场，还是另一个尚未出现的审查层？