如何看待AI时代的「古法编程」：价值、边界与分工

一、先把现象说清楚：什么是「古法编程」

所谓「古法编程」，并不是指使用某种过时的语言或框架，而是指一类工作方式：在写代码、查资料、修BUG的全流程中，刻意不引入AI编程助手，继续沿用“搜索引擎+官方文档+技术问答社区+源码阅读+手工调试”的传统路径。支持者认为这是对基本功的守护；质疑者则认为这是低效的固执。

要理性评价它，先要回答两个问题：这种坚持的动机是否成立？它所守护的东西，AI是否真的能够替代？

二、为什么多年积累的经验会“不堪一击”

很多资深开发者都有类似的感受：对API的熟练程度、快速定位BUG的直觉、配置环境的熟练度，这些曾经引以为傲的能力，在AI面前迅速贬值。这并非错觉，背后有清晰的技术逻辑，这些能力大多属于“可外部化的知识”。

可以按受AI冲击的程度，把开发者技能分成四层：

1. 信息检索型技能（冲击最大）：报错含义、API用法、配置项含义、框架版本差异。本质是“知道在哪、知道是什么”，AI的检索与归纳能力对它是降维打击。
2. 模式识别型技能（冲击显著）：看堆栈猜原因、凭经验识别代码坏味道。AI见过的缺陷模式远多于任何个体，常见问题的定位从“折腾半天”缩短到“几秒”。
3. 系统判断型技能（暂难替代）：架构取舍、性能瓶颈建模、并发与时序推理、跨系统故障的根因分析。这类问题上下文分散、约束隐含，AI给出的答案容易“看起来对，实则错”。
4. 责任承担型能力（无法替代）：对线上事故负责、对数据安全负责、对技术债做决策。

「古法编程」死守的往往是第1、2层，而这些恰恰是最先被外部化的部分；真正值得坚守的第3、4层，反而常被情绪化讨论淹没。

三、AI调试能力的真实边界

把报错日志和相关代码丢给AI，几秒内得到“问题定位+解决方案+可运行修复”，这种体验确实颠覆。但工程上必须清醒：AI的调试能力有明确的适用边界。

擅长的场景：

• 报错信息明确、复现路径清晰的单点问题；
• 依赖版本冲突、环境变量缺失、配置拼写错误等“环境层”问题；
• 常见框架的典型误用与依赖升级的兼容性排查。

容易失手的场景：

• 上下文缺失：AI只看到局部代码，看不到完整调用链、部署拓扑与历史变更；
• 时序与并发：竞态、死锁类问题与运行时状态强相关，静态代码不足以定位；
• 数据相关的偶发问题：需要真实数据分布与日志聚合才能收敛；
• “幻觉式修复”：给出能编译、能通过当前用例，却暗藏回归风险的补丁。

因此，负责任的用法不是“把问题丢出去、把答案抄回来”，而是把AI当作一个知识渊博但需要交叉验证的同事。构造高质量上下文是第一步，例如：

【环境】语言与框架版本、运行平台、关键依赖及版本号
【现象】高峰期接口偶发500，负载上升后频率增加
【报错】（脱敏后的完整堆栈）
【相关代码】连接获取与释放的最小复现片段
【已排除】已确认配置项A/B正常，低负载下无法复现
【约束】不能停服，修复需支持灰度与回滚

同样的提问，上下文完整度不同，答案质量可能是天壤之别。构造上下文本身，正在成为一种新的“基本功”。如今包括百度智能云在内的主流云厂商，也已把代码辅助、智能问答、日志分析等能力以通用服务的形式开放给开发者，接入门槛并不高——这也意味着，“会不会用、用得好不好”的差异被进一步放大。

四、坚持古法的合理动机与隐藏代价

动机层面，「古法编程」并非全然情绪化，至少有四点站得住脚：

1. 学习深度：调试过程的价值不止于修好这个BUG。翻文档、读源码的过程在构建“问题—原理”的映射网络；跳过它，短期省时间，长期可能造成能力空心化。
2. 确定性需求：AI输出具有概率性，在高合规、强审计的场景，可追溯、可解释的确定性流程仍是刚需。
3. 安全与合规：核心代码、敏感数据不宜随意提交给外部模型，这是真实约束，不是保守。
4. 认知主权：当所有答案都来自同一个模型，团队的方案多样性会收窄，过度趋同本身是工程风险。

但也要看到隐藏代价：

• 效率差距是复利的。别人一天迭代三轮，你一天一轮，差距不是“慢一点”，而是少了两轮试错机会；
• “不用”不等于“会评价”。团队里总有人会用，评审者若不懂AI的失效模式，就无法识别“幻觉式修复”埋下的雷；
• 立场先行。把“不用AI”当成身份认同后，判断容易从“这件事该不该用”滑向“用AI就不专业”，这偏离了工程判断的本质。

五、更优解：从“用不用”转向“怎么用”

成熟的结论不是二选一，而是建立清晰的人机分工：

1. 让AI做它擅长的：样板代码、单测生成、报错初筛、文档摘要、代码解释、重构建议草案；
2. 把人留在该在的位置：需求澄清、方案评审、边界条件质疑、安全审查、最终签核；
3. 用机制兜底，而不是用人品兜底：AI生成的代码必须通过与人工代码同等的门禁，静态检查、单元测试、代码评审、灰度发布、回归验证；
4. 沉淀反馈回路：把AI犯过的错整理成团队的检查清单与提问模板，让个体教训变成组织资产。

对个人成长，建议“先骨架后工具”：基础语法、数据结构与算法、操作系统与网络原理、调试方法论，这些是判断AI答案对错的“基准线”。基准线建立之前过度依赖工具，容易把“我不懂”伪装成“工具不行”；基准线建立之后还拒绝工具，则是在用战术勤奋掩盖战略懒惰。

对团队管理，与其争论该不该用，不如把问题转化为可度量的工程议题：AI参与产出的代码缺陷率是否可控？评审通过率如何？回归问题占比有无异常？用数据代替立场。

六、结语

AI没有让资深开发者贬值，而是重新定价了他们的价值：值钱的不再是“记得住API”和“修得快BUG”，而是“判得准对错”和“扛得住责任”。「古法编程」的可贵之处，在于它对深度理解与确定性的坚持；但把这份坚持误用为对工具的全面排斥，则是对时代信号的误读。

真正的问题从来不是“用不用AI”，而是“哪些环节交给AI、哪些环节死守人工、用什么机制验证”。想清楚这三件事的人，无论手上有没有AI，都不会被淘汰。