用 AI 写代码越久，我越怕自己“手生”

  created  by  鱼鱼 {{tag}}
创建于 2026年10月08日 17:25:48 最后修改于 2026年10月08日 18:37:21
知识共享许可协议 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了。不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿。以前这些东西是肌肉记忆，现在得想一想。

我第一次意识到这件事的时候，心里咯噔了一下。倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑。我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来。

这篇文章不打算劝谁少用 AI。我自己每天都在用，而且用得挺开心。我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法。说是办法，其实也就是一些习惯，不一定对，供参考。

钢琴琴键上的一双手

图片来源：chocolatedazzles (Mic JohnsonLP) / Flickr（CC BY 2.0）

这不全是错觉

我一开始也以为是自己想多了。后来翻到两个研究，读完心情有点复杂。

第一个是 METR 在 2025 年 7 月发的随机对照实验。他们找了 16 位有经验的开源开发者，在自己长期维护的大型仓库里完成 246 个真实任务，每个任务随机决定能不能用 AI。结果是：允许用 AI 的任务，完成时间反而长了 19%。更有意思的是，这些开发者事前预计 AI 能让自己快 24%，做完之后还觉得自己快了 20%。

慢了，但感觉快了。这个落差比“慢了”本身更让我在意。

第二个是 Anthropic 在 2026 年 1 月发布的研究。52 位（大多是初级的）开发者学习一个没用过的 Python 异步库 Trio，一组可以用 AI 助手，一组纯手写，做完任务马上考一次试。AI 组平均分 50%，手写组 67%，差距最大的是调试类题目。完成速度上，AI 组只快了两分钟左右，而且统计上不显著。

当然，这两个研究都有边界。METR 的样本小，用的是 2025 年初的工具，今天的模型和工具已经不是一个水平了；Anthropic 那个测的是刚做完任务时的理解程度，不是长期能力。不能拿它们去证明“AI 让人变笨”。

但它们至少说明了一件事：“用 AI 更快”和“用 AI 学得更好”是两回事，而且我们对自己效率的感觉并不可靠。

Anthropic 那篇里还有一个细节我很喜欢：同样是用 AI，有些人是把整个任务丢给它，有些人是拿它问概念、问“为什么这样写”。后者的测验成绩明显更好。问题不在 AI，在于你把哪一部分思考交了出去。

“手生”到底是哪里生了

我仔细回想了一下，自己卡住的地方其实很少是语法。语法这东西，查一下就有，忘了也不丢人。真正退化的，是下面这几样：

能力 退化后的样子 可以问自己的问题
读代码的耐心 看 diff 只扫一眼，觉得“大概没问题”就合并 这段代码我能不能讲给同事听？
调试时提出假设 一报错就把堆栈整个丢给 AI，等它猜 在问 AI 之前，我心里有没有一个怀疑对象？
系统的心智模型 说不清一个请求从入口到数据库经过了哪些层 不看代码，我能不能画出这条链路？
对“不对劲”的直觉 AI 写得很顺，就默认它是对的 这段代码里，哪一行最可能出错？

你会发现，这些能力恰好就是审查 AI 输出时最需要的东西。这就有点讽刺了：AI 越能干，我们越需要有能力判断它干得对不对；而越依赖它，这个判断力反而越容易被磨掉。

我自己也有过这种状态：看 AI 改的代码，眼睛在动，脑子没动。编译过了，测试绿了，就点合并。这种时候最容易漏掉的，往往是那种“看起来更稳妥”的改动，比如把一个本该抛出去的异常吞掉，换成返回空列表。测试之所以是绿的，常常只是因为测试本来就没覆盖那条路径。说大不大，但想想挺后怕的。

我现在的几个习惯

下面这些都不是什么方法论，是我试过、觉得有点用、还在坚持的做法。

1. 先猜，再问

遇到 bug 或者设计问题，我会先在便签里写一句自己的猜测，哪怕只有一行，比如“我怀疑是缓存没失效”。然后再去问 AI。

AI 的答案和我的猜测一致，我会多一点信心；不一致，我就得想清楚是谁错了。这个过程很短，但它逼着我在把问题交出去之前，先动一下脑子。时间长了你会发现，自己猜中的比例在慢慢变高，这种感觉挺好的。

