AI时代，为什么“古法编程”反而成了救命稻草？

1. 看到这个小说标题，我没去追连载，反而给自己下了一个“禁AI令”

这两天《AI编程末日，只有我会古法编程》这个标题在开发圈里传得挺快，一度挤进热搜。评论区里什么说法都有，有人当爽文看，有人觉得这是程序员版的“最后一位老手艺人”，还有人直接开嘲讽：现在不让用AI写代码，跟不让用计算器有什么两样？

我属于那种手比嘴快的类型，讨论归讨论，不如动手验一把。因为标题里那个“古法编程”四个字，对一线写代码的人来说不是梗，是一个特别值得较真的命题：如果明天所有AI编程助手全部消失，我还剩多少能力是真能拿出来写项目的？反过来，如果AI已经这么强，我每天花在“补基本功”上的时间到底有没有白费？

所以我给自己定了一个实验任务：48小时之内，不打开任何AI编程助手，不复制AI生成的代码，也不去ChatGPT、Cursor、Copilot这类工具里问任何技术问题，完全靠手写键盘完成一个能实际运行的小项目，中途允许查官方文档、允许用搜索引擎查报错信息、允许用调试器。我把这个项目定为一个个人用的“命令行待办事项+工时统计工具”，不需要界面，跑在终端里就行，数据用JSON存本地。

这个实验的目的，不是在证明“AI是废物”，恰恰相反，我自己是主流AI编程工具的重度用户，每个月在Copilot和ChatGPT上的使用频率比大多数人都高。我想搞清楚的是另一件事：AI到底替我扛了哪部分工作？我在不知不觉里把哪部分思考外包给了它？如果有一天工具断供、模型出问题、公司采购收紧，我的实际产出会跌到什么位置？

整个实验过程我每天都有记录，包括卡壳点、效率瓶颈、爽感时刻和焦虑时刻。看完这篇分享，你大概能搞明白三个问题：第一，古法编程在2026年到底还剩多少存在价值；第二，什么样的基本功是AI替代不了的；第三，普通开发者怎么在AI时代把自己的手艺练到“工具没了也不慌”的状态。

先说结论，防止你在下文里找半天：AI编程确实替代了很多“写”的环节，但它替代不了一个思考闭环。而古法编程的核心，从来不是不用工具，而是你的脑子里有没有一个完整的、能脱离工具运转的建模系统。小说里那个男主角之所以在末日里还能写代码，本质上不是因为他键盘敲得快，而是因为他脑子里那套“地图”还在，其他人已经只剩AI给的“导航语音”了。

2. 古法编程到底是什么？我拆解下来，是AI改不掉的那五层内功

“古法编程”这个词听着很玄，但在实操里一点都不玄。它不是要你退回纸带打孔的年代，也不是让你背过标准库的所有API。我用自己的话定义：古法编程，是指不依赖AI生成、不依赖自动补全，一个人也能完整走完从需求到上线的整个闭环能力。

这套能力我拆成五层内功，每一层都能在小说标题对应的“极端场景”里找到映射。

第一层是需求翻译。这层说的是把一句模糊的人类语言，比如“我想要一个能统计我每天在哪些项目上花了多少小时的工具”，翻译成数据结构、接口边界、异常分支和验收标准的能力。AI擅长的是在需求已经很清晰的时候帮你写代码，但“把模糊需求变清晰”这件事，它的表现非常不稳定，经常会出现它替你拍板了某个关键交互逻辑、结果做出来根本不是你要的东西的情况。古法编程的人会先自己画一遍边界，再让AI去填具体实现。

第二层是系统拆解。拿到需求后，能判断这该做成单体脚本还是分模块工程，入口在哪、数据流怎么走、配置怎么放、错误怎么分级。这些决策来自对代码演进代价的理解，一个模块将来会不会膨胀、接口要不要预留扩展位，你得靠经验和直觉来判断。AI能给你一个合理的目录结构，但它不会为你未来三个月的迭代负责，你如果自己没判断力，就会陷入“AI搭台、你来拆台”的无限循环。

