AI Coding：屎山终结，优雅重现

2025-11-24
浙江
本文字数：3120 字
阅读完需：约 10 分钟

当下 LLM 已经解决“写代码容易”的时候，真正难题的只剩一件事：如何提升代码质量。SDD（规范驱动开发）把 Spec 变成唯一事实来源，把文档变成“可编译的源代码”，让开发者从 token 搬运工跃迁为逻辑决策者。用确定性的规范，驯服非确定性的算力。这才是 AI 时代开发者重新夺回掌控力的方式。

一、AI Coding 的本质与边界

在深入讨论如何使用 AI 编程之前，我们需要先祛魅。我们需要理解 LLM 是什么，以及它的边界在哪里。

1.1 LLM 的本质：强大，但不是万能

LLM 不是“理解机器”，而是高度优化的概率预测器。它擅长处理世界上已经出现过的模式——从 CRUD、API 胶水层、组件拼装到常规业务逻辑，都能做到近乎秒杀式的自动化。但它无法解决“未知的未知”：全新算法、完全没见过的业务规则、模糊概念界定等。

LLM 能让代码实现变得容易，却无法替你明确需求、定义边界或构建稳固的系统结构。

1.2 LLM 的真正价值：帮你干“工程的脏活累活”

软件工程中的复杂性问题分为 次要困难 和 根本困难 两类。

AI 能够极大的消除 次要困难：逆向文档、测试补全、大量模板生成、风险扫描与配置自动化，都能做到稳定、高效、不中断。它能显著减少人类的重复劳动，让开发者把精力集中在真正重要的地方：系统设计、业务建模、需求澄清。AI 是最强大的工程加速器，但不是替你思考的工程师。
AI 却无法解决 根本困难：对复杂业务概念的构思、对模糊需求的界定、对系统边界的划分。引入 AI 后，根本困难 对人的要求反而更高了——我们需要更清晰的问题定义能力。

1.3 从 Vibe Coding 到 Spec Coding：让 AI 从“快”变成“稳”

Vibe Coding 让开发启动更快，是原型时代的利器，但它有三个无法跨越的限制：

生成结果不稳定
上下文容易遗忘
隐藏技术债快速积累

要让 AI 真正走进生产环境，就必须从“靠感觉写代码”升级为“靠规范生成系统”。这正是 SDD（规范驱动开发）的价值：让 AI 按照可读、可控、可验证的规范执行，使代码结构稳定可靠。

1.4 SDD 核心理念：Spec 是唯一事实来源，代码是编译产物

在 SDD 模式中，Spec 不是注释，而是源代码本体。开发者通过 Spec 文档定义业务意图、数据结构、接口协议与测试标准，LLM 负责将 Spec 文档编译成具体实现。

这样可以彻底锁定上下文、保证逻辑一致性，并让所有决策透明化。SDD 把混乱的 Prompt 工程变成标准化的工程流水线，让团队协作更可控、更可扩展。

1.5 SDD 流水线：定义 → 计划 → 任务 → 实现

SDD 的流程如同一条清晰的编译管线：

Spec：写清楚“要什么”与“如何验证”；
Plan：AI 生成可执行的技术方案；
Tasks：拆解成原子的实现步骤；
Implement：AI 逐项生成代码并自动测试。

开发者从 Token 搬运工转变为逻辑决策者，AI 则成为执行引擎。

1.6 SDD 新问题

Spec Coding 解决问题，也产生了新问题

门槛高：强者更强，弱者更弱

规范考验的是开发者的架构与设计能力，让高手更容易发挥，但也让普通开发者更难入门，整体使用门槛被抬高。

灵活度低：难以适配不同任务场景

通常预设固定流程，面对从“小修一个 Bug”到“新增复杂功能”这种规模跨度大的任务时，往往显得不够灵活。

实际效率慢：大量时间花在查规范，而不是写代码

需要不断对照规范文档，审核流程繁琐，实际效率甚至可能低于直接评审代码，与敏捷开发强调“快速迭代、拥抱变化”的理念相冲突。

可控性弱：该放的时候不放，该收的时候又太死

AI 可能会漏掉关键细节，也可能“过度遵守规范”生成冗余代码；开发者仍需频繁介入调试与重构，代码依旧容易变成“功能堆砌”，长期维护成本高。

而这些问题之所以出现，本质原因在于：当下大多数 SDD 的落地，仍停留在“规范优先”这一早期阶段。

规范被写了，但并未真正成为工程体系的一部分，更无法对代码产生实质性的结构约束。

SDD（Specification-Driven Development）的实践需要经历三个阶段

① 规范优先（现阶段主流，但效果一般：Kiro/Spec-Kit/Open-Spec）

规范在开发前临时撰写，更多是对齐需求或输出一份“看起来专业”的文档。

任务完成后很可能被丢弃，既无法形成资产，也无法约束后续代码质量。

② 规范锚定（规范开始成为真实资产）

规范文档被视为长期维护的项目资产，会随着功能演进而同步更新。

其作用不再只是“开局对齐”，而是贯穿整个生命周期，成为团队协作的锚点（Anchor）。

③ 规范即代码（SDD 的最终形态）

开发者不再直接写代码，而是唯一编辑“规范”。

代码由 AI 基于规范自动生成，并且通常禁止人工随意修改，以确保结构一致性与可维护性。

此时规范具备了真正的“工程控制力”，而不是额外负担。

那有没有一款 SDD 产品，已经真正跨出了“规范优先”阶段，走向更高级的 SDD 解决方案？

二、MortiseAI “规范即代码”

MortiseAI 通过 Spec Doc + Spec Code 的方式，探索出一套 SDD “规范即代码” 的解决方案

2.1 Spec Doc - 规范文档

MortiseAI 采用 Agent 端到端生成模式，交互形式以工作流方式为核心，将 Spec 生成代码过程结构化、标准化、可视化，从而让复杂项目生成过程透明、可控、可持续迭代优化。

意味着开发者不仅能看到每一步的生成逻辑，还能随时介入与调整。让智能开发真正“看得见、改得动、越用越强”。

任务一键创建

流程自动规划

文档自动生成

代码稳定输出

2.2 Spec Code - 规范代码

MortiseAI 不只关注“代码怎么生成”，更关注“代码如何运行”。

因此，我们为规范文档设计了可一一对齐的规范代码框架，让规范真正成为代码结构的源头，从而迈向 SDD 的终极形态——“规范即代码”。

Mortise Spec Code Engine（MSCE）是一款为 Spec-Coding 而生的组件化代码框架引擎，它将复杂系统拆解为结构化的组件，并通过统一的事件机制实现组件间的高效通信，让 AI 能够在可控、可解释的框架中自动完成复杂软件项目的代码生成。

换句话说，MSCE 将“规范的结构”直接映射为“代码的结构”，让 AI 不再只是写代码，而是 按规范组装工程 —— 这是实现“规范即代码”的关键一步。

MortiseAI 将 MSCE 进行开源，旨在希望与开发者共同建设 SDD 的未来标准。

通过开放的组件体系、事件协议、规范格式以及参考工程结构，MortiseAI 希望推动一套 人人可用、AI 可执行、团队可协作 的 SDD 标准体系，让规范不再是文档，而成为整个软件生产链条的核心。共同打磨 “规范即代码” 的行业基础设施，让 AI 时代的工程体系具备真正的可解释性、可维护性与可演进性。