VF的部落格

第80篇：用 AI 做 Code Review——替你盯低级错误

2026-10-07T10:00:00+08:00

代码跑通了就敢提交？跑得通，只是及格线。

上一篇给代码装了安全网——单元测试。测试好用，但有天然盲区：

测试只查”结果对不对”，管不了”这么写行不行”。

举几个例子：数据库密码直接写代码里——测试全绿，直到代码被人看到；用户输入搜索词原样拼进查询——测试全绿，直到有人输入带引号的东西拖走整个库；报错时完整堆栈返回前端——测试全绿，同时把目录结构、表名全告诉别人；循环里每转一圈查一次库——测试全绿，上线 100 条数据就查 100 次。

共同点：功能全对、测试全绿，但这些代码全都迟早出事。 这类问题传统靠 Code Review（代码审查）——提交前让更有经验的同事看一遍。可你要是没有那个同事呢？ 个人开发、小团队、外包、刚入行，绝大多数人根本没有”更有经验的同事”随时帮你看。

这一篇，教你怎么把 AI 变成那个同事。

一、为什么直接说”帮我 review”，得到全是废话

先做个实验。把代码丢给 AI 说”帮我 review 一下”，它八成给你：

“整体结构清晰，命名较规范。建议：1. 添加更多注释 2. 考虑增加错误处理 3. 变量命名更语义化 4. 考虑可扩展性……”

看着像回事，实际一条没用。 这些话对任何代码都成立，等于没说。你真正想知道的”我这段代码有没有要命的坑”，它一个字没提。

你没告诉它「按什么标准看」，它只能给你放之四海皆准的空话。

破法只有一个：给 AI 一张检查清单，逼它逐项过。 像医院体检——你说”帮我看看身体”，医生只能”注意休息多喝水”；你递上 20 项体检单，他就得一项项出数值。

二、Review 五关：正、安、错、洁、快

那清单该有什么？把新手最容易踩、后果最严重的问题归成五个关卡，口诀：正、安、错、洁、快。注意顺序就是优先级，越靠前越致命。

第一关：正（正确性）

功能是不是真的对？ 逻辑判断搞反（该”大于等于”写成”大于”）、边界漏了（正好等于阈值呢？）、算错（浮点直接比相等、金额用小数存）。这一关和上篇”四靶”一套东西，测试从外面验，review 从里面看。

第二关：安（安全）

最易被新手忽略，也是唯一”出事就没法挽回”的关卡。 三大高发死法点名：

① 密钥硬编码 数据库密码、API 密钥、token 直接写代码。代码被人看到（同事、外包、公开仓库、截图发群）密钥就泄。正确做法：放配置文件或环境变量，确保那文件不被一起提交。

② 用户输入直接拼进指令 把用户填的内容原样拼进查询语句、系统命令、文件路径。用户填的不一定是”数据”也可能是”指令”，这是绝大多数数据泄露源头。正确做法：用参数化传值，不是字符串拼接。

③ 敏感信息进日志或返回前端 把密码、身份证、手机号打进日志；把完整报错堆栈返前端。报错信息通常含文件路径、表名、框架版本——等于给别人画了张地图。 正确做法：详细报错记服务器日志，返前端的只有一句”操作失败，请稍后重试”。

第三关：错（异常处理）

顺利时都对，出问题呢？ 网络请求没设超时（对方不响应就永远卡）、取可能不存在字段没判空（直接崩）、除法没防除零、捕获异常却什么都不做（第 75 篇”假成功”，最阴险的 bug）。→ 一句话：凡”跟外面打交道”的地方（网络、库、文件、第三方），都必须假设它会失败。

第四关：洁（整洁）

就是第 77 篇「重构六味」：长、重、名、套、魔、杂。重要但不致命，排在安全和异常后面。

第五关：快（性能）

第 78 篇内容，只盯几个”一眼看出”的：循环里查库（N+1，头号元凶）、循环里发网络请求、一次读海量数据进内存、能批却不批。性能排最后，因为按”优化三问”，没测量前性能建议大多是猜的。

五关速查表：

关	看什么	严重度
正	逻辑对不对、边界漏没漏	⚠️ 高
安	密钥硬编码、输入拼指令、敏感外泄	🔴 最高·不可逆
错	网络/空值/超时兜底、异常被吞	⚠️ 高
洁	长重名套魔杂（六味）	🟡 中
快	循环查库/发请求、能批没批	🟢 中低

三、提示词怎么写：四个关键技巧

清单有了，还得会问。四招决定 AI 给干货还是废话。

技巧一：禁止它夸你。 AI 改不掉先夸三句再说问题的毛病，夸完语气变软，”必须改”变成”可以考虑优化一下”，你一看就先不改了。直接堵死：“不要评价优点，不要写总结性褒奖，只挑问题。”

技巧二：要求按严重程度分级。 AI 一口气给 15 条全平铺，你分不清哪条”今天不改明天出事”哪条”改不改都行”。要求分三档：

🔴 必须改（安全漏洞、逻辑错、必崩空值）
🟡 建议改（不立刻出事，但欠债）
🟢 可以不改（纯风格）然后只处理红和黄，绿的直接跳过，15 条变 4 条，人不慌。

技巧三：每条必须给”四件套”。 要求每条含：1. 在哪（第几行/哪个函数）2. 什么问题（一句话）3. 为什么是问题（会造成什么后果，最关键）4. 怎么改（给改后代码）。第 3 条是过滤器——逼 AI 说清后果，一大半凑数假问题当场露馅。

技巧四：允许它说”没问题”。 AI 有强烈”必须交作业”倾向，你让它挑毛病它就一定挑，哪怕代码很好也开始挑鸡毛蒜皮甚至编造。明确给退路：“某一关确实没问题就写’本关无问题’，不要凑数硬找。”给了退路它反倒诚实。

四、AI 说的不一定对：三级过滤

拿到结果别急着照单全改。AI 的 review 结论分三类：

第一类：真问题（改）。 密钥硬编码、没判空、逻辑写反，占比约一半，直接改。

第二类：AI 看错了（不用改）。 AI 只看到你贴的这一段，看不到项目其他部分。 它可能说”这用户身份没校验”——可你在上层统一入口早校验过了，它不知道。识别法：你确定别处已处理，就是它上下文不全，回一句它会撤回。

第三类：风格之争（可不改）。 “建议改另一种写法”“建议提取独立函数”，没对错纯偏好，赶时间就跳过。

一句话验伪：让它举个会出事的场景

怎么快速分辨？万能追问：“这个问题在什么具体情况下会真的出事？给我能复现的场景：什么用户、什么操作、什么输入、最后什么后果。”

真问题 → 立刻说出：”用户搜索框输入带单引号内容时，查询被截断，攻击者可借此读整张用户表。”
假问题/凑数 → 开始打太极：”这主要提升可维护性和扩展性……”

说不出具体场景的，基本都能放一放。

五、实战：一段”跑得通”的代码被挑出了什么

假设你写了”用户登录”逻辑，功能正常、测试过了。丢进五关一过：

🔴 必须改（3 条）

【安全·第 8 行】 数据库连接密码直接写代码 → 后果：代码被看到密码就泄，传公开仓库几分钟被扫到 → 改法：移环境变量，代码只读变量名。
【安全·第 22 行】 用户名原样拼进查询 → 后果：输特殊字符可绕密码登录甚至读整张表 → 改法：参数化查询，用户名当”值”传不是”语句”。
【异常·第 35 行】 登录失败把完整错误返前端 → 后果：暴露表名、字段名、框架版本，给攻击者递地图 → 改法：详情写日志，前端统一”用户名或密码错误”。

🟡 建议改（2 条） 4. 【异常·15 行】调短信接口没设超时→对方挂了会卡住 5. 【整洁·全函数】一个函数干 5 件事→建议拆。

🟢 可以不改（1 条） 6. 变量 res 建议改名 loginResult。

看到没——功能没毛病、测试全绿，但三个必须改里两个能直接致数据泄露。 这就是 review 的价值：测试盯”对不对”，review 盯”稳不稳、安不安全”。

六、提交前三分钟自查清单

最后一张随身表，每次提交前花三分钟过一遍：

□ 代码里有没有写死的密码 / 密钥 / token？
□ 用户输入有没有被原样拼进查询语句或命令？
□ 报错信息会不会原样返回给前端？
□ 网络请求设超时了吗？
□ 可能为空的地方判空了吗？
□ 有没有 catch 了异常却什么都不做的地方？
□ 循环里有没有查数据库 / 发网络请求？
□ 有没有临时调试打印、注释掉的死代码、写死测试账号？
□ 单元测试跑过了吗？（上篇）
□ 这次改动，我能一句话说清改了什么、为什么改吗？

最后一条是隐藏考题。 说不清自己改了什么，说明混进了不该混的东西——拆开分两次提交。

提示词模板盒子

模板 1：五关全量 Review（主力模板）

你现在的角色是一位严格的代码审查员，正在帮编程新手做提交前最后检查。

【要审查的代码】

（把完整代码贴在这里，不要贴片段）

【这段代码是干什么的】
（两三句大白话说明业务用途、谁用、什么时候被调用）

【技术背景】
（什么类型项目、跑在哪、有没有暴露给外部用户）

【审查要求】
请严格按以下五关逐项审查，每关单独给结论：
第一关·正（正确性）：逻辑有无写反、边界有无遗漏、计算有无隐患
第二关·安（安全）：①密码/密钥/token有无硬编码 ②用户输入有无原样拼进查询/命令/路径 ③敏感信息（密码、身份证、手机号、完整堆栈）有无写进日志或返前端
第三关·错（异常）：网络有无超时、空值有无判空、有无捕获异常后啥都不做、外部调用失败有无兜底
第四关·洁（整洁）：过长、重复、命名、嵌套、魔法数字、职责过多
第五关·快（性能）：循环查库、循环发请求、能批却逐条、一次读海量数据

【输出格式】
按严重程度分三档，每档内按行号排序：
🔴 必须改（安全漏洞、逻辑错、必崩）  🟡 建议改（欠债）  🟢 可以不改（纯风格）
每一条必须含四要素：1.位置 2.问题（一句话） 3.后果（什么情况真出事、造成什么损失，不许写"影响可维护性"） 4.改法（给代码）

【严格约束】
- 不评价优点、不写褒奖，只挑问题
- 某关确实没问题就写"本关无问题"，不要凑数硬找
- 大白话解释，新手术语顺带解释一句
- 不确定处明确说"我看不到上下文需你确认"，不要猜

模板 2：安全快查（最快见效，建议每次都跑 + 提交前三分钟）

【A. 只查安全，其他不管】

（贴完整代码）

请只查这七项，逐项给结论（有问题指行号，没问题写"未发现"）：
1. 有无硬编码密码、密钥、token、连接字符串
2. 用户输入有无原样拼进数据库查询
3. 用户输入有无原样拼进系统命令或文件路径
4. 有无把完整报错堆栈/内部路径/表名返前端
5. 有无把密码、身份证、手机号写进日志
6. 有无该做权限校验却没做（能操作别人数据）
7. 有无用不安全老旧加密或伪随机
对每个发现说明：攻击者怎么利用（给可复现输入例子）、最坏后果、正确写法。
七项全无问题就明确答"七项均未发现"，别硬找别的。

【B. 提交前三分钟快查】

（贴代码）

只回答下面 10 个是非题，格式「序号+是/否+若是指出行号」：
有无写死密码/密钥/token  2. 用户输入有无原样拼进查询或命令
报错会不会原样返前端  4. 网络请求漏设超时没
有可能为空却没判空吗  6. 有无捕获异常啥都不做
循环里查库或发请求没  8. 有无调试打印/死代码/写死测试账号
有无本次改动外不小心带进的无关修改  10. 有无一眼可见逻辑错（判断反/边界漏）
最后一句话总结：这段代码现在能不能提交？不能只列必须先修那几条。

模板 3：验伪与纠偏（判别 AI 结论真假 + 补上下文）

【A. 验伪追问——对每条可疑结论用】
你刚才提的这条问题：
【把 AI 那条结论原样贴过来】
请给我一个能真实复现的具体场景：
- 什么身份用户 / 做了什么操作 / 输入了什么 / 最终什么后果（具体到用户看到啥、数据变啥）
如果你说不出具体可复现场景，或只是"理论上可能"，请直接答："这条不是真实风险，可以忽略。"
不要用"提升可维护性""增强健壮性""符合最佳实践"来搪塞。

【B. 上下文不全时的纠正】
你提的第 X 条问题（【贴那条】），我补充上下文：
【补充说明】这部分其实在别处已处理：（说明在哪层、怎么处理，最好贴那段代码）
请重新判断：1. 补了上下文这条还成立吗 2. 不成立请明确说"这条撤回" 3. 仍成立说明为什么现有处理不够、什么情况被绕过。
同时重新检查你其他结论，有没有同样因看不到全部代码而误判的。

80 篇速查卡

记忆点	内容
为什么需要 review	测试盯”对不对”，review 盯”稳不稳、安不安全”
AI 给废话的原因	你没给标准 → 给清单，逼它逐项过
Review 五关	正（正确）安（安全）错（异常）洁（整洁）快（性能）
顺序即优先级	安全最致命不可逆，性能排最后
提示词四技巧	禁夸奖 / 分三档 / 每条四要素 / 允许说”没问题”
四要素	在哪 + 什么问题 + 会造成什么后果 + 怎么改
三级过滤	真问题（改）/ AI 看错了（补上下文）/ 风格之争（可跳过）
一句话验伪	“给我一个会真出事的具体场景” —— 说不出的都是凑数
新手三大死法	密钥硬编码 / 输入拼进指令 / 报错原样返前端

下篇预告

现在代码有两道防线：测试盯结果，review 盯风险。但还有个问题没解决——三个月后你自己看不懂自己写的代码。变量名取对了、逻辑没毛病，却想不起”当初为什么这么写”。代码能说清”做了什么”，说不清”为什么”。下一篇《第 81 篇：用 AI 生成注释与文档》讲注释该写什么、不该写什么（剧透：写”为什么”不写”是什么”）。下篇见。

第79篇：用 AI 写单元测试——覆盖率不再头疼

2026-10-06T10:00:00+08:00

改了一行，不知道会崩哪儿。这种恐惧，能治。

上上篇讲重构时，我留了样东西叫「行为快照表」——改代码前先把”这段功能现在的表现”手工记一遍：输入什么、出来什么。改完照表跑，对上就安全。

那张表好用，但致命缺点是它是手工的。三个功能点跑一遍五分钟，三十个功能点跑一小时，于是你就不跑了。不跑等于没安全网。

这一篇就一句话：把那张手工快照表，变成一行命令就能全跑完的代码。 这东西叫单元测试。

一、先说人话：单元测试到底是个啥

别被”测试”吓到，它跟”测试工程师”两码事。最土的比喻：

