lijianfei.com

在生成式 AI 与 Coding Agent 以惊人速度重构软件研发范式的当下，“程序员即将消亡”、“写代码能力被 AI 100% 取代”的言论甚嚣尘上。不少跨界观察者断言：程序员除了敲代码啥也不会，未来属于稍微学点 AI 就能做出系统的各行业领域专家。

然而，中文互联网初代传奇黑客、三十年工程老兵 响马（@xicilion） 的一句轻描淡写的反击，如同一记重锤砸碎了这场狂欢幻觉：

“我说一件事吧。最近一周我花了大几十亿 token，一个新功能都没做出来，写的都是你说的没用的代码。”

随后，前微软工程师、知名技术思考者 宝玉（@dotey） 发布深度长文，从职业本质、工程交付鸿沟、能力双向迁移及 AI Native 组织演进等多维度进行系统拆解，彻底点燃了技术圈对“软件工程师真正护城河”的全网大讨论。

大几十亿 Token 砸下去，为什么一个新功能都看不见？那些外行眼中“没用的代码”到底是什么？从写出跑通的 Demo 到支撑现实商业世界，究竟横亘着怎样的工程天堑？

本文将以此为切入点，深度解构隐藏在代码表象之下的“软件工程暗冰山”，并探讨工程师在 AI 原生时代如何实现自我升维。

一、 论战风暴：外行傲慢与一线工程体感的激烈交锋

这场讨论之所以在技术圈引发海啸般的共鸣，是因为它直击了当前 AI 落地中最核心的认知撕裂。

flowchart TD
    subgraph Trigger["导火索：技术外行的降维断言"]
        ClaimA["“程序员除了写代码啥也不会，已被 AI 100% 替代”"]
        ClaimB["“金融、医疗、工业专家学一下 AI 就能搞定一切”"]
    end

    subgraph Defense["老兵反击：一线体感的工程重锤"]
        XiMa["响马：一周烧了大几十亿 Token，<br/>一个新功能没做出来，全是外行眼里『没用的代码』"]
    end

    subgraph DeepDive["体系剖析：宝玉的五维本质拆解"]
        D1["1. 代码仅是中间产物，软件开发本质是工程问题"]
        D2["2. 原型到上线存在天堑，懂 AI 本身就是高门槛工程学"]
        D3["3. 能力迁移是双向的，工程直觉是极难习得的元能力"]
        D4["4. 真正 AI Native：Agent 为执行主体，人类定义与验收"]
        D5["5. 抽象阶梯演进：工具升级只改变环节，推动职业升维"]
    end

    Trigger --> Defense
    Defense --> DeepDive

1. 认知误区：将“写代码”等同于“软件工程”

很多人认为“程序员的工作就是敲语法、写函数”，既然大模型能秒级生成一段 Python 脚本、甚至用 Prompt 拼凑出一个前端页面，那么软件开发者的存在价值自然被彻底清零。

宝玉一针见血地指出了这一逻辑的荒谬性：

严格说，从事软件开发这个职业的人叫软件工程师，不叫程序员。如果说“程序员唯一会的东西被 100% 取代”，这话跟说“医生唯一会的是开处方”差不多——处方反正可以百度搜索一份、AI 生成一份打印出来，所以医生没用了？

代码从来不是软件工程的目的，它仅仅是系统思维落地过程中的中间制品。

二、 响马那“大几十亿 Token”究竟在写什么？——解构软件工程的“暗冰山”

在非工程人员甚至浅层开发者的认知模型里，软件开发就是“看得到的界面 + 能点的按钮”。

但在真实且严酷的工业级生产环境中，看得见的代码往往不到整个系统的 10%，剩下的 90% 全是隐匿在海面之下、确保系统不至于在现实世界中粉身碎骨的“工程暗冰山”。

