结论
发现我这个公众号居然还活着，然后还有不少人关注。
这篇是手机打的，手机编辑器真的不好用，写一些最近的感悟。先说结论：AI 时代，由于 AI 在生产侧催化出 FDE、PDE 等各种职位，也就是利用 AI Coding 的杠杆能力加速端到端产出，但研发侧其实更累，收益同比旧时代下降。
根因在于：AI 让需求端提出需求、试错和变更的速度获得正向增益，但这些需求的收益没有同步被证明，生产端消化速度也没有同步跟上。 最终可能导致组织觉得“不需要那么多人”，或者直接裁员。当然，后疫情时代人招多了，也有关系。
这里先把两个英文岗位名校准一下：FDE 在英语世界里通常指 Forward Deployed Engineer，PDE 在不少 AI Native 组织里会被理解为产品研发工程师、产品工程师。不同公司叫法会有差异，但核心都指向一件事：离业务更近，端到端负责，把 AI 当生产杠杆。
拆解：AI 下的端到端交付
先说旧时代的交付。
一个完整协作周期大概分为：
- 需求提出：来源于业务诉求、业务现状、产品调研、价值确认、需求产出。这一步主责人一般是 PM。
- 需求评审：技术评审会覆盖大前端、后端、测试、其他相关方。这里的大前端包含前端、客户端、H5 等。几方会审没问题，各自出后续事宜。
- 技术评审：先写关键方案，内部对齐评审，再排期。这一步很关键，涉及历史兼容、技术演进、质量保障、团队节奏等等。
- 节奏推进：技术方案和评审做好之后，就有节奏地研发推进。团队协作过程中，如果发现风险预估不准，要提前暴露并同步调整。
- 预交付：最终多方都研发完成，进入可交付状态。测试修几轮问题和 bug，测试环境、监控告警等也要跟上，最终出一个大概的上线计划。
- 上线：白名单验证、灰度、监控和告警持续观测。正常就继续，反之反馈治理，最终完成上线。
旧时代为什么需要这样的流程？不是因为大家喜欢开会，而是因为软件交付需要在复杂协作里保证高质量交付。尤其是多人、多端、多系统协作时，这套流程是在兜底风险：需求是不是有价值、技术方案能不能兼容历史、质量怎么保障、上线后怎么观测。
流程看起来慢，但它背后对应的是组织对风险的消化能力。
AI 时代遇到的几个 case
AI 时代，问题不是流程直接消失了，而是在原来的组织结构下，出现了几个融合后的怪像。最近聊得比较多，也实际遇到比较多的，主要是三个 case。
1. 生产端累成狗
AI 刚出来的时候，研发很容易达成一种状态：早执行完，早休息。
工具变强，个体效率提升，局部收益非常明显。这个阶段大家会觉得 AI 是帮研发减负的。可真实情况是，组织很快会把这个收益吃掉。
以前一个需求要排期、要评审、要等资源。现在 AI 能快速补代码、快速做 Demo、快速试错，研发产出的速度确实上去了。但端到端交付里，真正消耗人的地方不只是写代码，还包括需求判断、历史兼容、系统拆分、联调测试、灰度回滚、监控告警、线上结果负责。
所以 Coding 被加速以后，不代表整个交付系统都被同等加速。生产动作快了，消化动作没有同步变快，研发反而更累。
2. 需求侧会更想“多搞一下”
第二个 case 是需求侧。
PM 和老板会很自然地形成一种判断：
反正有 AI，多搞一下，不行再改。
这句话很真实。AI 让 Demo 成本下降，也让需求侧更容易看到短期正反馈。以前一个想法要进入研发前，可能还会因为成本高而谨慎一点；现在 AI 能跑 Demo，能快速出方案，能快速试错，于是需求提出、试错和变化的速度都会被放大。
问题是，增速来自需求提出和试错，不一定来自真实收益。需求收益如果真的同步增长，而且增长足够高，保持原有组织形态也可能成立；但最近看到的更多情况是，需求变化速度上去了，收益验证没跟上，生产端消化速度也没跟上。
AI 可以让需求看起来更容易被验证，但不代表需求真的被验证；AI 可以让试错看起来更便宜，但不代表后续质量、联调、上线、回滚都便宜。最后这些不确定性还是会落到研发和交付链路上。
于是 AI 成了组织快速试错、快速看产出的工具，而研发成了工具的牺牲品。包含但不限于一种隐性压力：你不干，有的是人干。
3. 研发的心理预期会变差
第三个 case 是人的心理预期。
AI 刚开始给研发的心理预期是：我效率更高了，我可以少做重复劳动，我可以更早完成工作。
但如果组织只拿 AI 当加速工具，不同时升级需求验证、质量平台和组织边界，研发会很快发现另一种现实：不是少干活，而是更多需求、更快变化、更短反馈、更强压力。
这也是为什么我说研发侧其实更累，收益同比旧时代下降。
旧时代虽然慢，但节奏相对可预期。AI 时代如果只加速生产侧，不治理需求侧和组织侧，人的心理预期会被反复打穿：本来以为工具让自己更自由，最后变成工具让自己承接更多不确定性。
核心矛盾不是“AI 不好”
这里不是说 AI 不好。
AI Coding 的杠杆能力是真实存在的，FDE、PDE 这类角色的出现也是真实趋势。端到端交付能力变强，前后端边界融合，研发更靠近业务，这些都不是坏事。
真正的问题是：组织不能只吃 AI 带来的生产增益，却不升级需求验证、生态系统和质量保障。
如果只看生产端，会得到一个很简单的结论：AI 让人更快，所以人可以更少。
但如果看整个端到端交付链路，就会发现另一个现实：需求提出、试错和变更速度上去了，生产端 Coding 速度也上去了，可评审、协作、测试、上线、监控、回滚、人的承压能力不一定同步上去。
这才是最近这些 case 背后的核心矛盾。
| 观察点 | AI 带来的变化 | 真实风险 |
|---|---|---|
| 生产端 | Coding 更快，Demo 更快 | 交付链路其他环节没有同步提速 |
| 需求端 | 试错更便宜，想法更多 | 收益验证没同步跟上，需求变化频率和不确定性上升 |
| 研发侧 | 个体工具能力增强 | 承接更多评审、联调、上线和治理压力 |
| 组织侧 | 更容易看到短期产出 | 容易把效率收益直接转化为压强或裁员 |
所以“AI 让研发更高效”这句话只说对了一半。更完整的说法应该是：
AI 提升了生产侧的局部执行效率，也放大了需求侧提出、试错和变更的速度；但如果收益验证和生产端消化速度没有同步跟上，系统就会把多出来的不确定性转嫁给研发。
治理手段：我预期的改善路径
那么如何治理这种乱象？
我倾向于认为：AI Native 组织是个自上而下的事情。
不是给每个研发发一个 AI Coding 工具，组织就 AI Native 了。真正的 AI Native，是流程融合、生态融合、质量保障和组织升级一起发生。
1. 流程融合：需求验证前置
既然 AI 能跑 Demo，为什么不是产品提前跑通，先做好价值认证？
从用研、需求输出到需求验证，都应该提前。以前很多需求走到研发评审才发现价值不清晰，现在 AI 能低成本做原型，就更应该把需求判断放在前面。
研发不应该成为所有不确定性的第一接盘人。
2. 生态融合：让 Agent 进入交付系统
各系统生态也要融合起来。
需求产出后，应该能进入需求平台，比如 ONES；再同步到 bug 系统、排期系统、Code 系统、CI/CD、测试系统、监控告警系统。Agent 可以在这些系统之间巡检治理。
理想情况下，常规小需求可以由 Code Agent 自行修复、提交、Review、验证，并跟随大版本上线。
这时候 AI 才不是一个独立工具，而是组织交付链路里的执行和治理节点。
3. 生态保证：产能上去了，保障不能少
最近聊的一些公司，一上来就想搞研发融合，但兜底的监控、告警、回滚平台都没有，就是干。
就问你虎不虎吧。
产能上去了，质量保障不能少。否则 AI 只是把问题更快地推到线上。
4. 组织升级：可以扁平，但不能只剩压强
基于流程融合、生态融合和生态保证，组织可以逐渐扁平。
从最近聊得比较多的一些公司来看，大家都在转。比较极致的转型，是只有 PDE，直接跟产品或需求方对接，进行端到端交付。
这个方向不是不行。在 AI 加持下，前后端合并、提升各自双边能力，是有机会成立的。
但这种情况下需要降低产品和需求变化的速度。太快了，AI 能承担得住，人也有可持续健康度的考量。
如果没有需求前置验证，没有质量平台，没有稳定观测，没有明确边界，那 PDE 只是一个更好听的“全都你来”。
5. 人员调整：学习能力重要，人文原则也重要
基于以上变化，人员调整不可避免。
我的判断是：基于人文原则，员工可持续学习能力强，就持续学习；组织也可以根据需要外招一些 AI 落地或 AI Native 先行者。
但人员调整不能只用效率叙事包装。AI 带来的组织变化会影响很多人的职业路径，越是这种时候，越需要把规则讲清楚，把转型路径讲清楚。
总结
AI 能把输出变快，但不会自动把需求变准，也不会自动补齐交付系统。
所以不要只盯着研发再快一点。真正要做的是整个组织一起增速：需求先验证价值，产品收敛变化，研发可持续交付，平台和质量体系把监控、告警、灰度、回滚兜住。
长期看，token、人和基建都是投入，最后还是要回到交付需求能不能带来正向转化和收益。否则只是更快地产生更多变化，团队士气、组织稳定性和交付质量都会被持续消耗。