跳转至

JD 拆解索引

JD 拆解

这里的每篇文章只拆一份具体 JD：先保留岗位的原始信息，再把职责、要求、用户、协作对象、指标和面试准备拆成可验证的问题。

JD 不是岗位全貌。招聘页面通常只写团队希望候选人承担的方向，实际工作范围还要结合面试沟通、汇报关系、团队配置和入职后的首个目标确认。文章中的推断会与截图或原文分开标注，不把推断写成招聘方的承诺。

flowchart LR
    A[一份 JD] --> B[提取原文信号]
    B --> C[还原实际工作]
    C --> D[识别用户与协作边界]
    D --> E[整理面试证据]
    E --> F[投递前核验]

核心关系是：JD 拆解把岗位文字转成一组关于工作对象、结果责任和能力证据的问题，帮助候选人判断是否值得投、应该怎么准备。

阅读说明

岗位信息、薪酬、组织架构和招聘批次变化较快。每篇文章会记录素材来源与读取时间，投递前仍应以目标公司的最新招聘页面和面试沟通为准。

案例列表

一篇 JD 怎么拆

  1. 先固定原文：记录岗位名称、城市、招聘类型、职位 ID、发布日期和来源；截图不完整时标出缺失部分，不补写看不见的内容
  2. 再拆职责：把「建设产品」「理解需求」「跟进指标」翻译成具体交付物、决策权限和结果责任
  3. 补用户与场景：确认使用者、购买者、决策者和协作方是否相同，区分 JD 明写的信息与分析者提出的假设
  4. 拆技术协作：对 AI 岗位追问模型、数据、检索、工具、评测、成本、权限与人工兜底分别由谁负责
  5. 转成面试证据：每条能力要求都对应一段经历、一个作品或一次可复现的实验，避免只准备术语
  6. 留下核验问题：把不能从 JD 判断的内容整理成向招聘方或业务面试官确认的问题

与常见岗位分类的关系

常见岗位与 JD按岗位方向建立通用地图；本栏目按真实招聘文本建立案例。先用岗位分类确定大方向，再用具体 JD 拆解判断某个团队的实际工作范围。

相关阅读

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用