让 AI 开始构建功能之前，我现在会先做什么？

前言

差不多用 Vibe Coding 一年了，我感觉自己用 AI 开发应用和功能的方式，慢慢有了一些变化。

刚开始的时候，拿到需求就想让它赶紧写，先看看能做出什么。现在反倒会在动工之前停一停，多花点时间琢磨需求本身。

我想把这些变化记录下来，顺便复盘一下：哪些做法确实有用，哪些有点折腾，后面还有什么可以调整。

这一年，我是怎么用 AI 开发的

一年前，我主要用 Cursor 做前端开发。2025 年那会儿，按照我的使用体验，它还没有现在这么智能，大概就是“指哪打哪”。每次修改的范围不算大，改完以后基本都要自己 review，再告诉它下一步做什么。

到了 2026 年初，开始接触 Codex 和 Claude Code，明显感觉这些工具能干的事情多了。结合 Superpowers，已经可以把一个中小型模块的需求交给它，尝试从分析一直做到实现和测试。那段时间我也挺喜欢 TDD。先写测试，再补实现，有一套流程跟着走，心里会踏实一点。

但用了一段时间以后，又觉得 Superpowers 越来越重。有些事情本来很简单，也要跟着走一整套流程，多少有点被流程绑住的感觉。后来索性就不怎么用了，直接把需求说明白，让 AI 去做。

这里也和模型的迭代有关。以前很多事情需要一步一步教，现在它自己就能处理，遇到不确定的地方，也更容易主动提出来讨论。

所以，我现在没有固定采用哪一种方式。小需求说清楚就直接做；自己还没想明白的，先开计划模式聊一聊；特别大的任务，就用目标模式，把边界条件和验收标准交代好，让它持续往下跑。

当然，出于不放心，从零开始做一个复杂项目时，我还是会先准备一套 AGENTS.md 和相关的规范文档。

基础框架怎么选，组件怎么封装，主题、颜色、字体怎么统一，数据和路由怎么组织，这些最好在一开始就有个约定。项目的基础代码也要尽量搭好，后面 AI 写业务时，至少有现成的东西可以参考和复用。

测试要求也会提前放进去，比如把单元测试覆盖率目标设到 90%。不过，这个数字只能作为一个参考。关键业务规则有没有测到，异常情况下的行为对不对，还是要看具体的测试内容。覆盖率很高，业务理解错了，一样会出问题。

这些约定我目前还是觉得有必要，只是会尽量控制它们的数量。文档太多，每次做个小需求都要翻一堆，也容易回到之前觉得流程太重的状态。

现在开始一个需求之前，我会先做什么

目前比较花时间的，主要还是需求梳理、价值判断、异常场景和验收标准。有时候这些事情讨论下来，花的时间比 AI 写出第一版代码还长。

先看看，这个功能到底值不值得做

以前拿到需求，我很容易直接开始想怎么实现：需要几个页面、怎么接接口、哪些组件可以复用。

现在会多问几句：这个功能是谁在用？他现在遇到了什么问题？不做这个功能，有没有其他办法解决？做出来以后，用户能得到什么好处？

这些问题有时候还真没那么好回答。需求写在文档里，看着挺完整，往下追问几层，才发现有些地方只是一个大概的想法。所以，我现在会花更多时间看类似产品。看看别人怎么做，流程为什么这么安排，有哪些限制，以及它是怎么向用户介绍这个功能的。

“怎么介绍”这件事，我觉得也挺有帮助。如果一个功能做完以后，连它能给用户带来什么变化都说不明白，那可能还值得再想一想。

这部分工作，现在可以让 Agent 帮忙做很多。搜索资料、阅读文档、比较几种产品的做法，再整理出一份材料，比自己从头找起要省事不少。不过，资料来源和关键结论还是需要核对，别人的方案也不能直接照搬。

最后，我希望能留下一份不一定很长、但能把事情说清楚的需求说明：为什么做，这次做到哪里，暂时不考虑哪些情况。

如果涉及数据流和接口，也会顺手梳理出来。数据从哪里来，谁能修改，会影响哪些页面，需要和哪些系统交互。已经确定的就写下来，没确定的先标出来继续讨论。

这些地方不交代，AI 也能继续写，只是它会自己补上一些假设。等代码写完再发现双方想的不是一回事，改起来往往就比较麻烦了。

把业务里的异常情况提前拿出来聊

AI 做正向流程已经很快了。条件明确，步骤也清楚的时候，通常很快就能跑起来。

但一些实际业务里的异常，我感觉它处理得还是差一点意思。尤其是跟人的操作、业务习惯有关的情况，需求里没提，它未必会想到。比如做一个审批功能，提交、审批、通过，这条主流程很容易说明白。但用户提交之后想撤回怎么办？审批人已经开始处理了，还能不能改？审批到一半，负责人换了，又该交给谁？

这些问题不一定会让程序报错，但如果没有处理好，用户用起来就会卡住。

而且，这类问题往往没有通用答案。AI 可以给出一个看起来合理的处理方式，至于适不适合当前业务，还是得结合实际情况判断。

所以，在让它写代码之前，我会尽量先把这些场景列出来，再让 AI 帮忙补充和评估。哪些遗漏了，哪些规则相互冲突，哪些地方还需要找人确认，都可以在这个阶段讨论。

也不用一开始就把所有情况穷尽。我现在更愿意先抓那些经常发生、影响比较大，或者出了问题不好补救的场景。把这些约定下来，后面会省掉不少来回修改。

把“怎样才算做完”说具体一点

验收标准这件事，我现在也越来越重视。

目标比较模糊的时候，AI 往往也能交出一个结果，但那个结果距离自己想要的，可能还差好几轮修改。每次看完才补一句“这里还应该怎样”，需求就这样一点点往外长。

有些迭代确实需要看到东西以后才知道，但也有一些，其实可以提前说。

比如“支持导入数据”，听起来已经是一个明确的需求了。真要验收，还得继续往下问：有重复数据怎么办？缺少必填项怎么办？一部分成功、一部分失败，用户在哪里看结果，失败的数据能不能重新处理？

如果这些都没约定，最后就很容易出现“功能是做了，但还不能直接用”的情况。

所以我会尽量把验收标准写成能检查的结果，让自己和 AI 对“完成”有一个共同的理解。写的过程中，如果某一条始终说不清楚，也说明这个地方还没想好，可以先讨论，没必要急着进入实现。

条件允许的话，还可以让 AI 操作浏览器或者 App，跑一遍端到端测试。除了正常流程，也看看出错以后怎么提示，用户能不能继续操作，之前填的数据还在不在。

有了这些标准，后面 review 时也更容易聚焦，不用完全凭感觉判断做得怎么样。

结语

写到这里，感觉自己这一年的变化，确实有点有意思。

工具越用越熟，模型也越来越强，我却开始在写代码之前花更多时间。有时候 AI 已经随时可以动手了，我还在琢磨这个需求到底该怎么做。

这些准备肯定会增加前期投入，但我觉得其中有一部分时间，原本也省不掉。前面没讨论的问题，到了验收、上线，甚至用户真正开始使用以后，还是会找回来。那时候再改，通常更折腾。

当然，我也不想把这些做法再弄成一套很重的流程。毕竟前面刚经历过觉得流程太重、后来索性不用的阶段，再绕回去就没什么意思了。

准备到什么程度合适，我还在摸索。小需求聊几句就开工，复杂的业务多推演一会儿。现在我最想做好的，是在交给 AI 之前，先把那些自己也含糊的地方找出来，别等它写完一大堆代码，才发现最开始就没想明白。