第 1 天：为什么 AI 编程需要工程化

SDD + Harness 四周学习计划 · Week 1 · Day 1（认知打底第 1 课）

今日主题：Vibe Coding 的三大瓶颈（出码率≠提效 / 上下文失控 / 无法验证）；SDD 与 Harness 的分工——一个解决「做什么」，一个解决「怎么做」

建议用时：60–90 分钟｜参考文章：资源 3《出码率 90% 却没提效？》（详见文末延伸阅读）

输出物：一篇 200–300 字的「我与 Vibe Coding」个人反思 —— 这是 Day 7 第一篇学习笔记的草稿素材

0. 一句话剧透

AI 能写出代码，不等于你能提效。 今天只解决一个问题：为什么很多团队「出码率 90%」，交付却一点没变快，甚至更慢了？

答案是：答案根本不在 AI 身上，而在我们用「个人作坊」的方式，去干「团队工程」的活。

而 SDD 与 Harness，就是把这门新手艺工程化的两把钥匙——一把管「做什么」（方向对不对），一把管「做对」（干得可不可靠、能不能验证）。今天先把这两把钥匙摆到桌面上认清楚，具体怎么用，是接下来四周的事。

1. 今日目标（学完你能做到）

学完今天这一课，你应该能对以下问题给出有例子、有结构的回答：

能用自己的话解释：为什么「出码率高 ≠ 项目提效」（三大瓶颈中的第一个）
能说出「上下文失控」的典型表现，并举例说明它为什么让 AI 越写越偏
能说明「无法验证」带来的三个后果（返工、不兼容、不敢维护）
能用一句话讲清 SDD 与 Harness 的分工，并区分「做什么 / 怎么做」两层含义
能对照自查：我自己（或我的团队）目前的 AI 编程方式，踩中了哪几个坑

目标对应计划「评估标准」第 1、2 条的地基。今天不要求会写 spec（那是 Day 5），先解决认知。

2. 学习动线（建议时间分配）

步骤	内容	用时
1	场景带入：三个你大概经历过的瞬间	5 分钟
2	精读正文：资源 3《出码率 90% 却没提效？》	20–30 分钟
3	核心概念（一）：Vibe Coding 的三大瓶颈	20 分钟
4	核心概念（二）：SDD 与 Harness 的分工	15 分钟
5	当日自测 + 写 200 字反思打卡	15 分钟

先读这一节，再决定先看文章还是先看讲义：两种顺序都可以。如果读文章容易走神，就先看讲义「3、4」小节建立框架，再带着框架去读文章。

3. 场景带入：三个你大概经历过的瞬间

学概念前，先对号入座。下面三个场景，是不是很眼熟？

场景 A：出码很快，交付很慢 你让 AI 十分钟写出了接口、页面、甚至单测，感觉像开了外挂。可代码一进团队，Code Review 的人看不懂、架构师说不符合规范、测试发现改了一个地方坏了另外三处……你算了一笔账：AI 生成省下的 2 小时，全部花在解释、返工、联调上了，甚至还有多的。

场景 B：AI「前言不搭后语」 任务不大，但需求有点绕。开场你明明跟 AI 对齐了「接口要兼容老版本、不动数据库表结构」，写了两千行之后，AI 悄悄把表结构改了、接口也换了签名。它忘了前面约好的约束——不是故意，是它的上下文只能装这么多。

场景 C：它说「完成了」，你不敢信 AI 跑完说「功能已完成、测试已通过」。你打开一看，核心路径能跑，但边界情况（网络超时、权限不足、重复点击）全都没处理，测试也只覆盖了它自己写的那几条。它没有骗你，它只是不知道你不知道它不知道——而你根本没有低成本的手段去验证它说的是真是假。

这三幕，分别对应三大瓶颈：出码率≠提效、上下文失控、无法验证。下面逐一拆开。

4. 核心概念（一）：Vibe Coding 的三大瓶颈

4.1 先定义：什么是 Vibe Coding？

