2026年AI编程新范式：“渐进式Spec“

前言

朋友们，如果你还在用2025年初那种"张嘴就来"的方式跟AI编程助手聊天，那你可能已经out了。

还记得今年初Andrej Karpathy大神带火的那个词吗？Vibe Coding（氛围编程）。说白了就是：你闭着眼睛把需求一股脑儿倒给AI，管它三七二十一，让AI自由发挥，你只管感受那种"代码如行云流水般涌出"的快感。这感觉就像是你去饭店，跟厨师说"随便炒两个拿手菜"，上来的菜确实能吃，甚至味道还不错——但如果你天天这么吃，顿顿这么吃，半年后你会发现自己得了胃溃疡，还欠了一屁股饭钱。

到了2026年，**“渐进式Spec”（Gradual Specification）**正在把整个AI编程圈子从这种"狂野西部"的状态拉回文明社会。这玩意儿不是什么高大上的学术概念，说白了就是：别急着让AI写代码，先让它把话说清楚，咱们一点点把规矩立起来。

从"口嗨"到"立字据"：为什么需要渐进式Spec

去年我用Claude Code帮朋友做了个小程序，一开始也是玩Vibe Coding。我说："给我做个带登录功能的博客系统。"AI刷刷刷写了几百行代码，跑得挺欢。然后我补了一句："哦对了，要用JWT做认证。"AI又刷刷刷改了一通。接着我又想起来："还得支持手机号验证码登录。"如此反复了十几次，代码已经变成了一团 spaghetti（意大利面条），我自己都看不懂了。

这就是Vibe Coding的致命伤：AI的上下文窗口再大，也经不起你这么反复横跳。你每新增一个需求，AI就得重新理解整个项目的意图，久而久之，代码里的架构就像是用橡皮泥搭的城堡——看着像那么回事，实则一碰就塌。

Y Combinator在2025年冬季批次中发现了一个惊人数据：25%的初创公司代码库有95%是AI生成的。听起来很美好对吧？但随之而来的就是**“技术债务大爆炸”**——代码能跑，但没人知道为什么这么写；功能能上线，但改个按钮颜色可能要牵一发而动全身。

渐进式Spec要解决的，就是**“意图漂移”**的问题。它强迫你在敲代码之前，先把"想要什么"说清楚、说完整、说到可执行、可验证的程度。就像你去装修房子，Vibe Coding是"师傅看着办"，而渐进式Spec是"先出设计图、再出施工图、最后才动工"——而且设计图还得经过你签字确认。

渐进式Spec的三重境界

现在的业界把渐进式Spec分成了三个段位，有点像武学里的"三重境界"：

第一重：Spec-First（先立规矩再动手）

这是入门级玩法。你不再直接跟AI说"给我写个支付功能"，而是先写一份requirements.md，把用户故事、验收标准、异常流程都列清楚。然后让AI基于这份Spec去生成技术方案和代码。

GitHub在2025年9月推出的Spec Kit就是干这个的。它提供了一套CLI工具，让你通过/speckit.specify这样的命令把需求转化成结构化的规格说明。这时候的Spec还是个"指导手册"，代码仍是主要交付物，但AI的发挥空间被限制在了你画的框框里。

第二重：Spec-Anchored（以Spec为锚点）

到了这一层，Spec不再是一次性的文档，而是持续演进的活物。Amazon在2025年7月发布的Kiro就是这方面的代表作。它强制要求项目根目录下有三份文件：

• requirements.md：业务需求，用EARS（Easy Approach to Requirements Syntax）格式书写
• design.md：技术架构设计
• tasks.md：拆解后的可执行任务清单

Kiro的聪明之处在于它的**渐进式索引（Progressive Indexing）**机制——它不会一股脑儿把所有文档塞进AI的上下文窗口，而是像查字典一样，AI需要啥才读啥。这就好比你去图书馆找书，管理员不会把所有书都堆你面前，而是先给你个目录，你指哪本他才拿哪本。

Delta航空公司在2025年用Kiro搞了个项目，结果实现了1948%的效率增长。你没看错，是将近20倍。他们的秘诀就是：业务人员可以直接在Spec层面跟技术团队对话，产品经理改需求只需要改requirements.md，AI会自动同步到代码实现。

