v1.11.0 补齐移动端技能族（iOS/Android/Swift/Kotlin），零技能率 8.0%→7.3%

Minor 版：v1.8.0 起挂账的「小红书 ios/android/swift/objective-c/sdk 别名核对」查到底——
不是别名写错，是整族词条缺失：161 条词表里没有任何移动端技能，导致客户端岗被判成「零技能」。

新增

• 词表 +7（161 → 168）：
  PROG.SWIFT、PROG.KOTLIN、PROG.OBJC、ENGINEERING.IOS、ENGINEERING.ANDROID、
  ENGINEERING.FLUTTER、ENGINEERING.REACTNATIVE；别名覆盖 swiftui / objc / objective c /
  iphone / react native / react-native。
• 学习资源 +7 个技能块（106 → 113 个技能有资源，资源条目 118 → 129）：Swift、Kotlin、
  Objective-C、iOS、Android、Flutter、React Native 各配官方文档/课程。
• 测试 +3（383 → 386）：test_mobile_skills_resolve、test_mobile_client_jd_extracts_skills、
  test_react_native_does_not_shadow_react（长 token 优先，React Native 不被 React 抢走）。

归因证据（不是拍脑袋加词）

小红书 667 条里 59 条零技能，按 tools/zero-skill-attribution.py 口径拆解：

分桶	条数	占比
非技术岗（正确行为）	4	6.8%
疑似词表缺词	44	74.6%
待人工（纯中文短 JD）	11	18.6%

top missing token：ios 17 / android 8 / swift 7 / objective-c 5 / sdk 5（sdk 是通用词，不加）。

数据变更（语料不变，指标口径不变）

指标	变更前	变更后
语料 / 公司 / 来源	4240 / 79 / 16	4240 / 79 / 16
零技能	339（8.0%）	311（7.3%）
技术岗零技能	322 / 3656（8.8%）	294 / 3656（8.0%）
小红书零技能	59（8.8%）	41（6.2%）
技能命中	161/161	168/168
学习资源覆盖	106/161（65.8%）	113/168（67.3%）
抽取 F1（test / 全量）	0.9565 / 0.9123	0.9565 / 0.9123（不变）
skill_pair Recall@5 / resume Recall@5	0.9750 / 0.2200	0.9750 / 0.2200（不变，MRR 0.9229→0.9208）

踩坑（已写进 memory-bank/lessons.md 第 8、9 条）

• 初版把技能名写成「iOS 开发 / Android 开发」。「开发」是 JD 高频通用词，TF-IDF 字符 n-gram
  把它算成强信号，挤掉了 gold 里 Java 的 top-5 位次（resume Recall@5 0.2200→0.2000，刚好卡容差线）。
  改成专有名词 iOS / Android 后恢复 0.2200。
• 结论：技能 name 只放专有名词，通用词放 aliases 或不放；改词表后必须看 eval_all.py 的匹配表，
  不能只看抽取 F1。

完整变更

v1.10.3...v1.11.0

在线体验

https://hdwqwu3howppf2z2xv9i2q.streamlit.app/

v1.10.3 修复历史行被批量替换污染

纯文档补丁。审查发现：前几轮为同步语料数字，批量替换把 README 的历史周表也改了——
v1.4.0 那行从「5832 条 / 81 家 / 零技能 21.5%」被改成「4240 条 / 79 家 / 8.0%」，
等于篡改了发布史。

修复

• 用 git show 0f9a64c:README.md（v1.6.0 基线）逐行比对 | W.. | 行，
  发现 6 条被污染（W8 / W16 / W17 / W19 / W20 / W21）。
• 用基线原文恢复这 6 行；恢复后再次比对 不一致 0 条。
• 工具留档：agent-team/tools/check-history-rows.mjs（检查）、fix-history-rows.mjs（恢复）。
• 教训写入 memory-bank/lessons.md 第 7 条：
  批量替换必须排除历史区段，改完要跑基线比对。

未改动

• 首屏 / 功能说明里的当前数字保持最新（4240 条 / 79 家 / 16 源 / 161 技能 / 零技能 8.0%）。
• 语料、代码、门禁全部未动。

验证

• 测试 383 通过；门禁 10 项全绿；历史行与基线一致。

