作者前言：写了 30 多篇 Claude Code 深度教程后，我发现自己陷入了一个怪圈：教程里我把 AI 调教得像 F1 赛车手，现实中做复杂迁移时我却像个推着卡车过泥潭的苦力。直到我亲手打碎了“规范优先”和“并发崇拜”的滤镜，才找到了真正的提效之道。
一、 被神化的“理想态” vs 残酷的“现实态”
作为写过几十篇 AI 编程教程的人，我必须承认一个事实：我们被 Demo 骗了。
外面铺天盖地吹的 SDD（规范驱动开发） 和 Multi-Agent 并发协作，在绿地项目（Greenfield）里或许成立，但在棕地项目（Brownfield，尤其是复杂迁移）里，它们往往是生产力的黑洞。
1. SDD：双倍重工的深渊
在复杂迁移中，业务规则往往是模糊的、充满历史包袱的。
- 理想：写好 Spec → AI 精准实现 → 一次过。
- 现实：我花 2 小时写 Spec（试图把脑子里的隐性逻辑显化）→ AI 生成代码 → 我发现 AI 理解错了（因为它不懂老系统的潜规则）→ 我改 Spec → AI 再生成……
- 结果：写代码的时间 < 写文档 + 对齐的时间。 需求一旦变更，噩梦加倍。
2. 并发 Agent：把“写代码”变成“审案子”
我试过开 3 个 Claude Code 窗口并发干活。
- 理想：并行加速，效率 x3。
- 现实：AI 生成速度是毫秒级，我 Review 是分钟级。我被迫在三个不同的上下文里疯狂切换（Context Switching），还要时刻警惕它们互相改坏对方的代码。
- 结果：省下的打字时间，全赔给了审核成本和心智负担。
二、 我的“反潮流”实战策略
经过无数次撞墙，我总结出一套 “动态分级 + 人脑主刀” 的策略。这套策略不追求极致的自动化，只追求可控、自由、不累。
策略一：按“业务重要性”切分模式
我不再试图用一种模式统治所有代码。
| 场景 | 策略 | 原因 |
|---|---|---|
| 核心流程 / 复杂迁移 | 人工优先，AI 为辅 | 这是“修文物”。我掌控等价性、边界和回滚预案。AI 只负责查文档、找边界 Case、生成样板代码。 |
| 重要但改动小 | 轻量 SDD | 规则稳定，值得花时间定契约（Schema/Type），防止 AI 乱来。 |
| 非核心 / 探索性功能 | 手拆任务，随写随喂 | 这是“搭积木”。我不写长篇 Spec，直接拆成粗粒度任务，想到哪写到哪，Prompt 现写现用。 |
策略二：拒绝“过度拆解”，拥抱“即时编译”
我不做精细到函数的任务拆解，因为维护任务列表本身就有巨大成本。
- 以前：先花半天拆解任务 → 写详细 Prompt → 喂 AI → 发现不对 → 改任务 → 再喂。
- 现在：我脑子里有个大致方向，一边写一边拆。遇到需要 AI 帮忙的地方，当场写 Prompt 喂给它，像“即时编译”一样。
- 好处：需求变了？我直接改代码，不需要回去维护那堆已经过期的任务文档。
策略三：严格控制并发（<=2）
我放弃了“火力全开”的幻想。
- 复杂逻辑：单线程。我要的是稳，不是快。
- 模板/文档/测试：最多开 2 个窗口。超过这个数，我的脑子就开始过热报警。
三、 为什么我写的文章和现实差距这么大？
这是一个很扎心的自我剖析，也是我想分享给所有技术博主和读者的：
-
写作是静态的，工程是动态的。
写教程时，我需要构建一个完美的闭环逻辑（A → B → C）。但在真实项目里，PM 随时可能改需求，老代码随时可能藏着雷。教程展示的是 Claude Code 的“实验室性能” ，而我现在的实战，是在跑 “上路实测” 。
-
教程教你怎么“开车”，现实教你修“老爷车” 。
我的教程教大家怎么用 Headless 模式、怎么配置 Subagents、怎么玩 Plan 模式。这些都是对的，但那是针对新车（新项目） 。而我现在面对的是满是锈迹的老爷车（老系统迁移） 。在泥潭里，氮气加速（高级并发）只会让你陷得更深。
四、 结论：回归工程本质
AI 不是员工，它是外挂。
SDD 不是真理，它是护栏。
如果你也在被复杂的业务逻辑折磨，请记住：
- 不要为了用 AI 而用 AI。80% 的时候，人脑的直觉剪枝比 AI 的穷举生成更快。
- 不要迷信规范。在不确定性面前，轻装上阵比负重前行更安全。
- 把 AI 关进笼子里。让它做它擅长的（检索、样板、补全），把决策权和边界感牢牢握在自己手里。
真正的提效，不是让 AI 写更多的代码，而是让你不用再去操心那些不该操心的细节。
如果你也经历过从“AI 狂热”到“AI 冷静”的过程，欢迎在评论区聊聊你的实战体感。
