AI 辅助编程让我成了自己代码库的「游客」

去年我构建了大量应用。我审过了大部分进入这些应用的代码和提交，但其中相当大的一部分我无法解释。

不是"没法向初级工程师解释"。是连我自己都解释不了。测试是绿的，diff 看起来像是我自己会写的风格，然后我就点了 approve。如果四十分钟后有人叫住我，问我为什么那个函数需要加锁，我就得重新读一遍，像是在读别人的代码。

某种程度上，确实是别人的代码。而且这些大多是我自己的项目，所以下游没有第二个审查者。我就是整个质量关卡——而这道关卡已经悄悄停止阅读了。

我不打算假装这是什么新鲜观察。如果你在 dev.to 上看过文章，你今年春天已经看过四篇这种帖子了；如果你是 r/ExperiencedDevs 的读者，你见过那个帖子——有人说自己是"自己代码库里的观光客"，然后四百个人说对，我也是。2025 年 Stack Overflow 调查中，五分之一的开发者选择"对自己的问题解决能力变得不那么自信"作为对 AI 工具的主要不满。这个担忧并不缺乏报道。它可能是目前软件行业被提及最多的感受。

所以这不是一篇诊断文章。诊断已经做完了。我到处都找不到的，是对接下来的问题的诚实回答：任何人提出的修复方案都有相同的形状，而这个形状已被证明会失效。包括我花了两个星期设计的那个方案。

这正是我想深入探讨的，然后我想问你一件事。

让我彻底想通这件事的框架来自航空业，已经有大约三十年了。

研究者在测试那些在手动飞行训练中成长、但随后职业生涯都在驾驶高度自动化飞机度过的航空公司飞行员时，发现了一个具体现象。程序性技能——扫描仪表、手动驾驶飞机——虽然生疏但基本完好。飞行员仍然能飞。

但认知技能才是真正崩塌的部分。维持对飞机实际位置的 awareness（态势感知）。追踪下一步应该是什么。识别和处理仪表故障。（这是 Casner 等人，2014 年的研究；FAA 的回应是建议飞行员在大多数飞行中手动驾驶。）

把你的工作代进去再读一遍。打字能力还在。你头脑中的模型才是消失的那个。

Macnamara 和同事在 2024 年的一篇综述中专门延伸到 AI 助手，并提出了比我敢说的更尖锐的论点：由于 AI 模仿的是认知工作而非机械工作，而且认知技能比身体技能衰减得更快，AI 引起的技能衰减应该比我们已经在驾驶舱中记录到的自动化衰减更严重。

这就是那个框架。问题不在于 AI 让你写代码变慢了。而在于 AI 非常擅长做那份曾经顺便帮助你建立判断力的工作，而判断力不会自己在存储中维持。

这很重要，因为看看现在的工作是什么样的。审查。捕捉 AI 自信但错了的那个东西。知道该做什么。判断何时可信的答案是错误的答案。每一项都属于认知列，而非程序列。我们已经自动化掉了那些产生唯一我们仍在被付费的技能的练习。

你感觉不到这正在发生

这是改变我思考整个问题方式的部分。有三个独立的研究发现都说同一件令人不安的事：你从结构上就无法自我评估这个问题。

一、Macnamara 的综述直接命名了这个机制。普通的技能衰减你会注意到，因为你停止做那个任务了。AI 引起的衰减是隐藏的，因为你没有停止做任务——你继续交付、继续审查、继续关闭工单。只有认知参与停止了。一个仍在完成成功手术的外科医生没有信号表明他的判断力已经软化。你也一样，面对一个绿色的 CI 徽章。

二、METR 在 2025 年进行了一项随机对照试验，十六名有经验的开源开发者在他们自己仓库的 246 个真实任务上——项目平均有五年他们自己的贡献。开发者预测 AI 会让他们快 24%。之后，他们估计自己快了约 20%。实际上他们慢了 19%。

仔细想想。不是"他们对工具判断错了"。他们对自己的体验判断错了，就在体验之后，就在他们比任何人都更熟悉的代码上。而且在他们的先验经验更高的任务上，速度下降更严重。无论你会用什么感知仪器来在自己身上检测这个问题，那项研究就是校准检查，而且它失败了。

