业州愚公撰写的《AI 工具实操与提示词》系列文章中提到，一位转职的朋友在使用 AI 工具帮助优化程序码时遇到问题。朋友将一支爬数据的脚本贴进 AI 对话框，要求「帮我优化一下」，结果 AI 交回的版本虽然看起来更漂亮，但却偷偷改掉了空数据的处理，导致程序码报错。为了避免此类问题，业州愚公提出使用三个提示词，将重构与除错拆成可验收的流程：先让 AI 只读不改，讲清它看到什么；再让它一轮只动一处并写出理由；最后让它先立假设，然后给出能执行的验证步骤。这样可以确保 AI 的修改是可控和可验证的，避免类似的错误发生。
菜鸟之友系列：《AI 工具实操与提示词》・模板篇作者：业州愚公
上周帮一位转职的朋友看他接的小案子。他要改一支爬数据的脚本，于是开新对话，把文件贴进去，写了五个字：「帮我优化一下」。AI 很快回了一份改好的版本，加了型别注解、把回圈改写成串列推导式、函式拆得更短，看起来漂亮很多。他贴回去跑，第一次就报错，改了半天才发现有一处边界条件被改掉了——原本遇到空数据会跳过，改完变成整支停掉。
问题不在 AI 会不会写程序。它会写，而且写得不差。问题在你交出去的是一道没有验收标准的题目。「优化」不是需求，是一个形容词；它不知道你要的是跑得快、看得懂、还是以后好改，也不知道哪些行为是你绝对不能动的。它只能按自己的偏好选，而它的偏好是「让 diff 看起来很专业」。
要让它改得你放心，得把这件事拆成三步：先让它只读不改，讲清楚它看到什么；再让它分开动刀，一次只做一件事，并且讲出理由；最后给它验证条件，让它自己回答「怎么证明没改坏」。三个模板就按这个顺序排。
AI 改程序的主要风险不是写错语法，语法错误还算好消息——马上就报错。真正贵的是静默的行为改变：函式签章动了、回传型别从阵列变成物件、空值处理换了写法、例外从抛出改成吞掉、默认参数值被「顺手」改了。这些改动不会报错，跑起来也像对的，等到上线某个少见的输入进来才炸。
第二个风险是范围失控。你贴了 200 行让它修一个 bug，它还你 400 行——顺便帮你把命名改了、把注解删了、把两个文件合并了、还把你不认识的相依套件引进来。你想 review，但改动面已经大过你能一眼看完的量，最后只能凭感觉按接受。
这两个风险有共同的来源：你把「诊断」和「治疗」放在同一句话里，它就只能一边猜病因一边开刀。所以模板一是把诊断单独切出来。
适用场景：任何一段你不太熟、或别人写的程序码。你要先确认它「看懂了没有」，再决定让不让它动手。这一轮它一行都不准改。
【只读不改・可直接复制】
下面是一段程序码。这一轮你只做阅读与说明，不要输出任何修改后的程序码，不要提出重写版本。
请按四段回答：
1. 它做什么：用不超过 5 句话说明这段程序的整体功能，以及它的输入与输出（含型别、可能的空值情况）。
2. 数据怎么流：列出主要的执行步骤（编号），标出每一步会改变哪个变数；如果有多个函式，标出呼叫关系。
3. 可疑点：列出你认为可能有问题的地方，每条写成「位置 → 症状 → 你为什么这么怀疑」，并标注你的信心程度（高／中／低）。不要下结论说一定是 bug。
4. 我不确定的地方：如果你对某段逻辑的意图（例如某个判断条件为什么这样写）无法从程序码本身确认，直接列出问题问我，不要猜。
以下是程序码：
```
【贴上你的程序码】
```
为什么这样写：第 1、2 段是逼它把理解外显出来。这一步的价值不在答案，在你能立刻看出它哪里理解错了——如果它把「跳过空数据」讲成「中断处理」，你当场就知道不能把后续工作交给它。第 3 段的格式要求是为了把「可能是 bug」和「确定是 bug」分开，并附上信心程度；模型很爱用确定的语气讲推测，你把信心栏位写进格式，它就必须自己标一次。第 4 段是最省事的一条：它看不懂设计意图时，问你比猜你便宜一百倍。
落地细节：贴程序码时连同文件路径与语言版本一起写（例如「Python 3.11，Django 4.2」），模型对版本差异很敏感；如果这段程序有已知的业务规则（例如「金额一律以分为单位」），在第 4 段下面补一行写明，否则它会按通用常识理解。
适用场景：你已经知道要改什么了（可能是模板一给的清单，也可能是你自己发现的 bug）。重点是控制范围，让每一轮改动小到你真的能 review。
【单一目标重构・可直接复制】
请对下面的程序码做且只做一项修改：【在这里写下唯一一个目标，例如：修正当 items 为空阵列时会抛出例外的问题】。
规则：
1. 先写计画，再写程序码。 计画用编号列出你要动哪几行、改成什么、为什么。计画写完停下来等我确认，不要直接给改好的文件。
2. 不准顺手改别的。命名、排版、注解、无关的写法，一律保持原样。如果你认为附近有一处也该改，写在末尾的「建议但未执行」清单里，不要动手。
3. 不准新增外部相依。只能用这段程序已经引入的函式库。
4. 保持对外行为不变，除了你这次要修的那一点。特别注意：函式名称与参数、回传值的型别与结构、例外处理方式、默认值——这些都不要动。
5. 输出格式：先给「改动摘要」（一行讲完）、再给计画、再给完整的可复制程序码（不要只给片段，不要用「此处省略」），最后给「建议但未执行」。
以下是我的程序码：
```
【贴上你的程序码】
```
为什么这样写：第 1 条的「先写计画再停下来」是整段的核心。模型默认会一次交到底，因为它假设你要的就是结果；让它交计画，等于把一个可控的小关卡插在破坏发生之前——计画读起来很便宜，读一段错的程序码的替代方案是把它跑起来、出错、再找原因。第 2 条处理范围失控：把「顺手」变成一个必须分开呈现的栏位，它就不会混在主改动里。第 5 条要「完整程序码」是因为片段最容易出事，你会漏看它偷偷改掉的另一处；「不要用此处省略」这句一定要留着，否则它很爱省。
第 4 条是重构这件事的定义本身：重构的目标是改变结构而不改变行为，所以「对外行为不变」不是可选项。把它列成具体清单（签章、型别、例外、默认值），是因为「行为」太抽象，列出四个具体项目它才好对照。
要替换的变数：那个唯一的目标；如果目标本身比较大（例如「把这个 300 行的函式拆成三个」），就拆成几轮做，一轮只拆一个，并且在每轮第 4 条补一句「外部呼叫这个函式的地方不要改」。语言的差异也可以写进规则，例如「不要用 JavaScript 的箭头函式」或「符合 Pylint 默认规则」。
落地细节：改完一轮，把新版本当成新的输入，回到模板一重跑一次只读检查。这听起来多花一轮，但它拦下的正是那种「改 A 弄坏 B」的静默问题，而那种问题在你自己跑测试之前不会现形。
适用场景：程序已经出错了，你手上有错误讯息，但看不出成因。这跟模板二不同：模板二是你指定要改什么，模板三是让它先定位再修，而且要用你给的证据定位。
【除错定位与修复・可直接复制】
我的程序出了问题。请按下面的流程处理，每一步做完先停下来，等我回覆再进行下一步。
证据如下：
- 预期行为：【我本来以为会发生什么】
- 实际行为：【实际发生了什么】
- 错误讯息（原文贴上，不要改写）：
```
【贴上完整错误讯息与堆叠】
```
- 重现步骤：【1. … 2. … 3. …】
- 环境：语言与版本【如 Python 3.11】、作业系统【如 Windows 11】、相关套件版本【如 pandas 2.2.0】
- 相关程序码：
```
【贴上出错的函式与它的呼叫处】
```
流程：
1. 复述与定位：用自己的话复述这个错误是什么类型（语法／型别／状态／环境／逻辑），并指出你认为最可能的 3 个位置，按可能性排序。这一步不要给修好的程序码。
2. 提出验证方法：针对可能性最高的那一个，给我一句可以立刻执行的指令或一行 print，让我跑完告诉你结果。不要叫我做大范围改动。
3. 收到我的结果后，再判断假设是否成立；不成立就回到第 2 步换下一个假设。
4. 确认成因后，再给修复方案：先写一行成因，再给最小改动的完整程序码，最后说明「为什么这个改动不会影响其他行为」。
如果我提供的信息不足，直接问我缺哪一项，不要猜测后继续。
为什么这样写：这个模板把除错常见的错误做法倒过来了。一般人的做法是把错误讯息贴上去，问「这怎么修」，然后拿到一段猜出来的修改——因为模型在手上一无所有的时候，最合理的策略就是给你一个涵盖多种可能性的补丁，于是你会得到一堆「顺便也加了防御性检查」的改动。这个模板逼它先讲假设，再要一个能验证假设的最小动作，你跑完回报，它才推进；这样每一轮都建立在事实之上，而不是在猜测之上叠猜测。第 2 步那句「不要叫我做大范围改动」是关键限制：除错最贵的成本是你按建议改了五个地方，最后发现真正的原因在第六个地方，而前五个改动现在都成了新的变数。第 4 步要求说明「为什么不会影响其他行为」，等于把模板二的纪律搬过来——修得对还不够，得说得出为什么没有副作用。
要替换的变数：「证据如下」那六项要照实填，缺一项它的准确率就明显下降，尤其是版本号——很多 bug 是特定版本的行为差异；重现步骤愈小愈好，如果只能描述而无法稳定重现，就写「出现频率约十分之三」而不是编一个步骤。
落地细节：把每次的假设与验证结果留在对话里不要删，这份纪录就是你下次遇到类似错误的线索。
| 你要做的事 | 用哪个模板 | 产出 | 什么时候用 |
|---|---|---|---|
| 不确定 AI 有没有看懂这段程序码 | 模板一：只读不改 | 功能说明＋可疑点清单（含信心程度） | 每次动刀之前，先跑这一轮 |
| 已经确定要改什么 | 模板二：单一目标重构 | 计画＋完整程序码＋「建议但未执行」清单 | 一轮只做一件事，改完重跑模板一 |
| 程序已经出错，原因不明 | 模板三：除错定位与修复 | 假设清单＋可执行验证步骤＋最小修复 | 有错误讯息时，先定位再修 |
一句话记住：先让它读懂，再让它小口改，最后让它先立假设再动手。 三件事混在一起做，你拿到的就是最开头那个故事——一份看起来很专业、跑起来会炸的 diff。
回到开头那位朋友。后来我们把那支脚本重跑了一次模板一，它列出的「可疑点」里有一条正是空阵列的处理，信心程度标的是「中」——也就是说，它其实看到了，只是没人问它。重构与除错交给 AI，真正省下的不是打字时间，是你自己去找线索的时间；而前提是那条线索必须先被讲出来、列成清单、被你确认过。流程写对了，它交回来的东西你才敢用。
工具推荐随身机器人（新用户免费试用 7 天）
除错往往发生在你最不方便开电脑的时候——看到错误讯息、想先问一句。SY 视野的「随身机器人」把手机里的 AI 助理带着走，随时问、随时用，新用户免费试用 7 天。入口见 SY 视野（sylogs.com）首页。
下一篇预告： 程序码靠规则关住，翻译却没有编译器帮你检查。下一篇换个场景——多语翻译保真：怎么用提示词把「意思对但味道跑掉」的译文逼回来，以及为什么要求它一次给两版，比要求它「翻得准一点」有用得多。
业州愚公 ｜ SY 视野（sylogs.com）原创内容，转载请注明出处。
编辑评论 / Editor's Note
随着人工智慧技术的发展，编程工作中也逐渐引入了AI的协助，但这也带来了一些挑战和隐忧，尤其是在程序码优化和除错的过程中。透过设置明确的提示词和流程，可以更好地控制AI的修改内容和过程，从而确保程序码的安全性和可靠性。这种方法不仅能提高编程效率，也能减少AI修改所带来的风险。