手工验证，是把整台机器开起来看它转不转。 单元测试，是把每个零件单独拿出来，通上电，看它响不响。

“单元”就是一个函数、一个方法、一小块独立逻辑。你写一小段代码专门调用它，检查”我给它 3 和 5，它是不是返回 8？”是就打勾，不是就报红。

一个最小的单元测试，本质只有三句话：

准备：输入是什么
执行：调用它
断言：结果应该等于什么

第三步”断言”是灵魂——你写死在代码里那句“它必须等于这个”。以后谁改代码，结果不等于这个，机器当场报警。这就是它比手工表强的地方：机器帮你看、帮你对，一秒能对完几百条。

二、该测什么？记住「四靶」：正、边、错、空

小白写测试最大问题不是不会写，是不知道该测哪些情况。写完一个就觉得”测过了”，结果线上还炸，因为你只测了最顺的那种。

归成四个靶子，口诀：正、边、错、空。

靶一：正（正常情况） 最典型最顺的那一种，用户按你想的那样用。算折扣原价 100 打 8 折 → 80；手机号 13812345678 → 通过。这一靶最容易想到，也最没价值，只能证明”能用”不能证明”可靠”。

靶二：边（边界值） 刚好卡在临界线上的数，线上事故八成出在这。 满 100 减 20，那正好 100 呢？库存”大于 0 才能买”，正好 0、负数呢？分页每页 10 条，正好 10/11/第一页/最后一页呢？→ 记一条：代码里出现「大于」「小于」「至少」「最多」，那个数字本身就是必测靶。

靶三：错（错误输入） 用户会乱输，接口会返垃圾，必然的。手机号栏输汉字、金额栏输负数、日期输”2026-13-45”。你要测的不是”它能不能处理”，而是”出错时是不是优雅报错，而不是整个崩掉”。

靶四：空（空值） 新手漏得最多，也是线上崩溃第一元凶。 空字符串 ""、空数组 []（列表一条数据没有，页面白屏？）、null/None（数据库那字段本来就是空）、用户没填/接口没返。很多”莫名其妙崩溃”追到底，就是某处是空的，代码默认它一定有值。

四靶速记表：

靶	测什么	一句话
正	最典型正常输入	证明”能用”
边	临界值：0、1、正好、最大、最小	事故高发区
错	非法输入：类型错、格式错、负数	看它报错还是崩溃
空	空串、空数组、null、没填	崩溃第一元凶

务实标准：一个函数，四靶各写一条，四条就够用。 别一上来想写二十条。

三、让 AI 写测试：四步法「框、说、生、补」

流程压成四步，口诀：框、说、生、补。

第一步：框——先定测试框架

新手第一个坑。 直接说”帮我写单元测试”，AI 随便挑个框架给你写，复制过去一跑满屏报错——你项目根本没装那个框架。正确做法：先问 AI 你该用什么。 把项目依赖清单文件（记录”用了哪些工具”的文件）整份贴给 AI，问清三件事：① 已装测试框架吗、装哪个？② 没装推荐哪个、安装命令？③ 测试文件放哪、文件名怎么起。问清这三件少走一半弯路。

第二步：说——说清”它应该做什么”，别让 AI 猜

全篇最重要的一句话：千万不要只把代码丢给 AI 说”帮我写测试”。

因为 AI 会照着你的代码写测试。代码有 bug，AI 就把 bug 当”正确答案”写进断言。比如”满 100 减 20”你写错了写成”大于 100 才减”，AI 一看写出测试：”输入 100 应该不减。”测试绿了，可 bug 被永久固化，还有测试给它背书。

破法：先用大白话描述函数「应该」做什么，让 AI 按描述写，不是按代码写。 对比：

❌ 差：「这是我的代码，帮我写测试。」
✅ 好：「业务规则：订单原价满 100（含 100）减 20，不满不减，负数直接报错。请按这规则写测试。写完后对照我贴的代码，告诉我代码和规则有没有对不上。」

后半句是白送的 bug 检测器，让 AI 拿”规则”和”代码”对一遍，常能当场抓问题。

第三步：生——生成，然后一定要跑起来

AI 给测试代码后，别看，直接跑。 新手常卡在这三类报错：① 找不到文件（引入被测代码的路径不对）② 框架没装（命令不认识）③ 配置缺失（需要配置文件）。这三类全不用自己解决——把报错原文（整段别转述）贴回给 AI，加一句：”我按你给的代码跑，报了这个错，这是完整报错，请告诉我原因和具体改哪个文件哪行。” 这是第 71 篇老规矩：报错贴原文。

跑起来看到第一排绿勾，你才算真入门。

第四步：补——看覆盖率，找洞，补测

跑通后让 AI 教你开覆盖率报告：绿色行 = 被测到过，红色行 = 一次没跑到。

四、覆盖率：别追高，要找洞

覆盖率是新手最容易被骗的数字。 先把话说死：覆盖率高 ≠ 代码没问题。 它只统计”这行被跑过”，完全不管你有没有检查结果对不对。 极端例子：写个测试把所有函数调一遍，一个断言不写，覆盖率 100%，但啥也没测——从不检查结果，返回什么都说通过。

正确用法：不是追高，是找洞。 打开报告只看红色，对每块红的问自己：”这段代码从来没被测过，我慌不慌？”慌（支付金额、权限、扣库存）→ 立刻补；不慌（打印日志、界面颜色）→ 放着。这才是覆盖率真正的用法：一张藏宝图，标出你没走过的路，挑重要的走。

代码类型	建议覆盖率	理由
核心业务逻辑（钱、权限、库存）	80% 以上	出事代价最大
工具函数（格式化、校验）	60%~80%	好测，顺手测
界面胶水代码	不强求	测起来贵收益低
第三方库代码	0%	那是人家的事

为凑数字写假测试，是纯粹自我欺骗。 数字好看了，安全网还是破的。

五、AI 写测试的三个坑，提前告诉你

坑一：AI 把 bug 当正确答案。 上面说过，破法就是先说规则再让它写，最重要的一条。

坑二：AI 爱写”测了个寂寞”的测试。 它把所有外部依赖都换成假的（术语 mock），假到最后测的全是自己造的假数据，真实逻辑一行没跑到。破法加一句约束：“尽量少用 mock，只有网络请求、数据库、文件读写、当前时间这四类才允许替换成假的，其余用真实调用。”

坑三：AI 造的测试数据太”干净”。 它特爱用”张三”“test@test.com”“123”，全是标准格式一个坑踩不到。破法点名要脏数据：“测试数据要贴近真实：含中文、空格、超长字符串、特殊符号、emoji、前后带空格的输入。”

六、一条铁律：测试红了，先怀疑代码

这条单独说，因为它决定这套东西有没有用。你常会遇到：改了点代码一跑，红了。新手第一反应：”这个测试挡我路了，我把它改改让它过。”打住。

测试红了，永远先怀疑代码，最后才怀疑测试。

测试红是好事，说明安全网起作用了，刚拦下你没意识到的行为变更。把断言改成新结果，等于看到火警响了把警报器电池抠掉。

正确顺序：① 看它红在哪（期望值 vs 实际值）② 问：这变化是我故意的吗？③ 不是故意 → 恭喜抓到 bug，改代码 ④ 是故意（需求真改了）→ 才改测试，并在提交说明写清为什么改。这一条记住了，这篇文章就没白读。

七、完整走一遍：从零到绿灯

贴依赖清单，问 AI 用什么框架、装什么、文件放哪
装好框架，让 AI 写个”1+1=2”级最简单测试，先确保能跑起来（省掉后面 80% 抓狂）
挑最核心的函数（管钱、管权限那个）
用大白话写它应该做什么（业务规则）
让 AI 按规则 + 四靶写测试
跑，报错就贴原文回问
绿了看覆盖率，挑红色重要的补
以后每次改代码，先跑一遍测试

第 8 条才是全部价值所在。 前七步一次性投入，第八步是你此后每天的收益。

提示词模板盒子

模板 1：按业务规则写测试（核心，最重要）

请帮我为下面这个函数写单元测试。

【第一部分：这个函数应该做什么（业务规则）】
用大白话一条条列：
1. ……
2. ……
3. 出现 XX 情况时，应该报错，不能返回错误结果

【第二部分：当前代码实现】
（完整贴代码，不要贴片段）

【第三部分：要求】
1. 测试框架用：XXX
2. 严格按【业务规则】写测试，不要照代码现有行为写
3. 每个规则至少覆盖四类：正（典型正常）/ 边（临界值0、1、正好、最大、最小）/ 错（类型错、格式错、负数）/ 空（空串、空数组、null、字段缺失）
4. 尽量少用 mock，只有网络/数据库/文件/当前时间才允许替换成假
5. 测试数据要贴近真实：含中文、空格、超长串、特殊符号、前后带空格
6. 每条测试上用中文注释写清"测什么、为什么测"
7. 给完整可运行测试文件，不要片段

【第四部分：额外任务】
写完对照【业务规则】和【代码】，告诉我代码有没有和规则对不上，逐条列：规则说啥/代码做啥/造成啥后果。

模板 2：环境搭建与排错（定框架 + 跑不起来用）

【A. 确定框架（第一步必用）】
我是编程新手，想加单元测试，不知从哪开始。下面是我项目依赖清单文件内容：
【把依赖清单完整内容贴这里】
请大白话告诉我四件事：1. 已装测试框架吗、装哪个 2. 没装推荐哪个（新手易上手）、完整安装命令 3. 测试文件放哪、文件名怎么起 4. 装完用什么命令跑。
最后给个最简单"能跑通就行"的示例测试文件（比如测加法函数），我先确认环境通再写真的。

【B. 测试跑不起来（排错专用）】
我按你给的测试代码运行，报错了。
【我执行的命令】（原样贴）
【完整报错信息】（一个字没改全贴）
【我的项目目录结构】（测试文件和被测代码分别在哪）
请告诉我：1. 报错原因（大白话）2. 具体改哪个文件哪行、改成什么 3. 一次只给一处修改，我改完跑一遍再回来。

模板 3：找洞与验伪（覆盖率 + 测试红了用）

【A. 看覆盖率报告找洞】
我跑出覆盖率报告，下面是没被测到的代码行：
【未覆盖代码】（贴报告标红那段）
请做三件事：1. 逐段说明这段代码干啥、啥情况被执行到 2. 按"出事后果严重程度"排成【必须补】【建议补】【可以不管】三档（涉及金额/权限/删除/库存一律必须补）3. 对【必须补】直接给可运行测试代码。
我不追求数字好看，只想补真危险的地方，别为凑数建议给日志/常量/赋值写测试。

【B. 测试失败了，帮我判断】
我改了代码，一条测试红了。请判断该改代码还是改测试。
【失败的测试】（贴）【报错内容】（期望值和实际值那部分必贴全）【我这次改了什么】（大白话）
请回答：1. 这条测试原本保护什么行为 2. 我改动是"不小心破坏原行为"还是"需求真变了" 3. 前者告诉我校哪、怎么改回 4. 后者告诉我测试怎么更新，并写一句提交说明讲清为什么变。
请不要默认"改测试让它通过"是正确答案。

79 篇速查卡

记忆点	内容
单元测试是什么	用代码写的行为快照表，一行命令全跑完
测试三句话	准备 → 执行 → 断言（断言是灵魂）
测试四靶	正（正常）边（临界）错（非法）空（空值）
AI 写测试四步	框（定框架）说（说规则）生（生成跑通）补（覆盖率找洞）
最大的坑	只贴代码让 AI 写 → bug 被当正确答案固化
覆盖率用法	不追高，只用来找洞；红的里挑重要的补
铁律	测试红了，先怀疑代码，最后才怀疑测试

下篇预告

测试是机器帮你盯”结果对不对”。但有一大类问题机器盯不到：密钥写代码里、用户输入原样拼查询、循环里一遍遍查库、错误信息把内部结构吐给前端——这些代码全跑通、测试全绿，可迟早出事。这类本靠有经验同事帮你看，可你没有那个同事呢？下一篇《第 80 篇：用 AI 做 Code Review》教你把 AI 变成那个同事。下篇见。

第78篇：用 AI 做代码优化（性能/可读性）——双管齐下

2026-10-05T10:00:00+08:00

页面转圈五秒，用户已经关了。

上一篇我们把代码”擦干净”了，但没让它变快一分一毫。

这一篇要处理的，是所有人都会遇到的另一个难题：代码不光要好读，还得跑得动。 而这两件事经常打架——你会发现一个残酷规律：让代码变快的手段，多半会让它变难懂。 加缓存、批量、并发，每样都在往代码里塞额外复杂度。

所以”优化”和重构完全不同：

重构是”只赚不赔”，优化是”有得有失”。

重构改完更好懂、功能没变、没有代价。优化改完更快了，但总要付出点什么——可读性、内存、或多一个可能出错的环节。既然是买卖，就得先算账。

一、优化三问：值、位、价

动手之前先问自己三句话，口诀“值、位、价”。

第一问：值不值得改？（值）

这一问能砍掉八成无效优化。问自己：现在这个速度，真的有人在抱怨吗？

后台页面加载 1.2 秒 —— 不用改，没人骂你。
点提交转圈 6 秒 —— 必须改，已经在流失用户。
一年跑一次的报表脚本跑 10 分钟 —— 不用改，花两小时优化一年只省 9 分钟。

很土但好用的尺子：

场景	用户感受	该不该改
100 毫秒内	感觉”瞬间”	别碰
100ms - 1 秒	感觉”流畅”	一般不用
1 - 3 秒	开始”有点慢”	看情况
3 - 10 秒	明显不耐烦	该改
10 秒以上	以为坏了直接关	立刻改

过早优化是新手最大的时间黑洞。 你花一下午把 0.3 秒优化到 0.2 秒，用户完全无感，代码却多了一层没人懂的逻辑。

第二问：改哪一处？（位）

回到第 73 篇铁律：先测量，再优化。 绝大多数程序耗时符合规律：80% 的时间花在 20% 的代码上。 你随手挑一段优化，大概率优化了一段本来就不慢的东西。

顺序永远是：先测（整个流程几秒）→ 再拆（几秒分别花在哪）→ 锁定（占比最大的那段）→ 只改它，其他不动。没有测量数据就优化，等于蒙眼开枪。

第三问：代价是什么？（价）

最容易被跳过、也最要命的一问。任何优化都有代价，常见四种：

可读性（代码变绕）
内存（用空间换时间，缓存多了爆内存）
一致性（加了缓存数据可能旧）
复杂度（多一个可能出错的环节）

让 AI 优化时，一定要逼它把代价说出来。 它默认只吹”性能提升 80%”，不会主动告诉你”但数据可能延迟 5 分钟”。

二、提速四招：少、缓、批、延

真要改的时候，小白只需认识四类手段，口诀“少、缓、批、延”。这四招覆盖日常九成性能问题。

