面向 AI 辅助编程的安全优先工作流
TL;DR：在让 AI 助手改代码之前，先把你的代码提交（ commit ）掉。

常见错误 ❌
很多开发者都会这么干：
在本地还有未提交改动的情况下，直接让 AI 助手去“重构这个函数”或者“加点错误处理”。

结果呢？
AI 一出手，git diff 里全乱了——你自己刚写的代码和 AI 生成的修改全部混在一起。

一旦哪里炸了，你根本分不清：

哪些是你手写的

哪些是 AI 动的

更别说安全回滚了

这到底会带来哪些问题 😔
你之前的代码改动和 AI 生成的代码被混在一起

很快就搞不清自己到底改了什么

AI 给了个“幻觉级”建议，结果你还不好撤回

正确姿势：该怎么做 🛠️
先把手头的手动任务做完

跑一遍测试，确保全绿

提交你的代码

git commit -m “feat: manual implementation of X”
👉 不用 push，也没关系

再把你的需求发给 AI 助手

用 IDE 的 diff 工具仔细审查 AI 的改动

接受 or 回滚

改得不错？留着

不对劲？直接：

git reset --hard HEAD
再次运行测试，确认 AI 没把东西搞坏

单独提交 AI 的改动

git commit -m “refactor: AI-assisted improvement of X”
这样做的好处 🎯
Diff 非常清晰
AI 的“建议”是完全独立的一组改动

回滚极其轻松
AI 一旦胡说八道，一条命令立刻撤回

上下文可控
你确保 AI 操作的是一份“稳定、最新”的代码

测试永远是绿的
不会在不知不觉中破坏已有功能

背后的逻辑 🧠
当你让 AI 改代码时，它可能会：

删掉一个关键的逻辑判断

在多个文件里重命名变量

引入你完全没预料到的副作用

如果你本地还有未提交的改动，这些变化就会变得极难追踪。

而先 commit，等于给自己加了一张安全网：

用 git diff 可以精确看到 AI 改了什么

一旦出问题，一条命令就能回到干净状态

你会被迫用极小步迭代的方式工作（这本身就是好事）

而且，说实话——
不少 AI 助手在“撤销自己干过的事”这件事上，并不擅长。

Prompt / 命令速查 📝
git status # 查看是否有未提交改动
git add . # 暂存所有改动
git commit -m “msg” # 提交
git diff # 查看 AI 的改动
git reset --hard HEAD# 回滚 AI 的改动
git log --oneline # 查看提交历史
注意事项 ⚠️
只有在 write mode（AI 可以直接改代码）的情况下才有必要

你也可以在 AI 的规则里强制它：
在改代码前先检查仓库状态

局限性 ⚠️
如果你的项目根本没用版本控制
那这些步骤就只能靠你手动模拟了（强烈建议上 Git）

标签 🏷️
Complexity Level： 🔋 Beginner

相关技巧 🔗
使用 ** TCR **

练习 ** Vibe Test Driven Development **

把大型重构拆成多个小 Prompt

用 git bisect 定位 AI 引入的 bug

快速回滚 AI 幻觉级改动（ Reverting Hallucinations ）

总结 🏁
把 AI 当作一个 结对编程的队友，就应该遵守和人类协作一样的安全规范：

版本控制

Code Review

测试

在发 Prompt 之前先 commit，你就等于给开发过程加上了一连串清晰的检查点。

这一个小习惯，就能把 AI 从一个“不可控的黑盒”，变成一个你可以大胆试错、随时撤回的强力工具。

早点 commit，多 commit，别让 AI 碰你还没提交的代码。