语义驱动时代的软件工程：MiniSpec 与 SACC 的五层模型
语义驱动时代的软件工程：MiniSpec 与 SACC 的五层模型🔗
软件工程师一直有一个梦想 —— 仅通过清晰的结构化文档，就能生成整个系统的代码、测试与部署脚本。
而这个梦想，正在「语义驱动开发」的浪潮下成真。
本文是该系列的第一篇，我们将深入介绍什么是 MiniSpec DSL，以及它背后的 SACC 五层语义模型，如何重构我们对工程语言、上下文与 AI 的理解方式。
软件工程师的终极梦想：从 UML 到 AI-native DSL🔗
在过去数十年中，UML 曾被视为实现自动化开发的希望：以图形化的方式描述系统设计，理论上可以生成代码。但最终它在工程实践中失败了。
为什么？
- 语义模糊，图像与代码不一致
- 缺乏语法约束，难以维护
- 不利于版本控制与协作
如今，随着 AI 大模型的出现，「Prompt Engineering」再度点燃了自动化生成的希望。然而，它同样面临：
- 无结构、不可控
- 幻觉、错误率高
- 不易团队共建
这两者的教训是明确的：我们需要一种新的语言层，来清晰描述工程意图与上下文。
这就是 MiniSpec DSL 的诞生背景。
MiniSpec 是什么？🔗
MiniSpec（Minimal Specification）是一种语义驱动开发语法，旨在让工程意图可以被 AI 与人类共同理解并映射为可执行产物。
它不取代编程语言，而是站在编程语言之上，提供一种统一、清晰、可生成的语义描述。
其设计原则包括：
| 准则 | 描述 |
|---|---|
| ✅ 可读性 | 人类工程师能轻松理解 |
| ✅ 可结构化 | JSON/YAML 表达，方便 LLM parsing |
| ✅ 上下文与意图分离 | context 与 spec 分开，清楚界定语义边界 |
| ✅ 可映射到行动 | 每个 spec 都可映射为一个 agent 任务 |
| ✅ 模块化 | 适合各种场景：test、infra、deploy、api doc、prompt |
MiniSpec 语法示例🔗
version: "0.1"
context:
env: "staging"
user_role: "admin"
feature_flag: "beta"
git_branch: "feature/signup"
runtime: "Node.js 18"
spec:
goal: "建立新的用户注册流程"
entities:
- name: "User"
attributes:
- email
- password
- is_verified
behavior:
- "注册完成后寄出验证信"
- "email 必须唯一"
- "password 长度需大于 8"
test:
- "应该可以成功注册"
- "email 重复应该报错"
- "密码太短应该拒绝"
infra:
deploy_target: "AWS Lambda"
scaling: "auto"
database: "PostgreSQL"
对应应用输出🔗
| 类型 | LLM 可生成 |
|---|---|
| ✅ 测试码 | RSpec / Jest / Pytest |
| ✅ Infra Code | Terraform / Pulumi |
| ✅ API 文档 | Swagger / OpenAPI |
| ✅ Prompt | Function schema / Assistant |
| ✅ DevOps | GitHub Action / CI pipeline |
| ✅ 文档 | README.md / Spec文档 |
| ✅ UI 输出 | Figma DSL / HTML prototype |
| ✅ scaffolding | model/controller/service |
SACC 五层语义模型🔗
基于对 AI 与代码交互的深入理解，我们提出了 SACC（Spec and Context as Code）五层模型：
层级架构🔗
| 层级 | 名称 | 功能定位 | 类比 |
|---|---|---|---|
| L1 | Symbolic Layer | 最底层：语言符号、token、位元流 | 类似 OSI 的物理层/数据层 |
| L2 | Instruction Layer | 基本语法 + API 调用 + 控制结构（如 if/else、function） | 类似 OSI 的网络/传输层 |
| L3 | Intent Layer | 用户的明确意图，如「为这段程序代码写测试」 | 类似 OSI 的会话层 |
| L4 | Context Layer | 任务背景、对话历史、角色设定、先前知识 | 类似 OSI 的展示层 |
| L5 | Specification Layer | 任务标准、业务规格、约束条件、meta-goals | 类似 OSI 的应用层 |
每层的具体解析🔗
L1. Symbolic Layer — LLM 接收与处理的语言原子
- 所有语言处理都是从符号开始：token、字符、字符串、操作码
- 对应：Tokenizer, Embeddings, Binary Instructions, Assembly
- 示例：字符串 "def"、token ##ing，或嵌入向量 [0.82, -0.12, ...]
L2. Instruction Layer — 程序行为的语法结构
- 函数、条件语句、API 调用，是执行层级的基本单位
- AI 对这层的理解是行为模拟的关键（像 Copilot 那样补 code）
- 示例：for, return, fetch('/api'), assert, 等语法节点
L3. Intent Layer — 人类「想做什么」的具体意图
- 这是 prompt 的核心层次，例如：「请根据这个 API 自动生成测试程序代码」
- LLM 根据意图来规划接下来的程序产出
- 类似于函数的「调用」，但更语义化、更模糊
L4. Context Layer — 上下文为王的 AI 理解之源
- 这层是 LLM 的「短期记忆」与「语境理解」
- 包括之前的对话内容、角色假设、输入方式、prompt history
- 若缺 context，AI 容易 hallucinate 或误解任务
✅ 在这一层，我们首创提出：Spec/Context as Code Spec/Context 决定行为，就像 Code 决定输出。
L5. Specification Layer — 语义与逻辑的元指令层
- 像软件规格书一样，描述任务「应该完成什么」，以及其边界
- 可能来自：Product spec、Swagger、User story、设计图
- 这层不直接出现在输入，但决定最终产出是否正确
为什么要有这样一个模型？🔗
✅ 1. 明确划分 AI 的任务「思考层级」🔗
- AI 对 prompt 的理解不是单纯文字匹配，而是跨越语义结构
- 建立这个分层有助于打造更稳定、可控的 AI 行为模型
✅ 2. 帮助我们设计更精准的 Prompt Flow🔗
- 你可以在 Intent 层调整 prompt 语气与命令结构
- 在 Context 层设计输入流程与上下文控制策略
- 在 Specification 层用 DSL（如 JSON schema）来明确限制生成行为
✅ 3. 让 AI「可编程」，不是只靠模糊对话🔗
- 将语境当作程序代码（Spec/Context as Code），我们可以：
- 版本控制 context
- 单元测试不同语境产出的差异
- 形成「语境脚本库」：每一个 prompt context 都是可复用逻辑模块
MiniSpec 与 Prompt Engineering 的差异🔗
| 维度 | Prompt Engineering | MiniSpec DSL |
|---|---|---|
| 可复现性 | ❌ 较差，输入稍变输出完全不同 | ✅ 高，可控输出 |
| 可测试性 | ❌ 难以写单元测试 | ✅ 可生成 test case |
| 团队共识 | ❌ 靠个人技巧 | ✅ DSL + Schema |
| 多模块协作 | ❌ 难与 CI/CD 整合 | ✅ 可与 GitHub Workflow 整合 |
| 多场景扩展 | ⚠️ 需要大量 prompt 编写 | ✅ 自然扩展到 Infra / UI / API Doc 等 |
展望：构建 AI-native 工程生态🔗
我们的目标不仅是 MiniSpec，而是一整套语义驱动开发的生态：
- ✅ MiniSpec DSL 与 Playground
- ✅ VSCode Extension 与 GitHub Workflow 整合
- ✅ DevOps + OpenAPI + Prompt 多场景支持
- ✅ 开放规范 + 100 篇教学文章
我们称之为：SACC（Spec and Context as Code）
结语：一个时代的开端🔗
这不是「又一种 YAML DSL」，而是一种认知方式的升级。
工程的本质是语义对齐。
而我们要做的，是提供一种既给人写、又给 AI 理解的语言，让语义不再隐藏在代码背后，而是成为驱动一切的第一层。
这，就是语义驱动开发（Semantic-first Engineering）。
本文是 SACC 系列的第一篇，后续将深入探讨语义驱动开发的各种实践和应用场景。