Vibe Coding（氛围编程 / 跟着感觉编程）由 Andrej Karpathy 在 2025 年初提出，本质是：你不再逐行写代码，而是用自然语言描述「你想要什么」，让 AI 去写，你只看效果、不看实现。

必须承认它的价值：在原型验证、一次性脚本、个人小工具这类低风险、低存量、改错代价小的场景里，它是当前最高效的方式，没有之一。这也是很多人第一次被 AI 编程震撼的来源。

问题出在：当 Vibe Coding 被直接搬进有历史包袱、有多人协作、出错要负责的生产项目时，它的三个结构性缺陷会立刻放大。

4.2 瓶颈一：出码率 ≠ 提效

Vibe Coding 最容易营造一个错觉：AI 生成代码的「成功率高」，就等于「项目提效」。但真实的全链路不是这样。

第一层，编码只占整个研发链路的一小部分。 一次软件交付，是从产品提需求、设计、编码、Review、测试、联调、到上线部署的完整链路——编码环节通常只占 20%–30%。就算编码效率翻倍，反映到整体周期上也不过是几个百分点。

第二层，AI 写的代码更省事了吗？并没有，它把时间转移了。 生成变快，但看懂它写的代码、Review、调试、改 bug 的时间在增加。有个常被引用的数据：某大模型应用平台把 AI 出码率从 53% 提升到 80%–90%，项目交付周期却几乎没缩短——编码快了，但 Review 慢了；出码多了，返工也多了。这就是所谓的「半程红利」：只吃到「写得快」那一半，没吃到「交得快」那一半。

一句话记忆：出码率衡量的是「AI 写出来多少」，交付率衡量的才是「团队用上多少」。两者之间隔着审查、验证、返工这座大山。

4.3 瓶颈二：上下文失控

第二个瓶颈来自 AI 的物理限制：上下文窗口是有限的，注意力还会随长度而稀释。 任务一大，问题就来了。

AI 编程界总结过几种典型的「失控」失败模式：

失败模式	表现
One-shot 综合征	单个任务塞进太多东西，上下文填充率过高后，输出质量会快速衰退——开头约好的架构，写到后面全忘了
过早宣布胜利	AI 在只完成了局部、还没做完整验证时就报告「搞定了」
过早宣称功能完成	没做端到端测试就标记任务完成，只测了「能跑」的部分
冷启动问题	会话之间没有持久记忆，每次开新对话 AI 都「失忆」，团队历史决策要反复重讲

更隐蔽也更致命的是隐性知识（Tacit Knowledge）的丢失。存量项目里大量「没写进文档的约定」——这个模块为什么这么设计、那条路为什么不能走、这个坑之前踩过——AI 一概不知道。OpenAI 有一句被广泛引用的话：

「Agent 的知识边界等于代码库的文件边界。如果某条架构约定没有以机器可读的形式存在于代码库中，那么对 Agent 来说，它就不存在。」

存在人脑里、聊天记录里、口头传承里的知识，AI 看不见；而 AI 看不见，就会在它「自由发挥」时替你做出违背这些约定的决定——而且你很难及时发现。

4.4 瓶颈三：无法验证

前两个瓶颈导致「它可能写错、跑偏」，第三个瓶颈最要命：你缺乏低成本的手段发现它错了。

具体有三个后果：

返工不可控：AI 自由发挥，改出来的代码和现有架构不兼容、风格不一致。典型症状：要改 15 个接口，它只改了 10 个，剩下的 5 个散落在各处，没人知道漏没漏。
不可复现：同一句话，两次生成的代码可能完全不同。出了 bug 想复现「上次是怎么成功的」，做不到。
不敢维护：AI 写出来的「黑箱代码」没有设计文档、没有测试用例、没有需求来源。将来任何人（包括你自己）要改它，只能靠猜——于是代码库慢慢变成谁都不敢碰的「雷区」。

Vibe Coding 阶段，验证主要靠「肉眼看效果 + 人肉 Review」。这在个人玩具项目里够用，在需要机器可读、可审计、可回退的工程里，等于没有护栏。