三、Roediger 和 Karpicke（2006）的经典测试效应结果：重读材料的学生对自己记住它的信心评级比自测的学生更高——然后一周后回忆率是 40% 对比 61%。重读者平均读了 14.2 次。测试者只读了 3.4 次。重读感觉像在学习，但并不是。

一遍遍地读 diff 直到它看起来没问题是同样的操作。它建立了信心，却没有太多别的。

所以：衰减在结构上是不可见的，我们的自我报告被证明是反向的，而我们所有人使用的审查习惯恰好产生了记忆研究所警告的那种虚假信心。任何依赖注意到自己有问题才能生效的解决方案从一开始就是死的。

在继续读之前试试这个

两分钟，用你自己的代码。我真的很想知道会发生什么。

打开你最近一次由 AI 主导编写的提交或 PR。先不要读它。

在一个草稿文件中，写下它做了什么、为什么需要它、以及如果你删掉它会坏什么。

注意你在哪里卡住了。不是你是否"正确"——而是你在哪里卡住了。

这在认知科学中有一个名字：解释深度幻觉（Rozenblit & Keil, 2002）。人们对事物如何运作的理解评分很高，然后被要求产生一个实际的因果解释，随后就会大幅下调自己的评分。这个效应在解释性知识上比事实或程序知识强得多——这意味着它对代码审查所要求的那种认知是最强的。当机制就在你面前清晰可见时，效应也最强——这几乎是对阅读 diff 并感觉理解了它的一种残酷描述。

MIT 媒体实验室去年发现了这件事的一个版本：用 LLM 写文章的人在几分钟前刚完成文章后，很难引用自己写的东西。小样本研究，预印本，谨慎对待。但"我交付了这个却引用不了它"是我能认出的句子。

为什么我不打算建一个技能分数

我的第一反应是一个仪表盘。测量我。你的编码能力：73% 且在下降。一个数字，一条趋势线，足够的焦虑让我保持诚实。

在写任何代码之前我很高兴我读了习惯形成文献，因为那个想法是一个已知的失败模式。

CHI 2016 年的一项研究看了 Lift（后来的 Coach.me），那是那个时代最流行的习惯应用之一。连续记录和提醒确实推动了重复——那部分是有效的。但它们创造了一种依赖：行为绑定到了应用上而不是人身上。用户为连续记录而表演。然后不可避免地，他们停止打开应用——同一篇论文注意到了更广泛的模式，大约 74% 的用户在十次使用后就放弃了健康应用——行为也随之消失了。作者的表述是这些功能在本来应该让事情变得持久的东西上引入了脆弱性。

外部奖励挤出内部动机是古老的、被充分复现的心理学。一个技能分数就是那个陷阱戴上了一顶程序员的帽子：游戏化的焦虑。它告诉你你在下降，感觉很糟糕，这让你逃避这个工具，然后数字更糟。第二周你就卸载了它。

还有一个更干净的反对意见。分数测量的是输出。理解不是输出——它是一种能力，而观察能力的唯一方式是让人使用它。你无法报告理解。你只能展示它。

为什么常见的建议也不起作用

这是我期待人们反驳的部分，所以让我谨慎一点。

每篇关于这个话题的文章——包括那些好的——结尾都大致列了同样的清单：

先用十五分钟自己尝试

每天 20-30 分钟无辅助的问题解决

关闭工具，大声解释每一行

自己写架构

这些建议没有一条是错的。我认为所有这些都有效，当真正做到的话。但看看它的形状：每一个都是纪律形状的、计划好的、在工作流之外的。这是一个独立的练习，与时间竞争，靠意志力维持，没有提示，也没有跳过它的后果。

That is structurally the same object as the habit app. It's the pre-app version of the same object. And the reason to expect it to fail is the reason the article gave you in paragraph one: you're being asked to voluntarily add friction to fix a problem you cannot perceive yourself having, using time pressure as the counterweight, in an industry that measures you on what you shipped, never on whether you understood it.

