夜雨聆风原创于【IT黄大大】｜一起探索 AI 之路，也一起把工程基本功练扎实。
最近 AI 编程太火了。
从写代码、改 bug，到生成测试用例、做代码审查，很多事情都可以交给大模型完成。身边也经常有人说：“我已经很久没有真正从零写代码了。”
这当然是一个好趋势。
AI 确实提高了效率，也让很多重复性编码工作变得没那么痛苦。但在真实的研发现场里，我越来越强烈地感受到一件事：
AI 可以帮你写代码，但它替代不了 Git；AI 可以帮你提效，但它替代不了研发流程。
尤其是对一些中小团队来说，真正容易出问题的地方，往往不是“AI 写错了一段代码”，也不是“某个开发能力不行”，而是这些更基础的问题：
更常见的风险，其实藏在流程里：
代码被覆盖了，但没人知道是谁覆盖的； 分支乱建、乱合，master 上什么都有； 测试环境、演示环境、现场环境混在一起； 发版时配置缺失、字段没同步、脚本不一致； 出问题后无法快速回退，也无法准确溯源。
这些问题，AI 很难替你解决。因为它们不是代码生成问题，而是协作、规范和责任边界的问题。
01｜真正的痛点，不是 AI 写代码，而是代码没人管
AI 编程时代，代码生成变快了，但这也带来一个新问题：
代码变多了，提交变快了，风险也被放大了。
过去一个功能可能需要开发半天，现在 AI 可能几分钟就能生成一版。可问题是，生成得快不代表合得对、测得够、发得稳。
如果团队没有清晰的 Git 分支规范，没有环境隔离，没有发版流程，那么 AI 生成的代码越多，混乱反而越明显。
02｜真实案例：客户演示前，功能被覆盖了
前段时间，我们有一个已经写好的功能，准备拿去给客户演示。
结果在提交过程中，被其他角色的工程师覆盖了。更麻烦的是，被覆盖的不只是某个业务页面，而是一个公共函数。
这个公共函数一出问题，直接导致页面里很多下拉框阻塞刷新。偏偏这个问题又发生在客户演示前后。
结果就是：
原本准备演示的功能无法正常展示； 页面交互出现异常； 演示过程被迫中断； 团队临时排查问题，非常被动。
这件事表面上看，是一次代码覆盖事故。但本质上，它暴露的是三个问题：
提交前没有充分 review； 公共函数缺少影响范围评估； 演示环境没有稳定保护机制。
03｜现场版本一发布，各种问题都来了
另一个更典型的问题，是现场版本发布。
有时候一个包发布到现场环境后，各种“妖魔鬼怪”的问题就冒出来了：
配置文件缺失； 数据库表字段没有同步； 初始化脚本和现场脚本不一致； 本地能跑，测试能跑，现场就是不对； 修一个问题，又引出另一个问题。
这种情况最可怕的地方在于：它不是一个单点 bug，而是一整套环境和版本管理的问题。
原创于【IT黄大大】。把踩过的坑写下来，和你一起探索 AI 时代的工程实践。
04｜先把环境边界划清楚
后来我们先从环境管理开始梳理。
一个基本原则是：不同环境只能承载不同阶段的代码。
开发环境
开发环境可以灵活调整，主要用于日常开发和联调。但如果要调试公共能力，最好提前通知大家更新代码，避免别人本地功能没带上。
演示环境
演示环境要相对稳定。一般情况下，不应该随意更新。除非确实有临时开发的亮点功能需要给客户演示，才可以发布新包。
但发布之后必须做充分测试，并且要有回退机制。
现场环境
现场环境必须最严格。现场版本不能随便动，必须满足两个条件：功能已经充分测试，并且现场确实需要这个功能。
05｜Git 分支必须重新规划
环境梳理完之后，另一个核心问题就是 Git 分支。
我们之前的状态比较混乱：基本上就是一个 master 主干，大家各自又搞了一些分支，日常开发提交也容易往 master 上走。
master 到底是稳定版本，还是开发版本？
当时我请教了一些有经验的前辈，整理出两种方案。
方案 A：master 作为稳定版本，develop 作为开发分支
master 保持稳定；新增 develop 分支作为日常开发分支；测试确认没问题后，再合并到 master；每次发布前在 master 上打 tag。
方案 B：master 继续向前跑，单独切 stable 分支
master 继续作为开发主线；单独切一个类似 2026-04-stable 的稳定分支；bug 修复或测试稳定的功能，再同步到 stable 分支。
最终，我们选择了方案 A。因为它更清晰，也更容易让团队形成长期规范。
06｜最终规范：master 稳定，develop 开发，发布必须打 tag
master 只能由管理员合并
一般开发人员不能直接往 master 提交代码。日常开发都提交到 develop 分支，等功能测试通过后，再由管理员或负责人合并到 master。
每次发布前必须打 tag
每次发版前，都要在 master 上打 tag。tag 里要带上版本号、发布时间、本次发布内容、重要修复说明，以及是否可回退。
创建 develop 分支
git checkout master
git pull origin master
git checkout -b develop
git push -u origin develop给稳定版本打 tag
git tag -a v1.2.0 -m "修复支付模块严重 BUG，版本稳定可发布" a1b2c3d
git push origin v1.2.007｜AI 可以写代码，但流程必须由人来兜底
这套规范执行之后，效果其实很明显：
演示环境出错变少了； 代码提交更有边界； 现场包同步更及时； 出问题后更容易定位； 回退也不再完全靠猜。
这也是我为什么说：AI 永远替代不了 Git。
准确地说，AI 替代不了的不是 Git 这个工具，而是 Git 背后的协作秩序。
AI 可以帮你生成代码，但它不知道你的现场环境能不能动；
AI 可以帮你改 bug，但它不知道这个版本能不能发；
AI 可以帮你写提交说明，但它不能替团队承担发布事故。
真正能兜住项目质量的，还是这些看起来很“基础”的东西：分支管理、环境隔离、代码 review、测试验证、版本 tag、发布回退、团队共识。
AI 越强，工程规范越重要。
因为当代码生产速度越来越快时，真正决定项目能不能稳定交付的，不再只是“谁写得快”，而是“谁能把代码管得住”。
结尾
如果你的团队也在大量使用 AI 编程，我建议先别急着只关注模型有多强、提示词有多好。
可以先回头看三个问题：
你们的 master 到底是不是稳定版本？ 你们的演示环境和现场环境有没有明确边界？ 每次发版后，能不能通过 tag 快速追溯和回退？
这些问题不解决，AI 写得越快，团队可能乱得越快。
工具会变，但工程纪律不会过时。
