从写代码到管 Agent：斯坦福 AI 软件开发课讲师眼中的未来工程

软件开发的范式正在经历一场前所未有的重构：从亲手编织每一行代码，转变为管理一群不知疲倦的 AI Agent。这一转变不仅改变了工作流，更重塑了工程师的技能树。斯坦福大学 CS146S“The Modern Software Developer”课程的讲师 Mihail Eric 指出，大多数工程师尚未准备好迎接这一挑战。本文将深入探讨 AI 原生时代的工程师生存法则、Agent 管理的艺术以及代码库的进化方向。

AI Coding
图片来源：Unsplash

初级开发者的“三重风暴”：就业市场的寒冬与转型

核心问题：为什么当下的初级工程师面临着前所未有的就业困境？

这不仅仅是经济周期的波动，而是三股力量叠加形成的“完美风暴”。初级开发者正处于结构性调整的风暴中心，面临着供需关系的剧烈失衡。

风暴的三个维度

Mihail Eric 分享了一个令人深思的案例：一位 Berkeley 毕业生投递了约 1000 份简历，最终只收到了 2 个回复——仅仅是回复，而非面试邀请。这并非个例，其背后的根源在于三重因素的共振：

  1. 后疫情时代的裁员潮：2021 年前后，许多科技公司进行了过度招聘。随后的经济下行迫使企业进行大规模裁员。残酷的现实是，许多公司发现砍掉 20% 甚至 30% 的员工后，业务依然能够正常运转，这导致了企业对招聘变得更加谨慎。
  2. 人才供给的激增：计算机科学（CS）专业的毕业生数量在过去十年间翻了两到三倍。人才市场的供给端急剧膨胀，加剧了竞争的激烈程度。
  3. AI 对招聘逻辑的重构：雇主开始重新算账。面对任务，他们不再单纯思考“需要招多少人”，而是权衡“是否可以用更少的人配合 AI 完成”。AI 原生能力的出现，使得企业在招聘时更倾向于寻找那些能驾驭工具的高效能人才，而非单纯的人力堆砌。

AI 原生转型的必然性

这代初级开发者将成为“AI 原生转型”的第一代。他们面临的挑战是双重的：既要具备扎实的传统基本功（算法、系统设计、编程语言），又要拥有完整的 AI 原生能力。这两者不再是“锦上添花”，而是生存的“必选项”。

“

反思与见解：
这种困境看似绝望，实则是一次残酷的筛选。传统的“只会写代码”的工程师正在贬值，而懂得“用代码指挥 AI”的架构型工程师正在崛起。对于初级开发者而言，与其抱怨环境，不如审视自己是否已经掌握了这把新的钥匙。

AI 原生工程师的核心定义：管理 Agent 的新艺术

核心问题：AI 原生工程师究竟需要具备什么样的核心素质？

AI 原生工程师并非只是会调用 API 的程序员。他们是在传统编程底座之上，叠加了高效 Agent 编排能力的指挥官。然而，在通往顶尖工程师的道路上，存在一个巨大的误区。

拒绝“多 Agent 焦虑”

在 Claude Code 创造者 Boris Cherny 分享了他同时运行 10 个甚至更多 Agent 的工作流后，社区内产生了一种误解：仿佛高效就必须同时启动大量 Agent。Mihail Eric 强调，这是一个危险的误区。

正确的路径是“逐步搭建”：

  • 阶段一：先用一个 Agent 完成一件复杂的事。彻底跑通流程，确认你完全理解并能掌控它。
  • 阶段二：寻找隔离任务。例如，在主代码开发的同时，安排另一个 Agent 修复 Logo 或修改文案。这些任务必须互不依赖。
  • 阶段三：逐步扩容。只有当第一个 Agent 稳定运行，且你有余力管理第二个时，才考虑增加新的 Agent。

管理多个 Agent 就像游戏中的“最终 Boss”。能做到这一点的人，在今天已是顶尖的 0.1%。盲目追求数量，只会导致系统失控。