这在结构上与那个习惯养成 app 是同一个对象。它是同一个对象在 app 出现之前的版本。预期它会失败的原因，文章第一段已经告诉你了：你被要求主动增加摩擦来修复一个你自己感知不到的问题，用时间压力作为平衡，在一个用你交付了什么来衡量你、而不是用你是否理解了这个东西来衡量你的行业里。

Also — the specific advice to "rotate AI-free days" is trying to solve skill decay with abstinence, and the research doesn't actually support that framing. Which brings me to the useful finding.

还有——"轮换无 AI 日"这个具体建议，试图用戒断来解决技能衰退问题，但研究实际上并不支持这个框架。这就引出了那个有用的发现。

The finding that changed the design

改变设计的那个发现

In January 2026 Anthropic published a randomized controlled trial (Shen & Tamkin) that is, as far as I can tell, the most directly relevant study that exists. 52 mostly-junior engineers learned Trio, an async Python library none of them knew. Half had an AI assistant; half had docs and web search.

2026 年 1 月，Anthropic 发表了一项随机对照试验（Shen & Tamkin），据我所知，这是目前存在的关系最直接的研究。52 名大多数是初级工程师的参与者学习了 Trio，一个他们谁都没接触过的 Python 异步库。一半有 AI 智能体辅助；一半只有文档和网页搜索。

The headline is grim and got all the coverage: the AI group scored 50% on the comprehension quiz versus 67% for the hand-coders — about two letter grades, on concepts they had used minutes earlier. The largest gap was on the debugging questions, which is the precise skill you need to catch bad AI output. The speed advantage was about two minutes and wasn't statistically significant. Same speed. Much less understanding.

标题很残酷，也获得了所有关注：AI 组的理解测验得分是 50%，而手写代码组是 67%——相差大约两个字母等级，涉及的是几分钟前他们刚刚使用过的概念。差距最大的是调试题，而这恰恰是发现 AI 错误输出所需的关键技能。速度优势大约是两分钟，且没有统计学意义。同样的速度，却差得多的理解。

But the finding nobody quotes is the one underneath it. The researchers identified six distinct interaction patterns, and three of them preserved learning even with full AI assistance. High scorers averaged 65–86%. Low scorers were under 40%. Same tool, same time budget, double the comprehension.

但没人引用的是标题下面的那个发现。研究人员识别出了六种不同的交互模式，其中三种在完整 AI 辅助的情况下仍然保留了学习效果。高分组平均 65–86%。低分组低于 40%。同样的工具，同样的时间预算，却有双倍的理解差距。

The three that worked all involved cognitive engagement at the moment of generation:

有效的三种模式都涉及在生成时刻的认知投入：

generate the code, then ask follow-up questions about it

生成代码，然后就代码提问后续问题

ask for code and an explanation together

同时请求代码和解释

ask conceptual questions, then write the code yourself

先问概念问题，然后自己写代码

The three that failed: delegate wholesale, drift into delegation over the session, or use the AI to iteratively fix things without ever understanding them. (Participants in that last group were also slower.)

无效的三种：全权委托、在对话过程中逐渐变成委托、或者用 AI 迭代修复问题但从不真正理解它们。（最后一组的参与者也更慢。）

So the variable is not how much AI you use. It's whether an act of retrieval or explanation happens at the point of use. That's a much smaller intervention than "no-AI Fridays," and unlike willpower, it's the kind of thing software can put in front of you at the right moment.

所以变量不是你用了多少 AI。而是在使用时刻是否发生了提取或解释的行为。这比"无 AI 周五"小得多的干预，而且与意志力不同，这是软件可以在恰当的时刻呈现在你面前的东西。

Microsoft Research and CMU landed in the same place from a different direction at CHI 2025. Surveying 319 knowledge workers across 936 real AI-assisted tasks, they found higher confidence in the AI predicted less critical thinking, while higher confidence in your own ability predicted more. Their design recommendation was for tools that use "proactive prompts" and act as a provocateur rather than an answer machine.