v1.10.2 千问精判 427 条"规则拿不准"的岗位

把流水线的 --classify 阶段接上：规则判不出、也不像职能岗的岗位交给千问逐条判定，
结果回流到排除清单。再剔除 260 条，零技能率降到 8.0%。

新增：pipeline.mjs --classify

• 只导出 job_relevance.decide() == "uncertain" 的岗位（427 条，不是全部 842 条 unknown）——
  规则已能判定的不浪费 token。
• 用 qwen3.8-flash 分批判定（110 条/页，4 页，约 7 分钟）。
• 判定结果 runs/audit/unknown-verdicts.json，apply-relevance.py 读取后只采纳 drop，
  keep / unsure 一律保留（宁留噪音，不误删）。

判定分布：drop 260 / keep 136 / unsure 31。理由样例：职能-交付、职能-运营、职能-客服、职能-战略。

数据变更

指标	v1.10.1	v1.10.2
语料	4496	4240
公司数	79	79
零技能岗位	500（11.1%）	339（8.0%）
发布时间覆盖	3479（77.3%）	3323（78.4%）
唯一「公司+标题」	4265	4018
排除清单	1669	1938

零技能率从审查前的 22.7% 一路降到 8.0%：三成噪音被清掉了，剩下的基本是真·技术岗。

流水线补强

• 新增 --data 强制数据阶段：--classify 产生的 drop 需要重建才会生效，
  而审计只看"规则可判"的非技术岗，此时可能报 0 导致跳过。
• 零技能区间断言收紧到 5%~13%（原 8%~16%），与当前语料构成匹配。

验证

• 测试 383 通过；门禁 10 项全绿；快照常量同步 4240 / 79 / 4018。

v1.10.1 自动化维护链路 + 排除清单收敛修复

把「研发 → 排查 → 修补 → 验证 → 发布」做成一条可重复执行的流水线，并用它跑出了一轮收敛。

新增：agent-team/pipeline.mjs

node pipeline.mjs --config goals/xxx.json --audit-only      # 只体检，不改任何东西
node pipeline.mjs --config goals/xxx.json                  # 体检 + 数据修补 + 门禁验证
node pipeline.mjs --config goals/xxx.json --with-agents     # 额外跑 LLM 代码修复任务
node pipeline.mjs --config goals/xxx.json --release patch   # 全绿后提交/打 tag/推送

阶段	做什么	失败处理
1 体检	仓库扫描（硬编码/密钥/杂物）+ 语料审计（非技术/未知/零技能）	只报告
2 决策	把发现映射成动作（数据修补 / 代码任务 / 无需处理）	无动作则跳过
3 修补	数据：重算排除清单 → 重建语料 → 重生成 docs；代码：交给 agent-team	失败即停
4 验证	10 项门禁（run.mjs --gates-only）	红则停，不发布
5 发布	版本号 + commit + tag + push（默认关闭）	需显式 --release

设计要点：每阶段可单独跑；重活全在子窗口（主窗只收摘要）；发布必须显式授权。

修复：排除清单必须累积

流水线首次运行时踩到的坑：apply-relevance.py 从当前（已过滤）语料重算清单，
于是覆盖了原有 1607 条 → 下一次 merge 把它们全放回来（语料从 4557 弹回 6098，门禁立红）。

修复：清单改为只增不减的并集（existing | newly_classified），并记录
newlyExcluded / carriedOver 便于审计。清单现在 1669 条。

数据变更（链路的收敛结果）

指标	v1.10.0	v1.10.1
语料	4557	4501
公司数	79	79
零技能	521（11.4%）	505（11.2%）
发布时间覆盖	3525（77.3%）	3479（77.3%）
唯一「公司+标题」	4325	4270

第二轮补清的 56 条，是首轮剔除后去重顺序变化才浮出来的（此前被重复行挤掉）。
说明「剔除 → 重建 → 复查」至少要跑两轮才能收敛——这正是流水线要自动化的原因。

验证

• 测试 383 通过；门禁 10 项全绿（--audit-only 2 秒、完整链路过门禁约 90 秒）。
• 快照常量同步：4501 / 79 / 4270。

v1.10.0 语料审查：剔除 1607 条非 AI/技术研发岗

