一、能力概览 先打分(在下方清单里选等级),上面的雷达图和进度条会自动更新。达成率 = 当前等级 ÷ 目标等级。
53技能项总数
0已达目标等级
0%总体达成率
业务发现最薄弱能力域
六大能力域达成率
外圈 = 达标线(100%)
二、技能思维导图 点击域节点展开该域下的技能项;点击任意节点在右侧查看要求、自检问题并设置当前等级。节点填充色随等级变化。
L0 没接触L1 知道概念L2 指导下能做L3 能独立做并讲清L4 能定标准/教人边框 = 所属能力域
三、53 项技能清单 在这里打分最快:每行右侧下拉框选择当前等级。绿色 ✓ = 已达到目标等级。评分保存在本机浏览器,下次打开还在。
改动即时生效并保存在本机;清除浏览器数据会丢失,建议导出 JSON 备份。
表格较宽,可左右滑动查看完整内容 →
| 技能项 | 目标 | 具体要求 | 自检问题(答得出 = 达标) | 当前等级 |
|---|---|---|---|---|
| Business · 业务发现 — 把客户的一句「我们要做 AI」翻译成可落地、可衡量的场景。 | ||||
| Discovery 访谈 | L3 | 用结构化提问在 30–60 分钟内问清业务流程、数据量、系统现状、决策链与成功指标 | 给你 30 分钟和一位业务负责人,你能问出「什么结果算成功」的具体数字吗? | |
| 业务流程梳理 | L3 | 画出当前业务的完整流程图,标注每一步的耗时、责任人、出错率 | 你能画出客户某个流程的完整图,并指出最耗时的那一步花多少分钟吗? | |
| AI 机会识别 | L3 | 判断哪些环节适合 AI、哪些不适合,并说明不适合的理由 | 你能说出三个「看起来能做但我不建议做 AI」的场景及理由吗? | |
| 成功指标定义 | L3 | 把模糊期望翻译成可测量的指标(准确率、耗时、成本、覆盖率) | 客户说「提效」,你能当场把它变成可测的数字吗? | |
| ROI 与商业论证 | L3 | 算清投入产出,能用三句话讲明白值不值 | 给你一组业务数据,你能算出回收周期并给出可核对的过程吗? | |
| 报价与商业模式 | L2 | 知道 AI 项目的报价方式(项目制 / 人月制 / 订阅制)及各自适用条件 | 你能说明什么情况下 AI 模块不该按人月报价吗? | |
| 行业知识 | L3 | 至少深耕一个垂直行业的业务流程与监管约束 | 你能说出目标行业里三个 AI 不能碰的红线吗? | |
| 干系人与决策链 | L2 | 识别谁使用、谁拍板、谁能否决,并分别准备材料 | 你能列出一个项目里所有关键角色及各自关心什么吗? | |
| AI Engineering · AI 工程 — 从模型调用到推理落地:AI 应用本身的设计与实现能力,这是 AI-FDE 的技术核心。 | ||||
| LLM 能力与边界 | L3 | 理解 Token、上下文窗口、概率生成本质;清楚幻觉来源与四类必错场景 | 你能列出三个模型一定会出错的场景,并说明为什么吗? | |
| Prompt 工程 | L3 | 结构化提示词四要素;Prompt 版本管理与回归 | 你改一次 Prompt 后,能说清楚效果好在哪、好多少吗? | |
| Context Engineering | L3 | 上下文预算、压缩与摘要、检索注入、工具结果裁剪、长会话策略 | 你能写出一张 Token 预算表,并说明超预算时先砍哪部分吗? | |
| RAG 全链路 | L3 | 解析 → 切分 → 向量化 → 检索 → Rerank → 生成 → 引用溯源 | 知识库答不准时,你能按链路逐段定位是哪一环的问题吗? | |
| 文档解析工程 | L3 | 扫描件 OCR、表格还原、多栏排版、标题层级重建 | 给你一份含扫描件和合并单元格的 PDF,你能把它解析到可用吗? | |
| Tool Calling | L3 | 工具设计原则、参数与返回结构、工具描述写给模型看 | 你的工具描述,换个人看能明白什么时候该调用它吗? | |
| MCP 开发 | L3 | 能独立开发 MCP Server(Tool / Resource / Transport / 认证) | 你能把一个内部查询接口包成 MCP Server 并被客户端调用吗? | |
| AI 工程实现(Python) | L3 | LLM SDK 调用、流式输出、异步并发、超时重试、错误处理;能把 AI 逻辑写成可维护代码 | 给你一个需求,你能用 Python 写完整条链路(调用 → 解析 → 校验 → 重试 → 落库)吗? | |
| Agent 设计与实现 | L3 | Agent Loop、状态、记忆、规划、停止条件、错误恢复 | 你能画出 Agent 循环图并标出每一步可能失败的地方吗? | |
| Multi-Agent 判断 | L2 | 知道什么时候不该用 Multi-Agent,以及主从 Handoff 优于自由群聊 | 你能说出三个「不该上 Multi-Agent」的理由吗? | |
| AI Coding Agent | L2 | 理解 Coding Agent 的核心循环,能跑通并用于真实项目 | 你能让 Coding Agent 独立完成一个真实的小需求吗? | |
| Evaluation 体系 | L3 | 评测集构造(五类题)、RAG 四指标、Agent 指标、回归测试 | 你改动一次之后,能给出「从多少变到多少」的数字吗? | |
| Guardrails 四层 | L3 | 输入侧 / 模型侧 / 工具侧 / 输出侧逐层设防 | 你能说清用户输入的一句话,在到达模型前经过了哪几道检查吗? | |
| AI Gateway | L3 | 统一入口:多模型路由、鉴权、限流、配额、审计日志、成本归集 | 你能搭一个统一入口,让所有 AI 调用都可控、可追溯、可计费吗? | |
| 私有化推理 | L2 | vLLM / Ollama 一类方案,能在客户内网跑起开源模型 | 客户要求完全内网,你能在一周内跑起一个可用模型吗? | |
| 量化与容量估算 | L2 | 量化方案选择、显存与并发的关系、容量规划 | 客户问「要几张卡」,你能给出有依据的答案吗? | |
| Software Engineering · 软件工程 — 把 AI 能力真正写进软件的工程底座。 | ||||
| Python | L3 | 语言基础、异步、数据处理、包管理、能读能改别人的代码(AI 侧的 SDK 与工程实现归 AI 工程域) | 给你一段没见过的 Python 代码,你能读懂并改成你要的样子吗? | |
| Java / 企业后端 | L2 | 能在现有企业后端上做集成与改造 | 你能在一个 Java 项目里加一个接口并跑通测试吗? | |
| REST API 设计与对接 | L3 | 接口契约、错误处理、幂等、超时与重试 | 你能设计一个 Agent 调用不会把系统打挂的接口吗? | |
| 数据库与 SQL | L3 | 表设计、查询优化、权限控制、注入防护 | 你能设计一个只允许查本部门数据的查询工具吗? | |
| 结构化输出 | L3 | 让模型稳定输出 JSON / 枚举 / 表格,并做校验与重试 | 模型返回格式错了,你的程序会自动纠正还是直接崩? | |
| Git 与版本管理 | L2 | 分支、Diff、回滚、协作规范 | AI 生成的代码改坏了,你能干净地回退吗? | |
| 代码理解与改造 | L3 | 读懂陌生代码库、定位改动点、评估影响面 | 给你一个没见过的项目,你能在一个小时内找到该改哪里吗? | |
| 低代码平台(Dify 等) | L3 | 用低代码平台快速搭出可用应用,并做工程化配置管理 | 你能用 Dify 在半天内搭出一个带引用和拒答的知识库吗? | |
| Enterprise Integration · 企业集成 — 把 AI 接进已有系统,并让它符合企业的权限与审计要求。 | ||||
| 身份认证 | L3 | SSO、Token、服务身份、AI 代理操作的身份归属 | 一条 AI 发起的操作,你能追到具体是哪个人的身份吗? | |
| 授权与 RBAC | L3 | 角色权限模型、最小权限原则、越权防护 | 你能证明这个 Agent 拿不到它不该看的数据吗? | |
| 审计与追溯 | L3 | 操作日志、留痕设计、可回放 | 客户要求复盘三个月前的一次 AI 操作,你能调出来吗? | |
| 企业系统对接 | L3 | 与 ERP / CRM / OA / 核心业务系统的对接方式与坑 | 客户只有老系统没有 API,你能给出三种接入路径吗? | |
| 限流与配额 | L2 | 并发控制、预算熔断、按部门配额 | 某个部门把预算跑爆了,你的系统会自动停住吗? | |
| 密钥与配置管理 | L2 | 密钥轮换、环境隔离、配置不进代码库 | 你的密钥有没有可能被人从代码库里翻出来? | |
| 数据安全与脱敏 | L3 | PII 识别与脱敏、数据分级、不出域约束 | 你能保证客户敏感数据不会出现在模型厂商的日志里吗? | |
| Operations Engineering · 运维工程 — 让 AI 应用在生产环境稳得住、看得见、算得清——部署、稳定性与成本治理。 | ||||
| Linux 与服务部署 | L3 | 进程、日志、网络、资源、服务化部署 | 服务挂了,你能不看文档在三分钟内定位原因吗? | |
| Docker / Compose | L3 | 镜像、编排、网络、卷、健康检查、一键启停 | 你能做到换一台机器,一条命令把整套系统起来吗? | |
| 可观测性 | L3 | Trace / Tool Call / 成本 / 延迟 / 日志 / 指标六项可视 | 客户问「AI 到底做了什么」,你能调出完整链路吗? | |
| 成本工程 | L3 | Token 成本模型、缓存复用、模型分级路由、单位经济性 | 客户问「一年多少钱」,你能当场算出来吗? | |
| 故障恢复 | L2 | 降级方案、重试与熔断、恢复时间目标 | 模型服务不可用时,你的应用是崩溃还是降级? | |
| 监控告警 | L2 | 关键指标阈值、告警规则、值班响应 | 效果悄悄变差了,你会在客户发现之前知道吗? | |
| Delivery & Communication · 交付沟通 — 把技术变成客户认可的价值——FDE 的临门一脚在这里。 | ||||
| POC 快速交付 | L3 | 5 天内从 Discovery 到可演示 POC 的标准动作 | 给你一个模糊需求,你能 5 天拿出可运行的东西吗? | |
| Demo 与叙事 | L3 | 3 分钟剧本:痛点 → 真实数据 → 对比 → 失败边界 → 价值 → 下一步 | 讲完后,客户能复述出你的价值主张吗? | |
| 技术文档 | L3 | 九件套:问题/Discovery/方案/架构/实现/评测/部署/Demo/价值 | 你的项目文档,换成别人能照着复现吗? | |
| 客户沟通与预期管理 | L3 | 管理期望、说清边界、拒绝不合理需求 | 客户要一个做不到的功能,你能既拒绝又不丢单吗? | |
| 合规与 AI 治理 | L3 | 生成式 AI 管理办法、算法备案、数据不出域、内容安全、审计留存 | 客户问合规,你能当场答出三条以上而不是推给法务吗? | |
| 失败边界与兜底 | L3 | 主动定义失败场景、人工接管、可回滚、幂等 | 你的方案里写清楚「AI 错了怎么办」了吗? | |
| 培训与知识转移 | L2 | 把能力交给客户团队,而不是一直绑定自己 | 你交付完三个月,客户能自己运维吗? | |
| 节奏与项目管理 | L3 | 范围裁剪、里程碑、风险前置暴露 | 进度要延期时,你能提前一周说出来并给出方案吗? | |
四、等级定义与达标线 自评最容易犯的错是「用过就算会」。所以每一级都给了可判定的标准。
| 等级 | 名称 | 判定标准 | 典型证据 |
|---|---|---|---|
| L0 | 没接触 | 没听说过,或只见过名词 | — |
| L1 | 知道概念 | 能说出它是什么、解决什么问题,但没动手做过 | 能给别人解释这个概念 |
| L2 | 指导下能做 | 照着文档或示例能跑通,遇到异常需要人帮 | 有一个跑通过的 Demo |
| L3 | 能独立做并讲清 | 从零独立完成,能处理常见异常,能用 2 分钟给客户讲明白 | 有真实项目产出 + 能量化效果 |
| L4 | 能定标准/教人 | 能定义团队的规范与选型标准,能把别人教会,能优化别人的方案 | 有被复用的规范文档或带出过人 |
达标线怎么定:本清单里标 L3 的是核心技能(不会就不算 AI-FDE),标 L2 的是支撑技能(可以不够深但不能空白)。没有 L1 项——因为只写「了解即可」的内容没有进清单。
健康的分布应该是:L3 及以上占 60% 以上,且六大域里没有任何一域低于 50%。如果某一域明显偏低,那通常就是你的转型瓶颈所在。
健康的分布应该是:L3 及以上占 60% 以上,且六大域里没有任何一域低于 50%。如果某一域明显偏低,那通常就是你的转型瓶颈所在。
五、不同背景的短板 AI-FDE 是复合岗位,没人天然全都会。四类常见背景各自的短板不一样,补的地方也不同。
实施 / 交付出身
起点:业务理解与客户沟通是强项,沟通类技能通常直接达标。
最容易缺:AI 工程(Evaluation、Context Engineering、私有化推理)与运维工程(可观测、成本)。习惯按既定方案交付,遇到需要自己定义技术方案的场景会犹豫。
补法:先补 Evaluation——它是把「感觉挺好」变成「数据证明」的唯一手段,也是你向客户证明价值最有力的材料。
最容易缺:AI 工程(Evaluation、Context Engineering、私有化推理)与运维工程(可观测、成本)。习惯按既定方案交付,遇到需要自己定义技术方案的场景会犹豫。
补法:先补 Evaluation——它是把「感觉挺好」变成「数据证明」的唯一手段,也是你向客户证明价值最有力的材料。
售前 / 方案出身
起点:叙事与商业论证是天然优势,Discovery 和 Demo 上手最快。
最容易缺:动手深度。方案讲得好但自己做不出来,容易被技术方问倒,也容易被客户追问细节时露怯。
补法:至少做到 L2 以上的 Python 与 AI 工程实现、低代码平台能力——不需要写得多好,但要能自己搭出来跑通。
最容易缺:动手深度。方案讲得好但自己做不出来,容易被技术方问倒,也容易被客户追问细节时露怯。
补法:至少做到 L2 以上的 Python 与 AI 工程实现、低代码平台能力——不需要写得多好,但要能自己搭出来跑通。
运维 / SA 出身
起点:运维工程与企业集成是强项,Linux、Docker、权限审计通常起点很高。
最容易缺:业务发现与叙事。做得出来但讲不出去,客户听不懂价值,这是运维背景转型最大的坎。
补法:把 Discovery 和 Demo 当成技术任务一样刻意练习——录下自己讲 Demo 的视频回看,通常看一次就知道问题在哪。
最容易缺:业务发现与叙事。做得出来但讲不出去,客户听不懂价值,这是运维背景转型最大的坎。
补法:把 Discovery 和 Demo 当成技术任务一样刻意练习——录下自己讲 Demo 的视频回看,通常看一次就知道问题在哪。
开发出身
起点:软件工程与 AI 工程上手最快,代码类技能基本无障碍。
最容易陷进去的坑:技术栈发散。喜欢自己造轮子、追新框架,忽略业务价值与交付节奏。
补法:强制自己每个项目都写完整的九件套文档,尤其是 Business Value 那一份——写不出来就说明这个技术没有业务价值。
最容易陷进去的坑:技术栈发散。喜欢自己造轮子、追新框架,忽略业务价值与交付节奏。
补法:强制自己每个项目都写完整的九件套文档,尤其是 Business Value 那一份——写不出来就说明这个技术没有业务价值。
最容易被忽略的一项:交付与沟通里的「失败边界与兜底设计」。大多数人把精力放在「让 AI 做对」,但客户真正在意的是「它做错了会怎样」。能不能在方案里写清楚失败时怎么兜底、怎么人工接管,是区分「Demo 选手」和「能交付的人」的分水岭。