微软研究院和卡内基梅隆大学在 CHI 2025 上从不同方向得出了相同结论。他们调查了 319 名知识工作者在 936 个真实 AI 辅助任务中的表现，发现对 AI 越有信心，就越少进行批判性思考，而对自己能力越有信心，就越多。他们的设计建议是使用"主动提示"的工具，扮演挑衅者而不是答题机器。

I read that and realized the intervention I wanted had already been specified by people with better data than me. Nobody had built it into the place where the work actually happens.

我读到这里，意识到我想要的干预已经被拥有比我更好数据的人定义过了。没有人把它构建到实际工作发生的地方。

Not a score. Not an app. A review-time forcing function — something in the hook or MCP layer between the agent and the merge, where I already am.

不是分数，不是 app。是一个审查时的强制函数——在智能体和合并之间的 hook 层或 MCP 层里，在我已经在的地方。

The agent drafts a change. Before I can rubber-stamp it, it asks me one question:

智能体起草了一个变更。在我能够草率通过之前，它问我一个问题：

What does this change do?

这个变更做了什么？

What breaks if we remove it?

如果去掉它会坏什么？

Where's the edge case this misses?

它漏掉了哪个边界情况？

Then it does the part that makes it more than a journaling prompt: it compares my answer to the actual diff and shows me where my model diverged. Over time the signal isn't a vibe, it's a record — did my explanation match the code? Did I flag the thing that later broke? That's review accuracy and bug-catch rate, which are evidence, not a self-report.

然后它做了让这个不只是日志提示的部分：它把我的回答与实际的 diff 对比，并显示我的认知模型在哪里出现了分歧。随着时间推移，信号不是一种感觉，而是一条记录——我的解释与代码匹配吗？我标记了后来坏掉的那个东西吗？这是审查准确率和 bug 发现率，是证据而不是自我报告。

Design constraints, all of them derived from something above rather than from taste:

设计约束，全部从上文推导而来，而不是从个人偏好：

In-workflow, not an app. Out-of-workflow practices are the failure mode of the entire genre.

在工作流内，不是 app。工作流外的实践是整个类型的失败模式。

One question, ~20 seconds. Anything longer loses to delivery pressure, which is the honest reason none of us do the 20-minute practice.

一个问题，大约 20 秒。任何再长都会败给交付压力，这是我们谁都不做那 20 分钟练习的真实原因。

No score, no streak, no dashboard. Lift, and everything downstream of Lift.

没有分数，没有连续天数，没有仪表盘。Lift，以及 Lift 之后的一切。

Explanation-shaped, not recall-shaped. The illusion of explanatory depth is where the gap is largest; quizzing trivia would miss it.

解释形的，不是回忆形的。解释深度幻觉是差距最大的地方；考 trivia 会错过它。

Retrieval before review, not after. Roediger & Karpicke — you have to attempt the answer before seeing the material, or you've just re-read the diff with extra steps.

审查前提取，不是审查后。Roediger & Karpicke——你必须在看到材料之前尝试回答，否则你只是用额外步骤重新读了一遍 diff。

The adjacent shape I keep sketching is spaced repetition over your own codebase — Anki for the repo. "Why does this function exist?" "What would break if you deleted it?" I think it's weaker: it's out-of-workflow again, and it drifts toward recall when the thing that matters is explanation.

我一直在画的相邻形态是对你自己的代码库进行间隔重复——Anki for the repo。"为什么这个函数存在？""如果你删掉它会坏什么？"我认为这更弱：它又是工作流外的，而且漂向回忆而偏离了重要的解释。

Where I think this might be wrong

我认为这里可能错的地方

Three real holes, and I'd rather name them than get talked out of them in the comments.

三个真实的漏洞，我宁愿在这里指出，而不是在评论里被人说服。

It might become another rubber stamp. Anything mandatory gets gamed. I'd type "makes the retry idempotent" seventeen times a day without thinking. Every forced-friction tool ever built has hit this wall, and I don't have a good answer beyond "vary the question and only fire on non-trivial diffs," which is a hope, not a design.

