第 3 章 旧能力不是包袱：IT 岗位的迁移地图
3.1 转型不是把过去清零
面对一个新岗位，人们容易先看自己不会什么：不懂大模型，不熟悉智能体，没有做过 RAG，也没用过热门框架。于是转型变成重新上学，过去十年的经验仿佛突然失效。
FDE 恰恰不适合这种思路。
这个角色需要把业务理解、产品取舍、工程实现、质量保障、生产运维和客户协作连成闭环。很少有人一开始就全部具备。多数 FDE 都是从某个相邻岗位出发，保留自己的强项，再补齐最影响闭环的短板。
转型不是换掉旧职业，而是改变旧能力的使用方式。
3.2 程序员：从正确实现到正确选题
程序员最明显的优势是能够把想法变成系统。理解接口、数据库、权限、日志、异常和部署，也知道演示代码与生产代码之间隔着什么。
这些能力在 AI 项目中非常重要。模型调用只是系统的一部分，真正困难的往往是数据接入、状态管理、工具调用、失败恢复和现有架构的兼容。
程序员常见的短板，是过早进入解决方案。客户刚说“做一个知识助手”，脑中已经开始选择向量数据库和 Agent 框架，却还没有问清谁使用、解决什么问题、结果如何衡量。
向 FDE 转型，关键不是再多学几个框架，而是把技术动作推迟一点：先理解业务流程和成功标准，再决定是否需要 AI。还要学会用非技术语言解释取舍，让客户听懂“为什么现在不该做这个功能”。
程序员需要完成的变化是：从“把需求正确实现”，走向“和客户一起找到值得实现的需求”。
3.3 产品经理：从定义需求到验证系统
产品经理擅长理解用户、拆解流程、协调利益相关方和管理范围。他们通常能发现客户口中的愿望与真实问题并不相同，也知道一个项目为什么会在组织协作中停滞。
这与 FDE 的业务发现和场景定界高度重合。
短板往往在工程深度。传统产品经理可以把技术问题交给研发，但 FDE 需要理解数据怎样进入系统、模型为什么出现某类错误、权限如何控制、评测怎样自动运行。未必要成为资深后端工程师，但必须能够亲手做出原型、阅读日志、调用接口，并与工程师讨论生产风险。
产品经理的另一个挑战是从“功能接受”走向“效果验收”。AI 输出具有不确定性，不能只检查按钮是否存在，还要用测试集、失败类型和业务指标描述系统是否可用。
这条转型路线的核心，是从“写清楚应该做什么”，走向“亲手证明它能工作”。
3.4 测试工程师：从发现缺陷到定义可信边界
测试工程师习惯考虑正常路径之外的世界：空值、异常输入、权限错误、并发、超时、回归和恢复。这种失败模式思维，是 AI 项目中非常稀缺的能力。
大模型系统不能只问“答案对不对”。还要考虑是否引用了错误版本，是否泄露了无权查看的信息，是否在证据不足时编造结论，是否对危险操作给出过度自信的建议。模型、提示词和知识库任何一项变化，都可能让旧能力退化。
测试工程师适合向 AI 评测、安全护栏和交付质量方向切入。短板通常是容易停留在验证别人构建的系统，而不是端到端完成方案。
向 FDE 转型，需要补足业务发现、基本开发和系统集成能力。还要从“找到更多问题”进一步走向“根据风险决定哪些问题必须先解决”。
这条路线的变化是：从质量检查者，走向可信系统的共同设计者。
3.5 运维与 DevOps：从系统在线到业务有效
运维和 DevOps 人员熟悉企业最真实的一面：网络不会永远稳定，依赖服务会超时，权限不能随意开放，版本必须能够回滚，日志要在事故发生前准备好。
很多 AI 演示之所以进不了生产，正是缺少这些能力。模型怎样部署，密钥怎样管理，数据能否跨境，调用失败如何降级，成本异常如何报警，都是 FDE 必须面对的问题。
这类从业者的短板通常不是可靠性，而是价值发现。他们容易从“怎样让系统稳定运行”出发，却没有先确认系统是否值得运行，用户是否需要它，指标是否会改变。
向 FDE 转型，需要主动接触业务人员，理解流程和决策，不把所有需求都视为资源、容量和可用性问题。也需要补充大模型应用开发与评测知识。
核心变化是：从保证系统可用，走向保证系统对业务有用。
3.6 售前、实施与项目经理：从推动交付到亲手构建
这几类岗位虽然职责不同，却共享明显优势：熟悉客户现场，知道怎样组织会议、识别关键人、管理预期并推动多方完成任务。他们也更早理解一个项目的失败往往不是纯技术问题。
对 FDE 来说，这是非常有价值的基础。
短板通常在工程动手能力。只会写方案、排计划或协调研发，很难在信息不完整时快速验证判断，也容易依赖后方团队解决现场问题。
转型不要求立刻成为全栈专家，但至少需要能够调用模型和 API、处理基本数据、搭建简单应用、查看日志、设计评测，并理解部署和权限的基本逻辑。只有亲手做过，才能准确估算难度，也才能识别一个演示背后隐藏的生产风险。
这条路线的变化是：从把人和流程组织起来完成交付，走向自己也能完成关键构建。
3.7 数据与 BI：从解释过去到改变流程
数据分析和 BI 人员擅长理解指标、清洗数据、识别口径差异，并把业务问题转化为可计算结构。他们知道同名指标可能有不同定义，也知道数据表里最整齐的字段不一定最重要。
FDE 需要这种数据敏感度。没有可靠基线，就无法证明 AI 是否带来改善；没有理解数据来源，就容易把错误信息交给模型。
短板是许多分析工作止于报告。图表揭示了问题，却没有进入业务动作。向 FDE 转型，需要学习把分析结果嵌入流程：系统何时触发建议，用户如何确认，结果怎样写回，失败如何处理。
同时还要补充应用开发、模型能力边界和用户采用方面的知识。
核心变化是：从用数据解释发生了什么，走向用系统改变接下来发生什么。
3.8 管理者与 CTO：重新回到可验证的一线
管理者的优势是能够看见业务、组织、预算和技术之间的关系。经历过多次系统建设后，也更容易判断什么是概念包装，什么是真正影响落地的约束。
但管理年限越长，距离代码、数据和一线用户也可能越远。依赖汇报材料进行判断，在稳定项目中尚可，在变化迅速的 AI 项目中却容易失真。
管理者向 FDE 转型，不是放弃战略能力，而是重新获得亲手验证的能力。能够用真实数据做出小原型，能够看懂一次模型失败，能够和用户一起观察流程，会让过去的组织经验重新落地。
另一项挑战是放下头衔带来的惯性。FDE 在现场首先要发现事实，而不是立即给出高层答案。能否承认不知道、快速验证并根据证据修改判断，比维持权威更重要。
3.9 找到自己的主能力与补位能力
没有必要把所有能力练到同一水平。更现实的做法是保留一项主能力，再建立足以完成闭环的补位能力。
- 工程型 FDE 以开发和架构为主，补业务发现、沟通与价值衡量；
- 产品型 FDE 以场景和范围为主，补编码、数据、部署与评测；
- 交付型 FDE 以客户协作和项目推进为主，补原型构建和技术判断；
- 质量型 FDE 以评测、风险和可靠性为主，补业务选题与系统实现；
- 行业型 FDE 以领域知识为主，补 AI 工程和产品化能力。
真正危险的不是有短板，而是不知道短板会在哪个环节切断闭环。会写代码但找错问题，会做方案但不能落地，会保证稳定但没人使用，都会让项目失去价值。
本章小结
传统 IT 经历不是进入 FDE 的障碍，而是起点。程序员、产品经理、测试、运维、售前、实施、项目经理、数据人员和管理者，都已经拥有闭环中的一部分。
转型的关键不是从零学会所有事情，而是确认自己的主能力，并补上最影响结果的那一段。接下来，我们将进入 FDE 最先发生、也最容易被跳过的工作：业务发现。