对全量语料做了一次成果审查：逐条判断岗位是否属于「AI / 软件技术研发」范围，
把职能岗（运营/销售/财务/HR/法务…）与非软件域（硬件/结构/光学/制造/生物…）剔除。

结论：6098 条里 1607 条（26%）不属于目标范围，剔除后 4557 条，
零技能率从 22.7% 降到 11.4% —— 之前的"零技能偏高"有一半是这个噪音造成的。

判定方法（规则为主 + LLM 抽样守门）

1. 规则层（src/data/job_relevance.py）：
   • 中文标题走 job_family.classify_title（技术标记优先，避免「产品研发工程师」误判）
   • 英文/未知标题走三层顺序判定：强技术信号 → 角色类型词/非软件域 → 通用技术词
     顺序是关键：AI Operations Lead 含 "AI" 但是运营；Tech Lead, Autonomy Systems 含 "lead" 但是技术岗
2. 验证层：用千问（qwen3.8-flash）对未知岗位独立判定 300 条（149 条返回、131 条 keep/drop 明确），
   规则与 LLM 一致率 100%（129/131 → 补两条强技术模式后 131/131）。
   LLM 在这里的角色是抽样审计员，不是全量标注工——全量跑要 30 分钟且易超时。

剔除机制（可 review、可复现）

• 清单：configs/exclude_job_ids.txt（1607 个 job_id，纯文本，能像代码一样被 review）
• 生成：tools/apply-relevance.py（读语料 → 调 job_relevance.decide → 写清单）
• 应用：scripts/merge_jobs.py::load_exclusions() 在合并时过滤，不修改原始 CSV
• 回归：tests/test_job_relevance.py（26 条边界用例）+ tests/test_exclude_list.py（清单解析）

数据变更

指标	变更前	变更后
语料规模	6098	4557
公司数	81	79（2 家只剩职能岗，整源被清空）
零技能岗位	1384（22.7%）	521（11.4%）
技术岗零技能	322/3655（8.8%）	322/3656（8.8%，不变）
发布时间覆盖	4464（73.2%）	3525（77.3%）
技能命中	161/161	161/161
唯一「公司+标题」	5833	4325

剔除最多的源：kuaishou 619、xiaohongshu 533、tencent 152、xiaomi 129、tech_kaggle 36。

副作用与已知限制

• 1609 条记为「已消失」：这些是被主动剔除的岗位，新鲜度状态把它们当成"本轮未出现"。
  这是刻意剔除的副作用，不是自然下线；依据见 configs/exclude_job_ids.txt。
• 424 条 uncertain 保留：规则判不出、也不像非技术岗（如「管培生」）——宁可留噪音也不误删。
• meituan_campus 反而从 5 条涨到 19 条：此前它与社招技术岗 JD 重复被去重，社招重复行剔除后它得以保留。
• 零技能占比区间断言同步收紧到 8%~16%（原 20%~28%）；放宽会掩盖"又混进非技术岗"。

验证

• 测试 355 → 383（新增 26 条相关性用例 + 2 条清单解析用例）。
• 门禁 10 项全绿；docs/metrics.md / docs/source_health.md 重跑生成并提交。
• 快照常量同步：4557 / 79 / 4325；README / PROJECT_REPORT / memory-bank 数字按脚本实测替换。

v1.9.1 华为校招接入（+47 条，JD 偏薄）

补丁版：在 v1.9.0 修复华为社招（578 条 → 219 条入库）之后，顺带接入华为校招。

新增

• src/crawler/huawei_campus.py：复用 huawei.py 的网关与解析，只把 jobType 从 SR 换成 CR。
• 实测 jobType=CR → 109 条 / 11 页；技术族过滤后 104 条；56 条因 JD 过短被清洗丢弃，
  实际入库 47 条（技能仅 10 种）。
• 三处注册：merge_jobs.FILES / SOURCE_BY_FILE、recrawl_all.CRAWLERS；
  source_health 增加来源标签「华为校招」。
• huawei.py 小幅参数化：fetch_page/crawl/to_rows 支持 job_type 与 job_id 前缀，
  日志改为 华为岗位（jobType=…），社招行为不变。

重要：不需要账号 cookie

校招页面提示“登录华为账号后可查看”，但接口匿名可访问：在带 cookie 与不带 cookie 两种情况下，
getJobPage 都返回 total=109。因此本轮未使用任何凭据，用户提供的 cookie 已建议作废。

