工程师的定义：长期维护与持续交付

核心命题：AI时代的开发者应被视为”工程师”，而非”码农”。工程的核心不是写代码，而是长期维护一个有生命力的系统。

🧠 逻辑记忆框架

口诀：「品 → 转 → 配 → 衡」 —— 有品味 → 能转型 → 会搭配 → 懂平衡

分组记忆（2×2 矩阵）：

递进逻辑：

• 第①步：知道什么叫好代码（品味 = 长期维护的能力）
• 第②步：知道AI Coding该怎么走（工程体系化，而非次抛）
• 第③步：知道基模和Agent怎么配合（魔法棒 vs 助手）
• 第④步：知道多模型多Agent怎么管（成本与质量的永恒博弈）

一、核心观点总览

二、工程师的定义：长期维护与持续交付

2.1 码农 vs 工程师：一字之差，天壤之别

DeerFlow 的何涛首先提出，AI时代的开发者应被视为”工程师”，而非”码农”。

graph LR
    subgraph "码农 Coder"
        C1["📋 接收任务"] --> C2["⌨️ 写代码"]
        C2 --> C3["📤 交付"]
        C3 --> C4["👋 结束"]
    end
    subgraph "工程师 Engineer"
        E1["📋 理解需求"] --> E2["🏗️ 设计系统"]
        E2 --> E3["⌨️ 编码实现"]
        E3 --> E4["🔄 持续维护"]
        E4 --> E5["📈 迭代进化"]
        E5 -.-> E2
    end
    style C4 fill:#ffebee,stroke:#c62828
    style E5 fill:#e8f5e9,stroke:#2e7d32

[!important] 何涛的核心洞察 当前的AI模型在Benchmark上表现出色，但在实际应用中，需要将人类长期维护项目的“品味”（Taste）注入其中，才能实现持续的迭代和维护。品味 = 知道什么时候代码该改、什么时候不该改、什么时候该重构、什么时候该忍住。

三、对话MiniMax闫俊杰：M3突破与10T模型

3.1 MiniMax 的关键进展

graph TD
    subgraph "MiniMax 战略版图"
        M1["🧠 M3 模型突破<br/><i>性能飞跃</i>"]
        M2["🏗️ 10T 大模型<br/><i>训练决心</i>"]
        M3["🌐 中美差距分析<br/><i>清醒认知</i>"]
        M4["📊 数据观转向<br/><i>质量 > 数量</i>"]
        M5["🤝 10X专家合作<br/><i>开放生态</i>"]
    end
    M1 --> M2
    M2 --> M3
    M3 --> M4
    M4 --> M5
    style M1 fill:#e3f2fd,stroke:#1565c0
    style M2 fill:#fff3e0,stroke:#e65100
    style M3 fill:#f3e5f5,stroke:#6a1b9a
    style M4 fill:#e8f5e9,stroke:#2e7d32
    style M5 fill:#fce4ec,stroke:#c62828

四、AI Coding的拐点：工程体系 vs 次抛代码

4.1 从”次抛”到”工程”的范式跃迁

闫俊杰指出，AI Coding正迎来一个拐点——从”次抛代码”（一次性任务）转向工程体系化。

graph LR
    A["🗑️ 次抛代码<br/><i>用完即弃</i>"] -->|"拐点"| B["🏗️ 工程体系<br/><i>持续维护</i>"]
    A -.- C["特征：<br/>无测试、无文档<br/>无版本控制"]
    B -.- D["特征：<br/>可维护、可迭代<br/>有品味注入"]
    style A fill:#ffebee,stroke:#c62828
    style B fill:#e8f5e9,stroke:#2e7d32

[!warning] 次抛代码的隐患 次抛代码看似高效——AI秒出方案，复制粘贴即用。但它积累了隐性技术债：无人维护、无测试覆盖、无架构一致性。当AI生成的代码量指数级增长时，技术债也将指数级爆炸。

4.2 工程体系化的四大支柱