第三重：Spec-as-Source（规格即源码）

这是最激进的玩法，代表产品是Tessl（由Snyk创始人Guy Podjarny创办，融资1.25亿美元，估值超5亿刀）。在这个模式下，人类只维护Spec文件，代码完全是AI生成的副产品，甚至会在生成的代码顶部标注：// GENERATED FROM SPEC - DO NOT EDIT（根据规格生成，请勿手动修改）。

Tessl搞了个Spec Registry，里面有超过10,000个开源库的规格定义。这就好比Maven Central或者npm，但存的不是代码包，而是"API行为契约"。以后你让AI调用第三方库，它不会再瞎蒙API用法，而是去查官方的Spec，准确率直接拉满。

工具选型：现在能用的三板斧

说一千道一万，咱们手头上现在能用的工具有哪些呢？

• 如果你是GitHub Copilot重度用户：直接上GitHub Spec Kit。它支持Claude Code、Copilot、Gemini CLI、Cursor等主流AI助手。通过uvx --from git+https://github.com/github/spec-kit.git specify init就能初始化项目。它的优势是"无侵入"——你可以在一个已有项目中渐进式地引入Spec，不需要推倒重来。
• 如果你喜欢开箱即用：试试Amazon Kiro。它本质上是个VS Code的分支，自带20万token的上下文窗口（是普通IDE的10倍）。不过它是按交互次数收费的，免费版每月50次交互，Pro版19刀/月给1000次。适合那种从零开始的新项目，或者需要业务人员深度参与的场景。
• 如果你是架构控：Tessl值得观望。虽然它现在主要还是面向早期采用者，但其"Spec-as-Source"的理念代表了终局形态。它通过MCP（Model Context Protocol）协议跟各种AI助手集成，可以把你的架构约束（比如"所有API必须做输入验证"、“禁止直接拼接SQL”）固化成Constitutional Rules（宪法级规则），AI一旦违反直接报错。

开发者的新角色：从码农到架构师

渐进式Spec的流行，意味着咱们程序员的工作内容要发生根本性转变。

以前咱们80%时间在写CRUD、调API、修Bug，20%时间在思考架构。现在AI把写代码的活儿接过去了，咱们的核心价值变成了**“定规矩”**——写Spec就是在定规矩，审Spec就是在把控质量。

Anthropic在2025年底发布的Claude 4.5家族（包括Haiku 4.5、Sonnet 4.5、Opus 4.5），已经把SWE-bench Verified的基准测试刷到了80.9%。这意味着AI写代码的能力已经超过了绝大多数初级程序员。但它仍然需要你告诉它：应该写什么、不能碰哪些红线、业务上的优先级是什么。

这就像是从"泥瓦匠"变成了"建筑设计师"。泥瓦匠的活计AI干得更又快又好，但设计师的审美和功能规划还得靠人脑。而且，越是复杂的系统，越需要人类在Spec层面做权衡和决策。

写在最后

2026年不是AI取代程序员的一年，而是**"野生AI编程"向"工程化AI编程"转型**的一年。渐进式Spec就是这个转型的核心方法论。

咱们回顾一下软件工程的发展史：从汇编到高级语言是一次抽象，从瀑布模型到敏捷开发是一次抽象，从手写代码到AI生成代码又是一次抽象。而渐进式Spec，正是在AI生成代码之上的元抽象——咱们不再直接操作代码，而是操作"生成代码的意图"。

如果你今天只记住一句话，那就是：别让AI急着写代码，先让它把话说清楚，咱们一点点确认，这叫渐进式Spec。

下次再开新项目，别急着打开IDE敲代码了。先建个spec.md，把需求捋清楚。你会发现，AI还是那个AI，但它突然变得"懂事"了许多——因为它终于知道你想要什么了。

这才是2026年AI编程该有的样子。不是魔法，不是玄学，而是有章法的工程实践。

朋友们，你们准备好从Vibe Coding的狂野时代，迈进渐进式Spec的文明社会了吗？

目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。