AI Spec Coding:一场用Markdown堆砌的「巴别塔」幻梦

新闻

作者：微信文章

没有自律的自由不是自由，那是作死。同样，没有工程约束的 Spec Coding，不过是用一种更高级的方式在生产「屎山」。

AI Spec Coding 被吹捧为「编码的终结」，仿佛写几行 Markdown 就能让 AI 自动盖楼。这玩意儿在绿地项目里是神器，但在复杂的工业现实中，它可能正在制造一种新型的「语义债务」。咱们聊聊为什么非结构化的文档撑不起严谨的工程，以及为什么 DDD（领域驱动设计）才是 AI 时代的救命稻草。

⭐点击『极客精益』→ 右上角『...』→ 设为星标，别让算法把咱们走散了。觉得扎心就点个赞👍，有共鸣就转给你的 CTO 看看🔄。

---

01. 深夜的崩溃与「代码消失」的诱惑

说实话，谁没做过「不写代码」的梦呢？

大概从 2024 年底开始，技术圈就弥漫着一股躁动。大家都在传：以后不用写代码了，写 Spec（规范）就行。你只要用自然语言写个 spec.md，告诉 AI 「我要一个电商后台，带 RBAC 权限」，啪的一下，代码就生成了。

听起来是不是特性感？

这叫 AI Spec Coding （规范驱动编程）。如果你看过 GitHub Spec Kit 或者 Tessl 的宣传片，你会被那种「上帝造物」般的快感冲昏头脑。它们承诺倒置开发流程： 人类只维护文档（意图），AI 负责实现（细节） 。




学术界和工程界甚至一本正经地把这分成了三个境界，听着特唬人：

1. Spec-First（规范优先） ：先写文档，再生成代码。这是目前最正常、也最像人的做法。2. Spec-Anchored（规范锚定） ：文档和代码同步更新，文档是锚点。这是理想主义者，试图让文档永远「保鲜」。3. Spec-as-Source（规范即源码） ： 代码是垃圾，文档才是源码 。你只改文档，代码全靠编译。这是疯子，或者天才，反正目前还没几个人能真正落地。

刚开始前几个月，我也上头过。在做一个新的 SaaS 原型时，我试着只写 Markdown。前两周，简直是飞一样的感觉，我要什么有什么，效率提升了起码 3 倍。

但到了第三周，噩梦开始了。


深夜编程的绝望02. 当「文档」变成了一种新型高利贷

咱们搞技术的都知道，天下没有免费的午餐。AI Spec Coding 省下的敲代码时间，其实都暗中标好了价格。这个价格，就叫 Spec Debt（规范债务） 。
规范漂移：两条腿走路的尴尬

当你把项目做大，业务逻辑变复杂，你会发现一个要命的问题： 文档和代码，永远在打架。

为了赶进度，你偷偷改了一行代码修 Bug，没更新 Spec。哪怕就一次。
下次你再让 AI 基于 Spec 生成代码时，AI 会一本正经地把那个 Bug 又给你写回来了。因为它读的是「旧约全书」，而你已经生活在「新约」时代了。

这就陷入了所谓的「双重维护地狱」。你以前只需要 Review 代码，现在好了，你得 Review 那些冗长的、充满伪代码的 Markdown，还得 Review 生成出来的代码。

说白了，你不仅没少干活，还多请了一位需要你伺候的「文档大爷」。

我的观点：Spec Coding 在复杂项目的回报率会呈现出「反 J 曲线」：在项目初期（绿地项目），效率是起飞的；但一旦进入维护期（棕地项目），由于维护 Spec 的成本激增，效率会迅速掉坑里，甚至比直接写代码还慢。但它比非 Spec Coding 的纯 Vibe Coding 的回报率要高。


生产力的J曲线沙滩上的摩天大楼

这就触及到了问题的本质， Markdown 本身就是个烂地基 。

很多推崇 Spec Coding 的人忽略了一个常识： 自然语言（Natural Language）天生是随机的、模糊的、不确定的。

你写一句：「用户下单后，如果库存不足，提示错误。」
AI A 可能会抛出一个 Exception。
AI B 可能会返回一个 HTTP 400。
AI C 可能会在前端弹个窗，后端啥也不干。

你想用这种非结构化的、软绵绵的自然语言，去约束逻辑严密、容不得半点沙子的软件工程？这就像是用沙子堆摩天大楼。 文档越大，上下文（Context）越长，AI 的幻觉就越严重。 它会开始瞎编乱造，而你查错的时候，既要查代码逻辑，又要去查那几千行的 Markdown 到底哪句话误导了它。

这就是 语义债务（Semantic Debt） 。这不是进步，这是在制造混乱。


Spec漂移循环示意图03. 别被「低代码」的鬼话忽悠了

现在市面上很多 AI 编程工具（比如 Bolt.new, Windsurf 里的某些模式），走的是「低代码」的路子，从 UI 或者 API 接口倒推实现。

作为一个写了十几年以上代码的Coding Guy，我得泼盆冷水： 凡是从易腐层（UI/Interface）开始构建的系统，最后都得塌。