4.5 小结：三大瓶颈自查表

瓶颈	一句话	你在自己项目里的「症状」（自查勾选）
出码率≠提效	编码只占全链路 20–30%，审查返工把省的时间吃回去	[ ] 代码生成快，但 Review / 联调更慢了 [ ] 「写出来能用」和「上线没人敢改」同时存在
上下文失控	任务一大，AI 忘记前面的约束；隐性知识它看不见	[ ] 长任务做到一半 AI 开始「自由发挥」改约定 [ ] 新开对话就要把团队约定重讲一遍
无法验证	只有人能验证，而人验证不过来、也审计不了	[ ] 只改了 10/15 个接口，没人发现漏了 5 个 [ ] 改完「能跑」就直接提交，边界情况没人测

勾到的越多，说明你越需要今天下半场的答案：SDD 与 Harness。

5. 核心概念（二）：SDD 与 Harness 的分工

5.1 回应前面那道题

回到开头的问题：为什么出码率 90% 还没提效？

因为 Vibe Coding 把三件本来该分开的事压成了一件事——让 AI 同时负责「听懂你要什么」「自己决定怎么写」「自己证明写对了」。一个人（或一句话）承担的角色越多，越容易顾此失彼。

工程化的思路，就是把责任拆开，各配一套机制。这就是 SDD 与 Harness：

SDD（Spec-Driven Development，规范驱动开发）：管「做什么」。在动代码之前，先把意图写成结构化、可验收的规范（spec）。AI 不再「自由发挥猜需求」，而是去实现一份已经被约束好的目标。方向对不对，在写代码之前就定死。
Harness（驾驭工程）：管「怎么做」。这里的「怎么做」不是指代码怎么实现，而是指「用 AI 干活这件事本身，怎么被管起来」——怎么给它配规则、怎么限制它的权限、怎么在事后验证、怎么隔离上下文。它解决的是「AI 会不会跑偏、骗你、闯祸」。

计划封面那句话，就是这两者的全部关系：

SDD 告诉 AI 做什么，Harness 保证 AI 做对。

5.2 澄清一个容易混的点：「做什么 / 怎么做」到底谁说了算？

网上讲 SDD 时常说「人定 WHAT（做什么），AI 实现 HOW（怎么做）」。这和我们上面的分工听起来矛盾——到底 HOW 归 AI 还是归 Harness？

不矛盾，只是「怎么做」有两个层次，别混淆：

层次	「怎么做」指什么	归谁管
代码实现层	具体函数怎么写、用哪个库	交给 AI（人只定 WHAT，不逐行写）
工程执行层	AI 执行的过程可不可靠、结不结果对不对、跑没跑偏	交给 Harness（SDD 定好的目标，要有人保证它被执行对）

SDD 管的是「代码实现层」的 WHAT（意图与验收标准）；Harness 管的是「工程执行层」的 HOW（怎么让 AI 可靠地做对）。 两者不在同一层，所以不打架。

5.3 一个比喻：模型是野马，Harness 是缰绳与围栏

大模型是一匹很强但野性难驯的马：能力大、脾气大、会跑偏。你不可能靠「每次下命令时多求它两句」来保证它不跑偏——这相当于指望骑手嘴皮子够甜。

Harness 的创始性思路（Mitchell Hashimoto 的定义）是：

「每当你发现 AI Agent 犯了一个错误，就去工程化一个解决方案，让它再也不犯同样的错。」

它不改马的基因（模型本身），而是设计一整套控制系统：缰绳（规则）、围栏（权限与验证）、马厩（可隔离的上下文）——让马在围场里随便跑，但跑不出边界、跑错了能被立刻发现。人从「驯马师」变成「围场设计师」。

5.4 为什么对你个人也成立：个人技能 → 团队工程能力

很多人觉得「SDD/Harness 是团队、大项目才需要的东西，我一个人写脚本用不上」。这是一种误读。

不妨问自己三个问题：

