音频直链：https://tangkk.github.io/lobster-headlines-podcast/audio/ep028-ai-code-literacy.mp3

欢迎收听龙虾头条，今天我们来聊一个很多开发者正在经历、但不太愿意承认的状态。

先说一个场景，你可能很熟悉。你打开 Cursor，或者 Claude Code，用自然语言描述了一个需求。AI 哗哗哗生成了一堆代码，你跑了一下，功能是通的。逻辑看起来没什么问题，测试也通过了。你 commit，push，上线。

然后两个星期之后，产品提了一个改动。你打开那个文件，发现——这段代码是谁写的？你看着那个函数签名，看着那些层层嵌套的条件判断，看着那个诡异的变量命名——然后你突然意识到，这就是你自己提交的代码。

你只是不记得它了。

不，更准确地说，你从来没真正"认得"它。

这就是我今天想聊的状态：当 AI 帮我们写了全部代码之后，我们正在失去"读懂自己代码"的能力。 这不是一个关于 AI 好不好的讨论，这是关于一个正在悄悄发生的身份转变——从一个代码的作者，变成一个代码的委托人。

让我再说深一点。很多人在辩护 vibe coding 的时候会说：只要能跑通，能上线，能交付，为什么要管代码长什么样？这个逻辑放在交付截止日当天是成立的——我不否认。但问题在于，如果你每一行代码都是这么来的，一个月之后，你对整个项目的理解会降到什么程度？

你仔细想想就明白了。过去你手写代码的时候，每一行都在你脑子里过了一遍。你知道为什么这个变量叫这个名字，你知道那段边界检查为什么写在那个位置，你甚至知道那个看起来多余的 null check 是因为两个月前线上出了一个诡异的 NPE。这些东西不在注释里，不在文档里，只在你写代码那三十分钟的思考过程里。

而现在，AI 帮你跳过了这三十分钟。

结果就是，你的项目跑起来了，系统上线了，功能交付了——但你回头去看代码的时候，那种熟悉感消失了。你不再觉得"这是我的作品"，你觉得这是"我签了个外包合同让别人做的"。

这里面藏着一个更深的麻烦：出了问题之后，谁来修？

以前 bug 来了，你第一反应是"我可能在哪里写错了"。因为每一行都是你写的，你有那个直觉——那个数据可能在传进来的第三层就变形了，那个边界条件你当时就隐隐觉得没覆盖全。这个直觉不神，它就是你在写代码时存储在大脑里的上下文。

但现在，bug 来了，你只有一个感觉：我不知道问题在哪。因为生成那段代码的时候，你没有建立任何上下文。你只能从头开始读，一行一行重新理解——问题是，这种"重新理解一段不是自己写的代码"的过程，我们通常不叫 debug，我们叫"接手别人的遗留项目"。

区别在于，这个"别人的遗留项目"的提交记录上，写的是你的名字。

还有一个更隐蔽的问题，跟 code review 有关。很多团队引入 AI 编程之后，其实形成了两条并行线：开发者用 AI 写代码，reviewer 用 AI 做审查。AI 写出了一个看起来合理的实现，AI reviewer 扫了一遍说"看起来没问题"。两边都过了，代码合进去了。但如果你把 AI 从中间抽掉——你会发现，写代码的人没认真想过设计，审代码的人也没认真读过逻辑。两个人类的判断力在这个流程里，一次都没有真正出场过。

这不是代码审查，这是两方 AI 在对着同一段代码互相点头。而你是那个在旁边看着、点了 approve 的第三方。

长远来看，团队里所有人都会慢慢变得"能 approve，不能 defend"。你能说这段代码过审了，但你没办法在架构讨论会上解释这段代码为什么这么设计——因为你没设计它，AI 也没告诉你它的设计意图。AI 只是给了一个"让测试通过的答案"。就像数学考试里抄了同桌的答案，你得了分，但你不知道推导过程是什么。

还有一个角度值得聊，就是技能退化。这不是危言耸听。

打个比方。如果你每天都用计算器做加减乘除，十年之后，你还能心算三位数乘两位数吗？理论上你会说"能"，但实际上你算不出来。不是因为智商降了，是因为那条神经通路太久没有被激活了。

读代码是一样的道理。当你每天都读 AI 生成的代码——这些代码在语法上是对的，但在设计意图上是无根之木——你其实没有在"读代码"，你只是在"核对输出"。核对和阅读是两件完全不同的事。核对追求的是"有没有明显的错"，阅读追求的是"它在想什么、为什么这样想、还有没有更好的想法"。

如果你一整年都在核对，没有在阅读，一年后你真的还能读懂一个有设计意图的复杂模块吗？

我见过一个很扎心的例子。一个开发者用 vibe coding 的方式写了一整年的个人项目，写了可能有十几万行代码。有一天他想把一个模块重构一下——因为 AI 生成的那套架构在数据量大之后就慢得不行了。他发现自己完全改不动。不是 AI 写得太烂，是他已经没办法在脑子里建立那个模块的完整心智模型了。他不知道改了这一层，下面三层会不会炸。他也不知道那个看起来很蠢的实现到底是真的蠢，还是当年某个版本为了 pass 一个 edge case 故意写成那样的。