它可能变成另一个橡皮图章。任何强制的东西都会被应付。我会不假思索地每天打十七次"makes the retry idempotent"。每个强制摩擦工具都撞过这堵墙，我没有好的答案，除了"变换问题且只在非平凡 diff 时触发"，这是一个希望，不是设计。

Something has to grade the explanation, and that something is an AI. Which means I'd be offloading the assessment of whether I understood something to the same class of system whose output I stopped understanding. I think this is survivable — comparing my prose against a diff is a much narrower task than generating the diff — but I notice the shape of it, and it bothers me.

必须有东西来评判解释，而那个东西是 AI。这意味着我要把我是否理解了某事的评估外包给同一类系统，它的输出我已经不再理解了。我认为这是可以幸存下来的——把我的文字与 diff 对比比生成 diff 要窄得多的任务——但我注意到了它的形态，它困扰着我。

The friction lands in the wrong place. 66% of developers say their top AI frustration is code that's "almost right, but not quite," and 45% say debugging AI output already takes longer than writing it themselves. Those people are not short on friction. Adding a question to their review might be adding a tax to the exact step that's already the expensive one.

摩擦落在了错误的地方。66% 的开发者说他们最大的 AI 烦恼是"几乎对但不完全对"的代码，45% 说调试 AI 输出已经比他们自己写还慢。那些人并不缺摩擦。给他们审查加一个问题可能是在已经昂贵的步骤上再加税。

I'm asking because I have a rule against starting things right now — one flagship for 90 days, everything else goes in a parking lot file. This idea is in the parking lot. It comes out only if the reaction here says it should, so this is a real question with a real consequence, not a call to action.

我问是因为我有个规则反对现在就开始做事——90 天一个旗舰项目，其他都进待办文件。这个想法在待办里。只有这里的反响说它应该出来它才会出来，所以这是一个有真实后果的真实问题，不是行动号召。

Three things, and short answers are genuinely more useful than long ones:

三件事，简短回答真的比长回答更有用：

Did you run the two-minute test above? What happened — did you stall, or was it fine? Just say "stalled" or "fine" if that's all you've got. I especially want to hear "fine," because if most people are fine then I've written 1,800 words about my own bad habits.

你跑了上面的两分钟测试吗？发生了什么——你卡住了，还是没问题？如果你只会说"卡住了"或"没问题"就只说这个。我特别想听"没问题"，因为如果大多数人都没问题，那我就写了 1800 个字关于我自己的坏习惯。

What's your actual anti-atrophy practice — not the one you'd recommend, the one you did this week?

你实际的防衰退实践是什么——不是你会推荐的那个，是你这周做了的那个？

Would you install this? And if you think it's a bad idea, say so plainly. "This would annoy me into uninstalling it in a day" is the most useful comment I could get, and it costs you one line.

你会安装这个吗？如果你觉得这是个坏主意，坦白说出来。"这会烦到我一天内卸载它"是我能收到的最有用的评论，而且只花你一行字。

I've been assuming that because I can feel the erosion, a tool should exist. The research above says pretty clearly that my feelings about my own competence are not evidence. Yours might be worth more than mine.

我一直假设因为我能感觉到侵蚀，所以应该存在一个工具。上面的研究相当清楚地表明我对自己能力的感觉不是证据。你的可能比我的更有价值。

Sources, if you want to check my work: METR RCT (2025) · Shen & Tamkin, Anthropic (2026) · Macnamara et al., Cognitive Research (2024) · Lee et al., CHI 2025 (PDF) · "Don't Kick the Habit," CHI 2016 · Roediger & Karpicke (2006) · Rozenblit & Keil (2002) · Stack Overflow Developer Survey 2025

参考来源，如果你想核查我的工作：METR RCT (2025) · Shen & Tamkin, Anthropic (2026) · Macnamara et al., Cognitive Research (2024) · Lee et al., CHI 2025 (PDF) · "Don't Kick the Habit," CHI 2016 · Roediger & Karpicke (2006) · Rozenblit & Keil (2002) · Stack Overflow Developer Survey 2025

For further actions, you may consider blocking this person and/or reporting abuse

如需进一步行动，你可以考虑屏蔽此人或举报滥用