《互联网软件开发技术与实践》· 第 1 课（下）
软件开发范式转移与规约驱动开发
01
范式转移
从编写代码，转向定义意图、由 AI 生成并维护
02
四种开发范式
瀑布、敏捷、DevOps、AI 原生：各自解决什么问题
03
Vibe Coding
依赖直觉决策；意图难以固化，系统难以持续维护
04
SDD 开发范式
规约是首要制品；迭代与规约并行，故障可以追溯
01
软件开发的工作方式正在转变
- 从程序员逐行编写，转向人类定义意图、AI 生成并维护
- 这一转变十分深刻：有观点认为，手工编写代码的时代已经结束
1.1
核心变化：谁来写代码，谁来定义意图
- 软件开发正经历一场由大语言模型驱动的范式转移：工作中心从“把语句写对”转向“把意图说清、把约束写明确”。
- 新分工：人类负责目标、边界、失败时的表现和验收；AI 负责按这些约束生成、修改并维护软件。
- 业内有一种判断：手工编写代码的时代已经结束。它说对了生成速度，但没有说可以不读代码、不看失败路径，也没有说“模型声称完成”等于验收通过。
以前的默认假设
- 价值主要体现在亲手写出的代码行
- 先实现，再补说明、再补测试
- 懂代码的人，才有资格改系统
正在形成的默认假设
- 价值主要体现在意图、约束与验收是否清楚
- 先写可执行规约，再让 AI 按规约修改仓库
- 读得懂运行结果与失败路径的人，才能完成验收
1.2
人类必须承担的三件事：意图、约束、验收
意图
为谁解决什么问题，达到何种状态视为成功。校园智能助手面向本班的教师与学生，而不是面向所有人的通用问答。意图写不清，生成再快也只是通用功能的堆砌，上线后说不清为谁做成了什么。
约束
谁可以查看、谁不可以查看；无依据时不得编造；密钥不得进入前端。约束写不清楚，模型将自行填入默认假设。实际项目中，缺约束的典型后果是越权访问与密钥进入前端。
验收
用页面、接口、测试、日志证明约束成立。反馈来自系统是否通过检验，而不是来自模型口头声称完成。没有验收，完成标准就会落到“模型说完成了”。
02
软件开发范式如何一步步走过来
- 软件工程始终在探索：在不确定性中如何交付可靠软件
- AI 辅助编程正在推动新的转变；氛围编程只是尚不成熟的过渡形态，SDD 才是可落地的方法
2.1
一条时间轴：瀑布、敏捷、DevOps、AI 原生
①
瀑布先完成全部设计，再一次性实现。阶段清楚，变更成本高。
②
敏捷小步交付、边使用边调整。反馈加快；缺少验收时，范围容易扩散。
③
DevOps开发与运维贯通：构建、发布、观测、回滚成为同一条回路。
④
AI 原生人类定义意图，AI 生成并维护软件。控制点从代码行转到规约与验收。
2.2
瀑布与敏捷：先计划，还是先交付可运行增量
瀑布模型
- 有规范、无迭代：先定义做什么、再设计如何实现、最后编码，阶段单向推进
- 优点：留下完整决策链，事后能追到“当时为什么这样定”
- 其隐含前提是需求基本稳定。一旦变更，前期设计往往难以沿用
- 企业项目边开发边变更，很少适合纯瀑布
敏捷开发
- 有迭代、轻规范：可工作的软件优先于详尽文档，两周左右交出一版
- 优点：需求可以边做边澄清，反馈进下一次增量
- 若走向极端，口头默契会取代文档；人员或模型更换后，决策难以延续
- 范围容易在“再加一个小功能”中蔓延
2.3
DevOps：能交付，还要能持续运行
- 敏捷解决了“更快做出可运行增量”，但增量若无法稳定发布、观测和回滚，仍然停留在开发者本机。
- DevOps 将开发与运维纳入同一条回路：构建、测试、发布、监控、故障处理不再分属两个世界。
- 镜像、持续集成、生产部署、日志与压测，就是这条回路在真实项目里的最低配置。
它补上了什么
- 同一套代码能够重复构建、重复发布
- 出问题能看到日志、指标，并能回滚
- 开发与运行依据同一份事实，而不是两套口头传递的步骤
它还没有回答的问题
- AI 一次改很多处时，怎样判断“这次可以发布”
- 意图和约束写在哪里，谁来当完成标准
- 若无可执行规约，流水线只会更快地发布无法判定对错的结果
2.4
AI 原生开发：人定义意图，AI 生成并维护
- AI 原生不是“额外安装一个编程助手”，而是默认假设：大量实现由模型生成，人类把精力放在意图、约束与验收上。
- 仓库、测试与流水线仍然必要；只是它们服务的对象，从“人手写的每一行”转向“模型按约束修改后的系统”。
- 把 AI 原生做扎实，通常经过三个叠加的阶段，而不是三选一：提示词工程把意图写成对模型的指令；上下文工程决定模型看到哪些规约、仓库与约束；Harness 工程让模型、工具与仓库构成循环，以修改、运行、验证判定完成。
看起来像 AI 原生
- 在对话窗口中让模型“帮我做登录”
- 预览可以操作，但说不清权限写在何处
- 模型声称完成，便将其视为完成
真正的 AI 原生
- 意图和失败路径写进仓库，人和模型都读同一份
- Harness（模型 + 工具 + 仓库）按规约修改、启动并运行检查
- 用页面、测试、日志判定是否完成
2.5
对照：有无规约，有无迭代，什么算完成
| 做法 | 规约 | 迭代 | 什么算完成 | 缺口 |
|---|---|---|---|---|
| 瀑布 | 有，且较完备 | 基本没有 | 阶段成果通过验收 | 变更成本高，反馈晚 |
| 敏捷 | 偏轻，常靠口头约定 | 有 | 增量可运行、可演示 | 缺验收时难判对错 |
| DevOps | 继承敏捷 | 含发布与观测 | 能重复发布、可回滚 | 不自动保证符合意图 |
| 氛围编程 | 几乎没有 | 只有对话轮次 | 看似可用 | 决策难以保留 |
| SDD | 有，且结构化 | 规约与代码一并迭代 | 失败路径与证据成立 | 起始要先写清意图 |
03
Vibe Coding：最快的 AI 原生，也最容易失控
- 依据直觉提出需求、依据预览决定下一步，适合验证想法
- 演示之后需要追问：对错由谁判定，后续还能否安全修改
3.1
什么是 Vibe Coding（氛围编程）
- 它并非教科书中的正式方法，而是 Copilot、Cursor、Claude Code 等工具普及后，在开发者社区中逐渐形成的做法。
- Andrej Karpathy 于 2025 年初提出这一说法：用自然语言向 AI 描述想法，由其生成并运行代码。下文沿用这一名称，但须明确其适用边界。
- 其典型做法是依据当下直觉推进：需求、架构与取舍均发生在对话之中，很少固化为可保存、可传递的工程制品。
- 它是开发过程中使用 AI 的一种方式，与产品中的助手、技能、知识库不是同一件事。
它擅长
- 反馈极快，创作空间大：数分钟内即可由简短描述得到可运行原型
- 个人练习、探索新技术、一次性脚本，以及验证想法是否值得继续投入
- 概念验证、团队内对齐交互，让更多人能把软件做出来
它不擅长
- 事先写清设计、约束和验收
- 权限、隔离、密钥、失败路径、并发与数据一致
- 多人长期修改同一仓库时，仍能保持决策可追溯
3.2
它所依赖的是三种直觉，而不是三份工程制品
依据直觉描述需求
不再编写可核对的条目，只在对话中勾勒轮廓。角色、边界与失败处理往往并未明确规定。
依据直觉做决定
数据库、分页、缓存与错误码等选择，往往追随模型建议或对话走向，很少记录备选方案与理由。
依据直觉验收
完成标准退化成“能否运行”。不再追问为何如此实现、是否存在更优方案、风险位于何处。
3.3
它的实际过程：依据预览决定下一步
①
提出想法只给出大致方向。角色、边界与失败处理常常未予写明，或仅停留在口头约定
②
生成可运行代码模型依据概率补全未予说明的部分，很少追问提示是否成立，便生成可运行的代码
③
试运行后再修改查看预览、修改一句提示、再次生成。业务规则与性能假设大多仍留在对话窗口中
④
看似可用主路径一旦通过便停止验证。错误处理、并发、数据一致性与越权等情形常常未被检查
案例
现场演示：扣子编程（Coze）
①简要描述需求
②Agent 生成并运行
③再以简短语句迭代
给扣子编程的需求
做一个能录入并查询“班级课程表”的网页应用： - 教师可以添加课程（星期、节次、科目、教师） - 支持按星期筛选查看 - 页面风格简洁，主色用北大红
生成后应观察到，并当场追问
- 自动生成：分析需求 → 规划 → 前后端代码 → 云端沙箱（隔离的运行环境）中运行
- 即时预览：能录入、能按星期筛选
- 再次修改提示：“加一个按教师筛选”“节次冲突时拒绝保存”
同类工具可对照：编辑器内的 Cursor / Trae / Claude Code。
3.4
局部很快，返工往往更多
先改页面，再补约束
- 一句“先做出作业列表”，模型立刻生成可交互的页面
- 一句“界面好看一点”，样式随即更换一版
- 登录、班级隔离与密钥彼此脱节，因为始终缺少总体设计
- 单步速度很快，但在补齐硬性约束时往往需要大幅返工
先编写规约，再按规约验收
- 谁能看、失败时怎样、证据是什么，先写在同一份规约里
- 每一步都能对照：该不该生成这一层
- 起始稍慢，后续返工显著减少
- 验收依据规约，而不是依据“刚才预览尚可”
3.5
决策流失与上下文漂移：约定留在对话里，随后就会丢失
- 数日内即可做出具备检索功能的原型。向量库、分页、缓存与错误码等取舍，往往散落在多个对话窗口中。会话结束后，团队常常无法一致说明“为何选择该方案”。
- 模型上下文再大也有上限。对话一长，早期关键决定会被挤出或压成摘要。后半段代码单独看往往自洽，纳入系统后才发现与最初约定相互矛盾。
对话难以成为制品
- 对话是线性、即时的，适合展开讨论，但没有标题、大纲与版本
- 设计如果只发生在对话中，数日后便难以追溯
- 必须留下：考虑过哪些备选、为什么留下这一套
漂移为何当场难以发现
- 每一段新代码内部都显得自洽，冲突发生在跨模块、跨迭代的衔接处
- 例如：第一轮约定错误统一返回约定字段，第二十轮做排序时改回随意抛出异常
- 因此须将约定写入仓库。新开会话，相当于更换一批不了解既有设计的实现者
3.6
约定不进仓库之后：质量、协作、复现都会失守
①
质量靠不住未写入的边界模型不会补。能查本班作业，不代表改 URL 查看其他班级时会被拒绝
②
可维护被透支为何如此实现只留在对话里。上线前补隔离，改核心的时间往往接近当初开发
③
协作易冲突甲返回 homeworkId，乙生成 id；没有统一约定，合并变成逐行修补
④
无法稳定复现同一句提示换模型可以是另一套行为。当时能运行，下次却复现不出来
3.7
适用边界：探索可以快，上线必须另有验收机制
仍可依据直觉探索的情形
- 个人练习、学习新技术、一次性脚本、算法或数据探索
- 团队内对齐界面，例如确认列表应如何呈现
- 立项或技术探路阶段，不接入真实业务数据
- 没有真实用户，也不涉及生产数据与隐私
必须将直觉结果写成规约的情形
- 需要部署到生产环境，供真实用户使用
- 涉及成绩、权限、跨班级数据或 API 密钥
- 多人修改同一仓库，隔几周还要继续演进
- 必须证明实现和意图一致，而不能仅以演示可操作为依据
04
SDD：用规约约束 AI 原生开发
- 规约是首要制品，代码是其派生结果
- 既非回到瀑布模型，也非继续依赖直觉：既保持迭代，也保有规约
4.1
什么是规约驱动开发（SDD）
- Specification-Driven Development：把形式化或半形式化的规约放在开发活动的中心。人和模型的任务，都是实现一份已经写清的规约，而不是凭空写代码。
- 规约不再是代码之前的说明书。它必须可执行、可验证、可进版本库，成为团队沟通和验收的共同语言。
- 它不是否定氛围编程，而是为生成过程提供约束：在保持速度的同时，补上确定性、可复现性与可协作性。
核心要点
- 规约是首要制品，代码是派生结果
- 规约即代码：人和模型都读仓库里这一份
- 规约即测试：同一份就是完成标准
它分别补上了什么
- 补敏捷：增量必须对照条目，不能仅以界面可操作为依据
- 补 DevOps：流水线发布的必须是规约要求的行为
- 补氛围编程：给生成速度加上意图、约束和失败路径
4.2
默契无法传给模型，所以必须先写清意图
人协作时还能靠默契
- 固定团队可以通过例会、白板，记得上周为何如此决定
- 许多架构选择心照不宣，即使不形成文档，仍可继续推进
- 过去的成本主要在编写：实现慢，客观上迫使先作思考
模型当主笔时默契失效
- 它不参加例会，只知道当前窗口里还留着的内容
- 生成成本接近于零，错误出现更快，也更不易察觉
- 新开会话等于更换不了解既有设计的实现者。人必须把默契写成规约，模型才能照着写下的文字执行
4.3
两条循环，结果完全不同
氛围编程的循环
- 输入是简短的自然语言；循环是：描述 → 看预览 → 再描述
- 完成标准是“看似可用”；决策留在对话窗口
- 要改行为，再补一句提示。没有统一的行为约定可以复查
依据规约有序推进
- 先按意图写出可核对规约
- 团队内审查条目，通过后再交给 Harness
- 生成之后做规约一致性对照：页面、接口、测试
- 要改行为，先改规约，再改实现
4.4
好代码不等于好软件：故障时能否追溯
只写了“能打开列表”
- 逻辑正确，本地演示 200 毫秒
- 部署到公网后同步调用外部接口，列表响应可达数秒
- 代码里看得见同步调用，对话记录已经不可用
- 只能推测：当时为何如此实现？应当修改何处？
规约里还能补上缺失的约束
- 仓库里写着：为了简化错误处理，先用同步调用
- 即可定位：缺的是响应时间，不是功能对错
- 补一条：列表接口 2 秒内返回，再按规约改代码
- 好软件还要：意图清楚、决策可追、交付可验
4.5
SDD 的流程：先定义，再生成，再对照
①
写规约把需求意图写成可核对条目：谁、做什么、不做、失败时怎样、证据
②
审查团队内先行审查：条目是否具体、可验证。规约本身未通过，不得进入实现
③
生成把审过的规约原样交给 Harness，按规约修改同一仓库，而不是再次口头描述
④
对照用同一份规约做一致性验收：页面、接口、测试、日志相互一致才算完成
4.6
规约必须可验收：五要素，形式可以有轻有重
- 合格规约五要素：谁、做什么、不做、失败时怎样、用什么证据。换一批人或换一个模型，只读这份规约就能完成；评审只依据证据判定。
- 形式可以轻（仓库里的短规约、接口约定、类型约束、测试断言），也可以重（OpenAPI 等，了解即可）。不论轻重，愿望句“尽量安全一点”不是规约。
五要素如何写
- 谁：有哪些角色，各自能看什么、能改什么
- 做什么：成功路径上访问哪些页面、应当看到什么
- 不做：范围外明确排除
- 失败时怎样：越权 / 无资料 / 未登录时的表现
- 用什么证据：截图、接口、测试命令或日志字段
可验收的表述
- 学生打开作业列表，只看到本班、本人权限范围内的记录
- 把 URL 里的班级 ID 改成其他班级，返回 403
- 知识库无命中时文案含“没有检索到”，且无假出处
- 仓库与前端响应中均不含 sk- 开头的密钥
4.7
把刚才演示的课程表，写成可验收规约
当时给扣子的愿望
- 做一个能录入并查询“班级课程表”的网页应用
- 教师可以添加课程（星期、节次、科目、教师）
- 支持按星期筛选查看
- 页面风格简洁，主色用北大红
写成五要素之后
- 谁：已登录教师可添加、修改自己录入的课程；学生仅可查询
- 做什么：可按星期筛选；教师可添加星期、节次、科目、教师；主色为北大红
- 不做：不做选课与成绩；不接入真实教务数据
- 失败时怎样：节次冲突拒绝保存并提示；未登录教师无法写入；无课程时显示“本星期暂无课程”，不编造记录
- 证据：添加后按星期可见；故意制造冲突出现提示；未登录无法写入
课后
课后任务：用氛围编程完成一个小项目
- 安装一种编辑器内 AI 工具（Cursor / Codex / Trae / Claude Code 任选其一），打开一个空的本地文件夹。
- 用氛围编程的方式，凭简短自然语言生成一个可运行的小项目。不要先写规约，故意走“描述 → 看预览 → 再描述”。
- 题目自拟，控制在个人即可完成的范围，例如待办清单、个人记账页、课程表查询、单位换算器。不要接入真实用户数据，也不要处理密钥与生产环境。
- 将项目放入 Git 仓库。只需提交仓库地址，由扣子作业回收系统收取；不必另交报告或提示原文。
谢谢大家
第 1 课 · 人定义意图，AI 生成并维护，以规约约束过程