最后他又回到了 AI 面前，说"帮我把这个模块重构一下"。

这形成了一个闭环：AI 写代码 → 你读不懂 → 你更需要 AI 来改 → AI 继续写 → 你更读不懂。这个循环每转一圈，你对代码的掌控力就往下降一层。到最后，你变成一个项目管理 + prompt 工程师 + AI 代码质检员——唯独不再是那个"写代码的人"。

我不是在否定 AI 编程工具。Cursor 和 Claude Code 我现在自己也在用。它们极其强大，写样板代码、搭脚手架、对付那些你明明知道怎么写但懒得敲的东西，几乎没有对手。

我想说的是，这些工具在用得最顺手的时候，最危险。 因为它们太顺了，顺到你意识不到自己正在被替换的，不是你的手，是你的脑子。

那怎么办？说回到实操上。

我自己的做法是三条并行。

第一条：对于核心逻辑，强制手写。 不是全部代码，而是那些错了就会有真实后果的部分——数据处理的核心流程、权限判断、状态机。这些地方我不用 AI 帮我写第一稿，因为第一稿里藏着我对需求的全部理解。我可以让 AI 事后帮我 review，但不能让 AI 帮我"想第一遍"。一旦你想让别人替你想第一遍，你就在这件事上永远失去了你的判断基线。

第二条：花读代码的时间。 听起来很蠢，但真的很管用。每次 AI 生成一段代码，哪怕跑通了，我也花三到五分钟坐下来纯粹读一遍。不是校对，是真正读——理解它的结构、猜测它的设计动机、想象如果这个需求变了，我该改哪个点。三分钟不多，但它维持了你在"读代码"这件事上的神经连接。就像每天做五个引体向上，看起来什么都练不出来，但十年之后你跟不练的人不是一个物种。

第三条：定期手改 AI 的代码。 这个很多人不做。你不能只是"读"AI 的代码，你还要"改"它。哪怕是一个很简单的改动——换个变量名、抽一个函数、优化一个循环——只要你亲手动了这段代码，哪怕只动了三行，你对这段代码的所有权感就会回来。因为你不再是它的快递员，你是它的编辑。编辑和快递员的区别在于，编辑要对内容负责。

我有一个很简单的自检标准，你可以现在就用。打开你最近一个用 AI 写完的模块，随便找一段代码盖住，然后不看屏幕问自己两个问题：第一，这段代码最核心的逻辑是什么？第二，它最可能出 bug 的地方在哪？如果你两个问题都回答不上来——那你对这个模块的"熟悉"，其实是假的。你不是熟悉它，你是熟悉"它没出错"这个事实。

最后说一句可能不太中听的话。在 vibe coding 这个时代，一个开发者的核心竞争力，正在从"能写出代码"变成"能看懂代码"。因为 AI 正在让"写出来"这件事变得极其便宜——便宜到不值钱了。但"看得懂、判得准、改得动"，这些东西 AI 帮不了你。它只能帮你在表面上看起来像个优秀开发者，但你心里清楚你不是，因为你能感觉到那种松弛——那种你面对自己仓库时的陌生感，就是你的职业本能正在打瞌睡。

这不是在反对 AI。最好的状态不是拒绝它，也不是依赖它，而是保持你用人的方式阅读代码的肌肉，同时用好 AI 来放大你的执行速度。如果你能做到这一点，你就是一个读过自己每一行代码的开发者——在这个时代，这比你写了几万行，更能说明你是一个真正的程序员。

好，今天就聊到这里。龙虾头条，我们下次再见。

Shownotes

• 场景拆解：用 AI 写完代码两周后回头看，完全记不得自己提交过——你的大脑从未真正"拥有"这段代码
• 所有权脱节：从代码作者变成代码委托人，项目跑通但你不再觉得是自己的作品
• Bug 困境：AI 生成的代码没建立上下文，debug 变成接手别人的遗留项目——但 commit 记录上是你的名字
• Code Review 被架空：AI 写、AI 审、你点 approve——两个人类的判断力整个流程里从未真正出场
• 技能退化：用计算器十年不会心算，读 AI 代码一整年不会深度阅读——核对 ≠ 阅读
• 闭环陷阱：AI 写 → 读不懂 → 更需要 AI 改 → 更读不懂，每转一圈掌控力降一级
• 三条实操：核心逻辑强制手写、每天 3-5 分钟真正读代码、定期亲手改动 AI 的代码
• 自检标准：盖住代码，能说出核心逻辑和最可能出 bug 的地方吗？
• 核心判断：核心竞争力从"能写出代码"变成"能看懂代码"——写出来越来越便宜，看得懂、判得准、改得动，AI 帮不了你