flowchart TD
    subgraph Visible["露在水面的 10%（外行眼里的『有用功能』）"]
        V1["页面 UI 布局与动效呈现"]
        V2["主流程 Happy Path 功能逻辑"]
        V3["本地演示 Demo 与原型跑通"]
    end

    subgraph Submerged["沉入水下的 90%（响马大几十亿 Token 打磨的『没用代码』）"]
        direction TB
        S1["防御性规格与类型契约（Schema Enforcement）"]
        S2["极端边界与混沌容错（Edge Cases & Mutation Test）"]
        S3["分布式状态一致性与事务补偿（Distributed Rollback & Idempotency）"]
        S4["并发竞态与死锁防御（Race Conditions & Lock Contention）"]
        S5["全链路遥测与可观测性（Tracing, Telemetry & OpenTelemetry）"]
        S6["安全护栏与沙箱最小权限隔离（Sanitization & Anti-Injection）"]
        S7["Coding Agent 失败模式治理与 Eval 基准测试套件（Eval Harness）"]
    end

    Visible --- Submerged

当响马这样身经百战的架构师在与 Coding Agent 连续对话一周、消耗数十亿 Token 时，他绝不是在让模型写简单的增删改查（CRUD），而是在为这庞大的水下冰山注入确定性：

1. 契约守卫与类型系统硬化（Contract Enforcement）

LLM 生成的代码天生具有“快乐路径（Happy Path）过载”的缺陷——它总假设输入参数永远规范、网络请求从不丢包、第三方 API 绝不出错。
为了让系统具备工业级稳健性，工程师必须驱使 Agent 编写庞大且严谨的入参校验、状态转移约束、契约断言与数据模式（Schema）守卫。这些代码在业务方眼里毫无“新功能”可言，但一旦缺少，系统在真实世界里活不过十分钟。

2. 分布式一致性与幂等容灾（Idempotency & Resilience）

在复杂的现实网络中，超时、重试、并发重复提交是日常。每一笔交易、每一个外部调用、每一次状态更新，都需要设计不可逆操作的幂等键（Idempotency Key）、分布式锁、Saga 补偿机制与崩溃恢复日志。这些支撑骨架的代码量往往数倍于业务本身。

3. Agent 协作的 Eval 评估体系与失败模式治理

当组织尝试让 AI Agent 自动化执行任务时，最昂贵也是最核心的工程工作，是编写用于约束和测试 Agent 行为的 基准评估套件（Eval Harness） ：

• 构造自动化回归测试集，捕捉 Agent 在迭代中引入的隐蔽退化（Regression）；
• 设计上下文治理防线，处理长对话下的“中间遗忘（Lost in the Middle）”与上下文污染；
• 编写边界 Mock 与混沌故障注入测试。

这些全是一线工程师在后台默默消耗数十亿 Token 所构筑的真正壁垒。

三、 Vibe Coding 的致命幻觉：从“原型跑通”到“生产可用”的五道天堑

近来在科技圈风靡的“Vibe Coding”概念，让许多人误以为只要凭借灵感向模型提要求，就能轻而易举孵化商业产品。

然而，做个跑通的 Demo 给自己用，与发布一个工业级产品给全网用户用，中间隔着五道深不可测的马里亚纳海沟：

flowchart LR
    Demo["个人 Demo / Vibe 原型<br/>(单用户、本地局域网、纯正常流)"]
    
    subgraph Chasms["从原型到生产的五道工程天堑"]
        C1["1. 概率黑盒 vs 严格确定性"]
        C2["2. 高并发竞态与状态漂移"]
        C3["3. 静默故障与渐进式架构腐蚀"]
        C4["4. 安全沙箱与合规渗透防御"]
        C5["5. 延迟预算与 Token 成本悬崖"]
    end

    Prod["工业级生产系统<br/>(高并发、毫秒级响应、容灾高可用、可审计)"]

    Demo --> Chasms --> Prod

“稍微懂点 AI 的领域专家”可以在半天之内搭出一个惊艳的演示原型，但当面对上述这五道天堑时，缺乏严谨工程训练的人甚至不知道系统在何时、以何种诡异方式走向崩溃。

四、 能力迁移的“元能力”不对称：显性知识 vs 隐性工程直觉

论战中，Leto Bao 提出“各行业专家只要稍微了解 AI 就能胜过程序员，因为程序员不懂行业业务”。

宝玉与一线工程师的共识则揭示了一个深刻的反常识：能力迁移固然是双向的，但 底层元能力（Meta-capabilities） 的迁移难度极度不对称。

