Playbook / Learning Path
试错不是方法,是没方法
你卡住,不是因为不够努力,是因为你跳过了"先想清楚"那一步,直接拿改一行跑一下去顶。要补的不是某个框架,是两样心法:动手前先写下来(把想法落成一份小 spec),和 debug 时带着假设(像做实验一样排错,不靠瞎试)。这两样练顺了,试错从"唯一手段"退回"探路工具",效率自然就上来了。
从"为什么卡"走到"明天练什么"
咱们先把"试错"这事儿看清楚——它不丢人,丢人的是只会它。然后上三样真能治本的本事;橙色那站(带假设去 debug)直接打你说的"试错效率低"这个痛点。最后给一条你今晚就能起步的练法。
试错本身不丢人,丢人的是只会它
你说试错这事儿,我太懂了——改一行、跑一下、不对、再改一行,一晚上过去了,功能是出来了,可你自己都说不清它到底咋好的。这种感觉憋得慌,我先给你松口气:试错不是错的。
你想啊,一个东西你完全没碰过,不试你怎么知道它什么脾气?哪怕是老手,面对一个陌生的 API、一个没见过的报错,第一反应也是动手戳两下。试错是探路用的,这是它的本职。问题出在哪儿呢?——出在你把探路的工具,当成了走完全程的唯一办法。该收敛的时候你还在戳,那就成病了。
研究里早把这层说透了:学生最常见的一个误区,就是"程序不对的时候,挪挪语句、改改表达式、看看结果"被当成最好的排错办法1。听着耳熟吧?这不是笨,这是没人教过你另一套而已。
| 什么时候 | 试错很好 | 试错变成病 |
|---|---|---|
| 阶段 | 探索期:摸陌生地形 | 收敛期:该定方案了还在戳 |
| 你心里 | "我在试它什么反应" | "我也不知道为啥,反正它好了" |
| 下一次 | 试完攒下一条经验 | 换个项目又从零乱试 |
| 代价 | 几分钟,值 | 一整晚,且不可复用 |
回想你上一个卡很久的 bug:你最后是"想明白了为什么"才修好的,还是"瞎改着改着它自己就好了"?这两种结局,对你下一个 bug 有什么不一样的影响?先在脑子里答一句,再点开。
试着先答
"想明白了"——你攒下一条能复用的经验,下次同类 bug 几分钟搞定。"它自己好了"——你啥也没攒下,而且更糟:你不知道它真好了还是碰巧不报错了,这种修复随时会复发。试错最大的隐性成本不是时间,是它不给你留经验。
记住这一句:试错是探路的脚,不是赶路的车——你缺的不是更努力地试,是知道什么时候该停下试、改用想。
第一样:动手前先把它写下来
这是性价比最高的一样,先学它。说白了就一件事:动手敲(或者动手让 AI 敲)之前,先用大白话把"我要做啥、做成啥样算成"写下来。一个 markdown 文件就够,不需要什么工具3。
为什么这一步这么顶用?你想想你现在的 vibe coding 是怎么个流程:脑子里一个模糊的想法 → 直接甩给 AI 一句"帮我加个登录" → AI 只能猜你那几千个没说出口的细节 → 猜错一半 → 你看着不对 → 再试。试错的根,就在"想法是模糊的"这儿。大模型特别会补全模式,但它不会读心4——你给的越糊,它猜得越歪,你后面试得越久。
把想法写下来,逼的是你自己先想清楚,不是为了给 AI 看。行业里这套现在叫规格驱动开发(spec-driven development),但你别被名字唬住,核心就一个顺序:
注意第二步——出计划——你不是让 AI 直接写码,是让它先想:这事儿分几步、每步先后、哪步有坑3。这一步就是在替你做"问题拆解":把一个大问题切成几个小到一眼能看明白、能单独验证的块8。拆解这门手艺,是练出来的,在日常小任务上多练就长8。
下面是一份给"在我的笔记 app 里加个搜索框"写的迷你 spec,缺了最关键的两块。你先想想缺啥:
· 做啥:用户在顶部输入关键词,实时过滤出标题或正文含该词的笔记。
· 边界:?(空输入怎么办?没匹配怎么办?大小写敏不敏感?)
· 算成:?(怎样才算这个功能做完了、对了?)
对答案
边界:空输入时显示全部笔记;没匹配时显示"无结果"而不是空白;大小写不敏感;中文不分词只做包含匹配。算成:输入"会议"能秒出所有含"会议"的笔记、清空输入恢复全部、输入乱码显示无结果——这三条都过,才算做完。
你看,把"边界"和"算成"写出来这十分钟,省的是后面 AI 反复猜、你反复试的两小时。验收标准写不出来,说明你自己还没想清楚要什么。
记住这一句:动手前花十分钟写下"做啥、边界、算成",是把试错从代码里挪到脑子里——脑子里改一行想法,比代码里改一行跑一遍快一百倍。
第二样:带着假设去 debug
这一节直接打你说的"试错效率低"。你现在排错大概是这样:报错了 → 改个地方 → 跑 → 还错 → 再改个地方 → 跑……这就是纯试错,可能性太多的时候,你会被淹死1。
换一套,就一个动作的差别:动手改之前,先猜一句"我赌问题出在 X"。这叫带假设排错,说穿了就是先猜后验、跟做实验一个道理——先撂个预测,再动手验它12。为什么"先猜"这么关键?因为如果你先动手跑、再看结果,你的脑子会偷懒,顺着结果编一个解释1;先把话撂出去,你才是在真的检验,而不是事后找补。
| 一步 | 纯试错(你现在) | 带假设(要学的) |
|---|---|---|
| 第一反应 | 随手改个看着可疑的地方 | 先问:它应该怎样,实际怎样? |
| 动手前 | 不猜,直接改 | 撂一句"我赌是 X 导致的" |
| 改动 | 一次动好几处,不知哪处生效 | 一次只验一个假设,改一处 |
| 结果 | 好了也不知为啥好 | 验证了/推翻了,都长一条经验 |
| 不对时 | 再随机换一处 | 换下一个假设,范围已缩小 |
页面上用户头像不显示。纯试错:你开始挨个改 CSS、换图片路径、删了又加……。带假设:你先撂话——"我赌是图片 URL 拿到的是空"。怎么验?打开浏览器控制台看那个 <img> 的 src 值。一看,src 真是空 → 假设成立,问题往上游推:为什么 URL 是空?是接口没返回,还是字段名写错了?两步就锁定了,而不是瞎改二十次。
现象:点"保存"按钮,网页没反应,也不报错。按带假设排错,你的第一个假设该怎么撂?以及怎么花最小代价验它?先自己写一句再点开。
对答案
一个好假设 + 验法,比如:"我赌点击事件压根没触发"——验法:在按钮的点击处理函数第一行打一条 console.log("clicked"),点一下看控制台有没有打印。有 → 事件触发了,假设推翻,往下游(保存逻辑)查;没有 → 假设成立,问题在绑定(按钮没接上函数 / 选择器写错)。关键不是你猜得多准,是每次只验一件事、用最小动作验,这样无论对错,搜索范围都砍掉一半。
记住这一句:debug 不是改代码的手速比赛,是缩小怀疑范围的推理游戏——改之前先撂一句"我赌是 X",你就从乱试切换成了排查。
第三样:读得懂你没写的那段码
vibe coding 有个绕不开的软肋:那些码是 AI 写的,你没读。一出问题,你对着自己的项目却像看天书,只能回去再试。所以第三样本事是读代码——而且这恰恰是学校、培训班最不教的一项,可开发者超过七成的时间其实花在读别人的码上5。这门手艺被严重低估了。
读代码不是从第一行啃到最后一行。你以为得像读书一样通读一遍才懂——其实不是。真要那么读,你必迷路5。
"我得把这个文件从头到尾看明白再说。"——错。老手的读法是:先扫一眼全貌找个大概,然后挑一条执行路径跟着走。比如就盯"用户点登录"这一条线,只看跟它有关的码,其它全先不管5。一次跟一条线,比通读省十倍力气。
三个能立刻上手的小动作
一,让机器替你讲:别干瞪着码猜,打个断点,用调试器一步步走,看每个变量真实变成了啥5——这跟上一节的"带假设"是一套功夫。二,把变量名当线索:名字是原作者(哪怕是 AI)觉得重要的东西,顺着名字读能猜出意图6。三,看提交历史:哪些文件总一起改、哪个函数被反复动,这些是代码在告诉你它的"关节"在哪6。
还有个 vibe coding 时代的便宜可以占:你完全可以让 AI 帮你读——把那段你看不懂的码贴给它,让它逐行讲给你听、画出调用关系。但注意,这是让它当你的讲解员,你得跟着脑子过一遍,不是又一次"它说啥我信啥"。
记住这一句:读代码是门手艺,头几次都疼,跟一条执行路径、用调试器看真实值,跟几十次之后你看见的就不再是语法,是套路。
怎么练:一条 90 天的渐进路子
道理听完没用,得有个落地的练法。别想着一口吃成胖子——拆解、读码这些都是渐进练出来的本事,从低风险的小事起步,慢慢加难度8。给你一条不重学历、就靠你手上项目练的路:
| 阶段 | 练什么 | 怎么验证练到了 |
|---|---|---|
| 第 1 月 | 每个新功能动手前,写 3 行 spec:做啥 / 边界 / 算成 | 翻回去看,AI 一次猜对的比例有没有升 |
| 第 2 月 | 每次 debug 强制先撂一句"我赌是 X" 再动手 | 记 5 个 bug,数数"猜对/总数",看推理在变准 |
| 第 3 月 | 每周挑一段 AI 写的码,跟一条执行路径读懂,讲给自己听 | 能不看码,口述这段干了啥、哪步是关节 |
| 全程 | 每个能跑的版本都用 Git 存个快照 | 搞砸了能一键回到上一个好版本7 |
这里头有个顺序上的道理:先练第一样(写下来),因为它把你大量的试错从源头掐掉;再练第二样(带假设),它治你已经发生的试错;第三样(读码)垫在底下,让你有底气不怕碰 AI 写的东西。三样里你要是只挑一样今晚就开始,挑写 spec——它最省力、回报最快。
你手上正在做的那个项目,下一个要加的功能是什么?如果现在让你只写 3 行——做啥、边界、算成——你写得出来吗?卡在哪一行,哪一行就是你现在最该想清楚的地方。
试着先答
大多数人卡在"边界"和"算成"这两行——"做啥"谁都写得出,但一到"空输入怎么办、怎样算做完",就发现自己其实没想清楚。卡住不是坏事,那正是你过去靠试错糊过去的地方。这次把它写出来,就等于提前把一晚上的试错,压缩成十分钟的思考。
记住这一句:别等"准备好了"再练,就用你手上这个项目——下一个功能写 3 行 spec,下一个 bug 先撂一句假设,这就是起步。
你要补的是"先想后做",不是更会试
把话收一收。你卡在试错,不是技术不够,是缺了"动手之前先想清楚"这套肌肉。具体要学三样,有先后。先学写 spec——动手前用三行白话钉死"做啥、边界、算成"。你别小看这一步,它是性价比之王,直接掐掉大半试错的源头。再学带假设 debug——改之前先撂一句"我赌是 X",一次只验一个,乱改就变成了排查,这一样直接治你说的低效。最后垫上读代码——挑一条执行路径跟着走、用调试器看真实值,你就不再怕 AI 写的那堆东西了。这三样,全靠你手上现成的项目练,不用回炉学历。那什么时候这套不成立?——纯一次性的小玩具、周末扔了不要的 demo,你就该痛快 vibe、痛快试,给它套 spec 反而是浪费。这套心法是给"想认真做完、做对、还想下次更快"的项目准备的。一句话:试错留着探路,赶路换上"先想后做"这辆车。
这些地方我说实话也没全把握
- "90 天"这个节奏是我给的脚手架,不是铁律。有人一个月就顺了,有人需要半年。别拿日历卡自己,拿"验证那一栏"卡——验证过了就往下走。
- "开发者七成时间在读码"这个数널,常被引用但来源偏二手。方向我信(读远多于写),但具体百分比你听个意思就行,别当精确数据。
- 三样本事的排序是我的判断,有取舍。也有人主张先练读码(因为 vibe coding 的软肋最直接)。我把写 spec 排第一,是因为它对"减少试错"这个你最痛的点最直接见效——但这条我没有三方共识背书。
读完盖住,试着答这几题
试错什么时候是好的,什么时候变成病?分界线在哪?
试着先答
探索期(摸陌生地形)用试错是好的;收敛期(该定方案、该排错)还在瞎戳就是病。分界线是:你心里有没有"我在试它什么反应"的预期——有预期是探路,没预期是乱撞。
为什么"写 spec"能减少试错?它治的是哪个根?
试着先答
试错的根是"想法是模糊的",AI 只能猜,猜歪了你就得反复试。写 spec 逼你自己先想清楚"做啥、边界、算成",把试错从代码里(改一行跑一遍)挪到脑子里(改一行想法),快得多。
"带假设 debug"跟纯试错,关键差在哪一个动作?
试着先答
差在"动手改之前先撂一句'我赌是 X'"。先撂话你才是真检验、一次只验一个、无论对错都缩小范围;先动手再看结果,脑子会顺着结果编解释,等于没验。
应用题:你的 app 启动后白屏,控制台没报错。用带假设法,写出你的第一个假设 + 最小验法。
试着先答
示例:假设"根组件压根没渲染出来"。最小验法:在根组件渲染处打一条
console.log或在 DOM 里看根节点有没有内容。有内容 → 假设推翻,查是不是 CSS 把它藏了;没内容 → 假设成立,查挂载/路由。重点是只验这一件、用最小动作。读一段 AI 写的、你看不懂的代码,正确的第一步是什么?(不是什么?)
试着先答
不是从头读到尾。第一步是扫一眼全貌,然后挑一条执行路径(比如"点登录"这一条线)跟着走,只看相关的,其它先不管;配合调试器看真实值、变量名当线索。
把这几题截图,过两三天再凭记忆答一遍 —— 记得住才算真学会。
Sources
- Hypothesis-driven debugging(假设驱动排错教学笔记,Grinnell College CSC 151) — https://csc151.cs.grinnell.edu/readings/hypothesis-driven-debugging.html
- Debugging with the Scientific Method(用科学方法排错) — https://coders-errand.com/debugging-with-the-scientific-method/
- Spec-driven development with AI: a new open source toolkit(GitHub Blog) — https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- Addy Osmani — How to write a good spec for AI agents — https://addyosmani.com/blog/good-spec/
- The Most Efficient Way to Read Code Written by Someone Else(Towards Data Science) — https://towardsdatascience.com/the-most-efficient-way-to-read-code-written-by-someone-else-cb1a05102b76/
- How to interrogate unfamiliar code(Stack Overflow Blog) — https://stackoverflow.blog/2022/08/15/how-to-interrogate-unfamiliar-code/
- Beyond Vibe Coding: a systematic AI software development process(含版本控制/快照纪律) — https://eclipsesource.com/blogs/2026/05/26/beyond-vibe-coding-ocx26/
- Problem Decomposition in Programming: Breaking Down Complexity(DEV) — https://dev.to/mzunairtariq/problem-decomposition-in-programming-breaking-down-complexity-4b47