你一个月前让 AI 写的代码，现在还能说清它为什么这么写、改起来不慌吗？
你要交给别人的代码，对方能看懂设计意图、敢接手吗？
你靠 AI 沉淀下来的能力，是跟着你的聊天记录走，还是沉淀成了项目里可复用的资产？

第一个问题的答案若是「说不清」，你就已经站在「个人作坊」的悬崖边上了——哪怕只有你一个人。工程化的第一受益者，往往就是那个「单打独斗的人」：它把「存留在 AI 会话里的临时记忆」变成「存在仓库里的持久资产」。所谓「从个人技能到团队级工程能力」，起点不是团队，是你自己愿不愿意把话说清楚、把验证做起来。

5.5 全景：你今天站在哪，四周要走到哪

 人（意图）──SDD──▶ 规范 spec ──▶ AI Agent（执行）──▶ 代码产物 ──Harness──▶ 验证 / 审查 / 入库
           管「做什么」                                       管「怎么做 / 做对」
     方向对不对，动手前定死                          过程可不可靠、结果对不对、能否回退

周	解决什么	对应三大瓶颈
第 1 周：SDD（认知打底）	管「做什么」：把意图写成 spec	治「上下文失控」——意图在动手前固化，AI 不用猜
第 2 周：Harness（工程）	管「怎么做」：规则 / 权限 / 验证 / 隔离	治「无法验证」——加护栏，事后能验证、能拦截
第 3 周：工程化闭环	让 spec 变可执行验收、打通 CI/CD	治「出码率≠提效」——全链路可控可回退
第 4 周：沉淀输出	固化成模板与团队流程	把个人能力变成可复用资产

今天只要求你认清方向：三大瓶颈是病，SDD 与 Harness 是药。药怎么配、怎么吃，是 Day 2（精读闭环图）之后的事。

6. 当日自测

建议先合上讲义做，再对照文末「参考答案」。目标不是全对，是暴露「我以为我懂了」的地方。

选择题（单选）

下列哪一项最准确地解释了「出码率≠提效」？
- A. AI 生成代码太慢，跟不上人写代码的速度
- B. 编码只占研发全链路的一部分，且 AI 代码带来的审查/返工成本会吃掉省下的时间
- C. 出码率高说明 AI 偷懒，没有认真思考需求
- D. 只有出码率达到 100% 才能提效
关于「上下文失控」，下列描述错误的是？
- A. AI 的任务塞得越大，越可能忘记开头约好的约束
- B. 隐性知识（团队约定、历史决策）若不在代码库里，AI 就看不见
- C. 上下文失控只影响长对话，短任务完全没问题
- D. One-shot 综合征指上下文过载后输出质量下降
「无法验证」的后果，不包括下列哪一项？
- A. 只改了部分接口，漏改的没人发现
- B. 黑箱代码无人敢维护
- C. AI 永远无法生成符合需求的代码
- D. 同一句话两次生成结果不同，难以复现
SDD 与 Harness 的分工，最准确的说法是？
- A. SDD 管代码质量，Harness 管代码速度
- B. SDD 管「做什么」（固化意图与验收标准），Harness 管「怎么做」（保证 AI 可靠做对、能验证）
- C. 两者是一回事，只是叫法不同
- D. SDD 给 AI 用，Harness 给人用

简答题

用你自己的项目（或一个想象的项目）举例：你曾经踩中过三大瓶颈中的哪一个？当时的「症状」是什么？如果按 Day 1 学到的思路，你觉得介入点应该在哪一步？
为什么说「工程化的第一受益者往往是单打独斗的个人」，而不是反过来？请用「资产沉淀」的角度解释。

7. 今日打卡输出（约 200–300 字）

Day 7 你会有「周复盘 + 第一篇学习笔记」的作业。今天先写下草稿，建议回答三句话即可：

我对 Vibe Coding 的新认知：以前我以为它 __，现在明白它 __。
我目前（或所在项目）踩中频率最高的瓶颈是 __，证据是 __。
接下来 7 天，我最想弄明白的一个问题是 __。

