AI 帮你改老代码:看懂别人写的,修掉跑不通的
改不动代码,八成不是不会写,是没读懂它在干什么。
适用:接手了别人的项目、或者回来改自己半年前写的东西。核心原则:先让它解释,再让它动手。跳过「读懂」直接让 AI 改,等于闭着眼睛动刀。
操作流程
1
先让它把这段代码讲一遍
约 10 分钟复述是理解的验金石。它讲完你能听懂,说明真读懂了;讲得含糊,说明这段代码本身就是隐患。
- 一次只贴一个函数或一个文件,别整包甩过去。
- 让它按「输入、做了什么、输出、依赖了什么」四件事讲。
- 听到看不懂的名词就追问,直到你能用自己的话复述一遍。
可直接套用的提示词
请阅读下面这段代码,**先不要提任何修改建议**,只做解释: 按这四点讲清楚: 1. 输入是什么(参数、来源) 2. 它做了什么(按执行顺序说,别只讲结论) 3. 输出是什么(返回值、副作用,比如改了哪些全局状态) 4. 依赖了什么(调用了哪些外部函数、接口、全局变量) 如果有让人看不懂的地方,单独列出来告诉我「这里写得含糊」。 最后用一句话总结:这段代码的职责是什么。 代码: ______
卡住了怎么办看不懂它的解释——把那段代码自己用中文重写一遍注释,哪里写不出来,就直接问「第 X 行这里为什么要这么写」。
2
描述现象,让它给出可能原因
约 10 分钟报错信息比你的猜测值钱。把完整的报错和触发步骤给它,比说「这个功能不work」有效十倍。
- 说清三件事:我做了什么、期望什么、实际发生了什么(附完整报错)。
- 让它列出 3 个最可能的原因,按可能性排序。
- 每验证一个就回来告诉它结果,逐步排除。
可直接套用的提示词
我有一个问题需要定位: 我做了什么:______ 我期望的结果:______ 实际发生的:______ 完整报错信息: ______ 相关代码: ______ 请列出 3 个最可能的原因,按可能性从高到低排序。每个原因告诉我: 1. 为什么会这样 2. 我该怎么验证是不是这个原因(给一条具体的验证方法) 3. 如果是,怎么改 先不要一次给完整方案,我要先验证。
卡住了怎么办给的原因都不对——把「已经试过什么、结果如何」补充给它。排除法比重新提问更快收敛。
3
小步改,一次只动一处
约 10 分钟+一次改五处,出问题时你查不出是哪一处。改动越小,回滚成本越低。
- 让它只改目标函数,不要顺手「优化」别的地方。
- 每改一处就跑一次,确认没坏再改下一处。
- 改完让它说清「这次动了什么、为什么、有什么副作用」。
可直接套用的提示词
请只修改下面这个函数,达成这个目标:______ 约束: 1. 不要改动其他函数,不要顺手重构。 2. 保持原来的函数签名和返回值结构不变。 3. 用注释标出你改了哪几行,每处一句话说明为什么。 改完后单独告诉我:这个改动有没有可能影响别的地方?如果有,是哪里? 代码: ______
卡住了怎么办改了还是不行——让它给一个「最小可验证版本」:把这段逻辑抽成一个能单独跑的小例子,先在小例子里调通,再放回去。
常见坑
- 把整个项目一股脑贴给 AI,它也只能泛泛而谈。
- 跳过理解直接让它改,改完更看不懂了。
- 只说「不 work」,不贴报错,来回猜十轮。
- 一次让它改十个地方,出问题无法定位。
- 让它「顺便优化一下」,结果引入了新 bug。
- 改完不测,直接提交。
常见问题
不懂代码能用吗?
能用来「看懂」和「提问」,但改动最好交给懂的人。你能做的是:让它讲清楚这段在干什么,然后拿着这个理解去和开发沟通——这已经能省掉大量来回。
贴公司代码安全吗?
有风险。核心业务代码、含密码和密钥的配置,不要贴到公网工具里。可以把变量名和业务逻辑替换成等效的假例子再问。
AI 改的代码能直接用吗?
当成「一个水平不错的同事给的建议」:它常常能指出方向,但边界情况和历史包袱它不知道。改完必须自己跑一遍、测一遍。
