还记得吗，那时候用自动补全就意味着你并不是在“真正”编程？
一个真实的Stack Overflow 问题来自将近 15 年前。人们真的在怀疑自动补全是不是错的。
现在看看我们。
很长一段时间里，我有一个非常简单的方法来衡量自己是否在成为更好的开发者：
我自己能写多少代码？
- 我能记住语法吗？
- 我能在不查任何东西的情况下构建这个组件吗？
- 我能在不求助于人的情况下解决这个 bug 吗？
- 我能盯着一个空白文件，完全凭记忆把它变成软件吗？
我觉得很多自学成才的开发者都吸收了这种观念的某个版本：
- 如果你需要 Stack Overflow，你就是在作弊。（与此同时，我们中有一半人把它固定在标签页里。）
- 如果你需要查文档，说明你并没有真正掌握它。
- 如果你太频繁地使用自动补全，你就是在变懒。
而现在，在 AI 时代：
如果代码是模型写的，那你真的构建了任何东西吗？
我以前对这个问题担忧的程度，超过了我愿意承认的。
我不再这样了。
在构建了更多软件、弄坏了更多软件、调试了更多软件，并维护了那些五分钟前看起来还完全正常的代码之后，我开始用非常不同的方式衡量自己的能力。
问题不是：
我个人敲了多少行代码？
问题是：
- 我理解这个系统在做什么吗？
- 我能识别出它什么时候出错吗？
- 当顺利路径消失时，我能调试它吗？
- 我能解释为什么架构是现在这个样子吗？
- 我能在不破坏三个不相关功能的情况下修改它吗？
- 我下个月能维护它吗？
- 我愿意为结果负责吗？
这些问题最终被证明要比敲代码难得多。
代码生成现在是简单的部分
这就是 2026 年编程的奇怪之处。
你可以描述一个想法，几乎瞬间就能得到数百行看起来合理的代码。有时这些代码甚至能运行。最初几次，这感觉像魔法。
然后你构建了一些复杂的东西。突然之间，模型会：
- 修好一个 bug，又制造出另一个
- 重复其他地方已经存在的逻辑
- 自信地误解你的架构
- 通过了测试，却违反了实际需求
- 添加你从未要求的抽象
- 移除你并未意识到依赖于其他东西的行为
- 解决的是你描述的问题，而不是你实际遇到的问题
然后你意识到一件重要的事。
生成代码从来都不是工作的全部。它只是最显眼的那部分。
最难的技能变成了判断什么时候出了问题
AI 实际上让我花了更多时间思考软件。不一定是敲软件。而是思考它。
当一个智能体产出一份实现时，我必须问：
- 它为什么选择这种做法？
- 这个该放在这里吗？
- 这个状态归正确的组件所有吗？
- 我们是在修复根因还是在掩盖症状？
- 当它失败时会发生什么？
- 当它运行两次时会发生什么？
- 当用户做了完全不讲理的事情时会发生什么？
- 这份实现和代码库的其余部分一致吗？
以及我个人最喜欢的：
它为什么能跑通？
最后一个问题很重要，因为能跑的代码和你理解的代码不是一回事。
我不希望我的项目里有那种像是神谕递给我的神秘造物一样的软件。如果我解释不了它，我就还不信任它。
调试改变了我对作者身份的看法
写代码感觉很有产出。调试则教会你，你是否真正理解了自己构建的东西。
这两者之间有很大区别：
“AI 创建了这个功能。”
以及：
“AI 创建了一份初始实现，我发现了状态为什么会在组件之间泄漏，追踪了回归，修改了所有权模型，测试了边界情况，并验证了修复。”
第二种经历让你对系统了解得多得多。
而在某个时刻我意识到：那也是编程。也许更重要的是，那是工程。
作者身份不只是按下产生字符的按键。
- 它是做决策。
- 它是理解后果。
- 它是拒绝糟糕的做法。
- 它是决定什么该留下。
我曾以为需要帮助就意味着我不够好
自学成才可能会制造出一种奇怪的不安全感。
总有一个你不知道的概念。总有一个更懂网络的开发者。总有一个能面不改色解释内存管理的人。总有一个仓库，里面每个文件看起来都像是用外星语言写的。
于是你开始把独立当作能力的证明。
“如果我能不靠帮助做到这件事，那我一定真的属于这里。”
AI 直接戳中了那种不安全感。因为现在帮助永远都在。而且它能做很多事。
我不得不停止追问使用帮助是否让我的技能失效。开发者一直都在使用工具：
- 文档是工具。
- 库是工具。
- 框架是工具。
- 编译器是工具。
- 搜索引擎是工具。
- IDE 是工具。
AI 是另一个极其强大的工具。
有趣的问题不是这个工具是否参与其中。有趣的问题是当这个工具出错时会发生什么。
AI 生成代码的速度比我理解它的速度还快
这大概是我发现的最大危险。
生成速度很诱人。你添加功能的速度可以快过你为它们建立心智模型的速度。
一个提示变成三个文件。另一个提示变成一个抽象层。再一个提示悄悄改动了某个你并不知道是承重结构的东西。
然后有一天某个东西坏了，而你站在一个名义上属于你、却无法向任何人解释——包括你自己——的代码库里。
这就是陷阱。过去的瓶颈是我写代码的速度。现在是理解代码的速度，而工具不会慢下来等我。
所以我不得不养成几个习惯：
- 在接受 diff 之前先读它。全部读完。
- 让模型解释它的选择，然后检查这个解释是否真的和代码相符。
- 让改动小到我能装进脑子里。
- 测试不合理的情况，而不只是顺利路径。
- 如果我无法解释它为什么能工作，它就不上线。
这些习惯没有一个和打字有关。全都和理解有关。
我现在用的记分牌
我不再数行数了。我问自己是否理解我交付的东西，是否能在它坏掉时修好它，以及我是否愿意为它背书。
而下面这件事让我确信旧的记分牌是错的。
我的 GitHub 账号已经超过十年了。
其中很长一段时间，它很安静。我经历过职业中断。我换过方向。生活做了生活该做的事。
然而在过去一年里，我创建和维护的项目比那十年加起来还多。
我不认为这是巧合。
我不是说这些工具替我写好了作品集。仍然得有人决定要做什么、调试它、发布它，并让它持续运行。但过去那套衡量标准，我能仅凭记忆、独自一人、从一个空白文件开始做出这一切吗？，一直在悄悄阻止我把事情做完。
一旦我不再用它，我就开始动手构建了。