上下文切换：真正的难点

管理 Agent 的核心难点不在于技术配置，而在于“上下文切换”。

想象一下，你管理着一群热情但有时会犯错的实习生。Agent 就是这些实习生。它们会在终端里飞快地输出代码，但也可能卡在某一步。

  • 场景模拟：
    Agent 1 正在编写核心逻辑，突然卡住了。你需要立刻切换到 Agent 1 的上下文，理解它的困境并给出指令。
    紧接着，Agent 2 报告文案修改完成，但格式有问题。你又要迅速切回 Agent 2 的语境。

这种频繁的思维跳跃，对人类的认知负荷极高。这解释了一个现象：那些有过人类团队管理经验的工程师，往往更容易成为优秀的 Agent 管理者。 因为他们习惯了在信息不完整的情况下做决策，习惯了多线程的任务分配。

“

反思与见解：
这不仅是技术能力的竞争，更是管理能力的平移。过去我们认为“不想做管理的程序员不是好码农”，现在变成了“不会管理 Agent 的程序员写不出好代码”。单兵作战的时代正在落幕，指挥作战的时代已然来临。

打造 Agent 友好的代码库：从“能跑”到“严谨”

核心问题：如果将 Agent 投放到现有的代码库中，它能理解发生了什么吗？

这是衡量代码库质量的新标准。Agent 友好的代码库，本质上是对人更友好的代码库。在 AI 时代，过去那些“最好这么做”的最佳实践，变成了必须遵守的硬性约束。

测试即“合约”

Agent 如何知道自己没有搞坏东西？靠测试。

在传统开发中，测试不足可能只是导致排查困难；但在 Agent 开发中，测试不足意味着“无法定义正确性”。

  • 关键原则：Agent 只能基于显式定义的合约运作。测试覆盖不足，等于没有给 Agent 立规矩。
  • 场景对比：

    • 反例：代码库缺乏单元测试，Agent 修改了一处逻辑，引发了未知的连锁反应，导致系统崩溃。
    • 正例：完善的测试套件覆盖核心路径。Agent 修改代码后运行测试，测试失败立即反馈，Agent 根据报错自动修正方向。

文档与代码的一致性

“README 写完就过时”是开发界的顽疾。代码实现了功能 A，README 还在描述功能 B。

对于人类开发者，看到矛盾时可能会去问同事；但对于 Agent，这种矛盾是致命的。它会陷入逻辑死循环：到底该信文档还是信代码？

解决策略：建立强制同步机制。代码变更时，必须同步更新相关文档。这不再是为了好看，而是为了让 Agent 拥有唯一的真理来源。

防止错误的“滚雪球效应”

Agent 有一个特性：它会基于错误继续犯错。

如果 Agent 在第一步误解了需求，生成了错误代码，它不会自动意识到这是错的，而是会将这段错误代码视为正确的基础，继续叠加新的逻辑。最终，代码会变成一锅难以理清的“意面代码”。

操作清单：

  1. 初始化至关重要：在 Agent 接手前，确保第一版代码是自洽、设计完善且测试充分的。
  2. 原子化提交：让 Agent 每次只做一件小事，并在该步骤完成后立即验证，阻断错误蔓延。

设计模式的统一性

如果代码库中存在两种创建对象的方式（例如 API 1 和 API 2），Agent 会不知所措。

Mihail Eric 提到：“如果我走进你的代码库，看到两种不同的做法，我也会问自己该用哪个。”Agent 不会猜测，它只会随机选择或陷入停滞。

优化建议：在代码库中严格执行统一的设计模式和 API 规范。这不仅是为了美观，更是为了降低 Agent 的决策成本和犯错概率。

Clean Code
图片来源：Unsplash

品味：区分功能性与卓越的分界线

核心问题：在 AI 能够快速生成代码的时代，什么决定了软件的平庸与卓越？

答案是“品味”。AI 可以让软件从 0 到 1 变得触手可及，但从 90 分到 99 分的“最后一公里”，依然取决于工程师的品味。