数据变更

指标	变更前	变更后
语料规模	6054	6098
来源数	15	16（新增 huawei_campus）
公司数	81	81
唯一「公司+标题」	5798	5833
零技能	1350（22.3%）	1384（22.7%）
技术岗零技能	8.5%	8.8%
技能命中	161/161	161/161

已知限制

• 华为校招 JD 偏薄：104 条里 56 条不足 30 字（只写学历/专业要求），入库 47 条且技能种类仅 10 种。
  这批数据对指标贡献很小，保留的价值是覆盖校招渠道；若华为后续在接口里补全 JD，重跑即可自动受益。
• 与社招一样，只入技术族。

验证

• 测试 355 通过（复用 tests/test_huawei.py 的解析用例，校招走同一 to_rows；
  v1.9.0 笔记里的「356」为笔误）。
• 门禁 10 项全绿；docs/metrics.md / docs/source_health.md 重跑生成并提交。
• 快照常量同步：6098 / 81 / 5833。

v1.9.0 华为数据源修复：2 条 → 219 条

华为从 v1.6.0 起一直是 2 条 / 发布覆盖 0%，被标「⚠️ 关注」。本轮查明不是抓漏：
华为已把招聘搬到新站 career.huawei.com/cn，老门户接口 portalpub/getJob/newHr 只剩 2 条残留。

找到新站岗位列表接口后重写爬虫，华为从 2 条变成 288 条原始 / 219 条入库，
并顺带把技能覆盖补到 161/161（100%，此前缺「联邦学习」）。

修复

华为爬虫改用新站接口

• src/crawler/huawei.py 重写，纯 requests，无需登录 / 账号 / 浏览器：

  POST https://apigw-dgg-b0.huawei.com/api/apig/channelhw/recruitmentPosition/pub/getJobPage?X-HW-ID=app_000000035886
  headers: x-jalor-tenantalias: hcm / x-referer / x-alb-gray: prod / x-language: zh_CN
  body:    {"curPage": N, "pageSize": 10, "jobType": "SR"}
  ->       data.pageVO {totalRows: 578, totalPages: 58} + data.result[]
  

• 字段映射：jobId→hw_<id>、jobName→标题、jobFamilyName→岗位族、deptName→部门、
  workPlace→城市、lastUpdateDate→发布时间。

• 坑：接口用字面字符串 "None" 表示空值；jobDesc 常为 None，真 JD 在
  mainBusiness（标准职责）+ jobRequire（要求）；城市在 workPlace 而非 cityName。

• 口径与其它源一致：只入技术族（研发族 / 云服务族 / 质量与流程IT族），--all 可放开；
  --stats 只打印岗位族分布。

• 回归：tests/test_huawei.py（6 条，不发网络）。

数据变更

指标	变更前	变更后
语料规模	5837	6054
华为	2 条 / 发布覆盖 0%	219 条 / 发布覆盖 100%
公司数	81	81（未新增）
唯一「公司+标题」	5649	5798
零技能岗位	1254（21.5%）	1350（22.3%）
发布时间覆盖	4201（72.0%）	4420（73.0%）
技能命中	160/161（99.4%）	161/161（100.0%）
技术岗零技能	219/3446（6.4%）	308/3637（8.5%）

全站 578 条里只入技术族：研发族 269 / 云服务族 10 / 质量与流程IT族 9 = 288 条
（其余为财经 87、供应链 44、法务 43、制造 35、营销 22…）。
288 条原始中 64 条 JD 文本重复（岗位模板），按 text_hash 去重后入库 219 条。

已知限制

• 华为零技能率 44.8%（技术岗 46.9%），比其它源高。原因是「研发族」里包含大量
  硬件 / 结构 / 光学 / 制造工艺岗，JD 里不出现软件技能——属真实情况，不放宽判定。
• 老门户那 2 条岗位在新站已不存在，本轮被标记为「已消失」（inactive_history_rows=2）。
• 校招站仍需华为账号登录，本轮未接入；社招已覆盖 578 条，暂不需要账号。

验证

