现在不管是个人开发者还是团队，基本都在用 AI 写代码。Cursor、Copilot 一开，代码确实敲得飞快。但我相信很多人都有这种体感：AI 写代码一时爽，收尾火葬场。单模块生成速度确实翻倍了，但返工、改规范、修隐藏 Bug、补测试的时间，反而把效率全部吞回去，最后攒了一堆擦不干净的技术债务。 日常开发里这些问题应该特别普遍：AI 写的代码风格随心所欲，架构分层乱套，完全不贴合团队既定规范；单看这一段代码好像能跑，一合并进项目就爆兼容问题、逻辑漏洞；需求一改，AI 就重新瞎写一通，重复代码、冗余逻辑满天飞，经常改一行代码，整个功能直接崩；团队所有人都用 AI，但每个人产出的代码质量参差不齐，根本没法统一管控。行业里把这种靠感觉、无约束的 AI 开发方式，叫做 Vibe Coding（氛围编程）。看着进度飞快，实则隐患满满、完全不可控，根本撑不起企业级的迭代交付。 踩了很多坑之后我才发现，AI 编码的问题根本不是「写得太慢」，而是没有标准、没有流程、没有校验闭环。AI 只会根据字面意思生成代码，看不懂团队的架构设计，读不懂业务约束，更不会主动遵守工程规范。想让 AI 真正帮我们提效，而不是添乱，唯一的解法就是用工程化思维，把 AI 的编码行为彻底框起来。 这篇文章就结合我真实落地的经验，聊聊 SDD 规范驱动开发 + Harness 工程约束 这套组合打法。手把手讲清楚怎么搭一套能落地、能管控、能持续迭代的 AI 工程化开发体系，把 AI 从「随便写代码的工具」，变成「按规范写工程的得力助手」，真正实现个人提效、团队统一、交付稳定。

Vibe Coding

Vibe Coding的特征和面临的问题

vibe Coding(氛围编程)核心思想：开发者通过自然语言与AI进行对话式交互，依赖AI的理解能力来生成代码，而非逐行手写代码。

Vibe Coding六大核心特征

• 意图驱动：描述"做什么"而非“怎么做”
• 对话式交互：自然语言作为编程接口
• 迭代逼近：多轮对话逐步完善
• 审阅者心态：审代码、不写代码
• 指数级加速：项目启动和原型验证极快
• 容错包容：接受不完美、快速迭代修正

当前Vibe Coding面临的核心痛点

• 输出质量不稳定：相同prompt不同时间生成的代码差异大，难以复现优质结果。
• 缺乏规范约束：没有统一的代码标准和架构约束，导致代码混乱，难以维护。
• 团队协作困难：每个人与AI的交互方式不同，产生风格迥异，难以整合。
• 知识传递断裂：对话式编程上下文难以沉淀，新成员难以理解项目决策逻辑。

这些问题不在于AI不够聪明，而在于我们缺乏一套系统的方法来约束和引导AI的输出。

SDD是什么？（Spec-Driven Development）

SDD: 规范驱动开发

SDD（Spec-Driven Development）是一种以规范文档（Spec）为核心驱动力的AI 辅助开发方法论。它通过预先定义清晰、结构化的技术规范文档，来约束和引导AI 的代码生成过程。

SDD的本质是将传统软件工程中的"设计先行"原则与AI编程相结合，用文档化的规 范取代模糊的口头描述，让AI真正理解开发者的意图。

SDD核心工作流

1. 需求分析：明确功能需求与技术约束
2. Spec文档编写：API Spec/数据模型/UI规范/测试Spec
3. AI驱动代码生成：基于Spec约束生成高质量代码
4. Spec Review与验证：自动化质量检验与人工审查
5. 迭代优化：持续完善Spec,提升输出质量

SDD 能解决什么？解决不了什么？

SDD 能解决的问题：

• 代码质量一致性：通过Spec规范约束AI输出，确保代码风格、架构模式的统一。
• 需求到代码的精确传递：结构化Spec消除自然语言歧义，减少AI"误解"。
• 团队协作标准化：统一Spec模板让团队用一致方式与AI交互。
• 知识沉淀与复用：Spec文档是项目知识的结构化载体。
• 质量可追溯：每段代码有对应Spec，出问题可追溯源头

SDD解决不了的问题：

• AI模型能力上限：模型本身不支持某种范式，Spec再好也无能为力
• 创意和直觉决策：产品方向、UX设计等需要人类创造力的领域
• 复杂架构决策：技术选型、系统架构等仍需资深工程师判断
• SDD的边界认知：SDD是方法论层面的解决方案，规范"如何与AI协作"，而非"AI本身能力"。需配合Harness实现工程级落地。

Harness Engineering是什么？

Harness Engineering：工程护栏体系