第一招：少（少做点事） 最朴素也最有效：本来做十次改做一次。比如计算结果在循环里被反复算一千遍，算一遍存起来就行；从数据库查一万条回来在代码里筛五条——为什么不让数据库直接给那五条？代价：几乎没有，永远优先用。

第二招：缓（算过的存起来） 同样问题第二次直接给上次答案。城市列表、商品分类、汇率一天不变，每次查库纯浪费。代价：数据可能是旧的。 用缓存前先问：”这个数据过期 5 分钟会出事吗？”城市列表没事，账户余额过期 5 分钟出大事。

第三招：批（一次一批，别一次一条） 数据库操作上效果最猛，常快十倍以上。要存 1000 条却循环一条条存 1000 次，光”打招呼”就耗掉大部分时间，打包一次送过去直接起飞。代价：一批里一条出错，整批怎么办？要提前想清。

第四招：延（不急的放后面） 用户等的马上做，不急的挪后面。点”提交订单”依次做了存订单→扣库存→发短信→发邮件→写日志——用户等的只是”存没存上”，后面三件他不在乎。挪后台慢慢做，等待时间砍掉一大半。代价：多一个”后台那步失败了怎么办”的问题。

三、性能和可读性打架时，听谁的？

先给结论：99% 情况下，可读性优先。 依据很硬：你 99% 的代码根本不在瓶颈上，那部分写得再”高效”对整体速度影响近零，但变难懂的代价你每天承受。

情况	选谁
没测量，凭感觉慢	可读性（先去测量）
测过，这段不是瓶颈	可读性
测过是瓶颈，但优化只省 50 毫秒	可读性（不值得）
测过是瓶颈，从 6 秒降到 1 秒	性能，但必须补注释
是瓶颈，且优化后没变难懂（”少”常见）	两个都要

真要为速度牺牲可读性，你有义务留三样东西，否则三个月后这段代码成没人敢碰的雷区：

一段”为什么”注释——不要写”这里做了缓存”（代码看得出），要写清背景：哪天排查发现首页每次查全量分类表、单次 800ms、占首页 70%、分类日均变 0-1 次、允许 10 分钟延迟。
一组数字——”优化前 6.2 秒，优化后 1.1 秒”，写进注释，是后人判断”这段还值不值得留”的唯一依据。
一句”什么情况可删掉”——比如”分类降到 50 条内，这缓存可直接删”。

没有这三样，你留的不是优化，是定时炸弹。

四、实战：完整的一次优化对话

场景：用户点”导出订单”，转圈 12 秒。

第一步：先量（别跳过）。 第一句话不该是”帮我优化”，而是”帮我测量”。让 AI 加计时点跑一次，看 12 秒花在哪：

查询订单数据      1.1 秒
循环处理每条订单  9.8 秒   ← 元凶
生成文件          0.7 秒
写入响应          0.4 秒

优化的目标只有一个——那 9.8 秒。 剩下三段加起来才 2.2 秒，优化到 0 也只省两秒。

第二步：让 AI 给方案，但要它列代价。 关键：不要直接要代码，先要方案对比表。

方案	手段	预估效果	可读性代价	风险
A	循环里每条查用户名→改一次批量查	9.8s→1.5s	低	低
B	加多线程并发	9.8s→3s	高	中（并发问题）
C	结果整体缓存 10 分钟	二次→0.1s	中	中（数据延迟）

选择很明显：方案 A——效果最好、代价最低、风险最小，用的正是”批”。循环里查库是新手最常见性能杀手，行话叫 N+1 查询。方案 B 那种”加多线程”听着高级，但并发引入的 Bug 比它解决的性能问题更麻烦，能不用就不用。

第三步：只改这一处，改完再量。 从 12 秒降到 3.7 秒。这时停下问第一问：”还值得继续改吗？”3.7 秒已从”以为坏了”变成”有点慢但能接受”，再抠收益递减、风险递增。优化最容易上瘾，见好就收是一种能力。

五、三个新手最容易踩的优化陷阱

陷阱一：相信 AI 报的”提升百分比”。 它很自信说”提升 80%”，那是它猜的——没跑过你代码、不知数据量、不知配置。唯一可信的数字是你自己跑出来的，改完必须重测。

陷阱二：一次改五处。 和重构同理，但优化更危险——你分不清是哪一处带来提升。万一某处其实让程序变慢，被另一处提升掩盖，根本发现不了。一次改一处，改完就量。

陷阱三：优化了功能，忘了验证正确性。 最惨的一种：代码从 12 秒变 1 秒，但导出数据错了。性能优化常动数据处理逻辑——批量可能漏数据、缓存给旧数据、并发乱序。第 77 篇那张”行为快照表”，优化场景同样必须做，而且要更严格：优化后的正确性验证，比重构还重要。

六、一张随身判断表

□ 用户真的抱怨了吗？没有 → 停，别改
□ 慢到几秒？3 秒以内 → 大概率不用改
□ 我测量过了吗？没有 → 先去测，别猜
□ 最慢那段占比多少？不到 50% → 改它收益有限
□ 能用"少"解决吗？能 → 优先，代价最低
□ 要用"缓"吗？数据旧了会出事吗？
□ 要用"批"吗？一条失败整批怎么办？
□ 要用"延"吗？后台失败了谁来管？
□ 改完可读性变差了吗？变差 → 补三样：为什么/数字/何时可删
□ 改完我重新测了吗？
□ 改完验证数据还是对的吗？（比性能更重要）
□ 现在速度够用了吗？够了 → 停手

提示词模板盒子

模板一：先测量（永远的第一步）

下面这段代码执行很慢，用户点击后要等约 __ 秒。

【本轮只做一件事：帮我测量，不要优化】
1. 在关键节点插入耗时统计，把流程拆成若干段，分别打印每段耗时
2. 告诉我应该重点关注哪几段
3. 给我完整文件（含插入的计时代码）
4. 告诉我：测完怎么读这些数字，什么占比才算"这就是瓶颈"

【代码】
（在此粘贴完整文件）

模板二：方案对比（要表格，不要代码）

我已经测量过了，耗时分布如下：
（贴出各段耗时）
最慢的是【____】这一段，占总耗时约 __%。

【本轮要求 · 重要】
1. 只针对最慢这段给方案，其他部分一律不讨论
2. 不要给我代码，先给【方案对比表】，至少 3 个方案，含：
   方案 | 具体手段 | 预估效果 | 可读性代价（低/中/高） | 引入的新风险 | 实现难度
3. 明确标出你推荐哪个，以及为什么
4. 特别说明：哪些方案会改变数据正确性/一致性/实时性
5. 若属"用空间换时间"，说明大概多占多少内存

【我的情况】
数据量大约：____   使用人数：____   技术水平：新手，优先好理解、风险低的方案

模板三：执行与验收（带正确性护栏）

我选择方案【__】，请帮我实现。

【铁律】
只改这一处，其他任何地方不要动
性能可提升，但【数据正确性绝对不能变】——同样输入必须得到完全一样输出
若优化让代码变难懂，必须补注释说明：为什么这么写（原来慢在哪多慢）、优化前后耗时数字、什么情况可删这优化
若引入缓存，明确告诉我：缓存多久过期、数据变更时怎么失效

【交付要求】
完整文件，不要片段
末尾用表格列出：改了哪几行 | 改成什么 | 为什么
单独列出：改完我必须重点测哪几种情况（尤其易错边界）

【验收】这是优化前【A】和优化后【B】，请严格检查：
【正确性】所有输入下输出是否一致？特别查空数据/单条/超大量/特殊字符
【遗漏】A 里哪些判断/异常处理在 B 里被省略了
【新风险】B 引入了哪些 A 没有的失败可能（缓存不一致/批量部分失败/并发冲突）
【可读性】给 B 可读性 1-10 打分，说明比 A 差在哪
一句话结论：这次优化"划算"还是"不划算"
【A】（粘贴）【B】（粘贴）

下篇预告

两把刀到手：第 77 篇重构（擦干净，只赚不赔）、第 78 篇优化（跑得快，有得有失）。但都共一个前提——你得知道”改完到底有没有改坏”。手工快照表太累还爱偷懒。下一篇《第 79 篇：用 AI 写单元测试》讲怎么让机器自动盯。下篇见。

第77篇：用 AI 重构烂代码——可读性直线上升

2026-10-04T10:00:00+08:00

代码能跑，但一个月后你自己都看不懂。

这就是所有人都会撞上的那堵墙。

前面十几篇我们一直在解决”能不能跑“：写出来、跑起来、修好 Bug。从这一篇开始换赛道，解决”跑得好不好看“。

你可能会想：能跑就行呗，好看有什么用？我给你算笔账。

一段乱七八糟的代码，今天写完能跑。三周后要加功能，你盯了二十分钟才想起来”这个变量是干嘛的”。改完一测，另外三个地方坏了——因为你根本不知道这段代码还被谁用着。

代码不是写给电脑看的，电脑什么烂代码都能跑。代码是写给三周后的你自己看的。 而”三周后的你”，记忆力大概等于一个陌生人。

这一篇，教你把 AI 变成专门帮你”擦桌子”的助手。

一、先说清楚：什么叫重构

这个词听着唬人，其实一句话就能说明白：

重构 = 只改样子，不改行为。

改之前输入 1 得到 2；改之后输入 1 还得得到 2。功能一模一样，只是更好读了。 这句话是本篇的地基，务必记牢。新手用 AI 重构翻车，九成踩在这一句上。

典型翻车现场：

小白：（把整个文件甩给 AI）帮我重构一下这段代码。 AI：好的！我帮你重构了。（顺手合并三个功能，删掉两个”看起来没用”的判断，还改了接口返回格式）小白：（一测）……怎么全崩了？

AI 不知道哪些代码”看起来没用但其实很重要”。 那个奇怪的 if，可能是三个月前为某个客户特殊情况加的。你不说，AI 就当垃圾清掉。所以重构主导权必须在你手上，AI 只是那把刀。

二、烂代码的六种味道：先学会”闻”

程序员圈有个说法叫 Code Smell（代码坏味道）：不一定有 Bug，但闻着不对劲，早晚出事。记六种就够了，口诀长、重、名、套、魔、杂，叫重构六味：

第一味：长（函数太长） 一个函数拉到两百行，滚轮滚半天。判断标准很土但好用：一屏放不下，就是太长了。

第二味：重（重复代码） 同一段逻辑复制粘贴出现三次以上。改的时候必须记得改三个地方——你一定会忘掉一个。

第三味：名（命名瞎起） 满屏 a、b、tmp、data1、flag。写的时候知道，三周后不知道。

第四味：套（嵌套太深） if 里套 if，if 里再套 for——缩进快顶到屏幕右边了。 超过三层就该警觉。

第五味：魔（魔法数字） 代码里突然冒出 7、0.85、3600。从哪来的？代表什么？没人知道，包括三周后的你。

第六味：杂（一个函数干太多事） 一个”保存订单”函数，又查库存、又算优惠、又发短信、又写日志。名字说它干一件，实际干了四件。

三、重构四步法：锁、闻、拆、验

整套流程四步，口诀“锁闻拆验”。

第一步：锁（锁定行为基线）

这是最重要、也最容易被跳过的一步。 动任何一行之前，先回答：

改完之后，我怎么证明”没改坏”？

答不上来，就不要开始。最实用的做法是做一张“行为快照表”：把这段代码目前的几组”输入 → 输出”记下来。比如算运费的函数，实际跑几次记下来：

输入：重量 0.5kg、地址 本市    → 输出：6 元
输入：重量 3kg、地址 外省      → 输出：18 元
输入：重量 0（异常）           → 输出：报错"重量不能为0"
输入：地址 为空（异常）        → 输出：默认按外省算，22 元

最后两条异常必须记——AI 重构时最爱”顺手优化”的就是这些奇怪的边界处理。另外动手前做件五秒钟的事：把原文件复制一份改名 xxx_备份.txt 存着，它救过无数人。

第二步：闻（让 AI 先体检，不许动手）

很多人一上来就说”帮我重构”，这是错的。第一轮，只让 AI 诊断，明确禁止它给代码。 你要先知道这段代码有几个问题、哪个最严重，然后自己决定改哪个。诊断时让 AI 按六味对号入座，并按严重程度排序。

第三步：拆（一次只改一味）

看到 AI 列出六个问题，新手本能是”都改了吧”。千万别。 一次改六处，出问题你根本不知道是哪处引起的。一次只改一味，改完立刻验，验过再改下一味。

顺序建议从最安全的改起：

优先级	改什么	风险	收益
1	名（改命名）	极低	立竿见影
2	魔（数字变常量）	极低	高
3	重（合并重复）	中	高
4	长 / 杂（拆函数）	中	高
5	套（减少嵌套）	中高	中

先改成命名和魔法数字——几乎不可能改坏，读起来立刻不一样，先尝甜头建信心。拆函数放后面，因为它动结构、风险更高。

第四步：验（每改一次就验一次）

拿出第一步那张快照表，四组全跑一遍，尤其那两条异常——它们最容易被”顺手删掉”。一致 → 通过，进下一味；不一致 → 立刻回退备份，别试图”再改改就好了”。

四、实战演练：一段”六味俱全”的代码

假设你手上有段处理订单的代码（语言不重要）：两百行函数叫 handle，普通用户折扣写死 0.95、会员 0.85，if 套 if 套 if 判断四层库存和地区，三段几乎一样的”算运费”只是数字不同，最后又发短信又写日志。六味占全了。

第一轮，你说：“只诊断，不要给代码。按六味列出问题并排序。” AI 会给体检报告：杂（严重）、魔（严重，0.95/0.85/3/7 含义不明）、重（中等）、名（中等）、套（中等）、长（中等）。

第二轮，你只说一句：“先只改【魔】这一项，把四个数字提成有名字的常量，其他一律不动，给完整文件。” 改完跑快照表，四组一致 → 通过。

第三轮：“再只改【名】……” 这个节奏才对。 看着慢，但每一步都安全、随时能停。而”一次全改”看着快，一出事你要花三倍时间找哪儿坏的。

五、四个必须知道的坑

坑一：让 AI “顺便优化一下”。 最危险的六个字。你说重构它只改结构；加一句”顺便优化”，它可能改了业务逻辑。重构时明确禁止 AI 改变任何功能，写进提示词。

坑二：只给片段。 你只贴那个 200 行函数，没贴调用它的地方。AI 把函数名从 handle 改成 processOrder——所有调用处全报错，因为它不知道谁在调。→ 改函数名前，先问”这函数在哪被调用”，或自己全局搜一下。

坑三：接受”看起来更简洁”的改动。 AI 特喜欢把五行压成一行，看着酷但读起来更费劲。重构目标是”更好懂”不是”更短”，改完你自己读着更吃力，就是失败。