• 测试 350 → 356（新增 tests/test_huawei.py）。
• 门禁 10 项全绿；docs/metrics.md / docs/source_health.md 由脚本重跑生成并提交。
• 快照常量同步：tests/test_dataset_snapshot.py → 6054 / 81 / 5798。
• README / PROJECT_REPORT / memory-bank 数字按脚本实测同步（121 处）。

v1.8.1 华为数据源调研结论（渠道已迁移）

补丁版：只新增调研结论与复现方法，不改代码、不动语料。

结论

华为岗位只有 2 条不是我们抓漏，而是华为把招聘搬到了新站：

通道	现状
老门户接口（现爬虫用的 portalpub/getJob/newHr）	全站 2 条（API 与浏览器双向确认）
新站 career.huawei.com/cn/social-recruitment	页面显示 共 269 个职位，但列表由前端渲染，接口未暴露
新站校招页	明确要求登录华为账号
51job 第三方通道（仓库既有实验）	9 城市仅 3 条 AI 岗且无完整 JD

已确认可用的新站接口：calculateSocialRecruitmentJob（X-HW-ID + {"jobType":"SR"}）
→ 返回 175 个类目（含 familyCount），但不返回岗位；列表接口未在页面 XHR 与 JS bundle 中出现，
页面 HTML 也没有服务端渲染的岗位数据。

影响

• huawei 源在 docs/source_health.md 里仍是 2 条 / 发布覆盖 0% / 「⚠️ 关注」——
  这是渠道迁移导致，不是抽取器或词表问题。
• 复现方法写进 docs/source-triage-v1.7.md §8：
  一条看老接口 pageVO.totalRows，一条看新站类目接口，一条确认页面是否 SSR。

后续三条路（需产品决策）

1. 浏览器渲染抓取（无需账号）：能拿 269 条，慢且依赖 DOM。
2. 继续逆向新站列表接口：不确定能否成功。
3. 账号登录校招站：校招岗位必须登录；账号对社招无帮助。

验证

• 纯文档变更：测试 350 通过、10 项门禁全绿，jobs.jsonl / metrics.md / source_health.md 均未变。

v1.8.0 技术岗 / 非技术岗分层：零技能率不再是噪音

v1.7.1 的归因结论（零技能岗位里 79.5% 是职能岗）从"一次性分析脚本"升级为常规指标：
source_health 现在同时报告「总零技能率」和「技术岗零技能率」。

结论先行：快手 32.5% → 4.6%、小红书 37.4% → 8.3%。
之前被标「⚠️ 关注」的两个源，技术岗其实完全健康；异常来自它们同时挂着运营/产品/销售岗。

新增

岗位族判定（src/data/job_family.py）

• classify_title(title) → tech / non_tech / unknown，纯函数、无依赖。
• 技术标记优先：标题含「工程师/开发/算法/架构/大数据/SRE…」即为技术岗，
  避免「产品研发工程师」被「产品」误判成职能岗。
• unknown（如「管培生」）不计入技术岗分母，避免把模糊岗位硬塞进任一侧。

来源健康新增「技术岗零技能」列

• 总览新增一行：技术岗零技能 219 条 / 3446 条（6.4%）。
• 分来源表格新增一列，同时保留原来的「零技能」总口径。
• 判定口径里写明：状态判定仍按总零技能率，阈值未改。

本次指标（语料未变，仅新增口径）

口径	值
零技能（总）	1254 / 5837 = 21.5%
零技能（技术岗）	219 / 3446 = 6.4%
快手	32.5% → 4.6%（30/652）
小红书	37.4% → 8.3%（53/641）
美团校招	40.0% → 33.3%（1/3，样本过小）
华为	100% → 100%（1/1，样本 2 条）

为什么先不改状态阈值

把「⚠️ 关注」直接改成按技术岗零技能率判定，会让快手/小红书立刻变「✅ 正常」——
这是指标口径变更，会改变所有人对这两源的既有认知。本次只加列、不改判定，
把决策权留给维护者；需要切换时改 src/data/source_health.py 里的 status 计算一处即可。

验证

• 测试 335 → 350（新增 tests/test_job_family.py：15 条分类用例，含技术标记优先与 unknown 边界）。
• 门禁 10 项全绿；docs/metrics.md 零 diff（语料未变）；
  docs/source_health.md 有预期变更（新增列 + 总览一行），由脚本重跑生成。