Harness Engineering（驾驭工程）是一种为AI编程建立自动化约束和质量 保障机制的工程方法。它像高速公路的护栏一样，确保AI编程在正确的轨 道上高速运行。

Harness Engineering的核心价值在于：将人工的代码审查、规范检查、质 量验收等流程自动化，让AI编程的输出始终符合工程标准。

Harness Engineering的六大核心能力

1. 代码规范自动约束：自动检查代码风格、命名规范、目录结构是否符合团队标准

   示例：自动拒绝不符合命名规范的PR

2. 架构一致性守护：确保AI生成的代码符合预定的架构模式，防止架构腐化

   示例：限制跨层调用、强制依赖注入

3. 自动化测试集成：AI生成代码后自动触发单元测试、集成测试验证

   示例：代码生成后自动运行测试套件

4. 文档体系管理：结构化的文档目录和模板管理，确保知识沉淀

   示例：.harness目录下的规范文件体系

5. 协作流程规范化：定义团队成员与AI协作的标准流程和交互模式

   示例：Spec编写→Review→生成→验收

6. 质量度量与反馈：持续收集代码质量数据，优化Spec模板和约束规则

   示例：自动生成代码质量报告和趋势分析

Harness Engineering：三层护栏

1. 约定层 Convention

   告诉 AI "我们团队的规矩" .cursorrules + .kiro/steering/技术栈约定

2. 自动化层 Automation

   让机器自动检查 Pre-commit Hook + ESLint Prettier + CI 安全扫描

3. 验证层 Validation

   最终确认达标 自动化测试 + AI Code Review 对照 Spec 验收标准逐条检查

SDD+Harness如何让Vibe Coding走向工程化？

在Vibe Coding小节中我们说了Vibe Coding当前面临的问题，SDD+Harness可以解决这些问题

• 输出质量不稳定：SDD 解决 -> Spec规范约束AI输出范围和标准
• 缺乏规范约束：Harness 解决 -> 自动化护栏检查代码合规性
• 团队协作困难：SDD+Harness -> 统一的Spec模版+协作流程规范
• 知识传递断裂：SDD解决 -> Spec文档即知识沉淀载体

工程化公式：SDD（规范输入）+ Harness（自动约束）= 可控的、高质量的AI编程体验

完整方程式与五步工作流工程化

Vibe Coding = 需求对话 → Spec生成 → 代码实现→护栏检查→验收对照

SDD 工具全景对比

SDD生态核心工具

• Harness:结构化文档+工程护栏+自动化约束
• Superpowers:轻量级AI增强，个人快速原型
• Spec-kit:专注Spec文档管理与协作
• get-Shit-Done:极简主义风格，快速迭代交付
• Kiro: AWS推出的AI IDE，内置Spec驱动
• openSpec:专注API接口定义的规范标准

Harness — 企业级全栈工程方案

Harness定位于企业级全栈项目的SDD落地工具，提供从文档管理到代码约束的完整工程化 解决方案。

结构化文档体系: 提供标准化的.harness目录结构，包含规则定义、架构约束、编码标准等完整配置

工程护栏机制: 自动化的代码规范检查、架构一致性验证、依赖关系管理

自动化约束规则: 可配置的约束规则引擎，支持自定义检查项和验收标准

团队协作规范: 定义团队成员间的AI协作流程、Spec Review机制

Superpowers — AI 从实习生变高工

Superpowers定位于个人开发者和小型项目的轻量级AI增强工具，注重快速上手和敏捷迭代。

轻量级配置：极简的配置文件，几分钟即可开始使用，无需复杂的初始化流程

AI能力增强：通过简洁的指令系统增强AI的代码生成能力，提供上下文注入机制

快速迭代支持：支持频繁的原型迭代和实验性开发，不强制严格的规范约束

灵活的规则定义：可选择性地启用约束规则，按需配置而非全量覆盖

Spec-kit — GitHub 官方出品

get-Shit-Done极简主义风格

追求最小配置、最快启动，"能用就行"的实用主义哲学。

极简配置:单文件配置，零学习成本，即装即用

结果导向:不追求完美规范，聚焦于快速产出可用代码

灵活适配:适配各种AI编程工具，无供应商锁定

适用场景:

• 追求极致效率的独立开发者
• 需要快速交付的紧急项目
• 对规范要求不高的原型阶段

Kiro

Amazon Web Services推出的AI原生IDE，内置Spec驱动开发流程，紧密集成AWS生态。

IDE级别集成: Spec驱动流程深度集成到IDE工作流中，无需外部工具切换

AWS生态绑定: 与AWS云服务深度集成，适合AWS技术栈项目

内置Spec模板: 提供AWS最佳实践的Spec模板库

适用场景:

• AWS技术栈项目
• 希望IDE内置SDD能力的团队
• 已深度使用AWS服务的企业

