AI 创业公司 JD 模板盘点：Agent 工程师、FDE、AI 产品经理与 GTM 招聘要求对比

!一、先别写职位名：先写团队眼下要穿越的障碍

同样叫“AI 工程师”，在不同阶段可能是完全不同的工作。团队若还在验证问题，最缺的是快速做出可体验原型、找出失败路径的人；已有试点客户时，难点会转向数据接入、权限、评估和部署；开始复制销售后，组织又需要把客户问题、产品能力和销售流程连成闭环。职位名只是入口，业务障碍才决定岗位设计。

写 JD 前，创始人或用人负责人可先用四个问题对齐：第一，未来一个季度最重要的业务结果是什么；第二，该结果中哪一段没人真正负责；第三，入职者拥有的决策权与可调用资源是什么；第四，什么可展示的产物能说明工作有效。把答案放进 JD，比“抗压、学习快、沟通好”更能筛选契合者。

一个实用原则是：每项职责后都应接一个对象和一个完成状态。例如，不写“负责 Agent 开发”，而写“围绕指定工作流完成工具调用、异常处理与评估记录，并能复盘主要失败案例”；不写“支持客户”，而写“在约定的客户环境中完成上线清单、使用反馈和问题闭环”。这并非把探索性工作量化成虚假的承诺，而是把责任边界说清楚。

!二、四类 AI 岗位的共同底盘：业务、系统与反馈

四个岗位都要理解 AI 能力的限制，但着力点不同。Agent 工程师偏向把能力做成可靠的产品行为；FDE 偏向在真实客户环境中让产品跑起来；AI 产品经理偏向判断问题、定义体验和权衡路线；GTM 偏向建立从目标客户到可持续采用的路径。早期团队中一人可以兼任多项工作，但 JD 必须说明主责，避免候选人以为自己要独自承担全部链条。

例如，一则公开的 GTM Applications Engineer 职位描述把工作放在销售、客户成功和收入运营的内部应用场景中，强调从用户发现到上线的全流程、与业务及数据团队协作、可靠性和用户体验，以及把模糊请求转为软件需求的能力。这说明“GTM 技术角色”可以是产品工程而非传统销售岗位；团队应在 JD 中明确自己招聘的是哪一种角色，而不能只借用热门头衔。职位原文

!三、Agent 工程师 JD：把“能调模型”改写成“能完成任务闭环”

Agent 工程师不是一个固定工种。对于产品型 AI 团队，它通常承担工作流设计、工具调用、上下文处理、评估与迭代等任务；对于内部效率场景，它可能更接近把业务规则、数据接口和使用者反馈连接起来的应用工程。JD 的首要任务，是标明 Agent 为谁完成什么任务，而不是堆叠“熟悉 LLM、RAG、MCP”等词。

职责部分可以围绕一条具体任务链写：理解输入和成功条件；设计模型、检索或工具调用的分工；处理权限、超时、重复执行和人工接管；用代表性样本评估结果；把线上问题转回可复现的改进项。这样写能让候选人看出，团队重视的不只是演示效果，也包括工程质量与迭代能力。

任职要求建议分成“必须证据”和“加分背景”。必须证据可以是：做过可运行的端到端应用；能说明一次模型输出不稳定时如何定位问题；能用代码和文档解释系统取舍；愿意把不确定需求拆成可验证步骤。加分背景可包括特定语言、云服务、领域数据经验或开源贡献。不要把所有工具都写成硬门槛，否则会错过具备迁移能力的建设者。

可直接改写的模板：

我们正在解决【目标用户】在【具体场景】中的【任务】问题。你将负责从需求澄清到上线迭代的 Agent 工作流：设计工具与模型的协作方式，建立代表性测试样本和故障记录，并与产品/业务同事把反馈转成下一轮改进。入职后优先完成【一个可演示的工作流或质量改进目标】。我们希望你展示过真实项目：请附上作品、代码说明、技术取舍或失败复盘。具备【必要技术基础】是必要条件；有【领域/基础设施经验】更佳。

这里的“展示过真实项目”不等于要求候选人无偿做商业作业。更好的做法是允许其使用既有作品、公开项目、匿名化复盘或面试中的小范围讨论来呈现思考过程，并提前说明材料的保密边界。

