8.3
深览指数
产品人人都是产品经理·叶小钗··AI 生成
FDE 最难的问题：你凭什么认为，这样做就能赚钱？
文章基于作者陪跑一家AI原生To C企业核心管理团队、完成20多个AI项目课题的一手经验，提炼出FDE方法论的核心难题：如何在立项前就论证清楚「做了AI就一定能赚钱」。作者提出，AI项目启动前必须通过前置阶段的价值与可行性审查，核心是验证业务路径的完整性与评价标准的明确性，避免陷入「看起来有价值就做」的陷阱。文章详细拆解了业务建模、轻量构造、价值验证的FDE核心流程，并讨论了管理者、业务专家、产研等不同角色向FDE转型的能力短板与补强路径。适合正在推动企业AI落地、或负责AI项目管理与产品化的从业者阅读。原文 ↗
核心观点
- ▍FDE(Field Development Engineer/业务落地工程师)的首要难题不是技术实现，而是立项前的价值与可行性判断，核心是回答「凭什么认为这样做就能赚钱」——必须验证业务路径的完整性与评价标准的明确性。
- ▍FDE的核心能力是「能表达×能实现」：将不可言传的业务经验结构化表达为流程、规则与标准，并通过轻量构造(如AI表格、Workflow)快速验证逻辑是否成立，之后才进入正式的工程化与产品化阶段。
- 01作者陪跑一家AI原生To C企业，该企业已提前完成中层管理人员升级与业产研融合，参训人员具备强迁移能力，仅对能直接解决业务问题的内容感兴趣，这迫使培训从理论转向实际课题交付。
- 02一个内容团队提出「提升专业度→提高销售转化」的课题，被一线业务质疑：影响转化的关键可能不是内容专业度，而是服务时间与资源分配；揭示了过程指标与最终结果之间不能划等号的典型陷阱。
- 03某投放管理同学希望AI从海量聊天记录中找出「让客户决定购买的那句话」，但被追问时发现其无法回答「如何确定是这句话起作用」「客户前面聊了二十分钟算不算前置条件」等问题，暴露出企业自身也不知道成交如何发生。
- 04作者提出「会」的定义至少包含两点：业务实现路径(通过什么机制获得结果)和评价标准(凭什么判断机制成立)。只有目标(如提高转化率)而不具备这两点，属于业务研究问题，不应进入AI开发。
- 05一个没有技术背景的团队，为验证业务路径，人工将知识拆成十几个板块，先判断问题归属再丢给大模型生成答案——用「最土的方法」证明了业务逻辑可行，体现了轻量构造的精神。
- 06有一个反例：某团队在目标SOP和评价规则尚未清晰提炼时，就开始设计用户界面、系统集成、权限日志等工程化内容，结果后续验证发现核心节点与预期不符，导致前期设计被推翻。
- 07作者总结的FDE完整路径为：课题选择→业务建模→轻量构造→价值验证→FDE毕业→工程化/产品化→生产运行→规模推广。前置阶段解决「值不值」与「会不会」，核心区完成「能表达×能实现」。
反方 / 局限
- — 作者承认，文章中FDE方法论的核心假设——「做法成立与否可通过业务路径+评价标准验证」——隐含了前提：企业内部的业务逻辑存在可被结构化的部分。对于高度依赖直觉、经验或隐性知识(如顶级销售的话术、艺术家的创作)的业务场景，该方法可能失效或需要大量前置探索。
- — 文章提出的FDE角色定位(站稳中间、串联前后)对团队协作与组织信任要求很高。如果管理者、业务专家、产研各方无法就「到底谁来判断业务价值」「谁负责定义评价标准」达成共识，FDE可能沦为「什么都干却什么都干不好的夹心层」。这是作者从反面暗示的风险。
20 分钟 · 3 卡片 · 5 资料
读原文 →