我今天和 AI 协作学到的一件事

今天做项目时，我又遇到一个很典型的 AI 协作问题。

AI 很快，快到有时候我会误以为「它开始写了」就等于「它理解了」。但实际不是。它可能理解了 80%，剩下 20% 的偏差，会在后面变成返工。

我今天真正学到的，不是某个提示词，而是一个更朴素的工作流：先对齐，再开工。

问题不是 AI 慢，而是我太急

以前我经常这样用 AI：

我描述一个需求，让它分析，然后直接让它改代码。

这个方式在小任务上没什么问题。但一旦进入真实项目，比如一个餐饮 SaaS 里的业务逻辑、后台流程、数据处理，很多东西不是代码表面能看出来的。

有些逻辑看起来绕，是因为之前踩过坑；有些字段看起来多余，是因为真实门店流程里会用到；有些地方不能随便重构，是因为它牵着后面的运营链路。

这些上下文，AI 不会天然知道。

如果我自己没有先讲清楚，它就会用「看起来合理」的方式往前推进。结果就是：代码可能没错，但不一定解决我的问题。

我今天换了一个顺序

今天我开始刻意把第一步改掉。

不再先问：你能不能帮我实现？

而是先问：你先复述一下，你理解我要解决的问题是什么。

这个动作很小，但效果很明显。

当 AI 复述问题时，我能马上看到它有没有抓住重点。比如它有没有把目标说偏，有没有把不该改的地方也算进范围，有没有忽略边界条件。

如果复述都不准，我就不会让它继续写。

接着，我会让它列出验收标准：

• 什么结果算完成？
• 哪些旧行为必须保留？
• 哪些文件或模块最好不要动？
• 改完以后用什么方式验证？

这些问题看起来慢，但比返工便宜太多。

最小下一步，比大方案更可靠

我以前也喜欢让 AI 一次给完整方案。

现在我更倾向于让它只做最小下一步。

不是因为 AI 做不了大任务，而是因为真实项目里，很多判断要边做边验证。尤其是一个人做产品时，我既是产品、开发，也是运维，不能只看代码是否优雅，还要看它会不会影响上线后的稳定性。

所以现在我会把节奏压小：

• 先改一个点。
• 跑一次。
• 看结果。
• 确认没有破坏原逻辑。
• 再进入下一步。

这个节奏没有那么炫，但很适合独立开发者。

AI 是很强的队友，但不是项目负责人

今天最大的体会是：AI 协作不是把脑子外包。

AI 可以帮我写代码、查问题、拆方案、总结风险，但项目边界要我来定，业务判断要我来做，最后的责任也还是我来扛。

所以我的新工作流是：

复述问题 → 对齐边界 → 写验收标准 → 最小改动 → 运行验证 → 再推进下一步。

这套流程解决的不是「AI 能不能写代码」的问题，而是「我怎么减少误解和返工」的问题。

对我这种全职做自己产品和自媒体的独立开发者来说，这比追求某个万能 prompt 更重要。

如果你也在用 AI 做真实项目，可以试试先别急着让它开工。先让它说清楚：它以为自己要做什么。

这一步，往往能省掉后面很多麻烦。

你和 AI 协作时，最常遇到的问题是理解偏差、代码质量，还是验证困难？欢迎留言，我也会继续把每天真实踩坑和工作流记录下来。