一、现象：那些让“古法程序员”血压升高的声音

在AI代码生成能力快速普及的今天，开发者社区里常能听到一些颇具挑衅意味的说法：“这个功能我让AI生成了三次就出来了，你改了两天？”“你还在一行行读文档？直接把整个仓库丢给AI让它自己读啊”“这个bug贴给AI一秒就指出了，你查了一整天？”“代码风格有什么意义？AI生成完照样能跑。”

这些话之所以扎心，是因为它们共享同一个隐含假设：软件工程的本质就是“把代码写出来”，而“写代码”这一环节正在被AI以数量级的速度压缩。但这个假设本身，恰恰是对软件工程最大的误解。本文不打算停留在情绪层面，而是逐条拆解这些说法背后的技术误区，并讨论人机协作的务实姿势。

二、逐条拆解：效率叙事背后的技术误区

1. “AI三次就出结果，你改了两天？”——演示代码与生产代码的距离

一个功能从“能演示”到“能上线”，中间隔着大量AI一次性生成无法覆盖的工作：需求边界的澄清、异常分支的处理、与存量系统的兼容、并发场景下的正确性、性能与安全约束、监控告警与回滚预案。资深工程师花两天，往往不是“打字慢”，而是在补齐这些隐性成本。

看一个示意性的伪代码对比：

AI十秒生成的“能跑”版本

def transfer(account, amount):
account.balance -= amount
return True

这段代码在演示环境里确实可以工作，但它没有校验金额合法性、没有并发保护、没有失败时的一致性保证、也没有审计记录。补上工程判断之后，它会变成另一个样子：

def transfer(account, amount):
if amount <= 0:
raise ValueError(“amount must be positive”)
with account.lock: # 并发控制，防止超扣
if account.balance < amount:
raise InsufficientBalance()
account.balance -= amount
ledger.record(account.id, amount) # 审计流水
return True

差距不在语法，而在工程判断——而工程判断恰恰是AI最难替代的部分，也是“两天”里真正的价值所在。

1. “把整个仓库丢给AI读”——上下文边界与幻觉风险

代码生成模型的上下文窗口再大，也难以在一次交互中完整、准确地理解一个中大型仓库的全部语义：跨模块的隐式约定、历史包袱、配置与环境的耦合、文档与实现之间的时滞。更关键的是，模型存在幻觉风险，它可能以非常自信的口吻给出与真实实现不符的结论。

合理的做法是把AI当作高效的检索与摘要助手：让它快速定位相关模块、总结调用链、生成阅读笔记，但关键结论必须回到源码与官方文档中验证。文档不只是“信息”，更是接口契约与版本演进的记录。逐行精读关键文档所花费的时间，远低于在生产环境为错误理解买单的成本。

1. “AI一秒定位bug，你查了一天？”——表面修复与根因分析

对于常见错误（空指针、拼写错误、典型API误用），AI确实能给出接近即时的答案。但生产环境里真正昂贵的bug，往往涉及并发时序、网络分区、缓存一致性、资源泄漏、环境差异等系统性因素。这类问题的完整解决链路是：稳定复现→缩小范围→定位根因→修复→回归验证→监控确认。AI可以加速其中某些环节，比如提出假设、生成复现脚本，但“一秒指出”的答案如果未经这条链路验证，很可能只是把bug换了个地方，或者修掉了表象、留下了病根。

1. “代码风格有什么意义？”——可读性决定长期成本

代码首先是写给人看的，其次才是给机器执行的。风格统一的代码库能显著降低评审成本、新人上手成本和跨团队协作成本；静态检查、命名规范、分层约定这些“古法”，本质上是把团队多年的踩坑经验固化成可执行的约束。AI生成的代码如果绕过这些约束直接合入，短期看节省了时间，长期看是在给整个系统累积技术债——债务总会到期，而且通常在最不合适的时刻。

三、古法功夫的真正价值：从“写代码”到“定义问题”

如果把程序员的能力做分层拆解，会发现AI冲击的主要是“编码执行”层，而传统工程训练中真正稀缺的部分反而更值钱了：

• 问题定义能力：把模糊的业务诉求翻译成清晰的技术方案、接口契约与边界条件；
• 架构与权衡能力：在一致性、可用性、成本、演进速度之间做符合场景的取舍；
• 调试方法论：二分定位、日志与监控体系设计、最小复现的构造；
• 质量体系：测试策略、评审流程、灰度发布与可观测性建设。

这些能力不会因为AI能写代码而贬值。恰恰相反，当AI把工程师从重复劳动中解放出来后，这些能力成为产出质量的决定性因素。

四、人机协作的正确姿势：一条务实的分工原则

结合业界普遍实践，可以把任务大致分成两类。

适合交给AI的：

• 样板代码、配置模板、增删改查脚手架；
• 单元测试初稿、注释与文档补全；
• 正则表达式、格式转换、一次性小脚本；
• 对陌生代码库的初步梳理与结构摘要。

必须由人把关的：

• 核心业务逻辑，以及涉及资金、隐私的关键路径；
• 安全相关代码，如鉴权、加密、输入校验；
• 架构决策与第三方依赖的引入；
• 所有AI生成代码的测试、评审与合入。

无论使用哪家的智能编程工具——目前包括百度智能云在内的主流云平台都已把这类辅助能力纳入通用研发工具链——都应建立“生成即待审”的纪律：AI产出的一切代码，在通过测试与人工评审之前，一律视为草稿，而非成品。

五、结语：效率与匠心并不对立

“古法程序员”被激怒，从来不是因为AI太快，而是因为那些轻慢的说法抹掉了他们在无数次线上事故、深夜回滚和重构挣扎中积累的工程判断。AI是前所未有的效率杠杆，但杠杆放大的是使用者的判断力：判断力强，效率倍增；判断力缺失，错误同样倍增。

真正成熟的姿态，是把AI当作最快的实习生，而自己继续做那个把关的师傅——既拥抱十秒出码的速度，也守住测试、评审、文档与规范的底线。慢功夫不会过时，它只是换了位置：从键盘上，移到了更高的地方。