先说一个几乎人人都踩过的坑
很多人第一次用 Agent 做项目，第一句话是这样的：
帮我写一个xxx网页
然后 Agent 就开干了：先 npm create vite，装上 React、TypeScript、Tailwind，再装一个状态管理库，十几个文件一口气生成出来。你一看还挺像回事。
等你想说「我其实只想要一个打开就能用的单文件网页，数据存在浏览器里就行」时，已经晚了。要么把整个项目推倒重来，要么将就着用一套远超需求的技术栈。
问题不在 Agent 写得不好，而在你没告诉它边界，它只能按自己的「默认最佳实践」来。这一节要做的，就是在写第一行代码之前，先让 Agent 把方案写成文档，你看过、改过、点头了，再动工。
一、为什么要先计划后编码
说到底是一笔成本账：
| 阶段 | 发现方向错了，改起来要花多少 |
|---|---|
| 计划阶段 | 改一句话 |
| 写了一半 | 改几个文件，还要回头检查有没有别的地方受影响 |
| 写完了 | 推倒重来 |
Agent 生成代码的速度很快，但「快」有两面：写对的快，写错的也快。你在一个错误方向上多聊十轮，就会堆出十轮的错误代码。
计划文档的作用，是把最贵的决策（用什么技术、改哪些文件、先做什么后做什么）提前拿出来，放在最便宜的地方讨论。
还有一个不那么明显的好处：计划文档是给后面每一轮对话看的锚点。功能要分好几次做完时，你会反复让 Agent「按技术方案里的 M3 来做」。没有这份文档，每一轮你都得重新解释一遍需求。
二、技术选型怎么问：给约束，不给答案
技术选型最常见的两种问法都不太好：
- 什么都不说：「帮我选个方案」→ Agent 大概率推荐它最常见的那套主流做法，未必适合你。
- 直接指定答案：「用 xx 库做」→ 你可能根本不需要它，只是因为听说过。
更好的问法是把约束告诉它，让它在约束内比较几个方案。