坑四：没有快照表就开始改。 头号死因，再强调一次：没有验收标准的重构，不叫重构，叫赌博。

六、什么时候不该重构

三种情况别碰：

马上要上线——上线前一天动结构等于找刺激；
半年内不会再碰——重构是投资，要看回报；
完全看不懂在干嘛——先回第 69、74 篇让 AI 讲清楚，看不懂就改，坏了自己都不知坏哪。

三种情况值得改：

你每周都要打开这个文件
你准备在这加新功能
最近连着出过两次 Bug

重构最佳时机，是”你正要在这儿加东西”的前一刻——先扫地，再搬家具。

提示词模板盒子

模板一：代码体检（第一轮必用，只诊断不给码）

你是一位注重可维护性的资深工程师。

下面是我项目里的一段代码，我想改善它的可读性。

【本轮要求 · 重要】
1. 只做诊断，不要给我任何修改后的代码
2. 按以下六类"坏味道"对号入座：
   - 长：函数过长   - 重：重复代码   - 名：命名不清
   - 套：嵌套过深   - 魔：魔法数字   - 杂：单个函数职责过多
3. 按【严重程度】排序，每条注明：位置（第几行）| 具体问题 | 为什么是问题 | 预估改动风险（低/中/高）
4. 最后单独告诉我：你建议我第一个改哪一项，为什么

【代码】
（在此粘贴完整文件，不要只贴片段）

模板二：单点重构（一次只改一味）

接着上面的诊断。

【本轮只做一件事】
只修改【____】这一项问题，其他任何地方一律不动。

【铁律】
1. 严禁改变任何功能行为——输入什么，输出必须和原来完全一致
2. 严禁删除任何看起来"没用"的判断或分支（那可能是特殊业务处理）
3. 严禁"顺便优化"任何其他内容
4. 目标是更好懂，不是更短。不要为简洁牺牲可读性

【交付要求】
1. 给我完整文件，不要片段
2. 末尾用表格列出：改了哪几行 | 改成什么 | 为什么
3. 如果改动可能影响文件之外（如函数改名影响调用方），请明确警告我检查哪些位置

模板三：基线与验收（动手前建快照 + 改完对比）

下面这段代码，我准备重构它。

【第一部分 · 动手前：建立行为基线】
1. 列出所有输入参数及取值范围
2. 帮我设计 5 组测试用例，必须包含：2 组正常、2 组边界/异常（空值、0、超大值）、1 组最容易忽略的特殊分支
3. 每组写清：输入 | 预期输出
4. 指出有没有"看起来没用、但可能是特殊业务处理"的分支，单独标出提醒我别删

【第二部分 · 改完后：行为对比检查】
这是重构前的【A】和重构后的【B】。
1. 逐项确认 B 相对 A 有无任何功能行为变化
2. 特别检查：A 里哪个判断分支/异常处理/边界，在 B 里被弱化或删掉了
3. 有没有变量/函数被改名？有则列出提醒我检查调用方
4. 一句话结论：这是"安全重构"，还是实际已变成"重写"

【A - 重构前】
（粘贴）
【B - 重构后】
（粘贴）

下篇预告

这一篇我们只做了一件事：让代码变好读，一个字功能都没改。 可现实里代码不光要好读，还得跑得快——而这俩常打架。下一篇《第 78 篇：用 AI 做代码优化》讲”优化三问”与”提速四招”。下篇见。

第76篇：调试类小结——把排错思路彻底沉淀下来

2026-10-03T10:00:00+08:00

招式学了七篇，现在把它们收成一套。

从第 69 篇到第 75 篇，我们一路走过来：读不懂代码怎么办、框架原理怎么问、报错怎么贴、没报错怎么查、慢在哪怎么找、老项目怎么接、真实 Bug 怎么走完全程。

七篇，七套打法。

但如果你现在遇到一个新问题，脑子里第一反应还是“我该用哪一招？”——那说明这些招式还是散的。

这一篇的任务就是把它们收成一套，交给你三样东西：一张决策树、一套母版、一份误区清单。看完这篇，”代码理解与调试”这个小节就结课了。

一、先把七篇摆在一张地图上

很多人学完一堆技巧记不住，是因为脑子里没有位置感。先看这张地图——七篇其实只解决三类问题：

第一类：我看不懂（理解型）

篇目	解决什么	核心打法
69	一段代码读不懂	让 AI 逐行翻译成中文，先问干什么再问怎么做
70	用了库但不懂原理	让 AI 用生活类比讲清楚，再问”什么时候会坑我”
74	接手祖传老项目	剥洋葱五层：入口→地图→主线→数据→细节

第二类：它不对劲（故障型）

篇目	解决什么	核心打法
71	有红字报错	报错贴原文，一个字都不转述
72	没报错但结果不对	说清“期望什么 / 实际什么”，让 AI 逆推
75	完整一次实战	排错八步：现界差证，设修归盘

第三类：它太慢（性能型）

篇目	解决什么	核心打法
73	卡、慢、转圈	先测量再优化，性能四件套：作量时标

理解型问”这是什么”，故障型问”哪里错了”，性能型问”慢在哪里”。

三类问题，三种提问方式。选错类型，怎么问都问不出结果。

二、排错总决策树：遇到问题先问自己三句话

遇到问题别急着打字，先花十秒问自己三句话，你就知道该走哪条路。

第一句：屏幕上有没有红字 / 报错？

有 → 走【报错线】：完整复制报错原文 + 完整代码文件，直接问 AI。这是最省事的一条路，报错本身就是最强线索。
没有 → 进入第二句。

第二句：是”结果不对”，还是”能用但很慢”？

结果不对（数据没保存、数字不对、点了没反应）→ 走【逻辑线】：说清“我期望什么、实际得到什么、用的什么输入”，让 AI 逆推。
能用但很慢 → 走【性能线】：先测量，找出最慢的那一段再优化。没测量就优化 = 瞎猜。

第三句（前两句都不适用时）：我是不是压根没看懂这段代码？

是 → 走【理解线】：先让 AI 逐行讲清楚，看懂了再谈修。

再补一句判断偶发问题的：

如果问题”有时有、有时没有” → 不管属于哪条线，先做差异法：找一个必成功的例子和一个必失败的例子，逐字段对比，先把那个条件变量抓出来。

三、万能排错提示词母版：五件套

前面七篇给了几十个提示词模板，其实它们全都长一个样。骨架就五段，我叫它排错五件套：

象 · 证 · 境 · 试 · 要

段	全称	写什么	常见错误
象	现象	期望什么 / 实际什么	只说”报错了”“不好使”
证	证据	报错原文、日志、代码完整文件	转述、截断、只贴片段
境	环境	什么系统、什么工具、什么条件下必现	完全不提
试	试过	我已经排除了什么	让 AI 重复走你走过的死路
要	要什么	要解释？要清单？要改好的代码？	不说，然后嫌它答非所问

把这个骨架背下来，你就不需要背模板了。 完整母版见文末模板盒子。

同样一个问题：只说”报错了，帮我看看” → AI 给你一段通用建议，八成不对症；五件套齐全 → AI 基本一次命中。你多花两分钟组织信息，能省下两小时来回试错。

四、新手八大误区（踩一个白干半天）

这七篇里反复强调的坑，集中列在这儿：

误区一：不复现就开始改。 听用户说两句就动手，改了半天发现人家根本没点提交按钮。→ 自己亲眼看到 Bug 发生，才算立案。

误区二：转述报错。 “它说什么找不到之类的。” → 报错原文每个字符都是线索，全选、复制、原样贴。

误区三：只贴片段。 贴出错那三行，AI 看不到上下文只能猜。→ 贴完整文件。多贴几十行不花钱，猜错一次浪费半小时。

误区四：一次问五个问题。 “顺便优化下性能，再美化界面。” → AI 会给你大杂烩，还可能顺手改坏好的地方。一次一个问题。

误区五：让 AI 直接给代码，跳过解释。 它给了你贴上去好了，但不知道为什么好，下次还犯。→ 先要解释，再要代码。

误区六：AI 说什么信什么。 它会非常自信地编造不存在的函数名、配置项。→ 它说的是假设不是结论，每一条都要验证。

误区七：改完只测那一个场景。 修好失败那条就上线，结果把原来好的搞坏。→ 三条必测：原来坏的、原来好的、极端的。

误区八：修完就完，不复盘。 → 多问一句”同类问题项目里还有几个”，往往一次扫掉三五个雷。

五、关于 AI 排错，三条底线必须记住

这三条比任何技巧都重要。

第一条：AI 只知道你给它的那一屏。 它看不到你没贴的文件、数据库里的真实数据、服务器上的配置、你昨天改了什么。所以它答得不对，很多时候不是它笨，是你给的信息不够。

第二条：AI 不会说”我不知道”。 你问它不确定的问题，它大概率编一个听起来很合理的答案——语气笃定、格式工整、就是不对。→ 凡是它说的”因为 XX 导致 YY”，你都要能自己验证一遍。验不了的，别信。

第三条：最终按下确认键的人是你。 AI 可以给方案，但它不承担后果。数据删了是你删的，线上崩了是你的锅。所以规矩要成肌肉记忆：

改动前先备份
删改数据前，先只查不改试一遍
一次只改一处，改完立刻验证

六、一张随身自查表

把这张表存手机里，遇到问题照着走：

□ 我亲眼看到问题发生了吗？（没有 → 先复现）
□ 我能找到"必失败"和"必成功"两个例子吗？（偶发问题必做）
□ 这属于哪一类：看不懂 / 不对劲 / 太慢？
□ 数据断在哪一段：浏览器 / 网络 / 后端 / 数据库？
□ 我贴的是报错原文，还是我的转述？
□ 我贴的是完整文件，还是片段？
□ 我说清楚"期望什么、实际什么"了吗？
□ 我告诉 AI 我已经试过什么了吗？
□ 我要的是解释，还是代码？我说清楚了吗？
□ AI 给的原因，我验证过了吗？
□ 改动前我备份了吗？
□ 改完我测了三条吗（原来坏的 / 原来好的 / 极端的）？
□ 我问过"同类问题还有几个"吗？

十三个框全打勾，你就不是新手了。

七、这个小节最后想说的

很多人以为，会用 AI 写代码是本事。其实真正的分水岭是——生成出来的东西不对劲时，你能不能救回来。

这七篇讲的所有东西，本质上只有一件事：

AI 是一个知识极其渊博、但眼睛看不见的顾问。它的能力上限，取决于你描述现场的能力。

而”准确描述一个问题”，恰恰不需要任何代码基础。 一个完全不懂编程的人，认真练这七篇的方法，排错能力可以超过很多写了三年代码但从不整理思路的人。

工具是新的，方法是老的：看清现场、缩小范围、逐个验证、留下记录。 祝你以后每个 Bug 都死得明明白白。

📦 提示词模板盒子

模板一：万能排错五件套（象证境试要）

我遇到一个问题，需要你帮我定位。

【现象】
我期望：[正确应该是什么样]
实际发生：[实际是什么样]
偶发情况：[什么条件下必现，什么条件下正常]

【证据】
报错/日志原文（完整粘贴，未做任何修改）：
[粘贴，前后各多贴几行]

相关代码（完整文件，不是片段）：
[粘贴]

【环境】
系统：[Windows / Mac]
工具：[你用的 AI 工具]
触发条件/数据规模：[比如：数据超过 200 条时必现]

【我已经试过】
1. [试过什么，结果如何]
2. [排除了什么可能]

【我要什么】
1. 用大白话解释这是什么问题
2. 按可能性排序，列出 3 个最可能的原因
3. 每个原因告诉我怎么快速验证
4. 先解释和列清单，暂时不要给我改好的代码

我是新手，不熟悉专业术语，请一步步说清楚。

模板二：分流器（不知道怎么问的时候先问这个）

我遇到一个问题，但我不确定该从哪查起。

【我看到的现象】
[尽可能具体地描述，包括你点了什么、看到什么]

请你先不要给我解决方案，先帮我判断：
1. 这属于哪一类问题：代码理解 / 功能出错 / 性能太慢 / 环境配置
2. 我接下来应该收集哪些信息给你？请列一份"取证清单"，
   每一条写清楚我具体该点哪里、看什么
3. 这些信息里，哪一条最关键，我先弄哪个

我完全是新手，请把操作步骤写细一点。

模板三：校验与收尾（验真伪 + 安全护栏 + 复盘）

【A. 结论校验——怀疑 AI 在编时用】
你刚才说问题的原因是：[复述它的结论]。在我照做之前，请自己复核：
1. 这个结论依据的是我提供的哪几行内容？请指出来
2. 如果我提供的信息不足以支撑这个结论，请直接说"信息不够"
3. 你提到的函数/配置/参数，是否确实存在于我贴的代码里？逐个核对，不存在的请明确指出
4. 除了这个原因，还有没有别的可能被你忽略

【B. 安全护栏——让 AI 改动前必加的一段】
在你给出任何修改之前，请遵守：
1. 只改我指定的地方，其他一律不动，不要顺手优化、不要改格式
2. 输出完整文件，不要给片段
3. 单独列出：改了哪几行、每行改了什么、为什么
4. 如果改动可能影响其他功能，必须提前警告我
5. 涉及删除数据的操作，先给我一条"只查不改"的版本让我试跑

【C. 复盘器——修完必问的一句】
我刚修好一个问题，本质是：[一句话概括类型]。
请帮我扫一遍项目里其他相关文件：
1. 还有哪些地方存在同样或变种的问题？逐个指出位置
2. 按危险程度排序
3. 给我一条简单的自查规则，以后怎么避免这类问题
先列清单，不要改代码。

🔖 速查卡：调试全套口诀

【分类】三类问题
  看不懂 → 问"这是什么"
  不对劲 → 问"哪里错了"
  太慢了 → 问"慢在哪里"

【提问】五件套：象 证 境 试 要
  象 = 期望什么 / 实际什么
  证 = 报错原文 + 完整文件
  境 = 系统 / 工具 / 触发条件
  试 = 我已经排除了什么
  要 = 要解释还是要代码

【流程】八步：现界差证，设修归盘
  复现 → 划界 → 差异 → 取证 → 假设 → 修复 → 回归 → 复盘

【底线】三条
  1. AI 只知道你给它的那一屏
  2. AI 不会说"我不知道"，它会编
  3. 按确认键的人是你，改前先备份

👉 下篇预告

第 77 篇：用 AI 重构烂代码——可读性直线上升。 调试篇结课，下一篇进入「重构与质量」：代码能跑却一团糟怎么办，重构不是重写，让 AI 安全重构的三步法。下篇见。

第75篇：调试实战——一个真实 Bug 的全流程还原

2026-10-02T10:00:00+08:00

报名表单显示”提交成功”，后台却只收到一半人。