最后一公里的坚持

在 CS146S 课程中，很多学生完成基础功能要求（如五个功能流程）后就停下了。这代表软件“能用”。但顶尖的学生不同。

  • 真实案例：有些学生在拿到满分后，依然在打磨应用，扩展功能，使其更健壮。他们关注的是解决问题本身，而非仅仅是完成任务。
  • 结果差异：这些在“最后一公里”持续投入的学生，往往也是那些围绕课程项目开始创业的人。

顶尖工程师不会在任务完成时停下，他们在发现可能性时加速。

实验精神：像 Anthropic 一样迭代

即使是 Anthropic 这样顶尖的团队，也在不断试错。Boris Cherny 曾透露，Claude Code 团队每 1-2 周就会用 Claude 重写 Claude Code 本身。

他们没有“标准答案”，而是在不断的自我迭代中寻找最优解。对于工程师而言，最重要的能力不是“知道最佳实践”，而是“通过实验找到最佳实践”。

“

反思与见解：
品味听起来很抽象，但在 AI 时代，它变得具象化了。品味就是当 AI 生成了 10 个方案时，你一眼就能挑出那个最能解决用户痛点、架构最优雅的方案。这种判断力，是任何模型都无法替代的。

初级工程师的超能力与过度工程化的陷阱

核心问题：在转型期，初级工程师和资深工程师谁更具优势？

令人意外的是，资深开发者的经验有时反而成为负担。

“无知无畏”的力量

资深开发者往往对 AI 工具表现出更强的抗拒。他们习惯了某种特定的解决问题的路径，思维模式已经固化。相比之下，初级工程师展现出了惊人的适应性。

  • 超能力解析：初级工程师像海绵一样，没有历史包袱。他们不知道行业的潜规则，不知道所谓的“不可能”，这种“好的无知无畏”让他们敢于尝试一切。
  • 场景：面对一个复杂的医疗或金融合规问题，资深开发者可能第一反应是“这太难了，有监管风险”，而初级开发者可能直接问 AI：“能不能试试这个方案？”

这种灵活性，使得最早掌握 AI 原生技能的初级工程师，可能成为未来最敏捷的一批人。

开发者的傲慢与过度工程化

软件开发者有一种特质，可称为“开发者的傲慢”：看到任何问题，第一反应都是“我能用软件搞定”。

在 AI 时代，这种傲慢变成了双刃剑。构建软件变得太容易了。你可以让 Claude 生成前端，让 Codex 生成后端，再让 Agent 写测试。一个月后，你可能做出了一个精美绝伦、架构完美的产品——但上线后发现根本没人需要。

警示：AI 降低了构建成本，却提高了验证成本。不要在没确认需求之前，就利用 AI 制造出一个过度工程化的怪物。

AI 原生组织的未来形态

核心问题：未来的公司组织形式会变成什么样？

哈佛商学院副教授 Rem Koning 提出了几个关键洞察，预示了 AI 原生组织的形态。

  1. 分配智能的能力：未来的核心竞争力不在于你个人有多聪明，而在于你能否将智能合理地配置到正确的位置。这就像现在的云资源分配一样，智能将成为一种可流动的资源。
  2. AI 嵌入产品：AI 原生组织不是用 AI 辅助员工工作，而是把 AI 嵌入产品本身，直接与客户协作。最终目标是将人类从繁琐的中间环节中剥离。
  3. Agent 间的对话：当 Agent 开始与 Agent 对话，当 AI 开始彼此协作，谁能设计好这套通信协议和协作机制，谁就有可能成为下一个万亿级的企业。

Future Organization
图片来源：Unsplash

实用摘要与操作清单

为了帮助工程师平稳过渡到 AI 原生时代，以下是核心要点的速览与落地清单。

核心观点速览

