今年五月，我写过一篇关于如何解锁2025年软件开发新姿势的文章。没想到，半年一晃而过，AI编程领域发展迅猛，软件工具也在快速更新。各大公司纷纷推出自己的AI开发辅助工具，真是竞争激烈啊。
说实话，在五月之前，我觉得使用AI编程工具还是有点难度的。虽然有了自定义规则、Agent和MCP的概念，但操作起来真的挺麻烦的，整体感觉就像在随意编程。Karpathy发明的“氛围编程”真是个绝妙的描述，他形象地道出了用AI编程的体验。有时候，使用AI工具真的是碰运气，运气好时，它能给你带来意想不到的惊喜，但有时它就像个顽皮的小孩，把你的项目搞得一团糟。
在工具不够强大的时候，想要用好它，得投入不少时间。而且，我也感到软件的开发还是需要我们自己去掌控，这样才能有成就感。不过，到了九月份，我发现情况有了很大变化，各种工具的智能化程度大幅提升，Agent的能力也变得强大，设置规则的必要性降低了，基于SPEC驱动的开发方式也逐渐流行，使用YOLO模式运行也愈加顺畅。感觉AI编程工具越来越聪明，自己干预的情况越来越少，这让我既兴奋又有些不安，似乎软件行业真的可能面临巨大的挑战。
十月的时候，硅谷发生了大规模裁员，真让人震惊。被裁的人都是名校毕业、热门专业、在大公司工作的精英，现在这样的路越来越难走了。还有消息传出，美国顶尖名校的计算机专业毕业生找工作也变得困难。或许软件行业的日子真的不多了，但愿这一切不会成真，毕竟我在这个行业已经平安度过了二十多年。不过，若要实现AGI，软件行业必然是首个突破的领域，因为其逻辑性最强，基于符号系统。如果连软件行业都解决不了，AGI又如何实现呢？这让我暗自希望软件行业能早日突破，心里真是矛盾。
无论如何，回到规范驱动开发上来吧，毕竟在现阶段的AI编程工具中，它已经逐渐成为主流。我最近接触的主要是spec-kit和OpenSpec这两个工具。为啥要引入规范驱动开发呢？我觉得这主要是因为目前大模型的能力决定的。现在的AI辅助软件开发工具（Agent）主要是将用户的输入结合自身的整理形成提示词发给大模型，之后通过多轮交互输出结果。用户能控制的只有输入，但这些输入有时候不够准确或不够清晰，导致结果的质量也参差不齐。
spec-kit和OpenSpec的出现，就是为了将用户的输入过程固定下来，把输入分成需求、设计、计划、执行等环节，每个环节都形成自己的文档，这样AI就可以根据这些文档进行工作，甚至可以让AI先生成测试用例，再通过开发来实现这些用例，最终达到验收标准。这个过程中，实际上是在帮助用户细化需求和设计，AI也可以协助完成这些，最终生成的软件与用户需求的偏差会小很多。特别是在生成需求文档、设计文档和计划文档时，开发人员可以进行干预，修改这些文档。不管是手动修改，还是让AI来调整，目的就是通过这些清晰的文档，让AI更好地理解我们的需求、架构和验收标准，从而减少偏差。
在前期花点时间整理文档，后面就能省下很多返工的时间。别觉得审查文档很麻烦，现在可以借助不同的AI来帮忙审查。目前国产模型的进步也很快，大家都逐步达到Claude Sonet4以上的水平，而且价格比Anthropic便宜不少。比如GLM-4.6、Minmax M2和Kimi K2 thinking等。我通常用的工具有Claude code、Qwen CLI、iFlow CLI等，它们都能接入国产模型，互相校验也很方便。
特别值得一提的是Qoder的quest模式，这个是简化版的SPEC驱动开发，你输入需求，它生成SPEC，你审查后提出意见，接着它会进行多轮修改，最终形成SPEC并开始执行。想了解更多可以参考它的官方文档或B站的介绍。之所以称Qoder为简化版，是因为它还没有太好地区分各种SPEC，而是把它们融合在一起。
至于spec-kit和OpenSpec，B站上有很多介绍，我就不再赘述了。如果你想理解它们的理念，使用它们的命令只是第一步，最好能把它们的GitHub代码下载下来，看看有哪些模板，如何生成能够驱动各个Agent命令行的工具提示，搞清楚这些细节后，你将更深入地理解从需求到任务创建的过程。其实没有什么神秘的，只是不断与大模型互动，在它的帮助下生成软件开发所需的各种文档，最终让大模型根据这些文档生成符合预期的软件。链接参考：
https://github.com/github/spec-kit ，
https://github.com/Fission-AI/OpenSpec
网上有不少观点认为，Spec-Kit更适合从零开始的创新性工作，强调AI驱动的端到端实现，而OpenSpec则更适合现有系统的演进改进，强调结构化的变更管理和团队协作。选择哪个工具，主要还是看你的具体需求、项目阶段和团队环境。实际上，两者也可以结合使用：用Spec-Kit进行新功能的概念验证，再用OpenSpec进行生产环境的渐进式改进。我觉得这个观点很合理，从它们提供的命令就可以看出来，当然，还是建议去学习它们的git仓库，这样你的理解会更深。
Spec-Kit适合0→1的原因如下：
1. 设计哲学导向
– Spec-Kit的核心是“把规范变为可执行代码”，强调从概念直接生成完整实现。
– 工作流程从Constitution→Specify→Plan→Tasks→Implement，是一个完整的端到端创建过程。
2. 技术架构特点
– 基于Git分支管理，每个功能都是独立的分支。
– 单一规范文件夹结构，适合从头开始构建新功能。
– 强调AI驱动的多步精炼，适合创意探索和快速原型。
3. 实际应用场景
– 官方文档明确提到“0-to-1 Development(‘Greenfield’)”作为核心场景。
– 支持“Creative Exploration”和“Parallel implementations”。
– 实验目标包括“使用多种技术栈创建应用”。
OpenSpec适合1→n的原因：
1. 变更管理设计
– 双文件夹模型：openspec/specs/(当前SPEC)和openspec/changes/(提议更新)。
– 专门设计用于“修改现有行为”，特别是当更新跨越多个规范时。
– 强调“Brownfield-first”理念。
2. 企业级特性
– 结构化变更跟踪：提案、任务、规范增量生活在一起。
– 明确的审计轨迹和变更历史。
– 支持多团队协作的共享可见性。
3. 实际应用场景
– 官方明确表示“在0→1之外表现良好”。
– 专门解决“修改现有行为(1→n)”的挑战。
– 当“更新跨越多个规范”时表现出色。
Spec-Kit就像是“建筑师+施工队”：从零开始设计并建造全新的建筑。OpenSpec则像是“物业管理+改造团队”：在现有建筑基础上进行结构化改造。这种设计差异决定了它们各自最适合的场景：一个擅长从无到有的创造，另一个擅长在现有基础上的有序演进。
最后，规范驱动开发的核心价值在于提高AI辅助开发的可预测性和可控性。无论选择哪个工具，关键在于建立适合团队和项目的规范管理实践。
