古法编程的价值重估：从Vibe Coding回望结构化思维

一、当“告诉机器做什么”成为新的编程入口

过去，编程的核心是用精确的语法描述“如何做”：如何分配内存、如何遍历列表、如何处理并发。如今，基于大语言模型的编程辅助工具正在改变这一入口。开发者可以用自然语言表达意图，例如“为订单模块编写一个带重试机制的异步任务”，随后由模型生成方案、代码骨架、测试用例甚至定位缺陷。

这类工作方式常被称作“氛围编程”或“自然语言驱动开发”。它的本质不是消灭代码，而是把一部分表达成本从形式化语法转移到自然语言描述，再由模型完成到代码的映射。其背后依赖的是大语言模型读入海量文本与代码后形成的统计预测能力。

但入口的简化并不意味着工程复杂度的消失。相反，当代码生成变得容易，对代码正确性、可维护性和系统一致性的要求反而更高。这也是为什么一些团队和个人仍坚持“古法编程”——不是排斥工具，而是拒绝在没有充分验证机制的情况下，把关键实现交给黑盒。

二、大语言模型如何影响编程决策

要理解AI编程的适用边界，需要先理解其基础单位：Token。

Token是模型处理文本的最小语义块。在英文中，一个常见单词可能对应一个Token，例如“function”通常被切分为一个Token；在中文里，一个汉字可能消耗1到2个Token。“Hello World”大约是两个Token，而“你好世界”可能消耗四到六个Token。AI服务通常按照输入与输出消耗的Token总量计费。

Token机制带来三个直接后果：

第一，上下文窗口不是无限的。 模型一次能处理的Token总量有限。项目越大，历史代码越多，单次对话能携带的上下文就越少。开发者不得不频繁压缩、摘要或重新描述背景，这本身就是一个信息损耗过程。

第二，生成质量与提示精度强相关。 提示中每多一段模糊描述，生成结果就多一分偏差。表面上Token消耗是成本问题，实际上它反映的是信息密度问题：用更少的Token传递更精确的约束，本身就是一种工程能力。

第三，长链推理的可靠性与消耗成正比。 对于需要多步逻辑推导、跨文件依赖分析或状态追踪的任务，模型往往需要更多Token逐步展开推理。一旦Token预算受限，生成质量会明显下降。这也是为什么在资源受限或逻辑复杂的场景中，人工编写的结构化代码仍然更具确定性。

三、AI编程的真实能力边界

当前的大语言模型在以下场景表现较好：

• 生成重复性高的样板代码，如增删改查接口、数据访问层、单元测试框架；
• 解释已知代码片段的功能与潜在问题；
• 根据明确输入输出示例生成正则表达式、SQL语句、格式转换脚本；
• 在已有代码风格约束下完成局部重构。

但在以下场景中，AI生成结果需要更严格的人工校验：

• 涉及并发控制、事务边界和一致性保证的代码，这类问题往往取决于系统整体设计而非局部语法；
• 与遗留系统深度耦合的修改，模型可能不了解内部历史决策与隐式约定；
• 安全性敏感路径，例如认证、授权、加密与数据脱敏，错误通常不是语法错误而是语义漏洞；
• 需要明确资源释放、异常恢复和超时策略的底层实现。

“古法编程”的坚持者并非否认模型的辅助价值，而是判断：当代码的正确性无法通过编译器和测试立即验证，而错误代价又很高时，逐行理解与控制仍然是成本最低的方式。

四、可维护性如何被生成速度反噬

AI编程最吸引人的指标是首版代码的产出速度。但从软件生命周期看，首版编写通常只占整体成本的一小部分。后续的阅读、修改、调试、扩展和迁移才是长期投入。

当代码由模型生成，而开发者没有完全内化其结构意图时，会带来几类隐性成本：

1. 认知债：开发者需要额外时间理解“为什么这样写”，而这段理解时间可能超过自己直接编写的时间。
2. 一致性损耗：在不同时间、不同提示下生成的代码风格与设计决策可能漂移，导致项目内部出现多种实现范式。
3. 测试盲区：模型生成的测试可能恰好只覆盖了模型自己生成的逻辑路径，而遗漏真实业务边界。
4. 重构阻力：当开发者对代码缺乏“所有权”认知时，改动会变得犹豫，重构意愿降低。

在需要长期演进的核心业务系统中，这些成本会逐渐累积。而“古法编程”所代表的，正是一种对长期可维护性的偏好选择：宁可首版慢一些，也要保证每一行代码都经过明确的工程推理。

五、比“用不用AI”更重要的判断框架

是否使用AI辅助编程，本质上是一个工程决策，而非技术立场。更务实的问题不是“是否古法”，而是：

• 这段代码的生命周期有多长？是一次性脚本还是需要维护数年的核心模块？
• 错误代价有多高？是内部工具的小偏差，还是涉及资金、隐私或生产可用性的关键路径？
• 验证手段是否充分？是否有完善的测试体系、静态分析和灰度发布流程兜底？
• 团队的代码评审能力是否足以识别生成代码中的语义缺陷？

一个可行的折中策略是：在探索性原型、一次性数据处理脚本、样板代码生成等低风险场景中充分使用AI；在核心领域逻辑、复杂状态管理、安全敏感路径上保留人工精细实现。同时，无论是否使用工具，都要求生成代码通过相同的评审、测试与可观测性标准。

六、结构化思维仍然是开发者的核心资产

大语言模型擅长模式识别与概率生成，但软件工程中的许多关键决策并不来自模式高频出现，而来自对约束条件的精确理解。例如，一个订单状态的流转设计，取决于业务规则、补偿机制、审计要求与一致性强弱；这些信息往往分散在文档、会议、历史缺陷和团队经验中，而非单纯体现在代码语料里。

“古法编程”训练的核心能力，正是这种从模糊需求中提炼明确约束、从约束中构建结构化实现的思维方式。当模型输出的代码被投入生产，真正兜底的仍然是具备这种能力的工程师。

换句话说，AI降低了语法表达的门槛，但提高了语义判断的门槛。开发者不再需要花大量时间记忆API细节，却需要花更多时间确认：这段代码是否符合业务约束、是否在失败路径上安全、是否与系统其他部分的行为一致。

七、结语：工具在变，工程判断不变

“古法编程”不是对技术的保守，而是在生成速度与长期质量之间做出的审慎选择。AI编程工具的价值已经得到验证，但它的价值兑现依赖于使用者的判断力、验证体系与工程纪律。

未来更有竞争力的开发者，可能既不是完全不使用AI的“原教旨主义者”，也不是完全依赖AI输出的“提示词工程师”，而是能清醒判断何时让模型生成、何时必须自己掌控，并能对两者产出承担同等质量责任的人。工具会持续进化，但对正确性、可维护性和系统一致性的追求，不会因生成方式的改变而降低。