• 未改：判定阈值、skill_taxonomy.yaml、jobs.jsonl 字段与语义、隐私与上传限制。

已知限制

• 标题判定是启发式：研发管理、技术运营 这类复合岗会归到 tech 或 unknown，
  属解释性指标，不适合做强断言（测试只锁明确用例）。
• 技术岗分母为 0 的源（如全部是职能岗的小源）该列显示 -，不参与汇总。

v1.7.2 美团校招/实习接入（含 5 条新增岗位）+ 工程经验沉淀

新增美团校招 / 实习爬虫并正式接入构建流水线。全量抓取 311 条技术类岗位，
但按 text_hash 与现有语料比对后发现其中 301 条与社招 JD 完全重复，真正新增只有 5 条——
因此这是一个小版本：语料 5832 → 5837，公司数不变。

新增

美团校招 / 实习爬虫

• 新增 src/crawler/meituan_campus.py：PC 版 jobType 过滤（1=校招、2=实习）。
• 无需登录 / cookie / 签名（2026-11 实测，与社招一致）。只需一轮查询 token
  （u_query_id / r_query_id）整轮复用——每页换新会让分页退回第 1 页。
• 字段映射：name→标题、jobDuty + jobRequirement→JD、cityList→城市、
  refreshTime→发布时间（走 fmt_publish_time）、jobUnionId→mtc_<id>（缺失时用标题+城市哈希兜底）。
• 口径与社招一致：只入技术类；jobFamily 为空时用标题技术词兜底并打印丢弃分类。
• 三处注册：merge_jobs.FILES / SOURCE_BY_FILE、recrawl_all.CRAWLERS。
• 回归：tests/test_meituan_campus.py（7 条，不发网络请求）。

工程经验沉淀

• 新增 memory-bank/lessons.md：把本轮踩到的 6 个"看起来对、实际错"的判断
  写成可复用清单（分页外推、去重键、派生文件过期、半注册源、恒真门禁、凭据边界），每条附"当时怎么发现的"。

数据变更

指标	变更前	变更后
语料规模	5832 条	5837 条
公司数	81	81（美团已有，未新增公司）
来源数	14	15（新增 meituan_campus）
唯一「公司+标题」	5645	5649
零技能岗位	1252（21.5%）	1254（21.5%）
发布时间覆盖	4196（72.0%）	4201（72.0%）
含部门+发布时间	3749	3754

meituan_campus 单源画像：5 条 / 1 家 / 发布覆盖 100% / 零技能 2 条（40%）/ 状态正常。

为什么要特别说明"只加了 5 条"

抓到的 311 条技术类岗位里：清洗后唯一 JD 306 段，其中 301 段（98.4%）与社招 meituan 完全重复。
即美团校招技术岗与社招共用同一套 JD。preflight_new_source.py 体检为 PASS
（0 个 id 冲突、0 源内重复、技能覆盖仍 160/161、must 占比 59.9%），所以可以安全并入；
但收益天花板很低，后续再从这里扩量的意义不大。详见 docs/source-triage-v1.7.md §7。

安全说明

• 本轮不需要任何账号凭据；过程中未使用、未落盘任何 cookie。
• 凭据边界（只从环境变量/仓库外文件读）与兜底检查（tools/repo-audit.mjs、
  tests/test_no_hardcoded_paths.py）已写入 memory-bank/lessons.md。

验证

• 测试 328 → 335（+7 条美团校招解析回归）；覆盖率 66.06%（门槛 55%，未变）。
• 门禁 10 项全绿；docs/metrics.md、docs/source_health.md 由脚本重跑生成（预期有 diff，
  因为语料变了；生成后 git diff --exit-code 校验为零）。
• 快照常量同步：tests/test_dataset_snapshot.py → 5837 / 81 / 5649。
• README / PROJECT_REPORT / memory-bank 的数字已按脚本实测值同步（73 处，非手改估算）。

已知限制

• 零技能代理覆盖率（job_neighbors）仍是 v1.4 口径（1228/1252，约 98%），本轮未重算，
  文档已标注；重算需要跑全语料代理，成本高于本次 2 条增量带来的价值。
• 美团校招接口属于非公开文档接口，字段名可能变化；scripts/probe_meituan.py --campus 可复检。