被Vibe Coding搞累了？问题不在Cursor。KDDI给出的「设计占80%」翻盘法

引入Cursor几周后，代码确实写得更快了。Claude Code也试过。「自己也能做业务工具」的感觉回来了。

但总觉得有点累。

感觉比以前更忙了。调试AI生成的代码占去大量时间。「按理说能跑却跑不起来」的情况变多了。这种感觉，难道只有我一个人吗？

我是一个从客户成功（CS）岗位、通过Vibe Coding（氛围式编码）回到开发的前工程师。在中断了10年以上之后，重新发现了与AI一起写代码的乐趣。所以正因如此，这种「疲惫」的感觉才让我在意。深入调查后我发现，这并不是个人的问题。

本文将介绍Vibe Coding疲惫的真面目，以及KDDI正在实践的处方。先说结论：问题不在Cursor，也不在Claude Code，而在设计流程一侧。

---

「AI让我变快了，为什么反而更累」的真相

引入Cursor后的头一周令人感动。补全准确度很高。在聊天里说一句「我想要这样的功能」，它就把代码写出来。业务工具的原型一天就能搞定。

可是从第二周左右，风向开始变了。

AI生成的代码越来越频繁地不按意图运行。把报错丢给AI，它会帮你修，但又会在别处冒出新问题。代码的整体面貌看不清了，「哪里和哪里连着」要花时间才能搞明白。

回过神来，你已经比开始Vibe Coding之前更忙了。

这种感觉，其实有数据为证。

根据Harness公司2026年2月实施的调查（美英德法印五国共700名开发者），AI重度用户中有96%被夜间和周末的紧急响应缠身，开发负荷正在加重。69%的人回答「AI生成代码部署时频繁出问题」。AI让代码生成的确变快了。但下游的DevOps（开发→测试→部署的整套流程）跟不上了。这就是该调查的结论。

代码质量方面也出现了问题。GitClear的2025年报告分析了2.11亿行代码，结果显示code churn（一次写完的代码在短时间内被重写的比例）呈上升趋势。重复代码块急剧增加也被指出。AI带来的代码量增加正在推高维护成本，这种结构开始显现。

「写的量多了，要改的量也多了」。这种状况，绝不是个人的问题。

# Vibe Coding疲惫的恶性循环

需求模糊不清 → 让AI生成代码
    ↓
能跑，但和意图略有偏差的代码被生成
    ↓
手动修正 → 又有偏差 → 再修正
    ↓
对代码整体的理解跟不上了
    ↓
调试时间拉长 → 疲惫

这个循环，应该有不少人觉得似曾相识吧。

「用AI反而慢19%」的数据告诉我们什么

2025年，METR（机器学习评估的基准研究机构）实施的RCT（随机对照试验，Randomized Controlled Trial）发布了令人震惊的结果。

根据METR的论文（arxiv.org），16位熟练开发者在246项任务中分别以「使用AI」和「不使用AI」两种方式完成。结果显示，使用AI时慢19%。

而开发者本人的事前预测是「会快24%」。预测与实测之间存在43个百分点的落差。

「为什么？」很多人都会这么想。

需要注意的是，该实验的对象是2.2万星标、100万行以上的大型OSS仓库。和日常的脚本编写、小型项目条件不同。不过，「面对大型既有代码库时AI未必更快」这一事实仍有参考价值。

这项研究想说的并不是「AI不能用」，而是「引入AI就自动变快」这个前提其实站不住脚。

从我长期从事CS工作的经验来说，仅靠引入工具就改善流程的案例几乎没有。工具只是改变流程的手段。开发领域也在发生同样的事。

疲惫的真正原因是「流程未到位」

KDDI的敏捷开发中心（KAG，KDDI的内部软件开发部门）在2026年3月发布的报告，正中这个问题的要害。

根据KAG Tech Note的文章，他们将Vibe Coding疲惫的原因总结为「不是工具的品质问题，而是组织的流程与设计能力缺失」。

传统的开发流程，也就是「先做出来再修」的方式，花在设计上的时间只占整体的两成左右。实现和调试占了八成。把AI塞进这个流程里，结构并不会改变。反而因为AI会大量生成代码，「确认和调试」的工作量甚至可能变多。

问题的本质就在这里。

AI已经开始负责实现了，而人类一侧却还停留在「确认和调试」的角色。

人在设计（即定义”做什么”的工作）上花的时间并没有增加。一味地确认AI生成的代码，工作的质感不会改变。

PeopleX（一家HR平台创业公司）的案例值得参考。根据PR TIMES的发布，该公司给全体工程师配备了Cursor、Claude Code、GitHub Copilot等工具。结果，全产品新规实现的约80%变成了AI生成代码。成功的关键在于设计文档的共享方式。他们建立了**让Cursor跨项目读取MD文件（Markdown格式的文档）**的机制。因为「要做什么」的定义先于代码存在，AI才能在保持上下文的同时生成代码。

「写之前先设计」这件理所当然的事，在Vibe Coding的语境下很容易被省略。

KDDI找到的处方：「规约驱动开发（SDD）」

KAG从2025年9月开始正式引入的方法，叫做”规约驱动开发”，英文是Spec-Driven Development（SDD）。

SDD的理念本身很简单：写代码之前先写规约文档。 不过，这和传统的「先写设计文档再实现」略有不同。AI帮忙撰写规约文档，再基于这份规约文档由AI生成代码——整个流程被结构化了。

KAG目前采用的是名为”cc-sdd”的国产OSS（开源软件，任何人都可以免费使用的公开代码）。根据Qiita的解说文章，它在Claude Code、Cursor、Gemini CLI上都能运行。

