SDD + Harness 四周学习计划 · Week 3 · Day 16（工程化闭环第 2 课 / 全计划第 16 课）
今日主题：精读《SDD 规范驱动 + Harness：AI 全栈开发工程化跃迁》：规范即代码、规范即测试（契约测试 / Mock / 骨架代码生成）
建议用时：60–90 分钟 ｜ 前置：Day 15 四类契约
输出物：精读笔记（两条主线：规范即代码 / 规范即测试）+ 一张工具链映射表
0. 一句话剧透
Day 15 你认识了四类契约，但契约还是「写在文档里的约定」。今天精读腾讯云主文《SDD 规范驱动 + Harness：AI 全栈开发工程化跃迁》，看它如何把这句话推到极致：规范即代码、规范即测试——spec 不只是给人读的，它直接长出骨架代码、生成契约测试、变成 Mock 的输入。这是 Day 15 的深化，也是 Day 17「测试成为 CI/CD 门禁」的伏笔。
1. 今日目标（学完你能做到）
- 能用自己的话解释「规范即代码」（spec 直接生成骨架代码/数据校验）
- 能用自己的话解释「规范即测试」（spec 直接生成契约测试与 Mock）
- 能说出至少 4 个相关工具及其用途（OpenAPI Generator / Pydantic / Hypothesis / 契约测试 / Mock Server）
- 能说出「规范即测试」为什么能成为 CI/CD 的门禁（为 Day 17 铺垫）
- 完成动手练：精读原文 + 摘 3 句 + 填工具链映射表
2. 学习动线（建议时间分配）
| 步骤 | 内容 | 用时 |
|---|---|---|
| 1 | 第 3 节：文章的来龙去脉（承接《出码率 90% 却没提效？》） | 10 分钟 |
| 2 | 第 4 节：规范即代码 | 20 分钟 |
| 3 | 第 5 节：规范即测试 | 25 分钟 |
| 4 | 第 6 节：工具链映射表（对接 Day 15 四类契约） | 10 分钟 |
| 5 | 动手练（第 7 节）：精读原文 + 笔记 | 20–30 分钟 |
| 6 | 自测（第 8 节） | 10 分钟 |
3. 文章的来龙去脉：为什么会有这篇「工程化跃迁」
腾讯云另一篇《出码率 90% 却没提效？》讲了三个瓶颈（已核验）：出码率≠提效 / 上下文失控 / 无法验证，结论是 AI 编程要从「个人技能」升级为「团队级工程能力」。今天这篇主文就是「升级」的方案：用规范把 AI 的行为钉死，用 Harness 把规范执行到底。「规范即代码、规范即测试」是全文的灵魂。
4. 规范即代码：spec 直接长成代码
「规范即代码」的意思是：规范不是开发完再补的文档，而是代码生成与校验的输入。
已核验的落地方式：
- OpenAPI Generator：从 API 规范（OpenAPI/Swagger 定义）直接生成骨架代码——客户端、服务端接口、模型类都是生成的，人和 AI 不用手写一遍。接口定义变，生成代码就变，不会「文档和代码两张皮」。
- Pydantic：用数据模型声明做数据校验——字段类型、必填、取值范围在声明里写死，运行时自动校验。这就是 Day 15 数据契约的直接落地。
记忆钩子：代码是从规范「长」出来的，而不是人照着规范「写」出来的。
5. 规范即测试：spec 直接长成测试
「规范即测试」是更关键的一条：规范本身就是测试的输入，测试是从规范生成的，而不是人凭感觉补的。
已核验的落地方式：
- 契约测试：校验「接口实现是否符合规范承诺」——消费方和生产方各按契约独立测试，只要双方都过契约，联调就不会崩。Day 15 行为契约靠它落地。
- Mock Server：按规范自动生成模拟服务——前端/联调方在真实服务没好之前，先按契约跑 Mock，接口形状错了当场暴露。
- Hypothesis：基于属性的测试——不写死几条用例，而是按属性描述生成大量输入去探测边界，是「质量契约/边界」的自动化补充。
记忆钩子：测试是从规范「长」出来的，规范改了测试跟着改——这就是「规范即测试」。
6. 工具链映射表：把 Day 15 的四类契约接上
| 四类契约（Day 15） | 落地工具（已核验） | 生成/检验的形态 |
|---|---|---|
| 数据契约 | JSON Schema / Protobuf / Avro / Pydantic | 数据结构声明 + 运行时数据校验 |
| 行为契约 | OpenAPI Generator、契约测试、Mock Server | 骨架代码、契约测试、模拟服务 |
| 质量契约 | Hypothesis、指标阈值 | 基于属性的边界探测、SLO 监控 |
| 可观测性契约 | 日志/指标/追踪规范（具体工具待核验） | 运行时可观测标准 |
这张表是你 Day 21 周复盘的材料之一。文中还提到契约测试的规模与效果（已核验）：契约测试 1000+ 用例、错误率 <0.1%——这就是「规范即测试」在实际项目里的量化回报。
7. 动手练（约 20–30 分钟）
- 精读原文（腾讯云 2703349，重点读「规范即代码 / 规范即测试 / 工具链」三节），10 分钟。
- 摘 3 句你认为最重要的话，各用一句话解释「它改变了什么」，10 分钟。
- 自问自答：「为什么规范即测试能成为 CI/CD 的门禁？」——先自己想 1 分钟，再看下方提示，10 分钟。
提示（Day 17 预告）：测试是 CI/CD 流水线里的检查点。如果测试是从规范生成的、且规范改动会自动更新测试，那么「测试过 = 实现符合规范」这件事就变成自动化的了——门禁就可以放心卡住不符合规范的代码，不用靠人 review 时肉眼比对。
8. 自测题
- 「规范即代码」和「规范即测试」各是什么意思？
- OpenAPI Generator 生成什么？解决什么问题？
- Pydantic 属于哪类契约的落地？
- 契约测试和 Mock Server 分别解决什么问题？
- Hypothesis 是基于什么的测试？和普通单元测试的差别是什么？
- 为什么说「规范改了测试跟着改」很关键？
- 文中提到的量化成果是什么（契约测试用例数 / 错误率）？
答案与提示：
- 规范即代码：规范是代码生成与校验的输入（骨架代码、数据校验）；规范即测试：规范是测试生成的输入（契约测试、Mock）。
- 从 API 规范生成客户端/服务端骨架代码与模型类，解决「文档与代码两张皮」。
- 数据契约。
- 契约测试验证实现是否符合规范承诺；Mock Server 按契约生成模拟服务，供联调方提前开发。
- 基于属性的测试（Hypothesis）；差别在于不写死用例，而是按属性描述生成大量输入探测边界。
- 保证规范与测试永远同步，测试通过 = 实现符合规范，门禁才能自动化。
- 契约测试 1000+ 用例、错误率 <0.1%。
延伸阅读
- 腾讯云《SDD 规范驱动 + Harness：AI 全栈开发从「能跑」到「可控」》（今天的主文）：https://cloud.tencent.com/developer/article/2703349
- 腾讯云《出码率 90% 却没提效？》（三个瓶颈出处）：https://cloud.tencent.com/developer/article/2669269
- CSDN《SDD 和 Harness：AI 编程的两大支柱》：https://blog.csdn.net/qq_43284469/article/details/164267908
本工作纸依据《SDD+Harness四周学习计划.md》Day 16 主题编制。整理日期：2026-09-09
