(本文有AI的辅助，我提出想法，让AI来阅读所有的需求文档之后，整理成文，自己修改其中的语言，并配图)

今天我用带 AI 的 IDE 工具来更新一个软件——学位论文审查系统。现在已经迭代到 v3.0，连 PDF 也能审查了。从原型到可交付产品，这一段踩了不少坑，也攒下四个最实用的经验，分享给同样在用 AI 做项目的朋友。

不要“提问题让 AI 改”，要先“写清楚再编码”

把“聊天提问”拆成两步：先文档，后编码。

一开始，我遇到问题或者想要增加一个新功能，直接把错误或想法发给AI，让其帮我修订。结果往往是：

今天我会先花十几分钟（有时是和 AI 一起）把问题说清楚：

比如这次重构参考文献审查的假阴性问题，我先和 AI 梳理出「问题定位 → 根因拆解 → 解决思路」，写成一页纸，再让 AI 按文档去改代码，一次就能做到八九不离十。

聊天内容要及时归档：把一次解决变成长期资产

聊天结束，立刻把对话整理成一份 Markdown 归档。

你现在看我的 idea/answer/ 目录，几乎每一个问题都有一份归档。例如：

我常用的“归档模板”基本固定，目的就是：下次再遇到同类问题，一搜就能复用。

为什么要这么做？

AI 一次可能改好几个文件、几十上百行。只靠“看它说了什么”是不够的，必须看它“到底改了什么”。

有了 Git + IDE 的差异视图，你就能做到：

下面是我今天的工作流

这其实不是什么新东西，但在 AI 时代，源代码管理变成了你和 AI 之间的「安全网」。AI 放开手脚改，你放心大胆看，不对就撤。

这话听起来像广告，但真不是。

我这段时间最真实的感受是：付费模型的稳定性、上下文能力、输出一致性，明显比免费好。

算算账：付费模型换来的是更少的中断、更少的返工、更可预期的产出。对非专业程序员来说，时间往往比订阅费更贵。

遇到问题或要做新功能，我基本按这个流程走：

AI 是生产力工具，但工具要用对方法才能发挥威力。这四个经验都是我踩坑踩出来的，希望对你有用。