KAG最初验证的是AWS Kiro（AWS的SDD辅助工具，2025年11月发布正式版）。后来出于日语支持和灵活性的考虑，迁移到了cc-sdd。

引入SDD后，据说KAG的开发流程从「设计2成:实现8成」翻转为「设计8成:实现2成」。测试覆盖率也提高了。理由是AI会预先把大量异常情况（边界情况）纳入规约文档，所以测试代码的覆盖度更高。

听到这个，我觉得和CS的工作很像。客户来抱怨「不知怎么就有点烦恼」时，急着给解决方案往往会偏离重点。先把「问题是什么」梳理清楚，再行动。开发也是同样的结构。

根据Thoughtworks将SDD作为2025年AI辅助工程实践之一介绍的文章，SDD正逐渐被认知为「氛围模式（Vibe Mode，先聊天）」vs「规约模式（Spec Mode，先规划）」两种选择。氛围模式有适合的场景。但对于需要持续维护的产品，或团队共享的代码，规约模式更合适。

用cc-sdd今天就开始实践「设计80%:实现20%」

写一下实际试用cc-sdd的流程。只要环境里装了Claude Code或Cursor，就能跑起来。

# 安装cc-sdd（需要Node.js）
npm install -g cc-sdd

# 项目初始化
cc-sdd init

# 用自然语言输入需求，生成PLAN.md
cc-sdd plan "想做一个工具，监控Slack某个特定频道，
             当包含关键词的消息到来时，
             通过邮件发送通知"

执行cc-sdd plan后，AI会拆解需求并生成PLAN.md（整体设计文档）。在这个阶段，一行能运行的代码都没有。取而代之的是「要做什么」的设计文档。

# 审阅PLAN.md后，按功能单位生成SPEC
cc-sdd spec --feature slack-monitor

# 生成SPEC.md（功能的详细规约文档）
# 列出输入、输出、错误处理、边界情况

# 规约文档完成后再生成代码
cc-sdd implement --spec slack-monitor

# 测试代码也自动生成
cc-sdd test --spec slack-monitor

这套流程里最见效的，是「错误处理和边界情况由AI预先考虑好」这一点。Vibe Coding卡住的原因，大多是「在意料之外的情况下停下来」。规约文档里写明白后，AI从一开始就会生成包含这些情况的代码。

调试量大幅减少。

老实说一句：cc-sdd还是一个成长中的OSS，文档以英文为主。卡住的时候可以参考Qiita的解说文章。不熟悉的话，不必勉强使用cc-sdd。哪怕只是模仿「先自己写PLAN.md，再让AI实现」这个顺序，也会有效果。比起工具，习惯更重要。

另外，在英语圈，GitHub官方提供的「GitHub Spec Kit」也是一个选项。AWS Kiro在与云基础设施联动的用途上有优势。选择适合自己环境的就好。

「我的团队现在卡在哪里」自检清单

针对「SDD的理念我懂了，但不知道是否适用于自己」的读者，我整理了一份按阶段诊断的自检清单。

卡在实现阶段的模式

• AI生成的代码，每次都要大幅手动修正
• 把错误信息原样粘给AI已经成了每日例行
• 「先跑起来再说」成了口头禅
• 没人能看清代码的整体面貌，这种状态持续中

如果是这种模式，很可能是「先写规约文档」这个阶段根本就不存在。值得尝试cc-sdd或AWS Kiro。

卡在设计阶段的模式

• 「要做什么」的定义，是在聊天里边和AI讨论边决定的
• 功能边界还没厘清，实现就已经开始
• 规约文档或文档是事后补写（或干脆没写）
• 每次给AI的请求都变成长长的说明文

这种模式，靠有意识地增加设计时间就能解决。这更接近产品经理或CS的工作。对于以前没把「整理需求」纳入工程师工作范畴的人，这次转变尤其见效。

卡在部署/QA阶段的模式

• 不写测试代码就直接部署到生产
• AI生成代码的Review被省略
• 「本地能跑生产跑不了」反复发生
• AI生成代码的意图没有在团队中共享

这种模式正是Harness调查所指出的「代码生成快了但DevOps流程跟不上」的结构本身。养成让AI同时生成测试代码的习惯，这一块会迅速改善。

看完清单，会发现一件事：因为「AI的锅」而卡住的情况其实很少。绝大多数都来自人这一侧的流程。

这和我在CS岗位上观察了10年的结构是一样的。人们总以为引入工具就能解决问题，但如果使用流程不变，状况就不会改变。

总结：先理顺流程，再谈工具

引起Vibe Coding疲惫的，并不是工具的极限，而是流程的不到位。

正如METR RCT所揭示的，只是用AI并不会自动变快。哪怕代码量增加，如果省略了「做对的东西所需的设计」，就会陷入调试和修正的循环。

KDDI展示的「设计8成:实现2成」翻转，并不需要什么特别的技术。它只是「写代码之前先写规约文档」这个习惯的改变。cc-sdd则是迈出这个习惯第一步的入口。

不需要写出完美的规约文档。只要对AI说一句「先帮我做个PLAN.md」就行。这30分钟的投入，能消掉之后几个小时的调试。

希望你能想起来，Vibe Coding本来是一件令人开心的事。

---

图片指令一览

#	位置	type	说明
1	文章开头	eyecatch	疲惫的工程师在电脑前抱头
2	H2「慢19%」之后	diagram	METR RCT结果图（AI使用vs未使用的工作时间对比）
3	H2「疲惫的真相」之后	comparison	传统流程（设计2成:实现8成）vs SDD（设计8成:实现2成）对比图
4	H2「cc-sdd实践」内	diagram	cc-sdd工作流图（5步流程图）

合计：4张