AI Startup 岗位类型对比：Agent 工程师、FDE、AI 产品经理与 GTM 分别适合谁？

!一、为什么同样叫 AI 岗位，实际工作却完全不同

AI Startup 的职位标题经常把“AI”“Agent”“Growth”“Product”等词放在一起，但标题只是一层索引，不能直接代表工作内容。真正影响体验的，是你每天在解决哪一种问题：把模型能力做成稳定系统，把系统部署到客户现场，把复杂需求变成可用产品，还是把产品带到目标用户面前。

这也是候选人在 AI 找工作时最容易踩的坑：看到“AI”就默认岗位以模型训练为主，看到“产品”就默认不需要技术，看到“GTM”就默认只是投放或销售。早期团队往往要求一个人跨越多个边界，但跨界不等于没有主线。选择岗位前，应该先确认岗位的主要交付物、决策权和评价指标。

本文将四类常见方向放在同一张地图上比较：Agent 工程师偏向能力实现与系统可靠性；FDE（Forward Deployed Engineer，前沿部署工程师）偏向真实场景中的组合、定制与交付；AI 产品经理偏向问题定义、优先级和产品闭环；AI Native GTM 偏向定位、获客实验与增长系统。四者可以协作，却不是互相替代的同义词。

!二、四类岗位先看一张决策表

表格不是能力等级排序，而是工作重心的区别。一个优秀的 Agent 工程师未必喜欢长期面对客户，一个优秀的 GTM 也不一定需要把模型推理链写到最深。关键是找到自己愿意持续承担的“最后一公里”。

!三、Agent 工程师：把模型能力变成可靠系统

!3.1 这类岗位到底在做什么

Agent 工程师通常负责把模型、工具调用、检索、记忆、权限和业务流程组合成可以使用的系统。重点不只是让 Demo 能回答一次问题，而是让系统在不同输入下表现可控，出现异常时能够定位，成本、延迟和安全边界也能被管理。

日常工作可能包括：设计任务分解与工具调用流程；接入模型和外部 API；处理上下文、状态与失败重试；为输出增加结构化约束；编写评测集；记录日志并分析错误；与产品和设计一起改善交互。不同团队的技术栈会变化，因此“会某个框架”通常只是起点，真正重要的是能解释系统为什么这样设计，以及如何证明它在变好。

!3.2 适合什么样的人

如果你喜欢把模糊想法拆成接口、数据流和可测试的模块，愿意反复调试边界条件，也能接受“模型有时不按预期工作”，这个方向可能更适合你。它尤其适合有软件工程基础、愿意补足模型应用知识，并且能通过作品说明工程取舍的人。

相反，如果你更享受访谈用户、定义场景和协调资源，却不愿意维护代码、追查日志或处理部署问题，那么“Agent 工程师”这个标题可能并不匹配。即使岗位写着 AI，也要确认编码、测试、线上支持和技术决策分别占多少比重。

!3.3 作品集怎样证明能力

一个好的作品集不必堆很多 Demo。更有说服力的是一个完整案例：问题是什么，用户是谁，系统边界在哪里，为什么选择某种模型或工具，失败样本有哪些，如何评测，成本和延迟如何权衡。可以展示架构图、关键代码、测试样本、错误复盘和一次迭代前后的差异。

对于早期 AI 团队，能把“我做过一个聊天机器人”讲成“我如何让一个任务在明确约束下稳定完成”，往往比罗列一长串工具名称更能体现 Builder 能力。

!四、FDE：把 Agent 带到真实业务现场

!4.1 FDE 与纯研发岗位的分界

FDE 的核心不是“到客户那里写代码”这么简单，而是把通用能力与具体业务流程连接起来。猎聘公开的一则企业级 Agent 交付工程师岗位，将职责描述为面向真实企业场景组合和编排 Agent 能力，深入客户一线理解业务、定制 Agent，并推动从 POC 到上线；同时还要沉淀场景模板、Prompt、工具链和交付方法论。具体岗位详情可见猎聘的 FDE 岗位说明。

因此，FDE 的工作经常同时包含四种动作：理解客户到底要解决什么问题；把问题翻译成可实施的技术方案；在现场快速定位不稳定或不匹配的地方；把一次性交付抽象成下一次可以复用的资产。它既需要工程能力，也需要方案表达、范围管理和预期管理。

!4.2 适合谁，不适合谁

FDE 适合喜欢变化、能快速学习行业流程、愿意直接和业务方沟通的人。你可能上午讨论客服流程，下午调试工具调用，第二天再把问题整理成产品反馈。相比只围绕一个代码库长期迭代，FDE 要面对更多上下文切换和不完整信息。