flowchart TD
    subgraph "AI Coding 工程体系"
        P1["📐 架构设计<br/><i>系统骨架</i>"]
        P2["🧪 测试体系<br/><i>质量保障</i>"]
        P3["🔄 持续迭代<br/><i>生命力</i>"]
        P4["👁️ 品味注入<br/><i>人类智慧</i>"]
    end
    P1 --- P2
    P2 --- P3
    P3 --- P4
    P4 --- P1
    style P1 fill:#e3f2fd,stroke:#1565c0
    style P2 fill:#fff3e0,stroke:#e65100
    style P3 fill:#e8f5e9,stroke:#2e7d32
    style P4 fill:#f3e5f5,stroke:#6a1b9a

五、基模与Agent：是什么关系？

5.1 “魔法棒” vs “助手”

闫俊杰将基模比作”魔法棒”，Agent比作”助手”——二者是互补而非替代的关系。

flowchart LR
    subgraph "基模 Base Model"
        BM["🪄 魔法棒<br/><i>直接执行复杂任务</i>"]
    end
    subgraph "Agent"
        AG["🤖 助手<br/><i>处理具体、长期维护</i>"]
    end
    subgraph "未来方向"
        FU["📜 人类先哲思想<br/><i>Clean Code 等</i>"]
        FU -->|"蒸馏为技能"| AG
        AG -->|"调用能力"| BM
    end
    style BM fill:#e3f2fd,stroke:#1565c0
    style AG fill:#fff3e0,stroke:#e65100
    style FU fill:#f3e5f5,stroke:#6a1b9a

[!tip] 关键洞察 将人类的”清洁代码”（Clean Code）等工程先哲思想蒸馏成技能，再注入Agent——这是未来的重要方向。换句话说：不是教AI写代码，而是教AI如何像工程师一样思考。

5.2 知识蒸馏路径

flowchart TD
    H1["📜 人类工程智慧<br/><i>Clean Code · SOLID · DRY</i>"] -->|"提取原则"| D1["🧬 技能定义<br/><i>可执行的行为规范</i>"]
    D1 -->|"蒸馏"| D2["📦 技能包<br/><i>注入 Agent</i>"]
    D2 -->|"运行"| D3["🤖 有品味的 Agent<br/><i>不只是写代码<br/>而是写好代码</i>"]
    style H1 fill:#f3e5f5,stroke:#6a1b9a
    style D1 fill:#fff3e0,stroke:#e65100
    style D2 fill:#e3f2fd,stroke:#1565c0
    style D3 fill:#e8f5e9,stroke:#2e7d32

六、多模型与多Agent：平衡成本与质量

6.1 成本-质量博弈模型

Multica创始人张佳圆认为，在成本和质量之间取得平衡是关键，多模型、多Agent的组合是一种有效思路。

flowchart TD
    T["📋 任务输入"] --> Q{"任务复杂度？"}
    Q -->|"简单"| SM["⚡ 小模型<br/><i>低成本 · 快速</i>"]
    Q -->|"中等"| MM["🔧 中模型<br/><i>性价比均衡</i>"]
    Q -->|"复杂"| LM["🧠 大模型<br/><i>高质量 · 高成本</i>"]
    SM --> R["📤 输出结果"]
    MM --> R
    LM --> R
    R --> V{"质量评估"}
    V -->|"达标"| DONE["✅ 交付"]
    V -->|"不达标"| UPGRADE["⬆️ 升级到更大模型"]
    UPGRADE --> R
    style SM fill:#e8f5e9,stroke:#2e7d32
    style MM fill:#fff3e0,stroke:#e65100
    style LM fill:#ffebee,stroke:#c62828
    style DONE fill:#e8f5e9,stroke:#2e7d32

6.2 多模型多Agent组合策略

[!note] 张佳圆的核心观点 AI的价值在于将信息转化为可执行的决策路径，并在高频变化中为用户提供辅助与陪伴。多模型不是炫技，而是经济学——用最少的Token实现最好的结果。

七、逻辑记忆：一页全景图

