导读
AI 写完的代码出了毛病，人的第一反应是去修。我现在会多一步，先让它自己判断一次，这个值得修，还是重做更快。
这两件事的成本差得远。修一个别人写的、你自己也没完全看懂的东西，时间没有上限。重做一遍，大概能估出来。判断错了，就是白花一天。
下面这段整块发给它，它这次不动手，只给结论。
把这段话整段发给你的 AI
复制下面整块，原样发给它：
左右滑动查看完整代码
我这里有一段 AI 写的代码出了问题，你先不要动手改。请你先做一次判断，修还是重做，并把理由写清楚。
情况：（粘贴报错信息、出问题的功能、以及它现在的表现）
请查这四件事，每一件都写清你看到了什么。
一、坏的范围。出问题的这部分是独立的，还是和别处缠在一起。动它会不会牵出别的。
二、看不看得懂。这段代码有没有测试、有没有注释，能不能看出当初为什么这么写。看不懂的部分占多少。
三、修的成本。如果要修，要改哪几个地方，改完怎么证明没有弄坏别的地方。
四、重做的成本。如果要重写这一段，需要我提供什么，大概涉及哪些东西。
然后用四行给我结论。
1. 建议。修、重做、或者先补测试再决定。
2. 依据。上面四项各一句。
3. 风险。按你的建议做，最可能出问题的是哪一步。
4. 我必须自己做的一步。哪一步不能由你代劳。
看不出来的写“看不出来”，不要猜。这次不要改任何代码。它把四行结论交回来，你再决定让它动手还是自己接手。
需要你亲手做的三件事
- 决定要不要接受重做。重做意味着这段时间里，那个功能是坏的。这个取舍只有你能做。
- 先把还能跑的那一版存下来。它会提醒你备份，但哪一版还能用、放在哪，得你自己确认。它说坏了的东西，有时候只是你不满意。
- 改完自己走一遍真实路径。它跑通的是它自己写的测试。你平时怎么用它，只有你知道。
附：为什么先判断再动手
有测试的代码，修通常比重做便宜。没测试的代码，改哪里都是在赌，因为你不知道碰到的是哪根线。
判断的账很简单。理解这段代码要花的时间，如果超过重写一遍的时间，那修就是亏的。AI 写的这一段，账往往比重写更划算。它没有多年的历史包袱，没有为了兼容三年前的接口留下来的一堆分支，重做一遍的成本比人写的代码低得多。
真正会卡死的，是另一类东西。代码活了五年，当年写它的人走了，文档早丢了，谁接手都像考古。这种系统里的问题，卡住的地方不在技术，在没人肯接手。那是管理问题，跟谁写的没关系。
所以遇到这种事，我会让它先判断一次，再决定今天的时间是拿来修，还是拿来重写。