用了大半年 AI Coding，我来聊聊10倍效率提升
最近 Vibe Coding 这个词越来越火。各种 "10倍效率"、"颠覆软件开发"、"程序员要失业" 的说法满天飞。
我用 AI 做了几个真实项目——一个个人财务管理系统、一个个人博客、还有一个招聘相关的Agents。踩了不少坑，也有不少收获。今天就来说说我的真实感受。
先说一个很有意思的对比
前段时间 Anthropic 发布了一个案例，让我印象深刻：
他们用 16 个 Claude Agent 并行工作，每个跑在独立的 Docker 容器里，几周内从零写了一个包含 10 万行代码的 C 编译器，能成功编译 Linux 内核。API 费用大约花了 2 万美元。
从任何角度看，这都是个了不起的成就。
我把这个发给一个做 CTO 的朋友，他的回复是：
"AI 大大放大了焦虑感。在这么纷繁复杂的时候，我觉得最好的策略是等待。"
这两个反应放在一起，就是我今天想聊的核心问题：AI/Vibe Coding，到底是真实的生产力革命，还是被过度炒作的焦虑收割机？
为什么周围有这么多质疑的声音？
我朋友说的 "焦虑收割机" 这个形容很准确。
当一个行业出现很多贩卖焦虑的声音——"再不上车就被淘汰了"、"用这个能赚大钱"——这就很危险了。那些说 "AI 现在已经完美了" 的人，基本上都是在忽悠。
但另一方面，大趋势是真实的。完全否定，视而不见也是错的。
Vibe Coding 为什么让人失望
Vibe Coding 就是用自然语言描述你想要什么，让 AI 搞定实现细节。听起来很美，Demo 看起来也很顺滑。
但实际用起来，会碰到这几个问题：
Session 越长越跑偏
AI 的 Context 是有限的。你跟它聊了一个小时之后，它开始忘记你在开头定下的架构约束。第二个小时写出来的代码，和它第一个小时同意的设计已经对不上了。我做财务系统的时候就踩过这个坑，聊了半天，发现前后接口定义都不一致了。
没有测试，AI会高效地解决错误的问题
这是最致命的。你的验证不严格，AI 就会满怀信心地给你造一个你没要求的东西，而且速度极快。Anthropic 做编译器的团队在 Test Suite 上投入了大量精力，就是因为没有严密验证的 AI 跑得越快，偏得越远。
Spec 驱动失去了 Pair Programming 的感觉
我试过把一个功能拆成 40 多个细粒度任务，每个都写好 Spec。AI 确实没乱跑，但我不再像在协作，更像在盯着进度条。维护文档的开销开始吃掉效率的提升，而且那种"和 AI 一起解决问题"的感觉没了，变成了"等 AI 干活"。
开多个窗口、跑多个 Agent，瓶颈反而是自己
我以为多开几个 AI 窗口可以并行推进多个任务，结果发现自己的注意力才是最稀缺的资源。不停切换 Context，反而失去了焦点。
那么，什么真正有效？
踩了这些坑之后，我总结了一些在Claude Code的实际有用的做法：
1. 项目 Context 文件是基础
CLAUDE.md文件很重要，把你的架构约定、技术决策、以及之前踩过的坑都写进去。
AI 每次犯了不该犯的错，就往里加一条记录。这个文件会随着项目推进越来越有价值，复利效应非常真实。这其实就是给 AI 建立 "项目记忆"，让它不用每次从零开始理解你的系统。
2. Plan → Review → Execute，不要 Vibe → Fix → Vibe
感觉上来了就写 → 发现不对 → 再改，这个工作流其实很低效。
更好的节奏是：先用 Planning Mode 设计方案，自己 Review 一遍确认方向，再让 AI 去执行。看起来多了步骤，但避免的返工比这点开销多得多。Claude Code提供了superpowers和plan-in-files的skills非常有用，我现在用持久化的 Markdown 计划文件来跨 Session 保存规划，AI 接着读，不用重新交代背景。
3. 能用 Tool 解决的，别让 AI 凭感觉猜
凡是确定性的操作——查配置、跑命令、执行已知流程——都应该封装成 Script，Skill 或者 MCP Tool，而不是每次让 AI 自己琢磨怎么做。
越约束问题空间，输出越可预测。我做了不少这样的小 Skill，比如一键提交代码、一键构建镜像，把复杂操作变成简单指令，AI 调用起来又快又准。
4. Knowledge Base 很重要
架构设计文档、接口规范、团队约定的 Best Practice——这些参考材料对 AI 的输出质量影响极大。
有了好的 Knowledge Base，AI 就能从你的真实 Context 出发，而不是靠猜测发明一套自己的规则。Anthropic 做编译器的时候，要求 AI 写代码前必须先读文档，改完代码必须更新文档，这套 "文件即真相" 的思路让多个 Agent 协作起来几乎没有信息差。
5. 给 Example 比给描述管用得多
这一点真的非常被低估。
你给 AI 一个现有的组件、一个类似的接口实现、或者一个之前写好的模块作为参考，输出质量会显著提升。AI 非常擅长模式扩展——有了 Example 它就扩展你的风格，没有 Example 它就自己发明一套。两者的质量和速度差距可以达到十倍。
6. Test 是让 AI 自主工作的前提
没有自动化验证，你就没法让 AI 独立运行，因为你不知道它有没有跑偏。
Test 是把 AI 从 "需要时刻盯着的工具" 变成 "可以放手干活的 Pair" 的关键。我现在喜欢用合约驱动的方式：先定好接口，让 AI 根据接口生成 Test Case，再让它写实现。边界清晰，验证严格，AI 自己能跑通 Test 才算完成任务。
7. 做减法，不要做加法
AI 很容易给你生成很多东西：详细的文档、完善的 Error Handling、各种抽象层。大部分都会让 Codebase 更难维护。
真正有用的纪律是做减法：用 .claudeignore 控制 Context 范围、文档写短写精、小步迭代保持可 Review 性。复杂性生成起来成本极低，维护起来代价极高。
8. 敏捷的思路在 AI 时代更有效
以前 Agile 是为了加快团队协作的节奏，现在这套思路完全可以用在一个人身上。
设计、开发、测试、上线，可以在一次专注的工作里全部完成。小步迭代、Test First、即时反馈——在这种工作方式下，AI 的价值发挥得最充分。
我的两个不成熟的尝试
Spec Driven 的尝试：喜忧参半
我试过给每个任务写完整的 Spec 再交给 AI。好处是不容易失控，坏处是文档本身太多，消耗了大量时间和 Token，一个功能拆成 40 多个 Task，漫长的等待让人觉得自己是甲方，而不是在和 AI 协作。关于Spec Driven等我下次再写一个文章
多 Agent 并行的尝试：瓶颈不在 AI
开多个窗口让多个 AI 实例并行推进不同任务，理论上很美。实践中发现，自己的注意力才是最稀缺的资源，频繁切换 Context 反而降低了整体效率。
从个人到团队，挑战就来了
个人生产率的提升是真实的，我对这点没有任何怀疑。而且 AI 还能让组织结构更扁平——Manager 更容易通过 AI 快速了解技术细节，IC 能独立承担更多端到端的工作。
但如果你在大公司，问题就复杂得多。
个人 10 倍，10人组织不是 10×10
假设每个工程师都提升了 10 倍，直觉上觉得团队整体也会 10 倍。但大企业有大量的跨团队依赖，个人跑得再快，还是得等 Product 确定需求、等 Security Review、等下游团队的接口。个人速度提升，往往只是让这些等待更显眼，而不是消除它们。
要真正在组织层面放大效率，需要配套的 Knowledge Graph、统一的 MCP Tool Library、共享的 Skill 规范——让每个人的 AI 都在同一套语境下工作，才能做到高内聚、低耦合，把协作成本降下来。
AI 会把简单的东西过度工程化
这是个很反直觉的问题。AI 生成的东西往往太完美：文档很详尽、代码结构很工整、流程很严密。但过于精密的东西难以修改，有不同意见的时候也更难说服对方——因为那套东西看起来那么"专业"，反而增加了协作冲突。有时候一个粗糙但大家都能动手改的方案，比一个完美但只有 AI 能维护的方案更有价值。
Production变更不能让 AI独立做
线上 Incident 的代价可能是真实的商业损失，不可逆。AI 可以制定方案、在 Staging 验证、生成 Runbook，但执行 Production 变更这一步必须有人 Review 和确认。这不是对 AI 不信任，这是正确的系统设计。
技术能力退化是个慢性风险
全程依赖 AI 做技术决策，时间长了你自己的判断力会悄悄退化。等 AI 出错的时候，你可能已经没有能力识别它错在哪。保持真实的技术深度，有时候就是得绕开 AI 自己动手。
管理层的期望才是最难管理的变量
"我们用了 AI，效率应该 10 倍，为什么 Roadmap 没有 10 倍？" 这个问题如果不提前管理好预期，会直接导致团队 Burnout。AI 提升的是执行效率，不是决策质量，也不是需求的合理性。这个边界需要提前跟 Stakeholder 说清楚。
说到底，我怎么看这件事
AI Coding 是真实的，生产力的提升我亲身经历过。
但它是一个易学难精的东西。上手门槛低，但真正用好的门槛很高。随便 Vibe 和系统性地用好，效果差了不止一个数量级。
我的真实数字：在合适的任务上——新功能开发、局部重构、文档、Test 生成——我能稳定看到 3 到 5 倍的效率提升。不是每天，不是所有事情，但在它真正发挥作用的地方，是实实在在的。
工具已经足够好了。
瓶颈不在工具，在用工具的人——他们愿不愿意投入时间建立正确的工作方式、维护好 Context、在该约束 AI 的地方约束它、在该放手的地方放手。
问题不是 AI 能不能做到 10 倍。在对的条件下，它可以，甚至更多。
问题是，你有没有把条件建好。