第三层是缺陷定位。代码出问题时，能通过日志、断点、二分排除和阅读调用栈来缩小范围。这一层AI能起辅助作用，却扛不了大梁。原因很实际：真实问题的上下文往往分散在业务逻辑、网络状态和历史改动里，你没法把这些完整地、不遗漏地描述给聊天窗口。如果你自己不会排查，AI给的建议就只能是隔空猜。偶尔能一枪命中，大多数时候会让你改一个无关文件，然后问题更严重。

第四层是性能直觉。数据量上来后，知道瓶颈大概在数据库查询、内存拷贝还是IO等待上。这种直觉来自长期对资源消耗的敏感训练，你亲手写过、压测过、优化过，才会有“这里可能会炸”的预警。AI可以告诉你某段代码的时间复杂度是O(n^2)，但它不会在你写完第七天、数据量暴涨到500万行时主动提醒你。预警能力只能在脑子里。

第五层是代码品味。这一层没有量化标准，但是团队协作里最要命的东西。变量命名是否表意准确、函数是否只做了一件事、抽象边界是否自然、注释是在解释“为什么”还是复述“是什么”。AI模型在统计概率上生成的代码风格很像“平均水准”，到不了“这个函数设计得真漂亮”的程度。它不出大错，却也没魅力。

看到这里你应该能对上号了：小说里“末日”之后，AI不能用了，那些只会写提示词、只会让模型帮忙解题的人会突然失去脚手架；而真正能被称为“古法编程者”的人，恰好是五层内功都还健在的人。他们的代码跑在CPU上，更跑在自己的理解之上。这个设定听起来戏剧化，但内核其实非常现实——每一次工具中断、每一个模型降级、每一次网络断开，都在做末日模拟。

3. 48小时禁AI实录：效率下降了，但下降的方向很有意思

实验一开始，我预期最大的痛点是“写代码变慢”。真实跑下来，写普通业务代码的降速其实可控，真正让我抓狂的是三个完全没想到的地方。

第一个痛点是API细节的回忆成本。平时我一个 datetime 格式串不记得了，直接扔给AI问一句，它三秒给我答案。断AI之后，我不得不切到官方文档去翻，一次翻两分钟。单个功能还好，但累计十几个零星查阅之后，那种流畅的心流状态就被打断了，整体耗时大概多出80%。这个差距我自己能接受，因为我并不认为记住所有API细节是专业能力的核心。文档本来就是给人查的，效率差距来自工具特性，不是大脑退化。

第二个痛点是“批量正则替换”级别的重构变慢了。日常我用Copilot做跨文件改名、提取公共函数、替换调用方式时，它补得又快又准，几乎不用我过脑子。断AI之后我需要人肉搜索所有引用点，逐个看上下文再修改。这个环节出错的概率大幅升高，来来回回测试才发现有漏改的地方。我承认，在有AI的年代还不用AI做这种机械重构，确实是矫情，但这次实验也让我清醒地意识到：如果哪天AI没理解我的意图，做出了一个看起来合理、实际破坏性很大的批量修改，而我自己对人肉重构的生疏导致看不出错误，那才是灭顶之灾。

第三个痛点也最值得展开说：系统性排查问题时的上下文成本。第二天下午我的工具出现一个诡异现象：数据在程序重启后偶发性丢失，不是必现，大概每跑四五次会丢一次。这个是我实验里最耗时间的部分。我打开调试器，逐步检查写入流程，在写入前打印数据快照，发现有的流程走了异步写、有的流程走了同步写，在进程退出时异步写的回调还没执行完，进程就已经结束了。

在没有AI辅助的48小时里，我靠一路断点、一路加日志找到问题，足足花了两个小时。但换个角度想：如果我在用AI辅助，我会怎么问？我得在对话框里把整个项目的结构、关键代码、异步流程全部描述清楚，至少要打上百行字，而且大概率会漏掉某个关键细节，最后模型给我一个看起来全面、实际没踩到点的答案。反而是一个人闷头用调试器时，对代码的控制感是完整且连续的。