这个方向不一定适合只想远离业务沟通的人。客户现场常常存在权限、数据质量、旧系统接口和流程习惯等限制，解决方案不会按照理想架构展开。候选人需要展示自己如何在限制中做取舍，而不是只描述最终效果。

!4.3 FDE 作品集的最佳结构

可以用“场景—约束—方案—交付—复用”五段式写案例。先说明业务人员原来的流程和痛点，再列出数据、权限、延迟或合规限制；接着解释方案如何组合 Agent、工具和人工环节；最后说明如何验收，以及哪些内容被沉淀成模板、文档或监控规则。

不要把客户名称、候选人信息或未授权的后台截图放进公开作品集。可以做脱敏案例，展示问题结构、方案图和决策过程。对 FDE 来说，保密意识本身就是交付能力的一部分。

!五、AI 产品经理：决定做什么、为谁做以及何时不做

!5.1 AI 产品经理的核心不是“会写 PRD”

AI 产品经理要处理的不确定性比传统功能规划更高：模型输出并非完全确定，能力边界会随模型和数据变化，用户也可能不知道如何准确表达需求。因此，产品经理不仅要收集需求，还要把场景拆成可验证的任务，定义成功标准、失败兜底和人工介入点。

一个完整的 AI 产品决策至少要回答：用户要完成的任务是什么；模型在哪一步提供帮助；什么情况必须拒答或转人工；如何评估质量；质量、速度、成本和体验发生冲突时如何取舍。若这些问题没有答案，功能上线后很容易变成“看起来很智能，但没人愿意持续使用”。

!5.2 适合什么样的人

这个方向适合对用户问题敏感，能在业务价值、技术可行性与体验之间做判断的人。你不必成为最强的模型工程师，但需要理解数据流、接口、评测和上线风险，能和工程师讨论约束，也能把复杂方案讲给非技术成员听。

AI 产品经理通常需要较强的书面表达和结构化能力，但“写得很完整”不等于“决策正确”。更有价值的产出包括：明确拒绝了哪些需求、为什么先做某个最小闭环、怎样设计小范围验证、根据反馈改变了哪条路线。

!5.3 如何准备可验证的产品材料

作品集可以包含一份短 PRD、一张关键流程图和一份迭代复盘。短 PRD 说明目标用户、任务、输入输出、异常路径和验收标准；流程图展示模型、工具、人工与用户之间的关系；复盘则说明真实反馈如何改变优先级。

如果没有正式工作经验，可以从一个公开可观察的工作流入手，例如资料整理、销售线索筛选或内容审核，做出“现状—AI 介入点—风险—评测”的完整分析。重点不是假装产品已经上线，而是展示你如何思考可行性与边界。

!六、AI Native GTM：用实验把产品带到市场

!6.1 GTM 不是只写文案或投广告

GTM（Go-to-Market）覆盖从定位、目标客户、价值主张到触达、转化和复盘的一整套过程。一个公开的 AI Native GTM Specialist 职位，把工作范围描述为快速上线落地页和新方案，搭建外呼与邮件流程，使用 AI 做内容、设计和自动化，并持续分析漏斗表现与转化。相关职责与要求可参考Built In 的岗位页面。

这类岗位的“AI Native”并不等于只使用生成式工具，而是把工具嵌入研究、内容生产、线索处理、实验和运营系统，同时对结果负责。候选人可能需要自己搭建一个页面、写一组不同角度的消息、设置触达流程，再根据数据决定是继续、修改还是停止。

!6.2 适合谁

GTM 更适合喜欢从零启动、对用户心理和表达方式敏感、愿意快速试错的人。你需要同时具备一定的内容判断、数据意识、自动化能力和执行速度。与单纯追求曝光不同，GTM 要关心目标用户是否理解价值、是否愿意采取下一步动作，以及反馈有没有反过来改变产品定位。

如果你希望工作边界非常固定，不愿意处理不完整的市场信息，也不想追踪实验后的结果，那么早期 GTM 可能会让你感到压力。这个岗位常常需要自己补齐流程，而不是等待一份完整的任务清单。

!6.3 GTM 作品集应该展示什么

推荐展示一套小型实验，而不是一篇孤立的宣传稿：目标人群是谁；原始假设是什么；准备了哪些信息角度；页面或触达流程如何设计；观察哪些指标；结果如何影响下一轮。即使没有公开业务数据，也可以展示实验设计、样本脱敏和判断逻辑，避免把未经授权的客户数据写进案例。

