版本开发与创新实施制度
制度编号： APDX-VER-002 版本号： V1.4（发布流程重构：双轨协议（产品发布 + 模型开源）、灰度递进节奏（10%→50%→100%）、版本 Owner 权责统一） 生效日期： 2026 年 04 月 01 日 适用范围： Apodex 全体员工 定位： 规范公司从技术版本规划到具体 Idea 实施与上线的全过程管理。
第一章 总则
Section titled “第一章 总则”第一条（目的）
Section titled “第一条（目的）”为统一规范公司从技术版本规划到具体 Idea 的实施与上线的全过程管理，在保证迭代效率的前提下兼顾科研探索，特制定本制度。本制度在 V1.0 基础上，新增了对不同工作类型、不同 Idea 等级的区分，解决科研不可预测性、协作与 Ownership、集中审批与敏捷迭代等矛盾。
第二条（核心理念）
Section titled “第二条（核心理念）”- 版本是目标容器： 版本用于承载阶段性核心目标和对外承诺，按技术就绪程度与业务节奏灵活定义，不设固定周期。
- Idea 是实现手段： 不同等级的 Idea（探索 / 优化 / 核心）在版本框架下，以不同流程推进实验与上线。
- 快速迭代： 版本发布越快越好，以技术就绪为准，不人为设置发版间隔；双周 Sprint 承载日常迭代与小步试验。此处”快”指版本迭代节奏，不是模型推理响应速度——后者按技术宪章”正确性优先于速度”的原则，不作为一阶优化目标。
- 大方向一致，小单元灵活： 关键架构和模型行为通过版本统一规划；日常小改动和高风险探索通过轻量流程快速尝试。
第三条（适用边界）
Section titled “第三条（适用边界）”本制度主要适用于影响模型行为、算法效果、系统稳定性和成本的技术改动，包括但不限于：
- 模型结构与训练范式的改动；
- 推理框架与 Agent 框架的变更；
- 数据管线中影响模型行为的关键规则；
- 与安全、成本紧密相关的系统配置。
豁免说明
以下事项原则上不纳入本制度主流程，按各自 SOP 执行，仅在版本总结中做记录：纯产品需求（如「增加某个页面入口」）；小规模 bugfix、UI 微调；纯数据清洗、标签修正等不改变模型行为的基础工作；运维层面的服务部署与配置优化。
第四条（唯一权威）
Section titled “第四条（唯一权威）”本制度整合「Idea 管理」和「版本管理」相关内容，是公司技术创新管理在版本维度上的唯一权威制度。关于「Impact 计分」的规则与分配机制，以《Apodex 管理章程》（APDX-RES-001）为准。若与其他制度在流程执行上冲突，以本制度为准。
第二章 版本与 Idea 的关系
Section titled “第二章 版本与 Idea 的关系”第五条 版本定义
Section titled “第五条 版本定义”版本是公司根据业务需求和技术路线制定的阶段性目标集合。版本发布节奏以技术就绪程度为准，不设固定周期——能快则快，不人为拉长发版间隔。每个版本应明确：
- 版本名称、编号与时间窗口；
- 1–3 项核心指标目标（须从 APDX-RES-001 第 15 章核心 Benchmark 组中选取，如 AIME 提升区间、GAIA 成功率、LiveCodeBench Pass@1、成本下降等）；
- 版本 Owner 与主要参与团队；
- 预留 15–20% 资源给前沿探索目标（可不设硬性提点指标）。
版本目标经轮值技术主席审核、CEO 批准后在知识库公布，作为本周期所有 L2/L3 Idea 选择的版本挂载对象。
第六条 Idea 定义与分级
Section titled “第六条 Idea 定义与分级”Idea 是指对现有系统架构、算法、模型、工具链或流程的具体改进方案，用于：提升模型能力或可靠性；降低成本或复杂度；提高可观测性、安全性或可维护性。按性质与风险分为三级：
| 等级 | 名称 | 定义 | 典型场景 | 关联与上线要求 |
|---|---|---|---|---|
| L1 Exploratory | 探索性 Idea | 高失败率、小步快试；主要目标是验证方向可行性，而非直接上线 | 新 MidTrain/SFT/DPO/RL 训练策略；新检索方法、工具使用方式、Prompt 框架预研；小规模数据构造实验 | 必须关联版本：否，可选 必须上线：否，可仅形成结论与知识沉淀 |
| L2 Incremental | 优化性 Idea | 在已有方向上做可量化提升，或实现 Apodex 尚未具备但业界已有的方法；预期中等成功率，对线上行为有实质影响；在常规算力框架内可完成 | 当前推理框架下减少 steps、降成本；已有训练架构上做超参优化、数据配比调整；局部模块鲁棒性提升 | 必须关联版本：是（挂当期正式版本） 目标：有较明确的提点/降本目标，可合并上线 |
| L3 Major | 核心 Idea | 对架构、模型或大规模用户体验产生显著影响；对安全 / 合规 / 大客户交付有重要影响；可特批调用大规模算力资源 | 基座模型切换、推理框架重大升级；安全策略体系调整、成本结构大幅重构；任何需要重大资源倾斜的长期项目 | 必须关联版本：是，且需在版本目标中明确体现 决策：需 CEO / 轮值技术主席直接参与决策 |
第七条 版本与 Idea 的层级关系
Section titled “第七条 版本与 Idea 的层级关系”版本是顶层目标容器，用于约束范围、时间与核心指标。Idea 是版本下的执行单元，按等级采用不同流程：
- L1： 轻量记录 + 探索算力池 + 知识沉淀；
- L2： 标准「沙箱 → 轻量评审 → 小流量上线 → 观察期」；
- L3： 完整「版本规划 → 实验 → 多轮评审 → 分阶段上线」。
多个 Idea 可以在实验阶段合并评估，正式上线前可合版，但上线归因需记录到各 Idea。
第八条 关联要求
Section titled “第八条 关联要求”所有进入统一版本执行与上线渠道的 L2/L3 Idea，必须在创建时明确关联至至少一个已发布版本目标。
未关联版本的 L1 Idea：仅可使用探索算力池；不占用版本算力配额与上线窗口；成果必须在知识库中归档（包括失败结论）。
同一技术方向的多个 Idea 如高度重合，需由版本 Owner 组织讨论：决定是否合并为单一 Idea（多位 Co-Owner）；或作为并行路径做 A/B 实验。
第三章 角色与职责
Section titled “第三章 角色与职责”第九条 执行层
Section titled “第九条 执行层”执行层由公司工程师、研究员及其他技术人员构成，是 Idea 的主要实施主体，职责包括：
- 提出 Idea，按本制度完成 Idea 卡片填写，明确等级（L1/L2/L3）；
- 在沙箱或探索算力池中开展实验，记录 DAG / Step Graph 与指标数据；
- 准备实验报告，发起对应等级的评审及上线申请；
- 在小规模与正式上线阶段，监控指标与问题反馈，并负责复盘；
- 参与版本作战小组会议，配合版本 Owner 进行节奏协调和冲突解决。
协作角色说明
每个 Idea 卡片中需明确：
- Owner（唯一责任人）： 对结果与资源负责；
- Co-Owner（0–2 名）： 与 Owner 共同设计、共担技术责任；
- Contributors： 在数据、infra、工具等方面有关键贡献的同事。
任何人不得通过”抢先建卡”方式独占方向。版本 Owner 有责任组织同向合并与协作。
第十条 决策层
Section titled “第十条 决策层”决策层由 CEO、轮值技术主席及公司指定的资深技术顾问组成，职责包括：审批和发布版本目标；决策 L3 核心 Idea 是否纳入版本执行范围；对 L2 Idea 提供节奏与资源优先级指导；批准 L3 Idea 的关键阶段上线决策；在出现重大风险或争议时作最终裁决。
| Idea 等级 | 去中心化决策规则 |
|---|---|
| L1 | 决策权下放至直属 Leader 或指定资深技术顾问 |
| L2 | 由版本 Owner + 至少一名资深技术顾问决定，CEO / 轮值技术主席仅在冲突或资源争议时介入 |
| L3 | 必须由 CEO 或轮值技术主席审批 |
第十一条 版本 Owner
Section titled “第十一条 版本 Owner”由 CEO 或轮值技术主席指定，通常为对该技术方向最熟悉的资深工程师或负责人。
版本 Owner 对整个版本的发布质量与版本目标达成负最终责任，具体职责包括：
- 拟定版本目标与范围，提交决策层审批；
- 将版本目标拆解为里程碑与关键指标；
- 组织版本作战小组，协调各 Idea 的优先级与依赖关系；
- 跟踪版本整体进度和指标完成度；
- 协调 Idea 冲突、合并、多路径探索；
- 执行版本发布 Release Gate Checklist，对发布节奏拥有一票否决权；
- 向市场 / PR 团队发出书面宣发授权，确认线上发布与评测发布均已完成；
- 版本发布完成后 5 个工作日内提交发布复盘报告。
权责说明
版本 Owner 即本制度中所有发布环节的唯一责任人，不另设 Release Owner 角色。版本 Owner 的发布暂停决定无需额外审批，但须在 2 小时内向 CEO / 轮值技术主席同步情况。
第十二条 CEO 职责
Section titled “第十二条 CEO 职责”对本制度的解释与最终裁决负责。对以下事项有最终决策权：版本目标与资源分配；L3 核心 Idea 的纳入与上线；涉及重大风险/品牌/合规问题的争议。
第四章 核心流程
Section titled “第四章 核心流程”（版本规划 → Idea 实现 → 集成上线）
第一节 版本规划与 Idea 立项
Section titled “第一节 版本规划与 Idea 立项”第十三条 版本目标设定
Section titled “第十三条 版本目标设定”版本 Owner 在版本周期开始前，基于战略与路线图提出版本目标方案，至少包括：
- 版本名称、编号与时间窗口；
- 核心技术与业务指标及目标区间；
- 主要系统模块与约束边界；
- 为 L3 核心 Idea 及探索性工作预留资源比例（如正式版本算力的 15–20% 保留给探索类工作）。
版本目标经轮值技术主席审核、CEO 批准后在内部知识库公布。同时公布本版本周期内的双周 Sprint 时间表，用于承载 L1/L2 Idea 的实施与交付。
第十四条 Idea 卡片创建
Section titled “第十四条 Idea 卡片创建”任何员工均可在版本周期内发起 Idea。Idea 发起人必须在统一系统中创建 Idea 卡片，内容至少包括：Idea 标题与简述；Idea 等级（L1/L2/L3）；所属版本（必填：L2/L3；选填：L1）；问题描述与背景；改进假设与主要技术思路；目标指标与期望提升/改进方向；预估资源需求；Owner、Co-Owner 与主要 Contributors。
L1 Idea 经直属 Leader 或资深技术顾问确认即可进入探索算力池。L2/L3 Idea 经系统基本校验后进入版本候选池，由版本 Owner 安排评审与资源。
第二节 沙箱实验与科学验证
Section titled “第二节 沙箱实验与科学验证”第十五条 沙箱环境规范
Section titled “第十五条 沙箱环境规范”所有 L2/L3 Idea 必须优先在沙箱环境中进行验证。沙箱环境定义为：
- 与生产隔离的代码分支、配置、模型权重；
- 绑定明确的数据版本和内部 benchmark 子集；
- 可以是虚拟环境，也可以是专用测试集群。
L1 Idea 可在沙箱或探索算力池中进行，资源与隔离要求可适当放宽，但必须保证不会影响生产环境。
概念澄清与技术要求
沙箱环境（Sandbox） 是指隔离的技术测试环境；探索算力池（Exploratory Compute Pool） 是指为 L1 探索性工作预留的算力资源配额（预算）。两者概念不同，L1 Idea 可使用探索算力池的配额，在沙箱或个人开发环境中进行。
实验过程必须采用
DAG / Step Graph方式组织，记录：step_id、parent_step_id、branch_id、state_hash等，以保证可追踪与可复现。
第十六条 指标与成本记录
Section titled “第十六条 指标与成本记录”L2/L3 Idea 的沙箱实验必须至少在一个标准指标集上进行评估。评测指标须优先采用 APDX-RES-001 第 15 章规定的核心 Benchmark 组（FrontierSci-Research、HLE w/ tool、SuperChem、FrontierMath、IMO-Bench、SWE-Bench Verified、Internal SWE Bench、BrowseComp、Internal DeepResearch Hard Eval）；
- 若版本方向为 Infra / 系统能力类，须改用 APDX-RES-001 第 15.4 条规定的工程指标（训练效率 / GPU 利用率 / 推理延迟 / 成本 / 新能力里程碑等），不得以”无对应 Benchmark”为由免于评估；
- 若版本方向为数据工程类，可按第 15 章豁免条款改用工程指标（长链任务成功率、平均步骤数、单位任务成本等）。
实验期间需记录资源消耗，用于后续成本评估与 ROI 分析。
L1 Idea 至少需记录：实验配置；关键信号（成功/失败/不确定）；对后续工作的影响建议。
第十七条 实验报告与通过标准
Section titled “第十七条 实验报告与通过标准”实验结束后，Idea Owner 须提交简要实验报告，至少包括：实验环境与版本说明；主要改动点与影响范围；实验前后关键指标对比；成本与潜在风险说明。
| Idea 等级 | 量化通过标准 / 报告重点 |
|---|---|
| L2 | 至少满足以下任一条件： 1. APDX-RES-001 核心 Benchmark 组中任一指标达到有效提升门槛（AIME/GPQA Diamond/GAIA/BrowseComp ≥ 2pp；HLE/LiveCodeBench ≥ 1pp） 2. 平均步骤数降低 ≥ 3% 3. 单位任务成本降低 ≥ 5% |
| L3 | 在 L2 基础上，额外考虑： 1. 对安全性、合规性、系统复杂度的影响 2. 对未来版本可扩展性的贡献 |
| L1 | 不强制量化提点。报告重点：假设是什么；试验结果对假设的支持/否证；是否建议升级为 L2/L3；对后续团队的经验教训 |
注：如 L2/L3 Idea 未达到量化标准，但在安全性、稳定性、可观测性或长期架构价值上具有显著意义，允许”低提点高价值”Idea 特批通过。
第三节 评审与纳入版本执行
Section titled “第三节 评审与纳入版本执行”第十八条 评审流程（分级）
Section titled “第十八条 评审流程（分级）”- L1 Idea： 审批人：直属 Leader 或指定资深技术顾问；关注点：方向是否合理、资源是否合规；不要求 CEO / 轮值技术主席介入。
- L2 Idea： 评审组合：版本 Owner + 至少一名资深技术顾问；关注点：技术正确性、架构一致性、与版本目标匹配度、资源优先级。
- L3 Idea： 评审组合：至少一名资深技术顾问 + CEO 或轮值技术主席；关注点：战略匹配度、资源投入产出、风险与回滚方案。
第十九条 决策规则
Section titled “第十九条 决策规则”- L1 Idea： 由直属 Leader 或指定资深技术顾问直接决策通过。
- L2 Idea： 默认通过机制。自提交完整实验报告起，如 2 个工作日内版本 Owner 和资深技术顾问无明确反对意见，即可视为通过，进入小流量上线阶段。
- L3 Idea： 必须经 CEO 或轮值技术主席明确批准后，方可进入小规模上线阶段。
第四节 小规模上线与版本集成
Section titled “第四节 小规模上线与版本集成”第二十条 小规模上线与灰度递进
Section titled “第二十条 小规模上线与灰度递进”通过评审的 L2/L3 Idea，须按以下灰度递进节奏逐步扩量，不得跳过阶段直接全量上线：
| 阶段 | 流量比例 | 观察时长 | 进入下一阶段条件 |
|---|---|---|---|
| 沙箱验证 | 0%（隔离环境） | 按实验报告要求 | 通过 Release Gate Checklist |
| 小流量 | ≤ 10% | ≥ 48 小时 | 核心指标无劣化；错误率、超时率在基线 ±10% 以内 |
| 中流量 | ≤ 50% | ≥ 48 小时 | 同上；成本指标在预估范围内 |
| 全量 | 100% | 进入正式观察期 | 版本 Owner 确认，高风险改动须 CEO / 轮值技术主席审批 |
必须配置并持续监控：效果类指标（Pass@1、成功率、用户行为信号）；稳定性指标（错误率、超时率等）；成本指标（平均 token 数、GPU 使用时长等）。对多个 Idea 合版上线的情况，版本 Owner 需维护合版清单与开关策略，以便出现问题时可以按 Idea 粒度回滚。
第二十一条 回滚与观察期
Section titled “第二十一条 回滚与观察期”⚠️ 回滚红线触发条件
小规模上线前须明确回滚触发条件，一旦触发以下条件，应立即回滚，并由 Idea Owner 在 24 小时内完成复盘记录：
- 核心指标相对基线劣化超过预设阈值（如 5–10%）；
- 错误率或超时率显著恶化（如翻倍）；
- 触发安全 / 成本红线。
正式上线后设置观察期：高风险改动 ≥ 2 周；一般改动 ≥ 1 周；小幅低风险改动 ≥ 3–5 天。观察期内若出现重大异常，按回滚策略执行，并更新版本/Idea 总结。
第二十二条 多个 Idea 的版本整合
Section titled “第二十二条 多个 Idea 的版本整合”同一版本中的多个 Idea，可在不同时间完成上述流程，在版本窗口内逐步合并交付。版本 Owner 负责：
- 协调各 Idea 上线顺序与依赖关系；
- 整体指标的综合影响评估；
- 必要时对部分 Idea 延后上线或取消。
版本交付时，以「版本内所有已正式生效 Idea 的整体效果」作为版本目标达成度主要依据，同时在 Impact Leaderboard 中按 Idea 归因。
第五节 双轨协议
Section titled “第五节 双轨协议”目的： 确保模型能力、线上服务、评测数据与对外宣传在同一时间节点保持一致，防止”宣发先行、上线滞后”的错位风险。
第二十三条 发布阶段定义（双轨协议）
Section titled “第二十三条 发布阶段定义（双轨协议）”Apodex 的对外发布分为两条独立轨道，可并行推进，互不阻塞：
- 产品发布轨道（Product Track）：面向终端用户的线上服务发布，强调稳定性与用户体验，须严格遵循灰度递进与 Release Gate Checklist；
- 模型开源轨道（Open Source Track）：面向研究社区的模型权重与技术报告发布，强调时效性与学术影响力，可在产品发布轨道完成前独立启动。
双轨独立原则
模型开源发布（Open Source Track）不依赖产品线上发布的完成状态，可在内部模型发布（阶段 0）完成后独立启动。产品发布轨道的五阶段协议仍须完整执行，两者互不替代。
产品发布轨道（Product Track）—— 五阶段协议
Section titled “产品发布轨道（Product Track）—— 五阶段协议”产品发布轨道必须严格遵循以下五个阶段，各阶段之间存在强依赖关系，不得跳过或倒序执行：
阶段 0 · 模型发布（Model Release）—— 内部阶段 / 双轨共同起点
- 定义：模型权重训练完成，通过内部基础质量检验，可供内部测试与评测使用。此阶段是产品发布轨道与模型开源轨道的共同前置条件。
- 状态：仅限内部访问，不对外宣传；
- 产出物：模型权重文件、内部版本号、基础质量报告；
- 负责人：算法 / 训练团队 Owner。
阶段 1 · 线上发布（Online Release）—— 唯一”产品已发布”节点 ⭐
- 定义：生产服务已完成模型切换，真实用户流量已路由至新版本模型。
⚠️ 核心原则
只有完成线上发布，才可对外声称”已发布”或”已上线”。 任何在线上发布完成前发出的对外宣传，均视为违规宣发。
- 状态：生产流量 100% 切换（或按灰度计划完成目标比例）；
- 产出物：生产切换记录、流量监控截图、服务健康报告；
- 负责人：Release Owner（见第二十五条）。
阶段 2 · App 上架发布（App Store Release）—— 客户端同步
- 定义：移动端 / 桌面端客户端新版本已提交各应用商店审核并完成上架，用户可通过 App Store / Google Play 等渠道获取新版本。
说明
App 上架与线上服务发布应尽量同步推进，但受应用商店审核周期影响，允许在线上发布（阶段 1）完成后的合理窗口期内完成上架。宣发发布（阶段 4）必须等待 App 上架完成后方可启动。
- 前置条件：线上发布（阶段 1）已完成；
- 产出物：各平台上架截图、版本号记录、应用商店审核通过凭证；
- 负责人：客户端 / 产品团队，版本 Owner 确认。
阶段 3 · 评测发布（Evaluation Release）—— 数据就绪
- 定义：新版本在全套核心 Benchmark 上的评测数据已完成，结果经过内部审核，可对外公开。
- 前置条件：线上发布（阶段 1）已完成；
- 产出物：6 项核心 Benchmark 完整评测报告（AIME、GPQA、HLE、LiveCodeBench、GAIA、BrowseComp）；
- 负责人：评测团队，版本 Owner 联合确认。
阶段 4 · 宣发发布（Marketing Release）—— 最后阶段
- 定义：面向外部用户、媒体、合作伙伴的公开宣传与推广活动正式启动。
⚠️ 强制前置条件
宣发发布必须在以下三个条件同时满足后方可启动：
- ✅ 线上发布（阶段 1）已完成，Release Gate Checklist 全部通过；
- ✅ App 上架发布（阶段 2）已完成，各平台客户端已可下载；
- ✅ 评测发布（阶段 3）已完成，评测数据已就绪。
- 产出物：对外公告、博客、社交媒体内容、媒体沟通材料；
- 负责人：市场 / PR 团队，须获得版本 Owner 书面确认后方可发布。
模型开源轨道（Open Source Track）—— 独立并行路径
Section titled “模型开源轨道（Open Source Track）—— 独立并行路径”模型开源轨道面向研究社区，目标是在模型权重就绪后以最快速度建立技术影响力。此轨道独立于产品发布轨道，可在内部模型发布（阶段 0）完成后由算法团队 Owner 自主启动，无需等待产品线上发布完成。
OS-1 · 模型权重发布（Weight Release）—— HuggingFace / GitHub
- 定义：将模型权重、推理代码、基础使用文档发布至 HuggingFace Hub 或 GitHub，供研究社区下载与复现。
- 前置条件：内部模型发布（阶段 0）已完成；
- 产出物：HuggingFace 模型卡片、GitHub 仓库（含推理代码与 README）、License 文件；
- 负责人：算法团队 Owner，须获得 CEO 或轮值技术主席书面授权后方可发布；
- 时效目标：内部模型发布完成后 72 小时内完成开源发布（如有竞争窗口压力，可申请加急）。
OS-2 · 技术报告发布（Technical Report）—— 可选
- 定义：发布详细的技术报告（arXiv 或官方博客），描述模型架构、训练方法、评测结果与局限性。
- 前置条件：模型权重发布（OS-1）已完成；
- 产出物：技术报告 PDF（arXiv 预印本或官方博客文章）；
- 负责人：算法团队 Owner + 市场 / PR 团队联合确认；
- 说明：技术报告可与模型权重同步发布，也可在权重发布后独立发布，不受产品发布轨道约束。
开源轨道与产品轨道的宣发边界
模型开源发布（OS-1/OS-2）可在社区渠道（HuggingFace、GitHub、arXiv、技术博客）进行技术层面的宣传，但不得声称产品已上线或用户可直接使用。面向终端用户的产品宣发（如 App Store 推广、社交媒体广告）仍须等待产品发布轨道的宣发发布（阶段 4）完成后方可启动。
第二十四条 Release Gate Checklist（上线审批清单）
Section titled “第二十四条 Release Gate Checklist（上线审批清单）”在执行线上发布（阶段 1）前，版本 Owner 必须逐项确认以下 Checklist，全部通过后方可切换生产流量：
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 模型质量 | 内部核心 Benchmark 评测完成 | 相比上一版本无显著回退（核心指标劣化 < 2%） |
| 产品逻辑 | 关键用户场景端到端测试通过 | P0 / P1 级 Bug 清零；无已知严重回退 |
| 服务稳定性 | 预生产环境压测 / 灰度观察期完成 | 错误率、超时率、P99 延迟均在基线 ±10% 以内 |
| 资源保障 | GPU / 算力资源已就位，QPS 容量满足预期 | 峰值 QPS 容量 ≥ 预估需求 × 1.5 倍 |
| 回滚方案 | 回滚脚本已测试，回滚触发条件已明确 | 回滚演练通过；触发条件文档已更新 |
| 宣发对齐 | 市场 / PR 团队已知晓上线时间，宣发材料已准备但尚未发出 | 宣发材料已 Review，确认在线上发布完成后方可发出 |
| 安全合规 | 安全策略 Policy-as-Code 检查通过 | 无高危安全违规；合规审查已完成 |
| Eval 独立评测 | Eval 部门《进化真实性报告》已出具并经 CEO 签字 | 报告结论为”通过”；CEO 签字确认；此项为独立硬门槛，版本 Owner 无权绕过（见 APDX-RES-001 第 4.5 条） |
⚠️ 一票否决原则
上述任意一项未通过，版本 Owner 有权且有责任暂停线上发布，并同步通知市场 / PR 团队暂停宣发准备。版本 Owner 的暂停决定不需要额外审批，但须在 2 小时内向 CEO / 轮值技术主席同步情况。
第二十五条 版本 Owner 发布权责
Section titled “第二十五条 版本 Owner 发布权责”版本 Owner 是本制度中唯一的发布责任人，对整个版本的发布质量与版本目标达成负最终责任。本制度不另设 Release Owner 角色，所有发布相关权责统一归属版本 Owner。
| 权责 | 说明 |
|---|---|
| 统一协调 | 协调算法、工程、产品、客户端、市场 / PR 各团队，确保五阶段发布按序推进 |
| Checklist 执行 | 在线上发布前逐项确认 Release Gate Checklist，并留存书面记录 |
| 宣发授权 | 向市场 / PR 团队发出书面”宣发授权”，确认线上发布（阶段 1）、App 上架发布（阶段 2）与评测发布（阶段 3）均已完成 |
| 一票否决 | 在任意 Checklist 项未通过时，有权暂停发布流程，无需额外审批；须在 2 小时内向 CEO / 轮值技术主席同步 |
| 质量兜底 | 对版本上线后的用户体验质量、指标达成与稳定性负最终责任；出现重大问题时，版本 Owner 是第一责任人 |
| 事后复盘 | 版本发布完成后 5 个工作日内，提交发布复盘报告，记录各阶段时间节点、问题与改进措施 |
第二十六条 违规宣发处理
Section titled “第二十六条 违规宣发处理”若市场 / PR 团队在未获得版本 Owner 书面授权的情况下发出对外宣传，视为违规宣发，处理流程如下：
- 立即处置： 版本 Owner 有权要求立即撤回或暂停宣发内容；
- 责任认定： 由 CEO 办公室在 24 小时内完成责任认定；
- 记录留存： 违规事件记录在版本复盘报告中，作为后续流程改进依据；
- 制度修订： 如因违规宣发造成用户体验损害或品牌风险，触发本制度紧急修订流程。
第五章 关键管控与激励机制
Section titled “第五章 关键管控与激励机制”第二十七条 Impact Leaderboard
Section titled “第二十七条 Impact Leaderboard”公司设立 Impact Leaderboard，记录和量化个人与团队在系统层面的真实贡献。计分拆分为四条赛道：算法提点赛道、数据与基础设施赛道、探索贡献赛道、系统协作赛道。
计分分配机制
统一采用《APDX-RES-001》规定的贡献系数（wᵢ）机制。由 Version Owner 在 Kickoff 阶段设定初始 wᵢ，复盘时联合领域 Head 最终确认。不再采用固定的 Owner/Co-Owner 比例分配。
| 贡献类型 | 基础计分建议（严格对齐 APDX-RES-001） |
|---|---|
| 算法提点 | APDX-RES-001 核心 Benchmark 组中任一指标每达到一个有效提升门槛（≥ 2pp 或 ≥ 1pp，视具体 Benchmark），记 5 分 |
| 成本优化 | 单位任务成本每降低 5%，记 3 分 |
| 稳定性提升 | 长链稳定性每提升 5%，记 1 分 |
| 基础设施 | 关键基础设施能力在多个版本被反复复用，可按版本累计计分 |
| L1 探索 | 验证某高风险假设 → 成功 1 分 / 失败 0.3 分 |
注：Leaderboard 数据自动生成与更新，除纠错与违规处理外不得手动修改。
第二十八条 版本作战小组
Section titled “第二十八条 版本作战小组”每个版本必须设立版本作战小组，由版本 Owner 牵头，成员至少包括：算法代表、产品/应用代表、数据/infra 代表、安全/合规代表。职责：
- 协调各 Idea 优先级与资源分配；
- 每双周复盘版本进展与指标；
- 处理 Idea 冲突、合版、回滚等决策；
- 组织版本总结与经验沉淀。
第二十九条 算力使用原则
Section titled “第二十九条 算力使用原则”所有算力使用情况均需记录在实验报告及版本总结中，作为后续资源规划与复盘依据。小组内算力由小组与 Version Owner 自主分配；机动大队列算力须提交申请，经技术委员会审批后统一排期。
第六章 算力资源申请与分配
Section titled “第六章 算力资源申请与分配”第三十条 基本原则
Section titled “第三十条 基本原则”Apodex 的算力资源属于公司公共资产，采用**「专有保障 + 全局共享 + 分级治理」**的统一调度机制，任何个人或小组不得长期独占。资源使用遵循以下原则：
- 专有优先： 各小组优先使用本组专有队列资源；
- 弹性共享： 专有资源不足时方可申请机动大队列；
- 公开透明： 算力申请、审批结果及使用情况团队内可见，并与 Idea 对应；
- 优先级调度： 统一纳入 P0–P3 体系，调度以优先级为主、配额为辅；
- 合规审计： 所有任务须明确项目归属、用途及负责人，确保成本可追踪。
第三十一条 申请流程
Section titled “第三十一条 申请流程”算力申请按资源规模分三级处理：
- 专有队列（Dedicated Queue）： 平台按小组分配固定 GPU 资源并设置独立队列，具体配额由技术委员会讨论后在统一平台公布；专有队列内任务由小组自行管理与调度，原则上无需额外审批，但须保证组内信息透明。
- 机动大队列（Elastic / Shared Queue）： 当专有资源不足时须提交算力申请单，包含：实验目标、预估算力、负责人、计划周期；审批结果在团队内公开公示。
- 特大型任务（Critical / Foundation Run）： 满足任一条件（消耗超过公告阈值（如 15,360 GPU·h）、需预留大规模资源、关键对外里程碑）须提交 Proposal，至少包含：目标与成功标准、资源消耗与窗口、风险与回滚、数据合规、复现与归档、对外影响评估；由技术委员会 + 业务负责人联合评审，通过后统一排期执行。
| 类型 | 审批方式 | 时限 |
|---|---|---|
| 专有队列内任务 | 小组自主调度，无需审批 | 即时 |
| 机动大队列申请 | 领域 Lead 审批 + 全团队公示 | 48 小时内 |
| 特大型任务（Critical Run） | 技术委员会 + 业务负责人联合评审 | 5 个工作日内 |
第三十二条 任务认领机制
Section titled “第三十二条 任务认领机制”每个版本周期启动时，Version Owner 须在 D3 前公开发布本版本所有子任务清单，注明任务描述、所需职级门槛、预分配算力上限。所有达到职级门槛的 IC 均可申请认领，不得以非制度理由拒绝合格申请者。
第三十三条 竞争申请仲裁
Section titled “第三十三条 竞争申请仲裁”同一任务有多名 IC 申请时，按以下顺序依次判断，满足前一条即停止：
- 职级匹配度：优先选择与任务所需职级最接近的申请者，避免高职级抢占基础任务或低职级承接超出能力的任务；
- 历史参与度：近两个版本周期内，该方向 IMP 积分较低者优先——让贡献少的人先得到机会，避免强者恒强；
- Lead 裁量：前两条无法区分时，由领域 Lead 综合判断，裁量理由须书面记录在任务分配日志中，纳入透明度审计；
- 协作拆分：任务体量允许时，Lead 可将任务拆分为多个子任务，由多名申请者协作完成，各自计入 IMP。
申请者对分配结果有异议，可在 3 个工作日内向 Lead Committee 提出复议，Lead Committee 须在 5 个工作日内给出书面答复。
第三十四条 防垄断条款
Section titled “第三十四条 防垄断条款”- 单人/单小组持有的活跃算力配额，不得超过团队总配额的 30%；
- 连续两个版本周期独占核心任务的情况，须经 Lead Committee 审查；
- 领域 Lead 的任务分配记录纳入季度透明度审计。
第三十五条 机动大队列（Flexible / Elastic Queue）违规处理
Section titled “第三十五条 机动大队列（Flexible / Elastic Queue）违规处理”为防止共享算力资源被滥用，机动大队列实行以下违规认定与处罚机制：
| 违规类型 | 认定标准 | 处置措施 |
|---|---|---|
| 任务超时未释放 | 申请时长内未完成，且未提前申请延期 | 系统自动 Kill 任务；当次配额作废；须补交说明报告 |
| 未经 Vote 擅用 Flexible 资源 | 未提交申请单或未获审批即占用机动大队列 | 任务立即终止；记录违规一次；第二次起暂停该成员 Flexible 队列申请权 30 天 |
| 任务未关联 Idea 文档 | 提交任务时未填写对应 Idea 编号或任务目标 | 任务进入挂起状态，48 小时内补充信息后恢复；逾期自动取消 |
| GPU 利用率持续低下 | 连续 4 小时平均 GPU 利用率 < 30%（系统自动监控） | 系统发出警告；12 小时内未改善则自动 Kill；当次配额不予退还 |
| 未按时提交复盘报告 | 任务结束后 3 个工作日内未提交实验复盘报告 | 下次 Flexible 申请被冻结，直至补交报告；累计 2 次起，申请优先级降级 |
| 资源滥用（严重） | 伪造 Idea 文档、虚报实验目标、或将资源用于非版本相关任务 | 立即终止所有在途任务；暂停 Flexible 配额 90 天；上报 Lead Committee 处理；情节严重者触发 APDX-RES-001 纪律条款 |
申诉机制
被处罚成员可在处罚生效后 3 个工作日内向 Lead Committee 提出书面申诉，Lead Committee 须在 5 个工作日内给出书面答复。申诉期间处罚措施照常执行，申诉成功后予以撤销并恢复配额。
⚠️ 自动化执行原则
超时 Kill、低利用率警告等技术性处置由系统自动执行，无需人工审批。行政性处罚（暂停配额、优先级降级）由算力管理员在系统记录基础上执行，并在团队内公示。
第七章 与其它制度的衔接
Section titled “第七章 与其它制度的衔接”第三十六条 与安全制度（SOP-01）的关系
Section titled “第三十六条 与安全制度（SOP-01）的关系”本制度下所有实验与上线须遵守安全制度。沙箱阶段：默认以 Policy-as-Code Dry Run 方式运行，提示潜在违规。生产环境必须严格执行 Policy-as-Code，违规改动不得上线。
第三十七条 与知识与实验管理制度（SOP-03）的关系
Section titled “第三十七条 与知识与实验管理制度（SOP-03）的关系”Idea 实验数据、DAG trace、报告及版本总结应按 SOP-03 要求归档。L1 探索性 Idea 的失败经验必须在知识库中形成可检索条目，避免重复试错。
第三十八条 与 Apodex 研究员公约（APDX-RES-001）的关系
Section titled “第三十八条 与 Apodex 研究员公约（APDX-RES-001）的关系”本制度与《Apodex 管理章程》（APDX-RES-001）共同构成公司技术创新管理的制度体系，两者分工如下：
- APDX-RES-001（管理章程） 是公司研究员职级、Impact 计分规则、Benchmark 标准与激励分配的最高权威文件；
- 本制度（APDX-VER-002） 是版本规划、Idea 实施流程与发布管控的执行规范；
- 两者在 Impact Leaderboard 计分与版本归因上保持一致，以 APDX-RES-001 的规则为准；
- 如本制度与 APDX-RES-001 在激励分配、职级认定等事项上存在冲突，以 APDX-RES-001 为准；如在版本流程执行上存在冲突，以本制度为准。
第八章 附则
Section titled “第八章 附则”第三十九条 修订权
Section titled “第三十九条 修订权”本制度由 CEO 办公室负责解释与修订，根据公司发展与实践反馈每 3–6 个月评估一次是否需要更新版本号。
第四十条 生效
Section titled “第四十条 生效”本制度自 2026 年 04 月 01 日起执行；原涉及 Idea → 上线与版本管理的相关制度文本如与本制度不一致，以本制度为准。