flowchart TD
    A["① 工程师 ≠ 码农<br/><i>长期维护 > 一次性编码</i>"] --> B["② AI Coding 拐点<br/><i>次抛代码 → 工程体系化</i>"]
    B --> C["③ 基模 + Agent<br/><i>魔法棒 + 助手 = 完整体系</i>"]
    C --> D["④ 多模型多Agent<br/><i>成本与质量的动态平衡</i>"]
    D --> E["⑤ 人类品味是核心<br/><i>Clean Code 蒸馏为 Agent 技能</i>"]
    style A fill:#e3f2fd,stroke:#1565c0
    style B fill:#fff3e0,stroke:#e65100
    style C fill:#f3e5f5,stroke:#6a1b9a
    style D fill:#e8f5e9,stroke:#2e7d32
    style E fill:#fce4ec,stroke:#c62828

🧠 五步递进链：

八、正在发生的案例

[!abstract] 本章定位 以下案例全部来自 2024–2026 年真实发生的事件，精确对应前文每一个核心论点。

📊 案例全景映射表

案例 1：Devin — 从”AI工程师”到”AI码农”的教训 🤖

对应理论：§二 码农 vs 工程师 / §四 次抛代码的隐患

[!warning] 核心教训 Devin 完美印证了何涛的观点：能写代码 ≠ 工程师。 Devin 是超级”码农”——能快速完成编码任务，但缺乏长期维护系统的”品味”。工程的核心是生命周期管理，不是一次性交付。

案例 2：Claude Code — AI Coding 工程体系化的范本 💻

对应理论：§四 工程体系化 / §五 基模+Agent

Claude Code 的架构完美体现了”工程体系 vs 次抛代码”的分野：

[!tip] 关键洞察 Claude Code 的成功不在于模型多聪明，而在于它把工程实践编码进了系统——这就是闫俊杰所说的”将Clean Code蒸馏为Agent技能”的最佳实践。

案例 3：MiniMax M3 与 10T 路线 🏗️

对应理论：§三 模型突破与数据观转向

graph LR
    subgraph "旧数据观"
        O1["📊 追求数据量"] --> O2["📈 规模定律"]
    end
    subgraph "新数据观"
        N1["💎 追求数据质量"] --> N2["🧬 专家知识蒸馏"]
        N2 --> N3["🎯 精准训练"]
    end
    O1 -.->|"转向"| N1
    style O1 fill:#ffebee,stroke:#c62828
    style N3 fill:#e8f5e9,stroke:#2e7d32

案例 4：Multica — 多Agent组合的经济学 🎯

对应理论：§六 成本与质量的动态平衡

Multica 张佳圆的实践展示了多模型多Agent组合的落地路径：

张佳圆的核心理念：AI的价值 = 将信息转化为可执行的决策路径，在高频变化中为用户提供辅助与陪伴。

案例 5：SWE-bench — 品味的机器化尝试 🧪

对应理论：§四 品味注入 / §五 知识蒸馏

[!note] 深层含义 SWE-bench 本质上是在尝试把”什么是好代码”的品味部分形式化——用测试用例来定义”够了”。这是闫俊杰所说的”将Clean Code蒸馏为技能”的第一步。

九、最高级思考问答 · 全文终极总结

[!abstract] 本章定位 以 层层递进的 7 个终极问答，将全文从”是什么→为什么→怎么办→去哪里”完整串联。

Q1 · 本质追问：为什么”品味”是工程师的核心？

对应：§二 工程师的定义

追问：品味（Taste）听起来很主观，为什么它反而最重要？

回答：因为品味是隐性知识的显性表达。

[!quote] 深层洞察 品味不是玄学，而是长期维护经验凝结成的直觉。 AI可以学显性知识，但学不了品味——除非人类先把品味”蒸馏”成可执行的规则。这就是为什么工程师比码农更难被替代。

Q2 · 拐点追问：次抛代码真的有问题吗？

对应：§四 工程体系 vs 次抛代码

追问：如果AI能秒出代码，为什么不一直用次抛模式？

回答：因为代码不会消失，它会积累。

flowchart TD
    subgraph "次抛模式的幻觉"
        I1["💡 有需求"] --> I2["🤖 AI秒出代码"]
        I2 --> I3["✅ 问题解决"]
        I3 -.->|"看起来高效"| I4["🎉 皆大欢喜？"]
    end
    subgraph "累积的现实"
        R1["💡 需求1"] --> R2["🤖 代码1"]
        R3["💡 需求2"] --> R4["🤖 代码2<br/>与代码1风格不同"]
        R5["💡 需求3"] --> R6["🤖 代码3<br/>与代码1冲突"]
        R2 --> R7["💥 技术债爆发"]
        R4 --> R7
        R6 --> R7
    end
    style I4 fill:#fff8e1,stroke:#f57f17
    style R7 fill:#ffebee,stroke:#c62828

