AI 编程和人工编程有一个很大的不同：
单位时间产出的代码量较大。
如果没有很好的工程手段控制，生成的大量代码可能很快就会超出我们的控制。
常用方式
各大 AI 编程工具在这方面也都下了力气，提供了多种控制工具。
Git 支持
这个作为开发者，大家应该很熟悉了。
只要使用了 Git，最起码可以保证本地和代码库的区分，这是最直观，也是最靠谱的控制手段。
如果要求再高一点，建议根据需要在代码库中创建分支，可以依据自身需要，也可以参考业界的一些最佳实践，比如：Gitee 上的分支模型。
对话的检查点 Checkpoint
各大 AI 编程工具都有类似概念，一般是在指令消息附近或者每次对话结束的地方。
但叫法可能不一样，下面是几个常用工具的叫法：
- Cursor 就叫做 Checkpoint，我第一次知道就是从 Cursor 来的。Windsurf 是叫做 snapshot（快照），并且支持手动创建快照。TRAE 中叫做回退版本，大家交流时一定注意和项目版本区分。
如果回滚检查点之后代码生成效果一直不好，可以新开一个新的会话来避免残留上下文的影响。
生成代码的差异对比（Diff & Review）
这块也都没有再起什么名词，并且用法也大差不差，都是在指令对话框上面显示改动的文件，点击后可以在编辑器中看到精确到行的差异对比。
逐行确认并接受正确的代码。
这里建议逐行接受，而不是整个文件接受，因为 AI “幻觉”的存在，有时候确实会产生一些莫名的代码。
我的最佳实践
结合以上几种方式，分享一下我在 AI 编码过程中的实践工作流。
准备阶段
项目建立之初，Git 就采用“开发/发布/缺陷分离模型”划分好分支，开发只在 develop 分支进行，审阅后再合并到 master 分支。
确定好开发的工作区是干净的，避免接受代码后，无法区分是否本次修改内容。
代码生成阶段
向 AI 发送精确的指令，避免同一个问题多次对话完善，影响上下文质量。
针对生成结果，逐行审查并接受需要的代码。
如果生成结果差距太远，可以拒绝代码，或者直接回滚到某次对话之前，以保证后续生成结果的质量。
提交
Git 提交大家都不陌生，我刚入行时，一个学长就传授过“频繁提交”的原则，而实际工作后，发现大家往往不太喜欢频繁提交。
但 AI 编程模式下，强烈建议保持好“频繁提交”的习惯，一个是 AI 生成代码的速度，导致一天我们基础的代码量远超之前，另一方面，代码量增大后，出现低质量或错误代码的几率也随之增高，有备无患。
合并
这个和非 AI 编程模式下是一样的，只要做好审查和合并工作即可。
结语
AI 编程提升效率基本已是公认的事实了，但编程方式的改变，必定会引起研发范式的升级。
希望大家在关注开发工具技巧的同时，也多关注下代码的质量和安全，避免好技术造成坏结果。
