夜雨聆风AI 编程真正的分水岭：不是会写提示词，而是会写 Spec
很多上班族第一次接触 AI 编程，都会经历一个兴奋期。
你对 AI 说：
帮我做一个销售数据看板。
帮我开发一个客户管理系统。
帮我做一个可以上传 Excel 并自动分析数据的网页。
几分钟后，页面出现了，按钮也能点击，图表甚至还有动画。
你会产生一种错觉：
原来开发软件这么简单。
但继续修改几轮后，问题很快出现：
• 改了首页，详情页的样式乱了； • 新增一个字段，三个页面的数据对不上； • 修复一个问题，又出现两个新问题； • AI 忘记了之前确定的技术方案； • 页面看起来能用，实际流程却跑不通； • 代码越来越多，你却越来越不敢动。
这并不意味着 AI 编程没有价值。
真正的问题是：你一直在让 AI“猜”，却没有给它一份可以持续执行的工程规范。
这正是 Spec-Driven Development，规范驱动开发 要解决的问题。
一、什么是 Spec-Driven Development？
Spec-Driven Development，简称 SDD，可以翻译为：
规范驱动开发。
它的核心思想非常简单：
在开始写代码之前，先把系统应该做什么、不能做什么、如何实现、怎样验收，写成一套明确的规范，再让 AI 按照规范进行开发。
这里的 Spec，不是一份写完就放在文件夹里吃灰的需求文档。
它应该是一套能够真正约束 AI 的执行契约。
例如，你不能只对 AI 说：
帮我做一个销售管理系统。
而应该逐步明确：
• 系统给谁使用； • 要解决什么业务问题； • 包含哪些页面和功能； • 不包含哪些功能； • 数据之间如何关联； • 页面之间如何跳转； • 使用什么技术栈； • 哪些组件必须统一； • 什么情况下算开发完成； • AI 不允许擅自做哪些决定。
当这些内容形成稳定、可版本管理的规范后，AI 就不再是“根据一句话随机生成代码”，而是在一个确定的工程边界内完成任务。
二、为什么只靠自然语言聊天，很难做好一个完整系统？
很多人把 AI 编程理解成：
我提出要求，AI 生成代码；
不满意，我再说一句；
有问题，我让它继续修改。
这种方式适合做一个小页面、一次性脚本或者快速原型。
但当项目开始出现多个页面、多个角色、多个业务流程时，只靠对话就会逐渐失控。
原因主要有四个。
1. 对话不是可靠的项目记忆
你可能在第一轮告诉 AI：
所有列表页面统一使用相同的搜索区和分页组件。
到了第二十轮，你让它新增一个页面时，它可能重新设计一套完全不同的搜索区。
不是 AI 故意违反要求，而是长期对话中存在大量信息，早期约束很容易被弱化。
如果关键规则只存在于聊天记录里，项目就没有稳定的事实来源。
2. 模糊需求会被 AI 自动补全
当你说：
做一个用户管理功能。
AI 必须自行猜测：
• 用户有哪些字段； • 是否支持新增和删除； • 是否需要角色管理； • 删除是真删除还是停用； • 是否需要操作日志； • 是否允许批量导入； • 是否需要密码重置。
AI 的补全可能很合理，但未必符合你的真实业务。
没有明确写出来的需求，不代表不存在，而是意味着 AI 会替你做决定。
3. 代码能运行，不等于业务正确
AI 很容易生成一个“看起来像系统”的产品：
• 页面能打开； • 表格有数据； • 按钮能点击； • 弹窗可以出现。
但真正的业务系统还需要考虑：
• 页面之间的数据是否一致； • 操作前后状态是否正确变化； • 用户是否只能看到自己的数据； • 异常情况如何处理； • 前置条件不满足时是否禁止操作； • 提交后是否允许撤回； • 删除数据是否影响其他页面。
这些问题不能靠“页面看起来不错”来验收。
它们必须提前写进规范和验收标准。
4. 修改局部功能，可能破坏整个系统
没有规范时，AI 往往只关注你当前提出的问题。
例如：
把详情页的供应商状态改成“已通过”。
AI 可能只修改详情页，却没有同步修改：
• 项目列表中的状态； • 工作台中的统计数量； • 供应商汇总页面； • 后续流程的进入条件； • Mock 数据中的统一状态。
于是，一个页面改对了，整个系统的数据却不一致了。
SDD 强调的不是“把某个页面做出来”，而是：
所有实现都必须符合系统级规范。
三、Vibe Coding 和 SDD 有什么区别？
Vibe Coding 可以理解为“凭感觉和 AI 一起写”。
你告诉 AI 一个大概想法，然后不断查看效果、调整提示词、修改页面。
它的优势是快。
特别适合：
• 验证一个创意； • 制作简单原型； • 开发一次性工具； • 学习新技术； • 快速尝试不同页面风格。
但它的问题也很明显：
• 依赖当前对话； • 容易前后矛盾； • 难以复现； • 不利于长期维护； • 项目越大，修改成本越高。
SDD 则是先建立规则，再进行实现。
二者并不是非此即彼。
更合理的方式是：
先用 Vibe Coding 探索，再用 SDD 工程化落地。
你可以先让 AI 快速做出一个原型，确认产品方向；方向确定后，再把已经验证的内容整理成正式规范，进入稳定开发阶段。
四、对于普通上班族，Spec 到底应该写什么？
很多人看到“规范驱动开发”，第一反应是：
这是不是只有程序员和架构师才能做？
恰恰相反。
对于不擅长写代码、但熟悉业务的上班族来说，Spec 反而是最重要的能力。
因为你可能不知道某个函数应该怎么写，但你通常知道：
• 业务应该怎样运行； • 用户真正需要什么； • 哪些操作不允许发生； • 哪些数据必须保持一致； • 哪些结果才算正确。
一份适合 AI 编程的基础 Spec，至少应包含以下六部分。
1. 最终目标
不要只描述“做什么功能”，还要说明最终要交付什么。
模糊描述：
做一个销售数据分析系统。
更好的描述：
开发一套供销售运营人员使用的桌面端数据分析系统。用户可以上传线索表、商机表和订单表，查看销售漏斗、目标完成率、区域表现和异常客户，并导出分析结果。
目标要回答三个问题：
1. 谁使用？ 2. 解决什么问题？ 3. 最终交付什么成果？
2. 业务范围
明确哪些内容属于本次开发。
例如：
## 本次包含
- Excel 文件上传
- 数据格式检查
- 销售漏斗分析
- 目标完成率分析
- 区域和人员排名
- 异常数据提示
- 分析结果导出
## 本次不包含
- 用户注册与登录
- 在线支付
- CRM 系统接口
- 手机端适配
- 数据库持久化
- 多租户权限体系“不做什么”与“做什么”同样重要。
因为 AI 很容易为了让系统显得完整，主动增加你没有要求的功能。
3. 业务规则
业务规则决定系统能不能真正使用。
例如：
## 业务规则
1. 一条线索只能归属于一个销售人员。
2. 已关闭的商机不能重新进入跟进状态。
3. 订单金额必须大于 0。
4. 销售目标完成率 = 实际订单金额 ÷ 销售目标金额。
5. 同一客户存在多笔订单时，客户数只能统计一次。
6. 上传数据存在必填字段缺失时，不允许进入分析页面。很多 AI 项目失败，不是因为页面做得不好，而是因为业务规则没有被明确表达。
4. 页面、功能与交互
不要让 AI 自行决定整个系统的信息架构。
你需要提前说明：
## 页面结构
1. 首页工作台
2. 数据上传
3. 销售漏斗分析
4. 目标完成分析
5. 区域分析
6. 销售人员分析
7. 异常数据中心
8. 分析报告
## 页面跳转关系
- 首页点击“上传数据”进入数据上传页。
- 数据校验成功后，才能进入分析页面。
- 点击销售人员姓名进入个人详情页。
- 点击异常数量进入异常数据中心，并自动带入筛选条件。页面设计的重点不是“有几个按钮”，而是用户如何完成完整任务。
5. 技术与工程约束
这一部分是给 AI 划定技术边界。
例如：
## 技术约束
- 使用 React、TypeScript 和 Vite。
- 使用统一的组件库，不重复开发相同组件。
- 所有演示数据统一从 Mock 数据层读取。
- 页面中禁止直接写死业务数据。
- 类型定义统一存放在 types 目录。
- 页面组件、业务组件和基础组件分层管理。
- 单个文件职责必须清晰，禁止将整个系统写入一个文件。
- 不接入真实后端和数据库。对于非技术人员，不需要一开始就把所有技术细节写得非常专业。
你可以先明确最重要的原则：
• 技术栈统一； • 数据来源统一； • 组件统一； • 代码模块化； • 禁止重复实现； • 不允许擅自更换方案。
6. 验收标准
验收标准必须能够判断“通过”还是“不通过”。
不要写：
页面要美观。
系统要好用。
数据要准确。
应该写成：
## 验收标准
1. 上传符合模板的 Excel 后，可以正常进入分析页面。
2. 缺少必填字段时，页面必须明确提示缺失字段名称。
3. 首页订单金额必须与订单分析页汇总金额一致。
4. 销售人员排名页与个人详情页的订单金额必须一致。
5. 所有列表页面使用统一的搜索区、表格和分页组件。
6. 在 1440×900 和 1920×1080 分辨率下，不出现横向内容遮挡。
7. 所有页面均不得出现无效按钮、空白跳转或模拟成功提示。
8. 构建命令、类型检查和自动化测试必须通过。AI 能否稳定完成任务，很大程度上取决于你是否定义了明确的完成条件。
五、一套适合上班族的 SDD 工作流程
对于个人学习和中小型项目，不需要一开始就建立特别复杂的体系。
可以先使用下面这套七步流程。
第一步：先说清楚业务目标
先不要急着让 AI 写代码。
你可以告诉 AI：
我想开发一套销售运营数据分析工具。
目标用户是企业销售运营人员。
他们需要上传线索、商机和订单数据，快速发现销售转化问题、目标完成差距以及重点异常客户。
请先不要写代码，先帮助我梳理业务目标、用户角色、核心场景和产品范围。这一阶段的核心任务不是开发，而是减少需求模糊。
第二步：形成产品规范
让 AI 把讨论结果整理成 product_spec.md。
建议至少包含：
product_spec.md
├── 项目背景
├── 用户角色
├── 核心问题
├── 产品目标
├── 使用场景
├── 业务范围
├── 非目标范围
├── 业务流程
├── 业务规则
└── 验收指标这一文件回答的是：
系统为什么做、给谁做、要解决什么问题。
第三步：形成页面与交互规范
接着生成 page_structure.md 或 interaction_spec.md。
建议包含：
page_structure.md
├── 页面层级
├── 页面功能
├── 页面数据
├── 操作入口
├── 跳转关系
├── 页面状态
├── 异常状态
└── 页面间数据同步关系这一文件回答的是：
用户如何使用系统完成任务。
第四步：形成工程规范
建立类似下面的文件：
AGENTS.md
design_guide.md
frontend_rules.md
data_spec.md
acceptance.md它们可以分别负责：
• AGENTS.md：AI 在整个项目中必须遵守的最高规则；• design_guide.md：视觉语言、布局和组件使用原则；• frontend_rules.md：代码结构、技术栈和开发规范；• data_spec.md：字段定义、状态枚举和统一演示数据；• acceptance.md：验收场景和完成标准。
这样做的目的，是把关键要求从聊天记录中移到项目文件里。
第五步：把大任务拆成小任务
不要对 AI 说：
请一次性完成整个系统。
应该让 AI先生成 tasks.md：
# 实施任务
## 阶段一：基础工程
- [ ] 初始化项目
- [ ] 建立目录结构
- [ ] 配置路由
- [ ] 建立全局样式
- [ ] 建立 Mock 数据层
## 阶段二：通用组件
- [ ] 页面标题组件
- [ ] 搜索区组件
- [ ] 数据表格组件
- [ ] 状态标签组件
- [ ] 分页组件
- [ ] 空状态组件
## 阶段三：业务页面
- [ ] 首页工作台
- [ ] 数据上传页面
- [ ] 销售漏斗页面
- [ ] 目标完成页面
- [ ] 异常数据页面
## 阶段四：系统验收
- [ ] 页面跳转检查
- [ ] 数据一致性检查
- [ ] 响应式检查
- [ ] 构建检查
- [ ] 自动化测试每完成一个任务，就进行一次验证。
这比让 AI 一次生成几十个文件更加稳定。
第六步：按规范实现和测试
执行任务时，提示词不要只写“继续开发”。
可以使用以下结构：
## 当前任务
实现销售漏斗分析页面。
## 必读规范
- AGENTS.md
- product_spec.md
- page_structure.md
- design_guide.md
- data_spec.md
- acceptance.md
## 实施范围
只实现销售漏斗分析页面及其必要组件。
## 禁止事项
- 不修改其他业务页面。
- 不新增规范中不存在的功能。
- 不重新定义 Mock 数据。
- 不复制已有通用组件。
- 不更换现有技术栈。
## 完成要求
- 完成代码实现。
- 执行类型检查和构建。
- 检查页面数据与首页统计是否一致。
- 根据 acceptance.md 输出自检结果。这时 AI 接收到的不再是一句孤立命令，而是一个有上下文、有边界、有验收条件的工程任务。
第七步：修改需求时，先修改 Spec
这是 SDD 最容易被忽略的一步。
假设你决定：
销售目标完成率不再按照订单金额计算，而是按照回款金额计算。
不要直接让 AI 修改代码。
正确顺序应该是：
1. 修改指标定义； 2. 修改字段说明； 3. 修改页面展示规则； 4. 修改 Mock 数据； 5. 修改验收标准； 6. 再让 AI 根据新规范修改代码； 7. 运行全量检查。
这样，需求、数据、页面和代码才能保持一致。
六、一个可以直接使用的 Spec 模板
下面这份模板适合个人工具、内部管理系统和高保真前端 Demo。
# 项目规范
## 1. 项目背景
说明为什么要开发该系统，目前存在什么问题。
## 2. 目标用户
说明系统由哪些角色使用，每个角色的职责是什么。
## 3. 产品目标
说明系统最终需要帮助用户完成什么任务。
## 4. 最终交付物
说明需要交付网页、桌面应用、脚本、数据看板还是其他形式。
## 5. 核心业务场景
按照用户实际工作流程描述核心场景。
## 6. 功能范围
### 6.1 本次包含
- 功能一
- 功能二
- 功能三
### 6.2 本次不包含
- 排除项一
- 排除项二
- 排除项三
## 7. 业务规则
1. 规则一
2. 规则二
3. 规则三
## 8. 页面结构
### 8.1 一级页面
- 页面一
- 页面二
- 页面三
### 8.2 页面跳转关系
说明页面之间如何进入、返回和携带参数。
## 9. 数据规范
- 核心实体
- 字段定义
- 状态枚举
- 数据关联关系
- 统计口径
- 演示数据要求
## 10. 交互规范
- 默认状态
- 加载状态
- 空状态
- 错误状态
- 禁用状态
- 成功反馈
- 二次确认
## 11. 技术约束
- 技术栈
- 项目结构
- 组件复用
- 数据管理
- 状态管理
- 响应式要求
- 代码质量要求
## 12. 禁止事项
- 禁止擅自扩展业务范围
- 禁止重复创建相同组件
- 禁止在页面中写死业务数据
- 禁止绕过统一数据层
- 禁止为了通过测试删除有效断言
- 禁止修改未经授权的模块
## 13. 验收标准
使用可验证、可判断通过与否的方式描述。
## 14. 完成定义
只有满足以下条件，任务才能标记为完成：
- 功能已实现
- 页面可正常访问
- 数据保持一致
- 异常状态已处理
- 构建成功
- 测试通过
- 自检结果已输出七、学习 AI 编程，上班族真正需要补的不是语法
很多人认为，自己不会 JavaScript、Python 或数据库，所以不适合使用 AI 编程。
但在 AI Agent 时代，开发者的工作正在发生变化。
你不一定要先成为一个能够手写所有代码的程序员，但需要逐步建立五种能力。
1. 业务建模能力
能够把日常工作拆成：
• 角色； • 流程； • 规则； • 数据； • 状态； • 异常； • 结果。
业务越清楚，AI 生成的系统越接近真实需求。
2. 规范表达能力
把“我大概想要什么”，转换成：
• 明确目标； • 具体范围； • 操作规则； • 数据口径； • 验收条件。
AI 编程的核心，不只是把话说得详细，而是把要求表达得可执行、可验证。
3. 任务拆解能力
不要追求一句提示词生成整个系统。
要学会把项目拆成：
项目规范 → 页面结构 → 数据规范 → 工程规则 → 任务清单 → 分步实现 → 测试验收。
任务越小，AI 越容易稳定完成。
4. 结果验证能力
至少要学会检查：
• 页面是否能正常运行； • 浏览器控制台是否报错； • 数据是否前后一致； • 不同状态是否正确； • 构建是否成功； • 测试是否通过； • AI 是否修改了不该修改的内容。
不会写代码，并不意味着只能盲目接受代码。
5. 版本管理能力
规范、代码和数据都应该进入版本管理。
每次修改要能够回答：
• 为什么改； • 改了什么； • 影响哪些模块； • 是否更新了规范； • 是否完成回归验证。
AI 可以快速生成大量代码，但只有版本管理才能让这些代码保持可追踪、可恢复和可维护。
八、普通上班族应该从什么项目开始？
刚开始学习 SDD，不建议直接挑战复杂的企业级系统。
可以从与自己工作高度相关的小工具开始。
例如：
销售运营
• 销售目标拆解工具； • 销售漏斗分析看板； • 渠道商分级管理工具； • 商机异常预警工具； • 销售周报生成器。
人力资源
• 简历筛选辅助工具； • 面试评价记录系统； • 员工培训管理看板； • 绩效数据分析工具； • 招聘流程跟踪系统。
财务与行政
• 费用报销检查工具； • 预算执行分析看板； • 合同到期提醒工具； • 固定资产管理系统； • 会议纪要任务追踪工具。
产品与运营
• 用户反馈分类工具； • 需求优先级评估工具； • 内容选题管理系统； • 活动数据复盘看板； • 项目进度跟踪系统。
选择项目时，可以遵循一个原则：
先选择自己熟悉业务，但技术复杂度不高的问题。
你的业务经验会帮助你写出更准确的 Spec，而 AI 可以帮助你完成技术实现。
九、使用 SDD 最常见的五个误区
误区一：Spec 写得越长越好
规范的目标不是堆砌文字，而是减少歧义。
没有执行价值的背景介绍，不需要写几十页。
真正重要的是：
• 规则是否明确； • 边界是否清晰； • 数据是否统一； • 验收是否可执行。
误区二：写完 Spec 后就永远不能修改
SDD 不意味着需求不能变化。
它要求的是：
需求变化时，规范必须同步变化。
Spec 是活的工程资产，不是一次性文档。
误区三：有了 Spec，就可以完全不检查代码
规范可以提高 AI 输出的稳定性，但不能彻底消除错误。
对于重要系统，仍然需要：
• 自动化测试； • 静态检查； • 安全检查； • 人工评审； • 真实场景验证。
误区四：把普通需求文档改名为 Spec
一份只描述“需要哪些功能”的文档，还不能算完整 Spec。
真正能驱动开发的规范，还要包括：
• 范围边界； • 业务规则； • 数据契约； • 技术约束； • 异常场景； • 验收条件； • 禁止事项。
误区五：让 AI 自己生成规范，然后直接执行
AI 可以帮助你整理 Spec，但最终决策必须由人确认。
特别是以下内容，不能完全交给 AI 决定：
• 业务规则； • 数据口径； • 权限边界； • 核心流程； • 技术选型； • 安全要求； • 完成标准。
AI 可以起草，但人必须负责判断。
十、写在最后
AI 编程降低了写代码的门槛，却没有降低做好软件的门槛。
过去，软件开发的主要困难是：
如何把需求翻译成代码。
现在，越来越多的代码可以由 AI 完成，新的困难变成了：
如何准确地描述目标、组织上下文、约束过程并验证结果。
这也是为什么，真正决定 AI 编程效果的，不再只是你会不会写一条精彩的提示词。
而是你能不能建立一套清晰、稳定、可执行、可验证的规范。
对于上班族来说，这反而是一个机会。
因为你最大的优势可能从来不是编程语法，而是你对业务流程、岗位痛点和真实场景的理解。
当这些经验被整理成高质量的 Spec，再交给 AI Agent 执行，你就不只是一个“让 AI 帮忙写代码的人”。
你正在逐步成为：
产品意图的定义者、智能体工作的编排者，以及最终结果的质量负责人。
未来真正稀缺的，未必是写代码最快的人。
而是能够把模糊想法转化为明确规范，再组织 AI 稳定交付成果的人。