一句话答案：次抛模式的成本不在写的那一刻，而在改的每一天。

Q3 · 架构追问：基模和Agent的边界在哪？

对应：§五 基模与Agent

追问：如果基模越来越强，Agent会不会被取代？

回答：不会。因为“做对的事”和”把事做对”是两个不同的问题。

类比：基模 = 一个极聪明但失忆的顾问（每次都要重新了解情况）；Agent = 一个记得所有上下文的助手（能持续跟进）。即使顾问越来越聪明，你仍然需要一个助手来记住、跟进、执行。

Q4 · 经济追问：多模型策略的终局是什么？

对应：§六 成本与质量

追问：随着模型越来越强、越来越便宜，多模型策略会不会消失？

回答：不会消失，但分界线会上移。

graph TD
    subgraph "2024: 分界线在低端"
        A1["🤖 大模型<br/>复杂任务"] 
        A2["📱 小模型<br/>简单任务"]
    end
    subgraph "2026: 分界线上移"
        B1["🧠 超大模型<br/>极复杂任务"]
        B2["🤖 中模型<br/>常规任务"]
        B3["⚡ 小模型<br/>极简任务"]
    end
    subgraph "未来: 分界线继续上移"
        C1["🌟 巨型模型<br/>极端任务"]
        C2["🧠 大模型<br/>复杂任务"]
        C3["🤖 中模型<br/>常规任务"]
        C4["⚡ 小模型<br/>极简任务"]
    end
    style A1 fill:#ffebee,stroke:#c62828
    style B1 fill:#ffebee,stroke:#c62828
    style C1 fill:#ffebee,stroke:#c62828

一句话答案：多模型策略的本质是资源分配问题——只要资源有限（时间、算力、金钱），分层就永远存在。

Q5 · 实践追问：我如何成为”工程师”而非”码农”？

对应：§二 + §四 + §五

追问：作为一个开发者，我今天该怎么做？

回答：三个层次的转型路径——

[!tip] 行动建议 从今天开始，不再问”AI能帮我写多少代码”，而是问”AI写的代码，我能维护多久”。 这个问题本身，就是品味的起点。

Q6 · 终局追问：AI时代的”工程师”最终长什么样？

对应：全文综合

追问：如果把所有线索串起来，AI时代的工程师到底需要什么能力？

回答：

flowchart TD
    subgraph "AI时代工程师的能力模型"
        T["🧭 品味 Taste<br/><i>知道什么是对的</i>"]
        S["🏗️ 系统思维<br/><i>知道整体怎么运作</i>"]
        D["🧬 蒸馏能力<br/><i>把经验编码为规则</i>"]
        B["⚖️ 平衡感<br/><i>在成本和质量间抉择</i>"]
        E["👁️ 评估力<br/><i>判断AI输出的好坏</i>"]
    end
    T --- S
    S --- D
    D --- B
    B --- E
    E --- T
    style T fill:#f3e5f5,stroke:#6a1b9a
    style S fill:#e3f2fd,stroke:#1565c0
    style D fill:#fff3e0,stroke:#e65100
    style B fill:#e8f5e9,stroke:#2e7d32
    style E fill:#fce4ec,stroke:#c62828

Q7 · 终极追问：一句话总结这一切？

回答：

[!quote] 全文终极总结 AI时代的工程师，不是写代码最快的人，而是知道什么代码值得写的人。 工程的核心是长期维护一个有生命力的系统——这需要品味、需要体系、需要平衡、更需要人类的判断力。 当AI能写出所有代码时，定义”好代码”的人，就是最有价值的人。

十、全文总结 · 一页速览

📊 全文知识体系总表

十一、记忆宫殿

宫殿选址：想象你走进一座现代化智能工厂

🚪 第一进·工厂大门（工程师 vs 码农）