前面四篇，我们把排错的各个招式拆开讲了：贴报错、找逻辑错、查性能、读老代码。这一篇不教新招式，而是从头到尾还原一个真实的 Bug——让你看清楚一个问题从”完全懵”到”彻底解决”，中间到底发生了什么。

因为很多人的问题不是不会某一招，而是——

手上有一堆锤子，但不知道先抡哪个。

咱们开始。

一、事故现场

背景：你用 AI 工具做了一个小站，功能很简单——一个活动报名表单。

用户填四个框：姓名、手机号、公司、备注。点提交，页面弹出”报名成功”，后台管理页能看到报名名单。上线三天一切正常，第四天活动负责人找过来，脸不太好看：

“有人跟我说他报名了，可名单里没有他。你查一下。”

你打开后台名单，数了数：87 条。

活动群里的人数：112 人。

你心里咯噔一下。

这就是最难受的一类 Bug：

页面没有报错
用户看到的是成功
数据确实丢了
而且不是全丢，是丢了一部分

新手这时候最常见的反应是两种，两种都是错的：

“是不是服务器不稳定？” —— 把锅甩给玄学，然后什么都不做。
直接打开代码，从提交那一段开始一行行看。 —— 大海捞针，看两小时也看不出来。

二、第一步：复现——把”听说”变成”我看到了”

排错的第一步永远不是改代码，而是：你自己让 Bug 再发生一次。 为什么？因为你亲眼看到之前，手上的信息全是二手的：用户说”我提交了”可能没点按钮，说”显示成功”可能记错了，你以为丢的 25 条也可能有人压根没报名。

没复现之前，你连”有没有 Bug”都不确定，改什么？

复现要抓三个要素：

要素	你要问清楚的
谁	什么设备、什么浏览器、什么账号
做了什么	具体点了什么，填了什么
看到了什么	屏幕上原话是什么，最好要截图

于是你去群里问了一句：”哪几位报名后没在名单里的，麻烦举个手，告诉我你填的内容。”

三个人回复了。你拿到三份填写内容。

你自己照着填了一遍第一个人的内容——提交成功，名单里出现了。

咦？没复现出来。

这时候千万别放弃。 换第二个人的内容，再填一遍——

页面显示”报名成功”，名单里没有。

复现了。

这一刻你赢了一半——手里有了两个宝贝：一个必然失败的例子、一个必然成功的例子。

三、第二步：差异法——偶发不是玄学

只有一部分人丢单，说明不是所有情况都出问题。

那必然存在一个条件变量：满足它就挂，不满足就好。

找它的方法叫差异法：

把”成功的那次”和”失败的那次”摆在一起，一栏一栏比，看差在哪。

你把两份填写内容并排贴出来：

字段	成功的那个	失败的那个
姓名	张伟	李娜
手机号	138xxxx	139xxxx
公司	甲科技	乙传媒
备注	无	一大段话，写了他为什么想参加，200 多字

看到没有——备注字段的长度差了几十倍，这就是最可疑的条件变量。

把这份对比丢给 AI，它能帮范围收得更窄。注意：别问”为什么丢数据”，要问”这两组差异可能触发什么问题”。

我的表单有偶发丢数据的问题。同样的代码，有的提交成功并入库，有的
显示成功但库里没有。

我找到了一组对照：
【成功的一次】姓名：张伟 / 手机：138xxxxxxxx / 公司：甲科技 / 备注：（空）
【失败的一次】姓名：李娜 / 手机：139xxxxxxxx / 公司：乙传媒 / 备注：（约240字的中文长文本）

请你：
1. 指出这两组数据最值得怀疑的差异点（按可疑程度排序）
2. 针对最可疑的那一点，列出 3~5 个可能的技术原因
3. 每个原因给我一个"我怎么快速验证它是不是真凶"的动作
4. 先不要改代码

我是新手，请用大白话解释。

AI 给了你一串可能：字段长度限制、编码问题、数据库字段类型太短、校验规则拦截、请求体大小限制……

注意：这些都还只是猜测。下一步是验证，不是相信。

四、第三步：划界——判断到底在哪一段断的

一个表单提交，数据要走四段路：

浏览器 → 网络请求 → 后端处理 → 数据库写入

你现在的任务不是找出哪行代码错了，而是先确定：数据是在哪一段路上掉的。

这一步叫四段划界法，做法很朴素——每一段路口都装个”摄像头”：

第 1 段：浏览器有没有把数据组装对？

按 F12 打开开发者工具（Windows 按 F12，Mac 按 Command+Option+I），切到 Network（网络） 标签，然后提交那份会失败的内容。

你会看到列表里多出一条请求。点进去看 Payload / 请求负载，那里显示的就是浏览器实际发出去的内容。

结果：四个字段都在，备注那 240 字也完整。

→ 第 1 段没问题，排除前端组装。

第 2 段：请求有没有到后端？

同一个面板里看这条请求的 Status（状态码）：

显示 200。

→ 通了，第 2 段没问题。

第 3 段：后端处理有没有出错？

这一段看不见，需要日志。翻到刚才那个时间点的后端输出——居然有一行红字，服务没挂还在跑。

→ 抓到了。问题在第 3 段。

第 4 段：数据库——不用查了，第 3 段就断了，压根没走到第 4 段。

这一步的价值：范围缩小了 90%。 你原本要在几百行代码里找，现在锁定在”后端保存那一小段”里找。

五、第四步：取证——把真凭实据交给 AI

现在你有日志了。这时候才轮到把东西贴给 AI。

记住前面第 71 篇讲过的铁律：报错贴原文，一个字都别转述。

我的表单提交接口出现问题：接口返回 200 和"成功"，但数据没有写进
数据库。后端日志里有一段异常，但服务没有崩溃。

【后端日志原文】
[把那一段红字完整粘贴，包含前后各几行]

【接口对应的完整代码文件】
[粘贴整个文件，不要只贴片段]

【触发条件】
备注字段填约 240 字时必现；备注为空时正常。

请你回答：
1. 这段日志说的是什么问题（用大白话）
2. 为什么出了异常，接口还会返回成功给前端
3. 定位到具体是哪一行引发的
4. 先解释，暂时不要给我改好的代码

我是新手，请一步步说清楚。

AI 的回答让你恍然大悟，真相有两层：

第一层：为什么数据会丢？

保存前有一段校验：备注不能超过 200 字，超了就抛异常——李娜写了 240 字，被拦下。

第二层（更关键）：为什么页面还显示成功？

代码里有一段”捕获异常但什么也不做“的写法——出错了，它把错误吞掉，然后继续往下走，最后照常返回了”成功”。

用大白话说就是：

快递员把包裹弄丢了，但还是给你发了”已签收”的短信。

这就是假成功——页面上的”成功”，只代表”程序跑完了”，不代表”事情办成了”。

六、第五步：修——只改一处，别顺手重写

到这一步，很多人会犯一个错：让 AI “帮我把这个文件优化一下”。

千万别。 你现在只搞明白了一个问题，一次只解决一个。

而且这次的修法要分两层，因为真凶其实有两个：

表面凶手：备注超 200 字被拦
幕后黑手：异常被吞掉，导致失败伪装成成功

只修表面凶手（把 200 放宽到 1000）是治标——下次换个别的原因失败，你照样收到”成功”、照样丢单。

两个都要修：

现在我明白问题了，请帮我修，但请严格遵守：

1. 只修下面这两处，其他代码一律不要动，不要顺手优化、不要改格式
   （a）备注字段的长度上限，从 200 放宽到 1000
   （b）不要再静默吞掉异常：出错时必须记录日志，并且给前端返回失败，
       不能再返回成功

2. 返回给前端的失败提示要写给普通用户看，比如"备注最多 1000 字"，
   不要把技术错误原文丢给用户

3. 输出改动后的完整文件，不要给片段

4. 在文件外面单独告诉我：你一共改了哪几行、每行改了什么、
   为什么这么改

我是新手，请顺便说明我改完之后应该怎么验证。

这段提示词里有四个”新手保命条款”：

只改这两处，其他别动 —— 防止 AI 顺手重写导致新 Bug
输出完整文件 —— 防止你不知道片段该贴在哪
列出改了哪几行 —— 让你看得懂它动了什么
告诉我怎么验证 —— 修完不是终点

七、第六步：回归验证——三条必测

改完立刻测，而且必须测三条，一条都不能少：

测什么	期望结果	为什么必测
原来失败的那条（240 字备注）	提交成功，名单里能查到	证明问题真的修好了
原来成功的那条（备注为空）	依然成功	证明没有修坏别的
一条极端的（备注 1200 字）	提交失败，页面提示”备注最多 1000 字”	证明失败时会明确报错，不再假成功

第三条最重要。

因为它验证的不是这一个 Bug，而是”以后再出问题，你能不能第一时间发现”。

三条全过，才算修完。

然后你回群里补一句：”报过名但不在名单里的朋友，麻烦重新提交一次。”

——87 条变成了 110 条。

八、第七步：复盘——让这次经验值钱

Bug 修完，还剩最后一件事，也是最多人跳过的一件事：

问一句：同样的坑，项目里还有几个？

我刚修好一个问题：某处校验失败抛出异常，但异常被静默吞掉，
导致接口仍然返回成功，数据其实没保存。

【项目里其他几个接口的代码】
[粘贴其他接口文件]

请你帮我检查：
1. 还有哪些地方存在"吞掉异常后照常返回成功"的写法？逐个指出行号
2. 还有哪些地方"前端提示成功"和"实际结果"可能不一致？
3. 按危险程度排序，告诉我哪个最该先改
4. 给我一条简单的自查规则，以后写代码时怎么避免这类问题

先列清单，不要改代码。

AI 一查——另外两个接口也有同样的写法。

你顺手把它们也修了。

这就是复盘的价值：修一个 Bug 只值一次，找到这类 Bug 的规律值一辈子。

九、把这次流程压成八个字

回头看整个过程，其实是固定的八步：

复现 → 划界 → 差异 → 取证 → 假设 → 修复 → 回归 → 复盘

口诀记法：现界差证，设修归盘。

步骤	一句话	最容易被跳过的
复现	自己看到才算数	⭐ 最常被跳过
划界	先定位在哪一段断
差异	成功和失败差在哪
取证	拿日志，别拿猜想
假设	让 AI 列清单，你来验
修复	只改一处，完整文件
回归	三条必测	⭐ 第二常被跳过
复盘	同类问题还有几个	⭐ 最常被跳过

新手和熟手的差距，八成不在第六步”修复”，而在第一步和最后两步。

十、这一篇最该记住的三句话

第一句：没复现之前，你查的是传说，不是 Bug。

第二句：先划界，再看代码。范围没缩小之前看代码，等于大海捞针。

第三句：页面上的”成功”，只代表程序跑完了，不代表事情办成了。

最后再补一条心态上的：

Bug 不丢人，查不出来也不丢人。丢人的是每次都从零开始瞎撞。

你今天走完这八步，下次再遇到”数据莫名丢了”“偶尔才出错”这类问题，会发现流程一模一样。

📦 提示词模板盒子

模板一：对照找条件变量（偶发问题必用）

我遇到一个偶发问题：同样的操作，有时候正常，有时候不正常。

【现象】
正常时：[描述]
不正常时：[描述]

【我找到的一组对照】
成功的一次输入：[逐字段列出]
失败的一次输入：[逐字段列出]

请你：
1. 按可疑程度排序，指出这两组数据最值得怀疑的差异点
2. 针对最可疑的那一点，列出 3~5 个可能的技术原因
3. 每个原因给我一个"怎么快速验证它是不是真凶"的动作
4. 先不要改代码

我是新手，请用大白话解释。

模板二：四段划界（判断在哪一段断的）

我的功能出问题了：[描述现象]。

我想先确定数据是在哪一段丢的，一共四段：
浏览器 → 网络请求 → 后端处理 → 数据库

请你针对我这个功能，给我一份逐段排查指引：
1. 每一段我具体该看哪里（说清楚点哪个菜单、看哪个字段）
2. 每一段"正常"应该长什么样，"异常"长什么样
3. 按从易到难排序，我先查哪一段最省事

我完全没用过开发者工具，请把点击步骤写细一点。

模板三：取证提问（拿到日志后）

我的功能出现问题：[一句话现象]。

【日志/报错原文】
[完整粘贴，前后各多贴几行，不要转述、不要截断]

【相关的完整代码文件】
[粘贴整个文件]

【触发条件】
[什么情况下必现，什么情况下正常]

请你回答：
1. 这段日志说的是什么问题（大白话）
2. 为什么会出现"表面成功、实际失败"（如适用）
3. 定位到具体是哪一行引发的
4. 先解释，暂时不要给我改好的代码

我是新手，请一步步说清楚。

▸ 外科手术式修复：让 AI 只改指定几处、输出完整文件、列出改了哪几行；并要求出错时记录日志、向用户返回失败而非静默吞掉（原模板四）。 ▸ 回归验证清单：改完让 AI 列三类验证——原来失败的、原来正常的、极端的，每条写清操作与期望（原模板五）。 ▸ 复盘扫雷：修好后让 AI 在其它文件里找同类问题、按危险排序，并给一条自查规则（原模板六）。

🔖 速查卡：排错八步

复现 —— 自己看到才算数，拿到"必失败"和"必成功"两个例子
划界 —— 浏览器 / 网络 / 后端 / 数据库，先确定断在哪一段
差异 —— 成功与失败逐字段对比，找出那个条件变量
取证 —— 贴日志原文 + 完整文件，不转述、不截断
假设 —— 让 AI 列可能性清单，你负责逐个验证
修复 —— 只改一处，输出完整文件，要它列出改了哪几行
回归 —— 三条必测：修好的 / 原本好的 / 极端的
复盘 —— 同类问题还有几个，顺手一起扫掉

👉 下篇预告

第 76 篇《调试类小结——把排错思路彻底沉淀下来》。 下一篇把 71~75 这五篇收口，交给你三样东西：一张排错总决策树、一套万能排错提示词母版、一份新手八大误区清单。看完那篇，你手上就有一套完整的”AI 排错工具箱”了。 我们下篇见。

第74篇：用 AI 理解遗留老代码——接手祖传项目不慌

2026-10-01T10:00:00+08:00

代码不是你写的，写的人已经离职了。

前面几篇讲的都是”你自己写的代码”。

这一篇讲一个更让人头皮发麻的场景：

老板拍拍你肩膀：”这个项目以后你负责。”

你打开文件夹，看到：几十个文件夹，几千行代码，没有文档，注释寥寥无几，最后一次提交是两年前。

写这段代码的人，已经不在公司了。

你随手点开一个文件，看了三分钟，脑子里只有三个问题：

它到底从哪儿开始跑的？
这段是干嘛的？
我改这一行，会不会炸掉别的地方？

这就是俗称的”祖传代码“。

好消息是：这恰恰是 AI 最能帮上忙的场景之一。

坏消息是：如果你用错方法，AI 会把你带进更深的坑。