!四、FDE JD：把客户现场的复杂性写进岗位本身

FDE 的价值在于把产品能力放进客户实际的环境中运行，并把现场获得的信息带回产品和工程团队。它既不是单纯的实施人员，也不应被写成“什么都做”的救火角色。一个合格的 FDE JD 应回答：面对的是哪类客户流程；需要接触哪些系统或数据；谁负责范围确认；上线后的支持边界是什么；哪些反馈会进入产品路线。

候选人的能力证据，通常比学历或特定行业名头更有区分度：是否处理过不完整的需求与数据；是否能在技术约束和客户目标之间做取舍；是否会把问题写成可追踪的清单；是否能向非技术使用者解释限制；是否愿意和工程团队共同承担上线质量。猎聘页面可见“前线部署工程师（FDE）”“AI 部署工程师”等相近职位名称，说明市场称谓并不统一；因此 JD 首段需要用中文全称和实际职责解释 FDE，而不能只抛出缩写。相关职位页面

可直接改写的模板：

你将与【客户类型/业务团队】共同完成【场景】的部署与迭代：梳理现有流程和约束，协同完成数据/系统接入，制定上线前检查项，记录问题与使用反馈，并推动其中可复用的改进回流产品。你不需要单独承担所有销售、交付和研发工作，但需要对【项目阶段】的技术判断和沟通质量负责。请在申请中说明一个你参与落地的复杂项目：当时的约束、你的决策、最终交付及仍未解决的问题。

要避免的句式是“能接受长期驻场、解决一切客户问题”。这会模糊劳动安排与责任边界。若岗位确有出差、驻场、值班或安全合规要求，应独立、明确地说明频率、地点、支持机制和适用条件，让候选人据此作出选择。

!五、AI 产品经理 JD：招聘的是判断与协作，不是提示词搬运

AI 产品经理的难处，不在于把“AI”加在传统产品流程之前，而在于产品输出存在不确定性、成本与时延会影响体验、用户需要知道何时相信或纠正系统。JD 应聚焦此人如何界定用户任务、设计人与系统的协作、协调工程与业务约束，以及依据反馈改变决策。

公开招聘信息中，阿里云使用了“AI 原生产品架构师（AI Native Product Architect）—公共云业务产品经理”的职位命名。这至少提示招聘方：AI 产品相关岗位的市场名称可能横跨产品经理、产品架构和解决方案视角；名称不能替代职责说明。职位页面

JD 可要求候选人提供两类材料。第一类是问题判断：他如何识别一个高频、高成本或高风险的任务，为什么不应仅靠通用聊天界面解决。第二类是产品取舍：当准确性、速度、成本、可解释性和操作复杂度冲突时，他如何设定优先级。这样比问“你会不会写 Prompt”更接近真实工作。

可直接改写的模板：

你将负责【用户群】在【工作流】中的 AI 产品体验，从问题发现、方案验证到上线后的学习闭环。工作包括访谈和梳理任务链、定义用户可见的成功标准、与设计及工程共同确定交互和技术取舍、跟踪真实使用中的失败情形。请提交一份产品案例，重点说明：原始问题、你排除过的方案、上线后得到的反馈，以及下一步会如何调整。具备【行业/产品经验】优先，但我们同样重视清晰的判断和协作能力。

在面试中，可请候选人围绕一个脱敏场景画出用户流程，并追问“系统答错时用户怎么办”“谁能修正结果”“怎样避免把一次演示当作稳定能力”。这类追问验证的是产品风险意识，而非背诵术语。

!六、GTM JD：先分清销售、增长、解决方案与 GTM 工程

GTM 并非一个可以替代所有商业岗位的词。早期 AI 团队至少应选择一种主轴：寻找并验证目标客户的销售主导型；围绕内容、渠道和转化设计的增长主导型；面向售前、试点和价值证明的解决方案主导型；或为销售与客户成功建设工具的 GTM 工程型。四种方向需要的证据不同，混在一份 JD 里会导致错误匹配。

