最近越来越依赖 AI 编程助手写业务代码生成一个接口模块或者一份数据处理的逻辑快的时候几十秒就出来了实测跑起来也能用。但每次到了交付这一步也就是把改动整理成一次干净、可评审的提交时心里那股烦躁感就上来了。代码本身不是难点难的是“最后一步”那些琐碎又绕不开的收尾动作格式化、静态检查、补测试、写提交说明、处理冲突、推上远程分支。这些事听起来都不难可真要做完、做好经常比写代码还耗人。这篇就想聊聊怎么对付这最后一步适用每天用 AI 写代码、但提交前总手忙脚乱的开发者也适合想把自己工作流理顺的人。1. 复盘“最后一步”到底烦在哪1.1 不是写代码难是收尾太杂我以前总觉得代码生成出来能跑剩下的不过是走个过场。直到有次在某个内部项目里我用 AI 很快写完了一个列表查询接口满心欢喜提交后在代码评审环节被同事连续问了三轮为什么这里有个多余的日志为什么命名风格跟上下文不一致为什么没有针对空数据的测试用例那一瞬间我意识到AI 给我省下的时间并没有真正转化为省心只是把“写代码”的困难转移到了“收拾代码”的麻烦上。所谓收尾不只是跑一遍格式化而是一长串动作的叠加。首先是格式和风格不同编辑器、不同格式化配置可能把同一段代码改得乱七八糟。其次是静态检查各种 lint 规则会指出未使用变量、缺失的边界判断、被忽略的错误返回值。再然后是想清楚这次改动到底解决了什么写出让人看得懂的提交信息。最后还要在多人协作时面对合并冲突。单个步骤都不难但它们串在一起后心智负担特别重。就像点了一桌菜吃到一半发现还要自己刷碗而且碗碟还特别多。1.2 提交信息的心理负担比想象中大不要小看写一句提交信息这件事。AI 生成的代码AI 也会顺手帮我们生成提交说明但生成出来的东西经常有两个极端要么太笼统一句“更新代码”毫无信息量要么太浮夸列出七八条“优化了性能”“增强了稳定性”但对应的代码改动其实只是挪了一行变量声明。写提交信息之所以烦是因为它不是单纯记录“我做了什么”而是在跟未来的自己、跟团队的同事沟通。一个模块的改动可能涉及三个人之后还会回头维护。如果提交信息写得含糊过两周自己看 diff 都可能满脸问号。可又不可能每个改动都花半小时去雕琢措辞所以这种“说重不重、说轻不轻”的活最容易消耗耐心。我后来宁可让 AI 先根据 diff 生成一版提交信息我再逐条核对删改也不愿意从空白开始硬写但前提是得有一套检查标准避免被 AI 那一版带着跑。1.3 合并冲突像是拆盲盒AI 写代码方便了个人产出但这种产出往往是在自己本地分支上“自由发挥”的很少考虑别人正在改动的区域。等任务完成拉取最新主分支再合并时冲突就冒出来了。如果是简单的小冲突还好最怕的是 AI 改写的代码和另一个同事的重构互相嵌套比如变量名被重命名过或者逻辑顺序调整过。这种场景下AI 偏偏帮不上太多忙因为它只看得到代码片段看不到两个人各自的心智模型。我曾经让 AI 帮我处理一个冲突块结果它把两边的修改误以为是“可以合并的重复代码”最后生成了一段看似合理、实际丢了一个分支条件的代码。还好在本地跑测试时发现了否则上线就是事故。冲突处理这件事最终还是要自己理解上下文我给它的定位只能是“辅助解释”绝不是“自动解决”。2. 把最后一步变成一张可复制的清单2.1 先定义一个明确的“完成”标准很多最后一步的烦恼源于我们压根没想清楚“做完”是什么意思。写代码的完成不是本地能运行就叫完成而是一套可以对外交付的状态。我给自己定了四个完成标准缺一不可格式整洁、静态检查零新增问题、相关测试全部通过、提交信息说清楚了这次改了什么和为什么改。这个标准听起来很基础但真执行的人不多。大多数情况是“功能跑通了就先提交”然后等到代码评审或者 CI 挂掉再返工。与其来回折腾不如把这些验证动作前置。每完成一个小任务就在本地把四项过一遍没有通过就不算结束。这种定义带来的好处是你不需要在临提交前才手忙脚乱地四处补漏因为每个小步都已经自带出口检查。2.2 一套适合自己的提交前检查清单我现在把收尾流程固定成一张清单不做多余的事但每件事都是必选项。列出来给大家参考格式化跑一次格式化命令让代码风格统一。静态检查运行 lint看有没有新增告警。相关测试跑受影响的测试用例而不是全量测试节省时间。检查 diff用仓库的对比功能逐段过一遍自己即将提交的改动。提交信息列出核心改动点一般不超过三行。本地构建或关键路径验证根据项目类型选择比如编译一次或跑一个冒烟测试。这套清单的重点不是工具而是顺序。先格式化、再静态检查是因为格式化往往能顺带调整某些风格问题让后面的检查少一些噪音干扰先看 diff 再写提交信息是因为很多人在提交信息里写错了内容正是根本没认真看过 diff。这份清单的妙处在于它减少了我临时做决策的次数。以前我每次提交前都要纠结“要不要补个测试”“这个日志要不要删”现在到了这一步就按单执行不用再动脑子权衡。2.3 清单降低的是决策负担不是工作负担有人可能会说这不就是把以前随手做的事列出来而已吗不止如此。列清单的核心逻辑是从“我这次想做什么就做什么”变成“我每次都按同一流程走”。人在做重复性决策时会快速疲劳不疲劳的方法是减少决策本身。收尾动作一旦标准化到了提交这一步脑子里不会再同时考虑五件事只需要从上到下跑完清单。而且清单也是给 AI 赋能的基础。你可以把这份流程告诉 AI让它帮你生成检查脚本、提示遗漏甚至让它按你的标准写提交信息。但前提是你自己心里先有标准。没有标准的人用 AI只是把混乱换了一种形式继续混乱下去。3. 实操我现在的收尾工作流3.1 让 AI 先生成提交信息草稿但必须设约束我在提交前常做的一件事是把当前改动的 diff 摘要贴给 AI然后明确告诉它只许列实际改动点不许使用“了一些”“优化了性能”这种模糊表达如果某项改动没有对应代码变更就不要写进说明里。这样生成出来的提交信息草稿通常比我自己写的还整齐因为它会自动按照“改动区域、改动原因、影响范围”来组织。当然我也被坑过。有次一个只改了两个文件的小功能AI 生成了五条提交信息其中三条是原代码里根本没有的新方案描述纯属脑补。从那以后我固定了一个流程AI 生成草稿后我对照 diff 逐条打勾能对应上真实变更的才保留。这个过程单独看可能要花一两分钟但能避免提交信息虚假描述带来的评审麻烦非常值得。3.2 贴 diff 让 AI 自审但不是全权托付除了提交信息我也会让 AI 帮忙做个代码自审。具体做法是把准备提交的 diff 文本拿给它问它有没有发现潜在问题比如空指针风险、遗漏的边界条件、不合理的命名、多余的死代码。这一步对 AI 来说很好用因为它看得了全局比人眼更容易找出上下文不一致的地方。有一次它还真指出了我在一个循环里误用了外部变量那个 bug 单靠测试用例不一定拦得住。但要守住一个原则AI 提出的每条建议必须能明确对应到真实代码。它说“这里可能有问题”我就要去代码里找到那个位置自己判断到底影不影响功能。不符合这条原则的建议无论听起来多合理都不采纳。因为生成式模型偶尔会编造不存在的风险如果不加筛选反而会引入新的噪音。3.3 合并冲突处理先理解再动手合并冲突是我的老对手。现在我的流程很简单本地更新主分支合并自己的分支让冲突暴露出来。看到冲突标记后先把两边代码都完整读一遍理解各自想干什么。理解清楚之后我才会去改冲突块。有些冲突是纯位置重叠两边代码其实干的事完全不同那只需要调整位置即可有些冲突是逻辑冲突两边都对同一段流程做了不同处理那么就需要跟另一个开发者商量或者看需求文档。我不再让 AI 直接帮我写冲突后的代码但会把冲突片段丢给它让它分别解释两边做法的意图。这相当于有两个人同时给我讲解背景我再自己做决定。实测下来这套方法极少出问题而且处理速度也不慢。3.4 小步提交是最有用的防冲突策略我踩过的最大教训是改动越大收尾越难。以前我喜欢一个分支里塞好几个功能一起提交感觉这样效率高。但结果是提交信息写不清楚、代码评审时不知道从哪看起、合并时冲突还特别多。后来改成小步提交一个改动点对应一个提交整个体验立刻不同了。小步提交不等于频繁提交而是每次提交都有清晰的边界。比如“给查询接口增加分页参数”是一个提交“修复删除接口的权限校验遗漏”是另一个提交两者绝不混在一起。这样每个提交的 diff 都短自我检查速度快AI 生成的提交信息也准因为改动范围明确它没有什么空间发挥。4. 常见坑与排查实录4.1 AI 生成的提交信息为什么总是夸张现象提交信息明明没有对应代码却写了一个很唬人的功能点。原因在于 AI 是基于语义相似度联想生成内容的当 diff 里有“sort”这个关键词它就可能联想出“优化了排序算法”哪怕你只是改了一个方法名。排查方法很简单让 AI 给每条提交信息标注对应的文件路径或函数名然后逐条对照。没有对应代码的条目直接删掉。这也是我为什么强调要先看 diff 再提交人一旦偷懒把提交信息全托付给 AI迟早会出现这种失真情况。4.2 本地格式化完合并后 diff 爆炸这是团队协作里最容易遇到的坑。你本地格式化得很干净结果一合并整个文件都标红了因为别人的代码风格跟你的不一样。问题往往出在格式化范围的约定上有人用了行尾自动格式化有人单文件手动格式化互相叠加后diff 从功能改动变成风格改动评审体验极差。建议做法是在项目根目录统一配置格式化规则并在收尾流程中固定执行同一份配置。提交前先检查有没有格式化范围之外的改动如果出现说明你可能把某个小改动和格式化混在同一个提交里了最好拆开处理。我在实际项目里就吃过这个亏之后定了一个规矩格式化动作不跟功能改动混在一起单独一个提交必要时随时可以回退。4.3 本地测试全过远程 CI 仍失败这种情况常常让人怀疑是不是测试写错了。我排查过几次后发现大概率原因有三个一来本地环境依赖版本和远程不一致二来本地跑测试时没有清理缓存三来测试用例覆盖到的代码路径恰好被某些环境变量影响。与其盯着代码发呆不如先看日志CI 失败的原因几乎都会打在日志里。如果日志不明确就先把远程环境依赖锁文件更新到本地重新安装一遍依赖再跑测试。这个过程虽然浪费时间但能避免一个更大的坑你不知道本地是通过“侥幸”通过还是真的通过。做过一次环境对齐之后CI 失败的次数会明显减少每次失败也都更容易定位。4.4 交给 AI 处理冲突差点丢掉一个分支条件有一回冲突块两边分别改了同一个条件判断AI 给我的处理结果看起来完全正常语法也对逻辑却不对劲。因为我原本判断的是“权限为管理员或创建者时允许删除”另一个同事改成了“权限为管理员时允许删除创建者在特定状态下除外”。AI 合并时把两边条件简单取并集导致任何管理员都能无条件删除等于削弱了另外一个同事想收紧的权限。排查方式极其简单处理完冲突后不要只看冲突块本身要把整个函数的上下文再读一遍。如果你对这段逻辑不是百分百确定就去看看对应的测试用例是否存在、是否覆盖了这个分叉。缺失的测试用例在这种场景下特别致命因为它不会报错只会悄悄改变行为。现在我处理完每个冲突后都会顺手检查相关测试有没有跟上如果发现冲突改变了某个业务规则立刻补一个对应的用例。问题表现常见原因处理建议提交信息写得夸张AI 基于语义联想脱离实际 diff让 AI 标注每条信息对应文件逐条核对合并后 diff 爆炸格式化范围不一致统一配置提交前检查非功能改动本地测试过、远程失败环境依赖不一致对齐依赖版本清理缓存先看日志AI 合并冲突丢失逻辑把两边条件简单合并只看冲突块不够要读函数上下文并补测试5. 习惯层面把收尾变轻松的两个心态5.1 收尾不是额外负担而是交付质量的组成部分很多人天然把“写代码”看成正经事把“整理代码”看成杂活。换个角度想想用户和协作者看到的并不是你脑中的灵光一闪而是最终落到分支上的那一坨 diff。diff 本身就是交付物收尾就是在整理交付物。它跟写代码本身一样重要甚至更重要因为未来维护的人靠的就是这份 diff 和提交信息理解你的意图。一旦接受了这个设定收尾就不再是“浪费时间的麻烦事”而是应该主动投入精力的核心环节。心态转变之后我会更愿意花时间写清楚提交信息、主动补测试而不是每次到提交前才敷衍了事。这种质量信号在团队里很直接别人在 review 代码时能轻松理解你的改动他对你的信任度也会提高。5.2 养成固定的“收尾仪式”减少临时抱佛脚操作层面的方法再完备如果只是偶尔想起来用一次效果也有限。我建议每个人都建立一个属于自己的收尾仪式。可以是每天下班前固定半小时也可以是每完成一个小任务就立刻做清理动作关键是频率要和自己的工作节奏匹配。有人喜欢把多个任务攒在一起集中收尾有人喜欢写完一段立刻整理没有绝对的对错。但我的实际体验是结束后立即收尾比集中收尾更顺畅。因为大脑对于刚写完的代码还有清晰的上下文此时检查 diff、写提交信息、补测试都很顺手如果隔几个小时再回来光回忆上下文就要耗不少精力。现在我会刻意把“写完”和“提交”放在同一段时间里中间不去插入其他任务。这半个小时看似不起眼但它让我每天提交的质量整齐得多了。我在实际操作中的体会是AI 写代码拉高了速度上限人们最容易忽略的反而是那些不能自动化的“最后一公里”。收尾这件事之所以让人烦往往不是因为它难而是因为它琐碎、重复、没有即时反馈。但只要把它拆成标准清单固定成习惯再让 AI 帮自己完成其中可以生成的部分整个过程就不会再暴躁。最后给大家一个实用建议从明天开始尝试每次提交前都先看一遍完整 diff再写提交信息坚持一周你应该能明显感受到代码评审时被追问的次数少了很多。