这一篇，把接手老项目的完整打法讲清楚。

一、先纠正一个致命误区

新手接手老项目，第一反应通常是：

从第一个文件开始，一个一个读过去。

这是最慢、也最容易放弃的方式。

几千行代码，你按文件顺序读，读到第三个文件就晕了——因为你不知道这些东西之间是什么关系。

还有一种更常见的错误：

把整个项目一股脑丢给 AI，问一句”这项目是干嘛的？”

AI 会给你一段听起来很专业、但基本没用的概述。 而且大部分工具根本装不下你整个项目。

这里有一条必须刻在脑子里的原则：

AI 只知道你给它的那一屏。

它看不到你没贴的文件，看不到数据库里的数据，看不到服务器上的配置。

你贴什么，它答什么。你贴得没头没尾，它就编得有头有尾。

所以理解老项目，不是”把活丢给 AI”，而是你带路，AI 解说。

二、剥洋葱五层法：接手老项目的正确顺序

记住这个顺序：入口 → 地图 → 主线 → 数据 → 细节。

每一层没搞清楚之前，不要进下一层。

第一层：找入口——程序从哪儿开始跑

这是唯一正确的起点。

任何项目都有一个”第一行被执行的代码”。可能叫 main、app、index、server，也可能藏在某个启动脚本里。

找不到入口，后面全是瞎逛。

如果你自己找不到，就把项目根目录的文件列表贴给 AI，让它告诉你入口最可能是哪个。

文件名清单怎么拿？在项目文件夹里截个图、或者把文件名手动列一列都行。这一步不需要贴任何代码。

第二层：画地图——项目分成哪几大块

拿到入口后，别急着往下钻。

先搞清楚这个项目一共分几大块，每块干什么。

通常一个项目会有这么几类文件夹，名字千奇百怪，但角色就这几种：

页面 / 界面
业务逻辑
数据存取
工具函数
配置

把目录结构贴给 AI，让它帮你给每个文件夹标注”这块大概是干什么的”。

这一步的产出，应该是一张你自己能画出来的草图。画不出来，说明还没懂。

第三层：走主线——追一个完整功能，从头走到尾

这是最关键的一层。

不要试图理解所有功能。挑一个最核心的功能，把它从头到尾走一遍。

比如”用户下单”，从头到尾走一遍是这样的：

点击”提交订单”按钮
请求发到哪（哪个接口）
哪个函数接住了这个请求
它又调用了谁（下游逻辑）
数据最终存到哪（哪张表）
给用户返回了什么

走通一条主线，你对这个项目的理解就超过 60% 了。

因为其他功能，大概率是同一套路的复制。

第四层：看数据——数据从哪来，到哪去

老项目最容易搞错的地方，往往不在逻辑，而在数据。

搞清楚三件事：

数据存在哪（哪几张表 / 哪些文件）
谁在写（哪个功能在往里写）
谁在读（谁在依赖这份数据）

特别留意那些”被很多地方读、但只有一个地方写”的数据——那通常是整个项目的命脉，改它风险最高。

第五层：抠细节——到这一步才开始逐行读

前四层都清楚了，你再回头看具体某个函数的实现，会发现读起来轻松得多。

顺序反过来，就是灾难。

三、让 AI 解说的正确姿势：三个要求

贴代码给 AI 让它解释，大部分人只会说一句”这段代码是干嘛的？”

得到的回答通常是逐行翻译：

“这一行定义了一个变量，这一行是一个循环，循环里判断了……”

你自己都能看出来，这不叫理解。

要让 AI 说人话，加上这三个要求：

要求一：先说”它在整体里干什么”，再说”它怎么做的”

先要一句话的职责概括，再要实现细节。顺序不能反。

要求二：用大白话打比方，不要用术语堆砌

明确告诉它：”假设我完全不懂这个技术栈，请用生活化的比方解释。”

要求三：主动指出可疑和过时的地方

老代码里一定有坑。让 AI 顺便标出：哪里写法过时、哪里可能有隐患、哪里的命名和实际功能对不上。

第三点尤其值钱。因为它会引出下面这个话题——

四、老代码四大坑：AI 也会被骗

AI 读老代码时会犯的错，和人一模一样：它相信代码表面的样子。

这四个坑，你得心里有数：

坑一：名字骗人

一个函数叫 checkUser，你以为它只是”检查用户”，结果它顺手改了数据库、发了短信、还写了日志。

老项目里，函数名和实际功能对不上，是常态而不是意外。

AI 看到这个名字，也会顺着名字理解。所以永远别只看名字，要看它实际做了什么。

坑二：注释过期

注释写着”此处返回全部订单”，代码早就改成”只返回未支付订单”了。

注释是两年前的，代码是上个月的。

代码不会骗人，注释会。 两者冲突时，永远信代码。

坑三：同一段逻辑抄了好几份

老项目里经常有三四个长得几乎一样的函数，只有细微差别。

你改了其中一个，以为修好了。结果线上跑的是另一个。

所以改之前，一定要搜一下：这段逻辑是不是还有别的副本。

坑四：藏起来的调用

最阴险的一类。

你以为这个函数没人用了，准备删掉。结果它被好几处地方用着：

一个定时任务在调用它
一个配置文件里写着它的名字
某个几乎没人访问的老页面也在用

这类调用，AI 完全看不到——因为你没贴给它。

删之前，先全项目搜一遍这个名字。搜索框，是老项目里最重要的工具。

五、动手改之前，必做”三查”

理解只是第一步。真正的考验是：你要改它。

老项目改动的黄金法则是：

不懂全部，也能安全改动。

怎么做到？改之前，做完这三查。

查一：查引用——这东西被谁用着

要改的这个函数、这个变量、这张表，全项目搜一遍它的名字，看看有多少处在用。

只有 1 处用 → 风险低，可以放心改
有 10 处用 → 要小心了，你改的是公共部件
搜出来一堆，还有配置文件里的 → 先别动，去问人

这一步是纯手工的，AI 帮不了你，因为它看不到你没贴的文件。但它是最重要的一步。

查二：查影响——改了会波及什么

把这段代码 + 所有调用它的地方，一起贴给 AI，问它：

“如果我把这里改成 XX，会有哪些地方受影响？有没有我没注意到的连带后果？”

注意：必须把调用方也贴上。只贴被改的那段，AI 只能猜。

查三：查退路——出事了怎么退回去

改之前，把原始代码整段复制一份存起来，或者用版本管理工具提交一次。

老项目最怕的不是改错，是改错了还回不去。

六、边读边攒：给项目补一份说明书

这是最容易被跳过、但回报最高的一件事。

你花了两天搞懂的东西，三周后会忘掉一大半。

所以从第一天开始，就建一个文件，边读边记。不用写得多正式，记这五样就够：

入口在哪个文件
各文件夹分别是干什么的（一句话一个）
主流程走一遍是怎样的（用箭头连起来那种）
数据存在哪几个地方
踩过的坑 / 反直觉的地方（这条最值钱）

第 5 条尤其重要。 那些”看着像 A，其实是 B”的地方，正是你未来最容易再次踩进去的。

下次再问 AI 任何关于这个项目的问题，都可以把这份笔记贴在前面当背景——AI 立刻从”外人”，变成”看过说明书的同事”。

回答质量的差别，大到你会后悔没早点开始记。

提示词模板盒子

以下模板可直接复制使用，方括号内替换成你自己的内容。

模板一：找入口（第一步，不贴代码）

我接手了一个别人写的老项目，现在完全不知道从哪儿开始看。

下面是这个项目根目录的文件和文件夹清单：
[粘贴文件名列表]

请你告诉我：
1. 程序的入口最可能是哪个文件？为什么？给出第一、第二可能
2. 这几个文件夹分别大概承担什么角色（一句话一个）
3. 我应该按什么顺序打开这些文件，才最快搞懂这个项目
4. 有哪些文件是我暂时可以完全不用管的

我是新手，请用大白话说，不要用架构术语。

模板二：项目地图（第二层）

这是我接手项目的目录结构：
[粘贴目录树]

请帮我做一张"项目地图"：
1. 把这些文件夹归类成几大块（例如：界面层、业务层、数据层、工具、配置）
2. 每一块用一句话说明它负责什么
3. 用文字画出这几大块之间的调用关系（谁调谁，用箭头表示）
4. 指出哪一块是这个项目的"核心"，也就是我必须先搞懂的

请输出成我能直接抄进笔记的格式。

▸ 追一条主线：把相关代码段按序贴给 AI，让它讲清执行过程、指出断层、用箭头图总结（原模板四）。 ▸ 生成项目笔记：让 AI 整理入门笔记（入口/目录/主流程/数据/坑点），直接存文件（原模板六）。

模板三：解说一段陌生代码（最常用）

下面这段代码是我接手的老项目里的，我完全不知道它在干什么。

请按以下顺序回答，不要打乱：
1. 【一句话职责】这段代码在整个系统里负责什么（一句话，说人话）
2. 【打个比方】用一个生活中的例子来类比它做的事
3. 【分段说明】把它切成几个逻辑段落，每段说明在干什么（不要逐行翻译）
4. 【输入输出】它需要什么、产出什么
5. 【依赖】它调用了哪些外部东西（其他函数、数据库、接口、配置）
6. 【可疑之处】哪里写法过时、哪里可能有隐患、哪里的命名和实际功能对不上

前提：假设我完全不熟悉这个技术栈，请避免术语堆砌。

代码如下：
[粘贴代码]

▸ 改动前影响评估：把要改代码+调用方贴给 AI，评估影响与风险，并要求它指明风险（原模板五）。

速查卡：接手老项目五句口诀

剥洋葱   —— 入口 → 地图 → 主线 → 数据 → 细节，顺序不能乱
走主线   —— 追通一个功能，理解度立刻过半
信代码   —— 名字会骗人，注释会过期，只有代码不说谎
先三查   —— 查引用、查影响、查退路，缺一不改
边读边记 —— 笔记贴给 AI，它就从外人变成同事

最后

这一篇的核心，压缩成一句话：

接手老项目的本事，不是”全都读懂”，而是”没全懂也能安全动手”。

没有人能完全读懂一个几千行的祖传项目，老手也不能。

老手和新手的区别只在于：老手知道哪些必须搞清楚，哪些可以先放着。

入口必须清楚，主线必须走通，改动前必须三查。

其余的，用到再说。

下篇预告

第75篇《调试实战——一个真实 Bug 全流程》。 前面四篇拆开讲招式，下一篇串起来打一遍：还原一个真实场景——用户反馈”报表少了几条数据”，没报错、数据大、代码是别人写的，全程记录每一步贴了什么、信哪条。包括走错的两步弯路。看十篇方法论，不如走一遍。 我们下篇见。

第73篇：用 AI 做性能瓶颈分析——慢在哪，它告诉你

2026-09-30T10:00:00+08:00

能跑，结果也对，就是慢得让人想砸键盘。

前两篇讲”错”，这一篇讲”慢”。

这两件事完全不是一回事。

Bug 是有答案的：要么报错了，要么结果不对，改完一验证，对了就是对了。

慢没有答案。

页面点一下转圈五秒，导出一个表要等半分钟，数据一多就整个卡死——它不报错，它也没算错，它只是让你等。

更难受的是：你连”多快才算正常”都说不上来。

于是很多新手的操作是这样的：

觉得这段循环可能有点慢 → 改了 → 好像还是那么慢 → 又觉得那个查询有问题 → 再改 → 更慢了

改了一下午，快了 0.2 秒，还顺手改出两个新 bug。

这一篇我们把打法讲清楚。核心就一句：

先测量，再优化。凭感觉调性能，八成越调越慢。

一、新手最大的坑：跳过测量，直接动手

先说一个真实到扎心的规律：

你觉得慢的那段代码，十有八九不是真正慢的那段。

人对”哪里慢”的直觉极其不准。看起来很复杂的一段计算，可能只花了 3 毫秒；看起来平平无奇的一行取数据，可能花了 4 秒。

而 AI 呢？你不给它数据，它比你更爱猜。

你把 200 行代码丢过去说”这段有点慢，帮我优化”，AI 一定会给你一堆看起来很专业的建议：

“可以考虑使用缓存”
“建议改成异步处理”
“这里可以用更高效的数据结构”

每一条听起来都对。每一条都可能跟你的实际瓶颈毫无关系。

因为 AI 在做的事，和你一样——猜。

所以性能优化的第一步，从来不是”问 AI 怎么优化”，而是：

先让 AI 教你怎么量，量出数字，再拿数字问它。

二、不用专业工具，三招量出耗时

一提”性能分析”，很多教程立刻上性能剖析器、火焰图、监控平台。

对小白来说那太远了。先用最土的三招就够，土归土，管用。

第 1 招：整体计时——先确认到底有多慢

在这段功能开始前和结束后各记一个时间，相减打印出来。

这一步的意义是：把”感觉慢”变成”3.8 秒”。

数字一出来，讨论才有基础。

第 2 招：分段计时——把大块切成小块

这是最关键的一招。

把整个流程拆成 3~5 段（比如：取数据 / 处理数据 / 生成结果 / 返回），每段都记一次耗时。

跑一次，你会看到类似这样的结果：

阶段	耗时
取数据	3.6 秒
处理数据	0.1 秒
生成结果	0.08 秒
返回	0.02 秒

答案瞬间就有了。

你之前盯着看了半天的”处理数据”那段复杂逻辑，只占 0.1 秒。真正的问题在取数据。

这一张表，比你问 AI 十遍都有用。

第 3 招：改数据量——看它是不是”越多越慢”

同一个功能，分别用 10 条、100 条、1000 条数据各跑一次，记下耗时。

10 条 0.1 秒，100 条 1 秒，1000 条 10 秒 → 和数据量成正比，属于正常，但有优化空间
10 条 0.1 秒，100 条 10 秒，1000 条直接卡死 → 危险信号，说明数据一多耗时暴涨，多半是”循环里套查询”或”循环里套循环”
10 条 3 秒，1000 条也 3 秒 → 慢的不是数据处理，是某个固定开销（比如某次网络请求、某个初始化）

这三种情况的解法完全不同。分不清就乱改，必然白干。

三、性能四件套：作、量、时、标

有了数字，才轮到 AI 上场。

问性能问题，和问 bug 一样，要给四样东西。这一套记住：作、量、时、标。

1）作——是哪个操作慢

不要说”我系统慢”。要说”点击『导出报表』按钮之后慢”。

具体到一个用户动作。

2）量——数据规模多大

“表里有 5 万条记录，这次导出筛出 2000 条。”

数据量是性能问题的第一上下文。 不给数据量，AI 给的建议全是空话。

3）时——实测耗时，最好是分段的

把你第 2 招量出来的那张表直接贴给它。

4）标——你的目标是多快

“希望 3 秒内出来” 和 “希望 100 毫秒内出来”，是两个量级的方案。

