我们组一个跑了三年的老项目，最近想接 AI 编程助手提效。一开始直接让新人把所有代码丢给工具生成，结果产出一堆跑不起来的代码，review 的人比写的人还累。后来我们改了接法，才真正省下时间。
老项目接 AI 助手，难点不在工具，在「它不了解你的项目规矩」。你不让它先懂规矩，它就按通用套路乱来。
Cursor 这种编辑器式工具，我建议先写一份项目说明文件。把目录结构、用的框架、不能碰的模块、命名习惯写清楚，让它每次改之前先读。相当于给新人入职手册，AI 照着做规矩就少了。
它的好处是改动可视化，每处 diff 你都看得到，适合老项目这种「改错一步全盘皆输」的场景。
TRAE 我们用来做小模块的从零生成。比如补一个独立的小工具函数、写个一次性脚本，这部分边界清楚，让它放开手干效率高。大块的改动我们不让它碰。
国内版免费这点对团队试水很友好，先小范围用起来，大家有体感了再决定铺多开。
CodeBuddy 是插件式的，能接进现有 IDE，也能走云端。我们把它当「随时问一句」的助手：某个报错看不懂、某段老代码不知道干嘛的，丢给它问。它不改变你的工作流，嵌在原有开发环境里。
它对老项目最大的价值是「解释」而非「生成」。很多年前的代码没人记得为什么这么写，让它读一遍讲人话，省了大量考古时间。
我们立了条铁规：AI 生成的代码，提交前必须人工 review，关键逻辑要能讲出为什么这么写。这条保住了老项目的稳定性，没出过回滚事故。
范围要卡小。一开始我们只让助手碰新加的独立模块，核心交易链路一律人工。等它产出稳定了，再慢慢扩大边界。一口吃成胖子，老项目扛不住。
文档要补。AI 不了解的历史包袱，往往就是坑。我们顺手把那些「为什么这样」写成注释和说明文件，既喂给助手，也喂给新同事。
我观察到的转折点，是当大家开始主动把「说不清的报错」先丢给助手问一句、再决定要不要让它改，效率才真正起来。把它当随时在线的搭档，而不是全自动代写，老项目最稳。
新人培训也变简单了。以前带人读老代码要一周，现在让他跟着助手的解释走，三天就能动手改边角。知识转移的成本降了一大截。
我们踩过的反面教材，是把 AI 当全自动代写。新人图快，整模块丢进去生成，出来的代码能跑但看不懂，后面维护的人骂骂咧咧。后来我们规定，AI 只辅助，最终代码负责人必须自己能讲明白。我们定的红线是，AI 碰过的代码，人工 review 工时不能少于自己写的一半，这不是浪费，是买保险。
代码评审环节不能省。AI 生成的 PR 我们照样走 review，而且更仔细，因为它容易在不起眼的地方留隐患。这个成本必须花，省下来的返工时间更多。
老项目的测试覆盖往往不全，AI 改完你没测试兜底，心里没底。我们先补关键路径的测试，再让助手进场，它改完能立刻跑测试验证，安全感强很多。工具选型上，我们不让全员换编辑器，愿意用 Cursor 的用 Cursor，习惯插件的用 CodeBuddy，各取所需。强行统一反而降低接受度，提效的前提是大家真用得顺。
试点阶段我建议挑一个边界清楚、风险可控的小模块先跑两周。看产出稳不稳定、大家适不适应，再决定往核心挪。步子迈太大，老项目真的会出问题。文档这件事越早补越值，等大家都不记得当初为什么这么写，再让 AI 读了讲人话，你才知道多少坑被时间埋了。我们后来把「AI 解释老代码」列进了新人流程，效果比发一份过时的架构文档强，省下的考古时间够干不少正事。
更多工具见 AI 编程 IDE。
你们那个老项目现在最卡的是哪块？是写新功能慢，还是改老代码怕动坏？说一下，我帮你定个从哪块先接、怎么设人工闸最稳。