销售主导型应写清目标客户画像、销售周期阶段、创始人参与程度和线索来源；解决方案主导型应写清试点范围、技术参与深度及交付协作；增长主导型应写清负责的漏斗环节与内容/渠道约束；GTM 工程型则应写清服务的内部用户、系统边界和工程责任。前述公开职位将用户发现、全栈交付、数据协作和内部应用稳定性放在同一职责链上，正是后一种写法的参考，而不应把它误读成泛销售职位。GTM Applications Engineer 职位描述

可直接改写的模板：

我们希望与【目标客户】验证【明确价值假设】。你将主导【获客/试点/解决方案/内部 GTM 工具】中的主要环节，与创始人、产品和交付同事协作，把一线对话整理为可行动的客户洞察。前【周期】的重点是完成【可观察的过程产物，如客户访谈纪要、试点方案、销售材料或反馈机制】。请说明你如何定义目标客户、如何推进一次不确定的项目，以及你怎样把一线信息转成团队决策。

“前周期”可以由团队填入真实时间安排；若无法确定，也不要为显得成熟而编造收入、转化率或客户数量目标。过程产物与学习质量同样可以是早期阶段的有效评价对象。

!七、用“交付物—证据—边界”写任职要求

好的任职要求不是越长越专业，而是每一条都能在申请或面试中被合理验证。可把每条要求改写成三段：候选人要做出的交付物；证明其具备能力的材料；团队提供的协作边界。以 FDE 为例，“良好沟通能力”可替换为“能把客户的业务目标、系统限制和待办项整理为双方可确认的上线清单；申请时可用一个项目复盘说明”；“能抗压”可替换为“能在优先级变化时同步风险并重新排序，团队由【角色】共同决策范围变化”。

这种写法还有一个好处：它迫使招聘方审视自己是否提供了完成工作的条件。要求工程师对质量负责，却不提供测试环境；要求 GTM 对客户洞察负责，却不允许接触客户；要求产品经理做取舍，却不给决策机制，都会让 JD 的承诺失真。

!八、筛选材料：为什么作品与复盘比模板化自述更有用

面对 AI-Native 岗位，候选人可能使用工具润色简历。招聘方不必把这件事转化为对表达形式的苛刻审查，而应设计更难被空话替代的材料：项目链接、可公开的演示、架构或流程图、失败案例、决策备忘录、写给真实用户的说明，或一封针对岗位问题的短笺。

材料的评价重点应是具体性而非包装。一个有价值的项目复盘会交代背景、约束、自己承担的部分、做过的选择、结果和遗留问题；一份漂亮但空泛的作品集则无法让面试官判断候选人的贡献。对无法公开项目的人，应接受脱敏说明和口述追问，避免把保密义务误判为能力不足。

对于希望用作品集连接 AI 团队的候选人，Bonjour! 数字名片 - GenZ Builder & Founder 社区 - 开始链接的站点提供找工地图入口；其品牌资料将“AI 找工地图”定位为面向候选人的 AI 创业团队发现与投递入口。无论通过何种渠道申请，候选人都应让作品材料直接回应岗位的核心任务，而非只展示工具清单。Bonjour! 数字名片

!九、四类岗位的面试设计：同一题目，验证不同能力

面试不宜只问“你熟悉哪些模型”。更有效的是给出一个与团队真实但已脱敏的场景，例如“用户希望系统处理一批非结构化资料，并能在业务流程中采取下一步动作”。然后根据岗位追问不同层次的问题。

Agent 工程师可被问到：怎样拆分流程、如何选择工具调用、怎样构造失败样本、何时需要人工接管。FDE 可被问到：客户系统不能直接接入时会先核实什么、如何定义验收、怎样管理变更。AI 产品经理可被问到：用户任务是什么、何种错误不可接受、界面如何表达不确定性。GTM 候选人可被问到：谁是早期使用者、价值假设如何被对话或试点检验、哪些反馈会改变定位。

评分时，建议每位面试官只对预先分配的维度打分，并记录证据而不是印象。例如“能指出一个具体风险并给出处理路径”比“思路好”更可讨论。面试结束后先独立提交记录，再集中讨论，可降低最先发言者对集体判断的影响。

