当 Agent 开始写代码：软件工程里，到底哪一段会被取代？

一、今日思考概览
最近团队里讨论最多的一句话是：「agent 更新太快了，前端是不是不用人了，测试是不是要被全自动替代？」我自己也有过一阵真实的焦虑。但焦虑的问题在于它太笼统——「被取代」听起来像一整块石头砸下来，实际上它是有层次的。
今天我做的只有一件事：把这个模糊的恐惧拆开，看它到底落在软件工程的哪一段。结论先说——被冲击的不是「软件工程」这个整体，而是其中「目标清晰、结果可验证、上下文短」的那一段执行。 想清楚这一点，转不转型、往哪转，才有依据。
二、我的收获

1. 分解：把「被取代」拆成四层
   第一层，执行层：写组件、写接口、写测试用例、跑回归。特点是目标明确、可验证、上下文短。这一层最危险，因为 agent 恰好最擅长这种「给定输入、产出可检验结果」的任务。
   第二层，实现层：架构设计、方案选型、性能调优、复杂状态管理。这一层被「辅助」多于被「取代」。AI 能给三套方案，但权衡取舍（成本、团队能力、可维护性）仍要人拍板。
   第三层，判断层：需求真伪、优先级、风险、什么算「做完了」。这一层几乎不可替代，因为它依赖组织上下文、责任归属和价值判断——AI 可以给建议，但不能背锅，也没有真实的业务与政治语境。
   第四层，场景层：把系统落到真实的物理环境、客户现场、异构设备。这一层是护城河，因为现场永远 messy：网络不通、设备型号对不上、客户临时改需求。
   关键判断：前端和测试之所以被冲击得最明显，不是因为它们不重要，而是因为它们的日常工作里「执行层」占比最高。 占比高，可自动化比例就高，于是被压缩得最快——这是结构问题，不是价值问题。
2. 组合：一条完整的判断链
   agent 强 → 强在「清晰目标 + 可验证结果 + 短上下文」 → 软件工程里这类工作占比高 → 执行层被压缩 → 判断层、场景层反而更稀缺、更值钱 → 结论：不是「逃离软件」，是「往软件工程里 AI 够不着的那一端移动」。
   这条链最有用的一点在于：它把「要不要转行」换成了「往哪一端移动」。前者是情绪，后者是动作。
3. 对照：三个场景的推演
   我不假装做过严谨实验，但可以做一次逻辑对照：

• 场景一：让 agent 写一个标准 CRUD 页面。目标清晰、结果可跑、上下文短——它做得又快又好。这一层，确实在被替代。
• 场景二：让 agent 判断「这个需求该不该做、先做哪个季度」。它能给框架，但缺组织上下文、缺责任、缺对「谁会被得罪」的感知。这一层，替代不了。
• 场景三：让 agent 去客户现场，把系统接进一台真实车机、一条真实产线。它去不了。这一层，是人的地盘。
  三个场景对应三层价值。越往下，越安全，也越需要「非纯软件」的能力。

4. 边界：哪些话我不能说

• 不能说「测试会消失」。消失的是「重复执行」，不是「质量判断、探索性测试、测试策略」。把测试等同于点点点，才是真正的危险。
• 不能说「前端没前途」。靠近体验创新、复杂交互、性能极限的部分仍然稀缺。
• 不能说「转了就安全」。任何领域都在被 AI 渗透，区别只是速度快慢。
  三、写给自己和他人
  焦虑的解药不是「逃」，是「移动」。看清自己在价值链的哪一层，然后有意识地往 AI 够不着的一端走——这是我今天想清楚的第一件事。
  下一篇，我想把「往哪走」摊开：为什么是车载测试、硬件、FDE，以及它们共同的那条逻辑。