flowchart TD
    subgraph DomainKnowledge["领域知识（行业专家资产）"]
        DK1["会计准则、医疗诊断指南、金融风控条例、工业流程"]
        DK2["特点：绝大多数属于『显性知识（Explicit Knowledge）』"]
        DK3["AI 时代迁移方式：极易结构化、文档化并作为上下文/RAG 注入"]
    end

    subgraph EngineeringIntuition["工程元能力（软件工程师资产）"]
        EI1["把模糊现实抽象为离散状态机"]
        EI2["对系统失败模式（Failure Modes）的病态级敏感"]
        EI3["复杂系统解耦、架构分层与性能调优直觉"]
        EI4["特点：大量源自线上事故与数万行代码实战的『隐性知识（Tacit Knowledge）』"]
    end

    DomainKnowledge -.->|极其容易被 AI 赋能学习| Engineer["软件工程师"]
    EngineeringIntuition x-.-x|极难通过短期『稍微了解』习得| Expert["传统行业专家"]

1. 显性知识的低壁垒化

金融结算规则、医疗诊断路径、工业生产 SOP，绝大多数是白纸黑字的显性知识。在 LLM 时代，这类知识能够以极高的效率被整理、向量化，并精准投递进大模型的上下文窗口中。一个具备严密逻辑能力的软件工程师，借助 AI 辅助，可以在极短时间内掌握特定业务领域的核心运转逻辑。

2. 隐性工程直觉的无法速成

反观软件工程的核心能力——如何将一个混乱的需求抽象成高内聚低耦合的架构？如何预判一段异步代码在毫秒级并发下的竞态条件？如何设计能在灾难断网时无损自愈的数据同步协议？

这些工程直觉是经过无数次线上故障、内存泄漏排查、架构重构毒打出来的隐性经验。这种“系统思维”与“对失败的嗅觉”，绝非外行“稍微了解一下 AI”所能凭空获得的。

五、 重新定义 AI Native：是“人带 AI 工具”还是“Agent 驱动 + 人类把关”？

宝玉在博文中分享过他对“AI 原生（AI Native）”的底层判定准则：

“判断一家公司是不是 AI Native，看它做事的流程是围绕人设计的，还是围绕 AI Agent 设计的。AI 原生的核心是：AI Agent 是执行主体，人负责定义问题和验收结果。如果只是在原来的流程里加一点 AI，那不叫 AI 原生。”

flowchart TD
    subgraph LegacyFlow["伪 AI Native：人在回路中心（传统旧流程打补丁）"]
        direction LR
        DevH["人类工程师"] -->|写代码手敲| CodeH["代码库"]
        DevH -.->|偶尔让 Copilot 补个全| AIChat["AI 对话框"]
        DevH -->|排查 Bug/部署| ProdA["生产环境"]
        NoteA["瓶颈：人类的打字速度与认知带宽仍是吞吐上限"]
    end

    subgraph NativeFlow["真正的 AI Native：Agent 自主执行网络 + 人类裁判席"]
        direction TB
        Architect["人类工程师（系统架构师 / 裁判）"]
        
        subgraph SpecEval["人类核心阵地"]
            Spec["1. 严格规格定义（PRD & Schema）"]
            Eval["2. 基准评测集构建（Eval Harness）"]
        end

        subgraph AgentSwarm["AI Agent 执行集群（执行主体）"]
            direction LR
            CoderAgent["Coding Agent<br/>(自主写代码)"]
            ReviewAgent["Review Agent<br/>(静态安全分析)"]
            TestAgent["Test Agent<br/>(混沌边界测试)"]
        end

        Architect --> SpecEval
        SpecEval --> AgentSwarm
        AgentSwarm --> OutputValidation{"自动化评测通过?"}
        OutputValidation -->|未通过| AgentSwarm
        OutputValidation -->|通过| Deploy["自动化安全部署"]
        Architect -.->|最终验收与权责背书| Deploy
    end

