AI 编程的痛点清单：社区到底在抱怨什么¶
2026-07-03
2025 年初，Karpathy 造了 "vibe coding" 这个词——凭感觉写代码，忘掉代码本身的存在。一年之后，连他自己都说这个时代正在结束，我们在进入"agentic engineering"。于是 Spec-Driven Development（规范驱动开发）成了新的关键词，工具一夜之间冒出一大批：GitHub Spec Kit、Amazon Kiro、Tessl、OpenSpec、BMAD……
我们做 SpexCode，当然是站 spec 这一边的。但在讲我们自己的故事之前，我们想先做一件更老实的事：不带预设地去社区里看看，大家真正在抱怨的到底是什么。
于是我们花了一段时间，翻了 Hacker News 上十来个高热讨论帖（合计几千条评论），以及十来个 SDD 开源项目的 Issue 和 Discussion 区（六十多条独立抱怨）。下面这份清单，引用尽量用原话，每条都链到出处。我们的观点放在最后——你可以先跳过它，只看社区自己说了什么。
怎么读这份清单¶
每一条痛点，我们按三个维度评估严重程度：
- 广度——有多少互相独立的人、跨多少个帖子在复现它；
- 强度——情绪有多重，实际损失有多大；
- 是否已被解决——有没有哪个工具真正把它解掉了。
综合成三档：🔴 P0 致命且普遍未解 ／ 🟠 P1 严重 ／ 🟡 P2 中等或局部。
有一点得先说清楚：社区连"vibe coding"到底指什么都吵不拢（是 Karpathy 那种"忘掉代码"，还是任何用 LLM 辅助的编码？）。很多火气其实是定义之争。下面只保留对实际做法的、能反复复现的实质抱怨。
一、Vibe Coding 的账，第 90 天要还¶
最普遍的一条：所谓"一次性原型代码"根本不会被扔掉，它会直接上生产，然后再也没人重写。
"'一次性原型代码'被直接推上了生产，再也没更新过——因为它此刻正解决着真实需求，而没时间去修。vibe coding 把这个问题放大了很多。" —— HN 用户 @Analemma_，《Vibe Debugging: Enterprises' Up and Coming Nightmare》
"没有比一次性原型更永久的东西了。" —— HN 用户 @Sharlin，同帖
而技术债会以指数方式复利：
"3 个月后你发现了一个并发问题。但它现在已经以几百种变体散布在全代码库里。你到底要怎么修？" —— HN 用户 @kikimora，《The problem with "vibe coding"》
社区把这个现象叫做"第 90 天的清算"（the 90-day reckoning）：大约到第三个月、代码量越过某个规模之后，加新功能开始不断弄坏旧功能，维护成本开始超过手写。
严重度：🟠 P1。 极其普遍。需要说明的是，网上流传的那些具体数字（"测试覆盖率 12%""维护成本涨 300%""2028 年 40% 项目被取消"等）大多只能追溯到厂商营销博客、缺乏一手出处，不建议直接引用。真正经得起推敲的一手证据是 METR 的随机对照实验——16 名资深开源开发者、246 个真实任务，开发者事前以为用 AI 会快 24%、事后仍觉得快了 20%，而实测反而慢了 19%（arXiv 2507.09089，metr.org，2025-07）。它印证的不只是"技术债有多贵"，而是更底层的一点：连"更快"本身，都可能是一种错觉。
二、生成变便宜了，审查却成了瓶颈¶
这可能是所有讨论里最一致的一条结构性观察：AI 让"写"变便宜了，于是成本全被推到了"审"这一端——而审查不可扩展。
"组织现在生成 10 倍的代码，因为人人都能写了。但审查者的数量一个都没变。" —— HN 用户 @whatever1，《Vibe code hell has replaced tutorial hell》
"审 AI 生成的 PR 一点都不好玩……来回拉扯远比自己写要久。我怀疑那些'更高效'的说法，根本没算完整的开发周期。" —— HN 用户 @unzadunza，《Vibe Debugging》
更狠的一层：审查的前提是理解，而你没法审查你看不懂的东西。
"看不懂全貌，你就只能'凭感觉审查'（vibe-review），祈祷它没搞砸。" —— HN 用户 @louthy（40 年工龄），《Vibe coding creates fatigue?》
而 AI 的产出恰恰"看起来像好工程"——这正是它最危险的地方：
"agent 写的代码，在生成和展示给你的那一刻，看起来可信又漂亮。它连 PR 都很好看——因为你和 agent 都被训练得很懂什么叫'好 PR'。" —— 引自《After two years of vibecoding, I'm back to writing by hand》（@simonw 转述）
"看起来架构精良、工程规范。可一旦你用上一周，就会发现它全是 bug，那套'一致的架构'只是装出来的。生成代码专门被优化成'读起来很工程化'，这让问题正在急剧恶化。" —— HN 用户 @blablabla123，《The problem with "vibe coding"》
严重度：🔴 P0。 广度极大，且无解——因为它是"生成便宜、验证昂贵"这一根本非对称性的直接结果。
三、意图丢失：没人知道"为什么这么写"¶
排障时最痛的一刻：出了 bug，却找不到任何人能解释当初为什么这么改。
"工程师短时间里推平了惊人的工作量。可等一个必然的 bug 冒出来——'嘿，你把这里的事务处理方式改了，引发了一个诡异的竞态，为什么改？'——回答是'不知道，AI 干的'。这让追查难度呈指数级上升。" —— HN 用户 @frio，《Vibe coding creates fatigue?》
"LLM 不在乎'故事'，它只在乎代码的当前状态……它看不到那些迭代、hack、重构和回退。最后，我在几乎不用 AI 的情况下，从头重新设计了我的库。" —— HN 用户 @tomaytotomato，《Vibe coding kills open source》
原始意图是一份珍贵资产，而它在代码里无法被完全看见。 这一条我们感受尤其深——它正是《第二天问题》里那条"隐藏知识与坍缩"的另一面。
严重度：🟠 P1。 普遍，且随项目复杂度加重。
四、于是大家转向 Spec-Driven——但账单来了¶
上面这些痛点，正是 SDD 工具宣称要解决的：把意图写成规范、让规范成为唯一真相、用规范约束 agent。听起来很对。但社区在这些工具的 Issue 区里，报告了一组新的账单。
换皮的瀑布 / "制造工作的假象"。 这是被重复最多的框架：
"SpecKit 制造了一种工作的假象——生成一大堆文字……过度工程，因为 LLM 不去执行一条简洁的命令，而是忙着分析几 KB 的文本、再生成新的文本，彻底丢掉了活儿的本质。" —— GitHub github/spec-kit Issue #75（即被广泛转发的 Discussion #1784）
"我们重新发明了 Big Design Up Front（大设计先行）。只是把 Word 文档换成了 Markdown，把项目经理换成了 LLM。" —— Nils Kjellman，《Your Spec Driven Workflow Is Just Waterfall With Extra Steps》
仪式过重，成本翻倍。 有人拿"直接对 agent 提示"做基线，一测就穿：
"还没写出一个文件，token 就已经飙到 20k 以上……但我直接对 Claude 发一条命令，2k token 就完成了第一个任务。" —— claude-code-spec-workflow Discussion #41
"OpenSpec 多写了 50% 的代码、复杂度高 50%……耗时翻倍，成本三倍。" —— openspec Discussion #1159
Kiro 的成本抱怨更激烈（AWS 后来承认存在一个计费 bug）：
"分配的月度额度在 15 分钟内被完全耗尽。" —— kiro Issue #2171
上下文饱和——最大的反讽。 本该"提供上下文"的规范，反而把上下文窗口挤爆了：
"spec-kit 命令消耗约 18.6k token"——约等于 Cursor 默认窗口的 93%——"形成了一笔可观的'上下文税'，压缩了真正干活的空间。" —— spec-kit Issue #1401
"往上下文里塞几 KB 文字，它就会随机失败。输入越多，结果越不可预测……我把 CLAUDE.md 缩到三分之一，稳定性反而大幅改善。" —— spec-kit Issue #75
严重度：🟠 P1。 在 SDD 工具用户里相当普遍，尤其打击中小改动。
五、最扎心的一条：spec 和代码，终究会漂移¶
如果只能记住一条，请记住这条。SDD 整个卖点是"规范是活的唯一真相"，而这恰恰是用户报告失败最集中的地方：代码在规范之外被改动之后，没有任何东西负责把两者对齐。我们没有找到任何一个用户报告说"规范能从代码自动更新"。两个项目的维护者甚至公开承认这块没做。
"理想情况下，代码与规范之间的任何漂移都应该被'调和'。理想中这应该自动发生，不需要你操心……但在实现之前，很遗憾，这个过程只能手动。" —— openspec 维护者，Discussion #169
"晚上 11 点的快速修改，谁都不记得回去同步规范。等你下次开会话，规范已经过期了，而 agent 正拿着过时的上下文在干活。" —— 同帖
"实现之后，规范很快就过期了……理想中应该有个后台任务，能检测功能何时偏离了原始规范，并建议改动把它拉回来。" —— spec-kit Issue #620
Kiro 的三个规范文件同样不会自更新，用户只能手动 git diff 去核对：
"requirements 和 design 产物不会自动更新。" —— François Dexemple，《Brilliant, Broken, and Frustrating: My Deep Dive into Amazon's Kiro AI IDE》
品类层面的定论也很干脆：
"让规范与代码保持同步，制造了一笔随系统复杂度增长的维护税……每一次更新，都变成了伪装成工程纪律的文档债。" —— Isoform，《The Limits of Spec-Driven Development》
严重度：🔴 P0，且公认未解。 横跨 OpenSpec（≥8 个 issue）、Spec Kit（≥6 个）、BMAD、Kiro（发布后才开始补 git-ref 检测）全线复现，维护者自认无解。这是整个品类的真空。
六、散文管不住 Agent：社区在主动求"机制"¶
第二响的主题，是工作流里写死的步骤，agent 当"建议"看：跳步、偏离规范、把占位符假标成"已完成"。
"Claude 在第 8 步（质量检查）之后就停了，把'技术上能跑'当成了'完成'——不 commit、不开 PR、不清理……工作只存在于特性分支里（僵尸工作）。" —— agent-os Issue #36
"/create-spec、/execute-task 这些命令被当成了建议……Claude Code 频繁无视强制步骤。" —— agent-os Issue #33
有意思的是接下来发生了什么：用户开始主动请求"确定性的、绕不过去的强制机制"。
（请求）"用 hook 来做确定性的工作流强制。" —— agent-os Issue #37
"让'标记任务完成'在结构上变得不可能——无论 AI 的提示词里说了什么，都绕不过日志这一关。" —— spec-workflow-mcp Issue #199
换句话说，社区自己得出了一个结论：光靠散文（提示词、规范文档）约束不住 agent，需要的是机制。
严重度：🔴 P0。 因为这是社区从痛里长出来的方向性共识，而不是某个厂商的营销。
严重程度总表¶
| 痛点 | 严重度 | 广度 | 是否已解 |
|---|---|---|---|
| Spec ↔ 代码 漂移 | 🔴 P0 | 全品类普遍 | 公认未解 |
| 散文管不住 Agent（跳步 / 偏离 / 假完成） | 🔴 P0 | 全品类普遍 | 未解，用户在求机制 |
| 审查负担倒挂（生成便宜、验证是瓶颈） | 🔴 P0 | 极普遍 | 未解 |
| "看着像好工程"的 slop | 🟠 P1 | 极普遍 | 未解 |
| 上下文饱和（规范反而挤爆窗口） | 🟠 P1 | SDD 工具普遍 | 未解 |
| 原型直上生产 / 90 天技术债墙 | 🟠 P1 | 极普遍 | 未解 |
| 成本 / Token 暴涨（对比纯 agent 基线） | 🟠 P1 | SDD 工具普遍 | 未解 |
| 意图丢失（没人知道"为什么这么写"） | 🟠 P1 | 普遍 | 未解 |
| 仪式过重 = 换皮瀑布 / 假象工作 | 🟠 P1 | SDD 工具普遍 | 未解 |
| 非确定性（同一规范跑两次结果不同） | 🟠 P1 | 普遍 | 本质难解 |
| 认知疲劳 / 永不完工的警戒性倦怠 | 🟠 P1 | 强烈复现 | 未解 |
| 测试是假安全（LLM 作弊过自己写的测试） | 🟠 P1 | 常见 | 未解 |
| 过度工程 / 无视既有代码库 | 🟡 P2 | 常见 | 未解 |
| 技能萎缩 & 新人断代 | 🟡 P2 | 社会层面 | —— |
| OSS 维护者被 AI slop PR 淹没 | 🟡 P2 | OSS 局部但已发生 | 未解 |
我们从这份清单里读到了什么¶
到这里，观察结束。下面是我们的解读。
三条 P0 是彼此咬合的：审查不可扩展，是因为 agent 生成的代码里丢掉了意图、又会随时漂移离规范；而之所以压不住它，是因为大家一直在用散文（提示词、越写越长的规范文档）去约束一个不读散文的东西。
有意思的是，社区自己已经把答案的形状喊出来了——"要机制，不要更多散文"（agent-os 求 hook 强制，spec-workflow 求"结构上不可能绕过"）。
这正是 SpexCode 的下注：
- 对付漂移——我们不把规范当成一份需要你记得去回写的文档。一个节点的"版本"就是它
spec.md的内容提交数，漂移直接从 git 实时推导，不存哈希、不靠自觉。规范和代码被同一套 gate（pre-commit、main-guard、commit-before-declare）强制绑在同一次提交里落地。 - 对付"散文管不住 agent"——契约在 SpexCode 里是数据（一个 config 节点），经 harness 自动发现后成为始终在线的机制，而不是启动时的一段
--append-system-prompt。社区在别处求的"确定性强制"，在这里是默认形态。 - 对付意图丢失——原始意图和设计决策就留在代码旁边、可以被读到；recent / history 的版本时间线，加上每次提交的
Session:归因，把"为什么这么改"从 git 里还原出来。
我们并不觉得自己已经解掉了漂移——这是一道全行业的难题。我们只是选择把"git 就是数据库"这条项目最极端的信念，用到底：让规范与代码在 git 里被同一套机制强制同步，而不是靠谁的自觉。 这也是我们在《第二天问题》里说的那件事——把 agent 那条水平的能力曲线，掰弯向上。
信息来源：Hacker News 讨论帖——《Back to writing by hand》《Vibe coding kills open source》《Fatigue》《Vibe code hell》《Vibe Debugging》《Waterfall Strikes Back》《Are you still using SDD?》；GitHub 项目——spec-kit（#75/#1784、#464、#620、#1401）、Kiro（#2171）、OpenSpec（#169、#1159）、agent-os（#33/#36/#37）、spec-workflow-mcp（#199）、claude-code-spec-workflow（#41）；长评——Nils Kjellman、Isoform、François Dexemple（Kiro 评测）、Red Hat；生产力数据来自 METR 随机对照实验（arXiv 2507.09089）。引用均为原话，翻译如有出入以原文为准。