为什么？因为 UI 是变得最快的，接口是随业务调整的。它们是皮毛，不是骨架。

真正稳固的系统，必须建立在 数据模型（Data Model） 和 领域逻辑（Domain Logic） 之上。这也就是为什么我一直推崇 DDD（领域驱动设计） 。

Spec Coding 如果想活下去，绝对不能是「我描述一个页面，你给我生成代码」。
它应该是：

1. 我定义 领域模型 （实体、值对象、聚合根）。2. 我定义 业务规则 （政策、流程）。3. AI 帮我生成基础设施代码（数据库映射、API 路由、DTO 转换）。

遗憾的是，现在的 Spec 文档大多是一堆描述性的废话，而不是结构化的领域模型。 用 Markdown 写复杂的业务逻辑，本身就是一种行为艺术。 你试过用文字描述一个嵌套了三层的 if-else 循环吗？写出来比代码还难懂。（同样，我认为低代码平台的可视化if-else、loop等方式也比写代码更复杂、更低效。）
04. 理性的回归：80% 的机器与 20% 的灵魂

骂了半天，是不是 Spec Coding 就一无是处？
那倒也不是。

技术这东西，别看广告，看疗效。我们在团队里折腾了几个月，总结出了一套「防坑指南」。
1. 放弃「全自动」的幻想

别指望 AI 能把 100% 的代码都给你写了。 理性的比例是 80/20。
那 80% 的 CRUD、样板代码、单元测试、转换逻辑，交给 AI，交给 Spec 驱动。
剩下那 20% 的 核心业务逻辑、复杂的并发处理、微妙的性能调优 ，必须人来写，或者至少是人带着 AI 写。
2. 结构化大于自然语言

别再迷信纯 Markdown 了。咱们现在尝试引入更「硬」的约束。

• 用 OpenAPI、Swagger 等定义接口契约（这是硬指标，AI 不敢乱来）。• 用 Gherkin（Given/When/Then） 写测试用例（测试即文档，这才是活的 Spec）。• 严禁 在 Spec 里写伪代码。Spec 只描述「是什么（What）」和「为什么（Why）」，绝对不要试图去描述「怎么做（How）」。

3. 多 Agent 的分工协作

一个通用的 AI 就像一个全能但平庸的实习生。
要想搞定复杂系统，你得组建一个「AI 团队」。

• Agent A（产品经理） ：把你的胡言乱语转化成结构化的需求。• Agent B（架构师） ：基于需求设计数据模型。• Agent C（搬砖工） ：生成代码。• Agent D（质检员） ：写测试代码来怼 Agent C。• ...还有更多Agents，但 Agents 不是越多越好。

这听起来很复杂？对， 工程化从来就不简单。 企图用一个 Prompt 解决软件工程问题，那是天方夜谭。


Agent集群协作示意图05. 写在最后：程序员的「死亡」与「新生」

回到最初的问题：AI Spec Coding 是未来吗？

如果是指「写文档就能自动生成完美软件」，那它是骗局，是「瀑布开发模式」的借尸还魂。
但如果是指「 通过更高层级的抽象约束，让 AI 处理繁琐细节 」，那它是必然的趋势。

在这个时代，程序员的价值正在发生剧烈的位移。

以前，你的价值是你懂 QuickSort 等算法怎么写，懂 React、Spring 等框架的生命周期，以及更多的技术知识。

以后，你的价值在于：

1. 品味 ：你能分辨什么是好的设计，什么是垃圾。2. 共情 ：你能理解业务真正的痛点，而不是客户嘴上的需求。3. 系统论 ：你能驾驭复杂的 Agent 协作网络，而不是陷入单点逻辑。

所以，别把 Markdown 当作救世主。它只是另一块砖。
真正决定大楼是否稳固的，依然是你脑子里的那个架构图，和你对这个世界真实的理解。

兄弟们，夜深了。文档该写还得写，但别忘了，偶尔也得跳出那些该死的文本框，看看窗外的万家灯火。那才是真实的「Spec」。

---

读者互动：
这篇「反调」文章，不知道有没有戳中你的痛点？或者你已经在 Spec Coding 的路上踩出了什么新坑？
咱们评论区见，哪怕是来骂我「老古董」的，我也给你置顶。
👋


极客精益社区
延伸阅读：

1. Spec-Driven Development: The Waterfall Strikes Back[1] - [推荐理由：这老哥比我骂得还狠，直接说这就是瀑布流的诈尸，读完极度舒适。]2. The Limits of Spec-Driven Development[2] - [推荐理由：深度剖析了为什么 Spec 永远赶不上现实的变化，非常理性的分析。]3. Spec-Driven Development: From Code to Contract[3] - [推荐理由：如果你想看点学术界的严谨分类，这篇论文把 Spec 的三种形态讲透了。]

相关标签：
#AISpecCoding #软件架构 #DDD #技术反思 #Cursor
引用链接

[1] Spec-Driven Development: The Waterfall Strikes Back: https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html
[2] The Limits of Spec-Driven Development: https://isoform.ai/blog/the-limits-of-spec-driven-development
[3] Spec-Driven Development: From Code to Contract: https://arxiv.org/html/2602.00180v1