48小时结束后，我做了一个当天只有自己看到的统计：项目总代码量大概是1200行，整体耗时比日常用AI时多了大概一倍多，但项目里每一个模块怎么运转、数据怎么流转、边界怎么处理，我的清晰度可能比过去三个月里任何一段AI辅助产出的代码都高。

这种“清晰度”才是古法编程给从业者最大的红利：你写出来的代码是你的作品，不是你在聊天对话框里捡来的礼物。

4. 古法程序员手里真正不能丢的三件护身符：断点、日志、读码

小说里的男主能在末日里活下来，靠的肯定不是背下所有函数库，而是几件真正底层的实操技能。我这两天的实验下来，真正感受到“护身符”级别价值的，是下面这三样。

4.1 断点调试不是老古董，而是唯一能看清运行时真相的手段

现在的年轻开发者有一个共性习惯：遇到Bug，第一反应是复制报错信息扔给AI解释，而不是先自己看看变量在哪个环节开始不对。AI给出的解释通常很流畅，但它永远在“猜”你的运行时状态，而断点调试器是在直接“看”运行时状态。

拿我这次那个异步丢数据的Bug来说，如果走AI辅助路线，大概率它会建议我“改用同步写”“加锁”“等待协程结束”。这些方向没错，但你没看到证据链，心里不踏实，改完也很可能引入新问题。而我用pdb在进程退出前打了断点，一步步看调用顺序后，发现在写文件后、回调未执行完时，进程已经走了 sys.exit()，问题一目了然。

建议每个开发者都认真练一遍至少一种命令行调试器，Python就练pdb，Node.js就练node inspect，Java就把IDE的Debug视图所有按钮彻底搞清楚。能熟练使用断点的人，在AI横行的时代会活得很舒服，因为你拥有了不被模型解释带偏的独立验证能力。AI告诉你“可能”哪里有问题，断点告诉你“肯定”是哪里有问题。

4.2 日志不是写了就完事，这是需要设计的信息系统

古法编程和现代编程同样被低估的，还有日志设计。我见过太多工程出事时，生产环境打出来的日志全是INFO级流水账，真到了排查问题时，没有一个地方记录了关键上下文。

这里给一个可以直接抄走的日志设计思路：

• 日志不只是给“程序看的文字”，而是给“未来的你”留的案发现场。每次打日志前问自己：如果服务崩了，我看到这行日志能否知道之前发生了什么？缺了什么我能不能补出来？
• 错误日志必须携带足够上下文。很多开发者直接 logger.error("request failed")，然后上报Bug。古法编程者会写 logger.error("request failed, user_id=%s, order_id=%s, retry_times=%d", user_id, order_id, retry_times)。失败信息里没有关联ID，等于灾难现场没有坐标。
• 流程入口和出口必须埋点。函数进来时关键参数打DEBUG，出去时结果打DEBUG，中间异常打ERROR。这是最简单的全链路日志，却能让线上排查效率翻倍。

我那个待办工具的日志经历了三次改版，最后一次才做到“每一条日志都表意清晰”。开发阶段多花了一个小时设计日志，但实验结束前的测试阶段，我几乎没有再为定位Bug浪费时间。

4.3 阅读代码的能力决定你能从AI那里收获多少

古法编程里最容易被忽略的，是“读”而不是“写”。AI能替我们写新代码，但生产系统里存量最大的永远是别人以前写的、自己以前写的、甚至已经离职的人留下的老代码。要改它、优化它、修它，前提都是读懂它。

读码需要练一种“从细节回溯意图”的能力。我自己的习惯是从一个具体的函数入口进去，不急着读每一行，先抓住三个东西：输入是什么、输出是什么、它调用了哪些外部系统和数据源，然后从主干往分支看。遇到看不懂的命名，不急着骂人，先看看这段代码在哪个版本可能由什么原因引入。

