AI 辅助开发提效：正确姿势是让它当助手，而不是主角

最近有个趋势很明显：越来越多人开始用 AI 写代码，然后用”AI 写了整个项目”来炫耀生产力。但我的感受恰恰相反——AI 做主导，是最低效的用法。

这篇文章聊聊我实际用下来的一套工作方式：让 AI 做助手，Git 做守卫，人来做判断。

真正高效的 AI 辅助开发，不是让 AI 接管项目，而是把它放在清晰边界内做执行。

---

AI 不适合做主导，原因很简单

AI 很聪明，但它没有上下文判断力。

你让它写一个完整功能，它可以给你一堆代码，但它不知道：

• 这个功能背后的业务逻辑是否真的成立
• 某段看起来合理的代码是否会和你已有模块冲突
• 一个”优化”是否会悄悄改变原来的行为边界

更危险的是，AI 生成的代码，语法上完全正确，逻辑上可能千疮百孔。如果你把它当主角、全盘接收，最后要填的坑，比自己写还多。

AI 适合做助手，不适合做架构师，更不适合做决策者。

---

AI 真正擅长的：重复性工作

换个思路，把 AI 定位成一个”极其高效的代码民工”，它的价值就出来了。

工具类函数

这是 AI 最拿手的场景之一。

日期格式化、字符串处理、数组去重、文件路径解析……这类代码有标准答案、没有业务歧义、可以直接测试验证。以前这类工具函数可能要翻文档、找案例，花十几分钟。现在描述清楚需求，AI 30 秒出代码，你 Review 一遍、跑一下测试，搞定。

// 告诉 AI：写一个把秒级时间戳转成 "YYYY-MM-DD HH:mm" 格式的函数，需要支持时区参数

这类需求交给 AI，效率提升是肉眼可见的。

接口调用的样板代码

每次对接一个新的第三方接口，都要写一堆重复的模板：请求封装、参数构造、错误处理、响应解析。

这些代码结构高度相似，逻辑几乎没有创造性可言。AI 非常适合生成这类脚手架代码，你只需要核对字段对不对、错误分支有没有漏就行。

单元测试用例

测试代码是另一个 AI 的”主场”。

给 AI 一个函数，让它生成边界测试、异常用例、正常流程用例——它不会觉得枯燥，也不会”偷懒只写 happy path”（只要你在提示里强调边界）。

这部分对很多开发者来说是最容易被拖延的工作，AI 来做，省时省心。

功能优化与重构

“帮我把这段代码的时间复杂度从 O(n²) 降到 O(n)”、”把这个 if-else 嵌套改成策略模式”——这类优化任务，方向是你决定的，细节让 AI 做。

你要做的是判断优化前后的行为是否一致，而不是自己手写每一行。

AI 最适合处理边界清楚、可验证的小任务；任务越小，Review 成本越低。

---

Git 是这套工作方式的底座

AI 辅助开发有一个隐患：你很容易在短时间内产生大量代码改动，然后发现某处出问题了，却不知道是哪个 AI 给的代码惹的祸。

解决这个问题的方式，是把 Git 的粒度做细。

我的原则是：一个函数、一个功能、一个 commit。

git commit -m "feat: add formatTimestamp util function"
git commit -m "feat: add POST /api/order request wrapper"
git commit -m "test: add edge cases for formatTimestamp"
git commit -m "refactor: simplify order status check logic"

这样做有几个好处：

随时可以回退到任何一步。 AI 给了你一个”优化”，跑起来发现有问题，一条 git revert 或 git reset 就能精准回到上一个干净的状态，不用大范围 undo。

Review 成本低。 每个 commit 只做一件事，改动量小，你能快速判断这段代码对不对。如果是大块 AI 生成代码一次性提交，Review 就变成了大海捞针。

问题定位精准。 出 bug 了，git log 一眼看出来是哪个 commit 引入的，git diff 对比一下就知道改了什么。

和 AI 的协作节奏对齐。 让 AI 生成一个工具函数 → Review → 测试通过 → commit，再让它生成下一个。这是一个健康的节奏，每一步你都是清醒的，而不是一堆代码塞进来然后发现乱了。

Git 的价值不是“最后备份一下”，而是让每一次 AI 生成都变成可审查、可回退的工程步骤。

---

一个实际的工作流

整理成一个流程大概是这样：

1. 确定你要做什么（你来决策）
        ↓
2. 拆解成小任务（你来拆分）
        ↓
3. 把其中重复性的部分交给 AI（AI 生成）
        ↓
4. Review 代码，确认逻辑和业务对齐（你来判断）
        ↓
5. 跑测试，验证行为正确（AI 可以辅助生成用例）
        ↓
6. commit（一个功能一个 commit，写清楚 message）
        ↓
7. 重复以上

这个流程里，AI 是步骤 3 的执行者，你是步骤 1、2、4 的主导者。权责分明，出了问题知道找谁。

---

几个容易踩的坑

不要让 AI 一次性生成太多代码。 生成量越大，你 Review 的成本越高，遗漏问题的概率越大。宁可多来几次，每次只要一个小块。

AI 给的命名和风格不一定符合你的项目规范。 记得在提示里说清楚，或者 Review 时统一调整。

不要把业务判断交给 AI。 “这个状态值应该是 1 还是 2”、”这个接口是否需要鉴权”——这些决策属于你，不属于 AI。

commit message 要有意义。 不要 fix bug，不要 update，要能从 message 里看出这个 commit 做了什么事，方便以后 review 和回溯。

---

总结

AI 辅助开发的正确姿势，不是把项目交给 AI，而是把可以标准化、可以复用、可以验证的那部分工作外包给它，然后用 Git 把每一步的结果固定下来。

• AI 负责执行重复性工作：工具函数、接口样板、测试用例、代码优化
• 你负责做判断：需求拆解、逻辑 Review、边界确认、架构决策
• Git 负责记录：细粒度 commit，随时可回退，清晰可追溯

这样用下来，AI 是真的提效，而不是制造麻烦。

---

如果你也在用 AI 做开发，欢迎在评论区聊聊你的用法和踩坑经验。