前者可能加个索引就行，后者可能要上缓存、改架构。不说目标，AI 容易给你一个杀鸡用牛刀的方案。

把这四样凑齐，AI 的回答质量会立刻从”正确的废话”变成”能落地的建议”。

四、新手性能问题的四大元凶

看了大量新手代码之后，你会发现慢的原因高度集中。记住这四个，覆盖八成情况。

元凶一：在循环里查数据库（头号杀手）

这是最常见、也是最致命的一个。

代码逻辑通常长这样：

先查出 100 个订单 → 然后对每个订单，再去查一次它的客户信息

看起来很自然对吧？但实际发生的事情是：

1 次查询 + 100 次查询 = 101 次数据库往返。

每次往返哪怕只要 30 毫秒，101 次就是 3 秒多。

这就是那个反直觉的事实：真正拖慢你的不是代码，是它问了数据库一百遍。

正确做法是一次性把 100 个客户全查出来，再在内存里对应上。101 次变 2 次，3 秒变 60 毫秒。

你不需要会写这个优化，你只需要知道去问 AI：「我这段是不是在循环里查数据库？能不能改成批量查询？」

元凶二：一次性把全部数据拿出来

“查询所有订单” —— 表里有 50 万条，你全拿了出来，然后在代码里筛出 20 条显示。

该让数据库干的活，你搬到内存里干了。

三个关键词：

加筛选条件
加分页
只取需要的字段

元凶三：重复计算同一个东西

同一个结果，在一次流程里算了 5 遍；同一份配置，每次调用都重新读一次文件。

算过的东西存下来复用，这就是缓存最朴素的含义。

元凶四：前端一次性渲染太多东西

一次往页面上塞 5000 行表格、几十张没压缩的大图，浏览器直接卡住。

解法：

分页
懒加载
图片压缩

五、让 AI 改的时候，守住三条线

拿到 AI 的优化建议后，别一口气全改了。 性能优化最容易的翻车方式，就是”快了，但结果不对了”。

三条线，每次都守住：

第一条：一次只改一处，改完立刻测。

同时改三处，快了你不知道是哪处起的作用，慢了你也不知道该退哪一步。

第二条：改之前留副本。

原来的代码整段复制到一个备份文件里。优化改坏的概率，比你想的高。

第三条：改完必须核对结果一致。

这是最容易被忽略、后果最严重的一条。

优化的前提是”结果不变，只是更快”。而很多优化写法（尤其是批量查询、加缓存）极容易悄悄改变结果：少了几条数据、顺序变了、拿到的是旧数据。

所以每次优化后，必须拿同一份输入跑一遍，逐条对比新旧结果。

快了但结果错了，比慢着但对着糟糕得多。

六、一个完整的实战节奏

把上面的东西串起来，一次完整的性能优化长这样：

描述现象 —— 点导出按钮，等 8 秒
整体计时 —— 确认是 7.9 秒，不是错觉
分段计时 —— 取数据 7.5 秒，其余加起来 0.4 秒
变数据量再测 —— 100 条 0.8 秒，1000 条 7.5 秒，成正比且偏慢
凑齐四件套问 AI —— 作、量、时、标一次说清
AI 判断 —— 循环里逐条查客户信息，典型 N+1
只改这一处 —— 改成批量查询，留好备份
复测 —— 7.9 秒 → 0.6 秒
对结果 —— 导出条数、内容、顺序与优化前完全一致 ✔

九步走完，比瞎改一下午强一百倍。

注意第 9 步不能省。没对过结果的优化，不算完成。

提示词模板盒子

以下模板可直接复制使用，把方括号里的内容替换成你自己的情况。

模板一：让 AI 教你加计时（第一步永远是这个）

我要给下面这段代码做性能分析，但我不知道慢在哪。

请你帮我做两件事：
1. 把这段流程拆成 3~5 个阶段，在每个阶段前后加上计时代码，
   运行后能打印出每段各花了多少毫秒。
2. 计时代码请加得明显一点（加注释标出来），方便我之后删掉。

要求：
- 只加计时，不要改动任何原有逻辑
- 给我完整文件，不要片段
- 最后告诉我：运行后我应该重点关注哪几个数字

代码如下：
[粘贴你的代码]

▸ 数据量增长测试解读：把 10/100/1000 条各跑一次的耗时贴给 AI，让它判断是”成正比 / 暴涨 / 几乎不变”，并指出下一步先查哪段（原模板四）。

模板二：性能四件套——正式提问（核心模板）

我有一个性能问题，信息如下：

【作】慢的操作：[例如：点击"导出订单报表"按钮]
【量】数据规模：[例如：订单表 5 万条，本次筛出 2000 条]
【时】实测耗时（分段）：
  - 取数据：3.6 秒
  - 处理数据：0.1 秒
  - 生成文件：0.08 秒
  - 总计：3.8 秒
【标】目标：希望总耗时降到 1 秒以内

相关代码如下：
[粘贴最慢那一段的代码]

请你：
1. 先判断瓶颈最可能出在哪一行或哪几行，说明理由
2. 给出优化方案，按"见效大小"排序，并标出每个方案的风险
3. 先只给我改动最小、见效最大的那一个方案的完整代码
4. 告诉我改完之后，我应该怎么验证"结果没变，只是变快了"

不要一次给我多个方案的代码，我要一个一个改。

▸ 优化后安全核对：改完让 AI 列一份可勾选清单——对比哪几项确认”结果没变”，以及这种优化最易在什么边界悄悄出错（原模板五）。

模板三：排查”循环里查数据库”（头号元凶专用）

请检查下面这段代码，是否存在"在循环里反复查询数据库"的问题
（也就是常说的 N+1 查询）。

请按以下格式回答：
1. 有没有：是 / 否
2. 如果有，指出是哪一个循环、循环里的哪一行在查询
3. 按当前数据量估算：总共会产生多少次数据库查询
4. 改成批量查询后，查询次数会变成多少
5. 给出改造后的完整代码

特别注意：改造后必须保证返回的数据条数、内容、顺序
与原来完全一致。如果有可能不一致，请提前告诉我。

代码如下：
[粘贴你的代码]

速查卡：性能优化五句口诀

先量再改  —— 没有数字，不要动代码
分段计时  —— 一张耗时表，胜过十次猜
四件套    —— 作（什么操作）、量（多少数据）、时（多久）、标（目标）
一次一处  —— 改完立刻测，别批量改
必对结果  —— 快了但错了，比慢着更糟

最后

这一篇的核心，压缩成一句话：

性能问题里，”数字”就是你的报错。

Bug 有红字告诉你出事了，性能没有。那个数字，就是你自己造出来的红字。

没有它，你和 AI 都在猜；有了它，路径只剩一条。

先测量，再优化。 记住这五个字，你已经甩开一半的人了。

下篇预告

第74篇《用 AI 理解遗留老代码——接手祖传项目不慌》。 代码不是你写的、写的人离职了、没文档没注释几千行起步。下一篇讲：按什么顺序读（九成人一上来就开错文件）、怎么让 AI 画”项目地图”、以及动手前先查清”这一行被谁用着”。不懂全部，也能安全改动。 我们下篇见。

第72篇：让 AI 定位逻辑错误——没有红字，也能查出来

2026-09-29T10:00:00+08:00

一个错都不报，结果就是不对。

上一篇讲的是”有红字”的 bug。

那一类其实是幸运的——程序已经明确告诉你出事了，还顺手指了地方。

这一篇讲的是另一类，也是真正吃时间的那一类：

程序跑得好好的，没有任何报错。 但结果就是不对。

统计出来的总数少了三条。排序排完，第一名跑到了中间。明明该显示 10 条，页面上只有 7 条。金额算出来永远差那么几分钱。

没有红字，没有提示，你连从哪一行看起都不知道。

很多新手到这一步就卡死了，反复把整段代码丢给 AI，问一句：”帮我看看哪里有问题？”

然后 AI 开始一本正经地瞎猜。

这一篇，我们就把这类问题的正确打法讲透。

一、先理解：为什么 AI 对逻辑错更容易翻车

上一篇里，AI 表现得像个老手。这一篇，它经常表现得像个新手。

原因很简单：信息量差太多了。

	报错型 bug	逻辑型 bug
有没有明确信号	有，报错类型 + 消息	没有
出错位置	给了，精确到行	不知道
出错时的值	常常直接给出	完全没有
AI 拿到什么	一份证词	一段”看起来都对”的代码

关键在最后一行。

逻辑错的代码，从语法上看每一行都是对的。

你把它丢给 AI 说”这里有 bug”，AI 只能做一件事：从常见错误清单里挑几个像的，说给你听。

要让 AI 靠谱，你必须把它缺的那部分信息补上。

二、逻辑错四件套：入、期、实、码

上一篇的报错四件套是「错、码、做、境」。

这一篇换一套：「入、期、实、码」。

件	内容	一句话
入	输入数据	你喂进去的具体内容
期	期望输出	你认为应该得到什么
实	实际输出	它实际给了你什么
码	相关代码	处理这段数据的代码

核心逻辑：既然没有报错，那唯一的线索就是「期望和实际的差异」。

这个差异越具体，AI 越能顺着差异倒推。

「入」和「实」必须是具体的值，不能是描述

这是最多人做错的地方。

❌ “我传了一些订单数据进去，结果统计不对。”

这句话对 AI 来说约等于什么都没说。

✅ “我传了 5 条订单，金额分别是 12.5、8.0、30.25、0、-5。期望总额是 45.75，实际得到 50.75。”

看到区别了吗？

第二种写法里，那个 -5 和 0，一眼就能让 AI 想到”是不是负数/零值被过滤掉了”。

划重点：给样例胜过描述十句——在调试这里比写代码时更重要。

「期」要说清楚”为什么应该是这样”

有时候不是代码错了，是你以为的规则和实际规则不一样。

所以除了写期望值，最好补一句依据：

“期望是 45.75，因为按业务规则，负数订单（退款）也要算进总额。”

这一句能帮 AI 判断：到底是代码写错了，还是需求本来就有歧义。

三、最该学的一招：二分法定位

如果只让我教新手一个调试技巧，我会教这个。

它不需要任何工具，不需要懂调试器，笨但极其有效。

思路

假设你的处理流程有 10 步，结果在第 10 步不对。

问题在哪一步？你不知道。

那就先看第 5 步。

如果第 5 步的结果已经不对了 → 问题在前 5 步，后 5 步不用看了
如果第 5 步的结果是对的 → 问题在后 5 步

一次操作，排查范围砍掉一半。

再来一次，砍成四分之一。四五轮之内，你能把范围缩到具体某一行。

怎么”看”中间结果？

最简单的办法：打印出来。 这事儿不用你自己写，直接让 AI 帮你加：

“请在这段代码的每个关键步骤后面加一行打印，把当时的变量值和步骤名打出来，给我完整代码。我运行后会把打印结果贴给你。”

然后你运行，把打印出来的那一坨复制回去。

这个来回，就是新手能做的最高效的调试动作。

为什么这招对 AI 特别有效

因为它把”猜”变成了”看”。

AI 拿到中间打印结果之后，它面对的就不再是一段”看起来都对的代码”，而是一组带具体值的现场数据。

这时候它就从”猜谜”切换回了”破案”模式。

四、别问”哪里错了”，要让 AI”逐行推演”

这是个提问方式上的大坑。

❌ “这段代码哪里有问题？”

这句话在暗示 AI”这里有问题”。

AI 为了满足你，会努力找一个问题出来——哪怕代码其实是对的。

换个问法，效果完全不同：

✅ “请假设你是计算机，逐行执行这段代码。输入是【具体数据】。每执行一行，写出这一行执行后所有关键变量的值。最后告诉我程序输出是什么。 先不要看我的期望值，也不要试图找 bug，就老老实实推演。”

这叫「代码走读」，或者说”手工模拟执行”。

它的妙处在于：你没有让 AI 找 bug，你让它算一遍。

算完之后，你再对比：

“你推演出的结果是 50.75，我期望的是 45.75。现在请指出：是哪一步导致了这个差异？”

这时候 AI 给的答案，准确率会高一大截。

因为它是从自己的推演里找矛盾，而不是凭印象猜。

五、常见逻辑错清单：让 AI 照着查一遍

有一些逻辑错误特别高频，几乎每个新手都会踩。

你可以直接让 AI 拿这张清单去对照检查。

① 差一位（边界问题）

循环少跑一次或多跑一次；取列表最后一个元素时算错位置。

典型表现：结果永远少一条 / 多一条。

② 小数比较

0.1 + 0.2 在计算机里不等于 0.3。这不是 bug，是浮点数的天性。

典型表现：金额差几分钱 / 判断相等永远不成立。

③ 复制还是引用

你以为复制了一份数据去改，其实改的是原来那份。

典型表现：改了 A，B 也跟着变了。

④ 异步顺序

网络请求还没回来，你就去用它的结果了。

典型表现：第一次是空的，刷新一下就好了。

⑤ 条件判断顺序

多个 if 条件的顺序写反了，某些数据被前面的条件先截走了。

典型表现：大部分对，少数特定数据不对。

⑥ 类型隐式转换

字符串 "10" 和数字 10 在有些语言里能直接比较，结果可能出乎意料。

典型表现：排序结果诡异（比如 10 排在 9 前面）。

⑦ 空值与零值被一起过滤

代码里写了”如果没有值就跳过”，结果把真实的 0 也当成”没有值”跳过了。

典型表现：总数偏少，且缺的都是 0 或空字符串。

⑧ 时区与编码

时间差 8 小时；中文变成乱码。

典型表现：日期对不上 / 中文显示成问号或方块。

用法很简单：

“请按以下 8 类常见逻辑错误，逐条检查这段代码，明确说明每一条’有 / 没有 / 不适用’，不要跳过。”

六、终极验证：让 AI 写测试用例来”抓”这个 bug

修完之后，怎么确认真的好了？

跑一次看起来正常，不算数。

更靠谱的做法：让 AI 写一组测试数据，专门去踩容易出问题的地方。

“请针对这个函数，设计 8 组测试输入，要求覆盖：正常情况、空数据、只有一条、最大值、负数、零、重复数据、以及格式不规范的数据。每组给出输入和正确答案。”

然后你把这 8 组挨个跑一遍。

这一步经常能顺手抓出另外两三个你还不知道的 bug。

而且这组数据可以留下来——以后每次改这段代码，重跑一遍就知道有没有改坏。

七、把整个流程串起来

新手遇到”不报错但结果不对”，按这个顺序走：

步	动作	目的
①	凑齐入、期、实、码四件套	给足信息
②	先对八类高频错照一遍现象	碰运气，命中就省事
③	让 AI 加打印，运行，贴回结果	把”猜”变成”看”
④	按二分法缩小范围	定位到具体几行
⑤	让 AI 逐行推演（先别提期望值）	拿到中立判断
⑥	对比推演结果与期望，问差异出在哪一步	锁定根因
⑦	让 AI 写测试用例验证	确认真修好了