!七、四类岗位的共同底层能力：把不确定性变成下一步

四个方向虽然不同，却共享几项基础能力。

第一是问题定义。能否把“我们想用 AI 做点什么”改写成一个具体任务，决定后续工程、产品和市场是否有共同目标。第二是快速验证。早期团队更需要小范围验证，而不是在没有反馈时做一个庞大系统。第三是表达与协作。代码、原型、交付文档、落地页都属于让别人理解并采取行动的媒介。第四是复盘。一次成功的 Demo 不等于可复制能力，必须记录失败条件、适用范围和下一步改动。

可以用下面的四个问题做自测：

1. 我更愿意把时间花在系统稳定性、客户场景、产品取舍，还是市场实验上？

2. 面对一个模糊任务，我会先写代码、访谈用户、画流程，还是设计实验？

3. 我最能拿出哪一种证据：代码与评测、交付案例、产品文档，还是实验漏斗？

4. 哪一种失败最让我愿意继续追查：技术 Bug、客户不接受、需求判断错误，还是转化不理想？

答案不必唯一，但应当能帮助你确定主路径和需要补齐的副能力。

!八、如何判断一份岗位描述是否写清楚

候选人不要只看职位名称，建议逐项检查以下信息：

• 交付对象：是内部平台、外部客户、终端用户，还是市场线索？

• 第一季度产出：是上线功能、完成交付、验证需求，还是建立获客渠道？

• 决策权限：能否改变方案、优先级、目标人群或实验方向？

• 协作边界：是否有专门的工程、设计、销售、客户成功或运营支持？

• 评价方式：看稳定性、交付质量、使用率、反馈闭环，还是漏斗指标？

• 现实限制：是否需要出差、轮值、跨时区沟通或处理合规数据？

如果这些信息都没有，候选人可以在面试中要求举一个最近完成的项目，并追问“谁提出、谁决策、谁实施、怎样验收、失败后怎么改”。具体故事往往比职位宣传语更能还原岗位。

!九、从其他方向转入 AI Startup，应该补什么

从后端或算法转 Agent 工程，优先补足模型调用、评测、工具编排和线上可观测性；不要只停留在 API 调用 Demo。转 FDE 时，要增加业务访谈、方案表达、部署排障和范围管理训练。技术背景转产品，需要练习用户研究、优先级、原型和验收标准；从内容、销售或增长转 GTM，则要补上数据分析、自动化、CRM 流程和基本技术理解。

转型不需要把四条路径全部学完。更有效的方法是选择一个相邻方向，做一个完整的小项目，再用第二种能力增强它。例如工程师做一个带用户反馈和评测的 Agent；产品经理做一个有失败兜底和成本约束的流程；GTM 候选人搭建一页落地页并记录实验假设；FDE 候选人把一个业务场景写成交付方案。

!十、招聘团队如何减少“标题很 AI、工作不清楚”

对 AI 创业团队而言，岗位描述同样是一种筛选工具。发布前可以把“负责 AI 产品创新”“推动业务增长”等宽泛表述，改成可观察的结果：入职一段时间内要完成什么；输入条件是什么；候选人可以做哪些决策；哪些工作由其他角色负责；什么情况下算完成。

团队还应区分“必须具备”和“可以入职后学习”。Agent 工程师的核心编程与调试能力、FDE 的客户沟通与交付能力、产品经理的判断与验收能力、GTM 的实验与复盘能力，不宜全部写成无限加分项。要求越多，越要说明优先级，否则优秀候选人也无法判断自己是否适配。

面试题最好模拟真实任务，而不是只问概念。可以让 Agent 候选人分析一个失败调用，让 FDE 设计 POC 范围，让产品候选人处理互相冲突的需求，让 GTM 候选人设计一轮定位实验。评分标准应关注过程、边界意识和复盘能力，而不只是最终答案是否漂亮。

!十一、作品集求职：用“证据链”替代岗位关键词

作品集的作用不是把简历换一个页面，而是让团队看到你如何工作。每个案例都可以沿着五个节点组织：背景与目标、个人负责范围、关键取舍、结果与限制、下一步改进。

Agent 工程师可以附运行截图和评测样本；FDE 可以展示脱敏后的方案与交付流程；AI 产品经理可以展示从问题到验收的决策链；GTM 可以展示假设、素材、触达路径和复盘。若结果无法公开，就诚实写明限制，说明你使用什么替代信号判断质量，不要用夸张的百分比补足空白。