我甚至建议你做这个刻意练习：每次用AI重构旧代码之前，先自己通读一遍并且写一段不超过五行的模块意图总结——不需要给任何人看，写给自己。坚持一个月左右，你对代码结构的感觉会明显跟以前不一样。AI生成代码的准确度，很大程度上取决于你喂给它的上下文质量，而上下文质量取决于你读码的深度。

5. AI编程工具的正确打开方式：先古法画靶子，再让AI填子弹

实验结束后，我重新打开了日常使用的AI编程助手们，感受非常复杂。它依然好用，但我对待它的方式变了。过去我像让实习生干活一样把需求丢过去，它交回来什么我检查什么，那种方式叫“被动捡漏”；现在我更像让高级工具干活的老工人，先自己在脑子里画出完整的靶子，再让AI精准地把子弹射上去。

这套工作流的精炼版，可以归纳成五条操作习惯，我一个个拆开说。

5.1 写码前先自己写下三段话

每次让AI生成代码前，我自己先写三段话：第一段是需求结论，我要做什么，边界是什么，谁在什么场景下用；第二段是技术约束，复用现有工程的哪个模块、不能用哪些依赖、性能底线是多少；第三段是验收标准，怎么算做完了。这三段话加在一起通常不到200字，但它能把AI的产出从“大致能用”提升到“基本不用改大结构”。

我给这种方式取过个偷懒的名字，叫“喂靶心”：提示词里最值钱的不是形容词，而是具体的边界描述。比如我不写“请写一个健壮的待办工具”，而是写“支持新增、完成、删除待办事项，数据持久化到本地JSON文件，进程退出前保证写入完成”。这种话术差距，老手一眼就能看出来。

5.2 让AI先写测试，再写实现，顺序反了就是给自己埋雷

让AI写代码时默认顺序通常是“先写功能函数，再补测试”。我现在的习惯是反过来的：先让AI根据我给的验收标准输出测试用例，我看一遍用例覆盖的逻辑分支是否符合我的预期，再让它实现功能主体。

这样做的好处很实在：测试用例在先，相当于你先把“靶心”翻译成了机器能跑的语言，AI实现时会被测例约束，不易跑偏。等它写完后直接跑测试，红了就截图给它修，循环几轮，最后产出质量的稳定性比我过去“先功能后补测”高了不止一倍。

5.3 把AI当“读码搭子”而不是“写码替身”

很多人的误区是只让AI写新功能，其实它更擅长的是解释旧代码。工作中遇到可读性极差的老模块，我现在的做法是把文件完整贴进去，然后要求它按“数据流向—核心函数职责—潜在风险点”三个维度输出导读。它能快速帮我建立整体认知，指出明显的问题气味，我再回头用人脑判断哪些值得修、哪些大概率有历史包袱不能动。

这一招实测下来，阅读陌生项目的速度提升非常明显。过去接手一个模块大概要两天才敢改，现在半天能进入状态，而且不会因为完全依赖AI导读而丢掉自己的判断——因为每一步我都要求它引用的关键代码行号，我会跳回去复核。

5.4 “模拟评审会”模式挑错

与其让AI直接帮你修Bug，不如让它先扮演一个挑剔的Code Reviewer。我会在提示词里写明：“你现在是团队里最严格的代码评审人，请从正确性、并发安全、边界条件、可读性四个角度逐条列出问题，问题要按严重程度排序，不要给代码建议。”

为什么这样设置？因为直接给修复建议的AI容易把错误改没又引新错。而让它先列问题、我自己挑重点处理时，我不会失去对修复过程的主导权。实测中经常出现它提出的某条建议能覆盖三处隐患，而另一条看起来很高级的建议实际上不适用我的业务场景。如果我不加过滤地照单全收，业务会变得一团糟。

5.5 用AI当外置记忆体，而不是唯一的思考来源

我现在把AI当作一个“随时可检索的记忆外挂”。常见用法是：不记得某个加密库的用法了，问它；不确定某段配置在某个框架版本里是否还兼容，问它；需要快速生成一坨固定格式的模板代码，问它。但对于架构决策、数据结构选型、模块边界的划分这类“模型只给概率、不给利益判断”的问题，我坚持自己先拿主意。