大部分逻辑 bug，走不到第五步就解决了。

提示词模板盒子

以下模板可直接复制使用，把【】里的内容换成你自己的。

模板 72-1：逻辑错四件套（万能主模板）

我的程序没有任何报错，但运行结果不对，需要你帮我定位。

【① 入 —— 输入数据】
（给出具体的值，不要用"一些数据"这种描述）

【② 期 —— 我期望的输出】
期望结果：
为什么应该是这样：（说明业务规则或计算依据）

【③ 实 —— 实际的输出】
实际结果：
差异在哪：（例如"总数少了 3 条""金额多了 5.00"）

【④ 码 —— 相关代码】
（粘贴处理这段数据的完整代码）

补充：什么情况下结果是对的：（如果有）

请按顺序回答：
1. 你判断问题最可能出在哪一段？为什么
2. 我该怎么验证你的判断（要具体到我该做什么）
3. 确认后给出修改的完整代码

我是编程新手，请用大白话解释。

▸ 八类高频错筛查：让 AI 按 8 类常见逻辑错逐条回答”有 / 没有 / 不适用”，对”有”的指明行号与改法（原 72-5）。 ▸ 规则歧义排查：附上你理解的规则，让 AI 对比代码实际执行的规则，指出不一致处（原 72-7）。

模板 72-2：加打印做二分定位

这段代码的最终结果不对，但中间过程我看不到。

请给我一份"带日志版"的完整代码：
- 在每个关键步骤后面加一行打印
- 打印内容包括：步骤编号、步骤在干什么、当时关键变量的值
- 如果处理的是列表，请同时打印它的长度
- 打印格式要清晰，便于我复制回来给你看

不要改动原有逻辑，只加打印。

原代码：
【粘贴】

▸ 生成测试用例：让 AI 设计覆盖正常 / 空 / 边界 / 异常的输入组，改完挨个验证（原 72-6）。

模板 72-3：逐行推演（中立问法，防附和）

请你扮演一台计算机，逐行执行下面这段代码。

输入数据是：【具体的值】

要求：
- 一行一行来，不要跳步
- 每执行一行，写出这一行执行后所有关键变量的当前值
- 遇到循环，至少完整展示前两轮和最后一轮
- 最后给出程序的最终输出

重要：现在不要试图寻找 bug，也不要评价代码好坏，
就老老实实按代码写的逻辑推演一遍。

代码：
【粘贴】

▸ 对比差异找根因：把推演结果与期望值并排，追问差异从第几步产生、是代码错还是理解偏差（原 72-4）。

速查：两类 bug，两套四件套

	报错型（第71篇）	逻辑型（本篇）
四件套	错、码、做、境	入、期、实、码
核心线索	报错原文 + 栈	期望与实际的差异
关键动作	找栈里自己的文件名	加打印 + 二分法
最大的坑	红字消失≠修好	AI 顺着你说”是的这里有问题”
验收标准	说得清值为什么变成那样	测试用例全部通过

最后

这一篇的核心，也压缩成一句话：

没有报错的时候，”期望和实际的差”就是你的报错。

把这个差描述得越具体，AI 越派得上用场。

而当你连差异都描述不清楚的时候——先别急着问 AI，先加两行打印。

看见了，才谈得上分析。

下篇预告

第73篇《用 AI 做性能瓶颈分析——慢在哪，它告诉你》。 能跑、结果也对，就是慢——比 bug 更无从下手。下一篇讲先量再改、性能四大元凶，以及反直觉真相：拖慢你的往往不是代码，是它问了数据库一百遍。我们下篇见。

第71篇：Bug 调试——把报错贴给 AI，错误栈这样喂最有效

2026-09-28T10:00:00+08:00

一屏红字，你只复制了第一行。

前两篇讲的是「读懂」，从这一篇开始讲「修好」。

先说一个几乎所有新手都干过的动作：

程序跑挂了，屏幕上刷出一大片红字。你眯着眼睛看了两秒，鼠标一划，复制了最上面那一行，丢给 AI，问：

“这个错怎么解决？”

然后 AI 给了你一个答案。你照着改，红字消失了。

三天后，同一个地方，换了个姿势又炸了。

这就是”贴报错”最大的陷阱：你以为你在修 bug，其实你只是在让红字消失。

这一篇就讲三件事：一屏红字里哪几行是宝贝、哪几行是噪音；只贴报错为什么常拿不到正解、还差哪几样东西；以及怎么判断 AI 给的是真修好还是假修好。

一、先破个误区：错误信息不是”报警”，是”证词”

很多人对报错的心理是：这玩意儿是来骂我的。

所以看到红字，第一反应是躲——赶紧让它消失。

换个视角：错误信息是程序留给你的一份证词。

它老老实实交代了三件事：

发生了什么类型的问题（是找不到东西？还是类型不对？还是权限不够？）
是在哪一行、哪个文件出的事
出事的时候，那些变量是什么值

这三件事，就是破案的全部线索。

你把证词只念了第一句就合上，当然破不了案。

二、错误栈怎么读：三步定位法

所谓「错误栈」（也叫堆栈、调用栈、traceback），就是那一大坨看起来像天书的东西。

它其实是一张路径图：程序从哪儿出发，一路调用了谁，最后在哪儿摔倒了。

新手觉得它可怕，是因为里面大部分文件名你根本没见过——那些都是库和框架内部的文件。

记住三步，就能读懂九成的错误栈。

第一步：找”错误类型 + 错误消息”这一行

这是整段报错的核心。

不同语言位置不一样：

Python：在最后一行（比如 KeyError: 'user_id'）
JavaScript / Node：通常在第一行（比如 TypeError: Cannot read properties of undefined）
Java / C#：在第一行（比如 NullPointerException）

这一行告诉你”是什么错”。

第二步：从栈里找出你自己的文件名

这一步是最关键的，也是最多人漏掉的。

那一大坨路径里，绝大部分长这样：

at node_modules/xxx/lib/index.js:412
at /usr/lib/python3.11/site-packages/yyy/core.py:88

凡是路径里带 node_modules、site-packages、vendor、dist、lib 这些字眼的，基本都不是你的代码。

你要找的是带着你自己项目文件名的那一行——比如 app.py、main.js、UserService.java。

那一行，才是你真正要看的地方。

小技巧： 如果栈里出现了好几行你自己的文件，取离错误最近的那一行（Python 看最下面那个，JS 看最上面那个）。

第三步：看错误消息里的”具体值”

好的报错会把出事时的实际值写出来：

KeyError: 'user_id' —— 说明它去找一个叫 user_id 的东西，没找着 Cannot read properties of undefined (reading 'name') —— 说明某个东西是空的，你还想从它身上拿 name

这一步回答的是”为什么”。

三、贴报错四件套：错、码、做、境

现在到了最实用的部分。

只贴报错，AI 的回答准确率大概只有五成。

你要给它四样东西，我把它叫「贴报错四件套」：

件	内容	一句话
错	完整报错原文	从头到尾，别截断，别转述
码	出错那段代码	报错指到的那一行及其上下文
做	你做了什么才触发的	点了什么、传了什么参数
境	环境信息	语言版本、框架版本、怎么运行的

逐个说清楚为什么。

「错」：完整原文，不要转述

最要命的一个坏习惯是用自己的话描述报错：

❌ “它说什么找不到什么东西”

AI 收到这句话，只能靠猜。

✅ 直接把整段红字，从第一个字符复制到最后一个字符，原封不动贴进去。

你觉得看不懂的那部分，恰恰可能是 AI 最需要的部分。

「码」：贴出错那一行的前后文

只贴报错指到的那一行是不够的。

那一行是结果，原因往往在它上面几行。

建议贴出错行前后各 10～20 行，或者干脆把整个函数贴进去。

如果这段代码依赖别的地方传过来的数据，把数据长什么样也说一句。

「做」：复现动作

这一条最容易被忽略，但价值极高。

“我在页面上点了’提交’按钮，表单里手机号那一栏是空的，然后就报了这个错。”

这一句话，直接把排查范围从”整个项目”缩小到”表单提交 + 空值处理”。

很多时候，AI 靠这一句就能直接猜中根因。

「境」：环境信息

同样一行代码，在不同版本下的行为可能完全不同。

至少说清楚：什么语言、什么框架、大概什么版本、在哪儿跑的（本地/服务器/浏览器）。

四、最大的坑：红字消失 ≠ 问题解决

AI 有一个很强的倾向：它会优先给你”能让报错消失”的方案，而不一定是”能让问题不再发生”的方案。

下面这三种改法，都是典型的”假修好”：

假修好一：把错误吞掉

给你套一层 try / catch（或者 try / except），把报错捂住不让它冒出来。

红字确实没了。但那段逻辑其实根本没跑成功，只是你看不见了。

后果是：数据没存进去，你还以为存了。

假修好二：加个判空绕过去

比如报错是”某个值是空的”，AI 给你加一句”如果为空就跳过”。

问题是：它为什么会是空的？

如果它本来就允许为空，那这么改是对的；如果它本该有值却没有，那真正的 bug 在更上游——你只是把症状挡住了。

假修好三：强行转类型

报错说类型不对，AI 给你强制转一下。

这跟上面同理：类型为什么会不对？ 这才是要问的。

所以，AI 给完修改方案后，你必须追问三句话。

我把它叫「修完必问三句」：

这个错的根本原因是什么？ 请从触发到报错，按顺序讲一遍。
你这个改法是治标还是治本？ 如果是治标，治本该怎么改？
项目里还有没有别的地方，可能犯同样的错？

第三句尤其值钱。一个 bug 出现的地方，往往不止一处。

五、按错误类型分档，问法不一样

不是所有报错都要走完整套流程。先分个档，省时间。

第一档：一眼错（30 秒解决）

拼写错了、少个括号、变量名写错、忘了导入。

这类错误消息通常很直白，AI 几乎不会答错。

直接贴报错 + 那一行代码就够了，不用四件套。

第二档：环境错（最烦人的一档）

装不上、跑不起来、版本冲突、路径找不到。

这一档的特点是：代码本身没问题，问题在外面。

贴的时候一定要重点给「境」：操作系统、语言版本、安装命令、完整的安装日志。

提示：这一档特别容易踩到”网上抄的方案是别人环境下的”。让 AI 明确告诉你每条命令是干什么的，别闭眼执行。

第三档：隐蔽错（要走完整流程）

程序跑得好好的，某个特定条件下才炸。

这一档必须上四件套，而且「做」这一项最关键——你要说清楚什么情况下会出、什么情况下不出。

“输入正常数据没问题，一旦名字里带空格就报错。”

这一句话的价值，超过一百行代码。

六、还有一招：让 AI 教你自己看

如果你想真的进步，而不是每次都当伸手党，加一句话就行：

“修改之后，请再告诉我：以后遇到同类报错，我自己该怎么一眼看出问题在哪？”

AI 会给你一套”识别特征”。

积累十几条，你会发现大部分报错你自己扫一眼就知道原因了。

提示词模板盒子

以下模板可直接复制使用，把【】里的内容换成你自己的。

模板 71-1：贴报错四件套（万能主模板）

我遇到一个报错，需要你帮我定位并修复。

【① 错 —— 完整报错原文】
（从头到尾原封不动粘贴，不要删改、不要转述）

【② 码 —— 出错的代码】
（报错指向的那一行，及前后各 15 行；能贴整个函数更好）

【③ 做 —— 我是怎么触发的】
我做了：（例如：在页面点了"提交"按钮）
当时的输入是：（例如：手机号那栏是空的）
什么情况下不会出现：（例如：填了手机号就正常）

【④ 境 —— 环境信息】
语言/框架：  版本：  运行方式：（本地/服务器/浏览器）  操作系统：

请按以下顺序回答：
1. 这个报错的中文意思是什么（大白话）
2. 根本原因是什么，从触发到报错完整讲一遍
3. 给出修改后的完整代码，标出改动了哪几处
4. 说明这是治标还是治本

我是编程新手，请不要用没解释过的术语。

▸ 环境类报错：在「④ 境」里重点给操作系统、语言版本、安装命令和完整安装日志，并让 AI 说明每条命令是干什么的、别闭眼执行（原模板 71-4）。 ▸ 偶发 bug（时好时坏）：在「③ 做」里写清”什么情况下会出现、什么情况下不会、多久出现一次”，附上报错原文和相关代码，让 AI 按可能性列原因并给验证动作（原模板 71-5）。

模板 71-2：读懂错误栈（看不懂那一坨时用）

下面是一段报错的完整堆栈信息，我看不懂。

请帮我拆解：
① 错误类型和错误消息是哪一行？中文意思是什么？
② 这一坨里，哪几行是我自己的代码，哪几行是库/框架内部的？分别列出来。
③ 我应该重点看哪一行？为什么？
④ 从这段信息能推测出，出事时哪个变量是什么值？

报错原文：
【粘贴完整报错】

模板 71-3：修完必问三句（防假修好）

关于你刚才给的修改方案，我要确认三件事：

① 这个 bug 的根本原因到底是什么？
   请从"用户做了什么"开始，一步步讲到"为什么会报错"。

② 你的改法是治标还是治本？
   如果只是让报错不再出现、但根因还在，请明说，
   并告诉我治本应该怎么改。

③ 我的项目里，还有没有别的地方可能犯同样的错？
   请告诉我该用什么关键词去搜索排查。

▸ 顺便学会自己看：修好后加一句——”以后遇到同类报错，我自己该怎么一眼看出问题在哪？”让 AI 给你一套识别特征，抄进笔记（原模板 71-6）。

速查：一屏红字，先看这三处

步	看什么	回答什么
①	错误类型 + 消息（Python 看最后一行，JS/Java 看第一行）	是什么错
②	栈里带你自己文件名的那一行	错在哪
③	消息里出现的具体值 / 变量名	为什么

路径里带 node_modules、site-packages、vendor、dist 的，一律先跳过。

速查：三档报错，投入不一样

档	典型表现	该怎么贴
一眼错	拼写、括号、忘导入	报错 + 那一行，30 秒搞定
环境错	装不上、跑不起、版本冲突	重点给「境」+ 完整安装日志
隐蔽错	平时正常，特定条件才炸	上全套四件套，重点写「做」

最后

这一篇的核心，压缩成一句话：

红字消失，不代表 bug 修好了。

判断标准只有一条——你能不能说清”它原本为什么会变成那个值”。

说得清，是真修好；说不清，只是把问题往后拖了几天。

而要说得清，前提是你给了 AI 足够的证词：错、码、做、境。

下篇预告

第72篇《让 AI 定位逻辑错误——没有红字也能查》。 下一篇讲更难的：程序跑得欢、结果却不对，一个红字都没有——不报错的 bug，才是真正吃时间的那一类。我们下篇见。