第二章 · 第 6 节

调试思维

这一节你会拿到

你会拿到一张能反复用的"四栏调试卡",学会把报错准确地喂给 Agent,把一个"突然坏了"的问题，一步步修好。会修 bug,是你能不能独立走下去的分水岭。

回头一题

这道题不考这一节，考前面学过的。想不起来就回去翻一眼再答——记不住的东西，真用的时候一样会卡。

Supabase 给你两把钥匙：一把叫 Publishable(老项目叫 anon)，一把叫 Secret(老项目叫 service_role)。哪一把绝对不能提交到 GitHub、也不能出现在网页前端？

写到这儿你多半已经遇上过：昨天还好好的，今天一打开就报错，或者点个按钮页面就白了。这很正常。做东西的人，一半时间都在跟"它怎么坏了"打交道。能不能独立走下去，不看你会不会一次做对，而看你坏了之后修不修得回来。这一节就练这个。

很多人一看到满屏红字就慌，赶紧关掉。恰恰相反：那段报错，是电脑在告诉你"哪儿不对、在哪一行"。它是你最重要的线索，不是训你。你要做的第一件事，永远是:把它看清、原封不动地留下来,而不是关掉重来。

报错原文，是无价的。

哪怕你一个字看不懂，也别慌、别改写、别只截一半。那串英文对 Agent 来说，常常一眼就能定位问题。你看不懂没关系,你的活是把它完整搬给 Agent,让它来读。

修 bug 最容易犯的错，是丢给 Agent 一句"它坏了，你帮我看看"。Agent 跟你一样两眼一抹黑，只能猜。会修的人，是会"描述"的人。描述靠这四栏，缺一不可:

✗ 这样说，等于没说 "它坏了，你帮我修一下。"
"报错了，怎么办？"
"页面白了。"

✓ 这样说,Agent 一下就能动手 "我刚把提交按钮改成蓝色，一保存，页面就白了。报错原文是(贴全)……我期望页面正常显示，实际整页空白。我试过刷新，没用。"

把"好的说法"拆开，正好就是四栏。下面这张卡，以后每次卡住都照它填一遍:

卡住了就照这四栏填，填完点"生成",把它整段发给 Agent。四栏都填，它才不用猜。

① 报错原文把红字/报错完整、原样复制进来，别改写、别只留一半。看不懂也照搬。

② 我刚做了什么出错前的最后一步。八成问题就出在这一步。

③ 期望 vs 实际你本以为会怎样，结果实际怎样。这条帮 Agent 对准"到底哪里不对"。

④ 已试过什么你自己试过的招(哪怕没用)。免得 Agent 让你再走一遍冤枉路。

复制它，发给你的 Agent:

光看不练不算会。下面我们故意制造一个小故障，再用调试卡把它修好。真出问题时你就不慌了。

操作 · 一：制造一个 bug。

让 Agent 帮你做个"可控的小破坏"(它可控，好还原):

为了练习调试，请帮我在项目里故意制造一个小错误，让页面提交工单时会报错。
先别告诉我错在哪，我要自己照"四栏调试卡"把它描述出来、再让你修。
记得这个改动要能一键还原。

操作 · 二：照四栏卡描述它。

去触发那个错(比如提交一条工单),把报错原样复制，填进上面的四栏卡，点"生成"。

操作 · 三：把生成的那段发给 Agent,让它修。

然后看它怎么定位、改了哪里,这一眼很值钱，你会慢慢摸到"这类错一般出在哪"。修好后，自己再触发一次，确认真的不报了。

玻璃箱提醒

Agent 修的时候，别只说"好了下一个"。多问一句"它为什么会坏、你改了什么"。你不用看懂每行代码，但要能听懂"哦，原来是那个 key 填错了 / 那个字段名写错了"。这样下次同类的错，你自己一眼就看出来了。

2.6 · 四栏调试卡

对着你真修过的那个 bug 勾。

页面突然白屏、终端一堆红字。你第一步该干嘛？

照四栏卡填了、发给 Agent 还是修不好？把你填的四栏、和 Agent 的来回对话发到群里，或直接找 Abel、助教。有时换个人看一眼报错，一下就通了。