一、为什么这是"第一公理"
先交代问题背景。企学宝服务客户时，培训运营的第一件事永远是回答三个问题：
- 这个岗位的人应该会什么？（能力标准）
- 这个人实际会什么？（能力评估）
- 差的部分怎么补？（学习路径）
第2和第3个问题已经有大量技术文章（人才盘点、学习推荐），但第1个问题——能力标准从哪来——几乎所有人都默认"HR自己定义"。这在小规模时成立，当客户有上千个岗位、每年组织架构都在变的时候，人工定义维护不动，最后沦为"模型做了，锁在柜子里"。
我们的目标：让AI完成岗位能力建模80%的初稿工作，让HR把时间花在20%的专业判断上。
技术上的核心挑战有三个：
- 术语归一：同一个能力在不同企业的叫法千差万别（"跨部门协作"/"横向影响力"/"协同推进能力"是一回事吗？）
- 粒度控制：能力项拆多细？"沟通能力"太粗没法评估，"能在跨部门会议上用数据说服财务部门"太细没法复用
- 证据约束：LLM很乐意帮你"创造"岗位需要的能力——但那是编造，不是建模。所有提取出的能力项必须能追溯到输入材料
围绕这三个挑战，我们走了这样一条技术路线：
第0步：行业通用技能词典（一次性建设，持续运营）
│ 公开JD + 行业能力模型 → 聚类归一 → 技能本体
▼
第1步：岗位说明书解析（结构化抽取）
│ JD/岗位说明书/绩优述职报告 → 能力候选项
▼
第2步：能力项归一与映射（对齐到技能词典）
│ embedding召回 + LLM精判 → 标准能力项
▼
第3步：行为锚定（BARS生成与校准）
│ 每个能力项 → 分级行为描述（1-5级）
▼
第4步：五级映射链贯通
岗位 → 能力项 → 知识点 → 课程 → 学习内容
二、第0步：行业通用技能词典
一切的地基是一张技能词典——一个企业级的能力项全集，每个能力项有规范名称、定义、行为描述模板、与知识点/课程的映射关系。没有它，每次建模都是自由发挥，同一个能力在不同岗位模型里叫不同名字，人才盘点时数据完全对不齐。
2.1 从公开JD冷启动
词典的第一版来自公开数据的自举：
import re
from collections import defaultdict
class SkillTaxonomyBuilder:
"""从公开岗位数据构建技能词典"""
def __init__(self, embedding_client, llm_client):
self.embedder = embedding_client
self.llm = llm_client
async def build_from_job_posts(self, job_posts: list[dict],
min_frequency: int = 50) -> list[dict]:
"""
从岗位描述语料中提取高频技能词，聚类归一
job_posts: [{"title": "数据分析师", "requirements": "..."}, ...]
"""
# 1. LLM批量提取每份JD中的能力表述
raw_phrases = []
for post in job_posts:
phrases = await self._extract_capability_phrases(post)
raw_phrases.extend(phrases)
# 2. 词频统计 + 低频过滤（出现次数太少的不入库，避免长尾噪音）
freq = defaultdict(int)
for p in raw_phrases:
freq[p["phrase"]] += 1
candidates = [p for p in raw_phrases
if freq[p["phrase"]] >= min_frequency]
# 3. embedding聚类：语义相近的表述合并
clusters = self._cluster_by_embedding(candidates, threshold=0.88)
# 4. 每个聚类由LLM选出一个"规范名"并撰写统一定义
skills = []
for cluster in clusters:
canonical = await self._name_and_define(cluster)
skills.append({
"canonical_name": canonical["name"],
"definition": canonical["definition"],
"aliases": [c["phrase"] for c in cluster], # 别名集合
"frequency": sum(c["count"] for c in cluster),
"category": canonical["category"], # 专业能力/通用能力/领导力
"source_job_titles": list({
c["job_title"] for c in cluster}),
})
return skills
async def _extract_capability_phrases(self, post: dict) -> list[dict]:
"""从单份JD中提取能力表述"""
prompt = f"""从以下岗位要求中提取"能力表述"（描述任职者应具备的知识、技能、特质的短语）。
岗位：{post['title']}
要求：{post['requirements']}
要求：
1. 只提取明确出现的能力要求，不要推断
2. 每个能力表述保留原文措辞
3. 忽略纯经验年限要求（如"3年以上经验"）和学历要求
输出JSON：
{
{"phrases": [{
{"phrase": "原文表述", "context": "所在句子"}}]}}"""
result = json.loads(await self.llm.call(prompt))
return [{
"phrase": p["phrase"], "job_title": post["title"],
"count": 1} for p in result["phrases"]]
def _cluster_by_embedding(self, candidates: list[dict],
threshold: float) -> list[list[dict]]:
"""贪心聚类：表述按频率降序，逐个匹配已有簇或新建簇"""
sorted_cands = sorted(candidates,
key=lambda x: x["count"], reverse=True)
clusters = [] # 每个簇: {"centroid_emb": ..., "members": [...]}
for cand in sorted_cands:
emb = self.embedder.embed(cand["phrase"])
placed = False
for cluster in clusters:
sim = cosine_sim(emb, cluster["centroid_emb"])
if sim > threshold:
cluster["members"].append(cand)
# 增量更新质心
n = len(cluster["members"])
cluster["centroid_emb"] = (
cluster["centroid_emb"] * (n - 1) / n
+ emb / n
)
placed = True
break
if not placed:
clusters.append({
"centroid_emb": emb, "members": [cand]})
return [c["members"] for c in clusters]
async def _name_and_define(self, cluster: list[dict]) -> dict:
"""LLM为聚类确定规范名和定义"""
phrases = list({
c["phrase"] for c in cluster})[:20]
prompt = f"""以下是一组语义相近的能力表述，它们都属于同一个能力：
{json.dumps(phrases, ensure_ascii=False)}
请为这个能力：
1. 选出一个最准确、最专业的规范名称（或综合它们起一个）
2. 撰写一条30-60字的统一定义
3. 分类为：professional（专业能力）/ general（通用能力）/ leadership（领导力）
输出JSON：
{
{"name": "...", "definition": "...", "category": "..."}}"""
return json.loads(await self.llm.call(prompt))
贪心聚类而不是用KMeans，原因是KMeans需要预设K值——技能词典的规模事先不知道。贪心按频率降序处理，高频词先建簇，天然让"最重要的技能最先规范命名"。threshold=0.88是在验证集上扫出来的——0.85会把"项目管理"和"项目风险管理"合并（太粗），0.92会把"跨部门沟通"和"部门间协作"拆开（太细）。
2.2 词典的三层结构
最终的词典不是一张平表，是三层结构：
Category（能力大类）
├── 专业能力 / 通用能力 / 领导力 / 合规安全
│
└── Skill（标准能力项）
├── 规范名 + 定义 + 别名集合
├── 行为锚定模板（BARS，分级描述）
│
└── SkillKnowledgeLink（能力-知识点关联）
└── 支撑该能力达成的知识点集合（连接内容侧知识图谱）
第一版词典我们内置了约1200个能力项，覆盖制造、零售、互联网、金融四大行业。上线一年后的今天这个数字是4600——增长几乎全部来自客户的私有词汇回流（后面会讲）。
三、第1步：岗位说明书解析
有了词典，开始处理单个岗位。输入材料通常是三样：岗位说明书（职责+任职要求）、绩优员工的简历/述职、该岗位的历史招聘JD。
3.1 提取带证据约束
关键设计：每条提取结果必须携带证据引用，模型不允许输出没有证据支撑的能力项。
class JDCapabilityExtractor:
"""带证据约束的能力提取器"""
def __init__(self, llm_client, taxonomy: 'SkillTaxonomy'):
self.llm = llm_client
self.taxonomy = taxonomy
async def extract(self, doc: dict) -> list[dict]:
"""从岗位材料中提取能力项（带证据）"""
# 检索词典中与该岗位相关的候选能力（缩小LLM的判断范围）
relevant_skills = await self.taxonomy.search_similar_skills(
query=doc["text"],
top_k=80
)
prompt = f"""你是人才发展专家。请从以下岗位材料中识别该岗位所需的能力项。
【岗位材料】
{doc["text"]}
【候选能力清单】（优先从清单中匹配；材料中出现清单未覆盖的能力时，
允许提出新能力，但必须说明理由）
{json.dumps([s["canonical_name"] for s in relevant_skills], ensure_ascii=False)}
【输出要求】
每个识别出的能力项包含：
- skill_name: 匹配到的候选清单中的规范名，或新能力名
- evidence: 支撑该判断的原文片段（必须逐字引用，不得改写）
- confidence: high（材料明确提及）/ medium（材料隐含但较确定）/ low（推断成分较大）
- is_new: 是否清单外的新能力
- importance: 该能力在材料中的强调程度 critical/important/normal
【硬性规则】
1. evidence 必须是【岗位材料】中真实存在的连续文本片段
2. 材料中没有任何依据的能力，禁止输出
3. 输出JSON数组"""
raw_items = json.loads(await self.llm.call(prompt))
# 证据回验：检查每条evidence是否真的存在于原文
verified = []
for item in raw_items:
if self._verify_evidence(item["evidence"], doc["text"]):
verified.append(item)
else:
# 证据造假/改写——重试一次，再失败则丢弃并告警
retry = await self._retry_with_strict_rule(item, doc)
if retry and self._verify_evidence(retry["evidence"], doc["text"]):
verified.append(retry)
else:
self._log_hallucination(item, doc)
return verified
def _verify_evidence(self, evidence: str, source_text: str) -> bool:
"""证据回验：严格子串匹配 + 宽松规范化匹配"""
if not evidence:
return False
if evidence in source_text:
return True
# 规范化：去空格、统一标点，对抗LLM的格式漂移
norm_e = re.sub(r'\s+', '', evidence)
norm_s = re.sub(r'\s+', '', source_text)
return norm_e in norm_s
证据回验是整个提取环节的灵魂。 LLM做信息抽取最大的风险不是漏，而是"编"——它会把"负责跨部门项目推进"自信地扩展成"具备优秀的冲突调解能力"，听起来对，但材料里没有。回验逻辑简单粗暴：证据原文不在源文本里，重试一次，再不行丢弃并记录。上线后该机制平均拦截6%的无证据输出——这6%如果不拦截，会在HR复核时被识别为"AI胡说"，摧毁对整个系统的信任。
3.2 重要性分级
提取出的能力不是平权的。importance字段决定了后续学习路径的优先级（critical能力有gap → 排课优先级最高）。分级依据是LLM对材料强调程度的判断，加两条硬规则修正：
def adjust_importance(self, item: dict, doc: dict) -> str:
importance = item["confidence"] and item.get("importance", "normal")
# 硬规则1：出现在"任职要求"第一句的能力，至少升级为important
first_req_sentence = self._extract_first_requirement_sentence(
doc["text"]
)
if item["skill_name"] in first_req_sentence:
importance = max(importance, "important")
# 硬规则2：合规/安全类能力（安全生产、数据合规、反商业贿赂），
# 无论材料怎么措辞，一律critical——这些是培训的红线能力
if item["skill_name"] in self.COMPLIANCE_CRITICAL_SKILLS:
importance = "critical"
return importance
硬规则2值得展开——合规能力的强制critical是我们从客户事故里学到的。某制造客户的车间曾有员工考试通过但实际没掌握安全规程，出事后追责时发现安全能力在岗位模型里只是"normal"级。从那以后，安全/合规类能力在模型层面被强制置顶，不接受材料措辞的影响。
四、第2步：归一映射
LLM提取出的能力名可能是"跨部门协同推进"，词典里叫"跨部门协作"。归一映射把提取结果对齐到词典。
class SkillNormalizer:
"""提取结果 → 词典标准能力项的归一映射"""
def __init__(self, taxonomy: 'SkillTaxonomy', llm_client):
self.taxonomy = taxonomy
self.llm = llm_client
async def normalize(self, extracted_name: str,
evidence: str) -> tuple[str, str]:
"""
返回 (标准能力名, 映射方式)
映射方式: exact / alias / semantic / llm_judge / new_skill
"""
# 第1级：精确匹配规范名
hit = self.taxonomy.find_by_name(extracted_name)
if hit:
return hit.canonical_name, "exact"
# 第2级：别名匹配
hit = self.taxonomy.find_by_alias(extracted_name)
if hit:
return hit.canonical_name, "alias"
# 第3级：embedding语义匹配（高置信度直接采纳）
candidates = self.taxonomy.search(extracted_name, top_k=5)
if candidates and candidates[0].similarity > 0.93:
return candidates[0].canonical_name, "semantic"
# 第4级：LLM精判——给top5候选让LLM做选择题或判断题
prompt = f"""判断"跨部门协同推进"（语境：{evidence}）
与以下哪个标准能力是同义的：
{chr(10).join(f'{i+1}. {c.canonical_name}：{c.definition}'
for i, c in enumerate(candidates))}
{len(candidates)+1}. 以上都不是，它是一个新能力
输出JSON：{
{"choice": 序号, "reason": "一句话理由",
"new_skill_def": "如果选'以上都不是'，给出定义"}}"""
judge = json.loads(await self.llm.call(prompt))
if judge["choice"] <= len(candidates):
return candidates[judge["choice"] - 1].canonical_name, "llm_judge"
else:
# 新能力：进入待审核队列，由HR确认后入库
pending_id = await self.taxonomy.add_to_pending_review(
extracted_name, judge.get("new_skill_def")
)
return f"__pending__:{pending_id}", "new_skill"
四级瀑布策略（精确→别名→语义→LLM精判）的成本考虑：embedding匹配是毫秒级且几乎免费，LLM精判是秒级且有成本，所以语义阈值0.93以上直接采纳，0.85-0.93之间才升级到LLM判断。实测四级瀑布下，78%的提取结果在前两级归一完成，14%靠语义，6%走LLM精判，仅2%进入新能力审核队列——LLM调用量被压到了可接受的水平。
新能力处理是词典自增长的关键。 LLM判定"以上都不是"的能力进入待审核队列，HR确认入库后，它的表述作为别名、定义作为锚点写入词典。客户的私有词汇就是这样回流进通用词典的（词典从1200涨到4600的主要来源）。但有一条安全边界：客户A自定义的能力默认只在A的租户词典生效，不进入全局词典——避免某企业内部的黑话污染通用本体。跨租户复用的提名，由运营团队季度评审后人工晋升。
五、第3步：行为锚定（BARS）
能力项只是名字，"跨部门协作"怎么评估？HR领域有成熟答案——行为锚定等级评价法（BARS）：给每个能力写若干等级的行为描述，评估时"对号入座"而不是凭感觉打分。
传统BARS开发是重咨询工作（事件访谈→关键行为→等级分配），AI可以加速前三步：
class BARSGenerator:
"""为能力项生成分级行为描述"""
LEVELS = ["L1-基础", "L2-胜任", "L3-精通", "L4-专家", "L5-引领"]
async def generate(self, skill: dict, position_docs: list[dict]) -> dict:
prompt = f"""为能力「{skill['canonical_name']}」（定义：{skill['definition']}）
撰写五级行为锚定描述（BARS）。
参考材料（该能力相关岗位的真实工作要求）：
{json.dumps([d["excerpts"] for d in position_docs[:3]], ensure_ascii=False)}
【撰写要求】
1. 每级一条行为描述，30-50字，描述可观察的具体行为，禁止使用
"较好""较强"等无法验证的模糊程度词
2. 相邻等级的差异必须是"行为复杂度"的跃迁，不是同一行为的频率差异
（错误示例：L2"偶尔跨部门沟通"→L3"经常跨部门沟通"——频率不是复杂度）
（正确示例：L2"能参与跨部门项目"→L3"能主导跨部门项目并协调资源冲突"）
3. 描述要能用于评估普通员工，避免只描述高层行为
4. 语言风格统一（均以能力主体为省略主语的行为句）
输出JSON：
{
{"bars": [{
{"level": "L1-基础", "behavior": "..."}}, ...]}}"""
result = json.loads(await self.llm.call(prompt))
# 质量校验：模糊词检测 + 相邻等级差异检测
issues = []
for bar in result["bars"]:
fuzzy_hits = [w for w in self.FUZZY_WORDS if w in bar["behavior"]]
if fuzzy_hits:
issues.append(f"{bar['level']} 含模糊词 {fuzzy_hits}")
for a, b in zip(result["bars"], result["bars"][1:]):
if self._is_frequency_only_diff(a["behavior"], b["behavior"]):
issues.append(f"{a['level']}→{b['level']} 仅频率差异，缺复杂度跃迁")
if issues:
result["needs_revision"] = True
result["revision_notes"] = issues
return result
FUZZY_WORDS = ["较好", "较强", "一定程度", "基本", "一定的",
"能够独立开展（缺乏范围限定时）", "积极", "主动地"]
def _is_frequency_only_diff(self, lower: str, higher: str) -> bool:
"""用LLM判断两条BARS是否只有频率差异"""
prompt = f"""以下两条同一能力的行为描述，第二条相对第一条是否只是
"频率/数量"增加而没有"行为复杂度"跃迁？
低等级：{lower}
高等级：{higher}
输出JSON：{
{"frequency_only": true/false, "reason": "..."}}"""
r = json.loads(llm.call_sync(prompt))
return r.get("frequency_only", False)
这里体现我们对"AI初稿+人精修"边界的具体理解：行为描述的文字AI可以写，但"等级跃迁是否成立"AI只能提示，最终要人确认。 needs_revision标记的BARS进入HR精修队列，AI写的初稿平均能为每个能力节省40分钟的顾问撰写时间，但精修环节一个都不能省——BARS是评估的尺子，尺子刻度错了，后面所有测量全错。
六、第4步：五级映射链
到这里，岗位侧的模型建好了（岗位→能力项+BARS）。最后一步是把它和内容侧（知识点→课程）接通，形成完整链条：
岗位「数据分析师」
└── 能力「SQL数据查询」 要求等级 L3-精通
└── 支撑知识点
├── KP4001 窗口函数
├── KP4002 多表JOIN与执行计划
└── KP4017 大表查询优化
└── 承载课程
├── C2031《SQL进阶实战》（覆盖KP4001/4002）
└── C2088《查询性能调优》（覆盖KP4017）
能力-知识点的关联（SkillKnowledgeLink）怎么建？复用内容侧知识图谱的BELONGS_TO边，做双向锚定：
class CapabilityKnowledgeLinker:
"""能力 ↔ 知识点 关联构建"""
async def link(self, skill: dict) -> list[dict]:
# 路径1：从内容侧图谱反向聚合
# （知识点已被课程大纲标注，课程被打过技能标签）
indirect = await self.graph.find_kps_by_skill_tag(skill["canonical_name"])
# 路径2：LLM正向判断
# （拿技能定义 + BARS，逐条问"这个知识点对支撑该行为等级有必要吗"）
all_kps = await self.graph.get_all_knowledge_points()
direct = await self._llm_judge_relevance(skill, all_kps)
# 两条路径取并集，交集为高置信关联，仅单边命中进人工审核
merged = self._merge(indirect, direct)
return merged
async def _llm_judge_relevance(self, skill: dict, kps: list[dict]) -> list:
"""批量判断知识点与能力的相关性"""
relevant = []
# 按技能名做召回预过滤，只精判相似度top200的知识点，控制LLM调用量
candidates = await self.embed_search(skill["canonical_name"] +
skill["definition"],
corpus=kps, top_k=200)
for batch in self._chunk(candidates, 20):
prompt = f"""能力「{skill['canonical_name']}」的行为锚定：
{json.dumps(skill['bars'], ensure_ascii=False)}
判断以下每个知识点是否支撑该能力的达成：
{json.dumps([{'kp_id': k['id'], 'name': k['name']} for k in batch], ensure_ascii=False)}
输出JSON：{
{"links": [{
{"kp_id": "...", "relevance": "strong/moderate/weak"}}]}}
只输出strong和moderate。"""
result = json.loads(await self.llm.call(prompt))
relevant.extend(result["links"])
return relevant
映射链建好后，下游能力全部被激活：员工完成能力评估（对照BARS定级）→ 系统沿链计算gap → gap的知识点反查课程 → 生成个性化学习路径（这条路径规划的算法细节不在本文范围，是另一个话题）。
一个关键的数据结构决策：链条的每一跳都带权重而非布尔值。 "SQL数据查询"的L3等级，窗口函数是strong支撑、执行计划是strong、大表优化是moderate——下游做路径优先级时，strong知识点相关的课程排在前面。布尔值丢失了这个信息。
七、工程落地：建模流程的产品化
技术跑通后，最后一关是把它做成HR可自助操作的流程：
┌──────────────────────────────────────────────────────────┐
│ AI岗位建模工作台 │
│ │
│ ① 上传材料：岗位说明书 / JD / 绩优述职（可多个） │
│ ↓ │
│ ② AI初稿（约3分钟）： │
│ · 识别出 N 个能力项（标注来源证据 + importance分级） │
│ · 标注置信度：高/中/低（低置信项默认折叠待确认） │
│ ↓ │
│ ③ HR工作台逐项校准： │
│ · 采纳 / 修改名称（触发词典归一）/ 删除 / 补充新能力 │
│ · 设置目标等级（该岗位各能力的要求L1-L5） │
│ ↓ │
│ ④ 生成岗位模型草稿 → BARS预览 → 发布 │
│ · 发布后锁定版本，员工评估按版本执行 │
└──────────────────────────────────────────────────────────┘
一条真实的建模时间线（某零售客户，"门店店长"岗位）：上传材料3分钟 → AI初稿2.5分钟（识别出17个能力项，2个低置信折叠）→ HR校准32分钟（采纳14个、合并3个为1个、补充1个客户特有能力、调整5个importance）→ 目标等级设定10分钟 → 发布。从3周的咨询项目到48分钟的人机协作，这就是这套技术路线的实际意义。
AI初稿的采纳率（HR未修改直接确认的能力项占比）是模型质量的核心KPI，我们稳定在74%左右——这个数字我们对外从不宣传"AI全自动建模"，74%的初稿采纳率意味着每个岗位仍有4-5项需要专业判断，这是特性不是缺陷：把人的判断力集中在真正需要的地方。
八、踩坑实录
坑1：LLM把"任职资格"当"能力要求"。
早期提取器会输出"本科及以上学历""3年数据分析经验"这类条目——它们是门槛条件，不是可培养的能力。区分不清会导致学习路径荒谬（系统给专科员工推荐"升本课程"）。修复：提取Prompt显式排除经验/学历条目 + 后处理规则过滤 + 新增requirement_type字段把"门槛条件"作为独立输出（门槛本身也有用——盘点时要看"学历达标率"，但绝不进能力模型）。
坑2：跨行业术语污染。
通用词典初期用互联网JD为主语料训练，给制造业建模时出现灾难——车间"班组长"被提取出"对齐颗粒度"。根因是embedding召回按语义相似度，而我们的语义空间被互联网黑话主导。修复是行业语料分区：词典按行业打标签，制造业客户建模只在制造业子空间内召回候选。技能本体没有绝对中立，它带着语料的口音。
坑3：BARS的"形容词地狱"。
AI写BARS有强烈的文风倾向："能够出色地完成跨部门协调""具备高度的成本意识"——全是无法验证的形容词。用FUZZY_WORDS清单拦截后AI学会了换花样："能够高效地""能够妥善地"。语言在变，不可验证的本质没变。最终解法不是扩充黑名单，而是把校验器升级为LLM判断："该描述能否让两个不了解此员工的评估者做出一致判断？"——用可验证性测试替代词表匹配。
坑4：目标等级设置的"全员拉满"。
试点客户给"初级数据分析师"的全部17个能力项都设了L4要求——模型逻辑上成立，实际等于没建（没人能全达标，学习路径永远爆红）。产品层面后来加了约束引导：每个岗位模型中L4以上要求的能力占比不得超过30%，超出时提示HR复核。技术上正确不等于组织上可行——建模产品必须防住这种"把标尺当许愿池"的使用模式。
坑5：词典版本与岗位模型的耦合。
词典v1里"跨部门协作"的定义较窄，某岗位模型v1基于它建。词典v2修订了定义（吸收了新别名），重新自动映射时该岗位的能力被静默改判——员工的评估记录挂在旧能力上，新旧定义下的员工"被同一个人但不同能力"。修复：岗位模型发布时冻结能力项定义快照（定义文本随模型版本存档，不随词典升级漂移），词典升级只影响新建模型，存量模型由HR决定是否主动升级。
九、总结
岗位能力建模这条技术路线，本质是把一个传统咨询方法论（胜任力建模+BARS）拆解为AI可执行、人可校准的工序流水线：
- 词典先行：没有统一的能力本体，建模就是各说各话。四级归一瀑布把86%的对齐工作压到了零LLM成本
- 证据硬约束：无证据的提取一律拦截，这是HR信任AI初稿的前提——一次"AI胡说"毁掉的信任，十个准确案例都补不回来
- BARS是质量分水岭：能写出可验证的行为描述，AI才真正进入专业领域；写不出，就只是个词频工具
- 版本冻结：模型一旦用于评估就是组织契约，技术系统必须尊重这一点
我们给自己定的边界很清晰：AI负责"穷举与初稿"，人负责"裁剪与定夺"。 17个能力项里AI漏掉的那2个、目标等级设得对不对、BARS的等级跃迁是否成立——这些判断不值得让AI冒险，而剩下的80%体力活，AI确实能把三周压成两天。
作者注：文中技术实现为企学宝人才发展产品线的实践总结，已做简化与脱敏。BARS（行为锚定等级评价法）相关方法论参考了组织行为学经典文献，具体实施请结合企业实际人才管理体系。
