面向 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 碰你还没提交的代码。
