研究员公约
编号： APDX-RES-001 适用范围： 核心技术序列 定位： Apodex 内部管理规范 · 统一、可计算、可执行的管理体系
1. 目的与适用范围
Section titled “1. 目的与适用范围”1.1 目的
Section titled “1.1 目的”本章程旨在构建一套统一、可计算、可执行的管理体系，覆盖以下三个方面：
- 定级体系： 将候选人的教育背景、公司背景和岗位实操经验，转化为公司内部的初始职级与薪酬区间，实现标准化定级。
- 组织架构与职责： 明确轮值主席、领域 Lead、版本 Owner 等角色在技术决策、资源分配和责任承担上的边界。
- 成长与流程闭环： 将员工的职级晋升、薪酬调整，与 Idea→版本→上线→复盘的产品技术流程统一起来，通过 Impact Leaderboard 记录和衡量真实贡献。
本章程致力于帮助团队构建世界级 Heavy Duty Solver。本章程允许对”系统级跃迁或范式级创新”设置特殊贡献认定与破格机制。
1.2 适用范围
Section titled “1.2 适用范围”适用于公司全体技术序列人员（Researcher / Scientist 方向）。
与其他工程、安全、QA、回滚等技术类 SOP 协同生效；若有冲突，以本章程在”职级 / 权责 / 计分 / 晋升 / 薪酬”相关条款为准。
当其他 SOP 涉及流程执行细节时，以该 SOP 为准；当其他 SOP 涉及责任归属、贡献归因、晋升与激励影响时，以本章程为准。
2. 职级体系与薪酬结构
Section titled “2. 职级体系与薪酬结构”2.1 职级梯度
Section titled “2.1 职级梯度”公司技术序列设置 10 个正式职级。为减少”同名不同级”的歧义，各职级能力边界定义如下（用于晋升评审必要条件）：
- L1–L3： 可独立执行既定研究任务，对问题定义依赖指导。
- L4–L5： 可独立定义并完成模块级问题，能在评测约束下自主迭代并闭环交付。
- L6–L7： 可定义系统结构与关键能力路线，能组织跨模块协同并承担跨版本责任。
- L8： 可推动方向级范式或架构升级，能将探索转化为可复用能力与组织资产。
- L9： 可创造新的系统能力层或新范式，显著提升组织整体上限。
- L10： 可长期引领组织研究范式与系统路线，形成跨版本持续影响。
薪酬结构说明： 具体薪酬区间、Band 对应金额等由 HR 单独管理，不在本章程中公开。本章程只规定职级梯度与 Band 调整规则（见第 7 章）。
4. 组织架构与技术治理角色
Section titled “4. 组织架构与技术治理角色”4.0 两层扁平结构总览
Section titled “4.0 两层扁平结构总览”Apodex 采用极度扁平的两层组织结构，全公司只有两种人：Lead（管理层） 和 IC（Individual Contributor，个人贡献者）。
| 层级 | 角色 | 核心定位 |
|---|---|---|
| 管理层 | 领域 Lead | 公司唯一的 Manager 角色；负责团队日常管理、Base IMP 分配与人事评价 |
| 个人贡献者 | IC（所有非 Lead 人员，不论职级高低） | 专注技术贡献；向所属 Lead 汇报；完成本职后可自由发起创新获取 Bonus IMP |
Org Chart 示意：
CEO└── Lead Committee（所有领域 Lead 组成，选举产生轮值技术主席） ├── Lead · Post-Train │ ├── IC · L1–L10（向该 Lead 汇报） │ └── IC · ... ├── Lead · Pre-Train │ └── IC · ... ├── Lead · Data ├── Lead · Infra ├── Lead · Verification ├── Lead · Benchmark └── Lead · AI for Science（及其他领域）
虚线跨域角色（不改变汇报关系）：Version Owner · Module Ownerℹ️ 扁平化的核心原则
职级高低不等于管理权限。一名 L10 级 IC 与一名 L2 级 IC 同属个人贡献者，均向所属 Lead 汇报，均无下属管理职责。Lead 是公司唯一的 Manager，也是唯一拥有人事权的角色。
4.1 Individual Contributor（IC）
Section titled “4.1 Individual Contributor（IC）”IC 是公司的主体，涵盖从 L1 到 L10 的所有非 Lead 人员，不论职级高低，均属于 IC。
汇报关系： 每位 IC 有且仅有一个明确的直属 Lead，日常工作任务由该 Lead 分配，绩效评价与 Base IMP 由该 Lead 负责。
工作模式：
- 本职工作（Base）： 完成直属 Lead 分配的任务，获得 Base IMP；这是每位 IC 的基础职责，不可缺失；
- 创新贡献（Bonus）： 在完成本职 Base 任务的前提下，IC 可自由发起 Idea、参与跨领域协作、担任虚拟任务角色，获得 Bonus IMP；
- 跨域参与： IC 可在不改变汇报关系的前提下，担任 Version Owner 或 Module Owner 等虚拟角色，任务结束后自然卸职，不影响其在原团队的汇报关系。
4.2 领域 Lead —— 公司唯一管理层
Section titled “4.2 领域 Lead —— 公司唯一管理层”领域 Lead 是公司唯一的 Manager 角色，拥有对所属 IC 的人事权。Lead 之间地位平等，共同组成 Lead Committee（见 4.3）。
任职条件：
- 职级一般为 L5 及以上，多为 Staff / Senior Staff；
- 在对应技术领域内具有持续的高水平贡献记录；
- 由 CEO 与 Lead Committee 共同确认任命。
当前确定领域： Post-Train、Pre-Train、Data、Infra、Verification、Benchmark、AI for Science 等，随业务发展动态调整。
核心职责：
- 人事权（唯一）： 对所属 IC 的 Base IMP 任务分配、日常考核与绩效评价拥有直接人事权；可就成员薪酬调整与晋升向公司提出正式建议，最终决定须经公司审批流程确认；
- 技术路线： 对本领域的技术路线与健康度负责，提出并维护中长期目标与版本级里程碑；
- 资源协调： 在 Lead Committee 中代表本领域参与跨域资源与优先级协调；
- 持续责任： 对领域的长期技术债、评测健康度、复用资产质量承担持续责任。
⚠️ Lead 的边界
Lead 的管理权限严格限于所属领域的 IC。Lead 不得干预其他领域 IC 的日常工作分配与绩效评价。跨领域协调须通过 Lead Committee 或版本 Owner 机制进行。
4.3 Lead Committee 与轮值技术主席
Section titled “4.3 Lead Committee 与轮值技术主席”所有领域 Lead 共同组成 Lead Committee，是公司技术治理的集体决策机构。Lead Committee 通过内部选举产生轮值技术主席，作为对外代表与内部协调者。
轮值技术主席任职条件：
- 职级不低于 L6，通常为 Senior L6 / L8 及以上；
- 内部领导力等级（Leadership Level）在 0–6 档中达到 4 档及以上；
- 由 Lead Committee 内部选举，由 CEO 最终任命，任期一般为 6 个月，可连任。
轮值技术主席主要职责：
- 参与或主导版本目标设定与算力预算上限决策；
- 在多个领域 Lead 之间协调资源与优先级；
- 对高风险 / 高算力 Idea 是否进入版本流程拥有最终技术否决权；
- 不直接决定个人职级和薪酬，仅提供晋升及调薪建议。
轮值技术主席的否决权适用于”高风险 / 高资源 / 高外部影响”的技术决策与上线裁决，不干预一般版本的日常工程细节。
4.4 虚拟任务角色：Version Owner 与 Module Owner
Section titled “4.4 虚拟任务角色：Version Owner 与 Module Owner”Version Owner 和 Module Owner 是虚拟任务角色，不是常规管理岗位。任何达到职级门槛的 IC 或 Lead 均可担任，任务完成后自然卸职，不改变担任者的汇报关系与团队归属。
| 角色 | 职级门槛 | 任务范围 | 卸职时机 |
|---|---|---|---|
| Version Owner | L6 及以上（IC 或 Lead 均可） | 对某一版本的整体目标达成、发布质量与复盘结论负最终责任 | 版本发布完成并通过复盘后自然卸职 |
| Module Owner | L5 及以上（IC 或 Lead 均可） | 对某一子模块 / 功能攻关的技术方案与交付结果负责 | 模块问题解决 / 功能交付完成后自然卸职 |
关键原则：
- 虚拟性： Owner 角色不附带下属管理权，不改变任何人的汇报关系；Owner 通过影响力与责任感驱动协作，而非行政权力；
- 自然卸职： 任务结束即卸职，无需正式免职流程；同一人可在不同时期担任多个版本或模块的 Owner；
- 责任兜底： Version Owner 必须对版本最终指标、风险与复盘结论签字确认；重大偏差必须进入复盘责任链；
- 联合署名： 高算力 / 高风险 Idea 可采用”联合署名制”，由 L4 / L5 担任执行 Owner，并由一名 L6 及以上 Mentor 联合签字作为技术背书，积分与责任按贡献分配。
4.5 Eval 部门：独立评测机制
Section titled “4.5 Eval 部门：独立评测机制”🎯 设立初衷：防止假进化
Apodex 的核心风险不是进化太慢，而是假进化——内部分数持续上升，但真实能力没有提升甚至在退步。Eval 部门作为独立于研发体系的质量守门人，持续测量”我们真的在进步吗”，是自进化主线目标得以可信的前提。
定位与汇报关系。 Eval 是公司的独立领域，设立 Eval Lead，直接向 CEO 汇报，同时作为 Lead Committee 的正式成员参与技术治理。Eval 的独立性是其公信力的来源，任何使 Eval 从属于某个研究组的安排均不被允许。
三项硬权力：
| 权力 | 说明 | 优先级 |
|---|---|---|
| 版本发布否决权 | Eval 出具《进化真实性报告》并由 CEO 签字后，版本方可推进发布。Eval 否决为硬门槛，版本 Owner 无权绕过；如有异议，可向 CEO 申诉，由 CEO 最终裁决 | 高于版本 Owner 的 Release Gate Checklist |
| 训练数据拒绝权 | 每批数据进入训练流程前须通过 Eval 审核（污染率、高难度样本比例、抽检错误率）；不达标批次整批退回，数据团队不得绕过 | 与数据团队并列，Eval 具有最终拒绝权 |
| 评测标准制定权 | ”什么叫模型进化了”由 Eval 定义；Benchmark 体系的设计、更新与难度调整由 Eval 主导，研究团队可提出建议但无否决权 | 独立于研究团队，不受版本目标影响 |
Eval Lead 任职规则。 Eval Lead 除须满足第 4.2 条的通用 Lead 任职条件外，还须遵守以下特殊规定：
- 兼任限制： Eval Lead 只能由公司内部应用场景的直接负责人兼任，或由 Eval Lead 同时兼任应用场景负责人。当前公司核心应用场景为 Treatos；其他研究组负责人不得兼任 Eval Lead；
- 兼任逻辑： 应用场景负责人是模型能力的真实使用者，最能感知”真实进步”与”假进化”的差异，由其担任 Eval Lead 可保证评测标准贴近真实业务，而非仅凭内部指标；
- 独立性保障： Eval Lead 在执行评测职责时，不受其所在研究组或版本 Owner 的指令约束，评测结论直接上报 CEO。
⚠️ 与 VER-002 发布流程的关系
Eval 否决权优先于 VER-002 第二十四条的 Release Gate Checklist。版本 Owner 完成 Checklist 后，仍须等待 Eval《进化真实性报告》通过并经 CEO 签字，方可执行线上发布。两套机制并行，Eval 报告是额外的独立门槛，不替代 Checklist。
5. Impact Leaderboard：积分体系与记分规则
Section titled “5. Impact Leaderboard：积分体系与记分规则”5.1 积分结构：Base IMP + Bonus IMP
Section titled “5.1 积分结构：Base IMP + Bonus IMP”IMP 积分分为两层，性质不同，来源不同：
| 层级 | 名称 | 说明 |
|---|---|---|
| Base | Base IMP · 日常任务积分 | 由主管（领域 Lead）分配日常工作任务，员工按质按时完成后自动获得。固定可预期，是每位员工的基础积分来源。脏活、重活、基础设施维护等必要工作均通过 Base IMP 保障激励。 |
| Bonus | Bonus IMP · 创新超额积分 | 在完成本职 Base 任务的前提下，员工自由发起创新项目、超额贡献或突破性产出后额外获得。Bonus IMP 是真正的创新溢价，倍率更高，不设上限。 |
ℹ️ 设计原则：自由在完成本职之后
每位员工归属于一个团队，由主管负责日常工作分配与考核。完成 Base 任务后，员工可自由发起创新，获得 Bonus IMP 作为额外奖励。IMP 是创新的奖励，而非日常工作的替代品。这一设计解决了三个问题：① 需要引导的人有主管负责；② 脏活有人干且有激励；③ 创新积极性通过 Bonus 高倍率保留。
IMP_Total = Base IMP + Bonus IMP（晋升门槛与 Band 调整均基于 IMP_Total）5.2 Base IMP 记分规则
Section titled “5.2 Base IMP 记分规则”Base IMP 由主管在任务分配时预设分值，员工完成后确认发放。分值参考如下：
| 任务类型 | 典型示例 | Base IMP 参考 |
|---|---|---|
| 性能优化任务 | 指标提升 ≥1% / ≥3% / ≥5% | 5 / 10 / 20 |
| 成本优化任务 | 成本降低 ≥5% / ≥15% / ≥30% | 3 / 8 / 15 |
| 基础设施维护 | Logging / Monitoring 升级、数据流水线维护 | 10 – 20 |
| 评测与数据任务 | 新评测框架、标注流水线、数据清洗 | 10 – 25 |
| 协作与组织任务 | Mentor 新人、版本协调、跨团队支持 | 3 – 15 |
| 可靠性与安全任务 | error rate 降低 ≥20%、合规加固 | 5 – 10 |
主管须在任务 Kickoff 时明确 Base IMP 分值，完成后由主管确认发放，不得事后随意调整。
5.3 Bonus IMP 记分规则
Section titled “5.3 Bonus IMP 记分规则”Bonus IMP 由员工在完成 Base 任务后自主发起，经复盘确认后发放。典型来源：
- 自由创新项目： 员工自主提出并完成的 L1/L2/L3 Idea，产出经版本复盘确认有效；
- 超额贡献： 超出主管分配范围、主动承担额外高价值工作；
- 突破性产出： 系统级跃迁或范式级创新，可叠加突破系数 B。
对于突破性产出，其 Idea 在版本复盘时可获得更高的完成度系数 β（见第 5.7 条），β 上限可扩展至 2.0–3.0。具体认定须写入复盘纪要，由领域 Lead 与轮值主席联合确认，且必须提供可复现证据（对比实验、可复用资产、跨版本影响等）：
- 常规创新：β 上限 1.0–1.2（正常完成度范围）
- 系统结构升级：β 可达 1.5
- 范式级跃迁：β 可达 2.0–3.0
5.4 事前 IMP 的性质与复盘调整
Section titled “5.4 事前 IMP 的性质与复盘调整”任务 Kickoff 阶段，每个 Idea 的预估 IMP 及贡献系数（wᵢ）的主要作用为对齐预期与提供激励锚点，是分工与责任的明确依据。同时，各 Idea 预估 IMP 之和构成版本 Bonus IMP 总盘子（V_IMP）的基准值（见第 5.7 条），复盘时按版本整体成功程度调整。
在版本复盘中，可根据实际执行轨迹、贡献质量及跨 Idea 影响，对 wᵢ 进行合理调整。调整须满足以下条件：
- 有明确书面依据，并在复盘纪要中说明调整理由；
- 不得仅凭最终结果倒推（即”结果好了就来抢分”）；
- 调整须经 Version Owner 联合领域 Lead 共同确认，不得由单方决定。
5.5 Enablement / Cross-Idea IMP（跨 Idea 贡献积分）
Section titled “5.5 Enablement / Cross-Idea IMP（跨 Idea 贡献积分）”大模型研发中，部分工作不直接体现为单一 Benchmark 提升，但对多个 Idea 的成功起到关键支撑作用。为反映此类贡献的真实价值，设立 Enablement / Cross-Idea IMP。
🔗 适用场景
- 数据 pipeline、训练框架、工具链等基础设施，对多个 Idea 产生支持但不直接体现为单一 Benchmark 提升；
- Sequential improvement 中的前置 enablement 贡献（如 A 的工作使 B、C 的实验成为可能）；
- 共享模块、评测框架、数据标注流水线等，被多个 Idea 复用的基础能力建设。
分配机制：
- 优先路径： Enablement 工作应尽量在立项时作为独立 Idea 纳入第 5.7 条的版本总盘子体系，赋予基准系数 α 和完成度系数 β，与其他 Idea 统一参与分配；
- 兜底路径： 对于无法在立项时预见、或跨越多个版本的 Enablement 贡献，可在复盘中由 Version Owner 联合领域 Lead 单独提出，需有可追溯证据（实验记录、依赖关系图、复用情况说明等），分值由复盘委员会根据实际影响范围确定。
本机制不与已计入 Base IMP 或 Infra IMP 的工作重复计算。
5.6 减分规则与晋升熔断
Section titled “5.6 减分规则与晋升熔断”Base IMP 减分（日常任务失职）：
- 严重线上事故或关键指标大幅下滑且被迫回滚：–10 ～ –30（视影响范围确定）；
- 未经审批绕过规定流程上线高风险版本：额外 –10；
- 未经审批私自发起大规模训练 / 实验，导致明显算力浪费（如 ≥ $5,000 或 ≥ 100k GPU 小时）：–10 ～ –40；
- 引入严重安全 / 合规问题：–15 ～ –30。
Bonus IMP 减分（协作破坏）：
- 抢夺他人成果、恶意删改作者名单、故意阻碍他人项目进展，经调查属实：–5 ～ –20；
- 严重协作问题导致版本整体延期或目标失败：–5 ～ –15。
⚠️ 熔断条款
若某员工在一个自然年度内引发公司定义的 S 级严重事故，经复盘确认主要责任：当年度不得进行职级晋升评审，仅可根据实际情况调整 Band（包括下调）。
为保证责任约束有效，若个人在 12 个月内累计发生重大资源违规、重大事故主要责任或经复盘确认的严重协作破坏行为，可在 6–12 个月内限制其担任 Version Owner（必要时限制 Module Owner）；解除限制需经领域 Lead 复核通过。
5.7 版本 IMP 总盘子与 Idea 记分机制
Section titled “5.7 版本 IMP 总盘子与 Idea 记分机制”🎯 设计初衷：齐心协力，而非各自为战
传统”事前定价、逐 Idea 结算”的方式容易导致研究员只盯着自己的 Idea，忽视整体版本成败。本机制以版本整体成功程度决定总 IMP 盘子，再向下分配，从根本上对齐个人利益与版本目标。同时，总盘子由管理层灵活掌握，可有效控制晋升与提薪节奏，大幅降低沟通管理成本。
第一步：版本复盘后确定总 IMP 盘子
Section titled “第一步：版本复盘后确定总 IMP 盘子”每个版本发布并完成复盘后，由 Version Owner 联合领域 Lead 与轮值主席，依据版本整体成功程度，确定本版本的 Bonus IMP 总盘子（V_IMP）。评估维度包括但不限于：
| 成功程度 | 典型特征 | V_IMP 参考倍率 |
|---|---|---|
| 超预期 | 核心 Benchmark 全面超出立项目标，版本影响力显著 | 1.2× – 1.5× |
| 达预期 | 核心目标基本达成，无重大缺失 | 1.0× |
| 部分达成 | 核心目标部分达成，有明显短板但整体可接受 | 0.7× – 0.9× |
| 未达预期 | 核心目标大幅未达成，版本整体失败或被迫回滚 | 0.3× – 0.6× |
V_IMP 基准值由立项时各 Idea 预估 IMP 之和确定；复盘时按上述倍率调整，最终值由轮值主席拍板确认，写入复盘纪要。
第二步：立项时为每个 Idea 赋予基准系数（α）
Section titled “第二步：立项时为每个 Idea 赋予基准系数（α）”版本 Kickoff 阶段，Version Owner 依据每个 Idea 对版本目标的重要程度，为其赋予 基准系数 α：
- 重要度高的 Idea（核心战场、关键路径）赋予较高 α，激励研究员优先投入；
- 支撑性、探索性 Idea 赋予较低 α；
- 所有 Idea 的 α 之和不要求等于 1，α 仅作为相对权重使用。
第三步：复盘时为每个 Idea 赋予完成度系数（β）
Section titled “第三步：复盘时为每个 Idea 赋予完成度系数（β）”版本复盘时，Version Owner 联合领域 Lead 对每个 Idea 的实际完成情况进行评估，赋予 完成度系数 β：
| 完成度 | 描述 | β 参考值 |
|---|---|---|
| 超额完成 | 超出预期目标，产出有额外价值 | 1.2 – 1.5 |
| 完整完成 | 达成立项目标 | 1.0 |
| 部分完成 | 核心目标部分达成 | 0.5 – 0.8 |
| 未完成 / 放弃 | 未产出有效结果 | 0 – 0.3 |
第四步：按 Idea 记分系数比例分配总盘子
Section titled “第四步：按 Idea 记分系数比例分配总盘子”每个 Idea 的 记分系数 S = α × β。在版本总 IMP 盘子（V_IMP）下，各 Idea 按记分系数的比例获得对应积分：
Idea_IMP = V_IMP × (Sᵢ / ΣS)Sᵢ = αᵢ × βᵢ；ΣS 为本版本所有 Idea 记分系数之和Idea_IMP 确定后，再按第 6 条的贡献系数 wᵢ 与角色系数 R，分配到参与该 Idea 的个人：
个人积分 = Idea_IMP × wᵢ × R（完整分配链：版本总盘子 → Idea 分配 → 个人分配）⚠️ 与现有 Base IMP 的关系
本机制适用于 Bonus IMP 的版本级分配。Base IMP（日常任务积分）仍按第 5.2 条独立结算，不纳入版本总盘子。两者相加构成员工最终 IMP_Total。
6. 多人成果的贡献分配机制
Section titled “6. 多人成果的贡献分配机制”6.1 参与角色系数 R（Role Multiplier）
Section titled “6.1 参与角色系数 R（Role Multiplier）”🎯 设计原则：奖励最优秀的人，而非吃大锅饭
世界上不存在”人人都是核心贡献者”的项目。本机制的目的是把最高奖励集中给真正推动结果的少数人，而不是让每个参与者都自认为是核心。角色认定以对整个版本 / 项目的实际贡献为准，而非对某个子模块的贡献，也不以论文署名或自我申报为准。
每位参与者在版本复盘时，由 Version Owner 联合领域 Lead 依据实际贡献证据，认定其参与角色，并对应乘以角色系数 R：
| 角色等级 | 系数 R | 认定标准（对整个版本 / 项目而言） | 典型比例参考 |
|---|---|---|---|
| 边缘参与 (Contributor) | × 1.0 | 有实质参与，但贡献属于支持性、辅助性工作；是团队的普通贡献者。注：这是大多数参与者的正常状态，不是负面评价。 | 约 60–70% 的参与者 |
| 核心成员 (Core Member) | × 1.2 | 在整个版本中属于前 20% 贡献者；对关键模块或关键路径有实质性推动，且贡献可被团队普遍认可。20 人团队中约 4 人可达到此级别。 | 约 20% 的参与者 |
| Lead / Owner (Lead / Version Owner) | × 1.4 | 对整个版本负有 5% 以上的核心贡献；是版本成败的关键决策者或核心执行者之一。20 人团队中约 1 人可达到此级别；不一定是 Version Owner 头衔，但必须是实质意义上的核心驱动者。 | 约 5% 的参与者 |
| 从 0 到 1 开创 (Paradigm Shift) | × 1.8 | 开创了一个全新的研究范式或技术方向，且该贡献在业界引发广泛关注与讨论（如行业顶级人物公开点评、引发同行跟进）。极少数情况才能达到。仅凭论文发表或模块创新不足以认定；需有外部可验证的范式影响力。 | 极少数，非常规 |
⚠️ 常见误区：以下情形不构成角色升级的依据
- 仅是某个子模块的核心贡献者，但对整体版本贡献有限；
- 在论文中署名为核心作者，但实际工程贡献不对应；
- 自我申报为”核心”，但缺乏团队普遍认可的贡献证据；
- 参与了重要讨论，但未实质推动关键结果。
6.2 贡献系数 wᵢ 与角色系数 R 的关系
Section titled “6.2 贡献系数 wᵢ 与角色系数 R 的关系”两套机制作用于不同维度，共同决定个人最终积分：
- 贡献系数 wᵢ：衡量在参与成员之间如何分配项目总积分（份额分配）；
- 角色系数 R：衡量个人在整个版本中的角色重量（乘数放大）。
个人积分 = 项目总积分 × wᵢ × R（wᵢ 之和 = 1；R 由复盘时独立认定，不影响 wᵢ 的分配）每个项目 / 版本在 Kickoff 阶段，由 Version Owner 在系统中为参与成员设定初始贡献系数 wᵢ；复盘时由 Version Owner 联合领域 Lead 最终确认 wᵢ 与 R，可对初始值进行合理调整。对 wᵢ 或 R 存在重大分歧时，可提交贡献证据包（提交记录、代码贡献、实验日志、评测贡献、复盘材料等），由领域 Lead 组织仲裁并将结论固化在复盘纪要中。
📋 wᵢ 调整规则
Kickoff 阶段设定的贡献系数（wᵢ）为初始预估，用于明确分工与责任。在版本复盘中，可基于实际贡献情况进行调整，调整幅度不受初始设定限制，但须同时满足：
- 在复盘纪要中说明调整依据并留存证据；
- 不得仅凭最终结果倒推，须有贡献过程的可追溯记录；
- 对于涉及跨 Idea 的贡献（如共享模块、基础设施、数据 pipeline），需在复盘中单独说明其影响范围，并在 wᵢ 或 Enablement IMP（第 5.5 条）中予以体现。
6.3 项目基础分与可分配分
Section titled “6.3 项目基础分与可分配分”为保障核心负责人的激励强度，项目总分可拆分为：
- 项目基础分： 占项目总分的 20%–30%，由核心 Owner 直接获得（不参与 wᵢ 分配）；
- 可分配分： 占项目总分的 70%–80%，按贡献系数 wᵢ × R 分配给参与成员。
6.4 完整分配示例
Section titled “6.4 完整分配示例”以下示例展示从版本总盘子到个人积分的完整分配链。
背景： 某版本共 3 个 Idea，版本整体达预期，V_IMP 基准值 = 各 Idea 预估 IMP 之和 = 100 分，倍率 1.0×，故 V_IMP = 100 分。
第一层：Idea 分配（按 α × β）
| Idea | 基准系数 α | 完成度系数 β | 记分系数 S = α×β | 占比 | Idea_IMP（×100） |
|---|---|---|---|---|---|
| Idea 1（核心战场） | 3 | 1.2（超额完成） | 3.6 | 3.6 / 7.5 = 48% | 48 分 |
| Idea 2（重要支撑） | 2 | 1.0（完整完成） | 2.0 | 2.0 / 7.5 = 27% | 27 分 |
| Idea 3（探索性） | 1 | 0.75（部分完成） | 0.75 | 0.75 / 7.5 = 10% | 10 分 |
| Enablement IMP（兜底路径，独立分配） | — | — | — | — | 15 分 |
ΣS = 3.6 + 2.0 + 0.75 = 6.35；Enablement 15 分为兜底路径单独核定，不参与比例计算，合计发放 100 分。
第二层：个人分配（以 Idea 1 为例，Idea_IMP = 48 分，4 名参与者）
| 成员 | 角色认定 | 系数 R | wᵢ | 个人积分（48 × wᵢ × R） |
|---|---|---|---|---|
| 成员 A | Lead / Owner | 1.4 | 0.35 | 23.5 分 |
| 成员 B | 核心成员 | 1.2 | 0.30 | 17.3 分 |
| 成员 C | 边缘参与 | 1.0 | 0.20 | 9.6 分 |
| 成员 D | 边缘参与 | 1.0 | 0.15 | 7.2 分 |
完整分配链：版本总盘子（V_IMP）→ Idea 分配（α × β 比例）→ 个人分配（wᵢ × R）。Lead/Owner 与边缘参与者的最终积分差距在两层分配中被双重放大。
📎 第六章规则细化见独立文档：
draft/贡献分配细则-APDX-RES-001-第六章.md
7. 晋升与调薪机制（基于 Leaderboard）
Section titled “7. 晋升与调薪机制（基于 Leaderboard）”7.1 近 3 年滚动积分 IMP_Total
Section titled “7.1 近 3 年滚动积分 IMP_Total”IMP_Total = Base IMP + Bonus IMP（统计窗口为近 3 年）7.2 职级晋升门槛
Section titled “7.2 职级晋升门槛”| 晋升路径 | 年度 IMP_Total（按自然年结算） |
|---|---|
| L1 → L2 | 10 |
| L2 → L3 | 15 |
| L3 → L4 | 20 |
| L4 → L5 | 30 |
| L5 → L6 | 45 |
| L6 → L7 | 60 |
| L7 → L8 | 80 |
| L8 → L9 | 120 |
| L9 → L10 | 200 |
晋升规则：
- 员工达到对应门槛，即具备申报该晋升级别的资格；
- 晋升需通过技术评审（包括但不限于项目深度、独立性、影响范围、技术前瞻性等维度的综合评估）；
- 积分按自然年度结算，每年清零重计；每个自然年度内，最多仅可晋升一个职级；
- 积分超过对应门槛 150% 以上的部分，仅用于提高职级内 Band，不进一步缩短晋升周期。
为避免将”积分达标”误解为”自动晋升”，晋升评审除满足积分门槛外，还必须满足对应职级的能力边界定义（见第 2.1 条）。
7.3 职级内 Band 调整
Section titled “7.3 职级内 Band 调整”以 Senior L6 为例：
| Band | 当前职级内 IMP_Total（参考） | 匹配薪酬区间位置 |
|---|---|---|
| A | 0–150 | 区间 0%–30% |
| B | 150–300 | 区间 30%–65% |
| C | ≥300 | 区间 65%–100% |
- Band 调整周期为每 6 个月一次；
- 职级晋升评审周期一般为每 12 个月一次；
- Band 积分从晋升当日清零重新计算，与用于晋升资格的 3 年滚动窗口分开。
7.4 数据平衡性保障
Section titled “7.4 数据平衡性保障”通过以下机制保证体系在激励与稳健之间保持平衡：
- 晋升步长限制： 每年最多晋升一个职级，即使积分暴涨也须逐级上升；
- 超额积分处理： 超过晋升门槛 150% 的部分积分只影响 Band 的提升，不进一步加速下一个职级晋升。
7.5 破格晋升条款（Exceptional Promotion）
Section titled “7.5 破格晋升条款（Exceptional Promotion）”🚀 为适配 Frontier Lab 的极端突破型贡献，设立破格晋升通道：
- 条件： 单一版本或项目在复盘确认后获得 Effective IMP ≥ 80，或突破系数 B ≥ 2.0 且影响跨版本复用（且 Effective IMP ≥ 30）；
- 结果： 在满足对应职级能力边界的前提下，可允许同一自然年度晋升两级（仅适用于 L4 及以上）；
- 审批： 领域 Lead 与轮值主席联合签字，经 CEO 批准后生效，并写入复盘纪要归档；
- 限制： 同一员工 3 年内最多使用一次破格晋升，不得由该条款连续跨越多个高阶职级。
7.6 等级通胀与能力密度控制
Section titled “7.6 等级通胀与能力密度控制”📉 为保持 Frontier Lab 的能力密度与等级含金量：
- 连续 3 年 IMP_Total 低于同级中位数 50%，触发等级复核；
- 复核可包括 Band 下调、晋升冻结，必要时职级下调；
- 等级并非终身制，必须持续反映能力边界与实际贡献。
8. 与版本流程的对接
Section titled “8. 与版本流程的对接”本公约与 APDX-VER-002（版本开发 SOP）协同生效。详细的 Idea 提交、评审立项、执行监控、上线回滚等流程见 APDX-VER-002。本章仅说明各角色在版本流程中的职责边界与积分结算规则。
8.1 角色职责边界
Section titled “8.1 角色职责边界”| 角色 | 在版本流程中的职责 |
|---|---|
| 轮值主席 | 参与高算力 / 高风险 Idea 的联合评审，拥有最终技术否决权 |
| 领域 Lead | 负责 Base IMP 任务分配与团队日常考核；对领域技术路线健康度负责 |
| Version Owner | 负责版本整体目标达成；复盘后确认贡献系数 wᵢ 并写入 Leaderboard |
| Module Owner | 负责子模块技术方案与交付结果；参与贡献系数协商 |
8.2 复盘与积分结算
Section titled “8.2 复盘与积分结算”每个完成的版本需组织正式复盘，由 Version Owner 主持，确认：
- 项目最终应获得的 IMP 积分（Base / Bonus）；
- 各核心成员的最终贡献系数 wᵢ；
- 将积分写入个人 Leaderboard，用于后续 Band 调整与晋升评审。
9. Mentor 机制
Section titled “9. Mentor 机制”9.1 角色与权责
Section titled “9.1 角色与权责”Mentor 为公司内部自愿承担专业辅导职责的员工，仅负责技术与经验指导，不享有任何行政管理权、人事任免权或资源分配权。
9.2 资格条件
Section titled “9.2 资格条件”职级达到 L6 及以上的员工自动具备 Mentor 资格，是否担任 Mentor 完全由本人自愿决定。
9.3 关系建立
Section titled “9.3 关系建立”任一员工可主动向具备资格的员工申请由其担任 Mentor，经双方同意后，通过公司指定方式完成登记即视为生效，无需额外审批。
9.4 基本义务
Section titled “9.4 基本义务”在 Mentor–Mentee 关系存续期间，Mentor 原则上每两周至少开展一次 1:1 专业沟通，并在每个自然季度结束前对辅导情况进行简要书面记录。
9.5 IMP 激励规则
Section titled “9.5 IMP 激励规则”对于已登记且当季实际开展辅导并完成记录的每一对 Mentor–Mentee 关系，Mentor 每自然季度可获得基础 3 IMP 奖励；如该季度内 Mentee 完成经确认的关键成果或晋升，Mentor 另可就该 Mentee 额外获得 2 IMP，每名 Mentee 每季度最多触发一次成长奖励。
10. 员工视角的透明性要求
Section titled “10. 员工视角的透明性要求”10.1 个人页面展示
Section titled “10.1 个人页面展示”公司内部系统须为每位员工提供清晰、实时的个人页面，至少包括：
- 当前职级（不展示 Band 信息，Band 仅用于内部薪酬管理，不对员工公示）；
- 当前基准总薪酬区间（展示所在职级的整体区间，不展示在区间内的具体位置）；
- 近 3 年 IMP_Total（Base + Bonus，3 年滚动）；
- 下一职级晋升所需的积分门槛与当前差额；
- 近期版本中已获得的项目积分明细（含 P/F/C 类型、项目名称及 Owner）；
- 最近 12 个月扣分摘要（不包含敏感细节，但包含等级影响与处理状态）。
10.2 员工自主判断
Section titled “10.2 员工自主判断”通过上述信息，员工应能够自行判断：
- 当前所处职级与成长阶段；
- 若达到下一职级，需要大致完成多少类型与规模的项目；
- 在一个自然年度内，合理预期的晋升机会与薪酬变化区间。
11. 在职最低标准与 PIP 机制
Section titled “11. 在职最低标准与 PIP 机制”高薪酬与高自由度并存，意味着”在职研究员”这一身份本身有最低定义。入职时双方共同签字确认以下三项最低在职标准，作为劳动合同的组成部分。
11.1 三项最低在职标准
Section titled “11.1 三项最低在职标准”📋 每季度一份研究日志（1–2 页） 记录当季在做什么、为什么做、走到哪了。失败的方向也算，沉默不算。
💡 至少一张 Idea 卡 不要求通过，不要求上线，只要求有想法、写下来、递交了。
🤝 至少一次团队贡献 Mentor 一次、参与技术评审、做一次分享，均算满足。
11.2 PIP 触发与处理流程
Section titled “11.2 PIP 触发与处理流程”| 触发条件 | 处理措施 |
|---|---|
| 连续 2 个季度，三项标准均缺失 | 触发 PIP（绩效改进计划，正式记录） |
| PIP 期间无实质改善 | 依合同约定解除劳动关系 |
⚖️ 设计原则
辞退的合法性来自事前共识，不是事后追责。三项标准正常工作的人顺手即可完成；完全躺平的人无法连续伪造。工资按承诺全额发放，这一点不因 PIP 触发而改变。
12. 战略方向与创新边界（Mission & Innovation）
Section titled “12. 战略方向与创新边界（Mission & Innovation）”Apodex 的创新空间在战略边界之内。公司每年由轮值主席 + CEO 确定战略方向，所有研究工作须在战略范围内开展；战略方向是必须执行的任务，不是可选项。在战略范围内，鼓励研究员充分发挥自主性，通过 Bonus IMP 奖励创新贡献。
12.1 战略方向机制
Section titled “12.1 战略方向机制”- 战略方向由公司确定： 每年由轮值主席 + CEO 指定 3–5 个战略方向，全员必须在此范围内开展工作；
- Mission Lead 负责制： 每个战略方向由一名 Mission Lead 负责，对方向目标达成承担主要责任；
- 战略范围内自由创新： 研究员在完成 Base 任务的前提下，可在战略方向内自由发起创新，产出经确认后获得 Bonus IMP；
- 战略外工作不被认可： 超出战略范围的工作不计入 IMP，不作为晋升依据。
12.2 Mission Lead 职责
Section titled “12.2 Mission Lead 职责”- 对战略方向的目标拆解、里程碑设定与最终交付负责；
- 负责协调方向内的资源分配与跨团队协作；
- 对方向内成员的 Base IMP 任务分配有建议权，由领域 Lead 最终确认；
- 方向内产出的 Bonus IMP 由 Mission Lead 联合领域 Lead 确认发放。
🎯 设计原则
战略是边界，不是天花板。公司定义”做什么方向”，研究员在方向内决定”怎么做得更好”。Bonus IMP 奖励的是在战略范围内的创新突破，而非游离于战略之外的自由探索。
13. 对外 Title 体系
Section titled “13. 对外 Title 体系”公司采用”内部 10 级精确分级、对外 4 层简化 Title”的双轨制设计。内部级别用于薪酬、IMP 积分与晋升管理；对外 Title 用于名片、LinkedIn 等外部场合，消除外部层级政治，同时保留顶端的区分度。
13.1 对外 Title 映射表
Section titled “13.1 对外 Title 映射表”| 对外 Title | 对应内部级别 | 说明 |
|---|---|---|
| Research Scientist | L1 – L5 | 含实习至独立研究阶段 |
| Staff Scientist | L6 – L8 | 具备跨模块技术影响力 |
| Principal Scientist | L9 | 公司级技术方向影响力 |
| Fellow | L10 | 最高荣誉，极少数人可达；对外与学术界 Fellow 含义对齐 |
13.2 设计原则
Section titled “13.2 设计原则”- 消除 Title 政治： 对外层级大幅压缩，避免”为什么他是 Principal Scientist 我是 Staff Scientist”的内部攀比；
- 保留顶端区分度： Fellow 作为独立 Title，是公认的最高荣誉，稀缺性本身即是信号；
- 尊重候选人外部身份： 对学术出身的候选人，允许在对外场合并列学术职位，例如：“Professor at [University] · Principal Scientist, Apodex”；
- Offer 阶段明确告知： 映射规则在 Offer Letter 中明确写明，不做暗箱操作。
💡 设计哲学
内部 10 级精确区分贡献与薪酬，对外 4 层避免层级政治。权威来自汇报关系和专业判断，而不是来自 Title。这与 OpenAI 等顶级 Frontier Lab 的核心精神一致。
14. 信息保密与公开机制
Section titled “14. 信息保密与公开机制”公司采用”自己完全透明、管理层完全透明、平级之间不公开”的信息架构。员工对自身信息拥有完整知情权，管理层对下属信息拥有完整知情权，但平级之间的薪酬与内部级别不作横向公开。
14.1 信息可见性矩阵
Section titled “14.1 信息可见性矩阵”| 信息类型 | 员工本人 | 直属上级 / 领域 Lead | 平级同事 | 对外 |
|---|---|---|---|---|
| 内部级别（L 几） | ✅ 完全知道 | ✅ 完全知道 | ❌ 不公开 | ❌ 不公开 |
| 职级内 Band | ✅ 完全知道 | ✅ 完全知道 | ❌ 不公开 | ❌ 不公开 |
| 薪酬区间与位置 | ✅ 完全知道 | ✅ 完全知道 | ❌ 不公开 | ❌ 不公开 |
| IMP 积分（本人） | ✅ 实时可见 | ✅ 完全知道 | ⚠️ 仅排行榜排名 | ❌ 不公开 |
| 晋升门槛差额 | ✅ 实时可见 | ✅ 完全知道 | ❌ 不公开 | ❌ 不公开 |
| 对外 Title | ✅ | ✅ | ✅ | ✅ |
| 汇报关系 / 组织架构 | ✅ | ✅ | ✅ | ❌ 不公开 |
14.2 Impact Leaderboard 的公开范围
Section titled “14.2 Impact Leaderboard 的公开范围”IMP 积分排行榜在公司内部公开，但仅展示排名与积分总量，不展示个人级别与薪酬信息。排行榜的目的是激励贡献竞争，而非制造薪酬攀比。
14.3 管理层的信息权限
Section titled “14.3 管理层的信息权限”领域 Lead 及以上管理层对其直接下属的全部信息（级别、Band、薪酬、IMP 明细）拥有完整知情权，这是履行管理职责的必要条件。管理层不得将下属的薪酬与级别信息横向透露给其他员工。
15. 基准评测体系（Benchmark Standards）
Section titled “15. 基准评测体系（Benchmark Standards）”IMP 积分体系中涉及”性能提升”的奖励条款，须以本章规定的基准评测集为衡量依据。除非领域 Lead 与轮值主席联合批准另行指定，否则所有版本的性能提升均以下列 Benchmark 为准。
📐 选取原则与两级结构
Apodex 的核心战场是 科学发现（Sci）、数学推理（Math）、软件工程（SWE）、深度研究（DeepResearch） 四大领域。Benchmark 体系分为两层：第一层（核心战场） 直接衡量这四大领域的前沿能力，是 IMP 奖励的主要依据；第二层（辅助指标） 覆盖搜索、长周期任务、预测、用户体验等维度，作为补充参考，不单独触发 IMP 奖励，但可作为版本综合评估的参考数据。
15.1 第一层：核心战场 Benchmark（Core Battleground）
Section titled “15.1 第一层：核心战场 Benchmark（Core Battleground）”每个版本复盘时，必须报告以下核心指标的变化。性能提升 IMP 奖励以此为准。按四大战场分组：
| 战场 | Benchmark | 测量维度 | 有效提升门槛 | 说明 |
|---|---|---|---|---|
| 🔬 Sci（科学发现） | FrontierSci-Research | 前沿科学研究能力 | 绝对分 ≥ 2pp | 直接测量模型在真实科研任务中的发现与推理能力，当前顶级模型得分约 25%，区分度高 |
| 🔬 Sci | HLE w/ tool (Humanity’s Last Exam) | 跨领域专家级推理（含工具调用） | 绝对分 ≥ 1pp | 2,500 道题，覆盖数学、科学、人文 50+ 领域；带工具版本更贴近真实科研场景；当前最高分约 58%，天花板足够高 |
| 🔬 Sci | SuperChem | 化学专项推理与合成规划 | 绝对分 ≥ 2pp | 专注化学领域深度推理，当前顶级模型约 63%，是 AI for Science 方向的核心探针 |
| 📐 Math（数学推理） | FrontierMath | 研究级数学问题（非竞赛） | 绝对分 ≥ 2pp | 由职业数学家出题，当前顶级模型约 47%；测量真实数学研究能力，无法靠竞赛技巧刷穿 |
| 📐 Math | IMO-Bench | 国际数学奥林匹克竞赛推理 | 绝对分 ≥ 2pp | 顶级数学竞赛题，需要 10–15 步严密推导链；当前顶级模型约 91%，仍具区分度；OpenAI o3、DeepSeek-R1 均以此为主指标 |
| 💻 SWE（软件工程） | SWE-Bench Verified | 真实 GitHub Issue 修复（代码工程） | 绝对分 ≥ 2pp | 500 道经人工验证的真实 GitHub Issue；当前顶级模型约 81%；直接测量端到端代码工程能力 |
| 💻 SWE | Internal SWE Bench（内部评测集） | Apodex 内部代码工程评测 | 绝对分 ≥ 2pp | 基于 Apodex 实际代码库构建，防污染；与 SWE-Bench Verified 互补，作为内部版本迭代的主要参考 |
| 🔍 DeepResearch（深度研究） | Internal DeepResearch Hard Eval（内部评测集） | 长链深度研究任务（多跳 + 综合推理） | 绝对分 ≥ 2pp | Apodex 内部构建的高难度深度研究评测集，防污染；直接对应产品核心能力，是 DeepResearch 方向的首要指标 |
| 🔍 DeepResearch | BrowseComp | 多跳网页检索推理 | 绝对分 ≥ 2pp | OpenAI 2025 年发布，1,266 道题；GPT-4o 仅 1.9%，Deep Research 约 89%，区分度极高；测多跳信息检索 + 推理合并，是深度研究引擎的核心能力探针 |
⚠️ 关于有效提升门槛
上述高难度 Benchmark 中，绝对分 1pp 以内的变化属于统计噪音，不计入有效提升。HLE w/ tool 须达到 ≥ 1pp；其余核心战场 Benchmark 须达到 ≥ 2pp，方可触发对应 IMP 奖励。
15.2 第二层：辅助参考 Benchmark（Supporting Indicators）
Section titled “15.2 第二层：辅助参考 Benchmark（Supporting Indicators）”以下指标作为版本综合评估的补充参考，不单独触发 IMP 奖励，但须在版本复盘报告中一并披露，用于全面评估模型能力边界。
| 类别 | Benchmark | 测量维度 | 参考意义 |
|---|---|---|---|
| 搜索能力 | Wide Search | 广域信息检索与整合 | 当前约 79%；测量模型在宽泛搜索场景下的信息整合能力，补充 BrowseComp 的深度检索视角 |
| 长周期任务 | GDPval-AA | 长周期自主任务完成率 | 当前约 16%，难度极高；测量模型在长时间跨度自主任务中的稳定性，是 Agentic 能力的长期观测指标 |
| 预测能力 | FutureX | 未来事件预测与推断 | 当前约 61%；测量模型对现实世界动态的推断能力，反映知识时效性与因果推理水平 |
| 用户体验 | IFBench | 指令遵循与格式控制 | 当前约 82%；测量模型对复杂指令的精确遵循能力，直接影响产品可用性与用户满意度 |
15.3 Benchmark 治理机制
Section titled “15.3 Benchmark 治理机制”🏛️ 分工原则：委员会定方向，Eval 团队执行落地
Benchmark 体系的战略方向与取舍由 Lead Committee（技术委员会） 负责决策，包括：哪些 Benchmark 纳入核心战场、哪些退出、Heavy Duty Solver 专用 Benchmark 的能力覆盖范围。Eval 团队 在委员会方向指导下，负责具体 Benchmark 的开发、维护、防污染管理与评测执行，与 Infra、Data 等部门地位平等，均在委员会指导下工作。
- 年度审查： 每自然年度开始前，由轮值主席召集 Lead Committee 对核心战场指标组进行审查，确认是否需要替换（如新 Benchmark 出现、现有指标饱和）；审查结论由委员会集体决策，Eval 团队提供技术评估建议；
- HDS 专用 Benchmark： Heavy Duty Solver 专用评测体系的能力层级与覆盖范围由委员会确定方向，Eval 团队负责题目设计、难度校准与动态更新；
- 版本锁定： 同一版本周期内，Benchmark 版本一经立项确认，不得中途更换，以保证前后对比的有效性；
- 特殊豁免： 若某版本的研究方向与核心战场指标组无关（如纯 Infra 优化、数据工程），可申请豁免，改用成本 / 延迟 / 稳定性等工程指标替代，须在立项时注明。
15.4 Infra & System Capability IMP（基础设施能力解锁）
Section titled “15.4 Infra & System Capability IMP（基础设施能力解锁）”基础设施与系统能力工作是模型研发的底层支撑，其贡献无法用 Benchmark pp 衡量，但对团队整体产出有乘数效应。自本版本起，Infra 类工作作为一等公民独立触发 IMP，不再仅作为辅助指标。
⚙️ Infra IMP 触发原则：能力解锁（Milestone-Based）
Infra 类 IMP 不以 pp 提升衡量，而以能力里程碑解锁为触发条件。每个里程碑须在立项时明确定义”完成标准”，复盘时由领域 Lead 与轮值主席联合确认是否达成。
| Infra 类别 | 典型里程碑示例 | Bonus IMP 参考 |
|---|---|---|
| 训练能力 | 新训练框架上线（支持新并行策略）；MFU 提升 ≥ 5%；支持新模型架构训练 | 15 – 30 |
| 推理能力 | 推理延迟降低 ≥ 20%；新推理引擎上线；支持新量化方案 | 10 – 25 |
| GPU 利用率 | 集群 GPU 利用率提升 ≥ 10pp；显著减少 OOM / 任务失败率 | 10 – 20 |
| 成本与效率 | 单位 token 成本降低 ≥ 15%；自动化 pipeline 上线（替代人工流程） | 10 – 20 |
| 可观测性 / 稳定性 | 实时评测系统上线；自动 logging / alerting 覆盖率达标；P99 延迟 SLA 达成 | 8 – 15 |
| 新能力解锁 | Apodex 首次具备某项业界已有能力（如多模态输入、长上下文扩展） | 20 – 40 |
⚠️ 与 Base IMP 的关系
Infra 日常维护任务（Logging 升级、数据流水线维护等）已通过 Base IMP（第 5.2 条）覆盖。本节 15.4 的 Infra IMP 属于 Bonus IMP，仅适用于达到里程碑级别的系统性能力提升，不与日常维护任务重复计算。
15.5 Capability 型 IMP 的评估口径
Section titled “15.5 Capability 型 IMP 的评估口径”对于不直接体现为 Benchmark pp 提升、但显著增强系统能力的工作，统一采用 Capability 型 IMP（Milestone-Based） 计分，评估标准以”能力是否被解锁并可复用”为主，而非 pp 提升。
典型适用场景包括：
- 新训练 / 推理能力上线（如新并行策略、新量化方案）；
- 实时评测系统、自动 pipeline、logging / alerting 覆盖率达标；
- 稳定性、可观测性、复现能力的系统性提升；
- 数据标注流水线、评测框架等被多个版本复用的基础能力。
上述工作的 IMP 分值参考 15.4 节里程碑表，由领域 Lead 与轮值主席在复盘中联合确认，须提供可追溯的完成证据（上线记录、性能对比、复用情况等）。
16. 附则
Section titled “16. 附则”本章程为 Apodex 正式发布版本。若无正式修订公告，不得对本版本进行口头或零散调整。“研究员职级与 Idea→版本 全流程管理”方面的正式发布版本，若无正式修订公告，不得对本版本进行口头或零散调整。
其他部门如需在本章程基础上制定更细化的实施细则（如特定子领域的积分加权规则），须经公司统一审核后备案。
本章程自发布之日起生效；生效前产生的历史贡献，可按本章程原则进行一次性折算，作为初始化 Leaderboard 记录与 Band 位置的依据。
如与国家法律法规或监管要求发生冲突，以法律法规为准，并由公司修订本章程相应条款。
本章程的任何修订必须形成修订公告，明确生效日期、变更摘要与追溯规则；对外发布文本为唯一有效版本。
Apodex 研究员公约（Researcher Charter）· APDX-RES-001 · Confidential