留一个地方给自己“古法”编程吧
本文无 AI 辅助创作，请放心食用。
我看了一下自己最近纯手工编程的项目，是开源仓库 Noteman，最近更新时间是 Mar 29, 2025，距今一年多。而真正还在大规模手搓代码，大概是在 2023 年之前。
——对上了，22 年 11 月 30 日，OpenAI 发布 ChatGPT3.5，自那以后，无论是让 AI 生成之后我再 Copy（大约是在 2023~2025，基本用的是免费的 GPT 和 Gemini Pro 2.5），还是转向纯 Coding Harness（最近两年是诸如 Claude Code 或是 Codex CLI），我再也没有完全手搓代码了。哪怕是去年自己曾经一些极其复杂逻辑，AI 自己理解不了也给不了太好方案的情况下，也依然是让 AI 生成了部分相对不动脑的代码。
然后最近接触了一些刚毕业的校友，我发现他们几乎四年来从来没有自己完整手写地做完过任何一个编程作业——而他们的独立编程能力也十分堪忧。基本上可以说沦为了传话筒，没有 AI 就丧失工作能力只能发呆。他们可以面不改色地面对 AI 写出来的质量非常糟糕的代码，因为他们完全看不出来有任何问题。他们也几乎从未认真了解过 Clean Code 等原则，当我提到 SRP、OCP 时他们往往觉得这些东西过时了，或者应该封装成 Skill 然后就万事大吉了。
例如有个人长期把 Git、Docker 之类操作全部交给 AI，虽然不会手打命令（哪怕切出分支都不记得怎么做），但他们觉得自己已经掌握了 Git 和 Docker。然而据我观察他们并未如我们前 AI 时代的人那样建立了良好的心智模型，一旦遇到一些复杂的局面就只能全权交给 AI 但无法理解，就如一个产品经理遇到 AI 生成的前端代码报错那般。
所以，我想发表一个暴论，AI 时代，每个程序员一定要留一个完全手写的项目。
对老手而言，意义在于能对冲能力退化的风险，在 AI 作用受限时维持技术接管能力。毕竟依然不存在能理解如项目负责人那般周全的上下文的 AI，这块再聪明也没用。依然会有许多情况 AI 跑偏了，或者环境确实受限，或者极端点出现一段完全无法使用 AI 的时期，那么依然能够亲自进入系统解决问题，是你作为 Senior 的实力的证明。
对新手而言，长期来看，在不断设计、反思中手写代码，可能反而是更高效的训练。甚至可以说，保留一点手搓代码，是走向资深工程师的捷径，因为你的多数竞争者已经完全交给 AI 了。而他们享受不到手搓代码带来的一些意外的好处。
是的，手搓代码其实是有一些好处的！因为手搓代码可以迫使你频繁地在最细节的层面，做出有意义的决策。
举个例子，我最近也开始手搓一个迷你的 RTOS 叫 MiniRT。里面就涉及到大量的决策细节，比如亲手设计 Task 结构的时候，你必须思考哪些字段是最重要和最必要的（例如栈指针、任务状态等字段）。如果交给 AI，基本上大家会看 AI 的方案 Sounds good 就觉得 OK 了，然后不知不觉设计已经变得相当复杂，而你实际上不太清楚他是怎么演化到这样的复杂地步的，心里对整套系统也没有清晰的图景——哪怕你已经 review 了每个 PR。因为 Review 的时候往往你也是觉得看起来合并，就准了。然而不知不觉系统已经被 AI 写成屎山，甚至出错，这个时候才回过头来看设计，智商再高也会有种云里雾里的感觉。
所以手写的价值就是让你不得不仔细斟酌每个设计决定。这种过程是相当锻炼人的，任何经历过无 AI 时代，靠查 CSDN、Stack Overflow、翻书甚至翻论文来手搓代码的人都能理解我刚刚说这些意味着什么。
所以我建议大家尤其是新人一定要体验一下手搓代码，最好能给自己一块自留地可以长期手搓，如果是和现实业务相关就更好（玩具项目毕竟复杂度还是远不及现实），在这个过程中积累一手的编码设计决策经验，会让你非常快速地成长。哪怕今后 Review 代码和指挥 AI 重构，也会不容易被忽悠。
这和一些传统企业要求高级经理必须从基层做起是一样的，如果没有亲自做过，就很容易缺乏一些不可言说的判断力，被手下的 Agents 忽悠，总之，你写代码就会产生类似外行领导内行的奇妙场景。
而且编程的情绪体验也是很重要的一部分。和 AI 协作编程时，我的基本流程是先出 Design Doc（类似于战略），再出 Implement Guide（类似于战术），最后让 Agents 去施工。这个过程中我约等于 CTO，倒是很锻炼人的架构能力——我会让 AI 反复地拷问我，确保大方向上没有任何歧义和差错。
然而这个过程并不那么畅快，我经常会感觉到有种信息过载的感觉。
相比以前和同事慢慢讨论方案，一边一行行实现一边迭代重构相比，动脑的强度实际上高了很多，然后等待 AI 出工的过程中往往又会有点无聊，对于结果的不可控性和 AI 代码的理解困难性等方面又会让我有点焦虑。
纯手搓代码能够很好地互补这一点——我暂时离开了 AI 驱动的高峰值功率的生产节奏，能够平稳地享受专注的创造，感受心流带来的平静。可以说纯 AI 开发很糟糕地打破了编程的这一部分乐趣。
哎，真有点怀念古法编程时代。
最后叠个甲，我这里的“古法”编程的定义是，项目全部代码亲手编写，不以对话或其他方式让 AI 生成代码。但可以和 AI 讨论细节实现，至于用不用必须自己判断。用 Fitten 之类的 Tab 补全一行代码是 OK 的。我也不反对生产中用 AI 提效，也不试图说服坚决抵触手写者。本文只想写给仍想保有技术掌控力与完整创造经验的程序员。
2026 年 7 月于昆明
---
原文链接：[点击查看](https://www.v2ex.com/t/1229967)
我看了一下自己最近纯手工编程的项目，是开源仓库 Noteman，最近更新时间是 Mar 29, 2025，距今一年多。而真正还在大规模手搓代码，大概是在 2023 年之前。
——对上了，22 年 11 月 30 日，OpenAI 发布 ChatGPT3.5，自那以后，无论是让 AI 生成之后我再 Copy（大约是在 2023~2025，基本用的是免费的 GPT 和 Gemini Pro 2.5），还是转向纯 Coding Harness（最近两年是诸如 Claude Code 或是 Codex CLI），我再也没有完全手搓代码了。哪怕是去年自己曾经一些极其复杂逻辑，AI 自己理解不了也给不了太好方案的情况下，也依然是让 AI 生成了部分相对不动脑的代码。
然后最近接触了一些刚毕业的校友，我发现他们几乎四年来从来没有自己完整手写地做完过任何一个编程作业——而他们的独立编程能力也十分堪忧。基本上可以说沦为了传话筒，没有 AI 就丧失工作能力只能发呆。他们可以面不改色地面对 AI 写出来的质量非常糟糕的代码，因为他们完全看不出来有任何问题。他们也几乎从未认真了解过 Clean Code 等原则，当我提到 SRP、OCP 时他们往往觉得这些东西过时了，或者应该封装成 Skill 然后就万事大吉了。
例如有个人长期把 Git、Docker 之类操作全部交给 AI，虽然不会手打命令（哪怕切出分支都不记得怎么做），但他们觉得自己已经掌握了 Git 和 Docker。然而据我观察他们并未如我们前 AI 时代的人那样建立了良好的心智模型，一旦遇到一些复杂的局面就只能全权交给 AI 但无法理解，就如一个产品经理遇到 AI 生成的前端代码报错那般。
所以，我想发表一个暴论，AI 时代，每个程序员一定要留一个完全手写的项目。
对老手而言，意义在于能对冲能力退化的风险，在 AI 作用受限时维持技术接管能力。毕竟依然不存在能理解如项目负责人那般周全的上下文的 AI，这块再聪明也没用。依然会有许多情况 AI 跑偏了，或者环境确实受限，或者极端点出现一段完全无法使用 AI 的时期，那么依然能够亲自进入系统解决问题，是你作为 Senior 的实力的证明。
对新手而言，长期来看，在不断设计、反思中手写代码，可能反而是更高效的训练。甚至可以说，保留一点手搓代码，是走向资深工程师的捷径，因为你的多数竞争者已经完全交给 AI 了。而他们享受不到手搓代码带来的一些意外的好处。
是的，手搓代码其实是有一些好处的！因为手搓代码可以迫使你频繁地在最细节的层面，做出有意义的决策。
举个例子，我最近也开始手搓一个迷你的 RTOS 叫 MiniRT。里面就涉及到大量的决策细节，比如亲手设计 Task 结构的时候，你必须思考哪些字段是最重要和最必要的（例如栈指针、任务状态等字段）。如果交给 AI，基本上大家会看 AI 的方案 Sounds good 就觉得 OK 了，然后不知不觉设计已经变得相当复杂，而你实际上不太清楚他是怎么演化到这样的复杂地步的，心里对整套系统也没有清晰的图景——哪怕你已经 review 了每个 PR。因为 Review 的时候往往你也是觉得看起来合并，就准了。然而不知不觉系统已经被 AI 写成屎山，甚至出错，这个时候才回过头来看设计，智商再高也会有种云里雾里的感觉。
所以手写的价值就是让你不得不仔细斟酌每个设计决定。这种过程是相当锻炼人的，任何经历过无 AI 时代，靠查 CSDN、Stack Overflow、翻书甚至翻论文来手搓代码的人都能理解我刚刚说这些意味着什么。
所以我建议大家尤其是新人一定要体验一下手搓代码，最好能给自己一块自留地可以长期手搓，如果是和现实业务相关就更好（玩具项目毕竟复杂度还是远不及现实），在这个过程中积累一手的编码设计决策经验，会让你非常快速地成长。哪怕今后 Review 代码和指挥 AI 重构，也会不容易被忽悠。
这和一些传统企业要求高级经理必须从基层做起是一样的，如果没有亲自做过，就很容易缺乏一些不可言说的判断力，被手下的 Agents 忽悠，总之，你写代码就会产生类似外行领导内行的奇妙场景。
而且编程的情绪体验也是很重要的一部分。和 AI 协作编程时，我的基本流程是先出 Design Doc（类似于战略），再出 Implement Guide（类似于战术），最后让 Agents 去施工。这个过程中我约等于 CTO，倒是很锻炼人的架构能力——我会让 AI 反复地拷问我，确保大方向上没有任何歧义和差错。
然而这个过程并不那么畅快，我经常会感觉到有种信息过载的感觉。
相比以前和同事慢慢讨论方案，一边一行行实现一边迭代重构相比，动脑的强度实际上高了很多，然后等待 AI 出工的过程中往往又会有点无聊，对于结果的不可控性和 AI 代码的理解困难性等方面又会让我有点焦虑。
纯手搓代码能够很好地互补这一点——我暂时离开了 AI 驱动的高峰值功率的生产节奏，能够平稳地享受专注的创造，感受心流带来的平静。可以说纯 AI 开发很糟糕地打破了编程的这一部分乐趣。
哎，真有点怀念古法编程时代。
最后叠个甲，我这里的“古法”编程的定义是，项目全部代码亲手编写，不以对话或其他方式让 AI 生成代码。但可以和 AI 讨论细节实现，至于用不用必须自己判断。用 Fitten 之类的 Tab 补全一行代码是 OK 的。我也不反对生产中用 AI 提效，也不试图说服坚决抵触手写者。本文只想写给仍想保有技术掌控力与完整创造经验的程序员。
2026 年 7 月于昆明
---
原文链接：[点击查看](https://www.v2ex.com/t/1229967)
另外补充一点，找个那种能一行行互相 review 代码的开源社区也挺好。毕竟自己一个人闭门造车，还是不如多跟别人交流碰撞学得多。
· 0 个赞