大门口站着两个人：

• 左边：一个工人快速砌砖，砌完一面墙就走（= 码农），身后的墙歪歪斜斜
• 右边：一个工程师拿着放大镜在检查每块砖的位置（= 品味），身后是一栋稳固的大楼
• 门楣上刻着：“砌墙者走，养楼者留”

🧠 记忆锚点：放大镜 = 品味，歪墙 = 次抛，稳楼 = 长期维护。工程师的核心是维护，不是建造。

🏗️ 第二进·主车间（AI Coding 拐点）

车间里两条生产线：

• 左边：🗑️ 传送带上不断产出纸杯（= 次抛代码），用完就扔，地上堆满废弃纸杯
• 右边：🏗️ 传送带上产出的是一台台精密仪器，每台都有编号、说明书、维护记录
• 车间主任在两条线之间挂了一块牌子：“拐点：纸杯 → 仪器”

🧠 记忆锚点：纸杯 = 次抛代码（快但浪费），仪器 = 工程体系（慢但持久）。拐点 = 从纸杯思维转向仪器思维。

🔨 第三进·锻造台（基模与Agent）

锻造台上放着两样工具：

• 🪄 魔法棒（= 基模）：一挥就能变出任何东西，但用完就消失
• 🤖 小助手（= Agent）：手里拿着一本手册（= Clean Code蒸馏的技能包），能持续工作
• 锻造师对它们说：“魔法棒负责威力，助手负责持久”
• 墙上的蓝图写着：“先蒸馏人类智慧 → 注入助手 → 助手调用魔法棒”

🧠 记忆锚点：魔法棒 = 基模（强大但短暂），手册 = 蒸馏后的Clean Code，小助手 = Agent（持久且有品味）。

🎛️ 第四进·调度中心（多模型多Agent）

调度中心的墙上布满仪表盘：

• 💰 成本表：每个Agent消耗多少Token
• 📊 质量表：每个Agent的输出质量评分
• ⚖️ 平衡秤：左边放着金币（成本），右边放着钻石（质量），指针在中间摇摆
• 调度员的话：“不是所有任务都需要钻石，但所有任务都不能亏本”
• 三种调度模式：级联（先小后大）、分工（各司其职）、竞争（择优录取）

🧠 记忆锚点：平衡秤 = 成本vs质量的核心博弈。三种模式 = 级联/分工/竞争。调度员 = 经济学思维。

🧭 第五进·厂长办公室（品味与终极价值）

办公室很简洁，只有一张桌子和一个指南针：

• 桌上刻着今天的核心公式：“工程师 = 品味 × 系统思维 × 蒸馏能力”
• 指南针不指北，指着四个方向：品 → 转 → 配 → 衡 → 归人
• 窗户望出去，整个工厂尽收眼底：大门（定义）→ 车间（拐点）→ 锻造台（架构）→ 调度中心（运营）
• 桌上的话：“当AI能写所有代码时，定义’好代码’的人最有价值”

🧠 记忆锚点：指南针 = 品味（知道方向），公式 = 工程师新定义。五字口诀 = 品转配衡人。

🧠 宫殿快速回顾

📎 逻辑记忆总链

1
2
3
4
5
工厂大门（工程师=养楼者，品味是放大镜）
  → 主车间（拐点=纸杯→仪器，工程体系化）
    → 锻造台（魔法棒+手册=基模+Agent，Clean Code蒸馏）
      → 调度中心（平衡秤=成本vs质量，多模型经济学）
        → 厂长办公室（指南针=品味，一切回到人的判断力）

走过一遍工厂，五重智慧尽入心中。 🏭

💎 一句话带走：别问”AI能写多少代码”，问”这些代码我能维护多久”——答案就藏在你的品味里。

参考来源：MiniMax Dev Meetup 圆桌讨论 · Koji 对谈 MiniMax CEO 闫俊杰、Multica 创始人张佳圆、DeerFlow 核心负责人何涛、金融行业AI负责人虞扬

• Previous
  情绪是武器，不是枷锁 —— 处世中的情绪博弈论
• Next
  企业AI化推不动的真正原因：不是技术，是人心