写给开发者的慢思考：先把问题说清楚，再让AI帮忙写代码

最近和同事聊起一个共同感受：有了 AI 帮忙写代码，写出第一版代码变快了，但把代码真正做对、做稳，反而更考验人的判断。工具可以补全语法，却补不全我们对问题的理解。今天这篇文章，想聊聊一个朴素的工作方法：先把问题说清楚，再让 AI 帮忙写代码。

一、先写一句话问题

动手之前，先用一句话说清要解决什么。例如：用户在什么场景下遇到什么困难，希望得到什么结果。这句话越具体，后面的方向就越不容易跑偏。如果一句话说不清楚，往往说明需求本身还没有想明白，这时更适合先讨论、先拆分，而不是立刻生成代码。

二、把输入、输出和边界写下来

接下来可以列出三组信息。第一是输入：数据从哪里来，格式是什么，有哪些必填项。第二是输出：页面、接口或者文件应该呈现什么，成功和失败分别是什么样子。第三是边界：哪些情况不需要处理，哪些异常必须给出明确提示。把这些写下来，既是给自己的检查清单，也是给 AI 的清晰指令。

三、用小步骤代替一次到位

一个比较稳妥的做法，是把任务拆成小步骤：先实现最核心的一条链路，跑通后再补边界情况，最后再做优化。每一步完成后都看一下运行结果，确认符合预期再往下走。这样即使某一步出现偏差，也容易定位，不至于在大量代码里来回查找。

四、把验收标准放在前面

在写代码之前，先想好怎么算完成。比如：正常输入应该返回什么；空数据、重复提交、网络异常时应该怎么处理；哪些行为需要记录日志方便排查。验收标准越明确，评审 AI 生成的代码时就越有依据，而不是只看代码能不能跑起来。

五、对生成结果保持复核习惯

AI 给出的方案常常看起来完整，但仍需要人工复核。重点可以放在几个方面：逻辑是否符合业务规则；边界条件是否被遗漏；错误处理是否会把问题藏起来；命名和结构是否便于后续维护。遇到不确定的地方，宁可多问一句、多做一次验证，也不要直接放行。

六、给未来留一点可读性

代码是写给人看的，也是写给未来的自己看的。清晰的函数划分、恰当的注释、一致的命名，会让后续修改成本低很多。尤其是在多人协作时，可读性本身就是一种质量。AI 可以帮忙生成初稿，但结构和表达的取舍，仍然需要开发者来决定。

结语

AI 让写代码的起点变低了，但把事情想清楚的价值并没有降低。先说清问题、列清边界、拆成小步、定好验收，再借助工具提效，是一种更踏实的工作节奏。希望这篇短文，能给正在尝试 AI 辅助开发的你一点参考。