openSpec

openSpec：API接口规范专注于API接口定义的开放规范标准，为API优先的开发模式提供结构化描述能力。

API优先: 以API契约为核心驱动前后端并行开发

标准化格式: 提供统一的API描述格式，支持自动代码生成

生态兼容: 兼容OpenAPI/Swagger生态，丰富的工具链支持

适用场景:

• API密集型应用开发
• 前后端分离架构的团队
• 需要API文档自动化的项目

SDD工具核心功能与使用场景

按项目类型选择工具组合:

1. 企业级全栈项目

多人协作、长期维护、严格质量保障 Harness + openSpec + Spec-kit

2. 快速原型验证

个人或小团队快速验证产品想法 Superpowers / get-Shit-Done

3. API密集型微服务

前后端分离、多服务接口约定 openSpec + Harness AWS云原生项目

4. 深度使用AWS、云端开发环境

Kiro + openSpec

5. 从零到一创业项目

早期MVP轻量，成长后迁移 Superpowers → Harness

SDD工具核心功能深度解析

六大核心功能模块:

1. Spec文档自动生成: 根据需求自动生成结构化Spec模板 Harness / openSpec
2. 代码约束验证: 自动检查AI代码是否符合预定规范 Harness
3. 文档版本管理: Spec文档版本控制、变更追踪 Spec-kit
4. 协作Review流程: 多人Spec审查、评论、批准管理 Spec-kit / Harness
5. AI上下文注入: 自动将Spec和规则注入AI上下文 Superpowers / Harness
6. 质量度量报告: 代码质量、约束通过率数据报告 Harness

Harness+openSpec+superPower

/opsx 指令链路——需求驱动开发的四步工作流

/opsx:explore --> /opsx:propose --> /opsx:apply --> /opsx:archive

1. /opsx:explore: 探索现状

   扫描docs/+knowledge/

   定位已有/缺失/过期

   输出"信息版图报告"

   类比：医生全面体检

2. /opsx:propose: 方案提议

   基于explore生成实施计划

   需新建/更新哪些Spec

   任务拆分+风险预判

   人审核后才执行

3. /opsx:apply: 执行落地

   按方案创建Spec+代码

   受Harness约束

   superPower自动触发

   AI干活，人验收

4. /opsx:archive: 归档沉淀

   踩坑写入error-log

   经验写入lessonslearned

   更新exec-plans

   状态团队经验不流失

如何写Spec文档

Spec文档是让AI帮你生成，你只是提供prompt。

5条打磨心法

1. 一个模块一份Spec 别让AI把Todo和User注册混一个文件，上下文会冲散
2. 异常清单必带 空值/超长/越权/并发/重复/超时——至少过一遍
3. 数字必给单位/范围 "快"不是数字，"1秒内响应"才是
4. 枚举必列全 status有几个值列几个，别留"等等"
5. 不确定标[待确认] AI自己拍脑袋是大忌，标出来再讨论

人不可替代的三件事——AI是高产实习生，你是把关主编

1. 设定边界: 什么不做、什么是MVP,是你的商业判断
2. 找漏补缺: 异常路径、安全场景,是你的工程经验
3. 拍板定调多方案选哪个、何时定稿,是你的决策权

例如给todo list模块生成Spec文档 Prompt如下：

为项目的Todo待办清单模块生成一份Spec文档，文档结构必须包含：
1. 模块边界(包含哪些功能、不包含哪些功能)
2. 核心场景(用WHEN/THEN/AND格式枚举正常+异常路径)
3. 数据结构(请求/响应字段，含类型与约束)
4. 验收标准(可勾选)
要求：
- Todo只支持单用户私有，不做协作
- 字段命名钱后端统一用驼峰法
- 异常路径必须覆盖

AI生成文档后需要检查，看生成的是否有遗漏的地方，如果有需要给AI修改建议，例如：添加xxx约束，直到生成的文档满意为止

Spec Review机制与质量守护：建立文档审查的自动化流程

AI 生成文档，自己审查，难免有遗漏的地方，这就需要让AI再帮你审查一下。

万能Review Prompt

plaintext
请审查这份Spec，重点找出以下问题：
1. 安全风险——越权、信息泄露、未做限流的接口
2. 数据问题——字段类型/长度/索引是否合理
3. 逻辑漏洞——"没说清楚"的灰色地带
4. 异常路径——空值/超长/并发/重复点击是否覆盖
5. 验收标准——ACCEPTANCE是否可量化、可测试

每条问题给出：在Spec哪一行+什么问题+怎么改

AIWorkSpace全栈项目空间搭建—gitsubmodule 多仓库管理

为什么需要AIWorkSpace？git submodule = "合订本"

git submodule = 总仓库挂指针，子仓库各过各的（不复制代码）