接手一个不熟悉的老项目，最怕乱改把跑得好好的功能弄崩。我现在一律先让代码助手把项目读一遍，再让它干活，而不是直接下指令。
IDE 里常驻我用 GitHub Copilot。它在我写新代码时给补全，我主要拿它做小步快改，每次改动小，错了好回退。大动作我不敢交给他盲改。
国产 IDE 插件里我用 通义灵码 和 文心快码。它们对本地的注释风格和中文变量名理解更顺，我在老 Java 项目里让它补文档和单测，沟通成本比英文工具低。
读整个仓库给解答我用 CodeBuddy。它能跨文件看上下文，我问这个模块谁在调、那段逻辑干嘛用的，它答得比单文件工具全，适合我刚接手时快速摸底。
要补样例和注释我用 CodeGeeX。老项目缺文档，我让它给关键函数写注释和调用示例，先理解再动刀，比硬读强。
我的流程是这样。先让助手扫一遍项目结构，我挑三个最关键的模块问清楚职责，再让它做具体的小改。每次只改一处，跑测试过了再下一处。
我踩过的坑是让它一次改太多。有回我让它重构一个模块，它顺手把接口也变了，下游全挂。从那以后我只接受单点改动，大重构我自己分步指挥。读代码我让助手先画调用关系。问它这个接口被谁调、改了会影响哪些模块，它把链路列出来，我脑子里先有张图，再动手才不慌。
写新功能我让它先给方案再写。直接让它写代码，常常写出和老项目风格冲突的东西。我让它先说打算怎么改、动哪几个文件，我点头了它再落笔。
测试我要求它一起补。老项目最怕改一处坏一片，我让它每改一个函数就顺手加或修对应的测试，跑绿了再提交。没测试的改动我绝不并。
注释和文档我让它补在改动处。老项目缺说明，新接手的人（包括未来的我）看改动附近的注释就能懂，不用从头读全代码。
提交我控制粒度。一个逻辑改动一个提交，不混一堆。出问题时回退干净，不会连累无辜的改动。这也是我踩过坑学来的。
我还会给助手一份项目约定：命名风格、目录结构、不该碰的文件。它照着来，生成的代码才像项目自产的，而不是外来户。读不懂的代码我先让它写注释版。原文件不动，它另出一份带讲解的，我对照着读，理解完就删，不污染仓库。
提交前我让它自检。问它这段改动有没有破坏既有功能，它往往指出我没想到的影响面，比我自己盲测全。
我还不让它碰配置文件和迁移脚本。这类错一点就全局崩，我手工处理，AI 只管业务逻辑那部分。
新人接手我也用这招。把项目丢给助手生成一份 onboarding 文档，新来的照着读，比我口头讲标准。
我坚持小步提交。一个逻辑改动一个 commit，不混一堆，出问题回退干净，不连累无辜改动。
我还会让它解释复杂函数。遇到绕的逻辑，让它用大白话讲一遍，确认我俩理解一致，再决定改不改。
边界情况我专门问。让助手列这个模块可能在哪些输入下出错，我照着补测试，比等线上爆了再查强。
我不迷信它的补全。它给的代码我先读再贴，不盲抄，老项目里一行错可能连锁反应，谨慎没坏处。我要求它给改动写说明。每次提交附带一句它改了啥，我 review 快，也方便后人懂。
我不让它重构没让我重构的模块。它爱顺手优化，我明确划禁区，碰了就回退。
结对时我念出我的思路。边说边让它补，它出的东西更贴我意图，不像猜。
老项目我每周让它扫一次坏味道。重复代码、过长函数列出来，我挑着改，不一次性大动。我禁用它的自动提交。改完我先看 diff，确认没动无关文件才提交，安全绳不能松。
它给的多文件改动我拆开审。一份改动只含一个意图，review 快，回退也干净。
老项目我设只读区。核心模块标只读，它只能读不能改，防手痒乱动。你手头是什么语言的老项目？告诉我栈，我把对应的助手配置和提问模板发你。