引言：现象概述
2025年初至今，一个略带戏谑的概念——“古法编程”——在中文编程社区悄然兴起，并迅速成为开发者群体中热议的焦点。这股风潮的兴起，源于一个简单却意味深长的对比：在Cursor、Claude Code、GitHub Copilot 等AI编程工具大行其道的今天，仍有不少程序员选择坚持传统的手写代码方式，或对AI辅助工具的使用保持审慎态度。
根据知乎问题《如何看待现阶段坚持不用AI的「古法编程」？》的数据，该问题获得了超过2300人关注、近900个回答，以及海量的评论互动。这个现象所折射的，远不止是工具选择的分歧，更是技术变革浪潮下，开发者群体对于编程本质、职业价值与未来走向的一次集体叩问。
需要明确的是，“古法编程”并非一个严谨的学术定义，它更像一个社区创造的标签，用以概括从“完全拒绝AI”到“有限度使用IDE”的多种实践谱系。讨论的核心也早已超越了简单的“用或不用”的二元对立，深入到了在AI时代如何重新定义程序员的核心竞争力、如何平衡效率与质量、以及如何在快速迭代中守住专业底线的深层议题。
本文将基于社区中大量的真实讨论与案例，尝试对这一现象进行全面梳理与分析。
一、古法编程的定义与背景
1.1 什么是古法编程？
“古法编程”是一个相对且分层的概念，根据社区讨论，可以大致划分为三个层次：
- 最狭义的古法编程：指完全手写代码，仅使用最基本的文本编辑器（如 Vim、Notepad），拒绝使用任何IDE的智能补全、重构、调试等高级功能。
- 狭义的古法编程：使用IDE进行开发，但刻意关闭或避免使用集成的AI代码补全、生成功能，仅依赖语法高亮、基础代码提示等传统IDE特性。
- 广义的谨慎派：虽然使用AI工具，但在整个开发流程中保持主导地位。他们将AI视为“高级搜索引擎”或“代码建议器”，坚持对AI生成的每一行代码进行严格的审查与改写，绝不盲目信任。
1.2 历史演变脉络
有趣的是，“古法”的界定始终是动态变化的。正如一位答主略带幽默的观察：“曾几何时，一堆程序员鼓吹工具链+vim编程，视庞大的IDE为‘邪道’。如今，连使用IDE编程竟然也成了‘古法’。”
这种层层递进的“鄙视链”，恰恰揭示了技术发展中的一个永恒主题：每一代新工具的引入，几乎都会伴随关于“基本功”与“效率”的激烈争论。
1.3 当前争议的焦点
当前围绕“古法编程”的讨论，主要集中在以下几个核心问题上：
- AI生成代码的可控性：AI生成的代码，其质量、安全性和可靠性是否真的值得信赖？
- 程序员核心能力的变迁：过度依赖AI，是否会侵蚀开发者对底层原理、数据结构与算法设计的深度理解？
- 效率与质量的永恒博弈：AI带来的开发效率提升，是否会以牺牲代码的可读性、可维护性与架构优雅性为代价？
- 职业发展的重新定位：当AI能够完成大量基础编码工作时，程序员的价值和未来的职业路径究竟在哪里？
二、支持古法编程的观点
2.1 代码质量与可维护性
这是支持“古法”最核心、也最硬核的理由。许多资深开发者坚信，亲手敲出的代码在质量与长期可维护性上具有不可替代的优势。一位NGINX团队的工程师的观点非常典型：像nginx这类底层核心项目，对代码质量的要求远超“能运行”或“逻辑正确”。它要求代码极度简洁、清晰，行为完全可预测，架构路径干净，绝不能引入不合理的设计。
社区讨论进一步细化了AI代码可能存在的质量问题：
- 防御性编程过度：AI倾向于生成大量防御性代码（如过多的空值检查），虽然看似安全，却让代码变得臃肿，严重干扰代码审查的流畅性。
- 逻辑冗余与次优：AI生成的代码逻辑往往不是最优解，充斥着奇怪且不必要的步骤，增加了理解与维护的认知负担。
- 抽象层次混乱：AI容易“过度设计”，将本应由清晰架构保证的约束，退化为运行时四处散落的补丁判断，破坏了代码的整洁性。
2.2 心流状态与认知深度
多位答主提到了“心流”（Flow State）这一心理学概念。他们认为，沉浸式的手写编码过程更容易让开发者进入深度思考、创造力迸发的“心流”状态。
一位开发者的描述非常细腻：“古法编程更容易让我进入‘做产品’的心流状态。而使用AI时，我的大脑会变得异常浮躁和跳脱。等待AI生成、然后阅读、再修改的过程，不断打断我的连续思维。大脑和肌肉一样，越专注地使用，它就越强大、越有精神。”
另一位补充道：“‘Vibe Coding’（指完全依赖AI生成）和古法编程的一个巨大区别就在于心流。因为大语言模型（LLM）的响应延迟，你几乎要么在生成时刷网页，要么放空等待，思绪是被强行打断的。而且，你没有真正的‘学习’，因为只是‘看’了一眼代码，而不是亲手‘构建’它。”
2.3 职业发展与技能保持
从长远的职业发展角度看，支持者认为，保持扎实的手写编码能力是成长为高级乃至卓越工程师的基石。
一位答主的警告颇为尖锐：“对于初级程序员或编程新手，AI用得越多，其能力上限就可能越低。” 另一位开发者进一步解释道：“AI对‘菜鸟’来说是致命的，因为在整个现代开发流程中，‘仅会基础编码’的生态位正在被AI快速取代。如果新人从一开始就跳过亲手解决复杂问题的磨练，他们也同时失去了成长为技术‘大神’所必需的场景与机会。”
2.4 团队协作与责任边界
在团队协作环境中，“古法”或“审慎使用AI”的实践被认为更有利于项目的长期健康。
一位答主分享了一个令人警醒的案例：“在多人协作项目中，如果每个人都提交自己未经深度审查的AI生成代码，整个代码库的复杂度和混乱度会指数级增加。更糟的是，当被问及时，没人能说清某段复杂代码的完整意图。最终结果就是‘劣币驱逐良币’：AI写的代码只有AI（或许）能懂，维护者只能无奈地表示‘我也不清楚，让接手的人自己看着办吧’。” 这种讨论氛围，在很多开发者社区的交流板块中也能时常看到。
三、支持AI编程的观点
3.1 效率提升与生产力解放
支持全面拥抱AI的开发者，首要理由便是革命性的效率提升。一位答主的描述极具画面感：“AI生成代码的速度是碾压级的。5分钟描述需求，1-2分钟生成，为了稳妥再花3分钟审查调整，总共十分钟就能得到一套可工作的代码。这个速度，超越了任何顶级程序员的手工编码。”
效率提升主要体现在几个具体场景：
- 自动化重复劳动：如自动生成单元测试、API文档、样板代码等。
- 加速原型验证：快速构建功能原型（MVP），用于讨论新特性或验证想法的可行性。
- 充当跨领域导师：当需要快速学习一个新框架、新库或新语言时，AI能快速提供可运行的代码示例，极大地降低了学习门槛。
3.2 技术趋势与行业方向
支持者普遍将AI编程助手视为不可逆转的技术潮流。一位答主的观点很具代表性：“技术发展的历史一再证明，优秀的从业者永远是‘善用工具而不被工具定义’的人。与其陷入‘用或不用’的意识形态争论，不如积极思考如何让AI成为人类创造力的‘放大器’。”
3.3 市场压力与竞争现实
从残酷的商业竞争和就业市场角度出发，支持者强调了“适者生存”的紧迫性。一位评论者的发言引发了广泛共鸣：“那些还在坚持完全手写、一概不碰AI的，我只能说是比‘老传统’还传统。当公司上下所有技术骨干都在用AI提升效能时，你不用？等到公司开始‘降本增效’、优化团队时，你就知道疼了。”
四、评论区洞察：高频痛点与实践策略
4.1 高频痛点分析
社区讨论中，用户们总结出了AI编程工具当前几个最突出的痛点：
- 痛点一：AI的“幻觉”与不可预测性
一位评论者描述了一个经典场景：“AI的经典操作是，为了让测试用例通过（pass），它有时会生成奇怪的、不符合真实业务逻辑的代码，或者干脆直接跳过（skip）某些复杂测试，而不是去反思需求或逻辑本身是否合理。”
- 痛点二：上下文理解的局限性
对于稍具规模的项目，AI的上下文窗口长度仍是硬伤。多位开发者抱怨：“AI的上下文还是不够长，一个稍微复杂的模块，生成几次代码后就丢失了之前的全局信息，导致生成的代码前后不一致，项目变得不可维护。”
- 痛点三：心流打断与注意力碎片化
这个问题被反复提及：“‘等代码时刷短视频’这个描述太真实了！经常是等AI生成的时候顺手刷下手机，等回来时，已经完全忘记自己刚才在思考什么了。”
- 痛点四：调试与维护成本转嫁
一句生动的比喻道出了许多人的心声：“AI生成一时爽，调试维护火葬场。” 理解并修复一段并非自己亲手写出的、逻辑可能迂回的代码，有时比从头手写花费更多时间。
4.2 场景化策略与实践
面对痛点，社区也涌现出许多务实的“人机协作”策略：
- 策略一：分层的协作模式
一位答主清晰划分了人机职责：适合让AI做的事情包括——修复已知bug、讨论新功能原型、辅助代码审查（查漏补缺）、生成小型工具代码。绝不能完全依赖AI、放弃必要的Git版本管理、让编程新手直接进行“Vibe Coding”、在等待时彻底分散注意力。
- 策略二：明确的人机角色分工
一种被广泛认可的高效做法是：“先由开发者亲手搭建核心架构、定义关键接口和主流程逻辑，然后将实现细节、工具函数、数据验证等相对模式化的部分交给AI补充。这样既保证了架构的清晰可控，又大幅提升了编码效率。”
4.3 技术选型分歧
评论区也反映出开发者们在具体工具选型上的偏好差异，包括对 Claude、GPT、Gemini 等不同模型能力的评价，以及对“Tab键逐句补全”与“Agent全自动生成”两种使用模式的取舍。
五、行业趋势与适用场景
5.1 行业现状与场景分析
综合来看，AI编程工具在当下有其明确的优势与局限：
- 优势场景（适用）：
- 快速原型开发与业务概念验证。
- 生成重复性、模式固定的样板代码（如CRUD、DTO、简单API）。
- 辅助进行代码审查，发现潜在bug或安全漏洞。
- 作为学习和知识检索的“超级加速器”。
- 劣势场景（慎用/不适用）：
- 高度定制化、承载复杂业务规则的核心逻辑。
- 对性能有极端要求的底层系统、算法或数据结构。
- 需要长期维护、关乎系统命脉的核心模块。
- 真正的创新性算法设计与架构突破。
5.2 二八法则的实践应用
一位答主提出的“八二法则”获得了高度认同：“AI编程也符合帕累托法则。像NGINX这样的底层核心，属于那20%难以被替代的部分。但对于市场上80%的应用开发而言，首要目标是快速、可靠地交付业务价值，此时AI带来的效率优势就极具吸引力。”
5.3 团队与个人的差异化策略
不同角色的开发者，策略也明显不同：
- 个人开发者/创业者：更倾向于全面拥抱AI，追求极致的个人产出效率，快速验证想法。
- 中大型研发团队：态度更为谨慎，会制定内部使用规范，强调代码统一性、可读性和长期可维护性，AI辅助必须经过严格的Code Review。
- 企业决策层：态度出现分化，一部分激进的企业强制推行并采购企业版AI工具；另一部分则保持观望，或仅限于在非核心业务中试点。
六、未来展望
6.1 技术演进方向
未来的AI编程助手可能会在以下方向取得突破：
- 更强大的上下文理解：突破现有token限制，真正理解大型代码库的完整上下文和架构。
- 多智能体（Agent）协作生态：由多个具备不同专长的AI Agent协同完成设计、编码、测试、部署等完整工作流。
- 测试与验证体系的深度集成：AI不仅能生成代码，还能生成更智能、覆盖更全面的测试用例，并具备一定的逻辑自验证能力。
6.2 程序员角色的转变
一个清晰的趋势是：程序员的角色正在从“代码的编写者”（Coder）加速向“代码的设计者与审查者”（Designer & Reviewer）以及“需求的精确定义者”转变。核心价值将更多地体现在系统架构设计、复杂问题分解、关键技术选型和最终的代码质量把控上。
6.3 职业发展的分层建议
面对转变，不同阶段的开发者可以有不同的侧重点：
- 初级程序员：必须坚持手写核心代码逻辑，夯实基础。可以将AI作为强大的学习辅助和“参考答案”，但重点培养自己深度理解、批判性审查代码的能力。
- 中级程序员：积极探索AI工具的效能边界，建立并优化适合自己工作流的人机协作模式。同时，将更多精力投入到提升系统设计、模块化分解等高阶能力上。
- 高级程序员/技术负责人：主导团队内的AI工具选型与落地，建立相关的开发规范与质量门禁。另一个重要职责是：培养团队新人正确的“AI素养”，避免他们对工具产生过度依赖。
七、结论与建议
7.1 核心结论
- “古法”是一种理性选择：“古法编程”或对AI的审慎态度，并非技术进步的对立面，而是基于对代码质量、个人心智模式及长期职业发展的理性考量。
- AI的价值在于“放大”：当前AI编程工具的核心价值是“放大”优秀开发者的能力与效率，而非“替代”他们的思考与创造。
- 不可妥协的底线：无论是追求“心流”的深度工作状态，还是确保代码的长期可维护性，都是软件开发中不可妥协的底线。
- 新范式正在形成：行业正在快速演进并形成一种“人机协同”的新软件开发范式，如何在这种范式中找到自己的定位是关键。
- 角色定位的迁移：程序员的职业定位，正不可逆转地从“编码实现者”向“系统设计者与质量守护者”迁移。
7.2 实践建议
- 对个人开发者：主动建立并不断优化你的人机协作流程。在利用AI提速的同时，务必保留定期进行“无AI”深度编码练习的习惯，以保持对技术的“手感”和掌控力。
- 对团队管理者：尽早制定团队内部的AI工具使用指南与规范。建立针对AI生成代码的质量评估和审查标准，并将“AI素养”纳入团队人才培养的范畴。
- 对行业与社区：应积极推动AI工具在代码生成逻辑上更大的透明度。同时，建立和分享不同场景下的最佳实践，并关注其对计算机科学和软件工程教育体系的深远影响。关于这些前沿趋势的讨论，在云栈社区这样的技术论坛中总能引发有价值的思考。
7.3 写在最后
“古法编程”与“AI编程”之争，其本质早已超越了技术工具层面的优劣比较，它触及的是关于在智能时代，人类创造者如何定义自身价值、如何与机器协同共生的根本性思考。
在这个技术浪潮汹涌澎湃的时代，或许最重要的“古法”，并非某种具体的编码方式，而是那份保持开放心态、持续深度学习、并在纷繁信息中保有独立理性判断力的宝贵品质。这，才是每一位开发者穿越周期、持续成长的核心内功。
发表于 21 小时前
|
查看: 16|
回复: 0
