OpenAI花3年藏了这功能，程序员发现后集体破防

2024年，GitHub Copilot用户平均每月接受AI生成的代码建议超过40%。但同一批用户的代码回滚率在下半年暴涨了23%——不是因为AI写得慢，是因为它写得太快，快到让人忘了问"这真的对吗"。

这不是工具的问题。这是流程的崩塌。

AI编程最大的坑，不是代码报错，是你根本不知道自己跳进了什么坑。

我见过太多工程师的噩梦：一个功能跑通了，上线三天后才发现限流策略选错了，认证逻辑埋了雷，分页方案在数据量上来后直接卡死。AI帮你填了每一个空，但没人告诉你这些选择是不是你的系统真正需要的。

代码能编译，所以一定对吗？

这个周末，我决定把完整的流程摊开来。不是那种"提示词工程"的玄学，而是产品经理出身的工程纪律——怎么用AI搭出不会散架的应用。这是第一部分：规划阶段。大多数人跳过这一步，而跳过的代价最高。

Plan Mode：把工程纪律塞回AI工作流

软件工程从来都不是先写代码。理解问题、探索方案、分析权衡、最后才动手。但AI进场后，这套流程被压缩成一句话：一个提示词扔进去，AI填满所有空白，我们管这叫"效率"。

GitHub在2024年底推的spec-kit工具链，本质上是在对抗这种压缩。/specify、/plan、/tasks三个命令，强制你在写第一行代码前先交出一份设计文档。工具变了，工程没变。

我的路径更原始：脑暴倾倒→AI生成完整方案→像审设计文档一样审AI的输出→迭代到架构收紧。起点一样混乱，终点完全不同。

关键动作发生在plan mode（规划模式）。不是往备忘录里乱写，而是直接告诉AI："拿着这堆混乱，给我理出一张地图。"脑暴和规划请求一次性完成。

我打开Claude Code，切到plan mode，输入的内容长这样：

"做一个给远程团队用的异步视频工具，核心是让录屏像发消息一样简单。需要网页录制、即时分享、团队空间、评论时间戳。技术栈倾向现代全栈，但具体用什么没想好。目标用户是25人以下的产品团队。竞品看过Loom但觉得太重……idk what else"

字面意义上的"我不知道还有什么"。但这正是plan mode要的东西——未过滤的原材料，而不是 polished 的伪需求文档。

AI交出的不是代码，是架构评审材料

三分钟后，Claude返回的东西让我停下了手边的事。不是代码片段，是一份完整的技术设计文档（Technical Design Document），格式规整得像资深工程师在架构评审会上递过来的那种。

技术栈被拆成四层表格：后端选Node.js+Fastify，理由是原生JSON Schema验证和插件生态；前端用Next.js 14，为了Server Components减少客户端JS；数据库挑PostgreSQL+Prisma，ACID事务和类型安全；存储直接上Cloudflare R2，S3兼容但出口流量免费。

每一行都有"Why"列。这不是AI在炫技，是在逼我做选择题。

我盯着Auth Strategy那一行。AI给了三个选项：NextAuth.js（最快，但锁死在Next生态）、Clerk（功能全，按月活收费）、自研JWT（灵活，维护成本高）。它没替我选，而是把权衡摆成一排。

这就是plan mode和直接coding的区别。后者会偷偷帮你选一个，然后等你三个月后发现账单爆炸或者迁移成本锁死。

我回复Claude："团队规模假设25人，但计划6个月内扩到100人。Clerk的定价在这个区间会跳档，重新评估。"

第二轮返回的文档里，Auth Strategy变成了自研JWT+Redis会话，附带成本测算：Clerk在100人规模月费约$250，自研方案云成本$40但需要0.5个工程师维护。数字摆出来，决策变得具体。

迭代直到架构收紧：我的三个检查点

第一轮规划文档通常有漏洞。不是AI笨，是它不知道你系统的隐性约束。我的做法是设三个强制检查点：

检查点一：数据流是否闭环。 异步视频工具的核心是"录制→上传→转码→分发→播放"，AI给的初版方案里，转码环节用了FFmpeg自托管。我追问："如果同时10人上传4K视频，FFmpeg队列会堵死吗？"Claude补充了任务队列设计，改用Redis Streams+ BullMQ，峰值处理能力从并发3个提升到50个。

检查点二：失败场景是否覆盖。 初版文档提到"上传失败时重试3次"，但没定义什么算失败。网络中断？存储桶满？签名过期？我要求细化，返回的表格里多了错误码分类和降级策略：可重试错误进指数退避队列，不可重试错误触发用户通知并保留本地缓存。

检查点三：扩展假设是否显式。 AI喜欢写"支持未来扩展"这种正确的废话。我逼它量化：当前设计在PostgreSQL单实例下支撑多少并发？分片的触发条件是什么？答案写出来才发现，按预期的视频元数据增长速度，18个月后必须做读写分离，而方案里没提前留连接池配置。

三轮迭代后，文档从8页膨胀到14页，但每一页都是决策记录。不是我和AI的对话记录，是将来接手项目的工程师能直接读的上下文。

GitHub spec-kit的/specify命令自动化了部分检查，但判断什么值得检查、什么标准必须满足，仍然是人做。AI是实习生，能跑腿，不能背锅。

从规划到任务：为什么我还在用人工拆解

文档定稿后，下一步是拆任务。Claude能直接生成/task列表，但我只把它当草稿。

AI拆任务的方式是按模块切：数据库层→API层→前端组件→部署配置。听起来合理，实际开发时会撞墙——前端组件需要API先就绪，API需要数据库schema先冻结，但数据库schema在写API过程中几乎必然调整。

我重新排了依赖图：Week 1只交付可本地运行的录制+上传流程，用mock转码；Week 2接入真实转码队列，但播放端仍走直链；Week 3才做完整的权限系统和团队空间。每个里程碑都有可演示的产出，而不是"数据库层完成"这种黑箱状态。

这个排序AI给不出来，因为它不知道我团队里只有一个全职前端，也不知道投资人两周后要看demo。规划模式的终点不是完美文档，是可执行的、带上下文的行动清单。

我把最终的任务列表同步到Linear，每个任务附带规划文档的对应章节链接。三个月后回滚代码的人，能追溯到当初为什么选R2而不是S3。

整个流程走完，plan mode里停留的时间大约是直接coding的3倍。但过去六个月我用这套方法搭了4个原型，零个需要推倒重来。之前用"一个提示词出代码"的方式，平均每两个项目就有一个在第三周陷入架构债务泥潭，重构成本远超前期规划时间。

AI没有消灭工程，它只是把工程藏得更深。跳过规划的人，迟早要在调试器里补回来。

你的团队现在怎么分工？是让AI当主笔，还是只让它当校对？