存成一个随手可取的文本文件（建议放在本计划同一目录下，命名如 Day1-反思草稿.md）。Day 7 会把它扩写成第一篇正式学习笔记。

8. 术语速查卡（Day 1 够用版）

术语	一句话解释
Vibe Coding	用自然语言描述需求、让 AI 全权实现、人只看效果的编程方式（Karpathy 提出）
出码率 / 交付率	前者是「AI 写出来多少」，后者是「团队真正用上多少」，两者之间隔着审查与返工
半程红利	只吃到「写得快」的一半红利，没吃到「交得快」的另一半
上下文失控	任务超过 AI 上下文承载能力后，前面的约束被遗忘、输出质量下降
One-shot 综合征	单个任务塞得过满，上下文过载导致质量衰退
隐性知识	没写进文档、存在人脑/聊天记录里的约定，AI 无法感知
无法验证	缺乏机器可读的质量门禁与审计，只能靠人肉验证且验不过来
SDD	Spec-Driven Development：先写规范再写代码，规范管「做什么」
Spec	结构化、可验收的规范文档，是 SDD 的核心产物（Day 3 讲七要素）
Harness	驾驭工程：规则 / 权限 / 验证 / 隔离等护栏，管「怎么做、保证做对」

9. 延伸阅读

今日精读（必读）

资源 3《出码率 90% 却没提效？——从「个人技能」到「团队级工程能力」的转型动因》（腾讯云）
- 主站：https://cloud.tencent.com/developer/article/2669269
- 镜像（同上文，标题含副题）：https://developer.cloud.tencent.cn/article/2669269
- 阅读时带着问题：作者说的「瓶颈不在 AI」指什么？文中的「半程红利」数据是什么？

扫读（可选，5 分钟建立全局）

资源 1《SDD 和 Harness：AI 编程的两大支柱》（CSDN）——今天只需扫到「两大支柱的分工」这一部分即可，Day 2 会精读全文闭环图
- https://blog.csdn.net/qq_43284469/article/details/164267908

同类主题对照（可选，进阶）

《从 Vibe Coding 到 Harness × SDD：AI 全栈开发的工程化进化之路》：https://cloud.tencent.cn/developer/article/2703356
阿里云《告别「氛围编程」：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践》：https://developer.aliyun.com/article/1734485

完整八条资源清单见计划主文件《SDD+Harness四周学习计划.md》的「学习资源清单」一节。

附录 A：参考答案

选择题

B —— A 与事实相反；C/D 都是对「出码率」的错误解读。核心是编码只占全链路 20–30%，且审查返工吃掉红利。
C —— 上下文失控在短任务里表现为「隐性知识缺失」，长任务里表现为「约束遗忘」，不能说短任务完全没问题。
C —— AI 能否生成符合需求的代码，取决于 spec/上下文是否清晰，不是「无法验证」导致的必然后果；A/B/D 都是无法验证的直接后果。
B —— 注意 5.2 的层次区分：SDD 管「代码实现层」的 WHAT，Harness 管「工程执行层」的 HOW。

简答题（要点，供自评）

评分看三点：① 能指认出是哪个瓶颈；② 症状描述具体（有例子）；③ 介入点能落在「动手前（定意图）」或「动手后（加验证）」，而不是「下次提示词写得更细」——后者正是 Vibe Coding 思维的惯性，而 Day 1 要破除的正是它。
要点：对单打独斗者，「个人技能」高度绑定在会话记忆里，会随对话关闭而蒸发；工程化（写 spec、留文档、加验证）把这些沉淀为仓库里可复用的资产，等于把「会一次」变成「会无数次」，并让未来的自己/他人可接手、可回退。团队只是放大了这种资产的价值，不是前提。

本资料依据《SDD+Harness四周学习计划.md》Day 1 主题编制，概念定义综合自计划文末资源清单及公开技术文章，具体以原文章为准。整理日期：2026-09-07

SDD+Harness 四周学习计划 · Week 1 · Day 1