2. 学新东西的时候，让 AI 当老师而不是代笔

学一个新框架、新库的时候，我会刻意换一种问法：不是“帮我写一个 XXX”，而是“我想实现 XXX，先别给代码，告诉我需要理解哪几个概念”，或者“我写了一版，你帮我指出问题，但别直接改”。

现在不少工具也在往这个方向做，比如 Claude Code 有偏解释、偏教学的输出风格，ChatGPT 也有学习模式。具体叫什么、在哪打开，各家更新太快，大家自己找一下就好。我想说的是，同一个工具，用法不同，留在你脑子里的东西完全不同。

在笔记本上手写笔记

图片来源：Image Catalog / Flickr（CC0 1.0）

3. 调试的前十分钟留给自己

这条我执行得最不稳定，但效果最明显。线上不着急的 bug，我会给自己十分钟：看日志、看堆栈、加两行打印，试着自己定位。十分钟内搞定最好；搞不定，再把我已经排除的方向一起告诉 AI。

后一种情况其实也有好处：你给 AI 的上下文质量高了很多，它的回答也会准很多。比起直接丢一句“报错了，帮我看看”，这种提问方式省下的往返次数，基本能把那十分钟赚回来。

4. 要合并的每一行，都得能讲出来

这是给自己定的底线：AI 写的代码，只要是我要提交的，我就得能逐段讲清楚它在干什么。讲不清的地方，要么让 AI 解释，要么自己改写成我看得懂的样子。

听起来很慢，但实际执行下来，大部分代码一眼就能看懂，真正需要停下来的往往就那么几处。而这几处，恰恰是最可能出问题的地方。

5. 偶尔“断网”练一练

我会时不时挑一个小题目，比如实现一个 LRU 缓存、写一个简单的限流器、手撸一个 JSON 解析的小片段，关掉补全和对话，自己写完。不追求快，就当是练琴时弹弹音阶。

弹钢琴的人都知道，有自动伴奏的电子琴弹起来很爽，但音阶和指法练习不能停，不然哪天让你脱离伴奏弹一首曲子，手指就不听话了。写代码大概也是这个道理。

6. 给 AI 记一本“错题本”

AI 说错的地方，我会顺手记下来：编造的 API、过时的写法、看起来对但边界有问题的逻辑。记着记着，你会对它“容易在哪儿犯错”形成直觉，审查的时候就知道重点看哪里。

错题本还有个副作用：里面的一部分内容，可以直接整理进项目里给 AI 看的说明文件，让它下次别再犯。具体怎么写，我在今天另一篇《给仓库写一份 AGENTS.md》里细说。

哪些可以放心交出去，哪些要攥在手里

说了这么多，好像我很防着 AI。其实没有，我的态度是分区对待：

可以放心交给 AI 我会自己把关、甚至自己写
样板代码、DTO、getter/setter 核心业务规则和状态流转
一次性脚本、数据格式转换 并发、锁、事务边界
单元测试的初稿 权限校验、鉴权逻辑
正则、SQL 的初稿（但要验证） 数据迁移、删除类操作
文档、注释、提交说明 对外接口的契约设计

左边那一栏，就算 AI 写错了，代价也不高，而且通常很快能发现。右边那一栏，错了往往要很久才暴露，暴露的时候已经很疼了。

这个划分不是一成不变的。随着工具变强、你对它越来越了解，左边会慢慢变长。但我觉得右边那栏永远不会空，至少在可以预见的未来不会。

一点还没想明白的事

说实话，我对这个问题还没有特别确定的答案。有时候我也会怀疑，是不是自己太保守了：也许就像当年有了 IDE 自动补全、有了搜索引擎，大家也担心过“程序员会不会退化”，最后不也挺好的吗？

可能吧。但我还是愿意多留一点余地。工具可以换，模型可以升级，能看出“哪里不对劲”的那双眼睛，只能靠自己养。

如果你也有过那种“对着空白文件卡住”的时刻，不用太焦虑，也别装没发生。挑一两条上面的习惯试试，过一个月回头看看，说不定会有点不一样。

参考资料：

评论区
评论
{{comment.creator}}
 {{comment.createTime}} {{comment.index}}楼