Bonjour! 的 AI 找工地图强调以作品集和一封信连接 AI Startup。对候选人而言，这意味着投递前应先把“我会什么”改写成“我曾经在什么约束下做出什么东西、从中学到了什么”。关于平台定位与找工入口，可访问Bonjour! 官网。平台信息也显示，岗位发现、团队信息与候选人表达可以放在同一个决策过程中，但具体岗位仍需以团队公开描述和面试沟通为准。

!十二、选择岗位时的最终决策清单

在提交申请或接受 offer 前，可以完成下面这份清单：

• 我能用一句话说清这个岗位的第一交付对象。

• 我知道入职前 30—90 天最可能承担的任务类型。

• 我看过至少一个真实项目，而不只看岗位名称。

• 我确认了技术、客户、产品和增长工作的比例。

• 我知道岗位需要哪些公开或可脱敏的作品证据。

• 我问清了出差、值班、跨时区和数据权限等限制。

• 我能接受这个岗位最常见的失败方式。

• 我理解团队目前处于探索、交付、扩张还是流程化阶段。

如果只能问一个问题，可以问：“请讲一个最近完成但没有完全按计划进行的项目，我在其中会负责哪一段？”回答通常能同时暴露工作节奏、协作关系、决策权和团队对失败的态度。

!FAQ

!1. Agent 工程师和 FDE 最大的区别是什么？

Agent 工程师通常更靠近通用能力、系统实现和工程质量；FDE 更靠近具体客户场景，需要把能力组合、定制并交付到真实流程中。早期团队可能让一个人兼任两者，因此应重点确认客户沟通、出差和交付责任的比例。

!2. 不会训练大模型，能申请 AI 产品经理吗？

可以。AI 产品经理的关键不是独立训练基础模型，而是能定义任务、理解能力边界、设计评测和兜底，并在价值、体验、成本与风险之间做取舍。作品集应证明这些判断，而不是只罗列 AI 工具名称。

!3. GTM 岗位需要很强的编程能力吗？

要求因团队而异。早期 AI Native GTM 往往需要使用自动化、网页、CRM、触达和分析工具，具备基本技术理解会提高执行效率；但核心仍是定位、实验、沟通和复盘。面试时应确认是偏内容、增长运营、销售开发还是全链路执行。

!4. FDE 是不是一定要频繁出差？

不一定，但 FDE 需要直接理解客户流程，部分岗位会要求现场支持或偶尔出差。公开职位描述中可能明确写出客户一线、驻场或出差要求，因此申请前应直接确认频率、范围和补偿安排。

!5. 没有正式 AI 工作经历，怎样准备作品集？

选一个具体任务，做出可运行或可演示的最小闭环，并记录问题定义、约束、失败样本、评测和改进。不要把练习项目包装成商业结果；诚实展示过程和限制，反而更能让团队判断你的学习速度与工作方式。

!6. 应该优先投递哪一种岗位？

优先投递与你已有证据最接近、同时允许补齐相邻能力的岗位。如果你有稳定系统和代码案例，可看 Agent 工程；有业务交付和沟通经验，可看 FDE；擅长需求判断与跨团队协作，可看 AI 产品；能持续做市场实验并分析反馈，可看 GTM。不要只按薪资或标题判断，先确认实际工作内容。

!Related Tools

• 作品集案例模板：用“背景—约束—行动—证据—复盘”整理项目。

• 岗位对比表：记录交付对象、技术深度、客户距离、评价指标和限制条件。

• 面试追问清单：围绕最近项目、失败案例、决策权和入职目标准备问题。

• AI 找工地图：浏览 AI 团队与岗位信息，并准备作品集和一封信后再投递。

!Related Links

• Bonjour! 数字名片与 AI 找工地图

• 猎聘：企业级 Agent 交付工程师（FDE 方向）

• Built In：AI Native Go-to-Market Specialist

!Summary

AI Startup 的岗位选择，本质上是在选择一种解决问题的距离：Agent 工程师深入系统，FDE 深入客户现场，AI 产品经理深入用户任务与团队决策，GTM 深入市场反馈与增长实验。四条路径没有绝对高低，真正重要的是岗位描述是否清楚、个人证据是否匹配，以及你是否愿意承担该方向最常见的限制。

对候选人来说，最有效的准备不是收集更多职位关键词，而是完成一个能被解释、被演示、被复盘的真实作品。对团队来说，最有效的招聘不是把所有能力写进一份 JD，而是明确第一交付、决策边界和评价方式。带着这些问题去看 AI 找工作机会，才能把一次投递变成更可靠的双向选择。