{ "schemaVersion": "1.0", "standardVersion": "2026.1", "effectiveFrom": "2026-10-31", "license": "CC-BY-4.0", "publisher": "零七零六（苏州）科技有限公司", "canonical": "https://fde.0706.tech/", "disclaimers": [ "本体系是能力分级参考，不是国家职业资格；我们也不发放任何证书、不举办考试。截至目前，《国家职业分类大典》中没有「前沿部署工程师」这一职业。", "大厂职级与薪酬均为公开信息整理：大厂职级无官方公开口径且近年多次改革，薪酬为招聘广告与薪酬报告口径的区间估算，均不代表任何雇主实际支付，也不作为我方报价或承诺依据。", "级别看的是责任半径，不是技术深度，也不由年限自动决定；同一级别在两条通道上责任相同，只是能力权重不同。" ], "marks": [ { "key": "guided", "name": "依循", "desc": "有模板或指引时能完成，不需要自己判断" }, { "key": "solo", "name": "独立", "desc": "没有指引也能独立完成标准情形" }, { "key": "adaptive", "name": "应变", "desc": "能处理异常与非标准情形，并做出取舍" }, { "key": "systemic", "name": "系统", "desc": "能把做法固化为机制或标准，供他人照做" }, { "key": "industry", "name": "行业", "desc": "能影响外部：被同行采纳，或参与标准制定" } ], "domains": [ { "key": "business", "name": "业务认知", "desc": "看得懂行业机理、流程与角色分工，能用客户的指标语言描述问题。", "levels": { "L1": "按现成提纲记录流程与角色，复述时不出错", "L2": "独立跑完一次流程梳理，说清每个环节的输入、输出与责任人", "L3": "识别口径冲突与伪需求，在多部门诉求之间判断真实痛点", "L4": "判断业务线的 AI 适用边界，把判断标准写成可复用的评估清单", "L5": "提出被同行采用的行业问题框架或分类方法" } }, { "key": "scenario", "name": "场景工程", "desc": "把「我们想用 AI」翻译成可度量、有边界、可验收的场景，并锁定基线。", "levels": { "L1": "按模板把范围与验收填完整，不擅自扩大范围", "L2": "独立确认范围、量出基线、写出可判断的验收动作", "L3": "对一组场景排优先级并做取舍，说明放弃的理由", "L4": "定义组织的场景准入与验收标准，并让评审照此执行", "L5": "输出被外部引用的场景分类与判定方法" } }, { "key": "ai", "name": "AI 技术与调试", "desc": "模型与检索选型、评估集建设、失败兜底与拒答，能说清它什么时候会错。", "levels": { "L1": "按既定脚本复现正常与失败输出，并记录现象", "L2": "建 ≥20 条失败样例集，区分检索问题与生成问题", "L3": "处理模型、数据、工具三者交互导致的复杂故障，并设计兜底", "L4": "建评估与回归机制，把质量做成可检查的门禁", "L5": "提出被外部采用的评估方法或质量指标" } }, { "key": "delivery", "name": "交付保障", "desc": "数据与权限、成本与风险、进度与干系人；上线后有人用、出问题有人管。", "levels": { "L1": "按清单同步进展、完成交接，不遗漏已知风险", "L2": "打通数据与权限，说明脱敏与最小必要，推进试用与接管", "L3": "协调多方依赖与变更，控制范围蔓延与成本超支", "L4": "建立数据治理、事故应对与交付质量机制", "L5": "参与行业交付与合规规范的制定或实质讨论" } }, { "key": "engineering", "name": "交付工程化", "desc": "把一次性成果做成可复用资产（连接器 / 模板 / 评估集），让第二次更便宜。", "levels": { "L1": "整理可复用的片段与说明，供他人取用", "L2": "产出 ≥1 件资产（连接器/模板/评估集）并被第二处使用", "L3": "设计资产复用接口，沉淀 ≥2 件并统计复用效果", "L4": "建立资产库与复用指标，让同类项目工时可见下降", "L5": "资产被外部企业采用或开源复用" } } ], "levels": [ { "id": "L1", "rank": "初级", "keyword": "执行", "mark": "guided", "responsibility": "任务", "oneliner": "在既有框架与模板内，把一件边界清晰的事做对、交干净。", "stepUp": "入门基线：从「会用工具」变成「能交干净一件事」。", "scope": { "scenes": "1 个场景中的单个任务（一个模块、一段流程、一个接口）", "systems": "1 个系统内的 1–2 个模块", "stakeholders": "直接对接一线使用者与导师", "horizon": "天到周", "budget": "不承担预算决策" }, "titles": { "tech": "初级交付工程师", "business": "初级业务分析" }, "capability": { "business": "guided", "scenario": "guided", "ai": "guided", "delivery": "guided", "engineering": "guided" }, "evidence": [ "能独立跑通既有模板，并说明每一步在做什么", "有失败样例与修复记录（不是只贴成功截图）", "交接时能说清「哪里最容易出错」" ], "deliverables": [ "可运行的模块或配置", "启动说明", "失败样例记录" ], "metricLanguage": "任务级耗时与返工次数（分钟/小时口径）", "promotion": [ "连续 3 个任务无需返工即可交付", "能自己判断「这件事该不该暂停并求助」", "至少 1 份文档被他人直接复用" ], "breakthrough": "不做破格。这一级的价值在于基本功，跳过等于把风险留给下一级。", "misconception": "把「用过很多工具」当成能力 —— 工具熟练度不等于交付能力。", "failureMode": "任务做完但交不干净：没文档、没失败样例，第二个人接手就得从头问。" }, { "id": "L2", "rank": "中级", "keyword": "独立", "mark": "solo", "responsibility": "场景", "oneliner": "端到端对一个场景负责：范围、基线、验收、上线后能跑住。", "stepUp": "从「交任务」到「对结果负责」—— 开始为一条流程的成败签字。", "scope": { "scenes": "1 个场景全环（从需求到上线后运行）", "systems": "1–3 个系统的数据与接口打通", "stakeholders": "业务负责人 + 一线骨干 + IT/数据", "horizon": "周到月", "budget": "单场景量级，需报批" }, "titles": { "tech": "交付工程师", "business": "场景交付顾问" }, "capability": { "business": "solo", "scenario": "solo", "ai": "solo", "delivery": "solo", "engineering": "solo" }, "evidence": [ "一份范围卡：场景边界、基线数字、验收动作", "一套失败样例集（≥20 条），能说清它什么时候会错", "一次真实流程跑通记录（谁在什么时间用了什么）" ], "deliverables": [ "可运行场景", "验收单", "失败样例集", "运行手册初版" ], "metricLanguage": "场景指标（准确率、处理周期、单次耗时、错误率）", "promotion": [ "独立完成至少 2 个场景，且有 1 个连续运行 4 周以上", "能自己定义基线并把验收写成可判断的条件", "交付物中有 1 件被第二个场景复用" ], "breakthrough": "有同等规模场景的完整交付证据（含验收与接管）可跨过任务级考察，但不免除证据评审。", "misconception": "把「系统上线」当成交付完成 —— 上线只是开始，跑住才算。", "failureMode": "场景做完了但没人用：验收写的是功能，不是业务变化。" }, { "id": "L3", "rank": "高级", "keyword": "统筹", "mark": "adaptive", "responsibility": "项目群", "oneliner": "统筹多个场景的组合与资源，把一次攻坚变成可重复的打法。", "stepUp": "从「做好一个」到「决定做哪几个」—— 第一次拥有取舍权。", "scope": { "scenes": "3–10 个场景的组合（含优先级取舍）", "systems": "跨系统、跨部门的数据与流程编排", "stakeholders": "部门负责人及以上 + 多方供应商", "horizon": "季度", "budget": "项目群量级，参与预算编制" }, "titles": { "tech": "高级交付工程师", "business": "高级场景顾问" }, "capability": { "business": "adaptive", "scenario": "adaptive", "ai": "adaptive", "delivery": "adaptive", "engineering": "adaptive" }, "evidence": [ "一份场景组合规划：为什么先做这 3 个、放弃那 5 个", "一套可重复的评审与运营机制（谁在什么节点检查什么）", "至少 1 次跨部门冲突的处理记录（含取舍理由）" ], "deliverables": [ "场景组合路线图", "评审与运营机制", "架构决策记录", "可复用资产 ≥2 件" ], "metricLanguage": "组合价值（总成本、总工时、合格率、复用率）", "promotion": [ "同时统筹 ≥3 个场景且全部达到验收", "建立了被他人沿用（≥2 次）的机制或资产", "能在资源不足时做出可解释的取舍，而不是全都做" ], "breakthrough": "在单一复杂系统上达成 L4 级资产化成果（被跨项目复用 ≥3 次）可破格，需评审一致通过。", "misconception": "把「协调会议多」当成统筹能力 —— 统筹的产出是机制与取舍，不是会议数量。", "failureMode": "什么都在做、什么都差一点：没有取舍，等于没有优先级。" }, { "id": "L4", "rank": "资深", "keyword": "体系", "mark": "systemic", "responsibility": "组织体系", "oneliner": "设计组织的交付体系：质量门禁、资产化、能力培养，让结果不依赖个人。", "stepUp": "从「自己交付」到「让组织能交付」—— 产出从项目变成机制。", "scope": { "scenes": "跨项目群的体系设计（覆盖 10+ 场景 / 多业务线）", "systems": "平台与工具链（含复用架构与质量门禁）", "stakeholders": "分管领导 / 跨企业合作方", "horizon": "半年到一年", "budget": "体系级，主导编制" }, "titles": { "tech": "资深交付工程师", "business": "场景交付负责人" }, "capability": { "business": "systemic", "scenario": "systemic", "ai": "systemic", "delivery": "systemic", "engineering": "systemic" }, "evidence": [ "一套被执行的交付 SOP 与质量门禁（有检查记录，不是文档摆设）", "资产库：连接器/模板/评估集的复用数据（复用次数与工时下降）", "带出至少 1 名能独立负责场景的下级，并有交接验收记录" ], "deliverables": [ "交付体系与门禁", "资产库与复用指标", "人才培养路径", "跨项目复盘机制" ], "metricLanguage": "经营口径（资金占用、单位交付成本、资产入表、复用带来的毛利变化）", "promotion": [ "体系落地 ≥2 个季度，且交付事故率与返工率有可比较的下降", "资产复用使同类项目工时下降 ≥30%", "培养出 L2 及以上人员 ≥1 名（有独立交付证据）" ], "breakthrough": "在行业层做出被外部采纳的方法论或标准，可直接进入 L5 评审（需外部采纳证据）。", "misconception": "把「管的人多」当成体系能力 —— 体系能力看的是「人走了结果还在不在」。", "failureMode": "制度写得漂亮但没人执行：门禁形同虚设，问题仍然靠能人兜。" }, { "id": "L5", "rank": "专家", "keyword": "方法", "mark": "industry", "responsibility": "行业方法", "oneliner": "方法被行业采用：标准、生态与跨企业迁移，影响的不再是单个组织。", "stepUp": "从「组织内有效」到「外部也照做」—— 判定权交给外部证据。", "scope": { "scenes": "跨行业方法输出（含标准、教材、开源资产）", "systems": "行业级方法论与平台生态", "stakeholders": "行业组织 / 生态伙伴 / 监管与标准机构", "horizon": "一年以上", "budget": "生态级，涉及对外投入" }, "titles": { "tech": "交付专家", "business": "场景专家" }, "capability": { "business": "industry", "scenario": "industry", "ai": "industry", "delivery": "industry", "engineering": "industry" }, "evidence": [ "被外部机构或同行采纳的方法论（有引用、采用或联合发布记录）", "跨企业迁移的成功案例 ≥2 家（非同一集团内）", "公开可查的标准、教材、开源资产或行业报告署名" ], "deliverables": [ "行业标准或方法论", "生态合作机制", "公开可引用的研究成果" ], "metricLanguage": "行业影响（被采纳次数、生态伙伴数、行业口径变化）", "promotion": [ "方法被 ≥2 家非同集团企业实际采用并产生可核实结果", "在行业组织/标准工作中承担实质角色", "培养出 L3 及以上人员 ≥1 名" ], "breakthrough": "本级的判定以外部采纳为准，不接受自证；无外部证据时不评定本级。", "misconception": "把「讲得多」当成影响力 —— 影响力看的是别人有没有照着做。", "failureMode": "方法停留在演讲与文章：没有一家外部企业真正跑通。" } ], "evidenceCards": [ { "key": "diagnosis", "name": "业务诊断卡", "domain": "business", "byLevel": { "L1": "记录用户流程与问题，不遗漏关键角色", "L2": "能用客户指标语言描述问题，并给出量化基线", "L3": "能在多个部门间识别真实痛点与伪需求", "L4": "能判断业务线的 AI 适用边界，给出取舍依据", "L5": "能定义行业级问题框架并被外部采用" } }, { "key": "scenario", "name": "场景与验收卡", "domain": "scenario", "byLevel": { "L1": "按模板填写范围与验收，不擅自扩大", "L2": "独立确认范围、基线与验收动作", "L3": "对一组场景做优先级排序与资源分配", "L4": "定义组织的场景准入与验收标准", "L5": "输出可被同行引用的场景分类与判定方法" } }, { "key": "data", "name": "数据与权限卡", "domain": "delivery", "byLevel": { "L1": "在指导下完成数据接入，不动权限配置", "L2": "打通数据与权限，能说明脱敏与最小必要", "L3": "设计跨系统数据流与权限分级方案", "L4": "建立数据治理与审计机制", "L5": "参与行业数据与合规方法讨论" } }, { "key": "eval", "name": "AI 调试与评估卡", "domain": "ai", "byLevel": { "L1": "能复现正常与失败输出", "L2": "建立 ≥20 条失败样例集，能区分检索与生成问题", "L3": "设计评估体系，处理模型/数据/工具交互问题", "L4": "建立回归机制与质量门禁", "L5": "提出被行业采用的评估方法" } }, { "key": "operation", "name": "交付运营卡", "domain": "delivery", "byLevel": { "L1": "按清单交接，同步进展", "L2": "推进试用、验收与用户接管", "L3": "协调多方依赖与变更，控制范围蔓延", "L4": "建立交付质量与事故应对机制", "L5": "推动行业交付规范" } }, { "key": "asset", "name": "资产化卡", "domain": "engineering", "byLevel": { "L1": "能整理可复用的片段与说明", "L2": "产出 ≥1 件可复用资产并被第二处使用", "L3": "设计资产复用接口，沉淀 ≥2 件并统计复用", "L4": "建立资产库与复用指标，工时下降可量化", "L5": "资产被外部采用或开源复用" } } ], "channels": [ { "key": "tech", "name": "技术交付通道", "desc": "以系统构建、数据接入与评估调试为主线，对「能不能跑通、跑稳」负责。", "weight": { "business": 3, "scenario": 3, "ai": 5, "delivery": 3, "engineering": 5 } }, { "key": "business", "name": "业务交付通道", "desc": "以行业认知、场景定义与价值证明为主线，对「该不该做、做成没做成」负责。", "weight": { "business": 5, "scenario": 5, "ai": 2, "delivery": 4, "engineering": 3 } } ], "bigtechMap": [ { "level": "L1", "alibaba": "P4–P5", "bytedance": "1-1 ~ 2-1", "tencent": "T1.3–T2.1", "baidu": "T4–T5", "confidence": "中" }, { "level": "L2", "alibaba": "P5–P6", "bytedance": "2-1 ~ 2-2", "tencent": "T2.1–T2.3", "baidu": "T5–T6", "confidence": "高" }, { "level": "L3", "alibaba": "P6–P7", "bytedance": "2-2 ~ 3-1", "tencent": "T2.3–T3.1", "baidu": "T6–T7", "confidence": "中" }, { "level": "L4", "alibaba": "P7–P8", "bytedance": "3-1 ~ 3-2", "tencent": "T3.1–T3.3", "baidu": "T7–T8", "confidence": "中" }, { "level": "L5", "alibaba": "P8–P9", "bytedance": "3-2 ~ 4-1", "tencent": "T3.3–T4", "baidu": "T8–T9", "confidence": "低" } ], "salaryBands": [ { "level": "L1", "suzhou": "12–20", "hangzhou": "14–23", "shanghai": "16–26", "beijingShenzhen": "18–30", "basis": "应届至 2 年，招聘广告月薪 1.2–2.0 万反推" }, { "level": "L2", "suzhou": "20–33", "hangzhou": "23–38", "shanghai": "26–42", "beijingShenzhen": "30–48", "basis": "3–5 年，AI 应用集成月薪均值 4.7 万的下沿校准" }, { "level": "L3", "suzhou": "32–52", "hangzhou": "36–59", "shanghai": "42–68", "beijingShenzhen": "48–78", "basis": "5–8 年，含场景负责人溢价（AI 技能溢价 +62%）" }, { "level": "L4", "suzhou": "50–85", "hangzhou": "56–95", "shanghai": "65–110", "beijingShenzhen": "75–130", "basis": "8 年以上，对齐资深架构师区间下段" }, { "level": "L5", "suzhou": "80–130", "hangzhou": "90–145", "shanghai": "100–170", "beijingShenzhen": "120–200", "basis": "样本极少，参照头部资深 150–200 万的下沿" } ], "salaryNote": "杭州无单独的城市分档公开数据，按长三角区间（介于苏州与上海之间）估算；其余城市依据同一批招聘广告与薪酬报告口径。" }