评论

用 AI 写代码越久，我越怕自己“手生”

用 AI 写代码越久，我越怕自己“手生”

先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了。不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿。以前这些东西是肌肉记忆，现在得想一想。

我第一次意识到这件事的时候，心里咯噔了一下。倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑。我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来。

这篇文章不打算劝谁少用 AI。我自己每天都在用，而且用得挺开心。我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法。说是办法，其实也就是一些习惯，不一定对，供参考。

钢琴琴键上的一双手

图片来源：chocolatedazzles (Mic JohnsonLP) / Flickr（CC BY 2.0）

这不全是错觉

我一开始也以为是自己想多了。后来翻到两个研究，读完心情有点复杂。

第一个是 METR 在 2025 年 7 月发的随机对照实验。他们找了 16 位有经验的开源开发者，在自己长期维护的大型仓库里完成 246 个真实任务，每个任务随机决定能不能用 AI。结果是：允许用 AI 的任务，完成时间反而长了 19%。更有意思的是，这些开发者事前预计 AI 能让自己快 24%，做完之后还觉得自己快了 20%。

慢了，但感觉快了。这个落差比“慢了”本身更让我在意。

第二个是 Anthropic 在 2026 年 1 月发布的研究。52 位（大多是初级的）开发者学习一个没用过的 Python 异步库 Trio，一组可以用 AI 助手，一组纯手写，做完任务马上考一次试。AI 组平均分 50%，手写组 67%，差距最大的是调试类题目。完成速度上，AI 组只快了两分钟左右，而且统计上不显著。

当然，这两个研究都有边界。METR 的样本小，用的是 2025 年初的工具，今天的模型和工具已经不是一个水平了；Anthropic 那个测的是刚做完任务时的理解程度，不是长期能力。不能拿它们去证明“AI 让人变笨”。

但它们至少说明了一件事：“用 AI 更快”和“用 AI 学得更好”是两回事，而且我们对自己效率的感觉并不可靠。

Anthropic 那篇里还有一个细节我很喜欢：同样是用 AI，有些人是把整个任务丢给它，有些人是拿它问概念、问“为什么这样写”。后者的测验成绩明显更好。问题不在 AI，在于你把哪一部分思考交了出去。

“手生”到底是哪里生了

我仔细回想了一下，自己卡住的地方其实很少是语法。语法这东西，查一下就有，忘了也不丢人。真正退化的，是下面这几样：

能力 退化后的样子 可以问自己的问题
读代码的耐心 看 diff 只扫一眼，觉得“大概没问题”就合并 这段代码我能不能讲给同事听？
调试时提出假设 一报错就把堆栈整个丢给 AI，等它猜 在问 AI 之前，我心里有没有一个怀疑对象？
系统的心智模型 说不清一个请求从入口到数据库经过了哪些层 不看代码，我能不能画出这条链路？
对“不对劲”的直觉 AI 写得很顺，就默认它是对的 这段代码里，哪一行最可能出错？

你会发现，这些能力恰好就是审查 AI 输出时最需要的东西。这就有点讽刺了：AI 越能干，我们越需要有能力判断它干得对不对；而越依赖它，这个判断力反而越容易被磨掉。

我自己也有过这种状态：看 AI 改的代码，眼睛在动，脑子没动。编译过了，测试绿了，就点合并。这种时候最容易漏掉的，往往是那种“看起来更稳妥”的改动，比如把一个本该抛出去的异常吞掉，换成返回空列表。测试之所以是绿的，常常只是因为测试本来就没覆盖那条路径。说大不大，但想想挺后怕的。

我现在的几个习惯

下面这些都不是什么方法论，是我试过、觉得有点用、还在坚持的做法。

1. 先猜，再问

遇到 bug 或者设计问题，我会先在便签里写一句自己的猜测，哪怕只有一行，比如“我怀疑是缓存没失效”。然后再去问 AI。

AI 的答案和我的猜测一致，我会多一点信心；不一致，我就得想清楚是谁错了。这个过程很短，但它逼着我在把问题交出去之前，先动一下脑子。时间长了你会发现，自己猜中的比例在慢慢变高，这种感觉挺好的。

