今天 Hacker News 首页 有一篇讨论度很高的文章：AI is removing the middle class of software engineering?。标题很尖锐，但背后的问题并不新：当 AI coding agent 可以生成实现、修复测试、解释代码、写迁移脚本和补文档时，软件团队还需要多少“中间层”工程人力？
我的判断是：AI 不会简单消灭中级工程师，但会压缩某类中级岗位的舒适区。过去很多组织靠人力堆吞吐：资深工程师拆任务，中级工程师实现，初级工程师处理边角料。现在 agent 能接走一部分实现任务，真正稀缺的变成任务定义、边界判断、质量审查、系统演进和事故责任。
这篇长文从团队结构角度拆解这个变化。
软件工程任务正在重新分层
过去我们常把工程任务按难度分为 junior、mid、senior。但 AI 进来后，更有解释力的分层是：
第一类是明确输入输出的局部任务。比如添加字段、改 UI 文案、补单元测试、迁移 API 调用、写脚手架、生成配置。这类任务最容易被 agent 接走。
第二类是局部但需要上下文判断的任务。比如修一个并发 bug、调整缓存策略、改数据库索引、拆组件边界。这类任务 agent 可以参与，但需要人设定约束和审查。
第三类是跨系统任务。比如重做权限模型、设计账务一致性、迁移消息队列、降低发布风险。这类任务的难点不是写代码，而是知道哪些代码不能随便改。
第四类是组织级任务。比如定义质量标准、培养新人、维护技术路线、处理事故复盘、在产品压力和工程风险之间做取舍。AI 能辅助，但不能承担责任。
被挤压的不是“中级”这个职级，而是长期停留在第一类任务的人。过去这类任务足够多，可以支撑大量岗位。现在 agent 让这些任务的边际成本下降，团队会自然把人力转向第二、第三、第四类。
中层价值为什么会被重新定价
中级工程师的传统价值有三部分：产出代码、理解局部模块、独立完成中等复杂任务。AI coding agent 对第一部分冲击最大，对第二部分有辅助，对第三部分产生重新定义。
如果一个人只能把 Jira 票翻译成代码，而且代码审查中经常遗漏边界条件，那么 agent 加一个强 reviewer 可能更便宜。
如果一个人能维护模块不变量，知道哪些测试必须补，能识别 agent 输出里的危险假设，还能把模糊需求拆成可验证任务，那么 AI 会放大他的价值。
换句话说，中级工程师从“实现者”转向“局部 owner”。owner 不只是写代码，而是对模块行为负责。AI 可以帮 owner 写更多代码，但不能替 owner 解释为什么这样改、怎么回滚、出了事故谁判断。
审查成为核心瓶颈
AI 提升代码生成速度后，团队第一个碰到的瓶颈通常不是“没有代码”，而是“没有足够高质量的审查”。
审查包括四层：
第一层是语法和风格。格式化、lint、类型检查可以自动化。
第二层是局部正确性。测试、静态分析、diff review 可以覆盖一部分。
第三层是系统一致性。比如这个变更是否破坏幂等性，是否绕过权限，是否让缓存失效，是否影响审计日志。
第四层是产品和组织风险。比如这个功能是否改变用户承诺，是否触碰合规边界，是否让客服流程失效。
AI 最容易补第一层和部分第二层。真正稀缺的是第三层和第四层。未来团队可能不缺能生成 PR 的 agent，而缺能快速判断 PR 是否应该合并的人。
这会改变职级结构。过去中级工程师靠提交数量证明产出；未来更重要的是审查质量、事故率、回滚率、任务拆分质量和自动化验证覆盖率。
新人培养会变难
一个经常被忽略的问题是：如果低风险任务都交给 AI，新人靠什么成长？
传统成长路径依赖大量小任务。新人先改文案、补测试、修小 bug，逐渐理解代码库和发布流程。现在这些任务最容易自动化。如果团队为了短期效率把所有小任务交给 agent，新人会失去练习场，几年后组织缺少真正理解系统的人。
解决办法不是禁止 AI，而是重新设计训练机制。
第一，保留教学型任务。不是因为 AI 做不了，而是因为人需要练习。任务目标应明确标注为 training，不以最高吞吐为目标。
第二，要求新人审查 agent 输出。让新人从“写一切”变成“先判断输出哪里不可靠”。这比单纯让新人接受 AI 代码更有效。
第三，建立故障案例库。每次 agent 生成错误代码，都沉淀成训练材料：错误假设是什么，测试为什么没抓住，review 应该看哪里。
第四，让新人参与发布和回滚。工程能力不是只会写函数，还包括知道代码进入生产后会发生什么。
资深工程师的工作也会变化
很多人以为 AI 会让资深工程师轻松。实际更可能是：资深工程师从写关键代码，转向设计 agent 可执行的工作系统。
这包括：
把大任务拆成可验证小任务。
给 agent 提供足够上下文，但不泄露敏感信息。
定义工具权限和沙箱边界。
写回归评测，防止模型升级带来行为漂移。
设计代码审查 checklist。
维护架构决策记录。
处理 agent 失败后的归因。
这些工作不一定比写代码轻松，但杠杆更高。一个好的 senior 可以让多个 agent 和多个中级 owner 稳定产出；一个不负责的 senior 会让团队堆出大量看似完成、实则不可维护的代码。
组织形态的可能变化
未来软件团队可能出现三种形态。
第一种是传统团队加 AI 助手。每个人用 AI 提升个人效率，但流程不变。这是过渡形态，收益有限。
第二种是 owner 加 agent 执行池。每个模块有明确 owner，agent 负责生成实现、测试和文档，owner 负责验收。这种形态会减少纯实现岗位，增加审查和系统设计要求。
第三种是平台化 agent 工厂。组织把需求拆解、代码生成、测试、review、部署、监控都纳入流水线。人主要负责策略、例外、事故和架构演进。这种形态门槛最高，但长期效率最大。
大多数公司会卡在第二种。原因很简单：第三种需要极强的工程基础设施，包括测试可靠性、模块边界、观测系统、权限控制和知识库。如果这些基础不存在，agent 只会加速混乱。
个人应该怎么转型
对工程师个人来说，最不稳的是把自己定位成“能把需求写成代码的人”。这个能力正在商品化。
更稳的定位是：
我能把模糊需求变成可验证任务。
我知道这个系统的关键不变量。
我能设计测试抓住真实风险。
我能审查 AI 输出里的隐藏假设。
我能维护一条从需求到发布再到回滚的闭环。
我能让别人和 agent 在我的模块里安全工作。
这些能力需要长期积累。可以从每天的工作开始：少问“这个功能怎么让 AI 写”，多问“我如何判断这段 AI 代码真的可以上线”。
结论
AI 不会让软件工程只剩少数天才和一堆机器，但会让“中间层”重新分化。只做可替换实现的人会被压缩；能承担局部 ownership、审查质量和系统演进的人会被放大。
对团队来说，关键不是盲目裁人或盲目加 agent，而是重画责任边界：哪些任务交给 AI，哪些责任必须由人承担，哪些训练机会必须保留。对个人来说，关键也不是拒绝 AI，而是从代码产出者升级为系统质量负责人。
这才是今天 HN 这类讨论真正值得关注的地方：AI 改变的不是 IDE 里多一个补全，而是软件组织如何分配判断力、责任和成长路径。