维度 传统观念 AI 原生视角
工作流 手写代码，逐步调试 规划 -> AI 生成 -> 修改 -> 循环
技能核心 算法、语法熟练度 Agent 编排、上下文切换、架构设计
代码库要求 最好有测试，文档作为参考 测试即合约，文档即真理，设计必须统一
初级 vs 资深 资深代表经验和效率 初级代表灵活和无畏，资深可能意味着固守

工程师行动清单

  1. 代码库自查：

    • [ ] 检查核心功能的测试覆盖率，确保 Agent 有“合约”可依。
    • [ ] 审查 README，确保其与当前代码逻辑完全一致。
    • [ ] 统一代码库中的设计模式，消除模棱两可的实现方式。
  2. 工作流升级：

    • [ ] 不要急于并行运行多个 Agent。从管理单个 Agent 完成一个小任务开始。
    • [ ] 练习“上下文切换”。尝试在两个不同的编码任务间快速切换，模拟 Agent 管理场景。
  3. 心态调整：

    • [ ] 警惕“过度工程化”。在动手写代码（或生成代码）前，先验证需求是否存在。
    • [ ] 培养“品味”。在 AI 生成的众多方案中，训练自己识别最优解的能力。

一页速览

从写代码到管 Agent 的转型路径

  • 现状：初级开发者面临裁员、供给激增、AI 替代的三重风暴。
  • 定义：AI 原生工程师 = 扎实传统功底 + 高效 Agent 编排能力。
  • 误区：不要盲目追求多 Agent 并行，需从单点突破，逐步搭建。
  • 难点：上下文切换是管理 Agent 的核心挑战，管理经验可迁移。
  • 基建：Agent 友好代码库需满足测试合约化、文档一致化、模式统一化。
  • 陷阱：AI 易导致过度工程化，需警惕“开发者的傲慢”。
  • 未来：组织将从“人使用 AI”转向“AI 嵌入产品”，甚至实现 Agent 间自主协作。

常见问答 (FAQ)

Q1：初级工程师现在不仅要学编程，还要学 Agent 管理，会不会负担太重？
A：这确实是挑战，但也是机遇。AI 原生转型是第一代初级开发者必须跨越的门槛。既然工具已经改变了，技能树也必须随之更新。现在的学习投入，是未来竞争力的核心壁垒。

Q2：如果我不擅长管理团队，是不是就很难管理好 Agent？
A：这两者有相通之处，但管理 Agent 更多依赖的是清晰的逻辑定义和上下文切换能力。通过“逐步搭建”的方式练习，你可以培养出这种能力，不必是天生的管理者。

Q3：我的代码库很乱，测试也很少，怎么开始让 Agent 接手？
A：切忌直接把 Agent 扔进混乱的代码库。你应该先进行“基建清理”：补充核心测试、更新文档、统一关键设计模式。Agent 只能基于显式定义的合约运作，前提是你得先立好规矩。

Q4：Mihail Eric 提到的“品味”具体指什么？
A：品味是指在满足基本功能需求后，对细节的打磨、对架构的优雅追求以及对用户真实需求的深刻理解。AI 能生成代码，但无法替代这种对“卓越”的主观判断和坚持。

Q5：资深工程师如何克服对 AI 工具的抗拒？
A：资深工程师应意识到，抗拒往往源于路径依赖。尝试将 AI 视为放大器而非替代品。利用资深者对系统的深刻理解来指挥 Agent，能发挥出比单纯手写代码大得多的杠杆效应。

Q6：为什么说 Agent 在代码库里犯错会像“滚雪球”？
A：因为 Agent 通常是基于上下文来推理下一步操作的。如果它第一步理解错了，它会把这个错误结果当成正确前提继续推导，导致错误被层层包裹，最后生成的代码逻辑混乱，极难修复。

Q7：未来的软件开发是不是就不需要写代码了？
A：不是不需要写代码，而是“写”的形式变了。从敲击键盘输入字符，变成了“规划、审查、修改、整合”。代码依然是软件的基础，但生成的责任从“制造”转移到了“设计”和“审核”。