2. 学新东西的时候，让 AI 当老师而不是代笔

学一个新框架、新库的时候，我会刻意换一种问法：不是“帮我写一个 XXX”，而是“我想实现 XXX，先别给代码，告诉我需要理解哪几个概念”，或者“我写了一版，你帮我指出问题，但别直接改”。

现在不少工具也在往这个方向做，比如 Claude Code 有偏解释、偏教学的输出风格，ChatGPT 也有学习模式。具体叫什么、在哪打开，各家更新太快，大家自己找一下就好。我想说的是，同一个工具，用法不同，留在你脑子里的东西完全不同。

在笔记本上手写笔记

图片来源：Image Catalog / Flickr（CC0 1.0）

3. 调试的前十分钟留给自己

这条我执行得最不稳定，但效果最明显。线上不着急的 bug，我会给自己十分钟：看日志、看堆栈、加两行打印，试着自己定位。十分钟内搞定最好；搞不定，再把我已经排除的方向一起告诉 AI。

后一种情况其实也有好处：你给 AI 的上下文质量高了很多，它的回答也会准很多。比起直接丢一句“报错了，帮我看看”，这种提问方式省下的往返次数，基本能把那十分钟赚回来。

4. 要合并的每一行，都得能讲出来

这是给自己定的底线：AI 写的代码，只要是我要提交的，我就得能逐段讲清楚它在干什么。讲不清的地方，要么让 AI 解释，要么自己改写成我看得懂的样子。

听起来很慢，但实际执行下来，大部分代码一眼就能看懂，真正需要停下来的往往就那么几处。而这几处，恰恰是最可能出问题的地方。

5. 偶尔“断网”练一练

我会时不时挑一个小题目，比如实现一个 LRU 缓存、写一个简单的限流器、手撸一个 JSON 解析的小片段，关掉补全和对话，自己写完。不追求快，就当是练琴时弹弹音阶。

弹钢琴的人都知道，有自动伴奏的电子琴弹起来很爽，但音阶和指法练习不能停，不然哪天让你脱离伴奏弹一首曲子，手指就不听话了。写代码大概也是这个道理。

6. 给 AI 记一本“错题本”

AI 说错的地方，我会顺手记下来：编造的 API、过时的写法、看起来对但边界有问题的逻辑。记着记着，你会对它“容易在哪儿犯错”形成直觉，审查的时候就知道重点看哪里。

错题本还有个副作用：里面的一部分内容，可以直接整理进项目里给 AI 看的说明文件，让它下次别再犯。具体怎么写，我在今天另一篇《给仓库写一份 AGENTS.md》里细说。

哪些可以放心交出去，哪些要攥在手里

说了这么多，好像我很防着 AI。其实没有，我的态度是分区对待：

可以放心交给 AI 我会自己把关、甚至自己写
样板代码、DTO、getter/setter 核心业务规则和状态流转
一次性脚本、数据格式转换 并发、锁、事务边界
单元测试的初稿 权限校验、鉴权逻辑
正则、SQL 的初稿（但要验证） 数据迁移、删除类操作
文档、注释、提交说明 对外接口的契约设计

左边那一栏，就算 AI 写错了，代价也不高，而且通常很快能发现。右边那一栏，错了往往要很久才暴露，暴露的时候已经很疼了。

这个划分不是一成不变的。随着工具变强、你对它越来越了解，左边会慢慢变长。但我觉得右边那栏永远不会空，至少在可以预见的未来不会。

一点还没想明白的事

说实话，我对这个问题还没有特别确定的答案。有时候我也会怀疑，是不是自己太保守了：也许就像当年有了 IDE 自动补全、有了搜索引擎，大家也担心过“程序员会不会退化”，最后不也挺好的吗？

可能吧。但我还是愿意多留一点余地。工具可以换，模型可以升级，能看出“哪里不对劲”的那双眼睛，只能靠自己养。

如果你也有过那种“对着空白文件卡住”的时刻，不用太焦虑，也别装没发生。挑一两条上面的习惯试试，过一个月回头看看，说不定会有点不一样。

参考资料：


用 AI 写代码越久，我越怕自己“手生”2026-10-08鱼鱼

{{commentTitle}}

评论   ctrl+Enter 发送评论