十月初在 dev.to 上读到 Mika Flowers 的一篇复盘。她写自己在 5 周里提交了 866 次，同时承认对代码的理解没跟上。文章是 10 月 3 日发的。里面有一句话我盯着看了挺久：她生产软件的能力，提升速度快于解释所生产软件的能力。
我第一反应不是羡慕那个提交数，是去翻自己项目的 git log。翻完有点坐不住——有三四处改动，我现在也讲不清当时为什么那么写，只能靠 diff 反推。这篇笔记不聊她那些项目，只记我从里面挑出来、自己试了快两周的三条做法，以及一条我试过但没坚持下来的。你可以在下一个报错上试一遍，不保证省时间，但至少知道自己在哪儿断了。
先拆开看看这个循环断在哪。以前遇到报错，流程大概是读文档、翻 issue、改一点、再跑、再改，来回几轮才建立起对这块的心智模型。现在这个循环被压成了一次粘贴——把错误丢给助手，拿到一段具体修复，错误消失，继续往下写。
错误确实消失了。但它消失，跟我知道它为什么坏，是两件事，只是它们同时发生的时候很难区分。反馈快到一定程度，人会误以为反馈本身完成了学习。我自己的重灾区是数据存储这块：手上有段客户应用跑在 PostgreSQL 上，能跑、有人用，但我此前说不清一个索引的成本是什么——加索引让读变快，那代价记在哪儿？这个问题当时真答不上来。
Mika 一共列了四条规则。我全抄进了一个叫 NOTES.md 的文件，但两周下来真正每天用得上的只有三条。
第一条，问 AI 之前先写下自己的预测。落到操作上，我现在会先开一个空文件敲几行：
现象：列表页加载 3 秒以上
我的预测：user_id 上没有索引，走的全表扫
验证方式：EXPLAIN ANALYZE 看是不是 Seq Scan
关键是「我的预测」这一栏必须写，哪怕写错。写错反而更有价值——调查完再让助手看我的推理，让它指出我哪一步跳过了，比直接拿一个正确答案有用得多。这一步我一开始没搞懂为什么要单独写下来，后来才想明白：预测的作用不是猜对，是把脑子里的模型摊到纸面上，不然你永远分不清自己是懂了，还是只是认得这套说法。
顺着这条我还加了一个验证动作：把那个最慢的查询，在加索引和不加索引两种状态下各跑一次 EXPLAIN ANALYZE，对着两边输出读一遍差异。这比看任何一篇讲索引的文章都直接，因为代价数字是你自己机器上跑出来的。
第二条，不接受自己解释不了的代码。这条我本来就有，但文章里的问法比我原来的更狠。它要求你能回答五个问题：
这段代码解决什么问题
为什么这么实现
依赖了哪些假设
失败的时候会怎样
把它删掉会破坏什么
我最容易卡住的是第三个和第五个——「依赖什么假设」和「删掉会破坏什么」，恰恰是重构时最要命的两个。这里有个小技巧：让助手从「未来维护者」的视角把这段代码讲一遍，然后你对着真实代码读。💡 生成的代码读起来语气特别自信，注释也排得整齐，很容易让人略过可疑的设计决策；换个视角复述一遍，那些决策会自己浮出来。
第三条，故障修完之后，追问一句「什么测试本来可以提前发现它」。不要求你立刻补上这个测试，是要求你把失败模式想一遍。我照着这个思路做过一个练习：让助手模拟两个编辑从同一条记录的同一个版本开始改库存，先写下你认为第二次提交应该覆盖、合并还是报错，再去代码里追这个决定是哪一层做的。我写下的答案是「报错」，追下来发现当前实现是「后写覆盖」。这个差距本身就是收获，而且它顺便告诉你该给哪一层补测试。
第四条规则——重构前先自己读代码——我留着，但没写进日常。它跟第二条重叠度太高，而且我心里清楚真到重构时很难忍住不先甩给助手，留着当个提醒就行。
Mika 的计划里还有一条：每天用无 AI 的方式从空文件开始做一个小题，二十分钟，比如统计字符串单词数、列表去重。我照着试了几天。第一天做了个去重，做出来了，还挺顺；第二天没做，第三天想起来了但也没做。
我现在的判断是这条不适合当主线。它的本意是重新引入摩擦，但摩擦放在一个跟真实项目无关的小题上，收益留不住，因为它没有上下文可以挂钩。我后来把同样的意图挪进了真项目——每次让助手重写一段代码之前，先自己写清楚「我不喜欢它的哪一点、职责应该怎么拆」，再让它给方案。同样是刻意放慢，但慢下来的是我明天还要维护的东西，下次还记得住。
顺带说一句，我不是要停用 AI，这点得讲清楚，我也刚续了订阅。我关心的问题只有一个：如果明天所有编码助手都消失，我还能不能维护今天交付的东西。能不能同样快写出来、能不能记住某个 API 怎么调，这些我不在乎；调试、解释架构、安全地改动、认出一个方案哪里错了——这几样不行的话，前面那些快就没意义。
划重点
第一，「错误消失」和「知识缺口补上」是两件事，反馈越快越容易混为一谈，所以需要一个故意的卡点，卡在「贴给 AI 之前」。
第二，最容易落地的卡点只有一个动作：问之前先写下预测，写错也算数，查完再让助手挑你推理里的毛病。
第三，不接受自己讲不清的代码，尤其是「依赖什么假设」和「删掉会破坏什么」这两问——生成的代码语气太自信，读的时候要主动换个视角看它。
这篇就记到这里。你可以挑手上最慢的那个查询，先在纸上写下你猜的原因，再跑一次带执行计划的查询验证一遍，整个动作大概二十分钟。如果你也有过「提交数上去了、解释能力没跟上」的时刻，欢迎回来留言，我一起补一条笔记。