这里面有一个值得说的判断标准：凡是网上有标准答案且一成不变的问题，放心交给AI；凡是答案依赖项目上下文、历史包袱、团队习惯和未来规划的问题，一定自己先想清楚。后一类问题AI给不了个性化答案，它只能从一个“平均”项目的角度给你一个“平均”的建议，而你的项目从来不是平均的。

6. 踩坑记录：AI看着像会思考，实际只是擅长造句

前面讲了这么多工作流优化，最后说几个真实翻车案例，帮你提前避雷。

第一个坑：AI修Bug时给你“假阳性修复”。实验结束后第三天，我让AI帮我修一个JSON解析异常，它给我的修复方案是“在解析前先判断字段是否存在，存在再取”。听起来没问题对吧？但它没发现字段缺失只是表象，根因是上游接口在某种条件下返回了不同的字段名。它的修复只是让程序“不崩”，却让那个场景下一次静默丢失了数据。如果我没有保留古法编程者的追问习惯、没有继续追查上游契约，这就是一个线上数据事故。

第二个坑：上下文太长之后，AI会“变形”。当对话里堆积了大量代码片段，它越到后面越倾向于迎合你前面的表述逻辑，哪怕前面某个描述本身就是有偏差的。它会顺着错误的方向，一本正经地生成符合这个错误前提的代码。所以我现在的习惯是新任务就新开会话，必要上下文精简写在第一条消息里，长会话里每过几轮就对齐一次结论。

第三个坑：AI生成的代码参数像模像样，实质是“未定义行为的合法写法”。比如它给的一个文件写入方案，对普通小文件毫无问题，但用户目录空间满时会静默失败，没有任何错误提示；又比如它生成的并发控制用了一个看似安全的 threading.Lock()，但锁范围没有覆盖住共享资源的读取路径。这些问题单看语法、单跑单元测试都正常，只会在真实流量和高负载场景里露出马脚。

这类坑靠AI自己反思是修不掉的，模型没有“运行在生产环境的全身体验”。只有人，带着性能直觉和边界意识，在代码评审时问出那句“这里如果磁盘满了会怎样”“这里如果入口被并发打满会怎样”，才能把它堵住。而这些提问能力，恰恰就是古法编程的五层内功里我前面说的“性能直觉”和“代码品味”。

7. 别纠结工具，纠结自己的脚手架还在不在

这段写在最后，替还在焦虑的同行捋捋思路。小说里的“AI编程末日”不会以那个戏剧化的方式到来，但它确实以更温和的形式正在发生：某一天你会发现，你周围的同事里开始有人离开AI就无法独立完成一个模块，开始有人看不懂没有任何AI注释的源码，开始有人遇到线上问题只会“截图发给AI看看”。

这不是他们的智力和勤奋出了问题，而是他们把工具当成了脚手架，却没有意识到脚手架需要长在坚实的地基上。地基就是那套变不了的底层能力：能把需求翻译成边界、能靠调试器看清运行时真相、能在日志里快速重建现场、能读懂陌生代码的骨架、能在崩溃前嗅到风险。

用不用AI根本不重要。Cursor也好、Copilot也好，还是明年又冒出来的某某AI编程神器也好，它们都只是笔。笔变快了，最后落在纸上写出什么故事，仍然取决于握笔的人心里有没有一份完整的蓝图。

我对这个小说标题最大的共鸣，是它把“只有我会古法编程”描述成了一种极端稀缺能力。而在现实世界里，稀缺的从来不是会敲键盘的AI指令师，而是这些在任何工具环境下都具备完整判断力的人。希望看过这篇分享的你，不要真等“断网断AI”那一天才开始补课。现在就用调试器亲手查一次Bug，亲手给异常日志补上几个关联字段，不靠AI提示，把一个100行的旧代码模块通读一遍——这些练习不需要花你多少钱，但它买来的是在任何时代都不慌的底气。