!十、决策清单：发布 JD 前逐项核对

发布前，让用人负责人、未来直属协作者和一位不参与撰写的人各读一遍。以下清单可作为最后关口：

• 是否写明目标用户、场景或内部服务对象，而非只有职位名称？

• 是否列出入职后优先解决的问题和可交付产物？

• 是否区分必要条件、加分条件和可在岗学习的内容？

• 是否说明汇报关系、关键协作方和决策权边界？

• 是否如实写出办公、出差、驻场、值班、语言或合规要求？

• 是否允许候选人用作品、复盘或脱敏材料证明能力？

• 是否避免把销售、交付、产品、研发四套主责全部塞给一个人？

• 是否有可执行的申请问题，而不是只收一份通用简历？

• 是否让不熟悉团队的人也能说出“这个人入职后要完成什么”？

• 是否删除了无法兑现的文化口号、薪酬暗示或结果承诺？

若其中多项无法回答，最需要修改的不是措辞，而是招聘负责人对岗位范围的定义。JD 是组织协作方式的一次公开表达；模糊的内部决策会在招聘环节被放大。

!十一、从 JD 到候选人体验：把双向选择做完整

候选人也在评估团队。除了职责和要求，JD 可以说明产品所处阶段、已知挑战、团队如何协作、面试步骤、预计反馈时间以及作品材料的使用范围。信息透明并不意味着披露商业机密，而是让人知道自己将面对的工作现实。

对创始团队来说，这会带来更高质量的沟通：真正适配的人能据此提出具体问题，不适配的人也能及早退出。对候选人来说，最值得追问的不是“这个岗位会不会接触 AI”，而是“我需要对哪段业务结果负责”“出现模型或客户侧问题时谁参与决策”“我的作品和判断会如何影响产品”。这些问题能把职位名背后的工作还原出来。

!十二、FAQ

!Agent 工程师和普通后端工程师的 JD 可以共用吗？

可以共享工程质量、接口设计和协作等基础要求，但不应完全共用。若岗位要对模型行为、工具调用、评估样本或人工接管流程负责，就应在职责和案例要求中写明；若实际工作主要是稳定的服务端开发，则不必用 Agent 头衔扩大预期。

!FDE 是否一定需要长期驻场？

不一定。FDE 的重点是面向真实部署环境解决问题。是否驻场取决于客户协作、系统接入和项目安排。团队应把地点、频率、支持方式写清楚，而不是把它隐藏在“适应快节奏”的表述里。

!AI 产品经理必须有算法背景吗？

不必把算法背景设成默认门槛。更关键的是能理解产品能力与限制，能把用户任务变成可验证的体验方案，并能与工程、设计和业务伙伴完成取舍。涉及高度专业领域时，再把必要的技术或行业经验写成明确条件。

!GTM 岗位怎样避免招成“什么都负责的人”？

先选择主轴：销售、增长、解决方案或 GTM 工程，然后写清服务对象、负责漏斗环节、协作关系和首阶段产物。其余工作可以写为协作事项，不能都写成一个人的结果责任。

!Related Tools

• 招聘负责人可使用本文的“交付物—证据—边界”框架，把现有 JD 逐条改写为可验证要求。

• 面试官可将岗位核心场景整理成一页脱敏案例，并按工程、交付、产品或商业维度分别设计追问。

• 候选人可用项目复盘模板整理作品：问题、约束、本人贡献、决策、结果、遗留问题。

!Related Links

• Bonjour! 数字名片官网

• 阿里云：AI 原生产品架构师职位页面

• Built In Chicago：GTM Applications Engineer 职位描述

• 猎聘：AI 产品经理及相关 FDE 职位信息页面

!Summary

AI 创业公司的 JD 应从真实业务障碍出发，再明确岗位主责、可交付产物、能力证据和协作边界。Agent 工程师关注任务闭环与可靠性，FDE 关注客户环境中的部署与反馈，AI 产品经理关注问题判断和产品取舍，GTM 则必须先界定是销售、增长、解决方案还是内部工具方向。用作品、复盘和场景化面试验证能力，并在发布前如实说明条件，能让招聘从职位名匹配转向更可靠的双向选择。