在很多团队自称“AI 驱动”的今天，大部分人做的仅仅是在已有旧流程中挂一个 AI 侧边栏，这不过是把“翻看 Stack Overflow”换成了“向大模型提问”，本质上人类依然是低效的执行瓶颈。

在真正的 AI 原生研发范式中：

1. 执行主体彻底易位：让 Agent 集群全天候负责代码编写、语法重构、基准测试跑通与代码审查；
2. 人类职责全面升维：人类工程师从繁琐的语法敲击中抽身，转向顶层的 规格制定（Specification Engineering） 、 评测集搭建（Eval Engineering） 与 生产兜底 。

六、 抽象阶梯的跃迁史：软件工程师到底“死”过多少次？

回顾计算机科学近七十年的发展史，类似“某种职业要彻底消失”的恐慌其实周期性上演：

flowchart LR
    P0["1950s 纸带打孔时代<br/>打孔员: 汇编出现，我们完了"] --> 
    P1["1960s 汇编语言时代<br/>汇编师: Fortran/C 是玩具，效率太低"] --> 
    P2["1990s 4GL 可视化拖拽<br/>VB/Delphi: 鼠标拖拽搞定，程序员失业"] --> 
    P3["2010s 云原生与微服务<br/>运维: Serverless 普及，运维工程师消失"] --> 
    P4["2020s Coding Agent 时代<br/>外行: 写代码被取代，工程师清零"]

历史给出的答案惊人的一致：每一次工具抽象层级的跃迁，被消灭的都只是低维度的语法体力劳动；而伴随而来的，是软件工程对现实物理世界更大规模、更深层次的吞吐与渗透。

这正是经济学上的 杰文斯悖论（Jevons Paradox） ：
当编写单行代码的边际成本趋近于零时，人类对高质量、高复杂度软件系统的需求不仅不会减少，反而会呈几何级数爆发！

工程师的重心在过去几十年间从未停止升维：
管理物理内存与寄存器 → 编写高级业务逻辑 → 规划分布式微服务治理 → 编排自主 Agent 集群并定义系统规格。

七、 一线工程师在新时代的突围纲领（Actionable Framework）

面对 Coding Agent 的狂暴演进，一线开发者绝不能坐以待毙，但也无需陷入虚无主义的焦虑。确立以下三大核心能力，是实现自我跃迁的工程护城河：

1. 从“编写实现”转向“规格驱动（Spec-First Engineering）”

未来衡量一名优秀工程师的标准，不再是他手敲代码有多快，而是他能否以极其清晰、无二义性、结构化的方式定义 系统规格（Specifications） ：

• 熟练运用 JSON Schema、Protocol Buffers、OpenAPI 等强约束语言定义接口与状态机；
• 具备将业务方模糊多变的大白话，精准翻译为确定性边界约束与前置/后置断言的建模能力。

2. 深入钻研“评测工程学（Eval Engineering）”

当代码由 Agent 批量生成时，谁拥有验证 Agent 产出正确性的能力，谁就掌握了生产的核心权力：

• 为复杂业务设计确定性与模糊性兼具的自动化评测流（Evals）；
• 学会用混沌工程（Chaos Engineering）与突变测试（Mutation Testing）去探测 Agent 代码中隐匿的逻辑盲区。

3. 深耕底层系统原理与“失败模式嗅觉”

无论 AI 多么聪明，它终究是在概率空间中进行模式匹配。
当分布式系统发生未知原因的内存泄漏、连接池耗尽、TCP 丢包雪崩或死锁时，唯有真正深入理解 Linux 内核、网络协议栈、数据库底层存储引擎与现代硬件特性的工程师，才能在千钧一发之际完成故障定界与系统挽救。

八、 结语

响马那“大几十亿 Token 换不来一个新功能”的自白，不是技术的停滞，而是真正的现代软件工程在 AI 时代展现出的庄严与从容。

代码可以由大模型成吨吐出，但对复杂现实的理解、对系统灾难的敬畏、对架构优雅的追求，以及对生产环境稳定运行所承担的终极责任，始终深深植根于人类工程师的理性之中。

大浪淘沙之后，被时代抛弃的从来不是软件工程师，而是那些只会做大模型搬运工、拒绝理解系统本质的浅层打字员。