模态集团全公司 SOP 手册

v0.1（2026-10-21） · 655 条

一页纸摘要

目标：用 SOP 消灭“同步混乱”和“反复追问”。判定标准只有三条：每件事有唯一入口、每次交接有单据、每个结论有记录。群聊只是通道，不是入口、不是存档、不是决策记录。

公司级 5 个核心断点（来自全年复盘，只针对流程）

  1. 入口多路：需求、客户问题、资源/账号、报修从群 @、私聊、口头、微信多路进入，受理方反复追问“哪个/什么时候/要什么”。
  2. 交接无单据：合同→交付→开票、评审→研发→测试→发布、Offer→入职各段靠口头或群消息，下游“不知道要接”，验收无标准。
  3. 决策与规则无留痕：方向、口径、优先级在群聊边聊边定，反复重开、改口；“讲过两遍”与“从没听说”并存；规则不进制度库就要求执行。
  4. 门禁缺失：无发布单、无生产变更申请、合同先签后审、资金与额度口头决定，事故后才补流程。
  5. 单点与越级：关键节点依赖一两人，卡点终点全部汇到高管，被授权人不知道自己可以决定。

Top 10 优先 SOP（编号｜一句话理由）

# SOP 理由
1 X-PRD-05 需求唯一入口；不进需求池不排期，直接切断“绕过产品找研发”
2 X-CS-05 客户问题唯一入口与首响时限；反馈闭环率是客户最直接感受
3 LEG-03 合同多方会签；已盖章合同是交付工单的前置条件
4 X-DLV-07 交付订单受理即建群派工；替代“口头要货、多表散落”
5 RND-51 发布单与放行结论；发版后通知下游，消除“版本变了没人知道”
6 RND-58 生产变更申请（备份/灰度/回滚）；杜绝在生产上做测试
7 X-SEC-10 群内禁发凭据 + 密码库；几乎每个工作群都出现过明文密码
8 X-SEC-14 AI 工具订阅统一申请；终结个人自购、垫付、各自申诉封号
9 FIN-29 计费异常与退补走审批；资金类动作 100% 留痕
10 CEO-05 授权矩阵；让被授权人知道自己能拍板，越级事项退回原路径

两周内必须落地：3 个统一入口 + 3 个门禁

类别 项目 承接 SOP 系统建设项 牵头
入口 1 需求与客户问题统一入口（表单 + 需求池 + 问题工单） X-PRD-05、X-PRD-09、X-CS-05 SYS-01、SYS-02 产品负责人（待指定）+ 售后临时负责人（待指定）
入口 2 资源/账号/AI 工具统一申请入口（审批 + 资源台账） ADM-34、X-SEC-01、X-SEC-14、X-SEC-16、RND-27 SYS-08 IT/安全负责人（待指定）+ 财务（黄梦婷）
入口 3 交付工单入口（订单看板 + 自动建群） X-DLV-07、SAL-31、X-DLV-35 SYS-24（先用多维表格） 交付负责人（待指定）+ 销售（许君、李鹏为）
门禁 1 合同多方会签与用印审批 LEG-03、LEG-09、SAL-23 SYS-03 法务（李瑶）
门禁 2 发布单与生产变更申请 RND-50、RND-51、RND-54、RND-58 SYS-06 研发（丁震宇）
门禁 3 资金/额度类审批（赠送额度、充值、退补、卡密） FIN-16、OPS-07、FIN-29、OPS-10 SYS-04 财务（黄梦婷）

里程碑（10/28 为周三；优化期 10/29～11/11，共 10 个工作日）

日期 谁 交付什么
10/28（三） 13 位部门报送人 本部门 SOP 首轮报送：每条有 Owner、B 角、入口、留痕位置；综合部（赵雪冰）当日汇总进 SOP 总目录 v1.0
10/29（四） 总经办（田杰） 启动会：发布本总纲与 ALL-01～ALL-11；宣布“优化期内新规则只以 SOP 形式发布”
10/30（五） 总经办 + CEO 裁决 X- 归属与缺位职能临时负责人；确定 P0 清单（约 50 条）；发布《请求入口表》v1.0（ALL-01）
11/2～11/4 六个牵头人 3 入口 + 3 门禁上线，各用 1 个真实事项走通；群公告置顶入口链接（ALL-07）
11/4（三） 总经办主持 跨部门评审会：按 F1～F8 过交接点，产出《跨部门交接定义表》v1.0（ALL-04）；冲突当场拍板并记决策记录（ALL-03）
11/5～11/6 各 SOP Owner P0 SOP 试运行：每条主线 ≥ 3 个真实事项，记录卡点与绕行；IT/安全完成群内禁发凭据公告与密码库开通
11/9（一） 总经办 + 研发自动化负责人 发布授权矩阵与 AB 角清单；至少 5 个自动提醒上线（超时、到期、余额、缺报、发版）；看板目录 v1.0（ALL-09）
11/10（二） 各 SOP Owner 按试运行修订，定稿 v1.1；删除无人执行的步骤
11/11（三） 总经办主持，部门负责人互评 验收会：每位 Owner 用 5 分钟演示 1 条 SOP 的真实执行留痕；通过即发布宣贯，未通过列整改期限

作战总纲：用 SOP 运转公司

以下规则对全员生效，每条都可以被检查。规则编号 R-xx；“查”表示怎么检查。

一、单一事实来源：信息只能放在一个地方

  • R-01 每类工作信息只有一个主表，位置以《单一数据源清单》为准（ALL-08）：客户与商机→CRM（SAL-04）；合同→合同台账（LEG-11）；订单与交付→交付订单看板（X-DLV-07/X-DLV-35）；已交付实例→实例台账（X-DLV-31）；需求→需求池（X-PRD-09）；缺陷与任务→工单系统（RND-11）；版本与更新日志→发布记录（X-PRD-35）；环境地址与管理员→环境台账（X-SEC-09）；对外账号→账号台账（X-SEC-12）；价格→价格主表（SAL-18/X-PRD-22）；人员与主体→飞书通讯录 + 主体表（HR-28/CEO-24）；制度与 SOP→制度库与 SOP 总目录（GEN-01/GEN-18/ALL-10）；决策→决策记录表（ALL-03）。查：清单每类有链接和主责岗。
  • R-02 群聊不是存档。文件、地址、口径、联系方式在群里出现后，发言人 1 个工作日内写入主表，群里只留链接或编号。查：月度抽 10 条群内结论，看主表有无对应记录。
  • R-03 禁止建第二张同类表。要新建表或系统先提清单变更申请（ALL-08 步骤 6）；发现并存表 3 个工作日内合并。查：月度检查副本数。
  • R-04 群里问“在哪/发一下”的，回复清单链接或编号，不直接转发文件；同一信息月内被问 3 次以上，主责岗补公告或清单。查：每周抽 3 个群计数。
  • R-05 凭据（密码、密钥、验证码、root 口令）只能在密码管理工具流转，任何群与文档不得出现明文；出现即 1 小时内撤回并轮换（X-SEC-10/X-SEC-11）。查：检测机器人告警数。

二、一事一入口：请求只能从唯一入口进入

  • R-06 需要别人做事，先查《请求入口表》再提；没有入口的提到“其他请求”，由总经办 2 个工作日内补入口（ALL-01）。在群里 @ 人或私聊提请求的，受理岗只回入口链接，不在群里受理。查：入口外请求占比。
  • R-07 入口表 v1.0（优化期内先覆盖以下类型；时限为工作时间首响）：
请求类型 入口 受理人岗位 响应时限 对应 SOP
产品功能/优化需求（含客户定制、FDE 许愿） 需求提报表单 → 需求池 产品需求受理岗 1 个工作日内分类查重 X-PRD-05、X-PRD-09、X-FDE-02
紧急插单/优先级调整 需求池“插单申请”字段 产品负责人 当日给准入结论 X-PRD-10、CEO-07
客户/用户问题、故障反馈 反馈群机器人表单 → 客户问题工单 售后值班岗 30 分钟首响；P0 4 小时给处置方案 X-CS-05、X-CS-06、X-CS-13
产品缺陷（内部发现） 工单系统缺陷模板 模块负责人 1 个工作日内定级指派 RND-03、RND-07
生产告警/线上故障 告警群认领 + 故障话题 值班研发 15 分钟认领；P0 每 30 分钟同步 RND-78、RND-75
账号与系统权限（Gitea、后台、邮箱、SSO） IT 权限申请审批 IT/安全受理岗 标准权限 1 个工作日内开通 X-SEC-01、X-SEC-02、X-SEC-03、X-SEC-04
云资源、测试服务器、GPU、域名 资源申请审批 → 资源台账 IT/安全受理岗 常规 2 个工作日内交付 X-SEC-16、X-SEC-17、X-SEC-19、RND-23、RND-24
AI 工具订阅、模型 Key、额度 资源申请审批（AI 类） IT/安全受理岗 + 财务 1 个工作日内开通 X-SEC-14、RND-25、RND-27、GEN-09
生产环境访问 生产访问审批（带有效期） 研发负责人 4 小时内响应 X-SEC-18
采购、对公付款、充值 采购/付款审批 财务受理岗 常规采购 2 个工作日内审批 FIN-01、FIN-02、FIN-03、ADM-24、ADM-34
费用报销、差旅 飞书报销审批 财务专员 5 个工作日内审核付款 FIN-06、FIN-07
赠送额度、试用券、内部充值、退补、卡密 资金/额度审批 → 额度台账 财务 + 产品 1 个工作日内审批 FIN-16、OPS-07、FIN-29、OPS-10
合同审查、会签、用印 合同审批流 法务 销售合同 3 个工作日内完成会签；采购合同 2 个工作日 LEG-03、LEG-04、LEG-09
交付订单（一体机、充值、行业版） 交付订单表单 → 交付看板 交付受理岗 盖章后 1 个工作日内建群派工 X-DLV-07、SAL-31
演示支持、样机/演示机、售前技术支持 演示日历 + 演示资源台账 销售支持岗 演示前 2 个工作日锁定环境；借机 1 个工作日内答复 SAL-11、SAL-12、SAL-13、X-DLV-05、SAL-09
招聘需求（HC） HC 申请审批 招聘负责人 3 个工作日内审批 X-RCT-01
新人入职准备 入职清单（Offer 确认自动触发） HR 到岗前 2 个工作日备齐 HR-05、ADM-03、X-SEC-01、ALL-11
请假、居家、加班、补卡 飞书假勤审批 直属上级 / HR 1 个工作日内审批 HR-10、HR-11、HR-12
行政物资、设施报修、寄件 行政服务表单 行政 1 个工作日内受理 ADM-14、ADM-08、ADM-16、ADM-31
设计需求（UI/物料） 设计需求表单 设计负责人 / 品牌 2 个工作日内排期答复 X-PRD-16、BRD-13
数据取数/看板 数据需求表单 运营数据岗 一次性取数 2 个工作日 OPS-17、X-PRD-39
对外口径、宣发审核 口径库 + 发布前自查表单 品牌 / 法务 1 个工作日内答复 BRD-14、SAL-10、LEG-21
政策申报线索 政策线索库 政策申报 3 个工作日内报/不报结论 POL-01
制度/SOP 新建或修订 SOP 变更申请表单 SOP Owner 3 个工作日内评估 ALL-10、GEN-01
卡点升级、归属裁决 升级单 对方 B 角 → 部门负责人 → 总经办 按 ALL-06 阶梯 ALL-06、CEO-05
开会 飞书日程（带议程） 发起人 常规提前 1 个工作日 ALL-05、CEO-10
其他 “其他请求”表单 总经办运营 2 个工作日内分派或补入口 ALL-01
  • R-08 每个入口必须有受理岗 + B 角，两人都不在视为入口失效，由部门负责人当日接管。查：入口表 B 角列无空。
  • R-09 入口表变更只能由总经办发布新版本并更新群公告，不得口头宣布“以后找我”。查：版本号与群公告一致。

三、写清楚再发：请求的最少字段

  • R-10 任何请求至少包含 8 项：类型、一句话要做什么、对象（客户简称/系统/环境/版本/单号）、为什么（场景或关联编号）、期望时间与依据、紧急级别（P0/P1/P2）、附件链接、提出人岗位与可联系时段（ALL-01）。缺项的，受理岗一次性列出缺项退回，不逐条反问。查：一次退回率。
  • R-11 各 SOP 第 3 节“请求最少包含字段”是对 R-10 的细化；下游按它受理，不得再追加口头要求。查：抽样被退回请求是否超出 SOP 字段。
  • R-12 对客承诺前先拿到书面结论：非标需求、并发/性能承诺、渠道预装贴牌必须有产研评估记录与报价特批（SAL-21、SAL-28、X-PRD-11、X-CS-14）。查：承诺记录与评估记录一一对应。

四、消息分级与响应时限

  • R-13 发出要人行动的消息必须标级别：P0 = 正在影响客户/生产/资金/演示；P1 = 今天不处理会卡住别人；P2 = 其他。未标默认为 P1（ALL-02）。查：抽样消息标签率。
  • R-14 首响时限：P0 15 分钟、P1 2 小时、P2 1 个工作日；首响内容必须是“收到 + 预计时间”。超时机器人提醒 B 角。查：首次响应时长中位数。
  • R-15 什么时候可以打电话：只有 P0，且先电话后 15 分钟内补入口单；非工作时段只有 P0 允许电话。审批加急按 GEN-05。查：电话事项有无对应 P0 单。
  • R-16 什么时候不该私聊：涉及第三方要做事、改口径、定优先级、交接的事项不私聊；私聊里形成的工作结论由发起方 1 小时内回写群或工单。查：私聊回写率（部门自报 + 抽查）。
  • R-17 P0 处理中每 30 分钟在原消息/故障话题同步一次，不另开线程；客户群首响按 X-CS-05。查：故障话题时间戳。

五、决策留痕

  • R-18 影响他人的决定（方向、规则、优先级、口径、资源、做/不做）1 个工作日内写入决策记录表：议题、备选、结论、依据、决策人、生效日、影响范围、不做什么（ALL-03、CEO-04）。查：决策留痕率。
  • R-19 发布方式：决策记录链接贴到受影响工作群并置顶；规则类同步进制度库（GEN-01）；涉全员走通知群并要求回执（GEN-02）。查：发布链接与回执名单。
  • R-20 口头决定什么时候算数：决策人在记录上点“已确认”后算数；P0 故障中的处置决定先执行、24 小时内补记录。群里“就这么定”未记录的，任一相关方可代填并 @ 决策人确认。查：确认时效。
  • R-21 已记录的决策不得在群里推翻；要改走复议并附新证据，决策人 3 个工作日内答复。无新证据不重开。查：季度重开次数。
  • R-22 谁有权拍板以授权矩阵为准（CEO-05）；矩阵未覆盖的由 CEO 裁决并补矩阵。查：矩阵覆盖升级单中的裁决类型。

六、交接契约

  • R-23 跨岗位/跨部门交接必须发交接单，写清六要素：交什么（交付物 + 版本/编号）、给谁（岗位）、在哪里（系统位置链接）、什么时候（时限）、验收标准（可检查项）、超时找谁（ALL-04）。口头或群消息交接接收方可不受理。查：交接单覆盖率。
  • R-24 接收方 1 个工作日内确认“已接收 + 预计完成”或一次性退回缺项；交出方在完成后 2 个工作日内验收，逾期视为通过。查：确认时效与返工率。
  • R-25 优化期先定义并执行 8 个交接点：线索→销售（SAL-02）、合同盖章→交付工单（SAL-23→X-DLV-07）、评审通过→研发工单（X-PRD-13→RND-06）、提测→测试（RND-39）、放行→发布（RND-51）、签收单→开票（X-DLV-29→FIN-19）、Offer→入职清单（X-RCT-19→HR-05/ADM-03/X-SEC-01）、客户问题→缺陷/需求（X-CS-13→RND-03/X-PRD-09）。查：《跨部门交接定义表》每点六要素齐全。
  • R-26 高频跨部门 SOP 的交接条款已写入各条第 3/4/6 节，并在第 9 节标注“协作协议：遵循 ALL-xx”；执行以 SOP 条款为准，与本总纲冲突时以更严格者为准。查：SOP 第 9 节协作协议行。
  • R-27 人员离岗、借调、换负责人时，交接清单必须覆盖其名下所有未关闭的请求单、交接单、工单与客户承诺（HR-27、RND-85、SAL-35、X-DLV-37、X-PRD-40）。查：离岗当日未关闭单数为 0 或已改派。

七、升级阶梯

  • R-28 升级前自检三件事：已走入口、已超时限、已 @ 具体岗位而非泛问。未满足的升级被退回（ALL-06）。查：升级单“原单编号”字段非空。
  • R-29 阶梯与时限：一级 → 对方 B 角/值班（超时即刻）；二级 → 对方部门负责人（一级在 P0 30 分钟 / P1 4 小时 / P2 1 个工作日内无结果）；三级 → 总经办协调并确定裁决人（二级在 P0 1 小时 / P1 1 个工作日 / P2 2 个工作日内无结果）；四级 → CEO/COO/CTO 按授权矩阵裁决（P0 当日，其他 2 个工作日）。查：各级时效达标率。
  • R-30 升级时写 7 项：卡点一句话、原单编号、已做努力（找过谁、何时、对方说法）、影响、需要对方做的决定、期望期限、建议方案。查：升级单字段完整率。
  • R-31 越级直接找高管的事项，由高管/总经办退回应有层级并回复“请先找 X”；资金、合规、客户承诺类且矩阵未覆盖的可直接三级。查：越级率。
  • R-32 同一事项因“归属不清”升级 3 次以上，总经办必须提修 SOP 或授权矩阵的变更单（ALL-10）。查：升级原因分类统计。

八、会议纪律

  • R-33 开会前先问“能不能不开”：能用一条带字段的消息或文档评论解决的不开会（ALL-05）。查：无议程会议占比。
  • R-34 什么情况开会：需要多方当场决策或对齐、需要复盘、固定例会。发起时必须填目的、议程（每项标决策/对齐/通报）、材料、必到人、时长（默认 30 分钟）、记录人；常规会提前 1 个工作日，紧急会至少提前 2 小时。查：日程字段。
  • R-35 会后 24 小时内发布纪要：决议进决策记录表，待办逐条建任务并指派责任岗位与截止日；参会人 1 个工作日内回执“已阅”。查：纪要 24 小时发布率、待办进任务率。
  • R-36 开会不在群里反复 @ 催人；超过 5 分钟未到，发起人决定跳过或改期。时间当日改动 2 次以上改为异步处理。查：群内“人呢”类消息数。
  • R-37 下次例会先过上次待办；连续两次未完成的待办升级到部门负责人（CEO-15、ALL-06）。查：会议待办按期完成率。

九、状态可见：用看板替代追问

  • R-38 每类工作有且只有一个看板，统一六态：待办 → 进行中 → 阻塞 → 待验收 → 完成/取消（ALL-09）。优化期先上线：需求池、研发工单、发布计划、交付订单、商机、客户问题工单、招聘漏斗、采购付款、入职准备、申报台账。查：看板目录。
  • R-39 执行人在状态变化当日更新；预计完成日变化必须更新并写原因；阻塞当日标红写“需要谁解决”。超过 3 个工作日未更新机器人提醒执行人与看板主责。查：看板更新率。
  • R-40 “问进度”应变成“查看板”：想知道进度先查看板，不够再在条目评论区问，不在群里泛问；管理层也不例外。查：群内“进度/做了没”类消息数。
  • R-41 机器人每日 18:00 推各看板摘要到项目群、每周一推公司级摘要到管理层；日报周报优先由看板自动汇总，个人只补看板外事项（CEO-12、RND-10）。查：自动摘要覆盖率。

十、SOP 生命周期

  • R-42 每条 SOP 有 Owner 与 B 角，登记在 SOP 总目录；10/28 报送版为 v1.0，优化期定稿为 v1.1；之后内容变更 +0.1，结构/责任人变更 +1.0（ALL-10、GEN-01）。查：Owner 覆盖率 100%。
  • R-43 变更流程：变更单（编号、类型、触发原因、改什么、影响谁、生效日）→ Owner 3 个工作日内评估 → 修订定稿 → 版本递增 → 发布回执。群里口头改规则不算数，以 SOP 库版本为准。查：口头规则率。
  • R-44 每次 P0/P1 事故复盘、每月升级统计、每批试运行必须产出变更单或“无需变更”说明（CEO-16、RND-75、ALL-06）。查：复盘转修订率 100%。
  • R-45 季度抽检：每部门抽 2 条，Owner 用真实执行留痕演示；不通过的列整改期限，超期纳入部门负责人考核（GEN-18）。查：抽检通过率。
  • R-46 新人与新岗位上手路径：到岗前 3 个工作日生成上手包（导师、首周任务、本岗 SOP 清单）；第 1 天读入口表、消息分级、群规则、数据源清单、看板目录；第 1 周按本岗 SOP 完成首周任务；第 2 周独立走一遍本岗主流程并提交 SOP 反馈清单；第 1 月过上手检查表（ALL-11、HR-06）。查：到岗当日就绪率、上手检查通过率。
  • R-47 SOP 月例会由总经办主持：过变更单积压、抽检整改、执行指标，定下月修订重点。查：例会纪要。

十一、群聊治理

  • R-48 建群必须对应一个 SOP 或项目，命名「类型-主体/产品-对象-用途」，登记群台账，群公告写职能、入口表链接、禁发事项、群主与 B 角（ALL-07）。查：群公告覆盖率。
  • R-49 通知群只发通知与回执，讨论进话题或项目群；机器人按告警/待办/播报三级分群，播报默认静默。查：通知群噪音率。
  • R-50 项目/交付结束 5 个工作日内归档：结论与文件进知识库，群改名加「已归档」；30 天无消息的群季度清理。查：僵尸群数。

十二、衡量指标与采集

指标 口径 目标（优化期末） 怎么采集
重复追问次数 同一请求/交接单下，提出人“进度/做了没/什么时候”类消息数 平均 ≤ 1 每月抽 20 单，人工计数；后续机器人按单号聚合
首次响应时长 请求/消息创建到首次“收到”的工作分钟数，按 P0/P1/P2 分别统计中位数 P0 ≤ 15 分钟、P1 ≤ 2 小时、P2 ≤ 1 个工作日 工单与审批时间戳；群消息每月抽 30 条
入口外请求占比 主要工作群中 @ 人提请求但无单号的消息 / 当期请求总数 ≤ 20% 每周抽 3 个主要工作群人工计数
一次退回率 首次提交因缺字段被退回的请求占比 ≤ 25% 且逐月下降 请求单状态日志
交接单覆盖率 跨部门交接中有六要素交接单/工单的比例 ≥ 80% 每月抽 20 次交接
返工率 验收不通过需返工的交接/提测/发布占比 ≤ 10% 交接单验收结论、工单“打回”次数、发版后 hotfix 次数
决策留痕率 会议纪要与群内“定了”类表述中有决策记录的比例 ≥ 90% 每月抽 10 个纪要 + 3 个群
纪要 24 小时发布率 日程结束到纪要发布 ≤ 24 小时的会议占比 ≥ 90% 纪要文档时间 vs 日程时间
看板更新率 当周有变化的条目按时更新的比例 ≥ 90% 条目更新时间戳
越级率 直接找高管的事项中被退回的比例 ≤ 20% 且逐月下降 高管/总经办自报 + 升级单级别跳转字段
明文凭据告警数 群内检测到的明文凭据条数 趋近 0 X-SEC-10 检测机器人
SOP Owner 覆盖率 / 复盘转修订率 有 Owner 与 B 角的 SOP 比例 / 复盘后有变更单或说明的比例 100% / 100% SOP 总目录；复盘台账 vs 变更单
  • R-51 指标每月 5 日前由总经办汇总发布，按部门分列；连续两月不达标的指标由对应部门负责人在 SOP 月例会说明原因与整改。查：月度指标报表。
  • R-52 优化期内凡机器人尚未上线的指标，先用人工抽样采集，不得因为“没有系统”而不统计。查：报表每项有采集方式。

使用说明

  1. 先看第 3 章“两周优化攻坚清单”：得分最高的 SOP 是最该先固化的。
  2. 各部门负责人先看本部门文件开头的“请你确认”表，再改正文；改完即为本部门首轮报送稿。
  3. 第 4 章清单完全对齐 CEO 通知的六个字段（名称、适用场景、负责人、核心流程、交付结果、当前状态），负责人确认后即可用于 10 月 28 日首轮报送。
  4. “X-” 开头的条目归属待定（售后、产品、交付、FDE、招聘、信息安全等），由管理层决定归属后再并入部门。
  5. 每条完整 SOP 都有 10 个小节：场景判定 → 角色 → 办前准备 → 步骤 → 交付物 → 异常升级 → 指标 → 低效诊断 → 分支变体 → 待确认问题。

全景数据

655SOP 总数
2已有
297待优化
295待新建（有证据）
61建议新建（推断）

状态是对“流程载体是否成文、执行是否稳定”的判断，不是对部门工作的评价：待优化＝已有做法或文档，但需要固化、减少催办和返工；待新建（有证据）＝目前靠临时协调；建议新建（推断）＝聊天中未见，按常规应具备。

已有待优化待新建
ALL 全公司协作协议11ECO 研究院生态31BRD 品牌19POL 政策申报14MKT 生态市场（其他）20SAL 销售38OPS 运营29RND 研发90GEN 综合部统筹20CEO 总经办27ADM 行政36FIN 财务43LEG 法务33HR 人事33X-CS 售后 / 客户成功29X-PRD 产品42X-DLV 项目交付 / 实施42X-FDE FDE23X-RCT 招聘26X-SEC 信息安全 / IT 运维46X-OTH 其他待定3

端到端业务流

公司的“业务机器”由一条主营收线和若干支撑线构成：主营收线是“线索→商机→方案/演示→报价→合同→交付→验收→开票回款→售后续费”，以 LeapCore 一体机/私有化部署、行业版与 API/额度类产品为核心载体；它的前端由生态/品牌/市场活动供给线索和品牌势能，后端靠产品研发持续供给可卖、可交付、可运维的版本。人（招聘→入职→在职→离职）和钱（预算→采购→付款报销→开票回款→核算）两条线为所有部门提供资源；政策申报与资质为对外经营提供准入和补贴；IT 资源与信息安全保障账号、环境、凭据和生产变更可控。最上层是经营决策与会议体系，负责定方向、授权、排优先级和闭环跟踪。目前各线“环节”基本都有人在做，最大问题集中在环节之间的交接：入口不统一、交接无单据、责任人不唯一、结论不留痕。

F1 客户获取→签约→交付→售后→回款

从线索到回款与续费的主营收链路，覆盖直销、渠道与 API/额度类订单。

  1. 线索获取与分发认领
    SAL · 入站线索 24 小时内认领并首次联系
    SAL-01SAL-02MKT-07MKT-12SAL-33
    →SAL 归属销售：线索卡片（来源、联系人、需求摘要）
    ⚠ 线索散落在微信、私聊和活动名单，无统一入口与归属，撞单与漏跟并存
  2. 商机甄别与 CRM 登记
    SAL · 商机发现后 2 个工作日内录入 CRM；重点商机 3 个工作日内开启动会
    SAL-03SAL-04SAL-05SAL-06
    →X-FDE/X-PRD：售前评估申请（重点商机附启动会纪要）
    ⚠ CRM 使用率低，日报、纪要、CRM 三处重复录入，商机状态不可量化
  3. 售前方案、演示与试用
    SAL · 演示前 2 个工作日锁定稳定版环境；试用申请 1 个工作日内审批
    SAL-09SAL-11SAL-12SAL-13SAL-14SAL-16X-FDE-02X-FDE-03
    →RND/X-DLV：演示环境冻结申请、试用开通单
    ⚠ 演示使用测试服或新版，现场故障直接影响成单；售前需求不经产品直接找研发
  4. 报价与非标需求评估
    SAL · 标品报价 1 个工作日；非标评估 3 个工作日内给出做/不做/加价结论
    SAL-19SAL-20SAL-21X-PRD-11X-FDE-04X-DLV-01SAL-28
    →LEG：报价单与技术确认结论（作为合同附件）
    ⚠ 前线先对客承诺能力、并发和时间，产研事后评估，标品与非标口径长期不一致
  5. 合同会签、签约与用印
    LEG · 合同多方会签 3 个工作日内完成
    LEG-02LEG-03SAL-23LEG-09LEG-11SAL-24
    →X-DLV：已盖章合同+配置单，触发交付工单；→FIN：收入合同台账
    ⚠ 存在先签后审、熟人免审，合同硬件规格与实际交付不一致，签约主体事后才确认
  6. 交付受理、建群与排期
    X-DLV · 合同盖章后 1 个工作日建交付群并派工
    X-DLV-07X-DLV-08X-DLV-09X-DLV-04SAL-31
    →X-DLV 装机/部署负责人：交付工单（客户信息、配置、上门方式、截止日）
    ⚠ 销售不提单口头要货，订单信息散在多张表和群消息，多订单抢机无优先级规则
  7. 备货装机与部署上线
    X-DLV · 出发前完成真实环境预检；部署后 1 个工作日内完成联调演示
    X-DLV-02X-DLV-13X-DLV-14X-DLV-15X-DLV-18X-DLV-19X-DLV-24X-DLV-26
    →客户：可用系统与账号；→X-DLV：部署检查单
    ⚠ 镜像未验证即带去现场，认证、网盘等问题到现场才暴露，装机与部署依赖一两名外勤
  8. 培训、验收与签收归档
    X-DLV · 交付完成 3 个工作日内回收签收/验收单并上传
    X-DLV-28X-DLV-29X-DLV-31X-FDE-11X-DLV-30
    →FIN：签收单/验收单扫描件（开票与收入确认依据）
    ⚠ 签收单回收滞后，已交付设备、实例和客户信息没有唯一台账，售后找不到设备归属
  9. 开票、回款与收入确认
    FIN · 收到验收单后 5 个工作日内开票；回款每周核对认领
    FIN-19FIN-20FIN-21FIN-17FIN-18FIN-22
    →SAL：回款状态回写 CRM，逾期进入催款
    ⚠ 先交付后补合同，开票依据需销售逐条核实，软硬一体分税率开票易出错
  10. 售后受理、客户成功与续费扩容
    X-CS · 工作时间 30 分钟首响；P0 故障 4 小时内给出处置方案
    X-CS-01X-CS-05X-CS-06X-CS-13X-CS-04X-CS-12X-CS-19X-DLV-33
    →RND：缺陷/需求工单；→SAL：续费与扩容线索
    ⚠ 无专职售后，客户问题进研发群和私聊，反馈过半未闭环，故障常由客户先发现

F2 产品/研发：需求→排期→开发→测试→发布→运维与故障

把客户与业务需求变成稳定可交付版本，并对线上运行负责。

  1. 反馈与需求统一收口
    X-PRD · 新反馈 1 个工作日内完成分类与查重
    X-PRD-05X-PRD-07X-PRD-09RND-01RND-02X-PRD-08
    →X-PRD 需求池：分类后的需求/缺陷/Badcase 条目
    ⚠ 需求入口多路，销售与领导直接找研发，需求/缺陷/Badcase 归类摇摆
  2. 需求评审与优先级
    X-PRD · 迭代开始前 2 个工作日完成评审；紧急插单当日给出准入结论
    X-PRD-10X-PRD-13X-PRD-14RND-04RND-13
    →RND：评审通过的 PRD 与验收标准
    ⚠ PRD 迟到、评审后置，业务规则只在聊天里，产研测对同一功能理解不一致导致打回
  3. 迭代规划与任务分派
    RND · 迭代首日工单全部认领
    RND-06X-PRD-27RND-07X-PRD-29
    →各模块负责人：带估点、截止日的工单
    ⚠ 老板与客户插单绕过迭代，迭代范围被压缩，工单无人认领或模块归属不清
  4. 开发、代码评审与合并
    RND · PR 提交后 1 个工作日内完成评审
    RND-28RND-31RND-32RND-33RND-17RND-19RND-34
    →测试环境：已合并版本与提测说明
    ⚠ PR 合并与发版集中在一两名骨干，评审队列堆积；AI 生成代码缺评审约束
  5. 提测、产品验收与测试放行
    RND · 提测后 2 个工作日内给出验收结论
    RND-39RND-48RND-49X-PRD-31RND-41RND-42RND-44
    →发布负责人：放行结论（通过/带风险/拒绝）
    ⚠ 测试长期只有一人，产品验收无人认领，测试/预发/生产环境用途靠口头约定
  6. 封版、发布与热修复
    RND · 发布窗口固定；hotfix 准入当日判定、24 小时内上线
    RND-50RND-51RND-52RND-53RND-54RND-58RND-59
    →OPS/X-CS：发版完成通知与版本号
    ⚠ 无发布单与检查清单，hotfix 漏 pick、版本号未改、深夜发版无人验收
  7. 发版公告与对内外同步
    X-PRD · 发版当日发布更新日志；停机维护提前 1 个工作日通知
    X-PRD-35X-PRD-35MKT-16X-CS-15X-PRD-35X-PRD-36
    →SAL/X-CS/MKT：更新日志、对外口径、演示注意事项
    ⚠ 版本变化不同步给销售和售后，对外误发测试链接，演示踩新版问题
  8. 监控告警与故障响应
    RND · 告警 15 分钟内认领；P0 每 30 分钟同步一次进展
    RND-78RND-75RND-72RND-76RND-77
    →X-CS：对客口径与恢复通知
    ⚠ 告警无人认领可达数小时，故障无分级与统一指挥，常由用户先发现
  9. 基础设施与上游依赖运维
    RND · 上游余额低于阈值即预警；计划停机提前 1 个工作日通知
    RND-79RND-37RND-38RND-73RND-71X-SEC-29
    →全员：变更与维护通知；→FIN：上游充值申请
    ⚠ 网络、CI、服务器由一两人兼管，上游欠费与渠道切换无预案，多次引发全量故障
  10. 复盘与知识沉淀
    RND · P0/P1 故障 3 个工作日内出复盘
    CEO-16RND-86RND-12RND-85
    →GEN 知识库：事故报告与规则更新
    ⚠ 同类事故重复发生，规则由个人在群里宣布，未成文、未培训

F3 人：招聘→入职→在职（考勤/绩效/培训）→离职

让每个岗位按优先级招到合适的人、快速上手、口径一致地被管理并干净地离开。

  1. 招聘需求、HC 与 JD
    X-RCT · HC 审批 3 个工作日内完成
    X-RCT-01HR-03X-RCT-02X-RCT-03
    →X-RCT：经审批的岗位需求单（优先级、薪资带宽、签约主体）
    ⚠ 谁急谁找 HR，关键岗位被挤压；同一岗位薪资带宽和 JD 口径不一
  2. 渠道运营与简历筛选
    X-RCT · 新简历 2 个工作日内完成初筛与二筛
    X-RCT-04X-RCT-06X-RCT-07X-RCT-08X-RCT-16
    →用人部门：约面/待定/淘汰名单
    ⚠ 简历散在群文件、云盘和招聘平台，群、表格、系统三处台账并行无主数据
  3. 笔试、面试与面评
    X-RCT · 面试后 24 小时内提交面评
    X-RCT-10X-RCT-11X-RCT-12X-RCT-13X-RCT-14X-RCT-15
    →X-RCT：结构化面评与晋级结论
    ⚠ 面试集中在少数技术骨干，评价标准不统一，同一候选人评价相反
  4. 定薪、背调与 Offer
    X-RCT · 终面通过后 3 个工作日内发 Offer
    X-RCT-17X-RCT-18HR-04X-RCT-19
    →HR/ADM/X-SEC：入职清单（到岗日、工位、设备、账号、导师）
    ⚠ 定薪拍板链长且需多方协调，多主体下签约主体与发薪主体不一致
  5. 入职准备与账号开通
    HR · 到岗前 2 个工作日备齐工位、电脑与账号
    HR-05ADM-03ADM-04X-SEC-01RND-21
    →部门负责人：新人已就绪通知
    ⚠ 工位、电脑、账号常在到岗当天才处理，HR、行政、IT 未联动
  6. 入职培训、带教与转正
    HR · 入职首周明确导师与首周任务；转正前 2 周提醒评估
    HR-06HR-07HR-08HR-09
    →部门负责人：试用期目标与评估表
    ⚠ 新人无人派活、无人告知规则，实习生到岗后才确认归属
  7. 考勤、假勤与加班
    HR · 每月 3 个工作日内完成考勤核对
    HR-10HR-11HR-12HR-13HR-14
    →FIN：月度考勤结果
    ⚠ 加班调休规则长期口头，补卡与扣薪口径反复追问，人工催办量大
  8. 薪酬、社保与福利发放
    HR · 按固定发薪日发放，异常 3 个工作日内更正
    HR-15HR-15HR-16HR-17HR-22
    →FIN：工资表与审批记录；→员工：工资单
    ⚠ 财务、HR、管理层各有一套数据，补贴口径多次调整，出现多发少发与延期
  9. 绩效、激励与面谈
    HR · 每迭代/每月结束后 5 个工作日内出结果
    HR-19HR-18HR-20HR-21RND-12
    →员工与直属上级：评价结果与改进计划
    ⚠ 点数与绩效规则在群里争论，口径随版本调整，激励制度适用范围未先说明
  10. 调岗、借调与离职交接
    HR · 离职当日完成账号停权与资产回收
    HR-25HR-26HR-27X-SEC-08ADM-32RND-85
    →X-SEC/ADM/FIN：账号回收、资产回收、停发通知
    ⚠ 离职漏通知、交接无清单，账号权限与客户关系交接断档

F4 钱：预算→采购→付款/报销→开票/回款→核算

让每一笔支出有预算、有审批、有票据，每一笔收入有依据、可对账、能入账。

  1. 预算与授权额度
    FIN · 每月初发布部门预算余额
    CEO-01FIN-09MKT-15HR-03
    →各部门负责人：可用预算与审批权限表
    ⚠ 预算多为口头确定，临场授权无书面额度，业务方不清楚预算来源
  2. 采购申请与供应商比价
    FIN · 常规采购审批 2 个工作日内完成
    FIN-01FIN-02ADM-24ADM-25X-DLV-02X-OTH-01
    →LEG：采购合同；→FIN：付款申请
    ⚠ 先买后报、审批单无明细，询价与供应商无统一管理，各人重复比价
  3. 采购合同与用印
    LEG · 采购合同审核 2 个工作日内完成
    LEG-04LEG-07LEG-09LEG-11
    →FIN：已签合同（付款依据）
    ⚠ 用印无登记，盖章版本与审批版本不一致的风险，合同原件找不到
  4. 到货验收与资产入账
    ADM · 到货 2 个工作日内验收入库
    ADM-27ADM-33X-DLV-03
    →FIN：入库单与资产编号
    ⚠ 资产台账多版本并存且与财务未打通，硬件库存靠手工盘点
  5. 对公付款、充值与预支
    FIN · 上游余额预警后 1 个工作日内完成充值
    FIN-03FIN-04FIN-05X-OTH-03RND-73
    →业务方：付款回执与到账确认
    ⚠ AI 订阅与境外服务靠个人垫付，无票支出多，上游欠费停服后才处理
  6. 费用报销与发票管理
    FIN · 报销提交后 5 个工作日内审核付款
    FIN-06FIN-07FIN-08FIN-10FIN-11FIN-12
    →员工：报销到账；→FIN：票据归档
    ⚠ 能否报销的口径缺失、反复询问，存在替票等合规风险
  7. 收入开票与回款认领
    FIN · 开票申请 3 个工作日内开具
    FIN-17FIN-18FIN-19FIN-20FIN-21FIN-22
    →SAL：回款与开票状态
    ⚠ 客户催票时开票依据不全，软硬一体合同未分税率约定
  8. 渠道分成、支付对账与资金异常
    FIN · 支付渠道每日对账，差异 2 个工作日内处理
    FIN-23FIN-24FIN-25FIN-26FIN-27FIN-29
    →RND/X-CS：差异与修复工单
    ⚠ 分账、对账、退款差异反复多轮修复，财务确认角色缺位，研发直接处理资金调账
  9. 成本、定价与毛利核对
    FIN · 上游调价后 2 个工作日内完成成本价与对外价同步
    FIN-28FIN-30RND-69RND-70X-PRD-22SAL-18
    →X-PRD/SAL：生效价格表与毛利底线
    ⚠ 成本价、倍率、对外价在多处手工维护无单一来源，定价无财务审批
  10. 核算、税务与审计
    FIN · 每月 10 日前完成上月核算与申报确认
    FIN-31FIN-32FIN-34FIN-35FIN-36FIN-37
    →CEO：月度经营与税额确认
    ⚠ 多主体成本归属事后确认，历史缺票与期初差异推高审计工作量

F5 政策申报与资质

把政策机会、知识产权和经营资质变成可复用的准入与补贴能力。

  1. 政策线索研判与申报决策
    POL · 收到通知 3 个工作日内给出报/不报结论
    POL-01POL-02
    →POL 申报台账：申报项、牵头人、截止日
    ⚠ 申报、知识产权、年检归口长期不清，临时用“@谁负责”确认
  2. 申报基础资料库与证照调用
    POL · 资料调用 1 个工作日内响应
    POL-03GEN-13ADM-23LEG-10
    →申报牵头人：最新版资料包
    ⚠ 证书、合同、账号、手机卡分散在个人手里，资料找不到或非最新版
  3. 知识产权储备（软著/专利/商标）
    LEG · 审查意见在法定期限前 5 个工作日完成答复
    POL-10POL-11LEG-14LEG-16POL-10POL-11
    →POL：可用于申报的权属证明清单
    ⚠ 专利技术审核依赖单人，命名先于检索导致商标多次驳回，权属主体反复争议
  4. 佐证材料与指标报告
    POL · 截止日前 5 个工作日交付
    POL-06RND-43
    →申报牵头人：测试/检测/验收报告
    ⚠ 申报与客户交付争抢同一批技术人员，材料常被推后
  5. 项目、人才与补贴申报提交
    POL · 截止日前 2 个工作日完成内部审校
    POL-04POL-05POL-07POL-09
    →FIN：立项与补贴到账跟踪
    ⚠ 申报资格人员临时指定、缺人员库，主体选择影响补贴资格时才发现
  6. 备案与专项资质办理
    LEG · 产品上线前 30 天完成资质判断
    LEG-23LEG-24LEG-25LEG-25LEG-24X-SEC-20X-SEC-43
    →X-PRD/RND：资质结论与上线前置条件
    ⚠ 备案联系人登记在个人，复审反复失败；产品先上线再补备案与审核
  7. 年检年报与到期提醒
    POL · 到期前 30 天提醒，前 7 天办结
    POL-08GEN-14X-SEC-21
    →负责人：到期提醒与办理结果归档
    ⚠ 年报、证书、域名到期靠个人记忆，已发生逾期事故
  8. 主体登记与变更
    GEN · 工商变更完成后 3 个工作日内同步
    GEN-15FIN-38CEO-22
    →FIN/HR/LEG：主体信息变更通知
    ⚠ 多主体归属常在事后确认，影响补贴、资质使用和合同主体

F6 生态/品牌/市场活动

以活动、内容和生态合作制造品牌势能与线索，并把线索交给销售转化。

  1. 活动规划与参与决策
    ECO · 每季度首周发布活动日历
    ECO-01MKT-01MKT-02
    →MKT/ECO：季度活动日历与投入取舍
    ⚠ 活动多为临时决定，投入产出缺评估，大会方向临近仍被改变
  2. 立项、预算与营销方案审批
    MKT · 活动预算审批 3 个工作日内完成
    MKT-14MKT-15FIN-09LEG-21
    →FIN：活动预算单；→LEG：营销合规审核
    ⚠ 营销玩法先做后补合规，预算来源与审批人不清
  3. 生态伙伴引入与资源对接
    ECO · 新合作方 3 个工作日内完成内部对齐
    ECO-02ECO-03ECO-04MKT-12
    →SAL/X-PRD：合作线索与资源需求
    ⚠ 合作与对接依赖个人关系，资源与需求信息只在群聊和私聊
  4. 品牌口径、内容与物料
    BRD · 活动物料提前 5 个工作日定稿
    BRD-01BRD-13BRD-14BRD-17BRD-11MKT-09
    →MKT/SAL：定稿物料与统一话术
    ⚠ 产品名多种写法并存，对外表述靠即兴生成，物料版本散落
  5. 大会/活动筹备与分工
    ECO · 大型活动倒排 4 周启动
    ECO-16ECO-17ECO-18ECO-20MKT-03MKT-06
    →各责任人：任务清单与日会跟踪
    ⚠ 临近才拉群拆任务，领导意见集中在最后导致物料反复返工
  6. 演示与现场保障
    ECO · 活动前 3 天完成彩排与网络测速
    ECO-19ECO-21MKT-05X-SEC-32X-DLV-06SAL-12
    →RND/X-DLV：演示版本冻结与设备清单
    ⚠ 现场网络、设备临时借调，缺保障检查表，演示环境不稳
  7. 培训营与学员运营
    ECO · 名单确定后 3 个工作日内完成外联确认
    ECO-22ECO-23ECO-24ECO-25ECO-26X-FDE-17
    →ECO：学员台账与班级群
    ⚠ 外联记录分散在手写和个人表格，对外答复口径各异，通知通道资质不足
  8. 宣发与新媒体运营
    BRD · 事件型稿件活动后 1 个工作日内发布
    BRD-08BRD-09BRD-10BRD-12OPS-18
    →MKT：传播数据周报
    ⚠ 技术表述发布前缺核实，品牌与合规参与滞后
  9. 线索回收、转化与复盘
    MKT · 活动结束 2 个工作日内录入线索
    MKT-07ECO-28OPS-12ECO-12
    →SAL：活动线索清单（来源可追踪）
    ⚠ 活动线索无统一录入与来源追踪，转化效果无法复盘

F7 经营决策与会议体系

定方向、授权、排优先级、开会、派活并闭环，让决策可追溯、可执行。

  1. 规划与目标分解
    CEO · 每季度首周完成
    CEO-01CEO-13
    →各负责人：季度目标与关键事项清单
    ⚠ 规划催办依赖高管个人推动，未形成固定节奏
  2. 立项与重大方案决策
    CEO · 重大决策 1 个工作日内形成书面记录
    CEO-02CEO-03CEO-04RND-14X-PRD-01
    →GEN：决策记录（选项、依据、结论、负责人）
    ⚠ 多人各自拍板，技术路线与产品形态反复，决策只在群聊无记录
  3. 授权、汇报线与组织边界
    CEO · 架构调整当周同步飞书
    CEO-05CEO-06HR-02CEO-24CEO-08
    →全员：授权矩阵与组织架构公告
    ⚠ 汇报线虚线化，同一人向多人汇报，授权口头且不为被授权人所知
  4. 优先级与资源分配
    CEO · 每周例会更新一次
    CEO-07CEO-09X-PRD-10
    →各项目负责人：优先级清单与人力分配
    ⚠ 多项目抢同一批人，借调频繁，“紧急”的定义各方不一致
  5. 会议召集与纪要
    CEO · 会后 24 小时内发纪要
    CEO-10CEO-11RND-09
    →参会人与相关方：纪要与待办（进任务系统）
    ⚠ 结论只在会上或群里，相关人“没印象”，会议安排当日反复调整
  6. 任务派发、催办与周期汇报
    CEO · 待办超期 1 个工作日自动提醒
    CEO-15CEO-12RND-10SAL-32
    →总经办：待办台账与周报汇总
    ⚠ 催办靠在群里 @，日报散在群聊无结构化汇总，管理层看不到进度
  7. 制度发布与全员通知
    GEN · 制度发布后 1 周内完成宣贯
    GEN-01GEN-02GEN-03HR-01
    →全员：制度库条目与回执
    ⚠ 规则在群里口头宣布，通知群与闲聊群混用，新人和渠道查不到
  8. 向上汇报与风险上报
    CEO · 预计延期即时上报，不晚于节点前 2 个工作日
    CEO-14RND-08
    →管理层：风险与延期说明
    ⚠ 延期临近节点才暴露，越级汇报与传话导致口径变形
  9. 内部系统与协作工具治理
    CEO · 新系统上线前完成 UAT 与基础数据
    CEO-20X-PRD-38RND-81GEN-12
    →X-PRD/RND：系统边界与单一数据源清单
    ⚠ CRM、渠道、合同、项目等系统功能重叠、主数据不清，机器人规则与记忆易丢
  10. 复盘与经验沉淀
    GEN · 重大项目结束 1 周内复盘
    CEO-16GEN-11GEN-12
    →知识库：复盘报告与 SOP 修订
    ⚠ SOP 多次被提出但无实物、无人验收，“走 SOP”找不到入口

F8 IT 资源、账号与信息安全

账号、环境、AI 资源与凭据按需申请、最小授权、有台账、可回收，生产变更可控。

  1. 账号与系统权限开通
    X-SEC · 标准权限 1 个工作日内开通
    X-SEC-01X-SEC-02X-SEC-03X-SEC-04X-SEC-05
    →申请人：账号与权限（登记到账号台账）
    ⚠ 开号、加白依赖少数管理员，不在即停摆，权限无台账
  2. 服务器、云资源与算力申请
    X-SEC · 常规资源 2 个工作日内交付
    X-SEC-16X-SEC-17RND-23RND-24ADM-34
    →申请人：资源地址与到期日；→FIN：成本归属
    ⚠ 资源申请靠群里喊，优先级口头评估，闲置资源误释放或长期占用
  3. AI 工具、Key 与额度管理
    X-SEC · 申请 1 个工作日内开通
    RND-27X-SEC-14RND-25RND-26RND-27
    →FIN：采购与补贴口径；→申请人：Key/额度
    ⚠ 订阅与号池个人化，各自采购、各自封号申诉，成本与合规无人统管
  4. 凭据保管与环境台账
    X-SEC · 发现明文凭据 1 小时内撤回并轮换
    X-SEC-10X-SEC-12X-SEC-09
    →全员：密码管理工具与禁发规则
    ⚠ 几乎所有工作群都出现过明文密码与密钥，环境地址与管理员账号靠群内检索
  5. 生产访问、外部接入与变更
    X-SEC · 生产访问审批 4 小时内响应，到期自动回收
    X-SEC-18X-SEC-06X-SEC-07RND-58
    →RND：带有效期的访问授权与变更记录
    ⚠ 生产访问与客户 root 授权由个人把控，无有效期、无回收，曾在生产上做测试
  6. 上线安全检查与 Agent 权限
    X-SEC · 对外上线前 3 个工作日完成检查
    X-SEC-37X-SEC-38X-SEC-39RND-20X-SEC-33
    →RND/X-DLV：安全放行结论
    ⚠ 机器人权限过大且部署在个人电脑，已发生提示词注入与误操作，上线安全检查后置
  7. 安全事件与漏洞应急
    X-SEC · 高危通告 24 小时内完成排查
    X-SEC-11X-SEC-40X-SEC-41X-SEC-42
    →全员：通告与整改工单
    ⚠ 安全响应靠事故触发，终端防护计划长期未落地，缺复盘模板
  8. 资产盘点与权限回收
    X-SEC · 每月盘点一次；离职当日回收
    X-SEC-08X-SEC-21X-SEC-22ADM-33
    →FIN：可释放资源与成本节约清单
    ⚠ 服务、域名、设备“是谁的”反复追问，到期续费与释放靠记忆

两周优化攻坚清单（Top 40）

评分 = 频次 × 单次耗时/返工 × 跨部门程度 × 出错风险（各 1~5 分，满分 625），供排序参考。

#编号SOP归属状态得分主要问题
1POL-04科技项目申报（市/省重点研发、OPC 专项、联合申报）政策申报待优化500已有项目申报群、荣誉资料汇总文档、申报计划表和政策追踪 skill 雏形，也有专人操作；但归口在销售、总经办、生态市场条线之间多次变更，截止前临时拼材料、催技术配合人、找平台账密的情况反复出现
2SAL-11客户演示准备与执行销售待优化500已有《LeapCore+MercAll 通用演示流程》文档（演示前准备与话术），但 2026-01～09 演示几乎都是前一天才通知、临时定演示人、临时跑通，演示前通宵赶包、现场翻车、演示人不熟悉产品等反复出现约 90 次
3SAL-19客户方案与报价单编制审核销售待优化500已有报价 Skill（09 月发布）、报价群、标准报价单雏形，合同系统也在建设报价审批模块；但 03～10 月仍反复出现：临发前才发现漏写报价、同一份文件“是否已经加价”争论约 10 轮、方案没定就先报价、版本只靠文件名区分、审核人和时限不固定。约 40 次以上返工或催办
4SAL-31渠道报备→订单→交付（渠道系统）销售待优化500渠道系统已上线，2026-10 起订单入口从飞书问卷强制切换到渠道系统；但切换期旧订单材料需补齐、外部渠道开通无明确负责人、审核节点没有飞书通知、客户未绑定导致财务看不到余额，审核与管理员角色未拆分。
5RND-18跨团队/跨系统接口对齐与集成约定研发待优化500已有不少载体（OIDC 适配说明、ADR、OpenAPI/Apifox 文档、开放平台决议清单、渠道系统说明、工单系统），但 2026-01～10 约 20 起对接中，接口文档靠群里要，需求方与提供方反复反问才对齐，谁写数据、工单提给谁不清，联调现场才发现分支或 secret 不对，外部平台登录问题来回多次
6RND-51正式版本发布上线研发待优化500已有 50 验证→51 验收→102 生产的环境口径、Gitea tag/CI、LeapUpdate、构建与签名机器人卡片、字字可研 prod-release skill 与冒烟用例 wiki、平台部《版本发布 SOP》；但 2026-01～10 各产品线反复出现"部署了没/要发哪些组件"追问、漏组件、漏 cherry-pick、版本号错乱，发布后才发现未备份或缺配置，并发生正式服不可用、客户机升级死锁等事故，缺全公司统一的发布单与检查单。
7RND-75线上/测试环境故障响应与复盘研发待新建50041 条聊天证据覆盖 1～10 月几乎所有产研群，每次都靠群里 @ 人救火；没有故障分级、值班表、响应时限、通报模板和复盘模板；复盘要靠管理者点名催写，存放位置不统一；同类事故（60 秒超时、配置未下发、磁盘满、证书过期）反复发生
8FIN-25资金/分账异常排查与数据修复财务待新建500已有支付平台每日对账机器人、对账定时任务和 V5 资金告警通道，但只比对账实、不监控结算时效；2026-03～10 多次由商户上门或业务追问才发现问题（队列积压近 6 个月无人发现），修复后靠口头同步，财务未参与确认
9X-SEC-27办公网络故障报修与恢复信息安全 / IT 运维待新建500上半年至 10 月几乎每月都有大面积断网（7 月被统计为“重灾区”，约一周一断），全部靠群里喊“网管”、单人临时处理；9 月起才出现飞书“故障反馈”审批但未普及；无分级、无 SLA、无根因记录，宽带账号与办理人说不清，曾因欠费断网
10ALL-04跨部门交接契约全公司协作协议待新建400全年“交接断档”“职责不清”是高频信号：合同盖章后交付不知情、提测不知道测什么、接手模块只知“皮毛”、装机依赖个人环境；交接多以群消息或口头完成，无单据无验收。
11ECO-06开放平台 Skill/插件与第三方接入上架研究院生态待优化400已有 LeapSkill 格式规范 1.0.0、插件开发指南、DevKit、uploader 和审核流程，但入驻审核只靠“管理员给账号”、接口协作靠私聊；第三方合作方每家临时对接，07～10 月约 50 次往来中多次返工（凭据管理事后补、套壳/原生接入反复）
12SAL-23销售合同起草、条款谈判与用印销售待优化400已有通用版和正式销售合同模板、飞书合同盖章审批；但 04～08 月审核链路长、法务审核成为瓶颈，拖慢渠道签约；出现过拼写错误、终身权益与数量条款多轮修改；05 月合同里写的硬件形态与实际可交付不一致，导致补买机柜；7 月出台的“先签后动”“不做验收尾款”只在群里宣布。约 20 次
13SAL-27渠道伙伴开发、授权政策与协议签署销售待优化400已有《LeapCore 产品渠道管理办法》、渠道代理协议模板、渠道拓展执行方案和渠道培训 SOP；但 2026-07 同一协议一周内出了约 7 个版本，2026-08～09 独家条款与政策不一致、价格模板未更新、法务提示价格限制条款有反垄断风险，并被指出“没有专人负责渠道管理”。
14RND-26AI 工具/中转渠道采购、号池运维与封号应对研发待新建4002026-01～10 共 9 个群反复讨论“哪家稳、能不能开票、会不会封号”，长期靠个人垫资；号池维护人退出后交接断档，号池没人维护。目前只有“AI 产品采购表”和几条口头结论（自建中转、国内一手货源、国外经供应商二手货源），没有成文流程
15RND-54Hotfix 紧急修复准入与发布研发待新建4002026-06 产品口头定义了准入范围，2026-08 起有每日 hotfix 总工单和 17:30 冻结的口头规则，2026-09 起改走 51 验收；但 2026-04～10 一直没有成文规范。期间出现过：全量误发导致生产下线、未验证提交进入 hotfix 引入更大问题、工单进了 hotfix 而代码没进、修复漏 pick、hotfix 一周发不出、凌晨直推无人验收。2026-08 产品负责人明确要求单独出标准化 SOP
16RND-64行业版插件开发、接入规范与交付研发待优化400已有插件规范 1.0、插件开发指南和 LeapOpen 下发能力，但规范仍在迭代；2026-08 两次误发（提前下发、发老版本）紧急撤回；企业名单靠群内口头给，Cloud 与 LeapUpdate 两处手工配置
17RND-67新模型/上游渠道/第三方 API 接入与上线验证研发待优化400已形成"工单 → PR → 测试服 → 验收 → hotfix"路径并有接入/查价 skill，但 2026-05～10 仍反复出现需求模型反复变、配置阻塞在单人、key 归属不明、测试服没钱、价格未验证、漏开模型开关等问题，管理层多次要求"SOP 化"
18CEO-07多项目优先级与人力分配总经办待优化400已有过周分工清单和一张梳理任务的多维表格；但 2026-02～09 排序与派活仍靠关键人临场判断，同一人被多线拉取、"人呢/进展如何"类催问约 20 次，商务需求无准入，大项目并行时只能临时找人或招人
19FIN-29计费扣费异常核查与退补财务待新建4002026-06～07 至少 5 次同类事件，每次临时查日志、逐个对令牌，结论散在群聊与机器人回复中，退补无审批链
20X-CS-05客户问题受理、分流与工单流转售后 / 客户成功待优化4002026-07 已发布《Leap 反馈渠道及提报规范》，反馈群有机器人卡片和 AI triage，2026-09 起双轮岗值班；但入口仍多头（反馈群、订单群、客户微信群、私聊），信息不全反复追问，一线答疑集中在少数研发，缺分级 SLA 和回告闭环
21X-CS-09计费余额异常核查、对账修复与退款售后 / 客户成功待新建400充值回调延迟、生成失败仍扣费、预占规则不透明、对账口径不一、大客户缓存未命中等问题在 2026-06～10 反复出现约 20 次，每次靠群内临时拉人排查；无客服入口、无退款规则、无数据修复规范，仅在一次大客户事故后补了复盘文档。
22X-CS-12硬件设备售后、返修与上门维保售后 / 客户成功待新建4002026-07 起多次提出需要售后 SOP，08 月两次催办后仍只有两条占位内容的草稿；05～10 月客户设备掉线、IP 变化、断电无法访问等约 20 余次，每次群内临时拉人，分工靠口头约定"硬件找运维、软件找后端"；返厂地址、联系人、上门收费均未成文。
23X-PRD-05需求统一收口与提需入口规则产品待优化400收口原则已多次口头宣布（「鼎慧产研决策部」2026-05～06、「LeapCore（archived）」2026-05、「Leap产研测」2026-10），市场需求准入规则在「【模态】行业版leapcore」2026-06～07 执行一致；但入口在群聊、表单、Gitea、需求池多处并存，绕过产品、临时加急、研发自行加功能后被砍等情况仍反复出现。
24X-DLV-13一体机出厂装机、预装与测试验收项目交付 / 实施待优化400已有《交付 SOP（产研）》《软件部署 SOP》、部署 skill、测试脚本与 OOBE 镜像；但 2026-06～10 交付信息分散在硬件、软件、订单三张表，进度靠群里追问约 15 次；硬件→软件交接缺检查单（缺 SSH/软件源无法远程）；部署后测试责任人不固定；SOP 落后于版本，出现“SOP 都走不明白”的交付差错
25X-DLV-19客户现场/远程部署实施与上门安排项目交付 / 实施待优化400已有《软件部署SOP》（依赖清单、环境确认、设备注册、部署、用户导入、部署检查单、WG 部署、客户信息上报）、Deploy-Skill 与交付订单表；但 2026-03～09 多个群反复出现"谁装/找谁""交付前一天才问能否搞定""谁能下发配置"、外勤无人可用、每次向研发索要 IP 与账号、上门约时间靠群内追问等问题。
26X-DLV-25信创/国产算力适配与厂商协同项目交付 / 实施待新建400已有《Leap信创上下文》文档覆盖打包与测试 SOP，但需求入口、版本/DDL 指派、厂商问题升级、对外口径均无固定做法；03～10 月海光、壁仞、麒麟等厂商问题靠口头"抽鞭子"催办约 25 次，适配 owner 与 DDL 多次被追问
27X-DLV-34交付期现场问题反馈与故障闭环项目交付 / 实施待新建40002～09 月同类问题多次靠电话、口头转达和群内临时 @ 人处理，无故障单、无分级、日志仅 info 级；出现交付介质与机型不符、代码已提交未封包等交付差错
28X-FDE-04定制项目技术方案、硬件选型报价与内部审核FDE待优化400已形成"产出人提交—一审—关键项目二审"的固定习惯，且有 AI 预审先例；但无统一方案模板和硬件 BOM 库，技术路线反复争论、每个项目重新估算和询价，审核人单点排队，审核后仍出现条款疏漏返工，因此判定待优化。
29X-RCT-17定薪谈薪、录用审批与 Offer 发放招聘待优化400已有招聘 SOP（含试用期规范）、录用通知书模板和邮箱发放的固定做法，但没有岗位薪酬带宽表和录用审批单，定薪逐人在群里请示；2026-01～10 多个招聘群反复出现口径不一、试用期折扣现问、岗位名称现问、多层级各自报价、出薪卡点不透明，合计 30 次以上
30X-SEC-14AI 编程工具订阅账号开通、充值与防封管理信息安全 / IT 运维待优化400已有 wiki《订阅防封攻略（公司个人自购版）》，镜像订阅也有每月约 10 日开号、发 CDK 的节奏和负责人；但 2026-01～10 在 11 个群里反复出现开号、封号、充值断供、报销口径的问题，约 200 次；防封经验散在聊天里，不按文档操作就被封；新人开号要靠人提醒；CDK、借用账号在大群明文发；补贴、报销、代付的口径不一致。
31ECO-19大会演示场景与 Demo 准备研究院生态待新建375LeapCore 已有现场演示流程与 QA 文档，但无案例库与演示脚本库；案例分派后长期无人跟进，演示视频大会前临时拼凑，场景、名称多次变更，演示环境（公网/内网）前一晚才讨论，属于每次临时处理。
32BRD-12媒体采访与外部拍摄接待及对外口径品牌待新建37505～09 月多次媒体来访均为临时组群处理：前一天才通知、通宵赶制物料、受访人临时得知、研发区未提前预告被拍屏幕、受访稿口径靠群内讨论；无登记表、无检查清单、无口径审批
33SAL-07政企客户需求对接与方案汇报销售待新建3752026-03 多次“没准备就去讲”“去了才知道跟谁聊”，白皮书改到第六版；2026-08 客户总办会退回，要求补数据分级与模型选型论证；2026-06 礼品拜访无事前审批、敏感内容不敢在大群发；每次都靠临时群聊协调，没有模板和清单
34SAL-22招投标与供应商入库销售待新建375频次不高但金额大；05～10 月每次都临时找材料（法人证件、社保证明、审计报告靠在群里来回问），报价表 v1～v10 反复返工，合计与分项对不上，标书分工靠群里临时分配，还出现过需要法务把关的陪标报价单。没有模板，也没有资料库
35RND-72上游模型故障告警响应与降级研发待优化375已有“临时状态助手”“AI 上游连续失败告警”等机器人，但无值班、分级与处置手册；2026-08 起告警后约 1 小时才有人响应，某生产功能失效约两周才被发现
36LEG-03销售合同审查与多方会签法务待优化375已有 LeapCore 合同审核群、飞书合同审批流程和 AI 审查报告，07～10 月审了 60 余份合同；但公司名称、金额大小写、法定代表人、地址、型号等低级错误反复出现约 40 次，模板版本混用，硬件配置与可交付不一致，早期还出现过签完才发现口头承诺与合同不符
37X-DLV-24离线/私有化项目现场部署实施项目交付 / 实施待优化375已有 docker-compose/env 模板、一键部署脚本、部署文档与反馈表；但 2026-01～08 现场反复救火：国产卡机器拉取失败通宵改方案、IP 写死搬机后失效、未预演镜像现场起不来、同一问题多次往返现场、部署文档反复被催、命令靠翻聊天记录；本地大模型交付多轮返工且部署要点未纳入运维 SOP。
38X-DLV-27客户 POC/演示环境搭建与交付项目交付 / 实施待优化375演示与 POC 已形成习惯做法（先测、录屏、写文档、发客户），但 01～09 月多次出现截止日在群里反复变动、方案边聊边定、交付前夜返工，缺立项评估、验收口径和交付检查清单
39X-SEC-43等保测评、整改与云安全产品采购信息安全 / IT 运维待优化375已有测评服务商、资产表、差距报告、等保脚本仓库、堡垒机等基础，但 2026-01～07 两套系统推进约半年：测评只能排到年后、整改人排期难对齐近 2 个月、复测又出新问题、采购被追问约 3 次、申报主体临近结束才确认，等保需求未经产品导致登录改造反复返工
40ALL-03决策记录与发布全公司协作协议待新建320全年多次出现同一问题反复讨论 3～5 次、结论改口、“我讲过两遍”与“从没听说”并存；方向与规则在群聊中边聊边定，无记录，新人与机器人均查不到。

全公司 SOP 清单（首轮报送口径）

六个字段对齐 CEO 通知：名称、适用场景、负责人、核心流程、交付结果、当前状态。

ALL 全公司协作协议 报送人：待定（建议综合部牵头）

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ALL-01工作请求提交与受理（一事一入口）任何人需要别的岗位或部门为自己做一件事（提需求、要资源、要审批、要支持、要数据、要人）时，决定“往哪里提、写什么、多久有人接”，替代在群里 @ 人或私聊口头提。主责——总经办运营（当前：田杰·部门报送人）；协同——各入口受理岗（产品需求受理岗、售后值班岗、IT/安全受理岗、交付受理岗、财务受理岗、HR 受理岗，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 判断请求类型 → ② 按入口表选唯一入口 → ③ 按最少字段填写 → ④ 受理岗限时认领并回执 → ⑤ 补齐信息或退回 → ⑥ 转入对应 SOP 执行 → ⑦ 状态回告提出人 → ⑧ 提出人确认关闭一张全公司“请求类型 → 入口 → 受理岗位 → 响应时限 → 对应 SOP”入口表（群公告置顶 + 知识库）；每条请求都有编号、受理人、状态和关闭记录。待新建300
ALL-02消息分级与响应时限发出或收到一条需要别人行动的工作消息时，判断它是 P0/P1/P2、该用什么渠道（群、工单、电话）、多久必须有回应，以及什么时候不该私聊。主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人（排值班与 B 角）、研发负责人（当前：丁震宇·部门报送人，告警与故障分级口径）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 发消息前定级 → ② 按级别选渠道并标注 → ③ 接收方按时限回应“收到+预计” → ④ 超时自动提醒 B 角 → ⑤ 处理结果回到原消息/工单 → ⑥ 月度统计响应时长《消息分级与响应时限规则》（群公告 + 知识库）；每条 P0/P1 消息有可查的首响记录；私聊中的工作结论回写到群或工单。待新建300
ALL-03决策记录与发布任何会影响他人工作的决定（方向、规则、优先级、口径、资源分配、做/不做）在会上、群里、电话或私聊中形成后，判断是否需要记录、记在哪里、怎么发布、什么时候算数。主责——总经办运营（当前：田杰·部门报送人，决策记录表维护）；协同——各决策人（CEO、COO、CTO、各部门负责人）、综合部（制度类决策发布，当前：赵雪冰·部门报送人）；兜底——CEO（当前：待指定）① 判断是否为“影响他人的决定” → ② 决策人或记录人 1 个工作日内写决策记录卡 → ③ 发布到相关群并置顶/进知识库 → ④ 相关方回执 → ⑤ 生效 → ⑥ 复议走正式通道 → ⑦ 季度回顾《决策记录表》（多维表格）；每条决策有编号、选项、依据、结论、决策人、生效日、影响范围、发布链接；规则类决策进入制度库。待新建320
ALL-04跨部门交接契约一件事从一个岗位/部门交给另一个岗位/部门继续做（销售→交付、产品→研发、研发→测试、交付→财务、HR→IT 等）时，规定每次交接必须说明交什么、给谁、在哪里、什么时候、验收标准、超时找谁。主责——总经办运营（当前：田杰·部门报送人，交接定义表维护）；协同——各主线 SOP 负责人（按手册第 2 章 F1～F8 交接点）、各部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 识别交接点 → ② 交出方按“六要素”发交接单 → ③ 接收方限时确认接收或退回 → ④ 接收方按验收标准做 → ⑤ 交出方验收/关闭 → ⑥ 超时触发升级 → ⑦ 交接点定期复盘《跨部门交接定义表》（每个交接点：交出方、接收方、交付物、位置、时限、验收标准、超时升级人）；每次交接有可查的交接单或工单字段。待新建400
ALL-05会议发起、纪要与待办闭环任何人想开会（例会、专题、评审、对齐、复盘）时，判断是否真的需要开会、怎么发起，以及会后 24 小时内如何产出决议与待办并进入任务系统。主责——总经办运营（当前：田杰·部门报送人）；协同——各会议发起人、记录人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 判断能否不开会 → ② 发起：目的/议程/材料/参会人/时长 → ③ 开会并开启智能纪要 → ④ 24 小时内校对纪要、决议进决策记录、待办进任务 → ⑤ 参会人回执 → ⑥ 待办跟踪关闭带议程与材料的日程；24 小时内发布的纪要（决议 + 待办 + 责任人 + 截止日）；待办全部在任务系统可查。待优化180
ALL-06卡点升级阶梯一件事卡住（无人认领、对方超时、两边意见不一致、资源不够、不知道找谁）时，规定卡多久向谁升级、升级时写什么，替代“直接找老板”或“反复在群里催”。主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人、各入口受理岗；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 确认已走入口且已超时限 → ② 第一级：对方 B 角/值班 → ③ 第二级：对方部门负责人 → ④ 第三级：总经办协调 → ⑤ 第四级：CEO/COO/CTO 裁决 → ⑥ 升级结果回写原单 → ⑦ 月度升级统计每次升级有一条可查的升级记录（卡点、已做努力、需要谁决定什么、期限）；升级路径固定，越级事项被退回原路径。待新建300
ALL-07群聊治理（建群、命名、公告、归档）需要新建工作群、决定某条消息发到哪个群、设置群公告、处理群混用与刷屏、项目结束归档群时启动；明确群只是沟通渠道，不是存档与受理入口。主责——综合部负责人（当前：赵雪冰·部门报送人）；协同——飞书管理员（当前：待指定）、各群群主；兜底——总经办运营（当前：田杰·部门报送人）① 判断是否需要建群 → ② 按命名规则建群并设群主/B 角 → ③ 发布群公告（职能、入口链接、禁发事项） → ④ 按群类型发消息 → ⑤ 机器人分级降噪 → ⑥ 项目结束归档 → ⑦ 季度清理《群职能与命名规则》；每个工作群有群公告（职能 + 入口表链接 + 禁发规则）；群台账（群名、类型、群主、B 角、状态）。待优化120
ALL-08信息归档与单一事实来源产生或需要查找一份工作信息（客户信息、合同、订单、需求、版本、环境地址、账号台账、价格、制度、决策、文档）时，规定它只能存在哪里、谁维护、群聊与私聊中的内容如何回写；替代“翻群找”“问一下谁有”。主责——综合部负责人（当前：赵雪冰·部门报送人，数据源清单与知识库）；协同——各数据主责岗（CRM：销售；需求池：产品；工单：研发；台账：交付/IT/财务/HR）、产品负责人（内部系统归口，X-PRD-38）；兜底——总经办运营（当前：田杰·部门报送人）① 查《单一数据源清单》 → ② 信息产生时直接写入指定位置 → ③ 群/私聊只贴链接或编号 → ④ 聊天中的结论 1 个工作日内回写 → ⑤ 其他位置只做引用不做副本 → ⑥ 月度检查副本与过期信息 → ⑦ 清单变更走审批《单一数据源清单》（信息类型 → 唯一位置 → 主责岗位 → 编号规则 → 对应 SOP）；群公告与入口表链接到清单；每类信息只有一个主表。待新建300
ALL-09状态看板与进度同步任何人想知道“某件事到哪了”，或执行人需要让别人知道进展时，规定用看板/工单状态替代群里追问；“问进度”应变成“查看板”，执行人按节奏更新状态而不是被动回答。主责——总经办运营（当前：田杰·部门报送人，公司级看板）；协同——研发负责人（工单看板，当前：丁震宇·部门报送人）、产品负责人（需求池/迭代看板，当前：待指定）、交付负责人（交付看板，当前：待指定）、销售负责人（CRM 商机看板，当前：许君、李鹏为·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 每类工作有一个看板 → ② 执行人按状态机更新 → ③ 阻塞当日标红并写原因 → ④ 看板自动推送日/周摘要 → ⑤ 想知道进度先查看板 → ⑥ 看板缺失才允许问 → ⑦ 月度统计更新率公司级看板目录（需求、工单、发布、交付、商机、招聘、采购、入职、申报）；每个看板有状态定义、更新责任人与更新时限；管理层可不问人看到进度。待新建150
ALL-10SOP 变更与版本管理任何 SOP 需要新建、修订、合并、废止，或有人发现 SOP 与实际做法不一致、规则在群里被口头改变时，规定 Owner、版本号、变更流程、发布与宣贯、季度抽检；保证“只有 SOP 库里的版本算数”。主责——综合部负责人（当前：赵雪冰·部门报送人，SOP 总目录）；协同——各 SOP Owner（按部门报送人指定）、总经办运营（当前：田杰·部门报送人，SOP 例会与抽检）、研发负责人（当前：丁震宇·部门报送人，全公司版本编写牵头）；兜底——CEO（当前：待指定）① SOP 总目录登记（编号、Owner、版本、状态） → ② 变更申请（谁、为什么、改什么） → ③ Owner 修订并评审 → ④ 版本号递增、发布与宣贯 → ⑤ 旧版标废止 → ⑥ 季度抽检执行情况 → ⑦ 事故/升级触发强制修订SOP 总目录（全部编号、Owner、B 角、版本、生效日、复审日、状态、入口链接）；每次变更有变更记录；季度抽检报告。待新建240
ALL-11新人与新岗位上手新员工、实习生、借调/外包人员到岗，或在职员工转到新岗位/新项目时，规定第一天、第一周、第一月分别要拿到什么（入口表、群、看板、数据源清单、本岗 SOP、导师），让新人不用靠“问人”才能开始工作。主责——人事（当前：黄莹·部门报送人）；协同——用人部门负责人（导师指定与首周任务）、IT/安全受理岗（账号，当前：待指定）、行政（工位设备，当前：胡则瑾·部门报送人）、综合部（SOP 与制度必读包，当前：赵雪冰·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 到岗前：入职清单触发（HR-05） → ② 第 1 天：账号、群、必读包、导师 → ③ 第 1 周：本岗 SOP 清单与首周任务 → ④ 第 2 周：独立走一遍本岗主流程 → ⑤ 第 1 月：上手检查 → ⑥ 反馈回流修 SOP岗位上手包（必读清单、入口表、群清单、看板、本岗 SOP 编号、导师）；上手检查表；新人对 SOP 的反馈清单。待新建180

ECO 研究院生态 报送人：陈梦琪

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ECO-01生态活动年度规划与 ROI 取舍每月/每季度规划对外生态活动（黑客松、沙龙、训练营、大会、开源/高校合作），或收到外部活动邀约，需要决定办不办、去不去、投入多少时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，ROI 与技术选题把关）、FDE/运营（当前：李凯·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认，大会场务）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 线索入活动池 → ② 填立项卡估 ROI → ③ 分级取舍 → ④ 月度评审 → ⑤ 发布活动日历并分派 → ⑥ 选题/人力锁定 → ⑦ 活动后复盘回写经 CEO 确认的月度/季度活动日历（含每场目标、预算、ROI 预估、执行负责人）及每场活动复盘记录待优化108
ECO-02生态合作伙伴引入与内部对齐接触到新的合作方、渠道、KOL 或外部专家，需要先在内部统一理解合作模式、评估对接方式、决定关系维护动作（含赠送试用额度、开通工具账号）时启动主责——生态市场条线负责人（当前：许君·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，合作形态定性）、开放平台负责人（当前：郭逸非·推断待确认）、FDE/Skill 负责人（当前：李凯·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，工单项目与额度审批）、研发对接人（当前：邓乾·推断待确认）、运维/账号开通（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记合作线索 → ② 内部对齐会 → ③ 合作形态定性 → ④ 对齐纪要确认 → ⑤ 开工单项目 → ⑥ 外部技术对接 → ⑦ 关系维护动作 → ⑧ 台账月度更新合作伙伴台账记录 + 内部对齐纪要（合作模式、产品形态、技术投入、负责人）+ 需要研发时的工单项目待新建90
ECO-03生态资源池建设与资源对接引荐手上有新一批生态资源（活动名单、合作方名单、表格）要入池，或内部有人需要找团队/供应商/专家/设备/客户，需要从资源池匹配引荐时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——资源池系统研发（当前：邓乾·推断待确认）、开放平台/FDE（当前：郭逸非·推断待确认）、运维/域名（当前：宋祺睿·推断待确认）；审批——CEO（当前：邴龙志·推断待确认，名单对外使用）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 按模板收集资源 → ② 自动抽取转标准字段 → ③ 试导入确认 → ④ 去重打标入池 → ⑤ 需求登记 → ⑥ 匹配引荐 → ⑦ 结果回流与周汇总可检索、已去重打标的生态资源池；每条内部需求的引荐结果记录；有商机的资源转入销售线索池待新建72
ECO-04生态厂商合作申请（样机/测试卡/适配报告/认证）收到 NVIDIA、电信、国产算力（海光、壁仞、百度等）、国产 OS/CPU（统信、麒麟、飞腾、龙芯）等生态方邀请或要求，需要填申请表/评分表、领取样机或测试卡、交付适配测试报告或申请互认证书时启动主责——生态厂商对接人（当前：丁震宇·推断待确认，建议移交生态市场条线）；协同——认证对接（当前：韩诗琪、陈芷青·推断待确认）、测试（当前：杨云峰、潘浩伟·推断待确认）、IT/资产（当前：杨明学·推断待确认）、交付部署（当前：游家豪·推断待确认）、信创负责人（当前：李子遥·推断待确认）、销售/渠道（当前：闫登辉·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 登记生态机会 → ② 判断是否申请 → ③ 材料库 + AI 生成申请材料 → ④ 审阅提交 → ⑤ 跟踪批复 → ⑥ 样机入资产 → ⑦ 测试出报告/认证 → ⑧ 归档并转宣传已提交的申请表/评分表；入资产台账的样机或测试卡；适配测试报告或厂商互认证书；可用于宣传稿和投标资质的材料待优化180
ECO-05开放平台业务归属与需求路由口径开放平台/基座等业务的归属、汇报线、例会参会人不清，或市场销售对开放平台能力认知混乱、需求被错误路由时启动；同时作为销售判断“需求该进开放平台还是定制”的规则依据主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，通知与产品视角）、插件研发（当前：侯怡辰·推断待确认，开发课）、FDE 负责人（当前：李凯·推断待确认）、总经办（当前：待指定，架构与汇报登记）；裁决——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记业务归属与汇报线 → ② 绑定例会参会名单 → ③ 编制能力边界与分类决策树 → ④ 全员通识课 → ⑤ 新销售必修 → ⑥ 需求按决策树路由 → ⑦ 争议裁决 → ⑧ 季度更新业务归属与汇报登记表；《开放平台能力边界与项目分类决策树》及 FAQ；通识课课件与培训记录；需求路由记录待新建120
ECO-06开放平台 Skill/插件与第三方接入上架内部研发、FDE、外部开发者或合作伙伴要把 Skill、插件或数据源接入 LeapCore 开放平台并上架，或 LeapCore 客户端需要对接开放平台下发技能时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——插件接入技术负责人（当前：侯怡辰·推断待确认）、开放平台账号与网关（当前：吴亚军·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，架构决策）、客户端后端（当前：宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）、FDE 负责人（当前：李凯·推断待确认）、销售总监（当前：吴琪·推断待确认）、数据源评估（当前：白立新·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；计费设计——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 接入申请 → ② 分类评估（第三方过检查表） → ③ 开通开发者账号与 Key → ④ 按规范开发自检 → ⑤ 提交审核 → ⑥ 客户端联调 → ⑦ 计费鉴权打通 → ⑧ 上架通知与反馈迭代通过审核并在开放平台上架的 Skill/插件/数据源；第三方合作的接入检查表与商务条款确认记录；计费鉴权配置待优化400
ECO-07OPC 社区/商城第三方商家入驻与准入OPC 社区、智能涌现商城、智能体工坊招募外部商家/开发者入驻，或内部员工要上架自有产品，或承接地方政府 OPC/AI 产品征集需要厂商预上架时启动主责——OPC 社区/商城运营负责人（当前：陈梦琪·推断待确认）；协同——商城研发/商家对接（当前：葛家和·推断待确认）、招商与定价（当前：丁震宇·推断待确认）、厂商联系（当前：杨朋伟、刘昱潇·推断待确认）、技术对接（当前：毛鹏程·推断待确认）、准入标准修订（当前：李铭熙·推断待确认）、支付冲正（当前：吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 发布入驻须知 → ② 商家提交入驻申请 → ③ 准入评审与可用性核验 → ④ 签入驻协议 → ⑤ 定价与商品资料 → ⑥ 卡密/兑换码导入校验 → ⑦ 预上架测试 → ⑧ 上架与进度汇报 → ⑨ 结算与售后签署协议、通过准入、完成预上架测试并上架的商品；商家入驻台账；结算与售后记录；对政府主管部门的进度表待新建300
ECO-08开源社区建设、运营与产出汇报运营开源聚变 AI 社区（内容/智能体/活动征集、论坛与社群人气）、维护公司开源项目名单、汇总开源与布道产出、对接外部开源社区活动（赞助、演讲）时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——开源/布道（当前：李子遥·推断待确认）、线下分享协调（当前：吴亚军·推断待确认）、运营（当前：李凯·推断待确认）、新媒体（当前：鲁周毅·推断待确认）、开源聚变技术支持（当前：宋祺睿·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、选拔赛设计（当前：黄莹·推断待确认）、推广（当前：侯明月、邓乾·推断待确认）；发起与审批——CEO（当前：邴龙志·推断待确认）；开源准入——CTO（当前：丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 季度社区运营计划 → ② 开源准入审核 → ③ 维护开源名单 → ④ 统一表单征集内容/智能体/活动 → ⑤ 内容合规审核 → ⑥ 社区日常运营 → ⑦ 每周产出汇报 → ⑧ 外部社区活动评估对接 → ⑨ 月度复盘季度社区运营计划；开源项目与贡献者名单；审核后发布的社区内容；每周开源产出周报；外部活动立项与复盘记录待优化72
ECO-09内部项目开源孵化公司内部出现小而有趣、可独立开源的 idea 或工具（如 PR 审阅 Bot、本地多模态推理网关），需要征集、筛选立项、开发、评审并定期汇报进度时启动。主责——开源孵化管理（当前：杨萌·推断待确认）；协同——技术评审/创始人兼 CTO（当前：丁震宇·推断待确认）、项目开发者（当前：李子遥、葛家和·推断待确认）、idea 来源方（当前：陈梦琪、岳阳·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 征集 idea → ② 初筛 → ③ 立项并指定唯一负责人 → ④ 需求文档与里程碑 → ⑤ 开发与自动日报 → ⑥ AI 预审 + 人工 code review → ⑦ 每周进度更新 → ⑧ 结项转发布（ECO-10）或终止通过评审、可编译可运行、带 README 的开源候选仓库，以及它在孵化看板中的完整记录（立项、里程碑、评审结论、周进度、结项结论）。待优化54
ECO-10开源项目与技术成果对外发布研发完成可对外展示的工具或技术成果（自研工具开源获客、国产硬件适配首发等），需要做首发调研、开源合规核查、建公开仓库与 README、对外推文宣传时启动。主责——开源运营/发布专员（当前：李子遥·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、技术作者（当前：杨云峰·推断待确认）、对外沟通与厂商协调（当前：常元和·推断待确认）、推文宣传（当前：刘昱潇·推断待确认）、CI/开源技术顾问（当前：吴世豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 成果登记 → ② 宣传价值判断与首发调研 → ③ 开源合规核查 → ④ 上游/厂商确认 → ⑤ 发布审批（LEG-29）→ ⑥ 建仓库与 README → ⑦ 对外口径核对 → ⑧ 公开与推文 → ⑨ 台账登记与发布后维护公司 GitHub 组织下已公开、带 README/LICENSE/贡献指南的仓库，经核对的对外推文，以及研发成果与开源项目台账中的完整记录。待新建96
ECO-11开源贡献署名、报备与统计员工以公司名义给外部开源项目提 issue/PR、需要统一署名；工作时间提交外部贡献需要报备；或领导、投资方、政府申报、对外合作需要公司开源贡献清单时启动。主责——开源贡献台账管理（当前：李子遥·推断待确认）；协同——创始人兼 CTO（统筹报送，当前：丁震宇·推断待确认）、GitHub 组织管理员（当前：王皓南·推断待确认）、技术验证（当前：宋祺睿·推断待确认）、研究院生态负责人（当前：陈梦琪·部门报送）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 统一公司 GitHub 组织与公共邮箱 → ② 署名规则执行 → ③ 工作时间外部 PR 报备 → ④ 合入后登记台账（脚本自动拉取）→ ⑤ 每周开源产出汇报 → ⑥ 报送需求按口径筛选 → ⑦ 人工核实后对外报送一份持续更新、可链接验证的“开源贡献台账”，以及按报送对象口径导出的贡献清单；外部贡献统一带公司署名标识。待新建48
ECO-12外部活动/会议参会与信息回收收到或决定参加外部社区答辩、专家评审、开源会议、技术派对、社区分享会等活动，需要选派人员、报名、准备材料，并在会后回收纪要与人脉信息时启动。主责——生态运营（外部活动对接）（当前：待指定）；协同——活动对接人（当前：杨萌·推断待确认）、研发派员决策/创始人兼 CTO（当前：丁震宇·推断待确认）、参会代表（当前：王皓南、宋祺睿、魏宗浩、李子遥·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 登记邀请 → ② 定目标与是否参加 → ③ 指定唯一带队人与参会人、报名 → ④ 征集问题、准备材料与演示 → ⑤ 日程与提醒 → ⑥ 现场参会 → ⑦ 会后 2 个工作日内出纪要 → ⑧ 人脉与线索回流 → ⑨ 产出登记外部活动登记表中一条完整记录（目标、参会人、材料、纪要链接、产出），以及回流到资源池/招聘/销售的联系人与线索。待新建54
ECO-13对外讲课、培训与布道宣讲已确认接下高校课程、政府/合作方培训、参访交流、布道宣讲、Meetup 等对外讲课场次，需要排讲师、拼装标准内容、核验案例、交付授课并回收反馈时启动；也包括内部分享材料转成外部课程。主责——外部分享负责人/讲师统筹（当前：陈梦琪·推断待确认）；协同——场次与内容要求提出/CEO（当前：邴龙志·推断待确认）、研发讲师调度/创始人兼 CTO（当前：丁震宇·推断待确认）、讲师/布道官（当前：李子遥、望政韬、王皓南·推断待确认）、内部分享组织（当前：杨萌·推断待确认）、标杆案例组长（当前：白福康·推断待确认）、参访接待（当前：杨朋伟·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 场次需求单 → ② 查讲师库档期并排班 → ③ 从标准内容包拼装课件 → ④ 案例与数据核验 → ⑤ 课件评审定版 → ⑥ 演示环境与物料就绪 → ⑦ 授课 → ⑧ 反馈回收与内容包更新 → ⑨ 讲师工作量登记按时、按听众定制完成的授课场次，定版课件归档，反馈与新 FAQ 回填到标准内容包，讲师工作量入台账。待优化108
ECO-14高校/校园生态合作与校园大使围绕高校与 OPC 平台开展校园合作（算力赞助、补贴券推广、校园大使招募与邀请码分润、全员转发引流）时启动。主责——校园生态运营（当前：陈梦琪·推断待确认）；协同——高校/政府关系与方向拍板/CEO（当前：邴龙志·推断待确认）、算力赞助方案（当前：李凯·推断待确认）、校园大使招募执行/行政（当前：侯明月、丁蕊·推断待确认）、邀请码需求/产品（当前：杨萌·推断待确认）、开发（当前：张康·推断待确认）、测试（当前：张东郅·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 合作立项（目标、高校、预算、KPI）→ ② 赞助/补贴/分润规则发布 → ③ 校园大使招募与高校覆盖 → ④ 邀请码与分润系统上线（含压测）→ ⑤ 统一素材包与全员转发 → ⑥ 补贴/算力发放 → ⑦ 月度提成结算与提现 → ⑧ 月度复盘已立项的校园合作计划、在岗校园大使名单与高校覆盖看板、可追踪的邀请码推广数据、经财务核对的补贴与提成发放记录、月度复盘。待新建180
ECO-15黑客松与开发者/内部 AI 赛事筹办计划举办对外黑客松（开发者用 LeapAll 做 Skill/Agent）或内部 AI 赛事（LeapAgent 赛马等），需要确定赛制、评分权重、参赛环境、赛事群运营和奖励发放时启动。主责——赛事组织负责人（当前：杨萌·推断待确认）；协同——方案把关与技术资源/创始人兼 CTO（当前：丁震宇·推断待确认）、积分总额与奖项拍板/CEO（当前：邴龙志·推断待确认）、评测（当前：张东郅·推断待确认）、研发驻场（当前：岳阳、王皓南·推断待确认）、评委（当前：李铭熙·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 赛事立项（目标、对象、规模、预算/积分总额）→ ② 赛制与评分规则发布 → ③ 参赛环境与教程 → ④ 评测机与评测集 → ⑤ 报名与赛事群运营 → ⑥ 比赛执行与驻场 → ⑦ 评审打分 → ⑧ 公示与申诉 → ⑨ 奖励发放 → ⑩ 复盘完成的赛事、公示的评审结果、发放完毕并入账的积分或奖金、赛事复盘（含可复用的赛制与评分模板）。待新建96
ECO-16生态大会立项与总体筹备CEO 决定举办生态大会、理事会、股东会或专场大会，需要立项、定总体方案与议程、组建筹备组、邀请人清单、报名网站、全员动员与调休安排时启动。主责——大会项目经理/总协调（当前：赵雪冰·推断待确认）；协同——CEO（定目标与方向，当前：邴龙志·推断待确认）、联合创始人（大会主方向与上台，当前：常元和·推断待确认）、创始人兼 CTO（研发资源与全员通知，当前：丁震宇·推断待确认）、方案与嘉宾邀请（当前：李鹏为·推断待确认）、展区统筹（当前：杨萌·推断待确认）、发布会内容（当前：王皓南·推断待确认）、演示环境（当前：宋祺睿·推断待确认）、物料与接待（当前：侯明月·推断待确认）、资料记录（当前：董蓝汐·推断待确认）、报名网站（当前：葛家和·推断待确认）、外部活动对接（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① CEO 立项（目标、定位、日期、预算）→ ② 指定唯一项目经理与模块负责人 → ③ 总体方案与议程 → ④ 邀请人清单 → ⑤ 报名网站与入场 → ⑥ T-3 内容冻结 → ⑦ 全员动员与调休通知 → ⑧ 彩排 → ⑨ 现场执行 → ⑩ 会后考勤、费用与复盘按里程碑完成的大会（立项单、总体方案、议程、邀请清单、报名名单、全员通知、彩排记录），以及会后费用归集与复盘报告。待新建200
ECO-17大会任务分工与进度跟踪公司确定举办生态大会、研究院大会等大型对外活动并进入倒计时（约活动前 30 天）后，需要把议程拆成任务清单、落实到人，并按天跟踪进度与风险。主责——大会总统筹（总经办）（当前：赵雪冰·推断待确认）；协同——产品展区模块负责人（当前：杨萌·推断待确认）、生态活动与物料模块负责人（当前：陈梦琪·推断待确认）、邀约与运营模块负责人（当前：李凯·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项并书面指定拍板人 → ② 按议程拆任务清单 → ③ 指定模块第一负责人与 DDL → ④ 启动会 → ⑤ 每日更新进度 → ⑥ 日会只过红黄项 → ⑦ 阻塞与拍板升级 → ⑧ 活动前 2 天查漏补缺 → ⑨ 会后关闭任务并移交复盘一张覆盖所有模块的大会任务看板（任务-负责人-截止日-状态-风险-链接）、日会纪要与决策记录、会后任务关闭清单与费用汇总。待优化250
ECO-18大会嘉宾邀约与嘉宾资料收集大会立项后，需要确定并邀请政府、高校、企业嘉宾，收集嘉宾名单、职务、照片、演讲材料、圆桌问题，并产出座次图与席卡。主责——嘉宾邀约与资料总口（生态市场总监）（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、各条线邀请人（当前：闫登辉、杨朋伟、刘昱潇、吴琪、陈梦琪·推断待确认）、行政（当前：侯明月·推断待确认）、产品经理（当前：陈震·推断待确认）、商务（当前：杨朋伟、裴建武·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 发嘉宾名单表按条线分派 → ② 各条线填报 → ③ 拍板邀请名单 → ④ 统一邀约口径与节奏 → ⑤ 发出邀请并登记状态 → ⑥ 表单收集嘉宾资料 → ⑦ 圆桌问题提前发嘉宾 → ⑧ 座次图/席卡定稿 → ⑨ 活动前 1 天终核已确认的嘉宾名单（含邀请人、状态）、完整嘉宾资料库（职务/照片/演讲材料/圆桌问题）、唯一版本的座次图与席卡。待优化160
ECO-19大会演示场景与 Demo 准备大会、发布会或渠道/客户演示前，需要确定演示场景与案例、编写各产品演示流程与 QA、开发活动互动 Demo，并交付产品材料与演示视频。主责——产品总监（当前：杨萌·推断待确认）；协同——场景总包（当前：王皓南·推断待确认）、各产品演示文档负责人（当前：宋祺睿、刘昱潇、李铭熙·推断待确认）、活动 Demo 第一负责人（当前：陈梦琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、视频剪辑（当前：李宣昊·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 明确受众与场景候选 → ② 拍板场景清单 → ③ 内容合规筛查 → ④ 活动 Demo 需求定稿与原型评审 → ⑤ 开发、跑通与回归 → ⑥ 演示流程与 QA 文档 → ⑦ 演示环境选择与安全确认 → ⑧ 录屏保底与素材归档 → ⑨ 搭建前最终走查演示场景库（场景-步骤-素材-测试状态-录屏）、各产品现场演示流程与 QA 文档、可运行的活动 Demo、统一规格的演示视频与保底录屏。待新建375
ECO-20大会物料评审、定稿与采购大会筹备期，视觉、手册、展板、PPT、视频及身份卡、积分卡、礼品等物料需要统一归集、集中评审定稿、做成本数量决策并采购制作、现场发放。主责——物料评审组织人（总经办）（当前：赵雪冰·推断待确认）；协同——各物料负责人（当前：杨萌、陈梦琪、陈震、许君、闫登辉·推断待确认）、素材库与命名规范维护（当前：李凯·推断待确认）、询价采购（当前：潘浩伟、葛家和·推断待确认）、积分卡技术方案（当前：张东郅·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 建物料清单 → ② 统一归集与命名 → ③ 提交初稿 → ④ 一日一审集中评审 → ⑤ 修改复审并记录结论 → ⑥ 品牌合规检查 → ⑦ 成本数量决策 → ⑧ 下单打样与验收 → ⑨ 定稿打包交制作 → ⑩ 现场发放与遗留登记唯一的定稿物料包（含版本记录）、采购/制作验收单、积分卡等物料发放记录。待优化128
ECO-21大会展区硬件、搭建彩排与现场执行大会前一周至当天，需要借用/验收/装机演示机、确认现场电力网络、安排展区值守与交接、运输搭建、彩排清场、签到引导及现场故障响应。主责——现场执行负责人（总经办）（当前：赵雪冰·推断待确认）；协同——展区负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、外设与运输（当前：闫登辉·推断待确认）、活动码负责人（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 设备清单与借用登记 → ② 验收装机与配置 → ③ 会场电力网络确认 → ④ 展区排班与话术交接 → ⑤ 活动码清单与压测 → ⑥ 彩排 → ⑦ 装箱清点与运输搭建 → ⑧ 当天清场、签到、现场响应 → ⑨ 设备归还与调休登记设备清单与借还台账、装机验收记录、展区排班与交接确认、彩排记录、现场执行清单、会后设备归还验收单。待新建200
ECO-22培训营报名筛选、分层与名单管理FDE 等培训营报名问卷持续涌入（千人级）时，需要按准入标准评分并分为初/中/高级，确定班级规模与落选去向，维护唯一名单，并向主管部门和领导汇报报名看板。主责——培训营统筹（生态组负责人）（当前：陈梦琪·推断待确认）；协同——FDE 评分执行（当前：佘天禾·推断待确认）、准入标准与复核（当前：郭逸非·推断待确认）、评分标准校准（当前：吴亚军·推断待确认）、筛选 SOP 文档（当前：谭涛·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 开班前定准入标准、比例与容量 → ② 建唯一名单源 → ③ AI 按规则打分分层 → ④ 人工复核与特殊人员判断 → ⑤ 定班级规模与分流标签 → ⑥ 输出带版本的入选名单 → ⑦ 生成报名看板并评审发布 → ⑧ 新增报名后增量重跑唯一在线名单（含分数、分层、分流标签、变更记录）、首批入选名单、报名数据看板（总览 + 分层，隐藏分数）。待优化108
ECO-23学员分班、批次分配与特殊插班培训营名单确定后，需要按行业分批分班（每班约 100 人）并录入报名系统，处理销售/领导/政府推荐的插班、同事同班、旁听，以及统一“为什么没进首批/为什么在初级”的对外口径。主责——分班负责人（FDE 教务）（当前：佘天禾·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、名单清洗（当前：谭涛、蔡鸿坤、侯晨帆·推断待确认）、系统导入（当前：邓乾·推断待确认）、销售侧（当前：韩诗琪、朱文瑜·推断待确认）、口径制定（当前：陈梦琪·推断待确认）；兜底——开放平台负责人（当前：郭逸非·推断待确认）① 发布分班规则 → ② 按行业拆表清洗 → ③ 标记特殊人群 → ④ 分批分班与人数平衡 → ⑤ 特殊通道插班 → ⑥ 人工复核终审 → ⑦ 导入报名系统并生成自助查询 → ⑧ 发布对外口径与 Q&A → ⑨ 调班与二次分班各批次各班名单（已录入生态资源池 SaaS）、自助查询页、特殊通道登记表、对外口径与 Q&A 更新。待优化108
ECO-24学员外联确认、台账与候补补位培训营批次名单确定后，需要电话邀约确认、批量短信通知、协调兼职外包、实时记录联系台账并核实进群，对放弃或联系不上的名额进行候补补位。主责——外联组长（当前：谭涛·推断待确认）；协同——培训营统筹（当前：陈梦琪·推断待确认）、电话外联（当前：蔡鸿坤·推断待确认）、官微与拉群（当前：侯晨帆·推断待确认）、名单与统计（当前：佘天禾·推断待确认）、支援外联（当前：韩诗琪、丁蕊、汪家诺·推断待确认）、短信通道技术（当前：邓乾、宋祺睿·推断待确认）、人事（兼职招募）（当前：待指定）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 一页版外联 SOP → ② 人手与兼职到位 → ③ 名单分配 → ④ 电话确认 → ⑤ 合规短信通知 → ⑥ 实时记台账 → ⑦ 进群核实与每日汇总 → ⑧ 缺口候补补位 → ⑨ 开课前锁定名单每班确认参加并已进群的锁定名单、完整联系台账（意向/进群/备注）、每日汇总报告、候补补位记录。待优化256
ECO-25学员答疑、班级群与自助查询培训学员确认入选后，需要加官微、进班级群、接收通知、提问答疑，或自助查询分班、上课时间地点和群二维码主责——生态运营（官微与 Q&A）（当前：侯晨帆·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、开放平台负责人（课程/考核答疑）（当前：郭逸非·推断待确认）、LeapAll 服务端研发（查询页）（当前：邓乾·推断待确认）、FDE 成员（Q&A 接机器人）（当前：佘天禾·推断待确认）、AI 讲师/助教（当前：梅立·推断待确认）；兜底——研究院生态负责人（当前：陈梦琪·推断待确认）① 入选通知 → ② 加官微并拉入班级群 → ③ 配置查询页 → ④ 收集问题进待答池 → ⑤ 分派责任人答复 → ⑥ 入库 Q&A 并同步机器人 → ⑦ 课前须知/FAQ 更新下发学员全部进入对应班级群；查询页信息准确可自助查询；唯一一份持续更新的 Q&A 文档及接入客服机器人的知识库；每批次的课前须知 PDF待优化180
ECO-26培训/课程实操环境与算力容量准备高校课程、FDE 培训、大型活动需要学员现场或远程实操 LeapCore 时，需要提前完成并发容量评估、网络接入方案、设备采购、预测试和现场技术保障主责——培训技术保障负责人（当前：待指定）；协同——IT 运维/网管（当前：杨明学·推断待确认）、Leap 研发/技术负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、交付/IT（当前：李奎星·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）；方案与采购审批——创始人兼 CTO（当前：丁震宇·推断待确认）；预算审批——CEO（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交活动需求单（≥ 2 周前）→ ② 容量与接入方案评估 → ③ 方案拍板与采购 → ④ 部署与账号分发 → ⑤ 提前 1 周压测 → ⑥ 前一天踩点 → ⑦ 现场保障 → ⑧ 回收与复盘经压测验证的实操环境（设备、网络、账号、模型额度）、学员接入文档、现场保障检查表与值守排班、活动后的回收记录与压测/故障结论待新建250
ECO-27开班仪式与线下培训会务筹备线下培训（大课+小班实操）或开班仪式开课前，需要落实活动方案、场地、物料、人员分工，并邀请专家、学员代表与领导出席主责——研究院生态负责人（活动总协调）（当前：陈梦琪·推断待确认）；协同——行政助理/会务（当前：丁蕊·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、销售运营/销售支持（助教排班）（当前：韩诗琪·推断待确认）、生态运营（名单文档）（当前：谭涛·推断待确认）、FDE 成员（筛名单）（当前：佘天禾·推断待确认）、会务（当前：郭昊·推断待确认）、生态运营（官微）（当前：侯晨帆·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、CEO（政府表述确认）（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 开课前 3 周立项与清单 → ② 活动方案与分工 → ③ 嘉宾与学员代表邀请 → ④ 物料设计制作 → ⑤ 场地踩点 → ⑥ 学员通知与助教排班 → ⑦ 前一天彩排检查 → ⑧ 当天执行细化到个人的活动方案、嘉宾与学员代表出席名单、物料到位清单、踩点检查表、助教排班表、学员通知（场地指引、培训通知）待优化160
ECO-28培训结营复盘与学员转化每批线下培训结束后，复盘活动问题，回访学员并把有需求的学员转化为客户、渠道伙伴或孵化对象，交接给销售或长期运营主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——研究院生态负责人（收集与回访）（当前：陈梦琪·推断待确认）、AI 讲师/助教（长期运营）（当前：梅立·推断待确认）、AI 讲师/班主任（当前：张家瑞·推断待确认）、CEO（转化方向）（当前：邴龙志·推断待确认）、销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 结营当天发反馈问卷 → ② 3 个工作日内召开复盘会 → ③ 回访学员并分类 → ④ 商机线索推送销售 → ⑤ 孵化/伙伴对象转对应团队 → ⑥ 学员群转长期运营 → ⑦ 改进项落到下批 SOP复盘纪要与改进项待办、学员分类回访台账、推送给销售的商机线索、长期运营交接记录待新建72
ECO-29生态合作伙伴台账、分级与年度评估退出生态伙伴（芯片/信创厂商、开发者团队、高校社团、开源社区、KOL、OPC 商家）完成引入后，需要统一登记、分级给权益、定期评估与退出时启动主责——生态运营专员（当前：待指定）；协同——品牌（当前：待指定）、财务（当前：待指定）、销售对接人（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 入库登记 → ② 分级标准 → ③ 季度分级评审 → ④ 权益兑现跟踪 → ⑤ 年度贡献评估 → ⑥ 升降级/续约/退出决定 → ⑦ 退出收尾 → ⑧ 台账更新生态伙伴台账（含级别、权益、成本、贡献）、年度评估结论、退出收尾记录待新建72
ECO-30线下活动安全预案、报备与现场应急举办生态大会、黑客松、培训开班、沙龙、校园活动等线下活动，尤其人数较多、在外部场馆或通宵进行时启动主责——活动安全负责人（当前：待指定）；协同——行政（当前：待指定）、法务（当前：待指定）、IT/网络（当前：待指定）、品牌（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 规模评估与报备判断 → ② 场地安全条款 → ③ 编制安全预案 → ④ 购买保险 → ⑤ 现场安全分工 → ⑥ 活动前安全检查 → ⑦ 现场突发处置 → ⑧ 事件记录复盘安全预案、报备/许可回执（如需）、保单、现场应急联络表、事件记录待新建180
ECO-31产学研/校企合作立项、协议与成果归属与高校、科研院所共建联合实验室、实习实践基地、横向课题、共建课程，或研究院对外开展合作研发时启动主责——产学研合作专员（当前：待指定）；协同——法务专员（当前：待指定）、研发负责人（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 合作提议登记 → ② 评估立项 → ③ 协议起草（知识产权、署名、保密、经费、学生管理） → ④ 用印签署 → ⑤ 执行与经费拨付 → ⑥ 成果登记与权属申请 → ⑦ 年度评估续约/终止 → ⑧ 归档立项审批、合作协议、成果登记表、年度评估与档案待新建96

BRD 品牌 报送人：何思雨

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
BRD-01产品命名与更名决策新产品或新硬件需要对外名称，已有产品改名，或同一产品对外出现多个叫法、需要统一时启动。范围从候选名开始，到界面、包名、域名、Logo、应用提审、对外口径全部切换完成为止。主责——产品总监（当前：杨萌·推断待确认）；拍板——COO（当前：常元和·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户端/服务端研发（当前：岳阳、邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——品牌负责人（当前：何思雨·推断待确认）① 登记命名需求 → ② 限时征集候选名 → ③ 商标/域名/关键词冲突检索 → ④ 拍板定名 → ⑤ 公告命名决议与禁用旧名 → ⑥ 按改名检查表逐项切换 → ⑦ 发版前扫描旧名并验收 → ⑧ 更新品牌命名表经拍板的《产品命名决议》（中英文名、内部代号、禁用旧名、上架名、适用范围）、全部触点完成切换的改名检查表、更新后的品牌命名表。待新建240
BRD-02品牌视觉（Logo/形象/外观物料）设计评审与源文件取用需要新 Logo、IP 形象或吉祥物、Slogan、高管形象图、定制版机身 Logo/丝印时启动；对外使用公司或产品 Logo、产品外观图时也走本流程。主责——品牌负责人（当前：何思雨·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——UI/UX 设计师（当前：康紫馨·推断待确认）、产品总监（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、IT 运维/采购（当前：杨明学·推断待确认）、生态运营（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 先查品牌素材库 → ② 提视觉需求单 → ③ 设计出 2～3 个方案 → ④ 限时按清单评审 → ⑤ 拍板定稿 → ⑥ 导出全规格源文件入库 → ⑦ 对外使用确认 → ⑧ 版本变更公告定稿视觉稿；品牌素材库中规格齐全的源文件（.ai 非渐变版、SVG、透明 PNG、彩色/黑白、横版/竖版、常用比例）；对外使用确认记录。待新建108
BRD-04产品官网/落地页与下载页上线单个产品（如 LeapAll、LeapCore、行业版）对外发布或大版本更新，需要新建或改版落地页（landing page）、下载页、交付下载页时启动。主责——官网/落地页前端负责人（当前：季学森·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、服务端研发（当前：邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、运营负责人（当前：李凯·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）① 任务简报对齐 → ② 设计资源决策（内部/借调/外包） → ③ 收齐内容包 → ④ 框架稿评审 → ⑤ 开发与预览 → ⑥ 上线检查表验收 → ⑦ 部署并挂接下载 → ⑧ 发版时自动更新下载链接通过验收的线上落地页或下载页（含页脚联系方式、备案号、可用或置灰的下载入口），以及归档的内容包和简报。待新建144
BRD-05公司官网改版与内容更新（含 SEO）公司官网（company-site）改版，或内容变更（招聘页、页脚社媒入口、二维码、证书/资质、硬件规格等）时启动，范围从需求收集到上线，再到上线后的 SEO 和站长平台收录。主责——官网负责人（当前：陈梦琪·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——官网前端开发（当前：季学森·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、运营验收（当前：鲁周毅·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、人事负责人（当前：黄莹·推断待确认）、生态市场条线负责人（当前：许君·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 需求统一进需求池 → ② 官网负责人按批次收口定稿 → ③ 排期并分派设计/开发 → ④ 设计稿评审 → ⑤ 功能分支开发 → ⑥ 预览部署，验收人一次性验收 → ⑦ 上线检查表与生产部署 → ⑧ 上线后 SEO、收录与变更通报已上线并通过检查表的官网版本；需求池中对应需求关闭；SEO 与收录检查报告；官网变更记录。待优化240
BRD-06官网故障响应与迁移公司官网或产品官网打不开、证书失效、首屏加载异常慢、服务器下线，或需要计划迁移托管时启动；包括报障、认领、止血、修复/迁移、恢复通报和复盘。主责——官网运维责任人（当前：丁震宇·推断待确认）；协同——IT 运维/监控（当前：杨明学·推断待确认）、官网内容（当前：陈梦琪、葛家和·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 拨测告警或人员报障 → ② 15 分钟内认领 → ③ 定级初判 → ④ 止血（切 CNAME/回滚/切备用托管） → ⑤ 修复或迁移 → ⑥ 恢复验证 → ⑦ 恢复通报 → ⑧ 复盘并补监控恢复可用的官网；故障记录与通报；需要时出复盘结论和监控、证书提醒补强项。待新建96
BRD-07新媒体账号注册、认证与运营授权开设或接管公司在抖音、小红书、公众号、视频号等平台的账号时启动，包括确定挂靠主体、补齐资质、企业认证（蓝 V）、实名与管理员设置、授权运营人和台账登记。主责——新媒体运营（当前：李宣昊·推断待确认）；协同——新媒体运营（当前：鲁周毅·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、云平台管理员（当前：王皓南、宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——运营负责人（当前：待指定）① 开号申请（平台、用途、主体） → ② 主体与资质核对 → ③ 缺项补齐（ICP、软著、商标、授权书） → ④ 注册并优先做企业主体认证 → ⑤ 绑定公共手机号/邮箱与管理员 → ⑥ 授权运营人 → ⑦ 登记账号台账 → ⑧ 交接或注销完成企业认证、绑定公共联系方式、运营人已授权的公司账号，以及账号台账记录。待新建128
BRD-08新媒体日常内容生产与发布按日或按周为各产品在抖音、小红书、公众号、视频号产出短视频、图文、推文和信息流素材时启动，覆盖选题、制作、审核、定时发布、发布后分发和数据回收。主责——新媒体运营（当前：李宣昊·推断待确认）；协同——内容/视频运营（当前：宫经喜·推断待确认）、产品总监（当前：杨萌·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、销售总监（当前：吴琪·推断待确认）、业务专家（当前：王满·推断待确认）；兜底——运营负责人（当前：待指定）① 月度内容日历 → ② 选题入库并判定转载/改写/原创 → ③ 脚本/文案 → ④ 制作（拍摄、配音、剪辑、图文） → ⑤ 发布前审核 → ⑥ 多平台定时发布 → ⑦ 发布后分发与数据记录 → ⑧ 周复盘调整按日历发布的内容，以及每条内容的数据记录（播放/阅读、互动、留资），作为 BRD-10 周复盘的输入。待优化135
BRD-09事件型宣发稿与新闻稿公司活动、产品发布、培训开班/结课、适配认证通过、厂商联合发布、销售外出参会等“有日期的事件”需要发公众号推文、新闻稿或多平台内容时启动主责——品牌宣发专员（当前：汪家诺·推断待确认）；协同——事件发起方对接人（销售负责人，当前：李鹏为·推断待确认；研究院生态，当前：陈梦琪·推断待确认）、内容撰稿（当前：陈芷青、徐沛、吴琪·推断待确认）、研发技术核对人（当前：李子遥、丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 事件报备 → ② 判定是否发稿及渠道 → ③ 收集素材 → ④ AI 初稿与排版 → ⑤ 技术/事实核查 → ⑥ 审核定稿 → ⑦ 预览发布 → ⑧ 分发与归档已发布的推文/新闻稿（各平台链接）、事实核查记录、带版本号的终稿与素材包归档待优化240
BRD-10新媒体周数据复盘每周五对公司各新媒体平台账号（当前 3 个平台、6 个账号）做数据汇总、分析表现，并在周例会上确定下周选题与计划主责——新媒体运营（当前：李宣昊·推断待确认）；协同——产品/业务负责人（当前：杨萌·推断待确认）、管理层（当前：常元和·推断待确认）；兜底——运营负责人（当前：待指定）① 拉取各平台数据 → ② 填周数据表 → ③ 写分析 → ④ 周例会回顾 → ⑤ 定下周选题与计划 → ⑥ 知识库归档与月度汇总周数据表、《新媒体周情况总结和新规划》文档、月度汇总（知识库）已有24
BRD-11宣传视频制作与多版本审核大会播放视频、产品介绍视频、数字人视频、周年宣传片/TVC、领导访谈等视频需求，或研发用 AI 生成的演示视频/素材想对外使用时启动主责——运营部视频负责人（当前：鲁周毅·推断待确认）；协同——新媒体运营（当前：李宣昊·推断待确认）、导演/剪辑（当前：宫经喜·推断待确认）、需求方（当前：许君、杨萌·推断待确认）、研发画面保密审核（当前：丁震宇·推断待确认）、行政（当前：胡则瑾·推断待确认）；兜底——运营负责人（当前：待指定）；重大视频终审——CEO（当前：邴龙志·推断待确认）① 需求提报 → ② 评估排期并登记视频总清单 → ③ 脚本/分镜确认 → ④ 素材与授权收集 → ⑤ 制作初版 → ⑥ 版本评审 → ⑦ 合规自查与终审 → ⑧ 发布交付与归档定稿视频（各版本规格）、视频总清单记录、评审意见记录、肖像/声音授权书、源文件与提示词归档待优化300
BRD-12媒体采访与外部拍摄接待及对外口径国家级/地方电视台、报社记者等到访采访、拍摄、踩点或补拍，需要对内预告、选定受访人与演示内容、统一对外数据与说法、现场接待并回收素材时启动主责——媒体对接人（运营，当前：李凯·推断待确认）；协同——综合部/行政（当前：赵雪冰、胡则瑾·推断待确认）、技术统筹（当前：王皓南·推断待确认）、研发保密与技术口径（当前：丁震宇·推断待确认）、媒体口径审定（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）；重大来访由 CEO（当前：邴龙志·推断待确认）兜底① 邀约登记 → ② 评估分级并定筹备组 → ③ 对内预告 → ④ 口径与受访稿 → ⑤ 演示与场地准备 → ⑥ 现场接待 → ⑦ 素材回收与发布前审看 → ⑧ 复盘归档媒体来访登记记录、审定的受访稿与口径 Q&A、演示兜底视频、现场素材与报道链接、复盘记录待新建375
BRD-13宣传物料（海报/折页/手册/PPT）制作与校对销售、活动、新产品或行业版需要海报、三折页、产品手册、宣讲 PPT、产品能力图、FAQ 话术手册、商城上架说明、官网/公众号板块内容等对外物料时启动主责——品牌物料统筹（当前：鲁周毅·推断待确认）；协同——需求方（销售/市场，当前：李鹏为、吴琪、闫登辉·推断待确认）、产品内容与口径（当前：杨萌·推断待确认）、技术表述审核（当前：丁震宇·推断待确认）、文案撰写（当前：陈梦琪、吴琪·推断待确认）、校对（当前：宋祺睿·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 需求提报 → ② 排期分派 → ③ 内容收集 → ④ 统稿出文案 → ⑤ 技术/口径审核 → ⑥ 设计制作 → ⑦ 校对与终审 → ⑧ 版本归档发布定稿物料（源文件 + 导出文件）、物料版本表记录、统一存放的物料库待优化192
BRD-14对外口径、品牌用语与发布前合规自查任何对外推广、市场/销售回答客户问题、视频/文案/页面发布前，需要统一品牌名与话术，并检查敏感词、竞品/第三方标识、版本信息、环境链接及数据安全/模型来源等说法时适用主责——品牌口径维护人（当前：李凯·推断待确认）；协同——品牌与命名决策（当前：常元和·推断待确认）、技术口径（当前：丁震宇·推断待确认）、发布前审看（当前：宋祺睿、张东郅·推断待确认）、素材取舍决策（当前：杨萌·推断待确认）、销售话术使用方（当前：杨朋伟·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 建品牌与话术库 → ② 管理层与法务审定 → ③ 发布并培训 → ④ 发布前作者自查 → ⑤ AI 初筛 → ⑥ 人工复核与终审 → ⑦ 新问题入库 → ⑧ 定期更新《品牌与对外话术库》（含产品规范名、标准 Q&A、禁用词、正式链接入口、logo/模板）、发布前合规自查记录待新建300
BRD-15客户案例与白皮书收集及授权核查签单/交付验收后沉淀客户案例，或市场、销售需要案例做手册、PPT、视频、白皮书、推文、演示机内容，或 FDE 产出场景化案例/演示 Skill 需要转化为对外内容时启动主责——市场案例管理（当前：闫登辉·推断待确认）；协同——市场把关（当前：李鹏为·推断待确认）、FDE 案例产出（当前：李凯、黄振锋、佘天禾·推断待确认）、内容转化（当前：韩诗琪、许君·推断待确认）、优先级协调（当前：常元和·推断待确认）、技术支持（当前：丁震宇、杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 结项触发案例入库 → ② 填案例卡 → ③ 授权核查与分级 → ④ 入市场知识库 → ⑤ 内容转化需求提报 → ⑥ 撰写/录制 → ⑦ 发布前授权过滤与审核 → ⑧ 发布与季度盘点带授权等级的案例库（多维表格 + 市场知识库）、案例集/白皮书/推文/演示素材、授权确认记录待优化180
BRD-16竞品对比评测与素材产出产品实测出性能/成本优势，或需要与竞品（豆包、Kimi、ZCode 等）做同任务对比，并把结果转化为推文、演示和销售素材时启动；研发日常实测发现可用对比素材时也按本流程沉淀主责——竞品评测统筹（产品，当前：杨萌·推断待确认）；协同——评测执行（当前：李慧珍、陈芷青、陈震、黄飞鹏·推断待确认）、研发实测（当前：岳阳、王皓南·推断待确认）、技术判断（当前：丁震宇·推断待确认）、销售/对外使用（当前：闫登辉·推断待确认）、市场运营（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 选题与评测方案 → ② 审核范围 → ③ 同任务实测与取证 → ④ 整理对比文档 → ⑤ 评审（无优势则反馈产品）→ ⑥ 合规自查 → ⑦ 入竞品对比库 → ⑧ 转化素材与定期复测竞品评测文档（结论先行、图表、录屏截图）、竞品对比库记录、可对外使用的对比素材待新建72
BRD-17品牌素材库与对外资料库维护申报、论坛、市场、销售、官网/新媒体需要产品图、渲染图、演示视频、手册截图、合影、Logo、二维码、产品介绍（topic）、Q&A 等素材时，统一从素材库调取；新素材产生或旧素材过期时，按版本入库和更新主责——品牌素材库管理员（品牌岗）（当前：陈梦琪·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、总经办（当前：赵雪冰·推断待确认）、销售对外资料整理人（当前：闫登辉·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、官网仓库维护研发（当前：宋祺睿·推断待确认）、新媒体运营（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 素材分类与责任人认领 → ② 新素材入库（脱敏+打标签+标版本）→ ③ 需求方按目录自助调取 → ④ 库中缺失时提素材需求任务 → ⑤ 责任人补齐并回填入库 → ⑥ 每周五过期检查 → ⑦ 每月盘点缺失与下架一个唯一入口的品牌素材库与对外资料库（产品信息总表 + 分类素材目录），每条素材有责任人、版本日期、可否对外标记；素材需求全部有任务记录并回填入库待优化180
BRD-18品牌舆情监测与危机公关处置社交媒体、新闻媒体、开源社区、招聘平台或用户群出现针对公司、产品、高管的负面内容、事故曝光或不实信息时启动主责——品牌经理（当前：待指定）；协同——法务专员（当前：待指定）、客服/运营对接人（当前：待指定）、事件涉及部门负责人（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 日常监测 → ② 发现上报 → ③ 分级研判 → ④ 事实核查 → ⑤ 口径制定与审批 → ⑥ 回应处置 → ⑦ 持续跟踪 → ⑧ 复盘归档舆情事件登记单、经审批的对外回应口径、处置记录与复盘报告，口径沉淀进对外口径库待新建120
BRD-19宣传素材版权与肖像授权管理宣传视频、推文、海报、手册、PPT 使用外部图片、字体、音乐、视频片段、AI 生成形象，或出现员工、嘉宾、学员、外部人员的肖像与声音时启动主责——品牌设计/内容专员（当前：待指定）；协同——法务专员（当前：待指定）、行政（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 素材来源登记 → ② 版权核查 → ③ 肖像/声音授权签署 → ④ AI 生成内容审核 → ⑤ 发布前清单核对 → ⑥ 授权归档 → ⑦ 到期/撤回下架带来源与授权信息的素材台账、已签署的肖像/声音授权书、发布前核对记录待新建96
BRD-20合作方联合宣发与公司品牌授权使用渠道、生态伙伴、芯片/信创厂商、高校、政府平台要联合发稿、在其宣传中使用公司名称/Logo/产品名，或我方宣传中提及对方时启动主责——品牌经理（当前：待指定）；协同——业务对接人（当前：待指定）、法务专员（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 受理申请 → ② 品牌规范审核 → ③ 合作事实确认 → ④ 法务审核 → ⑤ 双方稿件互审 → ⑥ 发布监测 → ⑦ 授权登记 → ⑧ 合作终止撤下双方确认的联合稿件/物料、品牌使用授权记录（范围、期限）待新建96

POL 政策申报 报送人：王蕊

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
POL-01政策与补贴线索收集研判及申报决策任何人看到或收到政府补贴、扶持政策、人才、就业社保类政策信息时，统一登记进政策线索库，在限定时间内完成适用性初判、决定是否申报及由谁牵头主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总经办专员（当前：王欣·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 线索登记 → ② 去重与 AI 摘要 → ③ 按主体初判适用性 → ④ 分级 P0/P1/P2 → ⑤ 申报决策 → ⑥ 转申报台账并建任务 → ⑦ 放弃/暂缓留痕 → ⑧ 周推送与月复盘政策线索库中每条线索都有结论（申报/放弃/暂缓+复查日），申报项已指定牵头人和截止日并转入申报台账待新建72
POL-02政府部门日常对接与机构设立事项经信局、科创局、财政局等政府部门提出推广、客户清单、标杆案例、繁星计划推进、大会或比赛安排，或公司需新设研究院等机构挂牌时，确定唯一对接人、准备并审核材料、跟进到落地主责——生态市场条线负责人（当前：许君·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、COO（当前：常元和·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 事项登记 → ② 指定唯一对接人 → ③ 确认流程与材料 → ④ 材料编制与脱敏审核 → ⑤ 重大事项决策 → ⑥ 递交与周跟进 → ⑦ 结果归档 → ⑧ 活动复盘政府事项台账中每件事都有对接人、材料清单、进度和结果；机构设立类形成批复/挂牌文件与协议，均已归档待新建240
POL-03申报基础资料库与口径维护各类申报、平台入驻、监管征集、外部核查需要公司基础信息、资质证书、知识产权、人员社保、产品信息、财务口径、历史案例或平台账号时，从统一资料库调取；库里没有的，按固定口径人确认后回写主责——总经办专员（当前：王欣·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建库分工 → ② 填表先查库 → ③ 未命中提口径请求 → ④ 按类别找口径人确认 → ⑤ 回写入库 → ⑥ 人员资格匹配 → ⑦ 有效期与离职预警 → ⑧ 季度更新一套按主体维护的申报资料库（基础信息、资质、知识产权、荣誉、产品、人员资格、财务口径、平台账号索引、案例、历史申报书），每个字段有口径来源和确认人待新建240
POL-04科技项目申报（市/省重点研发、OPC 专项、联合申报）科技局、科技厅、区级部门发布科技项目申报通知，且已决定申报（来自 POL-01）后，从资格核对、牵头主体与负责人确定、分工撰写，到提交、退回修改和结果归档的全过程主责——政策申报专员（当前：王蕊·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、技术配合人（当前：黄振锋·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政专员（当前：侯明月·推断待确认）、CEO（当前：邴龙志·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 立项 → ② 资格条件检查 → ③ 定牵头主体/负责人/方向/金额 → ④ 联合申报协议 → ⑤ 组建写作组与倒排 → ⑥ 撰写与内审 → ⑦ 盖章提交 → ⑧ 退回修改 → ⑨ 结果归档与验收跟踪按时提交的申报书及附件、平台提交回执；退回意见处理记录；立项后的任务书与验收指标进入跟踪待优化500
POL-05人才计划与赛事类申报收到人才计划（招才局、光谷 3551、青年拔尖人才、卓越工程师等）或 AI 大赛申报通知，需要确定推荐人选、评估个人与公司风险、收集个人和项目材料并提交主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、总经办专员（当前：王欣·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 政策解读 → ② 候选人初筛 → ③ 风险评估 → ④ 人选决策 → ⑤ 本人确认 → ⑥ 一次性列清单收材料 → ⑦ 填报审稿 → ⑧ 盖章提交 → ⑨ 结果与后续义务跟踪已提交的人才/赛事申报材料、人选决策记录、本人确认记录、后续义务（承诺期、考核、拨付）跟踪表待新建96
POL-06申报佐证材料（测试/检测/验收报告、指标对比）编制产品认证、成果推荐、科技项目申报或验收、合作方政府项目需要技术指标对比表、测试报告、验收报告、检测报告、安全评测调研表时，基于真实测试结果出具或委托检测，并沉淀为可复用的申报材料包主责——政策申报专员（当前：王蕊·推断待确认）；协同——研发报告编制人（当前：马漳毓·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 需求登记 → ② 查材料包 → ③ 获取对方标准 → ④ 指标表初稿与专业化 → ⑤ 基于真实测试出报告 → ⑥ 真实性与合规审核 → ⑦ 定稿交付 → ⑧ 入材料包经 CTO 审定、基于真实测试记录的报告/指标表，并以版本、有效期、适用范围登记在申报材料包中待新建90
POL-07补贴申领资料归集（上云补贴等）已决定申领上云补贴、上云服务券等费用类补贴后，按主体归集云服务商、上云时间、年消费额、发票、消费主体、消耗记录并提交主责——政策申报专员（当前：王蕊·推断待确认）；协同——云资源管理人（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 确认申领条件 → ② 发起按主体的归集清单 → ③ 导出云账号与账单 → ④ 核对发票与付款 → ⑤ 判断主体一致性 → ⑥ 整理提交 → ⑦ 跟踪拨付入账按主体整理好的补贴申领材料包（云服务清单、账单、发票、付款凭证、消耗记录）与提交回执，补贴到账后入账待新建36
POL-08周期性政府报表与年检填报工信部软件和信息技术服务业月报/年报、LEI 续期、研究院年检等周期性填报到期时，按日历提醒、准备数据、填报、审核并留档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建报表日历 → ② 截止前提醒 → ③ 准备数据 → ④ 口径核对 → ⑤ 填报 → ⑥ 审核 → ⑦ 提交留档 → ⑧ 更新下期按期提交的报表或年检材料、提交截图/回执、数据底稿，报表日历更新到下一期待新建36
POL-09行业/团体标准参编与编制外部机构发起行业标准/团体标准参编征集，或公司受邀、拟牵头编制团体标准时，从评估是否参编到按分工完成稿件提交的全过程主责——标准项目牵头人（当前：吴琪·推断待确认）；协同——技术协调人（当前：杨萌·推断待确认）、技术编写人（当前：郭逸非、黄飞鹏·推断待确认）、外部渠道对接人（当前：李鹏为·推断待确认）、技术评估人（当前：李子遥·推断待确认）、终审人 CTO（当前：丁震宇·推断待确认）、参编决策人 CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 登记标准机会 → ② 核实参编条件 → ③ 评估资质与投入 → ④ 管理层决策（参编/联合/放弃）并指定牵头人 → ⑤ 建群、领分工与模板、开大纲会 → ⑥ AI 起草 + 多模型交叉审 → ⑦ 内部终审 → ⑧ 提交、归档并跟踪发布参编决策记录；按分工完成并经终审的标准章节/附件（docx）及提交回执；「政策/标准机会池」记录更新待新建120
POL-10软件著作权申请与权属确认产品或平台上线、需要证明权属、软件退税或政策申报需要软著时，先确定著作权人（申报主体）、费用承担与合作方关系，再完成材料、盖章、代理提交和取证主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——材料撰写人（各产品线，当前：韩诗琪、葛家和、陈梦琪·推断待确认）、技术与权属把关（当前：丁震宇·推断待确认）、主体与退税判断（当前：常元和·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、盖章环节（当前：杨萌、黄飞鹏·推断待确认）、外部代理机构；兜底——CEO（当前：邴龙志·推断待确认）① 立项登记 → ② 权属确认（著作权人、费用、合作方）→ ③ 按模板写材料包 → ④ 总经办初审 → ⑤ 代理复核 → ⑥ 选对主体用印 → ⑦ 提交缴费 → ⑧ 取证登记并通知登记在正确主体名下的软件著作权登记证书，及知识产权台账中的完整记录（名称、主体、版本、状态、证书号、对接人）待优化192
POL-11专利申报（交底→技术审核→代理撰写→定稿→缴费）研发产生可申请专利的技术方案、核心功能被抄袭需要保护，或公司要求在政策/人才申报前集中出专利时，从技术交底到代理撰写、定稿、缴费完成专利申请提交主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——技术审核（当前：丁震宇·推断待确认）、发明人（各研发组，当前：季学森、宋祺睿·推断待确认）、提案人（当前：杨萌·推断待确认）、专利转让与商务对接（当前：常元和·推断待确认）、外部专利代理机构；兜底——CEO（当前：邴龙志·推断待确认）① 技术成果登记提案 → ② 按模板写交底书 → ③ 内部技术审核（可专利性、泄密、合并/舍弃）→ ④ 邮件提交代理并抄送总经办 → ⑤ 代理撰写初稿 → ⑥ 发明人核稿定稿 → ⑦ 递交与缴费 → ⑧ 台账更新转入审查跟进已递交并取得受理号的专利申请、经内审的交底书、专利台账记录（案号、名称、发明人、状态、下一步责任人、截止日）待优化135
POL-14企业资质认定与年度维护（高新技术企业、科技型中小企业、专精特新等）各主体的企业资质临近到期、年度评价窗口开放，或新主体满足认定条件时启动主责——政策申报专员（当前：待指定）；协同——财务（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）、法务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 建资质日历 → ② 条件自评 → ③ 差距补足 → ④ 材料编制与专项审计 → ⑤ 内审用印 → ⑥ 提交跟踪 → ⑦ 证书入库与优惠落地 → ⑧ 年报与变更报告按期取得/保持的资质证书、年度报告回执、资质日历与资质库更新待新建200
POL-15获批项目执行、专项资金使用与验收结题科技项目、补贴、资助或券类项目获批立项后，至验收结题与事后抽查的全周期主责——项目负责人（当前：待指定）；协同——政策申报专员（当前：待指定）、财务（当前：待指定）、研发（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 签任务书建台账 → ② 设专账 → ③ 资金到账入账 → ④ 按预算执行 → ⑤ 季度跟踪 → ⑥ 中期检查/变更申请 → ⑦ 验收结题 → ⑧ 档案留存项目台账、专项资金辅助账、中期与验收材料、结题证书/验收意见、完整项目档案待新建160
POL-16申报代理/中介机构选用与服务管理决定委托外部机构代办资质认定、项目申报、人才申报、软著/专利或补贴申领，或外部机构主动推销代办服务时启动主责——政策申报专员（当前：待指定）；协同——法务专员（当前：待指定）、财务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 自办/委托判断 → ② 机构资质核查 → ③ 比价选择 → ④ 合同审核 → ⑤ 材料提供与保密 → ⑥ 过程审核 → ⑦ 按结果付款 → ⑧ 年度评价合格机构名录、经法务审核的服务合同、服务评价记录待新建48

MKT 生态市场（其他） 报送人：许君

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
MKT-01外部活动/展会情报收集与参与决策任何人发现外部行业大会、展会、厂商沙龙、黑客松、开发者 Meetup、社区活动或有奖赛事，需要判断公司是否参加、摆摊、赞助或做议题，并在报名截止前完成报名时启动。主责——生态活动运营（当前：陈梦琪·推断待确认）；协同——运营（活动信息订阅，当前：待指定）、比赛/案例组长（当前：白福康·推断待确认）、研发负责人（技术社区活动评估与小额预算，当前：丁震宇·推断待确认）、CEO（参展/参赛主体与超阈值投入拍板，当前：邴龙志·推断待确认）；兜底——生态市场条线负责人① 线索登记 → ② 每周汇总与截止提醒 → ③ 初评分级 → ④ 参与决策与主体确认 → ⑤ 报名/赞助申请 → ⑥ 转执行（MKT-03） → ⑦ 见闻回传归档外部活动台账中每条线索都有“参加/不参加”结论、参与形式、参与主体、负责人和报名状态；决定参加的活动在截止日前完成报名并转入 MKT-03。待新建72
MKT-02发布会立项与预算审批计划举办产品发布会（线上/线下/借外部大会发布）或阶段性加大市场投入时，从动议到立项、产品发布门槛评审、预算审批、对外材料定稿和排期。主责——市场负责人（当前：待指定）；协同——产品总监（产品定义与发布门槛，当前：杨萌·推断待确认）、研发负责人（技术就绪与预算建议，当前：丁震宇·推断待确认）、宣发材料制作（当前：王皓南·推断待确认）、COO（方案与商务，当前：常元和·推断待确认）、运营（当前：待指定）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人① 提出动议 → ② 提交立项单 → ③ 发布门槛评审 → ④ 预算审批 → ⑤ 排期与分工 → ⑥ 产品一页纸与对外材料定稿 → ⑦ 转执行 → ⑧ 发布后复盘经 CEO 审批的发布会立项单（目标、发布内容、预算、排期、负责人）、通过评审的产品一页纸与对外材料、发布后复盘。待新建128
MKT-03参展/大会报名与现场执行统筹已决定参加或举办展会、大会、赛事、沙龙、Meetup 后，从确定参会人和名额、参会审批、票务差旅、展区分工与话术、排班与加班报备，到现场执行、会后复盘与报销的全过程。主责——生态市场总监（当前：许君·推断待确认）；协同——会务/生态活动运营（当前：陈梦琪·推断待确认）、产品总监（展区与话术，当前：杨萌·推断待确认）、销售（排班与路演，当前：刘昱潇、闫登辉、杜中瑞、时建、杨朋伟·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、行政（票务与差旅，当前：侯明月·推断待确认）、人事（加班审批与招聘物料，当前：待指定）、财务（报销，当前：待指定）；兜底——CEO① 建活动任务并指定负责人 → ② 确定参会人与名额 → ③ 参会审批 → ④ 报名信息与票务差旅 → ⑤ 展区分工/话术/物料/演示准备 → ⑥ 排班与加班报备 → ⑦ 现场执行 → ⑧ 会后复盘与报销活动执行台账（人员、排班、物料、演示、预算）、参会审批单、展区话术文档、现场线索表（转 MKT-07）、复盘纪要、按口径完成的报销。待新建300
MKT-04自办渠道大会邀请与授牌确认公司自办渠道合作伙伴大会、行业沙龙、FDE 开班等需要邀请外部企业的正式活动前，汇总邀请名单、确认签约/授牌/上台对象、发放邀请函，并在改期时同步。主责——销售运营（当前：韩诗琪·推断待确认）；协同——各销售（邀约与填报，当前：杜中瑞、吴琪等·推断待确认）、会务（当前：陈梦琪·推断待确认）、法务（授牌协议，当前：待指定）；审核——生态市场总监（当前：许君·推断待确认）；任务下达——销售负责人（当前：李鹏为·推断待确认）；兜底——销售负责人① 定日期与邀约指标 → ② 发布名单表（必填校验） → ③ 销售填报 → ④ 截止收口 → ⑤ 名称与授牌/上台核对 → ⑥ 审核定版 → ⑦ 发邀请函与回执 → ⑧ 改期同步与会前终版审核定版的邀请名单（企业全称、简称、联系人、是否签约/授牌/上台）、邀请函回执、授牌与上台清单（交会务和现场执行 MKT-03）。待优化120
MKT-05展会/大会/发布会演示环境与设备准备展会、大会、发布会、渠道大会或客户现场需要产品演示时，准备演示场景与脚本、演示版本与环境、数据与账号、录屏兜底、设备运输与网络、产研现场支持，结束后回收硬件。主责——产品总监（演示统筹，当前：杨萌·推断待确认）；协同——演示设计（当前：王皓南·推断待确认）、环境与数据（当前：宋祺睿、杨云峰·推断待确认）、硬件与网络（当前：杨明学、游家豪·推断待确认）、测试（当前：张东郅·推断待确认）、客户端演示版（当前：岳阳、李铭熙·推断待确认）、现场演示人（当前：闫登辉、吴琪、王满、胡橙橙·推断待确认）；决策——研发负责人兼 CTO（当前：丁震宇·推断待确认）；兜底——研发负责人兼 CTO① 演示需求单 → ② 场景与脚本 → ③ 演示版本冻结与环境/账号/额度 → ④ 设备与网络 → ⑤ 素材合规审查与录屏兜底 → ⑥ 冒烟测试、彩排与培训 → ⑦ 现场 oncall → ⑧ 硬件回收与复盘演示准备清单全部勾选（脚本、冻结版本、独立演示环境、账号与额度、设备、网络备份、录屏视频、负责人）、彩排记录、硬件回收登记与演示复盘。待新建240
MKT-06活动物料与礼品制作及回收活动或摆摊前需要备齐易拉宝、海报、传单、贴纸、二维码、积分卡、抽奖礼品、3D 打印礼品等，从需求、出稿、校对、采购打印或分工制作，到带去现场、活动后归还入库与费用报销。主责——行政（物料制作与采购，当前：侯明月·推断待确认）；协同——活动负责人（提需求，当前：杨萌、陈梦琪·推断待确认）、设计出稿（当前：王皓南·推断待确认）、审稿与预算（当前：丁震宇·推断待确认）、人事（招聘二维码，当前：黄莹·推断待确认）、制作联系（当前：潘浩伟·推断待确认）、3D 打印小组（当前：葛家和、吴世豪、宋祺睿、杨明学·推断待确认）、抽奖环节（当前：葛家和·推断待确认）、财务（当前：待指定）；兜底——行政负责人① 提物料需求单 → ② 按模板出稿 → ③ 校对审稿 → ④ 比价下单或分工制作 → ⑤ 验收清点入库 → ⑥ 出库带往现场 → ⑦ 活动后归还入库 → ⑧ 费用报销按时到场且无错误的活动物料与礼品、物料出入库登记、电子版终稿归档在物料库、费用报销单。待新建108
MKT-07活动后线索跟进与转化复盘参加展会、沙龙、座谈会、数转活动、线下 Meetup 或抽奖/扫码引流活动后，统一录入线索、分配跟进、统计转化并复盘活动价值。主责——生态活动运营（活动复盘负责人，当前：陈梦琪·推断待确认）；协同——CRM 管理员（线索录入与分配，当前：闫登辉·推断待确认）、参会销售（跟进，当前：陈名赞、时建、杜中瑞·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营（公司号与社群，当前：待指定）；兜底——销售负责人① 活动前定目标客户画像 → ② 统一引流码与线索表单 → ③ 现场采集 → ④ 24 小时内入 CRM 并分配 → ⑤ 3 个工作日内首次跟进 → ⑥ 拜访/拉群 → ⑦ 活动复盘 → ⑧ 月度转化统计CRM 中带活动来源标记的线索（含分配人、跟进状态）、单场活动复盘（线索数、匹配度、转化）、月度活动渠道 ROI 统计。待新建135
MKT-08外部布道/分享活动接单与讲师分工高校社群、政府部门、团委、国企、中小企业服务机构、OPC 社群等主办方邀请公司做技术/产品分享（如 OpenClaw 布道）时，从接单登记、评估场次、指派讲师、向主办方报题目与讲师简介，到现场分享、引流和复盘。主责——布道活动对接人（当前：李鹏为·推断待确认）；协同——布道统筹（定策略、选讲师、内容 review，当前：丁震宇·推断待确认）、讲师（当前：李子遥、望政韬、马漳毓·推断待确认）、活动线索提供人（当前：邴龙志、闫登辉、杨朋伟·推断待确认）、品牌（讲师简介库，当前：待指定）、法务（当前：待指定）；兜底——生态市场条线负责人① 主办方填需求单 → ② 登记布道场次台账并定目的 → ③ 评估是否接 → ④ 指派主讲/辅助 → ⑤ 从简介库选定讲师简介并经本人确认 → ⑥ 报题目与简介给主办方 → ⑦ 准备与内容 review → ⑧ 现场分享与引流 → ⑨ 复盘布道场次台账中每场都有主办方需求、目的、主讲/辅助、经本人确认的简介、PPT 版本、效果与线索；对外讲师头衔口径统一、真实。待新建180
MKT-09演讲/布道 PPT 与演示素材制作、评审及外发布道/分享场次与讲师已确定，或 CEO/高管受邀在外部峰会、大会演讲，需要按听众做一版 PPT（含讲稿、演示 Demo），评审定版交主办方；主办方要求提前拿材料时按水印 PDF 外发主责——布道/演讲材料负责人（当前：李子遥·推断待确认）；协同——峰会演讲材料执行（当前：许君·推断待确认）、讲师（当前：望政韬、马漳毓·推断待确认）、技术口径评审（当前：丁震宇、王皓南·推断待确认）、演示素材录制（当前：邓乾、张康、宋祺睿·推断待确认）、视频剪辑（当前：宫经喜·推断待确认）、主办方对接（当前：李鹏为·推断待确认）、现场设备调试（当前：侯明月·推断待确认）；兜底——生态市场条线负责人① 登记场次与听众 → ② 从母版库出初稿 → ③ 选取/补录 Demo 素材 → ④ 内容与技术口径评审 → ⑤ 定版并配讲稿/提词器 → ⑥ 现场试放彩排 → ⑦ 按需水印 PDF 外发 → ⑧ 回收归档到母版与 Demo 库定版 PPT（含备注讲稿）、演示视频/Demo、提词器版本、外发用水印 PDF、更新后的母版库与 Demo 库条目待优化180
MKT-10客户来访接待与演示客户、合作方来武汉考察交流，需要安排行程、场地、议程、席卡订餐、演示环境，并在会后形成纪要和跟进事项主责——销售总监/客户经理（当前：吴琪·推断待确认）；协同——渠道/演示负责人（当前：闫登辉·推断待确认）、业务专家演示（当前：王满·推断待确认）、会议与场地协助（当前：刘昱潇·推断待确认）、行政/展厅（当前：待指定）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 来访登记（时间、人数、名单、目的） → ② 确认场地（会议室/展厅） → ③ 定议程与我方参会人 → ④ 席卡、订餐、接送 → ⑤ 演示环境准备与预演 → ⑥ 接待执行 → ⑦ 会后纪要与跟进任务来访接待单、议程、席卡与餐饮安排、可用的演示环境、会议纪要与跟进任务待新建135
MKT-11演示机/试用机准备与分配管理市场、销售或渠道商需要一台演示机或试用/试销机（豪华演示机、工程版演示机、渠道试用机），需从申请、配置硬件软件网络到交付、登记去向和回收全程管理（非正式客户交付）主责——市场样机管理员（当前：陈芷青·推断待确认）；协同——市场需求负责人（当前：杨萌·推断待确认）、硬件/网络/账号（当前：游家豪·推断待确认）、软件与模型对接及资产（当前：杨明学·推断待确认）、渠道需求提单（当前：刘昱潇·推断待确认）、规格审批（当前：丁震宇·推断待确认）、现场协助（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 提申请（用途/规格/接收人/期限） → ② 规格确认与审批 → ③ 硬件准备 → ④ 网络接入 → ⑤ 软件模型配置与开账号 → ⑥ 账密托管 → ⑦ 交付给提单人并登记台账 → ⑧ 流转登记、到期回收与盘点可用的演示/试用机、演示机台账记录（编号、机器码、网段、管理员、去向）、交接单、回收记录待新建96
MKT-12外部合作与政府需求线索接收及分派外部公司、硬件厂商、电商渠道或政府部门联系我方谈合作、要培训方案或接待安排，需统一接收、指派对接人、安排试用，进入方案阶段后由单一负责人出方案 PPT 并统一口径主责——生态市场线索接口人（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、产品负责人/试用安排（当前：杨萌·推断待确认）、创始人兼 CTO/技术口径（当前：丁震宇·推断待确认）、运营/FDE（当前：李凯·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 任何人收到即登记转交 → ② 分类 → ③ 按路由表指派对接人 → ④ 首次联系与材料互换 → ⑤ 需要时安排试用 → ⑥ 方案阶段单人出方案与口径 → ⑦ 评审后对外提交 → ⑧ 结果写入 CRM合作线索登记记录、指派结果、首次沟通纪要、（如需）试用开通、合作方案/培训方案 PPT、CRM 跟进记录待新建60
MKT-13第三方平台/商城上架与消费券推广政府或第三方平台（武创通 AI 商城、OPC 社区商城、超算互联网商城）开放入驻、统一批次上架、征集活动厂商或发放体验券批次时，准备商品信息与合规文案、录入卡密、上架，并推动内部及用户领券购买主责——外部平台上架对接人（当前：杨萌·推断待确认）；协同——OPC 社区运营（当前：陈梦琪·推断待确认）、政策口径（当前：邴龙志·推断待确认）、研发/卡密与说明（当前：邓乾·推断待确认）、商城后端（当前：葛家和·推断待确认）、运营答疑与问卷（当前：胡橙橙·推断待确认）、宣发策略（当前：李凯·推断待确认）、平台入驻材料（当前：闫登辉·推断待确认）、平台通知转发（当前：宋祺睿·推断待确认）、新员工通知（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人① 平台通知登记并指定响应人 → ② 参与决策 → ③ 入驻材料 → ④ 商品信息与合规预审 → ⑤ 价格档位与卡密导入 → ⑥ 平台就绪检查后上架 → ⑦ 购买指南与 FAQ 发布 → ⑧ 领券推广答疑 → ⑨ 批次复盘已上架商品（名称合规、说明齐全、卡密到位）、购买指南与 FAQ、领券推广通知、问卷与销量汇总待优化180
MKT-14营销活动与裂变玩法策划及合规审批产品进入拉新或推广阶段，有人提出营销创意（砍一刀、拼车、大赛、校园大使/代理、KOL、赛事合作等），需要统一提报、细化方案与预算、合规把关、审批后执行并复盘；赛事主办方或校园大使索要算力券/API 额度时按权益菜单审批主责——运营负责人（当前：李凯·推断待确认）；协同——KOL/渠道运营（当前：胡橙橙·推断待确认）、校园地推方案（当前：刘昱潇·推断待确认）、校园大使与赛事合作（当前：陈梦琪·推断待确认）、渠道运营（当前：杨朋伟·推断待确认）、风控/防刷（当前：陈晖·推断待确认）、营销合规提醒（当前：李鹏为·推断待确认）、策略与技术可行性（当前：丁震宇·推断待确认）、预算审批（当前：邴龙志·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人① 点子入池 → ② 每周初筛 → ③ 细化活动策划卡 → ④ 合规评审 → ⑤ 预算与权益审批 → ⑥ 排期执行 → ⑦ 发放登记与对账 → ⑧ 复盘审批通过的活动策划卡、合规评审意见、预算/权益审批单、发放与对账记录、活动复盘报告待新建180
MKT-15推广投放预算审批与效果复盘运营或外部代理商提出投流、KOC、自媒体推广方案时，完成成本审核与预算审批、素材评审、上线投放、每周效果报告，预算耗尽或周期结束后复盘决定是否续投主责——跃竞业务负责人（当前：徐莉·推断待确认）；协同——内容/投放运营（当前：宫经喜·推断待确认）、销售/市场（当前：黄捷·推断待确认）、代理商方案审核（当前：杨萌、李鹏为·推断待确认）、关联业务方审批（当前：刘恒昊·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提投放方案 → ② 成本审核与比价 → ③ 预算审批 → ④ 素材评审 → ⑤ 上线投放 → ⑥ 每周效果报告 → ⑦ 预算耗尽/周期结束复盘 → ⑧ 决定续投、调整或停止审批通过的投放方案与预算单、评审过的素材、每周投放效果报告、复盘纪要与唯一负责人的待办清单待优化144
MKT-16产品版本更新向市场/销售同步新版本上线前或产品有可分享的新能力时，按“开发一版、预告一版、发布一版”向市场和销售同步新功能与 UI 变化，组织内部分享（脱敏），并准备可直接对外使用的材料主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、发版负责人（当前：宋祺睿·推断待确认）、内部分享主讲（当前：刘昱潇·推断待确认）、演示环境（当前：望政韬·推断待确认）、OPC/推文对接（当前：陈梦琪·推断待确认）、市场销售接收人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 版本规划时登记同步排期 → ② 发布前写市场版发布说明 → ③ 周一市场会预告并机器人提醒 → ④ 内测期准备售卖材料 → ⑤ 内部分享前脱敏与内容评审 → ⑥ 发布当天正式同步 → ⑦ 收集市场反馈 → ⑧ 对外推文经脱敏与口径审核市场版发布说明（新功能、UI 变化、话术、截图/视频）、预告记录、售卖材料、脱敏后的分享回放、市场反馈记录待优化72
MKT-17市场产品反馈汇总交接市场部在一个迭代周期内从客户、渠道、展会、演示、试用中收集到产品反馈，需要在产品排下一迭代前统一整理、交给产品负责人做优先级判断时启动主责——市场专员/销售运营（当前：韩诗琪·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/渠道对接人（当前：待指定）；兜底——生态市场条线负责人① 日常登记反馈 → ② 迭代前截止汇总 → ③ 去重归类（AI 初分）→ ④ 市场负责人复核 → ⑤ 交接给产品 → ⑥ 产品逐条给结论并排期 → ⑦ 结论回告市场与反馈人一份按固定模板整理、已去重归类的《产品反馈交接表》，以及产品对每条反馈的处理结论（纳入迭代/进需求池/不做及原因），并回告到原反馈渠道待优化72
MKT-18市场运营日报与沟通记录规范市场、运营、销售支持成员（含新入组成员与实习生）每个工作日下班前提交日报（部门群模板、多维表格或飞书汇报模块），为周例会和阶段复盘提供依据；以及市场条线与客户、渠道发生沟通（尤其在微信上）后，需要把关键信息沉淀到飞书/CRM 时启动主责——市场运营团队负责人（由鼎慧负责人/产品总监兼任，当前：杨萌·推断待确认）；协同——市场/运营/销售成员（当前：李宣昊、王满、吴琪、闫登辉、王皓南及运营实习生·推断待确认）、飞书与 AI 工具支持（当前：丁震宇、张东郅·推断待确认）；兜底——生态市场条线负责人；制度拍板——CEO（当前：邴龙志·推断待确认）① 发布日报规则与模板 → ② 当日沟通即时记入飞书/CRM → ③ 下班前按模板提交日报 → ④ 机器人截止前提醒、截止后汇总 → ⑤ 负责人次日上午回应协助项 → ⑥ 每周 AI 生成周报 → ⑦ 周会复盘 → ⑧ 月度抽查沟通记录完整性 → ⑨ 试行期满评估调整每日结构化日报记录（今日完成/明日计划/需要协助）、AI 生成的周报、客户沟通关键内容在飞书/CRM 中可检索的记录、试行评估结论待优化90
MKT-19市场年度计划、预算编制与费用执行跟踪每年末编制下一年度市场计划与预算，季度分解滚动，并按月跟踪市场费用执行时启动主责——市场经理（当前：待指定）；协同——品牌、研究院生态、销售负责人（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）① 收集目标 → ② 编制市场日历与预算 → ③ CEO 审批 → ④ 季度分解 → ⑤ 活动按预算立项占用 → ⑥ 月度执行台账 → ⑦ 超预算审批 → ⑧ 季度投入产出复盘经审批的年度市场计划与预算、月度费用执行台账、季度投入产出复盘待新建144
MKT-20市场活动与线索个人信息收集使用合规活动报名表、问卷、培训班报名、展会扫码、名片、线索名单、短信/电话邀约，以及把名单共享给渠道、外包或合作方时启动主责——市场经理（当前：待指定）；协同——法务专员（当前：待指定）、安全/IT 管理员（当前：待指定）、研究院生态与销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）① 表单告知同意 → ② 最小必要收集 → ③ 公司工具存储与权限 → ④ 合规使用（邀约/营销） → ⑤ 对外共享审批 → ⑥ 到期删除 → ⑦ 撤回与投诉处理 → ⑧ 年度自查法务审定的报名/问卷模板、个人信息名单登记台账、共享审批与删除记录待新建160

SAL 销售 报送人：许君、李鹏为

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
SAL-01主动获客（社群/短视频/私域/冷邮件）销售/获客人员每天在抖音、小红书、kook、B站、公众号、微信私域或海外邮件上主动联系目标客户，要把联系结果变成可跟进的线索并约到演示时启动主责——获客专员（当前：刘安达·推断待确认）；协同——线索工具研发（当前：张楠、魏小东·推断待确认）、内容/商户运营（当前：宫经喜·推断待确认）、商机跟进销售（当前：待指定）、法务负责人（当前：待指定）；兜底——跃竞业务线负责人（当前：徐莉·推断待确认）① 定目标客群与渠道配额 → ② 养号与内容触达 → ③ 线索工具抓取+AI 二筛 → ④ 私信/加微信建联 → ⑤ 线索当日入库分级 → ⑥ 预约演示 → ⑦ 演示后 24 小时内填反馈 → ⑧ 日报按漏斗口径汇报与周复盘线索库中带来源、阶段、下次跟进时间的有效线索；已完成的演示记录与反馈；按漏斗口径（触达→建联→有效线索→演示→入驻/成交）统计的获客日报待优化225
SAL-02入站线索接入、背调与分发认领官网预约演示/定价页申请、陌生来电、公众号咨询、介绍人引荐、布道分享后的政企听众、高管转来的客户资源、外部转介绍与培训班名单等“对方找上门”的线索出现，需要登记、甄别、分给唯一销售并首次联系时启动主责——线索中台管理员（当前：许君·推断待确认）；协同——线索分发专员（当前：侯明月·推断待确认）、销售负责人（当前：李鹏为·推断待确认，认领规则与复盘）、各销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）、CTO（当前：丁震宇·推断待确认，技术类线索分派）、跃竞负责人（当前：徐莉·推断待确认，跃竞官网线索）、官网线索机器人研发（当前：张楠·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 各入口线索统一登记进线索池 → ② 机器人推送卡片 → ③ 甄别背调（真客户/渠道/推销/测试）→ ④ 分级 P0～P2 → ⑤ 认领或指派唯一负责人 → ⑥ 12 小时内首次联系 → ⑦ 跟进记录入 CRM → ⑧ 超时回收与 P0 未转化复盘线索池中每条入站线索都有来源、甄别结论、等级、唯一负责销售、首次联系时间和跟进记录；每周线索盘点与 P0 未转化复盘待优化180
SAL-03商机甄别、可行性初筛与赢丢单复盘新商机或外部需求（标准 B 端项目、伙伴转介客户、熟人介绍的 Demo/MVP 小单、外部培训、外部技术撮合）出现，在投入方案、报价、研发之前判断“能不能做、值不值得做、谁来做”；商机赢单、丢单或卡住后做复盘主责——销售负责人（当前：李鹏为·推断待确认）；协同——商机负责销售（当前：闫登辉、吴琪、刘昱潇、时建、杜中瑞·推断待确认）、CTO（当前：丁震宇·推断待确认，技术可行性与优先级）、FDE Leader（当前：黄振锋·推断待确认，技术信息收集）、CEO（当前：邴龙志·推断待确认，战略取舍）、法务/财务负责人（当前：待指定，外部小单合同与收款）；兜底——CEO（当前：邴龙志·推断待确认）① CRM 登记商机与需求原文 → ② 发客户信息收集清单 → ③ 五项甄别（预算/决策链/时间/标品匹配/竞争）→ ④ 技术可行性与定制比例评估 → ⑤ 分级 A/B/C 并决定跟进、放弃或转介 → ⑥ 立项推进或礼貌退出 → ⑦ 赢丢单复盘与月度规则更新CRM 中每个商机带评估结论（等级、是否立项、理由、审批人）；已填的客户信息收集清单；赢丢单复盘记录与月度复盘结论待新建320
SAL-04CRM 客户/商机录入与维护出现新客户、线索、商机、合同或渠道，每次拜访/沟通之后，每周周报之前，台账缺失需要补录，CRM 切换过渡期，新人要开 CRM 账号，或试用客户充值需要登记时主责——CRM 管理员（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，口径与督办）、销售台账维护（当前：汪家诺·推断待确认）、CRM 研发（当前：郭逸非·推断待确认）、CRM 部署（当前：杨睿·推断待确认）、系统管理员（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认，绩效挂钩规则）、各销售（录入）；兜底——销售负责人（当前：李鹏为·推断待确认）① 开通账号与角色 → ② 企查查全称查重 → ③ 线索进公海池、商机按规范命名 → ④ 每次沟通后 24 小时内记跟进 → ⑤ 赢单上传合同并生成订单 → ⑥ 每周五机器人查缺补漏 → ⑦ 每月与合同台账、回款核对 → ⑧ 考核只取 CRM 数据CRM 中客户唯一、负责人唯一、商机阶段与金额准确、跟进记录完整、合同与订单可关联；每周未更新清单；每月数据质量报告待优化180
SAL-05客户拜访与会议纪要记录、信息同步与客户、渠道、合作方或政府单位完成拜访、会议、饭局、展会交流，或需求/验收/售后沟通之后，需要把结论、承诺、下一步留痕并同步给内部相关人时启动主责——商机负责销售（当前：吴琪、时建、杜中瑞、陈名赞·推断待确认）；协同——销售运营（当前：韩诗琪·推断待确认，纪要汇总表维护）、重大项目总负责人（当前：时建·推断待确认）、生态市场总监（当前：许君·推断待确认，汇总表口径）、产品负责人（当前：杨萌·推断待确认，客户信息表）、CTO（当前：丁震宇·推断待确认，客户沟通留痕规则）、CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 建日程时定记录人并默认录制 → ② 会中录制/妙记 → ③ 会后 24 小时内发纪要（3～5 句结论+承诺+下一步）→ ④ 写入 CRM 跟进与客户档案 → ⑤ 下一步转飞书任务 → ⑥ 同步销售群或项目群 → ⑦ 每周汇总与回访统一模板的会议纪要、CRM 跟进记录、客户档案（售后文档）更新、带负责人和截止日期的待办、每周纪要汇总表待优化120
SAL-06重点商机上报与大客户分级推进销售发现客户有强烈购买意向，或商机金额较大、客户为集团/国企/政府/行业头部等战略客户，需要上报、分级、拉齐公司资源，并按节点推进到签约时启动主责——销售负责人（当前：李鹏为·推断待确认）；协同——项目负责销售（当前：闫登辉、刘昱潇、吴琪、杨朋伟、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，方案审核与产品/定价判断）、COO（当前：常元和·推断待确认，统一口径与 CRM 督促）、产品负责人（当前：杨萌·推断待确认，需求对齐与 Demo）、CEO（当前：邴龙志·推断待确认，资源决策）；兜底——CEO（当前：邴龙志·推断待确认）① 填表上报重点商机 → ② 分级 A/B/C → ③ 项目启动会（目标、分工、里程碑、口径、价格边界）→ ④ 需求对齐 → ⑤ Demo/方案并审核 → ⑥ 报价与合同 → ⑦ 每周更新看板、周会汇报 → ⑧ 卡点升级 → ⑨ 签约转交付或丢单复盘重点项目看板（阶段、下一步、卡点、需支持人）、启动会纪要与分工、每周进展、签约合同或明确的放弃结论待优化300
SAL-07政企客户需求对接与方案汇报政府部门（科创、科技、公安等）或国企、国有金融机构提出 AI 建设需求、邀请我方汇报，或客户内部上会需要我方提供支撑材料时启动主责——销售负责人（当前：李鹏为·推断待确认）；协同——政企跟进销售（当前：闫登辉、杨朋伟、刘昱潇·推断待确认）、技术方案负责人（当前：王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认，方案评审与口径）、CEO（当前：邴龙志·推断待确认，客户关系与需求）、COO（当前：常元和·推断待确认，统筹与跟进人安排）、FDE/Skill 方案（当前：李凯·推断待确认）、法务负责人（当前：待指定，密级与合规）；兜底——CEO（当前：邴龙志·推断待确认）① 接需求/邀约建任务卡 → ② 摸底（对象角色、密级、部署、经费、算力、时间）→ ③ 定主讲与陪同 → ④ 出方案/白皮书（通俗版+技术附录）→ ⑤ 内部一次性评审 → ⑥ 出发前清单核对与拜访汇报 → ⑦ 会后复盘、报价、跟进 → ⑧ 支撑客户内部上会评审政企客户档案、需求摸底清单、方案/白皮书定稿（含纸质版）、汇报纪要与复盘、客户上会支撑材料（数据分级分类规范、模型选型论证等）、礼品接待审批记录待新建375
SAL-08客户/渠道/合作方来访交流准备与会后复盘客户、渠道商、生态方或合作意向公司来访、线上交流或邀我方上门洽谈（含带技术问题清单来访、套壳/集成合作洽谈），需要会前统一口径和材料、定出席人与技术同席、会后纪要与复盘时启动主责——来访对接人（销售/商务）（当前：时建、闫登辉、杨朋伟·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，判断来意、指派出席人与口径分工）、生态组负责人（产品口径，当前：陈梦琪·推断待确认）、IT 运维（信创/算力口径，当前：杨明学·推断待确认）、技术同席（当前：李铭熙、郭逸非、吴亚军·推断待确认）、会议组织（当前：杨萌·推断待确认）、COO（当前：常元和·推断待确认，高职级出席）；兜底——销售负责人（当前：李鹏为·推断待确认）① 填来访信息卡 → ② 判断来意与披露级别 → ③ 定出席人与 AB 角、发日程（默认录制）→ ④ 会前口径卡与精简讲解/演示 → ⑤ 会前 30 分钟提醒 → ⑥ 会中录制、不当场承诺 → ⑦ 纪要与统一书面答复 → ⑧ 复盘并转跟进来访信息卡、会前口径卡、出席安排（含 AB 角）、会议纪要、对方问题的统一书面答复、复盘清单与跟进任务待新建135
SAL-09售前技术支撑与技术问题统一答复销售接待客户或去客户现场需要技术人员同席、演示视频/案例/资质材料，或客户、渠道在售前阶段集中提出技术问题（含私有化、二次开发、源码、海外交付）时启动主责——售前技术负责人（当前：丁震宇·推断待确认）；协同——销售对接人（当前：闫登辉、杜中瑞·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、技术同席人员/研发（当前：王皓南、宋祺睿·推断待确认）、材料持有人（当前：刘昱潇、李凯·推断待确认）、法务（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 销售提交售前支撑申请 → ② 判断客户意图与支撑方式 → ③ 排班派人/从资料库取材料 → ④ 客户问题整理成文档 → ⑤ 1 个工作日内出统一书面答复 → ⑥ 敏感口径会审 → ⑦ 答复入 FAQ 库写入日历的技术同席安排、发给客户的标准化技术答复文档、更新后的售前资料库与 FAQ 条目待优化144
SAL-10对外沟通口径统一与对客通知审核客户问部署能力、服务可用性、数据安全、Agent 架构、竞品对比、价格与性能承诺，或与硬件/渠道伙伴做商务沟通，或项目侧准备向客户发布使用政策/通知时，按统一口径答复，对客通知先内部审核主责——对外口径库负责人/产品总监（当前：杨萌·推断待确认）；协同——价格与合同口径归口：市场销售负责人（当前：李鹏为·推断待确认）、硬件口径归口：IT/硬件负责人（当前：杨明学·推断待确认）、技术事实确认：Leap 研发负责人（当前：王皓南·推断待确认）、一线使用人：COO 及销售（当前：常元和、吴琪、刘昱潇、闫登辉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别对外口径问题 → ② 查口径库 → ③ 无现成口径向归口人申请 → ④ 归口人起草（AI 辅助）→ ⑤ 审定后发布入库 → ⑥ 一线按口径对外 → ⑦ 对客通知走内部审核 → ⑧ 冲突复盘并更新分领域的对外口径库（产品/技术/安全、价格/合同、硬件、故障安抚、竞品对比）、经审核的对客通知、口径冲突复盘记录待新建225
SAL-11客户演示准备与执行客户、渠道、政府/评审机构、领导或资本方要看产品演示（现场或远程）时，从接到演示需求到演示后反馈收集全程按本流程走主责——演示统筹人/产品总监（当前：杨萌·推断待确认）；协同——演示申请人/销售及 COO（当前：闫登辉、吴琪、常元和·推断待确认）、技术保障（当前：王皓南、宋祺睿·推断待确认）、测试验证（当前：张东郅·推断待确认）、演示视频制作（当前：杨黔昆·推断待确认）、演示账号安排（当前：李凯·推断待确认）、场景案例梳理（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交演示申请 → ② 定演示人、操作人、技术保障 → ③ 选场景写脚本 → ④ 环境、账号、额度就绪（SAL-12/13）→ ⑤ 按脚本内部预演并录兜底视频 → ⑥ 现场演示 → ⑦ 1 个工作日内登记反馈并复盘演示申请记录、演示脚本与话术、兜底录屏、演示反馈登记（转需求/商机跟进）待优化500
SAL-12演示环境与版本保障（冻结/稳定版/兜底）已确定对外演示（客户现场、远程、发布会、云栖类大会、资本方）后，指定演示环境与稳定版本、在演示窗口冻结更新、准备备用机与网络兜底，演示失败时排查复盘主责——演示环境负责人/产品总监（当前：杨萌·推断待确认）；协同——研发发版负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、客户端与 hotfix（当前：岳阳、马漳毓·推断待确认）、测试（当前：张东郅·推断待确认）、演示机管理（当前：游家豪·推断待确认）、IT 网络与备机（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 演示登记入演示日历 → ② 指定专用演示机/稳定版 → ③ 冻结窗口生效、发版避让 → ④ 推送已知问题与禁用功能 → ⑤ 演示前冒烟检查 → ⑥ 兜底就绪（录屏、备用机、随身网络）→ ⑦ 演示中故障应急 → ⑧ 解冻与复盘演示日历与冻结记录、演示前冒烟检查结果、已知问题清单、兜底包（视频/备用机/网络）、演示事故复盘待新建256
SAL-13演示账号与演示机管理销售、市场、渠道需要演示账号、演示额度/积分券、Demo 访问权限，或借用演示机/样机给客户演示试看时，按申请→分配→登记→回收管理，不暴露管理权限主责——演示资源管理员（当前：闫登辉·推断待确认）；协同——对外演示产品清单维护：产品总监（当前：杨萌·推断待确认）、演示机硬件与在线状态：运维/交付部署工程师（当前：游家豪·推断待确认）、备机与内网接入：IT 运维（当前：杨明学·推断待确认）、演示页/后台账号：后端/运维（当前：宋祺睿·推断待确认）、演示站维护：基座研发负责人（当前：望政韬·推断待确认）、Demo 能否公开确认：苏州销售负责人（当前：刘昱潇·推断待确认）、积分券管理（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交借用/开通申请 → ② 审核用途与权限级别 → ③ 从账号池/演示机台账分配（演示角色，不给管理员）→ ④ 凭据经安全渠道私发并登记 → ⑤ 额度/券按标准发放登记 → ⑥ 到期回收、改密、重置数据 → ⑦ 每月盘点台账演示账号池与演示机台账（编号、持有人、版本、额度、在线状态、借用记录）、对外演示产品清单（可对外/仅内部/需脱敏）待新建144
SAL-14售前 Demo/样稿制作与客户需求转产研意向客户要定制 Demo、接口集成演示、竞品 PK 样稿，或销售需要产研配合做售前交付物时，经统一入口（先找产品）提交，评估后优先复用已有能力，限期交付主责——售前需求入口/产品总监（当前：杨萌·推断待确认）；协同——售前需求方（当前：侯明月、刘昱潇·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Demo 开发/FDE（当前：邓乾·推断待确认）、研发侧技术需求收口人（当前：李铭熙·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、行业能力负责人（当前：白立新·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交售前需求单 → ② 产品 1 个工作日内分诊 → ③ Demo 立项（范围、必备客户材料、交付日）→ ④ 优先复用 Demo 台账与行业工作流 → ⑤ 开发/生成 → ⑥ 内部验收与录屏 → ⑦ 交付客户并收集反馈 → ⑧ 入 Demo 台账已交付的 Demo/样稿（含录屏与说明）、Demo 台账条目、转入正式需求池的需求或拒绝说明待新建144
SAL-15销售物料、标杆案例与知识库建设新品发布、对外材料变更、演示或竞品对比成功产生案例、赢单产生标杆、行业版搭建市场体系，或销售规则/合同模板/渠道协议/价格更新时，把话术、演示场景、竞品对比、案例、行业作战包和规则模板沉淀到销售知识库并保持唯一最新版主责——生态市场总监（当前：许君·推断待确认）；协同——渠道/知识库与白皮书维护（当前：闫登辉·推断待确认）、演示视频合集与技能清单：产品总监（当前：杨萌·推断待确认）、CRM 赢单数据：销售运营（当前：韩诗琪·推断待确认）、行业版负责人（当前：吴琪、杨朋伟、闫登辉·推断待确认）、场景案例：业务专家（当前：王满·推断待确认）、案例认证积分（当前：丁震宇·推断待确认）、体系要求与验收：CEO（当前：邴龙志·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 识别更新事件 → ② 素材提交（案例/话术/视频/客户问题/规则）→ ③ 归口人整理、脱敏与审核 → ④ 发布到知识库“最新版”目录并标版本 → ⑤ 通知群推送并置顶 → ⑥ 销售培训与抽查 → ⑦ 每月清理旧版分类清晰、版本唯一的销售知识库（话术/FAQ、演示场景库与视频合集、竞品对比、标杆案例集、行业版作战包、规则/模板/价格）及更新记录待优化144
SAL-16客户/渠道试用申请审批、开通与转化跟进客户或渠道要求先试用再购买（线上额度试用、演示机带用、样机部署、繁星计划等政府推荐企业试用、渠道试用账号）时，从判断给不给、给多少并审批，到开通、跟进反馈、回访转化或回收主责——试用审批人/市场销售负责人（当前：李鹏为·推断待确认）；协同——试用开通与充值事务：销售运营（当前：韩诗琪·推断待确认）、繁星计划台账：渠道负责人（当前：闫登辉·推断待确认）、带用部署与培训：销售（当前：杜中瑞、陈名赞、吴琪·推断待确认）、部署与演示机：产品总监与 IT 运维（当前：杨萌、杨明学·推断待确认）、使用报告监督（当前：许君·推断待确认）、教育线试用账号开通（当前：陈梦琪·推断待确认）、技术答复（当前：岳阳、宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 现场不承诺，回公司提交试用申请 → ② 按试用档位审批 → ③ 开通账号/额度或安排带用/部署 → ④ 登记试用台账 → ⑤ 带用培训并收集反馈 → ⑥ 半个月内出使用报告 → ⑦ 到期转化或回收 → ⑧ 输单复盘经审批的试用记录、试用台账（客户、档位、额度、期限、阶段、消耗、反馈）、客户使用报告、转化结果（充值/签约）或回收记录待新建240
SAL-17赠送额度、借机与特殊商务行为报备留痕销售、产品或渠道打算给客户、合作伙伴、种子用户赠送额度或设备、借出设备、提供超出标准口径的免费试用，或员工自费购买公司产品时，先报备审批，再在合同、后台、账务三处留痕主责——市场销售负责人（当前：李鹏为·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交特殊商务申请 → ② 产品核定成本与口径 → ③ 市场销售负责人审批（超档位 CEO 加签）→ ④ 审批通过后出库/发放 → ⑤ 后台备注与合同/协议留痕 → ⑥ 财务入账 → ⑦ 到期回收或转化跟进带审批编号的特殊商务申请单；对应的赠送/借用协议或个人采购合同；后台额度备注；财务可对账的赠送台账待新建96
SAL-18产品定价与价格体系管理新产品、新模型、新套餐、新硬件机型上市，或成本、渠道政策变化需要调价时，统一测算成本、倍率、毛利与渠道分成，经审批后发布“内部总表 + 对外价格表”两套版本主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——COO（当前：常元和·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 定价需求登记 → ② 汇总成本（模型折扣/硬件/人力）→ ③ 用定价测算表算倍率、毛利、分成 → ④ 内部评审 → ⑤ 管理层审批 → ⑥ 发布内部总表与对外价格表 → ⑦ 同步销售、渠道与系统配置 → ⑧ 每月复核带版本号的定价测算表、内部价格总表（含成本列，限定可见范围）、对外价格表（不含成本与折扣）、价格变更通知、系统价格配置记录待优化320
SAL-19客户方案与报价单编制审核客户询价、扩容或提出项目制需求时，由销售先完成需求调研，再编制方案书、报价单和内部成本测算表，经技术复核和分级审批后，只发出一版客户版报价主责——客户对接销售（当前：按商机归属，如闫登辉、刘昱潇、吴琪·推断待确认）；协同——FDE Leader（当前：黄振锋·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、产品总监（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 需求调研与报价登记 → ② 方案范围冻结 → ③ 分块估算（软件人日/硬件/模型用量/运维）→ ④ 用报价 Skill/模板生成方案书、报价单、成本测算表 → ⑤ 技术复核 → ⑥ 按毛利分级审批 → ⑦ 生成唯一客户版 PDF 发出 → ⑧ 登记台账并跟进反馈审批通过的客户版报价单（PDF，唯一版本）、方案书、内部成本测算表、报价台账记录待优化500
SAL-20硬件/算力配置评估、询价与报价客户提出并发、模型、预算、席位或服务器定制需求时，由技术评估配置与容量（必要时压测），IT 和渠道询价得出 BOM 成本，商务再加软件与词元价，形成带有效期的对外硬件报价主责——IT 运维/硬件负责人（当前：杨明学·推断待确认）；协同——销售骨干/商务报价（当前：闫登辉·推断待确认）、各需求销售（当前：刘昱潇、时建、陈名赞·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交硬件评估需求单 → ② IT 出配置方案（软件侧评估并发/上下文）→ ③ 容量存疑时压测 → ④ 客户确认配置 → ⑤ 询价出 BOM 成本 → ⑥ CTO 复核成本与配置 → ⑦ 商务按系数加软件与词元价 → ⑧ 财务、法务审核后发客户（注明有效期）配置清单、BOM 成本表、（必要时）压测/容量评估结论、带有效期的硬件报价单待优化240
SAL-21定制/非标需求评估、报价与特批签约前或签约后，客户在标品之外提出定制需求（换 Logo/去商标、定制 skill、接入指定模型或自有算力、API 适配、行业版开发、多机登录等）时，先判定是否非标，研发只报人天，销售定价，特批通过并签（追加）合同、收到首付款后才排期主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、COO（当前：常元和·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交非标需求受理单 → ② 产品判定标品/已有版本/非标 → ③ 研发评估人天与工期 → ④ 销售定服务价 → ⑤ 特批（占用研发多的 CTO 加签）→ ⑥ 签合同或追加合同、收首付款 → ⑦ 进入研发排期 → ⑧ 交付验收非标需求受理单（含判定结论、人天、价格、审批）、服务说明、（追加）合同、研发排期记录待新建144
SAL-22招投标与供应商入库国企、政府客户采购需要走招投标、供应商入库、竞争性报价，或合作方邀请联合投标时，统一登记、评审合规性，从标准资质包取材料，分工编制标书和报价/技术响应表，交叉审核后按期提交主责——投标负责人（当前：闫登辉·推断待确认）；协同——项目商务负责人（当前：刘昱潇·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、法务负责人（当前：李瑶·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 登记招标/入库信息与截止时间 → ② 投标可行性与合规评审 → ③ 拆分任务（商务、技术、报价、资质、演示）→ ④ 调取标准资质包 → ⑤ 编制标书与响应表 → ⑥ 交叉审核 → ⑦ 用印、封装、提交 → ⑧ 结果登记与复盘按期提交的投标文件/入库材料、投标台账记录、标准资质包（持续更新）、开标结果与复盘待新建375
SAL-23销售合同起草、条款谈判与用印客户进入商务合同阶段时，销售按模板起草（含保密协议、三方签约、合同拆分），组织交付可行性与风险会签，与客户谈条款，红线条款升级，定稿后用印签署并通知交付与财务主责——合同起草销售（当前：按商机归属，如吴琪、闫登辉、杨朋伟、刘昱潇·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、销售运营（当前：韩诗琪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 选现行模板起草 → ② 填写交付规格（引用标准套餐和规格文档）→ ③ 内部会签（市场销售负责人、交付可行性、法务、财务）→ ④ 对客谈判并记录条款修改 → ⑤ 红线条款升级 → ⑥ 定稿 → ⑦ 用印签署 → ⑧ 归档、CRM 上传，通知交付与财务双方签署的合同（及保密协议、补充协议）、会签记录、条款修改记录，并完成 CRM 上传和交付、财务通知待优化400
SAL-24收款条件、赢单登记与回款跟踪签约前要确认收款条件（默认先款后货，不赊账、不货到付款）；合同签署或赢单后，销售在 CRM 上传合同、关联商机、标记赢单、登记回款计划，财务确认到账后再通知交付主责——商机归属销售（当前：按商机归属，如杨朋伟、杜中瑞、吴琪、刘昱潇·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：郭逸非、陈子康·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 签约前确认收款条件 → ② 例外情况特批 → ③ 签署后 CRM 上传合同并关联商机 → ④ 标记赢单 → ⑤ 登记回款计划 → ⑥ 财务确认到账 → ⑦ 到账后通知交付/发货 → ⑧ 逾期催收升级CRM 中状态为“赢单”的商机（含合同附件或收款凭证）、回款计划与到账记录、到账后发出的交付通知待优化72
SAL-25合同范围外需求拦截与客户预期管理已签约或已出方案的客户提出合同、方案书、报价单里没有的新需求（新功能、二开接口、外部系统对接、资质协助、专属界面、人数或资源超出方案档位等）时启动。主责——客户归属销售（当前：吴琪、刘昱潇·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO/客户关系（当前：常元和·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT/现场交付（当前：杨明学·推断待确认）；兜底——销售负责人① 一线不当场承诺 → ② 1 个工作日内登记需求变更单 → ③ 对照合同/方案书判定范围 → ④ 分流（拒绝/通用功能排期/转定制报价/免费有限支持审批）→ ⑤ 书面答复客户 → ⑥ 承诺归档到 CRM每条范围外需求对应一张已判定、已书面答复客户的《需求变更单》（含结论、费用口径、排期、对客承诺原文），挂在该客户的 CRM 记录下。待新建180
SAL-26API/额度类分销订单（API 转售、卡密、第三方商城）外部客户或分销平台要购买公司的模型 API 或产品额度（API 转售、发卡平台卡密、第三方商城上架）时启动，覆盖报价、收款、开通、交付和对账。主责——API 分销商务负责人（当前：丁震宇·推断待确认）；协同——网关与计费研发（当前：王皓南·推断待确认）、运维部署（当前：宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、商城对接产品经理（当前：黄飞鹏·推断待确认）、财务（当前：待指定）；兜底——销售负责人① 询单登记 → ② 资质与转售合规核查 → ③ 按价格表报价审批 → ④ 先收款 → ⑤ 上游充值 → ⑥ 网关开号限额/生成卡密 → ⑦ 交付 key 与文档 → ⑧ 用量监控与月度对账入账一笔已收款、已开通、已对账的分销订单：订单台账记录、网关 key（含额度与并发上限）或卡密批次、对客交付文档、对账单与入账记录。待新建300
SAL-27渠道伙伴开发、授权政策与协议签署出现有代理/经销意向的伙伴（硬件厂商、运营商、云平台、集成商、个人或机构）时启动，从准入评估、政策洽谈、授权等级到协议定稿签约。主责——渠道负责人（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，政策与等级审定）、渠道销售（当前：吴琪、杜中瑞、时建、陈名赞、朱文瑜、刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）、生态市场总监（当前：许君·推断待确认）、产品总监（当前：杨萌·推断待确认）、CEO（当前：邴龙志·推断待确认，分润与合资类决策）；兜底——销售负责人① 渠道线索登记 → ② 准入评估 → ③ 洽谈分工与政策 → ④ 等级与非标条款审定 → ⑤ 按现行模板拟协议 → ⑥ 法务审查 → ⑦ 用印签署 → ⑧ 台账登记、系统开户、转培训已签署的渠道代理协议（引用当前启用模板版本和产品清单），渠道台账记录，渠道系统账号，进入培训陪跑的渠道名单。待优化400
SAL-28渠道非标合作（预装/贴牌/联合开发）承诺审批渠道或客户提出 OEM 预装、贴牌、联合开发、专属额度发放、分润等标准渠道政策以外的合作时启动，先汇总需求、产研评估，审批后统一对外承诺。主责——渠道对接销售（当前：时建·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、COO/市场销售（当前：常元和·推断待确认）、生态市场总监（当前：许君·推断待确认）；兜底——销售负责人① 不口头承诺，登记非标合作申请 → ② 核实已有承诺与协议状态 → ③ 产研评估指标与排期 → ④ 商务评估价格分润 → ⑤ 审批 → ⑥ 签协议/补充条款 → ⑦ 指定唯一口径人对外答复 → ⑧ 按对接清单实施并跟踪里程碑一份已审批的《非标合作申请单》（含产研评估、商务条件、对外承诺原文）、签署的合作协议或补充条款、进入任务看板的实施里程碑。待新建200
SAL-29渠道与销售产品培训赋能渠道签约后需要让渠道会讲、会卖、跑出首单，或产品新版本/新功能上线、销售与渠道反复问同类问题时启动。主责——渠道负责人（当前：闫登辉·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，新功能培训组织与回放归档）、研发讲师（当前：吴世豪·推断待确认）、销售负责人（当前：李鹏为·推断待确认，策略与考核）、渠道销售（当前：陈名赞、杜中瑞、吴琪、朱文瑜、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，对客话术）、生态市场总监（当前：许君·推断待确认，渠道物料）；兜底——销售负责人① 触发登记到培训台账 → ② 定讲师与材料 → ③ 发培训通知 → ④ 授课 → ⑤ 回放与文档归档 → ⑥ 小测与补课 → ⑦ 渠道陪跑首单 → ⑧ 重复问题回收更新 FAQ培训台账记录、课件/课程文档、录屏回放（知识库固定位置）、FAQ 与对客话术、测验结果；渠道侧还有首单陪跑记录。待优化135
SAL-30渠道体系管理（台账、分级评级、分润与推荐费结算）渠道签约后，需要维护签约台账、划分等级、定期评级、管理中间人与个人推荐，以及按规则核算分润和推荐费时启动。主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，体系设计与分润决策）、渠道负责人（当前：闫登辉·推断待确认）、生态市场总监（当前：许君·推断待确认，渠道手册与知识库）、商务（当前：杨朋伟、杜中瑞·推断待确认，承接推荐客户）、财务（当前：待指定）、法务负责人（当前：待指定）；兜底——CEO① 签约渠道入台账 → ② 定等级 → ③ 推荐线索登记与归属 → ④ 成单后按规则表核算分润/推荐费 → ⑤ 结算审批 → ⑥ 财务打款 → ⑦ 季度评级与违规处理 → ⑧ 制度与手册更新发布渠道台账（唯一数据源、随时可导出签约渠道清单）、渠道等级与季度评级结果、分润/推荐费结算单、现行渠道管理制度与渠道销售手册。待优化180
SAL-31渠道报备→订单→交付（渠道系统）渠道（含按渠道处理的内部直销主体）发现客户或项目，需要在渠道系统报备商机、提交订单、走到 IT 交付、充值、验收、开票时启动。主责——订单与交付统筹（当前：杨萌·推断待确认）；协同——渠道系统负责人（当前：丁震宇·推断待确认）、渠道系统开发（当前：陈子康·推断待确认）、商务审核（当前：闫登辉、吴琪·推断待确认）、IT 交付（当前：游家豪、杨明学·推断待确认）、软件部署（当前：宋祺睿、杨云峰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——销售负责人① 渠道报备客户/项目 → ② 商务审核进入保护期 → ③ 带合同发起订单 → ④ IT 配置预审、渠道确认 → ⑤ 商务审核订单 → ⑥ 财务确认收款 → ⑦ 硬件准备、软件部署、充值开通 → ⑧ 上传验收单关闭订单 → ⑨ 开票渠道系统中一条已关闭的订单：报备记录、五类合同材料、IT 预审单、收款确认、部署与充值记录、验收单、发票记录；渠道销量与充值看板随之更新。待优化500
SAL-32销售日报周报与汇报保密销售每周（特定时期每天）向部门报送工作汇报，管理层据此复盘商机；月底为人事提供考勤工作记录；汇报或群聊涉及客户内部信息、机密信息时按保密分级选择沟通渠道。主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认，信息分级与 CRM 权限）、销售运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）、全体销售（当前：杜中瑞、闫登辉、时建、吴琪、杨朋伟、陈名赞、朱文瑜、汪家诺·推断待确认）；兜底——CEO① 周五按统一模板填周报 → ② 同步更新 CRM 商机 → ③ 机器人提醒未交者 → ④ 汇总生成部门周报 → ⑤ 周五部门例会复盘 → ⑥ 月底导出考勤依据 → ⑦ 机密内容按分级走受限渠道每人每周一份按项目/渠道分标题的周报（多维表格记录）、部门周汇总、CRM 商机阶段同步、月度考勤工作记录；机密信息只在 CRM 受限字段或直属上级处留存。待优化90
SAL-33商机与客户归属分配制度出现新商机、多个销售争抢同一客户，或渠道直签/已出货客户没有对接销售时，按统一规则指定唯一归属销售主责——销售负责人（当前：李鹏为·推断待确认）；协同——渠道负责人（当前：闫登辉·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、产品总监/交付统筹（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 登记无主/争议商机 → ② CRM 查重 → ③ 按规则指定归属销售 → ④ 归属销售确认接收并首联 → ⑤ 争议裁决 → ⑥ 周简报公示 → ⑦ 月度回收超期商机重分配每个商机/订单在 CRM 中有且仅有一个归属销售，分配记录可查，激励按归属与订单类型计入待优化180
SAL-34销售业绩考核与提成核算每月/每季度以 CRM 数据对销售做 KPI 考核与档位结算，计算提成奖励；新制定或调整销售奖励政策，或产品成本变动影响奖励兑现时主责——销售负责人（当前：李鹏为·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、销售 KPI 数据整理（当前：汪家诺·推断待确认）、财务专员（当前：待指定）、HR（当前：待指定）、采购/成本核对（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 周期前定稿考核口径 → ② 奖励政策成本核对 → ③ 月末 CRM 数据截止 → ④ 系统自动计分+主管人工评分 → ⑤ 公示与申诉 → ⑥ 导出复核 → ⑦ 提成核算审批 → ⑧ 交财务发放归档经复核的月度 KPI 结果表、季度档位排名表、提成奖励核算表（审批通过并交财务），以及带版本号和生效日的奖励政策文档待优化192
SAL-35销售人员离岗客户与商机交接销售/渠道经理离职、调岗、长期休假或客户归属调整时，把其名下客户、商机、合同、回款与对客承诺完整移交给接手人并告知客户主责——销售负责人（当前：待指定）；协同——离岗销售、接手销售、HR 专员、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 离岗/调整确认 → ② CRM 导出名下客户与商机清单 → ③ 指定接手人 → ④ 逐客户交接（商机阶段、合同、回款、承诺、关键联系人）→ ⑤ 联合告知客户 → ⑥ CRM 归属变更 → ⑦ 30 天跟踪复核双方确认的客户交接清单；CRM 归属已变更；客户已收到对接人变更通知待新建96
SAL-36销售合同变更、终止与退换货处理已签销售合同需要变更（数量、配置、交付时间、付款条件）、客户要求解除合同、退货/换货或退款时，统一评估、审批并完成合同、账务与交付侧闭环主责——销售负责人（当前：待指定）；协同——客户对接销售、法务、财务专员、交付负责人（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 受理客户书面请求 → ② 影响评估（成本、库存、已交付部分）→ ③ 方案与报价 → ④ 法务/财务会审 → ⑤ 审批 → ⑥ 签补充协议/解除协议 → ⑦ 退换货与退款/红冲 → ⑧ CRM 与台账更新签署的补充协议或解除协议；完成的退换货、退款或红冲；更新后的合同台账与 CRM待新建200
SAL-37商务招待、礼品与反商业贿赂合规销售、市场、FDE 在对接客户（尤其政府、国企、事业单位）时发生宴请、礼品、差旅邀请、样机赠送、中间人推荐费等商务往来，事前判断是否合规并审批留痕主责——销售负责人（当前：待指定）；协同——法务专员、财务专员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 识别商务往来类型 → ② 对照红线清单 → ③ 事前申请 → ④ 审批 → ⑤ 执行并留存凭证 → ⑥ 报销时核对 → ⑦ 季度抽查经审批的招待/礼品记录；合规的报销凭证；季度抽查结论待新建90
SAL-38销售目标分解、商机预测与月度 Pipeline 复盘每季度/每月把销售目标分解到人与产品线，并基于 CRM 商机做成交预测，输出给交付备货、财务资金计划与管理层主责——销售负责人（当前：待指定）；协同——各销售、交付负责人、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 季度目标分解到人 → ② 月末商机阶段更新 → ③ 生成预测表（承诺/可能/机会三档）→ ④ Pipeline 复盘会 → ⑤ 输出备货与资金预测 → ⑥ 月度偏差复盘季度目标分解表；月度销售预测表；复盘会纪要与行动项；给交付的硬件需求预测待新建144

OPS 运营 报送人：李宣昊

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
OPS-01新站点/分站上线运营配置新开对外可注册、可付费的分站（Sorux 模态版、code.leapinfra.cn 编码站、MerCode 等），或现有分站改名、换支付渠道、改站内币时，完成从命名到试付验收的上线配置主责——站点配置工程师（当前：宋祺睿·推断待确认）；协同——站点与账号拥有者（当前：丁震宇·推断待确认）、测试（当前：王皓南·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 上线立项单（命名/域名/主体）→ ② 开管理员账号与收件邮箱 → ③ 站点基础配置 → ④ 支付渠道配置与资金账户核对 → ⑤ 币种/计费文案法务审核 → ⑥ 测试账户试付与全链路验收 → ⑦ 上线检查表签核后发布并登记通过上线检查表签核、试付成功的分站，以及一条站点登记记录（域名、主体、支付渠道、邮箱、负责人、上线日期）待新建96
OPS-02模型上线与定价规则LeapOne 新上线模型、调整收费、开放充值、赞助比赛或活动需要临时开充值/发代金券时，按统一规则核对成本、定价并开放主责——LeapOne 运营负责人（当前：李凯·推断待确认）；协同——LeapOne 研发负责人（当前：黄振锋·推断待确认）、LeapOne 产品负责人（当前：杨萌·推断待确认）、成本价提供人（当前：闫登辉·推断待确认）、统一支付研发（当前：陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 运营提出上线/调价清单 → ② 研发确认上游渠道与可用性 → ③ 取 API 成本价 → ④ 按毛利底线定价并自动校验 → ⑤ 审批 → ⑥ 配置上线并核验扣费 → ⑦ 充值/代金券安排 → ⑧ 月度毛利与对账复核经审批的模型定价表（含成本价、售价、毛利率），已配置上线并核验的模型与价格，以及充值/代金券发放记录待新建72
OPS-03帮助中心、使用手册与更新日志维护产品每次迭代上线、hotfix、新功能开放或内测/公测时，同步更新帮助中心、使用手册、FAQ、更新日志、教学视频、官网与客服入口，并自检不影响安装包下载主责——帮助中心与手册负责人（当前：杨萌·推断待确认）；协同——文档运营（当前：杨黔昆·推断待确认）、发布部署（当前：宋祺睿·推断待确认）、客户端前端（当前：葛家和·推断待确认）、产品经理（当前：陈震·推断待确认）、跃竞线产品负责人（当前：徐莉·推断待确认）、跃竞线文档更新（当前：陈雁·推断待确认）、LeapPPT 运营负责人（当前：李凯·推断待确认）、视频制作（当前：魏宗浩·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发版清单触发"文档同步"任务 → ② 研发提供变更汇总 → ③ AI 起草更新日志/手册改动 → ④ 产品审核内容 → ⑤ preview 环境自检 → ⑥ PR 合并部署 prod → ⑦ 同步客服知识库与群通知 → ⑧ 归档到飞书知识库已上线的帮助中心/手册/FAQ 更新、与版本号对应的更新日志、同步后的客服知识库，必要时附教学视频待优化144
OPS-05全员使用自研产品推动与内测反馈自研产品（LeapAll、LeapPPT、LeapCore、许愿机及各类小工具）内部上线或内测时，推动全员安装使用、邀请非研发同事试用，统计用量、督促落后部门，并把反馈收束到统一入口主责——内部推广负责人（当前：杨萌·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、反馈收口人（当前：杨黔昆·推断待确认）、版本发布（当前：岳阳·推断待确认）、额度与链接（当前：宋祺睿、张东郅·推断待确认）、各部门负责人（当前：徐莉、赵雪冰、李凯 等·推断待确认）、人事（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发布内部使用公告 → ② 部门负责人确认责任 → ③ 当天安装与首次真实场景使用 → ④ 每周用量数据公示 → ⑤ 未使用名单自动提醒 → ⑥ 反馈统一入表、分派 → ⑦ 场景提交与月度考核 → ⑧ 周报复盘全员安装与使用记录、每周使用数据公示、反馈池（含处理状态）、各部门月度场景提交记录、积分/奖惩依据待优化135
OPS-06员工 AI 补贴与内部余额月度充值核对每月 AI 补贴发放日，通知员工用补贴充值 LeapAll、统一为全员补充 LeapCore 内部余额，次日拉后台名单提醒未完成者，月底核对并输出补贴保留/取消依据；含政府消费券领取、购买与核销主责——内部余额管理员（当前：杨萌·推断待确认）；协同——LeapAll 服务端（当前：邓乾·推断待确认）、LeapCore 后端（当前：宋祺睿·推断待确认）、人事（当前：黄莹·推断待确认）、券与活动（当前：葛家和、胡橙橙·推断待确认）、财务（当前：待指定）、计费口径（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 补贴到账后发充值通知 → ② LeapCore 全员余额批量补充 → ③ 员工自行充值 LeapAll/核销券码 → ④ 次日按飞书手机号匹配后台数据 → ⑤ 机器人提醒未完成者 → ⑥ 月底核对、例外处理 → ⑦ 输出名单交人事/财务 → ⑧ 记录留档月度充值核对表（人员、账号、手机号、LeapAll 充值、LeapCore 补充、券码核销、例外说明），交人事/财务的补贴处理名单，批量充值审计记录待优化144
OPS-07试用额度与兑换券申请、发放与登记内部员工、天使用户、合作方、媒体、内测客户、活动参赛者需要 LeapAll 额度、LeapPPT 券码、MerCoder 体验券或模态币时，经表单申请、分级审批、自动或人工发放，并在统一台账登记对内外发放记录主责——额度与券码管理员（当前：杨萌·推断待确认）；协同——LeapAll 充值经办（当前：邓乾·推断待确认，备岗：张康·推断待确认）、LeapPPT 发券（当前：马漳毓·推断待确认）、表单与自动化（当前：陈晖·推断待确认）、发券接口（当前：黄振锋·推断待确认）、审批人（当前：丁震宇、李凯、李铭熙·推断待确认）、活动额度配置（当前：宋祺睿·推断待确认）、活动测试（当前：张东郅·推断待确认）、活动负责人（当前：陈梦琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 申请人填表（产品、环境、用途、数量、账号）→ ② 按规则自动放行或分级审批 → ③ 接口自动发放/人工发放 → ④ 发放结果回写并通知申请人 → ⑤ 对外发放登记台账 → ⑥ 活动券上线前测试 → ⑦ 每月统计发放量与成本已到账的额度或券码、含申请-审批-发放-回执的完整记录、对内对外统一发放台账、月度发放统计待优化300
OPS-08邀请码申请与账号开通外部用户、客户、渠道或内部同事需要试用字字可研等产品时，受理邀请码/验证码申请、开通生产或测试账号与管理后台账号、发放额度包，并记录申请来源与处理状态主责——账号开通运营（当前：杨萌·推断待确认）；协同——后台研发（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、业务专家/回访（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、渠道对接（当前：闫登辉·推断待确认）、基石计划跟进（当前：黄飞鹏·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 申请入表（产品内申请/表单）→ ② 状态字段与来源标记 → ③ 运营审核真伪 → ④ 后台生成并短信发送邀请码 → ⑤ 开通账号与额度包 → ⑥ 回写状态、处理人 → ⑦ 回访与渠道统计申请人收到可用的邀请码或账号（正确环境），申请记录带状态（待处理/已发/拒绝）、处理人和来源渠道；后台账号按角色开通待优化96
OPS-09用户额度包与企业组织运维LeapAll / LeapCore / 字字可研用户需要月度额度重置、特殊用户调额、补词元，或用户反馈充值未到账、余额异常，或企业客户要求开通/删除组织、转移组织管理员时启动主责——产品负责人（额度规则与变更审批，当前：杨萌·推断待确认）；协同——后台/NewAPI 研发（当前：宋祺睿、柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、品牌/Logo 设计对接（当前：待指定）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交额度/组织变更申请 → ② 按额度规则核对口径 → ③ 审批 → ④ 后台执行（批量脚本或单条） → ⑤ 测试/抽查核对余额 → ⑥ 通知申请方及关联方（换 Logo 等） → ⑦ 台账留痕已在后台生效且经核对的额度/组织变更，以及一条可追溯的变更记录（申请人、规则依据、执行人、生效时间）待优化144
OPS-10渠道卡密生成、额度包配置与核销外部平台（AI 内容平台、AI 商城、地推活动等）需要售卖或兑换本公司产品，需要完成厂商接入、额度包配置、卡密/渠道邀请码生成、发放登记与核销查询时启动主责——产品负责人（渠道接入统筹，当前：杨萌·推断待确认）；协同——渠道需求/商务对接（当前：段涵·推断待确认）、后台研发（当前：宋祺睿·推断待确认）、后端实现（当前：王皓南·推断待确认）、兑换/钱包后端（当前：邓乾·推断待确认，备岗：岳阳·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、外部沟通（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 渠道需求立项 → ② 定额度包与结算口径（人工审批） → ③ 后台配置额度包与渠道 → ④ 测试验证 → ⑤ 后台生成卡密并登记 → ⑥ 加密交付渠道并留档 → ⑦ 核销查询/接口对接 → ⑧ 月度对账已配置并验证的渠道额度包、登记在册的卡密批次、交付记录，以及可随时查询的核销状态与月度渠道对账表待新建300
OPS-11OPC 商城自营商品上架、下架与补货公司自营的卡密、兑换券、Skill、算力加油包或主管单位要求上架的免费产品，需要在 OPC 商城上架、下架、补货或因退款销毁卡密时启动主责——OPC 商城运营（当前：陈梦琪·推断待确认）；协同——卡密管理员（当前：葛家和·推断待确认）、商品提供方研发（当前：邓乾·推断待确认）、兑换接口研发（当前：望政韬·推断待确认）、退款审核（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 商品上架申请 → ② 提交介绍与卡密 → ③ 卡密导入核对并登记台账 → ④ 商城录入、内部试用 → ⑤ 正式上线 → ⑥ 库存监控与补货 → ⑦ 下架/退款销毁留痕在 OPC 商城正常售卖且库存充足的商品；记录完整的卡密台账（每批上架、补货、销毁的操作人与原因）待优化192
OPS-12渠道来源 UTM 链接/二维码申请与追踪市场活动、生态大会、媒体投放、线下积分卡或运营推广需要带来源标识的注册链接/二维码，并在后台统计渠道转化时启动主责——渠道码管理员（当前：张东郅·推断待确认）；协同——需求方产品负责人（当前：杨萌·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、研发（当前：马漳毓、黄振锋·推断待确认）、技术方案（当前：王皓南·推断待确认）、渠道推广（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交渠道码申请 → ② 按规范命名 utm_source → ③ 确认正式环境支持 → ④ 生成长期链接/短链/二维码 → ⑤ 测试扫码注册归因 → ⑥ 交付并登记 → ⑦ 周度归因报表可用于投放的带 utm_source 的长期链接/二维码，渠道登记记录，以及按渠道统计的注册转化报表待优化72
OPS-13拉新增长活动策划与传播物料产品内测拉新、邀请注册、分享红包/代金券/额度赠送等增长活动需要立项，以及配套传播文案与物料需要统一发布时启动主责——运营负责人（当前：李凯·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、方案提议人（当前：王皓南、丁震宇·推断待确认）、风控评审（当前：宋祺睿·推断待确认）、传播执行（当前：赵雪冰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 活动立项（目标/预算/承接） → ② 风控与财务审批 → ③ 产品承接与研发配置 → ④ 文案物料生成与审核 → ⑤ 定版发布 → ⑥ 活动监测 → ⑦ 复盘经审批的活动方案、唯一定版的传播物料与发布记录，以及活动结束后 5 个工作日内的复盘报告（拉新数、成本、薅羊毛拦截情况）待新建144
OPS-14种子用户与产品用户社群运营团队成员邀请朋友、客户、学生、媒体老师试用产品，需要发券并拉入用户群；或产品用户社群需要明确归属、处理新成员入群与账号变更时启动主责——运营负责人（当前：李凯·推断待确认）；协同——产品（当前：杨萌、杨黔昆·推断待确认）、邀请人（当前：王皓南、杨朋伟、邴龙志等·推断待确认）、表单维护（当前：陈晖·推断待确认）、话术/FAQ（当前：胡橙橙·推断待确认）、企微认证（当前：侯明月·推断待确认）、兼职研发（当前：黄振锋·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 邀请人提交发券申请（含用户微信号） → ② 先拉群/加客服 → ③ 审批发券 → ④ 入群欢迎与须知 → ⑤ 收集反馈 → ⑥ 周度抽查与种子用户识别 → ⑦ 社群维护（换号、清理）每个获券用户都已进入对应用户群或添加客服；种子用户名单与反馈记录；每个产品社群有明确负责人和入群须知待新建144
OPS-15付费用户识别、跟踪与挽留C 端产品（如字字可研）出现充值用户，或用户充值后停止使用，需要识别是否真实用户、跟踪回访、收集反馈并挽留或引导升级时启动主责——用户运营建联（当前：王满·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、数据查询（当前：陈锦杰·推断待确认）、权限开通（当前：宋祺睿·推断待确认）、销售承接（当前：吴琪·推断待确认）、挽留额度审批（当前：丁震宇·推断待确认）；兜底——运营负责人（当前：李宣昊·推断待确认）① 付费事件推送 → ② 按权限查看用户信息 → ③ 判定真实用户/调研/放弃 → ④ 首次建联 → ⑤ 赠额度与邀请反馈（审批） → ⑥ 引导企业版/LeapCore → ⑦ 台账跟进付费用户跟进台账（每个付费用户的类型判定、联系记录、反馈、赠送额度、转化结果）待新建72
OPS-16用户反馈收集与归集用户在产品群、用户群、客服渠道反馈问题或 Bug，需要自动或人工汇总进多维表格并流转给产品/研发时启动主责——产品运营（当前：杨黔昆·推断待确认）；协同——反馈工具提供（当前：王皓南·推断待确认）、工具打包（当前：宋祺睿·推断待确认）、需求读取（当前：马漳毓·推断待确认）、飞书权限管理员（当前：待指定）；兜底——产品负责人（当前：杨萌·推断待确认）① 固定反馈机器人入群并开权限 → ② 每日定时抽取群消息 → ③ AI 识别反馈、去重、打标签 → ④ 写入反馈表 → ⑤ 人工确认分级 → ⑥ 转需求/Bug 工单 → ⑦ 周报与回复用户每日更新、已去重分级的用户反馈多维表格，每条反馈有处理状态与去向（需求/Bug/不处理），以及每周反馈周报待优化54
OPS-17运营数据需求、看板与统计口径产品、运营、管理层或俱乐部业务方需要用户使用、成本、额度、订单等运营数据（一次性取数、固定看板、每日推送、月度导出）时启动主责——数据与后台研发（当前：宋祺睿·推断待确认）；协同——指标口径审定（产品负责人，当前：杨萌·推断待确认）、遥测研发（当前：邓乾·推断待确认）、管理后台研发（当前：柯逸飞·推断待确认）、跃竞后端/前端（当前：张楠、陈真炎·推断待确认）、跃竞运维（当前：席博田·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 表单提需求 → ② 查指标字典/已有看板 → ③ 确认口径 → ④ 取数或开发看板 → ⑤ 需求方核对 → ⑥ 交付归档 → ⑦ 重复需求固化为定时报表/机器人推送口径明确、标注环境的数据结果（表格/看板/每日推送）及更新后的指标字典条目待优化144
OPS-18内容运营选题审核与发布排期LeapCore 等产品公众号、视频号、社群推文需要按周持续产出，进行选题、草稿、审核、排期发布与产出考核时启动主责——新媒体运营（当前：鲁周毅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、市场负责人（当前：许君·推断待确认）、新媒体执行（当前：徐沛、侯晨帆·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）① 月度内容日历 → ② 收集选题 → ③ 每周选题会 → ④ 撰写草稿存草稿箱 → ⑤ 事实核对 → ⑥ 终审 → ⑦ 排期发布 → ⑧ 回填数据与周报考核按排期发布的推文/视频；内容宣发排期表中每条内容有选题、负责人、审核人、发布时间和数据；每周运营周报待优化54
OPS-19AI 资讯日报生成与社群分发每天定时采集 AI 新闻、社交媒体、RSS、公众号信源，生成 AI 大事件日报，推送内部飞书群和对外社群（开源聚变 AI 社区），并归档往期、安排发布人 AB 角时启动主责——日报发布人（新媒体运营）（当前：鲁周毅·推断待确认）；协同——信源与 skill 维护（当前：宋祺睿、丁震宇·推断待确认）、公众号订阅数据接口（当前：李凯·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）① 维护统一信源清单 → ② 定时采集 → ③ AI 去重筛选分类出 Top 8～10 → ④ 人工抽检终审 → ⑤ 推送飞书群 → ⑥ 适配格式发微信社群 → ⑦ 自动归档 → ⑧ 每周按反馈调整规则每日一期日报（飞书版 + 微信社群版）；可按日期/分类检索的往期归档表待优化36
OPS-20客户案例沉淀与宣传客户用产品做出可量化成果、交付满半个月需形成深度使用反馈，或销售/渠道推广缺少某行业案例时，启动案例发现、登记、量化、标杆培育与入库主责——销售运营（案例库管理）（当前：韩诗琪·推断待确认）；协同——各客户经理（当前：朱文瑜等·推断待确认）、案例包装（当前：丁震宇、闫登辉·推断待确认）、对外表述（当前：许君·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——市场销售负责人（当前：待指定）① 发现即登记 → ② 交付 15 天自动催反馈 → ③ 量化效果 → ④ 判定可公开度并取得授权 → ⑤ 按模板成稿 → ⑥ 审核入库 → ⑦ 分发销售/市场 → ⑧ 月度盘点案例库（多维表格）中审核通过的案例条目（行业、场景、效果数据、素材、可公开度、授权状态）；每月标杆案例清单待优化108
OPS-21内部 AI 应用场景与创意征集推广 LeapAll/LeapCore 或推进全员 AI 化时，需要向全员征集 AI 提效场景、使用案例、开源 idea、产品缺口场景、外呼等专项需求，并评审、激励、落地时启动主责——产品负责人（征集统筹）（当前：杨萌·推断待确认）；协同——人事（当前：黄莹·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、业务专家（当前：王满·推断待确认）、技术复现（当前：陈晖、王皓南·推断待确认）、学习委员（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 征集立项（目的、标准、评审团、激励、截止）→ ② 激励规则审批 → ③ 统一入口发布 → ④ 收集与提醒 → ⑤ AI 初筛聚类 → ⑥ 评审打分 → ⑦ 公示与激励 → ⑧ 入选项转任务/skill/开源 → ⑨ 复盘统一需求/创意池中带评审结论的征集结果；入选项对应的任务、skill 或开源立项；激励发放记录待优化90
OPS-22社区冷启动内容填充与汇报演示准备OPC/智能涌现/开源聚变社区或官网上线初期板块为空，或领导演示、向主管政府部门汇报在即，需要批量准备种子内容（帖子、评论、活动、政策、Agent 样例）时启动主责——社区运营（当前：陈梦琪·推断待确认）；协同——内容生产（当前：李玄冰·推断待确认）、接口与脚本研发（当前：葛家和、吴世豪·推断待确认）、文案（当前：王皓南·推断待确认）、技术方向与 AI 预审（当前：丁震宇·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 按节点倒排计划 → ② 书面确定真实性边界与质量线 → ③ 采集真实内容 → ④ 生成并标注种子内容 → ⑤ AI 预审 + 人工抽检 → ⑥ 经接口上线 → ⑦ 演示前走查 → ⑧ 节点后回收或转正节点前 2 个工作日完成填充并走查的社区/官网内容；种子内容台账（来源、标注、账号、回收计划）待新建128
OPS-23社区内容与入驻信息审核OPC/智能涌现/开源聚变社区中用户发帖、评论、改名、自定义标签、发布智能体/共创需求/资讯，以及入驻厂商提交资料，进入审核队列需要合规审核与准入判定时启动主责——社区内容审核岗（当前：陈梦琪·推断待确认）；协同——社区研发（当前：裴建武·推断待确认）、配置与第三方审核接入（当前：葛家和、吴世豪·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、厂商对接（当前：杨朋伟、谢昕璟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 内容提交 → ② 机器初筛（敏感词库 + 语义审核，只拒不放）→ ③ 推送待审队列 → ④ 值班人工复核 → ⑤ 通过/拒绝并记录原因与审核人 → ⑥ 举报申诉处置 → ⑦ 厂商准入预审与终审 → ⑧ 每周迭代规则与词库在时限内处理完毕、有审核人和理由记录的审核单；入驻厂商的准入结论；版本化的审核规则与敏感词库待优化300
OPS-24会员端活动上新、权益与积分配置合作俱乐部有新活动（节日、新赛季）需在会员端上新或换图，或要求增删会员权益、改兑换客服、上架积分商城商品、批量给老板加积分，以及策划共创/星耀计划等会员活动时启动主责——会员端产品经理（当前：陈雁·推断待确认）；协同——配置执行（当前：丁震宇·推断待确认）、后端（当前：王子明·推断待确认）、前端（当前：魏小东·推断待确认）、活动策划（当前：宫经喜·推断待确认）、俱乐部方运营对接人（外部）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 机器人卡片提报 → ② 产品经理确认边界与素材 → ③ 写入变更台账并建任务 → ④ 配置执行 → ⑤ 提报人验收 → ⑥ 卡片状态回写 → ⑦ 月度复盘按截止时间上线并验收的活动页、权益、商城或积分变更；变更台账记录“原值—新值”、操作人和验收人待优化240
OPS-25平台罚款申诉审核陪玩或俱乐部在跃玩管理端对平台罚款提交申诉，需要平台侧在时限内审核并反馈结果时启动主责——平台运营审核岗（当前：待指定）；协同——跃竞前端研发（当前：陈真炎·推断待确认）、跃竞后端研发（当前：待指定）、财务（涉及退罚款时）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 申诉提交触发通知 → ② 审核岗认领 → ③ 核对罚款依据与申诉材料 → ④ 作出维持/撤销/部分撤销决定 → ⑤ 执行退款或解除处罚 → ⑥ 反馈申诉方 → ⑦ 登记归档有审核结论、处理记录和反馈记录的申诉单；如撤销罚款，对应金额已退回或处罚已解除待新建80
OPS-26运营平台账号与登录验证管理运营人员登录、换设备、实名/人脸认证或新开抖音、小红书、微信（公众号/视频号）等公司运营账号，需要验证码或实名主体配合时启动；同时覆盖账号登记与人员交接主责——运营账号管理员（当前：李宣昊·推断待确认）；协同——实名手机号持有人（当前：待指定）、IT/信息安全（当前：待指定）、品牌（当前：待指定）；兜底——运营负责人（当前：待指定）① 账号登记入台账 → ② 绑定方式整改（企业认证/共享号码） → ③ 设验证码接收值班 → ④ 发起登录/认证申请 → ⑤ 验证码按安全渠道转达 → ⑥ 人脸/实名认证预约 → ⑦ 人员变动时交接与改绑一份完整的公司运营账号台账（主体、绑定号码、管理员、备份人）；每次登录/认证在约定时限内完成，且验证码不在聊天中明文留存待新建108
OPS-28运营资料汇总与岗位交接运营新人（含实习生）入职，或运营人员转岗、离职时，需要把群运营思路、运营流程、对外资料、用户调研成果统一交接给接手人主责——产品总监（当前：杨萌·推断待确认）；协同——运营文档维护人（当前：待指定，维护流程与群运营思路文档）、人事（当前：待指定）；兜底——运营负责人（当前：待指定）① 维护统一的运营知识库目录 → ② 按岗位整理“入门包” → ③ 入职前准备交接清单与权限 → ④ 入职当周当面讲解 → ⑤ 接收人按清单自学并完成入门任务 → ⑥ 双方核对签收 → ⑦ 交接后更新文档一份按岗位组织的运营入门包（知识库目录 + 交接清单 + 入门任务），以及双方确认的交接记录待优化36
OPS-29用户个人信息权利请求与账号注销处理产品用户（C 端或企业成员）提出查询、复制、更正、删除个人信息、撤回同意或注销账号，或应用商店/监管要求提供注销能力时启动主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、研发后台负责人（当前：待指定）、客服（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 统一受理 → ② 身份核验 → ③ 请求分类 → ④ 注销前检查与告知 → ⑤ 执行删除/匿名化 → ⑥ 答复用户 → ⑦ 留痕 → ⑧ 季度统计自查按时答复的请求处理单、执行记录，季度统计与自查报告待新建80
OPS-30营销权益防刷与异常账号风控处置新人注册福利、邀请码、代金券、试用额度、卡密、校园大使分润、红包类活动上线前后，需防批量注册、刷邀请、刷券、额度异常消耗与套现时启动主责——用户运营专员（当前：待指定）；协同——研发后台负责人（当前：待指定）、财务（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 上线前风控评审 → ② 配置监控告警 → ③ 每日巡检 → ④ 异常判定 → ⑤ 冻结/封停/回收 → ⑥ 用户申诉 → ⑦ 规则调整复盘 → ⑧ 月度损失统计活动风控评审记录、异常处置清单、月度权益损失统计待新建180
OPS-31用户举报、消费投诉与监管协查响应用户举报违法违规内容或账号、消费者通过监管平台投诉被转办、公安/网信等部门来函调取数据或要求协查、应用商店发出下架警告时启动主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、客服（当前：待指定）、研发后台负责人（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 统一入口登记 → ② 分类 → ③ 内容举报处置 → ④ 消费投诉核实答复 → ⑤ 监管来函核验 → ⑥ 最小化提供与整改 → ⑦ 台账归档 → ⑧ 季度复盘举报/投诉/来函台账、处理与答复记录、调证交付记录、整改记录待新建120

RND 研发 报送人：丁震宇

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
RND-01反馈群问题收集与分流（bug/需求/badcase）内部员工、客户或市场在反馈群、话题群、内测群或口头反映产品问题时，判定类型、查重、转入对应载体，并在原帖回复去向主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、反馈群值班产品经理（当前：杨黔昆、陈震·推断待确认）、Badcase 收集人（当前：黄霆瑄·推断待确认）、反馈机器人维护人（当前：待指定）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 收帖 → ② 补齐复现信息 → ③ 判类型（bug/需求/badcase/使用问题）→ ④ 查重 → ⑤ 转工单/需求池/badcase 表/直接答复 → ⑥ 原帖回复去向 → ⑦ 处理完成后通知反馈人每条有效反馈都有明确去向（工单编号、需求池记录、badcase 记录或答复），并回在原话题下；每周一份分流统计待优化180
RND-02Badcase 记录、分诊与回归集沉淀用户或内部发现 AI/Agent 表现差（答非所问、上下文丢失、工具乱调用、提前结束、生成质量差）但不属于代码缺陷时，登记 badcase、分诊根因、跟进修复，并沉淀为回归/评测用例主责——评测/Badcase 负责人（当前：黄霆瑄·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、Agent 研发（当前：岳阳、杨云峰、李铭熙·推断待确认）、字字可研 AI 助手研发（当前：宋祺睿·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 登记 → ② 补上下文 → ③ 入库判定 → ④ 分诊根因 → ⑤ 归因会指派 → ⑥ 修复（提示词/skill/工具/模型，或转 bug）→ ⑦ 回归验证 → ⑧ 入评测集并通知提交人带编号（BADCASE-NN）的 badcase 记录（含根因类别、处理方式、修复版本、关联工单）；每周 badcase 周报；新增的回归/评测用例待优化108
RND-03缺陷提报、复现、分级与指派测试、产品、研发、客户或交付人员发现产品缺陷时，复现留证、按模板建单、定级、指派认领、修复关联 PR、验收关闭主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 发现与复现 → ② 查重 → ③ 按模板建单 → ④ 定级 → ⑤ 指派/认领 → ⑥ 修复并关联 PR → ⑦ 产品/测试验收（打回或通过）→ ⑧ 关闭并通知每个缺陷都有一张信息完整、定级、有负责人、关联 PR 并经验收关闭的工单；发版前 P0/P1 清零记录待优化180
RND-04需求提出、澄清与评审入迭代产品、业务、客户、领导或研发提出新需求（含一句话需求、迭代中插队需求、客户现场需求）时，登记、澄清、评审，决定做/不做/排入哪个迭代，并留痕主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震、杨黔昆·推断待确认）、CTO（客户项目需求取舍，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵、陈雁·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 登记入需求池 → ② 澄清（背景/目标/验收标准）→ ③ 产品初筛 → ④ 需求评审（方案与估点）→ ⑤ 决策并留痕 → ⑥ 拆工单入迭代 → ⑦ 插队走确认 → ⑧ 产品验收需求池中每条需求都有来源、结论（做/不做/待定）和目标迭代；评审纪要；挂在迭代上、带估点、优先级和验收人的工单待优化144
RND-05新产品/新项目研发立项与分工提出新产品、新客户端或跨团队基础能力（如 MercAll/ClawLite、MercPay/LeapPay 支付中台、billing、电子签）需要多人协作落地时，完成立项、定角色、写需求、建协作载体、拆任务并跟踪到 MVP 验收主责——项目技术负责人（立项时指定，当前：待指定）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、外部/领域技术顾问（如支付，当前：王子明·推断待确认）、财务负责人（涉资金链路时，当前：黄梦婷·推断待确认）、法务负责人（涉电子签时，当前：李瑶·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 立项提出 → ② 立项卡（目标/MVP 范围/不做项/DDL）→ ③ 角色表 → ④ PRD/用户故事 → ⑤ 需求梳理会+纪要 → ⑥ 建仓库、群、工单项目、里程碑 → ⑦ 拆任务进看板 → ⑧ 进度同步 → ⑨ MVP 验收并转入常规迭代经 CTO 确认的立项卡、角色表、PRD/用户故事、需求梳理会纪要、工单项目与里程碑、MVP 验收结论待新建128
RND-06迭代规划、工单拆分与排期每个迭代（约两周）开始前，或新产品/大版本确定上线日期需要倒排时，把需求池整理成有人认领、有点数、有截止日的迭代计划主责——研发负责人/迭代负责人（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌、黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各模块负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 产品冻结迭代需求清单 → ② 研发拆故事卡/工单并关联需求 → ③ 估点与容量校验 → ④ 迭代规划会定范围与优先级 → ⑤ 认领与截止日 → ⑥ 倒排关键节点（提测/冻结/UAT/发版）→ ⑦ 发布迭代计划并通知已发布的迭代计划（cycle/milestone）：全部工单有唯一负责人、点数、优先级、截止日并关联需求，附关键节点日历与规划会纪要待优化108
RND-07研发任务分派、模块负责人与归属判定新迭代分工、出现无人认领的 bug/工单、跨团队问题不知找谁、成员超载/闲置/借调/改汇报线、新人入职派活时，确定唯一端到端负责人并维护模块负责人清单主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、各模块负责人（当前：待指定）、人事负责人（当前：黄莹·推断待确认，仅汇报线调整/新人入职时）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 维护模块负责人清单（主责/兜底/PR 审批人）→ ② 新问题按清单定位并指派 → ③ 查不到时首个接手人暂管并上报 → ④ 研发负责人裁定端到端负责人 → ⑤ 每周负载检查与调配 → ⑥ 人员变动填交接单并转派工单 → ⑦ 更新清单并公告公开的“模块—主责—兜底—PR 审批人—对外接口人”清单；每项任务/工单有唯一端到端负责人；人员调整有交接单待新建108
RND-08研发进度跟催与延期风险上报迭代/冲刺执行中，按工单跟踪进度、处理阻塞、节点前收口；预计延期时由负责人主动上报风险并决策调整范围或日期主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各工单负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 工单负责人每日更新状态并主动提测 → ② 机器人每日推送超期/未领/阻塞清单 → ③ 站会逐项处理 → ④ 节点 D-3 风险盘点 → ⑤ 预计延期按模板主动上报 → ⑥ 决策加人/砍范围/延期 → ⑦ 对外同步新日期 → ⑧ 迭代末归类延期原因每日进度异常清单、延期风险登记（原因、影响、新日期、决策人）、对测试与销售同步的最终范围与上线日期、迭代延期原因统计待优化240
RND-09研发站会与例会每个工作日固定时间的站会、代码评审（CR）会，以及迭代规划/回顾会、周会、专题评审会，用于同步进度/阻塞/风险并产出纪要与待办主责——研发负责人/站会主持（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认，上线冲刺期主持 bug 站会）、全体研发；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 按会议矩阵建周期性固定日程 → ② 会前更新工单状态 → ③ 按模板开会（站会 ≤15 分钟）→ ④ 智能纪要自动生成 → ⑤ 决议/待办转工单 → ⑥ 线下结论同步线上 → ⑦ 纪要归档迭代文档一张会议矩阵（固定日历）、每次会议的纪要、由会议决议生成的工单/待办待优化60
RND-10研发日报/周报与进展同步每个工作日下班前与每周五，研发/项目组提交日报与周报，汇总成管理层可读的进展、风险与下周计划；跨团队、子公司或借调人员对外同步进展主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认，产研周报与对上汇报）、全体研发、日报机器人维护人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 下班前更新工单状态 → ② 需补充者按四要素填日报 → ③ 机器人 20:00 汇总推送日报 → ④ 缺报/不合格自动 @补充 → ⑤ 周五研发负责人审定研发周报 → ⑥ 产品负责人合成产研周报与对上汇报版 → ⑦ 归档固定入口每日产研日报、每周产研周报（本周进展/风险/下周重点/点数完成情况）、对上汇报版本、跨团队进展同步记录待优化60
RND-11工单状态维护与工单系统规范任务、bug、需求进入工单系统流转后，按统一口径及时更新状态、负责人、迭代与标签，并通过自动通知、巡检与统计保证数据可信主责——研发负责人/工单系统管理员（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌·推断待确认，负责产品验收状态）、测试负责人（当前：张东郅·推断待确认，负责 bug 状态与统计）、代码仓库管理员（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 确定唯一数据源与状态口径 → ② 建单填必填字段 → ③ 按状态机流转（待办→进行中→待测→测试中→待验收→完成/打回）→ ④ 状态变更自动通知 → ⑤ 每日机器人巡检违规与滞留 → ⑥ 每周自动统计点数与 bug → ⑦ 按季度修订规范成文《工单规范》（状态定义、必填字段、流转规则、通知规则、统计口径）、每日巡检清单、每周统计报表待优化90
RND-12研发绩效、点数考核与事故追责每个迭代结束要核算研发点数和质量指标；或版本上线后出现 bug、数据事故、验收不通过，需要评级、认定责任并按规则扣点时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监/点数统计人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 开工前全量估点 → ② bug 入库定级并标来源 → ③ 迭代结束自动出点数与质量报表 → ④ 事故评级与责任认定 → ⑤ 扣点/回扣核算 → ⑥ 公示与异议 → ⑦ 季度汇总交人事与积分每迭代一份《研发点数与质量报表》（个人点数、bug 回扣、阻塞率、返工率）；事故/缺陷责任认定记录；公示后的点数结果；季度研发评价表待优化108
RND-13开工前方案设计与前置过审研发拿到新功能、较大改动，或涉及 LeapCore 平台能力、账号/权限、计费、网关等基础设施的需求，在写代码前先写方案并经负责人过审时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、跃竞后端权限负责人（当前：张楠·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、任务负责研发（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 确认需求已定 → ② 判定方案等级 → ③ 写 issue 方案/设计文档 → ④ 不确定点跑 PoC → ⑤ 过审 → ⑥ 定稿后估点开工 → ⑦ 偏离方案先更新再改挂在 Gitea issue 上的已过审技术方案（轻量为 issue 内方案，重量为设计文档加评审记录），PR 关联方案链接待新建144
RND-14技术方案评审、选型决策与赛马同一技术问题有 2 个以上方案或明显分歧（协议、框架、数据库、部署位置、计费归属、底座路线、交互原型），需要明确决策人、按标准评审或赛马择优，并把结论写成决策记录时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——议题收口负责人（按领域指定，如 Agent Runtime/协议当前：岳阳·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 登记决策议题 → ② 指定收口人与决策人 → ③ 写 ADR 草稿与方案对比 → ④ 选评审方式（文档/决策会/原型/赛马）→ ⑤ 评审或评测 → ⑥ 决策人拍板 → ⑦ ADR 归档公告 → ⑧ 落执行工单归档的技术决策记录（ADR：背景、选项、取舍、结论、决策人、日期、生效范围、重议条件）及执行工单；赛马另含章程、评测报告、评分表和名次公告待新建192
RND-15新技术/开源方案/第三方能力调研评估出现值得跟进的开源工具，或产品需要网盘、AI 网关、OCR、企业软件、第三方数据等外部能力时，评估“自研 / 二开 / 套壳 / 直接引入 / 采购 API”并给出立项建议时启动主责——技术调研负责人（当前：王皓南·推断待确认，可按议题另行指定）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、研发联调（当前：魏宗浩·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 登记调研议题 → ② 明确业务目标与数据范围 → ③ AI 初评横评 → ④ 人工评估许可、授权、成本、维护、隔离方式 → ⑤ 试用或 PoC → ⑥ 评审拍板 → ⑦ 转立项、接入或采购调研评估报告（候选对比、许可证与授权结论、成本、工期、推荐方案、实施负责人），调研台账结论，转入立项/接入/采购的记录待新建144
RND-16技术栈、组件库统一与通用能力复用新项目或新组件启动要选语言、框架、UI 组件库、通信方式、数据库；或发现多个项目在重复造同类轮子；或 FDE/定制项目做出可复用能力需要回流到模板、标准组件时启动主责——技术规范维护人（当前：待指定）；协同——基座组架构负责人（当前：陈晖·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、前端负责人（当前：季学森·推断待确认）、开放平台/FDE 负责人（当前：郭逸非·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 立项时对照技术栈清单勾选 → ② 查组件目录做复用评估 → ③ 清单外选型提偏离申请 → ④ 审批拍板 → ⑤ 更新清单并置顶公告 → ⑥ 可复用能力回流 → ⑦ 共性规范写入约束 → ⑧ 季度复盘生效的《公司技术栈与组件清单》（含版本和生效日期）、组件目录、偏离申请记录、回流 PR、写入 Agent 约束的共性规范待新建54
RND-17重大技术变更/重构报备与同步开发者准备重构/重写模块、更换方案或选型、修 bug 时会删改用户可见功能、关停高风险功能或下线接口、改关键设计口径、合入会影响他人仓库或接口的代码，或发现外部依赖风险时，事前报备并同步相关方主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、测试负责人（当前：张东郅·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）、变更摘要机器人维护人（当前：李铭熙·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 判定变更级别 → ② 写变更说明（影响面/回滚/测试建议）→ ③ @相关人征求意见 → ④ 按级别审批 → ⑤ 实施并在 PR 标注 → ⑥ 测试回归 → ⑦ 合入后自动通知 → ⑧ 每日变更摘要与日志已审批的变更说明、带“影响面”字段的 PR、合入通知记录、回归结果、变更日志条目待新建240
RND-18跨团队/跨系统接口对齐与集成约定两个以上研发组、产品或外部平台需要对接（账号/OIDC 登录、网盘、计费网关、订单与充值、开放平台、渠道系统、小程序互跳、底座与下游仓），要先对齐接口契约、数据唯一写入方、责任边界和降级方案，再并行开发与联调时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——LeapCore 后端/运维（当前：宋祺睿·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 提跨组对接单 → ② 分派两端负责人与裁决人 → ③ 写对接方案（边界/数据主责/接口/时序/降级）→ ④ 评审定版契约 → ⑤ 提供方出 mock 并行开发 → ⑥ 按清单联调 → ⑦ 文档与配置归档 → ⑧ 后续变更版本通知定版的对接方案与接口契约（OpenAPI/事件 schema，单一文档源）、数据主责表条目、联调清单与问题表、外部对接的责任矩阵与协议待优化500
RND-19前后端接口变更、联调与废弃通知后端新增、修改、删除接口或字段，或一个功能同时涉及前端、后端、管理后台需要配套合并与联调时启动，直到前端完成对接、旧接口按兼容窗口下线为止主责——后端负责人（跃竞当前：王子明·推断待确认；工程咨询线当前：宋祺睿·推断待确认）；协同——前端负责人（跃竞小程序当前：魏小东·推断待确认；工程咨询线当前：季学森·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞产品经理（当前：陈雁·推断待确认）；兜底——各线负责人（跃竞当前：徐莉·推断待确认；工程咨询线当前：王皓南·推断待确认）① 判定变更类型 → ② 同 PR 更新 Swagger 与对接文档 → ③ 登记变更清单并通知前端 → ④ 配套 PR 关联合并 → ⑤ 推测试服后通知联调 → ⑥ 联调问题表闭环 → ⑦ 破坏性变更锁步发布 → ⑧ 兼容窗口后废弃更新后的 Swagger（以 dev 环境为准）和对接文档、接口变更清单条目、关联 PR、闭环的联调问题表、废弃接口下线记录待优化120
RND-20Agent 安全与权限控制设计自研或开源 Agent（LeapAgent、LeapAll 客户端、龙虾/OpenClaw、赛马 Agent）新增或变更命令执行、文件/存储访问、远控能力，或设计内部服务鉴权时，先过安全基线评审和安全测试，再发版主责——Agent 核心研发（当前：岳阳·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、安全攻防测试（当前：王皓南、邓乾·推断待确认）、基座网关/鉴权研发（当前：望政韬·推断待确认）、架构安全评审（当前：陈晖·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 安全需求登记定级 → ② 对照安全基线出方案 → ③ 安全评审定范围 → ④ 实现并提 PR → ⑤ 红队用例测试 → ⑥ 产品验收与免责文案 → ⑦ 发版门禁与审计留痕通过评审的安全方案、已合并的 PR、红队测试报告、更新后的安全基线清单、用户协议免责条款待新建240
RND-21新成员研发账号开通与开发环境搭建研发、测试、实习生入职，或在职成员加入新项目时，在到岗首日内开通账号权限、跑通本地或开发服环境，并完成首周上手任务主责——用人项目技术负责人（当前：Leap 线王皓南、跃竞线王子明·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、带教人（当前：岳阳、杨云峰、游家豪·推断待确认）、前端负责人（当前：魏小东·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 到岗前提交开通清单 → ② 运维批量开通 → ③ 安全交付凭证 → ④ 指定带教人和模块边界 → ⑤ 按文档跑通环境 → ⑥ 完成首周任务并交付产出 → ⑦ 把新踩的坑补进 FAQ开通清单全部勾选（权限到位）、环境跑通截图、首周上手文档、更新后的环境 FAQ待优化108
RND-22代码仓库创建、归属与权限新项目或新组件需要建仓库、散落的仓库需要迁入公司组织、成员需要开通/变更/回收仓库权限时启动主责——Gitea 管理员（当前：宋祺睿、李铭熙·推断待确认）；协同——仓库负责人（当前：待指定，按仓库台账逐仓登记）、迁移规划（当前：陈晖·推断待确认）、CI/CD 基建（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交建库/权限申请 → ② 管理员核对命名与归属 → ③ 直接在组织下建库并授权 → ④ 登记仓库台账 → ⑤ 初始化 README、分支保护和 CI → ⑥ 定期复核并回收权限建在公司 Gitea 组织下的仓库、仓库台账记录（用途/负责人/开发者）、按最小权限开通的访问权限待优化72
RND-23开发测试服务器/云资源/域名申请研发、测试或业务需要虚拟机、裸机、云服务器、数据库、对象存储、域名解析、端口/安全组、短信/邮件/内容审核等云服务或测试设备时，统一申请、开通、登记，到期时续费或释放主责——Agent Infra Owner（当前：宋祺睿·推断待确认）；协同——IT 运维（负责内网、机房、采购、云账号，当前：杨明学·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查资源台账和能力目录 → ② 提交资源申请 → ③ 选型与审批 → ④ 开通并安全交付 → ⑤ 登记台账 → ⑥ 到期提醒 → ⑦ 续费或释放可用的资源（含访问方式）、资源台账记录（用途/负责人/到期日/是否常驻/成本归属）、审批单、月度资源与成本报告待新建192
RND-24GPU 算力申请、租赁与采购部署、微调、评测或测速模型需要 GPU 时，先盘点公司的闲置卡；不够再走小额租用或采购询价；用完按期释放主责——IT 运维（算力资源管理，当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、需求方研发、财务负责人（当前：黄梦婷·推断待确认）；审批与兜底——CTO（当前：丁震宇·推断待确认）① 提交算力申请 → ② 估算需求并盘点闲置卡 → ③ 内部分配，或转外部方案 → ④ 询价比价 → ⑤ 审批 → ⑥ 开通交付并登记 → ⑦ 到期释放或退租分配到人的 GPU 资源（有台账记录）、询价记录、审批单、释放/退租记录待新建108
RND-25AI 编码工具账号/订阅/额度申请发放员工需要 Claude、Codex、Cursor 等 AI 编码工具的订阅、号池 key 或额度时（研发优先，非研发其次），以及额度耗尽、新人入职、离职回收、AI 补贴月度申报时主责——AI 资源管理员（号池/额度运维，当前：杨明学·推断待确认）；协同——研发负责人（审批，当前：王皓南·推断待确认）、入职工具配置（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查可用渠道和本人资格 → ② 提交额度申请 → ③ 部门负责人审批 → ④ 从号池或公司订阅发放，或改走补贴自购 → ⑤ 登记台账 → ⑥ 用量监控与告警 → ⑦ 到期续用或回收可用的个人子 key、席位或订阅（台账有记录）、审批单、月度用量报表、补贴核定结果待新建240
RND-26AI 工具/中转渠道采购、号池运维与封号应对官方渠道贵、易封号或中转不稳时，对 AI 模型渠道（官方订阅、企业版、云厂商、中转站、号商）做准入评估、对公采购付款、号池/网关运维交接与续费评估，以及处理账号被封、KYC、风控主责——AI 渠道与号池运维负责人（当前：杨明学·推断待确认）；协同——渠道评测（当前：王皓南、宋祺睿、魏宗浩·推断待确认）、内部 API 网关部署（当前：宋祺睿、吴世豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、信息安全（当前：待指定）、管理层（海外主体等重大事项，当前：常元和·推断待确认）；决策与兜底——CTO（当前：丁震宇·推断待确认）① 需求与用量测算 → ② 渠道评估与准入 → ③ 采购审批与对公付款 → ④ 接入统一网关并登记 → ⑤ 健康监控与故障切换 → ⑥ 到期续费评估 → ⑦ 封号应对与月度复盘渠道白名单和评估表、采购审批单与发票/对账凭证、渠道与号池台账、统一网关配置、封号事件记录、维护人交接清单待新建400
RND-27模型 API Key 与调用额度申请（统一接入站）研发、测试、产品或项目需要调用公司统一 AI 接入站（aiapi/NewAPI/MercAll）或云厂商模型，需新开 Key、加额度、区分测试/生产、更换失效 Key，或申请第三方云服务接口 Key、模型服务权限时启动；同时管 NewAPI 实例管理员与 2FA 治理，并约束模型调用只走公司指定渠道主责——AI 接入站经办管理员（当前：杨明学·推断待确认）；协同——预算审批人（当前：丁震宇·推断待确认）、网关技术负责人（当前：望政韬·推断待确认）、NewAPI 实例负责人（LeapCore 当前：柯逸飞·推断待确认；LeapAll 当前：邓乾·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、申请表单与自动化维护人（当前：陈晖·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 对照术语表选申请类型 → ② 填「统一AI接入配额申请」→ ③ 预算审批 → ④ 接入站建用户/令牌并设额度、IP、到期 → ⑤ 私密渠道发放（生产 Key 由环境运维注入）→ ⑥ 台账回写 → ⑦ 用量、渠道合规监控与阈值告警 → ⑧ 失效/超额处置 → ⑨ 到期回收与月度对账 → ⑩ 管理员名单与 2FA 定期审计按用途和环境隔离、设了额度上限的接入站令牌；台账记录（归属人/项目/环境/额度/到期）；月度按项目归集的消耗报表待优化144
RND-28AI 编码协作规范与质量管控研发、产品或其他成员用 Codex/Claude Code 等 AI 编码工具或多 Agent 协作写代码、做 Demo、产出分析结果时，必须遵守的事前准备、执行约束、自测审查和交付规则主责——研发技术负责人（AI 编码规范维护）（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、Agent/客户端核心研发（当前：岳阳·推断待确认）、产品总监（非研发使用方）（当前：杨萌·推断待确认）、各仓库 owner（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 界定范围并写任务书 → ② 仓库 AGENTS.md 就绪 → ③ 选模型分工（强模型写工单/验收，执行模型写代码）→ ④ 隔离环境、禁止碰生产 → ⑤ 执行中频繁 commit 与监工 → ⑥ 自测（单测+冒烟）→ ⑦ 独立 Agent 审查+人工 review → ⑧ 人话交付说明并回写踩坑到 AGENTS.md通过自测、独立审查和人工 review 的代码/PR；任务书与验收记录；更新后的 AGENTS.md待新建180
RND-29AI 工具使用经验沉淀、培训与互助排障员工使用 Claude Code/Codex/OpenCode/Gemini 等 AI 工具遇到报错、不可用、配置问题，或有新工具/新订阅上线、摸索出值得推广的新用法、需要换工具迁移上下文时启动主责——AI 工具文档维护人（tech writer）（当前：魏宗浩·推断待确认）；协同——AI 工具群答疑值守（当前：游家豪·推断待确认）、AI 工具渠道与供应商对接人（当前：丁震宇·推断待确认）、代理与网络支持（当前：杨明学·推断待确认）、skill 征集与推广（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 在 AI 工具群按模板报问题 → ② 值守人查 FAQ/渠道状态表并响应 → ③ 给出临时规避 → ④ 供应商故障统一对接并公告 → ⑤ 解决后沉淀 FAQ → ⑥ 新工具上线同步发集成教程 → ⑦ 新方法/skill 评审后推广 → ⑧ 月度更新与培训持续更新的《AI 工具使用手册》（含 FAQ、渠道状态表、集成教程）；新工具教程；推荐 skill/方法清单待优化64
RND-30研发编码与工程协作规范宣贯新团队开始协作、新人加入、出现编码风格/提交方式/本地环境/文档载体/群聊沟通问题，或规范新增变更时，统一制定、落地工具检查并宣贯主责——研发技术负责人（研发规范 owner）（当前：王皓南·推断待确认）；协同——前端规范维护人（当前：季学森·推断待确认）、后端与 Git 规范维护人（当前：宋祺睿·推断待确认）、ESLint/TS 规范维护人（当前：陈晖·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞各端规范维护人（当前：张楠、魏小东·推断待确认）、各仓库 owner（当前：待指定）、人事负责人（当前：黄莹·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 识别规范缺口 → ② 规范维护人起草/更新 → ③ 研发评审 → ④ 落库并工具化（lint、hook、CI、PR 模板）→ ⑤ 研发通知群发布变更 → ⑥ 纳入新人入职清单 → ⑦ PR 评审执行 → ⑧ 季度复审成文的《研发协作规范》及总索引；仓库内 AGENTS.md/CODE_STYLE/README 与 lint 配置；群公告中的沟通约定；新人规范阅读确认记录待优化36
RND-31Git 分支管理与协作规范新建仓库、开发新功能、多版本并行、准备发版或紧急修复，以及发生误推/强推、分支污染、源码外泄风险时，按统一分支模型、合并方式和保护规则操作主责——研发技术负责人（分支规范 owner）（当前：王皓南·推断待确认）；协同——Gitea 管理员/发版把关（当前：宋祺睿·推断待确认）、Leap 客户端仓库 owner（当前：岳阳·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）、产品经理（标注迭代）（当前：黄飞鹏·推断待确认）、法务（开源与源码保密）（当前：李瑶·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 建仓套模板（默认私有、主分支保护、禁强推、必须 PR）→ ② 从基线拉功能分支 → ③ 每日 rebase 基线、频繁提交推远端 → ④ PR 指向正确目标分支并标注迭代 → ⑤ 评审+CI 通过后人工合并 → ⑥ 发版前冻结并隔离下一版本代码 → ⑦ hotfix 合入后回合 → ⑧ 合并后删分支、核对分支状态所有仓库统一的分支模型与保护配置；每次合并有 PR 与评审记录；发版分支只含本版本已验收提交待新建144
RND-32PR 提交与代码评审合并研发（含产品/运营用 AI 写代码）完成功能或修复，需要把代码合入 Gitea 上 main/dev/test/hotfix 等共享分支时启动。主责——Leap 研发技术负责人（当前：王皓南·推断待确认），负责 PR 规范、仓库保护规则与评审人分配；协同——PR 作者（各研发）、各仓库 Code Owner 评审/合并人（当前：LeapNew/LeapLite/LeapAgent 岳阳；v5/LeapAuth 宋祺睿；LeapCore/Cloudreve/LeapUpdate 杨云峰；字字可研 frontend 季学森；跃玩后端 王子明、前端 魏小东·均推断待确认）、测试负责人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）；兜底——研发负责人/创始人兼 CTO（当前：丁震宇·部门报送人）① 工单先行建分支 → ② 自测 + AI 预审 → ③ 按模板提 PR 且 CI 通过 → ④ 自动指派评审人 → ⑤ 评审与修改（SLA 计时）→ ⑥ 合并并同步 hotfix → ⑦ 标测试、工单流转 → ⑧ 超时 PR 日报清理通过 CI、经至少 1 名 Code Owner 批准、关联工单、附自测证据并合入目标分支的 PR；每日待合 PR 清单有明确处理人。待优化120
RND-33AI 代码评审与夜间自动评审需要用 AI 对 PR 做首轮机审、对仓库做夜间批量审查，或对代码库做全库 Bug/技术债审计时启动。主责——AI 评审机制负责人（当前：王皓南·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认，Gitea 集成与日常 CR）、测试负责人（当前：张东郅·推断待确认，评审 skill）、跃玩后端负责人（当前：王子明·推断待确认，跃玩审计）、CI 负责人（当前：吴世豪·推断待确认，定时任务托管）、各仓库 Code Owner；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 定审查范围与触发方式 → ② 合规与成本审批 → ③ 统一 skill/提示词并部署到服务器 → ④ 自动运行（PR 触发/夜间定时/月度审计）→ ⑤ 结果回写 PR 或生成报告 → ⑥ 人工复核分级 → ⑦ 转工单整改 → ⑧ 月度误报与成本复盘PR 上的 AI 评审评论；每日夜间评审报告与月度全库审计报告（飞书文档）；按阻塞/建议/误报分级并已转为工单的整改项；月度成本与采纳率统计。待新建48
RND-34数据库 Schema 变更与迁移脚本功能涉及新增/修改/删除表、字段、索引，或需迁移/回填历史数据，并要推到测试库、生产库或已交付客户现场时启动。主责——产品线后端负责人（DB 变更放行人）（当前：Leap/字字可研 宋祺睿、跃玩 王子明·推断待确认）；协同——变更提交研发、研发技术负责人（当前：王皓南·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃玩运维（当前：席博田·推断待确认）、IT 运维/现场执行（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① PR 勾选 DB 变更并附迁移/回滚/回填脚本 → ② 登记变更表 → ③ 评审（含存量数据影响）→ ④ 测试库执行与新旧数据验证 → ⑤ 生产前快照 → ⑥ 生产执行（先库后服务）→ ⑦ 生产验证与登记回执 → ⑧ 客户现场升级同步版本化迁移脚本（含回滚、回填）、经评审并在测试库演练通过的变更记录、生产执行与验证记录、更新后的迁移文档。待新建180
RND-35数据库性能、慢 SQL 治理与数据库故障应急新增复杂查询（统计、排行、大表 JOIN、递归、导出）上线前，或生产数据库出现高负载、慢查询、连接池耗尽、OOM、闪断告警时启动。主责——产品线数据库/架构负责人（当前：跃玩 王子明·推断待确认；Leap 待指定）；协同——后端研发（当前：张楠、蒋兴武（跃玩），邓乾、柯逸飞（Leap）·推断待确认）、运维（当前：席博田·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、产品线业务负责人（当前：徐莉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 复杂 SQL 上线前 explain 评审 → ② 测试库验证与压测 → ③ 慢查询/连接/内存告警 → ④ 故障定级与指挥分工 → ⑤ 止损（杀会话/限流/超时/扩容）→ ⑥ 根因定位（含厂商工单）→ ⑦ 修复并压测后热修 → ⑧ 书面复盘与改进项跟踪复杂 SQL 评审与压测记录；故障处置时间线；书面复盘报告（根因、影响、改进项）；厂商工单与升配决策记录。待新建300
RND-36依赖版本锁定与供应链管理部署栈或构建依赖第三方镜像、语言模块、开源底座（如 OpenClaw）时，需要锁定版本、保证可复现构建、升级前回归，或上游异常导致构建/部署失败时启动。主责——研发基础设施/发布负责人（当前：宋祺睿·推断待确认）；协同——CI 负责人（当前：吴世豪·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、交付部署（当前：魏宗浩、游家豪·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 建依赖/镜像/底座版本清单 → ② 锁文件与固定版本入库 → ③ 镜像与包本地化 → ④ CI 校验（禁 latest、lock 一致）→ ⑤ 升级走 PR + 回归 → ⑥ 统一下发并通知各环境 → ⑦ 上游异常回退到已验证版本已验证版本清单；入库且由 CI 校验的锁文件；内部镜像仓库/代理中的依赖副本；升级回归记录与各环境同步状态。待新建72
RND-37CI/CD 流水线建设与构建资源管理需要新建或调整自动构建、nightly、镜像构建、测试门禁，或 runner/构建机/签名机出现慢、挂、排队、磁盘满、权限与凭据缺失时启动。主责——CI 负责人（当前：吴世豪·推断待确认）；协同——CI 备份负责人（当前：岳阳、宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：丁震宇·部门报送人）、跃玩运维（当前：席博田·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① CI 需求/故障登记 → ② 判定类型（流水线/资源/网络/上游/不稳定测试）→ ③ 资源申请审批 → ④ IaC 创建或配置 runner → ⑤ 按模板配置流水线与门禁 → ⑥ 监控告警与定时清理 → ⑦ 凭据与配置清单化 → ⑧ 月度容量复盘可用的 PR check、nightly、release、镜像流水线与门禁规则；runner/构建机清单（含负责人、访问权限、凭据存放）；监控告警与清理任务；资源申请审批记录。待优化180
RND-38CI/构建失败排查与恢复机器人推送 nightly/release/部署失败卡片，或 runner/签名机/CI 机掉线、主线单测失败、依赖拉取失败，导致 PR 无法合并、打不出包时启动主责——CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维/网管（当前：杨明学·推断待确认）、CI 备用维护者（当前：宋祺睿、岳阳·推断待确认）、信创/Linux 打包负责人（当前：李子遥·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 按模板报障 → ② CI 值班认领并初判类别 → ③ 分流到代码/脚本/机器/网络/签名责任方 → ④ 止血（切备用 runner、切镜像、降级） → ⑤ 重跑验证全链路 → ⑥ 恢复通知 → ⑦ 登记与复盘恢复为 SUCCESS 的流水线（含补跑的 nightly/release）、群内恢复通知、CI 故障登记记录；达到复盘条件的附复盘文档与长期措施工单待新建240
RND-39提测、产品验收与测试验收流转研发完成一个需求或缺陷修复、已部署到测试环境，需要经产品验收（是否符合需求）和测试验收（功能是否正确）后关闭工单时启动主责——研发负责人/工单流转规则负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 自测+合并+部署测试环境 → ② 按模板提测并指定验收人 → ③ 产品验收（需求类） → ④ 测试验收 → ⑤ 不通过打回修复 → ⑥ 通过关闭 → ⑦ 每日滞留巡检 → ⑧ 迭代末缺陷清零状态为“完成”的工单，评论区留有提测信息、产品验收结论、测试验收结论（含环境与版本/commit）；“完成”的口径是验收通过，标了 ready-for-test 不算完成待优化180
RND-40测试体系建设与测试设计评审新团队/新产品线没有专职测试或质量靠客户发现时，建立最小 QA 流程；每个迭代需求冻结后，测试编写测试设计并组织产研评审（测试前移）时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、产品经理（当前：杨萌、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 明确测试范围与 QA 状态 → ② 需求阶段测试前移 → ③ 编写测试设计与计划 → ④ 测试设计评审会 → ⑤ 用例入库与分级 → ⑥ 执行与缺陷流程 → ⑦ 自动化固化 → ⑧ 迭代回顾修订每个迭代一份评审通过的测试设计/计划（飞书文档）、入库的用例（level1 长期/level4 一次性）、评审结论回写需求表；新团队有一套最小 QA 流程（QA 状态、缺陷模板、冒烟集）待新建108
RND-41发版前测试冲刺与测试人力调配发版前测试积压、测试“卡脖子”，或多个项目同时争抢测试人力，需要集中按用例分工测试、临时抽调研发/产品/实习生时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、被抽调研发与测试（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 迭代初分配测试人力 → ② 判定是否进入冲刺 → ③ 出冲刺计划与用例认领表 → ④ 抽调人员并开对齐会 → ⑤ 认领执行与提单 → ⑥ 每日站会同步 → ⑦ 出测试报告并做 Go/No-Go → ⑧ 释放人员与复盘冲刺测试计划、用例认领表（全部用例有认领人和结果）、测试报告（通过/不通过/无法验收/新增缺陷/未关闭数）、Go/No-Go 结论待优化144
RND-42冒烟测试与核心用例回归新包/新版本部署到测试环境、发版上线前后、模型/渠道切换前、交付项目打包刻盘前，需要按核心用例冒烟回归并给出放行结论时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、发版研发（当前：宋祺睿、葛家和·推断待确认）、产品负责人（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 发版研发通知提测（版本、更新日志、修复清单） → ② 测试环境冒烟 → ③ 缺陷登记与分级（立即修/后续 OTA） → ④ 修复与定向回归 → ⑤ 放行签字 → ⑥ 发布后生产冒烟 → ⑦ 内测放量与记录归档 → ⑧ 冒烟用例维护带 PASS/FAIL 的冒烟记录（测试环境+正式环境）、放行结论（通过/有条件通过/不通过）、缺陷工单；内测版本附反馈收集入口待优化180
RND-43性能压测与容量评估新服务/新版本/新上游或新模型上线前、扩大推广或发券前、大规模集中使用（百人培训、大量席位）前，需要验证并发与容量并给出结论时启动主责——测试负责人（压测执行，当前：张东郅·推断待确认）；协同——被测服务研发（当前：马漳毓、邓乾、杨云峰·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、研发负责人（当前：王皓南·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 提交压测申请 → ② 确认容量目标 → ③ 准备环境与数据（mock 上游、隔离、备份） → ④ 发布压测窗口公告 → ⑤ 执行（探测→基准→容量→稳定性） → ⑥ 出报告与结论 → ⑦ 优化后复测 → ⑧ 恢复清理并发结束通知按模板的压测报告（场景、并发档位、QPS/RPM、成功率、耗时分布、瓶颈、容量结论），原始数据（CSV/JSON）归档，压测窗口的起止公告待优化192
RND-44上线前安全测试、资金逻辑专项测试与漏洞修复产品对外开放下载/发布、政府或对外平台上线、涉密客户交付、涉及余额/支付/退款/兑换券/验证码的功能提测前做安全与资金专项检查；或上线后发现可利用漏洞需要紧急修复时启动主责——测试负责人（专项测试与复测，当前：张东郅·推断待确认）；协同——项目研发负责人（当前：王皓南·推断待确认）、IT 运维/安全加固（当前：杨明学·推断待确认）、安全测试支持（当前：宋祺睿、邓乾·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、产品负责人（当前：杨萌、徐莉·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 识别触发并选清单 → ② 自动扫描（源码/依赖/安装包/AI 渗透） → ③ 人工专项测试（安全+资金） → ④ 漏洞登记与分级 → ⑤ 修复与复测 → ⑥ 门禁签字放行 → ⑦ 上线后漏洞热修与通告逐项打勾的上线安全门禁清单、资金类测试覆盖表、漏洞工单（含分级、影响面、修复、复测结论）、放行签字；上线后漏洞附 hotfix 记录待新建240
RND-45AI 辅助与自动化测试验收工单转入产品验收或测试验收时，用 AI 机器人生成“实现锚定需求”和测试用例，或用 e2e/浏览器自动化脚本对功能和历史缺陷做回归验收时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、自动化脚本维护研发（当前：魏宗浩·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试工程师（当前：黄霆瑄·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 转产品验收时触发 AI 扫代码生成实现说明 → ② 产品确认验收口径、研发/测试确认测试锚点 → ③ 冻结锚点 → ④ 转测试验收时 AI 生成用例并执行 → ⑤ 报告回写工单 → ⑥ 人工抽检并签字 → ⑦ 统计可信度、调整门禁工单评论中的“实现锚定需求”（已冻结）、AI 执行报告（用例、步骤、截图、结论），以及人工抽检签字；AI 结论只作参考，验收通过须由人确认待新建36
RND-46UI 设计交付与视觉/交互走查新界面或改版需要设计稿，或界面功能开发完成后，需要设计师、产品、测试对照设计稿和既有版本检查样式与交互一致性时启动主责——UI/UX 设计师（当前：康紫馨·推断待确认）；协同——产品总监/产品经理（当前：杨萌、陈震·推断待确认）、前端研发（当前：葛家和、岳阳、魏宗浩、吴世豪·推断待确认）、测试（当前：黄霆瑄、涂维轩·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 登记设计需求 → ② 出 Figma 稿与交付清单 → ③ 研发按稿还原 → ④ 提交走查（截图+版本+对照稿）→ ⑤ 设计走查出问题单 → ⑥ 争议一次性拍板 → ⑦ 修复并做 PR 一致性审查 → ⑧ 视觉验收收口并沉淀规范挂在工单上的设计稿与交付清单、已关闭的 UI 走查问题单、附改前/改后截图的 PR、视觉验收结论、更新后的设计规范/组件库待优化108
RND-47测试账号、测试额度与测试数据管理测试、验收、内测或演示前需要测试环境账号/企业/管理员权限/模型余额/测试数据，或测试服上游额度耗尽、测试数据需要造数或清理时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——后端/运维（当前：宋祺睿、魏宗浩·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 提交测试资源申请 → ② 审核并优先从账号池分配 → ③ 新建账号/企业并按标准额度配置 → ④ 凭据安全发放、台账登记 → ⑤ 余额预警补额 → ⑥ 真实充值先审批后付款 → ⑦ 造数与到期清理 → ⑧ 月度对账回收可用的测试账号/企业/权限与额度、测试账号台账、余额预警与补额记录、测试服充值审批单与月度对账单、测试数据清理记录待新建240
RND-48开发/测试/生产环境分层与共享环境占用新建或调整环境用途，多人共用同一测试/演示机器需要占用、改配置、切模型 tag、清理、重装、换机或挪网段，或产品从内测转公测需要拆分生产与测试环境时启动主责——环境与基础设施负责人（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 制定环境分层规范 → ② 登记环境台账 → ③ 占用/变更申请 → ④ 冲突协调与冻结窗口 → ⑤ 变更前公告 → ⑥ 备份后执行 → ⑦ 更新台账并通知 → ⑧ 季度盘点回收成文的环境分层规范；实时更新的环境台账（环境/层级/地址/版本/负责人/数据级别/占用状态/冻结期）；占用与变更记录待新建320
RND-49测试环境部署与更新通知代码合入 dev/test 或需要验证某组件时，把服务（Agent、v5 cloud/edge、LeapAuth、Cloudreve、LeapUpdate、前后端）部署到测试环境，并在更新前预告中断、更新后通知验收时启动主责——测试环境发布负责人（当前：魏宗浩·推断待确认）；协同——CI/CD 与环境运维（当前：宋祺睿、杨云峰·推断待确认）、代码提交者（各研发）、测试负责人（当前：张东郅·推断待确认）、产品经理（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① PR 合并入待发布队列 → ② 发布预告并收集搭车 → ③ 加发布锁 → ④ 核对来源分支后构建 → ⑤ 部署/滚动更新 → ⑥ 完成播报版本与变更 → ⑦ 失败@提交者修复或回滚 → ⑧ 工单转测试验收测试环境运行指定版本；发布预告与完成通知（环境、组件、版本/commit、变更清单）；环境台账版本字段更新；失败修复或回滚记录待优化135
RND-50版本封版、打 tag 与发布分支管理迭代到期或对外发版节点前，需要盘点随版本发布的工单、执行 P0 清零闸门、冻结代码、打 rc/正式 tag、拉发布/hotfix 分支并剥离下一版本代码时启动主责——版本负责人（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、发版执行人（当前：柯逸飞、岳阳、宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 公布发版日历 → ② 工单收口与范围确认 → ③ P0 清零闸门 → ④ 冻结代码 → ⑤ 全仓库打 rc tag、建 hotfix 分支 → ⑥ rc 冒烟与放行 → ⑦ hotfix 双向合入核对 → ⑧ 打正式 tag 交接发布发版清单（版本范围、仓库×tag×分支×负责人）、全仓库 rc/正式 tag、hotfix/vX 分支、测试放行结论、移出版本的工单清单待新建240
RND-51正式版本发布上线测试验收通过的迭代版本或 hotfix，需要部署到内部生产（如 102）、对外正式服或客户环境（OTA），涉及服务端、客户端 OTA、agent 镜像、管理后台、配置中心等任一组件上线时启动。主责——版本发布负责人（当前：宋祺睿·推断待确认）；协同——研发负责人（放行决策，当前：王皓南·推断待确认）、客户端/OTA 发布（当前：岳阳、葛家和、邓乾·推断待确认）、测试负责人（当前：张东郅；字字可研线：李国庆·推断待确认）、产品负责人（当前：杨萌·推断待确认）、基础设施与 CI（当前：杨云峰、吴世豪·推断待确认）、客户经理（当前：吴琪·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）① 建发布单定窗口 → ② 封版与组件清单核对 → ③ 测试环境回归与放行签字 → ④ 备份与发布前检查 → ⑤ 按序部署（迁移→服务端→后台/配置→客户端 OTA） → ⑥ 生产冒烟与放行/回滚 → ⑦ 发布公告与中文更新日志 → ⑧ 观察期后关闭发布单生产/客户环境运行指定版本；关闭状态的发布单（版本号、组件、冒烟结论、回滚点）；对内对外发布公告与中文更新日志。待优化500
RND-52客户端打包、签名与安装包分发需要新版 Windows/macOS（含 Linux/信创）客户端安装包——nightly、beta/测试、正式、hotfix、客户定制或渠道包——时，从 CI 打包、签名公证、冒烟、上传下载入口、配置 OTA 到群内通知的全过程；也包括签名证书的采购与有效期管理。主责——客户端发版负责人（当前：岳阳·推断待确认）；协同——打包执行/CI（当前：葛家和、吴世豪、李铭熙·推断待确认）、签名与证书保管（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、OTA 配置（当前：邓乾、葛家和·推断待确认）、产品与版本台账（当前：杨萌、杨黔昆·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务（证书采购开票，当前：黄梦婷·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）① 登记打包申请与版本号 → ② 签名预授权 → ③ CI 多平台构建 → ④ 签名与公证 → ⑤ 冒烟放行 → ⑥ 上传 COS 并更新版本台账/下载页 → ⑦ 配置 OTA 渠道（先灰度） → ⑧ 机器人推送发布卡片并观察带正确版本号与签名的各平台安装包；版本台账中一条完整记录（含下载链接与测试结论）；已配置的 OTA 渠道；固定群内置顶的发布卡片。待优化320
RND-53OTA 在线更新与强制更新LeapCore/LeapAll 客户端、容器镜像或 updater/stack 组件的新版本（含 hotfix）已测试通过，需要在 LeapUpdate 配置授权与渠道并推送 OTA，或者要强制淘汰旧版、撤回发错的版本时启动主责——客户端发布与 OTA 负责人（当前：岳阳·推断待确认）；协同——OTA 推送与安装包管理（当前：葛家和·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapUpdate 维护（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、对客沟通产品经理（当前：黄飞鹏·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 兼容性检查（服务端先行）→ ② LeapUpdate 登记版本、渠道、授权与最低可用版本 → ③ 内部渠道灰度 → ④ 升级冒烟 → ⑤ 按窗口全量推送并发公告 → ⑥ 核对版本分布，强制升级旧版 → ⑦ 发错版本时撤回LeapUpdate 中一条完整的版本发布记录（版本号、渠道、灰度范围、最低可用版本、是否强更）；推送完成并验证过的客户端/容器版本；公告群升级通知；版本分布统计待优化240
RND-54Hotfix 紧急修复准入与发布线上（生产 102、正式服、客户实例）出现阻塞使用或严重影响体验的缺陷，或者有经批准插队的紧急需求，需要绕开常规迭代、基于线上版本快速修复并发布时启动主责——Hotfix 流程负责人（当前：王皓南·推断待确认）；协同——客户端 hotfix 打包发布（当前：岳阳·推断待确认）、服务端 hotfix 部署（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（准入与紧急程度判定，当前：杨萌·推断待确认）、OTA 与签名（当前：葛家和·推断待确认）、Update 与 Agent 镜像（当前：杨云峰、魏宗浩·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提 hotfix 申请 → ② 准入判定 → ③ 从线上 tag 建 hotfix 分支并 cherry-pick → ④ 定时冻结并比对清单 → ⑤ 51 验收环境回归 → ⑥ 生产发布与 OTA → ⑦ 发布核对与公告 → ⑧ 回合主干并关单一张关闭的 hotfix 申请单（含影响面、提交清单、测试结论、回滚方案）；新的小版本 tag 与生产部署；客户端 OTA；群内 hotfix 公告；修复已回合 main待新建400
RND-55Agent 容器镜像构建与发布Agent 代码、Dockerfile（时区、字体、办公库等）、内置 Skill 清单或运行配置有变更，需要构建 leapagent 容器镜像（含 hotfix 镜像），发布到测试(50)、生产(102)或客户环境时启动主责——Agent 镜像与 CI 负责人（当前：宋祺睿·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Skill 打包（当前：魏宗浩·推断待确认）、容器部署与 LeapUpdate 渠道（当前：杨云峰·推断待确认）、生产构建发布（当前：柯逸飞·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 代码与 Skill 清单入库 → ② CI 构建并推送镜像仓库（tag 带版本、commit、渠道）→ ③ 50 测试 → ④ preview 渠道灰度 → ⑤ stable 发布到生产/客户 → ⑥ 发布验证与通知 → ⑦ 登记版本与交接镜像仓库里带版本 tag、哈希和 changelog 的 leapagent 镜像；LeapUpdate 渠道配置记录；50/102/客户实例的验证记录；发布通知待优化144
RND-56产品 Skill 开发、评审、上架与内置发布新增或更新面向用户的产品 Skill（内置、官方、开放平台、企业专属、付费），需要开发自测、质量与安全评审、确定分级、打包或上架下发，以及处理版本更新、回滚、下架和用户修改覆盖时启动主责——Skill 发布负责人（当前：魏宗浩·推断待确认）；协同——Skill 质量评估（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Agent/内置 Skill 代码评审（当前：岳阳·推断待确认）、产品总监（分级与下发决策，当前：杨萌·推断待确认）、Leap 研发技术负责人（规则与术语，当前：王皓南·推断待确认）、付费 Skill 与 LeapSkill 后台（当前：李铭熙·推断待确认）、法务负责人（版权与合作，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 在 Skill 台账登记来源与作者 → ② 按 LeapSkill 规范开发、跑 selfcheck → ③ PR 进 Skills 仓库 → ④ 质量、安全、版权评审 → ⑤ 定分级（内置/官方/开放平台/企业）→ ⑥ 打包随镜像发布或上架下发 → ⑦ 发布通知与反馈收集 → ⑧ 版本更新、回滚与下架Skills 仓库或开放平台里一个合规的 Skill 版本（manifest、版本号、display_name、来源与许可齐全）；Skill 台账条目（分级、负责人、渠道、计费方式）；评审记录（含 review_rank）；发布通知待新建320
RND-58生产变更管控（备份、灰度、配置、访问审批）要对生产环境做任何变更时启动，包括：生产版本部署、DNS/证书切换、网关升级、数据库结构或数据手工改动、镜像手工调整、环境变量与密钥配置、Pulumi/infra 变更、功能灰度名单调整、旧环境维护与环境迁移主责——生产变更审批人（当前：王皓南·推断待确认）；协同——生产发布执行人（当前：宋祺睿·推断待确认）、基础设施与网关运维（当前：杨明学·推断待确认）、LeapCore 部署（当前：杨云峰·推断待确认）、LeapAll 服务端（当前：邓乾·推断待确认）、跃竞后端与运维（当前：王子明、席博田·推断待确认）、开放平台（当前：郭逸非、吴亚军·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提交生产变更申请（内容、窗口、影响、回滚、验证人）→ ② 按等级评审 → ③ 申请限时访问权限 → ④ 变更前在线备份 → ⑤ 窗口内执行，一人执行一人复核 → ⑥ 灰度并观察 → ⑦ 验证与通知 → ⑧ 关单留痕，或回滚每次生产变更一条审批记录（含备份位置、执行人、复核人、回滚方案、结果）；变更日历；灰度名单配置记录；生产系统一主二备值班表待新建240
RND-59线上部署回滚新版本上线后关键功能（支付、退款、分账、登录、数据加载）出现异常，且短时间内无法修复，需要先止血（封入口或回滚到上一个已知正常版本），或者回滚后发现版本不对需要纠正时启动主责——后端负责人（回滚执行）（当前：王子明·推断待确认）；协同——运维（当前：席博田·推断待确认）、后端研发（核对基线，当前：蒋兴武·推断待确认）、前端负责人（当前：魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、业务负责人（拍板回滚或封禁入口，当前：徐莉·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 按模板报障 → ② 10 分钟内做止血判定（封入口/回滚/直接修）→ ③ 确定回滚目标 commit sha 并二次确认 → ④ 执行回滚（先评估数据库兼容）→ ⑤ 比对基线、回归核心用例 → ⑥ 通知相关方 → ⑦ 修数据、补回遗漏功能后重新上线 → ⑧ 复盘回滚记录（原因、目标 sha、执行人、确认人、时间、影响）；回滚后的回归结论；回滚通知；数据修复和重新上线记录；复盘文档待新建180
RND-60小程序/App 商店提审与上架小程序（星域、PeRo/猩球、弈荟等）新版本验收通过、需要提交微信审核并发布，或遇到审核驳回、类目缺失、主体变更、保证金和年审；LeapCore 移动端要上架 iOS App Store（含国区 App 备案）时启动主责——小程序/App 提审负责人（当前：魏小东·推断待确认）；协同——会员端提审（当前：郝智豪·推断待确认）、业务负责人（类目、加急、保证金、虚拟支付决策，当前：徐莉·推断待确认）、产品验收（当前：陈雁、段涵·推断待确认）、iOS 上架（当前：岳阳·推断待确认）、备案（当前：杨明学·推断待确认）、总经办用印（当前：田杰·推断待确认）、法务负责人（协议文案合规，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 产品验收通过 → ② 提审前合规自查（测试数据、类目、协议、虚拟商品/支付、素材）→ ③ 提审并登记 → ④ 跟踪审核 → ⑤ 驳回处理（查驳回原因库、修改、申诉或加急）→ ⑥ 过审发布并通知 → ⑦ 维护主体/类目/保证金/年审台账过审并发布的小程序/App 版本；提审记录（版本、提交时间、结果、驳回原因与处理）；驳回原因库与应对话术；主体、类目、保证金、年审台账；iOS 上架材料包待新建240
RND-61客户演示前版本冻结与演示环境准备已确定客户/领导/媒体演示、POC 演示或上线评审答辩的时间，需要在演示前冻结研发改动并备好环境、数据、账号、skill 和第三方额度主责——产品总监/演示统筹（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、基础设施工程师（当前：葛家和·推断待确认）、测试负责人（当前：张东郅·推断待确认）、演示方（销售/FDE，当前：吴琪、李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 登记演示 → ② 涉密与范围判定 → ③ 定演示人与版本 → ④ 宣布冻结窗口 → ⑤ 备环境/数据/账号/额度 → ⑥ 彩排自检 → ⑦ 演示与现场保障 → ⑧ 解冻与复盘一份已签核的《演示准备单》、一个冻结且可用的演示环境（含数据、账号、skill、额度）、一次彩排记录与演示后复盘待新建180
RND-62内部 Demo/原型/静态页面部署员工（含非研发）用 AI 做出 Demo、原型或 HTML 页面，需要给同事、领导、外部用户或客户访问主责——运维/发布工程师（当前：宋祺睿·推断待确认）；协同——IT 运维/网管（域名、服务器，当前：杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、申请人；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 提交部署申请 → ② 判定访问范围与类型 → ③ 分配位置/端口/子域名 → ④ 仓库归入组织 → ⑤ 部署并安全检查 → ⑥ 发布预览链接 → ⑦ 登记 Demo 台账 → ⑧ 到期回收可访问的预览链接（已备案域名、HTTPS），Demo 台账中的一条登记记录（含负责人、访问范围、到期日）待新建54
RND-63信创适配开发、打包与验收市场/销售/客户提出新的"芯片 × 操作系统"适配需求，或主线出新版本需要出信创包、测试、修复并对外同步适配状态主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——产品总监/项目统筹（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、客户端研发（当前：岳阳·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、IT 运维（构建机/测试机，当前：杨明学、游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 需求登记 → ② 周评审定优先级 → ③ 借机/备环境 → ④ 流水线构建出包 → ⑤ 矩阵测试出报告 → ⑥ 缺陷提单分诊 → ⑦ PR 合入与 hotfix 回移 → ⑧ 按口径更新适配表并对外同步可下载的信创安装包（含 commit 与 jobset 标识）、测试报告（通过/有条件通过/不通过）、适配多维表格中更新的状态、对外口径说明待优化256
RND-64行业版插件开发、接入规范与交付工程/投资/法律/招投标等行业功能以插件或 skill 接入 LeapCore，需要按规范开发、测试验收、确定版本号并下发到指定企业实例；子公司或外部团队要接入 Leap 平台主责——行业版负责人/产品总监（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、插件研发（当前：侯怡辰、陈锦杰·推断待确认）、FDE/skill 下发（当前：邓乾·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、运维/实例配置（当前：宋祺睿·推断待确认）、测试（当前：李国庆·推断待确认）、业务验收（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 立项与规范对齐 → ② 按插件规范开发 → ③ 提测 → ④ 业务/产品验收 → ⑤ 定版本号与发版方式 → ⑥ 下发前检查 → ⑦ 测试机先发再发企业实例 → ⑧ 台账登记与回滚通过验收的插件/skill 包（含版本号）、更新后的"企业-实例-行业版-已下发版本"台账、下发记录待优化400
RND-65移动端研发协作与构建发布LeapCore 手机端/录音卡由外部伙伴承接开发，需要明确里程碑、接口文档、缺陷管理、APK/iOS 构建与内测分发、测试放行主责——外部协作负责人/产品总监（当前：杨萌·推断待确认）；协同——产品经理（当前：黄飞鹏·推断待确认）、客户端研发（接口与构建，当前：岳阳·推断待确认）、会议接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：潘浩伟、余超·推断待确认）、IT 运维（Apple 账号/证书，当前：杨明学·推断待确认）、外部开发团队（当前：外部伙伴）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 立项定里程碑 → ② 原型与接口清单交付 → ③ 每日同步 → ④ 接口文档变更通知 → ⑤ 构建与内测分发 → ⑥ 测试提缺陷 → ⑦ 修复验收 → ⑧ 放行结论与公测按里程碑交付的 APK/iOS 内测包、维护中的移动端 API 文档（含变更日志）、测试报告与放行结论待优化320
RND-66支付功能联调与收款商户管理支付/网银/电子签功能开发需真实小额付款联调；产品需按 2B/2C 选择或切换收款商户；线上出现到账延迟、回调异常、分账失败主责——支付研发工程师（当前：陈锦杰·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务（经办，当前：刘梦可·推断待确认）、支付渠道对接人（当前：徐莉·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAll 对接研发（当前：邓乾·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 测试付款申请 → ② 小额真实联调 → ③ 商户路由规则确认 → ④ 切换前检查 → ⑤ 切换与一元验证 → ⑥ 监控与对账 → ⑦ 异常处置 → ⑧ 复盘联调通过记录与测试付款报销凭证、商户路由配置（产品↔主体↔商户）、切换检查单、支付异常处置与复盘记录待新建160
RND-67新模型/上游渠道/第三方 API 接入与上线验证产品、客户或内部需要新模型、新上游渠道或第三方付费 API（OCR、企业数据、搜索、生图、视频），需完成 key 申请、网关接入、参数规则、价格配置、测试服验证、生产上线与下游同步主责——模型网关研发负责人（当前：柯逸飞·推断待确认）；协同——上游渠道/aiapi 维护（当前：杨明学·推断待确认，备岗：吴世豪·推断待确认）、研发技术负责人（网关架构，当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户本地 NewAPI 配置（当前：李铭熙·推断待确认）、LeapAll NewAPI（当前：邓乾·推断待确认）、财务（充值，当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 接入需求登记 → ② 成本对比与是否接入 → ③ key/额度申请 → ④ aiapi/v5 网关配置渠道与价格 → ⑤ 测试服部署 → ⑥ 冒烟/稳定性/价格验收 → ⑦ hotfix 上生产并观察 → ⑧ 下游同步与通知生产可用的模型/API（含渠道、模型 ID、价格、fallback）、模型上架台账记录、验收结论（工单评论）、下游（LeapCore/LeapAll/客户本地）同步完成通知待优化400
RND-68模型与上游供应商选型评测出现更便宜/更稳的上游渠道、新模型、新 OCR 或工具，或客户硬件变化需要选型，需做质量 bench、测速、成本与折扣核算，决定是否采用主责——模型供应商与评测负责人（当前：待指定）；协同——测试负责人（当前：张东郅·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、模型评测（当前：董洪焜、魏宗浩·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维/硬件测速（当前：杨明学、游家豪·推断待确认）、基座研发负责人（客户本地模型，当前：望政韬·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 登记评测需求 → ② 定评测范围、预算与负责人 → ③ 开评测账号/额度 → ④ 跑固定评测集（质量/速度/稳定性） → ⑤ 成本与折扣核算 → ⑥ 出评测报告 → ⑦ 选型决策 → ⑧ 结论入库并转接入一份标准评测报告（质量、速度、稳定性、成本、结论），评测记录多维表格中的一条记录，采用时转 RND-67 的接入工单待新建108
RND-69模型定价、倍率与成本价配置新模型上架、上游调价/折扣开通或到期、峰谷分时计价上线、汇率或倍率决策变更时，把成本价换算成对外价，并同步到 AIAPI、LeapCore/LeapAll NewAPI、v5 网关及客户本地网关主责——模型价格维护人（当前：柯逸飞·推断待确认）；协同——AIAPI 上游成本维护（当前：杨明学、吴世豪·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 价格变更登记 → ② 核成本价（四价、阶梯/分时、汇率） → ③ 定倍率与对外价 → ④ 测试服配置 → ⑤ 账单级验价 → ⑥ 生产及各下游同步 → ⑦ 通知产品/财务并更新台账已生效且验价通过的各网关价格配置；更新后的“模型价格台账”（成本价、倍率、对外价、生效日、核价人）及变更记录待优化240
RND-70计费准确性验证与账单/缓存对账计费/扣费/预扣功能上线前提测；用户或内部发现扣费异常；新模型/新折扣上线后要对照上游账单核实；缓存命中率异常；需要按主体账号归集模型成本主责——计费测试与对账负责人（当前：张东郅·推断待确认）；协同——计费研发（当前：邓乾、柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、AIAPI 上游成本维护（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提测/异常登记 → ② 准备测试账号与观测点 → ③ 固定请求集跑数 → ④ 比对平台扣费、配置价与上游账单 → ⑤ 定位差异 → ⑥ 修复与退补 → ⑦ 周度对账报告计费验证报告（预期 vs 实际）；差异处理记录（含退补决定）；每周上游账单与平台扣费对账表；按主体归集的模型成本表待新建135
RND-71模型档位路由与渠道切换变更因成本变化、模型升级或故障恢复后调整，需要新增/切换/删除上游渠道，或调整 LeapCore/LeapAll 经济/标准/专家档对应模型与思考强度、生图主通道与 fallback 时启动（计划内变更）主责——模型路由变更执行人（当前：柯逸飞·推断待确认）；协同——AIAPI 渠道维护（当前：杨明学·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提变更单 → ② 方案拍板 → ③ 先加新渠道不动旧 → ④ 测试服切换 → ⑤ 回归测试 → ⑥ 窗口内切生产并盯日志 → ⑦ 同步价格与下游 → ⑧ 发公告保留回滚点 → ⑨ 观察期后下线旧渠道已完成并验证的路由/渠道变更；变更单（含回归结果、回滚点）；更新后的“渠道-模型-档位”台账；变动通知群公告待优化240
RND-72上游模型故障告警响应与降级告警机器人推送“AI 上游连续失败/模型探测异常”、官方状态页发布事故，或用户/测试反馈超时、502/429/503、降智、余额耗尽导致不可用时启动主责——AI 网关值班人（当前：杨明学·推断待确认）；协同——LeapCore 网关研发（当前：柯逸飞·推断待确认）、V5 网关备用维护（当前：吴世豪·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、字字可研研发（当前：侯怡辰、陈锦杰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 告警/反馈 → ② 值班认领 → ③ 定级 → ④ 定位故障层级 → ⑤ 止血（切备线/降级/禁用） → ⑥ 内外通报 → ⑦ 恢复验证 → ⑧ 复盘在时限内止血并恢复的服务；故障工单（定级、根因、处置、时间线）；对内对外通知；P0/P1 复盘记录待优化375
RND-73上游账户余额、凭证到期与 Token 消耗管控产品依赖的上游模型账户（模型厂商官方账户、云厂商 A/B 的模型平台、算力平台、中转站等）与第三方服务凭证（如文档解析 Token）需要日常监控余额、到期和用量，以及内部测试需要额度 Key 时启动主责——上游账户与凭证管理员（当前：杨明学·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、计费研发（当前：邓乾·推断待确认）、CI/网关研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 账户与凭证入台账 → ② 设余额/到期阈值 → ③ 每日用量播报 → ④ 低于阈值预警 → ⑤ 充值审批与付款 → ⑥ 到账确认 → ⑦ 凭证到期前续期 → ⑧ 测试 Key 限额发放与回收 → ⑨ 月度复核完整的上游账户与凭证台账；每日用量与余额播报；欠费中断为零；测试 Key 发放与回收记录待新建72
RND-74NewAPI/AI 网关部署、升级与值守新建 API 中转分站（如 LeapOne、OPC 社区网关、产品线专用站）、网关版本升级或安全漏洞修复、生产服迁移、新增反代层或协议兼容、网关维护人变更交接时启动主责——AI 网关负责人（当前：杨明学·推断待确认）；协同——网关备用维护（当前：柯逸飞、吴世豪·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、分站部署研发（当前：黄振锋·推断待确认）、LeapAll 部署（当前：邓乾·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求与容量评估 → ② 服务器申请 → ③ 按基线部署（反代超时、安全组） → ④ 部署检查 → ⑤ 功能测试与压测 → ⑥ 窗口内切换上线 → ⑦ 纳入监控与台账 → ⑧ 值守与交接按基线部署并压测通过的网关实例；网关台账（实例、版本、域名、调用链拓扑、负责人）；升级/迁移记录；权限交接清单待优化96
RND-75线上/测试环境故障响应与复盘生产、测试、客户私有化或内网环境出现服务不可用或大面积报错（OOM、连接池满、磁盘满、证书到期、网络中断、网关超时、容器挂、支付回调丢失、生成任务批量卡死等）时，从报障、定级、指定指挥人、止血恢复、状态同步与对客口径，一直到事故报告和改进项闭环主责——故障指挥人（各产品线技术负责人；当前：王皓南·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/网管（当前：杨明学·推断待确认）、客户端/Agent 研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监/对客通报（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 报障建卡 → ② 定级并指定指挥人 → ③ 首次通报 → ④ 定位与止血 → ⑤ 定时同步进度 → ⑥ 恢复确认与对客通知 → ⑦ 事故报告与复盘 → ⑧ 改进项转工单闭环故障台账记录（级别、影响面、时间线）；恢复通报；P0/P1 事故复盘报告（存入统一目录）；已排期的改进项工单待新建500
RND-76用户问题日志收集与定位单个用户或测试报“执行失败、卡死、白屏、400/401/402、生图/PPT 失败、启动失败”时，按清单一次收齐版本、环境、模型档位、截图、trace_id 和诊断包；研发据此逐层定位（客户端 → 内网服务 → 公网服务 → 网关 → 上游），回复结论或建单主责——客户端问题定位接口人（当前：岳阳·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapCore 服务端/部署研发（当前：杨云峰、宋祺睿·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）、LeapPPT/生图研发（当前：马漳毓·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 用户按清单反馈 → ② 机器人补问缺项 → ③ 一键上传诊断包并关联工单 → ④ AI 初判 → ⑤ 研发逐层定位 → ⑥ 复现确认 → ⑦ 回复结论/绕行办法并建单 → ⑧ 沉淀 FAQ带完整环境信息和日志链接的问题工单；给反馈人的定位结论或临时绕行办法；更新后的常见错误 FAQ待优化120
RND-77错误提示、日志上报与可观测性规范新功能开发、客户端/网关/后端改造，或复盘发现报错“看不懂、查不到、对不上”时，按统一规范设计用户可见的错误提示、错误码映射、贯穿全链路的 trace_id、错误上报（PostHog/Grafana）以及日志保留与降噪，并在评审和 CI 中检查主责——可观测性负责人（当前：魏宗浩·推断待确认）；协同——Leap 研发技术负责人（当前：王皓南·推断待确认）、客户端研发（当前：岳阳·推断待确认）、v5 网关研发（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 汇总问题 → ② 起草/修订规范 → ③ 评审发布 → ④ 开发落地 → ⑤ CI 与测试校验 → ⑥ 线上抽查与降噪 → ⑦ 版本化修订《错误提示与可观测性规范》（错误码字典、提示文案、trace_id 规则、上报字段、环境区分、数据保留策略）；规范落地的代码和 CI 检查；统一的查询入口页待新建81
RND-78生产告警认领、分级与降噪监控机器人推送生产告警（Grafana 错误日志检测、EasyPlay 告警、死信队列告警、Redis Sentinel、定时巡检任务告警）时，负责认领、分诊、修复和关闭；同类误报反复出现时，调整阈值、日志级别、通知对象和模板，且变更前先在测试群验证主责——告警值班人（建议按周轮值；当前：王子明·推断待确认）；协同——跃竞运维（当前：席博田·推断待确认）、跃竞后端（当前：蒋兴武、张楠·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）① 告警分级推送 → ② 值班认领 → ③ 分诊（真实故障/业务异常/误报/第三方）→ ④ 指派或升级 → ⑤ 处置 → ⑥ 关闭登记 → ⑦ 每周降噪 → ⑧ 规则变更先测后发每条告警都有认领人和处置结论（台账记录）；《告警分级与日志级别规范》和忽略清单；经测试的告警规则/模板变更记录待优化80
RND-79服务器容量治理与内部研发基础设施故障服务器磁盘/日志暴涨、系统参数（inotify、磁盘类型、分区）不满足部署基线，或 Gitea/CI/NAS/内网服务器断网掉电、硬件损坏、服务迁集群或改地址时，做容量基线检查、日志轮转、故障报修排期和地址变更通知主责——IT 运维/基础设施负责人（当前：杨明学·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、开放平台后端/运维（当前：杨睿·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 建立服务台账 → ② 部署前基线检查 → ③ 容量监控告警 → ④ 报修建单 → ⑤ 响应与排期 → ⑥ 清理/扩容并补治理 → ⑦ 变更前公告 → ⑧ 验证并更新台账服务器与服务台账（服务、负责人、地址、磁盘、证书到期）；部署基线检查记录；磁盘/日志告警和日志轮转配置；基础设施工单与变更公告待新建108
RND-80系统/主体迁移与生产数据订正业务主体或支付商户迁移、老系统迁服务器、测试环境转正式或新旧版本切换、内部生产环境迁移；以及线上缺陷产生异常订单/金额数据，需要圈定影响范围并订正或退款时主责——迁移/订正负责人（按系统指定；当前：跃玩线 王子明、Leap 线 王皓南·推断待确认）；协同——跃竞负责人（当前：徐莉·推断待确认）、产品总监（当前：杨萌·推断待确认）、运维（当前：席博田、杨明学·推断待确认）、后端（当前：蒋兴武、张楠·推断待确认）、前端（当前：魏小东·推断待确认）、测试（当前：赵伟龙·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）① 立项与影响评估 → ② 迁移清单与负责人 → ③ 迁移测试演练 → ④ 备份 → ⑤ 公告与冻结 → ⑥ 执行 → ⑦ 核对验收 → ⑧ 切换与观察 → ⑨ 数据订正（分支）→ ⑩ 归档带回滚点的迁移方案和检查清单；迁移前备份和迁移后核对报告；停服/切换通知；数据订正审批单与执行记录；异常订单台账待新建250
RND-81内部 AI 机器人/Agent 平台部署、配置与使用边界要在飞书群或私聊中上线、升级、迁移、下线内部 AI 机器人（OpenClaw、Hermes、LeapAll 机器人、工单助手、排障 MCP 助手、许愿机等），或机器人出现越权、刷屏、乱提单、幻觉、配置丢失、不响应时启动主责——内部 AI 机器人平台负责人（当前：王皓南·推断待确认）；协同——运维/镜像维护（当前：宋祺睿、杨明学·推断待确认）、各机器人 owner（当前：岳阳、杨萌、魏宗浩、王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、飞书管理员/安全（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 上线登记 → ② 权限矩阵评审 → ③ 按模板配置 → ④ 镜像构建与部署 → ⑤ 上线前测试 → ⑥ 发布使用说明 → ⑦ 规则变更走评审 → ⑧ 故障值守与月度复核机器人台账中的完整登记（owner、备岗、模型、技能、权限、可用范围、成本上限）、受版本管理的配置与提示词、群内使用说明卡片、变更与故障记录待新建192
RND-82Agent 评测集与评测体系需要量化 Agent（LeapAgent/LeapAll/LeapCore）或某个模型、skill 的能力，发版前做回归评测，多方案赛马，或测算行业报告生成效果与单篇成本时启动主责——Agent 评测负责人（当前：张东郅·推断待确认）；协同——Leap 研发负责人（评测方向与流程设计，当前：王皓南·推断待确认）、产品总监（功能清单与跟进会，当前：杨萌·推断待确认）、评测工程师（当前：黄霆瑄、董洪焜·推断待确认）、Agent 研发（当前：岳阳、李铭熙·推断待确认）、报告跑测研发（当前：陈锦杰、黄飞鹏·推断待确认）、业务专家（当前：王满·推断待确认）、模型网关 API owner（当前：柯逸飞·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 定评测目的与基线 → ② 建/更新评测集与 verifier → ③ 准备环境、账号与额度 → ④ 批量跑评测 → ⑤ 失败聚类归因 → ⑥ 改动后定向+回归评测 → ⑦ 出报告并例会审阅 → ⑧ 失败样本回流版本化评测集（case、verifier、评分标准）、评测报告（图表/HTML，含得分、成本、时长、失败归因）、评测看板、发版回归结论待优化192
RND-83Agent 生成文档质量问题治理LeapCore/LeapAll 生成的 PPT、Word、Excel、HTML 出现格式错乱、字体缺失、水印、标题颜色异常、导出失败、预览不全等问题，或客户演示前需确认默认文档格式与组织模板时启动主责——文档生成研发负责人（当前：马漳毓·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Word 套件研发（当前：邓乾·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、业务专家/组织模板维护（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、方案研发（当前：陈锦杰·推断待确认）、销售演示人（当前：吴琪·推断待确认）、法务（字体版权，当前：李瑶）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 收集反馈 → ② 补齐原始提示词与文件提 issue → ③ 分类打标 → ④ 阻断类当天止血 → ⑤ 两周一次集中归因 → ⑥ 修模板/skill/导出链路 → ⑦ 文档回归样例集回归 → ⑧ 发版通知与演示前检查已分类的文档质量问题清单、公司默认格式模板（以国标公文为基准）及版本记录、文档产出回归样例集与回归报告、修复发版说明、演示前检查记录待优化180
RND-84知识库数据清洗入库与更新行业知识库（字字可研/工程版数据源）内容过时需更新，或新采集、外包交付的数据要清洗、迁移入库、打标签，以及新增行业 skill 需分类并绑定行业时启动主责——知识库数据研发（当前：魏宗浩·推断待确认）；协同——运维/数据库（入库窗口与标签脚本，当前：宋祺睿·推断待确认）、产品总监（发起与进度，当前：杨萌·推断待确认）、开放平台负责人（行业标签与下发，当前：郭逸非·推断待确认）、LeapAll 服务端（skill 分类方案，当前：邓乾·推断待确认）、产品经理（分类审核，当前：黄飞鹏·推断待确认）、业务专家（内容抽检，当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 更新立项 → ② 检视/重写爬虫并采集 → ③ 清洗 → ④ 申请入库窗口并迁移 → ⑤ 跑标签 → ⑥ 行业与 skill 绑定 → ⑦ 业务抽检验收 → ⑧ 关闭窗口、归档数据版本更新后的知识库数据（含本次 updated_at 范围）、标签完成报告、行业与 skill 绑定表、验收记录、数据版本说明与导出备份待新建72
RND-85研发工作与项目交接研发成员离职、调岗、借调结束、实习结束、长期请假，或项目/模块/系统负责人更换、MVP 从作者转给维护者时，完成工单、代码、文档、环境、账号权限、待办与上下文的移交并由接手人签收主责——交出方所属团队技术负责人（当前：王皓南·推断待确认，非 Leap 产研团队由对应技术负责人担任）；协同——交出方原负责人、接手方新负责人、Gitea/服务器权限管理员（当前：宋祺睿·推断待确认）、IT 资产与服务器台账（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 指派交接与截止日 → ② 交出方按模板写 handoff → ③ 工单完成、释放或转派 → ④ 仓库迁组织仓并转移权限 → ⑤ 交接会与读代码/演练 → ⑥ 接手人逐项签收 → ⑦ 更新台账并公告新负责人 → ⑧ 回收交出方权限、30 天答疑签收的 handoff 文档（统一模板，存仓库 docs/handoff 并链接飞书）、转派完毕的工单、更新后的系统台账（负责人、仓库、服务器、域名）、新负责人公告、权限变更记录待新建144
RND-86技术文档与上下文知识沉淀调研/实验性工作结束、踩到需要告诉后来者的坑、新人或 AI 反复需要项目背景、跨团队需要产品与技术全景、AI 会话记录需要留存时，按统一位置和模板沉淀文档主责——研发负责人（当前：王皓南·推断待确认）；协同——各项目技术负责人/文档 owner、运维/发版（仓库文档约定，当前：宋祺睿·推断待确认）、开放平台后端（产品架构文档，当前：杨睿·推断待确认）、开放平台/FDE 课程负责人（当前：吴亚军·推断待确认）、产品总监（当前：杨萌·推断待确认）、支付研发顾问（踩坑文档，当前：王子明·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 判定沉淀类型 → ② AI 生成初稿、作者核对 → ③ 放入约定位置 → ④ 更新 AGENTS.md 索引 → ⑤ 迭代末审阅调研文档 → ⑥ PR 附带文档更新 → ⑦ 会话归档 → ⑧ 季度清理仓库 docs 分类文档与 AGENTS.md 索引、飞书知识库项目页、调研文档与审阅纪要、踩坑记录、AI 会话归档待新建72
RND-87技术分享、内部 Skill/工具发布与推广研发做出可复用的内部 skill、插件、小工具或配置包，或有值得推广的技术经验、评测结果、新规范，需要评测、登记、发布、分享培训并收集反馈时启动主责——研发负责人（当前：王皓南·推断待确认）；协同——Skill/工具作者（当前：马漳毓、邓乾、柯逸飞、张东郅·推断待确认）、评测（当前：黄霆瑄·推断待确认）、Skill 宣讲（当前：李凯·推断待确认）、内部开源工具负责人（当前：李子遥·推断待确认）、产品总监（产品化判断，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 作者发布登记 → ② 安全扫描与 eval → ③ 推组织仓打版本 → ④ 写使用说明 → ⑤ 机器人发群并入目录 → ⑥ 周五分享/学习任务 → ⑦ 反馈迭代 → ⑧ 月度产品化或下架评估内部 Skill/工具目录中的登记（名称、owner、版本、仓库、安装方式、eval 结果、反馈入口）、发布说明与教程、分享排期与录屏纪要、技术主管周成果汇总待优化72
RND-88外包数据采集委托与验收需要批量采集网站数据（招投标、政务站点、行业资料等）而内部人手不足，决定委托外部团队或分包采集时，覆盖合规评估、委托约定、样例确认、分批交付验收到结单付款全过程主责——数据采集负责人（总包验收方）（当前：魏宗浩·推断待确认）；协同——外包审批与结单人（当前：丁震宇·推断待确认）、数据接入/运维（当前：宋祺睿·推断待确认）、产品总监（需求与进度，当前：杨萌·推断待确认）、Leap 研发负责人（验收要求，当前：王皓南·推断待确认）、业务验收专家（当前：待指定）、法务负责人（当前：李瑶·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 写需求并评估自采/外包/采购 → ② 站点合规评估 → ③ 选外包并签约 → ④ 分配任务与字段规范 → ⑤ 样例验收 → ⑥ 分批交付自动校验 → ⑦ 业务抽检 → ⑧ 结单付款并转入库外包任务表（站点、分包方、状态）、签署的委托合同（含数据来源合法与保密条款）、样例与分批验收记录、验收报告、结单付款审批、移交入库的数据待新建200
RND-89对外技术咨询答复与方案文档评审市场、销售、厂商或合作方询问技术可行性、产品能力，或研发写好的技术方案/产品说明/演示视频需要发给客户时，由研发统一受理、评估答复并在对外发出前完成评审主责——研发技术咨询接口人（当前：丁震宇·推断待确认）；协同——信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、Leap 架构/运维研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、提问方销售/市场（当前：李鹏为、许君·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提交咨询单 → ② 接口人分级派单 → ③ 领域负责人评估 → ④ 形成结论与承诺边界 → ⑤ 对外材料评审 → ⑥ 统一渠道发出 → ⑦ 沉淀 FAQ/口径库带可行性等级与承诺边界的书面答复；经评审签发的对外技术方案/产品说明；更新后的产品能力 FAQ 条目待新建240
RND-91产品版本生命周期与私有化实例版本支持策略LeapCore 等产品同时存在多个在用版本（客户私有化、一体机、渠道实例、信创版），需要明确支持哪些版本、何时停止支持、客户如何升级主责——研发发布负责人（当前：待指定）；协同——产品负责人（当前：待指定）、交付负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 制定版本支持规则 → ② 发版时登记版本与支持截止日 → ③ 每季度盘点在用版本分布 → ④ 停止支持前提前通知 → ⑤ 推动升级 → ⑥ 到期停止补丁并登记例外版本支持策略文件、版本生命周期表、在用版本分布表、停止支持通知待新建96
RND-92研发数据使用合规（数据集登记、客户数据授权与脱敏）研发在评测、微调、调试、复现问题、构建知识库或评测集时，需要使用客户数据、生产数据、外部采集数据或公开数据集主责——数据集管理员（当前：待指定）；协同——使用数据的研发人员、法务（当前：待指定）、信息安全负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提出用途申请 → ② 核对来源与授权 → ③ 脱敏或取最小样本 → ④ 登记数据集 → ⑤ 受控存放与访问 → ⑥ 到期删除并留痕数据集登记表、用途审批记录、脱敏记录、删除记录待新建90

GEN 综合部统筹 报送人：赵雪冰

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
GEN-01制度与 SOP 起草、签发与发布宣贯任一部门要出台或修订公司级/部门级制度、规则、SOP（含集团制度需同步到子公司），或同类事务在 IM 中被反复询问、需要沉淀为 SOP 时启动主责——总经办制度统筹（当前：赵雪冰·推断待确认）；协同——制度起草部门负责人（人事：黄莹、财务：黄梦婷·推断待确认）、行政签章（当前：侯明月·推断待确认）、行政 SOP 合集维护（当前：胡则瑾·推断待确认）、总经办通知（当前：田杰、王欣·推断待确认）、SOP 技术载体（当前：柯逸飞·推断待确认）、子公司负责人（当前：徐莉·推断待确认）；签发——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项登记 → ② 起草（含适用范围） → ③ 草案共享批注 → ④ 部门负责人审 → ⑤ 总经办初审 → ⑥ 盖章与 CEO 签发 → ⑦ 公示发布与宣讲答疑 → ⑧ 入库归档、子公司同步与试运行复盘已签发并盖章的制度/SOP 正式版（含版本号、适用范围、生效日期、FAQ）、发布通知与宣讲录屏、知识库/SOP 合集条目、试运行复盘记录待优化240
GEN-02全员通知发布与必读信息分级需要全员或多部门知晓、配合的事项（放假、制度、活动、地点变更、居家安排、表单填报、重要决策）要对外发布时启动主责——总经办通知专员（当前：田杰·推断待确认）；协同——人事（当前：黄莹·推断待确认）、行政（当前：侯明月·推断待确认）、总经办（当前：赵雪冰·推断待确认）、各部门负责人（当前：杨萌等·推断待确认）；规则制定——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 判定等级与渠道 → ② 与相关负责人对齐 → ③ 按模板撰写 → ④ 通知群发布并同步负责人群 → ⑤ 负责人传达 → ⑥ 已读/回执统计 → ⑦ 截止前催办 → ⑧ 归档按模板发布的正式通知（一句话版+完整版）、已读/回执名单、重要通知归档记录待优化120
GEN-03工作沟通渠道与群职能规则任何工作事项需要沟通（需求、进展、问题、文档、客户信息）时，用于决定在哪个群/工单/文档里说，以及新建项目或群时设定群职能主责——总经办（当前：田杰·推断待确认）负责规范成文、群公告与培训；协同——规则发起与裁决 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、各群群主/项目负责人；兜底——CEO（当前：邴龙志·推断待确认）① 判断事项类型 → ② 选择渠道（项目群/工单/会议/文档） → ③ 公开沟通并 @责任人 → ④ 结论沉淀到文档/工单 → ⑤ 群置顶归集 → ⑥ 偏离时提醒与转移成文的《工作沟通规范》、各群群公告（群职能）、项目群置顶总目录、留痕可追溯的沟通记录待优化120
GEN-04沟通礼仪与对内外称谓、时间规范在工作群反馈问题、接任务、给客户或同事发工作消息、对内外称呼他人时，用于统一表达方式、发送时间与称谓主责——人事负责人（当前：待指定）负责成文写入员工手册与入职培训；协同——规则发起 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维负责人（当前：宋祺睿·推断待确认）；兜底——综合部负责人① 成文三项规范（表达、时间、称谓） → ② 写入员工手册与群公告 → ③ 入职培训讲解 → ④ 日常按模板执行 → ⑤ 偏离时就事提醒 → ⑥ 季度回顾修订《沟通礼仪与称谓规范》（员工手册章节）、问题反馈模板、对外消息定时发送规则待新建27
GEN-05临时加急审批与关键人联络飞书审批事项紧急而审批人外出、开会或未及时查看飞书，或需要尽快联系到不常看飞书的关键人员时启动主责——飞书审批管理员/人事（当前：黄莹·推断待确认）负责代理人配置与联络升级；协同——审批人（当前：丁震宇·推断待确认）、申请人（行政：侯明月、研发：葛家和等·推断待确认）、IT/飞书管理（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 申请人判定紧急等级 → ② 提交审批并标注加急 → ③ 飞书加急提醒 → ④ 超时转代理审批人 → ⑤ 电话联络关键人 → ⑥ 事后补审与记录按时完成的审批单（含代理审批记录）、审批代理人清单、关键人紧急联络表待新建54
GEN-06节假日前工作安排与值班连续 3 天及以上假期（春节、五一、国庆等）前，研发、产品、客户支持需要规划节前任务、决定发版冻结、安排值班与应急联络时启动主责——产品总监/迭代负责人（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、各值班责任人、客服/客户反馈对接人（当前：待指定）、人事（放假通知，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 假期前 3 周启动节前规划 → ② 迭代不跨假期、定发版冻结日 → ③ 排研发值班与反馈值班 → ④ 定客户升级兜底人与应急联络 → ⑤ 发布值班表 → ⑥ 假期值守与记录 → ⑦ 节后交接复盘节前任务清单、发版冻结通知、假期值班表（研发+客户反馈）、应急联络与升级路径、节后值班记录与复盘待新建96
GEN-07内部分享会与学习活动组织组织周五例行分享、AI 总动员讲座、全员培训日、销售研讨会、英语等学习小组，或公司承办/参加有保密要求的分享活动时启动主责——学习委员（当前：杨萌·推断待确认）；协同——学习委员（当前：陈梦琪·推断待确认）、各组小组学委（当前：宋祺睿、胡橙橙等·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、会务/卫生委员（当前：侯明月、赵雪冰·推断待确认）、活动助理（当前：杨黔昆·推断待确认）、主持人（当前：闫登辉·推断待确认）、审稿人（当前：丁震宇·推断待确认）；发起与激励——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 议题征集与认领 → ② 排期与确认内/外部类型 → ③ 场地与日程发布 → ④ 讲稿/材料审阅 → ⑤ 保密与录制规则确认 → ⑥ 举办与录屏 → ⑦ 资料入库与积分登记分享排期表、飞书日程与通知、审定讲稿/PPT、录屏与 AI 摘要、知识库分享归档、积分/激励登记待优化48
GEN-08团建与内部文体活动组织公司或团队组织聚餐、团建、趣味比赛、节日快闪，或员工自发组织 KTV、奶茶、桌游等活动，需要通知、报名、费用与奖品安排时启动主责——行政（当前：侯明月·推断待确认）；协同——文体委员（当前：王皓南·推断待确认）、活动发起人（当前：杨萌、张东郅等·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务（当前：待指定）；经费审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 发起与立项 → ② 预算申请 → ③ 投票/报名 → ④ 确认人数后预订 → ⑤ 通知与提醒 → ⑥ 执行（采购/奖品） → ⑦ 报销结算与登记活动报名/投票结果、已审批预算、预订与采购记录、活动通知、费用报销单与活动登记待优化36
GEN-09AI 工具订阅开通与使用补贴管理公司统一采购的 AI 订阅（如 SoruxGPT 套餐）开通、升级或月度换 CDK，以及公司要求员工使用自有 AI 产品（LeapAll/LeapCore）而需要发补贴、统计充值、调整补贴规则时启动主责——AI 工具与补贴管理专员（当前：侯明月·推断待确认）；协同——产品总监/内部使用规则发布人（当前：杨萌·推断待确认）、LeapAll 服务端后台数据（当前：邓乾·推断待确认）、创始人兼 CTO（套餐选型与研发补贴试点，当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 采购/规则确定 → ② 开通名单登记与核对 → ③ 全员通知 → ④ 月度 CDK/补贴发放 → ⑤ 次日充值与使用统计 → ⑥ 月末核对与补贴扣减 → ⑦ 超额报销/额度调整 → ⑧ 季度复盘规则AI 工具开通名单与套餐台账、每月 CDK 分发与激活记录、月度充值/使用统计表、补贴扣减与超额报销清单、成文的补贴规则（含试点细则）待优化108
GEN-10自研产品内部推广使用与反馈闭环LeapCore/LeapAll 等自研产品需要在公司内部部署、发账号、安装培训并要求各职能部门真实使用和反馈时启动主责——总经办内部推广负责人（当前：赵雪冰·推断待确认）；协同——产品发布负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、各部门负责人（当前：黄莹、黄梦婷、胡则瑾、田杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 产品发布内部使用包 → ② 账号与远程接入开通 → ③ 总经办下达部门任务 → ④ 部门建团队空间与安装试用 → ⑤ 分层培训 → ⑥ 反馈统一登记 → ⑦ 每周汇总给产品并回告 → ⑧ 月度使用复盘各部门完成安装与团队空间创建的清单、培训签到与录屏、内部反馈登记表及每周汇总、月度内部使用情况报告待优化90
GEN-11集团档案整理与合同台账管理集团需要建立或执行电子/纸质档案归档规则、组织年度/专项档案盘点，或审计、内控、尽调、领导需要查找合同、制度、资质、项目资料时启动主责——档案委员（当前：田杰、胡则瑾·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、合同整理与盖章（当前：侯明月·推断待确认）、人事/财务档案（当前：黄莹、黄梦婷·推断待确认）、各部门档案组长（当前：丁震宇、李鹏为、许君、鲁周毅、杨明学、韩诗琪、谌思铭、黄飞鹏·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 档案办法制定与审批 → ② 设档案委员与部门组长 → ③ 发前置准备通知 → ④ 排期逐部门盘点 → ⑤ 登记档案台账与合同台账 → ⑥ 纸质入档案室、电子入线上档案库 → ⑦ 权限与借阅登记 → ⑧ 月度自查、季度抽查成文的档案管理办法、集团档案台账（一级目录）、按主体分开的合同台账、线上档案库与档案室、借阅登记、月度自查与季度抽查记录待优化240
GEN-12知识库与协作文档沉淀（含飞书空间治理）项目或团队产生正式文档需要统一进知识库，团队需要建立协作基准与个人工作说明，在飞书以外工具（Agent）产出的文档需要回到飞书协作，或飞书多维表格工作台视图、权限混乱需要治理时启动主责——各项目/团队知识库管理员（当前：杨萌·推断待确认）；协同——团队协作基准编制人（当前：陈梦琪·推断待确认）、文档汇总维护人（当前：葛家和·推断待确认）、Agent 与共享上下文方法（当前：丁震宇·推断待确认）、全体项目成员；兜底——创始人兼 CTO① 按模板建知识库目录 → ② 定命名与版本规则 → ③ 正式文档在知识库创建或定稿后归档 → ④ 外部 Agent 产出导入飞书再协作 → ⑤ 项目上下文文档日更 → ⑥ 工作台视图与权限按规则配置 → ⑦ 月度检查与清理按统一目录组织的项目/团队知识库、协作基准文档（含个人说明书）、项目上下文文档、权限与视图规则清晰的工作台、月度检查记录待优化72
GEN-13荣誉资质、宣传素材与对外信息口径库对外申报、媒体拍摄、峰会演讲、外部活动或路演表单需要用到公司荣誉资质、标准公司/产品介绍或公司基本信息（主体、融资阶段、核心数据）时，从统一的库里取用；库内容新增或变化时更新主责——总经办素材与口径库管理员（当前：田杰·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、产品总监（当前：杨萌·推断待确认）、生态市场负责人（当前：许君·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）；口径终审——CEO（当前：邴龙志·推断待确认）① 建库分类与维护人 → ② 收集最新素材 → ③ 定标准介绍与口径页 → ④ CEO 审定 → ⑤ 按需取用 → ⑥ 外部表单按口径填报 → ⑦ 新荣誉/新版本即时入库 → ⑧ 季度复核分类清晰、有维护人和版本号的素材与口径库（荣誉资质、公司介绍、产品介绍、行业版、案例、视频），公司对外信息口径页，外部表单填报记录待新建108
GEN-14公司对外账号、证照年检与年报管理公司公共手机号/邮箱、公众号/小程序/服务号、以公司或财务身份注册的第三方平台账号需要开通、交接、收验证码，或 LEI 编码年检、工商年报、增值电信年报、认证续费等周期事项临近时启动主责——总经办账号与证照管理员（当前：田杰·推断待确认）；协同——财务账号持有人（当前：黄梦婷·推断待确认）、行政/电话卡管理（当前：侯明月·推断待确认）、公共邮箱与技术账号（当前：丁震宇·推断待确认）、营业执照登记（当前：王欣·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建账号与周期事项总台账 → ② 绑定公共手机号/邮箱 → ③ 新开通按申请登记 → ④ 研发需用时开子账号 → ⑤ 到期前 30 天机器人提醒 → ⑥ 责任人办理年检/年报/续费 → ⑦ 结果存档 → ⑧ 季度盘点公司对外账号与证照/编码/年报总台账、年审与续费日历、公共手机号与邮箱分配记录、各平台子账号分配记录、年报与年检回执存档待新建225
GEN-15工商变更与新机构设立手续公司发生增资扩股、股东变更、地址变更等工商变更，或需要新设研究院、子公司等机构，并且有明确完成节点时启动主责——综合部工商经办（当前：侯明月·推断待确认）；协同——COO（股东材料，当前：常元和·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：祁航·推断待确认）、法务（当前：待指定）；兜底——综合部负责人；发起与审批——CEO（当前：邴龙志·推断待确认）① 发起任务单（事项+节点） → ② 确认变更项与材料清单 → ③ 收集材料 → ④ 股东会/董事会决议与法务审核 → ⑤ 用印 → ⑥ 提交办理 → ⑦ 领取新执照 → ⑧ 同步税务、银行、社保、证照库与档案新营业执照或设立登记证明、变更登记通知书、经盖章的决议与章程修正案、后续同步事项完成清单、归档材料待新建80
GEN-16政府/领导及合作伙伴来访接待省市领导、政府部门到公司参观视察，或外部合作伙伴来访授牌、挂牌时，由总经办统筹接待方案、动线、陪同、讲解、摄影和事后归档主责——总经办接待统筹（当前：赵雪冰·推断待确认）；协同——管理层陪同（当前：邴龙志、丁震宇、常元和·推断待确认）、品牌摄影（当前：待指定）、行政（当前：待指定）；兜底——综合部负责人① 接收来访信息并确认要素 → ② 出接待方案 → ③ 分工与报备 → ④ 提前 1 天现场检查 → ⑤ 当天接待与控时 → ⑥ 事后材料存档、物品归位 → ⑦ 照片入库与宣发 → ⑧ 复盘更新模板接待方案（时间、动线、讲解点、陪同人、物料、摄影、着装）、现场照片、授牌/材料存档记录、接待复盘待新建72
GEN-17AI 前沿资讯跟踪与新工具评测分享成员发现 AI 新模型、新工具、行业文章或竞品动态，需要在内部转发沉淀、判断是否试用、产出评测结论并分享时启动主责——产研 AI 情报与评测统筹人（当前：王皓南·推断待确认）；协同——资讯机器人维护人（当前：宋祺睿·推断待确认）、鼎慧产研资讯组织人（当前：杨萌·推断待确认）、工具试用评测人（当前：魏宗浩、季学森、岳阳、宫经喜等·推断待确认）、内部宣讲人（当前：李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 转发并打标签 → ② 机器人抓摘要、去重入库 → ③ 日报/周报精选 → ④ 认领试用 → ⑤ 按模板评测 → ⑥ 审阅定结论 → ⑦ 周五分享 → ⑧ 结论归档与落地多维表格「AI 情报库」中带摘要和标签的资讯条目；统一模板的工具评测文档（含结论：采用/参考/观望/不推荐）；分享会纪要；“采用”项转入 X-PRD-09（需求池）或 FIN-02（新购开通）的记录待优化80
GEN-18制度与 SOP 定期复审、版本管理与废止已发布的制度与 SOP 需按周期复审；组织、系统、业务变化导致内容失效；同一事项存在多份版本冲突主责——制度管理员（当前：待指定）；协同——各 SOP 主责岗位、各部门负责人、法务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 建立制度/SOP 总目录 → ② 到期提醒 → ③ 主责复审（保留/修订/废止）→ ④ 修订走 GEN-01 → ⑤ 废止公告与下架 → ⑥ 更新目录制度/SOP 总目录（编号、版本、主责、复审日、状态）、复审记录、废止公告待新建60
GEN-19员工意见反馈、投诉与违规举报受理员工对制度、管理或同事行为有意见与投诉；或发现收受回扣、利益冲突、虚假报销、私卖公司数据或资源等违规行为需要举报主责——合规受理专员（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 公布受理渠道 → ② 登记分级 → ③ 指定调查人并回避 → ④ 调查取证 → ⑤ 处理决定 → ⑥ 反馈举报人 → ⑦ 保密归档受理登记、调查报告、处理决定、反馈记录待新建36
GEN-20外部来文来函收发登记与分办公司收到政府部门通知/公文、监管函、律师函、法院或仲裁文书、税务/社保通知、客户或供应商正式函件（纸质、邮件、平台站内信、挂号信等）主责——收文专员（当前：待指定）；协同——法务（当前：待指定）、行政（当前：待指定）、各承办部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 统一收文登记 → ② 当日判定类型、紧急度与回复期限 → ③ 分办承办部门 → ④ 承办人确认接收 → ⑤ 按期办理或回函 → ⑥ 发文用印 → ⑦ 归档收发文登记台账、分办记录、回函/办结记录、归档文件待新建48

CEO 总经办 报送人：田杰

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
CEO-01年度/季度/月度规划与目标分解年终复盘、每季度初或每月初，需要先定公司级目标，再分解到部门、负责人和个人关键事项时启动主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、各部门负责人（当前：生态市场 许君、产品 杨萌、Leap 研发 王皓南·推断待确认）、总经办（当前：待指定）、人事负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 复盘并定公司级目标 → ② 发规划模板 → ③ 部门报规划并挂靠目标 → ④ 负责人对齐会定版 → ⑤ 事项分解到人并写验收标准 → ⑥ 一对一/OKR 确认 → ⑦ 月度跟踪复盘定版的公司级目标清单、各部门规划（每项挂靠一个公司目标，含负责人/验收标准/截止日期）、个人 OKR 与一对一记录、目标跟踪表待优化135
CEO-02战略论证会与闭门专题研讨CEO 召集各负责人做战略/经营论证，或就某一体系（如市场体系）开闭门专题研讨，需要会前准备、会后作业与跟进时启动主责——总经办/综合部负责人（当前：赵雪冰·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，发起与主持）、各部门负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起议题 → ② 锁定时间与会议室 → ③ 发议程与会前共享文档 → ④ 参会人预读并带方案 → ⑤ 开会录妙记 → ⑥ 发纪要与作业 → ⑦ 跟踪作业提交 → ⑧ 同步会议重点并转任务会议纪要（含决议）、作业清单与提交物、会议重点同步消息、转入飞书任务的落实事项待优化135
CEO-03新业务/创新项目立项与拍板员工提出新业务方向或创新 idea、AI 创新 lab 收到内外部小需求、子公司负责人提出业务打法/授权/融资诉求，需要立项、拿预算或拍板时启动主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、AI 创新 lab 内部创新负责人（当前：杨萌·推断待确认）、AI 创新 lab 外部创新负责人（当前：陈梦琪·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 提交立项单 → ② 登记入池 → ③ 初评分级 → ④ 按级别审批（预算/授权/融资）→ ⑤ 指定负责人与验证期 → ⑥ MVP/试运行 → ⑦ 验收评估 → ⑧ 转运营、继续或终止归档已审批的立项单（目标、负责人、预算、期限、验收标准）、立项台账、决策纪要、验收结论与归档记录待新建144
CEO-04重大技术/产品方案决策（拍板、公示与记录）研发或产品对方案出现分歧（计费归属、职责下发位置、模型选型等），或需要对需求优先级、技术取舍、技术路线与产品方向做决定时启动主责——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、方案提出人；兜底——CEO（当前：邴龙志·推断待确认）① 发起决策单 → ② 判定决策级别 → ③ 限时讨论 → ④ 公示或评审会 → ⑤ 拍板 → ⑥ 写决策记录并同步 → ⑦ 测试环境验证后上线 → ⑧ 复议走正式通道决策记录（议题、选项、依据、结论、决策人、生效时间），同步到相关群与决策记录表待新建192
CEO-05决策授权与汇报路径（去单点、防越级）需要明确哪些事由各负责人自行决定、哪些须报 CEO/COO，以及资源、权限、技术类问题"找谁"、跨主体或高层需求如何传达时启动；也用于新负责人任命后的授权书面化主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、总经办（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 盘点高频问题与决策事项 → ② 制定授权矩阵与"找谁"清单 → ③ 书面任命各组负责人 → ④ 发布并配置问答机器人 → ⑤ 按"结论+依据"汇报 → ⑥ 跨主体需求按入口传达 → ⑦ 每季度复核授权矩阵（事项×决策层级）、问题分类"找谁"清单、各组负责人书面任命、一页纸汇报模板、跨主体需求传达路径说明待新建300
CEO-06组织架构、汇报线与职责边界调整新业务、新团队、新人加入或主体合并，需要重新划分部门、负责人、直属上级、职责边界或用工主体，并同步飞书时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定架构）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、飞书管理员（当前：待指定）、财务负责人（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提出调整需求 → ② 起草架构与职责边界 → ③ 限时审阅定版 → ④ 影响评估（主体/审批/权限/群/考勤）→ ⑤ 发布通知（生效、交接、反馈截止）→ ⑥ 收集反馈修正 → ⑦ 飞书同步 → ⑧ 用工主体迁移 → ⑨ 30 天复盘定版组织架构图与人员架构表、职责边界 RACI 表、调整通知、飞书组织架构/直属上级/审批代理/部门群同步完成、人员主体台账更新待优化240
CEO-07多项目优先级与人力分配多个客户项目、新业务、内部产品同时推进，同一批人被多线抢占，或有人手头项目结束无人安排、商务/政府需求不断涌入时启动主责——研发资源协调人（当前：丁震宇·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/商务负责人（当前：刘昱潇·推断待确认）、各项目负责人（当前：待指定）、人事负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求统一入口并准入评分 → ② 每周资源盘点 → ③ 周优先级会排序 → ④ 发布周分工 → ⑤ 成员先写 plan 再开工 → ⑥ 插单走变更 → ⑦ 周五进度汇报 → ⑧ 缺口走外包或招聘项目池（含优先级 P0/P1/P2）、项目×人员占用看板、每周分工公告、变更记录、周进度汇报待优化400
CEO-08跨部门人员借调与技术人员外派审批其他部门需要临时借用本部门人员，或商务需要技术/FDE 人员去客户现场、参加对外会议，涉及优先级冲突与差旅成本时启动主责——借出部门负责人（当前：研发线 丁震宇、FDE/开放平台 郭逸非·推断待确认）；协同——需求发起人（商务/销售，当前：刘昱潇·推断待确认）、被借调/外派人员、行政（差旅预订，当前：待指定）、财务（差旅费用，当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起人与技术先对齐可行性 → ② 提交借调/外派申请 → ③ 借出部门负责人审批 → ④ 冲突时升级 → ⑤ 差旅预订 → ⑥ 定会议角色并执行 → ⑦ 纪要回传 → ⑧ 归还确认已审批的借调/外派单（目的、人员、时间、成本、DDL）、会议/外勤纪要、归还确认待新建108
CEO-09项目启动与重大事项跨组对齐会新项目启动、客户需求突变，或与供应商/客户谈判前，需要把产研、市场、基座组拉齐目标、分工、里程碑与对外话术时启动。主责——项目负责人/发起人（当前：丁震宇·推断待确认）；协同——项目管理/产品协调（当前：杨萌·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、研发执行负责人（当前：杨明学、杨云峰·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 判定需对齐 → ② 建日程并发会议通知 → ③ 会前材料就位（谈判分支备目标价/底线/话术）→ ④ 会上定目标、分工、选型、里程碑 → ⑤ 纪要与决议登记 → ⑥ 各人登记里程碑 → ⑦ 会后变更同步 → ⑧ 周期进度同步启动会/对齐会纪要、决议登记（目标、分工、里程碑、对外口径）、里程碑文档、谈判对齐单（谈判分支）、周期进度同步日程。待优化144
CEO-10会议召集、会议室预约与纪要归档任何内部或对外会议需要确定参会人、时间地点、会议室/视频会议，并在会后产出、分发和归档纪要时启动。主责——会议组织者（谁发起谁负责；产研侧当前常见：杨萌·推断待确认）；协同——行政（会议室规则与冲突协调，当前：待指定）、飞书管理员（机器人权限，当前：丁震宇·推断待确认）、转述人（当前：王皓南·推断待确认）、全体参会人；兜底——综合部负责人① 确认会议五要素 → ② 预约会议室 → ③ 建日程并发通知与材料 → ④ 参会人接受并预读 → ⑤ 开会并开启纪要 → ⑥ 纪要校对、待办转任务 → ⑦ 归档带议程、材料、会议室的飞书日程；会议纪要（含待办/责任人/DDL）；知识库归档链接。待优化60
CEO-11周例会与项目组例会公司经营例会、部门例会、项目组周例会/月度会/专题会等按固定周期召开、需要各方会前填报并跟进重点待办的会议。主责——例会组织者（公司经营例会：总经办，当前：赵雪冰·推断待确认；产研/项目推进周会：当前：杨萌·推断待确认；平台部/教育组例会：当前：陈梦琪·推断待确认；市场销售例会：销售负责人，当前：李鹏为·推断待确认）；协同——各部门负责人/部门代表、纪要与督办（当前：韩诗琪、闫登辉·推断待确认）、汇报分层制定（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 投票后固定周期并建重复日程 → ② 会前 1 个工作日建本期文档并提醒 → ③ 各部门按模板填报 → ④ 会前催填 → ⑤ 会上先过上期待办再分层汇报 → ⑥ 纪要与本期重点待办发布 → ⑦ 待办转任务跟踪本期例会文档（各部门汇报＋上期待办进展）、会议纪要、本期重点待办清单（责任人＋DDL）。待优化180
CEO-12日报/周报（DailyWork）与周期汇报员工每日/每周提交工作汇报，经部门/项目组汇总后同步给管理层；含冲刺期、居家办公期的加强汇报。主责——综合部负责人（汇报制度与 DailyWork 推行，当前：赵雪冰·推断待确认）；协同——总经办（通知与指引，当前：王欣·推断待确认）、开放平台（工具技术支持，当前：郭逸非·推断待确认）、LeapCore 适配研发（当前：岳阳·推断待确认）、部门/项目组汇总人（当前：杨萌、陈梦琪、葛家和、陈震·推断待确认）、全体员工；兜底——CEO（当前：邴龙志·推断待确认）① 系统每日生成草稿 → ② 本人核对确认 → ③ 未确认提醒 → ④ 部门日报汇总 → ⑤ 周报生成与确认 → ⑥ 部门/侧周报汇总 → ⑦ 周五周报群同步 → ⑧ 周统计与例会材料已确认的个人日报/周报、部门日报/周报、周报群同步记录、每周提交率统计与未提交名单。待优化225
CEO-13阶段总结与工作计划收集长假前、项目阶段结束或周期末，管理者要求个人与团队负责人提交阶段总结和下一阶段工作计划时启动。主责——发起管理者/产研负责人（当前：杨萌·推断待确认）；协同——团队负责人（当前：王皓南、张东郅·推断待确认）、各模块负责人、全员；兜底——上一级部门负责人① 定周期、范围、截止日 → ② 发通知与模板 → ③ 个人填写 → ④ 团队负责人汇总团队总结 → ⑤ 到期提醒 → ⑥ 审阅与退回 → ⑦ 1v1 交流 → ⑧ 汇总归档、行动项转任务个人阶段总结与计划、团队总结、汇总结论、1v1 记录、下一阶段行动项。待新建36
CEO-14向上汇报规范与关键节点上报项目遇到卡点、延期、重构、方向/战略调整或到达关键节点，或 CEO 抽查进度、索要发布会/融资/调研材料时，负责人按统一口径向上汇报。主责——项目/部门负责人（汇报人，当前：杨萌、王皓南·推断待确认）；协同——CTO（预审与指导，当前：丁震宇·推断待确认）、CEO（听取与决策，当前：邴龙志·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 判定触发 → ② 按四段式写一页纸 → ③ 预审 → ④ 先对齐结论 → ⑤ 需要时补完整文档 → ⑥ 记录决策 → ⑦ 同步口径 → ⑧ 回报结果一页纸汇报（是什么/为什么/怎么做/什么结果）、决策记录、相关团队统一口径、CEO 可查的项目清单。待新建108
CEO-15任务指派、催办与闭环跟踪在群内、会上或口头提出需要他人执行的任务/需求后，从明确负责人和时限，到登记、跟进、结果回报关闭的全过程。主责——任务发起人（对结果负责到成功或失败）；协同——被指派执行人、任务台账归口（项目管理/产品协调，当前：杨萌·推断待确认；综合事项：总经办，当前：赵雪冰·推断待确认）、上一级负责人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提出任务写清四要素 → ② 执行人限时认领 → ③ 登记任务台账 → ④ 按优先级执行并更新 → ⑤ 定期汇总未完成项 → ⑥ 超期催办与升级 → ⑦ 回报结果（成功/失败）→ ⑧ 发起人确认关闭每个任务有唯一负责人、DDL、优先级、状态，并以“成功/失败＋说明”关闭；每周未完成清单。待新建240
CEO-16重大项目/活动复盘大会、展会等重大活动结束，或客户项目交付出现问题后，需要复盘原因、沉淀经验并形成行动项时启动。主责——复盘负责人（项目/活动负责人，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户侧对接人（当前：吴琪·推断待确认）、市场同步人（当前：李铭熙·推断待确认）、各点名成员；兜底——CTO（当前：丁震宇·推断待确认）① 触发并指定复盘负责人 → ② 用模板建文档、分板块 → ③ AI 拉取时间线与客户问题初稿 → ④ 分块填写 → ⑤ 复盘会对齐事实与根因 → ⑥ 定稿行动项 → ⑦ 发送去向、行动项转任务 → ⑧ 跟踪关闭复盘文档（目标/结果/差距/原因/行动项）、客户问题清单、行动项任务、发给市场/产品的结论摘要。待新建90
CEO-17政府部门对接、汇报演示与政策风险应对政府部门、政府平台运营方或合作方领导临时通知开会、要看项目进度、下达合规/整改要求，或外部政策态度出现变化需要启动 PlanB 时启动主责——政府事务对接统筹（当前：陈梦琪·推断待确认）；协同——CEO 对外联络（当前：邴龙志·推断待确认）、CTO 方案与优先级（当前：丁震宇·推断待确认）、演示研发（当前：葛家和、裴建武·推断待确认）、商务汇报与运营（当前：杨朋伟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 登记通知 → ② 确认议题 → ③ 指派参会人 → ④ 材料与演示准备 → ⑤ 参会汇报与纪要 → ⑥ 要求拆解登记 → ⑦ 跟踪闭环 → ⑧ 政策风险触发 PlanB政府事务登记记录、汇报材料与演示环境、会议纪要、政府要求整改清单（已闭环）、政策风险预案待新建180
CEO-18高管日程与外部约见管理外部人员或内部同事约高管见面、饭局、会议，或已排日程需要改期时启动主责——高管助理/总助（当前：待指定）；协同——被约高管（当前：邴龙志·推断待确认）、代为协调的高管（当前：丁震宇·推断待确认）、行政（会议室）（当前：待指定）；兜底——综合部负责人① 约见请求登记 → ② 查冲突给时段 → ③ 高管确认 → ④ 写入日历订会议室 → ⑤ 提醒 → ⑥ 变更通知 → ⑦ 会后记录高管共享日历中已确认的约见日程、约见登记记录、改期通知记录待新建72
CEO-19外部合作方/顾问评估与分成决策外部合作方、顾问、代写/渠道伙伴的产出不达标，或合作满一个周期，需要评估是否继续合作及调整分成/付费方式时启动主责——合作方对接业务负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、用户对接（当前：杨萌·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；决策——COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 事实收集 → ② 对照合同条款 → ③ 评估打分 → ④ 真实用户反馈 → ⑤ 方案与测算 → ⑥ 决策会 → ⑦ 协议与结算落地 → ⑧ 台账归档合作方评估表、决策纪要、补充协议或终止通知、更新后的合作方台账待新建96
CEO-20内部管理系统与协作工具建设（内控/业财平台）建设或改造内控与经营管理平台、业财系统、PRM/CRM/工单/合同等内部系统，或决定统一内部协作工具并强制推行时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——总经办（当前：田杰·推断待确认）、CTO 系统架构（当前：丁震宇·推断待确认）、定制系统开发（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、工单系统研发（当前：王皓南·推断待确认）、各板块执行协同人（当前：黄梦婷、韩诗琪、杨明学·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项建议书 → ② 系统盘点与选型 → ③ CEO 决策 → ④ 组推进组 → ⑤ 需求与边界 → ⑥ 开发配置与权限 → ⑦ 每周同步 → ⑧ 跑测验收 → ⑨ 上线强制推行 → ⑩ 系统台账交接项目建议书（含 MVP 范围）、选型打分表、推进表、系统台账（负责人/边界/权限）、上线公告与验收记录待优化300
CEO-21全员 AI 案例征集与积分激励宣贯总经办推出全员制度（如积分激励制度）需要宣贯，或面向全员发起案例征集、命名征集等活动时启动主责——总经办（当前：田杰·推断待确认）；协同——CEO 发起与评审（当前：邴龙志·推断待确认）、产品总监（案例收集与需求池）（当前：杨萌·推断待确认）、综合部负责人答疑（当前：赵雪冰·推断待确认）、问题收集（当前：宋祺睿·推断待确认）、人事（积分发放）（当前：待指定）；兜底——综合部负责人① 方案与口径核对 → ② 发通知 → ③ 宣贯会 → ④ 答疑与 FAQ → ⑤ 征集收表 → ⑥ 统计催交 → ⑦ 评审 → ⑧ 积分发放与公示宣贯通知与一页纸速览、FAQ、征集结果表、评审结论、积分发放与公示记录待优化40
CEO-22股东会筹备与决议（含主体设立/注销材料）召开母公司年度股东会、子公司股东会，或因设立全资子公司、注销旧主体需要股东会决议与配套材料时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——COO 汇报材料与股权结构（当前：常元和·推断待确认）、CEO 议案与决议（当前：邴龙志·推断待确认）、CTO 子公司会议发起与技术保障（当前：丁震宇·推断待确认）、行政接待与物料（当前：侯明月·推断待确认）、财务清税证明（当前：黄梦婷·推断待确认）、摄影（当前：宫经喜·推断待确认）、技术保障（当前：游家豪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 定会期与议案 → ② 发会议通知 → ③ 会务清单拆分到人 → ④ 议案/决议/汇报材料准备 → ⑤ 会前 3 天复核 → ⑥ 打印用印 → ⑦ 召开与表决 → ⑧ 签署归档与工商衔接会议通知、议案与股东会决议（已签署）、签到表与表决表、汇报材料、会议纪要；设立/注销时附股权结构与清税证明待优化200
CEO-23股权/期权激励方案起草与审议发放需要制定或修订期权/限制性股权激励方案并提交董事会、股东会审议，或发放一批期权时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——董事会成员（当前：邴龙志、丁震宇、常元和·推断待确认）、法务（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 起草方案与授予协议 → ② 法务审阅 → ③ 待决事项清单 → ④ 董事会集中讲解与决议 → ⑤ 定稿 → ⑥ 股东会审议 → ⑦ 授予协议签署发放 → ⑧ 发放汇报与遗留问题处理股东会审议通过的激励方案、董事会决议记录、签署的授予协议、发放名册与汇报纪要待新建100
CEO-24分子公司/关联主体边界与权限管理关联公司（EG、鼎慧、深圳、苏州、参股合资公司、曜途等）涉及积分、期权、福利、飞书账号、办公用品、人员兼岗、招聘考勤、项目资料同步等事项，需要判断是否共享、如何切割及对外口径时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——CTO 口径决策（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）、人事（当前：黄莹·推断待确认）、EG 负责人（当前：徐莉·推断待确认）、子公司 CEO（当前：赵捷·推断待确认）、曜途技术负责人（当前：白立新·推断待确认）、财务/法务/行政（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 识别涉及关联主体的事项 → ② 查边界清单 → ③ 未覆盖事项出建议 → ④ 会签 → ⑤ 管理层决策 → ⑥ 书面同步子公司 → ⑦ 账号权限与费用切割 → ⑧ 子公司项目定期同步 → ⑨ 季度复核《关联主体边界清单》（可共享/不共享）、对外口径说明、飞书组织架构与权限调整记录、子公司服务边界约定、子公司项目周报与资料归档待新建225
CEO-25重大突发事件与危机应对（舆情、监管、重大事故）发生可能严重影响公司声誉、经营或合规的事件，如重大客户事故、大规模数据泄露、负面舆情、监管约谈/检查、人员安全事件、核心供应商断供主责——总经办负责人（当前：田杰·部门报送人）；协同——研发负责人、品牌负责人（当前：何思雨·部门报送人）、法务（当前：待指定）、销售负责人（当前：待指定）、人事（当前：待指定）；兜底——总经办（当前：田杰·部门报送人）① 上报总经办 → ② 分级 → ③ 成立应急小组 → ④ 统一对内对外口径 → ⑤ 处置与定时同步 → ⑥ 宣告结束 → ⑦ 复盘整改事件分级记录、应急小组名单、对外声明/口径、进展通报、复盘报告待新建125
CEO-26年度经营预算审定与月度经营分析年度开始前审定各部门、各主体经营预算（收入、人力、采购、云与模型成本、市场费用）；每月召开经营分析会，对比预算与实际并决策调整主责——总经办负责人（当前：田杰·部门报送人）；协同——财务负责人（当前：黄梦婷·部门报送人）、各部门负责人、各主体负责人；兜底——总经办（当前：田杰·部门报送人）① 下发预算模板 → ② 各部门编报 → ③ 财务汇总测算 → ④ 管理层审定 → ⑤ 发布预算 → ⑥ 每月出经营数据 → ⑦ 经营分析会 → ⑧ 决议跟踪年度预算表、月度经营数据包、经营分析会纪要与决议清单待新建180
CEO-27融资推进与投资者关系管理公司启动新一轮融资，或需向现有投资人定期报送经营信息、响应投资人问询与尽调主责——融资/投资者关系负责人（当前：待指定）；协同——财务负责人（当前：黄梦婷·部门报送人）、法务（当前：待指定）、研发负责人、总经办（当前：田杰·部门报送人）；兜底——总经办（当前：田杰·部门报送人）① 融资启动决策 → ② 准备材料与数据室 → ③ 投资人接触与保密协议 → ④ 尽调响应 → ⑤ 条款谈判与决策 → ⑥ 交割 → ⑦ 投后定期报告融资计划、商业计划书、数据室、尽调问答记录、交割文件、投后定期报告待新建100

ADM 行政 报送人：胡则瑾

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ADM-01办公场地选址、租赁、装修与搬迁现有场地工位饱和、租约到期/提前退租，或需新增办公点/展厅时，从选址评估一直走到装修验收、整体搬迁和原场地退租主责——行政负责人（当前：胡则瑾·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求立项 → ② 踩点与场地对比表 → ③ 决策会拍板 → ④ 商务谈判（租金/免租期/发票）→ ⑤ 合同审核与用印 → ⑥ 施工准备（物业三方签字、押金）→ ⑦ 施工跟踪与验收 → ⑧ 搬迁与退租已签署的租赁合同（含发票条款）、装修验收单与空气检测报告、搬迁完成通知、退租交接单及押金退还记录待新建250
ADM-02工位调整与座位安排组织调整、团队扩招、分区搬迁或新增场地，需要重新排座位、调整桌椅并同步全员时主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、CTO（当前：丁震宇·推断待确认）、行政专员（当前：侯明月·推断待确认）、各部门负责人（当前：杨萌、李凯、陈梦琪等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交工位变更申请 → ② 核对工位台账 → ③ 定分区方案 → ④ 发布座位表 → ⑤ 桌椅补齐 → ⑥ 统一搬迁 → ⑦ 更新台账已发布的最新座位表（多维表格）、完成搬迁的工位、更新后的工位台账待优化72
ADM-03新员工入职行政准备（工位、电脑、领用登记）人事确认新员工/实习生到岗日期后，到岗前备好工位、电脑/显示器/开发机及办公用品，到岗当天完成发放与领用登记主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、IT 运维负责人（当前：杨明学·推断待确认）、运维工程师（当前：游家豪·推断待确认）、行政专员（当前：侯明月·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职信息推送 → ② 工位确认 → ③ 配置判定 → ④ 库存核对/采购 → ⑤ 预装系统 → ⑥ 工牌门禁账号 → ⑦ 到岗发放与登记 → ⑧ 清单关闭到岗当天可用的工位和预装好的设备、已填写的领用登记、全部勾选完成的入职准备清单待优化144
ADM-04工牌制作与门禁/钥匙/临时密码管理新人领工牌、批量换版工牌、门禁指纹/NFC 录入、门卡遗失，以及装修/保洁/空调师傅或访客需要临时进门时主责——行政专员（当前：侯明月·推断待确认）；协同——行政助理（当前：丁蕊·推断待确认）、IT 运维/门锁管理员（当前：杨明学·推断待确认）、门锁 App 持有人（当前：宋祺睿·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——行政负责人（当前：胡则瑾·推断待确认）① 入职触发工牌采集 → ② 按月批次制作 → ③ 发放签收 → ④ 门禁录入 → ⑤ 临时授权（限时密码+登记）→ ⑥ 遗失补办/离职注销 → ⑦ 月度权限盘点已发放并签收的工牌、门禁权限台账（含临时授权记录和到期时间）待新建72
ADM-05会议室预约与公共空间使用规范开会、演示、培训、分享会、1v1 需要会议室，或出现会议室冲突、公共空间使用纠纷（不关灯关门、午休噪音）时主责——行政专员（当前：侯明月·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、人事负责人（当前：黄莹·推断待确认）、905 区域行政（当前：董蓝汐·推断待确认）、各会议组织者；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 飞书预约（按人数选房）→ ② 冲突处理 → ③ 签到/超时释放 → ④ 使用 → ⑤ 会后复原 → ⑥ 每日巡检 → ⑦ 月度复盘有记录的会议室预约、按规则释放的空闲时段、公示的公共空间使用规范与巡检记录待优化100
ADM-06外部来访接待与参观/拍摄报备客户、供应商、领导、院校、政府、媒体来访，外部朋友/合作方参观，或在办公点拍摄时，从报备到现场接待、费用与归档主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、CRM/接待表管理员（当前：闫登辉·推断待确认）、CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交接待申请 → ② 行政确认并预留资源 → ③ 分级审批（拍摄/政府/媒体）→ ④ 前一天同步物业与客户 → ⑤ 现场接待与场控 → ⑥ 宴请与费用 → ⑦ 当日归档接待登记记录（含照片、纪要、费用）、已确认的会议室与物业配合事项、拍摄审核记录待优化240
ADM-07面试会议室预约与候选人到访接待线下或线上面试排期确定后，预约合适会议室与设备，并在候选人到访时引导、接待直至送离主责——HR 招聘专员（当前：张欣怡·推断待确认）；协同——HR 招聘助理（当前：匡蓉·推断待确认）、面试官（当前：丁震宇、陈晖、王皓南、张东郅等·推断待确认）、IT 运维（当前：杨明学·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 排期确定 → ② 预约合适会议室 → ③ 前一天复核 → ④ 发到访指引 → ⑤ 到访接待 → ⑥ 面试进行 → ⑦ 送离并释放会议室已绑定会议室的面试日程、候选人到访登记、面试结束后释放的会议室待优化90
ADM-08办公设施故障报修与维修验收空调、门锁、门窗、灯具、插座、电闸、卫生间、漏水、网络/AP、机房过热、家具、咖啡机等设施损坏或异常时，从报修到师傅上门、验收、费用与复盘主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外部物业/厂家；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 表单报修 → ② 自动分派 → ③ 初判与预计时间 → ④ 比价/审批 → ⑤ 预约上门 → ⑥ 维修与现场验收 → ⑦ 关单记费用 → ⑧ 重复故障复盘关闭的报修工单（含照片、费用、供应商、质保期）、应急联系人表、重复/重大故障复盘记录待新建225
ADM-09停电/极端天气等突发事件通知与居家办公安排办公楼计划停电/修闸、突发断电断网、网络线路割接，或台风暴雨等极端天气影响通勤与办公时，统一发布通知并决定到岗、居家或换点办公。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——IT运维（当前：杨明学·推断待确认）、产研通知对接人（当前：杨萌·推断待确认）、管理层决策人（当前：丁震宇、常元和、邴龙志·推断待确认）；兜底——综合部负责人① 获知事件并分级 → ② 行政与 IT 拉齐影响范围 → ③ 管理层定到岗/居家方案 → ④ 发布唯一口径加急通知 → ⑤ 停电前按清单关服务 → ⑥ 员工报备与换点办公 → ⑦ 恢复确认与复盘一条统一口径、已加急并确认已读的通知；服务器按清单关停与恢复的记录；居家/换点办公报备记录；事件复盘记录待新建96
ADM-10下班及节假日离岗安全检查（断电、锁门、机房）每天下班最后离开办公区时，以及周末、长假前，完成关灯、空调、电视、电脑与电源，锁好门窗，并确认机房和远程机器的断电或保电安排。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月、丁蕊·推断待确认）、IT运维（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·推断待确认）、各区域最后离开者；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建分区域设备台账与关闭图文 → ② 门口张贴离岗清单 → ③ 最后离开者按清单检查 → ④ 次日早抽查与异常登记 → ⑤ 节前征询保电需求 → ⑥ IT 确认机房/远程机器保电范围 → ⑦ 节前通知与当晚巡检 → ⑧ 节后恢复确认张贴的离岗检查清单与空调等设备关闭图文；每日抽查与节前巡检记录；节假日断电范围与保电设备清单；纳入入职培训的办公区安全规范待新建160
ADM-11办公区保洁、值日、大扫除与虫害消杀办公区日常卫生维护、外包保洁、节前/夏季大扫除、装修后清理，以及出现蟑螂、蚊虫、异味、积水等卫生事件时，安排值日、保洁或消杀并验收。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——卫生委员（当前：侯明月、赵雪冰·推断待确认）、各组组长/卫生小组长、外包保洁、消杀服务商；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 划分区域并发布月度值日表 → ② 值日人每日整理 → ③ 外包保洁每周清洁拍照 → ④ 行政验收 → ⑤ 杂物清运 → ⑥ 定期大扫除 → ⑦ 定期消杀 → ⑧ 卫生事件即时处置月度值日表与完成记录；保洁验收记录（含照片）；大扫除与消杀日历及执行记录；卫生事件处置记录待优化48
ADM-12行政制度与办公规范制定发布需要建立或修订采购、接待、福利、报销等公司级行政制度，或发布办公室使用规范（卫生间、门、空调、会议室规则）时，统一由行政起草、相关部门会签、审批后发布并入库。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、行政助理（当前：丁蕊·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总助/总经办（当前：赵雪冰·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 提出制度/规范需求 → ② 行政登记立项 → ③ 起草初稿 → ④ 财务/人事/相关部门会签 → ⑤ 总助审核、CEO 审批 → ⑥ 发布公告与张贴 → ⑦ 入制度库并培训 → ⑧ 定期复审经审批的制度文件或规范（带编号与版本）、发布公告、现场张贴物、制度库条目待优化96
ADM-13行政事务归口、交接与行政日报快递、报修、打印、保洁、物品领用、会议室等行政杂务没有明确承接人，行政岗位变动、空缺或由实习/兼职助理承担，以及行政人员每日工作汇报时。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员/助理（当前：侯明月、丁蕊·推断待确认）、财务（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CTO（行政缺位时的临时协调，当前：丁震宇·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 编制行政事务归口清单 → ② 设统一受理入口 → ③ 公示岗位分工与在岗时间 → ④ 每日提交日报 → ⑤ 跨部门事项同步总经办 → ⑥ 岗位变动按清单交接 → ⑦ 空缺期指定代理人 → ⑧ 每周复盘未结事项行政事务归口清单（每项有主责、备岗、入口、时限）；行政服务受理台账；每日行政日报；岗位交接清单与签收记录待新建135
ADM-14办公物资/家具申购与行政服务需求受理员工需要桌椅、柜子、打印机、取暖设备、屏风等物资，消耗品（饮用水、纸巾、垃圾袋、洗手液）用完，需要占用场地放置物品，或需要行政配合摆放、清理、布置会场时，统一受理、选型、采购或授权垫付、交付验收并集中收票。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT运维（网络/设备/门锁，当前：杨明学·推断待确认）、总助（场地占用审批，当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、需求方；审批——预算审批人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求方提交申请单 → ② 行政受理分类 → ③ 选型比价并请需求方确认 → ④ 按金额阈值审批 → ⑤ 下单或授权垫付 → ⑥ 到货通知、签收、组装 → ⑦ 需求方验收 → ⑧ 订单与发票入表、报销或月度集中结算已验收交付的物资或服务；带订单号、下单人、供应商的需求台账；齐全的发票与报销/结算记录；公示的消耗品存放位置与库存表待优化180
ADM-15快递代收、公共物品借用与失物招领快递或供应商送货到公司、需要借用公共物品（U 盘、吸尘器、工具箱、拖车、清洗机、测试机等）、发现遗落物品，或有陌生人员上门推销、找人时，按规则登记、通知、借还、认领与引导。主责——行政专员（当前：侯明月·推断待确认）；协同——IT运维（IT 类公共设备，当前：杨明学·推断待确认）、运维/交付工程师（打印机与设备登记，当前：游家豪·推断待确认）、当日前台值守人；兜底——综合部负责人① 建公共物品台账与位置标签 → ② 发布办公指南 → ③ 快递到件登记并通知 → ④ 借用登记与按期归还 → ⑤ 遗落物品登记与限期认领 → ⑥ 陌生来访识别与引导 → ⑦ 月度盘点公共物品台账（含位置与保管人）；办公指南（打印机、会议室、物资位置、门禁获取方式）；快递登记与认领记录；借还记录；失物招领记录待新建72
ADM-16对外寄件与快递月结向客户或供应商寄送交付机器、签收单、合同材料，或设备寄修时，统一登记收件信息、使用公司快递月结账户发货、回填单号并同步相关人员，月底对账。主责——行政负责人（月结账户与寄件规则，当前：胡则瑾·推断待确认）；协同——IT运维/寄件执行（当前：杨明学·推断待确认）、交付统筹（收件信息确认，当前：杨萌·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（月结对账，当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 寄件人提交寄件登记 → ② 交付统筹确认收件信息 → ③ 打包与保价判断 → ④ 用公司月结账户下单 → ⑤ 回填单号并同步需求群 → ⑥ 跟踪签收 → ⑦ 月度对账寄件登记台账（含收件信息、物品、单号、签收状态）；按时签收的寄件；月结账单与台账核对记录待优化90
ADM-17零食福利月度采购与额度/报销管理每月员工零食饮料福利，从系统开放选购（或部门自行收集需求）到截单、统一采购、到货分发、发票核对与报销结算的全过程主责——行政负责人（当前：胡则瑾·推断待确认）；协同——总经办通知专员（当前：王欣·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、零食系统维护人（当前：丁震宇·推断待确认）、各部门零食汇总人（当前：杨萌、陈梦琪、杨明学、游家豪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 生成当月名单与额度 → ② 开放选购并通知 → ③ 截止前催确认 → ④ 锁单汇总 → ⑤ 统一下单 → ⑥ 到货分发 → ⑦ 收票报销 → ⑧ 月度复盘当月采购汇总单、到货分发记录、按部门/月份归档的“发票+付款凭证”报销包、更新后的需求与 BUG 看板待优化108
ADM-18节日福利与员工福利物资发放节日或公司决定向员工统一发放福利物资（节日礼盒、福利图书、定制周边等），从立项、意向收集/投票、采购或定制，到发放签收主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（周边打样与供应商对接）（当前：杨明学·推断待确认）、福利发起与定调人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定预算与截止 → ② 出方案/打样 → ③ 意向收集或投票（设默认方案）→ ④ 汇总下单 → ⑤ 到货验收 → ⑥ 发放签收 → ⑦ 报销归档福利方案（含预算上限、默认方案、截止时间）、选择/投票结果、采购订单与发票、发放签收表待优化36
ADM-19活动定制物料与对外礼品（工服、伴手礼、品牌周边赠送登记）大会、董事会等活动需要统一工服，或对外需要伴手礼、宣传册、品牌周边，以及样品借用和向合作伙伴赠送物品主责——行政负责人（当前：胡则瑾·推断待确认）；协同——市场/品牌需求方（当前：许君·推断待确认）、设计（当前：康紫馨·推断待确认）、行政专员（尺码统计、出入库登记）（当前：侯明月·推断待确认）、活动现场发放（当前：林子淇、康紫馨·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求提报 → ② 倒排排期 → ③ 询价并确认工期 → ④ 设计与文案定稿 → ⑤ 款式/尺码统计 → ⑥ 下单 → ⑦ 到货验收入库 → ⑧ 发放/赠送出库登记物料排期表、供应商工期确认单、定稿设计文件、到货验收记录、出入库（发放/赠送/借用）登记台账待新建72
ADM-20团建、聚餐与全员活动组织组织月度生日会、季度/破冰团建、周年庆、程序员节、年终聚餐、团队聚餐、培训日用餐等内部活动，从方案预算到通知报名、保险交通、订位执行和报销主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（通知与执行）（当前：侯明月·推断待确认）、行政助理（策划与保险）（当前：丁蕊·推断待确认）、人事负责人（人员名单）（当前：黄莹·推断待确认）、CEO（方案与预算拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项（目的、时间、预算）→ ② 方案与比价 → ③ CEO 审批 → ④ 通知与表单报名 → ⑤ 保险、交通、订位 → ⑥ 现场签到执行 → ⑦ 报销与复盘活动方案（含预算）、报名名单、保险名单、供应商合同/订单、签到表、发票报销单、复盘记录待优化108
ADM-21全员年会筹办公司决定举办全员年会/全员大会后，在约 2 周内完成定日期、找场地、设计流程与互动、发邀请函、订餐、物料与布置主责——行政（年会筹办牵头）（当前：侯明月·推断待确认）；协同——人事负责人（邀请与人员）（当前：黄莹·推断待确认）、创始人兼 CTO（内容、视频与 PPT）（当前：丁震宇·推断待确认）、CEO（形式、场地、流程拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定日期与预算 → ② 场地比价锁定 → ③ 流程与奖品方案 → ④ CEO 定稿 → ⑤ 邀请函发出 → ⑥ 订餐与物料 → ⑦ 布置彩排与当天签到 → ⑧ 报销复盘年会倒排表、场地合同/确认单、流程文档、奖品清单、邀请函、订餐确认、签到与人员清单、费用报销与复盘待新建60
ADM-22差旅订票与企业出行账户管理员工因公出行需要订票（含二等座售罄等例外），以及企业滴滴等出行账户的开通、余额充值与分主体对账主责——行政专员（差旅与企业出行账户）（当前：侯明月·推断待确认）；协同——财务专员（充值与报销）（当前：刘梦可·推断待确认）、CEO（差旅例外审批）（当前：邴龙志·推断待确认）、销售负责人（差旅高频部门代表）（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 出差审批 → ② 按标准订票 → ③ 例外在审批中说明并附证明 → ④ 报销按标准核对；企业出行账户：① 开通申请 → ② 按主体开通 → ③ 余额预警 → ④ 充值 → ⑤ 月度对账出差审批单、符合标准的票据与报销单、企业出行账户成员清单、充值记录、按主体的月度对账单待优化27
ADM-23公司证照与档案（印章/档案柜）保管调用业务需要营业执照、法人证件、资质等材料（小程序审核、合同、渠道资料、申报），或人事档案、公章、财务资料需要安全存放与借阅主责——行政专员（证照与印章保管）（当前：侯明月·推断待确认）；协同——总助助理（档案体系建设）（当前：董蓝汐·推断待确认）、人事负责人（人事档案）（当前：黄莹·推断待确认）、财务负责人（财务凭证）（当前：黄梦婷·推断待确认）、法务负责人（合同档案）（当前：李瑶·推断待确认）、CEO（档案室规划拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建电子证照库 → ② 设权限与水印规则 → ③ 申请调用 → ④ 发放带水印版本/原件借出登记 → ⑤ 证照变更同步 → ⑥ 纸质档案编号入柜 → ⑦ 借阅登记 → ⑧ 季度盘点按主体分类的电子证照库（含版本与有效期）、证照调用记录、原件与档案借阅登记表、纸质档案目录、季度盘点报告待新建96
ADM-24IT设备与研发硬件采购申请新人入职、设备不足、研发换配置、测试机不足、需要工作站/CI 机/算力机/NAS/服务器、外设耗材、客户交付硬件备货、设备返修时的采购申请到配发入账主责——IT 运维/采购专员（当前：杨明学·推断待确认）；协同——创始人兼 CTO（IT 预算与配置审批）（当前：丁震宇·推断待确认）、CEO（付款审批）（当前：邴龙志·推断待确认）、行政专员（京东慧采下单）（当前：侯明月·推断待确认）、财务负责人（付款）（当前：黄梦婷·推断待确认）、运维/交付工程师（到货验收与领用核对）（当前：游家豪·推断待确认）；兜底——创始人兼 CTO① 提交“采购申请”审批 → ② 查库存可否调拨 → ③ 按分级标准选型询价 → ④ CTO 审配置预算、CEO 审付款 → ⑤ 下单 → ⑥ 财务付款 → ⑦ 到货验收 → ⑧ 入台账并领用签收信息完整的采购审批单、询价比价记录、订单与发票、验收单、IT 资产台账记录、领用签收记录待优化192
ADM-25交付用硬件备货采购与供应商比价交付库存（元和/源核/龙智/震宇等机型、周年版）低于安全库存，或新交付、客户采购意向需要服务器/工作站/机柜时，完成库存评估、成本核算、供应商比价压价和下单补货。主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——交付统筹（当前：杨萌·推断待确认）、销售/商务（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 库存预警/需求提出 → ② 库存与需求量评估 → ③ 规格确认与成本核算 → ④ 合格供应商比价压价 → ⑤ 采购审批 → ⑥ 下单与到货跟踪 → ⑦ 验收入库并更新库存已审批的补货采购单、供应商比价记录、按期到货并入库的交付硬件、更新后的库存与成本表待新建192
ADM-26调研/验证用设备临时采购与处置研发/产品为竞品调研或技术验证需要实机（如小米 NAS、懒猫微服、某存储设备厂商 NAS），完成临时采购或借用、领用登记，评估结束后按期保留、退货、转赠或出售。主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——需求方研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、设备保管运维（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 提出需求（用途/评估期/预算）→ ② 先查替代方案 → ③ 选采购方式并标注退货期 → ④ 小额快速审批 → ⑤ 下单、入库登记、领用 → ⑥ 评估期满前提醒 → ⑦ 处置（保留/退货/转赠/出售）并更新台账调研设备台账记录（含退货截止日、保管人、处置结果）、评估结论、退款或资产入账凭证待新建32
ADM-27IT设备到货验收、入库登记与调配变更采购的服务器、CI 机、内存、主板、迷你主机、电脑及外设到货，或设备在员工之间换人使用、退回时，完成验收、资产编号入库、分配和资产表变更。主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、需求方/验收人（当前：宋祺睿·推断待确认）、行政（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 到货通知 → ② 打印/生成验收单 → ③ 需求方验收签字 → ④ 分库入库并编号 → ⑤ 领用/分配登记 → ⑥ 调配或退回时提变更 → ⑦ 更新资产表并归档签字验收单、带资产编号的入库记录、领用/调配记录、账实一致的资产多维表格待优化144
ADM-28内部测试设备与资源借用登记研发、测试、交付需要借用公司闲置测试机、Mac mini、Windows 机、平板、录音卡、iPhone/iPad 真机、移动硬盘/U 盘/光盘等交付介质时，查台账、登记借用、按期归还。主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 查测试设备台账 → ② 提交借用登记 → ③ 确认/审批 → ④ 领取并记录配件 → ⑤ 到期提醒 → ⑥ 归还验收、清数据 → ⑦ 台账回写；无库存时转采购实时可查的测试设备与交付介质台账、每次借用/归还记录、按需补充的安全库存待新建96
ADM-29样机/设备外借（销售演示、展会、客户现场应急）销售/市场需要借 LeapCore 样机或其他设备用于客户演示、渠道/经销商试用、展会，或政府等客户现场应急需要终端时，完成借用审批、出库登记（含配件清单）和归还入账。主责——IT资产/样机管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、销售（当前：杨朋伟·推断待确认）、产品总监（当前：杨萌·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认），特殊情形加签 COO（当前：常元和·推断待确认）；兜底——综合部负责人① 提前 1～3 天确认样机存量 → ② 提交样机借用审批 → ③ 按常规/特殊分级审批 → ④ 出库登记配件并拍照 → ⑤ 领取或邮寄 → ⑥ 到期提醒 → ⑦ 归还核对配件并入账已审批的借用单、含配件清单和照片的出库/归还记录、样机台账状态更新待优化180
ADM-30信创测试机申请与厂商借机/归还信创适配或测试缺少海光/飞腾/鲲鹏/龙芯/兆芯等芯片或对应操作系统的实体机、虚拟机、构建服务器时，提需求审批，按内部资源、厂商借机、云租赁、采购四条路径获取，验收入库交测试，到期归还或转长期。主责——IT资源/资产管理员（当前：杨明学·推断待确认）；协同——信创适配负责人（当前：李子遥·推断待确认）、运维（当前：游家豪·推断待确认）、渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、测试（当前：潘浩伟·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 提交配置需求 → ② 审批并定路径（内部/借用/云/采购）→ ③ 指定到位日期与负责人 → ④ 获取资源（组装/开账号/向厂商借/采购）→ ⑤ 验收入库、交测试 → ⑥ 占用与转借登记 → ⑦ 到期归还或转长期可用的信创测试/构建环境、信创设备借用台账（来源、位置、保管人、归还日）、按期归还记录待优化300
ADM-31IT设备故障报修显示器、键盘、笔记本、mini PC、移动硬盘等 IT 设备出现故障或人为损坏时，统一报修登记，完成排障、维修或更换，必要时判定赔偿，并把退役/闲置设备回收再分配或处置；电脑、服务器、硬盘、U 盘、手机、测试机、客户退回的一体机等设备报废、出售、转赠、退租或返厂维修前，完成数据清除与资产注销。主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CTO（当前：丁震宇·推断待确认，审批）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交“设备维修”审批 → ② 远程/现场初步排查 → ③ 定级（换配件/送修/换新）→ ④ 维修或更换 → ⑤ 判定是否人为损坏 → ⑥ 验收交还并更新台账 → ⑦ 退役设备鉴定回收 → ⑧ 数据清除或物理销毁 → ⑨ 处置审批与执行 → ⑩ 资产注销与财务核销报修工单闭环记录、修复或替换后的设备、更新后的资产台账（含维修记录）、需要时的报损与赔偿判定记录；处置设备的数据清除记录（含序列号）、处置凭证与资产注销记录待优化54
ADM-32离职/换机设备回收员工（含实习生、外部合作者）离职、合作结束或更换设备时，按清单回收电脑、键鼠、充电线等公司资产，核对资产表并重新入库，同时联动账号收口。主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、运维（当前：游家豪·推断待确认）；认定——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 离职审批流转到运维节点/换机申请 → ② 按资产表生成回收清单 → ③ 约定回收时间 → ④ 逐项核对实物与编号 → ⑤ 数据清理与账号收口联动 → ⑥ 审批签字 → ⑦ 资产表回写并重新入库逐项核对的回收清单、运维节点已审批的离职单、更新后的资产表（状态“在库/闲置”）待优化72
ADM-33资产盘点、闲置回收与审计配合到了定期盘点节点（季度/年后），或审计、董事会、尽调需要账实资料，或发现外借、送测、闲置设备长期未归还时，启动全量或专项资产盘点与回收主责——IT 资产管理员（当前：杨明学·推断待确认）；协同——盘点执行人/IT 运维交付（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外借发起部门对接人（当前：李鹏为、闫登辉·推断待确认）、运维/云资源管理员（当前：宋祺睿·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 触发并发盘点通知 → ② 导出台账底表 → ③ 现场扫码盘点并补标签 → ④ 使用人确认 → ⑤ 外借与闲置追回 → ⑥ 差异处理 → ⑦ 与财务账核对 → ⑧ 出盘点报告并归档更新后的资产台账（账实相符）、盘点报告与差异清单、外借/闲置回收记录、提交审计或董事会的资产资料待新建240
ADM-34云服务与软件订阅等非实体资产申领与释放内部团队或子公司需要云服务、测试环境、域名、开放平台企业 ID、AI 工具订阅/兑换码/Token 等非实体资产，或这类资源不再使用需要释放回收时主责——云资源与权限管理员（当前：宋祺睿·推断待确认）；协同——审批人/创始人兼 CTO（当前：丁震宇·推断待确认）、资源原负责人（当前：按台账登记，待指定）、交付核对人（当前：杨云峰、游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申请人；兜底——创始人兼 CTO① 提交「非实体资产申领」审批 → ② 分类与主体判定 → ③ 审批 → ④ 采购付款（如需） → ⑤ 开通/发放 → ⑥ 登记资源台账 → ⑦ 释放申请与在用确认 → ⑧ 执行释放并更新台账已审批的申领单、开通完成并登记到资源台账的资源（含负责人、到期日、费用归属）、经确认的释放记录待优化96
ADM-35消防安全检查与应急疏散演练办公区、机房、库房的日常消防检查，每年至少一次的应急疏散演练，以及发生火情、冒烟、电池鼓包等险情时适用主责——行政专员（当前：待指定）；协同——IT/运维（当前：待指定）、人事（当前：待指定）、楼宇物业（外部）；兜底——行政负责人（当前：胡则瑾·部门报送人）① 消防设施台账 → ② 月度检查 → ③ 隐患整改 → ④ 年度疏散演练 → ⑤ 险情处置 → ⑥ 复盘与台账更新消防检查记录、隐患整改单、演练记录、险情处置报告待新建80
ADM-36场地租金、物业及水电网费用缴纳与租约到期提醒每月/每季度缴纳房租、物业费、水电费、宽带专线费，以及租赁、物业、宽带合同到期前的续约决策时适用主责——行政专员（当前：待指定）；协同——财务（当前：待指定）、IT/运维（当前：待指定）；兜底——行政负责人（当前：胡则瑾·部门报送人）① 建立固定费用台账 → ② 到期前提醒 → ③ 核对账单 → ④ 付款申请 → ⑤ 付款与收票 → ⑥ 合同到期前评估续约 → ⑦ 台账更新按期缴纳的付款记录与发票、续约或退租决定待新建72

FIN 财务 报送人：黄梦婷

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
FIN-01对公采购申请与付款审批业务需以公司名义向外部供应商采购 IT/网络/算力/软件服务/硬件/家宽专线等，需要签合同或对公付款时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购（当前：杨明学·推断待确认）、总经办采购发起（当前：田杰·推断待确认）、行政合同与用印（当前：侯明月·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 询价比价并确认可开票 → ② 提交“采购申请” → ③ 合同审核与用印 → ④ 技术审批与终审 → ⑤ 财务提“付款申请”制单 → ⑥ 复核打款 → ⑦ 回执给采购人提货/开工 → ⑧ 验收、发票回收入账审批留痕完整的采购申请、已盖章合同、付款回单、合规发票、验收/资产登记记录与入账凭证；交付类采购同时拿到回执完成提货。待优化320
FIN-02AI 工具订阅与第三方服务新购开通团队需要新购 AI 订阅席位、模型账号、第三方 API Key 或按量付费服务（含产品集成的第三方服务、内容团队试用的生成工具）时启动。主责——IT 资源与采购（当前：杨明学·推断待确认）；协同——CTO 用途与预算审批（当前：丁震宇·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、NewAPI 网关管理员（当前：望政韬·推断待确认）、行政报销对接（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CEO 超阈值审批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提需求（工具/用途/席位/预算）→ ② 官方渠道与付款主体核验 → ③ “AI 工具/服务开通申请”审批 → ④ 以公司账号开通并公司付款 → ⑤ 密钥接入 NewAPI/密钥库并限额 → ⑥ 登记服务台账 → ⑦ 到期/余额/封号提醒 → ⑧ 月度用量与成本复盘以公司主体开通、可用且登记在台账的订阅/账号/Key，明确负责岗位、额度上限、到期日与成本归属。待新建192
FIN-03上游模型/云服务/三方 API 账户充值与余额预警公司已有的云厂商、模型厂商、中转渠道、三方 API、SaaS 席位账户余额低于预警线、欠费或账期到期时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——云资源与账户监控（当前：宋祺睿·推断待确认）、IT 运维与渠道（当前：杨明学·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 余额自动监控告警 → ② 确认充值需求（金额/主体/账户）→ ③ 财务统一提“付款申请” → ④ 技术审批 + 终审 → ⑤ 核验账户后汇款 → ⑥ 到账确认并通知 → ⑦ 消耗后开票回收 → ⑧ 月度对账复盘账户恢复到目标余额且服务不中断；付款申请、回单、到账记录、发票在账户台账中一一对应。待优化225
FIN-04境外服务外币付款与无票支出处理需要向境外 AI 服务、网关、订阅、云服务支付外币，或支出无法取得国内合规发票时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CTO 需求审批（当前：丁震宇·推断待确认）、IT 运维流程指引（当前：杨明学·推断待确认）、CEO 例外审批与公司卡（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 先找可开票/对公替代渠道 → ② 提“境外/无票支出申请” → ③ CTO、财务、CEO 审批 → ④ 公司外币卡或对公外币付款 → ⑤ 平台账号登记台账 → ⑥ 留存 Invoice 与付款凭证 → ⑦ 按无票支出入账核销用公司支付工具完成的境外付款，附审批单、平台 Invoice/账单、付款凭证与无票说明，可入账、可审计。待新建240
FIN-05备用金/费用预支申请与核销研发/运维需先支付小额零散费用（硬件测试零件、算力、AI 账号、手机号卡、月付订阅），且来不及对公付款或暂时没有发票时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购申请人（当前：杨明学·推断待确认）、CTO 审批（当前：丁震宇·推断待确认）、CEO 特批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 判断是否适用备用金 → ② 提“备用金申请”并关联采购申请 → ③ CTO 审批（超限 CEO 特批）→ ④ 财务打款 → ⑤ 使用并取票 → ⑥ 提“备用金核销” → ⑦ 余额走还款退回公户审批留痕的备用金，按期核销、余额退回，每笔支出有发票或经批准的无票说明。待优化144
FIN-06日常费用报销提交与审核员工因公垫付办公采购、设备、餐费、耗材、零食福利、打车、通信、云服务等费用后需要报销时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——行政（报销表单通知、票据收集、垫付打车报销，当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、各部门直属上级（当前：按申请人）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 对照可报销清单判断 → ② 取得合规发票（抬头为所属主体）→ ③ 飞书“费用报销”提单 → ④ 直属上级审批 → ⑤ 财务审核 → ⑥ 终审 → ⑦ 制单打款并回传回单 → ⑧ 票据整理归档已付款的报销单，附合规发票、付款凭证与回单，可入账、可审计。待优化180
FIN-07差旅事前报备与差旅报销员工因公到外地或境外出差、参会、拜访客户时，从事前报备到报销付款全程适用。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——综合部（差旅制度与行程单简化，当前：赵雪冰·推断待确认）、销售负责人（审批链节点，当前：李鹏为·推断待确认）、COO 差旅标准制定（当前：常元和·推断待确认）、CEO 特批与制度梳理（当前：邴龙志·推断待确认）、市场部（报销填单 AI skill，当前：陈芷青·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 出差前提“出差报备” → ② 直属上级审批（超标/境外加特批）→ ③ 出行并收集电子发票 → ④ 生成往返闭环行程单 → ⑤ 提“费用报销”关联报备 → ⑥ 财务审核 → ⑦ 打款 → ⑧ 参会成果文档归档（如适用）已付款的差旅报销单，关联出差报备，附闭环行程单、发票和（如适用）特批记录与参会成果文档。待优化108
FIN-08企业滴滴充值与通勤打车报销员工通勤、加班返程、因公出行打车，以及企业滴滴账户月度充值、额度调整、余额不足时适用。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——财务充值（当前：黄梦婷·推断待确认）、行政用车仪表盘（当前：侯明月·推断待确认）、CEO 标准制定（当前：邴龙志·推断待确认）、人事入离调同步（当前：黄莹·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职开通并宣讲 → ② 员工按入口用车 → ③ 行政月度汇总提交充值 → ④ 财务充值 → ⑤ 余额预警 → ⑥ 月度仪表盘与抽查 → ⑦ 余额不足时垫付报销 → ⑧ 入离调同步账户每月额度充足可用的企业滴滴账户、月度用车仪表盘与核查记录。待优化36
FIN-09活动/团建/大会费用预算与统计归集行政或业务小组组织团建、主题活动、生态大会等，需要事前报预算、事中按口径采购或垫付、事后报销，并按活动汇总实际花费主责——活动负责人（立项时指定；团建默认行政专员，当前：侯明月·推断待确认）；协同——大会费用汇总人（综合部负责人，当前：赵雪冰·推断待确认）、各组负责人、报销人、财务专员（当前：刘梦可·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项报预算 → ② 预算审批 → ③ 发布费用口径 → ④ 按口径采购/垫付 → ⑤ 报销时关联活动名 → ⑥ 各组登记明细 → ⑦ 预算对照汇总 → ⑧ 财务核对归档活动费用汇总表（预算 vs 实际，按科目/小组拆分），关联的报销单与发票齐全并归档待优化81
FIN-10员工 AI 工具补贴核发与超额报销每月按岗位核发员工 AI 工具补贴；员工因工作使用 AI 工具超出补贴需额外申请或报销；外部研发方、参赛者需要订阅支持；补贴资格复核与使用调研主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（补贴表核算，当前：黄莹·推断待确认）、创始人兼 CTO（口径解释与超额审批，当前：丁震宇·推断待确认）、CEO（标准与预算，当前：邴龙志·推断待确认）、产品负责人（LeapAll 充值核验，当前：杨萌·推断待确认）、行政专员（AI 采购登记，当前：侯明月·推断待确认）；兜底——综合部负责人① 冻结当月名单与分档 → ② 差异比对 → ③ 管理层审核 → ④ 计税并提付款 → ⑤ 每月 15 日打款 → ⑥ 超额申请审批 → ⑦ 发票审核报销 → ⑧ 充值/使用核验与月度统计当月 AI 补贴发放表与付款凭证（含个税代扣记录）、已审批的超额申请与合规票据报销单、充值/使用核验名单、按主体汇总的月度 AI 费用统计、一页式补贴制度待优化256
FIN-11飞书报销审批表单配置与应用问题处理财务新建或调整飞书费用报销、预付后补票、关联差旅报备等审批表单；员工提交时遇到退回、发票被占用、控件值为空、明细超行数、需撤回修改等应用问题主责——财务负责人（当前：黄梦婷·推断待确认）；协同——飞书审批管理员（当前：黄莹·推断待确认）、发票报销应用管理员（当前：丁震宇·推断待确认）、综合部负责人（报销自动化改造，当前：赵雪冰·推断待确认）、外部厂商客服；兜底——综合部负责人① 员工按 FAQ 自查 → ② 提交问题单 → ③ 财务排查 → ④ 转管理员/厂商 → ⑤ 表单变更测试 → ⑥ 发布 → ⑦ 通知 → ⑧ 沉淀 FAQ可用的报销类表单配置及变更记录、员工问题处理记录、《报销系统 FAQ》、应用管理员与插件余量台账待优化81
FIN-12进项发票索取、缺票催收与归档公司或员工产生采购、垫付、云服务/SaaS、订阅等支出后，向供应商索取合规发票，财务收集、去重、催收缺票并归档，集中处理抵扣票主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT/采购（云服务与海外订阅开票，当前：杨明学·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（SaaS 席位开票，当前：黄莹·推断待确认）、各支出经办人；兜底——综合部负责人① 支出时按开票信息卡索票 → ② 上传并登记台账 → ③ 识别去重 → ④ 重命名归档 → ⑤ 月度缺票清单 → ⑥ 催收补票 → ⑦ 无票/异常人工判定 → ⑧ 抵扣票汇总按主体、月份统一命名归档的进项发票库；发票台账（含是否已报销、是否抵扣）；月度缺票清单与催收结果待优化192
FIN-14劳务、顾问及奖金类报酬结算与个税兼职、劳务人员、外部顾问、驻场人员、外部技术服务方按月或按项目结算报酬，或比赛奖金发放，需要确认用工性质与工作量、签协议、开票或代扣个税并付款主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（台账与确认单汇总，当前：黄莹·推断待确认）、业务负责人（确认工作量，当前：杨萌·推断待确认）、CEO（结算方式决策，当前：邴龙志·推断待确认）、COO（合同签批，当前：常元和·推断待确认）、创始人兼 CTO（技术服务方需求，当前：丁震宇·推断待确认）、赛事组织负责人（当前：白福康·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人① 判定用工/合作性质 → ② 签合同或协议 → ③ 月度工作量确认 → ④ 开票或代扣个税 → ⑤ 付款申请关联合同 → ⑥ 付款 → ⑦ 台账更新与凭证归档外部人员结算台账、已签署的合同/协议、工作确认单、发票或完税凭证、付款回单、奖金归属确认书待新建144
FIN-15支付通道选型、商户进件与收款权限开通产品或新主体需要上线收款、分账，或已有商户需开通网银、微信/支付宝、公众号/小程序支付、临时额度，或渠道风控、资质异常导致支付失败主责——支付渠道负责人（汇付商户与渠道控台，当前：徐莉·推断待确认）；协同——创始人兼 CTO（需求发起与选型拍板，当前：丁震宇·推断待确认）、财务负责人（进件材料、流水与合同，当前：黄梦婷·推断待确认）、综合部负责人（主体证照与协议，当前：赵雪冰·推断待确认）、支付研发（当前：陈锦杰、王子明、张楠·推断待确认）、鼎慧商户管理员（当前：杨萌·推断待确认）、CEO（对接支付方高层，当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO① 登记收款需求 → ② 查台账/通道选型评估 → ③ 拍板主体与通道 → ④ 准备进件材料 → ⑤ 提交进件并跟进 → ⑥ 安全交接密钥 → ⑦ 沙箱 + 小额实测 → ⑧ 登记台账并持续监控资质已开通并实测通过的商户与通道；主体-商户号-appid-支付能力台账；选型评估记录；进件材料包；风控材料标准包待新建250
FIN-16内部测试与客户赠送额度申请审批内部测试、FDE、演示账号，或新交付、试用客户需要平台额度、词元、兑换券时的申请、审批、充值/发券、台账登记、成本归属与回收主责——额度审批人（产品负责人，当前：杨萌·推断待确认）；协同——后台充值执行（当前：柯逸飞、邓乾、宋祺睿·推断待确认）、商务负责人（客户特批，当前：李鹏为·推断待确认）、财务负责人（成本归属与渠道线下充值，当前：黄梦婷·推断待确认）、FDE 负责人（培训机额度标准，当前：吴亚军·推断待确认）、生态组负责人（社区卡密，当前：陈梦琪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交额度申请 → ② 按标准审批 → ③ 超标准特批 → ④ 后台充值/生成券 → ⑤ 申请人确认 → ⑥ 台账登记与成本归属 → ⑦ 月度对账 → ⑧ 到期回收经审批的额度申请记录、后台充值/发券记录、额度台账（对象、金额、用途、成本中心）、月度赠送额度成本汇总待新建128
FIN-17客户充值到账审核与额度开通企业/渠道客户为 LeapCore、LeapAll 付款充值（线上支付或线下对公转账），或新部署机器需预充、额度用尽需续充时，从确认到账到开通额度、对账闭环主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、额度充值执行人（当前：柯逸飞·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交充值订单/下载结算单 → ② 付款并上传汇款凭证 → ③ 财务审核到账 → ④ 接口开通额度（含赠送） → ⑤ 订单完结并通知 → ⑥ 日对账与客户/实例绑定 → ⑦ 退款/补发/错充处理已审核到账、额度到位且留痕的充值订单；订单—支付—到账—额度—客户/实例一一对应的充值台账与月度对账表待新建300
FIN-18客户充值订单开票客户在 LeapCore/LeapAll 线上或线下充值 Token 后申请发票，或需集中登记对外开票（含兑换券、集采）时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、LeapCore 发票功能研发（当前：魏宗浩·推断待确认）、渠道系统维护负责人（当前：郭逸非·推断待确认）、销售支持（当前：韩诗琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 订单已支付并已充值 → ② 客户提交开票信息 → ③ 同步渠道系统待开票 → ④ 财务判定票种并开具 → ⑤ 上传发票回写订单 → ⑥ 通知客户并登记台账 → ⑦ 错票红冲重开与充值订单一一对应、票种正确的电子发票，订单页可查看下载；对外开票台账完整待优化240
FIN-19销售合同开票申请与红冲销售合同签署、交付验收或约定预付款节点到达后，业务申请开票；以及错票红冲、客户催票、收款认款核销时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·合同台账（当前：韩诗琪·推断待确认）、总经办（当前：田杰·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 合同编号登记 → ② 业务提交开票申请 → ③ 财务校验开票条件与税率 → ④ 税务系统开具 → ⑤ 上传分发给申请人/客户 → ⑥ 回款认款与凭证核销 → ⑦ 错票红冲重开税目税率正确、与合同和收款对应的发票；认款核销完成的收款记录与凭证待优化300
FIN-20软硬一体合同分税率开票与硬件基准价维护LeapCore 等软硬一体销售合同起草、审核和开票时，按硬件 13%、软件及技术服务 6% 拆分金额；每月按采购价校准 SKU 硬件基准价主责——财务负责人（当前：黄梦婷·推断待确认）；协同——总经办（当前：田杰·推断待确认）、IT 价格维护（当前：游家豪·推断待确认）、渠道负责人·商务核价（当前：闫登辉·推断待确认）、法务负责人（当前：李瑶·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月度核定硬件基准价 → ② SKU 配置录入留痕 → ③ 合同生成按型号自动拆分 → ④ 法务审核核对拆分 → ⑤ 财务分税率开票 → ⑥ 月度校准提醒与变更通知软硬金额分列的合同、分税率发票；带生效时间和修改历史的 SKU 硬件基准价表待优化240
FIN-21收入合同台账、回款跟进与收入确认合同签订、交付验收、开票、回款各节点发生时登记收入合同台账，跟进回款，核对公户进款并按月确认收入，处理"已交付/已回款但无合同"业务主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·台账（当前：韩诗琪·推断待确认）、销售对接人（当前：闫登辉、吴琪、杜中瑞·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 合同签订登记台账 → ② 交付与验收单回传 → ③ 开票登记 → ④ 回款跟进与催款 → ⑤ 公户进款认领核对 → ⑥ 月末收入确认 → ⑦ 无合同业务清单处理字段完整的收入合同台账；每月收入确认清单与应收账龄表；无合同业务处理结论待优化240
FIN-22境外客户收款、形式发票与结汇海外客户按合同以外币付款时，开具形式发票（Proforma Invoice），到账后向银行补材料审核、结汇入账并存档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——业务对接人（当前：丁震宇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 业务提出收款需求并提供交易信息 → ② 签署对方盖章的英文合同 → ③ 开具形式发票并盖章 → ④ 发送客户并按对方时区跟进 → ⑤ 网银汇入汇款确认上传材料 → ⑥ 大额加强审核补材料 → ⑦ 结汇入账 → ⑧ 存档与台账结汇完成的人民币入账；合同、形式发票、银行审核材料、结汇凭证完整存档；境外回款台账待优化200
FIN-23渠道/开发者分成结算、分润打款与开票产品收款需按约定分给开发者、渠道、合作方，商城需向厂商或渠道平台结算，或用户支付后需退款冲正时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——支付/分账研发（当前：陈锦杰·推断待确认）、LeapCore 产品负责人（当前：杨萌·推断待确认）、字字可研产品经理（当前：黄飞鹏·推断待确认）、商城对接研发（当前：葛家和·推断待确认）、COO（税务口径，当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 结算规则书面确认 → ② 系统计算待分成金额 → ③ 财务核对 → ④ 分账或批量打款 → ⑤ 开票/收票 → ⑥ 对账 → ⑦ 退款与冲正按书面规则完成的分账/打款记录、对应发票、月度结算对账单；退款审批与冲正记录待新建225
FIN-24支付渠道每日对账、手续费与差异处理每日支付、分账、提现、退款发生后核对系统与支付平台、公户到账；处理对账差异与失败重跑；每月核对收单与公户到账、申请手续费发票主责——财务负责人（当前：黄梦婷·推断待确认）；协同——跃竞后端负责人·对账开发（当前：王子明·推断待确认）、LeapPay 支付研发（当前：陈锦杰·推断待确认）、跃竞负责人·支付商户管理（当前：徐莉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 每日 20:00 机器人推送对账结果 → ② 判定账实平/差异/失败 → ③ 失败重跑 → ④ 差异分类与修复 → ⑤ 财务确认关闭 → ⑥ 月度收单与公户到账核对 → ⑦ 手续费发票申请与入账每日对账结论均有回执；差异清单逐条关闭；月度支付结算对账表；手续费发票按月取得待优化200
FIN-25资金/分账异常排查与数据修复支付回调异常、分账延迟或待结算队列积压、钱包/俱乐部账与支付平台余额不一致、资金任务告警触发时，启动排查、资金修复、客户告知与复盘主责——跃竞后端负责人（当前：王子明·推断待确认）；协同——跃竞后端研发（当前：张楠、蒋兴武·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、商户运营（当前：宫经喜·推断待确认）、财务专员（当前：刘梦可·推断待确认）、V5 后端研发（当前：陈锦杰·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 发现与登记 → ② 止损与定级 → ③ 根因排查 → ④ 资金影响清单 → ⑤ 修复方案审批 → ⑥ 执行修复/手动分账 → ⑦ 财务复核与客户告知 → ⑧ 复盘与监控补齐已闭环的资金异常工单（含影响清单、修复记录、财务复核结论）、对受影响商户/俱乐部的书面告知、复盘结论与新增监控项待新建500
FIN-26网关月度账单导出与财务对账每月初财务需要上月网关账单（token 类与非 token 类计费），或财务提出新的账单字段/导出需求时启动主责——网关计费研发（当前：柯逸飞·推断待确认）；协同——财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、产品总监（当前：杨萌·推断待确认）、研发工程师（提供单价，当前：魏宗浩·推断待确认）、支付研发（当前：陈锦杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 月初定时导出 → ② 研发自检 → ③ CTO 审核口径 → ④ 推送财务 → ⑤ 财务对账 → ⑥ 差异提工单 → ⑦ 归档上月网关账单包（按上游、按 Key、按 API 三份 CSV + 字段说明）、财务对账结论、差异工单待优化108
FIN-27客户按量计费月度账单核算与发送按工作量、token 或调用量向客户收费的项目或 API 客户，每个结算周期核算用量、计算折扣、出具账单并发送收款时启动主责——客户项目研发对接人（当前：葛家和、李铭熙·推断待确认）；协同——创始人兼 CTO（定价折扣把关，当前：丁震宇·推断待确认）、COO（商务定价口径，当前：常元和·推断待确认）、研发工程师（工时数据，当前：魏宗浩·推断待确认）、财务专员（开票收款，当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 月度提醒 → ② 导出用量/工时 → ③ 按合同口径核算 → ④ 折扣与报价审核 → ⑤ 发送客户 → ⑥ 开票收款 → ⑦ 归档经审核的客户月度账单（用量明细 + 应收金额）、发送记录、开票与收款记录待优化180
FIN-28模型成本价、计价倍率维护与成本收入核对新增/调整上游渠道、官方调价、汇率变化、产品定价调整，或怀疑计价与成本不一致时，维护成本价与汇率、确定倍率/毛利/额度包并定期核对成本与收入主责——IT 运维/上游渠道维护（当前：杨明学·推断待确认）；协同——创始人兼 CTO（价格谈判与定价拍板，当前：丁震宇·推断待确认）、产品总监（定价档位与毛利，当前：杨萌·推断待确认）、网关计费研发（当前：柯逸飞、邓乾、张康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售骨干（对外报价需求，当前：闫登辉·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 变更触发登记 → ② 更新成本价主表 → ③ 定价/倍率审批 → ④ dry-run 同步网关 → ⑤ 上线核对 → ⑥ 通知相关方 → ⑦ 月度成本收入对账最新成本价主表（模型-渠道-币种-折扣-汇率-生效日期）、售价/倍率配置记录、月度成本收入对账报告待优化320
FIN-29计费扣费异常核查与退补客户或内部用户质疑扣费异常、单次报告/对话消耗远超预期、误调用高成本模型时，核算真实成本、判断是否多收、决定退补并校准计价口径主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——网关计费研发（当前：柯逸飞、邓乾·推断待确认）、后端研发（当前：陈锦杰、宋祺睿·推断待确认）、产品总监（客户口径，当前：杨萌·推断待确认）、渠道/客户对接研发（当前：陈子康·推断待确认）、测试负责人（定性，当前：张东郅·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 定级 → ③ 拉日志与成本 → ④ 按定价公式核算 → ⑤ 定性（计费错误/正常消耗/误调用） → ⑥ 修复 → ⑦ 退补审批 → ⑧ 答复客户与沉淀扣费异议核查报告（数据、结论、多收金额）、修复版本、退补审批单、客户答复记录待新建400
FIN-30云/模型服务成本按项目归集与账号台账月度云账单出具、需按项目归集云/模型成本、统计个人与项目 API 用量，或维护多主体云账号台账与回收发票时启动主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、创始人兼 CTO（账号持有与归集口径，当前：丁震宇·推断待确认）、Leap 研发负责人（IaC 规范，当前：王皓南·推断待确认）、后端/运维研发（当前：宋祺睿·推断待确认）、网关计费研发（当前：柯逸飞·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月初下载各平台账单与回单 → ② 按项目/标签筛选导出 → ③ 未归集资源补归属 → ④ 内部 API 用量按人/项目统计 → ⑤ 成本分摊入账 → ⑥ 发票回收 → ⑦ 台账更新月度按项目云/模型成本表、账号台账（平台-主体-用途-开票规则）、发票回收记录待优化81
FIN-31研发项目立项与研发费用归集新增研发项目需立项，或审计、税务（研发加计扣除、软件退税）要求立项资料、研发工时划分、费用归集与阶段性成果说明时启动主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（技术口径与人员划分，当前：丁震宇·推断待确认）、研发人员（工时填报）、客户端研发（阶段性成果材料，当前：葛家和·推断待确认）、行政（材料保密，当前：侯明月·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项三件套起草 → ② 技术补充与审批 → ③ 设科目与项目辅助核算 → ④ 月度工时填报 → ⑤ 费用归集 → ⑥ 季度成果沉淀 → ⑦ 审计/税务材料输出各研发项目立项三件套（立项申请书、可行性报告、股东会纪要）、月度人工成本核算表、按项目研发费用明细、阶段性成果说明待优化240
FIN-32多主体业务归属与子公司成本隔离子公司或关联主体使用母公司资源、采购服务或对外签约时，确认合同签署主体与采购/出货主体一致、子公司支出走本主体采购并归集、跨主体成本分摊与账目隔离主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（资源与支出审批，当前：丁震宇·推断待确认）、IT 采购（当前：杨明学·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、子公司业务负责人（当前：赵捷·推断待确认）、COO（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 业务发起时确定签约主体 → ② 校验采购/出货主体 → ③ 子公司支出走本主体采购 → ④ 跨主体资源使用申请 → ⑤ 按主体分账号/分 key → ⑥ 月度消耗对账与分摊 → ⑦ 切换与归档主体一致的合同与采购记录、子公司资源与 API Key 台账、跨主体资源使用批准记录、月度分摊对账表待新建200
FIN-33关联主体资金划转与注资集团内某主体（子公司/关联公司）账户余额不足以支付工资、税费、货款，或需实缴注册资本时，由其他主体向其划转资金主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定性审批）、创始人兼 CTO（当前：丁震宇·推断待确认，付款执行/审批）、法务负责人（当前：李瑶·推断待确认，协议与决议）；兜底——CEO① 月度资金预警 → ② 缺口测算与方案（借款/投资款） → ③ 管理层定性审批 → ④ 协议或股东决定 → ⑤ 付款申请与打款 → ⑥ 入账与凭证留存 → ⑦ 台账登记与还款/实缴跟踪按审批定性完成的资金划转、对应借款协议或注资决议、银行回单与注资证明、关联往来台账更新待新建120
FIN-34子公司月度营收统计与汇报每月第一周，子公司（当前为跃竞）导出上月营收（交易手续费、会费）与流水，按统一口径向董事会汇报主责——跃竞负责人（当前：徐莉·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认，定口径）、CEO（当前：邴龙志·推断待确认，审阅追问）、财务负责人（当前：黄梦婷·推断待确认，口径复核）；兜底——CEO① 每月 1 日提醒 → ② 导出汇付流水与会费数据 → ③ 按口径剔除余额支付等 → ④ 填月报模板 → ⑤ 群内提交摘要+明细 → ⑥ 董事会审阅追问 → ⑦ 归档并用于分润/奖金核算月度营收报告（文字摘要 + 会费统计表 + 商户汇总净额表），存档于固定位置待优化81
FIN-35月度税务申报与税额确认每月/每季度法定申报期内，完成各主体增值税、附加税、印花税、个税、企业所得税的测算、管理层确认与申报缴纳主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，税额确认）、代账会计（当前：待指定，外部协助）、人事负责人（当前：黄莹·推断待确认，人员异动）；兜底——CEO① 申报日历提醒 → ② 下载回单、核对开票与进项勾选 → ③ 测算税额与税负 → ④ 群内提交管理层确认 → ⑤ 个税按人员异动更新 → ⑥ 申报扣款 → ⑦ 保存完税凭证 → ⑧ 遗漏检查各主体按期完成的申报表、扣款回单与完税凭证，月度税额测算表存档已有180
FIN-36审计、尽调与投标财务资料准备年度审计、融资尽调、投标或申报需要经审计财务报告或成套财务资料时，从需求确认到资料提交的全过程主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，对外提交前合规检查）、销售/人事等业务部门负责人（当前：待指定，补票与访谈）、政策申报负责人（当前：王蕊·推断待确认，政府补助资料）；兜底——CEO① 接收需求（用途、截止日、口径）→ ② 发资料清单 → ③ 资料收集与缺票催收 → ④ 差异调账与三表勾稽 → ⑤ 配合审计访谈 → ⑥ 管理层合规检查 → ⑦ 出具提交 → ⑧ 归档审计报告或尽调/投标财务资料包（报表、序时账、科目余额表、申报表、银行流水、合同、补充说明），提交记录与归档待优化250
FIN-37财务人员交接、代账交接与整顿期汇报财务人员更换，或代账公司/异地主体（武汉、苏州等）账务转回内部时，完成交接、建账、补账，并在整顿期定期汇报进度主责——财务负责人（接手方，当前：黄梦婷·推断待确认）；协同——原财务人员（移交方，当前：祁航·推断待确认）、代账会计（当前：待指定）、CEO（当前：邴龙志·推断待确认，下达交接与跟进汇报）；兜底——CEO① 下达交接指令 → ② 移交清单（账户、税务、社保公积金、网银、海外收付款）→ ③ 代账资料逐项核对 → ④ 建账（科目、期初、辅助核算）→ ⑤ 差异调账与勾稽 → ⑥ 补做往期账务 → ⑦ 整顿期日报/周报 → ⑧ 交接确认签字双方签字的交接清单、完整的资料与权限移交、内部建好的账套（期初平衡）、整顿期汇报记录待优化250
FIN-38主体工商税务登记变更与注销子公司注销（含简易注销）、营业执照补领、办税员添加等主体工商税务登记事项的材料准备、办理与结果归档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，决策与签字）、COO（当前：常元和·推断待确认，结果接收方/签字人，推断）、法务负责人（当前：李瑶·推断待确认，决议文件）、总经办（当前：田杰·推断待确认，证照归档）；兜底——CEO① 事项发起与决策 → ② 材料清单与决议 → ③ 税务前置申报/清算 → ④ 取得清税证明 → ⑤ 工商办理（公示）→ ⑥ 银行、社保等配套注销/变更 → ⑦ 回执归档并通知相关人办理完成的登记结果（注销回执/新执照/办税员权限）、扫描件归档于证照台账，相关人确认已收到待新建72
FIN-39资金计划与临时周转借款按月编制滚动资金计划，预判阶段性资金缺口；确需通过借款或银行授信等方式短期周转时，完成方案审批、协议签署、到账入账与还款跟踪主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 滚动资金计划与预警 → ② 缺口测算 → ③ 方案比选（股东借款/外部机构借款/银行授信）→ ④ 审批 → ⑤ 协议签署与用印 → ⑥ 到账入账 → ⑦ 还款计划与跟踪 → ⑧ 结清归档滚动资金计划、经审批的周转方案、签署的借款或授信协议、到账回单与入账凭证、还款台账及结清证明待新建75
FIN-40银行账户、网银 UKey 管理与付款复核各主体银行账户开立、变更、销户，网银 UKey 与密码保管、授权变更，以及每笔对公付款的制单—复核分离时适用主责——出纳（当前：待指定）；协同——付款复核人（当前：待指定）、法务（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 账户台账 → ② 开户/变更/销户审批 → ③ UKey 分离保管 → ④ 制单 → ⑤ 复核授权 → ⑥ 回单核对 → ⑦ 月度余额对账多主体银行账户台账、UKey 保管登记、付款制单与复核记录、月度银行余额调节表待新建80
FIN-41月度结账与管理报表每月结束后，对各主体完成费用、收入、成本、往来的入账与核对，出具财务报表与管理报表供管理层决策时适用主责——总账会计（当前：待指定）；协同——出纳（当前：待指定）、各业务部门（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 结账日历 → ② 业务单据截止 → ③ 银行与支付渠道对账 → ④ 收入成本确认与费用计提 → ⑤ 往来核对 → ⑥ 关账出表 → ⑦ 管理报表与分析各主体月度资产负债表、利润表、管理报表（收入、毛利、模型成本、人力成本、现金余额）待新建144
FIN-42年度企业所得税汇算清缴与研发费用加计扣除每年 1 月起至 5 月 31 日前，各主体完成上一年度企业所得税汇算清缴、研发费用加计扣除及高新技术企业相关指标核对时适用主责——税务会计（当前：待指定）；协同——研发项目负责人（当前：待指定）、人事（当前：待指定）、外部税务师（如有）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 制定汇算计划 → ② 年度账务调整 → ③ 研发费用辅助账与项目资料核对 → ④ 纳税调整测算 → ⑤ 管理层确认 → ⑥ 申报与缴补税 → ⑦ 资料留存备查各主体年度企业所得税申报表、研发费用辅助账与备查资料、补退税记录待新建75
FIN-43年度预算编制与执行分析年度/季度开始前编制各部门与各主体的收入、成本、费用、人力、算力预算，以及每月对比实际执行、超预算审批时适用主责——财务预算专员（当前：待指定）；协同——各部门负责人（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 下发预算模板与假设 → ② 部门编报 → ③ 财务汇总平衡 → ④ 管理层审定 → ⑤ 预算分解发布 → ⑥ 月度执行分析 → ⑦ 超预算审批与季度调整经审定的年度预算（按部门、主体、科目）、月度预算执行分析表待新建160
FIN-44政府补助资金到账、专款核算与验收审计科技项目、人才计划、上云补贴等政府补助资金到账后，进行确认、专款核算、按要求使用，并配合项目验收与专项审计时适用主责——总账会计（当前：待指定）；协同——政策申报专员（当前：待指定）、项目负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 到账识别 → ② 对应项目与资金性质确认 → ③ 设专项辅助核算 → ④ 按预算使用并留证 → ⑤ 定期执行报告 → ⑥ 验收/专项审计配合 → ⑦ 结余处理与归档补助资金台账、专项核算明细、验收与审计资料、结余处理记录待新建120

LEG 法务 报送人：李瑶

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
LEG-01合同模板库建设、版本维护与发布产品、价格、税点、渠道政策发生变化，或新业务、新系统（渠道系统、线上充值）上线需要合同模板时，由法务修订或新建模板，定稿后编号发布到唯一模板库，旧版同时作废主责——法务负责人（当前：李瑶·推断待确认）；协同——模板版本维护人/渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、总经办（当前：田杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交模板变更/新建申请 → ② 法务评估影响并列出待定规则 → ③ 业务、财务答复规则 → ④ 法务修订 → ⑤ 销售/产品/财务会签 → ⑥ 定版编号入库、旧版作废 → ⑦ 发布并同步系统模板 → ⑧ 抽查使用情况唯一模板库中的定稿模板（带版本号、生效日期、变更摘要、适用场景），发布通知，以及渠道系统、电子签中同步更新的模板待优化225
LEG-02我方签约主体选择与印章信息登记起草合同或报价、申请用印、试用转正式时，集团内有多个主体（模态跃迁、鼎慧、渠道公司等）都可能签约，需要定下我方签约主体及结算路径；主体资料与印章信息需要在系统里新增、变更或关闭时主责——法务负责人（当前：李瑶·推断待确认）；协同——起草合同的销售（当前：吴琪·推断待确认）、产品/鼎慧负责人（当前：杨萌·推断待确认）、财务（当前：待指定）、总经办（当前：田杰·推断待确认）、CMS 研发（当前：裴建武·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 起草前填写主体判断要素 → ② 按主体决策表初判 → ③ 财务确认收款、开票与集团内采购路径 → ④ 法务确认 → ⑤ 例外情形审批 → ⑥ 合同审批单选主体并带出资料 → ⑦ 主体与印章主数据维护每份合同的主体确认结论（含集团内采购/结算安排），以及系统内准确的“签约主体—印章”主数据待新建120
LEG-03销售合同审查与多方会签销售或商务起草、或客户修改销售类合同（LeapCore 一体机、行业版、渠道代理、试用、词元充值、设备借用、战略框架）后，在签署前由法务、产品、技术/交付、财务会审定稿主责——法务负责人（当前：李瑶·推断待确认）；协同——销售/商务起草人（当前：闫登辉、杜中瑞、时建、杨朋伟、陈名赞、汪家诺、吴琪、刘昱潇·推断待确认）、产品负责人（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 硬件审核（当前：杨明学·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 按现行模板起草并自查 → ② AI 预审并判定通道 → ③ 提交审核 → ④ 标准合同快速核对 / 非标合同多方并联会审 → ⑤ 起草人修订留痕 → ⑥ 非标与让步终审 → ⑦ 提交飞书合同审批并用印签署 → ⑧ 归档经会审定稿、与报价单/配置单一致的销售合同，飞书合同审批记录，修订记录与审查报告待优化375
LEG-04采购/服务及其他对外合同、承诺函起草与审核我方采购 API/大模型服务、硬件或技术服务，签一体机交付与服务合同、网络施工/装修/搬家/场地等工程类合同、保密协议模板，以及向客户出具承诺函、质保函等非销售类对外文件时，由法务审核定稿（含配套验收单/结算单）主责——法务负责人（当前：李瑶·推断待确认）；协同——总经办（当前：田杰·推断待确认）、业务负责人（当前：丁震宇、常元和·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、IT 硬件（当前：杨明学·推断待确认）、市场/渠道（当前：闫登辉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交合同审核申请并写清交易背景 → ② 选模板或提交对方文本起草 → ③ 业务确认内容一致性 → ④ 法务审核并配套验收单/结算单 → ⑤ 财务核对付款开票税点 → ⑥ 定稿 → ⑦ 用印签署与付款 → ⑧ 归档法务审定的对外合同（附验收单/结算单）、承诺函或质保函，飞书合同审核记录，后续用印与付款依据待优化144
LEG-05保密协议与外部合作（合作开发/非劳务）协议拟定与客户、外部公司或非员工个人开展合作前，需要交换敏感资料（脱敏数据、PRD、代码方案）或界定合作关系时，先签保密协议、合作开发保密与知识产权协议或非劳务合作协议，再开放资料与权限主责——法务负责人（当前：李瑶·推断待确认）；协同——客户对接商务（当前：杨朋伟·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、人事负责人（当前：黄莹·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、COO（当前：常元和·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 业务提出合作与资料交换需求 → ② 法务问询合作性质 → ③ 选模板起草或审对方文本 → ④ 业务与人事确认商务与人员安排 → ⑤ 跟踪对方审批节点 → ⑥ 用印寄送 → ⑦ 签署后开放资料与权限 → ⑧ 归档并设到期提醒双方签署的保密协议/合作开发协议/非劳务合作协议，协议节点跟踪记录，资料与权限开放记录待新建120
LEG-06股东会/董事会决议与合资合伙协议签署召开股东会/董事会表决，设立合伙企业或合资公司，签署对外补充协议或期权激励方案等公司治理类文件时，由管理层先读、法务审阅，按签署检查清单完成签署盖章主责——总经办（当前：田杰·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、协议起草人（当前：陈晖·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 登记文件与签署截止日 → ② 管理层在同一份文档批注商业意见 → ③ AI 风险初筛 → ④ 法务审阅 → ⑤ 定稿并按签署清单检查 → ⑥ 会议表决（如需） → ⑦ 签名用印 → ⑧ 归档并启动后续变更法务审定并签署盖章的决议、合伙/合资协议、补充协议或期权文件，表决记录，签署检查清单待新建120
LEG-07云厂商合同与代付协议电子签署各云厂商/办公软件平台通过电子签平台发来合同变更、三方代付协议、代付合同等签署待办时，确认变更内容、按需法务审阅后完成电子签署并归档主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 收到签署待办并登记 → ② 拉取变更摘要 → ③ 判定快速签或法务审 → ④ 法务、财务确认（需要时） → ⑤ 授权签署人在平台签署 → ⑥ 下载归档并登记到期日 → ⑦ 通知财务与供应商台账更新已签署的云厂商合同/代付协议 PDF、变更摘要、合同台账记录待优化18
LEG-08业务电子合同（电子签）接入与线上签约产品或业务需要在线签约（LeapCore 词元充值、行业版客户、渠道硬件合同、俱乐部与陪玩代签）时，接入电子签平台、配置并授权法务定稿的合同模板，上线后批量出具电子合同并存档主责——业务线产品负责人（当前：杨萌·推断待确认；跃竞线：徐莉·推断待确认）；协同——电子签接入研发（当前：陈锦杰、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部/合同模板（当前：赵雪冰·推断待确认）、销售模板起草（当前：吴琪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、前端（当前：魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、运营执行（当前：刘安达、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 立项明确签约场景 → ② 评估复用与平台采购 → ③ 法务定稿模板并定可变字段 → ④ 控制台配置与授权 → ⑤ 开发接入 → ⑥ 测试验收 → ⑦ 上线并发布操作手册 → ⑧ 运行存档与模板变更管控上线可用的电子签约功能、已授权的合同模板、电子合同 PDF 存档、接入与授权手册、操作 SOP待优化160
LEG-09用章用印审批与盖章版本核对合同、协议、报价表、股东会/董事会决议、证明、函件、申报材料、授权文件等需要加盖公司印章（公章/合同章/法人章/骑缝章）时，先按类型和分级走审批，再核对版本后盖章、回传扫描件并归档主责——行政负责人（当前：胡则瑾·推断待确认）；协同——印章保管与盖章执行（当前：侯明月·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、总经办（当前：田杰·推断待确认）、飞书审批管理员（当前：黄莹·推断待确认）、各部门申请人；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 判定审批类型 → ② 法务/财务前置审核 → ③ 发起飞书审批 → ④ 分级审批 → ⑤ 锁定最终版 → ⑥ 打印并比对审批附件 → ⑦ 盖章登记 → ⑧ 回传扫描件 → ⑨ 原件交行政归档与审批附件一致的盖章文件、上传至审批单的盖章扫描件、用印登记记录、交行政归档的纸质原件待优化240
LEG-10公司证照、授权委托书与负责人签字材料提供ICP/网站备案、软件分发认证、企业开发者注册、短信签名、云服务开通、合作协议签署等需要营业执照、授权委托书、承诺书、在职证明，或需法定代表人/指定负责人签字盖章时，出具合规的盖章版材料主责——行政/印章管理（当前：侯明月·推断待确认）；协同——综合部证照提供（当前：赵雪冰·推断待确认）、苏州主体资料对接（当前：刘昱潇·推断待确认）、申请人（IT 运维/后端运维，当前：杨明学、宋祺睿·推断待确认）、授权签字人（当前：待指定）、协议审核（当前：邴龙志、常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 申请人列材料清单 → ② 确认主体与签字人 → ③ 从证照库取最新版 → ④ 套模板起草授权书/承诺书 → ⑤ 发起用章用印申请 → ⑥ 签字盖章 → ⑦ 回传并登记符合平台要求的盖章版证照复印件/扫描件、授权委托书、承诺书、在职证明，签字人与用印记录可追溯待优化81
LEG-11合同编号、台账与原件归档合同（含订货单、战略/三方协议、云厂商电子合同）签署前需要编号，签署完成后需登记台账、归档原件；或尽调、报销、审计、查账需要查找合同时主责——总经办合同管理（当前：田杰·推断待确认）；协同——编号规则拍板（当前：丁震宇·推断待确认）、系统对接研发（当前：陈锦杰·推断待确认）、合同经办人（销售，当前：吴琪、时建、刘昱潇·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 审批通过时取号 → ② 编号写入合同正文与订货单 → ③ 双签后上传扫描件并登记台账 → ④ 原件交行政入柜并记录位置 → ⑤ 借阅登记 → ⑥ 每季度核对补录全公司唯一编号的合同台账（可按主体、对方、类型、状态检索）、扫描件云盘、原件存放位置可查的档案柜待新建144
LEG-14专利审查意见答复与状态同步代理师发来修改意见、国家知识产权局下发审查意见通知书/补正通知/受理通知等官文时，指派发明人在期限内答复，并同步全部在途案件状态主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——发明人/技术答复（当前：丁震宇·推断待确认）、专利转让对接（当前：常元和·推断待确认）、外部代理师；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 官文/意见统一接收 → ② 登记台账并算期限 → ③ 指派发明人 → ④ 发明人答复 → ⑤ 代理提交 → ⑥ 核对代理系统状态 → ⑦ 每周推送汇总 → ⑧ 结案每件官文均在期限内完成答复，专利台账状态与代理系统一致，每周一份在途案件状态汇总待优化108
LEG-15专利挖掘培训与知识产权激励申报公司推动员工进行专利挖掘与交底撰写时，组织专利培训，并在专利/软著达到节点后按知识产权激励办法申报、核验、兑现奖金或积分主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——培训组织（总经办，当前：王欣·推断待确认）、激励口径与技术把关（当前：丁震宇·推断待确认）、人事（积分/奖金发放，当前：待指定）、财务（当前：待指定）、研发员工（当前：季学森、郭逸非·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 制定激励办法与积分口径 → ② 发布并宣贯 → ③ 组织专利挖掘培训（线下 + 录屏）→ ④ 收集专利线索 → ⑤ 节点达成后员工申报 → ⑥ 按台账核验 → ⑦ 审批 → ⑧ 公示与兑现成文的知识产权激励办法、培训录屏与资料、专利线索清单、经审批的激励兑现记录待新建32
LEG-16商标查询、注册申请与驳回复审新品牌、新产品命名或改名时，在对外使用前完成商标近似检索、确定主体与类别群组、委托申请，并跟进受理、初审公告、驳回复审、注册证与续展，同时按类别保存使用证据主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——产品负责人（当前：杨萌、徐莉·推断待确认）、类别预选与技术口径（当前：丁震宇·推断待确认）、开源社区负责人（当前：陈梦琪、葛家和·推断待确认）、复审与主体决策（当前：常元和·推断待确认）、外部商标代理；兜底——CEO（当前：邴龙志·推断待确认）① 命名前近似检索 → ② 代理出风险评估 → ③ 决定申请（主体、类别、群组）→ ④ 准备标样 → ⑤ 委托代理提交 → ⑥ 台账登记与进度跟进 → ⑦ 驳回复审决策 → ⑧ 注册证归档、使用证据保存、续展提醒商标台账（名称、主体、类别群组、申请号、状态、期限、使用证据）及注册在正确主体名下的商标注册证待新建144
LEG-17被抄袭/侵权线索处置员工发现外部网站、产品或社区页面抄袭、1:1 复刻公司官网内容/设计、产品界面或功能，或冒用公司品牌时，启动登记、取证、定性和维权主责——法务（当前：待指定）；协同——发现人（任一员工）、品牌/官网负责人（当前：待指定）、研发取证支持（当前：待指定）、对外沟通与处置决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 线索登记 → ② 证据固定 → ③ 权属与相似度评估 → ④ 查明对方主体 → ⑤ 定性并审批处置方案 → ⑥ 先礼后兵对外沟通 → ⑦ 投诉/律师函/诉讼升级 → ⑧ 结案归档与补权侵权线索登记记录、证据包（截图、录屏、存证或公证）、经审批的处置方案与对外函件、结案记录；需要时触发专利/软著/商标补申待新建48
LEG-18用户协议、隐私政策、EULA 与免责文案编制及变更管控产品、官网、社区、App 或安装包面向外部用户上线前，或新增个人信息收集、UGC、IP 属地、第三方 SDK、储值退款等功能，或产品内法律提示被改动时，编制/更新用户协议、隐私政策、社区公约、EULA、AI 免责文案，并管控后续变更主责——产品线协议负责人（产品经理）（当前：Leap 系列为杨黔昆、跃玩为樊九辰·推断待确认）；协同——法务（当前：待指定）、产品负责人（当前：杨萌·推断待确认）、客户端研发（当前：岳阳·推断待确认）、社区/生态运营（当前：陈梦琪·推断待确认）、合规负责人（当前：常元和·推断待确认）；兜底——法务负责人① 需求评审触发登记 → ② 按模板起草/修订 → ③ 法务审核 → ④ 产品与合规会签 → ⑤ 研发上线展示 → ⑥ 版本归档与告知 → ⑦ 受保护文案变更守卫 → ⑧ 半年复核经法务审核的协议/政策/EULA/免责文案定稿（含版本号、生效日）、在线链接与产品内展示位、协议版本台账、必备法律文案清单待新建180
LEG-19新产品/新功能上线合规评估产品对外发布，或研发/产品提出可能涉及合规风险的功能（第三方数据抓取或展示、读取 cookie、视频下载、云端读取客户文件、字体/素材版权、境外或未备案模型、API 对外转售、商城上架第三方产品），在开发前由法务出具合规结论与整改要求主责——法务（当前：待指定）；协同——需求提出产品经理（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、数据来源与合规责任人（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 需求评审合规勾选 → ② 补齐评估材料 → ③ AI 初筛 → ④ 法务出结论 → ⑤ 争议事项决策 → ⑥ 按整改要求实现与验收 → ⑦ 上线门禁 → ⑧ 结论入库与抽检合规评估单与合规结论书（可做/附条件可做/不可做 + 整改项）、整改验收记录、合规结论库待新建240
LEG-20AIGC 内容安全审核与 AI 生成标识合规面向国内用户的 AI 生成产品（LeapPPT、LeapAll 等）正式推广前，或出现内容审核误杀、漏放、演示被拦截、需要向监管或客户说明时，落实内容审核链路、手机号实名注册、AI 生成标识、违规处置与复盘主责——产品线内容安全负责人（当前：LeapPPT 为李凯·推断待确认）；协同——审核链路研发（当前：马漳毓·推断待确认）、云资源与审核服务开通（当前：杨明学·推断待确认）、法务（当前：待指定）、运营审核员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 推广前合规门禁 → ② 审核链路接入 → ③ AI 生成标识 → ④ 分级策略配置与回归 → ⑤ 误杀/漏放处置 → ⑥ 疑似内容人工复核 → ⑦ 违规处置与留痕 → ⑧ 月度复盘推广前检查单、审核策略配置记录、AI 生成标识实现、误杀/漏放处置记录、违规处置台账、《内容安全与隐私规范》待新建320
LEG-21营销短信与推广内容合规审核向用户发送含营销性质（优惠、免费额度包、活动、拉新、召回）的短信、站内信、邮件或推广文案前，完成分类、对象核查和文案合规审核后再发送主责——发送需求方运营（当前：待指定）；协同——法务（当前：待指定）、短信通道管理员（当前：待指定）、风险提示与技术支持 CTO（当前：丁震宇·推断待确认）；兜底——运营负责人① 提交发送申请 → ② 通知类/营销类分类 → ③ 接收对象核查 → ④ 文案合规检查 → ⑤ 通道模板报备 → ⑥ 小批量试发与正式发送 → ⑦ 投诉与退订监控 → ⑧ 模板入库审核通过的短信/推广文案与发送名单、通道模板、发送与投诉记录、合规文案模板库待新建48
LEG-22业务合规红线与灰色业务风险隔离业务中出现批量私信获客、代理 IP 池、购买/租用账号、数据买卖或交换等请求，或与外部合作方沟通涉及合规边界的话题时，按红线清单判断能否做，并让公司与员工远离违法风险主责——法务（当前：待指定）；协同——业务发起方负责人（跃竞：徐莉·推断待确认）、研发/IT（当前：待指定）、销售负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别请求 → ② 对照红线清单自查 → ③ 提交风险评审 → ④ 法务出结论（禁止/附条件可做） → ⑤ 争议决策 → ⑥ 附条件执行与留痕 → ⑦ 对外沟通口径 → ⑧ 登记台账与季度复查业务合规红线清单、风险评审结论、附条件执行的合同与授权证明、对外沟通口径、风险评审台账待新建120
LEG-23ICP/网站/App 备案办理与备案信息维护新域名、展示站、产品站或 App 需要对外使用，或云厂商发来备案核查通知、备案信息（主体、负责人、电话）需要变更时，完成 ICP 备案、公安联网备案、App 备案及备案信息维护主责——备案专员/IT 运维（当前：杨明学·推断待确认）；协同——证照与授权委托材料、签章（当前：赵雪冰·推断待确认）、苏州主体材料提供人（当前：刘昱潇·推断待确认）、法人/主体负责人（当前：邴龙志·推断待确认）、站点研发（当前：宋祺睿·推断待确认）、App 上架产品经理（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 备案需求登记 → ② 查台账判断是否需新备案 → ③ 确定主体与负责人 → ④ 备齐材料包 → ⑤ 云厂商提交与管局审核 → ⑥ 公安联网备案与备案号展示 → ⑦ 登记台账 → ⑧ 核查响应与信息变更ICP 备案号、公安联网备案号、App 备案号；备案台账（域名/App、主体、负责人、联系人、状态）；备案材料包模板待优化240
LEG-24增值电信业务许可证办理与年报每年 1～3 月持证主体办理增值电信业务经营许可证年报（3 月 31 日截止），或业务需要新办、增项、续期、变更增值电信许可（ICP、EDI、国内互联网虚拟专用网 B13 等，如 LeapVPN 对外经营）时，完成证照核查、材料与方案准备、填报提交、跟进审查和归档主责——综合部证照资质管理（当前：赵雪冰·推断待确认）；协同——年报填报执行（当前：杨明学·推断待确认）、新办/增项证照申报岗（总经办，当前：田杰·推断待确认）、技术方案编写人（当前：吴世豪·推断待确认）、业务说明起草与技术审核 CTO（当前：丁震宇·推断待确认）、往年材料与经验提供（当前：常元和·推断待确认）、财务（上年财务报表，当前：待指定）、行政协助（当前：侯明月·推断待确认）；审定——CEO（当前：邴龙志·推断待确认）① 合规日历自动提醒 → ② 核对持证清单与系统账号 → ③ 收集财务、业务与网络安全材料 → ④ 填报 → ⑤ CTO 核对业务类别与数据、CEO 审定 → ⑥ 提交并留存回执 → ⑦ 新办/增项：确认许可类别、咨询材料清单、确认上游云服务商合规支持 → ⑧ 编写可研报告与技术、安全方案，核验各类负责人 → ⑨ 内部审批后提交并跟进审查 → ⑩ 领证、证照原件与材料归档按期提交的年报回执、网络与信息安全管理制度文件、业务说明；新办/增项的可行性研究报告、网络技术方案、安全保障方案与申报进度表；新办、增项或续期后的许可证（电子与纸质）、资质台账与年度材料包；产品“有证经营”上线确认待新建160
LEG-25算法备案、办学许可、3C 认证等专项资质办理产品上线前需做算法备案（或已提交的算法备案材料被打回需补正、备案信息需变更）、拟开展对外收费培训需判断是否申领办学许可、新机型或新供应商硬件出货（尤其渠道批量）需要 3C 证书时，先判断是否必须办理，再组织办理并维护资质台账主责——综合部负责人（资质合规统筹）（当前：赵雪冰·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总经办专员（当前：田杰·推断待确认）、IT 运维/采购资产（当前：杨明学·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、产品负责人（当前：杨萌·推断待确认）、交付工程师（当前：游家豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、算法备案材料负责人（当前：陈子康·推断待确认）、研发改造（当前：王皓南·推断待确认）；决策与兜底——CEO（当前：邴龙志·推断待确认）① 需求登记 → ② 是否需办理判定 → ③ 定主体与责任人 → ④ 准备材料 → ⑤ 内部审核对齐 → ⑥ 提交/送检跟进 → ⑦ 取证入台账 → ⑧ 到期与变更提醒取得的算法备案号/办学许可证/3C 证书；资质台账（含机型—证书对应表）；可对外提供的证书资料包待新建200
LEG-26境外主体设立与海外 AI 服务采购合规国内主体无法直接采购企业版海外 AI 服务，或需要境外账号、IP、支付方式，有人提出设立境外公司或用个人/境外账户、支付渠道付款时，先做合规评估，再决定是否设立境外主体及采用何种付款路径主责——COO/联合创始人（当前：常元和·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总助（当前：刘昱潇·推断待确认）、财务负责人（当前：待指定）、法务负责人（当前：李瑶·推断待确认）、需求方研发负责人（当前：王皓南、宋祺睿·推断待确认）、架构/风险评估（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交需求单 → ② 境内替代方案排查 → ③ 法务+财务合规会签 → ④ CEO 决策 → ⑤ 境外主体设立与开户 → ⑥ 以公司主体开通服务账号 → ⑦ 付款入账 → ⑧ 登记台账并年度维护境外采购合规评估单（结论与条件）；获批时设立的境外主体与银行/支付账户；企业版海外 AI 服务账号；境外主体与账号台账待新建100
LEG-27开源与保密规范制定、评审与发布公司首次出台或修订开源规范、保密规范（资产分级、个人开源项目、远程操作责任等）时，经多部门评审与法务确认后全员发布，并配套落地 SOP 与表单；是 LEG-28～LEG-31 的上位制度主责——创始人兼 CTO（规范起草与决策）（当前：丁震宇·推断待确认）；协同——研发评审人（当前：王皓南、宋祺睿、李子遥、陈晖、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、配套 SOP 搭建人（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项定范围 → ② 起草初稿 → ③ 法务预审 → ④ 多部门逐条评审 → ⑤ 改稿并关闭意见 → ⑥ 法务终审与 CEO 批准 → ⑦ HR 发布与签收 → ⑧ 配套 SOP 上线与年度复审正式生效的保密规范、开源工作管理规范、速查卡与入口页；评审意见清单（含处理结果）；配套 SOP、表单与审批流；全员签收记录待优化100
LEG-28开源组件引入与许可证合规评估在产品、Agent 容器或交付物中引入/集成/二开第三方开源组件，复制开源 UI 代码，把员工业余开源项目引入公司项目，或二开后改名换 Logo 对外分发时，先评估许可证义务并确定使用条件主责——研发技术负责人（当前：王皓南·推断待确认）；协同——引入方研发（申请人）、许可证初审人（当前：岳阳、柯逸飞·推断待确认）、开源负责人（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、品牌负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交开源组件引入申请 → ② CI 自动扫描许可证 → ③ 技术初审（使用方式与隔离） → ④ 法务判定 → ⑤ 定使用条件（署名、命名、隔离、开源义务） → ⑥ 登记台账并 fork 备份 → ⑦ 发版前复核第三方声明开源组件引入审批记录；开源组件台账；每个组件的使用条件（版权声明、about 页署名、对外命名、是否需公开源码）；发版包内的第三方声明文件待优化135
LEG-29员工开源账号备案与对外开源发布审批员工入职报备个人开源账号；员工或团队拟把公司代码、Skill、模板、模型对外开源、向上游贡献，或在 GitHub/HuggingFace 发布；公司孵化开源项目立项时，完成备案、分级审批、署名与发布主责——开源事务管理员（当前：陈晖·推断待确认）；协同——申请人（项目主要维护者）、分级复核人（非申请人的研发同事）、技术负责人/审批人（当前：丁震宇·推断待确认）、研发技术负责人（当前：王皓南、宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、开源负责人/公司开源组织管理员（当前：常元和·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 开源账号报备 → ② 提交开源申请表单 → ③ 分级复核 → ④ 按级别审批 → ⑤ 发布前检查（敏感信息、许可证、署名） → ⑥ 在公司组织下发布 → ⑦ 登记台账与激励 → ⑧ 立项后按月跟进开源账号报备表；开源申请审批记录；公司 GitHub/HuggingFace 组织下的公开仓库（含许可证、署名、维护者）；开源项目台账待优化144
LEG-30对外提供材料与代码权限的保密审查需要把含真实客户信息的材料（可研报告、方案、数据样例）发给外部人员，对外披露渠道/供应商/灰度产品信息，或合作方索取代码库/源码时，先做保密审查，决定脱敏、签 NDA、限定授权方式或拒绝主责——法务负责人（当前：李瑶·推断待确认）；协同——发起人所在产品/研发负责人（当前：杨萌、王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起外发申请 → ② 密级与敏感信息判定 → ③ 选择提供方式 → ④ 签署 NDA → ⑤ 审批 → ⑥ 受控交付 → ⑦ 登记并到期回收对外资料/源码授权审批记录；已签 NDA；脱敏材料或限时只读代码权限；外发台账待新建100
LEG-31代码与机密资产外泄管控及事件处置获得或形成高价值代码、Skill、提示词等机密资产需要控制流转范围，或发现员工把公司代码/资产放到个人公开仓库、外部平台时，执行登记管控与泄露事件处置主责——创始人兼 CTO（机密资产管控负责人）（当前：丁震宇·推断待确认）；协同——资产所属业务线技术负责人（当前：王皓南·推断待确认）、资产登记员（当前：王满·推断待确认）、清洗改写研发（当前：陈锦杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 资产定级登记 → ② 权限化分发与拷贝登记 → ③ 清洗确认后方可扩散 → ④ 定期扫描公开仓库 → ⑤ 发现泄露立即止损 → ⑥ 取证与影响评估 → ⑦ 按规范定性处理 → ⑧ 复盘整改机密资产登记表（含拷贝持有人）；泄露事件处置记录（止损、证据、影响、处理结论）；整改项清单待新建160
LEG-32诉讼、仲裁与法律纠纷应对公司收到律师函、起诉状、仲裁申请、法院传票，或需要对客户欠款、供应商违约、侵权方等发起法律主张时启动主责——法务专员（当前：待指定）；协同——涉事业务部门负责人（当前：待指定）、财务（当前：待指定）、外部律师（如有）；兜底——法务负责人（当前：李瑶·部门报送人）① 文书接收与期限登记 → ② 事实与证据收集 → ③ 风险评估与策略 → ④ 管理层决策 → ⑤ 协商/发函/应诉/起诉 → ⑥ 执行与回款 → ⑦ 结案复盘纠纷台账、证据目录、处理策略与决策记录、和解协议或裁判文书及执行结果待新建100
LEG-33监管问询、执法调证与约谈应对网信、公安、通信管理、市场监管等部门对公司产品或用户数据发出问询、调取证据、协助调查、约谈或整改通知时启动主责——法务专员（当前：待指定）；协同——研发/运维负责人（当前：待指定）、产品负责人（当前：待指定）、政策申报对接人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 接收与身份核验 → ② 登记期限 → ③ 法律评估调取范围 → ④ 审批 → ⑤ 最小范围提供数据或材料 → ⑥ 整改落实 → ⑦ 归档与复盘经核验的执法文书登记、数据提供记录、整改报告、约谈纪要待新建80
LEG-34个人信息权利请求与数据安全事件合规处置用户请求查询、复制、更正、删除个人信息或注销账号，或发生用户个人信息、客户数据泄露、篡改、丢失等数据安全事件需要法律评估、告知与报告时启动主责——法务专员（当前：待指定）；协同——客服/运营（当前：待指定）、研发/运维负责人（当前：待指定）、安全负责人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 受理与身份核验 → ② 分类（权利请求/安全事件）→ ③ 影响评估 → ④ 执行请求或止损 → ⑤ 告知个人/客户 → ⑥ 必要时向监管报告 → ⑦ 留痕归档权利请求处理记录、数据安全事件评估报告、告知与报告留档待新建120
LEG-35合同履约节点与到期续约管理已签署的销售、采购、服务、合作合同中存在验收期、质保期、付款节点、自动续约、到期终止通知期等关键节点，需要提前提醒和决策时适用主责——合同管理员（当前：待指定）；协同——合同经办人（当前：待指定）、财务（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 签约时提取关键节点 → ② 录入台账 → ③ 节点前自动提醒 → ④ 经办人确认履约状态 → ⑤ 续约/终止/变更决策 → ⑥ 发函或签署补充协议 → ⑦ 台账更新带关键节点的合同台账、续约或终止决定、相关函件与补充协议待新建96

HR 人事 报送人：黄莹

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
HR-01人事制度编制、意见征集与发布宣贯公司需要新出台或修订人事类制度（员工手册、考勤、休假、年假、加班、实习/试用期规范、放假与福利通知等）时启动，覆盖起草、评审、意见征集、定稿发布、宣贯答疑全过程。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、法务（当前：待指定）、各部门负责人及部门意见汇总人；终审——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定框架 → ② 起草初稿 → ③ 管理层/法务批注 → ④ 部门负责人评审 → ⑤ 全员解读与归口征集 → ⑥ 定稿终审 → ⑦ 发布并配置飞书规则 → ⑧ 宣贯答疑与归档经终审、带版本号和生效日的正式制度文档；全员发布通知；已配置的飞书假勤/审批规则；意见处理表；宣贯签到记录与 FAQ。待优化300
HR-02组织架构调整与飞书架构/审批人维护部门新设、更名、合并、负责人调整，或飞书审批上线/改版需要明确直属上级与审批人时启动，确保组织架构表、飞书通讯录、审批流三者一致。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、财务（当前：陈雅萍、黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、各部门负责人；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 调整决策 → ② 更新组织架构表 → ③ 发布调整通知 → ④ 部门负责人逐一沟通 → ⑤ 飞书通讯录与直属上级同步 → ⑥ 审批流审批人复核 → ⑦ 全员反馈确认 → ⑧ 关联方同步与归档最新版组织架构表（含岗位、直属上级、部门负责人、人员类型）；已同步的飞书通讯录与审批人配置；调整通知与反馈表汇总。待优化72
HR-03HC申请与人力成本统计部门需要新增人员编制（HC），或管理层索要人员清单、岗位清单、人力成本数据时启动，按统一模板测算、审批并输出花名册与成本表。主责——人事负责人（当前：黄莹·推断待确认）；协同——申请部门负责人（当前：杨萌、徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 部门提出 HC 需求 → ② 按模板测算预算与 ROI → ③ HR 核对人力成本基数 → ④ CEO 审批 → ⑤ 获批转招聘 → ⑥ 花名册/成本表月度更新 → ⑦ 按需出数据报表已审批的 HC 申请单；实时更新的员工花名册与月度人力成本表；按需输出的人员/岗位/成本报表。待新建81
HR-04用工主体判定与劳动合同/协议签署新员工入职、补签、转正改签或出现特殊用工（在读学生、未成年人、远程试用、另有劳动关系、多公司法人入职、对外任职）时启动，确定劳动关系主体与用工类型，签署劳动合同/实习/劳务协议及保密、竞业、对外任职承诺。主责——人事负责人（当前：黄莹·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、行政（用印）（当前：侯明月·推断待确认）、用人部门负责人（当前：徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 收集用工信息 → ② 判定用工类型 → ③ 判定合同主体 → ④ 特殊情形法务咨询 → ⑤ 拟定合同并群内审核 → ⑥ 用章审批 → ⑦ 入职当日签署 → ⑧ 归档与主数据登记主体与类型正确、双方签署并盖章的劳动合同/实习协议/劳务协议，配套保密、竞业、知识产权、对外任职承诺；员工主数据中的主体、合同类型、期限、到期日。待新建180
HR-05新员工入职准备与办理候选人确认到岗日后启动，由 HR 发出入职通知单，统一协调工位、电脑、飞书账号/组织层级/席位、邮箱、代码仓库与终端软件、门禁工牌、拉群、福利告知，直至到岗当天接待完成。主责——人事负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、行政（当前：胡则瑾、侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、用人部门负责人；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 用人部门提交入职通知单 → ② HR 发候选人入职通知 → ③ 采集入职信息并核对证件 → ④ 设备采购/调配 → ⑤ 工位、门禁、名片 → ⑥ 飞书席位与组织归位 → ⑦ 账号与权限开通 → ⑧ 到岗接待与介绍 → ⑨ 清单核验入职清单全部勾完：合同已签、工位与设备到位、飞书账号在正确部门与直属上级下、邮箱/代码仓库/终端软件/产品账号已开通、已拉入对应群、导师已指定、新人已在部门群介绍。待优化225
HR-06新人入职培训、带教与首周上手新员工或实习生到岗后启动，完成通用入职培训（价值观、架构、制度、作息）、指定导师、发放岗位学习资料与环境指引、安排首周任务并明确权限边界，直到 30 天回顾。主责——人事负责人（当前：黄莹·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、用人部门负责人（当前：杨萌、王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认）、导师（当前：岳阳、宋祺睿、陈晖·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 到岗前指定导师与首周任务 → ② 发放入职资料包 → ③ 首日作息与制度告知 → ④ 岗位环境与规范上手 → ⑤ 首周任务与每日跟进 → ⑥ 集中入职培训 → ⑦ 首周与 30 天回顾新人入职交接卡（导师、首周任务、权限边界）；首周任务完成记录；集中入职培训签到；30 天回顾记录（作为转正评估输入）。待新建108
HR-07实习生用工管理录用和管理在校/应届实习生时启动，涵盖协议类型、观察期、出勤确认与按天结算、导师与归属调整、学校材料（三方协议、实习证明、日志）配合，直至转正或离职。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、导师/直属上级（当前：李子遥·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 核验在校身份 → ② 签实习协议并定档 → ③ 指定导师与出勤方式 → ④ 每日出勤记录 → ⑤ 月末导师确认出勤 → ⑥ HR 核算、财务发放 → ⑦ 学校材料办理 → ⑧ 观察期满转正/转岗/离职签署的实习协议；实习生台账（身份、档位、导师、观察期、出勤方式）；导师确认的月度出勤表；按时足额发放的实习薪酬；学校所需证明材料。待新建144
HR-08试用期/实习观察期考核与转正新员工入职（试用期 3 个月）或实习生入职（观察期 2 个月）后启动：入职即定考核指标，期间设检查点，期满前 HR 发起评估，由直属上级给结论、决策人定转正薪资，完成转正、延长或不通过处理。主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/评估人（当前：杨萌、王皓南、张东郅、王子明·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；转正定薪——CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职定考核指标 → ② 2 周/1 个月检查点 → ③ HR 月度到期名单 → ④ 员工交转正报告 → ⑤ 直属上级评估 → ⑥ 定薪定级 → ⑦ 三方面谈与书面通知 → ⑧ 签约变更与归档每人一份考核指标；转正报告与评估表；转正/延长/不通过结论与书面通知；转正薪资确认；花名册与合同同步更新。待优化108
HR-09薪酬定级与调薪制定或调整薪酬带宽与实习生统一档位；员工转正定级、表现突出或到季度调薪时点需要调薪；管理层口头决定调薪或补贴变更、需要 HR 落地时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——创始人兼 CTO（研发岗评估，当前：丁震宇·推断待确认）、产品/业务负责人（当前：杨萌·推断待确认）、技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 维护薪酬带宽与实习档位 → ② 直属负责人提交定级/调薪申请 → ③ CTO/业务负责人评估 → ④ CEO 审批 → ⑤ 写明生效月与实发月 → ⑥ 告知员工 → ⑦ 写入异动表推送财务 → ⑧ 首个实发月核对并归档审批通过的定级/调薪单（级别或区间、生效月、实发月、理由）、更新后的人员异动表与工资表、员工告知记录、现行薪酬带宽与实习档位表待新建180
HR-10日常考勤打卡、补卡与到岗规范员工日常上下班打卡与到岗；飞书打卡失败、漏打卡需要补卡；超过最晚到岗时间未到且未报备需要提醒或按规扣罚；团队进入或结束冲刺期需要调整到岗规则时主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、站会组织人（当前：李铭熙、宋祺睿·推断待确认）、规则拍板人创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 发布公司考勤规则与组内弹性约定 → ② 配置飞书考勤 → ③ 员工每日打卡 → ④ 异常自动提醒本人 → ⑤ 员工提补卡 → ⑥ 直属上级审批 → ⑦ 到岗异常提醒与警告 → ⑧ 扣罚进入月度核对一页纸《考勤打卡与补卡指引》、飞书考勤规则配置、每日异常提醒与补卡审批记录、到岗警告记录待优化90
HR-11请假、居家/远程办公与外勤报备员工需要请事假/病假/年假/调休，或申请居家/远程办公、外勤、外出办事与外出培训时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/团队负责人（当前：杨萌、王皓南·推断待确认）、研发线审批人创始人兼 CTO（当前：丁震宇·推断待确认）、非研发审批人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 员工事前提交对应假勤审批 → ② 直属上级审批（按部门自动路由） → ③ 审批通过自动通知团队群与项目负责人 → ④ 交接与紧急联系 → ⑤ 居家期间站会与日报 → ⑥ 变更在审批内撤回/修改 → ⑦ 额度与余额维护 → ⑧ 数据进入月度考勤核对审批通过的请假/居家/外勤单、团队群同步通知、交接记录、居家日报、员工可自查的年假与调休余额待优化60
HR-12加班申请、工时登记与调休/加班费结算项目赶工、上线、大会、客户线下加急需要晚间/周末/法定节假日加班，或公司宣布紧急赶工期时，从事前申请到事后折算调休、加班费、补贴或积分全程适用主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、研发加班审批人创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 制度成文并经法务审定 → ② 事前提交加班申请或名单 → ③ 直属上级审批 → ④ 加班打卡 → ⑤ 事后提交工时与成果 → ⑥ 上级确认工时 → ⑦ HR 月度汇总 → ⑧ 折算调休/加班费/积分 → ⑨ 落账并告知经法务审定的《加班管理制度》、审批通过的加班单与名单、确认后的加班工时明细、月度加班结算清单、员工可查的调休余额与工资条加班项待新建320
HR-13节假日放假调休与值守安排通知春节、五一、中秋国庆等法定节假日或公司统一调休日前，需要确定放假/补班/调休/居家办公方案、收集各项目组值守与 oncall，并向全员发正式通知时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（方案决策，当前：邴龙志·推断待确认）、创始人兼 CTO（研发侧方向与值守，当前：丁震宇·推断待确认）、各项目组负责人（当前：杨萌、陈梦琪、徐莉、王皓南·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 年初发布全年放假日历 → ② 长假前发起方案收集 → ③ 各项目组上报居家/到岗/值守 → ④ CEO 拍板 → ⑤ HR 发正式通知并要求已读 → ⑥ 飞书假勤配置补班与调休扣减 → ⑦ 节中值守 → ⑧ 节后考勤与加班处理年度放假与调休日历；节前正式通知（放假与补班、公司调休日抵扣规则、居家安排与工作时间、值守/oncall 表、节日福利、加班结算口径）；节后调休扣减记录待优化90
HR-14月度考勤核对与请假扣薪核定每月初核对上月出勤，通知员工补卡补请假，由直属上级确认缺卡、事假、病假、迟到是否扣薪，输出考勤结果供工资核算时启动；考勤试运行期按周执行主责——人事负责人（当前：黄莹·推断待确认）；协同——各直属上级/组长（当前：杨萌、王皓南·推断待确认）、扣薪审核人创始人兼 CTO（当前：丁震宇·推断待确认）、口径决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 每周推送异常给上级 → ② 月初导出上月考勤并比对审批 → ③ 推送个人异常与补卡截止 → ④ 员工补卡/补请假 → ⑤ 直属上级确认扣薪意见 → ⑥ HR 按制度核定 → ⑦ 审核 → ⑧ 锁定考勤结果提交工资核算月度考勤结果表（每人应出勤、实出勤、缺卡、事假、病假、迟到、旷工、扣薪天数）、直属上级确认记录、补卡截止通知、扣薪说明待优化180
HR-15月度工资核算发放与员工个税答疑每月发薪周期内，人事确定薪资明细后由财务测算个税，经管理层审核审批后发放并推送工资条；处理错发、金额异常、个税申报异常与员工退补税咨询主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（薪资明细与工资条，当前：黄莹·推断待确认）、CEO（审核审批，当前：邴龙志·推断待确认）、COO（审核，当前：常元和·推断待确认）、创始人兼 CTO（审核，当前：丁震宇·推断待确认）、跃竞负责人（跃竞薪酬核对，当前：徐莉·推断待确认）；兜底——综合部负责人① 1 日收集异动 → ② 3 日薪资表定稿 → ③ 管理层审核 → ④ 5 日前测税反写 → ⑤ 付款审批 → ⑥ 8 日双人复核发放 → ⑦ 推送工资条确认 → ⑧ 个税申报与答疑经审核的分主体工资表、付款回单、员工已确认的飞书工资条、个税申报回执、异常处理记录待优化180
HR-16社保公积金缴纳与增减员员工入职、离职、在模态/鼎慧/苏州/跃竞等主体间变更劳动关系，或缴费基数调整、员工咨询缴纳情况、税务系统发出社保与个税口径差异预警时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——社保办理人（当前：侯明月·推断待确认，拟交接至人事）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（口径，当前：丁震宇·推断待确认）、COO（主体规划，当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 入离职/主体变更自动进入当月增减员清单 → ② 20 日前核对主体、基数、比例 → ③ 25 日前办理增减员与申报 → ④ 财务付款 → ⑤ 扣款对账 → ⑥ 更新员工缴纳台账 → ⑦ 每季度盘点应缴未缴 → ⑧ 税务预警处置月度增减员清单与办理回执、社保公积金明细表、员工缴纳台账（主体、基数、比例、起缴/停缴月）、付款记录、季度盘点报告、预警处置记录待优化180
HR-17AI工具补贴发放与调整每月为员工发放 AI 工具补贴，以及新入职、实习、岗位变化、警告取消、离职、超额申请、规则调整等需要核定或变更补贴档位时启动主责——人事专员（当前：黄莹·推断待确认）；协同——财务专员（当前：黄梦婷·推断待确认）、IT 核定人（当前：杨明学·推断待确认）、补贴制度制定人（当前：丁震宇·推断待确认）、法务（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）；档位例外审批——CEO（当前：邴龙志·推断待确认）① 月初更新名单与档位 → ② 例外调档审批 → ③ 出补贴发放表 → ④ 财务 15 日打款 → ⑤ 发放通知与 FAQ → ⑥ 月底员工提交支出凭证 → ⑦ IT 核定达标并记录暂停/恢复 → ⑧ 超额部分走报销当月按时到账的 AI 补贴；与工资分开的《AI 补贴发放表》；《AI 补贴名单与核定台账》（含档位、达标结果、暂停/恢复月份）；单一版本的补贴规则 wiki + FAQ待优化144
HR-18积分激励制度运行积分激励、期权激励、知识产权激励等制度发布后，需要宣贯答疑、编制积分预算、组织申报、核验公示、登记台账、兑换发放时启动主责——积分运营组牵头人（总经办，当前：赵雪冰·推断待确认）；协同——人事负责人（当前：黄莹·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）、积分系统负责人（当前：丁震宇·推断待确认）、各一级部门负责人；决策——积分管理委员会（董事会成员 + 一级部门负责人，召集人当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 制度发布与宣贯（写明适用范围）→ ② 季度积分预算 → ③ 个人/部门申报 → ④ 运营组初核 → ⑤ 委员会审议 → ⑥ 公示与异议复核 → ⑦ 登记台账 → ⑧ 兑换发放带适用范围和 FAQ 的制度宣贯包；季度积分预算；经委员会决议并公示的积分结果；积分台账（个人、部门、来源、余额）；与财务对接的兑换/发放清单待新建225
HR-19研发绩效评价与质量奖惩每个迭代结束或每月初，需要统计研发/测试工作量（故事点、任务点数）、评级，统计线上 Bug 并认定责任，据此确定奖金、扣款、积分或 AI 补贴调整时启动主责——研发团队负责人（Leap 线当前：王皓南·推断待确认；跃竞线当前：徐莉·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、绩效汇总人（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 迭代前公示参与人与点数 → ② 迭代后统计工作量 → ③ 上线后 Bug 定级归因 → ④ 公示责任比例 → ⑤ 申诉与终裁 → ⑥ 月度评级汇总 → ⑦ 人事合规复核 → ⑧ 结果应用与结算每迭代工作量统计表；每次发布的 Bug 定级与责任认定公示；月度研发/测试绩效总表（评级 + 主观评分）；经人事复核的奖惩结算清单（交财务随工资结算）待优化180
HR-20员工绩效/行为问题访谈与处置员工出现产出持续不足、交付质量问题影响他人、多次迟到、失联、不配合或态度问题，需要访谈调查、书面警告、改进期、调岗/降薪转岗或终止时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——直属负责人（当前：各团队负责人，如王皓南、杨萌·推断待确认）、带教人（实习生，当前：待指定）、法务负责人（当前：李瑶·部门报送人）；处置决策——研发负责人/CEO（当前：丁震宇、邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 记录事实 → ② 直属负责人首次沟通 → ③ 人事访谈调查 → ④ 分级判定 → ⑤ 处置决策 → ⑥ 书面告知与签收 → ⑦ 改进期跟踪 → ⑧ 结论归档（终止则转离职交接）问题事实记录；访谈纪要（权限受限）；处置决定（警告函/改进计划/调岗通知/终止通知）及本人签收；改进期复盘结论；人事档案归档待新建180
HR-21年度/阶段总结收集与1v1面谈年终或阶段节点（季度、集中加班后），需要下发总结通知与模板、按名册收集、组织互读评论、安排管理者与员工 1v1 面谈并沉淀结论时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——年度通知发起人与访谈人（CEO，当前：邴龙志·推断待确认）、技术部总结组织人（当前：丁震宇·推断待确认）、产研阶段总结组织人（当前：杨萌·推断待确认）、各模块负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 拟通知、模板与名册 → ② 管理层审阅 → ③ 按名册发布并建待办 → ④ 提交并回填汇总表 → ⑤ 自动催交 → ⑥ 互读评论与批注 → ⑦ 1v1 预约与面谈 → ⑧ 纪要归档与结果应用全员总结提交汇总表（100% 覆盖名册）；管理者批注与互评记录；1v1 排期表与面谈纪要（权限受限）；用于绩效、调薪参考的结论清单待优化72
HR-22员工福利：体检与商业保险公司开通或年度发放体检、团体商业保险、中医问诊等福利，需要方案选型、对接机构、发卡、组织预约、收集体检报告、更新参保名单、解答理赔问题时启动主责——福利统筹（行政，当前：侯明月·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、财务（当前：待指定）、各组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 年度方案对比 → ② CEO 选定 → ③ 付款开通 → ④ 发卡与参保名单 → ⑤ 发布使用指引与 FAQ → ⑥ 统一/自行预约 → ⑦ 体检报告收集（限授权查看）→ ⑧ 理赔答疑与季度名单更新年度福利方案与对比文档；体检卡发放台账；团险参保名单（按季度更新）；《体检与保险使用指引 + 理赔 FAQ》；体检报告提交记录（仅授权人员可见）待优化96
HR-23内部培训与分享会组织有内部培训或分享需求（价值观、AI 工具、FDE、信创、专利、LeapCore/LeapAll、周五分享、销售演示等），需要选题排期、报名或参训确认、场地与线上会议、通知、录屏、资料归档和反馈收集时启动主责——内部培训统筹人（学习委员，当前：杨萌·推断待确认）；协同——总经办培训专员（当前：王欣·推断待确认）、综合部负责人（参训确认，当前：赵雪冰·推断待确认）、行政（场地，当前：胡则瑾·推断待确认）、课程体系负责人（当前：李凯·推断待确认）、FDE 培训组织人（当前：陈梦琪·推断待确认）、讲师（当前：王皓南、马漳毓、陈子康等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 提交分享/培训申请 → ② 统筹人确认选题与排期 → ③ 讲师备课（大纲、软件清单、海报必填项）→ ④ 发通知与报名/参训确认 → ⑤ 订场地并建飞书会议（默认录制）→ ⑥ 实施与签到 → ⑦ 1 个工作日内归档妙记与课件 → ⑧ 反馈汇总进入选题池培训日历上的场次；报名/参训确认记录；签到记录；录屏、妙记、课件归档在知识库“内部课程”目录；反馈汇总与下期选题待优化120
HR-24员工活动：年会、团建与委员/兴趣小组组织年度全员大会、户外团建、联合团建、节日或非工作活动，以及学习/卫生/文体委员和兴趣小组开展活动、申请经费时启动主责——活动后勤负责人（行政，当前：侯明月·推断待确认）；协同——人事负责人（请假与人员名单，当前：黄莹·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、卫生委员（当前：侯明月、赵雪冰·推断待确认）、学习委员（当前：杨萌·推断待确认）、各项目组小组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 年度活动日历 → ② 活动立项与预算 → ③ 时间投票（选项完整）→ ④ 提前 7 天发正式通知 → ⑤ 报名/请假/饮食一表收集 → ⑥ 后勤落实 → ⑦ 前一天提醒、当天签到 → ⑧ 复盘归档与费用报销年度活动日历；活动方案与预算审批；正式通知（时间、地点、路线、环节、请假方式）；报名与签到记录；活动复盘与费用凭证；委员活动记录（用于积分）待优化108
HR-25人员调岗、借调与汇报线确认员工要从一个组/业务线长期调到另一个组，或被临时借调（含按比例投入，如 0.5 人力），或实习生被其他组拉去干活，或组织调整后直属上级变化时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——调出方负责人、调入/借调方负责人（当前：按个案指定）、资源裁定人：创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 调入方提需求 → ② 先与调出方负责人对齐 → ③ 有冲突时资源裁定 → ④ 提交调岗/借调审批 → ⑤ 明确汇报线、派活人、绩效归属与期限 → ⑥ 工作交接与权限调整 → ⑦ HR 更新飞书架构并通知 → ⑧ 借调到期归还或续期已审批的调岗/借调单（含汇报线、派活人、绩效归属、期限、投入比例）、接手人签收的交接清单、更新后的飞书组织架构与人员异动记录、原组和新组群内通知待新建108
HR-26人事异动同步通知入职、转正、调岗/借调、调薪、离职任一人事异动确定（审批通过或生效日确定）后，把信息同步给 CEO、财务、行政、IT、直属上级和相关群主责——人事负责人（当前：黄莹·推断待确认）；协同——财务（当前：祁航·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人① 异动审批通过 → ② 人事当天登记 → ③ 机器人按类型推送 CEO/财务/行政/IT/直属上级 → ④ 各方 1 个工作日内回执 → ⑤ 人事群同步、有无特殊处理 → ⑥ 先通知再改飞书架构 → ⑦ 月度异动表审核后交财务每条异动都有登记和各接收方回执；月度人员异动表审核通过并作为工资核算依据；飞书组织架构与实际一致待新建120
HR-27员工离职办理与交接正式员工、实习生、兼职或顾问提出离职、被劝退、合作到期终止，或发现未办手续离岗时启动；长假前、业务系统移交、换账号时参照其中交接与数据转移步骤主责——人事负责人（当前：黄莹·推断待确认）；协同——离职人直属上级（当前：按个案）、财务负责人（当前：黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CEO（当前：邴龙志·推断待确认，审定离职文件、决定竞业）；兜底——综合部负责人① 飞书提交离职申请 → ② 直属上级审批、定 last day 与接手人 → ③ 写交接文档、接手人确认 → ④ 财务核查未完结事项 → ⑤ 离职文件拟定审定 → ⑥ last day 回收资产、停账号、退群 → ⑦ 清理席位、结算最后工资 → ⑧ 归档审批通过的离职单、接手人签收的交接文档、财务/行政/IT 回执、《离职声明》《员工离职单》《离职证明》、最后工资结算记录待优化225
HR-28人事档案管理与信息权限分级新员工入职建档、全员档案补齐或盘点、档案保管人变更、新岗位（行政助理、会计、总助等）进群或需要查看人事表单、对外提供劳动合同等材料时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——行政（当前：侯明月·推断待确认）、分级标准审定：CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 制定分级标准并由创始人评审 → ② 入职 3 个工作日内建档校验 → ③ 纸质入带锁档案柜、电子入台账 → ④ 按级配置表单与文档权限 → ⑤ 权限变更先通知后执行 → ⑥ 季度盘点与权限审计 → ⑦ 调阅与对外提供登记员工档案/合同台账（多维表格，标出缺项）、《人事信息分级与可见范围表》、上锁档案柜及目录索引、季度盘点与权限审计记录、调阅登记待新建120
HR-29员工申诉与劳动争议处理员工对考勤扣薪、绩效、调岗、解除、加班费等提出异议或投诉，或收到劳动监察投诉、劳动仲裁申请时启动主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 受理登记 → ② 事实核查与证据固定 → ③ 法务风险评估 → ④ 内部沟通调解 → ⑤ 形成处理决定并书面告知 → ⑥ 仲裁/诉讼应对（如进入）→ ⑦ 结案归档与制度改进书面处理结论或调解协议；进入仲裁的，完整证据目录与答辩材料；争议台账一条待新建100
HR-30工伤与员工意外事件处理员工在工作时间、工作场所或因公外出（含出差、上门交付、展会搭建）期间受伤或突发疾病时启动主责——人事专员（当前：待指定）；协同——行政（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 现场救助与报告 → ② 事故信息登记 → ③ 判断是否申请工伤认定 → ④ 法定期限内提交申请 → ⑤ 商保理赔协同 → ⑥ 停工留薪与复岗安排 → ⑦ 隐患整改与归档事故报告、工伤认定申请回执或不申请的书面说明、复岗记录、隐患整改记录待新建60
HR-31劳动合同到期续签与终止员工劳动合同、实习协议或劳务协议即将到期，需要决定续签、变更或终止时启动主责——人事专员（当前：待指定）；协同——员工所在部门负责人（当前：待指定）、法务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 到期前提醒 → ② 部门续签意见 → ③ 审批决定 → ④ 与员工沟通 → ⑤ 签署续签合同或出具终止通知 → ⑥ 异动同步 → ⑦ 归档续签的劳动合同或书面终止通知；合同到期台账更新待新建32
HR-32非研发岗位周期绩效考核与结果应用每季度（或半年）对综合、市场、生态、运营等非研发岗位开展绩效考核，并将结果用于调薪、奖金、晋升与改进时启动主责——人事专员（当前：待指定）；协同——各部门负责人（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 期初目标设定 → ② 期中跟进 → ③ 期末自评 → ④ 上级评价与校准 → ⑤ 结果面谈 → ⑥ 结果应用（调薪/奖金/改进计划）→ ⑦ 归档每位员工的考核表与等级、校准后的部门结果汇总、结果应用清单待新建72
HR-33竞业限制启动、豁免与补偿支付已签竞业限制协议的员工离职时，决定是否启动竞业限制、如何支付补偿、离职后如何跟踪履约时启动主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、原部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 离职时识别竞业协议 → ② 评估是否启动 → ③ 书面通知员工 → ④ 按月支付补偿 → ⑤ 定期确认履约 → ⑥ 违约处置或期满结束竞业启动/不启动书面通知、补偿支付记录、履约确认记录待新建45

X-CS 售后 / 客户成功 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-CS-01售后服务体系、分工与值班排班产品交付或上线后，需要明确谁对客户负责、谁值班首响、谁兜底研发问题，以及制定和发布日常/节假日值班排班时启动主责——售后统筹（产品负责人兼）（当前：杨萌·推断待确认）；协同——研发负责人（排研发 oncall，当前：王皓南·推断待确认）、产品值班（当前：陈震、黄飞鹏·推断待确认）、研发 oncall（当前：宋祺睿、吴世豪等·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 定售后分工与 SLA → ② 出月度产品/研发值班表 → ③ 发布并告知销售与客户 → ④ 机器人每日提醒当日值班 → ⑤ 值班首响与分流（转 X-CS-05） → ⑥ 节假日排班提前发布 → ⑦ 月度复盘修订成文的《售后服务制度》（分工、呼叫规则、SLA、升级路径）、飞书多维表格值班表（含节假日）、每日值班提醒、售后月报待优化240
X-CS-02客户试用/正式账号开通、封停溯源与席位扩容潜在客户申请试用账号或加额度、需为客户在正式环境开号、发现来源不明的客户账号需溯源或封停、已交付客户申请增加席位时启动主责——客户账号管理员（后端/运维）（当前：宋祺睿·推断待确认）；协同——申请人（销售/产品，当前：杜中瑞、杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（特批，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 提交开通/扩容/封停申请 → ② 审核客户来源与资源 → ③ 执行开通或调整 → ④ 登记台账 → ⑤ 通知申请人与客户 → ⑥ 月度对账与到期提醒 → ⑦ 异常账号溯源封停生效的账号/席位，并在客户账号台账中留痕（客户、来源、开通人、额度、席位、并发上限、到期日）待新建144
X-CS-03客户额度充值到账、分配与补发客户购买额度需要到账、新用户默认额度发错需补发、客户反馈"额度已耗尽"或统计不符、为挽留/推广/项目交付赠送额度时启动主责——额度操作员（NewAPI/后端）（当前：宋祺睿·推断待确认）；协同——销售总监/客户经理（当前：吴琪·推断待确认）、业务对接（当前：王满·推断待确认）、充值发起人（当前：王皓南·推断待确认）、操作备岗（当前：张康·推断待确认）、后端研发（当前：杨云峰、陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交充值/补发/赠送/扣减申请 → ② 财务确认到账或审批赠送 → ③ 确认产品线与单位口径 → ④ 在 NewAPI/后台执行并截图 → ⑤ 校验 token 启用与分配 → ⑥ 登记台账 → ⑦ 通知客户并确认 → ⑧ 月度对账额度准确到账并按组织/个人分配，台账留痕（来源、口径、审批、执行截图、客户确认）待新建180
X-CS-04客户私有化实例登记与在线监控告警客户（含渠道代发）LeapCore 实例首次注册上线、渠道把机器分给终端客户、实例需改名，以及实例掉线或服务异常需要主动告警时启动主责——交付部署工程师（当前：游家豪·推断待确认）；协同——后端研发（cloud 改名与监控，当前：宋祺睿·推断待确认）、研发负责人（命名规则，当前：王皓南·推断待确认）、产品负责人（渠道系统对接，当前：杨萌·推断待确认）、研发排查（当前：吴世豪、杨云峰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发货/部署前分配实例名 → ② cloud 注册并填客户/渠道字段 → ③ 写入实例台账 → ④ 渠道分机后回填终端客户 → ⑤ 监控在线与服务状态 → ⑥ 异常告警并主动联系客户 → ⑦ 月度核对台账每台客户实例在台账和 cloud 中都能查到客户、渠道、编号、版本、联系人；掉线/服务异常 10 分钟内推送飞书告警待新建144
X-CS-05客户问题受理、分流与工单流转客户、内测/种子用户、销售或内部使用者通过反馈群、客户群、产品内"报告问题"或右下角反馈提出问题，需要首响、补全信息、分类、转工单并回告客户时启动主责——当日产品值班（当前：陈震、黄飞鹏·推断待确认）；协同——售后统筹（当前：杨萌·推断待确认）、研发 oncall/一线技术答疑（当前：岳阳、宋祺睿、杨云峰·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、客户对接（当前：吴琪、王满、闫登辉、杨朋伟·推断待确认）、Badcase 收集（当前：黄霆瑄·推断待确认）、FAQ 维护（当前：许君、韩诗琪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一入口收单 → ② 1 小时内首响 → ③ 按模板补全信息 → ④ 分级分类 → ⑤ 咨询类按 FAQ 答复，Bug 转研发工单 → ⑥ 跟进修复与发版 → ⑦ 回告客户并确认 → ⑧ 关单与 FAQ 沉淀每个客户问题都有工单编号、分级、分类、负责人、状态和对客回复；同类问题沉淀为 FAQ待优化400
X-CS-06客户现场问题分级排查与日志/诊断包收集一线无法判断的客户故障（死机、模型无响应、Agent 中断、容器创建失败、断电后异常、VPN/网络异常、定时任务异常），需要按顺序收集日志/诊断包、远程排查、定位根因并修复（含批量修复）时启动主责——当日研发 oncall（当前：吴世豪、杨云峰、岳阳·推断待确认）；协同——产品值班/对客转接（当前：黄飞鹏、陈震·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、服务端与发版（当前：宋祺睿·推断待确认）、NewAPI 查询（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、远程访问与日志归集（当前：郭逸非·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 一线按排查顺序自查 → ② 导出客户端诊断包 → ③ 研发初判 → ④ 必要时取服务端日志或远程上机 → ⑤ 给止血方案 → ⑥ 出书面结论与影响面 → ⑦ 修复或批量修复 → ⑧ 回访并关单每个现场故障有书面结论（现象-根因-验证-修复-影响面），附诊断包和工单号；批量问题有经评审的修复脚本和受影响客户清单待优化320
X-CS-07客户端安装、更新与模型服务连接问题一线支持客户安装/更新失败、被安全软件拦截、签名校验失败、系统不兼容、连错服务器、网页提示模型服务不可用时，由一线按手册远程指导解决，解决不了再升级主责——一线售后支持（当前：韩诗琪·推断待确认）；协同——客户端研发（当前：岳阳、葛家和·推断待确认）、服务端/运维（当前：宋祺睿·推断待确认）、IT 网络（当前：杨明学·推断待确认）、产品值班（当前：张东郅·推断待确认）；兜底——售后统筹（当前：杨萌·推断待确认）① 核对系统要求与版本 → ② 按排障手册判类（安装/更新/连接/模型服务） → ③ 远程指导客户可操作的步骤 → ④ 收集截图、时间、版本、环境 → ⑤ 升级研发/运维 → ⑥ 回复客户并补充 FAQ客户恢复使用；或 1 小时内带完整信息升级；《系统要求+安装排障》手册和话术库持续更新待优化72
X-CS-08账号登录失败与密码找回用户或企业管理员登录失败、忘记密码、重置短信收不到、报错提示模糊、客户实际连到错误实例，需要核验身份后重置或纠正连接地址时启动主责——账号密码重置管理员（后端）（当前：宋祺睿·推断待确认）；协同——产品值班（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、销售（重置申请发起，当前：陈名赞·推断待确认）、测试（当前：张东郅·推断待确认）、CTO（审批规则，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 一线引导自查（提示、实例地址、账号是否注册） → ② 普通用户找本企业管理员重置 → ③ 管理员忘记时提交重置申请 → ④ 三方核验 → ⑤ 重置为随机密码并私密交付 → ⑥ 客户首登改密 → ⑦ 留档客户恢复登录；超管密码重置有审批和操作留档；初始/重置密码不在群里明文传递待新建96
X-CS-09计费余额异常核查、对账修复与退款客户或用户反馈充值未到账、扣费异常（失败仍扣费、扣得过快）、余额为 0 或为负、充值/消费/剩余三者对不上、Token 消耗异常激增，或额度充错对象时启动。主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、服务端研发（当前：邓乾、杨云峰、岳阳·推断待确认）、网关上游维护（当前：杨明学·推断待确认）、运维（当前：宋祺睿·推断待确认）、一线客户对接人（当前：杜中瑞、杨朋伟、游家豪、闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 分类定级 → ③ 查订单/账单/网关日志 → ④ 定位根因 → ⑤ 出修复或补偿方案并审批 → ⑥ 备份后执行修复/退款 → ⑦ 客户验收与答复 → ⑧ 复盘并沉淀 FAQ结案的计费异常工单（含根因、影响范围、修复/退款记录、客户确认），P0/P1 事件的复盘文档，更新后的计费 FAQ。待新建400
X-CS-10C 端用户售后入口、退款与客诉处理C 端用户（LeapAll、OPC 商城卡密、消费券等）申请或催退款、反馈卡密过期、查不到订单、找不到售后联系方式，或客诉直接打到公司人员电话时启动。主责——C 端客服/运营专员（当前：陈震·推断待确认）；协同——社区运营负责人（当前：陈梦琪·推断待确认）、电话客服（当前：胡橙橙·推断待确认）、平台开发（当前：葛家和、吴世豪、邓乾·推断待确认）、测试（当前：张东郅·推断待确认）、财务专员（当前：待指定）、外部退款审批合作方；兜底——运营负责人（当前：李凯·推断待确认）① 统一入口受理 → ② 查单核实 → ③ 判断退款条件 → ④ 提交合作方/财务审批 → ⑤ 跟踪进度并定期回告 → ⑥ 到账确认与答复 → ⑦ 结案归档与话术更新结案的售后工单（退款到账或给出明确不予退款理由），用户确认记录，持续更新的客服话术库。待新建225
X-CS-11定制客户特殊配置台账与售后范围界定客户使用了魔改版本、自带模型、自接 NewAPI、本地算力路由或临时脚本等非标配置，出现问题需要判断是否属于标品售后、给出诊断报告与对客口径时启动；新增任何非标配置时也需登记。主责——Leap 研发/技术负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、排查研发（当前：宋祺睿、柯逸飞·推断待确认）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 非标配置特批与登记 → ② 问题来时查台账 → ③ 判定标品/非标 → ④ 定响应优先级 → ⑤ 出诊断报告 → ⑥ 销售按统一口径对客回复 → ⑦ 收费/修复决定 → ⑧ 更新台账定制客户特殊配置台账（客户、定制点、负责人、版本、是否收费）；每次问题对应的诊断报告与对客回复记录。待新建96
X-CS-12硬件设备售后、返修与上门维保已交付的一体机/工作站/服务器出现故障（硬盘、掉线、网口、断电、IP 变化、无法访问），需要远程判断、上门处理、返修或换机时启动；销售一体机时界定售后责任与运维成本也按本流程的责任矩阵执行。主责——硬件运维负责人（当前：杨明学·推断待确认）；协同——现场运维/交付工程师（当前：游家豪·推断待确认）、软件运维（当前：宋祺睿、杨云峰·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、产品与交付统筹（当前：杨萌·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 远程初判（硬件/软件/网络/客户操作）→ ③ 远程指导处理 → ④ 派运维上门 → ⑤ 返修判断与备机替换 → ⑥ 返厂寄送与跟踪 → ⑦ 修复验收与回寄 → ⑧ 费用与责任界定、结案结案的硬件售后工单（故障原因、处理方式、返厂物流、费用归属、客户确认），更新后的设备台账与客户须知。待新建400
X-CS-13客户反馈转缺陷/需求与修复验收闭环反馈群、客户群、试点客户、内部试用或测试中发现的问题与 badcase，需要判定是 Bug、需求、Badcase 还是定制，进入 Issue/需求池，修复后验收并回告反馈人时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——反馈值班提单人/测试（当前：黄霆瑄、张东郅、潘浩伟·推断待确认）、研发（当前：岳阳、柯逸飞、陈晖·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、一线对接人（销售/FDE/交付，当前：杜中瑞、王满、吴琪、季学森·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、运维（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一收集 → ② 值班人每日汇总提单 → ③ 判定 Bug/需求/Badcase/定制 → ④ 新包验证与去重 → ⑤ 分级指派或进需求池 → ⑥ 修复并指派验收人 → ⑦ 验收 → ⑧ 回告反馈人并回写状态 → ⑨ 周期复盘每条反馈都有去向（Issue 编号、需求池条目或"不处理"理由），修复项有验收记录并已回告客户；按月输出反馈分析报告。待优化180
X-CS-14客户新需求承诺前可行性确认与变更响应已交付客户或合作客户提出新功能、活动规则、重度使用要求，对接人准备答应或客户已在等待答复时启动；对客承诺任何非现有功能前必须先走本流程。主责——客户项目负责人（当前：徐莉〔跃竞线〕·推断待确认；Leap 线当前：待指定）；协同——一线对接人（当前：陈雁、张康·推断待确认）、技术可行性评估人（当前：丁震宇·推断待确认）、产品负责人（当前：待指定）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 一线不当场承诺，登记需求 → ② 判断是否 Bug / 合同范围内 → ③ 技术可行性与工作量评估 → ④ 定答复方案（做/折中/加价/拒绝）→ ⑤ 按模板对客答复 → ⑥ 进入需求池或变更报价 → ⑦ 记录承诺并跟踪兑现每条客户新需求的可行性确认单（结论、答复口径、是否收费、负责人），以及对客的书面答复记录。待新建144
X-CS-15版本更新/停机客户通知与更新日志服务端或客户端版本上线、停机升级、额度/数据迁移等会影响客户使用时，需要提前通知销售、售后和客户群避开更新窗口，并在帮助中心发布更新日志时启动。主责——产品负责人（发版统筹）（当前：杨萌·推断待确认）；协同——产品经理（更新日志）（当前：陈震·推断待确认）、产品经理（客户群通知）（当前：黄飞鹏·推断待确认）、研发技术负责人（停机窗口）（当前：王皓南·推断待确认）、运维发版（当前：宋祺睿·推断待确认）、帮助中心部署（当前：葛家和·推断待确认）、销售（当前：杜中瑞·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 确定发版/停机窗口 → ② 起草通知与更新日志 → ③ 内部先通知销售/售后/市场 → ④ 按时限通知客户群 → ⑤ 时间变动即时补发 → ⑥ 执行更新 → ⑦ 发布完成通知与更新日志 → ⑧ 更新后 1 小时观察客户反馈已送达所有受影响客户群的更新/停机通知（含时间窗、影响、注意事项），帮助中心更新日志，通知送达清单。待优化160
X-CS-16服务迁移中的客户账号与余额迁移测试服转正式服、旧网关（如旧 NewAPI）下线切换到新网关、服务器迁移或服务停用时，需要迁移客户账号、数据、余额并统一对外口径、提前通知客户时启动。主责——发起迁移的技术负责人（当前：王皓南·推断待确认）；协同——对外口径收口（当前：韩诗琪·推断待确认）、产品负责人（当前：杨萌·推断待确认）、额度迁移管理员（当前：邓乾〔LeapAll〕、柯逸飞〔LeapCore/网关〕·推断待确认）、运维（当前：宋祺睿·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、测试（当前：张东郅·推断待确认）、定制软件负责人（当前：望政韬·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 依赖与客户盘点 → ② 定迁移方案与继承规则 → ③ 定对外口径与 FAQ → ④ 提前通知客户（含截止日）→ ⑤ 迁移账号/余额并核对总额 → ⑥ 灰度关停旧服务 → ⑦ 观察期 → ⑧ 销毁旧资源并登记迁移完成且余额核对一致的客户清单、已送达的客户通知与 FAQ、旧资源下线与销毁记录、新的系统负责人边界。待新建200
X-CS-17对外沟通口径、FAQ 话术与对外信息脱敏客户或销售/渠道问“为什么慢/贵/失败”“选哪个模型”“支不支持某环境/某功能”、需要解释数据异常，或要把内部截图/通知转给客户时，先查 FAQ 口径库，查不到再按本流程定口径，对外内容先脱敏主责——FAQ/口径库维护人（产品，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售/渠道负责人（当前：闫登辉·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查 FAQ 口径库 → ② 未命中则提口径申请 → ③ 研发核对技术事实 → ④ 口径负责人定稿 → ⑤ 对外回复（含脱敏检查）→ ⑥ 入库并通知销售/渠道 → ⑦ 每次发版复核一条已入库、标注适用范围与生效日期的 FAQ 口径；一次符合口径、已脱敏的对外回复待新建160
X-CS-18帮助中心、使用手册与交付注意事项维护客户/员工索要使用手册，客户或销售反馈帮助中心内容缺失、过时，交付现场或售后反复遇到同类使用问题（登录、网口、IP、飞连）时，更新帮助中心与交付注意事项手册并发布主责——帮助中心内容负责人（产品，当前：杨萌·推断待确认）；协同——交付部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、销售（当前：杜中瑞·推断待确认）、测试负责人（当前：张东郅·推断待确认）、运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 收集问题与内容需求 → ② 分类（帮助中心/注意事项手册/运营推文/转研发）→ ③ 撰写或修订 → ④ 技术核对 → ⑤ 发布并更新入口 → ⑥ 通知销售与交付 → ⑦ 每迭代复核已更新的帮助中心页面与交付注意事项手册（含版本号与更新日期），并在产品内、交付群公布入口待优化135
X-CS-19重点客户回访与使用推进重点客户交付上线后，按固定节点回访；或发现客户关键使用人（尤其决策人）没用起来、商务推进被卡时，安排客访推动使用，并把反馈分类传回产品主责——客户经理（当前：按客户分配，吴琪、杨朋伟·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 交付后建回访计划 → ② 看后台使用数据 → ③ 按节点回访/客访 → ④ 填回访记录 → ⑤ 反馈分类并转产品 → ⑥ 制定推进动作 → ⑦ 回告客户更新 → ⑧ 月度复盘每个重点客户的回访记录（多维表格）、反馈处理去向、使用推进动作及结果待优化135
X-CS-20客户成功案例与效果文档制作项目出现效果好的客户使用场景，或销售/品牌需要展示材料时，按统一模板整理成功案例与效果文档，经真实性核查、客户授权和脱敏后对外使用主责——项目研发/FDE（当前：张康·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户经理（当前：待指定）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提出案例需求 → ② 采集真实输入输出 → ③ 按模板撰写 → ④ 真实性核查 → ⑤ 客户授权与脱敏 → ⑥ 定稿入库 → ⑦ 分发销售/品牌一份标注“内部可用/对外可用”的案例文档（场景、输入、输出、效果数据、客户反馈、授权状态），入案例库待新建120
X-CS-21VIP 客户“一键增强”人工代写服务白名单内的特殊/VIP 客户在产品内点击“一键增强”后，由内部人员用 Claude Code 人工优化可研报告并回写到客户侧，在约定时限内交付主责——增强写作执行人（后端/全栈研发，当前：徐鑫宇·推断待确认）；协同——前端研发（当前：侯怡辰·推断待确认）、前端负责人（当前：季学森·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户经理（当前：待指定）；兜底——Leap/鼎慧研发负责人（当前：王皓南·推断待确认）① 白名单申请与开通 → ② 客户点击触发通知 → ③ 认领 → ④ 人工增强写作 → ⑤ 质量审核 → ⑥ 回写数据库 → ⑦ 通知客户 → ⑧ 登记交付时长经质量审核的增强版可研报告已更新到客户账号，并在工单中记录认领、完成时间待新建200
X-CS-22俱乐部/商户入驻与会员端配置对接新俱乐部/商户确定入驻跃玩、星域或会员端时，收集入驻材料、开通商户、配置会员等级与权益、导入客户名单、完成操作教学，并持续接收配置类咨询主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、销售/商务（当前：飞书用户8994FW·推断待确认）、获客/客户教学（当前：刘安达·推断待确认）、产品经理（当前：段涵·推断待确认）、网页端前端（当前：陈真炎·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 签约后建入驻工单 → ② 发材料清单与信息收集表 → ③ 材料审核与商户开通 → ④ 会员端配置 → ⑤ 客户名单批量导入 → ⑥ 操作教学 → ⑦ 上线确认 → ⑧ 首月跟进与问题入台账已开通并完成会员体系配置的俱乐部/商户账号，客户名单导入完成，教学记录与入驻台账状态为“已上线”待优化135
X-CS-23俱乐部客户反馈受理与转研发排查俱乐部、陪玩、老板反馈使用问题、入账/分账异常、余额支付或提现失败、积分/成长值未同步时，统一受理、收齐要素、按客户等级与资金影响分级，转研发排查，修复后回告客户主责——客户反馈受理（运营，当前：陈雁·推断待确认）；协同——商户入驻专员（当前：宫经喜·推断待确认）、产品经理（当前：段涵·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠、蒋兴武、魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 受理登记（必填订单号/UID 等）→ ② AI 助手自查 → ③ 分级分派 → ④ 研发排查与复现 → ⑤ 修复/补正（涉资金人工确认）→ ⑥ 回告客户 → ⑦ 根因归类入排查手册一条要素完整、有优先级、有处理人和根因的问题记录；客户收到处理结果；重复问题沉淀为排查手册或 FAQ待新建300
X-CS-24俱乐部账务类工单处理俱乐部提出主户更换、实名更换、剩余资金迁移、资金调账、罚款强制划扣或账单疑问时，通过统一工单受理，涉资金操作经审批后由研发执行并留痕主责——俱乐部工单受理（客服/运营，当前：宫经喜·推断待确认）；协同——后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 俱乐部提交工单 → ② 材料核验 → ③ 审批（按类型分级）→ ④ 研发执行 → ⑤ 复核 → ⑥ 通知俱乐部 → ⑦ 归档留痕一张完成审批、执行、复核的工单，附执行前后数据截图和通知记录待新建225
X-CS-25订单投诉受理与售后缓冲规则跃玩平台顾客对订单或陪玩服务不满发起投诉，或自助订单陪玩提交服务凭证后进入 48 小时售后缓冲期时启动主责——平台客服/售后主管（当前：待指定）；协同——俱乐部接待、平台超管（当前：待指定）、产品经理（当前：樊九辰、段涵·推断待确认）、后端投诉域开发（当前：张楠、王子明·推断待确认）、财务专员（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 顾客发起投诉/售后申请 → ② 接待首响与首次处理 → ③ 顾客确认或二次申诉 → ④ 管理员升级复核 → ⑤ 超管终局裁定 → ⑥ 退款/罚款/补偿分级审批执行 → ⑦ 结案留痕；无异议订单缓冲期满自动完单结算有完整处理轮次、事实快照与审计留痕的投诉单；已执行的退款/罚款/补偿凭证；按规则自动完单结算的自助订单待优化225
X-CS-26客户续约续费与维保到期管理客户的额度包、订阅、席位、软件授权或硬件维保即将到期时，提前提醒、评估续约意向并推动续签，避免服务中断与收入流失主责——客户成功专员（当前：待指定）；协同——客户对接销售、财务专员、交付负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 到期台账维护 → ② 到期前 60 天提醒 → ③ 使用情况与健康度分析 → ④ 续约沟通 → ⑤ 报价与合同 → ⑥ 续费到账开通 → ⑦ 未续约处置续约合同或续费到账记录；未续约客户的流失原因记录待新建72
X-CS-27B 端客户投诉升级处理与满意度回访企业/政府/渠道客户对产品质量、交付延期、服务态度或计费结果正式表达不满、要求赔偿或威胁解约时，按等级受理、升级、给出处理方案并回访主责——客户成功专员（当前：待指定）；协同——客户对接销售、交付负责人、研发值班、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 投诉登记 → ② 分级（一般/严重/重大）→ ③ 指定处理人与时限 → ④ 调查原因 → ⑤ 出处理方案并内部审批 → ⑥ 对客答复 → ⑦ 满意度回访 → ⑧ 月度复盘投诉处理记录、对客书面答复、回访结果、整改项待新建96
X-CS-28售后访问客户环境与数据的授权留痕售后、交付、研发为排查问题需远程登录客户私有化实例、查看客户业务数据/对话记录/文件、导出日志或诊断包时，先取得客户授权、限定范围，并在操作后留痕主责——售后负责人（当前：待指定）；协同——研发值班、交付工程师、客户对接销售、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 判定是否需访问客户数据 → ② 向客户申请书面授权（范围、时限）→ ③ 内部登记 → ④ 最小范围访问 → ⑤ 操作记录 → ⑥ 关闭临时通道与删除导出数据 → ⑦ 告知客户结束客户授权记录、访问登记与操作记录、通道关闭与数据删除确认待新建200
X-CS-29客户服务终止、账号注销与数据返还销毁客户合同到期不续、解约、试用结束未转化，或客户/用户申请注销账号时，按约定停止服务、返还或导出客户数据、销毁我方留存数据并出具确认主责——售后负责人（当前：待指定）；协同——客户对接销售、研发值班、交付负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 终止触发确认 → ② 结清费用 → ③ 通知客户数据导出窗口 → ④ 协助导出/返还 → ⑤ 停服与账号/席位注销 → ⑥ 销毁我方留存数据与备份 → ⑦ 出具确认函 → ⑧ 台账关闭数据返还/导出记录、账号与实例注销记录、数据销毁确认函、台账状态关闭待新建60

X-PRD 产品 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-PRD-01产品方向、路线图与新产品形态决策出现新商机、新范式/竞品冲击、前沿热点，或产品定位（B端/C端、标品/行业版、产品形态）说法不一致时，启动方向研判，产出季度路线图或新产品形态决策。主责——产品总监（当前：杨萌·推断待确认）；决策——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、基座架构/预研负责人（当前：陈晖·推断待确认）、COO（当前：常元和·推断待确认）、IT/采购（当前：杨明学·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 机会登记 → ② AI 初研 → ③ 周研判会 → ④ 方案与可行性 → ⑤ 决策评审留 ADR → ⑥ 纳入路线图/立项 → ⑦ dogfood 验证 → ⑧ 季度复盘机会池条目、决策记录（ADR）、季度产品路线图（版本、节点、负责人）、新品立项卡待新建192
X-PRD-02竞品调研与对标评测发现竞品、竞品发布新品、行业出现同类产品、竞品申请入驻自家商城或疑似抄袭自家功能时，启动登记、评测与对标，产出可复用的对标结论。主责——产品运营（当前：杨黔昆·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）① 发现登记 → ② 分级 → ③ 基准任务评测 → ④ 对标结论 → ⑤ 结论分流 → ⑥ 月度简报 → ⑦ 任务集更新竞品档案（多维表格）、单品对标评测报告、月度竞品简报、基准任务集待新建96
X-PRD-03用户调研、专家访谈与场景案例沉淀需要验证产品价值、挖掘用户痛点、定义质量标准（如“什么是好可研”），或客户反复问“有哪些场景案例”时，组织用户访谈、专家对话、顾问群运营，并沉淀调研结论与场景案例库。主责——产品总监（当前：杨萌·推断待确认）；协同——COO（当前：常元和·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营负责人（当前：李凯·推断待确认）、研发/运维（当前：宋祺睿·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、运营/客服（当前：胡橙橙·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 调研计划 → ② 对象筛选 → ③ 约访发提纲 → ④ 访谈与转写 → ⑤ 纪要入库 → ⑥ 结论打标签分流 → ⑦ 案例入库 → ⑧ 月度简报调研计划、访谈纪要、调研结论（含用户画像判断）、场景案例库、用户/专家联系台账待优化108
X-PRD-04行业版需求摸排与产品规划新行业版（科研、投资人、法律、工程、水利、电竞、招投标、产学研等）启动或推进时，摸排行业需求，判断走标品/行业包/项目定制/暂缓，形成行业版规划和固定迭代排期。主责——产品总监（当前：杨萌·推断待确认）；协同——行业版负责人（当前：徐莉、闫登辉、吴琪、杨朋伟·推断待确认）、工程版产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、插件研发（当前：陈锦杰、季学森、侯怡辰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 行业版登记 → ② 需求摸排 → ③ 四去向分流 → ④ 规划编写 → ⑤ 规划评审 → ⑥ 排期与功能清单 → ⑦ 插件需求客户确认 → ⑧ 试用验收 → ⑨ 周度台账更新行业版需求管理表（版本详情+需求详情）、行业版规划文档、迭代排期表/功能清单、客户需求台账、行业插件需求文档待优化192
X-PRD-05需求统一收口与提需入口规则市场、销售、客户、领导、FDE、研发、合作方等任何人要对产品提功能/优化/定制需求时，一律经产品统一入口受理、评审、排期，并把结果回告提出人；禁止绕过产品直接找研发。主责——产品总监（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认，辅助审核）、客户端研发（当前：李铭熙·推断待确认，辅助审核）、测试负责人（当前：张东郅·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认，FDE 侧需求汇总）、COO（当前：常元和·推断待确认）、各业务线兼职产品对接人（当前：刘昱潇·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认，业务线需求对接）、研发（当前：杨云峰、张康、裴蔬桐、岳阳·推断待确认）、CEO（当前：邴龙志·推断待确认，战略需求提出）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认，加急审批与收口仲裁）① 表单提报 → ② 产品受理 → ③ 归类定侧 → ④ 周需求评审 → ⑤ 排入迭代 → ⑥ 开工前对齐 → ⑦ 验收 → ⑧ 回告提出人需求池中状态完整的需求单（含来源、优先级、产品确认人、验收标准、迭代、处理结果），及对提出人的回告待优化400
X-PRD-06内测与内部试用（dogfood）反馈收集分流新产品或新版本（LeapPPT、LeapAll、LeapCore、内部 AI 小站等）进入内测或全员试用时，组织内部先用起来，统一收集 bug、体验问题、需求和 Badcase，并分流到工单或需求池，结果回告反馈人。主责——产品运营（当前：杨黔昆·推断待确认）；协同——LeapAll 研发（当前：邓乾、李铭熙、岳阳·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）、研发/发版（当前：宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认，对外准入把关）；兜底——产品总监（当前：杨萌·推断待确认）① 内测公告 → ② 推动使用 → ③ 统一入口反馈 → ④ 每日 triage → ⑤ 研发认领修复 → ⑥ 发版回告 → ⑦ 周报 → ⑧ 内测复盘与准入判定内测反馈表（含状态与关联工单）、已知问题公示表、每周内测周报、内测复盘与对外准入结论待优化108
X-PRD-07外部用户、客户与销售反馈收集回流产研外部用户、客户、销售/市场一线、培训学员、内部业务系统（CRM、渠道系统）使用者提出问题或建议时，统一登记、triage（bug/体验/需求/Badcase/咨询）、回流产研，并把处理结果回告反馈人。主责——产品总监（当前：杨萌·推断待确认）；协同——产品运营（当前：杨黔昆·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态市场总监（当前：许君·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、渠道系统/CRM 负责人（当前：郭逸非·推断待确认）、渠道系统/CRM 研发（当前：陈子康·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 按规范提报 → ② 机器人入表查重 → ③ triage 定类定级 → ④ 转工单/需求池 → ⑤ 修复或答复 → ⑥ 回告与 FAQ 更新 → ⑦ 销售周汇总 → ⑧ 月度复盘反馈总表（含类型、优先级、状态、关联工单、回告情况）、客户 FAQ、销售客户问题周汇总、月度反馈复盘报告待优化300
X-PRD-08Agent Badcase 收集与转需求/缺陷工单Agent 能跑通但效果差（理解偏差、规划失败、工具调用错误、Skill 效果差、缓存命中率低等）时，保留对话样本作为 Badcase 沉淀，用于评测回归，并分流为需求或 bug 工单。主责——评测工程师（当前：黄霆瑄·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、Agent/模型研发（当前：岳阳·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）；兜底——测试负责人（当前：张东郅·推断待确认）① 提交样本 → ② 初筛 → ③ 分类分流 → ④ 入样本库标注 → ⑤ 转 Agent 能力 issue → ⑥ 修复与回归 → ⑦ 月度评测报告Badcase 样本库（含对话、标注、状态）、“Agent 能力”项目 issue、月度 Badcase 评测报告、并入基准评测集的回归用例待新建24
X-PRD-09需求提报登记与需求池管理任何人（用户、销售、交付、运营、高层、研发、测试）提出新功能或体验优化需求（非缺陷），需要查重、登记入需求池、指派负责人、跟踪状态，直到上线后通知提出人主责——产品经理（当前：杨萌·推断待确认）；协同——需求池维护/产品助理（当前：杨黔昆、陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞线产品经理（当前：徐莉、段涵、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一入口提报 → ② 查重归并 → ③ 登记需求池并回执 → ④ 产品评估（采纳/待定/不做） → ⑤ 入工作台指派负责人 → ⑥ 进迭代转工单并通知测试 → ⑦ 上线自动通知提出人 → ⑧ 双周查漏清理状态准确的需求池（多维表格），每条需求都有来源、提出人、负责人、评估结论、状态与上线日期；上线时自动通知提出人待优化180
X-PRD-10需求优先级评估与紧急插单高层、客户、销售或市场提出“急需求”，或多个需求争抢同一迭代时，按统一分级标准决定插单、后置、转 FDE 或拒绝主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、销售/客户经理（当前：杨朋伟、杜中瑞、闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 高优表单提报 → ② 产品按分级标准定级 → ③ 研发评估工作量与对当前迭代的影响 → ④ 决策（插单/下迭代/转 FDE/拒绝） → ⑤ 回执提出人 → ⑥ 插单则等量移出并通知测试 → ⑦ 每周同步重点队列带分级、决策结论和理由的“重点需求队列”；插单决定附“移出项清单”；提出人收到书面答复待新建192
X-PRD-11客户定制需求评估、标品化判断与报价估算大客户、渠道或客户 Demo 提出定制需求时，先澄清需求，再判断标品吸收、开关隔离、FDE Skill 还是项目定制，输出范围、人日、成本价和排期，交商务定价主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、基座研发/FDE（当前：望政韬、黄振锋、张康·推断待确认）、商务负责人（当前：常元和·推断待确认）、销售（当前：刘昱潇、吴琪、杨朋伟、闫登辉·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 定制需求提报 → ② 需求澄清（问卷+资料格式） → ③ 标品化判定 → ④ 范围与人日评估（含研发 Review） → ⑤ 输出成本价与兜底规则 → ⑥ 商务定价与立项 → ⑦ 隔离开发与按版本冒烟 → ⑧ 客户确认版需求清单发出定制需求评估单（范围、标品化结论、人日、成本价、售后边界、排期），以及发给客户确认的需求清单待新建300
X-PRD-12跨产品线/版本线能力同步与适配决策某产品线上线新能力，或主线客户端发布新版本时，决定是否、何时、以何种范围同步到其他产品线、信创版或基座组件主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座架构负责人（当前：陈晖·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发版或新能力触发 → ② 自动生成能力变更清单 → ③ 产品逐项标注同步决策 → ④ 各线评估工作量与依赖 → ⑤ 按跟版规则定适配窗口 → ⑥ 测试排期 → ⑦ 登记同步台账并通知跨线同步台账（能力项 × 产品线 × 是否同步 × 目标版本），以及每次主线发版对应的适配排期待新建81
X-PRD-13PRD 撰写与需求评审需求进入开发前，按模板写 PRD/原型并做 AI 预审，召开评审会确认技术可行性，发布评审结论和需求文档，让研发拿到能直接实现的需求主责——产品经理（当前：杨萌·推断待确认）；协同——产品专员（当前：陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、前端/后端评审代表（当前：季学森、侯怡辰、宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、UI 设计（当前：康紫馨·推断待确认）、跃竞线产品经理（当前：段涵、徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 判定是否需写 PRD → ② 按模板撰写 → ③ AI Review 与追问澄清 → ④ 前后端技术初评 → ⑤ 评审会宣讲与结论记录 → ⑥ 已读确认 → ⑦ 拆 issue 并关联 PRD → ⑧ 会议结论转行动清单与任务评审通过的 PRD（含评审结论、字段变更、不做什么、验收标准）、评审会纪要与行动清单、关联 PRD 的 issue待优化192
X-PRD-14业务规则与统计口径定义需求未写清的业务规则（额度归属、折扣、分账、状态定义、支付限额等），或同一指标在不同端、不同报表的计算不一致时，由产品定义规则/口径并全链路统一主责——对应产品线产品经理（当前：鼎慧线黄飞鹏、跃竞线徐莉·推断待确认）；协同——Leap 线产品经理（当前：杨萌·推断待确认）、跃竞产品（当前：段涵、樊九辰·推断待确认）、后端研发（当前：蒋兴武、王子明、张楠、陈锦杰、王皓南·推断待确认）、测试（当前：赵伟龙、李国庆·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 发现规则/口径疑问 → ② 工单打“待产品确认”标签提问 → ③ 产品给出结论（资金类会签） → ④ 写入业务规则与口径词典 → ⑤ 通知研发/测试/运营 → ⑥ 测试按口径验证 → ⑦ 存量数据影响处理 → ⑧ 上线公告业务规则与统计口径词典（每条有定义、公式、取值区间、生效版本），以及对应的实现与测试验证记录待优化144
X-PRD-15产品命名、术语与用户可见文案规范新产品、模块、型号需要命名，或出现说法不一、内部技术名词外露、报错与提示文案不清时，统一命名与术语表，规范对外口径和用户可见文案主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品专员（当前：陈震·推断待确认）、前端研发（当前：葛家和、侯怡辰·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 命名/文案需求提出 → ② 生成候选并查重（重名、商标、域名、禁用词） → ③ 拍板定名 → ④ 登记命名与术语表 → ⑤ 发布通知与改名影响清单 → ⑥ 代码/界面/文档统一修改 → ⑦ 用户可见文案对照表维护 → ⑧ 发版前禁用词扫描命名与术语表（内部名/对外名/中文名/代码字段/禁用词/商标状态）、错误码—文案对照表、改名影响清单完成记录待新建72
X-PRD-16UI/UX 设计需求、评审与设计走查新功能/页面需要设计，或界面风格不一致时，提设计需求、评审设计稿或方案、前端还原、设计走查并完成 UI 验收，规范和素材统一沉淀主责——产品经理（当前：杨萌；跃竞线段涵·推断待确认）；协同——UI 设计师（当前：康紫馨、史家宜、陈伟康·推断待确认）、前端研发（当前：岳阳、葛家和、季学森、侯怡辰、郝智豪、魏小东、陈真炎·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品专员（当前：杨黔昆、陈震、黄飞鹏、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提设计需求单 → ② 设计排期（无设计资源时 AI 原型） → ③ 开发前草图/方案评审 → ④ 高保真稿交付（标注、切图、状态稿、版本号） → ⑤ 前端还原 → ⑥ 设计走查 → ⑦ 产品 UI 验收 → ⑧ 规范与素材归档评审定稿的设计稿（统一入口、带版本号）、设计走查记录、UI 验收结论，以及持续更新的设计规范（色卡、组件、图标）与素材库待优化72
X-PRD-17风险功能准入与合规需求评估产品功能可能带来安全或法务风险（加载本机插件、执行系统命令、对外开放数据接口），客户 IT 提出安全合规要求（禁用命令、防批量拷贝、操作审计），或用户协议/隐私政策首次上线、内容更新、需要用户重新同意时，进开发排期前先完成风险评估和准入决策主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、LeapCore 后端（当前：杨云峰·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、协议功能研发（当前：魏宗浩·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 登记风险/合规需求 → ② 风险分级 → ③ 技术路径与成本评估 → ④ 法务与合同条款评审 → ⑤ 准入决策 → ⑥ 落地风险提示、开关或协议版本 → ⑦ 上线前复核 → ⑧ 归档并答复客户风险评估单（结论为准入/有条件准入/不准入）、上线的风险提示组件与功能开关（如开发者模式）、合同免责条款或对客承诺边界说明、协议版本台账与用户同意记录待新建150
X-PRD-18模型选型、档位配置与评测出现新模型或新渠道、现有模型不稳定、上游成本或折扣变化、客户反馈体验问题时，评估并决定用户可选模型上下架、经济/标准/专家档位背后的模型与思考强度、企业版开放的模型和 Skill 范围主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、测试与评测负责人（当前：张东郅·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、NewAPI 配置（当前：张康·推断待确认）、客户端/Skill Store（当前：李铭熙·推断待确认）、后端（当前：杨云峰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提出候选模型/调整 → ② 接入测试服并配成本 → ③ 跑评测集与试用 → ④ 输出评测结论 → ⑤ 决策档位映射与上下架 → ⑥ 测试环境验证后生产切换 → ⑦ 更新档位方案一页纸并通知 → ⑧ 上线后观察与回退评测报告、当前档位方案一页纸（档位/模型/渠道/思考强度/倍率/生效日期）、生产配置变更记录、对客档位说明口径、企业版模型与 Skill 开放清单待优化192
X-PRD-19第三方能力与外部方案调研选型接入产品需要接入外部 API、SaaS 或新能力（OCR、视频生成、企业信息查询、电子签、外呼、客户远程访问等）时，完成调研对比、成本与合规评估、选型决策，并交出接入清单与排期主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、接入研发（当前：魏宗浩·推断待确认）、后端/核价（当前：宋祺睿·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、网关（当前：吴世豪·推断待确认）、总经办采购（当前：待指定）、市场商务对接（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提需求并写清场景 → ② 归类入接入清单 → ③ 调研 2～4 个方案 → ④ PoC 实测 → ⑤ 成本、定价与合规评估 → ⑥ 选型评审决策 → ⑦ 采购开户与凭据入库 → ⑧ 接入开发、计费配置与上线排期选型对比表、PoC 结论、选型决策记录、第三方接入清单条目（类别、计费方、对接人、状态）、接口清单与计费 ID、采购/开户记录待新建240
X-PRD-20Skill 上架审核、开发者入驻与分润客户、OPC 开发者或第三方申请在开放平台/Skill Store/OPC 平台上架 Skill 或应用，需要入驻审核、竞品准入判断、按次扣费配置和分润结算规则时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill Store/客户端（当前：李铭熙·推断待确认）、商城研发（当前：邓乾·推断待确认）、网关研发（当前：岳阳、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开发者入驻申请 → ② 资质与协议签署 → ③ 提交 Skill 与扣费声明 → ④ 自动预检 → ⑤ 人工审核（含竞品与安全） → ⑥ 上架与计费配置 → ⑦ 调用计量与分润结算 → ⑧ 更新/下架/注销处理入驻记录与开发者协议、审核记录、上架的 Skill 商品（名称、描述、分类、价格、扣费规则）、调用量统计、分润结算单待优化180
X-PRD-21内置技能评估与技能商店内容维护公司自研的 Skill/插件新开发或更新后，评估是内置进客户端、由开放平台下发还是只上技能商店；以及技能商店里的描述、分类、版本维护，和开放平台下发技能/场景包/行业参数的接口契约对接主责——Skill 负责人（当前：李凯·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill 开发（当前：邓乾、魏宗浩·推断待确认）、builtin 审查（当前：岳阳·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、客户端与 LeapAuth/Update（当前：宋祺睿、杨云峰·推断待确认）、Skill Store/私有 Hub（当前：李铭熙·推断待确认）、产品排期（当前：陈震·推断待确认）、测试（当前：潘浩伟·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 提交 Skill 及测试结果 → ② 安全与格式审查 → ③ 内置/下发/商店评审 → ④ 建工单排期 → ⑤ 填写商店内容并上架或内置 → ⑥ 发版验收 → ⑦ 商店内容日常维护 → ⑧ 下发接口契约变更同步Skill 评审记录（结论为内置/开放平台下发/仅商店/不上线）、排期工单、上架或内置的 Skill（名称、描述、分类、版本、计费说明）、技能商店内容台账、下发接口契约文档待优化108
X-PRD-22模型/API 售价、倍率调整与对外价格表同步上游模型成本、汇率、折扣变化，或新模型/新能力（视频、OCR、企业信息查询）上线，或平台首次上线需要定价时，测算毛利、确定倍率与档位售价、配置网关计费，并同步对外价格表与模型清单主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、v5 后端与发布（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、AIAPI 渠道维护（当前：杨明学、吴世豪·推断待确认）、NewAPI 配置（当前：邓乾·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务（当前：待指定）；定价批准——COO（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别价格变动 → ② 更新成本价 → ③ 测算毛利与建议售价 → ④ 定价审批 → ⑤ 提 PR 改网关价格并补测试 → ⑥ 测试环境验证后发布 → ⑦ 同步对外价格表与模型清单 → ⑧ 通知销售与财务对账价格主表新版本（成本价、倍率、售价、生效时间）、定价审批记录、合并发布的计费配置、对外价格表与模型清单、价格变更通知待优化240
X-PRD-23产品套餐、积分/额度定价与计费规则产品商业化、公测、新增付费档位（如 Pro/高画质）、上线充值、邀请奖励、注册赠送或额度包时，完成成本测算，确定积分/词元/额度单价、套餐与赠送规则、计费口径，并落到开发与验收主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/扣费实现（当前：宋祺睿、邓乾·推断待确认）、LeapPPT 研发（当前：马漳毓、黄振锋·推断待确认）、运营方案（当前：李凯·推断待确认）、产品经理（当前：杨黔昆、黄飞鹏·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 立项定价需求 → ② 真实场景成本测算 → ③ 拟定价与激励方案 → ④ 定价评审拍板 → ⑤ 出计费口径单 → ⑥ 开发实现并引用口径单 → ⑦ 口径对账与上线检查 → ⑧ 发布说明与上线后监控成本测算表、定价决策记录、计费口径单（售价、成本、毛利、换算比例、赠送、并发限制）、已上线的套餐/额度包配置、对用户的计费说明待新建300
X-PRD-24硬件产品配置选型、成本评估与供应商问题反馈出现新机型或供应商新报价、硬件配置要变更（CPU、RAID、新增屏幕或外壳开模）、客户询问能跑多大模型或硬件跑不动、渠道系统需要标准席位与增配规则，以及录音卡等硬件出现固件问题需要反馈工厂时启动主责——硬件负责人（当前：杨明学·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、供应商对接与成本核算（当前：闫登辉·推断待确认）、配置文档维护（当前：游家豪·推断待确认）、商务定价（当前：李鹏为、常元和·推断待确认）、模型规格评估（当前：望政韬·推断待确认）、后端（当前：杨云峰·推断待确认）、外包硬件对接人（当前：吕振·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 登记触发事项 → ② 技术方案与成本核算 → ③ 选型/变更评审 → ④ 商务拍板售价 → ⑤ 更新标准配置与席位 SKU 表 → ⑥ 发布对外口径、作废旧版 → ⑦ 有效期到期复核 → ⑧ 硬件问题反馈工厂并闭环硬件选型/变更评审记录、标准配置表（带版本与有效期）、“型号×内存×硬盘→席位/并发/参考价”标准表、对外配置与价格口径、模型×硬件基线表、硬件问题清单与工厂反馈记录待优化180
X-PRD-25AI 报告提示词与报告类型配置变更字字可研等 AI 报告产品要新增报告类型或项目类型、调整提示词（目录或正文），或者业务专家提交新的提示词、专业类型、法规类型等配置时启动。主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——业务专家/提示词作者（当前：王满·推断待确认）、后端研发（当前：王皓南·推断待确认）、平台研发（当前：宋祺睿·推断待确认）、前端研发（当前：待指定）、测试（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 登记变更 → ② 产品审核类型与字段 → ③ 自动通知并校验覆盖率 → ④ 研发接入/配置 → ⑤ 在测试环境生成验证 → ⑥ 业务专家验收 → ⑦ 不通过的开整改单 → ⑧ 随版本上线并标记版本提示词库中带版本号、状态为“已上线”的提示词记录；对应报告类型能在生产环境正常生成；变更记录和整改记录都能追溯。待优化81
X-PRD-26行业案例、测试数据与知识库素材获取产品或行业 Skill 开发需要真实案例、测试数据、评判标准或行业资料，要向合作方、客户、外包爬虫或自有数据源获取，并清洗入库时启动。主责——需求方产品经理（当前：杨萌·推断待确认）；协同——数据/爬虫研发（当前：魏宗浩·推断待确认）、后端研发/查库（当前：王皓南·推断待确认）、业务专家（当前：王满·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、FDE/Skill 研发（当前：邓乾、李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、平台研发（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 写数据需求单 → ② 盘点现有库存与缺口 → ③ 选定来源并约定截止日 → ④ 获取并留痕 → ⑤ 脱敏、清洗、转换 → ⑥ 入 test 库，抽样检查 → ⑦ 产品验收后入 prod 或评测集 → ⑧ 登记素材台账按类型分好、已脱敏、有标签的案例集、测试数据集或知识库数据（test/prod），以及一份记录来源、范围、覆盖率的素材台账。待新建180
X-PRD-27迭代规划、故事拆分与排期每个迭代开始前（两周或一周一迭代），汇总评审通过的需求，拆成 issue 或故事卡，估点数，分配到人，确定迭代范围和交付日；迭代中插入需求或迭代末迁移未完成项时也适用。主责——产品负责人/迭代负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、段涵·推断待确认）、研发复杂度评估（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 产品出下迭代需求（D-5）→ ② 研发估点（D-3）→ ③ 按容量砍需求、低优先级移入待评估池 → ④ 迭代计划会 → ⑤ 建 milestone/issue 并分配到人 → ⑥ 成员按天拆任务 → ⑦ 迭代末迁移未完成项一份迭代计划，含需求清单、点数、负责人、交付日、待评估池；每个需求有对应 issue 并挂在 milestone 上；工作台任务视图更新完毕。待优化108
X-PRD-28开发中需求澄清与产品拍板研发或测试在开发、测试中遇到需求细节没定义、预期行为不确定（看起来像 bug 又像设计）、术语或权限语义有分歧、新集成要选技术方案，需要产品澄清或拍板时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 在工单按模板提问 → ② 自动 @ 模块产品 → ③ 产品限时答复或拍板 → ④ 有争议的开 15 分钟对齐会 → ⑤ 结论回写工单和决策记录表 → ⑥ 涉及术语、规则的同步更新术语表或规则台账 → ⑦ 通知相关研发和测试工单里有明确的产品结论（谁定、何时定、结论是什么）；决策记录表新增一条；需要时同步更新需求文档、术语表、权限矩阵或业务规则台账。待优化135
X-PRD-29需求变更控制开发中的需求要被砍、范围或文案调整、临时追加，或实现与原型不一致需要改，包括演示和发布前体验者提的新需求、前线口头协商的需求时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、前线/解决方案（当前：李凯·推断待确认）、发布冻结期变更审批人（当前：常元和·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交变更单 → ② 研发评估影响 → ③ 产品决定（本迭代/下迭代/拒绝）→ ④ 冻结期另需审批人同意 → ⑤ 更新需求文档、原型和工单 → ⑥ 机器人通知研发和测试 → ⑦ 调整排期和测试点 → ⑧ 判断是否重新评审一条已审批的需求变更记录（变更内容、影响、决定、决策人）；需求文档、工单、原型都已同步更新；研发、测试收到通知，排期已调整。待优化192
X-PRD-30迭代站会、进度追踪与交付节点管理迭代执行期的日常站会和迭代回顾；多项目、多客户、多版本并行时，需要统一追踪关键交付节点、发布进度和延期预警时启动。主责——项目经理/进度负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、技术顾问（当前：望政韬·推断待确认）、后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/部署（当前：杨明学·推断待确认）、商务对接（当前：闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、CEO（知会）（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 站会前更新 issue 和任务状态 → ② 固定时间开站会 → ③ 站会决议写入迭代文档 → ④ 维护“客户×版本×节点”里程碑台账 → ⑤ 机器人每日汇总进度 → ⑥ 节点前 2 天预警 → ⑦ 延期决策并通知 → ⑧ 迭代末开回顾会每日站会纪要；实时更新的里程碑台账（客户、版本、模块、截止日、负责人、状态）；延期通报；迭代回顾的改进待办。待优化240
X-PRD-31产品验收研发完成需求、准备转测试（ready-for-test）前，或新版本上线前，需要产品逐项或逐模块确认实现符合需求（含计费口径和文案）时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、提交验收的研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：涂维轩、黄霆瑄、潘浩伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 研发自测后附录屏和验收地址，改状态为“待产品验收” → ② 机器人 @ 指定验收人 → ③ 产品按验收标准走查 → ④ 通过：留痕并流转测试 → ⑤ 不通过：评论问题并退回 → ⑥ 技术单改由研发负责人和测试联合验收 → ⑦ 迭代末清点状态 → ⑧ 发版前内测，同步已知问题每张功能工单上都有“验收人 + 结论 + 截图/录屏 + 日期”的留痕；通过的进入测试，不通过的有明确问题清单；发版前有已知问题清单。待优化180
X-PRD-32AI 生成质量评测与领域专家验收字字可研等 AI 报告产品出了新版本或新生成能力（仿写、套模板、先审后生、测算规则），需要工程师、领域专家或客户审核人评价，做双盲对比，或业务规则不明需要领域专家澄清并验收时启动。主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——领域专家（当前：王满·推断待确认）、后端研发/方案（当前：王皓南·推断待确认）、测算与功能研发（当前：季学森、陈锦杰、侯怡辰·推断待确认）、外部可研工程师（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 明确评测目标和验收标准 → ② 准备评测样本 → ③ 生成多版本样稿 → ④ 隐去来源做双盲 → ⑤ 专家按评分表打分并写一句话感受 → ⑥ 汇总结论，AI 解析客户修订痕迹 → ⑦ 整改项进缺陷单 → ⑧ 复测，结论归档一份评测结论（各版本得分、优劣、是否达到上线或客户审核标准），一份整改清单（负责人、截止日、复测状态），评测样本和评分表归档后可复用。待新建240
X-PRD-33产品改版数据迁移与版本切换产品结构改版（如建议书/可研拆为独立项目类型）或业务体系升级（如会员体系从单俱乐部升级为联盟级、品牌端迁移），需要把存量业务数据迁到新结构并切换到新版本主责——所属产品线产品负责人（当前：杨萌（鼎慧/Leap）、段涵（跃玩）·推断待确认）；协同——后端研发（当前：宋祺睿、蒋兴武·推断待确认）、研发核对人（当前：王皓南·推断待确认）、前端（当前：郝智豪、魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、知识库数据研发（当前：魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 迁移立项与影响面评估 → ② 产品拍板迁移规则 → ③ 编写迁移方案（含回档/回滚） → ④ 测试环境演练与对账 → ⑤ 抽检验收 → ⑥ 择时生产迁移（灰度） → ⑦ 迁移后对账巡检 → ⑧ 关闭旧逻辑并归档一份经产品签核的《数据迁移方案》、测试与生产两次迁移的数量对账记录、抽检记录、迁移后 7 天巡检报告；新版本切换完成且旧逻辑下线待新建160
X-PRD-34功能分批上线、入口隐藏与提审模式某功能的依赖（正式合同、发票、渠道系统 API、正式环境密钥）未就绪，或小程序需要过平台审核，需要拆分上线、隐藏入口或开启审核模式，待条件满足后再放开主责——产品总监（当前：杨萌·推断待确认）；协同——研发（当前：陈锦杰、魏宗浩、宋祺睿、王皓南·推断待确认）、渠道系统负责人（当前：丁震宇·推断待确认）、小程序前端（当前：郝智豪、魏小东·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、法务/财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 上线前依赖检查 → ② 判定拆分/隐藏/审核模式 → ③ 登记功能开关 → ④ 研发隐藏入口或配置审核模式 → ⑤ 验收隐藏效果 → ⑥ 依赖就绪评审 → ⑦ 放开入口并通知 → ⑧ 清理开关一张功能开关清单（每个被隐藏/延后功能的原因、依赖、放开条件、负责人、状态），以及按清单执行的上线版本或提审包待优化144
X-PRD-35产品发版/内测公告与通知分发新产品或新版本进入内测、公测、正式发布，或计费/会费等规则变更、官网变更、故障停机时，按统一模板和渠道对内（全员、市场、销售）、对外（用户、俱乐部、内测客户）发布公告与安装包/升级通知主责——产品发布负责人（当前：杨萌·推断待确认）；协同——运营宣发（当前：李凯·推断待确认）、对外口径审核（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、跃竞线对外通知（当前：徐莉·推断待确认）、研发发布（当前：王皓南·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发布就绪检查 → ② 定性（内测/公测/正式）与发布时间 → ③ 按模板起草公告 → ④ 口径、福利、保密审核 → ⑤ 按渠道表分发 → ⑥ 统一下载页更新与客户版本登记 → ⑦ 反馈收集与问题跟进审核通过并按渠道发出的公告（内部群、市场/销售群、公众号/推文、俱乐部公告、客户群），统一下载页的最新链接，以及发布记录待优化240
X-PRD-36产品手册与使用说明维护产品发版、新功能开放、客户/渠道索要使用手册，或新产品/硬件交付缺少说明时，维护用户手册、管理员手册、操作说明、授权教程和随机说明书，统一存放在知识库并保证版本一致主责——所属产品线产品经理（当前：杨萌（LeapCore/字字可研/MercAll）、段涵与陈雁（跃玩/星域/会员端）·推断待确认）；协同——手册站点开发（当前：魏小东·推断待确认）、产品使用网站（当前：宫经喜·推断待确认）、文档编写研发（当前：邓乾、李铭熙、张康·推断待确认）、销售渠道（当前：闫登辉、王满·推断待确认）、交付（当前：游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 发版或索要触发 → ② 确认手册唯一来源 → ③ 起草/更新（AI 草稿） → ④ 研发核对 → ⑤ 产品审核并标注“可外发” → ⑥ 发布到知识库/帮助中心/手册站点 → ⑦ 通知销售客服 → ⑧ 定期巡检每条产品线一套带版本号的手册（用户手册、管理员手册、更新说明），存放在唯一指定的知识库位置，并标注是否可对外分享待优化72
X-PRD-37小产品/实验产品快速内测与发布用 AI 快速做出的小产品/实验产品（如 OPC-MBTI 测评、论文工具、八字等）需要确定目的、评审数据采集需求、内部测试、收集反馈并对内外发布或上架售卖主责——小产品产品负责人（当前：杨黔昆·推断待确认）；协同——研发（当前：岳阳·推断待确认）、测试（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、运营宣发（当前：李凯、陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 一页立项（目的、用户、渠道） → ② 需求与数据采集评审 → ③ 研发部署测试链接 → ④ 产品验收+测试过一遍 → ⑤ 清理测试数据、上线前检查 → ⑥ 内测邀请+表单收反馈 → ⑦ 反馈筛选入排期 → ⑧ 对外发布/上架与售后规则一份小产品立项单、一张上线前检查表、一张内测反馈多维表格与排期结果、对外发布物料；付费产品附定价与售后条款待优化108
X-PRD-38内部业务系统建设归口与数据主责边界内部系统（CRM、渠道系统、合同系统、项目系统、金蝶、运营中台等）新建或扩功能时出现功能重复、数据冲突或多个团队各自建设，需要划定单一数据源和系统边界，统一归口建设并约定数据同步规则主责——内部系统归口负责人（当前：丁震宇·推断待确认）；协同——综合部负责人/业财主数据标准（当前：赵雪冰·推断待确认）、总经办（当前：田杰·推断待确认）、内部系统研发负责人（当前：陈子康·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、产品总监（名词统一，当前：杨萌·推断待确认）、需求方（当前：徐莉、陈梦琪、李凯、吴琪、李鹏为、杜中瑞·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 新系统/新功能需求进入统一需求池 → ② 查重与归属判定 → ③ 对照数据主责矩阵 → ④ 边界与同步规则评审 → ⑤ 财务/业务口径书面确认 → ⑥ 指定系统负责人建设 → ⑦ 迁移“先同步、再校验、后停写” → ⑧ 更新矩阵并公告一张《数据主责矩阵》（每类数据的唯一写入系统、同步方向、负责人）、一页“系统职责边界说明”（如 CRM vs 渠道系统）、统一的内部系统需求池待新建160
X-PRD-39产品使用数据统计与导出产品或业务需要用户使用数据（用户数、活跃、使用情况）做分析或汇报，需从后台导出，或把重复的导出固化为后台报表/定时推送主责——后端研发（数据导出/报表）（当前：宋祺睿·推断待确认）；协同——产品总监（需求方/口径定义，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 提交取数申请（口径、范围、用途、截止时间） → ② 判断是否已有报表 → ③ 有则自助导出 → ④ 无则研发导出并保存脚本 → ⑤ 交付结果 → ⑥ 同类需求第 2 次出现即排期固化为后台报表 → ⑦ 开通查看权限按约定口径的统计文件或后台报表/看板，以及可重复执行的导出脚本待新建36
X-PRD-40产品/研发岗位工作交接产品负责人将缺席迭代、人员调岗、新人接手，或小产品中途换负责人时，需要按交接清单移交需求、反馈、代码与资料，并经带教确认接手人能独立工作主责——交出方直属负责人（当前：产品线杨萌、研发线宋祺睿·推断待确认）；协同——交出人、接手人、研发技术负责人（当前：王皓南·推断待确认）、人事（当前：黄莹·推断待确认）、小产品接手人（当前：岳阳、杨黔昆·推断待确认）、需求发起方（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 确认交接事项与接手人 → ② 交出人按清单写交接文档 → ③ 打包仓库/账号/资料 → ④ 交接会议（文档+当面） → ⑤ 带教期跟做 → ⑥ 接手人独立完成一项任务 → ⑦ 三方确认交接完成 → ⑧ 公告并更新职责表一份经交出人、接手人、直属负责人三方确认的交接文档（含职责、需求池、反馈分流、仓库、环境、账号、待办、联系人），以及更新后的职责分工表待新建144
X-PRD-41私有化版本支持策略与旧版本停止维护LeapCore 等产品同时存在多个私有化/一体机/信创/行业版客户版本时，明确支持哪些版本、维护多久、何时强制升级、何时停止修复，并对内对外公布主责——产品总监（当前：待指定）；协同——研发负责人、交付负责人、售后负责人、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 统计在网版本分布 → ② 制定支持策略（如支持最近 N 个大版本）→ ③ 评审发布 → ④ 版本到期前通知 → ⑤ 推动升级 → ⑥ 停止维护 → ⑦ 例外审批版本支持策略文档、在网版本分布表、停止维护通知待新建96
X-PRD-42产品/功能下线（EOL）与停服通知公司决定停止某个产品、产品线、站点或付费功能（含实验产品、分站、旧网关、套餐）时，评估影响、制定迁移与退款方案、提前通知用户并有序下线主责——产品总监（当前：待指定）；协同——研发负责人、运营负责人、售后负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 下线提议 → ② 影响评估（用户、付费、合同、数据）→ ③ 决策 → ④ 迁移/退款方案 → ⑤ 提前公告 → ⑥ 停止售卖 → ⑦ 停服下线 → ⑧ 数据处置与资源释放下线决策记录、对外公告、迁移/退款完成记录、资源释放记录待新建120

X-DLV 项目交付 / 实施 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-DLV-01一体机硬件配置咨询、配置单与报价客户、销售或渠道询问 LeapCore 一体机/服务器的配置、席位并发与价格，或客户要求扩容（存储/内存/多办公点）需要重新出配置与报价时启动。主责——硬件配置与采购工程师（当前：杨明学·推断待确认）；协同——研发负责人（配置审核，当前：王皓南·推断待确认）、交付/产品负责人（售价核定，当前：杨萌·推断待确认）、后端运维（软件容量口径，当前：杨云峰·推断待确认）、销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交配置需求 → ② 套标品配置 → ③ 非标技术评估 → ④ 供应商询价核成本 → ⑤ 核定售价 → ⑥ 审核出配置单 → ⑦ 签约前报价-合同-BOM 三方核对 → ⑧ 归档与版本更新经审核、带版本号的配置单（含 BOM、成本、售价、报价有效期），写入合同附件且与采购 BOM 一致待优化192
X-DLV-02硬件供应商选型、BOM 与采购补货演示/交付需要新机型，或库存将尽、销量预测上升需要补货，或现有供应商成本偏高、起订量/供货受限需要新增供应商或自组装时启动。主责——硬件采购工程师（当前：杨明学·推断待确认）；协同——销售负责人（供应商商务谈判，当前：李鹏为·推断待确认）、交付/产品负责人（需求节奏，当前：杨萌·推断待确认）、销售（供应商对接，当前：闫登辉、杨朋伟·推断待确认）、交付部署工程师（到货装机，当前：游家豪·推断待确认）、财务（打款，当前：待指定）；决策——CEO（下单数量与金额，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 补货/选型需求 → ② 选型与 BOM → ③ 询比价（≥3 家）→ ④ 商务谈判 → ⑤ 采购评审与审批 → ⑥ 签约下单打款 → ⑦ 排期与到货跟踪 → ⑧ 到货验收入库经审批的采购单与供应商合同、留痕的询比价记录、按期到货并验收入库的设备待新建300
X-DLV-03硬件库存与资产台账维护硬件采购入库、在产、待交付、已交付、自用、租出、赠送、回收，或在公司/机房/客户处之间上下架运输时，统一更新库存与资产台账及看板。主责——交付部署工程师（库存管理员，当前：游家豪·推断待确认）；协同——硬件采购工程师（采购与到货，当前：杨明学·推断待确认）、交付/产品负责人（交付表与看板，当前：杨萌·推断待确认）、后端运维（渠道系统库存接入，当前：宋祺睿·推断待确认）、财务（资产对账，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 到货入库登记 → ② 状态流转登记 → ③ 关联订单/客户 → ④ 出库与运输记录 → ⑤ 回收入库 → ⑥ 每周盘点与看板更新 → ⑦ 每月与财务对账一张以设备序列号为主键、与订单和客户关联的库存/资产台账，以及按机型、按状态拆分的库存看板待优化192
X-DLV-04出货排期、机器调配与延期通知多个订单抢机、库存不足、供应商延期或硬件故障，需要决定发货优先级与机器分配、处理销售预定留机、向销售/客户发出延期或承诺变更通知时启动。主责——交付/产品负责人（排期统筹，当前：杨萌·推断待确认）；协同——硬件采购工程师（库存与到货，当前：杨明学·推断待确认）、交付部署工程师（装机部署，当前：游家豪·推断待确认）、销售负责人（发货报备、先款后货特批、承诺变更，当前：李鹏为·推断待确认）、销售（当前：杨朋伟、杜中瑞、刘昱潇·推断待确认）、模型网关研发（压测，当前：柯逸飞·推断待确认）；决策——CEO（库存优先原则，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 每周排期会更新库存与到货 → ② 新订单可交性评估并回复交付日 → ③ 按优先级分配机器 → ④ 预留/调拨/回收 → ⑤ 发货前席位与收款核对 → ⑥ 延期或承诺变更判定 → ⑦ 通知销售与客户 → ⑧ 回写台账每台机器有明确的订单归属与承诺交付日；延期与承诺变更有审批记录和书面通知待新建300
X-DLV-05样机/演示机借用与演示环境管理销售、渠道、展会需要借用龙智/源核等样机或演示机，或需要配置高质量演示环境（演示、跑分、送检）时启动；不属于正式交付。主责——样机管理员（当前：汪家诺·推断待确认）；协同——销售负责人（审批与特批，当前：李鹏为·推断待确认）、硬件运维（参展/外借出库，当前：杨明学·推断待确认）、交付部署工程师（借用栏与库存关联，当前：游家豪·推断待确认）、销售运营（SOP 维护，当前：韩诗琪·推断待确认）、测试负责人（演示环境，当前：张东郅·推断待确认）、交付/产品负责人（当前：杨萌·推断待确认）；特批——CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 判定借用类型 → ② 提交借用审批 → ③ 审批/特批 → ④ 确认库存并配置演示环境 → ⑤ 出库交接登记 → ⑥ 到期提醒 → ⑦ 归还验收 → ⑧ 台账更新每台样机有审批记录、借用人、预计与实际归还日；演示机按统一“豪华演示版”配置可用待优化96
X-DLV-06展会与大型活动现场设备保障展会、会场演示，或数百人同时使用 LeapCore 的培训/发布活动，需要准备设备、现场网络和并发容量时启动。主责——硬件与 IT 运维（当前：杨明学·推断待确认）；协同——交付/产品负责人（方案决策，当前：杨萌·推断待确认）、销售（现场演示，当前：闫登辉·推断待确认）、行政（会场网络对接，当前：侯明月·推断待确认）、交付部署工程师（打包运输，当前：游家豪·推断待确认）、CTO（容量评估，当前：丁震宇·推断待确认）、CEO（冗余标准，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 活动登记（T-14）→ ② 容量与设备评估（T-10）→ ③ 会场网络确认（T-7）→ ④ 硬件就位联调（T-7～T-3）→ ⑤ 降级预案与清单确认（T-3）→ ⑥ 打包运输（T-1）→ ⑦ 现场保障 → ⑧ 回收复盘（T+1）签核的现场保障清单（设备、网络、降级预案、负责人），活动顺利完成并回收全部设备待新建72
X-DLV-07交付订单受理、建群与派工销售/渠道为客户购买的 LeapCore 一体机（或充值、行业版）提交交付订单后，自动建专属交付群、确认信息、回复交付时间并按硬件/软件/充值/开放平台/现场分工派单。主责——交付负责人（当前：杨萌·推断待确认）；协同——交付部署工程师（部署发货总跟进，当前：游家豪·推断待确认）、硬件采购工程师（备机，当前：杨明学·推断待确认）、后端运维（实例 ID、网络配置，当前：杨云峰·推断待确认）、模型网关与计费研发（充值，当前：柯逸飞·推断待确认）、开放平台负责人（实例注册、行业版下发，当前：郭逸非·推断待确认）、研发负责人（机器人维护，当前：王皓南·推断待确认）、后端（v5 cloud，当前：宋祺睿·推断待确认）、销售提单人（当前：吴琪、闫登辉、杜中瑞、杨朋伟、刘昱潇等·推断待确认）、销售运营（现场培训，当前：韩诗琪·推断待确认）、财务（收款确认，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 销售提单（必填校验）→ ② 机器人发卡片并自动建群 → ③ 群内确认订单信息与订单类型 → ④ 回复预计交付日 → ⑤ 按角色派工 → ⑥ 各节点完成即群内通知并更新状态 → ⑦ 交付培训与验收单上传 → ⑧ 关闭订单每个订单有专属交付群、完整的订单记录（状态、预计交付日、实例 ID、充值、验收单），并以验收单为准关闭待优化300
X-DLV-08交付项目台账与立项留痕出现外包项目、POC、定制化项目或市场/销售 Demo 服务器部署需求时，统一登记项目台账、确认已走商务流程、指定责任人，并做技术留痕与工时登记直至结项。主责——FDE Leader/项目业务负责人（当前：黄振锋·推断待确认）；协同——CTO（台账与评审，当前：丁震宇·推断待确认）、COO（商务，当前：常元和·推断待确认）、基座研发负责人（水利类项目，当前：望政韬·推断待确认）、硬件与 IT 运维（Demo 服务器部署，当前：杨明学·推断待确认）、总经办（工时口径与需求整理，当前：田杰·推断待确认）、综合部负责人（合规与财务视角，当前：赵雪冰·推断待确认）、PRM 开发（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 填写项目开发申请 → ② 商务确认 → ③ 立项评审与指定专班责任人 → ④ PRM/台账登记 → ⑤ Demo/服务器部署申请 → ⑥ 每周工时登记与进度更新 → ⑦ 材料与会议归档 → ⑧ 验收结项或手动结束每个项目在 PRM/台账中有唯一记录（商务状态、责任人、里程碑、工时、材料、验收单），结项后工时转运维成本待优化180
X-DLV-09交付项目启动会与客户资料收集客户合同双方盖章生效（或首款到账）后，需要拉齐双方对接人与职责、交付里程碑、开票安排，并向客户收齐数据集/业务样例/参考资料时启动主责——交付项目经理（当前：王皓南·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、商务负责人（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、业务专家（当前：王满·推断待确认）、IT 运维（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 签约生效通知 → ② 开票申请 → ③ 内部预备会定分工 → ④ 发启动会邀请与资料清单 → ⑤ 召开启动会 → ⑥ 纪要与任务下发 → ⑦ 资料签收与催办 → ⑧ 资料可用性确认并转入部署/培训启动会纪要（双方对接人表、项目 RACI、里程碑、验收口径）、客户资料签收表、已提交的开票申请、指派到人的飞书任务待新建180
X-DLV-10客户定制需求承接、拆解与排期签约客户或合作伙伴提出合同约定的交付内容，或超出标品的定制功能（账单/计费口径、账号打通、专属管理页、API Key 统计限量、客服机器人、特定模型部署等）时，从需求对齐到拆单、派工、排期、验收全程管理主责——交付需求收口人/产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、对客窗口商务负责人（当前：常元和·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、研发工程师（当前：邓乾、宋祺睿、魏宗浩·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 需求登记 → ② 合同范围核对 → ③ 可行性与技术路线评估 → ④ 范围与对客口径确定 → ⑤ 对客书面确认 → ⑥ 拆单绑迭代派工 → ⑦ 周度进度同步 → ⑧ 验收闭环客户需求登记条目（关联合同条款）+ Gitea 工单（迭代、唯一负责人、点数）+ 客户确认的范围与交付日期 + 验收记录待优化320
X-DLV-11行业版与白牌定制交付订单要求行业版、特殊 Skill/场景包，或客户/渠道要求专属品牌（名称、Logo、帮助中心、客户端安装包、管理后台）时，完成定制配置、打包发版与交付主责——交付产品负责人（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、客户端打包/OTA（当前：葛家和·推断待确认）、管理后台与部署（当前：杨云峰、宋祺睿·推断待确认）、测试（当前：李国庆、张东郅·推断待确认）、行业 Skill 提供（当前：陈锦杰·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 订单评审识别定制项 → ② 能力评估 → ③ 素材收集 → ④ 开放平台注册企业与配置下发 → ⑤ 管理后台/客户端包定制 → ⑥ 行业 Skill 与渠道切换 → ⑦ 测试服验证 → ⑧ 放行发包 → ⑨ 定制配置归档客户可用的定制版本（品牌、帮助中心、行业 Skill 均生效）、定制检查清单验收记录、企业定制配置台账待新建240
X-DLV-12批量装机镜像（ISO/OOBE）制作与发版协同批量出货、新机型首批出货或客户要求扩容时，需要确定出厂规格、制作并验收 ISO/OOBE 镜像，并与软件发版节奏对齐主责——镜像/OOBE 负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件规格（当前：杨明学·推断待确认）、存储方案（当前：吴世豪·推断待确认）、发版（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付工程师（当前：游家豪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 出厂规格确认 → ② 预装版本冻结 → ③ ISO/OOBE 制作 → ④ 镜像验收 → ⑤ 试产 3 台 → ⑥ 批量烧录出厂 → ⑦ 规格台账登记 → ⑧ 扩容预案经验收的 ISO/OOBE 镜像（含版本说明）、出厂规格表、每台设备的规格与镜像版本记录、扩容方案待新建120
X-DLV-13一体机出厂装机、预装与测试验收新机器到货或交付订单提单后，完成来料检验、装系统、部署 LeapCore、注册充值、自动化测试与出厂检查，验证合格后发货或安排上门主责——交付工程负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、交付工程师（当前：游家豪·推断待确认）、部署研发（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付统筹（当前：杨萌·推断待确认）、网关额度（当前：柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 交付单信息收齐 → ② 到货组装与来料检验 → ③ 装系统与环境确认 → ④ 硬件→软件交接 → ⑤ 部署 LeapCore → ⑥ 注册与充值 → ⑦ 自动化测试出报告 → ⑧ 出厂检查 → ⑨ 发货/上门 → ⑩ 台账回写通过出厂检查的整机（系统、版本、席位、注册、额度、网络均就绪）、测试报告、出厂检查单、发货记录、设备台账条目待优化400
X-DLV-14设备指纹注册与平台登记每台新装/新增机器（客户、演示、测试、内部研发、集群主从）上线前，需要采集设备指纹（DMI UUID + SN / TPM）、在平台注册组织与机器、网关登记、开放平台登记组织 ID 并配置席位时启动主责——平台注册负责人（当前：杨云峰·推断待确认）；协同——交付工程师（当前：游家豪·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、网关研发（当前：柯逸飞·推断待确认）、平台配置（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、厂商对接（当前：闫登辉·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 来料指纹采集与唯一性校验 → ② 提交注册申请 → ③ 平台注册组织/机器/实例 → ④ 网关登记指纹 → ⑤ 开放平台登记组织 ID → ⑥ 席位配置 → ⑦ 机器端验证 → ⑧ 台账回写 → ⑨ 变更与注销已在 LeapUpdate、网关、开放平台三处登记且机器端验证通过的设备，指纹—机器—组织 ID—客户/用途对应台账待优化96
X-DLV-15客户组织、账号开通与额度充值交付上线前，或客户/内部提出时，为客户或设备建组织、批量导入用户与初始密码、开管理员与灰度权限、设置人均额度/容量上限、充值词元额度或席位主责——交付开通负责人（当前：宋祺睿·推断待确认）；协同——额度充值执行（当前：柯逸飞·推断待确认）、交付统筹/额度决策（当前：杨萌·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）、灰度开关（当前：侯怡辰·推断待确认）、测试（当前：李国庆·推断待确认）、IT 资产（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 提交开通申请（关联订单/用途）→ ② 额度审批 → ③ 建组织与管理员 → ④ 名单批量导入 → ⑤ 额度/容量/灰度/开关配置 → ⑥ 充值 → ⑦ 冒烟测试 → ⑧ 对客窗口验看后交付 → ⑨ 回写台账与财务同步客户管理员与成员可登录、额度与权限正确的组织；充值回执；冒烟记录；回写到订单表的开通与充值信息待优化192
X-DLV-16客户网络与远程接入配置客户设备需接入公司网关、需外网/分公司访问、云端需回连客户本地服务，或研发/售后需远程进入客户内网排障时，完成方案选型、WireGuard/frp/域名/LeapVPN 配置、客户间隔离、客户 IT 协调与访问回收主责——客户接入配置管理员（当前：游家豪·推断待确认）；协同——网关策略/IT 运维（当前：杨明学·推断待确认）、隔离方案与平台（当前：宋祺睿·推断待确认）、WG 部署（当前：杨云峰·推断待确认）、代理实例（当前：王皓南·推断待确认）、LeapVPN 管理员（当前：吴世豪·推断待确认）、对外技术窗口（当前：李铭熙·推断待确认）、现场排查（当前：望政韬·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 发客户环境要求清单 → ② 接入方案选型 → ③ 分配端口/网段并生成配置 → ④ 部署与隔离校验 → ⑤ LeapVPN 开通（如需）→ ⑥ 登记接入台账 → ⑦ 远程访问审批与配置下发 → ⑧ 客户 IT 协调与统一口径 → ⑨ 用后关闭客户设备可稳定接入且与其他客户隔离；客户接入台账（客户、机器、配置、端口、负责人、客户 IT 联系人）；每次远程访问的审批与关闭记录待新建300
X-DLV-17客户自备/第三方设备部署准入评估客户自备电脑/服务器，或市场、渠道要求在非我方硬件上部署 LeapCore/OpenClaw 时，在预约部署前完成配置、网络与需求范围的准入评估。主责——IT 运维/交付硬件负责人（当前：杨明学·推断待确认）；协同——销售对接人（当前：李鹏为·推断待确认）、部署工程师（当前：游家豪·推断待确认）、信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 销售发起准入并收客户环境确认表 → ② 对照最低配置核对 → ③ 评估授权与防破解 → ④ 判定标准/非标需求 → ⑤ 出具准入结论 → ⑥ 非标升级拍板 → ⑦ 告知客户并约部署 → ⑧ 归档审批通过的《非自有设备部署准入评估单》（结论、限制条件、免责说明），作为 X-DLV-19 部署工单的前置附件。待新建96
X-DLV-18部署方式决策与现场部署前预检合同签订后、出发现场前，确定交付方式（上门/寄送/公司装好再送），并完成硬件方案确认、客户网络与机房条件预检、关键链路（登录、网盘、计费等）在真实或等效环境的联调。主责——交付统筹（当前：杨萌·推断待确认）；协同——IT 运维/硬件负责人（当前：杨明学·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/发布（当前：宋祺睿·推断待确认）、销售对接人（当前：吴琪、韩诗琪·推断待确认）、部署工程师（当前：游家豪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 签约触发交付前检查单 → ② 硬件清单经硬件负责人确认 → ③ 决定交付方式 → ④ 客户网络/机房预检 → ⑤ staging 关键链路联调 → ⑥ 编写现场预案 → ⑦ 交付前一天预检会放行 → ⑧ 转实施放行的《交付前检查单》（硬件方案、交付方式、网络/机房条件、联调用例结果、现场预案、到场人员），作为进入 X-DLV-19 的放行凭证。待新建300
X-DLV-19客户现场/远程部署实施与上门安排订单通过交付前检查（X-DLV-18）后，排外勤并上门或远程完成 LeapCore/一体机装机部署、端口/内网/账号/配置下发、联调演示、培训与验收；也覆盖已交付设备的远程修复、搬迁与现场维护。主责——交付部署负责人/IT 运维（当前：杨明学·推断待确认）；协同——部署工程师（当前：游家豪·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、后端/发布与远程运维（当前：宋祺睿·推断待确认）、交付统筹（当前：杨萌·推断待确认）、项目牵头研发（当前：李铭熙·推断待确认）、高级部署（当前：望政韬·推断待确认）、销售/项目经理（当前：韩诗琪、闫登辉、杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 交付工单排班 → ② 约客户与外出审批 → ③ 公司内按《软件部署手册》装机自测 → ④ 物料与出发 → ⑤ 现场/远程部署与配置下发 → ⑥ 账号开通与交接 → ⑦ 联调演示与培训 → ⑧ 验收单 → ⑨ 复盘与回流客户可正常使用的 LeapCore 环境（访问地址、管理员账号、安装包已交付）、签字或回执验收单、部署记录（版本、IP、端口、配置、远程通道）、培训录像（如有）与复盘记录。待优化400
X-DLV-20集群版交付部署客户集群硬件到货或需扩展从机（sub 节点）时，完成上电联网、IP 下发、设备身份注册（TPM/指纹）、主从关联、OOBE 交付与席位配置。主责——LeapCore 部署研发（当前：杨云峰·推断待确认）；协同——后端/v5 云端（当前：宋祺睿·推断待确认）、部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 到货/扩容登记并指派 → ② 客户侧上电联网说明 → ③ 云端配置身份与 IP、注册指纹 → ④ 主机部署与 OOBE → ⑤ 从机预部署 → ⑥ 角色关联与席位配置 → ⑦ 两轮验收 → ⑧ 发货/接入与记录主从节点均注册并关联的集群、OOBE 完成、席位按合同配置、两轮验收全部 PASS 的记录、客户侧操作说明。待新建160
X-DLV-21客户模型/API 能力接入与本地 NewAPI 维护客户需要使用海外模型/搜索、指定自有云算力或本地定制模型接入 LeapCore，或客户本地独立部署的 NewAPI 需要同步价格、峰谷配置、新模型并提供调用示例时。主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——上游渠道维护/IT 运维（当前：杨明学·推断待确认）、客户环境配置研发（当前：李铭熙·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售（当前：闫登辉·推断待确认）、远程环境/WG（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAgent 研发（当前：岳阳·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 销售填确认信息表 → ② 技术评估与路由方案 → ③ 分批上线计划拆任务 → ④ 上游渠道接入 → ⑤ 客户本地 NewAPI 配置 → ⑥ 测试 → ⑦ 调用示例、接入文档与知情书 → ⑧ 对客与异常初判 → ⑨ 变更同步核对客户可用的模型清单与渠道配置、调用示例与接入文档、客户环境配置清单（地址、访问方式、同步项）、必要的体验受限知情书；每次调价/上新后的同步核对记录。待优化180
X-DLV-22OpenClaw/龙虾批量装机与上门部署客户采购盒子/Mac mini 需批量预装 OpenClaw/ClawLite/LeapAgent，或政企客户要求上门安装"龙虾"并演示/科普时，完成安装包获取、批量预装、API 与飞书/微信绑定、Skill 与 Logo 定制、测试和交付。主责——部署工程师（当前：游家豪·推断待确认）；协同——安装包与镜像（当前：杨明学·推断待确认）、安装包与绑定教程（当前：李铭熙·推断待确认）、ClawLite 维护与人设/API（当前：邓乾·推断待确认）、容器与环境变量（当前：杨云峰·推断待确认）、销售对接（当前：闫登辉、李鹏为·推断待确认）、上门讲解与部署（当前：李子遥、魏宗浩·推断待确认）、交付需求方（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求清单与免责确认 → ② 定方案与唯一负责人 → ③ 从统一出处取版本化安装包 → ④ 跑通样机并写参数表 → ⑤ 批量写盘/安装 → ⑥ 逐台测试入台账 → ⑦ 解绑移交或上门部署 → ⑧ 需求与问题回流按台账逐台通过测试的设备（版本、Skill、绑定、Logo 符合需求）、客户签收/验收单、移交拉群或绑定完成记录、更新后的部署包。待新建240
X-DLV-23离线/私有化部署包准备与预演客户要求本地化/国产化/内网离线部署或 POC 时，在出发前完成可行性评估、测试环境申请、依赖梳理、按目标架构打包镜像/模型/rpm、同款环境离线预演与放行，并推进一键化部署。主责——IT 运维/镜像打包负责人（当前：杨明学·推断待确认）；协同——业务研发（当前：李玄冰、葛家和·推断待确认）、基座研发/部署（当前：望政韬·推断待确认）、架构评估（当前：陈晖·推断待确认）、部署工程师（当前：游家豪·推断待确认）、后端/部署（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、商务（当前：杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 离线可行性问卷 → ② 评估与承接决定 → ③ 申请同款测试环境 → ④ 梳理依赖与配置 → ⑤ 按目标架构打包 → ⑥ md5 校验与离线预演 → ⑦ 测试文档与手册 → ⑧ 放行通过放行清单的离线部署包（镜像/模型/rpm/一键脚本/配置模板，含 md5）、预演记录、测试文档与用户手册、推荐配置。待新建180
X-DLV-24离线/私有化项目现场部署实施项目到交付节点，把知识库/RAG/ChatBI/大模型/文档解析/embedding 等部署到客户内网、离线或国产硬件，完成现场测试、验收、上线及补丁更新；含数天内紧急交付和非标本地大模型一体机。主责——交付运维负责人（当前：杨明学·推断待确认）；协同——基座研发/现场部署主力（当前：望政韬·推断待确认）、部署工程师（当前：游家豪·推断待确认）、应用研发（当前：李玄冰、张康·推断待确认）、模型部署与路由（当前：柯逸飞·推断待确认）、验收测试（当前：陈晖、黄振锋、裴蔬桐·推断待确认）、客户接口（当前：常元和、杨朋伟、李鹏为·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——CTO/项目总协调（当前：丁震宇·推断待确认）① 交付任务单与时间窗 → ② 核对放行包 → ③ 介质与入场手续 → ④ 现场部署/升级 → ⑤ 逐项测试 → ⑥ 客户验收与汇报 → ⑦ 问题回传与补丁回归 → ⑧ 文档沉淀在客户环境运行并经客户验收的系统；部署记录（版本、哈希、配置、回滚包）；遗留问题清单与反馈表；更新后的部署文档。待优化375
X-DLV-25信创/国产算力适配与厂商协同客户、渠道或厂商联合宣发提出信创/国产算力要求（国产 CPU/OS/GPU/一体机），需要确定适配版本、完成测试、向厂商升级问题并统一对外"是否已适配"口径时启动主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、产品总监（当前：杨萌·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求登记 → ② 定适配版本、负责人与 DDL → ③ 拿机/备环境 → ④ 打包与部署测试 → ⑤ 厂商问题登记与升级 → ⑥ 出测试结论并更新适配矩阵 → ⑦ 对外口径同步适配矩阵中一条"平台×产品×版本×结论"记录、信创测试报告、厂商问题跟踪记录，以及可直接转给销售/市场的适配口径待新建400
X-DLV-26客户现场准入材料准备要进入国企、央企、军队或涉密客户的生产环境部署前，需要准备人员入场材料和软件准入材料时启动主责——项目交付负责人（当前：丁震宇·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、部署工程师（当前：游家豪、张康、邓乾·推断待确认）、基座研发（当前：望政韬·推断待确认）、法务（当前：待指定）、人事（当前：待指定）；兜底——研发条线负责人（当前：丁震宇·推断待确认）① 获取客户准入要求 → ② 拆成人员/软件/合规三类清单 → ③ 私密收集人员材料 → ④ 生成组件依赖清单与安全说明 → ⑤ 合规材料（算法备案号等）核对 → ⑥ 打包提交客户 → ⑦ 安排考试/登记并归档客户认可的准入材料包（人员登记、电子签、考试记录、组件依赖清单/SBOM、安全加固说明、算法备案信息）和准入名单待新建150
X-DLV-27客户 POC/演示环境搭建与交付销售演示后客户要求限期 POC，或客户领导来演示/验收，需要拉研发定方案、搭演示/试用环境、按意见修改并交付甲方时启动主责——POC 实施负责人/FDE Leader（当前：黄振锋·推断待确认）；协同——销售/客户对接（当前：刘昱潇、杨朋伟·推断待确认）、研发排期（当前：王皓南·推断待确认）、Skill 研发（当前：李凯·推断待确认）、演示环境部署（当前：望政韬、魏宗浩·推断待确认）、Demo 开发（当前：裴蔬桐·推断待确认）、数据入库（当前：李玄冰·推断待确认）、现场支持（当前：杨明学·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① POC 立项登记 → ② 技术评估与方案选型 → ③ 与客户确认截止、验收口径 → ④ 搭环境与开发 → ⑤ 需求—功能对表与内部彩排 → ⑥ 交付甲方并出测试报告 → ⑦ 收集反馈与商务跟进可访问的 POC/演示环境、使用文档或演示视频、POC 测试报告，以及客户书面/记录在案的验收意见待优化375
X-DLV-28客户培训与使用手册准备产品交付上线或阶段验收后，需要给客户（管理员/员工）做使用培训，并准备手册、视频、演示场景时启动主责——培训总负责人/产品总监（当前：杨萌·推断待确认）；协同——培训主讲/业务专家（当前：王满·推断待确认）、客户经理（当前：吴琪·推断待确认）、研发讲师（当前：杨云峰、岳阳·推断待确认）、文档站维护（当前：杨黔昆·推断待确认）、交付研发（当前：宋祺睿·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 与客户约培训（验收后） → ② 指定主讲与材料负责人 → ③ 研发内部培训交付人员 → ④ 准备手册/视频/演示场景 → ⑤ 彩排与流程跑通 → ⑥ 客户培训执行 → ⑦ 收集反馈并更新手册分角色用户手册（管理员/员工）、操作讲解视频、培训演示脚本、培训签到与反馈记录待优化120
X-DLV-29交付签收单、验收单与开票跟进硬件或软件交付到客户后，需要用签收单/验收单/交接单取得客户书面确认、回收原件、上传系统，作为开票和回款依据时启动主责——硬件交付收口/部署工程师（当前：游家豪·推断待确认）；协同——IT 运维/发货（当前：杨明学·推断待确认）、客户经理/销售（当前：吴琪、常元和、闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）① 按合同取模板生成单据 → ② 随货寄送签收单 → ③ 客户签收盖章并回寄 → ④ 软件验收单签署 → ⑤ 核对原件 → ⑥ 上传渠道系统并通知财务 → ⑦ 财务按合同阶段开票 → ⑧ 纸质原件归档客户签字盖章的签收单/验收单（电子版已上传渠道系统、纸质原件归档），以及据此开出的发票待优化240
X-DLV-30交付服务承诺口径（保修、运维边界、客户须知）硬件随软件销售或批量出货前，需要统一保修时长、运维主体与远程售后边界、客户侧注意事项与免责声明时启动；或发生客户误操作导致离线等责任争议后需要补口径时启动主责——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、研发（当前：杨云峰、王皓南、宋祺睿·推断待确认）、销售与渠道（当前：李鹏为、闫登辉、常元和·推断待确认）、法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 收集待决问题 → ② 对齐厂商保修信息 → ③ 开会定运维主体与售后边界 → ④ 起草客户须知与免责声明 → ⑤ 法务审阅 → ⑥ 发布并写入合同/交付单据 → ⑦ 交付时签署并贴机身标签《交付服务承诺口径》一页纸（保修时长、运维主体、远程售后范围、收费情形）、《客户使用须知与免责声明》（交付时客户签署）、机身标签/二维码待新建80
X-DLV-31已交付设备与客户信息登记归档每交付一台 LeapCore 或项目交付完成后，登记设备与客户的唯一信息源（指纹、渠道、客户全称、版本、管理员地址、Skill 下发），归档客户材料与验收单，并在客户反馈问题时据此定位设备与交付人主责——部署工程师/设备登记（当前：游家豪·推断待确认）；协同——交付 SOP 统筹（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、企业更新与设备指纹（当前：宋祺睿、杨云峰·推断待确认）、模型网关与计费（当前：柯逸飞·推断待确认）、IT/硬件交付（当前：杨明学·推断待确认）、销售（当前：吴琪、杨朋伟·推断待确认）；兜底——产品总监/交付 SOP 统筹（当前：杨萌·推断待确认）① 成单写入交付订单表 → ② 部署后登记设备（指纹、版本、IP、渠道） → ③ 行业版到开放平台登记 → ④ 补管理员地址等交付信息并同步客户 → ⑤ 上传验收单与材料 → ⑥ 订单—设备关联校验 → ⑦ 定期核对与离线跟进一张以设备 ID 为主键、与交付订单关联的"已部署设备台账"（唯一信息源），以及按项目归档的客户交付材料待优化192
X-DLV-32已交付/演示机版本升级与回退新版本发布后要给客户机、演示机、伙伴机推送更新，或次日要交付/演示需确认机器已在可用版本上，并在升级失败时回退主责——发版/运维（当前：宋祺睿·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、部署工程师/现场（当前：游家豪·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 确定升级范围与优先级 → ② 预检（在线、环境变量、磁盘、依赖） → ③ 分批推送 → ④ 探测验证 → ⑤ 失败回退 → ⑥ 修复后重推 → ⑦ 更新升级状态表目标机器全部处于可用版本（或已回退到上一稳定版本），升级状态表记录每台机器的版本、结果与遗留问题待新建108
X-DLV-33已交付客户扩容与加席位变更已交付 LeapCore 一体机/系统的客户要求加席位、多开账号、升级扩容或自行加装内存，或内部核对发现客户系统席位与合同/席位表不一致时启动主责——交付统筹（当前：杨萌·推断待确认）；协同——LeapCore 部署/后端工程师（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、IT 运维/硬件负责人（当前：杨明学·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、后端/运维发版（当前：宋祺睿·推断待确认）、销售（当前：吴琪、李鹏为·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 受理变更申请 → ② 核对合同席位与硬件规格 → ③ 按政策判定（是否允许/席位上限/是否收费）→ ④ 审批 → ⑤ 远程改席位或返厂扩容 → ⑥ 通知客户并验证 → ⑦ 登记席位台账已生效且与合同一致的席位配置、更新后的席位台账记录、客户确认记录（收费时附补充合同/订单）待新建180
X-DLV-34交付期现场问题反馈与故障闭环交付/驻场期间（尚未验收转入常规售后），客户反馈系统异常（解析失败、问答超时、推理服务不可用、显卡/驱动掉线、IP 变化、系统慢）或提出优化需求时启动，直到问题关闭并正式回复客户主责——现场交付工程师（当前：游家豪·推断待确认）；协同——项目负责人（当前：丁震宇·推断待确认，定口径与优先级）、IT 运维/现场排查（当前：杨明学·推断待确认）、研发对接人（当前：李玄冰、张康·推断待确认）、商务/合同（当前：闫登辉·推断待确认）、客户关系（当前：常元和·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 统一入口登记 → ② 分级 → ③ 健康检查与日志收集 → ④ 研发定位根因 → ⑤ 修复封包或临时方案 → ⑥ 现场部署验证 → ⑦ 按口径回复客户 → ⑧ 沉淀根因并关闭已关闭的问题登记记录（含根因、处理方式、修复版本）、客户正式回复、必要时的新版本包与更新后的部署/测试文档待新建400
X-DLV-35交付进度跟踪与卡点盘点交付订单从受理到客户验收期间，按“采购/装机→软件部署→测试→充值→发货/上门”逐环节接力并同步进度；每周盘点卡点与遗漏；订单激增积压时调配人力主责——交付总负责人（当前：游家豪·推断待确认）；协同——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）、IT 运维/硬件采购（当前：杨明学·推断待确认）、LeapCore 部署/网络配置（当前：杨云峰·推断待确认）、充值负责人（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、后端/订单答疑（当前：宋祺睿·推断待确认）、定制项目负责人（当前：望政韬·推断待确认）、整理纪要（当前：吴琪·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 订单入台账并倒排节点 → ② 各环节完成即改状态并同步订单群 → ③ 自动提醒下一环节 → ④ 每日逾期推送 → ⑤ 每周盘点与例会 → ⑥ 积压时调配人力 → ⑦ 验收后关闭状态实时可见的交付订单看板、每周卡点盘点清单与处理结论、定制项目周简报待优化240
X-DLV-36部署 SOP 与交付文档沉淀每次交付/部署完成后补漏，或新版本、新机型、新部署形态首次交付前，需要编写或更新部署 SOP、部署手册、使用教程、现场测试流程并组织演练时启动主责——部署 SOP 维护人（当前：杨云峰·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、研发文档作者（当前：李玄冰、张康、邓乾、望政韬·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）、技术审核（当前：王皓南·推断待确认）、测试（当前：张东郅·推断待确认）、商务口径（当前：闫登辉·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 识别更新需求 → ② 分工并按模板起草 → ③ 技术审核 → ④ 非作者演练 → ⑤ 修订发布并记版本 → ⑥ 放入固定空间/随包分发 → ⑦ 交付后复盘补遗固定 wiki 空间中带版本号的“部署 SOP + 使用手册 + 现场测试流程”三件套（必要时含录屏）、交付记录与变更日志待优化81
X-DLV-37交付负责人 AB 角与项目交接交付负责人/项目负责人请假、调岗、离职，或新人入职接手客户项目时启动；平时为每种交付形态和每个在做项目预设 AB 角主责——交付统筹（当前：杨萌·推断待确认）；协同——交付负责人 A 角（当前：杨云峰·推断待确认）、B 角/备选操作人（当前：宋祺睿、游家豪、杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、原/新项目负责人（当前：黄振锋、望政韬、李铭熙·推断待确认）、项目拉人方（当前：常元和·推断待确认）、开发协助（当前：张康·推断待确认）、HR（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 建 AB 角台账 → ② B 角轮流上机演练 → ③ 触发代岗或交接 → ④ 按清单准备交接包 → ⑤ 交接会与签字 → ⑥ 公告新负责人 → ⑦ 跟岗答疑与回访AB 角台账（每种交付形态/项目一名负责人 + 至少一名已实操的 B 角）、双方确认的项目交接清单、群内新负责人公告待新建128
X-DLV-38星域俱乐部商户入驻、开通与数据迁移意向电竞俱乐部/工作室确定合作后，从收集入驻材料、签约、开户，到开通会员端模块与配置、旧系统会员数据迁移、客服/接待培训并上线的全过程主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端开发（当前：张楠·推断待确认）、管理端开发（当前：陈真炎·推断待确认）、培训教学（当前：刘安达·推断待确认）、迁移方案（当前：蒋兴武·推断待确认）、会员体系（当前：林瑾鸿·推断待确认）、小程序/H5（当前：魏小东·推断待确认）、法务/财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 建档并收集入驻材料 → ② 签约 → ③ 开户与管理员开通 → ④ 会员端模块与配置 → ⑤ 旧系统数据迁移（如有）→ ⑥ 客服/接待培训 → ⑦ 上线冒烟与回访入驻台账中状态为“已上线”的商户记录（含合同、账户、模块开关、配置清单、迁移对账结果、培训记录）、商户展示素材待新建240
X-DLV-39外部数据集交付（构建验证、质检与外发保密）向外部客户交付强化学习环境、代码任务、游戏数据等数据包时启动，覆盖保密确认、制作、构建验证、反作弊与难度测试、外发审批、打包交付、客户反馈修订与成果展示主责——数据交付负责人（当前：丁震宇·推断待确认）；协同——研发/数据工程（当前：待指定）、商务（当前：待指定）、法务（当前：待指定）、外部协作者对接人（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认，与主责重合，建议另设）① 需求与保密确认 → ② 定价与分派（含外部协作）→ ③ 制作 → ④ 构建验证（x86/arm）→ ⑤ 反作弊与难度测试 → ⑥ 外发审批 → ⑦ 打包交付 → ⑧ 反馈修订与成果复盘通过构建、判分、反作弊与难度测试的数据包（含版本号、清单与校验值）、外发审批记录、客户验收反馈、成果展示材料（录屏/PDF）与 ROI 复盘结论待新建250
X-DLV-40项目结项、交付转售后移交与复盘交付项目取得验收（或标品订单完成签收）后，正式结项：资料归档、成本核算、把客户环境与承诺移交售后，并做项目复盘主责——交付负责人（当前：待指定）；协同——交付工程师、售后负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 验收确认 → ② 交付资料归档 → ③ 售后移交会 → ④ 售后签收移交清单 → ⑤ 项目成本与工时核算 → ⑥ 复盘 → ⑦ 交付群转售后群/关闭结项报告、售后签收的移交清单、归档资料、复盘纪要待新建144
X-DLV-41一体机发运包装、物流保价与到货异常处理一体机、服务器、集群节点等高价值硬件需寄送客户或渠道时，按规范包装、保价发运、跟踪物流，并处理到货破损、丢件、错发主责——交付工程师（当前：待指定）；协同——行政专员、交付负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 出库核对（序列号、配件清单）→ ② 拍照留证 → ③ 规范包装 → ④ 保价下单 → ⑤ 运单同步 → ⑥ 物流跟踪 → ⑦ 到货开箱确认 → ⑧ 异常理赔与补发带序列号的发货单、开箱照片、运单号与保价凭证、客户到货确认待新建96
X-DLV-42客户现场作业规范（变更确认、操作留痕、备份回退）交付、售后、FDE 人员在客户现场或远程对客户环境做部署、升级、配置变更、数据迁移、断电重启等操作时，事前确认方案与客户同意、事中备份留痕、事后验证并可回退主责——交付负责人（当前：待指定）；协同——交付工程师、FDE 工程师、研发值班、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 变更方案与回退方案 → ② 客户确认操作窗口 → ③ 操作前备份 → ④ 按步骤操作并记录 → ⑤ 功能验证 → ⑥ 失败回退 → ⑦ 客户确认 → ⑧ 记录归档客户确认的变更单、操作记录、验证结论待新建150

X-FDE FDE 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-FDE-01非标客户项目报备与技术留痕市场/销售人员对接到任何非标或定制项目需求（无论最终是否成交）时，在留痕系统报备立项，并把后续方案、报价、案例、交付文档关联归档。主责——FDE Leader/项目部负责人（当前：黄振锋·推断待确认）；协同——各市场/销售负责人（当前：闫登辉、刘昱潇、杨朋伟、吴琪、杜中瑞、时建、朱文瑜·推断待确认）、PRM 开发支撑（当前：裴蔬桐、张康、望政韬·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 识别非标需求 → ② 提交项目开发申请 → ③ 机器人通知 → ④ 受理并分派评估人 → ⑤ 材料文档持续关联 → ⑥ 工时按项目归集 → ⑦ 状态更新与月度核对留痕台（后续为 Leap PRM）中带唯一项目编号的项目记录，挂齐需求、方案、报价、案例、交付文档、研发工时和当前状态。待优化96
X-FDE-02客户需求入口受理与分层分流FDE、客户或内部同事提出新需求（含"许愿机"群许愿）时，按 FDE → 开放平台 → 产研分层确定入口和接单人，禁止绕过分层直接向产研加塞。主责——开放平台负责人（需求统一受理口，当前：郭逸非·推断待确认）；协同——FDE 负责人（当前：李凯·推断待确认）、许愿机项目组总负责人（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、内部需求接单人（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 统一表单提需求 → ② 受理分类 → ③ FDE 层先解 → ④ 开放平台层评估 → ⑤ 产研每周评审 → ⑥ 指定接单人并回执 → ⑦ 状态播报、验收关闭需求池中每条需求都有来源、类型、优先级、接单人、状态；需求方收到受理回执和最终结果。待新建135
X-FDE-03客户需求澄清、可行性评估与技术答复客户提出技术问题、系统打通或新需求（含客户自拟的长篇需求文档）时，由 FDE 澄清范围、验证可行性、编写内部版/外部版文档后统一答复，不提前承诺。主责——FDE 负责人（需求评估，当前：李凯·推断待确认）；协同——项目经理/销售（当前：杨朋伟、闫登辉、刘昱潇·推断待确认）、开放平台（当前：郭逸非·推断待确认）、商务负责人（对外材料审核，当前：常元和·推断待确认）、技术顾问（当前：望政韬·推断待确认）、IT 公共账号管理（当前：游家豪·推断待确认）、总助（第三方资质申请，当前：赵雪冰·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 受理并约定答复时间 → ② 写内部版需求摘要 → ③ FDE 逐项评估 → ④ 索取样例 → ⑤ Demo 验证 → ⑥ 第三方账号/API 登记 → ⑦ 写外部版答复 → ⑧ 商务审核后发送并留痕内部版需求摘要、需求评估单、Demo/录屏（如需）、经审核的外部版答复或需求文档，并关联到 X-FDE-01 项目记录。待新建240
X-FDE-04定制项目技术方案、硬件选型报价与内部审核行业版或本地化部署客户需要技术方案与报价时，设计方案、按并发/模型规模/国产化要求选型硬件并询价，对外发出前经一审、二审。主责——FDE Leader/项目部负责人（方案报价一审，当前：黄振锋·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、方案研发（当前：邓乾·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、开放平台（当前：郭逸非·推断待确认）、硬件/算力评估（当前：杨明学、望政韬·推断待确认）、标品对接（当前：杨萌、王皓南·推断待确认）；兜底——研发负责人/CTO（二审，当前：丁震宇·推断待确认）① 需求清单定稿 → ② 技术路线评估 → ③ 方案初稿 → ④ 硬件选型与询价 → ⑤ 编制报价 → ⑥ AI 预审 → ⑦ 一审/二审 → ⑧ 客户技术确认并留痕经审核的技术方案、硬件 BOM 与报价单、审查报告，对外发送并关联到 X-FDE-01 项目。待优化400
X-FDE-05FDE 人员派驻、调配与项目交接客户场景落地需要 FDE 派驻、项目人手不足、人员转岗或换项目时，申请并安排 FDE 派驻或借调/外包补位，完成背景交接与权限管理；需要引入外包或合作公司人员（驻场或远程）参与研发、测试，涉及协议、工位、账号、仓库权限与交付范围时也走本流程。主责——FDE 部门负责人（人力调配，当前：郭逸非·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、接收方负责人（当前：黄振锋、王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapCore FDE（当前：李凯·推断待确认）、人事负责人（当前：黄莹·推断待确认）、法务负责人（当前：李瑶·推断待确认）、技术对接人（外包监工，当前：岳阳·推断待确认）、权限开通负责人（当前：宋祺睿·推断待确认）、行政（工位，当前：待指定）、财务（付款主体，当前：待指定）；决策——CEO（外包合作形式与付费主体，当前：邴龙志·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提交派驻/借调/外包申请 → ② 查负荷看板选人（外包面试确认）→ ③ 外包确定合作形式与付费主体 → ④ 书面通知接收方与本人 → ⑤ 签协议与保密协议 → ⑥ 外包定首期范围与接口文档 → ⑦ 新任 FDE 模拟交付 → ⑧ 按清单交接 → ⑨ 最小化开通权限与工位 → ⑩ 入场培训 → ⑪ 周更负荷与验收、结束回收已审批的派驻/借调/外包记录、确认回执、已签合作协议与保密协议（外包/借调）、首期范围与接口文档（外包研发）、交接清单、权限开通与回收记录、人力负荷看板更新。待新建192
X-FDE-06客户模型接入与模型路由配置服务客户因合规只能使用自有 API 或本地算力，或希望降低模型成本时，由 FDE 远程/上门接入客户模型、配置各档位路由规则，并出具成本或体验影响说明。主责——LeapCore 网关/标品技术负责人（当前：王皓南·推断待确认）；协同——模型网关实施（当前：柯逸飞·推断待确认）、adapter 开发（当前：宋祺睿·推断待确认）、Agent 约束（当前：岳阳·推断待确认）、商务（当前：闫登辉、杨萌·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 售前识别 → ② 客户填信息表 → ③ 适配评估 → ④ 降本测算（如需）→ ⑤ 商务确认与知情书 → ⑥ 配置路由/代理 → ⑦ 测试切换 → ⑧ 交接归档入台账客户模型接入台账记录、适配评估单、路由配置（含防覆盖脚本）、测试记录、handoff 文档；降本场景另附成本节省说明。待新建300
X-FDE-07客户业务系统数据对接的授权与限流需要对接客户内部业务系统（如投管系统、数据库）读写业务数据时，先取得书面授权、明确读写范围与限流策略，再接入并全程留痕。主责——FDE 项目技术负责人（当前：邓乾·推断待确认）；协同——项目经理（当前：杨朋伟·推断待确认）、开放平台（当前：郭逸非·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、安全/法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 取得书面授权 → ② 确认接入方式 → ③ 并发与限流设计 → ④ 鉴权设计 → ⑤ 安全评审 → ⑥ 最小化取数并登记 → ⑦ 写回经客户确认 → ⑧ 缺陷沟通与结项处置客户书面授权、接入确认单、流量调度与鉴权设计、客户数据访问日志、项目结束的数据处置记录。待新建150
X-FDE-08定制 Skill 需求承接、评估定价与交付跟进客户或内部同事提出定制 Skill 需求、内部发现可产品化的好用场景时，统一受理、查重、评估工作量与定价、排期开发、适配测试并交付跟进。主责——产品总监（Skill 需求统筹，当前：杨萌·推断待确认）；协同——Skill 交付研发（当前：邓乾·推断待确认）、Skill 开发/业务专家（当前：王满、王蕊·推断待确认）、适配测试（当前：佘天禾·推断待确认）、客户对接销售（当前：刘昱潇、杨朋伟·推断待确认）、Skill 负责人/运营（当前：李凯·推断待确认）、Skill 开发（当前：李铭熙、马漳毓、裴蔬桐·推断待确认）、容器环境（当前：岳阳、宋祺睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提交 Skill 需求单 → ② 查重复用 → ③ 评估工作量与依赖 → ④ 定价或定优先级 → ⑤ 指派开发 → ⑥ 按规范提交 → ⑦ 适配测试与补依赖 → ⑧ 内置/交付并跟进反馈Skill 需求池记录、评估单与报价审批、符合格式规范的 Skill 包与测试记录、上架/交付记录及反馈结论。待优化180
X-FDE-09行业版 Skill/插件提交审核、开放平台上架与下发FDE、行业团队、客户或第三方 SaaS 开发完成 Skill/MCP/插件，需要经 LeapOpen 开放平台审核后，按全局/行业/企业/部门范围上架或下发到客户 LeapCore 实例时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——开放平台账号与架构（当前：吴亚军·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、插件规范与开发辅导（当前：邓乾·推断待确认）、LeapCore 接入研发（当前：杨云峰、柯逸飞·推断待确认）、行业版 Skill 开发 FDE（当前：李凯、陈锦杰、季学森·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开通开发者账号/Developer Key → ② 按 LeapSkill/插件规范开发并自检 → ③ 打包提交 LeapOpen → ④ lint+Agent 初审 → ⑤ 中高风险人工二审 → ⑥ 发布并设定可见范围 → ⑦ 客户侧验证安装运行 → ⑧ 上线抽检与迭代通过审核、带签名和版本号的 Skill/插件包，已按指定 scope 对目标企业/行业可见，并在客户 LeapCore 上验证可安装可运行；下发记录可查待优化180
X-FDE-10OpenClaw/龙虾/龙智一体机部署配置交付政企客户、企业老板或俱乐部客服场景购买或要求部署 OpenClaw 智能体（龙虾）/龙智旗舰版，需要定制配置（人设、飞书多机器人、模型 Key、Skill 包、启动脚本）并接入客户工作流时启动主责——部署交付工程师（当前：游家豪、魏宗浩·推断待确认）；协同——客户经理/销售（当前：吴琪、李鹏为、闫登辉·推断待确认）、专属 FDE（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 订单与需求确认 → ② 部署方式与资源决策 → ③ 环境准备（镜像/版本/模型 Key）→ ④ 配置人设、飞书机器人与 Skill 包 → ⑤ 内部全量验收 → ⑥ 交付（上门/寄送/安装包）→ ⑦ 需求沟通会与工作流接入 → ⑧ 经验入踩坑库客户可用的 OpenClaw/龙智实例（版本固定、模型 Key 归属客户、飞书/微信通道可用），部署清单与交付确认记录，需求优先级清单与会议纪要，踩坑库更新待新建300
X-FDE-11客户试点开通、驻场陪跑与分层培训行业版进入客户试点、客户部署后“不会用”、或客户高层/政府单位需要授课时，开通席位、分层培训并安排 FDE 驻场陪跑主责——FDE 子部门负责人（当前：李凯·推断待确认）；协同——产品总监/试点统筹（当前：杨萌·推断待确认）、客户经理（当前：吴琪、闫登辉、杜中瑞·推断待确认）、驻场 FDE（当前：王满·推断待确认）、部署交付工程师（当前：游家豪·推断待确认）、人事（驻场打卡，当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 试点立项与 FDE 指派 → ② 客户需求调研 → ③ 开通席位并分配 → ④ 交付当天基础操作教学 → ⑤ 分层正式培训 → ⑥ 驻场陪跑与需求评审 → ⑦ 反馈汇总回流开发 → ⑧ 试点复盘已开通并分配的席位清单、各部门需求调研表、培训记录与资料、驻场周报、试点反馈清单与复盘结论待新建180
X-FDE-12FDE/开发者 LeapCore 调试环境与额度发放开放平台批准插件开发者入驻，或 FDE 开始真实开发，需要一个 LeapCore 调试环境和模型额度时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——云资源与运维（当前：宋祺睿·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、模型网关与渠道（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；额度政策终裁——CEO（当前：邴龙志·推断待确认）① 开发者入驻审批通过 → ② 提交环境申请 → ③ 判定环境类型与名额 → ④ 创建云端实例并发 VPN → ⑤ 发放赠送额度 → ⑥ 讲解插件调试方法 → ⑦ 登记台账 → ⑧ 到期回收开发者可登录的 LeapCore 调试实例（或本地 mock 环境）、VPN 账号、到账的赠送额度，以及环境与额度台账待新建24
X-FDE-13内部 FDE 需求挖掘、开发与验收公司内部 FDE 计划推进中各部门挖掘 AI 场景，或业务部门提出内部系统需求（合同、积分、CMS、CRM、考勤、采购等），需要澄清、开发 Skill 或业务系统并验收时启动主责——内部 FDE 统筹（当前：杨萌·推断待确认）；协同——需求评估与 Skill 验收（当前：佘天禾·推断待确认）、FDE 子部门负责人/产品设计（当前：李凯·推断待确认）、内部 FDE 开发（当前：裴建武、陈子康、邓乾、郭逸非·推断待确认）、部署运维（当前：杨睿·推断待确认）、业务拍板人（当前：田杰、赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、各部门 FDE；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；方向发起——CEO（当前：邴龙志·推断待确认）① 统一入口提需求 → ② FDE 追问澄清并画业务流程图 → ③ 分级与采纳评估 → ④ 指定负责人与排期 → ⑤ AI 拆工单并群内评审 → ⑥ 开发（Skill 或系统 MVP）→ ⑦ preview 部署与业务验收 → ⑧ 每日进度同步与按天迭代带分级和负责人的需求台账；业务确认的流程图与需求文档（需求描述＋技术约束）；通过验收的 Skill 或上线的内部系统；测试验收记录；每日进度汇总文档待优化300
X-FDE-14内部 FDE 成果评测与阶段性案例收集部门 Skill 通过验收后需验证改进效果并与竞品对比，或内部 FDE 进入阶段性周报（每周功能点对比与场景化案例）时启动主责——FDE 成果归集专员（当前：佘天禾·推断待确认）；协同——FDE 评测（当前：盛亦舒·推断待确认）、内部 FDE 统筹（当前：杨萌·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）、市场内容（当前：韩诗琪、许君·推断待确认）、各部门 FDE；兜底——CEO（当前：邴龙志·推断待确认）① 已验收 Skill 进入评测 → ② 前测后测并录屏 → ③ 与竞品对比 → ④ 结果入表并派优化 → ⑤ 收敛 Skill 输出后重测 → ⑥ 各部门按周提交功能点与案例 → ⑦ 自动统计缺口并提醒 → ⑧ 优秀案例转市场与产品评测多维表格（前后测与竞品对比结论、录屏链接）；每周各部门功能点对比、3 好 3 坏评价、场景化案例；案例转市场推文与产品改进的清单待优化90
X-FDE-15内部 FDE 与 LeapCore 培训组织及补课新工具/新能力上线、内部 FDE 阶段启动，或部分同事错过培训需要补课时，组织面向内部员工的 FDE/LeapCore 培训主责——FDE 培训主讲（当前：李凯·推断待确认）；协同——内部 FDE 统筹（当前：杨萌·推断待确认）、培训 QA 整理（当前：佘天禾·推断待确认）、研发负责人（研发参训点名，当前：丁震宇·推断待确认）、各部门 FDE；兜底——CEO（发起人，当前：邴龙志·推断待确认）① 确定主题与对象 → ② 约时间与会议室并发日程 → ③ 授课并录制妙记 → ④ 发资料包 → ⑤ 布置作业与成果展示 → ⑥ 缺课补课 → ⑦ 培训总结入 wiki培训录像与妙记纪要、资料包（PDF、教程 wiki、skill 压缩包）、参训与缺课名单、作业与成果展示记录、培训总结 wiki待优化60
X-FDE-16FDE 课程体系开发与评审面向渠道、合作伙伴、政府、高校需要分级（初/中/高级）FDE 课程，或具体开班前课程内容（PPT、实操任务、Skill 制作）需要开发与评审时启动主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——FDE 课程体系设计（当前：李凯·推断待确认）、中级大纲与讲师（当前：郭逸非·推断待确认）、高级课程（当前：黄振锋·推断待确认）、讲师（当前：陈子康、张家瑞·推断待确认）、宣传与活动（当前：陈梦琪·推断待确认）、课程框架与标准底座（当前：丁震宇·推断待确认）；兜底——CEO（需求方与终审，当前：邴龙志·推断待确认）① 需求方填课程需求单 → ② 出初版框架 → ③ 专家/开放平台研讨定稿 → ④ 讲师开发课件与实操任务（先自跑一轮）→ ⑤ 按检查表评审 → ⑥ 试讲与设备测试 → ⑦ 开课 → ⑧ 课后回流更新标准版分级课程体系文档（标准版＋本期定制版）、课件 PPT、实操任务 spec 说明书、讲稿与主持稿、评审记录、教学资料包（入 FDE 课程仓库）待优化240
X-FDE-17FDE 培训班筹备与开课保障外部 FDE 培训班（官方认证班、线下百人班、高校实训课）开课日期确定后，从立项到首课开讲、再到课后账单收口的全部筹备与保障工作。主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——培训技术统筹（当前：王皓南·推断待确认）、开放平台后端/权限（当前：杨睿·推断待确认）、交付/IT 现场支持（当前：李奎星、杨云峰·推断待确认）、IT 网络（当前：杨明学·推断待确认）、会务（当前：丁蕊·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态组（当前：陈梦琪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 立项建群定 DDL → ② 名单锁定与筛选 → ③ 师资/助教排班 → ④ 会场勘察与网络验收 → ⑤ 平台/账号/额度开通 → ⑥ 课前彩排与预案 → ⑦ 发通知并开课值守 → ⑧ 课后账单与复盘按期开课、现场环境可用的一期培训班，以及锁定名单、助教排班表、会场验收记录、账号开通台账、应急预案、培训通知、课后账单与复盘纪要。待新建250
X-FDE-18培训现场问题与学员反馈收集FDE 培训班/实训课/内部初级 FDE 培训会进行期间，需要课堂出题、收集学员现场问题（远程访问失效、文件被占用、下载挂起等）与课后反馈，并转产研修复。主责——培训班主任/AI 讲师（当前：张家瑞·推断待确认）；协同——助教/讲师（当前：梅立、杜中瑞、吴琪、李奎星·推断待确认）、产品负责人（当前：杨萌·推断待确认）、现场 oncall 研发（当前：宋祺睿、杨云峰·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 课前指定出题人与反馈表 → ② 课前环境验证 → ③ 现场登记问题 → ④ 研发判定已知/新问题 → ⑤ 现场权宜处理 → ⑥ 当日提 bug → ⑦ 课后汇总反馈与调研报告 → ⑧ 回复学员并纳入下期改进课堂题目、现场问题登记表（含诊断日志）、对应 bug 工单、课后反馈汇总与调研报告、下期改进项清单。待新建90
X-FDE-19FDE 认证考试与结课发证学员完成 FDE 初级班课程后，组织认证考试、审核成绩并颁发初级 FDE 证书；中高级认证沿用同一流程。主责——培训班主任/题库负责人（当前：张家瑞·推断待确认）；协同——FDE 课程负责人/开放平台（当前：吴亚军·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、生态组（当前：陈梦琪·推断待确认）、讲师（当前：郭逸非·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 题库设计 → ② 内部试做校验 → ③ 公布认证规则 → ④ 学员上传 Skill 并答题 → ⑤ 成绩汇总与人工复核 → ⑥ 收集邮箱并审核名单 → ⑦ 生成并邮件发证 → ⑧ 申诉处理与归档通过名单、成绩记录、已发放的初级 FDE 电子证书、申诉处理记录。待优化120
X-FDE-20内部业务系统上线内测、业务验收与发布内部自研系统（CRM、渠道系统、合同、采购等）开发完成或出新版本后，组织按岗跑测、Agent/E2E 测试提单、账号开通与使用培训、业务方验收，并发布到预览/正式环境。主责——内部系统负责人（当前：郭逸非、陈子康·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、总经办（当前：王欣、田杰·推断待确认）、各业务角色代表（销售：闫登辉、吴琪；IT：杨明学、游家豪；财务：黄梦婷；合规：赵雪冰·推断待确认）、后端/权限（当前：宋祺睿、杨睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 开发自测与 E2E → ② 出验收报告与手册 → ③ 发布预览环境并分配角色账号 → ④ 按岗跑测 + Agent 测试提单 → ⑤ 问题分级修复与复测 → ⑥ 业务验收与培训 → ⑦ 正式发布与账号开通 → ⑧ 常态化反馈业务方确认的验收记录、更新后的用户手册、正式环境可用的系统版本与已开通账号、版本更新通知、反馈表进入常态化运转。待优化240
X-FDE-21定制交付成果复用沉淀与知识产权归属确认FDE 为客户开发的 Skill、工作流、提示词、插件、脚本或行业方案交付后，确认知识产权归属与可复用范围，把可复用部分脱敏入公司资产库主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、产品经理、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 签约前约定 IP 归属 → ② 交付后成果盘点 → ③ 判定可复用范围 → ④ 脱敏与通用化 → ⑤ 入资产库 → ⑥ 评估产品化 → ⑦ 记录复用次数成果盘点表、IP 归属结论、入库的通用资产、产品化建议待新建96
X-FDE-22客户数据带离现场与开发使用审批FDE、交付、产品为开发定制 Skill、调试提示词、做评测或训练需要把客户提供的样例文件、业务数据、对话记录带回公司或上传到外部模型时，先取得授权、脱敏，限定用途并在用后销毁主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、客户对接销售、研发值班（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 识别数据与用途 → ② 客户书面授权 → ③ 内部登记审批 → ④ 脱敏 → ⑤ 指定位置存放 → ⑥ 限定用途使用 → ⑦ 到期销毁 → ⑧ 销毁确认客户授权记录、数据登记、脱敏记录、销毁确认待新建120
X-FDE-23FDE 工时登记与项目成本核算FDE 人员投入客户项目、售前 Demo、内部 FDE 与培训时，按项目登记工时，月度核算项目人力成本与收入对比，为报价校准与人员调配提供依据主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、财务专员、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 项目编码建立 → ② 每周登记工时 → ③ 周度核对 → ④ 月度汇总成本 → ⑤ 对比报价与收入 → ⑥ 偏差复盘与报价校准项目工时表、月度项目成本报表、报价校准建议待新建72

X-RCT 招聘 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-RCT-01招聘需求提报与 HC/预算/优先级管理业务或技术负责人判断需要补人、提前备人、扩招，或需要缓招、暂停、关闭岗位时，形成经审批的岗位需求和 HC 台账主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（技术岗 HC 与优先级，当前：丁震宇·推断待确认）、CEO（非技术岗与总编制，当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、用人部门负责人（当前：王皓南、杨萌、杨明学、张东郅、陈梦琪等·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 用人部门提交招聘需求单 → ② 人事查重并核对 HC 余量 → ③ 技术岗由 CTO、非技术岗由 CEO 审批（含预算带宽）→ ④ 写入 HC 台账并定优先级 → ⑤ 转入 JD 编写与挂岗 → ⑥ 每周评审优先级 → ⑦ 招满、暂停或取消时关闭岗位并通知经审批的招聘需求单；实时更新的 HC 台账（岗位、人数、优先级、预算带宽、HC 归属、状态）；每周优先级清单与 HC 周报待优化192
X-RCT-02岗位 JD 编写评审与挂网上下架岗位需求获批后需要起草或修改 JD，或岗位要挂网、更新、暂停、下架，或招聘效果差需要迭代 JD 时主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：王皓南、陈晖、杨明学、吴世豪、张东郅、葛家和等·推断待确认）、CTO（技术岗 JD 审核，当前：丁震宇·推断待确认）、CEO（非技术岗定薪区间，当前：邴龙志·推断待确认）、综合部负责人（职能岗 JD 起草，当前：赵雪冰·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、官网维护（当前：季学森·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求单获批 → ② 套用模板起草或复用旧版 → ③ 评审（职责、画像、bar、岗位名、薪资带宽）→ ④ 人事定稿，入岗位库并编版本 → ⑤ 各渠道挂岗，官网与清单同步 → ⑥ 每 2 周看效果并迭代 → ⑦ 暂停或下架时全渠道同步岗位库中带版本号的终版 JD；各渠道挂岗链接；与官网一致的《在招岗位清单》；岗位上下架记录待优化108
X-RCT-03招聘账号与签约主体管理模态、鼎慧、跃竞（协游）、子公司共用 BOSS、牛客等招聘账号时，用来决定岗位挂哪个账号、谁有权限、充值归谁、录用后与哪个主体签约，以及对候选人怎么说主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（账号注册与充值预算，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务（当前：待指定）、招聘专员（当前：张欣怡、陈雁·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求获批时确定用工/签约主体 → ② 按账号台账选定挂岗账号 → ③ JD 和沟通话术写明签约主体 → ④ 沟通、面试、Offer 全程用签约主体口径 → ⑤ 充值、VIP、道具走审批，按月汇总费用 → ⑥ 每季度复核账号和权限招聘账号与权限登记表；岗位-账号-签约主体对照；对外话术卡；月度渠道费用汇总待新建96
X-RCT-04招聘渠道拓展与招聘物料运营被动投递的量或质量不够，需要新增或调整招聘渠道（小红书、知乎、脉脉、牛客、开源社区、技术社群、官网招聘页等）、投放付费道具，或制作招聘海报、易拉宝、电梯海报、活动物料时主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（渠道付费预算和技术社区资源，当前：丁震宇·推断待确认）、技术招聘协调人（技术向文案与精准搜索，当前：陈晖·推断待确认）、运营（官网招聘页与宣发，当前：鲁周毅·推断待确认）、生态组负责人（活动现场物料，当前：陈梦琪·推断待确认）、CEO（活动资源，当前：邴龙志·推断待确认）、设计师（当前：待指定）、行政（物料张贴，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月度渠道复盘，找出缺口 → ② 提渠道/投放方案 → ③ 预算审批 → ④ AI 出文案或物料初稿，设计复核 → ⑤ 对外口径审核 → ⑥ 发布、投放、张贴，统一投递入口 → ⑦ 登记渠道效果 → ⑧ 月度复盘 ROI 并调整渠道清单与月度渠道效果表；审核通过的招聘文案和物料；统一的简历投递入口待优化108
X-RCT-05主动寻访与开源人才外联发现优秀开源作者、技术博主或行业专家，或急岗需要主动寻访，决定建联、批量邮件外联、跟进回信，并转入招聘或顾问合作时主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（批量外联审批、技术建联，当前：丁震宇·推断待确认）、技术招聘协调人（识别人才、评估，当前：陈晖·推断待确认）、外联执行人（当前：李凯·推断待确认）、文案审核（当前：郭逸非·推断待确认）、用人部门负责人（当前：王皓南、李子遥等·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记线索 → ② 匹配岗位并判断优先级 → ③ 批量外联先审核（名单、模板、退订、发送量）→ ④ 小批量试发后分批发送 → ⑤ 24 小时内分类回复 → ⑥ 有意向的转入候选人台账 → ⑦ 顾问/外包合作分流 → ⑧ 每轮活动复盘寻访线索表（来源、状态、负责人、下一步）；经审核的外联模板；每轮外联复盘（发送量、回复率、简历数、投诉数）待新建192
X-RCT-06员工内推受理与内推奖励员工推荐熟人、同学或开源圈朋友应聘公司在招岗位时，从登记、初筛、面试、回复推荐人，一直到按节点认定和发放内推奖励主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人/面试官（当前：李子遥、郭逸非、王子明、吴亚军等·推断待确认）、CTO（技术岗内推初判，当前：丁震宇·推断待确认）、CEO（制度与特殊情形认定，当前：邴龙志·推断待确认）、财务负责人（奖励随工资发放，当前：黄梦婷·推断待确认）、运营（招聘推文扩散积分，当前：鲁周毅·推断待确认）、招聘专员（当前：王丽菲、张欣怡·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 推荐人查《在招岗位清单》→ ② 填内推表单 → ③ 人事登记、查重、分发 → ④ 用人方 2 个工作日内初筛 → ⑤ 7 个工作日内优先面试 → ⑥ 结果回复推荐人 → ⑦ 按节点认定奖励 → ⑧ 公示和异议期 → ⑨ 随工资发放内推台账（推荐人、候选人、岗位、状态、奖励节点）；给推荐人的结果回复；奖励公示和发放清单待优化96
X-RCT-07简历收集、初筛与分发各渠道每个工作日进来新简历时，由人事收集、去重、入库，经 AI 快筛和硬条件过滤后分发给指定筛选人，在约定时限内拿到“约面/待定/淘汰”结论主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡、匡蓉、王丽菲·推断待确认）、岗位筛选人（当前：陈晖、望政韬、王皓南、杨明学、宋祺睿、张东郅、王子明、葛家和等·推断待确认）、CTO（技术岗筛选标准与终筛，当前：丁震宇·推断待确认）、AI 打分工具维护（当前：季学森、魏宗浩·推断待确认）、子主体负责人（当前：徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 每日从各渠道收简历 → ② 去重、规范命名、入候选人台账 → ③ AI 按岗位筛选清单打分分档 → ④ 人事按硬条件剔除 → ⑤ 推送给岗位筛选人 → ⑥ 筛选人 1 个工作日内标结论 → ⑦ 人事按结论联系候选人 → ⑧ 每周抽检 AI 结果，校准标准每份简历在候选人台账中都有岗位、来源、AI 分档、筛选人结论和日期；每日约面名单；按岗位分版本的筛选清单待优化180
X-RCT-08简历真实性核验与 AI 代答识别简历、笔试或面试中出现真实性疑点时启动，包括经历时间线冲突、GitHub/开源贡献对不上、简历含隐藏提示词或有 AI 生成痕迹、疑似代考代答、培训班包装项目、疑似竞对派遣、换身份重复投递。核验完成并给出放行/加验/淘汰结论后才继续推进主责——招聘 HR（当前：黄莹·推断待确认）；协同——技术面试官（当前：陈晖、望政韬、吴世豪、王皓南、王子明·推断待确认）、技术初筛人（当前：张楠·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、法务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 查重并标注疑点 → ② 对照红线快速判断 → ③ HR 核实基础信息 → ④ 技术核验 GitHub/作品 → ⑤ 笔试/面试中定向追问 → ⑥ 出结论（放行/加验/淘汰）→ ⑦ 留痕入台账候选人真实性核验记录（疑点、核验手段、证据、核验人、结论），候选人台账上的“放行/加验/淘汰/拉黑”标签待新建144
X-RCT-09候选人预沟通与意向登记简历通过用人方二筛或笔试初步合格后、约面前，HR 电话/微信联系候选人确认意向和基本条件，按固定字段写回台账，由用人方决定是否约面主责——招聘专员（当前：张欣怡·推断待确认）；协同——招聘助理（当前：匡蓉、陈雁·推断待确认）、用人方/面试官（当前：丁震宇、陈晖、王皓南·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 用人方提交待沟通名单与附加问题 → ② HR 按标准问题清单沟通 → ③ 结果录入台账并通知用人方 → ④ 用人方决定约面/淘汰/暂缓 → ⑤ HR 回复候选人并保温 → ⑥ 超时提醒每位候选人一条字段完整的预沟通记录，以及用人方的下一步决定待优化90
X-RCT-10笔试与技术实操考核候选人通过初筛（或预沟通）后，需要用笔试、上机题或实操题验证真实能力；也包括题库的出题、审题、改版主责——技术笔试负责人（当前：陈晖·推断待确认，需确认是否已变更）；协同——招聘 HR（当前：黄莹、张欣怡、匡蓉·推断待确认）、各岗位出题人（当前：王皓南、望政韬、张东郅、王子明、张楠、吴世豪·推断待确认）、IT 运维负责人（运维岗实操与笔试系统，当前：杨明学·推断待确认）、阅卷复核人（当前：岳阳·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 岗位绑定题目（题库维护）→ ② 确认笔试意向并查重 → ③ 按岗位批量发题 → ④ 截止提醒与回收 → ⑤ AI 预审 → ⑥ 阅卷定档 → ⑦ 结论回写并触发下一步 → ⑧ 题库复盘每位候选人的笔试档次与处置建议（面/可面可不面/暂缓入池/淘汰），按岗位、版本管理的题库与评分标准待优化180
X-RCT-11面试安排与面试官分配候选人通过预沟通或笔试、进入面试环节时，确定轮次与面试官，协调时间、线上/线下、会议室、是否带电脑，创建日程并通知到位主责——招聘专员（当前：张欣怡·推断待确认）；协同——用人部门负责人（指派面试官，当前：丁震宇、王皓南、徐莉·推断待确认）、面试官（当前：陈晖、望政韬、吴世豪、岳阳、杨云峰、魏宗浩、王子明、张楠、张东郅·推断待确认）、招聘助理（当前：匡蓉、陈雁·推断待确认）、到面接待（当前：宫经喜·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 按“岗位×轮次面试官表”确定主面/副面 → ② 查面试官空闲给出时段 → ③ 约候选人并确定线上/线下 → ④ 建日程、订会议室、发到面指引 → ⑤ 面试前 1 个工作日发资料包 → ⑥ 面试前 1 小时双向确认 → ⑦ 改期与爽约处理已发出的面试日程（标题“岗位-候选人-第 N 面”，含会议链接或会议室）、发给候选人的到面/线上指引、发给面试官的资料包待优化180
X-RCT-12面试执行、面评与晋级决策面试当天按统一规范进行（时长、摄像头、录制、内部讨论边界），结束后面试官按模板提交面评，用人部门负责人据此决定进入二面、终面、录用、入池或淘汰主责——用人部门负责人（当前：技术岗丁震宇、跃竞徐莉·推断待确认）；协同——面试官（当前：陈晖、望政韬、王皓南、吴世豪、岳阳、宋祺睿、张东郅、杨明学、魏小东、康紫馨、段涵、陈梦琪、杨朋伟·推断待确认）、招聘 HR（当前：黄莹·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 面前看资料包、按题库备题 → ② 开场规范（录制、摄像头、纪要权限）→ ③ 分阶段执行，明显不符 20 分钟内收尾 → ④ 24 小时内提交结构化面评 → ⑤ HR 汇总并提醒 → ⑥ 负责人 1 个工作日内做晋级决策 → ⑦ 回写台账并转下游每场面试一份结构化面评（维度评分、强弱项、风险、结论、建议），每位候选人一条晋级决策记录（二面/终面/录用/入池/淘汰及决策人）待优化180
X-RCT-13面试官培养与考察标准新面试官上岗、新岗位开招前考察点不清，或面试评价质量不稳定时，明确各岗位考察标准和题型，按“旁听 → 副面 → 主面”培养面试官，并定期更新面试官手册主责——面试官手册负责人（当前：王皓南·推断待确认）；协同——面试辅导人（当前：岳阳·推断待确认）、AI 实操考官（当前：季学森·推断待确认）、测试岗标准负责人（当前：张东郅·推断待确认）、人事负责人（当前：黄莹·推断待确认）、新面试官（当前：杨云峰、魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开招前建岗位考察标准卡 → ② 指定新面试官并安排旁听 → ③ 副面带教 → ④ 认证为主面 → ⑤ 面试规则与安全培训 → ⑥ HR 观摩学习 → ⑦ 每季度校准与手册更新岗位考察标准卡、面试官手册（题库 + 评分要点 + 面试规则）、面试官名册（认证状态、可面岗位）待新建36
X-RCT-14跨组面试支援与候选人转推/归属分配多个业务线（鼎慧、跃竞、AI 教育、基座、Leap、开放平台/FDE 等）同时招人，需要确定简历归属；候选人不适合本组但可能适合别组；某组缺面试官需要借调主责——人事负责人（当前：黄莹·推断待确认）；协同——各组用人负责人（当前：王皓南、王子明、徐莉·推断待确认）、被借调面试官（当前：张楠、吴世豪、葛家和、杨明学·推断待确认）、技术复筛人（当前：陈晖、望政韬·推断待确认）、招聘专员（当前：张欣怡·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 简历按岗位标签分配业务线 → ② 不对口候选人标“建议转推”与理由 → ③ 通知目标组负责人 → ④ 24 小时内回应要/不要 → ⑤ 接收组复用已有面评，只补差异轮次 → ⑥ 借调面试官登记 → ⑦ 无人接收的入人才池台账中每位候选人有明确“归属组/负责面试官”，转推与借调有记录和结论待新建48
X-RCT-15面试结果通知与不录用处理笔试、一面、二面或终面有结论后，由 HR 按时限和话术通知候选人（通过/婉拒/暂缓入池），对需要留证的不录用写明原因，对主动联系的不合适候选人礼貌回复主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡·推断待确认）、面试官（当前：陈晖、望政韬、王皓南·推断待确认）、用人部门负责人（当前：丁震宇·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 面试官只把结论交 HR，不当场拒 → ② HR 按结论类型选话术 → ③ 在时限内通知候选人（内推同时回复推荐人）→ ④ 二面及以上淘汰补写正式不录用原因 → ⑤ 流程失误时正式致歉并处理路费 → ⑥ 收集候选人反馈 → ⑦ 台账回写，入池或拉黑候选人收到的结果通知、内部留存的不录用原因（需要时）、台账状态更新（录用/淘汰/入池/拉黑）待新建120
X-RCT-16候选人台账、人才池与招聘系统维护同时推进多名候选人（全职/实习/远程/内推），需要统一登记候选人状态、面试官和面评；或候选人放弃、失联、已有别家 offer、被淘汰、暂缓时，需结案或打标签放入人才池，以便日后回捞主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、匡蓉、陈雁·推断待确认）、技术岗候选人池维护人（当前：丁震宇·推断待确认）、面试官（当前：王皓南、望政韬、岳阳、王子明·推断待确认）、招聘系统开发（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 定唯一主数据源 → ② 新简历建档并查重 → ③ 阶段变更回写 → ④ 面评挂接 → ⑤ 结案或打标签入人才池 → ⑥ 每日待跟进推送 → ⑦ 月度人才池回捞与清理一份唯一、实时的候选人主台账（含阶段、面试官、面评链接、结论与原因），可按标签检索的人才池视图，每日待跟进摘要待优化108
X-RCT-17定薪谈薪、录用审批与 Offer 发放候选人终面通过后，需要确定岗位名称、职级、用工类型与主体，核定试用期与转正薪资、补贴，完成审批并发出录用通知书主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人/面试官（当前：王皓南、杨萌、张东郅、葛家和、徐莉、王子明·推断待确认）、技术岗定薪审批人（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 面试官出分项评价 → ② HR 摸底期望与现薪 → ③ 先定职能、职级与主体 → ④ 对照薪酬带宽出方案 → ⑤ 录用审批 → ⑥ HR 单一出口谈薪 → ⑦ 录用通知书审核并邮件发出 → ⑧ 归档并更新人力成本表已审批的录用审批单（定薪理由、试用期、转正薪资、补贴、主体）、经审核并发出的录用通知书、候选人确认回执与到岗日期待优化400
X-RCT-18拟录用背景调查候选人终面通过、薪资意向谈妥并口头接受后、正式发 offer 前，按岗位风险等级核实学历、工作经历、薪资流水和离职情况；或资料中出现疑点需要追加核实主责——HR 负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：徐莉、王子明·推断待确认）、面试官（当前：葛家和、张东郅·推断待确认）、法务（当前：待指定）、背调结论决策人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 判定背调等级 → ② 取得候选人授权与材料 → ③ 材料一致性核验 → ④ 前司与学历核实 → ⑤ 疑点追加核实 → ⑥ 出背调结论表 → ⑦ 决策并归档一份背调结论表（核实项、结果、疑点、结论：通过/有条件通过/不通过），作为发 offer 的前置条件留档待新建108
X-RCT-19录用确认到入职衔接候选人接受 offer 后到入职首日之间，确认到岗日期、用工形式、挂靠团队、直属上级与带教人、座位、设备与账号，完成交接并发出入职欢迎主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、王丽菲·推断待确认）、用人部门负责人（当前：丁震宇、陈子康·推断待确认）、带教人（当前：岳阳、王皓南、杨萌、李凯·推断待确认）、座位与行政协调（当前：杨萌·推断待确认）、IT 账号开通（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 书面确认到岗日期与用工形式 → ② 定挂靠团队、直属上级与带教人 → ③ 自动派发入职任务清单 → ④ 到岗前 1 天提醒候选人 → ⑤ 首日交接给带教人 → ⑥ 首个任务与首周跟进候选人到岗确认记录、已全部关闭的入职任务清单（座位、设备、账号权限、带教人、首个任务），新人按时到岗并被带教人接住待新建144
X-RCT-20实习生、兼职与校园招聘业务组需要长期实习生、暑期实习生、远程实习生或短期兼职；或有高校合作批量实习机会、校园宣讲、熟人推荐、开源社区与黑客松等来源的实习候选人，需要快速汇总需求、筛选、简化面试并录用主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人（当前：杨萌、张东郅、陈梦琪、徐莉、李鹏为·推断待确认）、高校合作发起人（当前：邴龙志·推断待确认）、宣讲人与宣讲材料（当前：马漳毓、李铭熙、王皓南·推断待确认）、市场岗初面（当前：杨朋伟、闫登辉·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 用人部门提交实习/兼职用工申请 → ② HR 汇总需求（高校批次导出给学院）→ ③ 多渠道收简历统一入台账 → ④ HR 硬条件预筛 → ⑤ 30 分钟简化面试 → ⑥ 1 个工作日内出结论 → ⑦ 按实习生标准出薪 → ⑧ 转入职衔接实习/兼职需求汇总表、按期到岗的实习生或兼职人员（含带教人与任务说明），高校批次的岗位需求清单与反馈记录待新建72
X-RCT-21急岗推进、招聘进度同步与漏斗复盘关键岗位被定为急岗（如 Agent 负责人、Agent 全栈、子公司技术负责人、后端、产品），或业务负责人关心招聘进度、春节前/月初到岗节点需要汇总漏斗，或连续面试通过率过低需要复盘渠道和面试策略主责——HR 负责人（当前：黄莹·推断待确认）；协同——技术招聘筛选与笔试（当前：陈晖·推断待确认）、HR 招聘专员（当前：张欣怡、陈雁、匡蓉·推断待确认）、用人部门负责人（当前：王皓南、徐莉、杨萌·推断待确认）、面试官（当前：望政韬、吴世豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 定急岗等级与目标 → ② 建岗位×阶段看板 → ③ 按流水线推进（收→筛→笔试→面试）→ ④ 急岗每日、常规岗每周自动推送进度 → ⑤ 超时自动提醒 → ⑥ 节点汇总 → ⑦ 月度或触发式漏斗复盘 → ⑧ 策略调整与 HC 变更留痕实时招聘看板、急岗日报与常规周报、月度漏斗复盘纪要（数据、共性问题、调整动作）待优化180
X-RCT-22招聘团队分工与交接招聘执行人员（招聘专员、招聘助理）或岗位面试官更换、新主体或新项目组开始招聘、职责边界不清（谁筛简历、谁约面、谁谈薪、谁背调）时，重新界定分工并完成候选人与台账交接主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员/招聘助理（当前：张欣怡、匡蓉、陈雁·推断待确认）、主体业务负责人（当前：徐莉·推断待确认）、各岗位面试官（当前：王子明、张楠、魏小东、段涵、陈晖、康紫馨、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别人员变动或职责空白 → ② 更新招聘分工矩阵 → ③ 群公告置顶 → ④ 交接在途候选人与账号权限 → ⑤ 新成员开权限 → ⑥ 双方确认交接 → ⑦ 一周后回查最新版招聘分工矩阵（岗位 → 简历筛选人 → 一面 → 二面 → 谈薪人 → 背调人 → offer 发放人）、交接清单与确认记录待新建72
X-RCT-23高管与子公司负责人招聘合资公司或子公司需要总经理兼技术负责人、CTO，或需要高薪的 Agent 专家、招投标 AI 方向负责人等关键岗位，需要从需求确认、寻访到多轮高层面试、定薪与签约的完整招聘主责——高管招聘发起人/创始人兼 CTO（当前：丁震宇·推断待确认）；协同——HR 负责人（当前：黄莹·推断待确认）、技术面试官（当前：王皓南·推断待确认）、技术筛选与笔试（当前：陈晖·推断待确认）、业务方/合资方对接人（当前：常元和·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求确认与预期管理 → ② 岗位定位与 JD → ③ 多渠道寻访 → ④ 预筛与笔试 → ⑤ 多轮高层面试 → ⑥ A 级背调 → ⑦ 薪酬与股权方案审批 → ⑧ offer 与签约主体确认 → ⑨ 退出原因复盘岗位定位说明与 JD、候选人评估记录、经审批的薪酬与股权方案、签约的关键岗位人选（或退出原因复盘与下一步方案）待新建100
X-RCT-24候选人个人信息与简历数据合规管理收集、存储、转发、用 AI 筛选候选人简历与面评，以及定期删除不再需要的候选人信息时适用主责——招聘专员（当前：待指定）；协同——法务（当前：待指定）、IT 管理员（当前：待指定）、面试官（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 收集时告知与同意 → ② 统一存放与权限控制 → ③ AI 处理前脱敏或确认工具合规 → ④ 内部流转限范围 → ⑤ 定期清理 → ⑥ 候选人查询/删除请求响应候选人信息存放清单与访问权限表、AI 处理规则、定期清理记录待新建96
X-RCT-25猎头与外部招聘服务商合作及费用结算急岗、高端岗位或管理岗需要委托猎头、RPO 或其他外部招聘服务商推荐候选人，及其后续保证期与费用结算时启动主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 判断是否需要外部服务 → ② 服务商比选 → ③ 签署合作协议 → ④ 下发岗位与推荐规则 → ⑤ 候选人归属判定 → ⑥ 入职与保证期跟踪 → ⑦ 对账付款已签合作协议、服务商台账、推荐归属记录、付款与保证期记录待新建72
X-RCT-26Offer 变更、撤回与候选人未到岗处理Offer 发出后需要修改条件、因岗位冻结或背调问题撤回 Offer，或候选人延期、爽约、拒绝到岗时启动主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、行政（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 识别变更情形 → ② 评估影响与法律风险 → ③ 审批 → ④ 书面告知候选人 → ⑤ 取消入职准备 → ⑥ 更新台账与人才池 → ⑦ 启动补位书面变更/撤回通知或候选人确认记录；已取消的工位、设备、账号准备；更新后的招聘台账待新建48

X-SEC 信息安全 / IT 运维 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-SEC-01新人入职 IT 账号一站式开通与内部系统“找谁”指引新员工、实习生、借调人员确定到岗日期后，按岗位清单一次性开通 Gitea、工单、LeapCore 内部版、NewAPI 控制台、PostHog、CRM/渠道系统、企业邮箱、飞书群等账号，并在到岗当天发放“系统-负责人-申请入口”目录主责——IT 运维（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、工单系统管理员（当前：王皓南·推断待确认）、PostHog 管理员（当前：魏宗浩·推断待确认）、NewAPI 管理员（当前：柯逸飞·推断待确认）、CRM/渠道系统管理员（当前：郭逸非、陈子康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各直属上级；兜底——CTO（当前：丁震宇·推断待确认）① 入职单触发开通清单 → ② 直属上级确认岗位权限模板 → ③ 拆单派给各系统管理员 → ④ 各系统开通并安全发放凭据 → ⑤ 回填账号台账 → ⑥ 到岗当天发放“找谁”目录 → ⑦ 新人首日自检登录 → ⑧ 台账归档备回收新人到岗当天可登录全部岗位所需系统；一份按人登记的账号台账（系统、账号、权限级别、开通人、开通日期），作为离职回收依据待新建192
X-SEC-02代码仓库（Gitea）账号与仓库权限开通、重置与封禁新人、转岗、新项目、子公司或外部人员需要 Gitea 账号、组织/团队/仓库权限、SSH 公钥，或忘记密码、仓库迁入组织，或离职/违规需要封号主责——Gitea 管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、组织/仓库 Owner（当前：岳阳、王子明、李铭熙、吴世豪·推断待确认）、研发负责人（当前：王皓南·推断待确认）、人事（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交仓库权限申请 → ② 直属上级/仓库 Owner 确认范围 → ③ 管理员建号并发邀请链接 → ④ 按团队模板授权 → ⑤ 申请人配置 git 身份与公钥并验证 → ⑥ 台账登记 → ⑦ 重置/封禁按单处理 → ⑧ 季度权限盘点可用的 Gitea 账号与按最小授权配置的组织/团队/仓库权限；权限台账（账号、组织、团队、仓库、角色、期限、批准人）待优化96
X-SEC-03内部业务系统与管理后台账号/角色开通及密码重置内部同事需要 LeapCore 内部版、字字可研等产品管理后台（测试/正式）、渠道系统/CRM、LeapPPT 后台等业务系统账号或角色，或忘记密码，或需要收回超范围的管理员权限主责——业务系统 Owner（当前：字字可研后台——宋祺睿；LeapCore 内部版——杨萌；渠道系统/CRM——陈子康；LeapPPT 后台——马漳毓·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、LeapPPT 管理员分配人（当前：陈梦琪·推断待确认）、申请人直属上级；兜底——CTO（当前：丁震宇·推断待确认）① 提交系统角色申请 → ② 系统 Owner/上级审批 → ③ 飞书登录或管理员建号 → ④ 分配角色并设期限 → ⑤ 安全发放凭据 → ⑥ 台账登记 → ⑦ 到期回收 → ⑧ 季度管理员盘点申请人以本人账号按所需角色登录对应系统；系统-账号-角色台账（含临时授权到期日）待优化96
X-SEC-04企业邮箱与公共邮箱开通授权新人或项目需要个人企业邮箱；业务需要对外统一收发的公共邮箱（售后、HR、笔试、合作商、报名收集）；系统需要用公共邮箱 SMTP 发件；公共邮箱成员增减主责——人事负责人（当前：黄莹·推断待确认）；协同——飞书邮箱管理员（当前：丁震宇·推断待确认）、公共邮箱使用部门负责人；兜底——CTO（当前：丁震宇·推断待确认）① 提交邮箱申请 → ② 判断类型（个人/公共/SMTP）→ ③ 创建邮箱或加成员 → ④ SMTP 授权码安全发放 → ⑤ 登记公共邮箱负责人 → ⑥ 人员变动同步移除 → ⑦ 季度核对可用的个人或公共邮箱；公共邮箱台账（邮箱名、用途、负责人、成员、是否开 SMTP、绑定系统）待优化27
X-SEC-05内部系统接入飞书统一登录（SSO）与登录方式变更内部系统、渠道系统、云平台、PVE、网盘等要用飞书登录替代自建账号，或要撤销独立管理员账号、改变登录方式时主责——IT 运维（当前：杨明学·推断待确认）；协同——系统开发者（当前：宋祺睿、葛家和·推断待确认）、系统管理员（当前：郭逸非·推断待确认）、飞书管理员（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记接入需求 → ② 按模板创建飞书应用（最小权限）→ ③ 飞书管理员审批权限与可用范围 → ④ 测试环境验证 → ⑤ 账号迁移与独立管理员账号撤销 → ⑥ 发布登录方式变更通知 → ⑦ 更新系统登录台账系统可用飞书账号登录，独立账号已停用或封存；系统登录方式台账；登录变更通知待优化36
X-SEC-06外部协作方访问内网、联调环境与数据授权外包、外部开发团队、外部厂商、子公司外部人员、算法协作者需要测试机、联调环境、VPN、系统账号或产品数据；或公司需接入外部厂商硬件（远程 VPN/堡垒机）主责——IT 运维（当前：杨明学·推断待确认）；协同——项目对接人（当前：杨萌·推断待确认）、研发运维（当前：宋祺睿、杨云峰·推断待确认）、VPN 负责人（当前：吴世豪·推断待确认）、数据接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 对接人提交外部接入申请 → ② 法务核验保密协议 → ③ IT 运维出隔离接入方案 → ④ CTO 审批 → ⑤ 开独立、最小、限期账号 → ⑥ 限时安全分享凭据 → ⑦ 台账登记 → ⑧ 到期回收与改密外部人员在隔离环境内以独立账号访问约定资源；外部接入台账（主体、人员、资源、数据范围、保密协议、期限、对接人）；到期回收记录待新建150
X-SEC-07客户/渠道索要设备 root/管理员账号与远程接入的审批与回收客户、渠道、实施人员要求设备 root 密码、服务器账密、管理员账号找回、内网穿透、公网映射或远程使用部署在公司的设备时，按统一口径答复，例外走审批，交付后回收主责——研发负责人（当前：王皓南·推断待确认）；协同——对客人员（当前：杨萌、时建、杨朋伟、吴琪·推断待确认）、交付部署工程师（当前：游家豪、杨云峰·推断待确认）、IT 运维（当前：杨明学·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、CTO（当前：丁震宇·推断待确认）审批、CEO（当前：邴龙志·推断待确认）特例审批；兜底——CTO（当前：丁震宇·推断待确认）① 对客人员收到诉求不当场答复 → ② 按类型对照口径 → ③ 标准件按话术回复 → ④ 例外提交“客户上机/高权限”审批 → ⑤ 审批通过后限时开通 → ⑥ 登记台账 → ⑦ 到期回收改密 → ⑧ 误发应急处置客户收到统一口径答复或受控、限期的权限；客户高权限授权台账；误发后的改密与加固记录待新建225
X-SEC-08离职/试用终止/调岗账号回收与权限收口人员离职、试用/实习终止、违规处理、调岗时，按账号台账一次性回收或调整 Gitea、工单、业务系统、邮箱、飞书群、企业微信、VPN/飞连、服务器公钥等权限，并清理敏感群成员主责——IT 运维（当前：待指定）；协同——人事（当前：待指定）、Gitea 管理员（当前：宋祺睿·推断待确认）、各系统管理员、直属上级/技术负责人（当前：王子明·推断待确认）、敏感群群主；兜底——CTO（当前：丁震宇·推断待确认）① 人事异动单触发回收清单 → ② 试用终止/违规先封号 → ③ 各系统停用或降级 → ④ 共享凭据改密 → ⑤ 移出群组与敏感群 → ⑥ 调岗按新模板授权 → ⑦ 回填台账并归档 → ⑧ 月度残留盘点已关闭的回收清单（每个系统的停用时间与执行人）；更新后的账号台账；敏感群成员审计记录待新建120
X-SEC-09测试/内部环境地址与管理员账号登记交接测试服、公司内部生产服、交付预演环境（50、102、103、108、109 等）新部署、重装、重置或改密后，部署人把访问地址和管理员账号登记到统一环境台账，再按需授权给测试、产品、销售演示使用；账号丢失或被锁时也按本流程重置。主责——环境运维/部署负责人（当前：宋祺睿·推断待确认）；协同——部署工程师（当前：杨云峰、陈子康·推断待确认）、IT运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品（当前：杨萌、杨黔昆·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 部署/重置完成 → ② 凭据写入密码库环境条目 → ③ 更新环境台账 → ④ 群内发变更公告（只给台账链接） → ⑤ 使用人查台账或提交访问申请 → ⑥ 改密/重置先公告后执行 → ⑦ 每月核对与回收一张实时有效的“环境台账”（环境、地址、用途、版本、负责人、状态、对应密码库条目），以及按人授权的密码库访问记录；群聊中不再出现明文账号密码。待新建240
X-SEC-10密钥与凭据分发保管规范（禁止群内明文）凡是要在人与人之间共享账号密码、API Key、AK/SK、数据库口令、kubeconfig、镜像仓库账号、SMTP/地图/公众号等第三方密钥、生产环境变量或客户系统账号时，一律走密码库或私密通道分发并登记，禁止在群聊、私聊、截图、文档、代码里出现明文。主责——信息安全负责人（当前：待指定）；协同——IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、云与模型 Key 持有人（当前：待指定）、客户项目账号主负责人（当前：邓乾·推断待确认）、行政（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 判定凭据密级 → ② 持有人在密码库建条目 → ③ 按人/按组授权或发一次性链接 → ④ 登记凭据台账（用途、持有人、一主二备、到期日） → ⑤ 使用人从密码库取用或注入环境变量 → ⑥ 到期轮换、人员变动回收 → ⑦ 群聊明文监测与月度审计公司统一密码库（按部门/项目/环境分组）、凭据台账、按人授权记录和轮换记录；群聊明文凭据清零。待新建250
X-SEC-11凭据泄露应急处置与密钥轮换发现密钥、验证码、密码被截图外发、贴进群聊或日志、随代码提交、被过度共享、可能被 AI 读取，或 API 额度被异常用光、开发电脑中招时，立即禁用、轮换、溯源、复盘；另外每到轮换周期或发生重大节点（如保密协议生效、人员批量变动），也按本流程统一轮换。主责——信息安全负责人（当前：待指定）；协同——云与模型 Key 管理员/Gitea 管理员（当前：丁震宇·推断待确认）、IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发现并上报 → ② 定级 → ③ 止血（撤回、吊销、禁用账号） → ④ 轮换并按 X-SEC-10 重新分发 → ⑤ 溯源与影响排查 → ⑥ 恢复与解封 → ⑦ 登记复盘与整改已吊销并替换的凭据、泄露事件登记表（含时间线、影响、处置、整改项）、轮换记录；重大事件附复盘纪要。待新建240
X-SEC-12第三方平台/对外账号台账与验证码代收公司在云厂商、AI 平台、模型渠道、OCR、微信开放平台、Apple 开发者、社媒、政务申报系统等平台持有的账号，统一登记主体、实名人、绑定手机号/邮箱、管理员和使用人；验证码统一收口；账号交接、注销、欠费都按台账处理。主责——IT运维/平台账号管理员（当前：杨明学·推断待确认）；协同——CTO（现为多数平台账号持有人和收码人，当前：丁震宇·推断待确认）、总经办（当前：待指定）、财务（当前：待指定）、法务（当前：待指定）、运营（当前：吴文葶·推断待确认）、政策申报（当前：王蕊、赵雪冰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 全量盘点登记 → ② 确认主体、实名人、管理员 → ③ 凭据入密码库 → ④ 绑定迁移到公司号码/公共邮箱 → ⑤ 验证码收码设备 + 机器人分流 → ⑥ 新增、交接、注销随时登记 → ⑦ 季度核对、到期和欠费提醒一张“对外平台账号台账”（平台、主体、实名人、绑定手机号/邮箱、管理员、使用人、费用与到期），密码库中对应条目，验证码自动转发记录；不再有账号只绑在某个人的手机上。待新建200
X-SEC-14AI 编程工具订阅账号开通、充值与防封管理员工需要 Claude、Codex、GPT、Kimi 等 AI 工具订阅，或需要公司镜像账号（Sorux 等）时，统一走申请、开通、登记、月度充值、封号上报和回收；防封网络与设备配置按 IT 发布的指引执行。主责——IT运维/AI 账号负责人（当前：杨明学·推断待确认）；协同——行政（镜像订阅名单、充值、收票，当前：侯明月·推断待确认）、人事（新人统计，当前：黄莹·推断待确认）、规则与预算决策（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 按岗位选工具类型 → ② 提交 AI 工具申请（入职或月底申请） → ③ 审批工具、额度、支付方式 → ④ 开通（镜像开号 / 按防封指引代注册官方订阅 / 补贴自购） → ⑤ 登记账号台账 → ⑥ 每月 10 日统一充值和名单更新 → ⑦ 封号或风控上报、申诉退款 → ⑧ 离职或不用时回收可用的 AI 工具账号、AI 工具账号台账（使用人、类型、支付方式、到期、状态）、月度充值记录、封号事件记录，以及一份受控的《AI 账号开通与防封指引》。待优化400
X-SEC-15云平台子账号/控制台权限与 AccessKey 申请研发、测试、运维或财务在腾讯云、阿里云、火山、EdgeOne 等控制台报“无权限”，或需要子账号、AccessKey、TCR 镜像推送、CLS/COS/CAM/监控、云安全产品、账单查看等权限时，按权限包申请、授权、登记，到期回收。主责——云平台管理员（当前：丁震宇·推断待确认）；协同——备份云管理员/IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、财务（当前：黄梦婷·推断待确认）；兜底——IT运维负责人（当前：杨明学·推断待确认）① 按岗位选权限包 → ② 提交云权限申请（平台、主体、资源、权限包、期限） → ③ 审批（高危权限人工判断） → ④ 一次性授予策略包或建子账号 → ⑤ AK 经密码库交付 → ⑥ 登记权限台账 → ⑦ 到期回收与季度盘点申请人拿到可用的子账号或策略权限，AK 进密码库；云权限台账记录谁在哪个平台、哪个主体下有什么权限、到什么时候。待新建144
X-SEC-16云服务器与云资源申请开通（CVM/COS/数据库/端口/镜像仓库）研发、交付、售前或非研发同事需要公有云服务器、对象存储桶、云数据库、安全组端口或镜像仓库时，从提需求到开通、登记、到期回收的全过程主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、资源审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交“非实体资产申领”审批 → ② 资源审批人审规格与必要性 → ③ 云资源管理员按模板开通（IaC 优先）→ ④ 凭据按规范下发 → ⑤ 登记资源台账 → ⑥ 申请人验收 → ⑦ 到期提醒续用或释放已开通可用的云资源 + 审批单留痕 + 资源台账一行记录（用途/负责人/项目/到期日/费用）待优化240
X-SEC-17内网测试服务器/GPU/虚拟机/CI Runner 资源申请、SSH 开通与调度产研需要公司机房内网的测试机、GPU（5090/4090 等）、PVE 虚拟机/LXC、CI runner、共享算力机账号、磁盘或内存扩容、测试机 SSH 登录，或 IT 需要换机、重置、回收时主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——资源优先级评估人/CTO（当前：丁震宇·推断待确认）、测试环境管理人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）、共享机与体验机管理员（当前：宋祺睿、岳阳·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交内网资源申请 → ② 优先级评估与排期 → ③ 网管建机、分配 IP/端口段 → ④ 公钥授权 → ⑤ 登记资源池台账 → ⑥ 使用中巡检与限额 → ⑦ 换机/重置提前通知，到期回收可登录的内网机器/虚拟机/GPU 时段/runner + 资源池台账记录（IP、用途、占用人、环境级别、到期日）+ 变更通知记录待新建180
X-SEC-18生产资源访问申请审批与回收研发或业务人员需要登录生产服务器、访问生产或客户数据库、查生产日志、获取生产环境变量，或做生产数据备份迁移时主责——生产权限开通执行人/运维（当前：宋祺睿·推断待确认）；协同——审批人/Leap 研发负责人（当前：王皓南·推断待确认）、客户环境运维（当前：杨明学、游家豪·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交“Leap 生产资源访问申请” → ② 审批人核对资源/上下文/预期操作 → ③ 机器人建专属群 → ④ 签发限时凭证（公钥/跳板/只读账号）→ ⑤ 访问操作留痕 → ⑥ 到期自动回收并关单 → ⑦ 月度复核审批单、限时访问凭证、操作记录、回收确认、归档的专属群待优化200
X-SEC-19域名解析、SSL 证书与端口开通新服务、内部工具、演示环境上线时，需要在已备案主域名下加子域名解析、HTTPS 证书、CNAME/EdgeOne 配置、COS 跨域或安全组端口放行主责——DNS/证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人/端口审批人（当前：丁震宇·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交域名/端口变更单 → ② 校验命名、备案状态与目标 → ③ 公网端口审批 → ④ 配置解析/EdgeOne/安全组/CORS → ⑤ 自动签发证书 → ⑥ 申请人验证 → ⑦ 登记域名台账可访问的 HTTPS 域名或已放行的端口 + 域名台账记录（域名、解析目标、证书方式、负责人、备案主体）待优化48
X-SEC-20域名选购与 ICP 备案新产品、官网或对外页面（含宣传物料上的二维码链接）需要正式对外域名时启动，包括选购、按主体备案、解析与 HTTPS、旧域名迁移/301，直至可以对外使用。主责——域名与备案管理员（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、官网前端（当前：葛家和·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记域名需求 → ② 查域名台账 → ③ 查候选可注册性、价格与可备案性 → ④ 确认主体并购买 → ⑤ ICP 备案 → ⑥ 解析、HTTPS、301 → ⑦ 上线核验（含二维码） → ⑧ 登记台账并设到期提醒已备案、可访问并启用 HTTPS 的对外域名；旧域名 301 跳转；域名台账（持有主体、用途、备案号、到期日、负责人）。待新建96
X-SEC-21证书与域名到期监控续期域名、HTTPS 证书或授权证书即将或已经到期，或云厂商发来证书到期、数据库安全升级通知时主责——证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人（当前：丁震宇·推断待确认）、服务负责人（当前：按台账）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 上线即登记到期台账 → ② 优先自动续签 → ③ 每日扫描剩余天数 → ④ 到期前 30/7 天提醒 → ⑤ 续期或下线 → ⑥ 部署验证 → ⑦ 更新台账；云厂商通知 → 指派处理持续有效的证书与域名、更新后的到期台账、续期记录待新建48
X-SEC-22云资源/域名资产盘点与闲置回收（成本治理）云服务器、数据库、COS、DNS 记录、演示机数量增长，或自动续费前、账单异常、旧云账号弃用、折扣更新时的定期盘点与闲置回收主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、销毁审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 每月导出云资源与账单 → ② 与台账比对标出无主/闲置/高价 → ③ 负责人限期认领 → ④ 未认领公示 7 天 → ⑤ 关机保留 7 天 → ⑥ 审批后销毁 → ⑦ 更新台账并出成本月报月度盘点表、释放清单与审批记录、更新后的资源台账、云成本月报待新建144
X-SEC-23代码签名证书申请、保管与签名使用Windows/macOS 安装包需要代码签名，涉及证书（Windows EV、Apple 开发者）采购与 CA 复审、UKey/签名机保管、CI 签名审批、签名工具使用授权与保管人交接主责——签名资产保管人/CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、签名审批人/CTO（当前：丁震宇·推断待确认）、客户端打包负责人（当前：李铭熙·推断待确认）、主体复审联系人（当前：邴龙志·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 证书采购申请 → ② 比价付款 → ③ CA 复审/Apple 核验 → ④ UKey 入库登记、签名机部署 → ⑤ CI 打包后机器人发签名审批 → ⑥ 审批确认后按范围签名 → ⑦ 使用日志、交接与到期续期有效的代码签名证书、资产台账登记（保管人、位置、到期日）、签名审批记录与签名后的安装包待优化240
X-SEC-24办公网络接入认证、网络分区与 WiFi 密码查询新人入职、访客到访、新设备（办公电脑、服务器、打印机等 IoT）需要接入公司网络，或员工需要获取 WiFi 凭据、确认该连哪个网络时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、人事负责人（当前：待指定，负责入职指引）、行政（当前：待指定，负责访客接待）；兜底——CTO（当前：丁震宇·推断待确认）① 判定接入类型与网络分区 → ② 提交入网登记 → ③ IT 审核并绑定认证 → ④ 按身份下发凭据 → ⑤ 接入验证 → ⑥ 设备台账登记 → ⑦ 定期轮换与离职回收已完成认证绑定并可正常上网的设备；更新后的入网设备台账（MAC/IP/责任人/分区）；成文的《办公网络使用说明》（含分区用途与获取方式）待优化160
X-SEC-25远程办公与内网访问接入（飞连/VPN/IP 白名单）员工居家/出差、销售外出演示需要访问内网 LeapCore 或内部服务，研发需要从外网连测试库/测试后台/测试机，或内网多人需要互相访问本地服务联调时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——LeapVPN 负责人（当前：吴世豪·推断待确认）、后端兼运维（当前：宋祺睿·推断待确认，负责 IP 白名单/安全组）、产品总监（当前：杨萌·推断待确认，负责远程访问使用手册与对外通知）、运维/交付部署工程师（当前：游家豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交访问申请 → ② 选定接入通道 → ③ 审批 → ④ 开通（席位/激活码/白名单/端口） → ⑤ 用户按手册自检 → ⑥ 登记台账 → ⑦ 到期与离职回收可用的远程访问通道（飞连账号/LeapCore 远程访问激活码/IP 白名单/端口互通）；远程访问台账；《远程访问与外出演示使用手册》（含排查口诀与 FAQ）待优化240
X-SEC-26海外出口线路与代理节点运维研发/CI 访问 GitHub、Docker、npm、海外 AI 服务出现断流、SSL/TLS 错误、超时或流量耗尽，或需要新增域名白名单、落地 IP、节点线路、续费扩容时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，预算与方向）、CI 负责人（当前：吴世豪·推断待确认，CI 依赖域名清单）、运维/交付部署工程师（当前：游家豪·推断待确认，全员配置）、财务（当前：待指定，付款与票据）、法务（当前：待指定，合规边界）；兜底——CTO（当前：丁震宇·推断待确认）① 提交需求或故障 → ② 分类（故障/白名单/新线路/续费） → ③ 按清单排查或评估 → ④ 预算审批 → ⑤ 向运营商/供应商申请执行 → ⑥ 验证并公告 → ⑦ 更新线路台账 → ⑧ 用量监控与月度复盘可用的海外出口线路/节点；线路与白名单台账（节点、落地 IP、白名单域名、带宽、流量、到期日、费用、票据方式）；用量告警与月度用量报告；《出口线路使用规范》待新建240
X-SEC-27办公网络故障报修与恢复办公 WiFi/有线/机房出口断网、变慢、丢包、TLS 阻断，或 CI 打包机、签名机、构建集群断网，影响飞书、Gitea、CI、LeapCore 与客户演示时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，现场排查）、CI 负责人（当前：吴世豪·推断待确认，CI 机与签名机）、后端兼运维（当前：宋祺睿·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，物业/施工/线槽）、行政（当前：侯明月·推断待确认，宽带续费）、外包网络工程师团队；兜底——CTO（当前：丁震宇·推断待确认）① 自检 → ② 提交报障 → ③ 分级 → ④ 响应并群内通报 → ⑤ 分层排查 → ⑥ 临时恢复 → ⑦ 根因修复（含运营商报修） → ⑧ 恢复通知、故障登记与复盘恢复可用的办公网络；故障登记表记录（时间、位置、现象、根因、处理人、耗时）；P0/P1 故障复盘；宽带与线路资产台账；《网络自检清单》待新建500
X-SEC-28办公网络建设升级、带宽专线扩容与机房设备采购新增楼层/机房、人员增长导致带宽不足、网络长期拥堵需整体重做，或需采购防火墙/交换机/模块、新增或升级专线与商宽、服务器上架与机房搬迁时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案评审与审批）、销售负责人（当前：李鹏为·推断待确认，引荐服务商与商务谈价）、运维/交付部署工程师（当前：游家豪·推断待确认，搬运上架）、财务（当前：待指定，付款与发票）、行政（当前：待指定，场地/物业/施工协调）；兜底——CTO（当前：丁震宇·推断待确认）① 需求立项（网络需求文档） → ② CTO 评审方案 → ③ 至少 2 家服务商/运营商勘探报价 → ④ 比价谈价 → ⑤ 采购审批与合同 → ⑥ 施工排期与变更公告 → ⑦ 测试验收 → ⑧ 台账更新与限速策略公告验收通过的网络/机房改造或新增线路；网络需求文档与比价表；验收记录（测试报告、设备打标、机柜整理照片）；更新后的线路台账与硬件清单；网络使用与限速策略公告待新建200
X-SEC-29机房/服务器停机维护、迁移与故障应急（含备份与数据恢复）计划停机检修（坏盘、物业停电、网络维护）、服务器迁移与 IP 切换、安全组/防火墙规则变更，或断电、硬盘/阵列、证书过期、Redis 断连等非计划故障，以及误操作导致数据丢失需恢复、新服务器上线需确认备份时启动；同时覆盖生产数据（云数据库、对象存储、网盘、计费/订单/钱包库、网关与渠道配置）的备份定级、每日校验与定期恢复演练主责——IT 运维/网管（当前：杨明学·推断待确认，机房与硬件）；协同——后端兼运维（当前：宋祺睿·推断待确认，服务迁移/安全组/备份）、运维/交付部署工程师（当前：游家豪·推断待确认，现场与 IP 切换）、Leap 研发负责人（当前：王皓南·推断待确认，研发侧需求与验证）、产品总监（当前：杨萌·推断待确认，对销售/客户通知）、NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、行政（当前：胡则瑾·推断待确认，停电等行政通知）；兜底——CTO（当前：丁震宇·推断待确认）① 变更申请或故障发现 → ② 查服务-负责人台账评估影响 → ③ 审批与公告 → ④ 有序停机/执行或应急止血 → ⑤ 按验证清单验证 → ⑥ 恢复通知 → ⑦ 复盘与台账更新 → ⑧ 生产数据备份定级（RPO/RTO）与跨账号副本 → ⑨ 每日备份校验与每周巡检 → ⑩ 季度恢复演练与整改按时完成且已验证的变更/恢复的服务；基础设施变更单与公告；服务器资产与服务-负责人台账；故障复盘；生产数据备份清单（含 RPO/RTO、保留期、负责人）；每日备份校验与巡检记录；季度恢复演练报告待新建300
X-SEC-30IT 资产领用、设备报修与终端技术支持员工领用实体/非实体 IT 资产、电脑与会议室设备故障报修、新电脑到岗初始化、AI 开发工具与内部工具安装配置求助时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，装机与现场）、后端兼运维（当前：宋祺睿·推断待确认，AI 工具配置支持）、人事负责人（当前：黄莹·推断待确认，审批流配置）、行政（当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，会议室设备）；兜底——CTO（当前：丁震宇·推断待确认）① 提交领用/报修/装机支持单 → ② 部门负责人审批（领用类） → ③ IT 受理分派 → ④ 发放/初始化/远程或现场处理/联系厂商 → ⑤ 台账自动更新 → ⑥ 申请人确认关闭 → ⑦ 沉淀 FAQ → ⑧ 月度对账已发放并登记的资产；已修复或已转送修的设备；完成初始化的新电脑；IT 资产台账（账实相符）；IT 支持 FAQ 与标准安装脚本待优化96
X-SEC-31终端安全管控（飞连/IOA 部署、锁屏与保密规范）为满足等保、研发代码合规与远程办公安全，需要选型采购终端管控/零信任产品、开通账号、下发管控策略，或执行电脑锁屏、重要文件保管、公司账号资产梳理等终端安全规范，以及管控策略引发员工数据异常时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案决策）、人事负责人（当前：黄莹·推断待确认，规范签署与入离职席位联动）、综合部负责人（当前：赵雪冰·推断待确认，公司账号资产梳理）、产品总监（当前：杨萌·推断待确认，规范适用范围）、运维/交付部署工程师（当前：游家豪·推断待确认，终端安装）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 明确合规目标与范围 → ② 选型对比与试用 → ③ 报价审批、合同与下单 → ④ 授权核对 → ⑤ IT 小范围灰度 → ⑥ 分批推广与账号开通 → ⑦ 策略执行（锁屏/白名单/IP 绑定）与检查 → ⑧ 异常反馈与厂商工单 → ⑨ 席位随入离职增减与季度审计覆盖全员终端的管控部署；授权核对表；账号开通通知与使用教程；《终端安全与保密规范》（含锁屏、远程监护、重要文件保管）签署记录；公司账号资产表；季度终端审计报告待优化200
X-SEC-32大会/活动现场网络与设备保障公司举办生态大会、发布会、比赛等大型线下活动，各展区、大赛区、直播区、签到区需要网络、电脑、显示器等 IT 保障时启动，从需求征集一直覆盖到撤场回收主责——IT 运维（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、各展区负责人（当前：待指定）、大会会务负责人（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 表单征集需求 → ② 汇总核对库存 → ③ 与场地/运营商/直播方确认布线与分网 → ④ 需求冻结 → ⑤ 备货贴标与搬运布设 → ⑥ 现场测速 → ⑦ 现场值守 → ⑧ 撤场回收冻结版设备与网络需求清单、布线与分网方案、开场前测速记录、设备出库与回收记录待优化128
X-SEC-33飞书自建应用/机器人/CLI 权限申请审批与停用员工为自建飞书应用、机器人、飞书 CLI（含 LeapCore 内 Lark-CLI 授权）申请开放平台权限、发布新版本、调整可见范围或配置登录回调，以及停用不再使用的应用、智能体时启动主责——飞书应用审核管理员（当前：丁震宇·推断待确认）；协同——飞书管理员/人事负责人（当前：黄莹·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、应用申请人；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）① 对照权限分级表自检 → ② 规范命名后在开放平台提审并登记用途 → ③ 机器人通知审核人 → ④ 按风险等级审核（超时转备份）→ ⑤ 发版生效与授权验证 → ⑥ 登记应用台账 → ⑦ 季度盘点与停用审核通过并已发版的应用版本、应用权限台账记录（owner、scope 等级、用途、可见范围、到期日、状态）、停用记录待优化144
X-SEC-34飞书平台管理员事项（席位、功能配置、可见范围、外部分享、Aily）员工遇到飞书功能或权限配置问题、需要管理员后台操作时启动，包括席位增购与开票、审批流/知识库/会议室配置、第三方应用可见范围、跨组织分享、Aily/AI 额度与管理员角色分配，以及需要找飞书服务商顾问的情况主责——飞书管理员（当前：丁震宇·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、飞书服务商顾问（外部）；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）① 查内部飞书 FAQ → ② 提交“飞书管理员事项”工单 → ③ 管理员分类派单 → ④ 后台配置/统一咨询顾问/采购 → ⑤ 回复关单 → ⑥ 共性问题沉淀 FAQ → ⑦ 季度复核管理员角色与席位完成的后台配置或席位订单与发票、工单记录、更新后的内部飞书 FAQ、管理员角色清单待优化120
X-SEC-35敏感数据导出与 AI 分析授权（聊天记录/CRM/业务数据）员工要批量导出飞书聊天记录（个人或群聊）做 AI 分析或分身 skill、导出 CRM/渠道等业务敏感数据，或让无人值守的自动任务读取飞书凭证时，先完成数据负责人确认和安全审批主责——CTO/信息安全审批人（当前：丁震宇·推断待确认）；协同——数据所属业务负责人（如销售负责人，当前：李鹏为·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、法务负责人（当前：待指定）、人事负责人（当前：待指定）、研发运维（当前：宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交数据使用申请 → ② 按数据等级分级 → ③ 数据负责人确认 → ④ 安全审批（模型、存储、凭证）→ ⑤ 必要时法务意见 → ⑥ 按最小范围导出并脱敏 → ⑦ 约束使用与分享 → ⑧ 到期删除回填审批通过的数据使用申请单、导出记录（范围、时间、存储位置、模型）、到期删除确认待新建60
X-SEC-36新工具与高权限软件安全试用环境需要试用 ClawLite、Hermes、龙虾（OpenClaw）等需要高系统权限或来源未审查的软件，或在本机运行 AI Agent（Claude Code 等）时，先申请隔离环境并按基线配置本机与备份主责——研发运维/云资源管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，审批）、试用申请人；兜底——CTO（当前：丁震宇·推断待确认）① 判定是否需隔离 → ② 提交试用环境申请 → ③ 审批 → ④ 开通云机/虚拟机/容器并配安全组 → ⑤ 凭据私发 → ⑥ 按 Agent 本机基线试用 → ⑦ 登记试用结论 → ⑧ 到期回收带到期日的隔离测试环境、试用结论记录、回收记录；本机 Agent 配置基线与备份记录待新建48
X-SEC-37AI Agent/飞书机器人上线安全检查与权限边界在公司服务器、个人电脑或飞书群部署 OpenClaw、LeapAll、Claude Code、Qoder 等具备执行能力的 Agent/机器人，并开放给 owner 以外的人使用前，以及运行中新增能力或放宽审批时主责——AI 机器人安全负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认，审批）、Agent 研发（当前：岳阳·推断待确认，安全基线）、IT 运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认，红队测试）、机器人 owner；兜底——CTO（当前：丁震宇·推断待确认）① 注册登记 → ② 按部署基线搭建 → ③ 配置身份授权与高危二次确认 → ④ 测试群红队测试 → ⑤ 上线评审 → ⑥ 进入白名单群 → ⑦ 运行审计 → ⑧ 变更重审与下线机器人注册表记录、上线检查表（含红队测试结果）、上线审批记录、运行日志与审计记录待新建180
X-SEC-38服务器上线安全基线与对外演示暴露面检查新开公司服务器或内网机器、给客户机器交付前、在公网部署演示服务（OpenClaw、LeapCore 等）时，上线前完成口令、登录方式和端口暴露面检查并登记主责——IT 运维（当前：杨明学·推断待确认）；协同——研发运维（当前：宋祺睿·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、服务器申请人/演示环境部署人；兜底——CTO（当前：丁震宇·推断待确认）① 用基线模板开机 → ② 部署人自检 → ③ 提交公网暴露申请 → ④ 端口与弱口令扫描 → ⑤ 上线确认并登记 → ⑥ 客户机器交付加安全验收项 → ⑦ 每月复扫 → ⑧ 到期下线上线安全检查单、资产与暴露面台账、扫描报告、事件复盘记录待新建90
X-SEC-39安全扫描与渗透测试申请执行对公司自有生产/测试环境、新装机器、MCP/Agent 接入前进行安全扫描、渗透测试或红蓝对抗时，先申请授权范围，再执行、出报告并移交整改主责——安全测试执行人（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，授权审批）、研发负责人（当前：王皓南·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、跃竞运维（当前：席博田·推断待确认）、被测系统负责人；兜底——CTO（当前：丁震宇·推断待确认）① 提交测试申请（范围、环境、时间窗、手段、禁止动作）→ ② 授权审批 → ③ 准备测试账号与资产白名单 → ④ 执行扫描/渗透 → ⑤ 机器人分级推送发现 → ⑥ 复测去误报与定级 → ⑦ 出报告 → ⑧ 建工单移交 X-SEC-40测试授权单、扫描/渗透报告（分级）、漏洞工单待新建120
X-SEC-40漏洞整改闭环与对外遗留资产清理安全扫描、渗透测试、外部报告或员工发现对外服务存在未授权接口、弱口令/默认口令、密钥泄露、调试端点暴露，或发现无人认领的站点、域名、服务器时，启动“登记定级 → 修复或下线 → 复扫关闭”的闭环主责——安全整改统筹（当前：王皓南·推断待确认）；协同——安全扫描与工单跟踪（当前：魏宗浩·推断待确认）、各服务负责人（当前：宋祺睿、吴世豪、李铭熙、葛家和·推断待确认）、云账号与 DNS 管理（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·部门报送人）① 线索登记 → ② 定级与临时封堵 → ③ 认领责任人 → ④ 修复或下线 → ⑤ 复扫验证 → ⑥ 回复报告人与日报 → ⑦ 更新资产台账与复盘已关闭的漏洞工单（含定级、修复说明、复扫截图）、更新后的对外服务资产台账、遗留站点下线记录（DNS/服务/密钥/云资源/收录均已清理）待新建320
X-SEC-41高危漏洞、供应链投毒与 AI 工具安全通告应急排查外部公开高危 CVE（Linux 内核、nginx、log4j2 等）、依赖包或开发工具被投毒（npm 包、Apifox、litellm）、AI 工具被曝上传代码/.env 或收集遥测、自部署开源服务高危漏洞、外部 skill 带毒或开源协议风险时，统一研判公司是否受影响，组织排查、处置并通报结论主责——安全通告响应负责人（当前：杨明学·推断待确认）；协同——技术研判人（按技术栈指定，当前：王子明、陈晖、张楠·推断待确认）、各服务/项目负责人（当前：吴世豪、岳阳·推断待确认）、全体研发（自查）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 通告登记 → ② 研判影响与定级 → ③ 发布统一通告与排查清单 → ④ 资产比对与自查回收 → ⑤ 升级/修补/轮换凭据 → ⑥ 验证与结论通报 → ⑦ 加固规则沉淀统一安全通告、排查结果回收表（对象 × 是否受影响 × 处置结果）、结论通报、更新后的加固规则与工具准入清单待新建180
X-SEC-42内网安全事件与异常请求溯源处置内网出现异常扫描、端口爆破、疑似中毒，生产环境出现来源不明的请求或机器注册，或外部人员、云厂商发出安全告警与整改建议时，统一上报、隔离、溯源、清除并复盘主责——网络与 IT 运维（当前：杨明学·推断待确认）；协同——发现人/受影响服务负责人（当前：宋祺睿·推断待确认）、日志与研发排查（当前：吴世豪、陈晖、魏宗浩、杨云峰·推断待确认）、行政（终端装机与资产，当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 事件快报 → ② 指派与定级 → ③ 隔离止血 → ④ 日志溯源定位设备 → ⑤ 清除与恢复 → ⑥ 补齐终端防护 → ⑦ 复盘通报安全事件记录单（时间线、来源设备、处置、根因）、复盘与改进项、更新后的终端防护覆盖清单与虚拟机台账待新建120
X-SEC-43等保测评、整改与云安全产品采购产品/系统需要办理或复审等保（如鼎慧通、墨跃启智 AI 教育系统），从确定申报主体与范围、对接测评服务商、驻场测评、逐项整改、采购云安全产品、复测取证，到抽检与续费的全过程主责——等保项目经理（当前：赵雪冰·推断待确认）；协同——技术总对接与采购决策（当前：丁震宇·推断待确认）、系统整改负责人（鼎慧通当前：宋祺睿；AI 教育当前：葛家和、吴世豪·推断待确认）、技术方案（当前：王皓南·推断待确认）、开发（当前：徐鑫宇·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、产品（当前：杨萌·推断待确认）、预算审批（当前：邴龙志·推断待确认）、财务与法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 立项定主体与范围 → ② 服务商对接与资产表 → ③ 驻场测评出差距报告 → ④ 整改台账拆解与需求同步 → ⑤ 安全产品采购 → ⑥ 逐项整改留证 → ⑦ 复测与取证归档 → ⑧ 抽检与续费等保测评报告（电子版+纸质版）、整改项台账（含截图证据与复测结果）、安全产品台账（含到期日）、等保脚本仓库、证书主体与使用范围登记待优化375
X-SEC-44数据泄露（含个人信息）事件响应与报告发现或怀疑客户数据、用户个人信息、员工信息或内部敏感数据被未授权访问、外传、误发或公开暴露主责——信息安全负责人（当前：待指定）；协同——研发负责人、法务（当前：待指定）、售后负责人（当前：待指定）、总经办（当前：田杰·部门报送人）；兜底——研发负责人（当前：丁震宇·部门报送人）① 发现上报 → ② 止损隔离 → ③ 影响评估 → ④ 判定是否通知客户/用户/监管 → ⑤ 对外通知 → ⑥ 根因整改 → ⑦ 事件报告归档事件登记、影响评估报告、对外通知记录、整改清单与事件报告待新建125
X-SEC-45个人信息分类分级、保留期限与用户权利请求处理产品收集用户个人信息与客户业务数据，需要分类分级、按期删除，并响应用户或客户的查询、导出、更正、删除、注销请求主责——个人信息保护负责人（当前：待指定）；协同——法务（当前：待指定）、产品负责人（当前：待指定）、后端负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 建立个人信息清单并分级 → ② 定保留期限 → ③ 受理用户请求 → ④ 核验身份 → ⑤ 执行导出/更正/删除/注销并留痕 → ⑥ 回复用户 → ⑦ 每季度清理到期数据个人信息清单、保留期限表、用户请求处理记录、季度清理记录待新建64
X-SEC-46账号与权限定期复核每季度对高权限与关键系统账号（飞书管理员、云平台子账号与 AccessKey、Gitea 管理员与仓库权限、生产服务器 SSH、网关管理员、数据库账号、第三方平台主账号）做复核，清理离职遗留、超范围与长期未用权限主责——IT 运维负责人（当前：待指定）；协同——各系统负责人（当前：待指定）、各部门负责人、人事（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 导出各系统账号权限清单 → ② 与在职名单及岗位比对 → ③ 系统负责人与部门负责人确认 → ④ 回收/降权 → ⑤ 出复核报告季度权限复核表、回收/降权记录、复核报告待新建96
X-SEC-47全员信息安全意识培训与考核新人入职、每年度及发生安全事件后，对全员（含实习生、外包与驻场人员）进行信息安全与保密培训、考核和钓鱼演练抽测主责——信息安全负责人（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、各部门负责人；兜底——研发负责人（当前：丁震宇·部门报送人）① 制定年度培训计划 → ② 编制课件与题库 → ③ 入职培训 → ④ 年度全员培训与考试 → ⑤ 钓鱼演练抽测 → ⑥ 统计与补训培训课件与题库、培训与考试记录、演练报告、补训名单待新建80

X-OTH 其他待定 报送人：待定

编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-OTH-01上游模型/云服务供应商询价、折扣谈判与签约新增或扩量上游渠道（云厂官转、中转站、视频/生图模型厂商、云服务/软件），或供应商对接人变更、报价迟迟不出时启动主责——上游渠道采购负责人（当前：丁震宇·推断待确认）；协同——渠道运维与账户管理员（当前：杨明学·推断待确认）、合同与开户跟进人（当前：宋祺睿·推断待确认）、鼎慧主体技术负责人（当前：王皓南·推断待确认）、销售对外报价对接人（当前：闫登辉·推断待确认）、渠道接入研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求立项与询价清单 → ② 确定签约/使用账号主体 → ③ 多家询价与用量换折扣谈判 → ④ 测试额度审批与试跑 → ⑤ 合规与合同审核 → ⑥ 签约/开户/充值 → ⑦ 登记上游供应商台账并同步定价 → ⑧ 对接人与 SLA 维护已签署的折扣/代付/采购合同；上游供应商台账一行完整记录（供应商、账号主体、折扣、合同状态、对接人、SLA、到期日）；同步给网关定价与财务的折扣信息待新建300
X-OTH-02上游并发/TPM 配额提额申请与追进线上或测试出现 429/并发不足，或新模型上线、压测前需要上游提高并发/RPM/TPM 配额时启动主责——模型网关研发（当前：柯逸飞·推断待确认）；协同——上游渠道采购负责人（当前：丁震宇·推断待确认）、测试负责人（当前：张东郅·推断待确认）、模型评测/压测执行（当前：董洪焜·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 发现 429/预判容量 → ② 估算并发与 TPM → ③ 生成问题说明/申请单 → ④ 提交工单或商务群 → ⑤ 追进确认 → ⑥ 复测 → ⑦ 登记配额台账并设回收预警上游确认的新配额（并发/RPM/TPM）；复测通过记录；配额台账更新待新建144
X-OTH-03云厂商代金券与赠送额度登记及到期消耗云厂商赠送限期代金券、试用额度或配额，需要登记并在到期前按优先级合理消耗时启动主责——IT 运维/云账户管理员（当前：杨明学·推断待确认）；协同——评测任务负责人（当前：王皓南·推断待确认）、构建/部署平台研发（当前：杨云峰·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 收到券/额度即登记 → ② 设到期前 14 天/3 天提醒 → ③ 提出消耗方案 → ④ 拍板优先级 → ⑤ 执行消耗 → ⑥ 到期后关停资源并复盘代金券/额度台账记录；获批消耗方案；到期前的消耗记录与资源关停确认待新建54

跨部门断点与组织级发现

跨部门关键断点 Top 10

# 断点 涉及部门 现状表现（匿名） 建议的 SOP/机制 关联 SOP
1 需求入口多路，绕过产品直达研发 SAL、MKT、X-FDE、X-PRD、RND、管理层 销售、FDE、领导、客户各自在群聊/私聊/微信提需求；研发“不知道急的是什么”；需求、缺陷、Badcase 归类反复摇摆 唯一需求入口：所有需求经产品受理并分层（FDE→开放平台→产研），未进需求池不排期；插单走优先级评估并书面留痕 X-PRD-05、X-FDE-02、X-PRD-09、X-PRD-10、RND-01、RND-04
2 对客承诺先于产研评估 SAL、X-FDE、X-PRD、RND、X-DLV 前线单方面承诺上线时间、并发能力与定制功能，产研事后评估；标品/非标/收费口径长期不一致 “承诺前确认”闸门：非标需求、并发/性能承诺、渠道贴牌预装必须先拿到产研书面结论与报价特批 SAL-21、SAL-28、X-PRD-11、X-CS-14、X-FDE-03、SAL-25
3 合同—交付—开票脱节 SAL、LEG、X-DLV、FIN 先交付后补合同、熟人免审；合同硬件规格未经技术会签；签收单回收滞后，开票依据需逐条核实 合同多方会签（业务/技术/财务/法务）；已盖章合同是交付工单的前置条件；签收/验收单是开票与收入确认的唯一依据 LEG-03、SAL-23、X-DLV-07、X-DLV-29、FIN-19、FIN-21
4 发布与生产变更无门禁 RND、X-PRD、X-SEC、X-CS、SAL 无发布单与检查清单；hotfix 漏 pick；测试与生产环境用途靠口头，曾在生产做测试；渠道/价格变更未通知下游 封版闸门（P0 清零）+ 发布单 + 生产变更申请（备份、灰度、回滚方案）+ 发版后通知；环境分层与占用登记 RND-48、RND-50、RND-51、RND-54、RND-58、RND-71、X-SEC-18
5 客户问题无统一入口，反馈不闭环 X-CS、RND、SAL、X-DLV、X-PRD 客户问题进研发群和私聊，缺字段与复现信息；约过半用户反馈未闭环；故障常由客户先发现 售后统一受理：首响时限、信息补全模板、分类转工单、修复后回告；售后值班与产研 oncall 排班 X-CS-01、X-CS-05、X-CS-06、X-CS-13、RND-76、X-PRD-07
6 定价/成本/倍率多处配置、无单一来源 X-PRD、RND、FIN、SAL、OPS 网关、各产品、本地部署、对外价格表多处手工同步，价格静默错位，出现多扣费与成本误判；定价无财务参与 价格单一数据源 + 调价变更单（产品定价、财务审核毛利、研发配置、测试验证）+ 定期成本与账单对账 X-PRD-22、RND-69、FIN-28、RND-70、FIN-29、SAL-18
7 凭据明文流转与权限不回收 全部门、X-SEC 密码、密钥、验证码、root 口令在大量群中明文出现；外部协作与客户 root 授权无有效期；离职回收无清单 密码管理工具 + 群内禁发规则 + 最小授权与到期回收 + 泄露即轮换 X-SEC-10、X-SEC-11、X-SEC-06、X-SEC-07、X-SEC-08、X-SEC-12
8 AI 订阅、云资源、硬件采购无统一入口 RND、X-SEC、FIN、ADM 各人自购订阅与中转、个人垫付、无票支出；上游余额耗尽后才充值；供应商价格靠群聊 统一资源申请入口与台账；余额阈值预警；境外/无票支出专项流程；供应商比价与签约归口 ADM-34、X-SEC-14、RND-26、FIN-02、FIN-03、FIN-04、RND-73、X-OTH-01
9 多主体归属与制度适用不清 FIN、LEG、HR、POL、CEO 合同主体、社保发薪主体、软著/商标/资质主体、子公司制度适用范围都在事后逐次澄清 主体判定规则表（签约/采购/出货/用工/申报主体一致性），子公司服务边界清单 FIN-32、CEO-24、LEG-02、HR-04、X-RCT-03、POL-10
10 招聘到入职衔接断档 X-RCT、HR、ADM、X-SEC、用人部门 HC 与薪资口径不一；面评分散；工位、电脑、账号到岗当天才备；新人无人派活 Offer 确认即触发入职清单（行政、IT、导师、首周任务同步就绪），到岗前 2 个工作日验收 X-RCT-01、X-RCT-17、X-RCT-19、HR-05、ADM-03、X-SEC-01、HR-06

组织级发现

按影响从大到小排序。

  1. 关键人单点普遍存在，覆盖研发合并发版、IT 网络与采购、云与飞书管理权限、测试、计费充值、招聘面试、HR 等关键节点。

    • 影响：一人请假、外勤或休息就会阻塞整条链路；骨干长期过载、连续超长工时，有人离岗后项目交接“另起炉灶”。这是全年复盘里出现次数最多的问题。
    • 建议：为每条主线的关键节点建 AB 角清单；高频操作（打包发版、开号、充值、部署）先写成 SOP，再尽量交给 CI/机器人自动执行；管理员权限至少两人持有；总经办每月看一次关键人负荷。

  2. 决策和规则主要靠群聊和口头传达，没有决策记录。

    • 影响：同一问题反复讨论 3～5 次，结论多次改口；经常出现“我讲过两遍”和“从没听说”两种说法；新人和渠道查不到规则；机器人“记忆”一重启，规则就丢了。
    • 建议：重大决策统一用一张决策记录卡（选项、依据、结论、负责人、生效日）；规则只有进入制度库才算生效，群里宣布只当通知；会议纪要里的待办自动转成任务。

  3. 决策权高度集中，同时又存在多人拍板。

    • 影响：少数高管自称“人肉 RAG”“上下文炸了”，成为审批和方向判断的瓶颈；下层又常问“到底听谁的”，被授权的人自己不知道被授权，于是继续越级请示。
    • 建议：发布书面授权矩阵，按事项类型和金额分级写明谁能拍板、谁需要知会；被授权人要在飞书公告中明确；越级事项退回原路径处理。

  4. 几个关键职能长期缺位或由他人兼任：产品经理、专职测试、运维、财务、行政、售后、渠道管理。

    • 影响：研发兼运维和售后，产品负责人兼项目经理、行政和大会筹备；相关事务没人承接，或者靠“谁有空谁干”，质量门禁和客户闭环都没法建立。
    • 建议：优化期内先给每个缺位职能指定临时负责人，并裁决 X- 开头的待定归属；同步把测试、运维、售后列为招聘最高优先级。

  5. 流程大多是出了事故才补，同类问题反复发生。

    • 影响：生产访问审批、签名前置、卡密台账、上线检查、合规审核都是事故后才建立；有些配置问题已经提醒过多次，仍然重复出错；产品往往先上线，再补用户协议、内容审核和备案。
    • 建议：把上线前检查清单、合规前置评估、故障分级与复盘设为强制环节；每次 P0/P1 事故复盘都必须产出一条 SOP 修订。

  6. 信息孤岛严重：群、表、系统多头并存，群定位混乱。

    • 影响：需求同时在工作台、Gitea 和群里维护，客户信息分散在 CRM、渠道系统、台账和周报里，导致重复录入、状态不同步、检索困难。通知群、工作群和闲聊群混用，重要通知被闲聊和机器人刷屏淹没。
    • 建议：给每类数据指定唯一数据源和负责系统；公布群职能规则（通知群只发通知、工作讨论进工作群或工单、私聊结论回写）；机器人通知分级降噪。

  7. 凭据管理和信息安全意识薄弱，机器人与 Agent 权限缺乏边界。

    • 影响：几乎每个工作群都出现过明文密码、密钥和验证码；机器人部署在个人电脑上，权限可达关机、读取本地文件，已经发生提示词注入和误操作；供应链投毒、疑似中毒只能靠群里临时自查。
    • 建议：统一密码管理工具，群内禁止发送凭据并配置自动检测提醒；建立机器人台账，写明 owner、权限、作用域和上线安全检查；明确泄露后立即轮换。

  8. 资金类动作缺少审批，财务介入滞后。

    • 影响：赠送额度、内部充值、计费退补、分账调账、AI 采购和备用金经常口头决定或由研发直接操作，曾出现多扣费、超额发放和无票支出等合规风险；定价、毛利和倍率也没有财务把关。
    • 建议：凡是涉及资金或额度的动作，一律走审批单并留痕；定价与成本口径由财务复核；资金异常由财务、产品、研发三方按固定流程处置。

  9. 多主体和关联公司的边界混乱。

    • 影响：签约主体、采购和出货主体、用工和发薪主体、申报和资质主体之间经常对不上，子公司是否适用集团制度也要逐次澄清，带来税务、用工和资质合规风险，还造成大量重复沟通。
    • 建议：制定主体判定规则表和子公司服务边界清单，在合同、采购、入职、申报四个入口强制选择主体。

  10. 外部紧急交付和插单持续打断研发，工程治理一再被推迟。

    • 影响：测试体系、发版体系、服务器和 CI 治理反复让位给大会、演示和客户交付；迭代范围被压缩，周末和深夜发版成为常态，质量问题又反过来增加救火量，形成恶性循环。
    • 建议：每个迭代固定预留一部分容量做工程治理；插单必须经过优先级评估，并说明会挤掉哪些事项；对外演示统一使用冻结的稳定版本。

  11. 汇报线与职责边界不清，借调频繁。

    • 影响：有人“同时向三个人汇报”、只有虚线上级；飞书组织架构与实际管理线不一致；跨组借调没有审批，派活冲突。新人和实习生到岗后才确认归属。
    • 建议：每人只有一条实线汇报线，并与飞书架构保持一致；借调走审批，写明期限、派活人和交接人；组织调整当周就发出通知。

  12. 规则口径频繁变化，人事与薪酬类口径尤其明显。

    • 影响：AI 补贴、加班调休、实习薪资、绩效点数、内部充值要求半年内多次调整，员工反复追问，HR 和财务数据对不上，出现多发少发。
    • 建议：所有涉及员工权益的口径都在制度库里做版本管理，写明生效月份和适用主体；口径变更走 HR 制度流程，不在群里临时调整。

  13. SOP 意识已经形成，但缺统一载体、负责人和验收。

    • 影响：聊天中经常有人说“走 SOP”“记进 SOP”，但找不到入口文档；已写的 SOP 散在群公告、wiki 和个人笔记里，没人维护，也没人检查执行。
    • 建议：用本次 640 余条 SOP 建统一目录，每条写明归属、负责人、版本和验收人；SOP 入口挂到飞书工作台；每季度抽查执行情况。

  14. AI 工具与机器人已经深度嵌入日常工作，这是推动 SOP 自动化的现成基础。

    • 影响：日报生成、建单、简历初筛、告警推送、排障都已有机器人参与，但它们各自维护，规则依赖“记忆”，待办没有进入任务体系，宕机或欠费就全部中断。
    • 建议：把高频 SOP 的触发、提醒、表单和台账落到飞书审批、多维表格和统一机器人上；机器人的规则写成文档并由 owner 维护，不依赖会话记忆。

重复条目：已合并与待裁决

已在审阅后合并的重复条目（原编号的引用已自动改指向保留条目）：

原条目 并入
X-SEC-13 RND-27 模型 API Key 与调用额度申请（统一接入站）
FIN-13 HR-15 月度工资核算发放与员工个税答疑
OPS-27 MKT-18 市场运营日报与沟通记录规范
LEG-12 POL-10 软件著作权申请与权属确认
LEG-13 POL-11 专利申报（交底→技术审核→代理撰写→定稿→缴费）
POL-12 LEG-25 算法备案、办学许可、3C 认证等专项资质办理
POL-13 LEG-24 增值电信业务许可证办理与年报
RND-90 X-SEC-29 机房/服务器停机维护、迁移与故障应急（含备份与数据恢复）
ADM-37 ADM-31 IT设备故障报修
X-OTH-04 X-FDE-05 FDE 人员派驻、调配与项目交接
BRD-03 X-SEC-20 域名选购与 ICP 备案
OPS-04 X-PRD-35 产品发版/内测公告与通知分发
RND-57 X-PRD-35 产品发版/内测公告与通知分发

待两周优化期裁决的合并建议：以下主题在多个部门都写了一条，相关负责人请在优化期内共同决定“谁主谁从”。从属条目改为主条目的“分支变体”，或在场景判定中写明“请走主条目”。

主题 涉及条目 建议
AI 工具订阅、号池与补贴 X-SEC-14、RND-25、RND-26、FIN-02、GEN-09、ADM-34；HR-17、FIN-10、OPS-06 开通和号池并入 X-SEC-14；补贴并入 HR-17（财务付款、充值核对作为分支）
域名解析、证书与到期续期 X-SEC-19、X-SEC-21、X-SEC-20、LEG-23 X-SEC-20 负责购买、解析、证书和到期管理；LEG-23 负责 ICP/App 备案
日报 / 周报 CEO-12、RND-10、SAL-32、MKT-18、ADM-13 CEO-12 作为总规则，各部门作为分支变体
团建 / 年会 / 分享会 ADM-20、ADM-21、GEN-08、HR-24；GEN-07、HR-23、RND-87 合并为 ADM-20（活动）、ADM-21（年会）、GEN-07（分享会）
来访接待 ADM-06、GEN-16、MKT-10、SAL-08、ADM-07 ADM-06 作为总流程，其余作为分支；媒体来访单列为 BRD-12
工商 / 证照 / 年检 / 档案 GEN-15、FIN-38、CEO-22；ADM-23、LEG-10、GEN-14、POL-08；GEN-11、LEG-11 每组合并为 1 条，归综合部
个人信息权利请求 OPS-29、LEG-34、X-SEC-45 LEG-34 统一口径，其余改为引用
客户演示 SAL-11、SAL-12、SAL-13、RND-61、MKT-05、MKT-11、X-DLV-05、X-DLV-27、ECO-19 保留 SAL-11（执行）、SAL-12（环境）、X-DLV-27（POC），其余并入分支变体
试用 / 赠送额度 OPS-07、FIN-16、SAL-16、SAL-17、X-CS-03 保留 FIN-16（审批）和 SAL-16（试用）
定价 / 倍率 / 成本价 OPS-02、RND-69、X-PRD-22、X-PRD-23、FIN-28、SAL-18 与系统建设项对齐：价格主表 1 条 + 调价变更 1 条
计费异常 FIN-29、X-CS-09、RND-70、X-CS-24 FIN-29 为主，X-CS-09 作为客户侧分支
岗位交接 HR-27、RND-85、SAL-35、X-PRD-40、X-DLV-37、OPS-28、X-RCT-22、FIN-37、ADM-13、X-FDE-05 HR-27 作为总流程，各部门“交接清单”作为附录，不单独成条
培训营 / 大会 ECO-22～28 与 X-FDE-15～19；ECO-16～21 与 MKT-02～06 在裁定 X- 职能归属时一并决定谁主谁从
知识产权与资质归口 POL-10、POL-11、LEG-14、LEG-24、LEG-25 已按“软著、专利归政策申报，资质、备案归法务”先行合并，请管理层确认归口

自动化与系统建设清单

总览

全部 657 条 SOP 共标注了 3951 个提效步骤。按标注口径，含“🔧飞书固化”的步骤 2865 个，含“🤖自动化”的步骤 1763 个，明确保留“👤人工判断”的步骤 446 个（同一步骤可能同时带多个标记）。从状态看，待新建 353 条、待优化 300 条，已有可用流程的只有 4 条，说明大部分提效要靠新建入口、台账和提醒，而不是在已有系统上微调。需求高度重复：同一类台账、提醒和审批分散在几十条 SOP 里各自出现，逐条建设会再造一批信息孤岛，所以本章把它们合并为 30 个可立项的建设项。优先级分 ≥300 的 85 条高优 SOP 中，有 82 条已被下文建设项覆盖；未覆盖的几条属于制度和授权类，并入“共性底座”。

下表按平台统计涉及的 SOP 数和步骤数。统计方法是按步骤“工具”字段的关键词归类，一个步骤可能同时计入多个平台，数字均为约数。

平台 涉及 SOP（约） 涉及步骤（约） 主要用法
多维表格（台账/看板） 550 1130 各类台账、需求池、看板、表单收集，是使用面最广的载体
外部系统集成（CRM/财务/代码仓库/网关等） 370 740 CRM、渠道系统、代码仓库与 CI、AI 网关、管理后台、网银、电子签
飞书文档模板/知识库 375 590 模板、FAQ、口径库、制度库、交接文档
飞书机器人/自动化流程 350 490 到期/超期提醒、状态变更通知、告警推送、缺报催办
飞书审批 300 460 采购、付款、合同、用印、额度、权限、发布与变更
AI Agent/大模型助手 270 380 起草初稿、查重分类、摘要纪要、预审比对、打分初筛
日历/任务 200 280 会议纪要转任务、日程提醒、假勤、值班、汇报

建设项清单

工作量口径（建议）：S 为飞书原生配置，约 1～3 人日；M 需要多表联动、脚本或单个系统接口，约 1～3 人周；L 涉及跨系统集成或数据迁移，超过 1 人月。覆盖 SOP 按优先级分从高到低列出。

编号 建设项 平台 覆盖 SOP 解决的低效 工作量（S/M/L） 建议阶段
SYS-01 统一需求入口与需求池：唯一提需表单，群消息一键转单，AI 查重并补全验收标准，状态变化自动回告提出人，评审通过后同步工单 多维表格；机器人；AI X-PRD-05、X-DLV-10、X-FDE-13、X-PRD-10、X-PRD-29、X-PRD-04、X-PRD-09、RND-04 等 13 条 需求从群聊、私聊多路进入，绕过产品直达研发；重复需求无人合并；提出人得不到结论 M 两周内
SYS-02 客户问题统一受理与反馈闭环：反馈群机器人追问缺失字段，分级后匹配 FAQ，转缺陷或需求工单，修复后回告客户；售后值班排班 机器人；多维表格；外部（工单） X-CS-05、X-DLV-34、X-CS-12、X-CS-06、X-PRD-07、X-CS-23、X-CS-01、X-CS-10 等 18 条 客户问题散落在研发群和私聊里，缺复现信息；约过半反馈未闭环；故障常由客户先发现 M 两周内
SYS-03 合同会签与用印审批流：模板库带版本号，业务/技术/财务/法务多方会签，用印前比对盖章件与审批件，审批通过自动编号入台账，履约节点提醒 飞书审批；文档模板；多维表格 SAL-23、SAL-27、LEG-03、LEG-09、GEN-11、LEG-01、HR-04、LEG-08 等 15 条 先交付后补合同，熟人免审；旧版模板仍在流通；盖章件与审批件不一致；台账靠事后补登 M 两周内
SYS-04 资金与额度类统一审批及额度台账：赠送额度、试用券、内部充值、退补、卡密一律走审批单；首期人工执行后回写台账，后续接入网关接口自动发放 飞书审批；多维表格 FIN-29、X-CS-09、OPS-07、FIN-17、OPS-10、SAL-16、RND-47、OPS-09 等 13 条 额度和退补常口头决定或由研发直接操作，超额发放、多扣费难追溯；券码在群内明文发放 M 两周内
SYS-05 采购、付款、报销审批流统一：采购单关联付款单和发票回收，比价附件必填，境外支出和无票支出走专项表单 飞书审批 FIN-01、X-DLV-02、FIN-04、ADM-24、ADM-25、FIN-06、ADM-14、FIN-05 等 14 条 个人垫付和无票支出多；采购与付款不关联；报销类型选错被反复退回 S 两周内
SYS-06 发布单与生产变更门禁：封版和发布检查单、hotfix 准入、生产变更与访问申请（备份/灰度/回滚）、环境占用登记，挂接上线合规评估 飞书审批；多维表格；外部（代码仓库/CI） RND-51、RND-54、RND-48、RND-80、RND-50、RND-58、RND-71、RND-44 等 14 条 没有发布单和检查清单，hotfix 漏 pick；测试与生产环境的用途靠口头约定；生产访问没有时限 M 两周内
SYS-07 密码库与凭据防泄露：统一密码管理工具，机器人检测群聊明文凭据并提醒，凭据台账加定期轮换提醒，验证码代收集中管理 外部（密码管理）；机器人；多维表格 X-SEC-10、X-SEC-11、X-SEC-09、X-SEC-12、X-SEC-24、X-SEC-15、OPS-26、ADM-23 密码、密钥、验证码在大量工作群里明文出现；泄露后没有轮换清单；验证码依赖个人手机 M 两周内
SYS-08 资源统一申请入口与资源台账：AI 订阅、云资源、GPU、测试服务器、上游采购统一申请，台账记录负责人和到期日，到期与闲置自动提醒 飞书审批；多维表格；机器人 X-SEC-14、X-OTH-01、X-SEC-16、FIN-02、RND-23、X-SEC-17、X-SEC-22、HR-17 等 14 条 订阅和中转渠道由个人自购；资源无负责人，到期才停或长期闲置；供应商报价散落在群聊 M 两周内
SYS-09 人事数据链：Offer 确认后自动生成入职清单并分派行政、IT、导师；异动自动推送相关方；考勤异常和加班比对结果直接进入工资表；社保增减员联动 飞书审批；日历/任务（假勤）；多维表格；机器人 HR-12、CEO-06、HR-15、HR-05、HR-27、HR-16、HR-09、HR-14 等 22 条 工位、电脑、账号到岗当天才准备；异动靠口头告知财务；考勤核对、加班费、增减员靠手工对表 M 两周内
SYS-10 实物资产与行政服务台账：IT 资产、测试机/信创借机、样机外借、报修、寄件统一台账，审批结果回写，归还与盘点自动提醒 多维表格；飞书审批；机器人 ADM-30、ADM-33、ADM-08、ADM-24、X-DLV-03、ADM-29、ADM-27、X-SEC-32 等 15 条 设备去向不明，借出不还；盘点与财务账对不上；报修和寄件靠在群里喊 M 两周内
SYS-11 到期提醒中心：证照年检、资质、商标/专利期限、备案、域名与证书、劳动合同、租约统一设“到期日”字段，按 90/30/7 天分档提醒 多维表格（自动化）；机器人 X-SEC-20、POL-03、LEG-23、X-SEC-23、GEN-14、LEG-25、POL-14、LEG-24 等 18 条 证照、证书、资质到期后才发现；专利官文期限只靠代理邮件提醒 S 两周内
SYS-12 演示资源统一调度：演示日历，环境/账号/演示机台账，演示前冻结窗口提醒，冒烟检查机器人，演示脚本库 多维表格；日历/任务；机器人 SAL-11、ECO-19、X-DLV-27、SAL-12、MKT-05、RND-61、SAL-13、SAL-14 等 11 条 演示前临时发版或重启导致演示失败；演示账号额度和演示机去向不清；相同场景反复从零准备 M 两周内
SYS-13 管理节奏工具：会议纪要待办自动建任务，日报周报 AI 汇总并提醒缺报，决策记录卡，多项目人力占用看板 日历/任务；AI；机器人 CEO-07、CEO-15、CEO-12、CEO-04、CEO-11、MKT-18、CEO-09、CEO-02 等 19 条 同一问题反复讨论，结论没有记录；群里布置的任务无人跟踪；周报手工汇总；超载情况看不到 S 两周内
SYS-14 活动与培训项目模板包：活动池与立项卡、大会任务分工表、嘉宾与物料表单、报名与学员台账、培训环境检查清单 多维表格；文档模板；日历/任务 MKT-03、ECO-24、ECO-17、ECO-26、X-FDE-17、X-FDE-16、MKT-08、ECO-16 等 25 条 每场活动、每期培训都从零搭表；物料散在离线文件里；报名和外联靠手工 S 两周内
SYS-15 价格主表与调价变更单：成本价、倍率、对外价放在同一个数据源，调价走审批，先 dry-run 同步网关核对差异，上线后验价 多维表格；飞书审批；外部（AI 网关） RND-67、FIN-28、SAL-18、X-PRD-23、SAL-26、X-PRD-22、RND-69、RND-71 等 12 条 网关、各产品、对外价格表多处手工同步，价格悄悄错位，造成多扣费和成本误判 L 一个季度内
SYS-16 上游账户余额与内部 Key 用量预警：每日拉取余额和消耗并按阈值告警，渠道探活与自动切换，按人按项目统计用量 机器人；外部（AI 网关/云账单） RND-26、RND-25、FIN-03、X-OTH-02、FIN-02、RND-27、RND-27、RND-74 等 11 条 上游余额耗尽后才充值；Key 用量无人关注；封号和渠道故障要等用户反馈才知道 M 一个季度内
SYS-17 支付与计费对账、资金异常处置：支付渠道日对账、网关月账单、客户按量账单，差异自动生成待办，退补闭环处理 外部（支付/网关/财务系统）；机器人；多维表格 FIN-25、X-CS-09、FIN-17、OPS-10、X-CS-24、X-CS-25、FIN-15、FIN-18 等 14 条 对账靠导表手算；资金和分账异常发现得晚，影响清单难以输出；退补口径不一致 L 一个季度内
SYS-18 发票 AI 识别验真与进项台账：发票邮箱或上传目录自动识别，验真查重，校验抬头，缺票看板与催收 AI；多维表格；飞书审批 FIN-01、FIN-10、FIN-36、FIN-04、FIN-03、FIN-12、FIN-06、FIN-07 发票逐张手工核对，重复报销和抬头错误靠人眼发现；缺票拖到审计前才集中补 M 一个季度内
SYS-19 账号权限生命周期自动化：入职按岗位模板开通，调岗收权，离职当天回收，外部协作和客户访问到期自动回收，定期扫描残留账号 飞书审批；多维表格；外部（统一登录/代码仓库/各后台） X-SEC-25、X-SEC-07、HR-27、X-CS-28、X-SEC-31、X-SEC-01、X-SEC-06、X-SEC-08 等 17 条 离职和外部协作权限不回收；开账号不知道找谁；客户 root 授权没有有效期 L 一个季度内
SYS-20 研发协作机器人：播报超期和无人认领的工单，自动指派 PR 评审人，推送构建失败、部署与提测通知、接口变更通知，自动生成更新日志和发版公告 机器人；AI；外部（代码仓库/CI） RND-18、RND-52、RND-65、RND-08、RND-38、RND-17、X-PRD-30、RND-60 等 29 条 研发靠群里 @ 人催办；接口变更不通知下游；更新日志和对内、对外、客户公告各写一遍 M 一个季度内
SYS-21 告警、故障与漏洞闭环：告警分级并由值班认领，故障自动建工单和公告卡片，复盘台账；漏洞台账、安全通告排查与复扫 机器人；多维表格；外部（监控/扫描） RND-75、X-SEC-27、RND-72、X-SEC-43、X-SEC-40、X-SEC-29、RND-35、X-SEC-26 等 16 条 告警噪声大，没人认领；故障通报靠口头；漏洞和整改项没有台账，复测没有记录 M 一个季度内
SYS-22 线索中心与分发机器人：官网、表单、活动线索统一进入 CRM，背调查重，推送认领卡片，超时自动回收，统计活动转化 外部（CRM）；机器人；AI MKT-03、SAL-06、SAL-01、SAL-02、MKT-07、SAL-33、SAL-04、MKT-10 等 15 条 线索散在表格和名片里，有的重复跟进，有的没人跟；活动转化无法统计 M 一个季度内
SYS-23 报价 Skill 与“承诺前确认”闸门：AI 生成方案和报价，成本测算，非标需求特批，自动比对合同范围外需求 AI；飞书审批；多维表格 SAL-19、X-FDE-04、SAL-22、SAL-07、SAL-03、X-PRD-11、SAL-20、X-FDE-03 等 14 条 前线先承诺后评估，标品、非标、收费口径不统一；报价反复手算，缺少技术复核 M 一个季度内
SYS-24 交付订单看板与签收开票联动：受理订单后自动建群派工，按状态机推进，延期自动通知，签收单和验收单回传后触发开票与收入确认 多维表格；机器人；外部（渠道系统/财务） SAL-31、X-DLV-07、X-DLV-04、FIN-19、X-DLV-35、X-DLV-29、FIN-21、X-DLV-08 等 13 条 合同、交付、开票三段脱节；签收单回收滞后，开票依据要逐条核实；交付卡点靠人工盘点 L 一个季度内
SYS-25 口径库、FAQ 问答机器人与发布前合规预审：对外话术、产品 FAQ、制度 FAQ 统一入库，问答机器人答疑，AI 初筛敏感词、品牌用语和授权字段 AI；文档/知识库；机器人 BRD-12、LEG-20、BRD-14、BRD-11、OPS-23、RND-89、BRD-09、SAL-10 等 19 条 同一问题反复问人；对外口径不一致；宣发和 AIGC 内容的合规检查靠人工通读 M 一个季度内
SYS-26 AI 组件准入：机器人/Agent 台账与上线安全基线，Skill/插件上架自动预检（权限分级、红队用例、selfcheck、安全扫描） AI Agent；外部（开放平台/CI）；多维表格 ECO-06、RND-64、RND-56、ECO-07、RND-20、RND-81、X-SEC-37、X-PRD-20 等 13 条 机器人部署在个人电脑上，权限没有边界；Skill 和插件上架靠人工逐个审核；第三方准入标准不一 M 一个季度内
SYS-27 申报与知识产权 AI 文书助手：AI 摘要政策线索，维护申报基础资料库，起草软著、专利、算法备案材料并做一致性比对，归集研发费用 AI；多维表格；文档模板 POL-04、POL-11、FIN-31、POL-10、POL-10、LEG-25、POL-11、LEG-24 等 12 条 申报材料每次从零写，资质口径前后不一致；软著和专利材料准备耗时 M 一个季度内
SYS-28 招聘候选人台账与 AI 初筛：简历汇总去重，跨主体查重，AI 打分分档，面试日程联动回写，漏斗看板，Offer 审批模板 多维表格；AI；日历/任务 X-RCT-17、X-RCT-01、X-RCT-05、X-RCT-07、X-RCT-11、X-RCT-12、X-RCT-21、X-RCT-10 等 15 条 简历分散在多个平台，出现重复面试；面评分散；HC 与薪资口径不一致；漏斗靠手工统计 M 后续
SYS-29 Badcase 与评测集平台：Badcase 表单入库，AI 预分类，维护回归评测集，版本间自动对比，专家盲评 AI；多维表格；外部（代码仓库/评测环境） RND-83、X-PRD-32、RND-82、X-PRD-18、X-FDE-14、RND-02、RND-68、RND-45 等 9 条 Badcase 归类反复摇摆；改动后不做回归评测，生成质量下降发现得晚 L 后续
SYS-30 交付部署工具链与已交付实例台账：部署 Skill 和一键脚本，预检与健康检查，设备指纹注册，远程接入配置，OTA 金丝雀升级，实例在线监控 外部（部署/OTA/VPN）；AI Agent；多维表格 X-DLV-19、X-DLV-13、X-DLV-25、X-DLV-24、X-DLV-16、X-DLV-18、X-FDE-10、X-FDE-06 等 22 条 现场部署依赖个人经验，同样的坑反复踩；已交付设备的版本分布不清，升级和回退风险高 L 后续

30 个建设项合计覆盖约 440 条 SOP，同一条 SOP 可能被多个建设项覆盖。其余 SOP 多为低频、单部门事务，建议沿用飞书原生表单或审批，按 SOP 自行配置，不单独立项。

建设项与总览中“跨部门关键断点 Top 10”的对应关系如下，便于按断点追踪建设成效：

断点 主要承接的建设项 建议观察指标
1 需求入口多路 SYS-01、SYS-20 绕过需求池直接找研发的需求条数
2 对客承诺先于产研评估 SYS-23、SYS-01 非标需求在承诺前拿到产研书面结论的比例
3 合同—交付—开票脱节 SYS-03、SYS-24、SYS-17 无合同交付单数；签收单回收时长
4 发布与生产变更无门禁 SYS-06、SYS-20、SYS-12 发布单执行率；发版后回滚和 hotfix 次数
5 客户问题无统一入口 SYS-02、SYS-21、SYS-25 反馈回告率；首响时限达标率
6 定价/成本/倍率多处配置 SYS-15、SYS-17、SYS-16 价格差异清单条数；计费异常工单数
7 凭据明文与权限不回收 SYS-07、SYS-19、SYS-26 群聊明文凭据告警数；离职与外部权限回收留痕率
8 采购与资源无统一入口 SYS-08、SYS-05、SYS-16 无票和个人垫付笔数；余额耗尽导致的中断次数
9 多主体归属不清 共性底座（主体主数据）、SYS-03、SYS-05 主体不一致被拦截的单数
10 招聘到入职断档 SYS-09、SYS-28、SYS-19 到岗前 2 个工作日完成准备的比例

分阶段路线

第一阶段：两周内（SYS-01 ～ SYS-14，飞书原生配置为主）

  • 第 1 周先建“入口”和“门禁”，与 SOP 优化期第 1 周同步：SYS-01 需求入口、SYS-02 客户问题入口、SYS-08 资源申请入口；SYS-03 合同会签与用印、SYS-04 资金与额度审批、SYS-05 采购付款报销、SYS-06 发布单与生产变更。每个入口都用一个真实事项走通，并在群公告置顶。
  • SYS-07 和安全快速整改同步推进：先开通密码管理工具并公告群内禁发凭据，存量明文凭据排查轮换完成后，再上线群聊检测机器人。
  • 第 2 周铺台账和提醒：SYS-09 ～ SYS-14。这一阶段至少上线 5 个自动提醒，建议优先做到期提醒（SYS-11）、借用归还提醒（SYS-10）、缺报提醒（SYS-13）、演示冻结提醒（SYS-12）、资源到期提醒（SYS-08）。
  • 这一阶段只用表单、审批、多维表格自动化和群机器人，不写代码；需要接口的部分（如 SYS-04 自动发券、SYS-01 同步代码仓库工单）先人工执行、在台账回写，接口留到第二阶段。
  • 依赖：本阶段的所有台账都要先采用“共性底座”里的人员、主体、客户字段和编号规则，否则第二阶段无法关联。

第二阶段：一个季度内（SYS-15 ～ SYS-27，接口集成与 AI 能力）

  • 钱和账优先：SYS-15 价格主表依赖 SYS-04 的额度台账和财务成本口径；SYS-17 对账依赖 SYS-15（价格单一来源）和 SYS-04（额度流水）；SYS-16 余额预警依赖 SYS-08 资源台账中的账户和负责人。
  • 合同到收入：SYS-24 交付订单依赖 SYS-03 的合同编号和台账（建议把已盖章合同设为交付工单的前置条件）；SYS-18 发票 AI 依赖 SYS-05 的采购单与付款单关联。
  • 权限与安全：SYS-19 依赖 SYS-09 的人事异动推送、人员主数据和 SYS-07 密码库；SYS-26 依赖“权限分级”底座；SYS-21 依赖 SYS-06 的环境与变更记录。
  • 研发与前线：SYS-20 依赖 SYS-06 发布单和 SYS-01 需求池状态；SYS-23 依赖 SYS-15 价格主表和 SYS-01 需求池（非标需求评估结论要回写需求池）；SYS-22 依赖客户主数据；SYS-25 依赖知识库目录与口径主责人；SYS-27 依赖 SYS-11 中的资质和知识产权台账。
  • AI 类建设项一律先做“AI 出初稿 + 人工确认”，运行一个月、准确率可接受后，再考虑减少人工复核环节。

第三阶段：后续（SYS-28 ～ SYS-30，重投入或依赖前序数据）

  • SYS-28 招聘 AI 初筛依赖 SYS-09 的入职衔接和人员主数据，并且要先完成候选人信息合规评估（X-RCT-24）。
  • SYS-29 评测集平台依赖 SYS-02 积累的 Badcase 和反馈数据，以及 SYS-06 的发版门禁（评测结果要作为发版条件）。
  • SYS-30 部署工具链依赖 SYS-24 的订单与实例台账、SYS-21 的告警通道和 SYS-19 的远程访问授权回收；建议先在标准一体机交付上试点，再扩展到私有化、信创和集群场景。
  • 每季度复盘一次：根据各台账的使用数据，决定是否把高频的多维表格方案升级为独立系统（与 CEO-20、X-PRD-38 的系统建设归口一致）。

各阶段验收（建议）

  • 第一阶段结束：14 个建设项都有主责人、入口链接和留痕位置，并且每项至少完成 1 次真实事项全流程；资金、额度、合同、发布四类动作 100% 有审批记录；自动提醒不少于 5 个，提醒对象和处理结果可查。
  • 第二阶段结束：价格只在主表修改，网关与对外价格表的差异清单可自动生成；每日对账和余额预警稳定运行一个月，没有漏报；离职当天权限回收有完整记录；AI 初稿类功能统计人工改动比例，作为是否扩大使用范围的依据。
  • 第三阶段：评测结果写入发版条件；新交付设备 100% 登记到实例台账，版本分布可随时导出；招聘漏斗数据直接取自候选人台账，不再手工汇总。
  • 立项方式：每个建设项立项时写清目标指标、数据来源、上线后的维护人和下线条件；达不到指标的建设项，在季度复盘时调整或停用，不长期挂着。

共性底座

以下基础设施被多个建设项复用，建议在第一阶段由总经办指定主责人先定口径，再开始建表，避免每个部门各自造一套字段。

  • 人员与岗位主数据：以飞书通讯录为唯一来源，补充岗位类别、用工主体、汇报线、在职状态、AB 角等字段（HR-28、HR-26、CEO-06）。AI 补贴、零食额度、账号开通、权限回收、资产领用都直接引用这张表（OPS-06、ADM-17、HR-17、X-SEC-01、X-SEC-08），不再各自导出花名册比对。
  • 主体主数据与判定规则：签约、采购、出货、用工、申报主体统一维护一张主体表和判定规则（LEG-02、FIN-32、CEO-24、HR-04、X-RCT-03），合同、采购、入职、申报四个入口强制引用，并自动比对主体是否一致。
  • 客户主数据：以工商全称加统一社会信用代码作为客户唯一标识，CRM、渠道系统、交付台账、实例台账、账单都按同一标识关联（SAL-04、SAL-33、X-DLV-29、X-DLV-31、MKT-04）；客户简称只作为展示字段。
  • 编号规则：合同、订单、项目、工单、设备、凭据各定一套编号规则，在创建时自动生成（LEG-11、X-FDE-23、FIN-31、X-DLV-08、X-DLV-14），跨表关联一律用编号，不用名称。
  • 产品、价格与口径字典：产品名、术语、统计口径、错误码文案维护在同一份词典里（X-PRD-14、X-PRD-15、BRD-01），价格主表（SYS-15）是唯一价格来源，对外价格表只从主表生成视图。
  • 文档模板库与制度库：SOP、制度、合同、方案、纪要、交接、复盘模板统一放在知识库目录下，标明版本号与主责人（GEN-01、HR-01、ADM-12、LEG-01、GEN-12）；复审到期自动提醒（GEN-18）。规则只有进入制度库才算生效，群内宣布只当作通知。
  • 授权矩阵与决策记录：按事项类型分级写明谁拍板、谁知会（CEO-05、CEO-04），审批流的节点直接引用授权矩阵，组织调整时一处修改、全部同步（HR-02）。
  • 权限分级与数据分级：信息按公开、内部、受限、机密分级，多维表格高级权限、外部分享、机器人 scope、数据导出都按同一分级执行（HR-28、X-SEC-33、X-SEC-35、X-SEC-15）。
  • 统一通知与机器人底座：机器人台账写明 owner、权限、作用域和通知群（RND-81）；通知分为告警、待办、播报三级，各级走固定的群，避免刷屏；所有提醒类自动化都挂在台账上，便于下线和交接。

注意事项

  • 数据权限与脱敏：薪酬、绩效、人事档案、客户数据、财务数据、凭据台账都要用受限视图或独立表，不在公共台账里放全量字段（HR-09、HR-28、X-SEC-10）。交给 AI 分析的数据，先按 X-SEC-35 定级，涉及个人信息、客户名称的先脱敏（RND-92、X-FDE-22）；候选人简历和客户材料只能交给内部网关或经法务确认的工具（X-RCT-24）。券码、密钥、账号只通过私聊或密码库发放，机器人不在群内输出明文（OPS-07、X-SEC-10）。
  • 不要过度自动化，保留人工判断：全部步骤中有 446 个明确标注为人工判断，主要集中在以下环节，建议保留“AI/机器人出建议、人拍板”的结构：合同条款终审、用印核对、定价与调价审批、退款和退补判定、资金与分账修复、录用与薪资决策、绩效评价与奖惩、故障定级与对客口径、合规红线与对外发布终审。涉及资金或额度的自动执行（自动发券、自动充值、自动退补）必须在审批通过后才触发，并保留可回滚的记录。
  • 机器人和 Agent 自身的边界：每个机器人上线前要过 SYS-26 的安全基线，权限申请最小化，用私聊与群聊隔离、非工作时段静默等配置降低误操作；AI 生成的内容要标注“AI 初稿”，没有经过人工确认的不能对外发出。
  • 试点后再推广：每个建设项先选一个部门、一条主线、3 个真实事项试运行，记录卡点和绕行情况，删掉无人执行的字段和提醒后再推广；提醒类自动化上线两周后统计一次触达和处理率，噪声大的降级或合并。
  • 单一数据源与 AB 角：同一类数据只保留一个主表，其他地方只引用视图；每个台账和机器人都要指定主责人和 B 角，管理员权限至少两人持有，避免把关键人单点的问题搬到系统上。
  • 成本与留痕：AI 调用和机器人按月复核活跃度和成本（RND-81），长期无人使用的及时下线；所有审批、台账变更、自动化执行都保留操作记录，以便审计和事故复盘。
逐条 SOP 提效标注（655 条）
SOP 🔧 可飞书固化的步骤 🤖 可自动化的步骤
ALL-01 工作请求提交与受理（一事一入口） 1.判断请求类型，在入口表中找到唯一入口；找不到就提…；2.按最少字段填表单/工单；群里只贴单号或链接；6.转入对应 SOP 执行，请求单关联该 SOP 的…；8.提出人确认结果并关闭；3 个工作日无回应自动关闭… 3.机器人自动回执单号、受理岗、承诺首响时限；7.状态变化（受理/进行中/阻塞/完成/拒绝）自动回…；8.提出人确认结果并关闭；3 个工作日无回应自动关闭…；9.每月统计各入口的首响达标率、退回率、入口外请求数
ALL-02 消息分级与响应时限 2.按级别选渠道：P0 = 电话 + 群内【P0】消…；5.处理过程中进展更新在原消息回复或工单，不另开新线… 4.超时未回应：机器人提醒 B 角；P0 由发送人直…；8.每月统计首响时长、超时数、P0 占比并通报
ALL-03 决策记录与发布 3.决策人在记录上确认（点“已确认”），未确认前不算…；4.发布：贴到受影响的工作群并置顶；规则类同步进制度… 2.填写决策记录卡（最少字段），AI 可据纪要或聊天…；5.相关方回执“已阅”；机器人 2 个工作日后统计未…；7.季度回顾：失效、被改、未执行的决策清单
ALL-04 跨部门交接契约 1.把交付物放到交接定义表指定的位置（台账/工单/知…；2.发交接单：按六要素填写（工单字段或交接表单），群…；5.接收方执行；进展按 ALL-09 在看板/工单更…；7.新增或变更交接点：主线 SOP 负责人更新交接定… 4.机器人对超时未确认的交接单提醒接收方 B 角与部…；8.季度复盘各交接点的超时率、退回率，修订时限或 S…
ALL-05 会议发起、纪要与待办闭环 2.建日程并填最少字段；紧急会至少提前 2 小时，常…；3.参会人接受/拒绝并预读；不能到的指定代理；6.校对纪要：决议写进决策记录表（ALL-03），待…；7.参会人 1 个工作日内回执“已阅”，异议在纪要评…；8.待办按 CEO-15 跟踪；下次例会先过上次待办 5.开启智能纪要；每个议题结束时口头复述“结论 + …；6.校对纪要：决议写进决策记录表（ALL-03），待…；9.每月抽查 10 个会议的纪要时效与待办进任务率
ALL-06 卡点升级阶梯 2.一级升级：@ 对方 B 角/值班，附升级单；P0…；3.二级升级：一级在 P0 30 分钟 / P1 4…；7.升级结果回写原请求/交接单，升级发起人关闭升级单 9.月度统计升级数、原因分类（无人/超时/归属不清/…
ALL-07 群聊治理（建群、命名、公告、归档） 2.按命名规则建群：「类型-主体/产品-对象-用途」…；3.发布群公告并置顶：职能、入口表链接、本群对应 S…；7.项目/交付结束后 5 个工作日内：结论与文件归档… 5.机器人按告警/待办/播报三级进不同群或话题，播报…；8.季度清理：30 天无消息的工作群通知群主确认归档…
ALL-08 信息归档与单一事实来源 2.信息产生时直接写入主表/知识库指定目录；群和私聊…；3.聊天中形成的结论、口径、地址、联系人岗位等，由发…；5.其他文档/表格引用主表时只放链接或同步视图，不复…；6.新建主表/系统需提交清单变更申请（信息类型、为何…；8.新人入职与新岗位上手时，把清单作为必读（ALL-… 3.聊天中形成的结论、口径、地址、联系人岗位等，由发…；4.群消息一键转记录：机器人把带标记的消息转入对应表…；7.月度检查：抽查 5 类信息是否只在主表、过期记录…
ALL-09 状态看板与进度同步 1.发布看板目录 v1.0：每类工作一个看板，写明状…；2.执行人在状态变化当日更新看板；预计完成日变化时同…；3.阻塞：当日标红、写原因与需要谁解决，并按 ALL… 4.机器人每日 18:00 推送各看板摘要（新增/完…；5.超过 3 个工作日未更新且未完成的条目，机器人提…；7.日报/周报优先由看板自动汇总生成，个人只补充看板…；8.月度统计各看板更新率、阻塞平均停留时长、群内“进…
ALL-10 SOP 变更与版本管理 1.建立 SOP 总目录：导入全部编号，每条指定 O…；2.提交变更申请（最少字段）；群里说“要写进 SOP…；5.版本号递增（内容变更 +0.1，结构/责任人变更…；6.发布与宣贯：按 GEN-01 发布，相关群公告更… 4.修订：AI 依据变更单生成修订稿，Owner 人…
ALL-11 新人与新岗位上手 1.Offer 接受后触发入职清单（HR-05），同…；3.第 1 天：账号、群（按 ALL-07 群清单）…；6.新人提交“SOP 反馈清单”：读不懂、与实际不符… 1.Offer 接受后触发入职清单（HR-05），同…；8.人事汇总上手完成率与反馈清单，交 SOP 月例会…
ECO-01 生态活动年度规划与 ROI 取舍 1.外部邀约、内部想法、高校/开源合作统一登记进活动…；2.为每条候选活动填立项卡（目标、受众、预算、人力、…；5.发布活动日历，每场指定执行负责人，按类型分派执行…；7.锁定人力与场务排班，缺口提前上报；8.活动复盘：实际投入、线索、转化对比预估，回写活动… 2.为每条候选活动填立项卡（目标、受众、预算、人力、…；6.技术类活动：收集各组内部需求，转为赛题草稿；8.活动复盘：实际投入、线索、转化对比预估，回写活动…
ECO-02 生态合作伙伴引入与内部对齐 1.首次接触后登记合作线索（类型、模式、诉求、投入、…；5.需研发投入的，在工单系统“生态合作战略”项目下开…；6.外部技术对接：系统调研 → 方案 → 权限 → …；7.关系维护：按额度档位审批后开账号、发欢迎消息（文…；8.每月更新台账状态（推进中/暂停/终止），季度回顾… 4.输出对齐纪要并在群内确认，口径以纪要为准
ECO-03 生态资源池建设与资源对接引荐 1.资源持有人按模板提交源文件并注明来源；5.内部需求登记进需求池（需求、截止、需求人、状态）；7.引荐结果写回需求池；机器人每周一汇总未响应、超期…；8.有商机的资源转入销售线索池 2.抽取脚本把各格式转为标准字段；4.全量导入、去重合并、分类打标（行业、地域、资源类…；6.AI 按需求初筛候选资源，主责确认后引荐
ECO-04 生态厂商合作申请（样机/测试卡/适配报告… 1.登记生态机会（厂商、类型、截止、我方收益、对接人…；5.每周更新批复进度；5 个工作日无回音主动追问厂商；6.样机/测试卡到货登记资产台账，指定测试人与归还日…；8.认证分支：锁定版本×架构×OS 矩阵，按厂商 c…；9.报告、证书、申请表归档进材料库，证书转市场出宣传… 3.从材料库取素材，AI 生成申请材料初稿；研发/交…；7.按模板测试并出报告：性能/模型部分由测试写，公司…
ECO-05 开放平台业务归属与需求路由口径 1.登记每条业务线的归属部门、负责人、日常汇报对象、…；2.例会参会名单从登记表生成，负责人变更自动同步；4.发全公司通知、组织 30 分钟内通识课（案例 +…；5.通识课录屏纳入新销售入职必修，入职 2 周内完成；6.销售提需求时按决策树自判类型并填路由单，开放平台… 2.例会参会名单从登记表生成，负责人变更自动同步；8.基于 FAQ 配置答疑机器人；每季度更新决策树与…
ECO-06 开放平台 Skill/插件与第三方接入上… 1.提交接入申请（主体、类型、用途、是否计费、是否需…；3.开通开发者账号与 Key，发开发者包（规范、指南…；5.提交审核：格式合法性 → 质量评分 → 安全门禁；6.客户端联调：接口约定（预签名链接、slug+ve…；8.上架发布并通知接入方；批量上传用 CLI 4.按规范开发并运行 selfcheck 与 AI …；8.上架发布并通知接入方；批量上传用 CLI
ECO-07 OPC 社区/商城第三方商家入驻与准入 1.发布入驻须知（商品类型、卡密格式、结算账期、售后…；2.商家提交入驻申请；进度统一在多维表格更新，不用多…；4.签署入驻协议（内部员工自有产品同样签）；7.预上架测试：下单、兑换、库存锁定、URL 篡改批…；8.正式上架；政府征集类导出进度表报主管部门；9.按 T+1 账期结算；卡密原则不退款，例外走退款… 6.导入卡密/兑换码：系统自动去重、有效期校验，重复…
ECO-08 开源社区建设、运营与产出汇报 2.开源准入审核：项目、许可证、代码范围，法务把关合…；3.维护开源项目与贡献者名单；4.统一表单征集内容/智能体/活动，写清范围口径，表…；6.社区日常运营：论坛发帖、活动日历、群内答疑；7.每周五提交开源产出周报（含实习生产出），主责汇总 5.内容合规审核（不涉黄涉政、无客户与敏感信息）后发…；7.每周五提交开源产出周报（含实习生产出），主责汇总；9.月度复盘：社区成员、活跃度、投稿数、开源项目进展
ECO-09 内部项目开源孵化 1.通过收集表提交 idea；9.每周五 18:00 前更新看板进度，机器人自动收… 2.初筛：去重、判断是否与核心代码解耦、补全缺失信息；4.编写需求文档（目标、范围、非目标、依赖、验收标准…；5.建 Gitea 仓库，接入日报机器人与 CI 编…；6.开发，每个里程碑提交一个可编译、可运行版本；7.AI 预审后人工 code review，阻断问…；9.每周五 18:00 前更新看板进度，机器人自动收…
ECO-10 开源项目与技术成果对外发布 1.在研发成果登记表登记成果，机器人通知生态与市场；3.先建公司组织下私有仓库，整理代码；6.发起开源发布审批（附合规记录、开源范围、维护人）；9.仓库转公开、发布推文，需要时与厂商联合宣传 1.在研发成果登记表登记成果，机器人通知生态与市场；2.判断宣传价值；AI 检索是否首发、有无重名项目；4.按清单做合规核查：许可证、厂商闭源代码/私有镜像…；7.写 README、教程、LICENSE、贡献指南…；10.登记开源项目台账；发布后 30 天内每周统计 s…
ECO-11 开源贡献署名、报备与统计 1.维护公司 GitHub 组织与公共邮箱；仓库名全…；2.新员工入职时绑定企业邮箱、加入组织（与 LEG-…；3.署名：工作时间或使用公司资产的贡献，用企业邮箱作…；4.工作时间提交外部 PR 前在报备表登记；含公司代…；6.每周五汇总本周开源产出（可推文的贡献、可开源工具… 5.脚本按组织成员账号每周拉取已合入的 PR/com…；6.每周五汇总本周开源产出（可推文的贡献、可开源工具…；8.从台账按口径导出清单，员工确认个人条目并剔除敏感…
ECO-12 外部活动/会议参会与信息回收 1.收到邀请后登记外部活动表；3.指定唯一带队人和参会人，完成报名/购票；5.发飞书日程给参会人，截止前 1 天和活动前 1 …；8.联系人入生态资源池；招聘线索转 X-RCT-05… 4.在群内征集同事想问的问题；上台场次准备材料与演示…；5.发飞书日程给参会人，截止前 1 天和活动前 1 …；7.按模板写会后纪要并同步群
ECO-13 对外讲课、培训与布道宣讲 1.填写场次需求单，内容要求不清的当场向主办方/要求…；2.查讲师库档期排班；优先生态讲师与布道官，非必要不…；6.跑通演示环境，备好二维码、社群入口与宣传物料；8.回收现场反馈与新问题，补到内容包 FAQ；课件归…；9.登记讲师工作量，按积分制度（HR-18）计入 3.从内容包按配比拼装课件（参考：科普 50% + …；8.回收现场反馈与新问题，补到内容包 FAQ；课件归…
ECO-14 高校/校园生态合作与校园大使 2.审批立项与预算；4.校园大使招募：方案海报 → 招募通知 → 报名表…；5.每周更新高校覆盖情况，缺位高校报 CEO 协调；6.邀请码与分润功能：需求 → 开发 → 功能测试与…；7.发起全员转发：统一素材包 + 转发登记表 + 推…；8.补贴/算力发放：按表单审核，记录额度与结果，机器…；9.月度提成结算：导出下线/首充/提成 → 大使提现… 7.发起全员转发：统一素材包 + 转发登记表 + 推…；8.补贴/算力发放：按表单审核，记录额度与结果，机器…；9.月度提成结算：导出下线/首充/提成 → 大使提现…；10.月度复盘：注册、券领取、大使产出、成本与 ROI
ECO-15 黑客松与开发者/内部 AI 赛事筹办 1.按模板写赛事立项方案并提交审批；3.定赛制与评分规则；权重用飞书投票确认，2 个工作…；4.准备教程/开发文档、参赛账号或邀请码；评估并发与…；6.开报名；赛事群用公告模板与 FAQ，邀请码按有效…；7.确定评委，发评审日程；9.收材料包（逾期视为弃赛），评委表单打分，系统按权…；10.公示结果，开 2 个工作日申诉窗口；11.发放奖励：积分入台账（HR-18），现金奖走财务… 5.准备评测机、评测集与 AI 评测脚本，试跑一轮；6.开报名；赛事群用公告模板与 FAQ，邀请码按有效…；9.收材料包（逾期视为弃赛），评委表单打分，系统按权…
ECO-16 生态大会立项与总体筹备 2.指定唯一大会项目经理与模块负责人（议程、嘉宾、展…；4.发起邀请人清单，各负责人限期填写；联系方式列只对…；5.上线报名网站/表单与入场方式，征集展示素材；7.发全员动员通知：时间地点、现场分工（接待、展区互…；10.会后：统一处理考勤补卡、费用归集、资料归档、复盘 3.出总体方案与议程（参会人分类、议程时间表、发言安…；5.上线报名网站/表单与入场方式，征集展示素材
ECO-17 大会任务分工与进度跟踪 2.按议程拆任务清单，每项写清交付物、DDL、依赖关…；4.启动会：过任务表、拍板规则、授权额度、日会机制；5.各负责人更新进度、成果链接、风险；6.日会：只过红/黄项与待拍板项（活动前 7 天起每…；7.逾期/阻塞自动提醒；需拍板事项按“选项-优缺点-…；9.关闭任务、汇总费用、移交复盘任务给各模块 2.按议程拆任务清单，每项写清交付物、DDL、依赖关…；6.日会：只过红/黄项与待拍板项（活动前 7 天起每…
ECO-18 大会嘉宾邀约与嘉宾资料收集 1.建嘉宾名单表，按分类分派填报人；2.各条线填报候选嘉宾（单位、职务、关系熟度、邀请人…；4.统一邀约口径：熟识嘉宾先口头预告；日期确定后统一…；5.发出邀请，每日更新状态（待邀/已邀/确认/婉拒）；6.嘉宾确认后填写资料表单，缺项自动标红并提醒；8.制作座次图与席卡；按“文件名-说明-日期”命名，…；10.会后致谢并归档嘉宾资料 4.统一邀约口径：熟识嘉宾先口头预告；日期确定后统一…；6.嘉宾确认后填写资料表单，缺项自动标红并提醒；7.整理圆桌问题与建议答题时长，审核后发给嘉宾
ECO-19 大会演示场景与 Demo 准备 4.活动 Demo：先出原型评审再定需求，记录名称与…；6.编写各产品演示流程与 QA 云文档并开会过一遍；8.录制保底视频与宣传视频，按规范命名存云盘 1.明确受众与目标；从场景库 + AI 整理的同类产…；5.开发与跑通；演示前回归测试脚本每日跑一次；6.编写各产品演示流程与 QA 云文档并开会过一遍
ECO-20 大会物料评审、定稿与采购 1.建物料清单，逐项指定负责人与截止日；2.发布归集规则：只在飞书创建与修改，离线文件统一上…；3.提交初稿链接到物料清单，更新“待审”；4.集中评审（一日一审，只邀物料负责人），AI 先查…；7.成本数量决策：询价并按决策模板提交；额度内物料负…；8.下单、打样、验收（实物比对定稿）；9.定稿打包（含版本号）交会务/供应商；10.积分卡等发放物料：兑换方案确认、正式服联调、现场… 2.发布归集规则：只在飞书创建与修改，离线文件统一上…；4.集中评审（一日一审，只邀物料负责人），AI 先查…；6.品牌合规检查：商标、Logo、主体名、日期落款；10.积分卡等发放物料：兑换方案确认、正式服联调、现场…
ECO-21 大会展区硬件、搭建彩排与现场执行 1.确认设备清单与软件分配，借用设备登记（来源、归还…；2.开机验收、装系统、关闭自动更新、装产品与远程工具…；4.发布哨兵排班；原负责人无法值守时当面交接，接班人…；5.汇总活动码清单，指定负责人，压测并准备备用码；7.统一时间装箱清点（按装箱清单打勾），统一叫车运输…；8.当天：发布会务分工与到场时间、清场规则、签到与座…；9.设备回收、借用设备验收归还；筹办人员调休/加班统… 5.汇总活动码清单，指定负责人，压测并准备备用码
ECO-22 培训营报名筛选、分层与名单管理 2.问卷数据导入唯一在线名单；每次导出文件命名带时间…；5.确定各级开班人数，给每人打分流标签；6.输出首批入选名单，记录版本号与变更日志 3.AI 按规则打分分层，只依据简介与简历中的佐证；7.生成报名看板（总览 + 分层，隐藏分数、附标准说…；8.新增报名按增量重跑步骤 3～7，看板同步刷新
ECO-23 学员分班、批次分配与特殊插班 3.按统一标签标记特殊人群（自媒体、高管与数字化负责…；5.特殊通道：推荐人员统一经表单提交给对接口，未报名…；8.更新对外口径与 Q&A（评分角度、分班依据、不确…；9.调班、时间冲突二次分班；锁定后不再换班 2.按行业自动预分类，“其他行业”人工重分入主类；4.先扣除预留名额，再按批次分班，检查班级人数均衡与…；7.导入生态资源池 SaaS，生成自助查询页；8.更新对外口径与 Q&A（评分角度、分班依据、不确…
ECO-24 学员外联确认、台账与候补补位 1.定稿一页版外联 SOP（唯一一份，在飞书云文档协…；2.确认人手：内部排班 + 兼职到岗，发材料包并开通…；3.按上课批次优先分配名单段，有疑问者放最后；5.发通知短信：企业商业短信通道、已备案签名、不带链…；6.每通电话后 10 分钟内记录台账（意向、是否进群…；7.进群核实：按手机号与群成员对账，未进群标红再跟进…；8.缺口 ≥ 5 人的班触发补位：从后续批次候补池按…；9.开课前 1 天下午锁定名单，之后不换班 1.定稿一页版外联 SOP（唯一一份，在飞书云文档协…；4.电话确认；未接听间隔 ≥ 2 小时回拨，最多 2…；5.发通知短信：企业商业短信通道、已备案签名、不带链…；7.进群核实：按手机号与群成员对账，未进群标红再跟进…
ECO-25 学员答疑、班级群与自助查询 1.发入选通知，附官微二维码与备注规则（“FDE+姓…；2.通过好友申请，按分组拉入对应班级群，统一群名，群…；3.建群当天预设群规则：防骚扰（发二维码/链接自动移…；4.导入名单与分组，配置批次-时间-地点-群码；上线…；6.汇总官微、群、小红书新问题到待答池（问题、来源、…；7.按类型分派：课程内容/考核 → 课程答疑人；其他…；9.新答复写入唯一 Q&A 文档，同步机器人知识库；10.每批课前更新课前须知/FAQ，导出 PDF 发各… 2.通过好友申请，按分组拉入对应班级群，统一群名，群…；4.导入名单与分组，配置批次-时间-地点-群码；上线…；5.群二维码到期前 1 天重导，图片按“批次-班级-…；6.汇总官微、群、小红书新问题到待答池（问题、来源、…；9.新答复写入唯一 Q&A 文档，同步机器人知识库
ECO-26 培训/课程实操环境与算力容量准备 1.提交活动需求单，明确峰值并发与席位人数的区别；3.方案拍板，需采购的走预算审批与采购合同；4.设备到货后上架、接内网、测 OOBE；配置网络接…；6.环境变更（漏洞修复、配置调整）先通知课程方，变更…；9.活动结束后保留日志，分析网络出口与负载；确认无流… 5.按峰值并发压测（含模型额度/限流、网络出口），记…；6.环境变更（漏洞修复、配置调整）先通知课程方，变更…
ECO-27 开班仪式与线下培训会务筹备 1.用活动筹备清单模板立项，列待办（电脑需求摸排、账…；3.确定嘉宾与学员代表范围（如只从本批班中选）；从名…；5.电话/消息邀请，回执实时更新状态（已邀请/确认/…；6.物料清单定稿（证书、指引牌、易拉宝、宣传册、礼品…；8.助教排班表定稿并同步到群；发学员通知（座位、签到… —
ECO-28 培训结营复盘与学员转化 1.结营当天在各班群发反馈问卷（满意度、问题、后续需…；2.召开复盘会：课程、会务、技术、答疑各环节一线反馈…；3.回访学员，按四类人群分类（企业高管/渠道服务商/…；4.有采购或试用意向的企业学员整理为商机线索推送销售 2.召开复盘会：课程、会务、技术、答疑各环节一线反馈…；4.有采购或试用意向的企业学员整理为商机线索推送销售；6.学员群移交长期运营：定期推文入群，设 bot 抓…
ECO-29 生态合作伙伴台账、分级与年度评估退出 1.伙伴入库登记（主体、类型、对接人、协议、权益）；8.更新台账与对外伙伴名单 4.登记权益发放与成本（额度走 FIN-16）；5.年度统计贡献与成本，形成评估
ECO-30 线下活动安全预案、报备与现场应急 5.指定现场安全岗、急救联络人，发应急联络表；6.活动前 1 日检查疏散通道、电源负载、搭建稳固性 3.编制安全预案（人流、消防、医疗、餐饮、用电、天气…
ECO-31 产学研/校企合作立项、协议与成果归属 1.登记合作提议；4.用印签署（LEG-09）；5.指定双方对接人与节点，经费按合同拨付；8.协议、成果、往来文件归档 —
BRD-01 产品命名与更名决策 1.在「产品命名表」登记需求：产品、定位、生效日期、…；2.用表单或文档评论限时征集候选名，不在大群发散讨论…；4.提交拍板。决议必须写明中文名、英文名、内部代号、…；5.在全员群和产研群公告：新名、禁用旧名、对外口径、…；6.生成改名检查表并分派到人，覆盖显示名、窗口名、安…；10.关闭改名检查表，把命名表状态改为「已生效」 3.对每个候选名做商标近似检索、域名可注册与可备案查…；9.发版前全局扫描旧名：代码仓库、安装包、官网、帮助…
BRD-02 品牌视觉（Logo/形象/外观物料）设计… 1.在品牌素材库检索现有版本；有则直接按规范取用，跳…；2.库中没有的，提交视觉需求单；3.品牌负责人受理并指派设计；简单需求可先用 AI …；5.限时评审：按清单（辨识度、比例、小尺寸可读、单色…；7.导出全规格源文件并入库，文件名带版本号和日期；旧…；8.对外使用确认：外观是否定型、商标是否已注册、是否…；9.交付外部（ODM、会务、印刷厂）时按对方格式提供… 4.出 2～3 个方案，标注编号，附使用效果示意
BRD-04 产品官网/落地页与下载页上线 1.需求方出任务简报，与落地页负责人当面对齐目标和投…；3.按内容清单一次性收齐内容包，缺项由对应岗位在截止…；6.开发完成并发布预览；7.跑上线检查表：链接可点、移动端、首屏加载、文案、…；8.部署生产并在群里通告上线地址 4.出框架稿（结构 + 主视觉 + 文案初稿，文案可…；9.下载页接入发版流水线，新版本发布后自动更新链接和…
BRD-05 公司官网改版与内容更新（含 SEO） 1.所有需求进「官网需求池」，群里零散提的由机器人或…；2.每周固定一次收口：合并、去重、判定做/不做/延后…；3.排期并分派设计、开发，写明截止日和验收人；不按「…；6.部署预览并机器人 @ 验收人；验收人对照需求清单…；8.官网负责人确认上线时间，合并主分支部署生产，在群…；10.资质证书有效期写入台账，到期前 30 天提醒官网… 1.所有需求进「官网需求池」，群里零散提的由机器人或…；5.在功能分支开发；可用 AI 辅助生成，但开发人对…；6.部署预览并机器人 @ 验收人；验收人对照需求清单…；7.跑上线检查表：按钮链接、图片清晰度、移动端、首屏…；9.上线后 SEO：提交 sitemap，维护公司主…
BRD-06 官网故障响应与迁移 4.止血：切换 CNAME 到备用托管、回滚到上一版…；7.通报：故障时段、影响、原因、处理结果；迁移的同时…；8.更新监控对象、证书提醒、运维文档；P1 出复盘 1.拨测机器人每 5 分钟检测可访问性、证书有效期、…；6.恢复验证：多地访问、HTTPS、首屏时间、微信内…
BRD-07 新媒体账号注册、认证与运营授权 1.提交开号申请：平台、用途、主体、账号名、运营人；3.对照「主体资质清单」核对平台认证所需材料，列出缺…；4.缺项分派：ICP 转 LEG-23，软著转 PO…；6.绑定公共手机号、公共邮箱，设至少 2 名管理员；7.用平台子账号或运营者权限授权运营人，不共享主账号…；8.登记账号台账，记录改绑限制日期等关键节点并设提醒；9.人员离职或调岗时，在离职交接中完成管理员、运营人… 8.登记账号台账，记录改绑限制日期等关键节点并设提醒
BRD-08 新媒体日常内容生产与发布 1.制定下月内容日历，经审核人确认；2.选题入库；外部文章先判定：可转载（取得授权或用平…；5.发布前审核：品牌称呼、技术表述、广告法、版权来源…；9.汇总进 BRD-10 周复盘，调整下周选题和账号… 3.写脚本或文案；可用 AI 出初稿，产品名和术语按…；4.制作：拍摄或 AI 生成画面、配音（读音专项复核…；6.按日历定时发布到各平台，评论区按话术引导；7.机器人把发布链接推到内部群，同事自愿转发，不组织…；8.发布后 48 小时回填数据：播放/阅读、完读、互…
BRD-09 事件型宣发稿与新闻稿 1.在活动报备表登记事件信息卡；3.向发起方索取照片与三段文字素材；7.审核定稿（修改不超过 2 轮）；联合稿同步厂商确…；9.同步到培训群/客户群/社区公众号，通知全员转发；… 4.AI 搭框架或借鉴同类稿出初稿；配图、排版；对外…；6.去 AI 味润色，按 BRD-14 合规自查清单…
BRD-10 新媒体周数据复盘 2.填入周数据表，自动计算环比；6.文档归档到知识库；每月首个周五出月度汇总 1.导出各平台各账号本周数据（阅读/播放、互动、涨粉…；3.写分析：涨跌原因、表现最好/最差的 3 条内容及…
BRD-11 宣传视频制作与多版本审核 1.按提报规则提交视频需求单；4.收集出镜人照片、声音母版、历史素材，签肖像/声音…；6.版本评审：每版编号上传，评审意见集中填入评审区（…；9.发布或交付播放；源文件、提示词、授权书归档到公司… 3.出脚本/分镜，需求方与终审人确认；5.制作初版（内部制作/AI 生成/外包）；AI 视…；8.按 BRD-14 清单合规自查（竞品/第三方标识…；10.项目结束后沉淀可复用的 AI 视频流程与提示词（…
BRD-12 媒体采访与外部拍摄接待及对外口径 1.任何人接到媒体邀约，转媒体对接人登记来访表；3.对内预告：时间、区域、注意事项（清屏、清白板、着…；9.报道发布后收集链接，转发并二次传播；更新登记表与… 4.受访稿：按提纲 AI 起草，引用口径库；涉及数据…
BRD-13 宣传物料（海报/折页/手册/PPT）制作… 1.提交物料需求单；3.按信息卡模板收集内容；8.按 BRD-14 合规自查后终审定稿；9.归档：源文件 + 导出文件放物料库，文件名带版本… 4.统稿，AI 出文案初稿或海报初稿；7.校对：AI 自动校对 + 人工逐页检查（错别字、…
BRD-14 对外口径、品牌用语与发布前合规自查 3.发布话术库，对市场、销售、运营做 1 次培训；4.每次对外发布前，作者按自查清单逐项勾选；8.客户/渠道提出库外问题 → 提交新问题，给出临时…；9.新问题审定入库；产品更名/发版时同步更新话术库版… 1.汇总现有口径，编写话术库初版（上述 6 类内容）；5.AI 初筛：敏感词/禁用词匹配、品牌名变体、竞品…
BRD-15 客户案例与白皮书收集及授权核查 1.签单/验收/场景完成时自动给项目负责人派“填案例…；2.填写案例卡，上传截图/录屏；4.市场把关复核授权等级，同步入市场部知识库；9.发布/交付并回填使用记录；每季度盘点案例库，补缺… 6.AI 生成结构初稿，真实体验与效果由人撰写；演示…；7.发布前按授权字段过滤：AI 批量生成的案例集只能…
BRD-16 竞品对比评测与素材产出 1.提交评测方案卡（场景、对照产品、指标、题目）；7.入竞品对比库（场景、对照产品、结论、素材链接、可…；9.研发/任何人日常实测发现亮点，1 分钟表单提交到… 4.整理对比文档：结论先行、对比表与图表、关键截图；…；6.对外前合规自查：如实标注测试时间与条件，不贬低竞…
BRD-17 品牌素材库与对外资料库维护 1.建立唯一入口：知识库首页挂“素材库总表”，分类：…；2.迁移存量：把产品信息表、PPT 素材库、Logo…；3.新素材入库：活动、发版、拍摄结束后，责任人上传素…；6.缺失时提需求：填素材需求表单，系统自动生成飞书任…；7.补齐交付：责任人提供素材（需新做的转 BRD-1…；8.每周五过期检查：机器人推送各责任人名下“版本日期… 2.迁移存量：把产品信息表、PPT 素材库、Logo…；5.自助调取：需求方按目录或关键词检索，直接下载使用…；8.每周五过期检查：机器人推送各责任人名下“版本日期…；9.月度盘点：统计缺失类目、未响应需求、失效链接，标…
BRD-18 品牌舆情监测与危机公关处置 2.员工发现即提交链接截图，不在外部评论区回应；5.起草回应口径，法务审核；重大事件报 CEO 1.按关键词巡检各平台，异常推送到舆情群；7.持续监测，每日通报进展
BRD-19 宣传素材版权与肖像授权管理 1.素材入库时登记来源、许可类型、到期日；3.拍摄前签授权书；活动现场张贴拍摄告知；5.发布前按清单核对（来源、授权、未授权人员打码）；6.授权书扫描件挂到素材台账 7.授权到期或本人撤回时下架并替换
BRD-20 合作方联合宣发与公司品牌授权使用 1.业务对接人提交授权/联合宣发申请；7.登记授权范围、期限、物料 2.审核 Logo 用法、产品名、品牌用语；8.合作终止时通知对方撤下我方标识
POL-01 政策与补贴线索收集研判及申报决策 1.提交“政策线索”表单：来源、链接、发布单位、截止…；4.分级：P0=有资金且符合、截止 ≤ 30 天；P…；6.申报项转入申报台账，建飞书任务并倒排里程碑，按类…；7.放弃或暂缓的写明原因；暂缓必须填具体复查日期，到…；9.月度复盘：线索数、申报数、获批数、错过数及原因 2.去重；AI 摘要条款（对象、条件、支持方式、材料…；8.机器人每周一推送新增线索、7 天内截止项；高频问…；9.月度复盘：线索数、申报数、获批数、错过数及原因
POL-02 政府部门日常对接与机构设立事项 1.登记政府事项台账：部门、对方对接人、事项、截止、…；4.编制材料；客户清单、案例、汇报稿只放授权可公开信…；7.递交材料，每 5 个工作日跟进一次并更新台账状态；8.对接人变更：一次性移交联系人、对接群、材料、进度…；9.结办归档：批复、牌匾照片、协议、纪要归档 4.编制材料；客户清单、案例、汇报稿只放授权可公开信…
POL-03 申报基础资料库与口径维护 1.建库：按主体建 10 个分区，每区指定数据提供岗…；2.填表人先查库，命中字段直接引用并登记“用于哪次申…；3.未命中字段提“资料/口径请求”表单：字段、用途、…；5.回写入库，标注口径来源岗位、确认日期、适用范围；8.季度更新：新增证书、专利、软著、荣誉、产品版本、… 7.预警：证照资质到期前 60 天、在申项目负责人提…；8.季度更新：新增证书、专利、软著、荣誉、产品版本、…
POL-04 科技项目申报（市/省重点研发、OPC 专… 1.在申报台账立项：项目、级别、主体、截止、是否有资…；2.研读指南，填资格条件检查表；存疑项致电主管部门核…；4.联合申报：对齐会明确研发内容分工；签联合申报协议…；5.CTO 指派技术配合人（大本子 ≥ 2 人），出…；6.收集项目组成员信息：用受限权限表单收集专业、学历…；9.用印、签字、打印；需线下投递的安排投递；12.每个节点在项目申报群同步；结果（公示、立项、任务… 2.研读指南，填资格条件检查表；存疑项致电主管部门核…；7.撰写：技术部分由技术配合人；公司基础/资质/财务…
POL-05 人才计划与赛事类申报 5.告知本人义务与承诺，取得书面同意；6.从资料库调材料，缺项一次性列清单给本人和相关岗位…；8.盖章、生成 PDF、提交，回执入台账；9.跟踪结果、拨付、年度考核与承诺期，在台账设提醒 1.解读政策并拆分申报口（快速通道/个人/团队），列…；9.跟踪结果、拨付、年度考核与承诺期，在台账设提醒
POL-06 申报佐证材料（测试/检测/验收报告、指标… 1.登记需求：材料类型、用途、格式标准、截止；2.查材料包，版本有效且适用直接使用；5.测试/验收报告：CTO 指派编制人；只依据真实测…；8.定稿交付并登记去向；入材料包（版本、有效期、适用… 4.指标对比表：AI 基于产品手册出初稿，统一使用指…；5.测试/验收报告：CTO 指派编制人；只依据真实测…
POL-07 补贴申领资料归集（上云补贴等） 1.按操作手册列出所需字段，按主体发起归集清单；5.按操作手册整理材料、盖章、提交；6.跟踪审核与拨付，到账后入账并回写台账 2.导出各主体云账号、上云时间、年度消费额、消耗明细
POL-08 周期性政府报表与年检填报 1.建报表日历并每年 1 月复核；3.准备数据底稿；6.年报类提交前报 CEO 确认；7.提交并截图留档；8.更新日历下期截止日，状态改为已完成 2.截止前 10 个工作日机器人提醒责任人；3.准备数据底稿
POL-09 行业/团体标准参编与编制 1.在「政策/标准机会池」登记来源、截止日、资质要求…；4.决策并指定牵头人、技术协调人；5.建项目群，召开大纲会，确认分工与节点计划；8.提交并保存回执，终稿归档，更新机会池状态，跟踪立… 3.评估资质是否满足、投入成本、对产品与品牌的价值；…；6.按模板用 AI 起草，至少两个模型交叉 revi…
POL-10 软件著作权申请与权属确认 1.在知识产权台账立项：名称、版本、产品线、用途（退…；6.需盖章材料走「用章用印申请」，选择对应主体；修改…；7.代理提交、总经办统一缴费，台账记录受理号；8.下证后登记证书号、存证书电子版，通知产品负责人与… 3.按模板编写材料包；可用 AI 根据产品文档生成使…；8.下证后登记证书号、存证书电子版，通知产品负责人与…
POL-11 专利申报（交底→技术审核→代理撰写→定稿… 1.在专利台账登记提案：名称、发明人、所属产品、来源…；4.审核通过后邮件提交代理，抄送总经办飞书邮箱；要求…；7.总经办确认递交、安排缴费，台账记录申请号与递交日 2.编写技术交底书，可用 AI 起草初稿后人工补全；8.每周机器人推送台账中“下一步责任人 + 截止日”…
POL-14 企业资质认定与年度维护（高新技术企业、科… 1.按主体建资质日历（到期日、年报日、评价窗口）；5.负责人审核、用印（LEG-09）；7.证书入资质库（POL-03），通知财务办理税收优… 2.对照认定条件自评（研发费用占比、高新收入占比、科…；8.按规定填报年度发展情况报告；更名或重大变化及时报…
POL-15 获批项目执行、专项资金使用与验收结题 1.签任务书，建项目台账（指标、节点、预算、配套要求…；4.按预算支出；超预算或调科目事前审批；8.全套档案归档，备事后抽查 5.季度更新进度、指标完成度、支出进度，节点前 1 …
POL-16 申报代理/中介机构选用与服务管理 3.至少 2 家比价，负责人选定；7.按合同节点付款并收票；8.年度评价机构，更新名录 2.核查机构资质、失信记录、案例；拒绝“包过”“材料…
MKT-01 外部活动/展会情报收集与参与决策 1.发现活动后在“外部活动台账”表单登记（群里转发不…；2.机器人定期抓取活动平台与行业大会信息入台账，按截…；5.发起“市场活动参与/赞助申请”审批：小额社区活动…；7.完成报名/企业通道申请/赞助确认，台账状态改“已…；8.创建活动任务、指定活动负责人，转入 MKT-03… 2.机器人定期抓取活动平台与行业大会信息入台账，按截…；9.有人到场（含未正式参展）的活动，按模板回传见闻，…
MKT-02 发布会立项与预算审批 1.动议人按模板提交立项单，群内口头预算不作数；2.产品总监提交产品一页纸和发布门槛自评；4.财务核对预算科目，CEO 审批立项与预算；5.倒排里程碑并建任务：材料、物料、演示、邀约、投放；6.AI 出对外材料初稿（海报、PPT、新闻稿、FA…；7.转入执行：现场按 MKT-03、演示按 MKT-… 2.产品总监提交产品一页纸和发布门槛自评；6.AI 出对外材料初稿（海报、PPT、新闻稿、FA…
MKT-03 参展/大会报名与现场执行统筹 1.建活动执行台账，指定活动总负责、会务、展区负责；3.参会人提交参会申请（目的、预期成果、预算），按口…；4.收集报名信息（受限权限表格）并提交主办方，订票住…；5.发布展区流程与话术文档，每人在文档内认领话术与提…；6.排班（按天/时段）与现场任务分工（展区、接待、礼…；7.行前通知：到场时间、带什么设备、着装、联系人、应…；8.现场执行：按排班到岗，线索用统一表单登记（转 M…；10.按审批口径提交报销/补贴，附成果说明 5.发布展区流程与话术文档，每人在文档内认领话术与提…；8.现场执行：按排班到岗，线索用统一表单登记（转 M…
MKT-04 自办渠道大会邀请与授牌确认 1.公布日期、邀约指标与名单截止日；2.用模板建邀请名单多维表格：企业全称/简称/联系人…；3.销售填报，机器人在截止前 T-3/T-1 提醒未…；6.发邀请函，回执状态回填名单；7.定版名单交会务制作牌匾/证书、排座与上台流程；8.改期时当天通知全部邀约人重确认，会前 2 天出终… 3.销售填报，机器人在截止前 T-3/T-1 提醒未…；4.AI 校验企业全称（工商名称）与简称、查重、标记…
MKT-05 展会/大会/发布会演示环境与设备准备 1.提交演示需求单（场合、产品、形式、时间、演示人）…；3.预约独立演示环境，冻结演示版本（冻结至活动结束）…；4.准备演示机+备机、网络与路由备份、插排；登记出库；9.清点回收硬件、解冻环境、收集现场反馈 2.写场景与脚本，打包固定演示数据；体现核心卖点（如…；6.运行演示冒烟脚本（登录、核心流程、额度、上游连通…
MKT-06 活动物料与礼品制作及回收 1.提交物料需求单，先查库存可复用项；4.印刷类至少 2 家比价后下单；积分卡兑换码用脚本…；5.3D 打印礼品：指定唯一责任人，在表中按颜色/部…；6.验收清点（数量、错字、色差），终稿电子版归档物料…；7.出库登记，确认送达时间与现场交接人；8.活动后按出库单清点归还（含电源、设备、剩余礼品）…；9.物料与打印材料费用按科目报销，附需求单链接 2.从模板库按尺寸/分辨率出稿，加二维码；3.按校对清单检查错别字、尺寸、二维码可扫、品牌口径…；4.印刷类至少 2 家比价后下单；积分卡兑换码用脚本…
MKT-07 活动后线索跟进与转化复盘 2.生成本场专属引流码与线索表单（自动带活动来源）；3.现场扫码/表单登记线索，标注意向等级与是否决策人；4.AI 汇总名片与登记信息，去重后入 CRM，按区…；5.首次跟进（电话/微信），回填跟进结果 4.AI 汇总名片与登记信息，去重后入 CRM，按区…；7.单场复盘：线索数、匹配度、决策人占比、成本，给出…；8.月度统计各活动类型线索到商机/签约转化，反馈 M…
MKT-08 外部布道/分享活动接单与讲师分工 1.收到邀请后发主办方需求单（统一模板），回收后登记…；3.指派主讲与辅助，确认档期；台账自动建日程与活动群；5.向主办方报题目与讲师简介，回执记入台账；7.现场分享，统一引流码收集听众（转 MKT-07） 3.指派主讲与辅助，确认档期；台账自动建日程与活动群；6.按目的与听众准备 PPT，AI 辅助按画像改版，…；8.复盘：听众反馈、线索数、目的达成情况，回填台账
MKT-09 演讲/布道 PPT 与演示素材制作、评审… 1.登记场次，确定讲师、听众、时长、定版截止时间（终…；3.从 Demo 库选素材；库里没有的向素材录制人提…；5.修改并定版：文件名带日期+版本号，上传场次台账，…；9.定版回收进母版库，新录 Demo 入库，记录现场… 2.从母版库选版，用指定 AI 工具链按听众画像生成…；6.一页 PPT 配一页讲稿，导出提词器版；高管场次…；8.主办方要求提前拿材料时，转 PDF 并加统一水印…
MKT-10 客户来访接待与演示 1.填来访接待单：单位、名单、人数、时间、目的、是否…；2.预订会议室或展厅，指定开门与引导人；4.制作席卡、订餐、安排接送；7.输出会议纪要，拆出跟进任务（唯一负责人+截止日）… 3.按默认方案出议程（介绍、演示、交流、参观），确认…；6.接待执行：签到、介绍、演示、交流，安排专人记录；7.输出会议纪要，拆出跟进任务（唯一负责人+截止日）…
MKT-11 演示机/试用机准备与分配管理 1.提交演示/试用机申请：用途、规格、席位、外设、接…；3.确认库存、装机、外设到位，给出预计交付日期；5.配置模型接入与软件、开演示用服务端账号；6.管理员账密存入公司密钥托管，台账只记托管位置和管…；7.只交付给提单人/市场样机管理员，签交接单，登记资…；8.每次内外部流转登记；到期前 3 天自动提醒归还或… 5.配置模型接入与软件、开演示用服务端账号；8.每次内外部流转登记；到期前 3 天自动提醒归还或…
MKT-12 外部合作与政府需求线索接收及分派 1.首接人用标准话术回应（已转负责人，请先发材料），…；3.按路由表指派唯一对接人，机器人通知对接人并抄送首…；5.需要试用的转 SAL-16 申请额度与开通，并指…；8.结果写入 CRM，约定下一步与时间；不推进的标注… 2.分类：电商/渠道合作、硬件厂商预装、政府培训/接…；6.进入方案阶段：对接人为唯一方案负责人，先整理上下…
MKT-13 第三方平台/商城上架与消费券推广 1.平台通知统一录入“渠道活动台账”，指定响应人和平…；8.发布购买指南与 FAQ（领取条件、地域限制、重复… 5.设定价格档位，研发出卡密 CSV，用脚本批量导入；8.发布购买指南与 FAQ（领取条件、地域限制、重复…；9.收集问卷与销量，汇总到多维表格，批次结束复盘
MKT-14 营销活动与裂变玩法策划及合规审批 1.点子提交到“营销点子池”：目标人群、玩法、预算估…；5.预算与权益审批：按权益菜单申请券/额度，超菜单的…；6.排期执行：研发需求走排期，素材走 OPS-13，…；7.发放登记：权益、邀请码、提成按人登记，月度对账 3.填写活动策划卡：规则、预算、素材、防刷、归因（U…；7.发放登记：权益、邀请码、提成按人登记，月度对账；8.活动结束复盘：拉新、转化、成本、问题，决定是否复…
MKT-15 推广投放预算审批与效果复盘 1.填投放方案：渠道、预算、周期、KPI、素材、追踪…；3.提交预算审批，附方案与比价；7.预算耗尽或周期结束开复盘会，纪要自动生成待办，每… 6.每周更新效果报告：消耗、曝光、点击、获客、转化（…；7.预算耗尽或周期结束开复盘会，纪要自动生成待办，每…
MKT-16 产品版本更新向市场/销售同步 1.版本规划确定后登记“市场同步排期”（预告日、发布…；3.在周一市场会预告并发群公告；机器人在发布前 5 …；6.举办内部分享并录制回放；8.收集市场销售反馈（材料可用性、客户问题），转 M… 2.编写市场版发布说明：新功能、UI 变化、客户影响…；3.在周一市场会预告并发群公告；机器人在发布前 5 …；7.发布当天同步正式说明与上线视频，更新售卖材料版本…
MKT-17 市场产品反馈汇总交接 1.收到客户/渠道反馈后按表单字段登记一条，不再散落…；2.迭代规划会前 3 个工作日截止本期收集，机器人提…；5.在产研群发交接表链接并@产品负责人，说明本期重点…；7.纳入项同步进需求池并关联交接记录；结论回告市场和…；8.版本上线后，把已上线的反馈项标记“已上线”并通知… 3.AI 对本期反馈去重、归类（功能缺失/体验/性能…；7.纳入项同步进需求池并关联交接记录；结论回告市场和…
MKT-18 市场运营日报与沟通记录规范 1.发布日报规则：字段、提交截止时间、填写时长（约 …；2.与客户/渠道在微信或电话有实质沟通后，把要点（含…；3.按模板提交日报：今日完成（附链接）、明日计划、需…；9.每月抽查：随机抽取客户，核对 CRM/飞书记录是… 4.机器人在截止前 30 分钟（18:00）提醒未提…；6.AI 基于一周日报和沟通记录生成周报草稿（完成、…
MKT-19 市场年度计划、预算编制与费用执行跟踪 1.向各子职能/产品线收集目标与活动计划；3.条线负责人审核后报 CEO 审批；5.单项活动立项时注明占用预算科目；7.预算外或超预算事项单独审批 2.编制年度市场日历与预算（按主体/产品线/活动类型…；6.与财务核对当月实际支出，更新执行台账
MKT-20 市场活动与线索个人信息收集使用合规 1.用标准模板建表，含告知同意勾选；3.名单存公司空间，限定可见人员，禁止个人网盘/个人…；5.向渠道/外包/合作方共享须审批并签数据处理条款；7.个人要求删除/退订/投诉，按时处理并留痕 4.邀约与营销仅限已同意人员，短信/电话提供退订方式；6.活动结束后按保存期限删除或匿名化，转为线索的进 …
SAL-01 主动获客（社群/短视频/私域/冷邮件） 2.养号，发布获客图文/短视频/帖子；5.有回应的客户录入线索库：来源渠道、联系人、规模、…；6.有意向的预约演示并发日程；7.演示后填反馈表（关注点、异议、下一步、意向等级 …；8.A 级线索转给商机跟进销售，按 SAL-04 录…；9.按漏斗口径提交日报，机器人自动汇总 2.养号，发布获客图文/短视频/帖子；3.用线索工具抓取评论与潜在客户，AI 二筛出高意向…；9.按漏斗口径提交日报，机器人自动汇总
SAL-02 入站线索接入、背调与分发认领 1.所有入口线索登记进线索池：官网表单自动写入；来电…；5.已有归属的直接派原负责人；无归属的发认领卡片，手…；7.首次联系结果写入 CRM；需求明确的转 SAL-…；8.意向客户每 2～3 个工作日跟进一次，直到转商机… 2.机器人推送线索卡片到销售群，测试来源打标签、不推…；3.甄别背调：企查查核主体、CRM 查重、判定真实客…；9.超时回收：24 小时未首次联系、7 天无跟进记录…
SAL-03 商机甄别、可行性初筛与赢丢单复盘 1.在 CRM 登记商机并附需求原文；没有具体金额的…；2.发客户信息收集清单（业务场景、数据、部署、并发、…；7.C 级或放弃：用统一话术礼貌退出，CRM 写明放…；8.赢单、丢单或卡住超过 30 天：填复盘表 2.发客户信息收集清单（业务场景、数据、部署、并发、…；4.技术可行性与定制比例评估（AI 先初筛需求文档，…
SAL-04 CRM 客户/商机录入与维护 1.新人入职/转岗申请账号，管理员按角色开通（销售只…；2.新建前用企查查全称查重；已存在的联系负责人或申请…；3.线索先进公海池，不直接建客户；有具体金额和需求后…；4.商机按「客户名称+产品类型+商机金额」命名；同一…；5.每次拜访/通话/会议后记跟进（时间、对象、内容、…；7.赢单必须上传合同并生成销售订单；试用客户充值同步…；9.核对 CRM 合同/订单与合同台账、财务回款的差…；10.月度/年度考核只取 CRM 数据 2.新建前用企查查全称查重；已存在的联系负责人或申请…；5.每次拜访/通话/会议后记跟进（时间、对象、内容、…；8.机器人推送本周未更新跟进的商机和缺失字段清单，销…；9.核对 CRM 合同/订单与合同台账、财务回款的差…
SAL-05 客户拜访与会议纪要记录、信息同步 1.建日程时指定记录人，默认开启飞书会议录制/妙记；…；3.发纪要：开头 3～5 句写主题、结论、下一步，正…；4.纪要链接写入 CRM 跟进记录；需求、验收、售后…；5.下一步转飞书任务（负责人+截止日期）；需回访的设…；6.同步：普通客户发销售群；重大合作项目发对应项目协… 2.会中记录参会人及角色、客户诉求、我方承诺、分歧、…；3.发纪要：开头 3～5 句写主题、结论、下一步，正…；4.纪要链接写入 CRM 跟进记录；需求、验收、售后…；7.机器人汇总本周纪要（日期、主题、客户、关键事项、…
SAL-06 重点商机上报与大客户分级推进 1.填重点商机上报表（客户、意向、金额、决策链、时间…；3.A/B 级发启动会通知（主题、时间、地点、参会人…；7.报价与合同按 SAL-19 / SAL-23 执…；8.更新看板（阶段、本周进展、下一步、卡点、需支持人…；9.卡点（客户失联、采购流程卡住、合同条款）在看板标… 4.启动会定目标、分工、里程碑、对外口径和价格边界，…；8.更新看板（阶段、本周进展、下一步、卡点、需支持人…
SAL-07 政企客户需求对接与方案汇报 1.收到需求或邀约后建“政企汇报任务卡”：时间、对象…；6.出发前核对清单：对象称呼与分管、口径、纸质版、演…；7.拜访汇报；会后发纪要（SAL-05）并复盘：客户…；10.礼品、宴请、第三方中介：事前提交事由、对象、形式… 2.摸底：对象单位与角色、数据敏感还是涉密、能否上云…；4.写方案/白皮书：通俗版讲痛点和成果，技术细节放附…；7.拜访汇报；会后发纪要（SAL-05）并复盘：客户…；9.客户内部上会被退回：输出数据分级分类规范、模型选…
SAL-08 客户/渠道/合作方来访交流准备与会后复盘 1.填来访信息卡：对方背景、诉求、问题清单、来访人、…；3.发日程：参会人、AB 角、记录人，默认开启录制+…；8.发纪要（SAL-05）；待答问题统一写成文档回复…；10.跟进动作（试用、合作协议、报价）入 CRM 和飞… 4.写会前口径卡：对方诉求、我方目标、产品版本、报价…；6.机器人提醒主备出席人；主出席人无法到场由 B 角…；8.发纪要（SAL-05）；待答问题统一写成文档回复…
SAL-09 售前技术支撑与技术问题统一答复 1.提交售前支撑申请（客户、阶段、预算、诉求、时间）；3.排班派人，写入飞书日程；时间地点变更由销售当场改…；4.从售前资料库自取案例、视频、专利/资质清单；缺项…；8.答复发客户；对方坚持面谈则约一次线上答疑会；新问… 5.客户技术问题整理成编号文档，现场不即兴作答；6.基于 FAQ 库由 AI 生成答复草稿，技术负责…
SAL-10 对外沟通口径统一与对客通知审核 2.未命中则提交口径申请（问题、场景、截止时间）；3.按领域分派：价格/合同 → 商务；硬件 → 硬件…；6.发布入库，标注版本、适用场景、失效条件，群内通知；7.对客通知（使用政策、限制、强制要求）提交审核，产… 1.先在口径库检索，命中则直接使用最新版；4.AI 起草，归口人改定；只写可兑现的事实，不写套…
SAL-11 客户演示准备与执行 1.提交演示申请（对象、目的、时间、地点、产品、场景…；4.按 SAL-12/13 申请演示环境、账号、额度…；5.按脚本完整预演一遍，测试确认；同步录兜底视频（本…；7.登记客户反馈、追问、需求和下一步，转商机跟进或需… 3.从脚本库选场景（2～3 个出结果快、5～10 秒…
SAL-12 演示环境与版本保障（冻结/稳定版/兜底） 1.在演示日历登记演示（时间段、环境、版本、功能、演…；3.冻结窗口生效：发版、OTA、重启、迁移前查日历，…；6.兜底就绪：本地可播放的录屏、备用演示机、随身网络 3.冻结窗口生效：发版、OTA、重启、迁移前查日历，…；4.推送当前已知问题与禁用功能、建议模型档位（标准模…；5.冒烟检查：版本、服务状态、证书、网络、额度、模型…
SAL-13 演示账号与演示机管理 1.提交演示资源申请（产品、用途、对象、资源类型与数…；3.从账号池或演示机台账分配；客户项目环境一律不得借…；4.凭据通过密码管理工具或私信发送，登记“谁、何时、…；6.到期提醒并回收：收回演示机、改密、重置演示数据、… 5.演示额度或积分券按标准发放，从演示券池出，不动已…；6.到期提醒并回收：收回演示机、改密、重置演示数据、…；7.每月盘点：账号池、演示机在线状态与持有人、额度消…
SAL-14 售前 Demo/样稿制作与客户需求转产研 1.提交售前需求单；不得直接拉研发开会或私下派活；4.查 Demo 台账与行业工作流，能复用的做契合度…；5.研发排期并指派；技术需求统一经研发收口人对接；7.内部验收，录屏，导出报告（固定模板含目录）；8.交付客户，1 个工作日内登记反馈；新 Demo … 3.AI 整理客户需求摘要；立项写清 P0 演示点、…；6.开发/生成；客户材料未到位的部分不开工，按 mo…；7.内部验收，录屏，导出报告（固定模板含目录）
SAL-15 销售物料、标杆案例与知识库建设 1.销售每周提交客户问题、答不上的问题、好话术（语音…；2.成功演示、竞品对比当场录屏，提交案例表单；5.发布到“最新版”目录，文件名带版本号和日期，旧版…；6.规则/模板/价格变更：通知群发布时附知识库链接，… 1.销售每周提交客户问题、答不上的问题、好话术（语音…；3.赢单或试用满半个月，从 CRM 导出生成案例草稿…；4.归口人整理：AI 聚合 FAQ、去重；案例脱敏（…；6.规则/模板/价格变更：通知群发布时附知识库链接，…；8.每月清理过期内容，检查各目录负责人与更新日期
SAL-16 客户/渠道试用申请审批、开通与转化跟进 1.现场不承诺试用；回公司在 CRM 提交试用申请（…；4.登记试用台账：客户、档位、额度、起止日、负责人、…；6.试用满半个月出深度使用报告（优先客户自写），入案…；7.到期前 3 天提醒；试用合同挂起超 2 周无回复… 3.开通：CRM 充值申请 → 开通账号与额度（设到…；6.试用满半个月出深度使用报告（优先客户自写），入案…；7.到期前 3 天提醒；试用合同挂起超 2 周无回复…
SAL-17 赠送额度、借机与特殊商务行为报备留痕 1.在承诺客户之前提交“特殊商务申请”，选择类型（额…；3.审批：档位内由市场销售负责人直接批；超档位、设备…；5.补齐书面留痕：赠送/借用确认函或试用协议；员工自…；7.到期提醒：借用设备回收或转销售；试用到期跟进转化… 2.核定成本（额度折算成本价、设备成本），标注是否与…；6.登记赠送台账（对象、内容、成本、审批编号），月底…；7.到期提醒：借用设备回收或转销售；试用到期跟进转化…
SAL-18 产品定价与价格体系管理 1.登记定价需求：对象、原因、期望生效日；2.提供成本数据（含折扣与有效期），写入成本表；5.审批：标品价格由 COO 批；低于毛利底线或改动…；6.发布：内部总表更新版本号（仅限授权人员可见）；同… 3.在定价测算表中填参数（成本、倍率、毛利目标、分成…；4.复核成本口径与倍率，校验公式；销售与渠道确认可卖…；7.同步：在销售群、渠道系统发布变更通知；网关和商城…；8.月度复核：对照上游成本变动和实际毛利，判断是否需…
SAL-19 客户方案与报价单编制审核 1.在报价台账登记：客户、商机、来源、需求四要素、客…；6.审批：毛利达到底线的由市场销售负责人批；低于底线…；7.从锁定版本生成客户版 PDF（不含人日明细的版本…；8.跟进客户反馈；改价必须新建版本、重新走第 6 步 3.分块估算：软件按模块估人日；硬件转 SAL-20…；4.用报价 Skill/模板生成方案书、报价单、内部…；5.技术复核：范围、承诺指标、成本因子（算力、人力、…；7.从锁定版本生成客户版 PDF（不含人日明细的版本…
SAL-20 硬件/算力配置评估、询价与报价 1.提交硬件评估需求单（必填项不全的退回）；7.按利润系数形成客户价，加上软件与词元价；注明有效…；8.价格审批，财务、法务核对配置与合同条款一致后发客… 2.软件侧给出并发、显存、上下文需求；IT 据此出配…；3.容量存疑（没有实测数据、大并发）时，安排非工作时…；5.用同一份需求文档向 2 家以上渠道询价（或从成本…；7.按利润系数形成客户价，加上软件与词元价；注明有效…
SAL-21 定制/非标需求评估、报价与特批 1.提交非标需求受理单，写清商务背景；4.按人天成本价加评估费和上浮定价；起草服务说明（交…；5.特批：市场销售负责人批价格；研发占用超过阈值或战…；6.签合同或追加合同（走 SAL-23）；收到首付款…；7.进入研发“非标”队列排期；标品工单优先，非标不插…；8.交付后按服务说明验收，回填受理单 3.评估改动点、人天（含测试）、工期，只报人天；4.按人天成本价加评估费和上浮定价；起草服务说明（交…
SAL-22 招投标与供应商入库 1.登记投标台账：项目、客户类型、主体、截止时间、提…；3.拆分任务：商务、技术（软件/硬件分块）、报价、资…；4.从资质包调取材料；缺失或过期的，当天向资质提供人…；7.定稿用印、封装、提交；质保函按模板出具；8.登记开标结果；未中标的，3 个工作日内复盘；新材… 5.编制：商务部分、技术响应、报价表在同一份在线文档…；6.交叉审核：合计与分项、格式、报价与合同条款一致、…
SAL-23 销售合同起草、条款谈判与用印 1.选现行模板起草，填写主体、金额、付款节点；客户模…；2.交付规格只用标准套餐描述，并链接规格文档；涉及硬…；3.发起内部会签：市场销售负责人、交付可行性、产品、…；7.发起用印（走 LEG-09），签署、寄送；8.签署后当天上传 CRM、移交归档，通知交付与财务… 1.选现行模板起草，填写主体、金额、付款节点；客户模…；4.发客户；客户的每轮修改都记录在“条款修改记录”中…；6.定稿：核对拼写、产品名、数量、金额大小写、与报价…；8.签署后当天上传 CRM、移交归档，通知交付与财务…
SAL-24 收款条件、赢单登记与回款跟踪 1.签约前向客户明确收款条件：设备先款后货、软件与词…；2.客户要求赊账、货到付款、先发货或分期的 → 提交…；3.合同签署后，在 CRM 新建合同并关联商机，上传…；5.按付款节点登记回款计划；6.合同上传后自动通知财务；到账后财务在 CRM 标…；7.到账（或特批通过）后才通知交付与发货 4.系统校验附件和编号，通过后商机自动变为“赢单”；…；6.合同上传后自动通知财务；到账后财务在 CRM 标…；8.回款到期前 3 个工作日自动提醒；逾期 7 天销…
SAL-25 合同范围外需求拦截与客户预期管理 2.登记《需求变更单》，补齐量化信息；3.对照合同、方案书自动比对功能清单，标出“在内/部…；5.分流：拒绝 → 第 6 步；通用能力 → 进需求…；8.答复和承诺原文归档到 CRM，交付/售后可查 3.对照合同、方案书自动比对功能清单，标出“在内/部…；6.起草对客书面答复（结论、费用、排期、边界），涉及…
SAL-26 API/额度类分销订单（API 转售、卡… 1.询单登记到分销订单台账（客户、产品、预计金额、并…；4.发报价与订单确认函，约定先款后开号、额度、并发、…；5.财务确认到账，在台账勾选“已收款”，同时确定入账…；6.上游余额不足时发起上游充值申请；8.冒烟测试通过后，发 key、接入文档与示例 3.按价格表计算单价（官方价×系数，加并发另计），超…；7.网关建 key 并配置额度上限、并发上限（超出排…；9.每日用量与余额告警，月末导出用量做对账、开票、提…
SAL-27 渠道伙伴开发、授权政策与协议签署 1.渠道线索登记（来源、意向、联系人、区域、行业）；2.准入评估：资源、出货能力、是否与已签独家冲突，A…；4.标准政策直接套用；独家/区域/任务量/返点让步提…；5.用当前启用版本模板拟协议，产品清单直接引用产品方…；6.AI 首轮条款审查，法务终审（独家定义、保护期上…；7.用印、寄送，跟进对方内部审批与签署；8.协议上传渠道系统开通渠道账号，登记渠道台账，终版… 2.准入评估：资源、出货能力、是否与已签独家冲突，A…；6.AI 首轮条款审查，法务终审（独家定义、保护期上…
SAL-28 渠道非标合作（预装/贴牌/联合开发）承诺… 1.收到非标诉求，回复“内部评估后书面答复”，登记《…；5.审批：技术承诺由 CTO，价格分润与品牌授权由 …；6.起草合作协议或补充条款，法务审查后签署；7.以审批版本对外书面答复（时间、指标、价格），只由…；9.合作暂停或变更时，书面通知对方和所有内部知情人 —
SAL-29 渠道与销售产品培训赋能 1.登记培训需求（对象、主题、触发原因）到培训台账；2.指定讲师，开发先与产品过一遍内容；课程文档写“怎…；3.发培训通知（时间、地点、会议号、必须参加人），同…；5.回放和文档归档到知识库培训专区，在通知群发链接；6.发小测验，缺席或未通过者看回放补课并重测 2.指定讲师，开发先与产品过一遍内容；课程文档写“怎…；5.回放和文档归档到知识库培训专区，在通知群发链接；6.发小测验，缺席或未通过者看回放补课并重测；8.收集培训后重复问题，更新 FAQ，月度复盘是否要…
SAL-30 渠道体系管理（台账、分级评级、分润与推荐… 1.新签渠道录入台账（以渠道系统/CRM 为唯一数据…；3.个人/中间人推荐：先在系统登记线索与推荐人，再交…；5.结算审批：销售负责人审核，规则外让步提交 CEO；6.财务按审批结果打款并取得发票或完税凭证；7.季度评级：按出货、报备、培训参与、违规记录打分，…；9.制度和手册更新后发布到知识库，通知全体渠道与销售… 4.订单回款后按分润规则表自动核算分润/推荐费，生成…；7.季度评级：按出货、报备、培训参与、违规记录打分，…
SAL-31 渠道报备→订单→交付（渠道系统） 1.在渠道系统报备客户/项目；2.审核报备，通过后进入保护期；驳回写明原因，可修改…；3.从报备记录发起订单，上传合同材料，填席位数与特殊…；5.商务审核订单（价格、合同一致性）；6.财务确认收款；材料不全时退回渠道补充；7.硬件准备 → 软件部署、充值、开通，绑定客户与实…；8.上传验收单，IT 最终验收后关闭订单 7.硬件准备 → 软件部署、充值、开通，绑定客户与实…；9.开票：普票线上自助，专票人工处理
SAL-32 销售日报周报与汇报保密 1.按模板填周报：每个项目/渠道一条，写进展、本周行…；2.同步更新 CRM 商机阶段；周报中出现但 CRM…；6.周一经营例会使用部门周汇总；7.月底导出每人当月周报记录给人事作为考勤依据 1.按模板填周报：每个项目/渠道一条，写进展、本周行…；3.机器人周五 17:00 提醒，周六 10:00 …；4.自动汇总部门周报，列出新增/推进/停滞商机和需支…；7.月底导出每人当月周报记录给人事作为考勤依据
SAL-33 商机与客户归属分配制度 1.登记无主或争议商机/订单，填写来源、类型、已有跟…；2.按客户主体在 CRM 查重，已有有效报备的直接判…；4.归属销售确认接收，首次联系客户并在 CRM 写跟…；6.在每周市场简报中公示本周新分配与改判商机；8.出货/签约订单提交时强制填写归属销售，未填不得提… 2.按客户主体在 CRM 查重，已有有效报备的直接判…；6.在每周市场简报中公示本周新分配与改判商机；7.回收超期未跟进商机（14 天无 CRM 跟进记录…
SAL-34 销售业绩考核与提成核算 1.书面定稿下一周期考核口径（周期、7 项指标、目标…；3.销售完成当月 CRM 录入；未入 CRM 的数据…；5.在 CRM 公示评分明细与规则说明，销售提出申诉…；8.财务按审批结果随工资发放，结果表与审批归档 4.CRM 自动计算前 5 项（90 分）；主管完成…；6.导出月度 KPI 明细/季度排名 Excel，销…；7.按奖励政策计算提成，提交审批（销售负责人→CEO…
SAL-35 销售人员离岗客户与商机交接 1.离职/调岗审批通过后通知销售负责人；4.逐客户补全阶段、承诺、风险、联系人；7.CRM 归属变更、历史记录保留 2.导出名下客户、商机、合同、回款清单
SAL-36 销售合同变更、终止与退换货处理 1.受理请求，要求客户书面提交；4.法务、财务会审；5.审批；8.退款或红冲开票 9.更新合同台账与 CRM
SAL-37 商务招待、礼品与反商业贿赂合规 2.提交招待/礼品事前申请；3.审批，疑难情形转法务；5.报销时关联事前审批单 6.核对审批与凭证一致，未审批的退回
SAL-38 销售目标分解、商机预测与月度 Pipel… 2.更新名下全部商机阶段与预计成交月；5.向交付、财务发送预测 3.生成三档预测表与硬件需求汇总；6.计算上月预测偏差并说明原因
OPS-01 新站点/分站上线运营配置 1.填写分站上线立项单：名称、域名、主体、支付渠道、…；2.开管理员账号、收件邮箱，一次性交给配置人；4.配置支付渠道；财务确认收款主体与账户余额；6.用测试账户小额试付，跑注册→充值→消费→退款全链…；7.按上线检查表逐项打勾，拥有者签核后开放；8.登记站点台账，在运营与客服群发上线通知 6.用测试账户小额试付，跑注册→充值→消费→退款全链…
OPS-02 模型上线与定价规则 1.提交模型上线/调价申请（模型、渠道、理由、上线日…；3.提供并登记 API 成本价与有效期；4.按毛利底线（[阈值待财务确认]）定价，表格自动校…；5.审批定价；低于毛利底线需 CTO 特批并写明期限；6.配置模型与价格上线，用测试账号实扣核验；7.需开放充值时确认已接统一支付，配置充值类型字段；8.安排代金券/赠送额度，按 OPS-07 登记发放 4.按毛利底线（[阈值待财务确认]）定价，表格自动校…；9.每月核对实际毛利、上游账单与充值流水
OPS-03 帮助中心、使用手册与更新日志维护 1.发版清单自动生成"文档同步"任务，指派文档运营；5.preview 环境自检：链接、安装包版本、旧客…；6.PR 合并到 prod 或手动触发部署；7.同步客服知识库、AI 客服 FAQ，在群内发更新…；9.文档、视频归档到飞书知识库对应版本目录 2.从工单、PR、提交记录导出本版变更汇总；3.AI 按"新增/优化/修复"结构起草更新日志与手…；5.preview 环境自检：链接、安装包版本、旧客…；7.同步客服知识库、AI 客服 FAQ，在群内发更新…；8.新功能需要视频时，用视频生成 skill 产出教…
OPS-05 全员使用自研产品推动与内测反馈 1.按模板发内部使用公告（入口、账号、额度、帮助、反…；2.部门负责人在机制文档中确认责任；5.未安装/未使用名单由机器人私信提醒，并抄送部门负…；6.反馈统一填表，收口人每日去重、分类并转工单；7.部门负责人每月提交至少 1 个达标场景；8.每周公示使用数据与有效反馈，月度汇总交人事计入积…；9.小工具邀请制试用：写邀请通知、开权限、置顶入口说… 4.后台用量自动汇总到多维表格，按部门统计；5.未安装/未使用名单由机器人私信提醒，并抄送部门负…；6.反馈统一填表，收口人每日去重、分类并转工单；8.每周公示使用数据与有效反馈，月度汇总交人事计入积…
OPS-06 员工 AI 补贴与内部余额月度充值核对 1.补贴到账当天，机器人在全员群发充值通知（金额、截…；5.机器人私信未完成者；手机号不一致者补正；7.月底最终核对，输出"已完成/未完成/例外"名单；8.名单交人事/财务执行补贴保留或取消，结果归档 1.补贴到账当天，机器人在全员群发充值通知（金额、截…；2.生成本月 LeapCore 补充名单，审批后批量…；4.次日导出后台数据，按飞书手机号自动匹配人事名单；5.机器人私信未完成者；手机号不一致者补正
OPS-07 试用额度与兑换券申请、发放与登记 1.填写额度/券码申请表（产品、环境、账号、用途、数…；6.机器人把券码/到账结果私发申请人，不在群内明文贴…；7.对外发放（合作方、媒体、政企用户）登记台账并同步… 2.规则判定：当日首次且 ≤ 默认额度自动放行；超额…；4.审批通过自动调接口发券/充值，回写兑换码、批次 …；6.机器人把券码/到账结果私发申请人，不在群内明文贴…；9.每月统计发放量、消耗与成本，区分赠券与付费券
OPS-08 邀请码申请与账号开通 1.申请统一入多维表格（含申请时间、来源、环境），注…；2.机器人推送申请卡片，卡片带"通过/拒绝"按钮；5.按规则发放额度包（默认 10 次），特殊额度走 …；6.内部同事：测试环境走特殊验证注册或预置白名单码；…；7.渠道批量码按渠道生成并登记发放人与额度包；8.C 端回访、B 端转业务专家跟进，按渠道统计转化 1.申请统一入多维表格（含申请时间、来源、环境），注…；4.通过后由后台接口生成邀请码并短信发送，回写状态；8.C 端回访、B 端转业务专家跟进，按渠道统计转化
OPS-09 用户额度包与企业组织运维 1.提交额度/组织变更申请，填写对象、类型、额度、理…；4.单条调额/补词元/组织变更在后台执行，删除组织前…；6.通知申请方与关联方（换 Logo、组织名等），在…；8.变更单归档，月底汇总当月发放额度给财务 3.月度重置：每月 1 日 10:00 前由定时脚本…；8.变更单归档，月底汇总当月发放额度给财务
OPS-10 渠道卡密生成、额度包配置与核销 1.渠道需求登记立项，填写渠道接入清单；3.后台创建渠道与额度包，配置叠加规则与"最多拥有数…；6.批次登记台账（批次号、渠道、额度包、数量、有效期… 5.正式环境用后台（不用临时脚本）生成卡密，核对"邀…；7.核销查询：通过后台查询页或机器人查卡密状态，不再…；9.每月 5 日前导出各渠道核销数据，与财务对账
OPS-11 OPC 商城自营商品上架、下架与补货 1.提交商品上架申请，登记上架清单；2.按模板提供介绍，卡密批次文件上传指定目录；5.正式上线并在群内同步上线信息；6.库存低于阈值（建议剩余 ≤ 7 天销量）机器人提…；8.退款：用户走"退款重新买"，退款审核通过后同步销… 3.卡密批量导入，脚本校验重复与格式，登记台账（批次…；6.库存低于阈值（建议剩余 ≤ 7 天销量）机器人提…
OPS-12 渠道来源 UTM 链接/二维码申请与追踪 1.提交渠道码申请，写清场景与用途；2.按命名规范审核 utm_source，查重；6.交付需求方，渠道配置表登记 2.按命名规范审核 utm_source，查重；4.生成长期链接，过长时做短链，批量生成二维码；7.每周一出各渠道注册与转化报表
OPS-13 拉新增长活动策划与传播物料 1.填写活动立项表（目标、预算、奖励、承接、风控、监…；3.风控与财务审批（现金类必须财务会签）；6.按定版物料发布，登记发布渠道与时间；文案更新时通… 5.AI 批量生成文案与物料，活动负责人审核定版，标…；7.活动期间每日监测拉新、成本、异常账号
OPS-14 种子用户与产品用户社群运营 1.填写发券申请表（必填"用户微信号""已拉群/已加…；3.审批：未拉群/未加客服的不通过；通过后发券（新用…；7.换号/外部引荐：用户加助手号由助手号代邀请；外部… 4.入群欢迎语 + 置顶入群须知（使用说明、反馈方式…；5.群内反馈由机器人归集入表；7.换号/外部引荐：用户加助手号由助手号代邀请；外部…
OPS-15 付费用户识别、跟踪与挽留 2.建联人在后台查看用户信息（最小权限，权限一次性开…；5.真实付费用户赠额度、放弃用户送额度挽留，提交审批…；7.反馈整理入反馈表，转产品 1.充值/放弃事件触发机器人推送到运营群并写入台账；8.每周复核台账：联系率、转化、复购
OPS-16 用户反馈收集与归集 1.新群建立时拉入固定反馈机器人，申请群消息读取权限；5.P0/P1 问题当即转 Bug 工单并通知研发；…；7.处理结果回写反馈表并在群内回复用户 2.每日 09:00 定时抽取前一日群消息；3.AI 识别反馈、去重、打标签，写入反馈表；6.待确认反馈累计满 5 条触发提醒，强制汇总；8.每周一出反馈周报（数量、分类、Top 问题、处理…
OPS-17 运营数据需求、看板与统计口径 1.用飞书表单提交取数/看板需求；6.交付归档：文件存云盘，需求单回填链接与 SQL/…；7.同类需求 30 天内第 2 次出现即固化为定时报… 2.查指标字典与已有看板，能自助的直接回链接；4.取数或开发：只读账号查询；需生产库按 X-SEC…；7.同类需求 30 天内第 2 次出现即固化为定时报…
OPS-18 内容运营选题审核与发布排期 1.出下月内容日历（每账号每周目标篇数）；2.产品、市场、销售向选题池提交素材与选题；7.定时发布并同步分发到社群、视频号；9.周报：产出 vs 目标、数据、下周计划 4.撰写草稿，AI 辅助初稿与排版，存公众号草稿箱；8.发布后第 3 天回填阅读、转发、涨粉数据
OPS-19 AI 资讯日报生成与社群分发 1.更新统一信源清单与去重规则；5.推送内部飞书群（卡片/HTML 格式）；7.归档到多维表格（日期、标题、分类、来源、链接） 2.定时采集各信源；3.AI 去重、打分、分类，生成 Top 8～10 …；6.生成微信社群版（短摘要 + 链接，避免折叠）并发…
OPS-20 客户案例沉淀与宣传 1.发现成果即填案例线索表（任何人都可提，客户经理补…；2.交付满 15 天自动提醒提交深度使用反馈；8.通知市场销售群；可对外的转 BRD-15 发布 3.量化效果：查用量、花费、节省时间；4.每周从周报、群聊抽取案例草稿补充线索；6.按模板成稿（行业/痛点/方案/效果/素材）
OPS-21 内部 AI 应用场景与创意征集 1.填征集立项卡（类型、目的、标准、评审团、激励、截…；3.在通知群发布，统一使用需求/创意池表单（按类型分…；7.公示结果，按积分制度发放激励；8.入选项转化：建任务定负责人；skill 上架并署… 4.截止前 2 天提醒未提交人员；5.AI 初筛：去重、聚类、可实现性初判
OPS-22 社区冷启动内容填充与汇报演示准备 1.节点确定后倒排内容计划；6.经种子账号接口/管理端导入上线；不得直接改生产库…；8.节点后回收演示数据，或经审核转为正式内容 3.采集真实内容：活动、政策按统一字段整理，AI 辅…；4.本地批量生成种子帖/评论，标注“示例/演示”；5.AI 预审打分 + 人工抽检不少于 20%
OPS-23 社区内容与入驻信息审核 2.待审条目推送审核群并 @值班；4.通过或拒绝，拒绝须选原因，系统记录审核人 1.机器初筛：敏感词库 + 大模型语义审核，命中即拒…；6.入驻厂商按准入清单预审，AI 预审材料
OPS-24 会员端活动上新、权益与积分配置 1.通过机器人卡片提报，卡片自动写入变更台账；3.指定执行人与截止，生成飞书任务；4.配置上线：优先后台自助；后台不支持需改库的，按 …；7.点“已改完”，状态自动回写提报人并关闭台账；8.会员活动：立项模板（目标/预算/奖励/审核/复盘… 5.批量积分：导出客户表 → 俱乐部方填表去重 → …
OPS-25 平台罚款申诉审核 1.申诉提交后自动推送到审核群并 @审核岗；2.认领申诉，在申诉单标记“处理中”；5.撤销类执行退款或解除处罚，财务核对；7.申诉单关闭，原因分类登记，月度汇总 1.申诉提交后自动推送到审核群并 @审核岗；6.向申诉方反馈结果与理由
OPS-26 运营平台账号与登录验证管理 1.盘点全部运营账号，建立台账（不记录密码明文）；3.设验证码接收值班：主接收人 + 备份人，共享号码…；4.在登记表提交登录/认证申请（平台、操作类型、期望…；7.人员变动时：交接账号清单、改管理员、改密码、更新… 3.设验证码接收值班：主接收人 + 备份人，共享号码…；5.接收人回复可用时段，运营触发验证码，接收人通过受…
OPS-28 运营资料汇总与岗位交接 1.维护统一知识库目录：流程、群运营思路、对外资料表…；2.按岗位整理“入门包”：必读清单、入门任务、常用群…；3.人事告知到岗日期，交接负责人开好文档/群/表格权…；7.接收人把交接中发现的缺漏补进知识库 5.接收人按清单自学并完成入门任务，疑问记在交接文档
OPS-29 用户个人信息权利请求与账号注销处理 1.登记请求（入口、时间、类型）；6.答复用户结果；不能满足的说明理由；7.处理单归档 5.执行删除或匿名化；依法须留存的交易记录按期限封存
OPS-30 营销权益防刷与异常账号风控处置 1.活动上线前风控评审：每人/设备/手机号限领、总量… 2.配置领取速率、聚集度、消耗突增告警；3.活动期间每日巡检领取与消耗数据；5.冻结领取、暂停活动、封停账号、回收额度、暂停分润…；8.统计月度权益损失报财务
OPS-31 用户举报、消费投诉与监管协查响应 1.所有入口统一登记（来源、时限、类型）；7.全部结果归档 3.内容举报按 OPS-23 审核，违规即下架并处罚…
RND-01 反馈群问题收集与分流（bug/需求/ba… 1.在统一入口发帖或填表；口头或私下收到的反馈由收到…；6.转载体：bug→建工单（进入 RND-03）；需…；9.工单关闭、需求有结论或 badcase 处理完后… 2.机器人按模板检查必填项，缺项在原话题追问；信息补…；3.机器人按口径预判类型，附理由；5.查重：按关键词/标题相似度检索已有工单、需求、b…；6.转载体：bug→建工单（进入 RND-03）；需…；7.在原话题回帖：类型、去向链接、负责人、预计处理时…；9.工单关闭、需求有结论或 badcase 处理完后…；10.汇总上周反馈：数量、类型分布、未分流数、重复率
RND-02 Badcase 记录、分诊与回归集沉淀 1.填写 badcase 表单（必填项见第 5 节）…；2.自动生成 BADCASE 编号、写入多维表格并通…；9.把典型 badcase 转为回归/评测用例（进入… 1.填写 badcase 表单（必填项见第 5 节）…；5.初分根因类别：模型能力/提示词/上下文压缩/工具…；6.会前推送待归因清单；归因会逐条过，指定处理人、方…；8.用原样例复测，通过标"已解决"并记修复版本；未通…；9.把典型 badcase 转为回归/评测用例（进入…；10.生成周报：新增、已解、类别分布、复发项
RND-03 缺陷提报、复现、分级与指派 3.按模板建单：选对团队、类型标签 bug、项目、迭…；7.修复：PR 标题带工单号，工单评论贴 PR 链接…；9.关闭：通过后置"完成"；来自反馈群的通知反馈人；… 2.查重：检索关键词和已知问题清单；重复的在原单追加…；3.按模板建单：选对团队、类型标签 bug、项目、迭…；5.按"模块-负责人"表指派；无法判断的交研发负责人…；9.关闭：通过后置"完成"；来自反馈群的通知反馈人；…；10.推送"未定级/未认领/超时未修/待验收超 2 天…
RND-04 需求提出、澄清与评审入迭代 1.提交需求池表单；领导或客户的口头方向由产品经理当…；5.会后把结论（做/不做、方案、估点、优先级）写回需…；6.拆卡建工单：估点 1/2/3/5，超过 5 必须…；10.迭代回顾：未完成需求回池或顺延，更新需求池状态 2.澄清：补齐背景、目标、验收标准；缺"为什么做"的…；5.会后把结论（做/不做、方案、估点、优先级）写回需…；10.迭代回顾：未完成需求回池或顺延，更新需求池状态
RND-05 新产品/新项目研发立项与分工 1.填写立项卡：目标、MVP 范围、不做项、DDL、…；3.发布角色表：技术负责人、开发、顾问、需求、测试、…；5.需求梳理会：逐条过用户故事，现场答疑，确认范围；…；6.建协作载体：代码仓库、项目群、工单项目、里程碑；10.转入常规迭代：后续需求走 RND-04，缺陷走 … 4.编写 PRD，并转成用户故事清单（角色/场景/验…；5.需求梳理会：逐条过用户故事，现场答疑，确认范围；…；8.进度同步：看板每日更新，每周向 CTO 汇报完成…
RND-06 迭代规划、工单拆分与排期 1.冻结下一迭代需求清单，标优先级并附 PRD/UX…；2.建新 cycle/milestone，把需求拆为…；4.召开迭代规划会：过范围、优先级、风险；超容量项当…；5.认领工单：每张有唯一负责人、截止日、优先级；会后…；7.在研发通知群发布迭代计划链接并 @相关人；产品同… 2.建新 cycle/milestone，把需求拆为…；3.估点（1 点≈1 人日，按复杂度），AI 估点必…；5.认领工单：每张有唯一负责人、截止日、优先级；会后…；7.在研发通知群发布迭代计划链接并 @相关人；产品同…
RND-07 研发任务分派、模块负责人与归属判定 1.建立并维护模块负责人清单（模块、产品线、主责、兜…；2.新问题/工单按清单定位负责人并指派；工单系统按模…；6.人员变动交接：交出人填交接单，工单批量转派，接手…；7.汇报线调整/借调：研发负责人提出，研发部门负责人…；8.新人入职：用人负责人写入职任务书（岗位目标、首月…；9.负责人请假超过 3 个工作日：兜底人接管，工单负… 2.新问题/工单按清单定位负责人并指派；工单系统按模…；5.每周负载检查：在手点数 <团队平均 50% 视为…
RND-08 研发进度跟催与延期风险上报 1.开工即改“进行中”，每日下班前更新状态与剩余工作…；4.节点 D-3 风险盘点：每人标“能完成/有风险/…；5.预计延期主动上报：工单链接、原因分类、影响范围、…；7.对测试、销售/市场同步最终范围与新日期，测试据此… 2.机器人推送“超期/今日到期/无人认领/进行中超 …；8.迭代末按原因分类（需求排太满/估点不准/前松后紧…
RND-09 研发站会与例会 1.按会议矩阵建周期日程（站会、CR、规划、回顾、周…；2.会前更新工单状态；无法参会者在群里按模板文字同步…；5.决议与待办转工单，指定负责人和截止日；8.主持人缺席由代理人主持；会议冲突由发起人顺延并修… 4.线下开会也开飞书会议录制，生成智能纪要并推送群；5.决议与待办转工单，指定负责人和截止日；7.纪要归档到迭代文档
RND-10 研发日报/周报与进展同步 1.更新当日工单状态，工单作为日报主数据源；2.工单无法体现的工作按四要素补充：做了什么/结果/…；7.周报归档到固定 wiki 入口并在群公告置顶链接… 3.机器人拉取工单变更、PR/提交、会议纪要，生成日…；4.机器人校验缺报与“优化/推进/调整”等单独出现的…；5.机器人生成周报草稿，研发负责人审改：按功能模块写…；6.合成产研周报（本周进展/主要风险/下周重点），另…
RND-11 工单状态维护与工单系统规范 1.确定唯一工单系统与仓库归属，发布状态机、必填字段…；2.建单：标题、类型（需求/任务/bug）、关联需求…；3.按状态机流转：开工改“进行中”，合并部署测试环境… 2.建单：标题、类型（需求/任务/bug）、关联需求…；4.状态变更、指派、打回、到期前 1 天自动通知负责…；5.每日巡检：无迭代、无负责人、跳过验收直接关闭、超…；7.每周自动统计：迭代点数完成/未完成、bug 新增…
RND-12 研发绩效、点数考核与事故追责 1.迭代内全部功能工单和 bug 工单估点；未估点的…；6.按规则核算扣点与回扣（如 bug 点数从引入人回…；7.在研发群公示报表（只公示数据，不附个人评价），异…；9.每 3 个月汇总点数、质量指标和主观评分，交人事… 2.bug 入库时填等级、来源功能、引入 PR、修复…；3.P1 及以上 bug 按修复时限跟踪，超期自动标…；4.迭代结束自动生成报表：个人完成点数、bug 回扣…；6.按规则核算扣点与回扣（如 bug 点数从引入人回…
RND-13 开工前方案设计与前置过审 2.判定等级：L1 小改（< 1 人日、单模块），i…；3.按模板写方案：目的、方案、改动范围、不做什么、风…；5.@过审人和受影响模块负责人评审，意见写在 iss…；7.估点排入迭代，PR 描述必须链接方案 issue 3.按模板写方案：目的、方案、改动范围、不做什么、风…
RND-14 技术方案评审、选型决策与赛马 1.登记决策议题：议题、选项、截止时间、发起人；5.评审：在文档逐项给意见；决策会控制在 90 分钟…；7.ADR 归档到知识库“技术决策”目录，群公告并置…；8.建执行工单并链接 ADR；被否方案的已有代码按 …；9.赛马子流程：发章程 → 参赛者截止前交 todo… 3.汇总选项写 ADR 草稿（≤ 2 页）；可用 A…；5.评审：在文档逐项给意见；决策会控制在 90 分钟…；9.赛马子流程：发章程 → 参赛者截止前交 todo…
RND-15 新技术/开源方案/第三方能力调研评估 1.登记调研议题：目标、业务方、期望日期、候选；8.转出：引入 → RND-05 立项或 RND-6… 4.AI 初评：生成候选对比（功能、许可证、活跃度、…
RND-16 技术栈、组件库统一与通用能力复用 1.立项时对照《技术栈清单》勾选，写入项目 READ…；3.需要清单外选型 → 提偏离申请：选项、理由、影响…；5.批准后更新清单（版本号、生效日期），群公告置顶；… 2.查组件目录，已有同类能力的写“复用评估”一段（复…；6.可复用能力回流：定制项目中除业务逻辑外的原子能力…；7.共性规范（翻页、增删改、软删除、前端防抖、后端幂…
RND-17 重大技术变更/重构报备与同步 3.在研发群/项目群 @受影响负责人、产品、测试征求…；9.记入变更日志 / 决策台账 2.写变更说明：原因、方案、影响面、回滚、测试建议、…；5.在独立分支实施；PR 必填“影响面 / 是否删除…；6.PR 勾选“改变用户可见功能”时自动 @产品和测…；7.合入后按仓库负责人名单（CODEOWNERS/订…；8.机器人每日汇总 commit 和变更工单发群；站…
RND-18 跨团队/跨系统接口对齐与集成约定 1.在工单系统提“跨组对接”单：背景、期望、涉及实体…；3.写对接方案：边界图、数据主责（实体-写入方-读方…；6.联调：按清单逐项核对（环境、域名、分支、clie…；7.归档：契约、配置说明、ADR、数据主责表更新；s… 3.写对接方案：边界图、数据主责（实体-写入方-读方…；5.提供方先出 mock 和 OpenAPI，两边并…；8.后续变更：提供方发版本说明并通知所有接入方；底座…
RND-19 前后端接口变更、联调与废弃通知 2.在同一个 PR 里更新 Swagger 注解和对…；3.登记接口变更清单并 @相关前端；4.配套 PR 互相关联，标明“需搭配合并”、是否需…；5.推测试服，确认 Swagger 已更新后再通知前…；7.联调问题统一登记联调问题表（接口、问题、责任人、…；9.废弃：先在 Swagger 标 deprecat… 2.在同一个 PR 里更新 Swagger 注解和对…；3.登记接口变更清单并 @相关前端；6.联调前用 AI 比对 Swagger 与前端调用…
RND-20 Agent 安全与权限控制设计 1.登记安全需求并定级：数据可能被删除或外传定 P0…；5.执行红队用例：危险命令集、越权路径、token/…；7.发版门禁：安全用例全部通过才能发版；每次拦截都写…；8.更新安全基线清单和用例库，并在研发群通报 4.实现方案并提 PR，附危险命令清单和自测结果；5.执行红队用例：危险命令集、越权路径、token/…；7.发版门禁：安全用例全部通过才能发版；每次拦截都写…
RND-21 新成员研发账号开通与开发环境搭建 1.发起“研发入组开通”申请，勾选权限清单；3.开通 VPN、测试服/开发服 SSH、监控和 C…；4.通过密码管理工具或单独加密渠道交付凭证，首次登录…；5.开通飞书 wiki 空间、项目群、小程序体验版、…；8.划定模块边界，布置首周任务（读代码并写现状文档，…；10.核对清单全部勾选后关闭申请；离组或离职时按同一清… 2.开通 Gitea 账号和仓库/组织权限，按最小权…；6.让 AI 读 README 和 CI 配置自动搭…；9.提交上手文档（代码现状、问题、环境踩坑）；带教人…
RND-22 代码仓库创建、归属与权限 1.在“仓库/权限申请”表单提交建库、迁仓或授权申请；3.直接在组织下建库，授予仓库负责人管理权限；不走“…；5.登记仓库台账：仓库、模块、代码范围、负责人、开发…；6.按最小权限开通访问权限并在申请单回执；申请人确认… 4.初始化仓库：README（用途、负责人、启动方式…；5.登记仓库台账：仓库、模块、代码范围、负责人、开发…；8.每季度复核权限；成员离组或离职当天回收权限
RND-23 开发测试服务器/云资源/域名申请 1.查台账和能力目录，确认有没有能复用的资源；2.提交“研发资源申请”：类型、规格、用途、期限、是…；4.审批：标准规格且用现有资源的，由研发负责人批；要…；6.安全交付：访问方式写在申请单回执里，SSH 用公…；7.登记台账（资源 ID、用途、负责人、到期日、是否…；10.月度盘点闲置资源和成本，回收闲置资源并通报 5.开通机器、域名、端口、存储、短信模板或子账号；演…；7.登记台账（资源 ID、用途、负责人、到期日、是否…；9.到期前 7 天机器人提醒使用人确认续用或释放；3…；10.月度盘点闲置资源和成本，回收闲置资源并通报
RND-24 GPU 算力申请、租赁与采购 1.填写算力申请：模型、精度、卡型、卡数、期限、项目；2.用估算工具核对需求是否合理，并盘点台账上的闲置卡；3.内部有闲置卡：直接分配，在台账标注占用人和到期日…；5.审批：小额临时租用由 CTO 在飞书审批；大额租…；6.下单或开机，测完网络和性能再交付，并登记台账；8.到期前 3 天提醒；需求方确认释放后，先备份数据… 2.用估算工具核对需求是否合理，并盘点台账上的闲置卡；7.使用期间每周自动上报利用率；连续 3 天低于阈值…；8.到期前 3 天提醒；需求方确认释放后，先备份数据…
RND-25 AI 编码工具账号/订阅/额度申请发放 1.查《AI 工具使用指南》，确认可用渠道和本人资格…；2.提交“AI 工具账号/额度申请”；实习生和外包由…；5.凭证经密码管理工具或审批回执交付，禁止在群里发公…；6.登记台账：人员、工具、key/席位、额度、周期、…；9.走补贴自购的，每月底前提交付费截图和商家 Inv…；10.到期前 7 天提醒续用；离职或转岗当天作废 ke… 4.发放：在内部网关为个人生成独立子 key 并设上…；8.按 key 统计周用量：到 80% 提醒本人，异…；9.走补贴自购的，每月底前提交付费截图和商家 Inv…；10.到期前 7 天提醒续用；离职或转岗当天作废 ke…
RND-26 AI 工具/中转渠道采购、号池运维与封号… 4.采购：发起采购审批（供应商、用途、能否开票），财…；6.登记渠道与号池台账；11.维护人变更时按交接清单交接（总 API、业务专用… 1.汇总需求，测算用量和成本；5.接入统一网关：多渠道分散接入，按人发子 key …；7.机器人定时探活各渠道，失败时自动切到备用渠道并在…；8.续费评估：到期前 7 天提醒，运维负责人拉网关日…；10.月度复盘：渠道可用率、成本、封号事件，据此更新白…
RND-27 模型 API Key 与调用额度申请（统… 1.填写配额申请：先对照 wiki 术语表选类型（测…；2.预算审批：测试用途小额按默认档放行，生产/外发/…；3.卡片通知经办人“待发放额度”；5.发放：申请人登录接入站自取，或经密码库授权给负责… 4.在接入站建用户/令牌，按申请设额度、模型分组、I…；6.回写台账：Key 名称（不含明文）、归属、环境、…；8.余额低于 20% 或单日消耗超过日均 3 倍时机…；9.到期前 7 天提醒；到期自动停用，需续期的重走步…
RND-28 AI 编码协作规范与质量管控 9.交付说明：用人话写改了什么、怎么验证、AI 生成… 4.隔离：worktree/独立分支，沙箱运行；AI…；5.执行：每次改动 commit；限制改动范围（只动…；6.自测：单测+真实场景冒烟；AI 报告“已通过”须…；7.独立审查：另一模型/另一 Agent（无写代码上…；10.回写：本次踩坑和纠偏写入 AGENTS.md 或…
RND-29 AI 工具使用经验沉淀、培训与互助排障 1.在 AI 工具群用话题按模板报问题，先自查手册 …；6.新工具/新订阅发放前，指定试用人按模板写集成教程…；8.每月第一周复核手册，过期内容下线；每季度做一次工… 2.机器人先检索 FAQ 自动回复，未命中再由值守人…；5.把新问题写进 FAQ，更新渠道状态表（渠道、可用…
RND-30 研发编码与工程协作规范宣贯 1.发现缺口：同类问题第 2 次出现即登记到规范待办；6.新人：入职清单含规范总索引和 Git 教程，3 …；8.复审：每季度检查规则是否过期、多处副本是否一致 2.起草或修改：写进对应仓库 AGENTS.md/C…；4.工具化：lint 告警按错误处理，commit …；5.发布：研发通知群发变更摘要和链接，更新总索引
RND-31 Git 分支管理与协作规范 1.建仓用模板：默认私有；main/dev（或 ma…；4.提 PR：目标分支正确，标题写需求内容，正文含需…；7.冻结：发版前冻结 dev/test 不合新提交，… 3.每日开工前 rebase 基线；每次有效改动 c…；6.未来版本隔离：下一版本代码进独立版本分支或用开关…；9.合并后删除功能分支；每周机器人推送超过 14 天…
RND-32 PR 提交与代码评审合并 1.确认工单并认领；方案类/重要改动先在 issue…；3.按模板提 PR：标题 type(模块)+工单号，…；5.按 CODEOWNERS 自动指派评审人，机器人…；8.合并：默认 squash；资金/计费/权限/sc…；10.工单流转为“待测试”，测试对照 PR 验收 2.自测并跑 AI 预审（规范 + 需求符合度、超范…；4.等 PR check 通过后再请求评审；失败先自…；5.按 CODEOWNERS 自动指派评审人，机器人…；11.机器人每日 10:00 汇总超 24 小时未评审…
RND-33 AI 代码评审与夜间自动评审 2.合规与成本审批：代码外送范围、单月费用上限；8.全库审计：每月第 1 周或发版前跑一次，输出报告… 3.评审机器人部署到 CI runner/服务器；P…；4.夜间批量：22:00 拉最新默认分支，多轮评审至…；5.次日 10:00 前推送报告链接并 @ 各仓库复…；8.全库审计：每月第 1 周或发版前跑一次，输出报告…
RND-34 数据库 Schema 变更与迁移脚本 3.PR 勾选“含 DB 变更”，在变更登记表新增记…；8.生产执行前做快照，确认执行窗口与回滚方案 2.编写迁移、回滚、回填脚本，更新 docs/mig…；4.多人改同一迁移目录：先合先得，后合者 rebas…；6.测试库执行（CI 自动执行或放行人执行），群内回…
RND-35 数据库性能、慢 SQL 治理与数据库故障… 4.慢查询、连接池、内存阈值告警推群并 @ 值班人；8.业务负责人对俱乐部/客户发说明；11.优化不可行时，业务负责人与 CTO 决定升配/换… 1.PR 勾选“含复杂 SQL”，附执行计划与数据量…；4.慢查询、连接池、内存阈值告警推群并 @ 值班人；9.根因定位：以执行计划验证（不只静态分析）；疑似厂…；12.复盘：AI 汇总群消息生成时间线草稿，指挥人补根…
RND-36 依赖版本锁定与供应链管理 1.盘点各部署栈与仓库的镜像/模块/底座版本，形成清…；7.回归通过后更新清单，机器人通知所有环境负责人（含… 2.关键镜像推内部镜像仓库；Go/npm 依赖走内部…；3.compose 作为唯一来源由 updater …；4.CI 校验：镜像不得为 latest；lock …；7.回归通过后更新清单，机器人通知所有环境负责人（含…；8.离线/信创：每个 tag 在离线环境构建验证，失…；9.现场部署只用清单内“已验证”版本，部署前脚本跑冒…
RND-37 CI/CD 流水线建设与构建资源管理 1.发现 CI 问题后在 CI 工单/专用群登记（附…；4.资源不足：提资源申请（规格、理由、费用），CTO…；10.凭据与配置清单化：Secrets 名称、用途、配… 5.runner 注册/升级：token 由 Git…；6.流水线规范：PR check 只跑快速集（Lin…；7.门禁：受保护分支要求 CI 通过才可合并，测试豁…；8.监控与清理：磁盘、队列长度、失败率、runner…；9.产物存储：日构建保留最近 N 个版本，正式构建长…
RND-38 CI/构建失败排查与恢复 1.按报障模板在产研测群（或 CI 故障话题）报障，…；4.止血：切备用 runner/机器、切国内镜像、加…；6.发恢复通知：影响时段、根因、临时措施、遗留问题；…；7.登记故障；同一根因 7 天内复发 ≥2 次或中断… 5.重跑失败 job、手动触发 nightly/re…；8.每日巡检 nightly/PARTIAL 结果，…
RND-39 提测、产品验收与测试验收流转 2.改状态：需求类改为“产品验收”，缺陷类改为“测试…；8.迭代结束前汇总未关闭的 P0/P1 和待验收数量… 1.自测通过，合并 PR，确认测试环境部署成功、版本…；3.状态变更后由机器人 @验收人，附工单链接和环境、…；7.每日推送“待我验收”和“滞留 >2 天”清单；无…
RND-40 测试体系建设与测试设计评审 1.（新团队）先跑通最小流程：开发完成标记 QA →…；5.在迭代固定时段召开测试设计评审会，按模块分场；结…；6.用例入库并分级：level1 长期运营（进回归/… 3.用模板写测试设计/计划；可用 AI 依据 PRD…；8.迭代结束后把稳定的 level1 用例转自动化，…
RND-41 发版前测试冲刺与测试人力调配 1.迭代开始时填测试人力分配表（项目 × 人 × 投…；3.出冲刺计划：按模块拆用例，生成认领表（用例-模块…；5.开 30 分钟对齐会：研发/产品至少 1 人讲功…；6.按认领表执行，结果当天回填；缺陷提工单（RND-… 2.每日看待测量与剩余人日，满足触发条件时宣布进入冲…；3.出冲刺计划：按模块拆用例，生成认领表（用例-模块…；7.每日固定时间站会：过测试进度、缺陷修复、验收进展…；8.出测试报告并召开 Go/No-Go：未解决 P0…
RND-42 冒烟测试与核心用例回归 1.部署成功后发提测通知：版本、更新日志、修复工单、…；6.发布后生产冒烟：只覆盖核心流程，使用专用测试账号…；7.内测放量：公司内测 → 小范围公测 → 正式；附… 1.部署成功后发提测通知：版本、更新日志、修复工单、…；2.测试环境冒烟：按清单逐条执行，记录 PASS/F…；4.修复后定向回归，并复跑受影响模块的冒烟用例；8.维护用例：新增重要功能稳定后纳入冒烟集，每月清理…
RND-43 性能压测与容量评估 1.提交压测申请（目标、环境、key、窗口、预算），…；3.准备环境：确认压测机连哪个环境；mock 上游可…；4.发窗口公告：起止时间、影响范围、环境地址、联系人…；8.恢复：清理/重置压测数据，恢复配置；发结束通知 3.准备环境：确认压测机连哪个环境；mock 上游可…；4.发窗口公告：起止时间、影响范围、环境地址、联系人…；5.执行：探测（Probe）→ 基准（如 8 并发 …；6.出报告：并发档位、成功率、耗时分布、瓶颈定位、容…；8.恢复：清理/重置压测数据，恢复配置；发结束通知
RND-44 上线前安全测试、资金逻辑专项测试与漏洞修… 5.漏洞登记与分级：严重/高/中/低，写明影响面和攻…；7.门禁放行：清单逐项打勾，严重和高危清零，中危以下… 2.自动扫描：源码与依赖扫描、安装包敏感信息扫描（私…；4.资金专项：金额边界（负数、溢出、精度、最小单位）…
RND-45 AI 辅助与自动化测试验收 3.确认后冻结锚点，后续改动须重新确认 1.工单转“产品验收”时，机器人扫代码生成“实现锚定…；4.转“测试验收”时，AI 依据锚点生成用例并在测试…；5.执行报告回写工单：用例清单、步骤、截图/录屏、通…；7.每迭代统计 AI 结论与人工结论的一致率、误判案…
RND-46 UI 设计交付与视觉/交互走查 1.需求评审通过后登记设计需求，标注"先出稿再开发"…；2.出设计稿并填写设计交付清单（稿、切图、文案、各状…；4.提交视觉走查：截图/录屏 + 环境版本 + 对照…；9.迭代测试中发现交互差异，先查迭代会纪要，纪要未覆… 4.提交视觉走查：截图/录屏 + 环境版本 + 对照…；5.视觉与交互走查，逐条输出问题（圆角、色值、间距、…；7.修复问题，PR 附改前/改后截图；合并前做 UI…
RND-47 测试账号、测试额度与测试数据管理 1.提交测试资源申请（账号/企业/权限/额度/造数）；4.凭据通过密码管理工具或一次性链接发放，台账登记（…；6.测试服上游真实充值：先提审批再充值，禁止先充后补…；8.测试结束或到期后清理自己的数据；共享环境清数据前…；10.月度对账：测试服充值、消耗与台账核对，回收过期账… 3.新建账号/企业/orgid，按标准额度配置余额，…；5.余额低于阈值时机器人推群并@网关研发；测试环境虚…；7.造数优先用种子数据脚本或固定测试企业；需改库的由…；8.测试结束或到期后清理自己的数据；共享环境清数据前…；10.月度对账：测试服充值、消耗与台账核对，回收过期账…
RND-48 开发/测试/生产环境分层与共享环境占用 2.每个环境登记台账，凭据只写存放位置不写明文；3.占用/变更申请：在台账登记或用机器人命令"占用/…；7.变更后更新台账（版本/用途/状态）、简单冒烟并通…；8.季度盘点：台账与实际机器核对，回收闲置，查清不明… 3.占用/变更申请：在台账登记或用机器人命令"占用/…；5.变更前机器人自动@当前占用人并发群公告；7.变更后更新台账（版本/用途/状态）、简单冒烟并通…
RND-49 测试环境部署与更新通知 3.加发布锁：同一环境同一时间只允许一个发布；8.工单转"待测试/待验收"，测试开测 1.PR 合并后登记待发布队列（组件、PR、工单、是…；2.发布预告：环境、组件、来源分支、预计中断窗口，询…；4.核对构建来源分支与 run 后触发构建；需重跑时…；5.部署/滚动更新；期间测试遇到异常先看锁状态，不报…；6.完成播报：版本/commit、变更清单、对应工单…；7.失败：机器人自动@提交者；提交者 30 分钟内响…；8.工单转"待测试/待验收"，测试开测；9.每周统计失败类型（lint、依赖版本、lock …
RND-50 版本封版、打 tag 与发布分支管理 1.公布发版日历：收口日、冻结时间、rc 冒烟窗口、…；7.rc 部署验收服冒烟，给出放行结论与遗留问题分级… 1.公布发版日历：收口日、冻结时间、rc 冒烟窗口、…；2.每日收口播报：未关闭工单数、P0/P1 数，标注…；5.冻结预告与执行：到点停止向发布线合入非修复代码；6.全仓库打 rc tag 并建 hotfix/vX…；7.rc 部署验收服冒烟，给出放行结论与遗留问题分级…；9.正式 tag 前比对"发布分支 vs main"…
RND-51 正式版本发布上线 1.创建发布单，定版本号、组件、窗口（避开深夜与大会…；5.发布前检查：备份 PG/Redis，核对环境变量…；6.发布预告：告知窗口、影响范围、预计中断时长，确认…；10.发布公告+中文更新日志，推内部群、业务方群；客户…；11.观察告警与错误率、跟踪客户反馈，关闭发布单 2.封版：冻结发布分支，确认修复已 cherry-p…；3.生成"已进版本/未测"清单，未通过测试的功能隔离…；5.发布前检查：备份 PG/Redis，核对环境变量…；7.按序部署：数据库迁移→服务端（滚动/优雅停机）→…；8.生产冒烟（主流程+本次 P0 用例），清 CDN…；10.发布公告+中文更新日志，推内部群、业务方群；客户…
RND-52 客户端打包、签名与安装包分发 1.在版本台账登记打包申请，确认版本号、分支与渠道；6.上传 COS 固定目录，更新版本台账与统一下载页… 2.对指定 commit 做签名预授权，避免构建后审…；3.CI 构建多平台矩阵，失败自动告警到群；4.签名与公证：Win 代码签名，Mac 签名+公证…；6.上传 COS 固定目录，更新版本台账与统一下载页…；8.机器人推送发布卡片到固定群并置顶
RND-53 OTA 在线更新与强制更新 1.兼容性检查：服务端是否已部署，登录/协议字段是否… 2.在 LeapUpdate 登记版本、包/镜像、渠…；3.先推内部渠道（公司内测机、50/51），小范围灰…；4.升级冒烟：从上一版本和"最老在用版本"各升级一次…；6.公告群推送升级通知：版本号、更新要点、已知问题、…；7.推送 24 小时后核对版本分布：逐一提醒仍在旧版…
RND-54 Hotfix 紧急修复准入与发布 1.在 hotfix 看板登记：工单、严重度、影响面…；10.确认修复已在 main、各仓库无漏同步，关闭申请… 3.指定当次发布人；从线上 tag 建 hotfix…；4.修复先合 main，再只 cherry-pick…；5.每日 17:30 冻结 hotfix 分支，机器…；6.更新版本号，打正式包（签名）和带 hotfix …；7.部署到 51 验收环境，测试按清单逐单验证，并冒…；9.核对各组件都已配置下发、客户端确实拿到新版本；群…
RND-55 Agent 容器镜像构建与发布 8.在镜像台账登记版本、哈希、各环境/客户当前版本 2.触发 CI 打包：workflow 自动读取 S…；3.构建完成，机器人在群里推送卡片（tag、哈希、c…；4.在 50 重建容器（数据目录先备份），按测试范围…；5.LeapUpdate 先发 preview 渠道…；7.发布后在生产验证图生图、内置 Skill 和文件…
RND-56 产品 Skill 开发、评审、上架与内置… 1.在 Skill 台账登记：名称、slug、来源、…；9.反馈统一进 Skill 反馈表；更新时版本号递增… 2.按规范开发；用 creator 工具做结构校验；…；3.自测：selfcheck 通过，在测试实例安装并…；5.CI 自动校验 manifest、selfche…；7.发布：内置/官方 → 合入 official-s…；8.在 50 和生产抽检可见、安装、调用；在公告群推…
RND-58 生产变更管控（备份、灰度、配置、访问审批… 1.提交"生产变更申请"；3.按 X-SEC-18 申请限时访问权限，通过堡垒…；8.异常超过阈值立即回滚；结果、备份位置、实际耗时写… 4.在线备份：数据库 dump 或卷快照，不停服；记…；5.按脚本执行：IaC 先 preview 再 up…；6.灰度：先灰度名单、开关或小比例；观察告警和日志 …；7.验证人按清单验证（功能、权限、数据、计费、证书）…
RND-59 线上部署回滚 1.发现人在项目群按报障模板报告，@后端负责人；6.在项目群通知回滚结果、影响范围和后续安排；涉及客…；8.资金类或回滚出错的，48 小时内按模板复盘，并关… 3.从上线记录取上一个正确版本的 sha，由基线核对…；4.执行回滚：在 Drone 选定构建，执行前在群里…；5.机器人比对线上 sha 与目标 sha；测试回归…；8.资金类或回滚出错的，48 小时内按模板复盘，并关…
RND-60 小程序/App 商店提审与上架 2.按提审清单自查：清测试数据、核对类目、检查协议敏…；3.提交审核，在提审台账登记版本、时间、素材，群里告…；7.新的驳回原因和处理办法写进原因库；8.每月检查台账，保证金、年审、主体迁移到期前提醒；… 2.按提审清单自查：清测试数据、核对类目、检查协议敏…；4.跟踪审核状态，状态变化由机器人通知群；5.被驳回：查驳回原因库，按应对方案修改（屏蔽或改页…
RND-61 客户演示前版本冻结与演示环境准备 1.在"演示日历"登记演示（时间、对象、演示人、环境…；4.机器人在研发群发布冻结窗口：演示前 4 小时至演…；5.准备演示环境：固定环境不与日常测试共用；开子域名…；7.核对第三方服务额度与到期日（文档解析、模型额度等…；10.演示结束后解冻并在登记表补复盘（问题、客户反馈、… 4.机器人在研发群发布冻结窗口：演示前 4 小时至演…；6.准备演示数据与账号：用造数脚本生成真实感数据，假…
RND-62 内部 Demo/原型/静态页面部署 1.填写 Demo 部署申请（产物形态、用途、访问范…；7.把链接发给申请人，并登记 Demo 台账；8.到期前 3 天机器人提醒申请人续期或下线，过期未… 3.静态页：通过机器人或托管入口上传即发布，自动生成…；4.带后端：代码迁入 Gitea 组织仓库，按"原型…；6.自检：国内网络可访问、HTTPS 正常、无 40…；8.到期前 3 天机器人提醒申请人续期或下线，过期未…
RND-63 信创适配开发、打包与验收 1.用统一表单提交适配需求（芯片+OS+端+客户+数…；3.借测试机/准备虚拟机并登记借用（机型、来源、期限…；6.提缺陷单：必填芯片、OS、包链接、终端日志、与 …；9.每日 18:30 前在适配表更新"今日进度/卡点… 4.流水线构建：rolling 跟 main，rel…；5.按矩阵测试（复用非信创测试 SOP 用例 + U…；9.每日 18:30 前在适配表更新"今日进度/卡点…
RND-64 行业版插件开发、接入规范与交付 3.填提测单（环境、包、待测范围、验收人），合并到测…；5.业务验收：测试统一开验收账号并发"验收入口说明"…；7.下发前检查：版本号、客户端版本、插件版本、模型标…；10.更新"企业-实例-行业版-已下发版本"台账；如误… 2.按插件规范开发，使用脚手架；提交前跑 selfc…；8.实例配置：在 Cloud 打行业模型标签，在 L…；9.先下发到测试机验证入口与版本，再下发正式企业实例…
RND-65 移动端研发协作与构建发布 3.外部团队每个工作日 18:00 前按模板同步进度… 3.外部团队每个工作日 18:00 前按模板同步进度…；4.接口变更或新增时同步更新 Gitea wiki …；5.代码合入后从最新 main 构建，发布提交号、变…；6.测试按清单测试，缺陷只提到 Gitea Leap…
RND-66 支付功能联调与收款商户管理 1.发起"支付测试付款"飞书审批（场景、轮数、金额、…；2.对公网银测试：提前预约经办盾、审核盾两人的在岗时…；5.切换前检查：分账比例上限、进件主体完整、结算方式… 6.在工单中执行切换，提前通知产品侧；测试验收后关闭…；8.开启支付异常告警与每日对账脚本（订单状态 vs …
RND-67 新模型/上游渠道/第三方 API 接入与… 1.在"模型上架台账"登记需求并建 LEAP 工单；4.申请上游 key 与额度（测试/生产分开），审批…；10.台账状态更新为"已上线"，机器人通知需求方与相关… 2.成本对比：与现有渠道比价，比现有便宜或补能力缺口…；5.在 aiapi/v5 配置渠道、模型 ID、价格…；6.部署测试服，确认测试 key 余额与环境变量；部…；7.验收：冒烟、多轮/流式/思考强度、稳定性抽样、逐…；9.同步下游：LeapCore 总 NewAPI、L…；10.台账状态更新为"已上线"，机器人通知需求方与相关…
RND-68 模型与上游供应商选型评测 1.在"模型评测记录"登记评测需求（对象、目的、基线…；7.按模板出评测报告并发评测群，供应商沟通记录同步归…；9.结论、评测集版本、报告链接写回评测记录；每月复盘… 3.开评测 key 与额度，确认渠道权限，压测前通知…；4.跑固定评测集：质量（与官方 trace/指纹对照…；5.本地部署类：在目标硬件用标准镜像部署，记录并发与…；6.成本与折扣核算：按官网价自动换算折扣，统一汇率口…
RND-69 模型定价、倍率与成本价配置 1.在价格台账新建变更记录：来源、模型、渠道、生效时…；6.上生产并同步所有下游（含客户本地网关）；折扣到期…；7.生产抽测 1 次；在通知群发布变更（模型、旧价→… 2.核成本价：按官方文档填四价及阶梯/分时/按次规则…；3.按规则算对外价（默认成本×档位倍率；官方原价类、…；5.账单级验价：用固定请求集（含高缓存命中、长上下文…；7.生产抽测 1 次；在通知群发布变更（模型、旧价→…
RND-70 计费准确性验证与账单/缓存对账 1.计费功能提测或异常反馈登记为工单，注明产品线、模…；2.提交提测材料：接口说明、观测点、测试账号、单测记… 3.用固定请求集在测试服跑数，按台账价计算每笔预期扣…；4.三方比对：平台扣费 vs 配置价预期 vs 上游…；7.上线后每周自动对账出周报；月末按主体（鼎慧/模态…
RND-71 模型档位路由与渠道切换变更 1.提交变更单：目标、原因、影响范围、窗口、回滚点、…；7.LeapAll 与客户本地网关同步切换；价格台账…；8.在变动通知群发公告：变更内容、影响范围、下游截止… 3.先新增渠道/模型，不改不删旧配置；用脚本核对目标…；5.跑固定回归集：文本、图片输入、生图、搜索、PPT…；8.在变动通知群发公告：变更内容、影响范围、下游截止…
RND-72 上游模型故障告警响应与降级 1.告警卡片自动 @ 当班值班人并建故障工单；人工反…；2.认领并在群内回复“已认领”；6.通报：研发群发结论（模型、影响、预计恢复）；涉及…；8.P0/P1 复盘：时间线、根因、影响、改进项（监… 1.告警卡片自动 @ 当班值班人并建故障工单；人工反…；4.定位层级：官方上游 / 渠道（余额、限额、被墙、…；6.通报：研发群发结论（模型、影响、预计恢复）；涉及…
RND-73 上游账户余额、凭证到期与 Token 消… 1.所有上游账户与第三方凭证登记入台账；个人持有账号…；2.按 7 日平均消耗设余额阈值（不低于 7 天用量…；5.发起充值申请（账户、金额、用途、预计可用天数），… 3.每日拉取各账户用量与余额，按产品线/主体出日报，…；4.低于阈值自动加急预警，@管理员与产品线负责人；8.内部测试 Key：提申请（用途、额度、有效期、渠…
RND-74 NewAPI/AI 网关部署、升级与值守 1.提交网关需求/升级单：用途、容量、版本、窗口，建…；7.纳入探测监控与网关台账，更新调用链拓扑文档；8.值守与交接：一主二备排班；维护人变更时按交接清单… 3.按基线一键部署：compose 模板、外部数据库…；4.部署检查：汇率、渠道、隐藏模型、磁盘、安全组；从…；5.功能测试（非流式→流式→长连接）与压测，出报告
RND-75 线上/测试环境故障响应与复盘 1.报障：在「故障响应群」用报障模板发帖（环境/现象…；3.首次通报：在群内发「已知悉 + 级别 + 处理人…；6.同步进度：在同一话题内定时更新（P0 每 30 …；7.确认恢复：测试/报障人复测主链路；排查受影响客户…；8.关闭登记：填写故障台账（开始/恢复时间、影响、临…；10.评审与闭环：在周会上过报告，改进项转工单并在台账… 1.报障：在「故障响应群」用报障模板发帖（环境/现象…；4.定位：核对机器标识 → 看监控（CPU/内存/磁…；9.复盘：P0/P1 必须写事故报告（时间线、影响、…
RND-76 用户问题日志收集与定位 1.按“报错反馈清单”在客户端反馈按钮或反馈群提交；8.沉淀：同类问题出现第 3 次时，补进常见错误 F… 2.自动追问缺项，并匹配已知问题和规避办法；3.上传诊断包：客户端一键上传到 COS 私有桶，生…；4.AI 初判：解析日志和 trace_id，匹配常…；8.沉淀：同类问题出现第 3 次时，补进常见错误 F…
RND-77 错误提示、日志上报与可观测性规范 7.规范变更在研发群公告，并在文档中记录版本 1.从故障台账和用户反馈中汇总“错误提示/定位”类问…；5.校验：CI 增加上报冒烟（模拟异常，检查是否进入…；6.线上抽查与降噪：每周看 Top 错误，确认能按 …
RND-78 生产告警认领、分级与降噪 1.分级推送：critical（资金/支付/主链路）…；2.认领：值班人点卡片“认领”或回复“已认领”；6.关闭：标记“已处理/误报/忽略原因”，填写根因和…；8.规则变更：阈值、通知对象、模板变更先在「告警测试… 3.分诊：查堆栈和日志，判断属于真实故障、业务异常、…；6.关闭：标记“已处理/误报/忽略原因”，填写根因和…；7.每周降噪：统计 Top 噪声告警，按分级规范调整…
RND-79 服务器容量治理与内部研发基础设施故障 1.建台账：登记服务名、负责人、地址/端口、所在主机…；4.报修/报障：内部设施故障在“基础设施报障表单”提…；7.变更公告：迁集群、改端口/IP/域名、改网络/防…；8.验证并更新台账：变更或修复后，验证调用方、web… 2.部署基线：新机/客户机部署前跑检查脚本——数据库…；3.容量监控：磁盘 ≥ 80% 预警、≥ 90% 严…
RND-80 系统/主体迁移与生产数据订正 2.清单与负责人：在迁移检查清单中逐项列出事项、负责…；5.公告与冻结：提前通知时间窗、入口变化和冻结规则（…；8.切换与观察：发布新入口并置顶，旧环境下线或改为只…；9.数据订正（分支）：导出异常单并分类 → 圈定影响…；10.归档：迁移方案、清单、核对报告、订正记录归档；把… 3.测试演练：在测试/干跑环境覆盖各商户和各类数据情…；4.备份：迁移前全量备份并校验可恢复；配置定时滚动备…；7.核对验收：用校验脚本比对迁移前后的用户数、订单数…
RND-81 内部 AI 机器人/Agent 平台部署… 1.填机器人上线登记：用途、owner、备岗、模型、…；5.上线前测试：@ 才响应、越权指令被拒、建单前确认…；6.设置飞书可用范围，群内发使用说明卡片：能做什么、…；9.月度复核：活跃度、调用成本、权限、owner 是… 3.按模板配置：只响应 @ 与私聊、非工作时段静默、…；4.构建镜像推统一镜像仓库，版本号和变更说明写入 R…；9.月度复核：活跃度、调用成本、权限、owner 是…
RND-82 Agent 评测集与评测体系 1.定评测目的、范围、基线和通过线，登记评测看板并指…；8.失败样本回流评测集与需求池；回归结论作为发版闸门… 2.构建/更新评测集：按产品承诺功能构造 case，…；4.批量跑评测：每个 case 多次 trial，记…；6.改动后先跑定向评测，再跑全量回归，无劣化才进入灰…；7.出报告（图表/HTML，不贴控制台截图），周四评…
RND-83 Agent 生成文档质量问题治理 1.反馈人在反馈群提交，值班研发当天要求补齐原始提示…；7.随版本发布，关闭 issue 时通知反馈人复验；8.客户演示前按清单检查模板、水印、字体、标题颜色、… 2.打标签：文件类型（PPT/Word/Excel/…；6.修复后跑文档产出回归样例集（每类 ≥ 10 个典…；7.随版本发布，关闭 issue 时通知反馈人复验
RND-84 知识库数据清洗入库与更新 1.发起更新：登记范围、原因、截止日，指定数据研发与…；4.入库前检查磁盘余量并备份，申请临时公网访问窗口迁…；8.关闭公网窗口，导出数据版本归档，群内通知更新完成… 2.检视爬虫：脚本统一放仓库，失效脚本用 AI 重写…；3.采集与清洗：去重、字段校验、格式统一，出清洗报告…；5.入库完成即触发标签脚本，告警逐条判断是否可忽略并…
RND-85 研发工作与项目交接 1.在项目群公告交接对象、接手人、截止日，同时建飞书…；3.工单处理：进行中的做完或转派，未开始的释放回池，…；7.更新系统台账中的负责人、需求对接人，通知业务方与…；8.离职/调岗场景按 X-SEC-08 回收交出方权… 2.按模板写 handoff，可让 AI 从代码与会…；7.更新系统台账中的负责人、需求对接人，通知业务方与…
RND-86 技术文档与上下文知识沉淀 3.放入约定位置：技术细节放仓库 docs/<类别>… 2.按模板写文档，可让 AI 从代码、会话、群记录生…；4.更新索引：仓库统一用 AGENTS.md，只放索…；7.AI 会话中的关键决策与上下文按项目归档（脱敏）…；8.每季度清理过时文档、重建索引，机器人汇总变更摘要…
RND-87 技术分享、内部 Skill/工具发布与推… 1.填发布登记：名称（查重）、用途、owner、版本…；6.周五分享会：周四前定排期，经验、工具、评测结果上…；7.新工具/新规范学习：发飞书任务带截止日，完成后打… 2.安全扫描（权限、执行命令、密钥、外部来源代码）+…；3.推组织仓并打 tag，不再通过 zip 私下分发；4.写使用说明/教程（可 AI 生成）：安装、示例、…；5.机器人将 Release 推送到 AI 探索群/…；10.技术主管每周同步本组成果与错误，AI 汇总成周报
RND-88 外包数据采集委托与验收 3.选外包，确定计价与付款条件（验收合格后付款、打回…；4.任务分配：按站点分给分包，任务表登记站点、分包方…；8.出验收报告，提交结单付款审批；数据转 RND-8… 5.样例验收：每个站点先交 sample，脚本校验字…；6.分批交付：大站点按批交付（单批建议 ≤ 10G）…
RND-89 对外技术咨询答复与方案文档评审 1.填写技术咨询单（来源、问题、背景、期望时间、答复…；3.未命中 FAQ：判定类型（可行性/架构问询/背调…；7.需出书面方案/说明：作者按对外文档模板撰写，按评…；8.评审：评审人用文档评论提意见，不直接改正文；涉及…；10.提问方通过约定渠道发出，并把发出版本链接和对方反…；11.把通用问答沉淀为 FAQ 条目，口径变化时更新 2.先查产品能力 FAQ，已有口径直接引用答复并关单；11.把通用问答沉淀为 FAQ 条目，口径变化时更新
RND-91 产品版本生命周期与私有化实例版本支持策略 2.每次正式发版登记版本号、发布日、支持截止日；4.对临近截止的版本向客户与销售发停止支持通知；6.到期后旧版本只做安全修复或不再修复 3.从实例台账/OTA 后台导出在用版本分布
RND-92 研发数据使用合规（数据集登记、客户数据授… 1.提交数据使用申请；4.登记数据集（来源、授权、级别、位置、期限、可访问…；6.到期删除或续期，删除后登记 3.脱敏（姓名、手机号、证件号、客户名称）或只取最小…；6.到期删除或续期，删除后登记
GEN-01 制度与 SOP 起草、签发与发布宣贯 1.在“制度/SOP 台账”登记名称、起草人、适用主…；3.草案共享至负责人群，@相关负责人并写明截止时间，…；4.部门负责人审核，部门内制度可直接转第 7 步发布；6.行政盖章并留存鲜章版原件；CEO 签发并抄送董事…；7.发布：全员制度由综合部在通知群发“一句话版+完整…；8.发布同时用表单征集疑问；组织宣讲会（线上+线下、…；9.写入 SOP 合集/知识库并标注版本号；涉及子公… 2.按模板起草，必须写明适用范围（哪些主体/人群不适…；7.发布：全员制度由综合部在通知群发“一句话版+完整…；8.发布同时用表单征集疑问；组织宣讲会（线上+线下、…
GEN-02 全员通知发布与必读信息分级 4.A/B 级在通知群发布（仅授权人可发），A 级同…；6.A 级通知用机器人卡片/表单统计已读与回执，拉出…；8.变更通知：原通知下回复“已变更”，并重新发一条带…；9.A 级通知同步写入知识库“通知归档”，制度类挂对… 3.按模板写“一句话版+完整版”，用正式书面语，写清…；6.A 级通知用机器人卡片/表单统计已读与回执，拉出…；7.机器人按名单 @未完成者，抄送其部门负责人
GEN-03 工作沟通渠道与群职能规则 2.新需求/项目涉及 3 人以上：建项目专群，写群公…；5.结论、需求、文档链接写进工单或总目录；日报等文档…；6.客户资料与沟通统一沉淀到飞书（外部群或文档）；客…；9.新员工入职培训讲解《工作沟通规范》 4.会议使用飞书日程；开启智能纪要，纪要发回对应群；7.发现工作内容出现在闲聊群/私聊：任何人可提醒“移…；8.每两周用 AI 整理项目群聊信息，生成进展摘要并…
GEN-04 沟通礼仪与对内外称谓、时间规范 3.写入员工手册、产研群公告；问题反馈模板做成群快捷…；5.工作时间（工作日 9:00～19:00，待确认）…；8.入职首周培训讲解本规范 4.反馈问题时按模板一条发完；接到任务先确认能否承接…
GEN-05 临时加急审批与关键人联络 1.判定紧急等级，在审批单“加急原因”字段写明影响与…；2.只提交一张审批单，不重复提单；需改内容时撤回重提…；3.P0/P1 审批提交后用飞书“加急”提醒审批人；7.审批人外出前设置审批代理，并在飞书状态中注明 4.P0 超过 2 个工作小时、P1 超过 1 个工…；9.每月汇总加急与代理审批记录，查找高频加急事项并优…
GEN-06 节假日前工作安排与值班 1.启动节前规划：列出假期前必须完成/可延后的任务与…；3.排研发值班（按产品线）与客户反馈值班，每天至少 …；5.冻结前完成更新检测与回滚验证，确认假期内无计划发…；6.发布值班表与升级路径，同步客户支持与销售，必要时…；7.假期内值班人保持飞书可达，按时限响应；每日在值班… 5.冻结前完成更新检测与回滚验证，确认假期内无计划发…；7.假期内值班人保持飞书可达，按时限响应；每日在值班…
GEN-07 内部分享会与学习活动组织 1.每月底在排期表征集下月议题，小组学委推荐，讲者认…；3.排期表自动生成飞书日程（主讲、场地、会议链接），…；6.需管饭或经费：按活动经费申请；7.举办：主持人控时（全员培训日每人约 10 分钟）…；9.在排期表登记讲者与参与情况，按积分制度申报激励 3.排期表自动生成飞书日程（主讲、场地、会议链接），…；4.讲者提交材料；大会/年会/对外分享稿交审稿人审阅…；8.会后录屏转 AI 摘要，材料与摘要入知识库“内部…
GEN-08 团建与内部文体活动组织 1.发起人填写活动方案，使用公司经费的提交预算申请；3.发投票/报名，写明时间、地点候选与截止时间；全员…；5.统一采购（奶茶、食材、奖品），按报名名单下单，避…；8.收集发票报销，登记活动台账（人数、费用、满意度） 5.统一采购（奶茶、食材、奖品），按报名名单下单，避…；6.活动前提醒（时间、地点、带什么），机器人在群内 …
GEN-09 AI 工具订阅开通与使用补贴管理 1.采购或升级完成后登记套餐、节点、席位、有效期、开…；3.在固定的 AI 工具群发开通/升级通知：变化内容…；4.每月固定日推送 CDK/补贴到账通知，附激活步骤…；7.超出额度部分凭发票走报销审批；产研测试额度走飞书… 2.向供应商核对实际开通名单，与应开通名单比对，差异…；4.每月固定日推送 CDK/补贴到账通知，附激活步骤…；5.导出充值与消费数据，生成未激活/未充值名单并推卡…；6.月末核对充值与使用记录，确定补贴取消/扣减名单，…；8.汇总供应商用量并对账付款；不用的账号列入关停清单
GEN-10 自研产品内部推广使用与反馈闭环 1.发布内部使用通知：安装包与版本号、账号获取方式、…；2.按部门名单批量开通账号与远程接入，回填开通状态；3.向部门负责人下达任务：安装、建团队空间、指定反馈…；5.组织分层培训（远程访问、FDE 初级、信创等），…；6.使用问题与需求统一填反馈表，不在群里零散发 7.每周汇总反馈，分类（Bug/需求/咨询）转产品工…；8.新版本发布时同步更新安装包链接与更新说明，不重复…
GEN-11 集团档案整理与合同台账管理 2.各部门推选档案组长，档案委员建档案整理群并公布名…；3.发前置准备通知：线上文档建部门汇总文件夹放快捷方…；4.预约日程，按排期逐部门盘点，现场确认归属、缺失、…；5.登记档案台账（只归集一级目录，信息最小化）与合同…；7.设置权限：合同台账对董事会开放，借阅报部门负责人…；8.新增合同双方盖章后触发入库提醒，当周补登台账；9.月度自查（组长）、季度抽查（档案委员），问题清单… 5.登记档案台账（只归集一级目录，信息最小化）与合同…；8.新增合同双方盖章后触发入库提醒，当周补登台账
GEN-12 知识库与协作文档沉淀（含飞书空间治理） 1.按模板建项目/团队知识库目录和常用文档入口页，公…；2.规范性文档（方案、规范、手册）直接在知识库创建；…；3.阶段性迁移：发迁移任务与截止日，完成者在进度表打…；4.新人入组 3 个工作日内填写个人说明书；团队协作…；7.工作台视图规则：个人视图一律私密；公共视图只由管… 3.阶段性迁移：发迁移任务与截止日，完成者在进度表打…；5.每个项目一份上下文文档：完成事项、更新资料、待办…；6.Agent 工具产出文档：导出 Markdown…；8.月度检查：命名、分类、未迁移文档、多余公共视图，…
GEN-13 荣誉资质、宣传素材与对外信息口径库 1.建库：按公司介绍/产品/行业版/案例/荣誉资质/…；2.向各部门、项目负责人收集最新材料，标注版本号和适…；6.外部活动/路演表单：按口径页填写；口径页未覆盖的…；7.获得新荣誉/证书、产品发版改变能力描述时，当周入… 5.对外取用：先查库，按场景组合；库里没有的由维护人…；7.获得新荣誉/证书、产品发版改变能力描述时，当周入…；8.季度复核：清理过期材料，比对各版本说法是否一致，…
GEN-14 公司对外账号、证照年检与年报管理 1.建总台账：账号/证照/编码名称、主体、绑定手机号…；3.新开通账号：需求方提交申请（用途、平台、主体），…；4.研发需登录公司身份平台时，优先分配独立子账号/空…；8.回执、证书、新账号信息存入档案并更新台账下次到期…；9.季度盘点：电话卡和账号在谁手里、是否在用、到期日… 6.到期前 30 天、7 天机器人提醒责任岗位；主管…
GEN-15 工商变更与新机构设立手续 1.发起任务单：写明事项类型、目的、完成节点、对接人；2.按事项类型调出材料清单模板，列出缺项与提供人，发…；3.向股东、各部门收集材料，逐项打勾；5.走用印审批，股东签字盖章；7.领取新执照，扫描上传证照库，原件交档案；8.按同步清单通知税务、银行、社保公积金、飞书主体信…；9.全部材料归档，任务关闭并通报 2.按事项类型调出材料清单模板，列出缺项与提供人，发…；8.按同步清单通知税务、银行、社保公积金、飞书主体信…
GEN-16 政府/领导及合作伙伴来访接待 1.接到来访信息后登记要素，向上级对接人确认人数、时…；2.按模板出接待方案：动线、各点讲解人与时长（总时长…；3.方案发管理层确认，并向行政报备场地与物料需求、向…；7.带回的材料、牌匾当天存档或归位并登记位置；8.照片、视频入品牌素材库，需要宣发的转新闻稿流程 2.按模板出接待方案：动线、各点讲解人与时长（总时长…；4.机器人推送日程提醒给陪同、讲解、摄影人员，附动线…
GEN-17 AI 前沿资讯跟踪与新工具评测分享 2.机器人抓取标题、来源、摘要，按链接去重后写入「A…；4.对“值得试用”的条目指定 1 名试用人，同类工具…；7.周五分享会：每次 2～3 个主题，每个 15 分…；8.评测结论和纪要链接回写情报库；“采用/借鉴”项按… 2.机器人抓取标题、来源、摘要，按链接去重后写入「A…；3.每日推送精选日报；每周五上午自动生成本周情报周报…；5.试用并按模板写评测：场景、效果、成本、稳定性/封…；7.周五分享会：每次 2～3 个主题，每个 15 分…
GEN-18 制度与 SOP 定期复审、版本管理与废止 1.建立总目录，每份文件登记编号、版本、主责、生效日…；4.修订按 GEN-01 发布，版本号加一并写变更说…；5.废止文件发公告、移入归档区并加“已废止”标记；6.更新总目录 2.复审日前 15 天自动提醒主责岗位
GEN-19 员工意见反馈、投诉与违规举报受理 1.公布匿名表单与指定邮箱，写明保密与不报复承诺；7.材料加密归档，限定可见人 —
GEN-20 外部来文来函收发登记与分办 1.签收后扫描登记（来文单位、类型、收到日、期限）；3.按对照表分办，承办人确认接收；6.发文登记并留存回执；7.原件与扫描件归档 4.期限前 3 个工作日自动提醒承办人
CEO-01 年度/季度/月度规划与目标分解 2.发布规划模板、提交截止时间和对齐会日程；6.部门内下发规划并 @ 责任人，要求已读确认；验收…；7.一对一：员工先自评复盘写计划，再与上级逐条对齐，…；8.月度跟踪：更新进度，偏差项在月度负责人会说明 4.召开负责人对齐会：逐部门过规划，删去不挂靠目标的…；8.月度跟踪：更新进度，偏差项在月度负责人会说明
CEO-02 战略论证会与闭门专题研讨 2.锁定时间与会议室，发日程；时间定后原则上不改；3.发布议程与会前共享文档，标明预读内容和需准备的方…；5.开会，开启妙记，按议程推进，当场明确决议与作业；6.发纪要：决议、作业（内容、负责人、截止日期），作…；7.跟踪作业：截止前 1 天机器人提醒，逾期在群内点…；8.汇总作业，整理"会议重点"同步全员，落实事项转入…；9.下次会议开头回顾上次决议落实情况 5.开会，开启妙记，按议程推进，当场明确决议与作业；6.发纪要：决议、作业（内容、负责人、截止日期），作…；7.跟踪作业：截止前 1 天机器人提醒，逾期在群内点…
CEO-03 新业务/创新项目立项与拍板 1.按模板提交立项单/提案；2.登记入立项池，查重；4.一级：创始人兼 CTO 审批预算与资源；7.指定负责人、验证期（内部 MVP 1 周、业务闭…；8.试运行，每周在立项池更新进度；10.通过的转运营/推广并指定接力人；未通过的终止归档… 2.登记入立项池，查重；6.三级：董事会会议决策，会前 3 个工作日发提案，…；8.试运行，每周在立项池更新进度
CEO-04 重大技术/产品方案决策（拍板、公示与记录… 1.争论超过 2 轮仍无共识时，停止群内争论，填决策…；4.一级、二级：公示方案，公示期至次日站会前；三级：…；6.写决策记录并同步到相关群，群聊结论由机器人落表；8.复议：有新证据时提交复议单，原决策人 2 个工作… 6.写决策记录并同步到相关群，群聊结论由机器人落表
CEO-05 决策授权与汇报路径（去单点、防越级） 1.盘点高频问题与决策事项，按类别统计找谁、耗时；5.发布并配置问答机器人自动回复"找谁"；6.汇报规范：给高管的汇报用"结论+依据+需决策事项…；7.例会：会前 1 个工作日填例会信息；半数以上缺席…；8.跨主体/高层需求：由对口产品负责人接收，进需求流… 1.盘点高频问题与决策事项，按类别统计找谁、耗时；5.发布并配置问答机器人自动回复"找谁"
CEO-06 组织架构、汇报线与职责边界调整 1.提出调整需求，写明原因和范围；2.起草架构表与职责 RACI，全员填入架构表；4.影响评估：逐项核对审批代理、权限、部门群、考勤、…；5.发布通知：部门更名/负责人/新设部门、生效日期、…；8.飞书同步：组织架构、直属上级、审批代理人、部门群…；9.用工主体迁移：合同、社保、发薪主体变更，更新人员… —
CEO-07 多项目优先级与人力分配 1.新需求填准入表进入项目池，按收益/客户价值/人力…；2.周一资源盘点：更新人员占用，标出超载（>2 条主…；4.发布本周分工：项目、负责人、本周目标、DDL；6.周中插单：提出人说明要替换哪项，协调人决定；被抽…；9.人力缺口：评估外包或招聘，提交需求 2.周一资源盘点：更新人员占用，标出超载（>2 条主…；4.发布本周分工：项目、负责人、本周目标、DDL；7.周五进度汇报：状态、阻塞、下周计划，机器人收集
CEO-08 跨部门人员借调与技术人员外派审批 2.提交借调/外派申请：目的、人员、时间、地点、成本…；5.预订交通住宿，费用计入对应项目；6.会前确认议程与角色（主持、方案讲解、答疑），发日…；8.借调结束，借出部门负责人确认人员归还，更新人员占… 7.执行外派/会议，结束后回传纪要与待办
CEO-09 项目启动与重大事项跨组对齐会 2.建飞书日程（含会议室/视频会议），在项目群发通知…；5.纪要自动生成；会务人提取“决议/待办/责任人/D…；6.各参与人按模板登记个人里程碑节点；7.会后目标/需求变更：提出人通知会务人，更新登记表…；8.建周期进度同步日程，按里程碑跟进，转入项目组例会 5.纪要自动生成；会务人提取“决议/待办/责任人/D…；7.会后目标/需求变更：提出人通知会务人，更新登记表…
CEO-10 会议召集、会议室预约与纪要归档 2.查询并预订会议室；无空闲则改时段或改线上；3.建飞书日程：邀请全部必参人、挂会议室、写议程和材…；4.在相关群发会议通知，@ 必参人，写明无需参加人；7.校对纪要，提取待办（事项/责任人/DDL）建飞书…；8.纪要归档到对应项目/部门知识库目录 3.建飞书日程：邀请全部必参人、挂会议室、写议程和材…；6.开会：确认关键人到场，开启纪要；7.校对纪要，提取待办（事项/责任人/DDL）建飞书…
CEO-11 周例会与项目组例会 1.投票确定例会周期后固定，建飞书重复日程，邀请必参…；2.用模板创建本期例会文档，按部门/产研分区，发群并…；3.各部门在本部门分区填写进展、卡点、需支持和上期待…；6.整理纪要和本期重点待办（事项/责任人/DDL），…；7.跟踪待办，下期会前更新状态 2.用模板创建本期例会文档，按部门/产研分区，发群并…；3.各部门在本部门分区填写进展、卡点、需支持和上期待…；4.检查未填部门并提醒；6.整理纪要和本期重点待办（事项/责任人/DDL），…
CEO-12 日报/周报（DailyWork）与周期汇… 4.生成部门日报，标注风险与需支持事项；6.按模板形成部门/侧周报，附工单与文档链接；7.部门周报同步到高管周报群，附 3 行摘要（做了什… 1.系统生成个人日报草稿并推送本人；3.推送未确认名单给本人和汇总人；4.生成部门日报，标注风险与需支持事项；5.系统汇总已确认日报生成个人周报草稿，员工确认；6.按模板形成部门/侧周报，附工单与文档链接；8.统计提交率/确认率，发未提交名单；汇总材料供下周…
CEO-13 阶段总结与工作计划收集 2.发正式通知（群公告）＋模板链接＋收集表；5.截止前 2 个工作日及当天提醒未提交者；8.汇总共性问题与下一阶段计划，归档；行动项建任务 3.按模板填写个人总结与计划（可先由 AI 从周报生…；4.汇总团队总结（问题、表现、管理与工作方式优化）；8.汇总共性问题与下一阶段计划，归档；行动项建任务
CEO-14 向上汇报规范与关键节点上报 6.记录决策（结论、负责人、时限）并更新项目清单；7.向相关群同步统一口径 2.按四段式写一页纸（≤ 1 页），结论放第一行
CEO-15 任务指派、催办与闭环跟踪 1.发起任务：写四要素；P0 才可 @ 加急或电话；3.群消息中的任务转为飞书任务进入台账；7.完成或失败：执行人在任务和原群回报“成功/失败＋… 3.群消息中的任务转为飞书任务进入台账；5.汇总各人未完成项、超期项和长期“老账”，推送群内
CEO-16 重大项目/活动复盘 2.用模板建复盘文档，分配板块与截止日，写明输出去向；7.行动项建飞书任务；结论摘要发市场/产品/相关群，…；8.跟踪行动项至关闭；下次同类活动立项时检查 3.AI 从会议记录、群聊拉取时间线与客户提问清单作…
CEO-17 政府部门对接、汇报演示与政策风险应对 1.收到通知后在“政府事务登记表”登记时间、地点、议…；3.按议题指派参会人（技术议题由 CTO 指派技术专…；5.按演示环境检查清单准备：mock 数据、冻结测试…；7.把整改/合规/联调要求逐条登记到反馈表（要求、责…；8.每周同步一次进度；到期前 1 个工作日向对方书面…；10.执行 PlanB：迁移、认证、商城跳转、物料同步… 4.用发言要点模板生成初稿（背景、我方能力、案例、诉…；6.参会/汇报；会后提交纪要：结论、对方要求、我方承…；8.每周同步一次进度；到期前 1 个工作日向对方书面…
CEO-18 高管日程与外部约见管理 1.所有约见请求统一提交到“高管约见表单”（外部请求…；2.查高管共享日历，判冲突，给出 2 个可选时段；4.写入飞书日程（含地点、议题、参会人），同步预订会… 5.机器人提醒：前一天 18:00 推送次日日程；开…；7.会后记录结论与待办，涉及后续事项转相关负责人
CEO-19 外部合作方/顾问评估与分成决策 3.填写合作方评估表并打分（交付达成、质量、响应、用…；7.法务出补充协议/终止函，财务调整结算口径，对接人…；8.更新合作方台账，设下次复评日期 4.拉用户群或访谈 3～5 个真实用户，记录反馈
CEO-20 内部管理系统与协作工具建设（内控/业财平… 2.盘点现有系统与功能交叠；自研 vs 厂商按统一打…；4.组推进组：每板块指定 1 名执行协同人，建推进表…；5.需求收集与边界划分：各板块在多维表格提需求；产品…；6.开发/配置；上线前按权限检查清单配置（读全放开、…；9.上线公告：时间表、培训、旧入口关闭日期、使用要求…；10.系统台账登记业务负责人、开发负责人、权限角色；交… 1.起草项目建议书：目标、范围、MVP 与分期、预算…；5.需求收集与边界划分：各板块在多维表格提需求；产品…；7.每周同步：推进表自动生成周报，逾期项 @ 负责人
CEO-21 全员 AI 案例征集与积分激励宣贯 2.用最新通知模板发布通知（目的、范围、时间、路径、…；4.会后开问题表单，汇总后发布统一 FAQ；5.发征集表，设截止时间（建议发布后 3～5 个工作…；8.积分录入积分系统并公示，公示期接受复核；9.归档：通知、FAQ、结果表、评审结论 3.召开宣贯会（线下+线上），录屏；4.会后开问题表单，汇总后发布统一 FAQ；6.截止前 1 天自动统计未提交人员，机器人推送本人…
CEO-22 股东会筹备与决议（含主体设立/注销材料） 1.确定会期、议案清单与负责人，建会务清单任务（复制…；3.清单拆分到人并设 ddl：汇报材料、通知、签到/…；4.收集股东到场名单及是否需安排住宿餐饮；6.会前复核：股东到场名单、接待、布置、汇报内容、嘉…；7.打印决议、签到表、表决表（按股东数+备份），申请…；9.决议签署扫描归档；需工商变更的转 GEN-15 3.清单拆分到人并设 ddl：汇报材料、通知、签到/…；5.议案、决议、汇报 PPT 初稿完成；设立/注销补…
CEO-23 股权/期权激励方案起草与审议发放 2.法务审阅并给出结构建议（持股平台、员工与外部人员…；3.汇总“待决事项清单”（每项列选项与建议）；4.发董事会成员并预约 15～20 分钟集中讲解；会…；6.按决议改写定稿，标注版本号与变更点，再发群确认；8.完善授予协议，组织激励对象签署，形成发放名册 1.起草方案与授予协议初稿，复杂条款加批注
CEO-24 分子公司/关联主体边界与权限管理 1.新制度/福利/系统发布前，发起人勾选“是否涉及关…；2.查边界清单；已有结论直接按清单执行；4.财务、法务、人事、行政会签；6.更新边界清单，书面单向同步给子公司负责人（只给指…；7.执行切割：飞书组织架构与账号权限调整（兼岗设两个…；8.子公司承接项目每周同步进度、纪要与资料；微信文件…；9.每季度复核边界清单与账号权限，清理离开主体的人员… 3.清单未覆盖：出建议（适用范围、成本分摊、对外口径…；8.子公司承接项目每周同步进度、纪要与资料；微信文件…
CEO-25 重大突发事件与危机应对（舆情、监管、重大… 3.一级事件建应急群，明确指挥、技术、口径、客户、法…；5.处置并每 2 小时在应急群同步进展；7.复盘并分派整改任务 —
CEO-26 年度经营预算审定与月度经营分析 1.下发年度预算模板与编制口径；7.决议录入台账并跟踪 3.汇总测算现金流与利润；5.出上月经营数据包（收入、成本、现金、人力、预算偏…
CEO-27 融资推进与投资者关系管理 3.接触前签保密协议，登记投资人与发出材料版本；4.按清单分派尽调问题并统一审核后答复；7.按约定向投资人报送季度/年度经营报告 2.准备商业计划书与数据室，统一数据口径；4.按清单分派尽调问题并统一审核后答复
ADM-01 办公场地选址、租赁、装修与搬迁 1.提交场地需求单（人数、预算、时间、特殊需求）；2.中介踩点，候选 ≥ 3 个，按模板填对比表；5.合同审核、用印、押金/租金对公付款；6.施工准备：物业三方签字、施工许可、图纸、成品保护…；7.施工日跟踪，落后 ≥ 1 天在群内预警；9.搬迁：搬家公司 3 家比价、设备清单、搬迁通知、… 2.中介踩点，候选 ≥ 3 个，按模板填对比表；7.施工日跟踪，落后 ≥ 1 天在群内预警
ADM-02 工位调整与座位安排 1.提交工位变更申请（人员、区域、日期、原因）；2.核对台账空位，与入职计划比对；4.发布座位表（变动者标色），在相关群公告；5.桌椅不足时汇总需求提采购；7.更新台账并锁定，2 周内无审批不再变动 2.核对台账空位，与入职计划比对
ADM-03 新员工入职行政准备（工位、电脑、领用登记… 1.入职审批通过后提交“入职准备”表单，自动建行政/…；2.确认工位并在工位表标记“预留待入职”；3.按岗位机型模板判定配置；实习生/自带设备/特殊配…；4.核对库存，不足立即触发采购；6.工牌信息采集、门禁录入、基础账号申请；7.到岗当日发放设备与办公用品，领用人填领用登记；8.勾选清单全部完成并关闭任务；带教人完成首日介绍 1.入职审批通过后提交“入职准备”表单，自动建行政/…；4.核对库存，不足立即触发采购
ADM-04 工牌制作与门禁/钥匙/临时密码管理 1.入职信息触发工牌采集表单，新人提交头像；2.每月固定日汇总给供应商制作；批量换版提前公告截止…；3.到货后发放，领取人签收；4.录入指纹/NFC 门禁，登记权限台账；5.临时授权：行政提申请 → 管理员生成限时密码 →…；6.遗失：当日注销旧卡/权限，补办；离职：离职当日注…；7.月度盘点门禁权限与临时密码，清理过期权限 1.入职信息触发工牌采集表单，新人提交头像；2.每月固定日汇总给供应商制作；批量换版提前公告截止…；7.月度盘点门禁权限与临时密码，清理过期权限
ADM-05 会议室预约与公共空间使用规范 1.在飞书日程中绑定会议室预约；1～3 人优先线上会…；2.周期性占用（每周 ≥ 2 次同一时段）提交审批；6.每日下班巡检会议室与公共区，记录违规；7.月度统计占用率、违规次数，调整规则并更新知识库 4.开始 15 分钟未签到系统自动释放；无效日程由创…；6.每日下班巡检会议室与公共区，记录违规；7.月度统计占用率、违规次数，调整规则并更新知识库
ADM-06 外部来访接待与参观/拍摄报备 1.提交“接待申请”表单；2.确认并预留会议室、茶水、停车、门禁卡，回复申请人；4.同步物业前台（停车、梯控、门禁、备用会议室）；向…；6.宴请/酒水：先领用库存，无库存再按标准报销；7.登记接待表（照片、纪要、费用、关联客户）；外借物… 2.确认并预留会议室、茶水、停车、门禁卡，回复申请人；4.同步物业前台（停车、梯控、门禁、备用会议室）；向…；7.登记接待表（照片、纪要、费用、关联客户）；外借物…
ADM-07 面试会议室预约与候选人到访接待 1.与面试官确认时间与形式；2.在面试日程中绑定会议室：1v1 优先线上会议间/…；3.面试前 1 个工作日复核会议室状态与设备；冲突或…；4.发送到访指引：地址、楼层门牌、到达时间（不早于 …；6.线上面试：会议链接提前发出，摄像头要求提前告知 2.在面试日程中绑定会议室：1v1 优先线上会议间/…；3.面试前 1 个工作日复核会议室状态与设备；冲突或…；4.发送到访指引：地址、楼层门牌、到达时间（不早于 …
ADM-08 办公设施故障报修与维修验收 1.提交“设施报修”表单；紧急情况同时电话行政并在全…；4.超过自修范围的维修比价 ≥ 2 家；超出限额报综…；7.关单：登记费用、供应商、质保；费用走对公付款或报… 2.按类别自动派单：设施→行政，网络/机房/门锁/电…
ADM-09 停电/极端天气等突发事件通知与居家办公安… 1.获知事件，登记时间、范围、预计时长，按"计划内/…；4.按模板发布唯一通知（时间、范围、到岗方式、报备方…；5.停电前保存数据、按清单关停服务器与 CI，记录关…；6.需居家/换点/无法通勤的员工提交报备；换点办公由…；8.来电/来网后按启动顺序恢复服务与 CI，在群内通…；9.补全事件记录，写明问题与改进项 4.按模板发布唯一通知（时间、范围、到岗方式、报备方…；8.来电/来网后按启动顺序恢复服务与 CI，在群内通…
ADM-10 下班及节假日离岗安全检查（断电、锁门、机… 1.建分区域设备台账与关闭图文，必要时请物业演示，放…；4.次日到岗检查或调取监控抽查，异常拍照登记并在区域…；5.节前向 IT 与各组推送保电需求征询；7.发布节前离岗通知：断电范围、电脑关机、拔排插、清…；8.放假当晚巡检门窗电源，拍照记录；11.将办公区安全与离岗规范加入入职培训 4.次日到岗检查或调取监控抽查，异常拍照登记并在区域…；5.节前向 IT 与各组推送保电需求征询；10.汇总当月异常，评估智能插座、红外空调遥控、门状态…
ADM-11 办公区保洁、值日、大扫除与虫害消杀 1.按区域生成下月值日表，小组长确认值日人；2.值日人整理公共区（垃圾、桌面、会议室），完成后勾…；3.外包保洁每周五晚或周六白天清洁，拍照上传；5.区域确认纸箱等杂物无用后报行政，安排清运；6.节前/季度大扫除：定时间、按区域分工、提前通知，…；7.定期消杀：每季度 1 次，6～9 月每月 1 次…；8.卫生事件：员工表单上报 → 行政判断自行处理或外… 9.汇总当月验收、事件与复发情况，调整保洁范围或频次
ADM-12 行政制度与办公规范制定发布 1.提交制度/规范需求，行政登记立项并定分类（公司级…；4.发起会签：财务、人事、相关部门在文档内批注；5.总助审核一致性后提交 CEO 审批；办公规范由行…；6.发布：飞书公告 + 需张贴的打印上墙，标注编号、…；7.入制度库，更新制度台账，关联相关 SOP；9.复审：制度台账到期提醒，评估是否修订 2.检索现有制度，确认是新建、修订还是合并；3.起草初稿（可用 AI 生成初稿再人工修改）；8.涉及全员行为的制度纳入新人培训材料；9.复审：制度台账到期提醒，评估是否修订
ADM-13 行政事务归口、交接与行政日报 1.编制归口清单（事项、主责、备岗、入口、时限），综…；2.设"行政服务申请"表单，按事项类型自动派给归口人；3.公示行政人员与兼职助理在岗时间、可处理事项与需转…；4.提交日报：今日完成 / 进行中 / 阻塞 / 明…；5.日报中涉及跨部门的事项同步总经办；7.岗位变动：离岗人按清单交接（在办事项、供应商、账… 2.设"行政服务申请"表单，按事项类型自动派给归口人；6.未提交日报自动提醒；连续 2 个工作日未提交提醒…；9.每周汇总未结与超时事项，AI 生成周报
ADM-14 办公物资/家具申购与行政服务需求受理 1.提交"办公物资/服务申请"，选类型（家具大件/消…；2.受理并分类，缺信息一次性退回补充；场地类转总助审…；4.超阈值或款式有争议时提交审批；5.下单（大件避免全额预付），回填订单号、下单人、供…；6.到货后通知需求方，组织取件、组装、摆放；7.需求方验收；服务需求行政完成后拍照回传；8.发票上传，按月集中交财务；垫付走报销审批；9.消耗品：维护存放位置与库存，低于阈值自动提醒补货 6.到货后通知需求方，组织取件、组装、摆放；9.消耗品：维护存放位置与库存，低于阈值自动提醒补货；10.每周推送未结需求与超时提醒
ADM-15 快递代收、公共物品借用与失物招领 1.盘点公共物品，建台账、贴标签，IT 类由 IT …；2.发布办公指南并置顶各办公群；3.快递/货物到达：值守人签收，拍照登记收件人、放置…；5.借用公共物品：扫码登记借用人、预计归还时间，归还…；7.公共区无主物品：拍照登记，放失物招领处，发认领通…；10.月度盘点台账，更新位置与状态，缺失项发起找寻 4.机器人通知收件人；无收件人信息的发群认领；6.逾期未还自动提醒借用人
ADM-16 对外寄件与快递月结 1.公布月结账户的使用方式、下单权限人与寄件规则，账…；2.提交寄件登记：用途、物品、收件信息、期望到达日期；3.确认收件信息无误；同一客户信息复用台账，不再重复…；5.用公司月结账户下单，回填单号；7.跟踪物流，签收后更新状态；交付类提醒收回签收单；8.月结账单与寄件台账逐单核对，交财务付款 3.确认收件信息无误；同一客户信息复用台账，不再重复…；6.机器人把单号推送到需求群；7.跟踪物流，签收后更新状态；交付类提醒收回签收单；8.月结账单与寄件台账逐单核对，交财务付款
ADM-17 零食福利月度采购与额度/报销管理 2.开放选购，发布通知（开放期、截止时间、收货点、指…；4.截止前提醒未确认人员；8.汇总发票、付款凭证、订单明细形成报销包提交（部门…；10.月度复盘：未确认率、超额、发票缺失、需求与 BU… 1.同步飞书通讯录生成当月名单与额度，人工核对入离职…；4.截止前提醒未确认人员；5.截单锁单，系统按“部门—收货点—渠道”生成汇总
ADM-18 节日福利与员工福利物资发放 1.立项：确定对象、预算上限、发放日期，报批；3.发布选择文档或投票，写明截止时间和逾期默认方案、…；8.通知领取，现场签收；出差/异地人员寄送或代领登记；9.提交报销并归档方案、投票结果、签收表 4.截止前提醒未回复人员；5.截止后汇总，未回复按默认方案计入，出采购清单
ADM-19 活动定制物料与对外礼品（工服、伴手礼、品… 1.提报物料需求（用途、数量、到位日期、预算）；2.按“到位日 − 物流 − 生产工期 − 设计确认…；5.工服：发布款式与尺码收集，优先调用尺码档案；各尺…；6.预算审批后下单付定金；8.活动现场发放；对外赠送、样品借用逐笔出库登记 2.按“到位日 − 物流 − 生产工期 − 设计确认…
ADM-20 团建、聚餐与全员活动组织 3.提交审批，确认时间、预算、家属规则、补休；4.发全员通知并开放报名表单（参加、家属、交通、饮食…；5.截止前提醒未报名者；与人事名单核对，不漏不重；7.现场签到、分组；生日会礼品本人签收；8.收集发票报销或结算，并归档方案、名单、签到表 2.出方案并比价不少于 2 家（外包或自办），含预算…；5.截止前提醒未报名者；与人事名单核对，不漏不重
ADM-21 全员年会筹办 1.立项：确定形式、日期、人数、预算上限，建倒排表；6.发邀请函与全员通知（时间、地点、着装、流程概要）…；7.餐厅清单投票、按餐标订餐；奖品与物料下单；10.当天签到、分组、执行；11.报销结算，整理人员清单，复盘并归档全部模板 4.起草流程文档（环节、时长、主持、互动项目）和奖品…；6.发邀请函与全员通知（时间、地点、着装、流程概要）…
ADM-22 差旅订票与企业出行账户管理 1.发起出差审批，写明行程、主体、项目；2.按标准订票；标准舱位售罄或无合适班次时，在审批中…；3.审批例外（符合例外条款的可由直属上级审批，不再临…；4.返回后提交报销，系统校验是否超标、是否有例外审批；5.企业滴滴开通申请提交表单，按主体加入对应企业账户 4.返回后提交报销，系统校验是否超标、是否有例外审批；6.设置余额预警阈值，低于阈值自动通知账户管理人与财…；8.月度导出账单，按主体对账，清理离职成员
ADM-23 公司证照与档案（印章/档案柜）保管调用 1.在飞书云盘建“公司证照库”，按主体分文件夹，记录…；2.设权限：营业执照等常用件全员可查看水印版；法人证…；3.申请人提交调用申请（主体、材料、用途、期限）；5.原件借出登记，约定归还日期，到期提醒；6.证照变更后替换电子版，旧版标“作废”归档，通知常…；7.纸质档案按分类编号入柜，登记目录；8.档案借阅：申请 → 对应档案负责人审批 → 登记… 4.常用件由机器人按关键词回复链接；敏感件由保管人发…；5.原件借出登记，约定归还日期，到期提醒
ADM-24 IT设备与研发硬件采购申请 1.提交“采购申请”审批，必填字段完整（品名、型号、…；2.查台账，能调拨的直接调拨并关闭申请；6.京东慧采加购下单；渠道采购签对公合同；8.到货按参数验收，核对型号、数量、序列号；9.登记台账（订单号、价格、序列号、使用人、存放点）…；10.退换与返修走“设备维修/退回”审批，进度更新到台… 2.查台账，能调拨的直接调拨并关闭申请；3.按分级标准选型，询价不少于 2 家，高价值设备出…；9.登记台账（订单号、价格、序列号、使用人、存放点）…
ADM-25 交付用硬件备货采购与供应商比价 1.库存低于安全线时自动提醒；或需求方提交补货/核价…；4.从供应商库询价，≥3 家比价；按急单/非急单分级…；5.提交采购审批，附比价表和成本核算表；7.下单，同步发起对公付款（走 FIN-01），登记…；8.跟踪到货；超过交期 2 个工作日未到，催办并通知…；9.到货验收、入库、更新批次与库存，移交装机 1.库存低于安全线时自动提醒；或需求方提交补货/核价…；3.按规格-价格对照表核算单台成本，与商务对齐售价和…；8.跟踪到货；超过交期 2 个工作日未到，催办并通知…
ADM-26 调研/验证用设备临时采购与处置 1.提交调研设备需求，填用途、评估期、预算；4.审批（小额走快速通道）；5.下单；到货后登记台账，标注退货截止日、评估截止日…；6.使用人领用登记；9.执行处置并更新台账；财务处理退款或资产入账 7.退货截止前 2 天、评估截止前 3 天自动提醒需…
ADM-27 IT设备到货验收、入库登记与调配变更 1.收货，核对数量与外包装，在群内/台账标记“已到货…；2.生成验收单（关联采购单号、序列号）；4.按分类入研发库或行政库，生成资产编号与二级编号，…；5.使用人提交领用申请，审批通过后自动扣库存、记使用…；6.设备换人、退回：原使用人或新使用人提交调配申请；9.验收单、发票归档，月末与财务核对新增资产 2.生成验收单（关联采购单号、序列号）；8.审批结果自动回写资产表（使用人、位置、状态），资…
ADM-28 内部测试设备与资源借用登记 1.在测试设备台账中查可借设备，不再在群里喊人；2.提交借用登记：设备编号、用途、起止日期；3.确认可借；≤ 14 天直接确认，> 14 天或冲…；4.领取，当面核对配件（电源、线、盒子），台账记“借…；8.交付介质低于安全库存（建议 ≥ 3 块编号专用盘…；9.每月核对一次台账与实物，清查“不明归属”设备 5.到期前 1 天机器人提醒；逾期每日提醒并抄送台账…；9.每月核对一次台账与实物，清查“不明归属”设备
ADM-29 样机/设备外借（销售演示、展会、客户现场… 1.向样机管理确认存量（或查样机台账）；2.提交“LeapCore 样机借用审批”，填申请人…；3.常规（≤3 天且无系统展示）：市场销售负责人 →…；5.出库：按配件清单核对（主机、电源、适配器、线材、…；6.自取或邮寄（邮寄按 ADM-16）；9.台账回写“在库”，缺件登记并追责 4.审批通过自动通知样机管理，台账扣减；样机管理核对…；7.到期前 1 天提醒申请人；逾期每日提醒
ADM-30 信创测试机申请与厂商借机/归还 1.提交“信创测试资源申请”，填配置、用途、最晚到位…；3.审批路径与优先级；结果自动推送需求方与项目群；5.实体机到货：验收（开机、芯片/OS 核对）、入库…；6.需求方确认可用，台账状态改“使用中”；转借他人需…；8.归还：通知占用方 2 个工作日内备份数据，清除数… 3.审批路径与优先级；结果自动推送需求方与项目群；7.云资源到期前 7 天、借机归还日前 7 天自动提…
ADM-31 IT设备故障报修 1.提交“设备维修”审批（群公告置顶入口；群内发“报…；4.换新或外修费用超阈值时审批；7.交还设备，报修人确认，工单关闭，台账记维修记录；9.提交处置申请（再分配/出售/转赠/退租/返厂/报…；12.资产台账注销，财务核销并处理处置收入 1.提交“设备维修”审批（群公告置顶入口；群内发“报…；7.交还设备，报修人确认，工单关闭，台账记维修记录；10.离开公司或报废前清除数据（多次覆写/加密擦除）；…
ADM-32 离职/换机设备回收 1.离职审批流转到运维节点时自动创建回收任务；换机申…；6.在离职审批运维节点签字通过；缺件写明并抄送人事；7.资产表回写：使用人清空、状态改“在库/闲置/待修… 1.离职审批流转到运维节点时自动创建回收任务；换机申…；2.从资产表拉出当事人名下资产，生成回收清单；8.每月核对一次：本月离职名单 vs 资产表仍挂在离…
ADM-33 资产盘点、闲置回收与审计配合 1.发盘点通知：范围（实体 IT/外借/机房/待处置…；3.现场逐台扫码核对编号、序列号、使用人、位置、状态…；4.推送名下设备清单给使用人确认在用/闲置/不在手；7.台账与财务固定资产账逐项核对，确认调账与报废 2.导出台账快照，生成盘点底表和超期外借清单；4.推送名下设备清单给使用人确认在用/闲置/不在手；7.台账与财务固定资产账逐项核对，确认调账与报废；8.出盘点报告，提交审计/董事会资料，闲置与报废处置…
ADM-34 云服务与软件订阅等非实体资产申领与释放 1.提交「非实体资产申领」审批，填领用类型、项目、主…；3.审批；审批卡片由机器人自动 @ 审批人，超时自动…；4.需付费的走采购付款；低于采购门槛的小额按约定口径…；5.开通资源或发放兑换码/账号，凭据通过私密通道或密…；7.资源到期或不再使用时提交释放审批，写明资源、用途…；9.执行解绑/注销/销毁，必要时先备份，更新台账状态… 5.开通资源或发放兑换码/账号，凭据通过私密通道或密…；6.写入资源台账：资源 ID、类型、主体、项目、负责…；8.原负责人确认无用；企业 ID/组织与交付表、客户…
ADM-35 消防安全检查与应急疏散演练 1.建立消防设施与疏散责任人台账；2.月度检查（灭火器、通道、插线板、机房温度）；3.隐患整改并复查；6.复盘并更新台账 —
ADM-36 场地租金、物业及水电网费用缴纳与租约到期… 1.建立固定费用台账（费用项、主体、周期、缴费日、合…；4.发起付款申请；7.审批并更新台账 2.缴费日前自动提醒
FIN-01 对公采购申请与付款审批 2.提交“采购申请”（用途、主体、金额、是否有票、是…；3.合同审核与用印；大额/非标合同转法务；4.技术审批 + 终审；5.关联采购单提“付款申请”，审核附件并制单；7.回单回传审批单，通知采购人提货/厂商开工；8.到货验收、资产登记 5.关联采购单提“付款申请”，审核附件并制单；9.发票回收、验真、入账归档
FIN-02 AI 工具订阅与第三方服务新购开通 1.提交“AI 工具/服务开通申请”；5.公司付款（对公/公司卡）；无法公司付款转 FIN…；7.登记台账（服务、主体、账号归属、负责岗位、席位成… 6.Key 接入 NewAPI 或密钥库，分测试/生…；8.到期/余额/封号提醒；月度用量与成本统计
FIN-03 上游模型/云服务/三方 API 账户充值… 3.财务统一提“付款申请”（事由、主体、是否预付、附…；4.技术审批 + 终审；6.到账确认，更新台账余额并在群里通知 1.每日拉取各账户余额，低于预警线推送群和负责人；7.消耗后申请发票，回收入账；8.月度对账：充值、消耗、汇率、发票对齐，调整预警线
FIN-04 境外服务外币付款与无票支出处理 2.提“境外/无票支出申请”（一张单覆盖采购与预支，…；3.CTO 审批 → 财务审核 → CEO 例外审批；5.平台账号登记台账（平台、主体、注册邮箱、支付工具… 6.下载 Invoice/账单与付款截图上传审批单
FIN-05 备用金/费用预支申请与核销 2.提“备用金申请”，在同一单关联“采购申请”；3.审批；超限额转 CEO 特批；4.审核并打款；财务不在岗时由 AB 角处理；6.提“备用金核销”，附票据；7.审核核销，余额走“还款”退回公户 1.对照指引判断是否适用备用金；8.到期前 3 天与到期当天自动提醒未核销
FIN-06 日常费用报销提交与审核 3.提“费用报销”：选类型与归属公司，上传发票（自动…；4.直属上级审批；6.按金额分级终审；7.制单打款，回单回传审批单；8.纸质票据集中整理贴票归档；月度与银行流水、审批数… 1.对照“可报销清单”判断能否报、选哪个类型；3.提“费用报销”：选类型与归属公司，上传发票（自动…；5.审核附件、金额、制度符合性；缺件一次性列清退回
FIN-07 差旅事前报备与差旅报销 1.提“出差报备”（事由、行程、预算、是否超标）；2.直属上级审批；超标/境外/以公司名义参会走特批分…；5.提“费用报销”关联出差报备，上传发票；7.打款并回传回单 4.生成往返闭环行程单；缺段写补充说明；5.提“费用报销”关联出差报备，上传发票
FIN-08 企业滴滴充值与通勤打车报销 1.入职开通账号并宣讲用车 SOP；外部人员原则上不…；3.汇总上月用量，按主体提交充值申请；4.审批后充值；6.手工导出月度用量，更新用车仪表盘，抽查超额与因公…；7.余额不足/未开通期间个人垫付，凭截图与发票报销；8.入离调、跨主体调动同步账户归属 —
FIN-09 活动/团建/大会费用预算与统计归集 1.提交活动预算申请（活动名、主体、预算科目、金额、…；3.在活动群发布费用口径：采购阈值、可报科目、发票抬…；5.提交报销，费用类型选"活动费用"，填写活动名称/…；6.各组在统计表登记本组明细；7.汇总预算 vs 实际，标出超支项与未报销项 7.汇总预算 vs 实际，标出超支项与未报销项；8.按活动名核对报销单与汇总表，归档
FIN-10 员工 AI 工具补贴核发与超额报销 1.冻结当月名单与分档（入离调、实习、驻场、跃竞/子…；4.分主体发起付款申请；财务按福利口径计算代扣个税；5.打款（与工资分开），群内通知已发放；6.员工提交超额申请：工具、金额、用途、产出说明；8.提交报销：类型"AI 工具费用"，附票据，主体与…；9.审核票据与 AI 工具相关、按发票号查重后付款 2.与上月自动比对，标出新增、删除、档位变化；9.审核票据与 AI 工具相关、按发票号查重后付款；10.核验自研产品充值/使用，推送未完成名单；月末仍未…；11.按主体汇总当月补贴与超额报销总额，报 CEO
FIN-11 飞书报销审批表单配置与应用问题处理 1.按 FAQ 自查（退回单先点确认/撤回释放发票；…；2.未解决则提交问题单（截图 + 单号）；6.发布并调整可见范围；7.发布变更通知（变更点、生效日、操作说明） 8.问题与答案沉淀进 FAQ；每周检查一次插件余量
FIN-12 进项发票索取、缺票催收与归档 1.按开票信息卡向供应商申请开票，要求发至公司发票邮…；3.发票上传收集目录并登记台账（或转发发票邮箱自动入…；6.对照付款与报销记录生成缺票清单，分人推送；9.汇总抵扣票，标记"已抵扣/仅收票不报销"，月末交… 3.发票上传收集目录并登记台账（或转发发票邮箱自动入…；4.自动识别发票字段，按发票号去重，标记抬头/票种异…；5.按命名规范重命名并归档；6.对照付款与报销记录生成缺票清单，分人推送
FIN-14 劳务、顾问及奖金类报酬结算与个税 2.发起合同申请并签署对应协议；3.提交月度工作确认单；6.提交付款申请，关联合同，上传确认单与发票；先付后…；7.审批并付款 8.更新台账：已付期数、终止日期；合作终止当月停止月…
FIN-15 支付通道选型、商户进件与收款权限开通 1.提交收款需求单；4.发材料清单，各方补齐；盖章协议走用印；5.提交进件，每 3 个工作日跟进一次并在群内同步进…；8.更新台账；支付失败/风控类告警路由给支付渠道负责… 8.更新台账；支付失败/风控类告警路由给支付渠道负责…；9.每月核对商户资质、证件有效期、已开通能力
FIN-16 内部测试与客户赠送额度申请审批 1.提交额度申请（对象、实例 ID、金额、用途、依据…；5.确认到账并在审批单回复；8.测试结束、人员离职、试用到期后回收或冻结额度 4.后台充值/配置赠送额度/生成券（一次性兑换、按人…；6.写入额度台账；7.月度对账：台账 vs 后台实际 vs 上游消耗；…
FIN-17 客户充值到账审核与额度开通 1.客户提交充值订单并下载盖章结算单（线下）；或线上…；2.转账后上传汇款凭证；未上传不进入审核；5.预充/续充/试用赠送：销售提交赠送申请，销售负责…；6.订单置为已完成，机器人通知客户与销售，客户可申请…；8.月末对账：充值台账与公户流水、收入台账核对 4.审核通过后渠道系统调用 LeapCore 充值接…；6.订单置为已完成，机器人通知客户与销售，客户可申请…；7.日对账：拉取正式服充值单与余额，与订单、到账比对…
FIN-18 客户充值订单开票 2.客户填写抬头、税号、邮箱，提交申请；页面提示"预…；6.上传发票文件至渠道系统，状态回写订单，客户订单页…；7.机器人通知客户/销售"发票已开具"；登记对外开票… 1.系统校验开票条件：已支付 + 已充值才显示开票入…；3.申请同步至渠道系统待开票列表；同步失败提示客户重…；6.上传发票文件至渠道系统，状态回写订单，客户订单页…；7.机器人通知客户/销售"发票已开具"；登记对外开票…
FIN-19 销售合同开票申请与红冲 1.合同签署后登记台账、获取合同编号；2.提交开票申请：合同号、开票项目、税率、票种、金额…；3.销售负责人审批；6.上传发票至审批单/渠道系统，系统通知申请人，申请…；7.回款到账后认款：关联合同号，确认收入归属，做收款… 1.合同签署后登记台账、获取合同编号
FIN-20 软硬一体合同分税率开票与硬件基准价维护 1.飞书任务自动提醒月度校准；IT 按最新采购价提出…；3.录入渠道系统 SKU 配置，系统留存价格、生效时… 4.发布本月基准价变更通知给销售、法务、财务；5.起草合同：按型号取基准价为硬件金额（13%），总…
FIN-21 收入合同台账、回款跟进与收入确认 1.合同签署后在台账新增记录，填写合同、回款计划字段；3.交付后上传签收单/验收单，更新履约字段；5.公户进款后财务发起认领，销售认领对应合同；来源不…；9.渠道平台、运营类收入与对方对账 4.回款到期前 5 个工作日机器人提醒销售；逾期每周…；6.月末自动生成"无合同已交付/已回款/已开票"清单…
FIN-22 境外客户收款、形式发票与结汇 1.业务提交境外收款申请，附交易信息与合同；8.全套材料归档，更新境外回款台账 3.按模板开具形式发票（编号 MTYQ-xxxx），…
FIN-23 渠道/开发者分成结算、分润打款与开票 1.结算规则书面化（比例按毛利还是成本、计算公式、周…；5.执行分账或批量打款（渠道分润不走支付机构分账时，…；7.生成月度结算对账单发给接收方确认；8.退款：提交退款审批，财务审批后由对应渠道退回，消… 2.分账规则配置进系统；分账前先查询订单可分账金额再…；3.按周期生成待分成清单（订单、金额、接收方、账户）
FIN-24 支付渠道每日对账、手续费与差异处理 2.账实平：财务在卡片点"已确认"回执；6.差异关闭：财务在待办中确认关闭；8.申请上月手续费发票（每月 12 日后，商户控台"… 1.机器人对前一日账期执行对账，推送交易笔数、净流水…；3.失败（对账单未就绪、查询超时、出金账单查询失败）…；4.有差异：系统建差异待办，开发判断是口径问题还是真…；7.月度核对：导出各产品账单与支付机构结算单，与公户…
FIN-25 资金/分账异常排查与数据修复 1.告警或反馈进入后在资金异常表登记，@事件负责人；6.财务复核影响清单与修复金额，跃竞负责人批准执行；7.执行修复，逐笔记录到修复台账；9.财务对修复后流水与平台余额再次对账并关单 1.告警或反馈进入后在资金异常表登记，@事件负责人；3.根因排查：回调日志、对账任务、队列限速、换户影响；4.输出影响清单：按商户/俱乐部列出差额、订单数、应…；9.财务对修复后流水与平台余额再次对账并关单
FIN-26 网关月度账单导出与财务对账 4.推送财务（附字段词典链接），首次使用的字段线上讲…；6.差异或新需求提 LEAP 工单（财务需求单独标签…；8.账单定稿归档（按月份） 1.定时任务导出上月账单三份 CSV（上游/Key/…；2.自检：总额与上游充值/扣费日志一致，无“-”或缺…
FIN-27 客户按量计费月度账单核算与发送 1.机器人按合同结算日提醒（默认每月 15 日后）；5.通过客户群发送给客户对接人，同步财务；6.客户确认后开票并跟踪回款；7.账单、确认记录、收款状态登记到按量付费清单 2.导出周期用量（token/调用量，按账号）或汇总…；3.按合同口径与折扣计算应收，生成账单草稿
FIN-28 模型成本价、计价倍率维护与成本收入核对 1.登记变更：渠道/模型/原因/生效日期；3.按毛利规则计算售价与倍率，提交审批；6.机器人推送变更到通知群（不含成本价明细给非授权人…；7.生产网关切换/发版时将“倍率与价格核对”列入发布… 2.更新成本价主表（币种、折扣、汇率版本）；4.dry-run 同步到网关，核对差异清单后正式下…；5.上线核对：抽检各档位模型，按“成本×倍率”算应扣…；8.月度对账：各模型消耗成本 vs 收入，输出毛利与…；9.业务取数需求（报告平均/最大成本）走固定报表
FIN-29 计费扣费异常核查与退补 1.受理并按模板登记异议（用户/企业/时间/模型/截…；7.退补审批：多收金额、退款或补额度方式；9.核查报告归档，计价问题同步 FIN-28 校准 3.拉日志与成本数据：请求数、token、缓存命中率…；4.按定价公式重算应扣，与实扣比对，算出差额
FIN-30 云/模型服务成本按项目归集与账号台账 3.未归属资源清单交 IT，按审批单补归属；无审批的…；6.按平台开票规则索取发票，个人充值与对公分开；7.更新账号台账：新增/停用账号、余额、负责人；8.新资源开通必须走“非实体资产申领”并按 IaC … 1.用财务只读子账号登录各平台，下载上月账单、回单、…；2.按“项目”维度筛选导出成本表；4.导出内部 API 用量（按人、档位、项目）
FIN-31 研发项目立项与研发费用归集 1.起草立项三件套；4.研发人员按项目填报当月工时；6.编制月度人工成本核算表，归集云费用等到项目；7.新增单据标注所属研发项目（采购审批必填） 8.每季度由仓库/工单自动生成阶段性成果摘要，技术确…
FIN-32 多主体业务归属与子公司成本隔离 1.交付/合同表单必填签约主体，按集团规则选择；2.采购与出货主体自动比对签约主体，不一致则拦截；3.子公司支出填采购申请（含归属研发/经营），走本主…；5.跨主体借用资源须提交使用申请，写明期限与切换计划；6.按主体与用途分 key（生产/测试/自用），登记… 2.采购与出货主体自动比对签约主体，不一致则拦截；7.月度导出各 key 消耗，按主体对账分摊
FIN-33 关联主体资金划转与注资 1.每月初更新集团资金计划表，标出余额不足主体；3.管理层确认划转性质与额度；4.借款：签关联方借款协议；投资款：出具股东决定/出…；5.提付款申请，银行附言写明“借款”或“投资款”；7.登记关联往来台账，借款设还款提醒，投资款更新实缴… 1.每月初更新集团资金计划表，标出余额不足主体
FIN-34 子公司月度营收统计与汇报 1.飞书任务/机器人提醒提交月报；3.按口径计算：营收 = 交易手续费 + 陪玩会费；…；6.在董事会群提交摘要 + 明细附件；8.答复追问，月报归档；超计划部分进入奖金核算 2.从汇付控台和业务后台导出上月流水、会费、商户汇总；3.按口径计算：营收 = 交易手续费 + 陪玩会费；…；4.填写月报模板，AI 生成文字摘要（环比、异常说明…
FIN-35 月度税务申报与税额确认 1.申报日历提醒（各主体、各税种、截止日）；5.群内发测算摘要（各主体税额、税负率、与上月差异原…；7.申报、扣款，下载申报表与完税凭证存档；8.按检查清单核对是否遗漏税种/主体 2.下载银行回单，核对销项开票与收入，完成进项发票勾…；3.测算增值税、附加、印花税、所得税，计算税负率
FIN-36 审计、尽调与投标财务资料准备 1.登记需求：用途、主体、期间、截止日、格式；2.按模板生成资料清单并分派到人；3.业务部门补交发票、合同、补助资料；6.安排审计访谈（销售、人事等）；8.提交审计机构/需求方，资料包与报告归档 5.科目余额表、序时账、报表三方勾稽，核对期初数
FIN-37 财务人员交接、代账交接与整顿期汇报 1.下达交接指令，明确交接截止日与监交人；2.移交方按清单整理资料，完成账户与权限变更；7.整顿期汇报：前 2 周每日、之后每周 2 次；8.交接完成确认，双方与监交人签字，结束整顿期 5.银行余额、往来、税务数据差异调账，三方勾稽；7.整顿期汇报：前 2 周每日、之后每周 2 次
FIN-38 主体工商税务登记变更与注销 1.发起事项登记，管理层确认是否办理；2.按事项类型生成材料清单，法务出具决议文件；7.回执归档到证照台账，在飞书任务中 @ 相关人确认… —
FIN-39 资金计划与临时周转借款 1.每周更新滚动资金计划，低于安全线自动预警；3.比选方案并提交审批（出借方类型、金额、利率、期限…；5.起草/审核协议并提交用印；7.登记还款台账，设置到期前 15 天提醒；8.按期还款，取得结清确认并归档 1.每周更新滚动资金计划，低于安全线自动预警
FIN-40 银行账户、网银 UKey 管理与付款复核 1.建立并维护银行账户与 UKey 台账；2.开户/变更/销户提交审批 6.下载回单并关联审批单；7.月末银行余额核对
FIN-41 月度结账与管理报表 1.发布月结日历与单据截止日；2.业务部门提交单据截止；4.收入成本确认、费用计提与分摊；6.关账出具各主体报表；7.编制管理报表并汇报 3.银行与支付渠道余额核对；4.收入成本确认、费用计提与分摊；7.编制管理报表并汇报
FIN-42 年度企业所得税汇算清缴与研发费用加计扣除 1.制定各主体汇算计划与资料清单；3.研发辅助账与项目资料核对；5.管理层确认税额与优惠口径；6.申报并缴补税/申请退税；7.资料归档备查 3.研发辅助账与项目资料核对
FIN-43 年度预算编制与执行分析 1.下发预算模板与编制假设；3.汇总平衡与差异沟通；5.分解发布并配置到审批；7.超预算审批与季度调整 3.汇总平衡与差异沟通；6.月度执行分析并推送部门负责人
FIN-44 政府补助资金到账、专款核算与验收审计 1.识别到账并通知政策申报专员；3.设立专项辅助核算；4.支出时在审批单标注项目，留存佐证；7.结余处理与资料归档 5.按季度出具资金使用执行表
LEG-01 合同模板库建设、版本维护与发布 1.提交模板变更/新建申请，写清原因、受影响模板、新…；5.会签：销售确认商务条款，产品确认功能与交付表述，…；6.定稿：编版本号（模板类型-YYMMDD-Vn），…；7.发布：在合同审核群、销售群发通知并置顶，写明“X… 4.用修订模式修订模板并附变更摘要；需要系统生成的模…；7.发布：在合同审核群、销售群发通知并置顶，写明“X…；8.抽查：发布后审核合同时核对版本号，发现旧版直接退…
LEG-02 我方签约主体选择与印章信息登记 1.起草前填写主体判断要素（客户类型、产品线、硬件来…；6.在合同审批单选择主体，自动带出主体资料，合同归入…；7.主数据维护：新增主体或印章时录入基础信息与印章信… 2.按主体决策表初判我方主体；涉及多主体时写明集团内…；7.主数据维护：新增主体或印章时录入基础信息与印章信…；8.主体或印章变更后通知销售、财务、行政，更新决策表
LEG-03 销售合同审查与多方会签 1.用现行模板起草，信息与报价单、配置单逐项一致；自…；3.在合同审核群或飞书合同审批提交合同、报价单/配置…；5.完整会审（并联）：产品核对功能与服务承诺；技术核…；8.定稿后提交飞书合同审批、用印签署（见 LEG-0… 2.跑 AI 预审，出审查报告；标出相对模板的修改项…；4.快速通道：核对版本号、主体、地址、金额、交付期，…
LEG-04 采购/服务及其他对外合同、承诺函起草与审… 1.提交飞书合同审核申请，必填对方主体、既往交易、计…；3.确认标的、范围、SLA、计费模式、金额与预付款与…；6.与对方确认修改；文件名加日期版本号；定稿；7.用印（鲜章或电子章，见 LEG-09）；付款或充…；8.签署件与验收单/结算单归档并登记台账（见 LEG… 2.起草：优先用模板库；对方制式文本直接提交；非法务…；4.审条款并出修订版与意见；标出需业务评估的条款（故…
LEG-05 保密协议与外部合作（合作开发/非劳务）协… 1.提交合作协议申请：对象、资料清单、合作性质、计划…；5.跟踪对方节点（对方法审、立项、上会、盖章），在跟…；6.我方用印并寄出（见 LEG-09），登记寄出日期… 3.选模板起草（NDA / 合作开发协议 / 非劳务…；5.跟踪对方节点（对方法审、立项、上会、盖章），在跟…；8.协议归档并设到期提醒（见 LEG-11）
LEG-06 股东会/董事会决议与合资合伙协议签署 1.登记文件：类型、对方、签署主体、签署人、截止日，…；5.定稿并按签署检查清单核对：无空白条款、不用授权委…；6.需表决的：发会议通知，参会人实名入会、提前 10…；7.签名与用印（可用手写签名电子印章，减少重复手签；…；8.归档并启动后续动作（工商变更、主体变更、授予通知… 3.AI 风险初筛，列出未填写条款与风险点
LEG-07 云厂商合同与代付协议电子签署 1.收到待办后转发到合同受理入口并登记厂商、主体、协…；5.授权签署人在平台签署（电子章、骑缝章） 2.对比上一版，写变更摘要（折扣、价格、新增模型、付…；6.下载已签 PDF，存入合同库并登记到期日、代付关…；7.通知财务与供应商台账更新
LEG-08 业务电子合同（电子签）接入与线上签约 3.法务定稿模板并确认固定条款与可变字段；产品确认；…；4.控制台配置“企业自有模板”：模板只放自动填充内容…；7.上线并发布操作手册（含授权签署人名单、俱乐部开通… 5.开发接入：企业名称从渠道系统或客户资料拉取，不让…；6.测试验收：企业名称注入、动态签署人、撤回、权限、…；8.运行：签完自动下载 PDF 存档并登记台账（见 …
LEG-09 用章用印审批与盖章版本核对 1.判定类型：合同类（采购/销售/渠道合同、战略合作…；3.发起审批：填主体、印章类型、份数、是否骑缝、合同…；4.分级审批：按文件类型 × 金额自动路由到对应审批…；5.版本锁定：审批中如需修改，撤回重提或更新审批附件…；7.盖章（含骑缝章、法人章），同步登记用印；8.扫描盖章件，上传审批单并通知申请人；需寄出的登记…；9.双方签署完成后上传双签扫描件，纸质原件交行政归档… 2.前置审核：合同类发法务、财务确认条款；核对正文金…；6.打印并交行政；行政逐页比对打印件与审批附件（主体…；9.双方签署完成后上传双签扫描件，纸质原件交行政归档…
LEG-10 公司证照、授权委托书与负责人签字材料提供 1.列材料清单：哪个主体、要哪些证照/文件、格式要求…；3.从证照库下载最新、高清、无水印版本；库中没有或过…；5.发起「用章用印申请」，附平台要求、待签文件、签字…；7.扫描回传并上传审批单；需寄送的登记单号；平台审核… 4.按平台模板填写授权委托书/承诺书，或用公司模板生…
LEG-11 合同编号、台账与原件归档 2.编号写入合同正文首页和订货单，盖章前由行政核对；3.双签后上传扫描件，填写台账必填字段；5.调阅：申请人在台账查编号与位置，借原件需登记，用…；7.历史合同一次性清理：各部门申报手头合同，补编号、… 1.合同审批通过时自动生成合同编号（订货单编号同规则…；6.每季度首月：台账与审批单、财务收付款记录比对，追…
LEG-14 专利审查意见答复与状态同步 1.要求代理所有邮件发往统一知识产权邮箱，官文卡片推…；2.登记台账：官文类型、到达日、官方期限、内部回复截…；3.指派发明人，在群里或任务中写清“哪一件、改什么、… 1.要求代理所有邮件发往统一知识产权邮箱，官文卡片推…；2.登记台账：官文类型、到达日、官方期限、内部回复截…；6.核对代理系统状态与台账一致，更新“下一步责任人”；7.每周一机器人推送：待发明人回复、代理处理中、临近…
LEG-15 专利挖掘培训与知识产权激励申报 2.审批并发布，在通知群和知识库置顶，附 FAQ；3.组织专利挖掘培训（线下 + 线上），录屏归档；4.培训后 2 周内收集专利线索，进入 POL-11…；5.员工在节点达成后提交激励申报（关联台账编号）；8.公示后兑现：积分入账，奖金随当月工资发放 6.核验台账状态、发明人及分配比例
LEG-16 商标查询、注册申请与驳回复审 1.命名候选确定前提交检索申请（每次 2～3 个备选…；5.准备标样并委托代理递交，统一缴费；6.登记台账；受理、初审公告（3 个月异议期）、注册…；8.注册后：证书归档，产品负责人按注册类别每月上传使… 2.委托代理近似检索，回传风险评级与近似商标；3.预选类别与群组：核心类（如 9/42/35）、防…；6.登记台账；受理、初审公告（3 个月异议期）、注册…；8.注册后：证书归档，产品负责人按注册类别每月上传使…
LEG-17 被抄袭/侵权线索处置 1.在「侵权线索」表登记链接、截图、被抄内容、发现时…；6.先礼后兵：按模板发沟通函或邮件，要求 5 个工作…；8.结案：更新线索状态，判断是否补申专利/软著/商标… 2.固定证据：全页截图 + 录屏 + 网页存档 + …；3.调取我方原始证明，AI 比对文案/界面/代码相似…；4.查明对方主体及类型：企业、政府或事业单位、个人、…
LEG-18 用户协议、隐私政策、EULA 与免责文案… 1.需求评审勾选“涉及协议/隐私/免责”，登记协议变…；3.法务审核条款合法性、完整性，出修改意见或定稿；5.上线：在线链接托管、登录注册页勾选同意、关于页入…；6.归档版本号、生效日、变更摘要；新增收集项或第三方…；8.半年复核：法规变化、功能变化与协议一致性 2.按模板库起草或修订，AI 生成初稿，附数据流向清…；5.上线：在线链接托管、登录注册页勾选同意、关于页入…；7.变更守卫：必备法律文案清单内容被修改或删除，须法…
LEG-19 新产品/新功能上线合规评估 1.需求评审时逐项勾选合规清单，命中即提交合规评估单…；6.按整改项开发，测试逐项验收；7.上线门禁：合规整改项未关闭不得发布；需要改协议的…；8.结论入库，按问题类型可检索；上线后变化（换模型、… 2.补齐材料：数据流向图、来源授权、上游条款、开源许…；3.AI 初筛：对照合规清单与结论库标出风险点和相似…；8.结论入库，按问题类型可检索；上线后变化（换模型、…
LEG-20 AIGC 内容安全审核与 AI 生成标识… 1.推广前检查：内容审核已接入、手机号注册、日志留存… 2.接入审核：用户 prompt 与润色后 prom…；3.AI 生成标识：图片/视频/PPT 加隐式标识（…；4.分级配置策略：C 端正式服保守；测试服可放宽但不…；8.月度复盘：误杀率、漏放数、策略变更、题库更新，修…
LEG-21 营销短信与推广内容合规审核 1.提交发送申请：目的、对象、文案、链接、时间、数量；4.文案检查：签名为公司/产品名；带“拒收请回复 R…；5.通道报备：营销类走推广短信签名与模板，不得放进验…；6.先向内部账号小批量试发，确认展示与链接后正式发送…；8.审核通过的文案入模板库，注明适用场景与审核日期 2.分类：含优惠、免费、活动、拉新、召回即为营销类；…；3.核查对象：营销类只发给已同意接收营销信息的用户，…；7.监控投诉、退订率、拦截率；收到投诉 24 小时内…
LEG-22 业务合规红线与灰色业务风险隔离 2.对照红线清单自查：命中“禁止”项直接婉拒；命中“…；3.提交风险评审单，写明目的、规模、数据来源、技术方…；6.附条件执行：与有资质合作方签书面合同明确合规责任…；8.评审结论入台账；每季度复查附条件事项是否仍满足条… 2.对照红线清单自查：命中“禁止”项直接婉拒；命中“…；8.评审结论入台账；每季度复查附条件事项是否仍满足条…
LEG-23 ICP/网站/App 备案办理与备案信息… 1.登记备案需求：域名/App、用途、拟用主体、对外…；4.按材料包模板备齐材料，盖章签字走用印审批；5.在云厂商提交（每批不超过 2 个域名），跟进初审…；6.网站开通后 30 日内办理公安联网备案；页脚展示…；7.登记台账：域名/App、主体、备案号、负责人、联…；8.信息维护：核查电话/邮件当天响应；人员离职、电话… 2.查台账：是否已备案、能否用已备案主域名的子域名、…；7.登记台账：域名/App、主体、备案号、负责人、联…
LEG-24 增值电信业务许可证办理与年报 1.合规日历在每年 1 月第 1 周按主体、按证自动…；2.核对持证清单、有效期与系统账号可登录；4.在系统填报，业务说明与许可类别（ICP/EDI …；6.提交并截图回执，回执与材料包归档；11.内部审批（含用印，LEG-09）后在系统提交，必…；12.证照原件入档案柜并登记保管人；新证下载电子证照、… 3.收集材料：财务报表、业务数据、网络与信息安全制度…；9.起草网络技术方案、安全保障方案（AI 基于需求与…
LEG-25 算法备案、办学许可、3C 认证等专项资质… 1.在资质台账登记需求，注明类型（算法/办学/3C/…；8.提交/送检，每周五更新进度；供应商承诺日前 3 …；9.取证后上传证书、录入编号与有效期；3C 同步更新…；10.到期前 90 天、主体或配置变更时自动提醒；新机… 4.准备材料：算法备案由材料负责人基于历史成功材料包…；6.算法备案：一致性核对——算法名称、产品全称、主体…；10.到期前 90 天、主体或配置变更时自动提醒；新机…
LEG-26 境外主体设立与海外 AI 服务采购合规 1.提交“境外采购/主体需求单”；5.委托注册代理设立主体、申请税号、开立银行或支付账…；6.以公司主体和公司邮箱开通服务账号，凭据进入密码管…；7.付款取得发票或收据，按跨境付款入账；8.登记境外主体台账：注册地、年审日、报税日、账户、… 2.排查境内替代方案并对比成本、合规性；8.登记境外主体台账：注册地、年审日、报税日、账户、…
LEG-27 开源与保密规范制定、评审与发布 4.发起评审：@评审人并附评审清单；意见逐条录入意见…；6.终审：法务书面确认，CEO 批准；7.发布：HR 复核规章程序，全员公告并签收，写明生…；8.配套落地：按条款建 SOP、表单、审批流和提醒；… 2.起草：保密与开源分为两个文件（保密为基础、开源为…；5.改稿：逐条标注采纳/不采纳及理由；AI 做条款交…
LEG-28 开源组件引入与许可证合规评估 1.提交飞书“开源审批”引入申请，按准备清单填写 2.CI 扫描依赖树许可证，标记 copyleft、…；6.登记组件台账；关键依赖 fork 稳定版到公司 …；7.发版前生成第三方声明（NOTICE），核对版权信…
LEG-29 员工开源账号备案与对外开源发布审批 1.在开源平台账号收集表报备账号（无账号也填写）；入…；2.按《开源项目申请 SOP》提交申请表单，注明类型…；4.审批：L3 指定复核责任人，分级后 10 天无操…；6.在公司 GitHub/HuggingFace 组…；7.登记开源项目台账，关联开源积分与激励；8.孵化项目每月更新进度，每季度复盘继续维护或归档 1.在开源平台账号收集表报备账号（无账号也填写）；入…；5.发布前检查：扫描密钥与敏感配置，补许可证文件、N…；7.登记开源项目台账，关联开源积分与激励
LEG-30 对外提供材料与代码权限的保密审查 1.提交“对外资料/源码授权”申请；4.签 NDA：使用法务标准模板，不临时自拟；5.审批：客户材料由法务批；源码由 CTO+法务批，…；6.受控交付：文档加水印、链接设有效期、禁止下载；代… 3.选择提供方式：优先演示视频/截图/脱敏样例；确需…；7.登记外发台账，到期自动提醒回收权限或要求删除
LEG-31 代码与机密资产外泄管控及事件处置 1.资产定级并登记，L1/L2 标注可接触人员范围；2.只通过仓库/文档权限分发，不发压缩包；每个拷贝持…；8.复盘：收紧权限（如组织创建权限）、补规则、全员提… 3.扩大范围或对外前完全清洗改写，AI 比对确认无原…；4.每周扫描员工报备账号与公司关键词的公开仓库；6.影响评估：内容、级别、暴露时长、是否被 fork…
LEG-32 诉讼、仲裁与法律纠纷应对 1.文书接收后登记期限，前台/行政收到法律文书当天转…；2.收集并固定证据；4.管理层决策 2.收集并固定证据
LEG-33 监管问询、执法调证与约谈应对 1.任何员工接到监管来电/来函，当天转法务，不自行答…；4.审批提供范围；5.按最小范围导出数据，双人核对后提供；7.归档并复盘制度与产品改进 5.按最小范围导出数据，双人核对后提供
LEG-34 个人信息权利请求与数据安全事件合规处置 1.受理登记并核验身份；3.回复用户处理结果；7.归档并推动整改 2.权利请求：研发按请求导出/删除并确认
LEG-35 合同履约节点与到期续约管理 2.录入台账并设置提醒；5.审批续约/终止/变更；6.发出通知函或签署补充协议；7.更新台账状态 1.签约归档时提取关键节点；3.节点前提醒经办人
HR-01 人事制度编制、意见征集与发布宣贯 2.按模板起草初稿，标出待决条款；3.管理层批注；涉及工时/加班/解除条款同步送法务；5.易误解条款（如年假折算）发表单试填，收集可理解性…；6.全员解读并公布截止时间；意见由部门内部收集、汇总…；8.终审定稿与生效日；9.配置飞书假勤/审批规则，与条文逐条对应；10.全员群发布正式通知（附原文链接、生效日、答疑渠道…；11.线上+线下宣贯会：会前 1 天预告、会议签到；无…；12.入制度库，登记版本与修订历史 2.按模板起草初稿，标出待决条款；6.全员解读并公布截止时间；意见由部门内部收集、汇总…；7.逐条处理意见，形成定稿与意见回复；11.线上+线下宣贯会：会前 1 天预告、会议签到；无…
HR-02 组织架构调整与飞书架构/审批人维护 2.更新架构表：岗位、直属上级（只写一人）、部门负责…；4.全员发布调整通知（内容、生效时间、反馈截止时间）；6.飞书后台同步部门、直属上级、部门负责人；7.复核受影响审批流审批人，并通知财务等审批流设计方；9.涉及关联主体的调整同步对方负责人；归档 8.员工填反馈表，汇总问题并处理
HR-03 HC申请与人力成本统计 1.填写 HC 申请（岗位、数量、理由、预算、ROI…；5.获批后转招聘并登记在招清单；6.入职/离职/调岗当日更新花名册；7.拉取上月工资与社保数据，更新月度人员成本表 2.提供本部门最新人员与成本基数；7.拉取上月工资与社保数据，更新月度人员成本表；8.管理层临时要数时，从仪表盘直接导出
HR-04 用工主体判定与劳动合同/协议签署 1.通过入职表单一次性采集合同字段与身份信息；5.向用人负责人确认主体、岗位、试用期、起薪、入职日…；7.发起用章用印申请（可按批集中）；8.打印、盖章，入职当日完成全部签署；9.登记主体、类型、期限、到期日并归档原件与扫描件 6.拟定合同及配套协议草稿，发群审核；9.登记主体、类型、期限、到期日并归档原件与扫描件；10.合同到期前 30 天提醒续签/改签
HR-05 新员工入职准备与办理 1.提交入职通知单（组别、直属上级、导师、设备、账号…；2.发候选人入职通知（地点、上班时间、携带材料、社保…；3.候选人填入职信息表，HR 核对证件信息；4.设备采购或调配需求报 IT，按标准配置；5.确认工位、门禁/工牌、名片（子公司区分主体）；6.检查飞书席位，不足时通知财务购买；7.邀请飞书账号并放入正确部门与直属上级；8.按岗位清单开通邮箱、代码仓库、VPN 客户端、I…；10.拉入部门群与对应群；部门群发布介绍（姓名、职责、…；11.核验入职清单，未完成项指派并追踪 2.发候选人入职通知（地点、上班时间、携带材料、社保…；6.检查飞书席位，不足时通知财务购买；8.按岗位清单开通邮箱、代码仓库、VPN 客户端、I…；10.拉入部门群与对应群；部门群发布介绍（姓名、职责、…
HR-06 新人入职培训、带教与首周上手 1.指定导师、填写入职交接卡（岗位、首周任务、权限边…；3.首日讲清作息（上下班、弹性规则、午休、打卡）、请…；5.执行首周任务，新人每日简报，导师当日反馈；7.参加集中入职培训（价值观、架构、部门职能、产品、…；9.30 天回顾，结果转给 HR 作为转正评估输入 2.向导师和新人推送通用+岗位资料包；3.首日讲清作息（上下班、弹性规则、午休、打卡）、请…；6.新人遇到资料未覆盖的问题记入 FAQ，由文档负责…
HR-07 实习生用工管理 2.签实习协议，登记档位、观察期（2 个月）、导师、…；3.告知计薪规则（按实际出勤日结算、8 小时计 1 …；4.每日打卡或提交日报（线上：日报+提交记录）；6.导师确认出勤天数并标注异常（请假、缺勤、失联）；8.发放实习薪酬及补贴；9.办理三方协议、实习证明、日志盖章；10.调岗/借调时更新台账归属与评价人；11.观察期满前 15 天发起转正评估（HR-08）或… 4.每日打卡或提交日报（线上：日报+提交记录）；5.月初机器人提醒导师确认上月出勤；7.核算薪酬并与在册名单对账（防漏发、多发）
HR-08 试用期/实习观察期考核与转正 1.起草考核指标，HR 统一格式，管理层确认后告知本…；2.2 周与 1 个月检查点面谈，记录问题与改进要求；4.发起转正审批，员工提交转正报告；8.发书面转正通知；实习转正改签劳动合同、调薪补书面…；9.更新花名册与工资表，归档全部材料 3.每月 1 日生成次月到期名单并@评估人；9.更新花名册与工资表，归档全部材料
HR-09 薪酬定级与调薪 1.维护薪酬带宽与实习档位表，研发/非研发、线下全职…；2.提交“定级/调薪申请”：员工、类型（转正定级/绩…；5.按统一口径写明“生效月（从该月工资起算）/实发月… 7.审批结果自动写入人员异动表，随月度异动推送财务；8.首个实发月核对工资条新薪资，审批单与告知记录归档
HR-10 日常考勤打卡、补卡与到岗规范 1.发布一页纸考勤指引：工作时间、弹性区间、最晚到岗…；2.配置飞书考勤：打卡范围、弹性规则、跨零点下班卡、…；5.员工提交补卡申请，写明原因、附凭证（如加班记录）；7.到岗核查：超过最晚到岗时间未打卡且无请假/外出/… 4.缺卡、迟到由考勤机器人推送本人并抄送直属上级，不…
HR-11 请假、居家/远程办公与外勤报备 1.选择对应类型提交审批（事假/病假/年假/调休/居…；2.审批按部门自动路由到直属上级；超过 3 天或超出…；5.居家/远程期间参加站会（开摄像头），下班前提交当…；6.计划变更在审批流内撤回或修改，不在群里口头改 3.审批通过自动推送团队群与项目负责人，并在日历上标…；7.按制度（司龄口径）维护年假额度，调休余额由加班审…；8.月末请假、外勤数据进入月度考勤核对
HR-12 加班申请、工时登记与调休/加班费结算 1.制度成文：申请审核、倍率、周末/节假日扣除休息时…；2.事前申请：员工本人提交（日期、预计时长、任务、安…；4.加班期间手动打卡上下班；5.在原申请单补充实际时段、时长、成果证明；扣除用餐…；9.调休余额写入飞书假勤；加班费进入当月工资表并在工… 7.审批与打卡自动比对，生成月度加班明细；9.调休余额写入飞书假勤；加班费进入当月工资表并在工…
HR-13 节假日放假调休与值守安排通知 1.发布全年放假与调休日历，员工订阅；2.发起长假方案收集：居家/到岗日期、值守人、onc…；5.起草正式通知（放假与补班、公司调休日抵扣、居家安…；6.配置飞书假勤：补班日、公司调休日自动扣减余额 6.配置飞书假勤：补班日、公司调休日自动扣减余额；8.节后核对补班日考勤与调休扣减；节中加班转 HR-…
HR-14 月度考勤核对与请假扣薪核定 3.机器人推送个人异常与补卡截止时间；通知群同步发布…；4.员工自查并补卡、补请假；直属上级当日审批；8.锁定考勤结果，提交工资核算；扣薪在工资条单列原因 1.日常：每周一把上周缺卡、迟到、未请假缺勤推送本人…；2.导出上月考勤，与审批记录自动比对，标记缺卡、事假…；3.机器人推送个人异常与补卡截止时间；通知群同步发布…；8.锁定考勤结果，提交工资核算；扣薪在工资条单列原因
HR-15 月度工资核算发放与员工个税答疑 1.收集当月异动与考勤，建立当月薪资表；2.薪资表定稿（公式模板锁定，禁止手改公式），生成与…；5.分主体发起付款审批（附汇总，明细另存）；6.审批付款；超 24 小时未批自动提醒；8.推送飞书工资条，员工点击确认；9.个税申报；员工咨询 2 个工作日内答复，共性问题… 2.薪资表定稿（公式模板锁定，禁止手改公式），生成与…；9.个税申报；员工咨询 2 个工作日内答复，共性问题…
HR-16 社保公积金缴纳与增减员 3.办理社保、医保、公积金增减员与基数申报；4.提交付款审批并缴费；6.更新员工缴纳台账：主体、基数、比例、起缴/停缴月… 1.入职、离职、主体变更审批通过后自动写入当月增减员…；5.扣款明细与清单逐人对账，个人部分同步给工资核算；7.盘点应缴未缴、主体不一致名单，提出补缴与调整方案…
HR-17 AI工具补贴发放与调整 1.从人员主表同步当月入转调离，按岗位类别自动带出档…；2.汇总例外项（调档、特殊预支、暂停/恢复）发起审批；6.机器人推送发放通知，附规则 wiki 与 FAQ…；7.员工提交当月支出凭证（官方套餐截图、Invoic…；10.超出额度部分（不超过当月补贴 30%）凭发票走报…；11.规则变更：改 wiki 并升版本号，法务审条款，… 1.从人员主表同步当月入转调离，按岗位类别自动带出档…；4.合并上月核定结果（未达标者本月暂停），锁定名单，…；6.机器人推送发放通知，附规则 wiki 与 FAQ…；8.核对凭证，汇总合规支出，判断是否达到当月补贴 8…；9.通知未达标员工下月暂停，并同步给人事专员进入下月…
HR-18 积分激励制度运行 1.制度发布前完成：适用范围、一页纸省流版、FAQ；…；2.宣贯后收集问题，统一发布补充说明并更新 FAQ；3.各部门提交季度积分预算，运营组汇总；4.员工/部门在申报窗口提交申报（产品有效反馈可随时…；7.公示结果（不含个人薪酬信息）；9.登记台账，部门积分由部门负责人分配到个人后回填；10.兑换：积分兑奖金随次月工资发放；期权认购按补充说… 2.宣贯后收集问题，统一发布补充说明并更新 FAQ；5.初核：材料完整性、是否重复计分、是否属于适用主体…；9.登记台账，部门积分由部门负责人分配到个人后回填
HR-19 研发绩效评价与质量奖惩 1.迭代开始：公示参与人员、任务点数，员工自行认领任…；4.公示责任比例与 git 证据；10.随当月工资结算，归档；11.规则修订：起草 → 相关负责人评审 → 法务/人… 2.迭代结束：自动汇总个人完成故事点、测试工作量；6.月度汇总：工作量评级（以基线点数划 A/B/C/…；9.输出结果应用清单：奖金/扣款（交财务）、积分（交…
HR-20 员工绩效/行为问题访谈与处置 1.记录问题事实，填写问题登记表；人事个案不在工作群…；3.仍未改善或问题严重 → 提交人事立案；7.按模板出具文书，人事与直属负责人共同面谈告知，员…；8.改进期：设定目标、演示节点、辅导人；中期检查一次；10.归档；如调岗/终止，转交接与离职流程，同步 IT… —
HR-21 年度/阶段总结收集与1v1面谈 1.起草通知（目的、范围、模板、截止日、互读要求），…；3.按名册发布：全员群公告 + 给名册中每人建飞书任…；4.员工在飞书文档写总结，把链接填入汇总表；7.发布 1v1 预约：访谈人开放时段，员工自选（优…；9.汇总待办与结论：需跟进事项分派负责人；绩效/调薪…；10.归档总结与纪要，设置查看权限；复盘本轮问题 1.起草通知（目的、范围、模板、截止日、互读要求），…；5.截止前 2 天、前 1 天机器人提醒未提交者，截…；6.管理者阅读并批注；员工互读评论 3～5 份；AI…
HR-22 员工福利：体检与商业保险 3.签约付款、开通；登记机构对接人；4.发卡：按名单发放体检卡并登记台账；团险提交参保名…；5.发布《体检与保险使用指引 + 理赔 FAQ》，必…；6.预约：员工自行预约；想统一时间的填表，统筹人汇总…；8.收集体检报告，表单仅授权人员可见；截止前 7 天…；9.理赔答疑：先查 FAQ，FAQ 未覆盖的由统筹人…；10.季度更新团险名单（新入职正式员工、满 1 个月的… 5.发布《体检与保险使用指引 + 理赔 FAQ》，必…；6.预约：员工自行预约；想统一时间的填表，统筹人汇总…；7.体检前 1 天机器人提醒（证件、禁食、地址）；改…；8.收集体检报告，表单仅授权人员可见；截止前 7 天…；9.理赔答疑：先查 FAQ，FAQ 未覆盖的由统筹人…
HR-23 内部培训与分享会组织 1.提交分享/培训申请；4.发通知：在通知群发布并创建飞书日程邀请对应人群；…；5.按报名人数订会议室，同步创建飞书会议并开启自动录…；7.实施：线下 + 线上同步；签到；必到者优先线下座…；8.归档：妙记、录屏、课件放入知识库“内部课程”目录…；9.发反馈问卷，汇总评分与下期选题建议；10.强制培训：统计缺席人员，要求 5 个工作日内看回… 3.讲师提交大纲、课前准备清单；统筹人用模板生成公告…；6.开课前 1 天、前 1 小时提醒（会议链接、软件…；8.归档：妙记、录屏、课件放入知识库“内部课程”目录…；9.发反馈问卷，汇总评分与下期选题建议
HR-24 员工活动：年会、团建与委员/兴趣小组 1.制定年度活动日历（年会、两次团建、节日活动），委…；2.活动立项：方案 + 预算，提交审批（小额委员活动…；3.时间投票：发布前另一人核对选项完整，投票 48 …；4.定稿后发正式通知：时间、地点、路线图、时长、餐饮…；5.一表收集：是否参加、请假原因、饮食忌口、交通方式…；8.当天签到、执行环节；变更即时在通知群和日程同步更…；9.复盘：照片、参与人数、反馈、费用；委员活动登记到…；10.费用报销与凭证归档 7.前一天提醒：集合时间地点、天气、证件、交通班次；…
HR-25 人员调岗、借调与汇报线确认 4.发起“调岗/借调”审批：类型、直属上级、派活人、…；5.被调人员填交接清单，接手人逐项确认；6.调整代码仓库、业务系统权限、群成员、工位设备；7.更新飞书组织架构、直属上级、审批人；登记人员异动…；8.在原组群、新组群发通知：谁、调往哪、自何日起原事…；9.借调到期前提醒；借调方确认“暂无需求”后归还，或… 8.在原组群、新组群发通知：谁、调往哪、自何日起原事…；9.借调到期前提醒；借调方确认“暂无需求”后归还，或…
HR-26 人事异动同步通知 1.异动审批通过或生效日确定后，在“人员异动登记表”…；2.按类型自动推送：离职、调薪 → CEO + 财务…；3.各接收方在记录中点“已知悉/已处理”；4.未回执自动再提醒；第 2 个工作日人事单独确认；5.在人事管理群同步异动（不含薪资），确认有无特殊处…；6.架构类变动：先在相关群通知，再改飞书组织架构；7.汇总上月人员异动表，发群审核；8.审核通过后交财务，作为工资核算依据 2.按类型自动推送：离职、调薪 → CEO + 财务…；4.未回执自动再提醒；第 2 个工作日人事单独确认；7.汇总上月人员异动表，发群审核
HR-27 员工离职办理与交接 1.在飞书提交离职申请（实习生、兼职同样提交）；2.审批，确定 last day、各类接手人；人事确…；4.按模板写交接文档（进行中事项、文档位置、账号、对…；5.网盘资料、LeapCore Agent 数据用管…；6.核查报销、借款、付款未回票、预付费用、加班，出结…；9.回收资产；封 Gitea，停飞书、企业微信、云平…；10.清理飞书席位；11.按实际出勤折算最后工资；无法调休的加班按加班费结…；12.离职资料归档，出具离职证明 3.审批通过自动生成离职清单任务，分派财务、行政、I…
HR-28 人事档案管理与信息权限分级 3.入职当天推送档案表单；员工提交后人事校验完整性，…；4.纸质材料放入带锁档案柜，更新目录索引；电子件存入…；5.按分级表配置多维表格字段权限与文档权限；给行政等…；6.权限新增或收回：提前通知受影响者并说明依据；7.季度盘点：档案缺项、合同签署与到期、权限名单、档…；8.调阅或对外提供：登记调阅人、用途、范围、审批人、… 3.入职当天推送档案表单；员工提交后人事校验完整性，…；7.季度盘点：档案缺项、合同签署与到期、权限名单、档…
HR-29 员工申诉与劳动争议处理 1.受理登记，确认诉求与涉及期间；2.调取并固定证据，访谈部门负责人；5.出具书面处理决定或签署调解协议；7.结案归档，复盘制度漏洞 2.调取并固定证据，访谈部门负责人
HR-30 工伤与员工意外事件处理 2.填写事故登记表，留存现场证据；5.同步商业保险报案与理赔材料；7.隐患整改、通报与归档 —
HR-31 劳动合同到期续签与终止 1.系统按到期日自动提醒人事与部门负责人；2.部门负责人提交续签意见；4.审批续签/终止决定；5.与员工沟通并签署续签合同或送达终止通知；6.同步财务、行政及账号相关方；7.归档并更新台账 1.系统按到期日自动提醒人事与部门负责人
HR-32 非研发岗位周期绩效考核与结果应用 1.发起周期，下发目标表；3.员工自评并附依据；7.结果应用并通知财务 3.员工自评并附依据
HR-33 竞业限制启动、豁免与补偿支付 1.离职审批时自动提示是否签有竞业协议；3.审批并在最后工作日前书面通知员工；7.期满或解除后停止支付并归档 5.定期请员工提供就业情况说明
X-CS-01 售后服务体系、分工与值班排班 2.出下月研发 oncall 表和产品值班表，写入同…；3.值班表发布到研发群、反馈群、市场销售通知群，说明…；6.出节假日值班表（多维表格+群公告，不用图片），销…；7.换班/请假：值班人自行找替班并在表中改人，机器人…；8.月度复盘：首响超时、转研发量、高频问题，调整分工… 4.机器人每个工作日 9:30 在反馈群 @当日产品…；8.月度复盘：首响超时、转研发量、高频问题，调整分工…
X-CS-02 客户试用/正式账号开通、封停溯源与席位扩… 1.提交「客户账号/席位申请单」（类型：试用/正式/…；5.登记台账：客户、来源、开通人、账号、额度、席位、…；6.通知申请人，由申请人告知客户；扩容须讲清"席位≠… 3.开通：在白名单网络登录管理后台，在正式环境创建账…；4.扩容：按单席位内存估算口径核对硬件；够则改组织最…；7.月度对账：后台账号与台账比对，列出无主账号；到期…
X-CS-03 客户额度充值到账、分配与补发 1.提交「额度变更申请」（付费充值/补发/赠送/扣减…；2.付费：财务确认到账；赠送/补发：审批人审批，写明…；5.校验：额度为 0 时被自动禁用的 token 已…；6.登记台账并附截图；7.通知申请人，申请人告知客户并确认可用 4.在 NewAPI/后台执行，截图留证；批量补发用…；5.校验：额度为 0 时被自动禁用的 token 已…；9.月度对账：台账 vs 系统额度 vs 收款
X-CS-04 客户私有化实例登记与在线监控告警 2.在 cloud 注册，填写客户、渠道、编号字段（…；3.写入实例台账；4.渠道分机：渠道通过渠道系统提单回填终端客户，交付… 5.后台定时检查 VPN 在线和核心服务健康；工作时…；6.飞书机器人推送告警到售后群，附实例名、客户、渠道…；8.月度核对 cloud 实例清单与台账，补齐差异
X-CS-05 客户问题受理、分流与工单流转 1.通用问题发 Leap 反馈群或用产品内"报告问题…；7.需求转需求池，Badcase 转收集表，收费/合… 2.机器人识别新帖，缺字段时自动回复补充清单，生成工…；4.分级（P0 多客户或核心功能不可用；P1 单客户…；5.咨询或已知问题：按 FAQ 答复（重启客户端、检…；9.每周汇总高频问题，更新 FAQ 与机器人知识库
X-CS-06 客户现场问题分级排查与日志/诊断包收集 2.未解决：指导客户导出诊断包，直接上传到工单，不经… 1.按排查顺序自查：是否使用方法问题 → 是否已知问…；3.初判（客户网络、安全软件、版本过旧、余额不足、上…；7.修复：单客户手工处理；多客户写带保护逻辑的批量脚…
X-CS-07 客户端安装、更新与模型服务连接问题一线支… 1.核对系统要求：Windows 10 及以上、ma…；5.仍未解决：收集截图、开始时间、模型/入口、版本、… 4.模型服务不可用：先说明不是客户电脑坏了；完全退出…；7.回复客户；新出现的问题补进排障手册和 FAQ 机…
X-CS-08 账号登录失败与密码找回 3.管理员忘记且无其他管理员：提交「管理员密码重置申…；7.建议客户为员工新建超管，不再共用一个超管号；留档 —
X-CS-09 计费余额异常核查、对账修复与退款 1.按"办之前请准备"收齐信息，登记计费异常工单，回…；7.审批：补偿/退款由产品负责人批准并抄送财务；P0… 3.P2 规则解释类（预占、最低余额门槛、失败扣费口…；4.查证：支付回调、钱包流水、网关请求日志、缓存读写…；10.P0/P1 写复盘；新口径补进 FAQ 与接入指…
X-CS-10 C 端用户售后入口、退款与客诉处理 1.统一入口受理（客服电话、售后邮箱、平台反馈入口、…；2.内部人员（含管理层）接到用户电话/私信时，不自行…；5.提交审批：经合作方结算的订单提交合作方并记录提交…；7.跟踪：每 2 个工作日查一次进度并主动回告用户；… 4.判断：符合退款条件 → 进入审批；不符合 → 按…；9.结案归档，新问题补进话术库；退款链路问题提缺陷，…
X-CS-11 定制客户特殊配置台账与售后范围界定 1.任何非标方案先提特批，批准后登记台账；相关脚本/…；8.更新台账（问题记录、脚本版本、负责人变化） 5.复现与诊断：对比请求/响应，形成兼容性结论（问题…
X-CS-12 硬件设备售后、返修与上门维保 1.统一入口受理（售后邮箱、服务热线、反馈群），登记…；6.返厂：按厂商返修清单（寄送地址、联系人、所需材料…；9.结案：关闭售后工单，更新设备台账（状态、IP、换… —
X-CS-13 客户反馈转缺陷/需求与修复验收闭环 1.所有渠道反馈汇入统一入口（反馈群机器人、飞书表单…；5.紧急（客户无法使用、数据或资金问题）直接提紧急工…；8.修复后标注修复版本，指派验收人（原反馈对接人或测… 1.所有渠道反馈汇入统一入口（反馈群机器人、飞书表单…；2.值班人每日汇总，AI 先做分类和去重，生成工单草…；10.回告反馈人/客户，工单状态回写反馈群；11.月度复盘：反馈量、类型分布、系统性问题、未闭环项
X-CS-14 客户新需求承诺前可行性确认与变更响应 1.对客只回复"已记录，评估后答复"，不当场承诺能做…；6.要做的：进需求池或变更单；需加价的转销售报价并补…；7.记录对客承诺（内容、时间），到期前 3 天检查兑… 5.按模板对客答复：Bug 才走免费修复；新增需求经…
X-CS-15 版本更新/停机客户通知与更新日志 1.发版计划确定：时间窗、是否停机、受影响范围；各需…；4.客户群通知：停机类提前 24 小时；普通更新提前…；5.发布时间变动或延期：立即补发更正通知（内部+客户…；7.完成后发恢复通知；发布更新日志到帮助中心；公司群… 2.按模板起草客户通知（时间窗、影响、保存数据提示、…；4.客户群通知：停机类提前 24 小时；普通更新提前…
X-CS-16 服务迁移中的客户账号与余额迁移 3.方案审批：涉及客户余额或关停对外服务的需 CTO…；5.通知客户：先内部销售/售后，再逐个客户群/试点单…；9.销毁资源并登记；新旧环境加醒目环境标识；更新资产… 1.依赖盘点：从日志拉取旧环境近 30 天调用方与余…；4.定口径：话术、FAQ（继承什么、客户怎么做、截止…；6.迁移账号/余额：按清单批量迁移，核对迁移前后总额…
X-CS-17 对外沟通口径、FAQ 话术与对外信息脱敏 1.按关键词查 FAQ 口径库，命中则直接按口径回复…；2.未命中：在口径申请表提交（客户原话、类型、草稿）…；6.对外回复前做脱敏检查：去掉激活码、后台地址、账号…；7.定稿口径入库（适用范围、生效日期、负责人），推送…；8.每次发版或模型档位/价格变化时复核相关条目，过期… 1.按关键词查 FAQ 口径库，命中则直接按口径回复…；3.AI 基于口径库与产品文档生成候选口径；8.每次发版或模型档位/价格变化时复核相关条目，过期…
X-CS-18 帮助中心、使用手册与交付注意事项维护 1.通过统一表单提交内容需求或共性问题（不走私聊）；5.发布到帮助中心/手册，写版本号与更新日期；6.在产品内“帮助”入口、交付群公告、销售群同步链接；8.每个迭代发版前按 checklist 复核受影响… 3.基于问题库与竞品文档生成初稿；6.在产品内“帮助”入口、交付群公告、销售群同步链接
X-CS-19 重点客户回访与使用推进 1.交付验收后建回访计划（7/14/30 天节点，之…；4.填回访记录模板；5.反馈分类（缺陷/需求/定制/咨询/优秀案例），A…；6.缺陷进 badcase 表、需求转 X-CS-1…；9.月度复盘：活跃度变化、反馈消化率、未用起来客户名… 2.每周拉取客户后台活跃度，低于阈值自动提醒；5.反馈分类（缺陷/需求/定制/咨询/优秀案例），A…；9.月度复盘：活跃度变化、反馈消化率、未用起来客户名…
X-CS-20 客户成功案例与效果文档制作 1.提出案例需求（用途、受众、截止日期）；6.定稿入案例库，标注“内部可用/对外可用”与有效期；7.推送给销售/品牌，按 SAL-15、BRD-15… 3.按模板生成案例初稿；7.推送给销售/品牌，按 SAL-15、BRD-15…
X-CS-21 VIP 客户“一键增强”人工代写服务 1.提交白名单申请，研发负责人审批后在后台添加（替代…；3.值守人点“认领”，超时未认领自动提醒研发负责人；7.通知客户经理，由其告知客户；8.工单记录完成时间、耗时，关闭工单 2.客户点击后机器人推送通知卡片，自动生成工单；3.值守人点“认领”，超时未认领自动提醒研发负责人；4.用 Claude Code + 增强 skill…；6.回写数据库并在客户侧确认已更新
X-CS-22 俱乐部/商户入驻与会员端配置对接 1.合作确认后建入驻工单，记录俱乐部等级与对接人岗位；2.发材料清单与信息收集表；8.上线确认，台账状态改“已上线”，拉入客户服务群；9.首月每周跟进使用；咨询先查知识库，配置类需求登记… 6.按模板导入客户名单，核对匹配成功/失败，失败数据…；9.首月每周跟进使用；咨询先查知识库，配置类需求登记…
X-CS-23 俱乐部客户反馈受理与转研发排查 1.在问题受理表登记，必填项不全则一次性向客户索取；3.分级：P0 资金类或重点俱乐部批量问题；P1 单…；6.用回复模板告知客户结果，必要时请客户复核（积分小…；7.根因归类（填错/接口变更/规则/积压/缺陷），重… 2.用 AI 小助手/星域 bot 查库自查，常见问…；3.分级：P0 资金类或重点俱乐部批量问题；P1 单…；7.根因归类（填错/接口变更/规则/积压/缺陷），重…
X-CS-24 俱乐部账务类工单处理 1.俱乐部经客服入口提交工单，选择类型并上传材料；3.审批：账户类由跃竞负责人批；资金类由跃竞负责人 …；6.通知俱乐部结果，请其确认；7.工单关闭归档，月底汇总给财务 6.通知俱乐部结果，请其确认；7.工单关闭归档，月底汇总给财务
X-CS-25 订单投诉受理与售后缓冲规则 5.顾客确认结案或发起二次申诉；逾期未操作按规则自动…；8.退款/罚款/补偿按权限分级审批后执行，财务核对资…；11.每月汇总投诉量、类型、时效、赔付金额，回流规则与… 1.顾客在订单详情发起投诉，系统校验投诉次数、订单状…；2.系统向接待、陪玩推送待办角标与定向通知，启动首响…；4.接待给出首次处理结论（驳回/退款/罚款/补偿），…；9.自助订单：凭证齐全后启动 48 小时售后缓冲期，…；11.每月汇总投诉量、类型、时效、赔付金额，回流规则与…
X-CS-26 客户续约续费与维保到期管理 1.交付/签约后登记到期信息 2.到期前 60 天机器人提醒；3.输出客户健康度（使用、问题、满意度）
X-CS-27 B 端客户投诉升级处理与满意度回访 1.登记投诉并首次回应客户；4.形成处理方案（含补偿），涉及补偿走审批；6.整改完成后满意度回访 —
X-CS-28 售后访问客户环境与数据的授权留痕 2.向客户发送授权申请（范围、时长、操作人）；3.内部登记访问申请；4.审批；7.告知客户访问结束及结论 —
X-CS-29 客户服务终止、账号注销与数据返还销毁 3.书面通知客户导出窗口（建议不少于 15 天）；8.关闭客户台账与实例台账 4.协助客户导出/返还数据；5.停服、注销账号/组织/席位，回收指纹授权；6.删除生产数据与备份中的客户数据
X-PRD-01 产品方向、路线图与新产品形态决策 1.把机会/热点登记到“机会池”，标来源、类型、紧急…；6.ADR 归档，在相关群发布结论；已定事项本季度不…；7.纳入季度路线图或新建立项卡，拆里程碑与负责人；8.内部 dogfood 或首批用户试用，收集反馈 2.生成初研稿：竞品做法、技术路线、市场信号，人工核…；4.“跟进”条目出方案：定位、目标客群、形态备选对比…
X-PRD-02 竞品调研与对标评测 1.发现即登记竞品档案（名称、链接、版本、发现人），…；5.结论分流：可借鉴点进需求池（X-PRD-05）；… 3.用基准任务集做同任务对比，记录过程截图与耗时；4.按模板写对标结论：功能、质量、稳定性、价格、可借…；7.月度竞品简报：本月新增、重点变化、对我方影响
X-PRD-03 用户调研、专家访谈与场景案例沉淀 1.写调研计划：目的、假设、画像、样本数（首轮 3 …；3.约访，提前 1 天发提纲；7.客户场景整理成案例（场景、原做法、用产品后做法、…；8.用户顾问群固定每周 1 次访谈时段，问题与回答入… 4.访谈，全程录音并 AI 转写；5.纪要入库：关键原话、痛点、期望、是否目标用户；7.客户场景整理成案例（场景、原做法、用产品后做法、…；9.月度调研简报：本月访谈数、主要结论、画像变化
X-PRD-04 行业版需求摸排与产品规划 1.行业版登记：是否切独立行业版、负责人、目标客户；2.需求摸排：表单提交场景、已做、进度、需标品支持、…；6.建排期表/功能清单，按周迭代，展示进度、状态、节…；9.需求池状态流转：状态 + 当前负责人字段，状态变… 4.编写行业版规划：目标客户、高频付费场景、MVP、…；7.插件需求：业务专家写需求文档初稿 → 客户方各板…；10.周度提醒未填/未更新负责人，周报汇总各行业版进度
X-PRD-05 需求统一收口与提需入口规则 1.通过唯一表单提交需求（群里提的由机器人一键转单，…；5.排入迭代，状态变化自动通知提出人与研发 1.通过唯一表单提交需求（群里提的由机器人一键转单，…；2.受理：查重、补问、AI 补全上下文与验收标准草稿；9.回告提出人：已上线版本 / 不做原因 / 暂缓到…
X-PRD-06 内测与内部试用（dogfood）反馈收集… 1.发内测公告并置顶：版本、范围、体验清单、唯一入口…；3.反馈：优先填表单；群里吐槽由机器人/AI 一键转… 3.反馈：优先填表单；群里吐槽由机器人/AI 一键转…；4.每日 triage：去重；bug → Gitea…；6.发版后更新已知问题表，机器人回告反馈人“已在 x…；7.内测周报：活跃人数、反馈数、未关闭数、Top 问…
X-PRD-07 外部用户、客户与销售反馈收集回流产研 1.按提报规范发到统一反馈群（或表单）；高优同时填表…；4.分流：bug → Gitea（P0/P1/P2）… 2.机器人抓取入反馈总表，自动查重、给分类建议（不直…；7.回告反馈人；高频问题更新 FAQ 与话术；8.销售侧周汇总：问题/建议/咨询分类、Top 问题…；9.月度反馈复盘：总数、闭环率、系统性问题、核心共创…
X-PRD-08 Agent Badcase 收集与转需求… 1.通过 Badcase 表单提交，自动带出会话 I… 1.通过 Badcase 表单提交，自动带出会话 I…；2.初筛：AI 先去重和预分类，评测工程师判定有无价…；4.入样本库并标注：任务类型、失败环节（理解/规划/…；6.研发修复后用原样本回归，通过则关闭并回告提交人；7.月度报告：新增数、失败环节分布、已修复率；典型样…
X-PRD-09 需求提报登记与需求池管理 1.通过“需求提报表单”提交；群里口头提出的，由需求…；3.机器人回执提出人：编号、当前状态、预计评估日期；5.采纳需求入工作台，指派产品负责人、研发负责人、测…；7.状态改为“开发中/待测试”时自动 @测试负责人；8.发版后状态改“已上线”，回填上线日期，机器人通知…；9.双周查漏：清理超 30 天无进展需求、核对状态与… 1.通过“需求提报表单”提交；群里口头提出的，由需求…；2.查重归并：相似需求合并、计票，重复项关联原记录；8.发版后状态改“已上线”，回填上线日期，机器人通知…；9.双周查漏：清理超 30 天无进展需求、核对状态与…
X-PRD-10 需求优先级评估与紧急插单 1.填写“高优需求正式提报”表单；高层口头需求由产品…；5.书面回执提出人：结论、预计时间、理由；正式提报不…；6.插单：更新迭代范围，移出项标记“下迭代”，@测试…；7.每周同步重点队列状态（客户、截止日期、进度、风险… 5.书面回执提出人：结论、预计时间、理由；正式提报不…；7.每周同步重点队列状态（客户、截止日期、进度、风险…
X-PRD-11 客户定制需求评估、标品化判断与报价估算 1.填写定制需求评估单（客户、场景、需求清单、优先级…；5.输出产研三项：预期需求范围、预期人日与成本价、兜…；7.立项后排期；需求单标注适用范围（标准/渠道/客户… 2.澄清：发需求澄清问卷，明确资料格式；资料不全或不…；4.范围与人日评估：常规由研发负责人；大项目由 CT…；7.立项后排期；需求单标注适用范围（标准/渠道/客户…；8.会后整理可发给客户的需求清单版本，请客户确认
X-PRD-12 跨产品线/版本线能力同步与适配决策 4.信创跟版：默认晚一个版本；主线正式发布且关键特性…；5.测试排期：构建完成自动通知测试负责人；人力不足时…；7.更新同步台账并在产研群通知 1.主线打 tag 或正式发布时自动生成能力变更清单…；4.信创跟版：默认晚一个版本；主线正式发布且关键特性…
X-PRD-13 PRD 撰写与需求评审 2.按模板撰写 PRD（背景、场景、功能清单、业务规…；5.评审会：会前 1 个工作日发文档；会上宣讲，逐条…；6.评审结论写入 PRD 固定章节；参评人在文档点“…；8.业务讨论会结论：会后整理“结论 + 待确认项 +… 3.AI Review：检查规则冲突、状态机缺失、术…；5.评审会：会前 1 个工作日发文档；会上宣讲，逐条…；7.拆 issue，关联 PRD 链接；设计以 is…；8.业务讨论会结论：会后整理“结论 + 待确认项 +…
X-PRD-14 业务规则与统计口径定义 4.写入词典：编号、定义、公式、取值区间（如统一左闭…；5.机器人通知研发、测试、运营；需求模板引用词典编号；8.上线公告写明口径变化，回填词典生效日期 5.机器人通知研发、测试、运营；需求模板引用词典编号；8.上线公告写明口径变化，回填词典生效日期
X-PRD-15 产品命名、术语与用户可见文案规范 1.提交命名/文案需求（对象、面向、候选、截止日期）；4.登记术语表：中文名、英文名、内部名、代码字段、定…；5.发布通知并生成改名影响清单（界面、仓库、域名、文… 2.生成候选并检索：重名、商标、域名、禁用词、竞品相…；7.维护错误码—文案对照表、短信与弹窗模板；缺陷单要…；8.发版前扫描 UI 字符串中的禁用词和内部名；开放…
X-PRD-16 UI/UX 设计需求、评审与设计走查 1.提交设计需求单（页面、场景、优先级、截止、参考、…；4.高保真稿交付：标注尺寸、切图、空/错误/加载状态…；6.提供走查环境：nightly 包或测试环境地址，…；9.规范与素材归档：色卡、组件、图标、Logo、卡片… 2.设计排期；设计资源不足时，用 AI 原型工具按规…；6.提供走查环境：nightly 包或测试环境地址，…；7.设计走查：按清单比对（间距、色值、图标、字重、状…
X-PRD-17 风险功能准入与合规需求评估 1.登记风险/合规需求，附原始材料，禁止只在群里转述；5.召开 30 分钟准入评审或线上审批，出结论：准入…；7.上线前复核：对照评估单逐项检查提示、开关、协议链… 3.给出至少 2 种技术路径（如 exec 黑白名单…；6.落地：统一风险提示组件、功能开关、协议版本号与生…
X-PRD-18 模型选型、档位配置与评测 1.提出候选模型或调整需求，建 LEAP 工单，写明…；7.更新档位方案一页纸，在产研群和销售群发变更通知卡… 3.跑评测集（private 题库为主），组织不少于…；4.输出评测报告：效果、速度、稳定性、成本、合规，给…；6.测试环境复制配置并验证（含思考开关、内部模型不可…；8.上线后 3 天观察报错率与用户反馈，异常则回退并…
X-PRD-19 第三方能力与外部方案调研选型接入 1.提交接入需求，写明场景、用量、付费方；6.选型评审：定厂商、接口范围（砍掉过贵或面议接口）…；7.采购签约、企业认证、充值；凭据存入密钥管理，不发…；8.接入开发：专用端点、每个 endpoint 设计… 3.调研 2～4 个方案，填选型对比表（价格、限额、…；5.成本与定价评估：单价、预计月成本、倍率建议；合规…；8.接入开发：专用端点、每个 endpoint 设计…
X-PRD-20 Skill 上架审核、开发者入驻与分润 1.提交入驻申请（主体、联系人、结算方式）；2.资质审核，签署开发者协议 4.自动预检：格式是否标准、包大小、脚本安全扫描、敏…；6.上架：配置分类、价格、计费 ID，安装抽检；7.计量与分润：网关记录付费调用，按月出调用量和分润…
X-PRD-21 内置技能评估与技能商店内容维护 1.提交 Skill 评审申请，附自测结果和商店信息；4.需研发配合的（内置、下发配置）建工单并排入迭代；5.上架或内置：按台账信息填写名称、描述、分类、版本…；7.商店内容维护：汇总反馈，修正描述、分类、版本，每…；8.下发接口契约变更：在单一契约文档更新字段，指定定… 2.格式与安全审查：builtin 格式、脚本扫描、…；5.上架或内置：按台账信息填写名称、描述、分类、版本…；8.下发接口契约变更：在单一契约文档更新字段，指定定…
X-PRD-22 模型/API 售价、倍率调整与对外价格表… 2.更新价格主表的成本价与生效时间；4.定价审批：成本、建议倍率/售价、生效日期、对账影…；7.同步对外价格表与模型清单（自动生成倍率后价、上下…；8.发变更通知卡片给销售、客服、财务；说明生效时间和… 1.识别价格变动：渠道调价、折扣、汇率（每月第 1 …；3.测算：按统一口径算毛利和建议售价（区分倍率与毛利…；5.提价格 PR：网关价格、预扣费、最小计费单位；同…；7.同步对外价格表与模型清单（自动生成倍率后价、上下…
X-PRD-23 产品套餐、积分/额度定价与计费规则 1.立项：写明产品、计费对象、上线日期、需定的数值清…；5.出计费口径单：统一术语与单位（如 m=百万），写… 2.成本测算：按真实场景各档跑 10 次以上，算平均…；3.拟方案：用人民币定价、积分/词元做运营单位；给出…；6.开发实现：PR 必须引用口径单版本；先合测试环境；7.口径对账：用一次真实任务核对扣量；测极端值；检查…；8.发布用户可见的计费说明；上线后 7 天监控日消耗…
X-PRD-24 硬件产品配置选型、成本评估与供应商问题反… 1.登记触发事项（新报价/配置变更/规格咨询/硬件缺…；3.评审会或线上评审：成本、性能、认证、对软件影响；5.更新标准配置表与席位 SKU 表（版本号、有效期…；6.发布对外口径（只写售价不写成本），旧版文档标“已…；8.硬件缺陷：复现、确认固件版本、反馈工厂、每周跟进… 7.报价有效期到期前 5 个工作日提醒，重新询价并复…
X-PRD-25 AI 报告提示词与报告类型配置变更 1.在提示词多维表格登记变更（类型字段、正文、版本号…；3.审核通过后自动通知研发；脚本校验格式并检查各类型…；7.不通过的问题记入缺陷表，写明整改方式、负责人、复…；8.通过后随版本上线，记录状态改为“已上线”，旧版本… 3.审核通过后自动通知研发；脚本校验格式并检查各类型…；5.用验收样例在测试环境生成，检查目录是否完整、有无…
X-PRD-26 行业案例、测试数据与知识库素材获取 1.填数据需求单：用途、类型、数量、来源、截止日、验…；5.范围变化一律在需求文档评论区确认，不只靠微信或口…；7.增量写入 test 库（新增数据不删除原有数据）…；9.更新素材台账：来源、范围、数量、覆盖率、授权情况 2.查测试库和生产库的案例分布，输出缺口清单；6.脱敏、清洗、格式转换、打标签；7.增量写入 test 库（新增数据不删除原有数据）…
X-PRD-27 迭代规划、故事拆分与排期 1.机器人提醒产品提交下迭代需求；产品把需求录入工作…；4.召开迭代计划会（产品、研发、测试参加；缺席者看纪…；5.建 milestone，issue 挂到 mil…；6.成员把任务按天拆进迭代任务视图，写明每日目标；8.迭代末把未完成项自动迁移到下迭代，状态标“顺延”… 2.拆 issue/故事卡并估点；需求里的隐含工作量…；7.机器人每日检查未填任务的人并点名提醒；8.迭代末把未完成项自动迁移到下迭代，状态标“顺延”…
X-PRD-28 开发中需求澄清与产品拍板 7.结论回写工单，写入决策记录表；涉及命名、权限、规… 2.机器人按模块自动 @ 对应产品经理；群里只转发工…；3.先查术语表、决策记录表有无现成结论，有就直接引用；7.结论回写工单，写入决策记录表；涉及命名、权限、规…；8.机器人把结论推送给工单相关研发和测试；测试据此更…
X-PRD-29 需求变更控制 1.填需求变更单（多维表格或提报表单），自动生成草稿…；4.大会或发布冻结期内的变更，另需冻结期审批人在变更…；5.更新需求文档、原型、工单描述，标注变更版本；被砍…；7.调整排期，更新测试点和回归范围 6.机器人推送变更摘要给相关研发、测试和群（流程性决…
X-PRD-30 迭代站会、进度追踪与交付节点管理 1.用飞书日程循环事件固定站会时间和会议室，召集人写…；4.站会决议（延期、换人、顺延）写入迭代文档或工作台；5.维护里程碑台账：客户新增或变更时更新版本、模块、…；7.节点前 2 个工作日检查完成度，低于 80% 的…；9.迭代末开回顾会（做得好/问题/改进），改进项进待… 2.站会前更新 issue 和任务状态，机器人提醒未…；4.站会决议（延期、换人、顺延）写入迭代文档或工作台；6.机器人每日汇总各项目进度和未完成项，推送到群并 …
X-PRD-31 产品验收 1.建单时指定“验收人/验收方式”（产品验收/技术联…；2.研发自测后部署到验收环境，附录屏和地址，把状态改…；5.通过：在工单评论写“产品验收通过 + 日期”，验…；8.迭代末清点需求池状态，列出未验收、验收未通过项；9.发版前组织内测验收，输出变更清单和已知问题清单，… 3.机器人 @ 验收人，每日 10:00 推送“待产…；5.通过：在工单评论写“产品验收通过 + 日期”，验…；9.发版前组织内测验收，输出变更清单和已知问题清单，…
X-PRD-32 AI 生成质量评测与领域专家验收 1.写评测单：目标、对比版本、样本、标准（自定标准或…；3.隐去版本来源，编号后分发给评审人；7.整改项进缺陷单，写明负责人、截止日、复测人；业务…；9.样本、评分表、结论归档到评测样本库，供下次复用 2.生成各版本样稿（如参考案例仿写版、套模板版、先审…；3.隐去版本来源，编号后分发给评审人；5.AI 解析客户修订痕迹，生成问题清单，作为对照
X-PRD-33 产品改版数据迁移与版本切换 1.在迁移登记表新建迁移批次，填写范围、影响面、计划…；7.发布迁移窗口通知（优先周末或低峰），同步客服；8.生产迁移：备份→灰度（先内部或少量客户）→全量→…；10.确认无异常后下线旧逻辑与临时同步开关，归档方案与… 3.编写迁移脚本、迁移前后数量对账脚本与回滚脚本；5.测试环境演练：先备份→跑迁移→对账→抽检；不通过…；8.生产迁移：备份→灰度（先内部或少量客户）→全量→…；9.迁移后 7 天每日对账/巡检报表，异常按第 6 …
X-PRD-34 功能分批上线、入口隐藏与提审模式 1.按依赖检查表逐项核对本版本功能依赖；3.在功能开关清单登记（功能、方式、原因、放开条件、…；6.小程序提审：开启审核模式，隐藏登录、客服、余额、…；9.通知市场销售与客服：哪些功能已开放 6.小程序提审：开启审核模式，隐藏登录、客服、余额、…；10.功能稳定后 1 个迭代内删除临时开关代码，清单状…
X-PRD-35 产品发版/内测公告与通知分发 1.发布就绪检查：产品、客服、额度、文档、下载链接；3.发版计划确定后机器人提醒各线准备公告；6.按渠道表分发（全员群/市场群/销售群/公众号/俱…；7.更新统一下载页，登记内测客户当前版本；8.下线过期公告，收集反馈并转 RND-01 3.发版计划确定后机器人提醒各线准备公告；4.按模板起草对内/对外公告，AI 初稿后人工改写；7.更新统一下载页，登记内测客户当前版本
X-PRD-36 产品手册与使用说明维护 1.发版检查单中“手册更新”项触发文档更新任务；7.通知销售、客服与渠道：最新链接与主要变化；10.每月巡检一次手册与线上版本是否一致 3.用 AI 根据需求/PRD/更新日志生成手册更新…；6.同步到帮助中心、手册站点、产品使用网站（从唯一来…；8.手册内容同步给产品内置客服/Agent 作为知识…
X-PRD-37 小产品/实验产品快速内测与发布 1.填写一页立项单，由决策人确认目的与优先级；5.上线前检查：清理测试数据、备案号、隐私说明、内容…；6.发内测邀请（含重点检查项与反馈表单链接），反馈只…；7.反馈汇总、去重、筛选，形成排期表；采纳的反馈按规…；10.对外宣发并持续迭代，迭代版本在群内同步 3.研发部署测试链接；7.反馈汇总、去重、筛选，形成排期表；采纳的反馈按规…
X-PRD-38 内部业务系统建设归口与数据主责边界 1.新系统/新模块需求统一提交到内部系统需求池，不在…；7.更新数据主责矩阵与系统职责边界说明并公告；9.旧系统对应功能停写并通知使用人 2.查重：对照现有系统功能与矩阵，标出重复或冲突项；8.功能迁移按“先同步、再校验、后停写”执行；同步脚…
X-PRD-39 产品使用数据统计与导出 1.用取数申请表提交需求（口径、范围、用途、截止时间…；5.交付统计文件，注明口径和数据截止时间；7.同类需求第 2 次出现，排期做后台导出按钮或定时… 3.无报表时编写导出脚本，排除测试/内部账号后导出；4.脚本提交到仓库并登记在取数申请中，便于复用；7.同类需求第 2 次出现，排期做后台导出按钮或定时…
X-PRD-40 产品/研发岗位工作交接 1.确认交接范围、接手人、交接截止日，在群内公告“谁…；3.打包仓库、题库、素材、链接、账号位置，转移文件与…；5.需求池、工单、反馈群值班的负责人字段改为接手人；8.三方确认交接完成；交出人保留 2 周答疑；9.更新职责分工表与“办事找谁”文档；区分对外公开版… 2.按交接清单模板写交接文档，可用 AI 根据群聊/…
X-PRD-41 私有化版本支持策略与旧版本停止维护 4.停止维护前 90 天通知客户与渠道；6.到期后旧版本只做安全修复或不再修复 1.统计在网版本分布
X-PRD-42 产品/功能下线（EOL）与停服通知 5.对内同步销售/市场/客服，对外公告（建议提前 3… 2.影响评估（用户、收入、合同、数据、依赖）；7.协助迁移、处理退款
X-DLV-01 一体机硬件配置咨询、配置单与报价 1.按第 3 节字段提交配置需求；2.按“人数—内存—硬盘—机型”映射套标品（标品/标…；4.向合作供应商询价，记录报价、有效期和对公/个人价；6.审核配置，生成带版本号的配置单发给销售；7.签约前做“报价单—合同附件—采购 BOM”三方核…；8.配置单、成本单挂到客户/订单；标品变化或软件发版… 2.按“人数—内存—硬盘—机型”映射套标品（标品/标…；8.配置单、成本单挂到客户/订单；标品变化或软件发版…
X-DLV-02 硬件供应商选型、BOM 与采购补货 1.库存低于安全线或预测缺口时发起补货需求；新机型由…；2.选型并出 BOM（按人数分档，对公价/个人价双列…；3.向至少 3 家供应商询价，登记报价、MOQ、交期…；5.采购评审：方案取舍（现货/自组装/ODM/开模）…；6.签约下单，提交付款申请，财务核对发票后打款；7.跟踪排产与物流，每周一更新预计到货日；延期当天同…；8.到货验收（配置核对、3C 标识、外观、压测）、贴… 1.库存低于安全线或预测缺口时发起补货需求；新机型由…；3.向至少 3 家供应商询价，登记报价、MOQ、交期…；7.跟踪排产与物流，每周一更新预计到货日；延期当天同…
X-DLV-03 硬件库存与资产台账维护 1.到货验收后登记入库：序列号、机型、配置、来源、采…；2.采购下单后登记在途：数量、预计到货日；延期时更新；3.设备分配到订单时填订单号，状态改为“预留/部署中…；4.出库/发货/上门交付登记：日期、去向、运输方式、…；6.回收入库：确认数据已备份/清除、外观与配件完整后…；7.每周五盘点抽检，更新看板（存货/在产/即将交付/… 3.设备分配到订单时填订单号，状态改为“预留/部署中…；7.每周五盘点抽检，更新看板（存货/在产/即将交付/…
X-DLV-04 出货排期、机器调配与延期通知 1.每周一召开排期会：更新在库、在途、预计到货与本周…；2.新订单提交后评估是否有货，回复预计交付日；不提单…；3.按优先级分配机器：全款 > 定金 > 已签未付 …；4.销售预定/留机：提交预留申请，写明客户、合同状态…；6.发货前核对：收款状态、席位数与订单一致、压测通过…；8.通知：机器人在订单群和销售群发布延期/变更（原因… 2.新订单提交后评估是否有货，回复预计交付日；不提单…；4.销售预定/留机：提交预留申请，写明客户、合同状态…；8.通知：机器人在订单群和销售群发布延期/变更（原因…
X-DLV-05 样机/演示机借用与演示环境管理 1.按第 3 节信息提交借用审批；远程试用只填账号申…；3.确认库存可借，不占用已预留交付机；4.配置演示环境：统一“豪华演示版”（演示专用模型/…；5.出库交接：清点机器、配件、随身 WiFi，借用人… 4.配置演示环境：统一“豪华演示版”（演示专用模型/…；6.到期前提醒；需续借重新走审批
X-DLV-06 展会与大型活动现场设备保障 1.登记活动需求（第 3 节字段）；2.按人数换算配置与公网容量，按峰值人数加冗余（参考…；6.按清单打包，约定集合时间与运输方式；8.回收设备、回报交付/回收清单，写 5 行复盘 4.硬件就位并联调、压测
X-DLV-07 交付订单受理、建群与派工 1.在交付订单表单提交（第 3 节字段必填并校验）；…；4.结合库存（X-DLV-04）回复预计交付日并写回…；5.派工：备机→部署→实例 ID→充值→开放平台注册…；6.硬件组装完成、软件部署并跑自动化测试、充值完成，…；8.上传验收单，订单表同步金额，关闭订单；交付后转运… 2.机器人发“新订单”卡片，自动建群（群名【Leap…；4.结合库存（X-DLV-04）回复预计交付日并写回…；6.硬件组装完成、软件部署并跑自动化测试、充值完成，…；9.每日对账“订单表 vs 已建群/已转发卡片”，处…
X-DLV-08 交付项目台账与立项留痕 1.填写“项目开发申请”表单；同一项目不重复提交，后…；2.商务确认：确认报价/合同状态；未签合同不得开工，…；4.方案/报价材料审批（可加签）；5.需要 Demo/试用服务器时提交部署申请，运维部…；6.每周登记工时、更新状态与里程碑；POC/无合同工…；7.客户会议、方案、报价、案例按项目名归档 6.每周登记工时、更新状态与里程碑；POC/无合同工…
X-DLV-09 交付项目启动会与客户资料收集 1.在交付群发“签约生效”通知，附合同交付条款摘要；2.按合同开票节点提交开票申请；4.向客户发启动会邀请与《客户资料清单》，约定资料交…；7.资料签收登记；到期前 1 天自动提醒；逾期由客户… 4.向客户发启动会邀请与《客户资料清单》，约定资料交…；6.发启动会纪要，待办转飞书任务指派到唯一负责人，抄…
X-DLV-10 客户定制需求承接、拆解与排期 1.登记需求：客户、来源、合同条款号、期望日期、对客…；7.每周推送进度到对客窗口与交付群；预计延期提前 2…；8.工单完成后验收（测试 + 业务），通知对客窗口回… 2.核对合同范围；合同外需求转 SAL-25 / S…；6.拆单：每项一个工单，绑迭代/milestone，…；7.每周推送进度到对客窗口与交付群；预计延期提前 2…
X-DLV-11 行业版与白牌定制交付 1.订单评审时在交付表勾选定制项，自动 @ 开放平台…；4.开放平台注册企业，配置 Logo/名称/提示词/…；6.行业版：镜像内置行业 Skill，LeapUpd…；9.归档企业定制配置（企业 ID、配置项、包版本、帮… 5.管理后台定制走 hotfix（基于生产基线，不得…；6.行业版：镜像内置行业 Skill，LeapUpd…；7.测试服按定制检查清单验证（安装包图标、快捷方式、…
X-DLV-12 批量装机镜像（ISO/OOBE）制作与发… 1.确定出厂规格：型号 × 盘位 × 文件系统 × …；7.逐台登记规格与镜像版本 3.制作 ISO/OOBE 镜像（分区方案、自动部署…；4.镜像验收：部署路径（交付工程师）、服务功能（测试…；6.批量烧录出厂（机器 key 仅可获取一次，重置视…
X-DLV-13 一体机出厂装机、预装与测试验收 1.收齐订单交付信息，写入交付单；缺项退回客户经理；4.交付单状态改“系统就绪”，自动通知部署人；6.转交注册与充值：按 X-DLV-14 提交指纹注…；8.出厂检查单逐项勾选（版本、席位、指纹、额度、网络…；9.发货（快递单号）或上门排期，同步客户经理；10.回写设备台账：机器—客户—版本—规格—执行人 2.到货/组装，来料检验（DMI UUID/SN 唯…；3.装系统与环境确认：系统版本、国内源、SSH、网卡…；5.部署 LeapCore：组织、管理员、席位、行业…；7.跑自动化测试（登录、加用户、企业/个人空间上传、…
X-DLV-14 设备指纹注册与平台登记 2.提交注册申请：机器名、用途、订单号/审批、指纹、…；3.平台注册：建组织（每组织仅一台主控）、注册机器、…；4.网关登记指纹并按审批档位配额度；5.开放平台登记组织 ID 并备注用途（生产客户/测…；7.回写台账：指纹—机器—组织 ID—实例 ID—客… 1.来料采集指纹并校验唯一性；重复则由厂商刷写或我方…；6.机器端验证：首次启动用指纹换取 Key 成功、S…
X-DLV-15 客户组织、账号开通与额度充值 1.提交开通申请：订单号或用途类型、组织、席位、人均…；2.额度审批：标准档位内自动通过；超档、无订单、无限…；3.建组织与管理员；初始密码随机生成，经私密渠道发给…；5.配置人均额度、容量上限、灰度与功能开关（配置化，…；8.通知客户经理先验看，再由客户经理交付客户；非阻塞…；9.回写台账（组织、席位、额度、充值人、时间），同步… 4.名单批量导入（模板校验手机号，错误行退回，不单独…；6.按审批金额充值；先清理测试残留余额；完成后自动回…；7.冒烟：管理员登录、成员登录、额度显示、上传与跳转
X-DLV-16 客户网络与远程接入配置 1.发《客户环境要求清单》并取得客户 IT 回填；5.如需 LeapVPN：创建企业实例、登记主节点指…；6.登记接入台账：客户、机器、配置类型、端口、配置负…；7.远程访问：审批通过后自动 @ 台账中的配置负责人…；9.用后关闭访问，在审批群回复“已关闭”，台账更新 3.从分配表取端口/网段，按客户生成独立配置（客户机…；4.部署并校验：握手、连通性、OTA 可达、跨客户不…；7.远程访问：审批通过后自动 @ 台账中的配置负责人…；8.客户侧网络问题：研发判断根因 → 起草话术 → …
X-DLV-17 客户自备/第三方设备部署准入评估 1.收到非自有设备部署需求，发起准入评估并附客户填写…；2.对照最低配置逐项核对（内存、CPU 架构、系统、…；5.出具结论：通过 / 有条件通过（客户整改或换机）…；8.准入单挂到部署工单；部署完成后补记实际环境与问题 —
X-DLV-18 部署方式决策与现场部署前预检 1.签约后在交付订单表登记，自动生成《交付前检查单》…；3.按决策表定交付方式：默认在公司装好调试后寄送/送…；6.编写现场预案：到场人员与分工、携带物料、断网/断…；8.检查单链接挂到交付工单，转入 X-DLV-19 … 4.网络/机房预检：内网互通、带宽实测（iperf3…；5.在 staging（与客户一致的版本、认证、存储…
X-DLV-19 客户现场/远程部署实施与上门安排 1.确认本周待部署订单，指定唯一执行人与备岗，写入外…；2.约客户时间，确认地址、门禁、客户 IT 与管理员…；4.核对携带物料与出发安排，服务器等大件货运直送门口；5.现场/远程部署：上架接电，配置 IP/端口/DN…；6.开通管理员账号、导入用户、分发安装包与访问地址；…；9.客户签验收单或回执照片，工单状态改"已交付"；10.复盘：问题进研发工单、需求进需求池；部署 SOP… 3.在公司按《软件部署手册》装机或更新版本：环境确认…；10.复盘：问题进研发工单、需求进需求池；部署 SOP…
X-DLV-20 集群版交付部署 1.到货或扩容需求登记交付工单，指定部署主责与客户对…；2.向客户发送操作说明：只需上电、接网；确认 IP …；6.Update 平台设置节点角色并关联 maste…；8.打包发货或现场接入；交付后更新部署记录并通知客户 3.在 v5 云端为交付人员配置机器身份与 IP，采…；4.主机部署并走 OOBE：交换 apikey → …；5.从机预部署：deploy skill 指定 su…；7.跑两轮验收脚本，全部 PASS 才发货/交付；兜…
X-DLV-21 客户模型/API 能力接入与本地 New… 1.收集客户需求（模型、人数、搜索、算力来源），填写…；3.制定分批上线计划并拆成飞书任务（渠道接入、渠道添…；4.上游渠道接入，总 NewAPI 添加渠道与价格 6.按接口类型（chat/images/messag…；7.生成调用示例与接入文档（AI 起草、人工校对），…；9.总 NewAPI 调价/上新/峰谷调整后，脚本比…
X-DLV-22 OpenClaw/龙虾批量装机与上门部署 1.与客户确认需求清单与部署前提，签免责声明；3.从统一制品库取带版本号的安装包、Skill 包、…；6.逐台跑测试用例 1～3，序列号、版本、结果写入台…；9.客户新需求登记 CRM，不当场承诺；问题回流工单… 5.批量：PE 写盘克隆或脚本批量安装，按参数表为每…；6.逐台跑测试用例 1～3，序列号、版本、结果写入台…
X-DLV-23 离线/私有化部署包准备与预演 1.提出离线/私有化需求并填写可行性问卷；3.申请同款测试环境（配置、系统、架构）并开通；8.对照放行清单逐项勾选，签字后方可带包出发，转 X… 4.梳理依赖与配置：构建依赖全部本地化，IP/端口/…；5.按目标架构打包镜像/模型/rpm/一键部署脚本，…；6.计算 md5 上传内网 NAS；在同款纯离线环境…；7.编写测试文档与用户手册（AI 起草初稿），含回滚…
X-DLV-24 离线/私有化项目现场部署实施 1.建交付任务单，约客户时间窗，确认入场手续；7.遗留问题登记反馈表并分派，远程结对排查；修复合并… 4.首次部署执行一键脚本；升级按"停止→删除旧容器→…；5.逐项跑测试用例并记录；本地模型做推理压测与重启测…；8.把现场问题与命令补进部署文档；大版本升级提前告知…
X-DLV-25 信创/国产算力适配与厂商协同 1.在"信创适配需求表"登记需求，自动通知信创负责人；2.查适配矩阵：已有结论直接按口径答复；无结论进入适…；3.确定适配版本、负责人、DDL，写入适配计划（跨版…；6.按测试模板实测并出报告，判定是否存在 P1 缺陷；7.平台/驱动/厂商系统问题登记"厂商问题跟踪表"，…；9.更新适配矩阵结论（可用/有条件可用/不可用 + … 2.查适配矩阵：已有结论直接按口径答复；无结论进入适…；5.按 RND-63（信创适配开发、打包与验收）的打…；6.按测试模板实测并出报告，判定是否存在 P1 缺陷；9.更新适配矩阵结论（可用/有条件可用/不可用 + …
X-DLV-26 客户现场准入材料准备 1.向客户索取完整准入要求，登记到项目准入清单；3.用飞书私密表单收集人员身份证、电子签等材料，仅交…；7.安排客户考试/登记，结果更新到准入名单；8.进场后，个人敏感材料按客户要求留存或销毁，准入材… 4.生成组件与依赖清单（SBOM）及版本
X-DLV-27 客户 POC/演示环境搭建与交付 1.在 POC 看板登记：客户、截止日、预算、环境限…；4.搭建环境（域名、端口、账号、模型 API）、开发…；5.按"需求—功能—证据"对表检查，冒烟测试，开演示…；7.生成 POC 测试报告初稿并人工审核；9.客户反馈逐条建任务，修改后重复步骤 5～8；PO… 6.录屏、写使用文档；演示场景内部彩排，不稳定功能不…；7.生成 POC 测试报告初稿并人工审核
X-DLV-28 客户培训与使用手册准备 1.验收通过后与客户确认培训日期、对象、人数、形式，…；4.编写分角色手册（飞书文档），AI 根据 PRD/…；8.发放反馈问卷，问题转工单，手册与 FAQ 更新 4.编写分角色手册（飞书文档），AI 根据 PRD/…；6.用客户实际设备/staging 环境跑通全流程，…
X-DLV-29 交付签收单、验收单与开票跟进 1.从交付知识库取模板，客户全称从合同自动带入，生成…；2.打印单据随货寄出，物流单号录入交付订单表；6.上传扫描件到渠道系统订单（支持 PDF/Word…；8.纸质原件交档案管理归档，交付订单表状态改为"已验… 1.从交付知识库取模板，客户全称从合同自动带入，生成…；6.上传扫描件到渠道系统订单（支持 PDF/Word…
X-DLV-30 交付服务承诺口径（保修、运维边界、客户须… 1.汇总待决问题清单（保修、运维主体、磁盘管理开放、…；2.整理厂商保修信息表，对齐对外保修时长；3.召开决策会，逐条定结论与负责人，会议纪要用妙记生…；6.发布口径一页纸，同步销售/渠道/售后；更新合同模… 3.召开决策会，逐条定结论与负责人，会议纪要用妙记生…；4.研发列软件侧注意事项，客户经理汇总成《客户使用须…
X-DLV-31 已交付设备与客户信息登记归档 1.成单后在交付订单表建记录（"卖一台建一条"），客…；2.部署完成后登记设备：指纹、序列号、版本、渠道、I…；3.行业版：提交开放平台登记，确认 Skill 自动…；6.上传验收单附件，项目材料放云盘标准目录；8.离线超过 7 天的客户设备推送给客户经理跟进原因 1.成单后在交付订单表建记录（"卖一台建一条"），客…；3.行业版：提交开放平台登记，确认 Skill 自动…；4.机器注册名统一为合同公司全称，计费侧校验一致；7.每周自动比对台账与后台在线实例，标出未登记、字段…；8.离线超过 7 天的客户设备推送给客户经理跟进原因
X-DLV-32 已交付/演示机版本升级与回退 1.列出本次升级机器与优先级（次日交付/演示 > 客…；2.通知现场将交付/演示机通电联网，保持至验证完成；4.先推 1 台金丝雀机器，验证通过再批量推送；6.失败或部分升级的机器立即回退上一稳定镜像，交付/…；8.更新升级状态表：版本、结果、离线/需补配置/需远… 2.通知现场将交付/演示机通电联网，保持至验证完成；3.运行预检：在线、磁盘、依赖、新增环境变量/配置是…；5.探测各机器升级结果与核心业务可用性；6.失败或部分升级的机器立即回退上一稳定镜像，交付/…
X-DLV-33 已交付客户扩容与加席位变更 1.收到客户诉求，按准备清单提交席位变更申请；2.核对合同席位、席位台账与系统实际值，标出差异；5.收费的补签补充合同/订单，确认回款节点；6.执行变更：远程改席位；硬件扩容安排返厂；8.更新席位台账（原值、新值、硬件规格、费用、审批号… 2.核对合同席位、席位台账与系统实际值，标出差异；3.查型号×内存的席位上限表判定可行性；硬件改动按政…；6.执行变更：远程改席位；硬件扩容安排返厂
X-DLV-34 交付期现场问题反馈与故障闭环 1.所有反馈统一登记；电话/微信来的由首接人代填；5.需改代码的：修复→封包（版本号、变更清单、介质格…；8.记录根因，按 X-DLV-36 补进部署 SOP… 3.跑健康检查脚本（模型/embedding/解析服…；5.需改代码的：修复→封包（版本号、变更清单、介质格…；7.回复客户：能做的给排期；大改动明确本期不做；合同…
X-DLV-35 交付进度跟踪与卡点盘点 1.订单入台账，按合同交付日倒排各环节截止；2.硬件采购/装机完成，改状态“硬件就绪”，自动通知…；3.软件部署与网络配置完成，改状态并自动给测试人派测…；5.宣布“软硬件就绪”，通知充值；充值完成后群内确认；8.每周一盘点全部未完成订单，列卡点与待决策事项并 … 2.硬件采购/装机完成，改状态“硬件就绪”，自动通知…；3.软件部署与网络配置完成，改状态并自动给测试人派测…；4.跑自动化测试脚本，测试报告发订单群；7.每个工作日 10:00 推送逾期及 24 小时内…；9.定制项目每周五发周简报（本周安排、进展、问题）到…
X-DLV-36 部署 SOP 与交付文档沉淀 1.部署中/交付后把遗漏点与新经验登记到“SOP 变…；6.修订后发布到固定 wiki 空间，更新版本号与变…；7.归档交付记录（时间、客户、内容、环境、问题、兜底…；8.月度检查变更池清零情况，过期文档标“已废弃”并指… 3.先出框架 SOP（拿到机器→测系统→装镜像→测镜…；7.归档交付记录（时间、客户、内容、环境、问题、兜底…
X-DLV-37 交付负责人 AB 角与项目交接 1.为每种交付形态和每个在做项目登记唯一负责人与 ≥…；3.A 角请假/变动提前报备，交付统筹确认期间由 B…；6.在项目群/客户群公告新负责人与生效日期，更新台账… 4.需正式交接时，原负责人按清单填交接包；AI 汇总…
X-DLV-38 星域俱乐部商户入驻、开通与数据迁移 1.意向确认后在入驻台账建条目，发材料清单；3.签署合同，人工审核条款与资金账户；4.开户与管理员账号开通，超管勾选接待等权限；5.按开通清单配置模块开关（club config …；9.上线冒烟（模块可见、昵称审核、红点、会员商品），… 6.有旧系统数据的做迁移评估（唯一标识、余额处理、历…；7.隔离环境试迁 → 停旧系统 → 正式迁移 → 余…；9.上线冒烟（模块可见、昵称审核、红点、会员商品），…
X-DLV-39 外部数据集交付（构建验证、质检与外发保密… 6.外发审批：核对包内无未授权内部代码、凭据、第三方…；7.打包（清单、版本号、校验值），加密传输并通知客户 4.构建验证：x86/arm 双架构构建、判分脚本运…；5.反作弊测试：检查可绕过判分的路径（如忽略失败开关…；7.打包（清单、版本号、校验值），加密传输并通知客户
X-DLV-40 项目结项、交付转售后移交与复盘 2.归档合同、方案、部署记录、手册、验收单；4.售后签收移交清单，录入定制配置台账（X-CS-1…；7.交付群改为售后服务群或解散，更新项目台账为已结项 5.汇总工时与采购成本，算项目毛利
X-DLV-41 一体机发运包装、物流保价与到货异常处理 1.按配件清单出库核对并登记序列号；4.按设备价值足额保价下单；6.提醒客户当面开箱验货、异常拒收或拍照；7.客户确认到货完好，更新台账为已送达 5.运单号同步交付群与销售
X-DLV-42 客户现场作业规范（变更确认、操作留痕、备… 1.编写变更单（步骤、影响、回退方案）；2.审核变更单；8.客户确认结果，记录归档到客户档案 4.备份配置、数据与当前版本；6.按检查项验证（登录、模型、网盘、计费等）
X-FDE-01 非标客户项目报备与技术留痕 1.识别为非标需求，填写「项目开发申请」（客户、需求…；4.方案、报价、案例、审查报告、交付文档定稿后通过「…；6.研发/FDE 按项目编号登记工时；7.更新项目状态（评估中/报价中/成交/搁置/关闭）；8.月度核对：项目清单对照合同、报价、工时，补漏并通… 2.机器人推送"新项目开发申请"卡片到核心项目群，@…；5.机器人推送"新增材料文档"卡片；8.月度核对：项目清单对照合同、报价、工时，补漏并通…
X-FDE-02 客户需求入口受理与分层分流 1.填写「需求受理表单」（群内许愿也需补填）；6.指定接单人，机器人向需求方回执接单人、预计时间、…；7.状态变化自动播报；交付后需求方验收并关闭 2.受理分类并分流：外部甲方许愿 → 许愿机项目组；…；6.指定接单人，机器人向需求方回执接单人、预计时间、…；7.状态变化自动播报；交付后需求方验收并关闭；8.月度统计各入口需求量、插队次数、关闭周期，供绩效…
X-FDE-03 客户需求澄清、可行性评估与技术答复 2.编写内部版需求摘要：目标、范围、不做项、需技术产…；6.涉及第三方账号、商家应用资质、外部 API：账号…；8.对外发送前提交商务审核，通过后发送，文档关联 X… 2.编写内部版需求摘要：目标、范围、不做项、需技术产…；5.做 Demo/录屏验证，标明"验证用，不代表生产…
X-FDE-04 定制项目技术方案、硬件选型报价与内部审核 1.定稿需求清单与部署参数（飞书版为唯一口径）；4.硬件选型：按"并发—模型规模—硬件 BOM"对照…；5.向 2～3 家固定硬件渠道/集成商询价比价，历史…；9.审核通过后与客户技术确认方案，出外部方案与报价，… 3.写方案初稿（需求、数据源、接入方式、风险、工时、…；7.AI 预审方案与报价（口径、风险条款、前后矛盾）…
X-FDE-05 FDE 人员派驻、调配与项目交接 1.提交派驻/借调/外包申请（项目、技能、人数、周期…；4.书面通知接收方负责人、被派驻人员及相关产品方，收…；5.外包/借调人员：签署合作/外派协议与保密协议（默…；8.移交人按交接清单交接背景、资料、待办、联系人；资…；9.协议签署后按最小权限开通代码仓库（外包用独立仓库…；10.外包/借调人员入场培训（保密、代码规范、协作方式…；11.派驻期间每周更新工时与负荷，外包每周进度对接与代… 6.外包研发：删减首期范围，产出接口文档或代码可见范…；11.派驻期间每周更新工时与负荷，外包每周进度对接与代…
X-FDE-06 客户模型接入与模型路由配置服务 2.发送信息表给客户填写并回收；8.写 handoff（路由表、代理位置、脚本、回滚… 3.适配评估：各档位（经济/标准/专家/生图/视频）…；4.降本场景：按使用场景出模型替换方案和成本节省说明；6.配置路由：优先配置文件/白名单；当前版本须加代理…
X-FDE-07 客户业务系统数据对接的授权与限流 6.最小化取数，只取代表性数据；每次取数登记时间、数… 6.最小化取数，只取代表性数据；每次取数登记时间、数…
X-FDE-08 定制 Skill 需求承接、评估定价与交… 1.填写 Skill 需求单（来源、客户、场景、样例…；5.确认合作或排期后指派承接人，建飞书任务 2.查重：在 Skill 市场/集市找类似 Skil…；6.按《LeapSkill 格式规范 1.0.0》提…
X-FDE-09 行业版 Skill/插件提交审核、开放平… 1.提交开发者/FDE 入驻申请，审核身份后开通账号…；4.在 FDE 操作台提交正式包与提交信息；7.发布：生成摘要与签名，设定可见范围（全局/行业/…；9.登记下发记录（包名、版本、客户、scope、日期… 2.按规范开发，运行 selfcheck 与 lin…；5.自动 lint＋Agent 初审，给出风险等级（…；9.登记下发记录（包名、版本、客户、scope、日期…
X-FDE-10 OpenClaw/龙虾/龙智一体机部署配… 1.提交订单并填写部署需求单；5.创建飞书机器人，把人设、职责、AppID 配入；…；8.老板版/定制版：召开需求沟通会，列优先级，记会议…；10.记录本次踩坑与配置差异，更新部署手册与踩坑库 4.按指定版本安装，锁定版本禁止自动升级；配置模型 …；5.创建飞书机器人，把人设、职责、AppID 配入；…；8.老板版/定制版：召开需求沟通会，列优先级，记会议…
X-FDE-11 客户试点开通、驻场陪跑与分层培训 1.建试点任务，指派驻场 FDE，客户经理约客户时间；2.发放调研表与问卷，收集各部门需求与原始材料；4.交付当天教对接人基础操作，并发视频教程；8.每周汇总试点反馈（问题、需求、使用度），转开发 2.发放调研表与问卷，收集各部门需求与原始材料；8.每周汇总试点反馈（问题、需求、使用度），转开发
X-FDE-12 FDE/开发者 LeapCore 调试环… 1.入驻审批通过后，申请人提交调试环境申请；5.按政策发放额度：真实开发首次赠送[金额已隐去]，…；6.发送开发指引：插件开发指南、DevKit、本地调…；7.登记台账（申请人、类型、实例、VPN、额度、开通… 3.审批通过自动生成实例创建工单；4.通过 v5 cloud 创建 LeapCore …；7.登记台账（申请人、类型、实例、VPN、额度、开通…；8.到期前 7 天提醒续期；无续期则回收实例与 VP…
X-FDE-13 内部 FDE 需求挖掘、开发与验收 1.通过统一表单提需求，附材料与流程图；4.指定负责人与排期，回写台账并通知提需人；8.部署 preview 域名，拉反馈群；业务白天反…；9.每日在群里同步：已完成/正在做/将要做，汇总到置… 2.追问背景，用 AI（grilling）结构化需求…；6.需求文档拆两块（需求描述＋技术约束），AI 拆工…；7.开发：Skill 先做 1～2 个送验收；系统先…；8.部署 preview 域名，拉反馈群；业务白天反…；9.每日在群里同步：已完成/正在做/将要做，汇总到置…；11.每周标出进度落后部门与逾期需求
X-FDE-14 内部 FDE 成果评测与阶段性案例收集 1.Skill 验收通过后自动进入评测队列；5.根据结论派优化项给部门 FDE；7.各部门每周提交：10 个功能点对比、3 好 3 … 4.结果写入评测表，AI 生成对比摘要；6.收敛 Skill：固定输出格式、示例写死、通用格…；8.自动统计各部门提交数量与缺口，按人推送提醒；AI…
X-FDE-15 内部 FDE 与 LeapCore 培训… 1.确定主题、对象与日期，批量发飞书日程（线下＋线上…；2.资料放入固定资料索引页；3.授课并开启妙记录制；记录参会名单；5.布置作业，定成果展示会日期；6.对缺课人员推送录像，必要时集中补课一次；8.整理 QA 与培训总结入 wiki，补充 AI … 3.授课并开启妙记录制；记录参会名单；4.发纪要、录像与资料链接到群；8.整理 QA 与培训总结入 wiki，补充 AI …
X-FDE-16 FDE 课程体系开发与评审 1.需求方填写课程需求单，对象与水平未填不启动；2.建项目看板：交付物、负责人（逐一 @ 到人）、截…；7.讲师修改后定稿入仓库，打版本号；讲稿与主持稿分工；9.课后收集问题与反馈，回流更新标准版 3.基于标准版出本期框架初稿（可 AI 辅助），发预…；9.课后收集问题与反馈，回流更新标准版
X-FDE-17 FDE 培训班筹备与开课保障 1.建专项群（技术、会务、交付、销售、生态各至少 1…；2.收报名表；AI 按职位+行业初筛；与销售确认筛选…；4.按行业分班，标注潜在客户，排销售助教并同步日历；…；9.初始凭据经一次性链接或单独渠道发放，首登强制改密…；12.会务出培训通知草稿，专项群征求意见 1 个工作日… 2.收报名表；AI 按职位+行业初筛；与销售确认筛选…；7.开放平台压测、沙盒、CLI 登录、测试环境/mo…；8.按开通模板批量导入账号：身份平铺（讲师=企业管理…；11.客户端安装包放局域网文件服务器并提前发给学员；课…；15.课后连续 3 天监控模型调用账单；回收/冻结额度…
X-FDE-18 培训现场问题与学员反馈收集 1.在培训排期表中指定出题人与定稿日，出题人确认接单；4.建现场支持群，公布反馈表单与 oncall 排班；5.现场问题登记：现象、影响人数、客户端版本、dia…；8.新问题当日提 bug 工单，关联问题记录；9.发放课后反馈表，回收学员与助教意见 3.课前环境验证：多人并发下载、远程访问组件、文件读…；10.汇总问题与反馈，AI 生成初稿，形成调研报告并评…
X-FDE-19 FDE 认证考试与结课发证 3.向学员公布认证规则：开放平台上传 Skill 且…；6.汇总两项成绩；边界分（Skill 65～75、答…；7.学员在开放平台留邮箱，核对名单与邮箱一致；11.成绩、名单、证书编号归档，统计通过率，题库更新 1.按模块抽题组卷（现行：20 题 × 5 分，80…；4.学员在开放平台上传 Skill，系统打分；5.现场答题，限时提交；9.按模板批量生成带编号证书，邮件发放
X-FDE-20 内部业务系统上线内测、业务验收与发布 3.部署预览环境；在多维表格登记环境地址与角色账号分…；4.发跑测通知：每个角色至少 1 名代表按岗位跑完整…；10.业务角色代表在验收记录上确认通过；手册同步更新到…；12.正式账号经飞书审批开通并配置身份；14.进入常态化反馈：反馈群消息机器人转工单，按版本回… 1.开发自测，补全 E2E；AI 按角色模拟操作，截…；5.Agent 测试 Bot 夜间跑 E2E，持测试…；10.业务角色代表在验收记录上确认通过；手册同步更新到…；13.推送"系统已升级"通知与更新说明；14.进入常态化反馈：反馈群消息机器人转工单，按版本回…
X-FDE-21 定制交付成果复用沉淀与知识产权归属确认 1.合同采用标准 IP 条款（通用能力归我方、客户专…；2.交付后盘点成果 4.去除客户数据、名称、专有规则，通用化
X-FDE-22 客户数据带离现场与开发使用审批 1.向客户取得书面授权（用途、范围、期限、是否可用第…；2.提交数据使用登记；3.审批，含个人信息或敏感数据的转法务；5.存放到指定受控位置，不存个人电脑和公共群 4.脱敏（姓名、证件、联系方式、金额、单位名称）；7.到期或项目结束销毁并登记
X-FDE-23 FDE 工时登记与项目成本核算 1.项目立项时建项目编码；2.按项目填报本周工时（半天为单位） 2.按项目填报本周工时（半天为单位）；4.汇总月度项目人天与成本；5.对比报价人天、合同收入，标出超支项目
X-RCT-01 招聘需求提报与 HC/预算/优先级管理 1.提交招聘需求单（新增/扩招/缓招/暂停/关闭）；2.查重：核对 HC 余量、同类在招岗位、可内部调剂…；4.写入 HC 台账，标注优先级和“急”，生成岗位编…；5.通知用人部门启动 JD（转 X-RCT-02），…；8.招满、暂停或取消时：台账改状态，下架岗位，告知在… 2.查重：核对 HC 余量、同类在招岗位、可内部调剂…；5.通知用人部门启动 JD（转 X-RCT-02），…；7.自动汇总 HC 余量、在招、已录用和缺口，推送管…
X-RCT-02 岗位 JD 编写评审与挂网上下架 3.定稿：补公司介绍、福利段、用工主体，编版本号，入…；4.在 BOSS、牛客等渠道挂岗，岗位名统一，薪资口…；5.同步《在招岗位清单》和官网招聘页；6.看效果：投递量、匹配率；不理想时出简版或另一版做…；7.暂停或下架：全部渠道同步，岗位库改状态 1.按模板起草 JD；能复用旧版的先复用再修改；5.同步《在招岗位清单》和官网招聘页；6.看效果：投递量、匹配率；不理想时出简版或另一版做…
X-RCT-03 招聘账号与签约主体管理 1.岗位需求获批时在台账写明签约主体；3.JD 首段和首次沟通话术写明签约主体全称；5.充值、VIP、道具：提交申请（主体、平台、金额、…；6.审批后付款并按主体记账；7.汇总各账号消耗、席位和效果 4.候选人跨主体查重：查同一人是否在其他主体面试过，…；7.汇总各账号消耗、席位和效果
X-RCT-04 招聘渠道拓展与招聘物料运营 1.按岗位统计渠道效果，找出量或质量不足的岗位；3.付费项目审批；6.发布、投放或张贴，投递入口统一指向简历归集位置 1.按岗位统计渠道效果，找出量或质量不足的岗位；4.AI 生成文案或物料初稿，设计复核、统一品牌视觉；7.登记每条渠道的曝光、简历数、有效数、成本
X-RCT-05 主动寻访与开源人才外联 1.登记线索：来源、主页、推荐理由、目标岗位、发现人；5.回信按“感兴趣/婉拒/顾问合作/投诉”分类，24…；6.有意向的索要简历或主页，转入候选人台账走筛选 4.先小批量试发（约 5%），看回复和负面反馈，再分…；5.回信按“感兴趣/婉拒/顾问合作/投诉”分类，24…；8.每轮结束后复盘：发送量、回复率、简历数、面试数、…
X-RCT-06 员工内推受理与内推奖励 1.填内推表单（不在群里或私聊直接丢简历）；2.登记、查重（是否已在台账、其他主体是否面过），信…；3.按岗位分发给用人部门；没有匹配岗位的，询问兄弟团…；5.安排面试，与社招同标准，可优先排期；7.到节点（入职满 1 个月、转正；实习满 3 个月…；8.公示认定结果，设异议期；9.异议期满后，随当月工资税前发放 2.登记、查重（是否已在台账、其他主体是否面过），信…；3.按岗位分发给用人部门；没有匹配岗位的，询问兄弟团…；6.把各节点结果回复推荐人，不透露面评细节；7.到节点（入职满 1 个月、转正；实习满 3 个月…
X-RCT-07 简历收集、初筛与分发 1.从 BOSS、牛客、邮箱、官网等收取新简历，按规…；4.硬条件剔除（学历、用工类型、到岗时间、明显不符的…；5.机器人推送当日待筛清单给岗位筛选人（只发台账链接…；8.按结论联系候选人，转预沟通、笔试或面试 1.从 BOSS、牛客、邮箱、官网等收取新简历，按规…；2.去重（同名、重复投递、其他主体或岗位已面）后入台…；3.AI 按岗位筛选清单打分分档，输出理由；7.超时未筛的自动提醒；仍未处理的转备份筛选人
X-RCT-08 简历真实性核验与 AI 代答识别 7.把疑点、证据截图、结论写入台账“真实性核验”字段… 1.查台账确认是否重复投递、是否做过笔试或被淘汰；用…；4.技术核验：查 GitHub 提交者、commit…
X-RCT-09 候选人预沟通与意向登记 1.用人方在台账里把候选人状态改为“待预沟通”，有附…；3.结果按固定字段录入台账（可用妙记或 AI 从通话…；6.候选人反馈有其他 offer 或截止日期的，标“… 3.结果按固定字段录入台账（可用妙记或 AI 从通话…；7.状态停留超过 2 个工作日未更新的，机器人提醒 …
X-RCT-10 笔试与技术实操考核 1.新岗位开招前出题；出题人提交题目 + 评分标准 …；3.按“岗位—题目对照表”选题，同批 ≤ 15 人，…；4.截止前 1 天提醒未交者；逾期给一次补交机会（延…；7.档次与建议写回台账并通知 HR：第一、二档约面（… 2.发题前确认候选人愿意参加笔试并查重：做过同岗位题…；4.截止前 1 天提醒未交者；逾期给一次补交机会（延…；5.答卷自动按人归档；AI 预审标出疑似代答、过度包…
X-RCT-11 面试安排与面试官分配 1.按岗位×轮次面试官表确定主面与副面；表里没有的岗…；2.查面试官日历给出 2～3 个时段；面试官 1 个…；4.建日程（标题“岗位-候选人-第 N 面”），一次…；5.给候选人发指引：线下发地址、楼层、前台、需带电脑… 2.查面试官日历给出 2～3 个时段；面试官 1 个…；6.给面试官发资料包：简历、预沟通记录、笔试档次与点…；7.每天 9:00 推送“今日面试”清单；面试前 1…
X-RCT-12 面试执行、面评与晋级决策 2.开场：开录制与智能纪要（线下也开会议录音）；摄像…；4.按模板提交面评：可用妙记 AI 摘要做底稿，面试…；7.回写台账：进入下一轮的转 X-RCT-11 排期… 4.按模板提交面评：可用妙记 AI 摘要做底稿，面试…；5.面评提交后自动通知 HR 与用人部门负责人；超过…
X-RCT-13 面试官培养与考察标准 1.新岗位开招前写考察标准卡：考察维度、必问题、实操…；4.辅导人确认可独立主面，登记进面试官名册（可面岗位…；5.规则培训：反问 ≤ 2 分钟、不对候选人做承诺（… 7.季度校准：抽查面评，对比试用期表现，找出漏考项（…
X-RCT-14 跨组面试支援与候选人转推/归属分配 3.机器人 @目标组负责人，附简历、面评、预沟通记录；6.借调面试官：申请方向对方组负责人说明岗位、轮次、… 1.简历按岗位标签分配到业务线，台账填“归属组”；匹…；7.24 小时无回应自动提醒；所有组都不要的入人才池…
X-RCT-15 面试结果通知与不录用处理 3.按结论类型选话术通知：通过 2 个工作日内；淘汰…；4.内推候选人：2 个工作日内同时回复推荐人；7.收集候选人对面试流程的反馈，汇总给用人部门负责人；8.台账回写：录用转 X-RCT-17；暂缓的入人才… 2.结论写入台账后自动生成“通知任务”，带截止日期
X-RCT-16 候选人台账、人才池与招聘系统维护 3.阶段变更回写：约面、笔试、面试完成由日程和笔试系…；4.面试官填写面评并把链接、结论回写到候选人记录；7.新 HC 或岗位重开时先按标签检索人才池；每月清… 2.新简历入库：建档、生成候选人 ID，自动查重并带…；3.阶段变更回写：约面、笔试、面试完成由日程和笔试系…；6.机器人每天 10:00 推送“超过 3 个工作日…；8.收集系统使用问题（上传权限、题组、渲染、预览），…
X-RCT-17 定薪谈薪、录用审批与 Offer 发放 1.终面后按模板给出分项评价和能力级别建议；不通过也…；5.提交飞书“录用审批”：带宽内由 HR 负责人与用…；7.用模板自动填字段生成录用通知书，发用人负责人（技…；8.需背调的岗位背调通过后，从 HR 邮箱发出录用通… 4.对照薪酬带宽出方案：试用期时长与折扣、转正薪资、…；7.用模板自动填字段生成录用通知书，发用人负责人（技…；9.审批单、通知书、候选人回执归档到候选人记录与人事…
X-RCT-18 拟录用背景调查 1.判定背调等级：A 级（财务、总助、核心技术负责人…；2.发送授权书和材料清单，候选人回传；6.填写背调结论表：核实项、结果、疑点、结论（通过/… 3.核对简历、应聘登记表、流水、离职证明的一致性（任…
X-RCT-19 录用确认到入职衔接 1.以邮件或飞书书面确认到岗日期、用工形式、实习周期…；3.自动派发入职任务：座位与工牌（行政）、设备与账号…；7.带教人确认首个任务已布置，首周末反馈一次适应情况 3.自动派发入职任务：座位与工牌（行政）、设备与账号…；4.机器人检查同日到岗人数与空位，冲突时提醒行政调整…；5.向候选人发到岗提醒：时间、地点、联系人、需带材料
X-RCT-20 实习生、兼职与校园招聘 1.提交实习/兼职用工申请，区分长期/暑期短期/远程…；3.多渠道收简历（校园宣讲、学院初筛、熟人/开源社区…；6.出结论并回写台账；熟人或高管推荐的，同步反馈给推…；7.按实习生标准档出薪并发录用通知（超出标准档转 X…；8.校园宣讲：提前排定宣讲人与备份人，材料由用人方提…；9.转入职衔接（X-RCT-19）与实习生管理（HR… 2.汇总各组需求到同一张多维表格；高校批次按学院要求…；4.硬条件预筛：实习周期、每周出勤、到岗时间、课程冲…
X-RCT-21 急岗推进、招聘进度同步与漏斗复盘 3.按流水线推进：新简历 1 个工作日内筛完；通过即…；7.漏斗复盘：每月第 1 周例行一次；某岗位连续两周… 2.建立/更新岗位×阶段看板，数据直接取自候选人台账；3.按流水线推进：新简历 1 个工作日内筛完；通过即…；4.急岗每个工作日 18:00、常规岗每周一 10:…；5.超时提醒：简历超 1 个工作日未筛、面评超 1 …；6.节点汇总（春节前、月初、项目启动前）：按岗位输出…；7.漏斗复盘：每月第 1 周例行一次；某岗位连续两周…
X-RCT-22 招聘团队分工与交接 2.更新分工矩阵，逐岗位写明各环节负责人与备份人，主…；3.在相关招聘群发公告并置顶矩阵链接，说明生效日期；5.给接手方和新面试官开通群历史消息、台账、招聘系统… 4.交出方导出名下在途候选人、待回复事项、已约日程、…；7.一周后回查：是否还有候选人无负责人、简历发错群
X-RCT-23 高管与子公司负责人招聘 2.编写专用 JD，岗位 title 与能力定位一致…；4.预筛与笔试/案例题，评估结论写入台账；7.拟定薪酬与股权方案，法务审核条款，报 CEO（及…；8.发 offer、确认签约主体与到岗日；合资/子公… 2.编写专用 JD，岗位 title 与能力定位一致…；4.预筛与笔试/案例题，评估结论写入台账
X-RCT-24 候选人个人信息与简历数据合规管理 1.在投递入口/面试邀约中加入个人信息处理告知；2.简历统一存入候选人台账，禁止群内转发附件；3.按岗位给面试官授予查看权限；6.清理入库超过保留期限（未录用默认 12 个月，具… 4.确认 AI 工具合规（内部网关或经法务确认的工具…；6.清理入库超过保留期限（未录用默认 12 个月，具…
X-RCT-25 猎头与外部招聘服务商合作及费用结算 1.提交使用外部服务申请；4.收到推荐时查重并确认归属；5.入职后跟踪保证期；6.按协议对账、申请付款并收票 4.收到推荐时查重并确认归属
X-RCT-26 Offer 变更、撤回与候选人未到岗处理 1.登记变更情形与原因；3.审批撤回/变更；5.通知行政、IT 取消入职准备 7.更新台账，判断是否从人才池补位
X-SEC-01 新人入职 IT 账号一站式开通与内部系统… 1.入职单生效，自动生成“账号开通清单”任务，带出岗…；3.按系统拆单，派给对应管理员；5.在台账回填账号名、权限级别、开通日期；8.处理自检异常，全部关闭后清单归档 3.按系统拆单，派给对应管理员；6.到岗当天推送账号清单 + “系统-负责人-申请入…
X-SEC-02 代码仓库（Gitea）账号与仓库权限开通… 1.提交“仓库权限申请”（账号、组织/仓库、角色、期… 3.建号（命名＝姓名拼音，机器人账号以 -bot 结…；6.回填台账：账号、团队、仓库、角色、期限、批准人；9.封禁：收到离职/试用终止/违规通知后先封号，再转…；10.季度盘点：对照花名册清理离职、超期、超范围权限；…
X-SEC-03 内部业务系统与管理后台账号/角色开通及密… 1.提交“业务系统角色申请”（系统、环境、角色、用途…；5.登记台账，临时授权设到期提醒；6.到期自动提醒，未续批即降级或停用 4.发放凭据：一次性链接或短信，强制首登改密；验证码…；6.到期自动提醒，未续批即降级或停用
X-SEC-04 企业邮箱与公共邮箱开通授权 1.个人邮箱随入职单自动开通（拼音@公司后缀）；2.公共邮箱/SMTP 提交“邮箱申请”；4.创建公共邮箱并按名单授权（成员 ≥ 2 人）；6.登记台账，配置新邮件飞书提醒到负责人；7.人员入转离时同步增减公共邮箱成员 6.登记台账，配置新邮件飞书提醒到负责人
X-SEC-05 内部系统接入飞书统一登录（SSO）与登录… 1.在登录台账登记接入需求（系统、用户范围、现有账号…；2.按接入模板创建飞书应用，只申请最小权限，配重定向…；6.发布变更通知：生效日、登录入口、旧账号停用时间、…；7.更新登录台账，系统纳入离职自动失效范围 2.按接入模板创建飞书应用，只申请最小权限，配重定向…
X-SEC-06 外部协作方访问内网、联调环境与数据授权 1.提交“外部人员接入申请”（主体、人员、资源、数据…；2.核验保密协议有效、覆盖本次数据范围；5.开通：每人独立账号、只读优先、设到期日；数据接口…；6.凭据通过密码工具或飞书保密文档限时分享，禁止在群…；7.实体测试机走“实体资产领用”审批出库寄送；8.登记台账；网络变更需重新下发配置时统一通知所有外…；9.到期前 3 个工作日提醒；结束当天停用账号、撤 … 5.开通：每人独立账号、只读优先、设到期日；数据接口…；9.到期前 3 个工作日提醒；结束当天停用账号、撤 …
X-SEC-07 客户/渠道索要设备 root/管理员账号… 2.按类型对照口径：root/服务器账密＝默认拒绝；…；3.标准件按话术回复（“交付的是产品不是服务器”，类…；4.例外或管理员密码找回：提交“生产环境访问—客户上…；6.执行：开限时账号或现场代操作；账密存团队密码库，…；8.到期回收：停用账号、撤 WG、改密，并回填 2.按类型对照口径：root/服务器账密＝默认拒绝；…；7.登记台账，到期自动提醒回收；8.到期回收：停用账号、撤 WG、改密，并回填
X-SEC-08 离职/试用终止/调岗账号回收与权限收口 1.异动单生效，按台账自动生成回收清单并派单；3.正常离职：各系统停用或转为不可登录；5.此人知晓的共享账号、服务器密码、密钥改密或轮换；6.移出飞书群、企业微信、外部协作群；敏感群（财务、…；7.调岗：按新岗位模板授权，移除原岗位多余权限和原部…；8.回收清单全部关闭，回填台账，人事归档 1.异动单生效，按台账自动生成回收清单并派单；7.调岗：按新岗位模板授权，移除原岗位多余权限和原部…；9.月度盘点：对照花名册扫描各系统残留账号与敏感群成…
X-SEC-09 测试/内部环境地址与管理员账号登记交接 1.部署或重置完成后，把 owner 账号、组织 I…；2.更新环境台账：地址、用途、版本、负责人、状态、密…；4.使用人先查台账；需要凭据的提交“环境访问申请”（…；7.忘记密码或账号被锁：先查密码库；仍不行就提交“重…；8.月度核对：台账与实际环境逐一比对，已下线环境归档… 1.部署或重置完成后，把 owner 账号、组织 I…；2.更新环境台账：地址、用途、版本、负责人、状态、密…；3.在产研群发变更公告：环境名、变化内容、台账链接，…；8.月度核对：台账与实际环境逐一比对，已下线环境归档…
X-SEC-10 密钥与凭据分发保管规范（禁止群内明文） 2.在密码库对应分组新建条目（名称含系统、环境、用途…；3.L2：直接授权给使用人或项目分组；L3：提交授权…；4.登记凭据台账：系统、环境、密级、持有人、一主二备…；8.月度审计：核对台账与密码库授权，清理离岗、到期授… 5.程序和 AI 代理只通过环境变量、CI secr…；6.凭据更新（如 90 天重置）后只更新密码库条目，…；7.群聊明文检测：机器人识别疑似密钥、密码后提醒撤回…；8.月度审计：核对台账与密码库授权，清理离岗、到期授…
X-SEC-11 凭据泄露应急处置与密钥轮换 1.撤回消息或删除文件，在“安全事件”表单上报（不写…；4.生成新凭据，按 X-SEC-10 经密码库重新授…；6.终端中招：全员排查同类问题，涉事机器清理或重装，…；7.登记复盘：时间线、影响、根因、整改项（如加 pr…；8.定期轮换：生产与 L3 以上凭据每 90 天轮换… 4.生成新凭据，按 X-SEC-10 经密码库重新授…；5.溯源：查用量、登录与调用日志，确认是否被滥用、凭…；8.定期轮换：生产与 L3 以上凭据每 90 天轮换…
X-SEC-12 第三方平台/对外账号台账与验证码代收 1.发起全量盘点：各持有人填写“平台账号登记表”，凭…；6.新注册、交接、转让管理员、注销账号时，当天更新台…；8.季度核对：使用人是否在岗、账号是否仍需要、密码库… 4.验证码收口：公司号码卡插入收码设备，机器人按“平…；7.余额、到期、认证到期前 15 天机器人提醒财务和…；8.季度核对：使用人是否在岗、账号是否仍需要、密码库…
X-SEC-14 AI 编程工具订阅账号开通、充值与防封管… 1.新人入职表单带“AI 工具需求”字段，自动写入台…；2.在岗员工每月 25 日前提交次月“AI 工具申请…；4.镜像账号：以企业邮箱开号，每月 10 日统一开通…；6.登记台账：使用人、工具、套餐、支付方式、出口、到…；9.离职、取消或连续 1 个月未使用：停订、回收，台… 1.新人入职表单带“AI 工具需求”字段，自动写入台…；2.在岗员工每月 25 日前提交次月“AI 工具申请…；4.镜像账号：以企业邮箱开号，每月 10 日统一开通…；7.到期前 5 天提醒充值负责人；充值完成后通知使用…；9.离职、取消或连续 1 个月未使用：停订、回收，台…
X-SEC-15 云平台子账号/控制台权限与 Access… 2.提交“云权限申请”；4.一次性授予整个策略包或新建子账号（默认最小权限，…；5.需要 AK 的，生成后直接写入密码库或 CI s…；6.申请人验证；仍缺权限的在原申请单补充，不另起群聊；8.临时权限到期当天回收；每季度盘点全部子账号、AK… 1.按岗位选权限包；报错不确定的，用 AI 根据报错…；5.需要 AK 的，生成后直接写入密码库或 CI s…；7.登记权限台账：人员、平台、主体、权限包/策略、A…；8.临时权限到期当天回收；每季度盘点全部子账号、AK…
X-SEC-16 云服务器与云资源申请开通（CVM/COS… 1.在“非实体资产申领”审批中按第 3 节填全字段提…；3.审批通过后自动生成开通任务派给云资源管理员；6.写入申请人公钥；密码类凭据放密钥管理，群内只发实…；8.登录自测，在任务中点“验收” 4.按标准模板开通（折扣机型、预装 docker、通…；6.写入申请人公钥；密码类凭据放密钥管理，群内只发实…；7.写入资源台账（实例 ID、IP、规格、用途、负责…；9.到期前 7 天提醒负责人续用或释放；释放按 X-…
X-SEC-17 内网测试服务器/GPU/虚拟机/CI R… 1.提交内网资源申请（资源类型选“内网”）；5.公钥统一由 IaC/updater 下发；面板默…；9.换机/重置/下线：提前 3 个工作日在台账和群内… 3.建机/建虚拟机/分配 GPU 时段或 runne…；4.配 IP、端口段、网关并写入脚本持久化（重启不丢…；5.公钥统一由 IaC/updater 下发；面板默…；6.登记资源池台账并自动通知申请人；7.按规则使用：容器限 CPU/内存/磁盘，预留约 …；8.巡检：CPU/内存/磁盘超阈值告警；30 天未登…；10.到期前 3 天提醒；未续期则备份后重置并更新台账
X-SEC-18 生产资源访问申请审批与回收 1.提交“Leap 生产资源访问申请”；3.机器人建专属群，推送卡片并 @ 开通执行人；6.群内回复处理结论并申请关闭；8.关单、解散专属群，审批单关联操作记录 4.签发限时凭证：服务器加带有效期的公钥；数据库给 …；5.在批准范围内访问，命令与查询留痕；禁止在生产机上…；7.到期自动回收公钥/账号、移除白名单，群内提示
X-SEC-19 域名解析、SSL 证书与端口开通 1.提交“域名/端口变更单” 2.校验主域名已备案、命名合规、与现有记录不冲突；按…；4.配置解析/EdgeOne/安全组/CORS（脚本…；5.证书优先 Caddy/ACME 自动签发续期；云…；7.写入域名台账，在变更单回复完成
X-SEC-20 域名选购与 ICP 备案 1.登记域名需求（用途、候选、主体、上线日）；2.查域名台账，有现成可用的直接分配，跳到步骤 6；5.在对应主体的云账号下购买，并提交 ICP 备案（…；6.备案通过后配置 DNS 解析、HTTPS 证书、…；8.登记台账（备案号、到期日、负责人），设到期前 3… 3.批量查询候选的可注册性、价格、能否在国内备案；结…；8.登记台账（备案号、到期日、负责人），设到期前 3…
X-SEC-21 证书与域名到期监控续期 1.新证书/域名上线时登记台账，优先 Caddy/A…；5.续期：自动续签失败查原因；免费证书手动续签；付费…；8.云厂商通知（证书、数据库安全升级）转飞书并指派，… 2.每日扫描全部对外域名的证书剩余天数并回写台账；3.到期前 30 天提醒服务负责人与证书管理员；7 …；6.部署新证书并验证浏览器、客户端、git 推送；7.更新台账到期日与续期记录
X-SEC-22 云资源/域名资产盘点与闲置回收（成本治理… 3.群内发认领清单并 @ 疑似负责人，5 个工作日内…；4.未认领资源公示 7 天；6.关机保留 7 天观察 1.导出全部云资源（服务器、数据库、COS、负载均衡…；2.与台账比对，标出无标签/无负责人、低负载（CPU…；8.高价型号迁到折扣型号，调整计费方式；9.更新台账，输出成本月报（总额、环比、释放节省、费…
X-SEC-23 代码签名证书申请、保管与签名使用 1.提交证书采购申请（主体、类型、渠道、费用）；2.审批并付款；4.UKey 到货登记资产台账（保管人、位置、到期日…；9.保管人或使用权变更：审批、按清单交接、群内通知 5.CI 打包完成，机器人推送签名审批卡片（Run、…；7.签名机按签名范围清单签名（只签自研可执行文件，已…；8.记录签名日志（Run、审批人、时间、文件数）
X-SEC-24 办公网络接入认证、网络分区与 WiFi … 1.对照《办公网络使用说明》判定分区：员工办公设备→…；2.提交“入网登记”表单（MAC、设备名、用途、责任…；4.按身份下发凭据：员工走认证/私聊一次性可见卡片；…；6.台账更新（MAC/IP/责任人/分区/入网日期）；7.访客网凭据每月轮换并更新 Bot；离职/设备报废… 3.审核申请；办公设备做飞连绑定+静态地址绑定，服务…；4.按身份下发凭据：员工走认证/私聊一次性可见卡片；…；7.访客网凭据每月轮换并更新 Bot；离职/设备报废…
X-SEC-25 远程办公与内网访问接入（飞连/VPN/I… 1.提交“远程访问申请”（场景、对象、时长、设备）；3.部门负责人审批必要性与时长；5.申请人按手册自检：公司内连 MTYQ-WORK；…；7.台账登记（人、通道、对象、到期日）；8.到期自动提醒回收；离职当日回收飞连席位与白名单；… 4.开通：飞连发账号并下发策略；IP 白名单跑同步脚…；5.申请人按手册自检：公司内连 MTYQ-WORK；…；8.到期自动提醒回收；离职当日回收飞连席位与白名单；…
X-SEC-26 海外出口线路与代理节点运维 1.提交“出口线路工单”（故障/白名单/新线路/续费…；2.分类与响应：故障工作时间 30 分钟内响应；白名…；4.需付费事项（新节点、落地 IP、续费、扩容）出预…；6.验证（使用人复测）并在通知群公告变更（新节点、白…；7.更新台账：节点/落地 IP/白名单/带宽/流量上… 2.分类与响应：故障工作时间 30 分钟内响应；白名…；3.故障按“控制变量清单”排查：换网对比→关本地代理…；8.用量与可用性监控：流量达 80% 告警；到期前 …
X-SEC-27 办公网络故障报修与恢复 2.提交“网络故障反馈”（位置、SSID、现象、时间…；4.响应并在通知群发状态（影响范围、预计恢复时间、临…；9.发恢复通知；故障登记；P0/P1 在 3 个工作… 1.按自检清单排除个人终端问题；5.分层排查：终端→AP/交换机/网线→IP 冲突与…；8.CI 机/签名机/runner 恢复在线并重跑积…；9.发恢复通知；故障登记；P0/P1 在 3 个工作…
X-SEC-28 办公网络建设升级、带宽专线扩容与机房设备… 1.按模板写网络需求文档并立项；5.采购审批与合同（含发票类型、二手设备开票方式）；6.排施工窗口（非工作时间、分区分批割接），提前公告…；7.施工进度在飞书任务/项目更新；延期由服务商当日书…；9.更新线路台账、硬件清单、拓扑；公告新限速与分区策… 4.比价表拆分硬件/软件/施工/年费，谈价
X-SEC-29 机房/服务器停机维护、迁移与故障应急（含… 1.计划变更提交“基础设施变更申请”（影响/窗口/回…；6.发恢复通知（对内+销售/客户）；新地址经台账或受…；7.故障或超窗变更 3 个工作日内复盘；更新台账；旧… 3.审批通过后发公告：计划内 ≥ 24 小时、紧急检…；5.按验证清单验证：服务可访问、卷已挂载、容器在数据…；8.备份定级与配置：盘点生产数据，按资金/客户/一般…；9.备份校验：每日自动校验备份是否成功、大小是否异常…
X-SEC-30 IT 资产领用、设备报修与终端技术支持 1.在飞书审批“运维”类别提交实体领用/非实体领用/…；2.领用类由部门负责人审批；5.审批通过/发放后自动更新台账（已发放数、库存、使…；6.申请人确认后关闭工单；8.月度台账对账：申请数与发放数一致、补齐数量/价格… 3.IT 受理并按类别分派（网络/电脑/账号/会议室…；4.处理：发放并登记；新机按初始化清单处理；远程或现…；7.同类问题出现 2 次以上写入 FAQ 或安装脚本；8.月度台账对账：申请数与发放数一致、补齐数量/价格…
X-SEC-31 终端安全管控（飞连/IOA 部署、锁屏与… 2.申请试用并按测试用例清单小范围测试，记录结论；3.按“需求清单+对比表”向渠道要报价，核对模块不重…；4.下单后核对授权数与模块（含 DLP、MDM），同…；6.分批推广：提前 2 个工作日通知（含备份提示、影…；8.员工异常反馈走“终端异常反馈”表单；IT 4 个…；9.席位随入离职增减；每季度审计覆盖率、授权余量、违…；10.公司数字账号资产统一登记，密码进入密码库，禁止私… 6.分批推广：提前 2 个工作日通知（含备份提示、影…；7.策略执行：强制自动锁屏（建议 ≤ 10 分钟）、…；9.席位随入离职增减；每季度审计覆盖率、授权余量、违…
X-SEC-32 大会/活动现场网络与设备保障 1.发布需求征集表单（区域、用途、电脑机型/数量、显…；2.各区填报，写清具体机型与用途，只在表单内修改；3.汇总核对，与库存比对，缺口走借用/采购；5.需求冻结；冻结后变更须在表内提变更并经会务负责人…；6.设备备货、按区域编号贴标、装机自检、装箱；10.撤场回收清点，更新台账，登记缺损 3.汇总核对，与库存比对，缺口走借用/采购；8.现场测速：每区有线/无线上下行实测，直播链路压测…
X-SEC-33 飞书自建应用/机器人/CLI 权限申请审… 2.在开放平台创建版本并提审；同时提交“应用权限申请…；3.机器人把待审事项推送给审核人（不再默认推送人事）；5.超时转交：L1/L2 超 1 个工作日未处理自动…；8.登记应用台账；9.季度盘点：到期或 90 天无调用的应用通知 ow… 1.对照权限分级表自检，删除不需要的 scope；3.机器人把待审事项推送给审核人（不再默认推送人事）；8.登记应用台账；9.季度盘点：到期或 90 天无调用的应用通知 ow…
X-SEC-34 飞书平台管理员事项（席位、功能配置、可见… 2.提交工单（类别、描述、截图、紧急度）；3.分类派单：咨询/后台配置/需顾问/采购；6.席位：用量 ≥ 90% 自动预警 → 人事汇总入… 1.先查内部飞书 FAQ，或用 AI 助手检索飞书帮…；9.回复申请人并关单；共性问题写入 FAQ
X-SEC-35 敏感数据导出与 AI 分析授权（聊天记录… 1.提交“敏感数据使用申请”；2.按勾选的数据类型自动定级，D1 仅登记；8.无人值守任务使用专用应用身份 + 最小 scop…；9.到期删除数据并在申请单回填 2.按勾选的数据类型自动定级，D1 仅登记；6.按批准范围导出：排除敏感群，手机号、证件号、金额…
X-SEC-36 新工具与高权限软件安全试用环境 2.提交试用环境申请（软件、来源、权限、系统、规格、…；4.开通云轻量机/虚拟机/容器；安全组仅放行必要端口…；5.凭据通过密码管理工具或一次性私信发放，禁止发群；8.到期提醒并回收；续期需重新申请 4.开通云轻量机/虚拟机/容器；安全组仅放行必要端口…；6.本机运行 Agent 按基线配置：非 root、…；8.到期提醒并回收；续期需重新申请
X-SEC-37 AI Agent/飞书机器人上线安全检查… 1.在机器人注册表登记 owner、能力、等级、sc…；3.身份授权：确认人按 open_id 绑定，群内转…；7.进入白名单内部群；外部群禁止接入，需外发信息改为…；10.不再使用的机器人下线，回收密钥与 scope 2.按部署基线搭建：容器/沙箱运行、非 root、仅…；4.会话隔离与信息过滤：私聊与群聊上下文隔离；证件号…；5.在测试群跑红队用例：套取环境变量/密钥、提示词注…；8.运行审计：调用日志保留 ≥ 90 天，每月抽查异…
X-SEC-38 服务器上线安全基线与对外演示暴露面检查 1.申请服务器时选择基线模板；4.提交公网暴露申请：端口、域名、用途、期限、鉴权方…；6.上线确认并登记资产与暴露面台账；7.客户机器：部署脚本强制随机口令、关闭 root … 2.开机即应用基线：证书登录、禁 root、随机口令；5.端口与弱口令扫描验证；7.客户机器：部署脚本强制随机口令、关闭 root …；8.每月复扫内网与公网口令和端口；演示环境到期提醒下…
X-SEC-39 安全扫描与渗透测试申请执行 1.提交测试申请（资产、环境、类型、时间窗、禁止动作…；3.准备单独测试账号、SSH 公钥登录、限定源 IP…；8.建工单移交整改，按等级设期限：高危 3 个工作日…；9.制定周期计划：每季度一次全量扫描，重大版本与 M… 4.在扫描工具中配置资产白名单，只在授权范围与时间窗…；5.机器人按高/中/低危推送发现到专用群；7.出报告：范围、方法、发现、等级、证据、修复建议
X-SEC-40 漏洞整改闭环与对外遗留资产清理 1.扫描结果、外部报告、员工发现统一录入漏洞台账，一…；3.确认归属：先查资产台账；查不到在安全群 @ 疑似…；6.下线遗留站点：按下线清单逐项清理 DNS、反向代…；8.回复外部报告人“已修复”；机器人每日推送未关闭工… 1.扫描结果、外部报告、员工发现统一录入漏洞台账，一…；7.针对该工单复扫，通过即关闭，不通过退回第 5 步；8.回复外部报告人“已修复”；机器人每日推送未关闭工…
X-SEC-41 高危漏洞、供应链投毒与 AI 工具安全通… 1.任何人看到通告转入安全通告群；响应负责人登记到通…；3.严重/高：在通知群发布统一通告（原理一句话、影响…；4.服务器由服务负责人跑排查脚本，个人设备由本人自查…；7.发布结论：排查对象数、受影响数、已处置数、遗留项… 1.任何人看到通告转入安全通告群；响应负责人登记到通…；2.比对资产清单，指定研判人确认触发条件并定级：严重…；4.服务器由服务负责人跑排查脚本，个人设备由本人自查…；6.每日推送未回填名单；脚本或抽查复核已处置项
X-SEC-42 内网安全事件与异常请求溯源处置 1.发现人在安全事件群发“事件快报”（现象、时间、截…；6.补防护：涉事设备及同网段未装终端安全软件的公司终…；8.云厂商告警/评估报告：逐项登记为整改项，转 X-… 4.溯源：按出口日志 → 内网流量日志 → DHCP…
X-SEC-43 等保测评、整改与云安全产品采购 2.与服务商签约并约驻场日期；整改负责人填资产表，技…；3.为测评方开临时访问（IP 白名单/测试账号），登…；4.驻场测评出差距报告后，拆成整改台账（测评项 → …；6.列出必须的安全产品，向服务商确认必要性与折扣，走…；9.提交资料，跟进约 2～3 周出电子版+纸质版报告…；10.保留安全配置；收到抽检通知按清单恢复被关闭的功能… 4.驻场测评出差距报告后，拆成整改台账（测评项 → …；7.逐项整改：基础设施（关公网、堡垒机、日志接入、云…；8.内部漏扫与自检脚本通过后约复测；复测问题汇总在 …；10.保留安全配置；收到抽检通知按清单恢复被关闭的功能…
X-SEC-44 数据泄露（含个人信息）事件响应与报告 1.在安全事件入口上报，不在大群扩散细节；3.评估数据类别、条数、是否被外部获取、影响对象；5.按审定口径通知受影响方；6.根因整改并复测，输出事件报告 3.评估数据类别、条数、是否被外部获取、影响对象
X-SEC-45 个人信息分类分级、保留期限与用户权利请求… 3.登记请求：C 端用户请求由 OPS-29 转入，…；6.回复请求人；客户需要时出具删除确认函 5.执行导出/更正/删除/注销，保留执行记录；7.按期限清理到期数据
X-SEC-46 账号与权限定期复核 3.发部门负责人确认保留/降权/回收；5.出复核报告并归档 1.导出各系统账号、角色、最近登录时间；2.与在职名单比对，标出离职遗留、超范围、90 天未…
X-SEC-47 全员信息安全意识培训与考核 3.新人完成线上课程与考试；4.年度全员培训与考试，80 分及格；6.统计未完成、不及格与中招人员并补训 2.编制课件与题库（凭据、AI 工具、钓鱼、终端、客…；5.每半年一次钓鱼邮件/消息演练
X-OTH-01 上游模型/云服务供应商询价、折扣谈判与签… 1.提交上游采购需求（模型/服务、用量、并发、截止时…；2.确定签约与使用账号主体，查台账已有折扣；3.按模板向 ≥2 家发询价（含所有主流模型折扣）；5.测试额度/最低准入套餐审批，试跑验证质量与并发；6.合同比对（折扣与官网价、并发、付款条款）及合规审…；7.签约、开户、首充；账密进统一密码库；8.登记台账，通知网关定价与财务成本价；9.供应商响应超时或对接人变更：拉群交接、更新台账 3.按模板向 ≥2 家发询价（含所有主流模型折扣）；6.合同比对（折扣与官网价、并发、付款条款）及合规审…；8.登记台账，通知网关定价与财务成本价
X-OTH-02 上游并发/TPM 配额提额申请与追进 4.提交工单，同时在商务群 @上游；线上事故由商务对…；5.追进：线上问题每 2 小时跟进；非紧急每个工作日…；7.更新配额台账，设置“低使用率回收”预警；8.压测前用模板通知上游 1.确认限流来源（上游 vs 我方网关），导出 42…；3.AI 生成给上游的问题说明/提额申请；6.上游确认后复测；7.更新配额台账，设置“低使用率回收”预警
X-OTH-03 云厂商代金券与赠送额度登记及到期消耗 1.收到券/额度当天登记台账；2.设置到期前 14 天、3 天自动提醒；3.收到 14 天提醒后，收集用途提案（评测、测试环…；6.到期当天关停临时资源，核对无券外费用；7.更新台账消耗结果，财务入账 2.设置到期前 14 天、3 天自动提醒；5.执行消耗：评测任务排期、IaC 一键起测试环境；6.到期当天关停临时资源，核对无券外费用

两周 SOP 优化期推进建议

总体原则：先打通跨部门交接，再细化部门内部流程；先抓高频、有事故史、涉及钱和安全的环节；每条 SOP 都要有负责人、入口、时限、留痕位置和验收人。

第 1 周：定归属、定入口、出 P0 SOP 初稿

时间 事项 牵头 产出/验收
第 1 天 启动会：发布本总览，宣布优化期规则（期内新规则只以 SOP 形式发布） 总经办 全员通知回执；各归属代码指定 1 名 SOP 负责人和 1 名 B 角
第 1～2 天 裁决 X- 开头的待定归属（售后、产品、交付、FDE、招聘、信息安全、其他），给缺位职能指定临时负责人 总经办 + 各部门负责人 归属裁决表定稿，每个 X- 条目都有落位部门
第 1～2 天 确定 P0 清单：Top 10 断点关联 SOP，加上每条主线中“事故最多”的 1～2 个环节，约 40～60 条 总经办 + 各 SOP 负责人 P0 清单与负责人表
第 2～4 天 按统一模板起草 P0 SOP（触发条件、输入、步骤、输出、时限、责任人、留痕位置、异常升级），可直接以本手册对应条目为初稿，再由负责人修订 各 SOP 负责人 P0 SOP 初稿全部进入统一知识库目录
第 2～4 天 优先落地三类“入口”：需求/客户问题统一入口（产品+售后）、资源/账号/AI 工具统一申请入口（信息安全/IT+财务）、交付工单入口（交付+销售） 产品负责人、IT/安全负责人、交付负责人 飞书表单/审批或多维表格入口上线，群公告置顶
第 3～5 天 优先落地三类“门禁”：合同多方会签（法务）、发布单与生产变更申请（研发）、资金/额度类审批（财务） 法务、研发负责人、财务负责人 审批流配置完成，并用一个真实案例走通
第 5 天 跨部门评审会：按 F1～F8 逐条过交接点（谁交给谁、交什么、多久） 总经办主持 每个交接点都有双方签字确认的交接定义；冲突项当场拍板并写入决策记录
全周 安全快速整改：群内禁发凭据公告，统一密码管理工具开通，存量明文凭据排查与轮换 IT/安全负责人 工具开通率，以及已轮换的高风险凭据清单

第 2 周：试运行、补 P1、验收发布

时间 事项 牵头 产出/验收
第 6～8 天 P0 SOP 试运行：每条主线至少选 3 个真实事项（1 个新线索、1 次发版、1 次采购、1 名入职等）按 SOP 全程走一遍 各 SOP 负责人 试运行记录，标出卡点、超时和绕行
第 6～8 天 起草 P1 SOP：各部门内部的高频事务（考勤、报销、会议纪要、测试冒烟、售后一线手册等） 各部门负责人 P1 初稿进入目录
第 7～9 天 自动化接入：把 SOP 的提醒、催办、台账和通知接到统一机器人和多维表格（超期提醒、余额预警、到期提醒、发版通知） 研发/IT 指定的自动化负责人 至少 5 个自动提醒上线；机器人台账与权限说明成文
第 8～9 天 授权矩阵与决策记录模板发布；关键节点 AB 角清单发布 总经办 授权矩阵公告；AB 角清单覆盖本文第 1 条发现中列出的全部单点节点
第 9 天 根据试运行修订 SOP，删除无人执行的步骤，合并重复条目 各 SOP 负责人 SOP v1.0 定稿
第 10 天 验收会：每位 SOP 负责人用 5 分钟演示一条 SOP 的真实执行留痕 总经办主持，各部门负责人互评 通过的 SOP 正式发布并完成宣贯；未通过的列出整改期限

验收指标（优化期结束时对比启动前一周）

  • 入口外需求数：绕过需求池直接找研发的需求条数明显下降。
  • 群内 @ 催办次数：主要工作群里的催办类消息减少。
  • 发布质量：发布单和检查清单执行率 100%，发版后回滚或 hotfix 次数下降。
  • 客户反馈闭环率：已回告的反馈占比达到目标值，首响时限达标率可统计。
  • 安全：新增明文凭据告警数趋近于零，离职与外部权限回收 100% 留痕。
  • 资金类动作：赠送额度、充值、退补、采购 100% 有审批记录。
  • SOP 覆盖：P0 SOP 都有负责人、入口和留痕位置，且至少完成 1 次真实执行。

优化期之后

每月由总经办召开一次 SOP 例会，看执行数据、事故复盘带来的修订和新增需求；每季度抽查一次执行情况，把 SOP 执行纳入部门负责人考核，避免“写完即失效”。

ALL 全公司协作协议

报送人：待定（建议综合部牵头） · 全公司通用 · 11 条 · 已有 0 / 待优化 2 / 待新建 9
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ALL-01工作请求提交与受理（一事一入口）任何人需要别的岗位或部门为自己做一件事（提需求、要资源、要审批、要支持、要数据、要人）时，决定“往哪里提、写什么、多久有人接”，替代在群里 @ 人或私聊口头提。主责——总经办运营（当前：田杰·部门报送人）；协同——各入口受理岗（产品需求受理岗、售后值班岗、IT/安全受理岗、交付受理岗、财务受理岗、HR 受理岗，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 判断请求类型 → ② 按入口表选唯一入口 → ③ 按最少字段填写 → ④ 受理岗限时认领并回执 → ⑤ 补齐信息或退回 → ⑥ 转入对应 SOP 执行 → ⑦ 状态回告提出人 → ⑧ 提出人确认关闭一张全公司“请求类型 → 入口 → 受理岗位 → 响应时限 → 对应 SOP”入口表（群公告置顶 + 知识库）；每条请求都有编号、受理人、状态和关闭记录。待新建300
ALL-02消息分级与响应时限发出或收到一条需要别人行动的工作消息时，判断它是 P0/P1/P2、该用什么渠道（群、工单、电话）、多久必须有回应，以及什么时候不该私聊。主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人（排值班与 B 角）、研发负责人（当前：丁震宇·部门报送人，告警与故障分级口径）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 发消息前定级 → ② 按级别选渠道并标注 → ③ 接收方按时限回应“收到+预计” → ④ 超时自动提醒 B 角 → ⑤ 处理结果回到原消息/工单 → ⑥ 月度统计响应时长《消息分级与响应时限规则》（群公告 + 知识库）；每条 P0/P1 消息有可查的首响记录；私聊中的工作结论回写到群或工单。待新建300
ALL-03决策记录与发布任何会影响他人工作的决定（方向、规则、优先级、口径、资源分配、做/不做）在会上、群里、电话或私聊中形成后，判断是否需要记录、记在哪里、怎么发布、什么时候算数。主责——总经办运营（当前：田杰·部门报送人，决策记录表维护）；协同——各决策人（CEO、COO、CTO、各部门负责人）、综合部（制度类决策发布，当前：赵雪冰·部门报送人）；兜底——CEO（当前：待指定）① 判断是否为“影响他人的决定” → ② 决策人或记录人 1 个工作日内写决策记录卡 → ③ 发布到相关群并置顶/进知识库 → ④ 相关方回执 → ⑤ 生效 → ⑥ 复议走正式通道 → ⑦ 季度回顾《决策记录表》（多维表格）；每条决策有编号、选项、依据、结论、决策人、生效日、影响范围、发布链接；规则类决策进入制度库。待新建320
ALL-04跨部门交接契约一件事从一个岗位/部门交给另一个岗位/部门继续做（销售→交付、产品→研发、研发→测试、交付→财务、HR→IT 等）时，规定每次交接必须说明交什么、给谁、在哪里、什么时候、验收标准、超时找谁。主责——总经办运营（当前：田杰·部门报送人，交接定义表维护）；协同——各主线 SOP 负责人（按手册第 2 章 F1～F8 交接点）、各部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 识别交接点 → ② 交出方按“六要素”发交接单 → ③ 接收方限时确认接收或退回 → ④ 接收方按验收标准做 → ⑤ 交出方验收/关闭 → ⑥ 超时触发升级 → ⑦ 交接点定期复盘《跨部门交接定义表》（每个交接点：交出方、接收方、交付物、位置、时限、验收标准、超时升级人）；每次交接有可查的交接单或工单字段。待新建400
ALL-05会议发起、纪要与待办闭环任何人想开会（例会、专题、评审、对齐、复盘）时，判断是否真的需要开会、怎么发起，以及会后 24 小时内如何产出决议与待办并进入任务系统。主责——总经办运营（当前：田杰·部门报送人）；协同——各会议发起人、记录人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 判断能否不开会 → ② 发起：目的/议程/材料/参会人/时长 → ③ 开会并开启智能纪要 → ④ 24 小时内校对纪要、决议进决策记录、待办进任务 → ⑤ 参会人回执 → ⑥ 待办跟踪关闭带议程与材料的日程；24 小时内发布的纪要（决议 + 待办 + 责任人 + 截止日）；待办全部在任务系统可查。待优化180
ALL-06卡点升级阶梯一件事卡住（无人认领、对方超时、两边意见不一致、资源不够、不知道找谁）时，规定卡多久向谁升级、升级时写什么，替代“直接找老板”或“反复在群里催”。主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人、各入口受理岗；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 确认已走入口且已超时限 → ② 第一级：对方 B 角/值班 → ③ 第二级：对方部门负责人 → ④ 第三级：总经办协调 → ⑤ 第四级：CEO/COO/CTO 裁决 → ⑥ 升级结果回写原单 → ⑦ 月度升级统计每次升级有一条可查的升级记录（卡点、已做努力、需要谁决定什么、期限）；升级路径固定，越级事项被退回原路径。待新建300
ALL-07群聊治理（建群、命名、公告、归档）需要新建工作群、决定某条消息发到哪个群、设置群公告、处理群混用与刷屏、项目结束归档群时启动；明确群只是沟通渠道，不是存档与受理入口。主责——综合部负责人（当前：赵雪冰·部门报送人）；协同——飞书管理员（当前：待指定）、各群群主；兜底——总经办运营（当前：田杰·部门报送人）① 判断是否需要建群 → ② 按命名规则建群并设群主/B 角 → ③ 发布群公告（职能、入口链接、禁发事项） → ④ 按群类型发消息 → ⑤ 机器人分级降噪 → ⑥ 项目结束归档 → ⑦ 季度清理《群职能与命名规则》；每个工作群有群公告（职能 + 入口表链接 + 禁发规则）；群台账（群名、类型、群主、B 角、状态）。待优化120
ALL-08信息归档与单一事实来源产生或需要查找一份工作信息（客户信息、合同、订单、需求、版本、环境地址、账号台账、价格、制度、决策、文档）时，规定它只能存在哪里、谁维护、群聊与私聊中的内容如何回写；替代“翻群找”“问一下谁有”。主责——综合部负责人（当前：赵雪冰·部门报送人，数据源清单与知识库）；协同——各数据主责岗（CRM：销售；需求池：产品；工单：研发；台账：交付/IT/财务/HR）、产品负责人（内部系统归口，X-PRD-38）；兜底——总经办运营（当前：田杰·部门报送人）① 查《单一数据源清单》 → ② 信息产生时直接写入指定位置 → ③ 群/私聊只贴链接或编号 → ④ 聊天中的结论 1 个工作日内回写 → ⑤ 其他位置只做引用不做副本 → ⑥ 月度检查副本与过期信息 → ⑦ 清单变更走审批《单一数据源清单》（信息类型 → 唯一位置 → 主责岗位 → 编号规则 → 对应 SOP）；群公告与入口表链接到清单；每类信息只有一个主表。待新建300
ALL-09状态看板与进度同步任何人想知道“某件事到哪了”，或执行人需要让别人知道进展时，规定用看板/工单状态替代群里追问；“问进度”应变成“查看板”，执行人按节奏更新状态而不是被动回答。主责——总经办运营（当前：田杰·部门报送人，公司级看板）；协同——研发负责人（工单看板，当前：丁震宇·部门报送人）、产品负责人（需求池/迭代看板，当前：待指定）、交付负责人（交付看板，当前：待指定）、销售负责人（CRM 商机看板，当前：许君、李鹏为·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 每类工作有一个看板 → ② 执行人按状态机更新 → ③ 阻塞当日标红并写原因 → ④ 看板自动推送日/周摘要 → ⑤ 想知道进度先查看板 → ⑥ 看板缺失才允许问 → ⑦ 月度统计更新率公司级看板目录（需求、工单、发布、交付、商机、招聘、采购、入职、申报）；每个看板有状态定义、更新责任人与更新时限；管理层可不问人看到进度。待新建150
ALL-10SOP 变更与版本管理任何 SOP 需要新建、修订、合并、废止，或有人发现 SOP 与实际做法不一致、规则在群里被口头改变时，规定 Owner、版本号、变更流程、发布与宣贯、季度抽检；保证“只有 SOP 库里的版本算数”。主责——综合部负责人（当前：赵雪冰·部门报送人，SOP 总目录）；协同——各 SOP Owner（按部门报送人指定）、总经办运营（当前：田杰·部门报送人，SOP 例会与抽检）、研发负责人（当前：丁震宇·部门报送人，全公司版本编写牵头）；兜底——CEO（当前：待指定）① SOP 总目录登记（编号、Owner、版本、状态） → ② 变更申请（谁、为什么、改什么） → ③ Owner 修订并评审 → ④ 版本号递增、发布与宣贯 → ⑤ 旧版标废止 → ⑥ 季度抽检执行情况 → ⑦ 事故/升级触发强制修订SOP 总目录（全部编号、Owner、B 角、版本、生效日、复审日、状态、入口链接）；每次变更有变更记录；季度抽检报告。待新建240
ALL-11新人与新岗位上手新员工、实习生、借调/外包人员到岗，或在职员工转到新岗位/新项目时，规定第一天、第一周、第一月分别要拿到什么（入口表、群、看板、数据源清单、本岗 SOP、导师），让新人不用靠“问人”才能开始工作。主责——人事（当前：黄莹·部门报送人）；协同——用人部门负责人（导师指定与首周任务）、IT/安全受理岗（账号，当前：待指定）、行政（工位设备，当前：胡则瑾·部门报送人）、综合部（SOP 与制度必读包，当前：赵雪冰·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 到岗前：入职清单触发（HR-05） → ② 第 1 天：账号、群、必读包、导师 → ③ 第 1 周：本岗 SOP 清单与首周任务 → ④ 第 2 周：独立走一遍本岗主流程 → ⑤ 第 1 月：上手检查 → ⑥ 反馈回流修 SOP岗位上手包（必读清单、入口表、群清单、看板、本岗 SOP 编号、导师）；上手检查表；新人对 SOP 的反馈清单。待新建180
ALL-01工作请求提交与受理（一事一入口）待新建300

状态：待新建｜证据：有证据（卡片 24 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：任何人需要别的岗位或部门为自己做一件事（提需求、要资源、要审批、要支持、要数据、要人）时，决定“往哪里提、写什么、多久有人接”，替代在群里 @ 人或私聊口头提。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人）；协同——各入口受理岗（产品需求受理岗、售后值班岗、IT/安全受理岗、交付受理岗、财务受理岗、HR 受理岗，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 判断请求类型 → ② 按入口表选唯一入口 → ③ 按最少字段填写 → ④ 受理岗限时认领并回执 → ⑤ 补齐信息或退回 → ⑥ 转入对应 SOP 执行 → ⑦ 状态回告提出人 → ⑧ 提出人确认关闭
  • 交付结果：一张全公司“请求类型 → 入口 → 受理岗位 → 响应时限 → 对应 SOP”入口表（群公告置顶 + 知识库）；每条请求都有编号、受理人、状态和关闭记录。
  • 状态依据：全年聊天中需求、资源、账号、报修、数据等请求同时从群 @、私聊、口头、微信多路进入，受理方反复追问“哪个服务”“哪个环境”“要什么时候”，提出人反复追问“做了没”，无统一入口与回执。

1. 场景判定

  • 触发条件：（a）你要让别人（尤其是别的部门）做一件事；（b）你收到一条别人 @ 你的“帮我弄一下”类消息；（c）你发现同一件事在两个群被提了两次。
  • 典型说法：「@某某 帮我看一下」「这个谁负责」「我之前在群里说过了」「哪个服务崩了」「要什么时候」「私聊你了」
  • 判断问题：这件事需要别人投入时间去做吗？需要 → 本流程（选入口）；只是通知或闲聊 → 不走本流程。
  • 不归本流程管：产品需求的受理与分层 → 请走 X-PRD-05 / X-PRD-09 / X-FDE-02；客户问题受理 → 请走 X-CS-05；研发缺陷提报 → 请走 RND-03；资源/账号申请 → 请走 ADM-34 / X-SEC-01 / X-SEC-16 / RND-27；采购付款 → 请走 FIN-01；任务指派后的催办与闭环 → 请走 CEO-15；审批加急 → 请走 GEN-05；消息分级与响应时限 → 请走 ALL-02；卡住后的升级 → 请走 ALL-06。
  • 本流程约束/替代的已有 SOP：CEO-15（“四要素”扩展为最少字段）、GEN-03（群内沟通先查入口表）、X-PRD-05、X-CS-05、RND-01、ADM-34、X-SEC-01（它们是入口表里的具体入口，本流程只规定“必须经入口”）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
入口表维护人 维护入口表版本、每月检查入口可用性 R 总经办运营（当前：田杰·部门报送人）
入口表审批 批准新增/合并入口 A 综合部负责人（当前：赵雪冰·部门报送人）
各入口受理岗 认领、回执、补齐、分派、回告 R 产品/售后/IT/交付/财务/HR 受理岗（当前：待指定）
受理岗 B 角 受理岗缺席时接管 R 各部门指定（当前：待指定）
提出人 按最少字段提交，接受退回补齐 R 全员
部门负责人 本部门入口的响应时限达标 A 各部门报送人
自动化负责人 配置表单、机器人回执、超时提醒 C 研发指定自动化负责人（当前：待指定）
全员 知道入口表在哪 I 全员

3. 办之前请准备

  • 查入口表：知识库《请求入口表》置顶链接（建议挂飞书工作台）
  • 请求最少包含字段（缺一项受理岗可直接退回）：① 请求类型；② 一句话要做什么；③ 对象（客户简称/系统/环境/版本/账号，不写明文凭据）；④ 为什么要（业务场景或关联工单/合同编号）；⑤ 期望完成时间与依据；⑥ 紧急级别（按 ALL-02 的 P0/P1/P2）；⑦ 附件或材料所在位置（链接，不贴长截图）；⑧ 提出人岗位与可联系时段
  • 已在入口表里查过“是否已有相同请求”（需求池/工单查重）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判断请求类型，在入口表中找到唯一入口；找不到就提到“其他请求”入口 提出人 提出前 知识库《请求入口表》 已选定入口 🔧飞书固化
2 按最少字段填表单/工单；群里只贴单号或链接 提出人 提出当时 飞书表单 / 多维表格 / 审批 带编号的请求单 🔧飞书固化
3 机器人自动回执单号、受理岗、承诺首响时限 机器人 提交后即时 飞书机器人 回执消息 🤖自动化
4 受理岗认领；字段不全则一次性列出缺项退回，不逐条反问 各入口受理岗 P0 15 分钟 / P1 2 小时 / P2 1 个工作日内 请求单状态 状态=已受理 或 待补齐（缺项清单） 👤人工判断
5 补齐信息后重新提交；两次仍不全由受理岗与提出人 10 分钟通话一次性澄清，结论写回请求单 提出人 / 受理岗 退回后 1 个工作日内 请求单 补齐后的请求单 👤人工判断
6 转入对应 SOP 执行，请求单关联该 SOP 的工单/审批单编号 受理岗 受理后当日 对应 SOP 的系统 关联编号 🔧飞书固化
7 状态变化（受理/进行中/阻塞/完成/拒绝）自动回告提出人；拒绝必须写理由与替代路径 机器人 / 执行人 状态变化当时 多维表格自动化 回告消息 🤖自动化
8 提出人确认结果并关闭；3 个工作日无回应自动关闭并记录 提出人 / 机器人 完成后 3 个工作日内 请求单 状态=已关闭 🔧+🤖
9 每月统计各入口的首响达标率、退回率、入口外请求数 入口表维护人 每月 5 日前 多维表格看板 月度入口报表 🤖自动化

5. 交付物与模板

  • 交付物：《请求入口表》；请求单；月度入口报表
  • 《请求入口表》字段：请求类型、典型说法、唯一入口（链接）、受理岗位、B 角、首响时限、完成时限参考、对应 SOP 编号、最少字段清单、版本与维护人
  • 请求单字段：单号、类型、标题、对象、原因/关联编号、期望时间、紧急级别、附件链接、提出人、受理岗、状态、关联工单号、关闭说明
  • 退回缺项模板：「单号 X 缺：①…②…，补齐后重新提交即可受理」

6. 异常与升级

  • 在群里 @ 或私聊提请求，未走入口 → 受理岗回复入口链接，不在群里受理；连续 2 次由部门负责人提醒 → 部门负责人（当周）
  • 入口表里找不到对应类型 → 提到“其他请求”入口，入口表维护人 2 个工作日内补入口 → 综合部负责人（超过 2 个工作日）
  • 受理岗超首响时限未认领 → 机器人提醒 B 角接管 → 部门负责人（超时 1 倍后）
  • 同一请求在两个入口重复提交 → 受理岗合并并在原单备注 → 不升级
  • 请求被拒绝但提出人不认可 → 按 ALL-06 升级阶梯处理 → 双方部门负责人（2 个工作日内）
  • P0 请求 → 可先电话 + 入口同步补单（见 ALL-02），不得只打电话不补单

7. 衡量指标

  • 入口外请求占比：主要工作群中“@ 人提请求但无单号”的消息数 / 当期请求总数，目标优化期末 ≤ 20%（采集：每周抽 3 个主要工作群人工计数，后续由机器人识别）
  • 首响达标率：按级别在时限内认领的请求数 / 总请求数，目标 ≥ 90%（采集：请求单时间戳）
  • 一次退回率：首次提交被退回补齐的比例，目标 ≤ 25% 并逐月下降（采集：请求单状态日志）
  • 重复追问次数：同一单号下提出人“进度？”类消息数，目标平均 ≤ 1（采集：每月抽样 20 单）

8. 低效诊断

  • 现象：请求在产研主群里以 @ 的形式提出，受理方需追问“哪个服务”“哪个环境”“什么时候要”，同一问题被问 3 次以上｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08
  • 现象：需求、资源与排期请求在决策群口头提出，无单号，后续靠“我之前说过”追溯｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：项目群内“反复问何时给”类催办多次出现，提出人与执行人对期望时间无共识｜依据：「跃玩项目组」2026-07、「工程咨询产研」2026-01
  • 现象：新模型接入等请求“没人告诉我要接入”，请求未到达执行人｜依据：「Leap产研测」2026-09

9. 分支变体

  • 对外（客户/渠道）请求：先由对接人转成内部请求单，客户不直接进入内部入口；售后类走 X-CS-05。
  • 高管提出的请求：同样走入口，由总经办代填亦可，但必须有单号；不走入口的口头指令按 ALL-03 补决策记录。
  • 子公司/关联主体请求：在请求单“主体”字段注明，受理岗按 CEO-24 判断是否受理。
  • 优化期（两周内）：入口表先覆盖需求、客户问题、资源/账号、交付、采购付款、HR 六类；其他类型暂走“其他请求”入口。

10. 待确认问题

  • 入口表维护人是否由总经办运营担任？“其他请求”入口由谁受理？
  • 六类入口的受理岗与 B 角人选（当前多数为“待指定”）。
  • 首响时限 P0 15 分钟 / P1 2 小时 / P2 1 个工作日 是否可行？
  • 是否允许高管口头指令不补单？建议不允许，需 CEO 确认。
  • 机器人回执与超时提醒由哪位自动化负责人在两周内配置？
ALL-02消息分级与响应时限待新建300

状态：待新建｜证据：有证据（卡片 30 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：发出或收到一条需要别人行动的工作消息时，判断它是 P0/P1/P2、该用什么渠道（群、工单、电话）、多久必须有回应，以及什么时候不该私聊。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人（排值班与 B 角）、研发负责人（当前：丁震宇·部门报送人，告警与故障分级口径）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 发消息前定级 → ② 按级别选渠道并标注 → ③ 接收方按时限回应“收到+预计” → ④ 超时自动提醒 B 角 → ⑤ 处理结果回到原消息/工单 → ⑥ 月度统计响应时长
  • 交付结果：《消息分级与响应时限规则》（群公告 + 知识库）；每条 P0/P1 消息有可查的首响记录；私聊中的工作结论回写到群或工单。
  • 状态依据：聊天中“催办”“没人回”“私聊流转”是出现最多的低效信号；紧急与否靠口头声明，“紧急”的定义各方不一致，告警无人认领可达数小时。

1. 场景判定

  • 触发条件：（a）你要发一条需要对方做事的消息；（b）你被 @ 了；（c）你想打电话或私聊某人谈工作。
  • 典型说法：「急」「现在就要」「人呢」「@某某 看一下」「我私聊你」「没人回我」
  • 判断问题：不处理会怎样？——正在影响客户/生产/资金/演示 → P0；今天不处理会卡住别人 → P1；其余 → P2。
  • 不归本流程管：生产告警的分级与认领 → 请走 RND-78；线上故障指挥 → 请走 RND-75；客户问题首响 → 请走 X-CS-05；审批加急与关键人联络 → 请走 GEN-05；措辞礼仪与发送时间 → 请走 GEN-04；请求本身该提到哪里 → 请走 ALL-01。
  • 本流程约束/替代的已有 SOP：GEN-03（补充“级别决定渠道”）、GEN-04（补充响应时限）、CEO-15（催办前先看级别与时限）、GEN-05（P0 电话规则与之一致）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规则维护人 维护分级规则与时限表 R 总经办运营（当前：田杰·部门报送人）
规则审批 批准规则与时限变更 A 综合部负责人（当前：赵雪冰·部门报送人）
发送人 定级、选渠道、标注级别 R 全员
接收人 时限内回“收到 + 预计时间” R 被 @ 的岗位
值班/B 角 接收人超时后接管 R 各部门值班（当前：待指定）
部门负责人 本部门响应达标 A 各部门报送人
自动化负责人 超时提醒机器人 C 研发指定自动化负责人（当前：待指定）

3. 办之前请准备

  • 定级依据：影响对象（客户/生产/资金/演示/内部）与不处理的后果
  • 消息最少包含字段：① 级别标签（【P0】【P1】【P2】）；② 一句话要对方做什么；③ 对象（系统/客户简称/单号）；④ 期望回应时间；⑤ 关联链接（工单/文档）
  • 知道对方的 B 角是谁（查入口表或部门值班表）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发送前定级：P0 影响客户/生产/资金/演示；P1 今日不处理会卡住他人；P2 其他 发送人 发送前 分级规则 级别标签 👤人工判断
2 按级别选渠道：P0 = 电话 + 群内【P0】消息 + 补工单；P1 = 群内【P1】@ 岗位 + 工单；P2 = 工单/表单，不 @ 发送人 发送当时 飞书群 / 电话 / 工单 带标签的消息 🔧飞书固化
3 接收人回应“收到 + 预计处理时间”：P0 15 分钟、P1 2 小时、P2 1 个工作日（工作时间计） 接收人 按级别 飞书 首响记录 👤人工判断
4 超时未回应：机器人提醒 B 角；P0 由发送人直接电话 B 角 机器人 / 发送人 超时即刻 飞书机器人 + 值班表 提醒记录 🤖自动化
5 处理过程中进展更新在原消息回复或工单，不另开新线程；P0 每 30 分钟同步一次 接收人 按级别 原消息 / 工单 进展记录 🔧飞书固化
6 私聊中形成的工作结论，由发起方 1 小时内回写到相关群或工单 发起私聊方 结论形成后 1 小时内 群 / 工单 回写记录 👤人工判断
7 非工作时段：只有 P0 允许电话；P1/P2 次日工作时间处理 全员 持续 规则 — 👤人工判断
8 每月统计首响时长、超时数、P0 占比并通报 规则维护人 每月 5 日前 多维表格 月度响应报表 🤖自动化

5. 交付物与模板

  • 交付物：《消息分级与响应时限规则》；各部门值班/B 角表；月度响应报表
  • 消息模板：「【P1】请 @岗位 在 今天 17:00 前 处理 XX（单号/链接），影响：…」
  • 回应模板：「收到，预计 15:00 给结果；若不行会在 14:30 前说明」
  • 值班表字段：部门、主值班、B 角、可电话时段、覆盖的系统/事项

6. 异常与升级

  • 把 P2 标成 P0 以插队 → 接收人按实际影响降级并说明 → 频繁误标由部门负责人提醒（当周）
  • P0 发出 15 分钟无人回应且 B 角也不在 → 发送人电话部门负责人 → 部门负责人（即刻）；仍无 → 总经办
  • 接收人回应“收到”后长期无进展 → 按 ALL-06 升级阶梯处理 → 接收人的直属上级（超过承诺时间 1 倍）
  • 工作结论只存在私聊里被他人追问 → 由私聊发起方补回写 → 部门负责人（当日）
  • 非工作时段 P1 被电话打扰 → 允许接收人次日处理，并提醒发送人规则 → 不升级

7. 衡量指标

  • 首次响应时长：从消息/工单创建到首次“收到”的工作分钟数，按级别统计中位数，目标 P0 ≤ 15 分钟、P1 ≤ 2 小时、P2 ≤ 1 个工作日（采集：工单时间戳；群消息每月抽样 30 条）
  • 超时率：超过时限的消息占比，目标 ≤ 10%（采集同上）
  • P0 占比：标记 P0 的消息占比，目标 ≤ 10%，异常偏高说明滥用（采集：标签统计）
  • 私聊回写率：抽样私聊结论中被回写到群/工单的比例，目标 ≥ 90%（采集：每月各部门自报 + 抽查）

8. 低效诊断

  • 现象：产研主群中“人呢”“看一下”“什么进度”类催办高频出现，紧急程度靠口头声明，被 @ 者未回“收到”即无从判断是否已受理｜依据：「Leap产研测」2026-05、「Leap产研测」2026-07、「Leap产研测」2026-08
  • 现象：决策群中请求与进展在多个线程穿插，私聊结论未回群，他人“不知道”｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：进度在不同群发布、被屏蔽，接收方未看到后反复追问｜依据：「Leap产研测」2026-06
  • 现象：机器人与通知混发导致重要消息被淹没，需要人工再 @ 一遍｜依据：「模态跃迁通知群」2026-08、「模态跃迁通知群」2026-09

9. 分支变体

  • 客户群/反馈群：首响时限按 X-CS-05（工作时间 30 分钟）执行，级别由售后值班判断。
  • 生产告警：按 RND-78 的告警等级，不另打标签。
  • 高管发出的消息：同样需标级别；未标默认为 P1。
  • 跨主体/子公司：使用同一规则；值班表按主体分列。

10. 待确认问题

  • 三档时限数值是否可行？研发与售后是否需要不同档位？
  • 值班与 B 角表由各部门在两周内提交，谁汇总？
  • 超时提醒机器人在优化期内能否上线？若不能，先由部门负责人人工抽查。
  • 非工作时段 P0 的电话权限是否需要限定在值班表内的人？
ALL-03决策记录与发布待新建320

状态：待新建｜证据：有证据（卡片 18 张 / 会话 5 个）｜优先级：频4 × 耗4 × 跨5 × 险4

  • 适用场景：任何会影响他人工作的决定（方向、规则、优先级、口径、资源分配、做/不做）在会上、群里、电话或私聊中形成后，判断是否需要记录、记在哪里、怎么发布、什么时候算数。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人，决策记录表维护）；协同——各决策人（CEO、COO、CTO、各部门负责人）、综合部（制度类决策发布，当前：赵雪冰·部门报送人）；兜底——CEO（当前：待指定）
  • 核心流程：① 判断是否为“影响他人的决定” → ② 决策人或记录人 1 个工作日内写决策记录卡 → ③ 发布到相关群并置顶/进知识库 → ④ 相关方回执 → ⑤ 生效 → ⑥ 复议走正式通道 → ⑦ 季度回顾
  • 交付结果：《决策记录表》（多维表格）；每条决策有编号、选项、依据、结论、决策人、生效日、影响范围、发布链接；规则类决策进入制度库。
  • 状态依据：全年多次出现同一问题反复讨论 3～5 次、结论改口、“我讲过两遍”与“从没听说”并存；方向与规则在群聊中边聊边定，无记录，新人与机器人均查不到。

1. 场景判定

  • 触发条件：（a）会上或群里有人说“就这么定”“按这个来”；（b）优先级、规则、口径、命名、资源分配被改变；（c）有人问“到底听谁的”“之前不是说…”。
  • 典型说法：「就按这个来」「之前定的是什么」「我记得不是这样」「谁拍的板」「这个定了吗」
  • 判断问题：这个决定会不会改变别人接下来要做的事或遵守的规则？会 → 本流程记录；只影响自己 → 不记录。
  • 不归本流程管：技术/产品方案分歧的决策过程 → 请走 CEO-04；新业务立项 → 请走 CEO-03；多项目优先级与人力 → 请走 CEO-07；制度与 SOP 的起草签发 → 请走 GEN-01；全员通知发布 → 请走 GEN-02；授权矩阵本身 → 请走 CEO-05；会议纪要产出 → 请走 ALL-05。
  • 本流程约束/替代的已有 SOP：CEO-04（决策记录字段与本流程统一）、CEO-05（授权矩阵决定谁有权拍板）、GEN-01（规则只有进制度库才生效）、X-PRD-01（ADR 归入决策记录表）、X-PRD-14（口径定义是决策的一种）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
决策人 拍板，确认记录内容 A 按 CEO-05 授权矩阵对应岗位
记录人 写决策记录卡并发布（会议记录人或发起人） R 会议记录人 / 发起人
决策记录表维护人 维护表、编号、季度回顾 R 总经办运营（当前：田杰·部门报送人）
制度类发布 规则类决策进制度库并宣贯 R 综合部负责人（当前：赵雪冰·部门报送人）
相关方 回执“已阅”，按决策执行 R 受影响岗位
全员 遇到争议先查决策记录表 I 全员

3. 办之前请准备

  • 决策记录最少包含字段：① 议题；② 备选方案（至少 2 个，或写明“无备选”）；③ 结论；④ 依据（1～3 条）；⑤ 决策人；⑥ 生效日期；⑦ 影响范围（哪些岗位/产品/主体）；⑧ 明确不做什么；⑨ 复审触发条件；⑩ 记录人与发布链接
  • 查一遍决策记录表，确认不是已定事项的重开
  • 若为规则类（制度、口径、流程），准备好进制度库的版本号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 决定形成时，由记录人当场说“我来记录”，口头/群内/私聊决定一律视为“待记录” 记录人 决定形成当时 飞书 认领记录 👤人工判断
2 填写决策记录卡（最少字段），AI 可据纪要或聊天生成初稿 记录人 决定后 1 个工作日内 多维表格《决策记录表》+ AI 初稿 决策记录（编号 D-YYYYMM-NN） 🤖+👤
3 决策人在记录上确认（点“已确认”），未确认前不算生效 决策人 收到后 1 个工作日内 多维表格 状态=已确认 🔧飞书固化
4 发布：贴到受影响的工作群并置顶；规则类同步进制度库（GEN-01）；涉全员的走 GEN-02 记录人 / 综合部 确认后当日 群公告 / 知识库 发布链接 🔧飞书固化
5 相关方回执“已阅”；机器人 2 个工作日后统计未回执名单 相关方 / 机器人 发布后 2 个工作日内 多维表格 回执名单 🤖自动化
6 争议或要改：提交“复议”并附新证据，决策人 3 个工作日内答复；不得在群里直接推翻 提出复议者 / 决策人 3 个工作日 决策记录表（复议字段） 复议记录 👤人工判断
7 季度回顾：失效、被改、未执行的决策清单 决策记录表维护人 每季度末 多维表格 季度决策回顾 🤖+👤

5. 交付物与模板

  • 交付物：《决策记录表》；单条决策记录卡；季度决策回顾
  • 决策记录卡字段：编号、议题、类型（方向/规则/优先级/口径/资源/其他）、备选方案、结论、依据、决策人、记录人、生效日、影响范围、不做什么、复审条件、发布链接、回执状态、复议记录
  • 发布模板：「【决策 D-202610-03】议题…；结论…；生效…；影响…；详情链接…；请相关人回复“已阅”」

6. 异常与升级

  • 决定只在口头/私聊/群聊里，无人记录 → 任一相关方可代为填卡并 @ 决策人确认 → 决策人 1 个工作日内未确认 → 决策人直属上级
  • 两位决策人结论冲突 → 按 CEO-05 授权矩阵确定有权者；矩阵未覆盖 → CEO 裁决（2 个工作日内）
  • 已记录决策被群里“口头推翻” → 以记录表为准，提醒走复议 → 总经办运营（当日）
  • 规则类决策未进制度库就要求执行 → 按“未生效”处理，先补 GEN-01 → 综合部负责人
  • 决策影响范围写漏，导致某部门不知情 → 补发布并追加回执 → 记录人

7. 衡量指标

  • 决策留痕率：抽样会议纪要与群内“定了”类表述中有决策记录的比例，目标 ≥ 90%（采集：每月抽 10 个会议纪要 + 3 个主要群）
  • 重开次数：同一议题无新证据再次讨论的次数，目标每季度 ≤ 2（采集：决策记录表“复议”字段 + 维护人记录）
  • 确认时效：决定形成到记录被确认的工作日，目标 ≤ 2（采集：多维表格时间戳）
  • 回执率：发布后 2 个工作日内相关方回执比例，目标 ≥ 90%（采集：机器人统计）

8. 低效诊断

  • 现象：产品命名、路线、技术方案等结论在群聊中反复改口，改名导致仓库、界面、域名多次返工｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08
  • 现象：决策群里“谁批准”“谁验收”无记录，重构与计费方案变更后其他人不知情｜依据：「鼎慧产研决策部」2026-05、「Leap产研测」2026-06
  • 现象：方案“现场拍板”，运维边界与责任事后再界定｜依据：「工程咨询产研」2026-02
  • 现象：综合类规则（补贴、口径）在群里口头调整，员工反复追问以哪次为准｜依据：「【模态】综合部」2026-08

9. 分支变体

  • 产品方向类：沿用 X-PRD-01 的 ADR 模板，编号同时登记到决策记录表。
  • 技术方案类：按 CEO-04 走决策单，结论回填决策记录表。
  • 人事与薪酬口径类：只能由 HR 按 HR-01 发布，决策记录表只登记编号与链接，不展示细节。
  • 子公司决策：子公司负责人为决策人，涉及集团资源时按 CEO-24 升级。
  • 紧急决策（P0 故障中的处置决定）：先执行，24 小时内补记录。

10. 待确认问题

  • 决策记录表由总经办运营维护是否合适？编号规则是否采用 D-YYYYMM-NN？
  • “未确认前不算生效”是否会拖慢执行？是否允许决策人口头确认后 24 小时内补点确认？
  • 哪些类型的决策必须 CEO 确认？需与 CEO-05 授权矩阵同步定稿。
  • 季度回顾是否纳入 SOP 例会议程？
ALL-04跨部门交接契约待新建400

状态：待新建｜证据：有证据（卡片 26 张 / 会话 6 个）｜优先级：频5 × 耗4 × 跨5 × 险4

  • 适用场景：一件事从一个岗位/部门交给另一个岗位/部门继续做（销售→交付、产品→研发、研发→测试、交付→财务、HR→IT 等）时，规定每次交接必须说明交什么、给谁、在哪里、什么时候、验收标准、超时找谁。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人，交接定义表维护）；协同——各主线 SOP 负责人（按手册第 2 章 F1～F8 交接点）、各部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 识别交接点 → ② 交出方按“六要素”发交接单 → ③ 接收方限时确认接收或退回 → ④ 接收方按验收标准做 → ⑤ 交出方验收/关闭 → ⑥ 超时触发升级 → ⑦ 交接点定期复盘
  • 交付结果：《跨部门交接定义表》（每个交接点：交出方、接收方、交付物、位置、时限、验收标准、超时升级人）；每次交接有可查的交接单或工单字段。
  • 状态依据：全年“交接断档”“职责不清”是高频信号：合同盖章后交付不知情、提测不知道测什么、接手模块只知“皮毛”、装机依赖个人环境；交接多以群消息或口头完成，无单据无验收。

1. 场景判定

  • 触发条件：（a）你做完自己那段，要让下一个岗位接着做；（b）你收到“这个给你了”；（c）人员离岗、借调、换负责人。
  • 典型说法：「这个交给你了」「我以为你接了」「你没跟我说要测这个」「东西在哪」「谁接手」
  • 判断问题：这件事接下来由另一个人/部门负责吗？是 → 本流程；只是通知进展 → ALL-09。
  • 不归本流程管：人员离职交接 → 请走 HR-27 / RND-85 / SAL-35 / X-DLV-37 / X-PRD-40；研发工单归属 → 请走 RND-07；交付订单建群派工 → 请走 X-DLV-07；需求评审通过后交研发 → 请走 X-PRD-13；提测流转 → 请走 RND-39；任务指派与催办 → 请走 CEO-15；交接后卡住的升级 → 请走 ALL-06。
  • 本流程约束/替代的已有 SOP：手册第 2 章 F1～F8 各交接环节所涉 SOP（如 SAL-23→X-DLV-07、X-DLV-29→FIN-19、X-PRD-13→RND-06、RND-39→RND-51、X-RCT-19→HR-05/ADM-03/X-SEC-01）的交接步骤须满足六要素；CEO-15（任务四要素扩展为交接六要素）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交出方 按六要素发交接单，交付物放到指定位置 R 上游岗位
接收方 限时确认/退回，按验收标准完成，回告 R 下游岗位
交接定义表维护人 维护交接点定义、季度复盘 R 总经办运营（当前：田杰·部门报送人）
主线 SOP 负责人 定义本主线每个交接点的六要素 A 各 SOP 负责人（当前：待指定）
部门负责人 本部门作为接收方的时限达标 A 各部门报送人
自动化负责人 交接字段、超时提醒配置 C 研发指定自动化负责人（当前：待指定）

3. 办之前请准备

  • 交接单最少包含字段（六要素）：① 交什么：交付物名称与版本/编号；② 给谁：接收岗位（不是群）；③ 在哪里：交付物所在系统或位置链接；④ 什么时候：接收方需要完成的时限与依据；⑤ 验收标准：接收方做完后怎么算完成（1～3 条可检查项）；⑥ 超时找谁：接收方超时后升级到哪个岗位
  • 交付物已放到指定位置（台账/知识库/工单），不是只在群里贴文件
  • 已查《跨部门交接定义表》中该交接点的默认时限与验收标准

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 把交付物放到交接定义表指定的位置（台账/工单/知识库），不以群文件为准 交出方 交接前 对应系统 交付物链接 🔧飞书固化
2 发交接单：按六要素填写（工单字段或交接表单），群里只贴链接并 @ 接收岗位 交出方 交付物就绪当日 工单 / 多维表格交接表单 交接单（编号） 🔧飞书固化
3 接收方确认“已接收 + 预计完成时间”，或一次性列出缺项退回 接收方 1 个工作日内（P0 按 ALL-02） 交接单 状态=已接收/退回 👤人工判断
4 机器人对超时未确认的交接单提醒接收方 B 角与部门负责人 机器人 超时即刻 飞书机器人 提醒记录 🤖自动化
5 接收方执行；进展按 ALL-09 在看板/工单更新 接收方 按交接单时限 对应 SOP 系统 进展记录 🔧飞书固化
6 完成后接收方回告，交出方按验收标准 2 个工作日内验收或退回；逾期视为通过 接收方 / 交出方 2 个工作日 交接单 状态=已验收 👤人工判断
7 新增或变更交接点：主线 SOP 负责人更新交接定义表并公告 主线 SOP 负责人 变更后 3 个工作日内 《跨部门交接定义表》 新版本 🔧飞书固化
8 季度复盘各交接点的超时率、退回率，修订时限或 SOP 交接定义表维护人 每季度末 多维表格 复盘记录 🤖+👤

5. 交付物与模板

  • 交付物：《跨部门交接定义表》；交接单；季度交接复盘
  • 交接定义表字段：交接点编号、主线（F1～F8）、交出方岗位、接收方岗位、交付物、位置（系统）、默认时限、验收标准、超时升级岗位、关联 SOP（上游/下游编号）、维护人
  • 交接单字段：编号、交接点、交付物链接、交出人、接收岗位、需完成时限、验收标准、超时找谁、状态、退回原因、验收结论
  • 建议优化期先定义的交接点：线索→销售（SAL-02）、合同盖章→交付工单（SAL-23→X-DLV-07）、评审通过→研发工单（X-PRD-13→RND-06）、提测→测试（RND-39）、放行→发布（RND-51）、签收单→开票（X-DLV-29→FIN-19）、Offer→入职清单（X-RCT-19→HR-05/ADM-03/X-SEC-01）、客户问题→缺陷/需求（X-CS-13→RND-03/X-PRD-09）

6. 异常与升级

  • 口头/群消息交接、无交接单 → 接收方可不受理并回复交接表单链接 → 交出方部门负责人（当周重复出现时）
  • 接收方超 1 个工作日未确认 → 机器人提醒 B 角 → 接收方部门负责人（超时 2 个工作日）→ 总经办（超时 3 个工作日）
  • 交付物不在指定位置、只在群里 → 退回补放 → 不升级
  • 验收标准不可检查（如“做好”） → 接收方要求改写为可检查项 → 交接定义表维护人裁定（2 个工作日）
  • 接收岗位不存在或缺位（如无专职测试/售后） → 按 overview 组织级发现 4 指定临时负责人 → 总经办（1 周内）
  • 跨主体交接（子公司↔集团） → 交接单注明主体，按 CEO-24 判定资源归属

7. 衡量指标

  • 交接单覆盖率：抽样跨部门交接中有交接单/工单六要素的比例，目标优化期末 ≥ 80%（采集：每月抽 20 次交接）
  • 交接确认时效：发单到接收方确认的工作日中位数，目标 ≤ 1（采集：交接单时间戳）
  • 退回率：因缺要素被退回的比例，目标 ≤ 20%（采集：交接单状态）
  • 返工率：验收不通过需返工的比例，目标 ≤ 10%（采集：验收结论字段）

8. 低效诊断

  • 现象：模块接手人事后才被告知业务背景，提测方不知道哪些可测、代码与环境在哪｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08
  • 现象：打包、CI 等职责多次转手，依赖个人环境，交接无清单｜依据：「Leap产研测」2026-07、「Leap产研决策部」2026-09
  • 现象：项目交付链路“硬件→软件→产品→销售→客户”靠口头约定推进，节点间无单据｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：定制项目中运维边界、网络责任到现场才临时界定｜依据：「工程咨询产研」2026-01

9. 分支变体

  • 研发内部交接（开发→测试→发布）：交接单即工单字段，不另建表单，但字段须含六要素。
  • 对外交接（交给客户/渠道/供应商）：交接单内部留存，对外用签收单/验收单（X-DLV-29）。
  • 人员离岗交接：走 HR-27 等专项 SOP，其清单须覆盖该人名下所有未关闭交接单。
  • 紧急交接（P0）：先电话确认接收，30 分钟内补交接单。

10. 待确认问题

  • 交接定义表由总经办维护，还是由各主线 SOP 负责人分别维护后汇总？
  • 优化期先定义的 8 个交接点是否合适？是否需要增加“需求→FDE”“采购→付款”？
  • “逾期 2 个工作日视为验收通过”是否可接受？
  • 交接表单与工单系统是否合一？由哪位自动化负责人在两周内配置超时提醒？
ALL-05会议发起、纪要与待办闭环待优化180

状态：待优化｜证据：有证据（卡片 14 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：任何人想开会（例会、专题、评审、对齐、复盘）时，判断是否真的需要开会、怎么发起，以及会后 24 小时内如何产出决议与待办并进入任务系统。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人）；协同——各会议发起人、记录人；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 判断能否不开会 → ② 发起：目的/议程/材料/参会人/时长 → ③ 开会并开启智能纪要 → ④ 24 小时内校对纪要、决议进决策记录、待办进任务 → ⑤ 参会人回执 → ⑥ 待办跟踪关闭
  • 交付结果：带议程与材料的日程；24 小时内发布的纪要（决议 + 待办 + 责任人 + 截止日）；待办全部在任务系统可查。
  • 状态依据：已有智能纪要与日程工具，但聊天中纪要发出后仍反复问同样问题，会上决策未落工单，开会前反复 @ 催人到场、时间当日多次调整。

1. 场景判定

  • 触发条件：（a）你准备拉人开会；（b）有人在群里说“开个会对一下”；（c）会议结束，需要产出纪要。
  • 典型说法：「拉个会对一下」「人呢」「你来没」「我也要开会吗」「上次会上说的是什么」
  • 判断问题：这个问题能用一条带字段的消息或一份文档解决吗？能 → 不开会；需要多方当场决定或对齐 → 开会。
  • 不归本流程管：会议室预约与纪要归档的操作细节 → 请走 CEO-10；例会节奏与议程 → 请走 CEO-11 / RND-09 / X-PRD-30；项目启动对齐会 → 请走 CEO-09；战略研讨 → 请走 CEO-02；客户拜访纪要 → 请走 SAL-05；决策记录本身 → 请走 ALL-03；待办的催办与关闭 → 请走 CEO-15。
  • 本流程约束/替代的已有 SOP：CEO-10（本流程规定“开不开”与“24 小时闭环”，操作按 CEO-10）、CEO-11、RND-09、X-PRD-30（例会纪要须含待办并进任务）、CEO-15（会议待办是任务的主要来源之一）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 判断必要性、写议程、定参会人、会后负责闭环 A 发起会议的岗位
记录人 开启纪要、校对、拆待办、发布 R 发起人指定（默认发起人）
参会人 预读材料、准时、回执 R 受邀岗位
待办责任人 在任务系统认领并按期完成 R 纪要中指定岗位
会议规范维护人 维护模板、月度抽查 R 总经办运营（当前：田杰·部门报送人）
部门负责人 本部门会议闭环率 A 各部门报送人

3. 办之前请准备

  • 会议邀请最少包含字段：① 目的（要做什么决定/对齐什么）；② 议程（≤ 5 项，每项标“决策/对齐/通报”）；③ 预读材料链接；④ 参会人（必到/可选）；⑤ 时长（默认 30 分钟）；⑥ 记录人；⑦ 会议室或会议链接
  • 需要决策的议题已附备选方案
  • 确认不是重复会：查上次纪要与待办

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 先问“能不能不开”：可用消息/文档/评论解决的不开会 发起人 发起前 — 开会判断 👤人工判断
2 建日程并填最少字段；紧急会至少提前 2 小时，常规会提前 1 个工作日 发起人 按会议类型 飞书日程 + 会议室预约（CEO-10） 日程邀请 🔧飞书固化
3 参会人接受/拒绝并预读；不能到的指定代理 参会人 会前 飞书日程 出席状态 🔧飞书固化
4 准点开始；超过 5 分钟未到的议题相关人，发起人决定跳过或改期，不在群里反复 @ 发起人 会议开始 5 分钟内 会议 — 👤人工判断
5 开启智能纪要；每个议题结束时口头复述“结论 + 待办 + 责任人 + 截止日” 记录人 会中 飞书会议智能纪要 原始纪要 🤖自动化
6 校对纪要：决议写进决策记录表（ALL-03），待办逐条建任务并指派；纪要链接发到相关群 记录人 会后 24 小时内 飞书文档 + 任务 + 多维表格 发布的纪要与任务 🔧+🤖
7 参会人 1 个工作日内回执“已阅”，异议在纪要评论区提出 参会人 纪要发布后 1 个工作日 飞书文档评论 回执/异议 🔧飞书固化
8 待办按 CEO-15 跟踪；下次例会先过上次待办 待办责任人 / 发起人 按截止日 飞书任务 关闭记录 🔧飞书固化
9 每月抽查 10 个会议的纪要时效与待办进任务率 会议规范维护人 每月 5 日前 多维表格 月度会议报表 🤖+👤

5. 交付物与模板

  • 交付物：日程邀请；纪要；任务；月度会议报表
  • 纪要模板：会议名/时间/参会人；议题 1：结论｜依据｜决策编号；待办：事项｜责任岗位｜截止日｜任务链接；未决事项与下次议题
  • 议程模板：目的、议题（决策/对齐/通报）、材料、时长分配

6. 异常与升级

  • 会议无议程无材料 → 参会人可要求补齐后再开 → 发起人直属上级（重复 2 次）
  • 纪要超 24 小时未发 → 发起人催记录人；48 小时仍未发由发起人补 → 发起人部门负责人
  • 待办只在纪要里、未建任务 → 记录人补建 → 会议规范维护人抽查通报（月度）
  • 会议时间当日反复改动 → 改动需在日程更新并说明原因；改动 ≥ 2 次改为异步处理 → 发起人决定
  • 会上决议与既有决策记录冲突 → 按 ALL-03 走复议，不直接覆盖 → 决策人

7. 衡量指标

  • 纪要 24 小时发布率：目标 ≥ 90%（采集：纪要文档创建/发布时间 vs 日程结束时间）
  • 待办进任务率：纪要中待办有任务链接的比例，目标 100%（采集：月度抽查 10 个会议）
  • 会议待办按期完成率：目标 ≥ 80%（采集：飞书任务完成时间）
  • 无议程会议占比：目标 ≤ 10%（采集：日程描述是否含议程，月度抽查）

8. 低效诊断

  • 现象：会前反复 @ 问“人呢”“你来没”，有人不清楚自己是否需要参会，会议室临时冲突｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：智能纪要已发出，群里仍重复提问纪要中已有内容；会上决定（如模型档位）未落工单｜依据：「Leap产研测」2026-06、「鼎慧产研决策部」2026-05
  • 现象：评审会时间多次变更，架构理解需要反复对话，最终拍板人不明｜依据：「鼎慧产研决策部」2026-04
  • 现象：市场销售例会结论与跟进事项依赖口头，后续追问“上次说的”｜依据：「【模态】市场销售」2026-07

9. 分支变体

  • 研发站会：按 RND-09，不要求单独议程，但阻塞项须当日建工单。
  • 对外会议（客户/政府/合作方）：纪要内部版按本流程，对外版按 SAL-05 / CEO-17 审核后发送。
  • 高管召集的临时会：允许 2 小时内发起，但会后 24 小时闭环要求不变。
  • 复盘会：按 CEO-16，产出的行动项同样进任务。
  • 无

10. 待确认问题

  • “能用消息解决的不开会”由谁裁定？建议发起人自判，部门负责人月度抽查。
  • 默认时长 30 分钟是否合适？
  • 记录人默认是发起人，还是由总经办为管理层会议统一配记录人？
  • 会议报表是否纳入部门考核？
ALL-06卡点升级阶梯待新建300

状态：待新建｜证据：有证据（卡片 22 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：一件事卡住（无人认领、对方超时、两边意见不一致、资源不够、不知道找谁）时，规定卡多久向谁升级、升级时写什么，替代“直接找老板”或“反复在群里催”。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人）；协同——各部门负责人、各入口受理岗；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 确认已走入口且已超时限 → ② 第一级：对方 B 角/值班 → ③ 第二级：对方部门负责人 → ④ 第三级：总经办协调 → ⑤ 第四级：CEO/COO/CTO 裁决 → ⑥ 升级结果回写原单 → ⑦ 月度升级统计
  • 交付结果：每次升级有一条可查的升级记录（卡点、已做努力、需要谁决定什么、期限）；升级路径固定，越级事项被退回原路径。
  • 状态依据：“职责不清”“不知道找谁”“催办”是最高频信号之一；高管自称“人肉 RAG”，被授权人不知道自己被授权，下层继续越级请示；告警无人认领可达数小时。

1. 场景判定

  • 触发条件：（a）你的请求/交接已超过承诺时限且对方无回应；（b）两个岗位对谁负责有分歧；（c）你需要一个你无权做的决定；（d）你不知道这件事该找谁。
  • 典型说法：「这个到底谁负责」「找谁能定」「我直接问老板吧」「催了三次了」「没人管」
  • 判断问题：我是否已经走了入口（ALL-01）并等满了时限（ALL-02/ALL-04）？是 → 升级；否 → 先走入口、等时限。
  • 不归本流程管：审批加急与关键人电话 → 请走 GEN-05；生产故障指挥与升级 → 请走 RND-75 / RND-78；客户投诉升级 → 请走 X-CS-27；研发延期风险上报 → 请走 RND-08；关键节点向上汇报 → 请走 CEO-14；授权矩阵本身 → 请走 CEO-05；员工投诉举报 → 请走 GEN-19。
  • 本流程约束/替代的已有 SOP：CEO-05（升级终点以授权矩阵为准）、CEO-15（催办超期后按本阶梯升级）、GEN-05（审批类加急的电话规则）、RND-07（研发归属不清时的判定人）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
升级发起人 写升级单，按阶梯逐级升级 R 卡住的岗位
一级：B 角/值班 接管或给出时间 R 各部门值班（当前：待指定）
二级：部门负责人 裁定本部门内归属与优先级 A 各部门报送人
三级：总经办 跨部门协调，确定裁决人 R 总经办运营（当前：田杰·部门报送人）
四级：高管 按授权矩阵裁决 A CEO / COO / CTO（当前：待指定）
升级记录维护人 统计升级原因，推动修 SOP R 总经办运营（当前：田杰·部门报送人）

3. 办之前请准备

  • 升级单最少包含字段：① 卡点一句话；② 原请求/交接单编号；③ 已做过什么（找过谁、什么时候、对方说了什么）；④ 影响（谁/什么被卡、到什么时候会出问题）；⑤ 需要升级对象做什么决定或动作；⑥ 期望答复期限；⑦ 我的建议方案（可选）
  • 已确认时限确实已过（看单上的时间戳，不凭感觉）
  • 查入口表/值班表确认对方的 B 角与部门负责人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 自检：是否已走入口、是否已超时限、是否已 @ 过岗位而不是泛问 升级发起人 升级前 原单 自检结论 👤人工判断
2 一级升级：@ 对方 B 角/值班，附升级单；P0 可电话 升级发起人 超时后即刻 原单评论 / 升级表单 升级记录 L1 🔧飞书固化
3 二级升级：一级在 P0 30 分钟 / P1 4 小时 / P2 1 个工作日内无结果，@ 对方部门负责人 升级发起人 按级别 升级表单 升级记录 L2 🔧飞书固化
4 部门负责人裁定：指定执行人与时限，或说明不做的理由 对方部门负责人 P0 1 小时 / P1 1 个工作日 / P2 2 个工作日 升级表单 裁定记录 👤人工判断
5 三级升级：跨部门分歧或部门负责人超时，提交总经办，总经办按授权矩阵确定裁决人并组织 15 分钟对齐 升级发起人 / 总经办 二级超时后 升级表单 裁决人与会议 👤人工判断
6 四级：高管裁决，结果按 ALL-03 记决策记录 CEO/COO/CTO 收到后 2 个工作日内（P0 当日） 决策记录表 决策记录 👤人工判断
7 升级结果回写原请求/交接单，升级发起人关闭升级单 升级发起人 结果出来当日 原单 关闭记录 🔧飞书固化
8 越级提出的事项由高管/总经办退回到应有层级，并回复“请先找 X” 被越级的岗位 收到时 飞书 退回记录 👤人工判断
9 月度统计升级数、原因分类（无人/超时/归属不清/授权不清），归属不清超过 3 次的事项提交修 SOP 或授权矩阵 升级记录维护人 每月 5 日前 多维表格 月度升级报表 🤖+👤

5. 交付物与模板

  • 交付物：升级单；月度升级报表；由升级触发的 SOP/授权矩阵修订提案
  • 升级单字段：编号、级别（L1～L4）、卡点、原单编号、已做努力、影响、需要的决定、期望期限、升级对象、裁定结果、关闭时间、原因分类
  • 升级消息模板：「【升级 L2｜P1】卡点：…；原单：…；已找 X 于 … 无回应；影响：…；请 @岗位 在 … 前决定：…」

6. 异常与升级

  • 未走入口直接升级 → 退回先走 ALL-01 → 不升级
  • 升级对象（部门负责人）休假或外勤 → 找其 B 角（部门报送人需指定代理）→ 总经办（无代理时）
  • 两个部门负责人均认为不归自己 → 总经办 1 个工作日内指定临时归属，并记入“待裁决归属”清单 → CEO（1 周内定归属）
  • 事项涉及资金/合规/客户承诺且授权矩阵未覆盖 → 直接三级升级，不等待一二级 → 总经办当日
  • 频繁越级者 → 总经办提醒；累计 3 次通报部门负责人

7. 衡量指标

  • 升级响应时效：各级在时限内给出结果的比例，目标 ≥ 85%（采集：升级单时间戳）
  • 越级率：直接找高管的事项中被退回的比例，目标逐月下降至 ≤ 20%（采集：高管/总经办自报 + 升级单“级别跳转”字段）
  • 归属不清触发的升级数：目标每月下降，连续两月为 0 的事项视为归属已定（采集：原因分类）
  • 重复升级数：同一事项升级 ≥ 2 次，目标 ≤ 5%（采集：原单编号去重）

8. 低效诊断

  • 现象：“这个是谁负责的”“谁来定”类问题在产研群高频出现，归属靠群内临时指定｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08
  • 现象：问题在决策群直接抛给高管，高管成为所有卡点的终点，被授权人不知道自己可以决定｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-07
  • 现象：数据库等资源归属不明，多次追问后才由负责人口头指定｜依据：「Leap产研测」2026-05
  • 现象：跨主体事项“找谁”反复确认｜依据：「Leap产研决策部」2026-10

9. 分支变体

  • 生产/客户 P0：跳过一级，直接按 RND-75 / X-CS-05 指挥链；本流程只管事后记录。
  • 资金/合规类：授权矩阵有明确审批人的，走审批流而不是升级。
  • 子公司：子公司内部按子公司负责人为二级；涉集团资源按 CEO-24 进入三级。
  • 研发内部归属不清：先按 RND-07 由研发负责人判定，仍不清再进三级。

10. 待确认问题

  • 四级时限是否可行？P0 的一级/二级是否应更短？
  • 总经办是否有权指定“临时归属”？建议由 CEO 授权总经办行使，并在授权矩阵写明。
  • 每位部门负责人的代理（B 角）是谁？
  • 月度升级报表是否在 SOP 例会上通报？
ALL-07群聊治理（建群、命名、公告、归档）待优化120

状态：待优化｜证据：有证据（卡片 16 张 / 会话 6 个）｜优先级：频4 × 耗2 × 跨5 × 险3

  • 适用场景：需要新建工作群、决定某条消息发到哪个群、设置群公告、处理群混用与刷屏、项目结束归档群时启动；明确群只是沟通渠道，不是存档与受理入口。
  • 负责人：主责——综合部负责人（当前：赵雪冰·部门报送人）；协同——飞书管理员（当前：待指定）、各群群主；兜底——总经办运营（当前：田杰·部门报送人）
  • 核心流程：① 判断是否需要建群 → ② 按命名规则建群并设群主/B 角 → ③ 发布群公告（职能、入口链接、禁发事项） → ④ 按群类型发消息 → ⑤ 机器人分级降噪 → ⑥ 项目结束归档 → ⑦ 季度清理
  • 交付结果：《群职能与命名规则》；每个工作群有群公告（职能 + 入口表链接 + 禁发规则）；群台账（群名、类型、群主、B 角、状态）。
  • 状态依据：全年通知群、工作群、闲聊群与机器人消息混用，重要通知被淹没；有人发错群；群数量多、命名无规则，新人与渠道不知道去哪个群；几乎每个工作群都出现过明文凭据。

1. 场景判定

  • 触发条件：（a）有人要“拉个群”；（b）不知道消息该发哪个群；（c）群里出现闲聊、机器人刷屏或明文凭据；（d）项目结束群还活着。
  • 典型说法：「拉个群吧」「发错群了」「这个群是干嘛的」「通知被刷走了」「哪个群说的」
  • 判断问题：这个群对应哪个 SOP 或项目？没有对应 → 不建群，用已有群或工单。
  • 不归本流程管：消息分级与时限 → 请走 ALL-02；沟通礼仪 → 请走 GEN-04；全员通知发布 → 请走 GEN-02；凭据禁发与泄露处置 → 请走 X-SEC-10 / X-SEC-11；机器人上线与权限 → 请走 RND-81 / X-SEC-33；知识库归档 → 请走 GEN-12 / ALL-08；客户群运营 → 请走 OPS-14 / X-CS-01。
  • 本流程约束/替代的已有 SOP：GEN-03（本流程为其“建群/命名/公告/归档”部分的细化，GEN-03 继续管“事项该在哪说”）、GEN-02（通知群只发通知）、X-DLV-07（交付群建群按本命名规则）、RND-81（机器人通知分级）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
群规则维护人 维护命名规则、群台账、季度清理 R 综合部负责人（当前：赵雪冰·部门报送人）
群主 设公告、维护成员、纠偏、归档 R 建群人（对应 SOP 负责人或项目负责人）
群 B 角 群主缺席时管理 R 群主指定
飞书管理员 批量设置、归档操作、机器人作用域 R 飞书管理员（当前：待指定）
自动化负责人 机器人通知分级、凭据检测 C 研发指定自动化负责人（当前：待指定）
全员 按群公告使用群 I 全员

3. 办之前请准备

  • 建群申请最少包含字段：① 群类型（通知/项目/职能/客户/临时）；② 对应 SOP 编号或项目编号；③ 群主与 B 角岗位；④ 成员范围；⑤ 预计归档条件（项目结束/日期）；⑥ 是否允许机器人及其通知等级
  • 已确认没有可复用的现有群（查群台账）
  • 群公告草稿：职能一句话、入口表链接、禁发事项（凭据、客户敏感信息、闲聊）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判断是否建群：能用现有群、工单或文档评论解决的不建群 建群人 建群前 群台账 判断结论 👤人工判断
2 按命名规则建群：「类型-主体/产品-对象-用途」（如「交付-LeapCore-客户A-实施」「通知-全员」）并登记群台账 建群人 建群当日 飞书群 + 多维表格群台账 群 + 台账条目 🔧飞书固化
3 发布群公告并置顶：职能、入口表链接、本群对应 SOP、禁发事项、群主/B 角 群主 建群当日 群公告 群公告 🔧飞书固化
4 按群类型发消息：通知群只发通知（禁回复讨论，用话题/评论）；项目群发进展与请求链接；闲聊进闲聊群 全员 持续 飞书 — 👤人工判断
5 机器人按告警/待办/播报三级进不同群或话题，播报类默认静默 自动化负责人 机器人上线前 机器人配置（RND-81） 分级配置 🤖自动化
6 纠偏：偏离职能的消息由群主回复“请移至 X 群/入口”，明文凭据按 X-SEC-11 处理 群主 发现当时 飞书 纠偏记录 👤人工判断
7 项目/交付结束后 5 个工作日内：结论与文件归档到知识库（ALL-08），群改名加「已归档」并解散或只读 群主 结束后 5 个工作日内 飞书群 + 知识库 归档记录 🔧飞书固化
8 季度清理：30 天无消息的工作群通知群主确认归档；无群主的群由管理员处理 群规则维护人 / 飞书管理员 每季度 群台账 + 机器人 清理清单 🤖+👤

5. 交付物与模板

  • 交付物：《群职能与命名规则》；群台账；群公告模板
  • 群台账字段：群名、类型、对应 SOP/项目、群主、B 角、建群日、成员数、机器人、状态（活跃/已归档）、归档链接
  • 群公告模板：「本群职能：…｜对应 SOP：…｜提请求请走：入口表链接｜禁发：密码/密钥/验证码、客户敏感信息、与本群无关内容｜群主：岗位｜B 角：岗位」
  • 群类型与允许内容：通知群（仅通知与回执）、项目群（进展、请求链接、风险）、职能群（本职能受理与答疑）、客户群（按 X-CS-01）、临时群（标注到期日）

6. 异常与升级

  • 未按规则建群 → 群规则维护人要求群主补命名与公告 → 不整改 3 个工作日后由管理员归档
  • 通知群出现讨论 → 群主移至话题或项目群并提醒 → 重复由部门负责人提醒
  • 机器人刷屏 → 自动化负责人 1 个工作日内降级或改话题 → 研发负责人
  • 群内出现明文凭据 → 立即按 X-SEC-11 撤回并轮换 → IT/安全负责人（1 小时内）
  • 重要通知被淹没导致遗漏 → 改在通知群重发并要求回执（GEN-02）→ 综合部
  • 客户群与内部群成员混入 → 群主当日清理成员 → 售后/交付负责人

7. 衡量指标

  • 群公告覆盖率：工作群中有合规公告的比例，目标 100%（采集：群台账季度核对）
  • 通知群噪音率：通知群中非通知消息占比，目标 ≤ 5%（采集：月度抽样 1 周消息）
  • 发错群/移群次数：群主纠偏记录数，目标逐月下降（采集：群主自报）
  • 明文凭据告警数：目标趋近 0（采集：X-SEC-10 检测机器人）
  • 僵尸群数：30 天无消息且未归档的群，目标季度清零（采集：管理员后台）

8. 低效诊断

  • 现象：通知群同时承载通知、讨论与机器人播报，重要通知需人工再 @ 一遍｜依据：「模态跃迁通知群」2026-06、「模态跃迁通知群」2026-08、「模态跃迁通知群」2026-09
  • 现象：机器人是否应进产研主群、通知等级无规则，造成刷屏与屏蔽｜依据：「研发通知」2026-07、「跃迁AI总动员」2026-09
  • 现象：会议通知发错群，有人不清楚自己是否相关｜依据：「Leap产研测」2026-05
  • 现象：AI 探索类群与正式工作群职能重叠，信息分散｜依据：「模态AI探索小分队」2026-05

9. 分支变体

  • 客户交付群：由 X-DLV-07 自动建群，命名与公告按本流程模板；客户在群内时禁发内部信息。
  • 外部协作群（供应商/渠道/合作方）：群名加「外」，公告写明对外口径负责人（SAL-10）。
  • 子公司群：命名前缀用主体简称；集团通知是否转发由子公司负责人按 CEO-24 决定。
  • 临时群（活动/演示/大会）：建群时写归档日期，到期自动提醒归档。

10. 待确认问题

  • 命名规则「类型-主体/产品-对象-用途」是否接受？已有群是否批量改名？
  • 飞书管理员由谁担任？是否至少两人？
  • 通知群“禁止回复讨论”是否可行，还是改用话题模式？
  • 季度清理由综合部还是总经办执行？
ALL-08信息归档与单一事实来源待新建300

状态：待新建｜证据：有证据（卡片 28 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：产生或需要查找一份工作信息（客户信息、合同、订单、需求、版本、环境地址、账号台账、价格、制度、决策、文档）时，规定它只能存在哪里、谁维护、群聊与私聊中的内容如何回写；替代“翻群找”“问一下谁有”。
  • 负责人：主责——综合部负责人（当前：赵雪冰·部门报送人，数据源清单与知识库）；协同——各数据主责岗（CRM：销售；需求池：产品；工单：研发；台账：交付/IT/财务/HR）、产品负责人（内部系统归口，X-PRD-38）；兜底——总经办运营（当前：田杰·部门报送人）
  • 核心流程：① 查《单一数据源清单》 → ② 信息产生时直接写入指定位置 → ③ 群/私聊只贴链接或编号 → ④ 聊天中的结论 1 个工作日内回写 → ⑤ 其他位置只做引用不做副本 → ⑥ 月度检查副本与过期信息 → ⑦ 清单变更走审批
  • 交付结果：《单一数据源清单》（信息类型 → 唯一位置 → 主责岗位 → 编号规则 → 对应 SOP）；群公告与入口表链接到清单；每类信息只有一个主表。
  • 状态依据：全年“找不到信息”“散落”“多版本”“重复录入”高频：安装包散落群聊、环境地址靠群内检索、需求同时在工作台/代码仓库/群里维护、客户信息分散在 CRM/渠道系统/台账/周报。

1. 场景判定

  • 触发条件：（a）你刚得到一条别人以后会用的信息；（b）你要找某个东西；（c）有人在群里问“在哪”“发一下”；（d）你准备新建一张表或一个文档。
  • 典型说法：「链接发一下」「在哪」「我这里有个表」「群里翻一下」「哪个版本是最新的」
  • 判断问题：这条信息以后会被别人用到吗？会 → 写进清单指定位置；只是一次性沟通 → 不归档。
  • 不归本流程管：知识库目录与权限治理 → 请走 GEN-12；合同/制度原件档案 → 请走 GEN-11；内部系统建设归口与数据主责 → 请走 X-PRD-38；凭据保管 → 请走 X-SEC-10；环境地址与管理员账号登记 → 请走 X-SEC-09；工单状态规范 → 请走 RND-11；技术文档沉淀 → 请走 RND-86；群归档操作 → 请走 ALL-07。
  • 本流程约束/替代的已有 SOP：GEN-12（本流程定“什么放哪”，GEN-12 定“知识库怎么建”）、X-PRD-38（系统级主数据归口）、systems.md 共性底座（人员/主体/客户主数据、编号规则）、SAL-04（CRM 为客户与商机唯一来源）、X-PRD-09（需求池唯一）、X-DLV-31（已交付设备唯一台账）、X-SEC-12（对外账号台账唯一）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据源清单维护人 维护清单、审批新增主表、月度检查 R 综合部负责人（当前：赵雪冰·部门报送人）
清单审批 批准新增/合并数据源 A 产品负责人（内部系统归口，当前：待指定）与综合部负责人共同
各数据主责岗 维护本类主表的字段、权限与准确性 R CRM：销售负责人；需求池：产品；工单：研发；交付台账：交付；账号/环境台账：IT/安全；合同台账：法务；人员主数据：HR；财务台账：财务（当前：各部门报送人/待指定）
信息产生人 写入指定位置、群里只贴链接、回写聊天结论 R 全员
自动化负责人 群消息一键转单/转记录、副本检测 C 研发指定自动化负责人（当前：待指定）

3. 办之前请准备

  • 查《单一数据源清单》确认该类信息的唯一位置与编号规则
  • 写入主表的最少字段：① 编号（按清单编号规则）；② 名称/标题；③ 主责岗位；④ 更新时间；⑤ 来源（会议/聊天/系统）；⑥ 版本或状态；⑦ 关联编号（合同/订单/工单/客户）
  • 若要新建表/文档：先确认清单里没有同类主表；有则在主表加字段或视图，不另建

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 优化期内发布《单一数据源清单》第一版：至少覆盖客户/商机、合同、订单与交付、需求、缺陷与工单、版本与发布、环境与账号台账、价格、人员与主体、制度与 SOP、决策记录 数据源清单维护人 优化期第 1 周内 知识库 + 多维表格 清单 v1.0 👤人工判断
2 信息产生时直接写入主表/知识库指定目录；群和私聊只贴编号或链接 信息产生人 产生当日 对应主表 主表记录 🔧飞书固化
3 聊天中形成的结论、口径、地址、联系人岗位等，由发言人或记录人 1 个工作日内回写主表或决策记录（ALL-03） 发言人 / 记录人 1 个工作日内 主表 / 决策记录表 回写记录 🔧+🤖
4 群消息一键转记录：机器人把带标记的消息转入对应表（需求池/工单/台账）并回贴编号 机器人 即时 飞书机器人 + 多维表格 转记录条目 🤖自动化
5 其他文档/表格引用主表时只放链接或同步视图，不复制内容；发现副本的，副本持有人 3 个工作日内合并回主表 副本持有人 3 个工作日 多维表格同步视图 合并记录 🔧飞书固化
6 新建主表/系统需提交清单变更申请（信息类型、为何现有主表不满足、主责岗位） 申请人 建表前 清单变更表单 审批记录 🔧飞书固化
7 月度检查：抽查 5 类信息是否只在主表、过期记录是否标记、群内“在哪”类提问数 数据源清单维护人 每月 5 日前 多维表格 月度检查报告 🤖+👤
8 新人入职与新岗位上手时，把清单作为必读（ALL-11） HR / 导师 入职首日 知识库 阅读回执 🔧飞书固化

5. 交付物与模板

  • 交付物：《单一数据源清单》；清单变更申请；月度检查报告
  • 清单字段：信息类型、唯一位置（链接）、主责岗位、B 角、编号规则、最少字段、更新时限、权限等级（公开/内部/受限/机密）、对应 SOP、禁止放置的位置（如“群文件”）
  • 建议的 v1.0 对应关系：客户与商机 → CRM（SAL-04）；合同 → 合同台账（LEG-11）；订单与交付 → 交付订单看板（X-DLV-07/X-DLV-35）；已交付实例 → 实例台账（X-DLV-31）；需求 → 需求池（X-PRD-09）；缺陷/任务 → 工单系统（RND-11）；版本与更新日志 → 发布记录（X-PRD-35）；环境地址与管理员 → 环境台账（X-SEC-09）；对外账号 → 账号台账（X-SEC-12）；价格 → 价格主表（SAL-18/X-PRD-22）；人员与主体 → 飞书通讯录 + 主体表（HR-28/CEO-24）；制度与 SOP → 制度库（GEN-01/GEN-18）；决策 → 决策记录表（ALL-03）

6. 异常与升级

  • 群里问“在哪/发一下” → 回复清单链接或主表编号，不直接转发文件 → 不升级；同一信息月内被问 ≥ 3 次由主责岗补清单或公告
  • 发现同类信息两张表并存 → 清单维护人 5 个工作日内裁定主表，另一张转为视图或归档 → 产品负责人（内部系统归口）
  • 主表无人维护、信息过期 → 清单维护人通知主责岗 3 个工作日内更新 → 主责岗所在部门负责人
  • 聊天结论未回写被他人引用出错 → 发言人补回写并在原群更正 → 部门负责人（重复发生）
  • 受限/机密信息被放入公开表 → 立即移除并按 X-SEC-35 / HR-28 处理 → IT/安全负责人（1 小时内）

7. 衡量指标

  • “在哪/发一下”类提问数：主要工作群每周此类消息数，目标优化期末下降 50%（采集：每周抽样 3 个群人工计数）
  • 主表覆盖率：清单列出的信息类型中有唯一主表且有主责岗的比例，目标 100%（采集：清单）
  • 副本数：月度检查发现的同类并存表数，目标季度内清零（采集：月度检查）
  • 回写时效：抽样聊天结论回写到主表的工作日，目标 ≤ 1（采集：月度抽 10 条）

8. 低效诊断

  • 现象：安装包、环境地址、仓库信息散落群聊，需要时靠翻记录或问人；工作台未被使用，进度“只在群里”｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：需求与进度在多个载体并行维护，群内提问重复出现｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-05
  • 现象：项目资料与客户信息分散，新接手人找不到最新版｜依据：「工程咨询产研」2026-03、「Leap产研决策部」2026-09
  • 现象：反馈群中用户/同事反复索要链接与说明，帮助内容未沉淀为唯一入口｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09

9. 分支变体

  • 研发技术文档：主表为代码仓库 README 与知识库技术目录（RND-86），聊天中的技术结论回写到对应文档。
  • 客户敏感信息：只在 CRM/受限台账，不在群与公共文档出现；对外脱敏按 X-CS-17。
  • 子公司：可有独立主表，但信息类型与编号规则沿用清单；集团可见范围按 CEO-24。
  • 在飞书外（Agent/本地）产出的文档：按 GEN-12 导回飞书后才算归档。

10. 待确认问题

  • 清单维护人是综合部还是产品负责人（内部系统归口）？建议综合部维护清单、产品负责人审批系统级变更。
  • v1.0 对应关系中 CRM、工单、价格主表当前是否已是事实上的唯一来源？
  • “副本 3 个工作日内合并”是否可执行？历史表格如何处理？
  • 群消息一键转记录机器人能否在优化期上线？
ALL-09状态看板与进度同步待新建150

状态：待新建｜证据：有证据（卡片 15 张 / 会话 6 个）｜优先级：频5 × 耗2 × 跨5 × 险3

  • 适用场景：任何人想知道“某件事到哪了”，或执行人需要让别人知道进展时，规定用看板/工单状态替代群里追问；“问进度”应变成“查看板”，执行人按节奏更新状态而不是被动回答。
  • 负责人：主责——总经办运营（当前：田杰·部门报送人，公司级看板）；协同——研发负责人（工单看板，当前：丁震宇·部门报送人）、产品负责人（需求池/迭代看板，当前：待指定）、交付负责人（交付看板，当前：待指定）、销售负责人（CRM 商机看板，当前：许君、李鹏为·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 每类工作有一个看板 → ② 执行人按状态机更新 → ③ 阻塞当日标红并写原因 → ④ 看板自动推送日/周摘要 → ⑤ 想知道进度先查看板 → ⑥ 看板缺失才允许问 → ⑦ 月度统计更新率
  • 交付结果：公司级看板目录（需求、工单、发布、交付、商机、招聘、采购、入职、申报）；每个看板有状态定义、更新责任人与更新时限；管理层可不问人看到进度。
  • 状态依据：“一键查询进度”“啥时候能搞完”类追问在产研群高频出现；工作台未被使用，进度在不同群发布；日报散在群聊；管理层“看不到进度”。

1. 场景判定

  • 触发条件：（a）你想问“到哪了”；（b）你被问“到哪了”；（c）你的任务状态变了（开始/阻塞/完成）；（d）有人要求“同步一下进展”。
  • 典型说法：「什么进度」「啥时候能搞完」「做了没」「同步一下」「有东西做完了怎么没人发」
  • 判断问题：这件事在哪个看板上？在 → 查看板/更新看板；不在 → 先按 ALL-01 建单，使它出现在看板上。
  • 不归本流程管：研发进度跟催与延期上报 → 请走 RND-08；工单状态规范 → 请走 RND-11；日报周报 → 请走 CEO-12 / RND-10 / MKT-18 / SAL-32；交付进度盘点 → 请走 X-DLV-35；招聘进度 → 请走 X-RCT-21；任务催办 → 请走 CEO-15；关键节点向上汇报 → 请走 CEO-14；运营数据看板 → 请走 OPS-17。
  • 本流程约束/替代的已有 SOP：CEO-15（催办前先看看板）、CEO-12 / RND-10（日报周报优先由看板自动生成）、RND-11（工单状态是研发看板唯一来源）、X-PRD-30（迭代进度看板）、X-DLV-35（交付看板）、X-RCT-21（招聘漏斗看板）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
看板目录维护人 维护看板目录、公司级摘要 R 总经办运营（当前：田杰·部门报送人）
各看板主责 定义状态机、保证更新率 A 研发/产品/交付/销售/HR/财务/政策负责人（当前：各部门报送人/待指定）
执行人 状态变化当日更新，阻塞标红写原因 R 任务/工单责任岗位
查看人 先查看板再问 R 全员
自动化负责人 日/周摘要推送、超期未更新提醒 C 研发指定自动化负责人（当前：待指定）

3. 办之前请准备

  • 查看板目录，找到对应看板与状态定义
  • 状态更新最少包含字段：① 当前状态（待办/进行中/阻塞/待验收/完成/取消）；② 预计完成日期（变化时必须更新）；③ 阻塞原因与需要谁解决（阻塞时必填）；④ 最近更新时间（自动）；⑤ 产出链接（完成时必填）
  • 如果要问进度：先写明你已查看板，看板缺什么信息

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布看板目录 v1.0：每类工作一个看板，写明状态定义、主责、更新时限、查看权限 看板目录维护人 优化期第 1 周内 知识库 + 多维表格/工单系统 看板目录 🔧飞书固化
2 执行人在状态变化当日更新看板；预计完成日变化时同步更新并写原因 执行人 状态变化当日 工单 / 多维表格 状态记录 🔧飞书固化
3 阻塞：当日标红、写原因与需要谁解决，并按 ALL-06 升级 执行人 阻塞当日 看板 阻塞记录 🔧飞书固化
4 机器人每日 18:00 推送各看板摘要（新增/完成/阻塞/超期）到对应项目群，每周一推送公司级摘要到管理层 机器人 每日 / 每周 飞书机器人 摘要消息 🤖自动化
5 超过 3 个工作日未更新且未完成的条目，机器人提醒执行人与看板主责 机器人 每日检查 飞书机器人 提醒记录 🤖自动化
6 想知道进度：先查看板；看板信息足够则不问；不足则在条目评论区提问，不在群里泛问 查看人 查询时 看板评论 评论记录 👤人工判断
7 日报/周报优先由看板自动汇总生成，个人只补充看板外事项 机器人 / 执行人 按 CEO-12 节奏 AI 汇总 + 看板 日报/周报 🤖+👤
8 月度统计各看板更新率、阻塞平均停留时长、群内“进度”类提问数 看板目录维护人 每月 5 日前 多维表格 月度看板报表 🤖自动化

5. 交付物与模板

  • 交付物：看板目录；各看板；日/周摘要；月度看板报表
  • 看板目录字段：看板名、覆盖范围、系统/链接、状态定义、主责岗位、更新时限、查看权限、对应 SOP
  • 统一状态机（建议）：待办 → 进行中 → 阻塞（可回进行中）→ 待验收 → 完成 / 取消；各看板可细分但须映射到这六态
  • 建议优化期先上线的看板：需求池（X-PRD-09）、研发工单（RND-11）、发布计划（RND-50/RND-51）、交付订单（X-DLV-35）、商机（SAL-04）、客户问题工单（X-CS-05）、招聘漏斗（X-RCT-21）、采购付款（FIN-01）、入职准备（HR-05）、申报台账（POL-01）

6. 异常与升级

  • 条目不在任何看板 → 提问人要求执行人先建单 → 执行人部门负责人（当日）
  • 执行人超 3 个工作日未更新 → 机器人提醒 → 看板主责（第 5 个工作日）
  • 看板状态与实际不符导致误判 → 执行人当日更正并在评论说明 → 看板主责通报（重复 2 次）
  • 阻塞超过 2 个工作日未解决 → 按 ALL-06 二级升级 → 对方部门负责人
  • 管理层绕过看板直接群内问进度 → 执行人回复看板链接并补更新 → 不升级；看板目录维护人月度向管理层反馈看板缺失项

7. 衡量指标

  • 看板更新率：当周有状态变化的条目中按时更新的比例，目标 ≥ 90%（采集：条目更新时间戳）
  • 群内进度追问数：主要工作群每周“进度/做了没”类消息数，目标优化期末下降 50%（采集：每周抽样 3 个群人工计数）
  • 阻塞平均停留时长：阻塞状态持续的工作日中位数，目标 ≤ 2（采集：状态日志）
  • 自动摘要覆盖率：有日/周摘要的看板比例，目标 100%（采集：机器人配置）

8. 低效诊断

  • 现象：“一键查询进度”“啥时候能搞完”类追问频繁，完成的事项无人发布，工作台未被使用｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：修复进度与优先级靠群里口头问答，无看板可查｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • 现象：产品线迭代进展散在群中，管理层多次要求“同步一下”｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：销售侧商机与跟进进度靠例会口头汇报，CRM 未成为进度来源｜依据：「【模态】市场销售」2026-07

9. 分支变体

  • 研发：看板即工单系统，状态机按 RND-11，不另建表。
  • 交付：按 X-DLV-35 的环节接力状态，客户可见部分另出对外进度（不含内部阻塞原因）。
  • 客户/渠道问进度：由对接人查看板后答复，不把内部看板直接开放给客户。
  • 子公司：可用独立看板，但须登记到看板目录并向集团提供周摘要。

10. 待确认问题

  • 公司级看板目录由总经办维护是否合适？管理层周摘要发给谁？
  • 统一六态状态机能否覆盖各部门现有系统？
  • “先查看板再问”是否作为群规写入群公告？
  • 日报周报改为看板自动生成后，CEO-12 的人工填报是否保留？
ALL-10SOP 变更与版本管理待新建240

状态：待新建｜证据：有证据（卡片 20 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：任何 SOP 需要新建、修订、合并、废止，或有人发现 SOP 与实际做法不一致、规则在群里被口头改变时，规定 Owner、版本号、变更流程、发布与宣贯、季度抽检；保证“只有 SOP 库里的版本算数”。
  • 负责人：主责——综合部负责人（当前：赵雪冰·部门报送人，SOP 总目录）；协同——各 SOP Owner（按部门报送人指定）、总经办运营（当前：田杰·部门报送人，SOP 例会与抽检）、研发负责人（当前：丁震宇·部门报送人，全公司版本编写牵头）；兜底——CEO（当前：待指定）
  • 核心流程：① SOP 总目录登记（编号、Owner、版本、状态） → ② 变更申请（谁、为什么、改什么） → ③ Owner 修订并评审 → ④ 版本号递增、发布与宣贯 → ⑤ 旧版标废止 → ⑥ 季度抽检执行情况 → ⑦ 事故/升级触发强制修订
  • 交付结果：SOP 总目录（全部编号、Owner、B 角、版本、生效日、复审日、状态、入口链接）；每次变更有变更记录；季度抽检报告。
  • 状态依据：聊天中“走 SOP”“记进 SOP”“加入全公司超级 SOP”多次出现，但找不到入口文档；已有 SOP 散在群公告、wiki、个人笔记，无人维护与验收；规则口径在群里口头调整后多次改口。

1. 场景判定

  • 触发条件：（a）有人说“这个要写进 SOP”；（b）发现 SOP 写的和实际做的不一样；（c）事故复盘、升级统计或试运行产生修订项；（d）组织/系统变化导致 SOP 失效；（e）10/28 首轮报送与两周优化期内的集中修订。
  • 典型说法：「按 SOP 来」「加入 SOP」「SOP 在哪」「这个规则改了吗」「以哪版为准」
  • 判断问题：这件事要改变“大家以后怎么做”吗？要 → 走本流程改 SOP；只是一次性处理 → 不改。
  • 不归本流程管：制度与 SOP 的起草、签发、宣贯操作 → 请走 GEN-01；周期复审与废止 → 请走 GEN-18；人事制度 → 请走 HR-01；行政制度 → 请走 ADM-12；决策记录 → 请走 ALL-03；知识库目录 → 请走 GEN-12；复盘本身 → 请走 CEO-16。
  • 本流程约束/替代的已有 SOP：GEN-01（本流程规定 SOP 的 Owner/版本/变更触发，签发操作按 GEN-01）、GEN-18（季度抽检与复审合并执行）、CEO-16 / RND-86（复盘必须产出 SOP 修订项）、ALL-06（升级统计中“归属不清 ≥ 3 次”触发修订）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
SOP 总目录维护人 维护总目录、版本号规则、发布 R 综合部负责人（当前：赵雪冰·部门报送人）
SOP Owner 本条 SOP 的内容、修订、执行达标 R 各部门报送人指定的岗位（当前：待指定）
SOP B 角 Owner 缺席时代理 R Owner 指定
部门报送人 审批本部门 SOP 变更 A 各部门报送人
跨部门变更审批 影响两个以上部门的变更 A 总经办运营（当前：田杰·部门报送人）组织相关部门会签
全公司版本牵头 首轮全公司版本与协作协议（ALL-）的编写与定稿 A 研发负责人（当前：丁震宇·部门报送人）
抽检人 季度抽检执行留痕 R 总经办运营 + 互评部门负责人
全员 发现不一致时提变更申请 C 全员

3. 办之前请准备

  • SOP 变更申请最少包含字段：① SOP 编号与当前版本；② 变更类型（新建/修订/合并/废止）；③ 触发原因（事故编号/升级单/试运行记录/组织变化/其他）；④ 改什么（节号 + 改前改后）；⑤ 影响哪些岗位与 SOP；⑥ 期望生效日；⑦ 申请人岗位
  • 已查 SOP 总目录确认编号与 Owner，避免重复新建
  • 若为新建：按手册统一的 10 节模板准备初稿

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立 SOP 总目录：导入全部编号，每条指定 Owner 与 B 角，版本号从 v1.0 起 SOP 总目录维护人 10/28 首轮报送后 3 个工作日内 多维表格（SOP 总目录）+ 知识库 总目录 v1.0 🔧飞书固化
2 提交变更申请（最少字段）；群里说“要写进 SOP”的，由在场任一人代填 申请人 发现后 2 个工作日内 变更申请表单 变更单 🔧飞书固化
3 Owner 评估：接受/合并到其他变更/拒绝（写理由），并给出修订时限 SOP Owner 收到后 3 个工作日内 变更单 评估结论 👤人工判断
4 修订：AI 依据变更单生成修订稿，Owner 人工定稿；跨部门变更组织相关 Owner 会签 SOP Owner 评估后 5 个工作日内 知识库 + AI 初稿 修订稿 🤖+👤
5 版本号递增（内容变更 +0.1，结构/责任人变更 +1.0），写变更记录，旧版标“已废止”并保留 SOP 总目录维护人 定稿当日 SOP 总目录 新版本与变更记录 🔧飞书固化
6 发布与宣贯：按 GEN-01 发布，相关群公告更新，受影响岗位回执；改动涉及入口/交接的同步更新 ALL-01/ALL-04 的表 综合部 / Owner 发布后 1 周内 群公告 + GEN-02 回执名单 🔧飞书固化
7 事故复盘（CEO-16/RND-75）、升级统计（ALL-06）、试运行记录结束后，强制检查是否产生变更单；无变更需写明理由 复盘负责人 复盘后 3 个工作日内 变更申请表单 变更单或“无需变更”记录 👤人工判断
8 季度抽检：每部门抽 2 条 SOP，Owner 用真实执行留痕演示；不通过的列整改期限 抽检人 每季度末 SOP 总目录（抽检字段） 抽检报告 👤人工判断
9 SOP 月例会：过变更单积压、抽检整改、执行数据，决定下月修订重点 总经办运营 每月 飞书会议（ALL-05） 例会纪要 👤人工判断

5. 交付物与模板

  • 交付物：SOP 总目录；变更单；版本变更记录；季度抽检报告；SOP 月例会纪要
  • SOP 总目录字段：编号、名称、部门、Owner、B 角、当前版本、生效日、复审日、状态（草稿/生效/已废止/已并入）、入口链接（表单/审批/看板）、留痕位置、最近抽检结果、关联 ALL 协议
  • 变更记录字段：版本、日期、变更类型、触发原因、改动摘要、申请人、审批人
  • 版本号规则：v1.0 为 10/28 首轮报送版；两周优化期定稿为 v1.1；之后内容变更 +0.1、结构/责任人变更 +1.0

6. 异常与升级

  • 规则在群里口头改了但没有变更单 → 以 SOP 库版本为准，提醒发言人补变更单 → 部门报送人（当周）
  • Owner 超 3 个工作日未评估 → B 角代评估 → 部门报送人（第 5 个工作日）
  • 两个部门对同一 SOP 内容有分歧 → 总经办组织会签，1 周内未达成由 CEO 裁决并记决策记录
  • 同一事项存在两条 SOP → 总目录维护人提出合并，按 GEN-18 处理
  • 抽检不通过且超整改期 → 纳入部门负责人考核（按 overview 建议）→ CEO
  • 10/28 报送缺失或格式不符 → 综合部退回，部门报送人 2 个工作日内补齐 → 总经办通报

7. 衡量指标

  • Owner 覆盖率：总目录中有 Owner 与 B 角的 SOP 比例，目标 100%（采集：总目录）
  • 变更单响应时效：提交到 Owner 评估的工作日，目标 ≤ 3（采集：变更单时间戳）
  • 复盘转修订率：P0/P1 事故复盘后产出变更单或“无需变更”说明的比例，目标 100%（采集：复盘台账 vs 变更单）
  • 抽检通过率：季度抽检通过的比例，目标 ≥ 80% 并逐季上升（采集：抽检报告）
  • 口头规则率：抽样群内“以后都…”类规则表述中无变更单的比例，目标 ≤ 10%（采集：月度抽样 3 个群）

8. 低效诊断

  • 现象：“走 SOP”“加入 SOP”多次被提出，但无统一载体与入口，执行靠个人记忆｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08、「鼎慧产研决策部」2026-07
  • 现象：交付流程被口头描述为固定顺序，但无成文版本可查，每次重新解释｜依据：「鼎慧产研决策部」2026-06、「LeapCore（archived）」2026-05
  • 现象：接入站/网关的使用规则在群内公布后多次调整，口径以最后一条消息为准｜依据：「AI API」2026-09
  • 现象：规则与分工在决策群口头宣布，事后出现“已经说过”与“没听说”并存｜依据：「Leap产研决策部」2026-09

9. 分支变体

  • 人事/薪酬类口径：变更只能由 HR 按 HR-01 发布，总目录登记版本与生效月份、适用主体。
  • 子公司 SOP：子公司可有本地版本，编号加主体前缀，集团版变更是否适用由子公司负责人按 CEO-24 确认。
  • 协作协议（ALL-）：变更需总经办 + 综合部 + 研发负责人三方会签，因影响全员。
  • 优化期（10/28～两周）：变更单可简化为“试运行记录 + 修订稿”，由 Owner 直接定稿 v1.1。

10. 待确认问题

  • SOP 总目录由综合部维护、SOP 例会由总经办主持，这一分工是否确认？
  • 各部门报送人是否在 10/28 前为每条 SOP 指定 Owner 与 B 角？
  • 版本号规则是否采用？是否需要与制度库（GEN-01）的版本规则统一？
  • 抽检结果是否纳入部门负责人考核？从哪个季度开始？
ALL-11新人与新岗位上手待新建180

状态：待新建｜证据：有证据（卡片 12 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨5 × 险3

  • 适用场景：新员工、实习生、借调/外包人员到岗，或在职员工转到新岗位/新项目时，规定第一天、第一周、第一月分别要拿到什么（入口表、群、看板、数据源清单、本岗 SOP、导师），让新人不用靠“问人”才能开始工作。
  • 负责人：主责——人事（当前：黄莹·部门报送人）；协同——用人部门负责人（导师指定与首周任务）、IT/安全受理岗（账号，当前：待指定）、行政（工位设备，当前：胡则瑾·部门报送人）、综合部（SOP 与制度必读包，当前：赵雪冰·部门报送人）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 到岗前：入职清单触发（HR-05） → ② 第 1 天：账号、群、必读包、导师 → ③ 第 1 周：本岗 SOP 清单与首周任务 → ④ 第 2 周：独立走一遍本岗主流程 → ⑤ 第 1 月：上手检查 → ⑥ 反馈回流修 SOP
  • 交付结果：岗位上手包（必读清单、入口表、群清单、看板、本岗 SOP 编号、导师）；上手检查表；新人对 SOP 的反馈清单。
  • 状态依据：新人文档无成稿、带教人不明、环境变量与 README 缺失、每个新人靠人带；实习生到岗后才确认归属。

1. 场景判定

  • 触发条件：（a）Offer 接受、到岗日确定；（b）调岗/借调/新项目加入；（c）外包或驻场人员进场；（d）新人在群里问“这个在哪”“找谁”。
  • 典型说法：「新人来了谁带」「有没有文档」「环境怎么跑」「我该进哪些群」「这个找谁」
  • 判断问题：这个人是否第一次承担该岗位的工作？是 → 本流程。
  • 不归本流程管：入职手续与账号开通操作 → 请走 HR-05 / ADM-03 / X-SEC-01 / RND-21；通用入职培训与试用期考核 → 请走 HR-06 / HR-08；实习生用工 → 请走 HR-07；调岗借调审批 → 请走 HR-25；研发环境搭建 → 请走 RND-21；岗位工作交接 → 请走 RND-85 / X-PRD-40 / X-DLV-37 / SAL-35；外部人员权限 → 请走 X-SEC-06。
  • 本流程约束/替代的已有 SOP：HR-06（本流程规定“上手包”内容，培训执行按 HR-06）、HR-05 / X-SEC-01（入职清单须包含上手包项）、RND-21（研发首周任务与本流程一致）、ALL-01 / ALL-07 / ALL-08 / ALL-09（入口表、群清单、数据源清单、看板是上手包必读）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
上手流程 owner 维护上手包模板与检查表，跟踪完成 R 人事（当前：黄莹·部门报送人）
用人部门负责人 指定导师、定义首周任务与本岗 SOP 清单 A 各部门报送人
导师 第 1 天到第 1 月带教，回答“找谁/在哪” R 用人部门指定（当前：待指定）
IT/安全受理岗 到岗前账号与群就绪 R IT/安全受理岗（当前：待指定）
行政 工位设备就绪 R 行政（当前：胡则瑾·部门报送人）
综合部 全公司必读包（制度、入口表、群规则、SOP 总目录） R 综合部负责人（当前：赵雪冰·部门报送人）
新人 完成必读、首周任务、提交反馈 R 新人

3. 办之前请准备

  • 到岗通知最少包含字段（HR 发给用人部门/IT/行政）：① 姓名与岗位；② 到岗日；③ 用工主体与类型；④ 直属上级与导师岗位；⑤ 所在项目/产品线；⑥ 需要的系统与群（按岗位模板）；⑦ 首周任务由谁定义
  • 岗位上手包模板已存在（综合部维护通用部分，部门维护岗位部分）
  • 本岗 SOP 清单：从 SOP 总目录按岗位筛出的 5～15 条编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 Offer 接受后触发入职清单（HR-05），同时生成上手包任务：导师、首周任务、本岗 SOP 清单 人事 / 机器人 到岗前 3 个工作日 飞书审批/多维表格（入职清单） 上手包任务 🔧+🤖
2 用人部门负责人指定导师与 B 角，写首周任务（可独立完成的 1～3 件小事） 用人部门负责人 到岗前 2 个工作日 上手包 导师与首周任务 👤人工判断
3 第 1 天：账号、群（按 ALL-07 群清单）、设备就绪；导师 30 分钟带读必读包：入口表（ALL-01）、消息分级（ALL-02）、数据源清单（ALL-08）、看板（ALL-09）、群规则（ALL-07） 导师 / IT / 行政 到岗当日 知识库必读包 必读回执 🔧飞书固化
4 第 1 周：新人通读本岗 SOP 清单，按 SOP 完成首周任务；遇到“找谁/在哪”先查入口表与数据源清单，再问导师 新人 / 导师 到岗 5 个工作日内 SOP 库 + 看板 首周任务完成记录 👤人工判断
5 第 2 周：在导师陪同下独立走一遍本岗主流程（如提一条需求、处理一张工单、走一次交付/报销） 新人 / 导师 到岗 10 个工作日内 对应 SOP 系统 真实执行留痕 👤人工判断
6 新人提交“SOP 反馈清单”：读不懂、与实际不符、缺入口的地方 新人 到岗 10 个工作日内 变更申请表单（ALL-10） 反馈清单/变更单 🔧飞书固化
7 第 1 月：上手检查表（会用入口、会查看板、会按 SOP 走主流程、知道升级路径），由导师与部门负责人签字 导师 / 用人部门负责人 到岗 20 个工作日内 多维表格（上手检查表） 检查结果 👤人工判断
8 人事汇总上手完成率与反馈清单，交 SOP 月例会（ALL-10） 人事 每月 多维表格 月度上手报表 🤖+👤

5. 交付物与模板

  • 交付物：岗位上手包；上手检查表；SOP 反馈清单；月度上手报表
  • 上手包字段：岗位、通用必读（制度库、入口表、消息分级、群规则、数据源清单、看板目录、SOP 总目录）、岗位必读（本岗 SOP 编号清单、本岗看板、本岗主表、本岗群）、导师与 B 角、首周任务、上手检查项
  • 上手检查表（建议）：能独立提交一条请求并被受理；能查到自己任务的看板状态；能说出本岗 3 条核心 SOP 的入口与时限；知道卡住时的升级路径；完成一次真实主流程执行
  • 新人反馈清单字段：SOP 编号、问题类型（读不懂/与实际不符/缺入口/缺模板）、描述、建议

6. 异常与升级

  • 到岗当日账号/群/设备未就绪 → 导师当日按 X-SEC-01 / ADM-03 催办 → 人事（当日）→ 综合部负责人（次日）
  • 未指定导师或导师长期缺席 → 人事要求部门负责人 1 个工作日内指定 → 综合部负责人
  • 岗位无 SOP 清单（新岗位/缺位职能） → 部门负责人 1 周内从 SOP 总目录指定最接近的条目并提新建变更单 → 总经办
  • 新人在群里反复问“找谁/在哪” → 导师引导查入口表与数据源清单；若确实缺，提变更单 → 不升级
  • 外包/驻场人员 → 上手包只含授权范围内内容，权限按 X-SEC-06

7. 衡量指标

  • 到岗当日就绪率：账号、群、设备、导师、首周任务在到岗当日齐备的比例，目标 ≥ 90%（采集：入职清单状态）
  • 上手检查通过率：到岗 20 个工作日内通过检查表的比例，目标 ≥ 85%（采集：上手检查表）
  • 新人提问转化率：新人反馈清单中被转为 SOP 变更单的条数，目标每位新人 ≥ 1（采集：变更单来源字段）
  • 新人“找谁/在哪”提问数：到岗前两周在群内此类提问数，目标逐批下降（采集：导师记录）

8. 低效诊断

  • 现象：新人文档无成稿、带教人不明、入职通知只在群里，新人靠人带｜依据：「Leap产研测」2026-06、「Leap产研测」2026-05
  • 现象：开发环境缺环境变量与 README，“跑不起来”，每个新人重复踩坑｜依据：「Leap产研测」2026-07
  • 现象：实习生与新人到岗后才确认归属与派活人，招聘与用人部门衔接断档｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-03
  • 现象：新岗位（行政助理等）进群与权限、工作范围需逐次确认｜依据：「【模态】综合部」2026-07

9. 分支变体

  • 研发新人：首周任务与环境按 RND-21，必读增加 RND-30 / RND-31 / RND-32。
  • 销售/FDE 新人：必读增加 SAL-10 对外口径、SAL-04 CRM、X-FDE-02 需求入口；第 2 周主流程为“录一条商机并提交一次售前支持请求”。
  • 转岗/借调：跳过第 1 天通用必读，只做岗位必读与第 2 周主流程；原岗位交接按 RND-85 等。
  • 实习生：按 HR-07 的观察期，上手检查表在观察期中点完成。
  • 子公司：通用必读包由集团提供，岗位部分由子公司负责人维护。

10. 待确认问题

  • 上手流程 owner 由人事担任是否合适？岗位上手包的岗位部分由谁维护？
  • 首周任务“1～3 件可独立完成的小事”是否可由每个部门预先准备模板？
  • 上手检查表是否与试用期考核（HR-08）合并？
  • 新人反馈清单是否强制？建议强制，作为 SOP 修订的固定来源。

ECO 研究院生态

报送人：陈梦琪 · 生态市场条线 · 31 条 · 已有 0 / 待优化 14 / 待新建 17
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ECO-01生态活动年度规划与 ROI 取舍每月/每季度规划对外生态活动（黑客松、沙龙、训练营、大会、开源/高校合作），或收到外部活动邀约，需要决定办不办、去不去、投入多少时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，ROI 与技术选题把关）、FDE/运营（当前：李凯·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认，大会场务）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 线索入活动池 → ② 填立项卡估 ROI → ③ 分级取舍 → ④ 月度评审 → ⑤ 发布活动日历并分派 → ⑥ 选题/人力锁定 → ⑦ 活动后复盘回写经 CEO 确认的月度/季度活动日历（含每场目标、预算、ROI 预估、执行负责人）及每场活动复盘记录待优化108
ECO-02生态合作伙伴引入与内部对齐接触到新的合作方、渠道、KOL 或外部专家，需要先在内部统一理解合作模式、评估对接方式、决定关系维护动作（含赠送试用额度、开通工具账号）时启动主责——生态市场条线负责人（当前：许君·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，合作形态定性）、开放平台负责人（当前：郭逸非·推断待确认）、FDE/Skill 负责人（当前：李凯·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，工单项目与额度审批）、研发对接人（当前：邓乾·推断待确认）、运维/账号开通（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记合作线索 → ② 内部对齐会 → ③ 合作形态定性 → ④ 对齐纪要确认 → ⑤ 开工单项目 → ⑥ 外部技术对接 → ⑦ 关系维护动作 → ⑧ 台账月度更新合作伙伴台账记录 + 内部对齐纪要（合作模式、产品形态、技术投入、负责人）+ 需要研发时的工单项目待新建90
ECO-03生态资源池建设与资源对接引荐手上有新一批生态资源（活动名单、合作方名单、表格）要入池，或内部有人需要找团队/供应商/专家/设备/客户，需要从资源池匹配引荐时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——资源池系统研发（当前：邓乾·推断待确认）、开放平台/FDE（当前：郭逸非·推断待确认）、运维/域名（当前：宋祺睿·推断待确认）；审批——CEO（当前：邴龙志·推断待确认，名单对外使用）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 按模板收集资源 → ② 自动抽取转标准字段 → ③ 试导入确认 → ④ 去重打标入池 → ⑤ 需求登记 → ⑥ 匹配引荐 → ⑦ 结果回流与周汇总可检索、已去重打标的生态资源池；每条内部需求的引荐结果记录；有商机的资源转入销售线索池待新建72
ECO-04生态厂商合作申请（样机/测试卡/适配报告/认证）收到 NVIDIA、电信、国产算力（海光、壁仞、百度等）、国产 OS/CPU（统信、麒麟、飞腾、龙芯）等生态方邀请或要求，需要填申请表/评分表、领取样机或测试卡、交付适配测试报告或申请互认证书时启动主责——生态厂商对接人（当前：丁震宇·推断待确认，建议移交生态市场条线）；协同——认证对接（当前：韩诗琪、陈芷青·推断待确认）、测试（当前：杨云峰、潘浩伟·推断待确认）、IT/资产（当前：杨明学·推断待确认）、交付部署（当前：游家豪·推断待确认）、信创负责人（当前：李子遥·推断待确认）、销售/渠道（当前：闫登辉·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 登记生态机会 → ② 判断是否申请 → ③ 材料库 + AI 生成申请材料 → ④ 审阅提交 → ⑤ 跟踪批复 → ⑥ 样机入资产 → ⑦ 测试出报告/认证 → ⑧ 归档并转宣传已提交的申请表/评分表；入资产台账的样机或测试卡；适配测试报告或厂商互认证书；可用于宣传稿和投标资质的材料待优化180
ECO-05开放平台业务归属与需求路由口径开放平台/基座等业务的归属、汇报线、例会参会人不清，或市场销售对开放平台能力认知混乱、需求被错误路由时启动；同时作为销售判断“需求该进开放平台还是定制”的规则依据主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，通知与产品视角）、插件研发（当前：侯怡辰·推断待确认，开发课）、FDE 负责人（当前：李凯·推断待确认）、总经办（当前：待指定，架构与汇报登记）；裁决——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记业务归属与汇报线 → ② 绑定例会参会名单 → ③ 编制能力边界与分类决策树 → ④ 全员通识课 → ⑤ 新销售必修 → ⑥ 需求按决策树路由 → ⑦ 争议裁决 → ⑧ 季度更新业务归属与汇报登记表；《开放平台能力边界与项目分类决策树》及 FAQ；通识课课件与培训记录；需求路由记录待新建120
ECO-06开放平台 Skill/插件与第三方接入上架内部研发、FDE、外部开发者或合作伙伴要把 Skill、插件或数据源接入 LeapCore 开放平台并上架，或 LeapCore 客户端需要对接开放平台下发技能时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——插件接入技术负责人（当前：侯怡辰·推断待确认）、开放平台账号与网关（当前：吴亚军·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，架构决策）、客户端后端（当前：宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）、FDE 负责人（当前：李凯·推断待确认）、销售总监（当前：吴琪·推断待确认）、数据源评估（当前：白立新·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；计费设计——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 接入申请 → ② 分类评估（第三方过检查表） → ③ 开通开发者账号与 Key → ④ 按规范开发自检 → ⑤ 提交审核 → ⑥ 客户端联调 → ⑦ 计费鉴权打通 → ⑧ 上架通知与反馈迭代通过审核并在开放平台上架的 Skill/插件/数据源；第三方合作的接入检查表与商务条款确认记录；计费鉴权配置待优化400
ECO-07OPC 社区/商城第三方商家入驻与准入OPC 社区、智能涌现商城、智能体工坊招募外部商家/开发者入驻，或内部员工要上架自有产品，或承接地方政府 OPC/AI 产品征集需要厂商预上架时启动主责——OPC 社区/商城运营负责人（当前：陈梦琪·推断待确认）；协同——商城研发/商家对接（当前：葛家和·推断待确认）、招商与定价（当前：丁震宇·推断待确认）、厂商联系（当前：杨朋伟、刘昱潇·推断待确认）、技术对接（当前：毛鹏程·推断待确认）、准入标准修订（当前：李铭熙·推断待确认）、支付冲正（当前：吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 发布入驻须知 → ② 商家提交入驻申请 → ③ 准入评审与可用性核验 → ④ 签入驻协议 → ⑤ 定价与商品资料 → ⑥ 卡密/兑换码导入校验 → ⑦ 预上架测试 → ⑧ 上架与进度汇报 → ⑨ 结算与售后签署协议、通过准入、完成预上架测试并上架的商品；商家入驻台账；结算与售后记录；对政府主管部门的进度表待新建300
ECO-08开源社区建设、运营与产出汇报运营开源聚变 AI 社区（内容/智能体/活动征集、论坛与社群人气）、维护公司开源项目名单、汇总开源与布道产出、对接外部开源社区活动（赞助、演讲）时启动主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——开源/布道（当前：李子遥·推断待确认）、线下分享协调（当前：吴亚军·推断待确认）、运营（当前：李凯·推断待确认）、新媒体（当前：鲁周毅·推断待确认）、开源聚变技术支持（当前：宋祺睿·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、选拔赛设计（当前：黄莹·推断待确认）、推广（当前：侯明月、邓乾·推断待确认）；发起与审批——CEO（当前：邴龙志·推断待确认）；开源准入——CTO（当前：丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 季度社区运营计划 → ② 开源准入审核 → ③ 维护开源名单 → ④ 统一表单征集内容/智能体/活动 → ⑤ 内容合规审核 → ⑥ 社区日常运营 → ⑦ 每周产出汇报 → ⑧ 外部社区活动评估对接 → ⑨ 月度复盘季度社区运营计划；开源项目与贡献者名单；审核后发布的社区内容；每周开源产出周报；外部活动立项与复盘记录待优化72
ECO-09内部项目开源孵化公司内部出现小而有趣、可独立开源的 idea 或工具（如 PR 审阅 Bot、本地多模态推理网关），需要征集、筛选立项、开发、评审并定期汇报进度时启动。主责——开源孵化管理（当前：杨萌·推断待确认）；协同——技术评审/创始人兼 CTO（当前：丁震宇·推断待确认）、项目开发者（当前：李子遥、葛家和·推断待确认）、idea 来源方（当前：陈梦琪、岳阳·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 征集 idea → ② 初筛 → ③ 立项并指定唯一负责人 → ④ 需求文档与里程碑 → ⑤ 开发与自动日报 → ⑥ AI 预审 + 人工 code review → ⑦ 每周进度更新 → ⑧ 结项转发布（ECO-10）或终止通过评审、可编译可运行、带 README 的开源候选仓库，以及它在孵化看板中的完整记录（立项、里程碑、评审结论、周进度、结项结论）。待优化54
ECO-10开源项目与技术成果对外发布研发完成可对外展示的工具或技术成果（自研工具开源获客、国产硬件适配首发等），需要做首发调研、开源合规核查、建公开仓库与 README、对外推文宣传时启动。主责——开源运营/发布专员（当前：李子遥·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、技术作者（当前：杨云峰·推断待确认）、对外沟通与厂商协调（当前：常元和·推断待确认）、推文宣传（当前：刘昱潇·推断待确认）、CI/开源技术顾问（当前：吴世豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 成果登记 → ② 宣传价值判断与首发调研 → ③ 开源合规核查 → ④ 上游/厂商确认 → ⑤ 发布审批（LEG-29）→ ⑥ 建仓库与 README → ⑦ 对外口径核对 → ⑧ 公开与推文 → ⑨ 台账登记与发布后维护公司 GitHub 组织下已公开、带 README/LICENSE/贡献指南的仓库，经核对的对外推文，以及研发成果与开源项目台账中的完整记录。待新建96
ECO-11开源贡献署名、报备与统计员工以公司名义给外部开源项目提 issue/PR、需要统一署名；工作时间提交外部贡献需要报备；或领导、投资方、政府申报、对外合作需要公司开源贡献清单时启动。主责——开源贡献台账管理（当前：李子遥·推断待确认）；协同——创始人兼 CTO（统筹报送，当前：丁震宇·推断待确认）、GitHub 组织管理员（当前：王皓南·推断待确认）、技术验证（当前：宋祺睿·推断待确认）、研究院生态负责人（当前：陈梦琪·部门报送）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 统一公司 GitHub 组织与公共邮箱 → ② 署名规则执行 → ③ 工作时间外部 PR 报备 → ④ 合入后登记台账（脚本自动拉取）→ ⑤ 每周开源产出汇报 → ⑥ 报送需求按口径筛选 → ⑦ 人工核实后对外报送一份持续更新、可链接验证的“开源贡献台账”，以及按报送对象口径导出的贡献清单；外部贡献统一带公司署名标识。待新建48
ECO-12外部活动/会议参会与信息回收收到或决定参加外部社区答辩、专家评审、开源会议、技术派对、社区分享会等活动，需要选派人员、报名、准备材料，并在会后回收纪要与人脉信息时启动。主责——生态运营（外部活动对接）（当前：待指定）；协同——活动对接人（当前：杨萌·推断待确认）、研发派员决策/创始人兼 CTO（当前：丁震宇·推断待确认）、参会代表（当前：王皓南、宋祺睿、魏宗浩、李子遥·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 登记邀请 → ② 定目标与是否参加 → ③ 指定唯一带队人与参会人、报名 → ④ 征集问题、准备材料与演示 → ⑤ 日程与提醒 → ⑥ 现场参会 → ⑦ 会后 2 个工作日内出纪要 → ⑧ 人脉与线索回流 → ⑨ 产出登记外部活动登记表中一条完整记录（目标、参会人、材料、纪要链接、产出），以及回流到资源池/招聘/销售的联系人与线索。待新建54
ECO-13对外讲课、培训与布道宣讲已确认接下高校课程、政府/合作方培训、参访交流、布道宣讲、Meetup 等对外讲课场次，需要排讲师、拼装标准内容、核验案例、交付授课并回收反馈时启动；也包括内部分享材料转成外部课程。主责——外部分享负责人/讲师统筹（当前：陈梦琪·推断待确认）；协同——场次与内容要求提出/CEO（当前：邴龙志·推断待确认）、研发讲师调度/创始人兼 CTO（当前：丁震宇·推断待确认）、讲师/布道官（当前：李子遥、望政韬、王皓南·推断待确认）、内部分享组织（当前：杨萌·推断待确认）、标杆案例组长（当前：白福康·推断待确认）、参访接待（当前：杨朋伟·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 场次需求单 → ② 查讲师库档期并排班 → ③ 从标准内容包拼装课件 → ④ 案例与数据核验 → ⑤ 课件评审定版 → ⑥ 演示环境与物料就绪 → ⑦ 授课 → ⑧ 反馈回收与内容包更新 → ⑨ 讲师工作量登记按时、按听众定制完成的授课场次，定版课件归档，反馈与新 FAQ 回填到标准内容包，讲师工作量入台账。待优化108
ECO-14高校/校园生态合作与校园大使围绕高校与 OPC 平台开展校园合作（算力赞助、补贴券推广、校园大使招募与邀请码分润、全员转发引流）时启动。主责——校园生态运营（当前：陈梦琪·推断待确认）；协同——高校/政府关系与方向拍板/CEO（当前：邴龙志·推断待确认）、算力赞助方案（当前：李凯·推断待确认）、校园大使招募执行/行政（当前：侯明月、丁蕊·推断待确认）、邀请码需求/产品（当前：杨萌·推断待确认）、开发（当前：张康·推断待确认）、测试（当前：张东郅·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 合作立项（目标、高校、预算、KPI）→ ② 赞助/补贴/分润规则发布 → ③ 校园大使招募与高校覆盖 → ④ 邀请码与分润系统上线（含压测）→ ⑤ 统一素材包与全员转发 → ⑥ 补贴/算力发放 → ⑦ 月度提成结算与提现 → ⑧ 月度复盘已立项的校园合作计划、在岗校园大使名单与高校覆盖看板、可追踪的邀请码推广数据、经财务核对的补贴与提成发放记录、月度复盘。待新建180
ECO-15黑客松与开发者/内部 AI 赛事筹办计划举办对外黑客松（开发者用 LeapAll 做 Skill/Agent）或内部 AI 赛事（LeapAgent 赛马等），需要确定赛制、评分权重、参赛环境、赛事群运营和奖励发放时启动。主责——赛事组织负责人（当前：杨萌·推断待确认）；协同——方案把关与技术资源/创始人兼 CTO（当前：丁震宇·推断待确认）、积分总额与奖项拍板/CEO（当前：邴龙志·推断待确认）、评测（当前：张东郅·推断待确认）、研发驻场（当前：岳阳、王皓南·推断待确认）、评委（当前：李铭熙·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① 赛事立项（目标、对象、规模、预算/积分总额）→ ② 赛制与评分规则发布 → ③ 参赛环境与教程 → ④ 评测机与评测集 → ⑤ 报名与赛事群运营 → ⑥ 比赛执行与驻场 → ⑦ 评审打分 → ⑧ 公示与申诉 → ⑨ 奖励发放 → ⑩ 复盘完成的赛事、公示的评审结果、发放完毕并入账的积分或奖金、赛事复盘（含可复用的赛制与评分模板）。待新建96
ECO-16生态大会立项与总体筹备CEO 决定举办生态大会、理事会、股东会或专场大会，需要立项、定总体方案与议程、组建筹备组、邀请人清单、报名网站、全员动员与调休安排时启动。主责——大会项目经理/总协调（当前：赵雪冰·推断待确认）；协同——CEO（定目标与方向，当前：邴龙志·推断待确认）、联合创始人（大会主方向与上台，当前：常元和·推断待确认）、创始人兼 CTO（研发资源与全员通知，当前：丁震宇·推断待确认）、方案与嘉宾邀请（当前：李鹏为·推断待确认）、展区统筹（当前：杨萌·推断待确认）、发布会内容（当前：王皓南·推断待确认）、演示环境（当前：宋祺睿·推断待确认）、物料与接待（当前：侯明月·推断待确认）、资料记录（当前：董蓝汐·推断待确认）、报名网站（当前：葛家和·推断待确认）、外部活动对接（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）① CEO 立项（目标、定位、日期、预算）→ ② 指定唯一项目经理与模块负责人 → ③ 总体方案与议程 → ④ 邀请人清单 → ⑤ 报名网站与入场 → ⑥ T-3 内容冻结 → ⑦ 全员动员与调休通知 → ⑧ 彩排 → ⑨ 现场执行 → ⑩ 会后考勤、费用与复盘按里程碑完成的大会（立项单、总体方案、议程、邀请清单、报名名单、全员通知、彩排记录），以及会后费用归集与复盘报告。待新建200
ECO-17大会任务分工与进度跟踪公司确定举办生态大会、研究院大会等大型对外活动并进入倒计时（约活动前 30 天）后，需要把议程拆成任务清单、落实到人，并按天跟踪进度与风险。主责——大会总统筹（总经办）（当前：赵雪冰·推断待确认）；协同——产品展区模块负责人（当前：杨萌·推断待确认）、生态活动与物料模块负责人（当前：陈梦琪·推断待确认）、邀约与运营模块负责人（当前：李凯·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项并书面指定拍板人 → ② 按议程拆任务清单 → ③ 指定模块第一负责人与 DDL → ④ 启动会 → ⑤ 每日更新进度 → ⑥ 日会只过红黄项 → ⑦ 阻塞与拍板升级 → ⑧ 活动前 2 天查漏补缺 → ⑨ 会后关闭任务并移交复盘一张覆盖所有模块的大会任务看板（任务-负责人-截止日-状态-风险-链接）、日会纪要与决策记录、会后任务关闭清单与费用汇总。待优化250
ECO-18大会嘉宾邀约与嘉宾资料收集大会立项后，需要确定并邀请政府、高校、企业嘉宾，收集嘉宾名单、职务、照片、演讲材料、圆桌问题，并产出座次图与席卡。主责——嘉宾邀约与资料总口（生态市场总监）（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、各条线邀请人（当前：闫登辉、杨朋伟、刘昱潇、吴琪、陈梦琪·推断待确认）、行政（当前：侯明月·推断待确认）、产品经理（当前：陈震·推断待确认）、商务（当前：杨朋伟、裴建武·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 发嘉宾名单表按条线分派 → ② 各条线填报 → ③ 拍板邀请名单 → ④ 统一邀约口径与节奏 → ⑤ 发出邀请并登记状态 → ⑥ 表单收集嘉宾资料 → ⑦ 圆桌问题提前发嘉宾 → ⑧ 座次图/席卡定稿 → ⑨ 活动前 1 天终核已确认的嘉宾名单（含邀请人、状态）、完整嘉宾资料库（职务/照片/演讲材料/圆桌问题）、唯一版本的座次图与席卡。待优化160
ECO-19大会演示场景与 Demo 准备大会、发布会或渠道/客户演示前，需要确定演示场景与案例、编写各产品演示流程与 QA、开发活动互动 Demo，并交付产品材料与演示视频。主责——产品总监（当前：杨萌·推断待确认）；协同——场景总包（当前：王皓南·推断待确认）、各产品演示文档负责人（当前：宋祺睿、刘昱潇、李铭熙·推断待确认）、活动 Demo 第一负责人（当前：陈梦琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、视频剪辑（当前：李宣昊·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 明确受众与场景候选 → ② 拍板场景清单 → ③ 内容合规筛查 → ④ 活动 Demo 需求定稿与原型评审 → ⑤ 开发、跑通与回归 → ⑥ 演示流程与 QA 文档 → ⑦ 演示环境选择与安全确认 → ⑧ 录屏保底与素材归档 → ⑨ 搭建前最终走查演示场景库（场景-步骤-素材-测试状态-录屏）、各产品现场演示流程与 QA 文档、可运行的活动 Demo、统一规格的演示视频与保底录屏。待新建375
ECO-20大会物料评审、定稿与采购大会筹备期，视觉、手册、展板、PPT、视频及身份卡、积分卡、礼品等物料需要统一归集、集中评审定稿、做成本数量决策并采购制作、现场发放。主责——物料评审组织人（总经办）（当前：赵雪冰·推断待确认）；协同——各物料负责人（当前：杨萌、陈梦琪、陈震、许君、闫登辉·推断待确认）、素材库与命名规范维护（当前：李凯·推断待确认）、询价采购（当前：潘浩伟、葛家和·推断待确认）、积分卡技术方案（当前：张东郅·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 建物料清单 → ② 统一归集与命名 → ③ 提交初稿 → ④ 一日一审集中评审 → ⑤ 修改复审并记录结论 → ⑥ 品牌合规检查 → ⑦ 成本数量决策 → ⑧ 下单打样与验收 → ⑨ 定稿打包交制作 → ⑩ 现场发放与遗留登记唯一的定稿物料包（含版本记录）、采购/制作验收单、积分卡等物料发放记录。待优化128
ECO-21大会展区硬件、搭建彩排与现场执行大会前一周至当天，需要借用/验收/装机演示机、确认现场电力网络、安排展区值守与交接、运输搭建、彩排清场、签到引导及现场故障响应。主责——现场执行负责人（总经办）（当前：赵雪冰·推断待确认）；协同——展区负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、外设与运输（当前：闫登辉·推断待确认）、活动码负责人（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 设备清单与借用登记 → ② 验收装机与配置 → ③ 会场电力网络确认 → ④ 展区排班与话术交接 → ⑤ 活动码清单与压测 → ⑥ 彩排 → ⑦ 装箱清点与运输搭建 → ⑧ 当天清场、签到、现场响应 → ⑨ 设备归还与调休登记设备清单与借还台账、装机验收记录、展区排班与交接确认、彩排记录、现场执行清单、会后设备归还验收单。待新建200
ECO-22培训营报名筛选、分层与名单管理FDE 等培训营报名问卷持续涌入（千人级）时，需要按准入标准评分并分为初/中/高级，确定班级规模与落选去向，维护唯一名单，并向主管部门和领导汇报报名看板。主责——培训营统筹（生态组负责人）（当前：陈梦琪·推断待确认）；协同——FDE 评分执行（当前：佘天禾·推断待确认）、准入标准与复核（当前：郭逸非·推断待确认）、评分标准校准（当前：吴亚军·推断待确认）、筛选 SOP 文档（当前：谭涛·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 开班前定准入标准、比例与容量 → ② 建唯一名单源 → ③ AI 按规则打分分层 → ④ 人工复核与特殊人员判断 → ⑤ 定班级规模与分流标签 → ⑥ 输出带版本的入选名单 → ⑦ 生成报名看板并评审发布 → ⑧ 新增报名后增量重跑唯一在线名单（含分数、分层、分流标签、变更记录）、首批入选名单、报名数据看板（总览 + 分层，隐藏分数）。待优化108
ECO-23学员分班、批次分配与特殊插班培训营名单确定后，需要按行业分批分班（每班约 100 人）并录入报名系统，处理销售/领导/政府推荐的插班、同事同班、旁听，以及统一“为什么没进首批/为什么在初级”的对外口径。主责——分班负责人（FDE 教务）（当前：佘天禾·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、名单清洗（当前：谭涛、蔡鸿坤、侯晨帆·推断待确认）、系统导入（当前：邓乾·推断待确认）、销售侧（当前：韩诗琪、朱文瑜·推断待确认）、口径制定（当前：陈梦琪·推断待确认）；兜底——开放平台负责人（当前：郭逸非·推断待确认）① 发布分班规则 → ② 按行业拆表清洗 → ③ 标记特殊人群 → ④ 分批分班与人数平衡 → ⑤ 特殊通道插班 → ⑥ 人工复核终审 → ⑦ 导入报名系统并生成自助查询 → ⑧ 发布对外口径与 Q&A → ⑨ 调班与二次分班各批次各班名单（已录入生态资源池 SaaS）、自助查询页、特殊通道登记表、对外口径与 Q&A 更新。待优化108
ECO-24学员外联确认、台账与候补补位培训营批次名单确定后，需要电话邀约确认、批量短信通知、协调兼职外包、实时记录联系台账并核实进群，对放弃或联系不上的名额进行候补补位。主责——外联组长（当前：谭涛·推断待确认）；协同——培训营统筹（当前：陈梦琪·推断待确认）、电话外联（当前：蔡鸿坤·推断待确认）、官微与拉群（当前：侯晨帆·推断待确认）、名单与统计（当前：佘天禾·推断待确认）、支援外联（当前：韩诗琪、丁蕊、汪家诺·推断待确认）、短信通道技术（当前：邓乾、宋祺睿·推断待确认）、人事（兼职招募）（当前：待指定）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 一页版外联 SOP → ② 人手与兼职到位 → ③ 名单分配 → ④ 电话确认 → ⑤ 合规短信通知 → ⑥ 实时记台账 → ⑦ 进群核实与每日汇总 → ⑧ 缺口候补补位 → ⑨ 开课前锁定名单每班确认参加并已进群的锁定名单、完整联系台账（意向/进群/备注）、每日汇总报告、候补补位记录。待优化256
ECO-25学员答疑、班级群与自助查询培训学员确认入选后，需要加官微、进班级群、接收通知、提问答疑，或自助查询分班、上课时间地点和群二维码主责——生态运营（官微与 Q&A）（当前：侯晨帆·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、开放平台负责人（课程/考核答疑）（当前：郭逸非·推断待确认）、LeapAll 服务端研发（查询页）（当前：邓乾·推断待确认）、FDE 成员（Q&A 接机器人）（当前：佘天禾·推断待确认）、AI 讲师/助教（当前：梅立·推断待确认）；兜底——研究院生态负责人（当前：陈梦琪·推断待确认）① 入选通知 → ② 加官微并拉入班级群 → ③ 配置查询页 → ④ 收集问题进待答池 → ⑤ 分派责任人答复 → ⑥ 入库 Q&A 并同步机器人 → ⑦ 课前须知/FAQ 更新下发学员全部进入对应班级群；查询页信息准确可自助查询；唯一一份持续更新的 Q&A 文档及接入客服机器人的知识库；每批次的课前须知 PDF待优化180
ECO-26培训/课程实操环境与算力容量准备高校课程、FDE 培训、大型活动需要学员现场或远程实操 LeapCore 时，需要提前完成并发容量评估、网络接入方案、设备采购、预测试和现场技术保障主责——培训技术保障负责人（当前：待指定）；协同——IT 运维/网管（当前：杨明学·推断待确认）、Leap 研发/技术负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、交付/IT（当前：李奎星·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）；方案与采购审批——创始人兼 CTO（当前：丁震宇·推断待确认）；预算审批——CEO（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交活动需求单（≥ 2 周前）→ ② 容量与接入方案评估 → ③ 方案拍板与采购 → ④ 部署与账号分发 → ⑤ 提前 1 周压测 → ⑥ 前一天踩点 → ⑦ 现场保障 → ⑧ 回收与复盘经压测验证的实操环境（设备、网络、账号、模型额度）、学员接入文档、现场保障检查表与值守排班、活动后的回收记录与压测/故障结论待新建250
ECO-27开班仪式与线下培训会务筹备线下培训（大课+小班实操）或开班仪式开课前，需要落实活动方案、场地、物料、人员分工，并邀请专家、学员代表与领导出席主责——研究院生态负责人（活动总协调）（当前：陈梦琪·推断待确认）；协同——行政助理/会务（当前：丁蕊·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、销售运营/销售支持（助教排班）（当前：韩诗琪·推断待确认）、生态运营（名单文档）（当前：谭涛·推断待确认）、FDE 成员（筛名单）（当前：佘天禾·推断待确认）、会务（当前：郭昊·推断待确认）、生态运营（官微）（当前：侯晨帆·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、CEO（政府表述确认）（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 开课前 3 周立项与清单 → ② 活动方案与分工 → ③ 嘉宾与学员代表邀请 → ④ 物料设计制作 → ⑤ 场地踩点 → ⑥ 学员通知与助教排班 → ⑦ 前一天彩排检查 → ⑧ 当天执行细化到个人的活动方案、嘉宾与学员代表出席名单、物料到位清单、踩点检查表、助教排班表、学员通知（场地指引、培训通知）待优化160
ECO-28培训结营复盘与学员转化每批线下培训结束后，复盘活动问题，回访学员并把有需求的学员转化为客户、渠道伙伴或孵化对象，交接给销售或长期运营主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——研究院生态负责人（收集与回访）（当前：陈梦琪·推断待确认）、AI 讲师/助教（长期运营）（当前：梅立·推断待确认）、AI 讲师/班主任（当前：张家瑞·推断待确认）、CEO（转化方向）（当前：邴龙志·推断待确认）、销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 结营当天发反馈问卷 → ② 3 个工作日内召开复盘会 → ③ 回访学员并分类 → ④ 商机线索推送销售 → ⑤ 孵化/伙伴对象转对应团队 → ⑥ 学员群转长期运营 → ⑦ 改进项落到下批 SOP复盘纪要与改进项待办、学员分类回访台账、推送给销售的商机线索、长期运营交接记录待新建72
ECO-29生态合作伙伴台账、分级与年度评估退出生态伙伴（芯片/信创厂商、开发者团队、高校社团、开源社区、KOL、OPC 商家）完成引入后，需要统一登记、分级给权益、定期评估与退出时启动主责——生态运营专员（当前：待指定）；协同——品牌（当前：待指定）、财务（当前：待指定）、销售对接人（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 入库登记 → ② 分级标准 → ③ 季度分级评审 → ④ 权益兑现跟踪 → ⑤ 年度贡献评估 → ⑥ 升降级/续约/退出决定 → ⑦ 退出收尾 → ⑧ 台账更新生态伙伴台账（含级别、权益、成本、贡献）、年度评估结论、退出收尾记录待新建72
ECO-30线下活动安全预案、报备与现场应急举办生态大会、黑客松、培训开班、沙龙、校园活动等线下活动，尤其人数较多、在外部场馆或通宵进行时启动主责——活动安全负责人（当前：待指定）；协同——行政（当前：待指定）、法务（当前：待指定）、IT/网络（当前：待指定）、品牌（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 规模评估与报备判断 → ② 场地安全条款 → ③ 编制安全预案 → ④ 购买保险 → ⑤ 现场安全分工 → ⑥ 活动前安全检查 → ⑦ 现场突发处置 → ⑧ 事件记录复盘安全预案、报备/许可回执（如需）、保单、现场应急联络表、事件记录待新建180
ECO-31产学研/校企合作立项、协议与成果归属与高校、科研院所共建联合实验室、实习实践基地、横向课题、共建课程，或研究院对外开展合作研发时启动主责——产学研合作专员（当前：待指定）；协同——法务专员（当前：待指定）、研发负责人（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）① 合作提议登记 → ② 评估立项 → ③ 协议起草（知识产权、署名、保密、经费、学生管理） → ④ 用印签署 → ⑤ 执行与经费拨付 → ⑥ 成果登记与权属申请 → ⑦ 年度评估续约/终止 → ⑧ 归档立项审批、合作协议、成果登记表、年度评估与档案待新建96
ECO-01生态活动年度规划与 ROI 取舍待优化108

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：每月/每季度规划对外生态活动（黑客松、沙龙、训练营、大会、开源/高校合作），或收到外部活动邀约，需要决定办不办、去不去、投入多少时启动
  • 负责人：主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，ROI 与技术选题把关）、FDE/运营（当前：李凯·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认，大会场务）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 线索入活动池 → ② 填立项卡估 ROI → ③ 分级取舍 → ④ 月度评审 → ⑤ 发布活动日历并分派 → ⑥ 选题/人力锁定 → ⑦ 活动后复盘回写
  • 交付结果：经 CEO 确认的月度/季度活动日历（含每场目标、预算、ROI 预估、执行负责人）及每场活动复盘记录
  • 状态依据：已有策划方案、活动方案文档和需求表，但缺 ROI 评估模板，规划时先列活动再补估 ROI；04～07 月约 6 次规划讨论中出现场务临时补人、出题与需求表衔接不一致约 3 次

1. 场景判定

  • 触发条件：季度/月度规划节点；收到外部大会、沙龙、高校/开源社区合作邀约；内部提出要办黑客松、训练营
  • 典型说法：「先预估一下 ROI」「大会和转化率低的会少参加，明确结果导向」「下两个月搞哪几场活动、核心目标是什么」「现阶段先收集想法，不要求写得很完整」
  • 判断问题：这件事是否需要公司投入人/钱/时间去办或参加一场对外活动？是否还没定“办不办、办几场”？是 → 本流程；已经定了要办 → 走对应执行 SOP（黑客松 ECO-15、大会 ECO-16～21、培训营 ECO-22～28）
  • 不归本流程管：黑客松具体执行 → 请走 ECO-15；大会筹备与现场 → 请走 ECO-16～21；培训营执行 → 请走 ECO-22～28；开源社区日常运营 → 请走 ECO-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动池维护与规划牵头 收集线索、组织立项卡、出活动日历草案、组织复盘 R 研究院生态负责人（当前：陈梦琪·推断待确认）
预算与优先级拍板 定活动分级、核心目标、批预算 A CEO（当前：邴龙志·推断待确认）
ROI 与技术选题把关 审 ROI 估算、审黑客松选题与内部需求衔接 C CTO（当前：丁震宇·推断待确认）
宣发与物料 开场 PPT、营销物料、招募宣传 C FDE/运营（当前：李凯·推断待确认）
场务与人力排班 大会场务分工、展区排班 C 综合部负责人（当前：赵雪冰·推断待确认）
活动发起与执行 填立项卡、锁定排班、活动后复盘回写 R 活动发起人/执行负责人（按场次指定）
兜底 主责缺位时接手规划与评审召集 I 生态市场条线负责人（当前：许君·推断待确认）

3. 办之前请准备

  • 活动线索：活动名称、主办方、时间地点、预计受众规模与构成
  • 目标：招聘/获客线索/品牌/生态合作，至少写一个可量化目标
  • 投入估算：预算、所需人力（人·天）、是否需研发出题或演示
  • 历史数据：同类活动上次的线索数、转化数、复盘结论
  • 内部需求表（黑客松类）：各组可开放的开发需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 外部邀约、内部想法、高校/开源合作统一登记进活动池 任何收到线索的人 → 研究院生态负责人 收到线索后 2 个工作日内 飞书多维表格“活动池” 活动线索记录 🔧飞书固化
2 为每条候选活动填立项卡（目标、受众、预算、人力、预期线索/转化、ROI 估算） 活动发起人 登记后 3 个工作日内 多维表格立项卡表单 立项卡 🔧+🤖
3 按高/中/低分级；转化率低的大会默认不参加，除非有明确生态/政府目标 研究院生态负责人 每月最后一周 活动池视图 分级草案 👤人工判断
4 月度规划评审：CTO 审 ROI 与技术投入，CEO 拍板预算与取舍 CEO、CTO 月度规划会当场 飞书会议 评审结论 👤人工判断
5 发布活动日历，每场指定执行负责人，按类型分派执行：黑客松 ECO-15、大会 ECO-16～21、培训营 ECO-22～28 研究院生态负责人 评审后 1 个工作日内 飞书日历/任务 活动日历、任务 🔧飞书固化
6 技术类活动：收集各组内部需求，转为赛题草稿 研究院生态负责人 活动前 3 周 需求表 + AI 生成 赛题草稿 🤖自动化
7 锁定人力与场务排班，缺口提前上报 执行负责人、综合部 活动前 5 个工作日 排班表 排班表 🔧飞书固化
8 活动复盘：实际投入、线索、转化对比预估，回写活动池 执行负责人 活动后 5 个工作日内 复盘模板 复盘记录 🔧+🤖

5. 交付物与模板

  • 交付物：月度/季度活动日历；每场立项卡；每场复盘记录
  • 建议模板/表单：活动立项卡（活动名、类型、日期、地点、主办方、目标类型、量化目标、受众、预算、人力人·天、预期线索数、预期转化数、ROI 估算、执行负责人、分级、评审结论）；活动复盘表（实际投入、实际线索/简历/合作数、转化数、ROI 实际值、问题、下次是否参加）

6. 异常与升级

  • 临时出现高价值活动（未在日历内）→ 走简化立项卡，主责 1 个工作日内评估 → 升级 CEO 拍板（2 个工作日内）
  • 活动前 5 个工作日人力仍有缺口 → 执行负责人上报 → 综合部负责人协调（1 个工作日内）
  • 选题与内部需求对不上 → 主责召集需求方与 CTO 对齐 → CTO 定稿（3 个工作日内）
  • 涉及开源合作、高校共建协议 → 先过法务 → 升级生态市场条线负责人

7. 衡量指标

  • 立项卡覆盖率 = 已办/已参加活动中有立项卡的比例，目标 100%
  • 复盘按时率 = 活动后 5 个工作日内完成复盘的比例，目标 ≥ 90%
  • 单场线索成本 = 活动总投入 ÷ 有效线索数，按活动类型逐季对比
  • 计划内活动占比 = 日历内活动数 ÷ 全部活动数，目标 ≥ 80%
  • 排班提前锁定率 = 活动前 5 个工作日已锁定排班的场次占比，目标 100%

8. 低效诊断

  • 现象：立项环节没有 ROI 模板，先列活动再补估 ROI，取舍依据靠口头｜依据：「【模态】生态组」2026-06
  • 现象：大会场务分工未提前锁定，现场缺人到前一晚才补人（排班环节事后补流程）｜依据：「【模态】生态组」2026-06
  • 现象：黑客松出题标准与内部需求表衔接口径不一，需求收集后二次加工｜依据：「【模态】生态组」2026-06、「【模态】生态组」2026-07
  • 现象：高校/开源社区合作靠个人社群推进，营销物料没有统一库，需要临时索要｜依据：「跃迁AI总动员」2026-06
  • 现象：开源 idea 征集、黑客松邀请分散在不同通知里，没有进入统一活动池｜依据：「跃迁AI总动员」2026-06、「跃迁AI总动员」2026-07

9. 分支变体

  • 黑客松：需额外完成内部需求→赛题转换，执行转 ECO-15
  • 大会/生态大会：需全员动员、场务分工、展区排班，执行转 ECO-16～21
  • 训练营：执行转 ECO-22～28
  • 沙龙/竞赛：按立项卡简化评估，预算低于审批阈值可由主责直接决定（阈值待定）
  • 开源/高校社区合作：涉及开源合规，需法务提前介入
  • 外部受邀参加的活动：只做“参加与否 + 派谁去”的取舍，不需出方案

10. 待确认问题

  • 主责是否为研究院生态负责人？规划拍板是否统一由 CEO 做？
  • ROI 估算口径：以线索数、招聘数还是签约额为主？不同活动类型是否用不同口径？
  • 是否设预算阈值，低于阈值无需 CEO 评审？
  • 月度规划会是否已有固定时间？“活动前 5 个工作日锁排班”是否可行？
  • 现有策划方案 PPT/docx 是否作为立项卡的基础模板？
ECO-02生态合作伙伴引入与内部对齐待新建90

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗3 × 跨5 × 险3

  • 适用场景：接触到新的合作方、渠道、KOL 或外部专家，需要先在内部统一理解合作模式、评估对接方式、决定关系维护动作（含赠送试用额度、开通工具账号）时启动
  • 负责人：主责——生态市场条线负责人（当前：许君·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，合作形态定性）、开放平台负责人（当前：郭逸非·推断待确认）、FDE/Skill 负责人（当前：李凯·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，工单项目与额度审批）、研发对接人（当前：邓乾·推断待确认）、运维/账号开通（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记合作线索 → ② 内部对齐会 → ③ 合作形态定性 → ④ 对齐纪要确认 → ⑤ 开工单项目 → ⑥ 外部技术对接 → ⑦ 关系维护动作 → ⑧ 台账月度更新
  • 交付结果：合作伙伴台账记录 + 内部对齐纪要（合作模式、产品形态、技术投入、负责人）+ 需要研发时的工单项目
  • 状态依据：各合作方均临时处理：合作内容靠电话传达、群内转述口径不一致；赠送额度口头决定；无合作立项模板与伙伴台账（04～08 月 4 类场景均无载体）

1. 场景判定

  • 触发条件：新渠道/培训机构/投资机构/KOL 主动接触或被引荐；合作方要求系统对接；想给伙伴赠送额度维系关系；邀请外部专家试用 AI 工具
  • 典型说法：「现在是我们内部统一一下上下文」「怎么感觉跟刚才电话说的不一样」「我可以在工单系统里单独给合作方开一个项目吗」「我想和他多交流但不知道发啥」
  • 判断问题：对方是新合作方或新合作模式吗？内部对“合作做什么、我方投入什么”是否已有书面一致结论？没有 → 本流程
  • 不归本流程管：试用额度发放执行 → 请走 OPS-07；硬件厂商样机/测试卡/认证 → 请走 ECO-04；Skill/插件上架开放平台 → 请走 ECO-06；OPC 商城商家入驻 → 请走 ECO-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
合作引入与对齐牵头 登记线索、召集对齐会、出纪要、维护台账 R 生态市场条线负责人（当前：许君·推断待确认）
合作形态定性 判定产品形态、技术投入边界、对接方式 A CTO（当前：丁震宇·推断待确认）
开放平台/Skill 评估 评估能否基于开放平台、Skill 配合量 C 开放平台负责人（当前：郭逸非·推断待确认）、FDE/Skill 负责人（当前：李凯·推断待确认）
工单项目与额度审批 批准工单项目归属、批准档位内赠送额度 R Leap 研发负责人（当前：王皓南·推断待确认）
技术对接执行 调研对方系统、出对接方案、联调 R 研发对接人（当前：邓乾·推断待确认）
账号开通 开账号、发欢迎消息 R 运维/账号开通（当前：宋祺睿·推断待确认）
外部专家工具支持 组织账号创建与安装指导 C 工程咨询业务专家（当前：王满·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、产品总监（当前：杨萌·推断待确认）

3. 办之前请准备

  • 合作方基本信息：类型（渠道/培训机构/投资机构/KOL/专家）、主营、对接人岗位
  • 对方诉求与我方诉求各一句话
  • 已沟通内容的书面记录（电话沟通须当天补成文字）
  • 拟合作产品形态初判（标品/开放平台/定制）
  • 需要对接系统时：对方技术栈、数据结构、可提供的接口
  • 需要赠送额度时：赠送理由、额度档位、有效期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 首次接触后登记合作线索（类型、模式、诉求、投入、对接人、状态） 主责或首接人 接触后 1 个工作日内 多维表格“合作伙伴台账” 台账记录 🔧飞书固化
2 召集内部对齐会：先内部、后拉对方，带一页纸合作立项单 主责 登记后 2 个工作日内 飞书会议 会议 👤人工判断
3 定性合作形态与对接方式：优先 API，禁止直接写对方原始数据库 CTO 对齐会当场 — 形态与方式结论 👤人工判断
4 输出对齐纪要并在群内确认，口径以纪要为准 主责 会后 4 小时内 飞书妙记 + AI 纪要 对齐纪要 🤖自动化
5 需研发投入的，在工单系统“生态合作战略”项目下开子项目、拆任务 研发对接人申请，Leap 研发负责人批 纪要确认后 1 个工作日内 工单系统 工单项目 🔧飞书固化
6 外部技术对接：系统调研 → 方案 → 权限 → 联调，按清单逐项勾选 研发对接人 按工单排期 对接 checklist 对接方案、联调记录 🔧+👤
7 关系维护：按额度档位审批后开账号、发欢迎消息（文档、安装命令，密钥单独发送） 主责申请、Leap 研发负责人批、运维执行 审批后 1 个工作日内 飞书审批、欢迎消息模板 账号与欢迎消息 🔧+👤
8 每月更新台账状态（推进中/暂停/终止），季度回顾合作价值 主责 每月最后一个工作日 台账视图 月度状态 🔧飞书固化

5. 交付物与模板

  • 交付物：合作伙伴台账记录；对齐纪要；工单项目（如有）；额度/账号发放记录
  • 建议模板/表单：合作立项单（合作方类型、合作模式、产品形态、我方技术配合清单、对方投入、商务条件、风险、负责人、下一步）；合作伙伴台账（名称代号、类型、来源、对接人、阶段、承诺事项、到期日、最近更新）；伙伴额度台账（伙伴、档位、理由、审批人、发放日、到期日）；欢迎消息模板

6. 异常与升级

  • 对齐会后各方理解仍不一致 → 主责重新出纪要逐条确认 → 升级 CTO 定性（2 个工作日内）
  • 合作方要求直接读写其原始数据库 → 研发对接人提出风险，Leap 研发负责人给出方案 → 升级 CTO 拍板（1 个工作日内）
  • 新合作形态与已有渠道冲突或区别不清 → 主责整理对比 → 升级生态市场条线负责人与销售负责人共同裁定（3 个工作日内）
  • 赠送额度超出档位 → 走单独审批 → 升级 CTO 拍板（1 个工作日内）；档位内额度由 Leap 研发负责人审批

7. 衡量指标

  • 对齐纪要覆盖率 = 新合作中有书面对齐纪要的比例，目标 100%
  • 对齐时长 = 首次接触到纪要确认的工作日数，目标 ≤ 3 个工作日
  • 台账更新及时率 = 月末状态已更新的合作数占比，目标 ≥ 90%
  • 额度留痕率 = 有审批记录的额度发放占比，目标 100%

8. 低效诊断

  • 现象：合作模式先经电话传达，群内转述与电话口径不一致，研发侧“云里雾里”（对齐环节无书面载体）｜依据：「开放平台卖课版」2026-08
  • 现象：新渠道与已有培训渠道的区别说不清，缺合作形态分类（定性环节无标准）｜依据：「开放平台卖课版」2026-08
  • 现象：合作方系统对接方案在读库同步与调 API 之间反复，开工单项目要临时问归属（对接环节缺模板）｜依据：「Leap产研测」2026-07
  • 现象：给伙伴送多少额度在群里临时商量，无台账、无阈值（关系维护环节无规则）｜依据：「鼎慧产研决策部」2026-04
  • 现象：外部专家工具账号开通先单人试点、步骤边做边摸索｜依据：「字字可研项目群」2026-05

9. 分支变体

  • 培训机构渠道：区分“课上推销产品”与“基于产品开发课程体系（开放平台培训版 LeapCore）”两种形态，后者需双方技术联合设计课程体系
  • 合作方系统数据对接：在工单系统“生态合作战略”下单独开项目，按对接 checklist 执行
  • KOL/渠道伙伴试用额度：本流程只管“送不送、送多少”，发放执行走 OPS-07
  • 外部专家 AI 工具账号（基石计划）：已有《基石计划 SOP—入组执行》，按该文档执行账号配置、书面约定、精选提交与复盘

10. 待确认问题

  • 主责是否为生态市场条线负责人？还是按合作类型分给渠道/研发不同负责人？
  • 合作形态定性是否必须由 CTO 做，能否下放给开放平台负责人？
  • 赠送额度分几档、各档审批人是谁？是否需要财务知情？
  • 是否已有合作方保密/合作框架协议模板？
  • 对齐会“2 个工作日内召开”是否可行？
ECO-03生态资源池建设与资源对接引荐待新建72

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险2

  • 适用场景：手上有新一批生态资源（活动名单、合作方名单、表格）要入池，或内部有人需要找团队/供应商/专家/设备/客户，需要从资源池匹配引荐时启动
  • 负责人：主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——资源池系统研发（当前：邓乾·推断待确认）、开放平台/FDE（当前：郭逸非·推断待确认）、运维/域名（当前：宋祺睿·推断待确认）；审批——CEO（当前：邴龙志·推断待确认，名单对外使用）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 按模板收集资源 → ② 自动抽取转标准字段 → ③ 试导入确认 → ④ 去重打标入池 → ⑤ 需求登记 → ⑥ 匹配引荐 → ⑦ 结果回流与周汇总
  • 交付结果：可检索、已去重打标的生态资源池；每条内部需求的引荐结果记录；有商机的资源转入销售线索池
  • 状态依据：资源池系统 09 月起开发中（已有需求说明 V1.0），但数据导入每次手工转换、格式不统一返工；需求与资源匹配没有固定通道，参考的外部社区做法同样是靠刷群和私聊

1. 场景判定

  • 触发条件：活动/合作结束后拿到一批名单；各部门持有零散资源表；内部提出“找人/找团队/找设备/找客户”
  • 典型说法：「先把这批导入进去，没问题了先给我看下」「有没有认识某家 FA 的」「谁有某某设备可以借用」「给个大概时间节点吧」
  • 判断问题：这是要把资源沉淀进公司池，或从池里找资源吗？是 → 本流程；已经是明确的销售商机 → 走 SAL-02
  • 不归本流程管：已确认的销售线索跟进 → 请走 SAL-02（入站线索接入、背调与分发认领）；合作伙伴引入与对齐 → 请走 ECO-02；活动规划 → 请走 ECO-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资源池业务负责 定字段与分类、确认导入、受理需求、确认引荐 R/A 研究院生态负责人（当前：陈梦琪·推断待确认）
系统与导入 维护资源池系统、抽取脚本、去重打标 R 资源池系统研发（当前：邓乾·推断待确认）
平台能力支持 Agent API/Skill 接入、数据同步方案 C 开放平台/FDE（当前：郭逸非·推断待确认）
域名与部署 域名、部署与访问权限 C 运维/域名（当前：宋祺睿·推断待确认）
名单对外使用审批 批准批量导出或对外提供名单 A（升级） CEO（当前：邴龙志·推断待确认）
资源提交与需求登记 按模板提交资源源文件、登记需求、回写引荐结果 R 活动执行人/各部门需求人
兜底 主责缺位时受理需求 I 生态市场条线负责人（当前：许君·推断待确认）

3. 办之前请准备

  • 导入：源文件（Word/Excel/CSV/多维表格）、来源说明（哪场活动/哪个合作方）、采集时间、是否已获对方同意使用联系方式
  • 需求：需要什么资源、用途、截止日期、需求人、可接受的条件
  • 统一字段清单（见第 5 节）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 资源持有人按模板提交源文件并注明来源 活动执行人/各部门 活动或合作结束后 3 个工作日内 飞书表单 待导入文件 🔧飞书固化
2 抽取脚本把各格式转为标准字段 资源池系统研发 收到后 2 个工作日内 Agent 抽取脚本 标准化数据 🤖自动化
3 先导入一批给业务确认字段、分类是否正确 研究院生态负责人 1 个工作日内 资源池系统 确认意见 👤人工判断
4 全量导入、去重合并、分类打标（行业、地域、资源类型、合作意向） 资源池系统研发 确认后 1 个工作日内 资源池系统 入池资源 🤖自动化
5 内部需求登记进需求池（需求、截止、需求人、状态） 需求人 提出需求当天 多维表格“需求池” 需求记录 🔧飞书固化
6 AI 按需求初筛候选资源，主责确认后引荐 研究院生态负责人 需求登记后 2 个工作日内 LeapCore Skill + 资源池 引荐记录 🤖+👤
7 引荐结果写回需求池；机器人每周一汇总未响应、超期需求 需求人、机器人 引荐后 5 个工作日内回写 飞书机器人 周汇总 🔧飞书固化
8 有商机的资源转入销售线索池 研究院生态负责人 判定后 1 个工作日内 线索池 线索记录 🔧飞书固化

5. 交付物与模板

  • 交付物：生态资源池（可检索）；需求池及引荐记录；每周未响应需求汇总
  • 建议模板/表单：资源字段（名称代号、类型：机构/个人/供应商/设备、行业、地域、来源、采集时间、联系方式（遮蔽存储）、合作意向、标签、最近联系时间、负责人）；需求池字段（需求描述、类型：采购/合作/融资/技术/设备/引荐、截止日期、需求人、状态、匹配资源、结果）

6. 异常与升级

  • 源数据格式无法抽取 → 退回提交人按模板补齐 → 超 3 个工作日未补，主责决定是否放弃
  • 系统开发节点不明确 → 研发每周在群内同步进度 → 延期超 1 周升级生态市场条线负责人
  • 需要批量导出或对外提供含联系方式的名单 → 提交导出申请 → 升级 CEO 审批（A（升级），2 个工作日内）；其余入池、引荐事项由研究院生态负责人拍板
  • 需求 5 个工作日无匹配 → 周汇总标红 → 主责决定外部渠道寻找或关闭

7. 衡量指标

  • 入池时效 = 源文件提交到入池完成的工作日数，目标 ≤ 5 天
  • 重复率 = 入池后重复记录占比，目标 ≤ 2%
  • 需求响应率 = 2 个工作日内有引荐或答复的需求占比，目标 ≥ 80%
  • 结果回流率 = 引荐后有结果记录的占比，目标 ≥ 90%

8. 低效诊断

  • 现象：系统需求经私下渠道提出，开发进度不透明，业务方需追问时间节点（需求受理环节无排期公示）｜依据：「公司内FDE」2026-09
  • 现象：源数据格式不统一（Word/Excel/CSV/多维表格混用），导入反复返工（收集环节无模板）｜依据：「公司内FDE」2026-09
  • 现象：存储选型（自建系统还是多维表格同步）反复讨论｜依据：「公司内FDE」2026-09
  • 现象（外部参考）：需求只发在群里，应答转私聊后无结果回流，部分采购类需求无人回应（匹配环节无需求池）｜依据：「奇绩校友飞书群」2026-04、「奇绩校友飞书群」2026-08

9. 分支变体

  • 需求方类型：采购/合作/融资需求 vs 供给方：技术/设备/引荐资源，匹配规则不同
  • 生态池与线索池：生态池为上游大池，只有确认商机的条目转入线索池
  • 外部校友社区做法仅作参考：可借鉴“检索工具 + 机器人汇总未响应需求”

10. 待确认问题

  • 资源池最终载体：自建系统还是飞书多维表格？两者是否需要同步？
  • 联系方式的采集授权与导出审批口径是否需要法务确认？
  • 引荐是否必须经主责，还是需求人可自助检索？
  • 生态池转线索池的判定标准是什么，由谁判定？
  • “2 个工作日内引荐”是否可行？
ECO-04生态厂商合作申请（样机/测试卡/适配报告/认证）待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨5 × 险3

  • 适用场景：收到 NVIDIA、电信、国产算力（海光、壁仞、百度等）、国产 OS/CPU（统信、麒麟、飞腾、龙芯）等生态方邀请或要求，需要填申请表/评分表、领取样机或测试卡、交付适配测试报告或申请互认证书时启动
  • 负责人：主责——生态厂商对接人（当前：丁震宇·推断待确认，建议移交生态市场条线）；协同——认证对接（当前：韩诗琪、陈芷青·推断待确认）、测试（当前：杨云峰、潘浩伟·推断待确认）、IT/资产（当前：杨明学·推断待确认）、交付部署（当前：游家豪·推断待确认）、信创负责人（当前：李子遥·推断待确认）、销售/渠道（当前：闫登辉·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 登记生态机会 → ② 判断是否申请 → ③ 材料库 + AI 生成申请材料 → ④ 审阅提交 → ⑤ 跟踪批复 → ⑥ 样机入资产 → ⑦ 测试出报告/认证 → ⑧ 归档并转宣传
  • 交付结果：已提交的申请表/评分表；入资产台账的样机或测试卡；适配测试报告或厂商互认证书；可用于宣传稿和投标资质的材料
  • 状态依据：统信、飞腾认证已跑通并有厂商 case 文档，但版本选择反复、材料重做；样机/测试卡申请仍靠个人转发与手工填表，02～10 月约 30 余次往来中多次催办、批复进度不透明

1. 场景判定

  • 触发条件：生态方发来 ISV 计划/样机申请表/评分表；需要厂商硬件做适配；厂商要求测完交报告；宣传或投标需要互认证书
  • 典型说法：「用他们的机子就得写一个报告」「让 AI 对着这个编得了」「每个版本都要有证书吗」「认证要求太高，这个版本先不测了」
  • 判断问题：对方是硬件/算力/OS 生态厂商，且需要我方填申请、出报告或拿证书吗？是 → 本流程
  • 不归本流程管：渠道、培训机构、KOL 等合作引入 → 请走 ECO-02；采购硬件 → 请走 ADM-24（IT 设备与研发硬件采购申请），付款走 FIN-01；客户项目上的信创适配交付 → 请走 X-DLV-25（信创/国产算力适配与厂商协同）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
生态机会对接 登记机会、判断是否申请、审阅提交、跟进厂商 R/A 生态厂商对接人（当前：丁震宇·推断待确认）
认证申请对接 与厂商确认产品分类、版本、CPU/OS 范围，提交认证 R 认证对接（当前：韩诗琪、陈芷青·推断待确认）
测试与报告 适配测试、性能/模型部分报告、认证自测报告 R 测试（当前：杨云峰、潘浩伟·推断待确认）
版本与架构确认 确认送测版本、打包与架构矩阵 C 信创负责人（当前：李子遥·推断待确认）
样机接收与资产 到货登记、资产台账、归还 R IT/资产（当前：杨明学·推断待确认）
申请表初填 填项目基础信息与测试计划 C 交付部署（当前：游家豪·推断待确认）
机会来源 转入厂商邀请 I 销售/渠道（当前：闫登辉·推断待确认）

3. 办之前请准备

  • 厂商邀请原文、申请表/评分表、截止日期、对方联系人
  • 公司简介、产品介绍、已有案例、已适配软硬件清单（取自生态申请材料库）
  • 拟测试的产品版本号、CPU 架构、OS 版本矩阵
  • 测试计划：测什么、谁测、周期、报告分工
  • 厂商平台登录账号（由对接人在密码管理工具中统一保管）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记生态机会（厂商、类型、截止、我方收益、对接人） 收到邀请的任何人 收到后 1 个工作日内 多维表格“生态厂商机会表” 机会记录 🔧飞书固化
2 判断是否申请；评分表类需决策人会签是否真合作 生态厂商对接人 登记后 2 个工作日内 会签审批 申请结论 👤人工判断
3 从材料库取素材，AI 生成申请材料初稿；研发/交付补项目基础与测试计划 交付部署、测试 截止前 3 个工作日 材料库 + AI 申请材料初稿 🤖自动化
4 审阅后提交厂商 生态厂商对接人 截止前 1 个工作日 邮件/厂商平台 已提交申请 👤人工判断
5 每周更新批复进度；5 个工作日无回音主动追问厂商 生态厂商对接人 每周五 机会表 + 提醒机器人 进度记录 🔧飞书固化
6 样机/测试卡到货登记资产台账，指定测试人与归还日期 IT/资产 到货当天 资产台账 资产记录 🔧飞书固化
7 按模板测试并出报告：性能/模型部分由测试写，公司/业务部分由对接人写 测试、对接人 试用期结束前 3 个工作日 测试报告模板 适配测试报告 🤖+👤
8 认证分支：锁定版本×架构×OS 矩阵，按厂商 case 自测，提交审核，复核证书 认证对接、测试、信创负责人 按厂商截止；锁版后不再变更 厂商认证平台 认证证书 🔧+👤
9 报告、证书、申请表归档进材料库，证书转市场出宣传稿；样机按期归还或转资产 认证对接、IT/资产 拿到结果后 2 个工作日内 知识库 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：申请表/评分表；资产台账记录；适配测试报告；认证证书；宣传素材
  • 建议模板/表单：生态厂商机会表（厂商、项目类型：样机/测试卡/ISV 计划/认证、截止日、我方收益、对接人、状态、批复日期、归还日期）；生态申请材料库（公司简介、产品介绍、案例、适配清单、资质）；适配测试报告模板（环境、版本、测试项、性能数据、结论、业务说明）；认证矩阵表（版本 × 架构 × OS × 报告/录屏 × 截止 × 状态）

6. 异常与升级

  • 厂商批复超 2 周无进展 → 对接人再次追问 → 升级生态市场条线负责人决定是否放弃（1 个工作日内）
  • 认证过程中产品版本变更 → 信创负责人评估是否换版重测 → 升级 CTO 拍板（1 个工作日内）
  • 厂商认证要求过高或缺测试机器（如无对应虚拟机） → 暂缓并在机会表标注 → 升级生态市场条线负责人
  • 厂商平台账号失效或无人掌握 → 对接人统一重置并登记保管位置 → 当天解决
  • 宣传急需证书但未通过 → 不得提前宣传 → 升级生态市场条线负责人

7. 衡量指标

  • 机会登记率 = 登记在表的生态机会 ÷ 全部机会，目标 100%
  • 申请材料准备时长 = 登记到提交的工作日数，目标 ≤ 3 天
  • 报告按期率 = 试用期结束前提交报告的占比，目标 100%
  • 认证返工次数 = 单项认证中因版本变更重做报告的次数，目标 ≤ 1
  • 样机归还/入账率 = 按期归还或入账的样机占比，目标 100%

8. 低效诊断

  • 现象：厂商合作信息只在群里口头转述，没有对接记录与样机接收流程（登记环节缺失）｜依据：「鸽子群模态分群」2026-07、「鸽子群模态分群」2026-08
  • 现象：申请表手工填写，初填缺项目基础与测试计划，需要再补素材让 AI 重写（材料环节无素材库）｜依据：「忠橙星行星引擎」2026-07
  • 现象：测试卡申请批复进度不透明，测试方多次追问（跟踪环节无进度表）｜依据：「跃迁基座项目交付沟通」2026-03
  • 现象：认证送测版本多次变动，报告重做（版本锁定环节缺失）｜依据：「信创LeapCore客户端适配」2026-09、「信创LeapCore客户端适配」2026-10
  • 现象：两边反馈不一致、谁拉进厂商沟通群不清、厂商平台账号失效（认证对接环节职责不清）｜依据：「信创LeapCore客户端适配」2026-09

9. 分支变体

  • 硬件样机（DGX Spark、RTX Spark 等）：重点在申请表、到货入资产、后续产品定位讨论（是否做特供版 LeapCore）
  • 国产算力测试卡（海光、壁仞、百度等）：试用期短，必须交测试报告；需关注新模型镜像支持
  • ISV/电信生态评分表：评分达标后是否真合作由领导会签决定
  • 互认证：统信需按版本 × 架构出多份报告；飞腾为录屏 + 证书；麒麟要求高，可暂缓；龙芯需先解决测试机器

10. 待确认问题

  • 生态厂商对接是否从 CTO 移交生态市场条线？移交后谁主责？
  • 评分表/ISV 计划“是否真合作”的会签人是谁？
  • 认证版本由谁最终锁定（信创负责人还是产品总监）？
  • 厂商平台账号统一保管在哪里？
  • 样机所有权与归还规则是否已有资产制度？
ECO-05开放平台业务归属与需求路由口径待新建120

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：开放平台/基座等业务的归属、汇报线、例会参会人不清，或市场销售对开放平台能力认知混乱、需求被错误路由时启动；同时作为销售判断“需求该进开放平台还是定制”的规则依据
  • 负责人：主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，通知与产品视角）、插件研发（当前：侯怡辰·推断待确认，开发课）、FDE 负责人（当前：李凯·推断待确认）、总经办（当前：待指定，架构与汇报登记）；裁决——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记业务归属与汇报线 → ② 绑定例会参会名单 → ③ 编制能力边界与分类决策树 → ④ 全员通识课 → ⑤ 新销售必修 → ⑥ 需求按决策树路由 → ⑦ 争议裁决 → ⑧ 季度更新
  • 交付结果：业务归属与汇报登记表；《开放平台能力边界与项目分类决策树》及 FAQ；通识课课件与培训记录；需求路由记录
  • 状态依据：已有公司架构图，但汇报对象和例会参会边界不清；无能力边界宣贯材料，销售对能力认知两极，09 月出现全定制项目被拉进开放平台

1. 场景判定

  • 触发条件：组织架构调整；某业务开会没人通知负责人；销售提出的需求不知道该进开放平台、行业包还是全定制
  • 典型说法：「开放平台算谁底下的」「他的部分谁来汇报」「市场销售对开放平台的能力和认知有点太混乱了」「一种以为还没上线，一种以为什么都能往里塞」
  • 判断问题：是“这事归谁/该进哪条线”的问题吗？是 → 本流程；已明确归属、只需要接入上架 → 走 ECO-06
  • 不归本流程管：Skill/插件接入上架 → 请走 ECO-06；客户需求评估与报价 → 请走 SAL-03（商机甄别与可行性初筛），定制/非标需求报价走 SAL-21；公司级组织架构调整本身 → 请走 CEO-06（组织架构、汇报线与职责边界调整）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
能力边界与路由确认 编制决策树/FAQ、确认需求分类、主讲通识课 R 开放平台负责人（当前：郭逸非·推断待确认）
归属与分类裁决 裁决业务归属、汇报线和分类争议 A CTO（当前：丁震宇·推断待确认）
通知与产品视角 拟全公司通知、约会议室、审核产品边界表述 C 产品总监（当前：杨萌·推断待确认）
开发课 面向开发者的接入课 C 插件研发（当前：侯怡辰·推断待确认）
FDE 视角 提供行业包/定制案例 C FDE 负责人（当前：李凯·推断待确认）
归属登记 维护业务归属与汇报登记表 R 总经办（当前：田杰·推断待确认）
销售与人事 销售按决策树提需求并填路由单；通识课纳入新销售入职必修 R 销售负责人（当前：李鹏为·推断待确认）、人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 最新公司架构图
  • 各业务线（开放平台、基座各子块）现负责人、日常汇报对象、对董事会汇报人
  • 开放平台已上线能力清单与路线图
  • 典型案例：标品、行业包、全定制各 1～2 个
  • 销售近期提交的需求清单（用于校验决策树）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记每条业务线的归属部门、负责人、日常汇报对象、董事会汇报人、例会参会人 总经办 架构变更后 3 个工作日内 多维表格“业务归属登记表” 登记表 🔧飞书固化
2 例会参会名单从登记表生成，负责人变更自动同步 总经办 登记后 1 个工作日内 飞书日历 + 多维表格自动化 参会名单 🔧+🤖
3 编制能力边界与项目分类决策树（标品/行业包/全定制）及 FAQ 开放平台负责人、产品总监 2 周内 知识库 决策树、FAQ 👤人工判断
4 发全公司通知、组织 30 分钟内通识课（案例 + 现状 + 未来） 产品总监、开放平台负责人 课前 3 个工作日发通知 飞书会议/妙记 课件、录屏 🔧飞书固化
5 通识课录屏纳入新销售入职必修，入职 2 周内完成 人事、销售负责人 入职 2 周内 培训系统 学习记录 🔧飞书固化
6 销售提需求时按决策树自判类型并填路由单，开放平台负责人确认分类 销售、开放平台负责人 提交后 1 个工作日内确认 需求路由表单 路由记录 🔧+👤
7 分类争议或归属争议提交裁决 CTO 2 个工作日内 飞书审批 裁决结论 👤人工判断
8 基于 FAQ 配置答疑机器人；每季度更新决策树与 FAQ 开放平台负责人 每季度首月 飞书机器人 更新版材料 🤖自动化

5. 交付物与模板

  • 交付物：业务归属与汇报登记表；能力边界决策树与 FAQ；通识课课件和录屏；需求路由记录
  • 建议模板/表单：业务归属登记表（业务线、上级部门、负责人、日常汇报对象、董事会汇报人、例会名称、参会人、生效日期）；需求路由单（客户代号、需求描述、销售自判类型、开放平台确认类型、是否争议、裁决结论、流向）

6. 异常与升级

  • 例会未通知业务负责人 → 会议组织者按登记表补发 → 连续 2 次发生升级总经办
  • 销售已对客户承诺开放平台做不了的能力 → 开放平台负责人 1 个工作日内给出替代方案 → 升级 CTO 与销售负责人
  • 全定制项目误入开放平台排期 → 退回并重新路由 → 升级 CTO（2 个工作日内）
  • 业务负责人变更未登记 → 总经办 3 个工作日内补登 → 升级 CEO 办

7. 衡量指标

  • 归属登记完整率 = 有明确负责人和汇报对象的业务线占比，目标 100%
  • 需求误路由率 = 被退回重新分类的需求 ÷ 全部需求，目标 ≤ 10%
  • 通识课覆盖率 = 市场销售人员完成学习的比例，目标 100%
  • 分类确认时长 = 路由单提交到确认的工作日数，目标 ≤ 1 天

8. 低效诊断

  • 现象：开放平台、基座业务归属不清，例会实际不含业务负责人，汇报对象说不清（登记环节缺失）｜依据：「鼎慧产研决策部」2026-07
  • 现象：销售对开放平台能力认知两极，全定制项目被错误路由进开放平台，内部低效扯皮（路由环节无决策树）｜依据：「【模态】开放生态」2026-09
  • 现象：通识培训无固定课件，靠临时组织（宣贯环节无沉淀）｜依据：「【模态】开放生态」2026-09

9. 分支变体

  • 标品：直接走开放平台已有能力
  • 行业包：开放平台 + FDE 组合交付
  • 全定制：不进开放平台，先走 SAL-21（定制/非标需求评估、报价与特批），再由项目部/FDE 交付
  • 对董事会汇报与日常汇报可以是不同对象，登记表中分开填写

10. 待确认问题

  • 开放平台当前唯一负责人是谁？对董事会汇报与日常汇报分别对谁？
  • 标品/行业包/全定制的边界由谁最终定义（产品总监还是 CTO）？
  • 业务归属登记表由总经办还是 CEO 办维护？
  • 通识课是否纳入新销售入职必修？
  • 是否已有成文的架构图更新与通知机制？
ECO-06开放平台 Skill/插件与第三方接入上架待优化400

状态：待优化｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：内部研发、FDE、外部开发者或合作伙伴要把 Skill、插件或数据源接入 LeapCore 开放平台并上架，或 LeapCore 客户端需要对接开放平台下发技能时启动
  • 负责人：主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——插件接入技术负责人（当前：侯怡辰·推断待确认）、开放平台账号与网关（当前：吴亚军·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认，架构决策）、客户端后端（当前：宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）、FDE 负责人（当前：李凯·推断待确认）、销售总监（当前：吴琪·推断待确认）、数据源评估（当前：白立新·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；计费设计——CTO（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 接入申请 → ② 分类评估（第三方过检查表） → ③ 开通开发者账号与 Key → ④ 按规范开发自检 → ⑤ 提交审核 → ⑥ 客户端联调 → ⑦ 计费鉴权打通 → ⑧ 上架通知与反馈迭代
  • 交付结果：通过审核并在开放平台上架的 Skill/插件/数据源；第三方合作的接入检查表与商务条款确认记录；计费鉴权配置
  • 状态依据：已有 LeapSkill 格式规范 1.0.0、插件开发指南、DevKit、uploader 和审核流程，但入驻审核只靠“管理员给账号”、接口协作靠私聊；第三方合作方每家临时对接，07～10 月约 50 次往来中多次返工（凭据管理事后补、套壳/原生接入反复）

1. 场景判定

  • 触发条件：有人要上架 Skill/插件；合作方想作为插件或数据源接入 LeapCore；客户端需要对接开放平台技能市场；需批量上传
  • 典型说法：「开放平台应该出一套完整的、面向开发者的规范和文档」「有开发者 Key，有对应的说明教怎么用吗」「外部插件扣费得多过一层鉴权」「我需要一次性上传 8 个插件，想要 CLI」
  • 判断问题：要接入的东西最终是否以 Skill/插件/数据源形式出现在开放平台？是 → 本流程
  • 不归本流程管：合作是否开展的前期对齐 → 请走 ECO-02；开放平台业务归属与需求分类 → 请走 ECO-05；商城商品入驻 → 请走 ECO-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
接入与上架总负责 受理申请、发 Key、组织审核、上架 R/A 开放平台负责人（当前：郭逸非·推断待确认）
插件接入技术 评估接入方式、DevKit、开发者答疑 R 插件接入技术负责人（当前：侯怡辰·推断待确认）
账号与计费网关 开发者账号、余额扣费网关实现 R 开放平台账号与网关（当前：吴亚军·推断待确认）
计费鉴权设计 外部插件扣余额的鉴权方案 A（升级） CTO（当前：丁震宇·推断待确认）
架构与路线 接入路线、跨组协作规则 C Leap 研发负责人（当前：王皓南·推断待确认）
客户端联调 预签名链接、版本/slug 对接 R 客户端后端（当前：宋祺睿、杨云峰·推断待确认）
产品优先级 兼容与回退等需求取舍 C 产品总监（当前：杨萌·推断待确认）
第三方评估 商务引入、数据源质量实测、Skill 质量评估 C 销售总监（当前：吴琪·推断待确认）、数据源评估（当前：白立新·推断待确认）、FDE 负责人（当前：李凯·推断待确认）
条款与资金 授权、计费、结算条款 C 财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 接入主体（内部/FDE/外部开发者/合作方）与联系人
  • 接入类型：Skill、Plugin（agent plugins/MCP Apps 标准）、数据源 API
  • 已阅读《LeapSkill 格式规范 1.0.0》《Leap 插件生态开发指南》，拿到 DevKit
  • 是否涉及计费、用户授权（OAuth）、外部数据
  • 第三方合作：商务条款草案、数据样本、测试设备到货时间
  • 请求最少包含字段（接入申请表必填，缺一项不受理、不另行追问）：接入主体与唯一接口人岗位、接入类型（Skill/Plugin/数据源）、名称与 slug、版本号、用途一句话、可见范围（全局/行业/组织）、是否计费与计费方式、是否需用户授权（OAuth）或外部数据、目标客户端版本、期望上架日与原因、代码/包所在位置、是否已跑 selfcheck

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交接入申请（主体、类型、用途、是否计费、是否需授权、联系人） 接入方 接入意向确定后，开发前提交 开放平台申请表单 接入申请（接入台账一行，编号自动生成，状态“待评估”，自动 @ 开放平台负责人） 🔧飞书固化
2 分类评估：内部/FDE 直接进入；第三方先填接入检查表（授权、数据质量、计费、安全、测试）并确认商务条款 开放平台负责人、商务、财务/法务 申请后 3 个工作日内 接入检查表 评估结论（回写接入台账：通过/退回/阻塞 + 检查表链接 + 条款确认人岗位）；商务/财务/法务 2 个工作日未回复→开放平台负责人升级 CTO 👤人工判断
3 开通开发者账号与 Key，发开发者包（规范、指南、DevKit、uploader/CLI、Key 使用说明） 开放平台账号与网关 评估通过后 1 个工作日内 开放平台后台 账号、开发者包（Key 经私密渠道发接入方，台账记账号名与开通日，开发者包链接固定在开放平台文档站）；超时→开放平台负责人 🔧+👤
4 按规范开发并运行 selfcheck 与 AI 格式校验 接入方 按申请表所填开发计划；预计超期提前 2 个工作日在台账更新 DevKit 校验工具 合规包（上传开放平台后台，selfcheck 报告附台账，状态改“待审核”） 🤖自动化
5 提交审核：格式合法性 → 质量评分 → 安全门禁 开放平台负责人、FDE 负责人 提交后 3 个工作日内 审核流程 审核结果（后台审核记录 + 台账状态“通过/退回”，退回附校验报告给接入方）；超时→CTO 🔧+👤
6 客户端联调：接口约定（预签名链接、slug+version 唯一键）写入工单，沟通走会议/群/工单 客户端后端、开放平台 1 个迭代内 工单系统 联调记录（工单编号回写台账，接口约定写入工单描述）；工单 2 个工作日无人认领→Leap 研发负责人 🔧飞书固化
7 计费与授权：外部插件扣余额走额外鉴权、只扣申请金额；OAuth/凭据管理方案上线前评审 CTO、开放平台账号与网关 上线前 5 个工作日完成评审 v5 网关 计费鉴权配置（评审结论记决策记录，配置变更记网关变更记录，链接回写台账） 👤人工判断
8 上架发布并通知接入方；批量上传用 CLI 开放平台负责人 审核通过后 1 个工作日内 开放平台 + 机器人通知 上架记录（台账状态“已上架”+ 上架日期，机器人通知接入方与【模态】开放生态群） 🔧+🤖
9 上线 2 周内收集接入方反馈，更新接入 SOP 与规范 开放平台负责人 上线后 2 周 反馈表 规范更新（反馈表链接贴台账，规范新版本号发文档站并公告） 👤人工判断

5. 交付物与模板

  • 交付物：上架的 Skill/插件/数据源；审核记录；第三方接入检查表；计费鉴权配置；接口约定工单
  • 建议模板/表单：接入申请表（主体、类型、名称、slug、版本、用途、可见范围：全局/行业/组织、是否计费、是否需授权、联系人）；第三方接入检查表（商务授权、数据来源与核验状态、计费模式、凭据管理、安全门禁、测试结论、商务条款确认人）

6. 异常与升级

  • 接入方不按规范提交 → 退回并附校验报告 → 二次不合格升级开放平台负责人约会对齐（3 个工作日内）
  • 跨组接口争议（版本回退、slug 互斥等） → 写入工单 → 产品总监定优先级，Leap 研发负责人定方案（2 个工作日内）
  • 第三方涉及资金扣费或用户数据 → 未完成计费鉴权与条款确认不得上线 → 升级 CTO 拍板计费鉴权方案（A（升级））；不涉及计费与用户数据的接入由开放平台负责人拍板
  • 合作方方案无人掌握（接口人转手） → 开放平台负责人指定唯一接口人 → 当天确定
  • 等待对方设备或数据 → 在申请表标注阻塞 → 超 2 周升级商务确认是否继续
  • 接入申请字段不全（无 slug/版本号、未说明是否计费与授权、无接口人）→ 不受理，退回接入方补齐 → 补齐超 3 个工作日自动关闭，需重新申请
  • 接入台账状态超过该步时限未更新 → 开放平台负责人标红并 @ 当前环节负责人 → 再过 1 个工作日无动作升级 CTO；影响合作方承诺日期的当天通知商务

7. 衡量指标

  • 接入周期 = 申请到上架的工作日数，内部目标 ≤ 10 天，第三方目标 ≤ 20 天
  • 一次审核通过率 = 首次提交即通过的占比，目标 ≥ 70%
  • 私聊对接占比 = 未走工单/群/会议的接口约定次数，目标 0
  • 第三方检查表完成率 = 上线前完成检查表的第三方接入占比，目标 100%

8. 低效诊断

  • 现象：跨组接口对接靠私聊和电话，被要求改走会议/群/工单；接口进迭代需临时拆任务（联调环节无约定载体）｜依据：「Leap产研测」2026-07
  • 现象：slug 互斥等规则未写入规范，联调时临时决定｜依据：「Leap产研测」2026-07
  • 现象：入驻审核没有流程文档，只靠管理员发账号；开发者 Key 无配套使用说明（受理环节缺失）｜依据：「【模态】开放生态」2026-07、「【模态】开放生态」2026-09
  • 现象：合作方按通用格式提交，不遵守 LeapSkill 规范；批量上传缺 CLI（开发与提交环节）｜依据：「【模态】开放生态」2026-09
  • 现象：第三方 OAuth 授权与凭据管理设计事后补；套壳还是原生接入反复（评估环节无检查表）｜依据：「【行业版LeapCore】招投标版」2026-09、「【行业版Leapcore】工程版」2026-09

9. 分支变体

  • 官方技能 / 开放平台技能 / 工程版专属技能：上传时需标记来源与可见范围
  • Skill：遵循 LeapSkill 格式规范 1.0.0
  • Plugin：遵循 agent plugins/MCP Apps 标准与插件开发指南，使用 DevKit
  • 第三方插件（标务类、审查类）：已接其他平台的可采用兼容/转换，需计费打通
  • 数据源 API：先实测样本质量，保留来源、哈希、核验状态，作为“候选数据源”再决定接入
  • 成本测算类产品：按插件或数据源择一路径评估
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-03（决策记录与发布）、ALL-07（群聊治理）

10. 待确认问题

  • 开放平台主责是否唯一为开放平台负责人？账号与网关是否由另一人负责？
  • 第三方接入的商务条款确认人是谁（商务、法务还是财务）？
  • 外部插件扣费的结算与分成规则是否已有成文口径？
  • 审核“3 个工作日内”是否可行？质量评分由谁打分？
  • 开发者注册是否计划开放，开放后是否走自动审批？
ECO-07OPC 社区/商城第三方商家入驻与准入待新建300

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：OPC 社区、智能涌现商城、智能体工坊招募外部商家/开发者入驻，或内部员工要上架自有产品，或承接地方政府 OPC/AI 产品征集需要厂商预上架时启动
  • 负责人：主责——OPC 社区/商城运营负责人（当前：陈梦琪·推断待确认）；协同——商城研发/商家对接（当前：葛家和·推断待确认）、招商与定价（当前：丁震宇·推断待确认）、厂商联系（当前：杨朋伟、刘昱潇·推断待确认）、技术对接（当前：毛鹏程·推断待确认）、准入标准修订（当前：李铭熙·推断待确认）、支付冲正（当前：吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 发布入驻须知 → ② 商家提交入驻申请 → ③ 准入评审与可用性核验 → ④ 签入驻协议 → ⑤ 定价与商品资料 → ⑥ 卡密/兑换码导入校验 → ⑦ 预上架测试 → ⑧ 上架与进度汇报 → ⑨ 结算与售后
  • 交付结果：签署协议、通过准入、完成预上架测试并上架的商品；商家入驻台账；结算与售后记录；对政府主管部门的进度表
  • 状态依据：已有《智能体准入标准 V1.0》和厂商筛选多维表格，但入驻协议、卡密格式、结算账期、退款售后规则只存在于聊天，02～04 月约 30 次被反复询问；上线测试才发现重复卡密、批量下单锁库存漏洞

1. 场景判定

  • 触发条件：外部商家/开发者申请入驻；内部员工要上架自有产品；政府 OPC/AI 产品征集需要厂商上架；商家提交卡密/兑换码
  • 典型说法：「上架 OPC 不是要签很多协议走手续吗」「一个商品只有一个价格，对应一个 txt」「产品不能太差，要把把关」「上商城的商品我该找谁对接」
  • 判断问题：是否有外部或内部主体要把商品/应用放到 OPC 社区或商城上售卖？是 → 本流程
  • 不归本流程管：自营商品上下架 → 请走 OPS-11；社区帖子/内容审核 → 请走 OPS-23；Skill/插件上架开放平台 → 请走 ECO-06；社区活动与内容运营 → 请走 ECO-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
入驻总负责 入驻须知、准入评审组织、进度汇报、商家台账 R/A OPC 社区/商城运营负责人（当前：陈梦琪·推断待确认）
招商与定价 招商、商品说明审核、供货价与毛利评估；供货价例外与售后争议裁定 A（升级） CTO（当前：丁震宇·推断待确认）
预上架测试 下单、兑换、库存锁定、URL 篡改等测试 R 测试负责人（当前：张东郅·推断待确认）
商城研发与商家对接 后台卡密导入、校验规则、商家技术问题 R 商城研发（当前：葛家和·推断待确认）
厂商联系 按话术联系厂商、更新进度表 R 厂商联系（当前：杨朋伟、刘昱潇·推断待确认）
技术对接 向厂商发送技术对接材料 R 技术对接（当前：毛鹏程·推断待确认）
准入标准修订 修订准入标准 C 准入标准修订（当前：李铭熙·推断待确认）
支付冲正 消费券冲正等支付处理 C 支付研发（当前：吴世豪·推断待确认）
协议与结算 入驻协议、结算、退款打款 R 财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 商家主体信息、商品类型（卡密/小 Agent/实物）、商品说明与产品介绍
  • 建议零售价、供货价、SKU 清单（一个 SKU 一个价格）
  • 卡密 txt（每行一个密钥）及兑换入口、有效期
  • 售后渠道（售后群信息、客服联系方式）
  • 产品在约定上线日前真实可用的证明（试用账号或演示）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布入驻须知（商品类型、卡密格式、结算账期、售后与退款规则、协议） 运营负责人 招募启动前 知识库 入驻须知 🔧飞书固化
2 商家提交入驻申请；进度统一在多维表格更新，不用多人编辑 Excel 商家、厂商联系 招募期内 飞书表单 + 多维表格 入驻申请、进度表 🔧飞书固化
3 准入评审（按准入标准两轮）+ 可用性核验 运营负责人、招商与定价 申请后 5 个工作日内 准入评审表 准入名单 👤人工判断
4 签署入驻协议（内部员工自有产品同样签） 财务/法务 准入后 3 个工作日内 飞书合同审批 入驻协议 🔧飞书固化
5 定供货价（统一折扣规则，例外报批）；审核商品说明与售后信息 招商与定价 协议签署后 2 个工作日内 定价表 定价与商品资料 👤人工判断
6 导入卡密/兑换码：系统自动去重、有效期校验，重复或过期拒收 商城研发 商家按约定日期交付后 1 个工作日内 商城后台“仓库” 库存 🤖自动化
7 预上架测试：下单、兑换、库存锁定、URL 篡改批量下单 测试、商城研发 上线前 2 个工作日 测试环境 测试结论 🔧+👤
8 正式上架；政府征集类导出进度表报主管部门 运营负责人 测试通过后 1 个工作日内 商城后台、多维表格 上架记录、进度表 🔧+👤
9 按 T+1 账期结算；卡密原则不退款，例外走退款审批：通知厂商作废卡密后人工打款；有效期纠纷由商家处理 财务、运营负责人 退款申请 2 个工作日内处理 飞书审批 结算/退款记录 🔧飞书固化

5. 交付物与模板

  • 交付物：入驻须知；入驻协议；商家入驻台账；准入评审记录；上架商品；结算与退款记录；政府征集进度表
  • 建议模板/表单：入驻申请表（主体、商品名、类型、SKU、建议零售价、供货价、兑换入口、有效期、售后渠道、联系人、上线日期）；卡密格式模板（一 SKU 一 txt、每行一个密钥、首批数量）；退款审批单（订单号、商品、原因、厂商作废确认、打款方式、审批人）

6. 异常与升级

  • 商家卡密重复或过期 → 系统拒收并通知商家补交 → 超约定日期 2 天未补，运营负责人决定延期或取消上架
  • 用户要求卡密退款 → 售后受理 → 走退款审批，财务打款（2 个工作日内），争议升级招商与定价负责人（CTO，A（升级））
  • 供货价低于统一折扣规则的例外申请 → 运营负责人整理理由 → 升级招商与定价负责人（CTO）拍板（2 个工作日内）
  • 产品在约定日期前不可用 → 不予上架 → 升级运营负责人通知商家（1 个工作日内）
  • 政府征集进度落后 → 运营负责人每日机器人催办 → 汇报前 1 天仍未达标升级生态市场条线负责人
  • 内部员工产品上架是否需答辩/协议有争议 → 按入驻须知执行 → 升级 CEO 办裁定

7. 衡量指标

  • 入驻周期 = 申请到上架的工作日数，目标 ≤ 10 天
  • 协议覆盖率 = 已上架商家中签署入驻协议的比例，目标 100%
  • 卡密质量问题数 = 上线后发现的重复/过期卡密投诉数，目标 0
  • 退款处理时长 = 退款申请到打款的工作日数，目标 ≤ 3 天
  • 规则类重复询问次数 = 群内就同一规则（退款、账期、格式）重复提问次数，按月下降

8. 低效诊断

  • 现象：上架是否需要签协议、答辩、归谁管不清，做 OPC 的目标未统一（入驻须知环节缺失）｜依据：「鼎慧产研决策部」2026-04
  • 现象：退款、冲正、有效期过期由谁负责靠群里临时回答；商家、研发、测试对兑现方式和账期理解不一（售后规则未成文）｜依据：「开源聚变入驻问题沟通群」2026-02
  • 现象：后台可上传重复卡密、可篡改 URL 批量下单锁库存，上线测试才发现（导入校验与预上架测试环节缺失）｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：厂商筛选用多人编辑 Excel，“搞着搞着就乱”，后转多维表格（进度跟踪环节）｜依据：「【模态】教育业务线」2026-03
  • 现象：对接话术前一晚才发，要求次日全部联系完，靠催办推进；成员不理解卡密机制（准备环节滞后）｜依据：「【模态】教育业务线」2026-03

9. 分支变体

  • 卡密类商品：一 SKU 一价格一 txt；商城只存卡密不负责兑现，用户自行到厂商平台兑换
  • 小 Agent/智能体：按《智能体准入标准》两轮评审，商品说明需审核
  • 实物商品：需补物流与售后约定（规则待定）
  • 内部员工自有产品：同样签协议，是否需答辩待确认
  • 政府 OPC/AI 产品征集：自有技术对接的厂商与挂靠成熟公司的方案分别跟进；已确认入驻与未确认的跟进动作不同；需按时向政府主管部门报进度
  • 与政府合作平台共用支付：退款由平台客服受理，不做消费券冲正
  • 线下代理渠道：规则待定

10. 待确认问题

  • 入驻主责是否为 OPC 社区/商城运营负责人？招商与定价是否继续由 CTO 承担？
  • 是否已有入驻协议模板？内部员工上架是否也必须签？
  • 统一供货折扣比例与例外审批人是谁？
  • T+1 账期与退款打款由哪个主体财务执行？
  • 上架答辩是否保留？OPC 业务目标（社区运营/拓产品线/收益）以哪个为主？
ECO-08开源社区建设、运营与产出汇报待优化72

状态：待优化｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：运营开源聚变 AI 社区（内容/智能体/活动征集、论坛与社群人气）、维护公司开源项目名单、汇总开源与布道产出、对接外部开源社区活动（赞助、演讲）时启动
  • 负责人：主责——研究院生态负责人（当前：陈梦琪·推断待确认）；协同——开源/布道（当前：李子遥·推断待确认）、线下分享协调（当前：吴亚军·推断待确认）、运营（当前：李凯·推断待确认）、新媒体（当前：鲁周毅·推断待确认）、开源聚变技术支持（当前：宋祺睿·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、选拔赛设计（当前：黄莹·推断待确认）、推广（当前：侯明月、邓乾·推断待确认）；发起与审批——CEO（当前：邴龙志·推断待确认）；开源准入——CTO（当前：丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 季度社区运营计划 → ② 开源准入审核 → ③ 维护开源名单 → ④ 统一表单征集内容/智能体/活动 → ⑤ 内容合规审核 → ⑥ 社区日常运营 → ⑦ 每周产出汇报 → ⑧ 外部社区活动评估对接 → ⑨ 月度复盘
  • 交付结果：季度社区运营计划；开源项目与贡献者名单；审核后发布的社区内容；每周开源产出周报；外部活动立项与复盘记录
  • 状态依据：已有征集表单、社区论坛、GitHub/Gitea 和每周汇报要求，但无社区运营方案与开源准入流程，开源聚变具体负责人不清，征集靠全员群反复求助，02～10 月约 40 次往来

1. 场景判定

  • 触发条件：社区需要内容/智能体/活动；员工或项目准备开源；每周开源产出汇报；外部开源社区邀请赞助或演讲
  • 典型说法：「开源社区即将迎来聚变」「公司拟孵化两个开源项目」「顺手复制一份发到论坛里」「对方邀请我们做个简单的演讲分享」
  • 判断问题：事情是否围绕开源聚变社区或公司开源项目？是 → 本流程
  • 不归本流程管：黑客松/大会等活动的立项取舍 → 请走 ECO-01；社区帖子日常审核 → 请走 OPS-23；OPC 商城商家入驻 → 请走 ECO-07；Skill/插件上架 → 请走 ECO-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
社区运营总负责 运营计划、征集汇总、周报汇总、外部活动评估 R/A 研究院生态负责人（当前：陈梦琪·推断待确认）
发起与资源审批 社区方向、重大活动与赞助费用审批 A（升级） CEO（当前：邴龙志·推断待确认）
开源准入 审批项目开源、许可证与代码范围 A（升级） CTO（当前：丁震宇·推断待确认）
法务 开源准入时的许可证与合规把关 C 法务负责人（当前：李瑶·推断待确认）
开源与布道 维护开源项目、布道分享、提交周报 R 开源/布道（当前：李子遥·推断待确认）
外部分享协调 线下分享对接与素材协调 R 线下分享协调（当前：吴亚军·推断待确认）
运营与宣发 外部活动联系、推文、新媒体 C 运营（当前：李凯·推断待确认）、新媒体（当前：鲁周毅·推断待确认）
社区技术支持 社区平台、论坛与代码仓库 C 开源聚变技术支持（当前：宋祺睿·推断待确认）、开放平台后端（当前：杨睿·推断待确认）
选拔赛与推广 选拔赛方案、推广拉新 C 选拔赛设计（当前：黄莹·推断待确认）、推广（当前：侯明月、邓乾·推断待确认）

3. 办之前请准备

  • 开源申请：项目说明、拟用许可证、仓库地址、是否含客户代码或敏感信息、维护人
  • 征集：征集主题、范围（地域/形式）、截止日期、审核标准
  • 周报：本周可写推文的贡献、内部可开源工具、可用于社区的工具
  • 外部活动：主办方、形式（赞助/演讲/展位）、费用、预期曝光与招聘效果

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定季度社区运营计划（社群、2B 开源社区、项目孵化、插件外包分成） 研究院生态负责人 每季度首周 知识库 运营计划 👤人工判断
2 开源准入审核：项目、许可证、代码范围，法务把关合规 CTO、法务 申请后 5 个工作日内 飞书审批 准入结论 🔧+👤
3 维护开源项目与贡献者名单 开源/布道 准入后 1 个工作日内登记 多维表格“开源名单” 名单记录 🔧飞书固化
4 统一表单征集内容/智能体/活动，写清范围口径，表单带审核状态 研究院生态负责人 每次征集前 3 个工作日发布 飞书表单 征集结果 🔧飞书固化
5 内容合规审核（不涉黄涉政、无客户与敏感信息）后发布论坛 运营 投稿后 1 个工作日内 AI 初审 + 人工复核 发布内容 🤖+👤
6 社区日常运营：论坛发帖、活动日历、群内答疑 运营、推广 每周 社区论坛、活动日历 运营记录 🔧飞书固化
7 每周五提交开源产出周报（含实习生产出），主责汇总 开源/布道 每周五 18:00 前 周报模板 周报 🔧+🤖
8 外部活动邀约登记 → 评估费用与曝光 → 指定唯一协调人对接 → 准备素材 研究院生态负责人、线下分享协调 登记后 3 个工作日内给结论 活动线索登记表 活动立项单 👤人工判断
9 月度复盘：社区成员、活跃度、投稿数、开源项目进展 研究院生态负责人 每月首周 多维表格看板 月度复盘 🤖自动化

5. 交付物与模板

  • 交付物：季度运营计划；开源名单；社区内容；开源周报；外部活动立项与复盘
  • 建议模板/表单：开源名单（项目、仓库、许可证、维护人、准入日期、状态、Star/贡献者数）；征集表单（类型：智能体/内容/活动、标题、作者、地域、形式、审核状态、审核人）；开源周报（可写推文的贡献、内部可开源工具、可用于社区的工具、下周计划）；外部活动立项单（活动、主办方、形式、费用、预期产出、协调人、结论）

6. 异常与升级

  • 拟开源代码含客户代码或敏感信息 → 驳回 → 升级 CTO 与法务（2 个工作日内）
  • 投稿涉及合规风险 → 下架并通知作者 → 升级研究院生态负责人（当天）
  • 外部赞助需付费 → 运营谈条件后出立项单 → 升级 CEO 审批（A（升级），3 个工作日内）
  • 项目拟对外开源 → 提交开源申请 → 升级 CTO 审批准入（A（升级），5 个工作日内），法务把关许可证；其余社区运营事项由研究院生态负责人拍板
  • 周报连续 2 周未交 → 主责提醒 → 升级生态市场条线负责人
  • 社区人气长期不足 → 月度复盘提出调整 → 升级 CEO 决定方向

7. 衡量指标

  • 周报按时率 = 按时提交的周数 ÷ 应交周数，目标 ≥ 90%
  • 投稿审核时长 = 投稿到发布的工作日数，目标 ≤ 1 天
  • 社区活跃度 = 月度发帖/回帖数与活跃成员数，按月环比
  • 开源准入覆盖率 = 已开源项目中经过准入审核的比例，目标 100%
  • 外部活动结论时效 = 邀约登记到给出结论的工作日数，目标 ≤ 3 天

8. 低效诊断

  • 现象：开源聚变具体负责人与分工不清，社区与开源项目谁负责说不明（职责定义缺失）｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 现象：没有社区运营方案和开源准入流程，开源名单靠员工自行加入（准入环节缺失）｜依据：「跃迁AI总动员」2026-08
  • 现象：内容/智能体/活动征集多次在全员群 @ 全体求助，靠人工拉人气（征集环节缺稳定渠道）｜依据：「模态集团（全员群）」2026-02、「模态集团（全员群）」2026-03
  • 现象：征集口径不一致，智能体不限地域而活动限本地，参与者易误解｜依据：「模态集团（全员群）」2026-04

9. 分支变体

  • 开源项目孵化：需过开源准入，确定维护人与许可证
  • 社区群与论坛运营：内容需合规审核，政府相关项目从严
  • 插件开发外包/分成：与 ECO-06 插件规范衔接，分成规则待定
  • 选拔赛：需额外设计参赛问卷与评选方案
  • 外部社区活动：赞助大会类需运营谈条件并报批；线下分享由协调人对接、素材由技术侧提供；可兼做招聘宣发

10. 待确认问题

  • 开源聚变社区唯一主责是谁？开源与布道是否正式归生态组？
  • 外部开源活动的统一对接人是谁？
  • 开源准入是否需要法务参与，审批人是 CTO 还是 CEO？
  • 周报汇报对象与模板是否固定？
  • 插件外包/分成模式是否推进，由谁定规则？
ECO-09内部项目开源孵化待优化54

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨3 × 险2

  • 适用场景：公司内部出现小而有趣、可独立开源的 idea 或工具（如 PR 审阅 Bot、本地多模态推理网关），需要征集、筛选立项、开发、评审并定期汇报进度时启动。
  • 负责人：主责——开源孵化管理（当前：杨萌·推断待确认）；协同——技术评审/创始人兼 CTO（当前：丁震宇·推断待确认）、项目开发者（当前：李子遥、葛家和·推断待确认）、idea 来源方（当前：陈梦琪、岳阳·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 征集 idea → ② 初筛 → ③ 立项并指定唯一负责人 → ④ 需求文档与里程碑 → ⑤ 开发与自动日报 → ⑥ AI 预审 + 人工 code review → ⑦ 每周进度更新 → ⑧ 结项转发布（ECO-10）或终止
  • 交付结果：通过评审、可编译可运行、带 README 的开源候选仓库，以及它在孵化看板中的完整记录（立项、里程碑、评审结论、周进度、结项结论）。
  • 状态依据：已有 leap-review 日报机器人、Gitea 仓库、置顶 wiki，也提出了 idea 收集表单；但收集表单“一直忘记建”，属事后补流程；2026-06～07 进度靠群内反复追问约 4 次；评审阶段才发现无法编译、依赖缺失。

1. 场景判定

  • 触发条件：员工或团队提出可独立运行、与核心商业代码解耦的小工具或 idea；或管理层指定某内部工具“后续作为项目开源出去”。
  • 典型说法：「整一个飞书收集表单吧，后续都作为项目开源出去」「最新进展如何」「今天下班前在群里汇报一下进度」
  • 判断问题：这个东西能否与公司核心产品代码、客户数据完全解耦？开源后是否有社区价值或品牌价值？是否有人愿意持续维护？
  • 不归本流程管：成果已就绪、需要合规核查、建公开仓库和推文 → 请走 ECO-10；员工给外部开源项目提 issue/PR、署名与贡献统计 → 请走 ECO-11；开源社区日常运营与产出汇报 → 请走 ECO-08；开源与保密规范本身的制定 → 请走 LEG-27；对外开源发布的审批 → 请走 LEG-29。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
孵化管理 维护收集表与看板、初筛、跟进进度、结项登记 R 开源孵化管理（当前：杨萌·推断待确认）
立项与技术评审 拍板立项、code review、判定阻断问题、决定终止 A 创始人兼 CTO（当前：丁震宇·推断待确认）
项目负责人/开发 写需求文档、开发、维护仓库、更新进度 R 项目开发者（当前：李子遥、葛家和·推断待确认）
测试 M3 后组织试用与测试 C 项目开发者（当前：葛家和·推断待确认）
idea 来源方 提供场景、验收是否满足需求 C idea 来源方（当前：陈梦琪、岳阳·推断待确认）
生态运营 知悉即将可发布的项目，准备 ECO-10 I 研究院生态（当前：陈梦琪·推断待确认）

3. 办之前请准备

  • idea 一句话描述、目标用户、使用场景、与现有产品的关系
  • 是否涉及公司业务代码、客户数据、内部账号或密钥（涉及则先走 LEG-30 保密审查）
  • 预计投入（人·周）和期望的首个可演示版本日期
  • 计划依赖的开源组件及许可证（对照 LEG-28）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过收集表提交 idea 任意员工 随时 飞书多维表格表单 idea 记录 🔧飞书固化
2 初筛：去重、判断是否与核心代码解耦、补全缺失信息 孵化管理 提交后 3 个工作日内 多维表格 + AI 预筛 初筛结论（通过/退回/合并） 🤖+👤
3 立项评审：定是否孵化、指定唯一项目负责人、定 M1～M3 里程碑 创始人兼 CTO 每两周集中评审一次 飞书会议、多维表格 立项记录 👤人工判断
4 编写需求文档（目标、范围、非目标、依赖、验收标准） 项目负责人 立项后 3 个工作日内 飞书文档（AI 起草） 需求文档 🤖自动化
5 建 Gitea 仓库，接入日报机器人与 CI 编译检查 项目负责人 立项后 1 个工作日内 Gitea、leap-review 日报机器人 仓库、自动日报 🤖+👤
6 开发，每个里程碑提交一个可编译、可运行版本 项目负责人 按里程碑日期 AI 编程工具 里程碑版本 🤖自动化
7 AI 预审后人工 code review，阻断问题必须修复后才能进下一里程碑 创始人兼 CTO 提交评审后 2 个工作日内 Gitea PR、AI 审阅 Bot 评审结论、阻断问题清单 🤖+👤
8 M3 后组织试用测试，问题回填仓库 issue 测试 M3 完成后 3 个工作日内 Gitea issue 测试问题清单 👤人工判断
9 每周五 18:00 前更新看板进度，机器人自动收集并汇总到群 项目负责人 每周五 18:00 前 多维表格 + 定时机器人 周进度汇总 🔧+🤖
10 结项：达到开源条件转 ECO-10；否则终止并记录原因 孵化管理 最后一个里程碑后 5 个工作日内 多维表格 结项/终止记录 👤人工判断

5. 交付物与模板

  • 交付物：idea 收集表、孵化项目看板、需求文档、Gitea 仓库（含 README、LICENSE 草案）、评审记录、周进度汇总、结项记录
  • 建议模板/表单：
    • idea 收集表：提交人、idea 名称、一句话描述、使用场景、是否涉及公司代码/数据、预计投入、期望首版日期
    • 孵化看板：项目名、项目负责人、状态（待评审/孵化中/评审中/待发布/已终止）、M1～M3 日期、仓库地址、最近评审结论、阻断问题数、本周进度、下周计划、风险

6. 异常与升级

  • 连续两周未更新进度 → 孵化管理在看板标红并提醒项目负责人 → 第 3 周周一仍未更新，升级创始人兼 CTO 决定延期或终止
  • 评审发现无法编译、依赖缺失等阻断问题 → 退回项目负责人 → 2 个工作日内未修复，升级创始人兼 CTO
  • 发现仓库含公司业务代码、密钥或客户数据 → 立即停止外部化、仓库保持私有 → 当日转 LEG-30 保密审查
  • 项目负责人调岗或无法继续 → 孵化管理 3 个工作日内重新指定负责人或提请终止
  • 机器人日报乱码或内容失真 → 暂停机器人，改为看板手工更新 → 由项目负责人 5 个工作日内修复

7. 衡量指标

  • 立项周期 = idea 提交到立项结论的自然日，目标 ≤ 14 天
  • 进度按时率 = 按时更新周进度的项目周数 / 应更新项目周数，目标 ≥ 90%
  • 评审一次通过率 = 首次 code review 无阻断问题的次数 / 评审总次数，目标 ≥ 70%
  • 孵化转发布率 = 转入 ECO-10 的项目数 / 立项项目数（按季度统计）
  • 催办次数 = 群内人工追问进度次数，目标每项目每月 ≤ 1 次

8. 低效诊断

  • 现象：征集环节缺载体，收集表单提出后长期未建，属事后补流程｜依据：「鼎慧产研决策部」2026-06
  • 现象：筛选权归属有分歧（开发者自筛还是管理方筛选），筛选与个人考核挂钩口径不清｜依据：「鼎慧产研决策部」2026-06
  • 现象：进度汇报无固定节奏，靠群内反复追问“最新进展”“下班前汇报”｜依据：「模态开源建设小组」2026-06
  • 现象：开发阶段没有“可编译”门槛，评审环节才发现阻断问题，导致返工｜依据：「模态开源建设小组」2026-06
  • 现象：日报机器人输出乱码、内容质量低，自动化未调优就投入使用｜依据：「模态开源建设小组」2026-06、「模态开源建设小组」2026-07

9. 分支变体

  • 无（工具类与网关类项目走同一流程；个人版、企业版的区分在 ECO-10 发布时处理）

10. 待确认问题

  • 孵化管理主责是否确定由产品侧负责？是否与研究院生态的开源社区运营（ECO-08）合并归口？
  • 立项评审每两周一次是否可行？立项拍板人是否只能是创始人兼 CTO，能否授权给研发负责人以去单点？
  • 孵化成果是否与个人 KPI 或积分挂钩？筛选权归孵化管理是否写入制度？
  • leap-review 日报机器人是否继续使用，还是统一改为多维表格 + 定时机器人收集？
  • “可开源”的判定标准（与核心产品解耦的边界）由谁书面定义？
ECO-10开源项目与技术成果对外发布待新建96

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：研发完成可对外展示的工具或技术成果（自研工具开源获客、国产硬件适配首发等），需要做首发调研、开源合规核查、建公开仓库与 README、对外推文宣传时启动。
  • 负责人：主责——开源运营/发布专员（当前：李子遥·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、技术作者（当前：杨云峰·推断待确认）、对外沟通与厂商协调（当前：常元和·推断待确认）、推文宣传（当前：刘昱潇·推断待确认）、CI/开源技术顾问（当前：吴世豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 成果登记 → ② 宣传价值判断与首发调研 → ③ 开源合规核查 → ④ 上游/厂商确认 → ⑤ 发布审批（LEG-29）→ ⑥ 建仓库与 README → ⑦ 对外口径核对 → ⑧ 公开与推文 → ⑨ 台账登记与发布后维护
  • 交付结果：公司 GitHub 组织下已公开、带 README/LICENSE/贡献指南的仓库，经核对的对外推文，以及研发成果与开源项目台账中的完整记录。
  • 状态依据：2026-02 首批开源项目发布前无许可证、脱敏、代码扫描记录；2026-03 国产硬件适配成果的合规与口径靠群内争论，推文表述事后纠正；开源标准化文档 2026-03 起仍为草稿；2026-04 CEO 指出研发成果“非研发绝大多数人不知道”。

1. 场景判定

  • 触发条件：研发成果可对外展示（新工具、国产硬件首发适配、性能突破等），或管理层提出“宣传一下”“开源出去”。
  • 典型说法：「开源生态第一步」「你先整个 private 的 org repo」「今天下午就要看到 repo」「什么时候宣传一下」
  • 判断问题：成果是否包含厂商闭源代码、私有镜像或客户数据？是否真的首发？对外表述（适配、移植还是 backport）是否准确？发布后谁维护？
  • 不归本流程管：内部 idea 还在开发阶段 → 请走 ECO-09；员工个人向外部项目提 PR/署名 → 请走 ECO-11；开源发布审批表单本身 → 请走 LEG-29；引入外部开源组件的许可证评估 → 请走 LEG-28；不开源、只做新闻稿宣传 → 请走 BRD-09；产品/项目重名与命名 → 请走 BRD-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
开源运营/发布专员 登记、首发调研、合规清单、仓库与发布执行、台账维护 R 开源运营/发布专员（当前：李子遥·推断待确认）
发布审批人 判断宣传价值、审批是否开源及开源范围 A 创始人兼 CTO（当前：丁震宇·推断待确认）
技术作者 提供成果、写 README/教程、核对技术表述 R 技术作者（当前：杨云峰·推断待确认）
对外沟通与厂商协调 与厂商/上游沟通确认、协调联合宣传 R 对外沟通负责人（当前：常元和·推断待确认）
推文宣传 撰写与发布推文、跟踪传播数据 R 推文宣传（当前：刘昱潇·推断待确认）
开源技术顾问 建议向上游提交 patch 等开源惯例 C CI/开源技术顾问（当前：吴世豪·推断待确认）
法务 许可证、知识产权、厂商代码合规意见 C 法务负责人（当前：李瑶·推断待确认）
CEO 重大首发/厂商联合宣传知情并定调 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 成果说明：做了什么、和已有方案的区别、截图或演示视频
  • 代码来源清单：自研部分、上游开源部分、厂商修改或提供的部分（含镜像、工具链）
  • 依赖许可证清单与密钥扫描结果
  • 拟用项目名（已查重名）、拟用许可证、计划维护人
  • 是否涉及厂商合作或需要厂商同意的表述

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在研发成果登记表登记成果，机器人通知生态与市场 技术作者 成果完成后 1 个工作日内 多维表格 + 机器人 成果记录 🔧+🤖
2 判断宣传价值；AI 检索是否首发、有无重名项目 开源运营 + 创始人兼 CTO 登记后 2 个工作日内 AI 检索、GitHub 首发调研结论 🤖+👤
3 先建公司组织下私有仓库，整理代码 技术作者 决定发布后 1 个工作日内 GitHub 组织 私有仓库 🔧飞书固化
4 按清单做合规核查：许可证、厂商闭源代码/私有镜像、密钥与数据脱敏、商标重名 开源运营 + 法务 3 个工作日内 扫描脚本、核查清单 合规核查记录 🤖+👤
5 涉及厂商或上游改动的，先与对方沟通并取得书面确认；适合的改动向上游提交 patch 对外沟通负责人、技术作者 公开前完成 邮件/飞书 厂商确认记录 👤人工判断
6 发起开源发布审批（附合规记录、开源范围、维护人） 开源运营 核查完成后当日 飞书审批（LEG-29） 审批单 🔧飞书固化
7 写 README、教程、LICENSE、贡献指南（AI 起草，作者审） 技术作者 审批期间并行，2 个工作日内 AI 编程工具 仓库文档 🤖自动化
8 推文起草，技术表述由作者逐句核对（如“backport”与“适配”不得混用） 推文宣传、技术作者 公开前 1 个工作日 飞书文档（BRD-14） 定稿推文 👤人工判断
9 仓库转公开、发布推文，需要时与厂商联合宣传 开源运营、推文宣传 审批通过后 2 个工作日内 GitHub、新媒体 公开仓库、推文 🔧飞书固化
10 登记开源项目台账；发布后 30 天内每周统计 star/issue/PR 并响应 issue 开源运营 发布当日登记，之后每周一 多维表格 + 脚本 台账与周数据 🤖自动化

5. 交付物与模板

  • 交付物：研发成果登记记录、首发调研结论、合规核查记录、发布审批单、公开仓库、推文、开源项目台账
  • 建议模板/表单：
    • 研发成果登记表：成果名、技术作者、完成日期、一句话亮点、截图/视频、是否可开源、是否可宣传、涉及厂商、状态
    • 开源发布检查清单：项目名查重、许可证、第三方代码来源、厂商确认、密钥扫描、数据脱敏、README、LICENSE、维护人、推文定稿、品牌元素
    • 开源项目台账：项目名、仓库地址、许可证、维护人、发布日期、star、核心贡献者、最近更新

6. 异常与升级

  • 发现厂商闭源代码或私有镜像 → 暂停公开，仅保留私有仓库 → 对外沟通负责人 3 个工作日内取得厂商意见，无结论升级 CEO
  • 推文发布后发现技术表述错误 → 24 小时内更正或删除重发 → 通报创始人兼 CTO
  • 无人写 README 或无维护人 → 不得转公开 → 开源运营当日提醒，次日升级创始人兼 CTO
  • 项目名与已有知名项目或商标冲突 → 转 BRD-01 改名 → 改名完成前不公开
  • 管理层要求“当天出 repo” → 允许先建私有仓库，合规核查与审批不得跳过

7. 衡量指标

  • 发布周期 = 成果登记到仓库公开的工作日，目标 ≤ 10 个工作日
  • 合规清单完成率 = 发布前完成全部检查项的项目数 / 发布项目数，目标 100%
  • 对外表述更正次数 = 发布后需更正的推文/README 次数，目标 0
  • issue 首次响应时长 = issue 创建到首次回复的工作日，目标 ≤ 3 个工作日
  • 成果宣传覆盖率 = 已宣传成果数 / 登记为“可宣传”的成果数（季度统计）

8. 低效诊断

  • 现象：首批开源发布前没有许可证、脱敏、代码扫描等记录，合规属事后补｜依据：「⭐大模型基座事业群」2026-02
  • 现象：开源项目负责人随事调整，发布后维护归属不清｜依据：「⭐大模型基座事业群」2026-02
  • 现象：涉及厂商修改代码的成果，合规与对外口径靠群内争论，发布前未先与上游确认｜依据：「鸽子群模态分群」2026-03
  • 现象：README 没人主动写，被追问才补；推文技术表述发布后需纠正｜依据：「鸽子群模态分群」2026-03
  • 现象：研发成果信息孤岛，非研发人员不知道已有成果，宣传靠转发后追问｜依据：「董事会」2026-03、「董事会」2026-04
  • 现象：开源标准化文档长期停在草稿，star 与核心贡献者统计未整理｜依据：「董事会」2026-03

9. 分支变体

  • 工具开源获客：分个人本地版与企业 2B 版，2B 版需额外确认不含商业功能代码
  • 国产硬件适配首发：必须先取得厂商确认，可与厂商联合宣传；优先考虑向上游提交 patch
  • 开源聚变社区项目：发布后同步到社区运营（ECO-08）
  • 仅宣传不开源（如产品集成能力展示）：跳过步骤 3～7，转 BRD-09

10. 待确认问题

  • 主责是否设为专门的开源运营/发布专员，还是由技术作者自行负责？创始人兼 CTO 的审批权能否下放？
  • 法务是否必须会签每个开源发布？无法务时由谁出合规意见？
  • 首发调研由开源运营还是市场负责？“首发”结论是否需要 CEO 确认后才能宣传？
  • 研发成果登记表由谁建、谁维护？是否强制研发每次成果都登记？
  • 开源发布的奖金或激励规则是否成文？与积分制度（HR-18）如何衔接？
ECO-11开源贡献署名、报备与统计待新建48

状态：待新建｜证据：有证据（卡片 5 张 / 会话 7 个）｜优先级：频2 × 耗2 × 跨3 × 险4

  • 适用场景：员工以公司名义给外部开源项目提 issue/PR、需要统一署名；工作时间提交外部贡献需要报备；或领导、投资方、政府申报、对外合作需要公司开源贡献清单时启动。
  • 负责人：主责——开源贡献台账管理（当前：李子遥·推断待确认）；协同——创始人兼 CTO（统筹报送，当前：丁震宇·推断待确认）、GitHub 组织管理员（当前：王皓南·推断待确认）、技术验证（当前：宋祺睿·推断待确认）、研究院生态负责人（当前：陈梦琪·部门报送）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 统一公司 GitHub 组织与公共邮箱 → ② 署名规则执行 → ③ 工作时间外部 PR 报备 → ④ 合入后登记台账（脚本自动拉取）→ ⑤ 每周开源产出汇报 → ⑥ 报送需求按口径筛选 → ⑦ 人工核实后对外报送
  • 交付结果：一份持续更新、可链接验证的“开源贡献台账”，以及按报送对象口径导出的贡献清单；外部贡献统一带公司署名标识。
  • 状态依据：署名方式、是否用企业邮箱、是否算公司赞助仅在 2026-02 口头讨论，无成文规范；2026-03 两次临时收集贡献清单，当日通知当晚截止，统计口径当天多次变动；2026-04 建组织账号时命名反复、账号被抢注。

1. 场景判定

  • 触发条件：（1）员工准备向外部开源项目提 issue/PR；（2）新员工入职或公司更名需要配置署名；（3）领导、投资方、政府申报、对外见面需要开源贡献清单。
  • 典型说法：「提 issue 的时候想说明自己是公司的，应该怎么带上信息」「给其他开源项目提 PR 要审批吗」「公司正在统计大家参与过的有名的开源项目」「你的开源贡献仓库发我一下」
  • 判断问题：这次贡献是在工作时间或使用公司资产（设备、账号、算力、代码）完成的吗？是否包含公司代码？报送对象是谁、需要什么口径？
  • 不归本流程管：把公司自有项目开源出去 → 请走 ECO-10；员工个人开源账号入职备案与开源发布审批 → 请走 LEG-29；开源与保密规范制定 → 请走 LEG-27；开源人才外联招聘 → 请走 X-RCT-05。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账管理 维护贡献台账、运行统计脚本、按口径导出清单 R 开源贡献台账管理（当前：李子遥·推断待确认）
统筹与报送 确定报送口径、审核清单真实性、对外报送 A 创始人兼 CTO（当前：丁震宇·推断待确认）
组织管理员 管理 GitHub 组织、命名规范、成员与外部贡献者权限 R GitHub 组织管理员（当前：王皓南·推断待确认）
技术验证 验证 Co-Authored-By 等标识可被统计 C 研发（当前：宋祺睿·推断待确认）
贡献者 按规则署名、报备、确认个人贡献记录 R 全体研发
生态运营 接收每周开源产出汇报，用于推文与社区 I 研究院生态负责人（当前：陈梦琪·部门报送）
法务 判断贡献是否涉及公司代码与保密 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 署名：企业邮箱已绑定个人 GitHub 账号、已加入公司 GitHub 组织
  • 报备：目标项目地址、PR/issue 链接、是否在工作时间、是否包含公司代码或内部信息
  • 统计/报送：报送对象、用途、截止时间、口径（平台、star 门槛、贡献类型）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 维护公司 GitHub 组织与公共邮箱；仓库名全小写、用连字符，不带地名等后缀；区分内部成员与外部贡献者权限 组织管理员 常态维护；公司英文名变更后 5 个工作日内同步 GitHub 组织 组织配置 🔧飞书固化
2 新员工入职时绑定企业邮箱、加入组织（与 LEG-29 账号备案同步办理） 贡献者、组织管理员 入职后 5 个工作日内 GitHub、飞书 组织成员记录 🔧飞书固化
3 署名：工作时间或使用公司资产的贡献，用企业邮箱作 author、加 Signed-off-by，PR 描述末尾注明由公司赞助；issue 不强制 贡献者 每次提交时 Git 带公司标识的提交 🔧飞书固化
4 工作时间提交外部 PR 前在报备表登记；含公司代码的必须先审批，不含的登记即可；非工作时间且不含公司代码的个人贡献无需报备 贡献者 提交 PR 前 多维表格表单 报备记录 🔧飞书固化
5 脚本按组织成员账号每周拉取已合入的 PR/commit，写入贡献台账 台账管理 每周一 脚本 + 多维表格 更新后的台账 🤖自动化
6 每周五汇总本周开源产出（可推文的贡献、可开源工具、社区工具）给生态运营 台账管理 每周五 18:00 前 多维表格视图 + 机器人 周开源产出 🔧+🤖
7 收到报送需求后，书面确定口径（平台、star 门槛、贡献类型、截止时间） 创始人兼 CTO 需求到达当日 飞书文档 报送口径说明 👤人工判断
8 从台账按口径导出清单，员工确认个人条目并剔除敏感项目 台账管理、贡献者 口径确定后 1 个工作日内 多维表格 待审清单 🤖+👤
9 核实每条贡献可链接验证，不夸大，审核后报送 创始人兼 CTO 报送截止前 飞书文档 报送清单 👤人工判断

5. 交付物与模板

  • 交付物：《开源贡献与署名规范》、GitHub 组织、外部 PR 报备表、开源贡献台账、周开源产出、各次报送清单
  • 建议模板/表单：
    • 外部 PR 报备表：贡献者、目标项目、PR/issue 链接、提交日期、是否工作时间、是否含公司代码、审批结论
    • 开源贡献台账：贡献者、GitHub 账号、项目名、项目 star、贡献类型（PR/commit/issue/维护者）、链接、合入日期、是否带公司署名、是否可对外披露
    • 报送口径说明：报送对象、用途、平台范围、star 门槛、贡献类型、截止时间、审核人

6. 异常与升级

  • 外部 PR 含公司代码或内部信息但未审批 → 贡献者立即关闭或撤回 PR → 当日报告法务与创始人兼 CTO
  • 报送需求时间不足 1 个工作日 → 只用台账现有数据，不临时扩口径 → 由创始人兼 CTO 向需求方说明
  • 组织名或邮箱被抢注、需改名 → 组织管理员向平台提工单 → 3 个工作日无进展升级创始人兼 CTO
  • 员工认为某贡献属敏感项目 → 标记“不可对外披露”，不进入报送清单
  • 报送清单出现无法验证或夸大的条目 → 删除该条目，报送人负责核实

7. 衡量指标

  • 台账覆盖率 = 台账中有记录的研发人数 / 有外部开源贡献的研发人数，目标 ≥ 90%
  • 报送准备时间 = 收到需求到提交清单的工作日，目标 ≤ 1 个工作日
  • 署名合规率 = 工作时间外部 PR 中带公司标识的比例，目标 ≥ 95%
  • 未报备外部 PR 数 = 抽查发现未报备的工作时间 PR 数，目标 0
  • 公司署名合入 PR 数（按月统计，看趋势）

8. 低效诊断

  • 现象：每次对外见面或报送前临时收集贡献，个人手动回忆仓库｜依据：「鼎慧产研决策部」2026-03、「技术部」2026-03
  • 现象：统计口径当天多次变动（star 门槛、是否只算 GitHub、有 PR 即算），当日通知当晚截止｜依据：「技术部」2026-03
  • 现象：对外包装提出“沾边就算”，真实性缺核实环节｜依据：「鼎慧产研决策部」2026-03
  • 现象：署名方式、是否使用企业邮箱、是否算公司赞助仅口头讨论，没有成文规则｜依据：「模态AI探索小分队」2026-02
  • 现象：组织账号与邮箱命名反复尝试、被抢注，相关品牌元素无人落实｜依据：「开源&保密规范评审」2026-04
  • 现象：公司英文宣传名变更后，组织显示名需二次修改｜依据：「模态开源建设小组」2026-06

9. 分支变体

  • issue 与 PR：PR 必须带公司署名；issue 可选
  • 个人账号与公司组织账号：个人账号贡献用企业邮箱署名；公司项目一律放公司组织下
  • 报送对象：政府申报（侧重知名项目与贡献数量）、投资机构（侧重影响力与核心维护者）、对外合作见面（侧重与对方相关的项目）

10. 待确认问题

  • 台账管理主责是否由开源运营岗承担？与 ECO-10 开源项目台账是否合并为一张表？
  • “工作时间外部 PR 需报备、含公司代码需审批”是否作为正式规则？审批人是法务还是创始人兼 CTO？
  • “知名项目”的 star 门槛定多少？是否只统计 GitHub？
  • 公司赞助标识用哪个英文名？公司英文名变更后历史提交是否需要处理？
  • 每周开源产出汇报给研究院生态是否作为固定机制？
ECO-12外部活动/会议参会与信息回收待新建54

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨3 × 险3

  • 适用场景：收到或决定参加外部社区答辩、专家评审、开源会议、技术派对、社区分享会等活动，需要选派人员、报名、准备材料，并在会后回收纪要与人脉信息时启动。
  • 负责人：主责——生态运营（外部活动对接）（当前：待指定）；协同——活动对接人（当前：杨萌·推断待确认）、研发派员决策/创始人兼 CTO（当前：丁震宇·推断待确认）、参会代表（当前：王皓南、宋祺睿、魏宗浩、李子遥·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 登记邀请 → ② 定目标与是否参加 → ③ 指定唯一带队人与参会人、报名 → ④ 征集问题、准备材料与演示 → ⑤ 日程与提醒 → ⑥ 现场参会 → ⑦ 会后 2 个工作日内出纪要 → ⑧ 人脉与线索回流 → ⑨ 产出登记
  • 交付结果：外部活动登记表中一条完整记录（目标、参会人、材料、纪要链接、产出），以及回流到资源池/招聘/销售的联系人与线索。
  • 状态依据：2026-02 开源会议纪要临时决定建文档；2026-03 技术派对参会无事前目标、预算和产出要求，参会人与讲稿临时确定，现场出现“查出发言者背景”类要求；提醒依赖机器人且时有失灵，无活动清单。

1. 场景判定

  • 触发条件：外部社区、会议主办方、合作方发来邀请（答辩、评审、分享、派对、开源大会），或员工发现有价值的活动建议参加。
  • 典型说法：「那个答辩我可能没时间去」「整个飞书文档记一下吧，同步在群里」「看看有没有技术大牛，招一个」「已经面对面建群了」
  • 判断问题：这是去“参加/听会/交流”，还是去“讲课/布道”？是否需要公司出钱摆摊或赞助？
  • 不归本流程管：展会/行业大会的情报收集、是否摆摊或赞助的评估 → 请走 MKT-01；应邀去讲课、培训、布道 → 请走 ECO-13；活动后的销售线索跟进 → 请走 MKT-07；招聘人才外联 → 请走 X-RCT-05；公司自办大会 → 请走 ECO-16。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动对接 登记邀请、发起决策、报名、跟进纪要与产出 R 生态运营（外部活动对接）（当前：待指定）
派员决策 决定是否参加、派哪位研发 A 创始人兼 CTO（当前：丁震宇·推断待确认）
原对接人 转交邀请信息、交代背景 C 活动对接人（当前：杨萌·推断待确认）
带队人 现场负责、写纪要、回流信息 R 参会代表（当前：王皓南·推断待确认）
参会人 参会、演示、收集信息 R 参会代表（当前：宋祺睿、魏宗浩、李子遥·推断待确认）
内部关注人 提交想问的问题、阅读纪要 I 相关团队成员

3. 办之前请准备

  • 活动信息：名称、主办方、时间地点、线上/线下、报名截止时间、费用、是否需要上台
  • 参加目标：品牌曝光 / 招聘 / 合作 / 学习，至少选一项并写预期产出
  • 上台场次：议题、演示环境、介绍公司的标准材料（从 MKT-09 素材库取）
  • 预算与差旅（如有，走 FIN-07 差旅事前报备）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到邀请后登记外部活动表 活动对接 收到后 1 个工作日内 多维表格表单 活动记录 🔧飞书固化
2 判定目标与是否参加；需研发参加的由创始人兼 CTO 决定人选 活动对接、创始人兼 CTO 登记后 2 个工作日内，且早于报名截止 3 天 多维表格 参加决定 👤人工判断
3 指定唯一带队人和参会人，完成报名/购票 活动对接 决定后 1 个工作日内 活动平台、飞书 报名凭证 🔧飞书固化
4 在群内征集同事想问的问题；上台场次准备材料与演示环境 带队人 活动前 3 个工作日材料定稿 飞书文档 问题清单、材料 🤖+👤
5 发飞书日程给参会人，截止前 1 天和活动前 1 天自动提醒 活动对接 报名后当日 飞书日历、机器人 日程与提醒 🔧+🤖
6 现场参会，记录要点；只交换对方自愿提供的联系方式，不做个人背景深挖 带队人、参会人 活动当天 飞书妙记/录音（主办方允许时） 现场记录 👤人工判断
7 按模板写会后纪要并同步群 带队人 活动后 2 个工作日内 飞书文档 + 妙记 AI 纪要 会后纪要 🤖自动化
8 联系人入生态资源池；招聘线索转 X-RCT-05，商务线索转 MKT-07 带队人 活动后 3 个工作日内 多维表格 回流记录 🔧飞书固化
9 在活动表填写产出与评价（是否值得再参加） 活动对接 活动后 5 个工作日内 多维表格 产出评价 👤人工判断

5. 交付物与模板

  • 交付物：外部活动登记表、报名凭证、会前问题清单、会后纪要、资源/线索回流记录
  • 建议模板/表单：
    • 外部活动登记表：活动名、主办方、类型（答辩/评审/开源会议/派对/社区分享）、时间、地点、报名截止、目标、带队人、参会人、是否上台、预算、纪要链接、产出、评价
    • 会后纪要模板：活动概况、关键信息与观点、回答了哪些会前问题、结识的机构与联系人（仅公开信息）、可跟进事项（负责人+日期）、是否建议再参加

6. 异常与升级

  • 带队人临时无法参加 → 至少提前 1 个工作日由活动对接指定替补 → 无替补时升级创始人兼 CTO 决定放弃或调人
  • 报名截止前未完成决策 → 活动对接在截止前 1 天提醒决策人 → 仍无结论默认不参加
  • 机器人提醒失效 → 改用飞书日程提醒，不再依赖聊天指令
  • 有人要求收集发言者或参会者超出公开范围的个人信息 → 拒绝执行 → 报法务（当日）
  • 主办方声明不可录音录像或保密场次 → 不录音、不外传，纪要只写公开内容
  • 活动后 2 个工作日未交纪要 → 活动对接提醒 → 第 4 个工作日升级带队人上级

7. 衡量指标

  • 纪要按时率 = 2 个工作日内交纪要的活动数 / 参加活动数，目标 100%
  • 有产出活动占比 = 产出至少 1 条可跟进线索/联系人/合作的活动数 / 参加活动数（季度统计）
  • 临时换人率 = 活动前 1 天内换人的次数 / 参加活动数，目标 ≤ 10%
  • 报名逾期数 = 因决策晚错过报名的活动数，目标 0

8. 低效诊断

  • 现象：参会人与上台人临时决定，活动前一天才赶 PPT｜依据：「鸽子群模态分群」2026-03
  • 现象：参会前没有目标、预算、产出要求，信息靠现场私加微信，会后无统一回收｜依据：「鸽子群模态分群」2026-03
  • 现象：现场布置“查出发言者背景”类任务，个人信息收集缺边界｜依据：「鸽子群模态分群」2026-03
  • 现象：纪要是否记录、记在哪临时决定，无会前问题征集与会后跟进模板｜依据：「技术部」2026-02
  • 现象（外部参照）：社区运营方同一通知多次重发、时间发错后更正、妙记链接无汇总，可作为本公司活动信息管理的反面参照｜依据：「奇绩校友飞书群」2026-01、「奇绩校友飞书群」2026-09

9. 分支变体

  • 社区答辩/专家评审：必须提前定上台人、议题和演示环境，答辩前 1 天彩排
  • 技术派对/线下公开课：以招聘与人脉为主，会后重点做 X-RCT-05 回流
  • 开源国际会议：线下派代表 + 其他人注册线上票，会前统一征集问题
  • 外部社区分享会/圆桌：表单报名、线下需寄存通讯设备、可能有异地分会场，会后向主办方索取妙记

10. 待确认问题

  • 外部活动对接主责放在研究院生态、市场部还是运营？与 MKT-01 的分界（本流程只管“参加”，MKT-01 管情报与是否摆摊赞助）是否认可？
  • 派研发参加外部活动是否都需要创始人兼 CTO 同意，能否授权研发负责人决定？
  • 纪要 2 个工作日的时限是否可行？
  • 现场收集联系人信息的边界是否需要法务出成文规定？
  • 外部活动登记表与 ECO-01 年度活动日历是否合并？
ECO-13对外讲课、培训与布道宣讲待优化108

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：已确认接下高校课程、政府/合作方培训、参访交流、布道宣讲、Meetup 等对外讲课场次，需要排讲师、拼装标准内容、核验案例、交付授课并回收反馈时启动；也包括内部分享材料转成外部课程。
  • 负责人：主责——外部分享负责人/讲师统筹（当前：陈梦琪·推断待确认）；协同——场次与内容要求提出/CEO（当前：邴龙志·推断待确认）、研发讲师调度/创始人兼 CTO（当前：丁震宇·推断待确认）、讲师/布道官（当前：李子遥、望政韬、王皓南·推断待确认）、内部分享组织（当前：杨萌·推断待确认）、标杆案例组长（当前：白福康·推断待确认）、参访接待（当前：杨朋伟·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 场次需求单 → ② 查讲师库档期并排班 → ③ 从标准内容包拼装课件 → ④ 案例与数据核验 → ⑤ 课件评审定版 → ⑥ 演示环境与物料就绪 → ⑦ 授课 → ⑧ 反馈回收与内容包更新 → ⑨ 讲师工作量登记
  • 交付结果：按时、按听众定制完成的授课场次，定版课件归档，反馈与新 FAQ 回填到标准内容包，讲师工作量入台账。
  • 状态依据：已有讲师信息收集表、布道官速成手册 v2.0 和多版布道手册，方向是对的；但 2026-03 出现前一天才定讲师、“每人教一点”拼 PPT、案例汇报版看不懂需重做，2026-05 讲师邀请多层转达、讲师自己写稿，内容包与排班机制都未固化。

1. 场景判定

  • 触发条件：外部邀请已经接单（MKT-08 已登记确认），或 CEO/合作方指定培训、参访、宣讲任务，或内部分享材料需要转为外部课程。
  • 典型说法：「想让你下周作为讲师出去讲个课」「形成一个标准讲东西的方案吧，以后会很多」「只能每个人教一点，然后拼一个能讲的 PPT」「能周末帮忙去讲一场吗」
  • 判断问题：听众是谁（学生/企业/政府）？时长多少？是否需要现场演示？这次能否从现有内容包拼装，而不是从零写？
  • 不归本流程管：邀请接单登记、场次评估、向主办方报讲师简介 → 请走 MKT-08；PPT 版式设计、外发加水印 → 请走 MKT-09；公司内部分享会本身 → 请走 GEN-07；FDE 认证课程开发 → 请走 X-FDE-16；培训营报名、分班与学员管理 → 请走 ECO-22～ECO-28；只去听会不讲课 → 请走 ECO-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
讲师统筹 建需求单、排班、维护讲师库与内容包、回收反馈 R/A 外部分享负责人（当前：陈梦琪·推断待确认）
场次要求方 说明听众、时长、重点，重要场次审定课件 C CEO（当前：邴龙志·推断待确认）
研发讲师调度 同意研发人员外出讲课，协调资源 C 创始人兼 CTO（当前：丁震宇·推断待确认）
讲师/布道官 拼装课件、准备演示、授课、回填 FAQ R 讲师（当前：李子遥、望政韬、王皓南·推断待确认）
内部分享组织 把内部分享材料移交给讲师统筹 C 内部分享组织（当前：杨萌·推断待确认）
案例负责人 提供可复现的标杆案例与可信度分级 C 标杆案例组长（当前：白福康·推断待确认）
生态运营 协助讲师准备现场与回收素材 C 生态运营（按场次指定）
参访接待 参访类场次的对接与接待 R 参访接待（当前：杨朋伟·推断待确认）

3. 办之前请准备

  • 场次需求单：主办方、听众类型（C 端学生/B 端企业/G 端政府）、人数、时长、日期地点、重点（科普/案例/生态）、是否需演示、主办方是否提供素材
  • 讲师库：讲师、可讲主题、可讲时段、历史场次与评价
  • 标准内容包：科普模块、案例场景模块、生态与公司产品模块，各带 FAQ；C 端地推版、B 端宣传版、G 端汇报版三套组合
  • 演示环境：已配置好的演示账号与设备

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写场次需求单，内容要求不清的当场向主办方/要求方问清 讲师统筹 接单后 1 个工作日内 多维表格表单 场次需求单 🔧飞书固化
2 查讲师库档期排班；优先生态讲师与布道官，非必要不派研发；派研发需本人同意并告知创始人兼 CTO 讲师统筹 活动前 14 天（周末场次同样提前 14 天） 讲师库多维表格 排班结果 🔧+👤
3 从内容包按配比拼装课件（参考：科普 50% + 专业 30% + 生态 10% + 公司产品 10%），按听众选版本 讲师 活动前 5 个工作日出初稿 飞书文档 + AI 拼装 课件初稿 🤖自动化
4 核验案例与数字：只用可复现（如十次成功八次以上）且证据链完整的 A/B 级案例 讲师统筹、案例负责人 活动前 3 个工作日 案例库多维表格 核验结论 👤人工判断
5 课件评审定版；G 端或重要场次由 CEO 审 讲师统筹（重要场次 CEO） 活动前 2 个工作日 飞书文档评论 定版课件 👤人工判断
6 跑通演示环境，备好二维码、社群入口与宣传物料 讲师、生态运营 活动前 1 个工作日 演示设备 就绪清单 🔧飞书固化
7 授课；参访类场次由参访接待负责全程 讲师 活动当天 — 完成场次 👤人工判断
8 回收现场反馈与新问题，补到内容包 FAQ；课件归档；听众联系人入资源池 讲师 活动后 2 个工作日内 多维表格、知识库 反馈记录、FAQ 更新 🤖+🔧
9 登记讲师工作量，按积分制度（HR-18）计入 讲师统筹 每月 5 日前 多维表格 讲师工作量台账 🔧飞书固化

5. 交付物与模板

  • 交付物：场次需求单、讲师库与档期表、标准内容包（三模块 + FAQ + 三个版本）、定版课件、反馈记录、讲师工作量台账
  • 建议模板/表单：
    • 场次需求单：场次名、主办方、听众类型、人数、时长、日期地点、重点、是否演示、对方素材、讲师、状态
    • 讲师库：讲师、所属部门、可讲主题、可讲时段、累计场次、平均评价、是否需上级同意
    • 案例库：案例名、场景、复现成功率、可信度分级（A/B/C）、适用听众、截图/视频、负责人

6. 异常与升级

  • 活动前 7 天仍无讲师 → 讲师统筹升级生态市场条线负责人 → 仍无人时与主办方协商改期或缩短时长（活动前 5 天内定）
  • 讲师临时无法出席 → 讲师本人至少提前 2 天告知 → 讲师统筹从讲师库找替补，用同一套定版课件代讲
  • 要求方对内容方向有新要求 → 活动前 2 个工作日后原则上不改，确需修改由要求方书面确认
  • 案例现场演示失败 → 切换录屏兜底；会后 2 个工作日内案例负责人复测并更新成功率
  • 研发讲师本人不愿意 → 不强派，改用布道官或生态讲师

7. 衡量指标

  • 排班提前量 = 讲师确定日到活动日的天数，目标 ≥ 14 天
  • 内容复用率 = 由内容包拼装的课件数 / 课件总数，目标 ≥ 80%
  • 临时救火次数 = 活动前 3 天内才确定讲师的场次数，目标 0
  • 场次满意度 = 主办方/听众评分均值，目标 ≥ 4（5 分制）
  • 研发外出讲课占比 = 研发讲师场次 / 总场次（看趋势，逐步下降）

8. 低效诊断

  • 现象：讲师排班无提前量，培训前一天才确定讲师｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：没有标准内容包，场次内容靠“每人教一点”拼 PPT，每次临时对需求｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：宣讲依赖 CEO 本人到场，缺代讲机制；布道官与生态谁来讲不清｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：宣讲数字像营销口径、证据链不够硬；汇报版案例领导看不懂需重做｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：讲课邀请多层转达，讲师自填收集表、自己从零写稿，邀请方素材未复用｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 高校课程/进校园：多为周末场次，讲师库优先排生态讲师与助教
  • 政府/领导培训与参访：G 端汇报版，CEO 审课件，参访接待全程陪同
  • 布道宣讲/Meetup：用布道官手册（两页能讲、十分钟能演），按 C 端地推版或 B 端宣传版组合
  • 内部分享转外部课程：内部分享（GEN-07）完成后，组织者 5 个工作日内把材料移交讲师统筹改造为外部课程，原分享人非必要不参与外部授课

10. 待确认问题

  • 讲师统筹主责是否为研究院生态负责人？与 MKT-08 的分界（MKT-08 管接单与报简介，本流程管排班、内容与交付）是否认可？
  • 提前 14 天排班是否可行？周末场次是否有额外激励？
  • 内容配比（科普/专业/生态/公司产品）是否作为固定标准？三个版本由谁维护？
  • 案例可信度分级标准与“十次成功八次”复现门槛是否适用于所有案例？
  • 研发外出讲课是否需要创始人兼 CTO 审批，还是告知即可？
ECO-14高校/校园生态合作与校园大使待新建180

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：围绕高校与 OPC 平台开展校园合作（算力赞助、补贴券推广、校园大使招募与邀请码分润、全员转发引流）时启动。
  • 负责人：主责——校园生态运营（当前：陈梦琪·推断待确认）；协同——高校/政府关系与方向拍板/CEO（当前：邴龙志·推断待确认）、算力赞助方案（当前：李凯·推断待确认）、校园大使招募执行/行政（当前：侯明月、丁蕊·推断待确认）、邀请码需求/产品（当前：杨萌·推断待确认）、开发（当前：张康·推断待确认）、测试（当前：张东郅·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 合作立项（目标、高校、预算、KPI）→ ② 赞助/补贴/分润规则发布 → ③ 校园大使招募与高校覆盖 → ④ 邀请码与分润系统上线（含压测）→ ⑤ 统一素材包与全员转发 → ⑥ 补贴/算力发放 → ⑦ 月度提成结算与提现 → ⑧ 月度复盘
  • 交付结果：已立项的校园合作计划、在岗校园大使名单与高校覆盖看板、可追踪的邀请码推广数据、经财务核对的补贴与提成发放记录、月度复盘。
  • 状态依据：2026-03 高校/OPC/政府合作停在战略讨论，无排期与负责人；2026-04 算力赞助无立项与预算、补贴到账快慢不一；校园大使招募由行政承担但归属不清；提成提现靠线下转账后台手工确认，缺财务介入；邀请码系统压测崩溃返工。

1. 场景判定

  • 触发条件：管理层提出校园推广目标；政府补贴券领取任务需要推动；需要招募校园大使；需要给学生或高校提供算力赞助。
  • 典型说法：「之后就是想用 LeapOne 直接给学生算力赞助」「麻烦大家一个人至少转发 3 个大学生微信群」「先把校园大使推广跑通，后续视规模再评估」
  • 判断问题：这次是否涉及钱或算力额度的发放？对象怎么选、标准是否公开？对外承诺的内容我们能否按时兑现？
  • 不归本流程管：在校园做讲座、课程 → 请走 ECO-13；实习生校园招聘 → 请走 X-RCT-20；营销裂变玩法本身的合规审批 → 请走 MKT-14；分润打款与开票 → 请走 FIN-23；大使提成的劳务个税 → 请走 FIN-14；年度生态活动规划 → 请走 ECO-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
校园生态运营 立项方案、规则、素材包、发放与复盘 R 校园生态运营（当前：陈梦琪·推断待确认）
方向拍板 审批立项与预算，协调缺位高校与政府 A CEO（当前：邴龙志·推断待确认）
算力赞助方案 赞助方案、额度规则、产品发布安排 R 算力赞助方案（当前：李凯·推断待确认）
招募执行 招募方案海报、发布通知、约面试 R 行政（当前：侯明月、丁蕊·推断待确认）
邀请码需求 需求文档、验收 R 产品（当前：杨萌·推断待确认）
开发/测试 邀请码与后台开发、功能与压测 R 开发（当前：张康·推断待确认）；测试（当前：张东郅·推断待确认）
技术方案 邀请码与地推分润机制方案 C 创始人兼 CTO（当前：丁震宇·推断待确认）
财务 补贴与提成核对、打款、对账 C 财务负责人（当前：黄梦婷·推断待确认）
全体员工 按素材包转发并登记 I 全体员工

3. 办之前请准备

  • 立项方案：目标（注册数、券领取数、大使人数）、目标高校清单、预算与算力额度、周期、对外承诺范围
  • 规则：补贴/赞助申请条件与额度、大使职责与提成规则、提现周期、异常处理
  • 素材包：海报、推文、统一文案、二维码、入群方式、外地员工的参与方式
  • 系统：邀请码功能已在测试服通过功能测试与压测

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交校园合作立项方案（目标、高校、预算、KPI、对外承诺） 校园生态运营 启动前 10 个工作日 飞书文档 立项方案 👤人工判断
2 审批立项与预算 CEO 提交后 3 个工作日内 飞书审批 审批结论 🔧飞书固化
3 发布赞助/补贴/提成规则，财务确认发放与对账方式 校园生态运营、财务 对外发布前 3 个工作日 飞书文档 规则文档 👤人工判断
4 校园大使招募：方案海报 → 招募通知 → 报名表单 → 面试 → 录用名单 招募执行 招募期 2 周 飞书表单、多维表格 大使名单、高校覆盖看板 🔧飞书固化
5 每周更新高校覆盖情况，缺位高校报 CEO 协调 校园生态运营 每周一 多维表格 缺位高校清单 🔧+👤
6 邀请码与分润功能：需求 → 开发 → 功能测试与压测 → 上线；后台给大使分配角色 产品、开发、测试 推广开始前完成，压测不通过不上线 测试环境、管理员后台 上线功能 🔧+👤
7 发起全员转发：统一素材包 + 转发登记表 + 推介码追踪 校园生态运营 发起前 1 个工作日备齐素材 全员群、多维表格 转发登记、推介数据 🔧+🤖
8 补贴/算力发放：按表单审核，记录额度与结果，机器人通知申请人 校园生态运营 申请后 2 个工作日内 飞书表单、多维表格、机器人 发放记录 🔧+🤖
9 月度提成结算：导出下线/首充/提成 → 大使提现走飞书审批 → 财务核对打款 → 后台确认记录 校园生态运营、财务 每月 10 日前 管理员后台、飞书审批（FIN-23） 提成发放与对账记录 🔧+🤖+👤
10 月度复盘：注册、券领取、大使产出、成本与 ROI 校园生态运营 每月 5 日前 多维表格看板 月度复盘 🤖自动化

5. 交付物与模板

  • 交付物：校园合作立项方案、规则文档、校园大使名单与高校覆盖看板、统一素材包、转发登记表、补贴/算力发放记录、提成结算与对账记录、月度复盘
  • 建议模板/表单：
    • 校园大使报名表：姓名、学校、年级、专业、社群资源、可投入时间、推荐人
    • 补贴/算力申请表：申请人、学校、用途、申请额度、审核结论、发放日期、发放额度
    • 提成结算表：大使、邀请码、下线数、首充数、应发提成、提现申请日、财务核对、打款日期、后台确认

6. 异常与升级

  • 压测不通过 → 不上线，推广延后 → 开发 3 个工作日内修复，再测仍不通过升级创始人兼 CTO
  • 提现数据与财务核对不一致 → 暂停该批次打款 → 校园生态运营 2 个工作日内与开发、财务核清
  • 有人投诉补贴发放“看人下菜” → 按规则复核并公开标准 → 3 个工作日内回复
  • 对外承诺内容无法按时兑现 → 立即停止相关宣传口径 → 当日报 CEO
  • 推广话术或分润玩法涉及合规疑问 → 暂停发布 → 转 MKT-14 审核
  • 缺位高校连续两周无人覆盖 → 升级 CEO 协调

7. 衡量指标

  • 校园大使高校覆盖率 = 有大使的目标高校数 / 目标高校数，目标 ≥ 80%
  • 补贴发放时效 = 申请到发放的工作日，目标 ≤ 2 个工作日
  • 提成结算准确率 = 无差异批次 / 结算批次，目标 100%
  • 推广转化 = 邀请码注册数、首充数、补贴券领取数（按月对比目标）
  • 单个注册获客成本 = 当月补贴 + 提成 + 物料成本 / 当月新增注册数

8. 低效诊断

  • 现象：高校、OPC、政府合作停在战略讨论，活动落地与内容更新无排期、无负责人｜依据：「模态AI探索小分队」2026-03
  • 现象：算力赞助与大会发布安排靠群内@，缺立项、预算、对象清单｜依据：「模态AI探索小分队」2026-04
  • 现象：补贴申领到账快慢不一，发放标准不透明｜依据：「模态AI探索小分队」2026-04
  • 现象：校园大使招募由行政承担，市场类任务归属不清｜依据：「内务大总管（2026版）」2026-04
  • 现象：全员转发缺统一海报、话术和入群方式，外地员工不知如何参与｜依据：「模态集团（全员群）」2026-03、「模态集团（全员群）」2026-04
  • 现象：提现靠线下转账后台手工确认，缺财务环节；压测并发崩溃导致返工｜依据：「LeapAll」2026-04

9. 分支变体

  • 学生个人算力补贴：表单申请 + 统一额度规则
  • 高校合作赞助：需立项、与学校签约（走 LEG-04），可兼顾高潜实习生筛选（转 X-RCT-20）
  • 政府补贴券推广：有政府任务指标，需每周向 CEO 报领取进度
  • 校园大使：注册邀请码或 OPC 券码核销时填写邀请码；提成按月结算
  • OPC 社区发放：按社区规则发放，记录同一发放台账

10. 待确认问题

  • 校园合作主责是否确定为研究院生态？行政是否继续承担大使招募执行？
  • 补贴与算力赞助的额度标准由谁定、谁审批？是否需要预算上限？
  • 校园大使提成是否按劳务报酬代扣个税？提现周期定为每月一次是否可行？
  • 邀请码分润是否需要法务审核（避免多级分销合规风险）？
  • 全员转发是否计入积分或激励？转发效果如何统计？
ECO-15黑客松与开发者/内部 AI 赛事筹办待新建96

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨4 × 险3

  • 适用场景：计划举办对外黑客松（开发者用 LeapAll 做 Skill/Agent）或内部 AI 赛事（LeapAgent 赛马等），需要确定赛制、评分权重、参赛环境、赛事群运营和奖励发放时启动。
  • 负责人：主责——赛事组织负责人（当前：杨萌·推断待确认）；协同——方案把关与技术资源/创始人兼 CTO（当前：丁震宇·推断待确认）、积分总额与奖项拍板/CEO（当前：邴龙志·推断待确认）、评测（当前：张东郅·推断待确认）、研发驻场（当前：岳阳、王皓南·推断待确认）、评委（当前：李铭熙·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① 赛事立项（目标、对象、规模、预算/积分总额）→ ② 赛制与评分规则发布 → ③ 参赛环境与教程 → ④ 评测机与评测集 → ⑤ 报名与赛事群运营 → ⑥ 比赛执行与驻场 → ⑦ 评审打分 → ⑧ 公示与申诉 → ⑨ 奖励发放 → ⑩ 复盘
  • 交付结果：完成的赛事、公示的评审结果、发放完毕并入账的积分或奖金、赛事复盘（含可复用的赛制与评分模板）。
  • 状态依据：2026-04 积分总量、奖项规则在群内商议，评分权重临时 @所有人 确认、关键人未回复；2026-05 对外黑客松临近时才讨论评测集由谁出、是否给示例代码；外部赛事群 2026-07～09 邀请码过期反复申请；每次赛事都临时商议，无立项模板。

1. 场景判定

  • 触发条件：管理层或生态团队提出办黑客松、开发者大赛、内部赛马、小龙虾赛等竞赛类活动。
  • 典型说法：「这个是对外活动」「需要给他们开发文档和示例代码吗」「定个总积分额度，然后办呗」「要不产品、技术、用户 4:3:3」
  • 判断问题：参赛者是外部开发者还是内部员工？是否需要我们提供环境、算力或 API？奖励是积分还是现金？
  • 不归本流程管：生态大会整体筹备 → 请走 ECO-16；全员 AI 案例征集 → 请走 CEO-21；积分制度本身与积分兑换 → 请走 HR-18；参加外部单位主办的比赛 → 请走 ECO-12；年度活动规划 → 请走 ECO-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
赛事组织 立项方案、赛制、评委、赛事群、公示、复盘 R 赛事组织负责人（当前：杨萌·推断待确认）
立项与奖励拍板 审批立项、预算与积分总额、奖项设置 A CEO（当前：邴龙志·推断待确认）
方案把关 确定教程与验收规范、协调研发资源 C 创始人兼 CTO（当前：丁震宇·推断待确认）
评测 评测机、评测集、AI 评测脚本、承载评估 R 评测（当前：张东郅·推断待确认）
研发驻场 赛中技术支持、环境故障处理 R 研发驻场（当前：岳阳、王皓南·推断待确认）
评委 按评分表打分、确认权重 C 评委（当前：李铭熙·推断待确认）
财务 现金奖发放与个税 C 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 立项信息：赛事名称、目标（拉新/产品验证/人才发现/内部创新）、参赛对象、预计队伍数与并发人数、时间、预算或积分总额
  • 赛制：命题还是自由、提交材料包要求、截止时间、弃赛规则
  • 评审：评审维度与权重、评委名单、轮次、申诉窗口
  • 环境：参赛账号或邀请码、教程/开发文档、是否给示例代码、API 并发承载评估

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板写赛事立项方案并提交审批 赛事组织 赛前 30 天 飞书文档、飞书审批 立项方案 🔧飞书固化
2 审批立项、预算/积分总额与奖项设置 CEO 提交后 3 个工作日内 飞书审批 审批结论 👤人工判断
3 定赛制与评分规则；权重用飞书投票确认，2 个工作日无异议即发布 赛事组织 赛前 21 天发布 飞书文档、飞书投票 赛事规则 🔧飞书固化
4 准备教程/开发文档、参赛账号或邀请码；评估并发与 API 承载 研发驻场、创始人兼 CTO 赛前 7 天 文档站、管理后台 参赛环境 🔧+👤
5 准备评测机、评测集与 AI 评测脚本，试跑一轮 评测 赛前 5 天 评测机、脚本 评测环境 🤖自动化
6 开报名；赛事群用公告模板与 FAQ，邀请码按有效期自动发放 赛事组织 赛前 14 天开报名至赛后 飞书表单、群机器人 报名名单、群公告 🔧+🤖
7 确定评委，发评审日程 赛事组织 赛前 7 天 飞书日历 评审日程 🔧飞书固化
8 比赛执行：研发驻场，评测实时跑分 研发驻场、评测 赛中 评测机 运行记录 👤人工判断
9 收材料包（逾期视为弃赛），评委表单打分，系统按权重归一化汇总 评委、赛事组织 评审当日 飞书表单、多维表格 评审结果 🔧+🤖
10 公示结果，开 2 个工作日申诉窗口 赛事组织 评审后 1 个工作日内 群公告 公示结果 🔧飞书固化
11 发放奖励：积分入台账（HR-18），现金奖走财务审批（FIN-14） 赛事组织、财务 公示期满后 10 个工作日内 积分台账、飞书审批 发放记录 🔧飞书固化
12 赛后复盘，更新赛制与评分模板 赛事组织 赛后 5 个工作日内 飞书文档（CEO-16） 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：赛事立项方案、赛事规则（赛制、评分权重、申诉）、教程与参赛环境、评测集与脚本、报名名单、评审结果、奖励发放记录、复盘报告
  • 建议模板/表单：
    • 赛事立项模板：名称、目标、对象、规模、时间线、预算/积分总额、奖项（一二三等奖、参与奖、评委分）、分工、风险
    • 评分表：参赛队、评委、维度（产品/技术/用户体验）、权重、得分、备注
    • 参赛材料包清单：部署入口与测试账号、API 接入说明、技术方案、加分项说明

6. 异常与升级

  • 评分权重有异议 → 赛事组织 1 个工作日内组织投票 → 仍有分歧由 CEO 拍板
  • 关键评委在确认期内未回复 → 默认按发布版本执行，并通知其本人
  • 并发或 API 承载不足 → 赛前 3 天内确定限流或扩容方案 → 升级创始人兼 CTO
  • 邀请码过期或发放失败 → 机器人重发；同一问题 24 小时内重复出现，赛事组织检查发放逻辑
  • 参赛者申诉 → 赛事组织会同评委 2 个工作日内答复，结果不变更时说明理由

7. 衡量指标

  • 筹备准时率 = 按时完成立项、规则、环境三个节点的赛事数 / 赛事总数，目标 100%
  • 规则变更次数 = 规则发布后修改评分或奖项的次数，目标 0
  • 参赛完成率 = 按时提交材料包的队伍数 / 报名队伍数
  • 奖励发放时效 = 公示期满到发放完成的工作日，目标 ≤ 10 个工作日
  • 赛事产出 = 入选作品转为产品功能、Skill 上架或招聘线索的数量

8. 低效诊断

  • 现象：评测集谁出、是否给示例代码等关键事项临近才讨论，驻场与评测人员临时安排｜依据：「Leap产研测」2026-05
  • 现象：积分总量、奖项规则在群聊中商议，赛事牵头人不明，反复催填表格｜依据：「【跃迁】高管群」2026-04
  • 现象：评分权重临时 @所有人 确认，关键人开会未回复，确认环节等待｜依据：「随时会被解散的群」2026-04
  • 现象：外部赛事群邀请码过期后反复申请，志愿者通知走私下渠道｜依据：「开源聚变黑客松交流群」2026-07、「开源聚变黑客松交流群」2026-09

9. 分支变体

  • 对外黑客松：参赛者用 LeapAll 做 Skill/Agent，需教程、账号、承载评估与研发驻场；命题赛需额外提供验收规范
  • 内部赛马（LeapAgent 赛等）：两轮评审（专业评审取前几名 + 现场演示用户评审），奖励以积分为主
  • 外部主办方赛事群（公司协办或参与）：本公司只负责自己承担的环节，群运营归属需先确认
  • 与生态大会合办：赛事结果在大会上公布时，节点倒排对齐 ECO-16

10. 待确认问题

  • 赛事组织主责是否固定由产品侧负责？对外黑客松是否应归研究院生态？
  • 积分 1 分折算的价值与奖金上限是否成文？现金奖是否一律走劳务报酬代扣个税？
  • 赛前 30 天立项是否可行？小型内部赛是否可简化为赛前 14 天？
  • 外部主办方的黑客松交流群是否属于本公司负责范围？
  • 评测集与评测机是否作为评测团队的常设资产维护？
ECO-16生态大会立项与总体筹备待新建200

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗5 × 跨5 × 险4

  • 适用场景：CEO 决定举办生态大会、理事会、股东会或专场大会，需要立项、定总体方案与议程、组建筹备组、邀请人清单、报名网站、全员动员与调休安排时启动。
  • 负责人：主责——大会项目经理/总协调（当前：赵雪冰·推断待确认）；协同——CEO（定目标与方向，当前：邴龙志·推断待确认）、联合创始人（大会主方向与上台，当前：常元和·推断待确认）、创始人兼 CTO（研发资源与全员通知，当前：丁震宇·推断待确认）、方案与嘉宾邀请（当前：李鹏为·推断待确认）、展区统筹（当前：杨萌·推断待确认）、发布会内容（当前：王皓南·推断待确认）、演示环境（当前：宋祺睿·推断待确认）、物料与接待（当前：侯明月·推断待确认）、资料记录（当前：董蓝汐·推断待确认）、报名网站（当前：葛家和·推断待确认）、外部活动对接（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·部门报送）
  • 核心流程：① CEO 立项（目标、定位、日期、预算）→ ② 指定唯一项目经理与模块负责人 → ③ 总体方案与议程 → ④ 邀请人清单 → ⑤ 报名网站与入场 → ⑥ T-3 内容冻结 → ⑦ 全员动员与调休通知 → ⑧ 彩排 → ⑨ 现场执行 → ⑩ 会后考勤、费用与复盘
  • 交付结果：按里程碑完成的大会（立项单、总体方案、议程、邀请清单、报名名单、全员通知、彩排记录），以及会后费用归集与复盘报告。
  • 状态依据：2026-04 股东会/理事会与生态大会筹备从零开始，邀请清单文档不便填写改表格，联系方式列有争议；2026-05 大会前一天方向由“展示”改为“发布会”，全员通宵改稿、彩排不足，“搞大会不应该是运营部的工作吗”；2026-09 大会筹备分散在群聊，无统一负责人与进度表。

1. 场景判定

  • 触发条件：CEO 宣布在某月举办生态大会、理事会、股东会、周年庆或专场大会。
  • 典型说法：「我计划 5 月中筹办一个生态大会」「你拉个 Excel 表，让大家都填一下邀请人清单」「生态大会所有相关筹办人员本周末调休，正常来公司上班」「一个十五分钟的发布，理论上彩排时间应该预留十个小时」
  • 判断问题：大会定位是展示、产品发布还是理事会/股东会？是否有政府领导或媒体到场？距离大会还有多少天，能否满足 T-30 立项？
  • 不归本流程管：大会任务拆分与日会跟踪 → 请走 ECO-17；嘉宾邀约与资料收集 → 请走 ECO-18；演示场景与 Demo → 请走 ECO-19；物料评审与采购 → 请走 ECO-20；展区搭建、彩排与现场执行 → 请走 ECO-21；股东会决议本身 → 请走 CEO-22；大会费用预算与归集 → 请走 FIN-09；参加外部单位大会 → 请走 MKT-01 / ECO-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
大会项目经理 立项单、总体方案、里程碑、筹备群与任务表、全程协调 R 大会项目经理（当前：赵雪冰·推断待确认）
决策人 定目标、定位、日期、预算，批准方向变更 A CEO（当前：邴龙志·推断待确认）
大会主方向 发布内容定调、上台 C 联合创始人（当前：常元和·推断待确认）
研发资源协调 调配研发人员、发全员通知 R 创始人兼 CTO（当前：丁震宇·推断待确认）
方案与邀请 议程文档、邀请人清单、保密提醒 R 方案与嘉宾邀请（当前：李鹏为·推断待确认）
展区与发布 展区统筹、发布会 PPT/视频、演示环境 R 展区统筹（当前：杨萌·推断待确认）；发布会内容（当前：王皓南·推断待确认）；演示环境（当前：宋祺睿·推断待确认）
后勤与记录 物料、接待、签到、资料记录 R 物料与接待（当前：侯明月·推断待确认）；资料记录（当前：董蓝汐·推断待确认）
报名与外联 报名网站、外部活动对接 R 报名网站（当前：葛家和·推断待确认）；外部活动对接（当前：鲁周毅·推断待确认）
人事 加班调休与会后考勤口径 C 人事负责人（当前：黄莹·推断待确认）
全体员工 按通知参会、承担现场分工 I 全体员工

3. 办之前请准备

  • 立项信息：大会名称、定位（展示/发布会/理事会/股东会）、目标、日期与场地、规模、预算、主办/支持/指导单位
  • 参会人分类：政策、高校园区、产业、学术、投资、媒体六类，各类负责邀请的人
  • 历史资料：上一次大会的方案、议程、邀请清单模板、复盘报告
  • 人力：可投入的筹办人员名单，是否需要周末加班与调休

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 CEO 立项：目标、定位、日期、规模、预算 CEO、大会项目经理 T-30 天（最迟 T-21 天） 飞书审批 立项单 👤人工判断
2 指定唯一大会项目经理与模块负责人（议程、嘉宾、展区/Demo、物料、现场、宣发、报名、后勤），建筹备群与任务表 大会项目经理 立项后 2 个工作日内 多维表格任务表（ECO-17） 分工表 🔧飞书固化
3 出总体方案与议程（参会人分类、议程时间表、发言安排） 方案与邀请 T-21 天 飞书文档 总体方案、议程 🤖+👤
4 发起邀请人清单，各负责人限期填写；联系方式列只对授权人可见，清单不得外传 方案与邀请 T-21 发起，T-14 截止 多维表格（字段权限，ECO-18） 邀请人清单 🔧飞书固化
5 上线报名网站/表单与入场方式，征集展示素材 报名网站负责人 T-14 天 报名网站、飞书表单 报名入口 🔧+🤖
6 内容冻结：定位、发布内容、PPT 主线冻结，之后改方向需 CEO 书面确认并评估可行性 大会项目经理、CEO T-3 天 飞书文档 冻结版本 👤人工判断
7 发全员动员通知：时间地点、现场分工（接待、展区互动、补座、合影）、员工是否需报名、考勤口径、筹办人员加班与调休 创始人兼 CTO、人事 T-5 天 通知群、飞书考勤（HR-12） 全员通知 🔧飞书固化
8 彩排：发布环节按足量预留彩排，T-1 在现场走通全流程 发布会内容、演示环境 T-2 至 T-1 现场（ECO-21） 彩排记录 👤人工判断
9 现场执行 各模块负责人 大会当天 ECO-21 完成的大会 👤人工判断
10 会后：统一处理考勤补卡、费用归集、资料归档、复盘 大会项目经理 T+5 个工作日内 飞书考勤、FIN-09、CEO-16 考勤处理、费用表、复盘报告 🔧飞书固化

5. 交付物与模板

  • 交付物：立项单、分工表、总体方案与议程、邀请人清单、报名名单、全员通知、彩排记录、费用归集表、复盘报告、资料归档
  • 建议模板/表单：
    • 大会立项单：名称、定位、目标、日期、场地、规模、预算、主办/支持/指导单位、项目经理、里程碑（T-30/T-21/T-14/T-5/T-3/T-1）
    • 邀请人清单：单位名、姓名、职务、类别、邀请人、是否发言、空闲时间、确认状态、联系方式（字段权限）
    • 全员通知模板：时间、地点、到场时间、分工与负责人、是否需报名、着装、考勤口径、调休规则、联系人

6. 异常与升级

  • 立项时距离大会不足 21 天 → 项目经理当日报 CEO，明确缩减范围（如取消展区或发布会）后再启动
  • T-3 后出现方向变更 → CEO 书面确认，项目经理评估人力与时间；无法完成的部分当场砍掉，不靠通宵
  • 模块负责人缺位或冲突 → 项目经理 1 个工作日内报 CEO 调人（必要时走 CEO-08 借调）
  • 邀请清单疑似外传 → 立即收回权限 → 当日报 CEO
  • 关键嘉宾变动 → 转 ECO-18 处理，议程 1 个工作日内更新
  • 会后考勤异常集中出现 → 按全员通知中的考勤口径统一处理，不逐个申请

7. 衡量指标

  • 里程碑按时率 = 按时完成的里程碑数 / 里程碑总数，目标 ≥ 90%
  • T-3 后方向变更次数，目标 0
  • 彩排完成度 = 大会前完成全流程彩排的环节数 / 上台环节数，目标 100%
  • 邀请到场率 = 实到嘉宾数 / 确认嘉宾数
  • 会后复盘按时率 = T+5 个工作日内完成复盘的大会数 / 大会数，目标 100%

8. 低效诊断

  • 现象：大会定位在前一天由“展示”改为“发布会”，全员通宵改 PPT 与视频｜依据：「鼎慧产研决策部」2026-05
  • 现象：展位方案、分工、话术在群里口述，无统一任务表与里程碑｜依据：「鼎慧产研决策部」2026-05
  • 现象：彩排时间不足，现场被场控提醒未彩排｜依据：「鼎慧产研决策部」2026-05
  • 现象：大会归属不清，研发团队承担大量筹办工作｜依据：「鼎慧产研决策部」2026-05
  • 现象：邀请人清单先用文档后改表格，联系方式列是否必要有争议，保密靠口头提醒｜依据：「【模态】总经办」2026-04
  • 现象：员工是否需要报名口径不一，合影时间临时调整，会后缺卡逐个询问｜依据：「模态跃迁通知群」2026-05、「模态跃迁通知群」2026-06
  • 现象：9 月大会报名网站、测试机预约、外部对接分散在群聊，无统一负责人与进度表｜依据：「跃迁AI总动员」2026-09

9. 分支变体

  • 股东会 + 理事会：总经办统筹资料、记录、接待与股东签字，决议走 CEO-22 / LEG-06
  • 自办生态大会（展区 + 发布会）：展区、Demo、发布会 PPT/视频按 ECO-19、ECO-21 执行，发布环节必须彩排
  • 技术专场大会：需预约远程测试机或演示设备，报名网站与素材征集提前到 T-14
  • 参与外部峰会或合办活动：公司只负责自有环节，走 MKT-01 / ECO-12，现场分工仍按本流程通知模板

10. 待确认问题

  • 大会项目经理主责是否固定由综合部/总经办承担？与生态市场条线、运营的分工如何划分？
  • T-30 立项、T-3 内容冻结两条规则能否作为硬性要求？
  • 员工参会是否强制？大会当天考勤与筹办人员加班调休是否按统一规则处理？
  • 邀请人清单的查看权限给哪些人？联系方式是否只由邀请人本人保管？
  • 大会预算由谁审批？是否需要与 ECO-01 年度活动规划对齐后才能立项？
ECO-17大会任务分工与进度跟踪待优化250

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：公司确定举办生态大会、研究院大会等大型对外活动并进入倒计时（约活动前 30 天）后，需要把议程拆成任务清单、落实到人，并按天跟踪进度与风险。
  • 负责人：主责——大会总统筹（总经办）（当前：赵雪冰·推断待确认）；协同——产品展区模块负责人（当前：杨萌·推断待确认）、生态活动与物料模块负责人（当前：陈梦琪·推断待确认）、邀约与运营模块负责人（当前：李凯·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 立项并书面指定拍板人 → ② 按议程拆任务清单 → ③ 指定模块第一负责人与 DDL → ④ 启动会 → ⑤ 每日更新进度 → ⑥ 日会只过红黄项 → ⑦ 阻塞与拍板升级 → ⑧ 活动前 2 天查漏补缺 → ⑨ 会后关闭任务并移交复盘
  • 交付结果：一张覆盖所有模块的大会任务看板（任务-负责人-截止日-状态-风险-链接）、日会纪要与决策记录、会后任务关闭清单与费用汇总。
  • 状态依据：倒计时阶段已有飞书 wiki 任务清单 + 日会机制且运行稳定；但筹备前期靠临时会议召集、会上未落实到人，拍板人不唯一，填表需群内反复提醒约 6 次，已完成事项事后找不到经办人，活动后才发现遗留问题。

1. 场景判定

  • 触发条件：已定日期的大会/发布会/大型沙龙，涉及 3 个及以上模块（展区、Demo、邀约、物料、会务、大赛、宣传）；或距活动 ≤ 30 天仍无统一任务表。
  • 典型说法：「生态大会任务排期、人员分配已更新在此表」「请各位务必认真浏览每项任务，对齐需求、ddl」「这个会定的，没说清楚谁负责什么」「距离大会还剩 2 天，请查看本表查漏补缺」
  • 判断问题：这件事是否有硬性日期、多个部门交付、需要一个人看全局？如果只是某一模块内部的执行，走对应子流程。
  • 不归本流程管：嘉宾邀约与资料收集 → 请走 ECO-18；演示场景与 Demo → 请走 ECO-19；物料评审定稿与采购 → 请走 ECO-20；展区硬件、搭建彩排与现场执行 → 请走 ECO-21；嘉宾接待安排 → 请走 ECO-16。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
大会总统筹 拆任务、维护看板、组织日会、催办、汇总风险与费用 R 总经办（当前：赵雪冰·推断待确认）
最终决策人 定目标、议程与预算；争议事项唯一拍板；授权额度 A CEO（当前：邴龙志·推断待确认）
产品展区模块负责人 产品演示、展区、开发大赛等产品侧任务 R（模块内） 产品总监（当前：杨萌·推断待确认）
生态活动模块负责人 活动方案、互动 Demo、物料排期与费用统计 R（模块内） 生态组负责人（当前：陈梦琪·推断待确认）
邀约与运营模块负责人 邀约进度、宣发 R（模块内） 运营负责人（当前：李凯·推断待确认）
研发资源把关 研发人力与产品交付冲突裁决 C 创始人兼 CTO（当前：丁震宇·推断待确认）
技术支援 领取看板上的技术任务 I Leap 研发负责人（当前：王皓南·推断待确认）、客户端研发（当前：葛家和·推断待确认）
产品/小程序 身份卡、互动区等子任务拆分 I 产品经理（当前：陈震·推断待确认）

3. 办之前请准备

  • 已确定的活动日期、地点、议程初稿、预算总额及审批人
  • 书面指定的最终拍板人，以及各模块负责人可自决的范围（事项类型、金额上限）
  • 模块清单：产品展区、活动 Demo、邀约、物料、会务、大赛、宣传、现场执行
  • 每个模块的第一负责人（一人一模块；表中第一个名字即负责人）
  • 「大会任务看板」多维表格模板，上届大会任务清单作参考
  • 日会固定时段与会议室（或线上会议链接）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：确认日期、目标、议程、预算，书面指定拍板人与总统筹 最终决策人 活动前 30 天 飞书文档 大会立项说明 👤人工判断
2 按议程拆任务清单，每项写清交付物、DDL、依赖关系 大会总统筹 立项后 2 个工作日内 飞书多维表格 任务看板初版 🔧+🤖
3 指定模块第一负责人，模块内拆子任务并认领 总统筹 + 模块负责人 看板发布后 1 个工作日内 多维表格人员字段 每项任务有唯一负责人 👤人工判断
4 启动会：过任务表、拍板规则、授权额度、日会机制 大会总统筹 看板发布后 2 个工作日内 飞书日程/会议 启动会纪要 🔧飞书固化
5 各负责人更新进度、成果链接、风险 模块负责人 每日日会前 1 小时 多维表格 当日进度 🔧飞书固化
6 日会：只过红/黄项与待拍板项（活动前 7 天起每日，之前每周 2 次） 大会总统筹 每次 ≤ 30 分钟 飞书会议 + 妙记 日会纪要、新增待办 🔧+🤖
7 逾期/阻塞自动提醒；需拍板事项按“选项-优缺点-成本”提交拍板人 大会总统筹 发现当日 机器人提醒 决策记录 🔧+👤
8 全表查漏补缺：每项已完成或有兜底方案 大会总统筹 活动前 2 天 多维表格 风险清单清零 👤人工判断
9 关闭任务、汇总费用、移交复盘任务给各模块 大会总统筹 活动后 3 个工作日内 多维表格 关闭清单、费用汇总 🔧飞书固化

5. 交付物与模板

  • 交付物：大会立项说明；大会任务看板；日会纪要；决策记录；会后关闭清单与费用汇总。
  • 建议模板/表单：「大会任务看板」字段——任务ID、模块、任务名、交付物、第一负责人、协作人、开始日、DDL、状态（未开始/进行中/待审核/已完成/阻塞）、风险等级（红/黄/绿）、风险说明、待拍板事项、成果链接、费用、最后更新时间；视图：按模块、逾期、待拍板、我的任务。

6. 异常与升级

  • 任务无人认领 → 总统筹当日指定临时负责人 → 升级最终决策人（24 小时内）
  • 模块负责人临时无法到场（答辩、出差）→ 本人书面指定代理人并更新看板 → 总统筹确认（当日）
  • 拍板事项超过 1 个工作日无结论 → 总统筹整理决策单直接找拍板人 → 当日闭环
  • 研发人力与产品交付冲突 → 研发资源把关人裁决（1 个工作日内）
  • 已拍板事项变更（议程、名称、日期）→ 总统筹在看板记录变更并通知受影响模块（2 小时内）

7. 衡量指标

  • 任务按期完成率 = DDL 前完成任务数 / 总任务数，目标 ≥ 90%
  • 看板更新率 = 日会前已更新的进行中任务 / 进行中任务总数，目标 100%
  • 拍板时长 = 决策请求提交到结论的小时数，目标 ≤ 24 小时
  • 无主任务数 = 负责人为空或无人认领的任务数，目标活动前 7 天起为 0
  • 会后遗留问题数 = 活动结束后新发现且无负责人的问题数，目标 ≤ 3

8. 低效诊断

  • 现象：筹备前期靠临时“会议通知@所有人”召集，会上未明确分工，邀约等任务长期无人推进｜依据：「鼎慧产研决策部」2026-05
  • 现象：拍板权不清，“人人都能拍板”与“几天没人拍板”并存，意见反复导致返工｜依据：「鼎慧产研决策部」2026-05
  • 现象：任务表进度靠群内多次提醒才填写，硬件需求多轮变更｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：已办事项无经办人记录，事后需在群里追问是谁做的｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：活动结束后才暴露遗留问题（未领卡人员如何补、参会需求未登记），费用事后统计｜依据：「平台部」2026-05、「平台部」2026-06

9. 分支变体

  • 大型对外大会：完整执行 9 步，活动前 7 天起每日日会。
  • 中小型活动（渠道沙龙、外部展会参展）：步骤 3、4 可合并，日会改每周 2 次。
  • 子模块（展区、大赛、会务、宣传）可建子视图，但只维护一张总看板。

10. 待确认问题

  • 大会总统筹是否固定由总经办承担，还是每次由 CEO 指定？
  • 拍板人是否只限 CEO 一人？COO、CTO 的拍板范围如何划分？
  • 模块负责人可自决的金额上限是多少？
  • 任务看板是否统一迁到飞书多维表格/飞书项目，不再用 wiki 表格？
  • 会后复盘由谁收口、是否需要单独的复盘模板？
ECO-18大会嘉宾邀约与嘉宾资料收集待优化160

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨5 × 险4

  • 适用场景：大会立项后，需要确定并邀请政府、高校、企业嘉宾，收集嘉宾名单、职务、照片、演讲材料、圆桌问题，并产出座次图与席卡。
  • 负责人：主责——嘉宾邀约与资料总口（生态市场总监）（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、各条线邀请人（当前：闫登辉、杨朋伟、刘昱潇、吴琪、陈梦琪·推断待确认）、行政（当前：侯明月·推断待确认）、产品经理（当前：陈震·推断待确认）、商务（当前：杨朋伟、裴建武·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发嘉宾名单表按条线分派 → ② 各条线填报 → ③ 拍板邀请名单 → ④ 统一邀约口径与节奏 → ⑤ 发出邀请并登记状态 → ⑥ 表单收集嘉宾资料 → ⑦ 圆桌问题提前发嘉宾 → ⑧ 座次图/席卡定稿 → ⑨ 活动前 1 天终核
  • 交付结果：已确认的嘉宾名单（含邀请人、状态）、完整嘉宾资料库（职务/照片/演讲材料/圆桌问题）、唯一版本的座次图与席卡。
  • 状态依据：有嘉宾名单表格、嘉宾信息 wiki 表与圆桌话题文档，但名单填报需催 3 次，邀约时间口径不一，资料要求私信发送，座次图多版本并存，现场被质疑座位规则。

1. 场景判定

  • 触发条件：大会立项后需要邀请外部嘉宾；或嘉宾已确认但资料（职务、照片、演讲材料、圆桌问题）未齐。
  • 典型说法：「今明两天大会创意和嘉宾名单必须填好」「各位嘉宾邀请人确定嘉宾信息后一同汇总给我」「把每个嘉宾会被问到的三个问题发一下」「这个座次图是最终可用的吗」
  • 判断问题：对方是否以“嘉宾/演讲人/圆桌成员/席位”身份出席？只是普通报名观众则不走本流程。
  • 不归本流程管：嘉宾到场接待、引导、餐饮 → 请走 ECO-16；大会整体任务跟踪 → 请走 ECO-17；现场签到与座次指引执行 → 请走 ECO-21；比赛选手报名 → 请走 ECO-15（黑客松与开发者/内部 AI 赛事筹办）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
嘉宾邀约与资料总口 维护名单与资料清单、定截止时间、汇总资料 R 生态市场条线负责人（当前：许君·推断待确认）
邀请名单拍板 确定邀请名单与优先级、政府嘉宾邀请时机 A CEO（当前：邴龙志·推断待确认）
条线分派 按条线分派填报人、统一邀约话术 R（名单阶段） 市场销售负责人（当前：李鹏为·推断待确认）
邀请人 邀约、跟进确认、填写嘉宾资料 R（各自嘉宾） 各条线邀请人（当前：闫登辉、杨朋伟、刘昱潇、吴琪、陈梦琪·推断待确认）
嘉宾信息表维护 建表、核对完整性 C 行政（当前：侯明月·推断待确认）
圆桌话题 整理圆桌问题与建议答题时长 C 产品经理（当前：陈震·推断待确认）
座次与席卡 制作座次图、标记缺席卡 R（座次） 商务（当前：杨朋伟、裴建武·推断待确认）
嘉宾问题审核 审核圆桌问题、提醒提前发送 C COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 大会日期（至少确定到“周”）、议程框架、圆桌/演讲环节数量
  • 嘉宾分类：本地政府、高校/OPC、合作伙伴、投融资、重要客户、赞助商
  • 「嘉宾邀约」多维表格（含资料收集表单）
  • 统一邀约话术与邀请函（日期未定时的说法、正式邀请的说法）
  • 嘉宾资料清单：姓名、单位、职务、照片、简介、演讲题目/PPT、圆桌问题确认、是否需席卡、随行人数、对接人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建嘉宾名单表，按分类分派填报人 条线分派 活动前 35 天 飞书多维表格 嘉宾候选表 🔧飞书固化
2 各条线填报候选嘉宾（单位、职务、关系熟度、邀请人） 邀请人 分派后 2 个工作日内 多维表格 候选名单 🔧飞书固化
3 拍板邀请名单与优先级，明确政府嘉宾邀请时机 邀请名单拍板 填报截止后 1 个工作日内 多维表格 确定邀请名单 👤人工判断
4 统一邀约口径：熟识嘉宾先口头预告；日期确定后统一发正式邀请函 嘉宾邀约总口 日期确定后 1 个工作日内 飞书文档 邀约话术 + 邀请函 🔧+🤖
5 发出邀请，每日更新状态（待邀/已邀/确认/婉拒） 邀请人 活动前 25 天起，每日 18:00 前 多维表格 邀约进度 🔧飞书固化
6 嘉宾确认后填写资料表单，缺项自动标红并提醒 邀请人 确认后 1 个工作日内 多维表格表单 + 机器人 嘉宾资料库 🔧+🤖
7 整理圆桌问题与建议答题时长，审核后发给嘉宾 圆桌话题负责人 活动前 5 天 飞书文档 圆桌问题单 🤖+👤
8 制作座次图与席卡；按“文件名-说明-日期”命名，只保留一个最新链接 座次与席卡 活动前 2 天 飞书表格/云盘 座次图终版、席卡 🔧飞书固化
9 终核：嘉宾到场确认、资料齐全、座次规则（前排预留）通知现场 嘉宾邀约总口 活动前 1 天 18:00 前 多维表格 终版嘉宾清单 👤人工判断
10 会后致谢并归档嘉宾资料 邀请人 活动后 3 个工作日内 多维表格 嘉宾档案 🔧飞书固化

5. 交付物与模板

  • 交付物：确定邀请名单；邀约话术与邀请函；嘉宾资料库；圆桌问题单；座次图终版与席卡；嘉宾档案。
  • 建议模板/表单：「嘉宾邀约」多维表格字段——嘉宾姓名、单位、职务、分类、邀请人、优先级、邀约状态、确认日期、出席环节（开幕/演讲/圆桌/观众）、照片、简介、演讲材料、圆桌问题已发送（是/否）、席卡（是/否）、座位区、随行人数、接待需求、备注。

6. 异常与升级

  • 填报截止仍有条线未填 → 总口当日提醒 → 升级拍板人（24 小时内）
  • 活动日期未定无法正式邀请 → 只做口头预告，不承诺具体日期 → 拍板人确认日期后统一邀请
  • 嘉宾临时婉拒或换人 → 邀请人当日更新表格并通知座次负责人 → 席卡、座次 2 小时内同步
  • 嘉宾资料活动前 3 天仍缺失 → 总口直接联系邀请人补齐 → 升级拍板人决定是否保留环节
  • 座次图存在多版本 → 以多维表格/云盘唯一链接为准，旧版删除 → 总口确认

7. 衡量指标

  • 名单填报准时率 = 截止前完成填报的条线数 / 条线总数，目标 100%
  • 嘉宾资料齐全率 = 资料全部字段完成的确认嘉宾数 / 确认嘉宾总数，活动前 3 天目标 100%
  • 座次版本数 = 活动当天现场流转的座次图版本数，目标 1
  • 圆桌问题提前送达率 = 活动前 5 天收到问题的圆桌嘉宾 / 圆桌嘉宾总数，目标 100%

8. 低效诊断

  • 现象：嘉宾名单靠领导在群内连续催填，各条线新建多张表分散填写｜依据：「【模态】市场销售」2026-04
  • 现象：活动日期未定，邀约时机与话术需临时统一，政府嘉宾邀请迟迟未发｜依据：「【模态】市场销售」2026-04、「鼎慧产研决策部」2026-05
  • 现象：资料收集因群消息过多被要求改为私信发送，信息只在个人手里｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：座次图多版本并存，现场无法确认哪版可用；前排座位规则未提前说明被现场质疑｜依据：「跃迁生态大会筹备群」2026-05

9. 分支变体

  • 圆桌嘉宾：需额外提前发送问题与答题时长。
  • 开幕式/演讲嘉宾：需收集演讲材料并纳入物料评审（ECO-20）。
  • 赞助商：按赞助权益确认展位、露出与席位。
  • 渠道沙龙、外部活动参与：只用步骤 1～6，不做座次席卡。

10. 待确认问题

  • 嘉宾邀约总口是否由生态市场总监承担，名单分派阶段是否由销售负责人负责？
  • 政府嘉宾的邀请时机与审批人是否需要单独规定？
  • 前排座位规则（预留/随意落座）由谁定、何时公布？
  • 嘉宾资料收集是否统一用多维表格表单，不再私信？
  • 嘉宾资料（照片、联系方式）会后的保存期限与访问权限？
ECO-19大会演示场景与 Demo 准备待新建375

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：大会、发布会或渠道/客户演示前，需要确定演示场景与案例、编写各产品演示流程与 QA、开发活动互动 Demo，并交付产品材料与演示视频。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——场景总包（当前：王皓南·推断待确认）、各产品演示文档负责人（当前：宋祺睿、刘昱潇、李铭熙·推断待确认）、活动 Demo 第一负责人（当前：陈梦琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、视频剪辑（当前：李宣昊·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 明确受众与场景候选 → ② 拍板场景清单 → ③ 内容合规筛查 → ④ 活动 Demo 需求定稿与原型评审 → ⑤ 开发、跑通与回归 → ⑥ 演示流程与 QA 文档 → ⑦ 演示环境选择与安全确认 → ⑧ 录屏保底与素材归档 → ⑨ 搭建前最终走查
  • 交付结果：演示场景库（场景-步骤-素材-测试状态-录屏）、各产品现场演示流程与 QA 文档、可运行的活动 Demo、统一规格的演示视频与保底录屏。
  • 状态依据：LeapCore 已有现场演示流程与 QA 文档，但无案例库与演示脚本库；案例分派后长期无人跟进，演示视频大会前临时拼凑，场景、名称多次变更，演示环境（公网/内网）前一晚才讨论，属于每次临时处理。

1. 场景判定

  • 触发条件：确定了对外演示的时间与受众（大会、渠道老板、政府/央国企客户）；或活动需要非产品功能的互动 Demo（身份卡、汇聚墙、小程序、弹幕等）。
  • 典型说法：「帮我拍板一下场景」「基础演示流程是必须跑通不能出错的」「现场演示流程及 QA 今天出一版云文档」「急，演示视频」「现在就是两边都依赖对方」
  • 判断问题：是否需要在外部受众面前现场操作产品或展示录屏？如果只是给客户发产品资料，不走本流程。
  • 不归本流程管：日常售前单客户演示 → 请走 SAL-11（客户演示准备与执行）；展区硬件、网络、排班 → 请走 ECO-21；展板、手册等物料定稿 → 请走 ECO-20；积分卡兑换链接 → 请走 ECO-20 及 OPS-10/OPS-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示总负责 定受众、分派、跟踪、催交、验收 A/R 产品总监（当前：杨萌·推断待确认）
场景拍板 场景取舍、优先级与研发资源冲突时拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
场景总包 收集/生成场景清单，跑场景、修 bug R Leap 研发负责人（当前：王皓南·推断待确认）
产品演示文档 各产品演示流程与 QA、保底录屏 R LeapCore（当前：宋祺睿·推断待确认）、LeapBase（当前：刘昱潇·推断待确认）、LeapAll（当前：李铭熙·推断待确认）
活动 Demo 第一负责人 活动需求定稿、效果验收 R 生态组负责人（当前：陈梦琪·推断待确认）
活动 Demo 开发 原型与开发 R 研发（当前：葛家和、吴世豪、裴建武、陈子康·推断待确认）
评测/回归 演示前回归、现场跑分工具 C 测试负责人（当前：张东郅·推断待确认）
视频剪辑 录屏素材剪辑、配音 R（视频） 新媒体运营（当前：李宣昊·推断待确认）
对外口径 包装口径与敏感内容把关 C CEO（当前：邴龙志·推断待确认）
IT 支持 演示环境网络、访问范围与安全确认 C IT 运维/网管（当前：杨明学·推断待确认）

3. 办之前请准备

  • 演示时间、地点、受众类型（直播/政府/渠道/企业），是否联网、是否允许公网访问
  • 各产品当前可用版本与已知问题清单
  • 演示场景库（多维表格）及上次演示的脚本、录屏
  • 活动方案文档（互动 Demo 需求、名称、视觉风格）
  • 录屏规范：分辨率、全屏/窗口、隐藏 Dock、比例 16:9、命名规则
  • 演示账号与额度（账号口令存放在密码管理处，不写进文档正文）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 明确受众与目标；从场景库 + AI 整理的同类产品场景生成候选清单 场景总包 活动前 25 天 多维表格 + AI 场景候选清单 🤖自动化
2 拍板保留场景，区分“基础必跑”与“高级可选”，确定“预制+现场执行”方案 场景拍板 + 演示总负责 清单发出后 1 个工作日内 飞书群/文档 定稿场景清单 👤人工判断
3 政府/央国企受众做内容筛查（外网内容、股票娱乐类剔除） 演示总负责 定稿当日 飞书文档 筛查结论 👤人工判断
4 活动 Demo：先出原型评审再定需求，记录名称与范围变更 活动 Demo 第一负责人 活动前 25 天前定稿 原型 + 多维表格 需求定稿单 🔧+👤
5 开发与跑通；演示前回归测试脚本每日跑一次 场景总包 / Demo 开发 活动前 7 天跑通 测试脚本 通过状态 🤖自动化
6 编写各产品演示流程与 QA 云文档并开会过一遍 产品演示文档负责人 活动前 5 天 飞书云文档 演示流程与 QA 🔧+🤖
7 选定演示环境（公网/内网/离线保底），确认访问范围与安全 产品演示文档负责人 + IT 活动前 5 天 环境选择清单 环境确认单 👤人工判断
8 录制保底视频与宣传视频，按规范命名存云盘 产品演示文档负责人 / 视频剪辑 活动前 3 天 飞书云盘 保底录屏、宣传视频 🔧飞书固化
9 搭建前一天按脚本完整走查一遍 演示总负责 活动前 1 天 现场/公司 走查记录 👤人工判断

5. 交付物与模板

  • 交付物：定稿场景清单；活动 Demo 需求定稿单；各产品演示流程与 QA；环境确认单；保底录屏与宣传视频；走查记录。
  • 建议模板/表单：「演示场景库」多维表格字段——场景名、产品线、受众类型、级别（基础/高级）、演示步骤、预制素材、负责人、测试状态、最后通过日期、录屏链接、已知风险、是否适用政府受众；「演示环境选择清单」——公网/内网/离线、访问范围、账号来源、网络依赖、保底方式。

6. 异常与升级

  • 升级条件：场景取舍有争议、需要追加研发资源或基础场景无法按期跑通时，由创始人兼 CTO 拍板（A（升级））；其余演示准备事项由产品总监拍板
  • 场景候选 1 个工作日无人拍板 → 演示总负责直接找场景拍板人 → 当日定稿
  • 活动前 7 天基础场景仍未跑通 → 降级为录屏演示 → 升级场景拍板人（当日）
  • 演示账号余额不足、模型或上游波动 → 切换备用账号/模型，用保底录屏 → 通知研发负责人（1 小时内）
  • 演示环境可能暴露公网或含敏感数据 → 改内网或离线 → IT 与场景拍板人确认（当日）
  • 演示文档含内网地址、账号口令 → 立即迁出正文、改为权限受控存放 → 文档负责人（当日）
  • 活动 Demo 需求反复变更 → 第一负责人冻结版本，变更需拍板人同意（活动前 10 天后）

7. 衡量指标

  • 场景跑通率 = 活动前 7 天跑通的场景数 / 定稿场景数，目标 100%（基础场景）
  • 保底覆盖率 = 有保底录屏的演示场景 / 现场演示场景，目标 100%
  • 需求变更次数 = 活动 Demo 定稿后的需求变更次数，目标 ≤ 2
  • 现场演示故障数 = 现场演示中断或无法完成次数，目标 0

8. 低效诊断

  • 现象：演示准备距大会两周才启动，展区电脑配置要求临时询问｜依据：「Leap产研测」2026-05
  • 现象：案例分派后长期无人跟进，演示视频大会前临时拼凑｜依据：「鼎慧产研决策部」2026-05
  • 现象：素材（图标、截图、视频）分散，演示账号余额、模型波动导致重录｜依据：「Leap产研测」2026-05
  • 现象：产品侧脚本与材料多轮催交，录屏缺口靠临时指定人补录；对外口径中途调整｜依据：「生态大会筹备-产品侧」2026-05
  • 现象：演示用公网还是内网在前一晚才提出，KT 板与背景板内容重复返工｜依据：「生态大会筹备-硬件」2026-05
  • 现象：活动 Demo 运营与研发需求互相等待，名称多次变更，会务方与研发重复做邀请页面｜依据：「生态活动开发组」2026-04、「生态活动开发组」2026-05

9. 分支变体

  • LeapCore：需通过办公网络接入软件连内网演示；LeapBase：使用 share 版，需提前建好资料库；LeapAll：本机安装客户端演示。
  • 大会（全国直播、现场提问）：基础场景必须预制 + 保底录屏，现场提问提前设计。
  • 渠道老板：侧重视频、PPT、合同审查等场景。
  • 政府/央国企：避免外网内容源，需内容筛查。
  • 活动 Demo：现场互动类（汇聚墙、弹幕）与线上类（小程序、网站）；小程序改名需提前 7 天申请审核。

10. 待确认问题

  • 演示总负责是否固定为产品总监？场景拍板是否只由 CTO 一人？
  • 是否建立长期维护的演示场景库与案例库，由谁维护？
  • 演示环境是否需要“一键部署”方案，责任团队是谁？
  • 活动 Demo 是否必须在活动前 25 天冻结需求？
  • 演示账号口令统一存放在哪里？
ECO-20大会物料评审、定稿与采购待优化128

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：大会筹备期，视觉、手册、展板、PPT、视频及身份卡、积分卡、礼品等物料需要统一归集、集中评审定稿、做成本数量决策并采购制作、现场发放。
  • 负责人：主责——物料评审组织人（总经办）（当前：赵雪冰·推断待确认）；协同——各物料负责人（当前：杨萌、陈梦琪、陈震、许君、闫登辉·推断待确认）、素材库与命名规范维护（当前：李凯·推断待确认）、询价采购（当前：潘浩伟、葛家和·推断待确认）、积分卡技术方案（当前：张东郅·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 建物料清单 → ② 统一归集与命名 → ③ 提交初稿 → ④ 一日一审集中评审 → ⑤ 修改复审并记录结论 → ⑥ 品牌合规检查 → ⑦ 成本数量决策 → ⑧ 下单打样与验收 → ⑨ 定稿打包交制作 → ⑩ 现场发放与遗留登记
  • 交付结果：唯一的定稿物料包（含版本记录）、采购/制作验收单、积分卡等物料发放记录。
  • 状态依据：已有一日一审机制、素材库与机器人、方案对比文档，但展板文字反复修改约 10 次、催交约 8 次，同名文件多版本并存，预算来源与授权额度未成文，商标变更后才发现已打印物料需处理。

1. 场景判定

  • 触发条件：大会需要对外展示或发放的物料（视觉 KV、产品/研究院手册、展板、PPT、视频、身份卡、积分卡、礼品、卡套等）进入制作或采购。
  • 典型说法：「今天开始，一天一审，尽快定稿」「所有文档和表格尽量在飞书上创建和修改」「使用 文件名+说明+日期 的格式」「给下预算清单」「这块新的在哪」
  • 判断问题：这个物料是否会印刷、对外发放或在现场展示？是否需要花钱采购？满足其一即走本流程。
  • 不归本流程管：演示场景与 Demo 开发 → 请走 ECO-19；兑换码生成与渠道追踪 → 请走 OPS-10、OPS-12；展区设备借用 → 请走 ECO-21；常规办公采购 → 请走 FIN-01（对公采购申请与付款审批）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
物料评审组织人 物料清单、评审会、催交、定稿打包 R 总经办（当前：赵雪冰·推断待确认）
最终审核 逐项审核、定稿、风格拍板 A CEO（当前：邴龙志·推断待确认）
物料负责人 产出初稿、按意见修改、按时提交 R（各自物料） 产品/生态/市场/销售（当前：杨萌、陈梦琪、陈震、许君、闫登辉·推断待确认）
素材库维护 命名规范、素材库、机器人去重 C 运营负责人（当前：李凯·推断待确认）
询价采购 询价、方案对比、下单打样 R（采购） 研发/测试兼办（当前：潘浩伟、葛家和·推断待确认）
预算授权 额度内授权、额度外拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
数量/礼品 数量核定、礼品 C 研发（当前：吴世豪·推断待确认）
积分卡技术 兑换方案、二维码、上线联调 R（积分卡） 测试负责人（当前：张东郅·推断待确认）、产品运营（当前：杨黔昆·推断待确认）

3. 办之前请准备

  • 物料清单（名称、用途、规格尺寸、数量、负责人、截止日）
  • 品牌规范：最新 Logo、商标、配色、字体、主体名称、活动日期写法
  • 物料预算总额及授权额度（多少金额内物料负责人可自决）
  • 统一素材库链接与命名规则：文件名-说明-日期（如：产品介绍-结尾-0523）
  • 决策请求模板：选项、优点、缺点、成本、推荐
  • 印刷/制作供应商的交期要求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建物料清单，逐项指定负责人与截止日 物料评审组织人 活动前 25 天 飞书多维表格 物料清单 🔧飞书固化
2 发布归集规则：只在飞书创建与修改，离线文件统一上传素材库并按规范命名 素材库维护 清单发布当日 飞书云盘 + 机器人 素材库 🔧+🤖
3 提交初稿链接到物料清单，更新“待审” 物料负责人 活动前 12 天 多维表格 初稿 🔧飞书固化
4 集中评审（一日一审，只邀物料负责人），AI 先查文字密度和错别字 物料评审组织人 活动前 12～5 天每日 飞书会议 + AI 评审意见 🔧+🤖
5 按意见修改，意见与结论记录在清单内，复审至“已定稿” 物料负责人 收到意见后 1 个工作日内 多维表格 修订稿 👤人工判断
6 品牌合规检查：商标、Logo、主体名、日期落款 物料评审组织人 定稿前 检查表 合规确认 🤖+👤
7 成本数量决策：询价并按决策模板提交；额度内物料负责人自决 询价采购 / 预算授权 活动前 15 天前 飞书文档 + 审批 采购决定 🔧+👤
8 下单、打样、验收（实物比对定稿） 询价采购 按交期，最迟活动前 3 天到货 采购审批 验收记录 🔧飞书固化
9 定稿打包（含版本号）交会务/供应商 物料评审组织人 活动前 3 天 飞书云盘 定稿物料包 🔧飞书固化
10 积分卡等发放物料：兑换方案确认、正式服联调、现场发放与遗留登记 积分卡技术 上线前 3 天联调；会后 3 个工作日内处理遗留 兑换系统 + 多维表格 发放记录 🔧+🤖

5. 交付物与模板

  • 交付物：物料清单；评审意见与定稿记录；采购决定与验收记录；定稿物料包；积分卡二维码包与发放记录。
  • 建议模板/表单：「大会物料清单」多维表格字段——物料名、类别（视觉/手册/展板/PPT/视频/卡类/礼品）、负责人、规格、数量、当前版本号、最新链接、审核状态（待审/修改中/已定稿/已下单/已验收）、评审意见、截止日、预算、实际费用、供应商；「决策请求」——选项、优点、缺点、成本、推荐方案、截止拍板时间。

6. 异常与升级

  • 物料负责人逾期未提交 → 组织人当日提醒 → 次日升级最终审核人
  • 评审会人员凑不齐 → 改线上或在清单内异步评审 → 组织人当日决定
  • 定稿后发现品牌信息错误（如商标变更）→ 立即停止制作并评估已印物料 → 升级最终审核人（2 小时内）
  • 采购金额超授权额度 → 按决策模板提交预算授权人（创始人兼 CTO，A（升级））→ 1 个工作日内答复；额度内由物料负责人自决，物料内容定稿由 CEO 拍板
  • 积分卡兑换链接正式服不可用或存在被刷风险 → 暂停发放，研发修复并联调 → 产品总监（当日）

7. 衡量指标

  • 定稿准时率 = 活动前 3 天已定稿物料数 / 物料总数，目标 100%
  • 平均修改轮次 = 各物料定稿前的评审轮次均值，目标 ≤ 3
  • 版本错用次数 = 使用非最新版本导致返工或重印的次数，目标 0
  • 预算偏差 = (实际费用 − 预算) / 预算，目标 ≤ 10%

8. 低效诊断

  • 现象：展板等物料文字、顺序、配色反复修改，评审会时间难凑｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：同名文件多版本并存，资料散在外部聊天群，找文件靠群内询问｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：商标变更在活动前一周才发现，已打印物料需处理｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：预算位置和成本控制标准不清，线下讨论的方案群里无记录，租/买反复｜依据：「生态活动开发组」2026-04、「生态活动开发组」2026-05
  • 现象：积分卡需求描述不清导致多轮讨论，正式服缺少来源字段｜依据：「LeapPPT」2026-05

9. 分支变体

  • 产品手册、研究院手册：需对应产品/研究院负责人先审再进评审会。
  • 展板、KV：评审重点是文字密度与视觉，AI 先检查。
  • 视频：遵循 ECO-19 录屏规范后进入评审。
  • 身份卡（NFC/PVC/纸质）、证卡打印机（租/买）、卡套绳子：走步骤 7～8 决策与采购。
  • 积分卡：实体卡刮码兑换，链接不带兑换码，统一来源参数；线上券另走 OPS-10。

10. 待确认问题

  • 物料评审组织人是否固定为总经办？最终审核是否只由 CEO？
  • 大会物料的授权额度是多少（多少以内物料负责人可自决）？
  • 物料采购是否必须走飞书采购审批，由谁执行下单与付款？
  • 素材库机器人去重和“最新版”标记由谁维护？
  • 积分卡兑换的防刷规则由谁确认？
ECO-21大会展区硬件、搭建彩排与现场执行待新建200

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：大会前一周至当天，需要借用/验收/装机演示机、确认现场电力网络、安排展区值守与交接、运输搭建、彩排清场、签到引导及现场故障响应。
  • 负责人：主责——现场执行负责人（总经办）（当前：赵雪冰·推断待确认）；协同——展区负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、外设与运输（当前：闫登辉·推断待确认）、活动码负责人（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 设备清单与借用登记 → ② 验收装机与配置 → ③ 会场电力网络确认 → ④ 展区排班与话术交接 → ⑤ 活动码清单与压测 → ⑥ 彩排 → ⑦ 装箱清点与运输搭建 → ⑧ 当天清场、签到、现场响应 → ⑨ 设备归还与调休登记
  • 交付结果：设备清单与借还台账、装机验收记录、展区排班与交接确认、彩排记录、现场执行清单、会后设备归还验收单。
  • 状态依据：有设备配置表与确认打勾做法，但每次大会临时拉群，前一晚还在找显示器、U 盘、翻页笔，设备未装箱，展区交接断档，活动二维码因访问频繁被限制且不清楚谁负责，无统一现场执行清单。

1. 场景判定

  • 触发条件：大会/展会进入最后 10 天，需要现场演示设备、展区值守、搬运搭建或签到引导。
  • 典型说法：「先把硬件确认一下吧」「把 Windows 更新关了」「找个人接替你，把你的上下文给他」「统一下午五点，把要带到会场的东西整理好」「活动二维码因为频繁访问被限制了，谁来看看」
  • 判断问题：是否需要把设备和人员带到现场，并保证当天演示、签到、扫码不出事？
  • 不归本流程管：演示内容与 QA 文档编写 → 请走 ECO-19；物料制作 → 请走 ECO-20；嘉宾接待 → 请走 ECO-16；座次图制作 → 请走 ECO-18；加班调休审批 → 请走 HR-12（加班申请、工时登记与调休）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
现场执行负责人 现场执行清单、会务分工、到场时间、清场规则、彩排 A/R 总经办（当前：赵雪冰·推断待确认）
展区负责人 设备需求、软件分配、哨兵排班、交接验收 R（展区） 产品总监（当前：杨萌·推断待确认）
IT 运维 会场电/网/WiFi 对接、专线、布网、内网接入范围 R（网络） IT 运维（当前：杨明学·推断待确认）
装机 开机验收、装系统、关自动更新、装软件 R（装机） 交付部署工程师（当前：游家豪·推断待确认）
外设与运输 外借设备、外设、统一叫车、装卸 R（运输） 销售骨干（当前：闫登辉·推断待确认）
展区哨兵 值守演示、接待、现场远程调试 R（值守） 研发（当前：王皓南、宋祺睿、岳阳、李铭熙·推断待确认）、LeapBase 负责人（当前：刘昱潇·推断待确认）
接班哨兵 接收交接、复述话术 R（接班） FDE Leader（当前：黄振锋·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）
活动码负责人 二维码/小程序码清单、压测、备用码 R（活动码） 生态组负责人（当前：陈梦琪·推断待确认）、客户端研发（当前：葛家和·推断待确认）
签到与座次指引 现场座次图发布、指引 C 人事负责人（当前：黄莹·推断待确认）
风险把关 研发优先级、展示边界 C 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 设备清单：型号、配置、来源（自有/借用）、需装软件（LeapAll/LeapCore/LeapBase）、归还日期
  • 会场信息：搭建时间、电源位置、网络/WiFi、卸货点与楼层、清场时间
  • 展区哨兵名单与备班名单
  • 交接包：产品价值话术、演示视频、QA、兜底话术、不可展示内容清单
  • 现场所有二维码/小程序码清单及其后台负责人
  • 现场杂物清单：U 盘、翻页笔、拖线板、显示器、拖车、工牌

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认设备清单与软件分配，借用设备登记（来源、归还日期） 展区负责人 活动前 10 天 飞书多维表格 设备清单、借还台账 🔧飞书固化
2 开机验收、装系统、关闭自动更新、装产品与远程工具，逐台打勾 装机 活动前 7 天 多维表格 装机验收记录 🔧飞书固化
3 与会场确认电力、网络、WiFi，必要时拉专线 IT 运维 活动前 7 天 会务对接 网络电力确认单 👤人工判断
4 发布哨兵排班；原负责人无法值守时当面交接，接班人复述一遍 展区负责人 活动前 5 天完成交接 交接清单 排班表、交接确认 🔧+👤
5 汇总活动码清单，指定负责人，压测并准备备用码 活动码负责人 活动前 3 天 多维表格 活动码清单、压测结果 🔧+🤖
6 彩排：圆桌、大赛预彩排；展区按脚本在公司过一遍 现场执行负责人 活动前 3～2 天 会议室 彩排记录 👤人工判断
7 统一时间装箱清点（按装箱清单打勾），统一叫车运输，当晚搭建布网、远程调试 外设与运输 / IT 运维 活动前 1 天 17:00 装箱完成 装箱清单 装箱与搭建记录 🔧飞书固化
8 当天：发布会务分工与到场时间、清场规则、签到与座次指引；故障进现场响应群 现场执行负责人 活动当天开场前 2 小时 飞书群 现场执行清单 🔧+👤
9 设备回收、借用设备验收归还；筹办人员调休/加班统一登记 展区负责人 / 现场执行负责人 活动后 3 个工作日内 借还台账、考勤 归还验收单、登记表 🔧飞书固化

5. 交付物与模板

  • 交付物：设备清单与借还台账；装机验收记录；网络电力确认单；排班表与交接确认；活动码清单；彩排记录；装箱清单；现场执行清单；归还验收单。
  • 建议模板/表单：「大会现场执行清单」多维表格——设备表（编号、型号、配置、来源、软件、责任人、装机状态、装箱状态、归还状态）；人员表（岗位、姓名、时段、到场时间、备班人）；交接表（产品、话术链接、演示视频、QA、兜底话术、不可展示内容、接班人复述确认）；活动码表（用途、平台、后台负责人、压测结果、备用码）。

6. 异常与升级

  • 借用设备配置不满足 → 展区负责人当日调换 → IT 运维协助（1 个工作日内）
  • 会场网络不可用 → 切换 4G/5G 热点或离线保底录屏 → IT 运维（30 分钟内）
  • 哨兵临时冲突（客户交付、接待）→ 启用备班人并完成交接 → 展区负责人（当日），优先级冲突升级 CTO
  • 活动二维码被限制或无法访问 → 立即切备用码并在现场广播 → 活动码负责人（15 分钟内）
  • 设备丢失或损坏 → 现场登记并拍照 → 升级现场执行负责人与行政（当日）
  • 现场人手不足 → 现场执行负责人从各部门调人 → 升级 CEO（1 小时内）

7. 衡量指标

  • 装机验收完成率 = 活动前 7 天验收通过设备数 / 设备总数，目标 100%
  • 交接完成率 = 已完成复述确认的换班岗位 / 换班岗位总数，目标 100%
  • 现场故障恢复时长 = 故障发现到恢复的分钟数，目标 ≤ 15 分钟
  • 设备归还及时率 = 按期验收归还的借用设备 / 借用设备总数，目标 100%
  • 临时采购/补缺次数 = 活动前 1 天及当天临时找物品的次数，目标 ≤ 2

8. 低效诊断

  • 现象：演示机配置差异需翻历史消息，前一天才发现缺显示器、缺软件；活动日期被误传｜依据：「生态大会筹备-硬件」2026-05
  • 现象：信息分散在群聊，执行方反问“现在需要我们做什么”，需要统一写通知文档｜依据：「生态大会筹备-硬件」2026-05
  • 现象：展区原负责人转去接待后交接断档，接班人不知道材料由谁准备，话术和视频多次催问｜依据：「生态大会筹备-硬件」2026-05
  • 现象：会前一晚找 U 盘、翻页笔、拖车，设备清点靠群里问｜依据：「模态集团（全员群）」2026-05
  • 现象：设备未装箱、伴手礼未装，卸货楼层和人员不清｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：活动二维码因访问频繁被限制，无人知道由谁负责｜依据：「跃迁生态大会筹备群」2026-05

9. 分支变体

  • 公司内演示机：先在公司装软件、过流程；现场机：电网接通后远程调试。
  • 借用设备：必须登记来源与归还日期，会后验收归还。
  • 产研人员只负责演示，不承接商务；商务问题用兜底话术引导到商务对接。
  • 对外大会与内部年会：内部年会可省略步骤 4、5。

10. 待确认问题

  • 现场执行负责人是否固定为总经办？展区负责人是否固定为产品总监？
  • 是否建立公司通用的“展会物资清单”，由行政还是 IT 维护？
  • 活动码（二维码、小程序码）上线前压测由哪个团队负责？
  • 筹办人员周末调休与加班费口径是否已有制度？
  • 外借设备的损坏责任与归还验收由谁签字？
ECO-22培训营报名筛选、分层与名单管理待优化108

状态：待优化｜证据：有证据（卡片 4 张 / 会话 1 个）｜优先级：频3 × 耗4 × 跨3 × 险3

  • 适用场景：FDE 等培训营报名问卷持续涌入（千人级）时，需要按准入标准评分并分为初/中/高级，确定班级规模与落选去向，维护唯一名单，并向主管部门和领导汇报报名看板。
  • 负责人：主责——培训营统筹（生态组负责人）（当前：陈梦琪·推断待确认）；协同——FDE 评分执行（当前：佘天禾·推断待确认）、准入标准与复核（当前：郭逸非·推断待确认）、评分标准校准（当前：吴亚军·推断待确认）、筛选 SOP 文档（当前：谭涛·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 开班前定准入标准、比例与容量 → ② 建唯一名单源 → ③ AI 按规则打分分层 → ④ 人工复核与特殊人员判断 → ⑤ 定班级规模与分流标签 → ⑥ 输出带版本的入选名单 → ⑦ 生成报名看板并评审发布 → ⑧ 新增报名后增量重跑
  • 交付结果：唯一在线名单（含分数、分层、分流标签、变更记录）、首批入选名单、报名数据看板（总览 + 分层，隐藏分数）。
  • 状态依据：已有成文的评分筛选分层 SOP（多版本）与 AI 评分工作流，但准入标准多次修订（高级人数过多重做、无佐证者被打成中级需重跑），每次 AI 结果都需人工复核，班级容量反复变更，名单多文件并存，看板需求同晚多轮返工。

1. 场景判定

  • 触发条件：培训营/训练营开放报名后，报名人数超过首期容量，或需要分层分班。
  • 典型说法：「高级有斩杀线，没有 MCP 落地的都不能是高级」「每导出一版本，要标注好时间精确到分钟」「初级班 80-100 人以内，中级班 30 人以内」「主管部门和领导都能清晰看见」
  • 判断问题：是否需要从报名名单中“选人、分层、定人数”？如果名单已定、只是分班，走 ECO-23。
  • 不归本流程管：按行业分班、特殊插班 → 请走 ECO-23；电话/短信外联与补位 → 请走 ECO-24；课程设计与授课 → 请走 X-FDE-16（FDE 课程体系开发与评审）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
培训营统筹 定容量、抽查、验收名单与看板、对上汇报 A 生态组负责人（当前：陈梦琪·推断待确认）
评分执行 编写评分规则、AI 跑分、输出名单与看板 R FDE 成员（当前：佘天禾·推断待确认）
准入标准与复核 给出准入标准与比例、人工复核、看板细节评审；标准争议时拍板 A（升级） 开放平台负责人（当前：郭逸非·推断待确认）
标准校准 后期校准 AI 打分标准 C FDE 课程负责人（当前：吴亚军·推断待确认）
文档维护 维护筛选 SOP 文档 R（文档） 生态运营（当前：谭涛·推断待确认）
汇报对象 查看报名看板 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 各层级准入标准（初级/中级/高级的硬性条件与佐证要求）与目标比例（如 6:3:1）
  • 首期各级容量与“一公司限几人”等约束
  • 报名问卷导出数据，及唯一的在线名单（多维表格/在线表格）
  • 可复用的 AI 评分规则（Skill/脚本）及输出模板
  • 分流标签清单：首期录取、候补、后续批次、基础预备池、企业组织合作、招进模态、持续关注
  • 数据安全要求：学员个人信息不上公网托管

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 开会确定准入标准、比例、各级容量与公司人数限制，写入 SOP 准入标准与复核 + 培训营统筹 报名截止前 5 个工作日 飞书云文档 标准与容量说明 👤人工判断
2 问卷数据导入唯一在线名单；每次导出文件命名带时间（精确到分钟） 评分执行 每次导出时 多维表格 唯一名单源 🔧飞书固化
3 AI 按规则打分分层，只依据简介与简历中的佐证 评分执行 导入后 1 个工作日内 AI 评分 Skill/脚本 分数 + 分层 🤖自动化
4 人工复核：抽查 ≥ 10%，存疑标黄并备注；政府/重点单位人员人工判断 准入标准与复核 + 培训营统筹 AI 结果出来后 1 个工作日内 多维表格 复核结论 👤人工判断
5 确定各级开班人数，给每人打分流标签 培训营统筹 复核完成当日 多维表格单选字段 分流结果 🔧+👤
6 输出首批入选名单，记录版本号与变更日志 评分执行 分流后当日 多维表格视图 入选名单 V*.* 🔧飞书固化
7 生成报名看板（总览 + 分层，隐藏分数、附标准说明），内部评审后发布 评分执行 名单发布后 1 个工作日内 看板模板 + 内网 报名看板 🤖+👤
8 新增报名按增量重跑步骤 3～7，看板同步刷新 评分执行 每批新增后 1 个工作日内 同上 更新名单与看板 🤖自动化

5. 交付物与模板

  • 交付物：准入标准与容量说明；唯一在线名单；首批入选名单（带版本）；报名看板；变更日志。
  • 建议模板/表单：「培训营报名名单」多维表格字段——报名序号、姓名、单位、职务、行业、联系方式（权限受控）、简介摘要、佐证材料、AI 分数、AI 分层、人工复核结论、存疑标记、最终层级、分流标签、批次、版本号、最后修改人、修改时间；看板模板：总览页（总数、来源、行业、地区）+ 分层页（各层人数与标准说明，不显示个人分数）。

6. 异常与升级

  • 升级条件：准入标准或分层比例需调整、AI 分层明显偏离目标时，由开放平台负责人拍板标准（A（升级））；容量、名单与看板验收由培训营统筹拍板
  • AI 分层比例明显偏离目标（如高级过多）→ 暂停发布、修订规则后重跑 → 准入标准与复核人确认（1 个工作日内）
  • 简历识别失败或无佐证被高分 → 人工修正并补写规则 → 评分执行（当日）
  • 容量调整（增减名额）→ 培训营统筹书面确认后更新参数并重跑 → 通知外联组（当日）
  • 存在“同公司多人”“开后门”观感的名单 → 按公司人数限制处理 → 培训营统筹拍板
  • 看板需对外展示 → 隐藏分数和个人信息，不走公网托管 → 培训营统筹验收（发布前）

7. 衡量指标

  • 复核改判率 = 人工复核改判人数 / AI 分层人数，目标 ≤ 5%（越低说明规则越稳）
  • 名单版本数 = 首批名单发布前产生的正式版本数，目标 ≤ 3
  • 筛选周期 = 报名截止到首批名单发布的工作日数，目标 ≤ 3 个工作日
  • 看板返工轮次 = 看板发布前需求变更轮次，目标 ≤ 1

8. 低效诊断

  • 现象：评分标准未经会上充分讨论即开跑，高级人数过多需重做｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：AI 将无佐证者判为中级，需限定依据范围重写规则并重跑；AI 输出表格需二次加工｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：名单多文件并存，不标版本导致新增报名易丢失｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：首期容量初期无人知晓，人数多次变更｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：看板需求同一晚多轮变更（先分层后总览、再加导航和说明、隐藏分数），工具选型有分歧｜依据：「FDE培训班专班沟通群」2026-09

9. 分支变体

  • 首批：初/中级，高级暂不单独开班，中级同一公司限 1 人。
  • 后续批次：按行业分班，容量与口径另定（衔接 ECO-23）。
  • 政府/重点单位/企业负责人：不受 AI 分数限制，人工判断。

10. 待确认问题

  • 准入标准与容量由谁最终拍板：生态组负责人还是 FDE/开放平台负责人？
  • AI 评分是否统一固化为一个 Skill，并由谁维护？
  • 名单唯一源用多维表格还是在线表格？
  • 看板是否统一用 LeapCore 生成并内网发布？
  • 落选者是否需要正式通知，口径由谁出？
ECO-23学员分班、批次分配与特殊插班待优化108

状态：待优化｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：培训营名单确定后，需要按行业分批分班（每班约 100 人）并录入报名系统，处理销售/领导/政府推荐的插班、同事同班、旁听，以及统一“为什么没进首批/为什么在初级”的对外口径。
  • 负责人：主责——分班负责人（FDE 教务）（当前：佘天禾·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、名单清洗（当前：谭涛、蔡鸿坤、侯晨帆·推断待确认）、系统导入（当前：邓乾·推断待确认）、销售侧（当前：韩诗琪、朱文瑜·推断待确认）、口径制定（当前：陈梦琪·推断待确认）；兜底——开放平台负责人（当前：郭逸非·推断待确认）
  • 核心流程：① 发布分班规则 → ② 按行业拆表清洗 → ③ 标记特殊人群 → ④ 分批分班与人数平衡 → ⑤ 特殊通道插班 → ⑥ 人工复核终审 → ⑦ 导入报名系统并生成自助查询 → ⑧ 发布对外口径与 Q&A → ⑨ 调班与二次分班
  • 交付结果：各批次各班名单（已录入生态资源池 SaaS）、自助查询页、特殊通道登记表、对外口径与 Q&A 更新。
  • 状态依据：有批次分配说明、行业分类表与 SaaS 导入，但分类数反复调整，出现同号两名、漏分组被追问；推荐名单散落、靠人记忆预留名额；电话人员临时答“随机抽样”与筛选标准矛盾，被事后纠正。

1. 场景判定

  • 触发条件：报名名单（ECO-22 输出）已确定，需要分批分班；或收到推荐插班、调班、同事同班、旁听请求；或学员询问为何未进首批。
  • 典型说法：「分班是按照行业来的」「这种人特事特办，单独给他分组」「这些人一定要给他们预留位置」「不知道的一律说记录下来确认后回复」
  • 判断问题：是否在决定“某人进哪一批、哪一班”或回答“为什么这样分”？
  • 不归本流程管：评分分层与容量 → 请走 ECO-22；电话短信通知、台账、补位 → 请走 ECO-24。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分班负责人 发布分班规则、汇总、终审 R FDE 成员（当前：佘天禾·推断待确认）
规则拍板 分班标准、特殊人群标记、特事特办拍板 A FDE 课程负责人（当前：吴亚军·推断待确认）
名单清洗 按段清洗、重分“其他行业”、标记 R 生态运营（当前：谭涛、蔡鸿坤、侯晨帆·推断待确认）
特殊通道对接口 接收销售推荐名单，经 SaaS 添加 R（插班） 生态运营（当前：谭涛·推断待确认）
系统导入 导入生态资源池 SaaS、生成查询页 R（系统） LeapAll 服务端研发（当前：邓乾·推断待确认）
销售侧 行业关键词、推荐客户 C 销售支持（当前：韩诗琪·推断待确认）、销售（当前：朱文瑜·推断待确认）
领导推荐处理 领导/政府推荐人员指示 C 开放平台负责人（当前：郭逸非·推断待确认）
口径制定 对外解释口径与 Q&A，报规则拍板人确认 R 生态组负责人（当前：陈梦琪·推断待确认）

3. 办之前请准备

  • ECO-22 输出的最终名单（层级、分流标签、版本号）
  • 批次数、每班人数上限、各批上课时间
  • 行业分类表与关键词（工程、制造、高校/OPC、AI 新兴、其他）
  • 特殊人群标记规则（颜色/标签含义）与预留名额数
  • 生态资源池 SaaS 导入权限
  • 最新版 FDE 培训 Q&A 与对外口径

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布分班规则（批次、班容量、行业分类、三步：校准→筛选→复核） 分班负责人 名单定稿后 1 个工作日内 飞书云文档 分班规则说明 👤人工判断
2 按行业自动预分类，“其他行业”人工重分入主类 名单清洗 规则发布后 2 个工作日内 脚本/LeapCore + 多维表格 行业分类结果 🤖+👤
3 按统一标签标记特殊人群（自媒体、高管与数字化负责人、无业、销售推荐伙伴） 名单清洗 与步骤 2 同步 多维表格单选字段 标记结果 🔧飞书固化
4 先扣除预留名额，再按批次分班，检查班级人数均衡与去重（同号多名） 分班负责人 分类完成后 1 个工作日内 脚本 分班草案 🤖自动化
5 特殊通道：推荐人员统一经表单提交给对接口，未报名者补信息；领导推荐由规则拍板人确认 特殊通道对接口 分班草案前提交；之后随时登记 多维表格表单 特殊通道登记表 🔧+👤
6 人工复核终审，检查“未分组”人员 分班负责人 + 规则拍板 草案完成后 1 个工作日内 多维表格 终版分班名单 👤人工判断
7 导入生态资源池 SaaS，生成自助查询页 系统导入 终审后 1 个工作日内 生态资源池 SaaS 查询页 🤖自动化
8 更新对外口径与 Q&A（评分角度、分班依据、不确定先记录后回复），培训一线人员 口径制定 外联开始前 1 个工作日 FDE 培训 Q&A 口径与 Q&A 🔧+🤖
9 调班、时间冲突二次分班；锁定后不再换班 分班负责人 开课前 1 天锁定 SaaS + 多维表格 调班记录 🔧飞书固化

5. 交付物与模板

  • 交付物：分班规则说明；终版分班名单；特殊通道登记表；SaaS 自助查询页；更新后的 Q&A 与口径；调班记录。
  • 建议模板/表单：「特殊通道登记」多维表格表单——被推荐人、单位、推荐来源（销售/领导/政府/学员自荐）、推荐人、是否已报名、需求（插班/同事同班/旁听/跳级）、拍板人、分配批次与班级、处理状态、处理日期；分班名单增加字段：行业、特殊标签、批次、班级、是否预留、调班记录。

6. 异常与升级

  • 分类标准争议（分几类、某行业归属）→ 规则拍板人当日定 → 写入分班规则
  • 同一手机号多名、漏选层级导致“未分组” → 分班负责人核实后补分 → Q&A 补写规则（当日）
  • 领导/政府推荐人员 → 规则拍板人确认“特事特办”，单独分组并登记 → 当日
  • 学员询问分班原因或要求跳级 → 一线只答评分角度，不确定的记录并在 1 个工作日内回复 → 口径制定人
  • 班级人数严重失衡 → 分班负责人调整后重新导入 → 锁定前完成

7. 衡量指标

  • 分班准确率 = 1 − (误分 + 未分组人数) / 总人数，目标 ≥ 99.5%
  • 特殊通道处理时长 = 登记到分配完成的工作日数，目标 ≤ 1 个工作日
  • 口径偏差次数 = 一线答复与 Q&A 不一致被纠正的次数，目标 0
  • 锁定后调班数 = 名单锁定后的换班人数，目标 0（特事特办除外）

8. 低效诊断

  • 现象：分类数从 3 到 5 反复调整，班级人数不平衡被延后处理｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：同一手机号对应两个名字，漏选初级班者被标为“未分组”后被追问｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：销售推荐名单散落，靠对接人提醒才预留名额；分班后才补塞｜依据：「FDE培训班专班沟通群」2026-09、「FDE培训班专班沟通群」2026-10
  • 现象：一线人员临时答“随机抽样/按报名顺序”，与筛选标准矛盾，事后纠正｜依据：「FDE培训班专班沟通群」2026-09

9. 分支变体

  • 首批：按层级分班，中级同一公司限 1 人。
  • 后续批次（共 5 批，至年底）：按行业分班，每班约 100 人。
  • 重点人员插班：单独分组或预留名额。
  • 同事同班、旁听：通过补录问卷登记后处理。

10. 待确认问题

  • 分班终审是 FDE 教务还是 FDE 课程负责人？
  • 每批预留给销售/领导推荐的名额比例是多少？
  • 特殊人群颜色/标签含义是否需要统一成字段？
  • 对外口径是否需要定期（每批次）更新并由谁发布？
  • 生态资源池 SaaS 添加权限给到哪些岗位？
ECO-24学员外联确认、台账与候补补位待优化256

状态：待优化｜证据：有证据（卡片 6 张 / 会话 1 个）｜优先级：频4 × 耗4 × 跨4 × 险4

  • 适用场景：培训营批次名单确定后，需要电话邀约确认、批量短信通知、协调兼职外包、实时记录联系台账并核实进群，对放弃或联系不上的名额进行候补补位。
  • 负责人：主责——外联组长（当前：谭涛·推断待确认）；协同——培训营统筹（当前：陈梦琪·推断待确认）、电话外联（当前：蔡鸿坤·推断待确认）、官微与拉群（当前：侯晨帆·推断待确认）、名单与统计（当前：佘天禾·推断待确认）、支援外联（当前：韩诗琪、丁蕊、汪家诺·推断待确认）、短信通道技术（当前：邓乾、宋祺睿·推断待确认）、人事（兼职招募）（当前：待指定）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）
  • 核心流程：① 一页版外联 SOP → ② 人手与兼职到位 → ③ 名单分配 → ④ 电话确认 → ⑤ 合规短信通知 → ⑥ 实时记台账 → ⑦ 进群核实与每日汇总 → ⑧ 缺口候补补位 → ⑨ 开课前锁定名单
  • 交付结果：每班确认参加并已进群的锁定名单、完整联系台账（意向/进群/备注）、每日汇总报告、候补补位记录。
  • 状态依据：已有电话话术、外联 SOP 草案与在线台账，但两版 SOP 并行不对齐；记录滞后需反复追问进度；外联手机号多次被运营商封禁，带链接/二维码短信被拦截出现“0 人回复 0 人进群”；兼职临时不到岗，补位靠临时指派。

1. 场景判定

  • 触发条件：ECO-23 分班名单已导入系统（最迟开课前 12 天）；或某班确认人数低于容量。
  • 典型说法：「先联系，联系完发短信，用什么手机发」「台账别零碎记录，不好追踪」「放弃的快速补位」「要确认打过的电话一定要进群」
  • 判断问题：是否要联系学员确认参加并让其进群？
  • 不归本流程管：筛选分层 → 请走 ECO-22；分班、插班规则与对外口径 → 请走 ECO-23；兼职人员的招聘 → 请走 X-RCT-01（招聘需求提报），用工协议走 HR-04；短信签名资质所需证照与授权材料 → 请走 LEG-10，用印走 LEG-09。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
外联组长 外联 SOP、话术、短信模板、名单分配、台账汇总、牵头补位 R 生态运营（当前：谭涛·推断待确认）
培训营统筹 节奏、验收汇总、协调人手 A 生态组负责人（当前：陈梦琪·推断待确认）
电话外联 按名单拨打、记录 R 生态运营（当前：蔡鸿坤·推断待确认）
官微与拉群 官微加好友、拉群、群成员核对、补录通道 R 生态运营（当前：侯晨帆·推断待确认）
名单与统计 名单导出、统计 C FDE 成员（当前：佘天禾·推断待确认）
支援外联 分段拨打 R（各自段落） 销售支持（当前：韩诗琪·推断待确认）、行政助理（当前：丁蕊·推断待确认）、销售（当前：汪家诺·推断待确认）
短信通道 商业短信、外呼平台接入 C 研发（当前：邓乾、宋祺睿·推断待确认）
体验与规则、兜底 通知体验要求、重开补录问卷；外联组长缺位时接手外联统筹 C/R（兜底） FDE 课程负责人（当前：吴亚军·推断待确认）
兼职招募 招募兼职/外包、确认到岗 C 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • ECO-23 终版分班名单与自助查询页
  • 一页版外联 SOP（正文 1 页，话术与 Q&A 作附件）：筛选标准摘要、联系谁确认什么、名单与话术、记录方式与异常给谁、确认后去向（测评/录取/候补）
  • 电话话术：自我介绍 → 确认意向 → 课程时间地点 → 进群方式 → 兜底（不确定的记录后回复）
  • 企业商业短信通道与已备案签名、无链接短信模板
  • 联系台账（统一字段）及编辑权限
  • 兼职材料包：名单段、话术、台账权限、Q&A
  • 候补池（按报名顺序/意向排序）与补录问卷

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 定稿一页版外联 SOP（唯一一份，在飞书云文档协同） 外联组长 分班名单导入后 1 个工作日内（最迟开课前 10 天） 飞书云文档 外联 SOP 🔧+🤖
2 确认人手：内部排班 + 兼职到岗，发材料包并开通台账权限 外联组长 / 人事 开课前 8 天 飞书 排班表 🔧飞书固化
3 按上课批次优先分配名单段，有疑问者放最后 外联组长 开课前 8 天 多维表格视图 个人名单段 🔧飞书固化
4 电话确认；未接听间隔 ≥ 2 小时回拨，最多 2 次；重点学员人工跟进 电话外联 / 支援外联 分配后 2 个工作日内打完 电话 / AI 外呼 通话结果 🤖+👤
5 发通知短信：企业商业短信通道、已备案签名、不带链接和二维码，引导公众号查询并回复“收到+已加入”；群发前先向同事自测 外联组长 电话后当日 云厂商短信平台 发送记录 🔧+🤖
6 每通电话后 10 分钟内记录台账（意向、是否进群、备注） 外联人员 实时 多维表格 联系台账 🔧飞书固化
7 进群核实：按手机号与群成员对账，未进群标红再跟进；每日 18:00 前按班汇报 官微与拉群 / 外联组长 每日 多维表格 + 群成员同步 每日汇总 🔧+🤖
8 缺口 ≥ 5 人的班触发补位：从后续批次候补池按顺序联系，其次补录问卷、官微插班、销售推荐 外联组长 缺口出现后 1 个工作日内 候补池 + 补录问卷 补位记录 🔧+👤
9 开课前 1 天下午锁定名单，之后不换班 外联组长 开课前 1 天 多维表格 锁定名单 🔧飞书固化

5. 交付物与模板

  • 交付物：外联 SOP；排班表；联系台账；短信发送记录；每日汇总；补位记录；锁定名单。
  • 建议模板/表单：「学员联系台账」多维表格字段——学员ID、姓名、批次、班级、层级、联系人（外联人员）、第 1 次拨打时间、结果（确认/暂定/放弃/未接听/空号）、第 2 次拨打、短信已发、是否进群、进群核对时间、放弃原因、补位来源、备注；每日汇总视图：按班统计确认进群/暂定/放弃/未接听。

6. 异常与升级

  • 外联手机号被运营商封禁 → 停用个人号，改企业外呼/商业短信 → 外联组长当日报培训营统筹
  • 短信被拦截、进群率接近 0 → 停发，改无链接模板并自测 → 短信通道技术（1 个工作日内）
  • 短信签名需新增主体资质（研究院）→ 先用已备案的苏州模态跃迁主体签名 → 合规承诺函走 LEG-09 用印审批（3 个工作日内）
  • 兼职未按时到岗 → 外联组长当日调内部人员支援 → 人事 1 个工作日内补招，长期需求升级 CEO 决定是否签劳务派遣
  • 学员问题超出 Q&A → 记录后 1 个工作日内回复 → 口径制定人（ECO-23）
  • 汇报数据与群成员不一致 → 外联组长当日对账 → 培训营统筹

7. 衡量指标

  • 联系完成率 = 2 个工作日内有结果的学员 / 分配学员，目标 ≥ 95%
  • 进群率 = 已进群人数 / 确认参加人数，目标 ≥ 95%
  • 台账及时率 = 通话后 10 分钟内记录的条数 / 通话总数，目标 ≥ 95%
  • 满班率 = 锁定时实际人数 / 班级容量，目标 ≥ 90%
  • 短信触达有效率 = 短信后 24 小时内回复或进群人数 / 发送人数，目标 ≥ 30%

8. 低效诊断

  • 现象：筛选 SOP 与电话 SOP 两版并行不对齐，未定稿先套公文格式，讨论散在多个群｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：联系结果不实时更新、零碎记录，统筹多次追问进度｜依据：「FDE培训班专班沟通群」2026-09、「FDE培训班专班沟通群」2026-10
  • 现象：外联手机号被运营商识别为风险号码封禁至少 3 次｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：个人手机群发带链接/二维码短信被拦截，发送后无人回复、无人进群；商业短信签名只有单一主体｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：兼职临时不到岗，外包未记录条目五十余条，仍靠内部人手｜依据：「FDE培训班专班沟通群」2026-09、「FDE培训班专班沟通群」2026-10
  • 现象：到场率预估不准，补位多轮临时指派｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 首批：人工逐个电话 + 官微拉群。
  • 后续批次：电话 + 无链接短信 + 公众号查询；多人 + 兼职分段，按上课批次优先。
  • 补位渠道顺序：后续批次候补 → 补录问卷 → 官微主动插班/旁听 → 报中级但愿上初级者 → 销售推荐客户与渠道。

10. 待确认问题

  • 外联组长是否固定由生态运营承担？培训营统筹是否为生态组负责人？
  • 是否接入 AI 外呼与企业商业短信，预算与审批人是谁？
  • 研究院主体短信签名是否申请，由谁办理？
  • 是否与劳务派遣团队签长期合作，由人事还是生态组对接？
  • 补位触发阈值（缺口 5 人）与锁定时间（开课前 1 天）是否可行？
ECO-25学员答疑、班级群与自助查询待优化180

状态：待优化｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：培训学员确认入选后，需要加官微、进班级群、接收通知、提问答疑，或自助查询分班、上课时间地点和群二维码
  • 负责人：主责——生态运营（官微与 Q&A）（当前：侯晨帆·推断待确认）；协同——FDE 课程负责人（当前：吴亚军·推断待确认）、开放平台负责人（课程/考核答疑）（当前：郭逸非·推断待确认）、LeapAll 服务端研发（查询页）（当前：邓乾·推断待确认）、FDE 成员（Q&A 接机器人）（当前：佘天禾·推断待确认）、AI 讲师/助教（当前：梅立·推断待确认）；兜底——研究院生态负责人（当前：陈梦琪·推断待确认）
  • 核心流程：① 入选通知 → ② 加官微并拉入班级群 → ③ 配置查询页 → ④ 收集问题进待答池 → ⑤ 分派责任人答复 → ⑥ 入库 Q&A 并同步机器人 → ⑦ 课前须知/FAQ 更新下发
  • 交付结果：学员全部进入对应班级群；查询页信息准确可自助查询；唯一一份持续更新的 Q&A 文档及接入客服机器人的知识库；每批次的课前须知 PDF
  • 状态依据：已有 Q&A 飞书文档、课前须知 PDF、生态资源池查询页和业务知识助手机器人；但 2026-09～10 群内出现重复新开 Q&A 文档、待答问题需多次 @ 催答约 6 次，二维码 7 天失效需重复导出、查询页占位符/标题/测试数据未清理等返工约 9 次

1. 场景判定

  • 触发条件：学员入选名单确认；学员在官微、班级群、小红书提问；分班/时间/地点/群码有变化需要让学员知道
  • 典型说法：「统一先引导报名者添加官微，再拉群」「能不能直接报中级/旁听？」「查不到自己分在哪个班」「企业微信二维码 7 天失效了」「回复准确 > 回复快」
  • 判断问题：提问人是否为已报名/已入选的培训学员？问题是否属于课程安排、考核、分班、通知、设备要求等学员服务范畴？
  • 不归本流程管：报名筛选与入选名单确定 → 请走 ECO-22（培训营报名筛选、分层与名单管理）；线下实操环境与算力准备 → 请走 ECO-26；开班仪式与会务 → 请走 ECO-27；结营后的商机转化 → 请走 ECO-28；媒体/舆情类公开发言 → 请走 BRD-18（品牌舆情监测与危机公关处置），媒体采访走 BRD-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
官微与 Q&A 维护人 持有官微、拉群、收集问题、维护 Q&A 文档、更新二维码 R 生态运营（当前：侯晨帆·推断待确认）
口径负责人 非课程类问题答复、回复口径与群规则审定，最终负责 A 研究院生态负责人（当前：陈梦琪·推断待确认）
课程/考核答疑人 课程内容、考核规则类问题答复 R 开放平台负责人（当前：郭逸非·推断待确认）
需求方 规定查询页字段、提出群与通知需求 C FDE 课程负责人（当前：吴亚军·推断待确认）
查询页开发 名单导入、分组配置、页面修复 R LeapAll 服务端研发（当前：邓乾·推断待确认）
机器人接入 Q&A 整理并接入客服机器人 R FDE 成员（当前：佘天禾·推断待确认）
班主任/讲师 群内集中解答、宣读课前须知 C AI 讲师/助教（当前：梅立·推断待确认）

3. 办之前请准备

  • 最终入选名单（姓名、手机号、批次、班级），已按班级分组
  • 官微（企业微信）账号可用，且有至少一名备岗可登录
  • 统一群名规则（如：FDE-第 X 批-X 班）与群规则文本
  • 当前版本 Q&A 文档链接（唯一一份）、课前须知草稿
  • 查询页字段：批次、上课时间、地点、企业微信群二维码，缺项默认“待定”

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发入选通知，附官微二维码与备注规则（“FDE+姓名”） 官微与 Q&A 维护人 名单确认后 1 个工作日内 短信、官微 入选通知 🔧飞书固化
2 通过好友申请，按分组拉入对应班级群，统一群名，群成员备注改为“姓名+手机尾号” 官微与 Q&A 维护人 申请后 1 个工作日内 企业微信 班级群及成员清单 🔧+🤖
3 建群当天预设群规则：防骚扰（发二维码/链接自动移出）、群公告、通知只由班主任/官微发 官微与 Q&A 维护人 建群当天 企业微信 群规则与公告 🔧飞书固化
4 导入名单与分组，配置批次-时间-地点-群码；上线前按检查清单核对标题、占位符、测试数据、课时展示 查询页开发；需求方验收 开班前 5 个工作日上线 生态资源池查询页 可用查询链接/二维码 🔧+🤖
5 群二维码到期前 1 天重导，图片按“批次-班级-到期日”命名，同步更新短信模板与查询页 官微与 Q&A 维护人；查询页开发 每 6 天一次 企业微信、查询页 有效二维码 🤖自动化
6 汇总官微、群、小红书新问题到待答池（问题、来源、类型、提问时间） 官微与 Q&A 维护人 当日收集，当日 18:00 前入池 飞书多维表格 待答问题清单 🔧+🤖
7 按类型分派：课程内容/考核 → 课程答疑人；其他 → 口径负责人；涉及政策、考核口径、收费的必须人工答复 官微与 Q&A 维护人 入池后 4 小时内 多维表格、飞书 @ 已分派问题 🔧+👤
8 已有 Q&A 的问题按标准口径直接回复；新问题由责任人给书面答复，群内问题由班主任/讲师集中解答 责任人、班主任 已有口径 2 小时内；新问题 1 个工作日内 官微、班级群 答复记录 👤人工判断
9 新答复写入唯一 Q&A 文档，同步机器人知识库 机器人接入人 答复当天 飞书 wiki、客服机器人 更新后的 Q&A 🔧+🤖
10 每批课前更新课前须知/FAQ，导出 PDF 发各班群，开课时由班主任宣读重点 官微与 Q&A 维护人；班主任 开课前 3 个工作日 飞书文档、班级群 课前须知 PDF 🔧飞书固化

5. 交付物与模板

  • 交付物：班级群及成员清单、查询页链接、唯一 Q&A 文档、课前须知 PDF、待答问题台账
  • 建议模板/表单：
    • 待答池（多维表格）：问题、来源渠道、提问时间、问题类型（课程/考核/分班/设备/费用/其他）、责任人、状态（待分派/待答/已答/已入库）、标准答复、答复时间
    • 查询页上线检查清单：页面标题、状态列用语、批次/班级占位符已替换、测试数据已清理、群码有效期、手机端显示
    • 群规则模板：群名规则、禁发内容、通知发布人、答疑时段

6. 异常与升级

  • 待答问题超过 1 个工作日无人回复 → 维护人在待答池标红并再次 @ → 升级口径负责人（当日）
  • 问题涉及政策、考核、收费、证书等口径未定 → 不先回复，统一回“已记录，1 个工作日内答复” → 升级口径负责人（4 小时内）
  • 群内出现负面情绪或疑似舆情 → 截图留存、暂停群内争论 → 升级口径负责人（1 小时内），必要时转品牌负责人
  • 查询页信息错误 → 立即下线错误字段或改为“待定” → 通知查询页开发（2 小时内修复）
  • 官微账号无法登录或负责人不在 → 由备岗接管 → 升级研究院生态负责人（当日）

7. 衡量指标

  • 进群率 = 已进群人数 / 入选人数，目标开课前 ≥ 95%
  • 首次响应时长 = 问题入池到首次回复的小时数，目标中位数 ≤ 4 小时
  • 新问题答复时长 = 入池到正式答复，目标 ≤ 1 个工作日
  • Q&A 覆盖率 = 用已有口径直接答复的问题数 / 问题总数，目标每批次环比提升
  • 查询页错误次数 = 每批次学员或内部发现的页面错误数，目标 0

8. 低效诊断

  • 现象：Q&A 被重复新开文档，口径分散在多处，需事后合并（Q&A 维护环节缺唯一入口）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：待答问题积压，需在群内多次 @ 才有人认领（分派环节无台账和时限）｜依据：「FDE培训班专班沟通群」2026-09、「FDE培训班专班沟通群」2026-10
  • 现象：企业微信二维码 7 天失效，需反复导出并同步更新短信和查询页；学员发码被自动移出（群码维护环节无到期提醒，群规则未提前告知）｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：查询页出现标题错误、“第 x 批第 x 班”占位未替换、测试数据、课时展示问题（上线前缺检查清单）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：官微登录设备在个人手中，远程协作困难（账号环节无备岗）｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 渠道差异：官微/班级群可直接答复；小红书等公开平台的提问只回复已有标准口径，新口径须口径负责人确认后再发
  • 调班：直接修改查询页名单分组，群码与时间地点随分组自动变更，同时通知学员换群
  • 批次差异：初级/中级/高级班的入班要求、课程内容不同，答复前先确认学员所在班级

10. 待确认问题

  • 官微与 Q&A 主责是否为生态运营岗？是否需要指定一名备岗共同持有官微？
  • 课程/考核答疑与其他问题的分派规则是否固定？时限“新问题 1 个工作日内答复”是否可行？
  • 待答池是否用飞书多维表格固化？客服机器人能否自动把未命中问题写入待答池并 @ 责任人？
  • 群码到期提醒是否可通过企业微信 API 或定时任务实现？
  • 查询页是否由研发长期维护，还是交给生态运营自行配置分组？
ECO-26培训/课程实操环境与算力容量准备待新建250

状态：待新建｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：高校课程、FDE 培训、大型活动需要学员现场或远程实操 LeapCore 时，需要提前完成并发容量评估、网络接入方案、设备采购、预测试和现场技术保障
  • 负责人：主责——培训技术保障负责人（当前：待指定）；协同——IT 运维/网管（当前：杨明学·推断待确认）、Leap 研发/技术负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、交付/IT（当前：李奎星·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）；方案与采购审批——创始人兼 CTO（当前：丁震宇·推断待确认）；预算审批——CEO（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交活动需求单（≥ 2 周前）→ ② 容量与接入方案评估 → ③ 方案拍板与采购 → ④ 部署与账号分发 → ⑤ 提前 1 周压测 → ⑥ 前一天踩点 → ⑦ 现场保障 → ⑧ 回收与复盘
  • 交付结果：经压测验证的实操环境（设备、网络、账号、模型额度）、学员接入文档、现场保障检查表与值守排班、活动后的回收记录与压测/故障结论
  • 状态依据：每次都是临时处理：2026-07 高校课程需求提出后一周内定方案，上架到开课前通宵调试；09 月 500 人会场需求提出当天就要定采购；10 月首批线下班现场出现网络出口打满、模型限流、杀毒软件与设备兼容问题约 15 次；没有需求提前量和检查表

1. 场景判定

  • 触发条件：任何培训、课程、展会、会场活动计划让 ≥ 10 名外部人员同时使用 LeapCore；或需要给外部开发者/学员开远程接入、批量账号
  • 典型说法：「方案得速定了，下周就要去上课了」「会场 500 个人同时用，今天得定清楚」「买 5 台还是 1 台拉满」「开场之前至少保证有一个人的电脑能用」
  • 判断问题：参与人数和并发人数是多少？是否需要公司提供算力、网络或账号？距离活动还有几天？
  • 不归本流程管：活动方案、场地、物料与人员分工 → 请走 ECO-27；学员通知与答疑 → 请走 ECO-25；客户正式项目部署交付 → 请走 X-DLV-19（客户现场/远程部署实施）；常规设备采购付款 → 请走 ADM-24（IT 设备采购申请），付款走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求提出人 提交活动需求单（人数、并发、时间、场地、用途） R FDE 课程负责人（当前：吴亚军·推断待确认）；课程负责人（当前：李凯·推断待确认）
技术保障负责人 统筹评估、部署、压测、现场保障与回收，对执行结果负责 R 培训技术保障负责人（当前：待指定）
网络与硬件 网络接入方案（WG/远程访问/内网）、限速、设备上架 R IT 运维/网管（当前：杨明学·推断待确认）
技术评估 并发容量评估、压测方案与结论 C Leap 研发/技术负责人（当前：王皓南·推断待确认）
部署与运维 设备部署、OOBE、模型额度扩容、日志 R 后端/运维（当前：宋祺睿·推断待确认）；LeapCore 后端/部署（当前：杨云峰·推断待确认）；运维/交付部署工程师（当前：游家豪·推断待确认）
账号与装机 学员账号注册、现场装机支持 R 交付/IT（当前：李奎星·推断待确认）
方案与采购审批 方案拍板、采购与合同 A 创始人兼 CTO（当前：丁震宇·推断待确认）
预算审批 超出既有预算的活动算力采购审批 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 活动需求单：活动日期、时段安排（如上午/下午轮次）、总人数、峰值并发人数、使用功能（客户端/Agent/模型调用量）、场地与网络条件、学员自带设备类型
  • 学员设备要求（目前仅支持标准 Windows 与 Mac M 系列芯片）、杀毒软件注意事项
  • 现有可用设备与模型额度清单
  • 学员名单（用于批量注册账号）
  • 预算范围与审批人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交活动需求单，明确峰值并发与席位人数的区别 需求提出人 活动前 ≥ 14 个自然日 飞书表单/多维表格 需求单 🔧飞书固化
2 评估容量与接入方式（线下搬机/远程接入/云端实例/机房托管），给出 2 个以内备选方案及成本 技术评估、网络与硬件 需求提交后 2 个工作日内 评估文档 容量评估与方案 👤人工判断
3 方案拍板，需采购的走预算审批与采购合同 方案与采购审批、预算审批 评估后 1 个工作日内 飞书审批 审批通过的方案与采购单 🔧飞书固化
4 设备到货后上架、接内网、测 OOBE；配置网络接入与限速；批量注册账号并分发配置文件和接入文档 部署与运维、账号与装机 活动前 ≥ 8 个自然日完成 管理后台、开发者平台 可用环境、账号清单、学员接入文档 🔧+👤
5 按峰值并发压测（含模型额度/限流、网络出口），记录结论；不达标调整方案 技术评估、部署与运维 活动前 7 个自然日 压测脚本 压测结论 🤖自动化
6 环境变更（漏洞修复、配置调整）先通知课程方，变更后回归测试 网络与硬件 变更前 1 个工作日通知 公告机器人 变更通知与回归记录 🔧+🤖
7 活动前一天踩点：测网络出口、电源、投屏，确认至少一台学员机全流程可用，准备备用机和热点 技术保障负责人 活动前 1 天 现场保障检查表 检查表签字 👤人工判断
8 现场值守：技术人员在场，限流/请求失败时扩容或提额，故障按分级在保障群响应 技术保障负责人、部署与运维 全程；P0 故障 15 分钟内响应 故障响应群 故障记录 👤人工判断
9 活动结束后保留日志，分析网络出口与负载；确认无流量→备份数据→删除账号与配置→释放机器 部署与运维、网络与硬件 活动结束后 5 个工作日内 日志、管理后台 回收记录、压测/故障结论留档 🔧+👤

5. 交付物与模板

  • 交付物：容量评估与方案文档、采购审批、账号清单、学员接入文档、压测结论、现场保障检查表、故障记录、回收记录
  • 建议模板/表单：
    • 活动需求单：活动名称、日期时段、总人数、峰值并发、轮次安排、使用功能、场地网络（带宽/出口/是否可接内网）、学员设备类型、需求人、预算上限
    • 现场保障检查表：网络出口压测、模型额度与限流阈值、设备兼容（Windows/Mac/杀毒软件）、备用电脑与热点、电源排插、值守人员与联系方式、应急切换方案
    • 回收清单：流量确认、数据备份位置、删除账号/配置项、释放设备

6. 异常与升级

  • 升级条件：方案需新增采购且超出已批预算时，由 CEO 审批预算（A（升级））；方案与在预算内的采购由创始人兼 CTO 拍板
  • 需求提出距活动不足 14 天 → 技术保障负责人评估可行性并给出降级方案（减少并发/改云端）→ 升级创始人兼 CTO（当日）
  • 压测不达标且采购来不及 → 改为轮次分组使用或演示为主 → 升级需求提出人与 CTO（压测当日）
  • 现场网络出口打满 → 启用热点/备用出口，提示学员切换网络或代理 → 升级网络与硬件（15 分钟内）
  • 模型 429 限流或请求失败 → 立即提额/扩容 → 升级部署与运维（15 分钟内）
  • 环境变更导致课程环境不可用 → 回滚配置 → 升级 CTO 并在 1 个工作日内复盘

7. 衡量指标

  • 需求提前量 = 需求单提交日到活动日的自然日数，目标 ≥ 14 天
  • 压测完成率 = 活动前 7 天完成压测的活动数 / 活动总数，目标 100%
  • 现场 P0 故障数 = 导致 ≥ 10 名学员无法实操超过 15 分钟的故障次数，目标 0
  • 故障恢复时长 = 故障发现到恢复的分钟数，目标 ≤ 30 分钟
  • 回收及时率 = 活动后 5 个工作日内完成回收的比例，目标 100%

8. 低效诊断

  • 现象：课程需求提出到上课不足一周，方案在群内多轮讨论，设备上架到开课前通宵调试（需求环节无提前量要求）｜依据：「FDE培训班专班沟通群」2026-07
  • 现象：网络维护责任不清，漏洞修复改配置未通知课程方、也未回归测试，导致课程环境中断（变更环节缺通知与回归）｜依据：「FDE培训班专班沟通群」2026-07
  • 现象：500 人会场需求提出当天就要定采购，并发与席位口径不一致反复确认（需求单缺并发字段）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：场务/课程负责人在活动前 3 周才确认（责任人环节无前置指定）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：首日会场网络出口打满、模型限额不足、杀毒软件与 Mac 输入框问题现场才发现（踩点和兼容测试环节缺检查表）｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 50 人以内课程：可采用远程接入（如 WG）+ 现有设备，评估与压测可合并在 1 个工作日完成
  • 数百人会场：需按峰值并发采购或租用设备，必须提前 7 天压测，现场配置双网络出口
  • FDE 长期内测机：按长期服务管理，纳入资产登记，定期巡检，不走活动回收
  • 接入方式：线下搬机+CPE / 远程接入 / 云端实例 / 机房托管，由技术评估按安全与成本选择

10. 待确认问题

  • 培训技术保障负责人由谁担任（IT 运维、研发运维还是交付）？是否需要每次活动单独指定？
  • 需求提前 14 天、压测提前 7 天的要求是否可行？紧急需求的审批路径是什么？
  • 并发容量评估是否需要形成标准换算口径（每台设备支持并发数）？
  • 远程接入方案的安全基线由谁审定？学员账号是否统一走开发者平台分发？
  • 活动算力采购的预算归属哪个部门？
ECO-27开班仪式与线下培训会务筹备待优化160

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗4 × 跨5 × 险4

  • 适用场景：线下培训（大课+小班实操）或开班仪式开课前，需要落实活动方案、场地、物料、人员分工，并邀请专家、学员代表与领导出席
  • 负责人：主责——研究院生态负责人（活动总协调）（当前：陈梦琪·推断待确认）；协同——行政助理/会务（当前：丁蕊·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、销售运营/销售支持（助教排班）（当前：韩诗琪·推断待确认）、生态运营（名单文档）（当前：谭涛·推断待确认）、FDE 成员（筛名单）（当前：佘天禾·推断待确认）、会务（当前：郭昊·推断待确认）、生态运营（官微）（当前：侯晨帆·推断待确认）、FDE 课程负责人（当前：吴亚军·推断待确认）、CEO（政府表述确认）（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 开课前 3 周立项与清单 → ② 活动方案与分工 → ③ 嘉宾与学员代表邀请 → ④ 物料设计制作 → ⑤ 场地踩点 → ⑥ 学员通知与助教排班 → ⑦ 前一天彩排检查 → ⑧ 当天执行
  • 交付结果：细化到个人的活动方案、嘉宾与学员代表出席名单、物料到位清单、踩点检查表、助教排班表、学员通知（场地指引、培训通知）
  • 状态依据：已有线下培训活动方案文档、场地指引、培训通知和助教排班表；但 2026-09～10 名单范围被纠正返工、日期混淆，物料在活动前两天才逐项确认，排插不足、场地下班时间等问题前一天才发现，约 12 次

1. 场景判定

  • 触发条件：确定线下培训/开班仪式日期；需要邀请政府、专家、企业代表出席；需要场地、物料、人员分工
  • 典型说法：「开班第一课仪式邀请的 15 个学员出席代表名单再定下」「当天整体活动方案细化至个人」「能确定物料吗？来一个物料表」
  • 判断问题：是否为面向学员或外部嘉宾的线下活动？是否涉及场地、物料、嘉宾邀请和现场人员安排？
  • 不归本流程管：实操设备、网络与算力准备 → 请走 ECO-26；学员进群、答疑与查询页 → 请走 ECO-25；结营复盘与转化 → 请走 ECO-28；物料采购付款 → 请走 FIN-01（对公采购申请与付款审批），个人垫付报销走 FIN-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动总协调 列待办清单、分派到人、审定嘉宾与学员代表名单，对活动结果负责 A/R 研究院生态负责人（当前：陈梦琪·推断待确认）
会务执行 活动方案、场地对接与指引、培训通知、紧急采购 R 行政助理/会务（当前：丁蕊·推断待确认）；会务（当前：郭昊·推断待确认）
设计 证书、指引牌、易拉宝、宣传册等物料设计 R UI/UX 设计师（当前：康紫馨·推断待确认）
名单整理 参会人员名单、重点学员代表筛选与邀请记录 R 生态运营（当前：谭涛·推断待确认）；FDE 成员（当前：佘天禾·推断待确认）
助教排班 销售助教排班与同步 R 销售运营/销售支持（当前：韩诗琪·推断待确认）
课程方 课程安排、课程物料需求 C FDE 课程负责人（当前：吴亚军·推断待确认）
学员通知 座位、签到、带电脑等通知发群 R 生态运营（当前：侯晨帆·推断待确认）
政府环节确认 对政府主管部门的活动表述与邀请口径 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 已确认的活动日期、时段、人数（大课/小班各多少人）
  • 场地候选及场地方管理规则（开放时间、电源、空调、网络、投屏）
  • 首批/本批学员名单（用于筛选学员代表）
  • 嘉宾初步名单与邀请口径（政府、专家、企业）
  • 物料预算范围、上一期活动方案与物料表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用活动筹备清单模板立项，列待办（电脑需求摸排、账号额度、题目资料、证书、政府环节、场地对接等）并分派到人 活动总协调 活动前 21 个自然日 飞书任务、多维表格 筹备清单 🔧飞书固化
2 出活动方案（流程、时间、分工细化到个人），放云文档共同补充 会务执行 活动前 14 个自然日初稿，7 天定稿 飞书云文档 活动方案 👤人工判断
3 确定嘉宾与学员代表范围（如只从本批班中选）；从名单中筛选企业负责人/知名企业员工及候补，总协调审定 名单整理、活动总协调 活动前 14 个自然日 多维表格 邀请名单 🔧+👤
4 对政府主管部门的活动表述与邀请口径提前确认 政府环节确认 发出邀请前 飞书消息 确认后的口径 👤人工判断
5 电话/消息邀请，回执实时更新状态（已邀请/确认/出席） 名单整理 活动前 10～5 个自然日 多维表格 出席名单 🔧飞书固化
6 物料清单定稿（证书、指引牌、易拉宝、宣传册、礼品等），按优先级设计制作；超预算项取消 设计、会务执行 活动前 7 个自然日定稿，3 天到货 物料表 物料到位清单 🔧飞书固化
7 场地踩点：网络、投屏、电源排插数量、空调、场地开放时间，缺项立即补采购 会务执行 活动前 5 个自然日 踩点检查表 踩点记录 👤人工判断
8 助教排班表定稿并同步到群；发学员通知（座位、签到时间、带电脑与电源） 助教排班、学员通知 活动前 3 个自然日 飞书表格、班级群 排班表、培训通知 🔧飞书固化
9 前一天彩排与清单逐项打勾，确认物料、人员、应急方案 活动总协调 活动前 1 天 筹备清单 完成的检查清单 👤人工判断

5. 交付物与模板

  • 交付物：活动方案、出席名单、物料到位清单、踩点记录、助教排班表、场地指引、培训通知
  • 建议模板/表单：
    • 活动筹备清单（多维表格）：事项、类别（场地/网络/电源/物料/人员/嘉宾/应急）、负责人、截止日、状态、备注
    • 嘉宾与学员代表表：姓名、单位、类别（政府/专家/企业代表/学员代表/候补）、邀请人、邀请状态、是否出席、座位
    • 踩点检查表：网络带宽、投屏、电源点位与排插数量、空调、场地开放/关闭时间、签到区、指引路线

6. 异常与升级

  • 嘉宾/学员代表确认数不足 → 启用候补名单 → 升级活动总协调（活动前 5 天）
  • 政府环节表述未确认 → 暂缓对外发出邀请 → 升级 CEO 确认（A（升级），1 个工作日内）；凡涉及政府主管部门的表述与邀请均须 CEO 确认，其余筹备事项由活动总协调拍板
  • 物料活动前 3 天未到货 → 改为电子版或简化版 → 升级活动总协调（当日）
  • 踩点发现电源、空调、场地时间限制 → 紧急采购或调整流程时间；无法解决的考虑换场地 → 升级活动总协调（当日）
  • 活动日期或名单范围有变更 → 总协调在群内发书面变更并更新所有文档 → 同步全体分工人员（1 小时内）

7. 衡量指标

  • 筹备清单按期完成率 = 截止日前完成事项数 / 总事项数，目标 ≥ 90%
  • 物料到位提前量 = 全部物料到位日距活动日的天数，目标 ≥ 3 天
  • 临时补救次数 = 活动前 2 天内新发现需紧急处理的问题数，目标 ≤ 2
  • 嘉宾/学员代表出席率 = 实际出席数 / 确认出席数，目标 ≥ 90%

8. 低效诊断

  • 现象：学员代表筛选范围不清，名单做完后被要求收窄到本批班重做（名单环节未先定范围）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：开班日期在群内被混用，信息出现偏差（变更环节缺统一书面发布）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：物料表在活动前几天才被催出，逐项确认到活动前两天（物料环节无截止日）｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：前一天才发现排插不足、场地方下班时间不能通融，紧急补采购（踩点环节晚、无检查表）｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 开班仪式：增加嘉宾与学员代表邀请、政府环节口径确认，需更早（≥ 21 天）启动
  • 普通线下实操课：可省略嘉宾邀请，重点是场地、电源、网络和助教排班
  • 成本控制：宣传册等核心物料优先，礼品袋等非必要物料可取消

10. 待确认问题

  • 活动总协调是否固定为研究院生态负责人？会务执行由行政还是生态运营承担？
  • 提前 21 天立项、7 天物料定稿的节奏是否可行？
  • 是否已有成文的活动筹备清单或场地准入标准（如场地开放时间、空调、电源要求）？
  • 政府主管部门的邀请与表述，除 CEO 外是否还需其他人确认？
  • 销售作为助教的排班，是否需要销售负责人审批？
ECO-28培训结营复盘与学员转化待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：每批线下培训结束后，复盘活动问题，回访学员并把有需求的学员转化为客户、渠道伙伴或孵化对象，交接给销售或长期运营
  • 负责人：主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——研究院生态负责人（收集与回访）（当前：陈梦琪·推断待确认）、AI 讲师/助教（长期运营）（当前：梅立·推断待确认）、AI 讲师/班主任（当前：张家瑞·推断待确认）、CEO（转化方向）（当前：邴龙志·推断待确认）、销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 结营当天发反馈问卷 → ② 3 个工作日内召开复盘会 → ③ 回访学员并分类 → ④ 商机线索推送销售 → ⑤ 孵化/伙伴对象转对应团队 → ⑥ 学员群转长期运营 → ⑦ 改进项落到下批 SOP
  • 交付结果：复盘纪要与改进项待办、学员分类回访台账、推送给销售的商机线索、长期运营交接记录
  • 状态依据：首批线下班结束后才临时召集复盘，回访与转化动作依赖个人记得推进，2026-10 群内约 4 次提及“事后补”；无固定表单、无销售交接口径

1. 场景判定

  • 触发条件：任一批次线下培训/课程结营；或培训中发现学员有采购、合作、孵化意向
  • 典型说法：「明天下午做一下复盘」「不同的学员想听到的内容是不一样的」「做成后续给客户培训的内容」「持续长期运营的工作交给你了」
  • 判断问题：培训是否已结束？学员中是否有企业高管、渠道服务商、创业者等潜在转化对象？
  • 不归本流程管：培训中的答疑与通知 → 请走 ECO-25；现场技术故障处理 → 请走 ECO-26；已进入报价/签约阶段的商机 → 请走 SAL-19（客户方案与报价单编制审核），签约走 SAL-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
复盘与转化负责人 召集复盘、汇总改进项、推动转化交接，对结果负责 A/R FDE 课程负责人（当前：吴亚军·推断待确认）
回访与收集 收集一线反馈、回访学员、维护分类台账 R 研究院生态负责人（当前：陈梦琪·推断待确认）
长期运营 学员群长期运营、推文入群、bot 抓取 R AI 讲师/助教（当前：梅立·推断待确认）
课程方 课程反馈、把内容沉淀为客户培训课程 C AI 讲师/班主任（当前：张家瑞·推断待确认）
转化方向 确定转化重点（研究院、孵化、客户培训） C CEO（当前：邴龙志·推断待确认）
销售对接 接收商机线索并跟进 R 销售对接人（当前：待指定）

3. 办之前请准备

  • 学员名单及报名信息（单位、行业、岗位）
  • 培训期间的问题记录（答疑待答池、现场故障记录、物料/会务问题）
  • 一线人员（实习生、助教、生态同事）的反馈
  • 学员反馈问卷链接
  • 销售对接人与孵化/研究院对接人名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 结营当天在各班群发反馈问卷（满意度、问题、后续需求、合作意向） 回访与收集 结营当天 飞书问卷 问卷结果 🔧飞书固化
2 召开复盘会：课程、会务、技术、答疑各环节一线反馈，产出改进项并指定负责人 复盘与转化负责人 结营后 3 个工作日内 飞书会议+妙记 AI 纪要 复盘纪要、改进项待办 🔧+🤖
3 回访学员，按四类人群分类（企业高管/渠道服务商/创业者/求职者），记录行业与需求 回访与收集 结营后 10 个工作日内 多维表格 学员分类台账 🔧+👤
4 有采购或试用意向的企业学员整理为商机线索推送销售 复盘与转化负责人 识别后 2 个工作日内 多维表格/CRM 商机线索 🔧+🤖
5 创业者、高管类引导至研究院/孵化方向，转对应对接人 复盘与转化负责人 识别后 5 个工作日内 飞书消息 转介记录 👤人工判断
6 学员群移交长期运营：定期推文入群，设 bot 抓取群内需求 长期运营 结营后 5 个工作日内交接 企业微信群、机器人 运营交接记录 🤖自动化
7 改进项更新到 ECO-25/26/27 等 SOP 与模板；课程内容沉淀为客户培训课件 改进项负责人、课程方 下批开课前 飞书文档 更新后的 SOP 与课件 👤人工判断

5. 交付物与模板

  • 交付物：复盘纪要与改进项清单、学员分类回访台账、商机线索清单、长期运营交接记录
  • 建议模板/表单：
    • 复盘纪要：批次、日期、参会人、做得好的、问题（按课程/会务/技术/答疑分）、改进项、负责人、截止日
    • 学员回访台账：姓名、单位、行业、人群分类、关注内容、合作意向（无/了解/试用/采购/合作）、下一步、转交对象、转交日期
    • 商机线索推送字段：单位、联系人岗位、行业、需求描述、意向等级、来源批次、推送日期、销售跟进人

6. 异常与升级

  • 结营后 3 个工作日内未召开复盘 → 生态市场条线负责人督办（第 4 个工作日）
  • 线索推送后 5 个工作日无销售跟进记录 → 提醒销售对接人 → 升级销售负责人
  • 学员群出现投诉或负面反馈 → 长期运营先回应并记录 → 升级研究院生态负责人（当日）
  • 改进项到下批开课前未完成 → 列入下批筹备清单首项 → 升级复盘与转化负责人

7. 衡量指标

  • 复盘及时率 = 结营后 3 个工作日内完成复盘的批次数 / 总批次数，目标 100%
  • 回访覆盖率 = 已回访学员数 / 结营学员数，目标 ≥ 80%
  • 线索推送数与转化率 = 推送销售的线索数；进入报价阶段的线索数 / 推送线索数，按批次跟踪
  • 改进项完成率 = 下批开课前完成的改进项 / 改进项总数，目标 ≥ 80%

8. 低效诊断

  • 现象：复盘在活动结束后临时召集，忙乱中补流程（复盘环节无固定时间点）｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：不同学员需求差异大，但回访和转化动作依赖个人记得推进（转化环节无台账和交接口径）｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：长期运营在结营当天才临时指定（运营交接环节无前置安排）｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 企业高管/渠道服务商：优先推送销售或渠道团队
  • 创业者：引导至研究院/孵化方向
  • 求职者：纳入人才库或社区运营，不推送销售
  • 制造、工程行业学员集中时：可整理为行业专场客户培训内容

10. 待确认问题

  • 复盘与转化的主责是否为 FDE 课程负责人？还是由研究院生态负责人统一负责？
  • 商机线索推送给谁？是否统一进入 CRM？销售对接人由谁指定？
  • 四类人群分类是否固定？是否有转化目标？
  • 学员群长期运营的职责边界（推文频率、bot 抓取内容）是否已有约定？
  • 结营后 3 个工作日内复盘的时限是否可行？
ECO-29生态合作伙伴台账、分级与年度评估退出待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：生态伙伴（芯片/信创厂商、开发者团队、高校社团、开源社区、KOL、OPC 商家）完成引入后，需要统一登记、分级给权益、定期评估与退出时启动
  • 负责人：主责——生态运营专员（当前：待指定）；协同——品牌（当前：待指定）、财务（当前：待指定）、销售对接人（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）
  • 核心流程：① 入库登记 → ② 分级标准 → ③ 季度分级评审 → ④ 权益兑现跟踪 → ⑤ 年度贡献评估 → ⑥ 升降级/续约/退出决定 → ⑦ 退出收尾 → ⑧ 台账更新
  • 交付结果：生态伙伴台账（含级别、权益、成本、贡献）、年度评估结论、退出收尾记录
  • 状态依据：已有 ECO-02（伙伴引入与内部对齐）、ECO-03（生态资源池）、SAL-30（渠道台账与分级评级）覆盖部分环节，本条补齐生态伙伴的统一台账、分级权益与年度评估退出（推断）

1. 场景判定

  • 触发条件：新伙伴完成引入（ECO-02）；季度末；伙伴申请更多资源；合作长期无产出
  • 典型说法：「这家给了多少额度了」「他们还算我们的合作伙伴吗」
  • 判断问题：对方是否已是登记在册的伙伴？是否在消耗公司资源？
  • 不归本流程管：伙伴引入与初次对齐 → 请走 ECO-02；资源入池与对接引荐 → 请走 ECO-03；渠道代理 → 请走 SAL-27/SAL-30；商城商家准入 → 请走 ECO-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
生态运营专员 台账维护、权益跟踪、评估材料 R 生态运营专员（当前：待指定）
研究院生态负责人 分级与退出决定 A 研究院生态负责人（当前：陈梦琪·部门报送人）
财务 权益成本核对 C 财务专员（当前：待指定）
品牌 退出后撤下品牌露出 I 品牌经理（当前：待指定）

3. 办之前请准备

  • 合作协议/合作确认、对接人、已给出的权益（额度、样机、算力、名额）
  • 伙伴贡献数据（线索、营收、内容、适配成果、活动参与）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 伙伴入库登记（主体、类型、对接人、协议、权益） 生态运营专员 引入完成后 3 个工作日内 多维表格 台账记录 🔧飞书固化
2 制定分级标准（战略/核心/一般）及对应权益 研究院生态负责人 首次一次性，年度修订 飞书文档 分级标准 👤人工判断
3 季度评审级别 研究院生态负责人 每季度末 台账 分级结果 👤人工判断
4 登记权益发放与成本（额度走 FIN-16） 生态运营专员 发放当天 台账 权益记录 🤖自动化
5 年度统计贡献与成本，形成评估 生态运营专员 每年 12 月 多维表格 评估表 🤖+👤
6 决定升级、维持、降级或退出 研究院生态负责人 评估后 10 个工作日内 飞书审批 决定记录 👤人工判断
7 退出：书面通知、回收权益与账号（X-SEC-06）、撤下品牌露出（BRD-20） 生态运营专员 决定后 10 个工作日内 邮件/后台 收尾记录 👤人工判断
8 更新台账与对外伙伴名单 生态运营专员 变更当天 台账 更新记录 🔧飞书固化

5. 交付物与模板

  • 交付物：伙伴台账、分级标准、年度评估表
  • 建议模板/表单：台账字段（伙伴名、类型、级别、对接人、协议期限、已发权益、权益成本、贡献指标、最近互动、状态）

6. 异常与升级

  • 伙伴超权益索取资源 → 生态运营专员 2 个工作日内报负责人决定
  • 伙伴出现违规或负面事件 → 立即暂停权益，报品牌与法务

7. 衡量指标

  • 台账覆盖率 = 登记伙伴 / 实际在合作伙伴，目标 100%
  • 伙伴投入产出比 = 年度贡献 / 年度权益成本

8. 低效诊断

  • 聊天中未见相关流程，存在伙伴资源无记录重复发放、无产出伙伴长期占用资源、退出后仍使用公司名义的风险（推断）

9. 分支变体

  • 开源社区伙伴以贡献与活跃度为主；硬件厂商以适配与联合销售为主；高校以人才与课程为主

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 分级是三级还是更多？各级权益上限由谁定？
  • 生态伙伴台账与 CRM、渠道系统是否需要打通？
ECO-30线下活动安全预案、报备与现场应急待新建推断180

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：举办生态大会、黑客松、培训开班、沙龙、校园活动等线下活动，尤其人数较多、在外部场馆或通宵进行时启动
  • 负责人：主责——活动安全负责人（当前：待指定）；协同——行政（当前：待指定）、法务（当前：待指定）、IT/网络（当前：待指定）、品牌（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）
  • 核心流程：① 规模评估与报备判断 → ② 场地安全条款 → ③ 编制安全预案 → ④ 购买保险 → ⑤ 现场安全分工 → ⑥ 活动前安全检查 → ⑦ 现场突发处置 → ⑧ 事件记录复盘
  • 交付结果：安全预案、报备/许可回执（如需）、保单、现场应急联络表、事件记录
  • 状态依据：已有 ECO-21（大会展区搭建彩排与现场执行）、MKT-03（参展/大会现场执行统筹）覆盖现场执行环节，本条补齐线下活动的安全预案、报备许可、保险与现场应急（推断）

1. 场景判定

  • 触发条件：活动立项（ECO-16、ECO-15、ECO-27）确定线下举办
  • 典型说法：「大会预计来多少人」「黑客松要通宵，安全谁管」
  • 判断问题：参加人数、场地是否自有、是否有夜间或饮食安排？
  • 不归本流程管：展区搭建与彩排执行 → 请走 ECO-21；外部展会/大会参展执行统筹 → 请走 MKT-03；现场网络保障 → 请走 X-SEC-32；舆情 → 请走 BRD-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动安全负责人 预案、报备、现场指挥 R 活动安全负责人（当前：待指定）
研究院生态负责人 批准预案 A 研究院生态负责人（当前：陈梦琪·部门报送人）
行政 保险、场地方对接、医疗物资 R 行政专员（当前：待指定）
法务 场地合同安全责任、报备法律判断 C 法务专员（当前：待指定）
品牌 现场突发对外口径 C 品牌经理（当前：待指定）
现场安全岗 现场巡查、突发即时处置 R 活动安全负责人指定人员（当前：待指定）

3. 办之前请准备

  • 预计人数、场地平面图与疏散通道、活动时段
  • 场地方消防与安全资质、场地合同
  • 供应商（搭建、餐饮、安保）资质

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 评估规模；达到大型群众性活动标准（1000 人以上）须向公安机关申请安全许可 活动安全负责人+法务 活动前至少 20 日提交申请 公安机关 报备/许可回执 👤人工判断
2 场地合同写明安全责任划分 法务 签约前 LEG-04 合同条款 👤人工判断
3 编制安全预案（人流、消防、医疗、餐饮、用电、天气、网络中断、不当言论） 活动安全负责人 活动前 10 个工作日 飞书文档 安全预案 🤖+👤（AI 出初稿）
4 购买活动意外险/公众责任险 行政 活动前 5 个工作日 保险机构 保单 👤人工判断
5 指定现场安全岗、急救联络人，发应急联络表 活动安全负责人 活动前 3 个工作日 飞书群 联络表 🔧飞书固化
6 活动前 1 日检查疏散通道、电源负载、搭建稳固性 活动安全负责人 活动前 1 日 检查清单 检查记录 🔧飞书固化
7 突发事件按预案处置，必要时报警/120，同步品牌口径 现场安全岗 即时 电话/群 处置记录 👤人工判断
8 记录事件与处理，纳入活动复盘 活动安全负责人 活动后 3 个工作日内 知识库 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：安全预案、报备回执、保单、联络表、检查记录
  • 建议模板/表单：安全检查清单（疏散通道、灭火器、电源负载、急救箱、饮用水、夜间值守、网络备用）

6. 异常与升级

  • 现场人数超出预计或拥挤 → 立即限流 → 报研究院生态负责人
  • 人员受伤或疾病 → 先救治并报 120 → 1 小时内报 CEO 与行政启动保险理赔

7. 衡量指标

  • 线下活动安全预案覆盖率，目标 100%
  • 安全事件次数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在大型活动未报备被叫停、人员受伤无保险、现场突发无人指挥的风险（推断）

9. 分支变体

  • 小型沙龙（几十人、自有场地）：简化为检查清单 + 联络表；通宵黑客松：增加夜间值守与餐饮安全；校园活动：遵守校方安全要求

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 人数阈值与报备时限请法务按当地规定确认
  • 是否有长期合作的保险机构？
ECO-31产学研/校企合作立项、协议与成果归属待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：与高校、科研院所共建联合实验室、实习实践基地、横向课题、共建课程，或研究院对外开展合作研发时启动
  • 负责人：主责——产学研合作专员（当前：待指定）；协同——法务专员（当前：待指定）、研发负责人（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——研究院生态负责人（当前：陈梦琪·部门报送人）
  • 核心流程：① 合作提议登记 → ② 评估立项 → ③ 协议起草（知识产权、署名、保密、经费、学生管理） → ④ 用印签署 → ⑤ 执行与经费拨付 → ⑥ 成果登记与权属申请 → ⑦ 年度评估续约/终止 → ⑧ 归档
  • 交付结果：立项审批、合作协议、成果登记表、年度评估与档案
  • 状态依据：已有 ECO-14（高校/校园生态合作）、LEG-05（合作开发协议拟定）覆盖部分环节，本条补齐产学研合作的立项评估、协议要点与成果归属登记（推断）

1. 场景判定

  • 触发条件：高校/院所提出共建、共同研发、学生实习基地、联合发表；我方提出合作课题
  • 典型说法：「学校想和我们挂个联合实验室」「这个课题的论文和专利算谁的」
  • 判断问题：是否有共同投入或共同产出（论文、专利、软件、数据）？有则走本流程
  • 不归本流程管：校园大使、算力赞助与校园推广 → 请走 ECO-14；与非高校机构的合作开发/保密协议 → 请走 LEG-05；对外讲课 → 请走 ECO-13；联合申报科技项目 → 请走 POL-04；实习生个人用工 → 请走 HR-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产学研合作专员 登记、评估材料、推进执行、归档 R 产学研合作专员（当前：待指定）
研究院生态负责人 立项初审 A 研究院生态负责人（当前：陈梦琪·部门报送人）
CEO 涉及经费或挂牌的最终审批 A（升级） CEO（当前：邴龙志·推断待确认）
财务 经费拨付与核算 C 财务专员（当前：待指定）
法务 协议审核、知识产权条款 C 法务专员（当前：待指定）
研发负责人 技术投入与成果评估 C 研发负责人（当前：待指定）

3. 办之前请准备

  • 合作方介绍、合作目标、双方投入（人员、经费、算力、数据）、预期产出
  • 公司知识产权与保密要求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记合作提议 产学研合作专员 收到后 2 个工作日内 多维表格 合作登记 🔧飞书固化
2 评估投入产出，研究院生态负责人初审，涉经费/挂牌报 CEO 产学研合作专员 5 个工作日内 飞书审批 立项结论 👤人工判断
3 起草协议：知识产权归属、署名、成果使用、保密、数据、经费、学生安全与保险、期限 法务 10 个工作日内 LEG-05 协议定稿 👤人工判断
4 用印签署（LEG-09） 产学研合作专员 定稿后 5 个工作日内 飞书审批 签署协议 🔧飞书固化
5 指定双方对接人与节点，经费按合同拨付 产学研合作专员+财务 按协议 台账 执行记录 🔧飞书固化
6 成果产生即登记，按协议申请专利/软著、确认论文署名 研发负责人 成果产生后 10 个工作日内 POL-10/POL-11 成果登记 👤人工判断
7 年度评估，决定续约或终止 研究院生态负责人 协议到期前 2 个月 评估表 评估结论 👤人工判断
8 协议、成果、往来文件归档 产学研合作专员 结束后 10 个工作日内 知识库 档案 🔧飞书固化

5. 交付物与模板

  • 交付物：立项审批、合作协议、成果登记表、年度评估
  • 建议模板/表单：合作台账（合作方、类型、期限、双方投入、对接人、成果、知识产权归属、状态）

6. 异常与升级

  • 合作方擅自发表含公司数据/代码的成果 → 法务 2 个工作日内介入
  • 学生在合作中发生安全事故 → 按协议责任处理，报 CEO 与人事
  • 升级条件：合作涉及公司经费投入、对外挂牌（联合实验室/基地）或核心代码与数据共享 → CEO 作为 A（升级）最终审批；其余合作由研究院生态负责人审批

7. 衡量指标

  • 合作协议签署率 = 有书面协议的合作 / 全部合作，目标 100%
  • 成果登记及时率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在成果归属不清引发纠纷、公司代码与数据被对方发表、学生安全责任不明的风险（推断）

9. 分支变体

  • 研究院与公司主体分别签约时，需明确签约主体与成果归属主体（LEG-02）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 目前已有哪些校企合作在执行、是否都有书面协议？
  • 产学研由研究院还是由各主体分别签约？

BRD 品牌

报送人：何思雨 · 生态市场条线 · 19 条 · 已有 1 / 待优化 7 / 待新建 11
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
BRD-01产品命名与更名决策新产品或新硬件需要对外名称，已有产品改名，或同一产品对外出现多个叫法、需要统一时启动。范围从候选名开始，到界面、包名、域名、Logo、应用提审、对外口径全部切换完成为止。主责——产品总监（当前：杨萌·推断待确认）；拍板——COO（当前：常元和·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户端/服务端研发（当前：岳阳、邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——品牌负责人（当前：何思雨·推断待确认）① 登记命名需求 → ② 限时征集候选名 → ③ 商标/域名/关键词冲突检索 → ④ 拍板定名 → ⑤ 公告命名决议与禁用旧名 → ⑥ 按改名检查表逐项切换 → ⑦ 发版前扫描旧名并验收 → ⑧ 更新品牌命名表经拍板的《产品命名决议》（中英文名、内部代号、禁用旧名、上架名、适用范围）、全部触点完成切换的改名检查表、更新后的品牌命名表。待新建240
BRD-02品牌视觉（Logo/形象/外观物料）设计评审与源文件取用需要新 Logo、IP 形象或吉祥物、Slogan、高管形象图、定制版机身 Logo/丝印时启动；对外使用公司或产品 Logo、产品外观图时也走本流程。主责——品牌负责人（当前：何思雨·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——UI/UX 设计师（当前：康紫馨·推断待确认）、产品总监（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、IT 运维/采购（当前：杨明学·推断待确认）、生态运营（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 先查品牌素材库 → ② 提视觉需求单 → ③ 设计出 2～3 个方案 → ④ 限时按清单评审 → ⑤ 拍板定稿 → ⑥ 导出全规格源文件入库 → ⑦ 对外使用确认 → ⑧ 版本变更公告定稿视觉稿；品牌素材库中规格齐全的源文件（.ai 非渐变版、SVG、透明 PNG、彩色/黑白、横版/竖版、常用比例）；对外使用确认记录。待新建108
BRD-04产品官网/落地页与下载页上线单个产品（如 LeapAll、LeapCore、行业版）对外发布或大版本更新，需要新建或改版落地页（landing page）、下载页、交付下载页时启动。主责——官网/落地页前端负责人（当前：季学森·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、服务端研发（当前：邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、运营负责人（当前：李凯·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）① 任务简报对齐 → ② 设计资源决策（内部/借调/外包） → ③ 收齐内容包 → ④ 框架稿评审 → ⑤ 开发与预览 → ⑥ 上线检查表验收 → ⑦ 部署并挂接下载 → ⑧ 发版时自动更新下载链接通过验收的线上落地页或下载页（含页脚联系方式、备案号、可用或置灰的下载入口），以及归档的内容包和简报。待新建144
BRD-05公司官网改版与内容更新（含 SEO）公司官网（company-site）改版，或内容变更（招聘页、页脚社媒入口、二维码、证书/资质、硬件规格等）时启动，范围从需求收集到上线，再到上线后的 SEO 和站长平台收录。主责——官网负责人（当前：陈梦琪·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——官网前端开发（当前：季学森·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、运营验收（当前：鲁周毅·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、人事负责人（当前：黄莹·推断待确认）、生态市场条线负责人（当前：许君·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 需求统一进需求池 → ② 官网负责人按批次收口定稿 → ③ 排期并分派设计/开发 → ④ 设计稿评审 → ⑤ 功能分支开发 → ⑥ 预览部署，验收人一次性验收 → ⑦ 上线检查表与生产部署 → ⑧ 上线后 SEO、收录与变更通报已上线并通过检查表的官网版本；需求池中对应需求关闭；SEO 与收录检查报告；官网变更记录。待优化240
BRD-06官网故障响应与迁移公司官网或产品官网打不开、证书失效、首屏加载异常慢、服务器下线，或需要计划迁移托管时启动；包括报障、认领、止血、修复/迁移、恢复通报和复盘。主责——官网运维责任人（当前：丁震宇·推断待确认）；协同——IT 运维/监控（当前：杨明学·推断待确认）、官网内容（当前：陈梦琪、葛家和·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 拨测告警或人员报障 → ② 15 分钟内认领 → ③ 定级初判 → ④ 止血（切 CNAME/回滚/切备用托管） → ⑤ 修复或迁移 → ⑥ 恢复验证 → ⑦ 恢复通报 → ⑧ 复盘并补监控恢复可用的官网；故障记录与通报；需要时出复盘结论和监控、证书提醒补强项。待新建96
BRD-07新媒体账号注册、认证与运营授权开设或接管公司在抖音、小红书、公众号、视频号等平台的账号时启动，包括确定挂靠主体、补齐资质、企业认证（蓝 V）、实名与管理员设置、授权运营人和台账登记。主责——新媒体运营（当前：李宣昊·推断待确认）；协同——新媒体运营（当前：鲁周毅·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、云平台管理员（当前：王皓南、宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——运营负责人（当前：待指定）① 开号申请（平台、用途、主体） → ② 主体与资质核对 → ③ 缺项补齐（ICP、软著、商标、授权书） → ④ 注册并优先做企业主体认证 → ⑤ 绑定公共手机号/邮箱与管理员 → ⑥ 授权运营人 → ⑦ 登记账号台账 → ⑧ 交接或注销完成企业认证、绑定公共联系方式、运营人已授权的公司账号，以及账号台账记录。待新建128
BRD-08新媒体日常内容生产与发布按日或按周为各产品在抖音、小红书、公众号、视频号产出短视频、图文、推文和信息流素材时启动，覆盖选题、制作、审核、定时发布、发布后分发和数据回收。主责——新媒体运营（当前：李宣昊·推断待确认）；协同——内容/视频运营（当前：宫经喜·推断待确认）、产品总监（当前：杨萌·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、销售总监（当前：吴琪·推断待确认）、业务专家（当前：王满·推断待确认）；兜底——运营负责人（当前：待指定）① 月度内容日历 → ② 选题入库并判定转载/改写/原创 → ③ 脚本/文案 → ④ 制作（拍摄、配音、剪辑、图文） → ⑤ 发布前审核 → ⑥ 多平台定时发布 → ⑦ 发布后分发与数据记录 → ⑧ 周复盘调整按日历发布的内容，以及每条内容的数据记录（播放/阅读、互动、留资），作为 BRD-10 周复盘的输入。待优化135
BRD-09事件型宣发稿与新闻稿公司活动、产品发布、培训开班/结课、适配认证通过、厂商联合发布、销售外出参会等“有日期的事件”需要发公众号推文、新闻稿或多平台内容时启动主责——品牌宣发专员（当前：汪家诺·推断待确认）；协同——事件发起方对接人（销售负责人，当前：李鹏为·推断待确认；研究院生态，当前：陈梦琪·推断待确认）、内容撰稿（当前：陈芷青、徐沛、吴琪·推断待确认）、研发技术核对人（当前：李子遥、丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 事件报备 → ② 判定是否发稿及渠道 → ③ 收集素材 → ④ AI 初稿与排版 → ⑤ 技术/事实核查 → ⑥ 审核定稿 → ⑦ 预览发布 → ⑧ 分发与归档已发布的推文/新闻稿（各平台链接）、事实核查记录、带版本号的终稿与素材包归档待优化240
BRD-10新媒体周数据复盘每周五对公司各新媒体平台账号（当前 3 个平台、6 个账号）做数据汇总、分析表现，并在周例会上确定下周选题与计划主责——新媒体运营（当前：李宣昊·推断待确认）；协同——产品/业务负责人（当前：杨萌·推断待确认）、管理层（当前：常元和·推断待确认）；兜底——运营负责人（当前：待指定）① 拉取各平台数据 → ② 填周数据表 → ③ 写分析 → ④ 周例会回顾 → ⑤ 定下周选题与计划 → ⑥ 知识库归档与月度汇总周数据表、《新媒体周情况总结和新规划》文档、月度汇总（知识库）已有24
BRD-11宣传视频制作与多版本审核大会播放视频、产品介绍视频、数字人视频、周年宣传片/TVC、领导访谈等视频需求，或研发用 AI 生成的演示视频/素材想对外使用时启动主责——运营部视频负责人（当前：鲁周毅·推断待确认）；协同——新媒体运营（当前：李宣昊·推断待确认）、导演/剪辑（当前：宫经喜·推断待确认）、需求方（当前：许君、杨萌·推断待确认）、研发画面保密审核（当前：丁震宇·推断待确认）、行政（当前：胡则瑾·推断待确认）；兜底——运营负责人（当前：待指定）；重大视频终审——CEO（当前：邴龙志·推断待确认）① 需求提报 → ② 评估排期并登记视频总清单 → ③ 脚本/分镜确认 → ④ 素材与授权收集 → ⑤ 制作初版 → ⑥ 版本评审 → ⑦ 合规自查与终审 → ⑧ 发布交付与归档定稿视频（各版本规格）、视频总清单记录、评审意见记录、肖像/声音授权书、源文件与提示词归档待优化300
BRD-12媒体采访与外部拍摄接待及对外口径国家级/地方电视台、报社记者等到访采访、拍摄、踩点或补拍，需要对内预告、选定受访人与演示内容、统一对外数据与说法、现场接待并回收素材时启动主责——媒体对接人（运营，当前：李凯·推断待确认）；协同——综合部/行政（当前：赵雪冰、胡则瑾·推断待确认）、技术统筹（当前：王皓南·推断待确认）、研发保密与技术口径（当前：丁震宇·推断待确认）、媒体口径审定（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）；重大来访由 CEO（当前：邴龙志·推断待确认）兜底① 邀约登记 → ② 评估分级并定筹备组 → ③ 对内预告 → ④ 口径与受访稿 → ⑤ 演示与场地准备 → ⑥ 现场接待 → ⑦ 素材回收与发布前审看 → ⑧ 复盘归档媒体来访登记记录、审定的受访稿与口径 Q&A、演示兜底视频、现场素材与报道链接、复盘记录待新建375
BRD-13宣传物料（海报/折页/手册/PPT）制作与校对销售、活动、新产品或行业版需要海报、三折页、产品手册、宣讲 PPT、产品能力图、FAQ 话术手册、商城上架说明、官网/公众号板块内容等对外物料时启动主责——品牌物料统筹（当前：鲁周毅·推断待确认）；协同——需求方（销售/市场，当前：李鹏为、吴琪、闫登辉·推断待确认）、产品内容与口径（当前：杨萌·推断待确认）、技术表述审核（当前：丁震宇·推断待确认）、文案撰写（当前：陈梦琪、吴琪·推断待确认）、校对（当前：宋祺睿·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 需求提报 → ② 排期分派 → ③ 内容收集 → ④ 统稿出文案 → ⑤ 技术/口径审核 → ⑥ 设计制作 → ⑦ 校对与终审 → ⑧ 版本归档发布定稿物料（源文件 + 导出文件）、物料版本表记录、统一存放的物料库待优化192
BRD-14对外口径、品牌用语与发布前合规自查任何对外推广、市场/销售回答客户问题、视频/文案/页面发布前，需要统一品牌名与话术，并检查敏感词、竞品/第三方标识、版本信息、环境链接及数据安全/模型来源等说法时适用主责——品牌口径维护人（当前：李凯·推断待确认）；协同——品牌与命名决策（当前：常元和·推断待确认）、技术口径（当前：丁震宇·推断待确认）、发布前审看（当前：宋祺睿、张东郅·推断待确认）、素材取舍决策（当前：杨萌·推断待确认）、销售话术使用方（当前：杨朋伟·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 建品牌与话术库 → ② 管理层与法务审定 → ③ 发布并培训 → ④ 发布前作者自查 → ⑤ AI 初筛 → ⑥ 人工复核与终审 → ⑦ 新问题入库 → ⑧ 定期更新《品牌与对外话术库》（含产品规范名、标准 Q&A、禁用词、正式链接入口、logo/模板）、发布前合规自查记录待新建300
BRD-15客户案例与白皮书收集及授权核查签单/交付验收后沉淀客户案例，或市场、销售需要案例做手册、PPT、视频、白皮书、推文、演示机内容，或 FDE 产出场景化案例/演示 Skill 需要转化为对外内容时启动主责——市场案例管理（当前：闫登辉·推断待确认）；协同——市场把关（当前：李鹏为·推断待确认）、FDE 案例产出（当前：李凯、黄振锋、佘天禾·推断待确认）、内容转化（当前：韩诗琪、许君·推断待确认）、优先级协调（当前：常元和·推断待确认）、技术支持（当前：丁震宇、杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 结项触发案例入库 → ② 填案例卡 → ③ 授权核查与分级 → ④ 入市场知识库 → ⑤ 内容转化需求提报 → ⑥ 撰写/录制 → ⑦ 发布前授权过滤与审核 → ⑧ 发布与季度盘点带授权等级的案例库（多维表格 + 市场知识库）、案例集/白皮书/推文/演示素材、授权确认记录待优化180
BRD-16竞品对比评测与素材产出产品实测出性能/成本优势，或需要与竞品（豆包、Kimi、ZCode 等）做同任务对比，并把结果转化为推文、演示和销售素材时启动；研发日常实测发现可用对比素材时也按本流程沉淀主责——竞品评测统筹（产品，当前：杨萌·推断待确认）；协同——评测执行（当前：李慧珍、陈芷青、陈震、黄飞鹏·推断待确认）、研发实测（当前：岳阳、王皓南·推断待确认）、技术判断（当前：丁震宇·推断待确认）、销售/对外使用（当前：闫登辉·推断待确认）、市场运营（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 选题与评测方案 → ② 审核范围 → ③ 同任务实测与取证 → ④ 整理对比文档 → ⑤ 评审（无优势则反馈产品）→ ⑥ 合规自查 → ⑦ 入竞品对比库 → ⑧ 转化素材与定期复测竞品评测文档（结论先行、图表、录屏截图）、竞品对比库记录、可对外使用的对比素材待新建72
BRD-17品牌素材库与对外资料库维护申报、论坛、市场、销售、官网/新媒体需要产品图、渲染图、演示视频、手册截图、合影、Logo、二维码、产品介绍（topic）、Q&A 等素材时，统一从素材库调取；新素材产生或旧素材过期时，按版本入库和更新主责——品牌素材库管理员（品牌岗）（当前：陈梦琪·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、总经办（当前：赵雪冰·推断待确认）、销售对外资料整理人（当前：闫登辉·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、官网仓库维护研发（当前：宋祺睿·推断待确认）、新媒体运营（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 素材分类与责任人认领 → ② 新素材入库（脱敏+打标签+标版本）→ ③ 需求方按目录自助调取 → ④ 库中缺失时提素材需求任务 → ⑤ 责任人补齐并回填入库 → ⑥ 每周五过期检查 → ⑦ 每月盘点缺失与下架一个唯一入口的品牌素材库与对外资料库（产品信息总表 + 分类素材目录），每条素材有责任人、版本日期、可否对外标记；素材需求全部有任务记录并回填入库待优化180
BRD-18品牌舆情监测与危机公关处置社交媒体、新闻媒体、开源社区、招聘平台或用户群出现针对公司、产品、高管的负面内容、事故曝光或不实信息时启动主责——品牌经理（当前：待指定）；协同——法务专员（当前：待指定）、客服/运营对接人（当前：待指定）、事件涉及部门负责人（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 日常监测 → ② 发现上报 → ③ 分级研判 → ④ 事实核查 → ⑤ 口径制定与审批 → ⑥ 回应处置 → ⑦ 持续跟踪 → ⑧ 复盘归档舆情事件登记单、经审批的对外回应口径、处置记录与复盘报告，口径沉淀进对外口径库待新建120
BRD-19宣传素材版权与肖像授权管理宣传视频、推文、海报、手册、PPT 使用外部图片、字体、音乐、视频片段、AI 生成形象，或出现员工、嘉宾、学员、外部人员的肖像与声音时启动主责——品牌设计/内容专员（当前：待指定）；协同——法务专员（当前：待指定）、行政（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 素材来源登记 → ② 版权核查 → ③ 肖像/声音授权签署 → ④ AI 生成内容审核 → ⑤ 发布前清单核对 → ⑥ 授权归档 → ⑦ 到期/撤回下架带来源与授权信息的素材台账、已签署的肖像/声音授权书、发布前核对记录待新建96
BRD-20合作方联合宣发与公司品牌授权使用渠道、生态伙伴、芯片/信创厂商、高校、政府平台要联合发稿、在其宣传中使用公司名称/Logo/产品名，或我方宣传中提及对方时启动主责——品牌经理（当前：待指定）；协同——业务对接人（当前：待指定）、法务专员（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）① 受理申请 → ② 品牌规范审核 → ③ 合作事实确认 → ④ 法务审核 → ⑤ 双方稿件互审 → ⑥ 发布监测 → ⑦ 授权登记 → ⑧ 合作终止撤下双方确认的联合稿件/物料、品牌使用授权记录（范围、期限）待新建96
BRD-01产品命名与更名决策待新建240

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：新产品或新硬件需要对外名称，已有产品改名，或同一产品对外出现多个叫法、需要统一时启动。范围从候选名开始，到界面、包名、域名、Logo、应用提审、对外口径全部切换完成为止。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；拍板——COO（当前：常元和·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户端/服务端研发（当前：岳阳、邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——品牌负责人（当前：何思雨·推断待确认）
  • 核心流程：① 登记命名需求 → ② 限时征集候选名 → ③ 商标/域名/关键词冲突检索 → ④ 拍板定名 → ⑤ 公告命名决议与禁用旧名 → ⑥ 按改名检查表逐项切换 → ⑦ 发版前扫描旧名并验收 → ⑧ 更新品牌命名表
  • 交付结果：经拍板的《产品命名决议》（中英文名、内部代号、禁用旧名、上架名、适用范围）、全部触点完成切换的改名检查表、更新后的品牌命名表。
  • 状态依据：没有成文的命名规则和审批人。2026-03～05 期间，LeapLite、LeapAll、LeapAgent、LeapCore、MercAll 多个名称并存；决策在群聊和群外确认之间来回，没有定稿。改名后窗口名、安装包、提审资料多次漏改返工（5 次以上），商标申请也没有和命名同步。

1. 场景判定

  • 触发条件：新软件产品、新硬件型号或新套餐需要对外名称；已决定给现有产品改名；同一产品对外有 2 个以上叫法；商标检索或驳回导致名称不能用。
  • 典型说法：「名字开头想统一，利于推广」「现在没有 Leaplite，以后是禁词」「对外只有 leapall」「中文能不能叫跃迁核心」「这个名字还是不行，急需群策群力」
  • 判断问题：这个名字会出现在客户能看到的地方吗？包括官网、安装包、商城、应用商店、合同和宣传物料。会就走本流程；只在代码或仓库内部使用就不走。
  • 不归本流程管：界面术语、功能模块名和报错文案的统一 → 请走 X-PRD-15；商标申请递交与驳回复审 → 请走 LEG-16；Logo 与视觉设计 → 请走 BRD-02；域名购买与备案 → 请走 X-SEC-20（域名购买与 ICP/算法备案）；客户白牌或定制名称 → 请走 X-DLV-11。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
命名统筹 登记需求、组织候选、推动检索、出决议、跟进改名检查表 R 产品总监（当前：杨萌·推断待确认）
最终拍板 从候选名中定名，确认中文名和是否申请商标 A COO（当前：常元和·推断待确认）
产品定位 给出产品矩阵与定位（C 端/B 端/底座） C CTO（当前：丁震宇·推断待确认）
商业策略建议 商城上架名与内部名是否分开等意见 C CEO（当前：邴龙志·推断待确认）
测试 改名后遗留检查（窗口名、安装包、图标、卸载残留）与回归 R 测试负责人（当前：张东郅·推断待确认）
研发落实 修改显示名、窗口名、安装包、下载页；评估包名和数据迁移 R 客户端/服务端研发（当前：岳阳、邓乾·推断待确认）
备案与提审 按新名准备域名备案、微信开放平台等提审资料 R IT 运维（当前：杨明学·推断待确认）
商标检索 近似商标检索，判断是否同步申请 C 法务负责人（当前：李瑶·推断待确认）
品牌一致性 检查宣传物料、官网和运营渠道的口径 C 运营负责人（当前：李凯·推断待确认）
商城上架 按决议更新商城上架名称与资料 I 生态运营（当前：陈梦琪·推断待确认）
全员 接收命名决议，停用旧名 I 全员

3. 办之前请准备

  • 一句话产品定位：面向谁，属于 C 端、B 端、底座还是硬件，在产品矩阵中的位置
  • 3～5 个候选名（中文和英文），每个写明命名理由
  • 现有名称清单：历史名、内部代号、仓库名、包名、已用域名
  • 计划生效日期，以及受影响的触点：官网、安装包、商城、应用商店、小程序、宣传物料、已盖章资料
  • 是否涉及已有用户数据继承的初步判断

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在「产品命名表」登记需求：产品、定位、生效日期、现有名称 命名统筹 触发后 1 个工作日内 飞书多维表格 命名需求记录 🔧飞书固化
2 用表单或文档评论限时征集候选名，不在大群发散讨论，到期收口 命名统筹 登记后 2 个工作日内收口 飞书表单/文档评论 候选名清单（不超过 5 个） 🔧飞书固化
3 对每个候选名做商标近似检索、域名可注册与可备案查询、搜索关键词冲突检查（竞品、开源项目名），并检查广告法用语 法务 + 命名统筹 收口后 2 个工作日内 商标查询系统、域名查询、搜索引擎 候选名风险评估表 🤖自动化 + 👤人工判断
4 提交拍板。决议必须写明中文名、英文名、内部代号、商城/应用商店上架名、是否同步申请商标 拍板人 收到评估表后 2 个工作日内 飞书审批 命名决议（审批通过） 🔧飞书固化 + 👤人工判断
5 在全员群和产研群公告：新名、禁用旧名、对外口径、生效日期 命名统筹 决议通过当天 飞书群公告 + 产品命名表 命名公告 🔧飞书固化
6 生成改名检查表并分派到人，覆盖显示名、窗口名、安装包名、下载页、域名、Logo、Slogan、提审资料、商城、宣传物料。原则：只改显示名，不改包名、数据目录、接口等功能性标识；要改须评审同意 命名统筹 公告后 1 个工作日内 飞书任务 改名检查表（每项有负责人和截止日） 🔧飞书固化
7 涉及包名或数据目录变更时，评估用户数据继承方案并写进发版说明 客户端研发 改名版本提测前 工单 数据迁移方案 👤人工判断
8 决议要求申请商标的，递交申请，后续转 LEG-16 跟进 法务 决议后 5 个工作日内递交 商标代理 申请受理号 👤人工判断
9 发版前全局扫描旧名：代码仓库、安装包、官网、帮助中心、提审资料。清零后验收 研发 + 测试 发版前 1 个工作日 扫描脚本 + 人工走查 旧名扫描报告 🤖自动化
10 关闭改名检查表，把命名表状态改为「已生效」 命名统筹 检查表全部完成后 1 个工作日内 飞书多维表格 命名表归档 🔧飞书固化

5. 交付物与模板

  • 交付物：命名决议；改名检查表；旧名扫描报告；品牌命名表（全公司唯一的命名信息源）。
  • 建议模板/表单：
    • 「产品命名表」字段：产品/型号、定位层级、中文名、英文名、内部代号、禁用旧名、商城上架名、包名、主域名、商标状态（未查/检索通过/已申请/已注册）、拍板人、生效日期、状态。
    • 「改名检查表」字段：触点、当前名称、目标名称、负责人、截止日、完成截图、验收人。

6. 异常与升级

  • 候选名商标近似风险高 → 退回步骤 2 重新征集；确需使用时由法务出书面意见，拍板人决定（2 个工作日内）
  • 拍板人 3 个工作日未决 → 命名统筹在周会提出 → 升级 CEO（1 个工作日内）
  • 提审或备案资料已按旧名盖章/提交 → 立即暂停，按新名重做 → IT 运维当天通知命名统筹，并在检查表登记延误
  • 发版后仍发现旧名 → 提 P2 缺陷，下个版本修复；涉及对外资料的 1 个工作日内修正
  • 已印刷或投放的物料与新名冲突 → 命名统筹评估继续使用、贴改还是重印 → 升级品牌负责人（2 个工作日内）

7. 衡量指标

  • 命名决策周期：从需求登记到决议通过的工作日数，目标 ≤ 7 个工作日
  • 改名遗漏数：发版后发现的旧名遗留处数，目标 0
  • 商标前置率：拍板前完成商标检索的命名数 / 全部命名数，目标 100%
  • 对外名称一致率：抽查官网、安装包、商城、物料中名称正确的触点数 / 抽查总数，目标 100%

8. 低效诊断

  • 现象：命名靠群里头脑风暴，最终确认在群外完成，结论没有成文，之后仍有人追问“确定不会改了吗”｜依据：「LeapAll」2026-04
  • 现象：拍板环节没有时限和代理人，提审资料迟迟等不到名称，已盖章资料只能按新名重做，微信应用提审因此延误｜依据：「Leap产研测」2026-05
  • 现象：改名没有触点检查表，窗口名、安装包、思考标签、图标仍是旧名，只能靠测试和体验者逐个发现｜依据：「Leap产研测」2026-05
  • 现象：改名时连带改了功能性标识，用户数据无法继承，迁移问题到改名之后才讨论｜依据：「跃迁AI总动员」2026-05
  • 现象：商标和撞名检索由研发自行搜索，商标申请没有和命名同步｜依据：「Leap产研测」2026-05、「LeapCore（archived）」2026-03
  • 现象：同一产品中文名有多个候选长期并存，硬件系列命名要等决策人有空才能推进｜依据：「LeapCore（archived）」2026-03、「LeapCore（archived）」2026-04

9. 分支变体

  • C 端 / B 端 / 底座：C 端用 LeapAll，B 端用 LeapCore，底层 LeapAgent 只在内部使用、不对外。命名决议要写明适用层级。
  • 只改商城或应用商店上架名：内部产品名不变，只执行步骤 3～6。
  • 硬件系列命名：同时定型号规则（系列名 + 档位），并同步 X-PRD-24 的 SKU 表。
  • 客户定制版名称/Logo：走 X-DLV-11，但不得使用未经检索的公司品牌词。
  • 公司英文名或集团品牌变更：按本流程执行，并联动 BRD-02 更新 Logo 源文件、处置已印物料。

10. 待确认问题

  • 命名统筹由产品总监承担，还是归品牌岗？品牌岗目前实际由谁执行？
  • 最终拍板人是 COO 还是 CEO？硬件命名和软件命名是否由同一人拍板？
  • 法务能否在命名阶段 2 个工作日内完成商标近似检索？
  • 「只改显示名，不改功能性标识」是否写成正式规则？
  • 是否先一次性盘点 LeapAll、LeapCore、LeapAgent、LeapPPT、MercAll 等现有名称，出一份现行命名表？
BRD-02品牌视觉（Logo/形象/外观物料）设计评审与源文件取用待新建108

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：需要新 Logo、IP 形象或吉祥物、Slogan、高管形象图、定制版机身 Logo/丝印时启动；对外使用公司或产品 Logo、产品外观图时也走本流程。
  • 负责人：主责——品牌负责人（当前：何思雨·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——UI/UX 设计师（当前：康紫馨·推断待确认）、产品总监（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、IT 运维/采购（当前：杨明学·推断待确认）、生态运营（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 先查品牌素材库 → ② 提视觉需求单 → ③ 设计出 2～3 个方案 → ④ 限时按清单评审 → ⑤ 拍板定稿 → ⑥ 导出全规格源文件入库 → ⑦ 对外使用确认 → ⑧ 版本变更公告
  • 交付结果：定稿视觉稿；品牌素材库中规格齐全的源文件（.ai 非渐变版、SVG、透明 PNG、彩色/黑白、横版/竖版、常用比例）；对外使用确认记录。
  • 状态依据：公司还没有 Brand VI 规范和统一素材库。2026-03～08 期间多次出现：找不到透明或黑白 Logo、临时现场改图、ODM 催要 .ai 文件、新旧 Logo 来回切换、评审没有明确拍板人、外观图能否对外不清楚。

1. 场景判定

  • 触发条件：新产品、社区或活动需要 Logo/IP/Slogan；高管形象图要对外使用；ODM 生产周年版、渠道版需要机身 Logo 或丝印；对外活动、视频、印刷需要 Logo 源文件；市场想把原型机或外观图用于宣传。
  • 典型说法：「大家提提意见」「谁能找到透明 logo」「logo 换回去先」「ODM 要求是 .ai 文件」「UI 认可了这个 logo 吗」「这个我能当产品宣传图吗」「所有物料里 logo 的英文要不要换」
  • 判断问题：这个视觉元素是否代表公司或产品身份，会不会被客户或公众看到？会就走本流程。只是产品界面里的功能图标或页面设计 → 不走。
  • 不归本流程管：产品界面 UI 设计与走查 → 请走 X-PRD-16；产品名称本身的确定 → 请走 BRD-01；海报、折页、手册等物料的内容制作 → 请走 BRD-13；照片、视频等素材的归档调取 → 请走 BRD-17；大会物料评审采购 → 请走 ECO-20；客户白牌 Logo 替换 → 请走 X-DLV-11。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌负责人 受理需求、组织评审、维护素材库与使用规范、确认对外使用 R 品牌负责人（当前：何思雨·推断待确认）
拍板人 Logo、IP、Slogan 定稿；公司级视觉变更 A CEO（当前：邴龙志·推断待确认）
设计执行 出方案、精修、导出全规格源文件 R UI/UX 设计师（当前：康紫馨·推断待确认）
产品视觉决策 产品 Logo 版本选择、产品宣传图是否体面可用 C 产品总监（当前：杨萌·推断待确认）
AI 初稿与官网视觉 用 AI 工具快速出初稿和官网视觉方向 C CTO（当前：丁震宇·推断待确认）
外观定型确认 确认硬件外观是否已定型，可否作宣传图 C 渠道负责人（当前：闫登辉·推断待确认）
ODM 对接 向 ODM 交付 Logo/丝印文件并跟进排期 R IT 运维/采购（当前：杨明学·推断待确认）
社区/周边需求 提出社区 IP、周边视觉需求并组织社区意见 C 生态运营（当前：陈梦琪·推断待确认）
取用方 按规范从素材库取用，不自行改图 I 研发、市场、会务等全员

3. 办之前请准备

  • 先在品牌素材库搜一遍，确认确实没有可用版本
  • 用途与场景：对内/对外，屏幕/印刷/机身丝印/视频
  • 规格要求：格式（.ai/SVG/PNG）、是否透明底、是否非渐变、颜色（彩色/黑白）、尺寸或比例
  • 使用截止日期和交付对象（如 ODM、会务、印刷厂）
  • 参考样例或调性描述；涉及人物形象图的，需本人知情同意

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在品牌素材库检索现有版本；有则直接按规范取用，跳到步骤 8 需求方 需要时立即 飞书云盘「品牌素材库」 取用记录 🔧飞书固化
2 库中没有的，提交视觉需求单 需求方 使用日前至少 5 个工作日 飞书表单 需求单 🔧飞书固化
3 品牌负责人受理并指派设计；简单需求可先用 AI 工具出初稿 品牌负责人 收单后 1 个工作日内 飞书任务 指派记录 🔧飞书固化
4 出 2～3 个方案，标注编号，附使用效果示意 设计执行 受理后 3 个工作日内 Figma / AI 生图 方案稿 🤖自动化 + 👤人工判断
5 限时评审：按清单（辨识度、比例、小尺寸可读、单色可用、与现有品牌一致、广告法用语）收集意见 品牌负责人组织 发出后 1 个工作日内截止 飞书投票/文档评论 评审汇总 🔧飞书固化
6 拍板定稿：公司级 Logo/IP/Slogan 由 CEO 定；产品 Logo 由产品总监定；人物形象图须本人确认 拍板人 评审截止后 1 个工作日内 飞书审批 定稿记录 👤人工判断
7 导出全规格源文件并入库，文件名带版本号和日期；旧版本标记「停用」并在群里公告 设计执行 + 品牌负责人 定稿后 2 个工作日内 飞书云盘 + 多维表格台账 入库源文件、版本台账 🔧飞书固化
8 对外使用确认：外观是否定型、商标是否已注册、是否需加注「示意图」、英文名是否为现行版本 需求方提交，品牌负责人确认 使用前 2 个工作日 飞书审批 对外使用确认 🔧+👤
9 交付外部（ODM、会务、印刷厂）时按对方格式提供，留存交付记录与对方确认 品牌负责人 / IT 运维/采购 收到需求后 1 个工作日内 云盘分享链接 交付记录 🔧飞书固化

5. 交付物与模板

  • 交付物：定稿稿件；品牌素材库（Logo 全规格、标准色值、字体、Slogan 现行版）；品牌视觉使用规范（简版 VI）；对外使用确认记录。
  • 建议模板/表单：
    • 「视觉需求单」字段：需求方、用途、对内/对外、格式、颜色、比例/尺寸、透明底、截止日、交付对象、参考样例。
    • 「素材版本台账」字段：素材名、版本号、定稿日期、拍板人、文件链接、状态（现行/停用）、商标状态、适用范围。

6. 异常与升级

  • 评审 1 个工作日内意见发散、无结论 → 品牌负责人按清单收敛为二选一 → 提交拍板人（1 个工作日内）
  • ODM 或印刷有硬截止，来不及新设计 → 沿用现行公司 Logo，先保生产 → 品牌负责人当天报拍板人备案
  • 商标未注册或英文名正在变更 → 物料暂不加 R 标，优先用中文名 → 品牌负责人通知会务、市场；已印物料的处置升级拍板人（2 个工作日内）
  • 外观未定型被要求对外 → 不得作为正式产品图，只能标「概念图」使用 → 渠道负责人与产品总监共同确认（1 个工作日内）
  • 发现有人自行改图或用了停用版本 → 品牌负责人要求替换为现行版本（1 个工作日内）

7. 衡量指标

  • 素材取用自助率：从素材库直接取到的次数 / 全部取用次数，目标 ≥ 90%
  • 新设计交付周期：从需求单到入库的工作日数，目标 ≤ 7 个工作日
  • 对外误用次数：使用停用版本或未确认外观图的次数，目标 0
  • 外部交付一次通过率：ODM/印刷一次接受的文件数 / 交付数，目标 ≥ 95%

8. 低效诊断

  • 现象：Slogan、Logo、官网视觉有多个版本，没有定稿机制；反馈分散在群消息里，要靠人记｜依据：「模态AI探索小分队」2026-04
  • 现象：形象和周边评审没有标准，容易聊散；最终谁拍板不清楚｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：要用透明底 Logo 时只能在群里问，翻群文件找压缩包；改用新版后又换回旧版｜依据：「Leap产研测」2026-06
  • 现象：公司没有 Brand VI，每次都要找人要源文件；英文名是否切换口径不一，已打印物料要返工处理｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：ODM 要非渐变 .ai 文件，现场才问找谁要；Logo 方案编号混淆，生产排期被催｜依据：「leapcore软硬件交付」2026-08
  • 现象：外观图能否对外、谁有权批准没有约定，要层层转问｜依据：「LeapCore（archived）」2026-04

9. 分支变体

  • 社区 IP / 吉祥物 / 周边：可用飞书投票收集社区意见，但最终仍由拍板人定稿。
  • 透明、黑白、横竖版：一次定稿时一并导出，不再按次临时制作。
  • 英文名变更或商标未下：按步骤 6 的异常处理执行，并同步 BRD-01。
  • ODM 周年版、渠道版丝印：渠道版可以不打公司 Logo（以商务约定为准），周年版须用 .ai 非渐变格式；标准版沿用现行 Logo。
  • 高管形象图：本人确认后才能入库和对外使用。
  • 产品外观图：仅定型后可作正式宣传图；需要「体面」的产品图时，可以棚拍或 AI 生成，但须产品总监确认与实物一致。

10. 待确认问题

  • 品牌岗实际负责人是谁？Logo 源文件此前由综合部负责人代为提供，是否移交品牌负责人？素材库和 VI 规范由谁维护？
  • 是否委托专业团队做正式 Brand VI？预算和时间怎么安排？
  • 产品 Logo 拍板人是产品总监还是 CEO？
  • 公司英文名的现行写法是什么，何时切换？
  • 素材库放飞书云盘还是知识库？对外取用是否需要审批？
BRD-04产品官网/落地页与下载页上线待新建144

状态：待新建｜证据：有证据（卡片 5 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨4 × 险3

  • 适用场景：单个产品（如 LeapAll、LeapCore、行业版）对外发布或大版本更新，需要新建或改版落地页（landing page）、下载页、交付下载页时启动。
  • 负责人：主责——官网/落地页前端负责人（当前：季学森·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、服务端研发（当前：邓乾·推断待确认）、IT 运维（当前：杨明学·推断待确认）、运营负责人（当前：李凯·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）
  • 核心流程：① 任务简报对齐 → ② 设计资源决策（内部/借调/外包） → ③ 收齐内容包 → ④ 框架稿评审 → ⑤ 开发与预览 → ⑥ 上线检查表验收 → ⑦ 部署并挂接下载 → ⑧ 发版时自动更新下载链接
  • 交付结果：通过验收的线上落地页或下载页（含页脚联系方式、备案号、可用或置灰的下载入口），以及归档的内容包和简报。
  • 状态依据：没有任务简报、内容清单和上线审核。2026-05 期间，素材、联系方式、备案号都要开发临时向各人催要（约 5 次）；外包和内部人选反复摇摆；目标没对齐就投入导致过度打磨；部署后发现空白页、文案和下载按钮问题返工（约 3 次）。

1. 场景判定

  • 触发条件：产品首次对外、公测或发布会前需要落地页；版本更新需要改下载页；交付客户需要下载页；营销活动需要产品介绍页。
  • 典型说法：「leapall 需要重新做一套 landing page」「leapall 目前还没有官网」「先给每个产品各搓一个就行」「联系方式给我一份」「下载按钮先弄成灰的，敬请期待」
  • 判断问题：页面是不是围绕单个产品、用于获客或下载？是就走本流程。公司整体官网 → 不走。
  • 不归本流程管：公司官网改版和内容更新 → 请走 BRD-05；官网打不开或证书失效 → 请走 BRD-06；帮助中心、使用手册、更新日志内容 → 请走 OPS-03；安装包打包、签名与上传 → 请走 RND-52；员工自做 Demo/静态页部署 → 请走 RND-62；域名与备案 → 请走 X-SEC-20。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
落地页负责人 按简报推进设计开发、收内容包、组织评审、对上线结果负责 R 官网/落地页前端负责人（当前：季学森·推断待确认）
需求方与验收人 出简报（目标、范围、风格、截止）并最终验收 A 产品总监（当前：杨萌·推断待确认）
内容边界把关 确定能写什么、不能写什么（如内部技术组件、模型列表、定价是否展示） C Leap 研发负责人（当前：王皓南·推断待确认）
部署 COS/CDN/Pages 部署、预览链接、生产发布 R 运维/发版（当前：宋祺睿·推断待确认）
下载页挂接 下载链接与版本号对接、自动更新 R 服务端研发（当前：邓乾·推断待确认）
备案号 提供页面所用域名的备案号 C IT 运维（当前：杨明学·推断待确认）
联系方式 提供客服/社群二维码、联系邮箱等页脚信息 C 运营负责人（当前：李凯·推断待确认）
预算与人选 外包预算和内部人选决策 C CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 任务简报：目标（品牌展示/获客/下载）、页面清单、风格基调（简约大气，不炫技）、截止日、验收人
  • 产品定位与核心卖点（3～5 条），面向用户的一句话介绍
  • 内容包：现行 Logo（从 BRD-02 素材库取）、产品截图/视频、Slogan、联系方式、备案号、下载链接或「敬请期待」状态、是否展示定价
  • 页面所用域名及备案状态
  • 参考站点 1～2 个

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 需求方出任务简报，与落地页负责人当面对齐目标和投入，对齐后才开工 需求方 立项后 1 个工作日内 飞书文档模板 任务简报 🔧飞书固化
2 设计资源决策：内部前端兼做 / 借调设计师（双方负责人同意）/ 外包（走预算审批）；同一任务不做多人「赛马」 需求方 + CTO 简报后 1 个工作日内 飞书审批 人选与预算决定 👤人工判断
3 按内容清单一次性收齐内容包，缺项由对应岗位在截止前补齐 落地页负责人 简报后 2 个工作日内收齐 飞书任务 + 云盘 内容包 🔧飞书固化
4 出框架稿（结构 + 主视觉 + 文案初稿，文案可 AI 生成后人工改） 落地页负责人 内容包齐后 2 个工作日内 模板站点 / AI 工具 框架稿预览 🤖自动化
5 框架稿评审：需求方、内容把关人限时给意见，一次汇总；文案从用户视角自审 需求方组织 1 个工作日内 预览链接 + 飞书文档评论 评审结论 👤人工判断
6 开发完成并发布预览 落地页负责人 + 运维/发版 评审后 3 个工作日内 Git 分支 + 预览环境 预览链接 🔧飞书固化
7 跑上线检查表：链接可点、移动端、首屏加载、文案、联系方式、备案号、下载入口（未发布则置灰「敬请期待」）、访问统计 落地页负责人自检，需求方验收 预览后 1 个工作日内 检查表 验收记录 🔧+👤
8 部署生产并在群里通告上线地址 运维/发版 验收通过当天 COS/CDN/Pages 线上页面 🔧飞书固化
9 下载页接入发版流水线，新版本发布后自动更新链接和版本号 服务端研发 首次上线后 5 个工作日内 CI 自动更新的下载页 🤖自动化

5. 交付物与模板

  • 交付物：任务简报；内容包；线上落地页/下载页；上线检查表记录。
  • 建议模板/表单：
    • 「落地页任务简报」字段：产品、目标、页面清单、风格基调、是否展示定价、截止日、验收人、预算（如外包）、执行人。
    • 「内容包清单」字段：Logo、产品图、视频、Slogan、卖点、联系方式、备案号、下载链接/状态、法律文案链接；每项写明提供岗位和截止日。
    • 「上线检查表」字段：链接与按钮、移动端、首屏加载时间、文案（用户视角、广告法）、联系方式、备案号、下载入口状态、统计埋点、验收人签字。

6. 异常与升级

  • 内容包缺项超过截止 1 个工作日 → 落地页负责人在任务里 @ 提供岗位 → 升级需求方（当天）
  • 设计资源不足 → 先用模板站点出简版上线，后续迭代 → 外包需求转预算审批，升级 CTO（2 个工作日内定）
  • 评审意见分歧大 → 需求方当场拍板，不再追加评审轮次（1 个工作日内）
  • 上线后发现空白页、错链或文案错误 → 回滚或 2 小时内修复 → 落地页负责人通告修复结果
  • 产品未正式发布 → 下载按钮置灰，不得挂测试包

7. 衡量指标

  • 落地页交付周期：简报对齐到上线的工作日数，目标 ≤ 10 个工作日
  • 上线后返工次数：上线 7 天内因错误修改的次数，目标 ≤ 1
  • 内容包一次收齐率：截止日前收齐的项数 / 清单项数，目标 100%
  • 下载页时效：新版本发布到下载页更新的时间，目标 ≤ 1 小时

8. 低效诊断

  • 现象：没有素材库和产品定位文档，开发要逐个索要图标、产品图、视频、Slogan、备案号，矢量 Logo 只能自己重画｜依据：「Leap产研测」2026-05
  • 现象：页脚联系方式由谁提供没有约定，开发多次催要；部署后才发现空白页、文案不对、下载按钮要置灰｜依据：「Leap产研测」2026-05
  • 现象：设计资源在外包、借调、内部兼做之间反复摇摆，一度多人同时做｜依据：「鼎慧产研决策部」2026-05
  • 现象：目标没对齐就投入，周末加班过度打磨，事后才约定「先对齐目标再投入」｜依据：「鼎慧产研决策部」2026-05
  • 现象：「官网谁做」需要在群里问，交付页访问范围临时决定｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 单产品落地页（LeapAll / LeapCore / 行业版）：完整执行。
  • 下载页：只做步骤 3、6～9，重点是版本号和链接自动更新。
  • 交付下载页：仅限内网或授权访问，不对公网开放，不进搜索引擎。
  • 帮助中心：页面框架按本流程上线，内容维护转 OPS-03。
  • 外包：需在简报中写清交付物、源码归属与验收标准，合同和付款走 FIN-01。

10. 待确认问题

  • 落地页的需求方和验收人是产品总监，还是各产品线负责人？
  • 产品联系方式（客服、社群二维码）统一由哪个运营岗提供并维护？
  • 下载页自动更新由服务端研发还是 CI 负责人落地？
  • 是否建立外包设计供应商库和预算标准？
  • 定价是否默认展示在落地页上？
BRD-05公司官网改版与内容更新（含 SEO）待优化240

状态：待优化｜证据：有证据（卡片 6 张 / 会话 3 个）｜优先级：频4 × 耗4 × 跨5 × 险3

  • 适用场景：公司官网（company-site）改版，或内容变更（招聘页、页脚社媒入口、二维码、证书/资质、硬件规格等）时启动，范围从需求收集到上线，再到上线后的 SEO 和站长平台收录。
  • 负责人：主责——官网负责人（当前：陈梦琪·推断待确认）；拍板——CEO（当前：邴龙志·推断待确认）；协同——官网前端开发（当前：季学森·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、运营验收（当前：鲁周毅·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、人事负责人（当前：黄莹·推断待确认）、生态市场条线负责人（当前：许君·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 需求统一进需求池 → ② 官网负责人按批次收口定稿 → ③ 排期并分派设计/开发 → ④ 设计稿评审 → ⑤ 功能分支开发 → ⑥ 预览部署，验收人一次性验收 → ⑦ 上线检查表与生产部署 → ⑧ 上线后 SEO、收录与变更通报
  • 交付结果：已上线并通过检查表的官网版本；需求池中对应需求关闭；SEO 与收录检查报告；官网变更记录。
  • 状态依据：2026-09 已形成「分支 → 预览 → 验收 → 主分支上线」的做法，并约定用文档收口需求；但需求入口仍分散，同一天内多次推翻，关键人不在时没人协调上线。此前（2026-03～08）出现过资质过期三个月无人处理、设计交接靠压缩包、无验收就上线的情况。

1. 场景判定

  • 触发条件：官网整体改版；新增或修改栏目、招聘岗位、页脚入口、二维码、资质证书、产品/硬件规格；资质过期或信息错误被发现；上线后需要做 SEO 和站长平台收录。
  • 典型说法：「官网证书快更新一下吧，天天有人问」「后面统一用文档收束修改需求，不支持一人一句」「谁来协调官网新版本上线」「jobs 网站要和官网样式同调」「有公司主体的百度站长账号吗」
  • 判断问题：改的是不是公司整体官网（含 jobs 站）？是就走本流程。单个产品的落地页或下载页 → 不走。
  • 不归本流程管：产品落地页和下载页 → 请走 BRD-04；官网打不开、证书失效、服务器下线 → 请走 BRD-06；岗位 JD 内容本身 → 请走 X-RCT-02；官网预约演示等入站线索 → 请走 SAL-02；用户协议、隐私政策文案 → 请走 LEG-18；发现官网被抄袭 → 请走 LEG-17；域名与备案 → 请走 X-SEC-20。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
官网负责人 管需求池、按批次定稿、排期、决定何时上线、对外显内容负责 R 官网负责人（当前：陈梦琪·推断待确认）
方向拍板 改版方向、重大内容取舍 A CEO（当前：邴龙志·推断待确认）
前端开发 开发、推分支、上线前自检、SEO 自查 R 官网前端开发（当前：季学森·推断待确认）
部署 预览环境、生产部署、域名与 CI R 运维/发版（当前：宋祺睿·推断待确认）
运营验收 在预览环境按需求逐项验收；社媒入口内容 R 运营验收（当前：鲁周毅·推断待确认）
设计 设计稿，以 Figma 链接交付 R UI/UX 设计师（当前：康紫馨·推断待确认）
招聘内容 提供岗位清单，审核招聘页 C 人事负责人（当前：黄莹·推断待确认）
市场内容 市场内容与 SEO 关键词 C 生态市场条线负责人（当前：许君·推断待确认）
技术建议 官网技术方案、SEO 建议、开发人选 C CTO（当前：丁震宇·推断待确认）
全员 发现问题提到需求池，不在群里零散提 I 全员

3. 办之前请准备

  • 需求写进需求池，写明页面、现状截图、目标内容、提出人、期望上线日
  • 内容素材：文案、图片原图、二维码、证书扫描件（含有效期）、岗位清单
  • 设计稿 Figma 链接（不发压缩包）
  • 涉及招聘、资质、法律文案的，先由对应岗位确认内容
  • 确认预览链接的访问方式（token 有效期）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有需求进「官网需求池」，群里零散提的由机器人或开发汇总回填 提出人 随时 飞书多维表格 + 群机器人 需求条目 🔧+🤖
2 每周固定一次收口：合并、去重、判定做/不做/延后，形成本批需求清单；本批定稿后新增需求进下一批 官网负责人 每周二前 多维表格视图 批次需求清单 🔧飞书固化
3 排期并分派设计、开发，写明截止日和验收人；不按「谁闲谁上」分配，门面改版由前端负责人主做 官网负责人 收口后 1 个工作日内 飞书任务 排期表 🔧飞书固化
4 设计稿评审（改版类必做，文字类免）：评论限时 1 个工作日，官网负责人定稿 设计 + 官网负责人 1 个工作日内 Figma + 飞书文档评论 定稿设计稿 👤人工判断
5 在功能分支开发；可用 AI 辅助生成，但开发人对还原度和可用性负责 前端开发 按排期，常规内容 2 个工作日内 Gitea 仓库 功能分支 🤖自动化
6 部署预览并机器人 @ 验收人；验收人对照需求清单一次性验收，问题回填需求池 运维/发版 + 运营验收 预览后 1 个工作日内 预览环境 + 机器人 验收结论 🔧+🤖
7 跑上线检查表：按钮链接、图片清晰度、移动端、首屏性能、占位数据清零、备案号、证书/资质有效期 前端开发 验收通过后 检查表 + PageSpeed 检查记录 🤖自动化
8 官网负责人确认上线时间，合并主分支部署生产，在群里通报变更内容 官网负责人决定，运维/发版执行 检查通过后 1 个工作日内 CI 生产版本 + 变更记录 🔧飞书固化
9 上线后 SEO：提交 sitemap，维护公司主体的百度/Google/Bing 站长账号，补关键词与描述，复查收录和排名，报告存云文档 前端开发 + 生态市场总监 上线后 5 个工作日内 站长平台 + AI 报告 SEO 检查报告 🤖自动化 + 👤人工判断
10 资质证书有效期写入台账，到期前 30 天提醒官网负责人更新 官网负责人 每次更新资质时 多维表格提醒 资质到期提醒 🔧飞书固化

5. 交付物与模板

  • 交付物：批次需求清单；定稿设计稿；生产版本；上线检查表；变更记录；SEO 检查报告。
  • 建议模板/表单：
    • 「官网需求池」字段：需求编号、页面、类型（改版/内容/招聘/资质/SEO）、提出人、内容说明、素材链接、批次、状态（待收口/开发中/待验收/已上线/不做）、验收人、上线日期。
    • 「官网上线检查表」字段：链接与按钮、图片清晰度、移动端、首屏加载、占位数据、备案号、资质有效期、法律文案、统计埋点、验收人签字。

6. 异常与升级

  • 本批已定稿后又要改 → 进下一批；确属紧急（错误信息、合规问题）由官网负责人当天插单
  • 官网负责人或部署人不在 → 按事先指定的 AB 角代理；没有代理人时升级生态市场条线负责人（当天）
  • 预览链接过期或打不开 → 运维/发版 2 小时内重发
  • 上线后发现外显错误 → 2 小时内回滚或修复，按 BRD-06 通报
  • 资质证书已过期 → 当天下线过期证书展示，5 个工作日内换新；跨月未处理升级 CEO
  • 站长账号缺失 → 生态市场总监 5 个工作日内用公司主体开通，账号入 X-SEC-12 台账

7. 衡量指标

  • 需求交付周期：需求入池到上线的工作日数，目标常规内容 ≤ 5 个工作日
  • 预览一次验收通过率：一次通过的批次数 / 总批次数，目标 ≥ 80%
  • 同批需求变更次数：定稿后追加或推翻的需求数，目标 ≤ 1
  • 资质过期在线天数：官网展示过期资质的天数，目标 0
  • 收录与排名：公司名和主要产品名在主流搜索引擎的首页命中，目标前 5 条

8. 低效诊断

  • 现象：多部门在群里一人一句提需求，同一天内多次推翻；预览中仍出现已要求删除的内容｜依据：「模态跃迁 官网研发」2026-09
  • 现象：关键人外出或请假时，没有人能协调新版本上线；预览链接过期，需要完整 token 才能访问｜依据：「模态跃迁 官网研发」2026-09
  • 现象：设计交给开发的是压缩包，开发用 AI 直接生成页面，没有验收环节，上线后才发现按钮无效、图片模糊；开发人选按「谁闲谁上」｜依据：「鼎慧产研决策部」2026-08
  • 现象：新版样式评审靠口头和 AI 锐评，页面带着占位数据和未完成交互对外｜依据：「跃迁AI总动员」2026-06
  • 现象：官网资质过期约三个月无人处理，新版官网放什么也没人定｜依据：「鼎慧产研决策部」2026-03
  • 现象：SEO 关键词由谁写、站长账号由谁开、301 由谁做都在群里临时推｜依据：「模态跃迁 官网研发」2026-09

9. 分支变体

  • 招聘页：人事负责人提供岗位清单（与飞书在招岗位清单同步），jobs 站与官网样式保持一致。
  • 页脚社媒入口、二维码：由运营提供并确认，二维码须指向长期有效地址。
  • 硬件规格、产品参数：由产品总监确认后再上线。
  • 资质/证书更新：联动 GEN-13 的荣誉资质库。
  • 改版方式：旧版 HTML 小改可用 AI 修改；整体改版必须先有设计稿再开发。
  • SEO：公司官网与产品官网（如 LeapAll）分别检查，产品官网的 SEO 由 BRD-04 的落地页负责人跟进。

10. 待确认问题

  • 官网负责人是否确定为生态组负责人？上线决定权是否明确归官网负责人？
  • 官网前端开发和部署是否设 AB 角？代理人是谁？
  • 需求池每周收口一次是否合适，还是按双周？
  • 公司主体的搜索引擎站长账号由谁开通和保管？
  • 资质证书台账由官网负责人维护，还是由综合部统一维护？
BRD-06官网故障响应与迁移待新建96

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：公司官网或产品官网打不开、证书失效、首屏加载异常慢、服务器下线，或需要计划迁移托管时启动；包括报障、认领、止血、修复/迁移、恢复通报和复盘。
  • 负责人：主责——官网运维责任人（当前：丁震宇·推断待确认）；协同——IT 运维/监控（当前：杨明学·推断待确认）、官网内容（当前：陈梦琪、葛家和·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 拨测告警或人员报障 → ② 15 分钟内认领 → ③ 定级初判 → ④ 止血（切 CNAME/回滚/切备用托管） → ⑤ 修复或迁移 → ⑥ 恢复验证 → ⑦ 恢复通报 → ⑧ 复盘并补监控
  • 交付结果：恢复可用的官网；故障记录与通报；需要时出复盘结论和监控、证书提醒补强项。
  • 状态依据：官网没有明确运维责任人和运维文档。2026-08 首屏加载慢、服务器下线、证书失效都是同事在群里发现后追问「谁做的官网」；迁移没有事先通告，监控对象事后才改。

1. 场景判定

  • 触发条件：拨测或监控告警；同事、客户、候选人反馈官网打不开、提示不安全、加载超过 10 秒；计划更换服务器或托管平台。
  • 典型说法：「谁做的官网，有人反馈进去要等一分钟才能进」「官网证书呢」「官网又打不开了」「原官网服务器下线了，准备换个」
  • 判断问题：问题是否出在官网的可访问性或安全性（打不开、证书、性能）？是就走本流程。只是内容不对、要加栏目 → 不走。
  • 不归本流程管：官网内容更新或改版 → 请走 BRD-05；产品生产环境、客户环境故障 → 请走 RND-75；机房、服务器硬件故障 → 请走 X-SEC-29；证书和域名的日常到期续期 → 请走 X-SEC-21；备案被核查或下架 → 请走 LEG-23。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
官网运维责任人 认领、止血、修复/迁移、通报、复盘 R/A 官网运维责任人（当前：丁震宇·推断待确认）
监控 维护拨测与告警，迁移后同步更新监控对象 R IT 运维（当前：杨明学·推断待确认）
内容负责人 确认恢复后的内容完整；判断是否需要临时公告 C 官网负责人（当前：陈梦琪·推断待确认）
前端 首屏性能问题定位与修复 C 官网前端（当前：葛家和·推断待确认）
报障人 报告现象、截图、时间、访问环境 I 任何发现者
受影响部门 招聘、销售接收通报，必要时改用备用材料 I 人事、销售

3. 办之前请准备

  • 故障现象截图、发生时间、访问地址、访问环境（网络、浏览器、是否微信内）
  • 官网托管位置、DNS 解析商、证书来源（应在官网运维文档中）
  • 备用方案：静态备份包、备用托管地址
  • 最近一次变更记录（谁、何时、改了什么）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 拨测机器人每 5 分钟检测可访问性、证书有效期、首屏时间，异常推送到告警群；人员发现的在告警群按模板报障 监控 / 报障人 发现即报 拨测机器人 + 飞书群 告警或报障消息 🤖自动化
2 认领并回复「已接手」 官网运维责任人 15 分钟内 飞书群 认领记录 👤人工判断
3 定级：P1 全站打不开或证书失效；P2 首屏严重变慢或部分页面失效；P3 个别资源异常 官网运维责任人 认领后 15 分钟内 — 故障级别 👤人工判断
4 止血：切换 CNAME 到备用托管、回滚到上一版本或重签证书 官网运维责任人 P1 2 小时内恢复，P2 1 个工作日内 DNS、云厂商托管、证书平台 临时恢复 🔧飞书固化
5 根治修复或迁移；计划迁移须提前 2 个工作日在群里通告时间窗口 官网运维责任人 P1 3 个工作日内根治 云平台 修复或迁移完成 👤人工判断
6 恢复验证：多地访问、HTTPS、首屏时间、微信内打开、下载和表单入口 官网运维责任人 + 前端 修复后 1 小时内 拨测、PageSpeed 验证记录 🤖自动化
7 通报：故障时段、影响、原因、处理结果；迁移的同时通告新地址或托管变更 官网运维责任人 恢复后 1 小时内 飞书群 恢复通报 🔧飞书固化
8 更新监控对象、证书提醒、运维文档；P1 出复盘 官网运维责任人 + 监控 恢复后 2 个工作日内 飞书文档 复盘与补强项 🔧飞书固化

5. 交付物与模板

  • 交付物：故障记录；恢复通报；复盘文档（P1）；更新后的官网运维文档。
  • 建议模板/表单：
    • 「官网报障模板」字段：现象、截图、地址、时间、访问环境、影响（客户/候选人/内部）。
    • 「官网运维文档」字段：域名与解析商、托管平台与账号归属（不写密码）、证书来源与到期日、备份位置、回滚方法、监控项、责任人与备岗。

6. 异常与升级

  • 15 分钟内无人认领 → 告警群自动 @ 兜底人 → 兜底人 30 分钟内指定处理人
  • P1 超过 2 小时未恢复 → 升级 CTO，并让人事、销售临时改用产品手册等备用材料（立即）
  • 证书失效原因是域名或备案问题 → 转 X-SEC-20 / LEG-23 并行处理（当天）
  • 迁移中发现内容缺失 → 先恢复可访问，内容缺口转 BRD-05 排期
  • 同一原因 30 天内重复发生 → 必须出复盘并在周会评审

7. 衡量指标

  • 可用率：月度官网可访问时间 / 总时间，目标 ≥ 99.5%
  • 认领时长：告警到认领，目标 ≤ 15 分钟
  • P1 恢复时长：告警到恢复，目标 ≤ 2 小时
  • 主动发现率：监控先于人员发现的故障数 / 故障总数，目标 ≥ 90%
  • 首屏时间：主流网络下首屏加载，目标 ≤ 3 秒

8. 低效诊断

  • 现象：官网首屏需要等约一分钟，同事在群里问「谁做的官网」才定位到负责人，上线前没做性能检查｜依据：「跃迁AI总动员」2026-08
  • 现象：原服务器下线、证书随之失效，事前没有通告，被同事发现后才说明｜依据：「跃迁AI总动员」2026-08
  • 现象：迁移后监控对象才改，期间没有主动告警｜依据：「跃迁AI总动员」2026-08
  • 现象：官网内容和可用性不足，面试等对外场景只能改发产品手册｜依据：「跃迁AI总动员」2026-08

9. 分支变体

  • 性能问题（首屏慢）：按 P2 处理，修复后把首屏指标写入 BRD-05 上线检查表。
  • 服务器下线、证书失效：按 P1 处理，优先切备用托管。
  • 计划迁移：属于变更，提前 2 个工作日通告，按步骤 5～8 执行，迁移完成同步更新监控。
  • 产品官网（如 LeapAll）：同一流程，责任人按 BRD-04 的落地页负责人与运维/发版协同。

10. 待确认问题

  • 官网运维责任人是否从 CTO 移交给运维/发版岗？备岗是谁？
  • 拨测与告警用现有监控工具还是新建机器人？告警发到哪个群？
  • P1 两小时恢复的目标是否可行？是否需要常备静态备份托管？
  • 官网托管平台与账号归属哪个主体？是否已登记到第三方平台账号台账？
BRD-07新媒体账号注册、认证与运营授权待新建128

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：开设或接管公司在抖音、小红书、公众号、视频号等平台的账号时启动，包括确定挂靠主体、补齐资质、企业认证（蓝 V）、实名与管理员设置、授权运营人和台账登记。
  • 负责人：主责——新媒体运营（当前：李宣昊·推断待确认）；协同——新媒体运营（当前：鲁周毅·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、云平台管理员（当前：王皓南、宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——运营负责人（当前：待指定）
  • 核心流程：① 开号申请（平台、用途、主体） → ② 主体与资质核对 → ③ 缺项补齐（ICP、软著、商标、授权书） → ④ 注册并优先做企业主体认证 → ⑤ 绑定公共手机号/邮箱与管理员 → ⑥ 授权运营人 → ⑦ 登记账号台账 → ⑧ 交接或注销
  • 交付结果：完成企业认证、绑定公共联系方式、运营人已授权的公司账号，以及账号台账记录。
  • 状态依据：每次开号都临时处理。2026-04 开号时才发现主体缺 ICP 和软著，只能借其他主体临时补；实名人改绑受平台期限限制，认证拖延十几天。2026-06 在全员群征集员工个人身份配合公司账号实名，有合规风险。

1. 场景判定

  • 触发条件：新产品或新业务线要开新媒体账号；已有账号需要企业认证、更换实名人或管理员；接管离职或调岗人员运营的账号；平台要求补 ICP、软著等资质。
  • 典型说法：「这个主体有 ICP 和软著吗」「要等实名满 180 天才能改绑」「想找一位抖音还没实名的同事配合」「直接给新账号认证公司主体」
  • 判断问题：账号是否代表公司或产品对外发声？是就走本流程。员工个人号转发公司内容 → 不走。
  • 不归本流程管：账号验证码代收、第三方平台账号台账 → 请走 X-SEC-12；运营平台登录验证的日常获取 → 请走 OPS-26；公司证照年检、认证续费提醒 → 请走 GEN-14；营业执照、授权委托书等材料 → 请走 LEG-10；软著申请 → 请走 POL-10；ICP 备案 → 请走 LEG-23；账号开通后的内容发布 → 请走 BRD-08。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账号负责人 发起申请、核对资质、注册认证、登记台账、授权运营人 R 新媒体运营（当前：李宣昊·推断待确认）
审批 批准开号、确认挂靠主体 A 运营负责人（当前：待指定）
运营人 按授权日常运营；交接时配合换绑 R 新媒体运营（当前：鲁周毅·推断待确认）
备案代办 补办 ICP 备案 R IT 运维（当前：杨明学·推断待确认）
主体与云账号 确认用哪个主体、哪个云账号备案 C CTO（当前：丁震宇·推断待确认）；云平台管理员（当前：王皓南、宋祺睿·推断待确认）
品牌口径 账号名称、头像、简介与品牌命名一致 C 产品总监（当前：杨萌·推断待确认）
法务 审核个人实名授权、主体材料与平台协议 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 平台、账号用途（垂直号/泛流量号/IP 号）、拟用账号名与头像（来自 BRD-02 素材库）
  • 挂靠主体，以及该主体的营业执照、ICP 备案、软著、商标等资质情况
  • 公共手机号、公共邮箱（不用个人手机号）
  • 管理员和运营人名单
  • 各平台企业认证要求与费用（以平台当期规则为准）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交开号申请：平台、用途、主体、账号名、运营人 账号负责人 计划启用日前 15 个工作日 飞书审批 开号申请 🔧飞书固化
2 审批开号，确认挂靠主体与产品主体一致 运营负责人 2 个工作日内 飞书审批 审批结论 👤人工判断
3 对照「主体资质清单」核对平台认证所需材料，列出缺项 账号负责人 审批后 1 个工作日内 多维表格「主体资质清单」 缺项清单 🔧飞书固化
4 缺项分派：ICP 转 LEG-23，软著转 POL-10，执照与授权书转 LEG-10 账号负责人 缺项确认当天 飞书任务 补办任务 🔧飞书固化
5 注册账号，优先用公司主体做企业认证（蓝 V）；平台必须个人实名的，填写授权书并经法务确认，不在群里征集个人身份 账号负责人 资质齐全后 3 个工作日内提交 各平台后台 认证申请 👤人工判断
6 绑定公共手机号、公共邮箱，设至少 2 名管理员 账号负责人 认证通过当天 平台后台 账号安全设置 🔧+👤
7 用平台子账号或运营者权限授权运营人，不共享主账号密码 账号负责人 认证通过后 1 个工作日内 平台后台 运营授权 🔧+👤
8 登记账号台账，记录改绑限制日期等关键节点并设提醒 账号负责人 授权完成当天 多维表格 台账记录 🔧+🤖
9 人员离职或调岗时，在离职交接中完成管理员、运营人换绑 账号负责人 离职前 5 个工作日内 平台后台 + 台账 换绑记录 🔧+👤

5. 交付物与模板

  • 交付物：已认证的公司账号；账号台账；个人实名授权书（如有）；主体资质清单。
  • 建议模板/表单：
    • 「新媒体账号台账」字段：平台、账号名、账号 ID、挂靠主体、认证状态与到期日、绑定公共手机号/邮箱（只记归属，不记号码明文）、管理员、运营人、实名人类型（企业/个人授权）、可改绑日期、用途、状态。
    • 「主体资质清单」字段：主体、营业执照、ICP 备案号、软著、商标、云账号、可用于哪些平台认证。

6. 异常与升级

  • 主体缺 ICP 或软著，短期补不上 → 评估改用资质齐全的主体开号，须产品与主体口径一致 → 运营负责人与 CTO 共同决定（2 个工作日内）
  • 平台规则限制改绑或认证（如实名满一定天数才能改绑） → 在台账登记可操作日期并设提醒，期间不换人 → 账号负责人跟进
  • 平台只接受个人实名 → 走书面授权并经法务确认 → 升级法务与人事负责人备案（3 个工作日内）
  • 认证被驳回 → 3 个工作日内补材料重提；连续驳回 2 次升级运营负责人
  • 账号被限流或封禁 → 账号负责人当天提交申诉，并通知品牌负责人评估对外影响

7. 衡量指标

  • 开号就绪周期：从申请到认证完成的工作日数，目标 ≤ 15 个工作日
  • 企业认证覆盖率：已企业认证的公司账号 / 公司账号总数，目标 100%
  • 台账完整率：台账登记的账号 / 实际运营的账号，目标 100%
  • 个人实名依赖数：靠员工个人实名的公司账号数，目标 0

8. 低效诊断

  • 现象：开号认证时才发现主体缺 ICP 和软著，临时借其他主体补备案，多人来回确认｜依据：「字字可研市场运营」2026-04
  • 现象：实名人改绑受平台期限限制，认证拖延十几天；账号挂在哪个主体事先没定｜依据：「字字可研市场运营」2026-04
  • 现象：公司账号实名靠在全员群征集员工个人身份配合，规则靠同事互相解释｜依据：「跃迁AI总动员」2026-06

9. 分支变体

  • 抖音、小红书、视频号：企业认证要求和费用各不相同，按平台当期规则办理，规则摘要记在台账备注。
  • 公众号：需绑定运营者微信与管理员，注意与小程序、开放平台主体一致。
  • 个人实名与企业认证：一律优先企业认证；个人实名仅作过渡，须有书面授权和换绑计划。
  • 主体选择：模态、鼎慧、苏州、跃竞等主体下的账号，挂靠主体须与对外产品主体一致，避免后续迁移。

10. 待确认问题

  • 新媒体账号的开号审批人是谁？运营负责人目前由谁担任？
  • 各主体现有 ICP、软著、商标资质情况是否已有清单？由谁维护？
  • 现有公司账号中，哪些仍挂在员工个人实名下？何时完成换绑？
  • 账号台账放运营部维护，还是并入 X-SEC-12 的第三方平台账号台账？
BRD-08新媒体日常内容生产与发布待优化135

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频5 × 耗3 × 跨3 × 险3

  • 适用场景：按日或按周为各产品在抖音、小红书、公众号、视频号产出短视频、图文、推文和信息流素材时启动，覆盖选题、制作、审核、定时发布、发布后分发和数据回收。
  • 负责人：主责——新媒体运营（当前：李宣昊·推断待确认）；协同——内容/视频运营（当前：宫经喜·推断待确认）、产品总监（当前：杨萌·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、销售总监（当前：吴琪·推断待确认）、业务专家（当前：王满·推断待确认）；兜底——运营负责人（当前：待指定）
  • 核心流程：① 月度内容日历 → ② 选题入库并判定转载/改写/原创 → ③ 脚本/文案 → ④ 制作（拍摄、配音、剪辑、图文） → ⑤ 发布前审核 → ⑥ 多平台定时发布 → ⑦ 发布后分发与数据记录 → ⑧ 周复盘调整
  • 交付结果：按日历发布的内容，以及每条内容的数据记录（播放/阅读、互动、留资），作为 BRD-10 周复盘的输入。
  • 状态依据：已有稳定的每日或每周产出节奏和负责人（2026-03～10 相关聊天记录约 200 条），但没有共享选题库、发布前审核节点和数据闭环。产出不足要上级指出才暴露；品牌称呼靠群里问；洗稿有版权风险；多平台靠手工逐个发布。

1. 场景判定

  • 触发条件：内容日历上的例行发布；行业或竞品出现值得跟进的文章或热点；产品有可展示的新功能；投放需要新素材。
  • 典型说法：「图文账号三平台定时发布」「看看我们是洗稿，还是转发，还是写一篇类似的？」「IP 视频 1 条，已完成各大平台发布」「上周视频运营这一块产出不足」「大家来涨点数据」
  • 判断问题：这是不是周期性、常规的品牌或产品内容？是就走本流程。针对某个活动、发布、认证的专题稿件 → 不走。
  • 不归本流程管：活动、发布会、认证通过等事件型稿件和新闻稿 → 请走 BRD-09；每周数据复盘 → 请走 BRD-10；对外口径和合规自查规则 → 请走 BRD-14；投放预算审批与效果复盘 → 请走 MKT-15；账号开通与认证 → 请走 BRD-07；被抄袭维权 → 请走 LEG-17；媒体采访 → 请走 BRD-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内容负责人 内容日历、选题判定、制作、发布、数据记录 R 新媒体运营（当前：李宣昊·推断待确认）
跃竞线内容运营 星域/会员端产品的脚本、视频、海报与发布 R 内容/视频运营（当前：宫经喜·推断待确认）
口径审核 发布前审核品牌称呼、产品表述 A 产品总监（当前：杨萌·推断待确认）
跃竞线审核 跃竞线内容质量审核与产出评价（品牌称呼与产品表述仍以口径审核为准） R 跃竞负责人（当前：徐莉·推断待确认）
选题提供 提供行业文章、客户关心的话题 C 销售总监（当前：吴琪·推断待确认）；业务专家（当前：王满·推断待确认）
内部同事 自愿转发，反馈内容意见 I 全员

3. 办之前请准备

  • 月度内容日历：平台、账号、频次、主题方向、发布时间窗口
  • 选题库：来源、类型（转载/改写/原创）、目标账号、优先级
  • 现行品牌命名表（BRD-01）与素材库（BRD-02、BRD-17）
  • 脚本、写作、配音、配图等 skill 和模板
  • 平台规则与敏感词清单（BRD-14）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定下月内容日历，经审核人确认 内容负责人 每月 25 日前 飞书多维表格「内容日历」 月度日历 🔧飞书固化
2 选题入库；外部文章先判定：可转载（取得授权或用平台转载功能）、改写（实质性改写并注明参考来源）或原创，不直接搬运 内容负责人 每周一前定本周选题 多维表格「选题库」 本周选题 🔧+👤
3 写脚本或文案；可用 AI 出初稿，产品名和术语按命名表 内容负责人 发布前 2 个工作日 AI 写作 skill 脚本/文案 🤖自动化
4 制作：拍摄或 AI 生成画面、配音（读音专项复核）、剪辑、字幕、封面；批量视频避免画面重复 内容负责人 发布前 1 个工作日 剪辑工具、配音工具、素材库 成片/图文 🤖+👤
5 发布前审核：品牌称呼、技术表述、广告法、版权来源、劳动关系等敏感话题；常规内容审核人 4 小时内回复，超时视为通过（敏感内容除外） 审核人 发布前 1 个工作日 飞书审批 审核结论 🔧飞书固化 + 👤人工判断
6 按日历定时发布到各平台，评论区按话术引导 内容负责人 按日历时段 平台后台 / 多平台分发工具 已发布内容 🤖自动化
7 机器人把发布链接推到内部群，同事自愿转发，不组织刷量 内容负责人 发布后 1 小时内 群机器人 分发记录 🤖自动化
8 发布后 48 小时回填数据：播放/阅读、完读、互动、留资、限流情况 内容负责人 发布后 2 个工作日内 内容日历表 单条数据 🤖自动化
9 汇总进 BRD-10 周复盘，调整下周选题和账号方向 内容负责人 每周五 多维表格仪表盘 复盘输入 🔧飞书固化

5. 交付物与模板

  • 交付物：月度内容日历；选题库；每条内容的成品和数据记录；周产出汇总。
  • 建议模板/表单：
    • 「内容日历」字段：日期、平台、账号、产品线、选题、类型（视频/图文/推文/信息流）、来源类型（原创/改写/转载授权）、脚本链接、成品链接、审核人、审核状态、发布时间、发布链接、播放/阅读、互动、留资、备注（限流/违规）。
    • 「选题库」字段：选题、来源链接、提供人、推荐理由、建议形式、优先级、状态。

6. 异常与升级

  • 当周产出低于日历计划 80% → 内容负责人周五说明原因并给补救计划 → 升级运营负责人
  • 审核人超时且内容敏感 → 不发布，顺延到审核通过 → 升级兜底人（1 个工作日内）
  • 账号被限流、违规或删帖 → 停发同类内容，当天复盘原因并更新敏感词清单 → 通知品牌负责人
  • 发现被抄袭 → 留存证据，用平台原创投诉 → 严重的转 LEG-17（3 个工作日内）
  • 品牌称呼拿不准 → 查命名表；命名表没有的，问口径审核人，结论回写命名表（当天）

7. 衡量指标

  • 日历完成率：按时发布条数 / 计划条数，目标 ≥ 90%
  • 审核覆盖率：经审核发布的条数 / 发布总条数，目标 100%
  • 违规/限流次数：月度被平台处罚或限流的次数，目标 0
  • 留资转化：月度留资数 / 月度总曝光，按产品线设基线后逐月提升
  • 数据回填率：48 小时内回填数据的条数 / 发布条数，目标 100%

8. 低效诊断

  • 现象：每天手工逐个平台发布；账号定位多次调整，垂直号和泛流量号后来不再区分｜依据：「字字可研市场运营」2026-03、2026-04
  • 现象：视频运营从脚本、拍摄、剪辑到发布都由同一岗位独自完成，没有排期和分工，产出不足要到周会被指出才暴露｜依据：「跃玩项目组」2026-06
  • 现象：批量视频画面重复，事后补做独立场景插画；配音读音多次复核｜依据：「跃玩项目组」2026-09
  • 现象：投放和留资数据没有统一汇总，留咨率下降后才改表单｜依据：「跃玩项目组」2026-08
  • 现象：选题靠在群里转发文章，转载还是改写临时决定；推文里的品牌称呼要在群里问｜依据：「字字可研项目群」2026-04、2026-06
  • 现象：发布后反复在群里号召同事刷数据；被抄袭后才想到原创投诉｜依据：「字字可研项目群」2026-06、2026-07

9. 分支变体

  • 鼎慧/字字可研线：垂直号与泛流量号，图文三平台定时发布，公众号推文单独发布；B 端工具在推文中统一称呼以命名表为准。
  • 跃竞线（星域/会员端）：IP 视频、产品介绍、行业口播、获客图文；与小红书推广公司或 KOC 合作的，报价与方案走 MKT-15。
  • 信息流广告素材：素材制作走本流程，开户、预算和投放复盘走 MKT-15。
  • 周年庆 TVC 等大型拍摄：按项目单列，演员招募提前 10 个工作日，并准备 AI 生成备选方案。
  • 公众号推文：转载须取得授权或使用平台转载功能；改写须实质性重写并注明参考来源。

10. 待确认问题

  • 本流程与 OPS-18（内容运营选题审核与发布排期）是否合并，以哪个为准？
  • 各产品线的口径审核人是谁？常规内容 4 小时超时视为通过是否可接受？
  • 是否采购多平台一键分发工具？费用归哪个部门？
  • 运营负责人目前由谁担任？跃竞线内容运营是否向其汇报？
  • 「洗稿」做法是否明确禁止，并改为授权转载或实质改写？
BRD-09事件型宣发稿与新闻稿待优化240

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：公司活动、产品发布、培训开班/结课、适配认证通过、厂商联合发布、销售外出参会等“有日期的事件”需要发公众号推文、新闻稿或多平台内容时启动
  • 负责人：主责——品牌宣发专员（当前：汪家诺·推断待确认）；协同——事件发起方对接人（销售负责人，当前：李鹏为·推断待确认；研究院生态，当前：陈梦琪·推断待确认）、内容撰稿（当前：陈芷青、徐沛、吴琪·推断待确认）、研发技术核对人（当前：李子遥、丁震宇·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 事件报备 → ② 判定是否发稿及渠道 → ③ 收集素材 → ④ AI 初稿与排版 → ⑤ 技术/事实核查 → ⑥ 审核定稿 → ⑦ 预览发布 → ⑧ 分发与归档
  • 交付结果：已发布的推文/新闻稿（各平台链接）、事实核查记录、带版本号的终稿与素材包归档
  • 状态依据：已有个人总结的发稿步骤（需求—AI 搭框架—配图排版—审核—手机自检—发出）和 AI 润色机器人，但未成文为团队规范；06～10 月聊天中多轮改稿、AI 味重返工、交接后资料找不到、活动信息事后才知、新闻稿素材临时催要约 15 次

1. 场景判定

  • 触发条件：已确定日期的公司事件（活动、发布、开班、认证通过、联合方案上线、销售参会/办会）需要以公司名义对外发声
  • 典型说法：「我们需要提前知道活动信息，才能提前准备新闻稿」「给我整段话吧，我要写到新闻稿里」「你帮我确认一下，这是联合宣发的推文」「整体 AI 味有点冲了」
  • 判断问题：有没有明确的事件和日期？是否以公司名义对外发布？我方在事件里有没有实质环节（演讲、签约、展台、成果）——仅到场参与的不发
  • 不归本流程管：新媒体日常数据复盘与选题 → 请走 BRD-10；视频制作 → 请走 BRD-11；媒体来访与采访 → 请走 BRD-12；海报/折页/手册 → 请走 BRD-13；口径规则与合规清单本身 → 请走 BRD-14；客户案例稿 → 请走 BRD-15；竞品对比稿 → 请走 BRD-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌宣发专员 接收报备、判定发稿、统稿排版、发布、归档 R 品牌宣发专员（当前：汪家诺·推断待确认）
生态市场条线负责人 判定争议事件是否发、终审对外口径 A 生态市场条线负责人（当前：许君·推断待确认）
事件发起方对接人 提前报备、提供“任务/成果/意义”素材 R 销售负责人（当前：李鹏为·推断待确认）；研究院生态（当前：陈梦琪·推断待确认）
内容撰稿 分渠道撰写推文/新闻稿/小红书/视频号文案 R 市场部/新媒体（当前：陈芷青、徐沛、吴琪·推断待确认）
研发技术核对人 核对产品名、版本、证书、架构与技术可行性表述 C 信创适配负责人（当前：李子遥·推断待确认）；CTO（当前：丁震宇·推断待确认）
合作厂商对接人 联合稿对稿、约定发布时间 C 外部合作方
法务 涉及合作方名称、承诺性表述时抽查 C 法务负责人（当前：李瑶·推断待确认）
全员 转发扩散 I —

3. 办之前请准备

  • 事件信息卡：事件名称、日期地点、我方环节、参与人、合作方、期望发布时间、渠道
  • 素材：现场照片/截图（无英文界面、无敏感屏幕）、讲师或负责人提供的“任务—成果—意义”三段文字（每段 1～2 句）
  • 技术事实：产品规范名称（以证书/官方命名为准）、版本号、证书名称、核心能力表述
  • 参考：同类事件已发布稿件 1～2 篇（从已发稿件库取）
  • 联合稿：对方初稿或对方审核人、双方发布时间约定

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在活动报备表登记事件信息卡 事件发起方对接人 活动前 3 个工作日（临时活动不晚于前 1 天 18:00） 飞书多维表格（日历视图） 报备记录 🔧飞书固化
2 判定是否发稿、渠道（公众号/小红书/视频号/新闻稿/社区公众号）与发布时间 品牌宣发专员；拿不准报条线负责人 报备后 1 个工作日内 多维表格 发稿决定与排期 👤人工判断
3 向发起方索取照片与三段文字素材 品牌宣发专员 活动结束当天 飞书任务 素材包 🔧飞书固化
4 AI 搭框架或借鉴同类稿出初稿；配图、排版；对外稿去掉地域前缀 内容撰稿 素材到齐后 1 个工作日内 AI 机器人、排版插件 初稿 v1 🤖自动化
5 事实核查：产品名、版本、证书、技术表述；无法担保的能力写“理论可行”并写明限定条件 研发技术核对人 收稿后 1 个工作日内 飞书文档评论 核查意见 👤人工判断
6 去 AI 味润色，按 BRD-14 合规自查清单过一遍 内容撰稿 0.5 个工作日内 AI 润色机器人 + 清单 初稿 v2 🤖+👤
7 审核定稿（修改不超过 2 轮）；联合稿同步厂商确认 条线负责人；联合稿含厂商 1 个工作日内 飞书审批 定稿 🔧飞书固化
8 手机端预览后发布，链接回填报备表 品牌宣发专员 事件结束后 2 个工作日内（新闻稿按约定时点） 公众号后台 发布链接 👤人工判断
9 同步到培训群/客户群/社区公众号，通知全员转发；终稿与素材归档到已发稿件库 品牌宣发专员 发布当天 飞书知识库 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：已发布推文/新闻稿链接、带版本号的终稿、事实核查记录、素材包
  • 建议模板/表单：
    • 活动报备表（多维表格）：事件名、类型、日期、地点、我方环节、对接人、合作方、是否发稿、渠道、计划发布时间、稿件链接、状态
    • 新闻稿素材卡：任务、成果、意义、可公开数据（需口径确认）、照片清单
    • 宣发稿事实核查清单：产品规范名、版本号、证书名称、架构/能力描述、合作方名称、承诺性表述、链接是否为正式环境
    • 发稿检查单：标题、封面、排版、地域前缀、错别字、手机端预览

6. 异常与升级

  • 活动当天或事后才得知 → 当天补登记，48 小时内补发；同一部门当月第 2 次漏报 → 报该部门负责人
  • 素材 1 个工作日未交 → 飞书任务催办一次，仍未交 → 升级条线负责人（当天）
  • 技术表述有争议或无法担保 → 加限定或删除 → 由 CTO 拍板（1 个工作日内）
  • 联合稿与厂商口径冲突 → 条线负责人与厂商协调，发布延期不超过 2 个工作日
  • 发布后发现事实错误 → 可修改的 2 小时内修改；不可修改的删除重发，并报条线负责人
  • 宣发岗位交接 → 交接清单须含在途稿件、素材位置、平台账号移交，交接当天完成

7. 衡量指标

  • 事件提前报备率 = 提前 ≥3 个工作日登记的事件数 / 发稿事件数，目标 ≥ 80%
  • 发稿时效 = 事件结束到发布的工作日数，目标 ≤ 2
  • 定稿修改轮次：目标 ≤ 2 轮
  • 发布后勘误次数：目标 0
  • 技术核查覆盖率 = 涉及产品/技术且经核查的稿件 / 涉及产品/技术的稿件，目标 100%

8. 低效诊断

  • 现象：发稿步骤只存在于个人经验总结，审核环节多轮修改，未形成团队规范｜依据：「【模态】市场销售」2026-06
  • 现象：多平台内容矩阵依赖单一岗位维护，缺少统一排期｜依据：「【模态】市场销售」2026-06、2026-07
  • 现象：销售活动在群里零散报备，宣发事后才知道，无日程汇总｜依据：「公司内FDE」2026-08
  • 现象：新闻稿素材在活动后临时索要，推文发布前预览确认多轮｜依据：「FDE培训班专班沟通群」2026-09、2026-10
  • 现象：联合宣发初稿 AI 味重、产品名称未按证书表述，技术可行性“理论 vs 工程”口径不一，需研发多轮修改｜依据：「信创LeapCore客户端适配」2026-09、2026-10
  • 现象：宣发岗位交接后历史稿件与资料位置不清｜依据：「信创LeapCore客户端适配」2026-10

9. 分支变体

  • 厂商联合宣发（海光、统信等）：增加厂商对稿环节；技术表述以适配证书和联合方案为准；双方约定同时发布
  • 认证通过类：产品名称、版本以证书原文为准；证书图片需确认可公开
  • 培训/研究院活动：在研究院与社区两个公众号发布，可附问题收集问卷与 Q&A 专栏；推文同步培训群
  • 销售外出活动：有我方环节才发，仅参会不发；拜访信息同步 CRM 不归本流程
  • 行业内容矩阵（如工程咨询方向的公众号/小红书/视频号）：由对应内容岗按本流程执行，审核口径统一

10. 待确认问题

  • 主责应为品牌岗（部门报送人）还是当前承接推文宣发的岗位？行业内容矩阵是否并入品牌统一管理？
  • 活动提前 3 个工作日报备是否可行？报备入口用多维表格还是飞书日历？
  • 终审是否统一由生态市场条线负责人，还是按事件级别分级（重大事件报 CEO）？
  • 厂商联合稿是否需要法务过目？
  • 已发稿件库由谁维护、放在哪个知识库空间？
BRD-10新媒体周数据复盘已有24

状态：已有｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨2 × 险2

  • 适用场景：每周五对公司各新媒体平台账号（当前 3 个平台、6 个账号）做数据汇总、分析表现，并在周例会上确定下周选题与计划
  • 负责人：主责——新媒体运营（当前：李宣昊·推断待确认）；协同——产品/业务负责人（当前：杨萌·推断待确认）、管理层（当前：常元和·推断待确认）；兜底——运营负责人（当前：待指定）
  • 核心流程：① 拉取各平台数据 → ② 填周数据表 → ③ 写分析 → ④ 周例会回顾 → ⑤ 定下周选题与计划 → ⑥ 知识库归档与月度汇总
  • 交付结果：周数据表、《新媒体周情况总结和新规划》文档、月度汇总（知识库）
  • 状态依据：03～04 月每周五稳定产出数据与分析，并在周例会回顾、制定下周计划，已有知识库文档；主要问题是多后台手工汇总

1. 场景判定

  • 触发条件：每周五固定执行；新账号开通或平台调整后，从下一个周五起纳入
  • 典型说法：「新媒体周情况总结和新规划」「本周新媒体数据已更新」
  • 判断问题：是不是公司自有新媒体账号的常规数据？是不是周期性复盘而非单次活动效果评估？
  • 不归本流程管：单个事件稿件撰写与发布 → 请走 BRD-09；视频制作 → 请走 BRD-11；活动/投放的专项效果复盘 → 由活动负责人在活动结项时单独做

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
新媒体运营 拉数据、填表、写分析、提下周计划、归档 R 新媒体运营（当前：李宣昊·推断待确认）
运营负责人 主持周例会、确认下周计划 A 运营负责人（当前：待指定）
产品/业务负责人 提供产品节点与选题输入 C 产品总监（当前：杨萌·推断待确认）
管理层 关注趋势与重点选题方向 I COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 各平台后台账号权限（公众号、视频号、小红书等），账号归公司管理
  • 统一的周数据表（固定字段与口径）
  • 本周已发内容清单（标题、平台、发布时间、类型）
  • 下周已知的产品节点、活动、发布计划（来自 BRD-09 报备表）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 导出各平台各账号本周数据（阅读/播放、互动、涨粉、转化） 新媒体运营 每周五 10:00 前 各平台后台 / 导出脚本 原始数据 🤖自动化
2 填入周数据表，自动计算环比 新媒体运营 每周五 11:00 前 飞书多维表格 周数据表 🔧飞书固化
3 写分析：涨跌原因、表现最好/最差的 3 条内容及原因 新媒体运营 每周五 12:00 前 飞书文档（AI 辅助出初稿） 周分析 🤖+👤
4 周例会回顾数据与分析 运营负责人主持 每周例会（15 分钟内） 飞书会议 会议结论 👤人工判断
5 确定下周选题、平台分工与发布时间 运营负责人 + 新媒体运营 例会当场 多维表格选题排期 下周计划 👤人工判断
6 文档归档到知识库；每月首个周五出月度汇总 新媒体运营 当天下班前；月度汇总每月首个周五 飞书知识库 归档 + 月报 🔧飞书固化

5. 交付物与模板

  • 交付物：周数据表、周分析与下周规划文档、月度汇总
  • 建议模板/表单：
    • 周数据表字段：周次、平台、账号、发文数、阅读/播放量、点赞、评论、转发/收藏、新增关注、累计关注、环比、备注
    • 周分析模板：本周概况（3 句话）、亮点内容、问题内容、原因分析、下周选题（标题/平台/负责人/时间）
    • 月度汇总：月度趋势图、TOP 内容、账号定位调整建议

6. 异常与升级

  • 周五无法按时出数（休假、平台故障）→ 指定备岗代出，最晚下周一 12:00 补齐 → 报运营负责人
  • 单账号数据连续 2 周下滑超过 30% → 在例会上专项讨论并给出调整动作
  • 平台账号权限丢失或异常 → 当天报运营负责人，按公司账号管理流程找回
  • 数据口径争议（如不同平台“阅读”定义不同）→ 由运营负责人定口径并写入模板说明

7. 衡量指标

  • 周报准时率 = 周五 12:00 前完成的周数 / 总周数，目标 ≥ 95%
  • 手工汇总耗时：目标 ≤ 30 分钟/周（自动导出后）
  • 下周计划执行率 = 按计划发布的内容数 / 计划内容数，目标 ≥ 80%
  • 账号增长：各账号月度净增关注数，目标由运营负责人按季度设定

8. 低效诊断

  • 现象：多平台多账号数据靠人工逐个后台复制汇总，每周重复｜依据：「字字可研市场运营」2026-03、2026-04
  • 现象：分析文档与数据表分散在多篇知识库文档，跨周对比需要手动翻找｜依据：「字字可研市场运营」2026-03

9. 分支变体

  • 不同产品线/主体账号（如字字可研与集团账号）：使用同一模板，按账号分视图；选题会可分开或合并，由运营负责人定

10. 待确认问题

  • 复盘覆盖的账号范围是否仅为当前 6 个，还是扩展到集团所有新媒体账号？
  • 周例会主持人与下周计划确认人是谁？
  • 是否有平台 API 或第三方工具可实现自动导出？是否允许采购？
  • 月度汇总是否需要报送管理层？
BRD-11宣传视频制作与多版本审核待优化300

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：大会播放视频、产品介绍视频、数字人视频、周年宣传片/TVC、领导访谈等视频需求，或研发用 AI 生成的演示视频/素材想对外使用时启动
  • 负责人：主责——运营部视频负责人（当前：鲁周毅·推断待确认）；协同——新媒体运营（当前：李宣昊·推断待确认）、导演/剪辑（当前：宫经喜·推断待确认）、需求方（当前：许君、杨萌·推断待确认）、研发画面保密审核（当前：丁震宇·推断待确认）、行政（当前：胡则瑾·推断待确认）；兜底——运营负责人（当前：待指定）；重大视频终审——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 需求提报 → ② 评估排期并登记视频总清单 → ③ 脚本/分镜确认 → ④ 素材与授权收集 → ⑤ 制作初版 → ⑥ 版本评审 → ⑦ 合规自查与终审 → ⑧ 发布交付与归档
  • 交付结果：定稿视频（各版本规格）、视频总清单记录、评审意见记录、肖像/声音授权书、源文件与提示词归档
  • 状态依据：已有《运营部｜视频需求提报规则》和视频清单 wiki，但 05～10 月大会视频归属不清、版本多轮返工、录音素材反复催交、AI 生成素材口头交接，约 60 条相关讨论

1. 场景判定

  • 触发条件：任何部门需要成片视频用于大会、官网、新媒体、销售演示；或研发产出 AI 视频/动画素材希望对外使用
  • 典型说法：「列个视频总清单，写一下每个视频的进度和责任人」「大家看下这个版本的结尾画面」「等市场部同事精加工一下」
  • 判断问题：最终是否成片对外播放或发布？能否说清主题、形式、交付时间、用途、审核人？——说不清先补需求，不进入排期
  • 不归本流程管：电视台/记者来公司拍摄与采访 → 请走 BRD-12；海报、PPT、手册 → 请走 BRD-13；仅内部培训录屏 → 由培训负责人自行处理；发布前用语合规规则 → 请走 BRD-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
运营部视频负责人 受理需求、排期、分派、维护总清单、组织评审 R 运营部视频负责人（当前：鲁周毅·推断待确认）
新媒体运营 清单维护、版本收集与发布 R 新媒体运营（当前：李宣昊·推断待确认）
导演/剪辑 脚本、访谈拍摄、剪辑、对接外包 R 内容/视频运营（当前：宫经喜·推断待确认）
需求方 提报需求、提供资料、确认版本 C 生态市场条线（当前：许君·推断待确认）；产品总监（当前：杨萌·推断待确认）
研发画面保密审核 研发区/屏幕/代码画面审核 C CTO（当前：丁震宇·推断待确认）
行政 场地、拍摄通知、桌面整理 C 行政负责人（当前：胡则瑾·推断待确认）
终审人 重大视频（大会、周年、品牌片）定稿 A CEO（当前：邴龙志·推断待确认）
出镜人 提供照片、声音母版，配合拍摄，签授权 C 出镜人员（当前：常元和、丁震宇等·推断待确认）

3. 办之前请准备

  • 需求单：主题、形式（真人实拍/AI 生成/数字人/混剪）、时长、交付时间、用途与播放场景、资料、审核负责人、参考视频（只写“做个视频”不排期）
  • 脚本或访谈问题初稿（可 AI 起草）
  • 出镜人正脸照、声音母版（45～60 秒 WAV，按录音要求录制）、肖像/声音使用授权书
  • 历史照片/活动素材所在位置（素材库链接）
  • 品牌素材：logo、模板、片头片尾、字幕规范

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按提报规则提交视频需求单 需求方 交付日前至少 10 个工作日（大会/周年片前 20 个工作日） 飞书多维表格表单 需求单 🔧飞书固化
2 评估可行性，定形式（真人/AI/外包）、负责人、里程碑，登记视频总清单 运营部视频负责人 提报后 2 个工作日内 多维表格视频总清单 排期与负责人 👤人工判断
3 出脚本/分镜，需求方与终审人确认 导演/剪辑 排期后 3 个工作日内 飞书文档 脚本 V1～V2 🤖+👤
4 收集出镜人照片、声音母版、历史素材，签肖像/声音授权 运营部视频负责人；行政协助 脚本确认后 3 个工作日内 飞书任务 + 授权书模板 素材包 + 授权书 🔧飞书固化
5 制作初版（内部制作/AI 生成/外包）；AI 视频先低分辨率试跑再出高清 导演/剪辑或外包 按清单里程碑 AI 视频工具、剪辑软件 初版 V1 🤖自动化
6 版本评审：每版编号上传，评审意见集中填入评审区（字幕、结尾、标题大小、画面） 需求方、终审人 收到版本后 1 个工作日内 多维表格评审字段 / 飞书文档评论 评审意见 🔧飞书固化
7 汇总意见后修改；原则上不超过 3 版 导演/剪辑 每轮 2 个工作日内 剪辑软件 V2/V3 👤人工判断
8 按 BRD-14 清单合规自查（竞品/第三方标识、英文界面、旧产品名、研发屏幕、授权）后终审定稿 视频负责人自查；终审人定稿 交付前 2 个工作日 合规清单 定稿 🤖+👤
9 发布或交付播放；源文件、提示词、授权书归档到公司云盘，不用个人网盘传递 新媒体运营 定稿当天 飞书云盘、视频号等 发布链接 + 归档 🔧飞书固化
10 项目结束后沉淀可复用的 AI 视频流程与提示词（Skill） 运营部视频负责人 交付后 5 个工作日内 飞书知识库 复用模板 🤖自动化

5. 交付物与模板

  • 交付物：定稿视频（横/竖屏各规格）、视频总清单记录、评审意见记录、授权书、源文件与提示词
  • 建议模板/表单：
    • 视频需求单：主题、形式、时长、交付时间、用途、资料链接、审核负责人、参考视频
    • 视频总清单（多维表格）：视频名、需求方、负责人、形式、当前版本、进度、截止时间、评审人、终审状态、成片链接
    • 肖像/声音使用授权书：授权人、用途、范围、期限、是否可用于 AI 生成
    • 录音要求说明：时长 45～60 秒、WAV 格式、安静环境、声道与采样率要求

6. 异常与升级

  • 需求不完整 → 退回补充，不进入排期；需求方 2 个工作日未补 → 关闭需求
  • 多个视频归属不清 → 视频负责人当天在清单中指定负责人；争议报运营负责人
  • 出镜人素材 2 个工作日未交 → 飞书任务催办一次，仍未交 → 报出镜人所在部门负责人；临近节点启用访谈保底片
  • 超过 3 版仍未定稿 → 视频负责人组织需求方与终审人当面过稿（1 小时内定方向）
  • 涉及研发画面或代码 → 必须经研发画面保密审核人确认后才能使用
  • 外包延期 → 视频负责人当天通知需求方，评估是否改为内部/AI 制作

7. 衡量指标

  • 需求按期交付率 = 按清单截止时间交付的视频数 / 视频总数，目标 ≥ 90%
  • 平均定稿版本数：目标 ≤ 3 版
  • 评审反馈时效 = 版本上传到意见汇总完成的工作日，目标 ≤ 1
  • 授权书覆盖率 = 有出镜人且已签授权的视频 / 有出镜人的视频，目标 100%

8. 低效诊断

  • 现象：大会多支视频并行时缺总清单，部分视频（研究院、签约、转场）归属不清｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：版本在群里逐个发、反馈分散，多轮返工｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：声音母版多次催交、格式不达标，高清放大后人脸失真返工｜依据：「三周年tvc视频+访谈」2026-07
  • 现象：历史照片需临时找人要，成片靠网盘链接传递｜依据：「三周年tvc视频+访谈」2026-07、2026-08
  • 现象：需求表述零散需二次梳理，之后才发布统一提报规则｜依据：「模态跃迁通知群」2026-08
  • 现象：研发 AI 生成的演示素材口头交接，无收集入口与发布审核｜依据：「跃迁AI总动员」2026-09、2026-10

9. 分支变体

  • 大会视频合集：先建视频总清单，每支视频单独负责人与截止时间；数字人视频单独开会对齐
  • 周年宣传片/TVC 与领导访谈：先定真人实拍还是 AI 生成；访谈作为保底片；剪辑可部分外包；先发短版
  • 研发 AI 生成素材：研发提交到素材收集表 → 市场/运营认领精加工 → 走步骤 8 终审后发布；版权与模型来源需人工确认
  • 公司内部实拍涉及研发区：提前 1 天由行政发通知，研发画面经保密审核人确认
  • 外部电视台/媒体来拍：按 BRD-12 执行

10. 待确认问题

  • 视频需求统一入口是运营部，还是品牌岗？运营负责人具体是谁？
  • 提报提前期 10/20 个工作日是否可行？
  • 哪些视频必须 CEO 终审，哪些由需求方确认即可？
  • 肖像/声音授权书是否已有法务模板？是否需要覆盖 AI 生成用途？
  • AI 视频 Skill 由谁维护、放在哪里？
BRD-12媒体采访与外部拍摄接待及对外口径待新建375

状态：待新建｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：国家级/地方电视台、报社记者等到访采访、拍摄、踩点或补拍，需要对内预告、选定受访人与演示内容、统一对外数据与说法、现场接待并回收素材时启动
  • 负责人：主责——媒体对接人（运营，当前：李凯·推断待确认）；协同——综合部/行政（当前：赵雪冰、胡则瑾·推断待确认）、技术统筹（当前：王皓南·推断待确认）、研发保密与技术口径（当前：丁震宇·推断待确认）、媒体口径审定（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）；重大来访由 CEO（当前：邴龙志·推断待确认）兜底
  • 核心流程：① 邀约登记 → ② 评估分级并定筹备组 → ③ 对内预告 → ④ 口径与受访稿 → ⑤ 演示与场地准备 → ⑥ 现场接待 → ⑦ 素材回收与发布前审看 → ⑧ 复盘归档
  • 交付结果：媒体来访登记记录、审定的受访稿与口径 Q&A、演示兜底视频、现场素材与报道链接、复盘记录
  • 状态依据：05～09 月多次媒体来访均为临时组群处理：前一天才通知、通宵赶制物料、受访人临时得知、研发区未提前预告被拍屏幕、受访稿口径靠群内讨论；无登记表、无检查清单、无口径审批

1. 场景判定

  • 触发条件：外部媒体/拍摄团队提出采访、拍摄、踩点、补拍需求；或政府/重要来访随行媒体
  • 典型说法：「明天要给某央媒客户演示产品」「又得搞采访，也没人跟我说」「下次有这种能不能提前通知一下」「稿子口径，如何」
  • 判断问题：来访方是否会对外发布内容（电视、报纸、网络）？是否进入办公区/研发区拍摄？是否需要我方人员出镜或提供数据？
  • 不归本流程管：公司自己发起的视频制作 → 请走 BRD-11；我方发布的新闻稿 → 请走 BRD-09；口径库与合规清单的维护 → 请走 BRD-14；无媒体的客户参观/演示 → 请走 SAL-08（客户/渠道/合作方来访交流准备与会后复盘）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
媒体对接人 登记邀约、对接媒体、组织筹备、回收素材 R 运营负责人/媒体对接（当前：李凯·推断待确认）
来访总负责人 重大来访总指挥，拍板演示内容与受访人；按来访级别二选一：政府/央媒等重大来访由 CEO 担任，技术类媒体来访由创始人兼 CTO 担任 A CEO（当前：邴龙志·推断待确认）；创始人兼 CTO（当前：丁震宇·推断待确认）
媒体口径审定人 审定受访稿、对外数据与说法 R COO（当前：常元和·推断待确认）
行政/综合部 发拍摄通知、会议室、白板、桌面整理、引导 R 综合部负责人（当前：赵雪冰·推断待确认）；行政负责人（当前：胡则瑾·推断待确认）
技术统筹 演示环境冻结、兜底视频、演示人员安排 R Leap 研发负责人（当前：王皓南·推断待确认）
研发保密审核 研发区拍摄范围与屏幕画面审核 C CTO（当前：丁震宇·推断待确认）
受访人/演示人 准备受访稿、现场受访或演示 R 按来访指定（当前：待指定）
新媒体运营 素材入库、报道转发与二次传播 I 新媒体运营（当前：李宣昊·推断待确认）

3. 办之前请准备

  • 来访信息：媒体名称、栏目、来访目的、时间、人数、联系人、拍摄范围（区域/人员/产品）、播出或发布时间
  • 采访提纲（向媒体索取）、我方受访人与备选人
  • 口径材料：公司与产品一句话介绍、标准 Q&A、对外可用数据（取自 BRD-14 口径库）
  • 演示方案：演示产品与脚本、演示环境负责人、兜底演示视频（无英文界面、无报错画面）
  • 场地：会议室、白板/大屏、研发区屏幕与白板清理、着装要求（无外文/他牌 logo）
  • 演示账号由技术统筹单独保管，不在群里发凭据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 任何人接到媒体邀约，转媒体对接人登记来访表 首个接到人 → 媒体对接人 接到后 2 小时内 飞书多维表格表单 来访登记 🔧飞书固化
2 评估分级（重大/一般/踩点补拍）与是否接受；重大来访确定总负责人并建临时筹备群，用飞书任务分工 媒体对接人 + 来访总负责人 登记后 4 小时内 飞书任务 分级、分工表 👤人工判断
3 对内预告：时间、区域、注意事项（清屏、清白板、着装、冻结发版与网络变更） 行政/综合部 至少提前 1 个工作日；每周五同步下周拍摄计划 全员群 + 飞书日历 拍摄通知 🔧飞书固化
4 受访稿：按提纲 AI 起草，引用口径库；涉及数据（研发投入、用量、客户数等）逐条标注来源 受访人 + 媒体对接人 来访前 1 天 12:00 前 飞书文档 + AI 受访稿初稿 🤖自动化
5 口径审定：删除负面/夸大/价格性表述，确认数据与对外一致 媒体口径审定人 来访前 1 天 18:00 前 飞书审批 审定稿 👤人工判断
6 演示准备：确定演示内容，冻结环境，录制兜底视频，演示工具使用合规国产模型，内部预演 1 次 技术统筹 来访前 1 天 18:00 前 演示环境、录屏工具 演示包 👤人工判断
7 现场接待：对接人到场，研发区拍摄由保密审核人陪同，按需补拍并现场把关画面 媒体对接人、行政、保密审核人 来访当天 — 接待记录 👤人工判断
8 回收素材与底片；发布前请求审看，涉及屏幕/代码/客户信息的画面要求打码 媒体对接人 来访后 2 个工作日内索取 公司云盘素材库 素材包、审看意见 👤人工判断
9 报道发布后收集链接，转发并二次传播；更新登记表与口径库，写 5 行复盘 媒体对接人 + 新媒体运营 报道发布后 2 个工作日内 多维表格、知识库 复盘记录 🔧飞书固化

5. 交付物与模板

  • 交付物：来访登记记录、拍摄通知、审定受访稿、演示兜底视频、素材包、报道链接、复盘
  • 建议模板/表单：
    • 媒体来访登记表：媒体、栏目、类型（采访/拍摄/踩点/补拍）、日期、区域、对接人、总负责人、受访人、演示内容、播出时间、素材状态、报道链接
    • 重大接待筹备清单：时间线（T-1 天/T-4 小时/T 当天）、人员分工、着装、场地、设备（白板尺寸、大屏）、环境冻结、兜底视频、交通与到场时间
    • 对外口径 Q&A：公司介绍、产品定位、可公开数据、敏感问题应答、不说的内容
    • 拍摄前保密检查清单：屏幕、白板、桌面文件、门禁区域、客户信息

6. 异常与升级

  • 来访通知不足 1 个工作日 → 立即按重大来访启动，总负责人当场分工；行政 1 小时内发对内预告
  • 受访人临时变更 → 媒体对接人当场通知新受访人并发审定稿；无审定稿不出镜
  • 记者追问口径库外的数据 → 现场不给具体数字，会后由口径审定人书面答复（1 个工作日内）
  • 口径审定人与受访人对数据或说法有分歧 → 以来访总负责人意见为准（当日）
  • 演示环境异常 → 立即切兜底视频；技术统筹事后 1 个工作日内说明原因
  • 发现有人拍到研发屏幕/敏感画面 → 现场请对方删除或标记打码，当天报保密审核人
  • 媒体不提供审看或素材 → 记录在登记表，下次评估接受与否时参考

7. 衡量指标

  • 对内预告提前率 = 提前 ≥1 个工作日通知的来访次数 / 来访总次数，目标 100%
  • 受访稿审定率 = 经口径审定的受访稿 / 受访稿总数，目标 100%
  • 素材回收率 = 拿到底片/素材的来访 / 来访总数，目标 ≥ 80%
  • 现场事故数（演示翻车、敏感画面外泄、口径错误）：目标 0

8. 低效诊断

  • 现象：重大拍摄前一天下午才通知，一晚上赶制视频、白板、拍摄稿；设备与人员分工不清，白板尺寸不合适需改大屏；演示环境凭据在群里直接发送｜依据：「某央媒客户Leap突击」2026-05
  • 现象：采访与补拍安排没有统一通知，受访人临时得知｜依据：「鼎慧产研决策部」2026-05、2026-06
  • 现象：采访前一天才通知，上下文靠人工同步；受访稿初稿出现不利于产品的价格表述，出镜人临时更换｜依据：「模态AI探索小分队」2026-05
  • 现象：来人后才知道谁对接，媒体底片素材未回收｜依据：「模态集团（全员群）」2026-05
  • 现象：研发采访数据口径无指定审稿人，靠群内讨论确认｜依据：「工程咨询产研」2026-05
  • 现象：是否邀请媒体的方针只在小范围口头传达，执行方事后才知道｜依据：「鼎慧产研决策部」2026-06
  • 现象：外部团队踩点/拍摄未提前告知研发区，员工误以为陌生人巡看电脑，且屏幕被拍，多次发生｜依据：「【模态】综合部」2026-08、「模态跃迁通知群」2026-08

9. 分支变体

  • 重大来访（国家级媒体、政府随行）：成立临时筹备组，CEO 或创始人任总负责人；冻结发版与网络变更；必须有兜底视频；统一着装
  • 地方媒体采访：可由媒体对接人牵头，受访稿须经口径审定；演示工具使用国产合规模型
  • 踩点/补拍：至少提前 1 个工作日预告涉及区域；研发区由保密审核人陪同
  • 学校/合作方宣传视频（外包剪辑）：按一般采访处理，成片发布前要求审看
  • 媒体邀约（我方主动邀请）：先做价值评估，管理层确认后再邀请

10. 待确认问题

  • 媒体对接统一入口是运营还是品牌岗？与综合部（拍摄通知）的分工是否如上？
  • 媒体口径审定人是否为 COO？涉及财务/研发投入数据是否还需财务确认？
  • 重大来访分级标准（哪些媒体/来访算重大）由谁定？
  • 媒体邀约方针（哪些媒体不必邀请）是否形成书面规则？
  • 研发区拍摄是否需要设固定可拍区域与禁拍区域？
BRD-13宣传物料（海报/折页/手册/PPT）制作与校对待优化192

状态：待优化｜证据：有证据（卡片 6 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：销售、活动、新产品或行业版需要海报、三折页、产品手册、宣讲 PPT、产品能力图、FAQ 话术手册、商城上架说明、官网/公众号板块内容等对外物料时启动
  • 负责人：主责——品牌物料统筹（当前：鲁周毅·推断待确认）；协同——需求方（销售/市场，当前：李鹏为、吴琪、闫登辉·推断待确认）、产品内容与口径（当前：杨萌·推断待确认）、技术表述审核（当前：丁震宇·推断待确认）、文案撰写（当前：陈梦琪、吴琪·推断待确认）、校对（当前：宋祺睿·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 需求提报 → ② 排期分派 → ③ 内容收集 → ④ 统稿出文案 → ⑤ 技术/口径审核 → ⑥ 设计制作 → ⑦ 校对与终审 → ⑧ 版本归档发布
  • 交付结果：定稿物料（源文件 + 导出文件）、物料版本表记录、统一存放的物料库
  • 状态依据：已有物料文件夹、行业版内容收集文档和 Q3 宣传全案，但 03～10 月反复出现版本混乱（旧版混入不当文字）、逐页改错别字、品牌名混用、logo/海报素材找不到、内容收集需多次催办，约 50 次

1. 场景判定

  • 触发条件：需要一份对外展示或分发的静态/演示物料，或官网、公众号新增/改版内容板块
  • 典型说法：「每个行业版能不能做一个这种宣传内容」「统一下中英文混排规范」「你有空看看这个图，不对的地方帮我们指出来」「所有市场相关物料我都放在一个文件夹里」
  • 判断问题：物料是否会给客户、合作方、公众看？内容是否涉及产品能力、数据安全、价格等承诺？——是则必须走审核
  • 不归本流程管：视频 → 请走 BRD-11；事件推文/新闻稿 → 请走 BRD-09；品牌用语规则与话术库维护 → 请走 BRD-14；客户案例内容 → 请走 BRD-15；竞品对比内容 → 请走 BRD-16；纯内部使用的梗图 → 不走本流程，但不得外传

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌物料统筹 受理需求、排期、收集内容、统稿、设计/对接设计、归档 R 运营/设计统稿（当前：鲁周毅·推断待确认）
生态市场条线负责人 对外物料终审、排期冲突裁决 A 生态市场条线负责人（当前：许君·推断待确认）
需求方 提报需求、说明用途与受众、验收 R 销售负责人（当前：李鹏为·推断待确认）；销售（当前：吴琪、闫登辉·推断待确认）
产品内容与口径 提供卖点、截图，确认产品表述；以其定稿为准 C 产品总监（当前：杨萌·推断待确认）
技术表述审核 审核数据安全、部署、模型等技术表述 C CTO（当前：丁震宇·推断待确认）
文案撰写 话术稿、FAQ、说明文字初稿 R 研究院生态（当前：陈梦琪·推断待确认）；销售（当前：吴琪·推断待确认）
校对 错别字、大小写、中英文混排、品牌名 R 校对人（当前：宋祺睿·推断待确认）
法务 涉及承诺、真人/名人形象、第三方商标时审阅 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 物料需求单：物料类型、用途/场景、受众、规格与数量、截止时间、内容负责人、是否对外、是否印刷
  • 内容信息卡（行业版/产品各一张）：卖点 3 条、典型场景、截图、联系人
  • 品牌素材：标准 logo（透明底）、模板、主色、产品规范名称表（来自 BRD-14）
  • 往期同类物料（从物料库取最新版，不用聊天里转发的旧版）
  • AI 生图时：使用标准提示词模板，产品名和定位从口径库复制，不临时编写

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交物料需求单 需求方 截止日前至少 5 个工作日（印刷品 8 个工作日） 飞书多维表格表单 需求单 🔧飞书固化
2 评估、排期、指定内容负责人与设计；明确“每个版本一张”等交付颗粒度 品牌物料统筹 提报后 1 个工作日内 多维表格 排期 👤人工判断
3 按信息卡模板收集内容 内容负责人（产品/业务） 排期后 2 个工作日内 多维表格 / 飞书文档 内容信息卡 🔧飞书固化
4 统稿，AI 出文案初稿或海报初稿 品牌物料统筹 / 文案撰写 内容到齐后 1 个工作日内 AI 工具 + 提示词模板 文案/初稿 🤖自动化
5 技术与产品表述审核（数据安全、部署形态、模型来源、能力边界），不必要的细节删减 产品内容与口径、技术表述审核 1 个工作日内 飞书文档评论 审定文案 👤人工判断
6 设计制作，使用品牌素材库 logo 与模板 品牌物料统筹 / 设计 2 个工作日内 设计工具 设计稿 V1 👤人工判断
7 校对：AI 自动校对 + 人工逐页检查（错别字、大小写、中英文混排、品牌名、联系方式、链接） 校对人 1 个工作日内 AI 校对 + 校对清单 校对意见（按页码） 🤖+👤
8 按 BRD-14 合规自查后终审定稿 生态市场条线负责人 1 个工作日内 飞书审批 定稿 🔧飞书固化
9 归档：源文件 + 导出文件放物料库，文件名带版本号与日期，旧版标“作废”；发布到市场群时只发物料库链接 品牌物料统筹 定稿当天 飞书云盘物料库 + 版本表 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：定稿物料（源文件、PDF/PNG）、物料版本表记录、审核记录
  • 建议模板/表单：
    • 物料需求单：类型、用途、受众、规格、数量、截止时间、内容负责人、是否对外、是否印刷、参考样例
    • 内容信息卡：产品/行业版名称（规范名）、一句话定位、卖点、场景、截图、数据（附口径来源）、联系人
    • 物料版本表（多维表格）：物料名、类型、产品线、版本号、日期、负责人、审核人、状态（在用/作废）、文件链接
    • 校对清单：错别字、中英文混排与空格、大小写、品牌名规范、logo 版本、联系方式、二维码/链接是否为正式环境

6. 异常与升级

  • 内容 2 个工作日未交 → 物料统筹催办一次，仍未交 → 报需求方部门负责人；可先出缺项占位版
  • 紧急需求（不足 2 个工作日）→ 需条线负责人同意插队，并明确可放弃的环节（仅能简化设计，不能跳过审核）
  • 产品与技术表述冲突 → 由 CTO 定技术事实，产品总监定表述方式（1 个工作日内）
  • 发现在用物料有错误或旧版流出 → 当天在物料库标作废并通知市场/销售群停用
  • 涉及真人/名人形象或第三方商标 → 先取得授权或改用无风险素材，报法务确认

7. 衡量指标

  • 按期交付率 = 按需求截止时间交付的物料 / 物料总数，目标 ≥ 90%
  • 校对后外发错误数：目标 0
  • 物料入库率 = 物料库中有版本记录的在用物料 / 在用物料，目标 100%
  • 平均制作周期 = 提报到定稿的工作日数，目标 ≤ 5

8. 低效诊断

  • 现象：材料需求零散提出、口径不一，多次催办｜依据：「【模态】市场销售」2026-08、2026-09
  • 现象：行业版宣传内容收集缺固定模板和交付节点，交付颗粒度需反复确认｜依据：「【模态】解决方案」2026-06、「【模态】行业版leapcore」2026-06
  • 现象：大会 PPT/手册临近截止通宵赶制，逐页截图改错别字约 3 轮；品牌名与合作方名称口径不统一；竖屏海报、logo 素材需临时找人要｜依据：「鼎慧产研决策部」2026-05
  • 现象：AI 生图时产品名多种写法混用，业务口径只存在于各人提示词中，无品牌审核｜依据：「随便瞎聊啦～」2026-04
  • 现象：物料散落各处需重复制作、找不到最新版｜依据：「字字可研市场运营」2026-04、2026-05

9. 分支变体

  • 行业版 LeapCore 统一内容：先发信息卡模板给各行业版负责人，统一收束后设计，每个行业版一张/一套
  • 宣讲 PPT/FAQ 话术手册：技术表述须技术审核；以产品口径负责人的定稿为准，旧版必须作废
  • 商城上架说明/产品能力图：按商城字段要求编写，能力描述以口径库为准
  • AI 生图海报：使用标准提示词模板；含真人/名人形象的仅限内部，对外须授权
  • 官网/公众号板块新增或改版：内容走本流程，上线前截图确认
  • 特定产品线物料（如 LocalMind、工程咨询版）：按产品线分目录归档

10. 待确认问题

  • 物料统筹主责是运营部还是品牌岗？设计资源归谁调度？
  • 对外物料终审人是否统一为生态市场条线负责人？技术类物料是否必须 CTO 签字？
  • 物料库放在哪个云盘目录？现有多个文件夹是否合并？
  • 提报提前期 5/8 个工作日是否可行？
  • 是否需要建品牌视觉规范（中英文混排、字体、配色）文档？
BRD-14对外口径、品牌用语与发布前合规自查待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：任何对外推广、市场/销售回答客户问题、视频/文案/页面发布前，需要统一品牌名与话术，并检查敏感词、竞品/第三方标识、版本信息、环境链接及数据安全/模型来源等说法时适用
  • 负责人：主责——品牌口径维护人（当前：李凯·推断待确认）；协同——品牌与命名决策（当前：常元和·推断待确认）、技术口径（当前：丁震宇·推断待确认）、发布前审看（当前：宋祺睿、张东郅·推断待确认）、素材取舍决策（当前：杨萌·推断待确认）、销售话术使用方（当前：杨朋伟·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 建品牌与话术库 → ② 管理层与法务审定 → ③ 发布并培训 → ④ 发布前作者自查 → ⑤ AI 初筛 → ⑥ 人工复核与终审 → ⑦ 新问题入库 → ⑧ 定期更新
  • 交付结果：《品牌与对外话术库》（含产品规范名、标准 Q&A、禁用词、正式链接入口、logo/模板）、发布前合规自查记录
  • 状态依据：已有一份传播文案模板和 logo 包，但无成文话术库与发布前清单：05 月品牌名反复变化、外部流传测试链接、媒体稿使用测试服截图、客户问数据泄露时无标准回答、视频临发布才审出第三方标识，均为临时处理

1. 场景判定

  • 触发条件：（1）任何内容即将对外发布（视频、推文、海报、官网、话术稿、媒体稿）；（2）客户/渠道提出敏感问题（数据安全、模型来源、产品定位、价格）而话术库没有现成答案；（3）产品更名或发布新版本
  • 典型说法：「大家写宣发文案的时候一定要小心」「有没有统一的话术」「口径统一得一定要快」「只要放出去，几十秒给几百个人看总能看到」
  • 判断问题：这段内容外部的人会不会看到？里面有没有产品名、数据、承诺、第三方名称或截图？——有就按本规则自查
  • 不归本流程管：具体稿件的撰写与发布 → 请走 BRD-09/11/13；媒体来访接待 → 请走 BRD-12（共用本话术库）；合同条款的法律审核 → 请走 LEG-03（销售合同审查），其他对外合同走 LEG-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌口径维护人 编写与维护话术库、文案模板、正式链接清单；组织培训 R 运营负责人/宣发（当前：李凯·推断待确认）
品牌与命名决策 产品命名、品牌定位、媒体口径最终决定 A COO（当前：常元和·推断待确认）
技术口径 数据安全、模型来源、部署形态等技术事实 C CTO（当前：丁震宇·推断待确认）
法务 审阅承诺性表述、主体名称、比较性表述 C 法务负责人（当前：李瑶·推断待确认）
内容作者 按话术库与文案模板撰写，发布前按清单自查 R 各稿件作者（按稿件指定）
发布前审看 逐段/逐帧审看视频与页面，标出问题点 R 测试/研发（当前：宋祺睿、张东郅·推断待确认）
素材取舍决策 审看问题的轻重取舍（品牌与口径分歧报品牌与命名决策人） R 产品总监（当前：杨萌·推断待确认）
话术使用方 按话术库对外沟通，反馈新问题 I 销售/商务（当前：杨朋伟·推断待确认）

3. 办之前请准备

  • 产品规范名称表（中英文、大小写、空格写法、禁止写法）
  • 标准 Q&A：数据安全与留存、模型来源与调用方式、部署形态（云端/本地/折中）、产品定位、价格表述原则
  • 禁用词与负面关联词表、竞品/第三方产品名与 logo 清单、地区/政治敏感词
  • 正式环境链接入口（官网、产品、帮助、客服），禁止对外发测试环境
  • 公司主体名称对照（对外落款、短信/通知签名所用主体）
  • logo 包与默认模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 汇总现有口径，编写话术库初版（上述 6 类内容） 品牌口径维护人 启动后 10 个工作日内 飞书知识库 话术库 V1 🤖+👤
2 管理层审定命名与定位，CTO 审技术事实，法务审承诺性与比较性表述 品牌决策、技术口径、法务 收到后 5 个工作日内 飞书审批 审定版 👤人工判断
3 发布话术库，对市场、销售、运营做 1 次培训 品牌口径维护人 审定后 5 个工作日内 飞书会议 + 知识库 培训记录 🔧飞书固化
4 每次对外发布前，作者按自查清单逐项勾选 内容作者 发布前 自查清单（飞书表单） 自查记录 🔧飞书固化
5 AI 初筛：敏感词/禁用词匹配、品牌名变体、竞品与第三方标识、测试环境链接、英文界面；视频抽帧检查 内容作者 发布前 1 个工作日 AI 机器人 + 词库 初筛报告 🤖自动化
6 人工复核：视频全片逐段审看，按时间点标注问题；按轻重分级（必须改/建议改） 发布前审看人 收到后 0.5 个工作日内 飞书文档 审看意见 👤人工判断
7 取舍决策与终审，必须改项未改不得发布 素材取舍决策人 0.5 个工作日内 飞书审批 发布许可 👤人工判断
8 客户/渠道提出库外问题 → 提交新问题，给出临时答复原则“不承诺、会后书面回复” 话术使用方 当天提交 飞书表单 新问题记录 🔧飞书固化
9 新问题审定入库；产品更名/发版时同步更新话术库版本并群公告 品牌口径维护人 新问题 2 个工作日内；更名当天 知识库 + 群公告 话术库新版本 🔧飞书固化

5. 交付物与模板

  • 交付物：《品牌与对外话术库》（带版本号）、发布前自查记录、新问题台账
  • 建议模板/表单：
    • 话术库结构：产品规范名表｜一句话定位｜标准 Q&A（问题、标准回答、禁止说法、审定人、版本）｜禁用词表｜正式链接清单｜主体名称对照｜logo 与模板
    • 发布前自查清单：产品名是否规范、版本号是否最新、是否出现竞品/第三方 logo 或名称、是否有英文/测试环境界面、链接是否正式、数据是否在口径库内、是否有夸大或绝对化承诺、是否有地区/政治敏感内容、真人形象是否授权
    • 新问题台账：问题、提出场景、临时答复、审定答复、审定人、入库日期

6. 异常与升级

  • 发布前发现必须改项、但时间来不及 → 推迟发布或删除相关片段，不带病发布 → 报素材取舍决策人（当天）
  • 话术库没有的问题被客户追问 → 不现场编答案，不夸大（如未实现的技术能力）→ 2 个工作日内由技术口径/品牌决策给出书面口径
  • 已发布内容发现口径错误 → 2 小时内下线或修改，报生态市场条线负责人；涉及客户承诺的同步报法务
  • 品牌名或主体信息与实际不一致（如通知签名主体）→ 报品牌决策人与法务，1 周内整改
  • 话术库与产品实际能力不符 → 产品负责人提更新，2 个工作日内修订

7. 衡量指标

  • 自查覆盖率 = 有自查记录的对外发布 / 对外发布总数，目标 100%
  • 发布后口径事故数（品牌名错误、测试链接外流、错误承诺）：目标 0
  • 新问题入库时效 = 提出到审定入库的工作日，目标 ≤ 2
  • 话术库培训覆盖率 = 已培训的市场/销售/运营人员 / 应培训人数，目标 100%

8. 低效诊断

  • 现象：品牌名多次变化，外部流传测试环境链接，媒体稿使用测试服截图｜依据：「LeapPPT」2026-05
  • 现象：对外通知所用主体名称与公司主体不一致，临时提出修改｜依据：「LeapPPT」2026-05
  • 现象：销售/商务对外缺少统一话术、正式链接和邀约说明｜依据：「LeapPPT」2026-05
  • 现象：客户问数据泄露时无标准回答，群内临时讨论，出现夸大建议被否决｜依据：「LeapCore（archived）」2026-05
  • 现象：视频临近发布才逐帧审出第三方产品标识、旧产品名；问题轻重取舍无标准｜依据：「Leap产研测」2026-05
  • 现象：产品名多种写法在对外素材中混用｜依据：「随便瞎聊啦～」2026-04

9. 分支变体

  • C 端用户话术：侧重功能与使用，链接一律正式环境
  • 企业客户/渠道：重点覆盖数据安全、模型来源、部署形态、定位（云端 SaaS / 算力机 / 折中方案）
  • 媒体稿：与 BRD-12 共用话术库，数据须经口径审定
  • 高校/资本方：按对象补充专用 Q&A，经品牌决策人审定
  • 产品内容安全过滤（产品内词库）：属研发需求，可复用本规则的敏感词表

10. 待确认问题

  • 话术库主责是运营、品牌岗还是生态市场条线？品牌岗报送人是否接手？
  • 品牌与命名最终决策人是否为 COO？技术口径是否统一由 CTO 签字？
  • 法务是否参与每次审定，还是只审话术库和高风险稿件？
  • 敏感词库是否采购第三方服务？
  • 自查清单是否需要做成飞书审批的必填前置项？
BRD-15客户案例与白皮书收集及授权核查待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：签单/交付验收后沉淀客户案例，或市场、销售需要案例做手册、PPT、视频、白皮书、推文、演示机内容，或 FDE 产出场景化案例/演示 Skill 需要转化为对外内容时启动
  • 负责人：主责——市场案例管理（当前：闫登辉·推断待确认）；协同——市场把关（当前：李鹏为·推断待确认）、FDE 案例产出（当前：李凯、黄振锋、佘天禾·推断待确认）、内容转化（当前：韩诗琪、许君·推断待确认）、优先级协调（当前：常元和·推断待确认）、技术支持（当前：丁震宇、杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 结项触发案例入库 → ② 填案例卡 → ③ 授权核查与分级 → ④ 入市场知识库 → ⑤ 内容转化需求提报 → ⑥ 撰写/录制 → ⑦ 发布前授权过滤与审核 → ⑧ 发布与季度盘点
  • 交付结果：带授权等级的案例库（多维表格 + 市场知识库）、案例集/白皮书/推文/演示素材、授权确认记录
  • 状态依据：已有案例汇总群、填写表和案例集文档，但 05～10 月靠群内反复催交、客户名能否公开逐个临时判断、案例未实时入知识库、演示素材无归口、案例职责在产研与市场间来回推，AI 批量生成的案例集曾包含未授权客户信息，审阅时才发现

1. 场景判定

  • 触发条件：项目签单、POC/交付验收完成；FDE 完成场景化案例或演示 Skill；市场/销售提出案例、白皮书、演示素材需求
  • 典型说法：「案例大家都在这个群都甩一下呀」「演示视频录了多少了，找谁要」「这个案例演示该我们产研做吗」「这种东西能不能不体现」
  • 判断问题：内容是否引用了具体客户/项目？客户是否授权公开、能否署名？需求是要案例素材，还是要产研开发新演示功能？
  • 不归本流程管：新演示功能开发 → 请走 X-PRD-09（需求提报登记与需求池管理）；竞品对比 → 请走 BRD-16；案例稿发布排版 → 请走 BRD-09；物料设计 → 请走 BRD-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
市场案例管理 维护案例库、收集与催交、组织转化 R 渠道/销售骨干（当前：闫登辉·推断待确认）
市场把关 判断案例能否对外、能否署名 A 市场销售负责人（当前：李鹏为·推断待确认）
项目负责人/FDE 结项后填案例卡，提供演示录屏与场景说明 R FDE 负责人（当前：李凯、黄振锋·推断待确认）；FDE 成员（当前：佘天禾·推断待确认）
销售对接人 向客户确认授权 R 对应客户销售（当前：待指定）
内容转化 把案例写成推文、PPT、白皮书 R 市场/销售运营（当前：韩诗琪·推断待确认）；生态市场条线（当前：许君·推断待确认）
优先级协调 案例/演示需求跨部门优先级冲突时裁定 A（升级） COO（当前：常元和·推断待确认）
技术支持 提供技术描述、核对事实，不负责出案例 C CTO（当前：丁震宇·推断待确认）；产品总监（当前：杨萌·推断待确认）
法务 授权书模板、涉密/敏感客户判断 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 案例卡字段：客户类型（行业，不写真名的匿名称呼）、痛点、方案、使用产品、效果数据（附来源）、截图/录屏链接、项目负责人
  • 授权信息：合同保密条款、客户是否同意署名/展示 logo/引用数据的书面确认
  • 需求方说明：用途（推文/PPT/白皮书/演示机/大会）、受众、截止时间
  • 已有案例库链接（先查再要，避免重复向同一人索取）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签单/验收/场景完成时自动给项目负责人派“填案例卡”任务 系统（案例管理配置） 结项当天 飞书任务/多维表格自动化 待办 🔧飞书固化
2 填写案例卡，上传截图/录屏 项目负责人/FDE 结项后 5 个工作日内 多维表格案例库 案例卡 🔧飞书固化
3 授权核查：查合同保密条款，向客户确认；标注授权等级（可署名/匿名可用/仅内部/禁止） 销售对接人；涉密客户由法务判断 案例卡提交后 5 个工作日内 多维表格授权字段 授权等级 + 确认记录 👤人工判断
4 市场把关复核授权等级，同步入市场部知识库 市场把关 + 案例管理 2 个工作日内 飞书知识库 入库案例 🔧飞书固化
5 需求方提报案例转化需求，案例管理按责任矩阵分派（案例与演示由 FDE/市场出，产研只做技术支持）；冲突由 COO 排优先级 需求方、案例管理 提报后 1 个工作日内 多维表格需求表 分派结果 👤人工判断
6 AI 生成结构初稿，真实体验与效果由人撰写；演示录屏按“当前能力/下两版/未来规划”分类 内容转化 / FDE 3 个工作日内 AI 工具 初稿/素材 🤖+👤
7 发布前按授权字段过滤：AI 批量生成的案例集只能从“可署名/匿名可用”记录取数，人工再核一遍客户信息 案例管理 发布前 1 个工作日 多维表格筛选视图 过滤后的稿件 🤖+👤
8 审核：市场把关审授权与表述，按 BRD-14 合规自查 市场把关 1 个工作日内 飞书审批 发布许可 👤人工判断
9 发布/交付并回填使用记录；每季度盘点案例库，补缺、下线过期案例 案例管理 发布当天；季度末 10 个工作日内 多维表格 使用记录、盘点报告 🔧飞书固化

5. 交付物与模板

  • 交付物：案例库（含授权等级）、案例集/白皮书、推文与演示素材、授权确认记录、季度盘点
  • 建议模板/表单：
    • 案例卡：行业、客户匿名称呼、项目阶段、痛点、方案、产品/Skill、效果数据及来源、素材链接、项目负责人、销售对接人、授权等级、授权依据、可用渠道、更新日期
    • 客户授权确认函：可公开内容（名称/logo/数据/截图）、渠道、期限
    • 案例转化需求表：用途、受众、截止时间、指定案例、负责人、状态

6. 异常与升级

  • 结项 5 个工作日未填案例卡 → 系统提醒一次，仍未填 → 报项目所在部门负责人
  • 客户授权不明 → 默认“仅内部”，不得对外使用；涉密/军队类客户一律“禁止”
  • 已发布材料发现未授权客户信息 → 当天下线/删除，报市场把关与法务，并检查同批材料
  • 案例或演示需求被推到产研 → 按责任矩阵退回 FDE/市场；争议 1 个工作日内由 COO 裁定（A（升级））；案例能否对外、能否署名由市场把关人拍板
  • 重要对外节点（发布会、大会）素材不足 → 节点前 10 个工作日由案例管理盘点并预警条线负责人

7. 衡量指标

  • 案例入库及时率 = 结项后 5 个工作日内入库的案例 / 结项项目数，目标 ≥ 80%
  • 授权标注覆盖率 = 已标授权等级的案例 / 案例总数，目标 100%
  • 未授权信息外露次数：目标 0
  • 案例需求满足时效 = 提报到交付的工作日数，目标 ≤ 5

8. 低效诊断

  • 现象：案例靠群内反复催交，“有多少发多少”；多人被重复索要同一案例｜依据：「模态案例集汇总群」2026-05
  • 现象：客户名是否可写需逐个临时判断，涉密类客户险些写入｜依据：「模态案例集汇总群」2026-05
  • 现象：案例未实时进入市场部知识库｜依据：「模态案例集汇总群」2026-08
  • 现象：FDE 案例与演示视频无归口，不知找谁要，对外节点前临时催清单｜依据：「公司内FDE」2026-08、2026-09
  • 现象：案例与演示职责在产研与市场间来回推，市场惯性找产研｜依据：「鼎慧产研决策部」2026-07、2026-08
  • 现象：AI 批量扫描生成的案例集包含未授权客户信息，审阅时才发现并删除｜依据：「核心项目群」2026-10

9. 分支变体

  • 既往签单案例 vs 后续大项目：既往案例一次性补录，新项目结项自动触发
  • 署名案例 vs 匿名案例：按授权等级决定，匿名案例用“某工程咨询客户/某地方政府客户”等称呼
  • FDE 场景案例与演示 Skill：转推文（案例拆解类、Skill 类）、演示机内置场景、大会/渠道大会素材
  • 白皮书：由市场牵头，产研提供技术章节，发布前法务审阅
  • 涉密/军队类客户：不进入对外案例库，仅内部留存

10. 待确认问题

  • 案例库主责是销售侧还是品牌/市场侧？是否需要专职？
  • 客户授权由销售确认是否可行？是否有现成授权函模板？
  • 案例与演示的责任矩阵（FDE、市场、产研）是否按上述划分？是否需要发文明确？
  • 能否在项目留痕/CRM 中增加“授权等级”字段，供生成材料时自动过滤？
  • 白皮书的牵头人是谁？
BRD-16竞品对比评测与素材产出待新建72

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：产品实测出性能/成本优势，或需要与竞品（豆包、Kimi、ZCode 等）做同任务对比，并把结果转化为推文、演示和销售素材时启动；研发日常实测发现可用对比素材时也按本流程沉淀
  • 负责人：主责——竞品评测统筹（产品，当前：杨萌·推断待确认）；协同——评测执行（当前：李慧珍、陈芷青、陈震、黄飞鹏·推断待确认）、研发实测（当前：岳阳、王皓南·推断待确认）、技术判断（当前：丁震宇·推断待确认）、销售/对外使用（当前：闫登辉·推断待确认）、市场运营（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 选题与评测方案 → ② 审核范围 → ③ 同任务实测与取证 → ④ 整理对比文档 → ⑤ 评审（无优势则反馈产品）→ ⑥ 合规自查 → ⑦ 入竞品对比库 → ⑧ 转化素材与定期复测
  • 交付结果：竞品评测文档（结论先行、图表、录屏截图）、竞品对比库记录、可对外使用的对比素材
  • 状态依据：06～07 月对比素材只在群里截图、点名研发准备后无交付跟踪；10 月刚开始搭建“产品联通市场运营”的评测链路，首版评测返工，尚无固定框架

1. 场景判定

  • 触发条件：（1）产品新版本或新能力上线，需要证明优势；（2）市场/销售提出对比素材需求；（3）研发实测中发现我方明显优于或劣于竞品的结果
  • 典型说法：「核心宗旨还是宣传我们的产品」「对比有证据」「对外部门要有平时积累素材的意识，后面直接复用」「同样的任务更便宜效果还更好」
  • 判断问题：是否为同一任务、同等条件下的实测？结果是否有可复现证据（录屏、截图、数据）？用途是对外宣传还是内部改进？
  • 不归本流程管：产品功能缺陷修复 → 请走 RND-03（缺陷提报、复现、分级与指派），新需求走 X-PRD-09；对比稿的发布 → 请走 BRD-09/13；对外表述合规规则 → 请走 BRD-14；模型基准评测（纯技术 bench）→ 请走 X-PRD-18（模型选型、档位配置与评测），Agent 评测走 RND-82

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
竞品评测统筹 定评测要求与框架、审核选题范围、评审结果 A 产品总监（当前：杨萌·推断待确认）
评测执行 选场景、写方案、实测、出文档 R 产品/评测（当前：李慧珍、陈芷青、陈震、黄飞鹏·推断待确认）
研发实测 提供技术方案、成本数据，日常提交对比素材 R 研发（当前：岳阳、王皓南·推断待确认）
技术判断 判断对比方法是否公平、结论是否成立 C CTO（当前：丁震宇·推断待确认）
销售/对外使用 提需求、使用素材、反馈客户关注点 I 销售/渠道（当前：闫登辉·推断待确认）
市场运营 把评测转成推文/演示素材 R 市场运营（当前：待指定）

3. 办之前请准备

  • 评测方案卡：场景（贴近客户真实任务）、对照产品与版本、评测指标（耗时、检出率/准确率、成本、易用性）、题目/输入、预计用时
  • 选竞品理由：客户常拿来比、同类定位
  • 取证工具：录屏、截图规范、测试时间与环境记录
  • 我方产品版本号与所用模型信息
  • 参考推文样例（评测转化后的目标形态）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交评测方案卡（场景、对照产品、指标、题目） 评测执行 接到任务后 1 个工作日内 多维表格评测任务表 方案卡 🔧飞书固化
2 审核范围：场景过大则收窄到 1～2 天可完成；题目不能过于简单 竞品评测统筹 1 个工作日内 飞书文档评论 确认方案 👤人工判断
3 同输入、同条件实测，记录产品与模型版本、测试时间，全程录屏截图 评测执行 / 研发实测 2 个工作日内 录屏工具 原始数据 + 素材 👤人工判断
4 整理对比文档：结论先行、对比表与图表、关键截图；AI 辅助整理表格 评测执行 1 个工作日内 飞书文档 + AI 评测文档 🤖自动化
5 评审：是否一眼看懂、是否体现优势、素材是否清晰、模型信息是否完整；无优势 → 转产品优化需求，不对外 竞品评测统筹；方法争议请 CTO 1 个工作日内 飞书文档 评审结论 👤人工判断
6 对外前合规自查：如实标注测试时间与条件，不贬低竞品，不使用竞品 logo，不夸大 评测执行 0.5 个工作日内 BRD-14 自查清单 自查记录 🤖+👤
7 入竞品对比库（场景、对照产品、结论、素材链接、可否对外、测试日期） 评测执行 评审通过当天 多维表格竞品对比库 库记录 🔧飞书固化
8 市场运营转化为推文、演示脚本或销售对比页 市场运营 按 BRD-09/13 排期 — 对外素材 👤人工判断
9 研发/任何人日常实测发现亮点，1 分钟表单提交到对比库“待整理”；每季度复测在用对比，过期结论下线 全员；统筹负责复测 随时提交；季度末 10 个工作日内复测 多维表格表单 待整理素材、复测记录 🔧飞书固化

5. 交付物与模板

  • 交付物：评测文档、竞品对比库记录、对外对比素材、复测记录
  • 建议模板/表单：
    • 评测方案卡：场景、任务描述、对照产品及版本、我方产品及版本、指标、题目链接、执行人、截止时间
    • 评测文档模板：一句话结论｜对比表（指标 × 产品）｜关键截图/录屏｜测试条件（时间、版本、模型、网络）｜局限说明｜改进建议
    • 竞品对比库字段：场景、对照产品、结论（优/平/劣）、素材链接、测试日期、可否对外、使用记录、下次复测日期

6. 异常与升级

  • 实测结果我方无优势 → 不对外，转产品需求池，由竞品评测统筹 2 个工作日内提需求
  • 竞品不开源、难以做基准对比 → 改为同任务端到端对比，并在局限说明中写明
  • 素材需求点名研发后 3 个工作日无交付 → 报竞品评测统筹调度
  • 对外素材被质疑不公平或过期 → 立即下线，CTO 复核方法，5 个工作日内复测
  • 对比涉及具体客户数据 → 改用脱敏或公开数据，按 BRD-15 授权规则处理

7. 衡量指标

  • 评测完成周期 = 方案确认到评审通过的工作日数，目标 ≤ 5
  • 首版评审通过率：目标 ≥ 60%
  • 对比库可对外条目数：按季度设定目标（如每季度新增 ≥ 6 条）
  • 素材使用率 = 被推文/演示/销售使用过的条目 / 可对外条目，目标 ≥ 50%

8. 低效诊断

  • 现象：研发实测竞品的截图散落群聊，无归档，复用困难｜依据：「跃迁AI总动员」2026-06
  • 现象：市场需要对比示例时直接点名研发准备，无需求单与交付跟踪；部分竞品不开源难做基准对比｜依据：「Leap产研测」2026-07
  • 现象：首版评测文档偏技术、素材模糊、题目偏简单，评审一次多条意见返工；选题范围过大需收窄｜依据：「leapcore竞品分析」2026-10

9. 分支变体

  • 场景化任务对比（如合同交付前质检、KPI 预警）：按完整评测流程执行
  • 生成类对比（PPT 生成、写作）：以成品截图并排展示，注明输入与时间
  • 成本对比（同任务费用）：费用数据需技术判断人确认计算口径后才可对外
  • 日常随手对比：仅入库“待整理”，经评审后才能对外

10. 待确认问题

  • 竞品评测主责是产品团队还是市场/品牌？市场运营的承接人是谁？
  • 对外使用竞品名称做比较是否需要法务逐条审阅？
  • 对比库是否与知识库现有竞品材料合并？
  • 评测频率：按版本发布触发，还是固定每月/每季度？
  • 成本类对比数据由谁确认口径？
BRD-17品牌素材库与对外资料库维护待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：申报、论坛、市场、销售、官网/新媒体需要产品图、渲染图、演示视频、手册截图、合影、Logo、二维码、产品介绍（topic）、Q&A 等素材时，统一从素材库调取；新素材产生或旧素材过期时，按版本入库和更新
  • 负责人：主责——品牌素材库管理员（品牌岗）（当前：陈梦琪·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、总经办（当前：赵雪冰·推断待确认）、销售对外资料整理人（当前：闫登辉·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、官网仓库维护研发（当前：宋祺睿·推断待确认）、新媒体运营（当前：鲁周毅·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 素材分类与责任人认领 → ② 新素材入库（脱敏+打标签+标版本）→ ③ 需求方按目录自助调取 → ④ 库中缺失时提素材需求任务 → ⑤ 责任人补齐并回填入库 → ⑥ 每周五过期检查 → ⑦ 每月盘点缺失与下架
  • 交付结果：一个唯一入口的品牌素材库与对外资料库（产品信息总表 + 分类素材目录），每条素材有责任人、版本日期、可否对外标记；素材需求全部有任务记录并回填入库
  • 状态依据：已有产品信息表、PPT 素材库、Logo/二维码大全压缩包、官网仓库“产品高清图”目录，并有周五更新提醒；但 2026-01～09 仍反复出现群内 @全体 找图、链接“永远不是最新版”、素材在个人手中和聊天里流转、谁维护不清，约 20 次以上

1. 场景判定

  • 触发条件：需要现成的产品/品牌/活动素材用于对外展示（申报、论坛、官网、报名网站、折页、推文、客户演示、PPT）；或新产品/新版本发布、活动结束后产生新素材；或发现库中链接、截图、介绍已过期
  • 典型说法：「谁有 LeapCore 一体机的图片素材，在做报名网站要用」「每次找产品链接、演示视频、项目文件都要到处翻」「信息经常被顶上去，或者永远不是最新版的链接」「还需要 3-4 张图片/视频，脱个敏」「开源社区的微信二维码发一下」「团队竖版照片谁有」「之前做分享那篇带合照的推文还能找到吗」「有个客户想看过往项目，有没有现成视频」
  • 判断问题：我要的是“已有素材的取用或更新”吗？如果是，先查素材库；库里没有、需要新做或重新拍摄，才进入第 4 步提需求
  • 不归本流程管：
    • 新物料（海报/折页/手册/PPT）设计制作与校对 → 请走 BRD-13
    • 宣传视频新拍、剪辑与审核 → 请走 BRD-11
    • Logo/品牌视觉设计评审与源文件定稿 → 请走 BRD-02；产品命名/英文名确定 → 请走 BRD-01
    • 客户案例、白皮书的收集与客户授权 → 请走 BRD-15；对外口径与发布前合规自查 → 请走 BRD-14
    • 申报专用基础资料与口径 → 请走 POL-03；销售话术、标杆案例知识库 → 请走 SAL-15
    • 演示账号/演示机 → 请走 SAL-13；第三方平台账号与密码 → 请走 X-SEC-12（账号密码不进素材库）
    • 产品帮助中心与使用手册的编写 → 请走 X-PRD-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
素材库管理员 维护目录结构与标签规则、受理素材需求、入库审核、周检与月度盘点 R 品牌素材库管理员（当前：陈梦琪·推断待确认）
兜底负责人 定目录与可对外范围、裁决责任人争议、处理超时升级 A 生态市场条线负责人（当前：许君·推断待确认）
产品素材责任人 维护产品信息总表（链接、版本、介绍 topic、截图、演示视频） R 产品总监（当前：杨萌·推断待确认）
照片与荣誉素材责任人 合影、活动照片、荣誉证书、团队照片归集 R 总经办（当前：赵雪冰·推断待确认）
对外资料整理人 销售侧对外资料、渠道资料入库并标注责任人 R 销售对外资料整理人（当前：闫登辉·推断待确认）
设计素材持有人 产品高清图、渲染图、Logo 源文件按规范上传 C UI/UX 设计师（当前：康紫馨·推断待确认）
官网仓库维护 官网仓库 design-assets 与素材库同步 C 官网仓库维护研发（当前：宋祺睿·推断待确认）
新媒体素材提供 推文、视频号成品及原始素材回填 C 新媒体运营（当前：鲁周毅·推断待确认）
需求方 先自助检索，缺失时按模板提需求，用后回填新版本 I 市场/销售/申报/研发各需求人（当前：待指定）

3. 办之前请准备

  • 用途与场景：申报 / 论坛 / 官网 / 报名网站 / 折页 / 推文 / 客户演示 / 内部汇报
  • 素材类型与规格：图片（横/竖版、分辨率、是否需透明底）、视频（时长、横竖屏）、文案（topic 字数、中英文）
  • 对象产品或主体：LeapCore、LeapAll、LeapBase、工程版等；对应主体（模态、鼎慧、跃迁、跃竞）
  • 是否对外、是否需要脱敏（客户名、界面数据、内部地址）
  • 截止时间（精确到日和时段）
  • 已在素材库检索过的关键词或目录（证明已自助查找）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立唯一入口：知识库首页挂“素材库总表”，分类：产品信息/产品图与渲染图/演示视频/手册截图/Logo 与二维码/合影与荣誉/推文与案例/Q&A；每类指定责任人 素材库管理员 本 SOP 发布后 10 个工作日内完成；之后分类变更随时更新 飞书知识库、飞书云盘、多维表格 素材库总表、目录与责任人清单 🔧飞书固化
2 迁移存量：把产品信息表、PPT 素材库、Logo/二维码大全、官网仓库产品高清图、散落在群聊中的文件统一登记到总表，旧入口改为跳转链接 素材库管理员牵头，各类责任人配合 第 1 步完成后 10 个工作日内 飞书云盘、Gitea 官网仓库 去重后的素材清单、旧入口跳转说明 🔧+🤖
3 新素材入库：活动、发版、拍摄结束后，责任人上传素材并填写标签（用途、产品、主体、版本日期、可否对外、是否已脱敏、版权来源、责任人） 对应素材责任人 素材产生后 3 个工作日内 多维表格表单、飞书云盘 带标签的素材记录 🔧飞书固化
4 入库审核：检查脱敏、清晰度、命名与版本；对外类素材确认可公开 素材库管理员（对外口径存疑时找兜底负责人） 收到入库后 1 个工作日内 多维表格审核状态字段 审核通过/退回记录 👤人工判断
5 自助调取：需求方按目录或关键词检索，直接下载使用；用于对外前确认版本日期不早于产品最近一次发版 需求方 即时 飞书知识库搜索、云盘 使用记录（可选） 🤖自动化
6 缺失时提需求：填素材需求表单，系统自动生成飞书任务派给该类责任人；不在大群 @全体 找图 需求方提交，素材库管理员分派 提交后 4 个工作小时内分派 飞书表单 + 任务 + 机器人 素材需求任务 🔧飞书固化
7 补齐交付：责任人提供素材（需新做的转 BRD-13/BRD-11），交付同时回填素材库，任务挂库内链接才能关闭 对应素材责任人 常规 2 个工作日内；加急 1 个工作日内 飞书任务、云盘 入库素材 + 关闭的任务 🔧飞书固化
8 每周五过期检查：机器人推送各责任人名下“版本日期超 90 天”或“关联产品已发新版”的条目，责任人确认或更新日期 机器人发起，各素材责任人处理 每周五 16:00 推送，下周一 12:00 前处理完 多维表格自动化、飞书机器人 更新后的版本日期、过期条目清单 🔧+🤖
9 月度盘点：统计缺失类目、未响应需求、失效链接，标注责任人；下架或归档过期素材 素材库管理员，兜底负责人审阅 每月最后一个工作日 多维表格仪表盘 月度盘点表 🤖自动化

5. 交付物与模板

  • 交付物：素材库总表（唯一入口）、分类目录、素材需求任务记录、每周过期检查记录、月度盘点表
  • 建议模板/表单：
    • 素材登记表字段：素材名称、分类、产品/主体、用途标签、文件链接、格式与规格、版本日期、关联产品版本号、可否对外（是/否/需审批）、是否已脱敏、版权来源（自制/客户授权/第三方）、责任人、最近检查日期、状态（有效/待更新/已下架）
    • 素材需求表单字段：需求人、用途场景、素材类型与规格、产品/主体、是否对外、是否需脱敏、截止时间、已检索关键词、加急原因
    • 产品信息总表字段：产品名（中/英）、一句话介绍、topic（是什么/解决什么/优势）、官网与下载链接、演示视频链接、手册链接、当前版本号、更新日期、产品责任人

6. 异常与升级

  • 需求 4 个工作小时内未分派 → 需求方在任务中提醒素材库管理员 → 仍无响应升级兜底负责人（再过 4 个工作小时）
  • 责任人超时未交付 → 素材库管理员催办一次 → 超时 1 个工作日升级兜底负责人
  • 库内无现成素材且需新拍/新设计 → 转 BRD-13 或 BRD-11，并在需求任务中挂关联链接 → 截止时间不可满足时当天告知需求方与兜底负责人
  • 素材是否可对外、是否涉及客户信息拿不准 → 暂停外发，找兜底负责人确认；涉及客户案例转 BRD-15（1 个工作日内答复）
  • 发现过期或错误素材已对外使用 → 责任人 1 个工作日内更新库内版本并通知已知使用方 → 影响对外口径时升级兜底负责人并走 BRD-14
  • 发现账号、密码、内部地址被放进素材库或文档 → 素材库管理员立即删除并通知责任人 → 账号类转 X-SEC-12 登记

7. 衡量指标

  • 自助命中率：自助调取成功次数 ÷（自助成功次数 + 素材需求单数），目标 ≥ 70%
  • 素材需求交付周期：需求提交到素材入库并关闭任务的工作日，目标常规 ≤ 2 天
  • 过期素材占比：版本日期超 90 天且未确认的条目 ÷ 有效条目总数，目标 ≤ 10%
  • 周五检查完成率：当周按期处理的过期条目 ÷ 推送条目，目标 ≥ 90%
  • 群内找素材次数：业务群中“谁有…图/视频/二维码”类求助次数，目标每月 ≤ 2 次

8. 低效诊断

  • 现象：入口分散——产品信息表、PPT 素材库、压缩包、官网仓库各自维护，需求方不知道先去哪，反复“到处翻”｜依据：「【模态】业务负责人」2026-04、「跃迁AI总动员」2026-09
  • 现象：版本过期——链接与介绍被反复修改，库里不是最新版，已有周五提醒但缺少到期判断和闭环｜依据：「【模态】业务负责人」2026-05、「【模态】渠道建设」2026-07
  • 现象：求助走大群——需要图片时 @全体征集，多人同时丢图，结果未回填，下次重复征集｜依据：「跃迁AI总动员」2026-09
  • 现象：载体不统一——Q&A 写在外部工具，需二次迁到飞书云文档才进知识库｜依据：「【模态】教育业务线」2026-01
  • 现象：责任人不清——缺失资料需事后梳理再逐项标注责任人，素材维护者没有事前认领｜依据：「【模态】渠道建设」2026-07
  • 现象：脱敏与命名临时处理——对外素材在交付前才临时脱敏、临时定英文名，口径不一

9. 分支变体

  • 申报/论坛：需要“脱敏版”图片视频和统一 topic，交付前必须过脱敏检查，申报专用材料另存 POL-03
  • 官网/报名网站：优先使用官网仓库 design-assets 中的产品高清图，素材库与仓库每次更新同步
  • 客户演示/过往项目：演示视频与手册截图从产品素材类调取；涉及具体客户的项目素材需客户授权，走 BRD-15
  • 社区推广/宣讲：二维码统一在“Logo 与二维码”类维护，群二维码到期前由社区运营更新
  • 主体差异：跃竞、鼎慧等主体素材单独建子目录，Logo 与主体名称不得混用

10. 待确认问题

  • 素材库主责是否由品牌岗（报送人口径）承担，还是由当前实际归集 PPT 素材库的生态运营承担？兜底是否为生态市场条线负责人？
  • 唯一入口放飞书知识库还是飞书云盘？官网仓库 design-assets 是否继续作为设计源文件的主存储？
  • “可否对外”的判定权在谁：素材库管理员、产品经理还是兜底负责人？
  • 过期阈值 90 天是否合适？产品信息类是否改为“随发版更新”？
  • 素材需求常规 2 个工作日、加急 1 个工作日的时限是否可行？
  • 照片、荣誉素材是否继续集中在总经办？是否已有成文的素材管理制度或模板可直接复用？
  • 账号密码类信息是否已有统一的密码管理工具可承接？
BRD-18品牌舆情监测与危机公关处置待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：社交媒体、新闻媒体、开源社区、招聘平台或用户群出现针对公司、产品、高管的负面内容、事故曝光或不实信息时启动
  • 负责人：主责——品牌经理（当前：待指定）；协同——法务专员（当前：待指定）、客服/运营对接人（当前：待指定）、事件涉及部门负责人（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）
  • 核心流程：① 日常监测 → ② 发现上报 → ③ 分级研判 → ④ 事实核查 → ⑤ 口径制定与审批 → ⑥ 回应处置 → ⑦ 持续跟踪 → ⑧ 复盘归档
  • 交付结果：舆情事件登记单、经审批的对外回应口径、处置记录与复盘报告，口径沉淀进对外口径库
  • 状态依据：已有 BRD-14（对外口径与发布前合规自查）、BRD-12（媒体采访对外口径）覆盖对外口径部分环节，本条补齐负面舆情监测、分级研判与危机回应（推断）

1. 场景判定

  • 触发条件：公开平台出现负面帖子/视频/报道；用户集中投诉被曝光；产品故障、数据安全事件、招聘或员工言论引发外部讨论；出现冒用公司名义的不实信息
  • 典型说法：「外面有人在发帖说我们……」「这个帖子转得挺多的，要不要回应」「有媒体来问这件事」
  • 判断问题：是否已在公开渠道传播？是否涉及公司/产品/高管声誉？单个用户私下投诉不算，公开扩散才算
  • 不归本流程管：单个客户售后投诉 → 请走 X-CS-05；网站/产品被抄袭 → 请走 LEG-17；媒体正常采访 → 请走 BRD-12；日常对外口径与发布前自查 → 请走 BRD-14；安全漏洞技术处置 → 请走 X-SEC-41/42；叠加监管介入或重大事故的公司级危机 → 请走 CEO-25（本流程负责舆情侧执行）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌经理 监测、研判、起草口径、发布回应 R 品牌经理（当前：待指定）
品牌负责人 定级、审批一般/较大事件口径 A 品牌负责人（当前：何思雨·部门报送人）
法务 审核口径法律风险、判断是否投诉/维权 C 法务专员（当前：待指定）
涉事部门 提供事实与整改措施 C 涉事部门负责人（当前：待指定）
CEO 重大事件最终审批与对外表态 A（升级） CEO（当前：邴龙志·推断待确认）
发现人 发现即提交链接截图 R 全体员工
全员 发现即上报，不得私自回应 I 全体员工

3. 办之前请准备

  • 监测关键词清单（各主体名、产品名、高管职务、常见错写）
  • 原帖链接、截图、发布时间、传播数据（转发/评论/阅读）
  • 已有对外口径库（BRD-14）与媒体联系人清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按关键词巡检各平台，异常推送到舆情群 品牌经理 每个工作日 1 次 舆情工具/机器人 巡检记录 🤖自动化
2 员工发现即提交链接截图，不在外部评论区回应 发现人 发现后 30 分钟内 飞书表单 舆情登记 🔧飞书固化
3 按传播量、是否涉及安全/资金/客户/监管定一般/较大/重大 品牌负责人 上报后 2 小时内 多维表格 事件分级 👤人工判断
4 涉事部门核实事实与原因 涉事部门负责人 分级后 4 小时内 飞书群 事实说明 👤人工判断
5 起草回应口径，法务审核；重大事件报 CEO 品牌经理 24 小时内 飞书文档+审批 定稿口径 🔧飞书固化
6 公开回应/私下沟通/向平台投诉不实信息 品牌经理 定稿后 2 小时内 各平台 回应记录 👤人工判断
7 持续监测，每日通报进展 品牌经理 事件后 3 天 舆情群 跟踪日报 🤖自动化
8 复盘原因与整改，口径入库 品牌负责人 结束后 3 个工作日内 知识库 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：舆情登记表、回应口径、复盘报告
  • 建议模板/表单：舆情登记（平台、链接、发现时间、传播量、涉及对象、级别、处理人、状态、结论）

6. 异常与升级

  • 涉及数据泄露、监管介入或媒体追问 → 直接定为重大 → 立即报 CEO 与法务（1 小时内）
  • 升级条件：事件定为重大，或品牌负责人与涉事部门对口径有分歧 → CEO 作为 A（升级）最终审批口径与对外表态；一般/较大事件由品牌负责人审批
  • 涉事部门 4 小时内无法给出事实 → 品牌负责人发“正在核实”过渡口径 → 报 CEO

7. 衡量指标

  • 首次响应时长 = 发现到完成分级的时间，目标 ≤ 2 小时
  • 口径定稿时长 = 分级到口径审批通过，目标 ≤ 24 小时
  • 复盘完成率 = 已复盘事件 / 较大及以上事件，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在负面信息发酵无人发现、员工各自回应导致口径不一、错过最佳回应时机的风险（推断）

9. 分支变体

  • 按主体与产品线分别监测（模态、鼎慧、Leap 系列、俱乐部业务）；招聘相关舆情需 HR 协同；开源社区舆情需研究院生态协同

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 是否采购舆情监测工具，还是先用关键词机器人？
  • 一般/较大/重大的分级标准与审批人是否认可？
  • 员工个人社交账号谈及公司的规范是否需要一并出台？
BRD-19宣传素材版权与肖像授权管理待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨3 × 险4

  • 适用场景：宣传视频、推文、海报、手册、PPT 使用外部图片、字体、音乐、视频片段、AI 生成形象，或出现员工、嘉宾、学员、外部人员的肖像与声音时启动
  • 负责人：主责——品牌设计/内容专员（当前：待指定）；协同——法务专员（当前：待指定）、行政（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）
  • 核心流程：① 素材来源登记 → ② 版权核查 → ③ 肖像/声音授权签署 → ④ AI 生成内容审核 → ⑤ 发布前清单核对 → ⑥ 授权归档 → ⑦ 到期/撤回下架
  • 交付结果：带来源与授权信息的素材台账、已签署的肖像/声音授权书、发布前核对记录
  • 状态依据：已有 BRD-15（客户案例授权核查）、BRD-14（发布前第三方标识自查）覆盖部分环节，本条补齐外部素材版权与人物肖像/声音授权管理（推断）

1. 场景判定

  • 触发条件：使用非自制的图片/字体/音乐/视频；拍摄或使用人物形象与声音；AI 生成真人风格形象或数字人
  • 典型说法：「这张图网上找的能用吗」「这个字体可以商用吗」「视频里拍到了学员，要不要打码」
  • 判断问题：素材是不是我方自制？出现的人是否同意过？对外发布还是仅内部使用？
  • 不归本流程管：客户案例与客户 Logo 授权 → 请走 BRD-15；发布前品牌用语与竞品/第三方标识自查 → 请走 BRD-14；产品内置字体/素材版权 → 请走 LEG-19；拍摄接待 → 请走 BRD-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌设计/内容专员 登记来源、核查授权、收集授权书 R 品牌设计/内容专员（当前：待指定）
品牌负责人 发布前把关 A 品牌负责人（当前：何思雨·部门报送人）
法务 提供授权书模板、判断争议素材 C 法务专员（当前：待指定）
活动/拍摄组织方 现场收集授权或告知 R 活动负责人（当前：待指定）

3. 办之前请准备

  • 素材来源链接与许可类型（商用/署名/禁止商用）
  • 肖像/声音授权书模板（法务出具，含用途、渠道、期限、撤回方式）
  • 公司已采购的图库、字体、音乐授权清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 素材入库时登记来源、许可类型、到期日 内容专员 入库当天 多维表格素材库 素材台账 🔧飞书固化
2 核查是否可商用，不可用的替换为已授权素材 内容专员 制作前 图库/字体授权清单 核查结论 👤人工判断
3 拍摄前签授权书；活动现场张贴拍摄告知 活动负责人 拍摄前 电子签/纸质 授权书 🔧飞书固化
4 AI 生成人物形象检查是否近似真人/名人，按规定加 AI 生成标识 内容专员 发布前 人工检查 审核记录 👤人工判断
5 发布前按清单核对（来源、授权、未授权人员打码） 品牌负责人 发布前 1 个工作日 发布检查单 核对记录 🔧飞书固化
6 授权书扫描件挂到素材台账 内容专员 签署后 3 个工作日内 素材库 归档 🔧飞书固化
7 授权到期或本人撤回时下架并替换 内容专员 收到通知后 3 个工作日内 各平台 下架记录 🤖自动化（到期提醒）

5. 交付物与模板

  • 交付物：素材授权台账、授权书档案
  • 建议模板/表单：素材台账字段（素材名、来源、许可类型、可用渠道、到期日、授权书附件、使用位置）

6. 异常与升级

  • 收到版权方/个人侵权通知 → 当天下架 → 报法务与品牌负责人（1 个工作日内）
  • 已离职员工要求撤下形象 → 3 个工作日内评估并下架

7. 衡量指标

  • 素材授权登记率 = 已登记来源的对外素材 / 对外发布素材，目标 100%
  • 侵权投诉次数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在使用网络图片/字体被索赔、拍摄人员未授权引发纠纷、AI 生成形象涉及肖像权的风险（推断）

9. 分支变体

  • 培训班/大会学员肖像：报名环节统一告知并取得同意；未成年人形象一律不用

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 公司已购买哪些图库、字体、音乐授权？
  • 员工肖像使用是否在入职协议中统一授权，离职后如何处理？
BRD-20合作方联合宣发与公司品牌授权使用待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：渠道、生态伙伴、芯片/信创厂商、高校、政府平台要联合发稿、在其宣传中使用公司名称/Logo/产品名，或我方宣传中提及对方时启动
  • 负责人：主责——品牌经理（当前：待指定）；协同——业务对接人（当前：待指定）、法务专员（当前：待指定）；兜底——品牌负责人（当前：何思雨·部门报送人）
  • 核心流程：① 受理申请 → ② 品牌规范审核 → ③ 合作事实确认 → ④ 法务审核 → ⑤ 双方稿件互审 → ⑥ 发布监测 → ⑦ 授权登记 → ⑧ 合作终止撤下
  • 交付结果：双方确认的联合稿件/物料、品牌使用授权记录（范围、期限）
  • 状态依据：已有 BRD-09（事件型宣发稿，含厂商联合发布）、X-DLV-25（信创厂商联合宣发）覆盖部分环节，本条补齐合作方使用我方品牌的授权审核与授权台账（推断）

1. 场景判定

  • 触发条件：对方索要我方 Logo、产品图；对方稿件提及“与模态合作/战略合作/已完成适配”；我方稿件使用对方名称与 Logo
  • 典型说法：「合作方要发个新闻，用我们 Logo 行不行」「他们稿子里写的是战略合作，可以吗」
  • 判断问题：是否有书面合作关系？表述是否超出实际合作内容？
  • 不归本流程管：渠道代理授权协议 → 请走 SAL-27；我方自己的事件稿（含我方主笔的厂商联合发布稿）→ 请走 BRD-09；信创适配状态与厂商协同口径 → 请走 X-DLV-25；商标注册 → 请走 LEG-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
品牌经理 受理、审核用法、互审稿件、登记 R 品牌经理（当前：待指定）
业务对接人 确认合作事实、对接对方 C 业务对接人（当前：待指定）
法务 审核合作表述与授权范围 C 法务专员（当前：待指定）
品牌负责人 批准授权 A 品牌负责人（当前：何思雨·部门报送人）

3. 办之前请准备

  • 对方稿件/物料初稿、发布渠道与时间
  • 双方合作协议或合作确认邮件
  • 公司 VI 规范与 Logo 标准文件（BRD-02）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 业务对接人提交授权/联合宣发申请 业务对接人 发布前至少 5 个工作日 飞书审批 申请单 🔧飞书固化
2 审核 Logo 用法、产品名、品牌用语 品牌经理 1 个工作日内 VI 规范 修改意见 🤖+👤（AI 初查用语）
3 确认“合作/适配/认证”等表述与事实一致 业务对接人 1 个工作日内 合作协议 事实确认 👤人工判断
4 审核“战略/独家/首家”等措辞与授权范围 法务 2 个工作日内 飞书审批 法务意见 👤人工判断
5 双方稿件互审定稿 品牌经理 发布前 1 个工作日 飞书文档 定稿 👤人工判断
6 发布后检查对方实际发布内容 品牌经理 发布当天 各平台 截图存档 👤人工判断
7 登记授权范围、期限、物料 品牌经理 发布后 2 个工作日内 多维表格 授权台账 🔧飞书固化
8 合作终止时通知对方撤下我方标识 品牌经理 终止后 10 个工作日内 邮件 撤下确认 🤖自动化（到期提醒）

5. 交付物与模板

  • 交付物：联合稿件定稿、品牌授权台账
  • 建议模板/表单：授权申请（合作方、用途、渠道、素材、期限、合作依据、业务对接人）

6. 异常与升级

  • 发现对方未经授权使用或表述失实 → 品牌经理 1 个工作日内要求更正 → 拒不更正报法务

7. 衡量指标

  • 联合宣发事前审核率 = 走审批的联合宣发 / 全部联合宣发，目标 100%
  • 授权台账更新及时率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在合作方夸大合作关系、Logo 误用、合作结束后仍挂我方标识的风险（推断）

9. 分支变体

  • 政府/平台方宣传：以对方口径为主，我方只核事实与产品名；信创适配宣发须研发确认适配口径（X-DLV-25）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 5 个工作日提前量对业务是否可行？
  • 是否需要标准《品牌使用授权函》模板？

POL 政策申报

报送人：王蕊 · 生态市场条线 · 14 条 · 已有 0 / 待优化 3 / 待新建 11
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
POL-01政策与补贴线索收集研判及申报决策任何人看到或收到政府补贴、扶持政策、人才、就业社保类政策信息时，统一登记进政策线索库，在限定时间内完成适用性初判、决定是否申报及由谁牵头主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总经办专员（当前：王欣·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 线索登记 → ② 去重与 AI 摘要 → ③ 按主体初判适用性 → ④ 分级 P0/P1/P2 → ⑤ 申报决策 → ⑥ 转申报台账并建任务 → ⑦ 放弃/暂缓留痕 → ⑧ 周推送与月复盘政策线索库中每条线索都有结论（申报/放弃/暂缓+复查日），申报项已指定牵头人和截止日并转入申报台账待新建72
POL-02政府部门日常对接与机构设立事项经信局、科创局、财政局等政府部门提出推广、客户清单、标杆案例、繁星计划推进、大会或比赛安排，或公司需新设研究院等机构挂牌时，确定唯一对接人、准备并审核材料、跟进到落地主责——生态市场条线负责人（当前：许君·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、COO（当前：常元和·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 事项登记 → ② 指定唯一对接人 → ③ 确认流程与材料 → ④ 材料编制与脱敏审核 → ⑤ 重大事项决策 → ⑥ 递交与周跟进 → ⑦ 结果归档 → ⑧ 活动复盘政府事项台账中每件事都有对接人、材料清单、进度和结果；机构设立类形成批复/挂牌文件与协议，均已归档待新建240
POL-03申报基础资料库与口径维护各类申报、平台入驻、监管征集、外部核查需要公司基础信息、资质证书、知识产权、人员社保、产品信息、财务口径、历史案例或平台账号时，从统一资料库调取；库里没有的，按固定口径人确认后回写主责——总经办专员（当前：王欣·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建库分工 → ② 填表先查库 → ③ 未命中提口径请求 → ④ 按类别找口径人确认 → ⑤ 回写入库 → ⑥ 人员资格匹配 → ⑦ 有效期与离职预警 → ⑧ 季度更新一套按主体维护的申报资料库（基础信息、资质、知识产权、荣誉、产品、人员资格、财务口径、平台账号索引、案例、历史申报书），每个字段有口径来源和确认人待新建240
POL-04科技项目申报（市/省重点研发、OPC 专项、联合申报）科技局、科技厅、区级部门发布科技项目申报通知，且已决定申报（来自 POL-01）后，从资格核对、牵头主体与负责人确定、分工撰写，到提交、退回修改和结果归档的全过程主责——政策申报专员（当前：王蕊·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、技术配合人（当前：黄振锋·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政专员（当前：侯明月·推断待确认）、CEO（当前：邴龙志·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 立项 → ② 资格条件检查 → ③ 定牵头主体/负责人/方向/金额 → ④ 联合申报协议 → ⑤ 组建写作组与倒排 → ⑥ 撰写与内审 → ⑦ 盖章提交 → ⑧ 退回修改 → ⑨ 结果归档与验收跟踪按时提交的申报书及附件、平台提交回执；退回意见处理记录；立项后的任务书与验收指标进入跟踪待优化500
POL-05人才计划与赛事类申报收到人才计划（招才局、光谷 3551、青年拔尖人才、卓越工程师等）或 AI 大赛申报通知，需要确定推荐人选、评估个人与公司风险、收集个人和项目材料并提交主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、总经办专员（当前：王欣·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 政策解读 → ② 候选人初筛 → ③ 风险评估 → ④ 人选决策 → ⑤ 本人确认 → ⑥ 一次性列清单收材料 → ⑦ 填报审稿 → ⑧ 盖章提交 → ⑨ 结果与后续义务跟踪已提交的人才/赛事申报材料、人选决策记录、本人确认记录、后续义务（承诺期、考核、拨付）跟踪表待新建96
POL-06申报佐证材料（测试/检测/验收报告、指标对比）编制产品认证、成果推荐、科技项目申报或验收、合作方政府项目需要技术指标对比表、测试报告、验收报告、检测报告、安全评测调研表时，基于真实测试结果出具或委托检测，并沉淀为可复用的申报材料包主责——政策申报专员（当前：王蕊·推断待确认）；协同——研发报告编制人（当前：马漳毓·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 需求登记 → ② 查材料包 → ③ 获取对方标准 → ④ 指标表初稿与专业化 → ⑤ 基于真实测试出报告 → ⑥ 真实性与合规审核 → ⑦ 定稿交付 → ⑧ 入材料包经 CTO 审定、基于真实测试记录的报告/指标表，并以版本、有效期、适用范围登记在申报材料包中待新建90
POL-07补贴申领资料归集（上云补贴等）已决定申领上云补贴、上云服务券等费用类补贴后，按主体归集云服务商、上云时间、年消费额、发票、消费主体、消耗记录并提交主责——政策申报专员（当前：王蕊·推断待确认）；协同——云资源管理人（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 确认申领条件 → ② 发起按主体的归集清单 → ③ 导出云账号与账单 → ④ 核对发票与付款 → ⑤ 判断主体一致性 → ⑥ 整理提交 → ⑦ 跟踪拨付入账按主体整理好的补贴申领材料包（云服务清单、账单、发票、付款凭证、消耗记录）与提交回执，补贴到账后入账待新建36
POL-08周期性政府报表与年检填报工信部软件和信息技术服务业月报/年报、LEI 续期、研究院年检等周期性填报到期时，按日历提醒、准备数据、填报、审核并留档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建报表日历 → ② 截止前提醒 → ③ 准备数据 → ④ 口径核对 → ⑤ 填报 → ⑥ 审核 → ⑦ 提交留档 → ⑧ 更新下期按期提交的报表或年检材料、提交截图/回执、数据底稿，报表日历更新到下一期待新建36
POL-09行业/团体标准参编与编制外部机构发起行业标准/团体标准参编征集，或公司受邀、拟牵头编制团体标准时，从评估是否参编到按分工完成稿件提交的全过程主责——标准项目牵头人（当前：吴琪·推断待确认）；协同——技术协调人（当前：杨萌·推断待确认）、技术编写人（当前：郭逸非、黄飞鹏·推断待确认）、外部渠道对接人（当前：李鹏为·推断待确认）、技术评估人（当前：李子遥·推断待确认）、终审人 CTO（当前：丁震宇·推断待确认）、参编决策人 CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 登记标准机会 → ② 核实参编条件 → ③ 评估资质与投入 → ④ 管理层决策（参编/联合/放弃）并指定牵头人 → ⑤ 建群、领分工与模板、开大纲会 → ⑥ AI 起草 + 多模型交叉审 → ⑦ 内部终审 → ⑧ 提交、归档并跟踪发布参编决策记录；按分工完成并经终审的标准章节/附件（docx）及提交回执；「政策/标准机会池」记录更新待新建120
POL-10软件著作权申请与权属确认产品或平台上线、需要证明权属、软件退税或政策申报需要软著时，先确定著作权人（申报主体）、费用承担与合作方关系，再完成材料、盖章、代理提交和取证主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——材料撰写人（各产品线，当前：韩诗琪、葛家和、陈梦琪·推断待确认）、技术与权属把关（当前：丁震宇·推断待确认）、主体与退税判断（当前：常元和·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、盖章环节（当前：杨萌、黄飞鹏·推断待确认）、外部代理机构；兜底——CEO（当前：邴龙志·推断待确认）① 立项登记 → ② 权属确认（著作权人、费用、合作方）→ ③ 按模板写材料包 → ④ 总经办初审 → ⑤ 代理复核 → ⑥ 选对主体用印 → ⑦ 提交缴费 → ⑧ 取证登记并通知登记在正确主体名下的软件著作权登记证书，及知识产权台账中的完整记录（名称、主体、版本、状态、证书号、对接人）待优化192
POL-11专利申报（交底→技术审核→代理撰写→定稿→缴费）研发产生可申请专利的技术方案、核心功能被抄袭需要保护，或公司要求在政策/人才申报前集中出专利时，从技术交底到代理撰写、定稿、缴费完成专利申请提交主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——技术审核（当前：丁震宇·推断待确认）、发明人（各研发组，当前：季学森、宋祺睿·推断待确认）、提案人（当前：杨萌·推断待确认）、专利转让与商务对接（当前：常元和·推断待确认）、外部专利代理机构；兜底——CEO（当前：邴龙志·推断待确认）① 技术成果登记提案 → ② 按模板写交底书 → ③ 内部技术审核（可专利性、泄密、合并/舍弃）→ ④ 邮件提交代理并抄送总经办 → ⑤ 代理撰写初稿 → ⑥ 发明人核稿定稿 → ⑦ 递交与缴费 → ⑧ 台账更新转入审查跟进已递交并取得受理号的专利申请、经内审的交底书、专利台账记录（案号、名称、发明人、状态、下一步责任人、截止日）待优化135
POL-14企业资质认定与年度维护（高新技术企业、科技型中小企业、专精特新等）各主体的企业资质临近到期、年度评价窗口开放，或新主体满足认定条件时启动主责——政策申报专员（当前：待指定）；协同——财务（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）、法务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 建资质日历 → ② 条件自评 → ③ 差距补足 → ④ 材料编制与专项审计 → ⑤ 内审用印 → ⑥ 提交跟踪 → ⑦ 证书入库与优惠落地 → ⑧ 年报与变更报告按期取得/保持的资质证书、年度报告回执、资质日历与资质库更新待新建200
POL-15获批项目执行、专项资金使用与验收结题科技项目、补贴、资助或券类项目获批立项后，至验收结题与事后抽查的全周期主责——项目负责人（当前：待指定）；协同——政策申报专员（当前：待指定）、财务（当前：待指定）、研发（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 签任务书建台账 → ② 设专账 → ③ 资金到账入账 → ④ 按预算执行 → ⑤ 季度跟踪 → ⑥ 中期检查/变更申请 → ⑦ 验收结题 → ⑧ 档案留存项目台账、专项资金辅助账、中期与验收材料、结题证书/验收意见、完整项目档案待新建160
POL-16申报代理/中介机构选用与服务管理决定委托外部机构代办资质认定、项目申报、人才申报、软著/专利或补贴申领，或外部机构主动推销代办服务时启动主责——政策申报专员（当前：待指定）；协同——法务专员（当前：待指定）、财务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）① 自办/委托判断 → ② 机构资质核查 → ③ 比价选择 → ④ 合同审核 → ⑤ 材料提供与保密 → ⑥ 过程审核 → ⑦ 按结果付款 → ⑧ 年度评价合格机构名录、经法务审核的服务合同、服务评价记录待新建48
POL-01政策与补贴线索收集研判及申报决策待新建72

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：任何人看到或收到政府补贴、扶持政策、人才、就业社保类政策信息时，统一登记进政策线索库，在限定时间内完成适用性初判、决定是否申报及由谁牵头
  • 负责人：主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总经办专员（当前：王欣·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 线索登记 → ② 去重与 AI 摘要 → ③ 按主体初判适用性 → ④ 分级 P0/P1/P2 → ⑤ 申报决策 → ⑥ 转申报台账并建任务 → ⑦ 放弃/暂缓留痕 → ⑧ 周推送与月复盘
  • 交付结果：政策线索库中每条线索都有结论（申报/放弃/暂缓+复查日），申报项已指定牵头人和截止日并转入申报台账
  • 状态依据：线索全靠群友偶然转发文章或政府宣传短信，2026-02 至 2026-09 至少 3 次出现“我们能申请吗”“要找谁问”后无登记、无责任人、无截止日；“年后再研究”后无下文；政策资讯机器人仅停留在提议

1. 场景判定

  • 触发条件：看到政府官网、公众号、政府工作群、外部申报机构推送的补贴/扶持/人才/就业社保/算力/上云类政策；或员工收到政府宣传短信
  • 典型说法：「我们能申请吗」「等年后再研究一下政策」「@人事 研究一下」「要找 HR 问，然后可能要去线下申报」
  • 判断问题：这条信息是否涉及公司（或某个主体、某类员工）可能拿到的资金、资质、荣誉或政策待遇？是否还没进入线索库？
  • 不归本流程管：已决定申报的科技项目 → 请走 POL-04；人才计划与赛事 → 请走 POL-05；上云补贴等费用类补贴资料归集 → 请走 POL-07；周期性报表与年检 → 请走 POL-08；政府部门提出的具体工作要求（客户清单、标杆、大会）→ 请走 POL-02；外部合作/政府需求线索的分派 → 请走 MKT-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 维护线索库、摘要、初判、分级、提报决策、立项建任务 R 政策申报专员（当前：王蕊·推断待确认）
生态市场条线负责人 审核初判与分级，P1/P2 可直接定夺，P0 提报 CEO；超期兜底 A 生态市场条线负责人（当前：许君·推断待确认）
CEO P0 及涉及新设主体、人员承诺、配套资金的申报决策 A（升级） CEO（当前：邴龙志·推断待确认）
CTO 技术类、算力类政策的业务匹配判断 C CTO（当前：丁震宇·推断待确认）
财务负责人 纳税地、营收、费用类条件核对 C 财务负责人（当前：黄梦婷·推断待确认）
人事负责人 就业、社保、人才类条件核对，线下窗口办理 C 人事负责人（当前：黄莹·推断待确认）
总经办专员 政策资讯/答疑机器人搭建与周推送 R（机器人） 总经办专员（当前：王欣·推断待确认）
全员 发现政策后提交表单 I 各部门

3. 办之前请准备

  • 政策原文链接或截图（不要只转二手解读）、发布单位、截止日期（可见时）
  • 各主体基本条件速查（注册地、纳税地、行业分类、规模、已有资质、社保人数）——从 POL-03 资料库调取
  • 已有政策线索库，避免重复登记
  • 不确定条款先记下问题，统一由政策申报专员致电主管部门核实

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“政策线索”表单：来源、链接、发布单位、截止日、可能适用主体 发现人（任何员工） 看到当天 飞书表单→多维表格 线索记录 🔧飞书固化
2 去重；AI 摘要条款（对象、条件、支持方式、材料、申报方式线上/线下、截止） 政策申报专员 登记后 1 个工作日内 多维表格+AI 政策摘要 🤖自动化
3 按主体（模态/鼎慧/跃迁/苏州等）逐项比对条件，缺数据向财务/人事/CTO 取数；条款歧义致电主管部门核实 政策申报专员 登记后 3 个工作日内；截止 ≤ 10 天的 1 个工作日内 多维表格+POL-03 资料库 初判结论（符合/部分符合+缺口/不符合） 👤人工判断
4 分级：P0=有资金且符合、截止 ≤ 30 天；P1=有资金需补条件或资质荣誉类；P2=观察 政策申报专员 与步骤 3 同日 多维表格 优先级 🔧+👤
5 申报决策：是否申报、申报主体、牵头人；涉及新设主体、个人承诺、配套资金的必须 CEO 拍板 生态市场条线负责人提报，CEO 决策 初判后 2 个工作日内 飞书审批 决策记录 👤人工判断
6 申报项转入申报台账，建飞书任务并倒排里程碑，按类型转 POL-04/05/07 政策申报专员 决策当天 多维表格+飞书任务 申报任务 🔧飞书固化
7 放弃或暂缓的写明原因；暂缓必须填具体复查日期，到期自动提醒 政策申报专员 决策当天 多维表格提醒 放弃/暂缓记录 🔧飞书固化
8 机器人每周一推送新增线索、7 天内截止项；高频问答沉淀进答疑机器人 总经办专员 每周一 10:00 前 飞书机器人 周推送 🤖自动化
9 月度复盘：线索数、申报数、获批数、错过数及原因 政策申报专员 每月第 1 周 多维表格仪表盘 月度复盘表 🔧+🤖

5. 交付物与模板

  • 交付物：政策线索库记录、政策摘要、初判结论、决策记录、申报任务、月度复盘表
  • 建议模板/表单：
    • 政策线索表字段：线索编号、政策名称、发布单位、来源链接、政策类别（AI/OPC、算力、上云、人才、就业社保、资质荣誉）、支持方式、申报条件、所需材料、申报方式（线上/线下）、截止日期、适用主体、初判结论、缺口、优先级、决策结论、牵头人、复查日期、状态
    • 初判检查项：注册地/纳税地、行业分类、企业规模、所需资质、人员社保条件、是否需新设主体、是否需配套资金

6. 异常与升级

  • 升级条件：P0 级政策，或申报涉及新设主体、人员承诺、配套资金时，由 CEO 拍板（A（升级））；P1/P2 由生态市场条线负责人直接定夺
  • 发现时距截止 ≤ 5 个工作日 → 政策申报专员当天完成初判 → 升级生态市场条线负责人当天决定是否加急
  • 需新设主体（如个体户、新公司）才能申报 → 不得自行办理 → 升级 CEO（2 个工作日内决策）
  • 需线下窗口办理或个人出面 → 人事负责人确认办理人和日期 → 无人承接时升级生态市场条线负责人（1 个工作日内）
  • 初判超 3 个工作日未完成 → 机器人提醒 → 兜底人接手并当天指定处理人
  • 同一政策多人重复转发 → 只保留一条线索，其余补充到该线索备注

7. 衡量指标

  • 初判及时率 = 3 个工作日内完成初判的线索 / 登记线索，目标 ≥ 90%
  • 线索闭环率 = 有明确结论（含暂缓复查日）的线索 / 全部线索，目标 100%
  • 错过窗口数 = 判定符合但因未及时处理错过截止的政策数，目标 0
  • 申报转化率 = 决定申报数 / P0+P1 线索数，按月观察

8. 低效诊断

  • 线索入口分散：政策靠群内转发文章、政府宣传短信，没有统一登记口，也没有按主体的条件速查｜依据：「鸽子群模态分群」2026-02、「跃迁AI总动员」2026-09
  • 研判没有责任人和截止日：问“能不能申请”后仅口头回复“年后再研究”，之后无记录｜依据：「鸽子群模态分群」2026-02
  • 申领路径不清：就业补贴类不知该找人事还是去线下窗口｜依据：「鸽子群模态分群」2026-08
  • 同类问题反复问、无沉淀：政策资讯机器人已提议但未落地｜依据：「董事会专项沟通群」2026-08

9. 分支变体

  • AI/OPC 补贴、算力服务费补助：先确认申报主体形态要求，可能需特定主体才可申报，由 CEO 决策
  • 人才房补、人才计划：涉及个人，转 POL-05
  • 吸纳就业、社保扩围：人事负责人主导，常需线下办理
  • 上云补贴：转 POL-07
  • 主体差异：模态、鼎慧、跃迁、苏州主体分别判定；纳税地不在政策所在地的主体通常难享受地方政策

10. 待确认问题

  • 线索库主责是政策申报专员，还是总经办专员？
  • 初判 3 个工作日、决策 2 个工作日是否可行？
  • P1/P2 是否授权生态市场条线负责人直接决定，只有 P0 报 CEO？
  • 政策资讯/答疑机器人由谁负责搭建，计划何时上线？是否接入已有的政策追踪 skill 自动抓取？
  • 外部申报机构推送的线索，是否也必须先进线索库再对接？
POL-02政府部门日常对接与机构设立事项待新建240

状态：待新建｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：经信局、科创局、财政局等政府部门提出推广、客户清单、标杆案例、繁星计划推进、大会或比赛安排，或公司需新设研究院等机构挂牌时，确定唯一对接人、准备并审核材料、跟进到落地
  • 负责人：主责——生态市场条线负责人（当前：许君·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、COO（当前：常元和·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 事项登记 → ② 指定唯一对接人 → ③ 确认流程与材料 → ④ 材料编制与脱敏审核 → ⑤ 重大事项决策 → ⑥ 递交与周跟进 → ⑦ 结果归档 → ⑧ 活动复盘
  • 交付结果：政府事项台账中每件事都有对接人、材料清单、进度和结果；机构设立类形成批复/挂牌文件与协议，均已归档
  • 状态依据：对接全靠个人，同一部门对接人在人事与行政间多次转手、联系人和群靠转发；对外汇报材料未经审核出现客户信息外露风险；申报、宣发“临时写稿”

1. 场景判定

  • 触发条件：政府部门要求提供客户清单、标杆案例、采访对象、参加活动/大会/比赛；繁星计划、补贴券、数转补贴等推进对接；新设研究院、研究中心等需政府挂牌或审批
  • 典型说法：「把近期签约的客户整理一个表给到他这里」「需要先跟科创局的人一起去社会事务局确定一下流程和材料」「宣发不能临了到哪就到哪临时写稿子，申报也是」「两边不冲突，是两件事」
  • 判断问题：对方是不是政府部门或其授权机构？是否需要我方出材料、出人或签文件？
  • 不归本流程管：高层汇报演示与政策风险应对 → 请走 CEO-17；政府领导来访接待 → 请走 GEN-16；补贴/科技项目正式申报 → 请走 POL-01、POL-04；外部线索分派 → 请走 MKT-12；合作协议审查 → 请走 LEG-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
生态市场条线负责人 政府事项归口，指定对接人，审核对外材料口径 A 生态市场条线负责人（当前：许君·推断待确认）
产业部门对接人 经信局、商务类部门日常对接，繁星计划、补贴券、数转推进 R 销售负责人（当前：李鹏为·推断待确认）；执行：销售骨干（当前：闫登辉·推断待确认）
机构设立对接人 科创局、社会事务局等机构设立手续、材料递交 R 行政专员（当前：侯明月·推断待确认）
人事负责人 机构设立涉及人员材料，交接前的首轮手续 C 人事负责人（当前：黄莹·推断待确认）
CEO 挂牌、联合机构、站队与利益协调、大会/比赛是否参加的决策；兜底 A（升级） CEO（当前：邴龙志·推断待确认）
COO 合作协议推进节奏与对外口径 C COO（当前：常元和·推断待确认）
苏州销售负责人 苏州及高校合作研究中心协议推进 R（该分支） 苏州销售负责人（当前：刘昱潇·推断待确认）
法务负责人 协议、承诺函审核 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 对方部门、对接人、联系方式（录入台账，不靠转发名片）、对方要求和截止日
  • 机构设立：发起人给出的设立方案文档、主体选择、拟挂牌名称、需要我方出资或人员的信息
  • 对外材料：已授权可公开的客户名单与案例（查 BRD-15 授权记录）、统一公司介绍
  • 参会/比赛：活动目标、预计投入、往期同类活动获客质量

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记政府事项台账：部门、对方对接人、事项、截止、我方首个接触人 首个接触人 接到当天 多维表格 事项记录 🔧飞书固化
2 指定唯一对接人：产业部门→产业部门对接人；机构设立→机构设立对接人；正式申报→政策申报专员；对方联系方式和对接群在台账登记 生态市场条线负责人 登记后 1 个工作日内 多维表格 对接人 👤人工判断
3 向对方确认流程、材料清单、办理窗口和时间节点；机构设立类先与主管部门共同确认 对接人 指定后 3 个工作日内 电话/拜访纪要 材料清单与节点 👤人工判断
4 编制材料；客户清单、案例、汇报稿只放授权可公开信息，客户用代称或经授权的名称 对接人 对方截止前 3 个工作日完成初稿 飞书文档 材料初稿 🔧+🤖
5 口径与脱敏审核；涉及协议、承诺函的同步法务 生态市场条线负责人、法务负责人 初稿后 1 个工作日内 飞书文档评论 审定稿 👤人工判断
6 重大事项报 CEO：挂牌、联合机构、出资、对方内部意见分歧、是否参加大会/比赛 生态市场条线负责人 发现后 1 个工作日内 飞书审批 决策记录 👤人工判断
7 递交材料，每 5 个工作日跟进一次并更新台账状态 对接人 递交后持续 多维表格提醒 进度记录 🔧飞书固化
8 对接人变更：一次性移交联系人、对接群、材料、进度，交接后在台账改人 原对接人 变更当天 交接清单 交接记录 🔧飞书固化
9 结办归档：批复、牌匾照片、协议、纪要归档 对接人 结办后 3 个工作日内 飞书云盘（GEN-11） 归档记录 🔧飞书固化
10 参加政府组织活动后回收线索与获客质量，评估是否继续参加同类活动 产业部门对接人 活动后 3 个工作日内 多维表格 活动复盘 👤人工判断

5. 交付物与模板

  • 交付物：政府事项台账、材料清单、审定材料、决策记录、交接清单、批复/协议/纪要归档
  • 建议模板/表单：
    • 政府事项台账字段：事项编号、部门、对方对接人、事项类型（推广/名单/标杆/采访/活动/机构设立/协议）、我方对接人、材料清单、对外材料审核人、截止日、状态、下次跟进日、结果、归档链接
    • 机构设立材料包：设立方案、主体资料、场地证明、拟任负责人材料、章程/协议草案、主管部门确认的清单

6. 异常与升级

  • 升级条件：涉及挂牌、联合机构设立、对外站队与利益协调、是否参加政府大会/比赛时，由 CEO 拍板（A（升级））；日常对接与材料口径由生态市场条线负责人拍板
  • 对方索要甲方信息、合同金额等敏感内容 → 暂停提供 → 升级生态市场条线负责人（1 个工作日内）判断，必要时征求客户授权
  • 对方部门内部意见不一，需要我方表态 → 对接人不表态 → 升级 CEO（2 个工作日内）
  • 对接人离岗或转岗未交接 → 兜底人当天指定新对接人并收回联系人与群
  • 合作方审合同周期过长、影响节点 → 按里程碑拆分并行事项 → 升级 COO（每 2 周汇报一次）
  • 补贴口径变化 → 当天同步 POL-01 线索库和销售团队

7. 衡量指标

  • 对接人指定及时率 = 1 个工作日内指定对接人的事项 / 全部事项，目标 100%
  • 对外材料审核覆盖率 = 经审核后递交的材料 / 递交材料，目标 100%
  • 事项按期办结率 = 在约定节点前办结 / 已到期事项，目标 ≥ 85%
  • 对接人变更交接完整率 = 有交接清单的变更 / 对接人变更次数，目标 100%

8. 低效诊断

  • 机构设立对接人在人事与行政间转手，联系人和对接群靠转发：“推给我一下，包括该加的群”｜依据：「行政人事对接群」2026-02
  • 对外汇报材料未经口径审核，存在客户信息外露风险；政府组织活动来的客群不匹配，事前未评估｜依据：「【模态】市场销售」2026-08
  • 申报、宣发没有体系，临时写稿，谁来做申报不清楚｜依据：「【跃迁】合伙人会议」2026-03、「【跃迁】高管群」2026-03
  • 联合研究中心是否合并推进意见不一，合作方审合同慢，没有决策与里程碑机制｜依据：「苏州模态跃迁」2026-07

9. 分支变体

  • 繁星计划、补贴券、数转补贴：由产业部门对接人推进，客户清单需授权核查
  • 比赛、办会、大会安排：先评估投入与获客，CEO 决策是否参加，执行转 ECO-12
  • 研究院等机构设立挂牌：先与科创局、社会事务局确认流程与材料，由机构设立对接人办理
  • 与高校设立联合研发中心：区分双方协议与三方协议，两件事分别立项，协议走 LEG-04
  • 知识产权申报类事项：转 POL-10、POL-11

10. 待确认问题

  • 政府事务归口是否为生态市场条线负责人？产业部门由销售负责人对接是否保留？
  • 机构设立由行政专员对接是否确定？人事负责人是否退出该事项？
  • 对外材料的审核人是生态市场条线负责人还是 CEO？
  • 政府事项台账与 CEO-17 是否合并为同一张表？
POL-03申报基础资料库与口径维护待新建240

状态：待新建｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：各类申报、平台入驻、监管征集、外部核查需要公司基础信息、资质证书、知识产权、人员社保、产品信息、财务口径、历史案例或平台账号时，从统一资料库调取；库里没有的，按固定口径人确认后回写
  • 负责人：主责——总经办专员（当前：王欣·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 建库分工 → ② 填表先查库 → ③ 未命中提口径请求 → ④ 按类别找口径人确认 → ⑤ 回写入库 → ⑥ 人员资格匹配 → ⑦ 有效期与离职预警 → ⑧ 季度更新
  • 交付结果：一套按主体维护的申报资料库（基础信息、资质、知识产权、荣誉、产品、人员资格、财务口径、平台账号索引、案例、历史申报书），每个字段有口径来源和确认人
  • 状态依据：每次申报都在群里问“这个数据谁有”，同一批数据（资质、实缴、专利数、工商变更）被反复追问；历史申报书经手人离职后需追终版；申报负责人离职或社保月数不足导致申报失败

1. 场景判定

  • 触发条件：填写申报书、平台入驻表、工信部年报、产品登记表、外部资质征集表、高企/备案核查材料时，需要公司或产品的基础数据和证明
  • 典型说法：「这个数据谁有」「公司成立以来的工商变更登记情况找谁」「你的公司有没有省部级及以上研发平台？」「申请软著，系统需要一个管理人，谁的社保在该主体」
  • 判断问题：要填的是不是“公司/产品/人员的既有事实”？是否会被多个申报重复使用？
  • 不归本流程管：具体科技项目申报组织 → 请走 POL-04；测试/验收报告编制 → 请走 POL-06；荣誉与宣传素材对外使用 → 请走 GEN-13；证照原件借用 → 请走 LEG-10；人事档案 → 请走 HR-28；工商变更办理 → 请走 FIN-38

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
总经办专员 建库、维护、回写、有效期预警、季度更新 R 总经办专员（当前：王欣·推断待确认）
综合部负责人 资料库验收、法定信息与档案确认；兜底 A 综合部负责人（当前：赵雪冰·推断待确认）
政策申报专员 查库取用、提口径请求、登记材料去向 R（使用） 政策申报专员（当前：王蕊·推断待确认）
COO 收入、财务类口径唯一确认人 C COO（当前：常元和·推断待确认）
CTO 产品负责人、开发完成日期、技术与案例口径 C CTO（当前：丁震宇·推断待确认）
财务负责人 实缴、营收、研发费用、技术合同收入数据 C 财务负责人（当前：黄梦婷·推断待确认）
人事负责人 各主体社保名单与月数、学历职称（受限字段） C 人事负责人（当前：黄莹·推断待确认）
CEO 资质与荣誉来源确认、申报负责人人选指定 C CEO（当前：邴龙志·推断待确认）
法务负责人 对外合规表述、是否以某主体名义提供过某服务的判断 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 要填的表格原件，标出需要的字段和用途、截止日
  • 先在资料库按主体检索；库里有的直接用并注明版本
  • 涉及人员资格的，提前确认主体、社保月数、学历要求（离截止至少 30 天）
  • 平台账号只登记“持有岗位与保险库位置”，不在库里或群里写账号密码

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建库：按主体建 10 个分区，每区指定数据提供岗位，收集现有证书扫描件、历史申报书、荣誉资料 总经办专员 启动后 30 个自然日内 多维表格+飞书云盘 资料库 V1 🔧飞书固化
2 填表人先查库，命中字段直接引用并登记“用于哪次申报” 政策申报专员/填表人 收到填表需求当天 多维表格 引用记录 🔧飞书固化
3 未命中字段提“资料/口径请求”表单：字段、用途、截止、建议值 填表人 发现缺口当天 飞书表单 口径请求 🔧飞书固化
4 按类别分派确认：财务/收入→COO（财务出数）；产品/技术→CTO；法定信息/工商→综合部负责人；人员→人事负责人 总经办专员 请求后 0.5 个工作日内分派；确认人 2 个工作日内答复 飞书任务 确认结论 👤人工判断
5 回写入库，标注口径来源岗位、确认日期、适用范围 总经办专员 确认后 1 个工作日内 多维表格 更新字段 🔧飞书固化
6 人员资格匹配：按资格库筛选候选人 → CTO/CEO 指定 → 告知本人并登记 人事负责人出名单，CTO/CEO 指定 申报截止前 ≥ 30 个自然日 资格库（受限权限） 指定记录 👤人工判断
7 预警：证照资质到期前 60 天、在申项目负责人提交离职时，自动提醒 总经办专员 自动触发 多维表格自动化 预警消息 🤖自动化
8 季度更新：新增证书、专利、软著、荣誉、产品版本、人员变动 总经办专员 每季度首月 10 日前 多维表格 更新记录 🔧+🤖

5. 交付物与模板

  • 交付物：申报资料库、口径确认记录、材料去向登记、人员资格库、季度更新记录
  • 建议模板/表单（资料库分区与字段）：
    • 基础信息：主体名称、注册地、纳税地、注册资本与实缴、成立日期、工商变更历史、所属行业
    • 资质证书：名称、级别、发证机关、有效期、扫描件、原件存放位置、维护岗位
    • 知识产权：专利（已授权/申请中）、软著、商标，权利主体、证书扫描件
    • 荣誉奖项：名称、级别、年份、申报书终版、证书
    • 产品基础信息：产品名、产品负责人岗位、发布日期、开发完成日期口径、软著号、简介、定价口径、应用案例、截图
    • 人员资格库（受限）：所属主体、社保起始月与累计月数、学历、职称、可担任角色、在申项目
    • 财务口径：AI 业务收入、软件收入、研发投入、技术合同收入的统计口径与确认人
    • 平台账号索引：平台名、主体、持有岗位、保险库位置、最近登录日
    • 案例与平台：FDE 案例、省部级研发平台、标准参编情况
    • 历史申报书：项目、年份、终版盖章件、经手岗位

6. 异常与升级

  • 证书清晰版或原件找不到 → 查档案（GEN-11）→ 2 个工作日内仍无，向发证机构申请补发，报综合部负责人
  • 同一字段历史上填过不同值 → 停止填报 → 升级 COO（财务类）或 CTO（技术类）2 个工作日内统一口径并记录
  • 在申项目负责人离职或社保月数不足 → 当天报 CEO 决定换人或放弃
  • 外部征集涉及“是否以某主体名义提供过某功能/服务”的合规问题 → CTO 确认事实 + 法务确认表述（3 个工作日内）
  • 历史材料经手人已离职 → 查离职交接清单 → 无记录时报综合部负责人

7. 衡量指标

  • 资料命中率 = 申报所需字段直接从库取得的数量 / 所需字段总数，目标 ≥ 80%（建库 3 个月后）
  • 口径请求响应时长 = 请求到确认的工作日数，目标 ≤ 2 个工作日
  • 口径冲突次数 = 同一字段在不同申报中填写不一致的次数，目标 0
  • 证照过期未续 = 0

8. 低效诊断

  • 每次申报重新追问资质、实缴、专利数、工商变更等同一批数据，口径来源不统一｜依据：「董事会专项沟通群」2026-06、「董事会专项沟通群」2026-07
  • 历史申报书由已离职人员经手，终版盖章件要临时追｜依据：「董事会专项沟通群」2026-06
  • 申报负责人离职、社保月数不够，到截止前才找人，平台关闭后无法新建账号｜依据：「综合&总经招聘考核沟通」2026-04、「综合&总经招聘考核沟通」2026-05
  • 外部征集省部级平台、标准参编情况时，没有内部台账可直接回答｜依据：「奇绩校友飞书群」2026-06

9. 分支变体

  • 资质证书、实缴、工商变更、历史荣誉：综合部负责人确认
  • 工信部年报、AI 业务收入等收入口径：一律由 COO 统一
  • 产品登记、平台入驻（如 OPC 平台产品信息表）：产品信息由 CTO 确认，介绍文字可由 AI 基于产品信息库生成
  • 项目负责人、软著管理人：社保须在申报主体且满足月数，鼎慧、模态等主体分别维护
  • 高企核查、算法备案材料：从库调取，备案办理本身转 LEG-25

10. 待确认问题

  • 资料库主责是总经办专员，还是政策申报专员？兜底是否为综合部负责人？
  • 财务/收入口径是否确定由 COO 唯一确认？
  • 人员资格库放在人事系统还是多维表格？哪些岗位可见？
  • 平台账号是否已有统一密码保险库？由谁管理？
  • 已有的荣誉资料汇总文档是否作为资料库荣誉分区的起点？
POL-04科技项目申报（市/省重点研发、OPC 专项、联合申报）待优化500

状态：待优化｜证据：有证据（卡片 8 张 / 会话 9 个）｜优先级：频4 × 耗5 × 跨5 × 险5

  • 适用场景：科技局、科技厅、区级部门发布科技项目申报通知，且已决定申报（来自 POL-01）后，从资格核对、牵头主体与负责人确定、分工撰写，到提交、退回修改和结果归档的全过程
  • 负责人：主责——政策申报专员（当前：王蕊·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、技术配合人（当前：黄振锋·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政专员（当前：侯明月·推断待确认）、CEO（当前：邴龙志·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 立项 → ② 资格条件检查 → ③ 定牵头主体/负责人/方向/金额 → ④ 联合申报协议 → ⑤ 组建写作组与倒排 → ⑥ 撰写与内审 → ⑦ 盖章提交 → ⑧ 退回修改 → ⑨ 结果归档与验收跟踪
  • 交付结果：按时提交的申报书及附件、平台提交回执；退回意见处理记录；立项后的任务书与验收指标进入跟踪
  • 状态依据：已有项目申报群、荣誉资料汇总文档、申报计划表和政策追踪 skill 雏形，也有专人操作；但归口在销售、总经办、生态市场条线之间多次变更，截止前临时拼材料、催技术配合人、找平台账密的情况反复出现

1. 场景判定

  • 触发条件：市重点研发、OPC 专项、省重大/重点研发、育苗计划、服贸引导基金、AI+行业应用等科技项目通知；客户或合作单位邀请联合申报
  • 典型说法：「项目申报资料这个群要做好同步，不要只在微信聊」「市里建议只申报一项」「项目负责人必须是有社保的博士」「安排个技术配合评估下，可能要写 200～300 页的大本子」「过往项目申报的材料都在谁手里」
  • 判断问题：是否需要撰写申报书并经政府平台提交？是否有资金或立项结果？
  • 不归本流程管：还没决定是否申报 → 请走 POL-01；人才计划与赛事 → 请走 POL-05；测试/验收报告编制 → 请走 POL-06；费用类补贴（上云券）→ 请走 POL-07；软著 → 请走 POL-10；专利 → 请走 POL-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 项目经理：检查表、倒排、催办、汇总、提交、退回处理、归档 R 政策申报专员（当前：王蕊·推断待确认）
生态市场条线负责人 申报统管，审批里程碑，协调跨部门资源；兜底 A 生态市场条线负责人（当前：许君·推断待确认）
CEO 牵头主体、联合单位、申报金额与自筹配套拍板 A（升级） CEO（当前：邴龙志·推断待确认）
CTO 申报方向与产品、项目负责人、指标承诺审定、指派技术配合人 C CTO（当前：丁震宇·推断待确认）
技术配合人 撰写技术方案、研发内容、指标 R（技术部分） 技术配合人（当前：黄振锋·推断待确认）
申报操作专员 平台注册、填报、上传 R（平台操作） 申报操作专员（当前：谌思铭·推断待确认）
销售骨干 客户联合申报的客户侧对接与材料 R（客户联合分支） 销售骨干（当前：闫登辉·推断待确认）
财务负责人 自筹配套测算、技术合同/收入/发票、经费预算 C 财务负责人（当前：黄梦婷·推断待确认）
行政专员 盖章、纸质材料打印与线下投递、技术合同清单 R（用印投递） 行政专员（当前：侯明月·推断待确认）
综合部负责人 资料库与历史申报材料支持 C 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 申报通知、指南、编写提纲、平台地址；截止日期（区级、市级各自节点）
  • 资格条件检查表：负责人学历/职称/社保月数、主体注册地与纳税地、合同与付款主体一致性、自筹比例、限报项数
  • 资料库（POL-03）：公司基础信息、资质、专利软著、荣誉、财务摘要、人员简历
  • 平台账号：确认注册主体、持有岗位、扫码/验证码接收人（截止前 ≥ 10 个工作日确认可登录）
  • 联合申报：合作单位联系人、联合申报协议模板
  • 请求最少包含字段（向 CTO/技术配合人、财务、行政、销售骨干派活时）：申报台账项目编号与项目名、级别与发布部门、申报主体、截止日（区/市/省各节点）、需要对方产出什么（技术方案章节/自筹测算/盖章投递/客户材料）、提纲与模板链接、资料库引用章节、交付截止日、提交到哪里（申报文档对应章节或受限文件夹）；缺项接收方一次性退回政策申报专员补齐

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在申报台账立项：项目、级别、主体、截止、是否有资金、P 级 政策申报专员 POL-01 决策当天 多维表格 项目记录（申报台账，带项目编号；群内只发台账链接） 🔧飞书固化
2 研读指南，填资格条件检查表；存疑项致电主管部门核实并记录 政策申报专员 立项后 2 个工作日内 多维表格+AI 摘要 检查表（挂台账项目记录，“不满足”项标红并写核实方式） 🔧+🤖+👤
3 确定牵头主体、联合单位、项目负责人、申报方向/产品、申报金额与自筹配套 CEO 拍板，CTO 定方向，财务测算 立项后 5 个工作日内且截止前 ≥ 20 个工作日 飞书审批 申报方案（飞书审批记录为唯一决策留痕，结论回写台账；口头拍板不作数）；超时见第 6 节 👤人工判断
4 联合申报：对齐会明确研发内容分工；签联合申报协议（费用分配、筹资、目标拆解） 政策申报专员组织，法务审 方案定后 5 个工作日内 飞书会议+协议模板 会议纪要（会后 1 个工作日内发，挂台账）、协议（签署件登记合同台账 LEG-11）；法务审 2 个工作日未回→综合部负责人 🔧+👤
5 CTO 指派技术配合人（大本子 ≥ 2 人），出提纲分工表，倒排初稿/内审/盖章/提交节点 CTO、政策申报专员 方案定后 2 个工作日内 飞书任务 分工表与里程碑（每个章节一条飞书任务：负责人、截止日、提交位置；被指派人 1 个工作日内认领）；超时见第 6 节 🔧飞书固化
6 收集项目组成员信息：用受限权限表单收集专业、学历、职称、分工；证件扫描件放受限文件夹，不在群里发 政策申报专员 分工后 3 个工作日内 飞书表单+受限云盘 成员信息表（受限多维表格）、证件扫描件（受限文件夹，台账挂链接） 🔧飞书固化
7 撰写：技术部分由技术配合人；公司基础/资质/财务从资料库取；佐证材料走 POL-06；AI 起草、人工核实事实 技术配合人、政策申报专员 截止前 7 个工作日出完整初稿 飞书文档+AI 申报书初稿（唯一飞书文档，各章节在对应任务下交付并关闭任务；财务提供自筹测算与技术合同清单）；章节超时→政策申报专员催办，再超 1 个工作日→CTO 🤖+👤
8 内审：对照检查表查完整性、数字口径一致、指标可验收；指标承诺由 CTO 签认 政策申报专员、CTO 截止前 5 个工作日完成 飞书文档评论 定稿（文档内“CTO 签认”评论 + 台账状态“已内审”）；超时→生态市场条线负责人 👤人工判断
9 用印、签字、打印；需线下投递的安排投递 行政专员 截止前 3 个工作日 用印审批（LEG-09） 盖章版（扫描件挂台账；投递凭证回填）；超时→综合部负责人 🔧飞书固化
10 平台提交并截图回执，项目负责人登录或授权操作 申报操作专员 截止前 2 个工作日 申报平台 提交回执（截图挂台账，状态“已提交”；平台账号持有岗位写入台账） 👤人工判断
11 退回修改：收到意见 1 个工作日内分派；非原则性修改由政策申报专员决定，金额/指标/负责人变更报 CTO/CEO；2 个工作日内重新提交 政策申报专员 退回后 3 个工作日内重提 申报平台 修改稿与重提回执（退回意见与处理记录挂台账；分派用飞书任务） 👤人工判断
12 每个节点在项目申报群同步；结果（公示、立项、任务书）入台账与荣誉素材库；立项后建验收指标跟踪 政策申报专员 节点当天；结果出来 3 个工作日内 群+多维表格 结果记录（台账状态 + 群内发台账链接）、验收跟踪表（移交 POL-15，任务书归档荣誉素材库 GEN-13） 🔧飞书固化

5. 交付物与模板

  • 交付物：申报台账记录、资格条件检查表、申报方案决策、联合申报协议、分工表、申报书定稿与盖章版、提交回执、退回处理记录、任务书与验收跟踪表
  • 建议模板/表单：
    • 申报台账字段：项目名、级别、发布部门、主体、牵头/联合、项目负责人、技术配合人、申报金额与自筹、截止日（区/市/省）、P 级、里程碑、状态、平台账号持有岗位、结果、归档链接
    • 资格条件检查表：条件项、要求、我方情况、证明材料、是否满足、核实方式
    • 标准申报材料包：公司介绍、资质清单、专利软著清单、财务摘要、核心人员简历（统一版本）
    • 联合申报协议模板：分工、经费分配、自筹、知识产权归属、目标拆解、验收责任

6. 异常与升级

  • 升级条件：确定牵头主体、联合单位、申报金额与自筹配套时，由 CEO 拍板（A（升级））；技术内容由 CTO 审定后报生态市场条线负责人，其余里程碑由生态市场条线负责人审批
  • 截止前 20 个工作日仍未定牵头主体或负责人 → 升级 CEO（1 个工作日内决定继续或放弃）
  • 资格硬条件不满足（负责人社保/学历、主体纳税地）→ 当天报 CTO/CEO 换人、换主体或放弃
  • 技术配合人 2 个工作日内未落实 → 升级 CTO；仍无人 → 生态市场条线负责人报 CEO 调配
  • 平台账号无法登录或审核卡住 → 当天联系平台客服并报兜底人；截止前 3 天仍未解决 → 启用线下或放弃
  • 联合单位对分工理解不一致 → 以协议条款为准，24 小时内开会对齐
  • 多个申报同时截止、资源冲突 → 生态市场条线负责人按 P 级排序，报 CEO 取舍
  • 申报专员转岗离职 → 移交材料、对接人、链接、账号持有关系、在办状态，交接清单经兜底人签认
  • 申报方案审批（步骤 3）提交后 3 个工作日无结论 → 政策申报专员在审批流催办 → 再 2 个工作日无结论升级生态市场条线负责人提请 CEO 限期决定
  • 章节任务到期未交付且无说明 → 政策申报专员在任务内 @ 负责人并标“卡住” → 1 个工作日无回应升级 CTO 换人或调配；进度一律看飞书任务与台账，不在群里问“写到哪了”
  • 申报沟通发生在微信或私聊 → 当事人当天把结论回写项目申报群或台账 → 未回写的结论不作为材料依据

7. 衡量指标

  • 按时提交率 = 截止前提交的项目 / 决定申报的项目，目标 100%
  • 内审前置率 = 截止前 ≥ 5 个工作日完成内审的项目占比，目标 ≥ 80%
  • 退回重提时长 = 收到退回到重新提交的工作日数，目标 ≤ 3 个工作日
  • 立项率 = 获批立项数 / 提交数，按年统计
  • 材料复用率 = 直接从资料库/材料包调用的章节占比，目标 ≥ 50%

8. 低效诊断

  • 申报归口多次变更（销售兼做、总经办统筹、再改条线统管），交接时材料、账密、状态需整体移交｜依据：「【模态】市场销售」2026-04、「【模态】项目申报」2026-06、「董事会专项沟通群」2026-06
  • 截止前一天才走盖章，历史材料和证书清晰版找不到｜依据：「【模态】总经办」2026-04、「【模态】总经办」2026-05
  • 技术配合人无人认领，两个大申报同时截止，反复催安排人｜依据：「董事会专项沟通群」2026-05、「董事会专项沟通群」2026-06
  • 负责人资格条件后知后觉，截止前不足 8 天仍在敲定合作方｜依据：「省重点研发-跃迁基座」2026-06
  • 联合单位对研发内容分工理解不一致，需反复催进度｜依据：「省重大科技-水利项目申报」2026-06
  • 平台账密不知在谁手里，需临时找人扫码｜依据：「【模态】项目申报」2026-09
  • 成员信息靠群内 @ 收集，存在个人信息明文外发风险｜依据：「跃迁基座项目交付沟通」2026-04
  • 账号主体与付款主体分属不同城市，影响政策享受｜依据：「【模态】总经办」2026-05
  • 申报只在微信沟通，项目群信息不同步｜依据：「【模态】项目申报」2026-06

9. 分支变体

  • 市重点研发 / OPC 专项：技术材料为主，市里可能建议只报一项、补充服务 OPC 社区的内容；区级先审，退回常见社保证明、间接经费比例
  • 省重大 / 重点研发：联合申报常见，负责人有硬性资格要求，需自筹配套，需在省级政务平台注册审核
  • 育苗计划类：需上年度技术合同、收入和发票，由财务提供
  • 客户联合申报（如某医疗机构客户、AI+制造类）：销售骨干对接客户，政策申报专员主写
  • 服贸引导基金等商务类项目：按通知要求，主体与收入口径由 COO 确认
  • 国际论坛/青年项目报名类：材料量小，可简化为步骤 1、7、10、12
  • 协作协议：遵循 ALL-04（跨部门交接契约）、ALL-03（决策记录与发布）、ALL-09（状态看板与进度同步）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 政策申报统管是否确定为生态市场条线负责人，政策申报专员为项目经理？
  • 申报操作专员是内部岗位还是外部申报机构？
  • “截止前 20 个工作日定方案、5 个工作日内审”是否可行？
  • 技术配合人是否建立轮值池，由 CTO 每季度指定？
  • 申报平台账号是否统一纳入密码保险库，持有岗位是谁？
POL-05人才计划与赛事类申报待新建96

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：收到人才计划（招才局、光谷 3551、青年拔尖人才、卓越工程师等）或 AI 大赛申报通知，需要确定推荐人选、评估个人与公司风险、收集个人和项目材料并提交
  • 负责人：主责——政策申报专员（当前：王蕊·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、总经办专员（当前：王欣·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申报操作专员（当前：谌思铭·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 政策解读 → ② 候选人初筛 → ③ 风险评估 → ④ 人选决策 → ⑤ 本人确认 → ⑥ 一次性列清单收材料 → ⑦ 填报审稿 → ⑧ 盖章提交 → ⑨ 结果与后续义务跟踪
  • 交付结果：已提交的人才/赛事申报材料、人选决策记录、本人确认记录、后续义务（承诺期、考核、拨付）跟踪表
  • 状态依据：每次政策来都临时评估，申报人选与互斥规则无人事先定；公司 PPT、个人简历版本多，多次催要；材料分批追补，表格顺序写反返工

1. 场景判定

  • 触发条件：人才计划、创业人才/团队、快速通道推荐、人工智能大赛、青年人才推荐表等通知到达，或外部申报机构发来推荐表
  • 典型说法：「每个人只能有一个 title」「对方建议一个企业只推荐 1 个」「你手头有的材料先发，然后看缺啥我再来补」「本周一定要把最新的公司 PPT 给我，不然来不及申报」
  • 判断问题：申报对象是否是“个人”或“团队/项目”而非公司整体？是否需要推荐人选？
  • 不归本流程管：企业科技项目 → 请走 POL-04；人才房补等政策线索研判 → 请走 POL-01；公司内部举办的赛事 → 请走 ECO-15；外部大会参会 → 请走 ECO-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 政策解读、初筛、清单、催收、填报、跟踪 R 政策申报专员（当前：王蕊·推断待确认）
CEO 是否申报、人选与名额分配拍板 A CEO（当前：邴龙志·推断待确认）
CTO 技术类人选评估与测算参与 C CTO（当前：丁震宇·推断待确认）
COO 统一版公司 PPT/BP、个人简历审定 R（公司材料） COO（当前：常元和·推断待确认）
财务负责人 个人税务、拨付方式、薪酬结构影响测算 C 财务负责人（当前：黄梦婷·推断待确认）
人事负责人 申报人基本情况、学历、社保、服务年限 C 人事负责人（当前：黄莹·推断待确认）
总经办专员 从资料库调专利、荣誉、证书 R（材料） 总经办专员（当前：王欣·推断待确认）
综合部负责人 历史材料与申报人既有资料支持 C 综合部负责人（当前：赵雪冰·推断待确认）
行政专员 人事材料协调、盖章 C 行政专员（当前：侯明月·推断待确认）
申报操作专员 推荐表生成 PDF、平台提交 R（提交） 申报操作专员（当前：谌思铭·推断待确认）
生态组负责人 赛事类项目材料对接 C 生态组负责人（当前：陈梦琪·推断待确认）
申报人本人 确认意愿与义务，提供个人证件材料、审稿 R（个人材料） 申报人

3. 办之前请准备

  • 政策原文：名额、推荐限制、条件（学历、年限、社保、成果）、材料清单、拨付方式、承诺期、审计要求
  • 标准材料包：统一版公司 PPT/BP、个人简历标准版、专利/荣誉清单（POL-03 资料库）
  • 申报人证件（身份证、学历学位证书）只放受限文件夹，不在群内发送
  • 赛事：产品信息库中的介绍、截图、案例

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 解读政策并拆分申报口（快速通道/个人/团队），列出互斥规则 政策申报专员 收到后 2 个工作日内 飞书文档+AI 摘要 政策解读卡 🤖+👤
2 按条件初筛候选人，出候选清单 政策申报专员、人事负责人 解读后 2 个工作日内 人员资格库 候选清单 👤人工判断
3 风险评估：个人税务、承诺期与离职风险、审计要求、对薪酬结构影响 财务负责人、CTO 候选清单后 3 个工作日内 测算模板 风险评估表 👤人工判断
4 决策：是否申报、人选、名额分配 CEO 评估后 2 个工作日内 飞书审批 决策记录 👤人工判断
5 告知本人义务与承诺，取得书面同意 政策申报专员 决策后 1 个工作日内 飞书审批/文档确认 本人确认 🔧飞书固化
6 从资料库调材料，缺项一次性列清单给本人和相关岗位，统一截止 总经办专员、政策申报专员 决策后 3 个工作日内 飞书任务+受限云盘 材料包 🔧飞书固化
7 按推荐表顺序填报，本人审稿签认 政策申报专员、申报人 截止前 5 个工作日 飞书文档 定稿 👤人工判断
8 盖章、生成 PDF、提交，回执入台账 申报操作专员、行政专员 截止前 2 个工作日 申报平台 提交回执 🔧飞书固化
9 跟踪结果、拨付、年度考核与承诺期，在台账设提醒 政策申报专员 结果出来 3 个工作日内建提醒 多维表格 义务跟踪表 🔧+🤖

5. 交付物与模板

  • 交付物：政策解读卡、候选清单、风险评估表、决策记录、本人确认、材料包、提交回执、义务跟踪表
  • 建议模板/表单：
    • 人才申报台账字段：计划名称、类别（个人/团队/快速通道/赛事）、名额与互斥规则、候选人、决策人选、本人确认日期、材料完成度、截止日、状态、结果、承诺期、下次考核日
    • 风险评估表：拨付方式、税务影响、承诺服务年限、离职处置、审计要求、结论
    • 个人材料清单：标准简历、学历学位证书、身份证件（受限）、专利/论文/荣誉、项目经历

6. 异常与升级

  • 同一人被多个口子拟推荐 → 按互斥规则由政策申报专员提出方案 → 升级 CEO（1 个工作日内）
  • 公司 PPT/简历催要超 2 次未交 → 升级生态市场条线负责人，当天点名截止时间
  • 条件差一点（年限、社保月数）→ 不得调整事实凑条件，如实判断是否放弃，报 CEO
  • 申报人申报后提出离职 → 当天报 CEO 与财务评估退回或承诺处置
  • 外部申报机构要求超出必要范围的个人信息 → 暂停提供，报法务负责人

7. 衡量指标

  • 材料一次收齐率 = 一次性清单后未再追补的申报 / 全部申报，目标 ≥ 80%
  • 决策及时率 = 解读后 7 个工作日内完成人选决策的申报占比，目标 ≥ 90%
  • 按时提交率，目标 100%
  • 承诺期内义务漏办数，目标 0

8. 低效诊断

  • 公司 PPT/BP、个人简历版本多，多次催要仍卡在提供环节｜依据：「董事会专项沟通群」2026-05
  • 多个申报口逐个评估后大部分放弃，人选、互斥和离职风险无事先规则｜依据：「董事会专项沟通群」2026-05
  • 材料分批追补（身份证、学历学位后补），表格顺序写反返工，人事信息由谁提供不明｜依据：「人才项目申报专项群」2026-07

9. 分支变体

  • 快速通道：通常一企推荐 1 人，CEO 决定人选
  • 个人创业人才：需个人简历、公司 PPT/BP、保证函
  • 人工智能创业团队：1 名领军 + 核心成员，成员互斥规则先定
  • 青年拔尖人才、卓越工程师：外部申报机构代办推荐表，材料从资料库调取
  • AI 大赛、企业产品比赛：以产品信息库为准，无现成材料时由生态组负责人与 CTO 先评估是否参赛

10. 待确认问题

  • 人才申报是否统一由政策申报专员牵头，还是由申报人本人负责？
  • 风险评估由财务负责人出测算模板是否可行？
  • 统一版公司 PPT/BP 和个人简历标准版的维护岗位是 COO 吗？
  • 外部申报机构接触个人证件信息，是否需要签保密协议？
POL-06申报佐证材料（测试/检测/验收报告、指标对比）编制待新建90

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨3 × 险5

  • 适用场景：产品认证、成果推荐、科技项目申报或验收、合作方政府项目需要技术指标对比表、测试报告、验收报告、检测报告、安全评测调研表时，基于真实测试结果出具或委托检测，并沉淀为可复用的申报材料包
  • 负责人：主责——政策申报专员（当前：王蕊·推断待确认）；协同——研发报告编制人（当前：马漳毓·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求登记 → ② 查材料包 → ③ 获取对方标准 → ④ 指标表初稿与专业化 → ⑤ 基于真实测试出报告 → ⑥ 真实性与合规审核 → ⑦ 定稿交付 → ⑧ 入材料包
  • 交付结果：经 CTO 审定、基于真实测试记录的报告/指标表，并以版本、有效期、适用范围登记在申报材料包中
  • 状态依据：没有留存的测试/自检报告（测试按工单而非报告），每次临时指派研发赶制；指标名称无标准，初稿多轮修改；报告缺少真实性复核环节

1. 场景判定

  • 触发条件：申报或认证要求提供测试报告、验收报告、检测报告、核心技术指标对比表、安全评测调研表、案例集
  • 典型说法：「我们的产品有没有内部的自检报告、测试报告呢」「我们测试都是按工单的，不是按报告的」「Agent 是个很新的玩意，所有标准和规范变得极快」
  • 判断问题：对方要的是不是“证明产品技术能力或测试结论”的材料？
  • 不归本流程管：申报书主体撰写 → 请走 POL-04；资质证书、专利清单调取 → 请走 POL-03；客户案例授权 → 请走 BRD-15；竞品对比宣传素材 → 请走 BRD-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 登记需求、索取对方标准、指标表初稿、追进度、入材料包 R 政策申报专员（当前：王蕊·推断待确认）
CTO 指派编制人，审定指标取值、测试环境与边界、报告结论；兜底 A CTO（当前：丁震宇·推断待确认）
研发报告编制人 依据测试记录编写测试/验收报告 R（报告） 研发报告编制人（当前：马漳毓·推断待确认）
法务负责人 真实性、对外表述与署名主体审核 C 法务负责人（当前：李瑶·推断待确认）
测试人员 提供测试记录，按需补测 C 测试负责人（当前：张东郅·推断待确认）

3. 办之前请准备

  • 用途（哪个申报/认证/合作方项目）、对方格式与评价标准、截止日
  • 产品版本、产品手册、已有测试工单与测试结果
  • 现有材料包：指标表、测试/验收报告、安全评测调研表、FDE 案例集的最新版
  • 合作方要报告的：确认署名主体、用途和是否对外公开

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记需求：材料类型、用途、格式标准、截止 政策申报专员 收到当天 多维表格 需求记录 🔧飞书固化
2 查材料包，版本有效且适用直接使用 政策申报专员 登记后 0.5 个工作日内 申报材料包 复用结论 🔧飞书固化
3 向对方索取格式与评价标准；无标准时用公司通用模板 政策申报专员 登记后 1 个工作日内 — 标准/模板 👤人工判断
4 指标对比表：AI 基于产品手册出初稿，统一使用指标库名称；CTO 改为量化专业稿 政策申报专员、CTO 初稿 1 个工作日；审定 2 个工作日 飞书文档+AI 指标表 🤖+👤
5 测试/验收报告：CTO 指派编制人；只依据真实测试工单与结果，写明版本、环境、边界；缺数据先补测 研发报告编制人 指派后 3 个工作日内 工单系统+报告模板 报告初稿 🔧+🤖
6 需第三方检测的，确定检测机构并委托 政策申报专员 截止前 ≥ 20 个工作日启动 — 检测委托 👤人工判断
7 审核：CTO 审结论与数据；法务审真实性、表述与署名主体 CTO、法务负责人 初稿后 2 个工作日内 飞书文档评论 审定稿 👤人工判断
8 定稿交付并登记去向；入材料包（版本、有效期、适用范围） 政策申报专员 交付当天 申报材料包 材料包条目 🔧飞书固化

5. 交付物与模板

  • 交付物：核心技术指标对比表、产品测试报告、产品验收报告、安全评测调研表、第三方检测报告、案例集
  • 建议模板/表单：
    • 测试报告模板：产品与版本、测试目的、测试环境、测试范围与边界、用例清单、测试结果（关联工单号）、未通过项、结论、编制人与审核人岗位、日期
    • 指标库字段：指标名称、定义、计量方式、当前值、测试日期、数据来源、适用产品版本
    • 材料包登记：材料名、版本、有效期、适用范围、用过的申报、审定人岗位

6. 异常与升级

  • 对方要求的指标我方未测过 → 补测或如实说明，不得编造数据 → 升级 CTO（1 个工作日内决定补测或放弃）
  • 时间不足以出真实报告 → 当天报 CTO 与生态市场条线负责人决定是否放弃该申报
  • 合作方要求以我方名义出报告用于其项目 → 法务审署名与用途（2 个工作日内），未审不得交付
  • 产品版本更新导致材料包失效 → 标记失效，下次使用前重测

7. 衡量指标

  • 材料包复用率 = 直接复用的需求 / 全部佐证需求，目标 ≥ 50%（建包 6 个月后）
  • 报告审核覆盖率 = 经 CTO 与法务审核后交付的报告 / 交付报告，目标 100%
  • 指标表返工轮次 = 初稿到定稿的修改轮数，目标 ≤ 2 轮
  • 交付及时率 = 截止前交付 / 全部需求，目标 100%

8. 低效诊断

  • 测试按工单而非报告，没有留存的测试/自检报告，每次临时指派研发赶制，缺模板和真实性复核环节｜依据：「【模态】项目申报」2026-09
  • 指标名称无标准，初稿“看起来都不太对”，多轮修改｜依据：「【模态】项目申报」2026-09
  • 安全评测调研表临时补做，测试环境与边界需临时确认｜依据：「【模态】项目申报」2026-10

9. 分支变体

  • 产品认证：需测试报告与验收报告
  • 成果推荐：以指标对比表为主
  • 安全评测调研：需求摸底，CTO 确认测试环境和边界
  • 合作方政府项目临时需要的测试/验收报告：必须先过法务审核署名和用途
  • 算力补贴类：财务材料清单转 POL-07

10. 待确认问题

  • 主责是政策申报专员（流程）还是 CTO（内容）？是否需要设测试负责人为报告固定编制人？
  • 公司是否接受委托第三方检测，预算由谁审批？
  • 测试报告模板由谁出，何时完成？
  • 合作方用我方报告的场景，是否需要签使用约定？
POL-07补贴申领资料归集（上云补贴等）待新建36

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗3 × 跨4 × 险3

  • 适用场景：已决定申领上云补贴、上云服务券等费用类补贴后，按主体归集云服务商、上云时间、年消费额、发票、消费主体、消耗记录并提交
  • 负责人：主责——政策申报专员（当前：王蕊·推断待确认）；协同——云资源管理人（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 确认申领条件 → ② 发起按主体的归集清单 → ③ 导出云账号与账单 → ④ 核对发票与付款 → ⑤ 判断主体一致性 → ⑥ 整理提交 → ⑦ 跟踪拨付入账
  • 交付结果：按主体整理好的补贴申领材料包（云服务清单、账单、发票、付款凭证、消耗记录）与提交回执，补贴到账后入账
  • 状态依据：云服务商无统一台账，财务侧信息不全，需逐个主体找人；部分消费未开票、发票仍在云平台未申请；云账单信息集中在个人手里

1. 场景判定

  • 触发条件：POL-01 已决定申领上云补贴/上云服务券等以已发生费用为依据的补贴
  • 典型说法：「目前公司所有的云服务商有人在统一管吗」「存在一些没有开票等各种情况」「苏州不在武汉纳税，很难享受政策」
  • 判断问题：补贴是否按我方已发生的云服务或软件费用计算？
  • 不归本流程管：是否申领的判断 → 请走 POL-01；云账号与成本日常台账 → 请走 FIN-30；云账户充值 → 请走 FIN-03；缺票催收 → 请走 FIN-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 归集清单、主体一致性初判、整理提交、跟踪 R 政策申报专员（当前：王蕊·推断待确认）
生态市场条线负责人 审核材料、兜底 A 生态市场条线负责人（当前：许君·推断待确认）
云资源管理人 导出云账号、开通时间、消费明细 R（数据） 云资源管理人（当前：丁震宇·推断待确认）
财务负责人 核对发票与付款主体、申请缺票、补贴入账 R（财务） 财务负责人（当前：黄梦婷·推断待确认）
鼎慧负责人 鼎慧主体云账号信息提供 C 鼎慧负责人（当前：杨萌·推断待确认）
综合部负责人 主体资料与盖章支持 C 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 政策申领操作手册、补贴条件（主体、纳税地、服务商范围、时间范围）
  • 云账号台账（FIN-30）：服务商、账号主体、开通时间、付款主体
  • 各云平台的账单导出权限、发票申请权限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按操作手册列出所需字段，按主体发起归集清单 政策申报专员 决定申领后 1 个工作日内 多维表格 归集清单 🔧飞书固化
2 导出各主体云账号、上云时间、年度消费额、消耗明细 云资源管理人 清单发出后 2 个工作日内 云平台控制台 账单导出 🤖自动化
3 核对每笔消费是否开票、开票主体与付款主体是否一致；缺票在云平台申请 财务负责人 账单到后 3 个工作日内 云平台+财务系统 发票核对表 👤人工判断
4 判断主体一致性：账号主体、付款主体、申报主体、纳税地；不一致的剔除或书面说明 政策申报专员、财务负责人 核对后 1 个工作日内 多维表格 可申报清单 👤人工判断
5 按操作手册整理材料、盖章、提交 政策申报专员 截止前 3 个工作日 申报平台 提交回执 🔧飞书固化
6 跟踪审核与拨付，到账后入账并回写台账 财务负责人 到账后 3 个工作日内 财务系统 入账记录 🔧飞书固化

5. 交付物与模板

  • 交付物：归集清单、账单导出、发票核对表、可申报清单、提交回执、入账记录
  • 建议模板/表单：
    • 云服务归集表字段：主体、云服务商、账号持有岗位、上云/开通时间、统计期间、消费额、已开票额、未开票额、发票主体、付款主体、纳税地、是否纳入申报、备注

6. 异常与升级

  • 云资源管理人 2 个工作日内未导出 → 机器人提醒 → 升级兜底人（1 个工作日内）
  • 消费未开票且平台不能补开 → 剔除该笔，记录原因
  • 账号主体与付款/纳税主体不一致 → 报 COO 决定是否以其他主体申报；长期问题转 FIN-32 处理主体归属
  • 补贴超期未到账 → 政策申报专员向主管部门查询，每 10 个工作日一次

7. 衡量指标

  • 归集周期 = 发起清单到可申报清单完成的工作日数，目标 ≤ 7 个工作日
  • 发票完整率 = 已开票消费额 / 拟申报消费额，目标 100%
  • 主体错配剔除额占比，按次统计，用于推动主体规范

8. 低效诊断

  • 云服务商无统一台账，财务侧信息不全，申报时需逐个主体找人收集｜依据：「董事会专项沟通群」2026-06
  • 部分消费未开票，发票仍在云平台未申请｜依据：「董事会专项沟通群」2026-06
  • 账单信息集中在个人手里，需“晚点提醒”才处理｜依据：「董事会专项沟通群」2026-06
  • 云账号主体与付款、纳税主体分属不同城市，影响补贴享受｜依据：「【模态】总经办」2026-05

9. 分支变体

  • 武汉、苏州、鼎慧等不同主体各自的云账号分别归集
  • 多云服务商分别导出账单
  • 领券类（先申领后使用）与按已发生消费补贴类，按各自操作手册执行

10. 待确认问题

  • 云资源管理是否仍由 CTO 本人负责，能否指定执行人？
  • 云账号台账（FIN-30）是否已建立，由财务还是 IT 维护？
  • 上云补贴的申报主责是政策申报专员还是财务负责人？
POL-08周期性政府报表与年检填报待新建36

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨2 × 险3

  • 适用场景：工信部软件和信息技术服务业月报/年报、LEI 续期、研究院年检等周期性填报到期时，按日历提醒、准备数据、填报、审核并留档
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——政策申报专员（当前：王蕊·推断待确认）、COO（当前：常元和·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 建报表日历 → ② 截止前提醒 → ③ 准备数据 → ④ 口径核对 → ⑤ 填报 → ⑥ 审核 → ⑦ 提交留档 → ⑧ 更新下期
  • 交付结果：按期提交的报表或年检材料、提交截图/回执、数据底稿，报表日历更新到下一期
  • 状态依据：工信部月报/年报由财务按时完成，但没有报表日历和台账，LEI、研究院年检等是否到期依赖个人记忆；补贴、备案、报表线索混在一起

1. 场景判定

  • 触发条件：报表日历到期提醒；主管部门发来填报通知；年检、续期通知
  • 典型说法：「完成工信部软件和信息技术服务业年报及月报填报」「要不要我整理资料尝试申报一下？」
  • 判断问题：这是周期性、强制或续期类的填报，而不是一次性的补贴申报吗？
  • 不归本流程管：补贴申报 → 请走 POL-01、POL-07；营业执照年报与对外账号 → 请走 GEN-14；算法备案 → 请走 LEG-25；税务申报 → 请走 FIN-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
财务负责人 工信部月报/年报、LEI 续期的数据准备与填报 R 财务负责人（当前：黄梦婷·推断待确认）
综合部负责人 研究院年检材料、日历审核；兜底 A 综合部负责人（当前：赵雪冰·推断待确认）
政策申报专员 维护报表日历、提醒 R（日历） 政策申报专员（当前：王蕊·推断待确认）
COO 收入口径与其他申报一致性确认 C COO（当前：常元和·推断待确认）
CEO 年报类数据最终确认 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 报表日历：报表名、主管部门、主体、周期、截止日、平台、账号持有岗位
  • 财务数据：营收（含软件与 AI 业务收入）、人员数、研发投入，与上期和税务申报数据对照
  • 研究院年检：年度工作报告、财务报告、活动记录
  • 上期报表底稿

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建报表日历并每年 1 月复核 政策申报专员、财务负责人 一次性建立后每年 1 月 多维表格 报表日历 🔧飞书固化
2 截止前 10 个工作日机器人提醒责任人 政策申报专员 自动 飞书机器人 提醒 🤖自动化
3 准备数据底稿 财务负责人（年检材料由综合部负责人） 截止前 5 个工作日 财务系统 数据底稿 🔧+🤖
4 口径核对：与上期、税务申报、近期其他申报填写值比对，差异超过 10% 写说明并由 COO 确认 财务负责人、COO 截止前 3 个工作日 POL-03 口径库 口径确认 👤人工判断
5 在平台填报 财务负责人 截止前 2 个工作日 主管部门平台 填报记录 👤人工判断
6 年报类提交前报 CEO 确认 财务负责人 截止前 2 个工作日 飞书审批 确认记录 🔧飞书固化
7 提交并截图留档 财务负责人 提交当天 飞书云盘 回执与底稿 🔧飞书固化
8 更新日历下期截止日，状态改为已完成 政策申报专员 提交后 1 个工作日内 多维表格 日历更新 🔧飞书固化

5. 交付物与模板

  • 交付物：报表日历、数据底稿、提交回执、年检材料归档
  • 建议模板/表单：
    • 报表日历字段：报表名、主管部门、主体、周期（月/季/年）、截止日、平台、账号持有岗位、数据来源、责任岗位、上期提交日、本期状态、回执链接

6. 异常与升级

  • 截止前 3 个工作日仍未开始 → 机器人提醒兜底人 → 综合部负责人当天指定处理人
  • 数据与其他申报口径冲突 → 暂停提交 → 升级 COO（1 个工作日内）
  • 平台账号无法登录 → 当天联系主管部门，报综合部负责人
  • 逾期未报 → 当天补报并书面说明原因，报 CEO
  • 升级条件：年报类数据提交前须经 CEO 最终确认（A（升级））；月报、年检等其余报表由综合部负责人审核拍板

7. 衡量指标

  • 按期提交率 = 截止前提交的报表 / 应报报表，目标 100%
  • 口径一致率 = 与其他申报同一字段一致的报表占比，目标 100%
  • 日历覆盖率 = 已录入日历的周期性报表 / 实际需报报表，目标 100%

8. 低效诊断

  • 周期性报表、年检、补贴线索没有日历与台账，依赖财务个人发现与跟进｜依据：「财务部」2026-05、「财务部」2026-07

9. 分支变体

  • 工信部软件和信息技术服务业月报、年报：财务负责人填报，收入口径由 COO 统一
  • LEI 续期：按年度，财务负责人办理
  • 研究院年检：综合部负责人准备材料
  • 不同主体（模态、鼎慧、跃迁、苏州）各自的报表分别列入日历

10. 待确认问题

  • 公司目前需报的周期性报表、年检具体有哪些？各自截止日是什么？
  • 研究院年检归综合部负责人还是研究院方？
  • LEI 续期由财务负责人办理是否正确？
  • 本流程与 GEN-14（证照年检与年报）是否合并维护同一张日历？
POL-09行业/团体标准参编与编制待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险3

  • 适用场景：外部机构发起行业标准/团体标准参编征集，或公司受邀、拟牵头编制团体标准时，从评估是否参编到按分工完成稿件提交的全过程
  • 负责人：主责——标准项目牵头人（当前：吴琪·推断待确认）；协同——技术协调人（当前：杨萌·推断待确认）、技术编写人（当前：郭逸非、黄飞鹏·推断待确认）、外部渠道对接人（当前：李鹏为·推断待确认）、技术评估人（当前：李子遥·推断待确认）、终审人 CTO（当前：丁震宇·推断待确认）、参编决策人 CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 登记标准机会 → ② 核实参编条件 → ③ 评估资质与投入 → ④ 管理层决策（参编/联合/放弃）并指定牵头人 → ⑤ 建群、领分工与模板、开大纲会 → ⑥ AI 起草 + 多模型交叉审 → ⑦ 内部终审 → ⑧ 提交、归档并跟踪发布
  • 交付结果：参编决策记录；按分工完成并经终审的标准章节/附件（docx）及提交回执；「政策/标准机会池」记录更新
  • 状态依据：无固定流程。团标立项时负责人在群内临时商定，标准征集靠成员转发偶然发现，3 个会话中均出现"谁来负责/找人打听"的临时安排且无结论回填；仅最近一次附件编写有分工表

1. 场景判定

  • 触发条件：收到标准化机构、行业协会、研究院的参编征集或立项通知；合作单位邀请共同起草；组织方下发分工表要求按章节提交内容；管理层提出牵头编制团标
  • 典型说法：「公开征集参编单位与专家，我们能上桌吗」「看看谁来负责这个事」「这个文件里面有分工表，按示例填充内容」
  • 判断问题：最终产出是不是一份"标准文本/标准章节"？是否要以公司名义署名为参编/起草单位？如果只是转发扶持政策、补贴措施，不走本流程
  • 不归本流程管：地方扶持政策、补贴线索研判 → 请走 POL-01；科技项目/OPC 专项申报 → 请走 POL-04；标准所需的测试/检测报告 → 请走 POL-06；以标准为主题的外部会议参会 → 请走 ECO-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
机会发现人 转发征集信息并登记机会池 R 任意员工
外部渠道对接人 联系组织方确认资质、费用、署名、工作量 R 市场销售负责人（当前：李鹏为·推断待确认）
技术评估人 评估标准性质、公司投入成本与能力匹配 C 信创负责人（当前：李子遥·推断待确认）
参编决策人 决定参编/联合申报/放弃，批准人力与费用投入 A CEO（当前：邴龙志·推断待确认）
标准项目牵头人 对外对接、建群、节点计划、催收稿件、提交 R 销售总监（当前：吴琪·推断待确认）
技术协调人 指定技术编写人、协调研发资源 R 产品总监（当前：杨萌·推断待确认）
技术编写人 按分工起草章节、AI 交叉审、标注修改 R 开放平台负责人、产品经理（当前：郭逸非、黄飞鹏·推断待确认）
终审人 提交前审定技术口径、公司信息与署名，分歧报参编决策人 R CTO（当前：丁震宇·推断待确认）
政策申报专员 维护机会池、归档终稿 C 政策申报专员（当前：王蕊·推断待确认）

3. 办之前请准备

  • 征集通知原文、截止日期、参编资质要求（单位类型、规模、专家资格、费用）
  • 拟用于参编的公司主体及营业执照、资质荣誉等基础材料（从 POL-03 资料库取）
  • 拟投入人员与工时预估
  • 可借力的合作单位清单（本地研究院、高校、生态伙伴）
  • 组织方提供的分工表、模板文件和示例

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在「政策/标准机会池」登记来源、截止日、资质要求、预估投入 机会发现人 发现当日 飞书多维表格 机会记录 🔧飞书固化
2 电话联系组织方，核实参编条件、费用、署名方式、工作量 外部渠道对接人 登记后 3 个工作日内 电话/邮件 条件核实记录（回填机会池） 👤人工判断
3 评估资质是否满足、投入成本、对产品与品牌的价值；资质不足时给出联合申报方案 技术评估人 + 牵头人 核实后 2 个工作日内 飞书文档 一页评估（参编/联合/放弃） 🤖+👤
4 决策并指定牵头人、技术协调人 参编决策人 评估提交后 2 个工作日内，且不晚于截止日前 5 个工作日 飞书审批 决策记录、负责人 🔧飞书固化
5 建项目群，召开大纲会，确认分工与节点计划 牵头人 + 技术协调人 决策后 3 个工作日内 飞书群、飞书任务 分工表、节点计划 🔧飞书固化
6 按模板用 AI 起草，至少两个模型交叉 review，修改处标色便于复审 技术编写人 内部稿比组织方截止日提前 3 个工作日 AI 工具 内部初稿 🤖自动化
7 终审技术口径、公司信息、署名，检查是否含未公开技术或客户信息 终审人 收稿后 2 个工作日内 飞书文档评论 终审稿 👤人工判断
8 提交并保存回执，终稿归档，更新机会池状态，跟踪立项/发布进度 牵头人 终审通过后 1 个工作日内 组织方平台/邮件、飞书云盘 提交回执、归档链接 🔧飞书固化

5. 交付物与模板

  • 交付物：参编评估与决策记录；标准章节/附件终稿（docx）；提交回执；发布后的标准文本及署名证明
  • 建议模板/表单：
    • 「政策/标准机会池」多维表格：机会名称、类型（国标/行标/团标/地方政策）、发布机构、来源链接、截止日期、资质要求、预计投入、负责人、决策结论、状态、归档链接
    • 标准编写分工表：章节/附件、负责单位、我方编写人、内部截止日、审核人、状态
    • 一页评估模板：标准性质、资质匹配、投入人天与费用、预期价值、建议（参编/联合/放弃）

6. 异常与升级

  • 资质或体量不足 → 牵头人提出联合申报方案 → 参编决策人（2 个工作日内）
  • 机会登记后无人认领 → 兜底人指定牵头人（1 个工作日内）
  • 内部稿逾期 → 牵头人提醒 → 逾期 1 个工作日升级技术协调人，2 个工作日升级 CTO
  • 组织方要求的费用或资源承诺超出预算 → 暂停 → 参编决策人（2 个工作日内）
  • 稿件涉及未公开技术方案、客户信息 → 删改后再提交 → 请走 LEG-30 保密审查（1 个工作日内）

7. 衡量指标

  • 机会响应时长：登记到决策的工作日数，目标 ≤ 5 个工作日
  • 按期提交率：按组织方截止日提交的比例，目标 100%
  • 内部返工轮次：终审退回次数，目标 ≤ 1 次
  • 机会登记率：群内出现的标准征集进入机会池的比例，目标 100%

8. 低效诊断

  • 现象：团标立项后"谁来负责"需在群内临时商量，牵头与技术协调分工多次确认｜依据：「字字可研市场运营」2026-04
  • 现象：标准征集靠群聊转发偶然发现，"找人打听"后无记录、无结论回填，参编条件与成本评估缺少固定环节｜依据：「模态AI探索小分队」2026-03
  • 现象：资质不足时是否联合申报、找谁联合临时讨论，无判断标准｜依据：「模态AI探索小分队」2026-03
  • 现象：分工表、模板在群内以文件流转，未进入统一台账，后续难追溯｜依据：「中国工程咨询协会AI团标」2026-08

9. 分支变体

  • 牵头编制团体标准：增加编制组组建、大纲会、征求意见、组织方对接环节；终审需 CTO + CEO
  • 参编外部团体标准：按组织方分工编写指定附件（如可信度评估、应用项目建议书），从步骤 5 开始
  • 国家级/行业标准征集（如信通院可信能力标准）：资质门槛高，重点在步骤 2～4，可考虑联合本地研究院/高校
  • 其他城市 OPC 扶持政策对标：仅作情报登记机会池，转 POL-01

10. 待确认问题

  • 标准项目牵头人是否固定由销售/市场侧担任，还是按标准领域由对应产品线负责？
  • 参编决策权归 CEO 还是 CTO？是否设投入上限（人天/费用）？
  • 是否建立统一的「政策/标准机会池」，与 POL-01 共用一张表？
  • 以哪个主体（模态/鼎慧/跃迁等）参编的选择规则是什么？
  • "AI 起草 + 多模型交叉审 + 人工终审"是否作为标准类对外稿件的默认做法？
POL-10软件著作权申请与权属确认待优化192

状态：待优化｜证据：有证据（卡片 5 张 / 会话 7 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：产品或平台上线、需要证明权属、软件退税或政策申报需要软著时，先确定著作权人（申报主体）、费用承担与合作方关系，再完成材料、盖章、代理提交和取证
  • 负责人：主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——材料撰写人（各产品线，当前：韩诗琪、葛家和、陈梦琪·推断待确认）、技术与权属把关（当前：丁震宇·推断待确认）、主体与退税判断（当前：常元和·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、盖章环节（当前：杨萌、黄飞鹏·推断待确认）、外部代理机构；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 立项登记 → ② 权属确认（著作权人、费用、合作方）→ ③ 按模板写材料包 → ④ 总经办初审 → ⑤ 代理复核 → ⑥ 选对主体用印 → ⑦ 提交缴费 → ⑧ 取证登记并通知
  • 交付结果：登记在正确主体名下的软件著作权登记证书，及知识产权台账中的完整记录（名称、主体、版本、状态、证书号、对接人）
  • 状态依据：2026-06 总经办已发布《专利/软著申报流转流程》和材料模板，但“主体怎么定”没有规则：开源社区软著挂哪个主体来回确认、连续多轮催主体；代理要求修改后需重新盖章，盖章人难追溯；历史软著出现无人知晓对接人的情况；子公司项目启动前才发现著作权人拟挂合作高校

1. 场景判定

  • 触发条件：新产品/平台或大版本上线；需要软著支撑软件退税、政策申报、招投标、客户要求的权属证明；子公司或合作项目产出软件成果
  • 典型说法：「有人能速成软著吗」「主体先不填」「先把著作权人写谁定下」「软著申报材料整理完毕后提交总经办初审」
  • 判断问题：要保护的是“软件代码与界面”本身吗？著作权人（主体）是否已经明确？如果保护的是技术方案，走专利 POL-11
  • 不归本流程管：专利申请 → 请走 POL-11；商标 → 请走 LEG-16；算法备案 → 请走 LEG-25；政策申报本身 → 请走 POL-04 / POL-05；合同盖章 → 请走 LEG-09；客户要求协助其申请软著 → 请走 SAL-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识产权归口 立项登记、初审、对接代理、缴费、取证、维护台账 R/A 总经办（当前：赵雪冰·推断待确认）
材料撰写人 写使用说明、截图、整理代码、填信息表 R 各产品线经办人（当前：韩诗琪、葛家和、陈梦琪·推断待确认）
技术把关 确认软件名称、功能拆分、代码范围不泄密 C 创始人兼 CTO（当前：丁震宇·推断待确认）
主体决策 按合同主体、退税、授权关系确定著作权人 A COO（当前：常元和·推断待确认）；CEO（当前：邴龙志·推断待确认）
子公司/合作项目 提前同步权属风险与合作方安排 R 子公司技术负责人（当前：白立新·推断待确认）
盖章 按所选主体走用印 R 产品线负责人（当前：杨萌、黄飞鹏·推断待确认）
外部代理 复核材料、提交、加急 C 代理机构
兜底 主体与权属争议拍板 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 预申请软件名称（需与合同、产品名称对应）、版本号、功能拆分范围（是否留部分功能给 2.0 版本）
  • 拟定著作权人（主体）及依据：合同从哪家主体签、是否涉及软件退税、是否有子公司/高校/研究院参与
  • 费用承担方、是否加急
  • 材料包：软件使用流程说明与截图（软件名称统一替换为申请名称）、源代码节选、信息登记表
  • 合作项目：合作协议中关于知识产权归属的条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在知识产权台账立项：名称、版本、产品线、用途（退税/申报/权属）、期望完成日 申报部门 需求确定后 2 个工作日内 多维表格 立项记录 🔧飞书固化
2 权属确认：按“合同从哪家主体走就申请到哪家”规则提出主体；涉及子公司、高校、研究院的填权属确认单 申报部门、主体决策人 立项后 3 个工作日内 权属确认单 主体与费用结论 👤人工判断
3 按模板编写材料包；可用 AI 根据产品文档生成使用说明初稿与截图整理 材料撰写人 主体确认后 5 个工作日内 软著材料模板 + AI 材料包 zip 🤖自动化
4 总经办初审：名称一致性、主体、截图与代码完整性 知识产权归口 收到后 2 个工作日内 飞书 初审意见 👤人工判断
5 转代理复核；代理意见回传后由撰写人修改 知识产权归口、撰写人 代理意见到达后 3 个工作日内改完 邮件/代理群 定稿材料 👤人工判断
6 需盖章材料走「用章用印申请」，选择对应主体；修改后重盖的，在审批单关联原单 盖章环节经办人 定稿后 1 个工作日内 飞书审批 盖章材料 🔧飞书固化
7 代理提交、总经办统一缴费，台账记录受理号 知识产权归口 盖章后 2 个工作日内 台账 受理号 🔧飞书固化
8 下证后登记证书号、存证书电子版，通知产品负责人与财务（退税用） 知识产权归口 下证后 2 个工作日内 台账 + 云盘 证书归档 🔧+🤖

5. 交付物与模板

  • 交付物：软著登记证书、材料包定稿、权属确认单、台账记录
  • 建议模板/表单：
    • 权属确认单字段：软件名称、开发团队、拟定著作权人、依据（合同主体/退税/授权关系）、合作方及协议条款、费用承担方、决策人、确认日期
    • 知识产权台账（软著）字段：名称、版本、主体、产品线、对接人、材料撰写人、代理机构、受理号、证书号、状态（立项/撰写/初审/代理复核/已提交/已下证）、用途、下证日期

6. 异常与升级

  • 主体 3 个工作日未定 → 知识产权归口提交 COO/CEO 拍板 → 2 个工作日内必须给出结论
  • 子公司或合作高校拟挂名著作权人 → 暂停提交，先开权属会议并由法务审合作协议 → 升级 CEO（5 个工作日内）
  • 代理要求修改导致重新盖章 → 新开用印申请并关联原单，旧盖章件作废登记
  • 历史软著对接人不明 → 在台账标“待认领”，由知识产权归口在 10 个工作日内追溯并补登记

7. 衡量指标

  • 主体确认周期：立项到主体结论的工作日，目标 ≤ 3 个工作日
  • 一次通过率：代理复核无需大改的件数 / 总件数，目标 ≥ 80%
  • 台账完整率：有主体、对接人、证书号的软著 / 全部软著，目标 100%
  • 主体错误数：下证后发现主体与合同/退税主体不一致的件数，目标 0

8. 低效诊断

  • 现象：申报主体没有规则，开源社区软著挂哪个主体来回确认，连续多轮催主体｜依据：「【模态】知识产权」2026-06
  • 现象：代理要求修改后需重新盖章，盖章人难以追溯｜依据：「【模态】知识产权」2026-06
  • 现象：历史软著对接人无人知晓，台账缺失｜依据：「【模态】知识产权」2026-07
  • 现象：初稿由谁写不明确，代理机构不负责写初稿，临时找人｜依据：「Leap产研测」2026-06
  • 现象：知识产权申请被反复延后，缺少负责人｜依据：「鼎慧产研决策部」2026-03
  • 现象：子公司项目启动前才发现著作权人拟挂合作高校，存在多方权属扯皮风险｜依据：「曜途同步群」2026-08

9. 分支变体

  • LeapCore：因软件退税，著作权人须与销售合同主体一致，软著名称与合同中软件名称对应
  • 鼎慧：软著用鼎慧主体，盖鼎慧章
  • 开源聚变社区：挂模态主体或研究院的讨论，需确定后授权
  • 子公司曜途：著作权放在曜途，合作高校不作为著作权人（以 CEO 意见为准）
  • LeapCore / LeapAll 分别申请

10. 待确认问题

  • “合同从哪家主体走就申请到哪家”是否作为正式主体选择规则？有无例外？
  • 软著材料撰写是否固定由产品线产品经理负责？
  • 主体决策由 COO 还是 CEO 拍板？
  • 子公司与合作高校的知识产权归属是否需在合作协议中前置约定？
  • 软著费用由总经办统一承担还是归集到产品线？
POL-11专利申报（交底→技术审核→代理撰写→定稿→缴费）待优化135

状态：待优化｜证据：有证据（卡片 3 张 / 会话 5 个）｜优先级：频3 × 耗5 × 跨3 × 险3

  • 适用场景：研发产生可申请专利的技术方案、核心功能被抄袭需要保护，或公司要求在政策/人才申报前集中出专利时，从技术交底到代理撰写、定稿、缴费完成专利申请提交
  • 负责人：主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——技术审核（当前：丁震宇·推断待确认）、发明人（各研发组，当前：季学森、宋祺睿·推断待确认）、提案人（当前：杨萌·推断待确认）、专利转让与商务对接（当前：常元和·推断待确认）、外部专利代理机构；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 技术成果登记提案 → ② 按模板写交底书 → ③ 内部技术审核（可专利性、泄密、合并/舍弃）→ ④ 邮件提交代理并抄送总经办 → ⑤ 代理撰写初稿 → ⑥ 发明人核稿定稿 → ⑦ 递交与缴费 → ⑧ 台账更新转入审查跟进
  • 交付结果：已递交并取得受理号的专利申请、经内审的交底书、专利台账记录（案号、名称、发明人、状态、下一步责任人、截止日）
  • 状态依据：2026-06 总经办已发布《专利/软著申报流转流程》并有《技术交底材料撰写要求》模板；但此前长期靠群聊加邮件，代理邮件有的未抄送总经办；技术审核集中在一人，自述改不过来；2026-07 代理所默认交底“都可以写”直接分配撰写，事后内部才审，一批申请全部撤回；代理混淆多篇专利名称、重复发稿，需反复确认

1. 场景判定

  • 触发条件：研发完成新算法、新架构、新交互等可能具有新颖性的方案；发现外部抄袭公司核心功能；CEO 要求在政策/人才申报节点前集中投专利；受让外部专利需要办理手续
  • 典型说法：「我们的测算功能可以申请专利吗」「尽可能专利这个月全部写完投出去」「正式申报资料须经总经办审核后提交」「最好的策略就是我们内部加个内审」
  • 判断问题：要保护的是“技术方案/方法”而不是代码或名称？交底书是否已经过内部技术审核？没审过的不得发给代理撰写
  • 不归本流程管：代理修改意见、国知局审查意见答复 → 请走 LEG-14；专利培训与激励兑现 → 请走 LEG-15；软著 → 请走 POL-10；商标 → 请走 LEG-16；抄袭侵权的取证维权 → 请走 LEG-17；人才/科技申报材料 → 请走 POL-04 / POL-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提案人/发明人 登记技术成果、写交底书、核对代理稿 R 各研发组发明人（当前：季学森、宋祺睿、杨萌·推断待确认）
技术审核 审合理性、可专利性、技术泄露风险，给出合并/舍弃意见 A 创始人兼 CTO（当前：丁震宇·推断待确认）
知识产权归口 立项、对接代理、确认递交、缴费、维护台账、进度推送 R 总经办（当前：赵雪冰·推断待确认）
外部代理 检索评估、撰写申请文件、递交 R（外部） 专利代理机构
专利转让对接 外部受让专利的商务与手续 R COO（当前：常元和·推断待确认）
集中申报决策 决定批量投出节奏与政策申报关联 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 技术交底书（按《技术交底材料撰写要求 V1》）：技术领域、背景与现有方案缺陷、本方案、关键步骤与附图、有益效果、可替代方案
  • 发明人名单及排序、申请主体（通过统一表单收集，不在群里私发证件）
  • 相关现有技术或竞品资料，自检是否已公开（论文、开源、对外演示）
  • 申请类型意向（发明/实用新型/外观）与期望递交日期、关联的申报项目

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在专利台账登记提案：名称、发明人、所属产品、来源（研发成果/抄袭防御/集中申报） 提案人 产生想法后 5 个工作日内 多维表格表单 提案记录 🔧飞书固化
2 编写技术交底书，可用 AI 起草初稿后人工补全 发明人 登记后 10 个工作日内 交底书模板 + AI 交底书 🤖+👤
3 内部技术审核：可专利性、是否泄露核心细节、与已有提案合并或舍弃 技术审核 收到后 5 个工作日内 飞书审批 审核结论（通过/修改/舍弃） 👤人工判断
4 审核通过后邮件提交代理，抄送总经办飞书邮箱；要求代理先回检索与合并建议 发明人、知识产权归口 审核通过后 2 个工作日内 邮件 委托记录 🔧飞书固化
5 代理撰写初稿 外部代理 按委托约定，一般 10～15 个工作日 邮件 申请文件初稿 👤人工判断
6 发明人核稿，修改意见回复代理，定稿抄送总经办 发明人 收稿后 5 个工作日内 邮件 定稿 👤人工判断
7 总经办确认递交、安排缴费，台账记录申请号与递交日 知识产权归口 定稿后 3 个工作日内 台账 + 付款审批 受理号、缴费记录 🔧飞书固化
8 每周机器人推送台账中“下一步责任人 + 截止日”，转入 LEG-14 跟进官文 知识产权归口 每周一 飞书机器人 周进度 🤖自动化

5. 交付物与模板

  • 交付物：交底书、内审结论、委托邮件、申请文件定稿、受理通知、缴费凭证、台账记录
  • 建议模板/表单：
    • 专利台账字段：内部编号、案号、名称、类型、申请主体、发明人及排序、技术审核结论、代理机构与代理师、状态（提案/交底/内审/代理撰写/核稿/已递交/实审/授权/撤回）、下一步责任人、截止日、关联申报项目
    • 内审表字段：可专利性判断、创造性/客体风险、泄密风险、合并或舍弃建议、审核人、日期

6. 异常与升级

  • 代理未经内审即开始撰写 → 暂停并要求代理先回合并/舍弃建议 → 已产生费用的升级综合部负责人与代理协商（3 个工作日内）
  • 技术审核积压超过 5 个工作日 → 由技术审核指定的备岗审核人分担 → 仍积压升级 CTO 确定优先级
  • 代理混淆专利名称、重复发稿 → 以台账内部编号为准逐件核对，要求代理邮件标题写内部编号
  • 集中申报节点前来不及 → 由 CEO 决定是否降为实用新型或调整批次
  • 发现方案已公开（论文、开源、演示）→ 技术审核判断是否仍可申请，必要时舍弃

7. 衡量指标

  • 内审覆盖率：经内部技术审核后才发代理的提案 / 全部发代理提案，目标 100%
  • 撤回率：递交前后撤回的件数 / 委托件数，目标 ≤ 10%
  • 交底到递交周期：交底书提交到递交的自然日，目标 ≤ 45 天
  • 抄送合规率：抄送总经办的代理往来邮件 / 全部，目标 100%

8. 低效诊断

  • 现象：流程成文前代理往来未抄送总经办，进度只能靠群里问｜依据：「【模态】总经办」2026-04、「【模态】知识产权」2026-06
  • 现象：技术审核集中在一个岗位，集中申报期改不过来｜依据：「【模态】综合部」2026-04
  • 现象：代理所默认交底都可写、直接分配撰写，内部事后审核，一批申请全部撤回｜依据：「董事会专项沟通群」2026-07
  • 现象：发现被抄袭后才想到申请专利，提出后无人受理跟进｜依据：「工程咨询产研」2026-03

9. 分支变体

  • 发明 / 实用新型 / 外观设计走同一流程，类型由技术审核与代理共同建议
  • 新增提案可先由技术负责人或其下属拟稿，再发代理
  • 外部受让专利（如高校专利转让）：走转让手续，进入实审后转 LEG-14
  • 集中申报批次：CEO 设定批次截止日，台账按批次视图跟踪
  • 代理日常技术咨询可直接对接，报批环节必须归口总经办

10. 待确认问题

  • 技术审核是否只能由 CTO 承担？能否按产品线指定备岗审核人？
  • 交底到递交 45 天目标、内审 5 个工作日是否可行？
  • 是否用飞书审批固化“交底提交—技术审核—定稿”？
  • 申请主体规则是否与软著一致？
  • 与代理所的委托约定中是否写明“先给检索与合并建议再撰写”？
POL-14企业资质认定与年度维护（高新技术企业、科技型中小企业、专精特新等）待新建推断200

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗5 × 跨4 × 险5

  • 适用场景：各主体的企业资质临近到期、年度评价窗口开放，或新主体满足认定条件时启动
  • 负责人：主责——政策申报专员（当前：待指定）；协同——财务（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）、法务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）
  • 核心流程：① 建资质日历 → ② 条件自评 → ③ 差距补足 → ④ 材料编制与专项审计 → ⑤ 内审用印 → ⑥ 提交跟踪 → ⑦ 证书入库与优惠落地 → ⑧ 年报与变更报告
  • 交付结果：按期取得/保持的资质证书、年度报告回执、资质日历与资质库更新
  • 状态依据：已有 POL-03（资质证书等申报资料库）、POL-08（周期性政府报表与年检填报）覆盖部分环节，本条补齐企业资质的认定条件自评、认定申报与年度维护日历（推断）

1. 场景判定

  • 触发条件：高企证书有效期剩余不足 1 年；科技型中小企业年度评价开放；专精特新/创新型中小企业申报通知；主体更名或重大变化
  • 典型说法：「高企明年到期了吧」「今年科小入库开始了」
  • 判断问题：是资质认定（长期证书），还是一次性项目申报？前者走本流程
  • 不归本流程管：科技项目申报 → 请走 POL-04；人才计划 → 请走 POL-05；申报资料调用 → 请走 POL-03；软件业月报/年报、LEI 续期等周期性填报 → 请走 POL-08；税务申报 → 请走 FIN-35；高企研发费用加计扣除的汇算 → 请走 FIN-42

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 日历维护、自评、材料编制、提交 R 政策申报专员（当前：待指定）
财务 研发费用与收入数据、专项审计对接、税收优惠备案 R 财务专员（当前：待指定）
人事 科技人员名单、学历与社保数据 C 人事专员（当前：待指定）
研发负责人 研发项目说明、知识产权与产品对应关系 C 研发负责人（当前：待指定）
政策申报负责人 审核、决定是否申报 A 政策申报负责人（当前：王蕊·部门报送人）

3. 办之前请准备

  • 各主体资质清单与有效期
  • 近 3 年财务报表、研发费用辅助账、高新产品收入明细
  • 知识产权清单（专利、软著）及与产品的对应关系
  • 员工花名册（学历、岗位、是否科技人员）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按主体建资质日历（到期日、年报日、评价窗口） 政策申报专员 每年 1 月 多维表格 资质日历 🔧飞书固化
2 对照认定条件自评（研发费用占比、高新收入占比、科技人员占比、知识产权） 政策申报专员+财务+人事 到期前 6 个月 自评表 差距清单 🤖+👤
3 补足差距：研发项目立项归集（FIN-31）、知识产权布局（POL-10/11） 研发负责人+财务 到期前 3 个月 项目台账 补足记录 👤人工判断
4 委托会计师事务所出具专项审计，编制申报书 政策申报专员 窗口截止前 1 个月 申报系统 申报材料 👤人工判断
5 负责人审核、用印（LEG-09） 政策申报负责人 截止前 10 个工作日 飞书审批 盖章材料 🔧飞书固化
6 线上提交，跟踪评审与公示 政策申报专员 按通知 申报系统 提交回执 👤人工判断
7 证书入资质库（POL-03），通知财务办理税收优惠 政策申报专员 取证后 5 个工作日内 资质库 更新记录 🔧飞书固化
8 按规定填报年度发展情况报告；更名或重大变化及时报告 政策申报专员 按年报节点 申报系统 年报回执 🤖自动化（提醒）

5. 交付物与模板

  • 交付物：资质证书、专项审计报告、年报回执
  • 建议模板/表单：资质日历（主体、资质名、证书号、有效期、年报日、负责人、状态）；自评表（各项指标、数值、是否达标、补足措施）

6. 异常与升级

  • 自评不达标且来不及补足 → 2 个工作日内报政策申报负责人决定是否放弃或换主体
  • 被抽查/复核要求补材料 → 当天通知财务与研发，按要求时限提交

7. 衡量指标

  • 资质到期断档次数，目标 0
  • 年报按期完成率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在资质到期断档、研发费用与收入口径不满足条件、税收优惠无法享受或被追缴的风险（推断）

9. 分支变体

  • 各主体（模态、鼎慧、跃迁等）分别认定，数据不得混用；研究院类机构按其主管部门要求另行维护

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各主体目前持有哪些资质、何时到期？
  • 专项审计由代账/事务所固定合作还是每次比价？
POL-15获批项目执行、专项资金使用与验收结题待新建推断160

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：科技项目、补贴、资助或券类项目获批立项后，至验收结题与事后抽查的全周期
  • 负责人：主责——项目负责人（当前：待指定）；协同——政策申报专员（当前：待指定）、财务（当前：待指定）、研发（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）
  • 核心流程：① 签任务书建台账 → ② 设专账 → ③ 资金到账入账 → ④ 按预算执行 → ⑤ 季度跟踪 → ⑥ 中期检查/变更申请 → ⑦ 验收结题 → ⑧ 档案留存
  • 交付结果：项目台账、专项资金辅助账、中期与验收材料、结题证书/验收意见、完整项目档案
  • 状态依据：已有 POL-06（验收报告等佐证材料编制）、POL-07（补贴申领资料归集）覆盖部分环节，本条补齐项目获批后的执行跟踪、专项资金使用与验收结题（推断）

1. 场景判定

  • 触发条件：收到立项通知/任务书；资金到账；主管部门发中期检查、验收、绩效评价或审计通知
  • 典型说法：「项目批下来了，后面要做什么」「钱到了怎么用」「要验收了，指标怎么证明」
  • 判断问题：项目是否已获批？申报阶段走 POL-04，获批后走本流程
  • 不归本流程管：申报材料编写 → 请走 POL-04；佐证报告编制 → 请走 POL-06；费用类补贴申领 → 请走 POL-07；补助资金入账与专款核算的财务细则 → 请走 FIN-44

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目负责人 按任务书推进、对指标负责 R 项目负责人（当前：待指定）
政策申报专员 台账、节点提醒、对接主管部门 R 政策申报专员（当前：待指定）
财务 专账核算、支出合规、决算与审计 R 财务专员（当前：待指定）
政策申报负责人 变更与验收材料审批 A 政策申报负责人（当前：王蕊·部门报送人）
CEO 重大变更、退资决策 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 立项通知、任务书/合同、批复预算与考核指标
  • 联合单位协议（如有）与分工

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签任务书，建项目台账（指标、节点、预算、配套要求） 政策申报专员 立项后 5 个工作日内 多维表格 项目台账 🔧飞书固化
2 设专项资金辅助账，明确可列支科目 财务 立项后 10 个工作日内 财务系统 辅助账 👤人工判断
3 资金到账确认并按政府补助入账 财务 到账后 3 个工作日内 财务系统 入账凭证 👤人工判断
4 按预算支出；超预算或调科目事前审批 项目负责人 支出前 飞书审批 审批记录 🔧飞书固化
5 季度更新进度、指标完成度、支出进度，节点前 1 个月预警 政策申报专员 每季度末 多维表格 季度报告 🤖自动化（提醒）
6 中期检查材料；负责人/内容/期限变更事先向主管部门申请 项目负责人 按通知 主管部门系统 检查/变更材料 👤人工判断
7 验收：指标佐证（POL-06）、专项审计、财务决算、验收汇报 项目负责人+财务 到期前 2 个月启动 申报系统 验收材料 👤人工判断
8 全套档案归档，备事后抽查 政策申报专员 结题后 10 个工作日内 知识库 项目档案 🔧飞书固化

5. 交付物与模板

  • 交付物：项目台账、辅助账、季度报告、验收材料、档案
  • 建议模板/表单：项目台账（项目名、主管部门、主体、负责人、批复预算、已支出、考核指标、完成度、下个节点、风险）

6. 异常与升级

  • 指标预计无法完成 → 节点前 2 个月报政策申报负责人，评估申请变更或延期
  • 发现支出不合规 → 财务立即暂停，报 CEO 决定调整或退回

7. 衡量指标

  • 按期结题率，目标 100%
  • 专项资金审计问题数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在资金未专款专用被追回、指标未达标验收不通过、档案缺失影响后续申报信用的风险（推断）

9. 分支变体

  • 联合申报项目：牵头方与参与方分别核算，按协议划拨；券类项目（上云券等）以使用凭证代替资金核算

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 目前在执行中的获批项目有哪些、各由谁负责？
  • 项目负责人默认由谁担任（申报人还是研发负责人）？
POL-16申报代理/中介机构选用与服务管理待新建推断48

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨3 × 险4

  • 适用场景：决定委托外部机构代办资质认定、项目申报、人才申报、软著/专利或补贴申领，或外部机构主动推销代办服务时启动
  • 负责人：主责——政策申报专员（当前：待指定）；协同——法务专员（当前：待指定）、财务（当前：待指定）；兜底——政策申报负责人（当前：王蕊·部门报送人）
  • 核心流程：① 自办/委托判断 → ② 机构资质核查 → ③ 比价选择 → ④ 合同审核 → ⑤ 材料提供与保密 → ⑥ 过程审核 → ⑦ 按结果付款 → ⑧ 年度评价
  • 交付结果：合格机构名录、经法务审核的服务合同、服务评价记录
  • 状态依据：已有 POL-11（专利代理对接）、CEO-19（外部合作方/顾问评估）覆盖部分环节，本条补齐申报类代理/中介机构的准入核查、合同约束与服务评价（推断）

1. 场景判定

  • 触发条件：申报事项决定委托外部机构；收到机构推送并承诺代办
  • 典型说法：「有家机构说可以帮我们包办」「这个能不能找中介做」
  • 判断问题：是否需要把公司材料与账号交给外部？涉及则走本流程
  • 不归本流程管：已选定代理后的软著/专利案件流程 → 请走 POL-10/POL-11；政策线索研判 → 请走 POL-01；非申报类外部顾问、代写或渠道伙伴的评估与分成 → 请走 CEO-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
政策申报专员 核查、比价、对接、过程审核 R 政策申报专员（当前：待指定）
法务 合同条款审核 C 法务专员（当前：待指定）
财务 付款与发票 C 财务专员（当前：待指定）
政策申报负责人 选定机构 A 政策申报负责人（当前：王蕊·部门报送人）

3. 办之前请准备

  • 委托事项、截止日、预计材料清单
  • 机构营业执照、过往案例、报价单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判断自办还是委托（复杂度、时间、内部能力） 政策申报专员 收到需求后 2 个工作日内 — 判断结论 👤人工判断
2 核查机构资质、失信记录、案例；拒绝“包过”“材料包装”承诺 政策申报专员 1 个工作日内 企业信用查询 核查记录 🤖+👤
3 至少 2 家比价，负责人选定 政策申报负责人 2 个工作日内 飞书审批 选定结论 🔧飞书固化
4 合同明确范围、费用结构、按结果付费、保密、材料真实性责任 法务 3 个工作日内 LEG-04 定稿合同 👤人工判断
5 按最小必要提供材料，账号由我方登录操作 政策申报专员 按进度 加密共享 材料交接记录 👤人工判断
6 机构编写材料须经我方审核后才能提交 政策申报专员 提交前 飞书文档 审核记录 👤人工判断
7 按合同节点付款并收票 财务 结果确认后 FIN-01 付款凭证 🔧飞书固化
8 年度评价机构，更新名录 政策申报专员 每年 12 月 多维表格 机构名录 🔧飞书固化

5. 交付物与模板

  • 交付物：机构名录、服务合同、评价记录
  • 建议模板/表单：机构名录（名称、服务类型、合作事项、费用模式、结果、评价、是否继续合作）

6. 异常与升级

  • 发现机构材料虚构或夸大 → 立即停止提交 → 报政策申报负责人与法务
  • 机构要求公司账号密码 → 拒绝，由我方操作或按 X-SEC-10 受控分发

7. 衡量指标

  • 委托事项合同覆盖率，目标 100%
  • 委托事项成功率与单项平均费用，按年统计

8. 低效诊断

  • 聊天中未见相关流程，存在机构虚构材料导致公司失信、费用不透明、公司资料与账号外泄的风险（推断）

9. 分支变体

  • 无

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 目前有哪些长期合作机构？
  • 是否所有委托都需法务审合同，还是只限超过公司采购阈值的？

MKT 生态市场（其他）

报送人：许君 · 生态市场条线 · 20 条 · 已有 0 / 待优化 7 / 待新建 13
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
MKT-01外部活动/展会情报收集与参与决策任何人发现外部行业大会、展会、厂商沙龙、黑客松、开发者 Meetup、社区活动或有奖赛事，需要判断公司是否参加、摆摊、赞助或做议题，并在报名截止前完成报名时启动。主责——生态活动运营（当前：陈梦琪·推断待确认）；协同——运营（活动信息订阅，当前：待指定）、比赛/案例组长（当前：白福康·推断待确认）、研发负责人（技术社区活动评估与小额预算，当前：丁震宇·推断待确认）、CEO（参展/参赛主体与超阈值投入拍板，当前：邴龙志·推断待确认）；兜底——生态市场条线负责人① 线索登记 → ② 每周汇总与截止提醒 → ③ 初评分级 → ④ 参与决策与主体确认 → ⑤ 报名/赞助申请 → ⑥ 转执行（MKT-03） → ⑦ 见闻回传归档外部活动台账中每条线索都有“参加/不参加”结论、参与形式、参与主体、负责人和报名状态；决定参加的活动在截止日前完成报名并转入 MKT-03。待新建72
MKT-02发布会立项与预算审批计划举办产品发布会（线上/线下/借外部大会发布）或阶段性加大市场投入时，从动议到立项、产品发布门槛评审、预算审批、对外材料定稿和排期。主责——市场负责人（当前：待指定）；协同——产品总监（产品定义与发布门槛，当前：杨萌·推断待确认）、研发负责人（技术就绪与预算建议，当前：丁震宇·推断待确认）、宣发材料制作（当前：王皓南·推断待确认）、COO（方案与商务，当前：常元和·推断待确认）、运营（当前：待指定）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人① 提出动议 → ② 提交立项单 → ③ 发布门槛评审 → ④ 预算审批 → ⑤ 排期与分工 → ⑥ 产品一页纸与对外材料定稿 → ⑦ 转执行 → ⑧ 发布后复盘经 CEO 审批的发布会立项单（目标、发布内容、预算、排期、负责人）、通过评审的产品一页纸与对外材料、发布后复盘。待新建128
MKT-03参展/大会报名与现场执行统筹已决定参加或举办展会、大会、赛事、沙龙、Meetup 后，从确定参会人和名额、参会审批、票务差旅、展区分工与话术、排班与加班报备，到现场执行、会后复盘与报销的全过程。主责——生态市场总监（当前：许君·推断待确认）；协同——会务/生态活动运营（当前：陈梦琪·推断待确认）、产品总监（展区与话术，当前：杨萌·推断待确认）、销售（排班与路演，当前：刘昱潇、闫登辉、杜中瑞、时建、杨朋伟·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、行政（票务与差旅，当前：侯明月·推断待确认）、人事（加班审批与招聘物料，当前：待指定）、财务（报销，当前：待指定）；兜底——CEO① 建活动任务并指定负责人 → ② 确定参会人与名额 → ③ 参会审批 → ④ 报名信息与票务差旅 → ⑤ 展区分工/话术/物料/演示准备 → ⑥ 排班与加班报备 → ⑦ 现场执行 → ⑧ 会后复盘与报销活动执行台账（人员、排班、物料、演示、预算）、参会审批单、展区话术文档、现场线索表（转 MKT-07）、复盘纪要、按口径完成的报销。待新建300
MKT-04自办渠道大会邀请与授牌确认公司自办渠道合作伙伴大会、行业沙龙、FDE 开班等需要邀请外部企业的正式活动前，汇总邀请名单、确认签约/授牌/上台对象、发放邀请函，并在改期时同步。主责——销售运营（当前：韩诗琪·推断待确认）；协同——各销售（邀约与填报，当前：杜中瑞、吴琪等·推断待确认）、会务（当前：陈梦琪·推断待确认）、法务（授牌协议，当前：待指定）；审核——生态市场总监（当前：许君·推断待确认）；任务下达——销售负责人（当前：李鹏为·推断待确认）；兜底——销售负责人① 定日期与邀约指标 → ② 发布名单表（必填校验） → ③ 销售填报 → ④ 截止收口 → ⑤ 名称与授牌/上台核对 → ⑥ 审核定版 → ⑦ 发邀请函与回执 → ⑧ 改期同步与会前终版审核定版的邀请名单（企业全称、简称、联系人、是否签约/授牌/上台）、邀请函回执、授牌与上台清单（交会务和现场执行 MKT-03）。待优化120
MKT-05展会/大会/发布会演示环境与设备准备展会、大会、发布会、渠道大会或客户现场需要产品演示时，准备演示场景与脚本、演示版本与环境、数据与账号、录屏兜底、设备运输与网络、产研现场支持，结束后回收硬件。主责——产品总监（演示统筹，当前：杨萌·推断待确认）；协同——演示设计（当前：王皓南·推断待确认）、环境与数据（当前：宋祺睿、杨云峰·推断待确认）、硬件与网络（当前：杨明学、游家豪·推断待确认）、测试（当前：张东郅·推断待确认）、客户端演示版（当前：岳阳、李铭熙·推断待确认）、现场演示人（当前：闫登辉、吴琪、王满、胡橙橙·推断待确认）；决策——研发负责人兼 CTO（当前：丁震宇·推断待确认）；兜底——研发负责人兼 CTO① 演示需求单 → ② 场景与脚本 → ③ 演示版本冻结与环境/账号/额度 → ④ 设备与网络 → ⑤ 素材合规审查与录屏兜底 → ⑥ 冒烟测试、彩排与培训 → ⑦ 现场 oncall → ⑧ 硬件回收与复盘演示准备清单全部勾选（脚本、冻结版本、独立演示环境、账号与额度、设备、网络备份、录屏视频、负责人）、彩排记录、硬件回收登记与演示复盘。待新建240
MKT-06活动物料与礼品制作及回收活动或摆摊前需要备齐易拉宝、海报、传单、贴纸、二维码、积分卡、抽奖礼品、3D 打印礼品等，从需求、出稿、校对、采购打印或分工制作，到带去现场、活动后归还入库与费用报销。主责——行政（物料制作与采购，当前：侯明月·推断待确认）；协同——活动负责人（提需求，当前：杨萌、陈梦琪·推断待确认）、设计出稿（当前：王皓南·推断待确认）、审稿与预算（当前：丁震宇·推断待确认）、人事（招聘二维码，当前：黄莹·推断待确认）、制作联系（当前：潘浩伟·推断待确认）、3D 打印小组（当前：葛家和、吴世豪、宋祺睿、杨明学·推断待确认）、抽奖环节（当前：葛家和·推断待确认）、财务（当前：待指定）；兜底——行政负责人① 提物料需求单 → ② 按模板出稿 → ③ 校对审稿 → ④ 比价下单或分工制作 → ⑤ 验收清点入库 → ⑥ 出库带往现场 → ⑦ 活动后归还入库 → ⑧ 费用报销按时到场且无错误的活动物料与礼品、物料出入库登记、电子版终稿归档在物料库、费用报销单。待新建108
MKT-07活动后线索跟进与转化复盘参加展会、沙龙、座谈会、数转活动、线下 Meetup 或抽奖/扫码引流活动后，统一录入线索、分配跟进、统计转化并复盘活动价值。主责——生态活动运营（活动复盘负责人，当前：陈梦琪·推断待确认）；协同——CRM 管理员（线索录入与分配，当前：闫登辉·推断待确认）、参会销售（跟进，当前：陈名赞、时建、杜中瑞·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营（公司号与社群，当前：待指定）；兜底——销售负责人① 活动前定目标客户画像 → ② 统一引流码与线索表单 → ③ 现场采集 → ④ 24 小时内入 CRM 并分配 → ⑤ 3 个工作日内首次跟进 → ⑥ 拜访/拉群 → ⑦ 活动复盘 → ⑧ 月度转化统计CRM 中带活动来源标记的线索（含分配人、跟进状态）、单场活动复盘（线索数、匹配度、转化）、月度活动渠道 ROI 统计。待新建135
MKT-08外部布道/分享活动接单与讲师分工高校社群、政府部门、团委、国企、中小企业服务机构、OPC 社群等主办方邀请公司做技术/产品分享（如 OpenClaw 布道）时，从接单登记、评估场次、指派讲师、向主办方报题目与讲师简介，到现场分享、引流和复盘。主责——布道活动对接人（当前：李鹏为·推断待确认）；协同——布道统筹（定策略、选讲师、内容 review，当前：丁震宇·推断待确认）、讲师（当前：李子遥、望政韬、马漳毓·推断待确认）、活动线索提供人（当前：邴龙志、闫登辉、杨朋伟·推断待确认）、品牌（讲师简介库，当前：待指定）、法务（当前：待指定）；兜底——生态市场条线负责人① 主办方填需求单 → ② 登记布道场次台账并定目的 → ③ 评估是否接 → ④ 指派主讲/辅助 → ⑤ 从简介库选定讲师简介并经本人确认 → ⑥ 报题目与简介给主办方 → ⑦ 准备与内容 review → ⑧ 现场分享与引流 → ⑨ 复盘布道场次台账中每场都有主办方需求、目的、主讲/辅助、经本人确认的简介、PPT 版本、效果与线索；对外讲师头衔口径统一、真实。待新建180
MKT-09演讲/布道 PPT 与演示素材制作、评审及外发布道/分享场次与讲师已确定，或 CEO/高管受邀在外部峰会、大会演讲，需要按听众做一版 PPT（含讲稿、演示 Demo），评审定版交主办方；主办方要求提前拿材料时按水印 PDF 外发主责——布道/演讲材料负责人（当前：李子遥·推断待确认）；协同——峰会演讲材料执行（当前：许君·推断待确认）、讲师（当前：望政韬、马漳毓·推断待确认）、技术口径评审（当前：丁震宇、王皓南·推断待确认）、演示素材录制（当前：邓乾、张康、宋祺睿·推断待确认）、视频剪辑（当前：宫经喜·推断待确认）、主办方对接（当前：李鹏为·推断待确认）、现场设备调试（当前：侯明月·推断待确认）；兜底——生态市场条线负责人① 登记场次与听众 → ② 从母版库出初稿 → ③ 选取/补录 Demo 素材 → ④ 内容与技术口径评审 → ⑤ 定版并配讲稿/提词器 → ⑥ 现场试放彩排 → ⑦ 按需水印 PDF 外发 → ⑧ 回收归档到母版与 Demo 库定版 PPT（含备注讲稿）、演示视频/Demo、提词器版本、外发用水印 PDF、更新后的母版库与 Demo 库条目待优化180
MKT-10客户来访接待与演示客户、合作方来武汉考察交流，需要安排行程、场地、议程、席卡订餐、演示环境，并在会后形成纪要和跟进事项主责——销售总监/客户经理（当前：吴琪·推断待确认）；协同——渠道/演示负责人（当前：闫登辉·推断待确认）、业务专家演示（当前：王满·推断待确认）、会议与场地协助（当前：刘昱潇·推断待确认）、行政/展厅（当前：待指定）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 来访登记（时间、人数、名单、目的） → ② 确认场地（会议室/展厅） → ③ 定议程与我方参会人 → ④ 席卡、订餐、接送 → ⑤ 演示环境准备与预演 → ⑥ 接待执行 → ⑦ 会后纪要与跟进任务来访接待单、议程、席卡与餐饮安排、可用的演示环境、会议纪要与跟进任务待新建135
MKT-11演示机/试用机准备与分配管理市场、销售或渠道商需要一台演示机或试用/试销机（豪华演示机、工程版演示机、渠道试用机），需从申请、配置硬件软件网络到交付、登记去向和回收全程管理（非正式客户交付）主责——市场样机管理员（当前：陈芷青·推断待确认）；协同——市场需求负责人（当前：杨萌·推断待确认）、硬件/网络/账号（当前：游家豪·推断待确认）、软件与模型对接及资产（当前：杨明学·推断待确认）、渠道需求提单（当前：刘昱潇·推断待确认）、规格审批（当前：丁震宇·推断待确认）、现场协助（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）① 提申请（用途/规格/接收人/期限） → ② 规格确认与审批 → ③ 硬件准备 → ④ 网络接入 → ⑤ 软件模型配置与开账号 → ⑥ 账密托管 → ⑦ 交付给提单人并登记台账 → ⑧ 流转登记、到期回收与盘点可用的演示/试用机、演示机台账记录（编号、机器码、网段、管理员、去向）、交接单、回收记录待新建96
MKT-12外部合作与政府需求线索接收及分派外部公司、硬件厂商、电商渠道或政府部门联系我方谈合作、要培训方案或接待安排，需统一接收、指派对接人、安排试用，进入方案阶段后由单一负责人出方案 PPT 并统一口径主责——生态市场线索接口人（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、产品负责人/试用安排（当前：杨萌·推断待确认）、创始人兼 CTO/技术口径（当前：丁震宇·推断待确认）、运营/FDE（当前：李凯·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 任何人收到即登记转交 → ② 分类 → ③ 按路由表指派对接人 → ④ 首次联系与材料互换 → ⑤ 需要时安排试用 → ⑥ 方案阶段单人出方案与口径 → ⑦ 评审后对外提交 → ⑧ 结果写入 CRM合作线索登记记录、指派结果、首次沟通纪要、（如需）试用开通、合作方案/培训方案 PPT、CRM 跟进记录待新建60
MKT-13第三方平台/商城上架与消费券推广政府或第三方平台（武创通 AI 商城、OPC 社区商城、超算互联网商城）开放入驻、统一批次上架、征集活动厂商或发放体验券批次时，准备商品信息与合规文案、录入卡密、上架，并推动内部及用户领券购买主责——外部平台上架对接人（当前：杨萌·推断待确认）；协同——OPC 社区运营（当前：陈梦琪·推断待确认）、政策口径（当前：邴龙志·推断待确认）、研发/卡密与说明（当前：邓乾·推断待确认）、商城后端（当前：葛家和·推断待确认）、运营答疑与问卷（当前：胡橙橙·推断待确认）、宣发策略（当前：李凯·推断待确认）、平台入驻材料（当前：闫登辉·推断待确认）、平台通知转发（当前：宋祺睿·推断待确认）、新员工通知（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人① 平台通知登记并指定响应人 → ② 参与决策 → ③ 入驻材料 → ④ 商品信息与合规预审 → ⑤ 价格档位与卡密导入 → ⑥ 平台就绪检查后上架 → ⑦ 购买指南与 FAQ 发布 → ⑧ 领券推广答疑 → ⑨ 批次复盘已上架商品（名称合规、说明齐全、卡密到位）、购买指南与 FAQ、领券推广通知、问卷与销量汇总待优化180
MKT-14营销活动与裂变玩法策划及合规审批产品进入拉新或推广阶段，有人提出营销创意（砍一刀、拼车、大赛、校园大使/代理、KOL、赛事合作等），需要统一提报、细化方案与预算、合规把关、审批后执行并复盘；赛事主办方或校园大使索要算力券/API 额度时按权益菜单审批主责——运营负责人（当前：李凯·推断待确认）；协同——KOL/渠道运营（当前：胡橙橙·推断待确认）、校园地推方案（当前：刘昱潇·推断待确认）、校园大使与赛事合作（当前：陈梦琪·推断待确认）、渠道运营（当前：杨朋伟·推断待确认）、风控/防刷（当前：陈晖·推断待确认）、营销合规提醒（当前：李鹏为·推断待确认）、策略与技术可行性（当前：丁震宇·推断待确认）、预算审批（当前：邴龙志·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人① 点子入池 → ② 每周初筛 → ③ 细化活动策划卡 → ④ 合规评审 → ⑤ 预算与权益审批 → ⑥ 排期执行 → ⑦ 发放登记与对账 → ⑧ 复盘审批通过的活动策划卡、合规评审意见、预算/权益审批单、发放与对账记录、活动复盘报告待新建180
MKT-15推广投放预算审批与效果复盘运营或外部代理商提出投流、KOC、自媒体推广方案时，完成成本审核与预算审批、素材评审、上线投放、每周效果报告，预算耗尽或周期结束后复盘决定是否续投主责——跃竞业务负责人（当前：徐莉·推断待确认）；协同——内容/投放运营（当前：宫经喜·推断待确认）、销售/市场（当前：黄捷·推断待确认）、代理商方案审核（当前：杨萌、李鹏为·推断待确认）、关联业务方审批（当前：刘恒昊·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提投放方案 → ② 成本审核与比价 → ③ 预算审批 → ④ 素材评审 → ⑤ 上线投放 → ⑥ 每周效果报告 → ⑦ 预算耗尽/周期结束复盘 → ⑧ 决定续投、调整或停止审批通过的投放方案与预算单、评审过的素材、每周投放效果报告、复盘纪要与唯一负责人的待办清单待优化144
MKT-16产品版本更新向市场/销售同步新版本上线前或产品有可分享的新能力时，按“开发一版、预告一版、发布一版”向市场和销售同步新功能与 UI 变化，组织内部分享（脱敏），并准备可直接对外使用的材料主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、发版负责人（当前：宋祺睿·推断待确认）、内部分享主讲（当前：刘昱潇·推断待确认）、演示环境（当前：望政韬·推断待确认）、OPC/推文对接（当前：陈梦琪·推断待确认）、市场销售接收人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 版本规划时登记同步排期 → ② 发布前写市场版发布说明 → ③ 周一市场会预告并机器人提醒 → ④ 内测期准备售卖材料 → ⑤ 内部分享前脱敏与内容评审 → ⑥ 发布当天正式同步 → ⑦ 收集市场反馈 → ⑧ 对外推文经脱敏与口径审核市场版发布说明（新功能、UI 变化、话术、截图/视频）、预告记录、售卖材料、脱敏后的分享回放、市场反馈记录待优化72
MKT-17市场产品反馈汇总交接市场部在一个迭代周期内从客户、渠道、展会、演示、试用中收集到产品反馈，需要在产品排下一迭代前统一整理、交给产品负责人做优先级判断时启动主责——市场专员/销售运营（当前：韩诗琪·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/渠道对接人（当前：待指定）；兜底——生态市场条线负责人① 日常登记反馈 → ② 迭代前截止汇总 → ③ 去重归类（AI 初分）→ ④ 市场负责人复核 → ⑤ 交接给产品 → ⑥ 产品逐条给结论并排期 → ⑦ 结论回告市场与反馈人一份按固定模板整理、已去重归类的《产品反馈交接表》，以及产品对每条反馈的处理结论（纳入迭代/进需求池/不做及原因），并回告到原反馈渠道待优化72
MKT-18市场运营日报与沟通记录规范市场、运营、销售支持成员（含新入组成员与实习生）每个工作日下班前提交日报（部门群模板、多维表格或飞书汇报模块），为周例会和阶段复盘提供依据；以及市场条线与客户、渠道发生沟通（尤其在微信上）后，需要把关键信息沉淀到飞书/CRM 时启动主责——市场运营团队负责人（由鼎慧负责人/产品总监兼任，当前：杨萌·推断待确认）；协同——市场/运营/销售成员（当前：李宣昊、王满、吴琪、闫登辉、王皓南及运营实习生·推断待确认）、飞书与 AI 工具支持（当前：丁震宇、张东郅·推断待确认）；兜底——生态市场条线负责人；制度拍板——CEO（当前：邴龙志·推断待确认）① 发布日报规则与模板 → ② 当日沟通即时记入飞书/CRM → ③ 下班前按模板提交日报 → ④ 机器人截止前提醒、截止后汇总 → ⑤ 负责人次日上午回应协助项 → ⑥ 每周 AI 生成周报 → ⑦ 周会复盘 → ⑧ 月度抽查沟通记录完整性 → ⑨ 试行期满评估调整每日结构化日报记录（今日完成/明日计划/需要协助）、AI 生成的周报、客户沟通关键内容在飞书/CRM 中可检索的记录、试行评估结论待优化90
MKT-19市场年度计划、预算编制与费用执行跟踪每年末编制下一年度市场计划与预算，季度分解滚动，并按月跟踪市场费用执行时启动主责——市场经理（当前：待指定）；协同——品牌、研究院生态、销售负责人（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）① 收集目标 → ② 编制市场日历与预算 → ③ CEO 审批 → ④ 季度分解 → ⑤ 活动按预算立项占用 → ⑥ 月度执行台账 → ⑦ 超预算审批 → ⑧ 季度投入产出复盘经审批的年度市场计划与预算、月度费用执行台账、季度投入产出复盘待新建144
MKT-20市场活动与线索个人信息收集使用合规活动报名表、问卷、培训班报名、展会扫码、名片、线索名单、短信/电话邀约，以及把名单共享给渠道、外包或合作方时启动主责——市场经理（当前：待指定）；协同——法务专员（当前：待指定）、安全/IT 管理员（当前：待指定）、研究院生态与销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）① 表单告知同意 → ② 最小必要收集 → ③ 公司工具存储与权限 → ④ 合规使用（邀约/营销） → ⑤ 对外共享审批 → ⑥ 到期删除 → ⑦ 撤回与投诉处理 → ⑧ 年度自查法务审定的报名/问卷模板、个人信息名单登记台账、共享审批与删除记录待新建160
MKT-01外部活动/展会情报收集与参与决策待新建72

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：任何人发现外部行业大会、展会、厂商沙龙、黑客松、开发者 Meetup、社区活动或有奖赛事，需要判断公司是否参加、摆摊、赞助或做议题，并在报名截止前完成报名时启动。
  • 负责人：主责——生态活动运营（当前：陈梦琪·推断待确认）；协同——运营（活动信息订阅，当前：待指定）、比赛/案例组长（当前：白福康·推断待确认）、研发负责人（技术社区活动评估与小额预算，当前：丁震宇·推断待确认）、CEO（参展/参赛主体与超阈值投入拍板，当前：邴龙志·推断待确认）；兜底——生态市场条线负责人
  • 核心流程：① 线索登记 → ② 每周汇总与截止提醒 → ③ 初评分级 → ④ 参与决策与主体确认 → ⑤ 报名/赞助申请 → ⑥ 转执行（MKT-03） → ⑦ 见闻回传归档
  • 交付结果：外部活动台账中每条线索都有“参加/不参加”结论、参与形式、参与主体、负责人和报名状态；决定参加的活动在截止日前完成报名并转入 MKT-03。
  • 状态依据：无台账、无审批，活动信息靠个人在群里转发；2026-04 至 2026-10 多个群反复出现“去不去”“为什么没有我们”约 10 次；2026-07 因无人跟踪错过大会企业专属报名通道（截止已近一个月），属于漏项，判定待新建。

1. 场景判定

  • 触发条件：看到外部活动信息（大会、展会、沙龙、黑客松、Meetup、社区活动、有奖赛事、高校孵化项目）；主办方或合作方发来参展/参赛邀请；活动订阅机器人推送新活动。
  • 典型说法：「我们去不去××大会摆摊啊」「去不去××武汉 meetup」「为什么没有我们」「这个通道上个月就截止了」「可以派人去一下××用户组的活动」「以后所有赚钱的比赛，把信息都同步在这里」
  • 判断问题：这是一个“还没决定要不要参加”的外部活动吗？有没有报名截止日、展位/赞助/议题机会需要抢？
  • 不归本流程管：已决定参加后的报名执行、票务差旅、现场排班 → 请走 MKT-03；自办发布会立项 → 请走 MKT-02；自办渠道大会邀约 → 请走 MKT-04；主办方邀请我方讲师做分享 → 请走 MKT-08；演示环境 → 请走 MKT-05；物料制作 → 请走 MKT-06。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账负责人 维护外部活动台账、每周汇总、盯截止日、发起决策与报名 R 生态活动运营（当前：陈梦琪·推断待确认）
信息订阅 订阅全国/全球大型活动与活动平台数据，定期导入台账 R 运营（当前：待指定）
赛事线索 收集有奖金赛事、高校孵化需求，评估是否承接 R 比赛/案例组长（当前：白福康·推断待确认）
小额决策 授权范围内的技术/开源社区活动是否参加、小额赞助审批（超授权上报 CEO） R 研发负责人（当前：丁震宇·推断待确认）
主体与大额决策 确定参展/参赛主体，批准付费展位、联合主办、超阈值预算 A CEO（当前：邴龙志·推断待确认）
法务 评委回避、联合主办利益冲突意见 C 法务（当前：待指定）
线索提供人 发现活动后登记台账 C 全员
行政/财务 获知差旅与费用预估 I 行政、财务（当前：待指定）

3. 办之前请准备

  • 活动名称、主办方、时间地点、官方链接（报名入口、Luma、活动行等）
  • 报名、展位、议题、赞助各自的截止日期；是否有企业专属通道
  • 受众画像（开发者、政企、行业客户、高校学生）
  • 可参与形式：参会/摆摊/付费展位/议题演讲/赞助茶点/联合主办/参赛
  • 预估费用（展位、赞助、物料、差旅）与可用名额
  • 主目的（单选）：产品发布、品牌曝光、生态合作、获客、招聘引流
  • 特殊关系：我方人员是否担任评委、是否联合主办

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现活动后在“外部活动台账”表单登记（群里转发不算登记） 线索提供人 发现后 1 个工作日内 飞书多维表格表单 台账线索 🔧飞书固化
2 机器人定期抓取活动平台与行业大会信息入台账，按截止日 T-15/T-7/T-3 推送提醒 信息订阅 每周一 多维表格+机器人 新增线索、截止提醒 🔧+🤖
3 补全字段并初评分级：A 必参（行业顶级/目标客户集中）、B 可参（社区/沙龙）、C 观察 台账负责人 登记后 2 个工作日内 多维表格 分级与建议 👤人工判断
4 在每周市场例会过 A/B 类线索，给出参与形式、主体、负责人建议 台账负责人 每周一次，距截止日不少于 10 个工作日 飞书会议 决策待办 👤人工判断
5 发起“市场活动参与/赞助申请”审批：小额社区活动由研发负责人或条线负责人批；付费展位、联合主办、超阈值预算、参赛主体由 CEO 批 台账负责人 提交后 2 个工作日内出结论 飞书审批 审批结论 🔧飞书固化
6 涉及评委、联合主办的赛事，确认回避规则、参赛主体与对外宣传口径 法务+台账负责人 报名前 3 个工作日 飞书文档 回避与口径说明 👤人工判断
7 完成报名/企业通道申请/赞助确认，台账状态改“已报名”并上传回执 台账负责人 截止日前至少 3 个工作日 主办方系统、多维表格 报名回执 🔧飞书固化
8 创建活动任务、指定活动负责人，转入 MKT-03 执行 台账负责人 报名后 1 个工作日内 飞书任务 执行任务 🔧飞书固化
9 有人到场（含未正式参展）的活动，按模板回传见闻，AI 汇总入台账 到场人员 活动后 3 个工作日内 飞书文档模板 见闻纪要 🤖自动化

5. 交付物与模板

  • 交付物：外部活动台账（含决策结论、报名回执）、参与/赞助审批单、见闻纪要。
  • 建议模板/表单：
    • 外部活动台账：活动名称、类型（大会/展会/沙龙/黑客松/Meetup/社区/赛事/高校孵化）、主办方、城市、活动日期、报名截止日、链接、受众、可参与形式、预估费用、主目的、分级、决策结论、参与主体、活动负责人、报名状态、见闻链接
    • 参与/赞助申请审批：活动、形式、主体、目的与预期成果、预算明细（展位/赞助/物料/差旅）、参与人员、物料需求、是否放招聘海报
    • 见闻纪要：活动概况、热点方向、同行与竞品做法、潜在客户/合作方、对我们的建议

6. 异常与升级

  • 发现时距截止日不足 5 个工作日 → 台账负责人当天发起加急审批 → 升级 CEO（当天）
  • 无人认领参会/摆摊 → 台账负责人按目的直接指派 → 升级条线负责人（1 个工作日内）
  • 参赛主体、评委回避有争议 → 暂停报名，法务出意见 → 升级 CEO（2 个工作日内）
  • 事后发现错过重要活动 → 台账记录原因并调整订阅源 → 条线负责人在月度复盘中处理（当月）

7. 衡量指标

  • 截止前报名率 = 决定参加的活动中截止日前完成报名的比例，目标 100%
  • 决策时效 = 登记到出结论的工作日数，目标 ≤ 5 个工作日
  • A 类漏报数 = 事后发现未登记或错过的重要活动数，目标每季度 0
  • 见闻回传率 = 有人到场的活动中提交纪要的比例，目标 ≥ 80%

8. 低效诊断

  • 现象：活动信息无订阅、无台账，大会企业专属通道截止近一个月才发现，事后争论该由谁关注｜依据：「鼎慧产研决策部」2026-07
  • 现象：是否参展没有决策环节，展会开幕时才有人问“为什么没有我们”，见闻只停留在群聊｜依据：「模态AI探索小分队」2026-04
  • 现象：“去不去”在群里提议后无拍板人、无报名动作，停在讨论｜依据：「跃迁AI总动员」2026-10
  • 现象：社区活动赞助预算口头授权，派人参加互相推让｜依据：「Claw布道/案例组」2026-03
  • 现象：联合举办赛事以哪个主体参赛、评委是否回避无书面规则｜依据：「跃迁AI总动员」2026-08
  • 现象：有奖赛事信息只同步链接，缺奖金、截止日、承接人字段｜依据：「打比赛专用群」2026-04

9. 分支变体

  • 大型大会（WAIC 等）企业专属通道：提前 1～2 个月登记，按通道截止日倒排；主体与议题由 CEO 确认。
  • 联合举办/可参与的 AIGC 赛事：先定参赛主体（模态/鼎慧/跃迁等）与评委回避，再对外宣传；宣传口径按主办方要求。
  • 开源/Linux/Deepin 等技术社区活动：可做议题、赞助茶点并放招聘海报；小额预算由研发负责人批，海报走 MKT-06，招聘二维码由人事提供。
  • 有奖金赛事与高校孵化（国创赛、挑战杯等）：统一进赛事线索，由比赛/案例组长评估承接，财务知悉奖金归属。
  • 付费展位 vs 受邀参会：付费展位必须审批并写预期成果；受邀参会只需登记+简化审批。

10. 待确认问题

  • 外部活动台账由生态活动运营还是运营岗维护？运营是否需专人订阅全国/全球大型活动？
  • 社区活动小额赞助的授权上限是多少？超过多少需 CEO 审批？
  • 参展/参赛主体（模态、鼎慧、跃迁等）的选择规则是否已有？谁最终拍板？
  • 员工担任赛事评委的回避规则由谁制定？
  • 有奖赛事奖金归属与分配是否需要成文？
  • 每周活动同步是否放进现有市场例会？
MKT-02发布会立项与预算审批待新建128

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：计划举办产品发布会（线上/线下/借外部大会发布）或阶段性加大市场投入时，从动议到立项、产品发布门槛评审、预算审批、对外材料定稿和排期。
  • 负责人：主责——市场负责人（当前：待指定）；协同——产品总监（产品定义与发布门槛，当前：杨萌·推断待确认）、研发负责人（技术就绪与预算建议，当前：丁震宇·推断待确认）、宣发材料制作（当前：王皓南·推断待确认）、COO（方案与商务，当前：常元和·推断待确认）、运营（当前：待指定）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——生态市场条线负责人
  • 核心流程：① 提出动议 → ② 提交立项单 → ③ 发布门槛评审 → ④ 预算审批 → ⑤ 排期与分工 → ⑥ 产品一页纸与对外材料定稿 → ⑦ 转执行 → ⑧ 发布后复盘
  • 交付结果：经 CEO 审批的发布会立项单（目标、发布内容、预算、排期、负责人）、通过评审的产品一页纸与对外材料、发布后复盘。
  • 状态依据：2026-01 大额发布会预算在群里口头流转，决策人不明，被当场叫停；2026-04～05 产品定义和对外材料“明天就要交”、发布门槛（质量优先还是速度优先）争议、节后发布什么产品靠群里确认，约 5 次。无立项与评审环节，判定待新建。

1. 场景判定

  • 触发条件：有人提出办发布会、新品上市、年度/季度加大市场投入；市场例会要求各产品交定义和对外材料；拟借外部大会做产品发布。
  • 典型说法：「打算整个发布会，投一笔大的」「年后大量投入」「明天每个产品还要交一个定义和对外材料」「节后的发布会是发布啥的」「报告质量符合预期了再发」「宣发的速度一定要快」
  • 判断问题：是否需要公司投入专项预算或以公司名义对外发布新产品/新版本？
  • 不归本流程管：参加外部展会是否报名 → 请走 MKT-01；发布会现场执行与人员排班 → 请走 MKT-03；演示环境 → 请走 MKT-05；物料制作 → 请走 MKT-06；日常版本更新日志、发版闸门 → 请走 RND-51（正式版本发布上线）；海报/文案内容校对 → 请走 BRD-13。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
立项负责人 写立项单、组织评审、排期、跟踪执行 R 市场负责人（当前：待指定）
产品定义 产品一页纸、发布门槛自评、发布内容建议 R 产品总监（当前：杨萌·推断待确认）
技术就绪 确认版本稳定性、演示可行性、预算建议 C 研发负责人（当前：丁震宇·推断待确认）
宣发材料 AI 出稿宣发图、PPT、视频初稿 R 宣发材料制作（当前：王皓南·推断待确认）
方案与商务 发布会方案、合作方与定价口径 C COO（当前：常元和·推断待确认）
运营 发布节奏、渠道投放、发布后数据 C 运营（当前：待指定）
财务 预算科目、预算执行跟踪 C 财务（当前：待指定）
审批 立项与预算最终审批 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 发布目的与目标（签约数、线索数、曝光量、渠道招募数）
  • 发布内容候选：产品/版本（LeapCore、LeapAll、PPT 产品、工程 Agent 等）及当前成熟度
  • 时间窗口、形式（自办线下/线上直播/借外部大会）与场地候选
  • 预算草案：场地、搭建、物料、礼品、投放、差旅、外部嘉宾
  • 产品一页纸草稿（定义、核心卖点、价格、FAQ）
  • 发布门槛自评：功能完整度、稳定性、报告/输出质量、交付能力

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 动议人按模板提交立项单，群内口头预算不作数 立项负责人 发布日前至少 30 个自然日 飞书审批“市场活动立项” 立项单 🔧飞书固化
2 产品总监提交产品一页纸和发布门槛自评 产品总监 立项提交后 3 个工作日内 飞书文档模板 一页纸、门槛自评 🔧+🤖
3 召开发布评审会：确认发布什么、是否达门槛、质量与速度取舍 立项负责人 立项提交后 5 个工作日内 飞书会议 评审纪要（发布内容锁定） 👤人工判断
4 财务核对预算科目，CEO 审批立项与预算 财务、CEO 评审后 2 个工作日内 飞书审批 审批结论 🔧飞书固化
5 倒排里程碑并建任务：材料、物料、演示、邀约、投放 立项负责人 审批通过后 2 个工作日内 飞书任务/多维表格 排期表 🔧飞书固化
6 AI 出对外材料初稿（海报、PPT、新闻稿、FAQ），负责人审核定稿 宣发材料制作、产品总监 发布日前 10 个自然日定稿 AI 工具、飞书文档 对外材料终稿 🔧+🤖
7 转入执行：现场按 MKT-03、演示按 MKT-05、物料按 MKT-06 立项负责人 发布日前 10 个自然日 飞书任务 执行子任务 🔧飞书固化
8 发布后复盘：目标达成、预算执行、问题清单 立项负责人 发布后 5 个工作日内 飞书文档 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：立项审批单、产品一页纸、发布评审纪要、排期表、对外材料终稿、复盘报告。
  • 建议模板/表单：
    • 立项单：名称、目的、目标指标、发布内容、形式、时间、地点、预算明细、负责人、关联产品负责人
    • 产品一页纸：产品定义、目标客户、核心卖点（≤3 条）、价格/版本、FAQ、对外禁用说法
    • 发布门槛清单：核心流程可演示、P0/P1 缺陷清零、输出质量达标样例、交付与售后承接人、对外材料审核人

6. 异常与升级

  • 未立项先在群里承诺投入或对外宣布 → 立项负责人补立项单，未审批前不得签约付款 → 升级 CEO（1 个工作日内）
  • 评审时产品未达发布门槛 → 降级为预告/内测发布或延期 → 升级 CEO 拍板（2 个工作日内）
  • 发布日前 10 天发布内容仍未锁定 → 立项负责人冻结范围 → 升级 CEO（当天）
  • 预算超出审批额 10% 以上 → 补充审批 → 升级 CEO（发生前）

7. 衡量指标

  • 立项覆盖率 = 发布会类投入中先立项后花钱的比例，目标 100%
  • 发布内容锁定提前量 = 锁定日到发布日的自然日，目标 ≥ 10 天
  • 预算偏差率 = （实际 − 审批）/ 审批，目标 ≤ 10%
  • 目标达成率 = 复盘中已达成指标数 / 立项指标数，目标 ≥ 70%

8. 低效诊断

  • 现象：大额发布会预算在群里口头流转，提出人和决策人都不明，当场被叫停｜依据：「鼎慧产研决策部」2026-01
  • 现象：产品定义与对外材料临时要求次日交，研发被催着写材料，风格反复争议｜依据：「鼎慧产研决策部」2026-04
  • 现象：发布门槛无清单，“质量达标再发”和“发布要快”两种口径并存｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：节后发布会发布哪个产品要在群里反复确认｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 自办线下发布会：完整走立项、评审、预算审批。
  • 借外部大会发布：参展决策走 MKT-01，发布内容与对外材料仍按本流程第 2～6 步评审。
  • 线上发布（公众号/视频号/官网）：无专项预算时可简化为产品一页纸+门槛评审+材料定稿。
  • 不同产品线（LeapCore、LeapAll、PPT 产品、工程 Agent）各出一页纸，同场发布时由立项负责人统一口径。

10. 待确认问题

  • 市场负责人由谁担任？发布会立项是否归生态市场条线？
  • 发布会类预算是否统一由 CEO 审批？是否设置分级阈值？
  • 发布门槛清单由产品总监还是测试负责人维护？
  • 30 天立项、10 天定稿的提前量是否可行？
  • 现有市场例会能否承担发布评审？
MKT-03参展/大会报名与现场执行统筹待新建300

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：已决定参加或举办展会、大会、赛事、沙龙、Meetup 后，从确定参会人和名额、参会审批、票务差旅、展区分工与话术、排班与加班报备，到现场执行、会后复盘与报销的全过程。
  • 负责人：主责——生态市场总监（当前：许君·推断待确认）；协同——会务/生态活动运营（当前：陈梦琪·推断待确认）、产品总监（展区与话术，当前：杨萌·推断待确认）、销售（排班与路演，当前：刘昱潇、闫登辉、杜中瑞、时建、杨朋伟·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、行政（票务与差旅，当前：侯明月·推断待确认）、人事（加班审批与招聘物料，当前：待指定）、财务（报销，当前：待指定）；兜底——CEO
  • 核心流程：① 建活动任务并指定负责人 → ② 确定参会人与名额 → ③ 参会审批 → ④ 报名信息与票务差旅 → ⑤ 展区分工/话术/物料/演示准备 → ⑥ 排班与加班报备 → ⑦ 现场执行 → ⑧ 会后复盘与报销
  • 交付结果：活动执行台账（人员、排班、物料、演示、预算）、参会审批单、展区话术文档、现场线索表（转 MKT-07）、复盘纪要、按口径完成的报销。
  • 状态依据：已有“产品展区流程”文档可复用，但参会审批、名额分配、报销口径（“只是建议，不是规定”）均未成文；2026-05～07 人手靠群里点名、加班单独上报、名额临时变化，约 30 次相关讨论，判定待新建。

1. 场景判定

  • 触发条件：MKT-01 审批通过的外部活动；公司自办大会/生态大会；主办方发来邀请函或门票；销售/研究院被要求参展路演。
  • 典型说法：「需要协调一下人手 3 号顶一天」「展会外出遇到的常见问题提交给我」「请大家阅读并熟悉产品展区流程，在文档结尾处写上自己对应的话术」「如果谈客户回来了才报，没结果就自己玩」「那边现在只能搞两张票了」「之前都是通知太临时了」
  • 判断问题：参不参加已经定了吗？现在要解决的是“谁去、怎么去、现场怎么干、钱怎么报”吗？
  • 不归本流程管：参不参加的决策 → 请走 MKT-01；自办渠道大会的邀请名单与授牌 → 请走 MKT-04；演示环境与设备 → 请走 MKT-05；物料与礼品制作 → 请走 MKT-06；会后线索跟进 → 请走 MKT-07；内部游戏比赛、团建 → 请走 ADM-20（团建、聚餐与全员活动组织）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动总负责 建台账、定名额与参会人、审批、统筹复盘 A 生态市场总监（当前：许君·推断待确认）
会务 主办方对接、报名、证件、日程通知 R 会务/生态活动运营（当前：陈梦琪·推断待确认）
展区负责 展区流程、话术文档、演示分工 R 产品总监（当前：杨萌·推断待确认）
排班与路演 销售人员排班、路演、现场接待 R 销售（当前：刘昱潇、闫登辉、杜中瑞、时建、杨朋伟·推断待确认）
销售协调 名额分配、客户邀约 C 销售总监/客户经理（当前：吴琪·推断待确认）
票务差旅 订票、住宿、差旅登记 R 行政（当前：侯明月·推断待确认）
加班与招聘 加班审批、招聘二维码与海报 C 人事（当前：待指定）
报销 审核报销口径 C 财务（当前：待指定）
现场人员 按排班到岗、填写话术、登记线索 I 参会员工

3. 办之前请准备

  • 主办方邀请函/议程、展位位置与尺寸、到场与布展时间
  • 名额上限与证件要求（报名所需个人信息只填进受限表格，按主办方要求最小化提供）
  • 参会目的：产品发布、品牌曝光、生态合作、获客（决定报销口径）
  • 展示内容：哪些产品、谁演示、是否路演（演示需求同步发 MKT-05）
  • 物料需求（易拉宝、立牌、二维码、手册、礼品，同步发 MKT-06）
  • 预算：展位费、差旅、补贴、物料
  • 产品展区流程文档最新版

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建活动执行台账，指定活动总负责、会务、展区负责 活动总负责 活动前 20 个自然日 飞书多维表格 活动台账 🔧飞书固化
2 确定名额与参会人（按目的选人），名额变化即时更新台账 活动总负责、销售协调 活动前 15 个自然日 多维表格 参会名单 👤人工判断
3 参会人提交参会申请（目的、预期成果、预算），按口径审批 参会人 活动前 12 个自然日 飞书审批“参会/出差申请” 审批单 🔧飞书固化
4 收集报名信息（受限权限表格）并提交主办方，订票住宿 会务、票务差旅 主办方截止前 3 个工作日 受限多维表格、差旅系统 报名回执、行程单 🔧飞书固化
5 发布展区流程与话术文档，每人在文档内认领话术与提问；演示与物料需求分别发 MKT-05、MKT-06 展区负责 活动前 7 个自然日 飞书文档 话术文档、子任务 🔧+🤖
6 排班（按天/时段）与现场任务分工（展区、接待、礼品、互动）；需加班的提前走加班审批 活动总负责、展区负责 活动前 5 个自然日 多维表格、飞书加班审批 排班表、加班单 🔧飞书固化
7 行前通知：到场时间、带什么设备、着装、联系人、应急电话 会务 活动前 2 个工作日 飞书群公告 行前通知 🔧飞书固化
8 现场执行：按排班到岗，线索用统一表单登记（转 MKT-07），记录客户常见问题 现场人员 活动当天 线索表单 线索、问题清单 🔧+🤖
9 复盘：成果、线索数、常见问题、改进项，更新展区流程文档 活动总负责 活动后 5 个工作日内 飞书文档模板 复盘纪要 👤人工判断
10 按审批口径提交报销/补贴，附成果说明 参会人 活动后 10 个工作日内 飞书报销 报销单 🔧飞书固化

5. 交付物与模板

  • 交付物：活动执行台账、参会审批单、报名回执、话术文档、排班表、加班单、线索表、复盘纪要、报销单。
  • 建议模板/表单：
    • 活动执行台账：活动名、类型、时间地点、目的、负责人、名额、参会人、排班、物料状态、演示状态、预算、实际支出、线索数
    • 参会申请：活动、目的、预期成果、预算、是否邀请参会、是否需要补贴
    • 复盘模板：目标 vs 实际、线索数与质量、客户常见问题、同行观察、下次改进
    • 话术文档：沿用“产品展区流程”（主动搭话、第一句讲清是什么、30 秒内进入演示、结尾引导留资加微信）

6. 异常与升级

  • 名额临时减少 → 活动总负责按目的重排优先级并通知 → 升级 CEO（当天）
  • 现场人手不足 → 按排班表备岗名单补位，不在大群点名 → 升级活动总负责（2 小时内）
  • 报名信息需身份信息 → 只在受限表格收集，不在群里传 → 法务/行政知悉（当天）
  • 报销口径有争议 → 财务按审批单口径执行 → 升级生态市场总监（3 个工作日内）

7. 衡量指标

  • 准备提前量 = 建台账到活动的自然日，目标 ≥ 20 天
  • 排班完整率 = 活动前 5 天已排定的岗位/时段比例，目标 100%
  • 复盘提交率 = 活动后 5 个工作日内提交复盘的比例，目标 100%
  • 单场线索数与有效线索率（有效 = 匹配目标客户画像），按活动类型设基线

8. 低效诊断

  • 现象：参展人手临时协调，会后客户清单各自整理，客户常见问题事后再收集｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-07
  • 现象：大会现场任务在群里点名“谁会过来”，加班时长靠个人单独上报，无统一台账｜依据：「字字可研项目群」2026-05
  • 现象：门票名额临时只剩两张，报销标准“只是建议，不是规定”｜依据：「鼎慧产研决策部」2026-07
  • 现象：外部活动通知太晚，需要临时拉人，奖品预算由个人垫付｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 政府主办大会（如光谷智能体经济大会）：名额少、证件要求严，提前 20 天报名单。
  • 行业展会（水博会、服博会等）：多日排班，展位费视情况由公司承担，销售为主力。
  • 自办/生态大会：全员协助，展区按产品分区（LeapAll、LeapCore、LeapBase 等），需加班审批。
  • 受邀参会 vs 自费参展：受邀参会走简化审批；自费参展须写预期成果。
  • 赛事（3551 大赛等）：参赛材料与评阅书打印由会务统一安排。
  • Meetup/社区活动：可同时招聘，二维码与海报由人事确认。

10. 待确认问题

  • 活动总负责默认是生态市场总监，还是按活动类型由销售/研究院负责人担任？
  • 参会报销口径是否采用“有成果才报销”或“固定补贴+会后分享”？由谁制定成文？
  • 大会筹备加班统一走飞书加班审批是否可行？
  • 20/15/12/7/5 天的倒排节点是否适合各类活动？
  • 报名所需个人信息的收集、保存、删除规则由谁负责？
MKT-04自办渠道大会邀请与授牌确认待优化120

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：公司自办渠道合作伙伴大会、行业沙龙、FDE 开班等需要邀请外部企业的正式活动前，汇总邀请名单、确认签约/授牌/上台对象、发放邀请函，并在改期时同步。
  • 负责人：主责——销售运营（当前：韩诗琪·推断待确认）；协同——各销售（邀约与填报，当前：杜中瑞、吴琪等·推断待确认）、会务（当前：陈梦琪·推断待确认）、法务（授牌协议，当前：待指定）；审核——生态市场总监（当前：许君·推断待确认）；任务下达——销售负责人（当前：李鹏为·推断待确认）；兜底——销售负责人
  • 核心流程：① 定日期与邀约指标 → ② 发布名单表（必填校验） → ③ 销售填报 → ④ 截止收口 → ⑤ 名称与授牌/上台核对 → ⑥ 审核定版 → ⑦ 发邀请函与回执 → ⑧ 改期同步与会前终版
  • 交付结果：审核定版的邀请名单（企业全称、简称、联系人、是否签约/授牌/上台）、邀请函回执、授牌与上台清单（交会务和现场执行 MKT-03）。
  • 状态依据：已有飞书表格“渠道大会拟邀请名单”和大会 PPT，形成固定做法；但 2026-09 名单模板活动前几天才建，连续约 4 次催确认，企业名称与授牌/上台逻辑反复核对，日期两次改期，判定待优化。

1. 场景判定

  • 触发条件：确定自办渠道大会/沙龙日期；销售负责人下达邀约任务；会务需要授牌、上台签约名单。
  • 典型说法：「公司渠道会定在 X 月 X 日，每个人都有邀约任务」「哪些人上台签约的？哪些要授牌的？」「渠道公司名称和简写是否写正确了」「一定要检查清楚没有遗漏」
  • 判断问题：这是我们自己办、需要向外部企业发邀请并区分签约/授牌/上台的活动吗？
  • 不归本流程管：大会现场执行与排班 → 请走 MKT-03；产研演示支持 → 请走 MKT-05；物料与礼品 → 请走 MKT-06；授牌对应的渠道协议签署 → 请走 SAL-27（渠道伙伴开发、授权政策与协议签署）；会后线索 → 请走 MKT-07。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
名单负责人 建表、催填、收口、导出、改期同步 R 销售运营（当前：韩诗琪·推断待确认）
邀约人 邀约客户、填报名单、发邀请函、收回执 R 各销售（当前：杜中瑞、吴琪等·推断待确认）
审核人 复核名称、授牌/上台名单，定版 A 生态市场总监（当前：许君·推断待确认）
任务下达 定日期与邀约指标 R 销售负责人（当前：李鹏为·推断待确认）
会务 座位、证书/牌匾制作、上台流程 C 会务（当前：陈梦琪·推断待确认）
法务 授牌对应协议状态核对 C 法务（当前：待指定）

3. 办之前请准备

  • 大会日期（含备选）、地点、议程草案
  • 每位销售的邀约指标
  • 渠道签约状态清单（已签/待签/意向），用于判断授牌/上台资格
  • 授牌与上台签约的判定规则
  • 邀请函模板、牌匾/证书模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 公布日期、邀约指标与名单截止日 销售负责人 大会前 20 个自然日 飞书群公告+任务 邀约任务 🔧飞书固化
2 用模板建邀请名单多维表格：企业全称/简称/联系人/签约状态/是否授牌/是否上台设为必填，授牌须已签约 名单负责人 大会前 18 个自然日 飞书多维表格 名单表 🔧飞书固化
3 销售填报，机器人在截止前 T-3/T-1 提醒未填人 邀约人 大会前 10 个自然日截止 多维表格+机器人 填报数据 🔧+🤖
4 AI 校验企业全称（工商名称）与简称、查重、标记授牌资格冲突 名单负责人 截止后 1 个工作日内 AI 校验脚本 校验结果 🤖自动化
5 审核授牌/上台名单并定版，锁表 审核人 截止后 2 个工作日内 多维表格 定版名单 👤人工判断
6 发邀请函，回执状态回填名单 邀约人 大会前 7 个自然日 邀请函模板 回执 🔧飞书固化
7 定版名单交会务制作牌匾/证书、排座与上台流程 名单负责人 大会前 7 个自然日 飞书任务 授牌/上台清单 🔧飞书固化
8 改期时当天通知全部邀约人重确认，会前 2 天出终版 名单负责人 改期当天；大会前 2 个自然日 群公告、多维表格 终版名单 🔧飞书固化

5. 交付物与模板

  • 交付物：定版邀请名单、邀请函回执、授牌与上台清单、终版签到名单。
  • 建议模板/表单：
    • 邀请名单：企业全称、企业简称、所属销售、联系人、职务、签约状态、是否授牌、是否上台签约、邀请函发送日期、回执状态、备注
    • 校验规则：全称与工商一致；简称全表唯一；授牌必须已签约；上台签约须有合同待签状态

6. 异常与升级

  • 截止日仍有销售未填 → 名单负责人当天点名提醒 → 升级销售负责人（1 个工作日内）
  • 企业名称无法核实或授牌资格不明 → 标记待定，不进入定版 → 升级审核人（1 个工作日内）
  • 定版后新增/删除授牌对象 → 需审核人同意并通知会务 → 大会前 3 天后原则上不再变动
  • 大会改期 → 名单负责人当天全员通知并重新收回执 → 销售负责人知悉（当天）

7. 衡量指标

  • 按时填报率 = 截止日前完成填报的销售比例，目标 100%
  • 名称差错数 = 定版后发现的企业名称/授牌错误数，目标 0
  • 催办次数 = 截止前人工催办次数，目标 ≤ 1 次
  • 邀约到场率 = 实际到场企业 / 发出邀请企业，按活动设基线

8. 低效诊断

  • 现象：名单模板在活动前几天才建，截止前后连续多日催确认｜依据：「【模态】市场销售」2026-09
  • 现象：企业名称、简称、授牌/上台对象反复核对，审核方临时追问授牌名单｜依据：「【模态】市场销售」2026-09
  • 现象：大会日期两次调整，名单与邀请函需重新收口｜依据：「【模态】市场销售」2026-09

9. 分支变体

  • 渠道大会：授牌、上台签约字段必填，授牌须先完成渠道协议。
  • 行业沙龙：去掉授牌字段，增加“行业/画像匹配度”字段。
  • FDE 开班：名单改为学员名单，字段增加所属企业、是否已缴费/授权。

10. 待确认问题

  • 名单负责人是否固定为销售运营？审核人为生态市场总监还是销售负责人？
  • 授牌、上台签约的判定规则是否已有成文版本？
  • 授牌是否必须以签署渠道协议为前提？由法务还是渠道负责人核对？
  • 20/10/7/2 天的时间节点是否可行？
  • 企业全称校验是否接入企查查等工具？
MKT-05展会/大会/发布会演示环境与设备准备待新建240

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：展会、大会、发布会、渠道大会或客户现场需要产品演示时，准备演示场景与脚本、演示版本与环境、数据与账号、录屏兜底、设备运输与网络、产研现场支持，结束后回收硬件。
  • 负责人：主责——产品总监（演示统筹，当前：杨萌·推断待确认）；协同——演示设计（当前：王皓南·推断待确认）、环境与数据（当前：宋祺睿、杨云峰·推断待确认）、硬件与网络（当前：杨明学、游家豪·推断待确认）、测试（当前：张东郅·推断待确认）、客户端演示版（当前：岳阳、李铭熙·推断待确认）、现场演示人（当前：闫登辉、吴琪、王满、胡橙橙·推断待确认）；决策——研发负责人兼 CTO（当前：丁震宇·推断待确认）；兜底——研发负责人兼 CTO
  • 核心流程：① 演示需求单 → ② 场景与脚本 → ③ 演示版本冻结与环境/账号/额度 → ④ 设备与网络 → ⑤ 素材合规审查与录屏兜底 → ⑥ 冒烟测试、彩排与培训 → ⑦ 现场 oncall → ⑧ 硬件回收与复盘
  • 交付结果：演示准备清单全部勾选（脚本、冻结版本、独立演示环境、账号与额度、设备、网络备份、录屏视频、负责人）、彩排记录、硬件回收登记与演示复盘。
  • 状态依据：已有“产品展区流程”“通用演示流程”文档，但无演示前检查清单和环境预约；2026-05～09 多次现场翻车（模型额度耗尽、上游不稳、会场网络差）、大会前一晚还在修功能、设备前两天才定，约 40 次相关讨论，判定待新建。

1. 场景判定

  • 触发条件：活动台账（MKT-01/03）或发布会立项（MKT-02）中含演示；销售约客户现场/线上演示；市场通知需要产研派人支持。
  • 典型说法：「彩排一下发布会」「所有人都带电脑」「演示由谁来」「一台纯摆着看，一台现场演示」「明天产品展示不翻车就够了」「最好到时候起码能看到实体」「为啥不要现场演示智能体」
  • 判断问题：这次对外场合是否要现场操作我们的产品或摆放实体设备？
  • 不归本流程管：是否参加活动 → 请走 MKT-01；现场人员排班与话术 → 请走 MKT-03；易拉宝、礼品等物料 → 请走 MKT-06；POC 环境 → 请走 X-DLV-27（客户 POC/演示环境搭建与交付）；客户正式交付部署 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；演示后线索 → 请走 MKT-07。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示统筹 收需求、建清单、分工、组织彩排 A 产品总监（当前：杨萌·推断待确认）
演示设计 场景、提示词、脚本、演示数据包 R 演示设计（当前：王皓南·推断待确认）
环境与数据 独立演示环境、版本冻结、数据清理、账号与额度 R 后端/运维（当前：宋祺睿、杨云峰·推断待确认）
客户端演示版 手机/桌面演示版本修复与打包 R 客户端研发（当前：岳阳、李铭熙·推断待确认）
硬件与网络 演示机/备机、运输、网络与路由备份、回收 R IT 运维（当前：杨明学、游家豪·推断待确认）
测试 演示前冒烟测试 R 测试（当前：张东郅·推断待确认）
现场演示人 熟悉脚本、现场演示、录视频 R 销售/运营/业务专家（当前：闫登辉、吴琪、王满、胡橙橙·推断待确认）
决策 演示策略取舍、是否现场实操 C 研发负责人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 活动时间地点、演示形式（展台/舞台/客户会议室/线上）、观众画像
  • 演示产品与版本（LeapAll、LeapCore、LeapBase、LeapPPT、手机端/桌面端）
  • 本地版还是公网版；现场网络条件（带宽、是否可用移动网络）
  • 可用设备：演示机、备机（与开发联调测试机分开）
  • 演示账号、模型额度、第三方服务额度
  • 参考“产品展区流程”“通用演示流程”文档（文档中的账号凭据另行受限保存）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交演示需求单（场合、产品、形式、时间、演示人），建演示准备清单 活动负责人/销售 活动前 10 个工作日（客户演示 3 个工作日） 飞书多维表格 需求单、清单 🔧飞书固化
2 写场景与脚本，打包固定演示数据；体现核心卖点（如 Skill 沉淀） 演示设计 活动前 7 个工作日 飞书文档 脚本、数据包 👤+🤖
3 预约独立演示环境，冻结演示版本（冻结至活动结束），清理数据，生成演示账号，预充模型与第三方额度，准备备用模型 环境与数据 活动前 5 个工作日 演示环境预约表 环境信息页（受限权限） 🔧飞书固化
4 准备演示机+备机、网络与路由备份、插排；登记出库 硬件与网络 活动前 3 个工作日 资产出入库登记 设备清单 🔧飞书固化
5 审查视频和截图素材（竞品/第三方 Logo、版本号、敏感信息），录制全流程兜底视频 演示统筹、现场演示人 活动前 3 个工作日 素材合规检查表 合规素材、兜底视频 👤人工判断
6 运行演示冒烟脚本（登录、核心流程、额度、上游连通） 测试 活动前 2 个工作日及当天开场前 自动化冒烟脚本 冒烟报告 🤖自动化
7 彩排并培训现场演示人（30 秒内进入演示、翻车话术、切换录屏） 演示统筹 活动前 2 个工作日 飞书会议/现场 彩排记录 👤人工判断
8 现场 oncall：指定 1 名产研值守，故障时切备用模型/备机/录屏 环境与数据 活动全程 飞书群 故障记录 👤人工判断
9 清点回收硬件、解冻环境、收集现场反馈 硬件与网络、演示统筹 活动后 2 个工作日内 资产登记、复盘文档 回收单、演示复盘 🔧飞书固化

5. 交付物与模板

  • 交付物：演示准备清单、脚本与数据包、环境信息页（受限）、设备出入库单、兜底视频、冒烟报告、彩排记录、演示复盘。
  • 建议模板/表单：
    • 演示准备清单：活动、日期、产品与版本、本地/公网、演示人、脚本链接、环境负责人、冻结起止、账号状态、模型额度、备用模型、演示机/备机编号、网络方案、兜底视频、冒烟结果、oncall 人
    • 素材合规检查表：第三方/竞品 Logo、他人开源项目名、未发布功能、版本号、客户信息、账号密码
    • 演示环境预约表：环境、时间段、使用人、用途、是否冻结

6. 异常与升级

  • 活动前 3 天仍未收到需求 → 演示统筹只保障录屏+静态展示 → 升级 CTO（当天）
  • 冒烟测试失败 → 环境负责人修复或切备用模型，2 小时内复测 → 仍失败升级 CTO（当天）
  • 现场翻车 → 立即切录屏或备机，口头引导 → 会后 1 个工作日内提交故障记录
  • 演示机与测试机冲突 → 演示机优先、测试改用其他环境 → 升级研发负责人（当天）

7. 衡量指标

  • 现场翻车次数 = 演示中断或需切换兜底的次数，目标每季度 ≤ 1
  • 清单完成率 = 活动前 2 个工作日清单项勾选比例，目标 100%
  • 需求提前量 = 需求单到活动的工作日数，目标 ≥ 10
  • 硬件回收及时率 = 活动后 2 个工作日内回收登记的比例，目标 100%

8. 低效诊断

  • 现象：大会前一晚仍在修流式输出和手机版，产品视频临近活动才发现含第三方产品画面只能替换｜依据：「Leap产研测」2026-05
  • 现象：演示设备活动前两天才确认，开发联调测试机能否拆去演示存在分歧｜依据：「Leap产研测」2026-06
  • 现象：同一天多场演示，地址与账号反复索要，演示机与测试机混用，演示内容未体现核心卖点｜依据：「LeapCore（archived）」2026-06
  • 现象：现场演示因模型额度耗尽、上游不稳多次翻车，每次重新选模型、测环境｜依据：「模态AI探索小分队」2026-05、「模态AI探索小分队」2026-06
  • 现象：渠道大会前一天才通知需要产研支持，演示配置前一晚才定，市场对产品不熟｜依据：「Leap产研决策部」2026-09
  • 现象：活动前一天才找 Logo 贴纸，大会带回硬件清点无截止时间｜依据：「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-05

9. 分支变体

  • 本地版演示：带演示机+备机，局域网环境信息单独成文。
  • 公网版演示：使用独立公网演示站，账号按场次发放，地址与账号只放受限文档。
  • 视频演示：舞台或网络不可靠时优先播放视频，现场只做简短实操。
  • 手机端 vs 桌面端：手机端需提前安装包并确认默认配置（如审批模式）。
  • 现场实机 vs 远程（飞连）：网络允许时可远程操作公司内样机。
  • 实体设备展示/销售（OPC 活动、开源会）：需贴公司 Logo、摆放并现场可用，活动后清点回收。

10. 待确认问题

  • 演示统筹默认由产品总监负责，还是按活动由销售/市场负责？
  • 是否设立固定的独立演示环境与演示机，禁止与联调测试机混用？
  • 演示前冒烟脚本由测试还是研发维护？
  • 10/5/3/2 个工作日的节点对客户临时演示是否过严？
  • 演示账号凭据的保存位置与权限由谁管理？
MKT-06活动物料与礼品制作及回收待新建108

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：活动或摆摊前需要备齐易拉宝、海报、传单、贴纸、二维码、积分卡、抽奖礼品、3D 打印礼品等，从需求、出稿、校对、采购打印或分工制作，到带去现场、活动后归还入库与费用报销。
  • 负责人：主责——行政（物料制作与采购，当前：侯明月·推断待确认）；协同——活动负责人（提需求，当前：杨萌、陈梦琪·推断待确认）、设计出稿（当前：王皓南·推断待确认）、审稿与预算（当前：丁震宇·推断待确认）、人事（招聘二维码，当前：黄莹·推断待确认）、制作联系（当前：潘浩伟·推断待确认）、3D 打印小组（当前：葛家和、吴世豪、宋祺睿、杨明学·推断待确认）、抽奖环节（当前：葛家和·推断待确认）、财务（当前：待指定）；兜底——行政负责人
  • 核心流程：① 提物料需求单 → ② 按模板出稿 → ③ 校对审稿 → ④ 比价下单或分工制作 → ⑤ 验收清点入库 → ⑥ 出库带往现场 → ⑦ 活动后归还入库 → ⑧ 费用报销
  • 交付结果：按时到场且无错误的活动物料与礼品、物料出入库登记、电子版终稿归档在物料库、费用报销单。
  • 状态依据：有“设计→行政定尺寸→打印”的协作链，但无模板库与校对清单；2026-03 易拉宝出现错别字（“全栈”写成“全招”），属于对外物料事故；2026-05～06 礼品需求活动前两天才提、制作人不明、物料借出未还，约 60 条相关讨论，判定待新建。

1. 场景判定

  • 触发条件：MKT-03 活动任务中有物料/礼品需求；摆摊、Meetup、大会需要招聘或产品物料；抽奖、积分兑换需加印。
  • 典型说法：「易拉宝和海报都需要审一下」「上次用的招聘物料的电子版是哪一版来着」「积分卡之前是谁联系做的」「还能生成 300 个兑换码吗」「所有人开始打印」「公司还有贴纸吗」「电源找到了」
  • 判断问题：这次活动是否需要制作、采购或借用实物物料与礼品？
  • 不归本流程管：物料文案与设计内容口径、品牌规范校对 → 请走 BRD-13；演示设备与网络 → 请走 MKT-05；参展报名与排班 → 请走 MKT-03；大额采购（超行政采购额度） → 请走 FIN-01（对公采购申请与付款审批）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
物料负责人 收需求、定尺寸、比价下单、验收、出入库 R 行政（当前：侯明月·推断待确认）
需求方 提物料与礼品需求、数量、截止日 R 活动负责人（当前：杨萌、陈梦琪·推断待确认）
设计出稿 按模板 AI 出稿，输出正确尺寸与分辨率 R 设计出稿（当前：王皓南·推断待确认）
审稿与预算 终稿确认、预算批准 A 研发负责人（当前：丁震宇·推断待确认）
招聘二维码 提供有效招聘二维码与岗位口径 C 人事（当前：黄莹·推断待确认）
制作联系 积分卡、兑换码等印刷与生成 R 制作联系（当前：潘浩伟·推断待确认）
3D 打印小组 认领打印、汇总成品 R 3D 打印小组（当前：葛家和、吴世豪、宋祺睿、杨明学·推断待确认）
财务 物料费用科目与报销 C 财务（当前：待指定）

3. 办之前请准备

  • 活动名称、日期、地点、送达方式与时间（送会场或主办方代收）
  • 物料清单：品类、尺寸（如易拉宝 80×200cm、传单 A4）、数量、用途
  • 需放置的二维码（企业微信/招聘/社群）及其有效期
  • 礼品方案：抽奖轮次、人人有份礼品、互动区奖品、兑换码数量
  • 预算上限与是否可复用库存（贴纸、易拉宝、展品）
  • 上一版电子文件链接（从物料库取）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交物料需求单，先查库存可复用项 需求方 活动前 7 个工作日（3D 打印礼品 10 个工作日） 飞书多维表格“物料需求与库存” 需求单 🔧飞书固化
2 从模板库按尺寸/分辨率出稿，加二维码 设计出稿 需求后 2 个工作日内 AI 设计工具、模板库 设计稿 🤖自动化
3 按校对清单检查错别字、尺寸、二维码可扫、品牌口径；终稿确认 物料负责人、审稿与预算 出稿后 1 个工作日内 校对清单 终稿 👤+🤖
4 印刷类至少 2 家比价后下单；积分卡兑换码用脚本生成 物料负责人、制作联系 终稿后 1 个工作日内 供应商比价表、兑换码脚本 订单 🔧+🤖
5 3D 打印礼品：指定唯一责任人，在表中按颜色/部件认领，每日更新完成数 3D 打印小组 活动前 2 个工作日完成 多维表格 成品与进度 🔧飞书固化
6 验收清点（数量、错字、色差），终稿电子版归档物料库 物料负责人 到货当天 物料库 验收记录 🔧飞书固化
7 出库登记，确认送达时间与现场交接人 物料负责人 活动前 1 个工作日 出入库登记 出库单 🔧飞书固化
8 活动后按出库单清点归还（含电源、设备、剩余礼品），入库 活动负责人 活动后 2 个工作日内 出入库登记 入库单 🔧飞书固化
9 物料与打印材料费用按科目报销，附需求单链接 实际垫付人 活动后 10 个工作日内 飞书报销 报销单 🔧飞书固化

5. 交付物与模板

  • 交付物：物料需求单、终稿电子版、校对记录、订单与验收记录、出入库单、报销单。
  • 建议模板/表单：
    • 物料需求与库存表：活动、物品、规格尺寸、数量、截止日、责任人、状态（待出稿/待审/下单/到货/出库/归还）、库存数、存放位置、电子版链接
    • 物料模板库：易拉宝、海报、传单、贴纸、立牌、积分卡（标注尺寸、分辨率、出血）
    • 校对清单：错别字、公司/产品名称、岗位名称、二维码可扫与有效期、联系方式、尺寸比例
    • 供应商比价表：供应商、品类、单价、交期、质量评价

6. 异常与升级

  • 需求提交时距活动不足 3 个工作日 → 物料负责人只做库存复用或加急件 → 升级活动负责人确认取舍（当天）
  • 终稿发现错误 → 已印刷的停用并重印，记录事故 → 升级审稿与预算负责人（当天）
  • 3D 打印成品率低、数量不足 → 责任人当天评估外包打印或减量 → 升级活动负责人（当天）
  • 活动后物料未归还 → 物料负责人按出库单追回 → 升级活动负责人（活动后 3 个工作日）

7. 衡量指标

  • 物料事故数 = 对外物料出现错别字/错误信息的次数，目标 0
  • 准时到场率 = 活动前 1 个工作日完成出库的需求比例，目标 100%
  • 一次校对通过率 = 无需重做即定稿的物料比例，目标 ≥ 80%
  • 归还率 = 活动后 2 个工作日内归还入库的出库物品比例，目标 100%

8. 低效诊断

  • 现象：易拉宝比例、分辨率不对多次重做，终稿出现错别字，找不到上一版电子文件｜依据：「模态文创」2026-03、「模态文创」2026-06
  • 现象：礼品文档位置不明、积分卡之前由谁联系不清楚、兑换码加印数量临时变化｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：3D 打印礼品活动前两天才提需求，未指定责任人，材料费用事后统计｜依据：「3D打印小组」2026-05、「3D打印小组」2026-06
  • 现象：积分卡印刷靠群里临时询价拍板｜依据：「鼎慧产研决策部」2026-05
  • 现象：展会物料借出后未归还，带回物品放门口无人收拾｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 招聘物料（易拉宝/传单）：二维码与岗位名称由人事确认。
  • 抽奖/积分卡：兑换码由脚本生成，加印数量以活动负责人书面确认为准。
  • 3D 打印礼品（吉他、手机支架等）：提前 10 个工作日，指定唯一责任人；数量超过小组产能时评估外包。
  • 贴纸、Logo、展品：作为常备库存，低于安全库存时补货。

10. 待确认问题

  • 物料负责人是否为行政（当前执行人）还是行政负责人另行指定？
  • 物料审稿与预算由研发负责人还是品牌/生态市场负责人负责？
  • 物料单场预算上限是多少？3D 打印材料费用走哪个科目？
  • 是否建立常备物料库存及安全库存线？存放位置在哪？
  • 7/10 个工作日的需求提前量是否可行？
MKT-07活动后线索跟进与转化复盘待新建135

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：参加展会、沙龙、座谈会、数转活动、线下 Meetup 或抽奖/扫码引流活动后，统一录入线索、分配跟进、统计转化并复盘活动价值。
  • 负责人：主责——生态活动运营（活动复盘负责人，当前：陈梦琪·推断待确认）；协同——CRM 管理员（线索录入与分配，当前：闫登辉·推断待确认）、参会销售（跟进，当前：陈名赞、时建、杜中瑞·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营（公司号与社群，当前：待指定）；兜底——销售负责人
  • 核心流程：① 活动前定目标客户画像 → ② 统一引流码与线索表单 → ③ 现场采集 → ④ 24 小时内入 CRM 并分配 → ⑤ 3 个工作日内首次跟进 → ⑥ 拜访/拉群 → ⑦ 活动复盘 → ⑧ 月度转化统计
  • 交付结果：CRM 中带活动来源标记的线索（含分配人、跟进状态）、单场活动复盘（线索数、匹配度、转化）、月度活动渠道 ROI 统计。
  • 状态依据：目前只在销售周报里写活动效果，无统一线索表与复盘；2026-08～10 周报反复出现“活动无目标客户”“来访非决策人”“匹配度不高”约 15 次；2026-03 引流全部进入个人微信、公司号无人运营，判定待新建。

1. 场景判定

  • 触发条件：活动结束；现场收集到名片、微信、扫码留资、抽奖登记；销售周报需填写活动效果。
  • 典型说法：「本周获客效果很差，参加的活动没有目标客户」「来访人员不是公司主要决策人」「原来引流效果这么大，下回展会可以多整整」「公司号也没人专门运营」
  • 判断问题：活动现场是否接触到可能的客户、渠道或合作方，需要后续跟进或评估活动价值？
  • 不归本流程管：活动是否参加 → 请走 MKT-01；现场执行 → 请走 MKT-03；布道场次本身的接单与讲师 → 请走 MKT-08；线索进入商机后的甄别、报价、POC、签约 → 请走 SAL-03（商机甄别、可行性初筛与赢丢单复盘），重点/大客户商机 → 请走 SAL-06（重点商机上报与大客户分级推进）；线索与客户归属争议 → 请走 SAL-33（商机与客户归属分配制度）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
复盘负责人 活动前画像、汇总线索、组织复盘、月度统计 A 生态活动运营（当前：陈梦琪·推断待确认）
CRM 管理员 线索去重入 CRM、按规则分配 R CRM 管理员（当前：闫登辉·推断待确认）
参会销售 现场扫码/表单登记线索 R 销售（当前：陈名赞、时建、杜中瑞·推断待确认）
跟进销售 首次跟进、拜访或拉群、回填 CRM R 按 SAL-33 指定的归属销售
销售总监 跟进质量检查与超时督办 C 销售总监/客户经理（当前：吴琪·推断待确认）
运营 公司号/社群承接非销售线索 R 运营（当前：待指定）
销售负责人 月度复盘知悉、活动渠道取舍 I 销售负责人

3. 办之前请准备

  • 本场活动目标客户画像（行业、规模、职务层级）与目标线索数
  • 统一引流二维码（企业微信/公司社群），不用个人微信二维码
  • 现场线索登记表单（手机可填）
  • 抽奖/福袋规则（以留资为条件）
  • 活动台账链接（来源 MKT-03）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在活动台账写目标画像与目标线索数，判断活动匹配度 复盘负责人 活动前 5 个工作日 多维表格 画像与目标 👤人工判断
2 生成本场专属引流码与线索表单（自动带活动来源） 运营 活动前 3 个工作日 企业微信、飞书表单 引流码、表单 🔧飞书固化
3 现场扫码/表单登记线索，标注意向等级与是否决策人 参会销售 活动当天 线索表单 原始线索 🔧飞书固化
4 AI 汇总名片与登记信息，去重后入 CRM，按区域/行业分配 CRM 管理员 活动后 24 小时内 CRM、AI 名片识别 已分配线索 🔧+🤖
5 首次跟进（电话/微信），回填跟进结果 跟进销售 分配后 3 个工作日内 CRM 跟进记录 🔧飞书固化
6 有意向的约拜访或拉群；非销售线索转运营社群 跟进销售、运营 首次跟进后 5 个工作日内 CRM、社群 拜访计划/入群 👤人工判断
7 单场复盘：线索数、匹配度、决策人占比、成本，给出“下次去不去”建议 复盘负责人 活动后 5 个工作日内 复盘模板 复盘纪要 👤+🤖
8 月度统计各活动类型线索到商机/签约转化，反馈 MKT-01 分级 复盘负责人 每月第 5 个工作日 CRM 报表 月度 ROI 表 🤖自动化

5. 交付物与模板

  • 交付物：CRM 线索（带活动来源）、单场复盘纪要、月度活动转化统计。
  • 建议模板/表单：
    • 现场线索表单：姓名、单位、职务、是否决策人、行业、需求描述、意向等级、登记人、活动来源（自动）、留资方式
    • 单场复盘：目标 vs 实际线索数、有效线索率、决策人占比、费用、首次跟进完成率、典型客户问题、下次是否参加
    • 月度统计：活动类型、场次、线索数、商机数、签约数、单线索成本

6. 异常与升级

  • 线索 24 小时未入 CRM → 复盘负责人提醒 → 升级 CRM 管理员与销售总监（次日）
  • 分配后 3 个工作日未首次跟进 → CRM 自动提醒 → 升级销售总监（第 4 个工作日）
  • 线索归属争议 → 本流程不自定规则，转 SAL-33（商机与客户归属分配制度）处理，期间由 CRM 管理员暂挂线索、不重复跟进（当天转出）
  • 连续两场同类活动有效线索率低于基线 → 在 MKT-01 中降级该类活动 → 销售负责人知悉（当月）

7. 衡量指标

  • 线索入库及时率 = 24 小时内入 CRM 的线索比例，目标 ≥ 95%
  • 首次跟进及时率 = 分配后 3 个工作日内完成首次跟进的比例，目标 ≥ 90%
  • 有效线索率 = 匹配目标画像的线索 / 总线索，按活动类型设基线
  • 活动转化率 = 活动来源线索中 90 天内转为商机的比例，按季度统计

8. 低效诊断

  • 现象：活动效果只写在个人周报，口径不一，无法比较哪类活动有效｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-10
  • 现象：参加前未判断客户匹配度，到场发现无目标客户、来访人员非决策人｜依据：「【模态】市场销售」2026-08
  • 现象：现场引流全部进入个人微信，公司号无人运营，线索无法沉淀｜依据：「鼎慧产研决策部」2026-03
  • 现象：活动前临时拉人、临时做 PPT，现场引流动作靠个人发挥｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 政府/数转活动：重点标注单位层级与决策链，跟进周期可放宽到 5 个工作日。
  • 渠道沙龙：线索分为“渠道伙伴”与“终端客户”，渠道伙伴转渠道负责人。
  • 展会：多日活动按天汇总，每日收档后入 CRM。
  • 抽奖/扫码引流：以留资为参与条件，抽奖名单与线索表单为同一张表。
  • 现场演讲 vs 摆展：演讲后统一扫码进社群，由运营承接再筛选。

10. 待确认问题

  • 活动复盘负责人是生态活动运营还是活动总负责（MKT-03）？
  • CRM 线索分配规则（区域/行业/登记人）是否已有？
  • 是否统一使用企业微信或公司社群承接引流？运营由谁负责公司号？
  • 24 小时入库、3 个工作日首次跟进是否可行？
  • 活动转化统计周期取 90 天是否合适？
MKT-08外部布道/分享活动接单与讲师分工待新建180

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：高校社群、政府部门、团委、国企、中小企业服务机构、OPC 社群等主办方邀请公司做技术/产品分享（如 OpenClaw 布道）时，从接单登记、评估场次、指派讲师、向主办方报题目与讲师简介，到现场分享、引流和复盘。
  • 负责人：主责——布道活动对接人（当前：李鹏为·推断待确认）；协同——布道统筹（定策略、选讲师、内容 review，当前：丁震宇·推断待确认）、讲师（当前：李子遥、望政韬、马漳毓·推断待确认）、活动线索提供人（当前：邴龙志、闫登辉、杨朋伟·推断待确认）、品牌（讲师简介库，当前：待指定）、法务（当前：待指定）；兜底——生态市场条线负责人
  • 核心流程：① 主办方填需求单 → ② 登记布道场次台账并定目的 → ③ 评估是否接 → ④ 指派主讲/辅助 → ⑤ 从简介库选定讲师简介并经本人确认 → ⑥ 报题目与简介给主办方 → ⑦ 准备与内容 review → ⑧ 现场分享与引流 → ⑨ 复盘
  • 交付结果：布道场次台账中每场都有主办方需求、目的、主讲/辅助、经本人确认的简介、PPT 版本、效果与线索；对外讲师头衔口径统一、真实。
  • 状态依据：2026-03～04 约 10 场布道，每次临时问“谁去”“什么时间什么地点”，主办方需求前一晚 23 点才下发；讲师头衔同一人改 6 版以上、不同场次说法不一，有被外部质疑夸大的风险；无需求单、排期表和简介库，判定待新建。

1. 场景判定

  • 触发条件：主办方发来分享邀请；商务/研究院侧拿到活动机会；需要向主办方报讲师介绍、海报嘉宾简介。
  • 典型说法：「明天下午是谁去」「你布置任务布置清楚一点，什么时间什么地点」「还有谁能上」「请准备一个 30 分钟的技术性分享」「别给我偷偷加核心俩字」「按目的来做布道，每一场的目的不一样」
  • 判断问题：是否由外部主办方邀请我方派人做演讲/分享/workshop？
  • 不归本流程管：我方主动参展/摆摊决策 → 请走 MKT-01；参展现场执行 → 请走 MKT-03；演示环境 → 请走 MKT-05；分享后线索跟进 → 请走 MKT-07；对外宣传稿 → 请走 BRD-09（事件型宣发稿与新闻稿）；品牌用语与对外口径规范 → 请走 BRD-14（对外口径、品牌用语与发布前合规自查）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
布道对接人 收需求单、登记台账、对接主办方、报题目与简介 R 布道活动对接人（当前：李鹏为·推断待确认）
布道统筹 判断接不接、定目的与策略、指派讲师、内容 review A 布道统筹（当前：丁震宇·推断待确认）
讲师 主讲/辅助、准备 PPT、确认本人简介 R 讲师（当前：李子遥、望政韬、马漳毓·推断待确认）
线索提供人 转交主办方邀请，确保信息完整 C CEO 及销售（当前：邴龙志、闫登辉、杨朋伟·推断待确认）
品牌 维护讲师简介库与“不得夸大”规则 C 品牌（当前：待指定）
法务 头衔与对外表述合规意见 C 法务（当前：待指定）

3. 办之前请准备

  • 主办方名称与类型、活动时间、地点（线上/线下）、时长与形式（分享/workshop/圆桌）
  • 听众画像（学生、公务员、创业者、企业 IT）与人数
  • 主办方对内容的要求（技术深度、是否需演示）与材料提交截止日
  • 本场目的（单选）：品牌宣传、推产品（如 NAS 一体机）、招商引资/政企项目引子、招聘
  • 主办方需要的讲师信息格式（头衔、简介字数、照片、是否实名）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到邀请后发主办方需求单（统一模板），回收后登记布道场次台账 布道对接人 收到邀请后 1 个工作日内 飞书表单+多维表格 需求单、台账记录 🔧飞书固化
2 评估是否接、确定本场目的，信息不全的退回补齐 布道统筹 登记后 1 个工作日内 多维表格 接/不接、目的 👤人工判断
3 指派主讲与辅助，确认档期；台账自动建日程与活动群 布道统筹 活动前 7 个自然日 多维表格+日历机器人 讲师安排、日程 🔧+🤖
4 从讲师简介库选版本（技术版/通俗版），讲师本人确认，未经本人确认不得提交 布道对接人、讲师 主办方截止前 2 个工作日 讲师简介库 定版简介 👤人工判断
5 向主办方报题目与讲师简介，回执记入台账 布道对接人 主办方截止日前 邮件/微信 提交记录 🔧飞书固化
6 按目的与听众准备 PPT，AI 辅助按画像改版，统筹 review 讲师、布道统筹 活动前 2 个自然日 AI 工具、飞书文档 PPT 定版 🤖+👤
7 现场分享，统一引流码收集听众（转 MKT-07） 讲师 活动当天 引流码、线索表单 线索 🔧飞书固化
8 复盘：听众反馈、线索数、目的达成情况，回填台账 讲师、布道对接人 活动后 2 个工作日内 多维表格 复盘记录 🤖自动化

5. 交付物与模板

  • 交付物：布道场次台账、主办方需求单、讲师简介库、PPT 版本库、复盘记录。
  • 建议模板/表单：
    • 主办方需求单：主办方、联系人、日期时间、地点、时长、形式、听众画像与人数、内容要求、是否演示、材料截止日、讲师信息格式
    • 布道场次台账：场次、主办方类型、目的、主讲、辅助、对接人、题目、PPT 版本、简介版本、状态、线索数、效果评价
    • 讲师简介库：讲师、技术版简介、通俗版简介、可用头衔清单、禁用说法、是否实名、本人确认日期

6. 异常与升级

  • 主办方需求在活动前 2 天内才到或临时变更 → 布道对接人与主办方协商沿用现有内容 → 升级布道统筹（当天）
  • 无讲师档期 → 布道统筹决定婉拒或改线上 → 当天回复主办方
  • 主办方要求使用未经确认或夸大的头衔 → 一律以简介库定版为准 → 升级品牌/法务（1 个工作日内）
  • 同一时段多场冲突 → 按目的优先级取舍 → 升级生态市场条线负责人（当天）

7. 衡量指标

  • 需求完整率 = 活动前 7 天需求单字段齐全的场次比例，目标 ≥ 90%
  • 讲师确定提前量 = 指派讲师到活动的自然日，目标 ≥ 7 天
  • 简介一次定版率 = 无需返工即提交的讲师简介比例，目标 100%
  • 单场线索数与目的达成率 = 复盘中“目的已达成”的场次比例，目标 ≥ 70%

8. 低效诊断

  • 现象：主办方技术分享要求在活动前一晚 23 点才下发，PPT 已定稿来不及改｜依据：「Claw布道/案例组」2026-03
  • 现象：“明天下午是谁去”“还有谁能上”反复追问，活动信息集中在个别对接人手里，需要催促才能拿到｜依据：「Claw布道/案例组」2026-03
  • 现象：活动细节分散在外部聊天工具，飞书无日程提醒｜依据：「Claw布道/案例组」2026-03
  • 现象：讲师头衔在群里改 6 版以上，不同场次头衔说法不一，讲师本人多次要求不得夸大｜依据：「Claw布道/案例组」2026-03
  • 现象：每场布道目的不同但未事先明确，内容与听众不匹配｜依据：「Claw布道/案例组」2026-03、「Claw布道/案例组」2026-04

9. 分支变体

  • 政府部门/国企主办：侧重安全顾虑与定制项目引子，简介用通俗版。
  • OPC/创业社群：侧重创业提效与 NAS 一体机等产品。
  • 高校学生社群：侧重应用案例与招聘引流。
  • 团委 workshop（约 90 分钟）：需准备动手环节与演示环境（走 MKT-05）。
  • 技术圈/开源社区：头衔只写真实贡献；面向大众场合可加通俗解释（如“国产操作系统内核维护者”）。
  • 讲师可按本人意愿使用网名，不强制实名。

10. 待确认问题

  • 布道对接人固定为销售负责人，还是设专人负责活动对接？
  • 布道统筹（选讲师、review）是否长期由 CTO 承担，是否需要备岗？
  • 讲师简介库由品牌还是生态市场维护？头衔“不得夸大”规则是否需法务出具？
  • 7 天确定讲师的节点是否可行？主办方临时邀约如何处理？
  • 布道场次是否与 MKT-01 外部活动台账合并为一张表？
MKT-09演讲/布道 PPT 与演示素材制作、评审及外发待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：布道/分享场次与讲师已确定，或 CEO/高管受邀在外部峰会、大会演讲，需要按听众做一版 PPT（含讲稿、演示 Demo），评审定版交主办方；主办方要求提前拿材料时按水印 PDF 外发
  • 负责人：主责——布道/演讲材料负责人（当前：李子遥·推断待确认）；协同——峰会演讲材料执行（当前：许君·推断待确认）、讲师（当前：望政韬、马漳毓·推断待确认）、技术口径评审（当前：丁震宇、王皓南·推断待确认）、演示素材录制（当前：邓乾、张康、宋祺睿·推断待确认）、视频剪辑（当前：宫经喜·推断待确认）、主办方对接（当前：李鹏为·推断待确认）、现场设备调试（当前：侯明月·推断待确认）；兜底——生态市场条线负责人
  • 核心流程：① 登记场次与听众 → ② 从母版库出初稿 → ③ 选取/补录 Demo 素材 → ④ 内容与技术口径评审 → ⑤ 定版并配讲稿/提词器 → ⑥ 现场试放彩排 → ⑦ 按需水印 PDF 外发 → ⑧ 回收归档到母版与 Demo 库
  • 交付结果：定版 PPT（含备注讲稿）、演示视频/Demo、提词器版本、外发用水印 PDF、更新后的母版库与 Demo 库条目
  • 状态依据：已有“AI 出稿→评审→定版”的固定做法，外发只发水印 PDF 的规则已口头确立；但 2026-01～07 群内出现前一夜/当天赶工约 4 次、找“最新版”约 2 次、主办方要求变化后重做约 3 次、“AI 做 PPT 用什么工具”被不同人重复提问约 4 次；无统一母版、素材库、版本清单和水印标准

1. 场景判定

  • 触发条件：布道/分享场次与讲师已确定（由 MKT-08 接单派出）；CEO/高管确认出席外部峰会、大会并需上台；周年庆等内部大会需要演讲材料；主办方或客户要求提前提供演讲 PPT
  • 典型说法：「今天就得做完 PPT 了」「尽快定版一下」「一页 PPT 配一页讲稿」「周六的 PPT 方便外发吗」「大家做 PPT 都用什么 AI 工具链」
  • 判断问题：这份材料是否由我方人员在外部或公开场合讲？场次、听众、时长是否已确定？
  • 不归本流程管：是否接这场分享、派谁讲 → 请走 MKT-08；课程体系与讲师排班 → 请走 ECO-13；活动现场演示环境与设备运输 → 请走 MKT-05；给客户做销售演示 → 请走 SAL-11；宣传视频成片 → 请走 BRD-11；销售标准物料与案例库 → 请走 SAL-15；对外口径总则与敏感词 → 请走 BRD-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
材料负责人 登记场次、定截止时间、组织评审、定版归档、维护母版库 R/A 布道/演讲材料负责人（当前：李子遥·推断待确认）
峰会演讲材料执行 高管峰会场次的 PPT、讲稿、提词器、briefing R 生态市场总监（当前：许君·推断待确认）
讲师 基于母版改稿、讲稿、彩排 R 布道讲师（当前：望政韬、马漳毓·推断待确认）
技术口径评审 审术语、产品表述、友商表述 C 创始人兼 CTO、Leap 研发负责人（当前：丁震宇、王皓南·推断待确认）
演讲人（高管场次） 终审内容与生态合作页 A（升级） CEO（当前：邴龙志·推断待确认）
素材录制 录屏、演示视频、截图 R 研发（当前：邓乾、张康、宋祺睿·推断待确认）
视频剪辑 剪辑演示视频 R 内容/视频运营（当前：宫经喜·推断待确认）
主办方对接 收主办方要求、外发定版材料 R 市场销售负责人（当前：李鹏为·推断待确认）
现场设备 现场试放、调整错位、提词器调试 R 行政/接待（当前：侯明月·推断待确认）

3. 办之前请准备

  • 场次信息：主办方、日期、时长、听众画像（政务/高校/OPC/企业）、屏幕比例、是否有提词器、主办方交稿截止时间
  • 母版库中对应版本（科普 30 分钟版、政务安全版、OPC 版、workshop 版）及上一场定版
  • Demo 库中适用的演示视频与案例
  • 品牌素材：Logo、联系方式、合作入口/拉群二维码
  • 统一口径：产品名、对外数据、友商表述红线
  • 外发需求：是否需提前发主办方、外发对象、水印强度

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记场次，确定讲师、听众、时长、定版截止时间（终稿锁定在活动前 48 小时） 材料负责人 场次确定当天 多维表格“演讲场次台账” 场次记录 🔧飞书固化
2 从母版库选版，用指定 AI 工具链按听众画像生成初稿，不另起炉灶 讲师 活动前 5 个工作日内出初稿 母版库 + 指定 AI 工具链 初稿 v0.1 🤖自动化
3 从 Demo 库选素材；库里没有的向素材录制人提需求 讲师 → 素材录制 需求提出后 2 个工作日内交付 Demo 库 演示视频、截图 🔧+👤
4 按评审清单检查：听众匹配、术语密度、单页字数、案例、友商表述、联系方式/二维码；技术表述由技术口径评审人确认 技术口径评审、演讲人 收到初稿后 1 个工作日内反馈 飞书文档评论 评审意见 👤人工判断
5 修改并定版：文件名带日期+版本号，上传场次台账，群内发“定版”，旧版标作废 讲师 活动前 48 小时 飞书云盘 定版 PPT（含备注讲稿） 🔧飞书固化
6 一页 PPT 配一页讲稿，导出提词器版；高管场次把 briefing（议程、采访问题、午宴安排）发到演讲人飞书，不经私信转述 材料负责人 / 峰会演讲材料执行 活动前 1 个工作日 飞书文档 讲稿、提词器版、briefing 🤖+👤
7 在现场或同型号电脑试放，检查字体、排版错位、视频播放，完成彩排 讲师、现场设备 活动前 1 天或开场前 1 小时 现场设备 彩排确认 👤人工判断
8 主办方要求提前拿材料时，转 PDF 并加统一水印，不发原件；材料负责人确认后由主办方对接人发出 主办方对接 收到要求后 4 小时内 机器人水印流程（ppt-watermark） 水印 PDF、外发记录 🤖自动化
9 定版回收进母版库，新录 Demo 入库，记录现场反馈与可改进点 材料负责人 活动后 2 个工作日内 母版库、Demo 库 更新的库条目 🔧飞书固化

5. 交付物与模板

  • 交付物：定版 PPT（含备注讲稿）、提词器版、演示视频、水印 PDF、场次台账记录
  • 建议模板/表单：
    • 演讲场次台账：场次、主办方、日期、听众类型、时长、讲师、材料负责人、定版截止、定版链接、是否外发、外发对象、现场反馈
    • 母版库：版本名（科普/政务安全/OPC/高校/workshop）、适用听众、时长、最近更新日期、维护人
    • Demo 库（多维表格）：场景、视频链接、适用听众、时长、质量等级、录制日期、产品版本、是否可外放
    • 评审清单：听众匹配、术语是否过多、每页字数、是否有案例、友商表述、产品名与数据口径、联系方式/二维码、版权页
    • 水印标准：文字“模态跃迁科技版权所有”、透明度、平铺/角标、轻量与强水印两档的适用场合

6. 异常与升级

  • 高管外部峰会/大会场次（CEO 本人上台） → 定版权由材料负责人升级至演讲人（CEO），内容与生态合作页以 CEO 终审为准 → 材料负责人在定版截止前 1 个工作日提交终审
  • 场次确定时距活动不足 3 个工作日 → 直接复用最近定版，只改听众相关页 → 当天告知材料负责人，必要时升级兜底人缩减内容
  • 主办方要求变化（时长、主题、听众） → 主办方对接人当天同步到场次台账并通知讲师 → 影响定版时间时 4 小时内升级材料负责人
  • 评审意见冲突（技术深度与听众接受度） → 以演讲人/技术口径评审人意见为准 → 1 个工作日内无结论升级兜底人
  • 外发对象涉及竞品或渠道敏感场合 → 改用强水印或不外发 → 由材料负责人当天请示兜底人
  • 现场排版错位或设备不兼容 → 立即切 PDF 版播放 → 会后记入现场反馈

7. 衡量指标

  • 按时定版率 = 活动前 48 小时完成定版的场次 / 总场次，目标 ≥ 90%
  • 初稿周期 = 场次确定到初稿完成的工作日，目标 ≤ 2 天
  • 母版复用率 = 基于母版改稿的场次 / 总场次，目标 ≥ 80%
  • 外发合规率 = 外发材料均为水印 PDF 的比例，目标 100%
  • Demo 库入库数 = 每月新增可复用演示视频数，目标逐月增加

8. 低效诊断

  • 现象：场次确定后迟迟开工，彩排前一晚才开始做 PPT，“半小时赶一版”反复出现（启动环节，缺定版截止时间）｜依据：「Claw布道/案例组」2026-03、「【模态】做PPT专用群」2026-07
  • 现象：群文件里有多个版本，要“最新 PPT”只能回复“看群文件”（版本管理环节）｜依据：「Claw布道/案例组」2026-03
  • 现象：演示视频每场临时找人录，质量粗糙，听众容易走神，现有 Demo 数量说不清（素材环节）｜依据：「Claw布道/案例组」2026-03、「Claw布道/案例组」2026-04
  • 现象：评审意见集中在术语太多、字太多、缺案例，每场重复提（评审环节，缺清单）｜依据：「Claw布道/案例组」2026-03
  • 现象：AI 做 PPT 的工具链被不同人重复询问，生成后二次修改费劲（工具环节）｜依据：「模态AI探索小分队」2026-01、「模态AI探索小分队」2026-03
  • 现象：水印做得过强被要求重做，水印标准无人能答（外发环节）｜依据：「Claw布道/案例组」2026-03
  • 现象：峰会材料迭代多版、不同电脑排版不兼容，briefing 未送达演讲人（现场准备环节）｜依据：「【模态】做PPT专用群」2026-07、「【模态】综合部」2026-07

9. 分支变体

  • 政务场次：强调安全治理、少技术细节；使用政务安全版母版
  • OPC/社区场次：强调提效与产品宣传（OPC 社区、一体机）
  • 高校场次：强调应用案例与上手演示
  • 高管外部峰会：增加讲稿、提词器、briefing、生态合作页与二维码，演讲人终审，产品表述经技术负责人确认
  • 内部大会（周年庆等）：材料提前收集给行政调试设备，可不加水印
  • 外发水印：政企客户用轻量水印（防乱转），渠道/竞品在场场合用强水印

10. 待确认问题

  • 材料负责人是否由布道组固定一人担任，峰会场次是否单独由生态市场总监负责？
  • 终稿锁定“活动前 48 小时”是否可行？临时场次如何豁免？
  • 母版库分为科普/政务安全/OPC/高校/workshop 五类是否够用，由谁维护？
  • 公司是否统一推荐 1～2 条 AI 出稿工具链（含离线环境）？
  • 水印标准文字、强弱两档如何定？是否全部交给机器人执行？
  • 外发审批人是材料负责人还是 CTO？
MKT-10客户来访接待与演示待新建135

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：客户、合作方来武汉考察交流，需要安排行程、场地、议程、席卡订餐、演示环境，并在会后形成纪要和跟进事项
  • 负责人：主责——销售总监/客户经理（当前：吴琪·推断待确认）；协同——渠道/演示负责人（当前：闫登辉·推断待确认）、业务专家演示（当前：王满·推断待确认）、会议与场地协助（当前：刘昱潇·推断待确认）、行政/展厅（当前：待指定）；兜底——市场销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 来访登记（时间、人数、名单、目的） → ② 确认场地（会议室/展厅） → ③ 定议程与我方参会人 → ④ 席卡、订餐、接送 → ⑤ 演示环境准备与预演 → ⑥ 接待执行 → ⑦ 会后纪要与跟进任务
  • 交付结果：来访接待单、议程、席卡与餐饮安排、可用的演示环境、会议纪要与跟进任务
  • 状态依据：2026-03～04 一个市场运营群内围绕来访的时间、名单、议程、场地反复沟通约 40 条，CTO 提出“整理一版默认方案”但尚未成文；无接待清单，场地开门、席卡、演示由谁负责每次临时确认

1. 场景判定

  • 触发条件：客户或合作方确定来访日期；外地客户来武汉考察；需要在公司会议室、展厅接待并演示产品
  • 典型说法：「把对方参会人名单发来，要提前做席卡」「会议议程发一下」「展厅那天谁来开」
  • 判断问题：对方是不是到我方场地来？是否需要我方准备场地、餐饮、演示？
  • 不归本流程管：来访报备、行政接待与参观/拍摄通用规则 → 请走 ADM-06（外部来访接待与参观/拍摄报备），本流程只补充客户来访的销售与演示环节；会前口径统一、会后商务复盘与商机推进 → 请走 SAL-08；演示内容与话术 → 请走 SAL-11；演示环境冻结与兜底 → 请走 SAL-12；媒体采访、领导视察 → 请走 BRD-12；政府部门对接 → 请走 POL-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户经理 确认来访信息、定议程、牵头接待、会后纪要与跟进 R/A 销售总监/客户经理（当前：吴琪·推断待确认）
渠道/演示负责人 演示场景与环境、渠道客户陪同 R 销售/渠道负责人（当前：闫登辉·推断待确认）
业务专家 行业场景演示、回答业务问题 C 工程咨询业务专家（当前：王满·推断待确认）
会议与场地协助 会议室预订、会议开通 R 销售（当前：刘昱潇·推断待确认）
行政/展厅 展厅开放、席卡、订餐、接待物料 R 行政（当前：待指定）
市场销售负责人 高规格来访出席、资源协调 A（升级） 市场销售负责人（当前：李鹏为·推断待确认）

3. 办之前请准备

  • 来访信息：单位、来访人名单与职务、人数、到达/离开时间、来访目的、是否需接送
  • 我方参会人名单及是否需要管理层出席
  • 场地：会议室或展厅预约情况、开门人
  • 演示需求：演示哪条产品线、客户行业、需要的样例数据
  • 默认接待方案模板（议程模板、席卡模板、餐标）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填来访接待单：单位、名单、人数、时间、目的、是否需接送与用餐 客户经理 来访确定当天 飞书表单/多维表格“来访登记” 接待单 🔧飞书固化
2 预订会议室或展厅，指定开门与引导人 会议与场地协助、行政 来访前 3 个工作日 飞书会议室 / 群任务 场地确认 🔧飞书固化
3 按默认方案出议程（介绍、演示、交流、参观），确认我方出席人 客户经理 来访前 2 个工作日 飞书文档模板 议程 🤖+👤
4 制作席卡、订餐、安排接送 行政 来访前 1 个工作日 接待清单 席卡、餐饮与车辆安排 🔧飞书固化
5 准备并预演演示环境与样例数据 渠道/演示负责人、业务专家 来访前 1 个工作日 演示环境 演示预演通过 👤人工判断
6 接待执行：签到、介绍、演示、交流，安排专人记录 客户经理 来访当天 飞书妙记 会议记录 🤖自动化
7 输出会议纪要，拆出跟进任务（唯一负责人+截止日），同步 CRM 客户经理 来访后 1 个工作日内 飞书文档 / 飞书任务 / CRM 纪要、跟进任务 🔧+🤖

5. 交付物与模板

  • 交付物：来访接待单、议程、席卡、会议纪要、跟进任务清单
  • 建议模板/表单：
    • 来访接待单：来访单位、来访人与职务、人数、日期时段、目的、我方主陪、我方出席人、场地、是否用餐/接送、演示内容、接待等级
    • 默认议程模板：欢迎与介绍（10 分钟）、产品演示（30 分钟）、交流（30 分钟）、参观展厅（15 分钟）
    • 接待清单：场地确认、开门人、席卡、茶水、餐饮、投屏与网络、演示设备、伴手礼、合影、纪要记录人

6. 异常与升级

  • 来访名单或人数临时变化 → 客户经理当天更新接待单并通知行政 → 影响席卡/餐饮时 2 小时内同步
  • 展厅或会议室冲突 → 行政调整场地 → 无法协调时当天升级市场销售负责人
  • 演示环境预演不通过 → 切换备用环境或录屏 → 来访前 1 天升级 SAL-12 负责人
  • 高规格来访（对方要求管理层出席，或需跨部门调配场地、人员、演示资源） → 客户经理提前 2 个工作日请示 → 决定权升级至市场销售负责人，由其拍板我方出席人与资源安排

7. 衡量指标

  • 接待单提前率 = 来访前 3 个工作日内建单的比例，目标 ≥ 90%
  • 纪要及时率 = 来访后 1 个工作日内出纪要的比例，目标 100%
  • 跟进任务关闭率 = 按期关闭的跟进任务 / 总任务，目标 ≥ 85%
  • 群内确认消息数 = 每次接待在群里的往返确认条数，目标逐月下降

8. 低效诊断

  • 现象：来访时间、名单、议程在群里多轮来回确认，同一次接待产生几十条消息（登记环节，缺接待单）｜依据：「字字可研市场运营」2026-03、「字字可研市场运营」2026-04
  • 现象：场地开门、会议开通、席卡由谁负责每次临时点名（分工环节）｜依据：「字字可研市场运营」2026-04
  • 现象：同类合作交流每次从零准备，没有默认方案（议程环节）｜依据：「字字可研市场运营」2026-03

9. 分支变体

  • 公司会议室接待：标准流程
  • 展厅接待：需提前约开门人与讲解人，增加参观环节
  • 外出拜访：不需场地与订餐，改为出行安排与演示设备携带（设备借用走 ADM-29）
  • 鼎慧（字字可研）客户与 Leap 客户：演示内容与业务专家不同

10. 待确认问题

  • 主责是否为客户经理（谁的客户谁主责），还是由市场统一接待岗负责？
  • 展厅/模态空间的开门与讲解归行政还是市场？当前行政接待人是谁？
  • 默认接待方案是否已有成文版本？餐标与伴手礼标准由谁定？
  • 本流程与 SAL-08（来访交流准备与复盘）是否合并？
MKT-11演示机/试用机准备与分配管理待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：市场、销售或渠道商需要一台演示机或试用/试销机（豪华演示机、工程版演示机、渠道试用机），需从申请、配置硬件软件网络到交付、登记去向和回收全程管理（非正式客户交付）
  • 负责人：主责——市场样机管理员（当前：陈芷青·推断待确认）；协同——市场需求负责人（当前：杨萌·推断待确认）、硬件/网络/账号（当前：游家豪·推断待确认）、软件与模型对接及资产（当前：杨明学·推断待确认）、渠道需求提单（当前：刘昱潇·推断待确认）、规格审批（当前：丁震宇·推断待确认）、现场协助（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人（当前：许君·推断待确认）
  • 核心流程：① 提申请（用途/规格/接收人/期限） → ② 规格确认与审批 → ③ 硬件准备 → ④ 网络接入 → ⑤ 软件模型配置与开账号 → ⑥ 账密托管 → ⑦ 交付给提单人并登记台账 → ⑧ 流转登记、到期回收与盘点
  • 交付结果：可用的演示/试用机、演示机台账记录（编号、机器码、网段、管理员、去向）、交接单、回收记录
  • 状态依据：已有资产审批与表格，但 2026-07～10 演示机每批都从零对齐硬件、网段、席位、管理员归属；三台试用机交给谁、谁在用说不清；管理员账密靠私下发送无留档；市场自用机与渠道机混放难管理

1. 场景判定

  • 触发条件：市场需要自用演示机（展厅、客户体验）；销售/渠道需要试用或试销机；渠道商预订机器先发后结；展会需借信创机器部署；已发出的试用机需要回收或盘点
  • 典型说法：「演示机现在什么进度，给个预计交付时间」「需求是豪华版，按豪华版标准来」「连哪个网段接入的，我能连吗」「谁提的给谁，别分开给不同的人」
  • 判断问题：这台机器是不是用于演示或试用、不是正式卖给客户？是否需要我方配置硬件、网络和软件？
  • 不归本流程管：已有样机的外借审批与出入库 → 请走 ADM-29；演示账号与额度发放 → 请走 SAL-13；客户试用审批与转化 → 请走 SAL-16；活动现场演示设备运输 → 请走 MKT-05；正式客户/渠道订单交付 → 请走 SAL-31；资产季度盘点 → 请走 ADM-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
市场样机管理员 接收交付、维护台账、登记内外部流转、到期回收 R 市场部样机管理（当前：陈芷青·推断待确认）
市场需求负责人 提出用途与规格、区分市场自用与渠道用 R 产品总监/市场需求方（当前：杨萌·推断待确认）
渠道需求提单 渠道试用/预订提单 R 销售（当前：刘昱潇·推断待确认）
硬件/网络/账号 库存确认、装机、网段接入、服务端账号 R 运维/交付工程师（当前：游家豪·推断待确认）
软件与资产 模型接入、软件配置、资产编号与审批 R IT 运维/资产（当前：杨明学·推断待确认）
规格审批 拍板规格、优先发机、安全风险结论 A 创始人兼 CTO（当前：丁震宇·推断待确认）
现场协助 展厅摆放、外设到位 C 行政（当前：胡则瑾·推断待确认）
财务 资产入账与盘点核对 I 财务（当前：待指定）

3. 办之前请准备

  • 用途：市场自用 / 渠道试用 / 工程行业版 / 展会借用
  • 规格：标准版或豪华版、席位数、存储（如全闪盘）、外设（麦克风、触屏平板）
  • 接收人（唯一）、使用地点、预计归还日期
  • 网络要求：是否接内网、需要的网段
  • 需预装的软件版本与模型
  • 渠道试用需附渠道信息与审批单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交演示/试用机申请：用途、规格、席位、外设、接收人、期限 市场需求负责人 / 渠道需求提单 需用日前 10 个工作日 飞书审批“演示/试用机申请” 申请单 🔧飞书固化
2 确认规格与优先级，渠道机先确认软件安全风险（机器码追踪） 规格审批 收到后 2 个工作日内 飞书审批 审批结论 👤人工判断
3 确认库存、装机、外设到位，给出预计交付日期 硬件/网络/账号 审批后 1 个工作日内回复交期 多维表格“演示机台账” 交期承诺 🔧飞书固化
4 按台账指定网段接入（演示机走隔离网段，不接办公内网） 硬件/网络/账号 装机完成当天 网络设备 网段记录 👤人工判断
5 配置模型接入与软件、开演示用服务端账号 软件与资产 装机后 2 个工作日内 服务端 / LeapCore 可用系统 🔧+🤖
6 管理员账密存入公司密钥托管，台账只记托管位置和管理员岗位，不在聊天中明文发送 硬件/网络/账号 开账号当天 密钥管理工具 托管记录 🔧飞书固化
7 只交付给提单人/市场样机管理员，签交接单，登记资产编号、机器码、去向 市场样机管理员 交付当天 演示机台账 + 资产审批 交接单、台账记录 🔧飞书固化
8 每次内外部流转登记；到期前 3 天自动提醒归还或续借；回收后复位系统并入库 市场样机管理员 流转当天登记；到期日回收 多维表格自动提醒 流转与回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：演示/试用机实机、交接单、台账记录、回收记录
  • 建议模板/表单：
    • 演示机台账：资产编号、型号/规格（标准/豪华/工程版）、机器码、席位数、外设清单、网段、软件版本、管理员岗位、账密托管位置、用途（市场自用/渠道试用/展会）、当前保管人、所在地点、交付日期、约定归还日、状态
    • 申请单字段：用途、规格、外设、接收人、使用地点、期限、关联客户/渠道、是否接内网

6. 异常与升级

  • 交期无法满足 → 硬件/网络/账号 1 个工作日内说明原因并给新日期 → 影响客户或展会时升级规格审批人
  • 试用机去向不明 → 市场样机管理员 2 个工作日内追查流转记录 → 仍不明升级兜底人并通知财务
  • 渠道要求部署到自备硬件 → 先确认软件安全与授权方式 → 由规格审批人拍板
  • 到期未归还 → 自动提醒后 5 个工作日仍未归还，升级需求方负责人；超 30 天转销售或计入损失

7. 衡量指标

  • 交付准时率 = 按承诺日期交付台数 / 总交付台数，目标 ≥ 90%
  • 台账完整率 = 字段齐全（含去向、机器码、托管位置）的台数 / 在册台数，目标 100%
  • 去向可查率 = 盘点时能定位的演示/试用机比例，目标 100%
  • 超期未归还台数 = 超约定归还日 30 天未回收数，目标 0

8. 低效诊断

  • 现象：每批演示机都从零沟通硬件、网段、席位，反复追问“管理员在谁那”“连哪个网段”（配置环节，缺台账）｜依据：「豪华演示机」2026-09、「豪华演示机」2026-10
  • 现象：市场自用机与渠道机混在一起，难以管理（登记环节）｜依据：「豪华演示机」2026-09
  • 现象：试用机交给了谁、后续谁在用说不清，审计盘点时找不到设备（交付与流转环节）｜依据：「豪华演示机」2026-09
  • 现象：管理员账密靠单独发送，无留档（账号环节）｜依据：「豪华演示机」2026-09
  • 现象：规格标准不清，需负责人当场拍板“按豪华版来”（申请环节）｜依据：「豪华演示机」2026-10

9. 分支变体

  • 豪华演示机：市场与渠道通用，含全闪盘、触屏平板等高配外设
  • 工程行业版演示机：面向工程客户渠道，预装行业版软件
  • 渠道试用/试销机：交付给提单人，市场总负责人登记内外部流转；带 CPE 的市场配套版预留固定套数
  • 渠道自备硬件：我方仅部署软件，需先确认安全风险与机器码追踪
  • 展会借用信创机器：按 ADM-29 外借，活动后归还

10. 待确认问题

  • 市场样机总负责人是否确定为市场部一人？与 ADM-29 的样机外借如何分工？
  • 演示机规格是否形成标准版/豪华版/工程版三档配置单？
  • 演示机是否统一走隔离网段？账密托管用哪种工具？
  • 试用机期限默认多少天？超期如何处理（转售/计损）？
  • 申请提前 10 个工作日是否可行？
MKT-12外部合作与政府需求线索接收及分派待新建60

状态：待新建｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频2 × 耗2 × 跨5 × 险3

  • 适用场景：外部公司、硬件厂商、电商渠道或政府部门联系我方谈合作、要培训方案或接待安排，需统一接收、指派对接人、安排试用，进入方案阶段后由单一负责人出方案 PPT 并统一口径
  • 负责人：主责——生态市场线索接口人（当前：许君·推断待确认）；协同——市场销售负责人（当前：李鹏为·推断待确认）、产品负责人/试用安排（当前：杨萌·推断待确认）、创始人兼 CTO/技术口径（当前：丁震宇·推断待确认）、运营/FDE（当前：李凯·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 任何人收到即登记转交 → ② 分类 → ③ 按路由表指派对接人 → ④ 首次联系与材料互换 → ⑤ 需要时安排试用 → ⑥ 方案阶段单人出方案与口径 → ⑦ 评审后对外提交 → ⑧ 结果写入 CRM
  • 交付结果：合作线索登记记录、指派结果、首次沟通纪要、（如需）试用开通、合作方案/培训方案 PPT、CRM 跟进记录
  • 状态依据：无统一合作入口与路由规则；2026-06 政府部门来电要培训方案时需在群里问“谁对接合适”再临时点名；2026-01 外部合作方的试用安排靠口头和临时微信群，拉群后冷场无人跟进；合作方案无模板、无单一负责人

1. 场景判定

  • 触发条件：外部公司（电商、硬件厂商、软件公司）提出合作；政府部门来电要求培训方案、参观接待；合作方希望先试用；合作推进到需要出合作方案或汇报 PPT
  • 典型说法：「这种让谁对接合适？」「我拉个群你安排一下试用」「区里要办一个培训班，让我们拿个方案」
  • 判断问题：对方是要“合作/方案/培训”，而不是直接买产品？是否还没有明确的我方对接人？
  • 不归本流程管：客户购买咨询、预约演示等销售线索 → 请走 SAL-02；渠道代理授权与协议 → 请走 SAL-27；预装/贴牌等非标合作承诺审批 → 请走 SAL-28；客户试用额度审批 → 请走 SAL-16；政府部门日常对接与挂牌 → 请走 POL-02；媒体与领导到访接待 → 请走 BRD-12；对外讲课与培训交付 → 请走 ECO-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
线索接口人 统一接收、分类、按路由指派、跟踪到首次沟通 R/A 生态市场总监（当前：许君·推断待确认）
首接人 收到外部来电/消息后用标准话术回应并登记 R 全员（研发、HR、运营等）
销售对接人 政企、培训类线索的商务对接与报价 R 市场销售负责人（当前：李鹏为·推断待确认）
产品/试用 安排试用、产品介绍 R 产品总监（当前：杨萌·推断待确认）
技术口径与方案 合作方案技术部分、合作边界 C 创始人兼 CTO（当前：丁震宇·推断待确认）
运营/FDE 政府培训需求首接、培训内容支持 C FDE/运营负责人（当前：李凯·推断待确认）
CEO 政府资源、重大合作拍板 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 对方信息：单位、联系人岗位、联系方式（登记在系统内，不在群里转发）、来源渠道
  • 需求描述：合作类型、期望时间、预算或付费能力判断、是否要求试用/方案
  • 我方标准材料：公司介绍、产品手册、合作模式说明
  • 路由表：合作类型 → 对接岗位
  • 合作方案模板与“上下文 md”标准格式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 首接人用标准话术回应（已转负责人，请先发材料），填“合作线索登记”表单 首接人 收到当天 飞书表单 / 统一合作邮箱 线索记录 🔧飞书固化
2 分类：电商/渠道合作、硬件厂商预装、政府培训/接待、其他 线索接口人 登记后 1 个工作日内 多维表格 分类结果 🤖+👤
3 按路由表指派唯一对接人，机器人通知对接人并抄送首接人 线索接口人 分类当天 飞书机器人 指派记录 🔧飞书固化
4 首次联系，发送标准材料，判断合作价值与对方付费能力 对接人 指派后 2 个工作日内 电话/会议 首次沟通纪要 👤人工判断
5 需要试用的转 SAL-16 申请额度与开通，并指定试用期跟进人 对接人、产品/试用 首次沟通后 2 个工作日内 飞书审批 试用开通 🔧飞书固化
6 进入方案阶段：对接人为唯一方案负责人，先整理上下文 md，再按模板出一版 PPT；其他人只评审不另起版本 对接人 约定提交日前 3 个工作日出初稿 方案模板 + AI 工具 方案初稿 🤖+👤
7 评审方案口径（价值点、合作边界、分润或报价）后对外提交 技术口径与方案、销售对接人 收到初稿后 1 个工作日内 飞书文档评论 定稿方案 👤人工判断
8 结果写入 CRM，约定下一步与时间；不推进的标注原因关闭 对接人 每次沟通后 1 个工作日内 CRM 跟进记录 🔧飞书固化

5. 交付物与模板

  • 交付物：合作线索登记记录、首次沟通纪要、合作/培训方案、CRM 跟进记录
  • 建议模板/表单：
    • 合作线索登记：来源（来电/邮件/转介绍/政府）、单位类型、合作类型、需求描述、首接人、登记日期、指派对接人、状态（待指派/沟通中/试用/方案/签约/关闭）、关闭原因
    • 路由表：电商/渠道合作 → 销售对接；硬件厂商预装 → 产品+CTO；政府培训/接待 → 销售对接+运营/FDE；未识别 → 线索接口人
    • 合作方案模板：对方现状、合作价值三点（提升对方产品竞争力、省研发成本、分润/收益）、合作模式、分工、时间表、下一步
    • 首接标准话术：已收到并转相关负责人，请先发送公司与合作材料，我方将在 2 个工作日内联系

6. 异常与升级

  • 线索 1 个工作日未被指派 → 机器人提醒线索接口人 → 2 个工作日仍未指派升级 CEO
  • 对方要求与产研排期冲突（如“排满后再处理”） → 对接人当天告知对方预计时间 → 涉及承诺需走 SAL-28
  • 政府类需求对方付费能力不明 → 先给标准方案与形态选项 → 重大资源事项升级 CEO
  • 多人同时在做方案 → 线索接口人当天指定唯一负责人，其他版本作为输入合并
  • 涉及政府资源对接或重大合作（需公司层面承诺、专项投入或排他条款） → 决定权由线索接口人升级至 CEO 拍板 → 线索接口人 1 个工作日内提请

7. 衡量指标

  • 指派时效 = 登记到指派的工作日，目标 ≤ 1 天
  • 首次联系时效 = 指派到首次沟通的工作日，目标 ≤ 2 天
  • 线索登记率 = 已登记线索 / 群内出现的外部合作需求，目标 100%
  • 方案单版本率 = 只出一版方案的合作数 / 进入方案阶段的合作数，目标 ≥ 90%

8. 低效诊断

  • 现象：政府部门来电要培训方案，接到的人在群里问谁对接，靠临时点名指派（接收环节，缺路由表）｜依据：「【模态】媒体对接&领导接待」2026-06
  • 现象：外部合作方拉群后试用安排靠口头，群内冷场无人跟进（试用环节）｜依据：「鼎慧产研决策部」2026-01
  • 现象：政府培训需求进来后要先讨论对方付费能力才能定产品形态，无标准方案可直接提供（方案环节，缺模板）｜依据：「【模态】媒体对接&领导接待」2026-06、「【模态】媒体对接&领导接待」2026-07

9. 分支变体

  • 电商/渠道合作（如对方代开网店销售产品）：转销售对接，可配试用
  • 硬件厂商 AI 预装合作：产品+CTO 出方案，口径围绕竞争力、省研发、分润三点；承诺类事项走 SAL-28
  • 政府培训方案：销售对接+运营/FDE 出培训方案，交付走 ECO-13
  • 政府媒体/领导接待：转 BRD-12
  • 信创、代理培训类合作：按路由表分派

10. 待确认问题

  • 线索接口人是否由生态市场总监担任，还是由市场销售负责人担任？
  • 是否开设统一合作邮箱或官网合作表单？
  • 政府类线索归市场、销售还是政策申报岗？
  • 合作方案模板是否以现有硬件厂商合作方案为基础？
  • 首次联系 2 个工作日时限是否可行？
MKT-13第三方平台/商城上架与消费券推广待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：政府或第三方平台（武创通 AI 商城、OPC 社区商城、超算互联网商城）开放入驻、统一批次上架、征集活动厂商或发放体验券批次时，准备商品信息与合规文案、录入卡密、上架，并推动内部及用户领券购买
  • 负责人：主责——外部平台上架对接人（当前：杨萌·推断待确认）；协同——OPC 社区运营（当前：陈梦琪·推断待确认）、政策口径（当前：邴龙志·推断待确认）、研发/卡密与说明（当前：邓乾·推断待确认）、商城后端（当前：葛家和·推断待确认）、运营答疑与问卷（当前：胡橙橙·推断待确认）、宣发策略（当前：李凯·推断待确认）、平台入驻材料（当前：闫登辉·推断待确认）、平台通知转发（当前：宋祺睿·推断待确认）、新员工通知（当前：胡则瑾·推断待确认）；兜底——生态市场条线负责人
  • 核心流程：① 平台通知登记并指定响应人 → ② 参与决策 → ③ 入驻材料 → ④ 商品信息与合规预审 → ⑤ 价格档位与卡密导入 → ⑥ 平台就绪检查后上架 → ⑦ 购买指南与 FAQ 发布 → ⑧ 领券推广答疑 → ⑨ 批次复盘
  • 交付结果：已上架商品（名称合规、说明齐全、卡密到位）、购买指南与 FAQ、领券推广通知、问卷与销量汇总
  • 状态依据：已有购买指南网页、问卷、商品使用说明文档和补贴产品标准，但 2026-03～07 出现平台“今日内回复”的征集通知无人认领、商品名上线前一天才因政策口径改名、卡密先于平台上线预售需紧急叫停、领券条件被反复问约 5 次

1. 场景判定

  • 触发条件：平台发布入驻/统一上架批次；平台征集活动厂商（地推、展位、体验券）；政府体验券批次开放；新产品需要上架到外部商城；商品名称或说明需按政策调整
  • 典型说法：「上架要等平台统一下一批才能上」「下周社区有一批上线，一起上一下」「政策写的是买 AI 产品，不能是这种券啊、币啊」「第二批体验券申领通道今天开启」「上次领过了，这次还能领吗」
  • 判断问题：是不是把我方产品放到外部平台售卖，或推动用户用政府券购买我方产品？
  • 不归本流程管：我方 OPC 商城自营商品上下架与补货 → 请走 OPS-11；第三方商家入驻我方 OPC 社区 → 请走 ECO-07；补贴政策研判与申报 → 请走 POL-01；申报用公司资质资料 → 请走 POL-03；线下参展执行 → 请走 MKT-03；营销裂变活动 → 请走 MKT-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
上架对接人 平台对接、决策汇总、上架执行与进度 R/A 产品总监（当前：杨萌·推断待确认）
OPC 社区运营 OPC 社区商城上架、专家评审对接、上线通知 R 生态组负责人（当前：陈梦琪·推断待确认）
政策口径 商品名称、说明是否符合补贴政策 A（升级） CEO（当前：邴龙志·推断待确认）
研发 商品使用说明、卡密 CSV、兑换功能就绪 R LeapAll 服务端研发（当前：邓乾·推断待确认）
商城后端 商城侧商品与卡密导入 R OPC 平台研发（当前：葛家和·推断待确认）
运营答疑 购买指南、问卷、FAQ、群内答疑 R 运营/客服（当前：胡橙橙·推断待确认）
宣发策略 上架时点与发布会节点协调 C 运营负责人（当前：李凯·推断待确认）
入驻材料 新平台发现与商家手册入驻 R 渠道负责人（当前：闫登辉·推断待确认）
通知转发 平台通知转入内部台账 I 研发（当前：宋祺睿·推断待确认）
行政 向新员工转发领券流程 I 行政负责人（当前：胡则瑾·推断待确认）
财务 价格档位、补贴结算与开票口径 C 财务（当前：待指定）

3. 办之前请准备

  • 平台通知原文、回复截止时间、批次时间表
  • 平台商家手册与入驻所需资质（营业执照、软著、产品介绍等，从 POL-03 资料库调取）
  • 补贴产品标准文件与命名禁忌（避免“币/券”类字样）
  • 商品信息：名称、各平台统一叫法、价格档位（一商品一价格）、使用说明、售后联系人
  • 卡密批次 CSV 与兑换功能上线状态
  • 购买指南网页与 FAQ 底稿

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 平台通知统一录入“渠道活动台账”，指定响应人和平台截止时间 上架对接人 收到当天（平台要求当日回复的 2 小时内） 多维表格 + 机器人提醒 台账记录 🔧飞书固化
2 决定是否参与/上架，与发布会等宣发节点对齐 上架对接人、宣发策略 平台截止前 群内决策 / 飞书审批 参与结论 👤人工判断
3 新平台按商家手册完成入驻材料提交 入驻材料 决策后 3 个工作日内 平台后台 入驻申请 👤人工判断
4 编写商品名称与说明，对照补贴标准做合规预审；各平台名称口径统一 上架对接人、政策口径 上架前 3 个工作日 合规检查清单 预审通过的商品文案 👤人工判断
5 设定价格档位，研发出卡密 CSV，用脚本批量导入 研发、商城后端 上架前 2 个工作日 脚本 + 商城后台 卡密导入记录 🤖自动化
6 平台就绪检查：我方兑换功能已上线、试兑成功后才允许开售，禁止先于平台上线预售 上架对接人 开售前 1 个工作日 就绪检查单 就绪确认 👤人工判断
7 提交平台评审/上架，上线后通知社区与内部群 OPC 社区运营 / 上架对接人 按平台批次 平台后台 / 群公告 上架成功 👤人工判断
8 发布购买指南与 FAQ（领取条件、地域限制、重复领取、小程序异常），批次开放时机器人推送 运营答疑 批次开放当天 购买指南网页 / 机器人 指南与 FAQ 🔧+🤖
9 收集问卷与销量，汇总到多维表格，批次结束复盘 运营答疑 批次结束后 3 个工作日内 多维表格 批次复盘 🤖自动化

5. 交付物与模板

  • 交付物：已上架商品、商品使用说明、购买指南与 FAQ、问卷汇总、批次复盘
  • 建议模板/表单：
    • 渠道活动台账：平台名、通知类型（入驻/上架批次/地推征集/体验券批次）、收到日期、平台截止时间、响应人、是否参与、状态
    • 上架清单：商品名（合规检查结果）、各平台统一叫法、说明文档链接、价格档位、卡密批次与数量、售后联系人、我方平台就绪状态、评审批次
    • FAQ：领取资格、地域限制、可否重复领取、领券后如何兑换、兑换失败如何处理、售后联系人

6. 异常与升级

  • 平台要求当日回复且响应人未定 → 上架对接人 2 小时内认领 → 无人认领升级兜底人
  • 商品名或说明不符合补贴政策、或合规预审有分歧 → 只改平台商品页文案，平台内叫法同步备注 → 当天升级政策口径（CEO）拍板，以其结论为准
  • 卡密已售但兑换失败 → 立即暂停售卖，运营统一回复用户 → 1 小时内升级研发与上架对接人，必要时退款（走财务）
  • 上架时点与发布会冲突 → 宣发策略与上架对接人协商 → 1 个工作日内无结论升级 CEO

7. 衡量指标

  • 通知响应及时率 = 在平台截止时间前回复的通知 / 总通知，目标 100%
  • 一次评审通过率 = 首次提交即通过的商品 / 提交商品，目标 ≥ 90%
  • 上架后兑换故障数 = 上架后 7 天内兑换失败工单数，目标 0
  • 重复咨询数 = 批次开放后群内同类领取问题数，目标逐批下降
  • 券转化数 = 每批次领券购买我方产品的订单数

8. 低效诊断

  • 现象：平台征集通知要求当日回复，转发到群后无人认领（通知接收环节）｜依据：「跃迁AI总动员」2026-04
  • 现象：是否上架、何时上架与大会发布节点冲突，临时讨论（决策环节）｜依据：「跃迁AI总动员」2026-04、「跃迁AI总动员」2026-05
  • 现象：商品命名在上线前一天才因补贴口径被要求改名，平台内与社区叫法不一致（合规预审环节）｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：卡密先行预售而我方兑换未上线，用户买后无法使用需紧急叫停（就绪检查环节）｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：领券资格、地域限制、重复领取被反复询问，新人需翻通知群找流程（答疑环节）｜依据：「跃迁AI总动员」2026-07
  • 现象：入驻步骤需要临时查阅商家手册（入驻环节）｜依据：「字字可研市场运营」2026-03

9. 分支变体

  • 武创通 AI 商城：需等平台统一批次上架；体验券分批开放，有地域与领取次数限制
  • OPC 社区商城（对接政府补贴）：按补贴产品标准专家评审，分批上线，商品名避免“币/券”
  • 超算互联网商城等新平台：按商家手册三步入驻
  • 线下地推/展位征集：是否参与由上架对接人与宣发策略决定，执行转 MKT-03
  • 产品差异：LeapAll、LeapPPT、字字可研分别准备说明与指南

10. 待确认问题

  • 外部平台上架主责是否为产品总监，还是由生态市场条线指定专人？
  • 商品名称合规由谁最终签字（CEO、政策申报岗还是法务）？
  • 卡密导入脚本是否已有？由研发还是商城后端维护？
  • 体验券销售的补贴结算与开票口径是否已有财务规则？
  • 各平台统一商品叫法是否需要一张对照表？
MKT-14营销活动与裂变玩法策划及合规审批待新建180

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：产品进入拉新或推广阶段，有人提出营销创意（砍一刀、拼车、大赛、校园大使/代理、KOL、赛事合作等），需要统一提报、细化方案与预算、合规把关、审批后执行并复盘；赛事主办方或校园大使索要算力券/API 额度时按权益菜单审批
  • 负责人：主责——运营负责人（当前：李凯·推断待确认）；协同——KOL/渠道运营（当前：胡橙橙·推断待确认）、校园地推方案（当前：刘昱潇·推断待确认）、校园大使与赛事合作（当前：陈梦琪·推断待确认）、渠道运营（当前：杨朋伟·推断待确认）、风控/防刷（当前：陈晖·推断待确认）、营销合规提醒（当前：李鹏为·推断待确认）、策略与技术可行性（当前：丁震宇·推断待确认）、预算审批（当前：邴龙志·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人
  • 核心流程：① 点子入池 → ② 每周初筛 → ③ 细化活动策划卡 → ④ 合规评审 → ⑤ 预算与权益审批 → ⑥ 排期执行 → ⑦ 发放登记与对账 → ⑧ 复盘
  • 交付结果：审批通过的活动策划卡、合规评审意见、预算/权益审批单、发放与对账记录、活动复盘报告
  • 状态依据：点子多但集中在群聊，2026-03～05 约 4 个群出现“谁来策划”“不是运营部”的推诿、方案等审批、预算与规则无审批、校园大使等提成但无成文政策、敏感内容发出后才被提醒；赛事/校园合作索要的算力券与额度无成文权益菜单和审批人

1. 场景判定

  • 触发条件：产品内测转拉新；有人在群里提出营销/裂变/病毒式传播创意；需要校园代理、社团、表白墙、KOL 推广；赛事主办方、校园大使向公司要算力券/API/编码工具额度作为奖励
  • 典型说法：「谁策划一个针对大学生的营销计划」「来点营销手段，转化率不够」「前期校园尽可能无死角覆盖」「咱可不能做这种营销，容易被封」
  • 判断问题：这件事是否要对外发起一个有规则、有预算或有权益发放的营销动作？
  • 不归本流程管：活动传播物料与社媒文案制作 → 请走 OPS-13；投流与代理商推广预算 → 请走 MKT-15；渠道代理授权与协议签署 → 请走 SAL-27；给单个客户赠送额度报备 → 请走 SAL-17；营销短信内容合规 → 请走 LEG-21；外部平台消费券推广 → 请走 MKT-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
运营负责人 维护点子池、每周初筛、指定活动负责人、组织复盘 R 运营负责人（当前：李凯·推断待确认）
活动负责人 细化策划卡、执行、数据回收 R KOL/渠道运营（当前：胡橙橙·推断待确认）、校园地推（当前：刘昱潇·推断待确认）、渠道运营（当前：杨朋伟·推断待确认）按活动指定
校园大使与赛事合作 收集合作方权益诉求、按权益菜单提申请 R 生态组负责人（当前：陈梦琪·推断待确认）
风控 邀请码、防刷量、AB 测设计 C 基座组架构负责人（当前：陈晖·推断待确认）
合规评审 敏感话题、平台规则、品牌调性 C 市场销售负责人（当前：李鹏为·推断待确认）、法务（当前：待指定）
策略与技术可行性 研发排期、权益形式可给范围 C 创始人兼 CTO（当前：丁震宇·推断待确认）
预算审批 活动预算与权益额度审批 A CEO（当前：邴龙志·推断待确认）
财务 预算科目、分成与提成结算 C 财务（当前：待指定）

3. 办之前请准备

  • 活动目标：拉新数、转化率、目标人群
  • 玩法与规则草案、防刷方式（邀请码、实名、用量对账）
  • 预算估算与权益形式（券、额度、实物、提成）
  • 所需研发支持与上线时间
  • 合规自查：是否涉及敏感话题、学生代理层级、平台规则、诱导分享
  • 可参考的现有方案（如 U 盘分销商业与交付方案的分工、结算与风控规则）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 点子提交到“营销点子池”：目标人群、玩法、预算估算、预期指标、合规风险自评 提议人（任何人） 随时 飞书表单 → 多维表格 点子记录 🔧飞书固化
2 每周初筛，选出进入策划的点子并指定唯一活动负责人 运营负责人 每周一 多维表格 / 周会 初筛结论 👤人工判断
3 填写活动策划卡：规则、预算、素材、防刷、归因（UTM/邀请码）、上线时间、复盘指标 活动负责人 指定后 3 个工作日内 飞书文档模板 策划卡 🤖+👤
4 合规评审：敏感内容、平台规则、学生代理层级与提成边界、诈骗与刷量风险、品牌调性 合规评审、风控 收到策划卡后 2 个工作日内 合规审阅清单 评审意见 👤人工判断
5 预算与权益审批：按权益菜单申请券/额度，超菜单的由预算审批人特批 活动负责人 → 预算审批 评审通过后 2 个工作日内 飞书审批“营销活动/权益申请” 审批单 🔧飞书固化
6 排期执行：研发需求走排期，素材走 OPS-13，渠道/KOL 对接 活动负责人 按策划卡时间 飞书任务 活动上线 🔧飞书固化
7 发放登记：权益、邀请码、提成按人登记，月度对账 活动负责人、财务 发放当天登记；次月 5 个工作日内对账 多维表格 发放与对账记录 🔧+🤖
8 活动结束复盘：拉新、转化、成本、问题，决定是否复制 运营负责人 结束后 5 个工作日内 飞书文档 / UTM 自动周报 复盘报告 🤖+👤

5. 交付物与模板

  • 交付物：活动策划卡、合规评审记录、审批单、发放与对账台账、复盘报告
  • 建议模板/表单：
    • 营销点子池：提议人岗位、目标人群、玩法简述、预算估算、预期指标、合规风险自评、状态（待筛/策划中/否决/执行/复盘）
    • 活动策划卡：目标、人群、规则、时间、预算、权益、素材清单、渠道、防刷措施、归因方式、负责人、复盘指标
    • 权益菜单：权益类型（算力券、API 额度、编码工具限量额度、云服务）、单次上限、发放方式（按 token 量，不按天免费）、审批人
    • 合规审阅清单：敏感话题、违法违规梗、平台诱导分享规则、学生代理层级、价格与提成口径、AI 生成内容标识

6. 异常与升级

  • 点子提出后无人认领 → 运营负责人在下次周会指定或否决 → 连续 2 周未处理升级兜底人
  • 合规评审有分歧 → 暂停上线 → 2 个工作日内升级法务与 CEO 决定
  • 内容已发出后发现敏感问题 → 立即撤回 → 当天报告合规评审人并复盘
  • 发现刷量或代理违规 → 冻结权益发放 → 1 个工作日内升级风控与 CEO
  • 预算超出审批额度 → 暂停投入 → 重新提审批

7. 衡量指标

  • 点子处理时效 = 入池到初筛结论的天数，目标 ≤ 7 天
  • 审批周期 = 策划卡提交到审批完成的工作日，目标 ≤ 4 天
  • 合规事故数 = 活动上线后因内容或规则被平台处罚/撤回的次数，目标 0
  • 获客成本 = 活动总投入 / 新增有效用户，按活动对比
  • 复盘完成率 = 完成复盘的活动 / 已结束活动，目标 100%

8. 低效诊断

  • 现象：点子多但无人承接，提议人因“不是运营部”无法推进，讨论停在群聊（提报与指派环节）｜依据：「LeapPPT」2026-05
  • 现象：“来点营销手段”缺转化数据支撑，被质疑后无结论（方案环节，缺策划卡与指标）｜依据：「LeapPPT」2026-05
  • 现象：校园地推方案等审批，分成与人头费、直营与渠道口径反复（审批环节）｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：敏感梗图与营销创意发出后才被提醒合规（合规评审环节）｜依据：「模态AI探索小分队」2026-03、「模态AI探索小分队」2026-05
  • 现象：校园大使等提成但无成文政策，落地时直接催研发“明天可以吗”（执行环节）｜依据：「模态AI探索小分队」2026-05

9. 分支变体

  • 线上裂变（砍一刀、拼车、邀请码）：需防刷与归因设计
  • 校园推广（学校代理、社团代理、表白墙）：代理层级不超过两级，提成规则成文并经法务确认，邀请码与用量对账
  • KOL/小红书/二手平台渠道：由 KOL/渠道运营对接，内容按合规清单审
  • 赛事合作与校园大使权益：按权益菜单发放，不接受“按天免费”，研发先跑通发放方案再批量复用
  • U 盘等实体渠道版：参照现有分销方案的分工、结算与风控规则，协议走 SAL-27

10. 待确认问题

  • 运营负责人是否确定为现任 FDE/运营负责人？与报送的运营负责人如何分工？
  • 营销预算审批人是否统一为 CEO？是否有金额分级？
  • 学生代理、提成政策是否需法务出具成文规则？
  • 权益菜单的额度上限由谁定？
  • 点子池每周初筛是否并入现有周会？
MKT-15推广投放预算审批与效果复盘待优化144

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：运营或外部代理商提出投流、KOC、自媒体推广方案时，完成成本审核与预算审批、素材评审、上线投放、每周效果报告，预算耗尽或周期结束后复盘决定是否续投
  • 负责人：主责——跃竞业务负责人（当前：徐莉·推断待确认）；协同——内容/投放运营（当前：宫经喜·推断待确认）、销售/市场（当前：黄捷·推断待确认）、代理商方案审核（当前：杨萌、李鹏为·推断待确认）、关联业务方审批（当前：刘恒昊·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提投放方案 → ② 成本审核与比价 → ③ 预算审批 → ④ 素材评审 → ⑤ 上线投放 → ⑥ 每周效果报告 → ⑦ 预算耗尽/周期结束复盘 → ⑧ 决定续投、调整或停止
  • 交付结果：审批通过的投放方案与预算单、评审过的素材、每周投放效果报告、复盘纪要与唯一负责人的待办清单
  • 状态依据：已有 wiki 每周投放效果报告和复盘会，但 2026-07～10 预算申请、方案审批依赖群聊 @ 人；复盘待办在多人消息中重复整理且负责人出现两版；代理商方案成本未定时无人明确负责审核；外部服务商需临时找两三家比价

1. 场景判定

  • 触发条件：运营准备投流或上线新广告/活动；外部代理商提交自媒体推广方案；计划采购 KOC 铺量等外部服务；投放预算耗尽或投放周期结束
  • 典型说法：「运营这边准备做投流，需要一笔预算，看能否批准」「代理商给的推广方案，成本没定下来，需要审核补充敲定终版」「找两三家公司比比价」
  • 判断问题：是否要花钱买流量或外部推广服务？预算和效果是否需要被跟踪复盘？
  • 不归本流程管：营销活动玩法与合规 → 请走 MKT-14；新媒体自然内容生产发布 → 请走 BRD-08；新媒体数据周复盘 → 请走 BRD-10；推广服务合同审核 → 请走 LEG-04；付款 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
业务负责人 提方案、组织审批与复盘、确定待办负责人 R 跃竞负责人（当前：徐莉·推断待确认）
投放运营 素材制作、投放执行、每周报告 R 内容/投放运营（当前：宫经喜·推断待确认）
销售/市场 承接线索转化、复盘待办 R 销售/市场（当前：黄捷·推断待确认）
代理商方案审核 审核代理商成本、范围与终版 C 产品总监、市场销售负责人（当前：杨萌、李鹏为·推断待确认）
预算审批 审批预算与续投 A 创始人兼 CTO（当前：丁震宇·推断待确认）
关联业务方会签 跃竞投放预算会签意见 C 关联业务方（当前：刘恒昊·推断待确认）
财务 预算科目、付款与发票 C 财务（当前：待指定）

3. 办之前请准备

  • 投放方案：渠道（小红书、抖音、信息流等）、预算、周期、目标 KPI（曝光、获客、转化）、素材清单
  • 代理商方案：成本明细、服务范围、交付物、结算方式；外部服务商至少两三家报价
  • 上一轮投放效果报告与复盘结论
  • 落地页与转化追踪方式（如 UTM、专属链接）
  • 第三方发布内容的合规要求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填投放方案：渠道、预算、周期、KPI、素材、追踪方式 业务负责人 计划上线前 5 个工作日 飞书文档模板 投放方案 🔧飞书固化
2 成本审核：代理商方案补齐成本明细；外部服务商至少比价 2～3 家 代理商方案审核、业务负责人 收到方案后 3 个工作日内 比价表 审核意见、比价结果 👤人工判断
3 提交预算审批，附方案与比价 业务负责人 → 预算审批 审批人 2 个工作日内处理 飞书审批“营销投放费用” 审批单 🔧飞书固化
4 素材评审：新广告素材与第三方发布内容按合规清单审核 投放运营 → 业务负责人 上线前 1 个工作日 飞书文档评论 定稿素材 👤人工判断
5 上线投放，记录开始时间与预算消耗节奏 投放运营 按审批时间 投放平台 投放记录 👤人工判断
6 每周更新效果报告：消耗、曝光、点击、获客、转化（含俱乐部转化）、获客成本 投放运营 每周一 多维表格 + wiki 报告 周报 🤖自动化
7 预算耗尽或周期结束开复盘会，纪要自动生成待办，每项唯一负责人与截止日 业务负责人 结束后 3 个工作日内 飞书会议 + 纪要机器人 + 飞书任务 复盘纪要、待办 🔧+🤖
8 决定续投/调整渠道/停止，续投重新走第 3 步 预算审批 复盘后 2 个工作日内 飞书审批 续投结论 👤人工判断

5. 交付物与模板

  • 交付物：投放方案、比价表、预算审批单、素材定稿、每周效果报告、复盘纪要与待办
  • 建议模板/表单：
    • 投放预算审批表：渠道、预算、周期、目标 KPI、素材链接、追踪方式、供应商、比价附件、申请人
    • 周报（多维表格）：周次、渠道、消耗、曝光、点击、获客数、转化数、获客成本、备注
    • 复盘纪要：目标对比、渠道表现、问题、结论（续投/调整/停止）、待办（事项、唯一负责人、截止日）

6. 异常与升级

  • 审批 2 个工作日未处理 → 机器人提醒 → 再 1 个工作日未处理升级兜底人
  • 消耗速度明显偏离计划或获客成本远超目标 → 投放运营当天暂停或降量 → 当天通知业务负责人
  • 第三方发布内容出现合规问题 → 立即要求下架 → 当天通知业务负责人与法务
  • 代理商方案成本迟迟无法确定 → 业务负责人限期 3 个工作日补齐 → 否则不进入审批

7. 衡量指标

  • 审批周期 = 提交到审批完成的工作日，目标 ≤ 2 天
  • 周报按时率 = 每周一按时更新的周数 / 投放周数，目标 100%
  • 获客成本 = 投放消耗 / 新增获客数，按渠道对比，目标逐期下降
  • 复盘待办关闭率 = 按期关闭的待办 / 总待办，目标 ≥ 85%
  • 比价覆盖率 = 外部服务采购中有 2 家以上报价的比例，目标 100%

8. 低效诊断

  • 现象：预算申请在群里 @ 多人等批，无固定审批单（审批环节）｜依据：「跃竞市场决策」2026-07
  • 现象：复盘会待办在不同成员消息中重复整理，负责人出现两个版本（复盘环节）｜依据：「跃竞市场决策」2026-08
  • 现象：外部 KOC 服务商需临时找几家比价（采购环节）｜依据：「跃竞市场决策」2026-08
  • 现象：代理商方案成本未定，谁负责审核和敲定终版不明确（成本审核环节）｜依据：「新媒体leapcore代理（老杨）」2026-07

9. 分支变体

  • 跃竞广告投流：业务负责人提报，关联业务方会签，创始人兼 CTO 审批
  • KOC 小红书铺量：外部服务商比价 2～3 家，可考虑自建方案降低风险
  • 用户内容共创（免会费+奖金）：权益部分按 MKT-14 权益菜单
  • Leap 产品代理商自媒体推广方案：由产品总监与市场销售负责人审核成本后审批

10. 待确认问题

  • 跃竞与 Leap 的投放审批人是否不同？关联业务方是否必须参与审批？
  • 投放预算是否按金额分级审批？
  • 周报从 wiki 迁移到多维表格是否可行？
  • 外部服务商比价是否强制 2 家以上？
  • 代理商方案成本审核由产品还是市场销售负责？
MKT-16产品版本更新向市场/销售同步待优化72

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：新版本上线前或产品有可分享的新能力时，按“开发一版、预告一版、发布一版”向市场和销售同步新功能与 UI 变化，组织内部分享（脱敏），并准备可直接对外使用的材料
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、发版负责人（当前：宋祺睿·推断待确认）、内部分享主讲（当前：刘昱潇·推断待确认）、演示环境（当前：望政韬·推断待确认）、OPC/推文对接（当前：陈梦琪·推断待确认）、市场销售接收人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 版本规划时登记同步排期 → ② 发布前写市场版发布说明 → ③ 周一市场会预告并机器人提醒 → ④ 内测期准备售卖材料 → ⑤ 内部分享前脱敏与内容评审 → ⑥ 发布当天正式同步 → ⑦ 收集市场反馈 → ⑧ 对外推文经脱敏与口径审核
  • 交付结果：市场版发布说明（新功能、UI 变化、话术、截图/视频）、预告记录、售卖材料、脱敏后的分享回放、市场反馈记录
  • 状态依据：已有群内通知、上线视频和每周一市场会，但 2026-04～09 出现市场侧不知道要上新版本、产品与市场销售沟通“有壁垒”、内部分享讲法被技术人员认为没讲清价值、脱敏步骤临时想等问题

1. 场景判定

  • 触发条件：版本（如 V5、1.4、1.5）进入内测或确定发布日期；客户端 UI 有明显变化；产品有可对市场/销售/全员分享的新能力；有人想把内部分享包装成对外推文
  • 典型说法：「开发一版，预告一版，发布一版」「市场侧的人可能根本不知道要上新版本」「我现在和市场销售沟通有壁垒」「内部分享可能需要对涉密内容进行清洗」
  • 判断问题：这次变化会不会影响市场/销售对客户的说法或演示？是否需要他们提前准备？
  • 不归本流程管：更新日志编写与用户公告 → 请走 X-PRD-35；帮助中心与使用手册 → 请走 OPS-03；渠道培训赋能 → 请走 SAL-29；市场反馈汇总给产品 → 请走 MKT-17；对外口径与敏感词 → 请走 BRD-14；对外推文发布 → 请走 BRD-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品总监 登记同步排期、写市场版发布说明、组织预告与分享 R/A 产品总监（当前：杨萌·推断待确认）
研发负责人 提供功能清单、截图、可演示环境 C Leap 研发负责人（当前：王皓南·推断待确认）
发版负责人 确认发布日期与范围变化 C 后端/发版（当前：宋祺睿·推断待确认）
技术评审 审分享内容是否讲清价值、对外说法是否准确 C 创始人兼 CTO（当前：丁震宇·推断待确认）
分享主讲 内部业务分享讲解 R 销售（当前：刘昱潇·推断待确认）
演示环境 用非敏感数据部署分享用环境 R 基座研发负责人（当前：望政韬·推断待确认）
推文对接 内部分享转对外内容的需求方 I 生态组负责人（当前：陈梦琪·推断待确认）
市场销售接收人 接收预告、准备售卖材料、反馈 R 市场销售接收人（当前：待指定）

3. 办之前请准备

  • 版本范围与发布日期、功能清单、UI 变化截图
  • 对客户的影响：新增卖点、改变的操作、已知问题、不可对外的内容
  • 上线视频或演示录屏
  • 分享用演示环境（非敏感数据）
  • 市场版发布说明模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 版本规划确定后登记“市场同步排期”（预告日、发布日、分享日） 产品总监 版本排期确定当天 多维表格 / 飞书任务 同步排期 🔧飞书固化
2 编写市场版发布说明：新功能、UI 变化、客户影响、推荐话术、截图/视频、不可对外内容 产品总监 发布前 5 个工作日 飞书文档模板 市场版发布说明 🤖+👤
3 在周一市场会预告并发群公告；机器人在发布前 5 天、1 天提醒 产品总监 发布前最近一次周一市场会 飞书会议 / 机器人 预告记录 🔧+🤖
4 内测期准备售卖材料（演示脚本、功能卖点页），发布时可直接使用 市场销售接收人 发布前 2 个工作日 飞书云文档 售卖材料 👤人工判断
5 内部分享前完成脱敏（演示环境换非敏感数据）与内容评审（技术人员预审讲法） 演示环境、技术评审 分享前 2 个工作日 分享前清单 脱敏确认、评审意见 👤人工判断
6 举办内部分享并录制回放 分享主讲 按排期 飞书会议 分享回放 🔧飞书固化
7 发布当天同步正式说明与上线视频，更新售卖材料版本号 产品总监 发布当天 群公告 / 机器人 发布通知 🤖自动化
8 收集市场销售反馈（材料可用性、客户问题），转 MKT-17 市场销售接收人 发布后 5 个工作日内 反馈表单 反馈记录 🔧飞书固化

5. 交付物与模板

  • 交付物：市场同步排期、市场版发布说明、售卖材料、脱敏分享回放、反馈记录
  • 建议模板/表单：
    • 市场版发布说明：版本号、发布日期、新功能（一句话卖点）、UI 变化截图、客户影响、推荐话术、已知问题、不可对外内容、演示视频链接、联系人
    • 分享前清单：数据是否脱敏、客户名称是否隐去、演示环境是否独立、产品术语是否经技术评审、是否允许转对外内容、回放权限

6. 异常与升级

  • 发布日期变更 → 发版负责人当天通知产品总监 → 产品总监当天更新排期并告知市场
  • 市场版说明未按时出 → 机器人提醒 → 发布前 3 个工作日仍未出升级兜底人
  • 分享内容涉及客户或涉密数据 → 暂停分享，重新部署脱敏环境 → 当天告知技术评审
  • 内部分享被要求转对外推文 → 先过分享前清单与 BRD-14 口径审核 → 未通过不得发布

7. 衡量指标

  • 预告覆盖率 = 发布前完成预告的版本 / 发布版本，目标 100%
  • 说明提前量 = 市场版发布说明完成日到发布日的工作日，目标 ≥ 5 天
  • 市场知晓率 = 发布后抽查市场销售能说出主要新功能的比例，目标 ≥ 90%
  • 脱敏事故数 = 分享或推文中出现涉密数据的次数，目标 0

8. 低效诊断

  • 现象：大版本临近上线时市场侧仍不知情，需临时补材料（预告环节）｜依据：「Leap产研决策部」2026-08
  • 现象：产品与市场销售存在信息差，通知发出但被认为“无感”（同步方式环节）｜依据：「Leap产研决策部」2026-09
  • 现象：内部分享讲法偏“画饼”，技术人员认为未讲清价值（内容评审环节）｜依据：「跃迁基座项目交付沟通」2026-04
  • 现象：脱敏需求临时提出，需另起一套环境（脱敏环节）｜依据：「跃迁基座项目交付沟通」2026-04

9. 分支变体

  • 客户端 UI 变更：完整走市场版说明、预告、售卖材料更新
  • 底层网关等市场无感变更：仅在周一市场会简报，不准备售卖材料
  • 内部分享包装成对外推文：增加脱敏与口径审核，发布走 BRD-08
  • 鼎慧（GraphBase 等）与 Leap 产品线：分别由各线产品负责人执行

10. 待确认问题

  • 市场销售接收人由谁担任？是否固定在周一市场会同步？
  • 发布前 5 个工作日出市场版说明是否可行？
  • 本流程与 X-PRD-35（更新日志与迭代预告）是否合并或分工为“对内市场版 / 对外用户版”？
  • 内部分享是否必须技术人员预审？
  • 分享回放存放位置与可见范围如何定？
MKT-17市场产品反馈汇总交接待优化72

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险2

  • 适用场景：市场部在一个迭代周期内从客户、渠道、展会、演示、试用中收集到产品反馈，需要在产品排下一迭代前统一整理、交给产品负责人做优先级判断时启动
  • 负责人：主责——市场专员/销售运营（当前：韩诗琪·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/渠道对接人（当前：待指定）；兜底——生态市场条线负责人
  • 核心流程：① 日常登记反馈 → ② 迭代前截止汇总 → ③ 去重归类（AI 初分）→ ④ 市场负责人复核 → ⑤ 交接给产品 → ⑥ 产品逐条给结论并排期 → ⑦ 结论回告市场与反馈人
  • 交付结果：一份按固定模板整理、已去重归类的《产品反馈交接表》，以及产品对每条反馈的处理结论（纳入迭代/进需求池/不做及原因），并回告到原反馈渠道
  • 状态依据：已有《【市场部】产品反馈交接表》docx 交接做法，产品据此围绕预装需求排下一迭代；但表格格式不固定、质量不稳，交接当场即被追问“这表谁做的”并建议改用 AI 做表，属有做法但需固定模板与入口

1. 场景判定

  • 触发条件：产品下一迭代规划会前 3 个工作日（约两周一次）；或市场单周累计同类反馈 ≥ 3 条；或出现影响成交的共性反馈（如“太慢、太贵”、预装需求）需要尽快进入排期讨论
  • 典型说法：「这份反馈交接表你先过一眼」「下个迭代主要围绕预装需求排一下」「这表谁做的，可以让 AI 做」「客户普遍说太慢、太贵」
  • 判断问题：这批反馈是不是“市场侧收集、多条汇总、用于影响下一迭代优先级”的？如果是单个客户的线上故障或需要立即处理的问题，不走本流程
  • 不归本流程管：单个客户报 Bug/账号/计费问题 → 请走 X-CS-05；反馈群里的问题实时分流 → 请走 RND-01；单条需求的提报登记与需求池管理 → 请走 X-PRD-09；外部用户与销售反馈的通用回流规则 → 请走 X-PRD-07；迭代内部的工单拆分与估点 → 请走 RND-06；内部试用（dogfood）反馈 → 请走 X-PRD-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈整理人 日常登记、截止汇总、去重归类、填交接表 R 市场专员/销售运营（当前：韩诗琪·推断待确认）
市场复核人 交接前复核完整性、共性判断与优先级建议 A 生态市场条线负责人（当前：待指定）
反馈提供人 补充客户背景、场景、原话与截图 C 销售/渠道对接人（当前：待指定）
产品接收人 逐条给结论，决定纳入迭代或需求池 R 产品负责人（当前：杨萌·推断待确认）
研发评估人 评估可行性与工作量，参与迭代排期 C Leap 研发负责人（当前：王皓南·推断待确认）
销售团队 知悉处理结论，对客户统一口径 I 销售负责人（当前：待指定）

3. 办之前请准备

  • 本周期内所有反馈原始记录（客户群截图、演示/拜访纪要、试用反馈、渠道转述），每条注明来源渠道与日期
  • 每条反馈对应的客户类型（如某工程咨询客户、某地方政府客户）、产品线（LeapCore/LeapAll/字字可研等）与版本
  • 上一期交接表及产品给出的结论，用于查重与跟踪“已承诺未上线”项
  • 当前需求池链接，先查是否已有同类需求
  • 产品下一迭代规划会的时间，倒推交接截止日

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到客户/渠道反馈后按表单字段登记一条，不再散落在聊天和 docx 中 反馈提供人、反馈整理人 收到反馈后 1 个工作日内 飞书多维表格表单 反馈记录 🔧飞书固化
2 迭代规划会前 3 个工作日截止本期收集，机器人提醒补录 反馈整理人 规划会前 3 个工作日 飞书机器人 本期反馈清单 🔧飞书固化
3 AI 对本期反馈去重、归类（功能缺失/体验/性能/价格/部署预装/竞品对比），合并共性问题并统计提及客户数 反馈整理人 截止后 1 个工作日内 多维表格 AI 字段 / LeapCore 归类后的交接表初稿 🤖自动化
4 复核：删无效反馈、补缺字段、标出影响成交的共性问题和市场建议优先级 市场复核人 初稿后 1 个工作日内 多维表格 定稿交接表 👤人工判断
5 在产研群发交接表链接并@产品负责人，说明本期重点（≤3 条） 反馈整理人 规划会前 1 个工作日 飞书群 交接消息 🔧飞书固化
6 产品逐条填写结论：纳入本迭代/进需求池/不做（附原因），研发给出工作量评估 产品接收人、研发评估人 规划会结束后 1 个工作日内 多维表格 + 需求池 带结论的交接表 👤人工判断
7 纳入项同步进需求池并关联交接记录；结论回告市场和反馈提供人，由销售对客户统一答复 产品接收人、反馈整理人 结论后 2 个工作日内 需求池 / 飞书群 回告记录 🔧+🤖
8 版本上线后，把已上线的反馈项标记“已上线”并通知市场对外宣传或回访客户 产品接收人 发版后 2 个工作日内 多维表格 / 发版通知 闭环状态 🔧飞书固化

5. 交付物与模板

  • 交付物：《产品反馈交接表》（每期一份视图，非单独 docx）、产品结论、需求池关联记录、客户回告记录
  • 建议模板/表单（飞书多维表格“市场产品反馈库”）字段：反馈编号、提交日期、来源渠道（客户/渠道/展会/演示/试用）、客户类型、主体（模态/鼎慧/跃迁等）、产品线与版本、反馈原话、场景描述、截图/附件、反馈类型（功能/体验/性能/价格/部署预装/竞品）、提及客户数、对成交影响（高/中/低）、市场建议优先级、提交人、所属迭代期、产品结论（纳入迭代/需求池/不做）、不做原因、需求池链接、状态（待整理/已交接/已排期/已上线/已回告）、回告日期

6. 异常与升级

  • 交接表被产品退回（字段缺失、无原话、无法判断场景）→ 整理人 1 个工作日内补齐 → 二次退回升级生态市场条线负责人
  • 规划会前未交接 → 本期反馈顺延下一迭代，影响成交的高优反馈单独提报 → 当天告知产品负责人
  • 反馈中含紧急故障或客户投诉 → 立即转 X-CS-05，不等本流程汇总 → 同时告知销售负责人
  • 市场与产品对优先级分歧（如客户强烈要求但产品不做）→ 双方在规划会上说明依据 → 仍不一致在 2 个工作日内升级研发总负责人/CTO 拍板
  • 产品给出“纳入迭代”但连续 2 个迭代未上线 → 整理人在下期交接表中标红跟踪 → 升级产品负责人

7. 衡量指标

  • 交接按期率 = 在规划会前 1 个工作日完成交接的期数 / 总期数，目标 100%
  • 交接表一次通过率 = 产品未退回的期数 / 总期数，目标 ≥ 90%
  • 反馈结论覆盖率 = 已给出结论的反馈条数 / 交接反馈条数，目标 100%（规划会后 1 个工作日内）
  • 反馈闭环周期 = 反馈登记到回告反馈人的自然日，目标中位数 ≤ 14 天
  • 反馈采纳率 = 纳入迭代或需求池的条数 / 交接条数，用于观察反馈质量，不设硬目标

8. 低效诊断

  • 现象：交接表格式不固定、质量不稳，产品接收时当场质疑并要求重做（模板环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：反馈以 docx 文件形式流转，无法按客户/类型筛选，也无法与需求池关联（载体环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：去重归类靠人工逐条整理，“太慢、太贵”等共性反馈需产品二次汇总（归类环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：交接后产品结论未见回告市场的固定动作，市场无法向客户统一答复（闭环环节）｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 鼎慧/工程咨询线：反馈侧重预装需求、行业模板，交接对象为鼎慧产品负责人
  • 硬件/一体机相关反馈（配置、性能、价格）：同步抄送硬件选型负责人，按 X-PRD-24 处理
  • 渠道伙伴反馈：由渠道对接人登记，来源渠道选“渠道”，涉及渠道政策的部分转销售负责人

10. 待确认问题

  • 主责是否为市场专员/销售运营？“xj”具体指谁、是否为市场复核人？
  • 交接节奏是否与迭代（约两周）对齐？规划会前 3 个工作日截止是否可行？
  • 是否同意用多维表格表单替代 docx 交接表？是否与 X-PRD-07、X-PRD-09 的反馈库/需求池共用一张表，避免两套台账？
  • 产品给结论的时限（规划会后 1 个工作日）是否可行？由谁负责回告客户？
  • 本流程是否应并入 X-PRD-07 作为“市场渠道”分支，还是保留为独立交接 SOP？
MKT-18市场运营日报与沟通记录规范待优化90

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨5 × 险3

  • 适用场景：市场、运营、销售支持成员（含新入组成员与实习生）每个工作日下班前提交日报（部门群模板、多维表格或飞书汇报模块），为周例会和阶段复盘提供依据；以及市场条线与客户、渠道发生沟通（尤其在微信上）后，需要把关键信息沉淀到飞书/CRM 时启动
  • 负责人：主责——市场运营团队负责人（由鼎慧负责人/产品总监兼任，当前：杨萌·推断待确认）；协同——市场/运营/销售成员（当前：李宣昊、王满、吴琪、闫登辉、王皓南及运营实习生·推断待确认）、飞书与 AI 工具支持（当前：丁震宇、张东郅·推断待确认）；兜底——生态市场条线负责人；制度拍板——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发布日报规则与模板 → ② 当日沟通即时记入飞书/CRM → ③ 下班前按模板提交日报 → ④ 机器人截止前提醒、截止后汇总 → ⑤ 负责人次日上午回应协助项 → ⑥ 每周 AI 生成周报 → ⑦ 周会复盘 → ⑧ 月度抽查沟通记录完整性 → ⑨ 试行期满评估调整
  • 交付结果：每日结构化日报记录（今日完成/明日计划/需要协助）、AI 生成的周报、客户沟通关键内容在飞书/CRM 中可检索的记录、试行评估结论
  • 状态依据：日报机制自 2026-03 起在群内试行，03～04 月约 120 次稳定提交，执行稳定；但日报文本冗长、同一事项反复出现、日期标注与发布时间不一致；客户沟通仍大量在微信，仅有“尽量多用飞书沟通和记录”的口头要求，无转录机制，客户信息有流失风险

1. 场景判定

  • 触发条件：每个工作日 18:30 前（日报）；与客户/渠道在微信、电话、线下完成一次有实质内容的沟通（报价、需求、承诺、反馈、约见）后；新人（含实习生）加入市场运营群首日；日报机制启动或规则调整时
  • 典型说法：「简要记录完成的事项、明日计划和需要的协助」「不要有任何信息壁垒」「汇报工作尽可能少转述」「关键卡点还是微信」「让市场尽量多用飞书沟通和记东西」
  • 判断问题：这条信息是不是“市场运营成员的日常进展”或“需要让公司其他人/AI 能查到的客户沟通内容”？如果是正式拜访纪要，按 SAL-05 录入；商机变更按 SAL-04 录入
  • 不归本流程管：公司级 DailyWork 日报周报 → 请走 CEO-12；销售日报周报与保密分级 → 请走 SAL-32；研发日报 → 请走 RND-10；客户拜访与会议纪要 → 请走 SAL-05；CRM 客户/商机录入 → 请走 SAL-04；导出聊天记录做 AI 分析的授权 → 请走 X-SEC-35；项目进度与交付周报 → 请走 CEO-12；研发迭代站会 → 请走 RND-09；需要即时决策的问题 → 直接找负责人，不等日报

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
机制负责人 发布规则与模板、看日报、回应协助项、组织周复盘、抽查沟通记录、试行评估 A 市场运营团队负责人（由鼎慧负责人/产品总监兼任，当前：杨萌·推断待确认）
日报提交人 每日按模板提交日报；客户沟通当天转录到飞书/CRM R 市场/运营/销售成员（当前：李宣昊、王满、吴琪、闫登辉、王皓南及运营实习生·推断待确认）
新成员 入组首周观察学习，第 2 周起按模板提交 R 新入组的市场/运营成员（含实习生）
系统 截止前提醒、截止后汇总、周报草稿生成 R 飞书机器人/汇报模块（由飞书/系统支持配置）
飞书/系统支持 配置日报表单、机器人提醒、CRM 字段与权限 C 飞书管理员/CTO（当前：丁震宇·推断待确认）
AI 汇总支持 提供周报生成与沟通记录摘要的 AI 方案 C AI 工具支持（当前：张东郅·推断待确认）
制度拍板 定“信息不设壁垒、少转述”的原则与例外 A（升级） CEO（当前：邴龙志·推断待确认）
条线负责人 兜底督导、处理长期缺报 I 生态市场条线负责人

3. 办之前请准备

  • 日报模板（三段式：今日完成/明日计划/需要协助）及填写示例
  • 所在部门群或日报多维表格的链接与提交入口
  • 使用飞书汇报模块时：已建立“市场运营日报”固定模板（三个必填字段），汇报对象设为机制负责人，抄送范围已确定，并开启未提交提醒
  • 当日任务清单或待办（便于约 5 分钟内写完）
  • 本人负责的客户/渠道清单及其在 CRM 中的记录链接
  • 当日微信、电话沟通的要点（时间、对象类型、内容、承诺事项、下一步）
  • 保密分级：哪些内容不能在大群同步（涉密项单独报给负责人）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布日报规则：字段、提交截止时间、填写时长（约 5 分钟）、试行周期、汇报对象与抄送范围；规则文本一次定稿后再发布 机制负责人 机制启动当日；规则调整时当日 飞书群公告 / 飞书汇报模板 日报规则 🔧飞书固化
2 与客户/渠道在微信或电话有实质沟通后，把要点（含截图）转录到 CRM 跟进记录或飞书客户群/文档；能迁到飞书的客户群优先迁移 日报提交人 沟通当天下班前 CRM / 飞书 沟通记录 🔧+👤
3 按模板提交日报：今日完成（附链接）、明日计划、需要协助（写明需谁、何时前）、风险/卡点（选填）；日期以当天为准，持续事项只写当日增量 日报提交人 每个工作日 18:30 前 飞书多维表格表单 / 群内日报模板 / 飞书汇报 日报 🔧飞书固化
4 机器人在截止前 30 分钟（18:00）提醒未提交者；截止后汇总当日日报、列出缺报名单，把“需要协助”项单独推送给负责人 系统 每个工作日 18:00 提醒、18:30 汇总 飞书机器人 / 飞书汇报提醒 日报汇总、缺报提醒 🤖自动化
5 查看日报，对协助项逐条指派处理人或给出答复 机制负责人 次日 10:00 前 飞书群 / 多维表格 / 飞书汇报评论 协助项处理记录 👤人工判断
6 AI 基于一周日报和沟通记录生成周报草稿（完成、进展、风险、下周计划），本人确认；机制负责人据此出周汇总 系统、日报提交人 每周五 17:00 前（周汇总在例会前 1 个工作日） LeapCore / 多维表格 AI / 飞书汇报统计 周报、周汇总 🤖+👤
7 周会复盘：对照周报看延期事项、协助项闭环情况和客户跟进 机制负责人 每周例会 飞书会议 复盘结论与行动项 👤人工判断
8 新人入群首周：先观察学习群内日报，第 2 周起按模板提交 新成员 入群后第 2 周起 飞书群 日报 👤人工判断
9 每月抽查：随机抽取客户，核对 CRM/飞书记录是否覆盖实际沟通，通报缺口 机制负责人 每月第 1 周 CRM 报表 抽查结果 🔧+👤
10 试行期满评估：提交率、协助项解决率、成员反馈，决定保留/调整字段或转为正式机制 机制负责人 试行开始后 4 周内 周例会 评估结论 👤人工判断

5. 交付物与模板

  • 交付物：日报规则、每日日报记录、日报汇总与缺报清单、AI 周报与周汇总、客户沟通记录、月度抽查结果、试行评估结论
  • 建议模板/表单：
    • 日报表单字段：日期（自动取当天）、提交人、条线（市场/运营/销售支持）、今日完成（每条附文档或链接）、明日计划、需要协助（事项、需谁、期望时间）、风险/卡点（选填）、涉及客户（关联 CRM）、是否含涉密内容
    • 周汇总字段：本周完成重点、未完成及原因、跨团队协助需求、下周重点
    • 客户沟通记录字段：沟通日期、渠道（微信/电话/线下/飞书）、客户（关联 CRM）、对接人岗位、沟通要点、客户原话或截图、我方承诺、下一步及时间、记录人

6. 异常与升级

  • 当日未提交日报 → 机器人 18:00 截止前提醒，次日 10:00 前补交 → 连续 2 个工作日未交由机制负责人当面了解，连续 3 个工作日未交升级条线负责人
  • 成员请假/外出 → 当天免填，在日报或汇报中注明请假 → 不计入缺报
  • 日报流于形式（连续多日内容重复、无具体产出） → 机制负责人在周会提出 → 试行评估或月度复盘时调整字段
  • 涉及制度原则或例外（信息公开范围、是否改用 DailyWork 统一提交、哪些内容不进大群） → 决定权由机制负责人升级至 CEO 拍板 → 机制负责人在下次管理层例会前提请
  • 协助项 2 个工作日无人响应 → 提交人在日报中标“仍需协助”并@负责人 → 3 个工作日仍未处理升级条线负责人
  • 内容涉密不宜在群内同步 → 日报中只写“涉密事项一项，已单独报负责人” → 按 SAL-32 保密分级处理
  • 客户只接受微信沟通 → 保留微信沟通，但关键内容当天转录 → 月度抽查发现漏记 ≥ 2 次，由负责人当面纠正并通报
  • 客户投诉或承诺事项变更在微信中发生 → 当天转录并同步销售负责人 → 影响合同或交付时 1 个工作日内升级条线负责人

7. 衡量指标

  • 日报按时提交率 = 18:30 前提交人次 / 应提交人次，目标 ≥ 95%
  • 协助项闭环率 = 2 个工作日内有响应的协助项 / 全部协助项，目标 ≥ 90%
  • 客户沟通入库率 = 抽查客户中 CRM/飞书有当期沟通记录的比例，目标 ≥ 90%
  • 日报重复率 = 与前一日内容完全重复的条目占比，目标 ≤ 10%
  • 周报生成耗时 = 本人确认 AI 草稿的时间，目标 ≤ 15 分钟
  • 协助项响应时效 = 日报提交到负责人回复，目标次日 10:00 前
  • 日报填写耗时 = 成员自评单次填写时间，目标约 5 分钟；周汇总准备时长目标 ≤ 30 分钟

8. 低效诊断

  • 现象：日报为自由文本，篇幅冗长，同一持续事项每天重复出现，阅读和汇总成本高（日报格式环节）｜依据：「字字可研市场运营」2026-03、「字字可研市场运营」2026-04
  • 现象：日报标注日期与实际发布时间不一致，事后按日期回溯困难（提交环节）｜依据：「字字可研市场运营」2026-03、「字字可研市场运营」2026-04
  • 现象：汇报中存在多层转述，信息失真，需反复强调“少转述、不设信息壁垒”（同步环节）｜依据：「字字可研市场运营」2026-03
  • 现象：公司内部沟通大部分已在飞书，但市场客户沟通仍以微信为主，内容无法进入 AI 上下文与 CRM，只有口头要求、无转录机制（沟通记录环节）｜依据：「跃迁AI总动员」2026-08
  • 现象：周报需人工从日报中二次整理（汇总环节）｜依据：「字字可研市场运营」2026-04
  • 现象：日报规则文本（填写时长、截止时间）未统一定稿，试行期缺少评估时间点与提交率统计，执行力度依赖负责人个人跟进（规则与评估环节）｜依据：（推断）

9. 分支变体

  • 运营日报：侧重新媒体发布、数据与活动进展，可附平台数据截图
  • 市场日报：侧重客户/渠道沟通、物料与活动筹备，“涉及客户”字段必填并关联 CRM
  • 销售成员参与时：日报格式与 SAL-32 保持一致，商机推进写入 CRM 而非只写在日报中
  • 跨主体（模态/鼎慧/跃迁）成员：日报中注明所属主体与产品线，便于分线汇总
  • 飞书汇报模块版：用汇报模块固定模板提交，汇报对象为机制负责人，模块自带未提交提醒与统计，周汇总可直接取模块统计
  • 已合并原 OPS-27（市场运营日报机制）：其规则发布、截止前提醒、请假免填、试行期满评估等内容已并入本条

10. 待确认问题

  • 机制负责人是否为市场运营负责人？运营负责人人选待确认，与报送口径是否一致？
  • 本 SOP 已合并原 OPS-27，归口由运营转为市场条线；是否再作为 CEO-12（DailyWork）的分支变体？市场运营是否改用 DailyWork 统一提交？请管理层裁定
  • 日报截止统一为 18:30、机器人 18:00 提醒是否可行？（原 OPS-27 写的是 19:00 截止、18:30 提醒，需统一）
  • 试行期多长？是否已评估并转为正式机制？
  • 填写人范围是否包含销售或兼任运营的业务专家？日报与周汇总是否同步给运营负责人或管理层？
  • 日报载体用群内模板、多维表格还是飞书汇报模块？是否已建立固定模板并开启未提交提醒？
  • 微信客户沟通是“当天转录”还是“只转录报价、承诺、需求变更等关键内容”？转录到 CRM 还是飞书文档？
  • 是否推动重点客户沟通迁移到飞书外部群？对只用微信的客户是否接受例外？
  • 月度抽查由谁执行？未入库的后果如何处理？
MKT-19市场年度计划、预算编制与费用执行跟踪待新建推断144

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：每年末编制下一年度市场计划与预算，季度分解滚动，并按月跟踪市场费用执行时启动
  • 负责人：主责——市场经理（当前：待指定）；协同——品牌、研究院生态、销售负责人（当前：待指定）、财务（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）
  • 核心流程：① 收集目标 → ② 编制市场日历与预算 → ③ CEO 审批 → ④ 季度分解 → ⑤ 活动按预算立项占用 → ⑥ 月度执行台账 → ⑦ 超预算审批 → ⑧ 季度投入产出复盘
  • 交付结果：经审批的年度市场计划与预算、月度费用执行台账、季度投入产出复盘
  • 状态依据：已有 MKT-02（发布会预算审批）、MKT-15（推广投放预算审批）、FIN-09（活动费用预算与归集）覆盖单项预算环节，本条补齐条线级年度市场计划、预算总盘与月度执行跟踪（推断）

1. 场景判定

  • 触发条件：年末规划；季度初；单项活动提出费用申请；月末费用核对
  • 典型说法：「今年市场能花多少钱」「这个展会在不在预算里」
  • 判断问题：是条线级总计划/总预算，还是单场活动？单场活动走对应 SOP，本流程管总盘子
  • 不归本流程管：单场发布会立项 → 请走 MKT-02；投放预算与效果 → 请走 MKT-15；单场活动费用报预算、垫付与归集 → 请走 FIN-09；生态活动日历与取舍 → 请走 ECO-01（其预算纳入本流程汇总）；公司级年度预算编制 → 请走 FIN-43（本流程结果作为市场条线输入）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
市场经理 汇总编制、执行台账、复盘 R 市场经理（当前：待指定）
生态市场条线负责人 审核、季度调整、预算外审批 A 生态市场条线负责人（当前：许君·部门报送人）
品牌/研究院生态/销售 提报各自计划与预算 C 各子职能负责人（当前：待指定）
活动负责人 单项活动立项时注明占用预算 R 活动负责人（当前：待指定）
财务 预算口径、费用对账 C 财务专员（当前：待指定）
CEO 年度预算审批、重大偏差裁定 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 公司年度目标（CEO-01）、产品发布节奏
  • 上年度市场费用实际与线索/转化数据
  • 已知展会、大会、培训班日程

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 向各子职能/产品线收集目标与活动计划 市场经理 每年 12 月第 1 周 飞书表单 计划汇总 🔧飞书固化
2 编制年度市场日历与预算（按主体/产品线/活动类型） 市场经理 12 月第 2 周 多维表格 预算草案 🤖+👤
3 条线负责人审核后报 CEO 审批 条线负责人 12 月第 3 周 飞书审批 年度预算 🔧飞书固化
4 季度分解，按实际滚动调整 市场经理 每季度首周 多维表格 季度预算 👤人工判断
5 单项活动立项时注明占用预算科目 活动负责人 立项时 飞书审批 预算占用 🔧飞书固化
6 与财务核对当月实际支出，更新执行台账 市场经理 每月 10 日前 多维表格 执行台账 🤖自动化
7 预算外或超预算事项单独审批 条线负责人 支出前 飞书审批 审批记录 🔧飞书固化
8 季度复盘投入产出（线索数、转化、品牌曝光） 市场经理 季度结束后 10 个工作日内 飞书文档 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：年度市场计划与预算、月度执行台账、季度复盘
  • 建议模板/表单：预算台账（科目、主体、产品线、活动、预算、已占用、已支出、余额、线索数、负责人）

6. 异常与升级

  • 单季度执行偏差超出预算一定比例（比例待确认）→ 条线负责人说明原因并报 CEO
  • 临时重大活动无预算 → 走预算外审批，2 个工作日内答复
  • 升级条件：年度市场预算定稿、单季度偏差超出预警比例、预算外支出超出条线审批权限 → CEO 作为 A（升级）审批；其余调整由生态市场条线负责人审批

7. 衡量指标

  • 预算执行偏差率 = |实际 − 预算| / 预算，按季度统计，目标控制在约定范围内
  • 单线索获取成本 = 季度市场费用 / 有效线索数

8. 低效诊断

  • 聊天中未见相关流程，存在活动临时起意、费用超支无人知晓、投入产出无法评估的风险（推断）

9. 分支变体

  • 子公司/关联主体的市场费用分别编制，跨主体活动按 FIN-32 分摊

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 市场预算由条线统一管还是各子职能各自管？
  • 偏差率预警阈值定多少？
MKT-20市场活动与线索个人信息收集使用合规待新建推断160

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨4 × 险5

  • 适用场景：活动报名表、问卷、培训班报名、展会扫码、名片、线索名单、短信/电话邀约，以及把名单共享给渠道、外包或合作方时启动
  • 负责人：主责——市场经理（当前：待指定）；协同——法务专员（当前：待指定）、安全/IT 管理员（当前：待指定）、研究院生态与销售对接人（当前：待指定）；兜底——生态市场条线负责人（当前：许君·部门报送人）
  • 核心流程：① 表单告知同意 → ② 最小必要收集 → ③ 公司工具存储与权限 → ④ 合规使用（邀约/营销） → ⑤ 对外共享审批 → ⑥ 到期删除 → ⑦ 撤回与投诉处理 → ⑧ 年度自查
  • 交付结果：法务审定的报名/问卷模板、个人信息名单登记台账、共享审批与删除记录
  • 状态依据：已有 MKT-07（活动后线索录入与分配）、LEG-21（营销短信与推广内容合规审核）覆盖部分环节，本条补齐活动报名与线索个人信息的收集告知、共享审批与到期删除（推断）

1. 场景判定

  • 触发条件：新建任何收集姓名、手机号、单位、职务、身份证、学历等信息的表单；导出或转发名单
  • 典型说法：「报名表加个身份证号吧」「把名单发给外包打电话」「这批手机号能不能发营销短信」
  • 判断问题：是否收集或传递了可识别到个人的信息？是则走本流程
  • 不归本流程管：线索录入、分配跟进与转化复盘 → 请走 MKT-07；产品用户的个人信息权利请求与账号注销 → 请走 OPS-29；营销短信文案审核 → 请走 LEG-21；飞书数据批量导出授权 → 请走 X-SEC-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动/表单负责人 按模板建表、管理名单 R 活动负责人（当前：待指定）
市场经理 名单登记、共享与删除把关 A 市场经理（当前：待指定）
法务 告知同意模板、共享协议 C 法务专员（当前：待指定）
安全/IT 管理员 权限设置、导出控制 C 安全/IT 管理员（当前：待指定）

3. 办之前请准备

  • 法务审定的告知同意文本（目的、范围、保存期限、联系方式、是否共享）
  • 本次活动确实需要的字段清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用标准模板建表，含告知同意勾选 活动负责人 发布前 飞书问卷/多维表格 合规表单 🔧飞书固化
2 删除非必要字段（身份证等仅在法定或场馆要求时收集） 市场经理 发布前 1 个工作日 检查清单 字段确认 👤人工判断
3 名单存公司空间，限定可见人员，禁止个人网盘/个人微信传表 活动负责人 收集期间 飞书权限 权限设置 🔧飞书固化
4 邀约与营销仅限已同意人员，短信/电话提供退订方式 活动负责人 发送前 短信平台 发送记录 🤖自动化
5 向渠道/外包/合作方共享须审批并签数据处理条款 市场经理+法务 共享前 2 个工作日 飞书审批 共享审批 🔧飞书固化
6 活动结束后按保存期限删除或匿名化，转为线索的进 CRM 活动负责人 到期后 5 个工作日内 多维表格 删除记录 🤖自动化（到期提醒）
7 个人要求删除/退订/投诉，按时处理并留痕 市场经理 收到后 15 个工作日内 飞书表单 处理记录 🔧飞书固化
8 年度自查名单台账与在用表单 市场经理 每年 12 月 台账 自查报告 👤人工判断

5. 交付物与模板

  • 交付物：标准报名/问卷模板、名单登记台账、共享与删除记录
  • 建议模板/表单：名单台账（活动、字段、收集人数、存放位置、可见人员、保存期限、是否共享、删除日期）

6. 异常与升级

  • 名单误发外部群或外泄 → 立即撤回 → 报安全管理员与法务（1 小时内），按 X-SEC-11 处置
  • 外包未按约定删除 → 法务发函要求删除并取得书面确认

7. 衡量指标

  • 表单模板使用率 = 使用标准模板的表单 / 收集个人信息的表单，目标 100%
  • 到期删除完成率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在报名名单在个人微信与外包间流转、超范围收集、未经同意发营销信息导致投诉或监管处罚的风险（推断）

9. 分支变体

  • 政府合作培训班：名单可能需报送主管部门，须在告知中写明；涉及在校学生按高校要求处理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 活动名单默认保存期限定多久？
  • 外包电话邀约是否已有数据处理协议？

SAL 销售

报送人：许君、李鹏为 · 销售 · 38 条 · 已有 0 / 待优化 20 / 待新建 18
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
SAL-01主动获客（社群/短视频/私域/冷邮件）销售/获客人员每天在抖音、小红书、kook、B站、公众号、微信私域或海外邮件上主动联系目标客户，要把联系结果变成可跟进的线索并约到演示时启动主责——获客专员（当前：刘安达·推断待确认）；协同——线索工具研发（当前：张楠、魏小东·推断待确认）、内容/商户运营（当前：宫经喜·推断待确认）、商机跟进销售（当前：待指定）、法务负责人（当前：待指定）；兜底——跃竞业务线负责人（当前：徐莉·推断待确认）① 定目标客群与渠道配额 → ② 养号与内容触达 → ③ 线索工具抓取+AI 二筛 → ④ 私信/加微信建联 → ⑤ 线索当日入库分级 → ⑥ 预约演示 → ⑦ 演示后 24 小时内填反馈 → ⑧ 日报按漏斗口径汇报与周复盘线索库中带来源、阶段、下次跟进时间的有效线索；已完成的演示记录与反馈；按漏斗口径（触达→建联→有效线索→演示→入驻/成交）统计的获客日报待优化225
SAL-02入站线索接入、背调与分发认领官网预约演示/定价页申请、陌生来电、公众号咨询、介绍人引荐、布道分享后的政企听众、高管转来的客户资源、外部转介绍与培训班名单等“对方找上门”的线索出现，需要登记、甄别、分给唯一销售并首次联系时启动主责——线索中台管理员（当前：许君·推断待确认）；协同——线索分发专员（当前：侯明月·推断待确认）、销售负责人（当前：李鹏为·推断待确认，认领规则与复盘）、各销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）、CTO（当前：丁震宇·推断待确认，技术类线索分派）、跃竞负责人（当前：徐莉·推断待确认，跃竞官网线索）、官网线索机器人研发（当前：张楠·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 各入口线索统一登记进线索池 → ② 机器人推送卡片 → ③ 甄别背调（真客户/渠道/推销/测试）→ ④ 分级 P0～P2 → ⑤ 认领或指派唯一负责人 → ⑥ 12 小时内首次联系 → ⑦ 跟进记录入 CRM → ⑧ 超时回收与 P0 未转化复盘线索池中每条入站线索都有来源、甄别结论、等级、唯一负责销售、首次联系时间和跟进记录；每周线索盘点与 P0 未转化复盘待优化180
SAL-03商机甄别、可行性初筛与赢丢单复盘新商机或外部需求（标准 B 端项目、伙伴转介客户、熟人介绍的 Demo/MVP 小单、外部培训、外部技术撮合）出现，在投入方案、报价、研发之前判断“能不能做、值不值得做、谁来做”；商机赢单、丢单或卡住后做复盘主责——销售负责人（当前：李鹏为·推断待确认）；协同——商机负责销售（当前：闫登辉、吴琪、刘昱潇、时建、杜中瑞·推断待确认）、CTO（当前：丁震宇·推断待确认，技术可行性与优先级）、FDE Leader（当前：黄振锋·推断待确认，技术信息收集）、CEO（当前：邴龙志·推断待确认，战略取舍）、法务/财务负责人（当前：待指定，外部小单合同与收款）；兜底——CEO（当前：邴龙志·推断待确认）① CRM 登记商机与需求原文 → ② 发客户信息收集清单 → ③ 五项甄别（预算/决策链/时间/标品匹配/竞争）→ ④ 技术可行性与定制比例评估 → ⑤ 分级 A/B/C 并决定跟进、放弃或转介 → ⑥ 立项推进或礼貌退出 → ⑦ 赢丢单复盘与月度规则更新CRM 中每个商机带评估结论（等级、是否立项、理由、审批人）；已填的客户信息收集清单；赢丢单复盘记录与月度复盘结论待新建320
SAL-04CRM 客户/商机录入与维护出现新客户、线索、商机、合同或渠道，每次拜访/沟通之后，每周周报之前，台账缺失需要补录，CRM 切换过渡期，新人要开 CRM 账号，或试用客户充值需要登记时主责——CRM 管理员（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，口径与督办）、销售台账维护（当前：汪家诺·推断待确认）、CRM 研发（当前：郭逸非·推断待确认）、CRM 部署（当前：杨睿·推断待确认）、系统管理员（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认，绩效挂钩规则）、各销售（录入）；兜底——销售负责人（当前：李鹏为·推断待确认）① 开通账号与角色 → ② 企查查全称查重 → ③ 线索进公海池、商机按规范命名 → ④ 每次沟通后 24 小时内记跟进 → ⑤ 赢单上传合同并生成订单 → ⑥ 每周五机器人查缺补漏 → ⑦ 每月与合同台账、回款核对 → ⑧ 考核只取 CRM 数据CRM 中客户唯一、负责人唯一、商机阶段与金额准确、跟进记录完整、合同与订单可关联；每周未更新清单；每月数据质量报告待优化180
SAL-05客户拜访与会议纪要记录、信息同步与客户、渠道、合作方或政府单位完成拜访、会议、饭局、展会交流，或需求/验收/售后沟通之后，需要把结论、承诺、下一步留痕并同步给内部相关人时启动主责——商机负责销售（当前：吴琪、时建、杜中瑞、陈名赞·推断待确认）；协同——销售运营（当前：韩诗琪·推断待确认，纪要汇总表维护）、重大项目总负责人（当前：时建·推断待确认）、生态市场总监（当前：许君·推断待确认，汇总表口径）、产品负责人（当前：杨萌·推断待确认，客户信息表）、CTO（当前：丁震宇·推断待确认，客户沟通留痕规则）、CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 建日程时定记录人并默认录制 → ② 会中录制/妙记 → ③ 会后 24 小时内发纪要（3～5 句结论+承诺+下一步）→ ④ 写入 CRM 跟进与客户档案 → ⑤ 下一步转飞书任务 → ⑥ 同步销售群或项目群 → ⑦ 每周汇总与回访统一模板的会议纪要、CRM 跟进记录、客户档案（售后文档）更新、带负责人和截止日期的待办、每周纪要汇总表待优化120
SAL-06重点商机上报与大客户分级推进销售发现客户有强烈购买意向，或商机金额较大、客户为集团/国企/政府/行业头部等战略客户，需要上报、分级、拉齐公司资源，并按节点推进到签约时启动主责——销售负责人（当前：李鹏为·推断待确认）；协同——项目负责销售（当前：闫登辉、刘昱潇、吴琪、杨朋伟、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，方案审核与产品/定价判断）、COO（当前：常元和·推断待确认，统一口径与 CRM 督促）、产品负责人（当前：杨萌·推断待确认，需求对齐与 Demo）、CEO（当前：邴龙志·推断待确认，资源决策）；兜底——CEO（当前：邴龙志·推断待确认）① 填表上报重点商机 → ② 分级 A/B/C → ③ 项目启动会（目标、分工、里程碑、口径、价格边界）→ ④ 需求对齐 → ⑤ Demo/方案并审核 → ⑥ 报价与合同 → ⑦ 每周更新看板、周会汇报 → ⑧ 卡点升级 → ⑨ 签约转交付或丢单复盘重点项目看板（阶段、下一步、卡点、需支持人）、启动会纪要与分工、每周进展、签约合同或明确的放弃结论待优化300
SAL-07政企客户需求对接与方案汇报政府部门（科创、科技、公安等）或国企、国有金融机构提出 AI 建设需求、邀请我方汇报，或客户内部上会需要我方提供支撑材料时启动主责——销售负责人（当前：李鹏为·推断待确认）；协同——政企跟进销售（当前：闫登辉、杨朋伟、刘昱潇·推断待确认）、技术方案负责人（当前：王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认，方案评审与口径）、CEO（当前：邴龙志·推断待确认，客户关系与需求）、COO（当前：常元和·推断待确认，统筹与跟进人安排）、FDE/Skill 方案（当前：李凯·推断待确认）、法务负责人（当前：待指定，密级与合规）；兜底——CEO（当前：邴龙志·推断待确认）① 接需求/邀约建任务卡 → ② 摸底（对象角色、密级、部署、经费、算力、时间）→ ③ 定主讲与陪同 → ④ 出方案/白皮书（通俗版+技术附录）→ ⑤ 内部一次性评审 → ⑥ 出发前清单核对与拜访汇报 → ⑦ 会后复盘、报价、跟进 → ⑧ 支撑客户内部上会评审政企客户档案、需求摸底清单、方案/白皮书定稿（含纸质版）、汇报纪要与复盘、客户上会支撑材料（数据分级分类规范、模型选型论证等）、礼品接待审批记录待新建375
SAL-08客户/渠道/合作方来访交流准备与会后复盘客户、渠道商、生态方或合作意向公司来访、线上交流或邀我方上门洽谈（含带技术问题清单来访、套壳/集成合作洽谈），需要会前统一口径和材料、定出席人与技术同席、会后纪要与复盘时启动主责——来访对接人（销售/商务）（当前：时建、闫登辉、杨朋伟·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，判断来意、指派出席人与口径分工）、生态组负责人（产品口径，当前：陈梦琪·推断待确认）、IT 运维（信创/算力口径，当前：杨明学·推断待确认）、技术同席（当前：李铭熙、郭逸非、吴亚军·推断待确认）、会议组织（当前：杨萌·推断待确认）、COO（当前：常元和·推断待确认，高职级出席）；兜底——销售负责人（当前：李鹏为·推断待确认）① 填来访信息卡 → ② 判断来意与披露级别 → ③ 定出席人与 AB 角、发日程（默认录制）→ ④ 会前口径卡与精简讲解/演示 → ⑤ 会前 30 分钟提醒 → ⑥ 会中录制、不当场承诺 → ⑦ 纪要与统一书面答复 → ⑧ 复盘并转跟进来访信息卡、会前口径卡、出席安排（含 AB 角）、会议纪要、对方问题的统一书面答复、复盘清单与跟进任务待新建135
SAL-09售前技术支撑与技术问题统一答复销售接待客户或去客户现场需要技术人员同席、演示视频/案例/资质材料，或客户、渠道在售前阶段集中提出技术问题（含私有化、二次开发、源码、海外交付）时启动主责——售前技术负责人（当前：丁震宇·推断待确认）；协同——销售对接人（当前：闫登辉、杜中瑞·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、技术同席人员/研发（当前：王皓南、宋祺睿·推断待确认）、材料持有人（当前：刘昱潇、李凯·推断待确认）、法务（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 销售提交售前支撑申请 → ② 判断客户意图与支撑方式 → ③ 排班派人/从资料库取材料 → ④ 客户问题整理成文档 → ⑤ 1 个工作日内出统一书面答复 → ⑥ 敏感口径会审 → ⑦ 答复入 FAQ 库写入日历的技术同席安排、发给客户的标准化技术答复文档、更新后的售前资料库与 FAQ 条目待优化144
SAL-10对外沟通口径统一与对客通知审核客户问部署能力、服务可用性、数据安全、Agent 架构、竞品对比、价格与性能承诺，或与硬件/渠道伙伴做商务沟通，或项目侧准备向客户发布使用政策/通知时，按统一口径答复，对客通知先内部审核主责——对外口径库负责人/产品总监（当前：杨萌·推断待确认）；协同——价格与合同口径归口：市场销售负责人（当前：李鹏为·推断待确认）、硬件口径归口：IT/硬件负责人（当前：杨明学·推断待确认）、技术事实确认：Leap 研发负责人（当前：王皓南·推断待确认）、一线使用人：COO 及销售（当前：常元和、吴琪、刘昱潇、闫登辉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别对外口径问题 → ② 查口径库 → ③ 无现成口径向归口人申请 → ④ 归口人起草（AI 辅助）→ ⑤ 审定后发布入库 → ⑥ 一线按口径对外 → ⑦ 对客通知走内部审核 → ⑧ 冲突复盘并更新分领域的对外口径库（产品/技术/安全、价格/合同、硬件、故障安抚、竞品对比）、经审核的对客通知、口径冲突复盘记录待新建225
SAL-11客户演示准备与执行客户、渠道、政府/评审机构、领导或资本方要看产品演示（现场或远程）时，从接到演示需求到演示后反馈收集全程按本流程走主责——演示统筹人/产品总监（当前：杨萌·推断待确认）；协同——演示申请人/销售及 COO（当前：闫登辉、吴琪、常元和·推断待确认）、技术保障（当前：王皓南、宋祺睿·推断待确认）、测试验证（当前：张东郅·推断待确认）、演示视频制作（当前：杨黔昆·推断待确认）、演示账号安排（当前：李凯·推断待确认）、场景案例梳理（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交演示申请 → ② 定演示人、操作人、技术保障 → ③ 选场景写脚本 → ④ 环境、账号、额度就绪（SAL-12/13）→ ⑤ 按脚本内部预演并录兜底视频 → ⑥ 现场演示 → ⑦ 1 个工作日内登记反馈并复盘演示申请记录、演示脚本与话术、兜底录屏、演示反馈登记（转需求/商机跟进）待优化500
SAL-12演示环境与版本保障（冻结/稳定版/兜底）已确定对外演示（客户现场、远程、发布会、云栖类大会、资本方）后，指定演示环境与稳定版本、在演示窗口冻结更新、准备备用机与网络兜底，演示失败时排查复盘主责——演示环境负责人/产品总监（当前：杨萌·推断待确认）；协同——研发发版负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、客户端与 hotfix（当前：岳阳、马漳毓·推断待确认）、测试（当前：张东郅·推断待确认）、演示机管理（当前：游家豪·推断待确认）、IT 网络与备机（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 演示登记入演示日历 → ② 指定专用演示机/稳定版 → ③ 冻结窗口生效、发版避让 → ④ 推送已知问题与禁用功能 → ⑤ 演示前冒烟检查 → ⑥ 兜底就绪（录屏、备用机、随身网络）→ ⑦ 演示中故障应急 → ⑧ 解冻与复盘演示日历与冻结记录、演示前冒烟检查结果、已知问题清单、兜底包（视频/备用机/网络）、演示事故复盘待新建256
SAL-13演示账号与演示机管理销售、市场、渠道需要演示账号、演示额度/积分券、Demo 访问权限，或借用演示机/样机给客户演示试看时，按申请→分配→登记→回收管理，不暴露管理权限主责——演示资源管理员（当前：闫登辉·推断待确认）；协同——对外演示产品清单维护：产品总监（当前：杨萌·推断待确认）、演示机硬件与在线状态：运维/交付部署工程师（当前：游家豪·推断待确认）、备机与内网接入：IT 运维（当前：杨明学·推断待确认）、演示页/后台账号：后端/运维（当前：宋祺睿·推断待确认）、演示站维护：基座研发负责人（当前：望政韬·推断待确认）、Demo 能否公开确认：苏州销售负责人（当前：刘昱潇·推断待确认）、积分券管理（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交借用/开通申请 → ② 审核用途与权限级别 → ③ 从账号池/演示机台账分配（演示角色，不给管理员）→ ④ 凭据经安全渠道私发并登记 → ⑤ 额度/券按标准发放登记 → ⑥ 到期回收、改密、重置数据 → ⑦ 每月盘点台账演示账号池与演示机台账（编号、持有人、版本、额度、在线状态、借用记录）、对外演示产品清单（可对外/仅内部/需脱敏）待新建144
SAL-14售前 Demo/样稿制作与客户需求转产研意向客户要定制 Demo、接口集成演示、竞品 PK 样稿，或销售需要产研配合做售前交付物时，经统一入口（先找产品）提交，评估后优先复用已有能力，限期交付主责——售前需求入口/产品总监（当前：杨萌·推断待确认）；协同——售前需求方（当前：侯明月、刘昱潇·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Demo 开发/FDE（当前：邓乾·推断待确认）、研发侧技术需求收口人（当前：李铭熙·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、行业能力负责人（当前：白立新·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交售前需求单 → ② 产品 1 个工作日内分诊 → ③ Demo 立项（范围、必备客户材料、交付日）→ ④ 优先复用 Demo 台账与行业工作流 → ⑤ 开发/生成 → ⑥ 内部验收与录屏 → ⑦ 交付客户并收集反馈 → ⑧ 入 Demo 台账已交付的 Demo/样稿（含录屏与说明）、Demo 台账条目、转入正式需求池的需求或拒绝说明待新建144
SAL-15销售物料、标杆案例与知识库建设新品发布、对外材料变更、演示或竞品对比成功产生案例、赢单产生标杆、行业版搭建市场体系，或销售规则/合同模板/渠道协议/价格更新时，把话术、演示场景、竞品对比、案例、行业作战包和规则模板沉淀到销售知识库并保持唯一最新版主责——生态市场总监（当前：许君·推断待确认）；协同——渠道/知识库与白皮书维护（当前：闫登辉·推断待确认）、演示视频合集与技能清单：产品总监（当前：杨萌·推断待确认）、CRM 赢单数据：销售运营（当前：韩诗琪·推断待确认）、行业版负责人（当前：吴琪、杨朋伟、闫登辉·推断待确认）、场景案例：业务专家（当前：王满·推断待确认）、案例认证积分（当前：丁震宇·推断待确认）、体系要求与验收：CEO（当前：邴龙志·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 识别更新事件 → ② 素材提交（案例/话术/视频/客户问题/规则）→ ③ 归口人整理、脱敏与审核 → ④ 发布到知识库“最新版”目录并标版本 → ⑤ 通知群推送并置顶 → ⑥ 销售培训与抽查 → ⑦ 每月清理旧版分类清晰、版本唯一的销售知识库（话术/FAQ、演示场景库与视频合集、竞品对比、标杆案例集、行业版作战包、规则/模板/价格）及更新记录待优化144
SAL-16客户/渠道试用申请审批、开通与转化跟进客户或渠道要求先试用再购买（线上额度试用、演示机带用、样机部署、繁星计划等政府推荐企业试用、渠道试用账号）时，从判断给不给、给多少并审批，到开通、跟进反馈、回访转化或回收主责——试用审批人/市场销售负责人（当前：李鹏为·推断待确认）；协同——试用开通与充值事务：销售运营（当前：韩诗琪·推断待确认）、繁星计划台账：渠道负责人（当前：闫登辉·推断待确认）、带用部署与培训：销售（当前：杜中瑞、陈名赞、吴琪·推断待确认）、部署与演示机：产品总监与 IT 运维（当前：杨萌、杨明学·推断待确认）、使用报告监督（当前：许君·推断待确认）、教育线试用账号开通（当前：陈梦琪·推断待确认）、技术答复（当前：岳阳、宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 现场不承诺，回公司提交试用申请 → ② 按试用档位审批 → ③ 开通账号/额度或安排带用/部署 → ④ 登记试用台账 → ⑤ 带用培训并收集反馈 → ⑥ 半个月内出使用报告 → ⑦ 到期转化或回收 → ⑧ 输单复盘经审批的试用记录、试用台账（客户、档位、额度、期限、阶段、消耗、反馈）、客户使用报告、转化结果（充值/签约）或回收记录待新建240
SAL-17赠送额度、借机与特殊商务行为报备留痕销售、产品或渠道打算给客户、合作伙伴、种子用户赠送额度或设备、借出设备、提供超出标准口径的免费试用，或员工自费购买公司产品时，先报备审批，再在合同、后台、账务三处留痕主责——市场销售负责人（当前：李鹏为·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交特殊商务申请 → ② 产品核定成本与口径 → ③ 市场销售负责人审批（超档位 CEO 加签）→ ④ 审批通过后出库/发放 → ⑤ 后台备注与合同/协议留痕 → ⑥ 财务入账 → ⑦ 到期回收或转化跟进带审批编号的特殊商务申请单；对应的赠送/借用协议或个人采购合同；后台额度备注；财务可对账的赠送台账待新建96
SAL-18产品定价与价格体系管理新产品、新模型、新套餐、新硬件机型上市，或成本、渠道政策变化需要调价时，统一测算成本、倍率、毛利与渠道分成，经审批后发布“内部总表 + 对外价格表”两套版本主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——COO（当前：常元和·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 定价需求登记 → ② 汇总成本（模型折扣/硬件/人力）→ ③ 用定价测算表算倍率、毛利、分成 → ④ 内部评审 → ⑤ 管理层审批 → ⑥ 发布内部总表与对外价格表 → ⑦ 同步销售、渠道与系统配置 → ⑧ 每月复核带版本号的定价测算表、内部价格总表（含成本列，限定可见范围）、对外价格表（不含成本与折扣）、价格变更通知、系统价格配置记录待优化320
SAL-19客户方案与报价单编制审核客户询价、扩容或提出项目制需求时，由销售先完成需求调研，再编制方案书、报价单和内部成本测算表，经技术复核和分级审批后，只发出一版客户版报价主责——客户对接销售（当前：按商机归属，如闫登辉、刘昱潇、吴琪·推断待确认）；协同——FDE Leader（当前：黄振锋·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、产品总监（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 需求调研与报价登记 → ② 方案范围冻结 → ③ 分块估算（软件人日/硬件/模型用量/运维）→ ④ 用报价 Skill/模板生成方案书、报价单、成本测算表 → ⑤ 技术复核 → ⑥ 按毛利分级审批 → ⑦ 生成唯一客户版 PDF 发出 → ⑧ 登记台账并跟进反馈审批通过的客户版报价单（PDF，唯一版本）、方案书、内部成本测算表、报价台账记录待优化500
SAL-20硬件/算力配置评估、询价与报价客户提出并发、模型、预算、席位或服务器定制需求时，由技术评估配置与容量（必要时压测），IT 和渠道询价得出 BOM 成本，商务再加软件与词元价，形成带有效期的对外硬件报价主责——IT 运维/硬件负责人（当前：杨明学·推断待确认）；协同——销售骨干/商务报价（当前：闫登辉·推断待确认）、各需求销售（当前：刘昱潇、时建、陈名赞·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交硬件评估需求单 → ② IT 出配置方案（软件侧评估并发/上下文）→ ③ 容量存疑时压测 → ④ 客户确认配置 → ⑤ 询价出 BOM 成本 → ⑥ CTO 复核成本与配置 → ⑦ 商务按系数加软件与词元价 → ⑧ 财务、法务审核后发客户（注明有效期）配置清单、BOM 成本表、（必要时）压测/容量评估结论、带有效期的硬件报价单待优化240
SAL-21定制/非标需求评估、报价与特批签约前或签约后，客户在标品之外提出定制需求（换 Logo/去商标、定制 skill、接入指定模型或自有算力、API 适配、行业版开发、多机登录等）时，先判定是否非标，研发只报人天，销售定价，特批通过并签（追加）合同、收到首付款后才排期主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、COO（当前：常元和·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 销售提交非标需求受理单 → ② 产品判定标品/已有版本/非标 → ③ 研发评估人天与工期 → ④ 销售定服务价 → ⑤ 特批（占用研发多的 CTO 加签）→ ⑥ 签合同或追加合同、收首付款 → ⑦ 进入研发排期 → ⑧ 交付验收非标需求受理单（含判定结论、人天、价格、审批）、服务说明、（追加）合同、研发排期记录待新建144
SAL-22招投标与供应商入库国企、政府客户采购需要走招投标、供应商入库、竞争性报价，或合作方邀请联合投标时，统一登记、评审合规性，从标准资质包取材料，分工编制标书和报价/技术响应表，交叉审核后按期提交主责——投标负责人（当前：闫登辉·推断待确认）；协同——项目商务负责人（当前：刘昱潇·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、法务负责人（当前：李瑶·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 登记招标/入库信息与截止时间 → ② 投标可行性与合规评审 → ③ 拆分任务（商务、技术、报价、资质、演示）→ ④ 调取标准资质包 → ⑤ 编制标书与响应表 → ⑥ 交叉审核 → ⑦ 用印、封装、提交 → ⑧ 结果登记与复盘按期提交的投标文件/入库材料、投标台账记录、标准资质包（持续更新）、开标结果与复盘待新建375
SAL-23销售合同起草、条款谈判与用印客户进入商务合同阶段时，销售按模板起草（含保密协议、三方签约、合同拆分），组织交付可行性与风险会签，与客户谈条款，红线条款升级，定稿后用印签署并通知交付与财务主责——合同起草销售（当前：按商机归属，如吴琪、闫登辉、杨朋伟、刘昱潇·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、销售运营（当前：韩诗琪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 选现行模板起草 → ② 填写交付规格（引用标准套餐和规格文档）→ ③ 内部会签（市场销售负责人、交付可行性、法务、财务）→ ④ 对客谈判并记录条款修改 → ⑤ 红线条款升级 → ⑥ 定稿 → ⑦ 用印签署 → ⑧ 归档、CRM 上传，通知交付与财务双方签署的合同（及保密协议、补充协议）、会签记录、条款修改记录，并完成 CRM 上传和交付、财务通知待优化400
SAL-24收款条件、赢单登记与回款跟踪签约前要确认收款条件（默认先款后货，不赊账、不货到付款）；合同签署或赢单后，销售在 CRM 上传合同、关联商机、标记赢单、登记回款计划，财务确认到账后再通知交付主责——商机归属销售（当前：按商机归属，如杨朋伟、杜中瑞、吴琪、刘昱潇·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：郭逸非、陈子康·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 签约前确认收款条件 → ② 例外情况特批 → ③ 签署后 CRM 上传合同并关联商机 → ④ 标记赢单 → ⑤ 登记回款计划 → ⑥ 财务确认到账 → ⑦ 到账后通知交付/发货 → ⑧ 逾期催收升级CRM 中状态为“赢单”的商机（含合同附件或收款凭证）、回款计划与到账记录、到账后发出的交付通知待优化72
SAL-25合同范围外需求拦截与客户预期管理已签约或已出方案的客户提出合同、方案书、报价单里没有的新需求（新功能、二开接口、外部系统对接、资质协助、专属界面、人数或资源超出方案档位等）时启动。主责——客户归属销售（当前：吴琪、刘昱潇·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO/客户关系（当前：常元和·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT/现场交付（当前：杨明学·推断待确认）；兜底——销售负责人① 一线不当场承诺 → ② 1 个工作日内登记需求变更单 → ③ 对照合同/方案书判定范围 → ④ 分流（拒绝/通用功能排期/转定制报价/免费有限支持审批）→ ⑤ 书面答复客户 → ⑥ 承诺归档到 CRM每条范围外需求对应一张已判定、已书面答复客户的《需求变更单》（含结论、费用口径、排期、对客承诺原文），挂在该客户的 CRM 记录下。待新建180
SAL-26API/额度类分销订单（API 转售、卡密、第三方商城）外部客户或分销平台要购买公司的模型 API 或产品额度（API 转售、发卡平台卡密、第三方商城上架）时启动，覆盖报价、收款、开通、交付和对账。主责——API 分销商务负责人（当前：丁震宇·推断待确认）；协同——网关与计费研发（当前：王皓南·推断待确认）、运维部署（当前：宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、商城对接产品经理（当前：黄飞鹏·推断待确认）、财务（当前：待指定）；兜底——销售负责人① 询单登记 → ② 资质与转售合规核查 → ③ 按价格表报价审批 → ④ 先收款 → ⑤ 上游充值 → ⑥ 网关开号限额/生成卡密 → ⑦ 交付 key 与文档 → ⑧ 用量监控与月度对账入账一笔已收款、已开通、已对账的分销订单：订单台账记录、网关 key（含额度与并发上限）或卡密批次、对客交付文档、对账单与入账记录。待新建300
SAL-27渠道伙伴开发、授权政策与协议签署出现有代理/经销意向的伙伴（硬件厂商、运营商、云平台、集成商、个人或机构）时启动，从准入评估、政策洽谈、授权等级到协议定稿签约。主责——渠道负责人（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，政策与等级审定）、渠道销售（当前：吴琪、杜中瑞、时建、陈名赞、朱文瑜、刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）、生态市场总监（当前：许君·推断待确认）、产品总监（当前：杨萌·推断待确认）、CEO（当前：邴龙志·推断待确认，分润与合资类决策）；兜底——销售负责人① 渠道线索登记 → ② 准入评估 → ③ 洽谈分工与政策 → ④ 等级与非标条款审定 → ⑤ 按现行模板拟协议 → ⑥ 法务审查 → ⑦ 用印签署 → ⑧ 台账登记、系统开户、转培训已签署的渠道代理协议（引用当前启用模板版本和产品清单），渠道台账记录，渠道系统账号，进入培训陪跑的渠道名单。待优化400
SAL-28渠道非标合作（预装/贴牌/联合开发）承诺审批渠道或客户提出 OEM 预装、贴牌、联合开发、专属额度发放、分润等标准渠道政策以外的合作时启动，先汇总需求、产研评估，审批后统一对外承诺。主责——渠道对接销售（当前：时建·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、COO/市场销售（当前：常元和·推断待确认）、生态市场总监（当前：许君·推断待确认）；兜底——销售负责人① 不口头承诺，登记非标合作申请 → ② 核实已有承诺与协议状态 → ③ 产研评估指标与排期 → ④ 商务评估价格分润 → ⑤ 审批 → ⑥ 签协议/补充条款 → ⑦ 指定唯一口径人对外答复 → ⑧ 按对接清单实施并跟踪里程碑一份已审批的《非标合作申请单》（含产研评估、商务条件、对外承诺原文）、签署的合作协议或补充条款、进入任务看板的实施里程碑。待新建200
SAL-29渠道与销售产品培训赋能渠道签约后需要让渠道会讲、会卖、跑出首单，或产品新版本/新功能上线、销售与渠道反复问同类问题时启动。主责——渠道负责人（当前：闫登辉·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，新功能培训组织与回放归档）、研发讲师（当前：吴世豪·推断待确认）、销售负责人（当前：李鹏为·推断待确认，策略与考核）、渠道销售（当前：陈名赞、杜中瑞、吴琪、朱文瑜、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，对客话术）、生态市场总监（当前：许君·推断待确认，渠道物料）；兜底——销售负责人① 触发登记到培训台账 → ② 定讲师与材料 → ③ 发培训通知 → ④ 授课 → ⑤ 回放与文档归档 → ⑥ 小测与补课 → ⑦ 渠道陪跑首单 → ⑧ 重复问题回收更新 FAQ培训台账记录、课件/课程文档、录屏回放（知识库固定位置）、FAQ 与对客话术、测验结果；渠道侧还有首单陪跑记录。待优化135
SAL-30渠道体系管理（台账、分级评级、分润与推荐费结算）渠道签约后，需要维护签约台账、划分等级、定期评级、管理中间人与个人推荐，以及按规则核算分润和推荐费时启动。主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，体系设计与分润决策）、渠道负责人（当前：闫登辉·推断待确认）、生态市场总监（当前：许君·推断待确认，渠道手册与知识库）、商务（当前：杨朋伟、杜中瑞·推断待确认，承接推荐客户）、财务（当前：待指定）、法务负责人（当前：待指定）；兜底——CEO① 签约渠道入台账 → ② 定等级 → ③ 推荐线索登记与归属 → ④ 成单后按规则表核算分润/推荐费 → ⑤ 结算审批 → ⑥ 财务打款 → ⑦ 季度评级与违规处理 → ⑧ 制度与手册更新发布渠道台账（唯一数据源、随时可导出签约渠道清单）、渠道等级与季度评级结果、分润/推荐费结算单、现行渠道管理制度与渠道销售手册。待优化180
SAL-31渠道报备→订单→交付（渠道系统）渠道（含按渠道处理的内部直销主体）发现客户或项目，需要在渠道系统报备商机、提交订单、走到 IT 交付、充值、验收、开票时启动。主责——订单与交付统筹（当前：杨萌·推断待确认）；协同——渠道系统负责人（当前：丁震宇·推断待确认）、渠道系统开发（当前：陈子康·推断待确认）、商务审核（当前：闫登辉、吴琪·推断待确认）、IT 交付（当前：游家豪、杨明学·推断待确认）、软件部署（当前：宋祺睿、杨云峰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——销售负责人① 渠道报备客户/项目 → ② 商务审核进入保护期 → ③ 带合同发起订单 → ④ IT 配置预审、渠道确认 → ⑤ 商务审核订单 → ⑥ 财务确认收款 → ⑦ 硬件准备、软件部署、充值开通 → ⑧ 上传验收单关闭订单 → ⑨ 开票渠道系统中一条已关闭的订单：报备记录、五类合同材料、IT 预审单、收款确认、部署与充值记录、验收单、发票记录；渠道销量与充值看板随之更新。待优化500
SAL-32销售日报周报与汇报保密销售每周（特定时期每天）向部门报送工作汇报，管理层据此复盘商机；月底为人事提供考勤工作记录；汇报或群聊涉及客户内部信息、机密信息时按保密分级选择沟通渠道。主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认，信息分级与 CRM 权限）、销售运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）、全体销售（当前：杜中瑞、闫登辉、时建、吴琪、杨朋伟、陈名赞、朱文瑜、汪家诺·推断待确认）；兜底——CEO① 周五按统一模板填周报 → ② 同步更新 CRM 商机 → ③ 机器人提醒未交者 → ④ 汇总生成部门周报 → ⑤ 周五部门例会复盘 → ⑥ 月底导出考勤依据 → ⑦ 机密内容按分级走受限渠道每人每周一份按项目/渠道分标题的周报（多维表格记录）、部门周汇总、CRM 商机阶段同步、月度考勤工作记录；机密信息只在 CRM 受限字段或直属上级处留存。待优化90
SAL-33商机与客户归属分配制度出现新商机、多个销售争抢同一客户，或渠道直签/已出货客户没有对接销售时，按统一规则指定唯一归属销售主责——销售负责人（当前：李鹏为·推断待确认）；协同——渠道负责人（当前：闫登辉·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、产品总监/交付统筹（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 登记无主/争议商机 → ② CRM 查重 → ③ 按规则指定归属销售 → ④ 归属销售确认接收并首联 → ⑤ 争议裁决 → ⑥ 周简报公示 → ⑦ 月度回收超期商机重分配每个商机/订单在 CRM 中有且仅有一个归属销售，分配记录可查，激励按归属与订单类型计入待优化180
SAL-34销售业绩考核与提成核算每月/每季度以 CRM 数据对销售做 KPI 考核与档位结算，计算提成奖励；新制定或调整销售奖励政策，或产品成本变动影响奖励兑现时主责——销售负责人（当前：李鹏为·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、销售 KPI 数据整理（当前：汪家诺·推断待确认）、财务专员（当前：待指定）、HR（当前：待指定）、采购/成本核对（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 周期前定稿考核口径 → ② 奖励政策成本核对 → ③ 月末 CRM 数据截止 → ④ 系统自动计分+主管人工评分 → ⑤ 公示与申诉 → ⑥ 导出复核 → ⑦ 提成核算审批 → ⑧ 交财务发放归档经复核的月度 KPI 结果表、季度档位排名表、提成奖励核算表（审批通过并交财务），以及带版本号和生效日的奖励政策文档待优化192
SAL-35销售人员离岗客户与商机交接销售/渠道经理离职、调岗、长期休假或客户归属调整时，把其名下客户、商机、合同、回款与对客承诺完整移交给接手人并告知客户主责——销售负责人（当前：待指定）；协同——离岗销售、接手销售、HR 专员、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 离岗/调整确认 → ② CRM 导出名下客户与商机清单 → ③ 指定接手人 → ④ 逐客户交接（商机阶段、合同、回款、承诺、关键联系人）→ ⑤ 联合告知客户 → ⑥ CRM 归属变更 → ⑦ 30 天跟踪复核双方确认的客户交接清单；CRM 归属已变更；客户已收到对接人变更通知待新建96
SAL-36销售合同变更、终止与退换货处理已签销售合同需要变更（数量、配置、交付时间、付款条件）、客户要求解除合同、退货/换货或退款时，统一评估、审批并完成合同、账务与交付侧闭环主责——销售负责人（当前：待指定）；协同——客户对接销售、法务、财务专员、交付负责人（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 受理客户书面请求 → ② 影响评估（成本、库存、已交付部分）→ ③ 方案与报价 → ④ 法务/财务会审 → ⑤ 审批 → ⑥ 签补充协议/解除协议 → ⑦ 退换货与退款/红冲 → ⑧ CRM 与台账更新签署的补充协议或解除协议；完成的退换货、退款或红冲；更新后的合同台账与 CRM待新建200
SAL-37商务招待、礼品与反商业贿赂合规销售、市场、FDE 在对接客户（尤其政府、国企、事业单位）时发生宴请、礼品、差旅邀请、样机赠送、中间人推荐费等商务往来，事前判断是否合规并审批留痕主责——销售负责人（当前：待指定）；协同——法务专员、财务专员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 识别商务往来类型 → ② 对照红线清单 → ③ 事前申请 → ④ 审批 → ⑤ 执行并留存凭证 → ⑥ 报销时核对 → ⑦ 季度抽查经审批的招待/礼品记录；合规的报销凭证；季度抽查结论待新建90
SAL-38销售目标分解、商机预测与月度 Pipeline 复盘每季度/每月把销售目标分解到人与产品线，并基于 CRM 商机做成交预测，输出给交付备货、财务资金计划与管理层主责——销售负责人（当前：待指定）；协同——各销售、交付负责人、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）① 季度目标分解到人 → ② 月末商机阶段更新 → ③ 生成预测表（承诺/可能/机会三档）→ ④ Pipeline 复盘会 → ⑤ 输出备货与资金预测 → ⑥ 月度偏差复盘季度目标分解表；月度销售预测表；复盘会纪要与行动项；给交付的硬件需求预测待新建144
SAL-01主动获客（社群/短视频/私域/冷邮件）待优化225

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频5 × 耗3 × 跨5 × 险3

  • 适用场景：销售/获客人员每天在抖音、小红书、kook、B站、公众号、微信私域或海外邮件上主动联系目标客户，要把联系结果变成可跟进的线索并约到演示时启动
  • 负责人：主责——获客专员（当前：刘安达·推断待确认）；协同——线索工具研发（当前：张楠、魏小东·推断待确认）、内容/商户运营（当前：宫经喜·推断待确认）、商机跟进销售（当前：待指定）、法务负责人（当前：待指定）；兜底——跃竞业务线负责人（当前：徐莉·推断待确认）
  • 核心流程：① 定目标客群与渠道配额 → ② 养号与内容触达 → ③ 线索工具抓取+AI 二筛 → ④ 私信/加微信建联 → ⑤ 线索当日入库分级 → ⑥ 预约演示 → ⑦ 演示后 24 小时内填反馈 → ⑧ 日报按漏斗口径汇报与周复盘
  • 交付结果：线索库中带来源、阶段、下次跟进时间的有效线索；已完成的演示记录与反馈；按漏斗口径（触达→建联→有效线索→演示→入驻/成交）统计的获客日报
  • 状态依据：跃竞 2026-06～10 每天在多个平台获客并发日报（约 110 次），做法固定；但日报只报“加了多少人”，口径不一、看不到转化漏斗，没有统一线索台账（CRM 2026-07 底才开始搭），演示反馈要负责人追问

1. 场景判定

  • 触发条件：每个工作日的例行获客；新产品/新功能（线索工具、俱乐部会员系统等）开始推广；海外 2B 产品启动冷邮件触达
  • 典型说法：「kook获客（78人）、公众号获客（13人）」「获客（添加俱乐部店长微信6个）」「今天客户演示的反馈怎么样？」「可以一起分担企业关键人邮箱的发掘和验证费用」
  • 判断问题：这条线索是我方主动找来的吗？如果是对方主动提交表单、来电、转介绍或活动后找来的，属于入站线索
  • 不归本流程管：官网表单、来电、转介绍等入站线索 → 请走 SAL-02；展会/沙龙后的线索 → 请走 MKT-07；判断商机值不值得投入 → 请走 SAL-03；批量私信、买号、IP 池是否合规 → 请走 LEG-22；投流预算 → 请走 MKT-15；内容选题与发布 → 请走 OPS-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
获客执行 养号、触达、建联、录线索、约演示、填日报 R 获客专员（当前：刘安达·推断待确认）
目标与复盘 定渠道配额、追演示反馈、周复盘调整打法 A 跃竞业务线负责人（当前：徐莉·推断待确认）
线索工具 评论抓取、AI 二筛、高意向名单推送 R 线索工具研发（当前：张楠、魏小东·推断待确认）
内容与投放 获客图文/视频、投放、入驻材料 C 内容/商户运营（当前：宫经喜·推断待确认）
演示与成交 高意向客户演示、报价、成交 R 商机跟进销售（当前：待指定）
合规把关 批量触达频率、邮箱数据来源合规 C 法务负责人（当前：待指定）

3. 办之前请准备

  • 目标客群画像（如电竞俱乐部/工作室店长、出海 2B 企业决策人）和本周各渠道配额
  • 各平台运营账号清单（登记在 OPS-26 台账）和养号规则
  • 标准话术、产品一页纸、演示视频（如俱乐部入驻演示视频）、网页版使用教程
  • 线索库（多维表格或 CRM 线索公海池）字段与录入权限
  • 演示预约日历和可用演示环境（见 SAL-12）
  • 冷邮件专用：名单来源说明、退订方式、发信域名与预热状态

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定本周目标客群、各渠道配额与话术重点 业务线负责人 每周一 12:00 前 多维表格 周获客计划 👤人工判断
2 养号，发布获客图文/短视频/帖子 获客专员、内容运营 每个工作日 抖音/小红书/B站/公众号 获客内容 🔧+🤖（AI 出文案初稿）
3 用线索工具抓取评论与潜在客户，AI 二筛出高意向名单 获客专员 每日 11:00 前 线索工具 高意向名单 🤖自动化
4 私信/加微信建联，按话术介绍，记录对方规模与核心问题 获客专员 当日 平台私信、微信 建联记录 👤人工判断
5 有回应的客户录入线索库：来源渠道、联系人、规模、需求、意向等级、下次跟进时间 获客专员 建联当日下班前 多维表格/CRM 线索记录 🔧飞书固化
6 有意向的预约演示并发日程 获客专员或跟进销售 意向确认后 2 个工作日内完成演示 飞书日程 演示预约 🔧飞书固化
7 演示后填反馈表（关注点、异议、下一步、意向等级 A/B/C） 演示人 演示后 24 小时内 飞书表单 演示反馈 🔧飞书固化
8 A 级线索转给商机跟进销售，按 SAL-04 录入 CRM 获客专员 评级后 1 个工作日内 CRM 商机 🔧飞书固化
9 按漏斗口径提交日报，机器人自动汇总 获客专员 每日 21:00 前 日报表单、机器人 漏斗日报 🔧+🤖
10 复盘各渠道转化率，调整下周配额与话术 业务线负责人 每周五 线索库看板 周复盘结论 👤人工判断

5. 交付物与模板

  • 交付物：线索库记录、演示反馈、漏斗日报、周复盘结论
  • 建议模板/表单：
    • 线索库：线索编号、来源平台、来源方式（评论抓取/私信/社群/邮件/电话回访）、客户名称、联系人、联系方式、规模、核心问题、意向等级、阶段（新建/已建联/已演示/入驻中/成交/放弃）、负责人、下次跟进时间、放弃原因
    • 演示反馈表：日期、客户、演示人、演示内容、客户关注点、异议、下一步、意向等级
    • 漏斗日报：日期、渠道、触达数、建联数、有效线索数、演示数、入驻/成交数、备注

6. 异常与升级

  • 平台限流或封号 → 停止该账号的批量动作，改人工触达 → 当天报业务线负责人；涉及合规的 2 个工作日内转法务负责人
  • 线索工具抓取异常或二筛误判 → 留存样例 → 1 个工作日内提给线索工具研发
  • 同一客户被多人触达 → 以先录入线索库者为准 → 有争议转 SAL-33，业务线负责人 1 个工作日内裁定
  • 演示后 24 小时未填反馈 → 机器人提醒 → 48 小时仍未填，业务线负责人追问
  • 冷邮件退信率超过 5% 或收到投诉 → 暂停发送、清洗名单 → 当天报法务负责人

7. 衡量指标

  • 有效线索数：每周新增、通过二筛且已建联的线索数，目标由周计划设定
  • 建联→有效线索转化率 = 有效线索数 / 建联数，按渠道统计
  • 演示转化率 = 完成演示数 / 有效线索数，目标 ≥ 20%（待确认）
  • 演示反馈及时率 = 24 小时内填写的反馈数 / 演示数，目标 ≥ 95%
  • 线索录入完整率 = 必填字段齐全的线索数 / 线索总数，目标 ≥ 90%
  • 冷邮件：退信率 ≤ 3%，回复率 ≥ 3%

8. 低效诊断

  • 现象：日报只报加了多少人，私信、触达、转化口径各不相同，看不出哪个渠道有效（汇报环节缺漏斗口径）｜依据：「跃玩项目组」2026-07、「跃玩项目组」2026-08
  • 现象：演示后反馈不主动回传，需负责人在群里追问（演示后环节缺反馈表）｜依据：「跃玩项目组」2026-07
  • 现象：没有统一线索台账，客户名单到 10 月仍在“收集”（录入环节缺载体）｜依据：「跃玩项目组」2026-07、「跃玩项目组」2026-10
  • 现象：加微信、养号、私信每天全手工重复（触达环节自动化不足）｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09
  • 现象：演示、入驻推进、培训多人交叉负责，客户不清楚找谁（交接环节无唯一负责人）｜依据：「跃玩项目组」2026-09

9. 分支变体

  • 跃玩/星域俱乐部店长获客：小红书/抖音找店长 → 加微信 → 演示 → 入驻推进；确定入驻后转 X-CS-22 / X-DLV-38
  • 线索工具（SaaS）销售：用自家线索工具获客，同时作为产品演示
  • 出海 2B 冷邮件（目前公司内未见实践，仅有外部做法参考）：销售导航类工具找决策人 → 邮箱发掘工具取邮箱 → 邮箱验证工具二次校验 → 邮件预热/群发工具发送；可与外部团队拼单分摊数据费用，但发送账号不共享；启动前须法务确认个人信息与反垃圾邮件合规
  • 模态主体（LeapCore/LeapAll）：聊天中未见成体系的主动获客，如启动按本流程执行

10. 待确认问题

  • 主动获客主责是否为跃竞获客专员？模态主体是否需要单设获客岗？
  • 线索库用跃竞 CRM 工作台，还是统一迁入跃迁 CRM 线索公海池？
  • 意向确认后 2 个工作日内完成演示、24 小时内填反馈是否可行？
  • 意向等级 A/B/C 的判定标准由谁定？
  • 线索工具批量私信/关注的频率上限，法务是否已有结论？
  • 出海冷邮件是否立项？数据工具采购是否走 FIN-02？
SAL-02入站线索接入、背调与分发认领待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：官网预约演示/定价页申请、陌生来电、公众号咨询、介绍人引荐、布道分享后的政企听众、高管转来的客户资源、外部转介绍与培训班名单等“对方找上门”的线索出现，需要登记、甄别、分给唯一销售并首次联系时启动
  • 负责人：主责——线索中台管理员（当前：许君·推断待确认）；协同——线索分发专员（当前：侯明月·推断待确认）、销售负责人（当前：李鹏为·推断待确认，认领规则与复盘）、各销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）、CTO（当前：丁震宇·推断待确认，技术类线索分派）、跃竞负责人（当前：徐莉·推断待确认，跃竞官网线索）、官网线索机器人研发（当前：张楠·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 各入口线索统一登记进线索池 → ② 机器人推送卡片 → ③ 甄别背调（真客户/渠道/推销/测试）→ ④ 分级 P0～P2 → ⑤ 认领或指派唯一负责人 → ⑥ 12 小时内首次联系 → ⑦ 跟进记录入 CRM → ⑧ 超时回收与 P0 未转化复盘
  • 交付结果：线索池中每条入站线索都有来源、甄别结论、等级、唯一负责销售、首次联系时间和跟进记录；每周线索盘点与 P0 未转化复盘
  • 状态依据：跃竞官网表单已接飞书机器人卡片，2026-08 定下“12 小时内首次触达、意向客户 2～3 天跟进一次”；但模态侧线索仍靠群里转发、各自认领后私下要上下文，2026-08 提出“建立线索中台”，到 2026-10 仍有“客户资源没人跟进”；布道后的政企线索只在群里口头传

1. 场景判定

  • 触发条件：官网表单提交（预约演示/定价页申请/免费开通）；陌生电话、公众号留言、介绍人引荐；布道、分享、培训后听众表达兴趣；高管转来客户资源；外部转介绍与培训班学员名单
  • 典型说法：「这是官网来咨询的」「现在应该有一个人给这些人打电话」「这种自动找上来的成单概率应该比较大」「信息中心那边想要这个，快派人去」「大家看完各自认领」「我们的客户资源没人跟进后续」
  • 判断问题：线索是对方主动找来或第三方转来的吗？在 CRM 按企查查全称查一下，是否已有销售在跟？
  • 不归本流程管：我方主动获客 → 请走 SAL-01；展会/沙龙等活动后的批量线索 → 请走 MKT-07；外部公司谈合作、政府提培训方案需求 → 请走 MKT-12；归属争议与撞单 → 请走 SAL-33；判断值不值得做 → 请走 SAL-03；外部讲课邀约 → 请走 MKT-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
线索池与规则 维护线索中台、统一入口、每周盘点超时线索 R 线索中台管理员（当前：许君·推断待确认）
接收人 收到来电、公众号、介绍人、活动、高管资源等入站线索后填表登记 R 全员（接收线索的任何人）
分发执行 登记、甄别背调、分级、推送认领卡片 R 线索分发专员（当前：侯明月·推断待确认）
认领规则与复盘 定认领顺序、指派 P0、组织 P0 未转化复盘，分发结果最终拍板 A 销售负责人（当前：李鹏为·推断待确认）
负责销售 认领后首次联系、背调、录 CRM、持续跟进 R 各销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）
技术类线索 指派技术同席，给出泄密等顾虑的口径 C CTO（当前：丁震宇·推断待确认）
线索提供 转线索并补充背景 I CEO（当前：邴龙志·推断待确认）、布道讲师（当前：李子遥·推断待确认）
官网机器人 表单写入线索池、卡片推送、测试来源隔离 R 研发（当前：张楠·推断待确认）
跃竞线索 跃竞官网线索跟进标准与执行 R 跃竞负责人（当前：徐莉·推断待确认）

3. 办之前请准备

  • 线索中台（多维表格或 CRM 线索公海池）的访问与编辑权限
  • 统一线索登记表单和活动现场二维码
  • 甄别清单：企查查全称、是否同行/推销/渠道、规模、决策人、预算线索
  • 首次联系话术（官网咨询、来电、政企听众“想用不敢用/担心泄密”的回应口径）
  • 当前销售名单与手上商机数（用于判断谁不饱和）
  • 线索转出人对客户背景的文字说明（不要私聊口述）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有入口线索登记进线索池：官网表单自动写入；来电、公众号、介绍人、活动、高管资源由接收人填表单 接收人/机器人 收到后 2 个工作小时内 官网 webhook、飞书表单、多维表格 线索记录 🔧飞书固化
2 机器人推送线索卡片到销售群，测试来源打标签、不推送 机器人 实时 飞书机器人 线索卡片 🤖自动化
3 甄别背调：企查查核主体、CRM 查重、判定真实客户/渠道/推销/测试 线索分发专员 登记后 4 个工作小时内 企查查、CRM 甄别结论 🤖+👤（AI 预判，人工确认）
4 分级：P0（有明确预算/决策人，或政企主动要部署）、P1（需求明确）、P2（了解咨询） 线索分发专员，P0 由销售负责人确认 与第 3 步同时 线索池 线索等级 👤人工判断
5 已有归属的直接派原负责人；无归属的发认领卡片，手上不饱和的销售优先；P0 由销售负责人指派；技术顾虑类同时 @CTO 指派技术同席 线索分发专员、销售负责人 推送后 4 个工作小时无人认领即指派 机器人认领卡片 唯一负责人 🔧飞书固化
6 首次联系：确认需求、规模、决策链，回答首要顾虑（如数据泄密 → 私有化方案） 负责销售 获取线索后 12 小时内 电话、微信 首次联系记录 👤人工判断
7 首次联系结果写入 CRM；需求明确的转 SAL-03 甄别 负责销售 联系当日 CRM 跟进记录 🔧飞书固化
8 意向客户每 2～3 个工作日跟进一次，直到转商机或放弃并写明原因 负责销售 每 2～3 个工作日 CRM、飞书任务 跟进记录 🔧飞书固化
9 超时回收：24 小时未首次联系、7 天无跟进记录的先提醒，再过 24 小时未处理退回线索池重新分配 机器人、线索中台管理员 见动作 多维表格自动化 回收记录 🤖自动化
10 每周盘点：未分配、超时、P0 未转化；P0 未转化由负责销售写复盘 线索中台管理员、销售负责人 每周五 线索池看板 周盘点、P0 复盘 👤人工判断

5. 交付物与模板

  • 交付物：线索池记录、首次联系与跟进记录、周盘点表、P0 复盘
  • 建议模板/表单：
    • 线索池：线索编号、来源入口（官网表单/来电/公众号/介绍人/布道活动/高管资源/转介绍/培训班）、来源人、提交时间、客户全称（企查查）、联系人与职务、联系方式、规模、核心需求、甄别结论、等级、负责销售、认领时间、首次联系时间、阶段、下次跟进时间、放弃原因、是否测试数据
    • 活动现场登记表单：姓名、单位、职务、关注点、是否担心数据安全、希望的联系方式
    • P0 复盘：线索背景、跟进过程、未转化原因（预算/决策链/产品不匹配/竞品/时机）、改进动作

6. 异常与升级

  • 甄别为伪装成客户的推销或同行套方案 → 标“无效-推销/同行”，不安排演示 → 疑似套方案当天报 CTO
  • 甄别为渠道 → 转渠道负责人，按 SAL-27 / SAL-31 处理（1 个工作日内）
  • 客户已在他人名下 → 归原负责人；有争议 → 销售负责人 1 个工作日内裁决（SAL-33）
  • 负责销售离职或调岗 → 名下线索由销售负责人 1 个工作日内重新分配，并在线索池写明交接上下文
  • 政企听众提出数据泄密顾虑而现有方案不能覆盖 → 如实答复并登记 → CTO 2 个工作日内给出对外口径（SAL-10）
  • 机器人推送乱码或失败 → 研发当日修复，期间人工登记

7. 衡量指标

  • 首次联系及时率 = 12 小时内首次联系的线索数 / 有效入站线索数，目标 ≥ 90%
  • 分配时长 = 登记到确定负责人的工作小时数，中位数 ≤ 4 小时
  • 无人跟进线索数 = 超过 7 天无跟进记录的线索数，目标 0
  • 入站线索转商机率 = 转为商机的线索数 / 有效入站线索数，按来源统计
  • 登记率 = 进入线索池的入站线索 / 月度抽查发现的入站线索，目标 100%

8. 低效诊断

  • 现象：官网预约由研发看到后手工转发市场，没人明确负责打电话，也没有甄别规则（接收与分配环节无责任人）｜依据：「鼎慧产研决策部」2026-08
  • 现象：官网线索机器人只推送不认领，测试消息和真实线索混在同一群（推送环节缺认领与来源区分）｜依据：「跃玩项目组」2026-06、「跃竞市场部」2026-06
  • 现象：线索清单发群后各自认领，再私下要上下文（认领环节信息不在线上）｜依据：「【模态】市场销售」2026-08
  • 现象：高管手里的客户资源没人跟进，线索散在多个表里（入口不统一）｜依据：「【模态】市场销售」2026-10
  • 现象：布道后政企听众的需求只在群里口述，临时喊“快派人去”（活动线索无登记与分派）｜依据：「Claw布道/案例组」2026-03
  • 现象：主动上门线索谁来联系，要高管在群里点人（分配规则缺失）｜依据：「字字可研市场运营」2026-03、「字字可研市场运营」2026-04
  • 现象：跟进标准在复盘会后才制定，人员变动后手上线索谁接不清（交接环节缺规则）｜依据：「跃竞市场决策」2026-08、「跃竞市场部」2026-08

9. 分支变体

  • 跃竞官网（定价页申请/免费开通）：机器人卡片 → 12 小时内首次触达 → 入驻材料阶段每日跟进答疑 → 开通后邀约培训并发操作手册 → 回访到正式使用才算闭环 → 已入驻客户写入 CRM 工作台，自动生成分润
  • 模态官网预约演示：按主流程，重点甄别伪装成客户的推销者和渠道
  • 主动上门（来电/公众号/介绍人）：先背调再安排拜访或来访；公众号咨询先留统一业务联系人
  • 布道/分享后政企听众：讲师现场用统一二维码登记，讲完 24 小时内由销售首次联系；有技术顾虑的同时拉技术同席
  • 高管资源、外部转介绍、培训班名单：统一进线索中台，由销售负责人分配
  • 专项计划线索（如繁星计划）：由市场部统一分发，仍登记进线索池

10. 待确认问题

  • 线索中台归市场生态还是销售运营维护？分发执行人是否仍为当前人员？
  • “12 小时首次联系、7 天无跟进即回收”是否推广到模态全公司？
  • P0/P1/P2 的定义是否认可？P0 未转化复盘由谁审？
  • 线索池用跃迁 CRM 线索公海池，还是独立多维表格？
  • 公众号/官网咨询的统一对外联系人是谁？
SAL-03商机甄别、可行性初筛与赢丢单复盘待新建320

状态：待新建｜证据：有证据（卡片 6 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨5 × 险4

  • 适用场景：新商机或外部需求（标准 B 端项目、伙伴转介客户、熟人介绍的 Demo/MVP 小单、外部培训、外部技术撮合）出现，在投入方案、报价、研发之前判断“能不能做、值不值得做、谁来做”；商机赢单、丢单或卡住后做复盘
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——商机负责销售（当前：闫登辉、吴琪、刘昱潇、时建、杜中瑞·推断待确认）、CTO（当前：丁震宇·推断待确认，技术可行性与优先级）、FDE Leader（当前：黄振锋·推断待确认，技术信息收集）、CEO（当前：邴龙志·推断待确认，战略取舍）、法务/财务负责人（当前：待指定，外部小单合同与收款）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① CRM 登记商机与需求原文 → ② 发客户信息收集清单 → ③ 五项甄别（预算/决策链/时间/标品匹配/竞争）→ ④ 技术可行性与定制比例评估 → ⑤ 分级 A/B/C 并决定跟进、放弃或转介 → ⑥ 立项推进或礼貌退出 → ⑦ 赢丢单复盘与月度规则更新
  • 交付结果：CRM 中每个商机带评估结论（等级、是否立项、理由、审批人）；已填的客户信息收集清单；赢丢单复盘记录与月度复盘结论
  • 状态依据：2026-05～10 管理层多次口头给出“摸清预算按预算倒推方案”“控制不了决策链基本是骗方案”“先签合同再定制”等规则，但没有评估表和固定复盘；为未确认预算的客户出了多轮方案后最终不做；外部小单、培训、技术撮合都靠口头接单报价，没有合同和定金

1. 场景判定

  • 触发条件：CRM 新建商机；客户或伙伴发来需求文档要报价；熟人/渠道介绍定制小单；政府/高校培训需求；外部技术需求找人做；管理层追问真实进展；商机卡住超过 30 天，或赢单/丢单
  • 典型说法：「摸清楚预算，我们按预算来倒推方案」「不是所有商机和客户都是优质的」「现在缺点上下文」「我们这边现在还无法给任何承诺和报价」「做一个 MVP 有没有搞头」「费用+内容+培训时间，给我报一下」「有没有认识能做这玩意的人」
  • 判断问题：客户有没有明确预算和可控的决策链？需求是标品能覆盖还是要定制？现在投入人力值不值？
  • 不归本流程管：线索接入与认领 → 请走 SAL-02；立项后的大客户推进 → 请走 SAL-06；定制需求人日与排期估算 → 请走 X-PRD-11 / SAL-21；方案与报价单编制 → 请走 SAL-19；政企客户需求摸底与汇报 → 请走 SAL-07；外部讲课布道接单 → 请走 MKT-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
登记与信息收集 登记 CRM、发信息收集清单、补齐五项甄别 R 商机负责销售（当前：闫登辉、吴琪、刘昱潇、时建、杜中瑞·推断待确认）
甄别把关与分级 审五项甄别，定等级与跟进/放弃，主持月度复盘 A 销售负责人（当前：李鹏为·推断待确认）
技术可行性 判断能否做、定制比例、是否派技术支持 R CTO（当前：丁震宇·推断待确认）
技术信息清单 列出评估所需技术信息、评估技术需求 R FDE Leader（当前：黄振锋·推断待确认）
战略取舍 共研、战略合作、政府背景项目的取舍 A（升级） CEO（当前：邴龙志·推断待确认）
外部小单合同与收款 需求确认单、定金、知识产权与介绍费条款 C 法务负责人、财务负责人（当前：待指定）
复盘 写赢单/丢单复盘 R 商机负责销售

3. 办之前请准备

  • 客户全称（企查查）、行业、规模、对接人及职务
  • 需求原文或需求文档；渠道/介绍人的转介说明
  • 客户信息收集清单（复用伙伴转介客户评估时用过的清单模板）
  • 预算范围与来源、决策链（谁拍板、谁使用、谁采购）、期望上线时间
  • 已知竞品和客户现有系统
  • 外部小单：需求范围、交付形式（链接/演示/代码）、报价、定金比例、介绍费约定

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 CRM 登记商机并附需求原文；没有具体金额的仍记为线索 商机负责销售 获知需求后 1 个工作日内 CRM 商机记录 🔧飞书固化
2 发客户信息收集清单（业务场景、数据、部署、并发、现有系统），技术项由 FDE Leader 出 商机负责销售、FDE Leader 登记后 2 个工作日内发出 飞书文档模板 已填清单 🔧+🤖
3 五项甄别：预算、决策链、时间、标品匹配度、竞争；缺预算或决策链的先去问清，不出方案 商机负责销售 清单回收后 2 个工作日内 CRM 必填字段 甄别结论 👤人工判断
4 技术可行性与定制比例评估（AI 先初筛需求文档，再人工确认） CTO 或其指定技术 收到后 2 个工作日内 商机评估表 可行/不可行/需定制及比例 🤖+👤
5 分级：A（预算与决策链明确、以标品为主）立项；B 继续培育；C 放弃或转介；共研/战略合作报 CEO 销售负责人 第 4 步后 1 个工作日内 CRM 商机等级 👤人工判断
6 A 级进入 SAL-06 / SAL-19；需定制的先签合同再定制；信息不全的先线下沟通摸底，不对外承诺价格 商机负责销售 分级后 CRM 立项记录 👤人工判断
7 C 级或放弃：用统一话术礼貌退出，CRM 写明放弃原因 商机负责销售 分级后 2 个工作日内 CRM 放弃记录 🔧飞书固化
8 赢单、丢单或卡住超过 30 天：填复盘表 商机负责销售 结果确定后 5 个工作日内 飞书表单 复盘记录 🔧飞书固化
9 月度赢丢单复盘会：汇总原因，更新甄别规则和话术 销售负责人主持 每月第 1 周 飞书会议 复盘结论、规则更新 👤人工判断

5. 交付物与模板

  • 交付物：商机评估表、客户信息收集清单、放弃记录、赢丢单复盘、月度复盘结论
  • 建议模板/表单：
    • 商机评估表：客户全称、来源、需求摘要、预算（区间与来源）、决策链（决策人/使用人/采购人）、期望上线时间、标品匹配度（高/中/低）、定制比例、竞品、技术可行性结论、预计投入人日、等级、跟进/放弃决定、审批人
    • 赢丢单复盘表：结果、所处阶段、周期、原因分类（预算/决策链/价格/产品/竞品/关系/时机/只要方案不签约）、教训、规则建议
    • 外部小单需求确认单+报价单：范围、交付物、不含事项、价格、定金比例与时间、交付形式（先演示链接与视频，收款后交代码）、知识产权归属、介绍费比例

6. 异常与升级

  • 客户催报价但信息不全 → 回复“先线下沟通摸底”，不给数字 → 销售负责人 1 个工作日内决定是否安排面谈
  • 商机属于共研、战略合作或政府背景项目 → 分级与取舍决定权由销售负责人升级至 CEO → 销售负责人在第 4 步后 1 个工作日内提报，CEO 3 个工作日内拍板
  • 销售与 CTO 对优先级判断冲突（如共研合作）→ 列出收入预期与投入 → 报 CEO 3 个工作日内裁决
  • 疑似只要方案不谈合同（控制不了决策链）→ 停止出方案 → 当天报销售负责人
  • 外部小单定金未到 → 不开工、不交源码 → 报 CTO
  • 管理层追问真实进展 → 销售负责人 1 个工作日内按 CRM 汇总回复
  • 同一客户多人对接 → 转 SAL-33，销售负责人 1 个工作日内指定唯一负责人

7. 衡量指标

  • 评估完成率 = 五项甄别齐全的商机数 / 新建商机数，目标 ≥ 90%
  • 甄别周期 = 登记到分级的工作日数，目标 ≤ 5 个工作日
  • 无效方案数 = 出过方案但预算或决策链不达标的商机数，按月统计，目标逐月下降
  • 丢单复盘率 = 有复盘的丢单数 / 丢单数，目标 100%
  • A 级商机赢单率 = A 级赢单数 / A 级商机数，按季度统计

8. 低效诊断

  • 现象：为未确认预算的客户出了多轮方案，最后建议不做（甄别环节缺预算/决策链门槛）｜依据：「【模态】市场销售」2026-05、「【模态】市场销售」2026-07
  • 现象：同一客户多人对接，管理层觉得“有点乱”（登记环节无唯一负责人）｜依据：「【模态】市场销售」2026-07
  • 现象：管理层多次追问“真实有效的商务进度”（商机阶段口径不一）｜依据：「【模态】市场销售」2026-05、「【模态】市场销售」2026-06
  • 现象：伙伴转介客户只有产品介绍资料，对方催报价，内部临时出信息清单（信息收集环节无标准模板）｜依据：「百分书童AI问答优化」2026-10
  • 现象：外部 Demo 小单口头报价，需求反复变化，无合同无定金（外部小单缺接单流程）｜依据：「鼎慧产研决策部」2026-05
  • 现象：外部培训需求报价无标准，员工逐个问报酬与公司是否抽成（培训接单缺报价模板）｜依据：「模态集团（全员群）」2026-05
  • 现象：外部技术需求在群里问谁能做，提成与结算凭口头（撮合入口不明）｜依据：「鸽子群模态分群」2026-03

9. 分支变体

  • 标准 B 端商机（定制项目、标品 LeapCore、政府项目、渠道推荐）：按主流程
  • 伙伴转介客户：转介人负责传递清单与反馈，按“技术评估 → 线下摸底 → 再报价”三步走，评估前不承诺价格
  • 外部小单（Demo/MVP）：需求确认单+报价单+定金节点；先交演示链接与视频，收全款后交代码；介绍费比例事先书面约定并报财务
  • 外部培训需求：报“费用+内容+时间”；以公司名义承接的走合同；讲师酬劳标准待定；客户有政府背景的单独标注
  • 外部技术撮合：登记需求、预算、期限；公司不做的可转介，但以公司名义收取佣金须走合同；纯请教类按统一话术婉拒
  • 共研/平台合作：默认低优先级，先从集成对方 Skill 试销开始，报 CEO 定

10. 待确认问题

  • 商机甄别主责是否为销售负责人？技术可行性能否下放给 FDE Leader，不必每次 CTO 判断？
  • A/B/C 分级标准和“没有具体金额只能叫线索”是否写入销售制度？
  • 外部小单、培训、撮合是否允许员工个人承接？介绍费、讲课酬劳、撮合佣金的标准与报备方式？
  • 月度赢丢单复盘放在销售周会，还是单独开？
  • 客户信息收集清单是否作为全公司统一模板，由谁维护？
SAL-04CRM 客户/商机录入与维护待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：出现新客户、线索、商机、合同或渠道，每次拜访/沟通之后，每周周报之前，台账缺失需要补录，CRM 切换过渡期，新人要开 CRM 账号，或试用客户充值需要登记时
  • 负责人：主责——CRM 管理员（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，口径与督办）、销售台账维护（当前：汪家诺·推断待确认）、CRM 研发（当前：郭逸非·推断待确认）、CRM 部署（当前：杨睿·推断待确认）、系统管理员（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认，绩效挂钩规则）、各销售（录入）；兜底——销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 开通账号与角色 → ② 企查查全称查重 → ③ 线索进公海池、商机按规范命名 → ④ 每次沟通后 24 小时内记跟进 → ⑤ 赢单上传合同并生成订单 → ⑥ 每周五机器人查缺补漏 → ⑦ 每月与合同台账、回款核对 → ⑧ 考核只取 CRM 数据
  • 交付结果：CRM 中客户唯一、负责人唯一、商机阶段与金额准确、跟进记录完整、合同与订单可关联；每周未更新清单；每月数据质量报告
  • 状态依据：已有 CRM（飞书多维表格原型 → 外购 CRM → 自研跃迁 CRM）和《销售体系管理制度》，2026-09 明确“不入 CRM 不计入绩效”；但 2026-04～07 至少 5 次群内催填，2026-06 自评“使用率非常低”，2026-07 合同已签不少但销售订单只有 3 个；CRM、台账、周报、多维表格多处重复录入

1. 场景判定

  • 触发条件：新客户/线索/商机/合同/渠道出现；拜访、通话、会议之后；每周五周报前；台账字段缺失或对外报送需要客户信息；新人入职或转岗；客户试用充值
  • 典型说法：「每天工作了，随手就把 CRM 填写下」「以后不入 CRM 的数据不计入绩效」「用企查查名字就行了，随意填写会影响绩效」「负责人只能有一个，不然会扯皮」「已经那么多合同了，为啥只有 3 个销售订单」
  • 判断问题：这条信息属于客户、线索、商机、合同还是跟进记录？CRM 里是否已经有了？
  • 不归本流程管：线索接入与分配 → 请走 SAL-02；客户归属争议与撞单 → 请走 SAL-33；赢单合同与回款跟踪 → 请走 SAL-24；按 CRM 数据考核与提成 → 请走 SAL-34；CRM 功能开发与上线验收 → 请走 X-FDE-20；渠道客户报备 → 请走 SAL-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账号与权限 开通/停用账号，分配销售、销售经理、管理员角色，对接系统问题 R CRM 管理员（当前：闫登辉·推断待确认）
录入规范与督办 定命名、必填、阶段口径，每周检查，挂钩考核 A 销售负责人（当前：李鹏为·推断待确认）
日常录入 客户、商机、跟进记录、合同关联、试用充值登记 R 各销售（当前：吴琪、杨朋伟、杜中瑞·推断待确认）
台账与核对 合同台账、周未更新清单、月度数据核对 R 销售台账维护（当前：汪家诺·推断待确认）
系统功能 修 bug、查重提示、公海池、权限、部署 C CRM 研发（当前：郭逸非·推断待确认）、部署（当前：杨睿·推断待确认）
系统管理 管理员权限、license、规则拍板 C 系统管理员（当前：丁震宇·推断待确认）
绩效规则 定“不入 CRM 不计绩效”等规则 A（升级） CEO（当前：邴龙志·推断待确认）
合同/回款联动 合同编号、回款数据比对 I 财务/法务负责人（当前：待指定）

3. 办之前请准备

  • CRM 账号与角色（入职当日申请）
  • 客户的企查查全称、统一社会信用代码
  • 联系人姓名、职务、联系方式（对外报送常需要）
  • 商机信息：产品类型、预计金额、阶段、预计签约时间
  • 拜访/会议纪要链接（见 SAL-05）
  • 赢单时：合同编号与扫描件；试用充值时：充值截图

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新人入职/转岗申请账号，管理员按角色开通（销售只看自己；销售经理看全体商机并接收待处理；管理员管系统） 申请人 → CRM 管理员 申请后 1 个工作日内 飞书审批、CRM 后台 账号 🔧飞书固化
2 新建前用企查查全称查重；已存在的联系负责人或申请加为协助人，不重复建客户 销售 建档前 CRM、企查查 查重结果 🔧+🤖
3 线索先进公海池，不直接建客户；有具体金额和需求后再转商机，转商机必填手机号 销售 获知当日 CRM 公海池 线索/商机 🔧飞书固化
4 商机按「客户名称+产品类型+商机金额」命名；同一客户多项目挂同一客户下各建商机；负责人唯一，可加协助人 销售 建商机时 CRM 商机 🔧飞书固化
5 每次拜访/通话/会议后记跟进（时间、对象、内容、下一步），纪要链接挂到商机 销售 沟通后 24 小时内 CRM 一键记录表单 跟进记录 🔧+🤖（AI 从纪要/日报抽取回填）
6 阶段变化时更新阶段与金额；不具备转化条件的商机撤出或降回线索 销售 变化当日 CRM 阶段更新 👤人工判断
7 赢单必须上传合同并生成销售订单；试用客户充值同步登记 销售 签约/充值后 2 个工作日内 CRM 合同、订单、充值记录 🔧飞书固化
8 机器人推送本周未更新跟进的商机和缺失字段清单，销售当日补齐 机器人、台账维护 每周五 16:00 推送，18:00 前补齐 飞书机器人 未更新清单 🤖自动化
9 核对 CRM 合同/订单与合同台账、财务回款的差异，报销售负责人 销售台账维护 每月第 3 个工作日前 CRM、合同台账 数据质量报告 🔧+🤖
10 月度/年度考核只取 CRM 数据 销售负责人 按考核周期 CRM 导出 考核数据 🔧飞书固化

5. 交付物与模板

  • 交付物：CRM 客户/商机/跟进记录、周未更新清单、月度数据质量报告、《CRM 录入规范》
  • 建议模板/表单：
    • 客户：企查查全称、统一社会信用代码、行业、地区、来源标签（展会/专项计划/渠道/官网/转介绍）、负责人、协助人、联系人（姓名/职务/电话）
    • 商机：名称、产品类型、金额、阶段（初步接触/需求确认/方案报价/商务谈判/赢单/丢单）、预计签约日、负责人、竞品、丢单原因
    • 跟进记录：时间、方式、对象、内容摘要、下一步、纪要链接
    • 《CRM 录入规范》（置顶群公告）：命名、查重、角色权限、阶段定义、必填项、归属冲突升级路径

6. 异常与升级

  • 登录失败或无权限 → 在 CRM 反馈群报 CRM 管理员 → 1 个工作日内解决；系统 bug 转 CRM 研发
  • 新建时出现重名或关联提示 → 先查归属，不得另建 → 有争议转 SAL-33，销售负责人 1 个工作日内裁决
  • 选不到他人建立的客户、无法补跟进 → 申请加为协助人 → CRM 管理员当日处理
  • 销售离职或调岗 → 名下客户、商机由销售负责人 1 个工作日内指定接手人，管理员执行转移
  • 新旧系统切换 → 先盘点所有登记点（含试用充值登记）→ 迁移完成前双写，完成后旧系统只读
  • 连续 2 周未更新 → 销售负责人点名 → 计入月度考核
  • 需要制定或调整 CRM 数据与绩效挂钩的规则（如“不入 CRM 不计入绩效”的范围与例外） → 决定权由销售负责人升级至 CEO → 销售负责人提出方案，CEO 在下一考核周期开始前拍板

7. 衡量指标

  • 跟进记录及时率 = 24 小时内录入的跟进记录 / 实际拜访沟通次数（按日报抽查），目标 ≥ 90%
  • 必填完整率 = 必填字段齐全的客户与商机 / 总数，目标 ≥ 95%
  • 合同-订单一致率 = CRM 有订单的合同 / 合同台账合同数，目标 100%
  • 重复客户数 = 同一企查查全称的重复客户数，目标 0
  • 周未更新占比 = 当周无跟进记录的活跃商机 / 活跃商机数，目标 ≤ 10%

8. 低效诊断

  • 现象：群里反复催“把 CRM 更新”（录入环节无自动提醒与门禁）｜依据：「【模态】市场销售」2026-04、「【模态】市场销售」2026-07
  • 现象：CRM、台账、周报、多维表格多处重复填，日报与 CRM 双重录入（多系统并行）｜依据：「【模态】市场销售」2026-04、「【模态】市场销售」2026-08
  • 现象：线索与商机混用，商机金额不准，使用率低到无法反映销售动作（阶段与金额口径不一）｜依据：「【模态】市场销售」2026-04、「【模态】市场销售」2026-06
  • 现象：合同已签但 CRM 只有少量销售订单，赢单项目未转化（赢单环节无合同上传门禁）｜依据：「【模态】市场销售」2026-07、「【模态】市场销售」2026-08
  • 现象：客户只在名称完全相同时才拦截，命名靠自觉，角色权限无说明（查重与权限环节无成文规范）｜依据：「跃迁CRM反馈群」2026-09
  • 现象：对外报送需要客户联系人时，台账中大多缺失（必填字段缺失）｜依据：「【模态】市场销售」2026-09
  • 现象：补台账要“人盯人”逐个督促、限时补齐（补录靠人工催办）｜依据：「【模态】市场销售」2026-08

9. 分支变体

  • 系统过渡：飞书多维表格原型 → 外购 CRM → 自研跃迁 CRM；过渡期新商机同时填台账，迁移完成后以跃迁 CRM 为准
  • 标品渠道客户走渠道系统（SAL-31），非标客户走 CRM
  • 试用客户充值：在 CRM 登记并截图；迁入跃迁 CRM 时保留该登记点
  • 渠道用户没有飞书账号：单独建号
  • 跃竞 CRM 工作台：已入驻客户写入后自动生成分润，口径与本流程一致
  • 台账分三类：商机、合同归档、渠道管理

10. 待确认问题

  • CRM 管理员是否为当前人员？销售台账维护由谁长期负责？
  • 外购 CRM 和飞书表格台账是否正式停用？切换日期是哪天？
  • 跟进记录 24 小时内录入是否可行？
  • 商机阶段定义、“没有具体金额只能叫线索”是否写进《销售体系管理制度》？
  • 试用充值登记是否已纳入跃迁 CRM 设计？
  • 客户联系人信息的可见范围如何控制？
SAL-05客户拜访与会议纪要记录、信息同步待优化120

状态：待优化｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频5 × 耗2 × 跨4 × 险3

  • 适用场景：与客户、渠道、合作方或政府单位完成拜访、会议、饭局、展会交流，或需求/验收/售后沟通之后，需要把结论、承诺、下一步留痕并同步给内部相关人时启动
  • 负责人：主责——商机负责销售（当前：吴琪、时建、杜中瑞、陈名赞·推断待确认）；协同——销售运营（当前：韩诗琪·推断待确认，纪要汇总表维护）、重大项目总负责人（当前：时建·推断待确认）、生态市场总监（当前：许君·推断待确认，汇总表口径）、产品负责人（当前：杨萌·推断待确认，客户信息表）、CTO（当前：丁震宇·推断待确认，客户沟通留痕规则）、CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 建日程时定记录人并默认录制 → ② 会中录制/妙记 → ③ 会后 24 小时内发纪要（3～5 句结论+承诺+下一步）→ ④ 写入 CRM 跟进与客户档案 → ⑤ 下一步转飞书任务 → ⑥ 同步销售群或项目群 → ⑦ 每周汇总与回访
  • 交付结果：统一模板的会议纪要、CRM 跟进记录、客户档案（售后文档）更新、带负责人和截止日期的待办、每周纪要汇总表
  • 状态依据：2026-06～08 销售群约 40 次发纪要，已有纪要汇总表并试点销售部机器人检索；但格式长短不一、未联动 CRM，缺席者要追问“聊了啥”，拜访记录表靠催补，客户需求沟通此前多在电话/企微无记录

1. 场景判定

  • 触发条件：任何对外拜访、来访、会议、饭局、展会交流结束；客户提出需求、验收意见、售后问题的沟通；重大合作项目的阶段会议
  • 典型说法：「你们中午聊啥了」「以后弄完了，最好来一个三五句的，一下就能看懂结果的总结」「做 B 端一定得注意信息留痕」「大家在这个群保持信息同步，没有信息差」「在客户信息表里新建了一个记录表」
  • 判断问题：这次沟通里有没有客户信息、我方承诺、客户需求或下一步动作？有就必须留痕
  • 不归本流程管：会前准备与口径 → 请走 SAL-08；纯内部会议纪要归档 → 请走 CEO-10；CRM 字段规范 → 请走 SAL-04；销售日报周报 → 请走 SAL-32；交付期客户问题 → 请走 X-DLV-34；售后问题受理 → 请走 X-CS-05；高管日程 → 请走 CEO-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
记录与发纪要 录制、整理纪要、写 CRM、建待办、回访 R 商机负责销售（当前：吴琪、时建、杜中瑞、陈名赞·推断待确认）
汇总与质检 维护纪要汇总表、检查格式、每周提醒缺纪要 R 销售运营（当前：韩诗琪·推断待确认）
重大项目报备 项目群同步纪要与阶段进展 R 重大项目总负责人（当前：时建·推断待确认）
审阅与跟进决定 审纪要、决定是否继续跟进、是否外发 A 销售负责人（当前：李鹏为·推断待确认）
汇总表口径 定汇总字段（日期/主题/关键事项/链接） C 生态市场总监（当前：许君·推断待确认）
留痕规则 客户需求/售后沟通录制并归档 C CTO（当前：丁震宇·推断待确认）
知悉 重大项目进展 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 飞书日程（参会人、记录人、是否录制）
  • 纪要模板（见第 5 节）
  • 客户档案/售后文档链接、CRM 商机链接
  • 上次纪要及未完成承诺清单
  • 线下会议：录音设备或手机妙记

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建日程时指定记录人，默认开启飞书会议录制/妙记；线下用妙记录音 会议发起人 会前 1 个工作日 飞书日程、妙记 带记录人的日程 🔧飞书固化
2 会中记录参会人及角色、客户诉求、我方承诺、分歧、下一步 记录人 会中 妙记 原始记录 🤖自动化
3 发纪要：开头 3～5 句写主题、结论、下一步，正文再附细节 记录人 会后 24 小时内 飞书文档模板、AI 摘要 纪要 🔧+🤖
4 纪要链接写入 CRM 跟进记录；需求、验收、售后类沟通同时写入客户售后文档 商机负责销售 纪要发出当日 CRM、客户档案 跟进记录 🔧+🤖
5 下一步转飞书任务（负责人+截止日期）；需回访的设回访日期 商机负责销售 纪要发出当日 飞书任务 待办 🔧飞书固化
6 同步：普通客户发销售群；重大合作项目发对应项目协调群；@ 缺席的关键人 商机负责销售/项目总负责人 纪要发出当日 飞书群 同步消息 🔧飞书固化
7 机器人汇总本周纪要（日期、主题、客户、关键事项、负责人、链接），列出有日程无纪要的拜访 销售运营 每周五 多维表格、机器人 周汇总表 🤖自动化
8 按任务日期回访，新增跟进记录 商机负责销售 按约定日期 CRM 回访记录 👤人工判断

5. 交付物与模板

  • 交付物：会议纪要、CRM 跟进记录、客户档案更新、飞书任务、周纪要汇总表
  • 建议模板/表单：
    • 纪要模板：日期、客户/单位（CRM 全称）、类型（拜访/来访/线上/饭局/展会/验收/售后）、我方参会人、对方参会人及角色、主题、3～5 句结论、客户诉求、我方承诺（承诺项/责任人/时限）、风险与分歧、下一步（负责人/截止日期）、录制链接、是否可对外
    • 纪要汇总表：日期、主题、客户、商机、关键事项、负责人、链接、是否已入 CRM
    • 客户档案/售后文档：历次沟通、承诺、需求变更、验收意见

6. 异常与升级

  • 会后 24 小时未发纪要 → 机器人提醒 → 48 小时仍未发，报销售负责人
  • 纪要中出现超出合同或口径的承诺 → 当日报销售负责人，按 SAL-10 / SAL-25 纠偏，必要时 2 个工作日内书面向客户澄清
  • 客户沟通未录制且事后有争议 → 用邮件或群消息让双方书面确认 → 升级销售负责人
  • 涉及客户内部信息或机密 → 不发大群，只发项目群或权限文档 → 按 SAL-32 保密分级
  • 重大项目多人分头对接、信息不一致 → 项目总负责人 1 个工作日内在项目群统一 → 仍有分歧升级 CEO

7. 衡量指标

  • 纪要及时率 = 24 小时内发出的纪要数 / 对外会议数，目标 ≥ 90%
  • 纪要入 CRM 率 = 已挂到 CRM 的纪要数 / 纪要总数，目标 ≥ 90%
  • 待办按期完成率 = 按期完成的会后待办 / 会后待办总数，目标 ≥ 85%
  • 客户沟通录制率 = 已录制的需求/验收/售后沟通 / 该类沟通总数，目标 ≥ 80%
  • 纪要合格率 = 含结论和下一步的纪要 / 纪要总数，目标 ≥ 90%

8. 低效诊断

  • 现象：会后只在群里口头同步要点，缺席者追问“聊了啥”，没有纪要和待办（会后同步环节缺失）｜依据：「鼎慧产研决策部」2026-04
  • 现象：纪要长短格式不一，被要求补“三五句结论”；纪要散在群里要靠回溯（格式与归集环节）｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-07
  • 现象：纪要不联动 CRM，跟进记录要另填一遍（记录环节重复）｜依据：「【模态】市场销售」2026-07
  • 现象：客户信息表、拜访记录表靠催补（录入环节无提醒）｜依据：「字字可研市场运营」2026-01、「字字可研市场运营」2026-03
  • 现象：客户需求与售后沟通多在电话/企微，没有记录，容易扯皮（留痕规则事后才定）｜依据：「LeapCore（archived）」2026-05
  • 现象：重大合作项目信息差，需专门建群要求报备（项目同步环节缺看板）｜依据：「某金控客户项目总协调沟通」2026-08、「光合组织合作群」2026-08
  • 现象：高管要人陪同拜访时临时找人，没有行程表（陪访排班缺失）｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-10

9. 分支变体

  • 规模化拜访期：在客户信息表中建拜访记录表，CRM 上线后迁入 CRM
  • 重大合作项目（一家集团或区政府下多个项目并行）：设项目协调群和项目总负责人，所有合作情况、信息、对接人在群内报备，纪要发群并挂项目看板（SAL-06）
  • 客户需求/验收/售后沟通：必须用飞书会议或语音录制，记录进客户售后文档
  • 渠道沙龙、政府拜访、内部晨会：用同一模板，政府拜访纪要默认不外发
  • 高管陪访：销售把行程填入共享行程表/日历，高管按表安排陪访；留守人员表是否建立待定

10. 待确认问题

  • 纪要主责是商机负责销售还是记录人？是否统一为“谁约的会谁负责”？
  • 纪要汇总表与销售部机器人由谁维护？
  • 客户售后文档放 CRM 附件还是知识库？
  • 需求/验收/售后沟通强制录制，是否需要事先告知客户？
  • 销售行程表与留守人员表是否建立，归本流程还是 CEO-18？
SAL-06重点商机上报与大客户分级推进待优化300

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：销售发现客户有强烈购买意向，或商机金额较大、客户为集团/国企/政府/行业头部等战略客户，需要上报、分级、拉齐公司资源，并按节点推进到签约时启动
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——项目负责销售（当前：闫登辉、刘昱潇、吴琪、杨朋伟、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，方案审核与产品/定价判断）、COO（当前：常元和·推断待确认，统一口径与 CRM 督促）、产品负责人（当前：杨萌·推断待确认，需求对齐与 Demo）、CEO（当前：邴龙志·推断待确认，资源决策）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 填表上报重点商机 → ② 分级 A/B/C → ③ 项目启动会（目标、分工、里程碑、口径、价格边界）→ ④ 需求对齐 → ⑤ Demo/方案并审核 → ⑥ 报价与合同 → ⑦ 每周更新看板、周会汇报 → ⑧ 卡点升级 → ⑨ 签约转交付或丢单复盘
  • 交付结果：重点项目看板（阶段、下一步、卡点、需支持人）、启动会纪要与分工、每周进展、签约合同或明确的放弃结论
  • 状态依据：已有周报分“非标项目/标品/渠道”汇报、A/B/C 分类和统一格式的启动会通知；但 2026-06 管理层追问“真实有效的商务进度”后才列出公司级重点项目，没有项目看板，对接人重叠，大客户合同卡点靠群里临时求助，异地团队进展靠口述、CRM 靠提醒

1. 场景判定

  • 触发条件：客户明确采购意向或预算；商机金额达到重点项目门槛（待定）；客户为集团、国企、政府或行业头部；需要两个以上部门投入（定制、POC、硬件）；管理层点名的公司级项目
  • 典型说法：「以上就是公司级的重点项目」「这几周的订单推进情况如何，我是指真实有效的商务进度」「先对需求，然后再给他们回馈一版 demo 产品方案，最后再定合同」「记得填 CRM」「合同有卡点，需要请求支持」
  • 判断问题：商机是否已通过 SAL-03 甄别？是否需要多部门投入，或金额/客户级别达到重点门槛？
  • 不归本流程管：商机初筛 → 请走 SAL-03；政企客户方案与汇报 → 请走 SAL-07；方案与报价单 → 请走 SAL-19；合同起草与用印 → 请走 SAL-23；POC 环境 → 请走 X-DLV-27；签约后交付启动 → 请走 X-DLV-09；跨组项目启动通用规则 → 请走 CEO-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
上报与推进 上报、组织启动会、推进各节点、每周更新看板 R 项目负责销售（当前：闫登辉、刘昱潇、吴琪、杨朋伟、时建·推断待确认）
分级与资源协调 定 A/B/C、主持启动会、协调支持、汇总向上汇报 A 销售负责人（当前：李鹏为·推断待确认）
方案审核 审方案、定标品/定制边界与定价判断 R CTO（当前：丁震宇·推断待确认）
对外口径 面谈前统一口径，督促 CRM C COO（当前：常元和·推断待确认）
需求与 Demo 需求对齐、Demo/产品方案 R 产品负责人（当前：杨萌·推断待确认）
资源决策 跨部门资源、价格特批、高层接待 C CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 已通过甄别的 CRM 商机
  • 客户背景：组织架构、决策链、预算与内部采购流程（是否多部门/多厂审批）
  • 需求材料和已有纪要
  • 启动会通知模板、项目看板
  • 现有方案、案例、销售方案；渠道参与时的分润模型

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填重点商机上报表（客户、意向、金额、决策链、时间、需要的资源），不再私下约汇报 项目负责销售 发现强意向后 1 个工作日内 飞书表单 → 项目看板 上报记录 🔧飞书固化
2 分级：A（公司级重点）、B（部门级）、C（常规）；A 级同步 CEO 销售负责人 上报后 1 个工作日内 项目看板 等级 👤人工判断
3 A/B 级发启动会通知（主题、时间、地点、参会人、议程、资料）；参会超过 7 人改站会 项目负责销售 分级后 2 个工作日内召开 飞书日程、文档 启动会通知 🔧飞书固化
4 启动会定目标、分工、里程碑、对外口径和价格边界，纪要发项目群 销售负责人主持 会议 ≤ 60 分钟，纪要会后 24 小时内 飞书会议、妙记 启动会纪要 👤+🤖
5 拜访客户对齐需求清单 项目负责销售、产品负责人 启动会后 5 个工作日内 纪要（SAL-05） 需求清单 👤人工判断
6 出方案或 Demo；A 级方案经 CTO 审核后发出 产品负责人/技术，CTO 审核 按里程碑，通常 ≤ 10 个工作日 飞书文档 方案/Demo 👤人工判断
7 报价与合同按 SAL-19 / SAL-23 执行；价格特批与高层接待由 CEO 参与 项目负责销售 按里程碑 CRM、飞书审批 报价单、合同 🔧飞书固化
8 更新看板（阶段、本周进展、下一步、卡点、需支持人），周会按看板汇报 项目负责销售 每周五 18:00 前 项目看板、CRM 周进展 🔧+🤖（周报由看板自动生成）
9 卡点（客户失联、采购流程卡住、合同条款）在看板标红并 @ 需支持人 项目负责销售 发现后 1 个工作日内 看板、项目群 支持请求 🔧飞书固化
10 签约后转交付（X-DLV-07 / X-DLV-09）；放弃或丢单按 SAL-03 复盘 项目负责销售 结果确定后 5 个工作日内 CRM 交接单/复盘 👤人工判断

5. 交付物与模板

  • 交付物：重点商机上报记录、项目看板、启动会纪要、周进展、合同或放弃结论
  • 建议模板/表单：
    • 项目看板：项目名、客户、等级、金额、负责人、配合人、阶段、里程碑日期、本周进展、下一步、卡点、需支持人、最近更新时间
    • 上报表：客户全称、意向描述、预计金额、决策链、期望时间、需要的资源（技术/产品/高层/硬件）
    • 启动会通知：主题、时间、地点或会议链接、参会人、议程、会议资料
    • 周报分区：非标项目 / 标品 / 渠道

6. 异常与升级

  • 卡点 3 个工作日无进展 → 销售负责人介入 → 5 个工作日仍无进展升级 CEO
  • 客户不回消息、不接电话 → 换对接层级（高层拜访）→ 销售负责人 2 个工作日内决定
  • 同一客户多人对接 → 销售负责人当日指定唯一负责人，其余为配合（SAL-33）
  • 客户要定制而标品不够 → 走 SAL-21 / X-PRD-11，价格与排期特批
  • 定制与标品打法有分歧 → 面谈前由 COO 统一口径，分歧大的报 CEO
  • 会议室或参会人冲突 → 改站会或线上

7. 衡量指标

  • 看板更新率 = 每周按时更新的 A/B 项目数 / A/B 项目数，目标 ≥ 95%
  • 上报到启动会时长：目标 ≤ 3 个工作日
  • 卡点响应时长 = 标红到需支持人回应：目标 ≤ 1 个工作日
  • A 级项目赢单率与平均成交周期，按季度统计
  • 管理层临时追问进度次数，按月统计，目标逐月下降

8. 低效诊断

  • 现象：管理层追问“真实有效的商务进度”后才临时列出重点项目（上报与分级环节缺台账）｜依据：「【模态】市场销售」2026-06
  • 现象：同一集团客户多个对接人，管理层觉得乱（分工环节不清）｜依据：「【模态】市场销售」2026-07
  • 现象：大客户合同有卡点、客户失联，临时在群里求支持（卡点升级无路径）｜依据：「【模态】市场销售」2026-07
  • 现象：异地团队商机进展靠群里口述，CRM 靠高管提醒（同步环节依赖人）｜依据：「苏州模态跃迁」2026-06
  • 现象：面谈前才统一口径，定制与标品打法反复争论（启动会环节缺失）｜依据：「苏州模态跃迁」2026-04、「苏州模态跃迁」2026-07
  • 现象：大会后的意向客户只有口述计划，没有商机管线（登记环节缺失）｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 异地团队大客户（水利、制造业、汽车）：客户内部采购需多部门审批后才出合同，看板单列“客户内部采购流程”节点；渠道商参与时附分润模型
  • 公司级重点项目：销售负责人每周汇总向 CEO 汇报
  • 大会/活动后工程咨询类意向客户：需求对齐 → Demo/产品方案 → 商务合同三步，行业版产品完善同步跟进
  • 政府项目、国企采购：叠加 SAL-07、SAL-22
  • 渠道大单：叠加 SAL-27 / SAL-31
  • 客户来访型启动会：参会人多时改站会，资料用飞书文档投屏

10. 待确认问题

  • 重点项目（A 级）的金额门槛是多少？
  • 启动会由销售负责人主持还是 CTO 主持？参会人上限定多少？
  • 项目看板放 CRM 还是多维表格？周会是否直接投屏看板？
  • 异地团队是否纳入统一看板？对外口径由谁最终审？
  • 价格特批与高层接待由 CEO 还是 COO 拍板？
SAL-07政企客户需求对接与方案汇报待新建375

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：政府部门（科创、科技、公安等）或国企、国有金融机构提出 AI 建设需求、邀请我方汇报，或客户内部上会需要我方提供支撑材料时启动
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——政企跟进销售（当前：闫登辉、杨朋伟、刘昱潇·推断待确认）、技术方案负责人（当前：王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认，方案评审与口径）、CEO（当前：邴龙志·推断待确认，客户关系与需求）、COO（当前：常元和·推断待确认，统筹与跟进人安排）、FDE/Skill 方案（当前：李凯·推断待确认）、法务负责人（当前：待指定，密级与合规）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 接需求/邀约建任务卡 → ② 摸底（对象角色、密级、部署、经费、算力、时间）→ ③ 定主讲与陪同 → ④ 出方案/白皮书（通俗版+技术附录）→ ⑤ 内部一次性评审 → ⑥ 出发前清单核对与拜访汇报 → ⑦ 会后复盘、报价、跟进 → ⑧ 支撑客户内部上会评审
  • 交付结果：政企客户档案、需求摸底清单、方案/白皮书定稿（含纸质版）、汇报纪要与复盘、客户上会支撑材料（数据分级分类规范、模型选型论证等）、礼品接待审批记录
  • 状态依据：2026-03 多次“没准备就去讲”“去了才知道跟谁聊”，白皮书改到第六版；2026-08 客户总办会退回，要求补数据分级与模型选型论证；2026-06 礼品拜访无事前审批、敏感内容不敢在大群发；每次都靠临时群聊协调，没有模板和清单

1. 场景判定

  • 触发条件：政府/国企客户提出智能体、知识库、安全扫描等建设需求；邀请参加专题会或汇报；客户内部总办会/评审会退回要求补材料；有人提议通过人脉、礼品、接待推进项目
  • 典型说法：「一般交流汇报都打印，政府喜欢看纸质」「上次也是去了才知道跟谁聊」「安全比智能化更重要」「有问他们经费从哪出吗」「结论是退回修订」「别搞不正经的生意」
  • 判断问题：对方是作为客户、有采购或建设可能的政府/国企吗？如果是监管要求、领导视察或平台方下达合规要求，不走本流程
  • 不归本流程管：政府监管、领导看进度、政策风险 → 请走 CEO-17；政府来访接待动线 → 请走 GEN-16；补贴申报 → 请走 POL-01；招投标与供应商入库 → 请走 SAL-22；报价单 → 请走 SAL-19；外部讲课布道 → 请走 ECO-13 / MKT-08；对外提供材料的保密审查 → 请走 LEG-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
牵头与任务卡 建任务卡、定主讲与陪同、推进全程 A 销售负责人（当前：李鹏为·推断待确认）
摸底与跟进 摸底清单、约时间、陪同、会后跟进 R 政企跟进销售（当前：闫登辉、杨朋伟、刘昱潇·推断待确认）
方案/白皮书 拆需求、选技术路线、撰写、现场讲技术 R 技术方案负责人（当前：王皓南·推断待确认）
方案评审与口径 按充实度/前沿性/可销售性打分，定口径 C CTO（当前：丁震宇·推断待确认）
客户关系 提供关键人、分管关系、需求原文 C CEO（当前：邴龙志·推断待确认）
统筹 追问经费、安排后续跟进人 C COO（当前：常元和·推断待确认）
上会支撑 数据分级分类规范、模型选型论证、Skill 方案 R FDE/Skill 方案（当前：李凯·推断待确认）
合规 密级判定、礼品接待合规审核 C 法务负责人（当前：待指定）

3. 办之前请准备

  • 政企客户档案：单位、处室、关键人及职务、分管关系、历次会谈
  • 需求摸底清单（见第 5 节）
  • 方案模板：通俗版（痛点—方案—成果—案例）+技术附录
  • 案例库与 Demo 视频（Claw/LeapCore 案例）
  • 报价口径与经费来源判断
  • 纸质版至少 2 份、演示设备与网络
  • 涉及礼品、宴请、第三方中介时：事前审批单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到需求或邀约后建“政企汇报任务卡”：时间、对象、主讲人、陪同销售、材料负责人 销售负责人 收到后 1 个工作日内 飞书任务 任务卡 🔧飞书固化
2 摸底：对象单位与角色、数据敏感还是涉密、能否上云或半私有化、经费来源、算力来源、交付期限、既有供应商 政企跟进销售（技术项由技术方案负责人） 汇报前 3 个工作日 摸底清单、公开信息检索 摸底清单 🤖+👤
3 定方案方向：私有化还是云部署，每条需求对应的技术路线 技术方案负责人，CTO 拍板 摸底后 2 个工作日内 飞书文档 方案大纲 👤人工判断
4 写方案/白皮书：通俗版讲痛点和成果，技术细节放附录，配案例和 Demo 技术方案负责人 汇报前 2 个工作日完成初稿 方案模板、AI 初稿 方案初稿 🤖+👤
5 内部评审：CTO 打分，销售负责人审表述（少用术语），意见一次性汇总 CTO、销售负责人 初稿后 1 个工作日内 飞书文档评论 定稿 👤人工判断
6 出发前核对清单：对象称呼与分管、口径、纸质版、演示设备、交通；技术与销售同去 政企跟进销售 出发前 1 天 18:00 前 清单 核对完成 🔧飞书固化
7 拜访汇报；会后发纪要（SAL-05）并复盘：客户关注点、需补案例、价格、经费 政企跟进销售 会后 24 小时内 纪要模板 纪要、复盘 🔧+🤖
8 确定后续跟进人与下一步，报价走 SAL-19 销售负责人 复盘后 2 个工作日内 CRM 跟进计划 👤人工判断
9 客户内部上会被退回：输出数据分级分类规范、模型选型论证等支撑材料，经 CTO 与法务审核后交客户 FDE/Skill 方案、技术方案负责人 退回后 3 个工作日内 材料模板 上会支撑材料 🤖+👤
10 礼品、宴请、第三方中介：事前提交事由、对象、形式、金额审批；不得提供现金及等价物；事后报备 政企跟进销售 事前 2 个工作日 飞书审批 审批记录 🔧飞书固化

5. 交付物与模板

  • 交付物：任务卡、政企客户档案、需求摸底清单、方案定稿与纸质版、纪要与复盘、上会支撑材料、礼品接待审批记录
  • 建议模板/表单：
    • 政企客户档案：单位、处室、关键人及职务、分管领导、与我方关系、历次会谈与结论、保密要求（权限仅限相关人）
    • 需求摸底清单：数据密级（公开/敏感/涉密）、部署方式（云/半私有/私有）、经费来源与区间、算力来源（自有/本地云/公有云）、交付期限、既有系统与供应商、决策流程（是否上总办会或专家评审）
    • 方案模板：通俗版正文 + 技术附录 + 案例 + 报价口径
    • 上会支撑材料模板：数据分级分类管理规范、模型选型论证（效果/成本/合规）、合规答疑
    • 商务接待/礼品审批单：事由、对象单位与职务、形式、金额、参与人、合规确认

6. 异常与升级

  • 临时通知来不及准备 → 只讲标准介绍和案例，不现场承诺 → 会后 2 个工作日内补正式方案，并报销售负责人
  • 没有合适主讲 → 销售负责人当日协调；临时借调研发的按 CEO-08 报备
  • 数据涉密或必须本地部署而方案不覆盖 → 不承诺 → CTO 2 个工作日内给结论，密级判定转法务
  • 方案改稿超过 3 轮 → 销售负责人召集 30 分钟对齐会统一意见
  • 客户上会退回 → 当天在项目群通报，按步骤 9 处理；二次退回升级 CEO
  • 有人提议送礼、付中介费等可能违规的做法 → 立即停止 → 当天报法务负责人和 CEO

7. 衡量指标

  • 准备达标率 = 任务卡+摸底清单+评审定稿齐全的汇报 / 汇报总数，目标 ≥ 90%
  • 方案改稿轮次：目标 ≤ 3 轮
  • 会后纪要及时率 = 24 小时内发出纪要的汇报 / 汇报总数，目标 100%
  • 客户上会一次通过率 = 一次通过的上会次数 / 上会次数
  • 礼品接待事前审批率 = 事前审批的次数 / 实际发生次数，目标 100%

8. 低效诊断

  • 现象：临时通知、研发被拉去讲方案，到现场才发现缺案例（准备环节无任务卡与案例库）｜依据：「鼎慧产研决策部」2026-03
  • 现象：去之前不清楚对象角色和称呼，“去了才知道跟谁聊”（摸底环节缺客户档案）｜依据：「武汉市科创局市场」2026-03
  • 现象：白皮书改到第六版，主要因为表述过于技术化（撰写环节缺通俗版模板）｜依据：「武汉市科创局市场」2026-03
  • 现象：经费来源、是否本地部署多人看法不一，担心数据泄露责任（摸底环节缺清单）｜依据：「武汉市科创局市场」2026-03
  • 现象：客户总办会退回，要求补数据分级与模型选型论证（上会支撑环节无模板）｜依据：「某投资机构B模态跃迁」2026-08
  • 现象：礼品拜访没有事前审批，敏感内容不敢在大群发（合规环节缺规范）｜依据：「苏州模态跃迁」2026-06

9. 分支变体

  • 科创/科技类政府客户：关注政务办理、算力和案例，经费有限，倾向云服务
  • 公安类客户：技术问题多、保密要求高、经费相对充足，倾向私有化
  • 国有金融/基金类客户：客户内部总办会评审，需要数据分级分类规范和模型选型论证
  • 双基座方案：传统基座与新一代 Claw 基座两套并行包装
  • 关系型销售：礼品、宴请、第三方中介一律事前审批，中介合作须法务审核

10. 待确认问题

  • 主责是销售负责人，还是专设政企销售岗？研发主讲时如何借调？
  • 政企客户档案放 CRM 还是独立多维表格？查看权限如何设？
  • 礼品、宴请的金额上限与审批人是谁？是否已有成文制度？
  • 数据密级是否由法务出具判定？
  • 上会支撑材料由 FDE 主写还是技术方案负责人主写？
SAL-08客户/渠道/合作方来访交流准备与会后复盘待新建135

状态：待新建｜证据：有证据（卡片 6 张 / 会话 10 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：客户、渠道商、生态方或合作意向公司来访、线上交流或邀我方上门洽谈（含带技术问题清单来访、套壳/集成合作洽谈），需要会前统一口径和材料、定出席人与技术同席、会后纪要与复盘时启动
  • 负责人：主责——来访对接人（销售/商务）（当前：时建、闫登辉、杨朋伟·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，判断来意、指派出席人与口径分工）、生态组负责人（产品口径，当前：陈梦琪·推断待确认）、IT 运维（信创/算力口径，当前：杨明学·推断待确认）、技术同席（当前：李铭熙、郭逸非、吴亚军·推断待确认）、会议组织（当前：杨萌·推断待确认）、COO（当前：常元和·推断待确认，高职级出席）；兜底——销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 填来访信息卡 → ② 判断来意与披露级别 → ③ 定出席人与 AB 角、发日程（默认录制）→ ④ 会前口径卡与精简讲解/演示 → ⑤ 会前 30 分钟提醒 → ⑥ 会中录制、不当场承诺 → ⑦ 纪要与统一书面答复 → ⑧ 复盘并转跟进
  • 交付结果：来访信息卡、会前口径卡、出席安排（含 AB 角）、会议纪要、对方问题的统一书面答复、复盘清单与跟进任务
  • 状态依据：2026-01 渠道首次交流“没有提前做针对性准备”、讲了 45 分钟没讲完；2026-02～03、2026-10 合作洽谈出席人临时商量、会前才发现没开录制；2026-10 负责人忘记客户会议、临时找人代听；没有会前清单、AB 角和复盘模板

1. 场景判定

  • 触发条件：客户/渠道/生态方/合作公司约来访或线上交流；对方提前发来问题清单；外部公司提出套壳、集成、代理合作；客户请求技术人员线上旁听
  • 典型说法：「每次客户（渠道）交流没有提前做针对性准备」「需要带一个 title 高的和一个懂开放平台的人去开个会」「回不出来的就说记录一下，统一发文档回复」「做好会议记录」「帮我听一下」
  • 判断问题：对方是否带着合作、采购或技术问题来，需要我方多人出席或统一对外口径？纯参观接待只走行政接待
  • 不归本流程管：场地、茶水、停车等接待事务 → 请走 ADM-06；政府/领导参观 → 请走 GEN-16；政企客户方案汇报 → 请走 SAL-07；演示内容准备 → 请走 SAL-11；售前技术问题统一答复 → 请走 SAL-09；对外口径库 → 请走 SAL-10；对外发材料保密审查 → 请走 LEG-30；纪要格式与入 CRM → 请走 SAL-05；生态合作伙伴引入 → 请走 ECO-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
来访组织 收集背景与问题、约时间、发日程、写口径卡、会后跟进与复盘 R 来访对接人（当前：时建、闫登辉、杨朋伟·推断待确认）
来意判断与出席指派 判断是否套方案、定出席人、AB 角、披露级别 A CTO（当前：丁震宇·推断待确认）
产品口径 统一产品功能与版本细节 R 生态组负责人（产品口径，当前：陈梦琪·推断待确认）
信创/算力口径 信创终端适配、算力说明 C IT 运维（信创/算力口径，当前：杨明学·推断待确认）
技术同席 答技术问题、演示、会后书面答复 R 技术同席（当前：李铭熙、郭逸非、吴亚军·推断待确认）
会议录制与纪要 开录制和智能纪要、发群 R 会议组织（当前：杨萌·推断待确认）
高职级出席 重要合作洽谈出席 C COO（当前：常元和·推断待确认）
复盘审阅 审复盘结论、更新口径 I 销售负责人（当前：待指定）

3. 办之前请准备

  • 对方单位全称、背景、来访人及职务、来访目的
  • 对方问题清单（事前索取）
  • 当前产品版本与演示链路（提前预约演示环境）
  • 报价口径（市场价/渠道价）、渠道政策 FAQ
  • 案例、能力图、演示视频（核对 UI 与当前版本一致）
  • 披露级别：可公开 / 口头概述 / 不披露
  • 需要时准备 NDA

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填来访信息卡：对方背景、诉求、问题清单、来访人、时间，标注类型（客户/渠道/生态/同行/合作） 来访对接人 确认来访当日，至少会前 2 个工作日 飞书表单 来访信息卡 🔧飞书固化
2 判断是否疑似套方案，定披露级别与出席人（商务 1 人+技术 1 人，重要合作加高职级 1 人），设 AB 角 CTO 收到信息卡后 1 个工作日内 信息卡 出席与披露决定 👤人工判断
3 发日程：参会人、AB 角、记录人，默认开启录制+智能纪要；会议室按 ADM-05 预约 来访对接人 会前 2 个工作日 飞书日程 日程 🔧飞书固化
4 写会前口径卡：对方诉求、我方目标、产品版本、报价口径、案例、可披露边界、当场答不了的处理方式；产品/信创/算力口径由对应负责人确认 来访对接人汇总，口径负责人确认 会前 1 个工作日 18:00 前 飞书文档、AI 背景摘要 口径卡 🤖+👤
5 准备 15～20 分钟精简讲解和演示，演示链路提前跑通 技术同席 会前 1 个工作日 演示环境（SAL-12） 讲解与演示 👤人工判断
6 机器人提醒主备出席人；主出席人无法到场由 B 角接替 机器人、B 角 会前 30 分钟 飞书日程提醒 到场确认 🤖自动化
7 会中录制；细节按披露级别答复，答不了的记下来，不当场承诺 出席人 会中 飞书会议/妙记 录音、待答问题 👤人工判断
8 发纪要（SAL-05）；待答问题统一写成文档回复对方 来访对接人、技术同席 纪要 24 小时内，书面答复 3 个工作日内 飞书文档 纪要、答复文档 🔧+🤖
9 复盘：诉求是否摸清、讲解时长、报价是否熟练、案例是否被质疑；新问题回填口径库 来访对接人 会后 2 个工作日内 复盘模板 复盘清单 👤人工判断
10 跟进动作（试用、合作协议、报价）入 CRM 和飞书任务 来访对接人 复盘当日 CRM、飞书任务 跟进任务 🔧飞书固化

5. 交付物与模板

  • 交付物：来访信息卡、口径卡、日程、纪要、书面答复、复盘清单、跟进任务
  • 建议模板/表单：
    • 来访信息卡：对方单位、来访人与职务、类型、目的、问题清单、我方对接人、日期、披露级别、出席人、AB 角
    • 会前口径卡：对方诉求、我方目标、讲解提纲（15～20 分钟）、产品版本、报价口径、案例、可披露/不披露清单、问题分工
    • 复盘模板：对方真实诉求、我方表现（时长、讲解、报价、案例）、未答问题、下一步、口径库新增项
    • 统一对外技术答复文档：问题、答复、披露级别、审核人

6. 异常与升级

  • 负责人忘记或无法到场 → B 角接替并录制 → 主负责人当日看纪要并跟进对方
  • 判断为同行套方案 → 只讲公开信息，细节答“数据涉密不便提供”，不给技术文档 → 当天报 CTO
  • 演示链路卡住 → 切换录屏兜底 → 会后 1 个工作日内找演示环境负责人排查
  • 出席人日程冲突 → 改期或改线上，最迟会前 1 天确定
  • 对方当场要价格或承诺 → 按口径卡报公开价，非标价格会后走 SAL-19
  • 对方索要代码或内部文档 → 转 LEG-30 保密审查，不当场给

7. 衡量指标

  • 会前准备达标率 = 有信息卡和口径卡的来访 / 来访总数，目标 ≥ 90%
  • 无人到场或临时找人代听次数：目标 0
  • 书面答复及时率 = 3 个工作日内答复的待答问题 / 待答问题总数，目标 ≥ 90%
  • 复盘完成率 = 完成复盘的来访 / 来访总数，目标 ≥ 90%
  • 首次交流推进率 = 进入试用、报价或协议的来访 / 来访总数，按季度统计

8. 低效诊断

  • 现象：渠道首次交流没有针对性准备，讲了 45 分钟没讲完，渠道政策和报价体系不熟，案例被质疑（会前准备环节缺清单）｜依据：「【模态】教育业务线」2026-01
  • 现象：合作洽谈谁去、以什么职级去临时商量，多人日程排满反复协调（出席指派环节无规则）｜依据：「武汉造风者科技生态合作交流」2026-10、「鼎慧产研决策部」2026-03
  • 现象：会前才发现没开录制总结，会议纪要由谁负责不明确（会议设置环节无默认录制）｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：负责人忘记客户会议，临时在群里找同事代听（提醒与 AB 角缺失）｜依据：「Leap产研测」2026-10
  • 现象：合作洽谈后集成方式、运维归属等问题在群里散聊，没有形成书面结论（会后答复环节缺统一文档）｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 渠道首次交流（如运营商渠道）：重点准备渠道政策、市场价/渠道价；教育类客户会要求看样板间
  • 合作伙伴套壳/集成洽谈：外部会与内部核心成员会分开开；会后明确集成方式（SDK、OAuth2.0、多租户、运维归属）并形成合作条款草案；代理商/集成商合作走开放平台（ECO-06）
  • 生态方来访（光电企业、云厂商生态、芯片厂商）：信创适配口径由 IT 运维（信创/算力口径）统一，算力以客户设备为准
  • 同行带技术问题清单来访：先由 CTO 判断是否套方案，技术同席限时，披露限于公开信息
  • 有真实购买意向的客户请求技术线上旁听：安排技术同席线上参加
  • 线上演示与线下会议：线上默认录制，线下用妙记录音

10. 待确认问题

  • 来访对接主责是否统一为销售/商务？兜底的销售负责人由谁担任？
  • 出席人指派是否必须由 CTO 决定？能否按类型下放（渠道→渠道负责人、生态→生态负责人）？
  • 技术披露分级标准是否需要法务出具？
  • 对外会议默认开启录制+智能纪要，是否作为强制要求？
  • 信息卡提前 2 个工作日提交是否可行？
SAL-09售前技术支撑与技术问题统一答复待优化144

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：销售接待客户或去客户现场需要技术人员同席、演示视频/案例/资质材料，或客户、渠道在售前阶段集中提出技术问题（含私有化、二次开发、源码、海外交付）时启动
  • 负责人：主责——售前技术负责人（当前：丁震宇·推断待确认）；协同——销售对接人（当前：闫登辉、杜中瑞·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、技术同席人员/研发（当前：王皓南、宋祺睿·推断待确认）、材料持有人（当前：刘昱潇、李凯·推断待确认）、法务（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 销售提交售前支撑申请 → ② 判断客户意图与支撑方式 → ③ 排班派人/从资料库取材料 → ④ 客户问题整理成文档 → ⑤ 1 个工作日内出统一书面答复 → ⑥ 敏感口径会审 → ⑦ 答复入 FAQ 库
  • 交付结果：写入日历的技术同席安排、发给客户的标准化技术答复文档、更新后的售前资料库与 FAQ 条目
  • 状态依据：已形成固定做法（销售找技术负责人借人、要材料；技术问题要求对方整理成文档统一书面答复），但无售前资料库、无排班、答复不沉淀，2026-03～09 借人与要材料约 14 次；2026-02 私有化二开/源码问题研发各人当场回答、口径不一

1. 场景判定

  • 触发条件：客户来访或拜访需要技术人员同席；客户/渠道索要演示视频、案例、专利/论文/奖项等资质；渠道或客户一次提出 3 个以上技术问题；客户问私有化能否二开、是否给源码、海外能否交付
  • 典型说法：「私有化本地部署支持二次开发吗」
  • 判断问题：客户此刻要的是“技术人员 / 技术材料 / 技术答复”吗？只是要看产品演示走 SAL-11；只是要价格走 SAL-19
  • 不归本流程管：产品演示准备与执行 → 请走 SAL-11；演示环境与版本稳定 → 请走 SAL-12；对外口径库与对客通知审核 → 请走 SAL-10；方案与报价编制 → 请走 SAL-19；定制需求评估报价 → 请走 SAL-21 / X-PRD-11；对外提供代码、内部材料的保密审查 → 请走 LEG-30；已签约客户的技术问题 → 请走 X-CS-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
售前技术负责人 判断客户真实意图、决定派人和可透露深度、审定书面答复 A/R 售前技术负责人（当前：丁震宇·推断待确认）
销售对接人 提交申请、整理客户问题文档、发送答复、同步行程变更 R 销售（当前：闫登辉、杜中瑞·推断待确认）
技术同席人员 按排班到场或线上答疑，会后补纪要 R 研发工程师（当前：王皓南、宋祺睿·推断待确认）
材料持有人 把演示视频、案例、资质材料补入资料库 R 产品/销售材料负责人（当前：刘昱潇、李凯·推断待确认）
商务负责人 对涉及价格、授权、合同承诺的答复把关 C 市场销售负责人（当前：李鹏为·推断待确认）
法务 审源码、二开授权、出口合规类口径 C 法务（当前：待指定）
研发负责人 技术负责人不在时代为判断与派人 C/I Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 客户基本信息：行业、规模、决策人、预算区间、商机阶段（初访/方案/招投标）
  • 本次诉求：同席 / 材料 / 书面答复；时间、地点、线上或线下
  • 客户问题清单（逐条编号的文档，不接受零散截图）
  • 是否已签保密协议；客户是否只要材料不谈预算（疑似“套方案”）
  • 海外客户：所在国家、交付形态（软件/一体机/云）、是否需要报备

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交售前支撑申请（客户、阶段、预算、诉求、时间） 销售对接人 需要同席的至少提前 1 个工作日 飞书表单 + 多维表格 支撑申请记录 🔧飞书固化
2 判断客户真实意图与商机质量，定派人级别、材料范围、可透露深度 售前技术负责人 收到后 4 个工作小时内 多维表格 支撑决定 👤人工判断
3 排班派人，写入飞书日程；时间地点变更由销售当场改日程 售前技术负责人、销售对接人 决定后 1 小时内；变更即时 飞书日历 同席日程 🔧飞书固化
4 从售前资料库自取案例、视频、专利/资质清单；缺项指定持有人补入库 销售对接人、材料持有人 自取即时；补缺 1 个工作日内 飞书知识库 材料包 🔧飞书固化
5 客户技术问题整理成编号文档，现场不即兴作答 销售对接人 收到问题当天 飞书文档 问题清单 🤖自动化
6 基于 FAQ 库由 AI 生成答复草稿，技术负责人校对定稿 售前技术负责人 收到问题清单后 1 个工作日内 FAQ 库 + AI 书面答复文档 🤖+👤
7 涉及源码、二开授权、SDK、出口、性能承诺的条目送商务、法务会审 商务负责人、法务 2 个工作日内 飞书审批 审定口径 👤人工判断
8 答复发客户；对方坚持面谈则约一次线上答疑会；新问答入 FAQ 库 销售对接人、售前技术负责人 发出当天入库 知识库 FAQ 新条目 🔧飞书固化

5. 交付物与模板

  • 交付物：同席日程、书面技术答复文档、答疑会纪要、FAQ 新增条目
  • 售前支撑申请表字段：客户（内部代号）、行业、商机阶段、预算区间、诉求类型（同席/材料/书面答复/海外交付咨询）、需要时间、地点/线上、销售对接人、是否签 NDA、处理结论、派出人员
  • 售前资料库目录：产品白皮书、分产品演示视频、案例、专利/论文/奖项清单（可外发版）、资质证书、私有化交付说明
  • 技术答复模板：问题编号、问题原文、答复、口径级别（公开/需 NDA/不对外）、答复人、日期
  • 私有化与二开标准口径（分档）：标准私有化不含源码 / 认证+换 Logo 白牌 / 仅开放前端 / 封装 SDK / 源码买断（单独定价 + 法务条款）

6. 异常与升级

  • 当天临时借人且无人可派 → 改为线上接入或提供录屏 → 当场升级售前技术负责人
  • 客户只要材料不谈预算、疑似套方案 → 只给公开版材料，深入问题统一回复“不便透露” → 销售负责人知悉（当天）
  • 客户要求源码、二开、买断 → 现场不承诺 → 2 个工作日内由技术负责人、商务、法务给出结论
  • 海外客户采购 → 不承诺交付形态 → 法务按 LEG-26 确认合规，3 个工作日内回复
  • 渠道合伙人要求绕过销售直接找技术负责人 → 由销售约会议，会后纪要入库，不做单线沟通
  • 书面答复超过 1 个工作日未出 → 销售在支撑表催办 → 升级 Leap 研发负责人

7. 衡量指标

  • 技术答复时效 = 问题清单提交到书面答复发出的工作小时，目标 ≤ 8 小时
  • 资料自取率 = 销售从资料库自取材料次数 / 全部材料需求次数，目标 ≥ 80%
  • FAQ 复用率 = 答复中直接引用 FAQ 的问题数 / 问题总数，半年内目标 ≥ 50%
  • 同席提前量达标率 = 提前 1 个工作日提交的同席申请 / 全部同席申请，目标 ≥ 90%
  • 敏感口径会审率 = 涉及源码/授权/出口的答复经会审比例，目标 100%

8. 低效诊断

  • 现象：借技术人员、要材料靠临时找人，没有申请入口和排班，行程变更不同步，出现现场人员安排混乱（申请与排班环节）｜依据：（推断）
  • 现象：演示视频、专利论文等材料分散在不同人手里，每次都要问“找谁要”（资料调取环节）｜依据：（推断）
  • 现象：私有化是否支持二开、是否给代码，研发当场口头回答且各不相同，没有授权分档口径（口径环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：渠道技术问题若现场口头答复，内容无法复用、口径不标准，同类问题反复回答（答复沉淀环节）｜依据：（推断）
  • 现象：判断客户意图、派人、给材料都集中在一位技术负责人，形成售前单点（角色环节）｜依据：（推断）

9. 分支变体

  • 政府客户（国资监管、数据管理类部门）：先确认预算与需求是否真实，材料使用可外发版本
  • 渠道/生态客户：问题量大，一律书面答复；渠道方问题与最终客户问题分开编号
  • 海外客户：交付方式、出口与报备先过法务，再报价
  • 私有化二开/源码咨询：按“私有化与二开标准口径”分档答复，买断类单独走商务定价
  • 资质材料调用：未公开专利、内部论文先走 LEG-30 审查再外发

10. 待确认问题

  • 售前技术负责人是否继续由 CTO 兼任？是否设专职售前/解决方案岗或按周排班？
  • 书面答复 1 个工作日是否可行？复杂问题是否放宽到 3 个工作日？
  • 私有化二开/源码/SDK 分档口径与定价原则由谁拍板？法务条款是否已有模板？
  • 售前资料库放在哪个知识库空间、由谁维护？是否与 SAL-15 销售知识库合并？
  • 海外客户采购 LeapCore 的交付与合规口径是否已有结论？
SAL-10对外沟通口径统一与对客通知审核待新建225

状态：待新建｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：客户问部署能力、服务可用性、数据安全、Agent 架构、竞品对比、价格与性能承诺，或与硬件/渠道伙伴做商务沟通，或项目侧准备向客户发布使用政策/通知时，按统一口径答复，对客通知先内部审核
  • 负责人：主责——对外口径库负责人/产品总监（当前：杨萌·推断待确认）；协同——价格与合同口径归口：市场销售负责人（当前：李鹏为·推断待确认）、硬件口径归口：IT/硬件负责人（当前：杨明学·推断待确认）、技术事实确认：Leap 研发负责人（当前：王皓南·推断待确认）、一线使用人：COO 及销售（当前：常元和、吴琪、刘昱潇、闫登辉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别对外口径问题 → ② 查口径库 → ③ 无现成口径向归口人申请 → ④ 归口人起草（AI 辅助）→ ⑤ 审定后发布入库 → ⑥ 一线按口径对外 → ⑦ 对客通知走内部审核 → ⑧ 冲突复盘并更新
  • 交付结果：分领域的对外口径库（产品/技术/安全、价格/合同、硬件、故障安抚、竞品对比）、经审核的对客通知、口径冲突复盘记录
  • 状态依据：无话术库与 FAQ，口径每次临时问、临时编；2026-06～07 部署能力、数据安全、Agent 架构口径前后不一约 11 次，2026-05～08 价格与合同口径对不上约 7 次；2026-04 出现项目侧未经内部知会就向客户推行使用政策

1. 场景判定

  • 触发条件：客户问“为什么不能部署/为什么不可用/为什么选我们不选竞品/数据怎么保证安全/属于哪类 Agent”；客户要求价格、性能、效果承诺；与硬件或渠道伙伴谈合作条件；任何人准备以公司名义向客户发政策、规则、限制类通知
  • 典型说法：「现在最好给我个理由和统一口径」「我们到底怎么保证数据安全的」「合同那边口径要从商务负责人那边出」「商务的一定得拉商务负责人聊」「不要自己给客户发通知」
  • 判断问题：这句话发出去后，客户会不会把它当成公司的承诺？会，就走本流程
  • 不归本流程管：品牌用语与发布前合规自查 → 请走 BRD-14；媒体采访口径 → 请走 BRD-12；客服 FAQ 话术与对外信息脱敏 → 请走 X-CS-17；版本更新/停机客户通知 → 请走 X-CS-15；价格体系制定 → 请走 SAL-18；具体报价单 → 请走 SAL-19；售前技术问题书面答复 → 请走 SAL-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
口径库负责人 维护口径库目录、受理口径申请、组织起草与发布 A/R 产品总监（当前：杨萌·推断待确认）
价格与合同口径归口 定价格、折扣、渠道政策、合同承诺口径；商务沟通收口 R 市场销售负责人（当前：李鹏为·推断待确认）
硬件口径归口 确认硬件配置、交付形态、合同硬件条款 R IT/硬件负责人（当前：杨明学·推断待确认）
技术事实确认 确认部署、安全、架构、性能的真实能力边界 C Leap 研发负责人（当前：王皓南·推断待确认）
口径审定 审定高风险口径（安全、性能、业绩数据），裁决冲突 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
一线使用人 按口径对外；遇到库外问题先申请再答复 R COO 及销售（当前：常元和、吴琪、刘昱潇、闫登辉·推断待确认）
项目对接人 对客通知起草与提交审核 R 项目负责人（当前：待指定）

3. 办之前请准备

  • 客户原话或截图、提问场景（售前/交付中/故障中）
  • 已有相关口径（口径库检索结果、最新白皮书与对外介绍材料版本）
  • 涉及价格或承诺的：客户预算、竞品报价、拟承诺的效果指标
  • 对客通知：通知正文、发送对象、生效时间、对客户的影响、替代方案

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 先在口径库检索，命中则直接使用最新版 一线使用人 即时 飞书知识库 + 问答机器人 引用口径 🤖自动化
2 未命中则提交口径申请（问题、场景、截止时间） 一线使用人 发现当天 飞书表单 口径申请 🔧飞书固化
3 按领域分派：价格/合同 → 商务；硬件 → 硬件；技术/安全 → 研发确认事实 口径库负责人 收到后 2 个工作小时内 多维表格 分派记录 🔧飞书固化
4 AI 起草，归口人改定；只写可兑现的事实，不写套话 归口人 普通 1 个工作日；客户在等的故障安抚 2 小时内 AI + 飞书文档 口径草稿 🤖+👤
5 安全、性能、业绩数据、竞品对比类口径送 CTO 审定 口径审定人 1 个工作日内 飞书审批 审定口径 👤人工判断
6 发布入库，标注版本、适用场景、失效条件，群内通知 口径库负责人 审定当天 知识库 + 通知群 口径条目 🔧飞书固化
7 对客通知（使用政策、限制、强制要求）提交审核，产品、研发、商务会签后才能发 项目对接人 计划发送前 1 个工作日 飞书审批 已审核通知 🔧飞书固化
8 出现口径冲突（同一问题不同人说法不同）24 小时内复盘，更新口径并告知全员 口径库负责人 发现后 1 个工作日内 飞书文档 冲突复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：对外口径库、对客通知审批记录、口径冲突复盘记录
  • 口径条目字段：编号、领域（产品/技术/安全/价格/合同/硬件/故障安抚/竞品对比）、问题、标准答复、禁止说法、适用场景、归口人、审定人、版本、生效日期、失效条件
  • 对客通知审批表字段：通知标题、正文、发送对象、生效时间、客户影响、替代方案、发起人、会签人（产品/研发/商务）
  • 故障安抚模板：现象说明、影响范围、预计恢复时间、临时替代方案、后续补偿口径（如有）

6. 异常与升级

  • 客户正在等答复且口径库没有 → 先回复“正在确认，X 点前答复”，2 小时内归口人给临时口径 → 超时升级 CTO
  • 商务与技术说法冲突（如收入预期、性能效果）→ 停止对外再说 → 当天由 CTO 裁决
  • 合同或报价已按非统一口径发出 → 商务负责人评估是否需补充说明或补充协议 → 2 个工作日内处理
  • 发现有人未经审核向客户发政策/通知 → 口径库负责人当天通知客户侧对接人纠正 → 升级 CTO 与该人所属部门负责人
  • 硬件相关承诺未经硬件归口确认 → 暂停推进 → 1 个工作日内补确认

7. 衡量指标

  • 口径库命中率 = 直接引用口径库答复的次数 / 对外口径问题总数，半年目标 ≥ 70%
  • 口径响应时效 = 口径申请到发布的工作小时，目标 ≤ 8 小时（故障安抚 ≤ 2 小时）
  • 口径冲突次数 = 每月发现的同题不同答次数，目标逐月下降至 0
  • 对客通知审核率 = 经审批发出的对客通知 / 全部对客通知，目标 100%

8. 低效诊断

  • 现象：部署能力、服务不可用原因、为何选我们等问题每次临时请教、临时编写，事后被指出前后口径不一（口径来源环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：数据安全、Agent 架构类问题无 FAQ，销售“实话实说”与“夸大宣传”冲突，AI 起草的宣传稿被认为是套话（审定环节）｜依据：「鼎慧产研决策部」2026-07
  • 现象：试用合同金额与行业版溢价由销售自行处理，事后才发现未与商务口径对齐（价格口径环节）｜依据：「Leapcore某工程咨询客户」2026-07、「Leapcore某工程咨询客户」2026-08
  • 现象：直接报价未先讲价值，客户预算与方案落差大（报价话术环节）｜依据：「某半导体客户」2026-05
  • 现象：与硬件/渠道伙伴沟通无统一收口人，合作方反馈“口径太乱”，合同硬件部分无人审过（商务收口环节）｜依据：「leapcore市场对接」2026-05、「LeapCore（archived）」2026-06
  • 现象：项目侧单方面要求客户只用某产品，研发和产品事后才知道（对客通知环节）｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 产品/技术/安全口径：由研发确认事实，CTO 审定，禁止承诺未上线能力
  • 价格与合同口径：只从商务负责人出；先讲价值/ROI 再报价；行业版需写明溢价与功能清单
  • 硬件伙伴与渠道商务沟通：商务事项必须有商务负责人参与，硬件事项先经硬件归口确认
  • 故障安抚：用故障安抚模板，2 小时内出口径
  • 竞品对比：只用实测对比结果，引用 SAL-15 对比素材
  • 对客通知：任何政策、限制类通知先审批后发送

10. 待确认问题

  • 口径库主责是否为产品总监？还是由生态市场条线（对外资料与 FAQ）统一维护？
  • 价格口径“只从商务负责人出”是否已成文？行业版溢价规则由谁定？
  • 聊天中提到对客户效果表述可“包装到 120%～150%”，是否作为规则？如何与“不夸大宣传”原则统一？
  • 对客通知会签人是否固定为产品、研发、商务三方？时限 1 个工作日是否可行？
  • 安全、业绩数据类口径是否需要 CEO 或 COO 也参与审定？
SAL-11客户演示准备与执行待优化500

状态：待优化｜证据：有证据（卡片 15 张 / 会话 10 个）｜优先级：频5 × 耗5 × 跨5 × 险4

  • 适用场景：客户、渠道、政府/评审机构、领导或资本方要看产品演示（现场或远程）时，从接到演示需求到演示后反馈收集全程按本流程走
  • 负责人：主责——演示统筹人/产品总监（当前：杨萌·推断待确认）；协同——演示申请人/销售及 COO（当前：闫登辉、吴琪、常元和·推断待确认）、技术保障（当前：王皓南、宋祺睿·推断待确认）、测试验证（当前：张东郅·推断待确认）、演示视频制作（当前：杨黔昆·推断待确认）、演示账号安排（当前：李凯·推断待确认）、场景案例梳理（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交演示申请 → ② 定演示人、操作人、技术保障 → ③ 选场景写脚本 → ④ 环境、账号、额度就绪（SAL-12/13）→ ⑤ 按脚本内部预演并录兜底视频 → ⑥ 现场演示 → ⑦ 1 个工作日内登记反馈并复盘
  • 交付结果：演示申请记录、演示脚本与话术、兜底录屏、演示反馈登记（转需求/商机跟进）
  • 状态依据：已有《LeapCore+MercAll 通用演示流程》文档（演示前准备与话术），但 2026-01～09 演示几乎都是前一天才通知、临时定演示人、临时跑通，演示前通宵赶包、现场翻车、演示人不熟悉产品等反复出现约 90 次

1. 场景判定

  • 触发条件：任何对外演示需求——客户来访/拜访、渠道或 OEM 合作洽谈、政府/评审答辩、领导临时要看、资本方或媒体、学校企业试用前演示、重点客户迭代 Demo 展示
  • 典型说法：「明天给谁演示」「明天要演示 LeapCore，这次效果直接影响能不能出货」「谁给我录个屏，明天我要现场演示」「下午演示要登录我自己的号吗」「领导不知道啥时候就要看」
  • 判断问题：是不是要让外部的人看到产品运行效果？是，就走本流程；只要材料或技术答复走 SAL-09
  • 不归本流程管：演示环境、版本冻结与兜底机 → 请走 SAL-12；演示账号、演示机借用 → 请走 SAL-13；定制 Demo 开发 → 请走 SAL-14；展会/大会/发布会现场演示 → 请走 MKT-05；客户来访接待 → 请走 MKT-10 / SAL-08；投标演示视频 → 请走 SAL-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示统筹人 受理申请、定演示人与场景、维护演示脚本库、组织预演和复盘 A/R 产品总监（当前：杨萌·推断待确认）
演示申请人 提交申请、说明客户目的与关注点、会后登记反馈 R 销售及 COO（当前：闫登辉、吴琪、常元和·推断待确认）
演示人 按脚本演示，事先完成培训与预演 R 销售或产品（按排定，当前：待指定）
技术保障 准备演示包/skill、现场或线上技术兜底、应对对方技术提问 R 研发（当前：王皓南、宋祺睿·推断待确认）
测试验证 按脚本跑一遍并确认可演示 R 测试负责人（当前：张东郅·推断待确认）
视频与素材 录兜底视频、截图、演示案例素材 R 产品运营（当前：杨黔昆·推断待确认）
场景案例 梳理客户行业场景并在产品中预跑 C 业务专家（当前：王满·推断待确认）
账号额度 安排演示账号与额度 C 账号安排人（当前：李凯·推断待确认）
审批/兜底 不足 1 个工作日的紧急演示批准、关键演示取舍 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 演示对象与目的：客户/渠道/政府/领导/资本方，想看什么、决策点是什么、会议性质（演示还是意向交流）
  • 时间、地点、现场/远程、对方是否自带设备
  • 想演示的产品与版本、客户行业场景、竞品对比需求
  • 是否需要消耗与成果数据、报价、讲稿
  • 客户可提供的测试材料（不得使用客户真实敏感文件做公开演示）
  • 请求最少包含字段：演示对象类型与内部代号、目的与决策点、会议性质（演示/意向交流）、日期时间、地点或远程方式、产品与版本、期望场景、对方人数与角色、是否需讲稿/报价/消耗数据、申请人岗位；缺任一项演示统筹人退回补齐，不另行追问

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交演示申请（对象、目的、时间、地点、产品、场景、会议性质） 演示申请人 至少提前 2 个工作日；不足 1 个工作日需 CTO 批准 飞书表单 → 演示日历 演示申请（落演示日历 + 演示台账，群内只发链接）；超时未受理→演示统筹人 🔧飞书固化
2 定演示人、操作人、技术保障；演示人未培训过的产品不得独立演示 演示统筹人 收到后 4 个工作小时内 多维表格 人员安排（写入演示台账并 @ 到人，被指派人 2 个工作小时内确认） 👤人工判断
3 从脚本库选场景（2～3 个出结果快、5～10 秒内见效、中文名称的 skill），AI 生成话术，统筹人审定 演示统筹人 演示前 2 个工作日 演示脚本库 + AI 演示脚本与话术（存演示脚本库，台账挂链接） 🤖+👤
4 按 SAL-12/13 申请演示环境、账号、额度；按通用演示流程准备数据（网盘数据、Skills、演示群与机器人、用量统计） 演示统筹人、技术保障 演示前 1 个工作日 12:00 前 演示环境台账 就绪的环境与账号（演示环境台账标“就绪”，凭据走密码库不贴群）；超时→技术保障负责人，再超 2 小时→CTO 🔧飞书固化
5 按脚本完整预演一遍，测试确认；同步录兜底视频（本地可播放） 演示人、测试验证、视频与素材 演示前 1 个工作日 18:00 前 测试环境 + 录屏 预演记录（台账勾选“预演通过”）、兜底视频（演示素材库，台账挂链接） 🔧+👤
6 现场演示：只演预演过的流程；出错新开对话，不点停止，标准模式优先；不稳定即切视频 演示人、技术保障 演示当时 演示环境 演示完成（台账状态改“已演示”） 👤人工判断
7 登记客户反馈、追问、需求和下一步，转商机跟进或需求池 演示申请人 演示后 1 个工作日内 多维表格 / CRM 反馈记录（CRM 商机页；产品需求转 X-PRD-05 需求池并回填需求编号）；超时→演示统筹人催办 🔧飞书固化
8 翻车或重要演示复盘，更新脚本库和禁忌清单 演示统筹人 演示后 2 个工作日内 飞书文档 复盘记录（演示脚本库“复盘与禁忌”页） 👤人工判断

5. 交付物与模板

  • 交付物：演示申请、演示脚本与话术、预演记录、兜底视频、演示反馈记录、复盘记录
  • 演示申请表字段：演示对象类型、对象名称（内部代号）、目的与决策点、会议性质、时间、地点/远程、产品与版本、场景、演示人、操作人、技术保障、是否需讲稿/报价/消耗数据、申请人
  • 演示脚本模板：场景名称、客户痛点、操作步骤、预期结果与时长、话术要点、禁忌与已知问题、兜底视频链接
  • 演示前检查单（引自通用演示流程）：网盘数据已填充、容器与模型在线、Skills 数量与演示用 skill 就绪、演示群与机器人已建、管理面板用量统计可看、账号余额充足、设备登录状态正常
  • 反馈记录字段：客户反馈、追问、答不上的问题、需求、下一步、负责人

6. 异常与升级

  • 前一天才提出（不足 1 个工作日）的演示，或关键客户演示需要取舍资源 → 统筹人评估能否保障 → 决定权由演示统筹人升级至 CTO，CTO 当场拍板保障、改视频演示或改期
  • 预演不通过 → 当天工作时间内修复或换场景 → 演示当天开场前 2 小时仍不通过，改用兜底视频
  • 演示现场崩溃 → 技术保障 5 分钟内远程排查，演示人切兜底视频 → 会后 1 个工作日内复盘
  • 演示人临时无法到场 → 统筹人指定已培训的替补 → 无替补则改线上或改期
  • 演示需要的能力未上线 → 只演已上线功能，未上线功能用视频说明“规划中”，不承诺时间
  • 申请提交后 4 个工作小时无人受理、或环境/账号到演示前 1 个工作日 12:00 未就绪 → 申请人在演示台账标“卡住”并 @ 演示统筹人 → 2 小时内无回应升级 CTO，由 CTO 指定保障人或改期
  • 演示后 1 个工作日未登记反馈 → 演示统筹人催办一次 → 第 2 个工作日仍未登记，通报市场销售负责人

7. 衡量指标

  • 演示提前量达标率 = 提前 2 个工作日提交的演示申请 / 全部演示，目标 ≥ 80%
  • 演示成功率 = 无需中断或切视频完成的演示 / 全部演示，目标 ≥ 90%
  • 预演执行率 = 演示前完成预演的场次 / 全部场次，目标 100%
  • 反馈登记率 = 1 个工作日内登记反馈的演示 / 全部演示，目标 100%
  • 演示前加班场次 = 每月因演示加急到 22 点后的次数，目标逐月下降

8. 低效诊断

  • 现象：演示需求前一晚才通知，研发连夜赶包、修 bug、做视频，演示当天仍出新错（申请提前量环节）｜依据：「Leap产研测」2026-05、「鼎慧产研决策部」2026-05
  • 现象：演示人、操作人、讲稿都在演示前临时问，会议性质要追问才知道（人员安排环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：演示人未培训、不熟悉产品，前一晚才找人录屏教学；能力边界口径不统一（演示人准备环节）｜依据：「跃迁基座项目交付沟通」2026-03
  • 现象：演示 PPT 和内容反复推翻，演示前不确定产品能否演示，最终翻车（脚本环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：演示用 skill 提示词太长、任务太慢需重选，测试环境不稳定（场景选择环节）｜依据：「LeapAll（Deprecated）」2026-04
  • 现象：演示后客户反馈靠追问、忘记发，未进需求池（反馈环节）｜依据：「某政企客户需求对接群」2026-01
  • 现象：行业版演示要的消耗与成果数据依赖未定的倍率，演示时间反复被追问（数据准备环节）｜依据：「【行业版Leapcore】工程版」2026-07
  • 现象：录屏兜底规则只停留在口头强调（兜底环节）｜依据：「跃迁AI总动员」2026-09

9. 分支变体

  • 渠道/OEM 预装伙伴：突出自研能力与差异点，演示后跟进出货量，素材侧重视频与营销文案
  • 政府/评审答辩：需讲稿、报价、固定演示数据账号；先确认是演示还是意向交流
  • 行业版演示：需预装行业 skill，附消耗与成果清单（倍率未定时注明“测试口径”）
  • 领导随时查看：使用常开、每日检查的稳定环境（见 SAL-12）
  • 学校/企业试用前演示：由已培训的商务演示，演示后转 SAL-16
  • 重点客户迭代 Demo：录制使用流程视频发客户，反馈 1 个工作日内登记
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 演示统筹人是否为产品总监？还是由市场（演示场景、视频）统筹、产研支持？
  • 提前 2 个工作日的申请时限是否可行？紧急演示的审批人是否为 CTO？
  • 《通用演示流程》文档是否作为正式演示脚本库的起点？由谁维护更新？
  • Agent 产品对外演示是否一律以录屏为主、实机为辅？
  • 演示反馈登记到 CRM 还是需求池，还是两边都登？
SAL-12演示环境与版本保障（冻结/稳定版/兜底）待新建256

状态：待新建｜证据：有证据（卡片 12 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨4 × 险4

  • 适用场景：已确定对外演示（客户现场、远程、发布会、云栖类大会、资本方）后，指定演示环境与稳定版本、在演示窗口冻结更新、准备备用机与网络兜底，演示失败时排查复盘
  • 负责人：主责——演示环境负责人/产品总监（当前：杨萌·推断待确认）；协同——研发发版负责人（当前：王皓南·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、客户端与 hotfix（当前：岳阳、马漳毓·推断待确认）、测试（当前：张东郅·推断待确认）、演示机管理（当前：游家豪·推断待确认）、IT 网络与备机（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 演示登记入演示日历 → ② 指定专用演示机/稳定版 → ③ 冻结窗口生效、发版避让 → ④ 推送已知问题与禁用功能 → ⑤ 演示前冒烟检查 → ⑥ 兜底就绪（录屏、备用机、随身网络）→ ⑦ 演示中故障应急 → ⑧ 解冻与复盘
  • 交付结果：演示日历与冻结记录、演示前冒烟检查结果、已知问题清单、兜底包（视频/备用机/网络）、演示事故复盘
  • 状态依据：2026-09 已明确“10 楼专用演示机用于所有演示”、公司 102 环境仅内部使用，但仍无演示登记、冻结窗口和自检；2026-06～09 至少 5 次演示当场失败（发布会周环境闪退、图片生成失败、证书过期两场演示失败、新版更新后服务崩溃），多次靠群通知“暂停对外演示”

1. 场景判定

  • 触发条件：演示日历出现对外演示；需要外出演示（飞连/随身 WiFi）；内部要发版、OTA、重启或迁移且可能影响演示环境；公司环境故障；客户要求换 Logo、切模型后演示
  • 典型说法：「先别发，有演示，等通知」「在外出演示，暂时不要更新测试服」「明天去企业做演示，新版会有问题吗」「演示环境下午四点应该稳吧」「公司环境出现故障，大家暂时不要使用产品演示」
  • 判断问题：这次演示依赖的环境，在演示时段会不会被别人改动或升级？会，就要登记冻结
  • 不归本流程管：演示内容、脚本与执行 → 请走 SAL-11；演示账号、演示机借用登记 → 请走 SAL-13 / X-DLV-05；研发侧冻结执行与环境技术准备 → 请走 RND-61；展会大会现场设备 → 请走 MKT-05 / X-DLV-06；线上故障处置 → 请走 RND-75；hotfix 发布 → 请走 RND-54；演示服务器暴露面检查 → 请走 X-SEC-38；远程接入 → 请走 X-SEC-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示环境负责人 维护演示日历与环境清单、批准冻结、发布演示限制通知 A/R 产品总监（当前：杨萌·推断待确认）
研发发版负责人 发版前查演示日历，冻结窗口内暂停发版 R Leap 研发负责人（当前：王皓南·推断待确认）
运维/发版 演示环境部署、演示链接与管理后台维护、服务状态检查 R 后端/运维（当前：宋祺睿·推断待确认）
客户端与 hotfix 演示前已知问题说明，故障紧急修复 R 客户端研发（当前：岳阳、马漳毓·推断待确认）
测试 演示前冒烟与稳定性测试 R 测试负责人（当前：张东郅·推断待确认）
演示机管理 专用演示机与备用机在线、版本、额度 R 运维/交付部署工程师（当前：游家豪·推断待确认）
IT 网络 内网/外网访问、随身网络、证书 C IT 运维（当前：杨明学·推断待确认）
演示人 登记演示、执行冒烟、反馈问题 R 销售/市场（当前：待指定）

3. 办之前请准备

  • 演示时间段（含前后各 2 小时缓冲）、地点、现场/远程
  • 演示用环境：专用演示机编号或云端地址、版本号、使用的模型档位
  • 需要演示的功能清单（便于对照已知问题）
  • 外出演示：网络方式（飞连/随身 WiFi/客户网络）、备用机
  • 换 Logo、切模型等配置需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在演示日历登记演示（时间段、环境、版本、功能、演示人） 演示人 至少提前 1 个工作日 飞书日历 / 多维表格 演示登记 🔧飞书固化
2 指定环境：对外一律用专用演示机或稳定版，不用公司内测环境和测试服 演示环境负责人 登记后 2 个工作小时内 演示环境清单 指定环境 👤人工判断
3 冻结窗口生效：发版、OTA、重启、迁移前查日历，冲突即顺延 研发发版负责人、运维 演示前 12 小时至演示结束 发版流程闸门 + 机器人提醒 冻结记录 🔧+🤖
4 推送当前已知问题与禁用功能、建议模型档位（标准模式优先） 客户端与 hotfix 演示前 1 个工作日 18:00 前 已知问题文档 已知问题清单 🤖自动化
5 冒烟检查：版本、服务状态、证书、网络、额度、模型、演示数据、管理后台链接 演示人 + 测试 演示前 2 小时 自动检查机器人 + 检查单 冒烟结果 🤖+👤
6 兜底就绪：本地可播放的录屏、备用演示机、随身网络 演示人、演示机管理 演示前 1 个工作日 演示机台账 兜底包 🔧飞书固化
7 演示中故障：演示人切兜底，技术保障 10 分钟内响应；公司环境故障 30 分钟内群发暂停演示通知 运维、演示环境负责人 即时 市场销售通知群 故障通知 👤人工判断
8 演示结束解冻；如出故障 2 个工作日内复盘并区分网络问题与产品缺陷 演示环境负责人 演示后 2 个工作日内 飞书文档 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：演示日历、演示环境清单、冻结记录、冒烟检查结果、已知问题清单、复盘记录
  • 演示环境清单字段：环境名称、类型（专用演示机/云端演示/内测）、地址（不含凭据）、当前版本、模型档位、负责人、对外可用状态、最近冒烟时间
  • 冒烟检查单：版本号与预期一致、服务健康、证书有效期、网络连通（含远程接入）、账号可登录、额度充足、演示数据完整、核心流程跑通、兜底视频可播放
  • 已知问题文档字段：问题、影响功能、规避方式、预计修复时间、更新时间

6. 异常与升级

  • 冻结窗口内必须发版（安全或严重故障）→ 研发发版负责人通知演示人并给替代方案 → CTO 批准
  • 冒烟不通过 → 换备用机或切视频 → 演示前 1 小时仍不通过，演示人决定改期或纯视频
  • 公司环境整体故障 → 30 分钟内通知群发布“暂停对外演示”及恢复预估 → 恢复后再发解除通知
  • 证书、域名过期导致演示失败 → 当场修复 → 按 X-SEC-21 补到期监控
  • 演示机离线、归属不清 → 演示机管理 30 分钟内定位 → 无法定位升级演示环境负责人

7. 衡量指标

  • 演示环境事故数 = 每月因环境/版本导致的演示失败次数，目标 0
  • 演示登记率 = 登记入演示日历的对外演示 / 全部对外演示，目标 100%
  • 冻结违规次数 = 冻结窗口内未经批准的发版/变更次数，目标 0
  • 冒烟执行率 = 演示前完成冒烟的场次 / 全部场次，目标 100%
  • 故障通知时效 = 环境故障发生到通知群发布暂停演示的分钟数，目标 ≤ 30 分钟

8. 低效诊断

  • 现象：发布会周要求不动环境只靠口头提醒，演示当天才发现严重 bug，事后才 hotfix 和复盘（冻结环节）｜依据：「Leap产研测」2026-06
  • 现象：前线问“新版会不会影响明天演示”，只得到口头保证，演示时功能失败（版本确认环节）｜依据：「Leap产研测」2026-07
  • 现象：演示机在谁那、谁申请、用哪个版本不清楚，演示前一天才确认方案（环境指定环节）｜依据：「Leap产研测」2026-08
  • 现象：外出演示期间测试服照常更新，演示失败后才排查（发版避让环节）｜依据：「Leap产研测」2026-09
  • 现象：演示者不知道当前已知故障和限制，靠个人经验选模型档位，外出时远程接入连不上（已知问题环节）｜依据：「Leap反馈群」2026-07
  • 现象：证书过期与服务异常导致两场演示失败，演示机离线现场才发现（冒烟检查环节）｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：内部升级后演示环境崩溃，通知晚于演示，演示者演示挂了才得知（故障通知环节）｜依据：「模态跃迁通知群」2026-08、「Leap市场销售通知群」2026-09
  • 现象：演示专用账号和稳定 API 渠道迟迟未落实，演示前两个环境都卡住（兜底环节）｜依据：「LeapPPT」2026-05
  • 现象：演示机切模型、换 Logo 靠手动，管理后台搬迁漏迁（配置切换环节）｜依据：「Leap产研决策部」2026-08、「Leap产研决策部」2026-09
  • 现象：演示需求靠转发聊天，开发准备了不存在的演示（需求传递环节）｜依据：「工程咨询产研」2026-07

9. 分支变体

  • 公司内部环境：仅内部日常与内测，对外演示禁用
  • 专用演示机：所有对外演示默认使用，节前/版本切换后由演示环境负责人维护演示数据
  • 外出/远程演示：飞连或随身 WiFi + 备用机 + 本地视频三重兜底
  • 客户测试机作为测试服：装 skill 与后续 OTA 由研发按交付流程执行（参见 X-DLV-27），演示前同样登记冻结
  • 换 Logo/切模型：使用配置下发或切换脚本，演示前 1 个工作日完成并冒烟
  • 交付前稳定性确认：交付前同样执行步骤 4～5
  • 大会/发布会：走 MKT-05，冻结规则同本流程

10. 待确认问题

  • 演示环境负责人是否为产品总监？专用演示机日常维护是否由运维/交付工程师负责？
  • 冻结窗口“演示前 12 小时至结束”是否合适？哪些情况允许打断冻结、由谁批准？
  • 是否开发演示前自动冒烟机器人（版本、服务、证书、网络、额度）？由谁开发？
  • 发版流程是否接入演示日历作为闸门？与 RND-61 的分工如何界定？
  • 专用演示机数量是否满足同时段多场演示？是否需要预约机制？
SAL-13演示账号与演示机管理待新建144

状态：待新建｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：销售、市场、渠道需要演示账号、演示额度/积分券、Demo 访问权限，或借用演示机/样机给客户演示试看时，按申请→分配→登记→回收管理，不暴露管理权限
  • 负责人：主责——演示资源管理员（当前：闫登辉·推断待确认）；协同——对外演示产品清单维护：产品总监（当前：杨萌·推断待确认）、演示机硬件与在线状态：运维/交付部署工程师（当前：游家豪·推断待确认）、备机与内网接入：IT 运维（当前：杨明学·推断待确认）、演示页/后台账号：后端/运维（当前：宋祺睿·推断待确认）、演示站维护：基座研发负责人（当前：望政韬·推断待确认）、Demo 能否公开确认：苏州销售负责人（当前：刘昱潇·推断待确认）、积分券管理（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交借用/开通申请 → ② 审核用途与权限级别 → ③ 从账号池/演示机台账分配（演示角色，不给管理员）→ ④ 凭据经安全渠道私发并登记 → ⑤ 额度/券按标准发放登记 → ⑥ 到期回收、改密、重置数据 → ⑦ 每月盘点台账
  • 交付结果：演示账号池与演示机台账（编号、持有人、版本、额度、在线状态、借用记录）、对外演示产品清单（可对外/仅内部/需脱敏）
  • 状态依据：已有账号管理表格和对外演示产品清单，但 2026-04～10 出现客户项目环境被内部借用演示导致数据混乱、现场找不到可用演示账号只能借个人账号、演示机开给谁无人知晓且密码无人掌握、讨论只读演示账号 20 余轮等问题约 6 起，均为事后补规则

1. 场景判定

  • 触发条件：需要给客户看产品但没有可用账号；出差地推、评审需要演示额度或积分券；需要借演示机/样机；演示 Demo 是否可对外不确定；演示结束需要回收
  • 典型说法：「谁那边有案例的账号密码，我在给客户演示」「不能直接给他们管理员账号」「明天要做产品演示，可以给我一个可用账号吗」「那台 1 号演示机是谁开给客户的」「我在理公司对外演示产品的表格」
  • 判断问题：要的是“演示用”的账号/机器/额度，而不是客户自己正式使用或试用？是，就走本流程
  • 不归本流程管：演示环境版本稳定与冻结 → 请走 SAL-12；客户试用账号与试用额度 → 请走 SAL-16；正式账号开通 → 请走 X-CS-02；研发测试账号额度 → 请走 RND-47；赠送客户额度 → 请走 SAL-17 / FIN-16；样机外借出库（交付侧）→ 请走 X-DLV-05 / MKT-11；凭据保管规范 → 请走 X-SEC-10；客户索要管理员/远程权限 → 请走 X-SEC-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示资源管理员 维护账号池与演示机台账、审核申请、分配与回收 A/R 演示资源管理员（当前：闫登辉·推断待确认）
对外演示产品清单维护 维护哪些 Demo 可对外、仅内部或需脱敏 R 产品总监（当前：杨萌·推断待确认）
演示机管理 演示机备机、贴牌、版本、在线状态 R 运维/交付部署工程师（当前：游家豪·推断待确认）
IT 运维 备机、内网接入、随身路由 C IT 运维（当前：杨明学·推断待确认）
演示页/后台 只读演示页、演示角色、脱敏数据 R 后端/运维（当前：宋祺睿·推断待确认）
演示站维护 共享演示站账号与脱敏数据 R 基座研发负责人（当前：望政韬·推断待确认）
公开性确认 判定带客户名称的 Demo 能否对外、能否录屏 C 苏州销售负责人（当前：刘昱潇·推断待确认）
积分券管理 演示用券的发放与已录入商城卡密保护 R 积分券管理员（当前：待指定）
申请人 按用途申请、按期归还、不转借 R 销售/市场/渠道人员

3. 办之前请准备

  • 演示产品与版本、演示对象、演示时间与时长
  • 需要的资源：账号（几个、什么角色）、额度/券数量、演示机（是否贴渠道 Logo、是否接内网、是否需随身路由）
  • 是否会展示客户名称或客户数据（决定是否需脱敏版）
  • 预计归还日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交演示资源申请（产品、用途、对象、资源类型与数量、归还日） 申请人 至少提前 1 个工作日 飞书审批 申请单 🔧飞书固化
2 审核用途与权限级别：只给演示角色或只读/前端演示页，不给管理员；带客户名称的 Demo 先确认公开性 演示资源管理员、公开性确认 收到后 4 个工作小时内 对外演示产品清单 审核结论 👤人工判断
3 从账号池或演示机台账分配；客户项目环境一律不得借用 演示资源管理员、演示机管理 审核通过后 2 个工作小时内 多维表格台账 分配记录 🔧飞书固化
4 凭据通过密码管理工具或私信发送，登记“谁、何时、哪台、到期日”，禁止群内明文 演示资源管理员 分配同时 密码管理工具 凭据发放记录 🔧飞书固化
5 演示额度或积分券按标准发放，从演示券池出，不动已录入商城的卡密 积分券管理员 审核通过后 2 个工作小时内 商城后台 + 台账 额度发放记录 🤖自动化
6 到期提醒并回收：收回演示机、改密、重置演示数据、收回剩余额度 演示资源管理员 到期当天提醒；到期后 1 个工作日内完成 机器人提醒 回收记录 🔧+🤖
7 每月盘点：账号池、演示机在线状态与持有人、额度消耗 演示资源管理员 每月第 1 个工作日 多维表格 盘点结果 🤖自动化

5. 交付物与模板

  • 交付物：演示账号池、演示机台账、对外演示产品清单、申请与回收记录、月度盘点结果
  • 演示机台账字段：编号、型号、贴牌、存放位置、当前持有人、借用对象（内部/客户代号）、版本、模型档位、额度余额、在线状态、借出日、应还日、管理人
  • 演示账号池字段：产品、账号标识（不含密码）、角色（演示/只读/前端 mock）、预置案例数据、当前使用人、到期日、上次重置时间
  • 对外演示产品清单字段：Demo 名称、链接、可见级别（可对外/仅内部/需脱敏）、是否可录屏、负责人、更新日期

6. 异常与升级

  • 现场找不到可用账号 → 申请人先放演示视频 → 演示资源管理员 30 分钟内提供账号池账号 → 无可用则升级 CTO
  • 发现演示机归属不明、密码无人知 → 当天由运维/交付工程师核查并重置 → 补登记，升级演示资源管理员
  • 客户项目环境被内部借用 → 立即停止使用、改密 → 当天通知客户对接人并评估影响，升级 CTO
  • 凭据在群内明文发送 → 当天改密、撤回消息 → 按 X-SEC-11 处理
  • 演示机超期未还 → 到期后 2 个工作日内催还 → 仍未还，升级申请人所属负责人
  • 额度被充错或用错 → 1 个工作日内核对冲正，记录原因

7. 衡量指标

  • 演示资源台账完整率 = 有持有人、到期日、在线状态的演示机与账号 / 全部，目标 100%
  • 演示资源响应时效 = 申请提交到资源分配完成的工作小时，目标 ≤ 4 小时
  • 超期未回收数 = 超过应还日 2 个工作日未回收的账号/演示机数量，目标 0
  • 凭据明文暴露次数 = 群内出现演示账号密码的次数，目标 0
  • 借用个人或客户账号演示次数，目标 0

8. 低效诊断

  • 现象：只读演示账号需求讨论约 20 轮，最终临时做前端 mock 演示页并多次催办（演示账号设计环节）｜依据：「鼎慧产研决策部」2026-07
  • 现象：客户项目环境被多人借来演示，测试文件和图谱混乱并打扰客户汇报，事后才隔离（环境借用环节）｜依据：「跃迁基座项目交付沟通」2026-06
  • 现象：演示机开给客户使用无订单无登记，密码无人知道，客户等待一周多（台账登记环节）｜依据：「武汉造风者科技生态合作交流」2026-10
  • 现象：现场演示前才找带案例的账号，借用业务同事个人账号，验证码登录反复失败，账号在群内流转（账号池环节）｜依据：「字字可研项目群」2026-04
  • 现象：哪些 Demo 能对外、需要脱敏的资料和提示词由谁做、演示机需求提给谁都不清楚（公开性与需求入口环节）｜依据：「某半导体客户」2026-05、「某半导体客户」2026-06
  • 现象：演示额度和积分券每次手动要，发券人不唯一（额度发放环节）｜依据：（推断）

9. 分支变体

  • LeapCore：优先使用专用演示机与演示角色账号；内网演示需远程接入
  • 字字可研：固定演示账号 + 预置案例项目，申请验证码豁免或专用演示环境
  • 研究院/渠道演示机：可贴渠道或研究院 Logo，接内网，配随身路由，纯演示用途
  • 出差地推、评审会：从演示券池发放有效期额度，演示后回收剩余额度
  • 共享演示站：只传脱敏资料，各人使用独立账号

10. 待确认问题

  • 演示资源管理员是否由渠道/CRM 管理员兼任？还是由市场部（样机管理）统一管理？
  • 是否采购或指定密码管理工具，替代群内或表格存放密码？
  • 演示券池额度标准（每次多少、有效期多久）由谁定？发券人是否唯一？
  • 字字可研演示账号能否在等保要求下豁免短信验证码？
  • 与 X-DLV-05、MKT-11 的演示机管理边界如何划分（销售借用 vs 交付出库）？
SAL-14售前 Demo/样稿制作与客户需求转产研待新建144

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨4 × 险3

  • 适用场景：意向客户要定制 Demo、接口集成演示、竞品 PK 样稿，或销售需要产研配合做售前交付物时，经统一入口（先找产品）提交，评估后优先复用已有能力，限期交付
  • 负责人：主责——售前需求入口/产品总监（当前：杨萌·推断待确认）；协同——售前需求方（当前：侯明月、刘昱潇·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Demo 开发/FDE（当前：邓乾·推断待确认）、研发侧技术需求收口人（当前：李铭熙·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、行业能力负责人（当前：白立新·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售提交售前需求单 → ② 产品 1 个工作日内分诊 → ③ Demo 立项（范围、必备客户材料、交付日）→ ④ 优先复用 Demo 台账与行业工作流 → ⑤ 开发/生成 → ⑥ 内部验收与录屏 → ⑦ 交付客户并收集反馈 → ⑧ 入 Demo 台账
  • 交付结果：已交付的 Demo/样稿（含录屏与说明）、Demo 台账条目、转入正式需求池的需求或拒绝说明
  • 状态依据：产研已有“需求提报”入口，但售前需求没有统一入口：2026-02～10 反复出现商务直接找研发、新销售直接拉研发开会、样稿前一晚才知道要交、Demo 范围反复、双方对已有 Demo 数量认知完全不同等问题，约 30 次

1. 场景判定

  • 触发条件：客户要求看按其业务定制的 Demo；客户要求接入其系统或第三方数据（CRM、资产管理、企业信息查询）后演示；客户或渠道要求与竞品对比、限时出样稿/报告；销售发现已有同类行业工作流想复用
  • 典型说法：「聊了一家企业，意向很大，但有一些定制化开发的需要」「客户要的只是一份报告」「你就应该一开始定好哪些是要演示要用的」「看看能不能直接复用一部分工作流」「找产研得先跟产品说一声」
  • 判断问题：要产研投入人力做“给某个客户看的东西”，且还没签合同？是，就走本流程；已签合同的定制开发走 SAL-21 / X-DLV-10
  • 不归本流程管：正式定制需求评估与报价 → 请走 SAL-21 / X-PRD-11；进入产品需求池 → 请走 X-PRD-05 / X-PRD-09；演示执行 → 请走 SAL-11；投标演示视频与材料 → 请走 SAL-22；内部 Demo 部署 → 请走 RND-62；合同范围外需求 → 请走 SAL-25；开放平台业务归属 → 请走 ECO-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
售前需求入口 受理需求单、分诊、立项、协调资源、对销售回复 A/R 产品总监（当前：杨萌·推断待确认）
售前需求方 提交需求单、收集客户材料、对接客户、交付与收反馈 R 销售/售前（当前：侯明月、刘昱潇·推断待确认）
研发排期 评估工作量、排期、指派开发 R Leap 研发负责人（当前：王皓南·推断待确认）
Demo 开发 开发 Demo、评估与客户业务契合度 R Demo 开发/FDE（当前：邓乾·推断待确认）
研发收口人 市场侧技术需求统一由其对接研发，避免多头转述 R 研发工程师（当前：李铭熙·推断待确认）
开放平台 判断接口集成类需求是否属开放平台 C 开放平台负责人（当前：郭逸非·推断待确认）
能力复用 提供已有行业工作流、模板，评估可复用度 C 行业能力负责人（当前：白立新·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）
审批/兜底 资源冲突裁决、是否投入、战略调整时止损 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户需求原文件、客户业务场景说明、决策人与采购阶段、商机金额区间
  • Demo 必须演示的 1～3 个核心点（P0），其余标为可选
  • 客户需提供的材料清单（规格书、样例数据、接口文档、项目信息）及到位时间
  • 期望交付日与交付形式（在线 Demo、录屏、报告 Word/PDF、页面包）
  • 是否为投资人版、行业版或开放平台类需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交售前需求单；不得直接拉研发开会或私下派活 售前需求方 发现需求当天 飞书表单 → 售前需求池 售前需求单 🔧飞书固化
2 分诊：标品可直接演示 / 复用已有 Demo 或工作流 / 需新做 / 属开放平台或生态合作 / 拒绝 售前需求入口 1 个工作日内 多维表格 分诊结论 👤人工判断
3 AI 整理客户需求摘要；立项写清 P0 演示点、mock 范围、客户材料、交付日 售前需求入口、售前需求方 分诊后 1 个工作日内 Demo 立项模板 + AI Demo 立项单 🤖+👤
4 查 Demo 台账与行业工作流，能复用的做契合度评估、命名与数据隔离清理 Demo 开发、能力复用 立项后 1 个工作日内 Demo 台账 复用评估 🔧+👤
5 研发排期并指派；技术需求统一经研发收口人对接 研发排期、研发收口人 立项后 1 个工作日内 工单系统 工单 🔧飞书固化
6 开发/生成；客户材料未到位的部分不开工，按 mock 先做演示面 Demo 开发 按立项交付日（纯前端/样稿一般 ≤ 3 个工作日，带真实后端 ≥ 5 个工作日） 代码仓库 / AI 生成 Demo/样稿 🤖自动化
7 内部验收，录屏，导出报告（固定模板含目录） 售前需求入口 交付日前 1 个工作日 录屏 + 导出模板 验收记录、录屏 🔧+🤖
8 交付客户，1 个工作日内登记反馈；新 Demo 入台账，后续需求转 SAL-21 或需求池 售前需求方、售前需求入口 交付后 1 个工作日内 Demo 台账 / CRM 反馈与台账条目 🔧飞书固化

5. 交付物与模板

  • 交付物：Demo 或样稿、录屏、使用说明、Demo 台账条目、反馈记录
  • 售前需求单字段：客户（内部代号）、行业、商机阶段、需求类型（定制 Demo/接口集成/PK 样稿/复用）、需求描述、P0 演示点、客户材料与到位日、期望交付日、交付形式、提交人
  • Demo 立项模板：目标客户、演示范围、mock 范围、必备数据、交付日、负责人、验收人、复用来源
  • Demo 台账字段：名称、场景、行业、状态、负责人、访问链接、录屏链接、适用客户类型、可见级别（可对外/仅内部/需脱敏）
  • 复用评估清单：功能对比、客户数据隔离检查、命名与标识清理、需定制项

6. 异常与升级

  • 新销售绕过入口直接找研发 → 研发转回入口，不接活 → 重复发生升级销售负责人
  • 客户材料未按时到位 → 售前需求方每 2 个工作日催一次 → 超过 5 个工作日暂停 Demo 并告知客户
  • 交付日无法满足 → 研发排期提前 1 个工作日告知，售前需求方用统一延期口径对客 → 涉及重点客户升级 CTO
  • 需求跨投资人版/运营版/开放平台归属不清 → 入口 1 个工作日内定归属 → 无法确定升级 CTO
  • 公司战略调整导致 Demo 中止 → CTO 决定 → 2 个工作日内交接服务器、代码与资料给售前需求方
  • 接第三方商业数据（如企业信息查询 API）→ 先由生态合作谈授权，产研不先开发

7. 衡量指标

  • 售前需求入口覆盖率 = 经需求单进入的售前需求 / 全部售前需求，目标 ≥ 90%
  • 分诊时效 = 需求单提交到分诊结论的工作小时，目标 ≤ 8 小时
  • Demo 按期交付率 = 按立项交付日交付的 Demo / 全部 Demo，目标 ≥ 85%
  • Demo 复用率 = 基于已有 Demo/工作流交付的数量 / 全部交付，半年目标 ≥ 40%
  • Demo 转化率 = 交付 Demo 后进入报价或签约的商机 / 交付 Demo 的商机，按季度跟踪

8. 低效诊断

  • 现象：商务私下找研发发需求文档，研发不知谁是对接人、是否投资人版需求，几轮后才转到正式需求提报（入口环节）｜依据：「Leap产研测」2026-07
  • 现象：对已有 Demo 数量的认知完全不同，各人各做、无清单（Demo 台账环节）｜依据：「模态AI探索小分队」2026-04
  • 现象：Demo 需求边界不清、演示优先级反复，缺客户规格书无法开工，中途项目暂停研发撤出（立项环节）｜依据：「制造业demo」2026-03
  • 现象：PK 样稿前一晚才得知，项目信息只有标题，目录格式反复改，周末加班（样稿需求与交付环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：市场侧技术需求在多人之间转述，同一问题讲两遍，没有研发收口人（研发对接环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：新销售直接拉研发开会，产品被动，销售说法与研发承诺不一致（入口规则环节）｜依据：「Leap产研决策部」2026-10
  • 现象：复用已有工作流只能靠“看看这个可以吗”反复口头确认，无结构化评估（复用评估环节）｜依据：「合同审查复用」2026-08

9. 分支变体

  • 定制 Demo（资产管理、企业信息查询、CRM 集成等）：接口类先判定是否开放平台需求
  • 投资人版 Demo：在投资人版专门群受理，入口仍登记
  • 政府单位可研报告竞品 PK 样稿：需项目信息完整；生成约 14 小时，提前至少 1 个工作日确认；固定 Word 导出模板含目录
  • 行业工作流复用（如招标文件审查复用到合同/制度合规审查）：必须完成数据隔离和其他客户痕迹清理
  • 纯前端演示 vs 带真实后端：后者需 1 周以上，需 CTO 批准投入
  • 老销售/新销售：新销售入职培训“联系产研先走产品”

10. 待确认问题

  • 售前需求统一入口是否由产品总监承担？是否与渠道系统或 CRM 的需求入口合并？
  • 研发侧技术需求收口人是否仍为指定研发工程师？各产品线是否分别指定？
  • 售前 Demo 投入的门槛（商机金额、阶段）是否需要明确？带真实后端的 Demo 由谁批准？
  • Demo 台账由谁维护？是否与 SAL-15 演示场景库合并？
  • PK 样稿对外延期口径由谁出？是否需要商务确认？
SAL-15销售物料、标杆案例与知识库建设待优化144

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：新品发布、对外材料变更、演示或竞品对比成功产生案例、赢单产生标杆、行业版搭建市场体系，或销售规则/合同模板/渠道协议/价格更新时，把话术、演示场景、竞品对比、案例、行业作战包和规则模板沉淀到销售知识库并保持唯一最新版
  • 负责人：主责——生态市场总监（当前：许君·推断待确认）；协同——渠道/知识库与白皮书维护（当前：闫登辉·推断待确认）、演示视频合集与技能清单：产品总监（当前：杨萌·推断待确认）、CRM 赢单数据：销售运营（当前：韩诗琪·推断待确认）、行业版负责人（当前：吴琪、杨朋伟、闫登辉·推断待确认）、场景案例：业务专家（当前：王满·推断待确认）、案例认证积分（当前：丁震宇·推断待确认）、体系要求与验收：CEO（当前：邴龙志·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 识别更新事件 → ② 素材提交（案例/话术/视频/客户问题/规则）→ ③ 归口人整理、脱敏与审核 → ④ 发布到知识库“最新版”目录并标版本 → ⑤ 通知群推送并置顶 → ⑥ 销售培训与抽查 → ⑦ 每月清理旧版
  • 交付结果：分类清晰、版本唯一的销售知识库（话术/FAQ、演示场景库与视频合集、竞品对比、标杆案例集、行业版作战包、规则/模板/价格）及更新记录
  • 状态依据：已有“对外资料汇总”知识库、FAQ 话术手册、演示案例视频合集、案例集 wiki、行业版销售 SOP 初稿，但 2026-04～10 反复出现资料杂乱、新旧白皮书混用、对比成功视频未录、案例集与 CRM 赢单需反复催填、规则只发群通知被冲掉等问题约 40 次

1. 场景判定

  • 触发条件：新品或新版本发布；对外介绍材料、白皮书、价格、合同模板、渠道协议、质保单更新；一次演示或竞品对比效果好；赢单或试用客户出使用报告；CEO 要求建立行业版市场体系；每周例会收集到客户新问题
  • 典型说法：「建立标准 QA 库」「演示视频能不能做个共享文档的合集」「之前每次对比成功的视频都没录下来」「案例集放置顶了，赶紧填」「这种规则性的除了发通知，再放个飞书文档」
  • 判断问题：这条信息以后会被其他销售反复用到吗？会，就要按本流程入库
  • 不归本流程管：对外口径的起草与审定 → 请走 SAL-10；品牌素材库 → 请走 BRD-17；客户案例对外授权核查 → 请走 BRD-15；竞品评测执行 → 请走 BRD-16 / X-PRD-02；合同模板内容维护 → 请走 LEG-01；渠道与销售培训组织 → 请走 SAL-29；帮助中心与使用手册 → 请走 X-CS-18；售前资料库中技术答复部分 → 请走 SAL-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识库总负责人 定目录与版本规则、审核入库、组织话术考核 A/R 生态市场总监（当前：许君·推断待确认）
渠道资料维护 渠道协议、白皮书、渠道宣讲材料最新版 R 渠道负责人（当前：闫登辉·推断待确认）
演示视频与技能清单 维护演示视频合集、产品技能分类清单 R 产品总监（当前：杨萌·推断待确认）
赢单数据 导出 CRM 赢单，提示销售补案例 R 销售运营（当前：韩诗琪·推断待确认）
行业版负责人 产出本行业作战计划、对外方案、3 个演示视频、需求池 R 行业版负责人（当前：吴琪、杨朋伟、闫登辉·推断待确认）
场景案例 提供业务场景与案例素材 C 业务专家（当前：王满·推断待确认）
案例认证 认证优质案例并发放积分 C 案例认证人（当前：丁震宇·推断待确认）
体系验收 提要求、验收行业版体系 A（升级） CEO（当前：邴龙志·推断待确认）
全体销售 每周提交客户问题、好话术、好案例 R 销售人员

3. 办之前请准备

  • 素材原件：话术、客户问题原文、演示录屏（成功演示当场录）、对比结果截图、使用报告
  • 素材属性：行业、场景、适用产品与版本、是否可外发、是否涉及客户名称
  • 规则类：规则正文、生效日期、适用范围（如仅大型 OEM/ODM 订单）、发布人
  • 旧版本位置（便于下线）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 销售每周提交客户问题、答不上的问题、好话术（语音转文字可） 全体销售 每周一 10:00 前 飞书表单 周度素材 🔧+🤖
2 成功演示、竞品对比当场录屏，提交案例表单 演示人 演示后 1 个工作日内 案例提交表单 案例素材 🔧飞书固化
3 赢单或试用满半个月，从 CRM 导出生成案例草稿，提醒销售补充 销售运营 每周五 CRM + AI 案例草稿 🤖自动化
4 归口人整理：AI 聚合 FAQ、去重；案例脱敏（渠道项目匿名）、确认可外发 知识库总负责人 收到后 3 个工作日内 知识库 + AI 待发布条目 🤖+👤
5 发布到“最新版”目录，文件名带版本号和日期，旧版移入归档 对应维护人 审核通过当天 飞书知识库 最新版文件 🔧飞书固化
6 规则/模板/价格变更：通知群发布时附知识库链接，并同步问答机器人 发布人 发布当天 通知群 + 问答机器人 变更通知 🔧+🤖
7 周例会随机抽人讲 PPT、他人扮客户提问；新话术纳入考核 知识库总负责人 每周例会 例会 考核记录 👤人工判断
8 每月清理过期内容，检查各目录负责人与更新日期 知识库总负责人 每月最后一个工作日 知识库 清理记录 🤖自动化

5. 交付物与模板

  • 交付物：销售知识库（含“最新版”目录）、FAQ 话术手册、演示场景库与视频合集、竞品对比集、标杆案例集、行业版作战包、规则/模板/价格目录、更新日志
  • 知识库目录：产品介绍与白皮书 / 话术与 FAQ / 演示场景与视频 / 竞品对比 / 标杆案例 / 行业版作战包 / 规则·模板·价格 / 渠道宣讲材料（限现场使用）
  • 案例提交表单字段：行业、场景、产品与版本、客户类型（代号）、效果数据、录屏/截图、是否可外发、是否需匿名、提交人
  • 演示场景库字段：场景、部门/行业、客户类型、素材链接、竞品对比结论、认证状态、负责人
  • 行业版作战包：作战计划（市场分析、目标客户标签、资源、推广责任人）、对外方案（标准模板）、3 个高价值演示视频、需求池、销售 SOP（可参照工程咨询版渠道销售十步框架）
  • 文件规范：文件名“名称_版本_日期”，每个目录标负责人和最近更新日期

6. 异常与升级

  • 发现新旧版本混用 → 维护人当天下线旧版并群内通知 → 涉及合同/价格的同时通知商务负责人
  • 销售未按时提交周度素材或案例 → 销售运营每周五提醒 → 连续 2 周未交，升级市场销售负责人
  • 规则被转发误解（适用范围不清）→ 发布人 1 个工作日内澄清并在条目中补“适用范围”
  • 案例涉及客户名称且无授权 → 不对外发布，按 BRD-15 补授权
  • 缺少常用模板（如单独保密协议）→ 提交法务按 LEG-01 补充，5 个工作日内入库

7. 衡量指标

  • 版本唯一率 = 知识库中同类材料只有一个“最新版”的比例，目标 100%
  • 素材提交率 = 按时提交周度素材的销售 / 全部销售，目标 ≥ 90%
  • 案例覆盖率 = 已入案例集的赢单 / CRM 赢单数，目标 ≥ 80%
  • 行业版作战包完成度 = 已完成四项交付的行业版 / 立项行业版，目标 100%
  • 知识库自助率 = 销售群里“X 在哪/最新版是哪个”提问次数，目标逐月下降

8. 低效诊断

  • 现象：云文档杂乱，最新对外材料不好找，白皮书新旧版本混用（目录与版本环节）｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-08
  • 现象：对比成功的演示视频没录下来，重复演示浪费人力（素材采集环节）｜依据：「【模态】市场销售」2026-07
  • 现象：200 多个 Skill 没有分类，销售现场答不上；每人各自维护对外 PPT（物料整理环节）｜依据：「【模态】市场销售」2026-07
  • 现象：演示场景收集与审核、竞品对比资料无明确负责人，各自临时演示（场景库环节）｜依据：「演示场景打磨专用群」2026-07
  • 现象：案例集与 CRM 赢单多次催填，只有少数人填写，渠道案例署名口径不一（案例收集环节）｜依据：「打赢这一仗」2026-07
  • 现象：行业版产品负责人不清，行业资料分散，FAQ 不成体系（行业版体系环节）｜依据：「【行业版】市场拓展专项组」2026-10
  • 现象：规则只在通知群发布，被消息冲掉，转发时适用范围被误解；保密协议模板缺失后补（规则归档环节）｜依据：「Leap市场销售通知群」2026-09、「Leap市场销售通知群」2026-10

9. 分支变体

  • 行业版（招投标、工程咨询、教育、投资、媒体、服装、数字化转型、老板版）：按作战包四项交付，行业版负责人负责
  • 竞品对比（豆包、WorkBuddy 等）：只入库实测结果和录屏，结论经审核
  • 规则/模板/价格类：发通知必须附知识库链接；合同模板、渠道协议、质保单、硬件交付单、保密协议、对外模型价格、标准交付配置均在“规则·模板·价格”目录
  • 渠道宣讲 PPT：限现场使用，不外发
  • 直销与渠道案例：渠道项目默认匿名
  • 演示场景认证：优质案例经认证后发放积分

10. 待确认问题

  • 知识库总负责人是否为生态市场总监？白皮书最终版本由谁定稿？
  • 销售每周提交素材的时间（周一 10:00 前）是否保留？
  • 案例认证与积分规则由谁制定和发放？
  • 行业版作战包的验收人是否为 CEO？完成时限是多久？
  • 是否开发销售知识库问答机器人？规则类内容是否同步做成 Skill？
SAL-16客户/渠道试用申请审批、开通与转化跟进待新建240

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：客户或渠道要求先试用再购买（线上额度试用、演示机带用、样机部署、繁星计划等政府推荐企业试用、渠道试用账号）时，从判断给不给、给多少并审批，到开通、跟进反馈、回访转化或回收
  • 负责人：主责——试用审批人/市场销售负责人（当前：李鹏为·推断待确认）；协同——试用开通与充值事务：销售运营（当前：韩诗琪·推断待确认）、繁星计划台账：渠道负责人（当前：闫登辉·推断待确认）、带用部署与培训：销售（当前：杜中瑞、陈名赞、吴琪·推断待确认）、部署与演示机：产品总监与 IT 运维（当前：杨萌、杨明学·推断待确认）、使用报告监督（当前：许君·推断待确认）、教育线试用账号开通（当前：陈梦琪·推断待确认）、技术答复（当前：岳阳、宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 现场不承诺，回公司提交试用申请 → ② 按试用档位审批 → ③ 开通账号/额度或安排带用/部署 → ④ 登记试用台账 → ⑤ 带用培训并收集反馈 → ⑥ 半个月内出使用报告 → ⑦ 到期转化或回收 → ⑧ 输单复盘
  • 交付结果：经审批的试用记录、试用台账（客户、档位、额度、期限、阶段、消耗、反馈）、客户使用报告、转化结果（充值/签约）或回收记录
  • 状态依据：试用规则零散在群里（2026-07“试用必须先回公司报备”、2026-08 繁星计划赠送额度下调、2026-10 标准版统一额度线上试用“试行”），2026-10 CEO 仍要求补特批制度与试用 SOP；2026-01～10 每遇试用就临时讨论，约 50 次，出现销售已对客户许诺后才补审批

1. 场景判定

  • 触发条件：客户/渠道提出“先试用再买”；政府部门推荐企业参加繁星计划；渠道商要求试用账号或宣传材料；客户要按 API 低价试用高成本模型；试用客户提出反馈或定制需求
  • 典型说法：「做 LeapCore 试用，一定要回来报备，现场先不答应」「标准版试用先按统一额度做线上试用」「开个试用账号给渠道商试一下找谁」「超过 2 个星期还不回复就放弃，找下一家」「客户试用后反馈了几个问题」
  • 判断问题：客户还没付费，但要实际使用我们的产品/机器/额度？是，就走本流程
  • 不归本流程管：内部演示用账号与演示机 → 请走 SAL-13；赠送额度、借机等特殊商务行为 → 请走 SAL-17；正式账号开通与充值 → 请走 X-CS-02 / X-CS-03 / X-DLV-15；客户反馈转缺陷/需求 → 请走 X-CS-13 / X-PRD-07；定制需求评估与报价 → 请走 X-PRD-11 / SAL-21；驻场陪跑与培训 → 请走 X-FDE-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
试用审批人 判断给不给、给哪个档位、是否特批；对接政府推荐渠道 A/R 市场销售负责人（当前：李鹏为·推断待确认）
特批与制度 制定试用特批制度；超档位特批 A（升级） CEO（当前：邴龙志·推断待确认）
负责销售（申请人） 提交申请、带用培训、收集反馈、回访转化 R 销售（当前：杜中瑞、陈名赞、吴琪·推断待确认）
试用开通 CRM 录入、充值申请、开通账号与额度 R 销售运营（当前：韩诗琪·推断待确认）
繁星计划台账 维护繁星计划台账、周更、统计转化 R 渠道负责人（当前：闫登辉·推断待确认）
部署与演示机 带用演示机、样机部署 R 产品总监与 IT 运维（当前：杨萌、杨明学·推断待确认）
使用报告监督 督促半个月使用报告并沉淀为案例 C 生态市场总监（当前：许君·推断待确认）
技术答复 试用中技术问题的统一答复 C 研发（当前：岳阳、宋祺睿·推断待确认）
教育线账号 教育产品试用账号开通 R 教育/生态运营（当前：陈梦琪·推断待确认）

3. 办之前请准备

  • 客户资质：行业、规模、决策链、预算、采购方式、预计转化时间与金额区间
  • 试用目的与场景、想试的产品与版本（标准版/行业版）、试用人数
  • 是否为政府推荐企业（繁星计划）、是否为渠道商
  • 是否需要机器或高成本模型
  • 试用成功标准（客户认可什么结果就采购）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 现场不承诺试用；回公司在 CRM 提交试用申请（资质、档位、期限、成功标准） 负责销售 拜访后 1 个工作日内 CRM / 飞书审批 试用申请 🔧飞书固化
2 按档位审批：标准版线上额度试用；行业版一事一议；繁星计划仅限政府推荐企业；实体机原则不提供，需特批 试用审批人；超档位由 CEO 特批 1 个工作日内 飞书审批 审批结论 👤人工判断
3 开通：CRM 充值申请 → 开通账号与额度（设到期日）；带用或部署按约定时间安排 试用开通、部署与演示机 审批后 1 个工作日内 CRM + 管理后台 试用账号/部署记录 🤖+👤
4 登记试用台账：客户、档位、额度、起止日、负责人、阶段 试用开通、繁星计划台账 开通当天 多维表格 台账条目 🔧飞书固化
5 带用培训（不让客户裸用），收集使用问题，按 X-PRD-07 / X-CS-13 转交，定制需求按 X-PRD-11 评估 负责销售 开通后 3 个工作日内首次带用 反馈表单 反馈记录 👤人工判断
6 试用满半个月出深度使用报告（优先客户自写），入案例库 负责销售、使用报告监督 开通后 15 个自然日内 使用报告模板 使用报告 🔧+🤖
7 到期前 3 天提醒；试用合同挂起超 2 周无回复则放弃；引导预充或签正式合同；未转化则回收额度与机器 负责销售、试用开通 到期前 3 天提醒；到期后 2 个工作日内回收 机器人提醒 + CRM 转化或回收记录 🔧+🤖
8 输单满 3 家，总结原因反馈市场生态组 负责销售 每月汇总 多维表格 输单复盘 👤人工判断

5. 交付物与模板

  • 交付物：试用申请与审批记录、试用台账、使用报告、转化/回收记录、输单复盘
  • 试用申请字段：客户（内部代号）、行业、规模、决策链、预算区间、产品与版本、试用档位、额度、期限、人数、是否政府推荐、是否需机器/高成本模型、成功标准、申请人
  • 试用台账字段：客户、来源（直销/渠道/政府推荐）、档位、额度、起止日、阶段（申请/开通/带用/报告/转化/放弃/回收）、消耗量、反馈数、负责人、下次跟进日
  • 使用报告模板：使用场景、使用频次与消耗、效果、问题与建议、付费意向
  • 试用档位表（规则为现行口径，待确认）：标准版线上额度试用（试行，统一额度）；行业版一事一议（建议带着用 ≤ 3 天）；繁星计划（政府推荐企业，试用合同不计收入，赠送额度已下调，满 50 家停止）；渠道试用账号（身份较高的合作伙伴才开）

6. 异常与升级

  • 销售已对客户许诺试用 → 补提申请，审批人 1 个工作日内决定是否兑现 → 不兑现由销售负责人出面说明；重复发生升级 CEO
  • 非政府推荐企业要求繁星计划待遇 → 不引导繁星计划，转正式采购或标准试用
  • 客户要按 API 低价使用高成本模型 → 仅销售带演示机演示，不开放低价试用；需求评估按收费标准走 SAL-21
  • 客户既买标品又提定制 → 拆成两件事：Skill/插件层面归标品，其余按定开评估
  • 样机或部署资源不足 → 部署与演示机负责人 1 个工作日内给排期 → 超 2 周未部署升级市场销售负责人
  • 试用账号密码在群内明文发送 → 当天改密，按 X-SEC-10 处理

7. 衡量指标

  • 试用审批覆盖率 = 经审批开通的试用 / 全部试用，目标 100%
  • 试用开通时效 = 审批通过到账号/部署可用的工作日，目标 ≤ 1 个工作日（部署类 ≤ 5 个工作日）
  • 使用报告按期率 = 15 天内产出使用报告的试用 / 全部试用，目标 ≥ 80%
  • 试用转化率 = 试用后充值或签约的客户 / 结束试用的客户，按月跟踪
  • 试用成本 = 每月试用消耗的额度与机器占用，按档位统计，超预算预警

8. 低效诊断

  • 现象：谁批准试用、谁部署不清，销售现场先答应，事后才补报备规则（审批环节）｜依据：「【模态】市场销售」2026-07
  • 现象：签约未部署积压、样机库存不足（开通部署环节）｜依据：「【模态】市场销售」2026-08
  • 现象：活动获客来的多是政府与园区人员，企业很少；付费意愿需反复追问；各人跟进同类客户（线索与转化环节）｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-09
  • 现象：每遇试用临时讨论，对“能否试用”说法不一，特批制度与试用 SOP 多次被要求补（规则环节）｜依据：「【模态】市场销售」2026-10
  • 现象：渠道商试用该先找谁对接没有成文，靠口头约定（入口环节）｜依据：「新媒体leapcore代理（老杨）」2026-07
  • 现象：开试用账号要先问找谁，账号密码在群里明文发（开通环节）｜依据：「【模态】教育业务线」2026-01
  • 现象：客户想用低价试高成本模型、标品与定开混在一起，讨论反复（档位与需求拆分环节）｜依据：「Leap产研决策部」2026-10
  • 现象：试用反馈原样截图转发，缺客户、场景、版本信息，研发需二次追问；对客安全口径与实际存储方式冲突（反馈环节）｜依据：「Leap反馈群」2026-07

9. 分支变体

  • 标准版线上试用：统一额度、线上开通，不提供实体机
  • 行业版试用：一事一议，建议准备演示机、流程资料、内部演练、FAQ、远程测试后再现场带用
  • 繁星计划：仅限政府部门推荐企业；走免费试用合同特批；部署后半个月出使用报告，第二、三个月引导预充；线索由市场部统一分发；台账每周更新
  • 渠道/合作伙伴试用：经审批人判断后 CRM 录入走充值申请，事务由销售运营办理
  • 教育线（教师端/学生端）：宣传 PPT 默认加水印，对方要无水印再单独审批
  • 高成本模型：只演示不试用，需求评估收费后进入定开评估

10. 待确认问题

  • 试用审批人是否为市场销售负责人？超档位特批是否由 CEO 审批？特批制度何时成文？
  • 标准版试用统一额度和行业版“带着用 ≤ 3 天”的标准是否正式生效？
  • 繁星计划赠送额度、50 家上限、免费试用合同的审批人是否已确定？
  • 试用台账是否与 CRM 打通，替代单独的多维表格？
  • 需求评估费的收费标准与是否抵扣后续合同款由谁定？
SAL-17赠送额度、借机与特殊商务行为报备留痕待新建96

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：销售、产品或渠道打算给客户、合作伙伴、种子用户赠送额度或设备、借出设备、提供超出标准口径的免费试用，或员工自费购买公司产品时，先报备审批，再在合同、后台、账务三处留痕
  • 负责人：主责——市场销售负责人（当前：李鹏为·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 提交特殊商务申请 → ② 产品核定成本与口径 → ③ 市场销售负责人审批（超档位 CEO 加签）→ ④ 审批通过后出库/发放 → ⑤ 后台备注与合同/协议留痕 → ⑥ 财务入账 → ⑦ 到期回收或转化跟进
  • 交付结果：带审批编号的特殊商务申请单；对应的赠送/借用协议或个人采购合同；后台额度备注；财务可对账的赠送台账
  • 状态依据：目前没有成文规则，也没有审批入口。07 月出现先把设备送出去、事后才补报备的情况；被驳回的试用申请在会上又被提出；09 月员工自费购买时，不知道该走哪种合同、找谁提单，财务反馈“不好理账”。约 3 次靠临时口头处理

1. 场景判定

  • 触发条件：对外免费给出任何有成本的东西（额度、设备、试用期、兑换券），且超出标准试用口径；对外借出设备；合作伙伴/种子用户批量发放 token 额度；员工以个人身份购买公司产品
  • 典型说法：「是买是送不重要，但流程得对」「做事留痕就行，不然后面财务不好理账」「给额度也得有一个 SOP，合作伙伴一次给多少」「客户反复暗示让我们给他充钱」
  • 判断问题：这件事会不会让公司产生没有对应收入的成本或资产外流？如果会，并且不在标准试用口径内，就走本流程
  • 不归本流程管：标准试用申请与开通 → 请走 SAL-16；额度的财务入账与内部测试额度 → 请走 FIN-16；兑换券的生成与发放执行 → 请走 OPS-07；渠道分润与推荐费 → 请走 SAL-30；样机/演示机借用 → 请走 X-DLV-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填写申请、说明商务理由、事后跟进转化或回收 R 销售总监（当前：吴琪·推断待确认）、各销售/产品人员
产品核定 核定额度/设备的成本，判断是否违反“不推试用”等现行口径 C 产品总监（当前：杨萌·推断待确认）
审批 批准或驳回，决定是否需要 CEO 加签 A 市场销售负责人（当前：李鹏为·推断待确认）
加签 超档位、设备赠送、战略合作类的最终决定 A（升级） CEO（当前：邴龙志·推断待确认）
额度/后台执行 按审批单发放额度，后台备注“赠送额度+审批编号” R Leap 研发负责人（当前：王皓南·推断待确认）
规则口径 提供额度档位、token 计费口径，裁决争议 C 创始人兼 CTO（当前：丁震宇·推断待确认）
财务 登记赠送台账，核对个人采购合同与收款 I/C 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 对象信息：客户/伙伴/员工名称、所属渠道或商机编号
  • 赠送内容：额度数量或设备型号与数量、试用起止日期、是否需要回收
  • 商务理由：预期收益（转化、案例、渠道铺货）和后续节点
  • 历史记录：该对象此前是否被驳回过、是否已经领过赠送
  • 员工自购：购买人、产品、价格，以及要关联的销售提单人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在承诺客户之前提交“特殊商务申请”，选择类型（额度/设备赠送/设备借用/超口径试用/员工自购） 申请人 对外承诺前；不得先送后补 飞书审批 申请单 🔧飞书固化
2 核定成本（额度折算成本价、设备成本），标注是否与现行口径冲突、是否被驳回过 产品核定 收到申请后 1 个工作日内 飞书审批意见、价格总表 成本核定意见 🤖+👤
3 审批：档位内由市场销售负责人直接批；超档位、设备赠送、战略合作自动转 CEO 加签 审批、加签 1 个工作日内；超时自动升级 飞书审批 审批结论 🔧+👤
4 审批通过后才出库或发放；后台备注“赠送额度+审批编号”，设备登记借用/赠送状态 额度/后台执行、交付 审批通过后 1 个工作日内 管理后台、资产台账 发放记录 👤人工判断
5 补齐书面留痕：赠送/借用确认函或试用协议；员工自购走个人采购合同，由销售提单，必要时注册渠道系统 申请人 发放当天 合同模板、渠道系统 协议/合同 🔧飞书固化
6 登记赠送台账（对象、内容、成本、审批编号），月底与后台记录核对 财务 发放后 3 个工作日内；每月末核对 多维表格 赠送台账 🤖+👤
7 到期提醒：借用设备回收或转销售；试用到期跟进转化结果并回填 申请人 到期前 3 个工作日提醒，到期后 5 个工作日内回填 飞书任务/机器人 回收或转化记录 🔧+🤖

5. 交付物与模板

  • 交付物：特殊商务申请单、赠送/借用确认函、个人采购合同、后台额度备注、赠送台账
  • 建议模板/表单：
    • 申请单字段：类型、对象、关联商机/渠道、内容与数量、成本估算、起止日期、是否回收、商务理由、是否曾被驳回、申请人、审批人
    • 额度档位表：合作伙伴/种子用户/硬件渠道各自的单次额度上限，以及超档位的加签人
    • 赠送台账字段：审批编号、对象、内容、成本、发放日期、后台备注、到期日、结果（回收/转化/核销）

6. 异常与升级

  • 发现已经先送、先借但没有审批 → 申请人当天补提申请并注明“事后补报” → 市场销售负责人 1 个工作日内决定追认或回收，并在月度会上通报
  • 审批人 1 个工作日未处理 → 系统自动催办 → 第 2 个工作日升级 CEO
  • 申请属于超档位额度、设备赠送或战略合作类 → 决定权由市场销售负责人升级至 CEO 加签 → 审批流自动转 CEO，1 个工作日内出结论
  • 客户反复暗示要白给额度 → 引导客户购买兑换券或标准试用 → 仍坚持的，由申请人提交申请走第 3 步
  • 产生纠纷（客户认为是赠送，我方认为是借用）→ 以确认函为准；没有确认函的，责任由申请人和审批人共同承担，交 CEO 裁决

7. 衡量指标

  • 事前审批率 = 先审批后发放的件数 / 全部特殊商务件数，目标 100%
  • 审批时长 = 提交到出结论的工作日，目标 ≤ 1 个工作日
  • 台账一致率 = 后台赠送备注与财务台账一致的条数 / 后台赠送总条数，目标 100%
  • 赠送转化率 = 赠送/试用后 30 天内成单的数量 / 赠送总数（按季度看，没有目标值，只观察）

8. 低效诊断

  • 现象：设备先送出去，事后才补汇报；申请人认为“已经发消息同步过，但没人回”（缺少事前审批入口和超时升级）｜依据：「鼎慧产研决策部」2026-07
  • 现象：被驳回的试用请求在会上又被提出，口径靠个人判断（驳回结论没有留痕）｜依据：「鼎慧产研决策部」2026-07
  • 现象：员工自购不知道走什么合同、找谁提单，财务难以理账（自购路径没有规定）｜依据：「Leap产研决策部」2026-09
  • 现象：合作伙伴额度临时拍板，档位标准没有沉淀（缺少额度档位表）｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 设备赠送/借用：必须 CEO 加签；借用必须写回收日期，并登记资产台账
  • 超口径免费试用：与现行“不推试用”口径冲突，默认驳回；确实需要的，由市场销售负责人说明理由并加签
  • 合作伙伴/种子用户/硬件渠道额度：按档位表发放，档位内不需要 CEO 加签；涉及分润的部分走 SAL-30
  • 员工自费购买：走个人采购合同（系统自动生成），由销售提单，价格按标准价，不享受渠道价
  • 客户暗示充值：一律引导购买兑换券，不私下充值

10. 待确认问题

  • 审批人是否为市场销售负责人？设备赠送是否一律要 CEO 加签？
  • 合作伙伴、种子用户、硬件渠道的额度档位分别是多少？由谁维护档位表？
  • “不推试用”是否为正式口径？例外情况由谁批？
  • 员工自购能否享受内部价？个人采购合同由谁出具？
  • 赠送成本计入销售费用还是市场费用？与 FIN-16 的分工是否按“本流程管审批、FIN-16 管入账”划分？
SAL-18产品定价与价格体系管理待优化320

状态：待优化｜证据：有证据（卡片 10 张 / 会话 6 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：新产品、新模型、新套餐、新硬件机型上市，或成本、渠道政策变化需要调价时，统一测算成本、倍率、毛利与渠道分成，经审批后发布“内部总表 + 对外价格表”两套版本
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——COO（当前：常元和·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 定价需求登记 → ② 汇总成本（模型折扣/硬件/人力）→ ③ 用定价测算表算倍率、毛利、分成 → ④ 内部评审 → ⑤ 管理层审批 → ⑥ 发布内部总表与对外价格表 → ⑦ 同步销售、渠道与系统配置 → ⑧ 每月复核
  • 交付结果：带版本号的定价测算表、内部价格总表（含成本列，限定可见范围）、对外价格表（不含成本与折扣）、价格变更通知、系统价格配置记录
  • 状态依据：已有价格多维表格、定价方案文档和 pricing 总表，但 03～10 月口径反复变化：倍率先是一个系数后改为另一个，公式还写死在表格里；部分产品线毛利率迟迟定不下来；成本数据换人维护后需要重新交接；销售和市场反复来群里问价；内部总表靠手工截图外发，约 40 次以上讨论

1. 场景判定

  • 触发条件：新品或新模型接入需要对客价；上游成本变化（厂商调价、折扣变动）；渠道或销售公司分成规则调整；套餐、充值折扣、赠送政策调整；上游厂商来报价需要比价
  • 典型说法：「模型价格乘多少倍，两个产品要统一」「我需要一张能动态更新的对外价格表」「标准化，得改掉以前来一单算一笔成本的毛病」「这个不能外发」
  • 判断问题：这次决定会不会影响“以后所有同类订单”的价格？会 → 走本流程；只影响某一个客户的某一单 → 走 SAL-19
  • 不归本流程管：单个客户的方案报价 → 请走 SAL-19；硬件配置与 BOM 询价 → 请走 SAL-20；定制需求报价 → 请走 SAL-21；模型在网关系统里上线和配置价格 → 请走 OPS-02；成本价、倍率维护与成本收入对账 → 请走 FIN-28；渠道分润结算 → 请走 SAL-30；OPC 商城商品上架 → 请走 OPS-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
定价负责人 发起测算、维护测算表与两套价格表、发布变更 R 产品总监（当前：杨萌·推断待确认）
成本提供 提供模型/算力成本与折扣、硬件成本 R IT 运维/上游渠道维护（当前：杨明学·推断待确认）
成本与倍率复核 复核成本口径、倍率算法与毛利 C 创始人兼 CTO（当前：丁震宇·推断待确认）
销售与渠道口径 提供市场价锚点、渠道诉求、分成方案 C 销售骨干（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）
标品价格审批 批准标品价格、折扣与分成 A COO（当前：常元和·推断待确认）
系统配置 按发布版本更新网关/商城价格，回填配置记录 R NewAPI 网关研发（当前：柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
兜底 毛利底线和分成争议的最终裁决 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 定价对象：产品/模型/套餐/机型名称，所属产品线（LeapCore、LeapAll、LeapOne、一体机、Token 包、OPC 商品）
  • 成本输入：上游官方价与实际折扣、硬件 BOM 成本、人力与运维成本，以及数据来源和日期
  • 市场锚点：竞品价、上游厂商对外价、渠道反馈
  • 销量预测（用于摊薄固定成本）：由市场销售给出年度预测
  • 渠道结构：直销/销售公司/渠道各层分成比例的现行口径

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记定价需求：对象、原因、期望生效日 任何发起人 需求出现当天 多维表格“定价需求” 需求记录 🔧飞书固化
2 提供成本数据（含折扣与有效期），写入成本表 成本提供 登记后 2 个工作日内 多维表格成本表 成本记录 🔧飞书固化
3 在定价测算表中填参数（成本、倍率、毛利目标、分成、销量），自动算出各档售价；倍率只放参数单元格，不写死在公式里 定价负责人 成本到位后 2 个工作日内 多维表格/测算表 测算版本 🤖自动化
4 复核成本口径与倍率，校验公式；销售与渠道确认可卖性 成本与倍率复核、销售与渠道口径 收到测算后 1 个工作日内 飞书文档评论 复核意见 🤖+👤
5 审批：标品价格由 COO 批；低于毛利底线或改动分成结构的，CEO 加签 标品价格审批、兜底 2 个工作日内 飞书审批 审批结论 🔧+👤
6 发布：内部总表更新版本号（仅限授权人员可见）；同时生成对外价格表视图（去掉成本、折扣、倍率列） 定价负责人 审批通过当天 多维表格视图权限、知识库 两套价格表 🔧飞书固化
7 同步：在销售群、渠道系统发布变更通知；网关和商城完成价格配置并回填 定价负责人、系统配置 发布后 1 个工作日内 群公告/机器人、网关后台 变更通知、配置记录 🤖+👤
8 月度复核：对照上游成本变动和实际毛利，判断是否需要调价 定价负责人 每月第 1 周 测算表、账单 复核结论 🤖+👤

5. 交付物与模板

  • 交付物：定价测算表（版本化）、内部价格总表、对外价格表、价格变更通知、系统配置记录
  • 建议模板/表单：
    • 测算表字段：产品/模型、档位、上游官方价、折扣、成本价、倍率、售价、毛利率、直销价、销售公司价、渠道价、生效日、版本号、审批编号
    • 对外价格表字段：产品/模型、档位、对外价、充值/累充折扣、赠送规则、生效日（不得出现成本、折扣来源、倍率）
    • 变更通知字段：变更项、旧价、新价、生效日、影响的在途报价处理方式

6. 异常与升级

  • 上游成本突然上涨 → 成本提供人当天通知定价负责人 → 3 个工作日内出调价方案；在此之前新报价必须注明有效期
  • 销售或渠道需要的价格不在对外表里 → 由定价负责人 1 个工作日内答复，不得口头临时给价
  • 内部总表被误发到外部 → 发送人立即撤回并报告定价负责人 → 当天升级 CTO 评估影响（保密处置见 LEG-30）
  • 价格低于毛利底线、改动分成结构，或毛利率口径争议 2 个工作日定不下来 → 决定权由 COO 升级至 CEO 加签或裁决（2 个工作日内）
  • 系统配置与发布价格不一致 → 系统配置人 1 个工作日内修正，并核查期间的订单

7. 衡量指标

  • 价格问询次数 = 每月群里询问“现在什么价”的次数，目标逐月下降，3 个月后 ≤ 2 次/月
  • 定价周期 = 登记到发布的工作日，目标 ≤ 7 个工作日
  • 价格一致率 = 抽查订单中报价与对外价格表一致的比例，目标 ≥ 98%
  • 系统价格同步时效 = 发布到配置完成，目标 ≤ 1 个工作日
  • 实际毛利偏差 = 实际毛利率 − 测算毛利率，按月看，偏差超过 5 个百分点要复核

8. 低效诊断

  • 现象：宏观方案在群里口述，没有成文文档，听的人缺少上下文，需要反复补充说明（方案成文环节缺失）｜依据：「鼎慧产研决策部」2026-03
  • 现象：新商品上架只能“去问某人”，没有上架清单（新品上市环节缺失）｜依据：「鼎慧产研决策部」2026-03
  • 现象：词元单价“太便宜/会亏”反复争论，每单重新核算成本，销量预测要反复向市场要（测算模型与输入环节）｜依据：「leapcore市场对接」2026-04、「字字可研市场运营」2026-04
  • 现象：某产品线毛利率迟迟定不下来，倍率公式写死，改了倍率还要改表（审批与表格设计环节）｜依据：「AI API」2026-06、「AI API」2026-07
  • 现象：销售把套餐价和 API 单价放在一起比较，也不知道当前折扣（对外价格表缺失）｜依据：「AI API」2026-09
  • 现象：成本价被随意转发，密级没有定义（发布与权限环节）｜依据：「AI API」2026-10

9. 分支变体

  • LeapCore 套餐：按“基础版 + 行业软件费 + 词元费”构成；行业版是否组合销售由 COO 定
  • 一体机（NAS、Mac Studio 等）：硬件成本 + 软件溢价，参考市场锚点；成本来自 SAL-20 的成本库
  • Token 包/算力包/充值折扣：按词元池统一换算，设体验/月度/年度阶梯；累充折扣是否对外需要明确写出
  • 对外 API 价格：企业本地网关分组倍率固定为 1，直接改模型价格，不靠分组倍率下发
  • 上游厂商来报价时：成本提供人比价，判断是否接入；我方单独卖 API 时不得高于市场价
  • 三级分成：直销/销售公司/渠道按“成本逐级加成”结构测算，整体毛利不得低于底线
  • 内部资料外发：内部总表禁止外发；需要给渠道的，只用对外价格表视图；发送成本价前必须在指定群报备

10. 待确认问题

  • 定价主责是否为产品总监？标品价格审批人是 COO 还是市场销售负责人？
  • 各产品线的毛利底线分别是多少？倍率是否全线统一？
  • 成本数据由谁维护（成本维护人已发生过变动）？更新频率多久一次？
  • 价格信息的密级（内部公开/机密/绝密）怎么定义？谁可以看内部总表？
  • 定价测算表与 FIN-28 的成本倍率表是否合并为同一张表？
SAL-19客户方案与报价单编制审核待优化500

状态：待优化｜证据：有证据（卡片 15 张 / 会话 13 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：客户询价、扩容或提出项目制需求时，由销售先完成需求调研，再编制方案书、报价单和内部成本测算表，经技术复核和分级审批后，只发出一版客户版报价
  • 负责人：主责——客户对接销售（当前：按商机归属，如闫登辉、刘昱潇、吴琪·推断待确认）；协同——FDE Leader（当前：黄振锋·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、产品总监（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 需求调研与报价登记 → ② 方案范围冻结 → ③ 分块估算（软件人日/硬件/模型用量/运维）→ ④ 用报价 Skill/模板生成方案书、报价单、成本测算表 → ⑤ 技术复核 → ⑥ 按毛利分级审批 → ⑦ 生成唯一客户版 PDF 发出 → ⑧ 登记台账并跟进反馈
  • 交付结果：审批通过的客户版报价单（PDF，唯一版本）、方案书、内部成本测算表、报价台账记录
  • 状态依据：已有报价 Skill（09 月发布）、报价群、标准报价单雏形，合同系统也在建设报价审批模块；但 03～10 月仍反复出现：临发前才发现漏写报价、同一份文件“是否已经加价”争论约 10 轮、方案没定就先报价、版本只靠文件名区分、审核人和时限不固定。约 40 次以上返工或催办

1. 场景判定

  • 触发条件：客户（直客或经渠道转来）要报价或初步方案；已有客户扩容；项目制定制；客户现场问“这套多少钱”
  • 典型说法：「这套下来多少钱」「帮忙审核一下这版报价」「最后只留一版报价」「这个口径要统一」「先让销售审，再给技术看」
  • 判断问题：客户要的是“一个具体项目的价格”吗？是 → 走本流程；如果需要先定一个新产品的标准价 → 先走 SAL-18
  • 不归本流程管：产品标准价、套餐与倍率制定 → 请走 SAL-18；纯硬件/服务器配置与询价 → 请走 SAL-20（结果回填本流程）；标品之外的定制工作量与特批 → 请走 SAL-21；甲方格式化投标报价表 → 请走 SAL-22；合同起草 → 请走 SAL-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
报价发起 需求调研、登记、汇总、对客发送与跟进 R 客户对接销售（当前：闫登辉、刘昱潇、吴琪、杜中瑞、时建·推断待确认）
软件/模块估算 按模块估人日与周期，维护报价 Skill R FDE Leader（当前：黄振锋·推断待确认）
硬件成本 出配置与硬件成本 R IT 运维/硬件（当前：杨明学·推断待确认）
产品与用量口径 提供词元用量、产品成本、赠送项口径 C 产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
技术复核 复核范围、技术承诺、成本因子 C 创始人兼 CTO（当前：丁震宇·推断待确认）
价格审批 批准报价与折扣，确认渠道费 A 市场销售负责人（当前：李鹏为·推断待确认）
大项目谈价/兜底 大额或战略项目定价，审批超时裁决 A（升级） COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 需求四要素：是否必须本地部署、期望交付时间、预算范围与付费方式（一次性/分阶段/订阅）、使用人数与并发
  • 客户材料：需求文档或会议纪要、甲方模板（如有）、客户关注点清单
  • 来源：直客还是经渠道/中间方转来（决定是否预留渠道费）、对应哪个签约主体
  • 当前对外价格表版本号（来自 SAL-18）和硬件成本（来自 SAL-20）
  • 方案是否已经冻结；没冻结的，只能出价格区间，不出正式报价
  • 请求最少包含字段：客户内部代号与签约主体、CRM 商机编号、来源（直客/渠道）、需求四要素、是否本地部署与硬件需求、客户截止日期、客户材料链接、估算方（软件/硬件/用量各找谁）；缺任一项估算人退回登记人补齐，不在群里逐条追问

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在报价台账登记：客户、商机、来源、需求四要素、客户截止时间 报价发起 收到询价当天 多维表格/CRM 商机 台账记录（报价台账，关联 CRM 商机编号；群内只发台账链接） 🔧飞书固化
2 冻结范围：列出包含项、不包含项、客户需提供的资料；硬件还在调整的，只给区间 报价发起、技术复核 登记后 1 个工作日内 飞书文档 范围确认单（挂在台账记录下，技术复核人在文档内签“已确认”） 👤人工判断
3 分块估算：软件按模块估人日；硬件转 SAL-20；模型用量按 P50/P95 估成本；运维按月估 软件/模块估算、硬件成本、产品与用量口径 标准报价 1 个工作日；项目制 3 个工作日 报价 Skill、成本测算表 估算明细（填入成本测算表对应分块，台账状态改“估算完成”）；超时→报价发起人催办，再超 1 个工作日→市场销售负责人 🤖+👤
4 用报价 Skill/模板生成方案书、报价单、内部成本测算表；删除客户没要求的项；开源组件不写进报价 报价发起 估算完成后 0.5 个工作日内 报价 Skill、模板 初稿（在原文件下建版本，版本号写入台账） 🤖自动化
5 技术复核：范围、承诺指标、成本因子（算力、人力、数据清洗、运维）是否齐全；用脚本校验合计、单价、大小写 技术复核 收到后 1 个工作日内 文档评论、校验脚本 复核意见（文档评论 + 台账“复核通过/退回”）；超时→COO 🤖+👤
6 审批：毛利达到底线的由市场销售负责人批；低于底线或有特殊折扣的，COO 加签；渠道费单列 价格审批、大项目谈价 1 个工作日内 飞书审批/合同系统报价模块 审批记录（飞书审批）、版本锁定（台账标“已锁定”）；超时见第 6 节 🔧飞书固化
7 从锁定版本生成客户版 PDF（不含人日明细的版本按需另出），只发一版，并在台账记录发送日期 报价发起 审批通过当天 模板、CRM 客户版报价单（PDF 挂 CRM 商机页，台账记发送日期与版本号） 🔧+🤖
8 跟进客户反馈；改价必须新建版本、重新走第 6 步 报价发起 发出后 3 个工作日内首次跟进 CRM、台账 反馈记录（CRM 商机跟进记录，台账状态更新为赢单/丢单/改价） 🔧飞书固化

5. 交付物与模板

  • 交付物：方案书、客户版报价单（PDF）、内部成本测算表、审批记录、报价台账
  • 建议模板/表单：
    • 报价单七章节：概述、模块工作量与费用、交付周期、运维标准、迭代收费、实施方案、风险与边界
    • 成本测算表字段：模块、人日、人日单价、硬件成本、模型用量（P50/P95）、运维月费、渠道费、毛利率、有效期
    • 报价台账字段：客户、商机编号、来源、版本号、估算人、复核人、审批人、毛利率、状态（草稿/审批中/已发/赢单/丢单）、发送日期

6. 异常与升级

  • 客户截止时间不足 1 个工作日 → 报价发起人当天在台账标“急”并通知审批人 → 审批人 2 小时内处理；来不及的，先发区间价，并注明“以正式报价为准”
  • 客户需求不清、估人数分歧大 → 按“底线 + 可调项”出两档；仍无法估算的，回到第 2 步，请客户补资料
  • 发现合同额与市面价差异过大、可能过不了客户审计 → 调整服务内容构成，不直接改单价 → 市场销售负责人 1 个工作日内确认
  • 不同渠道报给同一客户的价格不一致 → 以审批版本为准，由市场销售负责人当天统一口径
  • 审批 1 个工作日未处理 → 自动催办；第 2 个工作日升级 COO
  • 估算方（软件/硬件/用量）超时限未回填 → 报价发起人在台账标“卡住”并 @ 对应估算人 → 再超 1 个工作日升级市场销售负责人协调人力
  • 登记信息不齐（缺需求四要素、来源、截止日）→ 估算人一次性退回并列出缺项 → 报价发起人 1 个工作日内补齐，不进入估算

7. 衡量指标

  • 报价周期 = 登记到客户版发出，标准报价目标 ≤ 2 个工作日，项目制 ≤ 5 个工作日
  • 一次通过率 = 审批一次通过的报价数 / 报价总数，目标 ≥ 80%
  • 对外版本数 = 每个商机发给客户的报价版本数，目标 1 版（客户主动要求改价的除外）
  • 报价错误数 = 客户或审核发现的金额、合计、漏项错误，目标 0
  • 毛利达标率 = 赢单项目实际毛利不低于报价测算毛利的比例，目标 ≥ 90%

8. 低效诊断

  • 现象：临发前才发现漏写报价，30 分钟内多轮改价；同一份文件“是否已经加价”争论约 10 轮（缺少模板和版本管理）｜依据：「鼎慧产研决策部」2026-04
  • 现象：方案和硬件需求还没定就先做报价，导致无效劳动（范围冻结环节缺失）｜依据：「鼎慧产研决策部」2026-04
  • 现象：报价按最大成本还是分位数核算，口径不一，算错后要重算（成本口径环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：用量换算、价格表口径不稳定，客户问“[金额已隐去]能做多少事”答不出来（对外口径缺失）｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-07
  • 现象：软件、硬件、信创分块会签靠群里口头安排，版本靠文件名区分，AI 起草的方案里有客户不需要的项（会签与校验环节）｜依据：「某车企客户报价评估群」2026-07
  • 现象：现场被问价不知道怎么答，报价权在谁不明确（前线口径缺失）｜依据：「某地方政府客户市场群」2026-03
  • 现象：系统内“谁创建报价、谁审批”，开发与业务理解相反（审批层级未定义）｜依据：「cms反馈」2026-09
  • 现象：各人报出来的东西不统一（已用报价 Skill 部分解决）｜依据：「核心项目群」2026-09

9. 分支变体

  • AI 可研类订单：按“词元单价 × 每篇用量 × 篇数”测算；常规情况看 P50，最坏情况看 P95；赠送项计入成本；合同写明每篇用量上限和我方换模型的权利；篇数给范围值，测算功能另行收费
  • 经渠道/中间方转来的政企项目：报价单列渠道费；按客户采购规则控制单笔金额以简化招采，二期按询价流程
  • 客户现场问价：只回答“需要评估”，并当场收集需求四要素；不当场报数
  • 软件 + 硬件 + 信创会签：软件、硬件分别评估后由 CTO 核对；国产数据库等第三方授权费由客户自行解决，我方只提供建议
  • 模型调用报价（经济/标准/专家三档）：先确认对应哪个渠道或主体，再套对外价格表
  • 项目定制模块报价：在报价群提交，由 FDE Leader 出模块人日
  • 机房/机柜租赁报价：按价目表报（按 U、基础电力、超电补缴、IP、带宽）；价目表没有成文前，由 COO 审批
  • 合同系统报价模块：销售提交 → 业务负责人审批 → 锁定 → 选择已审批报价按模板生成客户版；修改须新建版本重审
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 主责是否为客户对接销售？价格审批人是市场销售负责人，还是按金额分级（业务负责人/财务）？
  • 毛利底线是多少？软件人日、硬件、模型用量是否各有不同的底线？
  • 报价 Skill 是否作为强制起草工具？硬件报价模板由谁补齐？
  • 合同系统报价模块上线后，本流程第 6～7 步是否全部迁入系统？
  • 报价群与报价台账是否合并？报价有效期统一为多少天？
SAL-20硬件/算力配置评估、询价与报价待优化240

状态：待优化｜证据：有证据（卡片 11 张 / 会话 12 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：客户提出并发、模型、预算、席位或服务器定制需求时，由技术评估配置与容量（必要时压测），IT 和渠道询价得出 BOM 成本，商务再加软件与词元价，形成带有效期的对外硬件报价
  • 负责人：主责——IT 运维/硬件负责人（当前：杨明学·推断待确认）；协同——销售骨干/商务报价（当前：闫登辉·推断待确认）、各需求销售（当前：刘昱潇、时建、陈名赞·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售提交硬件评估需求单 → ② IT 出配置方案（软件侧评估并发/上下文）→ ③ 容量存疑时压测 → ④ 客户确认配置 → ⑤ 询价出 BOM 成本 → ⑥ CTO 复核成本与配置 → ⑦ 商务按系数加软件与词元价 → ⑧ 财务、法务审核后发客户（注明有效期）
  • 交付结果：配置清单、BOM 成本表、（必要时）压测/容量评估结论、带有效期的硬件报价单
  • 状态依据：已有成本多维表格、BOM 文档和配置成本表，10 月 CTO 已口述“服务器报价 SOP”六步并要求 1 个工作日出方案；但 01～10 月“BOM 呢”“今天能不能出”类催办约 25 次，并发、席位参数在传递中失真，报价有效期一说一周、一说 30 天，硬件评估依赖单人

1. 场景判定

  • 触发条件：客户给出并发、模型、预算、人数等指标需要可行配置；客户要私有化服务器或一体机报价；自有品牌机型定价或降本；大并发场景需要确认能否支撑
  • 典型说法：「急报价，今天能不能出一版」「你把 BOM 丢给供应商就是了」「客户价得乘一个系数」「应该可以，但没实际测过」
  • 判断问题：报价里有没有我方需要采购或交付的硬件/算力？有 → 走本流程；只有软件和服务 → 走 SAL-19
  • 不归本流程管：标品一体机配置咨询与配置单维护 → 请走 X-DLV-01；供应商选型、采购下单与补货 → 请走 X-DLV-02；完整项目方案报价的汇总与审批 → 请走 SAL-19；硬件价格体系与机型标准价 → 请走 SAL-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求提交 填写评估需求单，确认客户是否自购、对客说明 R 各需求销售（当前：刘昱潇、时建、陈名赞·推断待确认）
配置与成本 出配置方案、询价、维护 BOM 与成本库 R IT 运维/硬件负责人（当前：杨明学·推断待确认）
备岗 硬件负责人不在时接手标准机型报价 R 交付部署工程师（当前：游家豪·推断待确认）
软件侧评估 并发、上下文、RAG、模型显存需求 C 基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）
成本复核 复核配置合理性与成本，决定降本项 R 创始人兼 CTO（当前：丁震宇·推断待确认）
商务报价 成本 × 利润系数 + 软件价 + 词元价，形成客户价 R 销售骨干/商务报价（当前：闫登辉·推断待确认）
价格审批 批准客户价与有效期 A 市场销售负责人（当前：李鹏为·推断待确认）

3. 办之前请准备

  • 需求单必填：使用人数、并发路数、席位、模型及参数量、上下文长度、存储与文档量、部署方式（本地/云/混合）、预算区间、交付时间
  • 客户约束：是否要求信创/国产化、是否有机房、是否客户自购硬件、机型形态（桌面/机架）
  • 客户原始资料（AI 生成的指标要标注出来，由技术确认是否合理）
  • 是否需要带源码、3C 认证、多版本方案

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交硬件评估需求单（必填项不全的退回） 需求提交 客户提出需求当天 多维表格派单 需求单 🔧飞书固化
2 软件侧给出并发、显存、上下文需求；IT 据此出配置方案（基础/推荐两档） 软件侧评估、配置与成本 标准机型 1 个工作日内；定制 2 个工作日内 估算表、配置库 配置方案 🤖+👤
3 容量存疑（没有实测数据、大并发）时，安排非工作时段压测或参考同型号实测，出容量结论 软件侧评估、配置与成本 3 个工作日内 压测脚本 容量评估结论 🤖自动化
4 销售与客户确认配置；客户自购的，只给推荐配置和价格区间 需求提交 1 个工作日内 — 配置确认 👤人工判断
5 用同一份需求文档向 2 家以上渠道询价（或从成本库直接取标准机型价），异常价标红汇总 配置与成本 配置确认后 1 个工作日内 成本库、询价表 BOM 成本表 🤖+👤
6 复核配置与成本，决定降本项（CPU、内存、硬盘等） 成本复核 收到后 0.5 个工作日内 成本库评论 复核结论 👤人工判断
7 按利润系数形成客户价，加上软件与词元价；注明有效期和“内存硬盘价格波动，仅供参考” 商务报价 复核后 0.5 个工作日内 报价模板 客户硬件报价 🔧+🤖
8 价格审批，财务、法务核对配置与合同条款一致后发客户；结果回填 SAL-19 台账 价格审批、需求提交 1 个工作日内 飞书审批 已发报价 🔧飞书固化

5. 交付物与模板

  • 交付物：硬件评估需求单、配置方案（基础/推荐）、BOM 成本表、容量评估结论、客户硬件报价单
  • 建议模板/表单：
    • 需求单字段：见“办之前请准备”必填项，另加需求来源、截止时间、是否急单
    • 成本库字段：机型/配件、品牌型号与料号、渠道、单价、询价日期、有效期、历史价
    • 并发 × 模型 × 显存估算表：模型、量化、卡型、单卡并发、token 速度、上下文、数据来源（实测/公开资料）
    • 报价单固定说明：有效期、价格波动声明、性能前提（并发口径）、非标准环境损坏不保

6. 异常与升级

  • 需求单信息不全 → 当天退回销售补充；客户给不出数据的，按行业经验估算，并在报价中写明假设
  • 硬件负责人 1 个工作日未出方案 → 自动提醒；第 2 个工作日由备岗接手标准机型，定制机型升级 CTO
  • 供应商缺货或报价超过有效期 → 换备选渠道重新询价，并通知销售更新报价
  • 并发/席位参数在传递中失真 → 以需求单为准，口头转述无效；发现成本因此高估或低估的，退回第 2 步
  • 客户要求信创而我方没有现成供应商 → 当天报告市场销售负责人找资源；3 个工作日内仍没有的，以默认方案兜底，并在报价中说明

7. 衡量指标

  • 方案时效 = 需求单到配置方案的工作日，标准机型目标 ≤ 1 天，定制目标 ≤ 2 天
  • 催办次数 = 每单被催“出了没”的次数，目标 0
  • 报价准确率 = 签约后实际采购成本与报价成本偏差 ≤ 5% 的单数占比，目标 ≥ 90%
  • 成本库覆盖率 = 能直接从成本库取价的报价占比，目标 ≥ 70%

8. 低效诊断

  • 现象：BOM 迟迟不出，反复催；渠道报价型号查不到料号（单点承接、缺少成本库）｜依据：「忠橙星行星引擎」2026-07、「忠橙星行星引擎」2026-10
  • 现象：客户指标由 AI 生成、需求太模糊，评估来回拉扯；硬件是否由我方报价有争议（需求输入环节）｜依据：「客户项目群（半导体）」2026-05
  • 现象：AI 起草的报价表缺少数量等字段，要追问是云端还是私有化规格（需求模板缺失）｜依据：「硬件价格评估」2026-04
  • 现象：销售按标品讲了并发和席位，成本被高估（参数传递环节）｜依据：「忠橙星行星引擎」2026-10
  • 现象：客户催促而报价体系迟迟不出（单人依赖、无时限）｜依据：「字字可研项目群」2026-03
  • 现象：谁定硬件配置不清，供应商无货后没有替代（职责与备选渠道缺失）｜依据：「leapcore 合同审核群」2026-07、「leapcore 合同审核群」2026-10
  • 现象：性能结论只在群里，数据频繁变化（缺少性能报告发布）｜依据：「Leap产研测」2026-08
  • 现象：大并发需求只能回答“应该可以”（缺少容量评估与压测规范）｜依据：「LeapVPN网络预研」2026-09

9. 分支变体

  • 自有品牌标准机型：直接从成本库取价，设定最低配成本，销售可以自助查；按年量与供应商谈折扣
  • 定制款服务器：走完整 8 步，目标 1 个工作日出方案，有效期与采购渠道对齐
  • 客户自购硬件：只出推荐配置和价格区间，不对硬件价格负责
  • 一体机/云桌面/PC：额外核算 3C 认证费；软硬一体价由市场销售负责人对客户报
  • 私有化带源码报价：由 CTO 和市场销售负责人单独定价，不套系数
  • 信创/国产化：优先海光等国产算力，并维护国产供应商清单；没有现成资源时以英伟达方案兜底
  • GPU 推理优化成果：版本冻结后由硬件负责人出性能测试报告（并发、上下文、机器成本），作为报价参考；对外引用前必须有实测证据
  • 大并发容量评估：在非工作时段压测，结论写入报价前提

10. 待确认问题

  • 主责是否为 IT 运维/硬件负责人？备岗是否为交付部署工程师？
  • 报价有效期统一为 7 天还是 30 天？
  • 利润系数的取值规则是什么？带源码、定制等特殊项由谁批？
  • 与 X-DLV-01 的边界：是否按“销售发起的项目报价走 SAL-20、标品配置单维护走 X-DLV-01”划分？
  • 是否需要财务、法务审核每一份硬件报价，还是只审合同阶段？
SAL-21定制/非标需求评估、报价与特批待新建144

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：签约前或签约后，客户在标品之外提出定制需求（换 Logo/去商标、定制 skill、接入指定模型或自有算力、API 适配、行业版开发、多机登录等）时，先判定是否非标，研发只报人天，销售定价，特批通过并签（追加）合同、收到首付款后才排期
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、NewAPI 网关研发（当前：柯逸飞·推断待确认）、COO（当前：常元和·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售提交非标需求受理单 → ② 产品判定标品/已有版本/非标 → ③ 研发评估人天与工期 → ④ 销售定服务价 → ⑤ 特批（占用研发多的 CTO 加签）→ ⑥ 签合同或追加合同、收首付款 → ⑦ 进入研发排期 → ⑧ 交付验收
  • 交付结果：非标需求受理单（含判定结论、人天、价格、审批）、服务说明、（追加）合同、研发排期记录
  • 状态依据：每次都是临时拉群、临时定价；05～10 月出现“上次报的改页面到现在还没定价”“我们根本没有商务”，以及版本边界反复问（某版本已并入标品，但合同里还在写）；客户先用后谈费用，研发被非标需求挤占。约 8 次争议

1. 场景判定

  • 触发条件：客户或渠道提出的需求不在标准功能清单内；要改品牌标识；要接入非默认模型或自有算力；要做行业版/定制 skill；已签客户提出合同以外的新功能
  • 典型说法：「要区分开标品和定制」「技术只管做多久、能不能做、什么时候做完」「给多少钱办多少事」「有需求就加钱，追加合同」
  • 判断问题：这个需求在标准功能清单里吗？做完能不能复用给其他客户？不在清单里 → 走本流程
  • 不归本流程管：已签合同交付中客户提出的范围外需求，先做拦截与预期管理 → 请走 SAL-25（确认要做的再回到本流程第 3 步）；渠道预装/贴牌/联合开发承诺 → 请走 SAL-28；定制需求的拆解、排期执行 → 请走 X-DLV-10；行业版与白牌交付 → 请走 X-DLV-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提出人 填写受理单，补充商务背景（客户类型、金额、预期收益） R 销售骨干（当前：闫登辉·推断待确认）及各客户对接销售
判定与协调 判定标品/非标，起草服务说明，协调排期 R 产品总监（当前：杨萌·推断待确认）
工作量评估 只报人天、工期、可行性，不报价格 R Leap 研发负责人（当前：王皓南·推断待确认）
实施 承接模型接入、API 适配类改动 R NewAPI 网关研发（当前：柯逸飞·推断待确认）
产品方向 判断是否并入标品或做成行业版 C COO（当前：常元和·推断待确认）
特批 批准价格与是否承接 A 市场销售负责人（当前：李鹏为·推断待确认）
加签/兜底 定优先级、拦成本，研发占用大时加签 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户类型：终端客户/渠道客户、是否已签约、合同编号与已购内容
  • 需求描述：具体改什么、截图或样例、期望上线时间
  • 商务背景：客户预算、合同金额、后续机会、是否战略客户
  • 已有方案：历史上做过的同类方案（注意是否已经过时）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交非标需求受理单，写清商务背景 提出人 客户提出后 1 个工作日内 飞书审批“非标需求立项” 受理单 🔧飞书固化
2 对照标准功能清单与版本边界，判定是标品、已有版本，还是非标；标品直接转工单，不再走后续步骤 判定与协调 1 个工作日内 功能清单、版本边界文档 判定结论 👤人工判断
3 评估改动点、人天（含测试）、工期，只报人天 工作量评估 2 个工作日内 评估表 人天评估 🤖+👤
4 按人天成本价加评估费和上浮定价；起草服务说明（交付内容、一次性交付、不含长期售后、再次改动另收费） 提出人、判定与协调 1 个工作日内 人日价格对照表、服务说明模板 报价与服务说明 🔧+🤖
5 特批：市场销售负责人批价格；研发占用超过阈值或战略让利的，CTO 加签 特批、加签 1 个工作日内 飞书审批 特批结论 🔧+👤
6 签合同或追加合同（走 SAL-23）；收到首付款后，产品才通知研发 提出人 客户确认后 5 个工作日内 合同流程、CRM 合同、首付款到账 🔧飞书固化
7 进入研发“非标”队列排期；标品工单优先，非标不插队 判定与协调、工作量评估 到账后 1 个工作日内排期 研发排期表/工单 排期记录 🔧飞书固化
8 交付后按服务说明验收，回填受理单 提出人、实施 交付后 3 个工作日内 工单 验收记录 🔧飞书固化

5. 交付物与模板

  • 交付物：非标需求受理单、人天评估、服务说明、（追加）合同、排期记录、验收记录
  • 建议模板/表单：
    • 受理单字段：客户、客户类型（终端/渠道）、合同状态、需求描述、商务背景、期望时间、判定结论、人天、价格、审批人、首付款状态、排期
    • 人日价格对照表：人日成本价、评估费、上浮比例、最低收费
    • 服务说明模板：交付内容、交付方式（一次性）、不包含项、再次改动收费规则
    • 标准功能清单与版本边界文档：明确哪些已并入标品、哪些属于行业版

6. 异常与升级

  • 销售未说明商务背景 → 产品当天退回，不进入评估
  • 客户要求“先做后付款” → 默认拒绝；确有必要的，由市场销售负责人与 CTO 共同特批，并写明付款节点
  • 研发与销售对“渠道要不要优先”意见相反 → 当天升级 CTO 裁决
  • 客户已经在用定制功能但没有付费 → 产品发现后 1 个工作日内通知销售补签；5 个工作日内未补签的，升级市场销售负责人决定是否停用
  • 历史方案已过时 → 重新评估人天，不沿用旧价

7. 衡量指标

  • 先签后做率 = 签约并收到首付款后才动工的非标需求数 / 非标需求总数，目标 100%
  • 受理周期 = 受理单到特批结论的工作日，目标 ≤ 5 个工作日
  • 非标挤占率 = 非标工时 / 研发总工时，按月观察，超过 20% 时复盘
  • 定价遗留数 = 已评估但超过 10 个工作日仍未定价的需求数，目标 0

8. 低效诊断

  • 现象：研发和销售对标品/定制的理解不同，价格在临时讨论中给出（判定环节缺失）｜依据：「Leap产研决策部」2026-09
  • 现象：改页面类需求评估后长期没有定价，没有商务角色承接（定价环节无人负责）｜依据：「Leap产研决策部」2026-10
  • 现象：某版本已并入标品，合同仍在写，版本边界被反复问（版本边界文档缺失）｜依据：「鼎慧产研决策部」2026-07
  • 现象：研发不了解商务背景，无法排人力；客户先用后谈费用（受理与收款门槛缺失）｜依据：「某通信国企客户项目群」2026-09、「某通信国企客户项目群」2026-10
  • 现象：标准化交付里没有的功能，与客户沟通出现偏差，引发纠纷（变更单缺失）｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 只换 Logo/名称：管理后台可配置，按最低收费执行
  • 完整去商标：涉及客户端构建、管理后台、soul、skill、帮助中心五处改动；原则上少卖，必须 CTO 加签
  • 接入客户指定模型：配置 + 测试按人天计费，另收需求评估费
  • 行业版：在标品价格基础上加收行业版费用，由 COO 确认是否做成通用行业版
  • 接自有算力/API 适配：判断走定开组还是产品组，由 CTO 指定
  • 多机登录等标准化不提供的功能：一律加钱，走追加合同
  • 早期用户改 Logo 赠送：按 SAL-17 报备
  • 渠道客户：可适度让利以维护关系，但服务说明必须写明“非标准功能”
  • 纯定开项目：转项目组，按 SAL-19 报价

10. 待确认问题

  • 受理主责是产品总监，还是应设专职商务岗？
  • 人日成本价、评估费和最低收费是多少？由谁维护对照表？
  • CTO 加签的研发占用阈值定为多少人天？
  • 标准功能清单和版本边界文档由谁维护？放在哪里？
  • 与 SAL-25 的分工是否按“拦截与预期管理在 SAL-25，评估报价在本流程”划分？
SAL-22招投标与供应商入库待新建375

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：国企、政府客户采购需要走招投标、供应商入库、竞争性报价，或合作方邀请联合投标时，统一登记、评审合规性，从标准资质包取材料，分工编制标书和报价/技术响应表，交叉审核后按期提交
  • 负责人：主责——投标负责人（当前：闫登辉·推断待确认）；协同——项目商务负责人（当前：刘昱潇·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、法务负责人（当前：李瑶·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 登记招标/入库信息与截止时间 → ② 投标可行性与合规评审 → ③ 拆分任务（商务、技术、报价、资质、演示）→ ④ 调取标准资质包 → ⑤ 编制标书与响应表 → ⑥ 交叉审核 → ⑦ 用印、封装、提交 → ⑧ 结果登记与复盘
  • 交付结果：按期提交的投标文件/入库材料、投标台账记录、标准资质包（持续更新）、开标结果与复盘
  • 状态依据：频次不高但金额大；05～10 月每次都临时找材料（法人证件、社保证明、审计报告靠在群里来回问），报价表 v1～v10 反复返工，合计与分项对不上，标书分工靠群里临时分配，还出现过需要法务把关的陪标报价单。没有模板，也没有资料库

1. 场景判定

  • 触发条件：客户告知需走招标、比选、竞争性谈判；需要进入客户的供应商库；甲方下发格式化报价/技术响应表；合作方邀请联合投标；需要出具质保函
  • 典型说法：「需要对接一下意见，看怎么快速改好，走招投标」「现在还差法人身份证复印件」「里面有四张子表，对应四个版本的报价」「每个人都要学会怎么写标书」
  • 判断问题：客户是否要求按规定格式、在规定期限内提交正式文件？是 → 走本流程
  • 不归本流程管：非招标的普通报价 → 请走 SAL-19；公司证照与授权委托书的出具 → 请走 LEG-10；审计、尽调财务资料准备 → 请走 FIN-36；用印审批 → 请走 LEG-09；中标后的合同 → 请走 SAL-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
投标负责人 登记、拆分任务、主笔商务部分、终审格式与合计、按期提交 R 投标负责人（当前：闫登辉·推断待确认）
项目商务 对客对接、汇总报价表、向供应商询价 R 项目商务负责人（当前：刘昱潇·推断待确认）
材料整理 维护标准资质包、整理标书附件 R 销售运营（当前：韩诗琪·推断待确认）
资质提供 营业执照、法人证件、社保证明、审计报告、业绩证明 R 行政负责人（当前：胡则瑾·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）
技术响应 软件/硬件指标填写、演示视频 R 基座研发负责人（当前：望政韬·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）
方案把关 技术方案与承诺口径审核 C 创始人兼 CTO（当前：丁震宇·推断待确认）
合规审核 联合投标、陪标、质保函等合规意见 C 法务负责人（当前：李瑶·推断待确认）
投标决策 批准是否投、投标报价 A 市场销售负责人（当前：李鹏为·推断待确认）
兜底 资质材料调取与跨部门协调 R 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 招标文件或入库通知全文、评分细则、截止时间、提交方式（线上/纸质）
  • 投标主体（哪个公司）和是否联合投标
  • 标准资质包：营业执照、法人身份证明、授权委托书、资质证书、社保参保证明、近年审计报告、业绩合同、软著与专利清单（敏感证件限定权限查看）
  • 甲方格式化表格原件（不改格式）
  • 同类历史标书与报价

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记投标台账：项目、客户类型、主体、截止时间、提交方式、金额预估 投标负责人 获知后当天 多维表格“投标台账” 台账记录 🔧飞书固化
2 可行性与合规评审：是否投、是否联合、是否涉及陪标或替他方制作报价；涉及的必须先取得法务书面意见 投标决策、合规审核 登记后 1 个工作日内 飞书审批 评审结论 👤人工判断
3 拆分任务：商务、技术（软件/硬件分块）、报价、资质、演示各指定一人，并写明分块截止时间（倒排，留 2 个工作日审核） 投标负责人 评审通过当天 飞书任务 任务清单 🔧飞书固化
4 从资质包调取材料；缺失或过期的，当天向资质提供人索取 材料整理、资质提供 索取后 1 个工作日内提供 知识库资质包 资质附件 🔧飞书固化
5 编制：商务部分、技术响应、报价表在同一份在线文档中分块填写；AI 起草初稿后，由各分块负责人逐项核对 各分块负责人 按任务截止时间 飞书在线表格/文档、AI 标书初稿 🤖+👤
6 交叉审核：合计与分项、格式、报价与合同条款一致、承诺指标有依据；脚本校验合计 投标负责人、方案把关 截止前 2 个工作日 校验脚本、文档评论 审核记录 🤖+👤
7 定稿用印、封装、提交；质保函按模板出具 投标负责人 截止前 1 个工作日完成 用印审批、投标平台 提交回执 🔧飞书固化
8 登记开标结果；未中标的，3 个工作日内复盘；新材料回收入资质包 投标负责人、材料整理 开标后 3 个工作日内 台账 结果与复盘 🔧飞书固化

5. 交付物与模板

  • 交付物：投标文件、报价/技术响应表、资质附件、质保函、提交回执、投标台账、复盘记录
  • 建议模板/表单：
    • 投标台账字段：项目、客户类型（政府/国企/企业）、投标主体、联合方、截止时间、分块负责人、版本、状态、金额预估、结果
    • 标准资质包目录：每份材料的名称、有效期、保管人、最近更新日期、查看权限
    • 标书模板库：资质章节、案例章节、技术方案章节、报价附件、质保函模板、承诺函模板
    • 演示 Demo/录屏素材库：按功能点归档，并标注录制版本

6. 异常与升级

  • 截止时间不足 3 个工作日 → 投标负责人当天报告市场销售负责人，决定是否放弃或压缩分工
  • 资质材料缺失（如没有当年审计报告）→ 当天报告综合部负责人，确认替代材料或说明函
  • 分块负责人临近截止仍未交 → 投标负责人提醒；仍未交付的，升级 CTO 或市场销售负责人调人
  • 涉及陪标、替他方制作报价单等合规敏感事项 → 没有法务书面意见一律不做 → 当天升级 CEO
  • 报价表合计与分项对不上 → 停止提交，由投标负责人当天组织修正

7. 衡量指标

  • 按期提交率 = 按期提交的投标数 / 决定投标数，目标 100%
  • 资质调取时长 = 索取到拿到材料的工作日，目标 ≤ 1 天
  • 报价表返工版本数 = 每个项目报价表的版本数，目标 ≤ 3 版
  • 废标数 = 因资质、格式、合计错误导致的废标，目标 0
  • 中标率 = 中标数 / 投标数（按季度观察）

8. 低效诊断

  • 现象：标书编制、方案、报价、盖章的分工靠群里临时分配，方案多版本返工（任务拆分环节缺失）｜依据：「【模态】市场销售」2026-05、「【模态】市场销售」2026-07
  • 现象：法人证件、社保证明、审计报告每次临时找，审计报告有没有要多次追问（资质包缺失）｜依据：「【模态】综合部」2026-06、「【模态】综合部」2026-07
  • 现象：报价表 v1～v10 反复改，分项合计与总和对不上，需要反复催审（版本与校验环节）｜依据：「客户项目群（半导体）」2026-05
  • 现象：标书资料散落在硬盘和个人手里（资料库缺失）｜依据：「鼎慧产研决策部」2026-03
  • 现象：演示视频临时抓人录屏，并多次反馈“不够精致”（素材库缺失）｜依据：「某水利项目研发群」2026-07
  • 现象：竞争性报价时，报价单内容与合同不一致，赠送口径临时统一（报价与合同联动缺失）｜依据：「leapcore合同审查」2026-06
  • 现象：入库、质保函需要临时拟定，只能熬夜赶工（模板缺失）｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-10

9. 分支变体

  • 供应商入库：只需资质包和服务目录，不走第 5～6 步的报价部分
  • 联合投标：先确认牵头方和分工，合作协议由法务审核（LEG-04）
  • 甲方格式化报价表：多版本分表（基础版/推荐版/单厂版/全集团版等）在同一份在线表格中分块填写，不得用文件名区分版本
  • 竞争性报价/比价：我方只对自己的报价负责；凡涉及他方报价单，必须由法务事前评估合规性
  • 政府/国企：按客户采购规则合理拆分阶段，二期按询价流程；报价预留议价空间
  • 质保函、承诺函：按模板出具，个案由法务审核

10. 待确认问题

  • 投标主责是否为闫登辉所在岗位？是否需要设专职投标专员？
  • 标准资质包由谁维护（销售运营还是行政）？敏感证件的查看权限怎么设？
  • 陪标、替他方制作报价单的做法，法务给出什么结论？
  • 是否需要设定“截止时间不足 N 天默认放弃”的规则？
  • 投标台账是否与 CRM 商机打通？
SAL-23销售合同起草、条款谈判与用印待优化400

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：客户进入商务合同阶段时，销售按模板起草（含保密协议、三方签约、合同拆分），组织交付可行性与风险会签，与客户谈条款，红线条款升级，定稿后用印签署并通知交付与财务
  • 负责人：主责——合同起草销售（当前：按商机归属，如吴琪、闫登辉、杨朋伟、刘昱潇·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、销售运营（当前：韩诗琪·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 选现行模板起草 → ② 填写交付规格（引用标准套餐和规格文档）→ ③ 内部会签（市场销售负责人、交付可行性、法务、财务）→ ④ 对客谈判并记录条款修改 → ⑤ 红线条款升级 → ⑥ 定稿 → ⑦ 用印签署 → ⑧ 归档、CRM 上传，通知交付与财务
  • 交付结果：双方签署的合同（及保密协议、补充协议）、会签记录、条款修改记录，并完成 CRM 上传和交付、财务通知
  • 状态依据：已有通用版和正式销售合同模板、飞书合同盖章审批；但 04～08 月审核链路长、法务审核成为瓶颈，拖慢渠道签约；出现过拼写错误、终身权益与数量条款多轮修改；05 月合同里写的硬件形态与实际可交付不一致，导致补买机柜；7 月出台的“先签后动”“不做验收尾款”只在群里宣布。约 20 次

1. 场景判定

  • 触发条件：客户确认购买意向；客户发来自己的合同模板或修改意见；需要先签保密协议；试用转采购；需要拆分或三方签约
  • 典型说法：「给法务再看看，创始人也看看，然后再发给对方」「当时拟合同的时候喊硬件负责人审了吗」「签合同我们这边才会动，不然浪费劳动力」「以后非特殊情况，不做验收尾款」
  • 判断问题：是否已经有了确定的报价，客户要落到纸面上签字？是 → 走本流程
  • 不归本流程管：法务审查标准与多方会签规则 → 请走 LEG-03；合同模板维护 → 请走 LEG-01；用印审批 → 请走 LEG-09；保密协议文本拟定 → 请走 LEG-05；渠道代理协议 → 请走 SAL-27；合同编号与原件归档 → 请走 LEG-11；收款与赢单登记 → 请走 SAL-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
起草与谈判 选模板起草、对客谈判、记录条款修改、推进签署 R 合同起草销售（当前：吴琪、闫登辉、杨朋伟、刘昱潇、杜中瑞·推断待确认）
商务审批 价格、付款节点、回款风险 A 市场销售负责人（当前：李鹏为·推断待确认）
交付可行性会签 硬件形态、规格、部署环境、免责条款 C IT 运维/硬件（当前：杨明学·推断待确认）
技术与风险条款 软著、验收、性能、数据安全等技术口径 C 创始人兼 CTO（当前：丁震宇·推断待确认）
产品口径 功能清单、版本、赠送权益表述 C 产品总监（当前：杨萌·推断待确认）
法务审核 条款合规、红线判断 C 法务负责人（当前：李瑶·推断待确认）
用印与寄送 发起盖章流程、邮寄 R 销售运营（当前：韩诗琪·推断待确认）
兜底 红线条款和重大让步的最终决定 A（升级） COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 审批通过的报价单（SAL-19/20）及版本号
  • 签约主体（我方哪个公司、客户方哪个主体）、是否三方
  • 现行合同模板（从模板库取，不用聊天记录里的旧文件）
  • 交付规格：机型（桌面/机架 × 档位）、是否需要机房、部署方式、软件版本、赠送项
  • 付款方式：默认一次性收款；需要分期或尾款的，提前准备特批理由
  • 客户合同稿（如客户坚持用自己的模板）
  • 请求最少包含字段（发起会签时）：客户内部代号与双方签约主体、CRM 商机编号、报价单版本号、合同模板版本号、相对模板的修改项清单、硬件配置单链接、付款方式与是否特批、期望签署日与加急原因；缺项会签人一次性退回，不逐条追问

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 选现行模板起草，填写主体、金额、付款节点；客户模板则标出与我方模板的差异 起草与谈判 客户确认意向后 1 个工作日内 模板库、合同系统 合同初稿（合同系统/CRM 商机页挂载，文件名含版本号） 🤖+🔧
2 交付规格只用标准套餐描述，并链接规格文档；涉及硬件交付的，必须勾选“交付可行性会签” 起草与谈判 起草同时 规格文档 规格条款（合同附件引用规格文档链接） 🔧飞书固化
3 发起内部会签：市场销售负责人、交付可行性、产品、法务、财务并行审阅 起草与谈判 会签人 2 个工作日内回复 飞书审批会签 会签意见（飞书审批节点内填写，不在群里给意见）；超时见第 6 节 🔧飞书固化
4 发客户；客户的每轮修改都记录在“条款修改记录”中（条款、客户诉求、我方回应） 起草与谈判 收到客户意见后 1 个工作日内回应 修订模式、记录表 修改记录（条款修改记录表，挂在合同记录下） 🤖+👤
5 触及红线（软著归属、验收尾款、经济补偿、无限责任、数据本地化承诺等）→ 法务出意见，必要时咨询外部律师；COO 决定是否让步 法务审核、兜底 2 个工作日内 红线清单 红线处理结论（写入条款修改记录“决定人”列，并同步会签流）；超时→起草销售 @ COO 👤人工判断
6 定稿：核对拼写、产品名、数量、金额大小写、与报价单一致 起草与谈判 1 个工作日内 校验脚本 定稿（合同系统标“定稿”，版本号锁定） 🤖自动化
7 发起用印（走 LEG-09），签署、寄送 用印与寄送 定稿后 1 个工作日内 飞书审批“合同盖章” 签署合同（扫描件上传合同台账 LEG-11，快递单号回填）；超时→市场销售负责人 🔧飞书固化
8 签署后当天上传 CRM、移交归档，通知交付与财务（开票、收款） 起草与谈判 签署当天 CRM、群通知 交付启动通知（CRM 商机标“赢单”；交付工单按 X-DLV-07 发起并回填工单号；财务在收入合同台账 FIN-21 登记）；交付 1 个工作日未受理→订单与交付统筹 🔧+🤖

5. 交付物与模板

  • 交付物：签署版合同、会签记录、条款修改记录、红线处理结论、交付启动通知
  • 建议模板/表单：
    • 合同模板分级：标品采购/工程咨询定制/试用转采购/政企（选用见 LEG-01）
    • 硬件规格套餐表：桌面/机架 × 低/中/高，各绑定规格文档和“非标准环境意外损坏不保”条款
    • 红线条款清单：条款、红线描述、可接受替代写法、决定人
    • 条款修改记录字段：轮次、条款号、客户诉求、我方回应、决定人、日期

6. 异常与升级

  • 会签人 2 个工作日未回复 → 自动催办 → 第 3 个工作日升级市场销售负责人；法务积压时由法务负责人当天给出优先级
  • 签约后发现合同写的硬件形态与可交付不一致 → 当天报告市场销售负责人和硬件负责人 → 3 个工作日内提出补救方案（换设备或补配），换设备须法务评估风险
  • 非合同岗位提出要补充条款 → 必须指定责任人，并通过飞书任务派给起草销售，完成后同步提出人；不得只口头提
  • 客户内部驳回保密协议或采购流程 → 起草销售当天记录原因，并列出客户所需补充材料清单，5 个工作日内提交
  • 客户要求突破红线条款或我方需做重大让步 → 决定权由市场销售负责人升级至 COO → 起草销售当天提请，COO 2 个工作日内决定确需先行的，按 SAL-17 报备，赠送或试用额度以“签约后再实际充值”为原则
  • 签署后交付/财务 1 个工作日内未确认收到（无交付工单号、无台账登记）→ 起草销售在 CRM 商机页 @ 交付统筹与财务负责人 → 再 1 个工作日无回应升级市场销售负责人
  • 用印发起后 1 个工作日未盖章寄出 → 销售运营催办法务/行政 → 再 1 个工作日升级综合部负责人

7. 衡量指标

  • 合同周期 = 起草到签署的自然日，标品目标 ≤ 10 天
  • 会签时效 = 会签人平均回复工作日，目标 ≤ 2 天
  • 合同交付一致率 = 交付时与合同规格无偏差的合同数 / 签署合同数，目标 100%
  • 先签后动率 = 签约后才启动交付或定制的项目数 / 项目总数，目标 100%
  • 文本错误数 = 签署前发现的拼写、金额、数量错误，签署后目标为 0

8. 低效诊断

  • 现象：拼写错误、权益与数量条款多轮修改（定稿校验环节缺失）｜依据：「【模态】市场销售」2026-04
  • 现象：付款周期、尾款条款争议，规则 7 月才在群里宣布（付款规则没有固化到模板）｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-07
  • 现象：渠道合同等法务确认导致签约变慢（法务审核排队、无优先级）｜依据：「【模态】市场销售」2026-07、「【模态】市场销售」2026-08
  • 现象：合同条款在群里集体讨论，软著、验收、经济补偿类问题反复出现（缺少红线清单）｜依据：「字字可研市场运营」2026-04
  • 现象：合同签完才发现硬件形态与实际可交付不一致，客户没有机房，只能补买机柜（交付可行性会签缺失）｜依据：「LeapCore（archived）」2026-05
  • 现象：补充条款靠口头提出，靠记忆跟进（条款变更需求没有闭环）｜依据：「leapcore 合同审核群」2026-07
  • 现象：交付先于合同，保密协议被客户内部驳回，进度卡约 2 周（合同状态没人跟踪）｜依据：「某金融国企客户项目群」2026-08

9. 分支变体

  • 标品采购合同：用通用版模板，只填主体、数量、金额、规格套餐
  • 工程咨询类定制合同：附功能清单与验收标准，产品口径会签必选
  • 试用先行后采购：先签试用协议并给固定赠送额度，签采购合同后再实际充值
  • 保密协议与三方签约：保密协议主体须与采购主体一致；三方协议可以拆成两两签署
  • 政府/国企：合同额与服务内容须能通过客户审计；客户内部评议要求的补充材料（如数据分类分级、技术论证）由 CTO 指定人撰写
  • 客户模板：优先争取用我方模板；只能用客户模板的，法务必须逐条审核
  • 协作协议：遵循 ALL-04（跨部门交接契约）、ALL-03（决策记录与发布）、ALL-06（卡点升级阶梯）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 合同起草主责是否为商机归属销售？是否应设合同专员统一起草？
  • 硬件交付可行性会签是否对所有涉及硬件的合同强制执行？
  • 红线条款清单由法务出初稿，COO 确认，是否可行？
  • “先签后动”“不做验收尾款”是否已写进销售制度？特批人是谁？
  • 本流程第 3 步会签与 LEG-03 是否合并为同一个审批流？
SAL-24收款条件、赢单登记与回款跟踪待优化72

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：签约前要确认收款条件（默认先款后货，不赊账、不货到付款）；合同签署或赢单后，销售在 CRM 上传合同、关联商机、标记赢单、登记回款计划，财务确认到账后再通知交付
  • 负责人：主责——商机归属销售（当前：按商机归属，如杨朋伟、杜中瑞、吴琪、刘昱潇·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：郭逸非、陈子康·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 签约前确认收款条件 → ② 例外情况特批 → ③ 签署后 CRM 上传合同并关联商机 → ④ 标记赢单 → ⑤ 登记回款计划 → ⑥ 财务确认到账 → ⑦ 到账后通知交付/发货 → ⑧ 逾期催收升级
  • 交付结果：CRM 中状态为“赢单”的商机（含合同附件或收款凭证）、回款计划与到账记录、到账后发出的交付通知
  • 状态依据：CRM 合同模块已经跑通（09～10 月），先款后货规则也已在群里宣布；但规则没有成文，销售仍会问“能不能货到付款”；渠道“早预订没提单”引发争议；上传失败、无法关联商机约 6 次；无合同个人采买用什么作凭证、财务如何确认到账、合同系统与 CRM 的边界都不清楚

1. 场景判定

  • 触发条件：客户或渠道要求货到付款、赊账、先发货；合同已签需要登记赢单；个人采买没有合同；回款到期
  • 典型说法：「都是先款后货，目前没有特殊情况，不做赊账生意」「没有合同，都无法变为赢单，也无法作为业绩考核指标」「个人采买没签合同，可以用汇款截图做凭证吗」
  • 判断问题：这一单是否已经（或即将）产生应收款？是 → 走本流程
  • 不归本流程管：财务到账核对、收入确认与合同台账 → 请走 FIN-21；开票 → 请走 FIN-19；线上充值到账与额度开通 → 请走 FIN-17；CRM 客户与商机录入 → 请走 SAL-04；提成核算 → 请走 SAL-34；渠道订单 → 请走 SAL-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
商机归属销售 确认收款条件、上传合同、登记回款计划、催收 R 商机归属销售（当前：杨朋伟、杜中瑞、吴琪、刘昱潇·推断待确认）
收款例外特批 批准赊账、货到付款、先发货、分期 A 市场销售负责人（当前：李鹏为·推断待确认）
CRM 管理 合同管理权限、编辑/作废审核、数据迁移 R CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）
CRM 系统 上传、关联、校验、报错提示等功能维护 R CRM 研发（当前：郭逸非、陈子康·推断待确认）
到账确认 确认到账并在 CRM 标记 R 财务负责人（当前：黄梦婷·推断待确认）
规则口径 收款规则解释 C 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 签署版合同扫描件（或个人采买的收款凭证截图）
  • CRM 中已存在的客户和商机
  • 合同编号（不得与已有编号重复）
  • 付款节点与金额计划
  • 例外情况的特批审批编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签约前向客户明确收款条件：设备先款后货、软件与词元先付后用；合同付款条款按此写 商机归属销售 报价或合同起草时 合同模板 收款条款 🔧飞书固化
2 客户要求赊账、货到付款、先发货或分期的 → 提交特批 商机归属销售、收款例外特批 1 个工作日内审批 飞书审批 特批结论 🔧+👤
3 合同签署后，在 CRM 新建合同并关联商机，上传附件（单个文件不超过系统上限） 商机归属销售 签署后 1 个工作日内 CRM 合同模块 合同记录 🔧飞书固化
4 系统校验附件和编号，通过后商机自动变为“赢单”；无合同的个人采买上传收款凭证，并标“无合同” 商机归属销售、CRM 系统 即时 CRM 赢单状态 🤖自动化
5 按付款节点登记回款计划 商机归属销售 与第 3 步同时 CRM 回款计划 🔧飞书固化
6 合同上传后自动通知财务；到账后财务在 CRM 标记已到账 到账确认 到账后 1 个工作日内 CRM + 机器人通知 到账记录 🔧+🤖
7 到账（或特批通过）后才通知交付与发货 商机归属销售 到账标记当天 交付群/交付表单 交付通知 🔧飞书固化
8 回款到期前 3 个工作日自动提醒；逾期 7 天销售催收，逾期 15 天升级 商机归属销售、收款例外特批 按节点 CRM 提醒 催收记录 🤖自动化

5. 交付物与模板

  • 交付物：CRM 合同记录（含附件）、赢单状态、回款计划、到账记录、特批记录、催收记录
  • 建议模板/表单：
    • 赢单必备材料清单：签署合同（或收款凭证 + 无合同标记）、合同编号、关联商机、回款计划
    • 收款例外特批单字段：客户、合同金额、例外类型（赊账/货到付款/先发货/分期）、理由、预计回款日、风险措施
    • 回款计划字段：节点、金额比例、预计日期、实际到账日期、状态

6. 异常与升级

  • 上传失败、无法关联商机、报“服务不可用” → 截图报给 CRM 研发，1 个工作日内修复；修复前在 CRM 管理员处登记，不影响业绩认定
  • 合同编号重复 → 系统提示，由 CRM 管理员 1 个工作日内核对改号
  • 已签合同需要修改或作废 → 由 CRM 管理员审核后操作，并留存原版
  • 渠道“早预订但没提单” → 以提单时间为准，按渠道政策（定金/框架协议）决定是否先发，由市场销售负责人裁决
  • 逾期 15 天未回款 → 升级市场销售负责人，暂停该客户的新增交付；逾期 30 天，通知法务评估

7. 衡量指标

  • 合同上传及时率 = 签署后 1 个工作日内上传的合同数 / 签署合同数，目标 ≥ 95%
  • 例外特批率 = 走特批的单数 / 签约单数，按月观察，目标 ≤ 10%
  • 先款后货执行率 = 到账（或已特批）后才发货的单数 / 发货单数，目标 100%
  • 回款逾期率 = 逾期回款金额 / 应收金额，目标 ≤ 5%
  • CRM 上传故障次数 = 每月因系统原因上传失败的次数，目标 0

8. 低效诊断

  • 现象：没有合同就无法赢单，上传失败、无法关联商机反复出现（系统校验与容量设置环节）｜依据：「跃迁CRM反馈群」2026-09
  • 现象：无合同个人采买能否用收款截图作凭证，需要逐例询问（赢单凭证标准缺失）｜依据：「跃迁CRM反馈群」2026-09
  • 现象：合同后续修改由另一套合同系统控制，到账登记要挂在结单移交下，边界不清（多系统衔接环节）｜依据：「跃迁CRM反馈群」2026-09、「跃迁CRM反馈群」2026-10
  • 现象：销售不确定能否货到付款，规则只在群里口头宣布；渠道早预订没提单引发争议（收款规则未成文）｜依据：「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-10

9. 分支变体

  • 设备销售：严格先款后货；渠道预订机按渠道政策收取定金或签框架协议后再排产
  • 软件订阅/词元：先付后用；试用额度按 SAL-17 处理，不计入应收
  • 无合同个人采买：上传收款凭证、标“无合同”，经财务确认到账后才算赢单
  • 渠道/算力充值订单：走渠道系统和充值流程（SAL-31、FIN-17），不在 CRM 重复登记
  • 旧版合同数据：由 CRM 管理员统一迁移，迁移完成前以旧系统为准
  • 试用机：试用审批走 SAL-16，样机外借与出入库走 ADM-29，不算销售

10. 待确认问题

  • 先款后货的例外特批人是市场销售负责人，还是需要财务联签？
  • 无合同个人采买以收款凭证认定赢单，财务和法务是否同意？
  • CRM 与合同系统的边界：合同修改、作废、到账确认各在哪个系统里做？
  • 回款逾期的升级时点（7 天/15 天/30 天）是否合适？
  • 赢单认定以“合同上传”为准，还是以“首款到账”为准（影响业绩口径，需与 SAL-34 对齐）？
SAL-25合同范围外需求拦截与客户预期管理待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：已签约或已出方案的客户提出合同、方案书、报价单里没有的新需求（新功能、二开接口、外部系统对接、资质协助、专属界面、人数或资源超出方案档位等）时启动。
  • 负责人：主责——客户归属销售（当前：吴琪、刘昱潇·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO/客户关系（当前：常元和·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT/现场交付（当前：杨明学·推断待确认）；兜底——销售负责人
  • 核心流程：① 一线不当场承诺 → ② 1 个工作日内登记需求变更单 → ③ 对照合同/方案书判定范围 → ④ 分流（拒绝/通用功能排期/转定制报价/免费有限支持审批）→ ⑤ 书面答复客户 → ⑥ 承诺归档到 CRM
  • 交付结果：每条范围外需求对应一张已判定、已书面答复客户的《需求变更单》（含结论、费用口径、排期、对客承诺原文），挂在该客户的 CRM 记录下。
  • 状态依据：公司没有成文的“一线可答应范围”，是否在合同内、收不收费全靠技术负责人个人把关；2026-02～05 客户项目群里多次出现“不在合同范围里，别答应”“需求不匹配方案”，还有条款不写进合同、事后再补承诺函的做法。

1. 场景判定

  • 触发条件：客户在现场、电话或群里提出合同/方案书/报价单之外的需求；实际使用人数、并发、容器、硬件资源超出方案档位；客户要求为其单独定制界面或流程。
  • 典型说法：「能不能顺便帮我们接一下财务系统」「给我们单独做个登录页」「顺手帮我们把软著/补贴也申请了」「人多了容器不够分」「这个不在合同范围里，你别答应就行」
  • 判断问题：① 合同、方案书、报价单里有没有明确写？② 这是所有客户都能用的通用能力，还是只给这一家做？③ 需要额外人天、硬件，或依赖对方开放接口吗？
  • 不归本流程管：已决定要做、需要出定制报价 → 请走 SAL-21；合同条款起草或补充协议 → 请走 SAL-23；交付实施期内的定制需求拆解排期 → 请走 X-DLV-10；赠送额度、借机 → 请走 SAL-17；售后期新需求的可行性确认 → 请走 X-CS-14；扩容加席位 → 请走 X-DLV-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求登记与对客答复 接收需求、登记变更单、书面答复、归档承诺 R 客户归属销售（当前：吴琪、刘昱潇·推断待确认）
现场一线 只记录不答复，当天转给客户归属销售 R IT/现场交付（当前：杨明学·推断待确认）
范围与收费口径判定 判定是否在合同内、给出收费思路 R CTO（当前：丁震宇·推断待确认）
技术边界评估 判断能否做成通用能力、估算工作量 C Leap 研发负责人（当前：王皓南·推断待确认）
需求池与排期 通用能力是否进需求池、排哪个版本 C 产品总监（当前：杨萌·推断待确认）
客户关系 需要拒绝或改为收费时，负责高层沟通 C COO（当前：常元和·推断待确认）
承诺函/补充条款审核 审核免费支持承诺函或补充条款 C 法务负责人（当前：待指定）
免费有限支持审批 审批不收费的让步，兜底裁决 A 销售负责人（当前：李鹏为·推断待确认）

3. 办之前请准备

  • 客户合同、方案书、报价单（重点看功能清单、人数/硬件档位、服务范围、免责条款）
  • 需求原话（截图或纪要）、提出人、提出渠道、期望完成时间
  • 量化信息：用户数、机器台数、IP/带宽、要对接的外部系统及其是否开放 API
  • 该客户以往的变更单与承诺记录（CRM）
  • 一线口径卡：哪些可以当场答、哪些必须回去汇报

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 现场或线上接到需求，统一回复“记录下来，回去确认后书面答复”，不当场答应 一线人员/客户归属销售 当场 一线口径卡 需求原话记录 👤人工判断
2 登记《需求变更单》，补齐量化信息 客户归属销售 接到后 1 个工作日内 飞书审批/多维表格 变更单 🔧飞书固化
3 对照合同、方案书自动比对功能清单，标出“在内/部分在内/不在内” 客户归属销售 登记后 1 个工作日内 CRM 合同附件 + AI 比对 范围比对结论 🔧+🤖
4 判定范围与收费口径；需要时研发给出工作量和通用化可能 CTO、Leap 研发负责人 2 个工作日内 变更单评论 判定结论（四选一） 👤人工判断
5 分流：拒绝 → 第 6 步；通用能力 → 进需求池排期；需收费 → 转 SAL-21 报价；免费有限支持 → 销售负责人审批，写明上限 产品总监/客户归属销售/销售负责人 判定后 1 个工作日内 需求池、飞书审批 分流记录 🔧飞书固化
6 起草对客书面答复（结论、费用、排期、边界），涉及承诺函或补充条款先过法务 客户归属销售、法务 分流后 2 个工作日内 飞书文档 对客答复/承诺函 🤖自动化
7 拒绝或改收费时，由客户关系负责人同步沟通 COO 按需，答复发出前 电话/会议 沟通纪要 👤人工判断
8 答复和承诺原文归档到 CRM，交付/售后可查 客户归属销售 答复当天 CRM 承诺台账 🔧飞书固化

5. 交付物与模板

  • 交付物：已关闭的《需求变更单》、对客书面答复（或承诺函/补充协议）、CRM 承诺记录。
  • 建议模板/表单：《需求变更单》字段——客户、合同编号、需求原话、提出人/渠道、提出日期、量化信息、是否在合同内（是/否/部分）、处理分类（拒绝/通用能力/定制收费/免费有限支持）、工作量（人天）、费用口径、排期版本、审批人、对客答复文本、答复日期、归档链接。
  • 一线口径卡：可当场答复（合同已列功能的用法、已排期的通用功能时间）／必须汇报（新功能、对接、资源扩容、资质协助、费用）。

6. 异常与升级

  • 发现一线已经口头答应 → 销售 1 个工作日内补变更单，CTO 判断要不要撤回或收费 → 涉及费用让步升级销售负责人（2 个工作日内）。
  • 客户不接受拒绝或收费、施压进度 → COO 出面沟通 → 仍僵持升级 CEO（3 个工作日内）。
  • 需求依赖对方系统开放接口而对方不开放 → 书面告知不可实施，结案。
  • 免费支持实际工作量超过审批上限 → 暂停并转 SAL-21 报价，同时通知客户。

7. 衡量指标

  • 范围外需求登记率 = 有变更单的范围外需求 ÷ 识别到的范围外需求，目标 100%。
  • 答复周期 = 登记到书面答复的工作日，目标 ≤ 5 个工作日。
  • 无偿追加工作量 = 每季度免费有限支持累计人天，目标逐季下降并有审批记录。
  • 口头承诺补登次数 = 先答应后补单的次数，目标每季度 ≤ 1。

8. 低效诊断

  • 现象：一线接触环节没有统一的“可答应范围”，客户电话直接打给现场人员，答不答应靠个人判断｜依据：「LeapCore（archived）」2026-02、2026-03
  • 现象：判定环节集中在单一技术负责人，同类收费口径问题被反复问，无成文规则｜依据：「LeapCore（archived）」2026-03
  • 现象：售前方案与客户实际需求不匹配，交付期才发现人数、界面诉求超出方案，产研被迫追加｜依据：「LeapCore（archived）」2026-05
  • 现象：条款不写进合同、事后补承诺函，承诺缺少留痕位置，后续交付和售后无处可查。

9. 分支变体

  • 直接拒绝：单客户专版界面/专属登录页（用户统一走 LeapCore 登录，不做单客户专版）。
  • 转通用能力排期：多个客户都会用的能力（如容器一对多、多协作者），进需求池，按版本 OTA 后通知客户。
  • 转 SAL-21 定制报价：二开 API、外部财务软件或自研系统接入（前提是对方开放 API）、机房托管/资源租用（先问清台数、IP、带宽再报价）。
  • 免费有限支持：资质协助类（软著材料、算法备案依赖清单），审批时写明工作量上限，超出转收费。
  • 政策补贴申报类服务：收费或分账，必须在服务开始前书面约定，分账比例由管理层审批。
  • 人数/资源超出方案档位：回到方案书档位沟通，确需扩容走 X-DLV-33。

10. 待确认问题

  • 主责是否由客户归属销售承担？现场交付人员接到需求是否一律转销售？
  • 范围判定的 A 角是 CTO 还是销售负责人？是否需要设 B 角，避免单点？
  • “免费有限支持”的审批上限设多少人天？超出由谁拍板？
  • 一线口径卡的“可当场答复”清单由谁维护、多久更新一次？
  • 政策补贴申报分账、外部系统接入是否已有统一价格或比例？是否需要法务出标准承诺函模板？
SAL-26API/额度类分销订单（API 转售、卡密、第三方商城）待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：外部客户或分销平台要购买公司的模型 API 或产品额度（API 转售、发卡平台卡密、第三方商城上架）时启动，覆盖报价、收款、开通、交付和对账。
  • 负责人：主责——API 分销商务负责人（当前：丁震宇·推断待确认）；协同——网关与计费研发（当前：王皓南·推断待确认）、运维部署（当前：宋祺睿·推断待确认）、产品总监（当前：杨萌·推断待确认）、商城对接产品经理（当前：黄飞鹏·推断待确认）、财务（当前：待指定）；兜底——销售负责人
  • 核心流程：① 询单登记 → ② 资质与转售合规核查 → ③ 按价格表报价审批 → ④ 先收款 → ⑤ 上游充值 → ⑥ 网关开号限额/生成卡密 → ⑦ 交付 key 与文档 → ⑧ 用量监控与月度对账入账
  • 交付结果：一笔已收款、已开通、已对账的分销订单：订单台账记录、网关 key（含额度与并发上限）或卡密批次、对客交付文档、对账单与入账记录。
  • 状态依据：属于新业务，没有合同模板、订单台账和充值/入账规则；2026-02、2026-04 在产研群里价格系数、限额、入账主体、提成都是聊天里口头定，客户当天要结果，工程师临时加班开通；卡密由谁生成、谁核销也是临时讨论。

1. 场景判定

  • 触发条件：外部客户（含海外）要采购模型 API；渠道平台要上架公司产品额度并要求提供卡密；第三方商城调整结算规则、要求填调价单。
  • 典型说法：「有人想买我们的视频 API」「都先款后开号」「超过并发上限的排队」「key 需要你们预先生成，我们入库到发卡平台」
  • 判断问题：① 买的是 API/额度（虚拟商品），还是软硬件一体机？② 上游协议是否允许转售？③ 款到了吗？
  • 不归本流程管：一体机/LeapCore 软硬件订单 → 请走 SAL-31；上游平台充值付款 → 请走 FIN-03；客户充值到账审核 → 请走 FIN-17；对外价格表、倍率调整 → 请走 X-PRD-22；渠道/开发者分成打款 → 请走 FIN-23；业务合规红线判断 → 请走 LEG-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分销商务 接单、谈价、定系数、客户沟通、订单登记 A API 分销商务负责人（当前：丁震宇·推断待确认）
网关与计费 价格参数、限额、并发、计费、卡密生成与核销接口 R 网关与计费研发（当前：王皓南·推断待确认）
部署运维 域名、反代、环境、冒烟测试 R 运维部署（当前：宋祺睿·推断待确认）
商城价格规则 商城上架价/供货价口径、调价单 R 商城对接产品经理（当前：黄飞鹏·推断待确认）
产品口径 确认上架价、额度包规格 C 产品总监（当前：杨萌·推断待确认）
收款/上游充值/入账 确认到账、发起上游充值、确定入账主体、对账开票 R 财务（当前：待指定）
转售合规 上游协议是否允许转售、对外合同条款 C 法务负责人（当前：待指定）
提成核算 订单提成与归属 I 销售负责人（当前：待指定）

3. 办之前请准备

  • 当前版本的 API/额度价格表（官方价、加成系数、加并发/多开 key 的加价规则）
  • 客户信息：主体名称、国家/地区、用途、预计用量、需要的并发
  • 上游平台转售许可依据（协议条款）与当前上游余额
  • 订单确认函/合同模板、对客接入文档与示例（skill）
  • 卡密场景：额度包规格、卡密数量、核销网址、渠道结算周期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 询单登记到分销订单台账（客户、产品、预计金额、并发） 分销商务 询单当天 多维表格 订单记录 🔧飞书固化
2 核查客户资质、用途、地区，以及上游是否允许转售 分销商务、法务 1 个工作日内 台账 + 上游协议 合规结论 👤人工判断
3 按价格表计算单价（官方价×系数，加并发另计），超出折扣权限的走审批 网关与计费研发、分销商务 1 个工作日内 价格计算器、飞书审批 报价单 🤖+👤
4 发报价与订单确认函，约定先款后开号、额度、并发、退款规则 分销商务 报价审批后 1 个工作日内 飞书文档 确认函 🔧飞书固化
5 财务确认到账，在台账勾选“已收款”，同时确定入账主体 财务 到账后 1 个工作日内 台账、银行流水 到账确认 🔧飞书固化
6 上游余额不足时发起上游充值申请 分销商务 → 财务 到账确认后 1 个工作日内 飞书审批（FIN-03） 充值记录 🔧飞书固化
7 网关建 key 并配置额度上限、并发上限（超出排队）、余额告警；卡密场景批量生成卡密、录入渠道发卡平台 网关与计费研发 收款后 1 个工作日内 自建网关、卡密脚本 key/卡密批次 🤖自动化
8 冒烟测试通过后，发 key、接入文档与示例 运维部署、网关与计费研发 开通当天 网关、文档站 交付记录 🔧飞书固化
9 每日用量与余额告警，月末导出用量做对账、开票、提成登记 网关与计费研发、财务 每月 5 日前 网关账单、台账 对账单 🤖自动化

5. 交付物与模板

  • 交付物：分销订单台账记录、报价单、订单确认函、key 或卡密批次清单、对客接入文档、月度对账单、入账与提成记录。
  • 建议模板/表单：分销订单台账字段——订单号、客户、地区、产品/模型、价格系数、单价、预付款、到账日期、入账主体、上游充值单号、额度上限、并发上限、key/卡密批次号、交付日期、当月用量、对账状态、开票状态、提成归属。
  • 卡密批次表：批次号、额度包规格、数量、生成时间、交付渠道、已核销数、结算状态。
  • 商城调价单：原供货价、现供货价、零售价、平台扣点规则、审批人。

6. 异常与升级

  • 客户要求先开号后付款 → 默认拒绝；确需放行由销售负责人审批并写明额度上限（当天）。
  • 客户用量接近额度或并发打满 → 网关告警 → 分销商务 1 个工作日内联系客户追加预付款；超额停止服务。
  • 上游余额不足或被限流 → 分销商务通知客户预计恢复时间 → 升级财务加急充值（当天）。
  • key 或卡密泄露、异常核销 → 立即冻结批次 → 研发排查 → 升级 CTO（2 小时内）。
  • 入账主体或提成归属有争议 → 财务负责人裁定（3 个工作日内）。

7. 衡量指标

  • 开通周期 = 到账到交付 key 的工作时间，目标 ≤ 1 个工作日。
  • 先款后号执行率 = 先收款再开通的订单 ÷ 全部订单，目标 100%。
  • 对账差异率 = 月度网关用量与账单差额 ÷ 当月应收，目标 ≤ 1%。
  • 上游垫资天数 = 上游充值早于客户到账的天数，目标 0。

8. 低效诊断

  • 现象：定价系数、限额、入账主体、提成都在群聊中口头确定，没有订单台账，事后要回头查“这笔账入哪了”｜依据：「鼎慧产研决策部」2026-04
  • 现象：客户当天要结果，开通环节没有标准开号与测试步骤，工程师临时加班开通｜依据：「鼎慧产研决策部」2026-04
  • 现象：卡密合作中“谁生成、谁核销、怎么结算”职责未提前约定，靠群里反复确认｜依据：「鼎慧产研决策部」2026-02
  • 现象：第三方商城的零售价、供货价口径理解不一致，没有价格联动表。

9. 分支变体

  • 视频 API 转售（海外客户）：先款后开号；多开 key、提并发另行加价；注意境外收款，走 FIN-22。
  • 国内 API 客户：同上，开票走 FIN-18。
  • 发卡平台卡密：我方预先生成卡密 → 入库渠道发卡平台 → 用户在渠道购买 → 跳转我方核销页使用；按结算周期对账，分成走 FIN-23。
  • 第三方智能体商城：供货价 = 零售价扣除平台扣点与税点；调价需填平台调价单，上架价由产品总监确认。

10. 待确认问题

  • API 分销是否继续由 CTO 主责，还是交给销售或运营部门？
  • 价格系数、加并发加价规则是否已有成文价格表？由谁维护？
  • 上游平台是否明确允许转售？是否需要法务出具意见？
  • 入账主体按什么规则定？提成如何计算、由谁核定？
  • 卡密由我方生成和核销的方案是否定稿？核销页由谁维护？
SAL-27渠道伙伴开发、授权政策与协议签署待优化400

状态：待优化｜证据：有证据（卡片 9 张 / 会话 9 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：出现有代理/经销意向的伙伴（硬件厂商、运营商、云平台、集成商、个人或机构）时启动，从准入评估、政策洽谈、授权等级到协议定稿签约。
  • 负责人：主责——渠道负责人（当前：闫登辉·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认，政策与等级审定）、渠道销售（当前：吴琪、杜中瑞、时建、陈名赞、朱文瑜、刘昱潇·推断待确认）、法务负责人（当前：李瑶·推断待确认）、生态市场总监（当前：许君·推断待确认）、产品总监（当前：杨萌·推断待确认）、CEO（当前：邴龙志·推断待确认，分润与合资类决策）；兜底——销售负责人
  • 核心流程：① 渠道线索登记 → ② 准入评估 → ③ 洽谈分工与政策 → ④ 等级与非标条款审定 → ⑤ 按现行模板拟协议 → ⑥ 法务审查 → ⑦ 用印签署 → ⑧ 台账登记、系统开户、转培训
  • 交付结果：已签署的渠道代理协议（引用当前启用模板版本和产品清单），渠道台账记录，渠道系统账号，进入培训陪跑的渠道名单。
  • 状态依据：已有《LeapCore 产品渠道管理办法》、渠道代理协议模板、渠道拓展执行方案和渠道培训 SOP；但 2026-07 同一协议一周内出了约 7 个版本，2026-08～09 独家条款与政策不一致、价格模板未更新、法务提示价格限制条款有反垄断风险，并被指出“没有专人负责渠道管理”。

1. 场景判定

  • 触发条件：展会、活动、转介绍、电销中出现有意代理 LeapCore 或一体机的伙伴；伙伴提出独家、区域、行业授权；需要与硬件厂商、云平台谈分工和分润。
  • 典型说法：「签了协议才是开始，后面要重点跟进他们怎么卖」「渠道嗷嗷待哺需要签约」「以后都按货到付款，不给账期」「代理商包办硬件采购测试销售售后，我们只管硬件之外的东西」
  • 判断问题：① 对方是要转售我们的产品（渠道），还是自己采购使用（终端客户）？② 要的是标准渠道政策，还是独家/联合运营/合资等非标安排？③ 有没有客户资源和出货能力？
  • 不归本流程管：渠道提出预装、贴牌、联合开发 → 请走 SAL-28；签约后培训陪跑 → 请走 SAL-29；渠道台账、评级、分润结算 → 请走 SAL-30；渠道报备与下单 → 请走 SAL-31；设立合资公司、股东协议 → 请走 LEG-06；终端客户销售合同 → 请走 SAL-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
渠道统筹 线索池、准入评估、推进签约、协议改稿与版本管理 R 渠道负责人（当前：闫登辉·推断待确认）
渠道洽谈 拜访、介绍政策、收集对方诉求 R 渠道销售（当前：吴琪、杜中瑞、时建、陈名赞、朱文瑜、刘昱潇·推断待确认）
政策与等级审定 渠道等级、独家授权、返点、任务量、付款政策 A 销售负责人（当前：李鹏为·推断待确认）
分润与合资决策 token/硬件分润比例、联合运营、合资公司 A（升级） CEO（当前：邴龙志·推断待确认）
技术分工确认 硬件适配、国产化、认证等技术边界 C CTO（当前：丁震宇·推断待确认）
协议法务审查 独家定义、保护期、价格限制、违约条款 C 法务负责人（当前：李瑶·推断待确认）
产品口径 协议中产品清单、行业版型号 C 产品总监（当前：杨萌·推断待确认）
物料与资料库 渠道宣讲 PPT/FAQ、协议终版归档 C 生态市场总监（当前：许君·推断待确认）
治理结构意见 合资/联合运营的董事会、表决机制 C COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 渠道方基本信息：主体名称、统一社会信用代码、法定代表人、主营业务、客户资源、出货能力、覆盖区域/行业
  • 现行渠道管理办法、渠道政策（等级定义、价格、返点、任务量、付款方式）
  • 当前启用版本的渠道代理协议模板与条款清单；产品方维护的产品/行业版清单
  • 已签渠道清单（检查区域、行业是否与现有独家冲突）
  • 渠道宣讲 PPT、FAQ、案例
  • 请求最少包含字段（提交审定/法务审查时）：渠道名称与类型、拟授权区域与行业、申请等级、是否独家及条件、返点与付款方式、与现有渠道冲突检查结果、协议模板版本号、修改项清单、期望签约日；缺项审定人或法务一次性退回

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 渠道线索登记（来源、意向、联系人、区域、行业） 渠道销售 首次接触后 1 个工作日内 CRM/渠道线索表 线索记录（渠道线索表，群内只发链接） 🔧飞书固化
2 准入评估：资源、出货能力、是否与已签独家冲突，AI 生成背景调研摘要 渠道销售、渠道负责人 3 个工作日内 准入评估表 + AI 准入结论（准入评估表“通过/不通过”，回写线索记录）；超时→销售负责人 🔧+🤖
3 拜访/邀约来公司演示，讲解渠道政策，记录对方诉求（等级、独家、返点、付款） 渠道销售 准入通过后 5 个工作日内 渠道宣讲包 洽谈纪要（挂在线索记录下，含对方诉求清单） 👤人工判断
4 标准政策直接套用；独家/区域/任务量/返点让步提交审定；分润比例、联合运营、合资提交 CEO 渠道负责人 → 销售负责人/CEO 提交后 3 个工作日内 飞书审批 审定结论（渠道政策审批单，审批通过记录即为唯一口径，不以会上口头为准）；超时见第 6 节 🔧飞书固化
5 用当前启用版本模板拟协议，产品清单直接引用产品方维护版本；修改意见用文档评论，不另存多份文件 渠道负责人 审定后 2 个工作日内 飞书云文档（版本记录） 协议草稿（唯一云文档，用版本记录区分，不传多份文件） 🔧飞书固化
6 AI 首轮条款审查，法务终审（独家定义、保护期上限、价格限制合规、违约） 法务负责人 3 个工作日内 AI 审查 + 法务审批 法务审定稿（飞书审批通过 + 文档“法务审定”版本标记）；超时→渠道负责人催办，再超 1 个工作日→综合部负责人 🔧+🤖
7 用印、寄送，跟进对方内部审批与签署 渠道负责人/渠道销售 对方签署前每周跟进 1 次 LEG-09 用印流程 双方签署协议（扫描件登记合同台账 LEG-11，跟进记录写线索记录） 🔧飞书固化
8 协议上传渠道系统开通渠道账号，登记渠道台账，终版归档资料库 渠道负责人、生态市场总监 签署后 2 个工作日内 渠道系统、知识库 渠道账号（渠道系统）、渠道台账记录（SAL-30 台账）、终版协议（知识库渠道目录）；账号 2 个工作日未开通→渠道系统负责人 🔧飞书固化
9 转入培训陪跑（SAL-29），重点渠道安排授牌 渠道负责人 签署后 5 个工作日内启动 培训台账 培训排期（培训台账记录，并通知渠道方对接人） 👤人工判断

5. 交付物与模板

  • 交付物：渠道准入评估表、政策审定记录、签署版渠道代理协议、渠道台账记录、渠道系统账号。
  • 建议模板/表单：渠道准入评估表——渠道名称、类型（硬件厂商/运营商/云平台/集成商/个人）、区域、行业、客户资源说明、出货能力、是否申请独家、与现有渠道冲突检查、建议等级、评估人。
  • 渠道政策审批单——等级、授权范围（区域+行业）、独家条件（任务量、出货方式、未完成处理）、返点、付款方式（默认货到付款不给账期）、保护期、特殊让步及理由。
  • 渠道等级定义表：一般/金牌/钻石的门槛与权益（由销售负责人维护）。

6. 异常与升级

  • 对方要求独家或长期授权 → 销售负责人审定，涉及多年独家或全区域独家升级 CEO（5 个工作日内）。
  • 涉及 token/硬件分润比例、联合运营或合资公司 → 决定权由销售负责人升级至 CEO → 渠道负责人整理方案提请，CEO 5 个工作日内决定政策需调整的，先改政策再改协议。
  • 法务提示合规风险（价格限制、排他） → 改条款，不得带风险签署。
  • 对方内部审批超过 30 天未签 → 渠道负责人复盘是否继续投入，向销售负责人报备。
  • 协议未签先发演示机或先开展业务 → 停止发货，先补签或签临时合作确认函（当天上报销售负责人）。
  • 政策审定提交后 3 个工作日无结论 → 渠道负责人在审批流催办一次 → 再超 2 个工作日升级 CEO 或由 CEO 授权销售负责人代决。
  • 政策口径有变（等级、返点、付款方式）→ 先更新渠道政策文档并在销售群发公告链接，再改协议；未更新文档的口头口径不作为签约依据。

7. 衡量指标

  • 签约周期 = 准入通过到双方签署的自然日，目标 ≤ 30 天。
  • 协议返工次数 = 单份协议法务审定后再修改的次数，目标 ≤ 1。
  • 政策一致率 = 抽查协议条款与现行政策一致的比例，目标 100%。
  • 签约后 90 天出单率 = 90 天内有订单的新签渠道 ÷ 新签渠道，目标 ≥ 50%（待确认）。

8. 低效诊断

  • 现象：协议评审靠群里“找茬”和文件改名，一周出多个版本，传错版本还要删旧版｜依据：「【模态】渠道建设」2026-07
  • 现象：协议中的产品口径（行业版是否同一产品）在评审会上临时对齐，写进了尚不存在的版本｜依据：「【模态】渠道建设」2026-07
  • 现象：渠道政策在周例会口头宣布，未参会的商务不知情，导致合同条款与政策不一致｜依据：「leapcore 合同审核群」2026-08、2026-09
  • 现象：价格模板未及时更新、渠道价与终端价界定靠群里问；渠道管理没有专职岗位｜依据：「【模态】市场销售」2026-08、2026-09
  • 现象：分润比例前后出现两套口径，比例变了要回头统一｜依据：「【跃迁】合伙人会议」2026-06
  • 现象：渠道方内部上会、法务审核周期长，缺少签约跟进节奏｜依据：「【模态】市场销售」2026-09
  • 现象：先放演示机、联合推广，协议后补｜依据：「某客户项目群」2026-06

9. 分支变体

  • 硬件厂商/整机渠道：代理商负责硬件采购、测试、销售、售后，我方负责软件与服务；涉及预装贴牌的转 SAL-28。
  • 运营商、国产芯片、云平台联合运营：需要联合运营方案、分润口径，由 CEO 审定；设立销售合资公司的走 LEG-06。
  • 方案型渠道（集成商、科研院所）：可能是多级决策链，先确认谁是签约方。
  • 独家代理：区域+行业授权，出货方式固定、任务量未完成取消独家，期限由销售负责人和 CEO 审定。
  • 本地网盘知识库一体机全国代理：按省市区铺代理并设置渠道 KPI，统一报价单与营销物料先于铺货到位。
  • 高校/教育渠道：以关系维护为主，每月至少 1 次关系维系与商机梳理，方案同步生态与解决方案团队。
  • 协作协议：遵循 ALL-03（决策记录与发布）、ALL-04（跨部门交接契约）、ALL-08（信息归档与单一事实来源）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 渠道负责人是否已正式任命？与销售负责人在政策审定上的分工是否如上？
  • 渠道等级（一般/金牌/钻石）的门槛与权益是否已成文？
  • 渠道代理协议模板当前启用版本放在哪里？版本由谁维护？
  • 独家授权的审批权限（年限、区域范围）如何划分？
  • 签约后 90 天出单率目标是否合理？
SAL-28渠道非标合作（预装/贴牌/联合开发）承诺审批待新建200

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：渠道或客户提出 OEM 预装、贴牌、联合开发、专属额度发放、分润等标准渠道政策以外的合作时启动，先汇总需求、产研评估，审批后统一对外承诺。
  • 负责人：主责——渠道对接销售（当前：时建·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、COO/市场销售（当前：常元和·推断待确认）、生态市场总监（当前：许君·推断待确认）；兜底——销售负责人
  • 核心流程：① 不口头承诺，登记非标合作申请 → ② 核实已有承诺与协议状态 → ③ 产研评估指标与排期 → ④ 商务评估价格分润 → ⑤ 审批 → ⑥ 签协议/补充条款 → ⑦ 指定唯一口径人对外答复 → ⑧ 按对接清单实施并跟踪里程碑
  • 交付结果：一份已审批的《非标合作申请单》（含产研评估、商务条件、对外承诺原文）、签署的合作协议或补充条款、进入任务看板的实施里程碑。
  • 状态依据：属于事故型流程——2026-06 对外交付日期由市场单方面确定，产研评估需要一个月；2026-09 渠道上门称已与内部人员谈好预装收费和分润，对接销售不知情，贴牌暂停也未通知到位；谁有权批准预装、贴牌没有规定。

1. 场景判定

  • 触发条件：渠道或客户提出在其硬件上预装 LeapAll/LeapCore、贴其品牌、展厅贴牌机、合作开发行业版本、按设备发放专属额度、硬件+token 分润等。
  • 典型说法：「来两台服务器让我们装上，每台收费再分 token 利润」「贴牌机放展厅」「我们一起合作开发一个行业版本」「方案都没确认，谁对外定的日期？」
  • 判断问题：① 标准渠道政策和协议里有没有？② 是否需要产研投入（适配、UI 定制、接口、打包）？③ 有没有人已经口头答应过？
  • 不归本流程管：标准渠道签约 → 请走 SAL-27；单客户定制功能报价 → 请走 SAL-21 / X-PRD-11；已审批后的白牌定制交付实施 → 请走 X-DLV-11；合作开发协议起草 → 请走 LEG-05；赠送额度 → 请走 SAL-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起与汇总 登记申请、核实已有承诺、对外唯一口径 R 渠道对接销售（当前：时建·推断待确认）
产品评估 合作计划、指标、时间节点、规则（如额度发放规则） R 产品总监（当前：杨萌·推断待确认）
研发评估 工作量、排期、技术风险（OTA、防刷、接口安全） C Leap 研发负责人（当前：王皓南·推断待确认）
技术承诺审批 机型适配、技术方案、交付时间 R CTO（当前：丁震宇·推断待确认）
商务条件审批 价格、分润、品牌授权 A CEO（当前：邴龙志·推断待确认）
市场协同 合作节奏、演示与宣发 C COO/市场销售（当前：常元和·推断待确认）
渠道产品对接 与对方产品对接需求和设计 R 渠道产品经理（当前：陈震·推断待确认）
实施 接口、UI 主题、打包、测试 R 后端（当前：邓乾·推断待确认）、前端（当前：葛家和·推断待确认）、CI（当前：吴世豪·推断待确认）、测试（当前：张东郅·推断待确认）
物料 贴牌物料、对外资料 I 生态市场总监（当前：许君·推断待确认）

3. 办之前请准备

  • 对方需求原话、对方联系人、介绍人，以及是否有人已口头答应过什么
  • 现有渠道协议签署状态与等级
  • 硬件机型、数量、交付地点和对方期望时间
  • 合作类型清单与默认答复（预装/贴牌/合作开发/专属额度）
  • 合作计划文档模板（时间节点、指标、双方分工、验收标准）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到非标诉求，回复“内部评估后书面答复”，登记《非标合作申请单》 渠道对接销售 收到后 1 个工作日内 飞书审批 申请单 🔧飞书固化
2 核实是否已有内部人员口头承诺、协议状态、介绍人背景，写入申请单 渠道对接销售 1 个工作日内 申请单 承诺核实记录 👤人工判断
3 产品出合作计划初稿（节点、指标、规则），研发评估适配与工作量；必要时与对方产研开对齐会 产品总监、Leap 研发负责人 3 个工作日内 飞书文档、日程 评估结论、合作计划 👤人工判断
4 商务评估价格、分润、品牌授权、责任划分（如密钥泄露损失由谁承担） 渠道对接销售 与第 3 步并行 申请单 商务条件 👤人工判断
5 审批：技术承诺由 CTO，价格分润与品牌授权由 CEO CTO、CEO 2 个工作日内 飞书审批 审批结论 🔧飞书固化
6 起草合作协议或补充条款，法务审查后签署 渠道对接销售、法务 审批后 5 个工作日内 LEG-05 签署协议 🔧飞书固化
7 以审批版本对外书面答复（时间、指标、价格），只由唯一口径人发出 渠道对接销售 签署或审批后 1 个工作日内 飞书文档/邮件 对外承诺原文 🔧飞书固化
8 按对接清单（规则、接口、安全、对账、UI、打包、交付）拆任务，里程碑进看板 产品总监 承诺发出后 2 个工作日内 任务看板、Gitea issue 实施计划 👤人工判断
9 合作暂停或变更时，书面通知对方和所有内部知情人 渠道对接销售 决定当天 群公告 + 申请单 变更记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《非标合作申请单》、合作计划文档、审批记录、合作协议/补充条款、对外承诺原文、实施看板。
  • 建议模板/表单：《非标合作申请单》——合作方、合作类型（预装/贴牌/合作开发/专属额度/分润）、需求原话、已有口头承诺（谁、何时、内容）、机型与数量、期望时间、产研评估（工作量、排期、风险）、商务条件（价格、分润、品牌授权、责任划分）、审批人、对外口径人、对外答复日期。
  • OEM 对接清单：发放规则、接口与鉴权、安全措施（IP 白名单、签名密钥、泄漏冻结）、每日数量核对、UI 主题包、专属打包、交付日期。

6. 异常与升级

  • 发现已有人对外口头承诺 → 渠道对接销售当天上报销售负责人 → 由 CTO/CEO 决定兑现、改条件还是撤回（2 个工作日内）。
  • 对外日期早于产研评估结果 → 以产研评估为准，口径人当天向对方修正。
  • 额度/密钥异常（伪造领取、泄漏）→ 研发立即冻结 → 按协议责任条款处理 → 升级 CTO（2 小时内）。
  • 对方需求反复变更 → 冻结范围，变更重新走第 3～5 步。

7. 衡量指标

  • 先审后诺率 = 审批后才对外承诺的合作 ÷ 全部非标合作，目标 100%。
  • 承诺兑现率 = 按承诺时间交付的里程碑 ÷ 承诺里程碑，目标 ≥ 90%。
  • 评估周期 = 登记到审批完成的工作日，目标 ≤ 5 个工作日。
  • 口径冲突次数 = 对方反馈“和你们某人说好了”但内部无记录的次数，目标每季度 0。

8. 低效诊断

  • 现象：承诺环节无审批，对外时间节点由市场单方面确定，产研事后评估发现需要更长时间｜依据：「鼎慧产研决策部」2026-06
  • 现象：合作条件通过私聊、电话谈定，渠道上门后对接销售才知情；暂停决定未同步到介绍人｜依据：「【模态】市场销售」2026-09
  • 现象：合作类型没有定义，渠道把“试用/合作开发”理解为传统预装模式｜依据：「【模态】市场销售」2026-09
  • 现象：OEM 发放规则在不同角色间理解不一致（老用户是否发放），开发文档写给谁看不清，素材到手晚｜依据：「Leap产研测」2026-07

9. 分支变体

  • OEM 预装 LeapAll（某整机厂商）：需双方产研对齐；按设备注册发放专属额度，规则为清单命中才发、一机一次、一号一次、异常人工补发；需 UI 主题包和专属打包；责任划分写进合同。
  • 渠道服务器预装 LeapCore：需先做机型适配评估，价格与分润由 CEO 审批。
  • 贴牌展厅机：品牌授权审批，物料由生态市场准备。
  • 合作开发行业版本：产出归研发资产，试用就是试用，协议走 LEG-05。

10. 待确认问题

  • 非标合作的主责是对接销售还是渠道负责人？
  • 技术承诺与商务条件分别由 CTO、CEO 审批是否可行？是否需要销售负责人前置初审？
  • 是否需要发布“合作类型清单与默认答复”？由谁维护？
  • OEM 渠道额度被伪造领取的损失责任是否已写入合同？
  • 已移交产品侧的技术实现部分，与本流程的交接点是否以“对外承诺发出”为准？
SAL-29渠道与销售产品培训赋能待优化135

状态：待优化｜证据：有证据（卡片 10 张 / 会话 9 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：渠道签约后需要让渠道会讲、会卖、跑出首单，或产品新版本/新功能上线、销售与渠道反复问同类问题时启动。
  • 负责人：主责——渠道负责人（当前：闫登辉·推断待确认）；协同——产品总监（当前：杨萌·推断待确认，新功能培训组织与回放归档）、研发讲师（当前：吴世豪·推断待确认）、销售负责人（当前：李鹏为·推断待确认，策略与考核）、渠道销售（当前：陈名赞、杜中瑞、吴琪、朱文瑜、时建·推断待确认）、CTO（当前：丁震宇·推断待确认，对客话术）、生态市场总监（当前：许君·推断待确认，渠道物料）；兜底——销售负责人
  • 核心流程：① 触发登记到培训台账 → ② 定讲师与材料 → ③ 发培训通知 → ④ 授课 → ⑤ 回放与文档归档 → ⑥ 小测与补课 → ⑦ 渠道陪跑首单 → ⑧ 重复问题回收更新 FAQ
  • 交付结果：培训台账记录、课件/课程文档、录屏回放（知识库固定位置）、FAQ 与对客话术、测验结果；渠道侧还有首单陪跑记录。
  • 状态依据：已有固定做法（通知 → 培训 → 回放归档）和 2026-10 发布的渠道陪跑执行 SOP 文档；但 2026-09 销售培训后仍反复问同类问题，回放位置靠临时询问，培训归谁讲、资料归谁出要追问，每个渠道单独培训。

1. 场景判定

  • 触发条件：新渠道签约；渠道方或云厂商渠道反映“讲不明白”；新版本/新功能上线；同一问题被销售或渠道问 3 次以上；渠道大会前。
  • 典型说法：「签了协议才是开始，要培训产品」「他们仍然在反复问一些问题」「真得开远程连接培训班了」「下午培训录屏在哪」「需要搞个渠道商培训把各个渠道商的能力提一下」
  • 判断问题：① 培训对象是渠道、内部销售，还是终端客户？② 内容是“怎么用/怎么卖”，还是技术实现？③ 已有课件和回放能不能直接复用？
  • 不归本流程管：终端客户使用培训 → 请走 X-DLV-28；FDE 课程与认证 → 请走 X-FDE-16、X-FDE-19；内部 FDE 与 LeapCore 培训补课 → 请走 X-FDE-15；新人入职培训 → 请走 HR-06；全员分享会 → 请走 HR-23；客户试点驻场陪跑 → 请走 X-FDE-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
培训统筹 培训台账、渠道培训排期、陪跑跟踪 A 渠道负责人（当前：闫登辉·推断待确认）
新功能培训组织 约时间、发通知、指定讲师、回放归档 R 产品总监（当前：杨萌·推断待确认）
讲师（功能） 讲怎么用、讲限制 R 研发讲师（当前：吴世豪·推断待确认）
对客话术 补充商业话术与对比口径 C CTO（当前：丁震宇·推断待确认）
渠道培训执行与陪跑 对渠道讲产品与销售策略、带前几次客户拜访 R 渠道销售（当前：陈名赞、杜中瑞、吴琪、朱文瑜、时建·推断待确认）
策略与考核 确定陪跑策略、检查学习效果 C 销售负责人（当前：李鹏为·推断待确认）
渠道物料 宣讲 PPT、FAQ 话术手册 C 生态市场总监（当前：许君·推断待确认）
学员 参加培训、完成测验 I 销售、市场、售后、渠道人员

3. 办之前请准备

  • 培训对象名单、必须参加人员
  • 功能文档或课程文档（产品出），对客话术与 FAQ（销售/CTO 补）
  • 演示账号或演示机（SAL-13）
  • 会议室、飞书会议号，录制设置
  • 渠道培训：渠道资料包（产品介绍、价格口径、演示视频、开票说明、报备方式）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记培训需求（对象、主题、触发原因）到培训台账 渠道负责人/产品总监 触发后 1 个工作日内 多维表格 台账记录 🔧飞书固化
2 指定讲师，开发先与产品过一遍内容；课程文档写“怎么用+限制”，话术另附 产品总监、研发讲师、CTO 培训前 2 个工作日 飞书文档 + AI 初稿 课件、话术 🔧+🤖
3 发培训通知（时间、地点、会议号、必须参加人），同步建日程 产品总监/渠道负责人 培训前 1 个工作日 飞书日程 通知 🔧飞书固化
4 授课：少术语、多示例，讲清限制和对客口径，留答疑时间 讲师 按排期 飞书会议（开录制） 录屏 👤人工判断
5 回放和文档归档到知识库培训专区，在通知群发链接 产品总监 培训后 1 个工作日内 妙记、知识库 回放链接 🔧+🤖
6 发小测验，缺席或未通过者看回放补课并重测 渠道负责人 培训后 3 个工作日内 飞书表单 测验结果 🔧+🤖
7 渠道陪跑：前 2～3 次客户拜访由我方带队，协助商机报备、开票说明，跟进首单 渠道销售 签约后 60 天内 渠道系统、CRM 陪跑记录 👤人工判断
8 收集培训后重复问题，更新 FAQ，月度复盘是否要加开专题课 渠道负责人、产品总监 每月最后一周 知识库、问答机器人 更新的 FAQ 🤖自动化

5. 交付物与模板

  • 交付物：培训台账、课件/课程文档、录屏回放、FAQ 与对客话术、测验结果、渠道陪跑记录。
  • 建议模板/表单：培训台账字段——培训编号、主题、类型（渠道/内部销售/新功能）、触发原因、讲师、日期、参训名单、出勤、回放链接、文档链接、测验通过率、待补课人员。
  • 渠道陪跑表字段——渠道、签约日期、培训完成日期、陪跑拜访次数、报备商机数、首单日期、负责销售。
  • 课程文档模板：功能是什么 → 怎么用（步骤截图）→ 限制与常见问题 → 对客话术 → 演示脚本。

6. 异常与升级

  • 培训后同一问题仍被问 3 次以上 → 产品总监补 FAQ 并安排 30 分钟专题补课（1 周内）。
  • 必须参加人员缺席且未补课 → 渠道负责人提醒 → 仍未完成报销售负责人（5 个工作日内）。
  • 渠道签约 60 天未出首单 → 渠道负责人与销售负责人复盘陪跑策略。
  • 回放未归档或找不到 → 产品总监 1 个工作日内补归档。
  • 培训内容涉及未上线功能或内部资料 → 讲师删除后再归档，对外版本单独输出。

7. 衡量指标

  • 回放归档及时率 = 1 个工作日内归档的培训 ÷ 全部培训，目标 100%。
  • 测验通过率 = 一次通过人数 ÷ 参训人数，目标 ≥ 80%。
  • 重复提问量 = 培训后 2 周内同主题提问次数，目标逐次下降。
  • 渠道首单周期 = 签约到首单的天数，目标 ≤ 60 天（待确认）。

8. 低效诊断

  • 现象：培训后缺少测验和话术库，同类问题反复问，讲师怀疑培训效果｜依据：「Leap产研决策部」2026-09
  • 现象：回放与文档散落，错过培训的人要在群里问录屏在哪｜依据：「公司全员群」2026-09、「Leap市场销售通知群」2026-09
  • 现象：功能上线后才安排培训，对客话术散落在群里｜依据：「LeapVPN网络预研」2026-07、2026-09
  • 现象：每个渠道各自单独培训，主讲和材料不固定｜依据：「【模态】市场销售」2026-08～10
  • 现象：渠道提出的培训需求无人认领｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：渠道讲不清时临时指派讲解人，资料包不存在，事后再被要资料。
  • 现象：售后由谁做、渠道能承担多少服务边界不清｜依据：「Leap产研测」2026-09、「模态AI探索小分队」2026-05

9. 分支变体

  • 新签渠道陪跑激活：按渠道陪跑执行 SOP 文档执行；标杆客户由我方带，非标杆客户交渠道承接。
  • 云厂商/集成商渠道要求培训：由渠道负责人安排讲师，同时提供渠道资料包。
  • 内部销售/交付/运营新功能培训：产品总监组织，研发讲师主讲，面向客户的同事必须参加，产研测可选。
  • 标品 vs 定制：标品能力教给渠道；定制服务由我方 FDE 承接，渠道只负责前线需求梳理。
  • 渠道员工是否纳入销售 KPI：按个案由销售负责人决定。

10. 待确认问题

  • 培训总统筹是渠道负责人还是产品总监？渠道培训和内部新功能培训是否拆成两个负责人？
  • 渠道陪跑 SOP 文档是否作为本流程附件？谁负责维护？
  • 测验通过率、首单周期的目标是否合理？
  • 知识库培训专区放在哪？问答机器人由谁维护？
  • 渠道培训是否等渠道系统就绪后再统一开班？
SAL-30渠道体系管理（台账、分级评级、分润与推荐费结算）待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：渠道签约后，需要维护签约台账、划分等级、定期评级、管理中间人与个人推荐，以及按规则核算分润和推荐费时启动。
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，体系设计与分润决策）、渠道负责人（当前：闫登辉·推断待确认）、生态市场总监（当前：许君·推断待确认，渠道手册与知识库）、商务（当前：杨朋伟、杜中瑞·推断待确认，承接推荐客户）、财务（当前：待指定）、法务负责人（当前：待指定）；兜底——CEO
  • 核心流程：① 签约渠道入台账 → ② 定等级 → ③ 推荐线索登记与归属 → ④ 成单后按规则表核算分润/推荐费 → ⑤ 结算审批 → ⑥ 财务打款 → ⑦ 季度评级与违规处理 → ⑧ 制度与手册更新发布
  • 交付结果：渠道台账（唯一数据源、随时可导出签约渠道清单）、渠道等级与季度评级结果、分润/推荐费结算单、现行渠道管理制度与渠道销售手册。
  • 状态依据：已有 CRM、渠道代理协议、《全国渠道管理体系策划案》和渠道管理机制 wiki；但 2026-08 签约渠道清单要从 CRM 导出后手工整理，2026-10 中间人制度、渠道评级制度仍在编写，个人推荐的渠道费只有口头约定。

1. 场景判定

  • 触发条件：新渠道签约；管理层要签约渠道清单；季度末评级；个人/兼职人员或中间人推荐客户；渠道出单需要结算分润；出现窜货、乱价。
  • 典型说法：「签约渠道清单这里再发一下」「下个阶段一定要系统性的把渠道动起来」「渠道的淘汰机制晚一点做没事」「在渠道代理合同里约束好」
  • 判断问题：① 对方是签约渠道、中间人，还是一次性个人推荐？② 这笔单子在系统里有没有报备、归属是谁？③ 适用哪一版分润规则？
  • 不归本流程管：渠道开发与协议签署 → 请走 SAL-27；渠道报备、下单、交付 → 请走 SAL-31；分润实际打款与开票 → 请走 FIN-23；内部销售提成 → 请走 SAL-34；内部商机归属争议 → 请走 SAL-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账与评级 维护渠道台账、组织季度评级、起草制度 A 销售负责人（当前：李鹏为·推断待确认）
体系与分润决策 体系设计、分润比例、中间人制度拍板 A（升级） CEO（当前：邴龙志·推断待确认）
渠道日常 台账字段更新、案例整理、违规线索 R 渠道负责人（当前：闫登辉·推断待确认）
手册与知识库 渠道销售手册、白皮书、定价资料与权限 R 生态市场总监（当前：许君·推断待确认）
推荐客户承接 承接个人推荐的客户（学校客户按指定商务） R 商务（当前：杨朋伟、杜中瑞·推断待确认）
结算打款 核对结算单、打款、取票 R 财务（当前：待指定）
合同约束 窜货、乱价、违约条款 C 法务负责人（当前：待指定）

3. 办之前请准备

  • 已签渠道协议（等级、授权范围、分润条款）
  • 现行分润规则表（硬件/软件/充值分润、推荐费比例与期限）
  • 渠道系统或 CRM 中的报备、订单、回款数据
  • 渠道等级与评级打分规则
  • 推荐人身份信息与推荐登记记录（结算时需要）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新签渠道录入台账（以渠道系统/CRM 为唯一数据源，不另建表） 渠道负责人 签约后 1 个工作日内 渠道系统/CRM 台账记录 🔧飞书固化
2 按等级定义确定等级，写入台账 销售负责人 签约后 3 个工作日内 台账 等级 👤人工判断
3 个人/中间人推荐：先在系统登记线索与推荐人，再交指定商务跟进；推荐人只负责引线 推荐人、商务 推荐当天 渠道系统 推荐登记 🔧飞书固化
4 订单回款后按分润规则表自动核算分润/推荐费，生成结算单 渠道负责人 回款后 5 个工作日内 渠道系统 结算单 🤖自动化
5 结算审批：销售负责人审核，规则外让步提交 CEO 销售负责人、CEO 3 个工作日内 飞书审批 审批结论 🔧飞书固化
6 财务按审批结果打款并取得发票或完税凭证 财务 审批后 10 个工作日内 FIN-23 打款记录 🔧飞书固化
7 季度评级：按出货、报备、培训参与、违规记录打分，决定升降级与淘汰 销售负责人 季度结束后 10 个工作日内 台账 + 自动打分 评级结果 🔧+🤖
8 窜货、乱价按协议条款处理，结果记入台账 渠道负责人、法务 发现后 5 个工作日内 台账 处理记录 👤人工判断
9 制度和手册更新后发布到知识库，通知全体渠道与销售，开通相关权限 生态市场总监 定稿后 2 个工作日内 知识库 发布记录 🔧飞书固化

5. 交付物与模板

  • 交付物：渠道台账、等级与评级结果、分润/推荐费结算单、打款记录、渠道管理制度（含中间人制度、评级制度、淘汰机制）、渠道销售手册。
  • 建议模板/表单：渠道台账字段——渠道名称、类型（经销商/中间人/个人推荐/行业渠道）、签约日期、协议版本、等级、授权区域/行业、对接销售、累计报备数、累计订单额、累计充值、最近评级、违规记录、状态（正常/观察/淘汰）。
  • 结算单字段——渠道/推荐人、关联订单、回款日期、适用规则版本、分润类型（首单/后续充值）、应结金额、审批人、打款日期、票据状态。

6. 异常与升级

  • 推荐线索归属有争议（多人报备同一客户）→ 以系统报备时间为准 → 仍有争议转 SAL-33 裁定（5 个工作日内）。
  • 推荐人或渠道对分润口径有异议 → 以协议和规则表为准，规则未覆盖的提交 CEO（5 个工作日内）。
  • 管理层临时要清单 → 直接从台账视图导出，不手工整理。
  • 渠道出现窜货、乱价 → 暂停该渠道下单权限 → 法务评估违约处理 → 升级销售负责人。

7. 衡量指标

  • 台账完整率 = 台账中字段完整的签约渠道 ÷ 已签协议数，目标 100%。
  • 清单出具时长 = 管理层要清单到交付的时间，目标 ≤ 10 分钟（直接导出）。
  • 结算周期 = 回款到分润打款的工作日，目标 ≤ 20 个工作日。
  • 分润争议次数 = 每季度渠道或推荐人对结算提出异议的次数，目标 ≤ 1。

8. 低效诊断

  • 现象：台账未固化，签约渠道清单要从 CRM 导出后手工整理，管理层多次重新要清单｜依据：「【模态】渠道建设」2026-08
  • 现象：评级、中间人等制度仍在编写，渠道依赖方式不明确｜依据：「【模态】渠道建设」2026-10
  • 现象：渠道打法材料先发群里、再由人整理进知识库，没有统一入口｜依据：「打赢这一仗」2026-07
  • 现象：个人推荐的渠道费只有口头约定，推荐人记错价格，知识库权限未配置。
  • 现象：渠道质疑产品、不买单、占用销售精力，缺少准入筛选与淘汰机制｜依据：「某渠道对接群」2026-09

9. 分支变体

  • 经销商：按协议等级分润，季度评级。
  • 中间人：只引线，按中间人制度结算，不享受渠道价拿货。
  • 兼职个人推荐：先登记后跟进，首单按比例提成，后续充值按比例分成（比例以审批后的规则表为准）；学校客户统一交指定商务。
  • 行业渠道（招标代理、会计事务所等）：按中间人或经销商之一归类，不另设规则。
  • C 端 LeapAll 与 B 端 LeapCore 推荐：分润基数不同，规则表分别列明。

10. 待确认问题

  • 渠道台账的唯一数据源是 CRM 还是渠道系统？
  • 中间人制度、渠道评级制度的发布时间和审批人是谁？
  • 个人推荐费比例与期限是否已经正式审批？结算需要推荐人提供哪些票据？
  • 季度评级的打分项与权重由谁定？淘汰机制何时启用？
  • 渠道销售手册与白皮书的知识库权限由谁开通？
SAL-31渠道报备→订单→交付（渠道系统）待优化500

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：渠道（含按渠道处理的内部直销主体）发现客户或项目，需要在渠道系统报备商机、提交订单、走到 IT 交付、充值、验收、开票时启动。
  • 负责人：主责——订单与交付统筹（当前：杨萌·推断待确认）；协同——渠道系统负责人（当前：丁震宇·推断待确认）、渠道系统开发（当前：陈子康·推断待确认）、商务审核（当前：闫登辉、吴琪·推断待确认）、IT 交付（当前：游家豪、杨明学·推断待确认）、软件部署（当前：宋祺睿、杨云峰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——销售负责人
  • 核心流程：① 渠道报备客户/项目 → ② 商务审核进入保护期 → ③ 带合同发起订单 → ④ IT 配置预审、渠道确认 → ⑤ 商务审核订单 → ⑥ 财务确认收款 → ⑦ 硬件准备、软件部署、充值开通 → ⑧ 上传验收单关闭订单 → ⑨ 开票
  • 交付结果：渠道系统中一条已关闭的订单：报备记录、五类合同材料、IT 预审单、收款确认、部署与充值记录、验收单、发票记录；渠道销量与充值看板随之更新。
  • 状态依据：渠道系统已上线，2026-10 起订单入口从飞书问卷强制切换到渠道系统；但切换期旧订单材料需补齐、外部渠道开通无明确负责人、审核节点没有飞书通知、客户未绑定导致财务看不到余额，审核与管理员角色未拆分。

1. 场景判定

  • 触发条件：渠道或内部销售发现客户/项目要报备；客户确定采购 LeapCore 软硬件或充值；旧订单需要补材料；需要开通渠道账号。
  • 典型说法：「渠道就只做两件事，提商机，提订单」「之后的订单都走渠道系统提交和管理」「报备可以先报备，下单得带合同」「请大家紧急核对各自订单机器应有的席位数量」
  • 判断问题：① 客户是否已报备并在保护期内？② 订单是否带齐合同材料？③ 是渠道单还是内部直销单（挂哪个商务负责人）？
  • 不归本流程管：渠道开发与协议签署 → 请走 SAL-27；API/额度类分销 → 请走 SAL-26；渠道分润结算 → 请走 SAL-30；交付派工与现场部署细节 → 请走 X-DLV-07、X-DLV-19；客户充值到账审核 → 请走 FIN-17；开票 → 请走 FIN-18；CRM 商机维护 → 请走 SAL-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程与订单统筹 流程设计、使用手册、切换通知、旧订单补录 A 订单与交付统筹（当前：杨萌·推断待确认）
渠道系统负责 需求与规则拍板、合同类型、权限设计 C 渠道系统负责人（当前：丁震宇·推断待确认）
系统开发与账号 系统维护、渠道账号开通、问题修复 R 渠道系统开发（当前：陈子康·推断待确认）
报备/订单审核 审核报备与订单、对接外部渠道 R 商务审核（当前：闫登辉、吴琪·推断待确认）
发起方 报备、下单、上传合同、确认配置 R 渠道/内部销售（当前：杨朋伟等·推断待确认）
IT 预审与交付 配置预审、硬件准备、最终验收 R IT 交付（当前：游家豪、杨明学·推断待确认）
软件部署 部署、充值、开通 R 软件部署（当前：宋祺睿、杨云峰·推断待确认）
收款确认 确认到账、退回补材料、开票 R 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 渠道账号（渠道需提供姓名、渠道名、统一社会信用代码、法定代表人，并上传战略合作协议；内部销售用飞书登录申请权限，共用内部渠道账号）
  • 客户主体信息、项目情况、预计采购内容
  • 下单材料：渠道-客户软硬件合同、模态-客户词元充值协议（渠道客户另签《软件服务开口协议》），按系统五类合同材料上传
  • 机器配置与席位数、交付地址与联系人、特殊情况备注（如专项计划客户）
  • 开票信息：抬头、税号、开票地址与电话、收票邮箱
  • 请求最少包含字段（下单时）：渠道/商务负责人、客户主体全称、合同编号与五类合同材料、商品明细与机型、机器数量与席位数、充值额度、交付地址与现场联系人岗位、期望交付日期、开票信息、特殊情况备注；缺项由系统或审核人一次性退回，不在订单群逐项追问

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在渠道系统报备客户/项目 渠道/内部销售 首次有效接触后 2 个工作日内 渠道系统 报备记录（渠道系统，带报备编号） 🔧飞书固化
2 审核报备，通过后进入保护期；驳回写明原因，可修改后重新发起 商务审核 1 个工作日内 渠道系统 + 飞书通知 审核结论（渠道系统状态 + 飞书通知发起人，驳回附原因）；超时见第 6 节 🔧飞书固化
3 从报备记录发起订单，上传合同材料，填席位数与特殊备注；指定公司兜底商务负责人 渠道/内部销售 合同签署后 2 个工作日内 渠道系统 订单（渠道系统订单号，关联报备编号与合同编号） 🔧飞书固化
4 IT 配置预审（商品明细、机型、席位），渠道确认调整 IT 交付、渠道 1 个工作日内 渠道系统 预审单（渠道系统订单内“预审通过/退回”，退回写明不一致项）；超时→订单与交付统筹 👤人工判断
5 商务审核订单（价格、合同一致性） 商务审核 1 个工作日内 渠道系统 审核结论（渠道系统状态 + 飞书通知）；超时→订单与交付统筹 🔧飞书固化
6 财务确认收款；材料不全时退回渠道补充 财务负责人 到账后 1 个工作日内 渠道系统待收款列表 收款确认（渠道系统“已收款”，财务同步登记 FIN-21 台账）；超时→订单与交付统筹 @ 财务负责人 🔧飞书固化
7 硬件准备 → 软件部署、充值、开通，绑定客户与实例 IT 交付、软件部署 按 X-DLV 交付时限 渠道系统、交付群 部署与充值记录（渠道系统订单状态逐环节更新；交付工单号回填；实例登记 X-DLV-31）；超时→交付负责人，再超 2 个工作日→订单与交付统筹 🔧+🤖
8 上传验收单，IT 最终验收后关闭订单 IT 交付 交付完成后 3 个工作日内 渠道系统 已关闭订单（验收单扫描件挂订单，状态“已关闭”，通知财务可开票）；超时→订单与交付统筹 🔧飞书固化
9 开票：普票线上自助，专票人工处理 财务负责人 申请后 5 个工作日内 渠道系统/FIN-18 发票（发票记录回填订单，通知申请人）；超时→财务负责人上级 🤖自动化

5. 交付物与模板

  • 交付物：报备记录、订单（含五类合同材料与正式合同编号）、IT 预审单、收款确认、部署/充值记录、验收单、发票；渠道销量与充值看板。
  • 建议模板/表单：订单必填字段——渠道、商务负责人、客户主体、合同编号、商品明细、机器数量与席位数、充值额度、交付地址、特殊情况备注、开票信息；“选填后基本不填”的字段改为必填。
  • 渠道看板：渠道 → 机器 → 余额、累计充值、合同报备状态。
  • 渠道账号申请单：姓名、渠道名、统一社会信用代码、法定代表人、战略合作协议附件。

6. 异常与升级

  • 审核节点超过 1 个工作日未处理 → 系统飞书提醒 → 仍未处理通知订单与交付统筹（再 1 个工作日）。
  • 同一客户多方报备 → 以先通过审核的报备为准，争议转 SAL-33。
  • 合同材料不全 → 财务退回，渠道 2 个工作日内补齐；过渡期旧订单由订单与交付统筹列清单限期补齐。
  • 席位数、配置与合同不一致 → IT 预审退回，暂停备货。
  • 系统故障或功能缺失（如协议无处下载）→ 渠道系统开发 1 个工作日内修复或给临时方案，报渠道系统负责人。
  • 客户未绑定导致余额不可见 → IT 交付在开通时补绑定，财务核对。
  • 订单状态超过 3 个工作日无更新（任一环节）→ 系统或统筹人在订单内 @ 当前环节负责人 → 再 1 个工作日无回应升级销售负责人；进度一律看渠道系统订单状态，不在群里问“到哪一步了”。
  • 需要交付变更（改配置、改地址、改席位）→ 发起方在订单内提交变更备注并 @ IT 预审 → 口头或私聊变更不生效。

7. 衡量指标

  • 系统下单率 = 渠道系统内提交的订单 ÷ 全部订单，目标 100%（切换完成后）。
  • 订单全周期 = 发起订单到关闭的自然日，目标 ≤ 15 天（不含硬件到货等待，待确认）。
  • 审核节点时效 = 各审核节点平均处理时长，目标 ≤ 1 个工作日。
  • 材料完整率 = 下单时合同材料齐全的订单占比，目标 ≥ 95%。

8. 低效诊断

  • 现象：飞书问卷提单与渠道系统并行，订单信息分散在订单群和问卷，切换期旧订单材料要陆续补｜依据：「Leap市场销售通知群」2026-08、2026-10
  • 现象：席位数事后紧急核对，限当天完成确认｜依据：「Leap市场销售通知群」2026-10
  • 现象：审核节点没有飞书通知，依赖人工盯；渠道审核与系统管理员角色未拆分｜依据：「渠道系统优化」2026-09
  • 现象：外部渠道开通、测试没有明确负责人；客户未绑定导致余额财务看不到｜依据：「渠道系统优化」2026-10
  • 现象：分润口径与渠道价拿货口径不一致，被商务质疑｜依据：「渠道系统优化」2026-09
  • 现象：上线前渠道看板、报备表归属不清，多系统各记一份｜依据：「鼎慧产研决策部」2026-07
  • 现象：系统先上线再补 SOP，渠道客户与自有客户是否都需签开口协议没说清。

9. 分支变体

  • 内部直销：武汉、深圳、苏州等模态主体和鼎慧按渠道处理，共用内部渠道账号，订单挂商务负责人字段。
  • 外部渠道：先开渠道账号（必须上传战略合作协议），由商务审核对接。
  • 过渡期：飞书问卷订单入口关闭后，旧订单由订单与交付统筹组织补录。
  • 线上充值与开票：充值线上完成，自动合同与电子发票随版本上线；初期普票线上、专票人工。
  • 验收单走渠道系统，并入交付流程。
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 订单与交付统筹是否长期由产品总监承担，还是移交销售运营或交付负责人？
  • 渠道审核员与系统管理员是否拆分？外部渠道开通由谁负责？
  • 自有客户是否也需签《软件服务开口协议》？
  • 订单全周期目标 15 天是否可行？硬件到货时间如何扣除？
  • 审核节点飞书通知何时上线？
SAL-32销售日报周报与汇报保密待优化90

状态：待优化｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频5 × 耗2 × 跨3 × 险3

  • 适用场景：销售每周（特定时期每天）向部门报送工作汇报，管理层据此复盘商机；月底为人事提供考勤工作记录；汇报或群聊涉及客户内部信息、机密信息时按保密分级选择沟通渠道。
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认，信息分级与 CRM 权限）、销售运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）、全体销售（当前：杜中瑞、闫登辉、时建、吴琪、杨朋伟、陈名赞、朱文瑜、汪家诺·推断待确认）；兜底——CEO
  • 核心流程：① 周五按统一模板填周报 → ② 同步更新 CRM 商机 → ③ 机器人提醒未交者 → ④ 汇总生成部门周报 → ⑤ 周五部门例会复盘 → ⑥ 月底导出考勤依据 → ⑦ 机密内容按分级走受限渠道
  • 交付结果：每人每周一份按项目/渠道分标题的周报（多维表格记录）、部门周汇总、CRM 商机阶段同步、月度考勤工作记录；机密信息只在 CRM 受限字段或直属上级处留存。
  • 状态依据：有固定周报节奏，但 2026-04～10 频率从日报改周报、格式先后多次调整，几乎每周都要在群里点名催交；周报与 CRM 重复登记，长文难检索，项目漏录要靠管理者发现；保密分级只口头宣布过。

1. 场景判定

  • 触发条件：每周五（周报）；新人或管理层要求的阶段性日报；月底人事核考勤；汇报内容涉及客户内部信息、报价底线、未公开项目。
  • 典型说法：「周报周报周报」「周报格式不再采用流水账，统一以项目或渠道做标题」「涉及甲方内部的，工作汇报先不写，口头说就好」「不涉密的信息一律在对应群里沟通，禁止非必要私聊」
  • 判断问题：① 这条内容是公开、内部透明，还是内部机密？② 这个项目在 CRM 里有没有对应商机？③ 是标品还是定制化项目？
  • 不归本流程管：CRM 客户与商机录入规则 → 请走 SAL-04；重点商机上报 → 请走 SAL-06；对外沟通口径 → 请走 SAL-10；考勤核对扣薪 → 请走 HR-14；对外提供材料的保密审查 → 请走 LEG-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
周报口径与审阅 定模板、点评、周五例会复盘 A 销售负责人（当前：李鹏为·推断待确认）
报送 按模板填写、同步 CRM R 全体销售（当前：杜中瑞、闫登辉、时建、吴琪、杨朋伟、陈名赞、朱文瑜、汪家诺·推断待确认）
汇总与考勤导出 汇总部门周报、提醒、月底导出考勤依据 R 销售运营（当前：待指定）
经营复盘 周一经营例会使用汇总、提出调整要求 I CEO（当前：邴龙志·推断待确认）
信息分级与权限 定三档分级与 CRM 权限、删除权限与备份 C CTO（当前：丁震宇·推断待确认）
客户问题收取 从周报中收取客户反馈与市场需求 I 生态市场总监（当前：许君·推断待确认）

3. 办之前请准备

  • 周报模板（多维表格表单）和本周 CRM 商机变化
  • 本周拜访纪要、渠道签约/培训进展
  • 信息分级说明：公开 / 内部透明 / 内部机密
  • 周报 skill（可用 LeapCore 自动生成初稿）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板填周报：每个项目/渠道一条，写进展、本周行动、难点卡点、下一步、需支持；标品和定制化项目分开 全体销售 每周五 20:00 前 多维表格表单 + 周报 skill 周报记录 🔧+🤖
2 同步更新 CRM 商机阶段；周报中出现但 CRM 没有的项目当天补录 全体销售 与第 1 步同时 CRM 商机更新 🔧飞书固化
3 机器人周五 17:00 提醒，周六 10:00 @未提交者 销售运营 自动 飞书机器人 提醒记录 🤖自动化
4 自动汇总部门周报，列出新增/推进/停滞商机和需支持事项 销售运营 周日 20:00 前 多维表格视图 + AI 汇总 部门周汇总 🤖自动化
5 部门例会复盘重点项目和卡点，分配资源 销售负责人 每周五下午 飞书会议 例会纪要 👤人工判断
6 周一经营例会使用部门周汇总 销售负责人 每周一 飞书文档 经营例会材料 🔧飞书固化
7 月底导出每人当月周报记录给人事作为考勤依据 销售运营 次月 3 个工作日内 多维表格导出 考勤工作记录 🔧+🤖
8 机密内容不写入公开周报，写入 CRM 受限字段或向直属上级单独汇报；不涉密信息一律在对应群沟通 全体销售 随时 CRM 权限 合规留痕 👤人工判断

5. 交付物与模板

  • 交付物：个人周报记录、部门周汇总、CRM 商机更新、月度考勤工作记录。
  • 建议模板/表单：周报字段——提交人、周次、类型（标品/定制化/渠道）、项目或渠道名称、CRM 商机链接、阶段、本周进展、本周行动、难点卡点、下一步、需要的支持、保密级别；新人另加“学习与反思”。
  • 信息分级表：公开（可发对外群）/ 内部透明（部门群可见）/ 内部机密（仅 CRM 受限字段或直属上级）；每档举例和对应渠道。

6. 异常与升级

  • 周六 10:00 后仍未提交 → 销售负责人点名 → 连续 2 周未交，计入月度考核（由销售负责人与人事确认口径）。
  • 周报中的项目在 CRM 缺失 → 销售当天补录；复盘时发现漏项，记录并在例会通报。
  • 机密内容误发到群 → 当事人立即撤回 → 报销售负责人评估影响（当天）。
  • CRM 数据误删 → 按每日备份回滚，报 CTO（当天）。

7. 衡量指标

  • 按时提交率 = 周五 20:00 前提交人数 ÷ 应交人数，目标 ≥ 95%。
  • 催办次数 = 每月人工点名催交的次数，目标 0（由机器人提醒替代）。
  • 周报-CRM 一致率 = 周报项目在 CRM 有对应商机的比例，目标 100%。
  • 机密信息外泄事件 = 每季度次数，目标 0。

8. 低效诊断

  • 现象：提交环节靠人工点名催办，几乎每周都要催，部分周只收到少数人｜依据：「【模态】市场销售」2026-04、2026-05、2026-07
  • 现象：频率与格式口径反复变化（日报改周报、流水账改按项目），报送人不清楚最新要求｜依据：「【模态】市场销售」2026-06、2026-09、2026-10
  • 现象：周报与 CRM、台账重复登记，长文在群里被截断、难检索，项目漏录要管理者事后发现｜依据：「【模态】市场销售」2026-09、2026-10
  • 现象：保密规则只在群里口头宣布，涉密内容的边界不清，线索认领、找案例等信息仍走私聊｜依据：「【模态】市场销售」2026-08、2026-09
  • 现象：月底考勤依据需人工把日报/周报整理后转交人事｜依据：「【模态】市场销售」2026-06

9. 分支变体

  • 日报：仅新人试岗期或管理层临时要求时使用，格式“今日完成/明日待办”。
  • 周报：常规形式，标品与定制化项目分开，渠道经理另写渠道签约与培训进展。
  • 涉密信息：脱敏后写入周报，或只写入 CRM 受限字段 / 向直属上级单独汇报。

10. 待确认问题

  • 周报截止时间定为周五 20:00 是否合适？是否保留周末补交？
  • 销售运营（周报汇总、考勤导出）现由谁承担？
  • 是否以 CRM 商机直接生成周报，取消群内长文？
  • 三档信息分级是否需要法务和 CTO 出成文规则？CRM 受限字段由谁配置？
  • 周报缺交是否与考核挂钩？口径需要人事确认。
SAL-33商机与客户归属分配制度待优化180

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：出现新商机、多个销售争抢同一客户，或渠道直签/已出货客户没有对接销售时，按统一规则指定唯一归属销售
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——渠道负责人（当前：闫登辉·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、产品总监/交付统筹（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 登记无主/争议商机 → ② CRM 查重 → ③ 按规则指定归属销售 → ④ 归属销售确认接收并首联 → ⑤ 争议裁决 → ⑥ 周简报公示 → ⑦ 月度回收超期商机重分配
  • 交付结果：每个商机/订单在 CRM 中有且仅有一个归属销售，分配记录可查，激励按归属与订单类型计入
  • 状态依据：已有《销售体系管理制度》并自 2026-06 起执行“商机统一汇总到销售负责人再分配”，但分配规则未成文；2026-09 仍出现渠道直签客户无人对接、多人轮流应付的情况，订单与销售的强制关联缺失

1. 场景判定

  • 触发条件：新商机进入但未指定销售；两名及以上销售声称跟进同一客户（撞单）；渠道直签或已出货订单没有对接销售；归属销售超期未跟进
  • 典型说法：「所有前面的商机后面都先统一汇总，后面再来分配」「真得强制要求每出一台货都要有销售」「因为没有销售所以不知道甩给谁」
  • 判断问题：这个客户/订单现在能说出唯一的对接销售吗？说不出、或说出两个以上，就走本流程
  • 不归本流程管：入站线索的接收、背调与认领 → 请走 SAL-02；CRM 录入规范与防重复报备 → 请走 SAL-04；渠道报备与订单交付 → 请走 SAL-31；渠道分润与推荐费 → 请走 SAL-30；交付后的售后承接 → 请走 X-CS-01；离职人员客户交接 → 请走 HR-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分配决策人 制定分配规则、指定归属销售、裁决撞单 A/R 销售负责人（当前：李鹏为·推断待确认）
渠道直签客户默认对接人 承接渠道直签及渠道出货客户 R 渠道负责人（当前：闫登辉·推断待确认）
归属销售 确认接收、首联客户、维护 CRM 跟进记录 R 商务/项目经理及各销售（当前：杨朋伟等·推断待确认）
无主订单发现方 发现无销售订单时登记提交，不直接长期对接 I/R 产品总监/交付统筹（当前：杨萌·推断待确认）
制度评审 评审分配规则与售后衔接 C CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
终裁与兜底 重大客户、跨主体争议终裁；无人承接时指定 A（升级） CEO（当前：邴龙志·推断待确认）
激励核算 按归属与订单类型计入激励 I 财务专员（当前：待指定）

3. 办之前请准备

  • 客户全称、统一社会信用代码或主体信息（用于 CRM 查重）
  • 商机来源：直销自拓 / 入站线索 / 渠道直签 / 转介绍；对应渠道商名称
  • 订单类型：公司直接订单 / 渠道订单；To G / To B
  • 已有跟进证据：首次报备时间、CRM 跟进记录、拜访纪要
  • 若为已出货订单：合同号、出货时间、客户当前诉求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记无主或争议商机/订单，填写来源、类型、已有跟进证据 发现人（销售/产研/运营/交付） 发现后 1 个工作日内 商机分配多维表格 待分配记录 🔧飞书固化
2 按客户主体在 CRM 查重，已有有效报备的直接判给原报备人 渠道负责人（兼 CRM 管理员） 登记后 0.5 个工作日内 CRM 查重结论 🔧+🤖
3 按规则指定归属销售：已报备优先→渠道直签归渠道负责人→其余按行业/区域/负载分配 销售负责人 查重后 1 个工作日内 商机分配表、CRM 归属字段 分配决定 👤人工判断
4 归属销售确认接收，首次联系客户并在 CRM 写跟进记录 归属销售 分配后 1 个工作日内 CRM、飞书任务 接收确认、首联记录 🔧飞书固化
5 撞单争议：双方提交报备时间与跟进证据，销售负责人裁决；重大客户上报 CEO 销售负责人 / CEO 争议提出后 2 个工作日内 飞书审批 裁决记录 👤人工判断
6 在每周市场简报中公示本周新分配与改判商机 销售负责人 每周五前 周简报模板 分配清单 🔧+🤖
7 回收超期未跟进商机（14 天无 CRM 跟进记录）重新分配 渠道负责人（兼 CRM 管理员）→销售负责人 每月第 1 个工作日 CRM 报表 回收清单 🤖自动化
8 出货/签约订单提交时强制填写归属销售，未填不得提交 订单提交人 订单提交前 订单系统/渠道系统必填字段 带归属的订单 🔧飞书固化

5. 交付物与模板

  • 交付物：CRM 中的归属销售字段与分配记录；每周简报中的分配清单；《销售体系管理制度》中的归属分配条款
  • 建议模板/表单（商机分配多维表格）：客户名称、主体信息、来源类型、订单类型（公司直接/渠道）、To G/To B、渠道商、首次报备时间、原跟进人、指定归属销售、分配时间、接收确认时间、首联时间、争议标记、裁决结论、最近跟进日期

6. 异常与升级

  • 渠道直签客户无销售、客户直接找产研/运营 → 产研/运营只登记不长期对接，当天转渠道负责人 → 渠道负责人 1 个工作日内无法承接时升级销售负责人指定
  • 客户事多收益低、无人愿接 → 销售负责人强制指定并按客户分级给出服务口径 → 仍无法落实时升级 CEO（2 个工作日内）
  • 撞单双方证据相当 → 销售负责人裁定主责+协同分成方案 → 不服者 2 个工作日内申请 CEO 终裁
  • 涉及跨主体（跃迁/LeapCore/鼎慧）客户 → 销售负责人与 COO 共同确认签约主体与归属 → 分歧升级 CEO
  • 重大客户（含重大政府客户）归属、跨主体争议，或销售负责人强制指定后仍无人承接 → 终裁权由销售负责人升级至 CEO → 销售负责人 1 个工作日内提请，CEO 2 个工作日内终裁 → 按 X-CS-01 指定售后承接人，销售负责人 1 周内补齐售后衔接条款

7. 衡量指标

  • 无主订单率：出货/签约订单中未关联归属销售的笔数 ÷ 总笔数，目标 0
  • 分配时效：登记到指定归属销售的工作日数，目标 ≤ 1 个工作日
  • 撞单争议数：每月进入裁决的争议笔数，目标逐月下降
  • 首联及时率：分配后 1 个工作日内完成首联的比例，目标 ≥ 95%
  • 产研/运营被客户直接找的次数：每月统计，目标 0

8. 低效诊断

  • 现象：早期商机先到先抢，缺统一入口，撞单与归属争议靠临时协商，后改为统一汇总再分配，但分配规则未写成条款｜依据：「【跃迁】合伙人会议」2026-06
  • 现象：渠道直签/已出货客户没有对接销售，客户反复直接打电话给产研和运营，多人轮流应付后才临时转给渠道侧｜依据：「Leap产研决策部」2026-09
  • 现象：订单与销售无强制关联，出货环节不校验归属，问题到售后阶段才暴露｜依据：「Leap产研决策部」2026-09
  • 现象：销售制度先跑简版，售后承接无配套制度，售后问题回流到销售与产研｜依据：「【跃迁】合伙人会议」2026-04
  • 现象：日报推行受阻改周报，商机进展与分配情况不透明，市场侧进展需当面追问才知道｜依据：「【跃迁】合伙人会议」2026-05
  • 现象：销售战略方案多轮返工、数字核算出错，分配与激励口径随之反复｜依据：「【跃迁】合伙人会议」2026-05

9. 分支变体

  • 直销商机：按“已报备优先→行业/区域/负载”分配，由销售负责人指定
  • 渠道直签客户/渠道出货订单：默认归渠道负责人对接；渠道商自行服务的，仍需指定公司侧对接销售
  • 公司直接订单 vs 渠道订单：激励口径不同（公司直接订单激励已下调），分配时须标注订单类型
  • To G / To B：To G 客户可按区域或政府关系指定，重大政府客户由 CEO 确认

10. 待确认问题

  • 主责是否为销售负责人？渠道直签客户是否默认归渠道负责人？
  • 分配规则按哪些维度（行业、区域、客户规模、负载）？是否需要写入《销售体系管理制度》？
  • 超期回收阈值 14 天是否合适？回收后原销售是否保留部分激励？
  • 订单系统/渠道系统能否把“归属销售”设为必填并拦截？由谁开发？
  • 事多收益低的客户是否设专门的服务口径或补贴，以解决无人愿接问题？
  • 售后承接人由谁担任，与归属销售如何分工（对接 X-CS-01）？
SAL-34销售业绩考核与提成核算待优化192

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：每月/每季度以 CRM 数据对销售做 KPI 考核与档位结算，计算提成奖励；新制定或调整销售奖励政策，或产品成本变动影响奖励兑现时
  • 负责人：主责——销售负责人（当前：李鹏为·推断待确认）；协同——CRM 管理员/渠道负责人（当前：闫登辉·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、销售 KPI 数据整理（当前：汪家诺·推断待确认）、财务专员（当前：待指定）、HR（当前：待指定）、采购/成本核对（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 周期前定稿考核口径 → ② 奖励政策成本核对 → ③ 月末 CRM 数据截止 → ④ 系统自动计分+主管人工评分 → ⑤ 公示与申诉 → ⑥ 导出复核 → ⑦ 提成核算审批 → ⑧ 交财务发放归档
  • 交付结果：经复核的月度 KPI 结果表、季度档位排名表、提成奖励核算表（审批通过并交财务），以及带版本号和生效日的奖励政策文档
  • 状态依据：已有 CRM 业绩看板、评分标准 wiki 与《LeapCore销售人员奖励政策》，但 2026-09～10 考核周期与业绩定义多次调整、部分指标仍需管理员手填，奖励政策发布前未核成本导致某型号奖励无法兑现

1. 场景判定

  • 触发条件：每自然月结束（月度 KPI）；每季度结束（档位结算）；新增或调整提成奖励政策；产品型号成本变动；销售对评分提出疑问
  • 典型说法：「业绩这一块还得重新定一下，目前不单单是回款」「以后不入 CRM 的数据不计入绩效」「按这个成本，这款的奖励发不出去」
  • 判断问题：这件事是否影响某个销售的考核分数、档位或提成金额？是则走本流程
  • 不归本流程管：CRM 客户/商机录入规范 → 请走 SAL-04；销售日报周报 → 请走 SAL-32；渠道分润与推荐费结算 → 请走 SAL-30；产品定价与成本倍率 → 请走 SAL-18；工资发放 → 请走 HR-15；研发绩效 → 请走 HR-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
考核口径与政策负责人 定稿指标、目标值、奖励政策；复核结果 R 销售负责人（当前：李鹏为·推断待确认）
CRM 管理员 维护目标值、导出数据、手填项录入、处理评分疑问 R 渠道负责人兼 CRM 管理员（当前：闫登辉·推断待确认）
CRM 研发 实现自动计分、导出、规则说明展示 R 研发（当前：陈子康、郭逸非·推断待确认）
各销售 按时完成 CRM 录入、查看评分明细、提出申诉 R 全体销售
KPI 数据整理 汇总全员 KPI、计算提成、对接财务 R 销售（当前：汪家诺·推断待确认）
成本核对 奖励政策发布前核对各型号成本可覆盖性 C 采购/成本核对（当前：杨明学·推断待确认）、财务专员（当前：待指定）
人事口径 考核口径与薪酬制度一致性审核 C HR（当前：待指定）
降本与技术评审 成本不足时推动降本 C CTO（当前：丁震宇·推断待确认）
发放 按审批结果发放并入账 R 财务专员（当前：待指定）
销售条线知会 了解考核结果与政策变化 I 销售条线负责人（当前：许君·推断待确认）
终审 批准奖励政策与奖金总额 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 当期有效的考核口径文档（指标、权重、目标线、数据来源、版本号）
  • 当期有效的奖励政策文档及各型号成本核对记录
  • CRM 已成单商机、回款、渠道与转介绍线索数据（截至月末）
  • 主管人工评分项（产品能力、过程管理与价值观）评分表
  • 市场部下发的渠道邀约 KPI（如适用）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 书面定稿下一周期考核口径（周期、7 项指标、目标值、数据源），与 HR 对齐后发布 wiki 并同步 CRM 规则说明；变更只在下一周期生效 销售负责人、HR 每月 25 日前 飞书 wiki、CRM 考核口径 vX 🔧飞书固化
2 新增/调整奖励政策前，按各型号当前成本核对奖励可覆盖性，仅向销售侧输出“可行/不可行+最低毛利线”，不披露成本明细 采购/成本核对、财务专员 收到草案后 3 个工作日内 成本核对表 成本核对记录 👤人工判断
3 销售完成当月 CRM 录入；未入 CRM 的数据不计绩效 各销售 每月最后一个工作日 18:00 前 CRM 截止数据 🔧飞书固化
4 CRM 自动计算前 5 项（90 分）；主管完成 2 项人工评分（10 分） CRM 系统、销售负责人 次月第 3 个工作日内 CRM 业绩看板 月度 KPI 初稿 🤖+👤
5 在 CRM 公示评分明细与规则说明，销售提出申诉，CRM 管理员核查 各销售、CRM 管理员 公示后 2 个工作日内 CRM、飞书审批 申诉处理记录 🔧飞书固化
6 导出月度 KPI 明细/季度排名 Excel，销售负责人复核确认 CRM 管理员、销售负责人 次月第 6 个工作日内 CRM 管理端导出 复核后结果表 🤖自动化
7 按奖励政策计算提成，提交审批（销售负责人→CEO） KPI 数据整理 次月第 8 个工作日内 飞书审批 提成核算表 🤖+👤
8 财务按审批结果随工资发放，结果表与审批归档 财务专员 随当月工资周期 飞书审批、财务系统 发放记录、归档 🔧飞书固化

5. 交付物与模板

  • 交付物：考核口径文档（带版本号、生效周期）；月度 KPI 结果表；季度档位排名表；提成核算表；奖励政策文档（带版本号、生效日）；成本核对记录
  • 建议模板/表单（月度 KPI 结果表）：姓名、考核月份、销售业绩（30）、有效商机与漏斗（15）、客户触达与需求诊断（15）、演示方案试用推进（10）、新客户及渠道生态拓展（20）、产品能力（5）、过程管理与价值观（5）、总分、数据来源、手填项标记、申诉状态、复核人
  • 建议模板/表单（奖励政策成本核对）：政策版本、适用型号、奖励口径、成本核对结论（可行/不可行）、最低毛利线、核对人、核对日期、生效日期

6. 异常与升级

  • CRM 无法从已成单商机自动抓取 → CRM 管理员手填并标记“手填”留痕 → 研发 5 个工作日内给出修复计划，超期升级 CTO
  • 销售看到评分不变、不知原因 → CRM 管理员 1 个工作日内答复并补充页面规则说明 → 同类问题月内超 3 次，升级销售负责人修订说明
  • 考核口径需在周期中途变更 → 默认下一周期生效；确需当期生效的由销售负责人提出、CEO 批准并全员公告
  • 奖励政策发布后发现成本无法覆盖 → 暂停该型号新口径并公告，CTO 推动降本、销售负责人修订政策 → 5 个工作日内报 CEO 决策，已成交订单按原政策执行
  • KPI 数据来源冲突（CRM 与周报不一致）→ 以 CRM 为准；CRM 漏录由销售补录并说明原因 → 争议升级销售负责人
  • 渠道员工销量是否计入公司销售 KPI 存疑 → 销售负责人逐案认定并写入口径文档

7. 衡量指标

  • 考核结果出具周期：月末到结果表复核完成的工作日数，目标 ≤ 6 个工作日
  • 自动计分覆盖率：系统自动计算的分值 ÷ 总分，目标 ≥ 90%（前 5 项全自动）
  • 手填项占比：手填记录数 ÷ 总记录数，目标逐月下降至 0
  • 申诉率与处理时长：申诉人数 ÷ 考核人数；申诉处理 ≤ 2 个工作日
  • 奖励政策成本核对覆盖率：发布前完成成本核对的政策版本占比，目标 100%
  • 奖金发放准时率：随当月工资周期发放的比例，目标 100%

8. 低效诊断

  • 现象：考核周期与业绩定义（仅回款还是多维度）多次调整，口径未书面定稿即进入开发，造成反复改系统｜依据：「跃迁CRM反馈群」2026-09
  • 现象：系统无法从已成单商机直接抓取业绩，需管理员逐条手填，耗时且易错｜依据：「跃迁CRM反馈群」2026-09
  • 现象：评分规则只放在 wiki，CRM 页面无说明，销售看到分数不变反复追问｜依据：「跃迁CRM反馈群」2026-10
  • 现象：奖励政策发布前未走成本核对，发布次日即发现某型号奖励无法兑现｜依据：「leapcore 合同审核群」2026-10
  • 现象：KPI 数据来源（CRM/周报）口径不一，全员 KPI 靠人工整理并反复催办，再对接财务｜依据：「【模态】市场销售」2026-09、「【模态】市场销售」2026-10

9. 分支变体

  • 月度 KPI（自然月，满分 100，导出含 KPI 明细与事实数据）与季度档位结算（仅排名），两套口径独立
  • 一体机奖励：按型号（源核/龙智/震宇款）分别设定，须逐型号核成本
  • 渠道邀约 KPI：由市场部下发，计入销售 KPI 的方式需在口径文档中写明
  • 回款 KPI 与新签 KPI：业绩项是否仅以回款计，待口径定稿
  • 渠道员工销量计入 KPI（某渠道客户案例）：逐案认定

10. 待确认问题

  • 业绩项最终口径：仅回款、仅新签，还是二者加权？由谁签字定稿？
  • 口径定稿时限（每月 25 日前）和结果出具时限（次月第 6 个工作日）是否可行？
  • 奖励政策发布前的成本核对由采购还是财务主责？销售侧只看“可行/不可行”是否满足管理需要？
  • 自动抓取已成单商机的开发由谁负责、何时上线？手填项何时取消？
  • 提成审批链是否为“销售负责人→CEO”？是否需要 HR 会签？
  • 是否已有成文的考核与提成制度（除奖励政策文档外），需与 HR-01 人事制度统一发布？
SAL-35销售人员离岗客户与商机交接待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：销售/渠道经理离职、调岗、长期休假或客户归属调整时，把其名下客户、商机、合同、回款与对客承诺完整移交给接手人并告知客户
  • 负责人：主责——销售负责人（当前：待指定）；协同——离岗销售、接手销售、HR 专员、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）
  • 核心流程：① 离岗/调整确认 → ② CRM 导出名下客户与商机清单 → ③ 指定接手人 → ④ 逐客户交接（商机阶段、合同、回款、承诺、关键联系人）→ ⑤ 联合告知客户 → ⑥ CRM 归属变更 → ⑦ 30 天跟踪复核
  • 交付结果：双方确认的客户交接清单；CRM 归属已变更；客户已收到对接人变更通知
  • 状态依据：已有 HR-27（员工离职办理与交接）覆盖通用交接环节，本条补齐销售岗位的客户关系、未回款合同与对客承诺交接（推断）

1. 场景判定

  • 触发条件：销售提出离职/被调岗；连续休假超过 2 周；SAL-33 判定客户归属需调整
  • 典型说法：「他走了这个客户谁跟？」「之前答应过客户什么我们都不知道」
  • 判断问题：该人员名下是否还有 CRM 客户、在途商机、未回款合同或未兑现承诺？
  • 不归本流程管：通用离职手续与账号回收 → 请走 HR-27、X-SEC-08；新商机归属分配 → 请走 SAL-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交接负责人 指定接手人、审核交接清单 A 销售负责人（当前：待指定）
离岗销售 整理名下清单、逐项讲清并陪同告知客户 R 离岗销售（当前：待指定）
接手销售 核对清单、确认接收、30 天内完成首次拜访 R 接手销售（当前：待指定）
HR 触发通知、将交接完成作为离职手续前置项 C HR 专员（当前：待指定）
财务 提供名下未回款与未开票清单 C 财务专员（当前：待指定）
CRM 管理员 变更客户/商机归属并保留历史 R CRM 管理员（当前：待指定）

3. 办之前请准备

  • CRM 中该人员名下客户、商机、合同、回款记录导出表
  • 财务出具的未回款、未开票、在途付款清单
  • 对客书面承诺（邮件、聊天截图、方案报价）及在途试用/借机清单（SAL-16、SAL-17）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 离职/调岗审批通过后通知销售负责人 HR 专员 审批通过当天 飞书审批 交接触发通知 🔧飞书固化
2 导出名下客户、商机、合同、回款清单 CRM 管理员 触发后 1 个工作日内 CRM 交接底表 🤖自动化
3 指定接手人（可按客户拆分给多人） 销售负责人 触发后 2 个工作日内 飞书 接手人分配表 👤人工判断
4 逐客户补全阶段、承诺、风险、联系人 离岗销售 离岗日前 3 个工作日内 交接模板 交接清单 🔧飞书固化
5 双方逐项过清单并确认接收 离岗销售、接手销售 离岗日前 2 个工作日内 线下/会议 双方确认记录 👤人工判断
6 联合告知重点客户对接人变更 离岗销售、接手销售 离岗日前 电话/微信/邮件 客户告知记录 👤人工判断
7 CRM 归属变更、历史记录保留 CRM 管理员 确认后 1 个工作日内 CRM 归属变更日志 🔧飞书固化
8 30 天内复核回款与商机推进情况 销售负责人 交接后第 30 天 CRM 复核结论 👤人工判断

5. 交付物与模板

  • 交付物：客户交接清单、客户告知记录、CRM 归属变更日志
  • 建议模板/表单：客户交接清单（客户名、等级、商机阶段、预计成交时间、合同号、未回款、未开票、对客承诺、在途试用/借机、关键联系人及关系、风险提示、接手人、确认时间）

6. 异常与升级

  • 离岗人员已无法配合 → 由销售负责人依据 CRM 与财务清单补齐，逐客户电话回访确认 → 升级销售部门报送人（3 个工作日内）
  • 发现未登记的口头承诺或私下优惠 → 记入风险清单，按 SAL-17 补报备 → 升级销售负责人（1 个工作日内）
  • 客户因对接人变更表示不满或流失风险 → 销售负责人亲自拜访 → 升级管理层（1 周内）

7. 衡量指标

  • 交接完整率 = 清单覆盖客户数 / CRM 名下客户数，目标 100%
  • 交接后 90 天客户流失数，目标 0（重点客户）
  • 交接后未回款合同按期回款率，目标 ≥ 交接前水平

8. 低效诊断

  • 聊天中未见相关流程，存在客户关系随人员流失、未回款合同无人跟进、口头承诺无人兑现的风险（推断）

9. 分支变体

  • 渠道经理离岗：同步交接渠道协议、分润与在途报备（SAL-27、SAL-30、SAL-31），并通知渠道伙伴
  • 跃竞等其他主体销售：按各主体 CRM 独立执行

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 销售交接是否作为 HR 离职手续的前置签字项？
  • 离岗前交接期留几个工作日合适？
  • 交接后在途商机的业绩/提成如何在离岗人与接手人之间划分（SAL-34）？
SAL-36销售合同变更、终止与退换货处理待新建推断200

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：已签销售合同需要变更（数量、配置、交付时间、付款条件）、客户要求解除合同、退货/换货或退款时，统一评估、审批并完成合同、账务与交付侧闭环
  • 负责人：主责——销售负责人（当前：待指定）；协同——客户对接销售、法务、财务专员、交付负责人（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）
  • 核心流程：① 受理客户书面请求 → ② 影响评估（成本、库存、已交付部分）→ ③ 方案与报价 → ④ 法务/财务会审 → ⑤ 审批 → ⑥ 签补充协议/解除协议 → ⑦ 退换货与退款/红冲 → ⑧ CRM 与台账更新
  • 交付结果：签署的补充协议或解除协议；完成的退换货、退款或红冲；更新后的合同台账与 CRM
  • 状态依据：已有 SAL-23（销售合同起草与用印）、LEG-03（销售合同审查会签）覆盖签约前环节，本条补齐签约后的合同变更、解约与 B 端退换货（推断）

1. 场景判定

  • 触发条件：客户书面提出改配置/改数量/延期/提前终止；硬件到货不符或客户不满意要求退换；项目因客户原因中止
  • 典型说法：「客户想把两台改成一台」「客户要退货，钱怎么退」「合同能不能改一下交付时间」
  • 判断问题：合同是否已签署生效？变更是否影响金额、交付物、税率或已开票部分？
  • 不归本流程管：签约前合同起草、谈判与审查 → 请走 SAL-23、LEG-03；签约后新增需求 → 请走 SAL-25；硬件故障维修 → 请走 X-CS-12；C 端退款 → 请走 X-CS-10；计费扣费退补 → 请走 X-CS-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批人 批准变更/解约方案 A 销售负责人（当前：待指定）
对接销售 受理请求、出方案、与客户谈判 R 客户对接销售（当前：待指定）
法务 审核补充协议/解除协议与违约责任 C 法务专员（当前：待指定）
财务 核算已收款、已开票、退款与红冲 C 财务专员（当前：待指定）
交付 评估已交付/已装机部分与回收可行性 C 交付负责人（当前：待指定）

3. 办之前请准备

  • 原合同、报价单、已签收/验收单（X-DLV-29）
  • 已收款、已开票明细
  • 客户书面变更/解约/退货请求（邮件或盖章函件）
  • 设备序列号、指纹登记与当前状态（X-DLV-31）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 受理请求，要求客户书面提交 对接销售 收到后 1 个工作日内 邮件/CRM 变更请求记录 🔧飞书固化
2 评估成本、库存、已交付部分与违约责任 对接销售、交付负责人、财务专员 受理后 3 个工作日内 合同台账 影响评估表 👤人工判断
3 形成变更/解约方案与新报价 对接销售 评估后 2 个工作日内 报价模板 方案与报价 👤人工判断
4 法务、财务会审 法务专员、财务专员 提交后 2 个工作日内 飞书审批 会审意见 🔧飞书固化
5 审批 销售负责人 会审后 1 个工作日内 飞书审批 审批结果 🔧飞书固化
6 签署补充协议或解除协议并用印 对接销售 审批后 5 个工作日内 LEG-09 用印 盖章协议 👤人工判断
7 回收/更换设备，注销指纹与席位 交付负责人 协议生效后 5 个工作日内 资产台账 回收/换货记录 👤人工判断
8 退款或红冲开票 财务专员 设备回收确认后 5 个工作日内 金蝶/银行 退款回单、红字发票 🔧飞书固化
9 更新合同台账与 CRM 对接销售 完成后 1 个工作日内 CRM 台账更新 🤖自动化

5. 交付物与模板

  • 交付物：补充协议/解除协议、退换货记录、退款回单或红字发票、台账更新记录
  • 建议模板/表单：合同变更申请单（原合同号、变更类型、变更内容、金额影响、已收款、已开票、已交付设备、违约责任、客户书面依据、会审意见、审批结论）

6. 异常与升级

  • 设备已开封使用或损坏 → 交付评估折旧与翻新成本，按协议扣减 → 升级销售负责人（2 个工作日内）
  • 客户以投诉或舆论施压 → 按 X-CS-27 处理，暂停对外承诺 → 升级管理层（1 个工作日内）
  • 已开票跨月或跨年 → 财务确认红冲口径 → 升级财务负责人（1 个工作日内）

7. 衡量指标

  • 变更处理周期 = 受理到协议签署的自然日，目标 ≤ 10 天
  • 退款完成周期 = 设备回收确认到退款到账，目标 ≤ 7 天
  • 无书面协议的变更数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在口头改合同、退货未回收设备、退款与红冲不一致导致资金与税务风险（推断）

9. 分支变体

  • 渠道订单变更：经渠道系统发起，渠道协议另有约定的从其约定（SAL-31）
  • 政府/国企项目：变更需客户内部流程，补充协议以客户模板为准

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 变更/解约的审批层级是否按金额分级？分级线由谁定？
  • 已开封硬件是否接受退货？折旧口径如何？
  • 退款是否需 CEO/COO 审批？
SAL-37商务招待、礼品与反商业贿赂合规待新建推断90

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨3 × 险5

  • 适用场景：销售、市场、FDE 在对接客户（尤其政府、国企、事业单位）时发生宴请、礼品、差旅邀请、样机赠送、中间人推荐费等商务往来，事前判断是否合规并审批留痕
  • 负责人：主责——销售负责人（当前：待指定）；协同——法务专员、财务专员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）
  • 核心流程：① 识别商务往来类型 → ② 对照红线清单 → ③ 事前申请 → ④ 审批 → ⑤ 执行并留存凭证 → ⑥ 报销时核对 → ⑦ 季度抽查
  • 交付结果：经审批的招待/礼品记录；合规的报销凭证；季度抽查结论
  • 状态依据：已有 SAL-17（赠送额度、借机与特殊商务行为报备）覆盖部分环节，本条补齐宴请、礼品、差旅邀请与推荐费等商务往来的反商业贿赂规则；“政企客户占比较高”为推断（推断）

1. 场景判定

  • 触发条件：拟宴请客户、赠送礼品或周边、邀请客户参访/参会并承担费用、向介绍人或客户方个人支付推荐费
  • 典型说法：「请客户吃个饭能报吗」「客户那边的人想要个推荐费」「给对方领导带点伴手礼」
  • 判断问题：对方是否为国家工作人员或客户采购决策人？是否处于招投标或合同谈判期？费用是否给到个人？
  • 不归本流程管：赠送额度/借机 → 请走 SAL-17；渠道分润与推荐费结算 → 请走 SAL-30；伴手礼、品牌周边的采购制作与赠送出入库登记 → 请走 ADM-19（本流程只判断能否送、送给谁并事前审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批人 事前审批招待/礼品申请 A 销售负责人（当前：待指定）
申请人 事前申请、执行、留存凭证 R 客户对接销售（当前：待指定）
法务 制定红线清单、判定疑难情形 C 法务专员（当前：待指定）
财务 报销时核对审批记录、季度抽查 C 财务专员（当前：待指定）

3. 办之前请准备

  • 对方单位性质、参与人员身份与职务
  • 当前商机阶段（是否在投标/谈判期）
  • 预计费用与形式（宴请/礼品/差旅/推荐费）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照红线清单自查（禁止现金、购物卡、给个人回扣、投标期宴请评委等） 申请人 发生前 红线清单 自查结论 👤人工判断
2 提交招待/礼品事前申请 申请人 发生前 1 个工作日 飞书审批 申请单 🔧飞书固化
3 审批，疑难情形转法务 销售负责人 提交后 4 小时内 飞书审批 审批结果 🔧飞书固化
4 执行并留存发票、参与人名单、事由 申请人 发生当天 飞书 凭证 👤人工判断
5 报销时关联事前审批单 申请人 发生后 10 个工作日内 FIN-06 报销 报销单 🔧飞书固化
6 核对审批与凭证一致，未审批的退回 财务专员 收单后 3 个工作日内 飞书审批 审核结论 🤖+👤（系统比对，人工复核退回）
7 季度抽查与红线清单更新 法务专员、财务专员 每季度首月 15 日前 台账 抽查报告 👤人工判断

5. 交付物与模板

  • 交付物：红线清单、招待/礼品台账、季度抽查报告
  • 建议模板/表单：商务招待申请单（客户单位、单位性质、参与人及职务、商机阶段、形式、预计费用、事由、是否涉及国家工作人员、审批人）

6. 异常与升级

  • 客户方个人索要好处费或回扣 → 立即拒绝并记录 → 升级销售负责人与法务（当天）
  • 事后发现未审批招待 → 财务退回报销，补说明 → 升级销售负责人（2 个工作日内）
  • 中间人要求按成交额提成 → 只能走 SAL-30 签书面协议、对公结算 → 升级法务（2 个工作日内）

7. 衡量指标

  • 招待事前审批率 = 有事前审批的招待报销数 / 招待报销总数，目标 100%
  • 季度抽查违规数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在对政企客户不当利益输送、推荐费付给个人引发商业贿赂与税务风险（推断）

9. 分支变体

  • 政府/事业单位客户：原则上不赠礼品、不宴请，仅限工作餐（推断，具体口径待法务确认）
  • 海外客户：另需遵守对方国家反腐败法规，由法务单独判断

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 招待与礼品的标准额度由谁定、按什么口径？
  • 是否需要全员签署反商业贿赂承诺书？
  • 推荐费/中间人费用目前如何支付？是否全部走对公？
  • 与 ADM-19 的伴手礼边界：礼品采购与出入库归行政，赠送对象与合规审批归本流程，是否认可？
SAL-38销售目标分解、商机预测与月度 Pipeline 复盘待新建推断144

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：每季度/每月把销售目标分解到人与产品线，并基于 CRM 商机做成交预测，输出给交付备货、财务资金计划与管理层
  • 负责人：主责——销售负责人（当前：待指定）；协同——各销售、交付负责人、财务专员、CRM 管理员（当前：待指定）；兜底——销售部门报送人（当前：许君、李鹏为·部门报送人）
  • 核心流程：① 季度目标分解到人 → ② 月末商机阶段更新 → ③ 生成预测表（承诺/可能/机会三档）→ ④ Pipeline 复盘会 → ⑤ 输出备货与资金预测 → ⑥ 月度偏差复盘
  • 交付结果：季度目标分解表；月度销售预测表；复盘会纪要与行动项；给交付的硬件需求预测
  • 状态依据：已有 X-DLV-04（出货排期与机器调配）、SAL-06（重点商机上报分级）覆盖部分环节，本条补齐销售目标分解、商机预测与 Pipeline 复盘，为备货提供前置输入（推断）

1. 场景判定

  • 触发条件：季度初；每月最后一周；出现大单或抢机
  • 典型说法：「下个月大概要出多少台」「这个季度能签多少」「库存又不够了」
  • 判断问题：是否需要对未来 1～3 个月的成交与出货做量化判断？
  • 不归本流程管：年度战略规划 → 请走 CEO-01；销售业绩提成 → 请走 SAL-34；单个大客户推进 → 请走 SAL-06；具体订单的出货排期与抢机调配 → 请走 X-DLV-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
预测负责人 目标分解、组织复盘、对预测负责 A 销售负责人（当前：待指定）
销售 更新商机阶段、金额、预计成交月与配置 R 各销售（当前：待指定）
交付 依据预测评估库存与采购周期 C 交付负责人（当前：待指定）
财务 依据预测编制回款与资金计划 I 财务专员（当前：待指定）
CRM 管理员 维护阶段定义、生成预测报表 R CRM 管理员（当前：待指定）

3. 办之前请准备

  • 季度目标（来自 CEO-01）
  • CRM 商机全量导出（阶段、金额、预计成交月、产品/配置）
  • 上月预测与实际成交、出货对比

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 季度目标分解到人、产品线、渠道 销售负责人 季度首周内 多维表格 目标分解表 👤人工判断
2 更新名下全部商机阶段与预计成交月 各销售 每月倒数第 3 个工作日前 CRM 更新后的商机 🔧飞书固化
3 生成三档预测表与硬件需求汇总 CRM 管理员 每月倒数第 2 个工作日 CRM 报表 预测表 🤖自动化
4 Pipeline 复盘会：逐单过承诺档、识别卡点 销售负责人 每月最后 1 个工作日 会议 纪要与行动项 👤人工判断
5 向交付、财务发送预测 销售负责人 复盘会后 1 个工作日内 飞书 备货与资金输入 🔧飞书固化
6 计算上月预测偏差并说明原因 CRM 管理员 每月第 3 个工作日前 CRM 报表 偏差分析 🤖自动化

5. 交付物与模板

  • 交付物：目标分解表、月度预测表、复盘纪要、硬件需求预测
  • 建议模板/表单：商机预测表（商机、客户、销售、阶段、预测档位、预计成交月、产品/配置、台数、是否需备货、风险、下一步）

6. 异常与升级

  • 承诺档商机连续两月未成交 → 降档并说明原因 → 升级销售负责人（复盘会当场）
  • 预测硬件需求超过库存加在途 → 交付发起补货评估（X-DLV-02）→ 升级管理层（2 个工作日内）
  • 销售未按期更新商机 → 系统提醒，复盘会点出 → 升级销售负责人

7. 衡量指标

  • 预测准确率 = 承诺档实际成交数 / 承诺档商机数，目标 ≥ 70%
  • 商机按期更新率，目标 100%
  • 因库存不足导致的交付延期单数，目标逐季下降

8. 低效诊断

  • 聊天中未见相关流程，存在备货滞后导致抢机延期、资金计划无依据的风险（推断）

9. 分支变体

  • 渠道销售：由渠道经理汇总渠道系统报备商机后纳入预测（SAL-31）
  • API/额度类销售：按充值金额预测，不涉及备货

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • CRM 当前是否有统一的商机阶段定义？
  • 复盘会是否并入现有销售周会？
  • 预测是否需要同步给研发作为交付人力规划输入？

OPS 运营

报送人：李宣昊 · 运营 · 29 条 · 已有 0 / 待优化 17 / 待新建 12
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
OPS-01新站点/分站上线运营配置新开对外可注册、可付费的分站（Sorux 模态版、code.leapinfra.cn 编码站、MerCode 等），或现有分站改名、换支付渠道、改站内币时，完成从命名到试付验收的上线配置主责——站点配置工程师（当前：宋祺睿·推断待确认）；协同——站点与账号拥有者（当前：丁震宇·推断待确认）、测试（当前：王皓南·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 上线立项单（命名/域名/主体）→ ② 开管理员账号与收件邮箱 → ③ 站点基础配置 → ④ 支付渠道配置与资金账户核对 → ⑤ 币种/计费文案法务审核 → ⑥ 测试账户试付与全链路验收 → ⑦ 上线检查表签核后发布并登记通过上线检查表签核、试付成功的分站，以及一条站点登记记录（域名、主体、支付渠道、邮箱、负责人、上线日期）待新建96
OPS-02模型上线与定价规则LeapOne 新上线模型、调整收费、开放充值、赞助比赛或活动需要临时开充值/发代金券时，按统一规则核对成本、定价并开放主责——LeapOne 运营负责人（当前：李凯·推断待确认）；协同——LeapOne 研发负责人（当前：黄振锋·推断待确认）、LeapOne 产品负责人（当前：杨萌·推断待确认）、成本价提供人（当前：闫登辉·推断待确认）、统一支付研发（当前：陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 运营提出上线/调价清单 → ② 研发确认上游渠道与可用性 → ③ 取 API 成本价 → ④ 按毛利底线定价并自动校验 → ⑤ 审批 → ⑥ 配置上线并核验扣费 → ⑦ 充值/代金券安排 → ⑧ 月度毛利与对账复核经审批的模型定价表（含成本价、售价、毛利率），已配置上线并核验的模型与价格，以及充值/代金券发放记录待新建72
OPS-03帮助中心、使用手册与更新日志维护产品每次迭代上线、hotfix、新功能开放或内测/公测时，同步更新帮助中心、使用手册、FAQ、更新日志、教学视频、官网与客服入口，并自检不影响安装包下载主责——帮助中心与手册负责人（当前：杨萌·推断待确认）；协同——文档运营（当前：杨黔昆·推断待确认）、发布部署（当前：宋祺睿·推断待确认）、客户端前端（当前：葛家和·推断待确认）、产品经理（当前：陈震·推断待确认）、跃竞线产品负责人（当前：徐莉·推断待确认）、跃竞线文档更新（当前：陈雁·推断待确认）、LeapPPT 运营负责人（当前：李凯·推断待确认）、视频制作（当前：魏宗浩·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发版清单触发"文档同步"任务 → ② 研发提供变更汇总 → ③ AI 起草更新日志/手册改动 → ④ 产品审核内容 → ⑤ preview 环境自检 → ⑥ PR 合并部署 prod → ⑦ 同步客服知识库与群通知 → ⑧ 归档到飞书知识库已上线的帮助中心/手册/FAQ 更新、与版本号对应的更新日志、同步后的客服知识库，必要时附教学视频待优化144
OPS-05全员使用自研产品推动与内测反馈自研产品（LeapAll、LeapPPT、LeapCore、许愿机及各类小工具）内部上线或内测时，推动全员安装使用、邀请非研发同事试用，统计用量、督促落后部门，并把反馈收束到统一入口主责——内部推广负责人（当前：杨萌·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、反馈收口人（当前：杨黔昆·推断待确认）、版本发布（当前：岳阳·推断待确认）、额度与链接（当前：宋祺睿、张东郅·推断待确认）、各部门负责人（当前：徐莉、赵雪冰、李凯 等·推断待确认）、人事（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发布内部使用公告 → ② 部门负责人确认责任 → ③ 当天安装与首次真实场景使用 → ④ 每周用量数据公示 → ⑤ 未使用名单自动提醒 → ⑥ 反馈统一入表、分派 → ⑦ 场景提交与月度考核 → ⑧ 周报复盘全员安装与使用记录、每周使用数据公示、反馈池（含处理状态）、各部门月度场景提交记录、积分/奖惩依据待优化135
OPS-06员工 AI 补贴与内部余额月度充值核对每月 AI 补贴发放日，通知员工用补贴充值 LeapAll、统一为全员补充 LeapCore 内部余额，次日拉后台名单提醒未完成者，月底核对并输出补贴保留/取消依据；含政府消费券领取、购买与核销主责——内部余额管理员（当前：杨萌·推断待确认）；协同——LeapAll 服务端（当前：邓乾·推断待确认）、LeapCore 后端（当前：宋祺睿·推断待确认）、人事（当前：黄莹·推断待确认）、券与活动（当前：葛家和、胡橙橙·推断待确认）、财务（当前：待指定）、计费口径（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 补贴到账后发充值通知 → ② LeapCore 全员余额批量补充 → ③ 员工自行充值 LeapAll/核销券码 → ④ 次日按飞书手机号匹配后台数据 → ⑤ 机器人提醒未完成者 → ⑥ 月底核对、例外处理 → ⑦ 输出名单交人事/财务 → ⑧ 记录留档月度充值核对表（人员、账号、手机号、LeapAll 充值、LeapCore 补充、券码核销、例外说明），交人事/财务的补贴处理名单，批量充值审计记录待优化144
OPS-07试用额度与兑换券申请、发放与登记内部员工、天使用户、合作方、媒体、内测客户、活动参赛者需要 LeapAll 额度、LeapPPT 券码、MerCoder 体验券或模态币时，经表单申请、分级审批、自动或人工发放，并在统一台账登记对内外发放记录主责——额度与券码管理员（当前：杨萌·推断待确认）；协同——LeapAll 充值经办（当前：邓乾·推断待确认，备岗：张康·推断待确认）、LeapPPT 发券（当前：马漳毓·推断待确认）、表单与自动化（当前：陈晖·推断待确认）、发券接口（当前：黄振锋·推断待确认）、审批人（当前：丁震宇、李凯、李铭熙·推断待确认）、活动额度配置（当前：宋祺睿·推断待确认）、活动测试（当前：张东郅·推断待确认）、活动负责人（当前：陈梦琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 申请人填表（产品、环境、用途、数量、账号）→ ② 按规则自动放行或分级审批 → ③ 接口自动发放/人工发放 → ④ 发放结果回写并通知申请人 → ⑤ 对外发放登记台账 → ⑥ 活动券上线前测试 → ⑦ 每月统计发放量与成本已到账的额度或券码、含申请-审批-发放-回执的完整记录、对内对外统一发放台账、月度发放统计待优化300
OPS-08邀请码申请与账号开通外部用户、客户、渠道或内部同事需要试用字字可研等产品时，受理邀请码/验证码申请、开通生产或测试账号与管理后台账号、发放额度包，并记录申请来源与处理状态主责——账号开通运营（当前：杨萌·推断待确认）；协同——后台研发（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、业务专家/回访（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、渠道对接（当前：闫登辉·推断待确认）、基石计划跟进（当前：黄飞鹏·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 申请入表（产品内申请/表单）→ ② 状态字段与来源标记 → ③ 运营审核真伪 → ④ 后台生成并短信发送邀请码 → ⑤ 开通账号与额度包 → ⑥ 回写状态、处理人 → ⑦ 回访与渠道统计申请人收到可用的邀请码或账号（正确环境），申请记录带状态（待处理/已发/拒绝）、处理人和来源渠道；后台账号按角色开通待优化96
OPS-09用户额度包与企业组织运维LeapAll / LeapCore / 字字可研用户需要月度额度重置、特殊用户调额、补词元，或用户反馈充值未到账、余额异常，或企业客户要求开通/删除组织、转移组织管理员时启动主责——产品负责人（额度规则与变更审批，当前：杨萌·推断待确认）；协同——后台/NewAPI 研发（当前：宋祺睿、柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、品牌/Logo 设计对接（当前：待指定）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交额度/组织变更申请 → ② 按额度规则核对口径 → ③ 审批 → ④ 后台执行（批量脚本或单条） → ⑤ 测试/抽查核对余额 → ⑥ 通知申请方及关联方（换 Logo 等） → ⑦ 台账留痕已在后台生效且经核对的额度/组织变更，以及一条可追溯的变更记录（申请人、规则依据、执行人、生效时间）待优化144
OPS-10渠道卡密生成、额度包配置与核销外部平台（AI 内容平台、AI 商城、地推活动等）需要售卖或兑换本公司产品，需要完成厂商接入、额度包配置、卡密/渠道邀请码生成、发放登记与核销查询时启动主责——产品负责人（渠道接入统筹，当前：杨萌·推断待确认）；协同——渠道需求/商务对接（当前：段涵·推断待确认）、后台研发（当前：宋祺睿·推断待确认）、后端实现（当前：王皓南·推断待确认）、兑换/钱包后端（当前：邓乾·推断待确认，备岗：岳阳·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、外部沟通（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 渠道需求立项 → ② 定额度包与结算口径（人工审批） → ③ 后台配置额度包与渠道 → ④ 测试验证 → ⑤ 后台生成卡密并登记 → ⑥ 加密交付渠道并留档 → ⑦ 核销查询/接口对接 → ⑧ 月度对账已配置并验证的渠道额度包、登记在册的卡密批次、交付记录，以及可随时查询的核销状态与月度渠道对账表待新建300
OPS-11OPC 商城自营商品上架、下架与补货公司自营的卡密、兑换券、Skill、算力加油包或主管单位要求上架的免费产品，需要在 OPC 商城上架、下架、补货或因退款销毁卡密时启动主责——OPC 商城运营（当前：陈梦琪·推断待确认）；协同——卡密管理员（当前：葛家和·推断待确认）、商品提供方研发（当前：邓乾·推断待确认）、兑换接口研发（当前：望政韬·推断待确认）、退款审核（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 商品上架申请 → ② 提交介绍与卡密 → ③ 卡密导入核对并登记台账 → ④ 商城录入、内部试用 → ⑤ 正式上线 → ⑥ 库存监控与补货 → ⑦ 下架/退款销毁留痕在 OPC 商城正常售卖且库存充足的商品；记录完整的卡密台账（每批上架、补货、销毁的操作人与原因）待优化192
OPS-12渠道来源 UTM 链接/二维码申请与追踪市场活动、生态大会、媒体投放、线下积分卡或运营推广需要带来源标识的注册链接/二维码，并在后台统计渠道转化时启动主责——渠道码管理员（当前：张东郅·推断待确认）；协同——需求方产品负责人（当前：杨萌·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、研发（当前：马漳毓、黄振锋·推断待确认）、技术方案（当前：王皓南·推断待确认）、渠道推广（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交渠道码申请 → ② 按规范命名 utm_source → ③ 确认正式环境支持 → ④ 生成长期链接/短链/二维码 → ⑤ 测试扫码注册归因 → ⑥ 交付并登记 → ⑦ 周度归因报表可用于投放的带 utm_source 的长期链接/二维码，渠道登记记录，以及按渠道统计的注册转化报表待优化72
OPS-13拉新增长活动策划与传播物料产品内测拉新、邀请注册、分享红包/代金券/额度赠送等增长活动需要立项，以及配套传播文案与物料需要统一发布时启动主责——运营负责人（当前：李凯·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、方案提议人（当前：王皓南、丁震宇·推断待确认）、风控评审（当前：宋祺睿·推断待确认）、传播执行（当前：赵雪冰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 活动立项（目标/预算/承接） → ② 风控与财务审批 → ③ 产品承接与研发配置 → ④ 文案物料生成与审核 → ⑤ 定版发布 → ⑥ 活动监测 → ⑦ 复盘经审批的活动方案、唯一定版的传播物料与发布记录，以及活动结束后 5 个工作日内的复盘报告（拉新数、成本、薅羊毛拦截情况）待新建144
OPS-14种子用户与产品用户社群运营团队成员邀请朋友、客户、学生、媒体老师试用产品，需要发券并拉入用户群；或产品用户社群需要明确归属、处理新成员入群与账号变更时启动主责——运营负责人（当前：李凯·推断待确认）；协同——产品（当前：杨萌、杨黔昆·推断待确认）、邀请人（当前：王皓南、杨朋伟、邴龙志等·推断待确认）、表单维护（当前：陈晖·推断待确认）、话术/FAQ（当前：胡橙橙·推断待确认）、企微认证（当前：侯明月·推断待确认）、兼职研发（当前：黄振锋·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 邀请人提交发券申请（含用户微信号） → ② 先拉群/加客服 → ③ 审批发券 → ④ 入群欢迎与须知 → ⑤ 收集反馈 → ⑥ 周度抽查与种子用户识别 → ⑦ 社群维护（换号、清理）每个获券用户都已进入对应用户群或添加客服；种子用户名单与反馈记录；每个产品社群有明确负责人和入群须知待新建144
OPS-15付费用户识别、跟踪与挽留C 端产品（如字字可研）出现充值用户，或用户充值后停止使用，需要识别是否真实用户、跟踪回访、收集反馈并挽留或引导升级时启动主责——用户运营建联（当前：王满·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、数据查询（当前：陈锦杰·推断待确认）、权限开通（当前：宋祺睿·推断待确认）、销售承接（当前：吴琪·推断待确认）、挽留额度审批（当前：丁震宇·推断待确认）；兜底——运营负责人（当前：李宣昊·推断待确认）① 付费事件推送 → ② 按权限查看用户信息 → ③ 判定真实用户/调研/放弃 → ④ 首次建联 → ⑤ 赠额度与邀请反馈（审批） → ⑥ 引导企业版/LeapCore → ⑦ 台账跟进付费用户跟进台账（每个付费用户的类型判定、联系记录、反馈、赠送额度、转化结果）待新建72
OPS-16用户反馈收集与归集用户在产品群、用户群、客服渠道反馈问题或 Bug，需要自动或人工汇总进多维表格并流转给产品/研发时启动主责——产品运营（当前：杨黔昆·推断待确认）；协同——反馈工具提供（当前：王皓南·推断待确认）、工具打包（当前：宋祺睿·推断待确认）、需求读取（当前：马漳毓·推断待确认）、飞书权限管理员（当前：待指定）；兜底——产品负责人（当前：杨萌·推断待确认）① 固定反馈机器人入群并开权限 → ② 每日定时抽取群消息 → ③ AI 识别反馈、去重、打标签 → ④ 写入反馈表 → ⑤ 人工确认分级 → ⑥ 转需求/Bug 工单 → ⑦ 周报与回复用户每日更新、已去重分级的用户反馈多维表格，每条反馈有处理状态与去向（需求/Bug/不处理），以及每周反馈周报待优化54
OPS-17运营数据需求、看板与统计口径产品、运营、管理层或俱乐部业务方需要用户使用、成本、额度、订单等运营数据（一次性取数、固定看板、每日推送、月度导出）时启动主责——数据与后台研发（当前：宋祺睿·推断待确认）；协同——指标口径审定（产品负责人，当前：杨萌·推断待确认）、遥测研发（当前：邓乾·推断待确认）、管理后台研发（当前：柯逸飞·推断待确认）、跃竞后端/前端（当前：张楠、陈真炎·推断待确认）、跃竞运维（当前：席博田·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 表单提需求 → ② 查指标字典/已有看板 → ③ 确认口径 → ④ 取数或开发看板 → ⑤ 需求方核对 → ⑥ 交付归档 → ⑦ 重复需求固化为定时报表/机器人推送口径明确、标注环境的数据结果（表格/看板/每日推送）及更新后的指标字典条目待优化144
OPS-18内容运营选题审核与发布排期LeapCore 等产品公众号、视频号、社群推文需要按周持续产出，进行选题、草稿、审核、排期发布与产出考核时启动主责——新媒体运营（当前：鲁周毅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、市场负责人（当前：许君·推断待确认）、新媒体执行（当前：徐沛、侯晨帆·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）① 月度内容日历 → ② 收集选题 → ③ 每周选题会 → ④ 撰写草稿存草稿箱 → ⑤ 事实核对 → ⑥ 终审 → ⑦ 排期发布 → ⑧ 回填数据与周报考核按排期发布的推文/视频；内容宣发排期表中每条内容有选题、负责人、审核人、发布时间和数据；每周运营周报待优化54
OPS-19AI 资讯日报生成与社群分发每天定时采集 AI 新闻、社交媒体、RSS、公众号信源，生成 AI 大事件日报，推送内部飞书群和对外社群（开源聚变 AI 社区），并归档往期、安排发布人 AB 角时启动主责——日报发布人（新媒体运营）（当前：鲁周毅·推断待确认）；协同——信源与 skill 维护（当前：宋祺睿、丁震宇·推断待确认）、公众号订阅数据接口（当前：李凯·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）① 维护统一信源清单 → ② 定时采集 → ③ AI 去重筛选分类出 Top 8～10 → ④ 人工抽检终审 → ⑤ 推送飞书群 → ⑥ 适配格式发微信社群 → ⑦ 自动归档 → ⑧ 每周按反馈调整规则每日一期日报（飞书版 + 微信社群版）；可按日期/分类检索的往期归档表待优化36
OPS-20客户案例沉淀与宣传客户用产品做出可量化成果、交付满半个月需形成深度使用反馈，或销售/渠道推广缺少某行业案例时，启动案例发现、登记、量化、标杆培育与入库主责——销售运营（案例库管理）（当前：韩诗琪·推断待确认）；协同——各客户经理（当前：朱文瑜等·推断待确认）、案例包装（当前：丁震宇、闫登辉·推断待确认）、对外表述（当前：许君·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——市场销售负责人（当前：待指定）① 发现即登记 → ② 交付 15 天自动催反馈 → ③ 量化效果 → ④ 判定可公开度并取得授权 → ⑤ 按模板成稿 → ⑥ 审核入库 → ⑦ 分发销售/市场 → ⑧ 月度盘点案例库（多维表格）中审核通过的案例条目（行业、场景、效果数据、素材、可公开度、授权状态）；每月标杆案例清单待优化108
OPS-21内部 AI 应用场景与创意征集推广 LeapAll/LeapCore 或推进全员 AI 化时，需要向全员征集 AI 提效场景、使用案例、开源 idea、产品缺口场景、外呼等专项需求，并评审、激励、落地时启动主责——产品负责人（征集统筹）（当前：杨萌·推断待确认）；协同——人事（当前：黄莹·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、业务专家（当前：王满·推断待确认）、技术复现（当前：陈晖、王皓南·推断待确认）、学习委员（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 征集立项（目的、标准、评审团、激励、截止）→ ② 激励规则审批 → ③ 统一入口发布 → ④ 收集与提醒 → ⑤ AI 初筛聚类 → ⑥ 评审打分 → ⑦ 公示与激励 → ⑧ 入选项转任务/skill/开源 → ⑨ 复盘统一需求/创意池中带评审结论的征集结果；入选项对应的任务、skill 或开源立项；激励发放记录待优化90
OPS-22社区冷启动内容填充与汇报演示准备OPC/智能涌现/开源聚变社区或官网上线初期板块为空，或领导演示、向主管政府部门汇报在即，需要批量准备种子内容（帖子、评论、活动、政策、Agent 样例）时启动主责——社区运营（当前：陈梦琪·推断待确认）；协同——内容生产（当前：李玄冰·推断待确认）、接口与脚本研发（当前：葛家和、吴世豪·推断待确认）、文案（当前：王皓南·推断待确认）、技术方向与 AI 预审（当前：丁震宇·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 按节点倒排计划 → ② 书面确定真实性边界与质量线 → ③ 采集真实内容 → ④ 生成并标注种子内容 → ⑤ AI 预审 + 人工抽检 → ⑥ 经接口上线 → ⑦ 演示前走查 → ⑧ 节点后回收或转正节点前 2 个工作日完成填充并走查的社区/官网内容；种子内容台账（来源、标注、账号、回收计划）待新建128
OPS-23社区内容与入驻信息审核OPC/智能涌现/开源聚变社区中用户发帖、评论、改名、自定义标签、发布智能体/共创需求/资讯，以及入驻厂商提交资料，进入审核队列需要合规审核与准入判定时启动主责——社区内容审核岗（当前：陈梦琪·推断待确认）；协同——社区研发（当前：裴建武·推断待确认）、配置与第三方审核接入（当前：葛家和、吴世豪·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、厂商对接（当前：杨朋伟、谢昕璟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 内容提交 → ② 机器初筛（敏感词库 + 语义审核，只拒不放）→ ③ 推送待审队列 → ④ 值班人工复核 → ⑤ 通过/拒绝并记录原因与审核人 → ⑥ 举报申诉处置 → ⑦ 厂商准入预审与终审 → ⑧ 每周迭代规则与词库在时限内处理完毕、有审核人和理由记录的审核单；入驻厂商的准入结论；版本化的审核规则与敏感词库待优化300
OPS-24会员端活动上新、权益与积分配置合作俱乐部有新活动（节日、新赛季）需在会员端上新或换图，或要求增删会员权益、改兑换客服、上架积分商城商品、批量给老板加积分，以及策划共创/星耀计划等会员活动时启动主责——会员端产品经理（当前：陈雁·推断待确认）；协同——配置执行（当前：丁震宇·推断待确认）、后端（当前：王子明·推断待确认）、前端（当前：魏小东·推断待确认）、活动策划（当前：宫经喜·推断待确认）、俱乐部方运营对接人（外部）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 机器人卡片提报 → ② 产品经理确认边界与素材 → ③ 写入变更台账并建任务 → ④ 配置执行 → ⑤ 提报人验收 → ⑥ 卡片状态回写 → ⑦ 月度复盘按截止时间上线并验收的活动页、权益、商城或积分变更；变更台账记录“原值—新值”、操作人和验收人待优化240
OPS-25平台罚款申诉审核陪玩或俱乐部在跃玩管理端对平台罚款提交申诉，需要平台侧在时限内审核并反馈结果时启动主责——平台运营审核岗（当前：待指定）；协同——跃竞前端研发（当前：陈真炎·推断待确认）、跃竞后端研发（当前：待指定）、财务（涉及退罚款时）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 申诉提交触发通知 → ② 审核岗认领 → ③ 核对罚款依据与申诉材料 → ④ 作出维持/撤销/部分撤销决定 → ⑤ 执行退款或解除处罚 → ⑥ 反馈申诉方 → ⑦ 登记归档有审核结论、处理记录和反馈记录的申诉单；如撤销罚款，对应金额已退回或处罚已解除待新建80
OPS-26运营平台账号与登录验证管理运营人员登录、换设备、实名/人脸认证或新开抖音、小红书、微信（公众号/视频号）等公司运营账号，需要验证码或实名主体配合时启动；同时覆盖账号登记与人员交接主责——运营账号管理员（当前：李宣昊·推断待确认）；协同——实名手机号持有人（当前：待指定）、IT/信息安全（当前：待指定）、品牌（当前：待指定）；兜底——运营负责人（当前：待指定）① 账号登记入台账 → ② 绑定方式整改（企业认证/共享号码） → ③ 设验证码接收值班 → ④ 发起登录/认证申请 → ⑤ 验证码按安全渠道转达 → ⑥ 人脸/实名认证预约 → ⑦ 人员变动时交接与改绑一份完整的公司运营账号台账（主体、绑定号码、管理员、备份人）；每次登录/认证在约定时限内完成，且验证码不在聊天中明文留存待新建108
OPS-28运营资料汇总与岗位交接运营新人（含实习生）入职，或运营人员转岗、离职时，需要把群运营思路、运营流程、对外资料、用户调研成果统一交接给接手人主责——产品总监（当前：杨萌·推断待确认）；协同——运营文档维护人（当前：待指定，维护流程与群运营思路文档）、人事（当前：待指定）；兜底——运营负责人（当前：待指定）① 维护统一的运营知识库目录 → ② 按岗位整理“入门包” → ③ 入职前准备交接清单与权限 → ④ 入职当周当面讲解 → ⑤ 接收人按清单自学并完成入门任务 → ⑥ 双方核对签收 → ⑦ 交接后更新文档一份按岗位组织的运营入门包（知识库目录 + 交接清单 + 入门任务），以及双方确认的交接记录待优化36
OPS-29用户个人信息权利请求与账号注销处理产品用户（C 端或企业成员）提出查询、复制、更正、删除个人信息、撤回同意或注销账号，或应用商店/监管要求提供注销能力时启动主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、研发后台负责人（当前：待指定）、客服（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 统一受理 → ② 身份核验 → ③ 请求分类 → ④ 注销前检查与告知 → ⑤ 执行删除/匿名化 → ⑥ 答复用户 → ⑦ 留痕 → ⑧ 季度统计自查按时答复的请求处理单、执行记录，季度统计与自查报告待新建80
OPS-30营销权益防刷与异常账号风控处置新人注册福利、邀请码、代金券、试用额度、卡密、校园大使分润、红包类活动上线前后，需防批量注册、刷邀请、刷券、额度异常消耗与套现时启动主责——用户运营专员（当前：待指定）；协同——研发后台负责人（当前：待指定）、财务（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 上线前风控评审 → ② 配置监控告警 → ③ 每日巡检 → ④ 异常判定 → ⑤ 冻结/封停/回收 → ⑥ 用户申诉 → ⑦ 规则调整复盘 → ⑧ 月度损失统计活动风控评审记录、异常处置清单、月度权益损失统计待新建180
OPS-31用户举报、消费投诉与监管协查响应用户举报违法违规内容或账号、消费者通过监管平台投诉被转办、公安/网信等部门来函调取数据或要求协查、应用商店发出下架警告时启动主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、客服（当前：待指定）、研发后台负责人（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）① 统一入口登记 → ② 分类 → ③ 内容举报处置 → ④ 消费投诉核实答复 → ⑤ 监管来函核验 → ⑥ 最小化提供与整改 → ⑦ 台账归档 → ⑧ 季度复盘举报/投诉/来函台账、处理与答复记录、调证交付记录、整改记录待新建120
OPS-01新站点/分站上线运营配置待新建推断96

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：新开对外可注册、可付费的分站（Sorux 模态版、code.leapinfra.cn 编码站、MerCode 等），或现有分站改名、换支付渠道、改站内币时，完成从命名到试付验收的上线配置
  • 负责人：主责——站点配置工程师（当前：宋祺睿·推断待确认）；协同——站点与账号拥有者（当前：丁震宇·推断待确认）、测试（当前：王皓南·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 上线立项单（命名/域名/主体）→ ② 开管理员账号与收件邮箱 → ③ 站点基础配置 → ④ 支付渠道配置与资金账户核对 → ⑤ 币种/计费文案法务审核 → ⑥ 测试账户试付与全链路验收 → ⑦ 上线检查表签核后发布并登记
  • 交付结果：通过上线检查表签核、试付成功的分站，以及一条站点登记记录（域名、主体、支付渠道、邮箱、负责人、上线日期）
  • 状态依据：（推断）没有上线检查表，配置项靠临时想起；分站上线过程中容易出现邮箱反复确认、站点命名未定、试付时才发现支付账户余额不足、文案合规提醒在配置完成后才提出等事后补救

1. 场景判定

  • 触发条件：决定新开对外分站或白标站点；现有分站要改名、切换支付渠道、改站内币名称或计价
  • 判断问题：这是不是一个外部用户能注册、能付钱的独立站点？是否涉及收款或站内币？如果两者都不涉及，只是内部 Demo，不走本流程
  • 不归本流程管：域名选购与 ICP 备案 → 请走 X-SEC-20（域名购买与 ICP/算法备案、主体迁移）；支付通道选型与商户进件 → 请走 FIN-15；模型上架与定价 → 请走 OPS-02 / RND-69；网关部署与升级 → 请走 RND-74；内部 Demo/静态页部署 → 请走 RND-62

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
站点配置工程师 后台配置站点、支付、邮箱，按检查表自检 R 站点配置工程师（当前：宋祺睿·推断待确认）
站点与账号拥有者 立项、定命名、发管理员账号、签核上线 A CTO（当前：丁震宇·推断待确认）
测试 用测试账户试付、走注册到消费全链路 R（验收） 测试（当前：王皓南·推断待确认）
财务 确认收款主体、支付账户余额/预存金额 C 财务（当前：待指定）
法务 审核站内币、充值、退款相关文案 C 法务（当前：待指定）
客服/运营 接收上线通知，准备客服入口 I 运营（当前：待指定）

3. 办之前请准备

  • 站点名称（中英文）及与现有品牌是否冲突的确认结论
  • 域名、备案状态、HTTPS 证书
  • 归属主体与收款主体、支付渠道商户号
  • 支付账户余额或预存要求（渠道是否要求账户有余额才能出款/退款）
  • 收件/客服邮箱名称（如 xxx-support）
  • 站内币名称、充值说明、退款说明文案草稿
  • 测试账户与试付用的小额测试订单
  • 帮助文档与客服入口链接

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写分站上线立项单：名称、域名、主体、支付渠道、上线日期 站点拥有者 计划上线日前 ≥ 7 个工作日 飞书表单 立项单 🔧飞书固化
2 开管理员账号、收件邮箱，一次性交给配置人 站点拥有者 立项后 1 个工作日内 管理后台、企业邮箱 账号与邮箱清单 🔧+👤
3 配置站点名称、Logo、注册与登录、客服入口 站点配置工程师 收到账号后 2 个工作日内 管理后台 站点基础配置 👤人工判断
4 配置支付渠道；财务确认收款主体与账户余额 站点配置工程师、财务 步骤 3 完成后 1 个工作日内 支付渠道后台 支付配置截图、余额确认 🔧+👤
5 站内币、充值、退款文案提交法务审核（不得带货币暗示） 站点配置工程师、法务 法务 2 个工作日内回复 飞书文档评论 审定文案 👤人工判断
6 用测试账户小额试付，跑注册→充值→消费→退款全链路 测试 步骤 4、5 完成后 1 个工作日内 测试账户 验收记录 🔧+🤖
7 按上线检查表逐项打勾，拥有者签核后开放 站点配置工程师、站点拥有者 上线前 1 个工作日 飞书多维表格 已签核检查表 🔧飞书固化
8 登记站点台账，在运营与客服群发上线通知 站点配置工程师 上线当天 多维表格、飞书群 站点登记、上线通知 🔧飞书固化

5. 交付物与模板

  • 交付物：分站上线立项单、已签核上线检查表、试付验收记录、站点台账条目、上线通知
  • 建议模板/表单：
    • 分站上线检查表字段：站点名、域名、证书到期日、归属主体、收款主体、支付渠道、支付账户余额是否充足、收件邮箱、客服入口、站内币名称、文案审核人与日期、试付结果、退款验证结果、签核人、上线日期
    • 站点台账字段：站点名、域名、用途（中转/编码/白标）、管理员、支付渠道、邮箱、负责人、状态（筹备/上线/下线）

6. 异常与升级

  • 试付报错、支付账户余额不足 → 暂停开放支付，财务补足余额后重测 → 升级 CTO（当天）
  • 站点命名未定 → 暂停对外配置，只做内部配置 → 升级 CTO，按 BRD-01 定名（2 个工作日内）
  • 文案法务未通过 → 不得上线，改稿后重审 → 法务当天回复修改意见
  • 上线后用户付款失败或重复扣款 → 关闭支付入口，按 RND-75 处理 → 升级 CTO 与财务（30 分钟内）
  • 需要新邮箱但拥有者不在 → 由兜底人代开 → 1 个工作日内

7. 衡量指标

  • 上线一次通过率 = 检查表首次签核即上线的站点数 / 新上线站点数，目标 ≥ 90%
  • 上线后 7 天内配置类返工次数，目标 ≤ 1 次/站点
  • 试付覆盖率 = 上线前完成试付与退款验证的站点占比，目标 100%
  • 立项到上线周期 = 立项单提交到对外开放的工作日，目标 ≤ 7 个工作日

8. 低效诊断

  • 邮箱、管理员账号在配置过程中逐项索取，配置被打断多次｜依据：（推断）
  • 站点命名未在立项时定下，配置中途更名｜依据：（推断）
  • 支付渠道配置后才做实付测试，才发现资金账户余额不足｜依据：（推断）
  • 站内币文案合规检查放在配置之后，需要返工｜依据：（推断）

9. 分支变体

  • Sorux 模态版：沿用 Sorux 后台，重点核对站点名称与站内币文案
  • code.leapinfra.cn 编码分站：需单独收件邮箱（support 类）和体验券配置，体验券走 OPS-07
  • MerCode 品牌站：命名需与品牌确认，域名与备案先走 X-SEC-20

10. 待确认问题

  • 分站上线的签核人是否固定为 CTO？还是按产品线由产品负责人签核？
  • 站点配置是否固定由一人负责，是否需要备岗？
  • 支付渠道余额由谁监控？是否并入 FIN-03 的余额预警？
  • 站内币文案是否已有法务认可的标准表述可复用？
  • 是否需要建立统一的分站台账，现有分站有几个、谁在维护？
OPS-02模型上线与定价规则待新建推断72

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：LeapOne 新上线模型、调整收费、开放充值、赞助比赛或活动需要临时开充值/发代金券时，按统一规则核对成本、定价并开放
  • 负责人：主责——LeapOne 运营负责人（当前：李凯·推断待确认）；协同——LeapOne 研发负责人（当前：黄振锋·推断待确认）、LeapOne 产品负责人（当前：杨萌·推断待确认）、成本价提供人（当前：闫登辉·推断待确认）、统一支付研发（当前：陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 运营提出上线/调价清单 → ② 研发确认上游渠道与可用性 → ③ 取 API 成本价 → ④ 按毛利底线定价并自动校验 → ⑤ 审批 → ⑥ 配置上线并核验扣费 → ⑦ 充值/代金券安排 → ⑧ 月度毛利与对账复核
  • 交付结果：经审批的模型定价表（含成本价、售价、毛利率），已配置上线并核验的模型与价格，以及充值/代金券发放记录
  • 状态依据：（推断）上线与定价章程尚未成文；毛利底线缺少书面规则；定价、充值、赠送额度分属不同环节，负责人未明确

1. 场景判定

  • 触发条件：LeapOne 要新上线模型；上游成本变化需调价；需要开放充值；活动或赞助比赛需要临时开充值或发代金券
  • 判断问题：本次变化是否影响 LeapOne 对外售价、充值入口或赠送额度？如果只是内部测试用模型，不走本流程
  • 不归本流程管：LeapCore/aiapi/NewAPI 通用倍率与成本价配置 → 请走 RND-69；新模型技术接入与连通性验证 → 请走 RND-67；企业客户报价 → 请走 SAL-18 / SAL-19；内部试用额度与兑换券 → 请走 OPS-07；支付通道选型 → 请走 FIN-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
LeapOne 运营负责人 选模型、提定价方案、安排充值与代金券 R 运营负责人（当前：李凯·推断待确认）
LeapOne 研发负责人 拟上线与定价章程、确认上游渠道、配置上线 R（技术）/C 研发负责人（当前：黄振锋·推断待确认）
LeapOne 产品负责人 审核定价与用户体验，审批上线 A 产品负责人（当前：杨萌·推断待确认）
成本价提供人 提供各模型 API 成本价及有效期 C 成本价提供人（当前：闫登辉·推断待确认）
统一支付研发 充值入口接统一支付（mercpay） R（支付） 支付研发（当前：陈锦杰·推断待确认）
财务 毛利复核、充值对账 C 财务（当前：待指定）
CTO 低于毛利底线的特批 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 拟上线/调价模型清单（模型名、渠道、上线日期、目标用户）
  • 上游渠道清单：主渠道与补充渠道、各自成本价、折扣到期日
  • 现行售价表与竞品价格（如有）
  • 充值开放方式：是否长期开放、活动临时开放的起止时间
  • 代金券/赠送额度方案：面额、数量、发放对象、预算上限
  • 支付入口是否已接统一支付

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交模型上线/调价申请（模型、渠道、理由、上线日） 运营负责人 上线日前 ≥ 5 个工作日 飞书表单 上线申请 🔧飞书固化
2 确认上游渠道可用性、稳定性与备用渠道 研发负责人 申请后 2 个工作日内 网关后台 渠道确认 👤人工判断
3 提供并登记 API 成本价与有效期 成本价提供人 申请后 1 个工作日内 定价多维表格 成本价记录 🔧飞书固化
4 按毛利底线（[阈值待财务确认]）定价，表格自动校验并标红不达标项 运营负责人 收到成本价后 1 个工作日内 定价多维表格 定价表 🔧+🤖
5 审批定价；低于毛利底线需 CTO 特批并写明期限 产品负责人、CTO 1 个工作日内 飞书审批 审批记录 🔧飞书固化
6 配置模型与价格上线，用测试账号实扣核验 研发负责人 审批后 1 个工作日内 网关后台 核验截图 🔧+👤
7 需开放充值时确认已接统一支付，配置充值类型字段 支付研发 上线前 1 个工作日 统一支付后台 充值入口 🔧+👤
8 安排代金券/赠送额度，按 OPS-07 登记发放 运营负责人 活动开始前 1 个工作日 发券台账 发放记录 🔧飞书固化
9 每月核对实际毛利、上游账单与充值流水 财务、运营负责人 每月 5 日前 账单、定价表 月度毛利复核 🤖自动化

5. 交付物与模板

  • 交付物：上线与定价章程（一次性制定后长期维护）、模型定价表、审批记录、充值与代金券发放记录、月度毛利复核表
  • 建议模板/表单：
    • 定价表字段：模型名、上游渠道、成本价（输入/输出）、成本有效期、售价、毛利率（自动计算）、是否达标（自动）、特批人、特批期限、上线日期、状态
    • 代金券安排字段：活动名、面额、数量、对象、预算上限、发放人、起止日期

6. 异常与升级

  • 产品负责人为定价与上线的唯一审批人（A）；CTO 作为 A（升级）的条件：定价低于毛利底线需特批（须写明特批期限），或上游成本变化导致在售模型整体低于毛利底线
  • 定价低于毛利底线 → 退回重定或申请特批 → 升级 CTO（1 个工作日内）
  • 上游成本上涨或折扣到期 → 3 个工作日内重算售价并重走步骤 4～6 → 升级产品负责人
  • 上线后扣费与定价不一致 → 立即下线该模型或暂停充值，按 RND-70 核对 → 升级研发负责人（当天）
  • 活动临时开充值未接统一支付 → 不得开放 → 升级支付研发（当天）
  • 赠送额度责任人不明 → 由运营负责人认领 → 升级兜底人

7. 衡量指标

  • 毛利达标率 = 售价满足毛利底线的在售模型数 / 在售模型数，目标 100%（特批除外）
  • 上线周期 = 申请到上线核验完成的工作日，目标 ≤ 5 个工作日
  • 价格配置差错次数 = 上线后发现售价/扣费错误的次数，目标 0
  • 月度毛利复核按时完成率，目标 100%

8. 低效诊断

  • 上线与定价章程长期处于"待拟"，规则靠口头约定｜依据：（推断）
  • 定价、充值、赠送额度分属不同环节但未指定负责人，负责人长期不明确｜依据：（推断）
  • 成本价需临时向他人索取，无统一成本台账｜依据：（推断）

9. 分支变体

  • 常规上线：完整走步骤 1～9
  • 上游调价：从步骤 3 开始，重算后走审批
  • 赞助比赛/活动临时开充值：步骤 7、8 为重点，写明关闭时间，活动结束后关闭入口
  • 代金券：额度标准和登记走 OPS-07

10. 待确认问题

  • LeapOne 运营负责人、产品负责人是否仍为当前人员？定价最终审批人是谁？
  • 毛利底线阈值定为多少（[阈值待财务确认]）？是否适用于所有模型？引流模型是否允许例外，例外由谁批？
  • 成本价应由谁提供并维护？是否改为研发从上游账单直接取？
  • 上线与定价章程由谁在何时前完成？
  • 充值类型字段（工单 LEAP-1754）是否已上线？
OPS-03帮助中心、使用手册与更新日志维护待优化144

状态：待优化｜证据：有证据（卡片 8 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：产品每次迭代上线、hotfix、新功能开放或内测/公测时，同步更新帮助中心、使用手册、FAQ、更新日志、教学视频、官网与客服入口，并自检不影响安装包下载
  • 负责人：主责——帮助中心与手册负责人（当前：杨萌·推断待确认）；协同——文档运营（当前：杨黔昆·推断待确认）、发布部署（当前：宋祺睿·推断待确认）、客户端前端（当前：葛家和·推断待确认）、产品经理（当前：陈震·推断待确认）、跃竞线产品负责人（当前：徐莉·推断待确认）、跃竞线文档更新（当前：陈雁·推断待确认）、LeapPPT 运营负责人（当前：李凯·推断待确认）、视频制作（当前：魏宗浩·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发版清单触发"文档同步"任务 → ② 研发提供变更汇总 → ③ AI 起草更新日志/手册改动 → ④ 产品审核内容 → ⑤ preview 环境自检 → ⑥ PR 合并部署 prod → ⑦ 同步客服知识库与群通知 → ⑧ 归档到飞书知识库
  • 交付结果：已上线的帮助中心/手册/FAQ 更新、与版本号对应的更新日志、同步后的客服知识库，必要时附教学视频
  • 状态依据：已有帮助中心仓库、EdgeOne 分支部署和飞书知识库；但更新靠负责人提醒（"记得更新一下"），变更汇总无固定来源，部署职责反复询问，hotfix 后帮助中心安装包未同步，客户端先于文档上线

1. 场景判定

  • 触发条件：迭代封版/上线、hotfix 发布、新功能开放、内测/公测开启、用户反复问同一操作问题
  • 典型说法：「我们的新功能，记得更新一下」「谁部署下帮助文档」「我在写更新日志怕有遗漏」「我的更新会不会影响别的流程」「写手册吧，用户反问应该能触发」
  • 判断问题：本次变化是否会改变用户看到的操作、入口或下载？如果会，必须在上线当天同步文档
  • 不归本流程管：版本发布本身 → 请走 RND-51；发版/停机对客通知 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）/ X-CS-15；产品官网与下载页建设 → 请走 BRD-04；宣传视频对外投放 → 请走 BRD-11；客户交付现场手册 → 请走 X-DLV-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
帮助中心与手册负责人 定结构与更新节奏，审核内容，对结果负责 A 产品总监（当前：杨萌·推断待确认）
文档运营 起草更新日志、截图、整理知识库 R 文档运营（当前：杨黔昆·推断待确认）
产品经理 补充安装、操作等指引需求 R 产品经理（当前：陈震·推断待确认）
发布部署 维护 main/preview/prod 分支、PR 部署、分支保护 R（部署） 后端/运维（当前：宋祺睿·推断待确认）
客户端前端 安装指引、帮助入口、安装包链接正确性 C 客户端前端（当前：葛家和·推断待确认）
研发负责人 提供每版变更汇总（工单/PR） C 研发负责人（当前：待指定）
跃竞线负责人/文档 小程序更新日志与 wiki 手册同步 R（跃竞） 跃竞产品负责人（当前：徐莉·推断待确认）、文档（当前：陈雁·推断待确认）
LeapPPT 运营 官网、帮助站、AI 客服知识库 R（LeapPPT） 运营负责人（当前：李凯·推断待确认）
视频制作 教学/发布视频 R（视频） 研发（当前：魏宗浩·推断待确认）
客服 接收更新、同步话术 I 客服（当前：待指定）

3. 办之前请准备

  • 版本号（客户端与服务端版本号对齐后的对外版本号）
  • 本版工单/PR 列表或机器生成的变更汇总
  • 新功能截图、录屏
  • 受影响的手册章节与 FAQ 条目
  • 安装包下载链接（确认正式服、确认已随 hotfix 更新）
  • 是否需要教学/发布视频
  • 对外渠道版本（终端客户版 / 渠道伙伴有 logo、无 logo 版）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发版清单自动生成"文档同步"任务，指派文档运营 研发负责人 封版当天 飞书任务/机器人 文档同步任务 🔧飞书固化
2 从工单、PR、提交记录导出本版变更汇总 研发负责人 封版后 1 个工作日内 Gitea + 脚本 变更汇总 🤖自动化
3 AI 按"新增/优化/修复"结构起草更新日志与手册改动 文档运营 拿到汇总后 1 个工作日内 AI + 帮助中心仓库 草稿 PR 🤖自动化
4 审核内容口径、补安装与操作指引 帮助中心负责人、产品经理 草稿后 1 个工作日内 PR 评审 审定内容 👤人工判断
5 preview 环境自检：链接、安装包版本、旧客户端访问帮助入口 文档运营、客户端前端 合并前 preview 环境 + 自检脚本 自检记录 🔧+🤖
6 PR 合并到 prod 或手动触发部署 发布部署 版本上线当天 EdgeOne 线上帮助中心 🔧飞书固化
7 同步客服知识库、AI 客服 FAQ，在群内发更新说明 文档运营、客服 上线当天 客服知识库、飞书群 同步回执 🔧+🤖
8 新功能需要视频时，用视频生成 skill 产出教学/发布视频 视频制作 上线后 3 个工作日内 视频 skill 视频文件 🤖自动化
9 文档、视频归档到飞书知识库对应版本目录 文档运营 上线后 2 个工作日内 飞书知识库 归档链接 🔧飞书固化

5. 交付物与模板

  • 交付物：版本更新日志、手册/FAQ 更新、自检记录、客服同步回执、教学/发布视频（按需）
  • 建议模板/表单：
    • 更新日志结构：版本号、发布日期、新增、优化、修复、已知问题、升级方式、推荐浏览器/系统要求
    • 文档同步检查项：手册章节、FAQ、安装指引、下载链接、帮助入口、客服知识库、渠道版（有/无 logo）
    • 自检清单：链接可访问、安装包为最新正式版、旧版客户端可打开帮助中心、内容与当前 UI 一致

6. 异常与升级

  • 研发未在 1 个工作日内给出变更汇总 → 文档运营从工单系统按"已关闭"自取 → 升级研发负责人
  • hotfix 后帮助中心安装包未更新 → 当天替换链接并在群内更正 → 升级发布部署（2 小时内）
  • 部署后影响 OTA/下载 → 立即回滚到上一版本 → 升级 CTO（30 分钟内）
  • 客户端先于文档上线 → 先发临时 FAQ，2 个工作日内补齐手册
  • 非标品（如定制版）手册归属不明 → 由帮助中心负责人指定负责人（1 个工作日内）

7. 衡量指标

  • 文档同步及时率 = 上线当天完成文档更新的版本数 / 上线版本数，目标 ≥ 90%
  • 更新日志遗漏数 = 上线后发现漏记的变更条数，目标 ≤ 1 条/版本
  • 帮助中心发布事故数（影响下载/OTA），目标 0
  • 同类操作问题在群内重复解释次数（每月），目标逐月下降

8. 低效诊断

  • 帮助文档站谁来部署反复询问，迁入组织、开域名、部署分散在不同环节｜依据：「Leap产研测」2026-05
  • 更新日志依赖个人手工整理，迭代结束后需追问"这个迭代更新了什么"｜依据：「工程咨询产研」2026-01、「Leap产研测」2026-05
  • 客户端版本与后端版本不对齐，更新日志难对应 hotfix 工单｜依据：「Leap产研测」2026-08
  • 帮助中心缺安装指引，客户端先于文档上线｜依据：「Leap产研测」2026-08
  • hotfix 后帮助中心安装包未同步，内容更新缺自检｜依据：「Leap产研测」2026-09
  • 新功能上线后需负责人提醒才更新 wiki 与手册｜依据：「跃竞市场部」2026-02、「跃竞市场部」2026-03
  • 帮助文档与产品功能不同步，客服入口无人值守｜依据：「LeapPPT」2026-05
  • 演示视频版本多、分散，靠手工提示词制作｜依据：「Leap产研测」2026-05、「Leap产研测」2026-09

9. 分支变体

  • LeapAll/LeapCore：帮助中心 help.leapall.cn，main/preview/prod 三分支对应 EdgeOne 环境；LeapCore 内置帮助入口仅企业版
  • 字字可研/工程咨询：飞书知识库手册，分终端客户版与渠道伙伴版（有/无 logo）
  • 跃竞小程序：每周迭代后发更新日志，运营/客服在 wiki 同步并回复"已同步"
  • LeapPPT：官网、帮助站经 Gitea Action 构建，同步 AI 客服知识库，人工 fallback
  • 定制版（如 TGWork）：单独手册，由帮助中心负责人指定维护人
  • 纯内容更新 vs 涉及接口变更：后者必须走 preview 自检并通知客户端前端

10. 待确认问题

  • 帮助中心与手册的唯一负责人是否为产品总监？各产品线是否分设维护人？
  • 变更汇总由谁提供：研发负责人、发布负责人还是机器自动生成？
  • "上线当天同步文档"是否可行？hotfix 是否放宽到 1 个工作日？
  • 对外版本号以 OTA 版本号为准是否已定？
  • 教学/发布视频是否每个新功能都要做？谁验收？
OPS-05全员使用自研产品推动与内测反馈待优化135

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：自研产品（LeapAll、LeapPPT、LeapCore、许愿机及各类小工具）内部上线或内测时，推动全员安装使用、邀请非研发同事试用，统计用量、督促落后部门，并把反馈收束到统一入口
  • 负责人：主责——内部推广负责人（当前：杨萌·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、反馈收口人（当前：杨黔昆·推断待确认）、版本发布（当前：岳阳·推断待确认）、额度与链接（当前：宋祺睿、张东郅·推断待确认）、各部门负责人（当前：徐莉、赵雪冰、李凯 等·推断待确认）、人事（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发布内部使用公告 → ② 部门负责人确认责任 → ③ 当天安装与首次真实场景使用 → ④ 每周用量数据公示 → ⑤ 未使用名单自动提醒 → ⑥ 反馈统一入表、分派 → ⑦ 场景提交与月度考核 → ⑧ 周报复盘
  • 交付结果：全员安装与使用记录、每周使用数据公示、反馈池（含处理状态）、各部门月度场景提交记录、积分/奖惩依据
  • 状态依据：已有《LeapAll 内测推广·部门负责人工作机制》、反馈表单和积分体系；但推动仍靠多次群内催办和人工拉名单，用量数据受新旧包版本影响失真，反馈入口分散在群、私信、表单三处，许愿机等小工具出现"谁来写通知"无人认领

1. 场景判定

  • 触发条件：自研产品对内开放；管理层要求全员使用并统计用量；新工具需要非研发同事试用；每周用量公示日
  • 典型说法：「自己的 AI 产品，自己一定要用起来」「记得装 LeapCore」「每个负责人要督促使用」「反馈统一收束到某某这里」「谁来写一个内部推广邀请通知」
  • 判断问题：目标是"让内部人用起来并给反馈"，还是"让外部用户知道"？前者走本流程，后者走 X-PRD-35
  • 不归本流程管：对外公告与发版通知 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）；内部额度与券码发放 → 请走 OPS-07；每月 AI 补贴充值核对 → 请走 OPS-06；反馈转工单与分诊 → 请走 RND-01；内部 AI 场景征集评审 → 请走 OPS-21；内部机器人部署 → 请走 RND-81

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内部推广负责人 发公告、拉数据、公示、组织反馈 R 产品总监（当前：杨萌·推断待确认）
CEO 定使用要求与奖惩规则 A CEO（当前：邴龙志·推断待确认）
CTO 新工具内部推广的发起与入口权限 C CTO（当前：丁震宇·推断待确认）
各部门负责人 本部门使用第一责任人，提交场景 R（部门） 部门负责人（当前：徐莉、赵雪冰、李凯 等·推断待确认）
反馈收口人 反馈收束、去重、分派 R（反馈） 产品/运营（当前：杨黔昆·推断待确认）
版本发布 安装包与 OTA，保证统计口径版本一致 C 客户端研发（当前：岳阳·推断待确认）
额度与链接 正式链接、内部额度开通 C 后端（当前：宋祺睿·推断待确认）、测试（当前：张东郅·推断待确认）
人事 积分、补贴奖惩落地，新人入职清单 C 人事负责人（当前：黄莹·推断待确认）
全体员工 安装、使用、反馈 I 全员

3. 办之前请准备

  • 正式环境下载链接/入口（发前核对不是测试域名）、企业连接地址、外网使用说明（飞连）
  • 账号是否已预注册、默认额度或额度申请入口
  • 帮助文档、反馈表单链接（字段含设备、浏览器、版本、截图）
  • 本期使用要求：完成时限、"真实场景使用"定义、防刷说明
  • 奖惩/积分规则与评价标准（使用活跃度、场景贡献）
  • 后台用量数据的取数方式与口径

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板发内部使用公告（入口、账号、额度、帮助、反馈、时限） 内部推广负责人 开放当天 飞书全员群 公告 🔧飞书固化
2 部门负责人在机制文档中确认责任 各部门负责人 公告后 1 个工作日内 飞书文档 确认记录 🔧飞书固化
3 员工安装并完成至少一次真实工作场景使用 全员 公告当天 产品 使用记录 👤人工判断
4 后台用量自动汇总到多维表格，按部门统计 内部推广负责人 每周五 18:00 前 后台 + 多维表格 用量周报 🤖自动化
5 未安装/未使用名单由机器人私信提醒，并抄送部门负责人 内部推广负责人 每周一 飞书机器人 提醒记录 🔧+🤖
6 反馈统一填表，收口人每日去重、分类并转工单 反馈收口人 1 个工作日内 反馈表单、工单系统 反馈池 🔧+🤖
7 部门负责人每月提交至少 1 个达标场景 各部门负责人 每月最后一个工作日前 场景多维表格 场景记录 🔧飞书固化
8 每周公示使用数据与有效反馈，月度汇总交人事计入积分/奖惩 内部推广负责人、人事 每周五；每月 5 日前 飞书群、多维表格 公示、奖惩依据 🔧+🤖
9 小工具邀请制试用：写邀请通知、开权限、置顶入口说明 工具发起人指定的负责人 上线后 2 个工作日内 飞书群置顶 邀请通知 🔧飞书固化

5. 交付物与模板

  • 交付物：内部使用公告、部门责任确认、每周用量公示、反馈池、月度场景记录、积分/奖惩依据表
  • 建议模板/表单：
    • 内部使用公告字段：产品与版本、入口/下载链接、企业地址、账号说明、额度获取、帮助文档、反馈入口、完成时限、奖惩说明
    • 反馈表单字段：反馈人、产品、版本、设备/系统/浏览器、类型（bug/需求/体验）、描述、截图/录屏、严重程度
    • 用量周报字段：部门、人数、已安装数、活跃人数、有效使用次数、有效反馈数、场景提交数

6. 异常与升级

  • 公告链接发成测试域名 → 30 分钟内更正 → 升级额度与链接负责人
  • 新旧安装包并存导致用量失真 → 统计只取最新版本，强制 OTA → 升级版本发布（1 个工作日内）
  • 部门连续 2 周使用率最低 → 通报部门负责人 → 升级 CEO
  • 工具上线无人认领推广 → 由 CTO 当场指定负责人（当天）
  • 员工无入口/无权限 → 1 个工作日内开通 → 升级额度与链接负责人
  • 出现刷用量 → 剔除异常数据 → 推广负责人判定

7. 衡量指标

  • 安装率 = 已安装人数 / 应安装人数，目标开放后 3 个工作日内 ≥ 95%
  • 周活跃率 = 当周有真实使用记录人数 / 在职人数，目标 ≥ 80%
  • 反馈处理率 = 已分派或关闭的反馈 / 反馈总数（每周），目标 ≥ 90%
  • 部门场景达标率 = 每月提交 ≥ 1 个达标场景的部门占比，目标 100%
  • 催办次数 = 群内人工催办次数（每月），目标逐月下降

8. 低效诊断

  • 全员安装要求在群内多次重复提醒，部分成员以为发错群｜依据：「跃迁基座项目交付沟通」2026-06
  • 使用要求、补贴、奖惩口径多次变化，用量是否等于价值存在争议｜依据：「模态集团（全员群）」2026-05、「模态集团（全员群）」2026-06
  • 未使用名单靠人工拉数据、群内公示，新旧包版本导致数据失真｜依据：「【模态】业务负责人」2026-06、「【模态】业务负责人」2026-07
  • 公告中的链接错发为测试域名，多次催"今天内完成"｜依据：「字字可研项目群」2026-05、「字字可研项目群」2026-06
  • 反馈入口分散在群、私信、表单，同一问题多人重复提｜依据：「模态集团（全员群）」2026-01、「模态集团（全员群）」2026-04
  • 新工具推广通知无人认领，入口与权限缺失，上线数周后仍有人问怎么用｜依据：「跃迁基座许愿机」2026-05、「跃迁基座许愿机」2026-06

9. 分支变体

  • LeapAll（C 端助手）：全员优先使用并对比反馈，额度见 OPS-07
  • LeapCore（企业版）：账号预注册，仅内网/飞连可用；部门负责人需在 LeapCore 创建团队空间并上传资料
  • LeapPPT：需券码，券码申请见 OPS-07
  • 趣味测评/小工具（MBTI 类、许愿机）：邀请制，指定专人收反馈，入口说明置顶
  • 对外平台（政府消费券平台）：领取、购买、核销与问卷见 OPS-06
  • 新员工：纳入入职清单，入职当天安装

10. 待确认问题

  • 内部推广主责是否固定为产品总监？各产品线是否分设？
  • 奖惩规则（奖金、扣补贴、积分）是否已成文，由人事还是财务执行？
  • 用量统计的"真实场景使用"如何界定，防刷指标由谁定？
  • 部门资料是迁入 LeapCore 团队空间还是保留原处？
  • 反馈收口人是否固定一人并设备岗？
OPS-06员工 AI 补贴与内部余额月度充值核对待优化144

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：每月 AI 补贴发放日，通知员工用补贴充值 LeapAll、统一为全员补充 LeapCore 内部余额，次日拉后台名单提醒未完成者，月底核对并输出补贴保留/取消依据；含政府消费券领取、购买与核销
  • 负责人：主责——内部余额管理员（当前：杨萌·推断待确认）；协同——LeapAll 服务端（当前：邓乾·推断待确认）、LeapCore 后端（当前：宋祺睿·推断待确认）、人事（当前：黄莹·推断待确认）、券与活动（当前：葛家和、胡橙橙·推断待确认）、财务（当前：待指定）、计费口径（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 补贴到账后发充值通知 → ② LeapCore 全员余额批量补充 → ③ 员工自行充值 LeapAll/核销券码 → ④ 次日按飞书手机号匹配后台数据 → ⑤ 机器人提醒未完成者 → ⑥ 月底核对、例外处理 → ⑦ 输出名单交人事/财务 → ⑧ 记录留档
  • 交付结果：月度充值核对表（人员、账号、手机号、LeapAll 充值、LeapCore 补充、券码核销、例外说明），交人事/财务的补贴处理名单，批量充值审计记录
  • 状态依据：充值规则和 SOP 文档已有，每月有固定节奏；但 LeapCore 余额由个人指挥 Agent 逐个充值、无审批无记录；手机号与账号不一致导致统计错误，充到测试服需迁移；券使用规则靠群内猜测，催办约 5 次/月

1. 场景判定

  • 触发条件：每月 AI 补贴到账；每月 LeapCore 内部余额补充日；政府消费券批次下发；月底补贴核对
  • 典型说法：「本月 AI 补贴已发放，大家可以充值 LeapAll 了」「请大家今天完成本月 LeapAll 的充值目标」「每个月给所有人 LeapCore 余额加 300」「请大家今天内完成券码的购买和核销」
  • 判断问题：这是全员按月例行的充值/核对吗？如果是个人临时要额度，走 OPS-07
  • 不归本流程管：补贴标准制定与核发、超额报销 → 请走 FIN-10；个人/项目临时额度与券码 → 请走 OPS-07；客户充值到账 → 请走 FIN-17；政府平台商品上架与消费券推广 → 请走 MKT-13；全员使用推动 → 请走 OPS-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内部余额管理员 发通知、执行批量补充、拉数据、核对、出名单 R 产品总监（当前：杨萌·推断待确认）
管理层 定补贴额度、充值要求、取消补贴规则 A 董事会/管理层（当前：待指定）
LeapAll 服务端 后台数据导出、账号迁移（测试服→正式服） R（数据） 服务端研发（当前：邓乾·推断待确认）
LeapCore 后端 批量充值接口/按钮、手机号更新 R（工具） 后端（当前：宋祺睿·推断待确认）
人事 提供以入职表单为准的人员与手机号名单 C 人事负责人（当前：黄莹·推断待确认）
财务 补贴发放与取消执行、内部成本核算 C 财务（当前：待指定）
券与活动 消费券领取指南、问卷 C 研发/运营（当前：葛家和、胡橙橙·推断待确认）
全体员工 按时充值、核销、补正手机号 I 全员

3. 办之前请准备

  • 本月补贴额度、最低充值金额、截止日（管理层规则）
  • 人事提供的在职名单及飞书手机号（以飞书/入职表单为准）
  • LeapAll、LeapCore 后台按手机号导出的充值/余额数据（正式服）
  • 本月消费券批次、购买指南、问卷链接
  • 计费口径说明：内部消耗与商业版价格一致
  • 例外清单：已手动充值、充到测试服、手机号不一致、新入职/离职

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 补贴到账当天，机器人在全员群发充值通知（金额、截止日、正式服入口、券码用法） 内部余额管理员 补贴到账当天 飞书机器人 通知 🔧+🤖
2 生成本月 LeapCore 补充名单，审批后批量充值，自动写回执 内部余额管理员、LeapCore 后端 每月固定日（如 1 日）当天 飞书审批 + 批量接口 批量充值记录 🤖+👤
3 员工自行充值 LeapAll、领取并核销消费券、填问卷 全员 通知当天内 LeapAll、消费券平台 充值/核销记录 👤人工判断
4 次日导出后台数据，按飞书手机号自动匹配人事名单 内部余额管理员、LeapAll 服务端 截止日次日 12:00 前 后台 + 多维表格 匹配结果 🤖自动化
5 机器人私信未完成者；手机号不一致者补正 内部余额管理员 截止日次日 飞书机器人 提醒记录 🔧+🤖
6 处理例外：测试服迁移、已手动充值、新入/离职 LeapAll 服务端、内部余额管理员 3 个工作日内 后台 例外说明 👤人工判断
7 月底最终核对，输出"已完成/未完成/例外"名单 内部余额管理员 每月最后一个工作日 多维表格 月度核对表 🔧飞书固化
8 名单交人事/财务执行补贴保留或取消，结果归档 人事、财务 次月 5 日前 飞书审批 处理结果 🔧飞书固化

5. 交付物与模板

  • 交付物：月度充值通知、LeapCore 批量充值审批与回执、月度充值核对表、补贴处理名单
  • 建议模板/表单：
    • 月度核对表字段：月份、姓名、部门、飞书手机号、LeapAll 账号手机号、是否一致、LeapAll 充值额与时间、环境（正式/测试）、LeapCore 补充额与执行时间、消费券核销状态、问卷是否填写、例外说明、处理结论
    • 补贴规则 FAQ：额度、最低充值、截止日、券码能否叠加/重复领取、实名绑定、过期规则、内部计费口径、LeapCore 是否支持券码

6. 异常与升级

  • 员工手机号与账号不一致 → 员工 1 个工作日内补正，后端更新号码 → 内部余额管理员复核
  • 充到测试服 → 服务端迁移到正式服 → 3 个工作日内完成
  • 批量充值失败或重复 → 停止执行，按回执逐个核对 → 升级 LeapCore 后端（当天）
  • 券码无法使用、抵扣失败 → 汇总后转券与活动负责人，必要时对接平台 → 2 个工作日内答复
  • 员工对补贴取消有异议 → 提供充值记录申诉 → 升级人事与管理层（5 个工作日内）
  • 内部余额管理员不在 → 由兜底人指定备岗执行批量充值

7. 衡量指标

  • 按时充值率 = 截止日前完成充值人数 / 应充值人数，目标 ≥ 95%
  • 名单匹配准确率 = 自动匹配成功人数 / 应核对人数，目标 ≥ 98%
  • LeapCore 批量充值留痕率 = 有审批与回执的批次 / 总批次，目标 100%
  • 人工催办次数（每月），目标 ≤ 1 次全员提醒
  • 核对完成时效 = 截止日到名单交人事/财务的工作日，目标 ≤ 5 个工作日

8. 低效诊断

  • LeapCore 全员余额靠个人指挥 Agent 逐个充值，无审批、无记录，只有一人掌握｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 充值统计按 LeapAll 账号手机号拉取，与飞书手机号不一致导致名单错误｜依据：「模态集团（全员群）」2026-06、「模态集团（全员群）」2026-07
  • 员工充到测试服，需服务端迁移账号｜依据：「模态集团（全员群）」2026-07
  • 消费券核销与充值靠群内逐人点名确认｜依据：「Leap产研测」2026-06
  • 券使用、实名绑定、计费口径无成文说明，群内互相猜测｜依据：「跃迁AI总动员」2026-07

9. 分支变体

  • LeapAll 员工自充：用补贴充值，需达到最低充值额
  • LeapCore 内部余额：公司统一为全员补充，不需员工操作；目前不支持券码充值、个人单独充值
  • 政府消费券：领取、购买、核销后填问卷；已手动充值的可单独说明，计入下月
  • 产研测试额度、客户代充：不走本流程，分别走 RND-47、FIN-17（客户代充需附 CRM 截图）

10. 待确认问题

  • 内部余额管理员是否固定为产品总监？是否需要设备岗？
  • 补贴额度、最低充值、未充值取消补贴的规则是否已成文，由谁发布？
  • LeapCore 批量充值是否需要审批？审批人是谁？批量接口何时可用？
  • 手机号以飞书为准是否全员适用？离职、新入职当月如何处理？
  • 补贴取消由人事还是财务执行？
OPS-07试用额度与兑换券申请、发放与登记待优化300

状态：待优化｜证据：有证据（卡片 11 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：内部员工、天使用户、合作方、媒体、内测客户、活动参赛者需要 LeapAll 额度、LeapPPT 券码、MerCoder 体验券或模态币时，经表单申请、分级审批、自动或人工发放，并在统一台账登记对内外发放记录
  • 负责人：主责——额度与券码管理员（当前：杨萌·推断待确认）；协同——LeapAll 充值经办（当前：邓乾·推断待确认，备岗：张康·推断待确认）、LeapPPT 发券（当前：马漳毓·推断待确认）、表单与自动化（当前：陈晖·推断待确认）、发券接口（当前：黄振锋·推断待确认）、审批人（当前：丁震宇、李凯、李铭熙·推断待确认）、活动额度配置（当前：宋祺睿·推断待确认）、活动测试（当前：张东郅·推断待确认）、活动负责人（当前：陈梦琪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 申请人填表（产品、环境、用途、数量、账号）→ ② 按规则自动放行或分级审批 → ③ 接口自动发放/人工发放 → ④ 发放结果回写并通知申请人 → ⑤ 对外发放登记台账 → ⑥ 活动券上线前测试 → ⑦ 每月统计发放量与成本
  • 交付结果：已到账的额度或券码、含申请-审批-发放-回执的完整记录、对内对外统一发放台账、月度发放统计
  • 状态依据：LeapPPT 发券表单+审批+自动发券已稳定运行，LeapAll 有充值申请 SOP；但 LeapAll 仍由单一经办人手动充值，出现漏发、错发、"点了完成但未充值"；额度标准（20/100/200）反复争论；测试服与正式服券混用；对外发放没有统一台账

1. 场景判定

  • 触发条件：新账号额度为 0；额度用完需加额；需要券码给学生、朋友、媒体、客户试用；合作方开内测；活动、比赛需要批量券或一日券
  • 典型说法：「内测额度要走审批」「谁给我个 2000 的兑换码」「自己填表」「一定要充值之后再点完成流程」「有没有一个地方记录都给谁发了」「我要 500 个券码，每个码 100 积分」
  • 判断问题：是否免费赠送/试用额度？对象是谁、用哪个环境？付费充值、正式席位不走本流程
  • 不归本流程管：每月员工补贴充值 → 请走 OPS-06；客户付费充值到账 → 请走 FIN-17；赠送额度的成本归属与财务口径 → 请走 FIN-16；测试账号与测试数据 → 请走 RND-47；渠道卡密 → 请走 OPS-10；演示账号 → 请走 SAL-13；客户正式额度分配补发 → 请走 X-CS-03 / X-DLV-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
额度与券码管理员 定额度标准、维护台账、月度统计 A 产品总监（当前：杨萌·推断待确认）
审批人 超额、非首次、对外、付费券审批 A（升级） 管理层（当前：丁震宇、李凯、李铭熙·推断待确认）
LeapAll 充值经办 执行充值、确认到账后再点完成 R 服务端研发（当前：邓乾·推断待确认；备岗：张康·推断待确认）
LeapPPT 发券 券批次生成、批量导出 R LeapPPT 研发（当前：马漳毓·推断待确认）
表单与自动化 表单、审批流、自动发券机器人 R（工具） 架构（当前：陈晖·推断待确认）
发券接口 发券接口与新用户/邀请积分规则 C 研发（当前：黄振锋·推断待确认）
活动额度配置/测试 体验券配置与兑换、教程验证 R（活动） 后端（当前：宋祺睿·推断待确认）、测试（当前：张东郅·推断待确认）
活动负责人 活动券需求与发放对象 C 生态组（当前：陈梦琪·推断待确认）
研发负责人 白名单、风险监控、强制更新 C Leap 研发负责人（当前：王皓南·推断待确认）
申请人 填表、核对账号与环境 I 各部门

3. 办之前请准备

  • 产品（LeapAll / LeapPPT / MerCoder / LeapCore）与环境：自用/内测选测试环境，外部用户选正式环境
  • 充值账号（手机号/用户名），确认账号存在于对应环境
  • 用途、对象（内部/学生/合作方/媒体/客户）、外部用户需先入用户群并提供 IM
  • 数量与每张券点数、期望额度
  • 对外发放需提供对象代号与来源（用于台账）
  • 活动券：活动规则、起止时间、单人限额、教程链接

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写额度/券码申请表（产品、环境、账号、用途、数量、点数） 申请人 需要时 飞书表单 申请单 🔧飞书固化
2 规则判定：当日首次且 ≤ 默认额度自动放行；超额、非首次、对外、付费券进入审批 系统 即时 飞书审批 放行/待审 🤖+👤
3 审批（任一审批人通过即可） 审批人 4 个工作小时内 飞书审批 审批结果 👤人工判断
4 审批通过自动调接口发券/充值，回写兑换码、批次 ID、接口状态 系统 即时 多维表格自动化 发放回执 🤖+👤
5 不能自动发放时人工充值，确认后台到账后再点"完成" 充值经办/发券 审批后 1 个工作日内 后台 到账截图 👤人工判断
6 机器人把券码/到账结果私发申请人，不在群内明文贴码 系统 发放后即时 飞书机器人 通知 🔧+🤖
7 对外发放（合作方、媒体、政企用户）登记台账并同步白名单/标签 额度与券码管理员 发放当天 多维表格 台账记录 🔧飞书固化
8 活动/比赛券上线前测试：兑换、用量显示、教程、核销、重复兑换 活动额度配置/测试 活动开始前 2 个工作日 测试账号 测试结论 👤人工判断
9 每月统计发放量、消耗与成本，区分赠券与付费券 额度与券码管理员 每月 5 日前 多维表格 月度统计 🤖自动化

5. 交付物与模板

  • 交付物：申请单、审批记录、发放回执、对内对外统一发放台账、活动券测试结论、月度发放统计
  • 建议模板/表单：
    • 申请表字段：申请人、项目、产品、环境（测试/正式）、具体用途、发放方式（自动/人工）、充值账号、数量、每张点数、对象类型、外部用户 IM、备注
    • 发放台账字段：自增编号（幂等）、对象代号、对象类型、产品、环境、额度/券数、批次 ID、兑换码状态（未用/已用/作废）、来源、审批人、执行人、完成时间、接口状态、错误信息
    • 额度标准表：新用户默认额度、员工默认额度、按角色额度、重度用户加额、活动券单人限额（由管理层定）

6. 异常与升级

  • 额度与券码管理员为本流程唯一负责人（A），默认额度内的申请按规则自动放行；审批人作为 A（升级）的条件：超出默认额度、同一账号非当日首次申请、对外发放（合作方、媒体、政企用户）、付费券，任一审批人在 4 个工作小时内审批
  • 审批通过但未到账/客户反馈余额不足 → 经办 2 小时内核查补充 → 升级额度与券码管理员
  • 发放额度与申请不符 → 当天补差或作废重发，台账备注 → 经办处理
  • 测试服券在正式服无法兑换 → 作废后按正确环境重发 → 申请人重新提交
  • 同一券可重复兑换、券被抢光等滥用 → 立即停用批次 → 升级 CTO（当天）
  • 唯一经办人不在 → 备岗执行；无备岗时升级兜底人（4 小时内）
  • 表单维护期间 → 提前在群内通知暂停时间，积压申请恢复后 1 个工作日内处理

7. 衡量指标

  • 发放时效 = 提交到到账的时长，自动发放目标 ≤ 10 分钟，人工发放目标 ≤ 1 个工作日
  • 发放差错率 = 漏发、错额、错环境次数 / 发放次数，目标 ≤ 1%
  • 台账覆盖率 = 已登记的对外发放 / 实际对外发放，目标 100%
  • 群内索要额度/券码次数（每月），目标 ≤ 2
  • 月度赠送成本 = 赠送额度按商业价折算，按月对比预算

8. 低效诊断

  • 额度申请审批人来不及批，自动放行后仍收到审批通知；申请大额实际按默认额发放｜依据：「Leap产研测」2026-05
  • 发放执行人单点，审批通过后仍需群内催办"还是没给我充值"｜依据：「Leap产研测」2026-05、「跃迁AI总动员」2026-05
  • 默认发放额度标准反复讨论，无统一口径｜依据：「跃迁AI总动员」2026-05、「模态跃迁通知群」2026-05
  • 兑换码靠群内或私下发放，聊天记录难以追溯｜依据：「跃迁AI总动员」2026-05、「LeapPPT」2026-05
  • 测试环境与正式环境混淆，申请时不知道该选哪个｜依据：「模态集团（全员群）」2026-05、「LeapPPT」2026-05
  • 流程已点完成但实际未充值，客户反馈余额不足｜依据：「Leap产研测」2026-06
  • 对外发放无统一台账，对内看申请表、对外分散记录｜依据：「鼎慧产研决策部」2026-06
  • 兑换券可重复兑换、被抢光，活动教程命令错误需返工｜依据：「模态小龙虾测试群」2026-04、「LeapAll」2026-04
  • 新用户积分、邀请奖励规则需追问研发才知道｜依据：「Leap产研测」2026-05

9. 分支变体

  • LeapAll 直充：按充值申请 SOP，单一经办需设备岗；后续统一为"一券多人各用一次"的兑换券
  • LeapPPT 券码：表单+审批+自动发券（测试服、正式服均已支持）；外部 C 端用户需先入用户群；新用户默认积分后不再单独发码
  • LeapCore：账号预注册，不支持券码与个人充值，额度走 X-DLV-15 / RND-47
  • MerCoder 活动/比赛体验券：活动负责人提需求，后端配置（参考月卡限额），测试验收兑换、用量与教程
  • 内测/重要客户充值：先确认生产还是测试环境，到账后再点完成
  • 对外合作方、政企用户：必须登记台账并打版本标签
  • 付费买券：单独审批留痕，与赠券分开记账

10. 待确认问题

  • 额度与券码管理员是否为产品总监？对外发放登记由谁负责？
  • 默认额度、自动放行阈值、按角色额度标准由谁定？是否成文发布？
  • LeapAll 充值何时接入接口自动发放？经办备岗是谁？
  • 赠送额度成本归属哪个部门？是否与 FIN-16 合并管理？
  • 对外发放台账与 CRM 的边界如何划分？
OPS-08邀请码申请与账号开通待优化96

状态：待优化｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频4 × 耗2 × 跨4 × 险3

  • 适用场景：外部用户、客户、渠道或内部同事需要试用字字可研等产品时，受理邀请码/验证码申请、开通生产或测试账号与管理后台账号、发放额度包，并记录申请来源与处理状态
  • 负责人：主责——账号开通运营（当前：杨萌·推断待确认）；协同——后台研发（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、业务专家/回访（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、渠道对接（当前：闫登辉·推断待确认）、基石计划跟进（当前：黄飞鹏·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 申请入表（产品内申请/表单）→ ② 状态字段与来源标记 → ③ 运营审核真伪 → ④ 后台生成并短信发送邀请码 → ⑤ 开通账号与额度包 → ⑥ 回写状态、处理人 → ⑦ 回访与渠道统计
  • 交付结果：申请人收到可用的邀请码或账号（正确环境），申请记录带状态（待处理/已发/拒绝）、处理人和来源渠道；后台账号按角色开通
  • 状态依据：已有产品内申请页、多维表格、机器人卡片和管理后台；但申请无状态和时间，注册与申请共用通知、卡片数与后台记录对不上；运营不会/无权限发额度，依赖后台研发手工发码；手机号在群里明文流转；内部新人每次在群里要码

1. 场景判定

  • 触发条件：用户在产品内或表单申请试用；内部同事/新人需要测试或正式账号、后台账号；渠道需要批量码；合作计划参与者需要账号与额度
  • 典型说法：「有新用户申请邀请码，请尽快审核发放」「来个正式环境的邀请码」「发 2 个邀请码给某某」「帮新同学开一下后台账号」「发 10 个，记得发 10 个」
  • 判断问题：对方是需要"进入产品的账号"（走本流程）还是"已有账号要加额度/券码"（走 OPS-07）？
  • 不归本流程管：试用额度与兑换券 → 请走 OPS-07；企业客户组织与席位开通 → 请走 X-CS-02 / X-DLV-15；渠道卡密 → 请走 OPS-10；UTM 渠道链接 → 请走 OPS-12；研发开发环境账号 → 请走 RND-21；额度包与企业组织日常运维 → 请走 OPS-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账号开通运营 审核申请、发码、开账号、回写状态 R 产品运营（当前：杨萌·推断待确认）
研发负责人 发码规则、渠道批量码、后台权限分配 A Leap 研发负责人（当前：王皓南·推断待确认）
后台研发 后台功能、状态字段、短信与数据同步 C 后端（当前：宋祺睿·推断待确认）
新媒体运营 C 端申请用户邀约、回访 R（C 端） 新媒体运营（当前：李宣昊·推断待确认）
业务专家 B 端用户开通与回访、培训案例 R（B 端） 业务专家（当前：王满·推断待确认）
测试 正式/测试环境注册验证 C 测试（当前：李国庆·推断待确认）
渠道/销售 提供渠道或客户对象信息 I 销售（当前：闫登辉·推断待确认）
合作计划跟进 计划参与者登记与支持 R（计划） 产品经理（当前：黄飞鹏·推断待确认）

3. 办之前请准备

  • 申请人信息：姓名、手机号、公司/身份、来源渠道（通过表单提交，不在群内明文发送）
  • 环境：正式环境（外部用户）或测试环境（内部测试）
  • 账号类型：用户账号 / 管理后台账号（运营或管理员角色）
  • 额度包数量（不填默认 10 次，一个码只能用一次）
  • 渠道批量码：渠道名、数量、对应额度包
  • 合作计划：参与者登记表、需开通的邮箱与额度、培训材料

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 申请统一入多维表格（含申请时间、来源、环境），注册事件不再触发申请通知 系统 即时 产品申请页 + 多维表格 申请记录 🔧+🤖
2 机器人推送申请卡片，卡片带"通过/拒绝"按钮 系统 即时 飞书机器人 待办卡片 🔧飞书固化
3 审核申请真伪（手机号校验、重复检测、测试数据过滤） 账号开通运营 收到后 4 个工作小时内 多维表格 审核结论 👤人工判断
4 通过后由后台接口生成邀请码并短信发送，回写状态 系统 即时 管理后台 API 已发码 🤖自动化
5 按规则发放额度包（默认 10 次），特殊额度走 OPS-07 账号开通运营 发码同时 管理后台 额度记录 🔧+👤
6 内部同事：测试环境走特殊验证注册或预置白名单码；后台账号按角色模板开通 后台研发 申请后 1 个工作日内 管理后台 账号 🔧+👤
7 渠道批量码按渠道生成并登记发放人与额度包 账号开通运营 申请后 1 个工作日内 后台 + 台账 渠道码清单 🔧+👤
8 C 端回访、B 端转业务专家跟进，按渠道统计转化 新媒体运营、业务专家 开通后 3 个工作日内 渠道报表 回访记录 🔧+🤖

5. 交付物与模板

  • 交付物：申请记录（带状态）、邀请码/账号、额度包记录、渠道码清单、后台账号开通记录、回访记录
  • 建议模板/表单：
    • 邀请码申请表字段：申请时间、姓名、手机号（脱敏展示）、公司/身份、来源渠道、环境、账号类型、状态（待处理/已发/拒绝/已注册）、处理人、处理时间、邀请码批次、额度包数、备注
    • 后台账号角色模板：运营、管理员、只读，各自权限说明
    • 合作计划参与者登记表：参与者代号、所属单位、账号、额度、培训状态、跟进人

6. 异常与升级

  • 卡片数与后台记录对不上 → 当天核对并清理测试数据 → 升级后台研发
  • 邀请码显示不存在/一号绑多码/发错码 → 作废后重发 → 后台研发 1 个工作日内修复
  • 后台变更导致运营账号或备注丢失 → 当天恢复权限 → 升级研发负责人
  • 批量误封或角色误改 → 立即恢复并核对影响名单 → 升级研发负责人（2 小时内）
  • 未走申请直接发码 → 补登记录；导致异常的回收邀请码
  • 疑似虚假/刷量申请 → 拒绝并记录 IP/header → 运营判定

7. 衡量指标

  • 申请处理时效 = 提交到发码的时长，目标 ≤ 4 个工作小时
  • 状态完整率 = 有状态与处理人的申请 / 申请总数，目标 100%
  • 发码差错数（发错码、一号多码、错环境）每月，目标 0
  • 群内索要邀请码次数（每月），目标 ≤ 2
  • 渠道转化率 = 某渠道注册且活跃用户 / 该渠道申请数，按月统计

8. 低效诊断

  • 邀请码在群内手工发放、明文贴出，无领用记录｜依据：「工程咨询产研」2026-01
  • 运营不清楚额度包规则、后台无权限，需研发代发｜依据：「鼎慧产研决策部」2026-01
  • 申请无状态与时间，注册也触发申请通知，卡片与后台记录对不上｜依据：「鼎慧产研决策部」2026-02、「工程咨询产研」2026-02
  • 内部新人逐个在群里要码，渠道批量码需临时找"谁有空"｜依据：「工程咨询产研」2026-02
  • 手机号在群里明文流转，后台批量误封账号、测试号无法重新注册｜依据：「工程咨询产研」2026-04
  • 内测申请链路增加后，C 端用户需逐个邀约回访｜依据：「字字可研市场运营」2026-03、「字字可研市场运营」2026-04
  • 合作计划账号开通、额度与培训由多人接力，跟进断档｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 公开申请（C 端）：产品内申请 → 审核 → 短信发码；开放注册后邀请码改为选填，按渠道注册链接统计
  • B 端用户：转业务专家开通与回访
  • 内部同事：测试环境走特殊验证注册；正式环境用预置白名单码
  • 管理后台账号：按角色模板开通，新人私聊或表单提交手机号
  • 渠道批量码：按渠道独立额度包，登记发放人
  • 合作计划参与者（如基石计划）：先登记，再开邮箱账号、分配额度、安排培训案例

10. 待确认问题

  • 邀请码发放主责是产品还是运营？是否给运营开通后台发码权限？
  • 开放注册后邀请码是否仍需审核？哪些场景必须用邀请码？
  • 申请卡片按钮直接审批发码是否排期？
  • 合作计划是否已有成文 SOP，由谁维护？
  • 内部同事正式账号是否统一预置，离职时如何回收？
OPS-09用户额度包与企业组织运维待优化144

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：LeapAll / LeapCore / 字字可研用户需要月度额度重置、特殊用户调额、补词元，或用户反馈充值未到账、余额异常，或企业客户要求开通/删除组织、转移组织管理员时启动
  • 负责人：主责——产品负责人（额度规则与变更审批，当前：杨萌·推断待确认）；协同——后台/NewAPI 研发（当前：宋祺睿、柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、品牌/Logo 设计对接（当前：待指定）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交额度/组织变更申请 → ② 按额度规则核对口径 → ③ 审批 → ④ 后台执行（批量脚本或单条） → ⑤ 测试/抽查核对余额 → ⑥ 通知申请方及关联方（换 Logo 等） → ⑦ 台账留痕
  • 交付结果：已在后台生效且经核对的额度/组织变更，以及一条可追溯的变更记录（申请人、规则依据、执行人、生效时间）
  • 状态依据：已有 LeapCore 管理后台、NewAPI 和额度包配置文档，但无成文额度规则；2026-04～07 群内出现约 14 次额度相关追问，月度重置靠人工逐个改，出现"三版额度定义"、加余额功能上线后才发现 Bug、删组织后漏通知换 Logo 等问题

1. 场景判定

  • 触发条件：新自然月需要重置用户限额；特殊用户申请提额/无上限；用户反馈"额度没更新""余额不对"；企业客户要求新开组织、删除组织、转移 owner、补词元；新额度包上线需配置
  • 典型说法：「怎么给大家新一个月的限额」「设多少给多少，此前花费不计入」「新额度包配置发一下」「把某客户的组织删了」「用户反馈账户额度没更新」
  • 判断问题：这是对已有用户/组织的额度或组织属性变更吗？是否需要改后台数据？如果是对外售卖的卡密或渠道码，则不是本流程
  • 不归本流程管：渠道卡密生成与核销 → 请走 OPS-10；商城商品上架补货 → 请走 OPS-11；额度包定价与折扣制定 → 请走 X-PRD-23（产品套餐、积分/额度定价与计费规则）；用户付费后的跟进挽留 → 请走 OPS-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
额度规则负责人 维护额度规则文档，审批特殊调额、组织删除/转移 A 产品负责人（当前：杨萌·推断待确认）
后台执行人 在管理后台/NewAPI 执行重置、调额、补词元、组织变更 R 后台研发（当前：宋祺睿·推断待确认）
NewAPI 额度排查 余额异常、充值未到账查询与修复 R NewAPI 研发（当前：柯逸飞·推断待确认）
功能修复 后台批量/加余额等功能缺陷修复 R Leap 研发（当前：王皓南·推断待确认）
核对人 执行后抽查余额与统计口径 C 测试（当前：张东郅·推断待确认）
口径审阅 额度概念定义、规则变更评审 C CTO（当前：丁震宇·推断待确认）
财务 知悉额度发放对应的成本与计费影响 I 财务（当前：待指定）
关联方 组织变更后的 Logo/品牌配置更新 I 设计/前端对接人（当前：待指定）

3. 办之前请准备

  • 用户/组织标识（账号 ID 或组织 ID，不在群里发手机号）
  • 变更类型：月度重置 / 调额 / 补词元 / 开通 / 删除 / 转移 owner
  • 目标额度及规则依据（引用额度规则文档条款；"设置值=发放值，历史花费不计入"等口径须写明）
  • 特殊调额理由与有效期；企业客户的书面要求（截图或工单）
  • 是否涉及关联配置（Logo、组织名、额度包类型）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交额度/组织变更申请，填写对象、类型、额度、理由 申请人 发现需求当天 飞书审批/多维表格 变更单 🔧飞书固化
2 对照额度规则核对口径（发放/消耗/冻结），特殊用户判断是否放行 额度规则负责人 收单后 1 个工作日内 额度规则文档 审批意见 👤人工判断
3 月度重置：每月 1 日 10:00 前由定时脚本批量执行 后台执行人 每月 1 日 10:00 前 管理后台/脚本 批量执行日志 🤖自动化
4 单条调额/补词元/组织变更在后台执行，删除组织前先导出备份 后台执行人 审批通过后 4 小时内 LeapCore 管理后台/NewAPI 执行截图或日志 🔧+👤
5 抽查生效结果：余额、统计口径、用户端显示一致 核对人 执行后 1 个工作日内 管理后台/测试账号 核对结论 👤人工判断
6 通知申请方与关联方（换 Logo、组织名等），在变更单勾选"关联项已通知" 后台执行人 执行后 2 小时内 飞书群/任务 通知记录 🔧飞书固化
7 余额异常/充值未到账：先查 NewAPI 流水，再定位后台问题，必要时提缺陷单 NewAPI 额度排查 反馈后 4 小时内给初步结论 NewAPI/工单系统 排查结论 👤人工判断
8 变更单归档，月底汇总当月发放额度给财务 后台执行人 每月最后 1 个工作日 多维表格 月度额度变更台账 🔧+🤖

5. 交付物与模板

  • 交付物：生效的额度/组织变更；月度额度变更台账；额度规则文档（新建）
  • 建议模板/表单：额度变更单（申请人、对象 ID、产品线、变更类型、原额度、目标额度、规则依据、理由、有效期、审批人、执行人、执行时间、核对人、关联项是否通知）

6. 异常与升级

  • 月度重置脚本失败或漏执行 → 后台执行人手工补跑并通报 → 升级额度规则负责人（当天）
  • 用户反馈额度未更新超过 4 小时未定位 → 升级研发负责人（当天）
  • 后台功能缺陷导致发放错误（多发/少发） → 冻结该功能、出影响名单 → 升级研发负责人与财务（2 小时内）
  • 企业客户要求删除组织但无书面依据 → 暂缓执行 → 升级销售对接人确认（1 个工作日内）

7. 衡量指标

  • 变更处理时长：申请提交到后台生效，目标 ≤ 1 个工作日
  • 月度重置准时率：每月 1 日 10:00 前完成的比例，目标 100%
  • 额度差错数：多发/少发/错发次数，目标 每月 0 次
  • 余额异常响应时长：反馈到初步结论，目标 ≤ 4 小时

8. 低效诊断

  • 现象：后台无批量修改，月度重置需逐个手改或临时找脚本处理（规则未定义"批量重置"需求）｜依据：「Leap产研测」2026-07
  • 现象：额度"设置"与"发放"概念未成文，群内出现三版定义，执行口径反复｜依据：「Leap产研测」2026-07
  • 现象：加余额功能发布前未测，上线后才发现只查部分记录的缺陷，造成返工｜依据：「Leap产研测」2026-07
  • 现象：用户额度问题经群内转述到达研发，缺少统一入口｜依据：「Leap产研测」2026-07
  • 现象：额度包配置需在群里索要文档、词元与点数折算口径不一；组织删除后未通知 Logo 更新，形成交接断档｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • LeapAll 个人用户：按月限额，月初统一重置
  • LeapCore 企业组织：组织额度池、组织开通/删除/转移 owner
  • 特殊用户（无上限或高额度）：必须走审批并设有效期
  • 新用户赠送 / 手动补发：按额度包配置执行，词元与点数按定价方案统一换算

10. 待确认问题

  • 额度规则负责人是否为产品负责人？月度重置是否可直接由定时任务执行无需审批？
  • "设置值=发放值、历史花费不计入"是否为最终口径？额度规则文档由谁在何时成文？
  • 特殊用户（无上限）名单由谁维护、多久复核一次？
  • 组织删除前是否需要数据备份及保留期？是否需客户书面确认？
  • 月度额度发放是否需要同步给财务做成本核算？
OPS-10渠道卡密生成、额度包配置与核销待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：外部平台（AI 内容平台、AI 商城、地推活动等）需要售卖或兑换本公司产品，需要完成厂商接入、额度包配置、卡密/渠道邀请码生成、发放登记与核销查询时启动
  • 负责人：主责——产品负责人（渠道接入统筹，当前：杨萌·推断待确认）；协同——渠道需求/商务对接（当前：段涵·推断待确认）、后台研发（当前：宋祺睿·推断待确认）、后端实现（当前：王皓南·推断待确认）、兑换/钱包后端（当前：邓乾·推断待确认，备岗：岳阳·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、外部沟通（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 渠道需求立项 → ② 定额度包与结算口径（人工审批） → ③ 后台配置额度包与渠道 → ④ 测试验证 → ⑤ 后台生成卡密并登记 → ⑥ 加密交付渠道并留档 → ⑦ 核销查询/接口对接 → ⑧ 月度对账
  • 交付结果：已配置并验证的渠道额度包、登记在册的卡密批次、交付记录，以及可随时查询的核销状态与月度渠道对账表
  • 状态依据：渠道售卖已实际发生，但每次临时对接，无接入清单与发放登记；2026-02～06 出现额度包多发、邀请码忘配额度导致用户无额度、"之前发给谁了"找不到、卡密是否被用要 @ 多人才查到等问题

1. 场景判定

  • 触发条件：外部平台要求本公司作为厂商入驻；需要生成一批卡密/兑换码放到渠道售卖；地推页面要对接兑换码核销；销售或渠道询问某卡密是否已使用
  • 典型说法：「需要我们作为厂商接入，设计卡密兑换通道」「需要生成一批卡密放在渠道平台上售卖」「看下这个卡密被使用过吗」「需要提供一个接口接到地推页面」
  • 判断问题：卡密/邀请码是否面向外部渠道售卖或兑换？是否涉及渠道结算？若只是自家商城商品上架则不是本流程
  • 不归本流程管：OPC 商城自营商品上架、补货、下架销毁 → 请走 OPS-11；已有用户/组织调额 → 请走 OPS-09；仅带来源的注册链接 → 请走 OPS-12；第三方商家入驻 → 请走 ECO-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
渠道接入统筹 立项、定额度包方案、拍板发放口径 A 产品负责人（当前：杨萌·推断待确认）
渠道商务对接 收集渠道需求、确认结算方式、交付卡密 R 渠道产品/商务（当前：段涵·推断待确认）
后台配置与生成 配置额度包、渠道、邀请码，生成卡密 R 后台研发（当前：宋祺睿·推断待确认）
后端实现 渠道逻辑、额度叠加规则实现与修复 R Leap 研发（当前：王皓南·推断待确认）
核销查询/接口 卡密状态查询、核销接口与 PR 合并 R 兑换/钱包后端（当前：邓乾·推断待确认；备岗：岳阳·推断待确认）
测试验证 按渠道邀请码注册验证额度、上线前核对 C 测试（当前：张东郅、李国庆·推断待确认）
外部沟通 拉外部入驻沟通群、对齐高层口径 C CTO（当前：丁震宇·推断待确认）
财务 结算口径审核、收款/退款、月度对账 C 财务（当前：待指定）

3. 办之前请准备

  • 渠道名称（内部代号）、渠道类型（代销/分销/地推/兑换）、对接人
  • 需求文档：售卖 SKU、额度包组成、数量、有效期、上线日期
  • 结算方式与结算时点（代销结算前能否兑换须写明）
  • 额度类型与成本测算（引用产品定价方案）
  • 是否需要核销接口；如需，字段与签名方式（手机号、兑换码、请求 ID、签名）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 渠道需求登记立项，填写渠道接入清单 渠道商务对接 收到需求当天 多维表格 渠道接入记录 🔧飞书固化
2 定额度包组成、折扣与结算口径，提交审批 渠道接入统筹 立项后 2 个工作日内 飞书审批 已审批的额度包方案 👤人工判断
3 后台创建渠道与额度包，配置叠加规则与"最多拥有数量" 后台配置与生成 审批后 2 个工作日内 管理后台 渠道配置 🔧+👤
4 测试环境按渠道邀请码注册，核对发放数量与叠加，确认普通邀请码不受影响 测试验证 配置后 1 个工作日内 测试环境 测试结论 👤人工判断
5 正式环境用后台（不用临时脚本）生成卡密，核对"邀请码已配额度包" 后台配置与生成 测试通过后 1 个工作日内 管理后台 卡密批次文件 🤖+👤
6 批次登记台账（批次号、渠道、额度包、数量、有效期、交付人），加密文件交付渠道并存档 渠道商务对接 生成当天 多维表格/飞书云盘 发放登记 🔧飞书固化
7 核销查询：通过后台查询页或机器人查卡密状态，不再逐人 @ 核销查询/接口 收到询问后 2 小时内 管理后台/机器人 查询结果 🤖自动化
8 地推/渠道需要接口时，渠道商务对接提工单；核销查询/接口负责人开发并提交 PR 合并，接口支持请求 ID 幂等 渠道商务对接（提单）、核销查询/接口（开发与合并） 提单后 2 个工作日内评估并给出排期，按排期交付 工单系统/Gitea 核销接口 👤人工判断
9 每月 5 日前导出各渠道核销数据，与财务对账 渠道商务对接 每月 5 日前 后台导出/多维表格 渠道对账表 🤖+👤

5. 交付物与模板

  • 交付物：渠道接入记录；额度包配置；卡密批次文件及发放登记；核销查询结果；月度渠道对账表
  • 建议模板/表单：渠道接入清单（渠道、对接人、类型、额度包、折扣、结算方式、结算时点、邀请码批次、上线日期、负责人）；卡密发放登记表（批次号、渠道、额度包、数量、生成时间、生成人、交付方式、交付时间、有效期、已核销数）

6. 异常与升级

  • 发现额度包多发/错发 → 立即停用该批邀请码，出影响名单 → 升级渠道接入统筹与财务（2 小时内）
  • 渠道上线后用户无额度 → 补配额度包并补发 → 升级研发负责人（当天）
  • 卡密疑似重复核销 → 冻结卡密、查核销日志 → 升级财务（当天）
  • 核销查询负责人请假 → 由备岗处理；无备岗 → 升级研发负责人（2 小时内）
  • 结算口径不明（如结算前能否兑换） → 暂停上线 → 升级渠道接入统筹与财务（1 个工作日内）

7. 衡量指标

  • 渠道接入周期：立项到上线的工作日数，目标 ≤ 7 个工作日
  • 额度错发次数：目标 每月 0 次
  • 卡密登记完整率：已生成卡密中有登记记录的比例，目标 100%
  • 核销查询响应时长：询问到给出结果，目标 ≤ 2 小时

8. 低效诊断

  • 现象：渠道接入每次临时对接，额度类型、定价、邀请码、测试、结算无清单，需求截止仅留 4 天｜依据：「工程咨询产研」2026-02
  • 现象：额度包发放数量与次数含义混淆，测试发现多款额度包全发、普通邀请码也送包，多轮返工｜依据：「工程咨询产研」2026-02
  • 现象：卡密生成后无发放登记，事后"不记得发给谁"；邀请码忘配额度包上线后才发现｜依据：「工程咨询产研」2026-03
  • 现象：卡密是否已使用缺查询入口，逐级转 4 人才找到能查的人；负责人请假无代理｜依据：「Leap产研测」2026-06
  • 现象：核销接口需求在群里口头提出，后补工单｜依据：「Leap产研测」2026-06

9. 分支变体

  • 默认渠道 / 渠道平台 A 专属渠道：额度叠加规则不同（学生体验包、学生优惠包，优惠包叠加项目创建个数）
  • 字字可研卡密：渠道售卖，结算口径由财务确认
  • 地推兑换页：需对接核销接口，接口字段与签名单独评审
  • 组织创建额度（内部/测试账号）：不走渠道，走 OPS-09
  • 退款：由测试验证退款后额度回收，财务处理退款

10. 待确认问题

  • 渠道接入主责是产品负责人还是销售/渠道负责人？
  • 结算方式（代销/买断）与结算时点由谁最终审批？财务是否必须会签？
  • 卡密文件统一存放位置与访问权限如何设置？
  • 卡密查询页/机器人是否已排期？核销接口幂等要求是否已写入接口规范？
  • 渠道接入周期 7 个工作日是否可行？
OPS-11OPC 商城自营商品上架、下架与补货待优化192

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：公司自营的卡密、兑换券、Skill、算力加油包或主管单位要求上架的免费产品，需要在 OPC 商城上架、下架、补货或因退款销毁卡密时启动
  • 负责人：主责——OPC 商城运营（当前：陈梦琪·推断待确认）；协同——卡密管理员（当前：葛家和·推断待确认）、商品提供方研发（当前：邓乾·推断待确认）、兑换接口研发（当前：望政韬·推断待确认）、退款审核（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 商品上架申请 → ② 提交介绍与卡密 → ③ 卡密导入核对并登记台账 → ④ 商城录入、内部试用 → ⑤ 正式上线 → ⑥ 库存监控与补货 → ⑦ 下架/退款销毁留痕
  • 交付结果：在 OPC 商城正常售卖且库存充足的商品；记录完整的卡密台账（每批上架、补货、销毁的操作人与原因）
  • 状态依据：已有商城后台与商品介绍模板，但 2026-03～08 反复出现催上架、卡密未提供就上架、下架需找外部平台方；2026-07 出现商城售出无效卡密、原始券码文件在个人手里、销毁无记录的事故，随后才定台账规则

1. 场景判定

  • 触发条件：新产品要在商城售卖或兑换；算力加油包/兑换券库存不足；商品需下架；用户反馈卡密无效或退款需销毁卡密
  • 典型说法：「某产品啥时候上商城」「卡密发了，但还没录入后台上架」「定期让运营去补货就行了」「这种操作应该要留痕」
  • 判断问题：商品是否为本公司自营、通过 OPC 商城售卖？是否涉及卡密库存？
  • 不归本流程管：第三方商家入驻与准入 → 请走 ECO-07；外部渠道平台售卖卡密 → 请走 OPS-10；用户额度调整 → 请走 OPS-09；商品定价 → 请走 X-PRD-23（产品套餐、积分/额度定价与计费规则）/ SAL-18（产品定价与价格体系管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
商城运营 商品录入上架、上线日期、库存监控、补货 R OPC 商城运营（当前：陈梦琪·推断待确认）
卡密管理员 卡密批次导入、台账维护、下架销毁操作 R 商城后台研发（当前：葛家和·推断待确认）
商品提供方 按模板提供商品介绍、生成卡密 R 产品研发（当前：邓乾·推断待确认）
兑换接口 兑换券对接 NewAPI 加额度、批量生成 C NewAPI 研发（当前：望政韬·推断待确认）
退款审核 审核退款并联动卡密销毁 R 产品经理（当前：陈震·推断待确认）
规则拍板 SKU、货币单位、上架规则决策 A 产品负责人（当前：杨萌·推断待确认）；SKU 规则（当前：丁震宇·推断待确认）
财务 账单与收入结算 I 财务（当前：待指定）

3. 办之前请准备

  • 按商城模板写好的商品介绍（名称、功能、使用方式、有效期、价格或兑换币值）
  • 卡密/兑换码批次文件（不通过私聊发送，放指定云盘目录）
  • SKU 与价格（已审批），货币单位口径
  • 上线日期、"即将上线"预告是否需要
  • 补货：当前库存、近 7 天销量；下架/销毁：卡密编号、原因、关联退款单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交商品上架申请，登记上架清单 商品提供方 计划上线前 5 个工作日 多维表格 上架记录 🔧飞书固化
2 按模板提供介绍，卡密批次文件上传指定目录 商品提供方 申请后 2 个工作日内 飞书云盘 介绍稿 + 卡密文件 🔧飞书固化
3 卡密批量导入，脚本校验重复与格式，登记台账（批次、数量、导入人） 卡密管理员 收到文件后 1 个工作日内 管理端/脚本 卡密台账 🤖自动化
4 商城录入商品，先挂"即将上线"，内部账号试购试兑换 商城运营 导入后 1 个工作日内 商城后台 试用结论 👤人工判断
5 正式上线并在群内同步上线信息 商城运营 试用通过当天 商城后台 上线通知 🔧+👤
6 库存低于阈值（建议剩余 ≤ 7 天销量）机器人提醒，生成新批次补货 商城运营 + 兑换接口 提醒后 2 个工作日内 NewAPI/机器人 补货批次 🔧+🤖
7 用户反馈卡密无效：卡密管理员对照台账与原始批次排查 卡密管理员 反馈后 4 小时内 管理端/台账 排查结论 👤人工判断
8 退款：用户走"退款重新买"，退款审核通过后同步销毁对应卡密，台账记录操作人与原因 退款审核 + 卡密管理员 退款审批通过后 1 个工作日内 飞书审批/管理端 销毁记录 🔧飞书固化
9 下架：提交下架原因，涉及外部平台的由商城运营对接，台账登记 商城运营 申请后 2 个工作日内 商城后台 下架记录 👤人工判断

5. 交付物与模板

  • 交付物：上线商品；卡密台账（含上架、补货、销毁全记录）；月度库存与销售汇总
  • 建议模板/表单：商品上架清单（商品名、类型、提供方、介绍稿链接、SKU、价格/兑换值、卡密批次、数量、试用结论、上线日期）；卡密台账（批次号、导入时间、导入人、数量、已售、已兑、销毁数、销毁原因、操作人、关联退款单）

6. 异常与升级

  • 卡密未到位但商品已上架 → 立即改回"即将上线" → 升级产品负责人（当天）
  • 售出无效卡密 → 先给用户补发或退款，排查原因 → 升级卡密管理员与财务（4 小时内）
  • 退款后卡密未销毁 → 立即作废并核对是否已被兑换 → 升级财务（当天）
  • 下架依赖外部平台方超过 2 个工作日未处理 → 升级研发负责人（第 3 个工作日）
  • 库存售罄 → 商城显示缺货并加急补货 → 升级商城运营负责人（当天）

7. 衡量指标

  • 上架周期：申请到正式上线的工作日数，目标 ≤ 5 个工作日
  • 缺货时长：商品库存为 0 的累计小时数，目标 每月 0 小时
  • 无效卡密率：用户反馈无效卡密数 / 售出数，目标 0
  • 台账完整率：卡密操作有记录的比例，目标 100%

8. 低效诊断

  • 现象：上架进度靠群里反复催问，商品信息与卡密未同步提供，出现先上架后补卡密｜依据：「Leap产研测」2026-03、「Leap产研测」2026-04
  • 现象：下架需找外部平台方处理，职责链路不清｜依据：「Leap产研测」2026-08
  • 现象：兑换券额度信息由谁存、谁验口径反复讨论；兑换码手动批量生成，补货无台账｜依据：「New API Claw SKILL计划」2026-03
  • 现象：原始券码文件个人保管、销毁操作无记录、人员离职后无法追溯，事故后才定台账规则｜依据：「Leap产研测」2026-07
  • 现象：货币单位命名多次讨论未定｜依据：「Leap产研测」2026-03

9. 分支变体

  • 自家商品（兑换码、词元券、Skill） vs 第三方合作方免费商品（主管单位要求上架）
  • 虚拟币兑换 vs 现金购买
  • 算力加油包：NewAPI 固定额度兑换码，约 3 档 SKU，用户在页面输入券码由后端调用兑换接口加额度
  • 退款销毁：统一走"退款重新买"，不做单券替换

10. 待确认问题

  • 商城运营与卡密管理员的分工是否如上（运营管上架补货，研发管卡密台账）？
  • 库存提醒阈值与补货时限是否可行？兑换码生成能否接口化？
  • 退款审核是否由产品经理承担，还是应归财务？
  • 外部平台方下架的对接人和时限是否有约定？
  • 货币单位名称是否已最终确定？
OPS-12渠道来源 UTM 链接/二维码申请与追踪待优化72

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：市场活动、生态大会、媒体投放、线下积分卡或运营推广需要带来源标识的注册链接/二维码，并在后台统计渠道转化时启动
  • 负责人：主责——渠道码管理员（当前：张东郅·推断待确认）；协同——需求方产品负责人（当前：杨萌·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、研发（当前：马漳毓、黄振锋·推断待确认）、技术方案（当前：王皓南·推断待确认）、渠道推广（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交渠道码申请 → ② 按规范命名 utm_source → ③ 确认正式环境支持 → ④ 生成长期链接/短链/二维码 → ⑤ 测试扫码注册归因 → ⑥ 交付并登记 → ⑦ 周度归因报表
  • 交付结果：可用于投放的带 utm_source 的长期链接/二维码，渠道登记记录，以及按渠道统计的注册转化报表
  • 状态依据：已有 UTM 渠道归因配置说明文档和后台来源字段，但 2026-04～05 约 10 余次申请靠群内沟通，命名规则临时约定，出现正式服版本落后无 utm 字段、使用场景未说清导致多轮讨论、反复催要二维码

1. 场景判定

  • 触发条件：任何对外推广物料需要注册入口；线下积分卡需扫码注册兑换；需要区分运营推来的用户与自然用户
  • 典型说法：「推广之前加个 utm source，不然都不知道什么渠道转化的」「大会嘉宾积分卡我需要一个专属链接」「给我一个带 utm 的长期链接」「运营推过来的用户，直接发带标识的 url 行不行」
  • 判断问题：本次推广是否需要统计"从哪来"？链接是否只做来源标记（不含兑换权益）？
  • 不归本流程管：链接内含兑换码/卡密权益 → 请走 OPS-10；用户邀请裂变奖励规则 → 请走 OPS-13；活动整体策划 → 请走 OPS-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
渠道码管理员 审核命名、生成链接/二维码、登记、出报表 R/A 测试负责人（当前：张东郅·推断待确认）
需求方 提交来源名、用途、场景（实体卡/线上）、有效期 R 产品负责人（当前：杨萌·推断待确认）；渠道推广（当前：杨明学·推断待确认）
流程协调 整理积分卡等扫码兑换流程、维护配置说明文档 C 产品运营（当前：杨黔昆·推断待确认）
研发 确认正式环境支持、实现"我的渠道链接"、短链 R 研发（当前：马漳毓、黄振锋·推断待确认）
技术方案 参数防拦截、邀请码与 utm 并存方案 C Leap 研发（当前：王皓南·推断待确认）

3. 办之前请准备

  • 来源名（短英文、数字、下划线或中划线，不带空格；建议"活动_渠道_日期"或"城市_渠道"）
  • 用途与场景：实体卡 / 海报 / 线上推文 / 媒体
  • 产品线与落地页；是否需二维码、数量
  • 有效期与负责人
  • 是否叠加兑换权益（如有，另走 OPS-10）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交渠道码申请，写清场景与用途 需求方 投放前 3 个工作日 飞书表单/多维表格 申请记录 🔧飞书固化
2 按命名规范审核 utm_source，查重 渠道码管理员 收单后 4 小时内 渠道配置表 确认的来源名 🔧+🤖
3 确认正式环境版本已支持来源字段 研发 收单后 1 个工作日内 正式环境 支持确认 👤人工判断
4 生成长期链接，过长时做短链，批量生成二维码 渠道码管理员 确认后 4 小时内 生成工具/脚本 链接 + 二维码包 🤖自动化
5 用新账号扫码注册，核对后台来源字段（首次点击归因，30 天有效，注册后锁定） 渠道码管理员 生成后当天 测试账号/后台 测试结论 👤人工判断
6 交付需求方，渠道配置表登记 渠道码管理员 测试通过当天 多维表格 登记记录 🔧飞书固化
7 每周一出各渠道注册与转化报表 渠道码管理员 每周一 12:00 前 后台/AI 周报 渠道归因周报 🤖自动化

5. 交付物与模板

  • 交付物：带 utm 的长期链接/短链、二维码压缩包、渠道登记记录、渠道归因周报
  • 建议模板/表单：渠道码申请表（渠道名、utm_source、用途、场景、产品线、落地页、数量、有效期、需求方、负责人、生成时间、测试结论）

6. 异常与升级

  • 正式环境不支持来源字段 → 延后投放或先用邀请码兜底 → 升级研发负责人（当天）
  • 投放前 1 个工作日内才提申请 → 按加急处理但需求方说明原因 → 升级产品负责人（当天）
  • 链接被平台拦截 → 研发调整参数名 → 升级技术方案负责人（4 小时内）
  • 周报中渠道归因为空 → 渠道码管理员排查 → 升级研发（1 个工作日内）

7. 衡量指标

  • 渠道码交付时长：申请到交付，目标 ≤ 1 个工作日
  • 归因覆盖率：新注册用户中有 utm_source 的比例，目标 ≥ 80%（推广期）
  • 命名合规率：登记渠道名符合规范的比例，目标 100%

8. 低效诊断

  • 现象：二维码与链接需求在群里临时提出、反复催要，缺申请入口与交付时限｜依据：「LeapPPT」2026-05
  • 现象：使用场景（实体卡还是线上）一开始未说明，多轮讨论后才定方案｜依据：「LeapPPT」2026-05
  • 现象：正式服版本落后，缺 utm 字段，投放前才发现｜依据：「LeapPPT」2026-05
  • 现象：积分卡扫码功能交付测试时缺功能说明，未登录无法扫码兑换需二次适配｜依据：「Leap产研测」2026-05
  • 现象：邀请码与带参数链接方案、渠道写死还是后台创建反复讨论｜依据：「LeapPPT」2026-04

9. 分支变体

  • 邀请链接（用户裂变）：链接较长需短链，后续做"我的渠道链接"
  • 渠道链接（活动/媒体）：不含兑换码，仅新注册用户生效
  • 实体积分卡：扫码 → 注册 → 兑换引导，兑换部分走 OPS-10
  • 渠道配置：当前为写死，后续改后台创建

10. 待确认问题

  • 渠道码管理员是否长期由测试负责人担任，还是移交运营岗？
  • 命名规范是否以"UTM Source 渠道归因配置说明"为准？
  • "我的渠道链接"与短链功能是否已排期？
  • 渠道归因周报由谁看、用于什么决策？
OPS-13拉新增长活动策划与传播物料待新建144

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：产品内测拉新、邀请注册、分享红包/代金券/额度赠送等增长活动需要立项，以及配套传播文案与物料需要统一发布时启动
  • 负责人：主责——运营负责人（当前：李凯·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、方案提议人（当前：王皓南、丁震宇·推断待确认）、风控评审（当前：宋祺睿·推断待确认）、传播执行（当前：赵雪冰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 活动立项（目标/预算/承接） → ② 风控与财务审批 → ③ 产品承接与研发配置 → ④ 文案物料生成与审核 → ⑤ 定版发布 → ⑥ 活动监测 → ⑦ 复盘
  • 交付结果：经审批的活动方案、唯一定版的传播物料与发布记录，以及活动结束后 5 个工作日内的复盘报告（拉新数、成本、薅羊毛拦截情况）
  • 状态依据：2026-02 多次讨论红包/代金券方案无结论，因运营岗位未就位被搁置；2026-05 运营 SOP 在做但未发布，执行同事用旧文案群发后文案又更新，物料无版本管理

1. 场景判定

  • 触发条件：产品需要拉新或提升活跃；有人提出红包、代金券、送额度、邀请排名等活动；需要批量发布推广文案
  • 典型说法：「分享领红包，认证工程师多领」「该定运营方案了」「我们现在缺的是用户承接」「正在优化 SOP，一会就发出来」
  • 判断问题：这是带资源投入（钱、额度、券）的增长动作吗？是否需要对外统一口径发布？
  • 不归本流程管：单个渠道链接/二维码 → 请走 OPS-12；种子用户邀请与拉群 → 请走 OPS-14；卡密/券的生成 → 请走 OPS-10；品牌宣发 → 请走 BRD-09（事件型宣发稿与新闻稿）/ BRD-08（新媒体日常内容生产与发布）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动负责人 立项、定方案、组织执行与复盘 A/R 运营负责人（当前：李凯·推断待确认）
产品承接 评估产品承接能力、确定落地页与转化路径 C 产品负责人（当前：杨萌·推断待确认）
方案提议 提出活动创意与奖励设计 C Leap 研发负责人/CTO（当前：王皓南、丁震宇·推断待确认）
风控评审 防薅羊毛规则与技术实现 C 后端研发（当前：宋祺睿·推断待确认）
传播执行 按定版物料发布 R 传播执行（当前：赵雪冰·推断待确认）
财务 预算与现金类奖励审批 C 财务（当前：待指定）

3. 办之前请准备

  • 活动目标（拉新数/激活数）与目标用户
  • 奖励形式（现金红包/代金券/额度）与预算上限
  • 产品承接路径：落地页、注册、首次使用引导
  • 风控规则：每人上限、实名/认证要求、异常账号识别
  • 渠道链接需求（走 OPS-12）与传播渠道清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写活动立项表（目标、预算、奖励、承接、风控、监测指标） 活动负责人 上线前 10 个工作日 多维表格 立项表 🔧飞书固化
2 产品承接评审，确认承接路径可用 产品承接 立项后 2 个工作日内 评审会/飞书文档 承接结论 👤人工判断
3 风控与财务审批（现金类必须财务会签） 风控评审 + 财务 立项后 3 个工作日内 飞书审批 审批结果 🔧飞书固化
4 研发配置奖励规则、渠道链接 研发 审批后 3 个工作日内 后台 活动配置 👤人工判断
5 AI 批量生成文案与物料，活动负责人审核定版，标注版本号 活动负责人 上线前 2 个工作日 物料生成器/多维表格 定版物料 🤖+👤
6 按定版物料发布，登记发布渠道与时间；文案更新时通知已发布方 传播执行 上线当天 多维表格 发布记录 🔧飞书固化
7 活动期间每日监测拉新、成本、异常账号 活动负责人 每日 18:00 前 后台/看板 日报 🤖自动化
8 活动结束出复盘 活动负责人 结束后 5 个工作日内 飞书文档 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：活动立项表、审批记录、定版物料、发布记录、日监测、复盘报告
  • 建议模板/表单：活动立项表（活动名、目标、目标用户、奖励形式、预算上限、承接路径、风控规则、监测指标、上线/结束日期、负责人）；物料版本表（物料名、版本号、定版时间、审核人、发布渠道、发布人、发布时间、是否已替换旧版）

6. 异常与升级

  • 方案讨论 2 次仍无结论 → 由活动负责人给出决策建议 → 升级研发负责人拍板（3 个工作日内）
  • 发现批量薅羊毛 → 暂停奖励发放 → 升级风控评审与财务（2 小时内）
  • 预算超支 80% → 暂停或缩量 → 升级财务（当天）
  • 旧版物料已发出 → 发更正或替换 → 升级活动负责人（当天）

7. 衡量指标

  • 获客成本：活动总成本 / 有效新增用户，目标按立项值
  • 有效新增：注册且完成首次核心操作的用户数
  • 异常账号率：识别为薅羊毛的账号占比，目标 ≤ 5%
  • 物料错版次数：目标 0

8. 低效诊断

  • 现象：活动方案多人提议但无人负责定方案，讨论后搁置；运营岗位未就位时方案无人落地｜依据：「鼎慧产研决策部」2026-02
  • 现象：红包类方案未先评估产品承接与防薅羊毛，讨论方向分散｜依据：「鼎慧产研决策部」2026-02
  • 现象：运营 SOP 未固化发布，执行侧取旧文案群发，文案更新后已发出的旧稿作废｜依据：「模态AI探索小分队」2026-05

9. 分支变体

  • 现金红包：必须财务会签，设单人上限
  • 代金券 / 额度赠送：券与额度生成走 OPS-10 / OPS-09
  • 传播渠道：社媒（X）、微信社群、邀请注册排名活动

10. 待确认问题

  • 运营负责人是谁？（报送口径与群内观察不一致）
  • 现金类活动的预算审批人是谁？是否需要 CEO 审批？
  • 运营 SOP 与物料生成器是否已有成稿？存放在哪里？
  • 立项提前 10 个工作日是否可行？
OPS-14种子用户与产品用户社群运营待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：团队成员邀请朋友、客户、学生、媒体老师试用产品，需要发券并拉入用户群；或产品用户社群需要明确归属、处理新成员入群与账号变更时启动
  • 负责人：主责——运营负责人（当前：李凯·推断待确认）；协同——产品（当前：杨萌、杨黔昆·推断待确认）、邀请人（当前：王皓南、杨朋伟、邴龙志等·推断待确认）、表单维护（当前：陈晖·推断待确认）、话术/FAQ（当前：胡橙橙·推断待确认）、企微认证（当前：侯明月·推断待确认）、兼职研发（当前：黄振锋·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 邀请人提交发券申请（含用户微信号） → ② 先拉群/加客服 → ③ 审批发券 → ④ 入群欢迎与须知 → ⑤ 收集反馈 → ⑥ 周度抽查与种子用户识别 → ⑦ 社群维护（换号、清理）
  • 交付结果：每个获券用户都已进入对应用户群或添加客服；种子用户名单与反馈记录；每个产品社群有明确负责人和入群须知
  • 状态依据：2026-05 反复要求出种子用户 SOP 但群内未见成稿；券发了一批但用户群一个没拉；群多且混乱；统计后"一个真正意义上的种子用户都没有"；LeapPPT 社群"谁管"不清

1. 场景判定

  • 触发条件：有人要给外部人员发试用券；新产品需要用户群；社群出现归属不清、群过多；用户换账号或外部人员想入群
  • 典型说法：「SOP 就是发券然后拉群」「没有进用户群的就不审批通过了」「这个产品的社群谁管呢」「换了账号，怎么邀请新账号入群」
  • 判断问题：对方是否为不付费但有价值、可帮忙推广的用户？是否需要持续收集其反馈？
  • 不归本流程管：大规模拉新活动 → 请走 OPS-13；带来源的注册链接 → 请走 OPS-12；用户反馈入表 → 请走 OPS-16；付费用户跟进 → 请走 OPS-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
社群负责人 统一运营策略与推广 SOP、审批发券、周度抽查 A/R 运营负责人（当前：李凯·推断待确认）
邀请人 邀请用户、填申请、先拉群后发券 R 团队成员（当前：王皓南、杨朋伟、邴龙志等·推断待确认）
产品 定义种子用户标准、反馈处理 C 产品（当前：杨萌、杨黔昆·推断待确认）
表单维护 发券申请表字段与审批流 R 表单维护（当前：陈晖·推断待确认）
话术/FAQ 入群欢迎语、FAQ、客服话术 R 运营/客服（当前：胡橙橙·推断待确认）
企微认证 企业微信主体认证 R 行政（当前：侯明月·推断待确认）
研发支持 社群所需功能（帮助页、机器人） C 兼职研发（当前：黄振锋·推断待确认）

3. 办之前请准备

  • 被邀请人类型：天使用户 / 媒体老师 / 学校团队 / 付费客户
  • 用户微信号（用于核对是否已入群，不在公开群里发）
  • 邀请理由与预期价值（反馈、推广）
  • 对应产品线与目标群（核心用户群或泛用户群）
  • 渠道链接（走 OPS-12），便于后台归因

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写发券申请表（必填"用户微信号""已拉群/已加客服"） 邀请人 邀请当天 飞书审批 申请单 🔧飞书固化
2 先引导用户扫微信客服码；愿意反馈的核心用户拉入核心群 邀请人 提交申请前 企业微信/微信客服 入群记录 👤人工判断
3 审批：未拉群/未加客服的不通过；通过后发券（新用户默认积分按规则） 社群负责人 收单后 1 个工作日内 飞书审批/后台 已发券 🔧飞书固化
4 入群欢迎语 + 置顶入群须知（使用说明、反馈方式、换号处理） 话术/FAQ 用户入群当天 机器人/群公告 欢迎记录 🤖自动化
5 群内反馈由机器人归集入表 社群负责人 每日 机器人/多维表格 反馈记录（转 OPS-16） 🤖自动化
6 每周抽查：发券用户入群率、活跃度，识别种子用户 社群负责人 每周一 后台/多维表格 种子用户名单 👤人工判断
7 换号/外部引荐：用户加助手号由助手号代邀请；外部人员先填登记表再审核入群 话术/FAQ 申请后 1 个工作日内 助手号/登记表 入群记录 🔧+🤖
8 每月清点社群：合并重复群、确认每群负责人 社群负责人 每月最后 1 个工作日 社群台账 社群清单 👤人工判断

5. 交付物与模板

  • 交付物：发券审批记录、社群台账、种子用户名单、入群须知、周度抽查结果
  • 建议模板/表单：发券申请表（邀请人、用户类型、用户微信号、产品线、目标群、是否已入群、券类型、理由）；社群台账（群名、产品线、群类型、负责人、成员数、建群日期、入群须知链接、最近活跃日期）

6. 异常与升级

  • 发券后 3 天用户仍未入群 → 邀请人跟进 → 社群负责人在周抽查中通报（每周一）
  • 社群无负责人 → 暂停新增成员 → 升级研发负责人指定（3 个工作日内）
  • 群内出现负面舆情或投诉 → 话术/FAQ 先安抚 → 升级社群负责人（2 小时内）
  • 企微认证未完成影响拉群 → 升级行政（1 个工作日内）

7. 衡量指标

  • 发券入群率：已入群/已加客服的获券用户 / 发券用户，目标 ≥ 90%
  • 种子用户数：每月提交有效反馈 ≥ 1 次的用户数
  • 社群归属率：有明确负责人的社群占比，目标 100%
  • 换号/入群处理时长：目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：反复要求出种子用户 SOP，但群内未见成稿，执行无监督，"没 SOP"与"没人落实"互相推诿｜依据：「LeapPPT」2026-05
  • 现象：先发券后拉群，券发出去但用户群未建，反馈无法回收，后台统计无真正种子用户｜依据：「LeapPPT」2026-05
  • 现象：用户群过多且混乱，需要运营统一收口｜依据：「LeapPPT」2026-05
  • 现象：引流产品作为运营工具后，社群由谁运营未明确，研发资源兼职｜依据：「鼎慧产研决策部」2026-05
  • 参考做法：外部创业社群用官方助手号欢迎新人、代邀换号账号、外部人员先填登记表，可借鉴为入群须知与机器人处理｜依据：「奇绩校友飞书群」2026-05、「奇绩校友飞书群」2026-06

9. 分支变体

  • 天使用户（不付费但有价值）/ 媒体老师 / 学校团队 / 付费客户（付费客户另走 OPS-15）
  • 核心用户群（只拉愿意反馈的） vs 泛用户群（客服码承接）
  • C 端产品（如 LeapPPT）社群 vs B 端产品客户群
  • 用户群只用微信/企业微信

10. 待确认问题

  • 运营负责人是谁？社群统一收口人是否为该负责人？
  • 种子用户的标准是什么（反馈次数、推广数）？
  • 新用户默认积分与种子用户券额是否已成文？
  • 企业微信认证当前进度？
  • LeapPPT 社群由谁负责？
OPS-15付费用户识别、跟踪与挽留待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：C 端产品（如字字可研）出现充值用户，或用户充值后停止使用，需要识别是否真实用户、跟踪回访、收集反馈并挽留或引导升级时启动
  • 负责人：主责——用户运营建联（当前：王满·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、数据查询（当前：陈锦杰·推断待确认）、权限开通（当前：宋祺睿·推断待确认）、销售承接（当前：吴琪·推断待确认）、挽留额度审批（当前：丁震宇·推断待确认）；兜底——运营负责人（当前：李宣昊·推断待确认）
  • 核心流程：① 付费事件推送 → ② 按权限查看用户信息 → ③ 判定真实用户/调研/放弃 → ④ 首次建联 → ⑤ 赠额度与邀请反馈（审批） → ⑥ 引导企业版/LeapCore → ⑦ 台账跟进
  • 交付结果：付费用户跟进台账（每个付费用户的类型判定、联系记录、反馈、赠送额度、转化结果）
  • 状态依据：2026-06～08 付费用户由产品负责人在后台手动发现后临时指派；跟进人看不到手机号与充值信息需逐次申请；无台账与话术，挽留额度无审批记录

1. 场景判定

  • 触发条件：后台出现新充值订单；付费用户连续 14 天未使用（建议口径）；单个用户充值金额较高
  • 典型说法：「有几个用户充了不少，要不单独联系下」「能不能把用户手机号和充值情况给我」「送点额度挽留一下」
  • 判断问题：用户是否为 C 端自助充值用户？是否需要人工联系？
  • 不归本流程管：企业客户合同 → 请走 LEG-03（销售合同审查与多方会签）；回款跟进 → 请走 FIN-21（收入合同台账、回款跟进与收入确认）；额度调整执行 → 请走 OPS-09；客诉与退款 → 请走 X-CS-05（客户问题受理、分流与工单流转）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
建联人 判定用户类型、联系、收集反馈、维护台账 R 用户运营建联（当前：王满·推断待确认）
发起/指派 定跟进优先级、反馈转需求 A 产品负责人（当前：杨萌·推断待确认）
数据查询 提供充值记录与用户信息 C 后端研发（当前：陈锦杰·推断待确认）
权限开通 为建联人开通后台最小必要查看权限 C 后台研发（当前：宋祺睿·推断待确认）
销售承接 有企业需求的用户转企业版/LeapCore R 销售总监（当前：吴琪·推断待确认）
额度审批 挽留/奖励额度审批 A（升级） CTO（当前：丁震宇·推断待确认）
运营负责人 兜底与周度复核 I 运营负责人（当前：李宣昊·推断待确认）

3. 办之前请准备

  • 用户 ID、充值时间与档位、使用记录（从后台查看，不在群里转发手机号）
  • 是否疑似竞品调研（注册信息、使用行为）
  • 联系话术与赠送额度标准
  • 企业版/LeapCore 介绍材料

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 充值/放弃事件触发机器人推送到运营群并写入台账 系统 实时 / 每日 10:00 飞书机器人/多维表格 待跟进记录 🤖自动化
2 建联人在后台查看用户信息（最小权限，权限一次性开通） 建联人 推送后 1 个工作日内 管理后台 用户画像 🔧+👤
3 判定类型：真实付费 / 疑似调研 / 放弃 建联人 推送后 1 个工作日内 台账 类型标签 👤人工判断
4 首次联系，按话术了解用途、邀请反馈 建联人 推送后 2 个工作日内 电话/微信 联系记录 👤人工判断
5 真实付费用户赠额度、放弃用户送额度挽留，提交审批后执行 建联人 + 额度审批 联系后 1 个工作日内 飞书审批/后台 赠送记录 🔧飞书固化
6 有企业需求的用户转销售承接 销售承接 转交后 2 个工作日内联系 CRM/台账 商机记录 👤人工判断
7 反馈整理入反馈表，转产品 建联人 联系后 1 个工作日内 多维表格 反馈记录（转 OPS-16） 🔧飞书固化
8 每周复核台账：联系率、转化、复购 运营负责人 每周一 多维表格 周度复核 🤖+👤

5. 交付物与模板

  • 交付物：付费用户跟进台账、赠送额度审批记录、反馈记录、周度复核
  • 建议模板/表单：付费用户跟进台账（用户 ID、产品线、充值时间、档位、类型、建联人、首次联系时间、反馈摘要、赠送额度、审批单号、是否转销售、当前状态）

6. 异常与升级

  • 产品负责人为本流程唯一负责人（A）；CTO 作为 A（升级）的条件：需要给付费或流失用户赠送挽留/奖励额度时，由建联人提交审批，CTO 1 个工作日内审批后执行
  • 建联人无后台查看权限 → 申请最小权限 → 升级权限开通人（1 个工作日内）
  • 2 个工作日内未联系 → 台账标红提醒 → 升级产品负责人（第 3 个工作日）
  • 用户投诉或要求退款 → 转 X-CS-05 → 升级运营负责人（当天）
  • 疑似竞品调研 → 不赠额度、仅记录 → 告知产品负责人（当天）

7. 衡量指标

  • 首次联系时长：充值到首次联系，目标 ≤ 2 个工作日
  • 付费用户联系率：已联系 / 新增付费用户，目标 100%
  • 挽留成功率：放弃用户 30 天内重新使用的比例
  • 复购率：付费用户 60 天内再次充值的比例

8. 低效诊断

  • 现象：付费用户靠人工翻后台发现，再临时指派，无自动提醒｜依据：「字字可研项目群」2026-07
  • 现象：跟进人看不到手机号与充值信息，需逐次找研发查询与开权限，首次联系被拖延｜依据：「字字可研项目群」2026-07
  • 现象：真实付费用户反馈价值高，但无台账与话术沉淀｜依据：「字字可研项目群」2026-06
  • 现象：挽留赠送额度靠群里口头决定，无审批与记录｜依据：「字字可研项目群」2026-08

9. 分支变体

  • 真实付费：赠额度 + 邀请深度反馈 + 引导企业版/LeapCore
  • 疑似竞品调研：只记录不赠送
  • 放弃用户：送额度挽留，30 天后复查

10. 待确认问题

  • 付费用户建联由谁长期负责（运营岗还是业务专家）？
  • 建联人可查看的用户字段范围如何界定？是否需要数据安全审批？
  • 赠送/挽留额度标准与审批人？
  • "放弃用户"的判定口径（14 天未使用）是否合适？
OPS-16用户反馈收集与归集待优化54

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨3 × 险2

  • 适用场景：用户在产品群、用户群、客服渠道反馈问题或 Bug，需要自动或人工汇总进多维表格并流转给产品/研发时启动
  • 负责人：主责——产品运营（当前：杨黔昆·推断待确认）；协同——反馈工具提供（当前：王皓南·推断待确认）、工具打包（当前：宋祺睿·推断待确认）、需求读取（当前：马漳毓·推断待确认）、飞书权限管理员（当前：待指定）；兜底——产品负责人（当前：杨萌·推断待确认）
  • 核心流程：① 固定反馈机器人入群并开权限 → ② 每日定时抽取群消息 → ③ AI 识别反馈、去重、打标签 → ④ 写入反馈表 → ⑤ 人工确认分级 → ⑥ 转需求/Bug 工单 → ⑦ 周报与回复用户
  • 交付结果：每日更新、已去重分级的用户反馈多维表格，每条反馈有处理状态与去向（需求/Bug/不处理），以及每周反馈周报
  • 状态依据：已有反馈表、feedback-harvester skill、飞书 CLI 拉取工具和机器人，但 2026-05 仍在手动整理数百条聊天记录，机器人因无群历史权限失败，未稳定运行

1. 场景判定

  • 触发条件：用户群/产品群出现问题描述、Bug、建议；用户访谈、客服记录需要归档
  • 典型说法：「把最近的反馈加入表格」「每满五个反馈触发强制查看，强制汇总到工作台」
  • 判断问题：这条信息是用户对产品的问题或建议吗？是否需要进入需求/Bug 池？
  • 不归本流程管：已确认的 Bug 修复 → 请走 RND-03（缺陷提报、复现、分级与指派）；需求评审排期 → 请走 X-PRD-09（需求提报登记与需求池管理）；付费用户回访 → 请走 OPS-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈负责人 每日确认分级、转工单、出周报 R 产品运营（当前：杨黔昆·推断待确认）
工具提供 维护 feedback-harvester skill 与抽取规则 C Leap 研发（当前：王皓南·推断待确认）
工具打包 飞书 CLI/拉取工具打包与部署 C 后台研发（当前：宋祺睿·推断待确认）
需求读取 读取反馈并承接相关需求 I 研发（当前：马漳毓·推断待确认）
权限管理 为反馈机器人开通群消息读取权限 C 飞书管理员（当前：待指定）
兜底 反馈优先级争议裁决 A 产品负责人（当前：杨萌·推断待确认）

3. 办之前请准备

  • 需要采集的群清单（产品群、用户群、客服群）
  • 反馈机器人已入群并获得群消息读取权限
  • 反馈表字段与标签体系（产品线、模块、类型、严重度）
  • 抽取 skill 与定时任务配置

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新群建立时拉入固定反馈机器人，申请群消息读取权限 反馈负责人 + 权限管理 建群后 1 个工作日内 飞书开放平台 权限开通记录 🔧飞书固化
2 每日 09:00 定时抽取前一日群消息 系统 每日 09:00 机器人/CLI 定时任务 原始消息 🤖自动化
3 AI 识别反馈、去重、打标签，写入反馈表 系统 每日 09:30 前 skill/多维表格 待确认反馈 🤖自动化
4 人工确认：是否有效、严重度、去向 反馈负责人 每日 12:00 前 多维表格 已分级反馈 👤人工判断
5 P0/P1 问题当即转 Bug 工单并通知研发；建议类进需求池 反馈负责人 确认后 2 小时内 工单系统 工单链接 🔧飞书固化
6 待确认反馈累计满 5 条触发提醒，强制汇总 系统 实时 机器人 提醒消息 🤖自动化
7 处理结果回写反馈表并在群内回复用户 反馈负责人 工单关闭后 1 个工作日内 多维表格/群 闭环记录 🔧飞书固化
8 每周一出反馈周报（数量、分类、Top 问题、处理率） 系统 + 反馈负责人 每周一 12:00 前 AI 周报 反馈周报 🤖自动化

5. 交付物与模板

  • 交付物：用户反馈多维表格、反馈周报、工单链接
  • 建议模板/表单：反馈表（反馈时间、来源群/渠道、产品线、模块、原文摘要、类型 Bug/建议/咨询、严重度、是否重复、去向、工单链接、处理状态、回复用户时间、确认人）

6. 异常与升级

  • 机器人无群消息权限 → 申请开通 → 升级飞书管理员（1 个工作日内）
  • 定时抽取失败 → 手动补跑 → 升级工具提供人（当天）
  • P0 问题（大面积不可用、数据丢失） → 不等日抽取，直接转研发 → 升级研发负责人（30 分钟内）
  • 单日反馈过多导致 AI 上下文溢出 → 分群分批抽取 → 告知工具提供人（当天）

7. 衡量指标

  • 反馈入表时效：用户发出到入表，目标 ≤ 1 个工作日
  • 反馈确认率：当日入表反馈当日确认的比例，目标 100%
  • 闭环率：已回复用户的反馈 / 有效反馈，目标 ≥ 90%
  • 人工整理耗时：每日人工处理时间，目标 ≤ 30 分钟

8. 低效诊断

  • 现象：反馈靠人工逐条填表或手动整理数百条聊天记录，耗时且易遗漏｜依据：「LeapPPT」2026-05
  • 现象：机器人未开群聊历史权限，自动采集失败，改为本地安装工具拉取，方案未固定｜依据：「LeapPPT」2026-05
  • 现象：是否需要专门建群采集、由谁负责收集存在分歧｜依据：「鼎慧产研决策部」2026-05
  • 现象：一次性处理消息量过大，AI 上下文不足｜依据：「LeapPPT」2026-05

9. 分支变体

  • 群消息：机器人每日抽取
  • 客服机器人 / 企业微信客服：导出后同表归集
  • 用户访谈：访谈人手动录入，标注来源"访谈"
  • 跨群采集：需逐群开通权限

10. 待确认问题

  • 反馈负责人是否为产品运营岗？各产品线是否分别指定？
  • 固定使用哪个机器人？群消息读取权限由谁审批（是否涉及安全合规）？
  • feedback-harvester skill 是否已部署为定时任务？
  • 反馈严重度分级标准是否与 Bug P0/P1 定级一致？
OPS-17运营数据需求、看板与统计口径待优化144

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：产品、运营、管理层或俱乐部业务方需要用户使用、成本、额度、订单等运营数据（一次性取数、固定看板、每日推送、月度导出）时启动
  • 负责人：主责——数据与后台研发（当前：宋祺睿·推断待确认）；协同——指标口径审定（产品负责人，当前：杨萌·推断待确认）、遥测研发（当前：邓乾·推断待确认）、管理后台研发（当前：柯逸飞·推断待确认）、跃竞后端/前端（当前：张楠、陈真炎·推断待确认）、跃竞运维（当前：席博田·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 表单提需求 → ② 查指标字典/已有看板 → ③ 确认口径 → ④ 取数或开发看板 → ⑤ 需求方核对 → ⑥ 交付归档 → ⑦ 重复需求固化为定时报表/机器人推送
  • 交付结果：口径明确、标注环境的数据结果（表格/看板/每日推送）及更新后的指标字典条目
  • 状态依据：已部署 OpenPanel/PostHog 遥测、ClickHouse 和管理后台，但 2026-02～10 反复出现“真实用户与测试账号分不开”“token 成本靠手写 SQL”“俱乐部订单每月人工导出”，口径与交付方式不固定，约 20 次相关讨论

1. 场景判定

  • 触发条件：需要注册数、活跃用户、报告生成数、真实用户数、token 成本、额度消耗、埋点事件、问卷与续费意愿，或某俱乐部某月订单/接单/会费收益统计
  • 典型说法：「遥测数据需要包一层给我用户使用的数据」「能不能接个机器人每天在群里推送用户数据」「现在的用户统计看不出来真实用户数据」「需要导出一份某俱乐部 9 月陪玩接单统计表」
  • 判断问题：要的是“数据结果”还是“新功能”？一次性还是会重复？时间范围、是否剔除内部/测试账号、查询哪个环境说清了吗？
  • 不归本流程管：用户反馈与 bug 汇总 → 请走 OPS-16；模型成本价与计价倍率维护 → 请走 FIN-28；生产库访问权限 → 请走 X-SEC-18；批量导出聊天记录/CRM 等敏感数据 → 请走 X-SEC-35；渠道 UTM 链接生成 → 请走 OPS-12；俱乐部客户反馈查数排障 → 请走 X-CS-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据执行 受理、取数/SQL、看板与推送开发、归档 R 数据与后台研发（当前：宋祺睿·推断待确认）
口径审定 定义并确认指标口径、维护指标字典 A 产品负责人（当前：杨萌·推断待确认）
需求方 提需求、说明用途、核对结果 C 运营/产品/业务需求方（当前：段涵、徐莉·推断待确认）
遥测与埋点 遥测部署、埋点事件、管理后台统计页 C 遥测研发（当前：邓乾·推断待确认）；管理后台研发（当前：柯逸飞·推断待确认）
跃竞数据导出 俱乐部订单导出、导出超时处理 R（分支） 跃竞后端（当前：张楠·推断待确认）；跃竞前端（当前：陈真炎·推断待确认）；跃竞运维（当前：席博田·推断待确认）
管理层 看板使用者、优先级裁定 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 用途：这份数据支持什么决策（定价、折扣、跟进客户、汇报）
  • 指标名称与定义；若字典里没有，写清计算方式
  • 时间范围与粒度（日/周/月）
  • 对象范围：产品线/主体/俱乐部；是否剔除内部与测试账号
  • 环境：生产或测试（默认生产只读）
  • 交付形式与频率：一次性表格 / 看板 / 每日推送 / 月度报表
  • 期望日期；是否含手机号等敏感字段（含则需脱敏）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用飞书表单提交取数/看板需求 需求方 需要前至少 2 个工作日 飞书表单 → 多维表格 需求单 🔧飞书固化
2 查指标字典与已有看板，能自助的直接回链接 数据执行 提交后 4 个工作小时内 指标字典、PostHog/OpenPanel、管理后台 受理或回复 🤖+👤
3 确认口径：指标定义、内部账号剔除、环境、额度计算规则；新指标报口径审定 数据执行 → 口径审定 受理后 1 个工作日内 多维表格 口径确认记录 👤人工判断
4 取数或开发：只读账号查询；需生产库按 X-SEC-18 申请；大批量导出走异步任务 数据执行 / 跃竞后端 一次性取数 2 个工作日内；看板按排期 ClickHouse、只读库、管理后台 数据文件/看板 🤖自动化
5 核对口径与抽样数据 需求方 收到后 1 个工作日内 — 验收结论 👤人工判断
6 交付归档：文件存云盘，需求单回填链接与 SQL/脚本，标注环境 数据执行 验收当日 多维表格、飞书云盘 归档记录 🔧飞书固化
7 同类需求 30 天内第 2 次出现即固化为定时报表或机器人推送 数据执行 第 2 次出现后 5 个工作日内 飞书机器人、定时任务 自动报表 🔧+🤖
8 巡检推送数据与后台一致性，下线无人看的看板 口径审定 每月首个工作周 多维表格 巡检记录 👤人工判断

5. 交付物与模板

  • 交付物：数据文件或看板链接（标注口径版本与环境）、每日数据推送、月度俱乐部统计表、指标字典
  • 数据需求单字段：需求编号、需求方、产品线/主体、用途、指标、时间范围、对象范围、是否剔除内部账号、环境、交付形式、频率、期望日期、敏感字段、执行人、状态、交付链接、SQL/脚本位置
  • 指标字典字段：指标名、业务定义、计算公式、数据源（表/事件）、剔除规则、更新频率、口径审定人、启用日期、版本
  • 每日推送内容（建议）：新增注册、活跃用户、报告生成数、token 消耗与成本、额度消耗，均剔除内部账号
  • 俱乐部月度统计表字段：俱乐部、月份、订单数、接单数、收入、会费收益、导出时间、数据环境

6. 异常与升级

  • 后台导出超时（数万条订单 30 秒内导不完）→ 研发改异步导出或运维临时调超时 → 1 个工作日未解决升级研发负责人
  • 查询环境不明（AI 助手默认连测试库）→ 交付物必须标注环境；发现用错库当天重出并通知使用方
  • 遥测数与后台数不一致 → 以指标字典为准；字典未定义的由口径审定 2 个工作日内裁定
  • 需要直连生产库 → 走 X-SEC-18 审批，不得在群里直接传库信息
  • 需求排期被挤压超过 5 个工作日 → 需求方报研发负责人裁定优先级
  • 管理层临时紧急 → 当日出初版并注明“未校验”，次日补校验

7. 衡量指标

  • 取数周期：提交到交付的工作日，一次性需求目标 ≤ 2 个工作日
  • 重复需求固化率：月内重复 ≥ 2 次的需求中已自动化的比例，目标 ≥ 80%
  • 指标字典覆盖率：看板/推送中已登记字典的指标占比，目标 100%
  • 数据返工次数：因口径或环境错误重出的次数，每月目标 ≤ 1
  • 内部账号标记率：内部/测试账号已打标签的比例，目标 100%

8. 低效诊断

  • 现象：遥测原始事件与业务统计口径不同，需求方要求“再包一层”，同一数据二次加工｜依据：「Leap产研测」2026-05
  • 现象：遥测平台全英文且需代理访问，需求方无法自助查看｜依据：「Leap产研测」2026-05
  • 现象：后台无法区分真实用户与内部测试账号，统计失真；单篇报告 token 成本靠临时手写 SQL｜依据：「工程咨询产研」2026-02
  • 现象：每日数据推送需求提出后，因后台优先级排低、正式环境滞后迟迟未落地｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：看板做出来仍需再让 AI 解读，偏离“直观”目标，重复返工约 3 次｜依据：「Leap产研决策部」2026-10
  • 现象：俱乐部月度接单统计每月人工导出，后台导出超时，AI 助手查询环境不明｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10

9. 分支变体

  • Leap/鼎慧产品线：遥测（OpenPanel/PostHog）原始事件 vs 管理后台业务统计；全部用户 vs 指定客户用户
  • 工程咨询（字字可研）：token 成本与额度消耗口径（智能提取/智能解析是否计入项目创建）
  • 跃玩/跃竞：俱乐部按月订单、接单、会费收益导出，需求方为跃竞业务，执行为跃竞后端
  • 问卷与续费意愿：问卷由产品发放，结果并入数据需求单；管理驾驶舱类看板由管理层指定专人对接

10. 待确认问题

  • 主责是否为数据与后台研发？是否需要设专职运营数据岗？
  • 指标字典由产品负责人还是运营负责人审定？
  • 后台“内部/测试账号”标签是否已落地？
  • 每日推送用普通飞书机器人还是现有 AI 助手？权限边界如何？
  • 一次性取数 2 个工作日的时限是否可行？
  • 跃竞俱乐部月度统计能否改为每月 1 日自动生成？
  • PostHog 与 OpenPanel 是否统一为一套？
OPS-18内容运营选题审核与发布排期待优化54

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险2

  • 适用场景：LeapCore 等产品公众号、视频号、社群推文需要按周持续产出，进行选题、草稿、审核、排期发布与产出考核时启动
  • 负责人：主责——新媒体运营（当前：鲁周毅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、市场负责人（当前：许君·推断待确认）、新媒体执行（当前：徐沛、侯晨帆·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）
  • 核心流程：① 月度内容日历 → ② 收集选题 → ③ 每周选题会 → ④ 撰写草稿存草稿箱 → ⑤ 事实核对 → ⑥ 终审 → ⑦ 排期发布 → ⑧ 回填数据与周报考核
  • 交付结果：按排期发布的推文/视频；内容宣发排期表中每条内容有选题、负责人、审核人、发布时间和数据；每周运营周报
  • 状态依据：已有内容宣发排期表（多维表格）和运营周报格式，但 2026-06 指出公众号产出低效，2026-09 产品公众号累计原创仅个位数，市场与运营分工不清，产出无目标与考核

1. 场景判定

  • 触发条件：每周常规内容生产；产品有新功能、新案例、客户成果可发；管理层要求提高更新频次
  • 典型说法：「至少一周2篇推文我觉得没问题」「选题审过做草稿的先做成草稿保存账户上」「这些案例组合起来发个推文其实很合适」
  • 判断问题：这是常规排期内容还是突发事件稿？属于哪个账号/产品线？
  • 不归本流程管：内容具体制作规范 → 请走 BRD-08；事件型宣发稿、新闻稿 → 请走 BRD-09；视频制作与多版本审核 → 请走 BRD-11；新媒体周数据复盘细则 → 请走 BRD-10；对外口径与敏感词自查 → 请走 BRD-14；账号注册认证 → 请走 BRD-07；AI 资讯日报 → 请走 OPS-19；客户案例素材沉淀 → 请走 OPS-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内容负责人 内容日历、选题会、排期、发布、周报 R 新媒体运营（当前：鲁周毅·推断待确认）
审核人 选题审定、终稿审核、产出考核 A 运营负责人（当前：李凯·推断待确认）
新媒体执行 撰稿、排版、视频剪辑、发布操作 R 新媒体执行（当前：徐沛、侯晨帆·推断待确认）
产品/研发 提供功能与案例素材，核对技术表述 C 产品负责人（当前：杨萌·推断待确认）；CTO（当前：丁震宇·推断待确认）
市场 提市场侧内容需求，对齐对外口径 C 市场负责人（当前：许君·推断待确认）
管理层 查看周报与产出 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 账号与产品线（LeapCore 公众号、视频号、社群等）
  • 本周产品更新、客户案例、行业热点清单
  • 内容宣发排期表（现有多维表格）
  • 品牌口径与话术库
  • 素材：截图、视频、客户授权（涉及客户时）
  • 上周发布数据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 出下月内容日历（每账号每周目标篇数） 内容负责人 每月 25 日前 多维表格 内容日历 🔧飞书固化
2 产品、市场、销售向选题池提交素材与选题 各方 每周三 18:00 前 飞书表单 选题池 🔧飞书固化
3 选题会确定本周选题、执行人、发布时间 内容负责人 + 审核人 每周四，30 分钟 飞书会议 选题清单 👤人工判断
4 撰写草稿，AI 辅助初稿与排版，存公众号草稿箱 新媒体执行 发布前 2 个工作日 公众号后台、排版 skill 草稿 🤖自动化
5 事实核对：功能、数据、客户授权 产品/研发对接人 收到后 1 个工作日内 飞书文档评论 核对意见 👤人工判断
6 终审，排期表状态改为“待发布” 审核人 发布前 1 个工作日 排期表 审核通过 👤人工判断
7 定时发布并同步分发到社群、视频号 新媒体执行 按排期 公众号/视频号/社群 发布链接 🔧飞书固化
8 发布后第 3 天回填阅读、转发、涨粉数据 新媒体执行 发布后第 3 天 多维表格 数据记录 🤖自动化
9 周报：产出 vs 目标、数据、下周计划 内容负责人 每周五 18:00 前 周报模板 周报 🔧飞书固化

5. 交付物与模板

  • 交付物：已发布内容、完整的排期表记录、每周运营周报
  • 排期表字段：编号、账号、产品线、选题、内容类型（推文/视频/案例）、素材来源、执行人、审核人、草稿完成时间、审核状态、计划发布时间、实际发布时间、链接、阅读、互动、涨粉、备注
  • 周报格式：本周产出数/目标、数据摘要、问题、下周选题（沿用运营组周报格式，不写废话）

6. 异常与升级

  • 本周产出未达目标 → 周报写明原因 → 运营负责人下周一前定补救安排
  • 连续 2 周选题池无产品素材 → 内容负责人找产品负责人 → 仍无则升级 CEO
  • 审核超 1 个工作日 → 机器人提醒 → 运营负责人代审
  • 内容涉及技术能力、数据承诺有争议 → 暂缓发布 → 按 BRD-14 核对口径
  • 市场与运营需求冲突或互相推诿 → 运营负责人与市场负责人 1 个工作日内协商 → CEO 裁定

7. 衡量指标

  • 周产出达成率：实际发布篇数 / 目标篇数，目标 ≥ 100%
  • 按期发布率：按排期日发布的比例，目标 ≥ 90%
  • 审核周期：草稿完成到终审通过的工作日，目标 ≤ 1 天
  • 内容效果：单篇平均阅读与互动，按月观察趋势
  • 排期表完整率：字段填写完整的条目占比，目标 100%

8. 低效诊断

  • 现象：产品公众号长期仅少量原创，缺少产出目标与考核机制｜依据：「Leap产研决策部」2026-09
  • 现象：市场提出内容需求后运营无法承接，需求方自行制作，市场与运营分工不清｜依据：「Leap产研决策部」2026-09
  • 现象：视频内容质量不达预期，现有制作方式效率低，未用 AI 工具提效｜依据：「Leap产研决策部」2026-09
  • 现象：公众号排版低效、浪费人力｜依据：「【模态】运营组」2026-06
  • 现象：内容与分发载体不匹配｜依据：「【模态】运营组」2026-06
  • 现象：可发的客户案例散落在产研群，没有进入选题池｜依据：「Leap产研决策部」2026-10

9. 分支变体

  • 公众号推文：走完整选题-草稿-审核-排期
  • 视频号/短视频：制作环节按 BRD-11，排期与考核仍在本流程
  • 社群内容：可简化审核，由内容负责人自审
  • 案例推文：素材来自 OPS-20 案例库，需确认客户授权
  • 不同产品线账号（LeapCore、模态等）分别设目标篇数

10. 待确认问题

  • 主责是否为新媒体运营？运营负责人是谁（报送口径与实际执行人不一致）？
  • 每账号每周 2 篇是否作为考核目标？
  • 市场与运营的内容边界如何划分？
  • 排期表是否沿用现有多维表格？
  • 公众号排版 skill、热点抓取机器人是否已可用？
  • 选题会频次与时长是否合适？
OPS-19AI 资讯日报生成与社群分发待优化36

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨3 × 险2

  • 适用场景：每天定时采集 AI 新闻、社交媒体、RSS、公众号信源，生成 AI 大事件日报，推送内部飞书群和对外社群（开源聚变 AI 社区），并归档往期、安排发布人 AB 角时启动
  • 负责人：主责——日报发布人（新媒体运营）（当前：鲁周毅·推断待确认）；协同——信源与 skill 维护（当前：宋祺睿、丁震宇·推断待确认）、公众号订阅数据接口（当前：李凯·推断待确认）；兜底——运营负责人（当前：李凯·推断待确认）
  • 核心流程：① 维护统一信源清单 → ② 定时采集 → ③ AI 去重筛选分类出 Top 8～10 → ④ 人工抽检终审 → ⑤ 推送飞书群 → ⑥ 适配格式发微信社群 → ⑦ 自动归档 → ⑧ 每周按反馈调整规则
  • 交付结果：每日一期日报（飞书版 + 微信社群版）；可按日期/分类检索的往期归档表
  • 状态依据：2026-06 底已用 skill 自动抓取并每日发布，但 2026-07 内筛选机制、标题归属、格式和分发渠道反复调整，多人各建信源，往期难查；参照外部社区同类做法，单人发布易断更

1. 场景判定

  • 触发条件：每日固定发布时间；信源或筛选规则需调整；发布人请假、交接；社群成员要往期
  • 典型说法：「这个也作为社群运营的内容，每天在各个群里发吧」「主要是筛信息源和筛选机制」「看发到微信社群里怎么看起来方便」
  • 判断问题：这是行业资讯聚合类日更，而不是公司自有产品内容吗？
  • 不归本流程管：公司产品推文与排期 → 请走 OPS-18；社群拉新与成员管理 → 请走 OPS-14；开源社区整体运营 → 请走 ECO-08；对外口径敏感问题 → 请走 BRD-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发布人 A 角 抽检终审、发布、收反馈 R 新媒体运营（当前：鲁周毅·推断待确认）
发布人 B 角 A 角缺席时顶岗 R 新媒体运营（当前：待指定）
信源与 skill 维护 采集 skill、信源站点、机器人 C 研发（当前：宋祺睿、丁震宇·推断待确认）
数据接口 公众号订阅数据接口 C 运营（当前：李凯·推断待确认）
运营负责人 标题署名口径、规则审定、断更兜底 A 运营负责人（当前：李凯·推断待确认）
社群运营要求方 提出分发范围要求 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 统一信源清单（RSS、X、公众号、Hacker News 等）与去重规则
  • 采集 skill / 日报机器人可用（rss-digest Skill 文档）
  • 分类模板：算力 / 模型 / 监管 / 资本等
  • 日报标题与署名口径（当前为“开源聚变 AI 社区”）
  • 推送群清单（飞书群、微信社群）
  • 往期归档表与 AB 角排班表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 更新统一信源清单与去重规则 发布人 + 信源维护 每月首个工作周 多维表格 信源清单 🔧飞书固化
2 定时采集各信源 机器人 每日 7:00 rss-digest skill 原始条目 🤖自动化
3 AI 去重、打分、分类，生成 Top 8～10 草稿 机器人 每日 7:30 前 LLM 日报草稿 🤖自动化
4 人工抽检：删冷门/重复/不实条目，核对来源链接 发布人 每日 8:30 前，用时 ≤ 20 分钟 飞书 终稿 👤人工判断
5 推送内部飞书群（卡片/HTML 格式） 机器人 每日 9:00 前 飞书机器人 飞书版日报 🔧飞书固化
6 生成微信社群版（短摘要 + 链接，避免折叠）并发布 发布人 每日 10:00 前 微信社群 微信版日报 🤖+👤
7 归档到多维表格（日期、标题、分类、来源、链接） 机器人 发布同时 多维表格 往期库 🔧飞书固化
8 汇总反馈，调整信源与筛选规则 发布人 每周五 多维表格 规则更新记录 👤人工判断

5. 交付物与模板

  • 交付物：每日飞书版与微信版日报；往期归档表（带按分类、关键词检索的视图）
  • 日报模板：标题（统一署名）+ 日期 + 分类小节 + 每条（一句话摘要、来源、链接）
  • 归档表字段：日期、期号、条目标题、分类、摘要、来源、链接、是否被反馈、发布人
  • 信源清单字段：信源名、类型、地址、权重、维护人、启用状态、最近更新
  • AB 角排班表：日期、A 角、B 角、请假记录

6. 异常与升级

  • 机器人未出稿或采集失败 → B 角 8:30 手动跑 skill → 10:00 前仍未发布，群内说明延迟并报运营负责人
  • 发布人请假或交接 → 提前 1 个工作日交给 B 角；不允许断更超过 1 天
  • 已发布内容有错 → 当日发更正说明，在归档表标记
  • 涉及监管、政治等敏感内容或版权存疑 → 不入选；拿不准报运营负责人
  • 标题署名口径变更 → 运营负责人确认后统一改模板，当天生效

7. 衡量指标

  • 按时发布率：9:00 前完成飞书版的天数 / 应发天数，目标 ≥ 95%
  • 断更天数：每月目标 0
  • 抽检剔除率：人工删除条目 / AI 入选条目，用于评估筛选规则，按月观察
  • 社群互动：每期回复/转发数，按月观察
  • 往期可检索率：归档表与日报一致的期数占比，目标 100%

8. 低效诊断

  • 现象：信源与筛选机制未统一，多人各自另建信源站点和接口，重复建设｜依据：「模态AI探索小分队」2026-06、「模态AI探索小分队」2026-07
  • 现象：日报标题归属在内部品牌与社区品牌之间切换，口径不统一｜依据：「模态AI探索小分队」2026-07
  • 现象：冷门条目过多，飞书与微信格式反复调整｜依据：「模态AI探索小分队」2026-07
  • 现象：往期查找困难，需另建话题群补救｜依据：「模态AI探索小分队」2026-07
  • 现象（外部同类做法参考）：日报依赖单人发布，交接期断更、多次延迟，社区成员追问是否停更，往期缺检索入口｜依据：「奇绩校友飞书群」2026-03、「奇绩校友飞书群」2026-05

9. 分支变体

  • 内部飞书群版：卡片/HTML，可全自动推送
  • 微信社群版（开源聚变 AI 社区）：需人工适配折叠问题后发布
  • 信源差异：X、RSS、公众号分别设权重
  • 可选扩展（参考外部做法，待评估）：语音版日报、周度专题信号汇总

10. 待确认问题

  • 日报是否作为长期运营项目？工作日发还是每天发？
  • 统一署名用哪个品牌？
  • B 角由谁担任？
  • 微信社群发布能否自动化，合规上是否允许？
  • 转载摘要是否需要法务确认版权口径？
  • 现有多个信源站点是否合并为一套？
  • 运营负责人是谁（报送口径与实际执行人不一致）？
OPS-20客户案例沉淀与宣传待优化108

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：客户用产品做出可量化成果、交付满半个月需形成深度使用反馈，或销售/渠道推广缺少某行业案例时，启动案例发现、登记、量化、标杆培育与入库
  • 负责人：主责——销售运营（案例库管理）（当前：韩诗琪·推断待确认）；协同——各客户经理（当前：朱文瑜等·推断待确认）、案例包装（当前：丁震宇、闫登辉·推断待确认）、对外表述（当前：许君·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——市场销售负责人（当前：待指定）
  • 核心流程：① 发现即登记 → ② 交付 15 天自动催反馈 → ③ 量化效果 → ④ 判定可公开度并取得授权 → ⑤ 按模板成稿 → ⑥ 审核入库 → ⑦ 分发销售/市场 → ⑧ 月度盘点
  • 交付结果：案例库（多维表格）中审核通过的案例条目（行业、场景、效果数据、素材、可公开度、授权状态）；每月标杆案例清单
  • 状态依据：已有 LeapCore 客户案例在线表格和征集表单，但 2026-08～10 多次催交标杆案例，素材散在周报、文档、聊天，部分行业案例只能私下找人，能否对外口径不一，约 18 次相关讨论

1. 场景判定

  • 触发条件：群里出现客户用产品做出成果；客户交付满 15 天；销售/渠道需要某行业案例；月度标杆目标未完成
  • 典型说法：「发市场群，宣传案例」「谁去看看他花了多少钱，做个宣传案例」「有做过教育行业客户的吗，找案例」「每个销售半个月内必须拿出一个标杆客户」
  • 判断问题：是外部客户的真实使用成果吗？还是内部员工的 AI 提效案例？
  • 不归本流程管：内部员工 AI 应用案例/场景征集 → 请走 OPS-21；案例转为对外推文、白皮书及授权核查发布 → 请走 BRD-15；推文排期 → 请走 OPS-18；客户演示准备 → 请走 SAL-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
案例库管理 登记、催办、审核入库、分发、月度盘点 R 销售运营（当前：韩诗琪·推断待确认）
标杆标准制定 定标杆标准、选重点培育客户 A CEO（当前：邴龙志·推断待确认）
客户经理 提交线索与使用反馈，取得客户授权 R 客户经理（当前：朱文瑜等各销售·推断待确认）
案例包装 把案例做成可演示/可传播的方案与素材 C 产研/销售（当前：丁震宇、闫登辉·推断待确认）
对外表述 审对外说法与可公开内容 C 市场负责人（当前：许君·推断待确认）
产品 提供用量、成本数据，演示材料建议 C 产品负责人（当前：杨萌·推断待确认）

3. 办之前请准备

  • 客户行业、规模、使用产品与版本（客户名称仅内部记录）
  • 使用场景与使用前做法、耗时
  • 效果数据：节省时间、成本、质量对比
  • 用量与花费（后台查询，按 OPS-17 申请）
  • 截图、录屏、演示材料
  • 客户联系人的反馈原话与授权意向

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现成果即填案例线索表（任何人都可提，客户经理补全） 客户经理 发现后 1 个工作日内 飞书表单 案例线索 🔧飞书固化
2 交付满 15 天自动提醒提交深度使用反馈 机器人 交付日 + 15 天 多维表格提醒 使用反馈 🔧飞书固化
3 量化效果：查用量、花费、节省时间 客户经理 + 产品 2 个工作日内 管理后台 效果数据 🤖自动化
4 每周从周报、群聊抽取案例草稿补充线索 案例库管理 每周一 AI 提取 案例草稿 🤖自动化
5 判定可公开度（仅内部 / 脱敏对外 / 实名对外），对外的取得客户书面授权 客户经理 3 个工作日内 授权确认单 授权记录 👤人工判断
6 按模板成稿（行业/痛点/方案/效果/素材） 案例包装 3 个工作日内 案例模板 案例稿 🤖+👤
7 审核入库，对外内容由对外表述把关 案例库管理 + 对外表述 2 个工作日内 多维表格 入库案例 👤人工判断
8 通知市场销售群；可对外的转 BRD-15 发布 案例库管理 入库当日 飞书群 分发通知 🔧飞书固化
9 月度盘点：标杆数 vs 目标、行业缺口、定向征集 案例库管理 每月最后一个工作日 多维表格 盘点结果 👤人工判断

5. 交付物与模板

  • 交付物：案例库条目、月度标杆清单、可对外案例包（转 BRD-15）
  • 案例库字段：案例编号、客户（内部名称）、对外代称、行业、场景、产品与版本、使用前做法、效果（时间/成本/质量）、用量与花费、素材链接、可公开度、授权状态与有效期、客户经理、包装人、审核人、入库日期、使用记录
  • 使用反馈报告模板：使用频次、主要场景、问题与建议、可量化效果、是否愿意做标杆

6. 异常与升级

  • 交付满 15 天未交反馈 → 机器人提醒 → 再过 3 个工作日升级市场销售负责人
  • 客户不同意公开 → 仅内部使用，标“仅内部”，不得对外引用
  • 某行业无案例 → 案例库管理 2 个工作日内发起定向征集；仍无则选重点客户培育
  • 案例数据夸大或与实际不符 → 退回客户经理，对外表述复核
  • 对外使用中授权到期 → 当日下架相关物料

7. 衡量指标

  • 月度新增入库案例数：目标待定（历史目标为每月 10 个标杆）
  • 行业覆盖：主要目标行业中有可用案例的比例，目标 100%
  • 反馈提交率：交付满 15 天按时提交反馈的客户比例，目标 ≥ 90%
  • 线索到入库周期：自然日，目标 ≤ 10 天
  • 授权完整率：对外使用的案例中授权齐全的比例，目标 100%

8. 低效诊断

  • 现象：案例靠群聊随手发现，无固定登记入口，线索容易流失｜依据：「鼎慧产研决策部」2026-08
  • 现象：渠道推广缺案例、场景、功能对比三类素材｜依据：「【模态】市场销售」2026-08
  • 现象：标杆案例目标靠反复催交，交付反馈填写不主动｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-09
  • 现象：知识库缺部分行业案例，只能在群里或私下找人问｜依据：「【模态】市场销售」2026-08
  • 现象：案例素材分散在周报、文档、聊天，是否可对外使用口径不一｜依据：「【模态】市场销售」2026-09
  • 现象：合作伙伴现场演示需求临时处理，后才改为视频 PPT 替代｜依据：「鼎慧产研决策部」2026-08

9. 分支变体

  • 客户标杆：选定重点客户培育，形成行业数字化标杆
  • 公司自用案例包装：公司内部使用成果包装为对外案例
  • 定制化项目案例：行业版/定制 SaaS 交付后包装
  • 合作伙伴演示材料：以视频 PPT 为主，深度演示另约

10. 待确认问题

  • 主责是否为销售运营？兜底的市场销售负责人是谁？
  • 每月标杆目标数是多少？
  • 交付后 15 天提交反馈的节点是否合适？
  • 客户授权书模板是否由法务出具？
  • 案例库与 BRD-15、知识库如何分工？是否合并为一个库？
  • 可公开度三级划分是否认可？
OPS-21内部 AI 应用场景与创意征集待优化90

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险2

  • 适用场景：推广 LeapAll/LeapCore 或推进全员 AI 化时，需要向全员征集 AI 提效场景、使用案例、开源 idea、产品缺口场景、外呼等专项需求，并评审、激励、落地时启动
  • 负责人：主责——产品负责人（征集统筹）（当前：杨萌·推断待确认）；协同——人事（当前：黄莹·推断待确认）、产品运营（当前：杨黔昆·推断待确认）、业务专家（当前：王满·推断待确认）、技术复现（当前：陈晖、王皓南·推断待确认）、学习委员（当前：陈梦琪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 征集立项（目的、标准、评审团、激励、截止）→ ② 激励规则审批 → ③ 统一入口发布 → ④ 收集与提醒 → ⑤ AI 初筛聚类 → ⑥ 评审打分 → ⑦ 公示与激励 → ⑧ 入选项转任务/skill/开源 → ⑨ 复盘
  • 交付结果：统一需求/创意池中带评审结论的征集结果；入选项对应的任务、skill 或开源立项；激励发放记录
  • 状态依据：2026-04～10 至少 7 次征集各自建问卷、各自汇总；评审团队、评选等级与奖励细则多次“后续发布”，流程相似但无统一入口

1. 场景判定

  • 触发条件：新产品推广需要场景；管理层要求业务部门提 AI 需求；需收集开源 idea、产品缺口、外呼等专项需求
  • 典型说法：「把你的场景描述提交至表单」「请每人至少提交 1 个已经实际使用、产生明确价值的案例」「发动一下全公司各个业务部门，提一些AI提效的需求」「现在先面向内部收集可参与开源的 idea」
  • 判断问题：征集对象是内部员工吗？是一次面向多人的批量征集，而不是单个需求？
  • 不归本流程管：外部客户案例 → 请走 OPS-20；总经办积分激励政策宣贯 → 请走 CEO-21；积分制度本身 → 请走 HR-18；开源 idea 入选后的孵化 → 请走 ECO-09；内部分享与学习活动 → 请走 GEN-07；内部 AI 赛事 → 请走 ECO-15；用户日常反馈/bug → 请走 OPS-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
征集统筹 立项、发布、组织评审、公示、转化落地 R 产品负责人（当前：杨萌·推断待确认）
批准人 批准征集主题与激励预算，裁定争议 A CEO（当前：邴龙志·推断待确认）
激励与调研 激励规则、积分/奖金发放、员工调研 C 人事负责人（当前：黄莹·推断待确认）
问卷与汇总 维护需求池、提醒、汇总 R 产品运营（当前：杨黔昆·推断待确认）
评审团 评分、判断可实现性、复现验证 C 业务专家（当前：王满·推断待确认）；技术（当前：陈晖、王皓南·推断待确认）
学习推进 学习小组、内部分享衔接 C 学习委员（当前：陈梦琪·推断待确认）
FDE 团队 缺口场景补齐 C FDE（当前：待指定）
全员 提交 I 全体员工

3. 办之前请准备

  • 征集目的、类型、提交标准（如“已实际使用、产生明确价值”）
  • 评审维度与权重：频次、节省工时、可实现性、可复制性
  • 激励规则与预算（发布前必须已批）
  • 评审团名单（3～5 人，写明姓名）
  • 截止时间（至少留 7 天）
  • 查需求池：近 30 天是否已有同类征集

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填征集立项卡（类型、目的、标准、评审团、激励、截止） 征集统筹 发布前 3 个工作日 多维表格 立项卡 🔧飞书固化
2 激励规则与预算审批 人事 → CEO 发布前 1 个工作日 飞书审批 已批规则 👤人工判断
3 在通知群发布，统一使用需求/创意池表单（按类型分视图） 征集统筹 截止前至少 7 天 通知群、飞书表单 征集通知 🔧飞书固化
4 截止前 2 天提醒未提交人员 机器人 截止前 2 天 飞书机器人 提醒 🤖自动化
5 AI 初筛：去重、聚类、可实现性初判 问卷与汇总 截止后 2 个工作日内 AI + 多维表格 初筛表 🤖自动化
6 评审打分，不确定能否实现的由技术复现验证 评审团 截止后 5 个工作日内 多维表格 评分结果 👤人工判断
7 公示结果，按积分制度发放激励 征集统筹 + 人事 评审后 3 个工作日内公示 通知群 公示与发放记录 🔧飞书固化
8 入选项转化：建任务定负责人；skill 上架并署名作者；开源 idea 转 ECO-09；缺口场景交 FDE 征集统筹 公示后 5 个工作日内 飞书任务 落地任务 🔧飞书固化
9 结项复盘：参与率、落地数、问题 征集统筹 结项后 2 周内 飞书文档 复盘 👤人工判断

5. 交付物与模板

  • 交付物：需求/创意池（含评审结论）、公示名单、激励发放记录、落地任务清单、复盘
  • 需求/创意池字段：编号、征集批次、类型（场景/案例/开源 idea/缺口/外呼等）、提交人、部门、场景描述、当前做法与耗时、期望效果、是否已实际使用、频次、预计节省工时、AI 初判、评分、结论、落地负责人、关联任务/skill、激励、状态
  • 征集立项卡字段：批次名、发起人、目的、类型、提交标准、评审团、评分维度、激励规则、预算审批号、发布日、截止日

6. 异常与升级

  • 激励规则未批 → 不得发布征集
  • 截止前 2 天提交率低于 30% → 部门负责人督促并可延期 3 天 → 仍低报 CEO
  • 30 天内同类征集重复发起 → 合并进已有批次
  • 入选项公示后 30 天未落地 → 征集统筹在周会说明原因 → CEO 决定继续或撤销
  • 激励争议 → 人事 5 个工作日内复核 → CEO 拍板

7. 衡量指标

  • 参与率：提交人数 / 应参与人数，目标 ≥ 60%
  • 落地率：入选项 30 天内转为任务/上线的比例，目标 ≥ 70%
  • 征集周期：发布到公示的自然日，目标 ≤ 15 天
  • 重复征集次数：每季度目标 0
  • 激励按时发放率：公示后按制度时限发放的比例，目标 100%

8. 低效诊断

  • 现象：一年内多次征集各自建问卷、各自汇总，无统一需求池，信息孤岛｜依据：「模态跃迁通知群」2026-05、「模态跃迁通知群」2026-08、「模态跃迁通知群」2026-10
  • 现象：奖励细则与评选等级“后续发布”，属事后补规则，影响积极性｜依据：「跃迁AI总动员」2026-05、「模态跃迁通知群」2026-08
  • 现象：评审团队成员未公布，评审环节职责不清｜依据：「跃迁AI总动员」2026-05
  • 现象：各人各自搭 skill，实用场景缺少共享与沉淀｜依据：「跃迁AI总动员」2026-05
  • 现象：研发“拿着锤子找钉子”，业务部门需求输入不足｜依据：「【跃迁】高管群」2026-04
  • 现象：学习委员/学习小组角色反复任命，推进职责不清｜依据：「【跃迁】高管群」2026-04

9. 分支变体

  • 场景大赛：有奖金，需预算审批
  • 全员 AI 案例征集：积分激励，按 HR-18 发放
  • 开源 idea：入选后转 ECO-09
  • 产品缺口/反馈收集：入选后交产品需求池或 FDE 补齐
  • 专项需求（如外呼/传呼系统）：征集后直接进入产品需求评审
  • 补贴调研、海外 AI 产品调研：仅收集不评奖

10. 待确认问题

  • 统一需求/创意池归产品还是总经办管？
  • 本流程是否与 CEO-21 合并？
  • 是否设固定评审团？名单是谁？
  • 场景大赛的奖金预算由谁审批？
  • 入选 skill 是否统一上架商城并回馈作者？
  • 每年征集次数是否需要控制（如每季度一次集中征集）？
OPS-22社区冷启动内容填充与汇报演示准备待新建128

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：OPC/智能涌现/开源聚变社区或官网上线初期板块为空，或领导演示、向主管政府部门汇报在即，需要批量准备种子内容（帖子、评论、活动、政策、Agent 样例）时启动
  • 负责人：主责——社区运营（当前：陈梦琪·推断待确认）；协同——内容生产（当前：李玄冰·推断待确认）、接口与脚本研发（当前：葛家和、吴世豪·推断待确认）、文案（当前：王皓南·推断待确认）、技术方向与 AI 预审（当前：丁震宇·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 按节点倒排计划 → ② 书面确定真实性边界与质量线 → ③ 采集真实内容 → ④ 生成并标注种子内容 → ⑤ AI 预审 + 人工抽检 → ⑥ 经接口上线 → ⑦ 演示前走查 → ⑧ 节点后回收或转正
  • 交付结果：节点前 2 个工作日完成填充并走查的社区/官网内容；种子内容台账（来源、标注、账号、回收计划）
  • 状态依据：2026-03 两次在汇报/演示前几天才临时拉人发帖、跟帖、造数；质量线口头约定，谁审未定；内容靠兼职和个人检索；群内已有“看着太假”的担忧，存在真实性与合规风险，未形成固定做法

1. 场景判定

  • 触发条件：社区/官网上线、领导演示、政府汇报、活动前，板块为空或数据不足
  • 典型说法：「麻烦大家帮忙跟帖认真评论下…等会儿去给领导演示需要个样例」「该填内容的抓紧填了」「看着真实就行」
  • 判断问题：内容用于对内演示（可生成但须标注），还是对外正式运营（必须真实）？
  • 不归本流程管：日常社区内容审核 → 请走 OPS-23；商家/厂商入驻 → 请走 ECO-07；开源社区长期运营 → 请走 ECO-08；政府汇报材料与对接 → 请走 CEO-17；演示环境冻结 → 请走 RND-61

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
社区运营 计划、组织生产、抽检、走查、回收 R 社区运营（当前：陈梦琪·推断待确认）
标准审定 真实性边界、质量线、最终放行 A CEO（当前：邴龙志·推断待确认）
内容生产 采集真实内容、批量生成种子内容 R 内容生产（当前：李玄冰·推断待确认）
接口与脚本 种子账号接口、评论填充脚本、导入与回收 C 研发（当前：葛家和、吴世豪·推断待确认）
文案 重点帖子文案 C 文案（当前：王皓南·推断待确认）
技术方向 AI 预审方案 C CTO（当前：丁震宇·推断待确认）
法务 真实性与合规意见 C 法务（当前：待指定）

3. 办之前请准备

  • 节点日期、受众（内部领导 / 政府部门 / 公众）
  • 需要填充的板块与数量
  • 书面的真实性边界：哪些可生成、生成内容如何标注
  • 种子账号清单与导入接口文档（seed-api-guide）
  • 质量标准：最低分数线与示例
  • 真实素材来源：活动、政策（名称、时间、地点、主办方、链接）
  • 回收计划：节点后删除还是转为正式内容

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 节点确定后倒排内容计划 社区运营 节点前 10 个工作日 多维表格 内容计划 🔧飞书固化
2 书面确定真实性边界与质量线，法务给意见 CEO + 法务 节点前 8 个工作日 飞书文档 标准文件 👤人工判断
3 采集真实内容：活动、政策按统一字段整理，AI 辅助检索 内容生产 节点前 5 个工作日 AI 检索 + 采集模板 真实内容表 🤖自动化
4 本地批量生成种子帖/评论，标注“示例/演示” 内容生产 节点前 5 个工作日 LLM 草稿库 🤖自动化
5 AI 预审打分 + 人工抽检不少于 20% 社区运营 节点前 3 个工作日 AI 预审 合格内容 🤖+👤
6 经种子账号接口/管理端导入上线；不得直接改生产库，确需时走 X-SEC-18 接口与脚本 节点前 2 个工作日 种子接口、管理端 上线内容 🔧飞书固化
7 按演示路线走查，替换不合格内容 社区运营 节点前 1 个工作日 社区前台 走查记录 👤人工判断
8 节点后回收演示数据，或经审核转为正式内容 社区运营 + 接口与脚本 节点后 5 个工作日内 管理端 回收记录 🔧飞书固化

5. 交付物与模板

  • 交付物：填充完成的板块、种子内容台账、回收记录
  • 种子内容台账字段：编号、板块、类型（帖子/评论/活动/政策/Agent）、来源（真实采集/AI 生成）、是否标注、发布账号、AI 预审分、抽检结论、上线时间、回收计划、回收时间
  • 活动/政策采集字段：名称、时间、地点、主办方、原文链接、采集人、核实状态
  • 进度表：用多维表格维护任务、负责人、截止，自动生成甘特视图供汇报

6. 异常与升级

  • 节点前 5 个工作日内容量不足 → 缩小演示范围，只展示真实内容 → 报 CEO
  • 抽检低于质量线 → 不上线，退回重生成
  • 面向政府或公众的场景使用了生成内容 → 必须标注或撤下，法务当天给意见
  • 兼职人员产出质量差 → 社区运营当天更换，由内部人员顶上
  • 需要生产库造数 → 走 X-SEC-18 审批，禁止在群里直接传库信息

7. 衡量指标

  • 节点前完成率：节点前 2 个工作日完成填充的比例，目标 100%
  • 抽检合格率：抽检合格条目 / 抽检条目，目标 ≥ 90%
  • 演示数据回收率：节点后 5 个工作日内回收或转正的比例，目标 100%
  • 真实内容占比：真实采集内容 / 上线内容，按次观察，逐步提高
  • 临时拉人次数：节点前 3 天内全员拉人发帖的次数，目标 0

8. 低效诊断

  • 现象：汇报/演示前几天才补内容，临时拉全员发帖、跟帖｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：种子内容质量线口头约定，谁审未定｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：演示数据靠向开发要生产库直接造，缺少审批｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：造数方式失真（改时间、集中发布），群内担心被识破、社区沦为资讯搬运区｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：汇报催得急，进度表与甘特图要求当天出，内容靠兼职和个人检索，兼职质量差｜依据：「智能涌现社区官网设计」2026-01、「智能涌现社区官网设计」2026-03
  • 现象：资质申请用的演示页需真实合规信息，临时返工｜依据：「智能涌现社区官网设计」2026-02

9. 分支变体

  • 对内演示：可用 AI 生成，必须标注“演示数据”，节点后回收
  • 对外正式运营：只用真实用户内容和真实采集内容，种子用户靠激励规则引入
  • 官网内容填充：政策资讯支持 md 导入，活动按统一字段采集
  • 资质申请演示页：只能使用真实、合规信息

10. 待确认问题

  • 面向公众的社区是否允许上线 AI 生成内容？标注方式是什么？
  • 法务对“种子内容”的真实性意见是什么？
  • 种子账号数量与管理人是谁？
  • 节点后是回收还是转正，由谁决定？
  • 10 个工作日倒排是否可行？
  • 进度表是否统一用多维表格维护并自动生成汇报？
OPS-23社区内容与入驻信息审核待优化300

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频5 × 耗3 × 跨4 × 险5

  • 适用场景：OPC/智能涌现/开源聚变社区中用户发帖、评论、改名、自定义标签、发布智能体/共创需求/资讯，以及入驻厂商提交资料，进入审核队列需要合规审核与准入判定时启动
  • 负责人：主责——社区内容审核岗（当前：陈梦琪·推断待确认）；协同——社区研发（当前：裴建武·推断待确认）、配置与第三方审核接入（当前：葛家和、吴世豪·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、厂商对接（当前：杨朋伟、谢昕璟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 内容提交 → ② 机器初筛（敏感词库 + 语义审核，只拒不放）→ ③ 推送待审队列 → ④ 值班人工复核 → ⑤ 通过/拒绝并记录原因与审核人 → ⑥ 举报申诉处置 → ⑦ 厂商准入预审与终审 → ⑧ 每周迭代规则与词库
  • 交付结果：在时限内处理完毕、有审核人和理由记录的审核单；入驻厂商的准入结论；版本化的审核规则与敏感词库
  • 状态依据：已有阿里云内容审核、AI 自动审核开关和管理端待审列表，但 2026-03 测试连续发现绕过（空格、拼音、外语、链接），机器审核开关曾长期未开，谁审核、谁维护词库未定，约 50 次相关讨论；入驻准入标准仍在起草，缺负面清单

1. 场景判定

  • 触发条件：管理端待审列表出现新条目；用户举报或申诉；新厂商提交入驻资料；测试发现漏审或误杀
  • 典型说法：「先审后发就行了」「审核下我改名」「后台论坛开下机器审核」「得做个简单的审核端口」
  • 判断问题：内容是否已在本社区平台提交并进入审核？是内容合规审核，还是商家商务准入？
  • 不归本流程管：商家入驻协议、定价、供货等商务手续 → 请走 ECO-07；开放平台 Skill/插件上架审核 → 请走 ECO-06、X-PRD-20；AIGC 产品内容安全策略与 AI 生成标识 → 请走 LEG-20；演示用种子内容生产 → 请走 OPS-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审核值班 人工复核、举报申诉处置、记录原因 R 社区内容审核岗（当前：陈梦琪·推断待确认；B 角待指定）
规则与准入标准 审核红线、负面清单、准入标准审定 A CEO（当前：邴龙志·推断待确认）
审核功能研发 审核链路、版本校验、举报申诉、敏感词库接入 R 社区研发（当前：裴建武·推断待确认）
配置与开关 第三方审核配置、机器审核开关 C 研发（当前：葛家和、吴世豪·推断待确认）
测试 绕过测试、审核回归 C 测试（当前：张东郅、李国庆·推断待确认）
厂商对接 收集入驻资料、预审、通知修改 R 厂商/社区运营（当前：杨朋伟、谢昕璟·推断待确认）
法务 违规追责、境外模型等口径 C 法务（当前：待指定）

3. 办之前请准备

  • 书面审核规则：先审后发范围、红线清单、拒绝原因分类
  • 敏感词库当前版本
  • 审核值班表（工作时间与非工作时间）
  • 机器审核开关状态（管理端可见）
  • 入驻资料：入驻申请表、优秀智能体标准、模型来源与备案信息
  • 拒绝原因模板与申诉答复模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 机器初筛：敏感词库 + 大模型语义审核，命中即拒或转人工，机器不直接放行；含图片/视频一律转人工 系统 实时 第三方审核 + 词库 初筛结果 🤖自动化
2 待审条目推送审核群并 @值班 机器人 实时 飞书机器人 待审通知 🔧飞书固化
3 人工复核帖子、智能体、需求、资讯、改名；通过时校验内容版本 id，防止审核期间二次编辑 审核值班 工作时间 2 小时内；非工作时间次日 10:00 前 管理端 审核结论 👤人工判断
4 通过或拒绝，拒绝须选原因，系统记录审核人 审核值班 与第 3 步同时 管理端 审核记录 🔧飞书固化
5 举报处置（下架）与申诉复核（恢复或维持） 审核值班 举报 4 小时内；申诉 1 个工作日内 管理端 处置记录 👤人工判断
6 入驻厂商按准入清单预审，AI 预审材料 厂商对接 收齐资料后 3 个工作日内 多维表格 + AI 预审意见 🤖+👤
7 入驻终审（评审会或规则负责人），否决的通知修改后重审 规则与准入标准 每周汇总一次 飞书审批 准入结论 👤人工判断
8 每周复盘漏审、误杀、绕过案例，更新词库与规则版本 审核值班 + 审核功能研发 每周五 词库维护表 新版本规则/词库 👤人工判断

5. 交付物与模板

  • 交付物：审核记录、举报申诉处置记录、入驻准入结论、规则与词库版本
  • 审核规则表字段：内容类型、审核方式（机器/人工/机器+人工）、红线条目、拒绝原因代码、时限、版本、生效日期
  • 审核记录字段：内容 id、版本 id、类型、提交人、机器结论、人工结论、拒绝原因、审核人、审核时间
  • 入驻准入清单：模型来源（境内/境外）、备案情况、产品描述红线、优秀智能体标准达标项、负面清单、预审人、终审结论
  • 敏感词库维护表：词条、变体（空格/拼音/外语）、来源、添加人、添加日期

6. 异常与升级

  • 违规内容已上线 → 30 分钟内下架并留痕 → 当日报 CEO；涉及法律风险 → 法务
  • 测试发现新绕过方式 → 提 issue → 研发 2 个工作日内修复，修复前该类内容全部转人工
  • 误判争议（如含“禁止赌博”被拦）→ 规则负责人裁定，原则从严
  • 机器审核开关未开或第三方服务故障 → 全部转人工，研发当日恢复
  • 待审积压超 2 小时 → 机器人催办 → 超 4 小时升级 CEO
  • 厂商被评审专家一票否决 → 厂商对接当日通知修改描述，重新预审

7. 衡量指标

  • 审核时效：工作时间提交到审结的时长，目标 ≤ 2 小时
  • 漏审数：上线后被发现的违规内容数，每月目标 0
  • 误杀率：申诉成功数 / 拒绝数，按月观察
  • 绕过类缺陷修复周期：发现到修复的工作日，目标 ≤ 2 天
  • 入驻预审周期：收齐资料到预审意见的工作日，目标 ≤ 3 天

8. 低效诊断

  • 现象：审核能力弱，敏感词加空格、拼音、外语、链接均可绕过，同类问题连续多轮返工约 6 次｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：研发与测试对关键词误判是否应拦口径不一｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：敏感词库由谁维护、人工审核由谁做未定，审核通过后追问“谁审的”｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：机器审核开关在配置文件中需研发开启，曾长期未开；测试与运营反复请人“帮忙通过”约 15 次｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：删帖后后台无关联记录，三类内容各有一套审核后台｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：入驻准入标准仍在起草，境外模型是否可用无书面口径，厂商描述被一票否决后临时修改｜依据：「平台部」2026-02、「平台部」2026-04

9. 分支变体

  • 帖子：先审后发，机器初筛 + 人工复核
  • 评论/跟帖、自定义标签：以机器为主，命中转人工
  • 含图片/视频内容：一律人工
  • 用户改名：机器初筛 + 人工抽查
  • 智能体、开放需求、资讯：人工审核
  • 入驻厂商：准入清单预审 + 评审会终审
  • 现有社区、Agent、用户管理三套审核后台，待统一

10. 待确认问题

  • 审核岗与 B 角由谁担任？非工作时间如何值班？
  • 敏感词库用开源方案还是采购（火山/腾讯/阿里等）？
  • 2 小时审核时效是否可行？
  • 境外模型能否在平台使用？书面口径由谁出？
  • 三套审核后台是否统一？
  • 面向大学生的社区是否有额外审核要求？
OPS-24会员端活动上新、权益与积分配置待优化240

状态：待优化｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：合作俱乐部有新活动（节日、新赛季）需在会员端上新或换图，或要求增删会员权益、改兑换客服、上架积分商城商品、批量给老板加积分，以及策划共创/星耀计划等会员活动时启动
  • 负责人：主责——会员端产品经理（当前：陈雁·推断待确认）；协同——配置执行（当前：丁震宇·推断待确认）、后端（当前：王子明·推断待确认）、前端（当前：魏小东·推断待确认）、活动策划（当前：宫经喜·推断待确认）、俱乐部方运营对接人（外部）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 机器人卡片提报 → ② 产品经理确认边界与素材 → ③ 写入变更台账并建任务 → ④ 配置执行 → ⑤ 提报人验收 → ⑥ 卡片状态回写 → ⑦ 月度复盘
  • 交付结果：按截止时间上线并验收的活动页、权益、商城或积分变更；变更台账记录“原值—新值”、操作人和验收人
  • 状态依据：已有“弈荟活动更新需求”机器人卡片、权益与商城 wiki、飞书待办，但 2026-01～09 配置集中在单人，靠群里@和提醒，多次遗忘、深夜上新；管理后台与后端不一致需直接改库；出现权益漏项、剩余数量配错

1. 场景判定

  • 触发条件：机器人卡片提报活动更新或图片更换；权益或商城变更；俱乐部活动需批量加积分；会员活动策划
  • 典型说法：「三个活动更新」「晚上提醒我整」「商城兑换客服需要改成…」「需要批量给老板录入积分」「完善星耀计划公告、奖励规则、投稿流程」
  • 判断问题：变更对象是已上线俱乐部的会员端配置吗？现有后台能否完成，还是需要新开发？
  • 不归本流程管：新俱乐部入驻与会员体系初始配置 → 请走 X-CS-22、X-DLV-38；俱乐部反馈积分不同步、查数 → 请走 X-CS-23；对俱乐部的版本与规则公告 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）；需新增功能（如生成核销码）→ 请走 X-CS-14；生产库直接修改 → 请走 RND-58

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求对接 确认边界、补素材、建任务、组织验收 R 会员端产品经理（当前：陈雁·推断待确认）
项目负责人 优先级、截止、超时升级、预算 A 跃竞负责人（当前：徐莉·推断待确认）
配置执行 后台配置、积分导入 R 配置执行（当前：丁震宇·推断待确认；B 角待指定）
后端 导出客户表、改库、导入工具 C 跃竞后端（当前：王子明·推断待确认）
前端 会员端页面与后台页面问题 C 跃竞前端（当前：魏小东·推断待确认）
活动策划 共创/星耀计划方案、投稿审核、发奖 R（分支） 活动策划（当前：宫经喜·推断待确认）
俱乐部方 提报需求、提供名单与素材、验收 I 俱乐部运营对接人（外部）

3. 办之前请准备

  • 活动上新：俱乐部、活动名、描述、公众号链接、图片（规定比例与尺寸）、上线/下线时间
  • 权益与商城：会员等级、权益名称（同一俱乐部内唯一）、描述、数量、兑换客服、核销方式、原值→新值
  • 批量积分：从系统导出的客户表（客户编号、昵称、微信号），俱乐部方去重后加“加分值”和“原因”列
  • 活动策划：目标、预算、奖励规则、投稿审核人、发奖方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过机器人卡片提报，卡片自动写入变更台账 俱乐部方 / 需求对接 上线前至少 2 个工作日 飞书机器人 + 多维表格 变更单 🔧飞书固化
2 确认边界（只删还是挪等级、名称唯一、图片比例）并补齐素材 需求对接 提报后 4 个工作小时内 卡片 / 群 确认后的变更单 👤人工判断
3 指定执行人与截止，生成飞书任务 需求对接 与第 2 步同时 飞书任务 任务 🔧飞书固化
4 配置上线：优先后台自助；后台不支持需改库的，按 RND-58 记录 配置执行 截止前，工作时间内完成 管理后台 配置结果 🔧+👤
5 批量积分：导出客户表 → 俱乐部方填表去重 → 导入前出校验报告（不存在/重复）→ 导入 → 出对账表 后端 + 配置执行 收到合格名单后 1 个工作日内 Excel / 导入工具 导入与对账表 🤖自动化
6 验收：截图确认 需求对接 + 俱乐部方 上线后 1 个工作日内 会员端 验收记录 👤人工判断
7 点“已改完”，状态自动回写提报人并关闭台账 配置执行 / 系统 验收当日 机器人 关闭状态 🔧飞书固化
8 会员活动：立项模板（目标/预算/奖励/审核/复盘）走审批，投稿表单自动汇总，发奖对接财务 活动策划 活动开始前 10 个工作日立项 飞书审批、表单 活动方案与执行清单 🔧+👤
9 月度复盘：超时、错误、改库次数 需求对接 每月首个工作周 多维表格 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：上线并验收的配置、变更台账、积分导入对账表、活动方案与复盘
  • 变更台账字段：编号、俱乐部、变更类型（活动上新/换图/权益/商城/客服/积分/弹窗开屏）、内容、原值、新值、素材链接、提报人、提报时间、截止时间、执行人、执行方式（后台/改库）、完成时间、验收人、验收结果
  • 积分导入表字段：俱乐部编号、客户编号、昵称、微信号、加分值、原因（活动/中奖）、校验结果、导入结果
  • 活动立项模板：目标、时间、参与俱乐部、分工、预算、奖励规则、投稿审核人、发奖方式、风险、复盘

6. 异常与升级

  • 截止前 4 小时未完成 → 机器人提醒执行人 → 到截止仍未完成，升级跃竞负责人，并告知俱乐部方新时间
  • 配置执行人不在 → B 角接手；无 B 角时报跃竞负责人
  • 素材缺失（如图片未给）→ 不沿用旧图，退回提报人，计时暂停
  • 积分名单有不存在或重复的账号 → 校验报告返俱乐部方自查，确认后再导入；中奖名单对不上时重新导出比对
  • 配置错误影响兑换（漏项、数量错）→ 2 小时内修正并通知俱乐部方，当周复盘
  • 需求超出现有功能 → 转需求评审，告知俱乐部方预计周期
  • 奖励预算未批 → 不得对外公布奖励

7. 衡量指标

  • 按时上线率：截止前完成的变更 / 总变更，目标 ≥ 95%
  • 处理周期：提报到验收的工作日，目标 ≤ 2 天
  • 配置错误次数：每月目标 0
  • 直接改库次数：每月统计，逐月下降
  • 人工催办次数：群里@提醒次数，目标逐月下降
  • 积分导入一次通过率：目标 ≥ 95%

8. 低效诊断

  • 现象：卡片提报后仍需在群里@一次，卡片状态与实际上线不同步｜依据：「跃玩会员端」2026-03、「跃玩会员端」2026-04
  • 现象：配置集中于单一执行人，靠“晚上提醒”，多次遗忘，上新集中在深夜｜依据：「跃玩会员端」2026-04、「跃玩会员端」2026-06
  • 现象：图片缺失时沿用旧图｜依据：「跃玩会员端」2026-04
  • 现象：管理后台长期未更新与后端不一致，部分配置只能直接改库｜依据：「跃玩会员端」2026-07
  • 现象：权益同名不同描述、等级绑定混乱需返工改名；高等级权益漏项、剩余数量配错｜依据：「跃玩会员端」2026-08、「跃玩会员端」2026-09
  • 现象：批量积分无导入功能，名单多次导出核对，中奖名单与客户表不一致需再次导出｜依据：「跃玩会员端」2026-04、「跃玩会员端」2026-05
  • 现象：会员活动方向中途调整，奖励发放、投稿审核责任人与预算审批未明确｜依据：「跃玩项目组」2026-10

9. 分支变体

  • 活动上新：节日、新赛季活动，按机器人卡片提报
  • 换图与弹窗/开屏：更换或下架，同样走变更台账
  • 权益与商城：新增、删除、改兑换客服、改说明文案、改核销方式；涉及新功能转需求评审
  • 批量积分：活动加分、中奖加分（每条中奖记录一次）
  • 会员活动策划：星域平台活动、会员端共创、俱乐部侧活动，走立项审批
  • 不同俱乐部（EG 系关联方等）：俱乐部方对名单真实性负责，平台只做工具与校验

10. 待确认问题

  • 配置执行能否从 CTO 转给产品/运营自助？后台自助配置开发排期？
  • 配置执行的 B 角是谁？
  • 提前 2 个工作日提报是否可行？
  • 批量积分导入工具与校验报告由谁开发？
  • 直接改库是否必须审批？审批人是谁？
  • 会员活动奖励预算的审批人与财务发奖流程是什么？
  • 俱乐部方与平台在名单准确性上的责任边界是否写入协议？
OPS-25平台罚款申诉审核待新建80

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗2 × 跨5 × 险4

  • 适用场景：陪玩或俱乐部在跃玩管理端对平台罚款提交申诉，需要平台侧在时限内审核并反馈结果时启动
  • 负责人：主责——平台运营审核岗（当前：待指定）；协同——跃竞前端研发（当前：陈真炎·推断待确认）、跃竞后端研发（当前：待指定）、财务（涉及退罚款时）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 申诉提交触发通知 → ② 审核岗认领 → ③ 核对罚款依据与申诉材料 → ④ 作出维持/撤销/部分撤销决定 → ⑤ 执行退款或解除处罚 → ⑥ 反馈申诉方 → ⑦ 登记归档
  • 交付结果：有审核结论、处理记录和反馈记录的申诉单；如撤销罚款，对应金额已退回或处罚已解除
  • 状态依据：管理端已有申诉页面，但没有指定审核人，也没有消息通知；2026-05 出现申诉挂起无人审核，发现后临时由研发同学直接通过，属事故暴露的流程空白

1. 场景判定

  • 触发条件：管理端申诉列表出现“待审核”的平台罚款申诉；或陪玩/俱乐部通过客服渠道反映对罚款有异议
  • 典型说法：「有一个平台罚款申诉，好像没人来审核」「这个得做个消息通知，我们都不知道」
  • 判断问题：异议对象是不是“平台按规则开出的罚款”？是否已在管理端生成申诉单？
  • 不归本流程管：订单退款与用户投诉 → 请走 X-CS-25（订单投诉受理与售后缓冲规则）；罚款规则本身的制定与调整 → 请走 X-PRD-14（业务规则与统计口径定义）；分账与结算差错 → 请走 FIN-24（支付渠道每日对账、手续费与差异处理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审核人 认领、核实、出结论、反馈 R 平台运营审核岗（当前：待指定）
审批人 对撤销罚款、金额较大或有争议的申诉拍板 A 跃竞负责人（当前：徐莉·推断待确认）
研发 提供订单/行为日志，维护通知与超时提醒 C 跃竞前端研发（当前：陈真炎·推断待确认）、跃竞后端研发（当前：待指定）
财务 涉及罚款退回时执行与对账 C 财务专员（当前：待指定）
申诉方 提交申诉与证明材料，接收结果 I 陪玩/俱乐部

3. 办之前请准备

  • 申诉单号、申诉方账号、对应订单号
  • 罚款记录：罚款规则条款、触发时间、金额、开罚方式（系统自动/人工）
  • 申诉方提交的说明与截图、聊天记录等材料
  • 订单与服务过程日志（由研发或后台导出）
  • 现行平台罚款规则版本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 申诉提交后自动推送到审核群并 @审核岗 系统 实时 管理端 + 飞书机器人 申诉通知 🔧飞书固化+🤖自动化
2 认领申诉，在申诉单标记“处理中” 审核岗 通知后 4 个工作小时内 管理端 认领记录 🔧飞书固化
3 调取罚款依据与订单日志，核对申诉材料 审核岗；研发协助取数 认领后 1 个工作日内 管理端 / 后台日志 核查记录 👤人工判断
4 出结论：维持 / 撤销 / 部分撤销；撤销类或有争议的报审批人 审核岗 → 跃竞负责人 认领后 2 个工作日内 管理端 / 飞书审批 审核结论 👤人工判断
5 撤销类执行退款或解除处罚，财务核对 审核岗 / 财务 结论后 1 个工作日内 管理端 / 支付后台 退款或解除记录 🔧+👤
6 向申诉方反馈结果与理由 审核岗 结论当日 站内消息 / 客服渠道 反馈记录 🤖自动化
7 申诉单关闭，原因分类登记，月度汇总 审核岗 关闭当日；每月 5 日前出汇总 多维表格 申诉台账 🔧飞书固化

5. 交付物与模板

  • 交付物：已关闭的申诉单（含结论、理由、审批记录、反馈记录）；月度申诉台账
  • 建议模板/表单：申诉台账字段——申诉单号、申诉方类型（陪玩/俱乐部）、订单号、罚款条款、罚款金额、提交时间、认领人、认领时间、结论、结论理由、审批人、退款状态、反馈时间、原因分类、是否需改规则

6. 异常与升级

  • 申诉提交 4 个工作小时无人认领 → 机器人催办 → 仍无人认领升级跃竞负责人（再 4 个工作小时）
  • 认领后 2 个工作日未出结论 → 审核岗说明原因 → 升级跃竞负责人（第 3 个工作日）
  • 罚款依据不清或规则有歧义 → 暂停结论，提交规则修订 → 跃竞负责人裁定（2 个工作日内）
  • 同一规则条款月内申诉 ≥ 3 次 → 汇总给跃竞负责人评估规则是否合理（月度汇总时）
  • 系统通知失效 → 研发修复 → 期间审核岗每日上午人工巡检申诉列表

7. 衡量指标

  • 认领时效：提交到认领的工作小时，目标 ≤ 4 小时
  • 结案周期：提交到反馈申诉方的工作日，目标 ≤ 3 个工作日
  • 超时未处理申诉数：每月目标为 0
  • 申诉撤销率：撤销与部分撤销数 / 申诉总数，按月观察，持续偏高说明规则或开罚环节有问题

8. 低效诊断

  • 现象：申诉提交后无通知触达，审核环节无人认领，申诉在列表中挂起｜依据：「跃玩管理端」2026-05
  • 现象：审核岗位未定义，发现后由研发人员直接操作“通过”，缺少审核依据与审批留痕｜依据：「跃玩管理端」2026-05
  • 现象：通知机制在问题发生后才提出，属事后补流程｜依据：「跃玩管理端」2026-05

9. 分支变体

  • 无（陪玩个人与俱乐部申诉暂按同一流程；后续如分星域/弈荟等产品线运营，再拆分审核岗）

10. 待确认问题

  • 审核岗由谁担任？是运营、客服还是产品？是否需要设置备岗？
  • 研发直接“通过”的那笔申诉是否需要事后补审核与留痕？
  • 4 小时认领、3 个工作日结案的时限是否可行？
  • 哪些情形必须报跃竞负责人审批（如撤销金额阈值、俱乐部类申诉）？
  • 申诉通知走飞书机器人还是管理端站内提醒？由哪位研发负责开发？
  • 是否已有成文的平台罚款规则与申诉规则对外公示？
OPS-26运营平台账号与登录验证管理待新建推断108

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：运营人员登录、换设备、实名/人脸认证或新开抖音、小红书、微信（公众号/视频号）等公司运营账号，需要验证码或实名主体配合时启动；同时覆盖账号登记与人员交接
  • 负责人：主责——运营账号管理员（当前：李宣昊·推断待确认）；协同——实名手机号持有人（当前：待指定）、IT/信息安全（当前：待指定）、品牌（当前：待指定）；兜底——运营负责人（当前：待指定）
  • 核心流程：① 账号登记入台账 → ② 绑定方式整改（企业认证/共享号码） → ③ 设验证码接收值班 → ④ 发起登录/认证申请 → ⑤ 验证码按安全渠道转达 → ⑥ 人脸/实名认证预约 → ⑦ 人员变动时交接与改绑
  • 交付结果：一份完整的公司运营账号台账（主体、绑定号码、管理员、备份人）；每次登录/认证在约定时限内完成，且验证码不在聊天中明文留存
  • 状态依据：（推断）目前没有账号台账和验证码接收机制，平台验证码与人脸认证依赖单一实名手机号持有人，每次登录需临时约时间，持有人不在岗时登录容易推迟

1. 场景判定

  • 触发条件：平台要求短信验证码或人脸/实名认证；新开账号（含鼎慧新账号）；换手机/换电脑登录；账号管理员变动
  • 判断问题：这个账号是不是以公司名义运营的平台账号？绑定的是不是公司实名手机号或主体？
  • 不归本流程管：内容选题、发布与审核 → 请走 BRD-08（新媒体日常内容生产与发布）；公司内部系统账号（飞书、云账号、Gitea）开通 → 请走 X-SEC-01（新人入职 IT 账号一站式开通）/ X-SEC-02（Gitea 账号与仓库权限）/ X-SEC-15（云平台子账号/控制台权限）；平台企业认证材料用印 → 请走 LEG-09（用章用印审批与盖章版本核对）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账号管理员 维护台账、发起登录/认证、组织交接 R 运营账号管理员（当前：李宣昊·推断待确认）
运营负责人 审批新开账号、管理员变更、改绑方案 A 运营负责人（当前：待指定）
实名号码持有人 接收验证码、配合人脸认证（整改前） C 实名手机号持有人（当前：待指定）
IT/信息安全 共享号码/验证码转发方案、密码库管理 C IT/信息安全（当前：待指定）
品牌 账号命名、主体与认证口径 I 品牌（当前：待指定）
运营人员 提交登录/认证申请、按约定时间触发验证码 R 运营人员（当前：待指定）

3. 办之前请准备

  • 账号台账中该账号的记录：平台、账号名、所属主体（模态/鼎慧等）、绑定号码归属、认证类型
  • 本次需要的操作：短信验证 / 人脸认证 / 实名变更 / 新开账号
  • 提前确认号码持有人或值班人的可用时段
  • 新开账号：营业执照、认证公函（如需用印）、账号命名与头像

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 盘点全部运营账号，建立台账（不记录密码明文） 账号管理员 本 SOP 发布后 5 个工作日内；新账号开通当日 多维表格 账号台账 🔧飞书固化
2 制定改绑方案：优先企业认证或运营负责人本人实名，或改绑公司共享号码 账号管理员 + IT 台账建立后 10 个工作日内 各平台后台 改绑方案 👤人工判断
3 设验证码接收值班：主接收人 + 备份人，共享号码时用转发机器人推送到受限群 IT 改绑完成当日 共享手机 / 转发机器人 值班表 🔧+🤖
4 在登记表提交登录/认证申请（平台、操作类型、期望时间） 运营人员 操作前至少 2 小时；人脸认证提前 1 个工作日 飞书表单 申请记录 🔧飞书固化
5 接收人回复可用时段，运营触发验证码，接收人通过受限渠道转达 接收人 申请后 2 个工作小时内 转发机器人 / 电话 完成登录 🤖自动化
6 人脸/实名认证由主体本人按约定时间完成 号码持有人 / 主体负责人 申请后 1 个工作日内 平台 App 认证完成 👤人工判断
7 人员变动时：交接账号清单、改管理员、改密码、更新台账 账号管理员 + 运营负责人 离岗/转岗前 3 个工作日 台账 / 各平台后台 交接记录 🔧+👤

5. 交付物与模板

  • 交付物：运营账号台账；验证码接收值班表；每次登录/认证申请记录；账号交接记录
  • 建议模板/表单：账号台账字段——平台、账号名、所属主体、用途、认证类型（个人/企业）、绑定号码归属（岗位，不填号码）、主管理员、备份管理员、密码存放位置（密码库条目名）、最近登录日期、状态
  • 申请表字段——申请人、平台、账号名、操作类型、期望时间、紧急程度、完成时间

6. 异常与升级

  • 接收人 2 个工作小时内无响应 → 转备份人 → 仍无响应升级运营负责人（当日）
  • 主接收人出差/设备不可用 → 提前在值班表登记代班人 → 无代班人时由运营负责人指定（出差前 1 个工作日）
  • 平台要求的人脸认证人不在岗 → 改约时间并通知运营负责人评估影响（当日）
  • 账号被封禁、异地登录告警、疑似被盗 → 立即改密并冻结操作 → 升级运营负责人与 IT（1 小时内）
  • 验证码或密码在群聊/私信中明文发出 → 当日改密并提醒 → 记入月度安全检查

7. 衡量指标

  • 验证码响应时长：申请到完成登录的工作小时，目标 ≤ 2 小时
  • 因验证码推迟到次日的次数：每月目标 ≤ 1 次
  • 台账覆盖率：已登记账号数 / 实际运营账号数，目标 100%
  • 单点依赖账号数：只有一名可接收验证码人员的账号数，目标为 0

8. 低效诊断

  • 现象：所有平台的验证码与人脸认证集中依赖一名管理者及其一部手机，形成单点；登录环节平均要先约时间｜依据：（推断）
  • 现象：接收人出差、开会、设备没电时没有备份，登录推迟到次日，内容发布与账号运营中断｜依据：（推断）
  • 现象：验证码在聊天中明文流转，缺少受控转达渠道｜依据：（推断）
  • 现象：没有账号台账，新开账号（如鼎慧）时主体、号码、管理员无统一登记｜依据：（推断）

9. 分支变体

  • 抖音/小红书：常见短信验证与人脸认证，人脸认证必须主体本人在场
  • 微信公众号/视频号：管理员扫码确认，可通过增设运营人员为管理员减少依赖
  • 鼎慧新账号：按鼎慧主体开设，开通时同步进台账并确定独立管理员

10. 待确认问题

  • 运营账号管理员是否为当前运营负责人？运营负责人人选待确认
  • 现有账号能否改为企业认证或改绑公司共享号码？共享手机由谁保管？
  • 是否引入密码库（如飞书或第三方工具）集中管理账号密码？
  • 2 小时响应时限是否可行？非工作时间的紧急登录如何处理？
  • 鼎慧等主体的账号是否由同一管理员统一管理？
  • 安全侧（信息安全/IT）由谁对接？
OPS-28运营资料汇总与岗位交接待优化推断36

状态：待优化｜证据：推断（来源为单聊，不对外引用）｜优先级：频2 × 耗3 × 跨3 × 险2

  • 适用场景：运营新人（含实习生）入职，或运营人员转岗、离职时，需要把群运营思路、运营流程、对外资料、用户调研成果统一交接给接手人
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——运营文档维护人（当前：待指定，维护流程与群运营思路文档）、人事（当前：待指定）；兜底——运营负责人（当前：待指定）
  • 核心流程：① 维护统一的运营知识库目录 → ② 按岗位整理“入门包” → ③ 入职前准备交接清单与权限 → ④ 入职当周当面讲解 → ⑤ 接收人按清单自学并完成入门任务 → ⑥ 双方核对签收 → ⑦ 交接后更新文档
  • 交付结果：一份按岗位组织的运营入门包（知识库目录 + 交接清单 + 入门任务），以及双方确认的交接记录
  • 状态依据：（推断）运营资料已有统一目录、对外资料汇总表和调研成果存放位置，但目录结构不稳定，没有新人交接清单，交接依赖个人当面对接

1. 场景判定

  • 触发条件：运营岗新人入职确定到岗日期；运营人员转岗/离职；运营流程或资料目录发生重大调整
  • 判断问题：交接内容是不是运营工作资料（流程、群运营思路、对外资料、调研成果）？
  • 不归本流程管：入职手续、账号开通、工位设备 → 请走 HR-05（新员工入职准备与办理）；离职手续 → 请走 HR-27（员工离职办理与交接）；运营平台账号交接 → 请走 OPS-26；客户资料与合同交接 → 请走 SAL-35（销售人员离岗客户与商机交接）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交接负责人 维护目录、准备入门包、当面讲解、签收 R 产品总监（当前：杨萌·推断待确认）
审批/兜底 确认交接完整，处理交接断档 A 运营负责人（当前：待指定）
文档维护人 更新流程与群运营思路文档 C 运营文档维护人（当前：待指定）
人事 提前告知到岗日期，同步入职安排 I 人事（当前：待指定）
接收人 自学、完成入门任务、签收 R 新入职/接手运营人员

3. 办之前请准备

  • 运营知识库统一目录（当前已有运营文档目录、对外资料汇总表、用户调研汇总页）
  • 标注过期文档：如“用户运营流程（弃用）”仅作历史参考，交接时说明不再执行
  • 接收人需要开通的文档、群、表格权限清单
  • 接收人入职首周的入门任务（读什么、做什么、交付什么）
  • 离职/转岗交接时：交出人的在办事项清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 维护统一知识库目录：流程、群运营思路、对外资料表、调研方式与成果，弃用文档加标记 交接负责人 + 文档维护人 常态维护；每月最后一个工作日检查一次 飞书知识库 运营知识库 🔧飞书固化
2 按岗位整理“入门包”：必读清单、入门任务、常用群与表格 交接负责人 岗位首次招聘前；之后随目录更新 飞书知识库 / 文档模板 岗位入门包 🔧飞书固化
3 人事告知到岗日期，交接负责人开好文档/群/表格权限 人事 → 交接负责人 到岗前 2 个工作日 飞书 权限清单 🔧飞书固化
4 当面讲解：业务背景、目录结构、在办事项、协作对象 交接负责人 到岗后 2 个工作日内 线下 / 飞书会议 讲解记录 👤人工判断
5 接收人按清单自学并完成入门任务，疑问记在交接文档 接收人 到岗后 5 个工作日内 飞书文档 入门任务成果 🤖自动化（AI 问答辅助）
6 双方逐项核对交接清单并签收 交接负责人 + 接收人 到岗后第 5 个工作日 多维表格 交接签收记录 👤人工判断
7 接收人把交接中发现的缺漏补进知识库 接收人 签收后 5 个工作日内 飞书知识库 更新后的目录 🔧飞书固化

5. 交付物与模板

  • 交付物：运营知识库目录；岗位入门包；交接签收记录
  • 建议模板/表单：交接清单字段——资料类别（流程/群运营思路/对外资料/调研成果/在办事项）、文档名与链接、是否有效（有效/弃用）、负责人、是否已讲解、接收人确认、确认日期、备注
  • 入门包结构：岗位说明 → 必读文档（按顺序）→ 常用群与表格 → 首周任务 → 常见问题

6. 异常与升级

  • 到岗前 2 个工作日仍未获知到岗日期 → 交接负责人询问人事 → 未明确则升级运营负责人
  • 交出人离职前未完成交接 → 运营负责人指定代交接人（离职前 3 个工作日）
  • 签收时发现资料缺失或文档过期 → 记入交接清单备注 → 交接负责人 5 个工作日内补齐
  • 接收人 2 周后仍无法独立完成基础工作 → 交接负责人复盘入门包缺口 → 报运营负责人

7. 衡量指标

  • 新人上手周期：到岗到独立完成首项运营任务的工作日，目标 ≤ 10 个工作日
  • 交接清单完成率：已签收项 / 清单总项，目标 100%
  • 文档有效率：知识库中标注有效且近 3 个月有更新的文档占比，按月观察
  • 目录调整次数：季度内目录结构大改次数，目标 ≤ 1 次

8. 低效诊断

  • 现象：文档结构短期内多次重调，整理工作重复投入｜依据：（推断）
  • 现象：交接依赖个人当面对接，没有书面清单与签收，交接人不在时容易断档｜依据：（推断）
  • 现象：弃用流程文档与现行文档并存，新人难以判断哪份有效｜依据：（推断）

9. 分支变体

  • 无

10. 待确认问题

  • 运营知识库目录由谁长期维护？是否有固定入口？
  • 是否已有成文的新人交接清单或入职任务？
  • “用户运营流程（弃用）”是否可归档或移出现行目录？
  • 人事是否能固定在到岗前 2 个工作日通知交接负责人？
  • 运营人员离职/转岗交接是否也走本流程，还是作为 HR-27 的部门交接清单附录？
OPS-29用户个人信息权利请求与账号注销处理待新建推断80

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨4 × 险5

  • 适用场景：产品用户（C 端或企业成员）提出查询、复制、更正、删除个人信息、撤回同意或注销账号，或应用商店/监管要求提供注销能力时启动
  • 负责人：主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、研发后台负责人（当前：待指定）、客服（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）
  • 核心流程：① 统一受理 → ② 身份核验 → ③ 请求分类 → ④ 注销前检查与告知 → ⑤ 执行删除/匿名化 → ⑥ 答复用户 → ⑦ 留痕 → ⑧ 季度统计自查
  • 交付结果：按时答复的请求处理单、执行记录，季度统计与自查报告
  • 状态依据：已有 LEG-18（隐私政策中的用户权利告知）、X-CS-02（账号封停溯源）覆盖部分环节，本条补齐产品侧个人信息权利请求与账号注销的受理执行；法律口径以 LEG-34 为准（推断）

1. 场景判定

  • 触发条件：用户通过客服、隐私政策所列邮箱、应用内入口提出上述请求
  • 典型说法：「我要注销账号」「把我的数据删掉」「我的手机号绑错了要改」
  • 判断问题：请求对象是否为用户本人信息？是否涉及余额、订单或企业管理员身份？
  • 不归本流程管：退款 → 请走 X-CS-10；企业转移管理员 → 请走 OPS-09；隐私政策编制 → 请走 LEG-18；活动名单删除 → 请走 MKT-20；答复时限、留存例外与拒绝理由等法律口径 → 以 LEG-34 为准；个人信息分类分级与保留期限 → 请走 X-SEC-45

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用户运营专员 受理、核验、协调、答复 R 用户运营专员（当前：待指定）
研发后台负责人 执行删除/匿名化/注销 R 研发后台负责人（当前：待指定）
法务 留存例外判断、拒绝理由审核 C 法务专员（当前：待指定）
运营负责人 处理结果把关 A 运营负责人（当前：李宣昊·部门报送人）

3. 办之前请准备

  • 用户账号、注册手机号/邮箱、请求类型与理由
  • 账号余额、未完成订单、所属企业组织信息

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记请求（入口、时间、类型） 用户运营专员 收到当天 飞书表单 请求单 🔧飞书固化
2 核验本人身份（绑定手机号验证码等） 用户运营专员 1 个工作日内 后台 核验结果 👤人工判断
3 分类：查询/复制/更正/删除/撤回同意/注销 用户运营专员 同步 — 分类 👤人工判断
4 注销前检查余额、订单、管理员身份，书面告知后果与余额处理 用户运营专员 2 个工作日内 后台 告知记录 👤人工判断
5 执行删除或匿名化；依法须留存的交易记录按期限封存 研发后台负责人 告知确认后 5 个工作日内 后台/数据库 执行记录 🤖自动化
6 答复用户结果；不能满足的说明理由 用户运营专员 受理后 15 个工作日内 客服渠道 答复记录 🔧飞书固化
7 处理单归档 用户运营专员 答复当天 多维表格 归档 🔧飞书固化
8 季度统计请求量与超时，检查注销入口可用 运营负责人 每季度末 台账 自查报告 👤人工判断

5. 交付物与模板

  • 交付物：请求处理单、执行记录、季度自查
  • 建议模板/表单：请求单（用户标识、产品、请求类型、核验方式、余额/订单情况、处理人、执行时间、答复时间、结果）

6. 异常与升级

  • 用户为企业唯一管理员 → 先按 OPS-09 转移管理员再注销
  • 用户投诉到监管或应用商店 → 当天报法务，按 OPS-31 处理

7. 衡量指标

  • 按时答复率 = 15 个工作日内答复的请求 / 全部请求，目标 100%
  • 注销执行时长 = 确认到完成，目标 ≤ 5 个工作日

8. 低效诊断

  • 聊天中未见相关流程，存在用户无法注销被投诉、应用商店审核不通过、删除不彻底违反个人信息保护要求的风险（推断）

9. 分支变体

  • 企业版：企业成员信息由企业管理员管理，个人请求需同时告知企业；俱乐部会员端：涉及余额与积分时先结清

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各产品（LeapAll、字字可研、会员端等）是否已有注销入口？
  • 答复时限 15 个工作日与留存期限请法务按 LEG-34 口径确认
OPS-30营销权益防刷与异常账号风控处置待新建推断180

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：新人注册福利、邀请码、代金券、试用额度、卡密、校园大使分润、红包类活动上线前后，需防批量注册、刷邀请、刷券、额度异常消耗与套现时启动
  • 负责人：主责——用户运营专员（当前：待指定）；协同——研发后台负责人（当前：待指定）、财务（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）
  • 核心流程：① 上线前风控评审 → ② 配置监控告警 → ③ 每日巡检 → ④ 异常判定 → ⑤ 冻结/封停/回收 → ⑥ 用户申诉 → ⑦ 规则调整复盘 → ⑧ 月度损失统计
  • 交付结果：活动风控评审记录、异常处置清单、月度权益损失统计
  • 状态依据：已有 OPS-07（试用额度与兑换券发放登记）、MKT-14（营销裂变玩法合规审批）、X-CS-02（来源不明账号溯源封停）覆盖部分环节，本条补齐有价权益活动的防刷评审、监控告警与异常处置（推断）

1. 场景判定

  • 触发条件：任何对外发放有价权益的活动上线；领取或消耗出现突增；同一来源大量注册
  • 典型说法：「这个券怎么一下领完了」「额度消耗太快，是不是被刷了」
  • 判断问题：是否涉及可兑换为钱或算力的权益？是否出现异常聚集？
  • 不归本流程管：权益发放审批 → 请走 OPS-07；营销玩法策划与合规审批 → 请走 MKT-14；企业客户来源不明账号的溯源封停 → 请走 X-CS-02；单个客户扣费异常 → 请走 X-CS-09；网络攻击 → 请走 X-SEC-42

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用户运营专员 评审发起、巡检、处置执行 R 用户运营专员（当前：待指定）
研发后台负责人 限领规则、监控告警、数据核查 R 研发后台负责人（当前：待指定）
财务 损失核算、分润暂停 C 财务专员（当前：待指定）
运营负责人 批准风控规则与大规模封停 A 运营负责人（当前：李宣昊·部门报送人）

3. 办之前请准备

  • 活动规则、权益总量与单人上限、预算
  • 已知异常特征（同 IP/设备/支付账号/手机号段聚集）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 活动上线前风控评审：每人/设备/手机号限领、总量上限、监测指标 用户运营专员 上线前 3 个工作日 飞书审批 评审记录 🔧飞书固化
2 配置领取速率、聚集度、消耗突增告警 研发后台负责人 上线前 监控/机器人 告警规则 🤖自动化
3 活动期间每日巡检领取与消耗数据 用户运营专员 每日 数据看板 巡检记录 🤖自动化
4 异常账号核查与判定 用户运营专员+研发 告警后 4 小时内 后台 判定清单 👤人工判断
5 冻结领取、暂停活动、封停账号、回收额度、暂停分润结算 用户运营专员 判定后 2 小时内 后台 处置记录 🤖+👤
6 受理申诉，误判 2 个工作日内恢复 用户运营专员 收到后 2 个工作日内 客服渠道 申诉结果 👤人工判断
7 复盘漏洞，调整规则 运营负责人 事件后 5 个工作日内 飞书文档 规则更新 👤人工判断
8 统计月度权益损失报财务 用户运营专员 每月 5 日前 多维表格 损失统计 🤖自动化

5. 交付物与模板

  • 交付物：风控评审记录、异常处置清单、月度损失统计
  • 建议模板/表单：风控评审表（活动、权益类型、总量、单人上限、限领维度、监控指标、告警阈值、负责人）

6. 异常与升级

  • 单日损失超过活动预算一定比例（比例待确认）→ 立即暂停活动 → 报运营负责人与财务
  • 涉及分润/提现套现 → 冻结结算并报财务与法务

7. 衡量指标

  • 风控评审覆盖率 = 走评审的有价活动 / 全部有价活动，目标 100%
  • 异常响应时长 = 告警到处置，目标 ≤ 6 小时

8. 低效诊断

  • 聊天中未见相关流程，存在券与额度被批量薅取、分润被套现、活动预算失控的风险（推断）

9. 分支变体

  • 校园大使分润：提现前加人工复核；商城卡密：与渠道约定异常核销处理；俱乐部积分：按会员端规则处理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 产品后台目前有哪些限领与监控能力？
  • 封停账号是否需法务确认用户协议依据？
OPS-31用户举报、消费投诉与监管协查响应待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：用户举报违法违规内容或账号、消费者通过监管平台投诉被转办、公安/网信等部门来函调取数据或要求协查、应用商店发出下架警告时启动
  • 负责人：主责——用户运营专员（当前：待指定）；协同——法务专员（当前：待指定）、客服（当前：待指定）、研发后台负责人（当前：待指定）、安全管理员（当前：待指定）；兜底——运营负责人（当前：李宣昊·部门报送人）
  • 核心流程：① 统一入口登记 → ② 分类 → ③ 内容举报处置 → ④ 消费投诉核实答复 → ⑤ 监管来函核验 → ⑥ 最小化提供与整改 → ⑦ 台账归档 → ⑧ 季度复盘
  • 交付结果：举报/投诉/来函台账、处理与答复记录、调证交付记录、整改记录
  • 状态依据：已有 OPS-23（社区内容与入驻审核）、X-CS-10（C 端客诉与退款）覆盖部分环节，本条补齐外部举报、监管平台转办投诉与执法协查的统一受理（推断）

1. 场景判定

  • 触发条件：产品内举报；举报邮箱来信；监管平台转办单；公安/网信等调证或协查函；应用商店警告
  • 典型说法：「有用户举报某个帖子」「平台转来一个投诉」「派出所来电要调用户信息」
  • 判断问题：是否来自外部第三方或监管？是否有时限要求？
  • 不归本流程管：普通售后问题 → 请走 X-CS-05；社区内容日常审核 → 请走 OPS-23；未升级到监管平台的 C 端客诉与退款 → 请走 X-CS-10；监管问询、执法调证与约谈的法律处置 → 请走 LEG-33（本流程负责受理登记与数据调取执行）；公开舆情 → 请走 BRD-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用户运营专员 登记、分发、跟进、答复 R 用户运营专员（当前：待指定）
法务 来函真实性与合法性核验、答复审核 R 法务专员（当前：待指定）
研发后台负责人 数据调取、内容下架 R 研发后台负责人（当前：待指定）
运营负责人 处理结果把关 A 运营负责人（当前：李宣昊·部门报送人）
客服 消费投诉核实与答复 R 客服（当前：待指定）
CEO 重大来函知悉 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 举报/投诉原文、涉及账号或内容链接、转办单号与时限
  • 监管来函原件、执法人员身份信息

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有入口统一登记（来源、时限、类型） 用户运营专员 收到当天 多维表格 登记记录 🔧飞书固化
2 分类：内容举报/消费投诉/监管来函/商店警告 用户运营专员 当天 — 分类 👤人工判断
3 内容举报按 OPS-23 审核，违规即下架并处罚账号 用户运营专员 24 小时内 审核后台 处置记录 🤖+👤
4 消费投诉核实事实，按转办单时限答复，必要时退款 客服 按转办单时限 监管平台 答复记录 👤人工判断
5 监管来函核验文书与执法主体，确认调取范围 法务 1 个工作日内 — 核验结论 👤人工判断
6 按范围最小化导出，加密交付并留存交接记录；需整改的落实整改 研发后台负责人 按来函时限 后台 交付记录 👤人工判断
7 全部结果归档 用户运营专员 办结当天 多维表格 台账 🔧飞书固化
8 季度复盘举报与投诉类型，推动产品与规则改进 运营负责人 每季度末 飞书文档 复盘 👤人工判断

5. 交付物与模板

  • 交付物：举报投诉来函台账、答复记录、调证交付记录
  • 建议模板/表单：台账字段（来源、类型、涉及产品/账号、时限、处理人、处理结果、答复时间、是否涉及数据提供、审批人）

6. 异常与升级

  • 来函无法核实真实性 → 不提供数据，法务通过官方渠道回核
  • 应用商店下架警告或监管约谈 → 当天报 CEO 与法务

7. 衡量指标

  • 按时答复率 = 在时限内答复的事项 / 全部事项，目标 100%
  • 重复投诉率 = 同一问题再次被投诉的比例，逐季下降

8. 低效诊断

  • 聊天中未见相关流程，存在投诉超时被监管处罚、向冒充执法者泄露用户数据、违规内容未及时下架的风险（推断）

9. 分支变体

  • 俱乐部/陪玩业务：订单投诉先走 X-CS-25，升级到监管平台后转入本流程；企业版：涉及企业数据的调取需同时评估合同保密义务

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 产品与隐私政策中公布的举报/联系渠道由谁值守？
  • 监管来函默认由谁签收（前台、法务还是运营）？

RND 研发

报送人：丁震宇 · 研发 · 90 条 · 已有 0 / 待优化 42 / 待新建 48
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
RND-01反馈群问题收集与分流（bug/需求/badcase）内部员工、客户或市场在反馈群、话题群、内测群或口头反映产品问题时，判定类型、查重、转入对应载体，并在原帖回复去向主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、反馈群值班产品经理（当前：杨黔昆、陈震·推断待确认）、Badcase 收集人（当前：黄霆瑄·推断待确认）、反馈机器人维护人（当前：待指定）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 收帖 → ② 补齐复现信息 → ③ 判类型（bug/需求/badcase/使用问题）→ ④ 查重 → ⑤ 转工单/需求池/badcase 表/直接答复 → ⑥ 原帖回复去向 → ⑦ 处理完成后通知反馈人每条有效反馈都有明确去向（工单编号、需求池记录、badcase 记录或答复），并回在原话题下；每周一份分流统计待优化180
RND-02Badcase 记录、分诊与回归集沉淀用户或内部发现 AI/Agent 表现差（答非所问、上下文丢失、工具乱调用、提前结束、生成质量差）但不属于代码缺陷时，登记 badcase、分诊根因、跟进修复，并沉淀为回归/评测用例主责——评测/Badcase 负责人（当前：黄霆瑄·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、Agent 研发（当前：岳阳、杨云峰、李铭熙·推断待确认）、字字可研 AI 助手研发（当前：宋祺睿·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 登记 → ② 补上下文 → ③ 入库判定 → ④ 分诊根因 → ⑤ 归因会指派 → ⑥ 修复（提示词/skill/工具/模型，或转 bug）→ ⑦ 回归验证 → ⑧ 入评测集并通知提交人带编号（BADCASE-NN）的 badcase 记录（含根因类别、处理方式、修复版本、关联工单）；每周 badcase 周报；新增的回归/评测用例待优化108
RND-03缺陷提报、复现、分级与指派测试、产品、研发、客户或交付人员发现产品缺陷时，复现留证、按模板建单、定级、指派认领、修复关联 PR、验收关闭主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 发现与复现 → ② 查重 → ③ 按模板建单 → ④ 定级 → ⑤ 指派/认领 → ⑥ 修复并关联 PR → ⑦ 产品/测试验收（打回或通过）→ ⑧ 关闭并通知每个缺陷都有一张信息完整、定级、有负责人、关联 PR 并经验收关闭的工单；发版前 P0/P1 清零记录待优化180
RND-04需求提出、澄清与评审入迭代产品、业务、客户、领导或研发提出新需求（含一句话需求、迭代中插队需求、客户现场需求）时，登记、澄清、评审，决定做/不做/排入哪个迭代，并留痕主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震、杨黔昆·推断待确认）、CTO（客户项目需求取舍，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵、陈雁·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 登记入需求池 → ② 澄清（背景/目标/验收标准）→ ③ 产品初筛 → ④ 需求评审（方案与估点）→ ⑤ 决策并留痕 → ⑥ 拆工单入迭代 → ⑦ 插队走确认 → ⑧ 产品验收需求池中每条需求都有来源、结论（做/不做/待定）和目标迭代；评审纪要；挂在迭代上、带估点、优先级和验收人的工单待优化144
RND-05新产品/新项目研发立项与分工提出新产品、新客户端或跨团队基础能力（如 MercAll/ClawLite、MercPay/LeapPay 支付中台、billing、电子签）需要多人协作落地时，完成立项、定角色、写需求、建协作载体、拆任务并跟踪到 MVP 验收主责——项目技术负责人（立项时指定，当前：待指定）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、外部/领域技术顾问（如支付，当前：王子明·推断待确认）、财务负责人（涉资金链路时，当前：黄梦婷·推断待确认）、法务负责人（涉电子签时，当前：李瑶·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 立项提出 → ② 立项卡（目标/MVP 范围/不做项/DDL）→ ③ 角色表 → ④ PRD/用户故事 → ⑤ 需求梳理会+纪要 → ⑥ 建仓库、群、工单项目、里程碑 → ⑦ 拆任务进看板 → ⑧ 进度同步 → ⑨ MVP 验收并转入常规迭代经 CTO 确认的立项卡、角色表、PRD/用户故事、需求梳理会纪要、工单项目与里程碑、MVP 验收结论待新建128
RND-06迭代规划、工单拆分与排期每个迭代（约两周）开始前，或新产品/大版本确定上线日期需要倒排时，把需求池整理成有人认领、有点数、有截止日的迭代计划主责——研发负责人/迭代负责人（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌、黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各模块负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 产品冻结迭代需求清单 → ② 研发拆故事卡/工单并关联需求 → ③ 估点与容量校验 → ④ 迭代规划会定范围与优先级 → ⑤ 认领与截止日 → ⑥ 倒排关键节点（提测/冻结/UAT/发版）→ ⑦ 发布迭代计划并通知已发布的迭代计划（cycle/milestone）：全部工单有唯一负责人、点数、优先级、截止日并关联需求，附关键节点日历与规划会纪要待优化108
RND-07研发任务分派、模块负责人与归属判定新迭代分工、出现无人认领的 bug/工单、跨团队问题不知找谁、成员超载/闲置/借调/改汇报线、新人入职派活时，确定唯一端到端负责人并维护模块负责人清单主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、各模块负责人（当前：待指定）、人事负责人（当前：黄莹·推断待确认，仅汇报线调整/新人入职时）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 维护模块负责人清单（主责/兜底/PR 审批人）→ ② 新问题按清单定位并指派 → ③ 查不到时首个接手人暂管并上报 → ④ 研发负责人裁定端到端负责人 → ⑤ 每周负载检查与调配 → ⑥ 人员变动填交接单并转派工单 → ⑦ 更新清单并公告公开的“模块—主责—兜底—PR 审批人—对外接口人”清单；每项任务/工单有唯一端到端负责人；人员调整有交接单待新建108
RND-08研发进度跟催与延期风险上报迭代/冲刺执行中，按工单跟踪进度、处理阻塞、节点前收口；预计延期时由负责人主动上报风险并决策调整范围或日期主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各工单负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 工单负责人每日更新状态并主动提测 → ② 机器人每日推送超期/未领/阻塞清单 → ③ 站会逐项处理 → ④ 节点 D-3 风险盘点 → ⑤ 预计延期按模板主动上报 → ⑥ 决策加人/砍范围/延期 → ⑦ 对外同步新日期 → ⑧ 迭代末归类延期原因每日进度异常清单、延期风险登记（原因、影响、新日期、决策人）、对测试与销售同步的最终范围与上线日期、迭代延期原因统计待优化240
RND-09研发站会与例会每个工作日固定时间的站会、代码评审（CR）会，以及迭代规划/回顾会、周会、专题评审会，用于同步进度/阻塞/风险并产出纪要与待办主责——研发负责人/站会主持（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认，上线冲刺期主持 bug 站会）、全体研发；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 按会议矩阵建周期性固定日程 → ② 会前更新工单状态 → ③ 按模板开会（站会 ≤15 分钟）→ ④ 智能纪要自动生成 → ⑤ 决议/待办转工单 → ⑥ 线下结论同步线上 → ⑦ 纪要归档迭代文档一张会议矩阵（固定日历）、每次会议的纪要、由会议决议生成的工单/待办待优化60
RND-10研发日报/周报与进展同步每个工作日下班前与每周五，研发/项目组提交日报与周报，汇总成管理层可读的进展、风险与下周计划；跨团队、子公司或借调人员对外同步进展主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认，产研周报与对上汇报）、全体研发、日报机器人维护人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 下班前更新工单状态 → ② 需补充者按四要素填日报 → ③ 机器人 20:00 汇总推送日报 → ④ 缺报/不合格自动 @补充 → ⑤ 周五研发负责人审定研发周报 → ⑥ 产品负责人合成产研周报与对上汇报版 → ⑦ 归档固定入口每日产研日报、每周产研周报（本周进展/风险/下周重点/点数完成情况）、对上汇报版本、跨团队进展同步记录待优化60
RND-11工单状态维护与工单系统规范任务、bug、需求进入工单系统流转后，按统一口径及时更新状态、负责人、迭代与标签，并通过自动通知、巡检与统计保证数据可信主责——研发负责人/工单系统管理员（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌·推断待确认，负责产品验收状态）、测试负责人（当前：张东郅·推断待确认，负责 bug 状态与统计）、代码仓库管理员（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 确定唯一数据源与状态口径 → ② 建单填必填字段 → ③ 按状态机流转（待办→进行中→待测→测试中→待验收→完成/打回）→ ④ 状态变更自动通知 → ⑤ 每日机器人巡检违规与滞留 → ⑥ 每周自动统计点数与 bug → ⑦ 按季度修订规范成文《工单规范》（状态定义、必填字段、流转规则、通知规则、统计口径）、每日巡检清单、每周统计报表待优化90
RND-12研发绩效、点数考核与事故追责每个迭代结束要核算研发点数和质量指标；或版本上线后出现 bug、数据事故、验收不通过，需要评级、认定责任并按规则扣点时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监/点数统计人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 开工前全量估点 → ② bug 入库定级并标来源 → ③ 迭代结束自动出点数与质量报表 → ④ 事故评级与责任认定 → ⑤ 扣点/回扣核算 → ⑥ 公示与异议 → ⑦ 季度汇总交人事与积分每迭代一份《研发点数与质量报表》（个人点数、bug 回扣、阻塞率、返工率）；事故/缺陷责任认定记录；公示后的点数结果；季度研发评价表待优化108
RND-13开工前方案设计与前置过审研发拿到新功能、较大改动，或涉及 LeapCore 平台能力、账号/权限、计费、网关等基础设施的需求，在写代码前先写方案并经负责人过审时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、跃竞后端权限负责人（当前：张楠·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、任务负责研发（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 确认需求已定 → ② 判定方案等级 → ③ 写 issue 方案/设计文档 → ④ 不确定点跑 PoC → ⑤ 过审 → ⑥ 定稿后估点开工 → ⑦ 偏离方案先更新再改挂在 Gitea issue 上的已过审技术方案（轻量为 issue 内方案，重量为设计文档加评审记录），PR 关联方案链接待新建144
RND-14技术方案评审、选型决策与赛马同一技术问题有 2 个以上方案或明显分歧（协议、框架、数据库、部署位置、计费归属、底座路线、交互原型），需要明确决策人、按标准评审或赛马择优，并把结论写成决策记录时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——议题收口负责人（按领域指定，如 Agent Runtime/协议当前：岳阳·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 登记决策议题 → ② 指定收口人与决策人 → ③ 写 ADR 草稿与方案对比 → ④ 选评审方式（文档/决策会/原型/赛马）→ ⑤ 评审或评测 → ⑥ 决策人拍板 → ⑦ ADR 归档公告 → ⑧ 落执行工单归档的技术决策记录（ADR：背景、选项、取舍、结论、决策人、日期、生效范围、重议条件）及执行工单；赛马另含章程、评测报告、评分表和名次公告待新建192
RND-15新技术/开源方案/第三方能力调研评估出现值得跟进的开源工具，或产品需要网盘、AI 网关、OCR、企业软件、第三方数据等外部能力时，评估“自研 / 二开 / 套壳 / 直接引入 / 采购 API”并给出立项建议时启动主责——技术调研负责人（当前：王皓南·推断待确认，可按议题另行指定）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、研发联调（当前：魏宗浩·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 登记调研议题 → ② 明确业务目标与数据范围 → ③ AI 初评横评 → ④ 人工评估许可、授权、成本、维护、隔离方式 → ⑤ 试用或 PoC → ⑥ 评审拍板 → ⑦ 转立项、接入或采购调研评估报告（候选对比、许可证与授权结论、成本、工期、推荐方案、实施负责人），调研台账结论，转入立项/接入/采购的记录待新建144
RND-16技术栈、组件库统一与通用能力复用新项目或新组件启动要选语言、框架、UI 组件库、通信方式、数据库；或发现多个项目在重复造同类轮子；或 FDE/定制项目做出可复用能力需要回流到模板、标准组件时启动主责——技术规范维护人（当前：待指定）；协同——基座组架构负责人（当前：陈晖·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、前端负责人（当前：季学森·推断待确认）、开放平台/FDE 负责人（当前：郭逸非·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 立项时对照技术栈清单勾选 → ② 查组件目录做复用评估 → ③ 清单外选型提偏离申请 → ④ 审批拍板 → ⑤ 更新清单并置顶公告 → ⑥ 可复用能力回流 → ⑦ 共性规范写入约束 → ⑧ 季度复盘生效的《公司技术栈与组件清单》（含版本和生效日期）、组件目录、偏离申请记录、回流 PR、写入 Agent 约束的共性规范待新建54
RND-17重大技术变更/重构报备与同步开发者准备重构/重写模块、更换方案或选型、修 bug 时会删改用户可见功能、关停高风险功能或下线接口、改关键设计口径、合入会影响他人仓库或接口的代码，或发现外部依赖风险时，事前报备并同步相关方主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、测试负责人（当前：张东郅·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）、变更摘要机器人维护人（当前：李铭熙·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 判定变更级别 → ② 写变更说明（影响面/回滚/测试建议）→ ③ @相关人征求意见 → ④ 按级别审批 → ⑤ 实施并在 PR 标注 → ⑥ 测试回归 → ⑦ 合入后自动通知 → ⑧ 每日变更摘要与日志已审批的变更说明、带“影响面”字段的 PR、合入通知记录、回归结果、变更日志条目待新建240
RND-18跨团队/跨系统接口对齐与集成约定两个以上研发组、产品或外部平台需要对接（账号/OIDC 登录、网盘、计费网关、订单与充值、开放平台、渠道系统、小程序互跳、底座与下游仓），要先对齐接口契约、数据唯一写入方、责任边界和降级方案，再并行开发与联调时启动主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——LeapCore 后端/运维（当前：宋祺睿·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 提跨组对接单 → ② 分派两端负责人与裁决人 → ③ 写对接方案（边界/数据主责/接口/时序/降级）→ ④ 评审定版契约 → ⑤ 提供方出 mock 并行开发 → ⑥ 按清单联调 → ⑦ 文档与配置归档 → ⑧ 后续变更版本通知定版的对接方案与接口契约（OpenAPI/事件 schema，单一文档源）、数据主责表条目、联调清单与问题表、外部对接的责任矩阵与协议待优化500
RND-19前后端接口变更、联调与废弃通知后端新增、修改、删除接口或字段，或一个功能同时涉及前端、后端、管理后台需要配套合并与联调时启动，直到前端完成对接、旧接口按兼容窗口下线为止主责——后端负责人（跃竞当前：王子明·推断待确认；工程咨询线当前：宋祺睿·推断待确认）；协同——前端负责人（跃竞小程序当前：魏小东·推断待确认；工程咨询线当前：季学森·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞产品经理（当前：陈雁·推断待确认）；兜底——各线负责人（跃竞当前：徐莉·推断待确认；工程咨询线当前：王皓南·推断待确认）① 判定变更类型 → ② 同 PR 更新 Swagger 与对接文档 → ③ 登记变更清单并通知前端 → ④ 配套 PR 关联合并 → ⑤ 推测试服后通知联调 → ⑥ 联调问题表闭环 → ⑦ 破坏性变更锁步发布 → ⑧ 兼容窗口后废弃更新后的 Swagger（以 dev 环境为准）和对接文档、接口变更清单条目、关联 PR、闭环的联调问题表、废弃接口下线记录待优化120
RND-20Agent 安全与权限控制设计自研或开源 Agent（LeapAgent、LeapAll 客户端、龙虾/OpenClaw、赛马 Agent）新增或变更命令执行、文件/存储访问、远控能力，或设计内部服务鉴权时，先过安全基线评审和安全测试，再发版主责——Agent 核心研发（当前：岳阳·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、安全攻防测试（当前：王皓南、邓乾·推断待确认）、基座网关/鉴权研发（当前：望政韬·推断待确认）、架构安全评审（当前：陈晖·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 安全需求登记定级 → ② 对照安全基线出方案 → ③ 安全评审定范围 → ④ 实现并提 PR → ⑤ 红队用例测试 → ⑥ 产品验收与免责文案 → ⑦ 发版门禁与审计留痕通过评审的安全方案、已合并的 PR、红队测试报告、更新后的安全基线清单、用户协议免责条款待新建240
RND-21新成员研发账号开通与开发环境搭建研发、测试、实习生入职，或在职成员加入新项目时，在到岗首日内开通账号权限、跑通本地或开发服环境，并完成首周上手任务主责——用人项目技术负责人（当前：Leap 线王皓南、跃竞线王子明·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、带教人（当前：岳阳、杨云峰、游家豪·推断待确认）、前端负责人（当前：魏小东·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 到岗前提交开通清单 → ② 运维批量开通 → ③ 安全交付凭证 → ④ 指定带教人和模块边界 → ⑤ 按文档跑通环境 → ⑥ 完成首周任务并交付产出 → ⑦ 把新踩的坑补进 FAQ开通清单全部勾选（权限到位）、环境跑通截图、首周上手文档、更新后的环境 FAQ待优化108
RND-22代码仓库创建、归属与权限新项目或新组件需要建仓库、散落的仓库需要迁入公司组织、成员需要开通/变更/回收仓库权限时启动主责——Gitea 管理员（当前：宋祺睿、李铭熙·推断待确认）；协同——仓库负责人（当前：待指定，按仓库台账逐仓登记）、迁移规划（当前：陈晖·推断待确认）、CI/CD 基建（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交建库/权限申请 → ② 管理员核对命名与归属 → ③ 直接在组织下建库并授权 → ④ 登记仓库台账 → ⑤ 初始化 README、分支保护和 CI → ⑥ 定期复核并回收权限建在公司 Gitea 组织下的仓库、仓库台账记录（用途/负责人/开发者）、按最小权限开通的访问权限待优化72
RND-23开发测试服务器/云资源/域名申请研发、测试或业务需要虚拟机、裸机、云服务器、数据库、对象存储、域名解析、端口/安全组、短信/邮件/内容审核等云服务或测试设备时，统一申请、开通、登记，到期时续费或释放主责——Agent Infra Owner（当前：宋祺睿·推断待确认）；协同——IT 运维（负责内网、机房、采购、云账号，当前：杨明学·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查资源台账和能力目录 → ② 提交资源申请 → ③ 选型与审批 → ④ 开通并安全交付 → ⑤ 登记台账 → ⑥ 到期提醒 → ⑦ 续费或释放可用的资源（含访问方式）、资源台账记录（用途/负责人/到期日/是否常驻/成本归属）、审批单、月度资源与成本报告待新建192
RND-24GPU 算力申请、租赁与采购部署、微调、评测或测速模型需要 GPU 时，先盘点公司的闲置卡；不够再走小额租用或采购询价；用完按期释放主责——IT 运维（算力资源管理，当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、需求方研发、财务负责人（当前：黄梦婷·推断待确认）；审批与兜底——CTO（当前：丁震宇·推断待确认）① 提交算力申请 → ② 估算需求并盘点闲置卡 → ③ 内部分配，或转外部方案 → ④ 询价比价 → ⑤ 审批 → ⑥ 开通交付并登记 → ⑦ 到期释放或退租分配到人的 GPU 资源（有台账记录）、询价记录、审批单、释放/退租记录待新建108
RND-25AI 编码工具账号/订阅/额度申请发放员工需要 Claude、Codex、Cursor 等 AI 编码工具的订阅、号池 key 或额度时（研发优先，非研发其次），以及额度耗尽、新人入职、离职回收、AI 补贴月度申报时主责——AI 资源管理员（号池/额度运维，当前：杨明学·推断待确认）；协同——研发负责人（审批，当前：王皓南·推断待确认）、入职工具配置（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查可用渠道和本人资格 → ② 提交额度申请 → ③ 部门负责人审批 → ④ 从号池或公司订阅发放，或改走补贴自购 → ⑤ 登记台账 → ⑥ 用量监控与告警 → ⑦ 到期续用或回收可用的个人子 key、席位或订阅（台账有记录）、审批单、月度用量报表、补贴核定结果待新建240
RND-26AI 工具/中转渠道采购、号池运维与封号应对官方渠道贵、易封号或中转不稳时，对 AI 模型渠道（官方订阅、企业版、云厂商、中转站、号商）做准入评估、对公采购付款、号池/网关运维交接与续费评估，以及处理账号被封、KYC、风控主责——AI 渠道与号池运维负责人（当前：杨明学·推断待确认）；协同——渠道评测（当前：王皓南、宋祺睿、魏宗浩·推断待确认）、内部 API 网关部署（当前：宋祺睿、吴世豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、信息安全（当前：待指定）、管理层（海外主体等重大事项，当前：常元和·推断待确认）；决策与兜底——CTO（当前：丁震宇·推断待确认）① 需求与用量测算 → ② 渠道评估与准入 → ③ 采购审批与对公付款 → ④ 接入统一网关并登记 → ⑤ 健康监控与故障切换 → ⑥ 到期续费评估 → ⑦ 封号应对与月度复盘渠道白名单和评估表、采购审批单与发票/对账凭证、渠道与号池台账、统一网关配置、封号事件记录、维护人交接清单待新建400
RND-27模型 API Key 与调用额度申请（统一接入站）研发、测试、产品或项目需要调用公司统一 AI 接入站（aiapi/NewAPI/MercAll）或云厂商模型，需新开 Key、加额度、区分测试/生产、更换失效 Key，或申请第三方云服务接口 Key、模型服务权限时启动；同时管 NewAPI 实例管理员与 2FA 治理，并约束模型调用只走公司指定渠道主责——AI 接入站经办管理员（当前：杨明学·推断待确认）；协同——预算审批人（当前：丁震宇·推断待确认）、网关技术负责人（当前：望政韬·推断待确认）、NewAPI 实例负责人（LeapCore 当前：柯逸飞·推断待确认；LeapAll 当前：邓乾·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、申请表单与自动化维护人（当前：陈晖·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 对照术语表选申请类型 → ② 填「统一AI接入配额申请」→ ③ 预算审批 → ④ 接入站建用户/令牌并设额度、IP、到期 → ⑤ 私密渠道发放（生产 Key 由环境运维注入）→ ⑥ 台账回写 → ⑦ 用量、渠道合规监控与阈值告警 → ⑧ 失效/超额处置 → ⑨ 到期回收与月度对账 → ⑩ 管理员名单与 2FA 定期审计按用途和环境隔离、设了额度上限的接入站令牌；台账记录（归属人/项目/环境/额度/到期）；月度按项目归集的消耗报表待优化144
RND-28AI 编码协作规范与质量管控研发、产品或其他成员用 Codex/Claude Code 等 AI 编码工具或多 Agent 协作写代码、做 Demo、产出分析结果时，必须遵守的事前准备、执行约束、自测审查和交付规则主责——研发技术负责人（AI 编码规范维护）（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、Agent/客户端核心研发（当前：岳阳·推断待确认）、产品总监（非研发使用方）（当前：杨萌·推断待确认）、各仓库 owner（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 界定范围并写任务书 → ② 仓库 AGENTS.md 就绪 → ③ 选模型分工（强模型写工单/验收，执行模型写代码）→ ④ 隔离环境、禁止碰生产 → ⑤ 执行中频繁 commit 与监工 → ⑥ 自测（单测+冒烟）→ ⑦ 独立 Agent 审查+人工 review → ⑧ 人话交付说明并回写踩坑到 AGENTS.md通过自测、独立审查和人工 review 的代码/PR；任务书与验收记录；更新后的 AGENTS.md待新建180
RND-29AI 工具使用经验沉淀、培训与互助排障员工使用 Claude Code/Codex/OpenCode/Gemini 等 AI 工具遇到报错、不可用、配置问题，或有新工具/新订阅上线、摸索出值得推广的新用法、需要换工具迁移上下文时启动主责——AI 工具文档维护人（tech writer）（当前：魏宗浩·推断待确认）；协同——AI 工具群答疑值守（当前：游家豪·推断待确认）、AI 工具渠道与供应商对接人（当前：丁震宇·推断待确认）、代理与网络支持（当前：杨明学·推断待确认）、skill 征集与推广（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 在 AI 工具群按模板报问题 → ② 值守人查 FAQ/渠道状态表并响应 → ③ 给出临时规避 → ④ 供应商故障统一对接并公告 → ⑤ 解决后沉淀 FAQ → ⑥ 新工具上线同步发集成教程 → ⑦ 新方法/skill 评审后推广 → ⑧ 月度更新与培训持续更新的《AI 工具使用手册》（含 FAQ、渠道状态表、集成教程）；新工具教程；推荐 skill/方法清单待优化64
RND-30研发编码与工程协作规范宣贯新团队开始协作、新人加入、出现编码风格/提交方式/本地环境/文档载体/群聊沟通问题，或规范新增变更时，统一制定、落地工具检查并宣贯主责——研发技术负责人（研发规范 owner）（当前：王皓南·推断待确认）；协同——前端规范维护人（当前：季学森·推断待确认）、后端与 Git 规范维护人（当前：宋祺睿·推断待确认）、ESLint/TS 规范维护人（当前：陈晖·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞各端规范维护人（当前：张楠、魏小东·推断待确认）、各仓库 owner（当前：待指定）、人事负责人（当前：黄莹·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 识别规范缺口 → ② 规范维护人起草/更新 → ③ 研发评审 → ④ 落库并工具化（lint、hook、CI、PR 模板）→ ⑤ 研发通知群发布变更 → ⑥ 纳入新人入职清单 → ⑦ PR 评审执行 → ⑧ 季度复审成文的《研发协作规范》及总索引；仓库内 AGENTS.md/CODE_STYLE/README 与 lint 配置；群公告中的沟通约定；新人规范阅读确认记录待优化36
RND-31Git 分支管理与协作规范新建仓库、开发新功能、多版本并行、准备发版或紧急修复，以及发生误推/强推、分支污染、源码外泄风险时，按统一分支模型、合并方式和保护规则操作主责——研发技术负责人（分支规范 owner）（当前：王皓南·推断待确认）；协同——Gitea 管理员/发版把关（当前：宋祺睿·推断待确认）、Leap 客户端仓库 owner（当前：岳阳·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）、产品经理（标注迭代）（当前：黄飞鹏·推断待确认）、法务（开源与源码保密）（当前：李瑶·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 建仓套模板（默认私有、主分支保护、禁强推、必须 PR）→ ② 从基线拉功能分支 → ③ 每日 rebase 基线、频繁提交推远端 → ④ PR 指向正确目标分支并标注迭代 → ⑤ 评审+CI 通过后人工合并 → ⑥ 发版前冻结并隔离下一版本代码 → ⑦ hotfix 合入后回合 → ⑧ 合并后删分支、核对分支状态所有仓库统一的分支模型与保护配置；每次合并有 PR 与评审记录；发版分支只含本版本已验收提交待新建144
RND-32PR 提交与代码评审合并研发（含产品/运营用 AI 写代码）完成功能或修复，需要把代码合入 Gitea 上 main/dev/test/hotfix 等共享分支时启动。主责——Leap 研发技术负责人（当前：王皓南·推断待确认），负责 PR 规范、仓库保护规则与评审人分配；协同——PR 作者（各研发）、各仓库 Code Owner 评审/合并人（当前：LeapNew/LeapLite/LeapAgent 岳阳；v5/LeapAuth 宋祺睿；LeapCore/Cloudreve/LeapUpdate 杨云峰；字字可研 frontend 季学森；跃玩后端 王子明、前端 魏小东·均推断待确认）、测试负责人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）；兜底——研发负责人/创始人兼 CTO（当前：丁震宇·部门报送人）① 工单先行建分支 → ② 自测 + AI 预审 → ③ 按模板提 PR 且 CI 通过 → ④ 自动指派评审人 → ⑤ 评审与修改（SLA 计时）→ ⑥ 合并并同步 hotfix → ⑦ 标测试、工单流转 → ⑧ 超时 PR 日报清理通过 CI、经至少 1 名 Code Owner 批准、关联工单、附自测证据并合入目标分支的 PR；每日待合 PR 清单有明确处理人。待优化120
RND-33AI 代码评审与夜间自动评审需要用 AI 对 PR 做首轮机审、对仓库做夜间批量审查，或对代码库做全库 Bug/技术债审计时启动。主责——AI 评审机制负责人（当前：王皓南·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认，Gitea 集成与日常 CR）、测试负责人（当前：张东郅·推断待确认，评审 skill）、跃玩后端负责人（当前：王子明·推断待确认，跃玩审计）、CI 负责人（当前：吴世豪·推断待确认，定时任务托管）、各仓库 Code Owner；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 定审查范围与触发方式 → ② 合规与成本审批 → ③ 统一 skill/提示词并部署到服务器 → ④ 自动运行（PR 触发/夜间定时/月度审计）→ ⑤ 结果回写 PR 或生成报告 → ⑥ 人工复核分级 → ⑦ 转工单整改 → ⑧ 月度误报与成本复盘PR 上的 AI 评审评论；每日夜间评审报告与月度全库审计报告（飞书文档）；按阻塞/建议/误报分级并已转为工单的整改项；月度成本与采纳率统计。待新建48
RND-34数据库 Schema 变更与迁移脚本功能涉及新增/修改/删除表、字段、索引，或需迁移/回填历史数据，并要推到测试库、生产库或已交付客户现场时启动。主责——产品线后端负责人（DB 变更放行人）（当前：Leap/字字可研 宋祺睿、跃玩 王子明·推断待确认）；协同——变更提交研发、研发技术负责人（当前：王皓南·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃玩运维（当前：席博田·推断待确认）、IT 运维/现场执行（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① PR 勾选 DB 变更并附迁移/回滚/回填脚本 → ② 登记变更表 → ③ 评审（含存量数据影响）→ ④ 测试库执行与新旧数据验证 → ⑤ 生产前快照 → ⑥ 生产执行（先库后服务）→ ⑦ 生产验证与登记回执 → ⑧ 客户现场升级同步版本化迁移脚本（含回滚、回填）、经评审并在测试库演练通过的变更记录、生产执行与验证记录、更新后的迁移文档。待新建180
RND-35数据库性能、慢 SQL 治理与数据库故障应急新增复杂查询（统计、排行、大表 JOIN、递归、导出）上线前，或生产数据库出现高负载、慢查询、连接池耗尽、OOM、闪断告警时启动。主责——产品线数据库/架构负责人（当前：跃玩 王子明·推断待确认；Leap 待指定）；协同——后端研发（当前：张楠、蒋兴武（跃玩），邓乾、柯逸飞（Leap）·推断待确认）、运维（当前：席博田·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、产品线业务负责人（当前：徐莉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 复杂 SQL 上线前 explain 评审 → ② 测试库验证与压测 → ③ 慢查询/连接/内存告警 → ④ 故障定级与指挥分工 → ⑤ 止损（杀会话/限流/超时/扩容）→ ⑥ 根因定位（含厂商工单）→ ⑦ 修复并压测后热修 → ⑧ 书面复盘与改进项跟踪复杂 SQL 评审与压测记录；故障处置时间线；书面复盘报告（根因、影响、改进项）；厂商工单与升配决策记录。待新建300
RND-36依赖版本锁定与供应链管理部署栈或构建依赖第三方镜像、语言模块、开源底座（如 OpenClaw）时，需要锁定版本、保证可复现构建、升级前回归，或上游异常导致构建/部署失败时启动。主责——研发基础设施/发布负责人（当前：宋祺睿·推断待确认）；协同——CI 负责人（当前：吴世豪·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、交付部署（当前：魏宗浩、游家豪·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 建依赖/镜像/底座版本清单 → ② 锁文件与固定版本入库 → ③ 镜像与包本地化 → ④ CI 校验（禁 latest、lock 一致）→ ⑤ 升级走 PR + 回归 → ⑥ 统一下发并通知各环境 → ⑦ 上游异常回退到已验证版本已验证版本清单；入库且由 CI 校验的锁文件；内部镜像仓库/代理中的依赖副本；升级回归记录与各环境同步状态。待新建72
RND-37CI/CD 流水线建设与构建资源管理需要新建或调整自动构建、nightly、镜像构建、测试门禁，或 runner/构建机/签名机出现慢、挂、排队、磁盘满、权限与凭据缺失时启动。主责——CI 负责人（当前：吴世豪·推断待确认）；协同——CI 备份负责人（当前：岳阳、宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：丁震宇·部门报送人）、跃玩运维（当前：席博田·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① CI 需求/故障登记 → ② 判定类型（流水线/资源/网络/上游/不稳定测试）→ ③ 资源申请审批 → ④ IaC 创建或配置 runner → ⑤ 按模板配置流水线与门禁 → ⑥ 监控告警与定时清理 → ⑦ 凭据与配置清单化 → ⑧ 月度容量复盘可用的 PR check、nightly、release、镜像流水线与门禁规则；runner/构建机清单（含负责人、访问权限、凭据存放）；监控告警与清理任务；资源申请审批记录。待优化180
RND-38CI/构建失败排查与恢复机器人推送 nightly/release/部署失败卡片，或 runner/签名机/CI 机掉线、主线单测失败、依赖拉取失败，导致 PR 无法合并、打不出包时启动主责——CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维/网管（当前：杨明学·推断待确认）、CI 备用维护者（当前：宋祺睿、岳阳·推断待确认）、信创/Linux 打包负责人（当前：李子遥·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 按模板报障 → ② CI 值班认领并初判类别 → ③ 分流到代码/脚本/机器/网络/签名责任方 → ④ 止血（切备用 runner、切镜像、降级） → ⑤ 重跑验证全链路 → ⑥ 恢复通知 → ⑦ 登记与复盘恢复为 SUCCESS 的流水线（含补跑的 nightly/release）、群内恢复通知、CI 故障登记记录；达到复盘条件的附复盘文档与长期措施工单待新建240
RND-39提测、产品验收与测试验收流转研发完成一个需求或缺陷修复、已部署到测试环境，需要经产品验收（是否符合需求）和测试验收（功能是否正确）后关闭工单时启动主责——研发负责人/工单流转规则负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 自测+合并+部署测试环境 → ② 按模板提测并指定验收人 → ③ 产品验收（需求类） → ④ 测试验收 → ⑤ 不通过打回修复 → ⑥ 通过关闭 → ⑦ 每日滞留巡检 → ⑧ 迭代末缺陷清零状态为“完成”的工单，评论区留有提测信息、产品验收结论、测试验收结论（含环境与版本/commit）；“完成”的口径是验收通过，标了 ready-for-test 不算完成待优化180
RND-40测试体系建设与测试设计评审新团队/新产品线没有专职测试或质量靠客户发现时，建立最小 QA 流程；每个迭代需求冻结后，测试编写测试设计并组织产研评审（测试前移）时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、产品经理（当前：杨萌、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 明确测试范围与 QA 状态 → ② 需求阶段测试前移 → ③ 编写测试设计与计划 → ④ 测试设计评审会 → ⑤ 用例入库与分级 → ⑥ 执行与缺陷流程 → ⑦ 自动化固化 → ⑧ 迭代回顾修订每个迭代一份评审通过的测试设计/计划（飞书文档）、入库的用例（level1 长期/level4 一次性）、评审结论回写需求表；新团队有一套最小 QA 流程（QA 状态、缺陷模板、冒烟集）待新建108
RND-41发版前测试冲刺与测试人力调配发版前测试积压、测试“卡脖子”，或多个项目同时争抢测试人力，需要集中按用例分工测试、临时抽调研发/产品/实习生时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、被抽调研发与测试（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 迭代初分配测试人力 → ② 判定是否进入冲刺 → ③ 出冲刺计划与用例认领表 → ④ 抽调人员并开对齐会 → ⑤ 认领执行与提单 → ⑥ 每日站会同步 → ⑦ 出测试报告并做 Go/No-Go → ⑧ 释放人员与复盘冲刺测试计划、用例认领表（全部用例有认领人和结果）、测试报告（通过/不通过/无法验收/新增缺陷/未关闭数）、Go/No-Go 结论待优化144
RND-42冒烟测试与核心用例回归新包/新版本部署到测试环境、发版上线前后、模型/渠道切换前、交付项目打包刻盘前，需要按核心用例冒烟回归并给出放行结论时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、发版研发（当前：宋祺睿、葛家和·推断待确认）、产品负责人（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 发版研发通知提测（版本、更新日志、修复清单） → ② 测试环境冒烟 → ③ 缺陷登记与分级（立即修/后续 OTA） → ④ 修复与定向回归 → ⑤ 放行签字 → ⑥ 发布后生产冒烟 → ⑦ 内测放量与记录归档 → ⑧ 冒烟用例维护带 PASS/FAIL 的冒烟记录（测试环境+正式环境）、放行结论（通过/有条件通过/不通过）、缺陷工单；内测版本附反馈收集入口待优化180
RND-43性能压测与容量评估新服务/新版本/新上游或新模型上线前、扩大推广或发券前、大规模集中使用（百人培训、大量席位）前，需要验证并发与容量并给出结论时启动主责——测试负责人（压测执行，当前：张东郅·推断待确认）；协同——被测服务研发（当前：马漳毓、邓乾、杨云峰·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、研发负责人（当前：王皓南·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 提交压测申请 → ② 确认容量目标 → ③ 准备环境与数据（mock 上游、隔离、备份） → ④ 发布压测窗口公告 → ⑤ 执行（探测→基准→容量→稳定性） → ⑥ 出报告与结论 → ⑦ 优化后复测 → ⑧ 恢复清理并发结束通知按模板的压测报告（场景、并发档位、QPS/RPM、成功率、耗时分布、瓶颈、容量结论），原始数据（CSV/JSON）归档，压测窗口的起止公告待优化192
RND-44上线前安全测试、资金逻辑专项测试与漏洞修复产品对外开放下载/发布、政府或对外平台上线、涉密客户交付、涉及余额/支付/退款/兑换券/验证码的功能提测前做安全与资金专项检查；或上线后发现可利用漏洞需要紧急修复时启动主责——测试负责人（专项测试与复测，当前：张东郅·推断待确认）；协同——项目研发负责人（当前：王皓南·推断待确认）、IT 运维/安全加固（当前：杨明学·推断待确认）、安全测试支持（当前：宋祺睿、邓乾·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、产品负责人（当前：杨萌、徐莉·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 识别触发并选清单 → ② 自动扫描（源码/依赖/安装包/AI 渗透） → ③ 人工专项测试（安全+资金） → ④ 漏洞登记与分级 → ⑤ 修复与复测 → ⑥ 门禁签字放行 → ⑦ 上线后漏洞热修与通告逐项打勾的上线安全门禁清单、资金类测试覆盖表、漏洞工单（含分级、影响面、修复、复测结论）、放行签字；上线后漏洞附 hotfix 记录待新建240
RND-45AI 辅助与自动化测试验收工单转入产品验收或测试验收时，用 AI 机器人生成“实现锚定需求”和测试用例，或用 e2e/浏览器自动化脚本对功能和历史缺陷做回归验收时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、自动化脚本维护研发（当前：魏宗浩·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试工程师（当前：黄霆瑄·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）① 转产品验收时触发 AI 扫代码生成实现说明 → ② 产品确认验收口径、研发/测试确认测试锚点 → ③ 冻结锚点 → ④ 转测试验收时 AI 生成用例并执行 → ⑤ 报告回写工单 → ⑥ 人工抽检并签字 → ⑦ 统计可信度、调整门禁工单评论中的“实现锚定需求”（已冻结）、AI 执行报告（用例、步骤、截图、结论），以及人工抽检签字；AI 结论只作参考，验收通过须由人确认待新建36
RND-46UI 设计交付与视觉/交互走查新界面或改版需要设计稿，或界面功能开发完成后，需要设计师、产品、测试对照设计稿和既有版本检查样式与交互一致性时启动主责——UI/UX 设计师（当前：康紫馨·推断待确认）；协同——产品总监/产品经理（当前：杨萌、陈震·推断待确认）、前端研发（当前：葛家和、岳阳、魏宗浩、吴世豪·推断待确认）、测试（当前：黄霆瑄、涂维轩·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 登记设计需求 → ② 出 Figma 稿与交付清单 → ③ 研发按稿还原 → ④ 提交走查（截图+版本+对照稿）→ ⑤ 设计走查出问题单 → ⑥ 争议一次性拍板 → ⑦ 修复并做 PR 一致性审查 → ⑧ 视觉验收收口并沉淀规范挂在工单上的设计稿与交付清单、已关闭的 UI 走查问题单、附改前/改后截图的 PR、视觉验收结论、更新后的设计规范/组件库待优化108
RND-47测试账号、测试额度与测试数据管理测试、验收、内测或演示前需要测试环境账号/企业/管理员权限/模型余额/测试数据，或测试服上游额度耗尽、测试数据需要造数或清理时启动主责——测试负责人（当前：张东郅·推断待确认）；协同——后端/运维（当前：宋祺睿、魏宗浩·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 提交测试资源申请 → ② 审核并优先从账号池分配 → ③ 新建账号/企业并按标准额度配置 → ④ 凭据安全发放、台账登记 → ⑤ 余额预警补额 → ⑥ 真实充值先审批后付款 → ⑦ 造数与到期清理 → ⑧ 月度对账回收可用的测试账号/企业/权限与额度、测试账号台账、余额预警与补额记录、测试服充值审批单与月度对账单、测试数据清理记录待新建240
RND-48开发/测试/生产环境分层与共享环境占用新建或调整环境用途，多人共用同一测试/演示机器需要占用、改配置、切模型 tag、清理、重装、换机或挪网段，或产品从内测转公测需要拆分生产与测试环境时启动主责——环境与基础设施负责人（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 制定环境分层规范 → ② 登记环境台账 → ③ 占用/变更申请 → ④ 冲突协调与冻结窗口 → ⑤ 变更前公告 → ⑥ 备份后执行 → ⑦ 更新台账并通知 → ⑧ 季度盘点回收成文的环境分层规范；实时更新的环境台账（环境/层级/地址/版本/负责人/数据级别/占用状态/冻结期）；占用与变更记录待新建320
RND-49测试环境部署与更新通知代码合入 dev/test 或需要验证某组件时，把服务（Agent、v5 cloud/edge、LeapAuth、Cloudreve、LeapUpdate、前后端）部署到测试环境，并在更新前预告中断、更新后通知验收时启动主责——测试环境发布负责人（当前：魏宗浩·推断待确认）；协同——CI/CD 与环境运维（当前：宋祺睿、杨云峰·推断待确认）、代码提交者（各研发）、测试负责人（当前：张东郅·推断待确认）、产品经理（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① PR 合并入待发布队列 → ② 发布预告并收集搭车 → ③ 加发布锁 → ④ 核对来源分支后构建 → ⑤ 部署/滚动更新 → ⑥ 完成播报版本与变更 → ⑦ 失败@提交者修复或回滚 → ⑧ 工单转测试验收测试环境运行指定版本；发布预告与完成通知（环境、组件、版本/commit、变更清单）；环境台账版本字段更新；失败修复或回滚记录待优化135
RND-50版本封版、打 tag 与发布分支管理迭代到期或对外发版节点前，需要盘点随版本发布的工单、执行 P0 清零闸门、冻结代码、打 rc/正式 tag、拉发布/hotfix 分支并剥离下一版本代码时启动主责——版本负责人（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、发版执行人（当前：柯逸飞、岳阳、宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）① 公布发版日历 → ② 工单收口与范围确认 → ③ P0 清零闸门 → ④ 冻结代码 → ⑤ 全仓库打 rc tag、建 hotfix 分支 → ⑥ rc 冒烟与放行 → ⑦ hotfix 双向合入核对 → ⑧ 打正式 tag 交接发布发版清单（版本范围、仓库×tag×分支×负责人）、全仓库 rc/正式 tag、hotfix/vX 分支、测试放行结论、移出版本的工单清单待新建240
RND-51正式版本发布上线测试验收通过的迭代版本或 hotfix，需要部署到内部生产（如 102）、对外正式服或客户环境（OTA），涉及服务端、客户端 OTA、agent 镜像、管理后台、配置中心等任一组件上线时启动。主责——版本发布负责人（当前：宋祺睿·推断待确认）；协同——研发负责人（放行决策，当前：王皓南·推断待确认）、客户端/OTA 发布（当前：岳阳、葛家和、邓乾·推断待确认）、测试负责人（当前：张东郅；字字可研线：李国庆·推断待确认）、产品负责人（当前：杨萌·推断待确认）、基础设施与 CI（当前：杨云峰、吴世豪·推断待确认）、客户经理（当前：吴琪·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）① 建发布单定窗口 → ② 封版与组件清单核对 → ③ 测试环境回归与放行签字 → ④ 备份与发布前检查 → ⑤ 按序部署（迁移→服务端→后台/配置→客户端 OTA） → ⑥ 生产冒烟与放行/回滚 → ⑦ 发布公告与中文更新日志 → ⑧ 观察期后关闭发布单生产/客户环境运行指定版本；关闭状态的发布单（版本号、组件、冒烟结论、回滚点）；对内对外发布公告与中文更新日志。待优化500
RND-52客户端打包、签名与安装包分发需要新版 Windows/macOS（含 Linux/信创）客户端安装包——nightly、beta/测试、正式、hotfix、客户定制或渠道包——时，从 CI 打包、签名公证、冒烟、上传下载入口、配置 OTA 到群内通知的全过程；也包括签名证书的采购与有效期管理。主责——客户端发版负责人（当前：岳阳·推断待确认）；协同——打包执行/CI（当前：葛家和、吴世豪、李铭熙·推断待确认）、签名与证书保管（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、OTA 配置（当前：邓乾、葛家和·推断待确认）、产品与版本台账（当前：杨萌、杨黔昆·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务（证书采购开票，当前：黄梦婷·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）① 登记打包申请与版本号 → ② 签名预授权 → ③ CI 多平台构建 → ④ 签名与公证 → ⑤ 冒烟放行 → ⑥ 上传 COS 并更新版本台账/下载页 → ⑦ 配置 OTA 渠道（先灰度） → ⑧ 机器人推送发布卡片并观察带正确版本号与签名的各平台安装包；版本台账中一条完整记录（含下载链接与测试结论）；已配置的 OTA 渠道；固定群内置顶的发布卡片。待优化320
RND-53OTA 在线更新与强制更新LeapCore/LeapAll 客户端、容器镜像或 updater/stack 组件的新版本（含 hotfix）已测试通过，需要在 LeapUpdate 配置授权与渠道并推送 OTA，或者要强制淘汰旧版、撤回发错的版本时启动主责——客户端发布与 OTA 负责人（当前：岳阳·推断待确认）；协同——OTA 推送与安装包管理（当前：葛家和·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapUpdate 维护（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、对客沟通产品经理（当前：黄飞鹏·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 兼容性检查（服务端先行）→ ② LeapUpdate 登记版本、渠道、授权与最低可用版本 → ③ 内部渠道灰度 → ④ 升级冒烟 → ⑤ 按窗口全量推送并发公告 → ⑥ 核对版本分布，强制升级旧版 → ⑦ 发错版本时撤回LeapUpdate 中一条完整的版本发布记录（版本号、渠道、灰度范围、最低可用版本、是否强更）；推送完成并验证过的客户端/容器版本；公告群升级通知；版本分布统计待优化240
RND-54Hotfix 紧急修复准入与发布线上（生产 102、正式服、客户实例）出现阻塞使用或严重影响体验的缺陷，或者有经批准插队的紧急需求，需要绕开常规迭代、基于线上版本快速修复并发布时启动主责——Hotfix 流程负责人（当前：王皓南·推断待确认）；协同——客户端 hotfix 打包发布（当前：岳阳·推断待确认）、服务端 hotfix 部署（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（准入与紧急程度判定，当前：杨萌·推断待确认）、OTA 与签名（当前：葛家和·推断待确认）、Update 与 Agent 镜像（当前：杨云峰、魏宗浩·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提 hotfix 申请 → ② 准入判定 → ③ 从线上 tag 建 hotfix 分支并 cherry-pick → ④ 定时冻结并比对清单 → ⑤ 51 验收环境回归 → ⑥ 生产发布与 OTA → ⑦ 发布核对与公告 → ⑧ 回合主干并关单一张关闭的 hotfix 申请单（含影响面、提交清单、测试结论、回滚方案）；新的小版本 tag 与生产部署；客户端 OTA；群内 hotfix 公告；修复已回合 main待新建400
RND-55Agent 容器镜像构建与发布Agent 代码、Dockerfile（时区、字体、办公库等）、内置 Skill 清单或运行配置有变更，需要构建 leapagent 容器镜像（含 hotfix 镜像），发布到测试(50)、生产(102)或客户环境时启动主责——Agent 镜像与 CI 负责人（当前：宋祺睿·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Skill 打包（当前：魏宗浩·推断待确认）、容器部署与 LeapUpdate 渠道（当前：杨云峰·推断待确认）、生产构建发布（当前：柯逸飞·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 代码与 Skill 清单入库 → ② CI 构建并推送镜像仓库（tag 带版本、commit、渠道）→ ③ 50 测试 → ④ preview 渠道灰度 → ⑤ stable 发布到生产/客户 → ⑥ 发布验证与通知 → ⑦ 登记版本与交接镜像仓库里带版本 tag、哈希和 changelog 的 leapagent 镜像；LeapUpdate 渠道配置记录；50/102/客户实例的验证记录；发布通知待优化144
RND-56产品 Skill 开发、评审、上架与内置发布新增或更新面向用户的产品 Skill（内置、官方、开放平台、企业专属、付费），需要开发自测、质量与安全评审、确定分级、打包或上架下发，以及处理版本更新、回滚、下架和用户修改覆盖时启动主责——Skill 发布负责人（当前：魏宗浩·推断待确认）；协同——Skill 质量评估（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Agent/内置 Skill 代码评审（当前：岳阳·推断待确认）、产品总监（分级与下发决策，当前：杨萌·推断待确认）、Leap 研发技术负责人（规则与术语，当前：王皓南·推断待确认）、付费 Skill 与 LeapSkill 后台（当前：李铭熙·推断待确认）、法务负责人（版权与合作，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 在 Skill 台账登记来源与作者 → ② 按 LeapSkill 规范开发、跑 selfcheck → ③ PR 进 Skills 仓库 → ④ 质量、安全、版权评审 → ⑤ 定分级（内置/官方/开放平台/企业）→ ⑥ 打包随镜像发布或上架下发 → ⑦ 发布通知与反馈收集 → ⑧ 版本更新、回滚与下架Skills 仓库或开放平台里一个合规的 Skill 版本（manifest、版本号、display_name、来源与许可齐全）；Skill 台账条目（分级、负责人、渠道、计费方式）；评审记录（含 review_rank）；发布通知待新建320
RND-58生产变更管控（备份、灰度、配置、访问审批）要对生产环境做任何变更时启动，包括：生产版本部署、DNS/证书切换、网关升级、数据库结构或数据手工改动、镜像手工调整、环境变量与密钥配置、Pulumi/infra 变更、功能灰度名单调整、旧环境维护与环境迁移主责——生产变更审批人（当前：王皓南·推断待确认）；协同——生产发布执行人（当前：宋祺睿·推断待确认）、基础设施与网关运维（当前：杨明学·推断待确认）、LeapCore 部署（当前：杨云峰·推断待确认）、LeapAll 服务端（当前：邓乾·推断待确认）、跃竞后端与运维（当前：王子明、席博田·推断待确认）、开放平台（当前：郭逸非、吴亚军·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提交生产变更申请（内容、窗口、影响、回滚、验证人）→ ② 按等级评审 → ③ 申请限时访问权限 → ④ 变更前在线备份 → ⑤ 窗口内执行，一人执行一人复核 → ⑥ 灰度并观察 → ⑦ 验证与通知 → ⑧ 关单留痕，或回滚每次生产变更一条审批记录（含备份位置、执行人、复核人、回滚方案、结果）；变更日历；灰度名单配置记录；生产系统一主二备值班表待新建240
RND-59线上部署回滚新版本上线后关键功能（支付、退款、分账、登录、数据加载）出现异常，且短时间内无法修复，需要先止血（封入口或回滚到上一个已知正常版本），或者回滚后发现版本不对需要纠正时启动主责——后端负责人（回滚执行）（当前：王子明·推断待确认）；协同——运维（当前：席博田·推断待确认）、后端研发（核对基线，当前：蒋兴武·推断待确认）、前端负责人（当前：魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、业务负责人（拍板回滚或封禁入口，当前：徐莉·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 按模板报障 → ② 10 分钟内做止血判定（封入口/回滚/直接修）→ ③ 确定回滚目标 commit sha 并二次确认 → ④ 执行回滚（先评估数据库兼容）→ ⑤ 比对基线、回归核心用例 → ⑥ 通知相关方 → ⑦ 修数据、补回遗漏功能后重新上线 → ⑧ 复盘回滚记录（原因、目标 sha、执行人、确认人、时间、影响）；回滚后的回归结论；回滚通知；数据修复和重新上线记录；复盘文档待新建180
RND-60小程序/App 商店提审与上架小程序（星域、PeRo/猩球、弈荟等）新版本验收通过、需要提交微信审核并发布，或遇到审核驳回、类目缺失、主体变更、保证金和年审；LeapCore 移动端要上架 iOS App Store（含国区 App 备案）时启动主责——小程序/App 提审负责人（当前：魏小东·推断待确认）；协同——会员端提审（当前：郝智豪·推断待确认）、业务负责人（类目、加急、保证金、虚拟支付决策，当前：徐莉·推断待确认）、产品验收（当前：陈雁、段涵·推断待确认）、iOS 上架（当前：岳阳·推断待确认）、备案（当前：杨明学·推断待确认）、总经办用印（当前：田杰·推断待确认）、法务负责人（协议文案合规，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 产品验收通过 → ② 提审前合规自查（测试数据、类目、协议、虚拟商品/支付、素材）→ ③ 提审并登记 → ④ 跟踪审核 → ⑤ 驳回处理（查驳回原因库、修改、申诉或加急）→ ⑥ 过审发布并通知 → ⑦ 维护主体/类目/保证金/年审台账过审并发布的小程序/App 版本；提审记录（版本、提交时间、结果、驳回原因与处理）；驳回原因库与应对话术；主体、类目、保证金、年审台账；iOS 上架材料包待新建240
RND-61客户演示前版本冻结与演示环境准备已确定客户/领导/媒体演示、POC 演示或上线评审答辩的时间，需要在演示前冻结研发改动并备好环境、数据、账号、skill 和第三方额度主责——产品总监/演示统筹（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、基础设施工程师（当前：葛家和·推断待确认）、测试负责人（当前：张东郅·推断待确认）、演示方（销售/FDE，当前：吴琪、李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 登记演示 → ② 涉密与范围判定 → ③ 定演示人与版本 → ④ 宣布冻结窗口 → ⑤ 备环境/数据/账号/额度 → ⑥ 彩排自检 → ⑦ 演示与现场保障 → ⑧ 解冻与复盘一份已签核的《演示准备单》、一个冻结且可用的演示环境（含数据、账号、skill、额度）、一次彩排记录与演示后复盘待新建180
RND-62内部 Demo/原型/静态页面部署员工（含非研发）用 AI 做出 Demo、原型或 HTML 页面，需要给同事、领导、外部用户或客户访问主责——运维/发布工程师（当前：宋祺睿·推断待确认）；协同——IT 运维/网管（域名、服务器，当前：杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、申请人；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 提交部署申请 → ② 判定访问范围与类型 → ③ 分配位置/端口/子域名 → ④ 仓库归入组织 → ⑤ 部署并安全检查 → ⑥ 发布预览链接 → ⑦ 登记 Demo 台账 → ⑧ 到期回收可访问的预览链接（已备案域名、HTTPS），Demo 台账中的一条登记记录（含负责人、访问范围、到期日）待新建54
RND-63信创适配开发、打包与验收市场/销售/客户提出新的"芯片 × 操作系统"适配需求，或主线出新版本需要出信创包、测试、修复并对外同步适配状态主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——产品总监/项目统筹（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、客户端研发（当前：岳阳·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、IT 运维（构建机/测试机，当前：杨明学、游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 需求登记 → ② 周评审定优先级 → ③ 借机/备环境 → ④ 流水线构建出包 → ⑤ 矩阵测试出报告 → ⑥ 缺陷提单分诊 → ⑦ PR 合入与 hotfix 回移 → ⑧ 按口径更新适配表并对外同步可下载的信创安装包（含 commit 与 jobset 标识）、测试报告（通过/有条件通过/不通过）、适配多维表格中更新的状态、对外口径说明待优化256
RND-64行业版插件开发、接入规范与交付工程/投资/法律/招投标等行业功能以插件或 skill 接入 LeapCore，需要按规范开发、测试验收、确定版本号并下发到指定企业实例；子公司或外部团队要接入 Leap 平台主责——行业版负责人/产品总监（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、插件研发（当前：侯怡辰、陈锦杰·推断待确认）、FDE/skill 下发（当前：邓乾·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、运维/实例配置（当前：宋祺睿·推断待确认）、测试（当前：李国庆·推断待确认）、业务验收（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 立项与规范对齐 → ② 按插件规范开发 → ③ 提测 → ④ 业务/产品验收 → ⑤ 定版本号与发版方式 → ⑥ 下发前检查 → ⑦ 测试机先发再发企业实例 → ⑧ 台账登记与回滚通过验收的插件/skill 包（含版本号）、更新后的"企业-实例-行业版-已下发版本"台账、下发记录待优化400
RND-65移动端研发协作与构建发布LeapCore 手机端/录音卡由外部伙伴承接开发，需要明确里程碑、接口文档、缺陷管理、APK/iOS 构建与内测分发、测试放行主责——外部协作负责人/产品总监（当前：杨萌·推断待确认）；协同——产品经理（当前：黄飞鹏·推断待确认）、客户端研发（接口与构建，当前：岳阳·推断待确认）、会议接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：潘浩伟、余超·推断待确认）、IT 运维（Apple 账号/证书，当前：杨明学·推断待确认）、外部开发团队（当前：外部伙伴）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 立项定里程碑 → ② 原型与接口清单交付 → ③ 每日同步 → ④ 接口文档变更通知 → ⑤ 构建与内测分发 → ⑥ 测试提缺陷 → ⑦ 修复验收 → ⑧ 放行结论与公测按里程碑交付的 APK/iOS 内测包、维护中的移动端 API 文档（含变更日志）、测试报告与放行结论待优化320
RND-66支付功能联调与收款商户管理支付/网银/电子签功能开发需真实小额付款联调；产品需按 2B/2C 选择或切换收款商户；线上出现到账延迟、回调异常、分账失败主责——支付研发工程师（当前：陈锦杰·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务（经办，当前：刘梦可·推断待确认）、支付渠道对接人（当前：徐莉·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAll 对接研发（当前：邓乾·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 测试付款申请 → ② 小额真实联调 → ③ 商户路由规则确认 → ④ 切换前检查 → ⑤ 切换与一元验证 → ⑥ 监控与对账 → ⑦ 异常处置 → ⑧ 复盘联调通过记录与测试付款报销凭证、商户路由配置（产品↔主体↔商户）、切换检查单、支付异常处置与复盘记录待新建160
RND-67新模型/上游渠道/第三方 API 接入与上线验证产品、客户或内部需要新模型、新上游渠道或第三方付费 API（OCR、企业数据、搜索、生图、视频），需完成 key 申请、网关接入、参数规则、价格配置、测试服验证、生产上线与下游同步主责——模型网关研发负责人（当前：柯逸飞·推断待确认）；协同——上游渠道/aiapi 维护（当前：杨明学·推断待确认，备岗：吴世豪·推断待确认）、研发技术负责人（网关架构，当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户本地 NewAPI 配置（当前：李铭熙·推断待确认）、LeapAll NewAPI（当前：邓乾·推断待确认）、财务（充值，当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 接入需求登记 → ② 成本对比与是否接入 → ③ key/额度申请 → ④ aiapi/v5 网关配置渠道与价格 → ⑤ 测试服部署 → ⑥ 冒烟/稳定性/价格验收 → ⑦ hotfix 上生产并观察 → ⑧ 下游同步与通知生产可用的模型/API（含渠道、模型 ID、价格、fallback）、模型上架台账记录、验收结论（工单评论）、下游（LeapCore/LeapAll/客户本地）同步完成通知待优化400
RND-68模型与上游供应商选型评测出现更便宜/更稳的上游渠道、新模型、新 OCR 或工具，或客户硬件变化需要选型，需做质量 bench、测速、成本与折扣核算，决定是否采用主责——模型供应商与评测负责人（当前：待指定）；协同——测试负责人（当前：张东郅·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、模型评测（当前：董洪焜、魏宗浩·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维/硬件测速（当前：杨明学、游家豪·推断待确认）、基座研发负责人（客户本地模型，当前：望政韬·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 登记评测需求 → ② 定评测范围、预算与负责人 → ③ 开评测账号/额度 → ④ 跑固定评测集（质量/速度/稳定性） → ⑤ 成本与折扣核算 → ⑥ 出评测报告 → ⑦ 选型决策 → ⑧ 结论入库并转接入一份标准评测报告（质量、速度、稳定性、成本、结论），评测记录多维表格中的一条记录，采用时转 RND-67 的接入工单待新建108
RND-69模型定价、倍率与成本价配置新模型上架、上游调价/折扣开通或到期、峰谷分时计价上线、汇率或倍率决策变更时，把成本价换算成对外价，并同步到 AIAPI、LeapCore/LeapAll NewAPI、v5 网关及客户本地网关主责——模型价格维护人（当前：柯逸飞·推断待确认）；协同——AIAPI 上游成本维护（当前：杨明学、吴世豪·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 价格变更登记 → ② 核成本价（四价、阶梯/分时、汇率） → ③ 定倍率与对外价 → ④ 测试服配置 → ⑤ 账单级验价 → ⑥ 生产及各下游同步 → ⑦ 通知产品/财务并更新台账已生效且验价通过的各网关价格配置；更新后的“模型价格台账”（成本价、倍率、对外价、生效日、核价人）及变更记录待优化240
RND-70计费准确性验证与账单/缓存对账计费/扣费/预扣功能上线前提测；用户或内部发现扣费异常；新模型/新折扣上线后要对照上游账单核实；缓存命中率异常；需要按主体账号归集模型成本主责——计费测试与对账负责人（当前：张东郅·推断待确认）；协同——计费研发（当前：邓乾、柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、AIAPI 上游成本维护（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提测/异常登记 → ② 准备测试账号与观测点 → ③ 固定请求集跑数 → ④ 比对平台扣费、配置价与上游账单 → ⑤ 定位差异 → ⑥ 修复与退补 → ⑦ 周度对账报告计费验证报告（预期 vs 实际）；差异处理记录（含退补决定）；每周上游账单与平台扣费对账表；按主体归集的模型成本表待新建135
RND-71模型档位路由与渠道切换变更因成本变化、模型升级或故障恢复后调整，需要新增/切换/删除上游渠道，或调整 LeapCore/LeapAll 经济/标准/专家档对应模型与思考强度、生图主通道与 fallback 时启动（计划内变更）主责——模型路由变更执行人（当前：柯逸飞·推断待确认）；协同——AIAPI 渠道维护（当前：杨明学·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提变更单 → ② 方案拍板 → ③ 先加新渠道不动旧 → ④ 测试服切换 → ⑤ 回归测试 → ⑥ 窗口内切生产并盯日志 → ⑦ 同步价格与下游 → ⑧ 发公告保留回滚点 → ⑨ 观察期后下线旧渠道已完成并验证的路由/渠道变更；变更单（含回归结果、回滚点）；更新后的“渠道-模型-档位”台账；变动通知群公告待优化240
RND-72上游模型故障告警响应与降级告警机器人推送“AI 上游连续失败/模型探测异常”、官方状态页发布事故，或用户/测试反馈超时、502/429/503、降智、余额耗尽导致不可用时启动主责——AI 网关值班人（当前：杨明学·推断待确认）；协同——LeapCore 网关研发（当前：柯逸飞·推断待确认）、V5 网关备用维护（当前：吴世豪·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、字字可研研发（当前：侯怡辰、陈锦杰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 告警/反馈 → ② 值班认领 → ③ 定级 → ④ 定位故障层级 → ⑤ 止血（切备线/降级/禁用） → ⑥ 内外通报 → ⑦ 恢复验证 → ⑧ 复盘在时限内止血并恢复的服务；故障工单（定级、根因、处置、时间线）；对内对外通知；P0/P1 复盘记录待优化375
RND-73上游账户余额、凭证到期与 Token 消耗管控产品依赖的上游模型账户（模型厂商官方账户、云厂商 A/B 的模型平台、算力平台、中转站等）与第三方服务凭证（如文档解析 Token）需要日常监控余额、到期和用量，以及内部测试需要额度 Key 时启动主责——上游账户与凭证管理员（当前：杨明学·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、计费研发（当前：邓乾·推断待确认）、CI/网关研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 账户与凭证入台账 → ② 设余额/到期阈值 → ③ 每日用量播报 → ④ 低于阈值预警 → ⑤ 充值审批与付款 → ⑥ 到账确认 → ⑦ 凭证到期前续期 → ⑧ 测试 Key 限额发放与回收 → ⑨ 月度复核完整的上游账户与凭证台账；每日用量与余额播报；欠费中断为零；测试 Key 发放与回收记录待新建72
RND-74NewAPI/AI 网关部署、升级与值守新建 API 中转分站（如 LeapOne、OPC 社区网关、产品线专用站）、网关版本升级或安全漏洞修复、生产服迁移、新增反代层或协议兼容、网关维护人变更交接时启动主责——AI 网关负责人（当前：杨明学·推断待确认）；协同——网关备用维护（当前：柯逸飞、吴世豪·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、分站部署研发（当前：黄振锋·推断待确认）、LeapAll 部署（当前：邓乾·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求与容量评估 → ② 服务器申请 → ③ 按基线部署（反代超时、安全组） → ④ 部署检查 → ⑤ 功能测试与压测 → ⑥ 窗口内切换上线 → ⑦ 纳入监控与台账 → ⑧ 值守与交接按基线部署并压测通过的网关实例；网关台账（实例、版本、域名、调用链拓扑、负责人）；升级/迁移记录；权限交接清单待优化96
RND-75线上/测试环境故障响应与复盘生产、测试、客户私有化或内网环境出现服务不可用或大面积报错（OOM、连接池满、磁盘满、证书到期、网络中断、网关超时、容器挂、支付回调丢失、生成任务批量卡死等）时，从报障、定级、指定指挥人、止血恢复、状态同步与对客口径，一直到事故报告和改进项闭环主责——故障指挥人（各产品线技术负责人；当前：王皓南·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/网管（当前：杨明学·推断待确认）、客户端/Agent 研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监/对客通报（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 报障建卡 → ② 定级并指定指挥人 → ③ 首次通报 → ④ 定位与止血 → ⑤ 定时同步进度 → ⑥ 恢复确认与对客通知 → ⑦ 事故报告与复盘 → ⑧ 改进项转工单闭环故障台账记录（级别、影响面、时间线）；恢复通报；P0/P1 事故复盘报告（存入统一目录）；已排期的改进项工单待新建500
RND-76用户问题日志收集与定位单个用户或测试报“执行失败、卡死、白屏、400/401/402、生图/PPT 失败、启动失败”时，按清单一次收齐版本、环境、模型档位、截图、trace_id 和诊断包；研发据此逐层定位（客户端 → 内网服务 → 公网服务 → 网关 → 上游），回复结论或建单主责——客户端问题定位接口人（当前：岳阳·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapCore 服务端/部署研发（当前：杨云峰、宋祺睿·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）、LeapPPT/生图研发（当前：马漳毓·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 用户按清单反馈 → ② 机器人补问缺项 → ③ 一键上传诊断包并关联工单 → ④ AI 初判 → ⑤ 研发逐层定位 → ⑥ 复现确认 → ⑦ 回复结论/绕行办法并建单 → ⑧ 沉淀 FAQ带完整环境信息和日志链接的问题工单；给反馈人的定位结论或临时绕行办法；更新后的常见错误 FAQ待优化120
RND-77错误提示、日志上报与可观测性规范新功能开发、客户端/网关/后端改造，或复盘发现报错“看不懂、查不到、对不上”时，按统一规范设计用户可见的错误提示、错误码映射、贯穿全链路的 trace_id、错误上报（PostHog/Grafana）以及日志保留与降噪，并在评审和 CI 中检查主责——可观测性负责人（当前：魏宗浩·推断待确认）；协同——Leap 研发技术负责人（当前：王皓南·推断待确认）、客户端研发（当前：岳阳·推断待确认）、v5 网关研发（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 汇总问题 → ② 起草/修订规范 → ③ 评审发布 → ④ 开发落地 → ⑤ CI 与测试校验 → ⑥ 线上抽查与降噪 → ⑦ 版本化修订《错误提示与可观测性规范》（错误码字典、提示文案、trace_id 规则、上报字段、环境区分、数据保留策略）；规范落地的代码和 CI 检查；统一的查询入口页待新建81
RND-78生产告警认领、分级与降噪监控机器人推送生产告警（Grafana 错误日志检测、EasyPlay 告警、死信队列告警、Redis Sentinel、定时巡检任务告警）时，负责认领、分诊、修复和关闭；同类误报反复出现时，调整阈值、日志级别、通知对象和模板，且变更前先在测试群验证主责——告警值班人（建议按周轮值；当前：王子明·推断待确认）；协同——跃竞运维（当前：席博田·推断待确认）、跃竞后端（当前：蒋兴武、张楠·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）① 告警分级推送 → ② 值班认领 → ③ 分诊（真实故障/业务异常/误报/第三方）→ ④ 指派或升级 → ⑤ 处置 → ⑥ 关闭登记 → ⑦ 每周降噪 → ⑧ 规则变更先测后发每条告警都有认领人和处置结论（台账记录）；《告警分级与日志级别规范》和忽略清单；经测试的告警规则/模板变更记录待优化80
RND-79服务器容量治理与内部研发基础设施故障服务器磁盘/日志暴涨、系统参数（inotify、磁盘类型、分区）不满足部署基线，或 Gitea/CI/NAS/内网服务器断网掉电、硬件损坏、服务迁集群或改地址时，做容量基线检查、日志轮转、故障报修排期和地址变更通知主责——IT 运维/基础设施负责人（当前：杨明学·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、开放平台后端/运维（当前：杨睿·推断待确认）；兜底——研发负责人（创始人兼 CTO）① 建立服务台账 → ② 部署前基线检查 → ③ 容量监控告警 → ④ 报修建单 → ⑤ 响应与排期 → ⑥ 清理/扩容并补治理 → ⑦ 变更前公告 → ⑧ 验证并更新台账服务器与服务台账（服务、负责人、地址、磁盘、证书到期）；部署基线检查记录；磁盘/日志告警和日志轮转配置；基础设施工单与变更公告待新建108
RND-80系统/主体迁移与生产数据订正业务主体或支付商户迁移、老系统迁服务器、测试环境转正式或新旧版本切换、内部生产环境迁移；以及线上缺陷产生异常订单/金额数据，需要圈定影响范围并订正或退款时主责——迁移/订正负责人（按系统指定；当前：跃玩线 王子明、Leap 线 王皓南·推断待确认）；协同——跃竞负责人（当前：徐莉·推断待确认）、产品总监（当前：杨萌·推断待确认）、运维（当前：席博田、杨明学·推断待确认）、后端（当前：蒋兴武、张楠·推断待确认）、前端（当前：魏小东·推断待确认）、测试（当前：赵伟龙·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）① 立项与影响评估 → ② 迁移清单与负责人 → ③ 迁移测试演练 → ④ 备份 → ⑤ 公告与冻结 → ⑥ 执行 → ⑦ 核对验收 → ⑧ 切换与观察 → ⑨ 数据订正（分支）→ ⑩ 归档带回滚点的迁移方案和检查清单；迁移前备份和迁移后核对报告；停服/切换通知；数据订正审批单与执行记录；异常订单台账待新建250
RND-81内部 AI 机器人/Agent 平台部署、配置与使用边界要在飞书群或私聊中上线、升级、迁移、下线内部 AI 机器人（OpenClaw、Hermes、LeapAll 机器人、工单助手、排障 MCP 助手、许愿机等），或机器人出现越权、刷屏、乱提单、幻觉、配置丢失、不响应时启动主责——内部 AI 机器人平台负责人（当前：王皓南·推断待确认）；协同——运维/镜像维护（当前：宋祺睿、杨明学·推断待确认）、各机器人 owner（当前：岳阳、杨萌、魏宗浩、王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、飞书管理员/安全（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 上线登记 → ② 权限矩阵评审 → ③ 按模板配置 → ④ 镜像构建与部署 → ⑤ 上线前测试 → ⑥ 发布使用说明 → ⑦ 规则变更走评审 → ⑧ 故障值守与月度复核机器人台账中的完整登记（owner、备岗、模型、技能、权限、可用范围、成本上限）、受版本管理的配置与提示词、群内使用说明卡片、变更与故障记录待新建192
RND-82Agent 评测集与评测体系需要量化 Agent（LeapAgent/LeapAll/LeapCore）或某个模型、skill 的能力，发版前做回归评测，多方案赛马，或测算行业报告生成效果与单篇成本时启动主责——Agent 评测负责人（当前：张东郅·推断待确认）；协同——Leap 研发负责人（评测方向与流程设计，当前：王皓南·推断待确认）、产品总监（功能清单与跟进会，当前：杨萌·推断待确认）、评测工程师（当前：黄霆瑄、董洪焜·推断待确认）、Agent 研发（当前：岳阳、李铭熙·推断待确认）、报告跑测研发（当前：陈锦杰、黄飞鹏·推断待确认）、业务专家（当前：王满·推断待确认）、模型网关 API owner（当前：柯逸飞·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 定评测目的与基线 → ② 建/更新评测集与 verifier → ③ 准备环境、账号与额度 → ④ 批量跑评测 → ⑤ 失败聚类归因 → ⑥ 改动后定向+回归评测 → ⑦ 出报告并例会审阅 → ⑧ 失败样本回流版本化评测集（case、verifier、评分标准）、评测报告（图表/HTML，含得分、成本、时长、失败归因）、评测看板、发版回归结论待优化192
RND-83Agent 生成文档质量问题治理LeapCore/LeapAll 生成的 PPT、Word、Excel、HTML 出现格式错乱、字体缺失、水印、标题颜色异常、导出失败、预览不全等问题，或客户演示前需确认默认文档格式与组织模板时启动主责——文档生成研发负责人（当前：马漳毓·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Word 套件研发（当前：邓乾·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、业务专家/组织模板维护（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、方案研发（当前：陈锦杰·推断待确认）、销售演示人（当前：吴琪·推断待确认）、法务（字体版权，当前：李瑶）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 收集反馈 → ② 补齐原始提示词与文件提 issue → ③ 分类打标 → ④ 阻断类当天止血 → ⑤ 两周一次集中归因 → ⑥ 修模板/skill/导出链路 → ⑦ 文档回归样例集回归 → ⑧ 发版通知与演示前检查已分类的文档质量问题清单、公司默认格式模板（以国标公文为基准）及版本记录、文档产出回归样例集与回归报告、修复发版说明、演示前检查记录待优化180
RND-84知识库数据清洗入库与更新行业知识库（字字可研/工程版数据源）内容过时需更新，或新采集、外包交付的数据要清洗、迁移入库、打标签，以及新增行业 skill 需分类并绑定行业时启动主责——知识库数据研发（当前：魏宗浩·推断待确认）；协同——运维/数据库（入库窗口与标签脚本，当前：宋祺睿·推断待确认）、产品总监（发起与进度，当前：杨萌·推断待确认）、开放平台负责人（行业标签与下发，当前：郭逸非·推断待确认）、LeapAll 服务端（skill 分类方案，当前：邓乾·推断待确认）、产品经理（分类审核，当前：黄飞鹏·推断待确认）、业务专家（内容抽检，当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 更新立项 → ② 检视/重写爬虫并采集 → ③ 清洗 → ④ 申请入库窗口并迁移 → ⑤ 跑标签 → ⑥ 行业与 skill 绑定 → ⑦ 业务抽检验收 → ⑧ 关闭窗口、归档数据版本更新后的知识库数据（含本次 updated_at 范围）、标签完成报告、行业与 skill 绑定表、验收记录、数据版本说明与导出备份待新建72
RND-85研发工作与项目交接研发成员离职、调岗、借调结束、实习结束、长期请假，或项目/模块/系统负责人更换、MVP 从作者转给维护者时，完成工单、代码、文档、环境、账号权限、待办与上下文的移交并由接手人签收主责——交出方所属团队技术负责人（当前：王皓南·推断待确认，非 Leap 产研团队由对应技术负责人担任）；协同——交出方原负责人、接手方新负责人、Gitea/服务器权限管理员（当前：宋祺睿·推断待确认）、IT 资产与服务器台账（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 指派交接与截止日 → ② 交出方按模板写 handoff → ③ 工单完成、释放或转派 → ④ 仓库迁组织仓并转移权限 → ⑤ 交接会与读代码/演练 → ⑥ 接手人逐项签收 → ⑦ 更新台账并公告新负责人 → ⑧ 回收交出方权限、30 天答疑签收的 handoff 文档（统一模板，存仓库 docs/handoff 并链接飞书）、转派完毕的工单、更新后的系统台账（负责人、仓库、服务器、域名）、新负责人公告、权限变更记录待新建144
RND-86技术文档与上下文知识沉淀调研/实验性工作结束、踩到需要告诉后来者的坑、新人或 AI 反复需要项目背景、跨团队需要产品与技术全景、AI 会话记录需要留存时，按统一位置和模板沉淀文档主责——研发负责人（当前：王皓南·推断待确认）；协同——各项目技术负责人/文档 owner、运维/发版（仓库文档约定，当前：宋祺睿·推断待确认）、开放平台后端（产品架构文档，当前：杨睿·推断待确认）、开放平台/FDE 课程负责人（当前：吴亚军·推断待确认）、产品总监（当前：杨萌·推断待确认）、支付研发顾问（踩坑文档，当前：王子明·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 判定沉淀类型 → ② AI 生成初稿、作者核对 → ③ 放入约定位置 → ④ 更新 AGENTS.md 索引 → ⑤ 迭代末审阅调研文档 → ⑥ PR 附带文档更新 → ⑦ 会话归档 → ⑧ 季度清理仓库 docs 分类文档与 AGENTS.md 索引、飞书知识库项目页、调研文档与审阅纪要、踩坑记录、AI 会话归档待新建72
RND-87技术分享、内部 Skill/工具发布与推广研发做出可复用的内部 skill、插件、小工具或配置包，或有值得推广的技术经验、评测结果、新规范，需要评测、登记、发布、分享培训并收集反馈时启动主责——研发负责人（当前：王皓南·推断待确认）；协同——Skill/工具作者（当前：马漳毓、邓乾、柯逸飞、张东郅·推断待确认）、评测（当前：黄霆瑄·推断待确认）、Skill 宣讲（当前：李凯·推断待确认）、内部开源工具负责人（当前：李子遥·推断待确认）、产品总监（产品化判断，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 作者发布登记 → ② 安全扫描与 eval → ③ 推组织仓打版本 → ④ 写使用说明 → ⑤ 机器人发群并入目录 → ⑥ 周五分享/学习任务 → ⑦ 反馈迭代 → ⑧ 月度产品化或下架评估内部 Skill/工具目录中的登记（名称、owner、版本、仓库、安装方式、eval 结果、反馈入口）、发布说明与教程、分享排期与录屏纪要、技术主管周成果汇总待优化72
RND-88外包数据采集委托与验收需要批量采集网站数据（招投标、政务站点、行业资料等）而内部人手不足，决定委托外部团队或分包采集时，覆盖合规评估、委托约定、样例确认、分批交付验收到结单付款全过程主责——数据采集负责人（总包验收方）（当前：魏宗浩·推断待确认）；协同——外包审批与结单人（当前：丁震宇·推断待确认）、数据接入/运维（当前：宋祺睿·推断待确认）、产品总监（需求与进度，当前：杨萌·推断待确认）、Leap 研发负责人（验收要求，当前：王皓南·推断待确认）、业务验收专家（当前：待指定）、法务负责人（当前：李瑶·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 写需求并评估自采/外包/采购 → ② 站点合规评估 → ③ 选外包并签约 → ④ 分配任务与字段规范 → ⑤ 样例验收 → ⑥ 分批交付自动校验 → ⑦ 业务抽检 → ⑧ 结单付款并转入库外包任务表（站点、分包方、状态）、签署的委托合同（含数据来源合法与保密条款）、样例与分批验收记录、验收报告、结单付款审批、移交入库的数据待新建200
RND-89对外技术咨询答复与方案文档评审市场、销售、厂商或合作方询问技术可行性、产品能力，或研发写好的技术方案/产品说明/演示视频需要发给客户时，由研发统一受理、评估答复并在对外发出前完成评审主责——研发技术咨询接口人（当前：丁震宇·推断待确认）；协同——信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、Leap 架构/运维研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、提问方销售/市场（当前：李鹏为、许君·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）① 提交咨询单 → ② 接口人分级派单 → ③ 领域负责人评估 → ④ 形成结论与承诺边界 → ⑤ 对外材料评审 → ⑥ 统一渠道发出 → ⑦ 沉淀 FAQ/口径库带可行性等级与承诺边界的书面答复；经评审签发的对外技术方案/产品说明；更新后的产品能力 FAQ 条目待新建240
RND-91产品版本生命周期与私有化实例版本支持策略LeapCore 等产品同时存在多个在用版本（客户私有化、一体机、渠道实例、信创版），需要明确支持哪些版本、何时停止支持、客户如何升级主责——研发发布负责人（当前：待指定）；协同——产品负责人（当前：待指定）、交付负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 制定版本支持规则 → ② 发版时登记版本与支持截止日 → ③ 每季度盘点在用版本分布 → ④ 停止支持前提前通知 → ⑤ 推动升级 → ⑥ 到期停止补丁并登记例外版本支持策略文件、版本生命周期表、在用版本分布表、停止支持通知待新建96
RND-92研发数据使用合规（数据集登记、客户数据授权与脱敏）研发在评测、微调、调试、复现问题、构建知识库或评测集时，需要使用客户数据、生产数据、外部采集数据或公开数据集主责——数据集管理员（当前：待指定）；协同——使用数据的研发人员、法务（当前：待指定）、信息安全负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提出用途申请 → ② 核对来源与授权 → ③ 脱敏或取最小样本 → ④ 登记数据集 → ⑤ 受控存放与访问 → ⑥ 到期删除并留痕数据集登记表、用途审批记录、脱敏记录、删除记录待新建90
RND-01反馈群问题收集与分流（bug/需求/badcase）待优化180

状态：待优化｜证据：有证据（卡片 9 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：内部员工、客户或市场在反馈群、话题群、内测群或口头反映产品问题时，判定类型、查重、转入对应载体，并在原帖回复去向
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、反馈群值班产品经理（当前：杨黔昆、陈震·推断待确认）、Badcase 收集人（当前：黄霆瑄·推断待确认）、反馈机器人维护人（当前：待指定）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 收帖 → ② 补齐复现信息 → ③ 判类型（bug/需求/badcase/使用问题）→ ④ 查重 → ⑤ 转工单/需求池/badcase 表/直接答复 → ⑥ 原帖回复去向 → ⑦ 处理完成后通知反馈人
  • 交付结果：每条有效反馈都有明确去向（工单编号、需求池记录、badcase 记录或答复），并回在原话题下；每周一份分流统计
  • 状态依据：已有反馈群、机器人代提单、Gitea/issues 工单、反馈表单和 badcase 表，但 2026-05～07 分类口径多次口头重定，机器人误分类或缺复现信息就 @ 研发，凭据权限丢失导致无法建单，"反馈入口在哪"反复被问，靠人点名"提个工单"的情况约 20 次以上

1. 场景判定

  • 触发条件：反馈群/话题群出现新帖；内测客户端（ClawLite、LeapAll、LeapPPT 等）发版后的全员体验反馈；客户、销售、市场转来的口头问题；群聊里有人说"提个工单/记一下"
  • 典型说法：「提工单吧，在这里说肯定会忘」「bug 提工单，需求发产研群，badcase 提到表里」「反馈表单在哪」「@NK AI 开个 issue，assign 给我」「无法复现但反复出现的问题，不能只说无法复现就丢掉」
  • 判断问题：这条反馈是否来自真实使用？是否还没进入任何工单或表格？能否说清现象、版本和环境？
  • 类型口径（写入机器人提示词）：bug＝产品行为与已定义功能不符；badcase＝AI/Agent 表现不佳（答非所问、工具乱调用、生成质量差），代码本身没错；需求＝想要但当前没有；使用问题＝产品已支持，用户不会用
  • 不归本流程管：已确认缺陷的分级、修复、验收 → 请走 RND-03；badcase 入库后的归因与回归 → 请走 RND-02；需求评审与排期 → 请走 RND-04；生产事故、大面积不可用 → 请走 RND-75（线上故障应急）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈群值班 每日巡帖、追问复现信息、确认类型、转载体、回帖 R 产品经理轮值（当前：杨黔昆、陈震·推断待确认）
产品负责人 制定分流口径；类型争议终审；决定需求是否进需求池 A 产品负责人（当前：杨萌·推断待确认）
研发负责人 bug 类 triage 与指派；规定机器人发言边界 C 研发负责人（当前：王皓南·推断待确认）
测试负责人 bug 查重、复现、补单 C 测试负责人（当前：张东郅·推断待确认）
Badcase 收集人 接收 badcase，补对话上下文 C 评测（当前：黄霆瑄·推断待确认）
反馈机器人/机器人维护人 机器人执行追问、预判、代建单、回帖与通知；维护人维护提示词、工单系统凭据与写权限 R（工具） 待指定
反馈人/收到人 发帖或代填反馈；提供截图、日志、版本、环境；确认修复结果 I 各部门员工/客户对接人

3. 办之前请准备

  • 统一反馈入口：每条产品线一个置顶的反馈表单或话题群地址
  • 类型口径和示例（bug、badcase、需求、使用问题各 3 例），已写入机器人提示词
  • 反馈必填信息：产品与版本号、客户端/网页端、操作系统、环境（测试/正式）、账号或 userId、复现步骤、截图/录屏、日志（如 leapagent.log.jsonl、HAR）
  • 工单系统、需求池、badcase 表的链接与写权限（值班人和机器人都要有）
  • 当前已知问题清单，方便直接回复"已有工单 #xxx / 新版已修"

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在统一入口发帖或填表；口头或私下收到的反馈由收到人代填 反馈人/收到人 发现当天 飞书话题群/表单 反馈帖 🔧飞书固化
2 机器人按模板检查必填项，缺项在原话题追问；信息补齐前不 @ 研发 反馈机器人 发帖后 30 分钟内 群机器人 追问消息 🤖自动化
3 机器人按口径预判类型，附理由 反馈机器人 信息补齐后 30 分钟内 群机器人 分类草稿 🤖自动化
4 值班人确认类型；边界模糊的交产品负责人终审 反馈群值班 工作时间 2 小时内 话题群 确定类型 👤人工判断
5 查重：按关键词/标题相似度检索已有工单、需求、badcase；重复的追加到原单备注，不新建 机器人+值班 与第 4 步同时 工单系统检索 查重结论 🤖+👤
6 转载体：bug→建工单（进入 RND-03）；需求→需求池"待评估"（进入 RND-04）；badcase→badcase 表（进入 RND-02）；使用问题→直接答复并沉淀 FAQ 值班（机器人代建） 确定类型后 1 小时内 issues 工单/需求池/badcase 表 工单号/记录 ID 🔧+🤖
7 在原话题回帖：类型、去向链接、负责人、预计处理时间 反馈机器人 建单后立即 话题群 回帖 🤖自动化
8 疑似紧急（大面积不可用、扣费异常、数据丢失）直接 @ 研发负责人和测试负责人 反馈群值班 发现后 15 分钟内 话题群/电话 升级记录 👤人工判断
9 工单关闭、需求有结论或 badcase 处理完后，在原话题通知反馈人 反馈机器人 状态变更后 1 个工作日内 工单 webhook→飞书 结果通知 🔧+🤖
10 汇总上周反馈：数量、类型分布、未分流数、重复率 反馈群值班 每周一 12:00 前 多维表格看板 分流周报 🤖自动化

5. 交付物与模板

  • 交付物：分流后的工单/需求/badcase 记录；原话题回帖；分流周报
  • 建议模板/表单（反馈入口表）：反馈人、来源（内部/客户/销售转述）、产品线、版本号、端（客户端/网页/移动）、环境、账号/userId、现象、复现步骤、预期结果、截图/录屏、日志附件、类型（机器人预判/人工确认）、去向链接、状态、通知时间
  • 机器人提示词固定项：类型定义与示例；必填项检查；未被 @ 或信息不全时不发言；建单前先查重；说明工单来源时先查 creator，不凭记忆

6. 异常与升级

  • 反馈人 1 个工作日内未补复现信息 → 标"待补充"，第 3 个工作日关闭并告知可重开 → 不升级
  • 无法复现但同类反馈 ≥ 3 次 → 不得关闭，转"疑难"专项跟踪 → 升级研发负责人（1 个工作日内）
  • 类型争议（bug、需求还是 badcase）→ 产品负责人终审 → 当天给结论
  • 机器人凭据或写权限失效、无法建单 → 值班手工建单，通知机器人维护人修复 → 超 4 小时未恢复升级 CTO
  • 机器人误分类或刷屏 → 撤回并更正，修改提示词 → 机器人维护人当天处理
  • 调试中的分流 skill 批量写入正式团队 → 立即停用并删除测试单 → 升级研发负责人（当天）

7. 衡量指标

  • 分流时效：发帖到回帖告知去向的工作时长，目标 ≤ 2 小时
  • 落单率：有效反馈中已进入工单/需求池/badcase 表的比例，目标 ≥ 95%
  • 分类准确率：每周抽检机器人分类正确的比例，目标 ≥ 90%
  • 重复单率：因重复关闭的工单占新建工单比例，目标 ≤ 10%
  • 结果通知率：处理完成后已通知反馈人的比例，目标 ≥ 90%

8. 低效诊断

  • 落单依赖有人 @ 机器人或口头"提个工单"，没人点名的反馈在群里沉底｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07
  • bug/badcase/需求边界没有成文，分类靠现场追问，机器人把 bug 混进 badcase 表后再清理｜依据：「Leap产研测」2026-06
  • 机器人缺复现信息就转发并 @ 研发，或未经请求自行发言，分散研发注意力｜依据：「Leap产研测」2026-07、「Leap反馈群」2026-06
  • 机器人凭据写权限多次丢失，期间无法建单｜依据：「Leap反馈群」2026-06、「Leap产研测」2026-07
  • 反馈入口不明，表单、工单、需求池并行，"表单在哪/需求池在哪"反复被问｜依据：「Leap产研测」2026-05、「leapall逗狗群」2026-06
  • 外部反馈若测试没有复提就不进流程，"无法复现"的单被直接关闭｜依据：「鼎慧产研决策部」2026-07
  • 内测反馈散落在闲聊群和测试群，同类问题多人重复提，提完没有状态回复｜依据：「模态AI探索小分队」2026-05、「模态小龙虾测试群」2026-03
  • 需求被当作 bug 提交，绕过产品评估｜依据：「Leap产研测」2026-05

9. 分支变体

  • 机器人代提：机器人预判并代建单，类型、优先级、指派由人确认；机器人不得自行定紧急/P0
  • 迭代外需求：先进需求池"待评估"，由产品负责人逐条决定关闭、排入迭代或转 bug（见 RND-04）
  • 内测客户端全员体验（ClawLite、LeapAll 等）：发版时同时发布反馈话题和模板；体验期结束后 1 个工作日内，值班清点未落单反馈
  • 客户情绪类反馈（如扣费异常投诉）：先追问具体信息和日志再转单；涉及扣费、退款的同步客户对接人
  • 不同产品线（Leap 系列、字字可研、跃竞）各设反馈入口和值班，类型口径统一

10. 待确认问题

  • 反馈群值班由产品经理轮值还是测试轮值？轮值表放在哪里？
  • 分流时效 2 小时、补信息 1 个工作日是否可行？
  • 是否收口为一个反馈入口（表单或话题群），并下线其他入口？
  • 目前多个机器人并存，保留哪一个？谁是维护人，凭据由谁保管？
  • 使用问题的 FAQ 沉淀到哪里（帮助中心还是知识库）？
RND-02Badcase 记录、分诊与回归集沉淀待优化108

状态：待优化｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：用户或内部发现 AI/Agent 表现差（答非所问、上下文丢失、工具乱调用、提前结束、生成质量差）但不属于代码缺陷时，登记 badcase、分诊根因、跟进修复，并沉淀为回归/评测用例
  • 负责人：主责——评测/Badcase 负责人（当前：黄霆瑄·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、Agent 研发（当前：岳阳、杨云峰、李铭熙·推断待确认）、字字可研 AI 助手研发（当前：宋祺睿·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记 → ② 补上下文 → ③ 入库判定 → ④ 分诊根因 → ⑤ 归因会指派 → ⑥ 修复（提示词/skill/工具/模型，或转 bug）→ ⑦ 回归验证 → ⑧ 入评测集并通知提交人
  • 交付结果：带编号（BADCASE-NN）的 badcase 记录（含根因类别、处理方式、修复版本、关联工单）；每周 badcase 周报；新增的回归/评测用例
  • 状态依据：已有 badcase 收集表单、飞书 badcase 表、BADCASE 编号和归因分析会，但入库标准、字段、与工单的关联、给提交人的结果通知都没固化；"提前结束/早退"类问题 2026-08～10 反复出现，批量补录靠机器人翻群至少 3 次

1. 场景判定

  • 触发条件：Agent 答非所问、读图失败或幻觉、工具选择错误、上下文压缩丢意图、长任务不遵循 skill、流式输出提前结束、PPT/文档生成质量差；AI 助手工具调用报错、乱调用
  • 典型说法：「提 badcase」「记个 badcase」「现在的 badcase 流程本身就是一个 badcase」「badcase 不会全收，你得说清 bad 的点在哪里」「给谁提，帮我 @ 一下」
  • 判断问题：代码有没有按设计执行？问题是"做得不好"还是"做错了/做不了"？能不能说清 bad 的点和预期结果？
  • 不归本流程管：功能缺陷、报错、白屏 → 请走 RND-03；反馈的初次分流 → 请走 RND-01；评测集建设与模型基准评测 → 请走 RND-82；新增 AI 能力的需求 → 请走 RND-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Badcase 负责人 收集、补上下文、入库判定、编号、周报、沉淀用例 R 评测（当前：黄霆瑄·推断待确认）
研发负责人 主持归因会，确定修复方式，拍板模型切换 A 研发负责人（当前：王皓南·推断待确认）
产品负责人 定 badcase 与 bug、需求的边界；决定修复优先级 C 产品负责人（当前：杨萌·推断待确认）
测试负责人 制定入库标准，判断是否转 bug C 测试负责人（当前：张东郅·推断待确认）
Agent 研发 根因分析，修改提示词、skill、工具约束 R（修复） Agent 研发（当前：岳阳、杨云峰、李铭熙·推断待确认）
AI 助手研发（字字可研） 工具集、system prompt、模型配置变更 R（分支） 后端研发（当前：宋祺睿·推断待确认）
提交人 提供对话链接、日志、预期结果，确认修复效果 I 各部门员工/客户对接人

3. 办之前请准备

  • 对话链接或完整上下文（展开工具调用过程）、使用的 skill、上传的原始文件
  • 产品与版本、模型档位（普通/专家）、模式（如目标模式）、环境
  • 原始提示词、预期结果、实际结果、bad 的具体点（必填，说不清不入库）
  • 客户端日志导出方法（固定一页指引，附在表单首页）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写 badcase 表单（必填项见第 5 节），或在反馈群 @ 机器人一键登记 提交人 发现当天 飞书表单/机器人 表单记录 🔧+🤖
2 自动生成 BADCASE 编号、写入多维表格并通知负责人 系统 提交即时 多维表格自动化 编号记录 🔧飞书固化
3 核对上下文与日志，缺失一次性追问齐 Badcase 负责人 1 个工作日内 表格评论/话题 完整记录 👤人工判断
4 入库判定：说得清 bad 点→入库；属代码缺陷→转 RND-03 建 bug 单；说不清→退回补充 Badcase 负责人 补齐后 1 个工作日内 多维表格 判定结果 👤人工判断
5 初分根因类别：模型能力/提示词/上下文压缩/工具选择与调用/skill/前端展示/数据 AI 预分类+负责人确认 入库后 2 个工作日内 多维表格+AI 根因类别 🤖+👤
6 会前推送待归因清单；归因会逐条过，指定处理人、方式、目标版本 研发负责人主持 每周二、四 14:00-15:00（会前 1 小时推送） 飞书日程+机器人 归因结论 🤖+👤
7 修复：提示词/skill/工具约束改动走 PR；需代码改动的建关联工单；模型切换由研发负责人拍板 Agent 研发 按优先级，同类高频的当迭代内 Gitea PR/issues PR、关联工单 👤人工判断
8 用原样例复测，通过标"已解决"并记修复版本；未通过退回第 7 步 Badcase 负责人 修复上线后 2 个工作日内 测试环境 回归结果 🤖+👤
9 把典型 badcase 转为回归/评测用例（进入 RND-82），通知提交人处理结果 Badcase 负责人 验证通过后 1 个工作日内 评测集仓库/机器人 新增用例、通知 🔧+🤖
10 生成周报：新增、已解、类别分布、复发项 机器人 每周一 10:00 前 多维表格看板 badcase 周报 🤖自动化

5. 交付物与模板

  • 交付物：badcase 库记录、归因会结论、修复 PR/关联工单、回归结果、新增评测用例、周报
  • 建议模板/表单（badcase 库）：编号、提交人、提交时间、产品（LeapCore/LeapAll/LeapPPT/字字可研）、版本、模型档位、模式、环境、提示词、预期、实际、bad 点描述、对话链接、日志/附件、根因类别、处理方式（提示词/skill/工具/模型/转 bug/不处理）、处理人、关联工单/PR、修复版本、状态（待补充/待归因/处理中/已解决/不处理）、是否入评测集、是否复发
  • AI 工具清单（字字可研 AI 助手适用）：工具名、适用聊天场景、权限、负责人、上线版本

6. 异常与升级

  • 同类 badcase 复发 ≥ 2 次 → 升级为专项并加入长程/回归评测 → 升级研发负责人（1 个工作日内）
  • 影响客户演示或交付的 badcase → 修复优先级提到当迭代最高 → 通知产品负责人（当天）
  • 工具误调用改动了客户项目内容 → 按缺陷紧急级处理，转 RND-03 → 升级研发负责人（2 小时内）
  • 修复需要切换模型、明显增加成本 → 提交成本估算 → CTO 确认（2 个工作日内）
  • 提交人 3 个工作日不补信息 → 关闭并说明原因 → 不升级

7. 衡量指标

  • 入库时效：提交到入库判定的工作日数，目标 ≤ 2 天
  • 归因完成率：入库 7 天内完成根因分类的比例，目标 ≥ 90%
  • 复发率：标"已解决"后 30 天内同类复现的比例，目标 ≤ 10%
  • 用例沉淀率：已解决 badcase 转为回归/评测用例的比例，目标 ≥ 80%
  • 结果通知率：处理完成后已通知提交人的比例，目标 ≥ 90%

8. 低效诊断

  • 没有独立登记入口，常需在群里 @ 人代记，提交人不知道"给谁提"｜依据：「Leap反馈群」2026-07、「Leap反馈群」2026-08
  • bug 与 badcase 边界靠口头判断，表内混入 bug 后再清理｜依据：「Leap产研测」2026-06
  • 收集时反复索要对话上下文和日志，约 10 次｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07
  • 汇总靠机器人临时翻群批量补录，每条链接都要临时整理｜依据：「Leap产研测」2026-06
  • 归因会频次来回调整，归因结论怎么回灌到提示词或模型没有约定｜依据：「Leap产研测」2026-06
  • "提前结束/早退"同类问题多月反复出现，没有形成回归用例｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09、「Leap反馈群」2026-10
  • AI 助手工具调用失败直接满屏报错，侧边栏与全屏工具集不一致，靠测试偶然发现，没有工具/模型变更回归规范｜依据：「工程咨询产研」2026-02、「工程咨询产研」2026-03
  • 工单附件不支持 html、日志等格式，badcase 证据难以附上｜依据：「Leap产研测」2026-07

9. 分支变体

  • LeapCore、LeapAll、LeapPPT 的 Agent 类 badcase 同表登记，用"产品"字段区分；目标模式、长程任务、识图幻觉单独打标签
  • 字字可研 AI 助手工具调用治理：每个聊天场景只开放对应工具，并动态拼装 system prompt；工具调用失败给简短失败提示，不展示大段报错；多项目场景工具必须显式带项目 ID；模型切换、工具增删走 PR，合入前跑固定样例回归
  • 客户专项（如某服装电商客户的图像能力）：由项目研发收集 badcase 和 good case，回归评测脚本自动跑全部历史 badcase 后再发正式服

10. 待确认问题

  • Badcase 负责人是否确定为评测岗？各产品线是否需要各设一名？
  • 归因会固定为每周二、四，还是并入每日例会？
  • badcase 表与工单系统是否打通（关联字段/自动建单）？
  • 评测集（RND-82）的入集标准由谁定？
  • 模型切换的成本审批线是多少，是否需要 CTO 签字？
RND-03缺陷提报、复现、分级与指派待优化180

状态：待优化｜证据：有证据（卡片 41 张 / 会话 15 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：测试、产品、研发、客户或交付人员发现产品缺陷时，复现留证、按模板建单、定级、指派认领、修复关联 PR、验收关闭
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发现与复现 → ② 查重 → ③ 按模板建单 → ④ 定级 → ⑤ 指派/认领 → ⑥ 修复并关联 PR → ⑦ 产品/测试验收（打回或通过）→ ⑧ 关闭并通知
  • 交付结果：每个缺陷都有一张信息完整、定级、有负责人、关联 PR 并经验收关闭的工单；发版前 P0/P1 清零记录
  • 状态依据：Leap 系列 2026-07 起已统一到 issues.leapinfra.cn，有优先级、状态流转提案和版本迭代测试流程文档；但 1～10 月各产品线先后用过群聊、飞书 bug 表、Gitea、issues 多套载体，重复单、无人认领、状态不更新、紧急级滥用、修了不建单等问题在 41 张卡片里反复出现

1. 场景判定

  • 触发条件：测试执行、产品走查、研发自测或开发中发现缺陷；客户/现场反馈经 RND-01 判定为 bug；研发自己修复的缺陷（也必须建单）
  • 典型说法：「先提工单再发群里」「自己修的也要提工单」「谁开发的这里，需要指派一个负责人」「验收不通过」「别滥用紧急」「复现不出来你就不提了吗」
  • 判断问题：产品行为是否违背已定义的功能或预期？能否给出环境、版本和复现步骤？是否已有同类工单？
  • 不归本流程管：反馈的初次分流 → 请走 RND-01；AI/Agent 表现不佳 → 请走 RND-02；新功能或"需求没做" → 请走 RND-04；生产事故止血与对外通报 → 请走 RND-75（线上故障应急）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发现者/提单人 复现、留证、查重、按模板建单 R 测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）及任何发现者
测试负责人 定级、提单规范、验收规则、每日盘点、发版前清点 A 测试负责人（当前：张东郅·推断待确认）
研发负责人 指派不明工单的 triage；紧急级审核；修复时限 R（指派） 研发负责人（当前：王皓南·推断待确认）
产品负责人/产品经理 判定预期行为、是否为缺陷；产品验收；紧急级审核 C 产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）
模块负责研发 认领、修复、关联 PR、更新状态 R（修复） 各模块研发（见模块-负责人表）
跃竞测试负责人 跃竞线缺陷提报与回归 R（分支） 测试负责人（当前：赵伟龙·推断待确认）
跃竞负责人 跃竞线是否为缺陷、优先级有争议时拍板 A（升级） 跃竞负责人（当前：徐莉·推断待确认）

3. 办之前请准备

  • 工单系统账号与正确团队/项目权限（Leap 线用 issues.leapinfra.cn，其他线见第 9 节）
  • 复现信息：环境（测试/正式/具体实例编号）、版本号、端与操作系统、账号/userId/项目 ID/订单号、复现步骤、预期与实际、截图或录屏
  • 证据：客户端日志、HAR/curl、接口地址与参数；卡顿类先用 F12 区分接口耗时还是渲染
  • 定级表（第 5 节）和"模块-负责人"表
  • 已知问题清单，便于查重

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 复现并留证；偶现问题记录每次出现的项目 ID 等线索 发现者 发现当天 测试环境/录屏/F12 复现记录 👤人工判断
2 查重：检索关键词和已知问题清单；重复的在原单追加备注 发现者 建单前 工单系统检索/AI 查重 查重结论 🤖+👤
3 按模板建单：选对团队、类型标签 bug、项目、迭代；先建单后发群，群里只贴链接；一张单只写一个问题 发现者（可用工单 skill） 发现当天下班前 issues 工单系统 工单 LEAP-xxx 🔧+🤖
4 定级（紧急/高/中/低）；"紧急"需研发负责人、产品负责人、测试负责人任一人审核 测试负责人或产品经理 建单后 2 个工作小时内 工单优先级字段 已定级工单 👤人工判断
5 按"模块-负责人"表指派；无法判断的交研发负责人 triage 测试负责人/研发负责人 定级后当天 工单指派字段 已指派工单 🤖+👤
6 认领：负责人把指派人改为自己，填写预计修复时间；不是自己的直接流转给正确的人 模块负责研发 紧急 30 分钟内；其他 1 个工作日内 工单系统 认领记录 👤人工判断
7 修复：PR 标题带工单号，工单评论贴 PR 链接和可验证环境；合入主干后状态改为"待验收" 模块负责研发 按定级时限 Gitea PR+工单 PR、状态变更 🔧+👤
8 验收：预期行为由产品验收，功能由测试验收；不通过在原单打回并附截图；Infra 级由研发交叉验收 产品经理/测试工程师 转验收后 2 个工作日内（紧急当天） 测试环境+工单 通过/打回 👤人工判断
9 关闭：通过后置"完成"；来自反馈群的通知反馈人；紧急级补根因和测试用例 测试工程师 验收通过当天 工单系统/机器人 关闭工单 🔧+🤖
10 推送"未定级/未认领/超时未修/待验收超 2 天"清单，站会前各人更新状态 机器人+测试负责人 每个工作日 10:00 前 工单视图+飞书机器人 每日清单 🤖自动化
11 发版前清点：P0/P1 必须清零，未清的报风险由产品负责人决定是否发版；发布前留半天冒烟 测试负责人 发版前 1 个工作日 工单迭代视图 清点结论 👤人工判断

5. 交付物与模板

  • 交付物：缺陷工单（含复现信息、等级、负责人、PR、验收结论）、每日盘点清单、发版前缺陷清点结论
  • 建议模板/表单（缺陷工单必填）：标题（[模块] 现象）、团队/项目、类型标签、产品与版本、端与系统、环境、账号/userId/项目 ID/订单号、复现步骤、预期、实际、截图/录屏、日志/HAR、来源（测试/产品走查/客户/现场）、等级、迭代、负责人、关联 PR、验收结论
  • 建议定级表（待测试负责人确认后置顶）：
    • 紧急（P0）：生产事故，资金、数据、安全问题，阻塞发布或客户演示｜2 小时内响应，当日修复或热修
    • 高（P1）：主流程受损但有替代方案｜1 个工作日内响应，当前迭代内修复
    • 中（P2）：非主流程或体验问题｜当天出排期，1～2 个迭代内修复
    • 低（P3）：轻微问题或优化建议｜当周出排期，进需求池评估
  • 状态流（Leap 线）：评审 → 待办 → 待开发 → 开发中 → 代码评审 → 产品验收 → 测试验收 → 完成；另有"已取消""重复"

6. 异常与升级

  • 建单 4 小时无人认领 → 机器人提醒，研发负责人当天强制指派 → 升级研发负责人
  • 紧急级超时未修 → 修复人提前报风险，评估热修或回滚 → 升级研发负责人（超时即报）
  • 同一缺陷验收打回 ≥ 2 次 → 产品、测试、研发三方当面对齐预期 → 升级产品负责人（1 个工作日内）
  • 研发修复未建单或 PR 未关联工单 → 补单并在周会通报 → 测试负责人当天处理
  • 现场问题线上无法复现 → 收集现场硬件与配置，在低配环境复现 → 升级 CTO（1 个工作日内）
  • 修复人离职或调岗 → 移交前释放手头工单并写交接备注 → 研发负责人重新指派（当天）
  • 机器人或 skill 批量误建单 → 删除并改用独立测试团队调试 → 升级研发负责人（当天）
  • 跃竞线某问题是否算缺陷、定什么优先级，测试负责人与研发/产品意见不一致 → 跃竞测试负责人汇总双方意见 → 升级跃竞负责人拍板（A（升级），当天）

7. 衡量指标

  • 认领时效：建单到认领的工作时长，目标中位数 ≤ 4 小时
  • 定级时效达成率：按定级表时限修复的工单占比，目标紧急 100%、高 ≥ 90%
  • 验收打回率：被打回工单占验收工单比例，目标 ≤ 15%
  • 重复单率：标"重复"的工单占新建 bug 比例，目标 ≤ 10%
  • PR 关联率：已修复 bug 中关联 PR 的比例，目标 ≥ 95%
  • 发版遗留：发版时未关闭的 P0/P1 数，目标 0

8. 低效诊断

  • 问题先在群里截图讨论再补单，或口头说"在修"却不建单，修了不关联工单｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08、「开源聚变入驻问题沟通群」2026-03
  • 载体反复切换（群聊→飞书 bug 表→Gitea→issues 系统），新旧并行，历史单迁移丢进度｜依据：「工程咨询产研」2026-02、「Leap产研测」2026-07、「跃玩项目组」2026-06
  • 指派规则多次变更，机器人默认指错人，模块负责人不明，"不知道分给谁"｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06、「Leap产研测」2026-08
  • 重复单多，同一缺陷被提三四次，机器人建单前不查重｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07、「Leap产研测」2026-09
  • 描述不清导致无法复现或验收打回，开发反复索要日志、HAR、项目 ID、接口参数｜依据：「工程咨询产研」2026-04、「Leap产研决策部」2026-09、「跃玩remote工作组」2026-06、「字字可研项目群」2026-04
  • 紧急级被滥用，调试中的 skill 批量生成紧急单进入正式团队｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • 状态不更新：修了不改状态，卡片按钮点了没人确认，测试验收积压上百单｜依据：「跃玩项目组」2026-02、「Leap产研决策部」2026-09、「Leap产研测」2026-08
  • 修复时限只在群里口头宣布，执行靠反复追问进度｜依据：「Leap产研测」2026-07、「鼎慧产研决策部」2026-01
  • 工单系统通知到不了人（@ 无效、回复提醒看不到），同一内容要在群里再发一次｜依据：「Leap产研测」2026-05、「开源聚变入驻问题沟通群」2026-04
  • 现场问题线上复现不了，既无现场问题登记也无低配复现环境，只能反复催｜依据：「跃迁基座项目交付沟通」2026-03、「跃迁基座项目交付沟通」2026-04
  • 研发自测不充分就转测，测试环境与演示环境混用｜依据：「LeapCore（archived）」2026-05
  • 正式服在非约定时间被直接更新，影响客户使用｜依据：「客户专项群（服装电商客户）」2026-08

9. 分支变体

  • Leap 系列（LeapCore、LeapAll、LeapNew、LeapPPT）：issues.leapinfra.cn，团队选 Leap；Issues 团队只登记工单系统自身缺陷；hotfix 工单标紧急、不挂迭代，进 hotfix 看板
  • 字字可研/工程咨询：历史用飞书多维表格 bug 池，迁移后按本流程执行；客户反馈需附项目 ID、账号、章节；导出格式类（可改）走本流程，AI 生成内容质量类转 RND-02；格式类问题每周设一次集中修复窗口
  • 跃竞（跃玩/星域/EasyPlay 会员端、管理端）：早期用"测试问题反馈"表单+机器人卡片（"收到，我来改""改完了"），2026-06 起用 Gitea easyplayBug 仓库；必填接口地址、参数、用户 UID、订单号、测试服/正式服；支付、退款、分账类缺陷至少定为高；工单需写根因和"至少需要测试的场景"
  • 管理后台"无权限/菜单缺失"：先由开发核对权限码与角色配置，确属漏配直接补配并记录；新功能在需求评审时登记权限码和默认角色
  • 开源聚变/OPC 平台：Gitea intelligenesis 系列仓库，沿用 P0～P4 定级（P4 优化建议只记录）
  • ClawLite/MercAll：统一放 MercAll 仓库，客户端与平台不再分仓登记
  • 客户现场项目（政企现场部署、某服装电商客户 API 项目）：现场问题建单附硬件、上下文配置、日志；在低配环境复现；正式服只在约定窗口（夜间/周末）更新，并在客户群告知"已修复请验证"
  • 低风险微改是否可以免建单：口径待定（见第 10 节）

10. 待确认问题

  • 定级时限以哪份为准（版本迭代测试流程文档、群内宣布的"P0 当日、P1 本周"、P0～P4 定级表三者不一致）？
  • 历史"P-1"命名是否已全部改为 P0 起算？工单系统"紧急/高/中/低"与 P0～P3 是否一一对应？
  • "模块-负责人"表由谁维护，多久更新一次？
  • 是否在 CI 中拒绝不带工单号的 PR？研发自修的小问题是否一律建单？
  • Infra 级工单由研发交叉验收的规则是否成立，谁来指定交叉验收人？
  • 跃竞、开源聚变等线是否迁移到统一的 issues 系统？
RND-04需求提出、澄清与评审入迭代待优化144

状态：待优化｜证据：有证据（卡片 9 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：产品、业务、客户、领导或研发提出新需求（含一句话需求、迭代中插队需求、客户现场需求）时，登记、澄清、评审，决定做/不做/排入哪个迭代，并留痕
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震、杨黔昆·推断待确认）、CTO（客户项目需求取舍，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵、陈雁·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记入需求池 → ② 澄清（背景/目标/验收标准）→ ③ 产品初筛 → ④ 需求评审（方案与估点）→ ⑤ 决策并留痕 → ⑥ 拆工单入迭代 → ⑦ 插队走确认 → ⑧ 产品验收
  • 交付结果：需求池中每条需求都有来源、结论（做/不做/待定）和目标迭代；评审纪要；挂在迭代上、带估点、优先级和验收人的工单
  • 状态依据：已有需求池/工作台、评审会、工单系统、跃竞需求管理机器人和迭代文档，但口头需求不留痕、事后追问来源，插队没有规则，评审参会无约定，工作台与工单靠人同步；跃竞线 2026-01～06 载体改了三次

1. 场景判定

  • 触发条件：产品写出迭代需求；领导或业务方口头提出方向；客户/现场提出新功能；反馈群中被判定为需求（来自 RND-01）；迭代进行中要插入新需求
  • 典型说法：「必须记录到飞书里，免得到时候你不记得了」「我要插队 3 个需求到这个迭代」「优先级呢」「需求在我这过一遍，大刀阔斧地砍」「产品讨论完再让技术估工期，只是我们开会没有 SOP」
  • 判断问题：这是现在没有的新能力或改动吗（不是缺陷）？是否需要研发投入工时？是否影响当前迭代范围？
  • 不归本流程管：已有功能不符预期 → 请走 RND-03；AI 表现不佳 → 请走 RND-02；全新产品或跨团队基础能力立项 → 请走 RND-05；客户合同范围外需求的商务确认 → 请走 SAL-25（合同范围外需求拦截与客户预期管理）；已签合同的变更 → 请走 SAL-36（销售合同变更、终止与退换货处理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求提出人 按模板提交，说明背景、目标、验收标准 R 各部门/客户对接人
产品经理 澄清、写需求文档、组织评审、维护需求池、验收 R 产品经理（当前：黄飞鹏、陈震、杨黔昆·推断待确认）
产品负责人 初筛取舍、定优先级、插队拍板、评审结论 A 产品负责人（当前：杨萌·推断待确认）
研发负责人 技术方案、估点、迭代容量把关、插队共同确认 C 研发负责人（当前：王皓南·推断待确认）
CTO 客户项目需求分档、合同外需求判定 A（升级） CTO（当前：丁震宇·推断待确认）
跃竞负责人 跃竞线需求排序有争议时拍板 A（升级） 跃竞负责人（当前：徐莉·推断待确认）
跃竞产品经理 跃竞线需求评审组织、迭代文档维护 R（分支） 产品经理（当前：段涵、陈雁·推断待确认）
测试 评审时提出可测性与验收口径 C 测试负责人（当前：张东郅·推断待确认）

3. 办之前请准备

  • 需求来源（谁提、哪个客户/合同、是否为领导指令）
  • 背景与目标：为什么做、做来干什么、不做的影响
  • 验收标准：可验证的完成条件；涉及权限的写清权限码与默认角色
  • 期望上线时间、涉及端（前端/后端/客户端/移动端）
  • 相关截图、原型或竞品对照

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交需求池表单；领导或客户的口头方向由产品经理当天整理入池并注明来源 提出人/产品经理 提出当天 飞书多维表格需求池 需求记录 🔧飞书固化
2 澄清：补齐背景、目标、验收标准；缺"为什么做"的退回提出人 产品经理 2 个工作日内 需求池/需求文档 完整需求 🤖+👤
3 初筛：分为做/不做/待定，砍掉不合理部分，给出初始优先级 产品负责人 每周一次 需求池视图 初筛结论 👤人工判断
4 评审会：会前 1 个工作日发材料；参会人为产品、相关模块研发、测试；技术方案与估点在会上确定 产品经理组织 迭代规划前 2 个工作日 飞书会议+妙记 评审结论 👤人工判断
5 会后把结论（做/不做、方案、估点、优先级）写回需求池并在群里同步 产品经理 会后 24 小时内 需求池+机器人 纪要与回写 🔧+🤖
6 拆卡建工单：估点 1/2/3/5，超过 5 必须拆分；未设优先级的不能离开"评审"；工单附需求池链接和验收人 研发负责人/产品经理 规划会当天 issues 工单系统 迭代工单 🔧飞书固化
7 核对迭代容量，超出部分顺延下个迭代 研发负责人 规划会当天 迭代看板 迭代范围 👤人工判断
8 插队：填写插队申请（优先级、理由、挤出项），产品负责人和研发负责人共同确认后在看板标注 提出人/产品负责人 1 个工作日内答复 工单+看板 插队记录 👤人工判断
9 开发完成后由产品验收，验收通过才算完成（与 RND-03 验收衔接） 产品经理 转验收后 2 个工作日内 工单状态 验收结论 👤人工判断
10 迭代回顾：未完成需求回池或顺延，更新需求池状态 产品经理 迭代最后一天 需求池 回顾记录 🔧+🤖

5. 交付物与模板

  • 交付物：需求池记录、需求文档、评审纪要、迭代工单、插队记录、验收结论
  • 建议模板/表单（需求池）：编号、标题、提出人、来源（内部/客户/领导/反馈群）、关联客户与合同内外、背景、目标、验收标准、涉及端、权限码、期望时间、优先级、初筛结论、评审结论、估点、目标迭代、关联工单、验收人、状态（待澄清/待评审/已排期/开发中/待验收/已完成/不做）
  • 插队申请字段：需求、优先级、插队理由、挤出项、确认人、确认时间
  • 评审会模板：议题、参会分层（必到/可选）、会前材料、结论、待办与负责人

6. 异常与升级

  • 需求描述 2 个工作日仍不清 → 退回提出人，不进评审 → 不升级
  • 评审后结论被推翻（领导或业务方改方向）→ 产品经理记录变更来源，重估影响 → 升级产品负责人（当天）
  • 插队导致迭代目标无法完成 → 明确挤出项并通知相关方 → 升级研发负责人与产品负责人（1 个工作日内）
  • 客户现场提出合同外需求 → 现场不承诺，记录后回报 → 升级 CTO 拍板分档与合同内外判定（A（升级）），同步销售负责人（1 个工作日内）
  • 跃竞线需求排序或评审结论有分歧 → 跃竞产品经理整理各方意见 → 升级跃竞负责人拍板（A（升级），当天）
  • 需求归属不清（哪个团队/哪个代码库）→ 研发负责人当天判定 → 不能判定时升级 CTO

7. 衡量指标

  • 留痕率：已开发需求中在需求池有记录和来源的比例，目标 100%
  • 澄清时效：提出到可评审的工作日数，目标 ≤ 2 天
  • 插队率：迭代中插入需求点数占迭代总点数比例，目标 ≤ 15%
  • 评审结论回写时效：会后回写需求池的时长，目标 ≤ 24 小时
  • 需求返工率：因需求理解偏差导致返工的工单占比，目标 ≤ 10%

8. 低效诊断

  • 需求在聊天里口头提出，事后忘记来源和口径，需要反复解释｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-04
  • 评审中的口径没写进文档，迭代末才暴露分歧｜依据：「鼎慧产研决策部」2026-01
  • 产品讨论会参会没有规则，会议拖长，决策介入晚导致原型反复改｜依据：「鼎慧产研决策部」2026-06
  • 迭代中插队没有优先级和挤出项，插入后研发临时救火｜依据：「鼎慧产研决策部」2026-07
  • 工作台与工单不是一一对应，状态停在"处理中"导致漏验收｜依据：「跃迁AI总动员」2026-05、「鼎慧产研决策部」2026-03
  • 需求管理表负责人或内容为空，状态忘记更新，载体反复改版｜依据：「跃玩项目组」2026-01、「跃玩项目组」2026-02、「跃玩项目组」2026-06
  • 迭代已创建后再追加需求，需求归属哪个团队不清｜依据：「研发通知」2026-10
  • 评审会时间临时通知，优先级靠群里点名｜依据：「跃玩remote工作组」2026-07、「跃玩remote工作组」2026-08、「跃玩会员端」2026-04
  • 客户现场新需求是否在合同内依赖个人判断，研发被多线打断｜依据：「跃迁基座项目交付沟通」2026-02、「跃迁基座项目交付沟通」2026-03

9. 分支变体

  • 常规迭代需求：两周一迭代，按第 4 节执行
  • 迭代中插队/临时需求：必须走第 8 步插队确认；机器人可起草工单，但提交人身份、优先级、是否插队必须人工确认
  • 领导或业务方方向类需求：先由产品负责人确认再下发，产品经理当天整理入池
  • 客户现场需求（政企现场部署项目）：按"优先做/次要做/不做"分档，标注合同内外和版本归属（哪个代码库），由 CTO 拍板
  • 跃竞线：需求管理多维表格+机器人"新增需求提醒"→ 周迭代文档 → 工作台；评审会由产品经理发起，智能纪要回写；例会前汇总当周工作到迭代文档
  • 产品讨论会分层：方向对齐会（产品负责人+研发负责人，少人）；内部评审会（含技术估点）；结论 24 小时内同步到全体研发

10. 待确认问题

  • 需求池以哪个载体为准（工作台、issues 系统"评审"状态，还是多维表格），是否只保留一个？
  • 插队申请由谁最终拍板，插队上限 15% 是否合适？
  • 产品评审会的必到人员如何分层？
  • 客户合同外需求的判定由 CTO 还是销售负责人主导？
  • 跃竞线是否并入统一需求池和迭代节奏？
RND-05新产品/新项目研发立项与分工待新建128

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：提出新产品、新客户端或跨团队基础能力（如 MercAll/ClawLite、MercPay/LeapPay 支付中台、billing、电子签）需要多人协作落地时，完成立项、定角色、写需求、建协作载体、拆任务并跟踪到 MVP 验收
  • 负责人：主责——项目技术负责人（立项时指定，当前：待指定）；协同——研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、外部/领域技术顾问（如支付，当前：王子明·推断待确认）、财务负责人（涉资金链路时，当前：黄梦婷·推断待确认）、法务负责人（涉电子签时，当前：李瑶·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 立项提出 → ② 立项卡（目标/MVP 范围/不做项/DDL）→ ③ 角色表 → ④ PRD/用户故事 → ⑤ 需求梳理会+纪要 → ⑥ 建仓库、群、工单项目、里程碑 → ⑦ 拆任务进看板 → ⑧ 进度同步 → ⑨ MVP 验收并转入常规迭代
  • 交付结果：经 CTO 确认的立项卡、角色表、PRD/用户故事、需求梳理会纪要、工单项目与里程碑、MVP 验收结论
  • 状态依据：两次立项（2026-03 MercAll、2026-04 MercPay）都是口头点名分工、需求零散发送后再补文档，开发多次"没懂""我是干啥的"，进度靠群里追问，没有立项模板和任务看板

1. 场景判定

  • 触发条件：新产品或新客户端提出；需要多个团队共建的基础能力；POC 项目要转正式产品；客户端重写
  • 典型说法：「先按 MVP 做，有些东西不用太智能和流畅」「来看看需求有没有疑问的」「那我是干啥的」「我要什么功能你做什么功能」「今天做完了哪些，还差多少」
  • 判断问题：是否需要 2 人以上、超过 2 周投入？是否需要新建代码仓库或新协作群？是否涉及资金、合同或外部接口？
  • 不归本流程管：已有产品的迭代需求 → 请走 RND-04；客户定制交付项目 → 请走 X-DLV-08（交付项目台账与立项留痕）、X-DLV-10（客户定制需求承接、拆解与排期）；缺陷修复 → 请走 RND-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
立项发起人 提出目标与 MVP 范围、DDL R CTO 或产品负责人
CTO 立项审批，指定项目技术负责人，范围最终拍板 A CTO（当前：丁震宇·推断待确认）
项目技术负责人 技术方案、任务拆分、派活、进度汇报 R 待指定（每个项目单独指定）
研发负责人 范围把关（只做立项卡内的功能），技术评审，监工 C 研发负责人（当前：王皓南·推断待确认）
产品负责人 写 PRD/用户故事，验收 MVP R（需求） 产品负责人（当前：杨萌·推断待确认）
测试负责人 测试计划，MVP 验收测试 C 测试负责人（当前：张东郅·推断待确认）
领域技术顾问 外部接口、行业规则咨询 C 支付技术顾问（当前：王子明·推断待确认）
财务/法务 涉资金链路、电子签时参与评审 C 财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 立项目的、目标用户、成功标准和上线 DDL
  • MVP 范围与"不做项"清单
  • 可投入人力，以及每人现有任务负载（避免一人同时负责两条产品线）
  • 外部依赖：第三方接口、支付通道、风控规则、合规要求
  • 预算与成本估算（云资源、第三方费用）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写立项卡：目标、MVP 范围、不做项、DDL、外部依赖、风险 立项发起人 提出后 2 个工作日内 飞书多维表格立项库 立项卡 🔧飞书固化
2 审批立项，指定项目技术负责人 CTO 1 个工作日内 飞书审批 立项结论 👤人工判断
3 发布角色表：技术负责人、开发、顾问、需求、测试、监工，每人写清职责 项目技术负责人 立项后 1 个工作日内 立项卡+项目群公告 角色表 🔧飞书固化
4 编写 PRD，并转成用户故事清单（角色/场景/验收标准） 产品负责人 立项后 3 个工作日内 飞书 wiki PRD、用户故事 🤖+👤
5 需求梳理会：逐条过用户故事，现场答疑，确认范围；纪要自动生成 项目技术负责人组织 PRD 完成后 2 个工作日内 飞书会议+妙记/纪要机器人 会议纪要 🔧+🤖
6 建协作载体：代码仓库、项目群、工单项目、里程碑 项目技术负责人 梳理会当天 Gitea+issues+飞书群 协作载体 🔧飞书固化
7 拆任务进看板，每项有负责人、估点、截止日期 项目技术负责人 梳理会后 1 个工作日内 issues 看板 任务清单 👤人工判断
8 进度同步：看板每日更新，每周向 CTO 汇报完成率与风险；外部规则变化当天评估影响 项目技术负责人 每日站会/每周五 看板+群公告 进度周报 🤖+👤
9 MVP 验收：主流程跑通、无致命缺陷，验收结论入立项卡 产品负责人+测试负责人 DDL 前 2 个工作日 测试环境+工单 验收结论 👤人工判断
10 转入常规迭代：后续需求走 RND-04，缺陷走 RND-03 项目技术负责人 验收通过后 需求池 移交记录 🔧飞书固化

5. 交付物与模板

  • 交付物：立项卡、角色表、PRD/用户故事、需求梳理会纪要、工单项目与里程碑、进度周报、MVP 验收结论
  • 建议模板/表单（立项卡）：项目名、发起人、目标与成功标准、MVP 范围、不做项、DDL、角色表（姓名、职责、投入比例）、外部依赖、风险与应对、预算估算、仓库/群/工单项目链接、状态（立项中/开发中/验收中/已转迭代/已终止）
  • 用户故事模板：作为〈角色〉，在〈场景〉下，我要〈功能〉，以便〈价值〉；验收标准；优先级

6. 异常与升级

  • 开发对需求表示"没懂"超过 2 次 → 暂停开发，补用户故事并重新开梳理会 → 升级产品负责人（当天）
  • 外部规则（如支付风控）变化导致方案需重做 → 评估影响并调整范围与 DDL → 升级 CTO（1 个工作日内）
  • 进度落后计划 ≥ 3 个工作日 → 技术负责人提出砍范围或加人方案 → 升级 CTO
  • 一人同时承担两条以上产品线的主开发 → 重新分工 → 升级研发负责人（立项时即检查）
  • 纪要或文档中出现商户号、密钥等敏感信息 → 立即删除并改用密钥管理工具 → 通知 CTO（当天）

7. 衡量指标

  • 立项留痕率：新项目中有立项卡和角色表的比例，目标 100%
  • 需求就绪时效：立项到 PRD/用户故事定稿的工作日数，目标 ≤ 3 天
  • MVP 按期率：按 DDL 通过 MVP 验收的项目占比，目标 ≥ 80%
  • 范围变更次数：立项后 MVP 范围的变更次数，目标 ≤ 2 次

8. 低效诊断

  • 需求先口头零散发出，开发多次表示没懂、问有没有上下文，文档事后才补｜依据：「LeapPay」2026-04
  • PRD 过长过杂，开发看不下去，当晚重写成用户故事｜依据：「LeapAll（Deprecated）」2026-03
  • 角色只在群里口头点名，参与者不清楚自己负责什么｜依据：「LeapPay」2026-04
  • 一人同时负责客户端和商店两条线，分工过载｜依据：「LeapAll（Deprecated）」2026-04
  • 没有任务看板，进度靠群里反复追问｜依据：「LeapAll（Deprecated）」2026-03、「LeapPay」2026-04
  • 立项时没识别外部依赖风险，支付风控规则变化后方案大半推翻｜依据：「LeapPay」2026-05
  • 范围边界摇摆（独立中台还是直接对接），需反复强调"只做要求的功能"｜依据：「LeapPay」2026-04

9. 分支变体

  • 单团队新产品（如 MercAll 余额中心+SKILL 商店+ClawLite 客户端）：立项卡可简化，DDL 紧时以 MVP 为准，"基本流程跑通、无致命缺陷"作为验收线
  • 跨团队基础能力（MercPay→LeapPay→LeapCore 支付子系统、billing、电子签）：必须有领域顾问；涉资金链路的需财务参与评审；测试计划需含对账与退款场景
  • POC 项目：可不维护订单等完整链路，但需在立项卡注明 POC 性质和转正条件
  • 二期功能/客户端重写：沿用原项目的仓库和群，新增立项卡版本

10. 待确认问题

  • 立项审批是否统一由 CTO 拍板，还是涉及资金/对外的需 CEO 参与？
  • 立项卡放在哪个多维表格，由谁维护？
  • "2 人以上、超过 2 周"作为立项门槛是否合适？
  • 涉资金链路项目的财务、法务对接人是谁？
  • POC 转正式产品的判定标准是什么？
RND-06迭代规划、工单拆分与排期待优化108

状态：待优化｜证据：有证据（卡片 16 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨3 × 险3

  • 适用场景：每个迭代（约两周）开始前，或新产品/大版本确定上线日期需要倒排时，把需求池整理成有人认领、有点数、有截止日的迭代计划
  • 负责人：主责——研发负责人/迭代负责人（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌、黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各模块负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 产品冻结迭代需求清单 → ② 研发拆故事卡/工单并关联需求 → ③ 估点与容量校验 → ④ 迭代规划会定范围与优先级 → ⑤ 认领与截止日 → ⑥ 倒排关键节点（提测/冻结/UAT/发版）→ ⑦ 发布迭代计划并通知
  • 交付结果：已发布的迭代计划（cycle/milestone）：全部工单有唯一负责人、点数、优先级、截止日并关联需求，附关键节点日历与规划会纪要
  • 状态依据：已有 issues 工单系统、迭代规划会、点数制度与规划文档，但 1～10 月多个产研群反复出现“迭代 issue 还是空的”“AI 估点明显低估”“版本号/milestone/工作台三处不一致”“迭代末集中提测测不完”，规划会时间与会议室多为临时通知，容量规则多次口头调整

1. 场景判定

  • 触发条件：上一迭代收尾前 2～3 个工作日；新产品/大版本确定上线日期需要倒排；迭代中途出现 P0 插单或人员变动需要重排
  • 典型说法：「下个迭代的 issue 大家先看看，明天开规划会」「本迭代规划已更新，请产品、测试确认并认领项目」「倒排一下任务节点，落实到人，粒度到天，要有验收」「本迭代的 issue 还是空的」
  • 判断问题：这件事是否要占用下一迭代的研发容量？是否需要多人/多模块协作并在某个日期交付？是 → 走本流程；只是单个 bug 修复且当前迭代有余量 → 直接建工单（RND-11）
  • 不归本流程管：需求是否立项与业务优先级 → 请走 X-PRD-09（需求提报登记与需求池管理）；模块归属不清、找不到人 → 请走 RND-07；迭代执行中的催办与延期上报 → 请走 RND-08；发版/OTA 闸门 → 请走 RND-51（正式版本发布上线）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
迭代负责人 建 cycle/milestone、拆卡估点、主持规划会、发布计划 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准迭代范围与里程碑，裁决优先级与人力冲突 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品经理 提交冻结的需求清单、PRD/UX 稿、验收标准；审查工单范围与优先级 R 产品经理（当前：杨萌、黄飞鹏、陈震·推断待确认）
测试负责人 评估测试工作量，确认提测与回归节点 C 测试负责人（当前：张东郅·推断待确认）
模块负责人/研发 复核点数、认领工单、提出技术风险 R 各模块研发（当前：待指定）
销售/市场 知悉对外承诺的上线日期 I 销售负责人（当前：待指定）

3. 办之前请准备

  • 产品侧：本迭代需求清单（优先级 P0/P1/P2、PRD 链接、UX 稿或按键改动清单、验收标准、期望上线日）
  • 研发侧：上一迭代未完成工单清单及原因；每人可用人天（请假、借调、值班、培训）
  • 测试侧：本迭代可投入测试人力、回归范围
  • 关键日期：对外承诺的上线日、节假日（迭代不跨长假）、代码冻结日
  • 系统：issues 工单系统中新 cycle/milestone 已建；规划会周期日程与会议室已预订

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 冻结下一迭代需求清单，标优先级并附 PRD/UX/验收标准，@迭代负责人“待评估” 产品经理 迭代开始前 3 个工作日 飞书多维表格需求池 冻结需求清单 🔧飞书固化
2 建新 cycle/milestone，把需求拆为故事卡/工单；每张工单引用需求链接与验收标准，缺 UX 稿的退回产品 迭代负责人 迭代开始前 2 个工作日 issues 工单系统 工单草稿 🔧+🤖
3 估点（1 点≈1 人日，按复杂度），AI 估点必须由模块负责人复核；对比上迭代实际完成点算容量 迭代负责人、模块负责人 迭代开始前 1 个工作日 issues 点数字段、容量表 点数与容量对比表 🤖+👤
4 召开迭代规划会：过范围、优先级、风险；超容量项当场砍掉或挪下迭代，形成“不做清单” 迭代负责人主持，产品/测试/研发参会 迭代第 1 天，≤60 分钟 飞书日程+会议室+智能纪要 定稿范围、会议纪要 🔧飞书固化
5 认领工单：每张有唯一负责人、截止日、优先级；会后仍无人认领的由迭代负责人直接指派 研发、迭代负责人 规划会后 4 小时内 issues 工单系统 全部工单已指派 🔧+🤖
6 倒排节点：重难点第一周完成、迭代中点提测、代码冻结、UAT、发版日，写入迭代页 迭代负责人 规划会当天 迭代文档、飞书日历 节点日历 👤人工判断
7 在研发通知群发布迭代计划链接并 @相关人；产品同步对外承诺日期 迭代负责人、产品经理 规划会当天下班前 飞书群+机器人 迭代计划公告 🔧+🤖
8 迭代中途插单：评估点数，同时移出等量工单，经产品与迭代负责人双方确认后改工单 迭代负责人、产品经理 插单当天 issues 工单系统 范围变更记录 👤人工判断

5. 交付物与模板

  • 交付物：迭代计划页（cycle/milestone）、规划会纪要、节点日历、迭代计划群公告、范围变更记录
  • 建议模板/表单：
    • 需求清单字段：需求ID、标题、优先级、PRD 链接、UX 稿链接、验收标准、来源（客户/内部）、期望上线日、产品负责人
    • 工单字段：标题、关联需求ID、验收标准、点数、负责人、截止日、优先级、迭代、状态
    • 迭代计划页：迭代起止日、容量（人天/点数）、范围清单、不做清单、关键节点（中点提测/代码冻结/UAT/发版）、风险项与备份负责人

6. 异常与升级

  • 规划会前需求未冻结或缺 UX 稿/验收标准 → 该需求不进本迭代 → 产品经理当天知悉，争议升级研发部门负责人（1 个工作日内）
  • 规划点数超出上迭代实际完成点 20% 以上 → 迭代负责人当场砍范围 → 争议升级研发部门负责人（规划会后 1 个工作日内裁决）
  • 单人同时承担 2 个以上 P0 → 拆分或指定备份负责人 → 升级研发部门负责人（规划会当天）
  • 迭代中途 P0 插单无法等量置换 → 升级研发部门负责人（4 小时内决定延期或加人）
  • 迭代跨长假 → 调整迭代起止日避开假期 → 迭代负责人决定，规划会前公告

7. 衡量指标

  • 规划准时率：迭代第 1 天下班前完成计划发布的迭代数 / 迭代总数，目标 ≥ 90%
  • 工单完整率：有负责人+点数+截止日+关联需求的工单 / 迭代工单总数，目标 100%
  • 估点偏差：|实际完成点 − 计划点| / 计划点，目标 ≤ 20%
  • 迭代承诺达成率：迭代末已验收点数 / 规划点数，目标 ≥ 80%
  • 中途插单率：迭代中新增点数 / 规划点数，目标 ≤ 15%

8. 低效诊断

  • 现象：迭代已开始但工单系统内迭代仍为空，测试无法提前准备——缺“需求冻结”前置环节｜依据：「Leap产研测」2026-07
  • 现象：PRD、评审、拆卡顺序混乱，文档写完才发现与需求不符；同一插单反复确认放不放｜依据：「鼎慧产研决策部」2026-03
  • 现象：AI 估点未经复核，明显低估，hotfix 前才发现做不完——缺估点复核与历史校准｜依据：「Leap产研测」2026-08
  • 现象：版本号、milestone、产品工作台三处口径不一致，靠事后口头同步｜依据：「工程咨询产研」2026-06
  • 现象：需求缺 UX 稿，研发无法拆 issue｜依据：「工程咨询产研」2026-05
  • 现象：容量规则多次口头调整，未完成工单被自动搬迁后又回挪｜依据：「Leap产研决策部」2026-08、「Leap产研决策部」2026-09
  • 现象：迭代末周五仍大量提测，测试排不下，影响周一发版——缺提测冻结节点｜依据：「Leap产研测」2026-07
  • 现象：模块分工靠群消息发布，新接手人缺上下文；排期压缩挤掉测试与修 bug 时间｜依据：「Leap产研测」2026-04
  • 现象：规划会时间与会议室临时通知，出现重复日程｜依据：「研发通知」2026-07、「鼎慧产研决策部」2026-07

9. 分支变体

  • Leap 主线（LeapCore/LeapAll/LeapNew/v5）：issues 工单系统 cycle 制，按点数管理；v5 等专项冲刺可用里程碑制
  • 字字可研/工程版：产品在飞书 wiki 需求表整理分组后交研发；issue 必须引用产品需求，测试按 issue 做单元测试，单需求所有 issue 部署后做需求级集成测试
  • 新产品上线倒排：先出平台设计文档定边界，再按模块列负责人+备份人，按“非 agent 部分先部署 → 功能验收 → agent 评审与接入测试”倒排，粒度到天；C 端页面完成后同步评估 B 端复用
  • 客户定制包/hotfix：P0 单列，不占常规迭代范围，或按步骤 8 等量置换

10. 待确认问题

  • 迭代负责人是否固定为研发负责人，还是按产品线（Leap 主线/字字可研/v5）各设一人？是否需要轮值排班？
  • 迭代周期是否统一为两周、统一周几开始？工程组与基座组节奏是否已统一？
  • 点数口径：“1 点≈1 人日、按复杂度”是否为正式标准？每人每迭代最低 7 点与团队容量 168 点以哪个为准？
  • 需求冻结时限“迭代开始前 3 个工作日”是否可行？
  • 需求池（飞书多维表格）与 issues 工单系统以谁为唯一数据源？是否做单向同步？
  • 未完成工单是否自动迁移到下一迭代？是否禁止迭代末周五下班后提测？
RND-07研发任务分派、模块负责人与归属判定待新建108

状态：待新建｜证据：有证据（卡片 15 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：新迭代分工、出现无人认领的 bug/工单、跨团队问题不知找谁、成员超载/闲置/借调/改汇报线、新人入职派活时，确定唯一端到端负责人并维护模块负责人清单
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、各模块负责人（当前：待指定）、人事负责人（当前：黄莹·推断待确认，仅汇报线调整/新人入职时）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 维护模块负责人清单（主责/兜底/PR 审批人）→ ② 新问题按清单定位并指派 → ③ 查不到时首个接手人暂管并上报 → ④ 研发负责人裁定端到端负责人 → ⑤ 每周负载检查与调配 → ⑥ 人员变动填交接单并转派工单 → ⑦ 更新清单并公告
  • 交付结果：公开的“模块—主责—兜底—PR 审批人—对外接口人”清单；每项任务/工单有唯一端到端负责人；人员调整有交接单
  • 状态依据：无成文模块负责人清单（仅有一次性分工文档与群内口头清单），1～10 月各产研群反复出现“这个谁负责/谁来修/到底谁在做”约 40 次，出现重复开发、负责人请假仍挂名、交接无模板

1. 场景判定

  • 触发条件：新增模块/产品线；规划后仍有工单无负责人；测试或反馈群提问找不到对应开发；同一工单多人重复做；成员闲置或超载；成员借调、改汇报线、离岗或请假超过 3 个工作日；新人入职
  • 典型说法：「这个谁来修？还没指派」「这个没 assign 的 bug 有人在做吗」「到底谁在做」「定制 skills 谁管」「没人给他派活」
  • 判断问题：我能在模块负责人清单里找到唯一且在岗的负责人吗？找不到、或清单上有多人、或负责人不在岗 → 走本流程
  • 不归本流程管：迭代整体范围与排期 → 请走 RND-06；已有负责人但进度拖延 → 请走 RND-08；工单字段与状态维护 → 请走 RND-11；招聘 → 请走 X-RCT-01（招聘需求提报与 HC/预算/优先级管理）；长期调岗、借调与汇报线确认 → 请走 HR-25（人员调岗、借调与汇报线确认）；研发绩效 → 请走 HR-19（研发绩效评价与质量奖惩）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 维护模块负责人清单、裁定归属、派活、负载调配 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准分工框架、跨团队归属裁决、人员借调与汇报线调整 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品负责人 提供需求侧归口、确认功能边界、对新人任务目标提出要求 C 产品负责人（当前：杨萌·推断待确认）
模块负责人 对模块端到端交付与合入的 PR 负责，指定兜底人 R 各模块负责人（当前：待指定）
测试/提问人 按清单定位并指派，找不到时上报 R 测试负责人（当前：张东郅·推断待确认）
首个接手人/交出人/接手人/兜底人 查不到负责人时暂管并上报；人员变动时填交接单、确认接手；负责人请假时接管工单 R 相关研发成员（当前：按模块负责人清单）
人事 汇报线调整、新人入职信息登记 I 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 问题/需求描述与链接（工单号、截图、复现路径）、涉及模块与产品线、紧急程度
  • 已知可能相关的人员与历史工单
  • 人员调整时：被调整人在手工单清单、现状说明、账号权限清单、相关文档链接
  • 新人入职时：岗位目标、首月任务、验收标准、派活人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立并维护模块负责人清单（模块、产品线、主责、兜底、PR 审批人、对外接口人），群公告置顶 研发负责人 每次迭代规划后 1 个工作日内更新 飞书多维表格、群公告 模块负责人清单 🔧飞书固化
2 新问题/工单按清单定位负责人并指派；工单系统按模块标签自动指派 提问人/测试/产品 发现后 2 小时内 issues 工单系统 已指派工单 🔧+🤖
3 清单查不到：首个接手人暂管，登记“待归属”并 @研发负责人 首个接手人 发现后 1 个工作日内 多维表格“待归属”视图 待归属记录 👤人工判断
4 裁定归属：按“一条功能链路一人负责到底”指定端到端负责人，更新清单 研发负责人 收到后 1 个工作日内 多维表格 归属结论 👤人工判断
5 每周负载检查：在手点数 <团队平均 50% 视为闲置、>150% 或同时 2 个以上 P0 视为超载，调整分工 研发负责人 每周一站会后 issues 负载视图 调整清单 🤖+👤
6 人员变动交接：交出人填交接单，工单批量转派，接手人确认后在站会过一遍 交出人、接手人 调整生效前 1 个工作日 飞书文档模板、issues 交接单、转派记录 🔧飞书固化
7 汇报线调整/借调：研发负责人提出，研发部门负责人批准，研发通知群公告，人事知悉 研发负责人 生效前 1 个工作日 飞书群、人事系统 调整公告 🔧飞书固化
8 新人入职：用人负责人写入职任务书（岗位目标、首月任务、验收标准、派活人），首周周会检查 研发负责人 入职前 1 个工作日 飞书文档、飞书任务 入职任务书 🔧+👤
9 负责人请假超过 3 个工作日：兜底人接管，工单负责人字段转派 模块负责人、兜底人 请假生效当天 issues 工单系统 转派记录 🔧飞书固化

5. 交付物与模板

  • 交付物：模块负责人清单、待归属登记、交接单、调整公告、入职任务书
  • 建议模板/表单：
    • 模块负责人清单字段：模块、产品线、主责、兜底、PR 审批人、对外接口人、关联仓库、更新日期
    • 交接单字段：交出人、接手人、生效日、在手工单（链接/状态/剩余工作）、未完成项、已知风险、账号权限、相关文档、接手确认
    • 入职任务书字段：岗位目标、首月任务（可验收）、验收标准、派活人、检查节点（第 1/2/4 周）

6. 异常与升级

  • 两个团队均认为不归自己 → 暂管人继续处理，研发负责人 1 个工作日内裁定 → 跨部门（开放平台/FDE/销售）升级研发部门负责人（2 个工作日内）
  • 同一工单发现多人在做 → 以工单负责人为准，其他人停止并转协作 → 研发负责人当天确认
  • 关键人单点（无兜底）→ 研发负责人 1 周内指定兜底 → 涉及招人时升级研发部门负责人
  • 认领后 3 个工作日无进展 → 机器人提醒，研发负责人收回重派 → 当天
  • 新人首周仍无明确任务 → 研发负责人补任务书 → 升级研发部门负责人（2 个工作日内）

7. 衡量指标

  • 无主工单数：迭代中无负责人的工单数，目标每日 0
  • 归属裁定时长：从登记“待归属”到裁定的工作日，目标 ≤ 1 天
  • 重复开发次数：同一工单多人同时开发的次数，目标每迭代 0
  • 清单覆盖率：有主责+兜底的模块 / 全部模块，目标 100%
  • 交接单覆盖率：有交接单的人员调整 / 人员调整总数，目标 100%

8. 低效诊断

  • 现象：测试与反馈处理时找不到负责人，只能群里 @可能的人；负责人请假近一个月仍挂名｜依据：「Leap产研测」2026-07
  • 现象：无人指派的 bug 被两人同时做，同功能不同团队归属不清｜依据：「Leap产研测」2026-08
  • 现象：交出方未拆分 P0，在手事项无人知晓，交接无模板｜依据：「Leap产研测」2026-05
  • 现象：分工框架反复争论（全栈通吃 vs 按功能固定），成员重叠，单人兼运维与后端被临时活打乱｜依据：「鼎慧产研决策部」2026-01
  • 现象：新入职人员无任务书，多方以为别人在派活，任务被反复重新解释｜依据：「鼎慧产研决策部」2026-02
  • 现象：“负责人”“兜底”“PR 合并”口径不一，出现有人没活、有活没人干｜依据：「鼎慧产研决策部」2026-07
  • 现象：一条功能链路（换模型、开放平台接 skill）需找三四个人｜依据：「Leap产研决策部」2026-09
  • 现象：ODM、定制 skills 等跨团队需求无人认领｜依据：「Leap产研决策部」2026-10
  • 现象：交付节点前分工频繁变动，登录模块多人重做，有人手头没活｜依据：「LeapCore（archived）」2026-05
  • 现象：汇报线调整一句话公告，原迭代任务去向不明｜依据：「研发通知」2026-06
  • 现象：关键人同时负责多个客户项目，单点过载｜依据：「跃迁基座项目交付沟通」2026-05

9. 分支变体

  • 分工方式：默认按功能纵切（单人负责整条链路）；网关、基础设施等平台能力可横切，由平台负责人对外提供接口
  • 多产品线并行：需求侧与进度统一对齐产品负责人；技术咨询找研发负责人/基座负责人；决策分歧找研发部门负责人；容器/硬件找 IT 运维
  • 客户项目并行：优先级由研发部门负责人统一宣布（按交付节点与付费情况），关键人一次只对接一个项目方
  • 长期汇报线调整 vs 短期借调（如协助测试验收）：借调不改清单主责，只在工单上加协作人
  • 新人：测试开发与评测工程师定位不同，任务书中须写明是软件测试还是 Agent 评测
  • 赛马机制：两人各负责独立模块并设统一截止日，结束后再定长期负责人

10. 待确认问题

  • 模块负责人清单由谁维护、放哪个多维表格？是否与公司架构图同步？
  • “负责人 = 主力开发 + 兜底 + 对合入 PR 负责”是否作为正式定义？
  • 默认纵切还是横切？开放平台是否并入 Leap 统一管理？
  • “不确定谁管就是你管”作为正式规则时，暂管人的权责与时限如何界定？
  • 借调/汇报线调整的审批人是研发部门负责人还是 CEO？是否需要人事参与？
  • 闲置/超载阈值（50%/150%）是否合适？
RND-08研发进度跟催与延期风险上报待优化240

状态：待优化｜证据：有证据（卡片 16 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：迭代/冲刺执行中，按工单跟踪进度、处理阻塞、节点前收口；预计延期时由负责人主动上报风险并决策调整范围或日期
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各工单负责人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 工单负责人每日更新状态并主动提测 → ② 机器人每日推送超期/未领/阻塞清单 → ③ 站会逐项处理 → ④ 节点 D-3 风险盘点 → ⑤ 预计延期按模板主动上报 → ⑥ 决策加人/砍范围/延期 → ⑦ 对外同步新日期 → ⑧ 迭代末归类延期原因
  • 交付结果：每日进度异常清单、延期风险登记（原因、影响、新日期、决策人）、对测试与销售同步的最终范围与上线日期、迭代延期原因统计
  • 状态依据：已有工单系统、站会、截止日字段，但 1～10 月进度主要靠负责人在群里逐个 @催问（累计上百次），“最后一天才暴雷”“截止日期没人看”“延期当天才报”反复出现，发版负责人与范围曾无人确定

1. 场景判定

  • 触发条件：迭代/冲刺执行中每日跟踪；节点（提测、代码冻结、发版、对外交付）前 3 个工作日；工单超期；阻塞超过半天；需求方追问上线时间；P0 插单影响原节点
  • 典型说法：「一键查询进度」「做不完的需求今天下班前在群里报一下风险」「有进展就说一下，别憋着」「你得主动提测，不然就算没干完」「本周要上线的需求都交给测试了吗」
  • 判断问题：已承诺的日期还能按期完成吗？我是否有超过半天解不开的阻塞？任一为“否/是” → 立即走本流程上报
  • 不归本流程管：迭代初始范围与排期 → 请走 RND-06；负责人归属不清 → 请走 RND-07；站会形式与纪要 → 请走 RND-09；日报周报格式 → 请走 RND-10；发版闸门与回滚 → 请走 RND-51（正式版本发布上线）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 每日看异常清单、站会处理阻塞、组织 D-3 盘点、延期决策 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 涉及对外承诺/P0 的延期与加人决策 A 创始人兼 CTO（当前：丁震宇·推断待确认）
工单负责人 每日更新状态、主动提测、主动上报风险 R 各工单负责人（当前：待指定）
产品负责人 参与砍范围/延期决策，对销售/市场同步日期 C 产品负责人（当前：杨萌·推断待确认）
测试负责人 评估测试窗口，窗口不足时提出风险 C 测试负责人（当前：张东郅·推断待确认）
销售/市场 知悉最终上线日期与范围 I 销售负责人（当前：待指定）

3. 办之前请准备

  • 迭代计划页与节点日历（来自 RND-06）
  • issues 工单系统中“超期/今日到期/无人认领/阻塞”视图已配置
  • 风险上报模板（见第 5 节）
  • 已对外承诺的日期清单（客户、渠道、市场活动）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 开工即改“进行中”，每日下班前更新状态与剩余工作量；完成即合并并部署测试环境，主动 @测试提测 工单负责人 每日 18:30 前 issues 工单系统 最新工单状态 🔧飞书固化
2 机器人推送“超期/今日到期/无人认领/进行中超 3 天无更新/阻塞”清单到研发群并 @负责人 机器人（研发负责人配置） 每工作日 9:30 issues+飞书机器人 异常清单 🤖自动化
3 站会逐项过异常清单，阻塞项当场指定协助人和解除时间 研发负责人 每日站会内 issues 站会视图 阻塞处理记录 👤人工判断
4 节点 D-3 风险盘点：每人标“能完成/有风险/做不完”，有风险的给乐观/平均/悲观三档日期 工单负责人、研发负责人 节点前 3 个工作日 issues 风险字段 风险盘点表 🔧+👤
5 预计延期主动上报：工单链接、原因分类、影响范围、新日期、需谁协助，不等被问 工单负责人 发现当天，最晚节点前 1 个工作日 研发群+issues 风险字段 风险登记 🔧飞书固化
6 决策：加人/砍范围/延期至下迭代；涉及对外承诺或 P0 的升级研发部门负责人 研发负责人、产品负责人 上报后 4 小时内 飞书群/会议 决策结论 👤人工判断
7 对测试、销售/市场同步最终范围与新日期，测试据此调整冒烟范围 产品负责人 决策当天 飞书群 日期同步公告 🔧飞书固化
8 迭代末按原因分类（需求排太满/估点不准/前松后紧/外部依赖/人手被抽调）汇总延期，复盘会过一遍 研发负责人 迭代结束后 2 个工作日内 多维表格 延期原因统计 🤖+👤

5. 交付物与模板

  • 交付物：每日异常清单、风险盘点表、风险登记、日期同步公告、迭代延期原因统计
  • 建议模板/表单：
    • 风险上报模板：工单链接、负责人、原定日期、预计日期（乐观/平均/悲观）、原因分类、影响（哪些功能/客户承诺/测试窗口）、需要谁协助
    • 完成标准：PR 已合并 + 已部署测试环境 + 已 @测试提测，三项齐全才算“开发完成”
    • 延期原因字段：需求排太满、估点不准、前松后紧、外部依赖、人手被抽调、需求变更、环境阻塞

6. 异常与升级

  • 负责人连续 2 个工作日未更新状态 → 机器人提醒，第 3 天研发负责人点名 → 屡次发生升级研发部门负责人
  • 汇报与事实不符（只发截图、口头说完但未合并）→ 以“完成标准”复核 → 研发负责人当天纠正，屡次发生升级研发部门负责人
  • 节点当天才报延期 → 计入迭代复盘 → 研发负责人
  • 测试窗口被压缩到不足 2 个工作日 → 测试负责人有权要求砍范围或延期 → 升级产品负责人（当天）
  • 运维组插单与现有 P0 冲突 → 需求方说明背景/目标/期限，运维负责人评估排期 → 冲突时升级研发部门负责人（1 个工作日内）

7. 衡量指标

  • 状态更新及时率：当日有更新的进行中工单 / 进行中工单总数，目标 ≥ 95%
  • 超期工单占比：每日超期工单数 / 迭代工单数，目标 ≤ 5%
  • 风险提前量：节点日 − 首次上报日（工作日），目标 ≥ 2 天
  • 节点达成率：按期达成的节点 / 节点总数，目标 ≥ 80%
  • 人工催办次数：群内“进度呢/啥时候能好”类消息数，逐迭代下降

8. 低效诊断

  • 现象：进度靠负责人群内逐个 @追问，“一键查询进度”成为常态，测试找不到可测对象｜依据：「Leap产研测」2026-04、「Leap产研测」2026-05
  • 现象：周五收口需人工拉超期清单逐条点名，存在无人领取的工单｜依据：「Leap产研测」2026-07
  • 现象：冲刺进度只在群里，部署时间口径不一，测试窗口被压缩｜依据：「Leap产研测」2026-08
  • 现象：执行依赖负责人每日盯，状态不更新、站会不汇报｜依据：「鼎慧产研决策部」2026-04
  • 现象：截止日字段无约束，研发不按优先级做单，重难点拖延两个迭代｜依据：「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-08
  • 现象：进度汇报失实、最后一天才暴雷，需求无总负责人｜依据：「鼎慧产研决策部」2026-08
  • 现象：迭代末只完成约四成，延期原因只在群里口头说，没有沉淀｜依据：「工程咨询产研」2026-04
  • 现象：发版时间、范围、部署负责人无人确定，延期当天才报｜依据：「Leap产研决策部」2026-08
  • 现象：预研项目负责人不主动同步、不主动提测｜依据：「LeapVPN网络预研」2026-08
  • 现象：需求上线日期不明，需求方需追问“现在是什么环节”，工作台上线日期缺失｜依据：「跃玩项目组」2026-08、「跃玩remote工作组」2026-07
  • 现象：运维待办表更新不及时，插单无规则｜依据：「忠橙星行星引擎」2026-07
  • 现象：长假前盘点靠每人在群里发一段话，格式不统一｜依据：「跃迁基座」2026-02

9. 分支变体

  • V5 等专项冲刺：以冲刺核心文档列工单卡与关键路径，每日两次同步（上午、傍晚），测试验收日提前锁定
  • 版本发布延期：发版日前 2 个工作日由研发负责人确认范围与部署负责人；客户端、服务端、网关各自节奏，延期需提前报给产品负责人对外同步
  • 跃竞/跃玩：测试负责人归口统一回复“交付/测完/上线”时间，跃竞负责人拍板上线时点；普通迭代周三交付、周四上午测完、周四下午上线；定日需求（如会员活动开启日）单独倒排
  • 运维组：统一使用运维组总表；插单需说明背景/目标/期限并明确优先级
  • 预研项目：一期 PoC 至少每 2 个工作日同步一次；转正式产品后纳入站会演示与倒排里程碑
  • 长假前后：放假前 1 个工作日在多维表格填写“进行中/节后一周计划”

10. 待确认问题

  • 每日异常清单机器人由谁搭建维护？数据源用 issues 系统还是飞书多维表格？
  • “PR 合并 + 部署测试环境 + 主动提测”是否作为全研发统一的完成标准？
  • 风险上报时限“最晚节点前 1 个工作日”是否可行？
  • 是否设专职项目管理岗承担日常跟催？
  • 对外同步上线日期是否统一由产品负责人负责？
  • 跃竞/跃玩是否沿用同一套机制，还是保留独立做法？
RND-09研发站会与例会待优化60

状态：待优化｜证据：有证据（卡片 19 张 / 会话 7 个）｜优先级：频5 × 耗2 × 跨3 × 险2

  • 适用场景：每个工作日固定时间的站会、代码评审（CR）会，以及迭代规划/回顾会、周会、专题评审会，用于同步进度/阻塞/风险并产出纪要与待办
  • 负责人：主责——研发负责人/站会主持（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认，上线冲刺期主持 bug 站会）、全体研发；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 按会议矩阵建周期性固定日程 → ② 会前更新工单状态 → ③ 按模板开会（站会 ≤15 分钟）→ ④ 智能纪要自动生成 → ⑤ 决议/待办转工单 → ⑥ 线下结论同步线上 → ⑦ 纪要归档迭代文档
  • 交付结果：一张会议矩阵（固定日历）、每次会议的纪要、由会议决议生成的工单/待办
  • 状态依据：站会与智能纪要机器人已稳定运行，但召集主要靠群内 @所有人（约 70 次），时间多次漂移（10:30→14:00→17:00），出现重复日程与链接、参会范围争议、决议未落工单，规范未成文

1. 场景判定

  • 触发条件：每个工作日站会；每日或按迭代的 CR；迭代首日规划会、迭代末回顾会；每周周会；上线冲刺期 bug 站会；需要多人对齐的专题评审
  • 典型说法：「两点站会」「把工单状态更新一下，更新完后开站会」「定会议不建日程、不约会议室等于没定」「逢会议必形成纪要」「站会不全员参与有啥用」
  • 判断问题：这是研发/产研团队内部的周期性同步或评审会议吗？是 → 走本流程；一次性客户会议、跨部门商务会 → 不走
  • 不归本流程管：迭代范围与排期内容 → 请走 RND-06；进度跟催与延期决策 → 请走 RND-08；日报/周报 → 请走 RND-10；公司级全员大会等跨部门会议 → 请走 CEO-10（会议召集、会议室预约与纪要归档）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
站会主持 建周期日程、准时开会、控时、确认决议转工单 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准会议矩阵，裁决会议冲突与参会范围 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品负责人 参加规划/回顾/例会，组织产研例会与工程版站会 R/C 产品负责人（当前：杨萌·推断待确认）
测试负责人 冲刺期主持 bug 站会并发编号纪要 R 测试负责人（当前：张东郅·推断待确认）
研发成员 会前更新工单，按模板汇报，缺席时文字同步 R 全体研发（当前：待指定）
代理主持/会议发起人/纪要人 主持人缺席时代为主持；发起人调整日程、同步线下讨论结论；纪要人把决议转工单 R 站会主持指定的研发成员（当前：待指定）
智能纪要助手 自动生成并推送纪要 — 飞书机器人

3. 办之前请准备

  • 会议矩阵：会议名称、频率、时间、时长、必选/可选参会人、议程、产出、主持人与代理人
  • 周期性飞书日程，绑定同一会议链接、会议室与迭代文档
  • 站会工单视图（按人筛选进行中/阻塞）
  • 缺席文字同步模板：昨日完成 / 今日计划 / 阻塞或需协助
  • 专题评审会：会前材料（文档链接）提前 1 个工作日发出

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按会议矩阵建周期日程（站会、CR、规划、回顾、周会），绑定唯一会议链接与会议室，写明必选/可选人 站会主持 每迭代开始前 1 个工作日 飞书日历、会议室预订 周期日程 🔧飞书固化
2 会前更新工单状态；无法参会者在群里按模板文字同步并说明原因 研发成员 会前 15 分钟 issues 工单系统、研发群 最新状态、缺席同步 🔧飞书固化
3 准时开会，按工单视图逐人过“昨日完成/今日计划/阻塞”，每人 ≤1 分钟，阻塞会后单独解决 站会主持 站会 ≤15 分钟 issues 站会视图 阻塞清单 👤人工判断
4 线下开会也开飞书会议录制，生成智能纪要并推送群 站会主持、机器人 会后 30 分钟内 智能纪要助手 会议纪要 🤖自动化
5 决议与待办转工单，指定负责人和截止日 站会主持或纪要人 会后 2 小时内 issues 工单系统 待办工单 🔧+🤖
6 线下临时讨论的结论同步到研发群 讨论发起人 讨论当天 研发群 结论同步消息 👤人工判断
7 纪要归档到迭代文档 机器人、站会主持 当天 迭代文档 归档纪要 🤖自动化
8 主持人缺席由代理人主持；会议冲突由发起人顺延并修改日程，不另建新日程 代理主持、发起人 会前 30 分钟 飞书日历 调整后日程 🔧飞书固化

5. 交付物与模板

  • 交付物：会议矩阵、会议纪要、决议待办工单、群公告中的会议规则
  • 建议模板/表单：
    • 会议矩阵字段：会议名、频率、时间、时长、主持/代理、必选人、可选人、议程模板、产出物、归档位置
    • 站会议程：工单视图过进行中 → 阻塞项 → 风险项 → 当日决议
    • 纪要字段：日期、参会/缺席、决议、待办（负责人/截止日/工单号）、风险
    • 规划/回顾会议程：迭代进度与风险 → 范围调整 → 流程问题 → 下迭代改进项

6. 异常与升级

  • 主持人缺席 → 代理人主持 → 代理人也缺席时站会改为群内文字同步（当天 18:30 前）
  • 出现重复日程/链接 → 以绑定迭代文档的日程为准，发起人删除重复 → 研发负责人当场裁定
  • 到点无人入会超过 5 分钟 → 主持人群内提醒；屡次迟到由研发负责人处理（处罚规则需人事确认）
  • 纪要机器人未产出 → 主持人当天手写简要纪要
  • 会议过多当日无法开站会 → 改文字站会，研发成员 18:30 前按模板同步

7. 衡量指标

  • 站会准时开始率：按日程准时开始的站会 / 站会总数，目标 ≥ 90%
  • 站会时长：中位数 ≤ 15 分钟
  • 纪要归档率：有纪要的会议 / 会议总数，目标 ≥ 95%
  • 决议转工单率：有对应工单的决议 / 决议总数，目标 100%
  • 手动 @所有人召集次数：目标每周 ≤ 1 次

8. 低效诊断

  • 现象：召集靠群内 @所有人喊人，时间随临时通知漂移，未做周期日程｜依据：「研发通知」2026-05、「研发通知」2026-07
  • 现象：同一会议出现两个日程、两个链接，参会人不知进哪个｜依据：「研发通知」2026-07
  • 现象：站会演变为当面念文档，形式与参与范围争议｜依据：「鼎慧产研决策部」2026-03
  • 现象：会议默认全群参加，缺必选/可选区分｜依据：「Leap产研测」2026-06
  • 现象：有智能纪要但会上决议未落工单；AI 建日程时间出错｜依据：「Leap产研测」2026-05
  • 现象：日报需人工汇总站会与群消息，格式不统一｜依据：「Leap产研测」2026-07
  • 现象：线下讨论结论未同步线上｜依据：「Leap产研测」2026-09
  • 现象：上线冲刺期 bug 未选迭代，站会未发现｜依据：「Leap产研决策部」2026-09
  • 现象：工程版站会临时通知，结论只在群消息｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：会前需人工点对勾确认工单，会议时间多次改动｜依据：「工程咨询产研」2026-01、「工程咨询产研」2026-02
  • 现象：会议规范未成文，谁记纪要、谁审不明｜依据：「鼎慧人事」2026-02

9. 分支变体

  • Leap 主线：每日站会 + CR；冲刺期可加开晚间进度同步会，每天最多两次
  • 上线冲刺期：测试负责人主持 bug 站会，会后发编号纪要（上线阻塞项、各线负责人、剩余 bug 与待验收数、上线高风险清单），产品负责人据此决定是否上线或砍功能
  • 字字可研/工程版：产品负责人召集，列编号待办并指定对接人，研发排期表由产品经理维护
  • 专题评审会（架构演进、badcase 归因、版本管理方案）：会前发材料，开场先读文档 10 分钟
  • 远程/居家期：线上站会，是否开摄像头待确认
  • 研发以站会+工单状态替代个人日报；非研发团队用飞书汇报

10. 待确认问题

  • 站会固定时间定为上午 10:30 还是下午 14:00？各产品线是否统一？
  • CR 会每日开还是按需开？是否与站会合并？
  • 产品、测试是否为站会必选参会人？
  • 迟到处罚是否成文？需人事确认是否合规
  • 站会/CR 纪要是否在迭代末汇总给人事作为绩效参考？
  • 周会与公司全员大会的边界和主持人？
RND-10研发日报/周报与进展同步待优化60

状态：待优化｜证据：有证据（卡片 16 张 / 会话 6 个）｜优先级：频5 × 耗2 × 跨3 × 险2

  • 适用场景：每个工作日下班前与每周五，研发/项目组提交日报与周报，汇总成管理层可读的进展、风险与下周计划；跨团队、子公司或借调人员对外同步进展
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认，产研周报与对上汇报）、全体研发、日报机器人维护人（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 下班前更新工单状态 → ② 需补充者按四要素填日报 → ③ 机器人 20:00 汇总推送日报 → ④ 缺报/不合格自动 @补充 → ⑤ 周五研发负责人审定研发周报 → ⑥ 产品负责人合成产研周报与对上汇报版 → ⑦ 归档固定入口
  • 交付结果：每日产研日报、每周产研周报（本周进展/风险/下周重点/点数完成情况）、对上汇报版本、跨团队进展同步记录
  • 状态依据：机器人日报、项目组《日报填写规范（试行）》、仓库贡献日报已在运行，但日报格式/受众/发送渠道反复调整，需人工点名催报，周报入口难找，机器人故障时无人兜底，变更与进展常走私聊

1. 场景判定

  • 触发条件：每个工作日下班前；每周五；管理层需要对上汇报；子公司/借调研发的成果需要同步；研发修改需求或线上逻辑需要告知相关方
  • 典型说法：「日报之后统一发在这个群」「总结成向上汇报的日报，不要出现技术语言」「周报在哪」「要改啥和改了啥要在群里同步，不要纯私聊」「日报普遍只写动作、不写结果」
  • 判断问题：这条信息是否需要让不在场的人（管理层、产品、测试、协作团队）看懂并据此决策？是 → 走本流程
  • 不归本流程管：站会组织与纪要 → 请走 RND-09；进度异常与延期决策 → 请走 RND-08；工单字段与状态规范 → 请走 RND-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 审定研发日报口径、撰写研发周报 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准日报/周报规范，接收周报 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品负责人 合成产研周报、生成对上汇报版 R 产品负责人（当前：杨萌·推断待确认）
研发成员 更新工单、按四要素补充日报 R 全体研发（当前：待指定）
机器人维护人 维护日报/周报机器人、故障兜底 R 研发工程师（当前：待指定）
跨团队/子公司/借调对应负责人 在既有项目群同步进展，影响他人的变更当天同步 R 对应项目或借调负责人（当前：待指定）
管理层 阅读周报与对上汇报 I CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 工单系统与代码仓库已对机器人开放读取权限
  • 日报模板（四要素）与周报模板（按功能模块）已置顶
  • 固定发送群与周报归档入口（wiki 链接）已公告
  • 对上汇报版改写规则：去技术语言、不出现内部 IP 与编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 更新当日工单状态，工单作为日报主数据源 研发成员 每日 18:30 前 issues 工单系统 最新工单状态 🔧飞书固化
2 工单无法体现的工作按四要素补充：做了什么/结果/进度%/阻塞或需协调；测试写四选一结论 研发成员 当日 22:00 前，不隔天补报 飞书多维表格表单 个人日报 🔧飞书固化
3 机器人拉取工单变更、PR/提交、会议纪要，生成日报推送固定群 机器人 每日 20:00 飞书机器人 产研日报 🤖自动化
4 机器人校验缺报与“优化/推进/调整”等单独出现的模糊词，@本人补充 机器人 次日 10:00 前 飞书机器人 待补充清单 🤖自动化
5 机器人生成周报草稿，研发负责人审改：按功能模块写完成/未完成、点数、风险、下周计划 研发负责人 每周五 15:00 前 机器人+飞书 wiki 研发周报 🤖+👤
6 合成产研周报（本周进展/主要风险/下周重点），另出去技术语言的对上汇报版 产品负责人 每周五 18:00 前 飞书 wiki 产研周报、对上汇报版 🤖+👤
7 周报归档到固定 wiki 入口并在群公告置顶链接，不走私聊 产品负责人 周五当天 飞书 wiki、群公告 归档周报 🔧飞书固化
8 跨团队/子公司/借调进展在既有项目群同步；影响他人的变更当天同步相关负责人 对应负责人 每周至少 1 次；变更当天 项目群 进展同步消息 👤人工判断

5. 交付物与模板

  • 交付物：每日产研日报、研发周报、产研周报、对上汇报版、跨团队进展同步记录
  • 建议模板/表单：
    • 日报字段：日期、署名、做了什么、结果/结论、进度%、阻塞/需协调（写明对象）、关联工单号；测试另加结论（全部通过/有条件通过/阻塞/未完成）
    • 周报字段：周期、按功能模块的已完成/未完成（含点数）、版本发布情况、主要风险（影响-原因-需谁协助）、下周重点
    • 对外/跨团队进展页：已经做了 / 正在做 / 将要做 三栏

6. 异常与升级

  • 日报机器人故障 → 维护人 2 小时内修复；当天由研发负责人用工单视图手工出简版 → 超过 1 个工作日未恢复升级研发部门负责人
  • 同一成员连续 2 个工作日缺报 → 研发负责人提醒 → 屡次发生纳入考核沟通
  • 日报中出现风险/阻塞 → 转 RND-08 风险上报 → 研发负责人当天处理
  • 外部群机器人无法推送 → 将机器人拉入群，未拉入前由汇总方当天人工转发
  • 进展或变更只在私聊 → 要求当天补发项目群并 @相关负责人

7. 衡量指标

  • 日报准时率：22:00 前提交的日报 / 应提交数，目标 ≥ 95%
  • 日报合格率：四要素齐全的日报 / 提交日报数，目标 ≥ 90%
  • 周报准时率：周五 18:00 前归档的周报 / 周数，目标 100%
  • 周报人工汇总耗时：目标 ≤ 30 分钟/周
  • 管理层追问进度次数：逐月下降

8. 低效诊断

  • 现象：机器人日报格式、受众、发送渠道（私聊/群）反复调整，机器人故障时无人兜底｜依据：「鼎慧产研决策部」2026-07
  • 现象：机器人日报分条乱序、需重新输出，反复调排版｜依据：「Leap产研测」2026-07
  • 现象：周报入口难找、内容过少、缺点数｜依据：「鼎慧产研决策部」2026-06
  • 现象：周会表格靠提醒填写，产品与研发内容重复｜依据：「鼎慧产研决策部」2026-03
  • 现象：迭代完成事项清单反复修改三轮才成型，缺固定格式｜依据：「鼎慧产研决策部」2026-03
  • 现象：问题“爆了才说”，产品只能看群消息猜进度｜依据：「鼎慧产研决策部」2026-07
  • 现象：日报格式颗粒度不一、日期写错、隔天补报，漏报靠点名｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-08
  • 现象：日报、工单状态、周报三处重复填报，群定位反复｜依据：「研发通知」2026-07
  • 现象：周报靠人工触发 AI 汇总，无固定时间｜依据：「Leap产研决策部」2026-09

9. 分支变体

  • Leap 主线：以工单状态为准，个人日报可选；研发周报由研发负责人统一写，按功能模块不按人
  • 跃竞/跃玩项目组：执行《日报填写规范》（四要素、测试四选一结论、22:00 前提交、署名、禁用模糊词），机器人每日 20:00～22:00 汇总并对不合格项 @补充；外部群需人工转发
  • 仓库贡献日报：机器人每日 9:00 推送前一日仓库活动并生成文档；无活动日建议合并入周报，授权过期自动续期
  • FDE/内部系统开发：自维护飞书进度文档（已做/正在做/将要做），发 FDE 群
  • 子公司/借调研发：在既有项目群每周同步商业化与技术进展
  • 对上汇报版：去技术语言、不暴露内部 IP/编号，由产品负责人出

10. 待确认问题

  • 研发是否取消个人日报，统一以工单状态+站会替代？
  • 跃竞/跃玩的《日报填写规范》是否上升为集团通用规范？
  • 日报/周报机器人由谁维护？故障兜底人是谁？
  • 周报是否需包含个人表现（performance）？接收人是研发部门负责人还是 CEO？
  • 子公司/借调研发的同步频率（每周一次）是否合适？
  • 日报统一发哪个群？研发通知群是否允许汇报类消息？
RND-11工单状态维护与工单系统规范待优化90

状态：待优化｜证据：有证据（卡片 9 张 / 会话 5 个）｜优先级：频5 × 耗2 × 跨3 × 险3

  • 适用场景：任务、bug、需求进入工单系统流转后，按统一口径及时更新状态、负责人、迭代与标签，并通过自动通知、巡检与统计保证数据可信
  • 负责人：主责——研发负责人/工单系统管理员（当前：王皓南·推断待确认）；协同——产品经理（当前：杨萌·推断待确认，负责产品验收状态）、测试负责人（当前：张东郅·推断待确认，负责 bug 状态与统计）、代码仓库管理员（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 确定唯一数据源与状态口径 → ② 建单填必填字段 → ③ 按状态机流转（待办→进行中→待测→测试中→待验收→完成/打回）→ ④ 状态变更自动通知 → ⑤ 每日机器人巡检违规与滞留 → ⑥ 每周自动统计点数与 bug → ⑦ 按季度修订规范
  • 交付结果：成文《工单规范》（状态定义、必填字段、流转规则、通知规则、统计口径）、每日巡检清单、每周统计报表
  • 状态依据：研发任务年初决定统一到代码仓库 issue，年中迁至自建 issues 工单系统，但产品工作台、飞书文档、工单三处并存；测试打回无通知、点数需导出手工统计、bug 未选迭代、跳过产品验收直接关闭等问题反复出现

1. 场景判定

  • 触发条件：新建任务/bug/需求工单；工单状态变化；测试打回；产品验收；迭代统计；工具或规范变更
  • 典型说法：「技术讨论、设计、任务追踪都放工单系统」「我只要一个唯一数据源」「工单本来就难用」「提了一堆 bug 都没选迭代」「过期的 issue 没有提醒」
  • 判断问题：这个状态或字段的变化会影响别人（测试、产品、统计、对外承诺）吗？会 → 必须按本规范操作
  • 不归本流程管：迭代范围规划 → 请走 RND-06；负责人归属裁定 → 请走 RND-07；进度跟催与延期 → 请走 RND-08；需求是否立项 → 请走 X-PRD-09（需求提报登记与需求池管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
工单系统管理员 维护状态机、必填字段、通知与巡检规则、统计报表 R 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准工单规范与工具选型 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品经理 维护需求与工单关联，执行“待验收→完成”或打回 R 产品经理（当前：杨萌·推断待确认）
测试负责人 维护 bug 状态口径与统计，执行“测试中→待验收/打回” R 测试负责人（当前：张东郅·推断待确认）
代码仓库管理员 账号开通、仓库与通知配置 C 后端/运维（当前：宋祺睿·推断待确认）
研发成员/建单人/工单负责人 按规范建单、更新状态，当日纠正巡检出的违规流转 R 全体研发（当前：待指定）

3. 办之前请准备

  • 唯一工单系统账号与项目权限（研发、测试、产品）
  • 《工单规范》链接（状态定义、必填字段、标签表）
  • 当前迭代 cycle/milestone
  • 需求池中对应需求ID（需求类工单）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定唯一工单系统与仓库归属，发布状态机、必填字段、标签表；产品需求池单向同步为工单 工单系统管理员 规范变更后 1 个工作日内公告 issues 工单系统、飞书文档 《工单规范》 🔧飞书固化
2 建单：标题、类型（需求/任务/bug）、关联需求ID、验收标准、负责人、迭代、优先级、点数（任务）或严重级别（bug）必填 建单人 发现问题后 2 小时内 issues 工单系统 合规工单 🔧+🤖
3 按状态机流转：开工改“进行中”，合并部署测试环境后改“待测”，测试通过改“待验收”，产品验收后才可“完成”；打回必须写原因 研发、测试、产品 状态变化当时 issues 工单系统 状态记录 🔧飞书固化
4 状态变更、指派、打回、到期前 1 天自动通知负责人与相关人到飞书 机器人 实时 issues+飞书机器人 通知消息 🤖自动化
5 每日巡检：无迭代、无负责人、跳过验收直接关闭、超 3 天未更新、已过截止日的工单，推送清单 机器人 每工作日 9:30 issues+飞书机器人 巡检清单 🤖自动化
6 违规流转纠正：被巡检出的工单由负责人当日恢复到正确状态并补齐字段 工单负责人 收到清单当天 issues 工单系统 修正记录 👤人工判断
7 每周自动统计：迭代点数完成/未完成、bug 新增/修复/剩余、打回次数，生成报表 机器人、工单系统管理员 每周五 12:00 前 issues 统计视图 周统计报表 🤖自动化
8 每季度收集工具与规范问题，修订规范并公告 工单系统管理员 每季度末 飞书文档 规范修订版 👤人工判断

5. 交付物与模板

  • 交付物：《工单规范》、标签表、每日巡检清单、每周统计报表、规范修订记录
  • 建议模板/表单：
    • 状态定义：待办（已排入迭代未开工）/进行中/待测（已合并并部署测试环境）/测试中/待验收（测试通过）/完成（产品验收通过）/打回（附原因）/取消（附原因）
    • 必填字段：标题、类型、关联需求ID、验收标准、负责人、迭代、优先级、点数或严重级别、截止日
    • bug 额外字段：复现步骤、环境、版本号、严重级别、发现人
    • 统计口径：点数按“完成”状态计；bug 剩余数 = 非完成且非取消的 bug

6. 异常与升级

  • 工单跳过测试或产品验收直接关闭 → 巡检发现后当天恢复状态 → 同一人一个迭代内 2 次以上升级研发负责人
  • 测试打回无人响应超过 1 个工作日 → 机器人再次提醒 → 升级研发负责人
  • 工单系统故障或数据丢失 → 管理员 2 小时内恢复或启用备份 → 升级研发部门负责人
  • 需求池与工单状态冲突（两人同时修改同一批工单）→ 以工单系统为准，需求池只读同步 → 工单系统管理员当天处理
  • 工具选型变更（如更换工单系统）→ 管理员出对比方案 → 研发部门负责人批准后迁移

7. 衡量指标

  • 字段完整率：必填字段齐全的工单 / 工单总数，目标 ≥ 98%
  • 违规流转数：跳过验收直接关闭的工单数，目标每迭代 0
  • 状态滞后率：实际已完成但状态未更新的工单占比（抽查），目标 ≤ 5%
  • 打回响应时长：打回到负责人响应的工作时长，目标 ≤ 1 个工作日
  • 统计人工耗时：每周点数/bug 统计人工耗时，目标 0（全自动）

8. 低效诊断

  • 现象：工单系统、产品工作台、飞书文档三处并存，需“又看文档又看 issue”；工单内容不全没人指出｜依据：「鼎慧产研决策部」2026-01
  • 现象：工单拆在多个仓库，项目看板需手动加 issue，里程碑难找｜依据：「鼎慧产研决策部」2026-01
  • 现象：测试打回无提醒，点数统计需导出手工算，工具难用｜依据：「鼎慧产研决策部」2026-07
  • 现象：截止日字段到期无提醒、无法按过期筛选｜依据：「Leap产研测」2026-07
  • 现象：大量 bug 提交时未选迭代，站会才发现｜依据：「Leap产研决策部」2026-09
  • 现象：工单跳过产品验收直接关闭，状态口径不一｜依据：「Leap产研决策部」2026-08
  • 现象：迭代日期不能自定义、未完成工单自动搬迁造成范围混乱｜依据：「Leap产研测」2026-10、「Leap产研决策部」2026-08
  • 现象：工单发布后群里无通知，需求池与工单被两人同时修改互相覆盖｜依据：「Leap产研决策部」2026-09

9. 分支变体

  • Leap 主线：自建 issues 工单系统（cycle 制）为唯一数据源
  • 字字可研/工程版：issue 必须引用产品需求，里程碑=迭代；产品仍维护需求池多维表格，需单向同步
  • 教育组等已用代码仓库工单统一产研测的团队：可保留，但字段与状态口径按本规范对齐
  • 委派提醒：飞书机器人对新指派、即将到期工单私信提醒负责人
  • 产品/市场/运营：不直接在工单系统操作，通过需求池提交

10. 待确认问题

  • 唯一工单系统是否最终确定为自建 issues 系统？代码仓库 issue 是否停用？
  • 状态机中“待验收→完成”是否必须由产品经理操作？无产品对应的技术任务由谁验收？
  • 产品需求池与工单系统采用单向同步还是双向同步？谁开发维护同步机器人？
  • 必填字段清单是否过多？点数是否对 bug 也要求？
  • 工单规范是否需要在新人入职时培训并签收？
  • 是否已有成文的工单规范文档可直接替换本 SOP 内容？
RND-12研发绩效、点数考核与事故追责待优化108

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：每个迭代结束要核算研发点数和质量指标；或版本上线后出现 bug、数据事故、验收不通过，需要评级、认定责任并按规则扣点时启动
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监/点数统计人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 开工前全量估点 → ② bug 入库定级并标来源 → ③ 迭代结束自动出点数与质量报表 → ④ 事故评级与责任认定 → ⑤ 扣点/回扣核算 → ⑥ 公示与异议 → ⑦ 季度汇总交人事与积分
  • 交付结果：每迭代一份《研发点数与质量报表》（个人点数、bug 回扣、阻塞率、返工率）；事故/缺陷责任认定记录；公示后的点数结果；季度研发评价表
  • 状态依据：已有 Gitea 工单点数标签、迭代点数图和测试日报，点数每个迭代都在算；但 2026-07～08 群里围绕“bug 扣不扣点、事故算不算点数、点数能不能刷、测试担不担责”争议多次，单次讨论约 15 条消息；P1 及以上修不完双倍扣点等规则先口头定再补通知，至今没有成文的《事故/缺陷分级与扣点规则》

1. 场景判定

  • 触发条件：迭代结束核算点数；上线后发现 bug 或数据事故；验收不通过；管理层质疑研发或测试效率；三个月一次的总评
  • 典型说法：「没估点我怎么统计工作量」「p1及以上修不完双倍扣点数」「事故是事故，点数是点数」「会给每个bug评级，对涉事人员进行绩效考核」「阻塞率高说明测试效率低 返工率高说明测试质量差」「修Bug也需要定义一下点数」
  • 判断问题：要回答的是“这个迭代谁做了多少、质量怎样、出了问题算谁的”吗？如果只是报 bug、定修复优先级，就不归本流程
  • 不归本流程管：bug 提报、复现、分级与指派 → 请走 RND-03；迭代排期与估点会 → 请走 RND-06；点数换算积分、奖金、期权与发放 → 请走 HR-18；绩效结果用于调薪、转正 → 请走 HR-19；个人行为问题访谈与处置 → 请走 HR-20；故障应急与技术复盘 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
估点与点数分配 给功能和 bug 工单估点，组织事故评级会，日常点数与责任认定拍板 A Leap 研发负责人（当前：王皓南·推断待确认）
点数统计 迭代结束出报表、公示、收异议 R 产品总监/点数统计人（当前：杨萌·推断待确认）
测试质量数据 提供 bug 来源、阻塞率、返工率，参与责任认定 R/C 测试负责人（当前：张东郅·推断待确认）
跃竞线评级 组织上线 bug 评级；提供测试侧意见 R/C 跃竞产品经理（当前：陈雁·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）
主观评分 按 SSR/SR/R 从技术、产品、经营三个角度打分 R 评分小组：COO（当前：常元和·推断待确认）、产品总监、Leap 研发负责人
积分整合 把研发口径合并进公司积分体系 C 综合部负责人（当前：赵雪冰·推断待确认）
价值度量设计 设计 DRV 等任务价值指标与日报 C 研发（当前：李铭熙·推断待确认）
被考核研发 核对个人点数，提异议 C/I 各研发工程师（当前：待指定）
人事 接收季度结果用于绩效 I 人事负责人（当前：黄莹·推断待确认）
终裁 规则变更拍板；评级会后仍有分歧的争议裁决 A（升级） 研发负责人（创始人兼 CTO，当前：丁震宇）

3. 办之前请准备

  • 本迭代工单清单：估点、委派人、状态、验收结果
  • bug 列表：等级、来源功能、引入 PR、功能负责人、修复人、是否超期
  • 当前生效的《点数与扣点规则》版本号
  • 测试日报里的阻塞次数、打回返工次数
  • 事故材料：影响范围、发现时间、关联提交、是否同类错误重复出现（第几次）
  • 注意：个人评价只在评审小范围讨论，大群只公示数据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 迭代内全部功能工单和 bug 工单估点；未估点的 bug 不得关单 Leap 研发负责人 迭代开工后 1 个工作日内；新 bug 入库当天 Gitea 工单点数标签 带点数的工单 🔧+👤
2 bug 入库时填等级、来源功能、引入 PR、修复人；AI 根据提交记录推荐引入 PR 测试 提 bug 当天 Gitea 工单字段 可归因的 bug 记录 🤖+👤
3 P1 及以上 bug 按修复时限跟踪，超期自动标红并提醒 机器人 实时 Gitea + 飞书机器人 超期清单 🤖自动化
4 迭代结束自动生成报表：个人完成点数、bug 回扣、验收打回、阻塞率、返工率 点数统计人 迭代结束后 1 个工作日内 脚本 + 多维表格 点数与质量报表 🤖自动化
5 召开事故评级会：对 P1 及以上 bug 和数据事故逐条评级，认定责任方（开发/测试/产品），判断是否属“反复”（同类错误 2 次及以上） Leap 研发负责人召集，测试负责人、产品参加 迭代结束后 2 个工作日内；数据事故发生后 2 个工作日内 飞书会议 + 责任认定表 责任认定记录 👤人工判断
6 按规则核算扣点与回扣（如 bug 点数从引入人回扣给修复人、P1 及以上超期加倍、验收不通过不计点），写入报表 点数统计人 评级会后 1 个工作日内 多维表格公式 核算后点数 🔧+🤖
7 在研发群公示报表（只公示数据，不附个人评价），异议窗口 2 个工作日 点数统计人 核算完成当天 飞书群 + 多维表格 公示记录 🔧飞书固化
8 处理异议，必要时调整并记录理由 Leap 研发负责人；争议升级研发负责人 异议截止后 2 个工作日内 多维表格 最终点数 👤人工判断
9 每 3 个月汇总点数、质量指标和主观评分，交人事和积分体系 点数统计人、综合部负责人 季度结束后 5 个工作日内 多维表格 季度研发评价表 🔧+👤

5. 交付物与模板

  • 交付物：迭代点数与质量报表、责任认定记录、公示记录、季度研发评价表
  • 建议模板/表单：
    • 多维表格「研发点数与质量台账」：迭代、工单号、类型（功能/bug）、估点人、点数、负责人、验收结果、bug 等级、引入 PR、修复人、是否超期、回扣点数、最终点数
    • 《事故/缺陷分级与扣点规则》：缺陷、事故、验收失败、“反复”的定义；等级与修复时限；扣点系数；测试漏测是否连带；点数由人估还是 AI 辅助；规则版本与生效迭代
    • 责任认定表：事故编号、等级、现象、影响范围、根因、责任方、是否反复、处理意见、认定人、日期
    • DRV 日报（探索中）：任务、项目、产出，结构化可在后台显示；暂不计算数值

6. 异常与升级

  • 工单没估点 → 统计人退回估点人，1 个工作日内补；仍缺按 0 点计并报 Leap 研发负责人
  • bug 归属有争议（引入人、修复人、测试漏测）→ 评级会裁定；仍有分歧 2 个工作日内升级研发负责人
  • 同类错误第 2 次出现 → 打“反复”标签，由 Leap 研发负责人和研发负责人人工决定是否转 HR-20；不在大群讨论个人
  • P1 及以上 bug 超期 24 小时 → 升级 Leap 研发负责人，决定加人或调整排期
  • 怀疑通过拆单抬高点数 → 估点人复核，复核结果记入台账
  • 测试阻塞率或返工率连续 2 个迭代超出目标 → 测试负责人 3 个工作日内交改进计划，抄送研发负责人
  • 升级拍板（A（升级））：《点数与扣点规则》新增或修改，或评级会裁定后 2 个工作日内仍有分歧 → 由研发负责人（CTO）终裁，结论写入规则版本或责任认定记录

7. 衡量指标

  • 估点覆盖率 = 已估点工单 / 本迭代全部工单（含 bug），目标 100%
  • 报表时效 = 迭代结束到报表公示的工作日，目标 ≤ 2 天
  • P1 及以上缺陷按时修复率，目标 ≥ 90%
  • 测试阻塞率 = 被阻塞的测试工单 / 测试工单总数（目标值待定）
  • 返工率 = 验收打回重开的工单 / 已提测工单，目标 ≤ 15%
  • 事故重复率 = 同类事故第 2 次及以上的占比，目标逐季下降
  • 异议率 = 提异议人次 / 被考核人次，目标逐季下降

8. 低效诊断

  • 现象：扣点规则先在群里口头定，再补站会通知和文字留痕，规则没有版本｜依据：「鼎慧产研决策部」2026-07
  • 现象：事故、bug、能力问题定义不清，出错多的人点数反而高，出事故不扣点，激励方向反了｜依据：「鼎慧产研决策部」2026-07
  • 现象：点数能否刷分、是否公平反复争论，评价机制公信力不足｜依据：「鼎慧产研决策部」2026-07
  • 现象：bug 不估点、委派不能多人，统计工作量要靠爬仓库，再要求个人“做出说明”｜依据：「Leap产研测」2026-08
  • 现象：上线 bug 称“按规定评级”，但评级标准没有文档，测试担不担责靠当场商量｜依据：「跃玩remote工作组」2026-06
  • 现象：测试阻塞率、返工率是否已有统计，管理侧和测试侧说法不一｜依据：「测试提效评估」2026-07
  • 现象：研发评价口径（工作量下限、主观评分）要并入公司积分，绩效系统由谁写 PRD 不清｜依据：「董事会专项沟通群」2026-08

9. 分支变体

  • Leap/鼎慧产研：工单点数 + bug 回扣 + 事故评级；约定从某个版本起单独出绩效评估（起始版本待确认）
  • 跃竞/跃玩：上线后 bug 由产品经理组织评级，上线前产生的 bug 在需求评审会评估；测试是否担责待定
  • 测试岗：看阻塞率、返工率和工作量/质量评估，与 AI 补贴、季度结算挂钩
  • 产品岗：看原型与文档质量（规则待定）
  • 评分粒度：技术分按研发个人，产品分按功能负责人；主观评分 SSR/SR/R
  • 问题类型：验收不通过（不计点）、过验收后出 bug（回扣）、数据事故（评级 + 追责）分别处理

10. 待确认问题

  • 主责是 Leap 研发负责人还是产品总监？跃竞线是否用同一套规则？
  • bug 点数是否从“引入人回扣给修复人”？bug 默认由功能负责人修吗？
  • P1 及以上超期双倍扣点、“整周不计点”等规则是否保留？是否已经人事和法务确认合规？
  • “反复”定义为同类错误 2 次及以上是否认可？后果是什么？
  • 测试漏测是否连带扣点？比例多少？
  • 点数由人估还是 AI 辅助估？是否允许、鼓励“刷分”？
  • 阻塞率、返工率的目标值是多少？是否与 AI 补贴挂钩？
  • 主观评分小组成员和权重是否固定？三个月总评从哪个季度开始？
  • 研发绩效系统作为工单系统的一个模块，PRD 由谁写？
RND-13开工前方案设计与前置过审待新建144

状态：待新建｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：研发拿到新功能、较大改动，或涉及 LeapCore 平台能力、账号/权限、计费、网关等基础设施的需求，在写代码前先写方案并经负责人过审时启动
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、跃竞后端权限负责人（当前：张楠·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、任务负责研发（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 确认需求已定 → ② 判定方案等级 → ③ 写 issue 方案/设计文档 → ④ 不确定点跑 PoC → ⑤ 过审 → ⑥ 定稿后估点开工 → ⑦ 偏离方案先更新再改
  • 交付结果：挂在 Gitea issue 上的已过审技术方案（轻量为 issue 内方案，重量为设计文档加评审记录），PR 关联方案链接
  • 状态依据：2026-01 起多次提出“先设计再开发”，2026-07 又提出“干活前想清楚为什么”“LeapCore 相关先过一遍”，但只有口头规则和 /grill-me 推荐，没有模板和必经节点；2026-06～10 仍出现网关拦截被要求删除、全量埋点被否、数千行 PR 在评审时才发现应改在认证服务等返工；基座组有设计文档批注定稿的习惯，但没有评审时限

1. 场景判定

  • 触发条件：拿到新功能或新组件；预计工作量 ≥ 1 人日或改动跨 2 个以上模块；涉及 LeapCore 平台能力、账号/权限/鉴权、计费、数据结构、网关、观测等基础设施；准备让 AI 一次性生成大段代码
  • 典型说法：「干活前一定想清楚为什么干」「拿到一个任务，就直接开始做，没有设计没有方案」「至少得写个issue几句话说说」「以后所有 leapcore 相关的…都找我过一遍」「开了 5000 行的 pr 已经太晚了」「有什么想改的和建议在文档里评论一下就行」
  • 判断问题：写代码前，我能不能用几句话说清“为什么做、做成什么样、边界在哪、改哪些模块”？说不清，或者会动到别人的模块，就先走本流程
  • 不归本流程管：需求本身还没定 → 请走 RND-04；多个方案有分歧要拍板或赛马 → 请走 RND-14；评估引入开源/第三方能力 → 请走 RND-15；开工后要重构或删改既有功能 → 请走 RND-17；跨组接口契约 → 请走 RND-18；写完代码的 PR 评审 → 请走 RND-32；Agent 运行时安全与权限 → 请走 RND-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
方案作者 澄清需求、写方案、跑 PoC、按意见修改 R 任务负责研发（当前：待指定）
方案过审人 确认等级、审方案、决定能否开工 A Leap 研发负责人（当前：王皓南·推断待确认）
基座组设计评审 批注设计文档，组织定稿 R 基座组架构负责人（当前：陈晖·推断待确认）
产品 确认需求目标和验收标准，不确定的需求不下发 C 产品总监（当前：杨萌·推断待确认）
受影响模块负责人 确认改动对本模块的影响 C 模块负责人（当前：待指定）
权限类评审 审权限矩阵，提前写越权用例 C 跃竞后端权限负责人（当前：张楠·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）
终审 L3 方案与跨线方案终审，裁定边界 A（升级） 研发负责人（创始人兼 CTO，当前：丁震宇）

3. 办之前请准备

  • 需求单链接：产品已确认的目的、期望效果、边界条件、验收标准
  • 相关模块现状：代码入口、已有接口和表、依赖服务
  • 用 /grill-me 或 AI 先把需求问一遍，记下澄清结论
  • 方案草稿可以让 AI 起草，但作者必须读懂并删掉过度设计
  • 权限类：现有权限矩阵（角色 × 操作 × 数据范围）
  • 预估工作量和预计 PR 行数

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认需求已定，目的、效果、边界、验收齐全；不确定的退回产品 方案作者 领任务当天 Gitea issue 澄清记录 👤人工判断
2 判定等级：L1 小改（< 1 人日、单模块），issue 写 3 句话即可；L2（≥ 1 人日、跨模块或预计 PR > 500 行），写 issue 方案并过审；L3（LeapCore 平台能力、权限、计费、新组件、跨线），写设计文档并评审 方案作者自评，过审人确认 领任务后 0.5 个工作日内 issue 标签 等级标签 🔧+👤
3 按模板写方案：目的、方案、改动范围、不做什么、风险与回滚、估点；权限类附权限矩阵变更 方案作者 L2 1 个工作日内；L3 2 个工作日内 Gitea issue 模板 / 飞书 wiki 设计文档模板 方案 🔧+🤖
4 不确定的技术点先做 PoC，在站会或评审会演示 方案作者 方案提交后 2 个工作日内 本地/测试环境 PoC 结论 👤人工判断
5 @过审人和受影响模块负责人评审，意见写在 issue 或文档评论里 过审人 L2 收到后 1 个工作日内；L3 2 个工作日内 Gitea 评论 / 飞书文档评论 + 飞书任务截止时间 评审意见 🔧飞书固化
6 给出结论：通过 / 修改后通过 / 驳回；L3 由过审人宣布定稿并分工 过审人 评审结束当天 issue 状态“方案已过审” 定稿方案 👤人工判断
7 估点排入迭代，PR 描述必须链接方案 issue 方案作者 定稿后 Gitea 关联 PR 🔧+👤
8 实现中要偏离方案（换选型、多改模块、加需求外功能），先在 issue 更新方案并 @过审人确认 方案作者 发现当天 Gitea 评论 方案变更记录 👤人工判断

5. 交付物与模板

  • 交付物：已过审的 issue 方案或设计文档、评审记录、PR 与方案的关联
  • 建议模板/表单：
    • L2 issue 方案模板：目的/期望效果、方案（3～10 句）、改动范围（模块/接口/表）、不做什么、风险与回滚、估点、验收标准
    • L3 设计文档模板：需求与目标、依赖、架构图、接口与数据结构、权限与安全、风险、里程碑、评审记录表（评审人、意见、处理、结论、日期）
    • 权限矩阵：角色 × 菜单/接口 × 数据范围 × 是否可配置，同时作为越权测试用例来源
    • issue 标签：方案等级 L1/L2/L3；方案状态（待写/待过审/已过审/驳回）

6. 异常与升级

  • 过审人超时未回复 → 机器人在 L2 超 1 个工作日时提醒；超 2 个工作日升级研发负责人
  • 没过审就开工，或 PR 超 500 行且没有方案链接 → PR 评审人直接退回补方案
  • 方案涉及其他管理线的系统（如开放平台、渠道系统与 LeapCore 交互）→ 只对齐“读写哪些数据、和哪些系统交互、负责人是谁”三项，研发负责人 2 个工作日内定边界
  • 评审意见分歧收不拢 → 转 RND-14
  • 需求方要求跳过方案赶工 → 过审人可批准“先做后补”，3 个工作日内必须补方案
  • 权限类方案上线前测出越权 → 阻断上线，按 RND-44 修复
  • 升级拍板（A（升级））：L3 方案、跨产品线/跨管理线方案，或过审人与作者、模块负责人意见不一致且 2 个工作日内收不拢 → 由研发负责人（CTO）终审并裁定边界

7. 衡量指标

  • 方案覆盖率 = 开工前已过审的 L2/L3 工单 / 全部 L2/L3 工单，目标 ≥ 90%
  • 评审周期 = 方案提交到结论的工作日，L2 ≤ 1 天、L3 ≤ 3 天
  • 方案类返工 = 因方案不当被要求删除或重写的 PR 数，目标逐月下降
  • 无方案大 PR 数 = 超 500 行且无方案链接的 PR 数，目标 0
  • 设计文档评审催办次数，目标每份 ≤ 1 次

8. 低效诊断

  • 现象：需求下发后边开发边出方案，方案反复变、工期定不下来；demo 做完直接上线，bug 集中｜依据：「鼎慧产研决策部」2026-01
  • 现象：开发按自己的理解直接实现（网关加拦截、观测工具全量采集），事后被要求删除；同一配置含义理解不同｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：AI 一次生成数千行 PR，评审时才发现应改在认证服务，又多轮争论方案｜依据：「Leap产研测」2026-10
  • 现象：“LeapCore 相关先过一遍”的范围没定，跨管理线的成员不清楚要不要过审，重复建设提醒了两次｜依据：「鼎慧产研决策部」2026-07
  • 现象：权限表 → 枚举 → 权限码多次改造，越权问题到测试阶段才发现，身份规则反复变化｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-06
  • 现象：设计文档评审没有时限，反复催“批注完了没”，评审人被会议占用；设计中途被推翻｜依据：「⭐大模型基座事业群」2026-01、「⭐大模型基座事业群」2026-02

9. 分支变体

  • Leap/鼎慧产研：L2 方案由 Leap 研发负责人过审；LeapCore 相关一律过审
  • 基座组：新组件（RAG、知识库、图谱、网盘、RBAC/网关、Harness）走 L3，文档批注 → 回改 → 宣布定稿 → 分工，核心设计追加对齐会；Demo 项目可降为 L2
  • 权限/角色类（跃竞、LeapCore）：必须附权限矩阵，平台管理员、俱乐部管理员、接待、陪玩、顾客等身份逐一列出，测试同步写越权用例
  • 基础设施类（观测、网关）：必须先 PoC 并在站会演示
  • 跨线项目（开放平台、FDE、渠道系统）：只对齐数据实体和交互边界，不审内部实现

10. 待确认问题

  • L2/L3 的阈值（1 人日、500 行）是否合适？
  • “LeapCore 相关”范围怎么界定？跨管理线项目由谁过审？
  • 基座组设计文档的终审人是否为研发负责人？评审时限 2 个工作日是否可行？
  • 方案统一放 Gitea issue 还是飞书 wiki？是否要求 PR 必须关联方案 issue 并加 CI 检查？
  • “不确定的需求不下发”由谁把关？
  • 权限矩阵由研发维护还是产品维护？
RND-14技术方案评审、选型决策与赛马待新建192

状态：待新建｜证据：有证据（卡片 18 张 / 会话 10 个）｜优先级：频4 × 耗4 × 跨3 × 险4

  • 适用场景：同一技术问题有 2 个以上方案或明显分歧（协议、框架、数据库、部署位置、计费归属、底座路线、交互原型），需要明确决策人、按标准评审或赛马择优，并把结论写成决策记录时启动
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——议题收口负责人（按领域指定，如 Agent Runtime/协议当前：岳阳·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 登记决策议题 → ② 指定收口人与决策人 → ③ 写 ADR 草稿与方案对比 → ④ 选评审方式（文档/决策会/原型/赛马）→ ⑤ 评审或评测 → ⑥ 决策人拍板 → ⑦ ADR 归档公告 → ⑧ 落执行工单
  • 交付结果：归档的技术决策记录（ADR：背景、选项、取舍、结论、决策人、日期、生效范围、重议条件）及执行工单；赛马另含章程、评测报告、评分表和名次公告
  • 状态依据：2026-03～09 框架/数据库、计费归属、网关协议、部署位置、OCR、模型档位等分歧讨论约 60 次，大多在群里争论后由负责人一两句话拍板，没有记录，同一问题反复重议、方案被推翻；只有 2026-07 开放平台决策会留下了决议清单；Agent 赛马有规则文档和评审通知，但规则、截止时间、模型要求多次口头变更

1. 场景判定

  • 触发条件：群里同一技术问题讨论超过 10 条消息或超过 1 天仍未收敛；两人以上提出不同方案；涉及长期架构（语言、框架、数据库、协议、部署位置、计费归属、底座路线）；交互方案有分歧需要产品选；需要从多人并行实现中择优
  • 典型说法：「你决策一下吧」「各做一个prototype 然后选」「你们赛马吧 谁效果好用谁的」「决策出现分歧或者方向不确定喊我」「这块方案收口到 Agent 负责人这做决策」「把文档发这一下，让他们先提前读半小时」
  • 判断问题：这是“选哪个方案”的问题，而且选错会造成返工或长期维护成本吗？只是个人的实现细节，不走本流程
  • 不归本流程管：单一方案的开工前过审 → 请走 RND-13；开源/第三方能力引入调研 → 请走 RND-15；全公司默认技术栈与组件库 → 请走 RND-16；大模型与上游供应商选型评测 → 请走 RND-68；涉及业务方向、预算、人力的重大决策 → 请走 CEO-04；对外黑客松与生态赛事 → 请走 ECO-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
议题发起人 登记议题，写本方方案 R 任一研发（当前：待指定）
收口负责人 汇总选项和考虑点，主持评审，起草 ADR R 按领域指定（Agent Runtime/协议当前：岳阳·推断待确认）
流程主责 / 产品线决策人 指派收口人；产品线内议题拍板；维护决策台账 A Leap 研发负责人（当前：王皓南·推断待确认）
跨线决策人 跨产品线、长期架构、涉及成本的议题拍板 A（升级） 研发负责人（创始人兼 CTO，当前：丁震宇）
技术顾问 安全、生产化、运维成本意见 C 基座研发负责人（当前：望政韬·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）
产品 赛马组织；交互/原型类议题的原型选择与范围裁定 R/A（升级） 产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）
评审人 在文档或决策会上逐项给意见 C 技术顾问、产品、评测负责人及受影响模块负责人（按议题邀请）
评测负责人 赛马评测集、评测器、执行评测 R 测试负责人（当前：张东郅·推断待确认）
赛马奖励 确定奖励与积分 A（升级） CEO（当前：邴龙志·推断待确认）
受影响研发 接收结论并执行 I 相关研发（当前：待指定）

3. 办之前请准备

  • 议题一句话，以及必须在什么时候定
  • 每个选项：原理、成本（工期/费用/人力）、风险（安全、维护、许可）、对现有系统的影响、谁来做
  • 已知约束：交付节点、客户环境（内网、多层 NAT、信创）、预算
  • 相关文档、PoC、Demo 视频链接；长文档另附 ≤ 2 页摘要
  • 赛马另需：目标、时限、参赛名单、统一接口协议、评测集版本（公开集/保密集）、统一基础模型、评分维度与权重、提交材料清单、奖励

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记决策议题：议题、选项、截止时间、发起人 议题发起人 发现分歧当天 多维表格「技术决策台账」 议题条目 🔧飞书固化
2 按分级指定收口人和决策人：模块内由收口人自决；产品线内由 Leap 研发负责人；跨产品线、长期架构、涉及成本由 CTO Leap 研发负责人 登记后 0.5 个工作日内 台账 责任人 👤人工判断
3 汇总选项写 ADR 草稿（≤ 2 页）；可用 AI 从群聊整理分歧点 收口负责人 指定后 1 个工作日内 飞书 wiki ADR 模板 ADR 草稿 🤖+👤
4 选评审方式：文档评论（默认）；决策会（3 方以上或跨部门，会前 30 分钟发材料）；原型对比（交互/组件选型，各做一版让产品选）；赛马（多人并行实现，见步骤 9） 收口负责人 与步骤 3 同时 — 评审安排 👤人工判断
5 评审：在文档逐项给意见；决策会控制在 90 分钟内，用智能纪要记录 评审人 文档评审 1 个工作日内 飞书文档评论 / 飞书会议 + 智能纪要 评审意见 🔧+🤖
6 决策人拍板，写明结论、理由、生效范围、重议条件 决策人（按步骤 2 分级：收口负责人 / Leap 研发负责人 / CTO） 评审完成当天 ADR 定稿 ADR 👤人工判断
7 ADR 归档到知识库“技术决策”目录，群公告并置顶，台账改为“已决策” 收口负责人 拍板后 1 个工作日内 飞书 wiki + 群公告 公告 🔧飞书固化
8 建执行工单并链接 ADR；被否方案的已有代码按 ADR 处置 收口负责人 拍板后 1 个工作日内 Gitea 执行工单 🔧+👤
9 赛马子流程：发章程 → 参赛者截止前交 todo、方案、工期 → 发统一协议和评测集 → 提交材料包 → 自动评测 + 评委打分 → 公布名次并开异议窗口 → 冠军方案按步骤 6～8 写 ADR 接入产品 产品总监（组织）、测试负责人（评测） 章程至少提前 3 个工作日发布；规则变更提前 1 个工作日通知 飞书 wiki、多维表格、评测仓库 评测报告、名次公告 🔧+🤖+👤

5. 交付物与模板

  • 交付物：技术决策台账条目、ADR、决策会决议清单、执行工单；赛马章程、评测报告、评分表、名次公告
  • 建议模板/表单：
    • 「技术决策台账」：议题、领域、选项、收口人、决策人、截止、状态、ADR 链接、关联工单、重议记录
    • ADR 模板：背景、约束、选项对比表（成本/风险/可维护性/可替换性/许可）、结论、理由、决策人、日期、生效范围、重议条件
    • 决策会材料：逐项待决事项 + 建议值；会后决议清单每项标责任方和阶段（参照 2026-07 开放平台决议清单）
    • 赛马章程：目标、时限、参赛者、接口协议版本、基础模型、评测集版本与保密规则、评分维度与权重（技术/产品/体验）、提交材料包、截止时间、异议渠道、奖励、成果归属
    • 评分表：评委、维度分、总分、备注；评委池名单

6. 异常与升级

  • 议题过了截止时间仍未决策 → 收口人当天升级决策人；决策人 1 个工作日内仍未拍板 → 升级 CTO
  • 已决策事项被重提 → 必须给新证据，由原决策人判断是否重开；没有新证据直接引用 ADR 回复
  • 评委或决策人缺席 → 用台账备选人；赛马评委从评委池替补，当天通知参赛者
  • 赛马评测集泄漏或与训练集撞题 → 暂停评测，测试负责人 1 个工作日内换保密集并通知全体
  • 赛马规则要变更 → 只在章程 wiki 修改，评论写清变更点，@全体通知一次；比赛前 24 小时内不改规则
  • 测试账号口令等凭据 → 不在群里发明文，走密码库；已外发的立即更换
  • 决策牵涉预算或人员调配 → 转 CEO-04 / CEO-07
  • 升级拍板（A（升级））：议题跨产品线、涉及长期架构或成本，或产品线内 1 个工作日未拍板 → 研发负责人（CTO）拍板；交互/组件选型以原型对比方式评审时 → 产品总监拍板；赛马奖励与积分 → 报 CEO 确定

7. 衡量指标

  • 决策时长 = 议题登记到 ADR 定稿的工作日，目标 ≤ 3 天（赛马除外）
  • ADR 覆盖率 = 有 ADR 的已决策议题 / 已决策议题，目标 100%
  • 重议率 = 重新打开的决策 / 已决策数，目标 ≤ 10%
  • 决策后返工数 = 因方案推翻产生的重写工单数（季度观察）
  • 赛马规则发布后变更次数，目标 ≤ 1 次

8. 低效诊断

  • 现象：同一问题多人在群里混讲，直到负责人指派才收口；谁定协议不清，方案被推翻（通信方式更换、远控推迟）｜依据：「Leap产研测」2026-04
  • 现象：方案没有评审纪要，事后发现冲突和重复建设；争论后出现推责｜依据：「Leap产研测」2026-05、「Leap产研决策部」2026-08
  • 现象：计费归属、底座路线等架构决策靠群聊口头形成，先接入后剥离，结论不记录｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：决策会材料太长没人读，改成会上讲；会议时间反复调整，决议没有固定存放位置｜依据：「Leap产研测」2026-05、「Leap产研测」2026-07
  • 现象：OCR、认证集成、仓库拆包等选型一两句话拍板，成本依据零散，对接方案前后反复调整｜依据：「研发通知」2026-06
  • 现象：原型对比决策太晚（hotfix 前一天还在换组件），选型没和其他研发同步｜依据：「Leap产研测」2026-08
  • 现象：赛马方向参赛者自述混乱；评测集撞训练集，比赛前一天紧急更换；模型要求只在会上口头说，多人接错；截止时间临时改｜依据：「Leap产研测」2026-04、「leapagent赛马」2026-04
  • 现象：底座路线和人员分配口头确定，测试口令明文发群｜依据：「LeapBase开发群」2026-06

9. 分支变体

  • 文档评审：默认方式，适合两方分歧
  • 决策会：开放平台等跨部门技术决策，逐项决策 + 决议清单
  • 原型对比：交互/组件选型，用 /prototype 并行做两版，产品看视频选，选定后写进工单
  • 赛马：自研 Agent/底座等关键内核；“命题作文”（测试组写评测集）或“自由作文”（选手自写评测集，测试只写评测器）；技术分（LLM judge、评分 Skill 自动打分）+ 体验分（评委看现场演示）；内部赛马与对外黑客松分开，对外走 ECO-15
  • 决策分级：模块内 / 产品线内 / 跨产品线或长期架构
  • 客户网络边界（如多层 NAT）：部署前提和免责说明作为交付规则写入 ADR

10. 待确认问题

  • 决策分级和对应决策人是否认可？Leap 研发负责人与 CTO 的边界怎么划？
  • ADR 放飞书 wiki 还是 Gitea 文档仓库？
  • 是否设固定的技术方案评审时段（如每周一次）？
  • 赛马章程模板由谁维护？评委池名单和默认评分权重（如产品 70% / 技术 30%）是否固定？
  • 赛马奖励和积分是否走 HR-18？参赛作品归属是否需要法务确认？
  • “无新证据不得重议”是否写进制度？
RND-15新技术/开源方案/第三方能力调研评估待新建144

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：出现值得跟进的开源工具，或产品需要网盘、AI 网关、OCR、企业软件、第三方数据等外部能力时，评估“自研 / 二开 / 套壳 / 直接引入 / 采购 API”并给出立项建议时启动
  • 负责人：主责——技术调研负责人（当前：王皓南·推断待确认，可按议题另行指定）；协同——产品总监（当前：杨萌·推断待确认）、基座组架构负责人（当前：陈晖·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、研发联调（当前：魏宗浩·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 登记调研议题 → ② 明确业务目标与数据范围 → ③ AI 初评横评 → ④ 人工评估许可、授权、成本、维护、隔离方式 → ⑤ 试用或 PoC → ⑥ 评审拍板 → ⑦ 转立项、接入或采购
  • 交付结果：调研评估报告（候选对比、许可证与授权结论、成本、工期、推荐方案、实施负责人），调研台账结论，转入立项/接入/采购的记录
  • 状态依据：每次临时处理：2026-01 开源套壳定了“自研与套壳并行”，但没有立项和负责人；2026-01～03 网盘、AI 网关出了多份评估报告后决策仍在变，许可证和商业授权在群里长时间争论；2026-09 首次做企业软件对接，范围、谁有需求反复讨论，产品侧明确提出要借此形成 SOP

1. 场景判定

  • 触发条件：发现热门开源项目可能替代或补强自有产品；产品需要新能力而公司没有；产品要接企业软件或第三方数据 API；客户需求需要外部能力支撑
  • 典型说法：「我建议派1-2个人组建一个小团队研究开源部署以及套壳」「套壳评估报告」「我们要接金蝶用友的api」「谁有需求和谁聊，聊完确定怎么接」「先把前面几步做好，再购买API授权」「GPL v3有风险」
  • 判断问题：要回答的是“这个能力该不该引入、用哪个、怎么引入”吗？已经定了要引入、只差开发对接，就不走本流程
  • 不归本流程管：已决定引入后的接入开发与上线验证 → 请走 RND-67；大模型与上游供应商选型评测 → 请走 RND-68；内部多方案拍板 → 请走 RND-14；AI 新工具资讯跟踪与试用分享 → 请走 GEN-17；外部合作方评估 → 请走 CEO-19；开源成果对外发布 → 请走 ECO-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 登记议题，说明业务目标 R 产品或研发（当前：待指定）
调研负责人 横评、试用、写报告 R 技术调研负责人（当前：王皓南·推断待确认）
业务范围梳理 组织业务部门列场景和数据范围（企业软件对接） R 总经办（当前：田杰·推断待确认）
调研指派 指定调研负责人和截止日期 R Leap 研发负责人（当前：王皓南·推断待确认）
业务与数据权限把关 指派梳理人；涉及财务或客户敏感数据时确定数据开放边界 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）
技术顾问 架构适配、许可证风险、授权限制 C 基座组架构负责人（当前：陈晖·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）
产品 定义需求和验收标准 C 产品总监（当前：杨萌·推断待确认）
财务 测试账号、授权采购、费用 C 财务负责人（当前：黄梦婷·推断待确认）
法务 许可证与授权条款审查 C 法务负责人（当前：李瑶·推断待确认）
销售 补充客户侧需求 C 销售（当前：闫登辉、吴琪·推断待确认）
研发联调 PoC 与接口可行性验证 R 研发（当前：魏宗浩·推断待确认）
拍板 是否投入、选哪个 A 研发负责人（创始人兼 CTO，当前：丁震宇）

3. 办之前请准备

  • 业务目标：解决谁的什么问题；公司自用还是客户需求；期望上线时间
  • 数据范围：读写哪些数据，是否涉及财务或客户敏感数据
  • 候选清单（至少 2 个，含“自研”选项）和来源链接
  • 先查调研台账，确认没人做过同类调研
  • 试用只用测试账号和非敏感数据；要付费授权的先评估再采购

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记调研议题：目标、业务方、期望日期、候选 发起人 当天 多维表格「技术调研台账」 议题 🔧飞书固化
2 指定调研负责人和截止日期（一般 ≤ 5 个工作日） Leap 研发负责人或 CTO 登记后 1 个工作日内 台账 + 飞书任务 负责人与截止 👤人工判断
3 企业软件/数据源类：组织财务、运维、销售、总经办列出要自动流转的数据和场景，确认版本、账套、调用限额 总经办 3 个工作日内 飞书 wiki 接口需求文档 范围清单 👤人工判断
4 AI 初评：生成候选对比（功能、许可证、活跃度、价格、部署要求） 调研负责人 1 个工作日内 AI 深度调研 初评报告 🤖自动化
5 人工评估：许可证传染性、商业授权与用户规模限制、维护状态、隔离方式（外挂封装不改源码 / 二开）、工期、成本、客户硬件能否跑得动 调研负责人 + 技术顾问 2 个工作日内 评估报告模板 评估报告 👤人工判断
6 必要时 PoC 或横评试用 调研负责人、研发联调 ≤ 2 个工作日 测试环境 PoC 结论 👤人工判断
7 评审拍板：先读报告再讨论，结论写入报告（自研/二开/套壳/引入/采购/不做） CTO 报告提交后 2 个工作日内 飞书文档评论或 30 分钟评审会 调研结论 👤人工判断
8 转出：引入 → RND-05 立项或 RND-67 接入；付费 → 采购审批（FIN-01）；许可证有风险 → 法务确认；台账关闭 调研负责人 拍板后 1 个工作日内 台账 转出记录 🔧飞书固化

5. 交付物与模板

  • 交付物：调研台账条目、评估报告、PoC 结论、转出记录
  • 建议模板/表单：
    • 「技术调研台账」：议题、来源（开源/第三方 API/企业软件）、业务方、调研负责人、截止、候选、结论、报告链接、转出去向、状态
    • 评估报告模板：业务目标；候选对比表（功能覆盖、许可证、商业授权、用户规模限制、活跃度/维护、部署要求、隔离/替换方式、工期、成本）；风险；推荐方案；实施负责人与里程碑
    • 企业软件对接附件：接口需求清单（场景、数据对象、读/写、频率、权限范围、账套、测试账号）
    • 开源组件功能清单：按模块列出功能，供选型后删减生成自有需求文档

6. 异常与升级

  • 调研超期 → 负责人说明原因可延期一次（≤ 3 个工作日）；再超期升级 CTO
  • 许可证有传染风险或商业授权有限制 → 默认只允许外挂封装、不改源码；需要二开的先报法务确认再拍板
  • 涉及财务或客户敏感数据 → 默认最小权限（如不开放账套查看权限），升级综合部负责人（A（升级））2 个工作日内确认数据开放边界，确认前不进入 PoC
  • 缺真实测试账号 → 财务/业务方 2 个工作日内提供；提供不了就停在评估阶段
  • 内部没人手 → 升级 CTO 决定借调或暂缓（参照 CEO-07）
  • 结论拍板后要推翻 → 必须有新证据，按 RND-14 重议

7. 衡量指标

  • 调研周期 = 登记到结论的工作日，目标 ≤ 7 天
  • 报告完整率 = 含许可证、授权、成本、工期四项的报告比例，目标 100%
  • 结论变更率 = 拍板后又改结论的议题比例，目标 ≤ 15%
  • 重复调研次数 = 同一能力被重复调研的次数，目标 0

8. 低效诊断

  • 现象：开源套壳研究“手头没人”，归属哪个组没定，没有立项和负责人｜依据：「鼎慧产研决策部」2026-01
  • 现象：网盘、AI 网关出了多份评估报告后决策仍反复，同一天先说不改源码、又说先改旧版｜依据：「⭐大模型基座事业群」2026-01
  • 现象：许可证、商业授权、维护状态在群里长时间争论，有人没看文档就参与讨论｜依据：「⭐大模型基座事业群」2026-01、「⭐大模型基座事业群」2026-03
  • 现象：企业软件对接时产研不熟悉业务，谁有需求、要不要接反复讨论，到测试阶段才发现缺真实账号｜依据：「leapcore接金蝶用友」2026-09、「leapcore接金蝶用友」2026-10

9. 分支变体

  • 开源套壳/集成：线上高配与线下低配可并行；强调外挂封装、微服务隔离
  • 开源组件选型：网盘（外挂套壳、不改源码）；AI 网关（商业授权和用户规模限制 vs 自研）
  • 第三方数据 API（工程数据、企业信息等）：AI 生成数据源优劣与价格对比，不够用再找商务谈
  • 企业软件：金蝶先、用友后（对方已有连接器）；公司自用先行；多主体分别开账套，注意调用限额
  • 公司自用 vs 客户需求：客户需求由销售补充场景

10. 待确认问题

  • 调研负责人默认由谁指派？是否设固定的技术预研人力？
  • 调研台账是否与 GEN-17 的 AI 情报库合并？
  • 许可证审查是否必须法务参与？
  • 企业软件对接的业务范围梳理是否固定由总经办牵头？
  • 调研时限 5 个工作日是否可行？
RND-16技术栈、组件库统一与通用能力复用待新建54

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨2 × 险3

  • 适用场景：新项目或新组件启动要选语言、框架、UI 组件库、通信方式、数据库；或发现多个项目在重复造同类轮子；或 FDE/定制项目做出可复用能力需要回流到模板、标准组件时启动
  • 负责人：主责——技术规范维护人（当前：待指定）；协同——基座组架构负责人（当前：陈晖·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、前端负责人（当前：季学森·推断待确认）、开放平台/FDE 负责人（当前：郭逸非·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 立项时对照技术栈清单勾选 → ② 查组件目录做复用评估 → ③ 清单外选型提偏离申请 → ④ 审批拍板 → ⑤ 更新清单并置顶公告 → ⑥ 可复用能力回流 → ⑦ 共性规范写入约束 → ⑧ 季度复盘
  • 交付结果：生效的《公司技术栈与组件清单》（含版本和生效日期）、组件目录、偏离申请记录、回流 PR、写入 Agent 约束的共性规范
  • 状态依据：基座组 2026-01 已拍板 TS 为主、前端 Vue3、后端 Elysia、组件间 HTTP，2026-03 定了数据库统一 PostgreSQL、缓存 Redis，也有前端脚手架；但结论只在群聊和投票里，同一决策 2026-01～02 重议约 5 轮；2026-03～06 各项目仍各选 UI 库和通信方式，“组建公司推荐 UI 库”多次提出没落地；定制能力回流规则只靠口头传达

1. 场景判定

  • 触发条件：新建仓库、新项目、新组件；想用清单外的语言、框架、组件库、通信或部署方式；发现别的项目已有类似模块；定制项目做出可复用的原子能力；AI 生成的系统反复出现同类缺陷（翻页、软删除、幂等）
  • 典型说法：「所有人，UI组件库用mui」「真得整治一下公司的技术栈了」「今天就确定下来…用啥为主」「后面就不用纠结语言和默认框架了」「不是可通用能力，而是可复用能力」「研发三大坑 不知道能复用别人的 不屑于复用别人的 复用不来别人的」
  • 判断问题：这个选择会被其他项目沿用，或影响别人接手维护吗？会就走本流程；只影响一个函数怎么写的不走
  • 不归本流程管：单个议题多方案拍板 → 请走 RND-14；外部开源/第三方能力引入评估 → 请走 RND-15；依赖版本锁定与供应链 → 请走 RND-36；AI 编码约束文件的编写规范 → 请走 RND-28；编码与工程规范宣贯 → 请走 RND-30；仓库创建与权限 → 请走 RND-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范维护人 维护清单和组件目录，初审偏离申请，组织季度复盘 R 技术规范维护人（当前：待指定）
拍板 清单变更、偏离审批 A 研发负责人（创始人兼 CTO，当前：丁震宇）
基座组技术意见 后端/AI 服务栈、模型接入层、RAG 封装 C 基座组架构负责人（当前：陈晖·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）
产品线技术意见 Leap/鼎慧前端与客户端栈、推荐 UI 库 C Leap 研发负责人（当前：王皓南·推断待确认）、前端负责人（当前：季学森·推断待确认）
回流负责人 定制项目可复用能力回流模板 R 开放平台/FDE 负责人（当前：郭逸非·推断待确认）
项目研发 立项勾选、复用评估、提偏离申请 R 各项目研发（当前：待指定）
交付组 沿用同一套技术栈 I 交付研发（当前：待指定）

3. 办之前请准备

  • 项目类型（Demo / 正式产品 / 客户定制）、预计生命周期、维护团队
  • 打算用的语言、框架、组件库、数据库、通信和部署方式
  • 在组件目录和代码仓库里检索过的结果（可复用模块、仓库链接）
  • 要偏离清单时：为什么清单内的方案不行（具体证据：缺陷、性能、客户环境限制）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项时对照《技术栈清单》勾选，写入项目 README；优先用官方脚手架 项目研发 建仓库当天 清单 + 仓库模板/脚手架 勾选记录 🔧飞书固化
2 查组件目录，已有同类能力的写“复用评估”一段（复用 / 部分复用 / 不复用及原因） 项目研发 建仓库当天 组件目录 + AI 检索仓库 复用评估 🤖+👤
3 需要清单外选型 → 提偏离申请：选项、理由、影响、维护人 项目研发 开工前 飞书表单 偏离申请 🔧飞书固化
4 规范维护人初审，CTO 拍板；默认语言/框架这类重大变更按 RND-14 写 ADR，可用飞书投票收集意见 规范维护人、CTO 2 个工作日内 飞书审批 / 投票 审批结论 👤人工判断
5 批准后更新清单（版本号、生效日期），群公告置顶；明确“无新证据不重议” 规范维护人 批准后 1 个工作日内 飞书 wiki + 群公告 新版清单 🔧飞书固化
6 可复用能力回流：定制项目中除业务逻辑外的原子能力，以 PR 合入模板或标准组件，附说明和测试 回流负责人 项目交付后 10 个工作日内 Gitea PR 回流 PR 👤+🤖
7 共性规范（翻页、增删改、软删除、前端防抖、后端幂等）写进 Agent 约束文件和模板检查脚本 规范维护人 发现共性缺陷后 5 个工作日内 约束文件 + CI 检查 约束与检查 🤖自动化
8 季度复盘：统计各项目偏离情况，淘汰、补充清单项，合并重复组件 规范维护人 每季度末 清单 + 组件目录 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：技术栈清单、组件目录、偏离申请与审批记录、回流 PR、约束文件更新
  • 建议模板/表单：
    • 《公司技术栈与组件清单》：分类（语言、前端框架、UI 组件库、后端框架、数据库/缓存、组件通信、部署方式、IaC、AI SDK/模型接入层）× 默认项 / 允许项 / 不推荐项 × 适用场景（Demo/正式）× 版本 × 生效日期 × ADR 链接
    • 组件目录：组件名、能力、仓库、维护人、使用项目、成熟度
    • 偏离申请表：项目、清单项、拟用方案、理由与证据、影响范围、维护人、有效期
    • 回流 PR 检查项：已去除业务逻辑；有文档与测试；实例 ID/机器码/SN 等标识语义与 LeapCore 一致

6. 异常与升级

  • 没申请就用了清单外技术 → PR 评审退回，或在 1 个迭代内迁移；重复发生升级 CTO
  • 已定的选型被反复质疑 → 规范维护人引用 ADR 回复；有新证据才进入重议
  • 新人被指引用多套技术栈 → 以清单为准，带教人 1 个工作日内纠正
  • 两个项目并行维护同类组件 → 规范维护人 5 个工作日内给出合并方案和负责人
  • 回流能力质量不达标 → 退回补测试；跨系统标识不一致 → 转 RND-18
  • 选型讨论发在不相关的大群 → 引导到研发群并登记议题

7. 衡量指标

  • 清单符合率 = 使用清单内默认/允许项的新项目 / 新项目总数，目标 ≥ 90%
  • 偏离审批时效 ≤ 2 个工作日
  • 重议次数 = 已定技术栈被重新讨论的次数，目标每季度 ≤ 1 次
  • 重复组件数 = 同类能力并行维护的组件数，目标逐季下降
  • 回流率 = 有回流 PR 的交付项目 / 交付项目总数（观察指标）

8. 低效诊断

  • 现象：语言和默认框架约一个月内重议约 5 轮，结论没有书面记录，只能转发聊天记录回溯；执行者几周内被指引了三套技术栈｜依据：「⭐大模型基座事业群」2026-01、「⭐大模型基座事业群」2026-02
  • 现象：组件库选型靠个人试用后在群里避雷、一句话宣布，没有选型文档｜依据：「鸽子群模态分群」2026-03、「鸽子群模态分群」2026-04
  • 现象：各项目分别选 UI 库和通信方式，有人自己再写一套组件；“统一技术栈”“推荐 UI 库”多次提出未落地，讨论还发在不相关的群里｜依据：「鸽子群模态分群」2026-05、「鸽子群模态分群」2026-06

9. 分支变体

  • 基座组 AI 服务：TS 为主，后端 Elysia，组件间 HTTP/REST，暂不引入 gRPC；Python 过渡版后续改 TS + AI SDK 统一维护；需考虑外部公司集成
  • 前端：Vue3 为默认（有前端脚手架），管理后台可用 React；React、Vue 两条线各定一个推荐 UI 库
  • 新后台/站点：数据库统一 PostgreSQL、缓存 Redis；正式库用云托管（带备份），测试库可放本地；初期 Demo 不上微服务
  • 通信：ws / sse / 轮询按场景在清单写明默认
  • 部署：容器滚动更新 vs k8s
  • FDE/定制项目：原子能力回流 LeapWorld 模板；与 LeapCore 只对齐实例 ID/机器码/SN，业务逻辑各自独立
  • 跨项目底座：先做“大杂烩”交付再拆组件；模型接入层统一，RAG/问数封装成工具

10. 待确认问题

  • 技术规范维护人由谁担任？是否成立技术委员会承接？
  • 现有默认栈（TS、Vue3、Elysia、PostgreSQL、Redis）适用全公司，还是只适用基座组？Leap 客户端、跃竞是否例外？
  • React、Vue 两条线的推荐 UI 库分别是什么？
  • 偏离申请由 CTO 审批，还是各线研发负责人审批即可？
  • 回流时限 10 个工作日是否可行？回流 PR 由谁评审？
RND-17重大技术变更/重构报备与同步待新建240

状态：待新建｜证据：有证据（卡片 13 张 / 会话 5 个）｜优先级：频4 × 耗4 × 跨3 × 险5

  • 适用场景：开发者准备重构/重写模块、更换方案或选型、修 bug 时会删改用户可见功能、关停高风险功能或下线接口、改关键设计口径、合入会影响他人仓库或接口的代码，或发现外部依赖风险时，事前报备并同步相关方
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、测试负责人（当前：张东郅·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）、变更摘要机器人维护人（当前：李铭熙·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 判定变更级别 → ② 写变更说明（影响面/回滚/测试建议）→ ③ @相关人征求意见 → ④ 按级别审批 → ⑤ 实施并在 PR 标注 → ⑥ 测试回归 → ⑦ 合入后自动通知 → ⑧ 每日变更摘要与日志
  • 交付结果：已审批的变更说明、带“影响面”字段的 PR、合入通知记录、回归结果、变更日志条目
  • 状态依据：事故驱动，没有固定机制：2026-05 重构合并覆盖他人功能、计费改一半就发包、产品合并改成重写未通知；2026-05～07 多次出现“谁同意他重构的”“为什么老是偷偷改”，修 bug 直接删掉托盘功能 3 天后才被测试发现；只有“breaking change 要提前报备”的口头规则、临时的每晚 commit 扫描，以及一次机器人辅助的跨仓通知

1. 场景判定

  • 触发条件（任一即属重大变更）：重构/重写模块或整端（桌面端、网关）；更换选型（认证、计费、队列实现）；删除或改变用户可见功能；关停功能、下线接口；改既定设计口径；改计费、鉴权、数据结构、配置默认值；分支重命名、强制更新；合入影响其他仓库或他人接口的代码；外部审核/依赖有延期风险
  • 典型说法：「改东西前同步一下」「开始干之前就得同步」「这个决策有人跟了吗 同步了吗 没定的话别干」「这种修复方式需要产品评审，不能说这个功能有问题就砍掉了」「重构的重点是保持重构前后行为一致」「该报的风险得报」「我刚合了三个PR，你看看需要通知哪些人」
  • 判断问题：这个改动会让产品、测试、其他研发或客户看到的行为、依赖的接口发生变化吗？会就必须先报备
  • 不归本流程管：新功能开工前方案过审 → 请走 RND-13；方案分歧拍板 → 请走 RND-14；前后端接口字段变更与废弃 → 请走 RND-19；数据库 Schema 变更 → 请走 RND-34；生产环境配置/部署变更审批 → 请走 RND-58；Git 分支规范 → 请走 RND-31；故障处置 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
变更发起人 写变更说明、征求意见、实施、通知 R 变更发起研发（当前：待指定）
技术审批 审批重构、换方案；主持站会过变更 A Leap 研发负责人（当前：王皓南·推断待确认）
产品评审 删改或关停用户可见功能的取舍 A（升级） 产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）
测试 评估回归范围，执行回归 R 测试负责人（当前：张东郅·推断待确认）
受影响模块负责人 确认影响，提出意见 C 模块负责人（当前：待指定）
PR 合并人 检查 PR 影响面字段，缺失则退回 R PR 主合并人（当前：岳阳·推断待确认）
变更摘要 每日汇总 commit 与变更工单发群 R 变更摘要机器人维护人（当前：李铭熙·推断待确认）
终审 计费、鉴权、整端重写等高风险变更终审 A（升级） 研发负责人（创始人兼 CTO，当前：丁震宇）

3. 办之前请准备

  • 变更原因和数据依据（如单文件行数、bug 数、性能数据）
  • 影响面：模块、接口、用户可见行为、其他仓库、客户在用版本
  • 回滚方案和回滚点
  • 测试建议：哪些老功能必须回归
  • 重写类：里程碑和截止日期
  • 外部依赖风险：审核周期、受影响的节点

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定级别：A 级（计费/鉴权/数据结构/整端或网关重写/删改或关停用户可见功能）；B 级（模块内重构、选型替换、跨仓接口变化）；C 级（外部行为不变的局部优化，只需 PR 说明） 变更发起人 动手前 工单标签 变更级别 👤人工判断
2 写变更说明：原因、方案、影响面、回滚、测试建议、截止日期 变更发起人 动手前至少 1 个工作日 Gitea issue 变更模板 变更说明 🤖+👤
3 在研发群/项目群 @受影响负责人、产品、测试征求意见，写明“无异议截止时间” 变更发起人 与步骤 2 同日 飞书群 征求意见记录 🔧飞书固化
4 审批：B 级由 Leap 研发负责人在 1 个工作日内批；A 级需产品评审 + Leap 研发负责人，计费/鉴权/整端重写再报 CTO，2 个工作日内批；关停功能写明原因、影响版本、替代方案 审批人 见左 工单评论 / 飞书审批 审批结论 👤人工判断
5 在独立分支实施；PR 必填“影响面 / 是否删除或改变用户可见功能 / 关联变更工单”；重构要保证行为一致并补单测 变更发起人 按截止日期 Gitea PR 模板 PR 🤖+👤
6 PR 勾选“改变用户可见功能”时自动 @产品和测试；测试按建议回归 测试 提测后按迭代节奏 CI + 回归用例 回归结果 🤖+👤
7 合入后按仓库负责人名单（CODEOWNERS/订阅）自动通知受影响人，跨仓合入成组通知 机器人 合入后 10 分钟内 Gitea webhook + 飞书机器人 合入通知 🤖自动化
8 机器人每日汇总 commit 和变更工单发群；站会过一遍当日 A/B 级变更 摘要机器人维护人、Leap 研发负责人 每日 20:00 前；次日站会 机器人 + 站会 变更摘要 🤖自动化
9 记入变更日志 / 决策台账 变更发起人 合入后 1 个工作日内 飞书 wiki 日志条目 🔧飞书固化

5. 交付物与模板

  • 交付物：变更说明与审批记录、PR、回归结果、合入通知、每日变更摘要、变更日志
  • 建议模板/表单：
    • 变更说明模板：级别、原因与依据、方案、影响面（模块/接口/用户可见行为/客户版本/其他仓库）、不做什么、回滚点、测试建议、截止日期、审批人、无异议截止时间
    • PR 模板新增：影响面；是否删除/改变用户可见功能（勾选）；需知会对象；关联变更工单；部署依赖/配置项
    • 功能关停单：关停原因（成本/误触发/安全/维护）、影响版本、对外口径、是否保留内部开关、替代方案
    • 项目风险登记表（项目群置顶）：风险描述、等级、发现日、影响节点、负责人、应对、状态

6. 异常与升级

  • 发现未报备的 A/B 级变更 → 任何人当天在群里提出；Leap 研发负责人 1 个工作日内决定回退或补审批；A 级未报备同时纳入 RND-12 评级
  • 修 bug 删了功能 → 先恢复，产品评估后再决定是否进需求池（RND-04）
  • 半成品误发包 → 立即回退（RND-59），2 小时内通知产品和测试
  • 合并覆盖他人代码 → 发起人当天恢复并通知原作者；禁止对共享分支强推
  • 多人同时改同一接口或同时发布同一环境 → 先在工单认领，发布前在群里确认；协商不了升级 Leap 研发负责人
  • 外部审核/依赖风险 → 发现后 24 小时内登记风险表，周会过一遍；影响里程碑的升级 CTO
  • 大会/重要演示前冻结期 → 不允许 A/B 级变更，CTO 批准的除外
  • 升级拍板（A（升级））：变更会删除、改变或关停用户可见功能 → 产品评审（产品总监/对应产品经理）拍板取舍；涉及计费、鉴权、整端或网关重写，或冻结期内申请变更 → 报研发负责人（CTO）2 个工作日内终审

7. 衡量指标

  • 报备率 = 事前有变更说明的 A/B 级变更 / 全部 A/B 级变更，目标 ≥ 95%
  • 无声变更事件数 = 事后才发现的删改功能、改口径次数，目标 0
  • 重构回归缺陷数 = 重构合入后 2 周内引入的回归 bug 数（观察指标）
  • 审批时效：B 级 ≤ 1 个工作日，A 级 ≤ 2 个工作日
  • 跨仓通知覆盖率 = 自动通知的跨仓 PR / 跨仓 PR，目标 100%

8. 低效诊断

  • 现象：核心页面自行重构，合并时覆盖了他人的消息队列功能，回归崩溃；事后才知会｜依据：「Leap产研测」2026-05
  • 现象：计费方案改一半就发包，造成固定计费；产品合并从集成改成重写没通知，同一功能更新要写两遍｜依据：「鼎慧产研决策部」2026-05、「Leap产研测」2026-05
  • 现象：选型替换和重构没人审批，事后追问“谁同意的”｜依据：「鼎慧产研决策部」2026-05
  • 现象：关键设计（容器创建时机、成果文件夹）被个人改动，其他人不知情；分支重命名等变更“没意见下午就改”，决策来源不明｜依据：「Leap产研测」2026-06
  • 现象：修 bug 时整体删除托盘功能，测试 3 天后才在夜间版本发现；高风险功能先上线才发现可能持续消耗额度且没有管理入口｜依据：「Leap产研测」2026-07
  • 现象：桌面端/网关重写，产品在设计阶段不知道，设计稿可能白做；决策标准多变｜依据：「鼎慧产研决策部」2026-07
  • 现象：方案改动只在聊天里说，无用代码是否还在用反复确认｜依据：「工程咨询产研」2026-03
  • 现象：两人做同一件事、接口被强推覆盖、发布撞车｜依据：「Leap产研测」2026-08
  • 现象：外部审核风险没在项目群同步，大家以为一切正常；跨仓合入要人工让机器人推断该通知谁｜依据：「鸽子群模态分群」2026-05、「leapall逗狗群」2026-06

9. 分支变体

  • 重构 vs 优化：外部行为不变且单 PR < 300 行算 C 级，超出走 B 级
  • 整端/网关重写：必须给截止日期、里程碑、回滚点，周会评审后才排期；可与现有版本并行，先做到与现界面相近
  • 功能关停：LeapCore 内部可放开、对外关闭；考虑旧版本客户端兼容
  • 计费/支付类：一律 A 级，CTO 终审
  • 双线并行（LeapLite 与 LeapAll）：同一人负责两条线时，变更说明分别列影响
  • 跨仓合入：按仓库成组通知；底座发版同步下游见 RND-18
  • 大会/演示前冻结期：仅允许 CTO 批准的变更

10. 待确认问题

  • A/B/C 级的划分标准是否合适？
  • 删改或关停功能的产品评审人是产品总监还是对应产品经理？
  • 是否在 Gitea 配置 CODEOWNERS + webhook 自动通知？由谁搭建？
  • 每日 commit 摘要是否继续由机器人发群？
  • 未报备变更是否与点数/绩效挂钩？
  • Agent 提示词修改是否纳入变更报备？
RND-18跨团队/跨系统接口对齐与集成约定待优化500

状态：待优化｜证据：有证据（卡片 21 张 / 会话 18 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：两个以上研发组、产品或外部平台需要对接（账号/OIDC 登录、网盘、计费网关、订单与充值、开放平台、渠道系统、小程序互跳、底座与下游仓），要先对齐接口契约、数据唯一写入方、责任边界和降级方案，再并行开发与联调时启动
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——LeapCore 后端/运维（当前：宋祺睿·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、产品总监（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 提跨组对接单 → ② 分派两端负责人与裁决人 → ③ 写对接方案（边界/数据主责/接口/时序/降级）→ ④ 评审定版契约 → ⑤ 提供方出 mock 并行开发 → ⑥ 按清单联调 → ⑦ 文档与配置归档 → ⑧ 后续变更版本通知
  • 交付结果：定版的对接方案与接口契约（OpenAPI/事件 schema，单一文档源）、数据主责表条目、联调清单与问题表、外部对接的责任矩阵与协议
  • 状态依据：已有不少载体（OIDC 适配说明、ADR、OpenAPI/Apifox 文档、开放平台决议清单、渠道系统说明、工单系统），但 2026-01～10 约 20 起对接中，接口文档靠群里要，需求方与提供方反复反问才对齐，谁写数据、工单提给谁不清，联调现场才发现分支或 secret 不对，外部平台登录问题来回多次

1. 场景判定

  • 触发条件：需求需要另一个组/系统新增或修改接口、字段、权限；两个系统都要读写同一业务实体（订单、余额、合同、发票、实例）；接入 LeapAuth/OIDC 登录；底座（LeapCore/LeapWorld）要新增字段或同步版本；对接外部平台；发现上下游强实时依赖缺少降级
  • 典型说法：「约定好一版接口 然后两边同步开工」「先对齐信息再做不然我也不知道要干什么」「一个实体只会有一个系统负责写入」「我怎么提工单 提给谁」「你们别把几个需求混一起了」「你用你的AI去gitea上提一个工单」「理清楚支付这块的责权」
  • 判断问题：这件事需要另一个团队/系统的负责人改东西或承诺接口吗？需要就走本流程；同一项目组内前后端字段对接走 RND-19
  • 不归本流程管：同项目前后端接口变更与联调 → 请走 RND-19；单系统方案过审 → 请走 RND-13；架构分歧拍板 → 请走 RND-14；开放平台业务归属口径 → 请走 ECO-05；开放平台 Skill/插件上架 → 请走 ECO-06；渠道报备与订单业务流程 → 请走 SAL-31；支付商户与支付联调 → 请走 RND-66；第三方模型/API 接入 → 请走 RND-67

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求方负责人 提对接单，写本端诉求，参与联调 R 需求方研发（当前：待指定）
提供方负责人 评估、写契约、出 mock、排期 R 提供方研发（LeapCore 平台当前：宋祺睿·推断待确认）
流程主责 维护对接台账，分派两端负责人，追进度 A Leap 研发负责人（当前：王皓南·推断待确认）
架构裁决 系统边界、数据唯一写入方、降级方案 A（升级） 研发负责人（创始人兼 CTO，当前：丁震宇）
产品 业务目标、阶段范围、需求提单 C 产品总监（当前：杨萌·推断待确认）
开放平台 开放平台侧需求收口与排期 R 开放平台负责人（当前：郭逸非·推断待确认）
网关/计费顾问 网关用户映射、key 签发、计费边界 C 基座研发负责人（当前：望政韬·推断待确认）
运维资源 部署位置、域名、数据库、对象存储 R IT 运维（当前：杨明学·推断待确认）
外部对接 对接外部平台、法务风险报告 R/C 生态组负责人（当前：陈梦琪·推断待确认）、法务负责人（当前：李瑶·推断待确认）
外部责权决策 支付、运维、坏账等责任边界 A（升级） CEO（当前：邴龙志·推断待确认）
财务口径 订单、发票、余额唯一数据源 C 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 对接目标与阶段（短期先让某客户用上 / 长期统一）
  • 涉及的实体、读写方、数据量、实时性要求
  • 账号与鉴权方式（OIDC client、token、service secret）
  • 环境信息：测试/预发/生产地址、分支（参考机器环境清单，内网地址不外传）
  • 已有文档链接（OpenAPI、ADR、配置说明）
  • 外部对接：对方联系人、接口文档、责任约定草稿
  • 不直接转发未经核对的 AI 生成内容当对接说明
  • 请求最少包含字段（对接单必填，缺项不受理）：需求方与提供方系统、业务目标与阶段、涉及实体及期望的读写方、接口清单草稿（或"待提供方定义"）、目标环境、期望完成日期与原因、验收标准、需求方负责人与兜底答疑人、关联需求/工单号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在工单系统提“跨组对接”单：背景、期望、涉及实体与读写、截止、验收；一个需求一张单，不混提 需求方负责人 发现需要对接当天 issues 工单 + 「跨组对接台账」 对接单（工单系统，同步登记跨组对接台账） 🔧飞书固化
2 分派提供方负责人、优先级、截止；涉及数据主责或跨产品线的拉架构裁决人 流程主责 收单后 1 个工作日内 工单 + 台账 分派结果（写回工单，两端负责人被 @；超时→需求方在工单 @ 流程主责） 👤人工判断
3 写对接方案：边界图、数据主责（实体-写入方-读方）、接口清单与时序、鉴权、错误与降级（上游不可用时用缓存或上次成功数据兜底）、环境与配置项、兜底答疑人 提供方负责人主笔，需求方补充 分派后 2 个工作日内 飞书 wiki 对接方案模板 对接方案（飞书 wiki 对接目录，链接贴回工单） 🔧+🤖
4 评审定版：文档评论或 30～60 分钟对齐会，逐项给结论，结论写进工单 双方负责人 + 架构裁决人 方案提交后 2 个工作日内 飞书文档 / 飞书会议 + 智能纪要 契约 v1（结论写进工单评论，方案文档标版本号） 👤人工判断
5 提供方先出 mock 和 OpenAPI，两边并行开发；接口文档由代码生成，放单一位置 提供方负责人 定版后 1 个工作日内 OpenAPI/Apifox + Gitea mock 地址与接口文档（Gitea/Apifox 单一位置，链接贴回工单） 🤖自动化
6 联调：按清单逐项核对（环境、域名、分支、client_id/secret、redirect URI、日志）；问题登记联调问题表 双方 按定版时排定的联调日期，单轮联调不超过 2 个工作日 多维表格联调问题表 联调记录与问题表（多维表格，每个问题有处理人与截止） 🔧+👤
7 归档：契约、配置说明、ADR、数据主责表更新；secret 走密码库，不发群 提供方负责人 联调通过后 1 个工作日内 飞书 wiki + 密码库 归档文档（飞书 wiki 对接目录）+ 工单关闭 🔧飞书固化
8 后续变更：提供方发版本说明并通知所有接入方；底座发版后机器人通知下游仓负责人并生成同步 PR 提供方负责人 变更合入当天 Gitea webhook + 机器人 变更通知（研发通知群 + 工单评论）、同步 PR（Gitea） 🤖自动化

5. 交付物与模板

  • 交付物：对接单、对接方案、契约与接口文档、数据主责表、联调问题表、外部对接责任矩阵与协议
  • 建议模板/表单：
    • 「跨组对接台账」：对接项、需求方/提供方及负责人、涉及系统、实体、状态（待评估/方案中/已定版/联调中/已上线）、截止、方案链接、契约版本、问题数
    • 对接方案模板：目标与阶段、边界图、数据主责表、接口清单（路径、方法、字段、示例、错误码、幂等）、时序图、鉴权、降级与缓存、环境与配置、SLA、责任人、兜底答疑人
    • 数据主责表：实体、唯一写入系统、读方、同步方式、标识口径（实例 ID/机器码/SN）
    • 外部对接附加：责任矩阵（开发、运维、客服、资金/坏账责任）、联调环境、问题升级人、协议
    • 联调清单：环境、域名、分支/版本、client 配置、secret 来源、回调地址、日志位置、测试账号

6. 异常与升级

  • 不知道提给谁 → 先登记对接台账，流程主责 1 个工作日内分派
  • 对接单超过 1 个工作日无人分派，或提供方超过 2 个工作日未给方案/联调回复 → 需求方在工单内 @ 流程主责（不另开群、不私聊）→ 再过 1 个工作日仍无响应升级 CTO
  • 提供方排不进 → 流程主责与产品协调优先级；2 个工作日没结论升级 CTO
  • 契约争议（谁做 OAuth、谁生成兑换券、谁定模型列表）→ 架构裁决人 1 个工作日内裁定
  • 联调现场发现分支或配置不对 → 当场记录，按联调清单逐项重核，并把遗漏项补进清单
  • 强实时依赖无降级 → 视为上线阻塞风险，书面提交，CTO 2 个工作日内定方案
  • 外部平台问题反复 → 约定对方问题升级人；涉及资金或责任先出法务风险报告，再签协议
  • secret、口令发到了群里 → 立即轮换
  • 下游仓门禁检查不过 → 下游负责人当天修复
  • 升级拍板（A（升级））：对接涉及系统边界、数据唯一写入方、降级方案，或跨产品线契约争议双方 1 个工作日内谈不拢 → 研发负责人（CTO）裁决；与外部平台对接涉及支付、运维、客服、坏账等责任边界 → 法务风险报告出具后报 CEO 拍板，再签协议

7. 衡量指标

  • 定版时长 = 提单到契约定版的工作日，目标 ≤ 5 天
  • 文档可得率 = 有单一来源接口文档的对接项 / 对接项总数，目标 100%
  • 联调问题数 = 每个对接项登记的联调问题数（观察指标）
  • 契约返工次数 = 因契约不清导致的返工次数，目标逐季下降
  • 数据主责覆盖率 = 已登记主责的多系统实体 / 多系统实体总数，目标 100%
  • 下游同步时延 = 底座发版到下游合并的天数，目标 ≤ 5 天

8. 低效诊断

  • 现象：接口文档、部署流程靠群里要，文档与实现不一致｜依据：「Leap产研测」2026-06、「开源聚变入驻问题沟通群」2026-03
  • 现象：三方对接中谁做 OAuth、谁生成兑换券、模型由谁定多轮反复，信息散在多个群｜依据：「New API Claw SKILL计划」2026-03
  • 现象：登录体系多次重做，配置项和 secret 在群里发，联调现场才发现网盘仍在旧分支｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • 现象：组件间协议（权限模型是否含资源）长篇争论未收敛，一方要等另一方先出版本才能动手｜依据：「⭐大模型基座事业群」2026-01
  • 现象：跨产品集成方案没吃透平台架构被要求重想，进度被反复追问｜依据：「工程咨询产研」2026-05、「工程咨询产研」2026-06
  • 现象：订单号格式来回改，多个系统写同一实体，充值订单唯一数据源存疑｜依据：「Leap产研决策部」2026-08、「渠道系统优化」2026-09
  • 现象：上下游强实时依赖缺少缓存和降级，谁提工单、提给谁不清｜依据：「Leap产研决策部」2026-09
  • 现象：需要开放平台配合的需求口头提、忘提单，工单优先级和截止无人负责，代码合并后环境迟迟不更新｜依据：「【行业版Leapcore】工程版」2026-08、「【行业版Leapcore】工程版」2026-10
  • 现象：外部平台登录、验证码问题来回多次，支付运维和客服责任不清｜依据：「平台部」2026-02
  • 现象：网关协议、环境变量等约定只在群里拍板，改完仍有服务按旧协议调用｜依据：「Leap产研测」2026-08
  • 现象：底座下游分仓同步冲突多，下游主干检查不过｜依据：「公司内FDE」2026-09、「公司内FDE」2026-10
  • 现象：订单、发票、分润的系统边界开会后结论未成文；产品边界和商城名称常被混淆｜依据：「LeapPay」2026-04、「LeapAll（Deprecated）」2026-04

9. 分支变体

  • 账号/登录：多产品统一走 LeapAuth OIDC，组织身份取目录成员的组织角色；公网/内网、service secret 方案按 ADR 执行
  • 计费网关：网关不负责主要计费；多个网关实例物理隔离、各自一套方案；不改网关源码，用 helper 代理
  • 订单/充值/余额：订单唯一来源；充值订单只由 LeapCore 写入，渠道系统通过平台 API 拉取；实例 ID 作为对齐标识，机器 ID 不参与；初始/赠送余额早期人工处理、后续自动化
  • 开放平台 × LeapCore：云端开放平台与企业本地微型开放平台；场景配置需缓存兜底；开放平台需求统一走工单收口到开放平台负责人
  • 底座 × 下游：LeapWorld 底座发版 → 推下游仓 → 业务代码 PR 合回；2026-10 起改为公司级 monorepo；业务项目要底座加字段走 Gitea 工单 + PR 链接，少改底座逻辑，要改用插件式
  • 外部平台（政府/合作方）：内部先对齐方案 → 法务风险报告 → 与对方开会确认接口 → 联调；支付、消费券核销责任必须书面约定
  • 跨产品线小程序互跳与账号绑定：账号、数据迁移、跳转、回滚四项写清；代码统一入 Gitea
  • 跨组索要代码/Skill：先填需求单说明目的和交付形式，代码外发需 CTO 授权
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-03（决策记录与发布）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 流程主责是否为 Leap 研发负责人？开放平台、FDE、渠道系统等跨部门对接由谁分派？
  • 对接台账放工单系统还是多维表格？
  • 数据主责表由谁维护？财务是否参与确认？
  • 接口文档统一由代码生成 OpenAPI 并链接到飞书 wiki，是否可行？
  • 外部平台对接的责任矩阵是否必须法务审核后才能开发？
  • 统一密码库由谁搭建和管理？
RND-19前后端接口变更、联调与废弃通知待优化120

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频5 × 耗3 × 跨2 × 险4

  • 适用场景：后端新增、修改、删除接口或字段，或一个功能同时涉及前端、后端、管理后台需要配套合并与联调时启动，直到前端完成对接、旧接口按兼容窗口下线为止
  • 负责人：主责——后端负责人（跃竞当前：王子明·推断待确认；工程咨询线当前：宋祺睿·推断待确认）；协同——前端负责人（跃竞小程序当前：魏小东·推断待确认；工程咨询线当前：季学森·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、跃竞产品经理（当前：陈雁·推断待确认）；兜底——各线负责人（跃竞当前：徐莉·推断待确认；工程咨询线当前：王皓南·推断待确认）
  • 核心流程：① 判定变更类型 → ② 同 PR 更新 Swagger 与对接文档 → ③ 登记变更清单并通知前端 → ④ 配套 PR 关联合并 → ⑤ 推测试服后通知联调 → ⑥ 联调问题表闭环 → ⑦ 破坏性变更锁步发布 → ⑧ 兼容窗口后废弃
  • 交付结果：更新后的 Swagger（以 dev 环境为准）和对接文档、接口变更清单条目、关联 PR、闭环的联调问题表、废弃接口下线记录
  • 状态依据：已有 Swagger（推测试服自动更新）、对接 md 文档、联调问题汇总、“代码调整”登记等习惯；但 2026-01～07 跃竞线接口追问约 100 次：缺字段、改名不通知、线上小程序在用的接口被删、全局标识改造让三端同时挂；工程咨询线出现“改了前端没改后端”、类型不一致导致助手整体不可用；“改接口要提前通知”只口头宣布过一次

1. 场景判定

  • 触发条件：后端新增接口或字段；修改字段名、类型、必填性、返回结构、分页；删除或重构接口；全局标识改造（如 uid、clubId）；功能需要前端 + 后端 + 管理后台配套合并；前端发现缺字段、404、参数错误
  • 典型说法：「改动接口的话，需要提前通知一下，小程序是有线上在正式用的」「有人改了前端没改后端」「是不是要搭配 pulls/55 合」「swagger也记得帮我更新」「只要是分页都需要返这个给我」「不知道用不用先deprecated」
  • 判断问题：改完以后，已上线或正在开发的前端、管理端、小程序会不会因为接口不一致而报错或拿不到数据？会就走本流程
  • 不归本流程管：跨团队/跨系统接口契约 → 请走 RND-18；数据库表结构变更与数据迁移 → 请走 RND-34；小程序提审发布 → 请走 RND-60；测试环境部署与更新通知 → 请走 RND-49；删改或关停用户可见功能的评审 → 请走 RND-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
后端开发 改接口，更新 Swagger 和文档，登记变更，通知前端 R 后端研发（跃竞当前：张楠、林瑾鸿、蒋兴武·推断待确认）
接口审批 破坏性变更审批，定兼容策略和发布节奏 A 后端负责人（跃竞当前：王子明·推断待确认；工程咨询线当前：宋祺睿·推断待确认）
前端开发 对接接口，登记联调问题 R 前端研发（跃竞会员端当前：郝智豪；管理端：陈真炎；星域：魏小东；工程咨询线：季学森、侯怡辰、徐鑫宇·推断待确认）
变更登记 维护“代码调整/接口变更”登记 R 后端研发（当前：王雨·推断待确认）
产品 裁决字段语义，宣布接口规则 C 跃竞产品经理（当前：陈雁·推断待确认）
测试 联调验证、回归 R 跃竞测试负责人（当前：赵伟龙·推断待确认）
兜底 跨端发布冲突与争议裁决 A（升级） 跃竞负责人（当前：徐莉·推断待确认）；Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 变更类型：新增 / 非破坏修改 / 破坏性修改（改名、改类型、可选变必填、删除、外层包装）
  • 影响端清单：网页管理端、会员端小程序、星域、仍在线的旧版小程序、Agent 与管理后台
  • 接口路径、示例 JSON、字段说明、状态枚举
  • 配套 PR 编号（前端 / 后端 / 管理后台）
  • 线上版本是否还在调用旧接口（查调用日志）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定变更类型；破坏性变更先在需求评审会或项目群公示，并经后端负责人审批 后端开发 动手前 工单 变更类型与审批 👤人工判断
2 在同一个 PR 里更新 Swagger 注解和对接文档（字段清单、示例、枚举、分页总数、公共参数） 后端开发 随代码提交 Swagger + 对接文档模板 对接文档 🔧+🤖
3 登记接口变更清单并 @相关前端 后端开发 merge 当天 多维表格「接口变更清单」+ 机器人 变更通知 🔧+🤖
4 配套 PR 互相关联，标明“需搭配合并”、是否需数据迁移、是否需同步管理后台 schema；同批合并 前后端开发 合并前 Gitea PR 模板 关联 PR 🔧+👤
5 推测试服，确认 Swagger 已更新后再通知前端联调 后端开发 推送后 30 分钟内 测试服 + 群通知 联调通知 🔧飞书固化
6 联调前用 AI 比对 Swagger 与前端调用字段，输出缺口 前端开发 联调开始前 AI 脚本 缺口清单 🤖自动化
7 联调问题统一登记联调问题表（接口、问题、责任人、状态），后端按表修复后推测试服并回填 前端、后端 问题 1 个工作日内响应 多维表格 闭环问题表 🔧+👤
8 破坏性变更锁步发布：前后端同一发布窗口上线；旧客户端仍在用的，新旧接口并行 后端负责人 发布日 发布单 发布记录 👤人工判断
9 废弃：先在 Swagger 标 deprecated 并通知，至少保留一个版本窗口（或等旧版客户端下线）再删除；删除前再通知一次 后端开发 兼容窗口结束时 Swagger + 变更清单 下线记录 🔧飞书固化

5. 交付物与模板

  • 交付物：Swagger 与对接文档、接口变更清单、关联 PR、联调问题表、下线记录
  • 建议模板/表单：
    • 「接口变更清单」：日期、接口、变更类型、是否破坏性、影响端、配套 PR、前端负责人、联调状态、兼容截止日、下线日期
    • 对接文档模板：接口路径、方法、参数（必填/类型）、返回示例、字段含义、枚举、分页、错误码、变更历史
    • 联调问题表：接口、现象、请求/响应样例、责任人、状态、修复版本、确认人
    • 接口公共规范：分页必返总数；公共参数（如 clubId）的传法；命名风格；弃用标注方式；v1/v2 并行规则

6. 异常与升级

  • 前端发现接口被删或 404 → 后端 2 小时内恢复或兼容；线上用户受影响按 RND-75 故障处理
  • 字段改名未通知导致联调失败 → 后端当天补兼容并登记；同类问题 2 次以上纳入 RND-12 评级
  • Swagger 没更新、测试服推了没生效 → 后端 30 分钟内确认部署状态并回复
  • 字段语义有分歧 → 产品经理 1 个工作日内裁决
  • 旧版小程序仍在用旧接口 → 后端保留兼容，下线时间由产品确认
  • 破坏性变更做不到锁步发布 → 推迟发布，升级后端负责人
  • 升级拍板（A（升级））：前端、后端、管理后台之间发布节奏冲突，或后端负责人与前端/产品对兼容策略 1 个工作日内达不成一致 → 升级各线负责人（跃竞：跃竞负责人；工程咨询线：Leap 研发负责人）当天裁决

7. 衡量指标

  • 变更登记率 = 登记的接口变更 / 实际接口变更（抽查 PR），目标 ≥ 95%
  • 无通知破坏性变更次数，目标 0
  • 联调问题平均关闭时长 ≤ 1 个工作日
  • 缺字段类联调问题数（每个功能），目标逐月下降
  • 接口不兼容导致的线上故障次数，目标 0

8. 低效诊断

  • 现象：后端改版而前端还没开始对接，测试先报功能不可用；全局标识改造后网页、小程序同时挂，测试没测出来｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-04
  • 现象：接口字段变更靠群里贴代码，旧接口没文档，前端不知道老接口是否还在用｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-06
  • 现象：缺字段（图标、总数、头像等）反复追问，字段改名不通知，Swagger 未更新、测试服推送不生效多次｜依据：「跃玩remote工作组」2026-05、「跃玩remote工作组」2026-06
  • 现象：线上小程序在用的接口被删，事后才宣布“改接口要提前通知”；可选字段变必填需要锁步发布｜依据：「跃玩remote工作组」2026-05、「跃玩remote工作组」2026-07
  • 现象：改了前端没改后端导致报错，类型对不上让助手整体挂掉；两边各写一套聊天组件｜依据：「工程咨询产研」2026-02

9. 分支变体

  • 跃竞：管理端、会员端小程序、星域三端，公共参数传法曾不统一；v1 → v2 接口并行；旧版小程序需后端兼容
  • 工程咨询/字字可研：前端 + agent 后端 + 管理后台三处配套；agent schema 变更按约定命令同步管理后台，并更新字段含义和提示词文档
  • 变更三类：新增必填字段（客户端兼容）、字段改名、删除接口，分别按步骤 8、9 处理
  • 数据库字段变更 → 同时走 RND-34

10. 待确认问题

  • 各条线的后端负责人分别是谁？跃竞的破坏性变更是否都由后端负责人审批？
  • 兼容窗口定为“至少一个版本”还是固定天数？
  • 接口变更清单用多维表格人工登记，还是用 Swagger diff 机器人自动生成？由谁搭建？
  • 联调问题表是否统一模板、跨项目使用？
  • Swagger 以 dev 环境为准，生产环境的接口文档怎么管理？
RND-20Agent 安全与权限控制设计待新建240

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：自研或开源 Agent（LeapAgent、LeapAll 客户端、龙虾/OpenClaw、赛马 Agent）新增或变更命令执行、文件/存储访问、远控能力，或设计内部服务鉴权时，先过安全基线评审和安全测试，再发版
  • 负责人：主责——Agent 核心研发（当前：岳阳·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、安全攻防测试（当前：王皓南、邓乾·推断待确认）、基座网关/鉴权研发（当前：望政韬·推断待确认）、架构安全评审（当前：陈晖·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 安全需求登记定级 → ② 对照安全基线出方案 → ③ 安全评审定范围 → ④ 实现并提 PR → ⑤ 红队用例测试 → ⑥ 产品验收与免责文案 → ⑦ 发版门禁与审计留痕
  • 交付结果：通过评审的安全方案、已合并的 PR、红队测试报告、更新后的安全基线清单、用户协议免责条款
  • 状态依据：目前只有口头原则（限制工作目录、删除走回收站、网关剥离内部身份头）。危险命令拦截虽有 PR，但没有成文需求和测试基线。2026-01～09 有 5 个群反复讨论，多数措施是在外部出现“Agent 误删用户文件”案例或内部攻防拿到 token 后才补上的

1. 场景判定

  • 触发条件：
    • Agent 新增或变更 shell 执行、文件读写/删除、远控本地电脑、网盘挂载、skill 调用等能力
    • 测试或攻防发现越权读写、高危命令无需确认就能执行、token/配置文件可读、skill 注入
    • 设计网关、Auth、RBAC，或调整内部服务之间的身份传递方式
    • 面向政务或企业客户宣讲“可信可控”，需要拿出可演示的安全能力
  • 典型说法：「执行前是不是得加授权」「高危命令不审批也是预期行为吗」「agent 以为文件改了，实际没改」「网关查到外部带进来的内部身份头直接移除」「能不能扫一下审计日志」
  • 判断问题：这个能力或设计会不会让 Agent 或外部请求，在用户不知情时删除、修改、外传数据，或拿到超出授权的身份？会，就走本流程
  • 不归本流程管：普通功能缺陷 → 请走 RND-03（缺陷提报、复现、分级与指派）；服务器、安全组、云资源开通 → 请走 RND-23；代码仓库权限 → 请走 RND-22；AI 工具账号封号风控 → 请走 RND-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发现人 发现安全问题并登记安全需求 R 测试/研发成员
Agent 核心研发 出安全方案，实现拦截/授权/隔离，提 PR R Agent 核心研发（当前：岳阳·推断待确认）
产品总监 定拦截范围和授权体验的取舍，产品验收 A 产品总监（当前：杨萌·推断待确认）
测试 设计安全用例，执行红队测试，提单 R 测试负责人（当前：张东郅·推断待确认）；测试（当前：黄霆瑄、潘浩伟·推断待确认）
安全攻防/评审 攻防演练，评审拦截范围 C 研发负责人（当前：王皓南·推断待确认）；FDE 研发（当前：邓乾·推断待确认）；模型网关研发（当前：柯逸飞·推断待确认）
网关/鉴权研发 制定并落实内部服务鉴权基线 R（鉴权分支） 基座研发负责人（当前：望政韬·推断待确认）
架构安全评审 评审鉴权方案，提示已知漏洞案例 C 基座组架构负责人（当前：陈晖·推断待确认）
产品文案 编写授权提示和免责说明文案 R（文案） 产品/运营（当前：杨黔昆·推断待确认）
法务 审核用户协议免责条款和对外安全承诺 C 法务负责人（当前：李瑶·推断待确认）
发版负责人 执行发版门禁，确认安全用例全部通过 R 研发负责人（当前：王皓南·推断待确认）
CTO 定安全底线；范围争议升级后拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 能力说明：新增或变更的执行面（tools 调用还是 shell 执行）、可访问的路径和存储、是否支持远控
  • 风险场景清单：可能导致误删、越权读写、外传、注入的路径，以及已发生过的同类案例
  • 现行安全基线清单版本：工作目录白名单、删除走回收站、授权分级、危险命令清单、内部身份头剥离
  • 关联的工单号/需求号、待评审 PR 的链接
  • 部署形态：toB 内网、公网/toC、政务客户

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记安全需求并定级：数据可能被删除或外传定 P0，越权读定 P1，只缺提示的定 P2 发现人（测试/研发） 发现当天 工单系统 安全需求单 🔧飞书固化
2 对照安全基线出方案：权限分级、危险命令判定规则、目录白名单、回收站、审计日志 Agent 核心研发 P0 在 2 个工作日内，P1 在 5 个工作日内 方案文档 安全方案 👤人工判断
3 安全评审：确定拦截范围（只拦删除类还是拦全部高危命令）、授权粒度和对体验的影响 产品总监、安全攻防、CTO 方案提交后 1 个工作日内 评审会/文档评论 评审结论（范围、优先级） 👤人工判断
4 实现方案并提 PR，附危险命令清单和自测结果 Agent 核心研发 按排期 Gitea PR PR + 自测记录 🤖自动化（AI 预评审）
5 执行红队用例：危险命令集、越权路径、token/配置读取、skill 注入、向无权限存储写入 测试 提测后 2 个工作日内 安全用例库 / CI 安全测试报告 🔧+🤖
6 产品验收；同步更新授权提示和用户协议免责条款 产品总监、法务 测试通过后 1 个工作日内 飞书文档 验收记录、协议更新 👤人工判断
7 发版门禁：安全用例全部通过才能发版；每次拦截都写入审计日志 发版负责人 发版前 CI / 发版闸门 门禁记录、审计日志 🔧+🤖
8 更新安全基线清单和用例库，并在研发群通报 Agent 核心研发 发版后 2 个工作日内 知识库 新版基线清单 🔧飞书固化

5. 交付物与模板

  • 交付物：安全需求单、安全方案、评审结论、PR、安全测试报告、审计日志样例、更新后的安全基线清单、用户协议免责条款
  • 建议模板/表单：
    • 安全需求单：编号、能力模块、风险类型（误删/越权读/越权写/外传/注入/鉴权绕过）、等级、复现步骤、影响范围、发现人、期望处理时限
    • Agent 安全基线清单：工作目录白名单、删除走回收站、授权分级（自动允许/询问/禁止）、危险命令清单（删除重要目录、强制删除、格式化分区等）、远控开关、切换到完全访问模式时的提示、审计日志字段
    • 内部服务鉴权基线：外部请求一律先过网关验签；网关剥离外部传入的内部身份头；请求头按白名单放行；业务服务不直接暴露公网；API Key 单独求解权限；鉴权放在上层业务，RAG 等下游只接收过滤条件

6. 异常与升级

  • 测试中真实数据被删或客户机器受损 → 立即停用相关能力并保留现场 → 1 小时内升级 CTO
  • 安全与好用之间的范围争议超过 1 个工作日未收敛 → 产品总监拍板；仍有分歧时当天升级 CTO，由 CTO 作最终决定（CTO 为 A（升级））
  • 根因在第三方组件（如网盘挂载、开源 Agent 白名单失效）→ 作为技术方案评审项处理，2 个工作日内在“改组件/上层补丁/接受风险”中给出结论 → 报 CTO 确认
  • 对外宣讲涉及安全承诺，但相关能力未经验证 → 暂停对外表述，宣讲前 2 个工作日升级 CTO 和法务

7. 衡量指标

  • 安全用例通过率 = 发版前通过的安全用例数 / 安全用例总数，目标 100%
  • P0 安全需求闭环周期 = 从登记到发版的自然日，目标 ≤ 7 天
  • 事后补流程次数 = 每季度由外部案例或事故触发的安全需求数，目标逐季下降
  • 安全议题进入工单的比例 = 已登记工单的安全议题 / 群聊中出现的安全议题，目标 100%

8. 低效诊断

  • 现象：执行授权、危险命令拦截都是在外部误删案例或“系统被删干净”之后才补做，需求登记环节缺失｜依据：「Leap产研测」2026-05、「Leap产研测」2026-08
  • 现象：危险命令拦截范围靠聊天确认，安全优先级有争议，评审环节没有成文需求和测试基线｜依据：「Leap产研测」2026-08
  • 现象：存储权限异常先按体验缺陷验收，不通过后才追到挂载层根因，缺少“体验缺陷 → 技术方案评审”的升级路径｜依据：「Leap产研测」2026-09
  • 现象：内部身份头是透传还是转换，当场争论未收敛，安全约束只存在于对话中｜依据：「⭐大模型基座事业群」2026-01
  • 现象：同一安全议题在布道群和开发群重复讨论，容器隔离与 bash 沙箱孰优孰劣一直没有定论｜依据：「Claw布道/案例组」2026-03
  • 现象：开源 Agent 的命令白名单和官方授权机制被测出失效，最后只能补免责声明｜依据：「LeapAll」2026-04、「leapagent赛马」2026-04

9. 分支变体

  • LeapAgent 危险命令：判定为危险就拦截，不提供“仍要执行”；远控本地电脑加开关；切换到完全访问模式时加提示
  • tools 调用与 shell 执行：tools 层可以逐项授权；shell 层以危险命令清单加工作目录限制为主
  • 网盘挂载存储：无权限时必须明确报错，不能出现“缓存改了、实际没改”；读取 I/O 错误和编辑假成功分别建用例
  • 内部服务鉴权：toB 内网部署按网关基线执行；将来上公网或做 toC，需另做 OAuth 架构评审
  • 政务龙虾/ClawLite：高危函数经 broker 拦截或询问；做用户隔离；配置文件对 workspace 不可见；审计日志可追溯；对外材料需经 CTO 确认
  • 开源 Agent（OpenClaw、赛马 Agent）：默认只允许访问工作区，上线前必须跑完安全测试 checklist

10. 待确认问题

  • 主责是否定为 Agent 核心研发？LeapAgent、LeapAll、龙虾是否各设一名安全 owner？
  • 是否设专职安全评审岗（X-SEC），还是由 CTO 兼任？
  • P0/P1/P2 的分级口径和时限（P0 方案 2 个工作日）是否可行？
  • 被拦截的危险命令是否允许用户手动放行？如允许，是否需要二次确认并记审计？
  • 红队用例库放在哪个仓库？是否接入 CI 作为发版硬门禁？
  • 用户协议免责条款由法务起草还是产品起草？
RND-21新成员研发账号开通与开发环境搭建待优化108

状态：待优化｜证据：有证据（卡片 8 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：研发、测试、实习生入职，或在职成员加入新项目时，在到岗首日内开通账号权限、跑通本地或开发服环境，并完成首周上手任务
  • 负责人：主责——用人项目技术负责人（当前：Leap 线王皓南、跃竞线王子明·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、带教人（当前：岳阳、杨云峰、游家豪·推断待确认）、前端负责人（当前：魏小东·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 到岗前提交开通清单 → ② 运维批量开通 → ③ 安全交付凭证 → ④ 指定带教人和模块边界 → ⑤ 按文档跑通环境 → ⑥ 完成首周任务并交付产出 → ⑦ 把新踩的坑补进 FAQ
  • 交付结果：开通清单全部勾选（权限到位）、环境跑通截图、首周上手文档、更新后的环境 FAQ
  • 状态依据：已有 docs/dev-setup.md、Deploy-Skill 仓库、AGENTS.md 索引、“运维-非实体资产”审批等零散载体，但没有统一的入组开通清单。2026-03～10 反复出现“有没有环境变量”“无权访问”“忘了开账号”，还有凭证明文发在群里

1. 场景判定

  • 触发条件：人事确认研发/测试/实习生的到岗日期；在职成员加入新项目或新仓库；成员首次需要在本地跑 LeapCore、LeapAuth、v5、LeapAll 等项目
  • 典型说法：「带新人把开发环境弄起来」「有没有环境变量」「来开个 git 账号」「群里讲下怎么跑 leapcore 吧」「无权访问」
  • 判断问题：此人是否第一次需要这个项目的仓库、内网、测试服或 AI 工具权限，或第一次在本地跑这个项目？是，就走本流程
  • 不归本流程管：单独建仓库或调整仓库归属 → 请走 RND-22；申请服务器、云资源、域名 → 请走 RND-23；AI 工具订阅、额度、补贴 → 请走 RND-25；人事入职手续 → 请走 HR-05（新员工入职准备与办理）；工位、办公电脑与领用 → 请走 ADM-03（新员工入职行政准备）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用人项目技术负责人 提交开通清单，指定带教人，划定模块边界，布置首周任务 A/R 用人项目技术负责人（当前：Leap 线王皓南、跃竞线王子明·推断待确认）
IT 运维 开通 VPN、服务器 SSH 公钥、测试服/开发服、监控和 CI 入口、数据库只读账号 R IT 运维（当前：杨明学·推断待确认）
Gitea 管理员 开通 Gitea 账号及组织/仓库权限 R Gitea 管理员（当前：宋祺睿·推断待确认）
带教人 指导环境搭建并答疑，带 Claude Code/Codex 入门 R 带教人（当前：岳阳、杨云峰、游家豪·推断待确认）
前端负责人 开测试服账号和小程序体验权限 R 前端负责人（当前：魏小东·推断待确认）
人事 到岗前 3 个工作日通知到岗信息 R/I 人事负责人（当前：黄莹·推断待确认）
新成员 按清单自检，跑通环境，产出上手文档 R 新成员
CTO 权限范围争议或开通人缺位升级后拍板、兜底 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 人事的到岗通知：姓名、岗位、所属项目、到岗日，是否为实习生或外部协作者
  • 新人的 SSH 公钥、Gitea 用户名、飞书账号
  • 所需权限清单：仓库（读/写）、VPN、测试服/开发服、数据库只读、监控/CI、飞书 wiki 空间、小程序体验版、Apifox、AI 工具
  • 项目环境文档链接：README、docs/dev-setup.md、Deploy-Skill、AGENTS.md 索引
  • 带教人、模块边界、首周任务

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起“研发入组开通”申请，勾选权限清单 用人项目技术负责人 到岗前 3 个工作日 飞书审批 + 多维表格 开通申请单 🔧飞书固化
2 开通 Gitea 账号和仓库/组织权限，按最小权限给 Gitea 管理员 申请后 1 个工作日内，且不晚于到岗前 Gitea 账号与权限 🤖+👤
3 开通 VPN、测试服/开发服 SSH、监控和 CI 入口、数据库只读账号 IT 运维 到岗前完成 VPN/服务器/监控/CI 权限开通记录 🔧+👤
4 通过密码管理工具或单独加密渠道交付凭证，首次登录强制改密；禁止在群里发明文 IT 运维 开通当天 密码管理工具 凭证交付记录 🔧飞书固化
5 开通飞书 wiki 空间、项目群、小程序体验版、Apifox 等协作权限 项目技术负责人 / 前端负责人 到岗首日 飞书 / 小程序后台 协作权限到位 🔧飞书固化
6 让 AI 读 README 和 CI 配置自动搭环境；重依赖项目优先连开发服验证，不在本地硬跑 新成员 + 带教人 到岗后 1 个工作日内跑通 dev-setup.md / Deploy-Skill / 开发服 环境跑通截图 🤖自动化
7 卡住超过 2 小时，按模板（环境、报错、已尝试的方法）在项目群提问；带教人 4 小时内响应 新成员 / 带教人 2 小时 / 4 小时 项目群 问题记录 👤人工判断
8 划定模块边界，布置首周任务（读代码并写现状文档，或修一个小单） 项目技术负责人 到岗首日 飞书任务 首周任务 🔧飞书固化
9 提交上手文档（代码现状、问题、环境踩坑）；带教人把新踩的坑补进 FAQ 新成员 + 带教人 到岗后 5 个工作日内 知识库 上手文档、FAQ 更新 🤖自动化
10 核对清单全部勾选后关闭申请；离组或离职时按同一清单回收权限 IT 运维 到岗后 2 个工作日内 / 离组当天 多维表格 关闭的开通单、回收记录 🔧飞书固化

5. 交付物与模板

  • 交付物：开通申请单（全部勾选）、凭证交付记录、环境跑通截图、首周上手文档、FAQ 更新
  • 建议模板/表单：
    • 研发入组开通单：姓名、岗位、项目、到岗日、带教人、Gitea 用户名、SSH 公钥、所需仓库及权限级别、VPN、测试服/开发服、数据库只读、监控/CI、飞书 wiki 空间、小程序体验版、Apifox、AI 工具（转 RND-25）、开通人、开通时间、回收时间
    • 仓库 README 环境章节（必填）：前置依赖及版本（bun、docker、electron、VS 等）、环境变量样例（不含真实密钥）、启动命令、开发服连接方式、常见报错 FAQ，并注明“开发模式下的性能表现不作为性能依据”
    • 环境版本查询：各环境当前部署版本一览，用页面或机器人提供

6. 异常与升级

  • 到岗当天账号未开通 → 项目技术负责人催 IT 运维 → 2 小时内仍未解决，升级 CTO
  • 权限范围有争议（如是否开写权限、生产数据只读权限）或开通人缺位超过 1 个工作日 → 项目技术负责人提交 CTO → CTO 当天拍板或指定替补开通人（CTO 为 A（升级））
  • 新人 1 个工作日跑不通环境 → 带教人远程协助 → 2 个工作日仍跑不通，按文档缺陷处理，由仓库负责人 3 个工作日内补齐文档
  • 发现凭证明文发在群里（外部群尤其要紧）→ 发现人通知 IT 运维 → 1 小时内重置凭证并撤回消息
  • 飞书 wiki 无权限 → 文档所有者 4 小时内授权，之后改为按空间成员授权
  • 开发模式下的卡顿被当作缺陷提单 → 测试负责人退回，引用“开发模式不作为性能依据”

7. 衡量指标

  • 账号就绪率 = 到岗当天权限全部到位的新人数 / 新人总数，目标 ≥ 90%
  • 环境跑通时长 = 从到岗到首次跑通环境的工作小时，目标 ≤ 8 小时
  • 环境重复提问数 = 每月群内同类环境问题被重复提问的次数，目标逐月下降
  • 凭证明文外发次数，目标 0

8. 低效诊断

  • 现象：仓库缺环境变量说明和 README，每个新人都要老员工手把手带｜依据：「Leap产研测」2026-05、「Leap产研测」2026-07
  • 现象：同一环境的版本信息被反复询问；从改代码到看到效果要约半小时，反馈太慢｜依据：「Leap产研测」2026-08
  • 现象：每个人各自踩 electron/ABI 等同类坑；开发模式下的卡顿被当作缺陷提单｜依据：「Leap产研测」2026-08
  • 现象：开账号靠在群里逐项点名，账号密码明文发在外部类型的群里；新人看 wiki 无权限，还要二次授权｜依据：「跃玩remote工作组」2026-04
  • 现象：新人到岗后工作安排不清，负责人要追问；AI 工具文档要向同事索要｜依据：「跃玩项目组」2026-03
  • 现象：服务器公钥、IP 在群里传递，权限由单人逐个配置，仓库权限也要逐个申请｜依据：「某客户专项群」2026-08、「渠道系统优化」2026-08
  • 现象：新人缺少模块边界和导师安排，任务全靠 @ 分派｜依据：「LeapPPT」2026-05

9. 分支变体

  • LeapCore/LeapAuth：依赖主板指纹和真实 Linux 环境，本地用虚拟机，或直接连开发服验证；开发服测通后再上测试服
  • v5 edge/cloud：按 docs/dev-setup.md 用 dev:edge 或 dev:all 启动，需配置 LEAPCORE_REPO、docker 和 host.docker.internal 解析
  • LeapAll/LeapLite/LeapAgent：让 AI 读仓库 CI 配置自动搭建；skill 打包使用相对路径
  • 跃竞（跃玩）前后端：另开 VPN、监控、CI 和小程序体验版；先读 AGENTS.md 索引和迭代需求文档；会员端新人先评估前人代码
  • 客户专项项目：开测试服/正式服 SSH 公钥权限；main 分支受保护，新人开新分支；服务器走“运维-非实体资产”审批
  • 实习生/外部协作者：只开所需仓库的最小权限；公司 Gitea 不对外部人员开放，必要时改用 GitHub 组织
  • 非研发新人（产品/运营/销售）：只开协作工具和 AI 工具，参加新员工演示培训

10. 待确认问题

  • 主责由用人项目技术负责人发起，还是统一由 IT 运维发起？人事能否在到岗前 3 个工作日通知研发？
  • “到岗当天权限全部到位”是否可行？Gitea、VPN、服务器的开通人各是谁，有没有备岗？
  • 公司是否已有密码管理工具？凭证交付渠道怎么约定？
  • 各仓库 README/环境文档的维护是否归仓库负责人？
  • 是否要建统一的开发机或“开发模式”（dev 分支自动推开发服），由谁建设？
  • 跃竞线沿用同一份清单，还是单独出一版？
RND-22代码仓库创建、归属与权限待优化72

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频4 × 耗2 × 跨3 × 险3

  • 适用场景：新项目或新组件需要建仓库、散落的仓库需要迁入公司组织、成员需要开通/变更/回收仓库权限时启动
  • 负责人：主责——Gitea 管理员（当前：宋祺睿、李铭熙·推断待确认）；协同——仓库负责人（当前：待指定，按仓库台账逐仓登记）、迁移规划（当前：陈晖·推断待确认）、CI/CD 基建（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交建库/权限申请 → ② 管理员核对命名与归属 → ③ 直接在组织下建库并授权 → ④ 登记仓库台账 → ⑤ 初始化 README、分支保护和 CI → ⑥ 定期复核并回收权限
  • 交付结果：建在公司 Gitea 组织下的仓库、仓库台账记录（用途/负责人/开发者）、按最小权限开通的访问权限
  • 状态依据：已有「Leap 仓库规范」台账和 LeapOrg/LeapInfra 组织，但建库和开权限仍靠在群里逐个 @。出现过仓库转让卡住、留下“幽灵仓库”，授权后 404 要重试，入职后忘开账号等问题，2026-01～09 反复发生

1. 场景判定

  • 触发条件：新项目、组件或脚手架启动；代码在个人账号或其他组织下，需要迁入公司组织；新人或协作者需要访问仓库；项目整合迁仓；成员离组
  • 典型说法：「我有组织的建库权限吗」「先建到自己名下再移交」「这个仓库给我开下权限」「404 not found」「最新的 repo 在哪」「置顶一个文档，写清每个仓库的负责人和开发者」
  • 判断问题：这件事会不会改变“某个仓库属于哪个组织、谁负责、谁能访问”？会，就走本流程
  • 不归本流程管：新人整体入组开通（含 VPN、服务器等）→ 请走 RND-21（其中仓库权限部分调用本流程）；PR 评审与合并 → 请走 RND-32（PR 提交与代码评审合并）；发版 → 请走 RND-51（正式版本发布上线）；服务器和域名 → 请走 RND-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 说明用途、命名、负责人和成员 R 研发成员
Gitea 管理员 建库、授权、管理组织、排查镜像同步问题 R Gitea 管理员（当前：宋祺睿、李铭熙·推断待确认）
仓库负责人 对单个仓库的内容、成员权限和 README 负责 R（单仓） 仓库负责人（当前：待指定，按仓库台账逐仓登记）
迁移规划 迁仓前出迁移方案 R（迁仓） 基座组架构负责人（当前：陈晖·推断待确认）
CI/CD 基建 接入 runner 和 CI C IT 运维（当前：杨明学·推断待确认）
测试/产品 通过台账把需求对应到仓库 I 测试负责人（当前：张东郅·推断待确认）；产品总监（当前：杨萌·推断待确认）
CTO 定组织结构和命名规范，拍板争议 A CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 仓库名称（按命名规范）、所属组织（Leap 产品类放 LeapOrg，基座类和项目类放 LeapInfra）、一句话用途
  • 仓库负责人、主要开发者名单及各自权限（读/写/管理）
  • 是否需要前后端分仓、submodule、单独的文档仓库
  • 迁仓时：原仓库地址、要保留的提交历史和分支、迁移方案
  • 申请权限时：Gitea 用户名、目标仓库、权限级别、使用期限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在“仓库/权限申请”表单提交建库、迁仓或授权申请 申请人 至少提前半个工作日 飞书表单/审批 申请单 🔧飞书固化
2 核对命名、组织归属，确认没有重复仓库 Gitea 管理员 申请后 4 个工作小时内 仓库台账 核对结论 👤人工判断
3 直接在组织下建库，授予仓库负责人管理权限；不走“先建个人仓库再转让” Gitea 管理员 核对后 1 个工作日内 Gitea 新仓库 🔧+👤
4 初始化仓库：README（用途、负责人、启动方式）、main 分支保护、分支命名约定、PR 模板、接入 CI 仓库负责人 + CI/CD 基建 建库后 2 个工作日内 Gitea / CI 初始化完成的仓库 🤖自动化
5 登记仓库台账：仓库、模块、代码范围、负责人、开发者、文档位置 Gitea 管理员 建库当天 多维表格，自动同步 leap-docs 台账记录 🔧+🤖
6 按最小权限开通访问权限并在申请单回执；申请人确认能访问后关单 Gitea 管理员 / 申请人 申请后 1 个工作日内 Gitea 权限开通记录 🔧+👤
7 迁仓：先出迁移方案（保留历史和分支、配置镜像同步），迁完通知新地址并归档旧仓库 迁移规划 + 仓库负责人 迁移前 2 个工作日出方案 Gitea 迁移方案、迁移记录 👤人工判断
8 每季度复核权限；成员离组或离职当天回收权限 Gitea 管理员 每季度末 / 离组当天 Gitea + 台账 复核与回收记录 🤖+👤

5. 交付物与模板

  • 交付物：仓库、仓库台账、README、权限开通/回收记录、迁移方案
  • 建议模板/表单：
    • 仓库/权限申请单：申请类型（建库/迁仓/授权/回收）、仓库名、组织、用途、负责人、成员及权限级别、期限、关联项目
    • 仓库台账：仓库、所属组织、对应模块、代码范围、负责人、主要开发者、文档位置、CI 状态、状态（活跃/归档）、更新时间
    • 提交与分支约定：分支命名为 feat/xxx、fix/xxx；commit message 写清改了什么（可让 AI 生成摘要），合并用 squash；客户定制代码放独立仓库或独立分支

6. 异常与升级

  • 仓库转让卡住、出现“幽灵仓库”→ 管理员清掉残留后直接在组织下重建 → 1 个工作日内仍未解决，升级 CTO
  • 授权后仍然 404 → 申请人在申请单反馈 → 管理员 2 小时内核查组织和团队权限
  • 镜像仓库同步失败 → 管理员先手动同步再排查 → 影响发版时当天升级 CI 负责人
  • 主线仓库不明确（存在多份副本）→ 仓库负责人 1 个工作日内确认唯一主线并在台账标注，其他副本归档
  • 外部人员申请公司 Gitea → 默认拒绝；确需协作的由 CTO 审批，按最小权限开通并设到期时间

7. 衡量指标

  • 权限开通周期 = 从申请到能访问的工作小时，目标 ≤ 8 小时
  • 台账覆盖率 = 已登记仓库数 / 组织下仓库总数，目标 100%
  • 无负责人仓库数，目标 0
  • 离组权限回收及时率 = 离组当天完成回收的人数 / 离组人数，目标 100%

8. 低效诊断

  • 现象：产品线变多后仓库散落在个人账号和多个组织下，事后才集中整理，组织命名也改了几次｜依据：「Leap产研测」2026-05
  • 现象：申请人不知道谁有建库权限，先建个人仓库再转让，失败后只能重建｜依据：「Leap产研测」2026-05
  • 现象：新仓库建好后成员访问 404，要逐个加权限，同一个地址被反复转发｜依据：「LeapCore（archived）」2026-03
  • 现象：迁仓时目录结构对不上，只能重建；提交信息不规范，出问题难回滚｜依据：「跃迁基座项目交付沟通」2026-02
  • 现象：最新仓库在哪要反复问，权限一个一个开｜依据：「跃迁基座项目交付沟通」2026-03、「跃迁基座项目交付沟通」2026-06
  • 现象：建库后评审靠在群里 @，没有评审清单，CI/CD 迟迟没搭好｜依据：「⭐大模型基座事业群」2026-01
  • 现象：新人入职后忘了开 Gitea 账号，开权限要靠点名｜依据：「TeamDNA」2026-03、「LeapVPN网络预研」2026-08

9. 分支变体

  • Leap 系列产品代码放 LeapOrg 组织；基座类和项目制客户代码放 LeapInfra 组织
  • 前后端分仓加文档仓库：前端用 submodule 引用；方案设计放文档仓库，里程碑放 wiki
  • GraphBase 二开或客户定制：主仓由基座负责人维护，定制代码放客户仓库；其他人 fork 或开 feat 分支开发
  • Demo 型项目可以弱评审；交付型项目必须开分支保护，并有单测和 CI
  • 外部协作者：使用 GitHub 组织或受限账号，不进公司 Gitea

10. 待确认问题

  • Gitea 管理员到底是谁（现在有好几个人在开权限）？是否设 A/B 角？
  • LeapOrg / LeapInfra 的组织划分是否就是最终口径？项目制客户代码放在哪？
  • 权限申请走飞书审批，还是多维表格加机器人就够？
  • 每季度复核权限是否可行？由谁执行？
  • 是否强制所有仓库接入 CI 并开分支保护？
RND-23开发测试服务器/云资源/域名申请待新建192

状态：待新建｜证据：有证据（卡片 15 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：研发、测试或业务需要虚拟机、裸机、云服务器、数据库、对象存储、域名解析、端口/安全组、短信/邮件/内容审核等云服务或测试设备时，统一申请、开通、登记，到期时续费或释放
  • 负责人：主责——Agent Infra Owner（当前：宋祺睿·推断待确认）；协同——IT 运维（负责内网、机房、采购、云账号，当前：杨明学·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 查资源台账和能力目录 → ② 提交资源申请 → ③ 选型与审批 → ④ 开通并安全交付 → ⑤ 登记台账 → ⑥ 到期提醒 → ⑦ 续费或释放
  • 交付结果：可用的资源（含访问方式）、资源台账记录（用途/负责人/到期日/是否常驻/成本归属）、审批单、月度资源与成本报告
  • 状态依据：只有部分资源走“运维-非实体资产”审批，或登记在 KVM 宿主机需求登记表里，大多数资源靠群聊或私下找人开通，没有统一台账。2026-04 演示机按量计费到期被自动释放，演示只能取消；2026-05 险些误删宿主机上的服务；群里已有人明确提出“该写资源申请 SOP 了”

1. 场景判定

  • 触发条件：需要新机器、加内存、普通算力；部署内部服务需要域名或端口；产品要接 COS、短信、邮件、内容审核或 Access Key；需要 Mac mini/Windows 测试机；资源到期或闲置
  • 典型说法：「给我开台虚拟机」「我能蹭资源吗」「有空开个域名吗」「开个存储桶，再分配一下权限」「公司有邮箱服务器吗」「服务器是不是被自动释放了」「真得同步下服务器使用情况」
  • 判断问题：是否需要公司出钱，或要占用公司共享的机器、云账号、域名、通道？是，就走本流程
  • 不归本流程管：GPU 显卡租用或采购 → 请走 RND-24；AI 编码工具账号与额度 → 请走 RND-25；客户现场或客户内网服务器部署 → 请走 X-DLV-19（客户现场/远程部署实施）；Gitea 仓库权限 → 请走 RND-22；办公电脑等固定资产 → 请走 ADM-24（IT 设备与研发硬件采购申请）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填写用途、规格、期限、负责人；到期确认续用或释放 R 研发/测试/业务成员
Agent Infra Owner 选型；开通云资源、域名解析、短信模板和子账号；维护台账 R Agent Infra Owner（当前：宋祺睿·推断待确认）
IT 运维 管内网虚机、裸机、KVM，负责采购下单、云账号与 Access Key、网络 R IT 运维（当前：杨明学·推断待确认）
研发负责人 审批标准规格申请的用途和规格是否合理 A 研发负责人（当前：王皓南·推断待确认）
CTO 审批新增采购和超标准规格；管理云主账号和域名 A（升级） CTO（当前：丁震宇·推断待确认）
财务 费用入账、按项目归集成本 C/I 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 先查资源台账和“公司基础服务能力目录”（邮件 SMTP、短信验证码、COS、域名、开发服），能复用就不新开
  • 用途、所属项目/产品、使用人、预计期限、是否常驻（演示机必须常驻）
  • 规格：CPU/内存/磁盘、地域（境内或境外节点）、网络（内网或公网）；域名前缀和解析目标；端口和安全组规则
  • 预算和成本归属（项目/部门）
  • 是否对外部人员开放，开放的话需要什么鉴权

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 查台账和能力目录，确认有没有能复用的资源 申请人 提申请前 多维表格 复用结论 🔧飞书固化
2 提交“研发资源申请”：类型、规格、用途、期限、是否常驻、成本归属 申请人 至少提前 2 个工作日，紧急的要注明 飞书审批 申请单 🔧飞书固化
3 按标准规格清单选型（虚机/KVM/裸机/轻量/CVM/静态托管），选有折扣的型号 Agent Infra Owner / IT 运维 申请后 4 个工作小时内 标准规格清单 选型方案 👤人工判断
4 审批：标准规格且用现有资源的，由研发负责人批；要新采购或超标准的，由 CTO 批 研发负责人 / CTO 1 个工作日内 飞书审批 审批结论 🔧飞书固化
5 开通机器、域名、端口、存储、短信模板或子账号；演示机一律包月常驻，不设自动到期 Agent Infra Owner / IT 运维 审批后 1 个工作日内；需采购的以到货为准 云控制台 / 虚拟化平台 开通的资源 🤖+👤
6 安全交付：访问方式写在申请单回执里，SSH 用公钥，Access Key 用最小权限子账号并经密码管理工具交付 开通人 开通当天 审批回执 / 密码管理工具 交付记录 🔧飞书固化
7 登记台账（资源 ID、用途、负责人、到期日、是否常驻、成本归属、安全组），并给云资源打标签 开通人 开通当天 多维表格 / 云标签 台账记录 🔧+🤖
8 上线前复查安全组和公网暴露面 申请人 + 开通人 上线前 云控制台 复查记录 👤人工判断
9 到期前 7 天机器人提醒使用人确认续用或释放；3 个工作日无回复的，先关机并留快照 机器人 / 开通人 到期前 7 天 飞书机器人 续费或释放记录 🤖自动化
10 月度盘点闲置资源和成本，回收闲置资源并通报 Agent Infra Owner 每月第一周 云账单 + 台账 月度资源报告 🔧+🤖

5. 交付物与模板

  • 交付物：审批单、开通的资源、台账记录、月度资源与成本报告
  • 建议模板/表单：
    • 研发资源申请单：资源类型（虚机/KVM/裸机/云服务器/数据库/对象存储/域名解析/端口安全组/短信模板/邮件/内容审核/测试设备）、规格、地域、用途、项目、使用人、期限、是否常驻、是否对外开放、成本归属、紧急程度
    • 资源台账：资源 ID、所属云账号或宿主机、类型规格、用途、负责人、使用人、开通日、到期日、是否常驻、计费方式、月成本、安全组、状态（在用/闲置/已释放）
    • 标准规格清单：开发虚机、测试机、演示机（按产品的最低配置档位）、静态站点、个人工具云服务器的推荐型号和折扣型号
    • 公司基础服务能力目录：邮件 SMTP（含每日发送上限）、短信验证码模板、COS、内容审核、域名、开发服，每项写明负责人和申请入口

6. 异常与升级

  • 演示或生产相关机器被释放或宕机 → 开通人立即用快照/镜像重建，1 小时内通知使用方 → 影响客户演示的，同时升级 CTO
  • 宿主机资源满或内存爆掉、没人认领 → Infra Owner 按台账找负责人 → 2 小时内仍无人认领的进程先停掉，并在研发群通报
  • 要重启共享的宿主机或虚拟机 → 至少提前 30 分钟通知台账上的全部使用人
  • 申请需要新采购、超出标准规格或涉及云主账号/生产域名 → 研发负责人审核后转 CTO 审批（1 个工作日内，CTO 为 A（升级））；对公付款请走 FIN-01
  • 采购审批超过 2 个工作日未批 → IT 运维催办 → 仍未批的升级 CTO
  • Access Key 或密码出现在群聊里 → 1 小时内轮换密钥并撤回消息
  • 客户临时要测试服务器 → 先控制规模，书面说明承载上限 → 升级研发负责人

7. 衡量指标

  • 资源开通周期 = 从审批通过到交付的工作小时，目标 ≤ 8 小时（需采购的除外）
  • 台账覆盖率 = 台账已登记的资源 / 云账单和宿主机上的实际资源，目标 100%
  • 意外释放/误删事件数，目标 0
  • 闲置资源成本占比 = 30 天内无使用的资源成本 / 资源总成本，目标 ≤ 10%
  • 凭证明文流转次数，目标 0

8. 低效诊断

  • 现象：资源申请靠在群里 @ 个人，每次都要临时问“开什么、谁来开”，没有统一规格｜依据：「鼎慧产研决策部」2026-05
  • 现象：按量计费的演示机到期被自动释放，回收站是空的，演示只能取消｜依据：「LeapCore（archived）」2026-04
  • 现象：服务器使用情况没有同步，差点误删宿主机上别人的服务；域名归属“没人定”｜依据：「鼎慧产研决策部」2026-05
  • 现象：服务器口头借用后归属记不清，最后又另买一台｜依据：「鼎慧产研决策部」2026-03
  • 现象：Access Key 和账号密码在聊天里传，哪个云账号归谁管还要追问｜依据：「跃迁AI总动员」2026-05
  • 现象：虚拟机资源满了、谁在用都要在群里问，内存爆掉也没人认领｜依据：「Leap产研测」2026-09
  • 现象：采购卡在审批，加内存“什么时候好”被反复催问｜依据：「Leap产研测」2026-06
  • 现象：需求方不知道公司已有邮件、短信能力，重复询问｜依据：「跃迁AI总动员」2026-09
  • 现象：内网服务器、CI/CD、网络问题都压在一个人身上，“加入待办”后没有排期｜依据：「⭐大模型基座事业群」2026-01、「⭐大模型基座事业群」2026-03
  • 现象：测试设备采购一直停留在讨论阶段，没有申请也没有结论｜依据：「跃迁AI总动员」2026-07

9. 分支变体

  • 内网虚机/KVM/裸机：先在 KVM 宿主机需求登记表登记，再对照资源预算表看剩余额度；在 KVM 独享和裸机共享之间二选一
  • 云服务器（云厂商 A/B）：轻量服务器适合个人工具和静态站，注意默认型号没有折扣；CVM 用于正式服务；境外节点用于海外服务
  • 演示机：包月常驻、不设到期，按产品最低配置档位开；释放前必须由演示方书面确认
  • 数据库：正式环境用托管数据库，账号由运维配置
  • 域名：在 DNS/EO 上加解析，使用指定的内部域名后缀；生产域名由研发负责人确定
  • 短信/邮件：短信模板提交平台审核（写明有效期）后，把模板 ID 和参数告诉后端；邮件用飞书 SMTP，注意每日发送上限
  • 测试设备（Mac mini/Windows/高内存工作站）：走研发设备采购审批，是否采购由管理层决定；研发网络独立组网单独立项

10. 待确认问题

  • 主责是否定为 Agent Infra Owner？和 IT 运维怎么分工（云资源 vs 内网/采购）？
  • 研发负责人审批和 CTO 审批的分界线（规格或费用阈值）定在哪？
  • 标准规格清单和演示机最低配置，是否由 Infra Owner 制定并发布？
  • 是否引入统一的密码/密钥管理工具？
  • 云主账号由谁持有？是否开子账号分权？
  • 资源成本是否按项目归集？财务需要哪些字段？
RND-24GPU 算力申请、租赁与采购待新建108

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：部署、微调、评测或测速模型需要 GPU 时，先盘点公司的闲置卡；不够再走小额租用或采购询价；用完按期释放
  • 负责人：主责——IT 运维（算力资源管理，当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、需求方研发、财务负责人（当前：黄梦婷·推断待确认）；审批与兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交算力申请 → ② 估算需求并盘点闲置卡 → ③ 内部分配，或转外部方案 → ④ 询价比价 → ⑤ 审批 → ⑥ 开通交付并登记 → ⑦ 到期释放或退租
  • 交付结果：分配到人的 GPU 资源（有台账记录）、询价记录、审批单、释放/退租记录
  • 状态依据：GPU 全靠在群里 @ 资源管理人口头分配，没有 GPU 台账。2026-01～10 出现过一台机器同时分给两个人、闲置卡“报了没人用”、租用只有口头批准、询价结果不归档要重问等问题

1. 场景判定

  • 触发条件：部署新模型体验或评测；模型转换或微调；推理性能实测；客户项目需要算力；租赁价格变动需要调整
  • 典型说法：「有没有 GPU 机器」「报需求，直接给你开」「盘一下，看够不够部署一个」「申请点钱租卡做测试」「有预算，下个月整」
  • 判断问题：是否要占用公司的显卡，或产生 GPU 租用/采购费用？是，就走本流程
  • 不归本流程管：普通 CPU 服务器、虚机、云资源 → 请走 RND-23；模型 API 额度 → 请走 RND-27；AI 编码工具 → 请走 RND-25 / RND-26；客户项目交付硬件 → 请走 X-DLV-02（硬件供应商选型、BOM 与采购补货）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求方 说明模型、显存、精度、并发和期限；用完确认释放 R 需求方研发
IT 运维 盘点、分配、开机、询价比价、下单、释放 R IT 运维（当前：杨明学·推断待确认）
部署测试 测试租用机器的网络和性能 C 运维/交付部署工程师（当前：游家豪·推断待确认）
CTO 拍板外租、采购和高价值卡的优先级，提供供应商渠道 A CTO（当前：丁震宇·推断待确认）
管理层 审批超出 CTO 权限的长期租赁或整机采购 A（升级） CEO（当前：邴龙志·推断待确认）
财务 付款，按项目归集预算 C/I 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 模型名称和参数量、精度（FP16/FP8/FP4）、所需显存和卡数、并发、使用期限
  • 用途（体验/评测/客户项目/微调）、关联项目和预算归属
  • 先用资源估算工具（如 llmfit）自估所需配置
  • 需要外租或采购的，至少准备 2 家报价，以及显存、互联、算力的对比

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写算力申请：模型、精度、卡型、卡数、期限、项目 需求方 至少提前 2 个工作日 飞书表单 申请单 🔧飞书固化
2 用估算工具核对需求是否合理，并盘点台账上的闲置卡 IT 运维 申请后 4 个工作小时内 GPU 台账 / 估算工具 盘点结论 🔧+🤖
3 内部有闲置卡：直接分配，在台账标注占用人和到期日，避免一卡多分 IT 运维 盘点后 1 个工作日内 GPU 台账 / 服务器 分配记录 🔧飞书固化
4 内部不够：询价比价（租还是买、英伟达还是国产卡），填写询价记录 IT 运维（CTO 提供渠道） 3 个工作日内 询价记录表 比价结论 👤人工判断
5 审批：小额临时租用由 CTO 在飞书审批；大额租赁或采购走采购审批，并绑定项目预算 CTO / 管理层 1 个工作日内 飞书审批 审批单 🔧飞书固化
6 下单或开机，测完网络和性能再交付，并登记台账 IT 运维 + 部署测试 租赁的审批后 1 个工作日内；采购的以到货为准 云平台 / 机房 交付记录 🔧+👤
7 使用期间每周自动上报利用率；连续 3 天低于阈值的提醒需求方 机器人 每周 监控脚本 利用率周报 🤖自动化
8 到期前 3 天提醒；需求方确认释放后，先备份数据再重置或退租 IT 运维 到期前 3 天 / 确认当天 台账 / 云平台 释放记录 🔧+🤖
9 测试类租用结束后提交结果小结，作为后续采购决策的依据 需求方 结束后 3 个工作日内 知识库 测试结果小结 👤人工判断

5. 交付物与模板

  • 交付物：算力申请单、GPU 台账记录、询价记录、审批单、利用率周报、释放/退租记录、测试结果小结
  • 建议模板/表单：
    • 算力申请单：申请人、项目、用途、模型及参数量、精度、所需显存/卡型/卡数、并发、开始日、期限、是否可共享
    • GPU 台账：卡型、数量、位置/平台、归属（自有/租赁）、占用人、项目、开始日、到期日、状态（空闲/占用/待释放）、月成本
    • 询价记录：供应商、卡型、显存、是否支持 FP8/FP4、互联方式、租期、报价、报价日期和有效期、能否开票、结论

6. 异常与升级

  • 同一资源分给了两个人 → IT 运维按台账登记先后为准，1 小时内另行安排并通知双方
  • 释放前没备份 → 释放必须先拿到需求方书面确认 → 发生误释放的，立即通报 CTO
  • 报价在有效期外 → 询价单按有效期作废，重新询价后再审批
  • 闲置卡“报了没人用”超过 7 天 → 收回重新分配，并通知原申请人
  • 资源管理人单点忙不过来，申请 1 个工作日无响应 → 升级 CTO 指定替补
  • 长期租赁或整机采购超出 CTO 审批权限（阈值待财务确认）→ CTO 审核后走采购审批（请走 FIN-01）→ 由管理层审批（管理层为 A（升级）），1 个工作日内给结论

7. 衡量指标

  • 申请响应时长 = 从提交到给出分配或外部方案的工作小时，目标 ≤ 8 小时
  • GPU 利用率 = 占用期间平均利用率，目标 ≥ 60%
  • 一卡多分事件数，目标 0
  • 询价归档率 = 已登记的询价次数 / 实际询价次数，目标 100%
  • 外租/采购费用留痕率 = 有审批单的费用笔数 / 总笔数，目标 100%

8. 低效诊断

  • 现象：分配不登记，一台机器分给了两个人；什么时候释放靠在群里提醒｜依据：「鼎慧产研决策部」2026-01
  • 现象：机器有没有人在用只能靠问，闲置卡“报了没人用”；盘点和调度都压在一个人身上｜依据：「模态AI探索小分队」2026-02、「模态AI探索小分队」2026-03
  • 现象：资源分配靠个人关系，个人显卡和公司服务器混着用，没有资源清单｜依据：「模态AI探索小分队」2026-04
  • 现象：临时租用的测试经费只有口头批准，没有单据｜依据：「某半导体客户项目群」2026-05
  • 现象：询价结果只在群里转述，价格两天就变，只能重新问｜依据：「某合作项目群」2026-08、「某合作项目群」2026-10
  • 现象：GPU 安排靠在群里点名，申请、审批、归还都没有记录｜依据：「AI工具跃迁交流群」2026-03

9. 分支变体

  • 内部闲置卡调配（如 5090）：直接在台账上分配，按期限回收
  • 云 GPU 临时租用（算力租赁平台 A 等，卡型如 H20、A100、4090）：走小额审批，用完立即释放，并提交测试结果
  • 长期租赁或采购（整机 8 卡/16 卡）：走询价比价加采购审批，绑定项目预算；退租旧卡要和新卡交付衔接上
  • 国产卡：比价时同时评估补贴申请，可行的与政策申报口对接
  • 研发个人设备的高内存选配：走 RND-23 中的测试设备采购

10. 待确认问题

  • 小额临时租用的审批阈值（[阈值待财务确认]）是多少？谁来批？
  • GPU 台账由谁维护？资源管理人是否需要替补？
  • 长期租赁是否必须绑定项目预算？由财务和谁共同审批？
  • 利用率阈值（60%）和闲置收回时限（7 天）是否合适？
  • 国产卡补贴申请是否由政策申报口对接？
RND-25AI 编码工具账号/订阅/额度申请发放待新建240

状态：待新建｜证据：有证据（卡片 18 张 / 会话 11 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：员工需要 Claude、Codex、Cursor 等 AI 编码工具的订阅、号池 key 或额度时（研发优先，非研发其次），以及额度耗尽、新人入职、离职回收、AI 补贴月度申报时
  • 负责人：主责——AI 资源管理员（号池/额度运维，当前：杨明学·推断待确认）；协同——研发负责人（审批，当前：王皓南·推断待确认）、入职工具配置（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 查可用渠道和本人资格 → ② 提交额度申请 → ③ 部门负责人审批 → ④ 从号池或公司订阅发放，或改走补贴自购 → ⑤ 登记台账 → ⑥ 用量监控与告警 → ⑦ 到期续用或回收
  • 交付结果：可用的个人子 key、席位或订阅（台账有记录）、审批单、月度用量报表、补贴核定结果
  • 状态依据：目前只有 AI 补贴核定规则讨论稿、个人自购防封攻略和号池后台，申请入口一直说不清（有人问“开 Codex 现在什么流程”，被推回“走报销”）。2026-01～10 反复出现 key 明文发群、公开 key 撤回重发、号池没人维护、额度半夜耗尽临时求助等情况

1. 场景判定

  • 触发条件：新研发入职；成员没有可用的 AI 编码工具或额度用完；号池有闲置额度要派发；测试或评测需要更高额度；补贴月度申报；人员离职或转岗
  • 典型说法：「公司开 codex 现在什么流程」「还没申请额度的来找我拿 key」「谁的 20x 用不完，借我用用」「能不能报销，报多少」「我现在其实啥都用不了」
  • 判断问题：要解决的是不是“个人使用 AI 编码工具需要的账号、额度或补贴”？是，就走本流程
  • 不归本流程管：渠道/号商/中转站选型、对公采购、号池维护交接、封号风控 → 请走 RND-26；研发调用统一接入站的模型 API Key 与额度 → 请走 RND-27；线上产品依赖的上游模型账户余额与 Token 消耗 → 请走 RND-73（上游账户余额、凭证到期与 Token 消耗管控）；GPU 算力 → 请走 RND-24；新人的其他账号 → 请走 RND-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 说明工具、用途、额度、周期；按月申报补贴 R 员工本人；实习生/外包由部门负责人代提
部门负责人 按标准档位审批额度 A 研发负责人（当前：王皓南·推断待确认）；非研发为各部门负责人（当前：待指定）
AI 资源管理员 从号池发 key、设额度、登记、回收、出用量报表、核定补贴 R AI 资源管理员（当前：杨明学·推断待确认）
入职工具配置 给新人装好 Claude Code/Codex，带入门 R 运维/交付部署工程师（当前：游家豪·推断待确认）
测试负责人 协调测试和评测所需的高额度 C 测试负责人（当前：张东郅·推断待确认）
产品总监 统筹 AI 补贴使用情况调研 C 产品总监（当前：杨萌·推断待确认）
人事 补贴发放，通知入离职 R（补贴） 人事负责人（当前：黄莹·推断待确认）
财务 报销和补贴入账 C 财务负责人（当前：黄梦婷·推断待确认）
CTO 定规则；超标准额度、评测经费和违规处理升级后拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 工具和档位（Codex/Claude Code/Cursor 等）、用途（日常编码/测试/评测/Benchmark）、预计月用量、使用周期
  • 本人类别：研发、非研发、实习生或外包
  • 是否已经领了 AI 补贴在自购（避免重复发放）
  • 评测类经费：评测计划、所用模型、预计 token 用量和费用

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 查《AI 工具使用指南》，确认可用渠道和本人资格（研发默认配齐，非研发分批开通） 申请人 申请前 知识库 资格确认 🔧飞书固化
2 提交“AI 工具账号/额度申请”；实习生和外包由部门负责人代提 申请人 至少提前 1 个工作日 飞书审批 申请单 🔧飞书固化
3 按标准档位审批；超出标准或申请评测经费的转 CTO 部门负责人 / CTO 4 个工作小时内 飞书审批 审批结论 👤人工判断
4 发放：在内部网关为个人生成独立子 key 并设上限，或分配席位，或告知按官方渠道走补贴自购 AI 资源管理员 审批后 1 个工作日内 内部 API 网关 / 号池后台 子 key、席位或自购指引 🤖+👤
5 凭证经密码管理工具或审批回执交付，禁止在群里发公开 key AI 资源管理员 发放当天 密码管理工具 交付记录 🔧飞书固化
6 登记台账：人员、工具、key/席位、额度、周期、到期日、费用来源 AI 资源管理员 发放当天 多维表格 台账记录 🔧飞书固化
7 新人入职首日配好 Claude Code/Codex 并完成入门；试用期内须能独立注册和使用 入职工具配置 到岗首日 入门文档 / 视频 配置完成记录 👤人工判断
8 按 key 统计周用量：到 80% 提醒本人，异常消耗告警管理员 机器人 实时 / 每周 网关用量 + 飞书机器人 用量报表 🤖自动化
9 走补贴自购的，每月底前提交付费截图和商家 Invoice；管理员核定合规支出 申请人 / AI 资源管理员 每月最后一个工作日前 / 次月 5 日前 飞书表单 补贴核定结果 🔧+🤖
10 到期前 7 天提醒续用；离职或转岗当天作废 key、回收席位；闲置额度在台账公示后派发 AI 资源管理员 到期前 7 天 / 当天 台账 + 机器人 回收与派发记录 🔧+🤖

5. 交付物与模板

  • 交付物：申请单、子 key/席位、台账记录、月度用量报表、补贴核定结果
  • 建议模板/表单：
    • AI 工具账号/额度申请单：申请人、类别（研发/非研发/实习/外包）、工具、档位、用途、预计月用量、周期、是否已领补贴、审批人
    • AI 额度台账：人员、部门、工具、发放方式（子 key/席位/补贴自购）、额度上限、开始日、到期日、费用来源、本月用量、状态（在用/到期/回收）
    • 《AI 工具使用指南》：可用工具和渠道清单、按任务类型推荐的默认模型和推理档位、额度重置规则、禁止事项（用低质量模型做测试、共享个人号、群发 key、使用未准入的中转站）
    • 补贴月度申报表：姓名、岗位类别、工具、套餐、付费截图、Invoice、所属月份、核定结果

6. 异常与升级

  • 申请超出标准档位或申请评测经费 → 部门负责人审核后转 CTO → CTO 4 个工作小时内审批（CTO 为 A（升级））
  • 额度耗尽影响工作 → 本人在申请单提“临时追加” → 管理员在工作时间 2 小时内处理，非工作时间由备岗处理
  • key 或账号口令出现在群聊里 → 1 小时内作废重发，并撤回消息
  • 违规使用（用低质量模型做测试、占用他人额度、使用未准入渠道）→ 第一次警告；再犯按补贴制度扣减，由 CTO 决定
  • 号池无人维护或管理员离岗 → CTO 1 个工作日内指定接手人，按 RND-26 交接
  • 补贴材料不合规（API 消费、非官方平台）→ 不计入核定，次月可以补正

7. 衡量指标

  • 发放周期 = 从提交申请到可用的工作小时，目标 ≤ 8 小时
  • 研发 AI 工具覆盖率 = 已配齐的研发人数 / 研发总人数，目标 100%
  • 明文 key 外发次数，目标 0
  • 台账一致率 = 台账记录 / 网关和号池里实际有效的 key 与席位，目标 100%
  • 人均月 AI 成本偏差 = |实际 − 预算| / 预算，目标 ≤ 10%

8. 低效诊断

  • 现象：申请入口不清楚，问流程被推给“走报销”｜依据：「跃迁基座许愿机」2026-05
  • 现象：给实习生补派额度要别人反复提醒才办；闲置额度靠在群里吆喝找人用｜依据：「跃迁基座许愿机」2026-05、「跃迁基座许愿机」2026-09
  • 现象：公司高档账号归谁管不清，个人使用规则没有成文，几十分钟就把限额烧完｜依据：「Leap产研测」2026-06
  • 现象：额度半夜耗尽临时求助，key 直接在群里转发｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：“全员可用”和报销口径都只是口头答复；负责充值的环节拖着，有人因此用不了工具｜依据：「鼎慧产研决策部」2026-03
  • 现象：先垫付再口头说“能报销”，账号口令在群里共享｜依据：「模态AI探索小分队」2026-02、「模态AI探索小分队」2026-03
  • 现象：各人自己买号，被封后自担损失；海外渠道开不了票，渠道建议互相矛盾｜依据：「鸽子群模态分群」2026-05、「鸽子群模态分群」2026-06
  • 现象：每个新人都要手工配置 AI 工具，补贴口径没有成文｜依据：「某合作项目群」2026-01、「某合作项目群」2026-02
  • 现象：测试额度要找人代充，批量加额度还得临时写脚本｜依据：「Leap产研测」2026-07
  • 现象：号池“没人维护”，重置卡到期没人提醒，评测经费没有申请表单｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-08
  • 现象：订阅申请、模型选择、违规处理都没有成文规则，是否该给已完成任务的人开订阅也有争议｜依据：「Leap产研决策部」2026-09

9. 分支变体

  • 研发：全员配齐 Claude 和 Codex，订阅走官方渠道；入门视频改为教注册和使用，试用期内必须掌握
  • 非研发：研发全员稳定后分批开通，可以先试用公共号池或 Claude Pro
  • 实习生/外包：由部门负责人代申请，只发号池子 key 并设上限，到期时间跟合同期走
  • 测试/评测：评测经费单独申请，CTO 审批，评测结束后提交结果
  • 补贴自购和公司号池：同一工具不重复发放；补贴按《公司 AI 补贴落实与核定规则》执行（当月合规支出达到补贴额度的 80% 才发放；API 消费和非官方平台套餐不计入；年付套餐由 IT 个案处理）
  • 子公司：参照本流程执行

10. 待确认问题

  • AI 资源管理员是谁？要不要设备岗？
  • 《AI 补贴落实与核定规则》讨论稿什么时候定稿？由 IT 核定还是人事核定？
  • 研发和非研发的标准档位、额度上限各是多少？
  • 号池子 key 和补贴自购能否同时享有？
  • 违规使用的认定和处罚口径是否写进制度？
  • 评测经费由 CTO 审批还是 CEO 审批？
RND-26AI 工具/中转渠道采购、号池运维与封号应对待新建400

状态：待新建｜证据：有证据（卡片 15 张 / 会话 9 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：官方渠道贵、易封号或中转不稳时，对 AI 模型渠道（官方订阅、企业版、云厂商、中转站、号商）做准入评估、对公采购付款、号池/网关运维交接与续费评估，以及处理账号被封、KYC、风控
  • 负责人：主责——AI 渠道与号池运维负责人（当前：杨明学·推断待确认）；协同——渠道评测（当前：王皓南、宋祺睿、魏宗浩·推断待确认）、内部 API 网关部署（当前：宋祺睿、吴世豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、信息安全（当前：待指定）、管理层（海外主体等重大事项，当前：常元和·推断待确认）；决策与兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求与用量测算 → ② 渠道评估与准入 → ③ 采购审批与对公付款 → ④ 接入统一网关并登记 → ⑤ 健康监控与故障切换 → ⑥ 到期续费评估 → ⑦ 封号应对与月度复盘
  • 交付结果：渠道白名单和评估表、采购审批单与发票/对账凭证、渠道与号池台账、统一网关配置、封号事件记录、维护人交接清单
  • 状态依据：2026-01～10 共 9 个群反复讨论“哪家稳、能不能开票、会不会封号”，长期靠个人垫资；号池维护人退出后交接断档，号池没人维护。目前只有“AI 产品采购表”和几条口头结论（自建中转、国内一手货源、国外经供应商二手货源），没有成文流程

1. 场景判定

  • 触发条件：现有渠道涨价、限流、跑路或宕机；需要新增模型渠道或扩容；向号商买号或续费；号池维护人变更；账号被封、要 KYC 或触发风控；需要对公付款或开票
  • 典型说法：「找中转谈，又便宜又稳定」「终于有一个能对公的中转站了」「个人垫资太多了」「后续找运维和号商对接」「默认不续费，要续再说」「别用这个节点加这个地区开号，秒封」「中转都不可用了」
  • 判断问题：这件事是不是“公司层面选哪个渠道、花钱买、谁来维护、出了事怎么办”？是，就走本流程；只是个人要额度 → 请走 RND-25
  • 不归本流程管：个人额度申请、发放和补贴 → 请走 RND-25；GPU 算力 → 请走 RND-24；对外售卖的模型计费和 NewAPI 产品功能 → 请走 RND-04（需求提出、澄清与评审入迭代）；产品线上依赖的上游模型渠道选型 → 请走 RND-68（模型与上游供应商选型评测）；对公付款执行 → 请走 FIN-01；个人自购后报销 → 请走 FIN-06（日常费用报销提交与审核）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
AI 渠道与号池运维负责人 维护渠道台账，对接号商，发起付款，运维网关，提醒续费，处理封号 R AI 渠道与号池运维负责人（当前：杨明学·推断待确认）
渠道评测 试用比价，测稳定性和倍率，出推荐清单 R/C 渠道评测（当前：王皓南、宋祺睿、魏宗浩·推断待确认）
网关部署 部署统一 API 网关（NewAPI/CPA），做限额和探活 R 网关部署（当前：宋祺睿、吴世豪·推断待确认）
财务 对公付款、开票、对账 R（付款） 财务负责人（当前：黄梦婷·推断待确认）
法务 评估服务条款、主体合规和数据外发边界 C 法务负责人（当前：李瑶·推断待确认）
信息安全 评估中转渠道的代码和数据外泄风险 C 信息安全（当前：待指定）
CTO 拍板渠道准入、预算、续费，以及是否使用灰色渠道 A CTO（当前：丁震宇·推断待确认）
管理层 决定海外主体、公司级境外支付卡等重大事项 A（升级） 管理层（当前：常元和·推断待确认）
账号持有人 封号时配合停用、申诉和登记 R（封号） 公司管理账号的持有人

3. 办之前请准备

  • 用量测算：人数、模型、每月预期 token、并发，是否用于线上业务
  • 至少 2 家候选渠道的信息：价格/倍率、近 30 天稳定性、封号或跑路记录、能否对公和开票、数据隐私条款、质保条件
  • 预算和成本归属
  • 做续费评估时：网关日志（502 重试量、路由降级情况）、使用方和用量
  • 处理封号时：账号、用途、持有人、封禁提示、最近的操作环境（节点、客户端）、账号内的数据
  • 请求最少包含字段（新增渠道/扩容申请必填，缺项退回）：申请人岗位与用途（研发自用/线上业务/哪条产品线）、需要的模型清单、预计月用量与并发、期望可用日期与原因、预算来源与成本归属、是否要求对公开票、是否会经该渠道传输客户或涉密数据、现有渠道为什么不够用

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 汇总需求，测算用量和成本 运维负责人 需求提出后 2 个工作日内 多维表格 / 网关用量 用量测算（写入渠道台账“需求”条目，申请人可见） 🤖自动化
2 渠道评估：试用至少 3 天，记录价格、稳定性、封号情况、开票能力和隐私条款；不尊重隐私或无质保的渠道一律不准入 渠道评测 + 信息安全 测算后 5 个工作日内 渠道评估表 评估结论（渠道评估表，多维表格，附推荐/不推荐理由） 👤人工判断
3 准入审批：CTO 批渠道白名单；涉及服务条款或主体合规的，先由法务出意见 CTO + 法务 评估结论提交后 2 个工作日内 飞书审批 白名单更新（飞书审批记录 + 知识库白名单页）；超时→运维负责人在审批流催办 👤人工判断
4 采购：发起采购审批（供应商、用途、能否开票），财务对公付款；确实无法对公的，事前经 CTO 批准再由个人垫付，并在 5 个工作日内报销 运维负责人 + 财务 准入后 1 个工作日内发起；审批后 2 个工作日内付款 飞书审批 付款凭证、发票（飞书审批附件，关联渠道台账） 🔧飞书固化
5 接入统一网关：多渠道分散接入，按人发子 key 并限额，配置备用渠道；号商交付的账号要登记出口 IP 和使用环境 网关部署 付款后 1 个工作日内 内部 API 网关 网关配置（网关后台）+ 接入完成通知（申请人与研发通知群） 🤖+👤
6 登记渠道与号池台账 运维负责人 接入当天 多维表格 台账记录（渠道与号池台账，多维表格） 🔧飞书固化
7 机器人定时探活各渠道，失败时自动切到备用渠道并在研发群通告 机器人 / 网关部署 实时；故障 15 分钟内通告 探活脚本 + 飞书机器人 告警与切换记录（研发通知群卡片 + 台账事件） 🤖自动化
8 续费评估：到期前 7 天提醒，运维负责人拉网关日志（502 重试、降级、用量）给出建议；CTO 决定（默认不续，有业务依赖的续） 运维负责人 / CTO 到期前 7 天提醒 / 到期前 3 天决定 台账 + 网关日志 续费决定（写回台账“续费”字段，通知使用方） 🤖+👤
9 封号应对：先停用该账号的路由并切到备用，24 小时内按模板申诉，能退款的走原路退款，登记封禁原因 运维负责人 / 账号持有人 发现后 24 小时内 台账 / 申诉模板 封号事件记录（台账）+ 受影响使用方通知（研发通知群） 👤人工判断
10 月度复盘：渠道可用率、成本、封号事件，据此更新白名单和《AI 账号使用规范》 运维负责人 每月第一周 知识库 月度渠道报告（知识库固定目录，CTO 与财务可见） 🤖自动化
11 维护人变更时按交接清单交接（总 API、业务专用 API、号商联系渠道、代理出口、到期日、使用方），并更新台账负责人 原负责人 / 新负责人 变更前 3 个工作日 交接清单 交接记录（交接清单文档归档知识库，台账负责人字段更新；双方确认） 🔧飞书固化

5. 交付物与模板

  • 交付物：渠道评估表、渠道白名单、采购审批与付款凭证、渠道与号池台账、网关配置、封号事件记录、月度渠道报告、交接记录
  • 建议模板/表单：
    • 渠道评估表：渠道名称、类型（官方订阅/企业版/云厂商/中转站/号商）、支持的模型、价格/倍率、近 30 天可用率、封号/跑路记录、能否对公开票、隐私条款、质保、评估人、评估日期、结论（准入/观察/禁用）
    • 渠道与号池台账：账号或渠道、用途（研发/业务线/公共号池）、持有人、出口 IP/节点、套餐、到期日、费用来源、使用方、状态、封禁记录
    • 《AI 账号使用规范》：只用官方客户端；禁用反代和第三方客户端；禁止共享个人号；统一出口节点；开号与养号规则；不能用的注册地区；绑定 2FA；附申诉模板
    • 号池交接清单：账号与 API 清单、后台入口、号商联系渠道（不含凭证明文）、代理出口、到期日、使用方、未结费用

6. 异常与升级

  • 主渠道宕机 → 15 分钟内切到备用渠道并通告 → 全部渠道都不可用的，1 小时内升级 CTO
  • 中转跑路或被清洗、余额受损 → 停止充值，登记损失，从白名单移除 → CTO 决定是否追偿
  • 线上业务依赖的号到期或被封 → 先切备用保住业务，当天通知业务方 → 升级 CTO 决定是否补号
  • 号商开不了票 → 采购前告知财务 → CTO 决定是否接受无票支出及如何入账
  • 涉及海外主体、境外支付卡等合规问题 → 法务评估、CTO 提出建议 → 升级管理层决策（管理层为 A（升级），5 个工作日内给结论）
  • 维护人离岗、渠道超过 1 个工作日无人维护 → CTO 指定临时负责人
  • 申请提出后 2 个工作日未得到测算结论，或准入/采购审批超过 2 个工作日无人处理 → 申请人在台账条目或审批流内催办运维负责人 → 再过 1 个工作日无响应升级 CTO
  • 接入完成后申请人未收到通知、不知道 key 在哪 → 运维负责人当天补发接入说明（网关地址、子 key 领取方式走密码库或私信），不在群内发明文

7. 衡量指标

  • 渠道可用率 = 工作时间内至少有一条渠道可用的时长 / 工作总时长，目标 ≥ 99%
  • 故障切换时间 = 从探活发现故障到切换完成的分钟数，目标 ≤ 15 分钟
  • 个人垫资笔数 = 每月未经事前审批的个人垫付笔数，目标 0
  • 封号事件数 = 每月公司管理账号被封次数，目标逐月下降
  • 台账覆盖率 = 已登记的渠道和账号 / 实际在用的渠道和账号，目标 100%

8. 低效诊断

  • 现象：各人自选中转，稳定性和成本口径不统一，“没有信得过的中转能去谈”｜依据：「鼎慧产研决策部」2026-01
  • 现象：能否给全员稳定开通官方高档订阅，调研了好几轮都没结论；中转一崩，工具直接报错｜依据：「鼎慧产研决策部」2026-03
  • 现象：买中转的钱要不要记采购表说不清，用量无法按人归集，共享账号被他人用超额｜依据：「鸽子群模态分群」2026-01
  • 现象：哪家稳、能不能开票、会不会封号在群里反复问答，渠道一宕机全员都用不了｜依据：「鸽子群模态分群」2026-02、「鸽子群模态分群」2026-03
  • 现象：封号经验靠口口相传，给非研发同事开的号被封，业务当场中断｜依据：「鸽子群模态分群」2026-03
  • 现象：没有订阅清单和到期提醒，“需要一个管理订阅的工具”｜依据：「鸽子群模态分群」2026-04
  • 现象：封号后才讨论怎么规避风控，经验没有沉淀｜依据：「模态AI探索小分队」2026-03、「模态AI探索小分队」2026-05
  • 现象：采购只有口头结论，“现在没人负责研究买什么中转”｜依据：「⭐大模型基座事业群」2026-03
  • 现象：能对公的渠道少，长期个人垫资再补报销｜依据：「技术部」2026-01、「技术部」2026-03
  • 现象：号商渠道只跟个人单线联系，维护人退出后交接断档、号池无人维护；续费全靠想起来才问｜依据：「跃迁基座许愿机」2026-06、「跃迁基座许愿机」2026-09
  • 现象：价格汇总散在全员群里，上游一出故障就各自找替代｜依据：「模态集团（全员群）」2026-01、「模态集团（全员群）」2026-03
  • 现象：没有渠道白名单，公司邮箱被站点封禁；“别建号池”的口径和实际做法不一致｜依据：「AI工具跃迁交流群」2026-03、「AI工具跃迁交流群」2026-10
  • 现象：每个人自己找中转，费用由谁承担不明确｜依据：「工程咨询产研」2026-02

9. 分支变体

  • 国内模型：公司向云厂商一手采购，先统计预期 token 再买，可申请折扣，对公开票
  • 海外模型：不以公司名义直接采购，通过供应商二手货源，把风险转给供应商；官方企业版（能开票、管理员发 key 并限额）优先评估
  • 中转站：分散在多家购买以分摊风险，用多少充多少；不使用不尊重隐私的站点
  • 号商买号：必须有质保（含 KYC 和手机号），付款走采购审批；替代方案是在官网直接买国产模型套餐
  • 号池/网关：由运维统一管理，按人发子 key；公司对“是否允许共享号池”的口径还有分歧，需 CTO 定稿
  • 各平台封号差异：Claude 风控严且封号不退款；OpenAI 对网络异常和 KYC 风控；反代类可能半小时内被封；Codex 有周限额和重置卡
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-08（信息归档与单一事实来源）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 主责是否定为 IT 运维？是否需要单设“AI 资源”岗位？
  • 公司到底是否允许号池或共享账号？“别建号池”和号池在用的现状如何统一？
  • 海外模型的采购主体和支付方式（海外主体、公司级境外支付卡）由谁决策？何时落地？
  • 对公采购和个人垫资的边界在哪？垫资后几天内必须报销？
  • 采购审批是否按金额分级？阈值是多少？
  • 渠道准入是否必须由法务和信息安全会签？
  • 现有“AI 产品采购表”是否升级为渠道台账继续使用？
RND-27模型 API Key 与调用额度申请（统一接入站）待优化144

状态：待优化｜证据：有证据（卡片 16 张 / 会话 20 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：研发、测试、产品或项目需要调用公司统一 AI 接入站（aiapi/NewAPI/MercAll）或云厂商模型，需新开 Key、加额度、区分测试/生产、更换失效 Key，或申请第三方云服务接口 Key、模型服务权限时启动；同时管 NewAPI 实例管理员与 2FA 治理，并约束模型调用只走公司指定渠道
  • 负责人：主责——AI 接入站经办管理员（当前：杨明学·推断待确认）；协同——预算审批人（当前：丁震宇·推断待确认）、网关技术负责人（当前：望政韬·推断待确认）、NewAPI 实例负责人（LeapCore 当前：柯逸飞·推断待确认；LeapAll 当前：邓乾·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、申请表单与自动化维护人（当前：陈晖·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 对照术语表选申请类型 → ② 填「统一AI接入配额申请」→ ③ 预算审批 → ④ 接入站建用户/令牌并设额度、IP、到期 → ⑤ 私密渠道发放（生产 Key 由环境运维注入）→ ⑥ 台账回写 → ⑦ 用量、渠道合规监控与阈值告警 → ⑧ 失效/超额处置 → ⑨ 到期回收与月度对账 → ⑩ 管理员名单与 2FA 定期审计
  • 交付结果：按用途和环境隔离、设了额度上限的接入站令牌；台账记录（归属人/项目/环境/额度/到期）；月度按项目归集的消耗报表
  • 状态依据：已有多维表格「统一AI接入配额申请」、卡片通知和 wiki 流程说明，环境字段已补；但 2026-01～09 仍反复出现私聊/群内明文发 Key、额度耗尽才发现（约 6 次）、令牌失效靠群里猜原因、额度单位误解、多渠道并存入口不清

1. 场景判定

  • 触发条件：开发/测试/Demo/比赛/项目交付需要调用大模型；现有 Key 报 401/403/429/503；额度即将耗尽；需要给实习生或面试候选人临时 Key；需要区分测试与生产调用；需要第三方云服务接口 Key（如文档解析）或 TTS 等模型服务权限；NewAPI 管理员交接或 2FA 登不上；发现调用走了非指定渠道
  • 典型说法：「这个表申请的是测试环境？」「一天刷光了」「应该是 one api 没钱了」「API 额度随便申请，走申请 SOP、说明正当理由就行」「注意消耗，别超出额度」「需要申领的统一走这个流程」「你要生产，按 SOP 申请一个项目交付号」
  • 判断问题：我要的是“按量调用的模型 API Key/额度”吗？用途是个人开发、内部测试还是项目交付外发？公司接入站上有没有这个模型？
  • 术语口径（写入 wiki 术语表）：账号＝NewAPI 用户；Key＝账号下的调用凭据；额度＝账号余额（人民币计价）；测试号＝带过期时间、仅限测试环境；项目交付号＝一个项目一个 NewAPI 用户，生产只发项目交付号
  • 不归本流程管：Claude/Codex/Cursor 等编码工具订阅与席位 → 请走 RND-25；中转渠道采购与号池维护 → 请走 RND-26；接入站尚未接入的新模型/新渠道 → 请走 RND-67；模型价格与倍率配置 → 请走 RND-69；上游账户充值付款 → 请走 FIN-03；上游故障降级 → 请走 RND-72；测试账号与产品内测试额度 → 请走 RND-47；Key 泄露 → 请走 X-SEC-11；云控制台子账号与 AccessKey → 请走 X-SEC-15；飞书机器人、应用权限与白名单 → 请走 X-SEC-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填申请单、按用途使用、不外传、到期归还 R 研发/测试/产品/项目成员
预算审批人 审批额度、高成本模型与外发用途 A CTO（当前：丁震宇·推断待确认）
接入站经办管理员 开用户/令牌、设额度与 IP、发放、台账回写、告警处置 R AI 接入站管理员（当前：杨明学·推断待确认）
备用经办 经办人不在时代办开通与故障处置 R（备岗） 网关备用维护者（当前：吴世豪·推断待确认）
网关技术负责人 接入站渠道配置、令牌失效与无可用渠道排查 C 网关技术负责人（当前：望政韬·推断待确认）
NewAPI 实例负责人 各实例一主二备；维护渠道与模型列表、管理员 2FA；交接期补齐历史账号归属 R LeapCore NewAPI（当前：柯逸飞·推断待确认）；LeapAll NewAPI（当前：邓乾·推断待确认）
环境运维 把生产 Key 注入生产环境变量/CI secrets，不经人转手 R 环境运维（当前：宋祺睿·推断待确认）
项目负责人 在项目交付号内自开 Key、分配额度；下游问题先自查使用日志 R 申请人所在项目负责人（当前：待指定）
表单与自动化维护人 维护表单字段、状态流转、卡片通知 R（工具） 研发（当前：陈晖·推断待确认）
财务 上游余额不足时充值打款；按项目归集模型费用 C 财务负责人（当前：黄梦婷·推断待确认）
信息安全 密钥分发规范、泄露处置 C 信息安全负责人（当前：待指定）

3. 办之前请准备

  • 用途分类：个人开发 / 内部测试 / 项目交付外发 / 比赛或活动 Demo / 面试实操
  • 归属：个人（一人一号）或项目（一项目一号），不得重复开号
  • 所需模型清单、预计月额度（人民币计价，不是 tokens）、使用起止时间
  • 环境：测试或生产；生产/外发需写明调用方和调用来源 IP
  • 已有账号的写原账号名，选“已有账号-增加额度”
  • 已经口头获批的，在理由里写清批准人和上下文，避免审批人缺背景
  • 交付外发的写明客户代号和部署环境；生产使用必须申请项目交付号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写配额申请：先对照 wiki 术语表选类型（测试号/项目交付号/加额度/服务权限），再填项目、用途、环境、模型、额度（元）、联系人、期限 申请人 需求出现当天 多维表格「统一AI接入配额申请」 申请记录 🔧飞书固化
2 预算审批：测试用途小额按默认档放行，生产/外发/生图视频等高成本模型逐单审；挂起超过 1 个工作日机器人提醒 预算审批人 提交后 1 个工作日内 多维表格自动化/飞书审批 审批结论 🔧飞书固化+👤人工判断
3 卡片通知经办人“待发放额度” 系统 审批通过即时 飞书机器人 待办卡片 🔧飞书固化
4 在接入站建用户/令牌，按申请设额度、模型分组、IP 白名单、到期日；测试号必须设过期时间，生产只发项目交付号；Key 名带项目或用途前缀（如面试 Key 统一前缀） 经办管理员 审批后 4 个工作小时内 aiapi/NewAPI 后台 令牌 🤖自动化
5 发放：申请人登录接入站自取，或经密码库授权给负责人；生产 Key 由环境运维注入生产环境变量/CI secrets；禁止群内/文档明文 经办管理员、环境运维 同步骤 4 接入站控制台/密码库/CI secrets 发放记录 🔧飞书固化
6 回写台账：Key 名称（不含明文）、归属、环境、额度、到期、关联申请记录、状态 经办管理员 发放当天 多维表格 台账行 🤖自动化
7 申请人配置到环境变量，不写入代码、SKILL、群消息；测试服上线前核对是否换成正确 Key；项目交付号由项目负责人在账号内自开 Key、分配额度 申请人/项目负责人 使用前 本地/测试服配置 可用配置 👤人工判断
8 余额低于 20% 或单日消耗超过日均 3 倍时机器人提醒经办人和申请人；发现非指定渠道（如直连模型官网）流量同步告警 系统 实时 接入站+飞书机器人 告警消息 🤖自动化
9 到期前 7 天提醒；到期自动停用，需续期的重走步骤 1；每月 5 日前导出上月按项目/用途消耗，交财务归集，清理过期和零散令牌 经办管理员 每月 5 日前 接入站导出 月度消耗表、回收记录 🤖自动化
10 每季度审计各 NewAPI 实例管理员名单（一主二备）、2FA 状态与渠道清单，结果登记到实例名单 NewAPI 实例负责人 每季度首月 NewAPI 后台+多维表格 审计记录 👤人工判断

5. 交付物与模板

  • 交付物：接入站令牌；配额台账；月度消耗报表；接入站使用说明 wiki（含术语表）；NewAPI 实例负责人名单（一主二备）；渠道清单
  • 建议模板/表单：申请人｜项目｜用途（项目交付外发/内部测试/个人使用/比赛 Demo/面试）｜环境（测试/生产）｜类别（新账号/增加额度/服务权限）｜已有账号名｜模型｜额度（元，表单强制标注单位）｜期限｜调用来源 IP｜批准上下文｜预算审批人｜经办人｜状态｜令牌名｜到期日｜回收日期
  • NewAPI 实例名单：实例（aiapi/LeapCore/LeapAll）｜主负责人｜两名备份｜2FA 状态｜管理员账号所在密码库条目｜最近审计日期
  • 渠道清单：模型｜指定渠道｜备用渠道｜禁止渠道｜折扣主体｜负责人

6. 异常与升级

  • 403 额度不足 → 申请人按步骤 1 提加额度；影响测试/演示的经办人先临时加额度 → 2 小时内无人处理升级 CTO
  • 审批挂起超过 1 个工作日 → 机器人提醒预算审批人 → 超过 2 个工作日升级 CTO
  • 测试 Key 被用到生产 → 经办管理员发现后 1 小时内通知负责人，补发项目交付号并由环境运维切换 → 已造成故障的按 RND-75 复盘，升级 CTO
  • 发现非指定渠道流量（如直连模型官网）→ 经办管理员查到 Key 和负责人，通知 1 个工作日内切换 → 逾期不切换的直接停用该 Key
  • NewAPI 管理员 2FA 无法登录或管理员交接 → 找该实例备份负责人，由数据库管理员重置（当天），处理记录登记到实例名单
  • 401 令牌过期/失效 → 经办管理员重发并在台账标记旧令牌作废（2 小时内）
  • 503 无可用渠道 / 上游欠费 → 网关技术负责人判定；上游余额问题转 FIN-03，渠道问题转 RND-72（30 分钟内响应）
  • Key 出现在群聊、日志、代码仓库 → 经办管理员立即禁用并重发，按 X-SEC-11 处置（当天）
  • 同一 Key 被多人重置导致他人失效 → 一律拆成个人/项目独立令牌，禁止共享
  • 单用户异常消耗（如大附件循环调用）→ 先限额再排查，结果同步申请人（1 个工作日内）

7. 衡量指标

  • 开通时长：提交到拿到令牌的工作小时数，目标 ≤ 1 个工作日
  • 明文 Key 外露次数：群聊/文档/代码中发现的次数，目标 0
  • 额度耗尽导致中断次数：测试/演示/线上因额度耗尽不可用的次数，目标每月 0
  • 台账覆盖率：接入站有效令牌中能在台账找到归属与到期的比例，目标 100%
  • 消耗归集率：月度消耗能归到项目/用途的比例，目标 ≥ 95%
  • 测试 Key 进生产次数：每季度发现次数，目标 0
  • 渠道合规率：走指定渠道的调用量 / 总调用量，目标 ≥ 99%

8. 低效诊断

  • 申请入口建成前全靠私聊开号，同一人是否已开过 Key 无从查证｜依据：「模态AI探索小分队」2026-04、「模态跃迁通知群」2026-04
  • 申请表最初缺“测试/生产”字段，只有默认测试的隐含规则，用时才补字段｜依据：「鼎慧产研决策部」2026-05
  • 额度见底才发现，充值到账前 Key 已被关停，开发与比赛中断｜依据：「工程咨询产研」2026-05、「LeapAll」2026-04、「leapagent赛马」2026-04
  • 报错后在群里猜是没钱、令牌过期还是渠道不可用，没有责任人和阈值提醒｜依据：「LeapCore虾塘测试群」2026-04
  • Key 在群里明文贴出，需要事后提醒安全意识｜依据：「技术部」2026-01
  • 测试服 Key 未更换导致 429；上游限额与本地限额混淆｜依据：「Leap产研测」2026-08
  • 额度单位被误当成 tokens 导致填错；共享订阅账号靠群里喊话分配｜依据：「模态AI探索小分队」2026-05、「模态AI探索小分队」2026-06
  • 多渠道并存（内部接入站、另开网关、个人中转），新人不知找谁｜依据：「模态AI探索小分队」2026-04、「模态AI探索小分队」2026-05
  • 各业务各自接 Key、同一 Key 被不同人重置｜依据：「LeapAll」2026-04
  • 测试 Key 被直接用到生产，过期后线上服务全面故障｜依据：「AI API」2026-05
  • “账号/Key”说法有歧义，加额度审批挂起很久无人发现｜依据：「AI API」2026-05、「AI API」2026-06
  • 内网自建网关的地址和访问凭据在群里重发，额度无人管也不回收｜依据：「跃迁AI总动员」2026-08
  • NewAPI 权限混乱，管理员 2FA 登不上，渠道账密不知在谁手上，交接靠 @ 人｜依据：「AI API」2026-06、「AI API」2026-07、「AI API」2026-09
  • 已宣布只用指定渠道，仍两次发现有流量走官网｜依据：「AI API」2026-07

9. 分支变体

  • 测试 Key vs 生产 Key：生产/外发必须单独账号、预充值、设 IP 白名单，便于月度导出核算
  • 个人 vs 项目：个人一人一号，项目一项目一号；公司自用开发统一在公司账号下按人建令牌
  • 实习生/面试候选人：由面试官或导师提申请，开独立子令牌、限额，面试结束或实习结束 24 小时内回收
  • 比赛/活动 Demo：按活动预算一次性申请，活动结束 3 个工作日内回收
  • 海外模型：按成本价文档统一加价后配置（加价口径见 RND-69）
  • 接入站不兼容的模型：经 CTO 同意后直连官方渠道，同样登记台账
  • 对外零售/散户售卖：不走内部接入站，单独网关单独记账
  • 云厂商直连 Key（为个人 Agent 单独开）：同样登记，便于监控消耗和限额
  • 项目交付号：一个项目一个 NewAPI 用户，项目负责人自开 Key、自分额度；经办管理员看不到 Key 归属，下游问题先由项目负责人自查使用日志再反馈
  • 面试题 Key：按场次批量开，统一名称前缀，面试结束后批量清理
  • 第三方云服务接口 Key（如文档解析）、TTS 等模型服务权限：在申请表选“服务权限”类，由云平台管理员按最小权限开通，同样登记台账、期限明确
  • 渠道规则：DeepSeek 类模型走指定云渠道，官网只作备用；零散第三方 Key 统一清退，改走接入站
  • 已合并原 X-SEC-13（模型 API Key / 内部 NewAPI 额度申请与渠道管理）：并入术语口径、项目交付号、生产 Key 注入、NewAPI 管理员与 2FA 治理、渠道合规与面试 Key 规则

10. 待确认问题

  • 经办管理员是否确定为当前人选？备用经办人是谁？主责是否已正式从前任管理员移交，交接是否完成？
  • 测试用途“免逐单审批”的默认额度上限定多少（[阈值待财务确认]）？额度多大时需要 CTO 以上审批？
  • 另开的商业 AI 网关是否并入统一接入站，还是保留为单独渠道并同样走本流程？
  • 告警阈值（余额 20%、日消耗 3 倍）是否合适？告警发给谁？
  • 合并 RND-27 后，模型 Key 与额度申请归口研发（RND，接入站经办）还是信息安全（X-SEC），请管理层裁定
  • 候选人/实习生 Key 的额度与回收时限是否由 HR 或面试官负责？面试 Key 清理期限定多久？
  • 测试号默认有效期定多久？渠道清单和违规停用规则是否需要正式发文？
  • 各 NewAPI 实例的一主二备名单是否已经确定？
RND-28AI 编码协作规范与质量管控待新建180

状态：待新建｜证据：有证据（卡片 25 张 / 会话 15 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：研发、产品或其他成员用 Codex/Claude Code 等 AI 编码工具或多 Agent 协作写代码、做 Demo、产出分析结果时，必须遵守的事前准备、执行约束、自测审查和交付规则
  • 负责人：主责——研发技术负责人（AI 编码规范维护）（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、Agent/客户端核心研发（当前：岳阳·推断待确认）、产品总监（非研发使用方）（当前：杨萌·推断待确认）、各仓库 owner（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 界定范围并写任务书 → ② 仓库 AGENTS.md 就绪 → ③ 选模型分工（强模型写工单/验收，执行模型写代码）→ ④ 隔离环境、禁止碰生产 → ⑤ 执行中频繁 commit 与监工 → ⑥ 自测（单测+冒烟）→ ⑦ 独立 Agent 审查+人工 review → ⑧ 人话交付说明并回写踩坑到 AGENTS.md
  • 交付结果：通过自测、独立审查和人工 review 的代码/PR；任务书与验收记录；更新后的 AGENTS.md
  • 状态依据：已有零散载体（各仓库 AGENTS.md、Agent 项目管理 Playbook、个人推广的多 Agent SOP 文件），但无公司级统一规范；2026-01～10 出现强推、误删、AI 回退清空工作、hook 写坏八小时零产出、一夜烧空额度、AI 自报“已跑通”实际未接线等事故

1. 场景判定

  • 触发条件：用 AI 工具写或改仓库代码；用多 Agent/长任务夜间运行；非研发成员（产品、设计）直接改代码；用 AI 生成脚本并产出分析结论；准备交付 AI 生成的代码、文档、视频
  • 典型说法：「不是不让用 AI 写，是要按规范用」「别让写代码的 Agent 自己检查」「写进 AGENTS.md」「Codex 不能当许愿机，这是生产级产品」「所有人的 Agent 操作都应该遵循最小操作原则」「每次改动都 commit 一下，本地 git 就够解决它乱改」
  • 判断问题：这次产出是否由 AI 生成或大幅修改？是否会合入仓库、交给他人或对外？AI 是否能接触生产、密钥或涉密数据？
  • 不归本流程管：AI 编码工具账号/订阅 → 请走 RND-25；模型 API Key → 请走 RND-27；工具故障、教程、经验分享 → 请走 RND-29；编码风格与提交规范 → 请走 RND-30；分支模型 → 请走 RND-31；PR 评审合并 → 请走 RND-32；AI 自动评审机制 → 请走 RND-33；开工前方案过审 → 请走 RND-13；产品内 Agent 权限设计 → 请走 RND-20；内部 AI 机器人平台 → 请走 RND-81

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
开发者（AI 使用者） 写任务书、驱动 Agent、自测、对产出负全责 R 研发/产品/设计
规范维护人 维护公司级 AGENTS.md 模板、模型分工与禁令清单 A 研发技术负责人（当前：王皓南·推断待确认）
测试负责人 独立 Agent 审查与测试门禁、验收 C 测试负责人（当前：张东郅·推断待确认）
危险操作拦截维护 维护危险指令拦截、Agent 越权约束 R（工具） Agent 核心研发（当前：岳阳·推断待确认）
仓库 owner 仓库 AGENTS.md 落地、人工 review 与合并 R 各仓库 owner（当前：待指定）
非研发使用方负责人 产品/设计改代码的范围与 PR 规则 C 产品总监（当前：杨萌·推断待确认）
CTO 规范争议升级拍板、生产权限与涉密边界裁定 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 任务书：目标、上下文（相关代码/issue/参考开源项目）、验收标准、约束、不做什么
  • 仓库根目录 AGENTS.md（≤ 100 行，含测试要求、命名、组件库、禁止项）
  • 可用的测试环境与配置；Demo 还是正式产品的范围界定
  • 本次额度预算（预计 token 消耗）；长任务需准备 worktree/独立分支
  • 确认 AI 不持有生产凭据、不能删除云实例

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 界定范围：先核心后扩展，Demo 砍掉非核心；写任务书（目标/上下文/验收/约束） 开发者 开工前 issue/飞书文档 任务书 👤人工判断
2 检查仓库 AGENTS.md 是否覆盖本任务约束，缺的先补 开发者 开工前 Gitea AGENTS.md 👤人工判断
3 模型分工：强模型写工单与验收，执行模型写代码；禁用 fast 档；按规范选择档位 开发者 开工时 Codex/Claude Code 工单拆分 👤人工判断
4 隔离：worktree/独立分支，沙箱运行；AI 不得操作生产、不得持有密钥明文，密钥写入文件由程序读取 开发者 开工时 git/WSL/容器 隔离环境 🤖自动化
5 执行：每次改动 commit；限制改动范围（只动本任务相关文件）；长任务配监工，30 分钟无产出告警 开发者 执行中 git/hook/编排工具 提交记录 🤖自动化
6 自测：单测+真实场景冒烟；AI 报告“已通过”须附命令输出或截图 开发者 提交 PR 前 CI/本地 自测证据 🤖+👤
7 独立审查：另一模型/另一 Agent（无写代码上下文）审 diff，结论转工单或修复 开发者 提交 PR 前 AI review bot 审查记录 🤖自动化
8 人工 review：阻塞级别以人为准，AI 只能给 +1/-1，合并需人工 仓库 owner PR 提交后 1 个工作日内 Gitea PR 合并结论 👤人工判断
9 交付说明：用人话写改了什么、怎么验证、AI 生成部分标注；作者本人须读过 开发者 合并/交付时 Gitea PR 模板 交付说明 🔧+👤
10 回写：本次踩坑和纠偏写入 AGENTS.md 或团队 skill 开发者 合并后 1 个工作日内 Gitea 规则更新 🤖自动化

5. 交付物与模板

  • 交付物：公司级《AI 编码协作规范》；仓库 AGENTS.md 模板；任务书模板；AI 交付自检清单
  • 建议模板/表单：任务书（目标｜上下文链接｜验收标准｜约束/禁止项｜范围外｜预计额度）；AGENTS.md（测试要求｜命名风格｜组件库来源｜禁止 merge 与 force push｜构建垃圾清理｜不得新增无意义文档｜UI 文案须人确认｜生产禁区）；自检清单（是否自测｜是否独立审查｜是否超范围改动｜是否含密钥/mock/调试代码｜作者是否通读）

6. 异常与升级

  • AI 误删/误回退本地工作 → 用 git 记录恢复；无提交记录的视为违反步骤 5，报仓库 owner（当天）
  • AI 触碰生产或云资源 → 立即中止、回收凭据，报 CTO（30 分钟内），按 RND-58/RND-75 处置
  • AI 读取或输出密钥 → 按 X-SEC-11 轮换（当天）
  • 空转/异常烧额度（单日超过预算 2 倍或长时间零产出）→ 停任务，复盘 hook/提示词，报规范维护人（1 个工作日内）
  • AI 自报完成但人工验证不通过 → PR 打回，同类问题累计 3 次由规范维护人更新 AGENTS.md
  • 非研发提交含 mock/预览代码 → 仓库 owner 打回并说明，必要时为其单独写 AGENTS.md
  • 涉密或客户数据可能上传云端 Agent 平台 → 禁止上传，报 CTO 裁定
  • 规范条款争议、生产权限或涉密边界超出规范维护人决定范围 → 规范维护人整理双方意见 → 升级 CTO 拍板（A（升级），2 个工作日内）

7. 衡量指标

  • AI 相关返工率：因 AI 产出缺陷被打回的 PR 数 / PR 总数，目标逐月下降，≤ 15%
  • AI 误操作事故数：误删、越权、强推、碰生产次数，目标每月 0
  • AGENTS.md 覆盖率：活跃仓库中有符合模板的 AGENTS.md 的比例，目标 100%
  • 自测证据附带率：PR 中附自测证据的比例，目标 ≥ 90%
  • 空转告警次数与单任务 token 成本：按周统计

8. 低效诊断

  • 规则散落在群聊和个人经验，同一纠偏（清理构建垃圾、评审分级、做重工作）反复出现｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • AI 产出未自测、测试无用例记录就交付生产级产品｜依据：「LeapPPT」2026-05、「鸽子群模态分群」2026-07
  • 写代码的 Agent 自查不可信，计费/吊销等未真正接线流入测试｜依据：「LeapVPN网络预研」2026-08、「LeapVPN网络预研」2026-09
  • 不同模型结论不同导致实验和计算重做｜依据：「鼎慧产研决策部」2026-01
  • AI 乱改乱删文件、两天烧掉大额 token 效果差｜依据：「模态AI探索小分队」2026-03、「模态AI探索小分队」2026-04
  • 多 Agent 空转、hook 写坏零产出、一夜烧空额度｜依据：「跃迁AI总动员」2026-09、「跃迁AI总动员」2026-10
  • AI 代理自行发 PR 无人知晓；可能动生产的操作缺少红线｜依据：「工程咨询产研」2026-04、「工程咨询产研」2026-06
  • 非研发直接改前端提交预览代码，UI 文案被 AI 自行添加｜依据：「Leap产研测」2026-08
  • 各人推一套 skill 和 PR 写法，无统一模板｜依据：「跃迁AI总动员」2026-10
  • 规范范围长期定不下来、经验无法在 Agent 间共享｜依据：「⭐大模型基座事业群」2026-01、「⭐大模型基座事业群」2026-03
  • 云端 Agent 平台全员试用时涉密边界边讨论边定｜依据：「模态AI探索小分队」2026-05

9. 分支变体

  • 研发 vs 非研发（产品/设计）：非研发改代码必须走 PR、由研发 review，UI 文案须人确认
  • Demo vs 正式产品：Demo 可简化门禁但须界定范围；正式产品必须完整执行步骤 6～8
  • AI 生成脚本/数据分析结论：记录需求、数据文件版本、模型版本、脚本；运行前校验列名/行数；多模型交叉复核，结论人工核对
  • 云端 Agent 平台（全员公车）：邀请制，涉密与客户数据不得上传，账号与额度走审批
  • 跃竞/跃玩：多代理协作规范明确禁用 fast 档并指定复核责任人
  • 产品内 Agent 提示词与 Harness 分工（能改 Harness 不改 Prompt）：属产品设计，见 RND-20/RND-82

10. 待确认问题

  • 规范维护人是否为当前研发技术负责人？各产品线（鼎慧、跃竞）是否各设一名？
  • 是否以现有 Agent 项目管理 Playbook 和多 Agent SOP 文件为底稿合并成文？
  • 模型档位与分工建议是否写死在规范里，还是按季度更新？
  • “AI 不得操作生产”的红线范围（只读查询是否允许）？
  • 空转/烧额度告警阈值和监工工具由谁建设？
  • AI 生成内容未自检造成他人返工，是否纳入 RND-12 考核？
RND-29AI 工具使用经验沉淀、培训与互助排障待优化64

状态：待优化｜证据：有证据（卡片 8 张 / 会话 4 个）｜优先级：频4 × 耗2 × 跨4 × 险2

  • 适用场景：员工使用 Claude Code/Codex/OpenCode/Gemini 等 AI 工具遇到报错、不可用、配置问题，或有新工具/新订阅上线、摸索出值得推广的新用法、需要换工具迁移上下文时启动
  • 负责人：主责——AI 工具文档维护人（tech writer）（当前：魏宗浩·推断待确认）；协同——AI 工具群答疑值守（当前：游家豪·推断待确认）、AI 工具渠道与供应商对接人（当前：丁震宇·推断待确认）、代理与网络支持（当前：杨明学·推断待确认）、skill 征集与推广（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 在 AI 工具群按模板报问题 → ② 值守人查 FAQ/渠道状态表并响应 → ③ 给出临时规避 → ④ 供应商故障统一对接并公告 → ⑤ 解决后沉淀 FAQ → ⑥ 新工具上线同步发集成教程 → ⑦ 新方法/skill 评审后推广 → ⑧ 月度更新与培训
  • 交付结果：持续更新的《AI 工具使用手册》（含 FAQ、渠道状态表、集成教程）；新工具教程；推荐 skill/方法清单
  • 状态依据：已有 AI 工具问题统一群、研发 AI 工具教程与套餐文档、Codex/Claude Code 使用指北等，但文档久未更新、维护人和更新时点未定，同类故障与配置问题在群里反复问约 10 次，渠道推荐频繁变化无清单

1. 场景判定

  • 触发条件：AI 工具报错/打不开/限流/被封/插件不可用；新工具或新订阅发放；有人摸索出新配置、hook、skill 或工作流；更换 AI 工具或电脑需要迁移会话上下文
  • 典型说法：「以后 AI 工具相关的使用问题都可以在这个群讨论」「换个 url 试试」「等恢复吧」「CodeX 也整一份流程，写一份集成教程」「每次更换 AI 工具就像搬家一样」「都需要会用这个命令」
  • 判断问题：这是工具“怎么用/为什么不能用”的问题，还是要开账号、要额度、要采购？
  • 不归本流程管：申请工具账号或订阅 → 请走 RND-25；采购中转渠道、号池维护、封号风控 → 请走 RND-26；模型 API Key/额度 → 请走 RND-27；AI 编码协作约束 → 请走 RND-28；内部自研 skill/工具发布与分享会 → 请走 RND-87；项目交接 → 请走 RND-85；新人入职培训 → 请走 HR-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提问人 按模板报问题，解决后确认 R 全员
群答疑值守 工作时间内首响、给规避方案、记录待沉淀问题 R AI 工具答疑值守（当前：游家豪·推断待确认）
文档维护人 维护手册、FAQ、渠道状态表、教程模板，月度更新 A tech writer（当前：魏宗浩·推断待确认）
渠道/供应商对接人 供应商故障投诉对接、发布恢复公告 R 渠道对接人（当前：丁震宇·推断待确认）
代理与网络支持 代理、网络类问题 C IT 运维（当前：杨明学·推断待确认）
skill 推广人 征集、评审、推广方法与 skill C 研发技术负责人（当前：王皓南·推断待确认）
人事 把手册纳入入职培训 I 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 报问题：工具及版本、操作系统（Windows/Mac/WSL）、使用的渠道或订阅、报错截图（遮挡 Key/Token）、已尝试的办法
  • 写教程：适用人群、获取方式、配置步骤、验证方法、常见问题
  • 推广新方法：使用场景、对比效果、安装命令、已知风险

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 AI 工具群用话题按模板报问题，先自查手册 FAQ 提问人 遇到问题时 飞书群话题 问题帖 🔧飞书固化
2 机器人先检索 FAQ 自动回复，未命中再由值守人响应 机器人/值守人 工作时间 30 分钟内 群机器人+wiki 首次回复 🤖自动化
3 给出规避方案（升级客户端、换分组/URL/渠道、调整环境变量），确认后标“已解决” 值守人 当天 群话题 解决记录 👤人工判断
4 判定为供应商整体故障：对接人联系站长/供应商，群内公告影响范围与预计恢复，恢复后再公告 渠道对接人 确认后 1 小时内 群公告 故障公告 👤人工判断
5 把新问题写进 FAQ，更新渠道状态表（渠道、可用工具、价格、稳定性、最后验证日期） 文档维护人 解决后 1 个工作日内 飞书 wiki/多维表格 FAQ 条目 🤖自动化
6 新工具/新订阅发放前，指定试用人按模板写集成教程，与发放通知一起发布 文档维护人 发放前或发放后 3 个工作日内 飞书 wiki 集成教程 🔧飞书固化
7 新方法/skill 推广：提出人写说明，skill 推广人评审是否纳入推荐清单，再 @全员 skill 推广人 提出后 5 个工作日内 wiki/多维表格 推荐清单 👤人工判断
8 每月第一周复核手册，过期内容下线；每季度做一次工具推荐清单与培训 文档维护人 每月第一周 wiki 更新记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《AI 工具使用手册》（FAQ、渠道状态表、各工具集成教程、推荐 skill 清单）；故障公告记录
  • 建议模板/表单：报障模板（工具｜版本｜系统｜渠道｜报错截图｜已尝试）；渠道状态表（渠道｜支持工具｜价格｜稳定性｜可否开票｜最后验证日期｜对接人）；教程模板（适用人群｜获取方式｜配置步骤｜验证｜FAQ｜更新日期）；skill 登记表（名称｜用途｜来源仓库｜安装命令｜评分｜推荐人）

6. 异常与升级

  • 工作时间 30 分钟无人响应 → 提问人 @ 文档维护人；2 小时未解决且影响开发 → 升级 CTO
  • 渠道整体不可用超过半天 → 渠道对接人评估切换渠道，涉及采购转 RND-26
  • 怀疑账号被封或中转站数据外泄 → 停止使用、改密，报信息安全（当天）
  • 截图或配置中暴露 Key/Token → 撤回消息并按 X-SEC-11 处置
  • 换工具/离职需迁移上下文 → 用公司上下文迁移 skill 导出；离职场景并入 RND-85 交接清单

7. 衡量指标

  • 重复提问率：月内命中已有 FAQ 却仍人工回答的问题数 / 总问题数，目标 ≤ 20%
  • 首次响应时长：工作时间内报问题到首次回复，目标 ≤ 30 分钟
  • 教程滞后：新工具发放到教程发布的工作日数，目标 ≤ 3 天
  • 文档新鲜度：手册各页最后更新日期距今，目标 ≤ 30 天
  • 渠道状态表验证率：每月验证过的渠道占比，目标 100%

8. 低效诊断

  • 同类故障（中转站挂、版本过旧、插件不支持中转）被不同人重复遇到，靠老手现场推测｜依据：「模态AI探索小分队」2026-01、「模态AI探索小分队」2026-03
  • 渠道推荐频繁变化，没有渠道清单和最后验证日期｜依据：「模态AI探索小分队」2026-03、「AI工具跃迁交流群」2026-02
  • 配置、hook、通知做法散落在聊天流，反复提问｜依据：「模态AI探索小分队」2026-02、「模态AI探索小分队」2026-03
  • 使用文档久未更新，没有维护人和验收｜依据：「鸽子群模态分群」2026-04
  • 工具已发放后才补教程，教程维护人未明确｜依据：「AI工具跃迁交流群」2026-02
  • 推荐 skill 清单只在图片里，工作流各人不同｜依据：「AI工具跃迁交流群」2026-03
  • 已有上下文迁移 skill，但非研发不知道，需要他人推荐｜依据：「跃迁AI总动员」2026-10

9. 分支变体

  • 操作系统：Windows / Mac / WSL 配置差异分别写教程
  • 渠道类型：官方订阅 / 中转站 / 镜像站 / 国产 Coding Plan，排障路径不同
  • 研发 vs 非研发：非研发优先给图文教程与上下文迁移方法
  • 个人换工具 vs 离职交接：离职交接并入 RND-85

10. 待确认问题

  • 文档维护人和群答疑值守是否为当前人选？是否需要轮值表？
  • 供应商故障统一对接人是否可从 CTO 下放给 IT 运维？
  • 手册放在哪个 wiki 空间，现有多份教程如何合并、旧文档谁下线？
  • 是否按 4D fluency 等框架建立 AI 使用考核指标，由谁定？
  • 群内 FAQ 检索机器人由谁搭建与维护？
RND-30研发编码与工程协作规范宣贯待优化36

状态：待优化｜证据：有证据（卡片 10 张 / 会话 6 个）｜优先级：频3 × 耗2 × 跨2 × 险3

  • 适用场景：新团队开始协作、新人加入、出现编码风格/提交方式/本地环境/文档载体/群聊沟通问题，或规范新增变更时，统一制定、落地工具检查并宣贯
  • 负责人：主责——研发技术负责人（研发规范 owner）（当前：王皓南·推断待确认）；协同——前端规范维护人（当前：季学森·推断待确认）、后端与 Git 规范维护人（当前：宋祺睿·推断待确认）、ESLint/TS 规范维护人（当前：陈晖·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞各端规范维护人（当前：张楠、魏小东·推断待确认）、各仓库 owner（当前：待指定）、人事负责人（当前：黄莹·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别规范缺口 → ② 规范维护人起草/更新 → ③ 研发评审 → ④ 落库并工具化（lint、hook、CI、PR 模板）→ ⑤ 研发通知群发布变更 → ⑥ 纳入新人入职清单 → ⑦ PR 评审执行 → ⑧ 季度复审
  • 交付结果：成文的《研发协作规范》及总索引；仓库内 AGENTS.md/CODE_STYLE/README 与 lint 配置；群公告中的沟通约定；新人规范阅读确认记录
  • 状态依据：已有 AGENTS.md、CODE_STYLE、ESLint/Prettier 配置、《Git 操作指北》、仓库 README，但规则靠群里宣布和点名纠正，同类问题反复提醒约 4～8 次，规则文件维护人和更新时点不明，仓库间口径不一

1. 场景判定

  • 触发条件：新团队/新人加入协作；同一类问题被提醒 ≥ 2 次；重构后出现回归；新增仓库或技术栈；群聊沟通混乱、报障缺信息
  • 典型说法：「现在要协作了，就得说了」「commit message 最低要求是一句人话」「本地临时改的东西别提交」「研发通知群别闲聊」「问题讨论请用话题」「养成用飞书文档的习惯」「eslint 统一配置」
  • 判断问题：这条约定是否需要所有研发长期遵守？能否写成文件并用工具检查？
  • 不归本流程管：分支模型与合并方式 → 请走 RND-31；PR 评审合并 → 请走 RND-32；AI 编码协作约束 → 请走 RND-28；技术栈与组件库选型 → 请走 RND-16；新人环境搭建 → 请走 RND-21；工单状态规范 → 请走 RND-11；重构报备 → 请走 RND-17；技术文档沉淀 → 请走 RND-86

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范 owner 规范总索引、评审、发布、季度复审 A 研发技术负责人（当前：王皓南·推断待确认）
前端规范维护人 前端规则、AGENTS.md/cursor rules 同步 R 前端负责人（当前：季学森·推断待确认）
后端与 Git 规范维护人 提交规范、命名、README 维护 R 后端研发（当前：宋祺睿·推断待确认）
lint 配置维护人 ESLint/TS 统一配置与 CI 接入 R 基座组架构（当前：陈晖·推断待确认）
跃竞规范维护人 跃竞各端 CODE_STYLE、docs/ 事实源 R 跃竞研发（当前：张楠、魏小东·推断待确认）
仓库 owner PR 评审按规范检查、违规打回；本仓库规则争议决定 R 各仓库 owner（当前：待指定）
测试负责人 报障模板、话题沟通约定 C 测试负责人（当前：张东郅·推断待确认）
人事 规范阅读纳入入职清单；屡次违规约谈 C 人事负责人（当前：黄莹·推断待确认）
全体研发 阅读确认、遵守、提出修改 I 全体研发

3. 办之前请准备

  • 问题实例（链接到 PR、群消息或工单），说明重复次数和影响
  • 现有相关规则所在位置（哪个仓库哪个文件）
  • 能否工具化（lint 规则、commit hook、CI 检查、PR 模板项）
  • 适用范围：全公司 / 某产品线 / 某仓库

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现缺口：同类问题第 2 次出现即登记到规范待办 任一研发 发现当天 规范待办表 待办条目 🔧飞书固化
2 起草或修改：写进对应仓库 AGENTS.md/CODE_STYLE/README，跨仓库通用的写入 wiki 总规范 对应维护人 登记后 3 个工作日内 Gitea/飞书 wiki 规范 PR 🤖自动化
3 评审：规范 PR 至少 1 名其他端负责人通过；有争议由规范 owner 裁定 规范 owner PR 后 2 个工作日内 Gitea PR 评审结论 👤人工判断
4 工具化：lint 告警按错误处理，commit message/调试代码/本地配置文件用 hook 拦截，PR 模板加检查项 维护人 合并后 5 个工作日内 ESLint/hook/CI 门禁 🤖自动化
5 发布：研发通知群发变更摘要和链接，更新总索引 规范 owner 合并后 1 个工作日内 研发通知群/wiki 变更通知 🤖自动化
6 新人：入职清单含规范总索引和 Git 教程，3 个工作日内阅读并确认 全体研发（新人）/人事 入职 3 个工作日内 飞书任务 阅读确认 🔧飞书固化
7 执行：PR 评审按规范检查，违规打回并引用条款，不在群里重复口头说明 仓库 owner 每次 PR Gitea PR 评审意见 👤人工判断
8 复审：每季度检查规则是否过期、多处副本是否一致 规范 owner 每季度首月 wiki 复审记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《研发协作规范》总索引（wiki）；各仓库 AGENTS.md/CODE_STYLE/README；统一 ESLint 配置；研发群公告
  • 规范最低条款建议：commit message 一句人话说明改了什么，git 账号配置一致；拉代码用 pull --rebase；本地为跑通临时改的模型/密钥配置不提交；不提交 console.log 调试代码；禁用 any 与 as unknown，前后端共用类型由后端导出；前端补全 aria 属性；Gitea 操作用 tea 不用 gh；本地开发统一用 docker；tag/branch 命名见 README；复杂业务逻辑写中文注释；AI 生成内容标注并带免责提示
  • 沟通约定：研发通知群只发会议、CI/CD 通知、纪要、汇报；讨论在产研测群并用话题；3 人及以上的问题在群里讨论，2 轮解决不了拉会，结论落到群和工单；报障必须带环境；对内文档用飞书文档或仓库 md，Word/PDF 仅对外

6. 异常与升级

  • 规则有争议（如命名风格、合并方式）→ 仓库 owner 决定本仓库；跨仓库争议由规范 owner 2 个工作日内裁定
  • 同一人同类违规累计 3 次 → 仓库 owner 报规范 owner，必要时与人事约谈
  • 多处规则副本冲突（如 cursor rules 与 AGENTS.md）→ 以总索引指定的主文件为准，1 周内同步
  • 新团队并入协作 → 并入当周召开一次规范宣贯会

7. 衡量指标

  • 重复提醒次数：同一条规范在群里被口头提醒的次数，目标每季度 ≤ 1
  • 工具化率：可自动检查的条款中已接入 lint/hook/CI 的比例，目标 ≥ 80%
  • 仓库覆盖率：活跃仓库具备 AGENTS.md/README 规范入口的比例，目标 100%
  • 新人确认率：入职 3 个工作日内完成规范阅读确认的比例，目标 100%
  • 通知群违规消息数：每月统计，目标逐月下降

8. 低效诊断

  • 新团队并入协作时未宣贯 Git 规范，重构改坏功能导致测试重复测｜依据：「鼎慧产研决策部」2026-05
  • 规则文件维护人互相推，AGENTS.md 与 cursor rules 两处需同步｜依据：「工程咨询产研」2026-01
  • commit message、调试代码、本地配置被提交等问题反复点名纠正｜依据：「工程咨询产研」2026-01、「工程咨询产研」2026-02
  • 群聊讨论刷屏难回溯，报障不带环境，开发环境异常只在少数人之间传｜依据：「工程咨询产研」2026-02
  • 通知群用途未成文，同一规则重复提醒约 4 次｜依据：「研发通知」2026-07
  • 规范散落在各仓库 README，没有总索引和变更通知｜依据：「研发通知」2026-07、「研发通知」2026-10
  • 统一 ESLint 配置多次催评审，版本差异导致返工｜依据：「跃迁基座」2026-03
  • 跃竞各端规范分散，前后端文档口径反复对齐｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09
  • 私聊或线下沟通结论未同步，需求当初没确认导致争论｜依据：「Leap产研测」2026-08

9. 分支变体

  • Leap 产研（v5/LeapNew/LeapAgent）：以仓库 AGENTS.md 和 README 为载体
  • 鼎慧字字可研：前端 Vue/TS 规范；测算类新增表按“数据结构 → 计算引擎 → UI 绑定”三步
  • 基座组：以《跃迁基座 TS 后端开发规范》为准
  • 跃竞/跃玩：Java/Go 后端、uni-app/H5 前端各有 CODE_STYLE，docs/ 作为业务规则、接口契约和数据字典的统一事实源
  • 开源依赖署名（CC BY/Apache 等）合规问题 → 转法务确认

10. 待确认问题

  • 规范 owner 是否为当前研发技术负责人？各产品线是否各设一名维护人？
  • 《研发协作规范》总索引放在哪个 wiki 空间？
  • 哪些条款必须在 CI 中硬拦截，哪些仅作 PR 检查项？
  • 屡次违规是否与 RND-12 研发考核挂钩？约谈由谁发起？
  • 通知群是否设为仅管理员和机器人可发言？
RND-31Git 分支管理与协作规范待新建144

状态：待新建｜证据：有证据（卡片 10 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：新建仓库、开发新功能、多版本并行、准备发版或紧急修复，以及发生误推/强推、分支污染、源码外泄风险时，按统一分支模型、合并方式和保护规则操作
  • 负责人：主责——研发技术负责人（分支规范 owner）（当前：王皓南·推断待确认）；协同——Gitea 管理员/发版把关（当前：宋祺睿·推断待确认）、Leap 客户端仓库 owner（当前：岳阳·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）、产品经理（标注迭代）（当前：黄飞鹏·推断待确认）、法务（开源与源码保密）（当前：李瑶·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 建仓套模板（默认私有、主分支保护、禁强推、必须 PR）→ ② 从基线拉功能分支 → ③ 每日 rebase 基线、频繁提交推远端 → ④ PR 指向正确目标分支并标注迭代 → ⑤ 评审+CI 通过后人工合并 → ⑥ 发版前冻结并隔离下一版本代码 → ⑦ hotfix 合入后回合 → ⑧ 合并后删分支、核对分支状态
  • 交付结果：所有仓库统一的分支模型与保护配置；每次合并有 PR 与评审记录；发版分支只含本版本已验收提交
  • 状态依据：仅有《Git 操作指北》和基座组规范，全公司未统一；2026-03 出现强推覆盖代码，2026-09 发版前发现下一版本代码混入主线，2026-05～07 跃竞测试分支反复混入未测提交、修复被冲掉，合并方式争论无结论

1. 场景判定

  • 触发条件：新建仓库；开始一个功能或修复；同一产品需要并行维护多个版本或多个发行版；发版前冻结；出现强推、误合并、默认分支设错、AI 回退清空本地代码
  • 典型说法：「以后所有新仓库 main 都得写死不能 push，只能 PR」「有未来需求的代码提到主线的，报告下然后回滚」「dev 分支发版之前别合新提交了」「用 PR 推 test，不允许直接推送」「谁 own repo 谁决定怎么做」「新功能塞 feature/ 下面」
  • 判断问题：这次操作会不会改变共享分支（main/dev/test/release）？代码属于哪个迭代？
  • 不归本流程管：PR 评审标准与合并审批 → 请走 RND-32；封版打 tag 与发布分支剥离 → 请走 RND-50；hotfix 准入判定 → 请走 RND-54；仓库创建、归属与访问权限 → 请走 RND-22 / X-SEC-02；提交信息与编码风格 → 请走 RND-30；AI 编码误操作约束 → 请走 RND-28；CI 门禁建设 → 请走 RND-37

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分支规范 owner 制定分支模型、合并方式默认值、规则裁定 A 研发技术负责人（当前：王皓南·推断待确认）
Gitea 管理员 仓库模板、分支保护、禁用强推、权限收紧 R Gitea 管理员（当前：宋祺睿·推断待确认）
仓库 owner 本仓库合并方式、冻结与放行、分支清理 R 各仓库 owner（Leap 客户端 当前：岳阳·推断待确认；跃竞后端 当前：王子明·推断待确认）
开发者 按规范拉分支、提交、提 PR、解决冲突 R 全体研发
测试 确认 PR 已测，参与 test 分支合并审批 C 测试（跃竞 当前：赵伟龙·推断待确认）
产品经理 为需求标注目标迭代 C 产品经理（当前：黄飞鹏·推断待确认）
法务 开源发布与源码对外的合规审核 C 法务负责人（当前：李瑶·推断待确认）
CTO 分支策略争议升级拍板、多发行版分叉审批、事故追责 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求/工单编号及目标迭代（如 1.5 / 1.6）
  • 本仓库分支约定（README 中的分支模型、命名、合并方式）
  • 已读《Git 操作指北》，会用 rebase、stash、cherry-pick
  • 本地 .gitignore 已覆盖依赖目录、构建产物、本地配置与密钥文件

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建仓用模板：默认私有；main/dev（或 master/test/dev）设保护，禁强推、禁直推，必须 PR；默认分支设为开发基线 Gitea 管理员 建仓当天 Gitea 受保护仓库 🔧+👤
2 从基线拉分支，命名 feature/、fix/、hotfix/、release/，一个功能一个分支，不混入其他需求 开发者 开工时 git 功能分支 👤人工判断
3 每日开工前 rebase 基线；每次有效改动 commit 并推远端，避免本地未存档被覆盖 开发者 每日 git 远端提交 🤖自动化
4 提 PR：目标分支正确，标题写需求内容，正文含需求链接、目标迭代、测试人、是否含数据库/接口变更 开发者 自测通过后 Gitea PR 模板 PR 🔧+👤
5 合并：CI 通过+人工评审后由仓库 owner 合并；合并方式按仓库约定（默认 squash 或 rebase，不用 merge commit） 仓库 owner PR 后 1 个工作日内 Gitea 合并记录 👤人工判断
6 未来版本隔离：下一版本代码进独立版本分支或用开关关闭；脚本在发版前检出主线上属于未来迭代的提交 开发者/仓库 owner 发版前 2 个工作日 git 脚本 检出清单 🤖自动化
7 冻结：发版前冻结 dev/test 不合新提交，只收本版本修复 仓库 owner 封版起至发布 Gitea 分支保护 冻结公告 🔧+👤
8 hotfix：从线上分支拉 hotfix，合入后当天回合到 dev/test 开发者 合入当天 git 回合 PR 👤人工判断
9 合并后删除功能分支；每周机器人推送超过 14 天未合并的分支和未推送状态 仓库 owner/机器人 每周一 Gitea+飞书机器人 分支状态周报 🤖自动化

5. 交付物与模板

  • 交付物：《Git 分支与合并规范》（在《Git 操作指北》基础上升级为全公司版）；Gitea 仓库模板；PR 模板；分支状态周报
  • 建议模板/表单：分支模型说明（分支｜对应环境｜谁可推送｜合并方式）；PR 模板（需求内容｜需求文档链接｜目标迭代｜测试人｜数据库变更｜接口变更｜自测证据）；新仓库检查单（可见范围｜默认分支｜保护规则｜.gitignore｜README 分支约定）

6. 异常与升级

  • 发生强推或主线被覆盖 → 立即停止推送，Gitea 管理员从备份或他人本地恢复，30 分钟内通报仓库 owner，当天复盘
  • 主线混入未来版本代码 → 提交人报告并回滚或迁到版本分支；涉及发版的由仓库 owner 1 个工作日内决定剥离方式
  • test/验收分支混入未测提交 → 仓库 owner 重置到上一个已验证点，相关人重新提 PR
  • 冲突导致修复丢失 → 对比 PR 记录补回，测试回归确认
  • 实习生/外部人员持有强推或管理权限 → 当天收回，按 X-SEC-02 处理
  • 代码或仓库被发到外部平台（GitHub 等）→ 立即下线，报法务与 CTO（当天）
  • 合并方式有争议 → 仓库 owner 决定；跨仓库统一事项由分支规范 owner 裁定
  • 分支规范 owner 裁定后仍有异议、多发行版需长期分叉、或强推/外泄事故需追责 → 升级 CTO 拍板（A（升级），2 个工作日内；事故类当天）

7. 衡量指标

  • 强推/误覆盖事故：每月次数，目标 0
  • 发版前未来版本提交检出数：发版前一日主线上的未来迭代提交数，目标 0
  • 分支保护覆盖率：活跃仓库启用主分支保护和禁强推的比例，目标 100%
  • 修复丢失次数：因冲突或重置导致已合修复丢失的次数，目标 0
  • 长期未合并分支数：超过 14 天未合并且无说明的分支数，目标逐周下降

8. 低效诊断

  • 发版前才发现下一版本提交混入主线，只能临时决定回滚或建分支｜依据：「Leap产研测」2026-09
  • 强推覆盖代码，实习生有强推权限，规范只写给一个组｜依据：「技术部」2026-03
  • 依赖目录入库、确认 AI 命令过快带上强推参数｜依据：「鸽子群模态分群」2026-03
  • 合并方式争论近 50 条消息无结论，默认分支误设为发布分支，新人只发了 AI 工具教程漏发 Git 教程｜依据：「LeapCore（archived）」2026-05
  • 测试分支混入未测提交需要大量 cherry-pick，开发分支被整体重置，规则多次变更，修复被后续 PR 冲掉｜依据：「跃玩remote工作组」2026-05、「跃玩remote工作组」2026-06、「跃玩remote工作组」2026-07
  • 功能分支未合并、未推送的状态只能靠日报发现｜依据：「跃玩项目组」2026-09
  • 同一客户端分叉出三个版本并行修改，维护成本暴涨｜依据：「开源聚变入驻问题沟通群」2026-03
  • AI 回退清空当晚未提交工作；仓库可见范围含义不清，有外发 GitHub 风险｜依据：「跃迁AI总动员」2026-05
  • hotfix 应提到哪个分支、原型和杂项脚本放哪个仓库无约定｜依据：「Leap产研测」2026-10

9. 分支变体

  • Leap 产研（LeapNew/v5/LeapAgent）：main 为当前发布版本，下一版本开 1.x 独立分支；hotfix 规则见 RND-54
  • 跃竞/跃玩：dev = 测试服，test = 产品验收，master = 正式；dev 可直推，test/master 必须 PR 且指定测试审批；会员端发版由负责人合到统一 release 分支后提 PR；紧急修复直合 master 后回合 test
  • 多发行版（OPC/自助/渠道版）：优先用配置开关的单代码库，不长期 fork；确需分叉须 CTO 批准并指定维护人
  • 原型/杂项脚本：放个人或杂项仓库，不进产品仓库
  • 对外开源仓库（GitHub）：须经法务与 CTO 审核后发布，内部 Gitea 默认私有

10. 待确认问题

  • 全公司默认合并方式定为 squash 还是 rebase？是否允许各仓库自定？
  • Leap 与跃竞两套分支模型是否统一命名，还是各自保留？
  • 分支保护和禁强推是否由 Gitea 管理员对存量仓库一次性批量开启？时限？
  • 发版前未来版本提交检出脚本由谁开发、挂在哪条 CI？
  • 实习生与外部协作者的默认仓库权限（只读/可推功能分支）如何设定？
  • 多发行版合并为单代码库的改造是否立项，由谁负责？
RND-32PR 提交与代码评审合并待优化120

状态：待优化｜证据：有证据（卡片 43 张 / 会话 10 个）｜优先级：频5 × 耗3 × 跨2 × 险4

  • 适用场景：研发（含产品/运营用 AI 写代码）完成功能或修复，需要把代码合入 Gitea 上 main/dev/test/hotfix 等共享分支时启动。
  • 负责人：主责——Leap 研发技术负责人（当前：王皓南·推断待确认），负责 PR 规范、仓库保护规则与评审人分配；协同——PR 作者（各研发）、各仓库 Code Owner 评审/合并人（当前：LeapNew/LeapLite/LeapAgent 岳阳；v5/LeapAuth 宋祺睿；LeapCore/Cloudreve/LeapUpdate 杨云峰；字字可研 frontend 季学森；跃玩后端 王子明、前端 魏小东·均推断待确认）、测试负责人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）；兜底——研发负责人/创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 工单先行建分支 → ② 自测 + AI 预审 → ③ 按模板提 PR 且 CI 通过 → ④ 自动指派评审人 → ⑤ 评审与修改（SLA 计时）→ ⑥ 合并并同步 hotfix → ⑦ 标测试、工单流转 → ⑧ 超时 PR 日报清理
  • 交付结果：通过 CI、经至少 1 名 Code Owner 批准、关联工单、附自测证据并合入目标分支的 PR；每日待合 PR 清单有明确处理人。
  • 状态依据：Gitea PR、CI、AI review 已普遍使用，LeapLite/LeapAgent 已开严格审批，v5 有“单 PR ≤800 行、覆盖率 ≥80%”规则，字字可研有机器人通知与每日 CR；但 01～10 月各研发群反复出现“帮我合下/来个 review”式催合（Leap 产研测单周常达 40～80 次）、合并集中于单人、直推 main/force push、PR 规范靠口头且前后口径不一。

1. 场景判定

  • 触发条件：代码改动需进入他人会拉取或会部署的分支；外部同事给本仓提接口 PR；非研发人员用 AI 生成代码需合入；hotfix 需同步。
  • 典型说法：「@评审人 帮我合下」「来个 review」「没合就是没修」「我只有一个分支，所以不需要 PR 对吗」「合 PR 之前不指派审核吗」
  • 判断问题：这次改动是否会进入共享分支并最终被部署？是 → 必须走本流程，不允许直推或“先斩后奏”。
  • 不归本流程管：夜间/批量 AI 审查与全库技术债审计 → 请走 RND-33；含表结构/迁移脚本的附加检查 → 叠加 RND-34；复杂 SQL 性能评审 → 叠加 RND-35；依赖升级 → 叠加 RND-36；CI runner/流水线故障 → 请走 RND-37；发版放行 → 请走 RND-51（正式版本发布上线）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规则负责人 定 PR 模板、大小上限、合并方式、强制 PR 仓库清单、CODEOWNERS、分支保护 A Leap 研发技术负责人（当前：王皓南·推断待确认）
PR 作者 工单先行、自测、AI 预审、提 PR、处理意见、解决冲突、主动推进合并 R 研发工程师（当前：各仓库提交人）
Code Owner 评审/合并人 按清单评审、在 PR 内给结论、合并 R 客户端核心研发（LeapNew/LeapLite/LeapAgent，当前：岳阳·推断待确认）；后端/运维（v5/LeapAuth，当前：宋祺睿·推断待确认）；LeapCore 后端/部署（LeapCore/Cloudreve/LeapUpdate，当前：杨云峰·推断待确认）；前端负责人（当前：季学森·推断待确认）；跃玩后端负责人（当前：王子明·推断待确认）；跃玩前端负责人（当前：魏小东·推断待确认）
备份评审人 主评审人超 SLA 或离岗时接手 R 各仓库第二评审人（由规则负责人在仓库评审配置表中逐仓指定；未指定前由规则负责人兼任）
测试 合并后对照工单验收，发现无 PR 提交及时反馈 C 测试负责人（当前：张东郅·推断待确认）
CI 负责人 保证 PR check 可用、门禁落地 C CI 负责人（当前：吴世豪·推断待确认）
产品 非研发提交时补工单、说明需求范围 C 产品总监（当前：杨萌·推断待确认）
高风险终审 资金/计费/权限类 PR 终审，规则负责人无法裁决的争议 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 关联工单号（LEAP-xxxx / issue #N）；没有工单先建并认领，不得挂到无关人名下
  • 已拉取最新目标分支并 rebase；确认目标分支正确（主线/hotfix/迭代分支，AI 代理开的 PR 尤其核对）
  • 本地编译、lint/type-check、单测通过；commit 邮箱与 message 符合规范（type(模块): 描述）
  • 自测证据：截图/录屏/GIF（GUI 改动）、接口用例结果；功能类 PR 能现场演示
  • AI 预审结果：已处理的 finding，以及不处理的理由
  • 规模自查：一 PR 一事；超过仓库行数上限（v5 为 800 行）先拆分或约会评审
  • 风险勾选：是否涉及 DB 变更、依赖升级、资金/计费/权限/OTA、跨前后端字段

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认工单并认领；方案类/重要改动先在 issue 写方案，与技术负责人过一遍 PR 作者 开发前 issues / Gitea issue 已认领工单、方案说明 🔧+👤
2 自测并跑 AI 预审（规范 + 需求符合度、超范围、调试代码、无关文件） PR 作者 提 PR 前 本地 / AI review skill 自测证据、预审记录 🤖自动化
3 按模板提 PR：标题 type(模块)+工单号，描述写 Closes #N、影响范围、自测方式、是否进 hotfix、风险勾选；未就绪标 WIP/Draft，不请求合并 PR 作者 自测完成当天 Gitea PR 模板 规范 PR 🔧+👤
4 等 PR check 通过后再请求评审；失败先自修，主线原因需在 PR 注明 PR 作者 CI 结束后 Gitea Actions 通过的 check 🤖自动化
5 按 CODEOWNERS 自动指派评审人，机器人只推 review_requested 与合并事件到产研测群/PR 专用群 系统（规则负责人维护） 即时 Gitea + 飞书机器人 评审卡片 🔧+🤖
6 评审人参考 AI 首轮结果做人工评审，意见写在 Gitea PR 内，结论为通过/需修改/拒绝 Code Owner 普通 PR 1 个工作日内；阻塞发版/hotfix 2 小时内 Gitea review 评审结论 👤人工判断
7 作者按意见修改并回复，冲突自行 rebase；同一 PR 超 3 轮未通过，约 15 分钟当面评审 PR 作者 收到意见后 1 个工作日内 Gitea 更新后的 PR 👤人工判断
8 合并：默认 squash；资金/计费/权限/schema/OTA 类需 2 人批准（含技术负责人或 CTO） Code Owner 批准后当天 Gitea 分支保护 合入记录 🔧+👤
9 需上 hotfix 的 cherry-pick 并另提 PR，两 PR 互链；hotfix 先上的必须回合主线 PR 作者 合并后当天 Gitea hotfix PR 👤人工判断
10 工单流转为“待测试”，测试对照 PR 验收 PR 作者 / 测试 合并后当天 issues 工单状态更新 🔧+👤
11 机器人每日 10:00 汇总超 24 小时未评审、超 7 天未合并的 PR 并 @ 作者与评审人；超 14 天无动作由作者关闭或说明 系统 / 规则负责人 每日 Gitea webhook + 飞书机器人 待合 PR 日报 🤖自动化

5. 交付物与模板

  • 交付物：合入的 PR（含评审记录、CI 结果、工单关联）；每日待合 PR 清单
  • 建议模板/表单：PR 模板字段——关联工单（Closes #N / LEAP-xxxx）、改动摘要、影响模块、自测方式与证据、AI 预审结论、是否 AI 生成、风险勾选（DB 变更/依赖升级/资金计费/权限/OTA/跨前后端）、是否进 hotfix、配对 PR 链接、回滚方式
  • 仓库评审配置表（多维表格）：仓库、Code Owner、备份评审人、是否强制 PR、是否允许自审直合、PR 行数上限、覆盖率门禁、默认合并方式
  • 评审清单：是否超出工单范围、调试代码/console.log、硬编码、整库或无关文件带入、旧数据兼容、测试覆盖、文档是否过量

6. 异常与升级

  • 主评审人 1 个工作日未响应 → 机器人转备份评审人（仓库评审配置表中未配置备份评审人的，直接转规则负责人评审）→ 仍无响应当天升级规则负责人
  • 资金/计费/权限类 PR 需终审，或评审争议规则负责人 1 个工作日内无法裁决 → 规则负责人整理分歧点 → 升级 CTO 终审（A（升级），1 个工作日内）
  • 有人直推 main 或 force push 受保护分支 → 立即恢复并核查分支保护 → 2 小时内通报规则负责人，复盘权限
  • 非研发（产品/运营）AI 代码 → 必须先有工单，由对应 Code Owner 评审，只取所需改动 → 有争议升级规则负责人
  • AI 评审结论矛盾或明显误报 → 以人工结论为准，误报样例反馈到 RND-33 → 规则负责人每两周迭代提示词
  • 发版前紧急 PR 来不及评审 → 规则负责人书面同意“先合后审”，24 小时内补审
  • 资金/支付类 PR 未经评审合入 → 冻结相关发布并回滚 → 当天升级 CTO
  • 外包/实习生/新人 PR → 必须人工复核，不得仅凭 AI 结论合入

7. 衡量指标

  • 首次评审响应时长 = 请求评审到首个评审结论的工作时长，目标中位数 ≤ 4 小时、P90 ≤ 1 个工作日
  • PR 合并周期 = PR 创建到合并的自然日，目标中位数 ≤ 2 天
  • 催合消息数 = 产研群内“帮我合/来个 review”类消息周计数，目标较基线下降 80%
  • 单人合并占比 = 最高合并人合并数 / 总合并数，目标 ≤ 50%
  • 直推/强推次数 = 受保护分支非 PR 提交次数，目标 0
  • 超大 PR 占比 = 超出仓库行数上限的 PR 占比，目标 ≤ 10%
  • 合并后回归 = 合并后 7 天内归因到该 PR 的缺陷数，持续下降

8. 低效诊断

  • 现象：评审与合并集中在单一合并人，作者只能在群里反复 @，深夜/周末等合并（评审人分配环节缺失）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：哪些仓库强制 PR、谁有合并权、能否自审直合、是否必须指派评审，口径前后不一（规则制定环节未成文）｜依据：「Leap产研测」2026-07、「工程咨询产研」2026-04
  • 现象：直推 main、force push 致历史分叉、主线被回滚（分支保护环节缺失）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08、「工程咨询产研」2026-01
  • 现象：超大 PR、一 PR 修多件事、带入调试代码/整库/过量文档，评审多轮往返（提交前自查环节缺失）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09、「鸽子群模态分群」2026-03
  • 现象：评审意见散落群聊未落到 PR，机器人通知刷屏后被关闭（通知与记录环节设计不当）｜依据：「工程咨询产研」2026-02、「Leap产研测」2026-07
  • 现象：AI 生成代码未经人审上线，出现登录类缺陷和依赖引入风险（高风险代码评审环节缺失）｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-07、「Leap产研决策部」2026-09
  • 现象：合并前不演示、不自测，到测试环境才暴露问题（合并准入缺少自测证据）｜依据：「鼎慧产研决策部」2026-01、「鸽子群模态分群」2026-05
  • 现象：PR 长期挂起导致冲突、两人重复开发同一功能（超时治理与认领环节缺失）｜依据：「鼎慧产研决策部」2026-02、「Leap产研测」2026-08、「工程咨询产研」2026-03

9. 分支变体

  • LeapNew/LeapLite/LeapAgent：严格审批；Agent 类/核心模块改动需额外向 Agent 架构评审人讲解改动
  • v5：单 PR ≤ 800 行、覆盖率 ≥ 80%；符合 PR check 可自审后合（是否仍执行待确认）
  • LeapAuth/LeapCore/Cloudreve/LeapUpdate：由后端/LeapCore 负责人合并，开发者无权限时找仓库管理员
  • 字字可研 frontend/agent：机器人推送 + 每日固定时段集中 CR；默认 squash；前后端字段联动需两端 PR 互链一并合并；agent 包需同步发 npm 版本
  • 跃玩/EasyPlay、LeapPay 等资金类仓库：白名单合并、仅管理员可合，AI 评审 + 人工双检，资金逻辑必须人工终审
  • FDE SaaS：PR 门禁限制改动模块数、代码行数、函数数量
  • 非研发 AI 提交：工单先行、标记 AI 生成、不得直接合并
  • hotfix：主线 PR 与 hotfix PR 各一份并互链

10. 待确认问题

  • 主责是否为 Leap 研发技术负责人？字字可研、跃玩是否各设本线主责？
  • 各仓库 Code Owner 与备份评审人名单（尤其 LeapNew/LeapAgent 的第二评审人）？
  • 评审 SLA“普通 1 个工作日、hotfix 2 小时”是否可行？
  • PR 行数上限统一为多少（已出现 500/800/1000 行三种提议）？是否推广到全部仓库？
  • “是否需要 CR 由发起人决定”与“至少 1 人批准才能合并”两种口径以哪个为准？
  • 无工单的小修复（如依赖升级、chore）是否允许免工单？
  • 默认合并方式统一为 squash 是否适用所有仓库？
  • 资金/计费/权限类 PR 是否强制 2 人批准，终审人是谁？
  • 评审请求统一发产研测群，还是新建 PR 专用通知群？
RND-33AI 代码评审与夜间自动评审待新建48

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频4 × 耗2 × 跨2 × 险3

  • 适用场景：需要用 AI 对 PR 做首轮机审、对仓库做夜间批量审查，或对代码库做全库 Bug/技术债审计时启动。
  • 负责人：主责——AI 评审机制负责人（当前：王皓南·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认，Gitea 集成与日常 CR）、测试负责人（当前：张东郅·推断待确认，评审 skill）、跃玩后端负责人（当前：王子明·推断待确认，跃玩审计）、CI 负责人（当前：吴世豪·推断待确认，定时任务托管）、各仓库 Code Owner；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 定审查范围与触发方式 → ② 合规与成本审批 → ③ 统一 skill/提示词并部署到服务器 → ④ 自动运行（PR 触发/夜间定时/月度审计）→ ⑤ 结果回写 PR 或生成报告 → ⑥ 人工复核分级 → ⑦ 转工单整改 → ⑧ 月度误报与成本复盘
  • 交付结果：PR 上的 AI 评审评论；每日夜间评审报告与月度全库审计报告（飞书文档）；按阻塞/建议/误报分级并已转为工单的整改项；月度成本与采纳率统计。
  • 状态依据：已有“Qoder 自动代码 Review Workflow”方案文档、PR 触发 AI 审查试验和跃玩全库审计报告；但夜间任务运行在个人电脑 tmux 进程，曾因时区错误未触发、因费用暂停、进程消失；审查结果只以文件发群，无回写 PR、无整改闭环；多种工具各用各的，无统一标准。

1. 场景判定

  • 触发条件：PR 创建/更新需要首轮机审；每日夜间批量审核心仓库；发版前或怀疑技术债堆积时做全库审计；接手无人认领的代码仓库。
  • 典型说法：「能不能给 Gitea 接模型审 PR」「纯审没用，还是得靠测试」「review clean 的判定是不是有点过于宽松了」
  • 判断问题：这次要的是“机器先看一遍、产出待人复核的意见”吗？是 → 本流程；要决定能否合并 → 以 RND-32 人工评审为准。
  • 不归本流程管：PR 人工评审与合并决策 → RND-32；CI 门禁与 runner → RND-37；慢 SQL 专项治理 → RND-35。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
机制负责人 定工具、触发方式、提示词/skill 版本、成本上限，月度复盘 A Leap 研发技术负责人（当前：王皓南·推断待确认）
集成实施 Gitea/CI 集成，评审机器人与飞书推送机器人（第 4 节中的“系统/飞书机器人”）部署到服务器，结果回写 PR R 后端/运维（当前：宋祺睿·推断待确认）
Skill 维护 维护评审 skill、误报样例库 R 测试负责人（当前：张东郅·推断待确认）
定时任务托管 提供 runner、监控夜间任务 R CI 负责人（当前：吴世豪·推断待确认）
仓库复核人 复核 AI 意见、分级、建工单 R 各仓库 Code Owner（当前：见 RND-32）
跃玩审计 跃玩全库审计与整改跟踪 R 跃玩后端负责人（当前：王子明·推断待确认）
开发者 阻塞项整改，修复 PR 走 RND-32 R 各仓库研发
预算与推广 合规与预算审批、超预算加额度、是否推广到全部仓库 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
财务 模型/订阅费用归集 I 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 被审仓库清单、默认分支、排除目录
  • 统一评审 skill/提示词版本（含公司评审清单：权限、事务、软删除、旧数据兼容、调试代码、超范围、硬编码）
  • 模型账号与额度；单日/单月费用上限；可外送代码的服务商范围（合规确认）
  • 运行环境：服务器或 CI runner（不用个人电脑），时区设为 Asia/Shanghai
  • 输出位置：PR 评论、飞书文档目录、工单标签

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定启用范围：PR 首轮机审（全部仓库）、夜间批量（核心仓库）、全库审计（月度/发版前） 机制负责人 启用前 1 周 飞书文档 范围清单 👤人工判断
2 合规与成本审批：代码外送范围、单月费用上限 机制负责人 → CTO 启用前 飞书审批 审批记录 🔧飞书固化
3 评审机器人部署到 CI runner/服务器；PR 打开或更新时自动触发，结果写成 PR 评论（输出文件，不贴全文进群） 集成实施 审批后 2 周内 Gitea Actions PR 评审评论 🤖自动化
4 夜间批量：22:00 拉最新默认分支，多轮评审至 REVIEW CLEAN 或达 5 轮上限，生成报告；AI 修改只能以分支+PR 形式提交 系统 每日 22:00～次日 08:00 qoder/Claude/codex + 定时任务 当日评审报告 🤖自动化
5 次日 10:00 前推送报告链接并 @ 各仓库复核人 飞书机器人 次日 10:00 前 飞书机器人 报告卡片 🤖自动化
6 复核：逐条标注 阻塞/建议/误报，阻塞项建工单并指派 仓库复核人 报告发出后 1 个工作日内 Gitea issue 整改工单 👤人工判断
7 阻塞项整改，修复 PR 走 RND-32 开发者 3 个工作日内 Gitea 修复 PR 👤人工判断
8 全库审计：每月第 1 周或发版前跑一次，输出报告并逐条认领 机制负责人 / 跃玩审计 每月第 1 周 AI 审计 + 多维表格 审计报告、认领表 🔧+🤖
9 月度复盘：覆盖率、采纳率、误报率、成本、发现缺陷数，迭代 skill/提示词 机制负责人 每月末 飞书文档 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：PR 评审评论；夜间评审报告；全库审计报告；整改工单；月度复盘
  • 评审报告模板：日期、仓库、提交区间、发现项（编号、文件/行、类别、严重度、证据、建议修复）、评审轮次与结论、本次费用
  • 整改登记表字段：发现项编号、仓库、严重度、复核人、复核结论（采纳/误报/暂缓）、工单号、整改人、截止日、状态
  • 运行手册：运行位置、日志查看、手动触发、重启方法、负责人与备份人（在现有 Qoder 自动评审 Workflow 文档基础上更新）

6. 异常与升级

  • 次日 10:00 未收到夜间报告 → 机器人告警 → CI 负责人当天恢复
  • 费用触达上限 → 自动暂停 → 机制负责人 1 个工作日内决定是否加额度，超预算升级 CTO
  • 启用前的代码外送合规与单月费用上限审批、超出年度/月度预算、或决定推广到全部仓库 → 机制负责人提交方案 → 升级 CTO 审批（A（升级），2 个工作日内）
  • 单份报告误报率 > 50% → 暂停对该仓库自动评论 → 机制负责人一周内调整提示词
  • AI 直接推送默认分支 → 立即回滚 → 当天通报机制负责人并收紧权限
  • AI 建议涉及数据回滚、资金逻辑 → 只作参考，必须人工判定，不得按 AI 建议直接执行
  • 审计发现无人认领的仓库 → 当天由产品线负责人指定接手人

7. 衡量指标

  • 自动评审覆盖率 = 触发 AI 评审的 PR 数 / 总 PR 数，目标 ≥ 95%
  • 采纳率 = 标为采纳的发现项 / 总发现项，目标 ≥ 40%
  • 误报率 = 误报 / 总发现项，目标 ≤ 30%
  • 阻塞项整改周期 = 建工单到关闭的工作日，目标 ≤ 3 天
  • 夜间任务成功率 = 按时产出报告天数 / 计划天数，目标 ≥ 95%
  • 预算执行率 = 月度实际费用 / 预算，目标 ≤ 100%

8. 低效诊断

  • 现象：夜间评审跑在个人电脑进程里，时区配置错误首日未触发，进程挂掉无人知晓（运行托管环节单点）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：审查报告只以文件发群，没有转工单、没有整改跟踪（结果闭环环节缺失）｜依据：「跃玩项目组」2026-01、「跃玩remote工作组」2026-07
  • 现象：多种 AI 工具轮流审，结论不一致、误报多，链条过长（工具与提示词未统一）｜依据：「鼎慧产研决策部」2026-04、「Leap产研测」2026-09
  • 现象：AI 评审意见原地更新、没有评论到 PR，评审意见来自聊天而非 PR（输出位置不统一）｜依据：「Leap产研测」2026-07、「跃玩remote工作组」2026-05
  • 现象：单次评审成本口径不一，何时暂停靠个人判断（成本控制环节缺失）｜依据：「模态AI探索小分队」2026-03、「Leap产研测」2026-06
  • 现象：无测试覆盖时单靠审查发现问题有限，人工审一个方案耗时两天（与测试环节脱节）｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 触发方式：PR 触发首轮机审 / 夜间批量评审 / 月度或发版前全库审计
  • Leap 系列：Gitea + qoder/Claude/codex，多轮 + 辩论机制判定结束
  • 字字可研：Gitea 机器人 + AI 评审机器人在 PR 上给意见
  • 跃玩：全库 Bug 审计报告，开发逐条回复“已处理/先封堵”
  • 同模型审 vs 跨模型审（一种模型写、另一种模型审）；GitHub 托管仓库可用平台自带 agent，公司 Gitea 需自建

10. 待确认问题

  • 主责是否为 Leap 研发技术负责人？是否需要设“首席 Reviewer”专人？
  • 夜间评审是否恢复？迁到哪台服务器、由谁托管？
  • 统一以哪个工具/模型做首轮评审？哪些服务商在代码外送合规范围内？
  • 单月 AI 评审预算上限是多少，超限谁审批？
  • 夜间评审是否允许 AI 自动修复并提 PR，还是只出报告？
  • 全库审计频率：每月一次还是每次发版前？
RND-34数据库 Schema 变更与迁移脚本待新建180

状态：待新建｜证据：有证据（卡片 10 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨3 × 险5

  • 适用场景：功能涉及新增/修改/删除表、字段、索引，或需迁移/回填历史数据，并要推到测试库、生产库或已交付客户现场时启动。
  • 负责人：主责——产品线后端负责人（DB 变更放行人）（当前：Leap/字字可研 宋祺睿、跃玩 王子明·推断待确认）；协同——变更提交研发、研发技术负责人（当前：王皓南·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃玩运维（当前：席博田·推断待确认）、IT 运维/现场执行（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① PR 勾选 DB 变更并附迁移/回滚/回填脚本 → ② 登记变更表 → ③ 评审（含存量数据影响）→ ④ 测试库执行与新旧数据验证 → ⑤ 生产前快照 → ⑥ 生产执行（先库后服务）→ ⑦ 生产验证与登记回执 → ⑧ 客户现场升级同步
  • 交付结果：版本化迁移脚本（含回滚、回填）、经评审并在测试库演练通过的变更记录、生产执行与验证记录、更新后的迁移文档。
  • 状态依据：各线工具各异（drizzle-kit、SQL 脚本、alembic），01～09 月多次出现迁移漏表险丢生产数据、测试库漏推导致测试环境整体不可用、生产执行报错、测试服与正式服结构不一致、存量数据未兼容致老用户报错，均为事后补救；无变更登记、放行与回滚流程。

1. 场景判定

  • 触发条件：PR 含 schema 文件、migration 目录、DDL/ALTER、数据订正 SQL；字段改名/改类型；新逻辑依赖历史数据字段；客户现场版本升级。
  • 典型说法：「drizzle-kit push 下，加了字段」「有没有数据库修改，没有我就不做同步了」「上正式服需要同步表结构」「迁移脚本上线前差点丢了个表格数据」「是我没做老用户数据兼容导致的」
  • 判断问题：发版后，数据库结构或已有数据会不会和上一版本不同？会 → 本流程。
  • 不归本流程管：慢 SQL、索引性能、数据库故障应急 → RND-35；代码评审本身 → RND-32；生产数据查询/访问权限 → 请走 X-SEC-18（生产资源访问申请审批与回收）；敏感数据批量导出 → 请走 X-SEC-35（敏感数据导出与 AI 分析授权）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
变更提交人 写迁移+回滚+回填脚本，评估存量数据影响，PR 勾选并登记 R 后端/全栈研发（当前：各提交人）
DB 变更放行人 评审命名/类型/约束/顺序，执行测试与生产，登记回执 A 产品线后端负责人（当前：宋祺睿（Leap/字字可研）、王子明（跃玩）·推断待确认）
技术负责人 破坏性变更方案评审（迁移 vs 代码兼容） C 研发技术负责人（当前：王皓南·推断待确认）
测试 测试库新旧数据验证，旧报告/老用户抽查 R 测试负责人（当前：张东郅·推断待确认）；跃玩测试负责人（当前：赵伟龙·推断待确认）
运维 生产快照、执行窗口、流水线 R 跃玩运维（当前：席博田·推断待确认）
现场执行 客户现场升级执行手工步骤 R IT 运维（当前：杨明学·推断待确认）
高风险终审 删表/改类型/大批量回填终审，例外审批 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 变更说明：涉及哪些表/字段/索引，是否破坏性（改名、改类型、删除）
  • 版本化迁移脚本（按序编号）+ 回滚脚本 + 存量数据回填脚本
  • 存量数据处理方案：代码兼容 / 回填 / 封堵入口三选一，并写明兼容代码删除时机
  • 前后端配对 PR 链接（字段联动时）
  • 测试库执行记录与验证截图
  • 类型核对：金额、额度等大数字段用 decimal/numeric，防溢出
  • 客户现场：脚本不依赖联网、保留旧数据、手工步骤清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 开发前判断是否涉及 DB 变更；破坏性变更先在 issue 写方案 变更提交人 开发前 Gitea issue 变更方案 👤人工判断
2 编写迁移、回滚、回填脚本，更新 docs/migration 文档 变更提交人 随代码提交 drizzle-kit / alembic / SQL 脚本与文档 🤖自动化
3 PR 勾选“含 DB 变更”，在变更登记表新增记录 变更提交人 提 PR 时 PR 模板 + 多维表格 登记记录 🔧飞书固化
4 多人改同一迁移目录：先合先得，后合者 rebase 后重新生成迁移，群内通知相关人拉最新；CI 校验文件命名与顺序 变更提交人 合并前 Gitea / CI 无冲突迁移序列 🤖自动化
5 评审：命名、约束、默认值、索引、类型上限、存量兼容、回滚可行性；AI review 为必经项 放行人 1 个工作日内 Gitea review + AI 评审结论 👤人工判断
6 测试库执行（CI 自动执行或放行人执行），群内回执“已在 test 执行” 放行人 合并后、提测前 CI / 数据库客户端 执行回执 🤖自动化
7 测试验证新功能与旧数据（老用户、历史订单、旧报告） 测试 提测后 1 个工作日内 测试环境 验证记录 👤人工判断
8 生产执行前做快照，确认执行窗口与回滚方案 放行人 / 运维 执行前 1 小时内 云数据库控制台 快照 ID 🔧+👤
9 生产执行：先库后服务；执行前核对连接的环境；执行后登记“prod 已执行” 放行人 发版窗口内 迁移工具 / 数据库客户端 执行记录 👤人工判断
10 生产验证：核心页面、历史数据可见、错误日志；异常按回滚方案处理 放行人 + 测试 执行后 30 分钟内 监控 / 日志 验证结论 👤人工判断
11 客户现场升级：内网测试机演练迁移，手工步骤写入发布说明交现场执行 变更提交人 + 现场执行 现场升级前 2 个工作日 内网测试机 现场升级说明 👤人工判断

5. 交付物与模板

  • 交付物：迁移/回滚/回填脚本；迁移文档；变更登记记录；测试与生产执行、验证记录；快照 ID
  • 数据库变更登记表（多维表格）字段：变更编号、产品线/仓库、PR 链接、变更类型（加字段/改字段/删表/索引/数据订正/回填）、是否破坏性、脚本路径、回滚方式、存量数据处理方式、提交人、评审人、test 执行时间与执行人、prod 执行时间与执行人、快照 ID、验证结果
  • PR 模板 DB 勾选项：是否含 DB 变更、存量数据影响、是否需前端同步、执行顺序

6. 异常与升级

  • 测试环境因漏推 schema 故障 → 放行人 1 小时内补推并群内通告 → 复盘登记遗漏原因
  • 生产执行报错 → 停止后续步骤，按回滚脚本/快照恢复 → 30 分钟内升级技术负责人与 CTO
  • 上线后老数据报错 → 先封堵入口或代码兼容止损，再用经评审的回填脚本修复 → 当天告知业务方
  • 迁移序列冲突 → 后合者重新生成，放行人确认最终顺序
  • 不确定当前连接的是哪个环境 → 立即停止，核对后再执行
  • 提出“推倒重来/删库重建” → 生产与已交付环境禁止，必须写迁移脚本保留旧数据；例外由 CTO 审批
  • 删表、改字段类型、大批量回填等破坏性/高风险变更 → 放行人评审通过后提交终审 → 升级 CTO 拍板（A（升级），生产执行前 1 个工作日）

7. 衡量指标

  • 登记覆盖率 = 已登记 DB 变更数 / 实际含 DB 变更的 PR 数，目标 100%
  • 迁移相关故障数 = 漏推、漏表、执行报错、类型溢出导致的环境故障，目标每季度 0
  • 存量数据回归缺陷 = 上线后 7 天内老数据报错工单数，目标 ≤ 1 个/版本
  • 环境结构一致性 = 发版后测试与生产 schema 自动比对差异项，目标 0
  • 生产快照率 = 有执行前快照的生产变更 / 全部生产变更，目标 100%

8. 低效诊断

  • 现象：迁移脚本漏表险丢生产数据，靠 AI 评审偶然发现（评审环节无迁移专项检查）｜依据：「鼎慧产研决策部」2026-01
  • 现象：测试库忘推 schema，测试环境整体不可用、生成失败（测试库执行环节靠人记）｜依据：「工程咨询产研」2026-04、「工程咨询产研」2026-05
  • 现象：迁移状态无记录，已完成的迁移被重复写脚本；正式环境发布后才发现旧报告不可见（变更登记环节缺失）｜依据：「工程咨询产研」2026-02
  • 现象：DDL 贴群手工同步，字段漏加、迁移忘跑，测试服与正式服不一致（执行与登记环节手工）｜依据：「跃玩remote工作组」2026-04、「跃玩remote工作组」2026-05、「跃玩remote工作组」2026-06
  • 现象：上线脚本在生产执行报错，临时提前执行部分脚本（生产演练环节缺失）｜依据：「跃玩项目组」2026-09
  • 现象：新逻辑上线后老用户/历史订单报错，多次事后回填（存量数据评估环节缺失）｜依据：「跃玩remote工作组」2026-06、「跃玩remote工作组」2026-07
  • 现象：多人同时改迁移目录，需反复重新生成（迁移序列协调环节缺失）｜依据：「Leap产研测」2026-08
  • 现象：发布后才问有无备份，备份只有按天快照（备份环节未前置）｜依据：「工程咨询产研」2026-05
  • 现象：字段类型前后端理解不一、number/string 反复改导致构建失败（跨端字段约定环节缺失）｜依据：「工程咨询产研」2026-01、「工程咨询产研」2026-02

9. 分支变体

  • Leap v5：迁移文件由工具生成，多人冲突时后合者重新生成
  • 字字可研：drizzle-kit push；纯加字段（向后兼容）随版本推送，业务数据迁移需在测试库演练；前后端字段联动需配对 PR 与 npm 包版本
  • 跃玩：SQL 脚本 + Drone 流水线，dev/test/prod 三环境；会员端、星域、弈荟分别发布；删表重建与加字段两类
  • 已交付客户现场（私有化/内网）：alembic 迁移，脚本不得联网，必须保留旧数据，手工步骤交现场执行
  • 存量数据处理三种方式：代码兼容 / 脚本回填 / 封堵入口

10. 待确认问题

  • 各产品线 DB 变更放行人是否为上述人员？是否设备份放行人？
  • 测试库迁移是否统一改为 CI 自动执行？
  • 生产 DB 变更是否走飞书审批？审批人是谁？
  • 生产执行前快照是否强制，由放行人还是运维执行？
  • 跃玩是否引入版本化迁移工具替代手工同步？
  • 金额/额度字段统一用 decimal/numeric 是否写入编码规范？
RND-35数据库性能、慢 SQL 治理与数据库故障应急待新建300

状态：待新建｜证据：有证据（卡片 5 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：新增复杂查询（统计、排行、大表 JOIN、递归、导出）上线前，或生产数据库出现高负载、慢查询、连接池耗尽、OOM、闪断告警时启动。
  • 负责人：主责——产品线数据库/架构负责人（当前：跃玩 王子明·推断待确认；Leap 待指定）；协同——后端研发（当前：张楠、蒋兴武（跃玩），邓乾、柯逸飞（Leap）·推断待确认）、运维（当前：席博田·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、产品线业务负责人（当前：徐莉·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 复杂 SQL 上线前 explain 评审 → ② 测试库验证与压测 → ③ 慢查询/连接/内存告警 → ④ 故障定级与指挥分工 → ⑤ 止损（杀会话/限流/超时/扩容）→ ⑥ 根因定位（含厂商工单）→ ⑦ 修复并压测后热修 → ⑧ 书面复盘与改进项跟踪
  • 交付结果：复杂 SQL 评审与压测记录；故障处置时间线；书面复盘报告（根因、影响、改进项）；厂商工单与升配决策记录。
  • 状态依据：04～09 月多次生产数据库事故（手工执行未审递归 SQL、排行榜全表扫描、并发 worker 打满、连接池耗尽、内存 OOM 进入恢复模式），每次在群里并行猜测，同一故障先后被归因为厂商闪断、负载过高、内部 SQL；复盘只在群聊，无 SQL 评审与压测准入、无故障分级与值班。

1. 场景判定

  • 触发条件：PR 含大表 JOIN、无索引 COUNT、递归/物化查询、全表聚合、导出；告警群短时间内大量告警；业务方反馈后台/小程序不可用或 AI 回复变慢；节假日前容量评估。
  • 典型说法：「出来认领，一直卡着」「得让 AI 给你优化一下 SQL 了」「谁想 JOIN 得审批」「所以又是云厂商的锅？」
  • 判断问题：问题是否落在数据库（连接数、CPU、内存、慢查询）上？是 → 本流程；只是表结构变更 → RND-34。
  • 不归本流程管：表结构变更与迁移 → RND-34；应用服务/网关等非数据库故障 → 请走 RND-75（线上/测试环境故障响应与复盘）；云资源采购付款 → 请走 FIN-01（对公采购申请与付款审批）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
故障指挥 / SQL 评审人 定级、分工、决定止损与热修/回滚；复杂 SQL 上线前评审 A 产品线数据库/架构负责人（当前：王子明（跃玩）·推断待确认；Leap 待指定）
值班研发 告警响应、初步定级、P0 拉应急群 R 按值班表轮值的后端研发（当前：待排班）
业务决策 判断业务影响、对俱乐部/客户口径、优化与升配取舍 A（升级） 产品线业务负责人（当前：徐莉（跃玩）·推断待确认）
SQL 定位与优化 抓会话、执行计划、改 SQL/索引/缓存 R 后端研发（当前：张楠、蒋兴武（跃玩）；邓乾、柯逸飞（Leap）·推断待确认）
厂商对接 提工单、约工程师、结论书面归档 R 后端研发（当前：张楠·推断待确认）
运维 监控告警、日志、连接池参数变更记录、归因报告 R 运维（当前：席博田·推断待确认）
压测 修复后与节前压测 R 测试负责人（当前：赵伟龙·推断待确认）
架构与兜底 限流/读库/缓存架构建议，P0 升级决策与预算 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 监控入口：Grafana、云数据库控制台、慢查询日志、连接数/CPU/内存
  • 生产库账号清单：只读账号与可终止会话的管理员账号（账号密码不在群里传）
  • 既有参考：限流设计文档、大 SQL 排查报告
  • 值班表、应急群模板、对客话术模板
  • 上线前评审材料：SQL 文本、explain analyze 结果、数据量级、预估 QPS、压测脚本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 PR 勾选“含复杂 SQL”，附执行计划与数据量级；AI 检查全表扫描、递归、无索引 COUNT 后端研发 提 PR 时 Gitea + AI 执行计划 🤖自动化
2 评审：大表 JOIN、递归、导出需数据库负责人批准；默认语句超时 2s（导出例外） 数据库负责人 1 个工作日内 Gitea review 评审结论 👤人工判断
3 测试库验证并压测，保留回滚方案；节前 5 个工作日做容量评估 测试 + 后端研发 上线前 压测工具 压测报告 👤人工判断
4 慢查询、连接池、内存阈值告警推群并 @ 值班人 运维 常态 Grafana + 飞书机器人 告警卡片 🔧+🤖
5 值班人响应并定级：P0 主业务不可用 / P1 部分降级；P0 拉应急群 值班研发 告警后 10 分钟内 飞书群 定级 👤人工判断
6 指挥人分工：会话与慢 SQL、应用日志、业务沟通各一人 故障指挥 定级后 10 分钟内 飞书群 分工 👤人工判断
7 止损：终止长会话（手工长查询按客户端追到执行人）、限流、调超时、加连接数、临时升配 故障指挥 P0 30 分钟内 数据库控制台 服务恢复 👤人工判断
8 业务负责人对俱乐部/客户发说明 业务负责人 P0 30 分钟内 飞书 / 客户群 对外通知 🔧飞书固化
9 根因定位：以执行计划验证（不只静态分析）；疑似厂商问题提工单、约工程师并书面归档结论 后端研发 / 厂商对接 24 小时内 云工单 根因结论 🤖+👤
10 修复：SQL/索引/缓存/读库；同链路相似 SQL 一并排查；压测通过后再热修 后端研发 + 测试 P0 后 3 个工作日内 Gitea 修复 PR、压测报告 👤人工判断
11 优化不可行时，业务负责人与 CTO 决定升配/换方案并走审批 业务负责人 / CTO 根因确认后 1 个工作日内 飞书审批 决策记录 🔧飞书固化
12 复盘：AI 汇总群消息生成时间线草稿，指挥人补根因与改进项（负责人+截止） 故障指挥 P0/P1 后 2 个工作日内 飞书文档 复盘报告 🤖+👤

5. 交付物与模板

  • 交付物：复杂 SQL 评审记录、压测报告、故障复盘报告、厂商工单与结论、升配决策审批
  • 复盘模板字段：故障编号、级别、发现方式、时间线（发现/响应/止损/恢复）、影响范围（端、用户、订单、支付）、直接原因、根本原因、证据（慢 SQL、监控截图）、临时措施、长期改进项（负责人/截止）、对外沟通记录
  • SQL 评审清单：大表 JOIN、无索引 COUNT、递归/物化、分页方式、是否走读库、超时设置、执行计划耗时、预估 QPS

6. 异常与升级

  • 有人在生产库手工执行未审查询拖垮数据库 → 立即终止会话 → 收回长查询/写权限，当天报 CTO
  • 根因争议（厂商 vs 内部）→ 以执行计划与厂商书面结论为准，指挥人拍板 → 24 小时未定升级 CTO
  • 托管数据库无最高权限、无法定位 → 提厂商工单 → 数据库负责人跟进，必要时 CTO 评估换方案
  • 修复后再次发生同类故障 → 升为 P0 复盘并冻结相关功能发布 → CTO
  • 节前压测不达标 → 暂停非必要上线，优先限流与缓存
  • 优化不可行需升配/换方案，或对俱乐部/客户的影响口径需取舍 → 故障指挥提供根因与方案 → 升级产品线业务负责人决定（A（升级），根因确认后 1 个工作日内）
  • 升配超出业务负责人预算权限、P0 故障 30 分钟未止损或根因争议 24 小时未定 → 升级 CTO 拍板（A（升级），即时）

7. 衡量指标

  • 数据库 P0 故障次数，目标每季度 ≤ 1
  • MTTR = 告警到恢复的时长，目标 P0 ≤ 30 分钟
  • 首次响应时长 = 告警到值班人响应，目标 ≤ 10 分钟
  • 复盘完成率 = 2 个工作日内出书面复盘的 P0/P1 占比，目标 100%
  • 改进项按期关闭率，目标 ≥ 90%
  • 慢查询数 = 每周超过 1 秒的慢查询条数，持续下降
  • 复杂 SQL 上线前 explain + 压测覆盖率，目标 100%

8. 低效诊断

  • 现象：手工执行的递归查询拖垮生产库，只能靠客户端 IP 追人（生产库访问控制环节缺失）｜依据：「告警通知群」2026-04
  • 现象：排行榜全表聚合上线后 CPU 周期打满，拖慢 AI 响应（上线前性能评审缺失）｜依据：「Leap产研测」2026-07
  • 现象：两次大故障现场多人并行猜测、无指挥分工（应急指挥环节缺失）｜依据：「告警通知群」2026-09
  • 现象：同一故障先后被归因为厂商闪断、负载、内部 SQL，次日才确认；静态分析结论未用执行计划验证（根因验证环节）｜依据：「告警通知群」2026-08、「告警通知群」2026-09
  • 现象：同类大 SQL 在不同模块反复出事，配套压测滞后于上线（修复后验证环节缺失）｜依据：「告警通知群」2026-09
  • 现象：厂商结论口头转述，谁对接厂商、谁拍板升配不固定（厂商对接与预算决策环节）｜依据：「告警通知群」2026-09
  • 现象：超时、连接池参数临时来回调整，无变更记录（参数变更环节）｜依据：「告警通知群」2026-08

9. 分支变体

  • 跃玩/EasyPlay：会员端（陪玩大厅）、星域端（接单/抢单大厅）、支付/钱包、定时任务、导出；托管分布式数据库，升配由业务负责人决策
  • Leap（LeapAll 等）：统计/排行类查询改为增量更新 + 锁 + 事务，先测试库 analyze 再上线
  • 故障类型：人为长 SQL / 并发 worker 打满 / 连接池耗尽 / 内存 OOM 恢复模式 / 云网络闪断
  • 处置手段：限流、超时、缓存、读库、冗余字段、升配；更换厂商仅作评估项

10. 待确认问题

  • Leap 侧数据库/架构负责人是谁？
  • 数据库故障值班如何排班，是否与研发 oncall 合并？
  • 默认语句超时 2s（导出例外）是否作为全线规范？
  • 生产库是否全面改为只读账号，写权限按审批临时开通？
  • 升配预算多少以内由业务负责人决定，多少以上需 CEO/财务审批？
  • 大表 JOIN 是否真的需要“审批”，审批人是谁？
  • 对俱乐部/客户的故障通告由谁发、用什么话术？
RND-36依赖版本锁定与供应链管理待新建72

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨3 × 险4

  • 适用场景：部署栈或构建依赖第三方镜像、语言模块、开源底座（如 OpenClaw）时，需要锁定版本、保证可复现构建、升级前回归，或上游异常导致构建/部署失败时启动。
  • 负责人：主责——研发基础设施/发布负责人（当前：宋祺睿·推断待确认）；协同——CI 负责人（当前：吴世豪·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、LeapCore 后端/部署（当前：杨云峰·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、交付部署（当前：魏宗浩、游家豪·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 建依赖/镜像/底座版本清单 → ② 锁文件与固定版本入库 → ③ 镜像与包本地化 → ④ CI 校验（禁 latest、lock 一致）→ ⑤ 升级走 PR + 回归 → ⑥ 统一下发并通知各环境 → ⑦ 上游异常回退到已验证版本
  • 交付结果：已验证版本清单；入库且由 CI 校验的锁文件；内部镜像仓库/代理中的依赖副本；升级回归记录与各环境同步状态。
  • 状态依据：03～09 月出现开源底座新版致现场部署失败、lock 缺 resolved 致离线国测无法构建、镜像用 latest 致升级后数据库不可降级、上游模块异常卡构建，均靠临时回滚或手动重 lock；部署脚本与 updater 两处版本不一致，版本锁定方案“挤不出时间”未落地。

1. 场景判定

  • 触发条件：新增或升级第三方依赖/镜像/底座；compose、部署脚本、updater 中镜像版本变更；离线/信创环境构建；构建卡在依赖下载；客户现场部署开源底座新版本。
  • 典型说法：「latest 是错的」「依赖得锁下版本 + 本地化」「lock 不应该不含 resolved 吧」「下次就固定版本号了，防止这种突发问题」
  • 判断问题：同一个 commit 换台机器、换一天再构建/部署，结果一定相同吗？不确定 → 本流程。
  • 不归本流程管：CI runner 与构建资源 → RND-37；内部代码 PR 评审 → RND-32；数据库 schema 升级 → RND-34。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范负责人 维护版本清单、内部镜像仓库，保证部署配置单一来源 A 研发基础设施/发布负责人（当前：宋祺睿·推断待确认）
CI 校验 在 CI 中加禁 latest、lock 一致性、依赖完整性检查 R CI 负责人（当前：吴世豪·推断待确认）
仓库 owner 本仓锁文件维护、升级 PR 与回归 R 客户端核心研发（当前：岳阳·推断待确认）；LeapCore 后端（当前：杨云峰·推断待确认）
信创/离线适配 每个 tag 离线构建验证 R 信创适配负责人（当前：李子遥·推断待确认）
交付部署 现场只用已验证版本，部署前冒烟 R 交付部署（当前：魏宗浩、游家豪·推断待确认）
技术负责人 升级策略、包管理器切换决策 C 研发技术负责人（当前：王皓南·推断待确认）
测试 升级回归跑冒烟清单 R 测试负责人（当前：张东郅·推断待确认）
发现人 发现上游异常即在群/工单报告 I 任一研发、CI 或交付人员
重大决策 不可降级升级、换底座的放行 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 当前版本清单（组件、版本、来源、适用环境）
  • 内部镜像仓库/包代理地址，确认依赖已有本地副本
  • 在干净环境重新生成的 lock 文件（package-lock / go.sum 等）
  • 升级材料：上游 changelog、破坏性变更、是否可降级（数据格式）
  • 冒烟清单（示例：飞书 @ 回复、微信发文件、搜索、文档读写、OTA 升级）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 盘点各部署栈与仓库的镜像/模块/底座版本，形成清单，禁止 latest 规范负责人 首次 2 周内，之后随变更更新 多维表格 / 仓库版本文件 版本清单 🔧飞书固化
2 关键镜像推内部镜像仓库；Go/npm 依赖走内部代理或 vendor 规范负责人 新依赖引入时 镜像仓库 / 包代理 本地副本 🤖自动化
3 compose 作为唯一来源由 updater 下发，部署脚本只负责安装 updater 规范负责人 1 个迭代内 LeapUpdate / 部署脚本 单一配置源 🤖自动化
4 CI 校验：镜像不得为 latest；lock 与清单一致、含 resolved；不一致时 CI 在干净环境重生成并提交 CI 负责人 1 个迭代内上线，之后每个 PR Gitea Actions 校验结果 🤖自动化
5 升级依赖/底座：提 PR 写明新旧版本、changelog 要点、能否降级，按 RND-32 评审 仓库 owner 升级前 Gitea PR 升级 PR 👤人工判断
6 升级回归：测试环境跑冒烟清单；不可降级的升级先备份数据 仓库 owner + 测试 合并后 1 个工作日内 测试环境 回归记录 👤人工判断
7 回归通过后更新清单，机器人通知所有环境负责人（含客户现场）同步并记录同步时间 规范负责人 回归通过当天 飞书机器人 + 多维表格 同步状态 🔧+🤖
8 离线/信创：每个 tag 在离线环境构建验证，失败即阻断出包 信创适配 每个 tag 离线构建机 构建记录 🤖自动化
9 现场部署只用清单内“已验证”版本，部署前脚本跑冒烟 交付部署 每次部署前 部署脚本 冒烟结果 🤖自动化
10 上游异常（下载卡住、上游删版本、新版 bug）：回退到上一个已验证版本，记录事件 发现人 → 规范负责人 发现后 1 小时内 群 / 工单 回退记录 👤人工判断

5. 交付物与模板

  • 交付物：版本清单；入库锁文件；内部镜像/代理副本；升级 PR 与回归记录；环境同步记录；上游异常事件记录
  • 版本清单字段：组件名、类型（镜像/npm/go/底座）、锁定版本、来源地址、验证状态（已验证/禁用）、验证日期、验证人、适用环境（dev/test/prod/客户现场/信创）、是否可降级、下次评估日期
  • 升级 PR 补充项：旧版本 → 新版本、changelog 要点、破坏性变更、回滚方式、冒烟结果

6. 异常与升级

  • 发版当晚构建卡在依赖下载 → 切内部代理/vendor 或回退版本 → 1 小时无解升级技术负责人
  • 升级后数据格式不可降级导致服务不可用 → 用备份恢复并回退镜像 → 30 分钟内升级 CTO
  • 现场发现底座新版 bug → 立即回滚到清单版本，当天在清单标记“禁用” → 通知交付负责人
  • 某环境未同步修复版本 → 机器人每日比对清单与环境实际版本，不一致 @ 环境负责人
  • 离线构建 lock 缺字段 → 阻断出包，仓库 owner 当天修复
  • 计划做数据格式不可降级的升级或更换开源底座 → 规范负责人提交评估（回滚方式、备份方案、回归结果）→ 升级 CTO 放行（A（升级），升级前 1 个工作日）

7. 衡量指标

  • 未锁定依赖数 = CI 扫描出的 latest/未锁定项，目标 0
  • 构建可复现率 = 同一 commit 在离线/干净环境重建成功比例，目标 100%
  • 依赖类故障次数 = 上游或版本不一致导致构建/部署失败次数，目标每季度 ≤ 1
  • 环境版本一致率 = 与清单一致的环境数 / 环境总数，目标 100%
  • 升级回归覆盖率 = 带回归记录的升级 PR / 全部升级 PR，目标 100%

8. 低效诊断

  • 现象：部署脚本仍拉 latest 镜像，与 updater 配置不一致，服务器恰好部署在修复前版本（配置单一来源环节缺失）｜依据：「Leap产研测」2026-08
  • 现象：版本锁定改造知道要做但一直没排期，同类部署问题重复发生（规范落地环节无排期）｜依据：「Leap产研测」2026-08
  • 现象：上游模块异常在发版当晚才暴露（依赖本地化环节缺失）｜依据：「Leap产研测」2026-09
  • 现象：lock 缺 resolved，离线国测需手动重新 lock，一周内同问题出现两次（lock 校验环节缺失）｜依据：「信创LeapCore客户端适配」2026-07
  • 现象：现场部署前升级到刚发布的底座新版，连续引入多个 bug 致安装失败（升级前回归环节缺失）｜依据：「Claw布道/案例组」2026-03

9. 分支变体

  • 容器镜像（meilisearch、tika 等）：内部镜像仓库 + 固定 tag，由 updater 下发 compose
  • Go 模块：go.sum + 内部代理或 vendor
  • 前端 npm：lock 必须含 resolved，CI 自动重生成；是否切换包管理器待定
  • 信创/离线环境：禁止联网构建，每个 tag 离线验证
  • 开源底座（OpenClaw 等）客户现场部署：只用已验证版本，部署前冒烟

10. 待确认问题

  • 主责是否为研发基础设施/发布负责人，还是由 CI 负责人兼任？
  • 版本清单放仓库文件还是多维表格？
  • 依赖升级节奏：按需升级，还是每月集中评估一次？
  • 内部镜像仓库与包代理由谁维护，容量与费用谁审批？
  • 前端包管理器是否切换（npm → pnpm/bun）？
  • 开源底座“已验证版本”由研发还是交付签发？
RND-37CI/CD 流水线建设与构建资源管理待优化180

状态：待优化｜证据：有证据（卡片 16 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：需要新建或调整自动构建、nightly、镜像构建、测试门禁，或 runner/构建机/签名机出现慢、挂、排队、磁盘满、权限与凭据缺失时启动。
  • 负责人：主责——CI 负责人（当前：吴世豪·推断待确认）；协同——CI 备份负责人（当前：岳阳、宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Gitea 管理员（当前：丁震宇·部门报送人）、跃玩运维（当前：席博田·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① CI 需求/故障登记 → ② 判定类型（流水线/资源/网络/上游/不稳定测试）→ ③ 资源申请审批 → ④ IaC 创建或配置 runner → ⑤ 按模板配置流水线与门禁 → ⑥ 监控告警与定时清理 → ⑦ 凭据与配置清单化 → ⑧ 月度容量复盘
  • 交付结果：可用的 PR check、nightly、release、镜像流水线与门禁规则；runner/构建机清单（含负责人、访问权限、凭据存放）；监控告警与清理任务；资源申请审批记录。
  • 状态依据：已有 Gitea Actions、多平台 runner、IaC 创建云 runner、每日凌晨清理任务，07 月定了“一主两备”CI 负责人，镜像 tag 命名规范与扩容提单审批已落地；但 01～10 月 CI 慢、挂、磁盘满、离线反复出现，签名凭据与 runner token 无人知晓存放，构建产物空间无明确负责人，规范与清单仍未成文。

1. 场景判定

  • 触发条件：新仓库/新项目需接入 CI；PR check/nightly/release 失败、排队、超时；runner 离线或磁盘满；需新增/扩容 runner、构建机、签名机；构建产物空间不足；新服务接入集群流水线；签名证书或 Secrets 变更、交接、到期。
  • 典型说法：「Windows CI 不干活了」「公司 CICD 的资源都发给我吧」「Secrets 配了就看不到了」
  • 判断问题：问题出在流水线/构建环境，而不是我的代码？（主线同样失败、换 runner 能过）是 → 本流程。
  • 不归本流程管：PR 评审合并规则 → RND-32；AI 自动评审机制 → RND-33；依赖版本锁定 → RND-36；发版放行与 OTA 灰度 → 请走 RND-51（正式版本发布上线）；采购付款执行 → 请走 FIN-01（对公采购申请与付款审批）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
CI 负责人 流水线与 runner 维护、故障处理、门禁配置、容量规划 A CI 负责人（当前：吴世豪·推断待确认）
CI 备份 主负责人不在时接手；客户端打包、Linux runner R 客户端核心研发（当前：岳阳·推断待确认）；后端/运维（当前：宋祺睿·推断待确认）
技术负责人 门禁策略、测试豁免、不稳定测试分配、排期 C 研发技术负责人（当前：王皓南·推断待确认）
IT 运维 物理构建机、网络/代理、硬件采购执行、远程访问 R IT 运维（当前：杨明学·推断待确认）
Gitea 管理员 实例级 runner token、仓库与组织权限 R 创始人兼 CTO（当前：丁震宇·部门报送人）
跃玩运维 跃玩 Drone/k8s 流水线与新服务接入 R 跃玩运维（当前：席博田·推断待确认）
发现人/仓库开发者 登记 CI 问题、按模板写流水线 R 各研发
财务 资源采购付款 I 财务负责人（当前：黄梦婷·推断待确认）
预算兜底 资源预算审批、负责人指定 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 故障登记：仓库、workflow、job 链接、失败日志、runner 名称、发生时间、是否阻塞发版
  • 新接入需求：仓库清单、所需平台（Linux/Windows/macOS/签名）、预计并发、缓存与产物需求
  • 资源申请：机器规格、内网/云选择理由、费用估算
  • runner/构建机清单与访问权限（谁能登录、谁能重启）
  • 凭据：签名证书、Apple ID、token 的存放位置（密钥管理系统，不在群里传）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现 CI 问题后在 CI 工单/专用群登记（附 job 链接），不在大群零散询问 发现人 发现即登记 Gitea issue / 飞书机器人 CI 工单 🔧飞书固化
2 响应并定性：流水线配置 / runner 资源 / 网络 / 上游依赖 / 不稳定测试 CI 负责人（不在时按备份顺序） 工作时间 30 分钟内；阻塞发版 15 分钟内 Gitea Actions 定性结论 👤人工判断
3 不稳定测试先隔离并列清单，技术负责人分配修复人，记入不稳定测试 wiki CI 负责人 + 技术负责人 当天 飞书 wiki 隔离清单 👤人工判断
4 资源不足：提资源申请（规格、理由、费用），CTO 审批，IT 运维采购或 IaC 创建云 runner CI 负责人 → CTO → IT 运维 审批 1 个工作日；创建 3 个工作日内 飞书审批 + OpenTofu 新 runner 🔧飞书固化
5 runner 注册/升级：token 由 Gitea 管理员发放并存入密钥管理；runner 版本纳入 IaC 统一升级 CI 负责人 / Gitea 管理员 申请后 1 个工作日 Gitea / IaC runner 清单更新 🤖+👤
6 流水线规范：PR check 只跑快速集（Linux 优先），release/nightly 跑全集；WIP PR 不触发；流水线内不直接起 docker（用 dind 或专用 action） CI 负责人 新仓库接入时 workflow 模板 标准 workflow 🤖自动化
7 门禁：受保护分支要求 CI 通过才可合并，测试豁免需技术负责人批准；镜像 tag 主线 canary-、其他分支“分支名-” CI 负责人 新仓库接入时 Gitea 分支保护 门禁配置 🤖自动化
8 监控与清理：磁盘、队列长度、失败率、runner 离线、证书到期（提前 30 天）告警；每日 02:00 清理镜像/卷/缓存，取消的 job 也纳入清理 CI 负责人 常态 定时任务 + 飞书机器人 告警、清理日志 🤖自动化
9 产物存储：日构建保留最近 N 个版本，正式构建长期保留；容量达 80% 告警 CI 负责人 常态 网盘 / 对象存储 保留策略 🤖自动化
10 凭据与配置清单化：Secrets 名称、用途、配置人、到期日、存放位置及 runner 访问方式，变更当天更新 CI 负责人 变更当天 飞书文档 + 密钥管理 CI 配置清单 🔧飞书固化
11 月度复盘：平均耗时、失败率、排队时长、资源利用率，决定扩容或调整 CI 负责人 + 技术负责人 每月第 1 周 飞书文档 容量复盘 👤人工判断

5. 交付物与模板

  • 交付物：标准 workflow 模板；runner/构建机清单；CI 配置与凭据清单；告警与清理任务；资源申请审批；月度容量复盘
  • runner/构建机清单字段：名称、平台、位置（内网/云/地域）、规格、并发数、适用仓库/标签、负责人、备份人、可远程登录人员、runner 版本、是否 IaC 管理、状态
  • CI 配置清单字段：仓库、workflow、触发条件、所用 Secrets 名称（不写值）、用途、配置人、到期日、存放位置
  • CI 问题工单字段：仓库、job 链接、现象、分类、是否阻塞发版、处理人、处理结果、耗时
  • 新服务接入检查表（集群流水线）：流水线文件模板、敏感配置走 env/Secret、零副本预置、回滚预演、切流审批

6. 异常与升级

  • CI 全挂或阻塞发版 → 15 分钟内响应，30 分钟无解切备用 runner 或经技术负责人同意暂停非必要 check → 2 小时无解升级 CTO
  • runner 断电/离线且只有特定人能远程 → IT 运维 1 小时内恢复；随后增加第二名可远程人员
  • 签名凭据丢失或无人知晓 → 按清单找配置人；无记录时由 Gitea 管理员与 CTO 重新签发并补入清单
  • 证书过期致无法拉代码 → IT 运维立即续签 → 补到期监控
  • 磁盘满 → 立即清理并定位未清理的 job；同月第 2 次须修改 workflow
  • 资源采购等待超 5 个工作日 → CI 负责人在审批中催办，必要时 CTO 协调
  • 新增/扩容 runner、构建机、签名机等资源申请，或 CI 负责人/备份人需重新指定 → CI 负责人提交申请 → 升级 CTO 审批（A（升级），1 个工作日内）

7. 衡量指标

  • PR check 平均耗时 = PR 触发到 check 完成，目标 ≤ 10 分钟
  • 环境类失败率 = 环境/资源原因失败的 job / 总 job，目标 ≤ 5%
  • CI 故障响应时长，目标工作时间 ≤ 30 分钟
  • 因 CI 阻塞发版次数，目标每月 0
  • runner 可用率，目标 ≥ 99%
  • 清单完整率 = 已登记负责人与凭据信息的 runner/Secrets 占比，目标 100%

8. 低效诊断

  • 现象：“CI 谁负责”长期是“谁需要谁改”，后来才定一主两备，IT 运维表示无人力（责任分配环节）｜依据：「Leap产研测」2026-07
  • 现象：改一行版本号触发十几个 CI 占满 Windows 并发，checkout 动辄 40～55 分钟（流水线分层与资源规划环节）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • 现象：磁盘满、残留镜像卷、取消的 job 不清理，反复手动处理（清理与监控环节）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-10
  • 现象：签名变量、runner token 无人知道谁配的、存在哪（凭据交接环节）｜依据：「鼎慧产研决策部」2026-07、「鸽子群模态分群」2026-05
  • 现象：资源在群里索要、地址账号反复重发，先聊后提单（申请入口环节）｜依据：「鸽子群模态分群」2026-04、「Leap产研测」2026-09
  • 现象：v5 CI 不跑测试，main 积累失败测试，环境差异时测试被“先跳过”（门禁规则环节）｜依据：「Leap产研测」2026-09
  • 现象：构建产物空间满时不知存储由谁负责（产物保留策略环节）｜依据：「Leap产研测」2026-07
  • 现象：Windows CI 只有一人能远程，停电后 runner 离线（单点访问环节）｜依据：「Leap产研测」2026-08
  • 现象：runner 注册反复刷 token、测试服务器与编译缓存混跑占满磁盘（搭建规范环节未成文）｜依据：「鸽子群模态分群」2026-01
  • 现象：CI/CD 与可观测性建设无牵头人，日志缺失致排查失败，证书过期致无法拉代码（基建规划环节）｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05、「忠橙星行星引擎」2026-06

9. 分支变体

  • Leap 系列：Gitea Actions；Linux（全组织通用）、macOS（客户端打包/签名，目前仅部分仓库可用）、Windows（签名机，并发有限）；nightly/OTA 产物上传对象存储或网盘
  • 字字可研/早期项目：act_runner 自建，测试服务器与编译缓存需分离
  • 跃玩：Drone + k8s 集群，dev/test/prod 三环境；新服务接入需流水线模板、零副本预置、回滚预演
  • 资源形态：内网物理机 / 云端 runner（境外节点 checkout 慢）/ 本地 mac
  • 镜像 tag：主线 canary-、hotfix-{ver}，信创另有命名格式

10. 待确认问题

  • CI 主负责人当前是谁（07 月曾定技术负责人为主、后由 CI 负责人接任）？备份顺序如何？
  • IT 运维与研发 CI 负责人的边界：物理机、网络、runner 软件各归谁？
  • 云 runner 与内网机的选型原则、月度预算上限？
  • 日构建产物保留几个版本？存储由谁负责？
  • 签名证书、Secrets 统一放在哪个密钥管理系统？
  • “测试必须通过才能合并”是否对所有仓库强制？豁免由谁批？
  • 资源申请是否统一走飞书审批，审批模板由谁建？
RND-38CI/构建失败排查与恢复待新建240

状态：待新建｜证据：有证据（卡片 8 张 / 会话 4 个）｜优先级：频5 × 耗4 × 跨3 × 险4

  • 适用场景：机器人推送 nightly/release/部署失败卡片，或 runner/签名机/CI 机掉线、主线单测失败、依赖拉取失败，导致 PR 无法合并、打不出包时启动
  • 负责人：主责——CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维/网管（当前：杨明学·推断待确认）、CI 备用维护者（当前：宋祺睿、岳阳·推断待确认）、信创/Linux 打包负责人（当前：李子遥·推断待确认）、PR 主合并人（当前：岳阳·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 按模板报障 → ② CI 值班认领并初判类别 → ③ 分流到代码/脚本/机器/网络/签名责任方 → ④ 止血（切备用 runner、切镜像、降级） → ⑤ 重跑验证全链路 → ⑥ 恢复通知 → ⑦ 登记与复盘
  • 交付结果：恢复为 SUCCESS 的流水线（含补跑的 nightly/release）、群内恢复通知、CI 故障登记记录；达到复盘条件的附复盘文档与长期措施工单
  • 状态依据：已有 Leap Pal 构建卡片和 9 月指定的 CI 负责人，但 7～10 月 runner 掉线、nightly 失败、签名机故障反复发生，每次靠群里 @人临时救火，报障信息不全、无 ETA、无根因登记；领导层明确指出“缺标准化解决问题的流程”，应急方案和值班机制均未成文

1. 场景判定

  • 触发条件：构建卡片显示 FAILED/PARTIAL；部署机器人报“构建或推送失败”；runner 显示 offline 或 job 长时间排队；主线单测失败；签名、产物上传（网盘/团队空间）失败
  • 典型说法：「为啥又没 runner 了」「lite 主线又挂了」「昨晚 nightly 找不到 runner」「有没有人能救救字字的 cicd」
  • 判断问题：失败是不是发生在 CI/构建链路上（而不是我的代码在本地也跑不过）？是否已影响他人合并或当天发版？两者有一个是 → 走本流程
  • 不归本流程管：新建流水线、扩 runner、缓存与镜像方案建设 → 请走 RND-37；办公网络/出口整体中断 → 请走 X-SEC-27；申请新的 runner 机器或虚拟机 → 请走 X-SEC-17；签名证书本身申请与保管 → 请走 X-SEC-23；生产服务故障 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
CI 负责人/值班 认领、初判、协调止血、发恢复通知、登记与复盘 A/R CI 负责人（当前：吴世豪·推断待确认）
CI 备用维护者 主责不在时接手值班，搭临时 runner 兜底 R CI 备用维护者（当前：宋祺睿、岳阳·推断待确认）
IT 运维 排查网络出口、机器硬件、内存/磁盘、签名机 R IT 运维/网管（当前：杨明学·推断待确认）
最近提交人 修复代码或单测导致的失败 R 各研发（当前：待指定）
信创打包负责人 信创/Linux AppImage 流水线故障 R 信创&Linux 适配负责人（当前：李子遥·推断待确认）
研发负责人 批准临时关闭 CI 门禁、改合并规则 C 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 中断超时或影响发版时裁决资源与方案 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
首个发现者 按报障模板在群里报障并 @CI 值班 R 任何发现失败的研发/测试

3. 办之前请准备

  • 失败 job 链接、所属仓库/流水线（nightly、release、PR 检查、部署）、平台（Linux/Windows/macOS/信创）
  • 首次失败时间、是否连续失败、同一提交重跑次数
  • 涉及的 runner/机器名（注明是否只看了一台）、关键日志片段（报错前后 30 行）
  • 影响范围：阻塞了哪些 PR、是否影响当天/次日发版
  • 已尝试的动作（重跑、切镜像、清缓存），避免重复操作

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按报障模板在产研测群（或 CI 故障话题）报障，@CI 值班，不私聊 首个发现者 发现后 15 分钟内 飞书群+报障模板 报障消息 🔧飞书固化
2 认领并回复初判类别：代码/单测｜CI 脚本/依赖/缓存｜runner/机器｜网络出口/镜像源｜签名/产物存储，并给出 ETA CI 值班 工作时间 30 分钟内；发版日 15 分钟内；夜间失败次日 10:00 前 Gitea Actions、构建卡片 认领回复+ETA 👤人工判断
3 分流：代码类交最近提交人修（主线单测提修复 PR）；网络/硬件由 IT 运维与 CI 值班同时排查，不互相等待；签名问题交签名机负责人 CI 值班 认领后 30 分钟内 Gitea PR、群 指定修复人 👤人工判断
4 止血：切备用 runner/机器、切国内镜像、加依赖重试、固定工具版本；如需关闭门禁改本地验证合并，须研发负责人批准并公告起止时间 CI 值班、备用维护者 预计恢复超 2 小时即执行 runner、CI 脚本 临时方案+公告 🔧+👤
5 重跑失败 job、手动触发 nightly/release，直到全链路 SUCCESS；手动重启已死 job CI 值班 修复后 1 小时内 Gitea Actions 成功构建记录 🤖自动化
6 发恢复通知：影响时段、根因、临时措施、遗留问题；降级期间合入的 PR 全部补跑 CI CI 值班 恢复后 30 分钟内 飞书群 恢复通知 🔧飞书固化
7 登记故障；同一根因 7 天内复发 ≥2 次或中断 >4 小时，出复盘文档并为长期措施建工单 CI 负责人 登记当天；复盘 3 个工作日内 故障登记表、飞书文档、工单 登记记录/复盘文档 🔧飞书固化
8 每日巡检 nightly/PARTIAL 结果，同一提交连续失败或 PARTIAL ≥2 次主动认领 CI 值班 每个工作日 10:00 前 构建卡片、机器人汇总 巡检记录 🤖自动化

5. 交付物与模板

  • 交付物：报障消息、认领回复、恢复通知、CI 故障登记记录、复盘文档（达到条件时）
  • 建议模板/表单：
    • 报障模板：现象、流水线/仓库、平台、runner/机器、首次失败时间、job 链接、日志片段、影响范围、已尝试动作
    • 故障登记表字段：编号、发生时间、恢复时间、中断时长、类别、根因、临时措施、长期措施工单、是否复发、处理人
    • 恢复通知：影响时段、根因一句话、临时措施、遗留问题、补跑情况

6. 异常与升级

  • 30 分钟无人认领 → 自动升级 CI 备用维护者 → 再 30 分钟仍无人 → 升级研发负责人
  • 中断超 4 小时或影响当天发版 → CI 负责人升级研发部门负责人拍板（A（升级）），决定是否借机器、改发版时间（1 小时内答复）
  • 网络/硬件类且 IT 运维 2 小时内无法恢复 → 启用备用机，并报研发部门负责人
  • 需关闭 CI 门禁 → 研发负责人批准，公告起止时间，恢复后 1 个工作日内补跑全部降级期合入的 PR
  • 同一提交连续失败 ≥3 次 → 停止盲目重跑，CI 值班必须给出根因判断

7. 衡量指标

  • 认领时长 MTTA：报障到认领，目标工作时间 ≤ 30 分钟
  • 恢复时长 MTTR：首次失败到全链路 SUCCESS，目标 ≤ 4 小时
  • nightly 成功率：每月成功次数 / 总次数，目标 ≥ 90%
  • 同根因复发次数：每月同一根因重复登记次数，目标 0
  • PARTIAL 积压：连续 PARTIAL 超过 2 天无人认领的次数，目标 0
  • 降级补跑率：降级期间合入 PR 的补跑比例，目标 100%

8. 低效诊断

  • 现象：runner、签名机、CI 机断网反复掉线，靠群里喊人修，无 ETA、无根因记录；CI 每天消耗约 150G 境外流量｜依据：「Leap产研测」2026-08
  • 现象：报障晚几个小时才传到网络侧、只报了一台机器，排查方向走偏；“签名机坏了”与“签名 CI 坏了”各说各话｜依据：「Leap产研测」2026-09
  • 现象：修网络与修 CI 两条线互相等待，各 CI 的 Node/依赖版本不一，脚本依赖外网包管理器｜依据：「鸽子群模态分群」2026-07
  • 现象：nightly 连续多日失败、同一原因反复排查；PARTIAL 提醒约两周无人处理，产物网盘长期上传失败无人发现｜依据：「研发通知」2026-07、「研发通知」2026-10
  • 现象：同一提交连续失败 3～5 次靠重跑；内网 runner 访问外网依赖的问题归属不明，热修上线被耽误｜依据：「工程咨询产研」2026-07、「工程咨询产研」2026-09
  • 现象：封版前 CI 满载，临时宣布关闭 CI、本地验证后合并，“开/关”口径不一且没有补跑｜依据：「Leap产研测」2026-09
  • 现象：缓存策略变更引发 cache miss 全量下包，合并规则要求反复 rebase 导致 PR 排队一周｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09

9. 分支变体

  • 桌面端 nightly（定时）/release（手动，含签名审批）：macOS 与 Windows 分别失败，签名机由 IT 运维配合；产物上传路径失败（网盘容量、token 过期）同归本流程
  • Linux 后端 CI：CI 负责人主责，机器扩容、内存/磁盘问题由 IT 运维配合
  • 信创/Linux AppImage：信创打包负责人主责，CI 负责人协同
  • 字字可研部署流水线（测试环境部署、生产镜像构建）：优先切国内镜像、固定 Bun 版本；运维侧由后端运维协同
  • 发版当天的打包机故障：认领时限缩短为 15 分钟，并同步告知发布负责人（RND-51/RND-52）

10. 待确认问题

  • CI 负责人是否需要设轮值？备用维护者的值班顺序和联系方式写在哪里？
  • 认领时限（工作时间 30 分钟、发版日 15 分钟、夜间次日 10:00）是否可行？
  • 关闭 CI 门禁的批准人是研发负责人还是研发部门负责人？
  • 故障登记表放在多维表格还是 Gitea issue？复盘文档由谁审？
  • 字字可研/鼎慧线的部署流水线是否也归 CI 负责人管？还是由后端运维单独负责？
  • 备用 runner 机器清单和切换步骤文档由谁维护，多久更新一次？
RND-39提测、产品验收与测试验收流转待优化180

状态：待优化｜证据：有证据（卡片 27 张 / 会话 8 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：研发完成一个需求或缺陷修复、已部署到测试环境，需要经产品验收（是否符合需求）和测试验收（功能是否正确）后关闭工单时启动
  • 负责人：主责——研发负责人/工单流转规则负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试工程师（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 自测+合并+部署测试环境 → ② 按模板提测并指定验收人 → ③ 产品验收（需求类） → ④ 测试验收 → ⑤ 不通过打回修复 → ⑥ 通过关闭 → ⑦ 每日滞留巡检 → ⑧ 迭代末缺陷清零
  • 交付结果：状态为“完成”的工单，评论区留有提测信息、产品验收结论、测试验收结论（含环境与版本/commit）；“完成”的口径是验收通过，标了 ready-for-test 不算完成
  • 状态依据：已有 issues 平台状态流（产品验收→测试验收→完成）、委派功能和滞留提醒；但 2～10 月在 Leap、鼎慧、跃玩各群反复出现“做完不改状态”“没通知测试”“工单无验收人”“产品回了 ok 不改状态”“用旧版本验收”，迭代尾部曾一次积压 150 张测试验收、22 张产品验收

1. 场景判定

  • 触发条件：PR 已合并并成功部署到测试环境（或小程序体验版、开发版已出）；缺陷修复已上测试服或新包
  • 典型说法：「研发自测完成了，安排测一下」「请验收」「产品验收做了吗，通过了交接给测试」「这个需求的产品是哪位？到产品验收了」「卡在哪了，能提测吗」
  • 判断问题：代码合并了吗？测试环境部署成功了吗？工单类型是需求还是缺陷？验收人是谁？四个都答得上来才进本流程，答不上来先补齐
  • 不归本流程管：缺陷怎么提、怎么定级 → 请走 RND-03；需求没写清楚、要重新评审 → 请走 RND-04；工单字段规范、AI 改工单 → 请走 RND-11；发版前集中测试 → 请走 RND-41；冒烟与放行 → 请走 RND-42；AI 自动验收 → 请走 RND-45；UI 走查 → 请走 RND-46

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发（工单负责人） 自测、合并、部署、按模板提测、推进到完成、修复打回项 R 各研发（当前：待指定）
产品经理 需求类工单的产品验收，在工单内留结论；产品负责人裁定需求理解分歧 R 产品负责人（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）
测试负责人 分配测试验收、巡检滞留、迭代末汇总未关闭 P0/P1 R 测试负责人（当前：张东郅·推断待确认）
测试工程师 在指定环境、版本上验收，给出通过或打回 R 测试（当前：潘浩伟、涂维轩、李国庆、黄霆瑄·推断待确认）
研发负责人 维护状态流转规则，委派无验收人工单，裁决流转争议，对流程结果负责 A 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 跨团队争议、迭代延期决策 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
飞书机器人 状态变更时 @验收人，每日推送滞留清单 R（工具） 机器人维护人（当前：待指定）

3. 办之前请准备

  • 工单号、类型（需求/缺陷）、关联 PR 链接（已合并）
  • 测试环境地址与版本号/commit、构建号；客户端问题附安装包版本，小程序附体验版/开发版二维码
  • 验收指引：改动点、验收条件、怎么测、不测范围；需求类附设计稿或参考图
  • 自测证据：截图或录屏（工单不能传视频时用 GIF 或飞书文档链接）
  • 验收人：产品 = 项目负责人，测试 = 项目成员；没有挂项目的，提测时自己委派

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 自测通过，合并 PR，确认测试环境部署成功、版本包含本次 commit 研发 开发完成当天 Gitea、CI 部署成功记录 🤖自动化
2 改状态：需求类改为“产品验收”，缺陷类改为“测试验收”；按提测模板评论，并填写/委派验收人 研发 部署成功后 2 小时内 issues 平台 提测评论 🔧+👤
3 状态变更后由机器人 @验收人，附工单链接和环境、版本 机器人 实时 issues 平台 webhook+飞书机器人 待验收通知 🤖自动化
4 产品验收：对照需求和设计稿走完整用户流程，在工单评论“通过/不通过+原因+截图”，由产品本人改状态（通过转“测试验收”，不通过转“进行中”） 产品经理 收到后 2 个工作日内 issues 平台 产品验收结论 👤人工判断
5 测试验收：在提测写明的环境和版本上验证；不通过时评论“验收不通过+环境+版本+复现步骤”，转“进行中”并 @研发；通过后改“完成” 测试工程师 P0 当天；其余 2 个工作日内 issues 平台、测试环境 测试验收结论 👤人工判断
6 打回后响应并修复，修完回到第 2 步重新提测；修复期间不得在已标待验收的分支上继续提交代码 研发 打回后 1 个工作日内响应 Gitea、issues 平台 修复提交 👤人工判断
7 每日推送“待我验收”和“滞留 >2 天”清单；无验收人工单列给研发负责人委派 机器人、测试负责人 每个工作日 10:00 机器人、保存视图 滞留清单 🤖自动化
8 迭代结束前汇总未关闭的 P0/P1 和待验收数量，在站会上过；P1 未修完的功能由产品和测试决定不上线或后续 hotfix 测试负责人 迭代结束前 3 个工作日 issues 平台、站会 缺陷清零清单 🔧+👤

5. 交付物与模板

  • 交付物：提测评论、产品验收结论、测试验收结论、每日滞留清单、迭代末缺陷清零清单
  • 建议模板/表单：
    • 提测评论：类型、PR 链接、环境地址、版本/commit、改动点、验收条件、怎么测、不测范围、自测截图/录屏、验收人
    • 验收结论评论：结论（通过/不通过）、环境、版本/commit、验证步骤、证据截图、未通过原因
    • 工单必填：类型（需求/缺陷，不允许互改）、项目、产品验收人、测试验收人、优先级

6. 异常与升级

  • 工单无验收人或验收人错配 → 研发自行委派；委派功能不可用时，在滞留清单中由研发负责人当天指定
  • 滞留超 2 个工作日 → 机器人 @验收人；超 4 个工作日 → 升级产品负责人或测试负责人
  • 同一工单打回 ≥3 次 → 测试负责人拉研发、产品 15 分钟当面对齐，确认是需求不清（转 RND-04）还是修复质量问题
  • 产品与测试对需求理解不一致 → 以工单里写的验收条件为准；没写的由产品负责人 1 个工作日内裁定，并补写进工单
  • 测试人力不足导致迭代末积压 → 转 RND-41 发起测试冲刺
  • 跨团队验收争议研发负责人无法协调，或积压导致迭代需延期 → 升级研发部门负责人拍板（A（升级），1 个工作日内）

7. 衡量指标

  • 提测合规率：带环境、版本、PR、验收人的提测数 / 提测总数，目标 ≥ 95%
  • 验收平均滞留：进入验收状态到结论的工作日，目标产品 ≤ 2 天、测试 ≤ 2 天
  • 一次通过率：首次验收即通过的工单 / 验收工单总数，目标 ≥ 80%
  • 无验收人工单数：每日巡检时无验收人的工单数，目标 0
  • 迭代末积压：迭代结束日仍处于验收状态的工单数，目标 ≤ 迭代工单数的 10%

8. 低效诊断

  • 现象：提测靠群里 @，测试不知道哪些能测、环境和代码在哪，测试记录不知道存在哪里｜依据：「Leap产研测」2026-04、「Leap产研测」2026-05
  • 现象：没改好就标 fixed；fixed 和 ready-for-test 两个标签语义有争议，删标签后老缺陷状态丢失｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：研发把“待验收”当成“做完”，合并后不通知测试；测试打回后也不通知研发，全靠负责人逐个催｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-07
  • 现象：用旧 commit 或错误环境验收；测试没有 PR 读权限，看不了代码｜依据：「Leap产研测」2026-07
  • 现象：工单没有验收人，委派功能有缺陷，需求单被改成缺陷单，工单负责人被改｜依据：「Leap产研测」2026-07、「Leap产研决策部」2026-07
  • 现象：产品在群里回“ok”但不改状态、验收不留痕；迭代尾部验收大量积压｜依据：「Leap产研决策部」2026-08
  • 现象：需求细节未定就开发，到验收时才争论；产品验收已通过的功能事后被质疑有没有意义｜依据：「Leap产研测」2026-08
  • 现象：产品靠研发私下发工单才知道要验收，觉得工单系统“看不明白”；验收视频没进工单｜依据：「Leap产研测」2026-09
  • 现象：产品待验收的功能还没推到测试版，产品没法验收；验收条件没有事先给出；开发版不会自动更新｜依据：「跃玩项目组」2026-05、「跃玩项目组」2026-08、「跃玩项目组」2026-09
  • 现象：支付功能提测状态不透明，产品反复追问“卡在哪”｜依据：「LeapPay」2026-08
  • 现象：做完不改状态，测试要主动追问本迭代是否部署完｜依据：「字字可研项目群」2026-03

9. 分支变体

  • Leap（issues.leapinfra.cn）：需求类先产品验收再测试验收；缺陷类直接测试验收；P0 由测试负责人兜底验收；自动化先跑一轮，结论由人签字（RND-45）
  • 鼎慧/字字可研：业务专家按模板实测，作为产品验收的一部分；未完成的需求要在工单里写明原因
  • 跃玩/跃竞：需求表填预计提测日期 → 推体验版/测试服 → 产品验收 → 测试验证并确认“能上” → 小程序提审（RND-60）→ 发布；支付相关功能要产品和测试双确认
  • LeapPay 支付/合同：POC 与正式版的验收口径分开写明；依赖的云服务未部署时不算提测
  • 低风险变更（文案、配置）：研发负责人确认后可免产品验收，测试抽查
  • 客户定制需求：内部测试验收通过后由客户验收，结论回写工单
  • 无测试点的基建需求：只做冒烟和回归（RND-42）

10. 待确认问题

  • 流程负责人是研发负责人还是测试负责人？两条产品线（Leap、鼎慧）是否统一？
  • 产品验收和测试验收的时限各定 2 个工作日是否可行？P0 当天能否保证？
  • “提测必须带 PR、环境、版本、验收人”是否在 issues 平台上做成必填校验？
  • 跃竞是否沿用多维表格需求表，还是迁移到 issues 平台？
  • 免产品验收的“低风险变更”范围由谁界定？
  • 迭代末 P1 未修完时，不上线的决定由谁拍板（产品负责人还是研发部门负责人）？
RND-40测试体系建设与测试设计评审待新建108

状态：待新建｜证据：有证据（卡片 5 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：新团队/新产品线没有专职测试或质量靠客户发现时，建立最小 QA 流程；每个迭代需求冻结后，测试编写测试设计并组织产研评审（测试前移）时启动
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、产品经理（当前：杨萌、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 明确测试范围与 QA 状态 → ② 需求阶段测试前移 → ③ 编写测试设计与计划 → ④ 测试设计评审会 → ⑤ 用例入库与分级 → ⑥ 执行与缺陷流程 → ⑦ 自动化固化 → ⑧ 迭代回顾修订
  • 交付结果：每个迭代一份评审通过的测试设计/计划（飞书文档）、入库的用例（level1 长期/level4 一次性）、评审结论回写需求表；新团队有一套最小 QA 流程（QA 状态、缺陷模板、冒烟集）
  • 状态依据：已有一份《版本迭代测试流程》（预研→开发→QA→发布→自动化，含 P0～P3 时限），但 2～6 月聊天里仍出现“我们其实没测试”、测试岗空缺数月、后台崩了才补规范；测试设计没有统一模板，评审时间每次临时约，评审人缺席就取消

1. 场景判定

  • 触发条件：新产品线/新团队首次需要测试；迭代需求冻结（开发前）；出现线上事故后发现缺少测试环节；新测试成员入职开始负责某模块
  • 典型说法：「所以其实我们没测试」「测试的发版也得规范下」「今天需要做本迭代的测试设计评审，产研都在不在」「怎么没有测试计划，只有功能描述」
  • 判断问题：这个迭代或产品有没有事先写好的测试范围和用例？有没有人评审过？没有 → 走本流程
  • 不归本流程管：具体工单的提测与验收 → 请走 RND-39；发版前冲刺调人 → 请走 RND-41；冒烟执行 → 请走 RND-42；压测 → 请走 RND-43；安全/资金专项 → 请走 RND-44；测试岗招聘 HC → 请走 HR-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 制定测试流程与模板，组织评审，审批测试设计 A/R 测试负责人（当前：张东郅·推断待确认）
测试工程师 编写测试设计/计划和用例，执行测试 R 测试（当前：李国庆·推断待确认）
产品经理 讲清需求，确认测试对需求的理解和验收标准 C 产品经理（当前：杨萌、段涵·推断待确认）
研发负责人/模块研发 评审测试范围，给出转 QA 排期，补技术风险点 C 研发负责人（当前：王皓南·推断待确认）
领域专家 专业模块（如测算）评审 C 测算模块负责人（当前：季学森·推断待确认）
研发部门负责人 批准测试体系发布与测试人力 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 冻结的需求文档/PRD、设计稿、验收标准（来自 RND-04）
  • 测试设计模板（功能点、测试范围/不测范围、用例、测试数据、环境与账号、通过标准、风险）
  • 测试环境地址、测试账号（RND-47）
  • 上迭代遗留缺陷和线上问题清单
  • 评审参会人名单：产品、相关研发、领域专家各至少 1 人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 （新团队）先跑通最小流程：开发完成标记 QA → 测试执行 → 缺陷入工单 → 修完标通过；同时定冒烟集 测试负责人 启动后 1 周内 Gitea/issues 看板 最小 QA 流程说明 🔧+👤
2 需求冻结后，测试对着需求提问题（测试前移），疑点在需求文档评论区提，由产品回复 测试工程师、产品经理 需求冻结后 1 个工作日内 飞书文档评论 需求疑点清单 👤人工判断
3 用模板写测试设计/计划；可用 AI 依据 PRD 生成用例草稿，测试人工补充和审定 测试工程师 需求冻结后 2 个工作日内 飞书文档、AI 测试设计初稿 🤖+👤
4 测试负责人预审：检查有没有测试计划、范围、数据、通过标准 测试负责人 收到后 1 个工作日内 飞书文档 预审意见 👤人工判断
5 在迭代固定时段召开测试设计评审会，按模块分场；结论写进文档并回写需求表 测试负责人主持 迭代第 3 个工作日前，≤45 分钟/模块 飞书日程、会议 评审结论 🔧飞书固化
6 用例入库并分级：level1 长期运营（进回归/冒烟）、level4 用后即弃；提交到用例库 测试工程师 评审后 1 个工作日内 用例库（Gitea TEST_CASE_DESIGN.md 或多维表格） 入库用例 🔧+👤
7 研发给出转 QA 排期；禁止把需求都堆到迭代最后两天提测 研发负责人 评审会当天 issues 平台 提测排期 👤人工判断
8 迭代结束后把稳定的 level1 用例转自动化，并在回顾会修订模板和流程 测试负责人 迭代回顾会 自动化仓库 自动化用例、流程修订 🤖自动化

5. 交付物与模板

  • 交付物：测试设计/计划文档、评审结论、用例库条目、提测排期、最小 QA 流程说明（新团队）
  • 建议模板/表单：
    • 测试设计：需求链接、功能点、测试范围/不测范围、场景（悬浮/全屏等）、用例（编号/前置/步骤/预期/优先级）、测试数据、环境账号、通过标准、风险与依赖
    • 评审记录：日期、参会人、范围变更、需产品确认项、结论（通过/修改后通过/重审）
    • 缺陷定级时限（沿用现有流程文档）：P0 发布前解决；P1 当迭代；P2 当天出排期、1～2 个迭代内解决；P3 当周出排期

6. 异常与升级

  • 关键评审人缺席 → 指定替补；无替补时 24 小时内改期，不直接取消；改期两次仍不成 → 升级研发负责人
  • 需求在评审时仍不清晰 → 退回产品，转 RND-04，该需求暂停开发
  • 团队没有测试人员 → 测试负责人兼任或指定研发交叉测试，同时向研发部门负责人提测试 HC（HR-03），2 个工作日内答复
  • 线上出现应在测试设计中覆盖的问题 → 3 个工作日内补用例并在回顾会复盘
  • 测试流程/模板需作为正式制度发布，或需新增测试人力 → 测试负责人提交方案 → 升级研发部门负责人审批（A（升级），2 个工作日内）

7. 衡量指标

  • 测试设计覆盖率：有评审通过的测试设计的迭代需求数 / 迭代需求总数，目标 ≥ 90%
  • 评审准时率：按计划日期完成评审的次数 / 计划次数，目标 ≥ 90%
  • 测试前移发现率：需求阶段发现的问题数 / 本迭代全部缺陷数，目标逐迭代提升
  • 线上逃逸缺陷：上线后发现的 P0/P1 数，目标逐月下降
  • level1 用例自动化率：已自动化的 level1 用例 / level1 用例总数，目标季度提升 20 个百分点

8. 低效诊断

  • 现象：没有固定的测试流程，“谁来测试”反复问；字段改动导致管理后台崩溃后才补发版规范；后台是否在测试范围内要临时确认｜依据：「鼎慧产研决策部」2026-02
  • 现象：PR 里的测试用例质量受质疑，测的不是关键点｜依据：「鼎慧产研决策部」2026-02
  • 现象：测试岗空缺数月，开发兼测，把带脏数据的版本先给客户用，质量靠客户反馈｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-06
  • 现象：功能上了测试环境才补 QA 标准，测试账号怎么注册要问人｜依据：「工程咨询产研」2026-02
  • 现象：测试设计先写 Word/md 再转飞书，缺测试计划部分；模板和评审人未定｜依据：「工程咨询产研」2026-02、「工程咨询产研」2026-03
  • 现象：评审要反复约时间；关键领域评审人不在群里，评审被迫取消｜依据：「工程咨询产研」2026-03

9. 分支变体

  • 软件功能测试（输出确定）与 Agent Eval（科学评估）分两条线，Agent 评测不套用本流程的用例模板
  • 字字可研：按模块分场评审（组织审核、测算、字字助手），测算模块需领域专家参加
  • 无专职测试的新团队：先用第 1 步的最小流程，测试设计可简化为功能点清单 + 冒烟集
  • 同一功能多场景（悬浮窗/全屏/项目内）：测试设计里分场景列范围

10. 待确认问题

  • 《版本迭代测试流程》是否作为正式制度发布？由谁签发？
  • 测试设计评审的固定时段（如迭代第 2 个工作日下午）是否可行？
  • 用例库统一放 Gitea 还是飞书多维表格？两条产品线是否统一？
  • 鼎慧线测试负责人是否单独指定？
  • 没有测试人员的团队（如开放平台、跃竞以外的新项目）由谁兼测？
RND-41发版前测试冲刺与测试人力调配待优化144

状态：待优化｜证据：有证据（卡片 8 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨3 × 险4

  • 适用场景：发版前测试积压、测试“卡脖子”，或多个项目同时争抢测试人力，需要集中按用例分工测试、临时抽调研发/产品/实习生时启动
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、被抽调研发与测试（当前：待指定）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 迭代初分配测试人力 → ② 判定是否进入冲刺 → ③ 出冲刺计划与用例认领表 → ④ 抽调人员并开对齐会 → ⑤ 认领执行与提单 → ⑥ 每日站会同步 → ⑦ 出测试报告并做 Go/No-Go → ⑧ 释放人员与复盘
  • 交付结果：冲刺测试计划、用例认领表（全部用例有认领人和结果）、测试报告（通过/不通过/无法验收/新增缺陷/未关闭数）、Go/No-Go 结论
  • 状态依据：每次大版本上线前都会集中测试，有人牵头、有工单；但 2～10 月多次出现发版前一周甚至前一晚才调人、多人重复测同一功能、测试报告要反复追问、测试人员被多个项目同时占用，有的功能完全没安排测试

1. 场景判定

  • 触发条件：距发版 ≤5 个工作日，待测试/待验收工作量超过剩余测试人日；P0/P1 未关闭数超过阈值；多个项目同时进入测试且人力冲突；领导演示或对外上线日期已锁定
  • 典型说法：「现在主要是卡测试」「做完需求的研发转测试」「别测重复了，认领一下」「会有测试报告吗」「从大群里直接调人来测」
  • 判断问题：按现有测试人力，在发版日前测得完吗？测不完，或有项目没人测 → 走本流程
  • 不归本流程管：日常单个工单验收 → 请走 RND-39；冒烟与放行签字 → 请走 RND-42；版本封版与发布 → 请走 RND-50、RND-51；人员长期调岗借调 → 请走 HR-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 评估容量、出冲刺计划、拆用例、分配、出报告 A/R 测试负责人（当前：张东郅·推断待确认）
产品负责人 定上线节奏和优先级，讲功能，与测试负责人共同做 Go/No-Go R 产品负责人（当前：杨萌·推断待确认）
研发负责人 指定可抽调的研发，安排修复优先级 R 研发负责人（当前：王皓南·推断待确认）
被抽调人员 按认领用例测试、提单、回填结果 R 研发/产品/实习生（当前：待指定）
部署研发 测试服部署最新版本、发测试账号、圈定可测范围 R 发版研发（当前：葛家和·推断待确认）
研发部门负责人 跨项目测试资源取舍、批准跨项目抽调、P0 未解决时的推迟裁定 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 本版本工单清单（待测、待验收、未关闭 P0/P1）和发版日期
  • 用例：基础用户流程清单（如 LeapCore 客户端、管理后台、LeapAll C 端 A1～I5）+ 本版本新增功能用例
  • 测试服已部署最新版本，并给出“本轮可测范围/不用测范围”
  • 测试账号（含管理员账号），见 RND-47
  • 可抽调人员名单（已完成本版本开发的研发优先）及其测试能力

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 迭代开始时填测试人力分配表（项目 × 人 × 投入比例）；有冲突的报研发部门负责人取舍 测试负责人 迭代第 1 个工作日 多维表格 人力分配表 🔧飞书固化
2 每日看待测量与剩余人日，满足触发条件时宣布进入冲刺，并报产品负责人和研发负责人 测试负责人 距发版 ≥5 个工作日时判定 看板、站会 冲刺决定 🤖+👤
3 出冲刺计划：按模块拆用例，生成认领表（用例-模块-认领人-环境-结果-缺陷链接） 测试负责人 宣布后 4 小时内 多维表格、AI 生成初稿 冲刺计划、认领表 🔧+🤖
4 抽调人员：已完成本版本需求的研发先转测试，其余由研发负责人指定；自动化任务只派给有能力的人 研发负责人、测试负责人 宣布后 1 个工作日内 群公告 抽调名单 👤人工判断
5 开 30 分钟对齐会：研发/产品至少 1 人讲功能、后台结构和不测范围，说明提单规范 测试负责人主持 抽调当天 飞书会议+智能纪要 对齐纪要 🔧飞书固化
6 按认领表执行，结果当天回填；缺陷提工单（RND-03），阻塞问题在群里加急；同类问题先查重再提 被抽调人员 按计划每日完成 认领表、issues 平台 测试结果、缺陷单 🔧飞书固化
7 每日固定时间站会：过测试进度、缺陷修复、验收进展；研发在冲刺期优先修 bug，不做新功能 测试负责人 每日 17:30 站会、机器人汇总 进度快照 🤖自动化
8 出测试报告并召开 Go/No-Go：未解决 P0 不发版；P1 由产品和测试决定带病上线还是推迟 测试负责人、产品负责人 发版前 1 个工作日 飞书文档 测试报告、Go/No-Go 结论 🤖+👤
9 释放抽调人员，复盘积压原因（提测过晚、人力不足、范围变更），更新下迭代分配 测试负责人 发版后 2 个工作日内 回顾会 复盘结论 👤人工判断

5. 交付物与模板

  • 交付物：人力分配表、冲刺计划、用例认领表、每日进度快照、测试报告、Go/No-Go 结论
  • 建议模板/表单：
    • 用例认领表：用例编号、模块、优先级、认领人、环境/版本、结果（PASS/FAIL/无法验收）、缺陷链接、备注
    • 测试报告：版本、范围、执行用例数/通过率、缺陷新增/已修/未关闭（按 P0～P3）、无法验收项及原因、遗留风险、建议（发/不发/有条件发）

6. 异常与升级

  • 多项目争抢同一测试人员 → 测试负责人提出方案，升级研发部门负责人 1 个工作日内裁定优先级（A（升级））
  • 对齐会后被抽调人员仍不清楚测什么 → 测试负责人当天补用例说明或换人
  • 测试服版本不是最新、缺管理员账号 → 部署研发 2 小时内处理，否则升级研发负责人
  • 发版前 1 天仍有 P0 未解决 → 产品负责人提出推迟或砍功能方案，升级研发部门负责人当天拍板（A（升级））
  • 有功能完全没有安排测试 → 不得进入本次发版，或由研发负责人书面确认研发自测并承担风险

7. 衡量指标

  • 冲刺提前量：宣布冲刺到发版日的工作日数，目标 ≥ 5 天
  • 用例认领覆盖率：有认领人且有结果的用例 / 计划用例，目标 100%
  • 重复测试率：重复提交的同类缺陷数 / 新增缺陷数，目标 ≤ 5%
  • 测试报告准时率：发版前 1 个工作日出报告的版本数 / 发版总数，目标 100%
  • 未测上线功能数：每个版本未安排测试即上线的功能数，目标 0

8. 低效诊断

  • 现象：多人重复测同一功能，需要在群里喊“认领”；测试报告要反复追问；一半旧缺陷没修也没说明｜依据：「Leap产研测」2026-06
  • 现象：上线前的验证清单靠群消息手工列，进度靠站会前催｜依据：「Leap产研测」2026-08
  • 现象：版本工单里还卡着一堆产品走查没完成，部分功能没补工单｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：发版前一周才调人，被派去做自动化的人能力不匹配｜依据：「Leap产研决策部」2026-08
  • 现象：测试人员同时挂在多个项目上，没有一个人全职投入当前迭代；新功能完全没有安排测试｜依据：「Leap产研决策部」2026-10
  • 现象：借调来的人反复问“测什么、怎么测”；上线前一晚才通知加班测；测试服长期被当开发服用、版本不新；同类问题多人重复提｜依据：「开源聚变入驻问题沟通群」2026-02、「开源聚变入驻问题沟通群」2026-03

9. 分支变体

  • LeapCore 上线前逐项验证：按模型档位、搜索（国内/国际）、计费分项挂工单并点名负责人，回复“测试完成”加工单链接
  • LeapAll 个人版：复用 LeapCore 的计划做整体测试
  • 对外社区/商城平台上线前从大群借调：商城重点测支付、订单、券；社区重点测审核和权限；义工测试的激励按行政规定执行
  • 跨团队测试支援：其他项目（如开放平台）需要测试时，向测试负责人申请排期，写进人力分配表，不靠私下协调
  • 信创认证、手机端、工程版、视频工作台等并行项目：迭代初就分配，暂停的项目由研发部门负责人决定收回测试人力

10. 待确认问题

  • 进入冲刺的触发阈值（如待测量超过剩余人日 1.5 倍、距发版 ≤5 个工作日）是否合适？
  • 抽调研发的批准人是研发负责人还是研发部门负责人？
  • 每日站会固定在 17:30 是否适用于所有产品线？
  • Go/No-Go 的最终拍板人是产品负责人还是研发部门负责人？
  • 测试人力分配表是否需要和 HR 的借调记录打通？
RND-42冒烟测试与核心用例回归待优化180

状态：待优化｜证据：有证据（卡片 11 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨3 × 险5

  • 适用场景：新包/新版本部署到测试环境、发版上线前后、模型/渠道切换前、交付项目打包刻盘前，需要按核心用例冒烟回归并给出放行结论时启动
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——鼎慧线测试（当前：李国庆·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、发版研发（当前：宋祺睿、葛家和·推断待确认）、产品负责人（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 发版研发通知提测（版本、更新日志、修复清单） → ② 测试环境冒烟 → ③ 缺陷登记与分级（立即修/后续 OTA） → ④ 修复与定向回归 → ⑤ 放行签字 → ⑥ 发布后生产冒烟 → ⑦ 内测放量与记录归档 → ⑧ 冒烟用例维护
  • 交付结果：带 PASS/FAIL 的冒烟记录（测试环境+正式环境）、放行结论（通过/有条件通过/不通过）、缺陷工单；内测版本附反馈收集入口
  • 状态依据：字字可研已有测试/正式环境冒烟模板，执行节奏稳定；但 Leap 客户端和跃玩线 5～8 月多次出现“包刚发就想发布”、反复追问“冒没冒”、带已知缺陷放行、先上线后补测，发版后正式服因配置错误整体故障，换渠道后功能出问题

1. 场景判定

  • 触发条件：测试环境或正式环境部署完成；安装包打出；模型/渠道/配置切换前；hotfix 发布；交付项目封板刻盘前；内测放量前
  • 典型说法：「先别给用户，你们先测下」「冒烟没」「发版完成，麻烦测一下」「测试环境冒烟测试通过」「上线前把新用户全流程走一遍」
  • 判断问题：这次变更会不会让核心流程（注册登录、对话、生成、支付、权限）不可用？会，或说不清 → 走本流程
  • 不归本流程管：单个工单验收 → 请走 RND-39；完整系统测试/冲刺 → 请走 RND-41；压测 → 请走 RND-43；安全与资金专项 → 请走 RND-44；发布操作本身 → 请走 RND-51；hotfix 准入 → 请走 RND-54；模型/上游接入验证 → 请走 RND-67

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 维护冒烟用例，给出放行结论 A/R 测试负责人（当前：张东郅·推断待确认）
测试执行人 执行测试环境和正式环境冒烟，登记缺陷 R 鼎慧线测试（当前：李国庆·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）
发版研发 部署、发提测通知（版本、日志、修复清单）、提供管理员协助 R 发版研发（当前：宋祺睿、葛家和·推断待确认）
产品负责人 依据测试结论确认发布、组织内测放量；有条件通过或需推迟发布时拍板 A（升级） 产品负责人（当前：杨萌·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）
修复研发 修复冒烟发现的缺陷，配合定向回归 R 各模块研发（当前：待指定）
后端负责人（跃竞） 发版后接口权限回归，兜底告警修复 R 跃竞后端负责人（当前：王子明·推断待确认）
研发部门负责人 交付项目封板决策、争议裁决 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 版本号、更新日志（上一版 → 本版）、本次修复的工单清单
  • 环境地址：测试环境、正式环境；客户端分 Win/Mac 安装包
  • 冒烟用例清单（基础功能 + 本次新增 P0/P1）
  • 测试账号：普通用户、管理员、无权限账号、余额不足账号；正式环境使用专用测试租户/账号
  • 核心用例优先级：致命缺陷回归用例 > 核心用例 > 客户用例 > 其他

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 部署成功后发提测通知：版本、更新日志、修复工单、环境、账号、本次不测范围 发版研发 部署成功后 30 分钟内 部署机器人+飞书群 提测通知 🔧+🤖
2 测试环境冒烟：按清单逐条执行，记录 PASS/FAIL；客户端 Win、Mac 分别跑；自动化脚本先跑，失败项人工复核 测试执行人 小版本 2 小时内；大版本当天 冒烟记录文档、Playwright 脚本 测试环境冒烟记录 🤖+👤
3 缺陷提工单并分级：P0 阻断发布；P1 由产品和测试决定立即修还是 OTA/下迭代 测试执行人、产品负责人 发现后 30 分钟内 issues 平台 缺陷单、分级结论 👤人工判断
4 修复后定向回归，并复跑受影响模块的冒烟用例 研发、测试执行人 修复后 2 小时内 测试环境 回归记录 🤖+👤
5 测试负责人给出放行结论，产品负责人确认发布；有条件通过须列出已知问题 测试负责人、产品负责人 发布前 冒烟记录、群内签字 放行结论 👤人工判断
6 发布后生产冒烟：只覆盖核心流程，使用专用测试账号，不批量造数据；新用户注册必测 测试执行人 发布后 1 小时内 正式环境 正式环境冒烟记录 🔧+👤
7 内测放量：公司内测 → 小范围公测 → 正式；附反馈表单，收集的问题按 RND-01 分流 产品负责人 生产冒烟通过后 反馈表单、反馈群 放量公告 🔧飞书固化
8 维护用例：新增重要功能稳定后纳入冒烟集，每月清理过期用例；核心路径接入定时自动巡检 测试负责人 每迭代回顾时 用例库、巡检脚本 更新后的冒烟清单 🤖自动化

5. 交付物与模板

  • 交付物：提测通知、测试环境冒烟记录、正式环境冒烟记录、放行结论、缺陷工单
  • 建议模板/表单：
    • 冒烟记录（沿用字字可研模板）：目标与范围、前置条件（账号角色、测试数据）、基础功能用例、本次新增 P0/P1、执行记录（场景编号/步骤/预期/结果/截图）、上线门禁结论
    • 提测通知：版本、更新日志、修复工单、环境、账号、不测范围、联系人
    • 放行结论：通过/有条件通过/不通过、已知问题清单、签字人、时间

6. 异常与升级

  • 冒烟出现 P0 → 立即停止发布，研发 2 小时内修复；修不了的由产品负责人决定推迟发布
  • 生产冒烟失败 → 发版研发评估是否回滚（RND-59），30 分钟内决定，并通知产品负责人
  • 测试执行人缺席、冒烟不彻底 → 测试负责人指定备岗，或由发版研发按清单代跑，结论注明“代跑”
  • 正式环境缺管理员账号无法验证 → 发版研发 1 小时内协助，长期问题按 X-SEC-09 登记账号
  • 发版后出现权限/接口异常告警 → 跃竞后端负责人 30 分钟内认领，查最近一次部署和提交人，补进回归清单
  • 测试负责人给出“有条件通过”，或 P1 需在立即修与 OTA 之间取舍 → 升级产品负责人拍板发布与否（A（升级），发布前）
  • 交付项目封板刻盘，或测试与产品对放行结论有争议 → 升级研发部门负责人裁决（A（升级），当天）

7. 衡量指标

  • 冒烟覆盖率：执行了冒烟的发布次数 / 发布总次数，目标 100%
  • 冒烟时效：提测通知到测试环境冒烟结论的时间，目标小版本 ≤ 2 小时
  • 发布后 24 小时内 P0 数：目标 0
  • 自动化误报率：自动化失败但人工复核正常的用例 / 自动化失败用例，目标 ≤ 10%
  • 生产脏数据：冒烟/压测后残留在生产库的测试用户数，目标 0

8. 低效诊断

  • 现象：安装包刚发出一小时就想对外发布，没有更新日志，测试与正式环境只有一套｜依据：「Leap产研测」2026-05
  • 现象：冒烟靠反复追问“冒没冒”，带已知缺陷放行，有工单被非验收人关闭，冒烟依赖单人｜依据：「Leap产研测」2026-06
  • 现象：上线后正式服因配置/密钥填错、旧包兼容问题整体故障｜依据：「Leap产研测」2026-06
  • 现象：换渠道前口头说“测过了”，上线后功能仍出问题；合并后没人叫测试｜依据：「鼎慧产研决策部」2026-06
  • 现象：冒烟范围随迭代变动，需要在群里确认；每次手工跑；自动化用例本身写错导致误报｜依据：「工程咨询产研」2026-04、「工程咨询产研」2026-06
  • 现象：生产冒烟和压测批量写入测试用户，难以清理｜依据：「工程咨询产研」2026-07、「工程咨询产研」2026-08
  • 现象：会员端功能先上线后补测，多次上线后复测｜依据：「跃玩项目组」2026-08
  • 现象：发版后权限校验缺失、改动牵连他人接口，靠告警发现，谁改的谁测的靠猜｜依据：「告警通知群」2026-05、「告警通知群」2026-08
  • 现象：夜间联测需要他人在管理端手动审核才能继续，正式服没有管理员账号｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：删功能不提工单导致漏测；内测版、开发版、正式版边界不清｜依据：「Leap反馈群」2026-07

9. 分支变体

  • Leap 客户端：Win/Mac 分别验收；LeapAll 个人版重点测充值、生图、视频、OTA，LeapCore 企业版重点测管理后台、网盘权限、席位
  • 字字可研：发版前测试环境全量冒烟，发版后正式环境冒烟；新增重要功能（如计费重构、开放注册）确认做完后才加入冒烟范围；本线已较成熟，重点是自动化巡检
  • 跃玩/跃竞：test 分支测试 → 线上分支复测 → 上线后需求复测；支付类真机回归；发版后接口权限回归（平台角色与俱乐部成员角色分开查）
  • 对外社区/商城平台：测试服做完整系统测试，正式服只做核心流程冒烟；大版本可约多人联测，每人领一个流程
  • 交付项目封板刻盘前：研发先自测 → 指定人员交叉测试 → 达到“无恶性缺陷”再打包，封板由研发部门负责人决定
  • hotfix：只做定向验证 + 核心冒烟（RND-54）

10. 待确认问题

  • 各产品线冒烟用例的维护人分别是谁？字字可研两份模板是否合并为一份？
  • 生产冒烟是否统一使用专用测试租户？测试数据由谁定期清理？
  • “有条件通过”放行的签字人是产品负责人还是研发负责人？
  • 正式环境核心路径定时巡检由谁建设，告警发到哪个群？
  • 跃竞发版后的接口权限回归清单由后端负责人还是测试负责人维护？
RND-43性能压测与容量评估待优化192

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：新服务/新版本/新上游或新模型上线前、扩大推广或发券前、大规模集中使用（百人培训、大量席位）前，需要验证并发与容量并给出结论时启动
  • 负责人：主责——测试负责人（压测执行，当前：张东郅·推断待确认）；协同——被测服务研发（当前：马漳毓、邓乾、杨云峰·推断待确认）、IT 运维/上游渠道维护（当前：杨明学·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、研发负责人（当前：王皓南·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 提交压测申请 → ② 确认容量目标 → ③ 准备环境与数据（mock 上游、隔离、备份） → ④ 发布压测窗口公告 → ⑤ 执行（探测→基准→容量→稳定性） → ⑥ 出报告与结论 → ⑦ 优化后复测 → ⑧ 恢复清理并发结束通知
  • 交付结果：按模板的压测报告（场景、并发档位、QPS/RPM、成功率、耗时分布、瓶颈、容量结论），原始数据（CSV/JSON）归档，压测窗口的起止公告
  • 状态依据：已有 k6/locust 脚本、Gitea 压测仓库、模型 API 测试验收 SOP 和 mock 上游；但 4～10 月多次出现 QPS 与长连接口径混淆、压测与发券撞车、打爆上游 RPM、压测机连生产还是测试要临时确认、结束后无人通知

1. 场景判定

  • 触发条件：新 API 网关/分站、新模型或新上游上线；产品计划推广、发券、活动；预期出现百人以上集中使用；高并发敏感功能（红包、支付、多商户轮询）提测；数据库 CPU 或内存异常需摸底
  • 典型说法：「定个 20～50 并发的压测方案」「除了 QPS 还得模拟真实使用场景长输出」「预期要承载多大的峰值」「正式服正在压测，期间服务可能异常」「mock 模型不上生产」
  • 判断问题：这次上线或活动的峰值并发有没有被验证过？上游声称的限额有没有实测过？没有 → 走本流程
  • 不归本流程管：新上游接入的功能验证 → 请走 RND-67；慢 SQL 治理 → 请走 RND-35；服务器扩容 → 请走 RND-79；功能冒烟 → 请走 RND-42；测试额度、测试账号申请 → 请走 RND-47

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 设计场景、执行压测、出报告和容量结论 A/R 测试负责人（当前：张东郅·推断待确认）
被测服务研发 提供接口、备份日志、配置并发参数、根据报告优化 R 被测服务研发（当前：马漳毓、邓乾、杨云峰·推断待确认）
产品/运营 给出预期峰值并发和活动时间 C 产品负责人（当前：杨萌·推断待确认）
IT 运维/渠道维护 确认环境、压测机网络与磁盘、上游限额与提额 R IT 运维（当前：杨明学·推断待确认）
跃竞测试 跃竞线高并发与全链路压测 R 跃竞测试负责人（当前：赵伟龙·推断待确认）
研发负责人 容量不达标时给出限流/排队/扩容方案 C 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准生产压测窗口、拍板目标 QPS 和压测预算 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 压测目标：预期峰值（并发用户/QPS/RPM/长连接数）、目标成功率与耗时，由产品/运营给出
  • 环境：测试环境优先；生产压测需注明理由；base_url、模型名、压测专用 key（不与生产 key 混用）
  • 上游：默认走 mock 上游（支持流式、随机长输出）；真实上游只做小规格抽样，并确认余额与 RPM 上限
  • 数据：专用测试租户/账号；压测后的清理或重置方案；日志备份
  • 窗口：避开营销活动、发券、演示；生产压测优先选凌晨
  • 预算：真实上游压测的预计消耗

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交压测申请（目标、环境、key、窗口、预算），@测试负责人 被测服务研发 上线/活动前 ≥5 个工作日 飞书多维表格/任务 压测申请 🔧飞书固化
2 确认容量目标和压测场景；统一口径：QPS、RPM、并发长连接分开写 测试负责人、产品/运营 申请后 1 个工作日内 申请单 场景与目标 👤人工判断
3 准备环境：确认压测机连哪个环境；mock 上游可用；检查磁盘、网络、上游余额与限额；备份日志 IT 运维、被测服务研发 压测前 1 个工作日 压测机、AiMock 环境就绪确认 🔧+🤖
4 发窗口公告：起止时间、影响范围、环境地址、联系人；压测期间冻结被测服务的发布 测试负责人 开始前 2 小时 飞书机器人公告 压测公告 🔧+🤖
5 执行：探测（Probe）→ 基准（如 8 并发 × 8 轮）→ 容量（逐档加压）→ 按需稳定性（Soak 24 小时）；流式接口长连接 ≥5 分钟 测试负责人 按窗口 k6/locust、测试 skill 原始数据 🤖自动化
6 出报告：并发档位、成功率、耗时分布、瓶颈定位、容量结论、建议；原始 CSV/JSON 归档 测试负责人 压测结束后 1 个工作日内 飞书 wiki、Gitea 压测报告 🤖+👤
7 研发按瓶颈优化（SQL、排队逻辑、换渠道），完成后复测同一场景 被测服务研发、测试负责人 优化后 2 个工作日内 同上 复测报告 👤人工判断
8 恢复：清理/重置压测数据，恢复配置；发结束通知 被测服务研发、测试负责人 窗口结束后 30 分钟内 重置脚本、飞书群 结束通知 🔧+🤖

5. 交付物与模板

  • 交付物：压测申请、窗口公告与结束通知、压测报告、原始数据归档、复测报告
  • 建议模板/表单：
    • 压测申请：被测服务、版本、环境、目标（并发/QPS/RPM/长连接）、上游类型（mock/真实）、key、窗口、预算、申请人
    • 压测报告：场景说明、工具与参数、档位结果表（并发/成功率/P50/P95/P99/错误类型）、瓶颈、容量结论（可承载 X 并发）、风险与建议、原始数据链接
    • 公告模板：开始/结束时间、影响范围、环境地址、联系人、回滚方式

6. 异常与升级

  • 必须在生产环境压测，或需使用真实上游产生费用 → 升级研发部门负责人批准窗口、目标与预算（A（升级），压测前 1 个工作日）；限 RPM（如 100 左右）并避开业务高峰
  • 压测中出现真实用户受影响、上游被打爆 → 立即停压，通知 IT 运维和产品，30 分钟内恢复
  • 压测中途被测服务被他人更新 → 作废本轮数据，重新排窗口；窗口期内发布须先和测试负责人确认
  • 上游实测能力明显低于宣称值 → 报 IT 运维对接厂商，转 RND-67/RND-68 重新评估
  • 容量结论达不到目标且上线日期已定 → 研发负责人 1 个工作日内给出限流/排队/扩容方案，报研发部门负责人

7. 衡量指标

  • 上线前压测覆盖率：触发条件内完成压测的上线次数 / 应压测次数，目标 100%
  • 报告时效：压测结束到报告发布的工作日，目标 ≤ 1 天
  • 压测冲突次数：压测与营销活动/真实业务冲突或打爆上游的次数，目标 0
  • 容量事故：上线后因容量不足导致的排队超时或故障次数，目标逐季下降
  • 压测数据残留：压测结束 1 个工作日后未清理的测试数据，目标 0

8. 低效诊断

  • 现象：并发与 QPS 口径混淆，只压 QPS 没压长输出；测试任务零散，压测人力不够｜依据：「Leap产研测」2026-05
  • 现象：没有压测方案文档，数据库 CPU 打满后才做 SQL 优化｜依据：「Leap产研测」2026-07
  • 现象：正式服压测期间使用者不知道该进哪个环境，测试与正式账号不互通，结束后要追问｜依据：「模态AI探索小分队」2026-05
  • 现象：压测与发券撞车；压测中途后台被更新、接口结构变了；上游宣称的 QPS 实为 QPM；峰值目标要追问｜依据：「LeapPPT」2026-05
  • 现象：压测 key 与上游 key 混淆，mock 上游失效要重写，压测打爆上游 RPM 后争论责任｜依据：「AI API」2026-04、「AI API」2026-07
  • 现象：压测脚本每次临时写，“并发”在幂等与压测两种含义间混用，慢 SQL 上线后才排查｜依据：「跃玩项目组」2026-04、「跃玩项目组」2026-07
  • 现象：压测机连生产还是测试要临时确认，压测时磁盘不足，压完后重置、导入数据靠群聊｜依据：「百人上课特供版leapcore」2026-10

9. 分支变体

  • 模型 API/NewAPI 分站：探测 → 基准 → 按需 24 小时稳定性 → 容量；对话、生图、视频异步任务、搜索类分别验收；默认 mock 上游
  • LeapPPT 等面向用户的产品：在正式服压测须提前公告，优先凌晨，压测后再跑夜间稳定性测试
  • 跃玩高并发功能（红包、支付、多商户轮询）：幂等测试与压测分开写；资金一致性同时按 RND-44 检查
  • 百人培训/大规模席位：mock 模型不上生产；先公司内压测，再会场现场压测；压完重置并导入学员信息
  • 内部压测与对外活动前压测：通知范围不同，对外活动前须通知市场/销售

10. 待确认问题

  • 压测申请是否统一走多维表格？提前 5 个工作日是否可行？
  • 生产压测的批准人是否固定为研发部门负责人？RPM 上限默认多少？
  • 真实上游压测的预算由谁审批，费用记哪个部门？
  • 跃竞线压测是否由跃竞测试负责人独立负责，还是归总测试负责人统筹？
  • 压测报告统一存放在哪个 wiki 目录？
RND-44上线前安全测试、资金逻辑专项测试与漏洞修复待新建240

状态：待新建｜证据：有证据（卡片 8 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：产品对外开放下载/发布、政府或对外平台上线、涉密客户交付、涉及余额/支付/退款/兑换券/验证码的功能提测前做安全与资金专项检查；或上线后发现可利用漏洞需要紧急修复时启动
  • 负责人：主责——测试负责人（专项测试与复测，当前：张东郅·推断待确认）；协同——项目研发负责人（当前：王皓南·推断待确认）、IT 运维/安全加固（当前：杨明学·推断待确认）、安全测试支持（当前：宋祺睿、邓乾·推断待确认）、跃竞测试负责人（当前：赵伟龙·推断待确认）、产品负责人（当前：杨萌、徐莉·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 识别触发并选清单 → ② 自动扫描（源码/依赖/安装包/AI 渗透） → ③ 人工专项测试（安全+资金） → ④ 漏洞登记与分级 → ⑤ 修复与复测 → ⑥ 门禁签字放行 → ⑦ 上线后漏洞热修与通告
  • 交付结果：逐项打勾的上线安全门禁清单、资金类测试覆盖表、漏洞工单（含分级、影响面、修复、复测结论）、放行签字；上线后漏洞附 hotfix 记录
  • 状态依据：清单只在聊天里出现过；漏洞多靠个人兴趣用 AI 扫出，或在冒烟、全员找问题时偶然发现；资金功能的覆盖面靠产品临场质询；2～9 月多次出现打包暴露私有仓库地址、越权与 SSRF、日志未脱敏、短信防刷缺失、公网接口泄露账号信息等问题，每次都是临时处理

1. 场景判定

  • 触发条件：允许外部下载安装前；对外/政府平台正式服上线前；涉密客户交付前；资金类功能（分账、退款、红包、存单、押金、钱包、兑换券、额度）提测；短信验证码等防刷功能上线；内部测试或外部反馈发现可利用漏洞
  • 典型说法：「允许外部下载安装前，需要至少做一轮安全审查」「上线前至少要有基本的日志记录，能追溯」「红包相关的流程，你目前的测试覆盖了哪些场景」「这种支付漏洞要多注意」「安全测试报告：严重漏洞」
  • 判断问题：这次上线是否面向外部用户或公网？是否涉及钱、账号或客户数据？任一为是 → 走本流程
  • 不归本流程管：申请外部渗透测试/安全扫描资源 → 请走 X-SEC-39；整改闭环与遗留资产清理 → 请走 X-SEC-40；服务器上线安全基线 → 请走 X-SEC-38；密钥泄露 → 请走 X-SEC-11；计费准确性对账 → 请走 RND-70；hotfix 准入与发布 → 请走 RND-54

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 选清单、组织专项测试、登记漏洞、复测、给出安全结论 A/R 测试负责人（当前：张东郅·推断待确认）
安全测试支持 AI 渗透、接口 fuzz、逆向检查 R 安全测试支持（当前：宋祺睿、邓乾·推断待确认）
项目研发负责人 组织整改，评估影响面，确定修复方案 R 研发负责人（当前：王皓南·推断待确认）
IT 运维/安全 加固方案、测试环境防护、网络暴露面 R IT 运维（当前：杨明学·推断待确认）
产品负责人 资金场景覆盖确认、用户可见文案与展示策略 C 产品负责人（当前：杨萌、徐莉·推断待确认）
跃竞测试 跃竞资金类测试矩阵与自动化回归 R 跃竞测试负责人（当前：赵伟龙·推断待确认）
研发部门负责人 漏洞定级争议裁决、是否对外通告、高危未清零时的上线裁定、放行会签 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 发布物：安装包/镜像/站点地址、源码仓库、接口清单（含新增/改动接口）
  • 测试环境：与正式环境隔离，不可被搜索引擎收录，不对公网开放管理入口
  • 账号：普通用户、管理员、跨租户账号（越权测试用）、余额不足账号
  • 资金类：资金流转图、支付渠道矩阵、优惠券/退款规则、对账口径
  • 安全门禁清单与资金测试清单的最新版本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别触发，选清单：通用安全门禁必选；资金功能加资金清单；客户端发布加安装包清单；涉密交付加输入校验清单 测试负责人 提测时 清单库 本次检查范围 👤人工判断
2 自动扫描：源码与依赖扫描、安装包敏感信息扫描（私有仓库地址、本机路径、密钥）、AI 渗透/接口 fuzz 安全测试支持 上线前 ≥3 个工作日 CI 扫描、AI 工具 扫描报告 🤖自动化
3 人工安全专项：鉴权与越权、SSRF、XSS/注入、文件大小与编码、日志可追溯且脱敏、限流与验证码防刷（手机号+IP）、令牌不含敏感信息、预签名链接时效、生产包无调试入口、测试环境不外露、内容审核与封号兜底 测试负责人 上线前 ≥2 个工作日 测试环境 安全测试记录 👤人工判断
4 资金专项：金额边界（负数、溢出、精度、最小单位）、导入非法值、幂等键不可外部传入、重复领取、并发超卖、部分退/整单退/优惠券组合、渠道矩阵、抓包改参数、自动退回、延迟入账、对账 测试负责人/跃竞测试负责人 上线前 ≥2 个工作日 测试矩阵、自动化脚本 资金测试覆盖表 🤖+👤
5 漏洞登记与分级：严重/高/中/低，写明影响面和攻击链；漏洞细节只在工单中，不在大群扩散 测试负责人 发现后 1 小时内 issues 平台（漏洞模板） 漏洞工单 🔧+👤
6 修复并复测：研发评估影响面（接口能否直接下线），按分级时限修复；测试复测并在工单写“验收通过” 项目研发、测试负责人 按分级时限 Gitea、测试环境 修复 PR、复测结论 👤人工判断
7 门禁放行：清单逐项打勾，严重和高危清零，中危以下有排期；测试负责人和研发部门负责人签字 测试负责人、研发部门负责人 上线前 1 个工作日 多维表格/飞书审批 放行签字 🔧飞书固化
8 上线后发现漏洞：按严重级别走 hotfix（RND-54），推测试环境复测后同步各端发版；评估是否需要对外通告 项目研发、测试负责人、研发部门负责人 严重级别 24 小时内 issues、发布流水线 hotfix 记录、通告结论 👤人工判断

5. 交付物与模板

  • 交付物：安全门禁清单（打勾版）、资金测试覆盖表、扫描报告、漏洞工单、放行签字、hotfix 记录
  • 建议模板/表单：
    • 漏洞工单：标题、级别、发现方式、影响面（接口/数据/用户范围）、攻击链（只写在工单内）、临时缓解、修复方案、修复人、复测结论、是否对外通告
    • 分级时限：严重（公网可利用、越权获取客户数据、资金损失）24 小时内修复或下线缓解；高 3 个工作日；中 当迭代；低 排期
    • 资金测试矩阵：支付方式 × 优惠券 × 内扣/外扣 × 正常结单/全额退/部分退/先部分再整单，每格标 PASS/FAIL

6. 异常与升级

  • 发现严重漏洞 → 测试负责人 1 小时内报项目研发负责人和研发部门负责人；涉及客户数据时同时报 IT 运维
  • 修复会影响客户端必需接口、不能直接下线 → 研发先改返回字段或加鉴权缓解，产品同步调整文案
  • 上线日期已定但高危未清零 → 升级研发部门负责人决定推迟上线或下线该功能（A（升级），当天），不得带高危上线
  • 漏洞定级有争议，或需判断是否对外通告 → 测试负责人整理影响面 → 升级研发部门负责人拍板（A（升级），严重级 24 小时内）
  • 资金类测试覆盖有争议（如“并发”指幂等还是压测） → 测试负责人拆成两项分别测，压测转 RND-43
  • 加固方案无人负责 → 研发部门负责人当天指定

7. 衡量指标

  • 门禁执行率：触发条件内执行了门禁清单的上线次数 / 应执行次数，目标 100%
  • 上线后安全漏洞：上线后 30 天内发现的严重/高危漏洞数，目标 0
  • 漏洞修复时效：按分级时限内修复的比例，目标 ≥ 95%
  • 资金缺陷逃逸：上线后发现的资金类缺陷数，目标 0
  • 资金测试矩阵覆盖率：已执行格数 / 应执行格数，目标 100%

8. 低效诊断

  • 现象：桌面端打包后才发现暴露私有仓库地址和本机路径，日志未对 key 脱敏；发布检查清单只在聊天里，执行人迟迟未定｜依据：「Leap产研测」2026-05
  • 现象：漏洞靠个人兴趣用 AI 扫出，报告发到群里但没有整改单和复测；测试服地址被搜索引擎收录｜依据：「鸽子群模态分群」2026-02
  • 现象：对外平台正式服前夜全员找问题，同类问题多人重复报；正式服被当测试服上传数据｜依据：「模态集团（全员群）」2026-02
  • 现象：上线赶，日志、审计、封号兜底都没做，出问题无法定责；新功能的管理接口未校验身份｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：资金功能覆盖面靠产品临场质询，“并发”口径混用；退款类缺陷反复出现约 15 次；自动化框架迟迟未交付｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-06
  • 现象：短信防刷在冒烟时才发现缺失；钱包从单边记账返工为复式记账｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：公网漏洞当晚验证后紧急修复，加固方案的负责人事后才指定｜依据：「LeapVPN网络预研」2026-09

9. 分支变体

  • C 端桌面包：重点查安装包敏感信息、调试入口、自定义 API 入口、日志脱敏、代码混淆
  • B 端/企业服务：重点查越权与跨租户隔离，要求更严
  • 对外/政府平台：加查内容审核、敏感词、封号兜底、日志审计、静态资源压缩、测试环境隔离
  • 资金类（跃玩订单/红包/存单/押金/联盟提现；Leap 钱包/兑换券/额度/Skill 分润）：用资金测试矩阵，自动化回归纳入发版前必跑
  • 涉密客户交付：加查 XSS、大文件限制、编码识别，修复在打包刻盘前完成
  • 上线后发现漏洞：直接从第 5 步开始，走 hotfix

10. 待确认问题

  • 安全门禁的主责是测试负责人还是 IT/安全岗？公司是否计划设专职安全岗？
  • 漏洞分级时限（严重 24 小时、高 3 个工作日）是否可行？
  • 放行签字是否需要研发部门负责人亲签，还是项目研发负责人即可？
  • 资金测试矩阵和红包测试清单是否沉淀为 wiki 模板？由谁维护？
  • 对外通告漏洞的标准和审批人是谁（是否需要法务参与）？
RND-45AI 辅助与自动化测试验收待新建36

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨2 × 险3

  • 适用场景：工单转入产品验收或测试验收时，用 AI 机器人生成“实现锚定需求”和测试用例，或用 e2e/浏览器自动化脚本对功能和历史缺陷做回归验收时启动
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、自动化脚本维护研发（当前：魏宗浩·推断待确认）、产品负责人（当前：杨萌·推断待确认）、测试工程师（当前：黄霆瑄·推断待确认）；兜底——研发部门负责人（创始人兼 CTO，当前：丁震宇·推断待确认）
  • 核心流程：① 转产品验收时触发 AI 扫代码生成实现说明 → ② 产品确认验收口径、研发/测试确认测试锚点 → ③ 冻结锚点 → ④ 转测试验收时 AI 生成用例并执行 → ⑤ 报告回写工单 → ⑥ 人工抽检并签字 → ⑦ 统计可信度、调整门禁
  • 交付结果：工单评论中的“实现锚定需求”（已冻结）、AI 执行报告（用例、步骤、截图、结论），以及人工抽检签字；AI 结论只作参考，验收通过须由人确认
  • 状态依据：8～9 月已试跑 issue 机器人、夜间自动验收、e2e-full 全量回归和测试 skill 仓库，但多人各自搭脚本，AI “把按钮点一遍就算验收完”，生成的文档越写越长、没人细看，流程依赖单人，缺统一门禁和可信度标准

1. 场景判定

  • 触发条件：工单状态改为“产品验收”或“测试验收”；夜间回归窗口；发版前历史缺陷批量回归
  • 典型说法：「issue 改产品验收之后触发这个，改测试验收之后触发测试」「今晚试试自动化能不能跑一晚上验收」「AI 说它把历史 bug 全验了」「AI 测完了，那我测什么」
  • 判断问题：这个验收能否由脚本或 AI 复现并给出可核对的证据？能 → 先走本流程再人工签字；需要体验或需求语义判断 → 仍以 RND-39 人工验收为主
  • 不归本流程管：人工验收流转 → 请走 RND-39；AI 代码评审 → 请走 RND-33；AI 编码规范 → 请走 RND-28；冒烟自动化巡检 → 请走 RND-42

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试负责人 设计流程与 skill，维护门禁与可信度标准，抽检签字 A/R 测试负责人（当前：张东郅·推断待确认）
自动化脚本维护研发 维护 e2e/夜间自动验收脚本与环境 R 研发（当前：魏宗浩·推断待确认）
产品经理 确认实现说明中的产品验收口径 R 产品负责人（当前：杨萌·推断待确认）
工单研发 确认实现与测试锚点，修复 AI 发现的问题 R 各研发（当前：待指定）
测试工程师 审核 AI 用例，抽检 AI 结论，补测体验类场景 R 测试（当前：黄霆瑄·推断待确认）
研发负责人 批准 AI 验收覆盖范围，统一脚本仓库 C 研发负责人（当前：王皓南·推断待确认）
研发部门负责人 批准门禁策略和 AI 成本 I 创始人兼 CTO（当前：丁震宇·推断待确认）
issues 机器人/自动化脚本 生成实现说明、执行 AI 用例、回写验收报告 R（工具） 由自动化脚本维护研发维护（当前：魏宗浩·推断待确认）

3. 办之前请准备

  • 工单需求描述、验收条件、关联 PR 与 commit
  • 可访问的测试环境、测试账号、版本号
  • 统一 skill/脚本仓库（如 testtool-skills、agent-task-flow-skill、e2e-full），不各自另起
  • 高成本场景（视频、生图）的 mock 配置
  • 本次 AI 验收的范围说明：哪些由 AI 执行，哪些必须人工

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 工单转“产品验收”时，机器人扫代码生成“实现锚定需求”评论，分“产品验收口径”和“测试锚点”两部分，长度控制在一屏内 机器人 状态变更后 30 分钟内 issues 机器人、skill 实现说明评论 🤖自动化
2 产品只确认产品口径，研发/测试确认测试锚点；有问题评论，没问题点通过；不另写“翻译版”文档 产品经理、工单研发、测试工程师 1 个工作日内 issues 平台 确认记录 👤人工判断
3 确认后冻结锚点，后续改动须重新确认 测试负责人 确认当天 issues 平台 冻结标记 🔧+👤
4 转“测试验收”时，AI 依据锚点生成用例并在测试环境执行（浏览器/模拟器/e2e）；高成本场景用 mock 机器人/自动化脚本 状态变更后当天或当晚 e2e-full、AutomationTest 执行结果 🤖自动化
5 执行报告回写工单：用例清单、步骤、截图/录屏、通过/失败、环境与版本 机器人 执行完成后自动 issues 平台 AI 验收报告 🤖自动化
6 人工审核与抽检：核对用例是否覆盖锚点、抽检通过项、补测体验类和异常场景；由人改状态签字 测试工程师 报告产出后 1 个工作日内 issues 平台 人工验收结论 👤人工判断
7 每迭代统计 AI 结论与人工结论的一致率、误判案例，调整 AI 可覆盖范围与门禁 测试负责人 迭代回顾 统计表 可信度报告 🤖+👤

5. 交付物与模板

  • 交付物：实现锚定需求评论、AI 验收报告、人工抽检结论、迭代可信度报告
  • 建议模板/表单：
    • 实现锚定评论：产品验收口径（用户可见行为，≤10 条）、测试锚点（接口/状态/边界，≤10 条）、确认人、冻结时间
    • AI 验收报告：环境、版本/commit、用例编号与对应锚点、步骤、证据、结论、未覆盖项
    • 验收可信度排序：提单人验收 ≥ 测试验收 ＞ 开发自验 ＞ AI 自动验收；AI 结论不能单独关闭工单

6. 异常与升级

  • AI 结论与人工抽检不一致 → 以人工为准，在工单标注误判并计入统计；同类误判连续出现 3 次 → 该类场景暂停 AI 验收
  • AI 批量改/建工单造成污染 → 立即停用相关权限，按 RND-11 回滚，报研发负责人
  • 生成内容过长、无人阅读 → 测试负责人当迭代精简模板
  • AI 验收成本超预算 → 报研发部门负责人，决定缩小范围或改用 mock
  • 流程只有一人懂 → 测试负责人 2 周内完成交接文档并指定备岗

7. 衡量指标

  • AI 验收覆盖率：经过 AI 预验收的工单 / 进入测试验收的工单，目标逐迭代提升
  • 一致率：AI 结论与人工结论一致的工单比例，目标 ≥ 90%
  • 误判通过数：AI 判通过但人工判不通过的工单数，目标逐迭代下降
  • 人工验收耗时：每张工单人工验收平均时长，目标较引入前下降 30%
  • 脚本重复建设：并行维护的同类自动化脚本数，目标 1 套

8. 低效诊断

  • 现象：多人各自搭自动化和夜间验收脚本，重复建设，没有统一验收标准｜依据：「Leap产研测」2026-09
  • 现象：AI 把所有按钮点一遍就判定验收通过，出现误判｜依据：「Leap产研测」2026-09
  • 现象：AI 和测试分工不清，测试不知道 AI 测完后自己测什么；有人提醒“别太自动化，做好门禁”｜依据：「Leap产研测」2026-09
  • 现象：实现锚定文档和产品文档重复输出，越写越长，产品改写成产品语言时语义漂移；流程只有一人掌握｜依据：「Leap产研决策部」2026-08

9. 分支变体

  • 夜间自动验收：脚本批量跑待验收工单，次日上午由测试抽检
  • e2e-full 全量回归：发版前对历史缺陷做全量回归，结果进 RND-42 放行结论
  • 工单级 AI 实现锚定：只用于需求类工单；缺陷类直接用复现步骤生成用例
  • 批量环境验收（多虚拟机并行）：尚在构想，未纳入本流程

10. 待确认问题

  • AI 验收的门禁边界：哪些类型的工单允许 AI 预验收，哪些必须纯人工？
  • 自动化脚本统一到哪个仓库？由谁维护？
  • AI 验收的成本预算和 mock 策略由谁审批？
  • 实现锚定评论是否只保留一个 skill 同时产出产品口径和测试锚点？
  • AI 机器人修改工单的权限范围如何限定？
RND-46UI 设计交付与视觉/交互走查待优化108

状态：待优化｜证据：有证据（卡片 5 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：新界面或改版需要设计稿，或界面功能开发完成后，需要设计师、产品、测试对照设计稿和既有版本检查样式与交互一致性时启动
  • 负责人：主责——UI/UX 设计师（当前：康紫馨·推断待确认）；协同——产品总监/产品经理（当前：杨萌、陈震·推断待确认）、前端研发（当前：葛家和、岳阳、魏宗浩、吴世豪·推断待确认）、测试（当前：黄霆瑄、涂维轩·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 登记设计需求 → ② 出 Figma 稿与交付清单 → ③ 研发按稿还原 → ④ 提交走查（截图+版本+对照稿）→ ⑤ 设计走查出问题单 → ⑥ 争议一次性拍板 → ⑦ 修复并做 PR 一致性审查 → ⑧ 视觉验收收口并沉淀规范
  • 交付结果：挂在工单上的设计稿与交付清单、已关闭的 UI 走查问题单、附改前/改后截图的 PR、视觉验收结论、更新后的设计规范/组件库
  • 状态依据：已有 Figma 设计系统文件和设计师走查文档，但 2026-05～08 群聊中样式反复改、多人给出不同意见、"为什么不用设计师的稿"、同一功能出现三套菜单等情况约 90 次，验收标准与最终拍板人均未成文

1. 场景判定

  • 触发条件：需求评审后需要新界面/改版；界面类功能自测完成准备提测；测试或产品发现样式/交互与设计稿、或与 LeapLite/LeapNew 等其他版本不一致；渠道或客户要求定制主题
  • 典型说法：「这个界面是不是可以再优化一下」「UI 不是画了设计图吗，为什么不用设计师的」「以 LeapNew 为准？」「该加一致性评审了」
  • 判断问题：问题是"长得不对/交互不一致"，而不是功能报错吗？有没有可对照的设计稿或设计规范？
  • 不归本流程管：功能缺陷（报错、数据错误）→ 请走 RND-03；UI/UX 设计需求的提出与优先级 → 请走 X-PRD-16；一般代码评审合并 → 请走 RND-32；产品功能验收 → 请走 X-PRD-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
设计负责 出稿、维护设计规范、执行视觉走查并给出验收结论 R UI/UX 设计师（当前：康紫馨·推断待确认）
视觉争议拍板 设计与研发、多方意见冲突时一次性定稿 A 产品总监（当前：杨萌·推断待确认）
设计对接 设计稿与工单关联、派给研发、渠道主题对接 R 产品经理（当前：陈震·推断待确认）
还原实现 按稿还原、提交走查截图、修复走查问题 R 前端研发（当前：葛家和、岳阳、魏宗浩、吴世豪、马漳毓·推断待确认）
UI 一致性审查 PR 合并前检查组件/菜单是否复用规范 R 客户端主程（当前：岳阳·推断待确认）
交互一致性检查 迭代测试中对照设计稿与跨版本行为提问题 R 测试（当前：黄霆瑄、涂维轩、潘浩伟、李国庆·推断待确认）
兜底 走查超时、拍板后仍有争议时裁决 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 对应工单号与需求说明，注明产品线（LeapCore 企业版 / LeapAll 个人版 / LeapNew / 管理后台）
  • Figma 设计稿链接、切图/图标/Logo 素材包、字体说明、各状态稿（空状态、加载、错误、选中、悬停）
  • 走查用截图或录屏，标注环境（50/51/102）与版本号、对照稿位置
  • 涉及跨版本对齐时，附 LeapLite/LeapNew 行为差异清单和迭代会结论

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 需求评审通过后登记设计需求，标注"先出稿再开发"或"按现有组件开发" 产品经理 评审后 1 个工作日内 工单系统 带设计标签的工单 🔧飞书固化
2 出设计稿并填写设计交付清单（稿、切图、文案、各状态、适用产品线） UI/UX 设计师 该工单开发开始前 1 个工作日 Figma、多维表格 交付清单 + Figma 链接挂工单 🔧飞书固化
3 按稿还原；缺页面/缺素材在工单内提出，不自行发挥 前端研发 发现缺失当天 Figma、工单 还原实现 / 缺稿问题 👤人工判断
4 提交视觉走查：截图/录屏 + 环境版本 + 对照稿位置，@设计师 前端研发 自测完成当天 工单评论、Figma 评论 走查请求 🔧+🤖
5 视觉与交互走查，逐条输出问题（圆角、色值、间距、组件、交互状态） UI/UX 设计师 收到请求后 1 个工作日内 Figma 评论、走查文档 UI 走查问题单 🤖+👤
6 多方意见冲突时汇总选项，一次性拍板并写入工单，不在群内投票 产品总监 冲突出现后 1 个工作日内 工单评论 拍板记录 👤人工判断
7 修复问题，PR 附改前/改后截图；合并前做 UI 一致性审查 前端研发、客户端主程 修复 1 个工作日内；审查 1 个工作日内 Gitea PR 模板 合入的 PR 🤖+👤
8 复核并给出"通过 / 遗留转低优先级工单"结论，关闭走查单 UI/UX 设计师 修复后 1 个工作日内 工单系统 视觉验收结论 👤人工判断
9 迭代测试中发现交互差异，先查迭代会纪要，纪要未覆盖的再提问题单 测试 迭代测试期内 迭代会纪要、工单 交互差异问题单 🔧飞书固化
10 本迭代新定稿的规则沉淀到设计规范/组件库 UI/UX 设计师 迭代结束后 3 个工作日内 Figma 设计系统 规范更新记录 👤人工判断

5. 交付物与模板

  • 交付物：设计稿与交付清单、UI 走查问题单、带前后对比截图的 PR、视觉验收结论、设计规范更新记录
  • 建议模板/表单：
    • 设计交付清单（多维表格）：工单号｜产品线｜页面/模块｜Figma 链接｜切图/素材包｜各状态稿是否齐全｜字体/文案说明｜交付日期｜设计师
    • UI 走查问题单：工单号｜环境/版本｜截图｜对照稿位置｜问题类型（视觉/交互/一致性）｜期望效果｜优先级｜状态
    • PR 模板 UI 必填项：改前/改后截图｜是否复用规范组件｜设计稿链接

6. 异常与升级

  • 开发开始时仍无设计稿 → 产品经理当天决定"等稿"或"按现有组件先做、标注待走查" → 当天未定升级产品总监
  • 设计与研发或多人意见冲突 → 汇总到工单由产品总监拍板（1 个工作日）→ 拍板后仍有争议升级 Leap 研发负责人
  • 走查请求 1 个工作日无响应 → 研发在工单中催一次 → 再超 1 个工作日升级产品总监
  • 大会/发布冻结期 → 除阻断性 UI 问题外一律挂起转下迭代，由产品总监确认
  • UI 类 PR 超 2 个工作日无人审查合并 → 升级 Leap 研发负责人指定审查人
  • 升级拍板条件：产品总监拍板后仍有争议，或走查/审查连续超时 2 个工作日 → Leap 研发负责人（A（升级））1 个工作日内裁决，结论写入工单

7. 衡量指标

  • 走查一次通过率 = 首次走查无问题的功能数 / 提交走查功能数，目标 ≥ 60%
  • 走查响应时长 = 提交走查到给出意见的工作时长，目标 ≤ 1 个工作日
  • UI 返工轮次 = 同一页面走查修改轮数，目标 ≤ 2 轮
  • 有稿开发率 = 开发开始前已有设计稿的界面类工单占比，目标 ≥ 90%

8. 低效诊断

  • 现象：研发未按设计稿还原、设计稿缺页面或素材到手晚，导致返工（交付环节缺清单）｜依据：「Leap产研测」2026-07
  • 现象：美观标准靠群内多人表态，同一细节（菜单、动效、勾选框位置）反复改，无唯一拍板人（决策环节）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-07
  • 现象：走查截图与结论散落群聊，未挂工单，事后找不到（记录环节）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • 现象：迭代会已讨论的交互结论无纪要，测试重复提问"以哪个为准"（信息同步环节）｜依据：「Leap产研测」2026-08
  • 现象：同一功能出现多套菜单、PR 无明确合并人，事后追查代码作者（PR 审查环节）｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • LeapCore 与 LeapAll 品牌区分：Logo/图标替换只改对应产品线，PR 中注明影响范围
  • 渠道/客户定制主题：产品经理单独登记，设计稿按主题出，走查对照主题稿
  • 管理后台：无设计稿时可由产品经理出低保真，仍需设计师走查一次
  • 大会/发布冻结期：只修阻断性 UI 问题

10. 待确认问题

  • 视觉争议最终拍板人是产品总监，还是 Leap 研发负责人？
  • 是否规定"界面类工单必须先出稿再开发"，例外情形有哪些？
  • 走查响应 1 个工作日、返工不超过 2 轮是否可行？
  • PR 的 UI 一致性审查由客户端主程负责，还是设轮值审查人？
  • 是否已有成文设计规范文件可作为走查基准？设计交付清单放多维表格还是 Figma 内？
RND-47测试账号、测试额度与测试数据管理待新建240

状态：待新建｜证据：有证据（卡片 13 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：测试、验收、内测或演示前需要测试环境账号/企业/管理员权限/模型余额/测试数据，或测试服上游额度耗尽、测试数据需要造数或清理时启动
  • 负责人：主责——测试负责人（当前：张东郅·推断待确认）；协同——后端/运维（当前：宋祺睿、魏宗浩·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交测试资源申请 → ② 审核并优先从账号池分配 → ③ 新建账号/企业并按标准额度配置 → ④ 凭据安全发放、台账登记 → ⑤ 余额预警补额 → ⑥ 真实充值先审批后付款 → ⑦ 造数与到期清理 → ⑧ 月度对账回收
  • 交付结果：可用的测试账号/企业/权限与额度、测试账号台账、余额预警与补额记录、测试服充值审批单与月度对账单、测试数据清理记录
  • 状态依据：无成文规则与申请入口；2026-01～09 多个群反复出现群内要号、账号密码明文流转、"109 没钱了 / 50 又没钱了"、先充值后问"找谁审批"、测试数据混入他人账号或出现在正式服，约 85 次，每次临时处理

1. 场景判定

  • 触发条件：需要新测试账号、企业/orgid、管理员权限或邀请码；测试环境余额不足导致"什么模型都用不了"；测试服上游模型账户余额耗尽需真实充值；需要造数、改数据状态或清理测试数据；需要在正式服做验证
  • 典型说法：「开个管理员账号」「109 充点钱」「再给 50 充点钱，50 又没钱了」「谁往我号里塞测试数据了」「最好别在他们正式版测」
  • 判断问题：资源是否只用于内部测试/验收/内测（不交付给客户）？要动的是测试环境里的虚拟余额，还是要花真实的钱？
  • 不归本流程管：客户正式账号与额度开通 → 请走 X-DLV-15；演示/客户赠送额度审批 → 请走 FIN-16；模型 API Key 与第三方 Key 申请 → 请走 RND-27；上游账户充值付款流程本身 → 请走 FIN-03；环境地址与管理员账号登记交接 → 请走 X-SEC-09；研发个人开发账号 → 请走 RND-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试资源总负责 维护测试账号池与台账、审核申请、定标准额度与测试数据规则 A 测试负责人（当前：张东郅·推断待确认）
开号与余额调整 建账号/企业、调整余额、管理员权限变更并登记 R 后端/运维（当前：宋祺睿、魏宗浩·推断待确认）
网关额度与上游充值 测试服模型额度配置、上游余额监控、发起充值申请 R 模型网关研发（当前：柯逸飞·推断待确认）
开放平台组织 注册 orgid、建测试企业 R 开放平台负责人（当前：郭逸非·推断待确认）
申请人 提申请、按规则使用、到期清理自己的数据 R 测试/研发/产品（当前：李国庆、涂维轩、黄霆瑄、杨萌·推断待确认）
真实充值审批与兜底 测试服上游真实充值审批、超额授权；规则争议、资金异常裁决 A（升级） 研发部门负责人/CTO（当前：丁震宇·推断待确认）
付款与对账 付款执行、月度对账 R 财务负责人（当前：黄梦婷·推断待确认）
正式服验证审批（跃竞线） 正式服验证范围、测试下单退款审批 A（升级） 跃竞负责人（当前：徐莉·推断待确认）

3. 办之前请准备

  • 环境（50/51/102/108/109、字字可研 test、跃玩测试服等）、产品线、用途（验收哪个工单/内测/演示）、使用期限
  • 需要的角色（普通用户/企业管理员/owner）、企业或 orgid 名称
  • 需要的额度和预计消耗（工程模型、视频生成等高消耗场景需单独说明）
  • 造数需求：数据类型、数量、是否需改状态/时间、用完是否清理
  • 真实充值：上游账户、金额、用途、对应环境，是否个人垫付

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交测试资源申请（账号/企业/权限/额度/造数） 申请人 需要前 1 个工作日 飞书表单 → 多维表格 申请记录 🔧飞书固化
2 审核：优先从固定测试账号池分配；新建、管理员权限、超标准额度需写明理由 测试负责人 0.5 个工作日内 多维表格 分配结论 👤人工判断
3 新建账号/企业/orgid，按标准额度配置余额，权限最小化 后端/运维、开放平台负责人 审核通过后 0.5 个工作日内 LeapAuth/v5 管理台/开放平台后台/字字可研管理后台 可用账号 🤖+👤
4 凭据通过密码管理工具或一次性链接发放，台账登记（账号、环境、持有人、额度、到期日） 后端/运维 开通当天 密码管理工具、台账 凭据 + 台账记录 🔧飞书固化
5 余额低于阈值时机器人推群并@网关研发；测试环境虚拟余额按标准补足并登记 模型网关研发 预警后 2 小时内（工作时间） 余额预警机器人 补额记录 🤖自动化
6 测试服上游真实充值：先提审批再充值，禁止先充后补；个人垫付须事先报备 模型网关研发 → 研发部门负责人/CTO 审批 1 个工作日内；紧急小额授权内可先充，1 个工作日内补登记 飞书付款审批（按 FIN-03） 审批单、到账确认 🔧飞书固化
7 造数优先用种子数据脚本或固定测试企业；需改库的由后端执行并记录 申请人、后端/运维 申请后 1 个工作日内 造数脚本、工单 测试数据 🤖自动化
8 测试结束或到期后清理自己的数据；共享环境清数据前提前公告 申请人、后端/运维 测试结束 1 个工作日内；清理前至少提前 1 个工作日公告 清理脚本、群公告 清理记录 🔧+🤖
9 正式服验证只做冒烟，不造数、不真实下单；必须下单的事先报备，当天退款/删除 申请人 验证当天 正式服、退款审批 验证记录 👤人工判断
10 月度对账：测试服充值、消耗与台账核对，回收过期账号与权限 测试负责人、财务负责人 每月 5 日前 台账、上游账单 对账单、回收清单 🔧+🤖

5. 交付物与模板

  • 交付物：测试账号台账、测试服充值审批与对账单、余额预警记录、测试数据清理记录
  • 建议模板/表单：
    • 测试资源申请表：申请人｜环境｜产品线｜用途/工单号｜账号类型/角色｜企业/orgid｜额度｜期限｜是否需造数｜审核人
    • 测试账号台账：账号标识（不含密码）｜环境｜持有人｜角色｜当前额度｜开通日｜到期日｜状态
    • 测试服充值登记：上游账户｜金额｜审批单号｜支付方式（对公/垫付）｜到账时间｜对应环境
    • 测试数据清理记录：环境｜数据范围｜清理人｜时间｜是否已提前公告

6. 异常与升级

  • 测试环境余额耗尽阻塞验收 → 网关研发 2 小时内按标准额度补足 → 超时升级测试负责人
  • 上游账户需真实充值且超出小额授权 → 当天提审批 → 研发部门负责人/CTO（A（升级））当天审批，财务负责人确认付款方式
  • 测试资源规则争议或出现资金异常（先充后批、对账不平）→ 测试负责人当天整理事实 → 升级研发部门负责人/CTO（A（升级））1 个工作日内裁决
  • 跃竞线需在正式服验证且必须真实下单/退款 → 申请人事先报备 → 跃竞负责人（A（升级））当天审批验证范围与退款安排
  • 管理员权限被误清或需要临时管理员权限 → 后端/运维恢复并登记 → 权限变更须通知持有人；争议升级研发部门负责人/CTO
  • 凭据在群内明文出现 → 当天改密并撤回 → 按 X-SEC-11 处置
  • 测试数据出现在正式服或汇报前需冻结数据 → 立即删除并通知产品负责人 → 涉及客户可见内容当天升级研发部门负责人/CTO
  • 测试数据污染导致误报缺陷 → 测试负责人核实账号状态后关闭误报，并补登记数据来源

7. 衡量指标

  • 开号时长 = 申请提交到账号可用，目标 ≤ 0.5 个工作日
  • 余额阻塞次数 = 每月因测试余额不足导致测试中断次数，目标 ≤ 1 次
  • 先充后批次数 = 未经审批的测试服真实充值次数，目标 0
  • 群内明文凭据次数 = 每月群内出现账号密码/服务器凭据次数，目标 0
  • 测试数据污染事件 = 正式服出现测试数据或误报缺陷次数，目标 0

8. 低效诊断

  • 现象：测试账号、企业、余额每次在群里@人临时开，入口和已开账号无人掌握（申请入口缺失）｜依据：「Leap产研测」2026-08、「鼎慧产研决策部」2026-01
  • 现象：新号默认额度为 0、加多少靠问，余额频繁耗尽阻塞验收（额度标准缺失）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：测试服上游充值先充值后问审批，审批人不明确、无对账（资金环节无流程）｜依据：「Leap产研测」2026-08
  • 现象：账号密码、手机号在群内明文流转，账号找不到再问（凭据发放环节）｜依据：「Leap产研测」2026-08、「工程咨询产研」2026-04
  • 现象：mock 数据塞进他人测试账号、共享测试服数据被清无通知、测试数据出现在正式服（数据管理环节）｜依据：「工程咨询产研」2026-04、「跃玩项目组」2026-01、「开源聚变入驻问题沟通群」2026-03
  • 现象：内测账号开通后无法创建团队、缺陷靠聊天复现（内测开通环节）｜依据：「鸽子群模态分群」2026-07

9. 分支变体

  • Leap 50/51/102/108/109：余额在 v5 管理台/LeapAuth 调整；102 为公司内部生产，账单可能混入测试，需在月度对账中区分
  • 开放平台：测试企业/orgid 由开放平台负责人注册，测试企业单独列入台账
  • 字字可研（工程咨询）：test 与正式两套管理后台分别开通；邀请码绑定手机号；测试环境走特殊验证注册，不提供用户删除
  • 跃竞/跃玩：测试服用固定测试俱乐部造数；正式服只冒烟，必须下单的事先报备跃竞负责人并当天退款
  • OPC 社区平台：领导汇报前冻结测试数据；商城用真实小额支付测试的须事先说明款项去向
  • 客户机器余额查询不归本流程，按 X-DLV-15

10. 待确认问题

  • 测试账号池与台账的主责是测试负责人，还是后端/运维？
  • 各环境默认测试额度、余额预警阈值定为多少？
  • 测试服上游真实充值的小额授权上限是多少（[阈值待财务确认]）？审批人是研发部门负责人/CTO 还是财务负责人？是否允许个人垫付？
  • 是否开发"重置测试账号""种子数据一键重置/清除"功能，由谁排期？
  • 跃竞线正式服验证的报备与退款审批人是否为跃竞负责人？
RND-48开发/测试/生产环境分层与共享环境占用待新建320

状态：待新建｜证据：有证据（卡片 15 张 / 会话 10 个）｜优先级：频5 × 耗4 × 跨4 × 险4

  • 适用场景：新建或调整环境用途，多人共用同一测试/演示机器需要占用、改配置、切模型 tag、清理、重装、换机或挪网段，或产品从内测转公测需要拆分生产与测试环境时启动
  • 负责人：主责——环境与基础设施负责人（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（跃竞线，当前：徐莉·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 制定环境分层规范 → ② 登记环境台账 → ③ 占用/变更申请 → ④ 冲突协调与冻结窗口 → ⑤ 变更前公告 → ⑥ 备份后执行 → ⑦ 更新台账并通知 → ⑧ 季度盘点回收
  • 交付结果：成文的环境分层规范；实时更新的环境台账（环境/层级/地址/版本/负责人/数据级别/占用状态/冻结期）；占用与变更记录
  • 状态依据：环境用途在 2026-01、06、07、08 多次口头宣布但未成文；测试服被当正式服交给客户、生产服被临时改成演示形态、测试机被换走无人通知、共享 NewAPI 实例互相覆盖等反复发生，约 150 次

1. 场景判定

  • 触发条件：新环境上线或用途变化；需要独占/改配置/切 tag/清理 docker/重装/压测某台共享环境；IT 侧换机、挪网段、回收机器；发布会或演示前需冻结环境；产品首次上线需拆分生产/测试
  • 典型说法：「别在 50 部署没合并过的分支」「这个 tag 有人在使用吗，没人的话我切了」「你测生产服干什么」「这台机器 29 号前别动了」「要不还是开三个环境」
  • 判断问题：这次操作会不会影响别人正在用的环境或数据？会不会改变某个环境的用途或数据级别？
  • 不归本流程管：服务器/虚拟机资源申请 → 请走 X-SEC-17；测试环境部署与更新通知 → 请走 RND-49；生产变更（备份、灰度、配置审批）→ 请走 RND-58；客户演示前环境准备 → 请走 RND-61；测试账号与测试数据 → 请走 RND-47；环境故障排障复盘 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
环境规范与台账 维护分层规范与环境台账、审批用途变更、协调占用冲突 A 环境与基础设施负责人（当前：宋祺睿·推断待确认）
机器与网络供给 开机器、快照、重置、换机、挪网段并提前通知 R IT 运维（当前：杨明学·推断待确认）
分层规则 定分支与环境对应规则、环境用途争议裁决 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）
冻结窗口 发布会/演示期冻结、环境对外使用边界 A（升级） 产品总监（当前：杨萌·推断待确认）
测试环境需求 提出验收环境要求、反馈可用性 C 测试负责人（当前：张东郅·推断待确认）
环境使用方 占用登记、按规则使用、用完释放、变更前公告 R 研发（当前：魏宗浩、岳阳、柯逸飞、邓乾、杨云峰、李国庆·推断待确认）
正式服数据管控（跃竞线） 禁止正式服造数、测试脚本连生产 A（升级） 跃竞负责人（当前：徐莉·推断待确认）
兜底 跨团队冲突与规则争议最终裁决 A（升级） 研发部门负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 目标环境编号/地址，查看台账中的当前用途、版本、占用人、冻结期
  • 操作类型：占用 / 改配置 / 切 tag / 清理 / 重装 / 换机 / 挪网段 / 改用途
  • 影响范围、预计时长、是否需要快照或数据备份
  • 涉及演示、展会或发布会时，确认冻结期日历和兜底环境

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定并发布分层规范：开发服（只部署已合入的最新 dev）/测试验收服（只部署即将发布内容）/预发演示/生产；域名与分支对应规则 环境与基础设施负责人、Leap 研发负责人 规范调整后 1 个工作日内发布 飞书知识库 环境分层规范 👤人工判断
2 每个环境登记台账，凭据只写存放位置不写明文 环境与基础设施负责人 环境上线当天 多维表格 环境台账 🔧飞书固化
3 占用/变更申请：在台账登记或用机器人命令"占用/释放" 使用方 操作前至少 30 分钟；改用途/重装/换机提前 1 个工作日 机器人、多维表格 占用记录 🔧+🤖
4 冲突协调：按发布优先级排序；冻结期内改动需产品总监同意 环境与基础设施负责人、产品总监 冲突出现 2 小时内 台账 协调结论 👤人工判断
5 变更前机器人自动@当前占用人并发群公告 使用方 操作前 机器人 变更公告 🤖自动化
6 执行：重装/清理前先快照或备份；不在服务器上直接构建；压测前确认网关限流与影响面 使用方、IT 运维 按申请窗口 PVE 快照、CI 变更结果 👤人工判断
7 变更后更新台账（版本/用途/状态）、简单冒烟并通知 使用方 完成后 30 分钟内 台账、群通知 台账更新 🔧+🤖
8 季度盘点：台账与实际机器核对，回收闲置，查清不明机器与进程 环境与基础设施负责人、IT 运维 每季度第 1 周 台账 盘点报告 🔧飞书固化

5. 交付物与模板

  • 交付物：环境分层规范文档、环境台账、占用/变更记录、季度盘点报告
  • 建议模板/表单：
    • 环境台账：环境编号｜层级（开发/测试验收/预发演示/生产）｜产品线｜地址/域名｜当前版本｜负责人｜数据级别（可清/保留/生产）｜是否允许改配置｜当前占用人｜占用截止｜冻结期｜最近快照｜凭据存放位置
    • 占用/变更申请：申请人｜环境｜操作类型｜影响范围｜开始/结束时间｜是否需备份｜通知对象
    • 上线拆分检查清单（内测转公测）：数据迁移方案｜域名/证书/DNS｜数据库配置｜支付链路｜OTA 地址｜回滚方案｜全链路冒烟｜负责人

6. 异常与升级

  • 两人同时要独占同一环境 → 环境与基础设施负责人按发布优先级排序 → 争议 2 小时内升级 Leap 研发负责人
  • 冻结期内需要改动演示/生产环境 → 产品总监（A（升级））批准后方可操作，否则禁止
  • 环境用途或分支对应规则有争议 → 环境与基础设施负责人整理选项 → Leap 研发负责人（A（升级））当天裁决
  • 跃竞线正式服出现测试数据或测试脚本误连生产 → 立即停用并清理 → 跃竞负责人（A（升级））当天决定处置与追责范围
  • 跨团队冲突经 Leap 研发负责人裁决后仍无法执行 → 升级研发部门负责人/CTO（A（升级））1 个工作日内最终裁决
  • 机器被换走/挪网段未提前通知导致阻塞 → 当天恢复缓冲环境 → 升级研发部门负责人/CTO 复盘
  • 环境用途被临时改动（如生产服改成演示形态）→ 操作人先公告并写明恢复时间 → 未公告的由 Leap 研发负责人复盘
  • 共享第三方实例（NewAPI 等）互相覆盖 → 改为独立实例或独立账号 → 环境与基础设施负责人当天给出隔离方案
  • 内测转公测临近上线仍未拆分生产/测试 → 按上线拆分检查清单逐项确认 → 未完成项由研发部门负责人/CTO 决定是否延期
  • 测试服数据丢失、压测打崩 → 按快照恢复 → 转 RND-75

7. 衡量指标

  • 台账准确率 = 季度盘点中台账与实际一致的环境数 / 环境总数，目标 ≥ 95%
  • 环境冲突次数 = 每月因占用冲突或未通知变更导致测试中断的次数，目标 ≤ 2 次
  • 未公告变更次数 = 未经公告的重装/切换/改用途次数，目标 0
  • 冻结期违规变更次数，目标 0

8. 低效诊断

  • 现象：环境用途靠口头宣布，"test 是 preview 还是 QA""108 是测试还是迁移用"反复澄清（规范成文环节）｜依据：「工程咨询产研」2026-02、「Leap产研测」2026-08
  • 现象：测试服曾被交给客户当正式服使用，客户端硬编码测试地址导致用户误连（环境边界环节）｜依据：「Leap产研测」2026-06
  • 现象：hotfix 验证与 dev 共用开发服、压测占满 IO、切模型 tag 靠群里问（占用登记环节）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：测试机被换走、挪网段、重装未通知使用方，迭代延误 0.5～1 天（变更通知环节）｜依据：「鼎慧产研决策部」2026-07、「交付订单通知群」2026-07
  • 现象：生产服被临时改为演示形态，其他使用者看到异常（生产保护环节）｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：多人共用同一 NewAPI 实例，令牌互相刷新，排障耗时数小时（隔离环节）｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：内测转公测前一晚才确定数据与域名方案、生产测试未拆分，通宵部署（上线规划环节）｜依据：「Leap产研测」2026-05
  • 现象：演示机同时被调试、录视频、展会占用，容器过多导致崩溃；服务器上直接构建导致测试数据丢失（演示环境保护与部署规范）｜依据：「LeapCore（archived）」2026-05、「LeapAll」2026-04

9. 分支变体

  • Leap 主线：50=开发服（只部署已合入 dev 的最新代码）；51=测试验收/预发布（只部署即将发布内容，含 hotfix 验证）；102=公司内部生产与演示，公司同事默认使用；108/109 等 v5 测试机用途以台账为准
  • 字字可研：dev.（IP 白名单，开发自测，自动部署）/ test.（公开，提测与内部使用）/ 正式域名（生产）
  • LeapAll 公测：现有服务器作正式服，测试/内测单开；服务按 [service].leapall.cn，测试服统一加 test
  • 内网演示机（如 103）：演示/展会前冻结、做快照、准备兜底机；创建容器前做内存阈值拦截
  • 跃竞/跃玩：正式服禁止上传测试商品；测试脚本启动前校验环境变量，防止连生产；compose 覆写的配置在台账注明
  • OPC 社区平台：生产服务器由合作方提供，测试服与教育项目测试服共用，需在台账注明

10. 待确认问题

  • 环境台账与分层规范的主责是否为环境与基础设施负责人？与 IT 运维的边界（机器/网络 vs 用途/规则）是否认可？
  • 50/51/102/108/109 当前的准确用途是否与第 9 节一致？
  • 占用提前 30 分钟、改用途提前 1 个工作日是否可行？
  • 是否建设按分支自动部署的预览环境，由谁排期？
  • AI 编码工具直接操作测试服的安全规则由谁制定？
RND-49测试环境部署与更新通知待优化135

状态：待优化｜证据：有证据（卡片 18 张 / 会话 3 个）｜优先级：频5 × 耗3 × 跨3 × 险3

  • 适用场景：代码合入 dev/test 或需要验证某组件时，把服务（Agent、v5 cloud/edge、LeapAuth、Cloudreve、LeapUpdate、前后端）部署到测试环境，并在更新前预告中断、更新后通知验收时启动
  • 负责人：主责——测试环境发布负责人（当前：魏宗浩·推断待确认）；协同——CI/CD 与环境运维（当前：宋祺睿、杨云峰·推断待确认）、代码提交者（各研发）、测试负责人（当前：张东郅·推断待确认）、产品经理（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① PR 合并入待发布队列 → ② 发布预告并收集搭车 → ③ 加发布锁 → ④ 核对来源分支后构建 → ⑤ 部署/滚动更新 → ⑥ 完成播报版本与变更 → ⑦ 失败@提交者修复或回滚 → ⑧ 工单转测试验收
  • 交付结果：测试环境运行指定版本；发布预告与完成通知（环境、组件、版本/commit、变更清单）；环境台账版本字段更新；失败修复或回滚记录
  • 状态依据：已有 Gitea Actions 流水线、"测试环境 发布通知"机器人卡片和 @_all 预告习惯；但 2026-01～10 群内反复出现"50 更新了吗""谁发的更新不发通知"、两人撞发互相覆盖、失败卡片无人认领，约 300 次

1. 场景判定

  • 触发条件：PR 合入 dev/test；工单进入待测试需要环境；hotfix 需放到验收服；测试环境部署失败或自动回滚
  • 典型说法：「我准备给 50 发更新，有人需要一起发吗？」「50 测试服 agent 容器将进行更新，期间可能会断一小会」「部署 test 没，卡点在哪」「谁最闲，去修一下」
  • 判断问题：目标是否是内部测试/验收环境（不是生产，也不是客户机器）？
  • 不归本流程管：正式版本上线 → 请走 RND-51；环境用途与占用规则 → 请走 RND-48；流水线建设与通用构建失败排查 → 请走 RND-37 / RND-38；提测与验收流转 → 请走 RND-39；Agent 镜像构建 → 请走 RND-55；已交付/演示机升级 → 请走 X-DLV-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测试环境发布 汇总待发布队列、发预告、加锁、发布、完成播报 A 测试环境发布负责人（当前：魏宗浩·推断待确认）
CI/CD 与环境运维 维护流水线、镜像仓库、LeapUpdate、凭据有效期，失败兜底排查与回滚 R CI/CD 与环境运维（当前：宋祺睿、杨云峰·推断待确认）
自助发布人 发布自己负责的组件时遵守同一预告与发布锁 R 研发（当前：岳阳、吴世豪、葛家和、柯逸飞、李铭熙、马漳毓·推断待确认）
失败修复 修复自己提交导致的构建/部署失败 R 代码提交者（当前：季学森、侯怡辰、徐鑫宇、陈锦杰·推断待确认）
验收方 按完成通知开测，报告环境问题 C 测试负责人（当前：张东郅·推断待确认）及测试（当前：李国庆、涂维轩、黄霆瑄、潘浩伟·推断待确认）
产品验收 接收部署通知后验收 I 产品经理（当前：杨萌·推断待确认）
兜底 发布优先级冲突、失败超时裁决 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 已合入的 PR/commit 链接与对应工单号
  • 要发布的组件清单与目标环境（50/51/102/108/109/test）
  • 构建来源分支与 run 编号（防止发错分支）
  • 新增环境变量/配置项（通过 PR 模板或密钥管理工具提交，不私发）
  • 是否会中断长连接或重启 agent，预计中断时长

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 PR 合并后登记待发布队列（组件、PR、工单、是否含配置变更） 代码提交者 合并后 30 分钟内 多维表格 / Gitea webhook 队列记录 🤖+👤
2 发布预告：环境、组件、来源分支、预计中断窗口，询问"有无不能停的任务、要搭车的组件" 测试环境发布负责人 发布前至少 15 分钟；cloud 或全量 stack 前 30 分钟 机器人公告卡片（同时推测试群与研发群） 预告 🤖自动化
3 加发布锁：同一环境同一时间只允许一个发布 测试环境发布负责人 发布开始时 机器人 / 环境台账 锁状态 🔧飞书固化
4 核对构建来源分支与 run 后触发构建；需重跑时注明原因 测试环境发布负责人 预告时间到即执行 Gitea Actions 构建产物 🤖自动化
5 部署/滚动更新；期间测试遇到异常先看锁状态，不报缺陷 测试环境发布负责人 按预告窗口 LeapUpdate / CD 脚本 更新完成 🤖自动化
6 完成播报：版本/commit、变更清单、对应工单，@测试与提需求人；更新台账版本 测试环境发布负责人 完成后 15 分钟内 机器人卡片、环境台账 完成通知 🤖自动化
7 失败：机器人自动@提交者；提交者 30 分钟内响应；1 小时未恢复回滚上一版本并通知 代码提交者 → CI/CD 与环境运维 30 分钟响应 / 1 小时恢复 Gitea、CD 自动回滚 修复或回滚记录 🤖+👤
8 工单转"待测试/待验收"，测试开测 代码提交者、测试 部署成功当天 工单系统 工单状态更新 🔧+🤖
9 每周统计失败类型（lint、依赖版本、lock 未提交、环境变量、凭据过期），补充 CI 检查 CI/CD 与环境运维 每周一次 机器人统计 失败分类与改进项 🤖自动化

5. 交付物与模板

  • 交付物：发布预告卡片、发布完成卡片、待发布队列、环境台账版本记录、失败/回滚记录
  • 建议模板/表单：
    • 发布预告卡片：环境｜组件｜来源分支/版本｜发布人｜预计开始时间｜预计中断时长｜是否断长连接｜搭车截止时间
    • 发布完成卡片：环境｜组件｜版本/commit｜变更清单（工单号）｜结果（成功/失败/已回滚）｜@验收人
    • 待发布队列（多维表格）：组件｜PR｜工单｜提交者｜是否含配置变更｜目标环境｜状态
    • 新环境信息格式：环境名｜客户端下载｜登录地址｜管理端地址｜账号获取方式（不写明文）

6. 异常与升级

  • 撞发或覆盖他人搭车分支 → 后发者停止并联系先发者 → 协商不成升级 Leap 研发负责人（A（升级））当场定发布顺序
  • 失败卡片 30 分钟无人认领 → CI/CD 与环境运维接手 → 1 小时未恢复升级 Leap 研发负责人（A（升级））决定回滚或指定修复人
  • kubeconfig、镜像仓库账号等凭据过期导致连续失败 → CI/CD 与环境运维当天更新，并检查是否影响生产发布
  • 测试环境整体不可用超过半个工作日 → 按 RND-75 开故障单，通知测试暂停验收
  • 修复已部署但验收仍失败 → 先核对环境版本与工单 commit，排除"测的是旧版本"

7. 衡量指标

  • 发布通知覆盖率 = 带预告与完成卡片的发布次数 / 全部发布次数，目标 100%
  • 合并到可测时长 = PR 合并到测试环境可用的工作时长，目标 ≤ 4 小时
  • 部署失败恢复时长 = 失败卡片到成功或回滚完成，目标 ≤ 1 小时
  • 撞发次数 = 每月同一环境并发发布次数，目标 0
  • "是否已部署"类询问次数，每周统计，目标季度内下降 50%

8. 低效诊断

  • 现象：测试反复问"更新了吗/发到哪了"，修复未部署导致验收假失败（部署与验收衔接）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08、「工程咨询产研」2026-01
  • 现象：两人同时发同一组件、搭车分支被覆盖，或都以为对方在发而漏发（发布协调无锁）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：更新期间无状态提示，测试误判 50 环境故障（状态可见性）｜依据：「Leap产研测」2026-07、「Leap产研测」2026-09
  • 现象：失败卡片高频且无固定响应人，通知噪声大被认为"没有意义"（失败响应）｜依据：「工程咨询产研」2026-03、「工程咨询产研」2026-04
  • 现象：依赖版本手改、lock 未提交、环境变量私发、凭据过期导致反复失败（构建输入）｜依据：「工程咨询产研」2026-05、「工程咨询产研」2026-06、「Leap产研测」2026-10
  • 现象：PR 发起即部署到测试环境，未评审代码进入测试（触发规则）｜依据：「鼎慧产研决策部」2026-03
  • 现象：新环境的账号、管理端地址反复追问（信息发布格式）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07

9. 分支变体

  • Leap 主线：50 手动跑 CI 或联合打包发 stack；51 打 RC tag 发布，只放即将发布内容；Agent 容器更新须预告 30±15 分钟内会重启
  • 字字可研：前端 test 分支触发 Release Test，后端 dev 分支合并即自动部署，失败自动回滚（前端无回滚）；前端依赖后端 npm 包，须先发包再升级引用并提交 lock 文件；管理后台单独部署并通知产品
  • OPC 社区平台：部署后发布测试服/管理端链接及"本轮可测内容"
  • 已有《软件部署SOP》（LeapCore 部署步骤与检查单）可作为新环境搭建参考，引用前需脱敏其中凭据

10. 待确认问题

  • 测试环境发布设固定负责人/轮值，还是"谁合并谁发布"？
  • 50 是否改为合并 dev 即自动部署？是否设固定发布窗口（如每日 12:00、17:00）？
  • 失败 30 分钟响应、1 小时回滚是否可行？
  • 发布通知推送到哪个群（测试群、研发通知群或独立 CI 群）？
  • 待发布队列用多维表格还是 Gitea 标签维护？
RND-50版本封版、打 tag 与发布分支管理待新建240

状态：待新建｜证据：有证据（卡片 9 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：迭代到期或对外发版节点前，需要盘点随版本发布的工单、执行 P0 清零闸门、冻结代码、打 rc/正式 tag、拉发布/hotfix 分支并剥离下一版本代码时启动
  • 负责人：主责——版本负责人（当前：王皓南·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、发版执行人（当前：柯逸飞、岳阳、宋祺睿、杨云峰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发部门负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 公布发版日历 → ② 工单收口与范围确认 → ③ P0 清零闸门 → ④ 冻结代码 → ⑤ 全仓库打 rc tag、建 hotfix 分支 → ⑥ rc 冒烟与放行 → ⑦ hotfix 双向合入核对 → ⑧ 打正式 tag 交接发布
  • 交付结果：发版清单（版本范围、仓库×tag×分支×负责人）、全仓库 rc/正式 tag、hotfix/vX 分支、测试放行结论、移出版本的工单清单
  • 状态依据：冻结与版本号规则只以群消息宣布；2026-03～09 出现误发正式版本号不可撤销、hotfix 只合发布分支未进主线导致客户端包崩溃、冻结后部分仓库漏打 tag、承诺的全量发布漏发等事故，属"出过事故/漏项"

1. 场景判定

  • 触发条件：迭代周期到期（发布日前 1～2 个工作日）；对外承诺上线日期；需要切 hotfix 分支；版本范围调整
  • 典型说法：「下午 2 点开始冻结代码，打包上测试」「所有仓库现在冻结代码打 tag」「测完确认没有 p0 bug 就发」「rc 随便造，正式版本别乱搞就行」
  • 判断问题：本次动作是否改变"哪些代码随哪个版本发出"？
  • 不归本流程管：正式上线部署与客户通知 → 请走 RND-51；hotfix 准入与发布 → 请走 RND-54；客户端打包签名 → 请走 RND-52；OTA 推送 → 请走 RND-53；日常分支协作规范 → 请走 RND-31；迭代规划排期 → 请走 RND-06；更新日志 → 请走 X-PRD-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
版本负责人 定发版日历与冻结时间、范围取舍、Go/No-Go、打正式 tag A 版本负责人（当前：王皓南·推断待确认）
测试放行 每日收口播报、P0 清零确认、rc 冒烟结论 R 测试负责人（当前：张东郅·推断待确认）
发布分支与 tag 各仓库建发布/hotfix 分支、剥离下一版本代码、打 rc tag R 发版执行人（当前：柯逸飞、岳阳、宋祺睿、杨云峰·推断待确认）
hotfix 合入核对 正式 tag 前核对发布分支与 main 差异并补漏 R 客户端主程（当前：岳阳·推断待确认）
hotfix 提交 冻结后修复按规则双向合入 R 研发（当前：葛家和、吴世豪、侯怡辰·推断待确认）
发版节奏与对外 对外承诺时间、参与延期决策 C 产品总监（当前：杨萌·推断待确认）
开放平台封板 开放平台封板时间表、PR 评审、红黑发布 R 开放平台后端/运维（当前：杨睿·推断待确认）、开放平台产品（当前：吴亚军·推断待确认）
兜底 跨产品线冲突、Go/No-Go 争议裁决 A（升级） 研发部门负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 本迭代工单列表（已验收/验收中/未完成）、P0/P1 清单
  • 需打 tag 的仓库清单（Agent、LeapNew、LeapCore、v5 cloud/edge、LeapAuth、Cloudreve、LeapUpdate、前后端包等）
  • 上一版本 tag、当前 main 差异、待合 hotfix 列表
  • 版本号规则与工作台中的迭代版本
  • 发布日与对外已承诺的时间点

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 公布发版日历：收口日、冻结时间、rc 冒烟窗口、正式发布日 版本负责人 迭代开始 1 个工作日内 飞书日历 + 机器人提醒 发版日历 🔧+🤖
2 每日收口播报：未关闭工单数、P0/P1 数，标注延期风险项 测试负责人 冻结前每日 11:00 前 工单系统统计 收口日报 🤖自动化
3 确认版本范围；未验收工单移至下一迭代（批量改迭代须二次确认） 版本负责人、测试负责人 冻结前 1 个工作日 工单系统 版本范围清单、移出清单 👤人工判断
4 P0 清零闸门：P0 未清零不得冻结；P1 逐项决定随版或转 hotfix 测试负责人 → 版本负责人 冻结前 Go/No-Go 检查单 闸门结论 👤人工判断
5 冻结预告与执行：到点停止向发布线合入非修复代码 版本负责人 冻结前 4 小时预告 研发通知群机器人 冻结公告 🤖自动化
6 全仓库打 rc tag 并建 hotfix/vX 分支；未验收代码从发布分支剥离；逐仓库在清单打勾 发版执行人 冻结后 2 小时内 Gitea、打 tag 脚本 tag 与分支清单 🤖自动化
7 rc 部署验收服冒烟，给出放行结论与遗留问题分级；生成版本功能概要 测试负责人 rc 后 1 个工作日内 51/验收服、工单系统 放行结论、功能概要 🔧+🤖
8 冻结后修复只走 hotfix：先合 dev 再 cherry-pick 到 hotfix（或两边各提 PR），每次递增 rc 号 研发 随修复 Gitea rc.N 👤人工判断
9 正式 tag 前比对"发布分支 vs main"差异，确认无漏合 客户端主程 正式 tag 前 差异比对脚本 差异报告 🤖自动化
10 打正式 tag，交接 RND-51 发布 版本负责人 放行当天 Gitea 正式 tag 👤人工判断

5. 交付物与模板

  • 交付物：发版日历、发版清单、Go/No-Go 检查单、放行结论、移出版本工单清单
  • 建议模板/表单：
    • 发版清单（多维表格）：版本号｜仓库｜rc tag｜正式 tag｜hotfix 分支｜负责人｜状态｜漏合检查结果
    • Go/No-Go 检查单：P0 清零｜P1 处置结论｜rc 冒烟通过｜打包签名就绪｜模型/渠道可用｜回归通过｜版本负责人确认｜测试负责人确认
    • 版本号规则：a.b.c 为正式版本；a.b.c-rc.N 为上线前版本；a.b.c-hotfix.N 为上线后修补；正式号仅在放行后由版本负责人打
    • 移出版本工单清单：工单号｜原因｜目标迭代｜确认人

6. 异常与升级

  • 冻结时间到仍有 P0 → 版本负责人决定延期或剔除功能 → 产品总监当天同步对外时间
  • 冻结后发现部分仓库漏打 tag → 发版执行人 1 小时内补打并在清单标注
  • 误发正式版本号（不可撤销）→ 立即通知版本负责人，改用下一版本号或 hotfix 号，不删除已发布包
  • hotfix 只进了发布分支或只进了 main → 客户端主程在正式 tag 前补齐 → 已发出的按 RND-54 处理
  • 版本范围口径不一 → 以发版清单为准，版本负责人当天拍板 → 跨产品线冲突升级研发部门负责人/CTO
  • 升级拍板条件：跨产品线发版冲突，或版本负责人与测试负责人对 Go/No-Go 结论不一致 → 研发部门负责人/CTO（A（升级））当天裁决
  • 迭代被批量误改 → 版本负责人当天回退并通知相关人

7. 衡量指标

  • 按期冻结率 = 按日历时间冻结的版本数 / 版本总数，目标 ≥ 90%
  • 漏 tag/漏合次数 = 每个版本漏打 tag 的仓库数 + 漏合 hotfix 数，目标 0
  • 正式版后补丁数 = 正式版发布后 7 天内的 hotfix 版本数，目标 ≤ 2
  • 冻结后变更量 = 冻结后进入发布分支的修复数，逐版本下降

8. 低效诊断

  • 现象：冻结时间、提测截止临时宣布，测试时间被压缩，发布前通宵（日历环节）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：未验收代码已进主分支，切发布分支只能逐个回退，同一修复写两遍（分支策略）｜依据：「Leap产研测」2026-08
  • 现象：hotfix 流程多种说法并存，hotfix 只合发布分支未进主线，导致客户端包崩溃（合入核对）｜依据：「Leap产研测」2026-08
  • 现象：自动化把一批验收中工单批量改到下个版本（范围管理）｜依据：「Leap产研测」2026-08
  • 现象：冻结后部分仓库没打 tag，出现两个同名迭代（tag 执行）｜依据：「Leap产研测」2026-09
  • 现象：封版前一晚 CI 打满、签名机故障，承诺的全量发布无人认领而漏发（封版到发布的交接）｜依据：「Leap产研测」2026-09
  • 现象：版本号规则只有一条群消息，误发正式版本号无法撤回（规则成文）｜依据：「工程咨询产研」2026-03
  • 现象：冻结后 hotfix 范围现场协商，打包开始后又取消（hotfix 准入）｜依据：「研发通知」2026-09

9. 分支变体

  • Leap 主线：迭代第二周周三下班冻结；rc 发 51 冒烟；Agent、LeapNew、v5 等仓库各自打 tag，须按全仓库清单执行；v5 网关发布节奏单独确定
  • 字字可研：版本号以飞书工作台迭代版本为准；rc 由脚本自增；前端依赖后端 npm 包版本须联动
  • 开放平台：活动/课程前按封板时间表执行（暂停涉及数据库的功能 → 上云 → 封板 → 试用 → 彩排）；PR 须带 E2E 与样式前后对比图；红黑发布并压测；新旧环境双线须分别提 PR
  • 客户定制版：从对应正式 tag 拉定制分支，只改定制内容，hotfix 同步评估是否需要
  • 企业版/个人版/渠道包：Go/No-Go 口径分别定义

10. 待确认问题

  • 版本负责人是否固定为 Leap 研发负责人？是否设轮值发版人并由老手带新人？
  • hotfix 统一规则：先合 dev 再 cherry-pick，还是两边各提 PR？hotfix 分支是否允许直接 PR？
  • 是否规定"未验收通过的代码不得合入主分支"？
  • "第二周周三下班冻结"和 P0 清零闸门是否作为固定制度？
  • 发版清单放多维表格还是工单系统？正式 tag 是否只允许版本负责人推送？
RND-51正式版本发布上线待优化500

状态：待优化｜证据：有证据（卡片 43 张 / 会话 17 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：测试验收通过的迭代版本或 hotfix，需要部署到内部生产（如 102）、对外正式服或客户环境（OTA），涉及服务端、客户端 OTA、agent 镜像、管理后台、配置中心等任一组件上线时启动。
  • 负责人：主责——版本发布负责人（当前：宋祺睿·推断待确认）；协同——研发负责人（放行决策，当前：王皓南·推断待确认）、客户端/OTA 发布（当前：岳阳、葛家和、邓乾·推断待确认）、测试负责人（当前：张东郅；字字可研线：李国庆·推断待确认）、产品负责人（当前：杨萌·推断待确认）、基础设施与 CI（当前：杨云峰、吴世豪·推断待确认）、客户经理（当前：吴琪·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 建发布单定窗口 → ② 封版与组件清单核对 → ③ 测试环境回归与放行签字 → ④ 备份与发布前检查 → ⑤ 按序部署（迁移→服务端→后台/配置→客户端 OTA） → ⑥ 生产冒烟与放行/回滚 → ⑦ 发布公告与中文更新日志 → ⑧ 观察期后关闭发布单
  • 交付结果：生产/客户环境运行指定版本；关闭状态的发布单（版本号、组件、冒烟结论、回滚点）；对内对外发布公告与中文更新日志。
  • 状态依据：已有 50 验证→51 验收→102 生产的环境口径、Gitea tag/CI、LeapUpdate、构建与签名机器人卡片、字字可研 prod-release skill 与冒烟用例 wiki、平台部《版本发布 SOP》；但 2026-01～10 各产品线反复出现"部署了没/要发哪些组件"追问、漏组件、漏 cherry-pick、版本号错乱，发布后才发现未备份或缺配置，并发生正式服不可用、客户机升级死锁等事故，缺全公司统一的发布单与检查单。

1. 场景判定

  • 触发条件：迭代结束出正式版；线上问题需 hotfix；产品或销售定了对外发布时间点；客户环境需要 OTA 升级；节假日、大会、演示前需要确定发布窗口或冻结期。
  • 典型说法：「今天几点上线，有没有问题」「这次需要发哪些组件」「备份好叫我发布」「打 tag，发包，发镜像，部署完 double-check」「这个版本今天发吗」
  • 判断问题：本次变更是否要进入任何真实用户在用的生产/正式/客户环境？是 → 走本流程；仅开发服、测试服自测部署 → 不走（按日常 CI 部署）。
  • 不归本流程管：客户端安装包打包、签名、下载链接分发 → 请走 RND-52；客户现场首次装机部署 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；菜单/接口权限、环境配置等生产变更审批 → 请走 RND-58（生产变更管控（备份、灰度、配置、访问审批）），但须在本流程检查单中勾选确认；发布公告与更新日志的写法与发布渠道 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发布负责人 建发布单、排窗口、执行服务端部署、发布后观察并关单 R 版本发布负责人（当前：宋祺睿·推断待确认）
研发负责人 确定发布范围，放行/延期/回滚决策 A 研发负责人（当前：王皓南·推断待确认）
客户端/OTA 发布 客户端 OTA 渠道与分组配置、agent 镜像推送 R 客户端负责人（当前：岳阳、葛家和、邓乾·推断待确认）
测试负责人 测试环境回归、放行签字、生产冒烟 R 测试负责人（当前：张东郅；字字可研线：李国庆·推断待确认）
产品负责人 确认上线范围、审更新日志、对内与业务方通知 C 产品负责人（当前：杨萌·推断待确认）
基础设施/CI 数据库备份、证书域名、CI runner 与流水线 C 运维/CI（当前：杨云峰、吴世豪·推断待确认）
客户经理 通知客户、收集上线反馈 I 客户经理（当前：吴琪·推断待确认）
兜底 跨产品线冲突、重大事故升级 A（升级） 研发部门负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 发布单（多维表格一行）：版本号、产品线、组件清单（服务端/客户端/agent 镜像/管理后台/配置中心）、各组件 tag 或 commit、目标环境、窗口、各步执行人。
  • 已进版本工单清单与未测清单（工单系统按"版本=x.y 且状态=已测"导出）。
  • 测试环境回归结论与冒烟用例（复用现有冒烟用例 wiki 模板）。
  • 数据库迁移脚本（已在回档后的测试库验证）；配置项/环境变量/密钥变更项名称（不写值）。
  • 兼容性说明：是否 breaking change；是则附发布顺序、强更策略与回退方案。
  • 回滚点：上一版镜像/版本号，PG 与 Redis 备份位置。
  • 中文更新日志草稿与对外公告文案。
  • 请求最少包含字段（向发布负责人提"要发版"时必带，缺项不排窗口）：产品线、版本号、组件清单及各组件 tag/commit、目标环境、本次包含的工单号清单、测试结论链接、是否 breaking、是否有迁移/配置/密钥变更项、期望窗口与原因、需要通知的客户或业务方、回滚点。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 创建发布单，定版本号、组件、窗口（避开深夜与大会/演示前一天） 发布负责人 常规发布日前 3 个工作日；hotfix 发布前 2 小时 飞书多维表格 发布单（发布单多维表格，一版一行，链接贴到研发通知群） 🔧飞书固化
2 封版：冻结发布分支，确认修复已 cherry-pick、版本号已递增，此后只收 P0 修复 研发负责人 发布前 24 小时 Gitea 分支保护/rc tag 封版 tag（Gitea）+ 封版通知（研发通知群，写明版本号与截止）；超时→发布负责人 @ 研发负责人 🤖+👤
3 生成"已进版本/未测"清单，未通过测试的功能隔离或关闭开关 测试负责人 封版后 4 小时内 工单系统+脚本 版本功能清单（贴回发布单"工单清单"字段） 🤖自动化
4 测试环境全量回归+冒烟，P0/P1 清零后签字放行 测试负责人 发布前 4～6 小时完成 冒烟用例模板 放行结论（发布单"放行人/结论"字段，通过/带风险/拒绝）；超时→发布负责人 @ 测试负责人，决定延期 👤人工判断
5 发布前检查：备份 PG/Redis，核对环境变量与密钥、后台价格/额度包配置、镜像端口、证书域名有效期、组件版本一致性 发布负责人 发布前 1 小时 检查单/校验脚本 勾选完成的检查单（发布单附件，含备份位置） 🔧+🤖
6 发布预告：告知窗口、影响范围、预计中断时长，确认无不可中断任务 发布负责人 发布前 1 小时 飞书机器人卡片 预告卡片（研发通知群 + 业务方群） 🔧飞书固化
7 按序部署：数据库迁移→服务端（滚动/优雅停机）→管理后台/配置中心→客户端 OTA/镜像；breaking 变更先服务端后客户端 发布负责人、客户端负责人 窗口内，单次不超过 2 小时 CI/Pulumi/LeapUpdate 部署记录（版本/commit 写入发布单，各组件完成即在发布单勾选） 🤖+👤
8 生产冒烟（主流程+本次 P0 用例），清 CDN 静态缓存 测试负责人 部署完成后 30 分钟内 冒烟用例/自动冒烟脚本 冒烟结果（发布单"冒烟"字段 + 研发通知群一句话结论） 🤖+👤
9 放行或回滚：冒烟失败且 30 分钟内修不好即回滚到上一版镜像 研发负责人 冒烟结果出来后 15 分钟内 Gitea registry 决策记录（发布单"放行/回滚"字段，回滚时同步登记故障台账） 👤人工判断
10 发布公告+中文更新日志，推内部群、业务方群；客户经理转达客户 产品负责人 放行后 1 小时内 飞书卡片/AI 汇总提交 公告、更新日志（研发通知群/业务方群卡片；更新日志归档知识库；客户通知由客户经理在客户群转达并回执） 🤖+🔧
11 观察告警与错误率、跟踪客户反馈，关闭发布单 发布负责人 发布后 24 小时 告警群/监控 关闭的发布单（状态=已关闭，附观察结论） 🔧飞书固化

5. 交付物与模板

  • 交付物：关闭的发布单、部署记录、冒烟结果、发布公告、中文更新日志；如回滚则附回滚记录与事故登记。
  • 发布单字段：版本号｜产品线｜类型（迭代/hotfix/rc/特供）｜组件与 tag/commit｜目标环境｜窗口｜是否 breaking｜迁移脚本｜配置/密钥变更项｜备份位置｜回滚点｜放行人｜部署人｜冒烟人｜通知人｜状态。
  • 发布检查单：分支与 cherry-pick｜版本号递增｜组件版本一致（core/node/agent）｜PG/Redis 备份｜环境变量/密钥｜后台配置｜镜像端口｜菜单权限同步｜证书域名｜CDN 缓存｜定时任务优雅停机｜公网数据库临时开放已关闭｜不可中断任务确认。
  • 公告模板：版本号、生效时间、新增/修复、已知问题、是否需重装或 OTA、数据/余额是否互通、反馈入口。

6. 异常与升级

  • 封版后仍要加需求 → 默认进下个版本或走 hotfix → 研发负责人当场决策。
  • 生产冒烟失败 → 30 分钟内修不好即回滚 → 研发负责人；影响客户时 1 小时内同步客户经理。
  • 部署后服务崩溃、crash-loop、证书或配置丢失 → 立即回滚并在告警群登记 → 研发负责人（15 分钟内），2 小时未恢复升级研发部门负责人。
  • 客户环境升级失败/死锁 → 暂停全量 OTA，改小批量灰度 → 研发负责人当日决策，客户经理同步客户。
  • 窗口内关键执行人缺席 → 延期，不由未授权人代发 → 发布负责人立即在群内公告新窗口。
  • 放行结论、封版 tag 或组件部署记录超过时限未出现在发布单 → 发布负责人在发布单评论 @ 对应责任人（不另开群追问）→ 1 小时无响应升级研发负责人决定延期或换人。
  • 业务方/客户经理未收到发布公告或不知道发了什么 → 产品负责人 1 小时内补发公告并在发布单登记通知对象；客户侧问题统一回到发布单，不在多个群分散问。
  • 节假日前后发布 → 节前发服务端、节后发客户端，排好 oncall → 研发负责人提前 3 个工作日确认。
  • 升级条件：跨产品线发布冲突（窗口、资源争用）研发负责人无法协调，或因发布导致生产不可用 2 小时未恢复、影响多个客户 → 升级研发部门负责人拍板（A（升级））。

7. 衡量指标

  • 发布准时率 = 按发布单窗口完成次数 / 总发布次数，目标 ≥ 90%。
  • 发布后返工率 = 发布后 48 小时内回滚或补 hotfix 次数 / 发布次数，目标 ≤ 15%。
  • 已修未发时长 = 修复合入到上生产的天数中位数，目标 ≤ 14 天（P0 ≤ 1 天）。
  • 发布事故数 = 因发布导致生产不可用的次数，目标每月 0 次。
  • 发布追问数 = 每次发布群内"部署了没/哪个版本"类追问，目标 ≤ 1 次。

8. 低效诊断

  • 现象：发布时间点与结果靠群内反复追问，部署完成后不主动同步｜依据：「Leap产研测」2026-06、「工程咨询产研」2026-04、「跃玩remote工作组」2026-07
  • 现象：发版时才问"要发哪些组件"，组件漏传、版本不一致、正式包未改版本号、修复未 cherry-pick 到发布分支，需重打｜依据：「Leap产研测」2026-07、「Leap产研测」2026-08
  • 现象：无固定发版节奏，修复早已合入却长期不上线；上线日屡次延期｜依据：「Leap产研测」2026-06、「鼎慧产研决策部」2026-07、「Leap产研决策部」2026-10
  • 现象：发布前检查缺失——未备份数据库、新增必填配置未下发致服务反复重启、公网数据库忘关、后台配置缺失｜依据：「Leap产研测」2026-06、「工程咨询产研」2026-02、「工程咨询产研」2026-03
  • 现象：客户端与服务端不兼容变更在发布前一晚才暴露，假期无人兜底｜依据：「Leap产研测」2026-09
  • 现象：内部环境未复现，外部客户机升级死锁，缺灰度｜依据：「Leap产研决策部」2026-09
  • 现象：发版时间与内容对业务方不透明，业务方无法提前验收，客户不知道更新了什么｜依据：「工程咨询产研」2026-04、「鼎慧产研决策部」2026-08
  • 现象：部署方法沉淀在个人脚本/skill 中，交接即断档，部署架构无文档｜依据：「鸽子群模态分群」2026-05、「公司内FDE」2026-09
  • 现象：服务端更新造成长时间停机，滚动发布与维护提示缺失｜依据：「鼎慧产研决策部」2026-05、「LeapPPT」2026-05
  • 现象：官网上线与宣发未联动，宣发前临时切域名、表单接口失效｜依据：「模态跃迁 官网研发」2026-09

9. 分支变体

  • Leap 主线（LeapCore/LeapNew/v5 cloud/edge/agent）：50 验证 → 51 验收 → 102 内部生产 → 客户环境 OTA；hotfix 走 hotfix/版本分支；客户私有部署升级须最大化保留数据；完全私有化买断客户不提供无条件 OTA。
  • 字字可研（工程咨询）：rc tag 上测试，正式/hotfix tag 上生产；前端、后端、管理后台分别发布但同一发布单；迭代结束后下周一发版，提前 4～6 小时通知业务方；使用现有冒烟用例 wiki。
  • 跃玩会员端：后端合 master 并同步数据库 → 同步菜单/权限表 → 后端在群内确认后，前端各品牌（星域/猩球/PeRo/弈荟）小程序分别提审 → 正式服冒烟 → 通知俱乐部；补丁可单独发，不阻塞当期。
  • LeapPPT/官网/外部客户项目：测试服 → pre-test → 正式服；breaking update 安排低峰夜间窗口，开维护提示页并保留快照；官网切域名须检查 HTTPS/DNS/API 代理/备案号并与宣发窗口联动。
  • 开放平台：main 自动部署灰度机，打 Vxx tag 触发生产，滚动部署+优雅停机，回滚用上一版镜像，发版前压测，生产保留服务器镜像备份。
  • 培训/特供版：单独分支与发布渠道，不走主线 update，版本号加后缀（如 -fde），须在更新服务登记，防止被生产版本覆盖。
  • 实验性功能：可随版本发布，但默认灰度/开关并设词元预算上限；测试只保证不影响其他功能与计费。
  • 教育/平台部线：已有《版本发布 SOP》（提前 3 天发飞书 TODO、发版前 24 小时禁加需求、P0/P1 禁发、P2 需评审、按模块经堡垒机发布），以该文档为准并对齐本检查单。
  • Java 定时任务服务：替换容器前确认定时任务优雅停机配置，避免发版期间死锁。
  • 协作协议：遵循 ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）、ALL-02（消息分级与响应时限）、ALL-03（决策记录与发布）

10. 待确认问题

  • 主责是统一设一个"版本发布负责人"，还是按产品线（Leap 主线/字字可研/跃玩/开放平台/LeapPPT）分设？
  • 放行采用"测试负责人+研发负责人"双签，还是试行群内提出的"3 票赞同"发版机制？
  • 常规发布日是否全公司统一为"迭代结束后下周一"？禁止发布的深夜截止时间定为几点？
  • 封版提前 24 小时、测试服提前 4～6 小时验证在当前人力下是否可行？
  • 发布单落在飞书多维表格还是工单系统的"上线工单"？是否已有上线工单模板可复用？
  • 对客户的更新通知由客户经理发还是产品负责人发？客户群公告是否需审批？
  • 平台部《版本发布 SOP》是否推广为全公司基线版本？
RND-52客户端打包、签名与安装包分发待优化320

状态：待优化｜证据：有证据（卡片 25 张 / 会话 9 个）｜优先级：频5 × 耗4 × 跨4 × 险4

  • 适用场景：需要新版 Windows/macOS（含 Linux/信创）客户端安装包——nightly、beta/测试、正式、hotfix、客户定制或渠道包——时，从 CI 打包、签名公证、冒烟、上传下载入口、配置 OTA 到群内通知的全过程；也包括签名证书的采购与有效期管理。
  • 负责人：主责——客户端发版负责人（当前：岳阳·推断待确认）；协同——打包执行/CI（当前：葛家和、吴世豪、李铭熙·推断待确认）、签名与证书保管（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、OTA 配置（当前：邓乾、葛家和·推断待确认）、产品与版本台账（当前：杨萌、杨黔昆·推断待确认）、研发负责人（当前：王皓南·推断待确认）、财务（证书采购开票，当前：黄梦婷·推断待确认）；兜底——研发部门负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 登记打包申请与版本号 → ② 签名预授权 → ③ CI 多平台构建 → ④ 签名与公证 → ⑤ 冒烟放行 → ⑥ 上传 COS 并更新版本台账/下载页 → ⑦ 配置 OTA 渠道（先灰度） → ⑧ 机器人推送发布卡片并观察
  • 交付结果：带正确版本号与签名的各平台安装包；版本台账中一条完整记录（含下载链接与测试结论）；已配置的 OTA 渠道；固定群内置顶的发布卡片。
  • 状态依据：已有 Gitea Actions 构建矩阵、nightly、"模态助手"签名审批卡片、构建成功卡片、LeapUpdate、COS 与"leap系列产品链接"wiki；但 2026-03～09 反复出现"包呢/最新包在哪"追问（单个时段约 15 次）、版本号重名、测试与正式包混用、未签名被系统拦截、签名审批超时导致构建白跑、OTA 配置错误循环更新、wiki 链接过期，签名证书归属与台账缺失。

1. 场景判定

  • 触发条件：迭代或 hotfix 需要客户端新版本；测试、演示、展会、内测需要可安装包；客户定制或渠道包；下载链接报毒或失效；签名证书缺失或临近到期。
  • 典型说法：「最新的包发一下」「最新的安装包现在是哪个」「不是先冒烟再 OTA 吗」「把签名改成自动的」「我们有 Windows 和 Mac 的签名证书吗」
  • 判断问题：交付物是否是"用户要安装的客户端包或客户端 OTA 更新"？是 → 本流程；只是服务端、镜像、后台上线 → RND-51。
  • 不归本流程管：服务端/agent 镜像/管理后台生产上线与整体发版窗口 → 请走 RND-51；客户现场装机部署 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；证书采购的付款与报销 → 请走 FIN-01（对公采购申请与付款审批），本流程只负责发起申请与台账；代码签名证书的申请与保管规范 → 以 X-SEC-23（代码签名证书申请、保管与签名使用）为准。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户端发版负责人 定版本号与渠道、签名预授权、决定是否 OTA A/R 客户端发版负责人（当前：岳阳·推断待确认）
打包执行 触发构建、Mac 签名公证、处理构建失败 R 客户端研发/CI（当前：葛家和、吴世豪、李铭熙·推断待确认）
签名与证书 签名机/UKey、Apple 开发者账号、证书台账与续期 R IT 运维（当前：杨明学·推断待确认）
测试 Win/Mac 安装、冒烟、OTA 更新路径验证 R 测试负责人（当前：张东郅·推断待确认）
OTA 配置 LeapUpdate/后台渠道与分组、上传更新文件 R 客户端研发（当前：邓乾、葛家和·推断待确认）
产品 更新日志与 OTA 弹窗文案、版本台账与下载页维护、对内通知 R 产品负责人（当前：杨萌、杨黔昆·推断待确认）
研发负责人 发布范围、hotfix 是否发 C 研发负责人（当前：王皓南·推断待确认）
财务 证书采购开票与付款 C 财务负责人（当前：黄梦婷·推断待确认）
申请人 登记打包申请，说明用途、目标服与平台 R 需求方（产品/测试/销售/交付等，按实际）
兜底 争议拍板、安全与效率取舍 A（升级） 研发部门负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 打包申请：产品线（LeapCore/LeapNew/LeapAll/ClawLite/定制）、类型（nightly/beta/正式/hotfix/定制/渠道）、目标服（测试服/正式服）、分支与 commit、目标平台。
  • 版本号：按规则递增（测试版带 beta，正式版不带；hotfix 末位递增，不复用已发版本号）。
  • 签名条件：签名机在线、证书与 Apple 开发者协议有效、签名审批人（一主二备）在岗。
  • 冒烟用例：基础流程 + 历史 P0 + 本次修复项 + OTA 更新路径。
  • 更新日志与 OTA 弹窗文案草稿。
  • 兼容性：能否 OTA、是否需卸载重装、数据/余额是否迁移或互通。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在版本台账登记打包申请，确认版本号、分支与渠道 申请人、客户端发版负责人 用包前 1 个工作日；紧急提前 2 小时 飞书多维表格 台账记录 🔧飞书固化
2 对指定 commit 做签名预授权，避免构建后审批超时 客户端发版负责人 触发构建前 签名审批机器人 预授权记录 🤖+👤
3 CI 构建多平台矩阵，失败自动告警到群 打包执行 触发后 1 小时内出产物 Gitea Actions 安装包、构建卡片 🤖自动化
4 签名与公证：Win 代码签名，Mac 签名+公证并产出 zip 与 latest-mac.yml，校验文件 Hash 打包执行、签名岗 构建完成后 1 小时内 签名机/Apple 公证 已签名包 🤖自动化
5 冒烟：Win/Mac 安装、启动、登录、主流程、P0 回归、OTA 更新路径；打包后不再加功能 测试负责人 收包后 2 小时内 冒烟用例 测试结论 👤人工判断
6 上传 COS 固定目录，更新版本台账与统一下载页/wiki 链接，旧链接标注"过期" OTA 配置、产品 放行后 30 分钟内 COS/下载页/wiki 有效下载链接 🤖+🔧
7 配置 OTA：渠道（stable/preview/定制）、分组、强/弱更、弹窗文案；先小范围灰度再全量 OTA 配置 放行后 1 小时内 LeapUpdate/后台 OTA 配置记录 👤人工判断
8 机器人推送发布卡片到固定群并置顶 产品 上传后 30 分钟内 飞书机器人 发布卡片 🤖自动化
9 观察 OTA 成功率与反馈，异常时暂停下发或回退 客户端发版负责人 发布后 24 小时 LeapUpdate/反馈表 观察结论、台账状态更新 👤人工判断

5. 交付物与模板

  • 交付物：已签名安装包、版本台账记录、OTA 配置记录、发布卡片、更新日志。
  • 版本台账字段：版本号｜产品线｜类型｜目标服｜平台｜分支/commit｜文件 Hash｜签名状态｜下载链接｜OTA 渠道/分组｜测试结论｜更新日志｜是否需重装｜发布时间｜状态（有效/作废/过期）。
  • 打包检查清单：版本号递增｜包名规范（产品+版本+环境+个人/企业）｜Win/Mac 版本一致｜签名/公证｜安装路径与卸载｜依赖完整｜授权跳转｜OTA 更新文件齐全｜杀软兼容。
  • 发布卡片模板：版本号、渠道、各平台下载链接、变更摘要、已知问题、安装说明（是否需重装、数据是否互通）、反馈入口。
  • 证书台账：类型、主体、到期日、保管人、存放位置、续期提醒（到期前 30 天）。

6. 异常与升级

  • 签名审批超时/构建失败 → 重新预授权后重跑，不得以未签名包对外分发 → 客户端发版负责人（30 分钟内）。
  • Apple 开发者协议失效或证书过期 → 签名岗当日处理 → 研发部门负责人。
  • 冒烟发现致命问题 → 停止上传与 OTA，台账标"作废" → 研发负责人（1 小时内）。
  • OTA 循环更新或大面积失败 → 立即关闭该渠道下发、回退配置 → 客户端发版负责人（15 分钟内），影响客户时同步客户经理。
  • 下载链接报毒/被拦截 → 换为已签名、信誉良好的下载地址，必要时向安全厂商申诉 → 签名岗（1 个工作日内）。
  • 无证书或证书需续购 → 发起采购审批（供应商、主体、开票） → 研发部门负责人审批，财务付款。
  • 升级条件：签名安全要求与出包时效冲突（如是否允许未签名包外发）、跨产品线渠道争议，或 OTA 大面积失败影响客户 → 升级研发部门负责人拍板（A（升级））。

7. 衡量指标

  • 出包周期 = 打包申请到发布卡片推送的时长，目标正式包 ≤ 4 小时、hotfix ≤ 2 小时。
  • 重打包率 = 因版本号/签名/漏依赖/选错分支重打次数 / 出包次数，目标 ≤ 10%。
  • 找包追问数 = 每次发包后群内"包在哪/哪个是最新"追问，目标 ≤ 1 次。
  • 签名覆盖率 = 对外分发包中已签名比例，目标 100%。
  • OTA 成功率 = 成功更新终端数 / 下发终端数，目标 ≥ 98%。
  • 证书按期续期率 = 到期前完成续期的证书比例，目标 100%。

8. 低效诊断

  • 现象：群内频繁催包，安装包以文件形式在群里流转，需要时再重发链接｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：版本号重名、测试包与正式包混在一起、分支选错打成主线｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：Mac 包未签名被提示"已损坏"，用户需手动执行去隔离命令；Windows 包报毒、签名反复丢失｜依据：「跃迁AI总动员」2026-05、「跃迁AI总动员」2026-06、「LeapAll」2026-04
  • 现象：签名审批在构建完成后才发起，超时即构建失败白跑；审批权限集中在少数人｜依据：「Leap产研测」2026-07
  • 现象：未冒烟即 OTA、OTA 配置写错导致循环更新、定制版 OTA 被遗忘｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08
  • 现象：下载入口多处且过期，wiki 链接无人维护，机器人也查不到最新链接｜依据：「Leap产研测」2026-06、「leapall逗狗群」2026-06
  • 现象：打包上传受网络影响（上传远长于打包），签名环境变量靠口头询问｜依据：「Leap产研测」2026-07
  • 现象：签名证书反复重新研究，归属与台账缺失｜依据：「New API Claw SKILL计划」2026-03
  • 现象：约定打包时间后仍不断加功能，导致发包延误；已合并功能因未整体测试被剔除，引发"合了没上"争执｜依据：「Leap产研测」2026-06、「Leap产研测」2026-09

9. 分支变体

  • nightly：每夜自动构建，不签名，仅内部使用，产物放固定网盘/下载目录并说明用法，不走 OTA。
  • beta/测试服包 vs 正式服包：测试版版本号带 beta；若两者包名相同只能装一个，公告须说明数据/余额是否互通。
  • 正式版/hotfix：必须签名并冒烟通过后才能 OTA；hotfix 版本号末位递增。
  • LeapAll（个人版）与 LeapCore（企业版）：共享代码但分别打包、分别测试；LeapCore 安装与使用需内网/飞连访问。
  • 客户定制版、渠道包：通过渠道参数单独构建与分组，台账指定专人负责其 OTA，避免遗忘。
  • ClawLite/MercAll：Win（NSIS/Inno）+ Mac（dmg 公证），上传 MercAll 后台应用管理并替换网页下载链接；先在群内测试通过再挂官网。
  • Claw 傻瓜安装包/U 盘批量：分区镜像批量克隆（约 11 分钟/个），每批登记版本号与授权方式。
  • Linux/信创：由信创适配岗按同一台账登记出包。
  • macOS 自动更新须同时上传 zip 与 latest-mac.yml。

10. 待确认问题

  • 客户端发版负责人是否为单一岗位？定制版/非标品的专人是谁？
  • 签名审批是否正式采用"预授权 commit + 一主二备审批人"？内测/beta 包是否允许不签名？
  • 统一下载入口用官网下载页、wiki 链接页还是多维表格版本台账？由谁维护？
  • 版本号与包名规则（beta 标识、hotfix 递增、个人/企业区分）是否已成文？
  • 证书台账由 IT 还是财务保管？续期提醒提前 30 天是否合适？
  • 出包时限（正式 4 小时、hotfix 2 小时）在当前打包机与网络条件下是否可行？
  • "CI 上云、打包与签名分离"方案是否已排期？
RND-53OTA 在线更新与强制更新待优化240

状态：待优化｜证据：有证据（卡片 9 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：LeapCore/LeapAll 客户端、容器镜像或 updater/stack 组件的新版本（含 hotfix）已测试通过，需要在 LeapUpdate 配置授权与渠道并推送 OTA，或者要强制淘汰旧版、撤回发错的版本时启动
  • 负责人：主责——客户端发布与 OTA 负责人（当前：岳阳·推断待确认）；协同——OTA 推送与安装包管理（当前：葛家和·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapUpdate 维护（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、对客沟通产品经理（当前：黄飞鹏·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 兼容性检查（服务端先行）→ ② LeapUpdate 登记版本、渠道、授权与最低可用版本 → ③ 内部渠道灰度 → ④ 升级冒烟 → ⑤ 按窗口全量推送并发公告 → ⑥ 核对版本分布，强制升级旧版 → ⑦ 发错版本时撤回
  • 交付结果：LeapUpdate 中一条完整的版本发布记录（版本号、渠道、灰度范围、最低可用版本、是否强更）；推送完成并验证过的客户端/容器版本；公告群升级通知；版本分布统计
  • 状态依据：已有 LeapUpdate、OTA 弹窗、help.leapcore.cn 下载页和约两周一次的发版节奏；但 2026-05～10 反复出现以下问题：OTA 何时支持被追问约 6 次，谁来发 OTA 靠口头提醒，用户用旧版报已修问题 15 次以上，发错版本导致签名校验失败，LeapUpdate 字段没人看得懂、只能让 AI 代发。强制更新和弃用规则至今没有交付

1. 场景判定

  • 触发条件：新版本或 hotfix 已冒烟/验收通过，需要推给用户；大量用户停留在旧版；服务端协议变更导致旧客户端不兼容；版本发错需要撤回；容器镜像、updater/stack 需要在线更新到客户机器
  • 典型说法：「冒一下没毛病的话也发 OTA 吧」「为什么不能 OTA」「请求里加个版本 header，版本不对的直接报错」「现在的 leapupdate 真的用不懂」「刚才发错版本了」「设置→关于，先看看你是什么版本」
  • 判断问题：要发的版本是否已经测完并打好正式包？这件事是"把现成的包推给用户"，还是"做包、修 bug"？只有前者走本流程
  • 不归本流程管：打包、签名与安装包上传 → 请走 RND-52；hotfix 要不要发、带哪些提交 → 请走 RND-54；服务端/镜像部署到生产 → 请走 RND-51、RND-55；更新日志与发版公告文案 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）；已交付客户机、演示机的现场升级与回退 → 请走 X-DLV-32；用户安装/更新失败的一线支持 → 请走 X-CS-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
OTA 发布负责人 判断能否推送，定渠道与灰度范围，拍板强更与撤回 A/R 客户端发布与 OTA 负责人（当前：岳阳·推断待确认）
OTA 执行人 在 LeapUpdate 配置版本、上传包，按渠道推送（普通版/渠道版/LeapAll/信创包） R OTA 推送与安装包管理（当前：葛家和·推断待确认）
LeapAll 服务端 LeapAll 服务端先行部署，LeapAll 客户端 OTA R LeapAll 服务端研发（当前：邓乾·推断待确认）
LeapUpdate 维护 维护授权、执行合约、渠道配置和升级预检，排查 not authorized 等报错 R/C LeapUpdate 维护（当前：宋祺睿、杨云峰·推断待确认）
测试 推送前做升级冒烟，推送后抽检升级路径 R 测试负责人（当前：张东郅·推断待确认）
产品 确认强更策略、弹窗时机与公告内容 C 产品总监（当前：杨萌·推断待确认）
对客沟通 提前告知客户升级窗口和断连时长 R 对客沟通产品经理（当前：黄飞鹏·推断待确认）
交付/销售 接收通知，转告客户与渠道 I 交付、销售对接人（当前：待指定）
兜底 资源协调与争议拍板 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 已签名的正式包或镜像 tag、版本号，以及对应的 Gitea tag 和 commit
  • 测试结论：冒烟通过记录、已知问题
  • 兼容性说明：是否依赖服务端新特性、是否改了登录/协议字段、服务端是否已经部署
  • 渠道清单：内测/preview/stable；普通版、渠道版、LeapAll、信创包；测试(50)、hotfix 验收(51)、生产(102)、客户私有实例
  • 本版"最低可用版本"和是否强更的建议
  • 回滚目标：上一个稳定版本号
  • 更新要点（X-PRD-35 产出）和需要通知的客户名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 兼容性检查：服务端是否已部署，登录/协议字段是否变更；依赖服务端的，先完成服务端发布 OTA 发布负责人 推送前 1 个工作日 飞书任务（OTA 检查清单） 勾选完成的检查清单 🔧飞书固化
2 在 LeapUpdate 登记版本、包/镜像、渠道、授权与执行合约字段（表单预置默认值），提交前跑升级预检，核对版本号是否一致 OTA 执行人 包就绪后 2 小时内 LeapUpdate 版本发布记录 🤖+👤
3 先推内部渠道（公司内测机、50/51），小范围灰度 OTA 执行人 登记当天 LeapUpdate 灰度推送记录 🤖+👤
4 升级冒烟：从上一版本和"最老在用版本"各升级一次，覆盖未登录状态和 LeapAll/LeapCore 两种模式 测试 灰度后 4 小时内 测试机（可用 AI mock 服务端） 升级验证结论 👤+🤖
5 选窗口全量推送：客户机和容器更新放在企业下班时间；需要断连的，提前 1 个工作日通知客户 OTA 发布负责人、对客沟通 验证通过后按窗口执行 LeapUpdate、客户群 全量推送记录、对客通知 👤人工判断
6 公告群推送升级通知：版本号、更新要点、已知问题、手动下载链接 OTA 执行人 推送后 30 分钟内 公告群机器人 升级公告 🤖自动化
7 推送 24 小时后核对版本分布：逐一提醒仍在旧版的客户；低于最低可用版本的请求由服务端拒绝，并提示强制升级 OTA 发布负责人 推送后 1 个工作日内 版本统计看板 版本分布、提醒记录 🤖自动化
8 发错版本或出现严重回归：立即暂停渠道，退回上一稳定版本，在公告群说明 OTA 发布负责人 发现后 30 分钟内 LeapUpdate 撤回记录 👤人工判断

5. 交付物与模板

  • 交付物：LeapUpdate 版本记录、灰度与全量推送记录、升级公告、版本分布报表、撤回记录（如有）
  • 建议模板/表单：
    • OTA 发布检查清单（飞书任务模板）：版本号、tag/commit、签名是否通过、服务端是否先行、协议是否变更、渠道列表、灰度范围、最低可用版本、是否强更、回滚版本、测试结论、对客通知是否已发
    • 强制更新规则表（多维表格）：产品线、最低可用版本、弃用日期、提示文案、豁免客户（例如停用自动更新的定制客户）
    • LeapUpdate 操作手册：各字段含义与默认值、updater 和 stack 的发布方式差异、常见报错（not authorized、升级检查不通过）的处理办法；AI 代发前必须先读这份手册

6. 异常与升级

  • LeapUpdate 报 not authorized 或预检不通过 → 执行人按手册排查 1 小时 → 仍未解决当天交 LeapUpdate 维护 → 影响生产升级超过 4 小时，升级到研发负责人
  • 签名校验失败或发错版本 → 30 分钟内暂停渠道并回退，公告群说明 → 当天复盘
  • 推送后集中报障（同一问题 ≥3 人）→ 暂停全量，转 RND-54 判断是否发 hotfix
  • 旧客户端因协议变更无法自动升级 → 在 help 下载页提供手动安装包，对客沟通逐一通知客户（1 个工作日内）
  • 客户坚持在业务时段升级 → OTA 发布负责人与客户书面确认后再执行
  • 首次在生产做大跨度版本升级 → 先在一台客户机试升级并观察 1 小时，再分批推进
  • 升级条件：OTA 故障影响生产升级超过 4 小时、强更策略在产品与研发间有争议，或撤回涉及多个客户 → 升级研发部门负责人拍板（A（升级））

7. 衡量指标

  • 升级覆盖率 = 全量推送 7 天后，达到最低可用版本的活跃客户端占比，目标 ≥ 90%
  • 旧版报障占比 = 反馈中确认"旧版已修"的问题数 / 全部反馈数，目标 ≤ 10%
  • OTA 发布耗时 = 包就绪到全量推送完成的时间，目标 ≤ 1 个工作日（不含客户指定窗口）
  • 发布事故数 = 发错版本、签名失败、强更误伤的次数，目标每月 0 次

8. 低效诊断

  • 现象：对外公测前，OTA 和强制升级被反复追问，方案讨论多次但排期一再顺延，用户每次更新都得重新下载安装包（机制建设环节没有明确 owner）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：冒烟后谁发 OTA、何时发靠群里口头提醒；OTA 弹窗在未登录时弹出，事后才补流程（发布步骤没有固化）｜依据：「Leap产研测」2026-07
  • 现象：大量用户用旧版报已修问题，研发反复回复"先看版本号、先升级"；服务端还没部署新包就推了客户端（兼容性检查环节缺失）｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07
  • 现象：发错版本后撤回，导致更新包签名校验失败；推送任务被理解错没发出；客户不知道更新了什么（执行确认与通知环节缺失）｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：LeapUpdate 授权和执行合约字段没人看得懂，升级失败跨周末都没恢复，只能让 AI 代发（工具和操作手册缺失）｜依据：「Leap产研测」2026-10
  • 现象：客户桌面端有没有 OTA 口径不一，容器更新时间窗临时决定（终端类型与窗口规则缺失）｜依据：「鼎慧产研决策部」2026-06
  • 现象：销售找不到指定版本的安装包；首次在生产做跨大版本升级前，客户机状态看不到（版本分布不可见）｜依据：「某研究院客户项目群」2026-09

9. 分支变体

  • 客户端 OTA（LeapCore/LeapAll 桌面端）：走 LeapUpdate 渠道；早期没有 OTA 的旧包只能手动下载安装
  • 容器/镜像在线更新：通过 update 服务发镜像并 rebuild，数据盘挂载保留；安排在企业下班时间
  • 一体机 vs 桌面端：一体机内置 OTA；桌面端看版本是否支持
  • 包类型：内测版、稳定版、渠道版、LeapAll 普通版、麒麟信创包各走各的渠道；对外演示一律用稳定版
  • 环境：测试(50)、hotfix 验收(51)、生产(102)、客户私有实例
  • 定制客户：按合同可以停用自动更新，改为人工通知后升级；离线版通过授权码升级
  • 强制更新：公司内测可以不强更；对外公测和正式客户必须设置最低可用版本

10. 待确认问题

  • 主责是岳阳还是葛家和？LeapUpdate 仓库和服务的维护人是谁（宋祺睿、杨云峰、吴世豪）？
  • 请求头带版本号、低于最低可用版本即拒绝的强更机制是否已上线？旧版弃用要提前几天通知？
  • 客户端版本分布看板用什么数据源（PostHog、LeapAuth 还是 LeapUpdate）？
  • 客户推送窗口统一定为"工作日 19:00 后"是否可行？需断连时提前 1 个工作日通知是否足够？
  • 统一存放构建产物的平台是否立项，由谁负责？
RND-54Hotfix 紧急修复准入与发布待新建400

状态：待新建｜证据：有证据（卡片 15 张 / 会话 5 个）｜优先级：频5 × 耗4 × 跨4 × 险5

  • 适用场景：线上（生产 102、正式服、客户实例）出现阻塞使用或严重影响体验的缺陷，或者有经批准插队的紧急需求，需要绕开常规迭代、基于线上版本快速修复并发布时启动
  • 负责人：主责——Hotfix 流程负责人（当前：王皓南·推断待确认）；协同——客户端 hotfix 打包发布（当前：岳阳·推断待确认）、服务端 hotfix 部署（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（准入与紧急程度判定，当前：杨萌·推断待确认）、OTA 与签名（当前：葛家和·推断待确认）、Update 与 Agent 镜像（当前：杨云峰、魏宗浩·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提 hotfix 申请 → ② 准入判定 → ③ 从线上 tag 建 hotfix 分支并 cherry-pick → ④ 定时冻结并比对清单 → ⑤ 51 验收环境回归 → ⑥ 生产发布与 OTA → ⑦ 发布核对与公告 → ⑧ 回合主干并关单
  • 交付结果：一张关闭的 hotfix 申请单（含影响面、提交清单、测试结论、回滚方案）；新的小版本 tag 与生产部署；客户端 OTA；群内 hotfix 公告；修复已回合 main
  • 状态依据：2026-06 产品口头定义了准入范围，2026-08 起有每日 hotfix 总工单和 17:30 冻结的口头规则，2026-09 起改走 51 验收；但 2026-04～10 一直没有成文规范。期间出现过：全量误发导致生产下线、未验证提交进入 hotfix 引入更大问题、工单进了 hotfix 而代码没进、修复漏 pick、hotfix 一周发不出、凌晨直推无人验收。2026-08 产品负责人明确要求单独出标准化 SOP

1. 场景判定

  • 触发条件：线上缺陷阻塞用户使用（无法登录、核心功能不可用、计费或资金错误、安全漏洞）；严重影响体验且没有绕过办法；已对客户承诺、经产品总监批准插队的紧急需求；生产告警暴露的缺陷
  • 典型说法：「这个需要发 hotfix」「紧急是让你直接发 hotfix 的，不是让你等下次的」「这个提交需要提前进入 hotfix 了」「hotfix 装不下了」「能不能 hotfix 一下」「直接推，不会比现在更糟糕了」
  • 判断问题：不修的话，客户今天会不会用不了、会不会出错账？能不能等下一个迭代（约两周）？修复能不能小到"秒修秒合"，且不夹带未验收的功能？
  • 不归本流程管：普通缺陷和新需求 → 请走 RND-03、RND-04（需求不进 hotfix）；常规封版与发布 → 请走 RND-50、RND-51；故障止血与复盘 → 请走 RND-75；回滚到上一版本 → 请走 RND-59；OTA 推送配置 → 请走 RND-53；手工改生产库、改生产配置 → 请走 RND-58

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Hotfix 流程负责人 维护准入标准，指定当次发布人，最终放行 A Hotfix 流程负责人（当前：王皓南·推断待确认）
提出人 在 hotfix 看板登记申请，提供工单、影响面与修复 PR R 研发/测试/产品（按实际）
准入判定 判断属不属于 hotfix、紧急程度如何 R 产品总监（当前：杨萌·推断待确认）
客户端发布人 建 hotfix 分支，更新版本号，打客户端正式包，配合 OTA R 客户端 hotfix 打包发布（当前：岳阳·推断待确认）
服务端发布人 服务端/v5 打 tag，部署 51 和生产 R 服务端 hotfix 部署（当前：宋祺睿·推断待确认）
签名与 OTA 打签名包，推送 OTA R OTA 与签名（当前：葛家和·推断待确认）
组件发布 Update、LeapAuth、Agent 镜像各自的 hotfix R Update 与 Agent 镜像（当前：杨云峰、魏宗浩·推断待确认）
修复人 修复、合 main、提 hotfix 同步 PR、关联工单 R 各模块研发（当前：待指定）
测试 准入评估，按清单在 51 回归，给放行结论 R/C 测试负责人（当前：张东郅·推断待确认）
对客沟通 告知客户升级与断连 I 对客沟通产品经理（当前：黄飞鹏·推断待确认）
兜底 争议拍板、事故升级 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 缺陷工单号（LEAP-xxx）、严重度、影响面（哪些客户/用户、哪条产品线、哪一端）
  • 线上版本号和对应的 tag、构建 commit
  • 修复 PR 链接：先合 main，再提 hotfix 同步 PR；写明是否涉及数据库或配置变更
  • 回滚方案和回滚目标版本
  • 验收人和验收环境（51）
  • 是否需要客户断连，要提前通知哪些客户
  • 请求最少包含字段（hotfix 申请单必填，缺项不进准入判定）：工单号、严重度（P0/P1）与判定依据、影响面（哪些客户/用户、哪条产品线、哪一端）、线上版本号与 tag、修复 PR 链接、涉及组件（客户端/服务端/镜像/Update）、是否改数据库或配置、回滚方案、建议验收人、是否需对客通知、提出人岗位

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 hotfix 看板登记：工单、严重度、影响面、修复 PR、涉及组件（客户端/服务端/镜像） 提出人（研发/测试/产品） 发现后 1 小时内 工单系统 hotfix 看板 hotfix 申请（工单系统 hotfix 看板一张单，看板自动 @ 准入判定人） 🔧飞书固化
2 按准入标准判定进不进 hotfix；不进的标注原因，转下个迭代 产品总监 + 测试负责人 申请后 2 小时内（P0 为 30 分钟） 工单评论 准入结论（写在申请单评论：进/不进 + 理由 + 目标发布时间）；超时→提出人 @ Hotfix 流程负责人 👤人工判断
3 指定当次发布人；从线上 tag 建 hotfix/vX.Y.0 分支（v5 cloud 与 edge 共用一个分支）；版本号按小版本递增，不加后缀 Hotfix 流程负责人、发布人 准入后 1 小时内 Gitea hotfix 分支（Gitea）+ 当次发布人与分支名写入每日 hotfix 汇总单 🤖+👤
4 修复先合 main，再只 cherry-pick 必要提交到 hotfix 分支，PR 标题注明工单号；拆不干净的不得直接发主线代码 修复人 准入当天 17:00 前 Gitea PR hotfix 同步 PR（Gitea，PR 链接贴回申请单）；超时→转次日批次并在申请单说明 👤+🤖
5 每日 17:30 冻结 hotfix 分支，机器人比对分支提交与清单；没关联工单或没验证的提交一律 revert 发布人 当日 17:30 Gitea 分支保护 + 机器人 比对结果（机器人贴到研发通知群与汇总单，列出清单内/外提交） 🤖自动化
6 更新版本号，打正式包（签名）和带 hotfix tag 的镜像 客户端/服务端发布人 冻结后 1 小时内 CI 包、镜像（CI 产物链接写入汇总单）；CI 失败→转 RND-38 并在汇总单标注 🤖自动化
7 部署到 51 验收环境，测试按清单逐单验证，并冒烟核心用例 测试 部署后 2 小时内 51 环境 验收结论（逐单写在工单评论：通过/不通过 + 问题）；超时→发布人 @ 测试负责人，决定当晚是否发 👤+🤖
8 避开使用高峰（一般 20:00 后）发布生产：先 Update/服务端，再客户端 OTA；需要断连的提前通知客户 服务端发布人、客户端发布人 验收通过当天 LeapUpdate、CI 生产版本（部署记录与版本号写入汇总单；断连通知由对客沟通产品经理提前 2 小时在客户群发） 👤人工判断
9 核对各组件都已配置下发、客户端确实拿到新版本；群发公告（版本、修复项、风险、是否需手动更新） 发布人 发布后 30 分钟内 公告群机器人 发布核对（汇总单勾选各组件）、公告（公告群卡片，抄送提出人与对客沟通产品经理） 🤖自动化
10 确认修复已在 main、各仓库无漏同步，关闭申请单；事后补验收的在 1 个工作日内补完 Hotfix 流程负责人 发布后 1 个工作日内 工单系统 关闭的申请单（状态=已关闭，附生产版本号） 🔧飞书固化

5. 交付物与模板

  • 交付物：hotfix 申请单、hotfix 分支与 tag、51 验收结论、生产发布记录、OTA 记录、hotfix 公告
  • 建议模板/表单：
    • hotfix 申请单（工单类型 = hotfix）：工单号、严重度（P0/P1）、影响面、涉及仓库与组件、修复 PR、hotfix 同步 PR、是否改数据库/配置、回滚方案、验收人、计划发布时间、是否需对客通知、批准人
    • hotfix 准入标准：可以进——阻塞使用、资金/计费错误、安全漏洞、严重体验问题且无绕过办法、经批准的插队需求；不能进——新需求、未验收功能、改动大又拆不干净的提交
    • 每日 hotfix 汇总单：当日版本号、清单内工单与 PR、验收状态、发布人、发布时间
    • 风险分级：提示词类（低）、配置模板类（中）、网关/数据库/容器升级类（高，必须过 51）

6. 异常与升级

  • 非工作时间出现 P0 且找不到验收人 → 产品总监与流程负责人共同批准"先推后验"，群里留言记录批准人；配置类改动必须留操作记录；次日 10:00 前补完验收
  • 冻结后还要进 hotfix → 发布人同意并重新比对，否则顺延到次日
  • 发布后引入新问题 → 30 分钟内回滚（RND-59），转 RND-75 处理
  • hotfix 卡在 CI 超过 4 小时 → 转 RND-38，同时升级研发负责人
  • hotfix 占用测试环境、影响迭代测试 → 研发负责人当天协调 51 专用
  • PR 审核人没空 → 指定备用审核人，1 小时内完成审核
  • 准入结论超过 2 小时（P0 超过 30 分钟）未出现在申请单 → 提出人在申请单 @ Hotfix 流程负责人（不私聊、不另开群）→ 再过 30 分钟无响应升级研发部门负责人
  • 提出人或业务方问"修了没/发了没" → 统一回指 hotfix 看板与每日汇总单；看板状态未更新的，由发布人 30 分钟内补更新
  • 修复带数据库迁移 → 申请单写清兼容性，发布后不得随意回滚代码，回滚前评估数据（RND-34）
  • 无操作记录、责任无法定位的事故 → 按 RND-12 认定，开发负责人和测试负责人共同负责
  • 准入判定与流程负责人意见不一致 → 由 Hotfix 流程负责人拍板（A）；hotfix 引发生产事故、卡在 CI 超过 4 小时，或需占用 51 影响迭代测试 → 升级研发部门负责人拍板（A（升级））

7. 衡量指标

  • Hotfix 时效 = 准入到生产发布完成的时间，P0 ≤ 4 小时，P1 ≤ 1 个工作日
  • Hotfix 引入新故障率 = 发布后 7 天内因该 hotfix 产生新缺陷的次数 / hotfix 次数，目标 ≤ 5%
  • 清单一致率 = 分支提交与清单完全一致的 hotfix 次数占比，目标 100%
  • 漏 pick/漏同步次数，目标每月 0 次
  • 先推后验占比 ≤ 10%，且次日补验完成率 100%

8. 低效诊断

  • 现象：准入范围只在群里口头说过，"有没有稳定分支"认知不一，风险评估各说各话（准入标准没成文）｜依据：「Leap产研测」2026-06
  • 现象：一次 hotfix 涉及多个仓库，谁打包、谁 OTA 要来回确认；CI 打包持续失败，hotfix 拖了一周（组件分工与发布清单缺失）｜依据：「Leap产研测」2026-07
  • 现象：工单挂在 hotfix 里但代码不在；修复没进 hotfix 被反复追问；新需求也要求 hotfix（范围管理环节缺失）｜依据：「Leap产研测」2026-07
  • 现象：每日冻结后仍有合入，反复 revert 再贴回，工单描述被覆盖；测试多次提醒关联工单无人响应（冻结与比对靠人盯）｜依据：「Leap产研测」2026-08
  • 现象：凌晨直推没人验收，事后发现配置被改，又没有操作记录，追不到原因（验收与审计环节缺失）｜依据：「Leap产研测」2026-08
  • 现象：hotfix 范围散乱，需要临时指派发布人；修复漏同步到 hotfix 分支；"紧急"定义不清（发布人和紧急分级没固定）｜依据：「Leap产研测」2026-09
  • 现象：误合并的提交要靠引用群消息、贴哈希来排除；现有工单承载不了 hotfix 跟踪（跟踪工具缺失）｜依据：「Leap产研测」2026-09
  • 现象：包已打好却没配置下发，客户还在用旧版；不知道 hotfix 该往哪个分支提 PR（发布核对环节缺失）｜依据：「Leap产研测」2026-10
  • 现象：hotfix 占用测试环境，阻塞新迭代测试；hotfix 的上线风险没上报（环境与风险上报缺失）｜依据：「Leap产研决策部」2026-07、「Leap产研决策部」2026-08
  • 现象：早期发 hotfix 前才在群里逐人确认有没有半成品功能，并强推 dev/test 分支（准入检查靠临时询问）｜依据：「研发通知」2026-04、「鼎慧产研决策部」2026-04
  • 现象：修复完成后等 PR 审核，告警持续刷屏；回滚过多导致数据库里的新枚举在代码中不存在（审核单点、回滚兼容性没检查）｜依据：「告警通知群」2026-09

9. 分支变体

  • 客户端（LeapNew/LeapLite）：建 hotfix 分支 → 更新版本号 → 打签名正式包 → 51 验收 → OTA（RND-53）
  • 服务端 v5 cloud/edge：两端共用一个 hotfix 分支，可能需要同时发布；先更新 update，再更新 cloud
  • Agent 镜像：打 hotfix tag 镜像，走 RND-55；只改客户端时可以只打客户端包
  • LeapAuth、Cloudreve、LeapVPN、Update：各自仓库建 hotfix 分支，单独发镜像
  • 客户定制热修：只发到指定客户实例，并单独通知该客户
  • 跃竞/跃玩：由生产告警驱动热修，PR 审核通过后发布；是否热修由业务负责人决定；PR 模板要加"回滚影响/数据库变更"项
  • 鼎慧早期：PR → 合 dev 自动部署 → 测试通过 → 推 hotfix 分支编译 → 正式环境
  • 协作协议：遵循 ALL-02（消息分级与响应时限）、ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 流程负责人是否为王皓南？发布人是否实行轮值（岳阳、宋祺睿、杨云峰）？
  • 准入标准，以及 P0 4 小时、P1 1 个工作日的时限是否认可？"先推后验"由产品总监加流程负责人批准是否可行？
  • 每日 17:30 冻结是常态，还是改为有需要才发？
  • 51 是否固定为 hotfix 专用验收环境？
  • 跃竞线的热修是否纳入本 SOP，还是单独成文？
  • "查不到操作记录时开发负责人、测试负责人负责"的追责口径，是否同步写入 RND-12？
RND-55Agent 容器镜像构建与发布待优化144

状态：待优化｜证据：有证据（卡片 4 张 / 会话 1 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：Agent 代码、Dockerfile（时区、字体、办公库等）、内置 Skill 清单或运行配置有变更，需要构建 leapagent 容器镜像（含 hotfix 镜像），发布到测试(50)、生产(102)或客户环境时启动
  • 负责人：主责——Agent 镜像与 CI 负责人（当前：宋祺睿·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Skill 打包（当前：魏宗浩·推断待确认）、容器部署与 LeapUpdate 渠道（当前：杨云峰·推断待确认）、生产构建发布（当前：柯逸飞·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 代码与 Skill 清单入库 → ② CI 构建并推送镜像仓库（tag 带版本、commit、渠道）→ ③ 50 测试 → ④ preview 渠道灰度 → ⑤ stable 发布到生产/客户 → ⑥ 发布验证与通知 → ⑦ 登记版本与交接
  • 交付结果：镜像仓库里带版本 tag、哈希和 changelog 的 leapagent 镜像；LeapUpdate 渠道配置记录；50/102/客户实例的验证记录；发布通知
  • 状态依据：Gitea workflow、云厂商镜像仓库和 LeapUpdate 渠道都已有，2026-07 起 Skill 清单也并入了打包流程；但 2026-06～07 出现：打包脚本没入库、原负责人没交接完导致无人能打包、bug 修了却没更新镜像、误发全量导致生产 P0、技能目录丢失、Skill 要在两处重复配置，镜像命名、版本、渠道和测试范围都没有成文

1. 场景判定

  • 触发条件：Agent 代码合并需要上线；Dockerfile 或系统依赖调整；内置/官方 Skill 清单或 Skills 仓库 commit 变更；需要打 hotfix 镜像；客户（如客户A）需要单独下发新镜像
  • 典型说法：「agent 需要重新打包吗」「你们 bug 改完有更新云上镜像仓库里的镜像吗」「agent 打包现在究竟有没有人能打」「要测什么、测什么版本，同步下信息」「stable 渠道还是 preview」
  • 判断问题：这次变更最终是不是要体现在 Agent 容器里？如果只是客户端或服务端代码，不走本流程
  • 不归本流程管：Skill 本身的开发、评审与分级 → 请走 RND-56；hotfix 准入 → 请走 RND-54；客户端 OTA → 请走 RND-53；CI 流水线建设与 runner 资源 → 请走 RND-37；构建失败排查 → 请走 RND-38；镜像仓库权限与 AK → 请走 X-SEC-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
镜像负责人 维护打包 workflow 和镜像命名规则，审批发布渠道 A/R Agent 镜像与 CI 负责人（当前：宋祺睿·推断待确认）
Agent 研发 Agent 代码合并，确定本次版本内容 R Agent 研发（当前：岳阳·推断待确认）
Skill 打包 维护内置/官方 Skill 清单和 Skills commit R Skill 打包（当前：魏宗浩·推断待确认）
部署 50/102/客户实例的容器更新，LeapUpdate 渠道配置 R 容器部署与 LeapUpdate 渠道（当前：杨云峰·推断待确认）
生产构建 生产镜像构建与发布执行 R 生产构建发布（当前：柯逸飞·推断待确认）
测试 按测试范围验证镜像（图生图、内置 Skill、文件处理） R 测试负责人（当前：张东郅·推断待确认）
技术决策 发布时机、客户下发优先级 C Leap 研发技术负责人（当前：王皓南·推断待确认）
兜底 资源与争议拍板 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 所有改动已经提交入库（Agent 仓库、Skills 仓库、打包脚本），不允许用本地未提交代码打包
  • 本次镜像版本号，以及对应的 Agent commit、Skills commit（行业版还要行业 commit）
  • 内置 Skill 白名单（slug 列表），与 LeapUpdate 侧配置一致
  • 变更说明和测试范围（要测什么、测哪个版本）
  • 目标渠道：dev/preview/stable；目标环境：50/102/指定客户实例
  • 回滚目标：上一个稳定镜像 tag

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认代码、Skills 清单、Dockerfile 已合并入库，填写变更说明和测试范围 Agent 研发、Skill 打包 打包前 Gitea 合并记录、变更说明 👤人工判断
2 触发 CI 打包：workflow 自动读取 Skills 清单，构建镜像并推送到镜像仓库；tag 格式为"版本-渠道-commit 短哈希" 镜像负责人 合并后 2 小时内 Gitea Actions、镜像仓库 镜像 tag、哈希 🤖自动化
3 构建完成，机器人在群里推送卡片（tag、哈希、changelog、测试范围） 镜像负责人（机器人自动推送） 构建完成即时 飞书机器人 构建卡片 🤖自动化
4 在 50 重建容器（数据目录先备份），按测试范围验证 部署、测试 卡片推送后 4 小时内 50 环境 测试结论 👤+🤖
5 LeapUpdate 先发 preview 渠道，小范围观察 部署 测试通过当天 LeapUpdate preview 发布记录 🤖+👤
6 发 stable 到生产(102)，发布前确认渠道和范围（禁止误选全量）；客户实例按客户窗口分批下发 镜像负责人确认、生产构建执行 preview 观察 ≥ 2 小时后 LeapUpdate 生产发布记录 👤人工判断
7 发布后在生产验证图生图、内置 Skill 和文件读写，并通知相关群 测试、部署 发布后 1 小时内 102 验证结论、通知 👤+🤖
8 在镜像台账登记版本、哈希、各环境/客户当前版本 部署 发布当天 多维表格 镜像版本台账 🔧飞书固化

5. 交付物与模板

  • 交付物：镜像 tag 与哈希、构建卡片、50 测试结论、preview/stable 发布记录、生产验证结论、镜像版本台账
  • 建议模板/表单：
    • 镜像发布单：镜像版本、Agent commit、Skills commit、行业 commit、内置 Skill 清单、变更说明、测试范围、渠道、目标环境/客户、回滚 tag、执行人、确认人
    • 镜像版本台账（多维表格）：环境/客户、当前镜像 tag、上次更新时间、渠道、是否定制镜像
    • 打包操作手册（入库）：构建步骤、凭证获取方式（不写明文）、容器重建注意事项（重建不会重新复制 Skills，/data 要先备份）

6. 异常与升级

  • CI 构建失败 → 镜像负责人 1 小时内定位，超过 4 小时转 RND-38
  • 发布后容器异常（Skill 丢失、服务起不来）→ 30 分钟内回滚到上一 stable tag，升级 Leap 研发技术负责人
  • 误发全量或错渠道 → 立即停止发布并回滚，按 RND-75 当作生产事故处理
  • 镜像里 Skill 数量与清单不一致 → 停止发布，Skill 打包负责人当天核对
  • 关键人不在、没人能打包 → 按操作手册由备岗执行；备岗也做不了的，升级研发负责人
  • 客户实例更新失败 → 对客沟通通知客户，部署负责人 1 个工作日内处理
  • 升级条件：镜像发布导致生产 P0、关键人与备岗都无法打包，或发布时机/客户下发优先级与技术负责人意见不一致 → 升级研发部门负责人拍板（A（升级））

7. 衡量指标

  • 镜像发布周期 = 代码合并到 stable 发布的时间，目标 ≤ 1 个工作日（hotfix ≤ 4 小时）
  • 可复现率 = 能用入库脚本、由 CI 重新构建的镜像占比，目标 100%
  • 镜像发布事故数（误发全量、Skill 丢失、生产 P0），目标每月 0 次
  • 台账准确率 = 抽查环境实际版本与台账一致的比例，目标 100%

8. 低效诊断

  • 现象：bug 修完没更新镜像仓库；重建容器不会重新复制 Skills，导致技能目录丢失（构建与部署衔接缺失）｜依据：「Leap产研测」2026-06
  • 现象：原负责人没交接完，打包脚本不在仓库里，有人用本地未提交的代码打镜像，没人能完整打出环境镜像（脚本没入库、交接缺失）｜依据：「Leap产研测」2026-06
  • 现象：给客户下发的镜像版本说不清，测试反复追问测什么、测哪个版本（版本台账和测试范围缺失）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：发布时误选全量，生产容器被清，造成 P0（渠道确认环节缺失）｜依据：「Leap产研测」2026-06
  • 现象：Skill 清单要在镜像打包和 LeapUpdate 两处各填一次；镜像 tag 缺行业 commit；清单构建 CI 放哪个仓库也定不下来（配置重复、规则未定）｜依据：「Leap产研测」2026-07

9. 分支变体

  • 标准镜像：合并 → CI → 50 → preview → stable
  • hotfix 镜像：从线上 tag cherry-pick 后打 hotfix tag，按 RND-54 时效执行
  • 客户定制镜像：单个客户（如客户A）单独下发，记入台账，与全网 OTA 分开
  • 行业版（工程咨询版）：独立渠道和镜像，内置 Skill 清单单独维护
  • 产品差异：LeapAll 只预置生图和 PPT；LeapCore 预置业务合集；生图、PPT、视频等硬编码能力不依赖 Skill

10. 待确认问题

  • 主责是宋祺睿，还是由 Agent 研发（岳阳）负责、宋祺睿负责 CI？Agent 镜像自动打包工单是否已落地？
  • 镜像 tag 统一为"版本-渠道-commit"是否可行？行业版是否加行业标识？
  • preview 观察 2 小时再发 stable 是否合理？客户实例下发由谁审批？
  • 镜像版本台账放在哪里（多维表格还是 LeapUpdate 后台）？
RND-56产品 Skill 开发、评审、上架与内置发布待新建320

状态：待新建｜证据：有证据（卡片 15 张 / 会话 6 个）｜优先级：频4 × 耗4 × 跨5 × 险4

  • 适用场景：新增或更新面向用户的产品 Skill（内置、官方、开放平台、企业专属、付费），需要开发自测、质量与安全评审、确定分级、打包或上架下发，以及处理版本更新、回滚、下架和用户修改覆盖时启动
  • 负责人：主责——Skill 发布负责人（当前：魏宗浩·推断待确认）；协同——Skill 质量评估（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、Agent/内置 Skill 代码评审（当前：岳阳·推断待确认）、产品总监（分级与下发决策，当前：杨萌·推断待确认）、Leap 研发技术负责人（规则与术语，当前：王皓南·推断待确认）、付费 Skill 与 LeapSkill 后台（当前：李铭熙·推断待确认）、法务负责人（版权与合作，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 在 Skill 台账登记来源与作者 → ② 按 LeapSkill 规范开发、跑 selfcheck → ③ PR 进 Skills 仓库 → ④ 质量、安全、版权评审 → ⑤ 定分级（内置/官方/开放平台/企业）→ ⑥ 打包随镜像发布或上架下发 → ⑦ 发布通知与反馈收集 → ⑧ 版本更新、回滚与下架
  • 交付结果：Skills 仓库或开放平台里一个合规的 Skill 版本（manifest、版本号、display_name、来源与许可齐全）；Skill 台账条目（分级、负责人、渠道、计费方式）；评审记录（含 review_rank）；发布通知
  • 状态依据：已有 LeapSkill 格式规范 1.0.0、Skill 交接文档、Skills 仓库 official-skills 分支和 selfcheck；但 2026-04～10 一直存在：内置/官方/开放平台的定义反复调整，93 个 Skill 未通过准入校验，外部抓取的 Skill 未经审核就推给了客户，内置 Skill 名单没人说得清，slug 要两处重复填写，更新会覆盖用户修改，付费与分账链路没定。格式之外的评审、分级、发布流程都没有成文

1. 场景判定

  • 触发条件：产品需求新增 Skill（PPT、文档、网页、调研、生图、视频等）；已有 Skill 修复或升级；外部合作方/员工要把 Skill 上架；需要调整内置名单；Skill 出问题需要回滚或下架；付费 Skill 要接计费
  • 典型说法：「得有一批默认 SKILL」「你得自己审核一下 SKILL，别引入危险 SKILL 了」「内置 skill 只能下发更新，不能自己更新，也不能改」「谁审核的」「skill 现在就两个地方，official-skill 和开放平台」「行业 Skill 的质量评估只能人来做」
  • 判断问题：这个 Skill 是不是要作为产品能力交给客户或全员使用？只在个人或团队内部用的效率工具，不走本流程
  • 不归本流程管：内部效率 Skill/工具的分享推广 → 请走 RND-87；外部开发者/合作伙伴在开放平台入驻、开发者 Key 与分账 → 请走 ECO-06；行业版 Skill/插件提交 LeapOpen、按企业下发 → 请走 X-FDE-09；客户定制 Skill 的评估定价 → 请走 X-FDE-08；Agent 镜像构建 → 请走 RND-55；对外开源发布 → 请走 LEG-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Skill 发布负责人 维护台账、清单与发布流程，组织评审，执行内置/官方发布 R Skill 发布负责人（当前：魏宗浩·推断待确认）
作者 开发、自测、提 PR、维护版本 R 各 Skill 作者（当前：待指定）
代码评审 审代码、依赖与安全（危险命令、凭证） R Agent/内置 Skill 代码评审（当前：岳阳·推断待确认）
质量评估 结构与边界评估，真人试用评分（review_rank） R Skill 质量评估（当前：李凯·推断待确认）
分级决策 决定内置/官方/开放平台/企业专属，以及是否默认下发 A 产品总监（当前：杨萌·推断待确认）
规则与术语 统一术语、裁定规则争议 C Leap 研发技术负责人（当前：王皓南·推断待确认）
开放平台 slug 与版本管理、上架、企业/部门下发 R 开放平台负责人（当前：郭逸非·推断待确认）
付费 Skill 计费单价与扣费链路，LeapSkill 后台 R 付费 Skill 与 LeapSkill 后台（当前：李铭熙·推断待确认）
法务 第三方来源许可、合作协议与分账条款 C 法务负责人（当前：李瑶·推断待确认）
兜底 安全底线与争议拍板 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 需求来源与目标用户（全员/行业/指定企业），拟定分级
  • 来源说明：自研、改编（注明原出处与许可），还是第三方/外部合作方提供
  • 符合 LeapSkill 规范的包：SKILL.md、MANIFEST.json（含 display_name、版本号）、scripts/selfcheck.py；目录名用英文，描述用中文
  • 凭证方案：Skill 里不得写密钥；需要调用付费 API 的走网关，个人凭证放个人空间配置
  • 示例输入和示例产出（文件/截图），依赖与网络访问清单
  • 付费 Skill：计费方式（按调用）、单价、扣费测试账号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 Skill 台账登记：名称、slug、来源、作者、目标产品线、拟定分级、是否付费 作者 开发前 多维表格「Skill 台账」 台账条目 🔧飞书固化
2 按规范开发；用 creator 工具做结构校验；检查 slug 是否与现有 Skill、默认能力冲突 作者 按排期 creator 工具、selfcheck Skill 包 🤖自动化
3 自测：selfcheck 通过，在测试实例安装并跑通示例产出 作者 提 PR 前 50/测试账号 自测记录、示例产出 👤+🤖
4 提 PR 到 Skills 仓库主分支，按 PR 模板填写分级建议、版本号、变更说明、依赖与凭证方式 作者 自测后 1 个工作日内 Gitea Skill PR 👤人工判断
5 CI 自动校验 manifest、selfcheck、密钥扫描和网络依赖；评审人审代码与安全；质量评估人试用并记 review_rank；第三方来源由法务确认许可 代码评审、质量评估、法务 PR 后 2 个工作日内 Gitea CI、AI 预审 评审结论 🤖+👤
6 按分级标准定内置/官方/开放平台/企业专属，以及是否默认下发 产品总监 评审通过后 1 个工作日内 Skill 台账 分级结论 👤人工判断
7 发布：内置/官方 → 合入 official-skills 并更新镜像里的 Skills commit，走 RND-55；开放平台 → 配置上架和下发范围；付费 → 在测试账号验证扣费后上线 Skill 发布负责人、开放平台负责人、付费 Skill 负责人 随最近一次镜像发布，或分级后 2 个工作日内 Skills 仓库、开放平台、LeapUpdate 已发布版本 🤖+👤
8 在 50 和生产抽检可见、安装、调用；在公告群推送更新通知（版本、变更、更新方式、本地修改是否会被覆盖） Skill 发布负责人 发布后 1 个工作日内 公告群机器人 验证记录、通知 🤖自动化
9 反馈统一进 Skill 反馈表；更新时版本号递增；开放平台不允许降级，回滚以新版本方式发布；下架要通知已安装的企业 Skill 发布负责人、作者 持续 多维表格、开放平台 版本记录、下架记录 🔧飞书固化

5. 交付物与模板

  • 交付物：Skill 包与版本、评审记录、分级结论、Skill 台账、发布与下架通知
  • 建议模板/表单：
    • 「Skill 台账」：名称、slug、display_name、版本、分级（内置/官方/开放平台/企业/用户自建）、适用产品线（LeapCore/LeapAll/行业版）、来源与许可、作者、维护人、是否默认下发、是否付费及单价、review_rank、状态（开发中/评审中/已发布/已下架）
    • Skill PR 模板：分级建议、版本号、变更说明、示例产出、依赖与网络、凭证方式、是否会覆盖用户本地修改
    • 分级标准：内置 = 核心能力，只读、随镜像发布、冷启动按名单强制覆盖；官方 = 公司维护、按部门/标签展示、可选装；开放平台 = slug 唯一、版本递增、按企业/部门下发；企业专属 = 只对指定企业可见
    • 上架检查清单：规范校验、密钥扫描、来源许可、与默认能力冲突检查、命名、示例产出、计费验证

6. 异常与升级

  • 未经审核的 Skill 已推给客户 → 当天下架，排查同一来源的其他 Skill，补审核记录，升级研发负责人
  • slug 重名或与内置能力冲突 → 不予上架，作者改名后重新提交
  • Skill 中发现明文密钥 → 拒绝合并，按 X-SEC-11 轮换密钥（当天）
  • 下发错误导致客户被扣费 → 立即停止下发，付费 Skill 负责人与客服核对退还，当天升级研发负责人
  • 用户误删内置 Skill → 冷启动按名单自动恢复；恢复失败的转 RND-54
  • 第三方/外部合作方 Skill 没有协议、版权不明 → 暂不上架，转法务和生态负责人
  • 行业 Skill 质量有争议 → 质量评估人组织业务人员真人试用评分，产品总监拍板
  • 升级条件：未经审核的 Skill 已推给客户、Skill 中发现明文密钥或造成客户误扣费，或分级结论与安全底线冲突 → 升级研发部门负责人拍板（A（升级））；其余分级与下发决定由产品总监拍板（A）

7. 衡量指标

  • 上架前校验通过率 = 发布版本中通过规范、密钥、许可校验的比例，目标 100%
  • 评审周期 = PR 提交到分级结论的工作日，目标 ≤ 3 个工作日
  • 发布后问题率 = 发布 30 天内被下架或回滚的 Skill 数 / 发布数，目标 ≤ 5%
  • 内置名单一致率 = 镜像实际内置 Skill 与台账一致的比例，目标 100%
  • Skill 反馈闭环时长 = 反馈登记到修复发布的中位数，目标 ≤ 10 个工作日

8. 低效诊断

  • 现象：Skill 以 zip 文件在群里反复发，没有版本号和变更说明，同名冲突要恢复初始状态（版本与发布渠道缺失）｜依据：「Leap产研测」2026-05
  • 现象：领取和安装要不要分开、按下载还是按调用收费说法不一，归属人临时指定（产品规则与归属不清）｜依据：「Leap产研测」2026-05
  • 现象：员工自制 Skill 没有上架权限；外部能力接入没有标准合作文档，也没有分账方案（提交入口与合作规范缺失）｜依据：「跃迁AI总动员」2026-05
  • 现象：内置 Skill 有几个、谁加的说不清，旧 Skill 与新 Agent 冲突，"覆盖还是增量"没有统一（内置名单与更新规则缺失）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：新增 Skill 要先推主分支再处理到 official-skills 分支，分类与标签规则混乱（发布步骤冗余）｜依据：「研发通知」2026-07
  • 现象：内置和官方的定义一天内反复改；直接装外部 Skill 的版权问题没人回答（分级与版权评审缺失）｜依据：「Leap产研测」2026-07
  • 现象：一次校验发现 93 个 Skill 全部未达准入条件，凭证存放方式各不相同（准入评审滞后）｜依据：「【模态】开放生态」2026-07、「【模态】开放生态」2026-08
  • 现象：外部抓取的 PPT Skill 未审核就推给客户，抢了默认 PPT 能力，事后追问谁审核的（上架审核环节缺失）｜依据：「Leap产研测」2026-08
  • 现象：官方套件每次更新都靠群里手工发包、发日志、通知卸载重装，改名没有公告（更新通知环节缺失）｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 现象：开放平台下发某数据类 Skill 的逻辑要到处问，默认下发又被要求下架（下发规则未成文）｜依据：「Leap产研测」2026-10
  • 现象：升级后 Skill 丢失或冲突，共享和保护机制缺失（升级兼容与资产保护缺失）｜依据：「Leap反馈群」2026-07
  • 现象：技能广场缺少常用 Skill，产出效果差缺模板，有人把密钥写进 SKILL（质量与安全检查缺失）｜依据：「LeapAll」2026-04

9. 分支变体

  • 内置（builtins）：只读挂载、随 Agent 镜像发布、冷启动按名单覆盖，不在名单且不是用户创建的会被删除；只能下发更新，用户不能改
  • 官方（official-skills）：按部门目录/标签展示，由 CI 生成清单，随镜像打包
  • 开放平台：slug 是名称的唯一来源；版本只能递增，回滚以新版本发布；更新前提示"本地修改将被覆盖"
  • 企业专属/共享：按公司、部门共享（企业管理员配置层待建）；Skill 属于公司资产
  • 付费 Skill：按调用计费，走 API 网关扣费
  • 产品线：LeapAll 只预置生图和 PPT；LeapCore 预置业务合集；个人版不预置；行业版（工程咨询版）用独立渠道
  • C 端技能广场与 B 端 LeapCore 同步上架时，两边分别验证安装

10. 待确认问题

  • 主责是否仍为魏宗浩？2026-07 已向宋祺睿、杨云峰交接，现在由谁负责？
  • 分级标准由产品总监拍板，还是 Leap 研发技术负责人拍板？内置名单谁维护？
  • review_rank 是否作为上架必填项？行业 Skill 的真人试用由谁组织？
  • 付费 Skill 计费和外部合作方分账规则由谁定？是否需要标准合作协议模板（法务）？
  • 企业管理员配置层（按企业开关 Skill）排期如何？LeapUpdate 是否已不再负责 Skill 下发？
RND-58生产变更管控（备份、灰度、配置、访问审批）待新建240

状态：待新建｜证据：有证据（卡片 11 张 / 会话 6 个）｜优先级：频4 × 耗4 × 跨3 × 险5

  • 适用场景：要对生产环境做任何变更时启动，包括：生产版本部署、DNS/证书切换、网关升级、数据库结构或数据手工改动、镜像手工调整、环境变量与密钥配置、Pulumi/infra 变更、功能灰度名单调整、旧环境维护与环境迁移
  • 负责人：主责——生产变更审批人（当前：王皓南·推断待确认）；协同——生产发布执行人（当前：宋祺睿·推断待确认）、基础设施与网关运维（当前：杨明学·推断待确认）、LeapCore 部署（当前：杨云峰·推断待确认）、LeapAll 服务端（当前：邓乾·推断待确认）、跃竞后端与运维（当前：王子明、席博田·推断待确认）、开放平台（当前：郭逸非、吴亚军·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交生产变更申请（内容、窗口、影响、回滚、验证人）→ ② 按等级评审 → ③ 申请限时访问权限 → ④ 变更前在线备份 → ⑤ 窗口内执行，一人执行一人复核 → ⑥ 灰度并观察 → ⑦ 验证与通知 → ⑧ 关单留痕，或回滚
  • 交付结果：每次生产变更一条审批记录（含备份位置、执行人、复核人、回滚方案、结果）；变更日历；灰度名单配置记录；生产系统一主二备值班表
  • 状态依据：2026-07 已建飞书审批"Leap 生产资源访问申请"，也有 Pulumi/infra 仓库、堡垒机和灰度开关；但变更本身没有申请与评审。2026-01～10 出现过：直接改生产库、生产变量漏推、密钥误写成明文、备份方式和是否停服起争议、切 DNS 遇证书问题临时回滚、测试服与生产服共用数据库、生产部署集中在一人且 key 私下传、负责人不在导致对客户承诺延期

1. 场景判定

  • 触发条件：任何会改变生产环境状态的操作，包括部署、配置、数据、网络/证书、基础设施、灰度范围；旧环境需要小修或迁移切换
  • 典型说法：「我要动生产库了，会有风险吗」「别养成动生产库的习惯了」「新版本已内测通过，会开始灰度，观察到大量失败请联系我回滚」「能帮我部署下生产 hotfix 吗」「为啥备份要关服」「你上次设置 env var 没设置生产的」「你没有被灰度」
  • 判断问题：这个操作会不会改变生产环境的代码、配置、数据或网络？如果会，不管多小都要有变更单（C 级可以只登记）
  • 不归本流程管：登录生产服务器的权限审批与回收 → 请走 X-SEC-18；密钥分发保管 → 请走 X-SEC-10；证书和域名到期续期 → 请走 X-SEC-21；版本发布的整体组织 → 请走 RND-51（其中的部署动作要挂本流程的变更单）；hotfix 准入 → 请走 RND-54；迁移脚本编写与评审 → 请走 RND-34；数据订正 → 请走 RND-80；模型渠道切换 → 请走 RND-71；机房停机维护 → 请走 X-SEC-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
变更审批人 审批 A/B 级变更，确认窗口和风险可接受 A 生产变更审批人（当前：王皓南·推断待确认）
高危变更会签 A 级变更会签，裁定高峰期禁做的事项 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）
变更申请人 填申请，准备脚本、备份与回滚方案 R 各模块研发（当前：待指定）
生产执行人 部署、配置环境变量与密钥、pulumi up R 生产发布执行人（当前：宋祺睿·推断待确认）
复核人 一起看执行过程，核对生产/测试变量和顺序 R 一主二备中的备岗（当前：待指定）
基础设施 网关、DNS、证书、数据库实例与备份 R 基础设施与网关运维（当前：杨明学·推断待确认）
业务线执行 LeapCore/LeapAll/跃竞/开放平台各自的生产变更 R LeapCore 部署（当前：杨云峰·推断待确认）；LeapAll 服务端（当前：邓乾·推断待确认）；跃竞后端与运维（当前：王子明、席博田·推断待确认）；开放平台（当前：郭逸非、吴亚军·推断待确认）
验证人 变更后按清单验证 R 测试负责人（当前：张东郅·推断待确认）
受影响方 接收变更通知 I 产品、交付、客服（当前：待指定）

3. 办之前请准备

  • 变更内容：系统、环境、改什么、执行脚本/命令（IaC 变更附 pulumi preview 输出）
  • 变更等级：A 高危（库表结构/数据、DNS/证书、网关升级、infra、支付链路）；B 常规（版本部署、环境变量、配置）；C 低风险（灰度名单增删、提示词）
  • 执行窗口（避开高峰，A 级一般 22:00 后）和预计耗时、阻塞时长
  • 影响范围：受影响的用户/客户、是否中断、是否涉及计费
  • 备份方案（在线 dump/快照，不停服）和回滚步骤
  • 执行人、复核人、验证人；所需密钥从密钥管理获取，不在群里传

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交"生产变更申请" 变更申请人 A 级至少提前 1 个工作日；B 级提前 2 小时；C 级执行前登记 飞书审批 变更单 🔧飞书固化
2 评审：A 级由审批人和研发负责人会签；B 级审批人单签；C 级只登记，不审批 变更审批人 A 级 4 小时内；B 级 1 小时内 飞书审批 审批结论、变更日历 👤人工判断
3 按 X-SEC-18 申请限时访问权限，通过堡垒机操作 生产执行人 审批通过后 飞书审批、堡垒机 限时权限 🔧飞书固化
4 在线备份：数据库 dump 或卷快照，不停服；记录备份位置，并抽验能否恢复 生产执行人 执行前 备份脚本 备份记录 🤖自动化
5 按脚本执行：IaC 先 preview 再 up；逐项核对生产和测试变量；密钥只写进 secret；多组件按依赖顺序（如先 update 后 cloud） 生产执行人 + 复核人 窗口内 Pulumi、k9s、CI 执行记录 🤖+👤
6 灰度：先灰度名单、开关或小比例；观察告警和日志 30 分钟；灰度名单通过管理页按手机号添加，不改代码不重启 生产执行人 执行后 30 分钟 灰度开关、监控 灰度观察结论 🤖+👤
7 验证人按清单验证（功能、权限、数据、计费、证书）；在研发通知群回帖结果；会影响用户的按 X-PRD-35 通知 验证人 变更后 1 小时内 验证清单 验证结论、通知 👤+🤖
8 异常超过阈值立即回滚；结果、备份位置、实际耗时写回变更单后关闭 生产执行人 当天 飞书审批 关闭的变更单 🔧飞书固化

5. 交付物与模板

  • 交付物：变更单、变更日历、备份记录、执行与验证记录、回滚记录（如有）
  • 建议模板/表单：
    • 飞书审批「生产变更申请」：系统、环境、变更等级、内容、脚本或 PR/tag 链接、执行窗口、预计阻塞时长、影响范围、备份方案、回滚方案、执行人、复核人、验证人、是否需对客通知
    • 变更前检查清单：备份完成、证书/泛域名已就绪、倍率/价格配置已核对、测试与生产数据库已隔离、监控与告警已打开、回滚步骤已演练
    • 一主二备值班表（飞书日历）：每个生产系统（LeapAll 服务端、v5 cloud、LeapCore、NewAPI 网关、开放平台、跃竞后端）1 名主责 + 2 名有权限、有手册的备岗
    • 灰度名单管理页字段：功能、用户手机号/组织、添加人、生效时间、到期时间

6. 异常与升级

  • 变更后出现大面积失败 → 执行人立即回滚（15 分钟内），按 RND-75 报障，升级审批人
  • 执行中发现证书、DNS 未就绪 → 停止切换，按原方案回退，改期重新申请
  • 主责不在、又必须当天发布 → 由备岗按手册执行；没有备岗或缺权限的，升级研发负责人决定是否延期，并通知产品调整对客承诺
  • 未经申请改动生产 → 审批人当天补单并复盘，同类情况计入 RND-12
  • 发现密钥写成明文或私下传递 → 立即撤回，按 X-SEC-11 轮换
  • 旧环境迁移期需要改动 → 迁移负责人公告冻结窗口；只允许经审批的小改动，大改动等切换到新环境
  • 升级条件：A 级高危变更（库表结构/数据、DNS/证书、网关升级、infra、支付链路）须研发部门负责人会签；变更引发生产事故、主责与备岗均无法执行需决定延期，或审批人与申请人对风险判断不一致 → 升级研发部门负责人拍板（A（升级））；B/C 级由变更审批人拍板（A）

7. 衡量指标

  • 变更留痕率 = 有变更单的生产变更 / 全部生产变更，目标 100%
  • 变更失败率 = 需要回滚或引发故障的变更 / 全部变更，目标 ≤ 5%
  • 高峰期高危操作次数，目标 0
  • 关键系统备岗覆盖率 = 有 2 名可执行备岗的生产系统占比，目标 100%
  • 灰度名单变更时长 = 申请到生效，目标 ≤ 30 分钟，免重启

8. 低效诊断

  • 现象：直接在群里说"要动生产库了"就动手，所有人都有生产权限，没有变更申请（变更申请环节缺失）｜依据：「鼎慧产研决策部」2026-01
  • 现象：生产环境变量漏推、密钥写成明文后撤销、Caddy 配置手工同步、需要时翻私聊找密钥（IaC 变更没有检查清单）｜依据：「鼎慧产研决策部」2026-04
  • 现象：灰度靠改环境变量加重启，用户拿不到 userId，反复"再试下"（灰度工具缺失）｜依据：「工程咨询产研」2026-04
  • 现象：核心支付链路灰度上线后靠人看告警和日志，发布与回滚预案没有统一公布（灰度观察与回滚预案缺失）｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-06
  • 现象：网关升级、切 DNS 时证书没签泛域名，临时回滚；倍率没调；测试服与生产服共用数据库；迁移跑全表导致 CPU 吃满（变更前检查缺失）｜依据：「Leap产研测」2026-07
  • 现象：服务端生产更新只有一个人有权限和经验，负责人不在时其他人连注意事项都不知道，导致对客承诺延期（备岗机制缺失）｜依据：「Leap产研测」2026-07
  • 现象：备份数据卷时服务被重启，未申请就使用生产权限，备份是否要停服起争议（备份规范与权限申请缺失）｜依据：「Leap产研测」2026-08
  • 现象：建索引会阻塞写入，要在群里临时讨论风险；证书过期后才发现，域名归属没人知道（高危变更评审缺失）｜依据：「Leap产研测」2026-09
  • 现象：生产部署集中在一人，反复被催"啥时候能更新"；key 配错导致功能失效；部署顺序口头确认（部署申请与顺序依赖没留痕）｜依据：「Leap产研测」2026-09
  • 现象：生产访问审批已经发布，但测试服务器怎么登录仍要在群里问（访问分级缺失）｜依据：「研发通知」2026-07
  • 现象：环境迁出后旧环境没人负责，小改动 SSH 进去手改，大改动因为没有 CI/CD 不敢动（迁移期责任与冻结窗口缺失）｜依据：「【行业版Leapcore】工程版」2026-10

9. 分支变体

  • 102 生产更新前备份：数据库 dump、数据卷、Agent 卷分别备份，全部在线进行，不停服
  • 网关/服务切换：NewAPI 灰度升级、DNS/证书切换，切换前确认证书中心和倍率配置
  • 基础设施：Pulumi/infra 变更区分国内 IDC 和海外云，preview 结果附在变更单里
  • 功能灰度：环境变量白名单过渡到管理页；跃玩支付/订单链路用后台灰度开关和 Redis 开关
  • 独立部署系统：渠道系统、模态空间、v5 cloud、update 各自出变更单，有依赖的写明顺序
  • 环境迁移：开放平台等迁移期公告冻结窗口，旧环境指定临时负责人
  • 测试服访问：比照生产做轻量登记，地址和账号统一登记（X-SEC-09）

10. 待确认问题

  • 变更审批人是否为王皓南？A 级会签是否需要研发负责人？跃竞线的审批人是谁？
  • A/B/C 三级划分和提前量（A 级 1 个工作日、B 级 2 小时）是否可行？
  • 堡垒机是否已覆盖所有生产系统？一主二备名单由谁排？
  • 证书中心、灰度管理页是否立项？由谁负责？
  • 测试服与生产服共用数据库的问题是否已拆分？
RND-59线上部署回滚待新建180

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：新版本上线后关键功能（支付、退款、分账、登录、数据加载）出现异常，且短时间内无法修复，需要先止血（封入口或回滚到上一个已知正常版本），或者回滚后发现版本不对需要纠正时启动
  • 负责人：主责——后端负责人（回滚执行）（当前：王子明·推断待确认）；协同——运维（当前：席博田·推断待确认）、后端研发（核对基线，当前：蒋兴武·推断待确认）、前端负责人（当前：魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、业务负责人（拍板回滚或封禁入口，当前：徐莉·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 按模板报障 → ② 10 分钟内做止血判定（封入口/回滚/直接修）→ ③ 确定回滚目标 commit sha 并二次确认 → ④ 执行回滚（先评估数据库兼容）→ ⑤ 比对基线、回归核心用例 → ⑥ 通知相关方 → ⑦ 修数据、补回遗漏功能后重新上线 → ⑧ 复盘
  • 交付结果：回滚记录（原因、目标 sha、执行人、确认人、时间、影响）；回滚后的回归结论；回滚通知；数据修复和重新上线记录；复盘文档
  • 状态依据：Drone 构建列表可以一键回滚，但没有回滚前确认目标 sha 和影响的步骤。2026-02～09 多次发生资金类线上问题（退款多退、分账数据通宵修复、已付款订单自动退款），回滚都靠群里临时决定；2026-09 还回滚到了错误版本，线上丢失一个提交并产生坏数据

1. 场景判定

  • 触发条件：上线后支付、退款、分账、登录、订单、数据加载等关键链路异常；告警激增；测试版或正式版数据全部加载失败；回滚后发现目标版本不对
  • 典型说法：「线上问题，先回滚？」「先 ban 了，改好再开放」「线上回退错版本了」「master 的哪个提交？来个 commit sha」「速速，坏数据多了就不好处理了」
  • 判断问题：问题是不是这次上线引入的？15 分钟内能不能安全修复？问题是否涉及资金或会持续产生坏数据？涉及的话，优先封入口或回滚
  • 不归本流程管：故障整体响应、对客口径与复盘组织 → 请走 RND-75；hotfix 修复发布 → 请走 RND-54；坏数据订正与退款 → 请走 RND-80；客户端版本退回 → 请走 RND-53；生产变更自身的回滚步骤 → 见 RND-58

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
回滚负责人 判定止血方式，确定回滚目标，组织执行 A/R 后端负责人（回滚执行）（当前：王子明·推断待确认）
发现人 按报障模板报告异常 R 产品/测试/运营（按实际）
业务拍板 涉及资金或需封禁业务入口时，决定是否回滚、是否封禁入口，承担业务影响 A（升级） 业务负责人（当前：徐莉·推断待确认）
运维执行 在 Drone 选定构建执行回滚，二次确认 sha R 运维（当前：席博田·推断待确认）
基线核对 核对目标 sha 与上一个正确基线，检查是否丢提交 R 后端研发（当前：蒋兴武·推断待确认）
前端回退 前端/小程序回退版本 R 前端负责人（当前：魏小东·推断待确认）
测试 复现问题，回滚后回归核心链路 R 测试负责人（当前：赵伟龙·推断待确认）
财务/客服 涉及资金时核对账务、对客说明 C/I 财务、客服对接人（当前：待指定）
兜底 重大事故升级、紧急会议 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 报障信息：端（小程序/网页/会员端/管理端）、现象、订单号或用户 ID、截图、开始时间
  • 本次上线的版本、commit sha、上线时间
  • 上一个确认正常的版本 sha（以上线记录为准，不靠口述）
  • 本次上线是否包含数据库迁移或新枚举（决定能否直接回滚代码）
  • 可封禁的功能入口或灰度开关
  • 已产生异常数据的范围

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现人在项目群按报障模板报告，@后端负责人 发现人（产品/测试/运营） 发现后 5 分钟内 飞书群 报障消息 🔧飞书固化
2 止血判定：资金类先封入口或关开关；判断是回滚还是直接修；不能马上决定的拉飞书会议 回滚负责人 + 业务负责人 报障后 10 分钟内 飞书会议、灰度开关 止血决定 👤人工判断
3 从上线记录取上一个正确版本的 sha，由基线核对人确认没有遗漏提交；数据库有变更的，评估回滚后能否兼容 回滚负责人、基线核对人 判定后 10 分钟内 Gitea、上线记录 回滚目标 sha 👤+🤖
4 执行回滚：在 Drone 选定构建，执行前在群里二次确认"回滚到 sha xxx"；前端同步回退 运维执行、前端回退 确认后 10 分钟内 Drone CI 回滚完成 🤖+👤
5 机器人比对线上 sha 与目标 sha；测试回归核心链路（支付、退款、登录、订单） 测试 回滚后 30 分钟内 Drone、测试用例 回归结论 🤖+👤
6 在项目群通知回滚结果、影响范围和后续安排；涉及客户的转客服 回滚负责人 回滚完成后 15 分钟内 飞书群 回滚通知 🔧飞书固化
7 修复缺陷，订正坏数据（RND-80）；把回滚时被带掉的功能重新上线 后端研发 1 个工作日内 Gitea、Drone 修复与重新上线记录 👤人工判断
8 资金类或回滚出错的，48 小时内按模板复盘，并关联工单 回滚负责人 48 小时内 飞书文档 复盘文档 🔧+🤖

5. 交付物与模板

  • 交付物：报障消息、回滚记录、回归结论、回滚通知、数据订正记录、复盘文档
  • 建议模板/表单：
    • 报障模板：端、现象、订单号/用户 ID、截图、开始时间、影响人数、是否涉及资金
    • 回滚记录（飞书审批或机器人表单）：原因、当前 sha、目标 sha、是否含数据库变更、执行人、确认人、执行时间、回归结论、丢失功能清单
    • 故障分级：资金类（立即封入口或回滚）、核心功能类（30 分钟内止血）、展示类（下个版本修）
    • 复盘模板：时间线、根因、影响（订单数、坏数据量）、止血动作、改进项（负责人 + 截止日）

6. 异常与升级

  • 回滚到错误版本 → 立即停止，重新核对 sha 后再回滚；同时排查期间产生的坏数据，转 RND-80
  • 回滚后数据库与代码不兼容（枚举、字段缺失）→ 暂停回滚，改为修复上线或配合数据处理，升级研发负责人
  • 有回滚权限的人不在 → 由备岗执行（运维与后端互为备份）；10 分钟内找不到人，升级研发负责人
  • 资金异常持续扩大 → 先封入口；涉及退款或分账的，当天通知财务核对
  • 节假日上线出问题 → 按值班表联系；不能处理的拉研发负责人开紧急会议
  • 升级条件：一般回滚由回滚负责人拍板（A）；涉及资金链路或需封禁业务入口 → 由业务负责人拍板（A（升级））；回滚后数据库与代码不兼容、10 分钟内找不到有权限的人，或资金异常持续扩大 → 升级研发部门负责人拍板（A（升级））

7. 衡量指标

  • 止血时长 = 报障到封入口或回滚完成的时间，资金类目标 ≤ 20 分钟，其他关键功能 ≤ 30 分钟
  • 回滚正确率 = 一次回滚到正确版本的次数 / 回滚次数，目标 100%
  • 资金类事故复盘完成率 = 48 小时内完成复盘的资金类事故占比，目标 100%
  • 回滚后功能补回时长 = 回滚到遗漏功能重新上线的时间，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：红包退款多退，临时封禁入口；订单退款和充值退款没有区分，责任界定不清（资金类故障分级与封禁机制缺失）｜依据：「跃玩项目组」2026-02
  • 现象：分账数据异常通宵修复，提现先开放再逐个核对（止血与数据核对规范缺失）｜依据：「跃玩项目组」2026-03
  • 现象：订单创建联调未完成就上线，微信支付后订单状态不变并自动退款，临时决定先回滚（上线门禁与回滚决策缺失）｜依据：「跃玩项目组」2026-06
  • 现象：测试环境数据加载失败，临时回滚（回滚前确认缺失）｜依据：「跃玩项目组」2026-08
  • 现象：线上回滚到错误版本，丢了一个提交，产生坏数据；回滚目标靠口述，事后才要 commit sha；谁有权限回滚不清楚（目标版本二次确认缺失）｜依据：「跃玩项目组」2026-09

9. 分支变体

  • 跃玩小程序/管理端：在 Drone 构建列表选上一个 master 构建执行 restart/回滚；小程序前端回退版本
  • 资金类 vs 展示类：资金类立即封入口或回滚；展示类记录下来，下个版本修
  • 前后端组合：前端先回退，后端推 fix 或一起回滚
  • 测试环境回滚：不需要业务拍板，但同样要确认 sha
  • Leap 系列：客户端退回通过 LeapUpdate 退回上一个稳定版本（RND-53）；服务端和镜像退回上一个 stable tag（RND-55）；hotfix 引入的问题按 RND-54 处理
  • 带数据库迁移的版本：不能只回滚代码，要先评估数据兼容

10. 待确认问题

  • 回滚负责人是王子明还是席博田？回滚权限是否只给这两人，是否需要备岗？
  • 业务负责人（徐莉）不在时，谁能拍板回滚？
  • Drone 回滚能否加"输入目标 sha 二次确认"？
  • 本 SOP 是否推广到 Leap 系列，统一回滚记录格式？
  • 资金类止血 20 分钟的目标是否可行？节假日值班表由谁维护？
RND-60小程序/App 商店提审与上架待新建240

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：小程序（星域、PeRo/猩球、弈荟等）新版本验收通过、需要提交微信审核并发布，或遇到审核驳回、类目缺失、主体变更、保证金和年审；LeapCore 移动端要上架 iOS App Store（含国区 App 备案）时启动
  • 负责人：主责——小程序/App 提审负责人（当前：魏小东·推断待确认）；协同——会员端提审（当前：郝智豪·推断待确认）、业务负责人（类目、加急、保证金、虚拟支付决策，当前：徐莉·推断待确认）、产品验收（当前：陈雁、段涵·推断待确认）、iOS 上架（当前：岳阳·推断待确认）、备案（当前：杨明学·推断待确认）、总经办用印（当前：田杰·推断待确认）、法务负责人（协议文案合规，当前：李瑶·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 产品验收通过 → ② 提审前合规自查（测试数据、类目、协议、虚拟商品/支付、素材）→ ③ 提审并登记 → ④ 跟踪审核 → ⑤ 驳回处理（查驳回原因库、修改、申诉或加急）→ ⑥ 过审发布并通知 → ⑦ 维护主体/类目/保证金/年审台账
  • 交付结果：过审并发布的小程序/App 版本；提审记录（版本、提交时间、结果、驳回原因与处理）；驳回原因库与应对话术；主体、类目、保证金、年审台账；iOS 上架材料包
  • 状态依据：微信后台和 App Store Connect 都在用，2026-07 后小程序提审形成了"验收 → 提审 → 告知预计更新时间"的习惯；但没有成文的提审清单和驳回原因库。2026-01～09 出现：同一天提审 3 次全被拒、申诉入口关闭只能加急、虚拟支付和用户协议文案多次被打回、保证金提醒反复出现、年审不知道填什么；iOS 上架没有固定负责人，材料清单散在聊天里

1. 场景判定

  • 触发条件：小程序版本验收通过准备提审；审核被驳回；需要增加类目或类目不符；被举报需要整改；小程序主体迁移；保证金、年审提醒；移动端首次上架 iOS 或更新版本
  • 典型说法：「验收一下，准备提审了」「今天提审了 3 次，全都没过」「两次打回都提示我们开通虚拟支付」「小程序很容易因为类目问题过不了审」「ios 要准备很多材料」「这个有人在走流程吗」
  • 判断问题：是否要把版本交给微信或苹果审核才能发布？要的话走本流程；网页端直接上线的走 RND-51
  • 不归本流程管：移动端开发协作与 APK/内测构建 → 请走 RND-65；ICP/App 备案办理 → 请走 LEG-23；主体变更申请函盖章 → 请走 LEG-09；版本更新日志与对客通知 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）；支付能力与收款商户 → 请走 RND-66

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提审负责人 自查、提审、跟踪、处理驳回，维护驳回原因库和素材包 R 小程序/App 提审负责人（当前：魏小东·推断待确认）
会员端提审 PeRo/猩球等会员端的提审 R 会员端提审（当前：郝智豪·推断待确认）
业务决策 类目、加急、保证金、是否开通虚拟支付、对外发布时间 A 业务负责人（当前：徐莉·推断待确认）
产品验收 版本验收；接收过审通知，安排公告 R 产品验收（当前：陈雁、段涵·推断待确认）
iOS 上架 上架材料清单、TestFlight、提交审核 R iOS 上架（当前：岳阳·推断待确认）
备案 国区 App 备案、网站备案信息 R 备案（当前：杨明学·推断待确认）
用印 主体变更申请函等盖章 R 总经办用印（当前：田杰·推断待确认）
法务 用户协议、隐私政策、下单须知文案合规 C 法务负责人（当前：李瑶·推断待确认）
测试 正式服过审后验证 R 跃竞测试负责人（当前：赵伟龙·推断待确认）
兜底 跨主体、跨部门协调 A（升级） 研发部门负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 已验收通过的体验版，以及版本号和更新说明
  • 提审素材包：过审版本保存的演示视频和截图（固定复用）、测试账号
  • 合规自查项：测试服商品和顾客数据已清空；页面和协议里没有敏感词（如"代打"）；涉及虚拟商品的页面已有方案；类目与功能一致
  • 主体信息：主体名称、类目、经营范围、年审所需资料（从台账取）
  • iOS：App 名称、图标、副标题、推广文本、描述、关键词、Support URL、隐私政策 URL、分类，iPhone/iPad 真机截图（各尺寸每个设备至少 3 张，不得出现 Android 元素）；国区还需完成 App 备案

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 开发完成后 @产品验收体验版 提审负责人 开发完成当天 微信体验版 验收结论 👤人工判断
2 按提审清单自查：清测试数据、核对类目、检查协议敏感词和虚拟商品页面、准备素材 提审负责人 验收通过后 2 小时内 提审检查清单 勾选完成的清单 🔧+🤖
3 提交审核，在提审台账登记版本、时间、素材，群里告知预计更新时间 提审负责人 自查完成当天 微信公众平台、多维表格 提审记录 🔧飞书固化
4 跟踪审核状态，状态变化由机器人通知群 提审负责人 每个工作日检查 1 次 多维表格 + 机器人 审核状态 🤖自动化
5 被驳回：查驳回原因库，按应对方案修改（屏蔽或改页面、改协议文案、重新录屏、备注说明业务）后重新提交；涉及开通虚拟支付、加急、改类目的报业务负责人决定 提审负责人、业务负责人 驳回后 1 个工作日内 驳回原因库 修改后重新提审 👤+🤖
6 过审后按约定时间发布，通知产品、后端和测试；测试在正式服验证 提审负责人、测试 过审后按发布计划 微信公众平台 发布记录 👤人工判断
7 新的驳回原因和处理办法写进原因库 提审负责人 处理完 1 个工作日内 多维表格 原因库条目 🔧飞书固化
8 每月检查台账，保证金、年审、主体迁移到期前提醒；主体变更申请函走用印审批 提审负责人、业务负责人 到期前 30 天提醒 多维表格提醒、用印审批 台账、办理记录 🔧飞书固化

5. 交付物与模板

  • 交付物：提审记录、过审发布记录、驳回原因库、主体/类目/保证金/年审台账、iOS 上架材料包
  • 建议模板/表单：
    • 提审检查清单：测试数据已清理、类目一致、协议与须知文案已审、虚拟商品/支付方案、素材包版本、测试账号、预计发布时间
    • 提审台账（多维表格）：小程序/App、主体、版本号、提交时间、审核结果、驳回原因、处理方式、是否加急、过审时间、发布时间
    • 驳回原因库：驳回原因原文、对应页面或文案、处理方案、是否可申诉、话术
    • 主体台账：小程序名称、主体、类目、经营范围、保证金状态、年审到期日、管理员、备案信息
    • iOS 上架材料清单：按 App Store Connect 字段列明内容、尺寸要求与负责人

6. 异常与升级

  • 同一版本被驳回 2 次以上 → 提审负责人当天报业务负责人，决定是否加急、改方案或拆版本
  • 驳回涉及类目或经营范围 → 业务负责人确认用哪个主体（经营范围是否包含对应类目），需要变更主体的走用印审批，在 1 个工作日内启动
  • 被举报或收到整改通知 → 当天先关闭公开搜索或按要求整改（如改名），通知业务负责人
  • 驳回要求开通虚拟支付、平台要求抽成 → 业务负责人评估影响，必要时改走 H5/公众号/App，由研发负责人确认技术方案
  • 保证金或年审逾期 → 当天通知业务负责人与财务处理
  • iOS 审核被拒 → iOS 上架负责人 1 个工作日内修改；涉及隐私政策的找法务
  • 升级条件：类目、加急、保证金、虚拟支付、对外发布时间由业务负责人拍板（A）；涉及跨主体迁移、跨部门资源协调，或需改走 H5/App 等技术路线变更 → 升级研发部门负责人拍板（A（升级））

7. 衡量指标

  • 一次过审率 = 首次提交即通过的版本数 / 提审版本数，目标 ≥ 80%
  • 提审周期 = 提交到过审的自然日，目标 ≤ 2 天
  • 驳回处理时长 = 驳回到重新提交的时间，目标 ≤ 1 个工作日
  • 台账逾期数（保证金、年审、类目）= 0

8. 低效诊断

  • 现象：同一天提审 3 次全部被拒，申诉入口已关闭只能付费加急；同一段视频有时过有时不过（素材包与提审清单缺失）｜依据：「跃玩项目组」2026-02
  • 现象：两个小程序反复提示交保证金，年审时不知道填什么、要翻主体信息（主体台账缺失）｜依据：「跃玩项目组」2026-03
  • 现象：因虚拟支付和用户协议文案多次被打回，每次先猜原因再改，只能临时屏蔽页面、重新录屏（驳回原因库和合规自查缺失）｜依据：「跃玩remote工作组」2026-06、「跃玩remote工作组」2026-07
  • 现象：充值须知一直被打回；提审前清理测试数据靠口头提醒；支付能力受限只能考虑改走 H5 或 App（提审前自查缺失）｜依据：「跃玩项目组」2026-07、「跃玩项目组」2026-09
  • 现象：iOS 上架没人记得之前谁走过流程，负责人和实际干活的人不是同一方；材料清单散在聊天里；备案要另找人（上架负责人与材料清单缺失）｜依据：「Leap产研决策部」2026-09

9. 分支变体

  • 多个小程序（星域、PeRo、猩球、弈荟、星域支付）各自审核，通过时间不同，可以先发已过审的那个
  • 类目问题：类目要与主体经营范围一致，某些类目只能放在经营范围包含该项的主体下
  • 被举报：先关闭公开搜索、调整名称等敏感表述，再提审
  • 主体迁移：写申请函并走用印审批，扫描件提交；迁移前确认新主体的微信能力，迁移期间审核与支付平台审查可能并行
  • 会员端需要微信审核，网页端直接上线（不走本流程）
  • iOS：先上 TestFlight（只需最少信息）再准备截图和正式提交；国区要先做 App 备案；Android 商店另行准备；Mac 商店暂不上架

10. 待确认问题

  • 主责是魏小东，还是由各端前端各自负责（星域：魏小东；PeRo/猩球：郝智豪）？
  • 加急费用、保证金的审批口径是什么，由业务负责人直接决定还是走财务审批？
  • 提审前协议文案是否每次都要法务审？还是只在协议变更时审？
  • LeapCore iOS 上架的负责人是谁（外部移动端团队还是内部研发）？国区备案由谁办理？
  • 是否评估把涉及虚拟商品的功能改走 H5/公众号/App？
RND-61客户演示前版本冻结与演示环境准备待新建180

状态：待新建｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：已确定客户/领导/媒体演示、POC 演示或上线评审答辩的时间，需要在演示前冻结研发改动并备好环境、数据、账号、skill 和第三方额度
  • 负责人：主责——产品总监/演示统筹（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、基础设施工程师（当前：葛家和·推断待确认）、测试负责人（当前：张东郅·推断待确认）、演示方（销售/FDE，当前：吴琪、李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 登记演示 → ② 涉密与范围判定 → ③ 定演示人与版本 → ④ 宣布冻结窗口 → ⑤ 备环境/数据/账号/额度 → ⑥ 彩排自检 → ⑦ 演示与现场保障 → ⑧ 解冻与复盘
  • 交付结果：一份已签核的《演示准备单》、一个冻结且可用的演示环境（含数据、账号、skill、额度）、一次彩排记录与演示后复盘
  • 状态依据：已有一份通用演示脚本 wiki，但冻结靠群内喊话、演示前一晚才定版本，2026-03～08 多次出现演示前环境被清库、测试服被挪用、第三方额度过期、功能临时不可用等救火，无演示申请和准备清单

1. 场景判定

  • 触发条件：日历上出现对外演示、POC 演示、展会、媒体拍摄、领导参观或上线评审答辩；或销售/FDE 提出"某天要给客户演示"
  • 典型说法：「下午有两个演示，能稳不」「一会要演示的，别搞」「媒体在会议室等着」「部署真的要有交底说明」
  • 判断问题：演示是否依赖公司内部某个环境（50/51/102/演示站/演示机）？演示期间研发是否可能发版、清库或改配置？是否需要第三方服务额度？
  • 不归本流程管：内部 Demo/原型页面对外发布 → 请走 RND-62；行业版插件下发给企业实例 → 请走 RND-64；新模型/渠道接入 → 请走 RND-67

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
演示统筹 登记演示、定演示人与版本、宣布冻结、签核准备单 A/R 产品总监（当前：杨萌·推断待确认）
演示方 提出需求、提供客户场景、准备话术与讲解、现场演示 R 销售/FDE（当前：吴琪、李凯·推断待确认）
研发技术负责人 确认冻结范围、评估演示功能稳定性、批准例外改动 C/R（冻结例外审批） 研发技术负责人（当前：王皓南·推断待确认）
环境与部署 固定演示环境、开子域名、配置交底、保护数据不被清理 R 运维/发布工程师（当前：宋祺睿·推断待确认）、基础设施工程师（当前：葛家和·推断待确认）
测试 演示前按脚本冒烟，确认数据与账号可用 R 测试负责人（当前：张东郅·推断待确认）
兜底决策 涉密边界、演示取消/改期、跨部门资源与预算 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 演示时间、地点、对象类型（客户/媒体/领导/评委）、时长、是否录屏或直播
  • 演示脚本：要展示的功能清单与顺序（可从通用演示流程 wiki 复制改写）
  • 涉密判定：是否涉及客户项目数据、涉密行业 demo（如水利类智能体），是否允许公开
  • 环境需求：使用哪套环境/演示机、需要的账号角色、需预装的 skill、需开通的功能开关
  • 第三方依赖：文档解析、模型额度、券码、积分，需写明到期日与余额
  • 预算来源：若需临时采购第三方服务额度，写明由哪个部门预算承担

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在"演示日历"登记演示（时间、对象、演示人、环境、功能清单） 演示方 演示前至少 3 个工作日；临时邀约收到后 2 小时内 飞书多维表格/日历 演示登记记录 🔧飞书固化
2 判定涉密与公开范围，确定演示人与回答问题的人 演示统筹 + 兜底决策人 登记后 1 个工作日内 飞书多维表格 涉密结论、演示人名单 👤人工判断
3 确定演示版本（tag/包/下载链接），评估演示功能稳定性 研发技术负责人 演示前 2 个工作日 Gitea、发版记录 演示版本号 👤人工判断
4 机器人在研发群发布冻结窗口：演示前 4 小时至演示结束，演示环境禁止发版、重启、清库、改配置 演示统筹 演示前 1 个工作日 18:00 前 飞书机器人 冻结公告（含环境编号） 🔧+🤖
5 准备演示环境：固定环境不与日常测试共用；开子域名、贴部署交底单（env、构建变量、依赖服务、回滚点）；预装 skill、开功能开关 环境与部署 演示前 2 个工作日 Caddy、飞书 wiki 交底模板 部署交底单 🔧+👤
6 准备演示数据与账号：用造数脚本生成真实感数据，假数据用功能开关标记；演示账号余额、积分、券码到位；账号密码只放在交底单受限文档，不在群发 环境与部署 + 演示方 演示前 1 个工作日 造数客户端/脚本 数据与账号清单 🤖自动化
7 核对第三方服务额度与到期日（文档解析、模型额度等），不足时按预算来源发起采购 演示方 演示前 2 个工作日 飞书审批 额度核对结果 🔧飞书固化
8 按演示脚本彩排一遍，测试同步冒烟；勾完《演示准备单》 演示方 + 测试 演示前 1 个工作日 演示准备单 彩排记录、签核 👤人工判断
9 演示当天：研发值班人在线，出问题按"切备份录屏/备用环境"处理，不现场改库 环境与部署 演示全程 飞书群 现场问题记录 👤人工判断
10 演示结束后解冻并在登记表补复盘（问题、客户反馈、改进项） 演示统筹 演示后 1 个工作日内 飞书多维表格 复盘记录 🔧飞书固化

5. 交付物与模板

  • 交付物：演示登记记录、冻结公告、部署交底单、数据与账号清单、彩排记录、复盘记录
  • 建议模板/表单：
    • 演示登记表字段：演示 ID、日期时间、对象类型、客户代号、演示人、演示统筹、环境编号、演示版本、功能清单、涉密结论、第三方依赖及到期日、预算来源、状态（待准备/已冻结/已演示/已复盘）
    • 部署交底单字段：环境编号与用途、访问域名、部署人、代码分支/commit、.env 与构建变量清单、依赖服务（Redis/PG/文档转换等）、功能开关、账号位置（受限链接）、回滚点、负责人与备份人

6. 异常与升级

  • 演示前发现核心功能不可用 → 研发技术负责人评估 2 小时内能否修复，不能修复则切备份录屏或缩减演示范围 → 升级创始人兼 CTO（当场）
  • 冻结期间必须改动（修演示阻塞 bug）→ 研发技术负责人书面批准后只改演示环境 → 通知演示统筹（改动前）
  • 演示环境被他人占用、清库或停机 → 立即恢复快照或切备用环境 → 升级运维负责人（30 分钟内）
  • 第三方额度过期且无预算归属 → 演示方提出、兜底决策人指定预算部门 → 1 个工作日内完成采购
  • 涉密边界不清 → 一律按"不公开"处理 → 创始人兼 CTO 拍板（演示前 1 个工作日）
  • 升级条件（A（升级））：涉密边界不清、演示取消/改期、跨部门资源或预算争议，或演示统筹与研发技术负责人意见不一致且 2 小时内未决 → 升级创始人兼 CTO 拍板；其余事项由演示统筹（A）决定

7. 衡量指标

  • 演示登记率 = 登记的演示数 ÷ 实际演示数，目标 100%
  • 提前准备率 = 演示前 ≥ 1 个工作日完成彩排的演示占比，目标 ≥ 90%
  • 演示事故率 = 演示中出现功能不可用/数据异常的演示占比，目标 ≤ 5%
  • 冻结违规次数 = 冻结窗口内对演示环境的未批准改动次数，目标 0

8. 低效诊断

  • 现象：冻结靠演示当天群内口头喊话，没有固定冻结窗口，研发不知道哪套环境在演示｜依据：「Leap产研测」2026-08、「跃迁AI总动员」2026-06
  • 现象：演示环境与日常测试共用，演示前环境被清库、测试服被挪作他用，演示前才发现对话异常｜依据：「Leap产研测」2026-07、「3.3墨跃思政演示项目」2026-02
  • 现象：部署人与开发人不同，配置靠群里贴文本，缺部署交底单，出现 404 和配置注入不确定｜依据：「3.3墨跃思政演示项目」2026-03
  • 现象：演示版本到前一晚才定，答辩/演示人临时分配｜依据：「LeapAll」2026-04
  • 现象：涉密边界靠口头确认，演示站账密在群里发送｜依据：「AI API」2026-05
  • 现象：演示机 skill 靠手工预装，环境与权限无台账，"谁有某数据库权限"要在群里问｜依据：「【行业版Leapcore】工程版」2026-07、「【行业版Leapcore】工程版」2026-08

9. 分支变体

  • 媒体/对外公开演示：必须先过涉密判定，使用专用演示版本并替换主题名称，准备记者问答口径
  • 客户 POC 演示站（如思政版、军校版）：单独拉分支和子域名，部署交底单必填；红色主题/提示词替换需列入功能开关
  • 上线评审答辩：需提前录制不超过 3 分钟的讲解视频，指定答辩人
  • 领导/老板现场演示：开发与测试需提前加免责声明并提醒避免触发重启等风险操作
  • 行业版演示机：提前装 skill 或安装压缩包，演示后回收账号

10. 待确认问题

  • 演示统筹的主责是否固定为产品总监，还是按产品线（LeapCore/LeapAll/鼎慧）分别指定？
  • 冻结窗口"演示前 4 小时至演示结束"是否可行？是否需要对重大演示提前到前一天 18:00？
  • 是否建立一套长期保留的专用演示环境，与 50/51 等测试机分离？由谁维护？
  • 第三方服务额度的演示预算默认归市场还是研发？
  • 现有通用演示流程 wiki 中的账号凭据是否需要移到受限文档？
RND-62内部 Demo/原型/静态页面部署待新建54

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨3 × 险3

  • 适用场景：员工（含非研发）用 AI 做出 Demo、原型或 HTML 页面，需要给同事、领导、外部用户或客户访问
  • 负责人：主责——运维/发布工程师（当前：宋祺睿·推断待确认）；协同——IT 运维/网管（域名、服务器，当前：杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、申请人；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 提交部署申请 → ② 判定访问范围与类型 → ③ 分配位置/端口/子域名 → ④ 仓库归入组织 → ⑤ 部署并安全检查 → ⑥ 发布预览链接 → ⑦ 登记 Demo 台账 → ⑧ 到期回收
  • 交付结果：可访问的预览链接（已备案域名、HTTPS），Demo 台账中的一条登记记录（含负责人、访问范围、到期日）
  • 状态依据：目前靠把 HTML 发给技术负责人手工上传静态网关；原型部署方案三天内换了三次；端口在群里口头申请且代码放个人仓库，无成文部署规范和 Demo 台账

1. 场景判定

  • 触发条件：已有可运行的页面/原型/Demo，需要一个稳定、国内可访问的链接；或 Demo 需要开放服务器端口
  • 典型说法：「单 html 直接给我就行了」「能不能整点稳定的部署服务」「需要开一下 3001 和 8080 端口」
  • 判断问题：这是一次性展示用的 Demo/原型，还是要长期给客户用的正式产品？是否含真实客户数据？只给内部看还是对外？
  • 不归本流程管：正式产品发版和生产部署 → 请走 RND-51（正式版本发布上线）；为客户演示准备环境 → 请走 RND-61；新增正式服务器/云资源 → 请走 X-SEC-16（云服务器与云资源申请开通）；需采购硬件 → 请走 ADM-24（IT设备与研发硬件采购申请）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提交页面/代码、说明用途与访问范围、到期后确认回收 R 申请人（各部门）
部署执行 选择部署方式、分配子域名/端口、部署、配置 HTTPS 与访问控制 A/R 运维/发布工程师（当前：宋祺睿·推断待确认）
域名与服务器 提供已备案域名、服务器资源、端口开放 R IT 运维/网管（当前：杨明学·推断待确认）
技术审核 对需开端口、带后端或数据库的 Demo 做安全审核 C 研发技术负责人（当前：王皓南·推断待确认）
兜底 部署方案取舍、对外开放的最终批准 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 产物形态：单 HTML / 多文件静态包 / 带后端服务（写明运行命令，如 bun 启动、sqlite 库）
  • 用途和访问范围：仅内部 / 指定外部人员 / 公开；预计使用期限
  • 是否含数据：是否有真实客户数据、是否需要登录、是否需要外部 API key（key 不得写进前端）
  • 代码位置：Gitea 组织仓库地址（不得放个人账号）
  • 期望子域名后缀（前缀由已备案域名决定）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写 Demo 部署申请（产物形态、用途、访问范围、期限、仓库） 申请人 需上线前 1 个工作日 飞书表单/机器人 申请记录 🔧飞书固化
2 判定类型：静态页走自助托管；带后端走"服务器 + Caddy 反代 + 已备案域名"；对外公开或开端口需技术审核 部署执行 申请后 4 个工作小时内 飞书表单 部署方案 👤人工判断
3 静态页：通过机器人或托管入口上传即发布，自动生成子域名 申请人 即时 静态托管/飞书机器人 预览链接 🤖自动化
4 带后端：代码迁入 Gitea 组织仓库，按"原型部署模板"（Caddy 配置、部署脚本）部署 部署执行 审核通过后 1 个工作日内 Gitea、Caddy、部署脚本 运行中的服务 🤖+👤
5 需开端口：只开必要端口，数据库端口不对公网开放，设强密码/访问控制 域名与服务器 与第 4 步同步 云控制台 端口开放记录 👤人工判断
6 自检：国内网络可访问、HTTPS 正常、无 401/404、无密钥暴露 部署执行 部署后 1 小时内 浏览器/脚本 自检结果 🤖自动化
7 把链接发给申请人，并登记 Demo 台账 部署执行 自检通过后即时 飞书多维表格 台账记录 🔧飞书固化
8 到期前 3 天机器人提醒申请人续期或下线，过期未续则下线并回收端口/子域名 部署执行 到期日 飞书机器人 回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：预览链接、部署记录、Demo 台账条目
  • 建议模板/表单：
    • Demo 部署申请字段：申请人、部门、Demo 名称、产物形态、用途（内部测试/客户演示/C 端内测）、访问范围、期望子域名、仓库地址、是否含数据/密钥、期限
    • Demo 台账字段：Demo 名称、负责人、子域名/链接、部署方式、服务器与端口、仓库、上线日期、到期日、状态（在线/已下线）
    • 原型部署模板：Caddy 反代片段、启动脚本、环境变量清单、回滚方式

6. 异常与升级

  • 链接国内打不开或不稳定（如海外托管平台）→ 改用自建服务器 + 已备案域名 → 部署执行当天处理
  • 需要新域名或备案 → 转 IT 运维/网管评估备案周期 → 超过 3 个工作日升级创始人兼 CTO
  • 发现代码在个人仓库或数据库端口对公网暴露 → 先关闭端口、迁仓库，再上线 → 升级研发技术负责人（当天）
  • 部署负责人无空导致对外开放搁置 → 2 个工作日内未处理自动转兜底人指派
  • 升级条件（A（升级））：Demo 需对外公开、对公网开放端口或含真实客户数据，或部署方案在部署执行与技术审核之间有分歧 → 报创始人兼 CTO 批准后再上线；仅内部访问的静态页由部署执行（A）决定

7. 衡量指标

  • Demo 部署时长 = 申请提交到链接可用的工作小时数，静态页目标 ≤ 1 小时，带后端目标 ≤ 1 个工作日
  • 台账覆盖率 = 已登记 Demo ÷ 在线 Demo，目标 100%
  • 安全违规数 = 个人仓库/数据库端口暴露/密钥泄露次数，目标 0

8. 低效诊断

  • 现象：非研发员工自行部署的页面国内无法访问，只能发文件给技术负责人手工上传，形成单点｜依据：「鼎慧产研决策部」2026-04
  • 现象：原型部署方案反复切换（海外静态托管 → 自建 → 换域名），每次临时讨论｜依据：「跃迁基座许愿机」2026-05
  • 现象：对外开放能力等待负责人排期而搁置｜依据：「跃迁基座许愿机」2026-05
  • 现象：端口开放在群里口头申请，代码先放个人账号再要求迁移，数据库端口有暴露｜依据：「某集团智库项目群」2026-02
  • 现象：没有 Demo 库，Demo 每次从头做且"谁都能做但没人做"｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 单 HTML/纯静态：自助托管，上传即发布
  • 带后端原型（如许愿机原型）：服务器 + Caddy + 已备案域名，bun 直接运行，sqlite 做库
  • 面向 C 端内测：必须稳定域名与 HTTPS，需技术审核
  • 内部能力培训用 Demo：可不对外，仅内网/飞连访问

10. 待确认问题

  • 主责是否为运维/发布工程师？是否需要一名非研发也能用的自助托管入口负责人？
  • 静态托管"上传即发布"的机器人/skill 是否已有雏形，由谁维护？
  • Demo 默认有效期定多久（如 30 天）？
  • 对外公开的 Demo 是否需要法务或品牌审核？
  • 公司 Demo 统一管理由产品还是研发牵头？
RND-63信创适配开发、打包与验收待优化256

状态：待优化｜证据：有证据（卡片 11 张 / 会话 3 个）｜优先级：频4 × 耗4 × 跨4 × 险4

  • 适用场景：市场/销售/客户提出新的"芯片 × 操作系统"适配需求，或主线出新版本需要出信创包、测试、修复并对外同步适配状态
  • 负责人：主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——产品总监/项目统筹（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、客户端研发（当前：岳阳·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、IT 运维（构建机/测试机，当前：杨明学、游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 需求登记 → ② 周评审定优先级 → ③ 借机/备环境 → ④ 流水线构建出包 → ⑤ 矩阵测试出报告 → ⑥ 缺陷提单分诊 → ⑦ PR 合入与 hotfix 回移 → ⑧ 按口径更新适配表并对外同步
  • 交付结果：可下载的信创安装包（含 commit 与 jobset 标识）、测试报告（通过/有条件通过/不通过）、适配多维表格中更新的状态、对外口径说明
  • 状态依据：已有 Nix + Hydra 流水线、适配多维表格、信创上下文 wiki 和测试报告模板，但优先级多次反复，进度同步靠人催，打包与测试均为单人，缺陷信息靠口头纠正

1. 场景判定

  • 触发条件：客户或项目要求某芯片（海光、飞腾、龙芯、兆芯等）× 系统（麒麟、UOS、Debian）可用；主线打新 tag/hotfix；有人问"某机型适配了吗"
  • 典型说法：「先解决有无，更新频率第二优先级」「今天是不是出包了」「报 bug 要把测试环境报了」「没有 P0 和 P1 就叫能跑」
  • 判断问题：需求是客户端还是服务端？是否已在适配表中？是否有可用测试机？是否属于 Linux 通行问题而非信创特有？
  • 不归本流程管：客户现场部署与装机 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；信创产品认证（如统信认证）与厂商联合适配协同 → 请走 X-DLV-25（信创/国产算力适配与厂商协同）；一般客户端 bug（非 Linux/信创） → 请走 RND-03（缺陷提报、复现、分级与指派）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
适配负责人 评估工作量、维护流水线与打包、交测、修平台问题、每日同步 A/R 信创&Linux 适配负责人（当前：李子遥·推断待确认）
项目统筹 收集需求、组织周评审、汇总对外口径 R 产品总监（当前：杨萌·推断待确认）
优先级决策 按市场占比与客户项目定优先级 R（定优先级） 市场销售负责人（当前：李鹏为·推断待确认）
测试 排期、矩阵测试、出报告、判 P0～P3 R 测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）
客户端研发 分诊业务类 bug、PR 评审与合并、回移 hotfix R 客户端研发（当前：岳阳·推断待确认）
基础设施 测试机借用、构建机磁盘与网络 R IT 运维（当前：杨明学、游家豪·推断待确认）
兜底 任命负责人、资源与人力调配 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
需求方 提交适配需求（芯片、OS、端、客户、数量、期限） R 销售/市场（当前：按需求提出人）

3. 办之前请准备

  • 需求方：芯片、操作系统及版本（如 UOS v20/v25）、客户端/服务端、客户场景、数量、期限
  • 测试机：是否已有实机或虚拟机；需借用时写明经销商、周期、费用由谁审批
  • 版本：要适配的基线（main 或 hotfix 分支/tag）
  • 资料：信创上下文 wiki、打包培训录屏、测试报告模板
  • 新成员入专项群时先读 wiki 与培训回放

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用统一表单提交适配需求（芯片+OS+端+客户+数量+期限） 需求方（销售/市场） 需求出现后 1 个工作日内 飞书表单 → 适配多维表格 需求记录 🔧飞书固化
2 每周固定评审：适配负责人给工作量，市场侧按市占率与项目价值定优先级，结论写入表格 项目统筹 + 优先级决策 每周一次，会后当天写表 适配多维表格 优先级列表 👤人工判断
3 借测试机/准备虚拟机并登记借用（机型、来源、期限、费用） 基础设施 优先级确定后 3 个工作日内 测试机借用登记表 可用测试环境 🔧飞书固化
4 流水线构建：rolling 跟 main，release/hotfix jobset 跟发布分支；出包后机器人把 eval/build 链接和 commit 写入适配表并 @ 测试 适配负责人 tag 后 1 个工作日内 Hydra、Gitea LeapNix 安装包与链接 🤖自动化
5 按矩阵测试（复用非信创测试 SOP 用例 + UI 自动化回归），结论分"通过/有条件通过（列必修项）/不通过" 测试 收到可测包后 3 个工作日内 测试报告模板、适配表 测试报告 🤖+👤
6 提缺陷单：必填芯片、OS、包链接、终端日志、与 Debian/Windows/mac 对比；标"信创适配"标签 测试 发现后当天 工单系统 缺陷单 🔧飞书固化
7 分诊：先在 Debian 复测，Linux 通行问题与客户端业务问题转客户端研发，信创特有问题归适配负责人 适配负责人 + 客户端研发 提单后 1 个工作日内 工单系统 分派结果 👤人工判断
8 修复以 PR 合入主线，研发评审；需进发布的修复回移到 hotfix 分支 适配负责人 + 客户端研发 PR 提交后 2 个工作日内完成评审 Gitea PR 合入记录 👤人工判断
9 每日 18:30 前在适配表更新"今日进度/卡点/明日计划"，机器人汇总播报 适配负责人 每个工作日 适配表 + 群机器人 日报 🔧+🤖
10 按口径更新状态：无 P0/P1 即"已适配"，未实机测的标"推测已适配"；项目统筹改写对外口径后由测试核对 项目统筹 + 测试 测试结论出后 1 个工作日内 适配表、话术模板 对外口径 👤人工判断

5. 交付物与模板

  • 交付物：信创安装包（按架构通用命名，如 amd64/arm64）、测试报告、缺陷单、适配表状态、对外口径
  • 建议模板/表单：
    • 适配需求表单：需求人、客户代号、芯片、OS 及版本、客户端/服务端、数量、期限、优先级、状态
    • 适配表状态字段：组合（芯片×OS）、当前包版本与链接、测试结论、P0/P1 数、状态（自动计算：已适配/推测已适配/未适配/暂缓）、更新时间
    • 缺陷单必填：芯片、OS、包链接（Hydra eval）、复现步骤、终端日志、对比环境结果、附件
    • 测试报告模板：基本信息、软硬件环境、用例与结果、结论、必修项

6. 异常与升级

  • 构建机磁盘满/网络故障阻塞出包 → 基础设施 4 小时内处理 → 超过 1 个工作日升级兜底人
  • 测试人力不足导致排期超过 3 个工作日 → 测试负责人提出加人或启用 UI 自动化 → 升级创始人兼 CTO
  • 测试用错包（rolling 或旧包）→ 结论作废，按适配表指定包重测 → 适配负责人当天说明
  • 优先级在评审外被临时改动 → 记录到表格并在下次周评审复核 → 升级市场销售负责人
  • 系统本身缺陷（如麒麟外链问题）→ 记录并转厂商 → 适配负责人跟进
  • 升级条件（A（升级））：需任命或更换负责人、跨团队人力/测试机资源调配、周评审中市场侧优先级与研发工作量评估冲突 1 周内未达成一致 → 升级创始人兼 CTO 拍板；日常适配交付由适配负责人（A）负责

7. 衡量指标

  • 出包时效 = tag 到可测包可下载的小时数，目标 ≤ 24 小时
  • 测试周期 = 收到可测包到出报告的工作日，目标 ≤ 3 天
  • 缺陷单信息完整率 = 首次提交即含全部必填项的单数 ÷ 总单数，目标 ≥ 90%
  • 进度催办次数 = 群内追问进度的次数/周，目标 ≤ 1
  • "已适配"误报数 = 对外宣称已适配后被客户发现不可用的次数，目标 0

8. 低效诊断

  • 现象：同一芯片优先级几度反复（不做→要做→不急→暂缓），客户场景到后期才暴露，缺固定需求入口和评审节奏｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-08、「信创LeapCore客户端适配」2026-10
  • 现象：进度同步靠管理方在群里追问，节奏不稳，后改为多维表格仍需提醒｜依据：「信创LeapCore客户端适配」2026-07
  • 现象：打包流水线和信创测试各依赖单人，构建机磁盘满阻塞约两周｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-08、「信创LeapCore客户端适配」2026-09
  • 现象：缺陷单多次被要求补环境与包版本，bug 提给错误的人｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-09
  • 现象："能跑/已适配"口径到项目中期才定，销售反复询问"有没有某某包"｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-08
  • 现象：培训回放和 wiki 缺入口，新成员很晚才知道专项群，重复提问｜依据：「信创LeapCore客户端适配」2026-08、「信创LeapCore客户端适配」2026-09
  • 现象：国产慢速算力环境下超时问题现场才暴露，逐层排查多轮，缺慢速 API 测试基线｜依据：「跃迁基座项目交付沟通」2026-02

9. 分支变体

  • 芯片×系统：x86（海光/兆芯）与 arm（飞腾）× 麒麟/UOS/Debian；龙芯、RISC-V 需重编 Electron/Chromium，不适用表单口径，单独评估
  • 打包形态：AppImage（当前主路径）；deb（上架应用商店用，待定）；LeapVPN 另立 static 构建
  • 客户端 vs 服务端：当前以客户端为主，服务端是否适配需在周评审中明确，避免市场与研发认知不一致
  • 慢速国产算力环境：研发需用限速模型 API（如 3～4 token/s）自测，超时统一由环境变量控制；给客户的版本不得接限速 API
  • 展会/展示用机：只做演示部署，不计入适配结论

10. 待确认问题

  • 主责是否为信创&Linux 适配负责人？测试侧是否需要指定备岗主测？
  • 优先级决策人是市场销售负责人还是创始人兼 CTO？周评审放在哪个固定时间？
  • "无 P0/P1 即已适配"的口径是否作为正式对外标准？
  • 测试机借用及费用审批是否统一走 ADM-30（信创测试机申请与厂商借机/归还）？
  • 慢速 API 测试环境是否固化为常驻服务，由谁维护？
RND-64行业版插件开发、接入规范与交付待优化400

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：工程/投资/法律/招投标等行业功能以插件或 skill 接入 LeapCore，需要按规范开发、测试验收、确定版本号并下发到指定企业实例；子公司或外部团队要接入 Leap 平台
  • 负责人：主责——行业版负责人/产品总监（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、插件研发（当前：侯怡辰、陈锦杰·推断待确认）、FDE/skill 下发（当前：邓乾·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、运维/实例配置（当前：宋祺睿·推断待确认）、测试（当前：李国庆·推断待确认）、业务验收（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 立项与规范对齐 → ② 按插件规范开发 → ③ 提测 → ④ 业务/产品验收 → ⑤ 定版本号与发版方式 → ⑥ 下发前检查 → ⑦ 测试机先发再发企业实例 → ⑧ 台账登记与回滚
  • 交付结果：通过验收的插件/skill 包（含版本号）、更新后的"企业-实例-行业版-已下发版本"台账、下发记录
  • 状态依据：已有插件规范 1.0、插件开发指南和 LeapOpen 下发能力，但规范仍在迭代；2026-08 两次误发（提前下发、发老版本）紧急撤回；企业名单靠群内口头给，Cloud 与 LeapUpdate 两处手工配置

1. 场景判定

  • 触发条件：行业功能（报告、测算、图片工作台、标务等）开发完成或有新需求；新企业开通行业版；子公司/合作伙伴要上架插件
  • 典型说法：「新 skill、skill 更新要怎么下发，找谁」「咱们插件规范有写好吗」「工程版要单独版本号吗」「以后集成都得走开放平台规范」
  • 判断问题：这是插件/skill 形态还是要改基座代码？目标企业实例是否已确定？客户端版本是否已发布？
  • 不归本流程管：行业版计费倍率 → 请走 RND-69；新模型/渠道接入 → 请走 RND-67；LeapCore 标品发版 → 请走 RND-51（正式版本发布上线），客户端安装包出包 → 请走 RND-52（客户端打包、签名与安装包分发）；演示机装 skill → 请走 RND-61

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行业版负责人 立项、排期、验收拍板、是否下发 A 产品总监（当前：杨萌·推断待确认）
架构决策 插件技术路径（MCP、UI webview 等）拍板 R（技术路径决策） 研发技术负责人（当前：王皓南·推断待确认）
插件研发 按规范开发、提测、修 bug R 插件研发（当前：侯怡辰、陈锦杰·推断待确认）
开放平台 插件门禁审核、版本号规则、企业名单、下发与撤回 R 开放平台负责人（当前：郭逸非·推断待确认）
skill 下发 按分类方案下发 skill 与场景包 R FDE/研发（当前：邓乾·推断待确认）
实例配置 Cloud 打标签、LeapUpdate 隐藏模型区配置 R 运维/发布工程师（当前：宋祺睿·推断待确认）
测试 测试环境测试、排期、出结论 R 测试（当前：李国庆·推断待确认）
业务验收 按业务场景体验并确认 C 工程咨询业务专家（当前：王满·推断待确认）
兜底 外部/子公司接入批准、架构争议裁决 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 读完插件开发指南与插件规范（MANIFEST 字段、capabilities、权限、打包、selfcheck、发布检查表）
  • 功能说明：行业版名称、插件/skill 清单、依赖的模型与工具、是否需 UI
  • 目标企业名单（名称 + 实例 UUID）、是否需要"行业模型"标签
  • 对应的 LeapCore 客户端最低版本
  • 外部/子公司接入：开放平台框架文档已读，测试号与开发者模式客户端已申请，数据上传与 OAuth 授权方案已写明
  • 请求最少包含字段（提测单/下发申请必填，缺项退回）：插件或 skill 名称与版本号、对应基座/客户端最低版本、目标企业名单（企业代号 + 实例 UUID，书面而非口头）、测试环境地址与包链接、待测范围、验收人（产品 + 业务）、期望下发日期与原因、回滚方式、提出人岗位

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：确认功能走插件/skill、技术路径和负责人，写入需求池 行业版负责人 + 架构决策 需求提出后 3 个工作日内 需求池、飞书 wiki 立项记录（需求池条目：负责人、技术路径、目标企业、排期） 👤人工判断
2 按插件规范开发，使用脚手架；提交前跑 selfcheck 与门禁检查 插件研发 按立项排期；延期须提前 2 个工作日在需求池条目说明 脚手架、CI 门禁 插件包（Gitea 产物 + selfcheck 结果） 🤖自动化
3 填提测单（环境、包、待测范围、验收人），合并到测试环境 插件研发 开发完成当天 提测多维表格 提测单（提测多维表格一行，自动 @ 测试） 🔧飞书固化
4 测试在测试环境执行并出结论；测试期间不得重拉代码重启服务 测试 提测后 2 个工作日内 测试环境 测试结论（写回提测单"结论"字段：通过/不通过 + 缺陷工单号）；超时→插件研发在提测单 @ 测试，再超 1 个工作日报行业版负责人 👤人工判断
5 业务验收：测试统一开验收账号并发"验收入口说明"（地址、网络要求、账号）；业务和产品按验收清单签核 测试 + 业务验收 + 行业版负责人 测试通过后 2 个工作日内 验收清单 验收记录（验收清单签核，附验收入口说明链接；账号走密码库或私信） 🔧飞书固化
6 定版本号与发版方式：默认跟随标品发版，版本号按"基座版本-行业版本"规则；确认客户端版本已发布 行业版负责人 + 开放平台 验收后 1 个工作日内 版本规则文档 版本号与发版方式（写入提测单与企业台账"待下发版本"） 👤人工判断
7 下发前检查：版本号、客户端版本、插件版本、模型标签、logo/文案、企业名单；发起下发审批 开放平台 下发前 1 个工作日 飞书审批 + 检查清单 审批记录（飞书审批，附勾选完成的下发检查清单与企业名单） 🔧飞书固化
8 实例配置：在 Cloud 打行业模型标签，在 LeapUpdate 配置隐藏模型 实例配置 审批通过后 4 个工作小时内 Cloud、LeapUpdate 配置记录（在审批单评论回写"已配置 + 实例列表"）；超时→开放平台 @ 实例配置岗 🤖自动化
9 先下发到测试机验证入口与版本，再下发正式企业实例；业务方抽查 skill 下发 + 开放平台 审批通过后 1 个工作日内 LeapOpen 下发记录（LeapOpen 记录 + 行业版群下发通知：版本、企业、时间） 🤖+👤
10 更新"企业-实例-行业版-已下发版本"台账；如误发立即撤回并通知负责人 开放平台 下发当天 多维表格台账 台账更新（企业台账多维表格，是版本分布的唯一来源） 🔧飞书固化

5. 交付物与模板

  • 交付物：插件/skill 包、提测单、验收记录、版本号、下发审批、企业台账
  • 建议模板/表单：
    • 提测单字段：插件名、版本、提测人、测试环境、包链接、待测范围、验收人、状态
    • 下发检查清单：插件版本 ↔ 客户端版本匹配、模型标签已打、logo/文案、企业名单与 UUID、回滚方式、审批人
    • 企业台账字段：企业代号、实例 UUID、行业版类型、标签、已下发插件及版本、下发时间、下发人、备注
    • 外部接入申请表：接入主体、插件说明、数据流向（是否上传服务器）、认证方式、测试号、提交人

6. 异常与升级

  • 下发后发现是未发布版本/老版本插件 → 开放平台立即撤回（15 分钟内）→ 通知行业版负责人与客户对接人，当天写复盘
  • 插件被运行策略保护拦截（skill/script 无法运行）→ 插件研发与架构决策人评估白名单方案 → 2 个工作日内给结论
  • 第三方插件无调试流程 → 先用测试号 + 开发者模式客户端调试 → 开放平台负责人跟进
  • 外部团队绕开开放平台要求直连集成 → 不批准 → 升级创始人兼 CTO
  • 业务方无法进入测试环境（网络/账号）→ 测试 4 小时内补发入口说明
  • 企业名单或实例 UUID 只在群里口头给、未写入下发申请 → 开放平台退回，不下发；行业版负责人 1 个工作日内补书面名单
  • 提测/验收/下发任一环节超过时限且责任人无回应 → 发起方在对应单据内 @ 责任人（不另开群）→ 1 个工作日无响应升级行业版负责人；涉及架构或外部接入升级创始人兼 CTO
  • 升级条件（A（升级））：外部团队或子公司申请接入平台、插件技术路径在架构决策人与行业版负责人之间 2 个工作日内未达成一致、误发造成客户影响 → 升级创始人兼 CTO 裁决；常规立项、验收与下发由行业版负责人（A）拍板

7. 衡量指标

  • 误发次数 = 下发后撤回的次数/月，目标 0
  • 验收周期 = 提测到业务验收签核的工作日，目标 ≤ 4 天
  • 台账准确率 = 抽查实例实际版本与台账一致的比例，目标 100%
  • 进度催办次数 = 群内"测完了吗/什么进度"追问次数/周，目标 ≤ 1

8. 低效诊断

  • 现象：行业版开发与打包无基建，先做再补流程，开发者被告知"你就是先驱者"｜依据：「Leap产研测」2026-06
  • 现象：误以为标品已发布而提前下发，后又下发老版本插件，两次紧急撤回｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：企业名单靠群里口头给，Cloud 与 LeapUpdate 需两处逐一配置｜依据：「【行业版Leapcore】工程版」2026-09
  • 现象：UI 插件负责人、前端注册方式反复争论，桌面端缺统一接入机制导致返工｜依据：「【行业版Leapcore】工程版」2026-07
  • 现象：插件开发文档和规范需追问获取，第三方插件无调试流程｜依据：「【行业版Leapcore】工程版」2026-08、「【行业版LeapCore】招投标版」2026-09
  • 现象：基座、行业版、插件版本号各自为政，发版时点理解不一致｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：业务人员不知道怎样用上测试版，测试中重拉代码导致任务失败｜依据：「【行业版Leapcore】工程版」2026-08

9. 分支变体

  • 工程版：随标品发版，下发到指定工程咨询客户实例，需行业模型标签
  • 投资人版：按标品下发 skill + 场景包，无专属 logo
  • 内置功能：如图片工作台由下发转为内置，按客户端发版处理
  • 第三方/合作伙伴插件（标务、子公司审查插件等）：以接入方主体走开放平台上架，由接入方提交，需合规审查
  • 测试机/生产机顺序：先 50/51 等测试机，再正式企业
  • 协作协议：遵循 ALL-04（跨部门交接契约）、ALL-01（工作请求提交与受理）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 行业版主责是产品总监，还是按行业（工程/投资/招投标）分别指定？
  • 版本号规则"基座版本-行业版本"是否由开放平台正式发布？
  • 下发是否必须走飞书审批？审批人是行业版负责人还是开放平台负责人？
  • 第三方插件调试流程与 OAuth/凭据管理方案由谁负责、何时完成？
  • 插件运行策略保护对随插件捆绑的 skill/script 如何放行？
RND-65移动端研发协作与构建发布待优化320

状态：待优化｜证据：有证据（卡片 4 张 / 会话 1 个）｜优先级：频4 × 耗4 × 跨5 × 险4

  • 适用场景：LeapCore 手机端/录音卡由外部伙伴承接开发，需要明确里程碑、接口文档、缺陷管理、APK/iOS 构建与内测分发、测试放行
  • 负责人：主责——外部协作负责人/产品总监（当前：杨萌·推断待确认）；协同——产品经理（当前：黄飞鹏·推断待确认）、客户端研发（接口与构建，当前：岳阳·推断待确认）、会议接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：潘浩伟、余超·推断待确认）、IT 运维（Apple 账号/证书，当前：杨明学·推断待确认）、外部开发团队（当前：外部伙伴）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 立项定里程碑 → ② 原型与接口清单交付 → ③ 每日同步 → ④ 接口文档变更通知 → ⑤ 构建与内测分发 → ⑥ 测试提缺陷 → ⑦ 修复验收 → ⑧ 放行结论与公测
  • 交付结果：按里程碑交付的 APK/iOS 内测包、维护中的移动端 API 文档（含变更日志）、测试报告与放行结论
  • 状态依据：协作群、接口文档、Gitea issues、构建通知卡已存在，但阶段划分缺失导致混合开发，接口文档"现查"、追问约 20 次，同一 bug 研发与外部重复修复，构建"没什么 SOP"

1. 场景判定

  • 触发条件：与外部团队合作开发移动端；外部开发提出接口问题；代码合入需要出包；新版本需测试放行或公测
  • 典型说法：「每天下班前同步下进度」「接口文档请查收」「最新 main 构建完成」「上线前修复 P2 及以上的 BUG」
  • 判断问题：本次需求属于哪个里程碑？接口是否已在文档中？包是否从最新 main 构建？
  • 不归本流程管：应用商店上架 → 请走 RND-60；外部团队费用结算付款 → 请走 FIN-01（对公采购申请与付款审批）；个人垫付的订阅费用报销 → 请走 FIN-06（日常费用报销提交与审核）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
协作负责人 立项、定里程碑、节奏与放行决策 A 产品总监（当前：杨萌·推断待确认）
产品 原型、优先级、页面逻辑验收 R 产品经理（当前：黄飞鹏·推断待确认）
接口与构建 维护 API 文档、研发支持、构建出包、变更日志 R 客户端研发（当前：岳阳·推断待确认）、会议接口研发（当前：马漳毓·推断待确认）
外部开发 按里程碑开发、每日同步、修复缺陷 R 外部开发团队（当前：外部伙伴）
测试 组织测试、定级、验收、出放行结论 R 测试负责人（当前：张东郅·推断待确认）、测试（当前：潘浩伟、余超·推断待确认）
账号证书 Apple 开发者账号、证书、UDID、TestFlight 成员 R IT 运维（当前：杨明学·推断待确认）
兜底 代码质量评审、合作方案调整 R/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 合作范围与里程碑（阶段一/二功能清单、日期、演示节点）
  • 原型文件与优先级、接口清单（已有/待开发）
  • 外部团队账号：Gitea 公司仓库权限、开发版 LeapCore 账号、Apple 开发者账号邀请
  • 测试机、录音卡等硬件寄送与签收
  • 代码必须在公司仓库，不得在外部仓库独立维护

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项会：确定阶段划分、里程碑、验收标准，写入协作 wiki 协作负责人 + 产品 合作启动 3 个工作日内 飞书 wiki 里程碑表 👤人工判断
2 交付原型与接口清单，标注每页对应接口与状态 产品 + 接口与构建 立项后 3 个工作日内 原型、Gitea wiki 接口清单 👤人工判断
3 外部团队每个工作日 18:00 前按模板同步进度/卡点/需配合事项 外部开发 每个工作日 协作群机器人提醒 日报 🔧+🤖
4 接口变更或新增时同步更新 Gitea wiki 文档（唯一版本），写变更日志并推送群 接口与构建 接口合入当天 Gitea wiki、OpenAPI 文档与变更日志 🤖自动化
5 代码合入后从最新 main 构建，发布提交号、变体、SHA-256、变更日志；Android 分发、iOS 上传 TestFlight 接口与构建 合入后 1 个工作日内 构建流水线、TestFlight、分发平台 内测包与通知卡 🤖自动化
6 测试按清单测试，缺陷只提到 Gitea LeapAPP issues 并定级 P0～P3；认领后标注处理人，避免重复修复 测试 + 外部开发 出包后 2 个工作日内 Gitea issues 缺陷单 🤖+👤
7 P0 由客户端研发当天评估能否次日修复；修复后测试在实机验收并关闭 接口与构建 + 测试 P0 当天评估 Gitea issues 验收结果 👤人工判断
8 测试出放行结论（如"上线前修复 P2 及以上"），协作负责人决定公测节奏 测试负责人 + 协作负责人 里程碑节点前 1 个工作日 测试报告 放行结论 👤人工判断
9 里程碑后做代码质量评审，结论写入协作 wiki 并要求改进计划 兜底 每个里程碑后 3 个工作日内 Gitea PR 评审 评审意见 👤人工判断

5. 交付物与模板

  • 交付物：里程碑表、API 文档与变更日志、内测包、缺陷单、测试报告与放行结论
  • 建议模板/表单：
    • 外部日报模板：今日完成、进行中、卡点、需公司配合事项、明日计划
    • 接口清单字段：模块、接口名、路径、状态（已有/开发中/待定）、负责人、更新日期、新旧客户端差异说明
    • 构建通知卡字段：版本号、提交号、变体、SHA-256、变更日志、下载/TestFlight 链接
    • 证书与 UDID 管理表：设备、UDID、使用人、证书到期日

6. 异常与升级

  • 接口文档缺失阻塞开发 → 外部团队在群内提出，接口与构建 1 个工作日内补齐 → 超时升级协作负责人
  • 包不是最新 main（如在临时 worktree 构建）→ 作废并重构建 → 当天通知测试
  • iOS 无证书或审核卡住超过 1 周 → IT 运维跟进 Apple 审核 → 影响演示节点时升级协作负责人
  • 修 bug 误删已有功能 → 回滚该提交，补回归用例 → 当天通知测试负责人
  • 测试人力被调走 → 测试负责人 1 个工作日内调整排期并告知协作负责人
  • 外部代码质量不达标 → 兜底人书面要求改进方案（3 个工作日内）
  • 升级条件（A（升级））：里程碑评审代码质量不达标、需调整合作范围/合作方或更换外部团队、里程碑延期超过 1 周 → 升级创始人兼 CTO 拍板；日常节奏与放行由协作负责人（A）决定

7. 衡量指标

  • 里程碑按期率 = 按期交付的里程碑 ÷ 总里程碑，目标 ≥ 80%
  • 接口追问次数 = 因文档缺失在群内追问次数/周，目标 ≤ 2
  • 重复修复次数 = 同一缺陷被两方同时修复的次数，目标 0
  • 出包时效 = 合入到内测包可用的小时数，目标 ≤ 24 小时

8. 低效诊断

  • 现象：未划分阶段，原型优先级与外部排期无共识，形成混合开发，页面逻辑多次反复｜依据：「手机端-录音卡」2026-08、「手机端-录音卡」2026-09
  • 现象：接口文档滞后，"现查"补充，文档编号混乱，外部看错版本｜依据：「手机端-录音卡」2026-09
  • 现象：同一缺陷研发与外部团队撞车修复，修 bug 时误删已有排队功能｜依据：「手机端-录音卡」2026-09、「手机端-录音卡」2026-10
  • 现象：构建无成文流程，曾在非最新代码上打包；iOS 证书与账号依赖单人｜依据：「手机端-录音卡」2026-09、「手机端-录音卡」2026-10
  • 现象：反复询问"包更新了没""什么时候能发代码"｜依据：「手机端-录音卡」2026-09

9. 分支变体

  • Android：内测分发平台/飞书文件（野包）→ 后续应用商店
  • iOS：TestFlight 内部组 → 公测链接（招募用户）→ 正式审核
  • 录音卡等硬件联调：需寄送硬件并登记
  • PC/移动对照测试：同一功能需与 PC 客户端行为对照

10. 待确认问题

  • 外部协作主责是否固定为产品总监？是否需要一个研发侧接口负责人作为第二责任人？
  • 外部团队的验收标准和付款节点是否与里程碑挂钩？由谁审批？
  • API 文档是否切换为 OpenAPI 自动生成？
  • Apple 账号与证书是否需要设置备岗管理员？
  • 放行标准"上线前修复 P2 及以上"是否作为移动端统一口径？
RND-66支付功能联调与收款商户管理待新建160

状态：待新建｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：支付/网银/电子签功能开发需真实小额付款联调；产品需按 2B/2C 选择或切换收款商户；线上出现到账延迟、回调异常、分账失败
  • 负责人：主责——支付研发工程师（当前：陈锦杰·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务（经办，当前：刘梦可·推断待确认）、支付渠道对接人（当前：徐莉·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAll 对接研发（当前：邓乾·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 测试付款申请 → ② 小额真实联调 → ③ 商户路由规则确认 → ④ 切换前检查 → ⑤ 切换与一元验证 → ⑥ 监控与对账 → ⑦ 异常处置 → ⑧ 复盘
  • 交付结果：联调通过记录与测试付款报销凭证、商户路由配置（产品↔主体↔商户）、切换检查单、支付异常处置与复盘记录
  • 状态依据：支付渠道无测试服，每次联调临时协调垫付资金与 U 盾；商户切换后才发现分账比例限制与进件缺失；回调延迟反馈后未修，分账失败靠偶然查日志发现，无告警和复盘流程

1. 场景判定

  • 触发条件：支付/网银/电子签接口开发完成待验证；新产品接入收款；新商户开通需切换；用户反馈已付款未到账
  • 典型说法：「没有测试服，不拿真实材料过不了校验」「加一个商户路由」「付一块钱试试」「别都回调一把梭」
  • 判断问题：是否涉及真实资金？用哪个收款主体？对公付款需要几个 U 盾、在谁手上？
  • 不归本流程管：支付功能立项 → 请走 RND-05；资金逻辑测试用例设计 → 请走 RND-44；对外开票 → 请走 FIN-18（客户充值订单开票）/FIN-19（销售合同开票申请与红冲）；支付渠道财务对账 → 请走 FIN-24（支付渠道每日对账、手续费与差异处理）；新商户进件与收款权限开通 → 请走 FIN-15（支付通道选型、商户进件与收款权限开通）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
支付研发 联调、路由配置、切换执行、查日志、异常修复 R 支付研发工程师（当前：陈锦杰·推断待确认）
技术负责人 支付架构（唯一数据源、幂等、兜底）、故障拉会、联调与切换放行 A 研发技术负责人（当前：王皓南·推断待确认）
财务 测试款审批与报销、对公 U 盾经办/审核、结算与对账 R/C 财务负责人（当前：黄梦婷·推断待确认）、财务（当前：刘梦可·推断待确认）
渠道对接 与支付渠道沟通开户、进件、分账比例 R 支付渠道对接人（当前：徐莉·推断待确认）
测试 工单验收、生产小额验证 R 测试负责人（当前：张东郅·推断待确认）
业务产品对接 LeapAll 等产品侧确认切换无影响 C LeapAll 对接研发（当前：邓乾·推断待确认）
兜底 收款主体划分、测试资金来源、遗留问题处置 R/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 测试计划：测试场景、轮数、单笔金额（尽量最小额）、预计总额、付款方式（个人小额/对公网银）
  • 对公测试：U 盾经办人与审核人在岗时间、业务模式是否已向银行/渠道申报
  • 商户信息：产品 → 2B/2C → 收款主体 → 商户号；分账比例上限、进件主体、结算方式（自动/手动）、打款附言配置
  • 工单号（如 LEAP-xxx）与回滚方案

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起"支付测试付款"飞书审批（场景、轮数、金额、付款账户），使用公司测试付款户，不由个人垫付 支付研发 联调前 2 个工作日 飞书审批 审批单 🔧飞书固化
2 对公网银测试：提前预约经办盾、审核盾两人的在岗时段 支付研发 + 财务 联调前 1 个工作日 飞书日程 预约时段 🔧飞书固化
3 小额真实联调，记录订单号、金额、结果；测试款项凭单报销或退款 支付研发 预约时段内完成 支付渠道、LeapPay 联调记录 👤人工判断
4 确定商户路由规则（如 2C 走一个主体、2B 走另一个主体、子品牌独立开户），写入路由配置表 兜底 + 财务 新产品接入前 多维表格 路由规则 👤人工判断
5 切换前检查：分账比例上限、进件主体完整、结算方式、打款附言、密钥映射 支付研发 + 渠道对接 切换前 1 个工作日 切换检查单 检查记录 🔧飞书固化
6 在工单中执行切换，提前通知产品侧；测试验收后关闭工单 支付研发 + 测试 按计划窗口 工单系统、LeapPay 后台 工单结论 🤖+👤
7 生产做最小金额支付验证，并验证回调、分账、到账 测试 切换后 1 小时内 生产环境 验证结果 👤人工判断
8 开启支付异常告警与每日对账脚本（订单状态 vs 渠道状态 vs 分账结果） 支付研发 上线当天 告警机器人、对账脚本 告警与对账报表 🤖自动化

5. 交付物与模板

  • 交付物：测试付款审批与报销凭证、联调记录、商户路由配置表、切换检查单、工单验收结论、对账报表、异常复盘
  • 建议模板/表单：
    • 测试付款审批字段：申请人、产品、测试场景、轮数、单笔金额、预计总额、付款账户、U 盾经办/审核人、报销/退款方式
    • 商户路由表字段：产品、业务类型（2B/2C）、收款主体、商户号代号、分账比例上限、进件状态、结算方式、附言、生效日期、负责人
    • 支付异常复盘字段：发现时间、影响订单数、异常类型（漏发/重发/漏收/处理报错/分账失败）、根因、补单/退款处理、改进项

6. 异常与升级

  • 用户已付款未到账 → 支付研发 30 分钟内查日志并主动查询渠道订单状态，必要时人工补单 → 1 小时未定位升级研发技术负责人
  • 回调漏发/重发 → 依靠定期状态查询兜底，处理逻辑保证幂等 → 当天写复盘
  • 分账失败 → 不得"久远就不管"，记录失败订单并与财务确认手动结算方案 → 2 个工作日内处理
  • 线下汇款 → 必须财务确认后才入账 → 财务负责人
  • U 盾持有人不在导致联调阻塞超过 1 个工作日 → 升级财务负责人调整
  • 升级条件（A（升级））：需新划分或调整收款主体/商户路由、测试资金来源无预算归属、支付异常影响用户资金且 4 小时内未止损、历史遗留分账失败订单需定处置口径 → 升级创始人兼 CTO 拍板；日常联调、切换与故障处置由研发技术负责人（A）放行

7. 衡量指标

  • 联调阻塞时长 = 因等资金/等盾/等人阻塞的工作日，目标 ≤ 1 天
  • 个人垫付次数 = 测试款由个人账户垫付的次数，目标 0
  • 支付异常发现时效 = 异常发生到告警/发现的分钟数，目标 ≤ 15 分钟
  • 对账差异率 = 对账不一致订单 ÷ 总订单，目标 0，差异当天闭环

8. 低效诊断

  • 现象：支付渠道无测试服，对公网银测试从首次尝试到首次成功卡了约一周，反复等 U 盾和经办人｜依据：「LeapPay」2026-08
  • 现象：测试资金来源、经办与审核职责不清，由个人垫付后再报销，业务模式未申报导致经办失败｜依据：「LeapPay」2026-04、「LeapPay」2026-08
  • 现象：同一商户给多个产品使用，附言只能商户级配置，2B/2C 收款混在一起｜依据：「LeapPay」2026-07、「LeapPay」2026-10
  • 现象：商户切换后才发现分账比例上限和进件缺失，导致分账失败｜依据：「LeapPay」2026-08
  • 现象：到账延迟反馈后长期未修，分账失败靠偶然查日志发现，无告警｜依据：「LeapPay」2026-06、「LeapPay」2026-08

9. 分支变体

  • 个人小额测试（支付宝/在线支付）：开发自行完成，按审批额度报销
  • 对公网银测试：需经办盾 + 审核盾两人，必须提前预约
  • 支付渠道差异：支付渠道 A/B/C 各有接入与分账规则，切换前逐项核对
  • 结算方式：自动结算 vs 财务后台手动拆分；子商户方案另行评估
  • 子品牌（如鼎慧）：独立开户，路由表单列

10. 待确认问题

  • 主责是否为支付研发工程师？研发技术负责人是否兼任支付故障第一响应人？
  • 是否设立公司专用测试付款户和月度测试额度？额度多少、由谁审批？
  • 收款主体划分（2B/2C 分别对应哪个主体）是否已有财务成文规定？
  • 已发生的分账失败遗留订单是否需要补处理？
  • 支付异常告警推送给哪个群、哪些人？
RND-67新模型/上游渠道/第三方 API 接入与上线验证待优化400

状态：待优化｜证据：有证据（卡片 22 张 / 会话 6 个）｜优先级：频5 × 耗4 × 跨4 × 险5

  • 适用场景：产品、客户或内部需要新模型、新上游渠道或第三方付费 API（OCR、企业数据、搜索、生图、视频），需完成 key 申请、网关接入、参数规则、价格配置、测试服验证、生产上线与下游同步
  • 负责人：主责——模型网关研发负责人（当前：柯逸飞·推断待确认）；协同——上游渠道/aiapi 维护（当前：杨明学·推断待确认，备岗：吴世豪·推断待确认）、研发技术负责人（网关架构，当前：王皓南·推断待确认）、运维/发布工程师（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户本地 NewAPI 配置（当前：李铭熙·推断待确认）、LeapAll NewAPI（当前：邓乾·推断待确认）、财务（充值，当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 接入需求登记 → ② 成本对比与是否接入 → ③ key/额度申请 → ④ aiapi/v5 网关配置渠道与价格 → ⑤ 测试服部署 → ⑥ 冒烟/稳定性/价格验收 → ⑦ hotfix 上生产并观察 → ⑧ 下游同步与通知
  • 交付结果：生产可用的模型/API（含渠道、模型 ID、价格、fallback）、模型上架台账记录、验收结论（工单评论）、下游（LeapCore/LeapAll/客户本地）同步完成通知
  • 状态依据：已形成"工单 → PR → 测试服 → 验收 → hotfix"路径并有接入/查价 skill，但 2026-05～10 仍反复出现需求模型反复变、配置阻塞在单人、key 归属不明、测试服没钱、价格未验证、漏开模型开关等问题，管理层多次要求"SOP 化"

1. 场景判定

  • 触发条件：上游出新模型；现有渠道不稳或更贵需换渠道；客户点名要某模型；产品需新增第三方付费能力；POC 有能力缺口需临时接外部服务
  • 典型说法：「我们的 aiapi 里上了吗」「模型到底什么时候能好」「这个要走审批吗」「没成本对比怎么就开始接入了」「记得配官网价」
  • 判断问题：是新增接入还是只改价格/档位？是否已做成本对比？给哪些产品线/客户用？生产与测试 key 是否分开？
  • 不归本流程管：渠道/模型的质量评测与供应商选型 → 请走 RND-68；行业版计费倍率 → 请走 RND-69；演示用第三方额度 → 请走 RND-61

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求方 提交模型/API 名称、用途、产品线、期限 R 产品/研发/销售（申请人）
接入负责人 建工单、成本对比、v5/aiapi 配置渠道与价格、提 PR R 模型网关研发负责人（当前：柯逸飞·推断待确认）
上游渠道 aiapi 上游渠道开通、key 发放、额度对账 R 上游渠道/aiapi 维护（当前：杨明学·推断待确认；备岗：吴世豪·推断待确认）
架构决策 网关方案、参数规则、档位映射拍板 C/R（技术方案） 研发技术负责人（当前：王皓南·推断待确认）
部署 测试服与生产部署、环境变量、密钥配置 R 运维/发布工程师（当前：宋祺睿·推断待确认）
测试验收 冒烟、稳定性、价格对账，结论写工单 R 测试负责人（当前：张东郅·推断待确认）
下游同步 LeapAll NewAPI、客户本地 NewAPI 同步配置 R LeapAll 研发（当前：邓乾·推断待确认）、客户本地配置（当前：李铭熙·推断待确认）
财务 充值、采购付款、成本归集 C 财务负责人（当前：黄梦婷·推断待确认）
兜底 是否接入、供应商商务、放行与回滚最终决策 A 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 模型/API 名称与版本（精确 ID，避免"2.0 / 2-0"之类命名差异）、类型（对话/生图/视频/搜索/OCR/企业数据）
  • 使用方：产品线（LeapCore/LeapAll/鼎慧/客户本地）、是否对客户开放、预计用量
  • 成本对比：候选渠道成本价、官网价、现有渠道价格、汇率口径、折扣是否真实生效
  • key 与额度：测试 key 与生产 key 分开申请，写明额度、负责人、到期日；不得使用个人账号开的试用 key
  • 上游特殊要求：是否需在控制台逐模型开关、是否需指定 provider、是否异步接口、并发/TPM 是否需提额
  • 请求最少包含字段（接入需求登记必填，缺项不建工单）：精确模型/API ID 与类型、需求方岗位与用途、使用的产品线与是否对客户开放、预计月用量/并发、期望上线日期与原因（客户承诺/POC/成本）、候选渠道与成本对比是否已做、测试/生产 key 是否已有、是否临时（POC）接入

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在"模型上架台账"登记需求并建 LEAP 工单 需求方 + 接入负责人 需求提出当天 多维表格、工单系统 台账记录（模型上架台账一行）+ LEAP 工单（工单号回填台账，需求方被 @） 🔧飞书固化
2 成本对比：与现有渠道比价，比现有便宜或补能力缺口才接；价格抓取由脚本同步官网/公开价，人工核对 接入负责人 建单后 1 个工作日内 查价 skill/脚本 成本对比结论（工单评论 + 台账"成本价/售价"字段） 🤖+👤
3 是否接入、接入批次（首批精选/二批）决策 兜底 对比结论出后 1 个工作日内 工单评论 接入决定（工单评论：接/不接/批次 + 理由）；超时→接入负责人在工单 @ 兜底人 👤人工判断
4 申请上游 key 与额度（测试/生产分开），审批通过自动记入 key 台账 接入负责人 + 上游渠道 已有厂商 1 个工作小时内，新厂商 2 个工作日内 飞书审批 → 台账 key 与额度（key 台账记录；key 本体走密码库，不进群）；超时→接入负责人 @ 备岗 🔧飞书固化
5 在 aiapi/v5 配置渠道、模型 ID、价格（按官网价/约定倍率）、fallback 顺序；按"先取上游参数范围再建任务"处理参数规则，不在下游硬编码映射 接入负责人 key 到位后，已有厂商 2 个工作小时内 aiapi、v5 网关 PR（Gitea，标题含工单号，链接贴回工单） 🤖+👤
6 部署测试服，确认测试 key 余额与环境变量；部署完成机器人自动 @ 测试负责人 部署 PR 合并后 2 个工作小时内 Gitea Actions、机器人 测试服可用（部署通知卡片 @ 测试负责人，含环境与模型 ID）；超时→接入负责人 @ 部署岗 🤖自动化
7 验收：冒烟、多轮/流式/思考强度、稳定性抽样、逐笔价格与预期 CSV 对比；压测前先通知上游维护者 测试验收 部署后 1 个工作日内 测试 skill、对账脚本 验收结论（工单评论：通过/不通过 + 价格对账结果）；超时→接入负责人在工单 @ 测试负责人 🤖+👤
8 发 hotfix 上生产（工作时间内上线），观察至当天 18:00，严重问题立即回滚 部署 + 接入负责人 验收通过后 1 个工作日内 生产环境 上线记录（工单评论 + 台账状态"生产已上"，按 RND-54 走 hotfix 单） 👤人工判断
9 同步下游：LeapCore 总 NewAPI、LeapAll NewAPI、客户本地 NewAPI；隐藏模型用统一前缀，防止误下发 下游同步 生产上线后 1 个工作日内 NewAPI 后台 同步记录（台账各下游状态字段逐项勾选，缺一不算完成）；超时→接入负责人 @ 对应下游负责人 🤖+👤
10 台账状态更新为"已上线"，机器人通知需求方与相关群；开启余额与可用率告警 接入负责人 同步完成当天 台账、告警机器人 上线通知（需求方 + 研发通知群卡片：模型 ID、价格、可用产品线）+ 告警开启记录 🔧+🤖

5. 交付物与模板

  • 交付物：工单与 PR、成本对比结论、key 台账记录、验收结论、上线记录、下游同步记录、上线通知
  • 建议模板/表单：
    • 模型上架台账字段：模型 ID、类型、上游渠道、需求方、产品线、批次、成本价、刊例价/售价、倍率、aiapi/v5/LeapCore/LeapAll/客户本地 各处状态、接入人、验收人、上线日期、fallback
    • key 台账字段：供应商、用途（测试/生产/研发自用）、额度、余额预警阈值、负责人、开通账号归属（必须公司账号）、到期日
    • 接入工单检查清单：渠道开关/逐模型开关、provider 指定、key（测试/生产）、模型 ID、价格（成本/售价/阶梯/缓存）、并发/TPM、超时、计费（失败不计费）、限流与审计、回滚点

6. 异常与升级

  • 已有 NewAPI 模型故障 → 接入负责人 4 小时内解决或切 fallback → 超时升级研发技术负责人
  • 测试服 key 余额不足或 402 → 上游渠道 1 个工作小时内补额度，并检查测试/生产 key 是否混用
  • 上线后价格/档位异常（扣费错误、400/429）→ 立即回滚，按工单补验收项 → 当天升级兜底人
  • 怀疑 key 泄露 → 立即重置并下调限额 → 通知运维与兜底人
  • 上游渠道维护人不在（交付/外出）→ 由备岗接手，不得阻塞超过 1 个工作日
  • 第三方付费 API 调用成本异常 → 开限流、缓存与审计 → 升级兜底人与财务
  • 需求方问"上了没/什么进度" → 统一回指模型上架台账状态，不在群里逐一答复；台账状态落后于实际超过半个工作日的，接入负责人补更新
  • 任一环节（key 申请、部署、验收、下游同步）超过时限且责任人无回应 → 接入负责人在工单内 @ 责任人与备岗 → 再过 4 个工作小时无响应升级研发技术负责人；影响客户承诺日期的同时通知需求方调整预期

7. 衡量指标

  • 接入时效 = 决定接入到生产可用的工作日，已有厂商目标 ≤ 1 天，新厂商目标 ≤ 3 天
  • 价格配置错误数 = 上线后发现价格/倍率错误的次数/月，目标 0
  • 测试阻塞次数 = 因测试 key 无额度/环境缺 key 阻塞验收的次数/月，目标 0
  • 进度追问次数 = 群内"上了没/什么进度"追问次数/周，目标 ≤ 2
  • 渠道可用率 = 生产渠道月可用时间占比，目标 ≥ 99%

8. 低效诊断

  • 现象：新 API 配置全部阻塞在单人，无一主两备，交接范围不清｜依据：「Leap产研测」2026-06、「AI API」2026-07
  • 现象：需求模型版本反复变，接入人"没人告诉我要接入这个"，未做成本对比就开始接入｜依据：「Leap产研测」2026-06、「AI API」2026-09
  • 现象：key 归属和额度无台账，试用 key 用个人账号开，测试服与生产 key 混淆导致"没钱"排查浪费时间｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：模型名/前缀/分组口头约定，命名不一致导致 model_not_found，接错渠道后改回｜依据：「Leap产研测」2026-07、「AI API」2026-07、「AI API」2026-08
  • 现象：价格手工同步，接入后才发现"价格没验证"、对外价与官网不一致｜依据：「跃迁AI总动员」2026-06、「工程咨询产研」2026-08
  • 现象：验收与部署靠群里 @ 催办，测试服被占用或误重启，生产档位失效约十余天才对上工单｜依据：「AI API」2026-09
  • 现象：上游故障时误判为自身代码问题，频繁临时切换渠道｜依据：「Leap产研测」2026-05
  • 现象：POC 遇到能力缺口，第三方 API 与云账号找谁开通反复询问｜依据：「某投资客户 POC 群」2026-08
  • 现象：生图上游 429/宕机后才临时加 fallback，成本价同步需人工提醒｜依据：「某服装客户专项群」2026-08、「某服装客户专项群」2026-09

9. 分支变体

  • 渠道类型：国内云厂商官转（云厂商 A/B/C）vs 海外中转站/AI Gateway（需指定 provider）
  • 模型类型：对话、生图、视频（异步接口，NewAPI 计费可能不支持，需评估 worker/新网关）、搜索、OCR、企业数据
  • 部署位置：aiapi 上游汇聚 → LeapCore 总 NewAPI → LeapAll NewAPI → 客户本地 NewAPI（如能源客户 A、高校客户 B，需单独同步）
  • 内部自用模型（不给客户）：按官网价配，可单独发 key，走"内部开放试用申请"，登记额度与回收时间
  • 子品牌渠道切换（如鼎慧产品切换到专属云渠道）：管理端价格需单独验证，阶梯计价需提前确认系统是否支持
  • POC 临时外部服务：在工单中标记"临时"，POC 结束后评估转正式或下线
  • 纯价格更新/档位切换：跳过第 2～4 步，验收重点为计费与思考强度/限流
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 主责是否为模型网关研发负责人？aiapi 上游维护的主备人员是否正式确认？
  • "一主两备、已有厂商 1～2 小时接入、模型故障 4 小时内解决"是否作为正式 SLA？
  • 上游 key/额度申请是否统一走现有飞书申请表，审批人是谁？财务充值由谁对接？
  • 研发测试与营业成本 key 是否必须分开归集？
  • 定价（售价/倍率）由谁最终审批？是否需要价格变更审批？
RND-68模型与上游供应商选型评测待新建108

状态：待新建｜证据：有证据（卡片 10 张 / 会话 9 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：出现更便宜/更稳的上游渠道、新模型、新 OCR 或工具，或客户硬件变化需要选型，需做质量 bench、测速、成本与折扣核算，决定是否采用
  • 负责人：主责——模型供应商与评测负责人（当前：待指定）；协同——测试负责人（当前：张东郅·推断待确认）、模型网关研发（当前：柯逸飞·推断待确认）、模型评测（当前：董洪焜、魏宗浩·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、IT 运维/硬件测速（当前：杨明学、游家豪·推断待确认）、基座研发负责人（客户本地模型，当前：望政韬·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 登记评测需求 → ② 定评测范围、预算与负责人 → ③ 开评测账号/额度 → ④ 跑固定评测集（质量/速度/稳定性） → ⑤ 成本与折扣核算 → ⑥ 出评测报告 → ⑦ 选型决策 → ⑧ 结论入库并转接入
  • 交付结果：一份标准评测报告（质量、速度、稳定性、成本、结论），评测记录多维表格中的一条记录，采用时转 RND-67 的接入工单
  • 状态依据：多次提出"要建立自己的评测流程/评测集"，但"安排一下"后无责任人和交付日期；每次新模型临时各自测、结论口径冲突、不留存；评测常因没账号、没额度中断；供应商与评测缺专职 owner

1. 场景判定

  • 触发条件：发现新渠道/新模型/新开源 OCR；上游涨价或不稳；准备切换生产渠道；客户硬件（国产卡、4090 等）需要部署模型；采购合同需核实折扣
  • 典型说法：「得有人管供应商和评测」「给个同一个文件的页/秒对照表格」「帮我核一下大致几折」
  • 判断问题：评测结论会影响生产切换或客户选型吗？有无可复用的评测集？预算上限是多少？
  • 不归本流程管：决定接入后的配置与上线 → 请走 RND-67；客户现场模型部署交付 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；供应商询价、折扣谈判与签约 → 请走 X-OTH-01（上游模型/云服务供应商询价、折扣谈判与签约）；供应商合同审核 → 请走 LEG-04（采购/服务及其他对外合同、承诺函起草与审核）；付款 → 请走 FIN-01（对公采购申请与付款审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
评测负责人 管理供应商清单、排评测、维护评测集、出报告 R 模型供应商与评测负责人（当前：待指定）
评测执行 跑 bench、对比官方 trace、指纹对照、测 TTFT/TPS/429 R 测试负责人（当前：张东郅·推断待确认）、模型评测（当前：董洪焜、魏宗浩·推断待确认）
账号与额度 开评测 key、配置渠道 R 模型网关研发（当前：柯逸飞·推断待确认）
硬件测速 在目标硬件部署并记录并发与吞吐 R IT 运维（当前：杨明学、游家豪·推断待确认）
技术意见 评测方法、评测集构成、结论复核 C 研发技术负责人（当前：王皓南·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）
兜底 设预算、选型拍板、商务谈判 A 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 候选对象：供应商/渠道、模型 ID 与版本、是否自部署/量化、接口协议
  • 对比基线：现有生产渠道或官方原版
  • 评测集：对话用 bench 题（如 deepswe 中等题）、OCR 用真实可研/表格/公式文档（含 word→pdf 反向对照）、生图用固定提示词集
  • 预算上限与评测 key 额度（评测账号需有对应渠道权限）
  • 成本资料：官网价、合同折扣页、充值优惠与汇率口径、能否开国内发票

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在"模型评测记录"登记评测需求（对象、目的、基线、截止日） 需求方 发现后 1 个工作日内 多维表格 评测需求 🔧飞书固化
2 指定评测执行人、截止日和预算上限，写入记录 评测负责人（必要时兜底人批预算） 登记后 1 个工作日内 多维表格 任务分派 👤人工判断
3 开评测 key 与额度，确认渠道权限，压测前通知上游维护者 账号与额度 分派后 4 个工作小时内 网关后台 可用评测 key 🤖+👤
4 跑固定评测集：质量（与官方 trace/指纹对照，排除量化弱智版）、速度（TTFT/TPS）、稳定性（成功率、429/5xx、多轮中断率） 评测执行 分派后 3 个工作日内 评测 skill/脚本 原始结果 🤖自动化
5 本地部署类：在目标硬件用标准镜像部署，记录并发与吞吐 硬件测速 硬件就绪后 3 个工作日内 测速脚本、标准环境镜像 测速结果 🤖自动化
6 成本与折扣核算：按官网价自动换算折扣，统一汇率口径，算单次调用/单张成本与毛利；内部核算表不对外发送 评测负责人 与第 4 步并行 成本/折扣台账 成本结论 🤖+👤
7 按模板出评测报告并发评测群，供应商沟通记录同步归档 评测负责人 截止日当天 飞书文档 评测报告 🔧飞书固化
8 选型决策：采用/作为 fallback/不采用；采用则建 RND-67 接入工单 兜底 报告发出后 2 个工作日内 工单系统 决策记录 👤人工判断
9 结论、评测集版本、报告链接写回评测记录；每月复盘一次供应商清单 评测负责人 决策当天；每月一次 多维表格 评测库 🔧飞书固化

5. 交付物与模板

  • 交付物：评测报告、评测记录、成本核算表（内部）、选型决策、供应商清单
  • 建议模板/表单：
    • 评测记录字段：评测 ID、对象（供应商/模型/版本）、类型（对话/生图/视频/OCR/工具）、基线、评测集版本、质量得分、TTFT/TPS、成功率、429/5xx、成本、结论、评测人、日期、报告链接
    • 供应商清单字段：供应商、渠道类型（官转/中转/AI Gateway/自部署）、支持能力（缓存、图生图、responses 等）、价格与汇率方式、能否开国内发票、客服渠道、负责人、最近评测结论
    • 评测报告模板：目的、对象与基线、评测集、方法、结果表、成本、风险、结论与建议

6. 异常与升级

  • 评测中途额度耗尽或无渠道权限 → 账号与额度 2 个工作小时内补充 → 超过 1 个工作日升级兜底人
  • 评测结果与官方差异明显（疑似量化/降智）→ 不切生产，整理复现说明发供应商 → 评测负责人跟进
  • 评测"安排一下"后超过截止日无结果 → 评测负责人改派 → 升级兜底人
  • 供应商无法开国内发票或合规存疑 → 标"不可采购" → 财务与兜底人确认
  • 国产硬件不支持新模型 → 向硬件厂商书面确认支持计划 → 硬件测速负责人跟进

7. 衡量指标

  • 评测完成率 = 截止日前出报告的评测数 ÷ 评测需求数，目标 ≥ 90%
  • 评测周期 = 登记到报告发出的工作日，目标 ≤ 5 天
  • 结论留存率 = 有报告链接的评测记录 ÷ 总评测，目标 100%
  • 误切次数 = 切换后因质量/稳定性问题回退的次数/季度，目标 0

8. 低效诊断

  • 现象：多次提出建立自有评测集和脚本，分派后无责任人与交付日期，停留在讨论｜依据：「模态AI探索小分队」2026-01、「模态AI探索小分队」2026-02、「模态AI探索小分队」2026-03
  • 现象：新模型/OCR 出现后各自临时自测，结论各说各话，程序和结果需翻找｜依据：「鸽子群模态分群」2026-02、「鸽子群模态分群」2026-03
  • 现象：供应商与评测缺专职 owner，评测因"没账号"无法开展，采购与评测顺序不清｜依据：「Leap产研决策部」2026-10
  • 现象：自部署上游质量 bench 因没钱、key 不足被打断，bench 集未建好｜依据：「AI API」2026-10
  • 现象：渠道切换后变慢又切回，稳定性判断靠经验，供应商沟通在外部 IM 群、未留痕｜依据：「AI API」2026-08
  • 现象：评测文档与实现不一致，模型 ID 对不上导致 402，搜索类 badcase 累计多起｜依据：「Leap产研测」2026-08
  • 现象：折扣口径看不懂、反复手工做表，内部算价文件险被当作对外文件｜依据：「鼎慧产研决策部」2026-03
  • 现象：每次新卡/新模型重新搭环境，CUDA 版本不匹配、模型文件损坏｜依据：「某算力项目群」2026-02

9. 分支变体

  • 云端上游渠道：官转 vs 中转 vs AI Gateway，重点比价格、速度、稳定性、缓存支持
  • 自部署/第三方托管模型：必须做质量 bench 与官方 trace/指纹对照，确认不是量化弱智版
  • 客户本地部署：按客户硬件（国产卡、4090/5090 等）评测与测速，结论用于报价与选型
  • OCR/文档解析：用真实业务文档评测集，指标含页/秒、表格、公式、格式还原
  • 工具类（AI 编程工具、编辑器、设计转代码）：以用量、效果对比为主，风险低，可简化报告
  • SaaS API 采购（财务软件、企业数据）：先谈成本与采购，再开账号评测

10. 待确认问题

  • 模型供应商与评测负责人由谁担任？是否与模型网关研发合并？
  • 评测预算上限（单次/月度）多少，由谁审批？
  • 固定评测集（对话、OCR、生图）由谁建设、多久更新一次？
  • 是否设立固定的 API 评测周会？
  • 成本/折扣核算表的对内/对外隔离规则是否需要成文？
RND-69模型定价、倍率与成本价配置待优化240

状态：待优化｜证据：有证据（卡片 14 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：新模型上架、上游调价/折扣开通或到期、峰谷分时计价上线、汇率或倍率决策变更时，把成本价换算成对外价，并同步到 AIAPI、LeapCore/LeapAll NewAPI、v5 网关及客户本地网关
  • 负责人：主责——模型价格维护人（当前：柯逸飞·推断待确认）；协同——AIAPI 上游成本维护（当前：杨明学、吴世豪·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 价格变更登记 → ② 核成本价（四价、阶梯/分时、汇率） → ③ 定倍率与对外价 → ④ 测试服配置 → ⑤ 账单级验价 → ⑥ 生产及各下游同步 → ⑦ 通知产品/财务并更新台账
  • 交付结果：已生效且验价通过的各网关价格配置；更新后的“模型价格台账”（成本价、倍率、对外价、生效日、核价人）及变更记录
  • 状态依据：已有价格表、价格查询 skill 和“成本×倍率”的惯例，但没有成文定价规则和变更单；2026-06～10 约 40 次以上价格“不对”返工（缓存价漏配、未配价模型按默认价静默上线、多乘系数、汇率口径不一），期望价格只在群里口头同步

1. 场景判定

  • 触发条件：上游公告调价/折扣/峰谷计价；新模型或新渠道上架；折扣到期；汇率口径调整；产品决定调整档位倍率；行业版功能需要专用模型单独计费
  • 典型说法：「检查一下价格是否是成本价×倍率」「后天有个定时 hotfix 要发」「调价公式准备好了吗，得提前上好做测试」「按一篇报告上限倒推倍率」
  • 判断问题：这次变的是“价格/倍率/汇率”本身吗？如果只是换渠道或换档位模型、价格不变，走 RND-71
  • 不归本流程管：新模型/渠道的技术接入与可用性验证 → 请走 RND-67；档位模型路由与渠道切换 → 请走 RND-71；扣费准确性与账单对账 → 请走 RND-70；财务口径的成本价/汇率维护与成本收入核对 → 请走 FIN-28（模型成本价、计价倍率维护与成本收入核对）；对外售价测算、倍率调整与对外价格表同步 → 请走 X-PRD-22（模型/API 售价、倍率调整与对外价格表同步）；LeapOne 分站模型上线定价规则 → 请走 OPS-02（模型上线与定价规则）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
价格维护人 登记变更、维护台账、配置 LeapCore/v5 价格、发起验价 R 模型价格维护人（当前：柯逸飞·推断待确认）
上游成本维护 获取官方价/折扣，配置 AIAPI 成本价与计价公式 R AIAPI 上游成本维护（当前：杨明学、吴世豪·推断待确认）
LeapAll 计费 同步 LeapAll 网关价格与钱包计费 R LeapAll 计费研发（当前：邓乾·推断待确认）
客户本地网关 同步客户本地部署网关价格 R 客户端/项目研发（当前：李铭熙·推断待确认）
定价决策 拍板倍率、折扣取舍、汇率口径 A 研发负责人/CTO（当前：丁震宇·推断待确认）
产品定价 提出档位倍率需求、维护对外价格表、行业版倒推倍率 C 产品总监（当前：杨萌·推断待确认）
计费逻辑 计费公式与网关实现评审 C Leap 研发负责人（当前：王皓南·推断待确认）
验价 测试服账单级复测，预期 vs 实际 R 测试负责人（当前：张东郅·推断待确认）
财务 确认汇率与成本口径，接收变更通知 C 财务专员（当前：待指定）

3. 办之前请准备

  • 上游官方价格页、公告或商务书面报价（输入、输出、缓存读、缓存写、阶梯、峰谷时段、按次/按秒）
  • 折扣信息：折扣率、生效与到期日期、所属主体账号（鼎慧/模态）
  • 当前适用的倍率与汇率口径（以价格台账为准）
  • 受影响网关清单：AIAPI、LeapCore 云端 NewAPI、LeapAll NewAPI、v5 网关、客户本地 NewAPI
  • 产品侧目标：对外价，或单次任务收费上限（行业版倒推倍率时还需样本任务的实际消耗）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在价格台账新建变更记录：来源、模型、渠道、生效时间、涉及网关 价格维护人（产品、上游成本维护也可发起） 获知变更当日 多维表格“模型价格台账” 变更记录 🔧飞书固化
2 核成本价：按官方文档填四价及阶梯/分时/按次规则，海外模型按统一汇率折算，注明主体账号 上游成本维护 登记后 1 个工作日内；上游调价须在生效前 2 个工作日完成 官方价格页、cost-analysis、价格查询 skill 成本价记录 🤖+👤
3 按规则算对外价（默认成本×档位倍率；官方原价类、RaaS 类单列）；非默认倍率提交审批 价格维护人；定价决策人审批 核价后 1 个工作日内 台账公式、飞书审批 对外价、审批记录 🤖+👤
4 先在测试服配置：AIAPI 配成本价，LeapCore/v5 配对外价（倍率并入价格，倍率字段保持 1），LeapAll 同步；峰谷/阶梯写公式；代码内配置走 PR 上游成本维护、价格维护人、LeapAll 计费研发 审批后 1 个工作日内 NewAPI 后台、v5 代码 PR 测试服配置 👤人工判断
5 账单级验价：用固定请求集（含高缓存命中、长上下文、生图/按次）跑数，比对预期价与实际扣费，误差超 1% 退回步骤 3 测试负责人 配置后 1 个工作日内 测试服、账单导出、对账脚本 验价报告 🤖自动化
6 上生产并同步所有下游（含客户本地网关）；折扣到期类提前建定时 hotfix 任务并写入发版通知 价格维护人、客户本地网关维护 按生效时间；定时 hotfix 提前 2 个工作日建任务 NewAPI、Gitea、飞书任务 生产配置 🔧+👤
7 生产抽测 1 次；在通知群发布变更（模型、旧价→新价、生效时间），@产品与财务；台账状态改为“已生效” 价格维护人 上线后 2 小时内 飞书群机器人、台账 变更通知 🔧+🤖

5. 交付物与模板

  • 交付物：模型价格台账（唯一事实来源）、价格变更审批记录、验价报告、更新后的对外价格表
  • 建议模板/表单：台账字段——模型名、模型 ID、渠道、渠道类型（官方/官转/中转/自部署）、主体账号、计价方式（token/按次/按秒）、输入价、输出价、缓存读价、缓存写价、阶梯/分时规则、币种、汇率、折扣率、折扣到期日、成本价、档位、倍率、对外价、生效日期、已配置网关、核价人、验价人、审批人、状态

6. 异常与升级

  • 未配价格的模型被下发上线 → 立即隐藏或禁用该模型，补价验价后再开放 → 当日报研发负责人
  • 验价误差超 1% 或出现“多乘系数” → 回退测试服配置，退回步骤 3 → 1 个工作日内修正
  • 生产发现价格错误 → 1 小时内回退到上一版价格，评估多收/少收影响后转 RND-70、FIN-29 → 当日报研发负责人与财务
  • 上游价格或缓存价查不到 → 向渠道商务索取书面报价，未拿到前不上架 → 2 个工作日未拿到报研发负责人
  • 折扣到期临近未建 hotfix → 台账在到期前 5 个工作日自动提醒 → 2 个工作日未处理升级研发负责人

7. 衡量指标

  • 价格差错率：生产发现的价格错误次数 / 价格变更次数，目标 ≤ 5%
  • 变更生效及时率：在上游生效时点前完成生产配置的比例，目标 100%
  • 台账一致性：脚本每日比对各网关价格与台账，不一致项目标 0
  • 变更周期：登记到生产生效的工作日，目标 ≤ 3 天

8. 低效诊断

  • 现象：缓存价漏配、未配价模型静默上线，价格错误多由用户或测试事后发现｜依据：「Leap产研测」2026-06、「AI API」2026-07
  • 现象：汇率口径多种并存（固定值、实时汇率、按充值时兑换价），每次配置各自理解｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08、「AI API」2026-08
  • 现象：同一模型要在 3～4 个网关分别手工配置，多个 NewAPI 版本并存｜依据：「鼎慧产研决策部」2026-06、「AI API」2026-07
  • 现象：期望价格只在群里口头同步，代码即事实来源，决策与配置错位、倍率记忆与实际不一致｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：折扣到期的定时 hotfix 依赖个人记忆，差点漏发｜依据：「Leap产研测」2026-09
  • 现象：行业版专用模型倍率因模型更换重算 3 次以上，产品多次催问进度｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：价格维护职责在交接中不清，“谁在调倍率”反复被问｜依据：「Leap产研测」2026-06

9. 分支变体

  • LeapCore：倍率并入价格，倍率字段为 1，便于下游自动同步
  • LeapAll：原价×倍率，在 LeapAll NewAPI 单独配置
  • LeapPPT：按 RaaS 收费另算倍率，含分润
  • 客户本地部署网关（如客户A）：继承 LeapCore 云端价，需单独同步并确认适用倍率
  • 官方原价模型：按官网原价配置，不加倍率
  • 峰谷分时：需网关公式支持，仅工作日等规则写入台账；上游生效前一个周末配好测好
  • 折扣到期：建定时 hotfix 任务，按日期生效
  • 行业版专用模型：跑样本报告取实际消耗，按“单篇目标收费上限 / 平均消耗”倒推倍率；隐藏模型名固定，底层可换；测算类按工具调用次数计费
  • 企业客户单独倍率：审批后单设分组倍率

10. 待确认问题

  • 价格维护主责是否明确为一人？AIAPI 成本价与 LeapCore 对外价是否分两人维护？
  • 默认倍率现行口径是多少（9 月后部分档位已调为 2.5）？各档位、各产品线倍率由谁拍板？
  • 海外模型汇率是否固定为 7？是否需要与财务按季度复核？
  • 价格事实来源放多维表格还是代码仓库？若以代码为准，期望价格如何走工单？
  • 验价误差阈值 1% 是否合适？验价是否必须由测试负责人执行？
  • 价格变更是否需要财务会签？
RND-70计费准确性验证与账单/缓存对账待新建135

状态：待新建｜证据：有证据（卡片 7 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨3 × 险5

  • 适用场景：计费/扣费/预扣功能上线前提测；用户或内部发现扣费异常；新模型/新折扣上线后要对照上游账单核实；缓存命中率异常；需要按主体账号归集模型成本
  • 负责人：主责——计费测试与对账负责人（当前：张东郅·推断待确认）；协同——计费研发（当前：邓乾、柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、AIAPI 上游成本维护（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提测/异常登记 → ② 准备测试账号与观测点 → ③ 固定请求集跑数 → ④ 比对平台扣费、配置价与上游账单 → ⑤ 定位差异 → ⑥ 修复与退补 → ⑦ 周度对账报告
  • 交付结果：计费验证报告（预期 vs 实际）；差异处理记录（含退补决定）；每周上游账单与平台扣费对账表；按主体归集的模型成本表
  • 状态依据：计费提测无规范，对账在 2026-05 提出后被推迟；2026-06 生图/视频未做预扣，失败仍扣费，视频功能临时下线；2026-10 仍靠临时构造请求对账，才发现缓存费用无折扣

1. 场景判定

  • 触发条件：计费、预扣、退费、额度相关功能提测；用户反馈“几个字扣好几块”“简单对话花一块多”；账单异常偏高；缓存命中率低于目标；新模型/新折扣上线满 1 周；月末成本归集
  • 典型说法：「计费相关没有精确测过吧」「就算多算，也不能少算」「缓存计费对账是吧」「没做生图/视频的预扣款」
  • 判断问题：问题是“扣得对不对 / 账对不对”吗？如果是价格本身配错，先走 RND-69 改价，再回本流程复核
  • 不归本流程管：价格与倍率的制定和配置 → 请走 RND-69；用户退补款的财务处理 → 请走 FIN-29；网关月度账单导出与财务对账 → 请走 FIN-26；云/模型成本按项目归集台账 → 请走 FIN-30；多主体业务归属规则 → 请走 FIN-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
计费测试与对账 设计用例、跑数、三方比对、出报告与周报 R 测试负责人（当前：张东郅·推断待确认）
计费研发 提供计费方案、接口说明、观测点、测试账号，修复问题 R 计费研发（当前：邓乾、柯逸飞·推断待确认）
计费口径决策 定扣费口径（按上游返回扣费还是按配置价计算）、预扣与退费规则 A Leap 研发负责人（当前：王皓南·推断待确认）
客户端 余额拦截、预扣显示、缓存前缀与 cache key C Agent 客户端研发（当前：岳阳·推断待确认）
上游成本 导出上游控制台账单、与渠道核实差异 C AIAPI 上游成本维护（当前：杨明学·推断待确认）
退补拍板 重大差异处置、超阈值退补决定、主体路由规则 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
发现人 登记异常扣费反馈，提供账号、时间、模型、请求 ID R 内部成员/测试/客服（当前：不限定·推断待确认）
财务 接收对账报告、主体成本归集入账 I 财务专员（当前：待指定）

3. 办之前请准备

  • 计费技术方案与面向测试的接口说明（扣费、冻结、解冻、退费的观测点）
  • 专用测试账号与限额 Key（不使用生产 Key）
  • 当前价格台账版本（成本价、倍率、缓存价）
  • 上游控制台账单导出权限或导出 CSV
  • 固定请求集：短对话、长上下文、高缓存命中（≥90%）、生图、视频、搜索 skill、失败/超时请求
  • 异常反馈信息：账号、时间、模型、请求 ID、扣费截图

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 计费功能提测或异常反馈登记为工单，注明产品线、模型、时间、请求 ID 计费研发 / 发现人 提测时；异常发现后 2 小时内 LEAP 工单 工单 🔧飞书固化
2 提交提测材料：接口说明、观测点、测试账号、单测记录、预扣/退费规则；材料不齐测试可拒收 计费研发 提测时 工单附件 提测材料 🔧飞书固化
3 用固定请求集在测试服跑数，按台账价计算每笔预期扣费 计费测试与对账 提测后 1 个工作日内 对账脚本 跑数记录 🤖自动化
4 三方比对：平台扣费 vs 配置价预期 vs 上游账单；缓存命中率单列 计费测试与对账；上游成本维护提供账单 跑数后 1 个工作日内（上游账单按 T+1） 账单 CSV、脚本 差异表 🤖自动化
5 定位差异原因：价格配置、缓存价/前缀/cache key、渠道类型、预扣冻结、失败未退、主体路由 计费研发、客户端研发 差异出现后 2 个工作日内 网关日志、请求追踪 根因结论 👤人工判断
6 修复并回归；涉及用户多扣或少扣的，汇总明细提交退补决定 计费研发；计费口径决策人审批（超阈值升级 CTO） 根因确认后 2 个工作日内 PR、工单、飞书审批 修复记录、退补单 👤人工判断
7 上线后每周自动对账出周报；月末按主体（鼎慧/模态）出成本归集 计费测试与对账（脚本） 每周一 12:00 前；每月 5 日前 机器人推送、多维表格 对账周报、主体成本表 🤖自动化

5. 交付物与模板

  • 交付物：计费验证报告、差异处理工单、退补审批记录、对账周报、主体成本归集表
  • 建议模板/表单：对账表字段——日期、产品线、主体账号、模型、渠道、请求数、输入/输出/缓存读/缓存写 token、缓存命中率、配置价预期金额、平台扣费、上游账单金额、差异额、差异率、原因分类、处理人、状态
  • 计费提测清单字段：计费方案链接、接口说明、观测点、测试账号、预扣/冻结规则、超时解冻时长、失败退费规则、已知限制

6. 异常与升级

  • 平台扣费低于上游成本（亏损）→ 当日通报研发负责人/CTO，必要时暂停该模型或功能 → 研发负责人/CTO 4 小时内决定
  • 用户被多扣费 → 汇总明细，计费口径决策人审批（超阈值升级研发负责人/CTO）后退补并转 FIN-29 → 3 个工作日内完成
  • 失败任务仍扣费或预扣不退 → 按 RND-72 临时降级该功能 → 修复验证前不恢复
  • 上游账单与配置价不符 → 上游成本维护向渠道书面确认，改价走 RND-69 → 5 个工作日内给结论
  • 缓存命中率连续 3 天低于目标 → 客户端研发排查前缀稳定性与 cache key、网关渠道类型 → 1 周内给出方案
  • 升级拍板条件（A（升级））：出现平台扣费低于上游成本需暂停模型/功能、单次退补金额超过 [阈值待财务确认]、或需新定/变更鼎慧/模态主体路由规则时，由计费口径决策人当日提交研发负责人/CTO 拍板；其余差异与退补由计费口径决策人决定

7. 衡量指标

  • 对账差异率：|平台扣费 − 预期扣费| / 预期扣费，目标 ≤ 2%
  • 内部发现率：计费问题由内部对账发现的占比，目标 ≥ 80%
  • 缓存命中率：按模型日均，DeepSeek 目标 ≥ 85%
  • 计费工单闭环时长：登记到修复上线的工作日，目标 ≤ 5 天

8. 低效诊断

  • 现象：计费提测材料只面向内部接口，测试拿不到观测点，只能黑盒推测｜依据：「Leap产研测」2026-05
  • 现象：skill 上游成本未计入总账，对账在提出后被推迟｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：生图/视频未做预扣，失败仍扣费，最终整块功能临时下线｜依据：「Leap产研测」2026-06
  • 现象：用户先发现异常扣费，修一轮后复核仍偏高｜依据：「模态AI探索小分队」2026-06
  • 现象：缓存命中率低时多次猜测原因，缺排查清单｜依据：「AI API」2026-07
  • 现象：配置价与上游实价不符（缓存无折扣），靠临时构造请求事后发现｜依据：「AI API」2026-10
  • 现象：调用走哪个主体账号靠口头约定，成本归集口径未定｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 文本 LLM：按 token 计费，缓存读为大头，重点核缓存价与命中率
  • 生图/视频/搜索 skill：先预扣再确认，失败须退回，超时自动解冻；视频无 tokenizer 时按输入素材与上游返回数据计费
  • 缓存机制差异：GPT/DeepSeek 自动缓存；Claude 需显式写缓存；网关渠道类型配错会过滤缓存参数（如 Anthropic 模型挂在 OpenAI 类型渠道下）
  • 主体归集：工程版插件及原 SaaS API 走鼎慧账号，标品与行业版走模态账号；统一余额但标注扣费来源
  • LeapCore 企业：按 API Key 记账

10. 待确认问题

  • 计费对账主责是测试负责人还是计费研发？财务是否参与每周对账？
  • 扣费口径最终是“按上游返回扣费”还是“按配置价计算”？
  • 对账差异率 2%、缓存命中率 85% 的目标是否可行？
  • 退补的审批人和金额阈值是多少？
  • 鼎慧/模态主体路由规则是否已有书面确认？
RND-71模型档位路由与渠道切换变更待优化240

状态：待优化｜证据：有证据（卡片 9 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：因成本变化、模型升级或故障恢复后调整，需要新增/切换/删除上游渠道，或调整 LeapCore/LeapAll 经济/标准/专家档对应模型与思考强度、生图主通道与 fallback 时启动（计划内变更）
  • 负责人：主责——模型路由变更执行人（当前：柯逸飞·推断待确认）；协同——AIAPI 渠道维护（当前：杨明学·推断待确认）、LeapAll 计费研发（当前：邓乾·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿、杨云峰·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提变更单 → ② 方案拍板 → ③ 先加新渠道不动旧 → ④ 测试服切换 → ⑤ 回归测试 → ⑥ 窗口内切生产并盯日志 → ⑦ 同步价格与下游 → ⑧ 发公告保留回滚点 → ⑨ 观察期后下线旧渠道
  • 交付结果：已完成并验证的路由/渠道变更；变更单（含回归结果、回滚点）；更新后的“渠道-模型-档位”台账；变动通知群公告
  • 状态依据：已有“测试服先行”惯例和 AI API 变动通知群，但无变更单、变更窗口与回滚预案；2026-06～08 出现图片请求被路由到不支持识图的模型导致全线报错、切错测试环境用户、未通知测试直接切生产等事故

1. 场景判定

  • 触发条件：产品/技术决定调整档位模型或思考强度；上游涨价、折扣变化需换渠道；模型版本升级；渠道下线或欠费恢复后回切；生图通道调整；网关生产服 DNS 切换
  • 典型说法：「先切测试服，然后让测试测一下」「你先加新的别改老的」「下次切之前先喊测试，别自己直接切」「普通情况默认便宜 fallback 就行」
  • 判断问题：线上是否正在故障？正在故障需立即止血 → 走 RND-72；能按计划排期的切换走本流程
  • 不归本流程管：上游突发故障的应急切换与降级 → 请走 RND-72；新模型/新渠道首次接入验证 → 请走 RND-67；上游供应商选型评测 → 请走 RND-68；价格/倍率调整 → 请走 RND-69；非模型类生产变更 → 请走 RND-58

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
变更执行 填变更单、测试服/生产切换、同步渠道台账 R 模型路由变更执行人（当前：柯逸飞·推断待确认）
方案拍板 批准档位模型、渠道、窗口；决定回滚 A 研发负责人/CTO（当前：丁震宇·推断待确认）
产品 提出档位调整需求，更新对外价格表与说明 R 产品总监（当前：杨萌·推断待确认）
AIAPI 渠道 新增/切换上游渠道，发变动通知 R AIAPI 渠道维护（当前：杨明学·推断待确认）
LeapAll 同步 LeapAll 后端与 NewAPI 同步切换 R LeapAll 计费研发（当前：邓乾·推断待确认）
客户端适配 接口类型（chat/responses）、思考参数、识图能力兼容 C Agent 客户端研发（当前：岳阳·推断待确认）
生产配置 LeapUpdate 下发配置的生产修改 R 后端/运维（当前：宋祺睿、杨云峰·推断待确认）
回归测试 测试服与生产回归，给放行结论 R 测试负责人（当前：张东郅·推断待确认）
生图通道 生图主通道、fallback、演示通道维护 R LeapPPT 研发（当前：马漳毓·推断待确认）
下游负责人 客户网关、字字可研等下游按通知迁移 I 各下游研发（当前：待指定）

3. 办之前请准备

  • 变更目标：产品线、档位、原模型/渠道 → 新模型/渠道、思考强度、接口类型
  • 新渠道能力核对：识图、工具调用、长上下文、缓存、QPS/限流
  • 新旧成本对比，是否需改价（需改价同时走 RND-69）
  • 影响清单：AIAPI、LeapAll 后端、LeapAll NewAPI、LeapCore NewAPI、LeapUpdate 下发、客户本地 NewAPI
  • 环境清单：测试服、生产服编号及对应用户分组（防止切错）
  • 回滚方案：旧渠道保留、旧配置快照
  • 当日有生产操作权限的人员在岗确认

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交变更单：目标、原因、影响范围、窗口、回滚点、通知对象 变更执行人 / 需求方（产品） 计划变更前 1 个工作日 飞书审批 / LEAP 工单 变更单 🔧飞书固化
2 方案拍板；涉及价格同步发起 RND-69 研发负责人 提交后 4 个工作小时内 飞书审批 审批结论 👤人工判断
3 先新增渠道/模型，不改不删旧配置；用脚本核对目标机器与用户分组 AIAPI 渠道维护、变更执行人 审批后当日 NewAPI 后台、核对脚本 新渠道就绪 🤖自动化
4 测试服切换，同步改 LeapUpdate 测试配置，@测试 变更执行人、生产配置 审批后 1 个工作日内 测试服、LeapUpdate 测试服生效 👤人工判断
5 跑固定回归集：文本、图片输入、生图、搜索、PPT、长输出、思考开关、扣费；全部通过才放行 测试负责人 测试服切换后 1 个工作日内 自动化回归脚本 回归报告 🤖自动化
6 在约定窗口（避开工作日高峰和客户演示）切生产，盯错误日志 30 分钟 变更执行人、生产配置 回归通过后按窗口 生产网关、日志 生产生效 👤人工判断
7 LeapAll 与客户本地网关同步切换；价格台账、对外价格表同步 LeapAll 计费研发、产品 生产切换后 1 个工作日内 NewAPI、价格台账 同步记录 🔧+👤
8 在变动通知群发公告：变更内容、影响范围、下游截止时间、回滚方式，@测试与产品 变更执行人 / AIAPI 渠道维护 生产切换后 1 小时内 飞书群机器人 公告 🔧+🤖
9 观察期满确认所有下游已迁移，再下线旧渠道；关闭变更单 变更执行人 观察期 ≥ 3 个工作日 渠道台账、工单 变更关闭 👤人工判断

5. 交付物与模板

  • 交付物：变更单、回归报告、变更公告、更新后的渠道-模型-档位台账
  • 建议模板/表单：变更单字段——变更编号、产品线、环境（测试/生产）、档位、原模型/渠道、新模型/渠道、思考强度、接口类型、是否改价、影响下游清单、计划窗口、执行人、测试人、回滚点、通知对象、实际生效时间、状态
  • 渠道台账字段：渠道名、来源（官方/官转/中转/自部署）、主体账号、支持能力、QPS、价格、余额、用途（普通/白名单/演示/fallback）、状态、负责人

6. 异常与升级

  • 回归不通过 → 不得上生产，退回步骤 3 → 当日告知研发负责人
  • 生产切换后错误率上升或出现客诉 → 15 分钟内回滚到旧配置 → 通报研发负责人并转 RND-72
  • 切错环境或用户分组 → 立即回切并核对机器备注 → 当日复盘入档
  • 有生产权限的人员不在岗 → 推迟窗口，不得由无权限人员绕过 → 研发负责人指定备岗
  • 下游未在截止时间前迁移 → 变更执行人点名催办 → 逾期 1 个工作日报研发负责人

7. 衡量指标

  • 变更事故率：引发回滚或客诉的变更数 / 总变更数，目标 ≤ 5%
  • 变更单覆盖率：生产路由变更中有变更单的比例，目标 100%
  • 回滚时长：发现异常到回滚完成，目标 ≤ 15 分钟
  • 下游迁移按期率：目标 100%

8. 低效诊断

  • 现象：切换后只验证“跑通一次”即判定稳定，图片请求被路由到不支持识图的模型导致全线报错，多人同时改路由｜依据：「Leap产研测」2026-06
  • 现象：测试服推理参数改动无评审，经济/标准档对话全部报错，事后查不到谁改的｜依据：「Leap产研测」2026-07
  • 现象：未通知测试直接切生产；换一次模型需同时改 5 处｜依据：「AI API」2026-07
  • 现象：切换时选错用户分组，测试环境实际未切；生产操作权限仅两人，请假即延误｜依据：「AI API」2026-08
  • 现象：档位模型与是否改价在群里多人混说，反复改动｜依据：「Leap产研测」2026-08
  • 现象：生图渠道现状散在个人手里，渠道被替换无人知情，演示当天临时加 fallback｜依据：「LeapPPT」2026-05
  • 现象：同一厂商有两个价格不同的模型，需事后提醒选对价格档｜依据：「AI API变动通知」2026-06

9. 分支变体

  • LeapCore 三档切换：测试服（50/51）→ 生产（102），生产需改 LeapUpdate 下发配置，LeapAll 同步切
  • 测试服推理配置：各家协议对思考参数要求不同（如关闭思考应不传参数），配置保存前校验
  • 生图渠道：效果第一，其次速度、价格；白名单/演示账号走稳定通道，普通用户走低价 fallback
  • 字字可研等下游：通过变动通知群给出迁移截止时间，旧模型保留作备用
  • 网关生产 DNS 切换：低峰时段（晚间/凌晨），旧服务保留后回收

10. 待确认问题

  • 变更执行主责是否统一到一人？AIAPI 层与 LeapCore 层是否分设？
  • 变更单走飞书审批还是 LEAP 工单？变更窗口时段如何定义？
  • 生产操作权限是否扩大到至少 3 人（含备岗）？
  • 观察期 3 个工作日后下线旧渠道是否合适？
  • 是否推行“下游统一模型别名，由 AIAPI 层路由”，减少多点修改？
RND-72上游模型故障告警响应与降级待优化375

状态：待优化｜证据：有证据（卡片 11 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨5 × 险5

  • 适用场景：告警机器人推送“AI 上游连续失败/模型探测异常”、官方状态页发布事故，或用户/测试反馈超时、502/429/503、降智、余额耗尽导致不可用时启动
  • 负责人：主责——AI 网关值班人（当前：杨明学·推断待确认）；协同——LeapCore 网关研发（当前：柯逸飞·推断待确认）、V5 网关备用维护（当前：吴世豪·推断待确认）、Agent 客户端研发（当前：岳阳·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、字字可研研发（当前：侯怡辰、陈锦杰·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 告警/反馈 → ② 值班认领 → ③ 定级 → ④ 定位故障层级 → ⑤ 止血（切备线/降级/禁用） → ⑥ 内外通报 → ⑦ 恢复验证 → ⑧ 复盘
  • 交付结果：在时限内止血并恢复的服务；故障工单（定级、根因、处置、时间线）；对内对外通知；P0/P1 复盘记录
  • 状态依据：已有“临时状态助手”“AI 上游连续失败告警”等机器人，但无值班、分级与处置手册；2026-08 起告警后约 1 小时才有人响应，某生产功能失效约两周才被发现

1. 场景判定

  • 触发条件：机器人告警（连续失败 ≥ 3 次、探测异常）；官方状态页事故；用户/测试反馈“网络异常”“标准专家都挂了”；上游余额不足、鉴权失败、限流
  • 典型说法：「这是 aiapi 出问题了？」「标准专家怎么都不可用了」「主要是没配 fallback」「换模型五分钟就应该换完了」
  • 判断问题：故障是否来自上游模型/渠道/网关层？如果是自家服务（数据库、部署）故障 → 走 RND-75
  • 不归本流程管：自家服务线上故障 → 请走 RND-75；告警规则治理与降噪 → 请走 RND-78；计划内渠道/档位切换 → 请走 RND-71；余额预警与充值机制 → 请走 RND-73；扣费退补 → 请走 RND-70

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
值班人 认领、定级、定位、止血、通报 R AI 网关值班人（当前：杨明学·推断待确认）
备岗值班 主值班 15 分钟未响应时接手；产品线网关排查 R LeapCore 网关研发（当前：柯逸飞·推断待确认）、V5 网关备用维护（当前：吴世豪·推断待确认）
决策 P0/P1 启用贵价备线、功能禁用、对外口径批准 A 研发负责人/CTO（当前：丁震宇·推断待确认）
客户端 错误追踪、重试/超时、功能开关下发 R Agent 客户端研发（当前：岳阳·推断待确认）
生产运维 生产日志、环境变量、hotfix 上线 R 后端/运维（当前：宋祺睿·推断待确认）
字字可研 字字可研告警响应与模型切换 R 字字可研研发（当前：侯怡辰、陈锦杰·推断待确认）
客户通知 汇总客诉、对外口径、客户群通知 R 产品总监（当前：杨萌·推断待确认）
测试 恢复后复测 R 测试负责人（当前：张东郅·推断待确认）
反馈人 按故障反馈模板填写真实模型、环境、时间、请求 ID R 内部成员/测试/客服（当前：不限定·推断待确认）

3. 办之前请准备

  • 告警卡片或反馈信息：真实模型名（不是档位别名）、环境、时间、请求 ID、现象截图
  • 档位-真实模型-渠道映射表（见 RND-71 渠道台账）
  • 预设备线清单及成本差（如官方渠道比主渠道贵数倍）
  • 功能开关位置：Agent 配置下发、灰度/止血开关
  • 上游厂商联系人与工单入口
  • 值班人事先开通的生产日志访问权限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 告警卡片自动 @ 当班值班人并建故障工单；人工反馈须按模板填写 机器人 / 反馈人 实时 告警机器人、飞书表单 故障工单 🔧+🤖
2 认领并在群内回复“已认领” 值班人 告警后 15 分钟内 飞书群 认领记录 🔧飞书固化
3 定级：P0 生产全量不可用或客户演示中；P1 单档位/单功能不可用；P2 测试环境或偶发 值班人 认领后 15 分钟内 处置手册 故障级别 👤人工判断
4 定位层级：官方上游 / 渠道（余额、限额、被墙、路由）/ AIAPI / 产品线网关 / 客户端 值班人、LeapCore 网关研发、客户端研发 P0 30 分钟内；P1 2 小时内 网关日志、错误追踪、官方状态页 根因初判 🤖+👤
5 止血：切预设备线；不能切则功能降级/禁用并给友好提示；贵价备线由研发负责人确认 值班人；客户端研发下发开关 P0 1 小时内；P1 4 小时内 NewAPI、配置下发 止血完成 👤人工判断
6 通报：研发群发结论（模型、影响、预计恢复）；涉及客户由产品发客户通知 值班人、产品总监 止血后 30 分钟内 飞书群、通知模板 通报记录 🔧+🤖
7 向上游提交工单或联系商务；恢复后回切主线并复测 值班人、测试负责人 上游恢复后 2 小时内 厂商工单、回归脚本 恢复确认 👤人工判断
8 P0/P1 复盘：时间线、根因、影响、改进项（监控覆盖、备线、开关） 值班人 恢复后 2 个工作日内 复盘模板 复盘文档 🔧飞书固化

5. 交付物与模板

  • 交付物：故障工单、通报记录、复盘文档、按错误类型编写的处置手册
  • 建议模板/表单：故障反馈表字段——反馈人、产品线、环境、档位及真实模型、时间、请求 ID、错误码/现象、影响范围、截图
  • 复盘字段：级别、开始/发现/认领/止血/恢复时间、根因分类（余额/限额/安全围栏/网络被墙/路由/上游宕机/配置）、处置、影响、改进项与负责人

6. 异常与升级

  • 主值班 15 分钟未认领 → 机器人 @ 备岗 → 30 分钟仍未认领升级研发负责人
  • P0 1 小时未止血 → 研发负责人直接决策（启用贵价备线或全局禁用）
  • 原因为余额不足 → 按 RND-73 加急充值，同时先切备线，不等充值到账
  • 客户演示/大会进行中 → 一律按 P0 处理，优先切最稳渠道
  • 开发/测试环境告警 → 只记录不 @ 所有人，工作时间内处理

7. 衡量指标

  • 认领时长：告警到认领，目标 ≤ 15 分钟
  • 止血时长：P0 ≤ 1 小时，P1 ≤ 4 小时
  • 用户先于监控发现的故障占比：目标 ≤ 20%
  • 告警误报率：误报数 / 告警数，目标 ≤ 10%
  • P0/P1 复盘完成率：目标 100%

8. 低效诊断

  • 现象：故障反馈到修复依赖群内 @ 和限时催促，归因在 bug/上游/降智/中转之间反复｜依据：「Leap产研测」2026-05
  • 现象：上游换接口在另一个群讨论，研发与产品不知情，客诉爆发后才知道｜依据：「Leap产研测」2026-08
  • 现象：告警后约 1 小时才有人响应；生产某功能失效约两周未被发现｜依据：「AI API」2026-08、「AI API」2026-09
  • 现象：新上架模型未加入探测；探测部署在不稳定网络环境，反复误报刷屏；反馈不说明模型，无法直接查上游｜依据：「AI API」2026-08
  • 现象：开发/测试环境告警同样 @ 所有人，告警名称与真实原因不符｜依据：「工程咨询产研」2026-08
  • 现象：上游欠费时“充值还是换渠道”无人负责，业务方反复追问｜依据：「工程咨询产研」2026-07
  • 现象：上游故障统一显示“网络异常”，未配 fallback｜依据：「Leap产研测」2026-10
  • 现象：功能禁用只在 Agent 配置生效、UI 未同步，用户困惑｜依据：「跃迁AI总动员」2026-06

9. 分支变体

  • Leap/AIAPI 渠道：区分官方状态异常与自家探测异常；429 限流需判断在 AIAPI 层还是产品线网关层
  • 字字可研：告警机器人 120 秒内 3 次失败触发、30 分钟冷却；生产 @ 值班，非生产静默；欠费按字字可研现有《统一 AI 接入配额申请》文档（对应 RND-27 模型 API Key 与调用额度申请）申请额度后切换
  • 生图/视频/PPT/搜索：失败易误扣费，优先功能禁用 + 友好提示 + 自动退费
  • 客户本地部署（如客户A）：区分客户侧过载与内部问题，由研发负责人向客户通报结论
  • 灰度止血开关：开关嵌入后台由业务控制；有现成云产品的优先采购，不自建配置中心

10. 待确认问题

  • AI 网关“一主二备”如何排班？是否用飞书日历？非工作时间是否值守？
  • P0/P1/P2 定级标准与止血时限是否可行？
  • 贵价备线的启用权限能否下放给值班人（设成本上限）？
  • 对外客户通知由产品还是客服发出？模板由谁维护？
  • 监控探测目标能否随模型上架台账自动生成？由谁负责？
RND-73上游账户余额、凭证到期与 Token 消耗管控待新建72

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：产品依赖的上游模型账户（模型厂商官方账户、云厂商 A/B 的模型平台、算力平台、中转站等）与第三方服务凭证（如文档解析 Token）需要日常监控余额、到期和用量，以及内部测试需要额度 Key 时启动
  • 负责人：主责——上游账户与凭证管理员（当前：杨明学·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、计费研发（当前：邓乾·推断待确认）、CI/网关研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 账户与凭证入台账 → ② 设余额/到期阈值 → ③ 每日用量播报 → ④ 低于阈值预警 → ⑤ 充值审批与付款 → ⑥ 到账确认 → ⑦ 凭证到期前续期 → ⑧ 测试 Key 限额发放与回收 → ⑨ 月度复核
  • 交付结果：完整的上游账户与凭证台账；每日用量与余额播报；欠费中断为零；测试 Key 发放与回收记录
  • 状态依据：没有余额预警和账号归属，2026-01～03 多次在用户反馈后才发现欠费，部分账号由个人持有；2026-03 文档解析 Token 过期导致演示失效；2026-07 测试用生产 Key 短时间产生高额消耗后才口头约定申请限额账号

1. 场景判定

  • 触发条件：新开上游账户或第三方凭证；余额/额度低于阈值；凭证到期前 14 天；每日用量异常（较 7 日均值上涨 50% 以上）；内部测试/调试需要 Key
  • 典型说法：「上游账户没钱了」「先少量充点，我换备用渠道」「token 默认两三个月就自动过期了」「测试任务走申请拿一个限额的帐号」
  • 判断问题：是“账户余额/凭证/消耗”问题，而不是上游服务本身故障？余额耗尽已导致中断 → 先按 RND-72 止血，再回本流程补充值
  • 不归本流程管：上游故障止血 → 请走 RND-72；充值付款的财务审批与付款 → 请走 FIN-03；业务方/客户的 API Key 与额度申请 → 请走 RND-27；研发个人 AI 编码工具订阅 → 请走 RND-25；赠送/试用额度 → 请走 FIN-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账户与凭证管理 维护台账、设阈值、发起充值、跟踪续期、发放测试 Key R 上游账户与凭证管理员（当前：杨明学·推断待确认）
预算审批 充值预算、测试 Key 额度审批 A 研发负责人/CTO（当前：丁震宇·推断待确认）
用量监控 用量统计脚本、日报、异常排查 R Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）
凭证配置 新凭证替换、网关额度配置 R 计费研发（当前：邓乾·推断待确认）、CI/网关研发（当前：吴世豪·推断待确认）
财务 充值付款、发票、成本入账、参与月度复核 R 财务专员（当前：待指定）
业务使用方 反馈欠费、提交测试 Key 申请 R 各产品线研发与测试（当前：待指定）

3. 办之前请准备

  • 账户清单：服务商、主体（鼎慧/模态）、账号持有方式（应为公司账号）、凭据存放位置（密码管理器，不在聊天中传）
  • 每个账户关联的产品/服务及备用渠道
  • 余额查询方式（控制台/API）与用量统计口径
  • 凭证有效期与续期方式
  • 充值预算与付款渠道（按 FIN-03）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有上游账户与第三方凭证登记入台账；个人持有账号限期迁到公司账号 账户与凭证管理员 新开当日；存量 2 周内完成 多维表格 台账 🔧飞书固化
2 按 7 日平均消耗设余额阈值（不低于 7 天用量），设到期提醒（到期前 14 天） 账户与凭证管理员 登记时 台账、提醒机器人 阈值配置 🔧飞书固化
3 每日拉取各账户用量与余额，按产品线/主体出日报，异常上涨标红 用量监控（脚本） 每日 10:00 前 云厂商用量 API、网关统计、机器人 用量日报 🤖自动化
4 低于阈值自动加急预警，@管理员与产品线负责人 机器人 实时 飞书机器人 预警消息 🤖自动化
5 发起充值申请（账户、金额、用途、预计可用天数），审批后转财务付款 账户与凭证管理员；研发负责人审批 预警后 1 个工作日内 飞书审批 → FIN-03 充值单 🔧飞书固化
6 确认到账，更新台账余额，通知受影响产品线 账户与凭证管理员 付款后当日 控制台、台账 到账确认 👤人工判断
7 凭证到期前更换新凭证，配置到对应服务并验证功能 凭证配置研发 到期前 7 天内完成 配置中心/环境变量 续期记录 👤人工判断
8 内部测试 Key：提申请（用途、额度、有效期、渠道），在网关创建限额 Key、到期自动回收；优先用低价渠道测通再切 业务使用方申请；账户与凭证管理员发放；研发负责人审批 申请后 4 个工作小时内 飞书审批、NewAPI 限额 Key 🤖+👤
9 月度复核：余额、充值、消耗趋势、闲置凭证回收 账户与凭证管理员、财务 每月 5 日前 台账 月度复核表 👤人工判断

5. 交付物与模板

  • 交付物：上游账户与凭证台账、用量日报、充值审批记录、测试 Key 发放回收记录、月度复核表
  • 建议模板/表单：台账字段——服务商、账户类型（模型/文档解析/搜索等）、主体、账号归属、关联产品/服务、备用渠道、当前余额、日均消耗、可用天数、阈值、凭证到期日、续期方式、凭据存放位置、负责人、备岗、状态
  • 测试 Key 申请字段：申请人、用途、额度上限、有效期、允许渠道/模型、是否含长上下文或大规模压测

6. 异常与升级

  • 已欠费导致生产中断 → 先切备用渠道（RND-72），同时加急充值 → 研发负责人 1 小时内审批
  • 余额低于阈值 1 个工作日未充值 → 机器人再次提醒 → 升级研发负责人
  • 单 Key/单账户 2 小时用量超过日均 3 倍 → 自动限额或冻结，管理员核查来源 → 当日报研发负责人
  • 凭证已过期导致功能失效 → 用公司备用凭证顶替，不得长期使用个人凭证 → 2 个工作日内补正式凭证
  • 上游方反馈异常流量 → 查明来源 Key，暂停并通知使用人 → 当日处理

7. 衡量指标

  • 欠费中断次数：目标 0 次/月
  • 预警提前量：预警时剩余可用天数，目标 ≥ 7 天
  • 凭证过期导致的故障次数：目标 0
  • 公司账号持有率：上游账户中公司账号占比，目标 100%
  • 测试 Key 合规率：内部测试使用限额 Key 的比例，目标 100%

8. 低效诊断

  • 现象：模型账户欠费后才发现并临时充值，一个月内反复发生｜依据：「工程咨询产研」2026-01
  • 现象：生产欠费由用户反馈发现，充值依赖个人账号，业务方反复催促｜依据：「工程咨询产研」2026-03
  • 现象：用量靠人工登录查看，监控停留在个人待办｜依据：「鼎慧产研决策部」2026-03
  • 现象：充值请求在群内多次喊人；模型改用档位别名后，无法定位真实上游｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • 现象：第三方 Token 过期导致演示功能失效，此前提过更换未落实｜依据：「3.3 思政演示项目」2026-03
  • 现象：测试使用生产 Key 短时间高额消耗，事后才口头定规则，Key 私下发放｜依据：「AI API」2026-07、「AI API」2026-08

9. 分支变体

  • 鼎慧主体云厂商账号：工程版/字字可研等服务切到鼎慧账号后，按主体分别监控与对账
  • 字字可研模型欠费：已有《统一 AI 接入配额申请》文档，按 RND-27 通过 AIAPI 申请额度，替代直连账户
  • 文档解析等第三方 Token：有效期短（14 天到 3 个月不等），按台账提醒续期，统一用公司账号申请
  • 测试烧钱管控：测试 Key 设额度上限与有效期，长上下文/大规模压测需单独审批
  • 研发个人 AI 编码工具订阅与号池不在本流程，走 RND-25

10. 待确认问题

  • 上游账户与凭证管理员是否由 AIAPI 维护人兼任？备岗是谁？
  • 余额阈值按“7 天用量”是否合适？是否需要按账户单独设定？
  • 充值审批是否全部走 FIN-03？小额应急充值能否先付后补？
  • 目前仍由个人持有的账户有哪些？迁移时间表如何定？
  • 测试 Key 默认额度上限与有效期定多少？
RND-74NewAPI/AI 网关部署、升级与值守待优化96

状态：待优化｜证据：有证据（卡片 9 张 / 会话 5 个）｜优先级：频2 × 耗4 × 跨3 × 险4

  • 适用场景：新建 API 中转分站（如 LeapOne、OPC 社区网关、产品线专用站）、网关版本升级或安全漏洞修复、生产服迁移、新增反代层或协议兼容、网关维护人变更交接时启动
  • 负责人：主责——AI 网关负责人（当前：杨明学·推断待确认）；协同——网关备用维护（当前：柯逸飞、吴世豪·推断待确认）、基座研发负责人（当前：望政韬·推断待确认）、分站部署研发（当前：黄振锋·推断待确认）、LeapAll 部署（当前：邓乾·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求与容量评估 → ② 服务器申请 → ③ 按基线部署（反代超时、安全组） → ④ 部署检查 → ⑤ 功能测试与压测 → ⑥ 窗口内切换上线 → ⑦ 纳入监控与台账 → ⑧ 值守与交接
  • 交付结果：按基线部署并压测通过的网关实例；网关台账（实例、版本、域名、调用链拓扑、负责人）；升级/迁移记录；权限交接清单
  • 状态依据：已有《软件部署 SOP》和《1000 QPS 部署注意事项》，但反代超时、端口、密钥管理仍是口头约定；2026-06 多层反代未配超时导致整条链路超时；2026-07 升级窗口多次变更；2026-08 维护人变更时没有交接资料

1. 场景判定

  • 触发条件：业务要单独起一个 API 站；NewAPI 官方发布漏洞或新版本；生产服版本过旧需迁移；新增反代层；需要支持新协议（如 Anthropic Messages）；网关负责人或备岗变动
  • 典型说法：「要单独部署一个站，然后接你的上游」「每一层都得配超时」「新部署一个最新版本，代替原测试服」「资料有交接吗」
  • 判断问题：这次动的是网关的“实例/版本/架构/人员”，而不是某个模型的价格或路由吗？
  • 不归本流程管：模型价格配置 → 请走 RND-69；渠道/档位切换 → 请走 RND-71；上游故障响应 → 请走 RND-72；服务器/域名资源申请 → 请走 RND-23；通用压测方法 → 请走 RND-43；分站运营配置 → 请走 OPS-01；一般研发工作交接 → 请走 RND-85

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
网关负责人 方案、升级窗口、上线决策、台账与值守排班 R AI 网关负责人（当前：杨明学·推断待确认）
备用维护者 主负责人不在时接手，参与升级与值守 R 网关备用维护（当前：柯逸飞、吴世豪·推断待确认）
审批 需求、服务器预算、维护人指定 A 研发负责人/CTO（当前：丁震宇·推断待确认）
架构顾问 部署基线、高并发与安全配置评审 R 基座研发负责人（当前：望政韬·推断待确认）
需求方 提交网关需求单（用途、容量、上游） R 各产品线/业务方研发（当前：不限定·推断待确认）
部署执行 分站/产品线网关部署、改主题、代码纳管 R 分站部署研发（当前：黄振锋·推断待确认）、LeapAll 部署（当前：邓乾·推断待确认）
运维 服务器、安全组、域名证书、生产环境 R 后端/运维（当前：宋祺睿·推断待确认）
测试 功能测试与压测方案、报告 R 测试负责人（当前：张东郅·推断待确认）
调用链梳理 多产品线网关上下游拓扑文档 C 研发（当前：陈子康·推断待确认）

3. 办之前请准备

  • 需求说明：用途（对外分站/内部总站/产品线专用）、预估用户量与 QPS、需接入的上游
  • 部署基线：《软件部署 SOP》《1000 QPS 部署注意事项》、反代配置模板（read/send 超时 900s、connect 180s、body 250m、关闭缓冲）
  • 服务器规格建议与审批单、域名、证书
  • 安全组白名单（默认只开 80/443/22，其余按需审批）
  • 凭据存放：数据库密码、管理员账号放密码管理器，不在群里粘贴
  • 升级场景：当前版本、目标版本、变更日志、漏洞说明、回滚方案
  • 交接场景：渠道清单（含用途）、账号权限、子负责人、未交接项

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交网关需求/升级单：用途、容量、版本、窗口，建单即指定负责人 需求方 / 网关负责人 计划上线前 3 个工作日；安全漏洞当日 LEAP 工单 需求单 🔧飞书固化
2 容量评估并按 RND-23 申请服务器，架构顾问评审方案 网关负责人、架构顾问 需求后 1 个工作日内 飞书审批 审批通过的方案 👤人工判断
3 按基线一键部署：compose 模板、外部数据库/Redis、每层反代超时、磁盘留 ≥ 10% 冗余；代码纳入 Gitea 部署执行、运维 服务器就绪后 1 个工作日内 1Panel/compose 脚本、Gitea 部署完成的实例 🤖自动化
4 部署检查：汇率、渠道、隐藏模型、磁盘、安全组；从顶层向下逐层做超时连通性探测 部署执行 部署当日 检查清单、探测脚本 检查单 🤖+👤
5 功能测试（非流式→流式→长连接）与压测，出报告 测试负责人 部署后 2 个工作日内 压测脚本 压测报告 🤖自动化
6 升级/迁移：提前通知窗口，低峰切 DNS，旧实例保留 ≥ 2 天再回收 网关负责人 压测通过后按窗口 DNS、通知群 切换记录 👤人工判断
7 纳入探测监控与网关台账，更新调用链拓扑文档 网关负责人 上线当日 监控机器人、多维表格 台账、拓扑 🔧飞书固化
8 值守与交接：一主二备排班；维护人变更时按交接清单逐项移交，接收方确认 网关负责人、备用维护者 人员变动前 3 个工作日 飞书日历、交接清单 交接记录 🔧飞书固化

5. 交付物与模板

  • 交付物：部署检查单、压测报告、网关台账、调用链拓扑、升级记录、交接清单
  • 建议模板/表单：台账字段——实例名、用途、产品线、环境、版本、服务器、域名、证书到期日、上游网关/下游调用方、数据库/Redis、是否接入监控、负责人、备岗、最近升级日期
  • 交接清单字段：系统/实例、账号与权限（存放位置）、渠道及用途、价格配置位置、监控与告警、子负责人、未完成事项、接收方确认

6. 异常与升级

  • NewAPI 官方发布安全漏洞 → 网关负责人当日评估，高危漏洞 24 小时内完成升级 → 报研发负责人知悉
  • 压测不达标 → 不上线，扩容或调参后重测 → 3 个工作日未解决报研发负责人
  • 切换后错误率上升 → 在保留期内回切旧实例 → 当日复盘
  • 发现凭据在群聊明文出现 → 立即更换凭据并撤回消息 → 当日通报研发负责人
  • 工单无负责人 → 研发负责人 1 个工作日内派单

7. 衡量指标

  • 部署一次通过率：部署检查单全项通过的比例，目标 ≥ 90%
  • 漏洞修复时长：官方漏洞通告到生产升级完成，目标 ≤ 24 小时
  • 台账覆盖率：已登记网关实例 / 实际实例，目标 100%
  • 明文凭据事件数：目标 0

8. 低效诊断

  • 现象：多层反代各有默认超时，改完后未重启，四层链路里找不到是哪一层超时｜依据：「Leap产研测」2026-06
  • 现象：部署配置、数据库密码、API Key 在群文档或群聊中明文流转｜依据：「New API Claw SKILL计划」2026-03、「AI API」2026-04
  • 现象：部署与压测 SOP 事后才提出；只改 Logo 和名称也要重新编译部署｜依据：「AI API」2026-04
  • 现象：升级窗口多次变更，测试服与生产服定位混乱｜依据：「AI API」2026-07
  • 现象：交接时未说明各渠道用途；维护人变动没有交接资料，账号经聊天发放｜依据：「AI API」2026-07、「AI API」2026-08
  • 现象：多产品线共用网关但没有拓扑文档，只能猜上层网关地址｜依据：「研发通知」2026-07
  • 现象：协议兼容需求建单后负责人不明确｜依据：「AI API」2026-10

9. 分支变体

  • LeapOne 类对外分站：换 Logo/名称/域名，以原装 NewAPI 为主，主题应做成可配置
  • 内部总站 AIAPI：原装版本，对接上游渠道，变更通知走 AI API 变动通知群
  • 产品线专用站（LeapCore/LeapAll）：有定制改动，与对应产品线保持同一版本后再升级
  • OPC 社区网关：公司自用与社区用分开部署、分开域名；只上架主流最新模型
  • 协议扩展（Anthropic Messages 等）：优先在网关层做协议转换，建单时指定负责人
  • 客户本地网关（如客户A、客户B）：远程核对反代与超时配置

10. 待确认问题

  • AI 网关负责人与“一主二备”名单是否确认？各实例是否分设负责人？
  • 部署基线是否以《1000 QPS 部署注意事项》为准？模板脚本由谁维护？
  • 高危漏洞 24 小时升级时限是否可行？
  • 凭据统一使用哪种密码管理工具？
  • 网关台账与拓扑文档放在哪个知识库？
RND-75线上/测试环境故障响应与复盘待新建500

状态：待新建｜证据：有证据（卡片 41 张 / 会话 16 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：生产、测试、客户私有化或内网环境出现服务不可用或大面积报错（OOM、连接池满、磁盘满、证书到期、网络中断、网关超时、容器挂、支付回调丢失、生成任务批量卡死等）时，从报障、定级、指定指挥人、止血恢复、状态同步与对客口径，一直到事故报告和改进项闭环
  • 负责人：主责——故障指挥人（各产品线技术负责人；当前：王皓南·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/网管（当前：杨明学·推断待确认）、客户端/Agent 研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监/对客通报（当前：杨萌·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 报障建卡 → ② 定级并指定指挥人 → ③ 首次通报 → ④ 定位与止血 → ⑤ 定时同步进度 → ⑥ 恢复确认与对客通知 → ⑦ 事故报告与复盘 → ⑧ 改进项转工单闭环
  • 交付结果：故障台账记录（级别、影响面、时间线）；恢复通报；P0/P1 事故复盘报告（存入统一目录）；已排期的改进项工单
  • 状态依据：41 条聊天证据覆盖 1～10 月几乎所有产研群，每次都靠群里 @ 人救火；没有故障分级、值班表、响应时限、通报模板和复盘模板；复盘要靠管理者点名催写，存放位置不统一；同类事故（60 秒超时、配置未下发、磁盘满、证书过期）反复发生

1. 场景判定

  • 触发条件：监控告警，或用户/测试/销售反馈某个环境（Leap 50/51/102、LeapAll 正式服、字字可研正式服、EasyPlay 生产、客户私有化/内网机）出现：服务打不开或 5xx、登录注册异常、生成任务批量卡死、模型全部不可用、支付或订单状态异常、数据丢失或错乱、证书过期、网络不通
  • 典型说法：「云服务一直在报错，我正在演示」「102 环境访问不了」「好几个用户反馈无法使用，需要加急排查」「付款成功但是订单状态没改变」「是平台出问题还是我的网络问题」「专家模式不可用，谁看一下」
  • 判断问题：受影响的是不是超过一个用户，或者整个环境？是否影响生产、付费客户、演示或资金？是不是已知问题且已有工单？影响超过单个用户或单次操作，走本流程；只有单个用户单次报错，先走 RND-76
  • 不归本流程管：单个用户报错的日志收集与定位 → 请走 RND-76；Grafana/死信等日常告警的认领与降噪 → 请走 RND-78；上游模型渠道限流/欠费的切换降级 → 请走 RND-72；磁盘/日志容量与 Gitea/CI/NAS 等内部设施故障 → 请走 RND-79；慢 SQL 专项治理 → 请走 RND-35；修复代码的紧急发布 → 请走 RND-54；部署回滚 → 请走 RND-59；非故障类缺陷 → 请走 RND-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
报障人/告警机器人 按模板报障，提供环境、现象、截图、时间，配合复现；告警机器人自动建卡 R 测试/产品/销售/内部用户（当前：张东郅、杨萌等·推断待确认）；告警机器人（配置人：值班处理人）
故障指挥人 定级、指定处理人、决定止血方案（回滚/重启/切渠道/限流）、控制通报节奏、指定复盘主笔 A 各产品线技术负责人（当前：Leap 与字字可研 王皓南、跃玩 王子明、LeapPPT 马漳毓·推断待确认）
值班处理人 第一响应，查监控、日志与最近变更，执行止血 R 运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）
模块处理人 负责对应服务（Agent/客户端、网关、机房网络、支付）的定位和修复 R 客户端/Agent 研发（当前：岳阳·推断待确认）；IT 运维（当前：杨明学·推断待确认）；跃竞后端（当前：蒋兴武、张楠·推断待确认）；跃竞运维（当前：席博田·推断待确认）
对客通报人 按统一口径通知客户/销售/俱乐部，收集受影响客户清单 R 产品总监（当前：杨萌·推断待确认）；跃竞负责人（当前：徐莉·推断待确认）
复测人 恢复后验证主链路，补漏测分析 R 测试负责人（当前：张东郅·推断待确认）
复盘主笔 写事故报告，登记改进项 R 指挥人指定的当事研发（当前：按事故指定）
研发负责人（兼权限管理） 接收 P0 升级并拍板，评审复盘，定追责尺度；故障期间审批并开通临时只读监控/云控制台权限，事后回收 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 环境标识：环境名 + IP/hostname（50/51/102/正式服/客户机）。排查前先核对目标机器标识，避免查错机器造成误报
  • 现象：截图/录屏、首次发现时间、报错原文、trace_id、受影响账号/订单号/项目 ID
  • 影响面：受影响用户数和客户、是否正在演示、是否涉及付费、资金或数据
  • 最近变更：近 24 小时的发布、配置修改、网络/防火墙改动、迁移（查发布记录和变更登记，见 RND-58）
  • 日志：服务端日志或客户端诊断包（获取方式见 RND-76）
  • 权限：值班人提前具备只读监控、日志和容器查看权限，不要等故障发生后再申请
  • 请求最少包含字段（报障帖必填，缺项由机器人或值班人一次性追问补齐，不来回问）：环境名 + IP/hostname、现象与报错原文、首次发现时间、影响范围（人数/客户/是否演示中/是否涉资金）、截图或录屏、trace_id 或受影响账号/订单号、最近是否有人变更、报障人岗位与可联系方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 报障：在「故障响应群」用报障模板发帖（环境/现象/时间/影响/截图/trace_id），或由告警机器人自动建卡 报障人/告警机器人 发现后 5 分钟内 飞书群 + 报障表单（多维表格） 带编号的故障卡片（故障台账一行 + 故障响应群话题，后续全部在该话题内） 🔧+🤖
2 定级：P0＝生产全站或核心链路不可用、资金/数据受损、演示中断；P1＝生产主要功能不可用或多个客户受影响；P2＝测试环境整体不可用并阻塞验收，或生产非核心功能异常；P3＝单用户问题，转 RND-76 值班处理人初判，指挥人确认 P0/P1 5 分钟内；P2 30 分钟内 多维表格级别字段 级别 + 指挥人 + 处理人（写入故障台账，话题内 @ 处理人）；超时→机器人 @ 指挥人 👤人工判断
3 首次通报：在群内发「已知悉 + 级别 + 处理人 + 下次同步时间」；P0/P1 置顶，并通知对客通报人 指挥人 定级后 10 分钟内 故障公告卡片模板 首次通报（故障响应群置顶卡片 + @ 对客通报人） 🔧飞书固化
4 定位：核对机器标识 → 看监控（CPU/内存/磁盘/连接池/证书）→ 查日志 → 对照最近变更；按“客户端 → 内网服务 → 公网服务 → 网关 → 上游”逐层排查 值班处理人 + 模块处理人 P0 30 分钟内给出初判；P1 1 小时内 监控、日志平台、AI 机器人查日志 初步根因（写在故障话题内，含排查到哪一层）；超时→指挥人加派模块处理人 🤖+👤
5 止血：先恢复服务（回滚 RND-59、重启/扩容、切渠道 RND-72、限流、暂停异常任务、官方 API 兜底）；涉及资金、删数据或生产热修的，必须经指挥人批准，热修走 RND-54，个人不得直接改正式服 处理人执行，指挥人批准 P0 1 小时内恢复或降级；P1 4 小时内；P2 当日 发布系统、容器管理工具 恢复/降级状态（话题内记录操作与时间，指挥人批准留言）；超时→升级研发负责人 👤人工判断
6 同步进度：在同一话题内定时更新（P0 每 30 分钟，P1 每 1 小时）；同一故障不在多个群分散讨论 指挥人 P0 每 30 分钟；P1 每 1 小时；P2 每半天 故障话题 时间线记录（故障话题内，复盘直接引用） 🔧飞书固化
7 确认恢复：测试/报障人复测主链路；排查受影响客户清单（数据、生成任务、补单是否完成）；按口径通知客户、销售或俱乐部 复测人、对客通报人 恢复后 30 分钟内复测；对客通知 1 小时内 冒烟用例、对客通知模板 恢复通报（故障响应群）+ 受影响客户清单（故障台账附件，交对客通报人；对客通知发客户群并回执） 🔧+👤
8 关闭登记：填写故障台账（开始/恢复时间、影响、临时措施、处理人），回收临时权限 指挥人 恢复当日 故障台账（多维表格） 台账记录（状态=已恢复，指定复盘主笔与截止日） 🔧飞书固化
9 复盘：P0/P1 必须写事故报告（时间线、影响、根因、为何没有提前发现、改进项、负责人、截止日）；AI 先根据群话题整理时间线初稿 复盘主笔 P0 恢复后 1 个工作日内；P1 2 个工作日内 事故报告模板（飞书文档，链接登记到 Gitea） 事故报告（飞书文档放统一事故目录，链接回填故障台账）；超时→指挥人催办，再超 1 个工作日报研发负责人 🤖+👤
10 评审与闭环：在周会上过报告，改进项转工单并在台账中跟踪到关闭；同一根因第二次出现时，必须拿出根治方案 指挥人、研发负责人 报告完成后的下一次周会 Gitea 工单、故障台账（多维表格） 改进项工单（Gitea，每项有负责人与截止日，工单号回填台账） 🔧+👤

5. 交付物与模板

  • 交付物：故障台账记录；首次、进度、恢复三类通报；事故报告；改进项工单
  • 报障模板字段：产品/环境（含 IP）、现象、首次发现时间、影响范围、截图/录屏、trace_id、受影响账号/订单、是否正在演示、最近是否有人变更
  • 故障台账字段：编号、级别、环境、产品线、开始/发现/恢复时间、受影响用户与客户、指挥人、处理人、根因分类（配置/代码/硬件/网络/上游/容量/证书）、临时措施、复盘链接、改进项与状态
  • 对客通报模板：现象、影响范围、当前状态、预计恢复时间、临时绕行办法、联系人（措辞由对客通报人确认，不对外透露内部根因细节和责任人）
  • 事故报告模板：概述、时间线、影响面、根因（含“为何监控没有发现”）、处置过程、改进项（负责人/截止日）、是否需要更新 SOP

6. 异常与升级

  • 15 分钟内无人认领 → 机器人 @ 指挥人；30 分钟仍无响应 → 升级研发负责人
  • P0 超过 1 小时未恢复，或涉及资金、数据丢失、安全问题（如错误密码也能登录）→ 立即升级研发负责人；资金类同时通知跃竞负责人和财务
  • 根因是他人变更，或多人同时在改配置 → 指挥人冻结变更，只留一名执行人；先恢复，再追溯，不在群里互相推诿
  • 根因在第三方（云厂商、支付通道、上游模型）→ 处理人提工单并保留工单号；对外口径由对客通报人统一，不能简单归咎第三方
  • 故障期间需要临时权限 → 向研发负责人申请最小权限，事后 24 小时内回收
  • 同一根因 30 天内复发 → 复盘必须给出根治方案，由研发负责人审核
  • 报障帖缺关键字段（环境/时间/影响/截图） → 值班人一次性列出缺项请报障人补齐，不逐条反问；5 分钟内补不齐的按已有信息先定级
  • 故障在多个群同时被讨论、或有人私聊处理人 → 指挥人把链接统一引回故障话题，其他群只贴话题链接；对客口径只由对客通报人发出
  • 销售/业务方问"恢复了吗" → 回指故障话题最近一次同步；超过约定同步间隔未更新的，指挥人 10 分钟内补一条
  • 研发负责人 A（升级）的条件：P0 超过 1 小时未恢复；涉及资金、数据丢失或安全问题；30 分钟无人响应；同因 30 天内复发；指挥人之间对止血方案有分歧。其余情况由故障指挥人拍板

7. 衡量指标

  • MTTA（平均认领时长）= 报障到指定处理人的分钟数，目标 P0 ≤ 5 分钟、P1 ≤ 15 分钟
  • MTTR（平均恢复时长）= 从发现到恢复或降级的时长，目标 P0 ≤ 1 小时、P1 ≤ 4 小时
  • 主动发现率 = 告警早于用户发现的故障数 / 故障总数，目标 ≥ 70%
  • 复盘按时率 = 按时提交报告的 P0/P1 数 / P0/P1 总数，目标 100%
  • 改进项关闭率 = 30 天内关闭的改进项 / 全部改进项，目标 ≥ 80%
  • 同因复发次数 = 30 天内同一根因再次引发故障的次数，目标 0

8. 低效诊断

  • 现象：报障时不带环境、日志和截图，研发反复追问“哪个服务崩了”“再发发日志”（报障环节）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06、「工程咨询产研」2026-02
  • 现象：没有值班表，只能在群里连续 @ 人、临时设时限催回复，有时无人认领或互相推诿（认领环节）｜依据：「Leap产研测」2026-06、「工程咨询产研」2026-01、「LeapPPT」2026-05
  • 现象：机器人连错机器造成误报；60 秒超时一周内重复定位 5 次以上，最后才发现各层网关都没配超时（定位环节）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：多人同时改配置，有人未经评审直接热修正式服；改端口、改防火墙不走变更窗口，同一天两次故障（止血与变更环节）｜依据：「Leap产研测」2026-06、「鼎慧产研决策部」2026-08
  • 现象：故障主要靠用户或管理者发现，夜间数据库 CPU 打满、周末告警刷屏数小时无人处理（发现环节）｜依据：「Leap反馈群」2026-06、「Leap产研测」2026-07、「工程咨询产研」2026-08
  • 现象：排查受影响客户要临时找销售，找不到客户群和验证人；对俱乐部的口径临时商量（对客环节）｜依据：「Leap产研决策部」2026-09、「跃玩项目组」2026-09
  • 现象：复盘靠点名、无模板、无统一存放位置，旧复盘找不到，根因散落在聊天里（复盘环节）｜依据：「Leap产研测」2026-07、「鼎慧产研决策部」2026-05、「AI API」2026-07

9. 分支变体

  • Leap 50/51 测试环境：默认 P2，阻塞验收时由测试负责人提级；测试集群禁止下发无关配置
  • Leap 102 公司生产 / LeapAll 正式服：默认 P1，全员不可用或正在演示时为 P0；用户群由对客通报人发统一公告
  • 字字可研正式服：恢复后扫描“有开始、无结束”的生成任务并标为异常，通知受影响用户重新生成；上游云厂商故障同步提供应商工单
  • 跃玩/EasyPlay 支付订单故障：一律按 P0 处理；后端确认补单任务全部跑完后，再通知跃竞负责人；对俱乐部口径由跃竞负责人统一；有资金差错的，转 RND-80 做数据订正
  • 客户私有化/内网环境：通过 WireGuard 或远程查看服务状态，需要客户配合时由销售/交付协助；修复按“正在使用的客户优先”排序
  • 版本升级/迁移引发的故障：迁移告警卡片视同报障；变更方事前未通知的，记入复盘
  • 配置事故（价格、渠道、缓存配置）：复盘后把正确做法沉淀为检查清单，并置顶到对应群
  • 临时授权查看监控：故障期间按最小权限开通，事后回收；长期方案是给值班人预置只读监控角色
  • 协作协议：遵循 ALL-02（消息分级与响应时限）、ALL-06（卡点升级阶梯）、ALL-04（跨部门交接契约）、ALL-05（会议发起、纪要与待办闭环）

10. 待确认问题

  • 故障指挥人是按产品线分设（Leap、字字可研、跃玩、LeapPPT），还是统一由一名值班负责人承担？
  • P0～P3 定级标准和响应时限（5/15/30 分钟）是否可行？夜间和周末是否需要值班轮换？
  • 事故报告统一放 Gitea 仓库还是飞书知识库？谁负责维护故障台账？
  • 生产热修是否必须由指挥人批准？紧急情况下一人先热修的，事后补审时限是多少？
  • 对客户/俱乐部的故障通报由谁最终签发？是否需要对外状态页？
  • 值班人默认应具备哪些只读权限（云监控、日志、容器），由谁开通？
RND-76用户问题日志收集与定位待优化120

状态：待优化｜证据：有证据（卡片 11 张 / 会话 4 个）｜优先级：频5 × 耗2 × 跨4 × 险3

  • 适用场景：单个用户或测试报“执行失败、卡死、白屏、400/401/402、生图/PPT 失败、启动失败”时，按清单一次收齐版本、环境、模型档位、截图、trace_id 和诊断包；研发据此逐层定位（客户端 → 内网服务 → 公网服务 → 网关 → 上游），回复结论或建单
  • 负责人：主责——客户端问题定位接口人（当前：岳阳·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、LeapAll 服务端研发（当前：邓乾·推断待确认）、LeapCore 服务端/部署研发（当前：杨云峰、宋祺睿·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）、LeapPPT/生图研发（当前：马漳毓·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 用户按清单反馈 → ② 机器人补问缺项 → ③ 一键上传诊断包并关联工单 → ④ AI 初判 → ⑤ 研发逐层定位 → ⑥ 复现确认 → ⑦ 回复结论/绕行办法并建单 → ⑧ 沉淀 FAQ
  • 交付结果：带完整环境信息和日志链接的问题工单；给反馈人的定位结论或临时绕行办法；更新后的常见错误 FAQ
  • 状态依据：客户端已有“设置 → 导出日志/诊断信息”、反馈按钮、trace_id、COS 私有桶，但用户普遍不知道入口；研发每次都重复追问版本/环境/模型/日志（约 25 次）；日志在群里流转，且含密钥和文件内容；“一键上传 + 自动建单”提出多次，仍未落地

1. 场景判定

  • 触发条件：单个用户或测试遇到报错、卡死、白屏、启动失败、生成失败，影响范围限于个人或单次操作
  • 典型说法：「发一下日志，在设置里面」「什么模型 + 提交日志」「status_code=400, Invalid size」「日志文件怎么发？」「谁看下错误详情」
  • 判断问题：其他人、其他账号是否也出现同样问题？多人同时出现或整个环境不可用 → 升级 RND-75；只有一个人 → 走本流程
  • 不归本流程管：环境级故障 → 请走 RND-75；需求、体验建议与 badcase → 请走 RND-01 / RND-02；已定位缺陷的修复排期 → 请走 RND-03；错误提示文案与上报规范设计 → 请走 RND-77；上游模型故障切换 → 请走 RND-72

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈人 按清单提供信息，导出并上传诊断包，配合复现 R 内部用户/测试/客户对接人（当前：杨萌、张东郅等·推断待确认）
反馈群机器人 自动追问缺项、匹配已知问题、日志初判 R 反馈群 AI 机器人（当前：已有机器人，配置人待指定）
定位接口人 分诊到对应模块，给出结论并回复 A 客户端问题定位接口人（当前：岳阳·推断待确认）
模块研发 查网关日志、服务端日志、VPN 日志、生图/PPT 参数 R 网关研发（当前：柯逸飞·推断待确认）；LeapAll 服务端（当前：邓乾·推断待确认）；LeapCore 服务端（当前：杨云峰、宋祺睿·推断待确认）；LeapVPN（当前：吴世豪·推断待确认）；LeapPPT（当前：马漳毓·推断待确认）
复现人 同版本/旧版本升级路径复现，补全工单 R 测试负责人（当前：张东郅·推断待确认）
日志上传链路维护 COS 私有桶、反馈 ID、预签名链接 R 运维/后端（当前：宋祺睿、杨云峰·推断待确认）
产品值班 同类问题第 3 次出现时补 FAQ 与机器人知识库 R 产品总监或产品轮值（当前：杨萌·推断待确认）
研发负责人 拍板日志隐私与脱敏规则、用户数据导出审批，处理超时升级 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 产品与版本号（设置 → 关于）、操作系统（Windows/Mac/信创）、环境（正式服/测试服/企业私有化/FDE 版）
  • 模型档位（经济/标准/专家）、发生时间（精确到分钟）、操作步骤
  • 截图或录屏（先给敏感信息打码再发）、报错原文和 trace_id（弹窗关闭前先复制）
  • 诊断包：设置 → 帮助 → 导出诊断信息/日志（leapagent-日期.log.jsonl、diagnose-日期.zip）；VPN 问题另附 leapvpn 日志目录
  • 不要把日志原文直接贴进群聊：容易泄露数据，也会撑爆机器人的上下文

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按“报错反馈清单”在客户端反馈按钮或反馈群提交 反馈人 发现当天 客户端反馈按钮 / 飞书表单 反馈记录 🔧飞书固化
2 自动追问缺项，并匹配已知问题和规避办法 反馈群机器人 反馈后 5 分钟内 机器人 + FAQ 知识库 补全的信息或已知问题回复 🤖自动化
3 上传诊断包：客户端一键上传到 COS 私有桶，生成反馈 ID 和预签名链接；工单只引用链接，不上传日志文件本身 反馈人 收到追问后 30 分钟内 客户端、COS 反馈 ID 🤖+👤
4 AI 初判：解析日志和 trace_id，匹配常见错误码（401 key 被禁、402 余额不足、429 限流、400 参数错误），给出初步归因 反馈群机器人 上传后 10 分钟内 AI 助手 初判结论 🤖自动化
5 逐层定位：客户端 → 内网服务 → 公网服务 → 网关（NewAPI）→ 上游；按 trace_id 查网关和服务端日志；需要导出用户 Agent 数据库时，先经研发负责人同意 定位接口人 + 模块研发 工作时间 2 小时内首次回复；重点客户 30 分钟内 日志平台、NewAPI 后台 根因判断 👤人工判断
6 复现：无法确认时，按同版本或旧版本升级路径复现；复现不出不直接判定“不是 bug”，标为“待观察”，并要求下次出现时附日志 复现人 1 个工作日内 测试环境 复现结论 👤人工判断
7 回复与建单：给反馈人结论和临时办法（换档位、新开会话、升级版本）；确认是缺陷的按 RND-03 建单并附反馈 ID；上游问题转 RND-72 定位接口人 定位当天 Gitea 工单 回复 + 工单号 👤人工判断
8 沉淀：同类问题出现第 3 次时，补进常见错误 FAQ 和机器人知识库 产品值班 每周 1 次 FAQ 文档 FAQ 条目 🔧+🤖

5. 交付物与模板

  • 交付物：问题工单（附反馈 ID/日志链接）、定位回复、FAQ 条目
  • 报错反馈清单字段：产品、版本、系统、环境、模型档位、时间、操作步骤、现象截图、报错原文、trace_id、反馈 ID/日志链接、是否可复现
  • 诊断包规范：含客户端日志、主进程日志、VPN 日志、版本信息；自动排除文件内容和密钥；单个文件大小有上限（具体值由客户端设定）
  • 定位回复模板：结论、问题所在层级、临时办法、是否建单（单号）、预计修复版本

6. 异常与升级

  • 用户担心隐私、不愿提供日志 → 说明脱敏范围；仍不同意的，改为远程协助或上门（全程录屏），由定位接口人决定
  • 日志中发现密钥或文件内容 → 立即删除群内副本，提脱敏工单，并通知研发负责人
  • 同一问题 1 小时内有 3 名以上用户反馈 → 升级 RND-75
  • 2 个工作小时无人回复 → 机器人 @ 定位接口人；4 个工作小时仍无回复 → 升级研发负责人
  • LeapCore 企业机日志只能在服务器上看 → 转服务端研发或交付人员远程获取
  • 研发负责人 A（升级）的条件：需要导出用户 Agent 数据库或调整日志脱敏规则；日志中发现密钥或文件内容；4 个工作小时无人回复。其余定位结论由定位接口人拍板

7. 衡量指标

  • 首次信息完整率 = 首次反馈就包含版本/环境/日志的工单数 / 全部反馈数，目标 ≥ 80%
  • 首次响应时长 = 反馈到研发首次回复，目标 ≤ 2 个工作小时
  • 定位周期 = 反馈到给出根因结论，目标中位数 ≤ 1 个工作日
  • 基础信息追问次数 = 每单研发追问版本/环境/日志的次数，目标 ≤ 1

8. 低效诊断

  • 现象：研发反复追问版本、环境、模型档位和日志，同一故障多人重复发日志（信息收集环节）｜依据：「Leap反馈群」2026-07、「跃迁AI总动员」2026-05
  • 现象：用户不知道日志在哪导出，需要截图指引；对“有没有这个功能”的说法前后不一（入口环节）｜依据：「Leap产研测」2026-05、「Leap反馈群」2026-08
  • 现象：日志在群里流转，被模型当上下文读爆，且含密钥和文件内容；日志上限设为 1G 导致读写占用（传输环节）｜依据：「Leap产研测」2026-05
  • 现象：报错统一显示“服务不可用”，掩盖真实错误类型；四层网络不清楚问题出在哪层（定位环节）｜依据：「Leap产研测」2026-07、「跃迁AI总动员」2026-06
  • 现象：复现不出就被判“不是 bug”，后来又复现成功；重置后日志丢失（复现环节）｜依据：「Leap产研测」2026-05
  • 现象：部分途径日志上报有遗漏，某些空间长时间没有日志上报（上报链路环节）｜依据：「Leap反馈群」2026-09
  • 现象：日志直接传 Gitea 被否决，改用 COS 链接的方案尚未落地（工单关联环节）｜依据：「LeapCore（archived）」2026-05

9. 分支变体

  • LeapAll（日志在本地）vs LeapCore（企业服务器日志需服务端研发查看）
  • PPT/生图：先查网关（NewAPI）响应中上游返回的 400 参数（如尺寸格式、比例映射）；参数类问题由 PPT/生图研发同步修改，并补参数回归用例
  • VPN/网络问题：附 leapvpn 日志，转 LeapVPN 负责人
  • 客户日志：上传 COS 私有桶，工单只引用反馈 ID 和预签名链接
  • 正式服 vs 测试服：先确认用户所在环境再查，避免查错环境

10. 待确认问题

  • 定位接口人固定由客户端研发担任，还是按产品轮值？
  • “一键上传诊断包 + 自动建单”计划何时上线？上线前是否统一用 COS 或群文档手工上传？
  • 日志保留期限和脱敏规则（排除文件内容、密钥）由谁审批？
  • 导出用户 Agent 数据库是否需要审批？审批人是谁？
  • 首次响应 2 个工作小时是否可行？重点客户是否单独设 SLA？
RND-77错误提示、日志上报与可观测性规范待新建81

状态：待新建｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：新功能开发、客户端/网关/后端改造，或复盘发现报错“看不懂、查不到、对不上”时，按统一规范设计用户可见的错误提示、错误码映射、贯穿全链路的 trace_id、错误上报（PostHog/Grafana）以及日志保留与降噪，并在评审和 CI 中检查
  • 负责人：主责——可观测性负责人（当前：魏宗浩·推断待确认）；协同——Leap 研发技术负责人（当前：王皓南·推断待确认）、客户端研发（当前：岳阳·推断待确认）、v5 网关研发（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 汇总问题 → ② 起草/修订规范 → ③ 评审发布 → ④ 开发落地 → ⑤ CI 与测试校验 → ⑥ 线上抽查与降噪 → ⑦ 版本化修订
  • 交付结果：《错误提示与可观测性规范》（错误码字典、提示文案、trace_id 规则、上报字段、环境区分、数据保留策略）；规范落地的代码和 CI 检查；统一的查询入口页
  • 状态依据：规则散落在群聊中，统一提示格式、生产环境不弹 trace_id、网关不透传上游错误、报错必须带 trace_id 等都是一次性口头说法，“弹不弹 trace_id”改了约 3 次；PostHog 已上线，但拆代码后上报失灵；数据清理策略未定；没有成文规范和明确负责人

1. 场景判定

  • 触发条件：新模块接入错误上报；网关或后端新增错误类型；复盘发现没有 trace_id、报错太笼统或是英文；PostHog/日志平台噪声大或存储超限；某条业务线（Leap、字字可研、跃玩）新建可观测体系
  • 典型说法：「这种报错就别直接给用户看了，一般都得包一层」「别透传，都得处理一下再传」「报错得有 trace_id」「‘本次回答执行失败，请稍后重试’这个提示太宽泛了」「做 2B 不能说搞清理」
  • 判断问题：要改的是“规则/规范”，还是某个具体故障？规则走本流程，具体故障走 RND-75 / RND-76
  • 不归本流程管：具体故障响应 → 请走 RND-75；单个用户日志收集 → 请走 RND-76；告警规则阈值与认领 → 请走 RND-78；上游模型错误切换 → 请走 RND-72；代码评审清单维护 → 请走 RND-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范负责人 起草维护规范、组织评审、跟踪落地、每周抽查 R 可观测性负责人（当前：魏宗浩·推断待确认）
规则拍板人 审定生产/开发环境差异、上报范围、保留策略 A Leap 研发技术负责人（当前：王皓南·推断待确认）
客户端落地 错误提示组件、trace_id 展示、上报与诊断包 R 客户端研发（当前：岳阳·推断待确认）
网关落地 上游错误码映射与兜底 R v5 网关研发（当前：吴世豪·推断待确认）；网关/NewAPI 研发（当前：柯逸飞·推断待确认）
跃玩线落地 Grafana/Loki trace_id 过滤、可读日志看板、后端报错带 trace_id R 跃竞运维（当前：席博田·推断待确认）；跃竞后端负责人（当前：王子明·推断待确认）
测试 错误场景用例、上报冒烟 R 测试负责人（当前：张东郅·推断待确认）
代码评审人 合并前检查异常级别、trace_id 与错误码映射 R 各仓库 PR 评审人（当前：按仓库指定）
产品 用户提示文案中文化与体验 C 产品总监（当前：杨萌·推断待确认）
研发负责人 规则分歧仲裁、敏感数据上报处置 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 现有错误类型清单（客户端、网关、Agent、后端）和当前文案截图
  • 近 30 天“定位不了/定位慢”的问题列表（来自 RND-75、RND-76 台账）
  • 现有观测组件和入口：PostHog、Grafana/Loki/Prometheus、NewAPI 日志、OpenTelemetry 规划
  • 合规要求：日志是否含用户数据，2B 客户对留存期限的期望

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 从故障台账和用户反馈中汇总“错误提示/定位”类问题 规范负责人 每月第 1 周 多维表格 问题清单 🤖自动化
2 起草/修订规范：①用户提示统一为“××操作出现问题，请重试或联系管理员”，可展开查看详情；常见错误（401/402/403/404/429/上游超载）给出明确的中文文案和处置建议；禁止把英文原始堆栈直接弹给用户 ②网关不透传上游错误，至少区分余额不足、并发限流、网络错误、上游超载、内部错误，未知错误先兜底为“模型错误请重试” ③所有后端报错都带 trace_id，并贯穿客户端→网关→Agent→上游；开发/测试 build 前台展示 trace_id，生产 build 不弹出、但详情中可复制 ④生产环境未捕获的异常只上报、不弹 toast，随附错误前后 200 条日志；上报字段含版本、环境、用户 ID、trace_id；开发环境默认关闭上报 ⑤2B 数据不随意清空，先打包归档到 COS，再清理噪声 规范负责人 汇总后 5 个工作日内 飞书文档 规范草案 👤人工判断
3 评审并发布规范 规则拍板人 草案提交后 3 个工作日内 评审会 发布版规范 👤人工判断
4 拆工单给客户端、网关、后端，按迭代落地 各落地人 按迭代排期 Gitea PR 👤人工判断
5 校验：CI 增加上报冒烟（模拟异常，检查是否进入 PostHog），错误码映射做自动化测试；代码评审检查“异常级别/trace_id”项 测试、代码评审人 每次合并前 CI 检查通过记录 🤖自动化
6 线上抽查与降噪：每周看 Top 错误，确认能按 trace_id 反查到日志；噪声错误修复或降级（阈值调整走 RND-78）；先归档再清理 规范负责人 每周 1 次 PostHog/Grafana 抽查记录 🤖+👤
7 规范变更在研发群公告，并在文档中记录版本 规范负责人 变更当日 飞书文档版本记录 变更记录 🔧飞书固化

5. 交付物与模板

  • 交付物：规范文档；错误码字典；查询入口汇总页；CI 上报冒烟用例
  • 规范文档章节：用户提示规范、错误码字典、trace_id 规则、上报字段与环境区分、日志级别（与 RND-78 保持一致）、保留与归档策略、查询入口
  • 错误码字典字段：错误码、所在层级（客户端/网关/Agent/后端/上游）、含义、用户文案、处置建议、是否上报、日志级别
  • 查询入口汇总页：PostHog、Grafana 看板、NewAPI 日志，以及按 trace_id 查询的方法

6. 异常与升级

  • 规则有分歧（弹不弹 trace_id、清不清数据）→ 规范负责人列出选项，3 个工作日内由规则拍板人决定；仍有分歧，升级研发负责人（A（升级）），其决定为最终结论
  • 拆代码或重构导致上报失灵 → 按 P1 缺陷处理，补 CI 冒烟拦截
  • 上报中出现用户敏感数据 → 立即停用相关字段，并升级研发负责人决定处置方式
  • 存储超限 → 先归档到 COS 再清理，不允许直接重置数据

7. 衡量指标

  • trace_id 覆盖率 = 带 trace_id 的错误上报 / 全部错误上报，目标 ≥ 95%
  • 可反查率 = 抽查错误中能按 trace_id 找到完整日志的比例，目标 ≥ 90%
  • 原始错误外露数 = 用户可见英文/原始堆栈报错的页面数，目标 0
  • 上报噪声占比 = 非故障类错误上报 / 全部错误上报，目标 ≤ 20%

8. 低效诊断

  • 现象：原始报错直接暴露给用户，提示太笼统或是英文，掩盖真实错误类型（提示设计环节）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-07
  • 现象：网关最初设计为完全透传上游错误，排查半天性能问题才发现是上游过载（网关环节）｜依据：「AI API」2026-08
  • 现象：“弹不弹 trace_id”规则反复修改；另一条业务线用户报错时没有 trace_id，难以定位（trace_id 环节）｜依据：「Leap产研测」2026-07、「跃玩项目组」2026-08
  • 现象：本地有详细日志，但上报后变成笼统的“调用失败”；拆代码后上报失灵（上报链路环节）｜依据：「Leap产研测」2026-07
  • 现象：PostHog 数据清不清理口径不一（数据保留环节）｜依据：「Leap产研测」2026-09
  • 现象：大家认同日志治理很重要，但无人牵头成文（规范归属环节）｜依据：「Leap产研测」2026-07

9. 分支变体

  • 客户端（LeapAll/LeapCore/LeapLite）：用 PostHog 错误追踪，区分生产与开发环境；崩溃前先刷写埋点，防止丢失
  • v5 网关：上游错误码映射与兜底，映射表配套自动化测试
  • 跃玩/EasyPlay：用 Grafana/Loki/Prometheus，提供 trace_id 过滤和可读日志看板；用户报错按 ID + 时间范围反查
  • 字字可研：计划接入 OpenTelemetry 类链路追踪，接入后同样执行本规范

10. 待确认问题

  • 可观测性规范负责人是否就是当前推断人员？跃玩线是否单独维护一份子规范？
  • 生产 build 是否允许在“详情”中复制 trace_id？
  • PostHog/日志保留周期（如在线 90 天 + COS 归档 1 年）是否可行？
  • 是否要统一到一套可观测平台（PostHog / Grafana / SigNoz），还是按业务线各用各的？
  • 本规范是否纳入代码评审清单（RND-32）和提测检查项？
RND-78生产告警认领、分级与降噪待优化80

状态：待优化｜证据：有证据（卡片 7 张 / 会话 2 个）｜优先级：频5 × 耗2 × 跨2 × 险4

  • 适用场景：监控机器人推送生产告警（Grafana 错误日志检测、EasyPlay 告警、死信队列告警、Redis Sentinel、定时巡检任务告警）时，负责认领、分诊、修复和关闭；同类误报反复出现时，调整阈值、日志级别、通知对象和模板，且变更前先在测试群验证
  • 负责人：主责——告警值班人（建议按周轮值；当前：王子明·推断待确认）；协同——跃竞运维（当前：席博田·推断待确认）、跃竞后端（当前：蒋兴武、张楠·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 告警分级推送 → ② 值班认领 → ③ 分诊（真实故障/业务异常/误报/第三方）→ ④ 指派或升级 → ⑤ 处置 → ⑥ 关闭登记 → ⑦ 每周降噪 → ⑧ 规则变更先测后发
  • 交付结果：每条告警都有认领人和处置结论（台账记录）；《告警分级与日志级别规范》和忽略清单；经测试的告警规则/模板变更记录
  • 状态依据：告警机器人已稳定推送（本条卡片累计 600+ 条），后期卡片已带级别、环境、服务和堆栈；但真正有人跟进的不足 15%，没有认领和关闭机制，同一任务告警连续约 8 天无人回应；业务异常大量按 ERROR 上报，降级和忽略口径不一

1. 场景判定

  • 触发条件：告警群出现「EasyPlay 告警」/「系统警报」（prod 或 admin-prod 5 分钟内 ERROR 超阈值）、死信队列告警、Redis Sentinel TILT、巡检任务告警；或某类告警一周内重复 3 次以上，被判定为噪声
  • 典型说法：「这个是你的了」「同一个错误，他们猛按就出了一堆」「还没修好吗」「拒付的这种告警直接忽略吧」「恢复就别发了吧，容易误认为告警」
  • 判断问题：这条告警是否意味着用户或资金已经受影响？是 → 认领后如果影响面扩大，升级 RND-75；否 → 按业务异常或误报处理，并进入降噪
  • 不归本流程管：大面积服务不可用 → 请走 RND-75；错误提示与 trace_id 规范 → 请走 RND-77；磁盘/容量等基础设施治理 → 请走 RND-79；上游模型告警 → 请走 RND-72；异常订单数据订正 → 请走 RND-80

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
告警值班人 按时认领、分诊、指派、关闭登记，参加每周降噪 A/R 告警值班人（当前：王子明·推断待确认，建议后端成员轮值）
模块负责人 修复代码、修正异常抛出级别、处理死信 R 跃竞后端（当前：蒋兴武、张楠·推断待确认）
告警平台维护 维护规则、阈值、通知对象、模板、测试群；每日巡检 R 跃竞运维（当前：席博田·推断待确认）
告警机器人 分级推送告警卡片，未关闭指纹自动升级 R Grafana 告警机器人（由告警平台维护人配置）
业务侧 判断业务影响；资金类告警是否可忽略有分歧时拍板 A（升级） 跃竞负责人（当前：徐莉·推断待确认）
财务 支付拒付、分账类告警影响账务时确认 C 财务专员（当前：待指定）
研发负责人 审批分级规范，处理超时未认领升级 A（升级） 研发部门负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 告警卡片信息：规则名、环境（prod/admin-prod/dev）、服务、错误摘要、堆栈、触发次数
  • Grafana/Loki 日志查询入口和 trace_id
  • 最近发布记录（Drone 构建号）和“模块 → 负责人”对照表
  • 告警分级与忽略清单（见第 5 节）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 分级推送：critical（资金/支付/主链路）@ 值班人 + 模块负责人；error @ 值班人；warning 只进群、不 @；dev 告警进测试群 告警机器人 实时 Grafana → 飞书 告警卡片 🔧飞书固化
2 认领：值班人点卡片“认领”或回复“已认领” 告警值班人 critical 10 分钟内；error 工作时间 30 分钟内，非工作时间次日 10 点前 飞书卡片按钮 认领记录 🔧飞书固化
3 分诊：查堆栈和日志，判断属于真实故障、业务异常、误报还是第三方问题；AI 按堆栈聚类重复错误，给出疑似模块和最近提交人 告警值班人 认领后 30 分钟内 Grafana/Loki、AI 助手 分诊结论 🤖+👤
4 指派或升级：真实缺陷指派给模块负责人并建工单；影响面扩大的升级 RND-75；资金类同步跃竞负责人 告警值班人 分诊后立即 工单系统 工单号 👤人工判断
5 处置：修复后发版，或临时在边缘层禁用异常接口止血；死信消息判断是重投、丢弃还是修数据（资金类死信不得直接丢弃） 模块负责人 critical 当日；error 3 个工作日内 Drone、Pulsar 修复版本/处置记录 👤人工判断
6 关闭：标记“已处理/误报/忽略原因”，填写根因和修复版本，补齐历史数据；同一告警指纹 24 小时未关闭的，自动升级 告警值班人 处置当日 告警台账（多维表格） 关闭记录 🔧+🤖
7 每周降噪：统计 Top 噪声告警，按分级规范调整日志级别（业务/校验异常为 WARN、429 为 INFO、系统异常为 ERROR、资金/支付为 CRITICAL），形成调整清单 告警平台维护 + 告警值班人 每周一 统计脚本 降噪清单 🤖+👤
8 规则变更：阈值、通知对象、模板变更先在「告警测试群」验证，再登记并在告警群公告；恢复通知折叠或不 @ 人 告警平台维护 变更前 1 个工作日登记 测试群、变更登记表 变更记录 🔧飞书固化

5. 交付物与模板

  • 交付物：告警台账、分级与日志级别规范、忽略清单、死信处置记录、规则变更登记
  • 告警台账字段：告警指纹、规则名、环境、级别、首次/最后触发时间、触发次数、认领人、分诊结论、工单号、修复版本、关闭时间、忽略原因
  • 分级与日志级别规范：CRITICAL＝资金/支付/主链路（含支付拒付，不得忽略）；ERROR＝系统、数据库、运行时异常；WARN＝业务异常、校验异常、余额不足；INFO＝429 限流、客户端主动断开
  • 忽略清单字段：告警规则/错误码、忽略理由、确认人、复核日期
  • 死信处置记录字段：队列、消息 ID、业务类型（payment-event/存单等）、处置方式（重投/丢弃/修数据）、确认人

6. 异常与升级

  • critical 告警 10 分钟无人认领 → 机器人 @ 跃竞后端负责人；30 分钟仍无人认领 → 升级研发负责人
  • 同一告警 1 小时内反复触发且影响订单/支付 → 升级 RND-75，按 P0/P1 处理
  • payment-event 类死信 → 当日处理；涉及账务的通知财务，并走 RND-80 数据订正
  • 对“是否忽略”有分歧 → 资金类默认不忽略，由跃竞负责人拍板
  • 测试告警误发到生产群 → 立即说明并撤回，记一次变更违规，复查测试群使用方式
  • A（升级）条件：资金类告警是否忽略有分歧 → 跃竞负责人拍板；critical 告警 30 分钟无人认领、分级规范发布或修订 → 研发负责人拍板。其余告警的认领、分诊与关闭由告警值班人负责到底

7. 衡量指标

  • 认领率 = 已认领告警 / 全部告警，目标 critical 100%、error ≥ 95%
  • 认领时长 = 告警到认领的分钟数，目标 critical 中位数 ≤ 10 分钟
  • 闭环率 = 7 天内关闭的告警 / 全部告警，目标 ≥ 90%
  • 噪声率 = 误报和可降级告警 / 全部告警，目标 ≤ 20%
  • 长期未关闭数 = 超过 3 天未关闭的告警指纹数，目标 0

8. 低效诊断

  • 现象：告警没有认领和关闭机制，靠群里口头指派、反复追问“还没修好吗”（认领环节）｜依据：「告警通知群」2026-01、「告警通知群」2026-09
  • 现象：早期卡片只有计数，要人工去日志里查堆栈再贴到群里（告警信息环节）｜依据：「告警通知群」2026-02、「告警通知群」2026-09
  • 现象：业务/校验异常按 ERROR 抛出，429 按 critical 告警；是否降级、是否忽略反复争论（分级环节）｜依据：「告警通知群」2026-04、「告警通知群」2026-09
  • 现象：同一任务告警连续约 8 天无人回应；修复后遗留的历史数据忘了补（闭环环节）｜依据：「告警通知群」2026-10、「告警通知群」2026-09
  • 现象：死信无人认领，积压多日；dev 队列死信混进生产告警群（死信环节）｜依据：「告警通知群」2026-07
  • 现象：测试告警直接发到生产群，模板改了两次；告警规则没有命名和环境标签规范（变更环节）｜依据：「告警通知群」2026-01、「告警通知群」2026-08
  • 现象：巡检与告警配置基本由一人承担，没有备岗（运维单点）｜依据：「跃玩项目组」2026-08

9. 分支变体

  • prod 与 admin-prod 两套规则：admin-prod 单独 @ 对应后端
  • 死信队列（Pulsar）：payment-event 类涉及资金，必须当日处理；存单类属于业务数据，3 个工作日内处理；dev 队列不进生产群
  • 定时任务/巡检类告警（分账扫表、投影巡检、客户资料任务清理）：同一 taskId 重试失败超过 3 次，即视为需要处理
  • 基础设施类告警（Redis Sentinel TILT、节点 Pod 异常重启）：由运维处理，容量问题转 RND-79
  • 日常巡检：运维每日巡检（窗口 12 小时），结果写入日报；发现的问题按本流程登记

10. 待确认问题

  • 告警值班是否按周在后端成员间轮值？非工作时间的 critical 告警由谁接？
  • 分级规范（业务异常 WARN、429 INFO、支付拒付 CRITICAL）是否认可？
  • 死信重投或丢弃由谁决定？资金类是否必须经财务确认？
  • 是否建立独立的「告警测试群」，并在 Grafana 中分开 dev/prod 通知渠道？
  • 本 SOP 目前只有跃玩线证据，是否推广到 Leap 和字字可研线？
RND-79服务器容量治理与内部研发基础设施故障待新建108

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：服务器磁盘/日志暴涨、系统参数（inotify、磁盘类型、分区）不满足部署基线，或 Gitea/CI/NAS/内网服务器断网掉电、硬件损坏、服务迁集群或改地址时，做容量基线检查、日志轮转、故障报修排期和地址变更通知
  • 负责人：主责——IT 运维/基础设施负责人（当前：杨明学·推断待确认）；协同——运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）、网关/NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、开放平台后端/运维（当前：杨睿·推断待确认）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 建立服务台账 → ② 部署前基线检查 → ③ 容量监控告警 → ④ 报修建单 → ⑤ 响应与排期 → ⑥ 清理/扩容并补治理 → ⑦ 变更前公告 → ⑧ 验证并更新台账
  • 交付结果：服务器与服务台账（服务、负责人、地址、磁盘、证书到期）；部署基线检查记录；磁盘/日志告警和日志轮转配置；基础设施工单与变更公告
  • 状态依据：数据库日志曾涨到 68G、容器日志约 170G，写满磁盘导致全站 500，清理后一周内再次爆盘；单机部署参数（inotify、数据库放机械盘）出故障后才发现；CI 和硬件维修长期靠反复催问；内部服务不知道是谁部署的；端口/地址变更没有通知调用方，同一原因导致中断 3 次

1. 场景判定

  • 触发条件：磁盘使用率超阈值、日志暴涨、服务因磁盘满或 IO 阻塞报 500/503；新机或客户机部署前；Gitea/CI/NAS/编译机/软路由等内部设施故障或硬件损坏；服务迁集群、改端口、改 IP/域名
  • 典型说法：「你们没有做日志自动清理吗」「硬盘又满了」「每天问一遍什么时候修」「gitea 是哪位老师部署的来着」「还是说以后都按新地址走」「运维把 docker 里的迁到集群里去了」
  • 判断问题：这是基础设施容量/设施问题，还是业务代码问题？是否已经影响对外生产？如果对外生产已不可用，先按 RND-75 止血，再回到本流程治理根因
  • 不归本流程管：对外生产故障响应 → 请走 RND-75；CI 构建失败排查 → 请走 RND-38；CI/CD 建设 → 请走 RND-37；新服务器/云资源申请 → 请走 RND-23；接口字段/协议变更 → 请走 RND-19；容量压测评估 → 请走 RND-43；慢 SQL 治理 → 请走 RND-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
基础设施负责人 维护台账、基线、监控告警、报修排期、变更公告 A/R IT 运维/基础设施负责人（当前：杨明学·推断待确认）
部署研发 部署模板默认开启日志轮转，维护基线检查脚本 R 运维/部署研发（当前：宋祺睿、杨云峰·推断待确认）
服务负责人 每个内部服务有唯一负责人，负责自己服务的恢复 R CI（当前：吴世豪·推断待确认）；NewAPI 网关（当前：柯逸飞·推断待确认）；Gitea（当前：丁震宇·推断待确认）；开放平台（当前：杨睿·推断待确认）
变更执行人 迁集群、改端口/IP 前公告，并确认调用方已更新 R 服务方后端/运维（当前：王子明·推断待确认）
调用方 接收变更公告，按时更新配置并回复确认 R 对应调用服务负责人（当前：按接口指定）
优先级拍板人 运维需求排期冲突、硬件维修长期无进展时拍板 A（升级） 研发部门负责人（当前：丁震宇·推断待确认）
报修人 按模板提报 R 研发使用方（当前：吴世豪、宋祺睿等·推断待确认）

3. 办之前请准备

  • 服务/机器标识（名称、IP、所在机房或云）及负责人
  • 现象和时间、监控截图（磁盘/IO/内存），磁盘与目录占用结果，容器日志大小
  • 部署基线检查结果：系统盘大小、/data 磁盘类型（SSD/机械盘）、inotify 上限、Docker restart 策略、日志轮转配置
  • 变更类：变更内容、旧/新地址与端口、受影响调用方清单、回滚办法、计划时间窗口

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建台账：登记服务名、负责人、地址/端口、所在主机、磁盘、证书到期、备份情况；新服务上线当日登记 基础设施负责人 上线当日 飞书多维表格 服务器/服务台账 🔧飞书固化
2 部署基线：新机/客户机部署前跑检查脚本——数据库放 SSD，不放机械盘；单机超过 100 个用户先调 inotify 上限；Docker 配置 restart 策略和日志滚动；数据库日志自动清理 部署研发 部署前 基线检查脚本 基线报告 🤖自动化
3 容量监控：磁盘 ≥ 80% 预警、≥ 90% 严重，监控 IO、inode；证书到期前 30 天提醒；全部推飞书群并 @ 负责人 基础设施负责人 持续 监控 + 飞书机器人 告警 🤖自动化
4 报修/报障：内部设施故障在“基础设施报障表单”提交，自动通知负责人 报修人 发现后 飞书表单 工单 🔧飞书固化
5 响应与排期：断网、掉电、服务不可用 1 小时内响应，当日恢复或给出预计时间；硬件维修/供应商事项每 2 个工作日更新进度；需求类（CI、NAS）进排期表，由优先级拍板人排序 基础设施负责人 见左 排期表 进度更新 👤人工判断
6 清理/扩容：磁盘满时先清日志或扩容恢复服务，再补日志轮转配置，不能只清理不治理 基础设施负责人 / 服务负责人 告警后 2 小时内 — 处置记录 👤人工判断
7 变更公告：迁集群、改端口/IP/域名、改网络/防火墙前，在变更群公告（内容、受影响接口和调用方、时间窗、回滚办法），@ 调用方确认；接口地址写在配置里，不写死在代码中 变更执行人 变更前 1 个工作日 变更公告模板 公告 + 调用方确认 🔧飞书固化
8 验证并更新台账：变更或修复后，验证调用方、webhook、部署通道正常，更新台账中的地址 变更执行人 完成当日 台账 验证记录 🔧飞书固化

5. 交付物与模板

  • 交付物：服务器/服务台账、基线检查报告、容量告警配置、基础设施工单、变更公告
  • 台账字段：服务名、用途、负责人、备岗、主机/IP、端口/域名、所在机房或云、磁盘类型与容量、日志轮转（是/否）、备份策略、证书到期日、最近变更日期
  • 基线检查清单：系统盘大小与分区、数据盘类型、inotify max_user_watches/instances、Docker restart 策略、容器日志 max-size/max-file、数据库日志清理、监控探针已接入
  • 报障表单字段：设施名称、现象、开始时间、影响人员/项目、紧急程度、截图
  • 变更公告模板：变更内容、时间窗、受影响服务/接口/调用方、调用方需做的动作、回滚办法、联系人

6. 异常与升级

  • 磁盘满导致对外服务 500 → 按 RND-75 P1 处理，恢复后回本流程补治理
  • 硬件维修超过 5 个工作日无进展 → 升级研发负责人，决定替代资源或采购
  • 运维需求反复被插队 → 每两周排期会公开排序，由优先级拍板人决定
  • 变更未公告导致调用方中断 → 立即回滚或补配置，并记入复盘
  • 找不到服务负责人 → 视为台账缺项，基础设施负责人当日补齐
  • 优先级拍板人（研发负责人）A（升级）的条件：运维需求排期冲突且基础设施负责人无法协调；硬件维修超过 5 个工作日无进展；需要采购替代资源。其余由基础设施负责人拍板

7. 衡量指标

  • 台账覆盖率 = 已登记服务数 / 在用服务数，目标 100%
  • 爆盘次数 = 因磁盘/日志满导致的故障次数，目标每季度 0 次
  • 基线合规率 = 部署前完成基线检查的机器数 / 新部署机器数，目标 100%
  • 报修响应时长 = 报修到首次响应，目标工作时间 ≤ 1 小时；维修类进度更新间隔 ≤ 2 个工作日
  • 未公告变更次数 = 未提前公告就执行的地址/端口/网络变更次数，目标 0

8. 低效诊断

  • 现象：数据库日志没有自动清理，爆盘后只做临时清理，一周内再次爆满（容量治理环节）｜依据：「AI API」2026-07、「AI API」2026-09
  • 现象：交接过来的机器没有配日志轮转，前任提醒后才发现（交接环节）｜依据：「AI API」2026-07
  • 现象：系统参数不足、数据库放在机械盘，出故障后才发现（部署基线环节）｜依据：「Leap产研测」2026-10
  • 现象：CI 和硬件维修需求长期被插队，只能反复催问（排期环节）｜依据：「鸽子群模态分群」2026-03、「鸽子群模态分群」2026-04
  • 现象：不知道内部服务由谁部署，多人猜原因；软路由与生产服务在同一台机器上，影响面没有评估过（归属环节）｜依据：「跃迁AI总动员」2026-08
  • 现象：地址/端口变更只 @ 个别人或临时说明，后来的人重复询问，调用方因同一原因中断 3 次（变更通知环节）｜依据：「跃迁AI总动员」2026-08、「跃玩会员端」2026-07、「跃玩会员端」2026-08

9. 分支变体

  • 容器日志写满磁盘：Docker 日志驱动配置滚动；数据库日志单独设清理策略
  • 单机部署基线：单盘机型系统盘固定 55.5GB，其余分配给 /data；双盘机型另行规划；FDE 培训机、测试机同样执行
  • 内部研发设施（Gitea、CI、NAS、编译机、软路由）：机房掉电/断网由基础设施负责人处理；CI 构建失败转 RND-38
  • 服务迁集群/改端口（跃玩线）：由运维执行，必须通知会员端等调用方，并检查 Drone webhook 等部署通道
  • 外包/老客户项目服务器：纳入台账，登记证书到期日和 restart 策略

10. 待确认问题

  • 基础设施负责人是否就是当前推断人员？是否需要指定备岗来消除单点？
  • 磁盘告警阈值 80%/90% 是否合适？夜间告警由谁接收？
  • 内部设施报障入口用飞书表单还是 Gitea 工单？
  • 是否全公司统一一个变更公告群？提前 1 个工作日公告是否可行？
  • 跃玩线的集群和服务器是否并入同一份台账？
RND-80系统/主体迁移与生产数据订正待新建250

状态：待新建｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：业务主体或支付商户迁移、老系统迁服务器、测试环境转正式或新旧版本切换、内部生产环境迁移；以及线上缺陷产生异常订单/金额数据，需要圈定影响范围并订正或退款时
  • 负责人：主责——迁移/订正负责人（按系统指定；当前：跃玩线 王子明、Leap 线 王皓南·推断待确认）；协同——跃竞负责人（当前：徐莉·推断待确认）、产品总监（当前：杨萌·推断待确认）、运维（当前：席博田、杨明学·推断待确认）、后端（当前：蒋兴武、张楠·推断待确认）、前端（当前：魏小东·推断待确认）、测试（当前：赵伟龙·推断待确认）、CRM 研发（当前：陈子康、郭逸非·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（创始人兼 CTO）
  • 核心流程：① 立项与影响评估 → ② 迁移清单与负责人 → ③ 迁移测试演练 → ④ 备份 → ⑤ 公告与冻结 → ⑥ 执行 → ⑦ 核对验收 → ⑧ 切换与观察 → ⑨ 数据订正（分支）→ ⑩ 归档
  • 交付结果：带回滚点的迁移方案和检查清单；迁移前备份和迁移后核对报告；停服/切换通知；数据订正审批单与执行记录；异常订单台账
  • 状态依据：主体/商户迁移、会员数据迁移、CRM 迁移、102 迁移，每次都临时拉任务清单，负责人要事后补；迁移时间多次调整；CRM 迁移后用户以为数据“消失”，旧合同未迁；异常订单靠导出文件在群里流转，同一天多次推翻判断，订正没有审批

1. 场景判定

  • 触发条件：小程序/业务主体变更、支付商户迁移；老系统迁到新主体服务器；测试环境转正式、旧版换新版域名；公司生产环境换机器或换网关；运营或告警发现订单金额、分账、余额与明细对不上
  • 典型说法：「迁移要做的往里面加，免得忘了」「负责人对应填一下」「明日 12 点后请不要在测试环境中更新信息」「要么晚上迁，要么停机一天，要么不停机但钱会乱」「这种单只能赶紧给退掉了」「这个订单金额计算错误了吗？」
  • 判断问题：会不会改动生产数据（批量迁移、订正、退款）或切换用户入口？会 → 本流程；只是表结构变更 → RND-34
  • 不归本流程管：常规 Schema 变更与迁移脚本 → 请走 RND-34；一般生产配置变更 → 请走 RND-58；支付通道接入与商户日常管理 → 请走 RND-66；故障止血 → 请走 RND-75；资金/分账异常的财务修复与退款审批 → 请走 FIN-25（资金/分账异常排查与数据修复）；计费扣费类退补 → 请走 FIN-29（计费扣费异常核查与退补）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
迁移/订正负责人 出方案和清单，编写脚本，执行，做回滚决策 A/R 跃玩线后端负责人（当前：王子明·推断待确认）；Leap 线技术负责人（当前：王皓南·推断待确认）
业务决策人 选定迁移窗口与停服时长、发对外通知、与第三方（支付通道）沟通排期 R 跃竞负责人（当前：徐莉·推断待确认）；产品总监（当前：杨萌·推断待确认）
运维 准备服务器、备份与恢复、冷迁移、域名/CDN R 跃竞运维（当前：席博田·推断待确认）；IT 运维（当前：杨明学·推断待确认）
研发执行 迁移/校验脚本、存量数据处理、前端迁移入口 R 后端（当前：蒋兴武、张楠·推断待确认）；前端（当前：魏小东·推断待确认）
测试 迁移测试用例，迁移后核对与主链路验证 R 测试（当前：赵伟龙·推断待确认）
CRM 迁移执行 CRM 环境迁移、发通知、推动用户切换 R CRM 研发（当前：陈子康、郭逸非·推断待确认）；CRM 管理员（当前：闫登辉·推断待确认）
财务 涉及金额、退款、分账的订正确认（资金类订正须其书面确认后执行） C 财务专员（当前：待指定）
研发负责人 审批高风险迁移和订正 A（升级） 研发部门负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 迁移范围：涉及的系统和数据表，用户/商户/订单数量，依赖顺序（主体 → 商户 → 小程序 → 数据）
  • 风险清单：待付款订单、迁移前已申请但未审核的退款、旧格式订单、跨主体用户标识（union_id 不能跨主体，需要映射方案，如兑换码或编号）
  • 备份：全量数据库备份并校验可恢复；备份脚本随迁移包一起交付
  • 回滚点和回滚步骤；第三方（支付通道、云厂商）的排期确认
  • 通知对象清单：内部用户、俱乐部/客户、销售
  • 订正场景：异常单清单（订单号、错误类型）、根因初判、订正 SQL/脚本、复核人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项评估：说明迁移原因、范围、风险、停服时长和方案选项（夜间迁/停机一天/不停机），由业务决策人选定 迁移负责人 计划迁移日前 5 个工作日 飞书文档 迁移方案 👤人工判断
2 清单与负责人：在迁移检查清单中逐项列出事项、负责人、依赖、截止时间，每一项都必须有负责人 迁移负责人 方案确认后 1 个工作日内 多维表格 / 飞书任务 检查清单 🔧飞书固化
3 测试演练：在测试/干跑环境覆盖各商户和各类数据情形，补齐适配脚本；确认迁移命令只在目标环境执行 测试 + 研发执行 迁移前 2 个工作日完成 测试环境 迁移测试报告 🤖+👤
4 备份：迁移前全量备份并校验可恢复；配置定时滚动备份 运维 迁移开始前 1 小时内完成 备份脚本 备份记录 🤖自动化
5 公告与冻结：提前通知时间窗、入口变化和冻结规则（“××点后不要在旧环境录入”），迁移当天再提醒；迁移前清理待付款订单 业务决策人 迁移前 1 个工作日；当天再提醒 群公告模板 / 机器人 公告 🔧飞书固化
6 执行：按清单顺序迁移，在群内同步进度；超出窗口 30 分钟仍未完成的，由迁移负责人决定回滚还是延期 迁移负责人 时间窗内 迁移脚本 执行记录 👤人工判断
7 核对验收：用校验脚本比对迁移前后的用户数、订单数、金额、余额、合同等；测试跑主链路；不一致项登记并处理 测试 + 研发执行 迁移后 2 小时内 对账脚本 核对报告 🤖自动化
8 切换与观察：发布新入口并置顶，旧环境下线或改为只读；7 天观察期内每天看告警和用户反馈 业务决策人 + 迁移负责人 迁移当日起 7 天 群公告、告警群 观察记录 🔧飞书固化
9 数据订正（分支）：导出异常单并分类 → 圈定影响范围和根因 → 编写订正脚本 → 提交订正申请（影响单数、SQL、复核人、是否退款）→ 资金类经财务确认 → 执行并复核 → 登记台账 订正负责人 发现后 1 个工作日内提交申请；客户正在使用的单据当日处理 飞书审批、多维表格 订正记录 🔧+👤
10 归档：迁移方案、清单、核对报告、订正记录归档；把本次暴露的问题补进清单模板 迁移负责人 完成后 3 个工作日内 飞书知识库 归档文档 🔧飞书固化

5. 交付物与模板

  • 交付物：迁移方案、检查清单、备份记录、核对报告、迁移通知、订正审批单、异常订单台账
  • 迁移检查清单字段：事项、负责人、依赖、开始/截止时间、状态、验证人、回滚步骤
  • 迁移通知模板：时间窗、受影响系统和入口、冻结要求、新入口、数据范围（写明哪些不迁）、联系人
  • 核对报告字段：核对对象（用户/订单/金额/余额/合同）、迁移前数量、迁移后数量、差异、处理结论
  • 数据订正申请单字段：发现来源、异常类型、影响订单/用户数、根因、订正 SQL/脚本、执行人、复核人、是否涉及退款或金额、财务确认
  • 异常订单台账字段：订单号、错误类型、处置方式（退款/人工修复/脚本订正）、状态、确认人

6. 异常与升级

  • 第三方排期变化（如支付通道）→ 业务决策人重新确定窗口并同步公告；窗口未确认前不执行
  • 核对发现资金或余额不一致 → 冻结相关功能，通知财务和研发负责人，当日拿出处理方案
  • 迁移后用户反馈数据“消失” → 先核对是录在了旧环境，还是不在迁移范围内，2 小时内答复；必要时补迁
  • 数据被误改 → 从最近一次备份恢复，记录恢复条数并复核
  • 订正判断反复推翻 → 暂停执行，由订正负责人和研发负责人复核根因后再执行
  • AI 助手给出的查证结论 → 必须由开发结合代码和数据确认后，才能定性为缺陷
  • 研发负责人 A（升级）的条件：业务主体/支付商户迁移、停服超过 1 个工作日、跨主体用户映射等高风险迁移；涉及资金或批量订正；核对发现资金或余额不一致；订正判断反复推翻。其余迁移与订正由迁移/订正负责人拍板

7. 衡量指标

  • 迁移一次成功率 = 未回滚的迁移次数 / 全部迁移次数，目标 ≥ 90%
  • 核对差异数 = 迁移后无法解释的差异条数，目标 0
  • 迁移计划变更次数 = 确定窗口后又改期的次数，目标 ≤ 1
  • 订正审批覆盖率 = 走审批的生产数据订正次数 / 全部订正次数，目标 100%
  • 异常单处理时长 = 发现到订正完成，目标 ≤ 2 个工作日

8. 低效诊断

  • 现象：迁移事项临时拉清单，负责人缺失要逐项补，靠催填（计划环节）｜依据：「跃玩项目组」2026-03
  • 现象：迁移时间多次调整，受第三方排期牵制（排期环节）｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-03
  • 现象：迁移测试后才发现旧订单展示、迁移前的退款申请无法审核，需追加脚本；新小程序正式服接了测试服接口（测试环节）｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-03
  • 现象：迁移脚本在错误环境误跑、表名出错；关键人请假，生产是否还用旧数据库没人能答（执行环节）｜依据：「Leap产研测」2026-08
  • 现象：用户在旧版本里录入，旧合同未迁，用户以为数据消失（切换通知环节）｜依据：「跃迁CRM反馈群」2026-09、「跃迁CRM反馈群」2026-10
  • 现象：异常单靠导出文件在群里流转，同一天多次推翻判断，没有订正审批（订正环节）｜依据：「告警通知群」2026-04
  • 现象：AI 助手只查库不看代码，结论前后矛盾，导出结果刷屏（查证环节）｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09

9. 分支变体

  • 支付商户迁移（跃竞主体）：与支付通道确认窗口，迁移前清理待付款订单，迁移后观察一周；多商户分账和联盟提现另行设计
  • 业务主体迁移（弈荟/跃玩迁到跃竞）：两套会员体系并行；union_id 不能跨主体，用兑换码或编号映射新旧用户；过渡期老会员端只做展示
  • 老系统冷迁移（EG 老后台）：打包数据库、发布包和反向代理配置；数据库如需公网访问，必须用强密码和非常用端口；迁移后定时滚动备份（如保留最近 3 天）
  • CRM 测试转正式 / 新旧版本切换：冻结旧环境录入，写明迁移范围（含合同），新入口置顶
  • Leap 102 内部生产迁移：先在 51 等环境灰度；余额等数据迁移后核对；迁移结果用机器人卡片通知
  • 异常订单订正：金额不一致的单据优先退款；迁移遗留单据人工修复；资金类必须经财务确认

10. 待确认问题

  • 迁移/订正负责人是否按业务线固定（跃玩线、Leap 线各一人）？
  • 生产数据订正是否必须走飞书审批？审批人是研发负责人，还是业务负责人 + 财务？
  • 迁移公告提前 1 个工作日、观察期 7 天，是否合适？
  • 备份保留策略（滚动 3 天）是否满足 2B 客户要求？是否需要定期做恢复演练？
  • 跨主体用户映射表由谁维护？过渡期多长？
RND-81内部 AI 机器人/Agent 平台部署、配置与使用边界待新建192

状态：待新建｜证据：有证据（卡片 15 张 / 会话 10 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：要在飞书群或私聊中上线、升级、迁移、下线内部 AI 机器人（OpenClaw、Hermes、LeapAll 机器人、工单助手、排障 MCP 助手、许愿机等），或机器人出现越权、刷屏、乱提单、幻觉、配置丢失、不响应时启动
  • 负责人：主责——内部 AI 机器人平台负责人（当前：王皓南·推断待确认）；协同——运维/镜像维护（当前：宋祺睿、杨明学·推断待确认）、各机器人 owner（当前：岳阳、杨萌、魏宗浩、王子明·推断待确认）、测试负责人（当前：张东郅·推断待确认）、飞书管理员/安全（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 上线登记 → ② 权限矩阵评审 → ③ 按模板配置 → ④ 镜像构建与部署 → ⑤ 上线前测试 → ⑥ 发布使用说明 → ⑦ 规则变更走评审 → ⑧ 故障值守与月度复核
  • 交付结果：机器人台账中的完整登记（owner、备岗、模型、技能、权限、可用范围、成本上限）、受版本管理的配置与提示词、群内使用说明卡片、变更与故障记录
  • 状态依据：2026-03～10 十余个机器人由个人各自搭建，无台账、无配置模板、无变更评审；群内反复出现越权提单、刷屏后被要求禁言或移出、任意成员口头改写全局规则、重启后规则丢失、机器人声称完成实际未执行、维护人休假后无人接手，累计约 150 次

1. 场景判定

  • 触发条件：新建或升级群内机器人/Agent；给机器人加技能或工具（Gitea、工单、数据库、支付查询、日志、服务器）；更换模型；机器人在工作群刷屏、越权、误建单、回显凭据；机器人不回复、上下文超限、网关报错；机器人 owner 休假或离岗
  • 典型说法：「别人没 at 你的消息，你别啥都回」「没让你提就别提」「怎么给你安装全局的 skills」「检查 log 为什么没发言」「镜像推哪」「这个群里的机器人重新规整一下，确认可以用的放在这里」
  • 判断问题：对象是不是“公司内部人员在飞书里调用的 AI 机器人/Agent”？要处理的是它的部署、配置、权限或行为边界吗？
  • 不归本流程管：飞书自建应用/机器人权限申请与停用 → 请走 X-SEC-33；机器人上线安全检查 → 请走 X-SEC-37；对外产品 Agent 的安全与权限设计 → 请走 RND-20；Agent 产品容器镜像发布 → 请走 RND-55；模型 API Key 与额度 → 请走 RND-27；Agent 能力评测 → 请走 RND-82；夜间自动代码评审任务 → 请走 RND-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
平台负责人 定机器人使用规范、审权限矩阵、审全局规则变更、月度复核 A 内部 AI 机器人平台负责人（当前：王皓南·推断待确认）
机器人 owner 登记、配置、上线说明、日常维护与故障处理 R 各机器人 owner（当前：岳阳、杨萌、魏宗浩、王子明·推断待确认）
运维/镜像维护 镜像构建推送、部署、回滚、运行机器维护 R 运维/发版工程师（当前：宋祺睿、杨明学·推断待确认）
测试负责人 执行上线前测试用例、登记机器人缺陷 R 测试负责人（当前：张东郅·推断待确认）
飞书管理员/安全 可用范围开通、凭据存放、权限审批 C 飞书管理员/安全（当前：待指定）
CTO 审批生产、资金、源码类高风险权限，裁决争议 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
变更提出人 提交规则/技能/提示词变更 PR，写明作用域 R 机器人 owner 或提出变更的使用成员
使用者 按说明使用、反馈问题 I 各群使用成员

3. 办之前请准备

  • 用途说明：服务哪些群、解决什么任务、明确不做什么
  • 模型与额度来源、月度成本上限、可调用高成本工具的人员名单
  • 工具/技能清单及每项权限（只读/可写），涉及数据库、支付通道、生产服务器、源码的单独列出
  • 凭据引用方式：密钥存放位置，不写入记忆、提示词和环境变量明文
  • owner 与备岗名单、可用范围（成员/群）
  • 配置模板：SOUL/USER/TOOLS/MEMORY、系统提示词、通道配置（只响应 @、debounce、bindings）、成员别名与 Gitea 用户名映射表
  • 部署方式：镜像地址与版本号、运行机器、重启方式（Docker 前台或 systemd）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填机器人上线登记：用途、owner、备岗、模型、技能、权限、可用范围、成本上限 机器人 owner 上线前 1 个工作日 多维表格（机器人台账） 台账记录 🔧飞书固化
2 评审权限矩阵：默认只读；建单、指派、关单、改配置、重启等写操作列白名单并要求人工确认；数据库只用只读审计账号，支付通道仅开查询类工具 平台负责人；高风险项加 CTO 收到登记后 1 个工作日内 台账 + X-SEC-37 检查单 权限矩阵 👤人工判断
3 按模板配置：只响应 @ 与私聊、非工作时段静默、debounce、上下文压缩阈值、别名表；禁止自建话题、禁止自改全局配置、禁止暴露内部编号与源码 机器人 owner 1 个工作日内 配置仓库（Gitea） 配置提交记录 🤖+👤
4 构建镜像推统一镜像仓库，版本号和变更说明写入 Release，由机器人推送群通知；禁止用群文件压缩包管理版本 运维/镜像维护 配置合入当天 Gitea CI + 镜像仓库 镜像版本、发布说明 🤖自动化
5 上线前测试：@ 才响应、越权指令被拒、建单前确认且建单后回贴链接、文件实际发送成功、凭据不回显、定时任务落表可查 测试负责人 部署后 1 个工作日内 测试用例清单 测试记录 🔧+👤
6 设置飞书可用范围，群内发使用说明卡片：能做什么、怎么 @、不做什么、找谁反馈、私聊需先主动发起一次 机器人 owner 上线当天 飞书开发者后台 + 群卡片 使用说明卡片 🔧飞书固化
7 规则/技能/提示词变更：提 PR 写明作用域（个人/群/全局），平台负责人评审后合入；群内口头指令只对发出人本人生效 变更提出人 → 平台负责人 提交后 2 个工作日内评审 Gitea PR 变更记录、可回滚版本 👤人工判断
8 故障处理：以日志而非机器人自述判断 → 回滚上一镜像/配置或切换模型 → 台账记故障与根因 机器人 owner；不在时备岗 工作时间 2 小时内响应 日志 + 台账 故障记录 👤人工判断
9 月度复核：活跃度、调用成本、权限、owner 是否在岗；无人维护或无用的下线并回收凭据 平台负责人 每月第 1 周 台账 + 成本报表 复核结论 🔧+🤖

5. 交付物与模板

  • 交付物：机器人台账记录、权限矩阵、配置仓库与镜像版本、上线测试记录、使用说明卡片、变更与故障记录
  • 机器人台账字段：名称、用途、服务群、owner、备岗、模型与档位、额度来源、月度成本上限、技能/工具清单、权限级别（只读/写白名单）、凭据存放位置、镜像地址与版本、运行机器、重启方式、可用范围、上线日期、最近复核日期、状态（试用/在线/停用）
  • 配置模板：SOUL.md（身份、禁区、回复格式）、TOOLS.md（工具与调用前提）、USER 别名表、MEMORY 作用域说明（个人/群/全局）
  • 上线测试用例清单：触发规则、越权拒绝、建单确认、结果回贴、文件发送、凭据不回显、定时任务落表、上下文超限处理
  • 机器人缺陷单（Gitea Issue）：输入、期望、实际、所用模型、工具调用日志、复现步骤

6. 异常与升级

  • 机器人越权执行或误建、误关、误指派工单 → 立即收回写权限或停用，恢复工单 → 当天升级平台负责人；涉及生产或资金立即升级 CTO
  • 凭据或源码被回显到群里 → 撤回消息、轮换密钥 → 1 小时内按 X-SEC-11 处置
  • 机器人在故障处理群刷屏干扰 → 群管理员先禁言或移出 → owner 当天修正触发规则后再恢复
  • 调用成本超过月度上限 → 限制可调用人员与高成本工具 → 1 个工作日内升级平台负责人
  • owner 休假或离岗 → 备岗接管；无备岗时平台负责人 1 个工作日内指定，离岗交接走 RND-85
  • 成员口头要求修改全局规则 → 机器人拒绝并提示走 PR → 平台负责人 2 个工作日内给结论
  • 模型持续报错（500、降智、不调用工具） → 按预案切换备用模型 → 4 小时内未恢复升级运维/镜像维护
  • 升级至 CTO 拍板（A（升级））的条件：权限矩阵涉及生产服务器、资金/支付通道、源码写权限；机器人越权操作波及生产或资金；平台负责人与 owner 对权限或下线意见不一致 → 平台负责人当天提交 CTO 裁决

7. 衡量指标

  • 台账覆盖率 = 已登记机器人数 / 群内实际运行机器人数，目标 100%
  • 越权/误操作事件数 = 每月机器人误建单、误指派、越权执行次数，目标 0
  • 规则变更走 PR 比例 = 走 PR 的全局规则变更 / 全部全局规则变更，目标 100%
  • 故障恢复时长 = 发现到恢复的工作小时，目标 ≤ 4 小时
  • 备岗覆盖率 = 有备岗的机器人 / 在线机器人，目标 100%
  • 成本达标率 = 未超月度上限的机器人 / 在线机器人，目标 100%

8. 低效诊断

  • 现象：机器人上线后直接在主工作群全员试用，出现吞消息、幻觉建单、误指派、刷屏，最终被要求移出（上线前测试环节缺失）｜依据：「Leap产研测」2026-06
  • 现象：机器人无 @ 也插话，在紧急故障群添乱被要求禁言（触发规则环节）｜依据：「工程咨询产研」2026-07、「Leap产研测」2026-06
  • 现象：任意成员口头指令被持久化为全局行为，随后又被推翻，约 6 次返工（规则变更无评审、无作用域）｜依据：「leapall逗狗群」2026-06
  • 现象：重启后规则丢失需反复交代；同一指令要对多个机器人逐个下发，各机器人反应不一（配置未模板化、未版本管理）｜依据：「Leap产研测」2026-06、「Clawgroup工作群」2026-04
  • 现象：机器人自述“已完成/已发送”与实际不符，定时任务未落表成幽灵任务（结果校验环节）｜依据：「leapall逗狗群」2026-06、「Bot测试」2026-03
  • 现象：机器人识图幻觉、回答前不确认功能是否存在、往产品 Badcase 系统提交自身问题（行为边界环节）｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07
  • 现象：镜像过时、未加载提示词和技能，镜像推到哪里反复问，版本靠群文件压缩包（部署发布环节）｜依据：「跃迁基座许愿机」2026-05
  • 现象：维护人休假后机器人停摆，工单改为人工补建，授权链接过期需重发（值守交接环节）｜依据：「Leap产研测」2026-07、「鼎慧产研决策部」2026-07
  • 现象：多人各自搭建同类 MCP 与技能，权限边界依赖作者自律（登记与复用环节）｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09、「随便瞎聊啦～」2026-03
  • 现象：环境变量中的凭证被机器人回显（凭据管理环节）｜依据：「Clawgroup工作群」2026-04

9. 分支变体

  • 研发群工单/日报助手：允许建单，但建单前须人工确认，建单后把链接贴回话题，标签格式同仓库已有 issue，不默认指派；一个工单可建独立群，完结后解散
  • 运维/客服排障 MCP 助手（跃竞）：数据库仅只读审计账号、支付通道仅查询类工具、SQL 白名单、提示注入测试和登录二维码单次锁定为上线必测项
  • 个人助理型机器人：仅 owner 可改规则，不进公共工作群；配对授权由 owner 在本机执行
  • 定时任务类：创建后必须回显任务列表核对；定时执行环境须具备发文件能力
  • 实验环境镜像（许愿机）：国内与海外服务器两套镜像，版本号统一，变更写发布说明
  • 运行方式：Docker 前台运行与 systemd 托管的重启方式不同，须写入台账；飞书与 Telegram 通道分别配置

10. 待确认问题

  • 平台负责人是否由 Leap 研发负责人担任？还是交给运维/发版岗统一管理？
  • 机器人台账放研发多维表格还是 IT 资产系统？
  • 高成本工具（命令行编码 Agent 等）的调用名单和月度上限由谁定？
  • 哪些群禁止接入机器人（如客户群、故障处理群）？
  • 规则变更 PR 2 个工作日内评审是否可行？
  • 机器人源码与配置的保密级别如何划分？
  • 飞书可用范围是否统一由飞书管理员开通，并纳入新人入职清单？
RND-82Agent 评测集与评测体系待优化192

状态：待优化｜证据：有证据（卡片 9 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨3 × 险4

  • 适用场景：需要量化 Agent（LeapAgent/LeapAll/LeapCore）或某个模型、skill 的能力，发版前做回归评测，多方案赛马，或测算行业报告生成效果与单篇成本时启动
  • 负责人：主责——Agent 评测负责人（当前：张东郅·推断待确认）；协同——Leap 研发负责人（评测方向与流程设计，当前：王皓南·推断待确认）、产品总监（功能清单与跟进会，当前：杨萌·推断待确认）、评测工程师（当前：黄霆瑄、董洪焜·推断待确认）、Agent 研发（当前：岳阳、李铭熙·推断待确认）、报告跑测研发（当前：陈锦杰、黄飞鹏·推断待确认）、业务专家（当前：王满·推断待确认）、模型网关 API owner（当前：柯逸飞·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 定评测目的与基线 → ② 建/更新评测集与 verifier → ③ 准备环境、账号与额度 → ④ 批量跑评测 → ⑤ 失败聚类归因 → ⑥ 改动后定向+回归评测 → ⑦ 出报告并例会审阅 → ⑧ 失败样本回流
  • 交付结果：版本化评测集（case、verifier、评分标准）、评测报告（图表/HTML，含得分、成本、时长、失败归因）、评测看板、发版回归结论
  • 状态依据：2026-06 已明确要建自有闭源 Agent Benchmark 并指定第一负责人，08 月起有评测群、功能清单与评测环境；但 09～10 月仍出现“0 人在搞”“没看到进度”，评测粒度反复调整，报告生成测评因样本篇幅不足重跑约 3 次，口径不一

1. 场景判定

  • 触发条件：Agent 能力明显落后竞品需系统提升；版本发布前需要回归；新模型、新 skill 或插件上线前验证效果与成本；多个方案或模型赛马；市场需要对比数据
  • 典型说法：「要找 50 个不好用的失败任务」「每个人提交评测集，效果好的胜出」「不够一篇完整报告没法算成本」「eval 最重要的还是构建 dataset」「从产品出发，不要从代码出发」
  • 判断问题：这次要回答的是“Agent/模型/skill 好不好、比上一版或对手好多少”吗？是否需要可重复的数据集和评分口径？
  • 不归本流程管：上游模型/供应商商务选型 → 请走 RND-68；产品侧模型档位配置 → 请走 X-PRD-18；行业报告领域专家验收 → 请走 X-PRD-32；Badcase 记录与分诊 → 请走 RND-02 / X-PRD-08；冒烟测试与核心用例回归 → 请走 RND-42；性能压测 → 请走 RND-43；单个内部 skill 发布 → 请走 RND-87

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
评测负责人 评测计划、看板、例会、报告与发版回归结论 A/R Agent 评测负责人（当前：张东郅·推断待确认）
研发负责人 定评测目的与流程设计，裁决口径争议 C/A（升级） Leap 研发负责人（当前：王皓南·推断待确认）
产品总监 提供产品承诺功能清单，组织跟进会 C 产品总监（当前：杨萌·推断待确认）
评测工程师 构造数据集与 verifier、搭环境、跑评测 R 评测工程师（当前：黄霆瑄、董洪焜·推断待确认）
Agent 研发 失败归因、改动、定向评测 R Agent 研发（当前：岳阳、李铭熙·推断待确认）
报告跑测研发 行业报告多模型跑测，记录时长与费用 R 后端/产品研发（当前：陈锦杰、黄飞鹏·推断待确认）
业务专家 报告类结果效果评审、测算类模拟操作 C 工程咨询业务专家（当前：王满·推断待确认）
模型网关 API owner 评测 API、账号与额度 C 模型网关研发（当前：柯逸飞·推断待确认）
CTO 评测资源投入与优先级 I/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 评测目的单：能力评测还是回归评测、被测对象与版本、对比基线、通过线
  • 产品承诺功能清单（网盘、PPT、Word、搜索、Skill 加载等）
  • 失败任务来源：Badcase 表、工单、dogfooding 记录、支持队列
  • 评测环境：专用评测服务器/容器环境、独立测试账号、评测 API 与额度
  • 评分方式：代码 verifier、LLM judge、人工评分标准（含评分表）
  • 报告/测算类：完整篇幅的基准项目材料、任务开始与结束余额记录方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 定评测目的、范围、基线和通过线，登记评测看板并指定每项责任人 评测负责人 发起后 2 个工作日内 多维表格评测看板 评测任务卡 🔧+👤
2 构建/更新评测集：按产品承诺功能构造 case，补充失败任务（每轮 ≥ 50 条），每条配 verifier 或评分标准，纳入版本管理 评测工程师 5 个工作日内 Gitea 评测仓库 评测集新版本 🤖+👤
3 申请评测账号与 API 额度、准备环境，与 API owner 确认接口与排期 评测工程师 2 个工作日内 评测服务器 + 模型网关 可用评测环境 👤人工
4 批量跑评测：每个 case 多次 trial，记录得分、token、缓存命中、时长、费用 评测工程师 / 报告跑测研发 按计划，优先夜间批跑 评测脚本 原始结果 🤖自动化
5 按任务聚类失败、读 transcript 归因（模型/提示词/工具/环境），形成假设 Agent 研发 + 评测负责人 跑完后 2 个工作日内 评测报告 归因表 👤人工判断
6 改动后先跑定向评测，再跑全量回归，无劣化才进入灰度或发版 Agent 研发 每次改动后，发版前 1 个工作日完成 CI 回归任务 回归结论 🤖自动化
7 出报告（图表/HTML，不贴控制台截图），周四评测例会审阅，周二小会对卡点，纪要发群 评测负责人 每周 飞书文档 / HTML 评测报告、会议纪要 🤖+👤
8 失败样本回流评测集与需求池；回归结论作为发版闸门输入 评测负责人 报告后 1 个工作日内 多维表格 回流记录 🔧飞书固化

5. 交付物与模板

  • 交付物：评测集（含版本号）、评测报告、归因表、回归结论、评测看板、例会纪要
  • 评测 case 字段：编号、所属功能、任务描述、输入材料、期望结果、verifier 类型（代码/LLM/人工）、评分标准、难度、来源（构造/失败回流/开源）、最近通过版本
  • 评测看板字段：评测项、目的、被测版本、负责人、状态、阻塞项、截止日、报告链接
  • 成本测评表字段：模型档位、样本编号、篇幅（字数）、时长、开始余额、结束余额、费用、效果评分、评审人岗位
  • 报告模板：被测对象与基线、总分与分项、成本与时长、失败聚类与归因、结论与建议动作

6. 异常与升级

  • 评测环境与真实环境不一致 → 停用该次结论并修环境 → 1 个工作日内升级研发负责人
  • 评测 API 或额度不足 → 按 RND-27 申请临时额度 → 当天联系模型网关 API owner
  • 口径争议（过程评估 vs 结果评估、单步 vs 多步） → 例会上由研发负责人拍板并写入评测规范 → 1 周内定
  • 报告类样本篇幅不足、成本不可比 → 打回重跑 → 2 个工作日内补齐
  • 评测项连续 2 周无进展 → 评测负责人在例会通报卡点 → 升级 CTO 调配人手
  • 发版前回归分数下降超过通过线 → 阻断发版并转 RND-51 → 当天通知研发负责人
  • 升级拍板（A（升级））：评测口径争议、通过线设定或是否阻断发版有分歧时，由研发负责人在例会拍板；评测资源（人手、服务器、额度）不足或评测项连续 2 周无进展时，由 CTO 拍板调配；日常评测计划与报告结论由评测负责人负责

7. 衡量指标

  • 承诺功能覆盖率 = 已有评测 case 的承诺功能 / 承诺功能总数，目标 100%
  • 回归执行率 = 发版前跑过回归评测的版本 / 发版总数，目标 100%
  • 失败样本回流时长 = 发现失败到入集的工作日，目标 ≤ 5 个工作日
  • 评测报告按期率 = 按周产出报告的周数 / 总周数，目标 ≥ 90%
  • 核心任务成功率、单任务平均成本、平均时长：按版本看趋势，目标逐版不劣化

8. 低效诊断

  • 现象：修复引入新 bug，长任务稳定性靠人工跑固定场景，无自动化回归集（回归环节）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：评测流程设计只在群聊讨论数十条仍未对齐，未成文，人手临时抽调（立项与分工环节）｜依据：「跃迁AI总动员」2026-06、「鼎慧产研决策部」2026-06
  • 现象：报告类评测没有数据集，每次手工生成再人工评，结果评估与过程评估分歧（数据集与评分口径环节）｜依据：「工程咨询产研」2026-02
  • 现象：测试输入篇幅不足导致单篇成本不准需重跑，每换模型全套重测（基准样本环节）｜依据：「【行业版Leapcore】工程版」2026-07、「【行业版Leapcore】工程版」2026-08
  • 现象：赛马各自评测，数据口径对不上（口径统一环节）｜依据：「Leap产研测」2026-07
  • 现象：跟进会参会面窄、成员不知道评测群，出现“0 人在搞”“没看到进度”（进度同步环节）｜依据：「Leap产研决策部」2026-09、「Leap产研决策部」2026-10、「LeapAgent评测」2026-10
  • 现象：评测粒度单步/多步反复调整，适配器随 Agent 更新需反复改（评测设计环节）｜依据：「LeapAgent评测」2026-08、「LeapAgent评测」2026-10

9. 分支变体

  • LeapAgent 能力评测：承诺功能数据集 + 开源数据集 + 构造多轮任务与 verifier，专用评测环境与独立测试账号
  • 回归评测：固定功能回归清单（网盘、PPT 等），与发版挂钩
  • 字字可研/工程版报告：经济/标准/高档模型各跑 N 份完整篇幅样本，记录时长与费用，业务专家评审效果，不达标先优化 skill 再重跑；测算类由业务专家模拟真实操作并记录前后余额
  • 模型/skill 赛马与竞品对比：对外宣传用的数据须研发负责人复核口径
  • Skill 发布前评测：见 RND-87
  • 长任务稳定性：固定长任务场景 + SSE 事件录制重放，降低演示风险

10. 待确认问题

  • 评测第一负责人是否仍为当前主责？测试与评测是否分岗？
  • 周四评测例会 + 周二小会是否固定？参会范围包括哪些组？
  • 评测集统一放 Gitea 还是多维表格？现有评测 wiki 是否作为规范基础？
  • 发版闸门：回归分数下降多少即阻断？
  • 评测专用服务器、测试账号和额度由谁统一申请？额度上限多少？
  • 报告类评测“完整篇幅”的标准字数是多少？
RND-83Agent 生成文档质量问题治理待优化180

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：LeapCore/LeapAll 生成的 PPT、Word、Excel、HTML 出现格式错乱、字体缺失、水印、标题颜色异常、导出失败、预览不全等问题，或客户演示前需确认默认文档格式与组织模板时启动
  • 负责人：主责——文档生成研发负责人（当前：马漳毓·推断待确认）；协同——Agent 研发（当前：岳阳·推断待确认）、Word 套件研发（当前：邓乾·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、业务专家/组织模板维护（当前：王满·推断待确认）、测试（当前：李国庆·推断待确认）、方案研发（当前：陈锦杰·推断待确认）、销售演示人（当前：吴琪·推断待确认）、法务（字体版权，当前：李瑶）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 收集反馈 → ② 补齐原始提示词与文件提 issue → ③ 分类打标 → ④ 阻断类当天止血 → ⑤ 两周一次集中归因 → ⑥ 修模板/skill/导出链路 → ⑦ 文档回归样例集回归 → ⑧ 发版通知与演示前检查
  • 交付结果：已分类的文档质量问题清单、公司默认格式模板（以国标公文为基准）及版本记录、文档产出回归样例集与回归报告、修复发版说明、演示前检查记录
  • 状态依据：已有工单、PPT 工作台、Word 套件与组织模板，但 2026-07～10 群内文档格式、导出类问题约 40 次逐个追问，管理层两次要求“集中优化”，客户演示中出现水印与字体异常，字体版权方案未定

1. 场景判定

  • 触发条件：用户、销售或客户反馈生成文件格式问题；演示前发现水印、字体、标题颜色异常；新增模板或调整默认格式；客户要求指定字体或统一格式
  • 典型说法：「Word 排版问题能不能集中优化一下」「默认的文档生成格式能不能优化一下」「生成的报告有水印，是怎么回事」「组织模板维护一下，比较影响给客户的演示」
  • 判断问题：问题出在“生成出来的文件本身”（格式、字体、版式、导出、预览）吗？如果是 Agent 理解错任务或内容事实错误，属于 Badcase
  • 不归本流程管：内容幻觉、任务理解错误等 Badcase → 请走 RND-02 / X-PRD-08；客户问题受理 → 请走 X-CS-05；Agent 能力评测 → 请走 RND-82；产品 Skill 上架 → 请走 RND-56；报告类型与提示词配置 → 请走 X-PRD-25；演示前版本冻结 → 请走 RND-61

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
文档生成研发负责人 问题分类、集中归因、修复与回归 A/R 文档生成研发负责人（当前：马漳毓·推断待确认）
Agent 研发 生成链路（直接写 docx、工具调用）改造 R Agent 研发（当前：岳阳·推断待确认）
Word 套件研发 默认格式模板、Word 套件维护 R LeapAll 服务端研发（当前：邓乾·推断待确认）
运维/发版 字体与环境、发版 R 运维/发版工程师（当前：宋祺睿·推断待确认）
业务专家 组织模板维护、阻断问题排查、格式标准建议 R 工程咨询业务专家（当前：王满·推断待确认）
测试 模板重置、回归样例执行 R 测试（当前：李国庆·推断待确认）
方案研发 编辑器字体与模板方案评估 C 后端研发（当前：陈锦杰·推断待确认）
销售演示人 反馈问题、执行演示前检查 R（检查） 客户经理（当前：吴琪·推断待确认）
反馈人/值班研发 反馈人提交问题；值班研发当天补齐原始提示词与文件并提 issue R 反馈人（任意使用者）；值班研发（按反馈群值班表）
法务 字体版权判断 C 法务负责人（当前：李瑶·部门报送人）
兜底 技术取舍拍板、复发升级 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 原始提示词/任务描述、模型档位、产品版本号
  • 原始生成文件（PPT/docx/xlsx），截图不能替代
  • 使用的组织模板/团队空间模板名称
  • 打开方式（WPS、Office、OnlyOffice、内置预览）与系统字体情况
  • 期望格式依据（如 GB/T 9704—2012、客户统一格式文件）
  • 是否影响近期客户演示及演示时间

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 反馈人在反馈群提交，值班研发当天要求补齐原始提示词与原始文件并提 issue 反馈人 + 值班研发 反馈当天 飞书反馈群 + Gitea Issue 文档质量 issue 🔧+👤
2 打标签：文件类型（PPT/Word/Excel/HTML）× 问题类型（格式/字体/水印/导出/预览）× 根源（模板/生成链路/客户端） 文档生成研发负责人 1 个工作日内 Gitea 标签 分类 issue 🤖自动化
3 阻断演示或客户交付的问题当天排查组织模板设置与近期改动，先一键重置模板或套标准模板止血 业务专家 + 测试 当天 组织模板后台 止血记录 👤人工判断
4 两周一次集中归因：合并同类问题，确定修复方式（改模板、改 skill、改导出链路、改为直接写 docx） 文档生成研发负责人 + Agent 研发 每两周一次 研发例会 修复方案 👤人工判断
5 维护默认格式模板：以国标公文格式为基准微调公司默认格式，模板版本化；字体只用可商用字体，其余提供用户导入或下载指引 Word 套件研发 + 法务 方案定后 5 个工作日内 Gitea 模板仓库 默认模板新版本 👤人工判断
6 修复后跑文档产出回归样例集（每类 ≥ 10 个典型任务），按格式检查项比对 文档生成研发负责人 + 测试 发版前 1 个工作日 回归脚本 + 人工抽检 回归报告 🤖+👤
7 随版本发布，关闭 issue 时通知反馈人复验 运维/发版 发版当天 更新日志 + 机器人通知 已关闭 issue 🔧+🤖
8 客户演示前按清单检查模板、水印、字体、标题颜色、导出 销售演示人 演示前 1 个工作日 演示前检查清单 检查记录 🔧飞书固化

5. 交付物与模板

  • 交付物：文档质量问题清单、默认格式模板及版本记录、回归样例集与回归报告、修复发版说明、演示前检查记录
  • issue 模板字段：文件类型、问题类型、原始提示词、模型档位、版本号、组织模板名、打开方式、原始文件附件、期望格式依据、是否阻断演示/交付
  • 回归样例字段：编号、文件类型、任务描述、使用模板、检查项（页边距、字体字号、标题层级与颜色、页码、目录、水印、导出 PDF）、通过/不通过
  • 演示前检查清单：组织模板是否为默认或客户模板、无水印、字体正常、标题颜色、目录与页码、导出与预览正常

6. 异常与升级

  • 客户演示前发现格式异常 → 重置模板或套标准模板 → 2 小时内无解升级 Leap 研发负责人
  • 客户要求的字体无版权 → 不内置，提供用户自行导入或下载指引 → 3 个工作日内法务给意见
  • 同一问题修复后复发 → 补入回归样例集，复盘根因 → 升级兜底人
  • 对“格式问题是否算 Badcase”有争议 → 统一按本流程打文档质量标签处理，不进 Badcase 池
  • 用 skill 优化格式耗时过长影响使用 → 列入集中归因，评估改为模板直出
  • 升级拍板（A（升级））：修复路线有分歧（改模板/改 skill/改导出链路/改为直接写 docx）、同一问题关闭后 30 天内复发、阻断演示问题 2 小时内无解时，由 Leap 研发负责人拍板；其余由文档生成研发负责人决定

7. 衡量指标

  • 文档质量类反馈量 = 每两周新增文档质量 issue 数，目标逐期下降
  • 修复周期 = issue 创建到发版关闭的工作日，目标 ≤ 10 个工作日；阻断类 ≤ 2 个工作日
  • 回归样例通过率 = 通过样例 / 全部样例，目标 ≥ 95%
  • 复发率 = 关闭后 30 天内同类问题再出现数 / 关闭数，目标 ≤ 10%
  • 演示前检查执行率 = 有检查记录的客户演示 / 客户演示总数，目标 100%

8. 低效诊断

  • 现象：PPT/Word 导出失败、顺序错乱、字体缺失等约 30 次，每个问题单独追问，未集中归因（收集归因环节）｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：反馈只贴截图，需再次索要原始提示词和原始文件（提交信息环节）｜依据：「Leap反馈群」2026-08
  • 现象：没有默认格式标准，markdown 转 docx 还是直接写 docx、以什么格式为基准在群里临时讨论（标准制定环节）｜依据：「Leap反馈群」2026-08、「【行业版Leapcore】工程版」2026-08
  • 现象：演示时才发现水印与字体异常，每次演示前要手动检查模板（演示准备环节）｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：用 skill 优化格式一次约需 10 分钟（生成效率环节）｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：编辑器缺少工程报告常用字体，内置有版权风险，方案悬而未决（合规环节）｜依据：「Leap反馈群」2026-08、「【行业版Leapcore】工程版」2026-09

9. 分支变体

  • PPT：PPT 工作台，导出需对话结束，视觉检查耗时纳入回归
  • Word：Word 套件 + 默认格式模板；组织模板（某工程咨询客户标准模板、模态团队空间模板）可一键重置
  • Excel 预览 / HTML / 生图：同一 issue 标签体系，归属对应研发
  • 行业版（工程版）：客户统一格式文件作为组织模板，由业务专家维护

10. 待确认问题

  • 文档生成质量主责是否为 PPT/文档生成研发？Word 是否另设负责人？
  • 两周一次集中归因是否可行？挂在哪个例会？
  • 默认格式以国标公文为基准是否已拍板？公司默认模板由谁审定？
  • 字体方案：用户导入还是提供下载？法务意见是什么？
  • 组织模板维护责任归研发、业务专家还是交付？
  • 回归样例集由测试还是研发维护？
RND-84知识库数据清洗入库与更新待新建72

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨3 × 险3

  • 适用场景：行业知识库（字字可研/工程版数据源）内容过时需更新，或新采集、外包交付的数据要清洗、迁移入库、打标签，以及新增行业 skill 需分类并绑定行业时启动
  • 负责人：主责——知识库数据研发（当前：魏宗浩·推断待确认）；协同——运维/数据库（入库窗口与标签脚本，当前：宋祺睿·推断待确认）、产品总监（发起与进度，当前：杨萌·推断待确认）、开放平台负责人（行业标签与下发，当前：郭逸非·推断待确认）、LeapAll 服务端（skill 分类方案，当前：邓乾·推断待确认）、产品经理（分类审核，当前：黄飞鹏·推断待确认）、业务专家（内容抽检，当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 更新立项 → ② 检视/重写爬虫并采集 → ③ 清洗 → ④ 申请入库窗口并迁移 → ⑤ 跑标签 → ⑥ 行业与 skill 绑定 → ⑦ 业务抽检验收 → ⑧ 关闭窗口、归档数据版本
  • 交付结果：更新后的知识库数据（含本次 updated_at 范围）、标签完成报告、行业与 skill 绑定表、验收记录、数据版本说明与导出备份
  • 状态依据：2026-01～02 入库靠口头接力（“洗完没”“知识库文件标签谁打”需产品追问，硬盘满只能分批写）；08～09 月更新时发现爬虫为手写或外包脚本、维护人离开后无人维护，skill 分类多次改动，“行业”与“行业版”标签关系未定，无固定更新周期

1. 场景判定

  • 触发条件：产品或业务发现知识库数据过时（政策、标准、造价、案例）；到达更新周期（建议每季度）；自采或外包数据交付；新增行业 skill 需要分类与行业绑定
  • 典型说法：「工程的知识库要做更新了，你的 AI 可以自动化一下吗」「更新完还要跑标签」「知识库文件标签谁打」「洗完没」
  • 判断问题：这批数据是否会进入产品知识库或数据源，被用户检索、被报告引用？
  • 不归本流程管：外包采集委托与验收 → 请走 RND-88；行业案例与测试素材获取 → 请走 X-PRD-26；生产数据订正与系统迁移 → 请走 RND-80；数据库 Schema 变更 → 请走 RND-34；开放平台 skill 上架与下发 → 请走 X-FDE-09 / ECO-06；帮助中心维护 → 请走 OPS-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识库数据研发 爬虫维护、采集、清洗、迁移入库、版本说明 A/R 知识库数据研发（当前：魏宗浩·推断待确认）
运维/数据库 入库窗口开关、磁盘检查、标签脚本运行与告警判断 R 运维/后端工程师（当前：宋祺睿·推断待确认）
产品总监 发起更新、定范围与截止日、跟进进度 C 产品总监（当前：杨萌·推断待确认）
开放平台负责人 行业/行业版标签口径与下发 C 开放平台负责人（当前：郭逸非·推断待确认）
LeapAll 服务端 skill 分类方案与下发 R 服务端研发（当前：邓乾·推断待确认）
产品经理 审核 skill 分类与命名 C 产品经理（当前：黄飞鹏·推断待确认）
业务专家 内容准确性抽检验收 R（验收） 工程咨询业务专家（当前：王满·推断待确认）
CTO 误更新回滚决策、资源调配 I/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 更新范围：数据源站点清单、行业、时间段、预计条数
  • 爬虫脚本仓库位置与上次运行记录
  • 字段规范与标签体系（行业、行业版、文档类型）
  • 目标库磁盘余量与备份
  • 临时公网访问窗口申请（时间段、来源 IP 白名单）
  • 业务抽检清单与抽样比例

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起更新：登记范围、原因、截止日，指定数据研发与验收人 产品总监 发现过时或到周期后 2 个工作日内 飞书任务 / 多维表格 更新任务卡 🔧飞书固化
2 检视爬虫：脚本统一放仓库，失效脚本用 AI 重写；需外包时转 RND-88 知识库数据研发 5 个工作日内 Gitea 可运行爬虫 🤖自动化
3 采集与清洗：去重、字段校验、格式统一，出清洗报告（条数、异常数、剔除原因） 知识库数据研发 3～5 个工作日 清洗脚本 清洗报告 🤖自动化
4 入库前检查磁盘余量并备份，申请临时公网访问窗口迁移入库；以 updated_at/deleted_at 圈定本次范围并记录 知识库数据研发 + 运维/数据库 窗口当天完成 数据库 入库记录 🔧+👤
5 入库完成即触发标签脚本，告警逐条判断是否可忽略并记录理由 运维/数据库 入库后 1 个工作日内 标签脚本 标签报告 🤖+👤
6 行业与 skill 绑定：skill 单独打标签按行业映射，分类方案经产品审核后一次下发，不反复改 LeapAll 服务端 + 开放平台负责人 + 产品经理 2 个工作日内 LeapOpen 标签 绑定表 👤人工判断
7 业务抽检：按清单抽样检查内容准确性与引用可用性，不合格打回步骤 3 业务专家 收到后 2 个工作日内 测试环境 验收记录 👤人工判断
8 关闭公网窗口，导出数据版本归档，群内通知更新完成和下次更新日期 运维/数据库 + 知识库数据研发 验收当天 存储桶 / 仓库 数据版本说明 🔧飞书固化

5. 交付物与模板

  • 交付物：更新后的知识库、清洗报告、标签报告、行业与 skill 绑定表、验收记录、数据版本说明与导出文件
  • 更新任务卡字段：知识库名称、行业、数据源、更新原因、范围、数据研发、验收人岗位、截止日、状态
  • 数据版本说明字段：版本号、数据源、新增/修改/删除条数、updated_at 范围、标签结果与告警处理、验收结论、导出文件位置、日期
  • 绑定表字段：skill 名称、分类、行业标签、行业版标签、下发状态、审核人岗位

6. 异常与升级

  • 磁盘满或存储不足 → 暂停入库，按 X-SEC-16 申请扩容 → 当天告知运维/数据库
  • 标签脚本告警无法判断 → 该批数据暂不上线 → 1 个工作日内升级 CTO
  • 误更新或误删 → 用导出版本回滚 → 立即升级 CTO
  • 公网访问窗口超时未关闭 → 运维强制关闭并记录
  • 爬虫维护人离岗 → 按 RND-85 交接脚本与运行说明
  • 数据源涉及非公开或竞品站点 → 停止采集，转法务意见（见 RND-88 步骤 2）
  • 升级拍板（A（升级））：发生误更新/误删需回滚、标签告警 1 个工作日内无法判断、或需追加服务器/人手资源时，由 CTO 拍板；其余入库与版本决定由知识库数据研发负责

7. 衡量指标

  • 数据新鲜度 = 距上次完成更新的天数，目标 ≤ 90 天
  • 更新周期 = 立项到验收通过的工作日，目标 ≤ 15 个工作日
  • 标签覆盖率 = 已打标签文件 / 本次入库文件，目标 100%
  • 抽检合格率 = 合格样本 / 抽检样本，目标 ≥ 95%
  • 公网窗口按时关闭率 = 按时关闭次数 / 开启次数，目标 100%

8. 低效诊断

  • 现象：入库进度要产品追问“洗完没”，标签由谁打要临时问（分工交接环节）｜依据：「工程咨询产研」2026-01
  • 现象：硬盘满导致只能分批写入（入库前检查环节）｜依据：「工程咨询产研」2026-01
  • 现象：迁移和标签靠口头接力，数据以 SQL 文件临时交给新人（归档环节）｜依据：「工程咨询产研」2026-02
  • 现象：爬虫为手写或外包脚本，维护人员离开后无人维护（采集工具环节）｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：skill 分类多版修改，“行业”与“行业版”标签关系未厘清（绑定环节）｜依据：「【行业版Leapcore】工程版」2026-09
  • 现象：没有更新周期，过时后才被动更新（触发环节）｜依据：「【行业版Leapcore】工程版」2026-08

9. 分支变体

  • 字字可研/工程版行业知识库：走全部步骤
  • skill 市场分类与行业标签绑定：只走步骤 1、6、8
  • 外包交付数据入库：先完成 RND-88 验收，再从步骤 3 开始

10. 待确认问题

  • 主责是否为知识库数据研发？爬虫的长期维护人是谁？
  • 每季度更新一次是否合适？不同行业是否需要不同周期？
  • “行业”与“行业版”标签最终口径由谁拍板？
  • 临时公网访问窗口是否需要审批？由谁审批？
  • 业务抽检比例与合格标准是多少？
  • 数据版本导出文件归档在哪里、保留多久？
RND-85研发工作与项目交接待新建144

状态：待新建｜证据：有证据（卡片 13 张 / 会话 10 个）｜优先级：频3 × 耗4 × 跨3 × 险4

  • 适用场景：研发成员离职、调岗、借调结束、实习结束、长期请假，或项目/模块/系统负责人更换、MVP 从作者转给维护者时，完成工单、代码、文档、环境、账号权限、待办与上下文的移交并由接手人签收
  • 负责人：主责——交出方所属团队技术负责人（当前：王皓南·推断待确认，非 Leap 产研团队由对应技术负责人担任）；协同——交出方原负责人、接手方新负责人、Gitea/服务器权限管理员（当前：宋祺睿·推断待确认）、IT 资产与服务器台账（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 指派交接与截止日 → ② 交出方按模板写 handoff → ③ 工单完成、释放或转派 → ④ 仓库迁组织仓并转移权限 → ⑤ 交接会与读代码/演练 → ⑥ 接手人逐项签收 → ⑦ 更新台账并公告新负责人 → ⑧ 回收交出方权限、30 天答疑
  • 交付结果：签收的 handoff 文档（统一模板，存仓库 docs/handoff 并链接飞书）、转派完毕的工单、更新后的系统台账（负责人、仓库、服务器、域名）、新负责人公告、权限变更记录
  • 状态依据：2026-03～10 交接均靠群内口头点名加临时压缩包或格式不一的 handoff 文件；出现核心上下文集中在一人、部署静默更新导致开发环境不可用、资料“忘记发给谁”、仓库放个人仓还是组织仓反复问、加人后才发现缺权限、交接文件写错机器、客户项目无人维护，约 60 次

1. 场景判定

  • 触发条件：成员离职、调岗、借调结束、实习结束；请假超过 3 个工作日且名下有进行中工单；项目、模块或系统负责人更换；MVP 交给维护者；项目转入主产品线
  • 典型说法：「把你手头的工单交接一下吧」「给我个 handoff」「你把该交接的今天都理好」「交接好了吗」「你把相关文档代码都交接给他」
  • 判断问题：是否有一块研发工作（工单、代码、服务、项目、系统）要从一个人手里换到另一个人手里？
  • 不归本流程管：产品经理岗位工作交接 → 请走 X-PRD-40；交付负责人 AB 角 → 请走 X-DLV-37；FDE 派驻与项目交接 → 请走 X-FDE-05；岗位离职总流程与离职手续 → 请走 HR-27（员工离职办理与交接；本 SOP 只覆盖其中的研发工作交接部分）；调岗与汇报线确认 → 请走 HR-25；离职/调岗账号回收 → 请走 X-SEC-08；测试环境地址与管理员账号登记 → 请走 X-SEC-09；运营岗交接 → 请走 OPS-28；内部 AI 机器人交接 → 请走 RND-81

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
所属团队技术负责人 发起交接、指定接手人与截止日、确认签收、公告 A 交出方所属团队技术负责人（当前：王皓南·推断待确认）
交出方 写 handoff、处理名下工单、交接会讲解、30 天答疑 R 原负责人
接手方 读文档与代码、提问、逐项核对签收 R 新负责人
权限管理员 仓库迁组织仓、开通接手人权限、调整发布权限 R Gitea/服务器管理员（当前：宋祺睿·推断待确认）
IT 资产与服务器台账 核对服务器、域名归属与新旧机器 C IT 运维/资产（当前：杨明学·推断待确认）
HR 离职/调岗时同步交接截止日 C 人事负责人（当前：黄莹·部门报送人）
CTO 跨团队交接指派、关键人单点处理、争议裁决 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
业务方/需求方 知悉新负责人与需求对接人 I 相关业务对接人

3. 办之前请准备

  • 名下工单清单（进行中、未开始、阻塞）
  • 负责的仓库（含个人仓）、分支、未合并 PR
  • 服务与环境：访问地址、服务器（区分新旧机）、部署方式、域名、端口、CI 配置
  • 账号与凭据的存放位置（只写位置，不贴明文）
  • 发布权限：测试服与生产各由谁发布
  • 已知问题、技术债、待办与截止日、外部联系人（岗位与单位）
  • 关键上下文：架构说明、配置入口、ADR、AI 会话归档位置

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在项目群公告交接对象、接手人、截止日，同时建飞书任务 所属团队技术负责人 决定当天 飞书群 + 飞书任务 交接任务 🔧飞书固化
2 按模板写 handoff，可让 AI 从代码与会话生成初稿，交出方核对 交出方 离岗前至少 3 个工作日完成；请假场景 1 个工作日 仓库 docs/handoff + 飞书文档 handoff 文档 🤖+👤
3 工单处理：进行中的做完或转派，未开始的释放回池，批量转派给接手人 交出方 + 所属团队技术负责人 与步骤 2 同步 工单系统 转派记录 🔧飞书固化
4 个人仓迁入组织仓；为接手人开通仓库、服务器、云资源权限；生产发布权限按最小范围重新指定 权限管理员 收到申请后 1 个工作日内 Gitea / X-SEC-02 / X-SEC-18 权限变更记录 👤人工
5 交接会：讲架构、环境、发布、已知坑；接手人先读代码再提问；核心模块演练一次部署或发版 交出方 + 接手方 交接期内 1～2 次 会议 + 录屏 交接纪要 👤人工判断
6 接手人逐项核对清单并签收，缺项打回交出方补齐 接手方 交接会后 2 个工作日内 飞书任务评论 签收记录 👤人工判断
7 更新系统台账中的负责人、需求对接人，通知业务方与相关群 所属团队技术负责人 签收当天 多维表格系统台账 新负责人公告 🔧+🤖
8 离职/调岗场景按 X-SEC-08 回收交出方权限；交出方 30 天内保持答疑 权限管理员 / 交出方 离岗当天回收 飞书 / Gitea 回收记录 🔧+👤

5. 交付物与模板

  • 交付物：handoff 文档、签收记录、工单转派记录、权限变更记录、更新后的系统台账、新负责人公告
  • handoff 模板字段：背景与目标、模块/系统清单、仓库与分支、访问地址、服务器与部署方式、技术栈、配置入口（各层分别控制什么）、发布权限、凭据存放位置、进行中工单、已知问题与技术债、下一步与截止日、外部联系人（岗位）、风险
  • 系统台账字段：系统名、功能概述、仓库、版本、访问地址、服务器、域名、部署方式、技术栈、负责人、备岗、需求对接人、最近更新日期
  • 签收清单：代码可拉取可构建、能独立部署一次、能访问各环境、工单已转派、凭据位置已知、遗留问题已确认

6. 异常与升级

  • 交出方已离开、资料缺失 → 接手方读代码并联合 IT 盘点服务器与仓库重建资料 → 3 个工作日内升级 CTO
  • 接手人没时间或推诿 → 所属团队技术负责人 1 个工作日内重新指定
  • 关键人单点（掌握全部上下文） → 先演练交付 SOP、文档 dump，指定 AB 角 → 由 CTO 跟进完成时间
  • 生产系统位置不清（新旧机混用） → 暂停迁移和变更，联合 IT 资产盘点 → 2 个工作日内升级 CTO
  • 发现群内明文凭据 → 撤回并轮换 → 按 X-SEC-11 当天处置
  • 原负责人对调整有疑问 → 指派人当面说明范围与后续安排，当天回复
  • 升级拍板（A（升级））：交接跨团队（交出方与接手方不在同一技术负责人下）、交出方已离开且资料缺失 3 个工作日未补齐、关键人单点、生产系统位置不清时，由 CTO 指派与裁决；其余由所属团队技术负责人决定

7. 衡量指标

  • 交接按期完成率 = 截止日前签收的交接数 / 交接总数，目标 ≥ 90%
  • 交接缺失事件 = 交接后 30 天内因信息缺失导致的故障或阻塞次数，目标 0
  • 系统台账负责人准确率 = 负责人正确的系统 / 系统总数，目标 100%
  • 离岗当天权限回收率 = 当天回收 / 离岗人数，目标 100%
  • 悬挂工单数 = 离岗 3 个工作日后仍挂在原负责人名下的工单数，目标 0

8. 低效诊断

  • 现象：成员请假或离开后工单悬挂，问题无人能答（工单释放环节）｜依据：「Leap产研测」2026-08
  • 现象：核心上下文集中在一人，接手方对“访谈还是读代码”有分歧，部署静默更新导致开发环境不可用（上下文转移环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：迭代负责人与功能产品负责人变更无通知，后来者要问“这个功能负责人是谁”（公告环节）｜依据：「工程咨询产研」2026-04
  • 现象：MVP 交给谁维护多轮推诿，接手人没有时间（指派环节）｜依据：「跃迁AI总动员」2026-04
  • 现象：handoff 文档不满足接手方，最后“还是自己看”；各人格式不同（文档模板环节）｜依据：「工程咨询产研」2026-09、「AI API」2026-09
  • 现象：交接资料“记得给过，忘了发给谁”，仓库放个人仓还是组织仓反复问，加人后才发现缺权限、访问 404（权限与归档环节）｜依据：「渠道系统优化」2026-10、「LeapVPN网络预研」2026-08、「LeapVPN网络预研」2026-09
  • 现象：成员离开后客户项目“落到别人头上”，交接内容只在聊天里（客户项目环节）｜依据：「跃迁基座项目交付沟通」2026-05
  • 现象：服务器、仓库、访问地址分散，靠群里临时按格式填写，服务器信息在群里流转（系统台账环节）｜依据：「公司内FDE」2026-09
  • 现象：项目只靠一人维护，测试与生产未隔离、正式版发布权限未限定（发布权限环节）｜依据：「技术部」2026-07

9. 分支变体

  • 离职/实习结束：走全部步骤，步骤 8 必做，与 HR-27 联动
  • 调岗/借调：保留答疑；借调结束回原岗时做反向交接
  • 请假超过 3 个工作日：只做步骤 1、3 和简版 handoff（进行中事项与联系人）
  • 主程/核心上下文交接：增加部署演练、交付 SOP，设置 AB 角
  • MVP 作者 → 维护者：补仓库整理、正式服托管、产品需求对接人
  • 项目转入主产品线：先定代码迁入主仓还是独立仓，复用已有的限流、计费、授权能力
  • 内部业务系统（CRM、渠道、合同、业财）：按系统台账逐个盘点，遵循“一个实体只由一个系统编辑、其他系统单向同步”

10. 待确认问题

  • 主责是否为所属团队技术负责人？跨团队交接是否统一由 CTO 指派？
  • 离岗前 3 个工作日完成 handoff 是否可行？
  • handoff 存放在仓库 docs/handoff、飞书知识库，还是两处都放？
  • 个人仓是否一律迁入组织仓？
  • 是否与 HR 离职/调岗流程打通，自动生成交接任务？
  • 交出方 30 天答疑期是否合适？
RND-86技术文档与上下文知识沉淀待新建72

状态：待新建｜证据：有证据（卡片 6 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨2 × 险3

  • 适用场景：调研/实验性工作结束、踩到需要告诉后来者的坑、新人或 AI 反复需要项目背景、跨团队需要产品与技术全景、AI 会话记录需要留存时，按统一位置和模板沉淀文档
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——各项目技术负责人/文档 owner、运维/发版（仓库文档约定，当前：宋祺睿·推断待确认）、开放平台后端（产品架构文档，当前：杨睿·推断待确认）、开放平台/FDE 课程负责人（当前：吴亚军·推断待确认）、产品总监（当前：杨萌·推断待确认）、支付研发顾问（踩坑文档，当前：王子明·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 判定沉淀类型 → ② AI 生成初稿、作者核对 → ③ 放入约定位置 → ④ 更新 AGENTS.md 索引 → ⑤ 迭代末审阅调研文档 → ⑥ PR 附带文档更新 → ⑦ 会话归档 → ⑧ 季度清理
  • 交付结果：仓库 docs 分类文档与 AGENTS.md 索引、飞书知识库项目页、调研文档与审阅纪要、踩坑记录、AI 会话归档
  • 状态依据：2026-01 提出“研究性工作都要写文档、迭代末审阅”，03 月提出“仓库即上下文”，但到 10 月仍在讨论文档放全员空间、仓库还是飞书，AGENTS.md 与 CLAUDE.md 并存，“写了文档也忘记去哪找”，背景靠口头反复交代，规则未落地

1. 场景判定

  • 触发条件：调研、预研、实验工作完成（迭代末）；踩坑经验需留存（支付通道限制、部署坑等）；同一背景被问 2 次以上；新人或新 AI 会话需要项目背景；跨团队需要产品与仓库对应关系
  • 典型说法：「以后研究性工作都要写文档」「仓库即上下文」「重点是识别出需要重复的工作并消除」「很多东西也是靠传承的」「有没有全组共用的项目/仓库/org 记忆层」
  • 判断问题：这份信息会不会被另一个人或 AI 再次需要？不写下来，下次是否要找人口述？
  • 不归本流程管：人员与项目交接 → 请走 RND-85；AI 工具使用经验与互助排障 → 请走 RND-29；技术分享会与内部工具发布 → 请走 RND-87；部署 SOP 与交付文档 → 请走 X-DLV-36；产品手册 → 请走 X-PRD-36；帮助中心 → 请走 OPS-03；重大技术决策评审 → 请走 RND-14 / RND-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 定文档规则与目录结构、迭代末审阅调研文档、季度清理 A 研发负责人（当前：王皓南·推断待确认）
工作执行人 按模板写文档、放约定位置、更新索引 R 承担调研/开发任务的研发
项目技术负责人 维护本项目 docs 与 AGENTS.md，PR 评审检查文档更新 R 各项目技术负责人
运维/发版 仓库文档约定落地（统一 AGENTS.md） C 运维/发版工程师（当前：宋祺睿·推断待确认）
开放平台研发 产品/技术全景文档与渲染图同步 C 开放平台后端（当前：杨睿·推断待确认）、开放平台/FDE 课程负责人（当前：吴亚军·推断待确认）
产品总监 面向产运、市场的文档需求 C 产品总监（当前：杨萌·推断待确认）
领域老人 输出踩坑文档 R（踩坑） 支付研发顾问（当前：王子明·推断待确认）
CTO 争议裁决、重点上下文专项安排 I/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 判定文档类型：项目上下文 / 调研 / 踩坑 / 架构与产品全景 / 会话归档
  • 原始材料：代码、会议纪要、群聊结论、AI 会话记录（先脱敏）
  • 目标位置：对应仓库 docs/<类别>/ 或飞书知识库项目页
  • 敏感信息检查：密钥、商户号、测试账号、客户信息不得写入文档

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定是否需要沉淀及类型；调研任务立项时在工单写明“产出为文档” 工作执行人 立项时 迭代工单 工单标注 👤人工判断
2 按模板写文档，可让 AI 从代码、会话、群记录生成初稿，作者核对事实 工作执行人 调研类在迭代末前；踩坑类发现后 2 个工作日内 AI + Markdown 文档初稿 🤖自动化
3 放入约定位置：技术细节放仓库 docs/<类别>/（Markdown，便于 Agent 读取）；面向市场/产运的放飞书知识库并链接仓库 工作执行人 同步骤 2 Gitea + 飞书知识库 文档 🔧+👤
4 更新索引：仓库统一用 AGENTS.md，只放索引与关键约束，不放长文 工作执行人 随文档提交 Gitea PR 索引更新 🤖+👤
5 迭代末评审调研文档，结论与后续动作写入纪要 研发负责人 迭代末评审会 研发例会 审阅纪要 👤人工判断
6 代码改动影响行为、接口或部署时，PR 模板要求勾选并更新相关文档，评审人检查 工作执行人 + 项目技术负责人 每个 PR Gitea PR 模板 文档随代码更新 👤人工判断
7 AI 会话中的关键决策与上下文按项目归档（脱敏），每周备份 工作执行人 每周五 仓库/知识库归档目录 会话归档 🤖自动化
8 每季度清理过时文档、重建索引，机器人汇总变更摘要发群 研发负责人 每季度首月第 1 周 机器人 + 仓库 归档清单 🤖自动化

5. 交付物与模板

  • 交付物：仓库 docs 文档与 AGENTS.md 索引、飞书知识库项目页、调研文档与审阅纪要、踩坑记录、会话归档、季度归档清单
  • 目录约定：docs/architecture、docs/product、docs/research、docs/pitfalls、docs/handoff、docs/adr
  • 调研文档模板：背景与问题、方案对比、实验过程与数据、结论、推荐动作、风险、参考资料
  • 踩坑记录模板：现象、环境与版本、根因、解决方式、限制条件（如分账方数量上限、调用频率限制）、记录人岗位、日期
  • 项目上下文文档：产品/服务与仓库对应关系、架构图、环境与部署入口、配置入口、负责人

6. 异常与升级

  • 文档位置有争议 → 按本 SOP 双层结构执行，新情况由研发负责人 2 个工作日内裁定
  • 文档中出现密钥、商户号、客户信息 → 立即删除并按 X-SEC-11 轮换 → 当天处置
  • 迭代末未交调研文档 → 视为任务未完成，例会通报，下迭代首日补齐
  • 未经安排私下开发的工具/SDK → 先在群里同步，再由研发负责人决定是否纳入
  • 关键人持有大量未成文上下文 → 研发负责人安排专项沉淀，或按 RND-85 设 AB 角 → 1 周内启动
  • 升级拍板（A（升级））：文档规则或存放位置的争议研发负责人 2 个工作日内无法裁定、涉及跨团队（研发以外部门）的文档归属、或关键人专项沉淀 1 周内未启动时，由 CTO 裁决；其余由研发负责人决定

7. 衡量指标

  • 调研文档交付率 = 有文档的调研任务 / 调研任务总数，目标 100%
  • 重复提问次数 = 同一背景在群内被问 2 次以上的次数，目标逐月下降
  • 索引覆盖率 = 有 AGENTS.md 索引的活跃仓库 / 活跃仓库，目标 100%
  • 新人上手时间 = 入职到首个 PR 合入的工作日，目标 ≤ 5 个工作日
  • 季度清理按期率 = 按期完成清理的季度 / 季度数，目标 100%

8. 低效诊断

  • 现象：研究性工作是否要写文档、写在飞书还是 Markdown 有争论（规则环节）｜依据：「鼎慧产研决策部」2026-01
  • 现象：同一背景每次口头重复交代，没有产品/服务对应仓库的说明，文档放哪各说各的（位置与索引环节）｜依据：「Leap产研测」2026-10
  • 现象：AGENTS.md 与 CLAUDE.md 并存且内容过长（索引规范环节）｜依据：「Leap产研测」2026-10
  • 现象：踩坑经验靠老人口头传承，新人接手支付要逐条问；私下做的 SDK 未同步造成重复（踩坑沉淀环节）｜依据：「LeapPay」2026-04
  • 现象：个人 AI 会话上下文超限后信息丢失，需要再找人补（会话归档环节）｜依据：「LeapPay」2026-04

9. 分支变体

  • 项目上下文：仓库 docs + AGENTS.md 索引
  • 调研/预研：迭代末交文档 + 审阅会
  • 踩坑传承（支付通道等）：飞书 wiki 与仓库 docs/pitfalls 双写，群内机器人助理可把群记录、会议纪要整理为文档初稿
  • 面向市场/产运的全景文档：以飞书文档为主，链接仓库
  • 教育/定制交付项目：项目记录写进仓库，文档检查纳入代码评审
  • 个人 AI 全局指南（Codex、Claude 等）：使用统一模板，放个人仓库

10. 待确认问题

  • 主责是研发负责人还是 CTO？
  • “仓库 docs + 飞书知识库”双层结构是否拍板？全员共享空间建在哪里？
  • 是否统一使用 AGENTS.md、删除 CLAUDE.md？
  • AI 会话记录是否强制上传？范围与脱敏规则？
  • 非调研类的研发任务是否要求写文档？
  • 文档检查是否纳入 CI 或代码评审必查项？
RND-87技术分享、内部 Skill/工具发布与推广待优化72

状态：待优化｜证据：有证据（卡片 11 张 / 会话 6 个）｜优先级：频4 × 耗2 × 跨3 × 险3

  • 适用场景：研发做出可复用的内部 skill、插件、小工具或配置包，或有值得推广的技术经验、评测结果、新规范，需要评测、登记、发布、分享培训并收集反馈时启动
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——Skill/工具作者（当前：马漳毓、邓乾、柯逸飞、张东郅·推断待确认）、评测（当前：黄霆瑄·推断待确认）、Skill 宣讲（当前：李凯·推断待确认）、内部开源工具负责人（当前：李子遥·推断待确认）、产品总监（产品化判断，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 作者发布登记 → ② 安全扫描与 eval → ③ 推组织仓打版本 → ④ 写使用说明 → ⑤ 机器人发群并入目录 → ⑥ 周五分享/学习任务 → ⑦ 反馈迭代 → ⑧ 月度产品化或下架评估
  • 交付结果：内部 Skill/工具目录中的登记（名称、owner、版本、仓库、安装方式、eval 结果、反馈入口）、发布说明与教程、分享排期与录屏纪要、技术主管周成果汇总
  • 状态依据：已有 Gitea、技能市场、周五分享习惯和 AI 探索群，但 2026-04～09 工具散落群聊、zip 私下分发、同名 skill 无人认领、“新 skill 在哪里”反复问、评测靠人工打开看效果，推广多次需领导催“发群里同步”

1. 场景判定

  • 触发条件：做出可复用 skill、插件、工具或配置包并希望他人使用；已有 skill 发新版；有值得分享的使用经验或评测结果；引入新工具、新规范需全员学习；技术主管每周成果同步
  • 典型说法：「最新的 skill 已经上传到仓库啦」「你应该跑个 eval，你现在太手工了」「这个 skill 是谁做的」「周五分享一下」「你发群里跟其他人同步一下」「每天都得有人用+收集反馈的问题」
  • 判断问题：受众是公司内部同事吗？目的是“让别人用上/学会”，而不是对外上架或开源吗？
  • 不归本流程管：产品内置 skill 与技能市场对外上架 → 请走 RND-56 / X-PRD-21；开放平台第三方 skill 上架 → 请走 ECO-06；内部项目开源与对外发布 → 请走 ECO-09 / ECO-10 / LEG-29；全公司培训与分享会 → 请走 GEN-07（内部分享会与学习活动组织）/ HR-23（内部培训与分享会组织）；AI 编码工具经验与互助排障 → 请走 RND-29；Agent 系统性评测 → 请走 RND-82；技术文档沉淀 → 请走 RND-86

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 维护目录与发布规则、排分享会、布置学习任务、裁决重名与多版本 A 研发负责人（当前：王皓南·推断待确认）
Skill/工具作者 登记、扫描、eval、推仓库、写说明、回应反馈 R Skill/工具作者（当前：马漳毓、邓乾、柯逸飞、张东郅·推断待确认）
评测 提供 eval 模板与评分基线，复核 eval 结果 C 评测工程师（当前：黄霆瑄·推断待确认）
Skill 宣讲 面向非研发同事的宣讲与安装指导 R（宣讲） FDE/运营负责人（当前：李凯·推断待确认）
内部开源工具负责人 TeamDNA 等工具的 PR 评审、内测与推广 R 信创与开源负责人（当前：李子遥·推断待确认）
产品总监 判断是否产品化、给出保留版本建议 C 产品总监（当前：杨萌·推断待确认）
CTO 推广范围决策、安全问题裁决 I/A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
各技术主管 每周同步本组成果与错误 R 各项目组技术主管

3. 办之前请准备

  • 组织仓地址（不用个人仓）、版本号、变更说明
  • 安装/使用方式（安装命令、技能市场搜索词、配置步骤）及截图或示例
  • eval 结果：先用低成本模型跑通的评测、评分文件或评分页面
  • 依赖与所需权限清单（执行命令、网络访问、密钥）
  • 维护人、备岗与反馈入口
  • 分享主题、时长、材料

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填发布登记：名称（查重）、用途、owner、版本、仓库、依赖与权限 作者 发布前 1 个工作日 多维表格（Skill/工具目录） 登记记录 🔧飞书固化
2 安全扫描（权限、执行命令、密钥、外部来源代码）+ eval（低成本模型跑通，评分文件存 COS/仓库） 作者 + 评测 2 个工作日内 扫描脚本 + eval 脚本 扫描与评测结果 🤖自动化
3 推组织仓并打 tag，不再通过 zip 私下分发 作者 扫描通过当天 Gitea Release 🤖+👤
4 写使用说明/教程（可 AI 生成）：安装、示例、限制、反馈入口；配置类成果必须有飞书文档 作者 与发布同步 README / 飞书文档 使用说明 🤖自动化
5 机器人将 Release 推送到 AI 探索群/研发群并更新目录 作者（机器人自动推送） Release 后即时 飞书机器人 群通知 🤖自动化
6 周五分享会：周四前定排期，经验、工具、评测结果上会；评测结果用图表/HTML；录屏和纪要入知识库 研发负责人 每周四前排期 飞书日历 + 妙记 分享纪要 🔧飞书固化
7 新工具/新规范学习：发飞书任务带截止日，完成后打卡确认 研发负责人 发布后 3 个工作日内完成 飞书任务 完成记录 🔧飞书固化
8 收集反馈（文档评论或反馈表），作者 5 个工作日内回复并迭代；内测期指定辅助使用人 作者 持续 反馈表 迭代版本 👤人工判断
9 月度评估：使用量高的提交产品化（转 RND-56），无人用或无人维护的下架 产品总监 + 研发负责人 每月第 1 周 目录统计 产品化/下架结论 👤人工判断
10 技术主管每周同步本组成果与错误，AI 汇总成周报 各技术主管 每周五 主管群 + 多维表格 周成果汇总 🤖+👤

5. 交付物与模板

  • 交付物：目录登记、扫描与 eval 结果、Release 与使用说明、群通知、分享纪要与录屏、学习完成记录、周成果汇总
  • Skill/工具目录字段：名称（唯一）、类型（Skill/插件/独立服务/模型类/配置包）、用途、owner、备岗、版本、仓库地址、安装方式、依赖与权限、eval 结果链接、安全扫描结果、反馈入口、使用量、状态（内测/推荐/产品化/下架）
  • 发布说明模板：版本、变更点、截图、安装步骤、已知问题、反馈方式
  • 分享排期表字段：日期、主题、分享人岗位、材料链接、录屏链接、纪要
  • 周成果模板：本组成果、踩坑与错误、可复用经验、需协同事项

6. 异常与升级

  • 扫描发现可疑执行权限或外部来源代码 → 禁止发布，按 X-SEC-41 复核 → 当天升级 CTO
  • 同名或重复 skill → 合并或改名，保留唯一 owner → 研发负责人 2 个工作日内裁定
  • 作者离岗 → 目录中指定新 owner，按 RND-85 交接
  • 同一需求多个版本竞争 → 用 eval 结果比较 → 产品总监 1 周内给出保留建议，研发负责人拍板
  • 工具拟对外开源 → 转 ECO-09 / LEG-29 评审，未评审前不得公开
  • 内部工具冷启动无人使用 → 研发负责人点名试用团队并设反馈截止日
  • 升级拍板（A（升级））：安全扫描发现可疑权限或外部来源代码、工具拟推广到研发以外部门或全公司、研发负责人与产品总监对产品化/保留版本意见不一致时，由 CTO 裁决；其余由研发负责人决定

7. 衡量指标

  • 目录登记率 = 已登记工具 / 群内发布的工具，目标 100%
  • 发布前 eval 执行率 = 有 eval 结果的发布 / 发布总数，目标 ≥ 90%
  • 私下分发次数 = 每月通过 zip 私下分发的次数，目标 0
  • 分享会举办率 = 实际举办的周五分享 / 应举办周数，目标 ≥ 80%
  • 学习任务按期完成率 ≥ 90%
  • 反馈响应时长 = 反馈到作者回复的工作日，目标 ≤ 5 个工作日

8. 低效诊断

  • 现象：工具散落群聊，没有版本、验收和统一维护人（登记环节）｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-08
  • 现象：同名 skill 无人认领，多人各写一版（命名与归属环节）｜依据：「模态AI探索小分队」2026-07
  • 现象：评测靠人工打开文件看效果，zip 私下分发未推仓库（评测与分发环节）｜依据：「跃迁AI总动员」2026-09
  • 现象：同一 PPT 需求多个版本竞争，可编辑/图片方案来回改，“新 skill 在哪里”需要问（版本与目录环节）｜依据：「模态AI探索小分队」2026-04
  • 现象：评测汇报格式不一，控制台截图直接贴群（汇报格式环节）｜依据：「跃迁AI总动员」2026-08
  • 现象：发版流程培训在 CI 多次出问题后才安排，培训无归档和完成确认（培训环节）｜依据：「研发通知」2026-07
  • 现象：周五技术交流会周期不稳定，教程补充靠认领（分享排期环节）｜依据：「技术部」2026-01、「技术部」2026-03
  • 现象：内部工具冷启动需反复催“有人用、收集反馈”，工具定位反复讨论（推广与反馈环节）｜依据：「模态开源内测群」2026-03、「模态开源内测群」2026-04
  • 现象：技术主管周成果同步宣布后未见持续记录（周同步环节）｜依据：「模态跃迁技术主管群」2026-02

9. 分支变体

  • 内部自用 skill：走步骤 1～5、8
  • 拟封进 LeapCore/技能市场的 skill：完成本流程后转 RND-56
  • 内部开源工具（TeamDNA 等）：PR 评审合并 → playground 仓库演练 → 飞书文档 + 线上直播教程答疑 → 内测群收反馈；公开开源前先过 ECO-09 / LEG-29
  • 研发培训（规范类、工具类、流程类）：挂在研发例会议程，学习任务带截止日
  • 配置包/教程类成果：必须配飞书文档，写清不同 Agent 的配置方法

10. 待确认问题

  • 主责是研发负责人还是 CTO？
  • Skill/工具目录由谁维护？放在哪个多维表格？
  • 发布前 eval 是否对所有 skill 强制？默认用哪个低成本模型？
  • 周五分享会是否固定？由谁排期？
  • 安全扫描工具与标准由谁定？
  • 技术主管周成果同步是否仍在执行？是否与 DailyWork 打通？
RND-88外包数据采集委托与验收待新建200

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：需要批量采集网站数据（招投标、政务站点、行业资料等）而内部人手不足，决定委托外部团队或分包采集时，覆盖合规评估、委托约定、样例确认、分批交付验收到结单付款全过程
  • 负责人：主责——数据采集负责人（总包验收方）（当前：魏宗浩·推断待确认）；协同——外包审批与结单人（当前：丁震宇·推断待确认）、数据接入/运维（当前：宋祺睿·推断待确认）、产品总监（需求与进度，当前：杨萌·推断待确认）、Leap 研发负责人（验收要求，当前：王皓南·推断待确认）、业务验收专家（当前：待指定）、法务负责人（当前：李瑶·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 写需求并评估自采/外包/采购 → ② 站点合规评估 → ③ 选外包并签约 → ④ 分配任务与字段规范 → ⑤ 样例验收 → ⑥ 分批交付自动校验 → ⑦ 业务抽检 → ⑧ 结单付款并转入库
  • 交付结果：外包任务表（站点、分包方、状态）、签署的委托合同（含数据来源合法与保密条款）、样例与分批验收记录、验收报告、结单付款审批、移交入库的数据
  • 状态依据：2026-01～03 多次外包采集均临时安排：验收标准不清（交付网页只有标题无法验收）、样例通过后整批约 80G 数据才发现结构不一致被全部打回、付款条件与计价口径未成文、风险站点的法律责任只做口头约定

1. 场景判定

  • 触发条件：内部爬虫人手不足或站点数量大（数百到数千个）；项目或知识库需在短期内拿到数据；需要评估“AI 自动采集 vs 外包 vs 直接采购”
  • 典型说法：「要哪些外包也赶紧整」「干的不行打回去重干」「现在要全部打回」「看过再结」
  • 判断问题：这批数据是否由公司外部人员采集交付，并需要付款？
  • 不归本流程管：自采数据清洗入库 → 请走 RND-84；外包研发人员引入 → 请走 X-FDE-05（FDE 人员派驻、调配与项目交接）；采购/服务合同起草与审核 → 请走 LEG-04；对公付款审批 → 请走 FIN-01；劳务报酬结算与个税 → 请走 FIN-14；外部数据集对外交付 → 请走 X-DLV-39；业务合规红线判断 → 请走 LEG-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据采集负责人 需求文档、任务分配、样例与分批验收、验收报告、发起结单 R 数据采集负责人（当前：魏宗浩·推断待确认）
外包审批与结单人 批准外包、定计价与付款条件、审批结单 A 外包审批人（当前：丁震宇·推断待确认）
法务 站点合规评估（意见为否时不得采集）、合同条款审核 C 法务负责人（当前：李瑶·部门报送人）
业务验收专家 内容可用性抽检 R（抽检） 业务验收专家（当前：待指定）
数据接入/运维 专用存储桶、测试环境接入 R 运维/后端工程师（当前：宋祺睿·推断待确认）
产品总监 提出数据需求、跟进进度 C 产品总监（当前：杨萌·推断待确认）
Leap 研发负责人 提出验收要求、调整采集负责人任务优先级 C Leap 研发负责人（当前：王皓南·推断待确认）
财务 按验收结论付款 R（付款） 财务负责人（当前：黄梦婷·部门报送人）
外包/分包方 按字段规范采集、交付样例与分批数据 R 外部供应商

3. 办之前请准备

  • 采集需求文档：站点清单/URL、字段规范、数据格式、量级、截止日、存储位置
  • 自采、AI 自动采集、外包、直接采购的成本与周期对比
  • 站点合规信息：是否公开数据、站点用户协议限制、是否竞品、是否含个人信息
  • 预算与计价方式（按站点或按量）、工作量偏差约定、付款节点
  • 验收标准：字段完整率、结构一致性、重复率、抽样比例
  • 专用存储桶与访问权限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 写采集需求文档，评估自采/AI 自动采集/外包/直接采购，报外包审批人 数据采集负责人 需求确认后 3 个工作日内 飞书文档 需求文档 + 方案评估 👤人工判断
2 逐站合规评估：非公开、竞品、含个人信息的站点须法务出书面意见，不通过的不采集；不得以“只采购最终数据”转移责任 法务 收到后 3 个工作日内 飞书审批 合规意见 👤人工判断
3 选外包，确定计价与付款条件（验收合格后付款、打回规则、工作量偏差上限），签委托合同（含数据来源合法声明、保密条款） 外包审批人 + 法务 2～5 个工作日 合同审批（LEG-04） 签署的合同 🔧飞书固化
4 任务分配：按站点分给分包，任务表登记站点、分包方、字段规范版本、截止日；开会讲清字段与交付格式 数据采集负责人 签约后 1 个工作日内 多维表格任务表 任务表 🔧飞书固化
5 样例验收：每个站点先交 sample，脚本校验字段与结构，不合格打回，合格才允许全量 数据采集负责人 收到 sample 后 1 个工作日内 校验脚本 样例验收记录 🤖+👤
6 分批交付：大站点按批交付（单批建议 ≤ 10G），每批自动校验字段完整性、结构一致性、重复率，异常批次整批打回 数据采集负责人 每批收到后 2 个工作日内 校验脚本 + 专用存储桶 分批验收记录 🤖自动化
7 业务抽检：外包说明采集范围，业务专家抽样检查内容可用性（正文、附件完整，不能只有标题） 业务验收专家 收到后 2 个工作日内 测试环境 抽检结论 👤人工判断
8 出验收报告，提交结单付款审批；数据转 RND-84 清洗入库 数据采集负责人 → 外包审批人 → 财务 验收后 3 个工作日内发起 飞书审批 付款审批、入库任务 🔧飞书固化

5. 交付物与模板

  • 交付物：需求文档与方案评估、合规意见、委托合同、任务表、样例与分批验收记录、抽检结论、验收报告、付款审批
  • 采集需求文档字段：用途、站点/URL 清单、字段定义（名称、类型、必填）、数据格式、预计量级、截止日、存储位置、验收标准
  • 外包任务表字段：站点/URL、分包方、字段规范版本、sample 状态、批次、交付量、校验结果、打回次数、验收状态、付款状态
  • 验收报告字段：委托站点数、通过数、打回数、字段完整率、重复率、抽检结论、遗留问题、建议付款比例

6. 异常与升级

  • 样例合格但全量结构不一致 → 整批打回并约定修复期限 → 同一分包 2 次打回仍不合格，升级外包审批人更换分包
  • 外包进度延误 → 数据采集负责人每周催办 → 超期 5 个工作日升级 CTO
  • 站点合规存疑或收到删除要求 → 立即停止采集与使用 → 当天转法务处理
  • 付款争议（工作量偏差超约定） → 外包审批人与财务按合同协商 → 5 个工作日内给结论
  • 数据采集负责人同时承担多项任务导致进度慢 → Leap 研发负责人调整优先级或增派人手
  • 站点合规以法务书面意见为准：法务意见为不通过的站点，外包审批人不得批准采集；对意见有异议的，由外包审批人与法务当面复议，仍不一致则停止该站点采集

7. 衡量指标

  • 样例一次通过率 = 一次通过的站点 sample / 提交 sample 总数，目标 ≥ 80%
  • 全量打回率 = 被打回的批次 / 交付批次，目标 ≤ 10%
  • 验收周期 = 每批交付到验收结论的工作日，目标 ≤ 3 个工作日
  • 合规评估覆盖率 = 已评估站点 / 委托站点，目标 100%
  • 结单周期 = 验收通过到付款审批发起的工作日，目标 ≤ 3 个工作日

8. 低效诊断

  • 现象：验收标准不清，交付网页只有标题无法验收，结单前临时找业务专家看（验收标准环节）｜依据：「鼎慧产研决策部」2026-01
  • 现象：样例通过后整批约 80G 数据才发现同一站点多套结构，整批打回重做（分批交付环节）｜依据：「鸽子群模态分群」2026-01
  • 现象：逐个人工检查分包数据结构，样本反复打回（自动校验环节）｜依据：「某政企客户需求对接群」2026-01
  • 现象：采集负责人同时推进多个任务，进度被追问（任务分配环节）｜依据：「某政企客户需求对接群」2026-01
  • 现象：外包由谁结单、按什么条件付款没有成文（结单环节）｜依据：「鼎慧产研决策部」2026-01

9. 分支变体

  • 总包 + 多分包：总包负责清洗与管理，分包按站点承接，工作量偏差约定上限
  • 单一外包团队：样例 → 分批 → 验收
  • 直接采购数据：重点在合规与来源证明，跳过步骤 4～5
  • 超大规模站点（数千个）：先评估 AI 自动采集方案，再决定是否外包
  • 社交平台数据：优先评估官方接口或合规第三方服务

10. 待确认问题

  • 外包采集是否统一由 CTO 审批与结单？
  • 法务介入范围：所有站点还是仅风险站点？
  • 付款节点：按批付款还是整体验收后一次付款？
  • 业务验收专家由谁担任？
  • 专用存储桶的数据保留期限多长？
  • 是否已有含数据来源条款的外包合同模板？
RND-89对外技术咨询答复与方案文档评审待新建240

状态：待新建｜证据：有证据（卡片 3 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：市场、销售、厂商或合作方询问技术可行性、产品能力，或研发写好的技术方案/产品说明/演示视频需要发给客户时，由研发统一受理、评估答复并在对外发出前完成评审
  • 负责人：主责——研发技术咨询接口人（当前：丁震宇·推断待确认）；协同——信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、Leap 架构/运维研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、产品总监（当前：杨萌·推断待确认）、提问方销售/市场（当前：李鹏为、许君·推断待确认）；兜底——研发部门负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交咨询单 → ② 接口人分级派单 → ③ 领域负责人评估 → ④ 形成结论与承诺边界 → ⑤ 对外材料评审 → ⑥ 统一渠道发出 → ⑦ 沉淀 FAQ/口径库
  • 交付结果：带可行性等级与承诺边界的书面答复；经评审签发的对外技术方案/产品说明；更新后的产品能力 FAQ 条目
  • 状态依据：无统一入口和登记表，问题在项目群里临时抛出，仅 1 次建了飞书待办；产品能力口径靠口头解释，合作方要示例和文档时拿不出；对外文档评审靠习惯、无清单，常由终审人直接改措辞

1. 场景判定

  • 触发条件：外部厂商/合作方/客户提出技术问询；销售或市场需要确认"能不能做、能做到什么程度"；需要背调开源项目或第三方技术；研发产出的方案、说明、演示视频准备发给客户
  • 典型说法：「看看这个 LeapCore 理论上能跑吗」「厂商问 LeapCore 服务端什么架构、容器化吗」「市场需要帮忙背调一下这个开源项目」「Claude Code 上的 Skill 能不能在 LeapAll 上跑」「视频生成最长能多长」「方案写好了，帮忙审一下再发客户」
  • 判断问题：答复是否会被外部方当作公司技术承诺或产品口径？是否要发到公司外部？如果是，走本流程
  • 不归本流程管：已签约客户的产品故障/Bug → 请走 X-CS-05（客户问题受理、分流与工单流转）；售前定制评估与报价 → 请走 SAL-21（定制/非标需求评估、报价与特批），POC 环境搭建 → 请走 X-DLV-27（客户 POC/演示环境搭建与交付）；对外宣传稿与品牌口径 → 请走 BRD-09（事件型宣发稿与新闻稿）、BRD-14（对外口径、品牌用语与发布前合规自查）；合同技术条款 → 请走 LEG-03（销售合同审查与多方会签）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提问方 填咨询单、提供背景与客户需求、接收结论并对外转达 R（提交） 销售/市场负责人（当前：李鹏为、许君·推断待确认）
技术咨询接口人 受理分级、派单、定承诺边界、对外材料终审 A 研发技术咨询接口人（当前：丁震宇·推断待确认）
领域评估人（信创/国产化/机密计算） 出可行性分析与方案分级 R 信创&Linux 适配负责人（当前：李子遥·推断待确认）
领域评估人（Leap 产品/架构） 补充架构、容器化、部署与网络事实 R/C Leap 研发技术负责人（当前：王皓南·推断待确认）；架构/运维研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）
口径维护人 维护产品能力 FAQ 与对外口径，审核答复是否与口径一致 C 产品总监（当前：杨萌·推断待确认）
方案作者 撰写方案/说明/视频，按评审意见修改 R（文档） 对应研发作者（当前：按文档指派）
业务线技术评审 跃竞等业务线方案的技术复核 C 跃竞负责人（当前：徐莉·推断待确认）；跃竞后端（当前：张楠·推断待确认）
前端/接入研发 小程序、iframe 等接入类问题答复 C 客户端前端研发（当前：葛家和·推断待确认）

3. 办之前请准备

  • 提问来源：厂商/合作方/客户类型（用"客户A""某国产芯片厂商"指代即可）、对接渠道
  • 问题原文与链接（开源项目地址、对方架构文档、截图）
  • 业务背景：是否有真实客户需求、预计规模、期望答复时间
  • 需要的答复形态：口头确认 / 书面结论 / 方案文档 / 示例与 API 文档
  • 对外材料评审时：文档终稿链接（飞书文档）、目标读者、发出渠道、是否含报价或交付承诺

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写技术咨询单（来源、问题、背景、期望时间、答复形态） 提问方 收到外部问询后 0.5 个工作日内 飞书多维表格表单 咨询单 🔧飞书固化
2 先查产品能力 FAQ，已有口径直接引用答复并关单 技术咨询接口人 提交后 2 小时内（工作时间） FAQ 库 + AI 问答机器人 引用口径的答复 🤖自动化
3 未命中 FAQ：判定类型（可行性/架构问询/背调/能力口径）与等级，指派领域评估人并建飞书任务设 DDL 技术咨询接口人 提交后 1 个工作日内 飞书任务 带 DDL 的评估任务 🔧+👤
4 评估并给出分级结论：可直接支持 / 理论可行需工程验证 / 不支持；列出前提条件与方案分级（如主机加密/虚拟机加密/容器隔离） 领域评估人 一般问询 1 个工作日；背调与方案分级 3 个工作日 飞书文档 可行性评估说明 👤人工判断
5 补充架构、部署、权限、网络等事实（如服务端架构、容器化比例） 架构/运维研发 被 @ 后 1 个工作日内 咨询单评论 事实补充 👤人工判断
6 确定承诺边界：区分"理论可行"与"工程交付承诺"，写明需客户需求立项后再做的部分 技术咨询接口人 评估完成后 0.5 个工作日内 咨询单 对外可说/不可说清单 👤人工判断
7 需出书面方案/说明：作者按对外文档模板撰写，按评审清单自检后提交评审任务 方案作者 按咨询单 DDL 飞书文档模板 + 飞书任务 方案初稿 + 自检清单 🔧飞书固化
8 评审：评审人用文档评论提意见，不直接改正文；涉及业务线时拉业务线技术评审 技术咨询接口人、业务线技术评审 提交后 1 个工作日内 飞书文档评论 评审意见 🔧+👤
9 作者按意见修改，接口人签发 方案作者、技术咨询接口人 意见后 1 个工作日内 飞书文档 签发版本（标版本号） 👤人工判断
10 提问方通过约定渠道发出，并把发出版本链接和对方反馈回填咨询单 提问方 签发后 1 个工作日内 咨询单 发出记录 🔧飞书固化
11 把通用问答沉淀为 FAQ 条目，口径变化时更新 口径维护人 关单后 3 个工作日内 FAQ 库 新增/更新的 FAQ 🔧+🤖

5. 交付物与模板

  • 交付物：技术咨询答复（含可行性等级与承诺边界）；签发版对外技术方案/产品说明；产品能力 FAQ 条目
  • 建议模板/表单：
    • 技术咨询单（多维表格）：编号、提出日期、提问方、外部来源类型、产品线（LeapCore/LeapAll/信创/跃竞等）、问题描述、附件链接、业务背景、期望答复日、类型（可行性/架构/背调/能力口径/文档评审）、可行性等级、结论、承诺边界、评估人、状态、关联 FAQ
    • 对外文档评审清单：读者与用途是否明确；能力描述与 FAQ 口径是否一致；是否区分已上线/规划中；有无未经确认的时间或性能承诺；有无内部地址、账号、客户真实名称；版本号与日期
    • 产品能力 FAQ：问题、标准答复、适用版本、限制条件、示例/文档链接、口径负责人、更新时间

6. 异常与升级

  • 评估超 DDL 未答复 → 接口人催办并重新指派 → 仍超期升级研发负责人（超期 1 个工作日）
  • 归属不清（如该问芯片厂商还是操作系统厂商、该研发组还是产品答） → 接口人当天定归口 → 定不了升级研发负责人（当天）
  • 对方要求书面承诺性能、工期或交付 → 停止技术答复，转销售负责人走 SAL-21（定制/非标需求评估、报价与特批）（当天）
  • 研发内部对"理论可行 vs 工程可行"有分歧 → 按保守结论对外答复，分歧记入咨询单 → 研发负责人裁定（2 个工作日内）
  • 对外材料已发出后发现口径错误 → 作者 0.5 个工作日内出更正版，提问方向对方更正 → 同步口径维护人更新 FAQ

7. 衡量指标

  • 咨询答复周期：提交到给出结论的工作日，目标一般问询 ≤ 1 天、方案分级/背调 ≤ 3 天
  • 登记率：外部技术问询进入咨询单的比例，目标 ≥ 90%
  • FAQ 命中率：直接用 FAQ 答复关单的比例，目标季度环比提升，半年内 ≥ 40%
  • 对外材料一次评审通过率：评审后不超过 1 轮修改即签发的比例，目标 ≥ 80%
  • 对外口径更正次数：发出后因口径错误更正的次数，目标每季度 0 次

8. 低效诊断

  • 现象：问询散落在项目群和外部小群，无统一入口与登记，只有个别问题建了待办，进度靠追问｜依据：「信创LeapCore客户端适配」2026-09
  • 现象：归口不清，不确定该问哪家厂商、哪个研发组，问题在多人间来回｜依据：「信创LeapCore客户端适配」2026-09
  • 现象：同一技术问题反复解释，"理论可行"和"工程可做"的区分说了几轮仍有分歧，缺分级结论模板｜依据：「信创LeapCore客户端适配」2026-09
  • 现象：产品能力（Skill 兼容、视频时长、API、小程序跳转）靠口头解释，合作方要示例和文档时拿不出，只能约到下周｜依据：「新媒体/电竞版Leapcore」2026-06、「新媒体/电竞版Leapcore」2026-07、「小程序问题咨询」2026-07
  • 现象：对外文档评审没有清单，终审环节直接改正文，作者看不到修改原因，同类问题下次重复出现；作者等评审回复时没有时限｜依据：（推断）
  • 现象：咨询与终审集中在一个岗位，形成单点瓶颈｜依据：「信创LeapCore客户端适配」2026-09、「新媒体/电竞版Leapcore」2026-06

9. 分支变体

  • 信创/国产化/机密计算可行性：由信创&Linux 适配负责人主评，按主机加密/虚拟机加密/容器隔离分级给结论；默认对外口径为"理论可行，工程实施以客户需求立项为准"
  • 厂商联合方案与客户架构问询：只答"当期架构"事实，未经确认的路线图不外发；需要时由架构/运维研发补事实
  • 开源项目/第三方技术背调：输出背调说明（许可证、活跃度、技术栈、与 LeapCore 适配度、风险），DDL 3 个工作日
  • 产品能力口径：先查 FAQ，口径以产品总监确认的版本为准；需要示例或 API 文档的转产品排期
  • 对外方案/产品说明/演示视频评审：内部技术方案只需领域负责人评审；对客户文档必须经接口人签发
  • 跃竞业务线：跃竞方案由跃竞技术人员先复核，再交接口人签发

10. 待确认问题

  • 主责接口人是否由创始人兼 CTO 本人担任，还是另指定研发接口人以消除单点？
  • 产品能力 FAQ 与对外口径的负责人是否为产品总监？各产品线（LeapCore/LeapAll/跃竞）是否分设口径人？
  • 时限（一般问询 1 个工作日、背调/方案分级 3 个工作日、评审 1 个工作日）是否可行？
  • 与厂商的沟通是否允许继续在外部即时通讯小群进行？结论是否必须回填飞书咨询单？
  • 对外文档是否需要统一模板（封面、版本号、免责声明）及统一发出渠道？
  • "理论可行，实操需客户需求再做"是否可作为对外标准表述？
  • 是否已有成文的对外技术承诺边界或保密要求？
RND-91产品版本生命周期与私有化实例版本支持策略待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：LeapCore 等产品同时存在多个在用版本（客户私有化、一体机、渠道实例、信创版），需要明确支持哪些版本、何时停止支持、客户如何升级
  • 负责人：主责——研发发布负责人（当前：待指定）；协同——产品负责人（当前：待指定）、交付负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 制定版本支持规则 → ② 发版时登记版本与支持截止日 → ③ 每季度盘点在用版本分布 → ④ 停止支持前提前通知 → ⑤ 推动升级 → ⑥ 到期停止补丁并登记例外
  • 交付结果：版本支持策略文件、版本生命周期表、在用版本分布表、停止支持通知
  • 状态依据：已有 X-PRD-12（跨版本线能力同步）、X-DLV-32（已交付机升级与回退）、RND-53（OTA 在线更新与强制更新）覆盖部分环节，本条补齐研发侧版本生命周期登记与支持截止规则；聊天中可见多客户多版本并行与旧版强制淘汰（推断）

1. 场景判定

  • 触发条件：正式版本发布；客户要求在旧版本上修 bug；每季度版本盘点；某版本临近支持截止
  • 典型说法：「客户还在用老版本，这个 bug 要不要给他单独修」「我们到底要维护几个版本」
  • 判断问题：问题出在哪个版本、该版本是否仍在支持期内？
  • 不归本流程管：版本发布上线 → 请走 RND-51；OTA 推送与强制更新 → 请走 RND-53；已交付机升级执行 → 请走 X-DLV-32；跨产品线能力同步 → 请走 X-PRD-12；紧急修复 → 请走 RND-54；客户通知发送 → 请走 X-CS-15；对外支持策略的产品决策与客户例外审批 → 请走 X-PRD-41（本流程负责研发侧生命周期表与补丁范围）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发布负责人 维护生命周期表、季度盘点、发起停止支持 R 研发发布负责人（当前：待指定）
产品负责人 确定支持窗口与长期支持版本 C 产品负责人（当前：待指定）
交付/售后 提供在用版本分布、执行客户升级与通知 C 交付负责人、售后负责人（当前：待指定）
研发负责人 审定支持策略与例外 A 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 已交付实例台账（X-DLV-31）中的版本号字段；各版本发布日期与 tag
  • 合同中对客户的维护期、升级承诺条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定规则：主线只修最新版；指定长期支持版本及支持月数；安全漏洞修复范围 发布负责人+产品负责人 1 个月内首版；每年复审 知识库 版本支持策略 👤人工判断
2 每次正式发版登记版本号、发布日、支持截止日 发布负责人 发版当日 多维表格 生命周期表 🔧飞书固化
3 从实例台账/OTA 后台导出在用版本分布 交付负责人 每季度首月 10 日前 LeapUpdate/台账 分布表 🤖自动化
4 对临近截止的版本向客户与销售发停止支持通知 售后负责人 截止前 60 天 客户群/邮件 通知记录 🔧飞书固化
5 排期升级，无法升级的登记例外（原因、期限、审批人） 交付负责人 截止前完成 工单系统 升级记录/例外清单 👤人工判断
6 到期后旧版本只做安全修复或不再修复 发布负责人 截止日起 工单系统 状态更新 🔧飞书固化

5. 交付物与模板

  • 交付物：版本支持策略、生命周期表、季度在用版本分布、停止支持通知模板
  • 建议模板/表单：生命周期表字段——产品、版本号、类型（正式/长期支持/信创）、发布日、支持截止日、安全修复截止日、在用实例数、备注

6. 异常与升级

  • 客户合同承诺的维护期长于支持策略 → 按合同执行并登记例外 → 升级研发负责人（3 个工作日内）
  • 旧版本出现高危漏洞 → 按 X-SEC-41 研判，必要时对停止支持版本也出补丁 → 升级研发负责人（当日）

7. 衡量指标

  • 支持期外实例占比 = 支持期外在用实例 / 在用实例总数，目标 ≤ 10%
  • 并行维护版本数，目标 ≤ 3 个

8. 低效诊断

  • 聊天中未见相关流程，存在旧版本无限期维护占用研发人力、客户版本碎片化导致问题难复现的风险（推断）

9. 分支变体

  • 信创版、行业版、白牌定制版可能需单独的支持窗口
  • 渠道代发实例的通知需同步渠道方

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 长期支持版本的支持月数（如 12 个月）是否可行？
  • 现有合同中是否已对维护期有承诺，口径是否需要法务统一？
RND-92研发数据使用合规（数据集登记、客户数据授权与脱敏）待新建推断90

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨3 × 险5

  • 适用场景：研发在评测、微调、调试、复现问题、构建知识库或评测集时，需要使用客户数据、生产数据、外部采集数据或公开数据集
  • 负责人：主责——数据集管理员（当前：待指定）；协同——使用数据的研发人员、法务（当前：待指定）、信息安全负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提出用途申请 → ② 核对来源与授权 → ③ 脱敏或取最小样本 → ④ 登记数据集 → ⑤ 受控存放与访问 → ⑥ 到期删除并留痕
  • 交付结果：数据集登记表、用途审批记录、脱敏记录、删除记录
  • 状态依据：已有 RND-84（知识库数据清洗入库）、RND-88（外包数据采集委托）、X-PRD-26（测试数据与素材获取）覆盖部分环节，本条补齐研发使用客户/生产数据的授权核对、脱敏、登记与到期删除（推断）

1. 场景判定

  • 触发条件：拿客户真实文件/对话复现 bug；用客户或生产数据做评测集、微调或 badcase 回归集；引入外部/开源数据集
  • 典型说法：「把客户那份文件拿来测一下」「这批数据能不能拿去做评测集」
  • 判断问题：数据是否来自客户或真实用户、是否含个人信息或商业秘密、合同/协议是否允许该用途？
  • 不归本流程管：登录生产环境 → 请走 X-SEC-18；导出聊天记录/CRM → 请走 X-SEC-35；外包采集 → 请走 RND-88；知识库清洗入库 → 请走 RND-84；向合作方获取案例与测试数据 → 请走 X-PRD-26；FDE 从客户现场带回数据 → 请走 X-FDE-22；开源组件许可证 → 请走 LEG-28；用户日志收集 → 请走 RND-76

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 说明用途、范围、期限并按规则使用 R 研发人员（当前：待指定）
数据集管理员 审核登记、维护台账、到期清理 R 数据集管理员（当前：待指定）
法务 判断客户合同/用户协议/许可是否允许 C 法务（当前：待指定）
研发负责人 审批客户数据与生产数据的使用 A 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 数据来源（客户、项目、平台、开源地址）、对应合同或许可证
  • 用途、数据量、使用期限、存放位置、可访问人员名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交数据使用申请 申请人 使用前 飞书审批 申请单 🔧飞书固化
2 核对来源授权；客户数据默认不得用于训练/微调，除非合同明确允许 数据集管理员+法务 1 个工作日内 合同台账 授权结论 👤人工判断
3 脱敏（姓名、手机号、证件号、客户名称）或只取最小样本 申请人 使用前 脱敏脚本 脱敏数据 🤖自动化
4 登记数据集（来源、授权、级别、位置、期限、可访问人） 数据集管理员 审批通过当日 多维表格 登记记录 🔧飞书固化
5 存放到指定受控位置，禁止放个人电脑、公开仓库或外部 AI 工具 申请人 持续 指定存储 受控存放 👤人工判断
6 到期删除或续期，删除后登记 数据集管理员 到期后 5 个工作日内 多维表格 删除记录 🔧+🤖

5. 交付物与模板

  • 交付物：数据集登记表、审批记录、删除记录
  • 建议模板/表单：数据集登记字段——名称、来源、授权依据、是否含个人信息、级别、用途、存放位置、可访问人、到期日、状态

6. 异常与升级

  • 发现客户数据被放入公开仓库或外部工具 → 立即删除并按 X-SEC-44 处理 → 升级研发负责人（1 小时内）
  • 授权不明的数据 → 暂停使用 → 由法务出结论（3 个工作日内）

7. 衡量指标

  • 数据集登记率 = 已登记数据集 / 抽查发现的数据集，目标 100%
  • 到期数据删除及时率，目标 ≥ 95%

8. 低效诊断

  • 聊天中未见相关流程，存在客户数据被用于未授权用途、个人信息外流到外部 AI 工具引发合同违约或合规处罚的风险（推断）

9. 分支变体

  • 私有化客户数据原则上不出客户环境，现场排查需在客户授权范围内进行
  • 公开数据集仅需登记许可证与来源，免审批

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 数据集管理员由哪个岗位兼任？
  • 现有客户合同与用户协议是否对数据用于改进模型有约定？

GEN 综合部统筹

报送人：赵雪冰 · 综合 · 20 条 · 已有 0 / 待优化 10 / 待新建 10
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
GEN-01制度与 SOP 起草、签发与发布宣贯任一部门要出台或修订公司级/部门级制度、规则、SOP（含集团制度需同步到子公司），或同类事务在 IM 中被反复询问、需要沉淀为 SOP 时启动主责——总经办制度统筹（当前：赵雪冰·推断待确认）；协同——制度起草部门负责人（人事：黄莹、财务：黄梦婷·推断待确认）、行政签章（当前：侯明月·推断待确认）、行政 SOP 合集维护（当前：胡则瑾·推断待确认）、总经办通知（当前：田杰、王欣·推断待确认）、SOP 技术载体（当前：柯逸飞·推断待确认）、子公司负责人（当前：徐莉·推断待确认）；签发——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项登记 → ② 起草（含适用范围） → ③ 草案共享批注 → ④ 部门负责人审 → ⑤ 总经办初审 → ⑥ 盖章与 CEO 签发 → ⑦ 公示发布与宣讲答疑 → ⑧ 入库归档、子公司同步与试运行复盘已签发并盖章的制度/SOP 正式版（含版本号、适用范围、生效日期、FAQ）、发布通知与宣讲录屏、知识库/SOP 合集条目、试运行复盘记录待优化240
GEN-02全员通知发布与必读信息分级需要全员或多部门知晓、配合的事项（放假、制度、活动、地点变更、居家安排、表单填报、重要决策）要对外发布时启动主责——总经办通知专员（当前：田杰·推断待确认）；协同——人事（当前：黄莹·推断待确认）、行政（当前：侯明月·推断待确认）、总经办（当前：赵雪冰·推断待确认）、各部门负责人（当前：杨萌等·推断待确认）；规则制定——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 判定等级与渠道 → ② 与相关负责人对齐 → ③ 按模板撰写 → ④ 通知群发布并同步负责人群 → ⑤ 负责人传达 → ⑥ 已读/回执统计 → ⑦ 截止前催办 → ⑧ 归档按模板发布的正式通知（一句话版+完整版）、已读/回执名单、重要通知归档记录待优化120
GEN-03工作沟通渠道与群职能规则任何工作事项需要沟通（需求、进展、问题、文档、客户信息）时，用于决定在哪个群/工单/文档里说，以及新建项目或群时设定群职能主责——总经办（当前：田杰·推断待确认）负责规范成文、群公告与培训；协同——规则发起与裁决 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、各群群主/项目负责人；兜底——CEO（当前：邴龙志·推断待确认）① 判断事项类型 → ② 选择渠道（项目群/工单/会议/文档） → ③ 公开沟通并 @责任人 → ④ 结论沉淀到文档/工单 → ⑤ 群置顶归集 → ⑥ 偏离时提醒与转移成文的《工作沟通规范》、各群群公告（群职能）、项目群置顶总目录、留痕可追溯的沟通记录待优化120
GEN-04沟通礼仪与对内外称谓、时间规范在工作群反馈问题、接任务、给客户或同事发工作消息、对内外称呼他人时，用于统一表达方式、发送时间与称谓主责——人事负责人（当前：待指定）负责成文写入员工手册与入职培训；协同——规则发起 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维负责人（当前：宋祺睿·推断待确认）；兜底——综合部负责人① 成文三项规范（表达、时间、称谓） → ② 写入员工手册与群公告 → ③ 入职培训讲解 → ④ 日常按模板执行 → ⑤ 偏离时就事提醒 → ⑥ 季度回顾修订《沟通礼仪与称谓规范》（员工手册章节）、问题反馈模板、对外消息定时发送规则待新建27
GEN-05临时加急审批与关键人联络飞书审批事项紧急而审批人外出、开会或未及时查看飞书，或需要尽快联系到不常看飞书的关键人员时启动主责——飞书审批管理员/人事（当前：黄莹·推断待确认）负责代理人配置与联络升级；协同——审批人（当前：丁震宇·推断待确认）、申请人（行政：侯明月、研发：葛家和等·推断待确认）、IT/飞书管理（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 申请人判定紧急等级 → ② 提交审批并标注加急 → ③ 飞书加急提醒 → ④ 超时转代理审批人 → ⑤ 电话联络关键人 → ⑥ 事后补审与记录按时完成的审批单（含代理审批记录）、审批代理人清单、关键人紧急联络表待新建54
GEN-06节假日前工作安排与值班连续 3 天及以上假期（春节、五一、国庆等）前，研发、产品、客户支持需要规划节前任务、决定发版冻结、安排值班与应急联络时启动主责——产品总监/迭代负责人（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、各值班责任人、客服/客户反馈对接人（当前：待指定）、人事（放假通知，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 假期前 3 周启动节前规划 → ② 迭代不跨假期、定发版冻结日 → ③ 排研发值班与反馈值班 → ④ 定客户升级兜底人与应急联络 → ⑤ 发布值班表 → ⑥ 假期值守与记录 → ⑦ 节后交接复盘节前任务清单、发版冻结通知、假期值班表（研发+客户反馈）、应急联络与升级路径、节后值班记录与复盘待新建96
GEN-07内部分享会与学习活动组织组织周五例行分享、AI 总动员讲座、全员培训日、销售研讨会、英语等学习小组，或公司承办/参加有保密要求的分享活动时启动主责——学习委员（当前：杨萌·推断待确认）；协同——学习委员（当前：陈梦琪·推断待确认）、各组小组学委（当前：宋祺睿、胡橙橙等·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、会务/卫生委员（当前：侯明月、赵雪冰·推断待确认）、活动助理（当前：杨黔昆·推断待确认）、主持人（当前：闫登辉·推断待确认）、审稿人（当前：丁震宇·推断待确认）；发起与激励——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 议题征集与认领 → ② 排期与确认内/外部类型 → ③ 场地与日程发布 → ④ 讲稿/材料审阅 → ⑤ 保密与录制规则确认 → ⑥ 举办与录屏 → ⑦ 资料入库与积分登记分享排期表、飞书日程与通知、审定讲稿/PPT、录屏与 AI 摘要、知识库分享归档、积分/激励登记待优化48
GEN-08团建与内部文体活动组织公司或团队组织聚餐、团建、趣味比赛、节日快闪，或员工自发组织 KTV、奶茶、桌游等活动，需要通知、报名、费用与奖品安排时启动主责——行政（当前：侯明月·推断待确认）；协同——文体委员（当前：王皓南·推断待确认）、活动发起人（当前：杨萌、张东郅等·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务（当前：待指定）；经费审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 发起与立项 → ② 预算申请 → ③ 投票/报名 → ④ 确认人数后预订 → ⑤ 通知与提醒 → ⑥ 执行（采购/奖品） → ⑦ 报销结算与登记活动报名/投票结果、已审批预算、预订与采购记录、活动通知、费用报销单与活动登记待优化36
GEN-09AI 工具订阅开通与使用补贴管理公司统一采购的 AI 订阅（如 SoruxGPT 套餐）开通、升级或月度换 CDK，以及公司要求员工使用自有 AI 产品（LeapAll/LeapCore）而需要发补贴、统计充值、调整补贴规则时启动主责——AI 工具与补贴管理专员（当前：侯明月·推断待确认）；协同——产品总监/内部使用规则发布人（当前：杨萌·推断待确认）、LeapAll 服务端后台数据（当前：邓乾·推断待确认）、创始人兼 CTO（套餐选型与研发补贴试点，当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 采购/规则确定 → ② 开通名单登记与核对 → ③ 全员通知 → ④ 月度 CDK/补贴发放 → ⑤ 次日充值与使用统计 → ⑥ 月末核对与补贴扣减 → ⑦ 超额报销/额度调整 → ⑧ 季度复盘规则AI 工具开通名单与套餐台账、每月 CDK 分发与激活记录、月度充值/使用统计表、补贴扣减与超额报销清单、成文的补贴规则（含试点细则）待优化108
GEN-10自研产品内部推广使用与反馈闭环LeapCore/LeapAll 等自研产品需要在公司内部部署、发账号、安装培训并要求各职能部门真实使用和反馈时启动主责——总经办内部推广负责人（当前：赵雪冰·推断待确认）；协同——产品发布负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、各部门负责人（当前：黄莹、黄梦婷、胡则瑾、田杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 产品发布内部使用包 → ② 账号与远程接入开通 → ③ 总经办下达部门任务 → ④ 部门建团队空间与安装试用 → ⑤ 分层培训 → ⑥ 反馈统一登记 → ⑦ 每周汇总给产品并回告 → ⑧ 月度使用复盘各部门完成安装与团队空间创建的清单、培训签到与录屏、内部反馈登记表及每周汇总、月度内部使用情况报告待优化90
GEN-11集团档案整理与合同台账管理集团需要建立或执行电子/纸质档案归档规则、组织年度/专项档案盘点，或审计、内控、尽调、领导需要查找合同、制度、资质、项目资料时启动主责——档案委员（当前：田杰、胡则瑾·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、合同整理与盖章（当前：侯明月·推断待确认）、人事/财务档案（当前：黄莹、黄梦婷·推断待确认）、各部门档案组长（当前：丁震宇、李鹏为、许君、鲁周毅、杨明学、韩诗琪、谌思铭、黄飞鹏·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 档案办法制定与审批 → ② 设档案委员与部门组长 → ③ 发前置准备通知 → ④ 排期逐部门盘点 → ⑤ 登记档案台账与合同台账 → ⑥ 纸质入档案室、电子入线上档案库 → ⑦ 权限与借阅登记 → ⑧ 月度自查、季度抽查成文的档案管理办法、集团档案台账（一级目录）、按主体分开的合同台账、线上档案库与档案室、借阅登记、月度自查与季度抽查记录待优化240
GEN-12知识库与协作文档沉淀（含飞书空间治理）项目或团队产生正式文档需要统一进知识库，团队需要建立协作基准与个人工作说明，在飞书以外工具（Agent）产出的文档需要回到飞书协作，或飞书多维表格工作台视图、权限混乱需要治理时启动主责——各项目/团队知识库管理员（当前：杨萌·推断待确认）；协同——团队协作基准编制人（当前：陈梦琪·推断待确认）、文档汇总维护人（当前：葛家和·推断待确认）、Agent 与共享上下文方法（当前：丁震宇·推断待确认）、全体项目成员；兜底——创始人兼 CTO① 按模板建知识库目录 → ② 定命名与版本规则 → ③ 正式文档在知识库创建或定稿后归档 → ④ 外部 Agent 产出导入飞书再协作 → ⑤ 项目上下文文档日更 → ⑥ 工作台视图与权限按规则配置 → ⑦ 月度检查与清理按统一目录组织的项目/团队知识库、协作基准文档（含个人说明书）、项目上下文文档、权限与视图规则清晰的工作台、月度检查记录待优化72
GEN-13荣誉资质、宣传素材与对外信息口径库对外申报、媒体拍摄、峰会演讲、外部活动或路演表单需要用到公司荣誉资质、标准公司/产品介绍或公司基本信息（主体、融资阶段、核心数据）时，从统一的库里取用；库内容新增或变化时更新主责——总经办素材与口径库管理员（当前：田杰·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、产品总监（当前：杨萌·推断待确认）、生态市场负责人（当前：许君·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）；口径终审——CEO（当前：邴龙志·推断待确认）① 建库分类与维护人 → ② 收集最新素材 → ③ 定标准介绍与口径页 → ④ CEO 审定 → ⑤ 按需取用 → ⑥ 外部表单按口径填报 → ⑦ 新荣誉/新版本即时入库 → ⑧ 季度复核分类清晰、有维护人和版本号的素材与口径库（荣誉资质、公司介绍、产品介绍、行业版、案例、视频），公司对外信息口径页，外部表单填报记录待新建108
GEN-14公司对外账号、证照年检与年报管理公司公共手机号/邮箱、公众号/小程序/服务号、以公司或财务身份注册的第三方平台账号需要开通、交接、收验证码，或 LEI 编码年检、工商年报、增值电信年报、认证续费等周期事项临近时启动主责——总经办账号与证照管理员（当前：田杰·推断待确认）；协同——财务账号持有人（当前：黄梦婷·推断待确认）、行政/电话卡管理（当前：侯明月·推断待确认）、公共邮箱与技术账号（当前：丁震宇·推断待确认）、营业执照登记（当前：王欣·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建账号与周期事项总台账 → ② 绑定公共手机号/邮箱 → ③ 新开通按申请登记 → ④ 研发需用时开子账号 → ⑤ 到期前 30 天机器人提醒 → ⑥ 责任人办理年检/年报/续费 → ⑦ 结果存档 → ⑧ 季度盘点公司对外账号与证照/编码/年报总台账、年审与续费日历、公共手机号与邮箱分配记录、各平台子账号分配记录、年报与年检回执存档待新建225
GEN-15工商变更与新机构设立手续公司发生增资扩股、股东变更、地址变更等工商变更，或需要新设研究院、子公司等机构，并且有明确完成节点时启动主责——综合部工商经办（当前：侯明月·推断待确认）；协同——COO（股东材料，当前：常元和·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：祁航·推断待确认）、法务（当前：待指定）；兜底——综合部负责人；发起与审批——CEO（当前：邴龙志·推断待确认）① 发起任务单（事项+节点） → ② 确认变更项与材料清单 → ③ 收集材料 → ④ 股东会/董事会决议与法务审核 → ⑤ 用印 → ⑥ 提交办理 → ⑦ 领取新执照 → ⑧ 同步税务、银行、社保、证照库与档案新营业执照或设立登记证明、变更登记通知书、经盖章的决议与章程修正案、后续同步事项完成清单、归档材料待新建80
GEN-16政府/领导及合作伙伴来访接待省市领导、政府部门到公司参观视察，或外部合作伙伴来访授牌、挂牌时，由总经办统筹接待方案、动线、陪同、讲解、摄影和事后归档主责——总经办接待统筹（当前：赵雪冰·推断待确认）；协同——管理层陪同（当前：邴龙志、丁震宇、常元和·推断待确认）、品牌摄影（当前：待指定）、行政（当前：待指定）；兜底——综合部负责人① 接收来访信息并确认要素 → ② 出接待方案 → ③ 分工与报备 → ④ 提前 1 天现场检查 → ⑤ 当天接待与控时 → ⑥ 事后材料存档、物品归位 → ⑦ 照片入库与宣发 → ⑧ 复盘更新模板接待方案（时间、动线、讲解点、陪同人、物料、摄影、着装）、现场照片、授牌/材料存档记录、接待复盘待新建72
GEN-17AI 前沿资讯跟踪与新工具评测分享成员发现 AI 新模型、新工具、行业文章或竞品动态，需要在内部转发沉淀、判断是否试用、产出评测结论并分享时启动主责——产研 AI 情报与评测统筹人（当前：王皓南·推断待确认）；协同——资讯机器人维护人（当前：宋祺睿·推断待确认）、鼎慧产研资讯组织人（当前：杨萌·推断待确认）、工具试用评测人（当前：魏宗浩、季学森、岳阳、宫经喜等·推断待确认）、内部宣讲人（当前：李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 转发并打标签 → ② 机器人抓摘要、去重入库 → ③ 日报/周报精选 → ④ 认领试用 → ⑤ 按模板评测 → ⑥ 审阅定结论 → ⑦ 周五分享 → ⑧ 结论归档与落地多维表格「AI 情报库」中带摘要和标签的资讯条目；统一模板的工具评测文档（含结论：采用/参考/观望/不推荐）；分享会纪要；“采用”项转入 X-PRD-09（需求池）或 FIN-02（新购开通）的记录待优化80
GEN-18制度与 SOP 定期复审、版本管理与废止已发布的制度与 SOP 需按周期复审；组织、系统、业务变化导致内容失效；同一事项存在多份版本冲突主责——制度管理员（当前：待指定）；协同——各 SOP 主责岗位、各部门负责人、法务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 建立制度/SOP 总目录 → ② 到期提醒 → ③ 主责复审（保留/修订/废止）→ ④ 修订走 GEN-01 → ⑤ 废止公告与下架 → ⑥ 更新目录制度/SOP 总目录（编号、版本、主责、复审日、状态）、复审记录、废止公告待新建60
GEN-19员工意见反馈、投诉与违规举报受理员工对制度、管理或同事行为有意见与投诉；或发现收受回扣、利益冲突、虚假报销、私卖公司数据或资源等违规行为需要举报主责——合规受理专员（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 公布受理渠道 → ② 登记分级 → ③ 指定调查人并回避 → ④ 调查取证 → ⑤ 处理决定 → ⑥ 反馈举报人 → ⑦ 保密归档受理登记、调查报告、处理决定、反馈记录待新建36
GEN-20外部来文来函收发登记与分办公司收到政府部门通知/公文、监管函、律师函、法院或仲裁文书、税务/社保通知、客户或供应商正式函件（纸质、邮件、平台站内信、挂号信等）主责——收文专员（当前：待指定）；协同——法务（当前：待指定）、行政（当前：待指定）、各承办部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 统一收文登记 → ② 当日判定类型、紧急度与回复期限 → ③ 分办承办部门 → ④ 承办人确认接收 → ⑤ 按期办理或回函 → ⑥ 发文用印 → ⑦ 归档收发文登记台账、分办记录、回函/办结记录、归档文件待新建48
GEN-01制度与 SOP 起草、签发与发布宣贯待优化240

状态：待优化｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：任一部门要出台或修订公司级/部门级制度、规则、SOP（含集团制度需同步到子公司），或同类事务在 IM 中被反复询问、需要沉淀为 SOP 时启动
  • 负责人：主责——总经办制度统筹（当前：赵雪冰·推断待确认）；协同——制度起草部门负责人（人事：黄莹、财务：黄梦婷·推断待确认）、行政签章（当前：侯明月·推断待确认）、行政 SOP 合集维护（当前：胡则瑾·推断待确认）、总经办通知（当前：田杰、王欣·推断待确认）、SOP 技术载体（当前：柯逸飞·推断待确认）、子公司负责人（当前：徐莉·推断待确认）；签发——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 立项登记 → ② 起草（含适用范围） → ③ 草案共享批注 → ④ 部门负责人审 → ⑤ 总经办初审 → ⑥ 盖章与 CEO 签发 → ⑦ 公示发布与宣讲答疑 → ⑧ 入库归档、子公司同步与试运行复盘
  • 交付结果：已签发并盖章的制度/SOP 正式版（含版本号、适用范围、生效日期、FAQ）、发布通知与宣讲录屏、知识库/SOP 合集条目、试运行复盘记录
  • 状态依据：2026-04 已定“提请人→部门负责人→总经办→签章→CEO”签发链路，2026-09 上线 SOP 合集多维表格入口；但 04～10 月仍出现适用范围未写明、合并通知拟好后延迟 2 天发出、制度被群消息淹没找不到、子公司事后才知福利差异等问题约 20 次

1. 场景判定

  • 触发条件：新制度/规则/价值观/SOP 需要起草或修订；已发布制度进入试运行复盘期；集团出台放假、福利、制度后需告知子公司；同一类问题在群里被问 3 次以上
  • 典型说法：「所有制度都是试运行，预留 1～2 个月测试期」「有意见的可以批注」「建议以后管理制度都提前说明适用范围」「SOP 一下，别忘了，不然后面又乱了」「我昨天才知道这边没有这个福利」
  • 判断问题：这件事是否需要形成对多人有约束力、可反复引用的书面规则？是否需要盖章或 CEO 签发？
  • 不归本流程管：一次性的全员通知/活动提醒 → 请走 GEN-02；人事制度的条款设计与意见征集细节 → 请走 HR-01；行政办公规范的具体条款 → 请走 ADM-12；知识库空间结构与权限治理 → 请走 GEN-12；组织架构调整发布 → 请走 CEO-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提请人 起草草案、写适用范围与生效日期、整理批注 R 制度起草人（当前：黄莹、黄梦婷等·推断待确认）
部门负责人 审核本部门草案，经授权审定并发布部门内制度 R 各部门负责人（当前：待指定）
制度统筹 登记台账、初审格式与口径、推动流转、组织宣讲 R 总经办制度统筹（当前：赵雪冰·推断待确认）
签章 加盖公章、留存鲜章版原件 R 行政签章负责人（当前：侯明月·推断待确认）
签发 原则把关与终审签发 A CEO（当前：邴龙志·推断待确认）
董事会成员 抄送知悉、跨主体意见 C CTO、COO（当前：丁震宇·推断待确认）
发布与入库 发布全员通知、写入 SOP 合集/知识库 R 总经办通知（当前：田杰·推断待确认）、行政（当前：胡则瑾·推断待确认）
SOP 载体 把 SOP 同步为 skill/机器人问答 C SOP 技术载体（当前：柯逸飞·推断待确认）
子公司负责人 判断适用性、改写子公司版执行 C/I 子公司负责人（当前：徐莉·推断待确认）
全体员工 阅读确认、宣讲参与、试运行反馈 I 全员

3. 办之前请准备

  • 制度/SOP 模板（必填：目的、适用范围与不适用主体、生效日期、条款、负责人、FAQ、版本号）
  • 现行相关制度链接，以及旧版与新版差异摘要（可由 AI 生成，人工核对）
  • 触发证据：引发本制度的问题/群聊链接，便于说明“为什么要定”
  • 发布形式与宣讲计划（全员群/部门内、是否开宣讲会、是否录屏）
  • 涉及子公司时：子公司现行做法与差异点清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在“制度/SOP 台账”登记名称、起草人、适用主体、计划发布日期 提请人 决定起草当天 飞书多维表格 台账条目 🔧飞书固化
2 按模板起草，必须写明适用范围（哪些主体/人群不适用）与生效日期 提请人 登记后 5 个工作日内 飞书文档模板、AI 辅助 草案 v0.x 🤖+👤
3 草案共享至负责人群，@相关负责人并写明截止时间，意见在文档批注，无异议在原消息点✅ 提请人 征求期 2～3 个工作日 飞书文档批注 批注与确认记录 🔧飞书固化
4 部门负责人审核，部门内制度可直接转第 7 步发布 部门负责人 收到后 2 个工作日内 飞书审批“制度发布” 部门审核意见 🔧飞书固化
5 总经办初审：格式、口径、与现行制度冲突、适用范围是否写清 制度统筹 收到后 2 个工作日内 飞书审批 初审意见 👤人工判断
6 行政盖章并留存鲜章版原件；CEO 签发并抄送董事会成员 签章、CEO 签章 1 个工作日内；签发 2 个工作日内 飞书审批、实体用印 正式签发版 🔧飞书固化
7 发布：全员制度由综合部在通知群发“一句话版+完整版+生效日期+适用范围”；部门制度由负责人在部门群发布 总经办通知/部门负责人 签发后 1 个工作日内 通知群、飞书公告 发布通知 🔧+🤖
8 发布同时用表单征集疑问；组织宣讲会（线上+线下、录屏），各负责人组内传导 制度统筹 发布后 5 个工作日内 飞书表单、飞书会议录屏 宣讲录屏、FAQ 🔧+🤖
9 写入 SOP 合集/知识库并标注版本号；涉及子公司时同步抄送子公司负责人，由其 3 个工作日内回复“适用/改写/不适用” 发布与入库 发布当天 SOP 合集多维表格、知识库、指导意见群 入库条目、子公司回执 🔧飞书固化
10 试运行 1～2 个月：发布后约半月集中复盘一次，到期汇总问卷决定转正式或修订 制度统筹 发布后第 15 天、试运行到期前 5 个工作日 飞书问卷 复盘记录、修订版 👤人工判断

5. 交付物与模板

  • 交付物：正式签发版制度/SOP、发布通知、宣讲录屏与 FAQ、SOP 合集条目、子公司适用回执、试运行复盘记录
  • 建议模板/表单：
    • 制度/SOP 台账：名称、类型（制度/SOP/规则）、起草人、主责部门、适用主体、不适用主体、状态（起草/征求/审核/签发/试运行/正式/废止）、版本号、生效日期、链接、复盘日期
    • 制度正文模板：目的、适用范围、术语、条款、负责人、流程图、FAQ、修订记录
    • 发布通知模板：一句话摘要、对谁生效、何时生效、需要员工做什么、文档链接、答疑入口

6. 异常与升级

  • CEO 为制度签发的唯一最终决策人（A）；仅在本部门内生效的部门级制度，由 CEO 授权部门负责人审定发布，发布后 1 个工作日内报制度统筹登记；内容涉及跨部门、全员或子公司的，一律回到 CEO 签发
  • 征求期截止仍有负责人未确认 → 截止当天提醒一次，次日视为无异议并在群内说明 → 有原则性分歧升级 CEO（1 个工作日内）
  • 签发停滞（已拟好通知超过 2 个工作日未发出）→ 制度统筹提醒签发人 → 升级 CEO（第 3 个工作日）
  • 发布后出现条款理解争议 → 制度统筹 2 个工作日内补发 FAQ 或补充说明 → 涉及劳动争议风险升级人事负责人与法务
  • 子公司对适用范围有异议 → 子公司负责人 3 个工作日内提出 → 升级董事会（CEO、CTO、COO）裁定
  • 同一问题在群内被问 3 次以上仍无 SOP → 由所在部门负责人发起本流程，统筹人登记台账

7. 衡量指标

  • 签发周期 = 草案提交到 CEO 签发的工作日数，目标 ≤ 7 个工作日
  • 适用范围完整率 = 写明适用/不适用主体的制度数 / 发布制度数，目标 100%
  • 入库率 = 发布当天入 SOP 合集/知识库的制度数 / 发布制度数，目标 100%
  • 制度类重复提问数 = 生效后 1 个月内群内同一条款被问的次数，目标 ≤ 2 次
  • SOP 化程度（CEO 口径）= 同类事务在 IM 中需要说明的消息量，按季度对比呈下降趋势

8. 低效诊断

  • 现象：签发环节无时限，已拟好的合并通知延迟约 2 天才发出｜依据：「【模态】综合部」2026-09
  • 现象：制度定位“讲原则”与综合部“细化条款”取向不一，草案反复讨论｜依据：「【模态】综合部」2026-05
  • 现象：制度未事先写明对子公司是否适用，发布后才补充说明｜依据：「【模态】业务负责人」2026-08、「模态跃迁通知群」2026-08
  • 现象：制度、报销流程发在群里被消息淹没，置顶/Pin 也找不到，新人逐一询问｜依据：「模态集团（全员群）」2026-02、2026-04
  • 现象：集团福利/制度调整未同步子公司，子公司事后才得知差异｜依据：「跃竞模态董事会」2026-09
  • 现象：SOP 化已推动三周仍有大量重复询问，SOP 入口集中于单人，载体偏 skill、缺人可读文档｜依据：「AI API」2026-09、2026-10

9. 分支变体

  • 全员制度：行政/综合部在全员通知群发布，需宣讲会；部门内部制度：部门负责人审核后直接在部门群发布，抄送总经办入库
  • 行政财务人事类（报销、备用金、接待、考勤、休假、福利、积分、内推）：条款细节分别走 HR-01、ADM-12 及对应财务 SOP，本流程管签发与发布
  • 集团→子公司同步：通过“指导意见参考群”抄送子公司负责人，子公司改写为本主体版本执行
  • SOP 沉淀（非制度）：无需盖章，部门负责人审核后入 SOP 合集，同时可同步为 skill/机器人问答
  • 不同主体（武汉模态、鼎慧、苏州、跃竞、曜途）：正文必须注明适用主体

10. 待确认问题

  • 制度统筹由总经办还是综合部负责人担任？SOP 合集入口由行政还是总经办维护？
  • 部门内部制度是否也需要报总经办登记入库？
  • 各环节时限（部门审 2 天、初审 2 天、签发 2 天）是否可行？是否上线飞书“制度发布”审批？
  • 试运行期 1～2 个月是否统一为固定期限？复盘由谁主持？
  • SOP 是否需要 CEO 签发，还是部门负责人签发即可？
GEN-02全员通知发布与必读信息分级待优化120

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频4 × 耗2 × 跨5 × 险3

  • 适用场景：需要全员或多部门知晓、配合的事项（放假、制度、活动、地点变更、居家安排、表单填报、重要决策）要对外发布时启动
  • 负责人：主责——总经办通知专员（当前：田杰·推断待确认）；协同——人事（当前：黄莹·推断待确认）、行政（当前：侯明月·推断待确认）、总经办（当前：赵雪冰·推断待确认）、各部门负责人（当前：杨萌等·推断待确认）；规则制定——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 判定等级与渠道 → ② 与相关负责人对齐 → ③ 按模板撰写 → ④ 通知群发布并同步负责人群 → ⑤ 负责人传达 → ⑥ 已读/回执统计 → ⑦ 截止前催办 → ⑧ 归档
  • 交付结果：按模板发布的正式通知（一句话版+完整版）、已读/回执名单、重要通知归档记录
  • 状态依据：2026-01 已宣布“正式通知发通知群、书面无歧义”，2026-06 定“全公司事宜负责人责任制”；但通知群人人可发、全员群与通知群职责重叠，01～10 月出现走错地点、重复转发、“通知了没人看”、负责人不知要不要通知等约 30 次

1. 场景判定

  • 触发条件：事项影响全员或 2 个以上部门；需要员工在指定时间到场/填表/安装/确认；地点、时间、规则发生变更；重要决策（客户见面、组织调整、技术重构）需要相关人知晓
  • 典型说法：「请注意通知一定要写得清楚明白，不要有歧义」「看通知群」「明天居家吗，要通知大家吗」「涉及全公司的事宜，负责人责任制」「正式的事情正式通知」
  • 判断问题：不看到这条消息的人会不会走错、错过、做错？如果会，就按本流程发
  • 不归本流程管：制度的起草与签发 → 请走 GEN-01；日常工作讨论放哪个群 → 请走 GEN-03；放假调休安排本身 → 请走 HR-13；停电/台风等突发 → 请走 ADM-09；人事任免异动 → 请走 HR-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事项发起人 提供内容、确定对象和截止时间 R 各部门（当前：按事项）
通知专员 审稿、按模板发布、维护通知归档 R 总经办通知专员（当前：田杰·推断待确认）
人事/行政发布人 发布放假、考勤、表单、活动类通知 R 人事（当前：黄莹·推断待确认）、行政（当前：侯明月·推断待确认）
部门负责人 组内传达、统计名单、督促未完成者 R 各部门负责人（当前：杨萌等·推断待确认）
综合部负责人 发布权限与分级规则把关 A 综合部负责人（当前：赵雪冰·推断待确认）
规则制定 定通知规则与渠道边界 C CEO（当前：邴龙志·推断待确认）
全体员工 阅读、确认、按要求行动 I 全员

3. 办之前请准备

  • 事项要素：背景、对象（全员/哪些部门/哪些主体）、时间、地点（附导航/楼层）、要员工做什么、截止时间、联系人
  • 等级判断：必读（需回执）/ 知悉 / 选读
  • 复杂事项先与相关负责人确认口径的记录
  • 报名/确认用的多维表格或表单链接

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定等级：A 必读需回执（到场、填表、规则变更）；B 知悉；C 选读（分享、活动推荐） 事项发起人 事项确定当天 分级规则表 等级标签 👤人工判断
2 复杂事项与相关负责人对齐口径（时间、范围、例外） 事项发起人 发布前 1 个工作日 负责人群 口径确认 👤人工判断
3 按模板写“一句话版+完整版”，用正式书面语，写清对象、时间、地点、动作、截止 发起人起草、通知专员审稿 审稿 2 小时内 通知模板、AI 校对 定稿通知 🤖+👤
4 A/B 级在通知群发布（仅授权人可发），A 级同时同步负责人群；C 级发全员群或兴趣群 通知专员/人事/行政 定稿后当天；需到场类至少提前 1 个工作日 飞书通知群、群公告、机器人卡片 已发布通知 🔧飞书固化
5 部门负责人转到部门群并组织填写/确认 部门负责人 收到后 4 个工作小时内 部门群 组内传达 👤人工判断
6 A 级通知用机器人卡片/表单统计已读与回执，拉出未读/未填名单 通知专员 截止前 1 个工作日 飞书已读统计、多维表格 未完成名单 🔧+🤖
7 机器人按名单 @未完成者，抄送其部门负责人 机器人/部门负责人 截止前 1 个工作日 群机器人 催办记录 🤖自动化
8 变更通知：原通知下回复“已变更”，并重新发一条带【变更】标识的通知 原发布人 变更确定后 1 小时内 通知群 变更通知 🔧飞书固化
9 A 级通知同步写入知识库“通知归档”，制度类挂对应制度条目 通知专员 发布当天 知识库 归档条目 🔧飞书固化

5. 交付物与模板

  • 交付物：正式通知、回执/已读名单、变更通知、通知归档
  • 建议模板/表单：
    • 通知模板：【等级】标题｜一句话版｜背景｜对象（含不适用主体）｜时间地点｜需要你做什么｜截止时间｜联系人｜附件/链接
    • 回执表：姓名、部门、是否已读、是否完成、完成时间、备注
    • 重要事项同步模板：做了什么/决定了什么/影响谁/需要谁做什么/截止时间

6. 异常与升级

  • 有人未看通知走错地点/错过 → 发布人在原群补发一次并 @当事人 → 同类情况一月 2 次以上，升级综合部负责人复盘渠道（1 周内）
  • 发布后发现有歧义 → 1 小时内发【更正】通知 → 涉及金额或权益时升级综合部负责人
  • 截止当天回执率 < 80% → 通知专员把未完成名单发负责人群 → 升级 CEO（次日）
  • 部门负责人不确定是否需要通知 → 默认“需要”，按 B 级发布 → 有疑问问综合部负责人（当天）

7. 衡量指标

  • A 级通知回执率 = 截止时已回执人数 / 应回执人数，目标 ≥ 95%
  • 重复通知率 = 因未看/歧义而补发的通知数 / 发布通知数，目标 ≤ 10%
  • 通知模板合规率 = 含对象、时间、动作、截止四要素的通知数 / 发布通知数，目标 100%
  • 需到场类通知提前量 = 发布到活动开始的小时数，目标 ≥ 24 小时

8. 低效诊断

  • 现象：通知群人人可发，与全员群职责重叠，重要消息被讨论淹没｜依据：「模态集团（全员群）」2026-01、2026-02
  • 现象：活动地点变更后员工未看到通知走错地点，靠在闲聊群重复回答｜依据：「随便瞎聊啦～」2026-01、2026-02
  • 现象：居家办公、团建是否通知、由谁通知无人拍板，最后不了了之｜依据：「鼎慧产研决策部」2026-04
  • 现象：全员事项需要负责人反复督促，同一内容在负责人群与通知群重复发，到岗时间表述不清｜依据：「【模态】业务负责人」2026-05、2026-06、2026-10
  • 现象：没有所有人必读的频道，个人只能靠机器人监控群消息｜依据：「鼎慧产研决策部」2026-03
  • 现象：客户见面、组织调整等重要事项只在小群一句话带过，相关人事后才知道与自己有关｜依据：「鼎慧产研决策部」2026-05
  • 现象：同一问题到处问、私聊传达，正式通知要求被反复重申｜依据：「模态跃迁通知群」2026-01、2026-09

9. 分支变体

  • 渠道：飞书通知群（A/B 级正式通知）、全员群（C 级与互动）、公司微信群（仅外部化或实名场景，正式内容仍以飞书为准）
  • 大会/培训动员：负责人责任制，按部门统计名单，用多维表格确认表
  • 居家/团建/分享会：由组织人决定并按 B 级发布，到场要求写清
  • 重要决策同步：使用“重要事项同步模板”，在相关部门群发布，不在私聊或小群一句话带过
  • 安装自查类（如 LeapCore 安装）：附自查表与数据平台未完成名单

10. 待确认问题

  • 通知群发布权限是否收紧为综合部+部门负责人？谁是管理员？
  • 三级分级（必读/知悉/选读）是否合适？A 级是否一律要求回执？
  • 全员群是否正式定位为闲聊/互动群？
  • 部门负责人传达时限 4 个工作小时是否可行？
  • 是否采购/开发带已读统计的通知机器人？
GEN-03工作沟通渠道与群职能规则待优化120

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频5 × 耗2 × 跨4 × 险3

  • 适用场景：任何工作事项需要沟通（需求、进展、问题、文档、客户信息）时，用于决定在哪个群/工单/文档里说，以及新建项目或群时设定群职能
  • 负责人：主责——总经办（当前：田杰·推断待确认）负责规范成文、群公告与培训；协同——规则发起与裁决 CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、各群群主/项目负责人；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 判断事项类型 → ② 选择渠道（项目群/工单/会议/文档） → ③ 公开沟通并 @责任人 → ④ 结论沉淀到文档/工单 → ⑤ 群置顶归集 → ⑥ 偏离时提醒与转移
  • 交付结果：成文的《工作沟通规范》、各群群公告（群职能）、项目群置顶总目录、留痕可追溯的沟通记录
  • 状态依据：2026-04～10 管理层多次口头宣布“少私聊、工作进工作群、闲聊群不聊工作”，同一规则被重申 15 次以上，但无书面规范，需求仍在私聊/微信中流转，新人接手无上下文

1. 场景判定

  • 触发条件：准备私聊同事谈工作；在闲聊/学习群里提工作问题；需求或项目开始但还没有专群；客户资料在微信群或本地文件里；需要开会同步
  • 典型说法：「别私聊，要不开会，要不群里说，要不工单上说」「工作安排在产研群讨论」「闲聊群别聊工作，工作群别闲聊」「这需求连群聊都没有，一直私聊沟通」
  • 判断问题：这条信息以后会不会有第二个人需要看到？如果会，就不能只在私聊里说
  • 不归本流程管：全员正式通知 → 请走 GEN-02；措辞礼仪与发送时间 → 请走 GEN-04；会议组织与纪要 → 请走 CEO-10；工单状态维护 → 请走 RND-11；知识库空间治理 → 请走 GEN-12；对外口径与话术 → 请走 X-CS-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范维护 起草/更新《工作沟通规范》、写入入职培训、维护群清单 R 总经办（当前：田杰·推断待确认）
规则裁决 定原则、裁决例外（涉密、对外） A CTO（当前：丁震宇·推断待确认）
研发群执行 产研群、工单渠道执行与提醒 R Leap 研发负责人（当前：王皓南·推断待确认）
产品/客户信息执行 推动客户沟通转飞书 R 产品总监（当前：杨萌·推断待确认）
项目负责人/群主 建专群、写群公告、置顶总目录 R 各项目负责人（当前：郭逸非、陈子康等·推断待确认）
机器人 纪要、归集、偏题提醒 C 智能纪要助手等机器人
全员 遵守 I 全员

3. 办之前请准备

  • 公司群清单：群名、职能（工作/项目/对接/通知/学习闲聊）、群主、是否允许外部成员
  • 群公告模板与“总目录”文档模板
  • 涉密信息范围说明（哪些可私聊）
  • 工单系统、会议纪要机器人已开通

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判断事项类型：可追踪任务/缺陷 → 工单；需多人讨论 → 项目/工作群；需实时对齐 → 会议；仅涉密 → 私聊并事后补结论 发起人 发言前 渠道选择表 渠道选择 👤人工判断
2 新需求/项目涉及 3 人以上：建项目专群，写群公告（目标、负责人、群职能），置顶总目录文档 项目负责人 项目启动当天 飞书群、群公告 项目群+总目录 🔧飞书固化
3 群内沟通必须 @具体责任人，一条消息写完整（现象、诉求、截止） 发起人 每次 飞书群 可追溯消息 👤人工判断
4 会议使用飞书日程；开启智能纪要，纪要发回对应群 会议发起人 会后 1 小时内 飞书日程、妙记 会议纪要 🤖自动化
5 结论、需求、文档链接写进工单或总目录；日报等文档按人命名挂置顶 当事人 结论形成当天 工单系统、飞书文档 留痕记录 🔧飞书固化
6 客户资料与沟通统一沉淀到飞书（外部群或文档）；客户只用微信时，对接人当天把文件/要点转存飞书项目群 客户对接人 收到后当天 飞书外部群、文档 客户资料归档 🔧飞书固化
7 发现工作内容出现在闲聊群/私聊：任何人可提醒“移步 XX 群”，当事人转贴到对应群 群主/任何成员 发现即提醒 群机器人 转移后的讨论 🤖+👤
8 每两周用 AI 整理项目群聊信息，生成进展摘要并更新总目录 项目负责人 每两周一次 AI 机器人 进展摘要 🤖自动化
9 新员工入职培训讲解《工作沟通规范》 总经办/人事 入职首周 培训材料 培训记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《工作沟通规范》、群清单、各群群公告、项目总目录文档、会议纪要
  • 建议模板/表单：
    • 渠道选择表：事项类型 → 渠道 → 示例（缺陷→工单；需求讨论→项目群；跨团队对齐→会议；涉密人事→私聊）
    • 群公告模板：群职能、可讨论/不可讨论内容、群主、相关群链接、置顶总目录
    • 群清单字段：群名、类型、主体、群主、成员范围、是否含外部、创建日期、状态

6. 异常与升级

  • 同一人一月内被提醒 3 次以上仍私聊处理工作 → 部门负责人一对一沟通 → 仍未改善转人事处理（1 周内）
  • 需求只在私聊流转导致交接断档 → 接手人在项目群公开要求补上下文 → 原对接人 1 个工作日内补齐，否则升级项目负责人
  • 客户坚持用微信/钉钉/腾讯会议 → 对接人可用，但当天转存要点到飞书 → 关键客户长期不用飞书时升级销售负责人
  • 规则与涉密冲突（人事、薪酬、个人事项）→ 允许私聊，不需转存

7. 衡量指标

  • 项目专群覆盖率 = 有专群和群公告的在研项目数 / 在研项目数，目标 100%
  • 偏题提醒次数 = 每月在闲聊群/学习群内的“移步”提醒数，目标逐月下降
  • 交接断档事件 = 因上下文只在私聊导致接手返工的次数，目标每季度 0 次
  • 会议纪要回群率 = 有纪要发回对应群的会议数 / 会议数，目标 ≥ 90%

8. 低效诊断

  • 现象：对接信息放在私聊，跨天口头结论未记录，会议室不够临时改线上｜依据：「Leap产研测」2026-07
  • 现象：成员习惯私聊不在群里回复，关键信息只在私聊，管理层讨论用权限手段约束｜依据：「鼎慧产研决策部」2026-04
  • 现象：同一“闲聊群不聊工作”规则被重复宣告约 5 次，技术/网络/采购讨论仍在闲聊群｜依据：「鸽子群模态分群」2026-06、2026-07、2026-08
  • 现象：AI 学习群里出现 CI、网络、招聘、报销等工作问题，信息难追溯｜依据：「跃迁AI总动员」2026-09
  • 现象：一个需求五六人参与但无专群，新人接手无上下文｜依据：「Leap产研决策部」2026-09
  • 现象：文档分散，业务方“到处找或啥都得问”，仍有用微信说正事｜依据：「公司内FDE」2026-08、2026-09、2026-10
  • 现象：客户沟通在微信群和本地文件里，研发拿不到上下文，需人工逐次转发飞书｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 研发：任务和缺陷优先进工单，讨论在产研群，闲聊群不展开工作安排
  • 内部 FDE/业务系统：一个总文档+分文档置顶归集，系统手册集成在系统内
  • 客户沟通：优先飞书外部群；客户使用微信/钉钉/腾讯会议时，对接人当天转存要点到飞书
  • 涉密事项（人事、薪酬、个人事务）：允许私聊，不要求公开
  • 学习/闲聊群：群公告写明“不讨论工作安排”

10. 待确认问题

  • 《工作沟通规范》由总经办还是综合部负责人起草？是否纳入员工手册？
  • “3 人以上建专群”的门槛是否合适？
  • 是否对闲聊群设置关键词提醒机器人？
  • 客户沟通是否强制使用飞书外部群？对不用飞书的管理层/客户如何例外处理？
  • 群主是否需要在群清单中登记并定期清理失效群？
GEN-04沟通礼仪与对内外称谓、时间规范待新建27

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗1 × 跨3 × 险3

  • 适用场景：在工作群反馈问题、接任务、给客户或同事发工作消息、对内外称呼他人时，用于统一表达方式、发送时间与称谓
  • 负责人：主责——人事负责人（当前：待指定）负责成文写入员工手册与入职培训；协同——规则发起 CTO（当前：丁震宇·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/运维负责人（当前：宋祺睿·推断待确认）；兜底——综合部负责人
  • 核心流程：① 成文三项规范（表达、时间、称谓） → ② 写入员工手册与群公告 → ③ 入职培训讲解 → ④ 日常按模板执行 → ⑤ 偏离时就事提醒 → ⑥ 季度回顾修订
  • 交付结果：《沟通礼仪与称谓规范》（员工手册章节）、问题反馈模板、对外消息定时发送规则
  • 状态依据：目前只有口头纠偏：2026-09 管理层集中要求“一次性说完、就事论事、不甩锅、不玩梗”约 8 次；2026-02 提出“给客户的消息在工作时间发”；2026-03 称谓“不让叫总”执行不统一，均无书面规范

1. 场景判定

  • 触发条件：在群里报问题或回应他人；接到任务分派；非工作时间准备给客户/同事发工作消息；新入职外联、市场同事对内外称呼他人
  • 典型说法：「能不能下次一次性说完」「不要下意识用攻击性语气，就事论事」「给你活别第一反应是甩活」「聊工作不要玩梗」「工作消息尽量在工作时间发，尤其是给客户的」「公司不让叫总」
  • 判断问题：这条消息对方一次能看懂吗？发送时间合适吗？称呼符合公司规范吗？
  • 不归本流程管：消息应发到哪个群 → 请走 GEN-03；全员正式通知写法 → 请走 GEN-02；对外话术与产品口径 → 请走 X-CS-17；员工行为问题处置 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规范维护 起草、写入员工手册、纳入入职培训 R 人事负责人（当前：待指定）
规则发起 确定原则与示范话术 A CTO（当前：丁震宇·推断待确认）
部门负责人 组内执行、就事提醒、示范 R 产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
协作者 反馈执行问题与改进建议 C 后端/运维负责人（当前：宋祺睿·推断待确认）
全员 遵守 I 全员

3. 办之前请准备

  • 问题反馈模板（现象/版本/影响/复现/需要谁）
  • 公司工作时间定义与客户免打扰时段
  • 称谓清单：内部称呼方式、对外称呼方式（客户、政府、合作方）
  • 飞书“定时发送”使用说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草《沟通礼仪与称谓规范》：表达（一次说完、就事论事、先解决再追因、@精准、不玩梗）、时间、称谓三章 人事负责人 立项后 10 个工作日内 飞书文档 规范初稿 👤人工判断
2 部门负责人审阅，CTO 确认后按 GEN-01 发布 部门负责人、CTO 5 个工作日内 飞书文档批注 定稿 👤人工判断
3 写入员工手册、产研群公告；问题反馈模板做成群快捷模板/表单 人事负责人 发布当天 员工手册、群公告、飞书表单 公告与模板 🔧飞书固化
4 反馈问题时按模板一条发完；接到任务先确认能否承接，不能则说明原因并给出替代人或时间 全员 每次 反馈模板 完整的问题描述 🤖+👤
5 工作时间（工作日 9:00～19:00，待确认）外给客户发消息一律用定时发送；同事间非紧急消息同样定时，紧急事项按 GEN-05 升级 发送人 每次 飞书定时发送 定时消息 🔧飞书固化
6 对内统一称呼姓名或“老师/同学”等（不称“总”“哥”）；对外按客户习惯称职务 全员 每次 称谓清单 统一称谓 👤人工判断
7 发现偏离：负责人就事提醒并示范改写，不公开指责个人 部门负责人 发现当天 群内回复 提醒记录 👤人工判断
8 入职首周培训讲解本规范 人事负责人 入职首周 培训材料 培训记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《沟通礼仪与称谓规范》、问题反馈模板、称谓清单
  • 建议模板/表单：
    • 问题反馈模板：产品/版本、现象、复现步骤、影响范围、紧急程度、期望谁处理、截止时间
    • 任务回应模板：收到/可承接时间 或 无法承接原因+建议承接人
    • 称谓清单：对象类型（同事/上级/客户/政府/合作方）、推荐称呼、禁用称呼

6. 异常与升级

  • 群内出现情绪化或甩锅式争执 → 部门负责人当场暂停争论、转为线下或会议讨论 → 反复出现升级人事负责人（1 周内）
  • 非工作时间必须联系客户（故障、交付） → 先电话/消息征得客户方对接人同意 → 告知部门负责人
  • 外部客户对称谓有特殊要求 → 以客户习惯为准，在客户台账备注

7. 衡量指标

  • 反馈模板使用率 = 按模板提交的问题反馈数 / 群内问题反馈数（抽样），目标 ≥ 80%
  • 对客户非工作时间消息数 = 每月 22:00 后～次日 8:00 前对客户发送的非紧急消息数，目标 0
  • 同类提醒次数 = 每月负责人就沟通方式提醒的次数，目标逐月下降

8. 低效诊断

  • 现象：同一问题分多条消息描述、描述模糊引发误判，被要求“一次说完”｜依据：「Leap产研测」2026-09
  • 现象：接任务第一反应是推给他人，问题定位时出现推责语气｜依据：「Leap产研测」2026-09
  • 现象：@人过多或不准，谁处理不清｜依据：「Leap产研测」2026-09
  • 现象：深夜向客户发送工作通知，周末交付是否打扰客户领导无规则可依｜依据：「鼎慧产研决策部」2026-02
  • 现象：对新加入外联同事的称谓不统一，靠群内玩笑讨论｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 对内：称呼姓名，表达以解决问题为先
  • 对客户：工作时间发送，非工作时间用定时发送；紧急故障除外
  • 对政府/合作方：称谓按对方习惯与职务，口径按 X-CS-17

10. 待确认问题

  • 本规范由人事还是总经办牵头？是否并入 GEN-03 的《工作沟通规范》作为一章？
  • 公司“工作时间”与对客户免打扰时段如何定义？
  • 对内称谓规则（不称“总”）是否为公司正式要求？对外是否例外？
  • 是否需要将违反沟通规范纳入绩效或积分评价？
GEN-05临时加急审批与关键人联络待新建推断54

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频3 × 耗2 × 跨3 × 险3

  • 适用场景：飞书审批事项紧急而审批人外出、开会或未及时查看飞书，或需要尽快联系到不常看飞书的关键人员时启动
  • 负责人：主责——飞书审批管理员/人事（当前：黄莹·推断待确认）负责代理人配置与联络升级；协同——审批人（当前：丁震宇·推断待确认）、申请人（行政：侯明月、研发：葛家和等·推断待确认）、IT/飞书管理（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 申请人判定紧急等级 → ② 提交审批并标注加急 → ③ 飞书加急提醒 → ④ 超时转代理审批人 → ⑤ 电话联络关键人 → ⑥ 事后补审与记录
  • 交付结果：按时完成的审批单（含代理审批记录）、审批代理人清单、关键人紧急联络表
  • 状态依据：（推断）目前没有审批代理与超时转交规则，审批人不在时依赖私下催办或让申请人换人重提，容易出现重复审批单；关键人员未及时查看飞书时需改用电话联络，联络耗时不可控

1. 场景判定

  • 触发条件：审批事项影响当天/次日业务（物料加印、应用上线、测试放行、采购付款）而审批未动；需联系的人超过 2 小时未回复飞书
  • 判断问题：不在今天/约定时间内审批，会不会造成交付、活动或资金损失？若不会，就按正常审批等待
  • 不归本流程管：审批流本身的设计与审批人设置 → 请走 HR-02；生产故障的应急响应 → 请走 RND-75；客户问题升级 → 请走 X-CS-05；资源/资产申领审批规则 → 请走 ADM-34

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 判定紧急等级、提交并标注加急原因 R 各部门申请人（当前：侯明月、葛家和等·推断待确认）
审批人 在时限内审批，外出前设置代理 A 各审批节点负责人（当前：丁震宇·推断待确认）
审批管理员 配置审批代理、超时自动转交、维护联络表 R 飞书审批管理员/人事（当前：黄莹·推断待确认）
飞书管理 配置机器人提醒与超时规则 C IT/飞书管理（当前：杨明学·推断待确认）
综合部负责人 兜底审批与联络升级 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 审批代理人清单：每个审批节点的第一代理人、可代理事项范围与金额上限
  • 关键人紧急联络表：飞书之外的备用联系方式（存于人事，仅授权人可见）
  • 紧急等级定义：P0 当天必须完成；P1 次日完成；P2 正常流程
  • 加急原因说明（影响什么、截止时间）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定紧急等级，在审批单“加急原因”字段写明影响与截止时间 申请人 提交时 飞书审批 带加急标识的审批单 🔧飞书固化
2 只提交一张审批单，不重复提单；需改内容时撤回重提并在备注注明 申请人 提交时 飞书审批 唯一有效审批单 🔧飞书固化
3 P0/P1 审批提交后用飞书“加急”提醒审批人 申请人 提交后 30 分钟 飞书加急 提醒记录 🔧飞书固化
4 P0 超过 2 个工作小时、P1 超过 1 个工作日未处理 → 自动转交代理审批人 系统/审批管理员 按时限自动 飞书审批超时规则 代理审批 🤖+👤
5 代理人也无响应 → 申请人联系审批管理员，按联络表电话联系审批人 审批管理员 转交后 1 小时 电话 联络结果 👤人工判断
6 仍联系不上 → 综合部负责人兜底审批或决定延期 综合部负责人 当天 飞书审批 审批结果/延期决定 👤人工判断
7 审批人外出前设置审批代理，并在飞书状态中注明 审批人 外出前 飞书审批代理设置 代理生效 🔧飞书固化
8 测试类审批需“刻意慢批”验证流程的，提前在研发群说明，避免被当作紧急催办 研发申请人 提交前 研发群 说明记录 👤人工判断
9 每月汇总加急与代理审批记录，查找高频加急事项并优化流程 审批管理员 每月 5 日前 多维表格 月度加急报告 🤖+👤

5. 交付物与模板

  • 交付物：已完成审批单、代理审批记录、月度加急报告、审批代理人清单、关键人紧急联络表
  • 建议模板/表单：
    • 审批单新增字段：紧急等级（P0/P1/P2）、加急原因、业务截止时间
    • 代理人清单：审批节点、审批人、代理人、代理范围、金额上限、生效时间
    • 加急记录：审批单号、等级、提交时间、完成时间、是否代理、是否电话联络、原因分类

6. 异常与升级

  • 各审批节点的审批人为该事项唯一决策人（A）；综合部负责人作为 A（升级）的条件：原审批人与代理审批人在转交后 1 小时内均无响应，或资金/合同类加急不允许代理而原审批人无法联系，由综合部负责人当天兜底审批或决定延期
  • 发现同一事项存在多张审批单 → 申请人撤回多余单据，审批管理员核对 → 重复出现升级综合部负责人
  • 关键人员长期不看飞书导致审批或协作延误 → 审批管理员记录 → 每月汇总后由综合部负责人与本人沟通，要求开启飞书通知
  • 涉及资金/合同的加急 → 不允许代理越权，必须原审批人或兜底人审批
  • 联络表信息变更 → 本人 3 个工作日内告知人事更新

7. 衡量指标

  • 加急审批按时完成率 = 在业务截止前完成的加急审批数 / 加急审批数，目标 ≥ 95%
  • 重复审批单数 = 每月同一事项多张审批单的数量，目标 0
  • 代理覆盖率 = 已设置代理人的审批节点数 / 审批节点总数，目标 100%
  • 关键人联络时长 = 发起联络到获得回复的时间，目标 P0 ≤ 2 小时

8. 低效诊断

  • 现象：审批依赖单一审批人，审批人外出时只能私下催办或换人重提｜依据：（推断）
  • 现象：同一事项产生多张审批单并被“留着备用”，审批记录不清｜依据：（推断）
  • 现象：关键人员不常查看飞书，飞书加急无效后才改用电话、其他即时通讯工具，联系耗时长｜依据：（推断）
  • 现象：缺少超时自动转交和代理设置，加急全部靠人工｜依据：（推断）

9. 分支变体

  • 行政物料加急（如积分卡加印）：P0，代理人可审批，金额超限需原审批人
  • 研发应用/测试审批：P1，代理人可审批；刻意慢批的测试需事先说明
  • 资金/合同类：不适用代理，走原审批人或兜底人
  • 联系不常看飞书的管理层：按联络表电话联系，由审批管理员执行

10. 待确认问题

  • 主责是人事还是 IT/飞书管理员？飞书审批管理员目前由谁归口？
  • 各审批节点的代理人是谁？代理范围与金额上限如何定？
  • P0 2 小时、P1 1 个工作日的超时转交时限是否可行？
  • 是否要求所有管理层开启飞书消息通知并承诺工作时间内响应时限？
  • 紧急联络表存放位置与可见权限如何设定？
GEN-06节假日前工作安排与值班待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：连续 3 天及以上假期（春节、五一、国庆等）前，研发、产品、客户支持需要规划节前任务、决定发版冻结、安排值班与应急联络时启动
  • 负责人：主责——产品总监/迭代负责人（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、各值班责任人、客服/客户反馈对接人（当前：待指定）、人事（放假通知，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 假期前 3 周启动节前规划 → ② 迭代不跨假期、定发版冻结日 → ③ 排研发值班与反馈值班 → ④ 定客户升级兜底人与应急联络 → ⑤ 发布值班表 → ⑥ 假期值守与记录 → ⑦ 节后交接复盘
  • 交付结果：节前任务清单、发版冻结通知、假期值班表（研发+客户反馈）、应急联络与升级路径、节后值班记录与复盘
  • 状态依据：2026-09 国庆 13 天长假前由 CTO 临时提出“提前规划任务与紧急问题方案”，迭代是否跨假期临时讨论；假期前 1 天才发布反馈值班表，客户升级问题谁兜底不清，无成文冻结规则与值班 SOP

1. 场景判定

  • 触发条件：距离 3 天及以上法定假期不足 3 周；假期内有客户在用的线上服务、私有化交付或活动；假期前有计划中的发版
  • 典型说法：「得提前规划好节前和节后的任务安排以及紧急问题处理方案」「迭代不要跨假期」「假期反馈值班表，请责任人当天保持微信飞书畅通」「不想假期一直接 oncall」
  • 判断问题：假期里出问题，客户找谁、谁能修、谁能拍板？如果答不上来，就走本流程
  • 不归本流程管：放假调休通知与考勤 → 请走 HR-13；下班/长假离岗断电锁门 → 请走 ADM-10；正式版本发布本身 → 请走 RND-51；售后日常排班 → 请走 X-CS-01；线上故障处理 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
节前规划主责 组织节前规划、定冻结日、发布值班表 R 产品总监/迭代负责人（当前：杨萌·推断待确认）
研发负责人 排研发值班、确认可修复范围与回滚方案 R Leap 研发负责人（当前：王皓南·推断待确认）
兜底决策 批准冻结例外、假期重大事件拍板 A CTO（当前：丁震宇·推断待确认）
反馈值班人 假期内接收客户反馈、分级、通知研发 R 客户反馈对接人（当前：待指定）
研发值班人 响应 P0/P1 问题 R 研发值班工程师（按值班表）
人事 发布放假通知，核对值班调休 C 人事（当前：待指定）
全员 知悉值班安排 I 全员

3. 办之前请准备

  • 假期日历与调休安排（来自人事放假通知）
  • 当前迭代计划、未完成工单、计划发版清单
  • 在线服务与客户清单：哪些客户假期内在用、合同约定的响应时限
  • 研发排班表、上一次假期值班记录与问题
  • 应急联络方式（存于值班表，仅内部可见）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 启动节前规划：列出假期前必须完成/可延后的任务与发版计划 节前规划主责 假期前 15 个工作日 飞书文档/工单 节前任务清单 🔧飞书固化
2 调整迭代使其不跨假期；确定发版冻结日（建议假期前 3 个工作日），冻结后只允许 Hotfix 主责+研发负责人 假期前 10 个工作日 迭代计划 冻结日通知 👤人工判断
3 排研发值班（按产品线）与客户反馈值班，每天至少 1 名主值班+1 名备份 研发负责人、主责 假期前 7 个工作日 飞书值班日历/多维表格 值班表草稿 🔧飞书固化
4 明确客户升级路径：反馈值班人分级 → 研发值班人处理 → 兜底决策人；写明 P0/P1 响应时限 主责 假期前 7 个工作日 值班表 升级路径 👤人工判断
5 冻结前完成更新检测与回滚验证，确认假期内无计划发版 研发负责人 冻结日前 发布清单 冻结确认 🔧+🤖
6 发布值班表与升级路径，同步客户支持与销售，必要时对重点客户发假期服务说明 主责 假期前 3 个工作日 通知群、飞书日历 值班通知 🔧飞书固化
7 假期内值班人保持飞书可达，按时限响应；每日在值班群记录事件（无事件写“无”） 值班人 每天 20:00 前记录 值班群、多维表格 值班日志 🔧+🤖
8 节后第 1 个工作日交接未结事件，复盘值班问题，更新本 SOP 与模板 主责 节后 2 个工作日内 飞书文档 节后复盘 👤人工判断

5. 交付物与模板

  • 交付物：节前任务清单、冻结通知、值班表、升级路径、值班日志、节后复盘
  • 建议模板/表单：
    • 值班表：日期、产品线、主值班、备份、反馈值班、兜底人、联络方式、可远程处理范围
    • 值班日志：时间、来源（客户/告警）、问题描述、等级、处理人、处理结果、是否需节后跟进
    • 节前清单：任务、负责人、必须节前完成（是/否）、状态、节后计划

6. 异常与升级

  • 假期内 P0（客户无法使用、资金/数据风险）→ 研发值班人 30 分钟内响应 → 1 小时内无法控制升级兜底决策人
  • 冻结期内必须发版 → 研发负责人提出 → CTO 批准后按 Hotfix 流程执行（RND-54）
  • 值班人临时不可达 → 备份顶上 → 主责调整当日值班并在值班群公告
  • 节前任务无法按期完成 → 主责在假期前 5 个工作日评估是否延后，并告知受影响客户/部门

7. 衡量指标

  • 值班表提前量 = 值班表发布到假期开始的工作日数，目标 ≥ 3 个工作日
  • 假期 P0 响应时长 = 客户反馈到值班人首次响应的分钟数，目标 ≤ 30 分钟
  • 冻结违规次数 = 冻结期内未经批准的发版数，目标 0
  • 值班日志完整率 = 有日志的值班日 / 值班日总数，目标 100%

8. 低效诊断

  • 现象：13 天长假前约 3 周才由管理层提出要规划任务与应急方案，迭代是否跨假期临时讨论｜依据：「Leap产研决策部」2026-09
  • 现象：假期反馈值班表在假期前 1 天才发布，客户升级问题由谁兜底不清｜依据：「Leap产研测」2026-09
  • 现象：缺少节前冻结与更新检测，研发担心假期内持续被拉 oncall｜依据：「Leap产研测」2026-09

9. 分支变体

  • 研发值班：按产品线（LeapCore/LeapAll/鼎慧/跃竞）分别排班，处理线上故障
  • 客户反馈值班：接收客户群与工单反馈，负责分级与通知，不要求修复
  • 私有化交付客户：假期前确认现场设备与远程通道可用，必要时提前告知客户值班联系人
  • 短假（≤2 天周末）：不启动本流程，按日常值班

10. 待确认问题

  • 主责是产品总监还是研发负责人？是否每个产品线各自负责？
  • 冻结日“假期前 3 个工作日”是否可行？
  • 客户反馈值班由客服、销售还是产品承担？
  • 值班是否给予调休或补贴？由人事按 HR-12 执行吗？
  • P0/P1 假期响应时限是否与合同约定一致？
GEN-07内部分享会与学习活动组织待优化48

状态：待优化｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频4 × 耗2 × 跨3 × 险2

  • 适用场景：组织周五例行分享、AI 总动员讲座、全员培训日、销售研讨会、英语等学习小组，或公司承办/参加有保密要求的分享活动时启动
  • 负责人：主责——学习委员（当前：杨萌·推断待确认）；协同——学习委员（当前：陈梦琪·推断待确认）、各组小组学委（当前：宋祺睿、胡橙橙等·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、会务/卫生委员（当前：侯明月、赵雪冰·推断待确认）、活动助理（当前：杨黔昆·推断待确认）、主持人（当前：闫登辉·推断待确认）、审稿人（当前：丁震宇·推断待确认）；发起与激励——CEO（当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 议题征集与认领 → ② 排期与确认内/外部类型 → ③ 场地与日程发布 → ④ 讲稿/材料审阅 → ⑤ 保密与录制规则确认 → ⑥ 举办与录屏 → ⑦ 资料入库与积分登记
  • 交付结果：分享排期表、飞书日程与通知、审定讲稿/PPT、录屏与 AI 摘要、知识库分享归档、积分/激励登记
  • 状态依据：2026-04 已推出委员制度与学委群，讲座有固定通知格式；但 01～06 月分享人临时指定、“没想好讲什么”、内部/外部分享记混、每次手写通知且无法直接建日程、激励细则未发布，约 30 次

1. 场景判定

  • 触发条件：每周例行分享时间临近；管理层提出要办内部/外部分享或全员培训日；学习小组固定活动；大会/年会需要内部项目分享稿；有外部人员参与且涉及未公开内容
  • 典型说法：「这周五分享一下」「下周内部的分享，想好了吗」「怎么不能直接创建日程」「一个人十分钟」「大家保密，勿外传」
  • 判断问题：这是以学习/知识传递为目的的活动吗？是否需要讲者、听众和场地？
  • 不归本流程管：新人入职培训 → 请走 HR-06；面向客户/生态的对外活动与会务 → 请走 ECO-01（生态活动年度规划与 ROI 取舍）/ ECO-16（生态大会立项与总体筹备）；技术专项分享与工具推广 → 请走 RND-87；团建与文体娱乐 → 请走 GEN-08；会议室预约规则 → 请走 ADM-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
学习委员 维护排期表、确认讲者与议题、发布通知 R 学习委员（当前：杨萌·推断待确认）
学习委员（生态侧） 协同组织全员讲座与外部分享 R 学习委员（当前：陈梦琪·推断待确认）
小组学委 收集组内议题、推荐讲者 C 小组学委（当前：宋祺睿、胡橙橙等·推断待确认）
活动助理 场地、日程、餐食申请 R 活动助理（当前：杨黔昆·推断待确认）
主持人 现场主持、控时 R 主持人（当前：闫登辉·推断待确认）
讲者 准备材料、按时提交审阅 R 当期讲者
审稿人 重要分享稿审阅（对外口径、内容真实性） C 审稿人（当前：丁震宇·推断待确认）
发起与激励 定方向、批经费、确定激励标准 A CEO（当前：邴龙志·推断待确认）
全员 参加、反馈 I 全员

3. 办之前请准备

  • 分享排期表（多维表格）与议题征集表
  • 场地或飞书会议、投屏与录屏设备
  • 讲者材料（PPT/讲稿/示例文件），对外内容需审稿
  • 保密等级判断：公开 / 内部 / 保密（不录音录像）
  • 餐食或经费需要时的申请单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 每月底在排期表征集下月议题，小组学委推荐，讲者认领日期 学习委员、小组学委 每月最后一周 飞书多维表格 下月排期 🔧飞书固化
2 管理层临时提出分享：学习委员 1 个工作日内登记，明确“内部/外部”、讲者、主题、日期 学习委员 提出后 1 个工作日内 排期表 确认条目 👤人工判断
3 排期表自动生成飞书日程（主讲、场地、会议链接），提前通知并提醒带电脑等要求 活动助理 分享前 3 个工作日 飞书日程、机器人 日程与通知 🔧+🤖
4 讲者提交材料；大会/年会/对外分享稿交审稿人审阅，可用 AI 润色，口径人工确认 讲者、审稿人 分享前 2 个工作日交稿，审稿 1 个工作日内 飞书文档评论 定稿材料 🤖+👤
5 确定保密等级：保密级在通知写明“不录音录像、不外传”，线下可统一寄存设备；内部级妙记仅限内部权限 学习委员 发通知时 通知模板 保密说明 👤人工判断
6 需管饭或经费：按活动经费申请 活动助理 分享前 3 个工作日 飞书审批 经费审批 🔧飞书固化
7 举办：主持人控时（全员培训日每人约 10 分钟），开启录屏（保密级除外） 主持人 当天 飞书会议 录屏 🔧飞书固化
8 会后录屏转 AI 摘要，材料与摘要入知识库“内部分享”目录，按权限设可见范围 学习委员 会后 2 个工作日内 飞书妙记、知识库 分享归档 🤖自动化
9 在排期表登记讲者与参与情况，按积分制度申报激励 学习委员 每月 5 日前 多维表格、积分系统 积分申报 🔧飞书固化

5. 交付物与模板

  • 交付物：分享排期表、日程通知、定稿材料、录屏与摘要、知识库归档、积分登记
  • 建议模板/表单：
    • 分享排期表：日期、类型（周五分享/讲座/培训日/外部分享/小组活动）、内部或外部、主题、讲者、主持人、场地/链接、保密等级、材料链接、录屏链接、参与人数、状态
    • 议题征集表：提议人、主题、建议讲者、目标听众、预计时长
    • 委员名册：委员类型（学习/卫生/文体/小组学委）、所属组、任期、职责

6. 异常与升级

  • 分享前 3 个工作日讲者仍未确认 → 学习委员找备选讲者或改为自由讨论 → 告知发起人
  • 讲者材料未按时提交 → 提醒一次，前 1 天仍未提交则延期一周
  • 保密内容被外传或妙记被转发 → 立即收回权限 → 升级 CEO（当天）
  • 场地冲突 → 改线上或调时间，按 ADM-05 处理

7. 衡量指标

  • 排期落实率 = 按计划举办的分享数 / 排期分享数，目标 ≥ 90%
  • 通知提前量 = 通知发布到分享开始的工作日数，目标 ≥ 3 个工作日
  • 归档率 = 2 个工作日内入知识库的分享数 / 举办分享数，目标 100%（保密级除外）
  • 参与率 = 实际参与人数 / 目标听众人数，目标 ≥ 70%

8. 低效诊断

  • 现象：多次提到“周五分享”但无人落实，讲者临时指定、事先没想好讲什么｜依据：「鼎慧产研决策部」2026-01
  • 现象：管理层口头布置分享，内部/外部分享被记混，被问才想起｜依据：「鼎慧产研决策部」2026-03
  • 现象：分享安排依赖口头找人协调，活动时间多次改动｜依据：「鼎慧产研决策部」2026-05
  • 现象：每次讲座手写场地通知，部分成员无法直接创建日程｜依据：「模态集团（全员群）」2026-04
  • 现象：委员制度已宣布，但激励细则未按期发布，委员变更靠群内宣布｜依据：「模态跃迁通知群」2026-04、「模态学委群」2026-06
  • 现象：保密分享一边要求不外传、一边逐个发送录像，无统一发放规则｜依据：「奇绩校友飞书群」2026-01、2026-04
  • 现象：个人阅读输出督导中，机器人反复催办“观点与转述”仍未完成，输出未沉淀｜依据：「学习输出」2026-09

9. 分支变体

  • 周五例行分享（研发内部）：每周固定时间，排期表认领
  • AI 总动员系列讲座、销售研讨会：全员群发布，设主持人，线上线下同步
  • 全员培训日：各负责人每人约 10 分钟，讲稿可 AI 辅助，提前 2 个工作日交稿
  • 学习小组（英语、桌游等兴趣组）：固定时间，小组长自行组织，只登记不审稿
  • 大会/年会项目分享稿：必须审稿
  • 保密类分享（外部社区或校友活动）：不录音录像，妙记按权限管控而非私发
  • 个人阅读输出群：机器人摘要+催办，输出需沉淀到文档并与产品评审挂钩

10. 待确认问题

  • 学习委员中谁为本流程唯一主责？与 HR-23（内部培训与分享会组织）如何分工？
  • 委员激励细则（积分/绩效）何时发布？
  • 分享经费（餐食）审批人与额度？
  • 保密等级由谁判定？外部社区活动的妙记是否允许内部转发？
  • 是否需要固定每周分享时段（如周五下午）？
GEN-08团建与内部文体活动组织待优化36

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨3 × 险2

  • 适用场景：公司或团队组织聚餐、团建、趣味比赛、节日快闪，或员工自发组织 KTV、奶茶、桌游等活动，需要通知、报名、费用与奖品安排时启动
  • 负责人：主责——行政（当前：侯明月·推断待确认）；协同——文体委员（当前：王皓南·推断待确认）、活动发起人（当前：杨萌、张东郅等·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务（当前：待指定）；经费审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 发起与立项 → ② 预算申请 → ③ 投票/报名 → ④ 确认人数后预订 → ⑤ 通知与提醒 → ⑥ 执行（采购/奖品） → ⑦ 报销结算与登记
  • 交付结果：活动报名/投票结果、已审批预算、预订与采购记录、活动通知、费用报销单与活动登记
  • 状态依据：聚餐类已稳定使用飞书投票（2026-01～02 约 8 次）；2026-04 宣布有专项经费，但无预算申请流程；2026-03 趣味比赛用机器人私聊全员失败、奖品临时指定；团建出现未统计时间就预订、奶茶重复下单等返工

1. 场景判定

  • 触发条件：团队聚餐、团建、趣味比赛、节日活动、员工兴趣活动需要多人参与或使用公司经费
  • 典型说法：「确认打勾，没问题就预约了」「速投速点，两点半截止」「所有人必须参赛，请准备奖品」「我们将会有专项经费支持大家学习、娱乐和团建」
  • 判断问题：这次活动是否需要报名统计、使用公司经费或通知全员？任一为是，就走本流程
  • 不归本流程管：全员年会 → 请走 ADM-21；大型团建（含保险、交通、生日会、周年庆）的行政执行细则 → 请走 ADM-20；节日福利物资发放 → 请走 ADM-18；委员与兴趣小组制度 → 请走 HR-24；学习分享活动 → 请走 GEN-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动发起人 提出方案、发投票/报名、现场组织 R 活动发起人（当前：杨萌、张东郅等·推断待确认）
文体委员 统筹全员文体活动、协助发起人 R 文体委员（当前：王皓南·推断待确认）
行政 预算申请、统一采购、预订、奖品、发放 R 行政（当前：侯明月·推断待确认）
经费审批 审批专项经费 A CEO（当前：邴龙志·推断待确认）
财务 报销结算、费用归集 C 财务（当前：待指定）
子公司负责人 子公司活动适用与对接 C 子公司负责人（当前：徐莉·推断待确认）
参与者 投票、报名、按时到场 I 全员

3. 办之前请准备

  • 活动方案：目的、时间候选、地点候选、人数估计、预算估计、是否全员必须参加
  • 报名/投票模板（飞书投票或多维表格）
  • 本季度专项经费余额与报销口径
  • 奖品/采购清单（如有）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起人填写活动方案，使用公司经费的提交预算申请 活动发起人 活动前 5 个工作日（小型自发活动前 1 个工作日） 飞书审批“活动经费” 预算审批单 🔧飞书固化
2 经费审批 经费审批人 提交后 2 个工作日内 飞书审批 审批结果 👤人工判断
3 发投票/报名，写明时间、地点候选与截止时间；全员活动在通知群发布并 @所有人，不使用机器人逐个私聊 发起人/文体委员 审批通过当天 飞书投票、多维表格 报名结果 🔧飞书固化
4 报名截止后统计人数与时间，确认后再预订场地/餐厅/车辆 行政 截止后 1 个工作日内 多维表格 预订记录 👤人工判断
5 统一采购（奶茶、食材、奖品），按报名名单下单，避免重复 行政 活动前 1 个工作日（即时类当天截单后 30 分钟内） 采购平台 采购订单 🔧+🤖
6 活动前提醒（时间、地点、带什么），机器人在群内 @报名者 机器人/发起人 活动前 1 天及开始前 1 小时 群机器人 提醒消息 🤖自动化
7 执行活动，奖品按规则发放并登记 发起人、行政 当天 奖品发放表 发放记录 👤人工判断
8 收集发票报销，登记活动台账（人数、费用、满意度） 行政 活动后 5 个工作日内 飞书报销、多维表格 报销单、活动台账 🔧飞书固化

5. 交付物与模板

  • 交付物：预算审批单、报名结果、预订与采购记录、活动通知、奖品发放记录、报销单、活动台账
  • 建议模板/表单：
    • 活动方案/经费申请：活动名称、类型（聚餐/团建/比赛/节日/兴趣）、发起人、时间、地点、预计人数、人均预算、总预算、经费来源、是否全员
    • 报名表：姓名、部门、可参加时间、饮食禁忌、是否需交通
    • 活动台账：日期、类型、参与人数、实际费用、经费来源、满意度、备注

6. 异常与升级

  • 报名人数不足方案的 50% → 发起人改期或取消，1 个工作日内通知 → 已预订的由行政处理退订
  • 实际费用超预算 10% 以上 → 行政先暂停追加 → 升级经费审批人（当天）
  • 重复下单或错单 → 行政核对名单后退换，记录原因
  • 活动中出现安全或健康问题 → 发起人立即处理并通知行政 → 升级综合部负责人（当天）

7. 衡量指标

  • 预算前置率 = 活动前完成审批的经费活动数 / 使用经费活动数，目标 100%
  • 预订返工次数 = 因未统计人数/时间导致改订的次数，目标每季度 0
  • 报名准时率 = 截止前完成报名的人数 / 参与人数，目标 ≥ 90%
  • 报销周期 = 活动结束到报销提交的工作日数，目标 ≤ 5 个工作日

8. 低效诊断

  • 现象：聚餐时间地点需多轮投票确认，提醒靠人工｜依据：「鸽子群模态分群」2026-01、2026-02
  • 现象：趣味比赛通知尝试由机器人私聊全员失败，改为群内 @所有人，奖品负责人与预算临时指定｜依据：「随便瞎聊啦～」2026-03
  • 现象：团建未先统计时间日期就统一预订｜依据：「鼎慧产研决策部」2026-04
  • 现象：自发活动投票后统一购买时出现重复下单，专项经费已宣布但无预算申请流程｜依据：「模态集团（全员群）」2026-01、2026-04

9. 分支变体

  • 公司组织（年前聚餐、趣味比赛、节日快闪）：走经费审批，行政统一采购
  • 员工自发（KTV、奶茶、桌游、居合等）：不用公司经费的只需投票报名；使用专项经费的走步骤 1～2
  • 子公司（跃竞）：按子公司预算执行，参照集团做法，由子公司负责人确认
  • 对外联合活动：涉及外部单位时同步行政与对接部门

10. 待确认问题

  • 主责是行政还是文体委员？与 ADM-20、HR-24 如何划分？
  • 专项经费的额度、审批人、按季度还是按次核定？
  • 员工自发活动在什么条件下可用公司经费？
  • 活动前 5 个工作日提交预算是否可行？小型即时活动是否简化？
  • 子公司是否共享集团团建经费？
GEN-09AI 工具订阅开通与使用补贴管理待优化108

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：公司统一采购的 AI 订阅（如 SoruxGPT 套餐）开通、升级或月度换 CDK，以及公司要求员工使用自有 AI 产品（LeapAll/LeapCore）而需要发补贴、统计充值、调整补贴规则时启动
  • 负责人：主责——AI 工具与补贴管理专员（当前：侯明月·推断待确认）；协同——产品总监/内部使用规则发布人（当前：杨萌·推断待确认）、LeapAll 服务端后台数据（当前：邓乾·推断待确认）、创始人兼 CTO（套餐选型与研发补贴试点，当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 采购/规则确定 → ② 开通名单登记与核对 → ③ 全员通知 → ④ 月度 CDK/补贴发放 → ⑤ 次日充值与使用统计 → ⑥ 月末核对与补贴扣减 → ⑦ 超额报销/额度调整 → ⑧ 季度复盘规则
  • 交付结果：AI 工具开通名单与套餐台账、每月 CDK 分发与激活记录、月度充值/使用统计表、补贴扣减与超额报销清单、成文的补贴规则（含试点细则）
  • 状态依据：已有月度 CDK 固定群发、LeapAll 内部使用规则公告和产研额度申请 SOP（飞书表单），但 2026-01～10 群内反复出现“权限开没开”“每月要不要重新兑换”“消费券能否重复领”等追问约 12 次，套餐升级无人通知，使用记录与额度统计仍靠人工，研发补贴调整只有口头宣布

1. 场景判定

  • 触发条件：公司新采购或升级共享 AI 订阅；每月 CDK/补贴发放日；员工反映“没有节点/没权限”；管理层调整补贴规则或开展补贴试点；月度充值统计发现未达标或消费异常偏高
  • 典型说法：「大家可以看看自己的开没开权限」「每个月都要重新兑换一下吗」「未完成当月充值，将取消下月 AI 补贴」「强制写使用记录，后面汇总一下」「用不完 AI 补贴就扣补贴」
  • 判断问题：这件事是不是“公司统一提供的 AI 工具/补贴，在员工侧开通、发放、统计或规则调整”？如果是新买一种工具或个人单独申请一个账号，不走本流程
  • 不归本流程管：新购 AI 订阅或第三方服务的采购审批 → 请走 FIN-02；补贴按档位核定与随工资发放 → 请走 HR-17 / FIN-10；内部余额月度充值的具体操作核对 → 请走 OPS-06；研发编码工具号池、中转渠道与防封 → 请走 X-SEC-14 / RND-26；产研测试额度、客户赠送额度 → 请走 FIN-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
AI 工具与补贴管理专员 维护开通名单与台账、发 CDK、汇总月度统计、对接供应商对账 R AI 工具与补贴管理专员（当前：侯明月·推断待确认）
内部使用规则发布人 起草/发布自有产品内部使用与补贴规则，答疑 R 产品总监（当前：杨萌·推断待确认）
后台数据提供人 发放日次日导出充值与消费数据、生成未充值名单 R LeapAll 服务端（当前：邓乾·推断待确认）
套餐与研发补贴决策 选套餐/升级、研发补贴试点方案 C 创始人兼 CTO（当前：丁震宇·推断待确认）
财务 供应商付款、超额部分报销审核、补贴扣减入账 C 财务（当前：待指定）
最终决策 补贴标准、取消/上调补贴、试点扩大 A CEO（当前：邴龙志·推断待确认）
全体员工 激活 CDK、按规则充值、填写使用记录 I 全体员工

3. 办之前请准备

  • 已签约订阅的套餐内容（席位数、节点数、有效期、续费日）与供应商对接人
  • 当前在职员工名单与应开通人员清单（含新入职、离职变动）
  • 本月 CDK 码清单或补贴发放名单
  • 现行补贴规则文本（最低充值额度、独立内部额度、超额报销口径、消费券使用限制）
  • 上月充值/使用统计与未达标名单
  • 产研测试额度申请入口（LeapAll 充值申请飞书表单）链接

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 采购或升级完成后登记套餐、节点、席位、有效期、开通人员 AI 工具与补贴管理专员 付款后 1 个工作日内 多维表格“AI 工具台账” 台账记录 🔧飞书固化
2 向供应商核对实际开通名单，与应开通名单比对，差异当天反馈供应商 AI 工具与补贴管理专员 登记后 2 个工作日内 多维表格 开通核对表 🤖自动化
3 在固定的 AI 工具群发开通/升级通知：变化内容、自查方式、问题表单入口（不收私聊） AI 工具与补贴管理专员 核对完成当天 飞书群 + 问题收集表单 群通知 🔧飞书固化
4 每月固定日推送 CDK/补贴到账通知，附激活步骤和截止日 机器人（专员维护） 每月发放日当天 飞书机器人定时消息 CDK 分发记录 🔧+🤖
5 导出充值与消费数据，生成未激活/未充值名单并推卡片提醒本人 后台数据提供人 发放日次日 12:00 前 产品后台 + 飞书卡片 未充值名单 🤖自动化
6 月末核对充值与使用记录，确定补贴取消/扣减名单，报 HR 与财务 AI 工具与补贴管理专员 每月最后 1 个工作日 多维表格 月度统计表、扣减清单 🤖+👤
7 超出额度部分凭发票走报销审批；产研测试额度走飞书表单申请 申请人 → 财务 次月 10 日前提交 飞书审批 / 表单 报销单、额度申请 🔧飞书固化
8 汇总供应商用量并对账付款；不用的账号列入关停清单 AI 工具与补贴管理专员 每月 5 日前 多维表格 + 对账单 对账记录、关停清单 🤖+👤
9 季度复盘：人均使用、成本、使用场景记录，提出补贴调整建议；试点方案写成细则后发布 规则发布人 + CTO 每季度首月 10 日前 飞书文档 复盘报告、补贴细则 👤人工判断

5. 交付物与模板

  • 交付物：AI 工具台账、月度 CDK 分发与激活记录、月度充值/使用统计表、补贴扣减清单、补贴规则与试点细则
  • 建议模板/表单：
    • AI 工具台账字段：工具名称、供应商、套餐/节点、席位数、开通人员、开通日期、续费日、月费用归属主体、负责人、状态（在用/待关停）
    • 月度统计字段：员工、部门、CDK 是否激活、自有产品充值是否达标、使用场景记录链接、超额金额是否报销、补贴结论（照发/取消/扣减）
    • 补贴细则字段：适用对象（按人/按项目组）、额度口径、是否含海外订阅、发放方式、取消条件、超额报销条件、试点期限与评估指标

6. 异常与升级

  • 员工反映没有节点/没权限 → 专员 1 个工作日内向供应商核实并回复 → 3 个工作日未解决升级 CTO
  • 供应商升级套餐未通知 → 专员收到信息当天发群通知并更新台账 → 涉及费用变化同时告知财务
  • 充值或消费明显超出预期（成本偏高） → 专员月末标记异常人员与场景 → 3 个工作日内报 CEO 决定是否调整补贴
  • 未充值导致补贴取消引起争议 → 规则发布人复核后台记录 → 2 个工作日内给出结论，仍有争议升级 CEO
  • 试点补贴口径不明 → 先暂停扩大发放 → CTO 5 个工作日内补细则并经 CEO 确认

7. 衡量指标

  • 开通准确率 = 实际开通名单与应开通名单一致的人数 / 应开通人数，目标 100%
  • CDK 激活率 = 发放后 3 天内激活人数 / 发放人数，目标 ≥ 95%
  • 充值达标率 = 当月按规则完成充值人数 / 应充值人数，目标 ≥ 95%
  • 群内同类追问次数 = 每月关于权限、兑换、领券的重复提问次数，目标逐月下降至 ≤ 2 次
  • 闲置订阅占比 = 当月零使用账号数 / 付费账号数，目标 ≤ 5%

8. 低效诊断

  • 现象：套餐升级、节点开通没有通知到员工，员工两周不知已升级，只能发名单让大家自查（开通核对环节）｜依据：「模态集团（全员群）」2026-01
  • 现象：开通问题靠私发给经办人收集，无表单留痕（问题收集环节）｜依据：「模态集团（全员群）」2026-01
  • 现象：每月需重新兑换 CDK，部分员工不知道，直到 5 月才固定发放群（分发环节）｜依据：「模态集团（全员群）」2026-04、「模态集团（全员群）」2026-05
  • 现象：内部产品充值消费偏高，额度谁管不清，使用记录计划提出后未执行（额度管理环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：规则发布当天即出现充值延迟；谁需买券、能否重复领券被反复询问（规则宣贯环节）｜依据：「跃迁AI总动员」2026-06
  • 现象：研发补贴扣减与上调只在群里口头宣布，按人还是按项目、是否含海外订阅未说明（规则调整环节）｜依据：「跃迁基座许愿机」2026-05、「跃迁AI总动员」2026-10

9. 分支变体

  • 外购订阅（SoruxGPT 三合一套餐等）：重点是开通名单核对、月度 CDK 与供应商对账
  • LeapAll 个人充值补贴：按规则每月充值，次日拉后台名单提醒，月末核对，未充值取消下月补贴
  • LeapCore 内部独立额度：部署后按人配置内部额度，与个人充值分开统计
  • 产研测试额度：走 LeapAll 充值申请飞书表单，由管理层审批后对接同事加额度
  • 政府消费券（武创通）抵扣：每人限用一次，需提前说明领取条件
  • 研发 AI 补贴上调试点：先由项目组试点，细则与评估指标成文后再决定是否扩大

10. 待确认问题

  • 主责是否为行政/总经办的 AI 工具与补贴管理专员？自有产品补贴的统计是否改由产品或运营负责？
  • 补贴规则的最终审批人是 CEO 还是董事会？研发补贴试点由谁出细则？
  • 最低充值额度、超额报销上限、未充值取消补贴的口径是否已有成文制度？
  • 后台“次日拉名单”是否可做成自动推送？由哪个研发岗位维护？
  • 外购订阅与研发个人号池（X-SEC-14）是否合并为一张台账？
GEN-10自研产品内部推广使用与反馈闭环待优化90

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险2

  • 适用场景：LeapCore/LeapAll 等自研产品需要在公司内部部署、发账号、安装培训并要求各职能部门真实使用和反馈时启动
  • 负责人：主责——总经办内部推广负责人（当前：赵雪冰·推断待确认）；协同——产品发布负责人（当前：杨萌·推断待确认）、IT 运维（当前：杨明学·推断待确认）、各部门负责人（当前：黄莹、黄梦婷、胡则瑾、田杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 产品发布内部使用包 → ② 账号与远程接入开通 → ③ 总经办下达部门任务 → ④ 部门建团队空间与安装试用 → ⑤ 分层培训 → ⑥ 反馈统一登记 → ⑦ 每周汇总给产品并回告 → ⑧ 月度使用复盘
  • 交付结果：各部门完成安装与团队空间创建的清单、培训签到与录屏、内部反馈登记表及每周汇总、月度内部使用情况报告
  • 状态依据：已有产品团队内部使用通知、飞连接入文档和培训会议，但 2026-06～10 推广主要靠群通知与逐人催办，同一通知多次转发，安装包版本需手动更新，内部档案以飞书还是 LeapCore 为主口径不一，约 8 次，缺反馈汇总机制

1. 场景判定

  • 触发条件：自研产品新版本可内部部署；公司要求职能部门用自研产品提效；新增内部培训（远程访问、FDE 初级、信创）；新功能需要内部试用（如接入飞书）
  • 典型说法：「支持公司自研产品，未来所有职能部门要通过自研产品实现内部提效」「请各位落实好安装、试用、反馈工作，相关事项下沉到实习生」「请各位负责人在 LeapCore 为自己部门创建团队空间」
  • 判断问题：这是不是“让公司内部员工装上、用起来自研产品并把使用反馈带回产品”？如果是研发自己的版本内测找 Bug，不走本流程
  • 不归本流程管：研发版本内测与 dogfood 问题分流 → 请走 X-PRD-06；内部培训的报名、场地、录屏 → 请走 HR-23 / X-FDE-15；飞连/VPN 开通 → 请走 X-SEC-25；安装包打包与分发链接维护 → 请走 RND-52；员工 AI 补贴与充值 → 请走 GEN-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内部推广负责人 下达部门任务、跟进进度、组织月度复盘 R/A 总经办内部推广负责人（当前：赵雪冰·推断待确认）
产品发布负责人 发布内部使用通知（安装包、账号、连接方式）、处理反馈、版本更新通知 R 产品总监（当前：杨萌·推断待确认）
IT 运维 批量开账号、飞连/远程接入、安装支持 R IT 运维（当前：杨明学·推断待确认）
部门负责人 创建部门团队空间、安排本部门安装试用、指定反馈人 R 各部门负责人（当前：黄莹、黄梦婷、胡则瑾、田杰·推断待确认）
研发负责人 拍板产品问题优先级、确认数据权限 C 创始人兼 CTO（当前：丁震宇·推断待确认）
全体员工/实习生 安装、使用、提交反馈 I 全体员工

3. 办之前请准备

  • 当前版本安装包下载地址与版本号、更新方式（是否支持自动更新）
  • 内部账号开通名单（按部门）与初始权限分层
  • 远程访问/飞连接入说明文档
  • 本期推广目标：每个部门至少要用起来的场景
  • 可上传与不可上传材料清单（非涉密才可上传；人事、薪酬、合同原件不上传）
  • 反馈登记表链接与培训日程

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布内部使用通知：安装包与版本号、账号获取方式、连接方式、反馈入口，置顶到全员必读 产品发布负责人 版本可用后 1 个工作日内 飞书群公告 + 知识库页面 内部使用通知 🔧飞书固化
2 按部门名单批量开通账号与远程接入，回填开通状态 IT 运维 通知后 2 个工作日内 管理后台 + 飞连 账号开通清单 🔧+👤
3 向部门负责人下达任务：安装、建团队空间、指定反馈人、试用场景，写明截止日 内部推广负责人 通知当天 飞书任务 部门推广任务 🔧飞书固化
4 部门负责人创建团队空间，上传非涉密材料，安排本部门（含实习生）安装试用 部门负责人 任务下达后 5 个工作日内 LeapCore 团队空间、安装完成名单 👤人工判断
5 组织分层培训（远程访问、FDE 初级、信创等），录屏入知识库 内部推广负责人 + 产品 按培训日程，录屏会后 2 个工作日内入库 飞书会议 + 知识库 签到表、录屏 🔧飞书固化
6 使用问题与需求统一填反馈表，不在群里零散发 部门反馈人 发现后当天 多维表格“内部反馈表” 反馈记录 🔧飞书固化
7 每周汇总反馈，分类（Bug/需求/咨询）转产品工单，处理结果回填并回告 产品发布负责人 每周五 18:00 前 多维表格 + 工单 周反馈汇总 🤖+👤
8 新版本发布时同步更新安装包链接与更新说明，不重复转发旧通知 产品发布负责人 发版当天 知识库页面 + 机器人 版本更新说明 🤖自动化
9 月度复盘各部门使用率、典型场景与未解决问题，报管理层 内部推广负责人 每月首个工作周内 飞书文档 月度使用报告 👤人工判断

5. 交付物与模板

  • 交付物：内部使用通知页（常驻更新）、账号开通清单、部门团队空间清单、培训签到与录屏、反馈周汇总、月度使用报告
  • 建议模板/表单：
    • 部门推广进度表字段：部门、负责人、反馈人、应安装人数、已安装人数、团队空间是否创建、已上线场景、截止日、状态
    • 内部反馈表字段：提交人部门、产品与版本号、场景、问题类型（Bug/需求/咨询/体验）、描述与截图、优先级、工单链接、处理结果、是否已回告

6. 异常与升级

  • 部门到期未完成安装/建空间 → 推广负责人提醒 1 次 → 再过 2 个工作日未完成，报 CTO 并在月度复盘中点部门
  • 安装失败或无法远程接入 → IT 运维 1 个工作日内处理 → 涉及产品缺陷转研发工单
  • 有人上传涉密材料（合同原件、人事、薪酬） → 部门负责人当天删除并通知推广负责人 → 涉及外泄风险升级 CTO
  • 反馈超过 2 周无处理结果 → 推广负责人在周汇总中标红 → 升级 CTO 定优先级
  • 档案存放口径冲突（飞书 vs LeapCore） → 以集团档案规则为准（GEN-11） → 冲突由综合部负责人裁定

7. 衡量指标

  • 安装覆盖率 = 已安装员工数 / 应安装员工数，目标 ≥ 95%
  • 部门周活跃率 = 每周至少使用 1 次的员工 / 已安装员工，目标 ≥ 70%
  • 反馈闭环率 = 已处理并回告的反馈 / 当期反馈总数，目标 ≥ 80%
  • 反馈处理周期 = 反馈提交到回告的自然日，目标中位数 ≤ 10 天
  • 重复通知次数 = 同一事项在群内转发次数，目标 ≤ 1 次

8. 低效诊断

  • 现象：推广靠群通知和负责人逐个催办，任务没有截止日和完成清单（任务下达环节）｜依据：「【模态】综合部」2026-06、「【模态】综合部」2026-07
  • 现象：同一通知（消费券、问卷）多次转发，员工找不到最新版本（通知环节）｜依据：「【模态】综合部」2026-07
  • 现象：安装包版本需手动更新，群里发压缩包传播版本（版本分发环节）｜依据：「【模态】综合部」2026-07
  • 现象：内部档案以飞书还是 LeapCore 为主没有统一说法，部门上传范围不清（数据上传环节）｜依据：「【模态】综合部」2026-07
  • 现象：要求“试用、反馈”但没有统一反馈入口和汇总，反馈难回到产品（反馈环节）｜依据：「【模态】综合部」2026-06

9. 分支变体

  • LeapCore 内部部署：重点是部门团队空间与非涉密数据上传，主要档案仍在飞书
  • LeapAll 内部使用：与补贴、充值挂钩，按 GEN-09 执行
  • FDE 初级培训：全体非研发同事须参加，缺课补课按 X-FDE-15
  • 新功能内部试用（如 LeapCore 接入飞书）：先小范围部门试点，反馈走本流程第 6～7 步
  • 消费券核销与问卷：按通知一次性完成，问卷结果由推广负责人汇总

10. 待确认问题

  • 内部推广主责在总经办还是产品团队？反馈汇总由产品还是运营负责？
  • “主要档案以飞书为主、LeapCore 只放非涉密材料”是否为正式口径？
  • 各部门的使用率目标是否纳入部门考核？
  • 安装包能否统一放在知识库固定页面并支持自动更新？
  • 内部反馈是否直接并入 X-PRD-06 的反馈表，避免两张表？
GEN-11集团档案整理与合同台账管理待优化240

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：集团需要建立或执行电子/纸质档案归档规则、组织年度/专项档案盘点，或审计、内控、尽调、领导需要查找合同、制度、资质、项目资料时启动
  • 负责人：主责——档案委员（当前：田杰、胡则瑾·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、合同整理与盖章（当前：侯明月·推断待确认）、人事/财务档案（当前：黄莹、黄梦婷·推断待确认）、各部门档案组长（当前：丁震宇、李鹏为、许君、鲁周毅、杨明学、韩诗琪、谌思铭、黄飞鹏·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 档案办法制定与审批 → ② 设档案委员与部门组长 → ③ 发前置准备通知 → ④ 排期逐部门盘点 → ⑤ 登记档案台账与合同台账 → ⑥ 纸质入档案室、电子入线上档案库 → ⑦ 权限与借阅登记 → ⑧ 月度自查、季度抽查
  • 交付结果：成文的档案管理办法、集团档案台账（一级目录）、按主体分开的合同台账、线上档案库与档案室、借阅登记、月度自查与季度抽查记录
  • 状态依据：已有档案管理办法（2026-03 审批通过）、线上档案库、合同台账模板和档案组长机制（2026-08 启动），但历史合同补录慢、清单无人持续维护，2026-10 仍有“所有签过的合同清单在哪里”的追问，档案进度靠“一天一同步”和私下汇报催办，约 10 次

1. 场景判定

  • 触发条件：新合同双方盖章完成需入库；年度档案盘点或审计、内控窗口期要求补材料；管理层或尽调要求提供合同清单、制度、资质；部门人员变动需移交档案；新设档案柜、档案室
  • 典型说法：「请各部门推选一名档案组长」「线上文档新建部门汇总文件夹，放原文件的快捷方式，不移动不删除原文件」「所有签过的合同、战协的清单在哪里」「我希望找任何东西从知识库就能找到」
  • 判断问题：这件事是不是“把公司正式文件按统一目录归档、登记、可查”？只是借用营业执照或公章，不走本流程
  • 不归本流程管：单份合同的编号发放与原件入库操作 → 请走 LEG-11；营业执照、印章、资质原件的保管调用 → 请走 ADM-23；人事档案收集与权限分级 → 请走 HR-28；项目过程文档进知识库 → 请走 GEN-12；荣誉证书汇总与对外调用 → 请走 GEN-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
档案委员 组织组长开展工作、排期盘点、维护档案台账、抽查 R 档案委员（当前：田杰、胡则瑾·推断待确认）
综合部负责人 起草/修订办法、统筹进度、裁定归属争议 A 综合部负责人（当前：赵雪冰·推断待确认）
总经办档案管理 搭建与维护线上档案库目录、权限 R 总经办档案管理（当前：董蓝汐·推断待确认）
合同管理 维护合同台账、发合同编号、收集纸质原件 R 合同整理与盖章（当前：侯明月·推断待确认）
部门档案组长 收拢本部门资料、登记清单、按时移交与自查 R 各部门档案组长（当前：丁震宇、李鹏为、许君、鲁周毅、杨明学、韩诗琪、谌思铭、黄飞鹏·推断待确认）
人事/财务档案 人事、财务档案按一级目录归集 R 人事负责人、财务负责人（当前：黄莹、黄梦婷·推断待确认）
CEO 审批档案办法、权限范围与档案室设置 A（升级） CEO（当前：邴龙志·推断待确认）
全体员工 按目录提交与借阅 I 全体员工

3. 办之前请准备

  • 现行档案管理办法与分类目录（综合档案：人事、财务、行政、法务；业务档案：运维、销售、生态、技术）
  • 线上档案库地址与各部门子文件夹权限
  • 合同台账模板（按武汉模态、湖北鼎慧、苏州模态等主体分 sheet）
  • 各部门档案组长名单与盘点排期表
  • 档案柜、档案室容量与钥匙保管人
  • 审计/内控/尽调提出的材料清单与截止日

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草或修订档案管理办法（分类、编号、保密分级、借阅、自查抽查），报 CEO 审批后发布 综合部负责人 起草 5 个工作日内，审批 3 个工作日内 飞书文档 + 审批 档案管理办法 👤人工判断
2 各部门推选档案组长，档案委员建档案整理群并公布名单 部门负责人 → 档案委员 通知后 3 个工作日内回复 飞书群 组长名单 🔧飞书固化
3 发前置准备通知：线上文档建部门汇总文件夹放快捷方式（不移动不删除原文件）；本地文件复制；纸质合同先集中保管，不必自行扫描 档案委员 组长确定后 1 个工作日内 飞书群公告 准备通知 🔧飞书固化
4 预约日程，按排期逐部门盘点，现场确认归属、缺失、版本不一致 档案委员 + 部门组长 每部门 1 个工作日，整体 8 月启动、最迟 9 月完成（年度盘点按同节奏） 飞书日程 + 排期表 盘点记录、问题清单 🔧飞书固化
5 登记档案台账（只归集一级目录，信息最小化）与合同台账；历史合同 PDF 用 AI 抽取字段补录 部门组长、合同管理 盘点后 5 个工作日内 多维表格 档案台账、合同台账 🔧+🤖
6 纸质原件入档案柜编号，电子档上传线上档案库对应目录 合同管理、档案委员 台账登记后 5 个工作日内 档案室 + 飞书云盘 归档编号、电子档 👤人工判断
7 设置权限：合同台账对董事会开放，借阅报部门负责人批准并登记 总经办档案管理 归档完成当天 飞书云盘权限 + 借阅表单 权限配置、借阅登记 🔧飞书固化
8 新增合同双方盖章后触发入库提醒，当周补登台账 合同管理 盖章后 3 个工作日内 合同审批联动机器人 新合同入库记录 🔧+🤖
9 月度自查（组长）、季度抽查（档案委员），问题清单限期整改并通报 部门组长、档案委员 每月最后 1 个工作日；每季度首月 15 日前 多维表格 自查表、抽查报告 🔧+👤

5. 交付物与模板

  • 交付物：档案管理办法、集团档案台账、合同台账（按主体分表）、线上档案库目录、档案室编号清单、借阅登记表、自查与抽查记录
  • 建议模板/表单：
    • 合同台账字段：合同编号、签约日期、合同名称、合同类型、状态、对方单位、我方主体、生效日、到期日、是否续签、存档类型（电子/纸质/两者）、原件位置、电子档链接、经办部门
    • 档案台账字段：档案编号、类别（综合/业务）、部门、一级目录名称、密级、载体（线上/本地/纸质）、存放位置或链接、责任人、最近自查日
    • 借阅登记字段：借阅人、档案编号、用途、批准人、借出日、应还日、实还日

6. 异常与升级

  • 综合部负责人为本流程唯一负责人（A）；CEO 作为 A（升级）的条件：档案管理办法发布或修订、合同台账与档案库权限范围调整、档案室设置；审计窗口期截止前 2 个工作日材料仍未齐；原件拒交或丢失；历史合同 5 个工作日内无法找回
  • 部门逾期未推选组长或未提交清单 → 档案委员提醒 1 次 → 2 个工作日后仍未完成升级综合部负责人
  • 资料归属不清、缺失或多版本 → 组长在群里登记问题 → 档案委员 3 个工作日内确认归属与有效版本，仍不清升级综合部负责人
  • 审计窗口期需补材料 → 档案委员按清单逐项分派到组长 → 截止前 2 个工作日未齐升级 CEO
  • 原件放在个人处不交 → 档案委员当天要求移交 → 拒绝或丢失报综合部负责人和 CEO
  • 历史合同找不到经办人（业务交接断档） → 合同管理向财务调付款/收款记录反查 → 5 个工作日内无结果列入缺失清单报 CEO

7. 衡量指标

  • 合同入库及时率 = 盖章后 3 个工作日内入台账的合同数 / 新签合同数，目标 ≥ 95%
  • 历史合同补录完成率 = 已入台账历史合同 / 已知历史合同，目标 100%（本年度内）
  • 查找时效 = 收到查找请求到提供文件的时间，目标 ≤ 1 个工作日
  • 抽查合格率 = 抽查合格档案数 / 抽查数，目标 ≥ 95%
  • 群内找文件次数 = 每月群里询问“XX 在哪”的次数，目标逐月下降

8. 低效诊断

  • 现象：档案办法通过后分工待调整，专利等事项“没人管”（职责分工环节）｜依据：「档案管理」2026-03
  • 现象：档案组长人选需反复催促，运维与技术组长由同一人兼任（组织环节）｜依据：「【模态】业务负责人」2026-08、「董事会专项沟通群」2026-08
  • 现象：证书原件、材料存放在个人处，需要时临时找（收拢环节）｜依据：「董事会专项沟通群」2026-08
  • 现象：线上档案库自 4 月试运行，但历史合同补录慢，10 月仍找不到全部合同与战协清单（台账维护环节）｜依据：「【模态】综合部」2026-05、「【模态】综合部」2026-10
  • 现象：进度靠“一天一同步”和私下汇报，没有看板（进度跟踪环节）｜依据：「【模态】总经办」2026-08
  • 现象：子公司业务接手人不明，过往合同追溯困难（交接环节）｜依据：「【模态】综合部」2026-05

9. 分支变体

  • 综合档案（人事、财务、行政、法务）与业务档案（运维、销售、生态、技术）分组管理
  • 人事档案、运维资产、账号档案：只归集一级目录，明细留在原系统
  • 纸质原件：集中入档案室编号，借阅登记；电子档：上传线上档案库，原文件只放快捷方式
  • 多主体合同：武汉模态、湖北鼎慧、苏州模态分 sheet 登记，后续新增主体按同样结构加表
  • 专利、证书：并入档案体系，原件与知识产权材料放在一起

10. 待确认问题

  • 档案委员是否为主责？合同台账由行政（盖章）还是法务维护？
  • 合同台账是否改为多维表格并与飞书合同审批联动自动入库？
  • 档案保密分级与借阅审批人（部门负责人还是综合部）是否已有成文规定？
  • 年度盘点固定在每年 8 月是否可行？
  • 苏州模态等子公司的历史合同由谁负责补录？
GEN-12知识库与协作文档沉淀（含飞书空间治理）待优化72

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨3 × 险2

  • 适用场景：项目或团队产生正式文档需要统一进知识库，团队需要建立协作基准与个人工作说明，在飞书以外工具（Agent）产出的文档需要回到飞书协作，或飞书多维表格工作台视图、权限混乱需要治理时启动
  • 负责人：主责——各项目/团队知识库管理员（当前：杨萌·推断待确认）；协同——团队协作基准编制人（当前：陈梦琪·推断待确认）、文档汇总维护人（当前：葛家和·推断待确认）、Agent 与共享上下文方法（当前：丁震宇·推断待确认）、全体项目成员；兜底——创始人兼 CTO
  • 核心流程：① 按模板建知识库目录 → ② 定命名与版本规则 → ③ 正式文档在知识库创建或定稿后归档 → ④ 外部 Agent 产出导入飞书再协作 → ⑤ 项目上下文文档日更 → ⑥ 工作台视图与权限按规则配置 → ⑦ 月度检查与清理
  • 交付结果：按统一目录组织的项目/团队知识库、协作基准文档（含个人说明书）、项目上下文文档、权限与视图规则清晰的工作台、月度检查记录
  • 状态依据：已有知识库分类目录、命名规范和平台部协作指南，但 2026-01～10 群里多次出现“找文档很麻烦”“谁忘迁移了”，迁移靠限期加点名催办，工作台视图被随意新增误改后才集中清理，Agent 产出如何回飞书协作没有约定

1. 场景判定

  • 触发条件：项目阶段性知识管理要求迁移文档；新文档定稿；新人入组需要填写个人说明书；有人反映“找不到文档”；多人在多维表格工作台新建视图或做实验；在 Agent 工具中产出需要他人评审的文档
  • 典型说法：「请大家把项目相关文档转移到知识库并做好分类归档」「最近感觉找文档很麻烦，经常找不到」「没有共享上下文 SOP 导致的」「你们自己的任务视图都变成私密吧」「怎么通过飞书和他人协作」
  • 判断问题：这是不是“团队日常工作文档该放哪、怎么命名、谁能改”的问题？如果是公司级合同、制度、资质的正式归档，不走本流程
  • 不归本流程管：合同、制度原件、资质等正式档案 → 请走 GEN-11；制度与 SOP 的起草发布 → 请走 GEN-01；产品使用手册维护 → 请走 X-PRD-36；销售话术与案例库 → 请走 SAL-15；人员离岗的工作交接 → 请走 RND-85；聊天渠道与群职能 → 请走 GEN-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识库管理员 建目录与规则、发迁移任务、检查与清理、工作台管理员 R/A 项目/团队知识库管理员（当前：杨萌·推断待确认）
协作基准编制人 编制团队协作基准、组织填写个人说明书 R 团队协作基准编制人（当前：陈梦琪·推断待确认）
文档汇总维护人 维护团队常用文档汇总入口页 R 文档汇总维护人（当前：葛家和·推断待确认）
方法负责人 制定共享上下文与 Agent 产出回流规则 C 创始人兼 CTO（当前：丁震宇·推断待确认）
项目成员 按规则创建、迁移、命名文档，设置个人视图 R 全体项目成员
部门负责人 知悉检查结果并督促 I 各部门负责人

3. 办之前请准备

  • 知识库目录模板：需求与产品设计、技术方案与架构、项目管理、运营资料、客户与商务、其他
  • 命名规则：日期-姓名-事项-版本
  • 团队常用文档汇总入口页链接
  • 协作基准文档模板（团队分工、个人说明书、会议与周报规则）
  • 多维表格工作台的数据表清单与当前管理员
  • 项目上下文文档模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板建项目/团队知识库目录和常用文档入口页，公布规则 知识库管理员 项目启动后 3 个工作日内 飞书知识库 目录与入口页 🔧飞书固化
2 规范性文档（方案、规范、手册）直接在知识库创建；过程性文档本地完成后定稿归档；只迁移正式版，草稿进“草稿归档”子文件夹 项目成员 定稿后 2 个工作日内 飞书知识库 已归档文档 🔧飞书固化
3 阶段性迁移：发迁移任务与截止日，完成者在进度表打勾 知识库管理员 → 项目成员 截止日一般为通知后 5 个工作日 多维表格打卡 + 机器人提醒 迁移进度表 🔧+🤖
4 新人入组 3 个工作日内填写个人说明书；团队协作流程变化当周更新协作基准 协作基准编制人、新人 入组后 3 个工作日内 飞书文档 个人说明书、协作基准 🔧飞书固化
5 每个项目一份上下文文档：完成事项、更新资料、待办，每日下班前追加 项目负责人 每个工作日 飞书文档 + AI 汇总 项目上下文文档 🤖自动化
6 Agent 工具产出文档：导出 Markdown/Word 导入飞书文档后再发起评审，评审意见只在飞书文档评论；多个 Agent 产出先互评、人工终审后合并 文档作者 需协作前完成导入 飞书文档 可协作文档、终审版 🤖+👤
7 工作台视图规则：个人视图一律私密；公共视图只由管理员建；实验不在正式表进行；按表设置编辑权限 知识库管理员 规则发布当天配置 飞书多维表格 视图与权限配置 🔧飞书固化
8 月度检查：命名、分类、未迁移文档、多余公共视图，AI 先扫一遍出问题清单，管理员确认后通知整改 知识库管理员 每月最后 1 个工作日 飞书知识库 + AI 检查 检查清单 🤖+👤

5. 交付物与模板

  • 交付物：项目/团队知识库、常用文档入口页、协作基准文档与个人说明书、项目上下文文档、工作台权限视图配置、月度检查清单
  • 建议模板/表单：
    • 迁移进度表字段：成员、负责文档、目标目录、是否完成、完成日期、备注
    • 项目上下文文档字段：日期、完成事项、更新资料链接、决策记录、待办与负责人、阻塞点
    • 月度检查清单字段：文档链接、问题类型（命名/分类/重复/草稿未归档/视图冗余）、责任人、整改截止日、状态

6. 异常与升级

  • 迁移截止后仍有未完成 → 管理员在进度表标出并单独提醒 1 次 → 再过 2 个工作日未完成，报项目负责人
  • 工作台视图或数据被误改、误删 → 管理员当天用历史版本恢复 → 确认原因后收回编辑权限，涉及客户数据报 CTO
  • 同一文档多处存放、版本冲突 → 以知识库版本为准，其余改为链接 → 作者 1 个工作日内合并
  • Agent 产出的数据或案例像营销口径、无法核实 → 人工终审时删除或标“待核实” → 对外使用前转 BRD-14 合规自查
  • 协作基准长期无人维护 → 管理员每季度提醒编制人更新 → 无人承接报部门负责人

7. 衡量指标

  • 文档归档率 = 已在知识库正式目录的定稿文档 / 应归档文档，目标 ≥ 95%
  • 迁移按期完成率 = 截止日前完成迁移的成员 / 应迁移成员，目标 100%
  • 找文档提问次数 = 每月群内“XX 文档在哪”提问次数，目标逐月下降
  • 个人说明书完成率 = 已填写成员 / 团队成员，目标 100%
  • 工作台公共视图数 = 管理员维护的公共视图数量，目标每张表 ≤ 5 个

8. 低效诊断

  • 现象：文档分散在群文件、个人空间，成员反映经常找不到（存放环节）｜依据：「平台部」2026-01
  • 现象：协作基准和个人说明书多次要求补填（填写环节）｜依据：「平台部」2026-04
  • 现象：迁移到期后仍有人遗忘，需在群里点名追问（迁移执行环节）｜依据：「字字可研项目群」2026-04
  • 现象：同类文档散落多处，需提醒“收进知识库以后好找”（归档环节）｜依据：「字字可研项目群」2026-06
  • 现象：管理者的上下文散在口头和微信中，AI 助手和同事都无法接手（上下文沉淀环节）｜依据：「鼎慧产研决策部」2026-07
  • 现象：工作台视图过多、被误改、客户表与任务表混用，混乱后才集中清理（权限治理环节）｜依据：「工程咨询产研」2026-04
  • 现象：Agent 工具产出的文档难以在飞书多人协作，飞书 CLI 体验差（工具衔接环节）｜依据：「跃迁AI总动员」2026-10

9. 分支变体

  • 项目文档（如字字可研）：按六类目录迁移，只迁正式版
  • 平台部/教育组：以“常用文档汇总”入口页 + 协作指南为核心
  • 个人/管理者上下文：每个 AI 助手只负责一个项目，产出统一写入项目上下文文档
  • 多 Agent 并行写文档：各自产出 → 互评 → 人工终审合并，开启 @提及 设置避免混乱
  • 多维表格工作台：管理员统一建公共视图，个人视图私密

10. 待确认问题

  • 公司知识库主平台是飞书知识库还是 infinitext 知识库？两者如何分工？
  • 每个项目的知识库管理员是否默认为项目负责人？
  • “日期-姓名-事项-版本”命名规则是否推广到全公司？
  • Agent 产出导入飞书的标准方式由研发统一提供工具还是各自处理？
  • 工作台是否需要由 IT 统一配置权限模板？
GEN-13荣誉资质、宣传素材与对外信息口径库待新建108

状态：待新建｜证据：有证据（卡片 2 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：对外申报、媒体拍摄、峰会演讲、外部活动或路演表单需要用到公司荣誉资质、标准公司/产品介绍或公司基本信息（主体、融资阶段、核心数据）时，从统一的库里取用；库内容新增或变化时更新
  • 负责人：主责——总经办素材与口径库管理员（当前：田杰·推断待确认）；协同——总经办档案管理（当前：董蓝汐·推断待确认）、产品总监（当前：杨萌·推断待确认）、生态市场负责人（当前：许君·推断待确认）、CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）；口径终审——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 建库分类与维护人 → ② 收集最新素材 → ③ 定标准介绍与口径页 → ④ CEO 审定 → ⑤ 按需取用 → ⑥ 外部表单按口径填报 → ⑦ 新荣誉/新版本即时入库 → ⑧ 季度复核
  • 交付结果：分类清晰、有维护人和版本号的素材与口径库（荣誉资质、公司介绍、产品介绍、行业版、案例、视频），公司对外信息口径页，外部表单填报记录
  • 状态依据：已有荣誉资料汇总文档和“做 PPT 专用群”，但素材靠群文件堆叠，无分类、版本和负责人，2026-04～09 出现反复重做 PPT、对外提供奖项时手里材料不全、同一产品能力说法不一、外部表单融资阶段随意填写等情况约 10 次

1. 场景判定

  • 触发条件：申报、媒体、峰会、客户需要公司介绍或荣誉材料；收到外部活动/路演表单需填融资阶段、规模等信息；获得新荣誉、证书、认证；产品介绍或核心数据更新
  • 典型说法：「形成一套统一的对外标准公司介绍和产品介绍，以及适配不同场景的组合素材库」「不要反反复复重新做 PPT」「第一次看到这个说法，之前不是另一种说法吗」「填表没？融资阶段填什么？」
  • 判断问题：这是不是“对外要说公司是谁、有什么荣誉、产品是什么”的标准信息？如果是做一份新的演讲 PPT 或产品图片视频，不走本流程
  • 不归本流程管：演讲/布道 PPT 制作与评审 → 请走 MKT-09；产品图、渲染图、视频等品牌素材 → 请走 BRD-17；品牌用语与发布前合规自查 → 请走 BRD-14；媒体采访接待 → 请走 BRD-12；申报所需人员、社保等基础资料 → 请走 POL-03；证书原件保管 → 请走 ADM-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
素材与口径库管理员 建库、收集、版本管理、答复取用、季度复核 R 总经办素材与口径库管理员（当前：田杰·推断待确认）
荣誉资质归档 新证书、奖项扫描入库，原件交档案 R 总经办档案管理（当前：董蓝汐·推断待确认）
产品口径提供 提供产品介绍、能力数字、行业版说明 C 产品总监（当前：杨萌·推断待确认）、CTO（当前：丁震宇·推断待确认）
市场口径提供 提供生态、案例、活动素材 C 生态市场负责人（当前：许君·推断待确认）
对外敏感信息口径 融资阶段、营收、客户数等对外说法 C COO（当前：常元和·推断待确认）
口径终审 审定标准介绍与对外口径页 A CEO（当前：邴龙志·推断待确认）
兜底 库无人维护或急需材料时临时指定维护人/提供人 R 综合部负责人（当前：赵雪冰·推断待确认）
取用人 按库内最新版使用，不自行改口径 I 各部门、项目负责人

3. 办之前请准备

  • 现有荣誉资料汇总文档（企业荣誉资质、投融资材料、生态认证、政府认可、赛事）
  • 各部门、项目负责人最近一版公司介绍、产品介绍、行业版 PPT 和分享材料
  • 已对外发布过的数据和说法清单（便于找出冲突）
  • 外部表单常见字段（成立时间、主体、规模、融资阶段、营收区间、主营产品）
  • 做 PPT 专用群内历史文件

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建库：按公司介绍/产品/行业版/案例/荣誉资质/视频/对外口径分类，每类指定维护人 素材与口径库管理员 启动后 5 个工作日内 飞书知识库 库目录与维护人表 🔧飞书固化
2 向各部门、项目负责人收集最新材料，标注版本号和适用场景 素材与口径库管理员 收集期 5 个工作日 飞书表单 素材清单 🔧飞书固化
3 编写“公司对外信息口径页”：公司简介标准版（短/中/长）、主体信息、融资阶段对外说法、产品能力标准数字、禁用说法 管理员 + 产品 + COO 收集完成后 5 个工作日内 飞书文档 口径页草稿 👤人工判断
4 CEO 审定标准介绍与口径页，定版后发布并通知全员“只用库内版本” CEO 提交后 3 个工作日内 飞书审批/文档评论 定版口径页 👤人工判断
5 对外取用：先查库，按场景组合；库里没有的由维护人 1 个工作日内补充 取用人、维护人 1 个工作日内响应 飞书知识库 取用记录 🤖+👤
6 外部活动/路演表单：按口径页填写；口径页未覆盖的敏感项（融资、营收、客户数）先问 COO 再填，提交后存档 填报人 表单截止前 1 个工作日完成 口径页 + 表单登记表 已提交表单存档 🔧+👤
7 获得新荣誉/证书、产品发版改变能力描述时，当周入库并更新版本号；做 PPT 群内新文件由机器人提醒归档 荣誉资质归档、产品 获得或发版后 5 个工作日内 知识库 + 群机器人 新版本素材 🔧+🤖
8 季度复核：清理过期材料，比对各版本说法是否一致，冲突提交 CEO 裁定 素材与口径库管理员 每季度首月 15 日前 飞书文档 + AI 比对 复核记录 🤖+👤

5. 交付物与模板

  • 交付物：素材与口径库、公司对外信息口径页、荣誉资质汇总（含更新日期）、外部表单填报登记、季度复核记录
  • 建议模板/表单：
    • 素材登记字段：素材名称、分类、适用场景（申报/媒体/峰会/客户/内部培训）、版本号、更新日期、维护人、是否可外发、链接
    • 口径页字段：口径项、标准说法、适用范围、禁用说法、审定人、生效日
    • 外部表单登记字段：活动/机构、表单截止日、填报人、敏感项填写内容、确认人、提交日、存档链接

6. 异常与升级

  • CEO 为对外口径的唯一终审人（A）；综合部负责人只负责库的运行兜底（指定维护人、提供人），口径冲突一律提交 CEO 定版
  • 对外急需材料但库里没有 → 维护人 1 个工作日内补充 → 赶不及时报综合部负责人临时指定提供人
  • 同一产品或公司数据出现两种说法 → 管理员当天暂停该素材外发 → 3 个工作日内提交 CEO 定版
  • 外部表单涉及融资、营收等敏感项且口径未定 → 先不提交 → 当天询问 COO，仍不确定报 CEO
  • 荣誉证书原件找不到 → 查档案台账（GEN-11） → 2 个工作日内无果报综合部负责人
  • 外部要求把素材同步到外网系统 → 维护人确认是否可外发 → 不可外发的需 CEO 同意

7. 衡量指标

  • 素材调取时效 = 收到需求到提供材料的时间，目标 ≤ 1 个工作日
  • 口径一致率 = 季度抽查对外材料中与口径页一致的份数 / 抽查份数，目标 100%
  • 素材新鲜度 = 近 6 个月内更新过的素材 / 在用素材总数，目标 ≥ 80%
  • 重复制作次数 = 每月因找不到素材重新制作 PPT 的次数，目标 0
  • 敏感项确认率 = 经确认后填写敏感项的表单 / 含敏感项的表单，目标 100%

8. 低效诊断

  • 现象：公司宣发内容、素材由谁输出、走什么流程不清楚（职责环节）｜依据：「【模态】综合部」2026-04
  • 现象：没有统一的公司与产品介绍，各场景反复重新做 PPT（制作环节）｜依据：「【模态】总经办」2026-04、「【模态】做PPT专用群」2026-06
  • 现象：向媒体提供奖项材料时手里资料不全（荣誉收集环节）｜依据：「【模态】总经办」2026-05
  • 现象：同一产品的能力数字与场景说法前后不一，内部人员第一次看到新说法（口径审定环节）｜依据：「【模态】做PPT专用群」2026-07
  • 现象：PPT 只在群文件流转，无分类、版本和负责人（存储环节）｜依据：「【模态】做PPT专用群」2026-06
  • 现象：外部活动表单融资阶段随手填写，认为“应该没人看”（表单填报环节）｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 公司通用介绍：短/中/长三版，用于申报、媒体、客户
  • LeapCore 行业版 PPT：由产品维护，行业版之间核心数字须一致
  • 峰会/大会分享：从库组合后按 MKT-09 评审定版
  • FDE 内部培训课件：可放库内“内部培训”类，标“不可外发”
  • 荣誉汇总：按企业荣誉资质、投融资、生态认证、政府认可、赛事分章，原件归档按 GEN-11
  • 外部活动/路演表单：按口径页填写，敏感项需确认

10. 待确认问题

  • 主责放在总经办还是品牌（生态市场条线）？与 BRD-17 品牌素材库是否合并为一个库？
  • 融资阶段、营收、客户数等对外说法由谁审定？是否有不可披露项清单？
  • 库是否放在飞书知识库，还是待外网可用后同步到 LeapCore？
  • 做 PPT 专用群是否保留？群内文件是否由机器人自动归档？
  • 荣誉资质更新是否与 POL-03 申报资料库共用一份数据？
GEN-14公司对外账号、证照年检与年报管理待新建225

状态：待新建｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：公司公共手机号/邮箱、公众号/小程序/服务号、以公司或财务身份注册的第三方平台账号需要开通、交接、收验证码，或 LEI 编码年检、工商年报、增值电信年报、认证续费等周期事项临近时启动
  • 负责人：主责——总经办账号与证照管理员（当前：田杰·推断待确认）；协同——财务账号持有人（当前：黄梦婷·推断待确认）、行政/电话卡管理（当前：侯明月·推断待确认）、公共邮箱与技术账号（当前：丁震宇·推断待确认）、营业执照登记（当前：王欣·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 建账号与周期事项总台账 → ② 绑定公共手机号/邮箱 → ③ 新开通按申请登记 → ④ 研发需用时开子账号 → ⑤ 到期前 30 天机器人提醒 → ⑥ 责任人办理年检/年报/续费 → ⑦ 结果存档 → ⑧ 季度盘点
  • 交付结果：公司对外账号与证照/编码/年报总台账、年审与续费日历、公共手机号与邮箱分配记录、各平台子账号分配记录、年报与年检回执存档
  • 状态依据：2026-04 起已梳理数字品牌资产表并办理公共电话卡，但事务多为事故驱动：增值电信年报临近截止才发现、LEI 年检到期时不清楚谁维护、公共手机卡在谁手里需群里问、账号绑定在个人手机、第三方平台验证码在群里明文发送多次（约 14 次）

1. 场景判定

  • 触发条件：新注册公众号/小程序/第三方平台账号；研发要登录以公司或财务身份注册的平台（如金蝶开放平台）；收到年检、年报、认证续费到期提醒（邮件、短信、主管部门通知）；公共电话卡、邮箱变更或交接；执照补领、账号主体变更
  • 典型说法：「现开展公司数字品牌资产梳理」「这个后续应该谁来维护」「某尾号的手机卡在谁那」「麻烦帮我接一下验证码」「这种账号开通创建类的工作要不总经办来整」
  • 判断问题：这件事是不是“公司身份的账号、编码、证照有到期或要验证码、要有人负责”？如果是研发自己的云服务器、模型 API 账号，不走本流程
  • 不归本流程管：云厂商、模型渠道、AI 平台等研发技术账号台账与验证码 → 请走 X-SEC-12；增值电信许可证办理与年报具体材料 → 请走 LEG-24；工信部报表、研究院年检等政府报表填报 → 请走 POL-08；域名与 HTTPS 证书续期 → 请走 X-SEC-21；新媒体账号认证与运营授权 → 请走 BRD-07；执照变更、补领的工商办理 → 请走 FIN-38 / GEN-15；密码与密钥的分发 → 请走 X-SEC-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账号与证照管理员 维护总台账与年审日历、分配公共号码邮箱、开子账号、跟进办理 R 总经办账号与证照管理员（当前：田杰·推断待确认）
综合部负责人 确定归口、审批新开通、事故复盘 A 综合部负责人（当前：赵雪冰·推断待确认）
财务账号持有人 财务类平台账号、工商年报财务数据、子账号分配配合 R 财务负责人（当前：黄梦婷·推断待确认）
电话卡管理 公共电话卡保管、分配登记 R 行政（当前：侯明月·推断待确认）
技术账号与公共邮箱 生成公共邮箱，研发侧平台需求提出 C 创始人兼 CTO（当前：丁震宇·推断待确认）
执照与公示系统登记 营业执照补领、公示系统登记 R 总经办（当前：王欣·推断待确认）
需求方 提出账号使用需求，按子账号使用 I 产品总监（当前：杨萌·推断待确认）、研发
CEO 涉及法人账号、跨境编码等重大事项决策 C CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 数字品牌资产表（公众号、服务号、小程序、视频号、网站、认证、绑定人、续费时间）
  • 公共电话卡（对内、对外）与公共邮箱清单及当前保管人
  • 证照/编码清单：营业执照、LEI 编码、增值电信许可证、各类认证，含到期日
  • 各主体工商年报、增值电信年报的上年回执
  • 第三方平台（如金蝶开放平台）的主账号、可分配子账号数量
  • 公司密码管理器或受限账号档案的访问权限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建总台账：账号/证照/编码名称、主体、绑定手机号（只记尾号与保管岗位）、绑定邮箱、责任岗位、到期/年报日 账号与证照管理员 启动后 10 个工作日内 多维表格（受限权限） 总台账 🔧飞书固化
2 把绑定在个人手机上的公司账号逐个迁到公共手机号/公共邮箱 管理员 + 原绑定人 台账建成后 1 个月内完成 各平台 迁移记录 👤人工判断
3 新开通账号：需求方提交申请（用途、平台、主体），审批后由总经办统一注册，账号密码入密码管理器或受限档案 需求方 → 管理员 申请后 2 个工作日内开通 飞书审批 + 密码管理器 新账号台账记录 🔧飞书固化
4 研发需登录公司身份平台时，优先分配独立子账号/空闲权限（绑定其本人手机号），不再代收验证码 财务账号持有人 + 管理员 申请后 1 个工作日内 平台子账号管理 子账号分配记录 🔧+👤
5 确需代收验证码时，持有人通过私密方式一次性提供，不在群里明文发送，并在台账记录 账号持有人 收到请求后 30 分钟内 飞书私密消息/密码管理 Bot 代收记录 👤人工判断
6 到期前 30 天、7 天机器人提醒责任岗位；主管部门邮件、短信通知统一转入综合部 机器人（管理员维护） 自动 多维表格自动化 提醒消息 🤖自动化
7 责任岗位办理年检、年报、续费（工商年报每年 6 月 30 日前，增值电信年报每年 3 月 31 日前，LEI 按年检日），财务提供数据 责任岗位 + 财务 截止日前 10 个工作日完成 公示系统/主管部门系统 回执 👤人工判断
8 回执、证书、新账号信息存入档案并更新台账下次到期日 账号与证照管理员 办结当天 档案库 + 台账 存档记录 🔧飞书固化
9 季度盘点：电话卡和账号在谁手里、是否在用、到期日是否正确；人员离职时同步交接 账号与证照管理员 每季度首月 10 日前 多维表格 盘点记录 🔧+👤

5. 交付物与模板

  • 交付物：对外账号与证照/编码/年报总台账、年审与续费日历、公共电话卡与邮箱分配记录、子账号分配记录、年报/年检回执存档
  • 建议模板/表单：
    • 总台账字段：类别（账号/证照/编码/年报/认证）、名称、所属主体、平台/发证机关、绑定手机号保管岗位（不写完整号码）、绑定邮箱、责任岗位、主账号/子账号、到期日或年报截止日、提前提醒天数、办理状态、存档链接
    • 账号开通申请字段：申请人、平台、用途、所属主体、需要的权限、是否需要子账号、使用期限
    • 禁止项：台账与群聊中不记录密码、验证码、证件号

6. 异常与升级

  • 年报/年检已逾期或收到未报送通知 → 责任岗位当天补报并联系主管部门 → 同时报综合部负责人与 CEO，3 个工作日内复盘
  • 不清楚某事项归谁维护 → 管理员当天先登记并临时认领 → 2 个工作日内由综合部负责人确定归口
  • 验证码或账号信息在群里明文出现 → 发送人立即撤回 → 管理员评估是否改密，按 X-SEC-11 处置
  • 公共电话卡下落不明 → 管理员按台账联系最近保管人 → 1 个工作日找不到办理挂失补卡并报综合部负责人
  • 公司电话号码被外部网站暴露或骚扰 → 管理员取证 → 报 COO/CEO 决定是否投诉

7. 衡量指标

  • 年报/年检按期率 = 截止日前完成的事项 / 应办事项，目标 100%
  • 台账覆盖率 = 已登记的公司对外账号与证照 / 实际存在数量（季度盘点核对），目标 100%
  • 个人手机绑定数 = 仍绑定在个人手机上的公司账号数，目标 0
  • 群内验证码明文次数 = 每月群里出现验证码/密码的次数，目标 0
  • 新账号开通时效 = 申请到开通的工作日，目标 ≤ 2 个工作日

8. 低效诊断

  • 现象：增值电信年报临近截止才由管理层发现（周期提醒环节）｜依据：「【模态】总经办」2026-04
  • 现象：LEI 编码年检到期时，群里追问由谁维护，经办人不了解该事项及其对跨境收付款的影响（归口环节）｜依据：「【模态】项目申报」2026-07
  • 现象：公共手机卡在谁手里要在群里问（保管登记环节）｜依据：「【模态】综合部」2026-07
  • 现象：公众号、小程序、认证等账号绑定在个人手机，形成单点（账号绑定环节）｜依据：「【模态】总经办」2026-04、「【模态】综合部」2026-04
  • 现象：研发登录财务身份注册的平台需人工接验证码，验证码在群里明文发送，同类请求反复出现（账号分配环节）｜依据：「leapcore接金蝶用友」2026-09、「leapcore接金蝶用友」2026-10
  • 现象：执照补领、新账号注册后账号信息需提醒才入档（存档环节）｜依据：「【模态】总经办」2026-08

9. 分支变体

  • 公众号、服务号、小程序、视频号：主体变更需走用印申请，认证续费按年提醒
  • 公共电话卡：一张对内、一张对外，分配给指定岗位，号码同步写入工商年报
  • 工商年报（各主体分别报）、增值电信年报：财务提供数据，按 LEG-24 准备材料
  • LEI 编码：影响海内外收付款，年检由综合部负责，财务配合
  • 营业执照作废补领：公示系统登记，账号密码入档
  • 金蝶等财务类开放平台：为研发分配子账号或空闲权限，不共享主账号验证码

10. 待确认问题

  • 本流程主责是否为总经办？与 X-SEC-12（研发技术账号台账）的分界是否按“公司/财务身份 vs 技术平台”划分？
  • 公司是否已有密码管理器？受限账号档案由谁保管？
  • LEI、增值电信、工商年报等周期事项各自的责任岗位是否已定？
  • 原绑定在个人手机上的账号迁移，是否需要 CEO 协调安排时间？
  • 金蝶开放平台是否还有空闲子账号可分配给研发？
GEN-15工商变更与新机构设立手续待新建80

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗4 × 跨4 × 险5

  • 适用场景：公司发生增资扩股、股东变更、地址变更等工商变更，或需要新设研究院、子公司等机构，并且有明确完成节点时启动
  • 负责人：主责——综合部工商经办（当前：侯明月·推断待确认）；协同——COO（股东材料，当前：常元和·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：祁航·推断待确认）、法务（当前：待指定）；兜底——综合部负责人；发起与审批——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发起任务单（事项+节点） → ② 确认变更项与材料清单 → ③ 收集材料 → ④ 股东会/董事会决议与法务审核 → ⑤ 用印 → ⑥ 提交办理 → ⑦ 领取新执照 → ⑧ 同步税务、银行、社保、证照库与档案
  • 交付结果：新营业执照或设立登记证明、变更登记通知书、经盖章的决议与章程修正案、后续同步事项完成清单、归档材料
  • 状态依据：卡片仅记录 2026-02 一次增资扩股/研究院设立，任务以一句话下达，经办人需先反问“变更哪项、材料有没有”，没有固定的材料清单和节点跟踪，属于每次临时处理

1. 场景判定

  • 触发条件：管理层决定增资扩股、引入新股东、股权转让、法定代表人或地址变更；需要新设研究院、子公司、分公司；上级部门要求在某日前完成登记
  • 典型说法：「下周跑一下公司变更流程，年前搞完」「变更哪项？相关材料有吗？」「研究院成立手续第一优先级，必须在第一周办完」
  • 判断问题：这件事是不是要到市场监管部门办理“主体登记信息变化或新设主体”？如果只是执照补领、办税员添加或注销，不走本流程
  • 不归本流程管：股东会召集与决议起草 → 请走 CEO-22；决议、合资协议的签署盖章 → 请走 LEG-06；子公司注销、执照补领、办税员变更 → 请走 FIN-38；研究院挂牌等政府对接 → 请走 POL-02；工商年报 → 请走 GEN-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
工商经办 确认材料清单、收集材料、线上/窗口办理、跟进进度 R 综合部工商经办（当前：侯明月·推断待确认）
CEO 发起、确定变更事项与节点、签字 A CEO（当前：邴龙志·推断待确认）
COO 协调新股东提供执照、联系人等材料 R COO（当前：常元和·推断待确认）
人事负责人 同步人员、社保、公积金主体信息 C 人事负责人（当前：黄莹·推断待确认）
财务 注册资本实缴、税务与银行信息变更 C 财务（当前：祁航·推断待确认）
法务 审核决议、章程修正案、股东协议 C 法务（当前：待指定）
综合部负责人 卡点协调、兜底 I 综合部负责人
行政 接收同步清单，更新办公地址、对外资料等行政信息 I 行政负责人（当前：胡则瑾·推断待确认）

3. 办之前请准备

  • 变更或设立事项说明：变更项目（注册资本/股东/地址/经营范围/法人）或新设主体名称、类型、注册资本、地址、负责人
  • 完成节点（如“年后 3 个工作日内”）
  • 新股东营业执照、法定代表人身份证明、联系人与联系电话（只在办理系统中填写，不在群里发）
  • 股东会/董事会决议、章程或章程修正案草稿
  • 新地址的租赁合同与产权证明（地址变更或新设时）
  • 原营业执照正副本、公章

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起任务单：写明事项类型、目的、完成节点、对接人 CEO 决定当天 飞书任务 工商任务单 🔧飞书固化
2 按事项类型调出材料清单模板，列出缺项与提供人，发回发起人确认 工商经办 收到后 1 个工作日内 飞书文档模板 材料清单 🔧+🤖
3 向股东、各部门收集材料，逐项打勾 工商经办、COO 清单确认后 3 个工作日内 多维表格 材料齐套表 🔧飞书固化
4 起草股东会/董事会决议、章程修正案，法务审核 工商经办、法务 材料齐后 2 个工作日内 飞书文档 审定决议与章程 👤人工判断
5 走用印审批，股东签字盖章 工商经办 审定后 2 个工作日内 飞书用印审批 盖章材料 🔧飞书固化
6 线上提交或窗口办理，补正意见当天处理 工商经办 盖章后 1 个工作日内提交 市场监管登记系统 受理回执 👤人工判断
7 领取新执照，扫描上传证照库，原件交档案 工商经办 核准后 2 个工作日内 证照库 + 档案室 新执照及扫描件 🔧飞书固化
8 按同步清单通知税务、银行、社保公积金、飞书主体信息、合同模板、官网与对外资料更新 工商经办 → 财务、人事、行政 领照后 10 个工作日内 飞书任务 同步完成清单 🔧+🤖
9 全部材料归档，任务关闭并通报 工商经办 同步完成当天 档案库 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：新营业执照或设立登记证明、变更登记通知书、盖章决议与章程修正案、同步完成清单、归档材料
  • 建议模板/表单：
    • 工商任务单字段：事项类型（增资扩股/股东变更/地址变更/新设主体/其他）、目的、完成节点、发起人、经办人、当前阶段、卡点
    • 材料清单模板（按事项类型分）：材料名称、提供人、是否原件、是否盖章、是否已收、备注
    • 变更后同步清单：税务登记、银行账户、社保公积金、开票信息、飞书主体、合同模板、官网与对外资料、资质证书、对外账号主体

6. 异常与升级

  • 变更项不明确 → 经办人当天向 CEO 确认 → 1 个工作日无答复由综合部负责人追问
  • 新股东材料迟迟不到 → COO 协调 → 距节点不足 3 个工作日仍缺，报 CEO 调整节点或改方案
  • 登记机关补正或驳回 → 经办人当天整理意见 → 涉及决议或章程内容，法务 1 个工作日内修改
  • 节点无法按期完成 → 经办人提前 2 个工作日说明原因 → CEO 决定是否加急或调整
  • 变更后发现未同步事项（如开票信息未改） → 财务/人事立即补办 → 记入同步清单模板防止再漏

7. 衡量指标

  • 按节点完成率 = 在约定节点前领到执照的事项数 / 工商事项总数，目标 100%
  • 材料一次齐套率 = 一次提交未被补正的事项 / 提交事项，目标 ≥ 80%
  • 办理周期 = 任务发起到领取新执照的工作日，目标 ≤ 15 个工作日（视登记机关调整）
  • 变更后同步完成率 = 领照后 10 个工作日内完成的同步项 / 应同步项，目标 100%

8. 低效诊断

  • 现象：任务以一句话下达，未说明变更哪一项，经办人需先反问再找材料（任务发起环节）｜依据：「内务大主管」2026-02
  • 现象：没有按事项类型的材料清单，新股东执照、联系人等材料临时索要（材料收集环节）｜依据：「内务大主管」2026-02
  • 现象：节点由管理层临时设定，缺少进度跟踪，优先级靠群里强调（节点管理环节）｜依据：「内务大主管」2026-02

9. 分支变体

  • 增资扩股/股东变更：需新股东材料、股东会决议、章程修正案，财务跟进实缴与验资要求
  • 研究院/子公司设立：需名称预核、注册地址、负责人、章程，与 POL-02 政府对接衔接；设立后进入 GEN-14 台账
  • 地址变更：需新地址租赁合同与产权证明，同步官网、合同模板与对外资料
  • 不同主体（武汉、苏州等）登记机关和流程差异：经办人在任务单中注明

10. 待确认问题

  • 工商经办主责是行政还是法务？是否使用代办机构？
  • 各类事项的材料清单是否已有成文模板？
  • 变更后的同步事项由谁负责通知各部门？
  • 新设主体后，财务、人事、档案的初始化是否另有流程？
  • 15 个工作日的办理周期目标是否可行？
GEN-16政府/领导及合作伙伴来访接待待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：省市领导、政府部门到公司参观视察，或外部合作伙伴来访授牌、挂牌时，由总经办统筹接待方案、动线、陪同、讲解、摄影和事后归档
  • 负责人：主责——总经办接待统筹（当前：赵雪冰·推断待确认）；协同——管理层陪同（当前：邴龙志、丁震宇、常元和·推断待确认）、品牌摄影（当前：待指定）、行政（当前：待指定）；兜底——综合部负责人
  • 核心流程：① 接收来访信息并确认要素 → ② 出接待方案 → ③ 分工与报备 → ④ 提前 1 天现场检查 → ⑤ 当天接待与控时 → ⑥ 事后材料存档、物品归位 → ⑦ 照片入库与宣发 → ⑧ 复盘更新模板
  • 交付结果：接待方案（时间、动线、讲解点、陪同人、物料、摄影、着装）、现场照片、授牌/材料存档记录、接待复盘
  • 状态依据：2026-06～07 有两次接待（领导参观、伙伴授牌），每次由统筹人在群里临时通知动线和时间，前一天才确定是否有交流环节，着装、摄影临时询问，没有接待模板

1. 场景判定

  • 触发条件：收到政府部门、上级单位、园区或合作伙伴的来访或参观通知；上级要求安排展示或交流；伙伴到访授牌、挂牌、取材料
  • 典型说法：「整体时间控制在半个小时内」「领导停车到一楼平台后直接上楼」「你们要穿工服吗」「上午的材料已拿回并存档」
  • 判断问题：来访方是不是政府、上级单位或伙伴，而且需要管理层陪同、展示公司形象？如果是客户考察或商务交流，不走本流程
  • 不归本流程管：会议室、茶水、车库指引、访客登记等行政保障 → 请走 ADM-06；客户来访考察与演示 → 请走 MKT-10 / SAL-08；媒体采访与拍摄 → 请走 BRD-12；演示环境准备 → 请走 RND-61；政府部门日常事项对接 → 请走 POL-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
接待统筹 确认来访要素、出方案、分工、现场控场、事后归档 R/A 总经办接待统筹（当前：赵雪冰·推断待确认）
管理层陪同 迎送、讲解、交流 R CEO、CTO、COO（当前：邴龙志、丁震宇、常元和·推断待确认）
讲解/演示人 展厅与业务区讲解、产品演示 R 相关业务负责人（当前：待指定）
摄影 现场拍照摄像、素材交付 R 品牌摄影（当前：待指定）
行政 会议室、茶水、停车、电梯、物料 R 行政（当前：待指定）
各业务区团队 动线经过区域保持工作状态与整洁 I 相关部门

3. 办之前请准备

  • 来访方单位、人数、级别、到场与离开时间、是否有交流环节、上级对接人
  • 接待方案模板（动线、讲解点、时长分配、陪同人、着装、摄影）
  • 展厅与动线经过区域的清单（如停车 → 展厅 → 业务区 → 交流点 → 离开）
  • 备用会议室（作为交流点）
  • 公司介绍、荣誉资质等标准材料（取自 GEN-13）
  • 授牌/挂牌活动所需的回执、领取材料清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 接到来访信息后登记要素，向上级对接人确认人数、时间、是否交流、是否需讲话 接待统筹 收到通知当天 飞书多维表格“来访登记” 来访登记 🔧飞书固化
2 按模板出接待方案：动线、各点讲解人与时长（总时长按要求控制，如半小时）、陪同人、着装、摄影、物料 接待统筹 来访前 2 个工作日 飞书文档模板 接待方案 🔧+🤖
3 方案发管理层确认，并向行政报备场地与物料需求、向摄影下单 接待统筹 方案完成当天 飞书群 + 任务 分工任务 🔧飞书固化
4 机器人推送日程提醒给陪同、讲解、摄影人员，附动线与着装要求 机器人（统筹维护） 来访前 1 个工作日 飞书日程 + 机器人 日程提醒 🤖自动化
5 现场检查：动线走一遍、展厅设备开机、演示可用、备用会议室就绪 接待统筹 + 行政 来访前 1 个工作日下班前 现场 检查记录 👤人工判断
6 当天按方案接待，统筹人控时；根据上级临时意见调整是否交流 接待统筹、陪同人 来访当天 现场 接待完成 👤人工判断
7 带回的材料、牌匾当天存档或归位并登记位置 接待统筹 当天 档案台账 存档记录 🔧飞书固化
8 照片、视频入品牌素材库，需要宣发的转新闻稿流程 摄影 → 接待统筹 来访后 2 个工作日内 素材库 照片与素材 🔧飞书固化
9 复盘问题（动线、控时、交流安排），更新接待模板 接待统筹 来访后 3 个工作日内 飞书文档 复盘与模板更新 👤人工判断

5. 交付物与模板

  • 交付物：来访登记、接待方案、日程提醒、现场照片、材料与牌匾存档记录、复盘记录
  • 建议模板/表单：
    • 来访登记字段：来访单位、级别、人数、到场/离开时间、上级对接人、是否交流、是否讲话、是否授牌、统筹人
    • 接待方案字段：时间轴、动线节点、各节点讲解人与时长、陪同人、着装要求、摄影安排、交流会议室、物料清单、应急备选

6. 异常与升级

  • 来访时间或交流安排临时变化 → 统筹人 30 分钟内通知全体分工人员 → 陪同人无法到场时报 CEO 指定替补
  • 上级要求与公司方案冲突（如取消交流） → 以上级意见为准 → 统筹人当场调整并告知陪同人
  • 展厅设备或演示故障 → 讲解人切换备用演示或口头讲解 → 事后转研发排查
  • 摄影人员无法到场 → 统筹人提前 1 天指定替补 → 当天无替补由行政用手机拍摄
  • 授牌材料或牌匾去向不明 → 统筹人当天查登记 → 找不到报综合部负责人

7. 衡量指标

  • 方案提前率 = 来访前 2 个工作日出方案的次数 / 接待次数，目标 100%
  • 控时达成率 = 按计划时长完成的接待 / 接待次数，目标 ≥ 90%
  • 归档及时率 = 当天完成材料存档与物品归位的次数 / 接待次数，目标 100%
  • 临时变更次数 = 来访前 1 天内对动线或交流安排的改动次数，目标逐次下降

8. 低效诊断

  • 现象：动线、时间、是否有交流环节在前一天才在群里确定（方案环节）｜依据：「董事会专项沟通群」2026-06
  • 现象：上级通知口径与现场安排不一致，交流环节临时取消（信息确认环节）｜依据：「董事会专项沟通群」2026-06
  • 现象：着装、摄影等事项临时询问，没有清单（分工环节）｜依据：「董事会专项沟通群」2026-06
  • 现象：授牌材料与牌匾存放靠群里说明，没有统一登记（事后归档环节）｜依据：「董事会专项沟通群」2026-07

9. 分支变体

  • 领导视察参观：重点是动线、讲解、控时，备用会议室作交流点，视上级意见调整
  • 伙伴授牌/挂牌：重点是材料领取、牌匾存放登记与照片宣发
  • 外出领取材料或参加授牌：由统筹人或指定人前往，回来当天存档
  • 来访同时有媒体：拍摄与对外口径按 BRD-12 执行

10. 待确认问题

  • 政府/领导接待的主责是否为总经办？与 ADM-06 行政接待如何分工？
  • 是否有固定的展厅讲解人和讲解词？
  • 着装（工服）是否需要统一规定？
  • 摄影是否固定由品牌岗承担？
  • 接待是否需要事前报 CEO 审批方案？
GEN-17AI 前沿资讯跟踪与新工具评测分享待优化80

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频5 × 耗2 × 跨4 × 险2

  • 适用场景：成员发现 AI 新模型、新工具、行业文章或竞品动态，需要在内部转发沉淀、判断是否试用、产出评测结论并分享时启动
  • 负责人：主责——产研 AI 情报与评测统筹人（当前：王皓南·推断待确认）；协同——资讯机器人维护人（当前：宋祺睿·推断待确认）、鼎慧产研资讯组织人（当前：杨萌·推断待确认）、工具试用评测人（当前：魏宗浩、季学森、岳阳、宫经喜等·推断待确认）、内部宣讲人（当前：李凯·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 转发并打标签 → ② 机器人抓摘要、去重入库 → ③ 日报/周报精选 → ④ 认领试用 → ⑤ 按模板评测 → ⑥ 审阅定结论 → ⑦ 周五分享 → ⑧ 结论归档与落地
  • 交付结果：多维表格「AI 情报库」中带摘要和标签的资讯条目；统一模板的工具评测文档（含结论：采用/参考/观望/不推荐）；分享会纪要；“采用”项转入 X-PRD-09（需求池）或 FIN-02（新购开通）的记录
  • 状态依据：已有 MOSS 日报、“HN 热门博客精选”卡片、链接预览机器人、零散的评测 wiki，2026-03 也定了每日精品资讯和周五分享的规则；但 2026-01～07 群内转发约 300 次，链接淹没在聊天里、重复转发约 4 次，摘要靠人读，预览机器人曾经失效，多人重复试用同类工具、结论没有沉淀约 20 次，至今没有统一入口和评测模板

1. 场景判定

  • 触发条件：看到新模型发布、新 AI 工具/开源项目、值得借鉴的行业文章、竞品产品动态；或者上级要求“试一试、出个评测”；或者积累的待分享内容够开一次分享会
  • 典型说法：「每天在群里发至少一条精品资讯」「能不能整个 Twitter 内容转飞书文档的工具」「这个我之前发了」「如何评价，有无用过的」「这个工具多玩玩，然后写一个评测文档」「该开分享会了」
  • 判断问题：这条信息是给内部跟进、判断要不要试用或借鉴的吗？如果是对外发布、组织正式活动、采购开通，就不归本流程
  • 不归本流程管：对外社群 AI 日报/内容发布 → 请走 OPS-19；正式分享会/培训的场地、报名、宣发组织 → 请走 GEN-07；决定采用后的付费订阅、账号开通 → 请走 FIN-02（AI 工具订阅与第三方服务新购开通）/ X-SEC-14（AI 编程工具订阅账号开通、充值与防封管理）；AI 编码规范（AGENTS.md、Prompt 模板、PR 门禁）制定与修订 → 请走 RND-28（AI 编码协作规范与质量管控）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
统筹人 维护情报库标签规则，分配试用，主持周五分享，跟进评测进度 R 产研 AI 情报与评测统筹人（当前：王皓南·推断待确认）
机器人维护人 维护日报、HN 精选、链接预览、转存机器人，保证抓取正常 R 资讯机器人维护人（当前：宋祺睿·推断待确认）
鼎慧线组织人 执行鼎慧产研群的每日精品资讯规则 R 鼎慧产研资讯组织人（当前：杨萌·推断待确认）
转发人 转发链接，附一句点评和标签 R 全体产研成员（当前：待指定）
试用评测人 认领工具，按模板试用并写评测 R 工具试用评测人（当前：魏宗浩、季学森、岳阳、宫经喜等·推断待确认）
审阅人 审阅评测结论，决定能否全公司分享、是否进入产品 A 创始人兼 CTO（当前：丁震宇·推断待确认）
宣讲人 对重点工具/Skill 做内部宣讲 R 内部宣讲人（当前：李凯·推断待确认）
研究顾问 对前沿研究类内容做点评、沉淀研究 wiki C 基座组架构/预研负责人（当前：陈晖·推断待确认）
相关部门 运营、生态、销售接收评测结论，用于对外内容或客户方案 I 运营负责人、生态市场负责人（当前：待指定）

3. 办之前请准备

  • 原始链接，以及一句话点评：为什么值得看、和我们哪个产品或场景有关
  • 标签：类别（模型/Agent 工具/IDE·CLI/技能库/视频生成/行业观点·融资/竞品）+ 关联产品线（LeapCore、LeapAll、FDE、鼎慧等）
  • 转发前先在「AI 情报库」搜一下，避免重复
  • 试用前确认：用测试账号，不上传客户数据和公司内部敏感资料；需要付费就先走采购
  • 评测文档用统一模板（见第 5 节）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 转发链接到指定群，附一句点评、标签，需要时 @ 相关同事 转发人 发现当天 飞书群 带标签的转发消息 👤人工判断
2 机器人抓取标题、来源、摘要，按链接去重后写入「AI 情报库」；重复链接自动回复已有条目 机器人维护人 转发后 10 分钟内自动完成 飞书机器人 + 多维表格 情报库条目 🔧+🤖
3 每日推送精选日报；每周五上午自动生成本周情报周报（按标签汇总 + 待试用清单） 机器人维护人 每日 / 每周五 12:00 前 机器人 + 多维表格 日报、周报 🤖自动化
4 对“值得试用”的条目指定 1 名试用人，同类工具只派 1 人，在情报库标记认领 统筹人 标记后 2 个工作日内 多维表格 + 飞书任务 试用任务 👤+🔧
5 试用并按模板写评测：场景、效果、成本、稳定性/封号风险、与自有产品对比、结论 试用评测人 认领后 5 个工作日内 飞书 wiki 评测模板 评测文档 👤+🤖
6 审阅评测，给出结论：采用 / 借鉴参考 / 观望 / 不推荐；决定是否全公司分享 审阅人 提交后 2 个工作日内 飞书 wiki 评论 审阅结论 👤人工判断
7 周五分享会：每次 2～3 个主题，每个 15 分钟以内；线下会议室同时开飞书会议，录制并自动生成纪要 统筹人、宣讲人 每周五固定时段 飞书日历 + 飞书会议/妙记 分享纪要、录屏 🔧+🤖
8 评测结论和纪要链接回写情报库；“采用/借鉴”项按 X-PRD-09 转产品需求池或按 FIN-02 申请采购，并通知相关部门 统筹人 分享后 1 个工作日内 多维表格 + 需求池 闭环记录 🔧飞书固化

5. 交付物与模板

  • 交付物：情报库条目、日报/周报、评测文档、分享纪要、转需求/转采购记录
  • 建议模板/表单：
    • 多维表格「AI 情报库」：链接、来源（公众号/X/GitHub/B站/小红书/HN）、标题、AI 摘要、类别标签、关联产品线、转发人、日期、是否值得试用、试用人、评测链接、结论、状态（新入库/待试用/评测中/已分享/已落地）
    • 评测文档模板：工具名与版本、试用场景、上手步骤、效果样例、费用与计费方式、稳定性与账号风险、数据安全、与自有产品/竞品对比、结论（4 选 1）、建议动作
    • 分享会纪要：主题、分享人、要点、结论、待办（负责人 + 截止日）

6. 异常与升级

  • 机器人抓取失败（如推文获取失败）→ 转发人补一句人工摘要；维护人 1 个工作日内修复 → 超过 3 个工作日没修好，升级研发负责人
  • 同一工具已有人在试用或已有评测 → 机器人或统筹人回复已有条目，不重复认领
  • 评测超期 → 统筹人第 6 个工作日提醒；超过 10 个工作日重新分配或关闭条目
  • 工具需要上传客户数据、内部代码或有封号风险 → 停止试用，升级研发负责人（当天）；涉及合规问题同步法务
  • 试用需要付费 → 暂停，按 FIN-02 申请，统筹人确认必要性（2 个工作日内）
  • 连续 2 周没有分享主题 → 统筹人从情报库“待试用”中指定主题；仍不足就当周取消并在群内说明

7. 衡量指标

  • 入库率 = 群内转发链接中进入情报库的比例，目标 ≥ 95%
  • 重复转发率 = 重复链接数 / 总转发数，目标 ≤ 5%
  • 评测周期 = 认领到评测审阅完成的工作日，目标 ≤ 7 个工作日
  • 分享会执行率 = 实际举办周数 / 计划周数，目标 ≥ 80%
  • 评测转化数 = 每季度结论为“采用/借鉴”并转入需求池或采购的工具数（观察指标，不设硬目标）

8. 低效诊断

  • 现象：链接只在聊天流里转发，没有分类、标签和去重，同一链接多次转发，事后找不到｜依据：「模态AI探索小分队」2026-01、「模态AI探索小分队」2026-02
  • 现象：摘要靠人工逐条读，外链预览机器人一度获取失败，信息消化成本高｜依据：「模态AI探索小分队」2026-01
  • 现象：多人分别试用同类工具，评价停在群里的几句口头反馈，没有评估表，结论没有沉淀｜依据：「模态AI探索小分队」2026-05、「模态AI探索小分队」2026-06
  • 现象：定了每日精品资讯和周五分享，但资讯质量参差、没有归档和复盘，分享会靠临时提议才开｜依据：「鼎慧产研决策部」2026-03、「模态AI探索小分队」2026-06
  • 现象：评测文档没有统一模板和截止时间，需要反复追问进度；分享会组织方式不统一，线下宣讲临时通知｜依据：「模态AI探索小分队」2026-07

9. 分支变体

  • 群聊差异：鼎慧产研群执行“每人每天至少一条精品资讯”的 KPI；模态 AI 探索小分队是自由转发。两边统一写入同一个情报库，用“来源群”字段区分
  • 内容类别：技术工具/模型动态（重点走试用评测）；行业观点/融资（只入库，不评测）；竞品产品（入库，并抄送产品负责人用于竞品分析）
  • 工具类别：模型评测可衔接测试评测组的基准评测；Agent/IDE/CLI 工具采用后，纳入《Agent 项目管理 Playbook》的工具清单；视频生成工具（可灵、即梦、Flova 等）由内容/视频运营评测，结论同步运营和品牌
  • 内部宣讲：重点 Skill 或工作流宣讲用线下会议室加飞书会议同步；规模较大、需要报名或对外开放时，转 GEN-07

10. 待确认问题

  • 主责统筹人是王皓南还是另设技术委员会？2026-03 提出的技术委员会是否已成立，是否由它承接本流程？
  • 两个群是否合并为一个资讯入口？鼎慧“每日一条精品资讯”KPI 是否继续执行、是否扩展到全产研？
  • 「AI 情报库」多维表格和自动摘要机器人由谁搭建？是否复用现有 MOSS 日报和 HN 精选机器人？
  • 评测时限（5 个工作日）、审阅时限（2 个工作日）是否可行？评测结论是否必须由 CTO 审阅，还是统筹人就能定？
  • 周五分享会的固定时段、频率（每周还是双周）是否确认？是否需要纳入飞书日历例会？
  • 与 OPS-19（对外 AI 日报）能否共用同一个情报库作为素材来源？
  • “不推荐/观望”结论是否需要对全员可见？试用中的数据安全红线是否已有成文制度？
  • 采用后的订阅开通走 FIN-02 还是 X-SEC-14，两条流程的边界请财务与 IT 确认
GEN-18制度与 SOP 定期复审、版本管理与废止待新建推断60

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨5 × 险3

  • 适用场景：已发布的制度与 SOP 需按周期复审；组织、系统、业务变化导致内容失效；同一事项存在多份版本冲突
  • 负责人：主责——制度管理员（当前：待指定）；协同——各 SOP 主责岗位、各部门负责人、法务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 建立制度/SOP 总目录 → ② 到期提醒 → ③ 主责复审（保留/修订/废止）→ ④ 修订走 GEN-01 → ⑤ 废止公告与下架 → ⑥ 更新目录
  • 交付结果：制度/SOP 总目录（编号、版本、主责、复审日、状态）、复审记录、废止公告
  • 状态依据：已有 GEN-01（制度与 SOP 起草、签发与发布宣贯）覆盖起草发布环节，本条补齐已发布制度与 SOP 的定期复审、版本管理与废止；本次全公司 SOP 梳理后条目较多（推断）

1. 场景判定

  • 触发条件：到达复审日（默认每年一次）；组织架构、系统或业务流程变化；执行中发现两份文件规定冲突
  • 典型说法：「这个流程早就不这么走了，文档还是老的」「两个文档写的审批人不一样，听哪个」
  • 判断问题：文件是否已发布生效？变化是否导致步骤、负责人或时限不再适用？
  • 不归本流程管：新制度起草发布 → 请走 GEN-01；人事制度编制 → 请走 HR-01；行政制度 → 请走 ADM-12；知识库空间与权限治理 → 请走 GEN-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
制度管理员 维护目录、发提醒、跟进复审、发布废止 R 制度管理员（当前：待指定）
SOP 主责岗位 复审并给出结论与修订稿 R 各 SOP 主责岗位
部门负责人 确认本部门复审结论 A 各部门负责人
法务 涉及合规条款的修订审核 C 法务（当前：待指定）
机器人 复审日前自动提醒 R 飞书机器人（制度管理员维护）

3. 办之前请准备

  • 全部已发布制度与 SOP 清单及存放位置
  • 近期组织架构、系统、业务变化清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立总目录，每份文件登记编号、版本、主责、生效日、复审日 制度管理员 1 个月内 多维表格 总目录 🔧飞书固化
2 复审日前 15 天自动提醒主责岗位 机器人 复审日前 15 天 飞书机器人 提醒 🤖自动化
3 主责复审，结论为保留/修订/废止 SOP 主责岗位 收到提醒后 10 个工作日内 飞书文档 复审记录 👤人工判断
4 修订按 GEN-01 发布，版本号加一并写变更说明 主责岗位+制度管理员 复审后 10 个工作日内 知识库 新版本 🔧飞书固化
5 废止文件发公告、移入归档区并加“已废止”标记 制度管理员 结论后 3 个工作日内 知识库/全员群 废止公告 🔧飞书固化
6 更新总目录 制度管理员 当日 多维表格 目录更新 🔧飞书固化

5. 交付物与模板

  • 交付物：总目录、复审记录、变更说明、废止公告
  • 建议模板/表单：总目录字段——编号、名称、类型（制度/SOP）、版本、主责岗位、所属部门、生效日、上次复审日、下次复审日、状态、链接

6. 异常与升级

  • 主责超期未复审 → 制度管理员提醒部门负责人；再超 10 个工作日 → 升级综合部负责人
  • 两份文件冲突 → 暂以较新且经审批者为准，10 个工作日内合并

7. 衡量指标

  • 复审按期完成率，目标 ≥ 90%
  • 超期未复审文件数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在 SOP 发布后逐渐失效、新旧版本并存导致执行口径不一的风险（推断）

9. 分支变体

  • 集团制度修订后需同步子公司版本（见 GEN-01）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 制度管理员由综合部哪个岗位兼任？
  • 默认每年复审一次是否合适，高频 SOP 是否半年一次？
GEN-19员工意见反馈、投诉与违规举报受理待新建推断36

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗3 × 跨3 × 险4

  • 适用场景：员工对制度、管理或同事行为有意见与投诉；或发现收受回扣、利益冲突、虚假报销、私卖公司数据或资源等违规行为需要举报
  • 负责人：主责——合规受理专员（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 公布受理渠道 → ② 登记分级 → ③ 指定调查人并回避 → ④ 调查取证 → ⑤ 处理决定 → ⑥ 反馈举报人 → ⑦ 保密归档
  • 交付结果：受理登记、调查报告、处理决定、反馈记录
  • 状态依据：聊天中未见员工投诉与违规举报的正式渠道（推断）

1. 场景判定

  • 触发条件：员工通过匿名表单、指定邮箱或当面提出意见、投诉或举报
  • 典型说法：「这个供应商是不是跟谁有关系」「我对这个安排有意见但不方便在群里说」
  • 判断问题：是一般意见建议、对人的投诉，还是涉嫌违规违纪？是否涉及举报人的直属上级？
  • 不归本流程管：员工绩效与行为问题处置 → 请走 HR-20；对考勤扣薪、绩效、调岗、解除等人事决定的申诉 → 请走 HR-29；客户投诉 → 请走 X-CS-10、X-CS-25；安全事件 → 请走 X-SEC-42、X-SEC-44；制度修订建议 → 请走 GEN-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
受理专员 登记、分级、反馈、归档 R 合规受理专员（当前：待指定）
调查人 调查取证、出报告 R 人事/法务/财务（当前：待指定，按事项指定）
决定人 一般事项指定调查人并作出处理决定 A 综合部负责人（当前：赵雪冰·部门报送人）
CEO 涉及部门负责人及以上人员的事项指定调查人并决定 A（升级） CEO（当前：邴龙志·推断待确认）
法务 证据与处理的合法性审核 C 法务（当前：待指定）

3. 办之前请准备

  • 事实描述、时间、涉及事项，可提供的证据（截图、单据）
  • 是否愿意实名、是否需要回避的人员

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 公布匿名表单与指定邮箱，写明保密与不报复承诺 受理专员 1 个月内上线 飞书匿名表单 受理渠道 🔧飞书固化
2 登记并分为意见建议/投诉/违规举报三类 受理专员 收到后 2 个工作日内 受控多维表格 受理登记 👤人工判断
3 指定调查人，与被举报人有关联者回避 决定人 登记后 2 个工作日内 — 调查指派 👤人工判断
4 调查取证并出报告 调查人 指派后 13 个工作日内 — 调查报告 👤人工判断
5 作出处理决定，涉及处分转 HR-20 执行 决定人 报告后 5 个工作日内 — 处理决定 👤人工判断
6 向实名举报人反馈结论（不披露他人隐私） 受理专员 决定后 3 个工作日内 私密渠道 反馈记录 👤人工判断
7 材料加密归档，限定可见人 受理专员 结案当日 受控云盘 归档 🔧飞书固化

5. 交付物与模板

  • 交付物：受理登记、调查报告、处理决定、反馈记录
  • 建议模板/表单：受理登记字段——编号、渠道、类别、是否实名、涉及部门、调查人岗位、状态、结论、结案日期（不记录举报人身份于公开字段）

6. 异常与升级

  • 涉及部门负责人及以上 → 受理专员在登记后 1 个工作日内直接报 CEO，由 CEO 作为 A（升级）指定调查人并作出处理决定
  • 涉嫌违法 → 法务在调查报告出具后 3 个工作日内评估是否报案
  • 调查超出 13 个工作日 → 调查人书面说明原因，决定人批准延期（最长 10 个工作日）并告知实名举报人

7. 衡量指标

  • 受理响应时长，目标 ≤ 2 个工作日
  • 结案周期 = 受理到反馈举报人（步骤 2～6 时限合计 25 个工作日），目标 ≤ 25 个工作日

8. 低效诊断

  • 聊天中未见相关流程，存在采购与供应商环节利益冲突无人发现、员工意见只能私下流传的风险（推断）

9. 分支变体

  • 子公司/关联主体员工可使用同一渠道，按主体分派调查人

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 受理专员由综合部哪个岗位兼任，是否需要设在人事之外？
  • 是否同步出台利益冲突申报（亲属关联供应商）要求？
GEN-20外部来文来函收发登记与分办待新建推断48

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗1 × 跨4 × 险4

  • 适用场景：公司收到政府部门通知/公文、监管函、律师函、法院或仲裁文书、税务/社保通知、客户或供应商正式函件（纸质、邮件、平台站内信、挂号信等）
  • 负责人：主责——收文专员（当前：待指定）；协同——法务（当前：待指定）、行政（当前：待指定）、各承办部门负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 统一收文登记 → ② 当日判定类型、紧急度与回复期限 → ③ 分办承办部门 → ④ 承办人确认接收 → ⑤ 按期办理或回函 → ⑥ 发文用印 → ⑦ 归档
  • 交付结果：收发文登记台账、分办记录、回函/办结记录、归档文件
  • 状态依据：已有 ADM-15（快递代收）、CEO-17（政府部门对接）覆盖部分环节，本条补齐外部正式来文来函的统一收文登记、分办与期限跟踪；聊天中可见外部通知由收到人自行转发（推断）

1. 场景判定

  • 触发条件：前台/行政签收挂号信或 EMS；公共邮箱、政务平台、税务/社保系统收到正式通知；员工个人收到发给公司的正式函件
  • 典型说法：「收到一封法院的信，给谁」「政务平台上有个通知要求下周前回复」
  • 判断问题：是否以公司为对象、是否有回复或履行期限、是否可能产生法律或行政后果？
  • 不归本流程管：普通快递代收 → 请走 ADM-15；政府部门日常对接 → 请走 CEO-17、POL-02；法律文书的应诉处置 → 请走 LEG-32；监管问询与执法调证的处置 → 请走 LEG-33；合同原件归档 → 请走 LEG-11；用印 → 请走 LEG-09；全员通知 → 请走 GEN-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
收文专员 登记、扫描、分办、期限跟踪、归档 R 收文专员（当前：待指定）
承办部门/承办人 确认接收、办理、起草回函 R 各承办部门负责人（可指定承办人）
法务 法律文书与监管函的研判与回复 R 法务（当前：待指定）
综合部负责人 分办争议裁定、逾期升级 A 综合部负责人（当前：赵雪冰·部门报送人）
机器人 期限前自动提醒 R 飞书机器人（收文专员维护）

3. 办之前请准备

  • 来文原件或截图、信封（含邮戳日期）、送达方式
  • 各类来文的默认承办部门对照表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签收后扫描登记（来文单位、类型、收到日、期限） 收文专员 收到当日 多维表格 收文登记 🔧飞书固化
2 判定紧急度；法律文书、监管函立即转法务 收文专员 收到当日 飞书 分级结果 👤人工判断
3 按对照表分办，承办人确认接收 收文专员+承办人 1 个工作日内 飞书任务 分办记录 🔧飞书固化
4 期限前 3 个工作日自动提醒承办人 机器人 期限前 3 个工作日 飞书机器人 提醒 🤖自动化
5 办理或起草回函，需盖章按 LEG-09 承办人 来文期限前 — 回函/办结说明 👤人工判断
6 发文登记并留存回执 收文专员 发出当日 多维表格 发文登记 🔧飞书固化
7 原件与扫描件归档 收文专员 办结后 3 个工作日内 档案柜/知识库 归档 🔧飞书固化

5. 交付物与模板

  • 交付物：收发文台账、分办记录、回函、归档
  • 建议模板/表单：收文台账字段——编号、来文单位、类型、送达方式、收到日、期限、紧急度、承办部门、承办岗位、状态、办结日、归档位置

6. 异常与升级

  • 法院/仲裁文书或监管函 → 当日升级法务与综合部负责人
  • 承办人 1 个工作日未确认 → 升级承办部门负责人
  • 临期未办结 → 期限前 1 个工作日升级综合部负责人

7. 衡量指标

  • 当日登记率，目标 100%
  • 按期办结率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在法律文书或监管通知被个人搁置、错过答辩或回复期限的风险（推断）

9. 分支变体

  • 各子公司/关联主体的来文按主体分别登记，注册地址代收的文件需约定转交时限

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 收文专员由行政还是总经办兼任？
  • 各主体注册地址的信件目前由谁代收、多久转交一次？

CEO 总经办

报送人：田杰 · 综合 · 27 条 · 已有 0 / 待优化 11 / 待新建 16
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
CEO-01年度/季度/月度规划与目标分解年终复盘、每季度初或每月初，需要先定公司级目标，再分解到部门、负责人和个人关键事项时启动主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、各部门负责人（当前：生态市场 许君、产品 杨萌、Leap 研发 王皓南·推断待确认）、总经办（当前：待指定）、人事负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 复盘并定公司级目标 → ② 发规划模板 → ③ 部门报规划并挂靠目标 → ④ 负责人对齐会定版 → ⑤ 事项分解到人并写验收标准 → ⑥ 一对一/OKR 确认 → ⑦ 月度跟踪复盘定版的公司级目标清单、各部门规划（每项挂靠一个公司目标，含负责人/验收标准/截止日期）、个人 OKR 与一对一记录、目标跟踪表待优化135
CEO-02战略论证会与闭门专题研讨CEO 召集各负责人做战略/经营论证，或就某一体系（如市场体系）开闭门专题研讨，需要会前准备、会后作业与跟进时启动主责——总经办/综合部负责人（当前：赵雪冰·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，发起与主持）、各部门负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起议题 → ② 锁定时间与会议室 → ③ 发议程与会前共享文档 → ④ 参会人预读并带方案 → ⑤ 开会录妙记 → ⑥ 发纪要与作业 → ⑦ 跟踪作业提交 → ⑧ 同步会议重点并转任务会议纪要（含决议）、作业清单与提交物、会议重点同步消息、转入飞书任务的落实事项待优化135
CEO-03新业务/创新项目立项与拍板员工提出新业务方向或创新 idea、AI 创新 lab 收到内外部小需求、子公司负责人提出业务打法/授权/融资诉求，需要立项、拿预算或拍板时启动主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、AI 创新 lab 内部创新负责人（当前：杨萌·推断待确认）、AI 创新 lab 外部创新负责人（当前：陈梦琪·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 提交立项单 → ② 登记入池 → ③ 初评分级 → ④ 按级别审批（预算/授权/融资）→ ⑤ 指定负责人与验证期 → ⑥ MVP/试运行 → ⑦ 验收评估 → ⑧ 转运营、继续或终止归档已审批的立项单（目标、负责人、预算、期限、验收标准）、立项台账、决策纪要、验收结论与归档记录待新建144
CEO-04重大技术/产品方案决策（拍板、公示与记录）研发或产品对方案出现分歧（计费归属、职责下发位置、模型选型等），或需要对需求优先级、技术取舍、技术路线与产品方向做决定时启动主责——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、方案提出人；兜底——CEO（当前：邴龙志·推断待确认）① 发起决策单 → ② 判定决策级别 → ③ 限时讨论 → ④ 公示或评审会 → ⑤ 拍板 → ⑥ 写决策记录并同步 → ⑦ 测试环境验证后上线 → ⑧ 复议走正式通道决策记录（议题、选项、依据、结论、决策人、生效时间），同步到相关群与决策记录表待新建192
CEO-05决策授权与汇报路径（去单点、防越级）需要明确哪些事由各负责人自行决定、哪些须报 CEO/COO，以及资源、权限、技术类问题"找谁"、跨主体或高层需求如何传达时启动；也用于新负责人任命后的授权书面化主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、总经办（当前：待指定）；兜底——COO（当前：常元和·推断待确认）① 盘点高频问题与决策事项 → ② 制定授权矩阵与"找谁"清单 → ③ 书面任命各组负责人 → ④ 发布并配置问答机器人 → ⑤ 按"结论+依据"汇报 → ⑥ 跨主体需求按入口传达 → ⑦ 每季度复核授权矩阵（事项×决策层级）、问题分类"找谁"清单、各组负责人书面任命、一页纸汇报模板、跨主体需求传达路径说明待新建300
CEO-06组织架构、汇报线与职责边界调整新业务、新团队、新人加入或主体合并，需要重新划分部门、负责人、直属上级、职责边界或用工主体，并同步飞书时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定架构）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、飞书管理员（当前：待指定）、财务负责人（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提出调整需求 → ② 起草架构与职责边界 → ③ 限时审阅定版 → ④ 影响评估（主体/审批/权限/群/考勤）→ ⑤ 发布通知（生效、交接、反馈截止）→ ⑥ 收集反馈修正 → ⑦ 飞书同步 → ⑧ 用工主体迁移 → ⑨ 30 天复盘定版组织架构图与人员架构表、职责边界 RACI 表、调整通知、飞书组织架构/直属上级/审批代理/部门群同步完成、人员主体台账更新待优化240
CEO-07多项目优先级与人力分配多个客户项目、新业务、内部产品同时推进，同一批人被多线抢占，或有人手头项目结束无人安排、商务/政府需求不断涌入时启动主责——研发资源协调人（当前：丁震宇·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/商务负责人（当前：刘昱潇·推断待确认）、各项目负责人（当前：待指定）、人事负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求统一入口并准入评分 → ② 每周资源盘点 → ③ 周优先级会排序 → ④ 发布周分工 → ⑤ 成员先写 plan 再开工 → ⑥ 插单走变更 → ⑦ 周五进度汇报 → ⑧ 缺口走外包或招聘项目池（含优先级 P0/P1/P2）、项目×人员占用看板、每周分工公告、变更记录、周进度汇报待优化400
CEO-08跨部门人员借调与技术人员外派审批其他部门需要临时借用本部门人员，或商务需要技术/FDE 人员去客户现场、参加对外会议，涉及优先级冲突与差旅成本时启动主责——借出部门负责人（当前：研发线 丁震宇、FDE/开放平台 郭逸非·推断待确认）；协同——需求发起人（商务/销售，当前：刘昱潇·推断待确认）、被借调/外派人员、行政（差旅预订，当前：待指定）、财务（差旅费用，当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起人与技术先对齐可行性 → ② 提交借调/外派申请 → ③ 借出部门负责人审批 → ④ 冲突时升级 → ⑤ 差旅预订 → ⑥ 定会议角色并执行 → ⑦ 纪要回传 → ⑧ 归还确认已审批的借调/外派单（目的、人员、时间、成本、DDL）、会议/外勤纪要、归还确认待新建108
CEO-09项目启动与重大事项跨组对齐会新项目启动、客户需求突变，或与供应商/客户谈判前，需要把产研、市场、基座组拉齐目标、分工、里程碑与对外话术时启动。主责——项目负责人/发起人（当前：丁震宇·推断待确认）；协同——项目管理/产品协调（当前：杨萌·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、研发执行负责人（当前：杨明学、杨云峰·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 判定需对齐 → ② 建日程并发会议通知 → ③ 会前材料就位（谈判分支备目标价/底线/话术）→ ④ 会上定目标、分工、选型、里程碑 → ⑤ 纪要与决议登记 → ⑥ 各人登记里程碑 → ⑦ 会后变更同步 → ⑧ 周期进度同步启动会/对齐会纪要、决议登记（目标、分工、里程碑、对外口径）、里程碑文档、谈判对齐单（谈判分支）、周期进度同步日程。待优化144
CEO-10会议召集、会议室预约与纪要归档任何内部或对外会议需要确定参会人、时间地点、会议室/视频会议，并在会后产出、分发和归档纪要时启动。主责——会议组织者（谁发起谁负责；产研侧当前常见：杨萌·推断待确认）；协同——行政（会议室规则与冲突协调，当前：待指定）、飞书管理员（机器人权限，当前：丁震宇·推断待确认）、转述人（当前：王皓南·推断待确认）、全体参会人；兜底——综合部负责人① 确认会议五要素 → ② 预约会议室 → ③ 建日程并发通知与材料 → ④ 参会人接受并预读 → ⑤ 开会并开启纪要 → ⑥ 纪要校对、待办转任务 → ⑦ 归档带议程、材料、会议室的飞书日程；会议纪要（含待办/责任人/DDL）；知识库归档链接。待优化60
CEO-11周例会与项目组例会公司经营例会、部门例会、项目组周例会/月度会/专题会等按固定周期召开、需要各方会前填报并跟进重点待办的会议。主责——例会组织者（公司经营例会：总经办，当前：赵雪冰·推断待确认；产研/项目推进周会：当前：杨萌·推断待确认；平台部/教育组例会：当前：陈梦琪·推断待确认；市场销售例会：销售负责人，当前：李鹏为·推断待确认）；协同——各部门负责人/部门代表、纪要与督办（当前：韩诗琪、闫登辉·推断待确认）、汇报分层制定（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 投票后固定周期并建重复日程 → ② 会前 1 个工作日建本期文档并提醒 → ③ 各部门按模板填报 → ④ 会前催填 → ⑤ 会上先过上期待办再分层汇报 → ⑥ 纪要与本期重点待办发布 → ⑦ 待办转任务跟踪本期例会文档（各部门汇报＋上期待办进展）、会议纪要、本期重点待办清单（责任人＋DDL）。待优化180
CEO-12日报/周报（DailyWork）与周期汇报员工每日/每周提交工作汇报，经部门/项目组汇总后同步给管理层；含冲刺期、居家办公期的加强汇报。主责——综合部负责人（汇报制度与 DailyWork 推行，当前：赵雪冰·推断待确认）；协同——总经办（通知与指引，当前：王欣·推断待确认）、开放平台（工具技术支持，当前：郭逸非·推断待确认）、LeapCore 适配研发（当前：岳阳·推断待确认）、部门/项目组汇总人（当前：杨萌、陈梦琪、葛家和、陈震·推断待确认）、全体员工；兜底——CEO（当前：邴龙志·推断待确认）① 系统每日生成草稿 → ② 本人核对确认 → ③ 未确认提醒 → ④ 部门日报汇总 → ⑤ 周报生成与确认 → ⑥ 部门/侧周报汇总 → ⑦ 周五周报群同步 → ⑧ 周统计与例会材料已确认的个人日报/周报、部门日报/周报、周报群同步记录、每周提交率统计与未提交名单。待优化225
CEO-13阶段总结与工作计划收集长假前、项目阶段结束或周期末，管理者要求个人与团队负责人提交阶段总结和下一阶段工作计划时启动。主责——发起管理者/产研负责人（当前：杨萌·推断待确认）；协同——团队负责人（当前：王皓南、张东郅·推断待确认）、各模块负责人、全员；兜底——上一级部门负责人① 定周期、范围、截止日 → ② 发通知与模板 → ③ 个人填写 → ④ 团队负责人汇总团队总结 → ⑤ 到期提醒 → ⑥ 审阅与退回 → ⑦ 1v1 交流 → ⑧ 汇总归档、行动项转任务个人阶段总结与计划、团队总结、汇总结论、1v1 记录、下一阶段行动项。待新建36
CEO-14向上汇报规范与关键节点上报项目遇到卡点、延期、重构、方向/战略调整或到达关键节点，或 CEO 抽查进度、索要发布会/融资/调研材料时，负责人按统一口径向上汇报。主责——项目/部门负责人（汇报人，当前：杨萌、王皓南·推断待确认）；协同——CTO（预审与指导，当前：丁震宇·推断待确认）、CEO（听取与决策，当前：邴龙志·推断待确认）；兜底——COO（当前：常元和·推断待确认）① 判定触发 → ② 按四段式写一页纸 → ③ 预审 → ④ 先对齐结论 → ⑤ 需要时补完整文档 → ⑥ 记录决策 → ⑦ 同步口径 → ⑧ 回报结果一页纸汇报（是什么/为什么/怎么做/什么结果）、决策记录、相关团队统一口径、CEO 可查的项目清单。待新建108
CEO-15任务指派、催办与闭环跟踪在群内、会上或口头提出需要他人执行的任务/需求后，从明确负责人和时限，到登记、跟进、结果回报关闭的全过程。主责——任务发起人（对结果负责到成功或失败）；协同——被指派执行人、任务台账归口（项目管理/产品协调，当前：杨萌·推断待确认；综合事项：总经办，当前：赵雪冰·推断待确认）、上一级负责人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提出任务写清四要素 → ② 执行人限时认领 → ③ 登记任务台账 → ④ 按优先级执行并更新 → ⑤ 定期汇总未完成项 → ⑥ 超期催办与升级 → ⑦ 回报结果（成功/失败）→ ⑧ 发起人确认关闭每个任务有唯一负责人、DDL、优先级、状态，并以“成功/失败＋说明”关闭；每周未完成清单。待新建240
CEO-16重大项目/活动复盘大会、展会等重大活动结束，或客户项目交付出现问题后，需要复盘原因、沉淀经验并形成行动项时启动。主责——复盘负责人（项目/活动负责人，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户侧对接人（当前：吴琪·推断待确认）、市场同步人（当前：李铭熙·推断待确认）、各点名成员；兜底——CTO（当前：丁震宇·推断待确认）① 触发并指定复盘负责人 → ② 用模板建文档、分板块 → ③ AI 拉取时间线与客户问题初稿 → ④ 分块填写 → ⑤ 复盘会对齐事实与根因 → ⑥ 定稿行动项 → ⑦ 发送去向、行动项转任务 → ⑧ 跟踪关闭复盘文档（目标/结果/差距/原因/行动项）、客户问题清单、行动项任务、发给市场/产品的结论摘要。待新建90
CEO-17政府部门对接、汇报演示与政策风险应对政府部门、政府平台运营方或合作方领导临时通知开会、要看项目进度、下达合规/整改要求，或外部政策态度出现变化需要启动 PlanB 时启动主责——政府事务对接统筹（当前：陈梦琪·推断待确认）；协同——CEO 对外联络（当前：邴龙志·推断待确认）、CTO 方案与优先级（当前：丁震宇·推断待确认）、演示研发（当前：葛家和、裴建武·推断待确认）、商务汇报与运营（当前：杨朋伟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 登记通知 → ② 确认议题 → ③ 指派参会人 → ④ 材料与演示准备 → ⑤ 参会汇报与纪要 → ⑥ 要求拆解登记 → ⑦ 跟踪闭环 → ⑧ 政策风险触发 PlanB政府事务登记记录、汇报材料与演示环境、会议纪要、政府要求整改清单（已闭环）、政策风险预案待新建180
CEO-18高管日程与外部约见管理外部人员或内部同事约高管见面、饭局、会议，或已排日程需要改期时启动主责——高管助理/总助（当前：待指定）；协同——被约高管（当前：邴龙志·推断待确认）、代为协调的高管（当前：丁震宇·推断待确认）、行政（会议室）（当前：待指定）；兜底——综合部负责人① 约见请求登记 → ② 查冲突给时段 → ③ 高管确认 → ④ 写入日历订会议室 → ⑤ 提醒 → ⑥ 变更通知 → ⑦ 会后记录高管共享日历中已确认的约见日程、约见登记记录、改期通知记录待新建72
CEO-19外部合作方/顾问评估与分成决策外部合作方、顾问、代写/渠道伙伴的产出不达标，或合作满一个周期，需要评估是否继续合作及调整分成/付费方式时启动主责——合作方对接业务负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、用户对接（当前：杨萌·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；决策——COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 事实收集 → ② 对照合同条款 → ③ 评估打分 → ④ 真实用户反馈 → ⑤ 方案与测算 → ⑥ 决策会 → ⑦ 协议与结算落地 → ⑧ 台账归档合作方评估表、决策纪要、补充协议或终止通知、更新后的合作方台账待新建96
CEO-20内部管理系统与协作工具建设（内控/业财平台）建设或改造内控与经营管理平台、业财系统、PRM/CRM/工单/合同等内部系统，或决定统一内部协作工具并强制推行时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——总经办（当前：田杰·推断待确认）、CTO 系统架构（当前：丁震宇·推断待确认）、定制系统开发（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、工单系统研发（当前：王皓南·推断待确认）、各板块执行协同人（当前：黄梦婷、韩诗琪、杨明学·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项建议书 → ② 系统盘点与选型 → ③ CEO 决策 → ④ 组推进组 → ⑤ 需求与边界 → ⑥ 开发配置与权限 → ⑦ 每周同步 → ⑧ 跑测验收 → ⑨ 上线强制推行 → ⑩ 系统台账交接项目建议书（含 MVP 范围）、选型打分表、推进表、系统台账（负责人/边界/权限）、上线公告与验收记录待优化300
CEO-21全员 AI 案例征集与积分激励宣贯总经办推出全员制度（如积分激励制度）需要宣贯，或面向全员发起案例征集、命名征集等活动时启动主责——总经办（当前：田杰·推断待确认）；协同——CEO 发起与评审（当前：邴龙志·推断待确认）、产品总监（案例收集与需求池）（当前：杨萌·推断待确认）、综合部负责人答疑（当前：赵雪冰·推断待确认）、问题收集（当前：宋祺睿·推断待确认）、人事（积分发放）（当前：待指定）；兜底——综合部负责人① 方案与口径核对 → ② 发通知 → ③ 宣贯会 → ④ 答疑与 FAQ → ⑤ 征集收表 → ⑥ 统计催交 → ⑦ 评审 → ⑧ 积分发放与公示宣贯通知与一页纸速览、FAQ、征集结果表、评审结论、积分发放与公示记录待优化40
CEO-22股东会筹备与决议（含主体设立/注销材料）召开母公司年度股东会、子公司股东会，或因设立全资子公司、注销旧主体需要股东会决议与配套材料时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——COO 汇报材料与股权结构（当前：常元和·推断待确认）、CEO 议案与决议（当前：邴龙志·推断待确认）、CTO 子公司会议发起与技术保障（当前：丁震宇·推断待确认）、行政接待与物料（当前：侯明月·推断待确认）、财务清税证明（当前：黄梦婷·推断待确认）、摄影（当前：宫经喜·推断待确认）、技术保障（当前：游家豪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 定会期与议案 → ② 发会议通知 → ③ 会务清单拆分到人 → ④ 议案/决议/汇报材料准备 → ⑤ 会前 3 天复核 → ⑥ 打印用印 → ⑦ 召开与表决 → ⑧ 签署归档与工商衔接会议通知、议案与股东会决议（已签署）、签到表与表决表、汇报材料、会议纪要；设立/注销时附股权结构与清税证明待优化200
CEO-23股权/期权激励方案起草与审议发放需要制定或修订期权/限制性股权激励方案并提交董事会、股东会审议，或发放一批期权时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——董事会成员（当前：邴龙志、丁震宇、常元和·推断待确认）、法务（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 起草方案与授予协议 → ② 法务审阅 → ③ 待决事项清单 → ④ 董事会集中讲解与决议 → ⑤ 定稿 → ⑥ 股东会审议 → ⑦ 授予协议签署发放 → ⑧ 发放汇报与遗留问题处理股东会审议通过的激励方案、董事会决议记录、签署的授予协议、发放名册与汇报纪要待新建100
CEO-24分子公司/关联主体边界与权限管理关联公司（EG、鼎慧、深圳、苏州、参股合资公司、曜途等）涉及积分、期权、福利、飞书账号、办公用品、人员兼岗、招聘考勤、项目资料同步等事项，需要判断是否共享、如何切割及对外口径时启动主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——CTO 口径决策（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）、人事（当前：黄莹·推断待确认）、EG 负责人（当前：徐莉·推断待确认）、子公司 CEO（当前：赵捷·推断待确认）、曜途技术负责人（当前：白立新·推断待确认）、财务/法务/行政（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 识别涉及关联主体的事项 → ② 查边界清单 → ③ 未覆盖事项出建议 → ④ 会签 → ⑤ 管理层决策 → ⑥ 书面同步子公司 → ⑦ 账号权限与费用切割 → ⑧ 子公司项目定期同步 → ⑨ 季度复核《关联主体边界清单》（可共享/不共享）、对外口径说明、飞书组织架构与权限调整记录、子公司服务边界约定、子公司项目周报与资料归档待新建225
CEO-25重大突发事件与危机应对（舆情、监管、重大事故）发生可能严重影响公司声誉、经营或合规的事件，如重大客户事故、大规模数据泄露、负面舆情、监管约谈/检查、人员安全事件、核心供应商断供主责——总经办负责人（当前：田杰·部门报送人）；协同——研发负责人、品牌负责人（当前：何思雨·部门报送人）、法务（当前：待指定）、销售负责人（当前：待指定）、人事（当前：待指定）；兜底——总经办（当前：田杰·部门报送人）① 上报总经办 → ② 分级 → ③ 成立应急小组 → ④ 统一对内对外口径 → ⑤ 处置与定时同步 → ⑥ 宣告结束 → ⑦ 复盘整改事件分级记录、应急小组名单、对外声明/口径、进展通报、复盘报告待新建125
CEO-26年度经营预算审定与月度经营分析年度开始前审定各部门、各主体经营预算（收入、人力、采购、云与模型成本、市场费用）；每月召开经营分析会，对比预算与实际并决策调整主责——总经办负责人（当前：田杰·部门报送人）；协同——财务负责人（当前：黄梦婷·部门报送人）、各部门负责人、各主体负责人；兜底——总经办（当前：田杰·部门报送人）① 下发预算模板 → ② 各部门编报 → ③ 财务汇总测算 → ④ 管理层审定 → ⑤ 发布预算 → ⑥ 每月出经营数据 → ⑦ 经营分析会 → ⑧ 决议跟踪年度预算表、月度经营数据包、经营分析会纪要与决议清单待新建180
CEO-27融资推进与投资者关系管理公司启动新一轮融资，或需向现有投资人定期报送经营信息、响应投资人问询与尽调主责——融资/投资者关系负责人（当前：待指定）；协同——财务负责人（当前：黄梦婷·部门报送人）、法务（当前：待指定）、研发负责人、总经办（当前：田杰·部门报送人）；兜底——总经办（当前：田杰·部门报送人）① 融资启动决策 → ② 准备材料与数据室 → ③ 投资人接触与保密协议 → ④ 尽调响应 → ⑤ 条款谈判与决策 → ⑥ 交割 → ⑦ 投后定期报告融资计划、商业计划书、数据室、尽调问答记录、交割文件、投后定期报告待新建100
CEO-01年度/季度/月度规划与目标分解待优化135

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：年终复盘、每季度初或每月初，需要先定公司级目标，再分解到部门、负责人和个人关键事项时启动
  • 负责人：主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、各部门负责人（当前：生态市场 许君、产品 杨萌、Leap 研发 王皓南·推断待确认）、总经办（当前：待指定）、人事负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 复盘并定公司级目标 → ② 发规划模板 → ③ 部门报规划并挂靠目标 → ④ 负责人对齐会定版 → ⑤ 事项分解到人并写验收标准 → ⑥ 一对一/OKR 确认 → ⑦ 月度跟踪复盘
  • 交付结果：定版的公司级目标清单、各部门规划（每项挂靠一个公司目标，含负责人/验收标准/截止日期）、个人 OKR 与一对一记录、目标跟踪表
  • 状态依据：已有董事会负责人规划会、季度规划 wiki、工作规划与组织架构文档；但 2026-01～10 聊天中多次出现"先定个调""工作要匹配大目标"的追问，规划下发后关键事项无验收标准需事后追问，一对一首次推行无模板，目标分解与跟踪未固化

1. 场景判定

  • 触发条件：年终（12 月下旬～1 月）；每季度第 1 周；每月初负责人会；公司战略方向调整后需要重新分解目标
  • 典型说法：「大家的工作至少得匹配一个大目标，不然就是无效工作」「同步一下 Q1 季度规划，查看和理解文档即可」「第一季度把团队和 SOP 弄明白比什么都重要」「我觉得应该先定个调」
  • 判断问题：这件事是不是在回答"本周期做什么、做到什么程度、谁负责"？如果只是单个项目的排期、插单或人员调配，不走本流程
  • 不归本流程管：多项目人力冲突与优先级调整 → 请走 CEO-07；组织架构/汇报线调整 → 请走 CEO-06；战略专题论证会 → 请走 CEO-02；新业务立项 → 请走 CEO-03；个人绩效考核 → 请走 HR-32（非研发岗位周期绩效考核）或 HR-19（研发绩效评价与质量奖惩）；积分结算 → 请走 HR-18（积分激励制度运行）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
公司级目标定调与定版 提出并拍板本周期公司级目标（≤3 个） A CEO（当前：邴龙志·推断待确认）
目标框架与产研规划 提出目标框架建议，牵头产研规划 R 创始人兼 CTO（当前：丁震宇·推断待确认）
经营节奏建议 控制每部门每周期重点要求数量 C COO（当前：常元和·推断待确认）
部门规划编制 编规划、分解事项、写验收标准、下发并确认 R 各部门负责人（当前：许君、杨萌、王皓南·推断待确认）
一对一与 OKR 与下属逐个对齐计划，形成个人 OKR R 直属上级（当前：杨萌、王皓南·推断待确认）
模板与跟踪表 发模板、组织会议、维护跟踪表、月度提醒 R 总经办（当前：待指定）
OKR 归档与保密 归档 OKR，处理一对一中的人事个案 C 人事负责人（当前：待指定）
员工 自评复盘、写计划、确认事项 I 全员

3. 办之前请准备

  • 上一周期复盘一页纸：目标完成情况、未完成原因、遗留事项
  • 公司级目标草案（≤3 个，示例：规模化销售 LeapCore、SOP 优化、合规与业财一体化）
  • 部门规划模板（事项、挂靠目标、优先级、负责人、验收标准、截止日期、所需资源）
  • 当前组织架构与缺位岗位清单
  • 上一周期目标跟踪表
  • 一对一前：员工自评复盘与下周期计划

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 完成上周期复盘，提出公司级目标草案（≤3 个） CEO、创始人兼 CTO 周期开始前 5 个工作日 飞书文档 目标草案 👤人工判断
2 发布规划模板、提交截止时间和对齐会日程 总经办 草案完成后 1 个工作日内 飞书文档模板、日程、群公告 规划征集通知 🔧飞书固化
3 编制部门规划，每项事项挂靠一个公司目标并写验收标准 各部门负责人 通知后 3 个工作日内 多维表格 部门规划初稿 👤人工判断
4 召开负责人对齐会：逐部门过规划，删去不挂靠目标的事项，标出缺位岗位 CEO 主持，总经办记录 周期第 1 周内，会议 ≤2 小时 飞书会议、妙记 定版规划、缺位岗位清单 👤+🤖
5 每个部门本周期只定 1 项重点要求，写入跟踪表 CEO、COO 对齐会当场 多维表格 部门重点要求 👤人工判断
6 部门内下发规划并 @ 责任人，要求已读确认；验收标准不清的当面对齐后补写进文档 部门负责人 定版后 2 个工作日内 飞书文档、已读回执 已确认的事项清单 🔧飞书固化
7 一对一：员工先自评复盘写计划，再与上级逐条对齐，形成个人 OKR 直属上级 定版后 10 个工作日内覆盖全员（每天 2～3 人） 飞书 OKR/文档模板、日程 个人 OKR、一对一记录 🔧+👤
8 月度跟踪：更新进度，偏差项在月度负责人会说明 各负责人填写，总经办汇总 每月第 1 个工作日 多维表格、机器人提醒 目标进度表 🔧+🤖
9 周期末复盘，结论作为下一周期第 1 步输入 CEO 主持 周期最后 1 周 飞书文档 复盘一页纸 👤人工判断

5. 交付物与模板

  • 交付物：公司级目标清单、部门规划、缺位岗位清单、个人 OKR、一对一记录、月度目标进度表、周期复盘
  • 建议模板/表单：
    • 目标跟踪多维表格：目标编号、公司目标、部门、事项、负责人、验收标准、截止日期、所需资源、状态（未开始/进行中/有风险/完成）、本月进展、偏差说明
    • 部门规划模板：事项、挂靠目标编号、优先级、负责人、验收标准、DDL、依赖部门
    • 一对一记录模板：上周期复盘、下周期计划、所需支持、发展方向、团队建议（人事个案字段仅本人、上级、人事可见）

6. 异常与升级

  • 公司级目标未按时定调 → 各部门暂按上周期目标延续 → 升级 CEO，最迟周期开始后 5 个工作日内定版
  • 部门事项无法挂靠任何公司目标 → 删除或写明理由 → 对齐会上由 CEO 当场裁决
  • 事项缺验收标准，执行方追问 → 产品与研发 2 个工作日内共同补写 → 未完成升级部门负责人
  • 部门间职责边界不清导致规划重叠或空白 → 记录争议点 → 转 CEO-06，5 个工作日内拉会划分
  • 一对一中出现离职意向、调岗等人事个案 → 不写入公开文档 → 直属上级 1 个工作日内告知人事负责人

7. 衡量指标

  • 目标挂靠率 = 挂靠到公司目标的事项数 / 部门事项总数，目标 100%
  • 验收标准完备率 = 写明验收标准的事项数 / 事项总数，目标 ≥ 90%
  • 规划定版准时率 = 周期第 1 周内定版的部门数 / 部门总数，目标 100%
  • 一对一覆盖率 = 定版后 10 个工作日内完成一对一的人数 / 应覆盖人数，目标 ≥ 95%
  • 月度事项按期完成率 = 按期完成事项数 / 当月应完成事项数，目标 ≥ 80%

8. 低效诊断

  • 现象：公司级目标未先定调，部门规划各写各的，无法判断工作是否有效（定调环节缺失）｜依据：「董事会」2026-05、「董事会」2026-10
  • 现象：规划文档只发不确认，关键事项无验收标准，执行方事后追问后改为"当面再对"（下发环节缺验收标准与已读确认）｜依据：「工程咨询产研」2026-01
  • 现象：一对一首次推行无模板，时间靠逐个协调，计划复盘与人员规划混在一次谈话里（一对一环节无标准）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-02
  • 现象：部门间岗位边界不清，规划无法落地，需另行拉会划分（规划与组织边界脱节）｜依据：「董事会」2026-10
  • 现象：关键岗位缺负责人，规划事项无人承接（缺位岗位未在规划环节暴露）｜依据：「董事会」2026-03

9. 分支变体

  • 产品线季度规划：产品负责人发布季度目标与工作计划（含转化率类 OKR 指标），按产品/研发/市场/运营列核心任务
  • 月度负责人规划会：CEO 发起，面向全部门负责人，重点是事项挂靠公司目标与缺位岗位
  • 年终复盘 + 一对一/OKR：研发线自上而下推行，测试岗单独沟通
  • 市场生态规划与产研规划：前者以活动、渠道、申报为事项，后者以版本、交付为事项，验收标准写法不同

10. 待确认问题

  • 公司级目标由 CEO 定版，还是董事会集体定版？
  • 规划节奏以月度为主还是季度为主？月度会是否固定在每月第 1 周？
  • 目标跟踪统一用飞书 OKR 还是多维表格？
  • 规划模板与月度跟踪由总经办哪位维护？
  • 一对一是否覆盖全员，频次是季度还是半年？
  • "每个部门每周期只提 1 项重点要求"是否作为正式规则？
CEO-02战略论证会与闭门专题研讨待优化135

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：CEO 召集各负责人做战略/经营论证，或就某一体系（如市场体系）开闭门专题研讨，需要会前准备、会后作业与跟进时启动
  • 负责人：主责——总经办/综合部负责人（当前：赵雪冰·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，发起与主持）、各部门负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发起议题 → ② 锁定时间与会议室 → ③ 发议程与会前共享文档 → ④ 参会人预读并带方案 → ⑤ 开会录妙记 → ⑥ 发纪要与作业 → ⑦ 跟踪作业提交 → ⑧ 同步会议重点并转任务
  • 交付结果：会议纪要（含决议）、作业清单与提交物、会议重点同步消息、转入飞书任务的落实事项
  • 状态依据：已有会前共享文档、妙记、纪要文档与作业机制；但 2026-06 同一轮论证会多次改期，作业需群里催交 2 次，会前准备要求靠口头，会议结论未统一转为任务

1. 场景判定

  • 触发条件：月度经营会、季度战略会；CEO 临时召集的战略论证；需要管理层集中梳理某一业务体系的闭门研讨
  • 典型说法：「请带着思考来开会，并把会议精神传递给同事」「大家带着方案，带着思路来开会，不要会上现想现讨论」「大家认真看一下内容和子链接，是本周开会需要讨论的主要内容」「大家记得交作业」
  • 判断问题：会议是否需要参会人会前准备材料、会后提交作业或分工写文档？只是信息同步的例会不走本流程
  • 不归本流程管：周期性规划与目标分解 → 请走 CEO-01；具体技术/产品方案拍板 → 请走 CEO-04；新业务立项 → 请走 CEO-03；部门日常周会 → 由部门自定

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
会议发起与主持 定议题、议程，主持会议，拍板结论 A CEO（当前：邴龙志·推断待确认）
会议组织 定时间会议室、发通知与材料、记录纪要、跟踪作业 R 总经办/综合部负责人（当前：赵雪冰·推断待确认）
参会负责人 预读、带方案参会、按时交作业、向本部门传达 R 各部门负责人（当前：待指定）
部门员工 接收会议精神与落实任务 I 全员

3. 办之前请准备

  • 议题与目标：本次要做出的决定或要产出的方案
  • 议程（每个议题的时长、主讲人）
  • 会前共享文档：背景材料、子链接、需参会人预填的部分
  • 参会名单与会议室（固定会议室优先）
  • 上次会议作业与决议的落实情况

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定议题、目标与参会人 CEO 会前 5 个工作日 飞书文档 议题说明 👤人工判断
2 锁定时间与会议室，发日程；时间定后原则上不改 总经办 议题确定后 1 个工作日内 飞书日程、会议室预订 会议邀请 🔧飞书固化
3 发布议程与会前共享文档，标明预读内容和需准备的方案 总经办 会前 ≥ 48 小时 飞书文档、群公告 议程、会前材料 🔧飞书固化
4 预读并在共享文档中写好本部门方案/观点 各部门负责人 会前 24 小时 飞书文档 会前方案 👤人工判断
5 开会，开启妙记，按议程推进，当场明确决议与作业 CEO 主持，总经办记录 按议程 飞书会议、妙记 会议录音与要点 🔧+🤖
6 发纪要：决议、作业（内容、负责人、截止日期），作业同时建飞书任务 总经办 会后 24 小时内 飞书文档、飞书任务 纪要、作业任务 🤖自动化+🔧
7 跟踪作业：截止前 1 天机器人提醒，逾期在群内点到部门 总经办 截止前 1 天、截止当天 飞书任务、机器人 作业提交台账 🔧+🤖
8 汇总作业，整理"会议重点"同步全员，落实事项转入任务 总经办，CEO 审定 作业截止后 2 个工作日内 群公告、飞书任务 会议重点同步、落实任务 👤+🔧
9 下次会议开头回顾上次决议落实情况 总经办 下次会议 飞书文档 落实情况表 🔧飞书固化

5. 交付物与模板

  • 交付物：议程、会前共享文档、妙记、纪要、作业提交物、会议重点同步、落实任务清单
  • 建议模板/表单：
    • 议程模板：议题、目标（要决定什么）、主讲人、时长、预读材料链接、需准备内容
    • 纪要模板：参会人、决议（编号）、作业（内容/负责人/截止）、待定事项、下次会议时间
    • 作业跟踪多维表格：会议名称、作业编号、负责人、截止日期、提交链接、状态

6. 异常与升级

  • 会议需改期 → 总经办至少提前 24 小时通知并给新时间 → 同一会议改期超过 1 次，报 CEO 决定是否取消或合并
  • 关键负责人无法参会 → 会前 24 小时书面提交意见并指定代理人 → 总经办记录
  • 参会人未预读、未带方案 → 主持人可将该议题顺延 → 会后 CEO 点评
  • 作业逾期 → 截止当天提醒 → 逾期 2 个工作日升级 CEO
  • 会上未形成结论 → 纪要中列为待定事项并指定负责人 → 5 个工作日内按 CEO-04 拍板

7. 衡量指标

  • 会议按期召开率 = 未改期召开次数 / 计划次数，目标 ≥ 90%
  • 会前材料提前量 = 议程发出至开会的小时数，目标 ≥ 48 小时
  • 纪要及时率 = 24 小时内发出纪要的会议数 / 会议总数，目标 100%
  • 作业按时提交率 = 按时提交作业数 / 应交作业数，目标 ≥ 90%
  • 决议落实率 = 到期已落实的决议数 / 到期决议数，目标 ≥ 85%

8. 低效诊断

  • 现象：同一轮论证会多次改期，参会人反复调整日程（会议时间锁定环节缺规则）｜依据：「【模态】业务负责人」2026-06
  • 现象：作业靠周末在群里催交（作业跟踪环节无任务与提醒）｜依据：「【模态】业务负责人」2026-06
  • 现象：会前准备要求只在群消息里口头提出，参会人会上现想（会前准备环节无模板）｜依据：「打赢这一仗」2026-07
  • 现象：会议重点（汇报层级、积分制、阶段重点）在月底才集中同步，未逐项转为任务（结论落实环节缺失）｜依据：「【模态】业务负责人」2026-06

9. 分支变体

  • 战略论证会（月度经营会、季度战略会）：有作业与截止日期，会后同步会议重点
  • 闭门专题研讨：针对某一体系（如市场体系），会后按分工各写文档
  • 配套会议节奏（规划中）：周例会、半月务虚会、月度经营会、季度战略会，按不同频次套用本流程的简化版

10. 待确认问题

  • 会议组织是否固定由总经办负责？是否需要备岗？
  • 周例会、半月务虚、月度经营会、季度战略会的节奏是否已正式确定？
  • 会前材料"提前 48 小时"和纪要"24 小时内"是否可行？
  • 作业是否统一进飞书任务，还是用多维表格跟踪？
  • 改期超过 1 次需 CEO 决定，这条是否接受？
CEO-03新业务/创新项目立项与拍板待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：员工提出新业务方向或创新 idea、AI 创新 lab 收到内外部小需求、子公司负责人提出业务打法/授权/融资诉求，需要立项、拿预算或拍板时启动
  • 负责人：主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、AI 创新 lab 内部创新负责人（当前：杨萌·推断待确认）、AI 创新 lab 外部创新负责人（当前：陈梦琪·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、财务负责人（当前：待指定）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 提交立项单 → ② 登记入池 → ③ 初评分级 → ④ 按级别审批（预算/授权/融资）→ ⑤ 指定负责人与验证期 → ⑥ MVP/试运行 → ⑦ 验收评估 → ⑧ 转运营、继续或终止归档
  • 交付结果：已审批的立项单（目标、负责人、预算、期限、验收标准）、立项台账、决策纪要、验收结论与归档记录
  • 状态依据：积分激励制度中有"创意提交→评审→MVP→成果转化"的原则，AI 创新 lab 刚宣布收束职能；但实际立项与小额预算靠群里口头批，子公司提案多次追问"看了吗"才有回应、结论无纪要，创新流程后段"产品包装→转移运营→推广"完全缺失

1. 场景判定

  • 触发条件：有人提出新方向想"真做"；内部创新 idea 或外部小需求需要投入人力/预算；子公司负责人带着书面提案请求拍板
  • 典型说法：「真做吗，真做就立项」「想跟你们对齐/拍板的几件事」「现在很多小产品感觉有点乱，负责人换来换去」「验证闭环要在一个月内」
  • 判断问题：这件事是否需要新的负责人、新的预算或新的授权？如果只是已有项目内的需求或排期，不走本流程
  • 不归本流程管：已立项项目之间的人力与优先级 → 请走 CEO-07；技术/产品方案分歧拍板 → 请走 CEO-04；客户需求进入产品需求池 → 请走 X-PRD-09（需求提报登记与需求池管理）；组织架构调整 → 请走 CEO-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
终审 二、三级立项拍板；子公司授权与融资决策 A CEO（当前：邴龙志·推断待确认）
技术与资源评估 可行性、所需资源、一级立项审批 R 创始人兼 CTO（当前：丁震宇·推断待确认）
内部创新统筹 内部 idea 收集、初评、跟进人指派、验收 R AI 创新 lab 内部创新负责人（当前：杨萌·推断待确认）
外部创新统筹 外部需求收集、初评、推广转运营 R AI 创新 lab 外部创新负责人（当前：陈梦琪·推断待确认）
子公司提案 按模板提交提案，列需拍板事项 R 子公司负责人（当前：徐莉·推断待确认）
战略意见 子公司、股权、对外合作类事项会签 C COO（当前：常元和·推断待确认）
预算与核算 预算额度核对、费用归集 C 财务负责人（当前：待指定）
提案人 填立项单、试运行、交验收材料 R 提案人（当前：待指定）
项目负责人 试运行推进，每周在立项池更新进度 R 项目负责人（当前：待指定）
人事 按阶段发放积分 R 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 立项单：背景、要解决的问题、目标与验收标准、负责人、所需人力、预算、验证期限
  • 可行性说明：自建/开源/采购/收购的对比，维护人手
  • 合规与风险说明（对外商用、资金、数据类必填）
  • 子公司提案另需：业务打法、分工、阶段目标、资金需求、需拍板事项清单
  • 已有同类项目检索结果（避免重复立项）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板提交立项单/提案 提案人 随时 飞书审批或多维表单 立项单 🔧飞书固化
2 登记入立项池，查重 AI 创新 lab 负责人（内部/外部） 提交后 1 个工作日内 多维表格 立项池记录 🔧+🤖
3 初评并分级：一级=小额试运行；二级=新业务方向/对外商用；三级=子公司授权、股权、融资 AI 创新 lab 负责人、创始人兼 CTO 提交后 24 小时内反馈 多维表格打分 初评结论、级别 👤人工判断
4 一级：创始人兼 CTO 审批预算与资源 创始人兼 CTO 初评后 2 个工作日内 飞书审批 批复 🔧飞书固化
5 二级：CEO 审批，必要时 30 分钟评审会 CEO 初评后 5 个工作日内 飞书审批、会议 批复、评审纪要 👤人工判断
6 三级：董事会会议决策，会前 3 个工作日发提案，当场形成纪要 CEO 主持，COO、创始人兼 CTO 参与 提案后 10 个工作日内开会 飞书会议、妙记 决策纪要 👤+🤖
7 指定负责人、验证期（内部 MVP 1 周、业务闭环 ≤1 个月）和跟进人 审批人 批复当天 飞书任务 立项任务 🔧飞书固化
8 试运行，每周在立项池更新进度 项目负责人 每周五 多维表格、机器人提醒 周进展 🔧+🤖
9 到期验收：可用性、内部使用率、外部推广成效 AI 创新 lab 负责人/审批人 验证期满后 3 个工作日内 多维表格 验收结论 👤人工判断
10 通过的转运营/推广并指定接力人；未通过的终止归档；按阶段发放积分 AI 创新 lab 负责人、人事 验收后 5 个工作日内 多维表格、积分系统 转运营记录、归档、积分 🔧+👤

5. 交付物与模板

  • 交付物：立项单、立项池台账、批复/决策纪要、周进展、验收结论、转运营或归档记录、积分发放记录
  • 建议模板/表单：
    • 立项单字段：项目名称、提案人、类型（内部创新/外部需求/新业务/子公司提案）、背景、目标、验收标准、负责人、人力、预算、验证期限、风险与合规、需拍板事项
    • 立项池多维表格：编号、级别、状态（待评/已批/试运行/验收中/转运营/终止）、负责人、跟进人、截止日期、使用率、积分阶段
    • 子公司提案模板：打法、分工、阶段目标、资金、需决策事项（逐条写"同意/不同意/待定"）

6. 异常与升级

  • 初评超过 24 小时无反馈 → 机器人提醒 → 超过 3 个工作日升级 CEO
  • 子公司提案超过 5 个工作日未回应 → 提案人在董事会群发提醒并申请会议 → CEO 10 个工作日内安排
  • 外部嘉宾来访或签约前仍有未拍板事项 → 来访前 2 个工作日内召开内部对齐会
  • 试运行超预算或超期 → 负责人提交延期/追加申请 → 原审批人 2 个工作日内决定继续或终止
  • 涉及对外商用、资金或数据合规风险 → 必须升为二级以上，并征求法务意见

7. 衡量指标

  • 初评反馈时长 = 提交到初评结论的小时数，目标 ≤ 24 小时
  • 立项单完备率 = 字段齐全的立项单 / 立项总数，目标 100%
  • 子公司提案决策周期 = 提案到形成纪要的工作日，目标 ≤ 10 个工作日
  • 验证期达标率 = 在验证期内完成验收的项目 / 立项数，目标 ≥ 80%
  • 创新转化率 = 转运营/推广的项目数 / 验收项目数（参考：内部使用率 ≥ 20% 视为可用）

8. 低效诊断

  • 现象：新方向的立项与小额预算在群里口头批复，无立项文档、负责人确认和结果评估（立项环节无表单）｜依据：「鸽子群模态分群」2026-02
  • 现象：子公司书面提案多次追问"看了吗"才有回应，决策推迟（审批环节无时限）｜依据：「跃竞模态董事会」2026-03、「跃竞模态董事会」2026-06
  • 现象：拍板结论口头形成，无纪要；外部嘉宾来访前才临时对齐（决策记录环节缺失）｜依据：「跃竞模态董事会」2026-06
  • 现象：小产品负责人更换频繁，"demo 验证→制作"激励不足，"产品包装→转移运营→推广"环节完全没有（后段接力缺失）｜依据：「AI创新lab」2026-04

9. 分支变体

  • 内部小额试运行（如自建 AI 中转/聚合 API）：一级，由创始人兼 CTO 批预算，但对外商用前须升二级并做合规评估
  • AI 创新 lab：内部创新与外部创新分别由两位负责人统筹；有价值的 idea 收束到 skill 制作小组；配月度专项预算与积分
  • 子公司提案（如跃竞）：三级，涉及授权、股权、融资，必须会议决策并形成纪要

10. 待确认问题

  • 一、二级的预算分界额度是多少？一级是否由创始人兼 CTO 审批？
  • 积分制度中的"产品委员会 24 小时内评审"由哪些人组成，与 AI 创新 lab 的初评是否合并？
  • AI 创新 lab 月度专项预算额度和使用审批人是谁？
  • 子公司提案的决策人是 CEO 还是董事会集体？COO 是否必须会签？
  • 转运营后的接力人由运营还是市场负责？
CEO-04重大技术/产品方案决策（拍板、公示与记录）待新建192

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频4 × 耗4 × 跨3 × 险4

  • 适用场景：研发或产品对方案出现分歧（计费归属、职责下发位置、模型选型等），或需要对需求优先级、技术取舍、技术路线与产品方向做决定时启动
  • 负责人：主责——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、方案提出人；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发起决策单 → ② 判定决策级别 → ③ 限时讨论 → ④ 公示或评审会 → ⑤ 拍板 → ⑥ 写决策记录并同步 → ⑦ 测试环境验证后上线 → ⑧ 复议走正式通道
  • 交付结果：决策记录（议题、选项、依据、结论、决策人、生效时间），同步到相关群与决策记录表
  • 状态依据：目前分歧在群里争论，靠负责人一句"就按这个来"收口；2026-08～09 同一需求线上线下说法矛盾，职责下发位置争论多轮，一项配置问题两周未决；公示表决只出现过 1 次且公示内容与异议无留存

1. 场景判定

  • 触发条件：两人以上对方案有不同意见且影响其他模块；涉及计费口径、对外承诺、网关/客户端职责划分；需求优先级或技术路线取舍
  • 典型说法：「别吵了」「就按这个来」「公示期至明早站会前，公示期无异议则全票通过按方案执行」「你们对外同步的信息太少了」「还是跟着成熟经验走，风险小」
  • 判断问题：这个决定改了以后会不会让别的模块返工、改计费口径或改对客户的说法？会，就走本流程；只影响本人代码实现的，由模块负责人自定
  • 不归本流程管：新业务是否立项 → 请走 CEO-03；多项目人力与优先级 → 请走 CEO-07；发版放行 → 请走 RND-51（正式版本发布上线）；Bug 定级 → 请走 RND-03（缺陷提报、复现、分级与指派）；线上质量奖惩 → 请走 HR-19（研发绩效评价与质量奖惩）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
二级决策人 跨模块、计费口径、对外承诺类拍板 A 创始人兼 CTO（当前：丁震宇·推断待确认）
一级决策人 经授权对模块内、单产品线技术方案拍板 R Leap 研发负责人（当前：王皓南·推断待确认）
三级决策人 技术路线、产品方向、开源策略拍板；二级争议裁决 A（升级） CEO（当前：邴龙志·推断待确认）
产品口径 计费归属、需求优先级、产品取舍意见 R 产品总监（当前：杨萌·推断待确认）
风险把关 提出测试与上线风险，验证方案 C 测试负责人（当前：张东郅·推断待确认）
跃竞线决策 经授权对跃竞/跃玩方案公示与拍板 R 跃竞负责人（当前：徐莉·推断待确认）
方案提出人 写决策单、列选项与依据 R 方案提出人（当前：待指定）
相关研发 公示期提异议，按结论执行 I 相关研发/测试

3. 办之前请准备

  • 决策单：议题、背景、至少 2 个选项、每个选项的依据（数据/成熟经验/参考仓库）、影响范围、成本与风险、提出人建议
  • 影响模块与相关负责人名单
  • 涉及计费的：计费口径与归属说明
  • 涉及对客户说法的：对外口径草稿

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 争论超过 2 轮仍无共识时，停止群内争论，填决策单 方案提出人 争议出现当天 多维表格表单 决策单 🔧飞书固化
2 判定级别：一级模块内 / 二级跨模块、计费、对外承诺 / 三级路线与方向 Leap 研发负责人 收到后 4 小时内 多维表格 级别、决策人 👤人工判断
3 限时讨论：相关负责人在决策单下补充意见 相关负责人 一、二级 24 小时内；三级 3 个工作日内 飞书文档评论 意见汇总 👤人工判断
4 一级、二级：公示方案，公示期至次日站会前；三级：召开 30～60 分钟评审会 决策人 讨论结束后 1 个工作日内 群公告、飞书会议 公示记录或评审纪要 🔧+👤
5 拍板：公示无异议视为通过；有异议由决策人当场裁决 决策人 公示期满当天 多维表格 结论 👤人工判断
6 写决策记录并同步到相关群，群聊结论由机器人落表 方案提出人 拍板后 4 小时内 决策记录表、机器人 决策记录 🤖+🔧
7 先在测试环境验证，无问题再上正式 研发、测试 按发布计划 测试服 验证结果 👤人工判断
8 复议：有新证据时提交复议单，原决策人 2 个工作日内答复；无新证据不重开讨论 提出人、原决策人 2 个工作日内 多维表格 复议结论 🔧+👤

5. 交付物与模板

  • 交付物：决策单、公示记录/评审纪要、决策记录、复议记录
  • 建议模板/表单：
    • 决策记录表（ADR）字段：编号、议题、级别、选项与依据、结论、决策人、公示期、异议及处理、生效时间、影响模块、对外口径、复议状态
    • 公示消息模板：方案链接、决策人、公示截止时间、异议提交方式

6. 异常与升级

  • 决策权归属：创始人兼 CTO 为本流程唯一最终决策人（A）；一级事项授权 Leap 研发负责人拍板、跃竞/跃玩事项授权跃竞负责人拍板，结论报创始人兼 CTO 备案，对授权拍板有异议时由创始人兼 CTO 裁决
  • CEO 作为 A（升级）的条件：① 三级事项（技术路线、产品方向、开源策略）；② 二级事项经创始人兼 CTO 裁决后仍有争议；③ 涉及对客户的路线或方向口径
  • 讨论超时仍无共识 → 决策人直接裁决 → 二级仍有争议时 1 个工作日内升级 CEO
  • 决策后执行中出现矛盾说法 → 以决策记录为准 → 方案提出人 4 小时内在群内更正
  • 线下会议结论与线上说法不一致 → 以决策记录为准，补记录 → 决策人当天确认
  • 涉及对客户的路线或方向 → 不在对客户沟通中直接否定客户观点，先内部按三级决策统一口径 → CEO 3 个工作日内定调
  • 决策导致线上问题 → 按研发发布质量机制定级 → 原决策人参与复盘

7. 衡量指标

  • 决策周期 = 争议出现到拍板的工作日，目标：一、二级 ≤ 2 个工作日，三级 ≤ 5 个工作日
  • 决策记录率 = 有决策记录的重大决策数 / 重大决策总数，目标 100%
  • 重复争议率 = 已决议题被无新证据重新讨论的次数，目标 0
  • 决策返工次数 = 因决策变更导致的返工次数 / 月，目标逐月下降

8. 低效诊断

  • 现象：同一需求线下会与线上说法矛盾、反复变更，执行方反映对外同步信息太少（决策同步环节缺记录）｜依据：「Leap产研测」2026-08
  • 现象：某职责应由网关还是客户端下发争论多轮（级别判定与决策人不明确）｜依据：「Leap产研测」2026-08
  • 现象：一项模型配置问题约两周未决，最后才定方案并先上测试服（无讨论时限）｜依据：「Leap产研测」2026-09
  • 现象：结论只留在群聊，后续有人再次质疑，需要重新解释（缺决策记录与复议规则）｜依据：「Leap产研测」2026-08
  • 现象：公示表决只做过 1 次，公示内容与异议无留存（公示规则未成文）｜依据：「跃玩项目组」2026-04、「跃玩项目组」2026-06

9. 分支变体

  • 研发间方案分歧（计费归属、网关/客户端职责、模型选型）：一级或二级，公示后拍板
  • 跃竞/跃玩：由跃竞负责人发布方案并公示至次日站会前，无异议即通过；倾向采用成熟经验
  • 技术路线与产品方向（对客户的路线说法、开源策略、生态方向、预研方向）：三级，评审会决策，定期同步给团队

10. 待确认问题

  • 一、二、三级的决策人是否如上划分？一级是否由 Leap 研发负责人决策？
  • 公示期"至次日站会前"是否在全公司推行？
  • 决策记录表放在哪个空间，由谁维护？
  • 技术路线类决策是否需要定期（如每月）向全研发同步？
  • 跃竞线是否单独维护决策记录？
CEO-05决策授权与汇报路径（去单点、防越级）待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：需要明确哪些事由各负责人自行决定、哪些须报 CEO/COO，以及资源、权限、技术类问题"找谁"、跨主体或高层需求如何传达时启动；也用于新负责人任命后的授权书面化
  • 负责人：主责——CEO（当前：邴龙志·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、总经办（当前：待指定）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 盘点高频问题与决策事项 → ② 制定授权矩阵与"找谁"清单 → ③ 书面任命各组负责人 → ④ 发布并配置问答机器人 → ⑤ 按"结论+依据"汇报 → ⑥ 跨主体需求按入口传达 → ⑦ 每季度复核
  • 交付结果：授权矩阵（事项×决策层级）、问题分类"找谁"清单、各组负责人书面任命、一页纸汇报模板、跨主体需求传达路径说明
  • 状态依据：授权全靠口头，被指定的负责人不知道自己被授权；2026-03 资源、账号、客户技术问题集中到一人，出现"严重单点阻塞"约 10 次；2026-04 汇报层级与口径不统一；2026-07 出现外部主体高层需求越级传达

1. 场景判定

  • 触发条件：同一类问题反复找同一位高管；任命新的组长/负责人；有人不确定某事能否自己决定；外部主体或高层直接向非对口人员提需求
  • 典型说法：「公司里是个人就跟我对东西」「别啥事都找我」「你给他很多东西他就不爱看了」「很多事你们直接决策就行」「有需求也应该正常按我们公司的流程来汇报」
  • 判断问题：这件事在授权矩阵里属于哪一级？"找谁"清单里有没有对口人？有就直接找对口人，没有才走本流程补充
  • 不归本流程管：具体方案的拍板过程 → 请走 CEO-04；组织架构与汇报线调整 → 请走 CEO-06；资金类审批额度与付款审批 → 请走 FIN-01（对公采购申请与付款审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
授权制定 审定授权矩阵与负责人任命 A CEO（当前：邴龙志·推断待确认）
授权起草 起草研发、产品、资源类授权与"找谁"清单 R 创始人兼 CTO（当前：丁震宇·推断待确认）
经营类授权 商务、定价、合同、对外口径类授权意见 C COO（当前：常元和·推断待确认）
被授权负责人 在授权范围内自行决策并定期汇报 R 产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
发布与维护 发布清单、维护机器人、季度复核提醒 R 总经办（当前：待指定）
员工 按清单找对口人，按模板汇报 I 全员

3. 办之前请准备

  • 近 1 个月找高管的问题清单（按账号资源、商务技术答疑、项目进度、预算采购、对外口径分类）
  • 现有各组/项目负责人名单
  • 例会与汇报的现行做法（谁汇报给谁、频次、形式）
  • 跨主体（鼎慧、跃竞、子公司）对接人名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 盘点高频问题与决策事项，按类别统计找谁、耗时 总经办 启动后 5 个工作日内 多维表格 问题盘点表 🤖+🔧
2 起草授权矩阵：L1 组长自决 / L2 部门负责人决策 / L3 报 CEO 或 COO 创始人兼 CTO、COO 盘点后 5 个工作日内 飞书文档 授权矩阵草案 👤人工判断
3 起草"找谁"清单：账号资源→IT 运维；商务技术答疑→FDE/项目负责人；项目进度→项目经理；预算采购→部门负责人 创始人兼 CTO 同步完成 飞书文档 找谁清单 👤人工判断
4 审定并书面任命各组负责人，写明授权范围，本人确认 CEO 草案后 3 个工作日内 飞书文档、群公告 任命通知 👤人工判断
5 发布并配置问答机器人自动回复"找谁" 总经办 审定后 2 个工作日内 群机器人 机器人上线 🔧+🤖
6 汇报规范：给高管的汇报用"结论+依据+需决策事项"一页纸，先与直属上级对稿 汇报人 每次汇报前 飞书文档模板 一页纸汇报 🔧飞书固化
7 例会：会前 1 个工作日填例会信息；半数以上缺席时改期并当天通知 会议组织人 会前 1 个工作日 飞书文档、日程 例会信息 🔧飞书固化
8 跨主体/高层需求：由对口产品负责人接收，进需求流程，同时抄送总经办知情；不越级直接改产品 对接人 收到需求当天 需求表单、群 需求登记 🔧飞书固化
9 季度复核授权矩阵与清单，根据单点问题调整 总经办发起，CEO 审定 每季度第 1 周 飞书文档 新版授权矩阵 👤人工判断

5. 交付物与模板

  • 交付物：授权矩阵、"找谁"清单、负责人任命通知、一页纸汇报模板、跨主体需求传达路径说明
  • 建议模板/表单：
    • 授权矩阵字段：事项类别、示例、决策层级（L1/L2/L3）、决策人岗位、需知会对象、时限
    • "找谁"清单字段：问题类别、典型说法、对口岗位、兜底岗位、办之前请准备
    • 一页纸汇报：结论、关键数据（统一口径，如 P95）、依据、风险、需决策事项、截止时间

6. 异常与升级

  • 被授权人不确定是否在授权范围内 → 先按矩阵自行判断并执行，事后 1 个工作日内知会上级 → 涉及 L3 的仍须事前报批
  • 对口人不在岗 → 找兜底岗位 → 兜底也不在时升级到部门负责人（4 小时内）
  • 有人绕过对口人直接找高管 → 高管转回对口人并抄送清单链接 → 同一问题重复出现 2 次以上，在季度复核中补充清单
  • 跨主体高层需求已越级传达 → 接收人当天转对口产品负责人并告知总经办 → 有争议时报 CEO
  • 汇报中指标口径不一 → 以汇报模板规定口径为准 → 汇报人重新提交

7. 衡量指标

  • 高管单点问题量 = 每周直接找创始人兼 CTO/CEO 的资源、权限类问题数，目标 3 个月内下降 50%
  • 授权覆盖率 = 书面任命并确认的负责人数 / 实际负责人数，目标 100%
  • 自决比例 = L1/L2 事项中由被授权人直接决策的比例，目标 ≥ 80%
  • 越级需求次数 = 跨主体或高层越级传达次数 / 月，目标 0

8. 低效诊断

  • 现象：组长授权只口头说过，被指定者不知道自己是负责人（任命环节未书面化）｜依据：「鼎慧产研决策部」2026-03
  • 现象：资源对接、账号开通、客户技术答疑都由同一位高管兜底，出现"严重单点阻塞"（缺"找谁"清单与项目经理角色）｜依据：「鼎慧产研决策部」2026-03
  • 现象：授权后仍不敢自行决策，反复回头确认（授权边界不清）｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-04
  • 现象：给高管的汇报材料过多不被阅读，指标口径（P50/P95）不统一；例会因多人缺席取消（汇报规范缺失）｜依据：「鼎慧产研决策部」2026-04
  • 现象：外部主体高层需求越级传达给公司高管，产品负责人事后才知道（跨主体需求入口缺失）｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 账号资源类：按"找谁"清单找 IT 运维/云资源负责人
  • 商务技术答疑类：找 FDE 或项目负责人，高管仅处理 L3 事项
  • 项目进度类：由项目经理汇总，不直接向高管逐个询问
  • 跨主体（鼎慧、跃竞、子公司）：对方高层需求经对口产品负责人进入需求流程，同步总经办

10. 待确认问题

  • 授权矩阵的 L1/L2/L3 划分标准由谁定稿？金额类事项如何分级？
  • 是否设立项目经理岗位承接项目进度类问题？
  • "找谁"机器人由总经办还是 IT 维护？
  • 产研向高管汇报，是直接报 CEO/COO，还是也可以报市场销售负责人？
  • 跨主体需求的对口人是否统一为产品总监？
CEO-06组织架构、汇报线与职责边界调整待优化240

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：新业务、新团队、新人加入或主体合并，需要重新划分部门、负责人、直属上级、职责边界或用工主体，并同步飞书时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定架构）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、飞书管理员（当前：待指定）、财务负责人（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提出调整需求 → ② 起草架构与职责边界 → ③ 限时审阅定版 → ④ 影响评估（主体/审批/权限/群/考勤）→ ⑤ 发布通知（生效、交接、反馈截止）→ ⑥ 收集反馈修正 → ⑦ 飞书同步 → ⑧ 用工主体迁移 → ⑨ 30 天复盘
  • 交付结果：定版组织架构图与人员架构表、职责边界 RACI 表、调整通知、飞书组织架构/直属上级/审批代理/部门群同步完成、人员主体台账更新
  • 状态依据：已有组织架构 wiki、人员信息表与 2026-07 一次规范的调整通知（含生效、交接、反馈截止）；但同年 03～09 架构定版拖延、部门归属争议约 10 次，合同主体与实际团队不一致，飞书部门架构不准，职责边界多次口头划分

1. 场景判定

  • 触发条件：新设/撤并/更名部门；更换负责人或直属上级；组建 FDE、独立项目等编组；主体合并或劳动关系迁移；新职能出现后团队间职责不清
  • 典型说法：「先得通知一下，不是飞书组织的问题」「从组织架构上来讲，他向谁汇报」「合同情况和实际架构情况不一致」
  • 判断问题：调整后是否改变了某人的直属上级、所属部门、用工主体或团队职责？任一项改变就走本流程
  • 不归本流程管：短期跨部门借调与外派 → 请走 CEO-08；项目间人力优先级 → 请走 CEO-07；个人入转调离手续 → 请走 HR-05（新员工入职准备与办理）/ HR-25（人员调岗、借调与汇报线确认）/ HR-27（员工离职办理与交接）；客户侧组织架构导入 → 请走 X-DLV-15（客户组织、账号开通与额度充值）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
架构决策 拍板部门划分、负责人、汇报线 A CEO（当前：邴龙志·推断待确认）
研发与经营意见 审阅研发编组、业务编组 C 创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
方案整理与落地 整理架构表、拟通知、收反馈、推动飞书同步与主体迁移 R 人事负责人（当前：黄莹·推断待确认）
主体与制度梳理 梳理合同主体、制度适用、档案 R 综合部负责人（当前：赵雪冰·推断待确认）
飞书设置 组织架构、直属上级、审批流、部门群、权限 R 飞书管理员（当前：待指定）
发薪与社保主体 核对发薪、社保、费用归属 C 财务负责人（当前：待指定）
部门负责人 确认本部门人员与职责，组织交接 R 各部门负责人（当前：待指定）
员工 知悉变化，按期提交反馈 I 全员

3. 办之前请准备

  • 调整原因与范围（新业务/新团队/主体合并/职责冲突）
  • 现行组织架构表与人员信息表（含直属上级、用工主体、社保、发薪主体、实际团队）
  • 新架构草案：部门、负责人、直属上级、子部门显示名称
  • 职责边界 RACI 草案（新职能必填）
  • 受影响的审批流、权限、群、考勤规则清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提出调整需求，写明原因和范围 发起人（CEO/部门负责人） 随时 飞书审批"组织调整申请" 调整申请 🔧飞书固化
2 起草架构表与职责 RACI，全员填入架构表 人事负责人 申请后 3 个工作日内 飞书 wiki、多维表格 架构草案、RACI 🔧+👤
3 审阅定版：CEO、创始人兼 CTO、COO 在文档内批注，限时 1 轮 CEO 定版 草案后 3 个工作日内 飞书文档评论 定版架构 👤人工判断
4 影响评估：逐项核对审批代理、权限、部门群、考勤、用工主体 人事负责人、飞书管理员、财务负责人 定版后 2 个工作日内 变更清单 影响清单 🔧飞书固化
5 发布通知：部门更名/负责人/新设部门、生效日期、交接期、反馈截止 CEO 发布，人事起草 定版后 2 个工作日内 通知群、反馈表单 调整通知 🔧飞书固化
6 收集反馈并修正，部门负责人当面向成员说明 人事负责人、部门负责人 通知后 2 个工作日内截止反馈 飞书表单 反馈处理结果 👤人工判断
7 完成交接与团队磨合 部门负责人 通知后 4 个工作日内 飞书任务 交接记录 👤人工判断
8 飞书同步：组织架构、直属上级、审批代理人、部门群自动拉人、权限 飞书管理员 通知后 6 个工作日内 飞书管理后台（可批量导入） 飞书设置完成 🔧+👤
9 用工主体迁移：合同、社保、发薪主体变更，更新人员主体台账 人事负责人、财务负责人 生效当月发薪前 人员主体台账 主体台账 🔧飞书固化
10 生效 30 天后复盘：审批是否走错、职责是否仍有争议 人事负责人 生效后 30 天 飞书文档 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：组织架构图、人员架构表、职责 RACI 表、调整通知、反馈处理记录、飞书变更记录、人员主体台账、复盘记录
  • 建议模板/表单：
    • 组织调整变更清单：飞书组织架构、直属上级、审批流与代理人、权限、部门群、考勤规则、用工主体、发薪主体、社保主体，每项含负责人与完成状态
    • 人员主体台账字段：姓名、实际团队、直属上级、合同主体、社保主体、发薪主体、变更日期
    • 调整通知模板：调整内容、生效日期、交接截止、飞书设置完成日期、反馈表单与截止时间

6. 异常与升级

  • 审阅超过 3 个工作日未定版 → 人事负责人提醒 → 升级 CEO，2 个工作日内拍板
  • 部门负责人空缺 → 指定临时代理人（审批、外出、财务审批都会经过此人）→ CEO 当天指定
  • 合同主体与实际团队不一致 → 记入主体台账 → 综合部负责人 10 个工作日内给迁移方案，CEO 确认
  • 两团队职责边界争议 → 按 RACI 表裁决 → 无法裁决时 5 个工作日内由 CEO 拉会划分
  • 飞书设置未按期完成导致审批走错 → 飞书管理员当天修正 → 由人事负责人通报

7. 衡量指标

  • 架构定版周期 = 提出申请到定版的工作日，目标 ≤ 6 个工作日
  • 飞书同步及时率 = 通知后 6 个工作日内完成飞书设置的调整次数 / 总次数，目标 100%
  • 主体一致率 = 合同主体与实际团队一致的人数 / 总人数，目标 ≥ 95%（差异须有台账说明）
  • 归属争议数 = 生效后 30 天内的部门归属/职责争议次数，目标 ≤ 1
  • 审批错配次数 = 因直属上级未同步导致的审批走错次数，目标 0

8. 低效诊断

  • 现象：架构方案多轮审阅，定版拖延较长（审阅环节无时限）｜依据：「模态人事大主管」2026-07
  • 现象：员工不知道架构已变化，部门归属反复争议（通知环节缺失）｜依据：「模态人事大主管」2026-07
  • 现象：部门负责人空缺时审批代理人未定，团队管理混乱（影响评估环节缺代理人检查）｜依据：「模态人事大主管」2026-07
  • 现象：编组时"谁来统筹"不清，先定人还是先定方向反复讨论（汇报线未写入方案）｜依据：「鼎慧产研决策部」2026-05
  • 现象：飞书部门架构不准，改组织靠个人用高权限工具操作，部门群没用起来（飞书同步环节无专人）｜依据：「鼎慧产研决策部」2026-07
  • 现象：合同主体与实际团队不一致，决策以"先这样，出问题再调"收尾（主体迁移无步骤）｜依据：「综合&总经招聘考核沟通」2026-09
  • 现象：新职能出现后部门间职责边界不清，需另行等待高层划分（职责 RACI 缺失）｜依据：「董事会」2026-10

9. 分支变体

  • FDE/独立项目编组：先定方向再定人，明确统筹人和汇报对象后再发通知
  • 主体合并与劳动关系迁移（武汉模态、鼎慧、苏州模态、深圳模态、跃竞）：必须走第 9 步，财务参与
  • 职能变化后的职责边界（如运维与开发、对外职能）：只出 RACI 表，不一定改架构
  • 外包人员：不划分部门，只登记对接负责人

10. 待确认问题

  • 主责是否为人事负责人？飞书管理员是谁（目前多人有管理员操作）？
  • 审阅时限 3 个工作日、飞书同步 6 个工作日是否可行？
  • 架构变更是否需要走飞书审批？审批人是 CEO 还是董事会？
  • 子部门是否在飞书上显示，显示规则谁定？
  • 用工主体迁移的制度适用（各主体规章）由综合部还是人事负责？
CEO-07多项目优先级与人力分配待优化400

状态：待优化｜证据：有证据（卡片 9 张 / 会话 6 个）｜优先级：频5 × 耗4 × 跨5 × 险4

  • 适用场景：多个客户项目、新业务、内部产品同时推进，同一批人被多线抢占，或有人手头项目结束无人安排、商务/政府需求不断涌入时启动
  • 负责人：主责——研发资源协调人（当前：丁震宇·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售/商务负责人（当前：刘昱潇·推断待确认）、各项目负责人（当前：待指定）、人事负责人（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 需求统一入口并准入评分 → ② 每周资源盘点 → ③ 周优先级会排序 → ④ 发布周分工 → ⑤ 成员先写 plan 再开工 → ⑥ 插单走变更 → ⑦ 周五进度汇报 → ⑧ 缺口走外包或招聘
  • 交付结果：项目池（含优先级 P0/P1/P2）、项目×人员占用看板、每周分工公告、变更记录、周进度汇报
  • 状态依据：已有过周分工清单和一张梳理任务的多维表格；但 2026-02～09 排序与派活仍靠关键人临场判断，同一人被多线拉取、"人呢/进展如何"类催问约 20 次，商务需求无准入，大项目并行时只能临时找人或招人

1. 场景判定

  • 触发条件：同一人同时承担 2 条以上主线；新项目/新需求进来需要人；某项目结束有人闲置；部门间抢人
  • 典型说法：「没让你多线作战」「现在同时并发的项目有点多，我得想办法给你们指定清楚」「不要啥都等我去问进度」「商务侧不要啥需求都丢进来」「没人可以协调，只能招人」「渠道版最靠后，opc 最优先」
  • 判断问题：这件事是否需要调整某人当前的工作安排或项目先后顺序？需要，就走本流程
  • 不归本流程管：周期目标制定 → 请走 CEO-01；新业务是否立项 → 请走 CEO-03；跨部门借人/技术外派审批 → 请走 CEO-08；长期编制和汇报线调整 → 请走 CEO-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资源协调 主持周优先级会、发分工、处理插单 R 研发资源协调人（当前：丁震宇·推断待确认）
最终裁决 跨部门优先级冲突（产品/运营/大会/商务）裁决 A CEO（当前：邴龙志·推断待确认）
产品口径 产品需求优先级、项目池维护 R 产品总监（当前：杨萌·推断待确认）
研发排期 评估工时、可用人力 C Leap 研发负责人（当前：王皓南·推断待确认）
商务需求提报 按准入表提需求、梳理 To do R 销售/商务负责人（当前：刘昱潇·推断待确认）
项目负责人 拆任务、写 plan、周五汇报 R 各项目负责人（当前：待指定）
招聘 承接人力缺口招聘 C 人事负责人（当前：待指定）
成员 按分工执行，主动汇报阻塞 I 研发、FDE、测试

3. 办之前请准备

  • 项目池：在途项目、客户、阶段、截止日期、合同/交付承诺
  • 人员占用表：每人当前项目、占用比例、下一个空档时间
  • 新需求准入表：客户类型、收益、客户价值、所需人力、截止日期
  • 上周分工与进度汇报
  • 请求最少包含字段（新需求准入）：需求名称、提出人岗位、客户类型与阶段、是否有合同或对客承诺、所需角色与人天、截止日期及理由、建议替换掉的在途事项；缺项退回，不进项目池

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新需求填准入表进入项目池，按收益/客户价值/人力评分 需求提出人（商务/产品） 需求出现后 1 个工作日内 多维表格表单 待排期需求（项目池多维表格条目，含评分） 🔧飞书固化
2 周一资源盘点：更新人员占用，标出超载（>2 条主线）和闲置人员 项目负责人填，协调人汇总 每周一 10:00 前 多维表格看板 占用看板（多维表格，标出超载/闲置；缺报→机器人提醒） 🔧+🤖
3 周优先级会：按"先保客户交付→再凝练行业版→再提开放平台/标品需求"排 P0/P1/P2；稳定项目冻结只修严重 bug 协调人主持，产品、研发、商务参加 每周一，≤30 分钟 飞书会议 优先级排序（项目池 P0/P1/P2 字段 + 会议纪要） 👤人工判断
4 发布本周分工：项目、负责人、本周目标、DDL 协调人 会后 2 小时内 群公告、机器人 分工公告（部门群公告置顶 + 机器人推送各负责人） 🔧+🤖
5 负责人先写 plan（任务拆解、依赖、风险），再开工 项目负责人 分工后 1 个工作日内 飞书文档/任务 plan（飞书文档，链接挂项目池；超时→部门负责人） 👤人工判断
6 周中插单：提出人说明要替换哪项，协调人决定；被抽调人列出手头活并交接 提出人、协调人 当天决定 多维表格变更记录 变更记录（多维表格，通知被抽调人与原项目负责人） 🔧+👤
7 周五进度汇报：状态、阻塞、下周计划，机器人收集 项目负责人 每周五 18:00 前 机器人、多维表格 周进度（多维表格，机器人汇总推送协调人） 🤖自动化
8 闲置人员安排：协调人提 2～3 个选项，部门负责人确认 协调人、部门负责人 闲置后 2 个工作日内 群/文档 新分工（更新占用看板 + 群公告） 👤人工判断
9 人力缺口：评估外包或招聘，提交需求 协调人、人事负责人 缺口确认后 3 个工作日内 飞书审批 外包任务单/招聘需求（飞书审批，编号回写项目池） 🔧+👤

5. 交付物与模板

  • 交付物：项目池、人员占用看板、周分工公告、plan、插单变更记录、周进度汇报、招聘/外包需求
  • 建议模板/表单：
    • 项目池字段：项目名、类型（客户交付/行业版/标品/内部）、客户（脱敏代号）、优先级、负责人、成员、截止日期、状态、阻塞
    • 人员占用表字段：姓名、所属组、项目及占比、下次空档、本周目标
    • 准入评分表字段：客户类型、预期收益、客户价值、所需人天、截止日期、是否有合同、评分

6. 异常与升级

  • 同一人被分到 3 条以上主线 → 协调人当天调整 → 无法调整时报 CEO 决定取舍
  • 产品、运营、大会、商务抢同一批人 → 周优先级会裁决 → 跨部门无法裁决时 1 个工作日内报 CEO；借出人员写明归还时间
  • 商务/政府需求未经准入直接派给研发 → 研发可拒绝并要求补准入表 → 争议报 CEO
  • 推进会被市场议题占满 → 市场会与推进会分开开 → 主持人当场叫停并另约
  • 成员超过 1 个工作日未汇报阻塞 → 机器人提醒 → 项目负责人跟进
  • 外部伙伴/外包任务进度失控 → 项目负责人 1 个工作日内重设 DDL → 协调人决定是否收回
  • 周一 10:00 前项目负责人未更新占用 → 机器人提醒 → 协调人按上周数据排会，缺报负责人会上说明
  • 分工公告超会后 2 小时未发 → 产品总监代发草稿 → 协调人当天确认
  • plan 超 1 个工作日未提交 → 协调人催办 → 升级部门负责人（第 2 个工作日）
  • 问进度一律先查占用看板与周进度表，看板缺失再 @项目负责人（建议）

7. 衡量指标

  • 多线率 = 同时承担 >2 条主线的人数 / 总人数，目标 ≤ 10%
  • 周分工准时率 = 周一 12:00 前发布分工的周数 / 总周数，目标 100%
  • 主动汇报率 = 周五按时提交进度的项目数 / 在途项目数，目标 ≥ 90%
  • 插单次数 = 每周优先级会之外插入的任务数，目标逐月下降
  • 交付准时率 = 按承诺日期交付的客户项目数 / 到期项目数，目标 ≥ 85%

8. 低效诊断

  • 现象：排序与派活依赖关键人临场判断，研发与非研发的上下文都要其调度（协调环节单点）｜依据：「⭐大模型基座事业群」2026-03
  • 现象："人呢""进展如何"类催问大量出现，授权后仍不敢自行决策（进度汇报环节缺机制）｜依据：「⭐大模型基座事业群」2026-03
  • 现象：同一人被多条新业务线同时拉取，反复追问"到底先弄哪个"，当事人要求产品来管流程（任务池与排序缺失）｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：多个大客户项目同时压上来，反复问谁能做，最终只能招人（资源盘点环节缺失）｜依据：「客户项目群（半导体）」2026-06、「客户项目群（半导体）」2026-09
  • 现象：商务/政府需求不加筛选进入研发，推进会被市场议题占满（需求准入环节缺失）｜依据：「鼎慧产研决策部」2026-03
  • 现象：产品、运营、大会抢人，优先级随高层口头变化（跨部门裁决环节缺失）｜依据：「鼎慧产研决策部」2026-05
  • 现象：项目结束后人员无人安排（闲置盘点缺失）｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 大客户交付项目并行（半导体、水利、燃气、特殊行业等）：先保合同交付，研发/FDE/硬件三类人手分开盘点
  • 基座组新业务并行（OPC、NAS、LeapCore、ClawLite、MercAll）：要求先写 plan，周末节点拆分
  • 同一产品多版本并行（如 OPC 版、自助版、U 盘渠道版）：按版本排序，渠道版最后
  • 行业版项目（如投资人版）：同时宣布技术负责人、研发负责人、Skill 负责人、项目经理
  • 协作协议：遵循 ALL-03（决策记录与发布）、ALL-05（会议发起、纪要与待办闭环）、ALL-06（卡点升级阶梯）、ALL-09（状态看板与进度同步）

10. 待确认问题

  • 研发资源协调人是否继续由创始人兼 CTO 兼任？是否设专职项目经理/PMO？
  • 周优先级会放在周一是否可行？哪些人必须参加？
  • "一人不超过 2 条主线"作为硬规则是否可行？
  • 商务需求准入评分由谁打分，研发是否有否决权？
  • 外包与招聘的审批人分别是谁？
CEO-08跨部门人员借调与技术人员外派审批待新建108

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：其他部门需要临时借用本部门人员，或商务需要技术/FDE 人员去客户现场、参加对外会议，涉及优先级冲突与差旅成本时启动
  • 负责人：主责——借出部门负责人（当前：研发线 丁震宇、FDE/开放平台 郭逸非·推断待确认）；协同——需求发起人（商务/销售，当前：刘昱潇·推断待确认）、被借调/外派人员、行政（差旅预订，当前：待指定）、财务（差旅费用，当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发起人与技术先对齐可行性 → ② 提交借调/外派申请 → ③ 借出部门负责人审批 → ④ 冲突时升级 → ⑤ 差旅预订 → ⑥ 定会议角色并执行 → ⑦ 纪要回传 → ⑧ 归还确认
  • 交付结果：已审批的借调/外派单（目的、人员、时间、成本、DDL）、会议/外勤纪要、归还确认
  • 状态依据：目前无借调或外派审批单；2026-06 当天临时加会、技术人员被"突击"，会议分工群里临时定；2026-09 有负责人绕过部门负责人直接调人外勤，导致专班进度延误；已有人提出要规范职能流程但未成文

1. 场景判定

  • 触发条件：需要非本部门人员投入 ≥ 半天；技术/FDE 人员去客户现场或参加对外会议；需要出差
  • 典型说法：「喊我去开会得先经负责人同意再说」「我们这边的事情当然是部门优先项」「别让技术突击，每次给个 DDL」「以后再有这种事要先找部门负责人」「尽可能飞书说，微信只当随口」
  • 判断问题：要用的人是不是别的部门的？是否会占用其原本的项目时间或产生差旅费用？是，就走本流程
  • 不归本流程管：长期调岗、编制调整 → 请走 CEO-06；项目间人力优先级 → 请走 CEO-07；差旅报销 → 请走 FIN-06（日常费用报销提交与审核）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批 评估本部门优先级，同意/驳回/改派 A 借出部门负责人（当前：丁震宇（研发）、郭逸非（FDE/开放平台）·推断待确认）
发起 先与技术对齐可行性，填申请，给 DDL R 需求发起人（当前：刘昱潇·推断待确认）
执行 按批准内容外派/支援，回传纪要 R 被借调/外派人员（当前：待指定）
差旅支持 订票住宿 C 行政（当前：待指定）
费用核算 差旅成本核对与报销 C 财务（当前：待指定）
冲突裁决 跨部门优先级冲突裁决 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 目的与客户情况（客户以代号写）、需要的技术角色
  • 时间、地点、预计时长、线上/线下
  • 会议议程与分工（谁主持、谁讲方案、谁答疑）
  • 差旅成本估算（交通、住宿）
  • 已与技术人员对齐过的可行性结论与 DDL

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 与拟借调的技术人员对齐可行性，给出每项任务的 DDL 需求发起人 申请前 飞书消息（不用微信） 可行性结论 👤人工判断
2 提交借调/外派申请：目的、人员、时间、地点、成本、议程与分工 需求发起人 线下外派提前 ≥ 2 个工作日；线上会议提前 ≥ 1 个工作日 飞书审批 申请单 🔧飞书固化
3 借出部门负责人评估本部门优先级，同意/驳回/改派他人 借出部门负责人 收到后 1 个工作日内（线上会议 4 小时内） 飞书审批 审批结论 👤人工判断
4 与本部门项目冲突无法协调时升级 借出部门负责人 审批时限内 飞书审批加签 裁决 👤人工判断
5 预订交通住宿，费用计入对应项目 行政 审批后 1 个工作日内 差旅平台 行程单 🔧飞书固化
6 会前确认议程与角色（主持、方案讲解、答疑），发日程 需求发起人 会前 1 个工作日 飞书日程、议程模板 会议议程 🔧飞书固化
7 执行外派/会议，结束后回传纪要与待办 被外派人员 结束后 1 个工作日内 飞书文档 纪要、待办 🤖+👤
8 借调结束，借出部门负责人确认人员归还，更新人员占用看板 借出部门负责人 结束当天 多维表格 归还确认 🔧飞书固化

5. 交付物与模板

  • 交付物：借调/外派审批单、行程单、会议议程、纪要与待办、归还确认
  • 建议模板/表单：
    • 借调/外派审批单字段：发起人、借出部门、人员、类型（借调/现场外派/对外会议）、客户代号、目的、开始/结束时间、地点、议程与角色、差旅预算、对原项目影响、归还时间、审批人
    • 对外会议议程模板：会议目标、客户参会人角色、我方主持、方案讲解、技术答疑、时长、会后待办

6. 异常与升级

  • CEO 作为 A（升级）的条件：借出部门负责人与发起方对本部门项目冲突无法协调；借出部门负责人驳回但业务确需；借调超期 2 个工作日仍未归还；同一发起人每月临时加会超过 2 次。其余情况由借出部门负责人（A）审批定案
  • 当天临时加会 → 发起人电话/飞书先征得借出部门负责人同意 → 24 小时内补审批单；同一发起人每月临时加会超过 2 次，报 CEO
  • 绕过部门负责人直接找人 → 被找人员先引导发起人找部门负责人 → 未经审批的外勤不计入工作安排
  • 借出部门负责人驳回但业务确需 → 发起人 1 个工作日内报 CEO 裁决
  • 外派期间原项目出现紧急问题 → 被外派人员当天告知部门负责人 → 部门负责人决定远程处理或改派
  • 借调超期未归还 → 借出部门负责人提醒 → 超期 2 个工作日报 CEO

7. 衡量指标

  • 审批覆盖率 = 走审批的借调/外派次数 / 实际发生次数，目标 100%
  • 提前申请率 = 按规定提前量申请的次数 / 总次数，目标 ≥ 85%
  • 审批时长 = 提交到审批结论的小时数，目标 ≤ 8 个工作小时
  • 原项目延误次数 = 因借调/外派导致原项目延误的次数 / 月，目标 0
  • 纪要回传率 = 结束后 1 个工作日内回传纪要的次数 / 总次数，目标 ≥ 90%

8. 低效诊断

  • 现象：其他负责人绕过部门负责人直接调人外勤，被调人员同时承担外勤、学校事务与专班任务，专班进度延误（审批环节缺失）｜依据：「FDE培训班专班沟通群」2026-09
  • 现象：当天临时加会，技术人员被"突击"，没有 DDL（提前申请环节缺失）｜依据：「客户项目群（半导体）」2026-06
  • 现象：会议由谁主持、谁答疑在群里临时分配（议程与角色环节缺失）｜依据：「客户项目群（半导体）」2026-06
  • 现象：事项先在微信沟通，飞书留痕不全（沟通渠道不统一）｜依据：「客户项目群（半导体）」2026-06

9. 分支变体

  • 线上会议：提前 1 个工作日申请，审批 4 小时内，无差旅
  • 线下客户现场：提前 2 个工作日申请，需差旅预算
  • 客户高层汇报会 vs 技术答疑会：前者由商务主持、技术负责人讲方案；后者由技术人员主答
  • FDE 部门成员借调：部门项目优先，须经 FDE 部门负责人同意

10. 待确认问题

  • 研发线外派审批人是否仍为创始人兼 CTO，是否可下放到各组负责人？
  • 线下外派提前 2 个工作日、线上会议提前 1 个工作日是否可行？
  • 是否在飞书审批中新建"借调/外派"审批流，与出差审批合并还是分开？
  • 差旅成本计入项目还是部门？
  • FDE 部门负责人目前是谁（多人被称为 FDE 负责人）？
CEO-09项目启动与重大事项跨组对齐会待优化144

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：新项目启动、客户需求突变，或与供应商/客户谈判前，需要把产研、市场、基座组拉齐目标、分工、里程碑与对外话术时启动。
  • 负责人：主责——项目负责人/发起人（当前：丁震宇·推断待确认）；协同——项目管理/产品协调（当前：杨萌·推断待确认）、商务负责人（当前：李鹏为·推断待确认）、研发执行负责人（当前：杨明学、杨云峰·推断待确认）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 判定需对齐 → ② 建日程并发会议通知 → ③ 会前材料就位（谈判分支备目标价/底线/话术）→ ④ 会上定目标、分工、选型、里程碑 → ⑤ 纪要与决议登记 → ⑥ 各人登记里程碑 → ⑦ 会后变更同步 → ⑧ 周期进度同步
  • 交付结果：启动会/对齐会纪要、决议登记（目标、分工、里程碑、对外口径）、里程碑文档、谈判对齐单（谈判分支）、周期进度同步日程。
  • 状态依据：已有会议通知文本、智能纪要助手、里程碑 wiki（任务-交付-准出结构），但参会名单靠临时 @、结论靠群转发、会后需求被改下游不知情；03～04 月约 8 次；谈判前对齐 06～07 月出现约 3 次，均为临时拉会、无模板。

1. 场景判定

  • 触发条件：新项目确定启动；客户需求出现方向性变化；与供应商或客户进行价格/条款谈判前；涉及 2 个及以上部门的重大事项需要统一口径。
  • 典型说法：「明天先拉对齐会，把产研和市场拉对齐」「参与项目的今天中午整理一下自己的里程碑节点」「每次跟供应商开会之前应该先拉产研对齐」「我们自己先对明白」
  • 判断问题：这件事是否需要两个以上部门共同承担？是否会改变目标、范围、排期或对外口径？如果不开会，下游是否会按旧口径继续做？
  • 不归本流程管：要不要立项、是否拍板 → 请走 CEO-03；研发内部立项与分工 → 请走 RND-05；客户侧交付启动会 → 请走 X-DLV-09；例行周会 → 请走 CEO-11；普通会议的会议室与纪要 → 请走 CEO-10；供应商询价与签约本身 → 请走 X-OTH-01 / X-DLV-02。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 判定开会、定议程、会上拍分工与优先级 A 项目负责人（当前：丁震宇·推断待确认）
会务与跟进 发通知/日程、登记决议、拉进度同步会、跟进待办 R 项目管理/产品协调（当前：杨萌·推断待确认）
最终决策 目标与范围最终拍板；会后改需求须触发变更同步 C COO（当前：常元和·推断待确认）
商务口径 谈判前提供目标价、底线、对方诉求，会上定主谈人 R（谈判分支） 商务负责人（当前：李鹏为·推断待确认）
研发执行 提供技术可行性、成本、工期；登记里程碑 C 研发执行负责人（当前：杨明学、杨云峰·推断待确认）
相关部门代表 会前读材料、会后按分工执行 I 各部门负责人（当前：待指定）
纪要机器人 自动生成会议纪要 — 智能纪要助手

3. 办之前请准备

  • 一句话目标与背景（客户痛点、需求变化点、谈判对象诉求）。
  • 参会名单：按“受影响就必须邀请”列出，含远程参会人；写明哪些人无需参加。
  • 会议资料链接（方案、架构图、目前进展），会前至少 2 小时发出。
  • 谈判分支：目标价、可接受底线、成本测算、新机型/配置清单、对方上次诉求、我方主谈人与技术答复人。
  • 里程碑模板（参考已有 LeapCore MileStone：阶段—关键任务—交付文档—准出标准）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定需开对齐会，确定议程与必邀人员 发起人 触发后 4 小时内 群消息 议程草案、参会名单 👤人工判断
2 建飞书日程（含会议室/视频会议），在项目群发通知（主题/时间/地点/参会人/议程/资料链接） 会务与跟进 会前至少 1 个工作日；紧急对齐会至少提前 2 小时 飞书日程、通知模板 日程邀请、群通知 🔧飞书固化
3 谈判分支：整理目标价、底线、让步顺序、话术与人员分工 商务负责人 + 研发执行 谈判前 1 个工作日 谈判对齐单 谈判对齐单 👤人工判断
4 开会：定目标、分工、技术选型、排期；谈判分支定主谈人与禁说事项 发起人主持 30～60 分钟 线下会议室/飞书会议 会上结论 👤人工判断
5 纪要自动生成；会务人提取“决议/待办/责任人/DDL”写入决议登记表并发项目群 会务与跟进 会后 2 小时内 智能纪要助手、多维表格 纪要、决议登记 🔧+🤖
6 各参与人按模板登记个人里程碑节点 研发执行及各参与人 会后 1 个工作日内 飞书 wiki 里程碑模板 里程碑文档 🔧飞书固化
7 会后目标/需求变更：提出人通知会务人，更新登记表并 @ 全部受影响人 最终决策人 / 会务与跟进 变更当天 项目群、多维表格 变更记录 🔧+🤖
8 建周期进度同步日程，按里程碑跟进，转入项目组例会 会务与跟进 会后 2 个工作日内 飞书日程 进度同步会 🔧飞书固化

5. 交付物与模板

  • 交付物：会议通知、会议纪要、决议登记、里程碑文档、谈判对齐单（谈判分支）。
  • 建议模板/表单：
    • 会议通知：主题、时间、地点/会议链接、必邀人、无需参加人、议程（1～5 项）、资料链接。
    • 决议登记表（多维表格）：项目、会议日期、决议内容、责任人、DDL、状态、变更内容、变更提出人、变更通知时间。
    • 谈判对齐单：谈判对象（匿名编号）、日期、我方目标价、底线、让步顺序、主谈人、技术答复人、禁说事项、会后结论。
    • 里程碑登记：阶段、关键任务、交付文档、准出标准、负责人、计划日期。

6. 异常与升级

  • 关键参会人未到场超过 10 分钟 → 会务人电话/飞书加急 → 仍未到则相关结论标“待确认”，会后 1 个工作日内单独补对。
  • 受影响人员漏邀 → 会务人会后 2 小时内补发纪要并 @ 本人；同一项目重复漏邀 → 升级发起人。
  • 会后需求被改但未同步 → 发现人当天告知会务人 → 会务人补发变更通知；已造成返工 → 1 个工作日内升级 COO。
  • 谈判前未完成内部对齐 → 商务负责人申请推迟，或本次只听取不承诺 → 谈判前升级发起人。

7. 衡量指标

  • 提前通知率 = 提前 ≥1 个工作日发通知的对齐会 / 对齐会总数，目标 ≥ 80%。
  • 决议登记及时率 = 会后 2 小时内完成登记的会议 / 总数，目标 ≥ 90%。
  • 未同步变更次数 = 每月发现的“会后变更未通知下游”次数，目标 0。
  • 谈判前对齐覆盖率 = 有谈判对齐单的谈判 / 谈判总数，目标 100%。

8. 低效诊断

  • 现象：参会名单靠临时 @，受影响人员被漏邀，会后才知道结论｜依据：「LeapCore（archived）」2026-03
  • 现象：远程参会人多次叫不到，需要反复催促，会议推迟开始｜依据：「LeapCore（archived）」2026-03
  • 现象：会上分工与结论靠群消息转发，没有固定落点；会后需求被修改，下游不知情导致返工｜依据：「LeapCore（archived）」2026-03、「LeapCore（archived）」2026-04
  • 现象：对外谈判前几小时才临时拉内部会，谁定目标价、谁说话术不清｜依据：「LeapCore（archived）」2026-06、「LeapCore（archived）」2026-07

9. 分支变体

  • 临时速对站会：当晚或数小时内召开，可省资料，但纪要和决议登记不可省。
  • 正式项目启动会：有议程、资料、日程，必须产出里程碑文档。
  • 供应商/客户谈判前对齐会：必须产出谈判对齐单，商务负责人为执行人。
  • 周期进度同步：启动后按周召开，转入 CEO-11 项目组例会管理。

10. 待确认问题

  • 启动会组织人默认是项目发起人还是项目管理岗？无专职项目经理时由谁兜底？
  • 会后改需求是否必须走 X-PRD-29 需求变更控制，由提出人发起变更通知？
  • 谈判前对齐是对所有供应商谈判强制，还是仅限重要谈判？阈值如何定？
  • 决议登记表放在哪个多维表格/知识库空间，由谁维护？
  • LeapCore MileStone 的“任务-交付-准出”结构是否定为公司里程碑标准模板？
CEO-10会议召集、会议室预约与纪要归档待优化60

状态：待优化｜证据：有证据（卡片 6 张 / 会话 3 个）｜优先级：频5 × 耗2 × 跨3 × 险2

  • 适用场景：任何内部或对外会议需要确定参会人、时间地点、会议室/视频会议，并在会后产出、分发和归档纪要时启动。
  • 负责人：主责——会议组织者（谁发起谁负责；产研侧当前常见：杨萌·推断待确认）；协同——行政（会议室规则与冲突协调，当前：待指定）、飞书管理员（机器人权限，当前：丁震宇·推断待确认）、转述人（当前：王皓南·推断待确认）、全体参会人；兜底——综合部负责人
  • 核心流程：① 确认会议五要素 → ② 预约会议室 → ③ 建日程并发通知与材料 → ④ 参会人接受并预读 → ⑤ 开会并开启纪要 → ⑥ 纪要校对、待办转任务 → ⑦ 归档
  • 交付结果：带议程、材料、会议室的飞书日程；会议纪要（含待办/责任人/DDL）；知识库归档链接。
  • 状态依据：已有飞书日程、固定会议室、智能纪要助手（06 月稳定产出纪要），但会议信息靠群转述、会议室冲突、机器人代建日程出现日期和参会人错误、部分会议无纪要、纪要无人跟进待办；01～08 月反复出现约 25 次。

1. 场景判定

  • 触发条件：3 人及以上参加的内部会议；对外会议（云厂商、合作方、客户）；领导临时要求开会；会议需要纪要留档。
  • 典型说法：「领导说明天开个会」「所有人吗？时间地点呢？」「谁在用会议室」「帮我开个日历事件，明天上午 10 点跟某云厂商聊」「怎么没有纪要」「怎么能让所有会议自动产生纪要」
  • 判断问题：这次会议是否占用他人时间、需要会议室或需要留纪要？参会人是否都已在飞书日程中收到邀请？
  • 不归本流程管：会议室日常使用规范 → 请走 ADM-05；面试会议室与候选人接待 → 请走 ADM-07；来访接待 → 请走 GEN-16；例会节奏与议程 → 请走 CEO-11；项目启动/谈判前对齐 → 请走 CEO-09；高管外部约见 → 请走 CEO-18；机器人日历权限申请 → 请走 X-SEC-33。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
会议组织者 确认要素、约会议室、建日程、发材料、校对与分发纪要 R/A 会议发起人（产研侧当前：杨萌·推断待确认）
转述人 领导口头发起时，先确认要素再通知 R 部门负责人（当前：王皓南·推断待确认）
行政 会议室预约规则、冲突裁定、设备保障 C 行政（当前：待指定）
飞书管理员 机器人日历/会议权限审批 C 飞书管理员（当前：丁震宇·推断待确认）
关键决策人 需拍板的会议提前确认时间并到场 C COO（当前：常元和·推断待确认）
参会人 接受日程、会前预读、准时到场 I 全体参会人（如：宋祺睿等）
机器人 代建日程、自动生成纪要 — NK AI、智能纪要助手

3. 办之前请准备

  • 会议五要素：主题、时间（日期＋星期＋时刻）、地点或视频链接、必参人与无需参加人、议程。
  • 会议室空闲情况（在飞书会议室页面查询）。
  • 会前材料链接，并标注“请会前阅读”。
  • 需要纪要的会议：确认使用飞书会议或开启纪要/妙记，并确认参会人有查看权限。
  • 对外会议：对方单位与对接人、我方主谈人、对外口径（见 SAL-10）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到口头开会要求，当场向发起领导确认参会范围、时间、地点、议程 转述人/组织者 收到后 1 小时内 飞书消息/电话 确认后的会议要素 👤人工判断
2 查询并预订会议室；无空闲则改时段或改线上 组织者 会前至少 4 小时；例会按周期预订 飞书会议室预订 会议室占用记录 🔧飞书固化
3 建飞书日程：邀请全部必参人、挂会议室、写议程和材料链接；机器人代建的须回读核对日期、星期和参会人 组织者（或 NK AI） 会前至少 1 个工作日；临时会至少提前 1 小时 飞书日程、NK AI 日程邀请 🔧+🤖
4 在相关群发会议通知，@ 必参人，写明无需参加人 组织者 与日程同时 群通知模板 群通知 🔧飞书固化
5 接受日程并预读材料；不能参加的指定替代人并回复 参会人 会前 飞书日程 回执 👤人工判断
6 开会：确认关键人到场，开启纪要 组织者 开始后 5 分钟内 飞书会议、智能纪要助手 录制与纪要 🤖自动化
7 校对纪要，提取待办（事项/责任人/DDL）建飞书任务，纪要发群 组织者 会后 4 小时内 飞书任务、群 校对后纪要、任务 🔧+🤖
8 纪要归档到对应项目/部门知识库目录 组织者 会后 1 个工作日内 飞书知识库 归档链接 🔧飞书固化

5. 交付物与模板

  • 交付物：飞书日程（含会议室）、群通知、会议纪要、待办任务、归档链接。
  • 建议模板/表单：
    • 会议通知：【会议通知】主题｜时间（YYYY-MM-DD 周X HH:MM–HH:MM）｜地点/链接｜必参｜无需参加｜议程｜会前请阅读：链接。
    • 纪要：会议信息、结论、待办（事项/责任人/DDL）、待确认事项、附件。
    • 机器人代建日程核对清单：日期与星期是否一致、时区、参会人是否齐全、会议室是否挂上、议程是否写入。

6. 异常与升级

  • 会议室冲突 → 后预订者让出或改线上；双方不让 → 行政 30 分钟内按规则裁定。
  • 关键决策人未到场 → 组织者 10 分钟内联系；无法到场则改期或改为信息同步会，不做决策。
  • 机器人缺日历权限 → 组织者先手工建日程，同时按 X-SEC-33 申请权限，管理员 1 个工作日内处理。
  • 已接受的邀请在日历中不显示 → 组织者重发邀请；仍异常 → 报飞书管理员。
  • 会后无纪要 → 组织者 1 个工作日内手工补写要点并发群。

7. 衡量指标

  • 会议要素完整率 = 日程含议程和必参人的会议 / 抽查会议数，目标 ≥ 90%。
  • 会议室冲突次数 = 每月因冲突临时换房或改期的次数，目标 ≤ 2 次。
  • 纪要覆盖率 = 有纪要的正式会议 / 正式会议数，目标 ≥ 95%。
  • 待办转任务率 = 纪要中待办被建成飞书任务的比例，目标 ≥ 90%。

8. 低效诊断

  • 现象：领导口头发起的会议靠群内转述，参会范围、时间、地点要二次确认｜依据：「鼎慧产研决策部」2026-01
  • 现象：机器人代建日程出现日期错、漏邀请，且因日历权限未开需等审批｜依据：「鼎慧产研决策部」2026-06
  • 现象：会议室各自约、常冲突，临开会才换房；关键决策人未到会议开不了｜依据：「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-08
  • 现象：部分会议未开纪要，事后找不到记录；纪要发出后无人跟进待办，同样问题在聊天中反复问｜依据：「鼎慧产研决策部」2026-05、「Leap产研测」2026-06
  • 现象：已接收的会议邀请不在日历中显示，迭代会被漏｜依据：「鼎慧产研决策部」2026-08

9. 分支变体

  • 领导临时发起：必须先确认要素再通知，禁止只转述“明天开个会”。
  • 机器人代建（NK AI）：机器人建完后组织者回读核对，核对通过才算完成步骤 3。
  • 对外会议：日程注明对方单位与对接人，会前确认我方口径。
  • 面试/客户/内部会：纪要归档目录不同（面试纪要随候选人档案，按 X-RCT-12）。
  • 会前预读：材料较长的会议，参会人须会前阅读，会上不逐页讲解。

10. 待确认问题

  • 会议室预约规则（提前多久、单次最长时长、冲突优先级）由行政还是总经办制定？
  • 是否全公司默认开启飞书会议自动纪要？纪要统一归档到哪个知识库目录？
  • NK AI 代建日程是否作为推荐方式？其权限由谁审批、谁维护？
  • 会前预读是否写入正式规范（材料提前多久发、未读如何处理）？
  • 产研与市场在对外会议中的分工（产研出成本与排期、定价与案例演示归市场）是否需单独成文？
CEO-11周例会与项目组例会待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：公司经营例会、部门例会、项目组周例会/月度会/专题会等按固定周期召开、需要各方会前填报并跟进重点待办的会议。
  • 负责人：主责——例会组织者（公司经营例会：总经办，当前：赵雪冰·推断待确认；产研/项目推进周会：当前：杨萌·推断待确认；平台部/教育组例会：当前：陈梦琪·推断待确认；市场销售例会：销售负责人，当前：李鹏为·推断待确认）；协同——各部门负责人/部门代表、纪要与督办（当前：韩诗琪、闫登辉·推断待确认）、汇报分层制定（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 投票后固定周期并建重复日程 → ② 会前 1 个工作日建本期文档并提醒 → ③ 各部门按模板填报 → ④ 会前催填 → ⑤ 会上先过上期待办再分层汇报 → ⑥ 纪要与本期重点待办发布 → ⑦ 待办转任务跟踪
  • 交付结果：本期例会文档（各部门汇报＋上期待办进展）、会议纪要、本期重点待办清单（责任人＋DDL）。
  • 状态依据：各层级例会已形成节奏，有共享文档、纪要机器人，部分组通知模板稳定；但公司例会 07 月多次延期改期，市场例会时间周一→周五反复调整，例会文档创建时间不固定、需反复催填，子部门归口不清，01～08 月约 50 次相关消息。

1. 场景判定

  • 触发条件：每周固定例会日前 1 个工作日；月度/季度节点；业绩或关键指标明显偏离需统一思路；新增重点任务需统一分工。
  • 典型说法：「什么时候创建这周的周会文档」「请各位参考会前共享文档完善本部门汇报内容」「每周开一次全员的会，同步下结论」「每个部门有一位同事参加即可」「周一全员在公司开会，统一思想，统一工作流程」
  • 判断问题：这是固定周期、多部门或全组参加、以同步进展和跟进待办为主的会吗？
  • 不归本流程管：研发每日站会/CR 会 → 请走 RND-09；迭代站会 → 请走 X-PRD-30；日报/周报填报 → 请走 CEO-12；临时会议的会议室与纪要 → 请走 CEO-10；年度/季度规划 → 请走 CEO-01；项目启动对齐 → 请走 CEO-09。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
例会组织者 定周期、建日程与文档、催填、主持、发布待办 R/A 总经办（当前：赵雪冰·推断待确认）；产研/项目组（当前：杨萌·推断待确认）；平台部（当前：陈梦琪·推断待确认）；市场销售（当前：李鹏为·推断待确认）
汇报分层制定 确定统一周期性汇报与非强制汇报的范围 C CTO（当前：丁震宇·推断待确认）
部门负责人/代表 会前填报、会上汇报、领取待办 R 各部门负责人/代表（当前：葛家和、杨朋伟、吴琪、王皓南、李宣昊、黄飞鹏·推断待确认）
纪要与督办 整理纪要和待办清单，会后跟进 R 销售支持（当前：韩诗琪、闫登辉·推断待确认）；其他例会由组织者兼任
CEO 经营例会决策、目标纠偏 A（升级） CEO（当前：邴龙志·推断待确认）
机器人 自动生成纪要 — 智能纪要助手

3. 办之前请准备

  • 本期例会文档（由模板复制）：一、各部门本周进展；二、下周计划/卡点/需支持；三、上期重点待办进展。
  • 上期纪要和重点待办清单。
  • 部门数据：CRM 过程指标、回款、迭代进度等（按部门）。
  • 会议室/视频会议预订（见 CEO-10）。
  • 需决策事项清单，提前标注，会上优先讨论。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 投票确定例会周期后固定，建飞书重复日程，邀请必参人或部门代表 组织者 周期确定后 1 个工作日内；如需变更提前 1 个工作日 飞书投票、飞书日程 重复日程 🔧飞书固化
2 用模板创建本期例会文档，按部门/产研分区，发群并 @ 填写人 组织者（或机器人） 例会前 1 个工作日 12:00 前 飞书知识库模板、机器人 本期文档 🔧+🤖
3 各部门在本部门分区填写进展、卡点、需支持和上期待办状态；用 AI 写入前确认不覆盖他人分区 部门负责人/代表 例会前 1 个工作日 18:00 前 飞书文档、DailyWork 周报 填报内容 🔧+🤖
4 检查未填部门并提醒 组织者 例会当天开会前 2 小时 机器人提醒 催填记录 🤖自动化
5 开会：先过上期重点待办，再按分层汇报（统一周期性 → 非强制周期性），最后讨论需决策事项 组织者主持 30～60 分钟 会议室/飞书会议 会上结论 👤人工判断
6 整理纪要和本期重点待办（事项/责任人/DDL），发群并建飞书任务 纪要与督办 会后 4 小时内 智能纪要助手、飞书任务 纪要、待办清单 🔧+🤖
7 跟踪待办，下期会前更新状态 纪要与督办 每周，下期会前 1 个工作日 飞书任务/多维表格 待办状态 🔧飞书固化

5. 交付物与模板

  • 交付物：重复日程、本期例会文档、纪要、重点待办清单。
  • 建议模板/表单：
    • 例会文档：部门、汇报人、本周完成、进行中（进度%）、卡点/风险、需支持（需要谁/做什么）、下周计划、上期待办状态。
    • 例会通知：【周例会通知】时间、地点/链接、预计时长、议题、需提前准备的材料及负责人。
    • 重点待办清单：编号、事项、责任人、DDL、状态、来源会议。

6. 异常与升级

  • 例会组织者为各层级例会的唯一负责人（A）；CEO 作为 A（升级）的条件：公司经营例会上需拍板的经营决策与目标纠偏；同一例会单月改期 ≥ 2 次需重新确定固定时间；子部门参会与归口争议组织者无法裁定。
  • 例会需改期 → 组织者至少提前 1 个工作日改日程并发群；同一例会单月改期 ≥ 2 次 → 升级兜底人重新确定固定时间。
  • 关键人无法参加 → 指定代理人汇报；无代理 → 该部门书面汇报，会后 1 个工作日内单独补对。
  • 部门未按时填报 → 组织者提醒一次；仍未填 → 会上口头汇报，纪要记“未填报”。
  • AI 误改他人内容 → 立即用文档历史版本恢复，并通知受影响人。
  • 子部门是否参会、由谁归口不清 → 兜底人 1 周内确定汇报分层名单。

7. 衡量指标

  • 准时召开率 = 按原定时间召开的例会 / 计划例会，目标 ≥ 90%。
  • 会前填报率 = 截止前完成填报的部门 / 应填部门，目标 ≥ 95%。
  • 重点待办按期完成率 = 按 DDL 完成的待办 / 到期待办，目标 ≥ 80%。
  • 纪要发布时效 = 会议结束到纪要发布的小时数，目标 ≤ 4 小时。

8. 低效诊断

  • 现象：团队会议多而分散、信息差大，全员同步会迟迟未定时间｜依据：「鼎慧产研决策部」2026-02
  • 现象：项目组会议时间一次会议内改动 3 次｜依据：「平台部」2026-02
  • 现象：每次例会需人工发文档链接、@ 填写人；日程忘拉参会人；会议室被占需临时换｜依据：「字字可研项目群」2026-03、「字字可研项目群」2026-04
  • 现象：周会文档创建时间不固定，填写人需追问；AI 改写误删他人内容需修复｜依据：「鼎慧产研决策部」2026-04
  • 现象：部门例会时间周一 → 周五 → 临时挪动，需要反复重新“划清工作边界”；会后待办靠人工整理｜依据：「【模态】市场销售」2026-05、「【模态】市场销售」2026-07
  • 现象：公司例会多次延期或改期，需投票重新定时间；子部门是否参会、由谁归口不清｜依据：「【模态】业务负责人」2026-07

9. 分支变体

  • 公司经营例会（总经办组织）：各部门负责人参加；汇报分两类——统一周期性汇报（核心产品与业务）、非强制周期性汇报（FDE、子公司、顾问）。
  • 市场销售例会（部门级，周五下午试运行）：基于 CRM 同步重大工作、卡点、需支持；季度/半年节点开专题会，要求每人提交工作思路与计划。
  • 产研全员周同步会：同步结论与分组，紧急事项另开会。
  • 平台部/教育组：周例会、月度深度会、专项会，提前一天发通知并同步日程。
  • 工程小组项目推进周会：固定周五下午，各部门派一名代表，约半小时；节假日提前或改线上。
  • 负责人晨会：如管理层要求每日上午召开，按重复日程固化。

10. 待确认问题

  • 公司经营例会固定时间是否已确定（原周一 10 点冲突多）？
  • “统一周期性汇报”与“非强制周期性汇报”的部门名单是否已明确？
  • 各层级例会是否统一一个文档模板，还是允许部门自定义？
  • 例会文档是否由机器人每周自动创建？机器人由谁维护？
  • 是否用 CEO-12 的周报自动汇总生成例会材料，替代会前手工填报？
  • 产研周会与研发站会（RND-09）的边界如何划分？
CEO-12日报/周报（DailyWork）与周期汇报待优化225

状态：待优化｜证据：有证据（卡片 13 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨5 × 险3

  • 适用场景：员工每日/每周提交工作汇报，经部门/项目组汇总后同步给管理层；含冲刺期、居家办公期的加强汇报。
  • 负责人：主责——综合部负责人（汇报制度与 DailyWork 推行，当前：赵雪冰·推断待确认）；协同——总经办（通知与指引，当前：王欣·推断待确认）、开放平台（工具技术支持，当前：郭逸非·推断待确认）、LeapCore 适配研发（当前：岳阳·推断待确认）、部门/项目组汇总人（当前：杨萌、陈梦琪、葛家和、陈震·推断待确认）、全体员工；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 系统每日生成草稿 → ② 本人核对确认 → ③ 未确认提醒 → ④ 部门日报汇总 → ⑤ 周报生成与确认 → ⑥ 部门/侧周报汇总 → ⑦ 周五周报群同步 → ⑧ 周统计与例会材料
  • 交付结果：已确认的个人日报/周报、部门日报/周报、周报群同步记录、每周提交率统计与未提交名单。
  • 状态依据：08 月已上线 DailyWork、操作指引和反馈表，平台部有技术/产品/运营三套周报模板和汇总人；但试用期使用人数不足 17 人、依赖个人 Codex 额度、授权权限多引发顾虑、是否强制及与积分挂钩未定；各组周报格式不一、靠人工催办，02～10 月持续出现。

1. 场景判定

  • 触发条件：每个工作日结束；每周五；项目冲刺期或居家办公期管理者宣布加强汇报；新人入职需纳入汇报。
  • 典型说法：「定时任务只生成和推送草稿，不会自动确认」「周报填一下吧」「大家记得每周的周报在这里同步」「每人每天在群内汇报工作内容、工作进度」「小日报记得发一下」「市场要写日报的，研发无所谓」
  • 判断问题：这是按日/按周、面向上级或跨组的常规进展汇报吗？
  • 不归本流程管：销售日报与汇报保密 → 请走 SAL-32；研发团队内部进展同步细则 → 请走 RND-10；市场运营日报 → 请走 MKT-18（市场运营日报与沟通记录规范）；行政日报 → 请走 ADM-13；卡点/关键节点即时上报 → 请走 CEO-14；阶段总结 → 请走 CEO-13；积分激励规则 → 请走 HR-18。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
制度与推行 定提交要求、截止时间、是否强制及与积分挂钩；每周统计使用率 A 综合部负责人（当前：赵雪冰·推断待确认）
通知与指引 发布试用/正式通知，维护操作指引 R 总经办（当前：王欣·推断待确认）
工具支持 DailyWork 故障与需求处理、权限最小化、迁移 LeapCore R 开放平台（当前：郭逸非·推断待确认）；LeapCore 适配（当前：岳阳·推断待确认）
员工 核对并确认草稿，补充系统抓不到的内容 R 全体员工
汇总人 生成部门/侧日报周报，检查未确认人员；不得代员工确认 R 部门/项目组负责人（当前：杨萌、陈梦琪、葛家和、陈震·推断待确认）
冲刺期跟进人 每日检查汇报、识别风险 R（冲刺期） 冲刺期负责人（当前：黄飞鹏、王满·推断待确认）
管理层 查阅、追问风险 I/C CEO（当前：邴龙志·推断待确认）；CTO（当前：丁震宇·推断待确认）
机器人 生成草稿、推送、汇总 — DailyWork/飞书小助手、NK AI

3. 办之前请准备

  • DailyWork 已按操作指引完成安装和绑定（飞书工作台入口、定时任务、时区）。
  • 授权范围确认：本人任务、工作群有效 @ 消息、会议、云文档；不授权非工作会话。
  • 当天系统抓不到的内容：线下拜访、Gitea 提交、外部沟通结果。
  • 对应周报模板（技术/产品/运营三套）。
  • 冲刺期：当日完成、进行中、风险三项。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 系统生成个人日报草稿并推送本人 DailyWork 每个工作日 17:00 DailyWork、飞书小助手 日报草稿 🤖自动化
2 核对、补充系统抓不到的内容并点击确认 员工 当日下班前（18:00 前）；当日外勤未归的次日 09:30 前补确认 DailyWork 已确认日报 👤人工判断
3 推送未确认名单给本人和汇总人 机器人 次日 09:30 飞书机器人 未确认提醒 🤖自动化
4 生成部门日报，标注风险与需支持事项 汇总人 次日 10:00 前 DailyWork 部门日报 部门日报 🔧+🤖
5 系统汇总已确认日报生成个人周报草稿，员工确认 员工 周五 15:00 前 DailyWork 个人周报 🤖+👤
6 按模板形成部门/侧周报，附工单与文档链接 汇总人 周五 17:00 前 飞书汇报、周报模板 部门周报 🔧+🤖
7 部门周报同步到高管周报群，附 3 行摘要（做了什么/计划/需决策） 汇总人 周五 18:00 前 高管周报群 周报同步 🔧飞书固化
8 统计提交率/确认率，发未提交名单；汇总材料供下周例会 综合部 每周一 12:00 前 汇总看板 周统计、例会材料 🤖自动化

5. 交付物与模板

  • 交付物：个人日报/周报、部门日报/周报、高管群周报同步、周统计表。
  • 建议模板/表单：
    • 个人日报：今日完成、进行中（进度%）、明日计划、需配合事项、风险。
    • 技术周报：开发任务（已完成：按模块附工单链接、Bug 修复数及典型问题；进行中：工单、进度%、预计完成）、其他贡献（面试、协作支持、技术/流程优化、文档）、下周计划。
    • 产品周报：产品核心工作（需求分析/设计/排期；进行中进度%与预计完成）、协作支持、其他事项，每项附文档/原型链接。
    • 运营周报：工作内容（聚焦事项、完成情况、卡点风险）、工作安排（计划、完成时间、潜在风险）、需协调资源（需要谁、做什么）。
    • 周统计表：部门、应交人数、已确认人数、确认率、未确认名单。

6. 异常与升级

  • DailyWork 故障或额度用完 → 员工当日改用飞书汇报/模板手写提交，并填反馈表 → 开放平台 1 个工作日内响应。
  • 授权权限过多引发顾虑 → 开放平台说明每项权限用途并收缩到最小集，2 周内完成。
  • 员工连续 2 个工作日未确认 → 汇总人提醒；连续 1 周 → 报部门负责人（是否计入积分待规则确认）。
  • 冲刺期汇报出现进度风险 → 跟进人当天 @ 项目负责人，按 CEO-14 上报。
  • 部门周报周五 18:00 前未同步 → 综合部次周一 10:00 前提醒，汇总人当日 12:00 前补交并记为迟交；同一部门当月第二次迟交报兜底人。

7. 衡量指标

  • 日报确认率 = 当周已确认日报 / 应交日报，目标 ≥ 90%。
  • DailyWork 覆盖率 = 完成安装并连续使用 1 周的人数 / 应用范围人数，目标 ≥ 95%。
  • 周报准时同步率 = 周五 18:00 前同步的部门 / 应同步部门，目标 ≥ 90%。
  • 人工催办次数 = 每周群内催交消息数，目标降至 ≤ 2 条/周。

8. 低效诊断

  • 现象：飞书汇报只在截止前提醒，不在开始时提醒；谁写、交给谁、研发是否写口径不一｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：小日报需每期追问才发；周报要求恢复、取消变化频繁｜依据：「平台部」2026-02、「平台部」2026-04
  • 现象：日报要求发出后不久就无人再发，缺少检查机制｜依据：「【模态】业务负责人」2026-04
  • 现象：周报需反复催写，模板忘记新建需他人代建；内容靠人转述给 AI 再填，填错栏需返工｜依据：「鼎慧产研决策部」2026-05
  • 现象：各组周报格式不一，管理层难以一目了然看进展｜依据：「鼎慧产研决策部」2026-05、「【跃迁】高管群」2026-05
  • 现象：日报系统拉取消息范围过大引发隐私顾虑，授权权限多｜依据：「鼎慧产研决策部」2026-07、「模态跃迁通知群」2026-08
  • 现象：工具依赖个人 Codex 额度，额度用完无法生成；使用人数少、组长无规范要求、是否强制未定｜依据：「模态跃迁通知群」2026-08、「董事会专项沟通群」2026-08
  • 现象：日报 skill 效果一般，反馈后无迭代回应｜依据：「跃迁AI总动员」2026-08
  • 现象：冲刺期每日汇报靠群内长消息，漏发需点名，无汇总｜依据：「工程咨询产研」2026-10

9. 分支变体

  • 个人日报/周报 vs 部门日报/周报：部门负责人只能在授权范围生成汇总，不能代员工确认。
  • 市场/销售日报：可替代外勤报备，含拜访对象和明日计划（细则见 SAL-32）。
  • 研发日报：是否强制存在分歧（待确认）；可用 DailyWork 草稿＋工单链接替代手写。
  • 平台部三侧：技术侧、产品侧、运营侧分别交各侧汇总人，汇总后上交。
  • 居家办公期：每日下班前群内小日报，取消周中报。
  • 冲刺期：每人每日汇报内容、进度和风险，指定跟进人每日检查，可配合补贴激励。
  • Leap 项目周报：NK AI 汇总各侧填写并提醒负责人。
  • 跨项目组：周五在高管周报群同步，核心产品与业务文档在群内备份。

10. 待确认问题

  • DailyWork 是否全员强制使用？研发是否必须写日报？
  • 与积分激励、晋升挂钩的具体规则和生效时间？
  • DailyWork 何时从 Codex 迁移到 LeapCore？迁移前额度不足如何保障？
  • 授权权限最小集是什么？是否明确排除所有非工作会话？
  • 部门周报截止统一为周五 18:00（个人周报 15:00、部门汇总 17:00）是否可行？
  • 高管周报群同步的部门范围和统一模板由谁确定？
CEO-13阶段总结与工作计划收集待新建36

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨3 × 险2

  • 适用场景：长假前、项目阶段结束或周期末，管理者要求个人与团队负责人提交阶段总结和下一阶段工作计划时启动。
  • 负责人：主责——发起管理者/产研负责人（当前：杨萌·推断待确认）；协同——团队负责人（当前：王皓南、张东郅·推断待确认）、各模块负责人、全员；兜底——上一级部门负责人
  • 核心流程：① 定周期、范围、截止日 → ② 发通知与模板 → ③ 个人填写 → ④ 团队负责人汇总团队总结 → ⑤ 到期提醒 → ⑥ 审阅与退回 → ⑦ 1v1 交流 → ⑧ 汇总归档、行动项转任务
  • 交付结果：个人阶段总结与计划、团队总结、汇总结论、1v1 记录、下一阶段行动项。
  • 状态依据：09～10 月产研线发起过阶段总结收集，有群通知但无模板、无固定周期；出现“写的不是总结和计划”“团队总结怎么写”等口径问题，每次临时组织。

1. 场景判定

  • 触发条件：长假前；阶段任务或项目里程碑结束；季度/半年末；管理者要求书面回顾与计划。
  • 典型说法：「请大家于某日提交个人阶段总结和下一阶段工作计划」「研发测试负责人要包含团队内容」「怎么写团队总结」
  • 判断问题：是否要求全员/全组在同一截止日提交“回顾＋计划”的书面材料？
  • 不归本流程管：公司年度总结与 1v1 面谈 → 请走 HR-21；试用期转正考核 → 请走 HR-08；目标制定与分解 → 请走 CEO-01；项目/活动复盘 → 请走 CEO-16；周报 → 请走 CEO-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 定周期、范围、截止日；发通知和模板；审阅；组织 1v1 A/R 产研负责人（当前：杨萌·推断待确认）
团队负责人 提交个人总结并汇总团队总结 R Leap 研发负责人/测试负责人（当前：王皓南、张东郅·推断待确认）
员工 按模板填写个人总结与计划 R 全员（含在本组工作的其他组同事）
人事 需与考核挂钩时介入；结果归档 C 人事（当前：待指定）

3. 办之前请准备

  • 本阶段目标/OKR、里程碑记录、周报（可由 DailyWork 周报汇总）。
  • 个人版与负责人版模板。
  • 提交范围名单（含跨组成员）与请假人员安排。
  • 收集表（多维表格）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定周期、提交范围、截止日 发起人 截止日前至少 10 个自然日 — 安排 👤人工判断
2 发正式通知（群公告）＋模板链接＋收集表 发起人 决定后 1 个工作日内 群公告、飞书文档模板、多维表格 通知 🔧飞书固化
3 按模板填写个人总结与计划（可先由 AI 从周报生成回顾草稿） 员工 截止日 18:00 前 飞书文档、DailyWork 个人总结 🤖+👤
4 汇总团队总结（问题、表现、管理与工作方式优化） 团队负责人 截止日 18:00 前 负责人版模板 团队总结 🤖+👤
5 截止前 2 个工作日及当天提醒未提交者 机器人 截止前 2 个工作日、截止日 10:00 多维表格提醒 提醒 🔧飞书固化
6 审阅；不符合要求的（如写成方案而非总结）退回并说明 发起人 截止后 3 个工作日内 文档评论 审阅意见 👤人工判断
7 1v1 交流 发起人 截止后 10 个工作日内（遇长假为节后首周） 飞书日程 1v1 记录 👤人工判断
8 汇总共性问题与下一阶段计划，归档；行动项建任务 发起人 1v1 完成后 3 个工作日内 飞书知识库、飞书任务 汇总结论、任务 🔧+🤖

5. 交付物与模板

  • 交付物：个人总结、团队总结、汇总结论、1v1 记录、行动项任务。
  • 建议模板/表单：
    • 个人版：阶段回顾（目标、完成情况、量化结果）、存在问题、工作表现自评、个人成长、管理或工作方式优化建议、下一阶段计划（事项/目标/时间）、需要的支持。
    • 负责人版：个人版＋团队总结（团队目标完成、主要问题、成员表现概述、协作与流程改进、下一阶段团队计划）。
    • 收集表：姓名、团队、类型（个人/负责人）、文档链接、提交时间、审阅状态、1v1 时间。

6. 异常与升级

  • 请假/出差无法按时 → 提前向发起人报备，最长顺延 5 个工作日。
  • 内容不符合要求 → 发起人 3 个工作日内退回，员工 2 个工作日内重交。
  • 超期 3 个工作日未交 → 报其上级负责人。
  • 跨组成员归属不清 → 发起人与其所属组负责人当天确认由谁收。

7. 衡量指标

  • 按时提交率 = 截止日前提交人数 / 应提交人数，目标 ≥ 95%。
  • 一次通过率 = 未被退回的提交 / 总提交，目标 ≥ 85%。
  • 1v1 完成率 = 完成 1v1 人数 / 应完成人数，目标 100%。
  • 行动项按期完成率 = 按期完成行动项 / 到期行动项，目标 ≥ 80%。

8. 低效诊断

  • 现象：先口头宣布，正式通知与模板滞后；提交范围需另行补充说明｜依据：「Leap产研决策部」2026-09、「Leap产研测」2026-09
  • 现象：无模板，提交物写成方案而非总结｜依据：「Leap产研决策部」2026-09
  • 现象：负责人临近截止才问团队总结怎么写，要求靠口头解释｜依据：「Leap产研决策部」2026-10

9. 分支变体

  • 个人 vs 团队负责人：负责人须包含团队内容。
  • 跨组成员：在本组工作的其他组同事同样在提交范围内，结果抄送其所属组负责人。

10. 待确认问题

  • 阶段总结是否设固定周期（每季度/长假前）？全公司统一还是各部门自行发起？
  • 与 HR-21 年度总结的关系：结果是否用于绩效或积分？
  • 模板是否由人事统一提供？
  • 1v1 是否强制，记录由谁保存？
CEO-14向上汇报规范与关键节点上报待新建108

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：项目遇到卡点、延期、重构、方向/战略调整或到达关键节点，或 CEO 抽查进度、索要发布会/融资/调研材料时，负责人按统一口径向上汇报。
  • 负责人：主责——项目/部门负责人（汇报人，当前：杨萌、王皓南·推断待确认）；协同——CTO（预审与指导，当前：丁震宇·推断待确认）、CEO（听取与决策，当前：邴龙志·推断待确认）；兜底——COO（当前：常元和·推断待确认）
  • 核心流程：① 判定触发 → ② 按四段式写一页纸 → ③ 预审 → ④ 先对齐结论 → ⑤ 需要时补完整文档 → ⑥ 记录决策 → ⑦ 同步口径 → ⑧ 回报结果
  • 交付结果：一页纸汇报（是什么/为什么/怎么做/什么结果）、决策记录、相关团队统一口径、CEO 可查的项目清单。
  • 状态依据：06 月 CEO 已在全员群宣布汇报方法论，但无模板、无固定节点；产研线出现“不会跟老板汇报”“先汇报还是先写文档”的反复争论，文档过长被要求直接说结论；项目负责人遇卡点不主动报需高管提醒。每次靠临时组织。

1. 场景判定

  • 触发条件（任一即报）：里程碑或交付日期可能延误 ≥ 2 个工作日；需要重构或推翻既有方案；方向、范围、人力计划调整；需要上级资源或决策；客户/合作方出现重大变化；CEO 点名索要材料。
  • 典型说法：「我们根本不会跟老板汇报」「其实还是得先汇报再写文档」「汇报方法论：是什么、为什么、怎么做、什么结果」「得让他养成每个项目遇到卡点和关键节点要汇报的习惯」
  • 判断问题：如果上级一周后才知道这件事，会不会影响他的判断或资源安排？会，就走本流程。
  • 不归本流程管：决策授权边界与汇报线 → 请走 CEO-05；研发延期风险上报细则 → 请走 RND-08；重大技术变更/重构报备 → 请走 RND-17；重点商机上报 → 请走 SAL-06；日常日报周报 → 请走 CEO-12；政府部门汇报演示 → 请走 CEO-17。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
汇报人 判定触发、起草、汇报、记录决策、跟进 R 项目/部门负责人（当前：杨萌、王皓南·推断待确认）
预审人 审结论、遗漏事项与措辞 C CTO（当前：丁震宇·推断待确认）
决策人 听取汇报，给出决策或资源 A CEO（当前：邴龙志·推断待确认）
业务决策 涉及商务、客户时参与；兜底 C COO（当前：常元和·推断待确认）
相关团队 接收统一口径 I 相关部门负责人（如：宋祺睿等）

3. 办之前请准备

  • 一句话结论：要什么决策，或告知什么事实。
  • 四段式材料：是什么（现状、数据）→ 为什么（原因：技术债/流程/外部）→ 怎么做（方案选项、需要的支持）→ 什么结果（量化预期、日期）。
  • 影响面：受影响项目、客户、日期、成本。
  • 关联材料链接（不超过 3 个）。
  • 措辞检查：区分“重构”与“新功能/优化”，讲清原因，不在大群直接讨论未整理的问题。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定触发，确定上报对象（直属上级/CTO/CEO） 汇报人 发现后 1 个工作日内 — 上报决定 👤人工判断
2 按四段式写一页纸（≤ 1 页），结论放第一行 汇报人 判定后 4 小时内 汇报模板、AI 摘要 一页纸 🤖+👤
3 预审结论、遗漏项与措辞 预审人 收到后 4 小时内 飞书文档评论 修改意见 👤人工判断
4 先口头或用一页纸对齐结论 汇报人 预审后 1 个工作日内；紧急事项当天 飞书会议/汇报群 初步决策 👤人工判断
5 需要书面方案时补完整文档，讨论后定稿 汇报人 对齐后 2 个工作日内 飞书知识库 完整文档 👤人工判断
6 记录决策（结论、负责人、时限）并更新项目清单 汇报人 决策当天 多维表格 决策记录 🔧飞书固化
7 向相关群同步统一口径 汇报人 决策后 1 个工作日内 群 口径同步 🔧飞书固化
8 按决策执行，在下一节点或例会回报结果 汇报人 按决策时限 周报/例会 结果回报 👤人工判断

5. 交付物与模板

  • 交付物：一页纸汇报、决策记录、口径同步消息、项目清单。
  • 建议模板/表单：
    • 一页纸汇报：标题、一句话结论、是什么、为什么、怎么做（选项 A/B、需要的支持）、什么结果（量化、日期）、需要的决策、决策截止时间。
    • 关键节点上报卡：项目、节点/卡点、影响、需要的支持、预计恢复日期。
    • 项目清单（多维表格，供 CEO 查阅）：项目、负责人、当前阶段、下一节点日期、风险等级、最近汇报日期、材料链接。

6. 异常与升级

  • 上级未回复 → 1 个工作日后再提醒一次；仍未回复 → 列入例会“需决策事项”。
  • 材料被退回 → 按意见 1 个工作日内重写，结论先行。
  • 发现应报未报（事后才暴露）→ 汇报人当天补报，上级在复盘中记录。
  • 同一事项多条汇报口径不一 → 预审人统一后再发。
  • 事项在 CEO 处堆积 → 汇报人整理成清单（事项/需要的决策/截止时间）一次提交。

7. 衡量指标

  • 关键节点上报及时率 = 触发后 1 个工作日内上报次数 / 触发总次数，目标 ≥ 90%。
  • 材料一次通过率 = 未被退回的汇报 / 总汇报，目标 ≥ 80%。
  • 事后暴露的未报风险 = 每月次数，目标 0。
  • 项目清单更新率 = 每周更新的在途项目 / 在途项目，目标 100%。

8. 低效诊断

  • 现象：问题与情绪在大群直接讨论，未整理即被上级看到，形成片面印象；重构原因未讲清｜依据：「鼎慧产研决策部」2026-01
  • 现象：规划文档过长，被要求直接说结论；“先汇报还是先写文档”顺序反复争论｜依据：「鼎慧产研决策部」2026-04
  • 现象：待处理事项在 CEO 处堆积，需统一整理后再提交｜依据：「模态集团（全员群）」2026-04
  • 现象：汇报方法论已宣布但无模板和载体，落地依赖个人｜依据：「模态集团（全员群）」2026-06
  • 现象：项目负责人遇卡点和关键节点不主动汇报，需高管提醒｜依据：「【跃迁】合伙人会议」2026-07

9. 分支变体

  • 书面 vs 口头：先口头或一页纸对齐结论，复杂事项再补文档。
  • 战略/规划调整：必须预审，先讨论再定稿。
  • CEO 抽查进度：直接用项目清单回答，1 个工作日内补充细节。
  • 发布会/融资/调研材料：先确认用途、受众、截止时间，交付前预审；同一材料需同步市场群、产品群时，以决策记录为唯一口径。

10. 待确认问题

  • “先汇报再写文档”与“先写文档、讨论、再汇报”，公司采用哪种顺序？
  • 关键节点阈值（延期天数、金额、客户等级）是否按项目级别区分？
  • 是否设固定汇报节奏（如每周 1v1，或周报附“需决策事项”）？
  • 产品线负责人向 CEO 汇报是否必须经 CTO 预审？
  • CEO 项目清单由谁维护、多久更新一次？
CEO-15任务指派、催办与闭环跟踪待新建240

状态：待新建｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：在群内、会上或口头提出需要他人执行的任务/需求后，从明确负责人和时限，到登记、跟进、结果回报关闭的全过程。
  • 负责人：主责——任务发起人（对结果负责到成功或失败）；协同——被指派执行人、任务台账归口（项目管理/产品协调，当前：杨萌·推断待确认；综合事项：总经办，当前：赵雪冰·推断待确认）、上一级负责人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 提出任务写清四要素 → ② 执行人限时认领 → ③ 登记任务台账 → ④ 按优先级执行并更新 → ⑤ 定期汇总未完成项 → ⑥ 超期催办与升级 → ⑦ 回报结果（成功/失败）→ ⑧ 发起人确认关闭
  • 交付结果：每个任务有唯一负责人、DDL、优先级、状态，并以“成功/失败＋说明”关闭；每周未完成清单。
  • 状态依据：闭环规则只在群里口头宣布、未成文；任务多以 @ 形式留在聊天中，无负责人/截止时间/状态；某项目 03～04 月催办消息约 20 次；建议类事项无人认领；总经办已有事项清单和每周两次汇报，但未推广到全公司。

1. 场景判定

  • 触发条件：群里 @ 某人“当个事办”；会议产生待办；跨部门请求协助；上级询问进度；任务需要多人接力。
  • 典型说法：「所有人都要保证任务闭环，禁止悬而未决，要有结果」「@某同事 当个事办」「中午醒了汇报一下项目进度」「还有啥待办」「应该指定一个人负责分工，不然大概率烂尾」
  • 判断问题：这件事是否需要别人去做，而且我关心结果？是，就必须有负责人、DDL 和结果。
  • 不归本流程管：研发工单分派与归属 → 请走 RND-07；研发进度跟催与延期上报 → 请走 RND-08；需求提报 → 请走 X-PRD-09；大会分工 → 请走 ECO-17；交付进度 → 请走 X-DLV-35；加急审批 → 请走 GEN-05；关键节点向上汇报 → 请走 CEO-14。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 写清任务四要素，对结果负责到成功/失败 A 任务发起人
执行人 认领、执行、更新进度、回报结果 R 被指派人（如：杨明学、胡则瑾、杨云峰等）
台账归口 维护任务台账，每周汇总未完成项 R 项目管理/产品协调（当前：杨萌·推断待确认）；综合事项：总经办（当前：赵雪冰·推断待确认，表格维护：董蓝汐·推断待确认）
上一级 无人响应或冲突时指定负责人、裁定优先级 C 上一级负责人（当前：丁震宇、王皓南·推断待确认）
CEO 定对接原则，盯重点事项进度 I CEO（当前：邴龙志·推断待确认）
机器人 记录待办、汇总未完成项 — Spock 等群 AI 助手

3. 办之前请准备

  • 任务四要素：做什么（含完成标准）、谁负责（一个人）、何时完成（具体日期）、优先级（P0/P1/P2）。
  • 前因后果说明（细碎事项也要写清背景）。
  • 相关链接与材料。
  • 多人接力任务：列出交接顺序和每段负责人。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起任务：写四要素；P0 才可 @ 加急或电话 发起人 提出时 飞书任务 任务卡 🔧飞书固化
2 认领，或回复拒绝/转交（转交须对方确认接收） 执行人 P0 1 小时内；P1/P2 24 小时内；建议类 48 小时内 飞书任务 认领记录 👤人工判断
3 群消息中的任务转为飞书任务进入台账 发起人/机器人 提出当天 飞书任务、多维表格 台账记录 🔧+🤖
4 按优先级执行（手上有 Bug 先修）；进度变化在任务中更新 执行人 按 DDL；至少每 3 个工作日更新一次 飞书任务 进度更新 👤人工判断
5 汇总各人未完成项、超期项和长期“老账”，推送群内 台账归口/机器人 每周一、周四 10:00 机器人、多维表格 未完成清单 🤖自动化
6 超期未更新：发起人催办一次；仍无响应找上一级 发起人 超期当天；催办后 1 个工作日 飞书任务评论 催办/升级记录 👤人工判断
7 完成或失败：执行人在任务和原群回报“成功/失败＋说明” 执行人 完成当天 飞书任务、群 结果回报 🔧飞书固化
8 确认关闭；失败的决定是否重开 发起人 回报后 1 个工作日内 飞书任务 关闭记录 👤人工判断

5. 交付物与模板

  • 交付物：任务卡、任务台账、周未完成清单、关闭记录。
  • 建议模板/表单：
    • 任务台账：任务、发起人、执行人、优先级、DDL、状态（待认领/进行中/阻塞/成功/失败）、结果说明、来源（群/会议/口头）、最近更新时间。
    • 周未完成清单：按执行人分组的超期项与阻塞原因。
    • 总经办事项清单（已在用）：节点、任务类型、进度、负责人、DDL。

6. 异常与升级

  • 无人认领 → 发起人 24 小时后找上一级指定负责人。
  • 任务被层层转交 → 第二次转交时由上一级指定唯一负责人。
  • 同一执行人超期事项 ≥ 5 → 台账归口报上一级重排优先级或调配人手。
  • 紧急程度理解不一致 → 以发起人标注的优先级为准；非 P0 不加急催问。
  • 执行人请假 → 除走审批外在群内同步，并指定代理人接手在途任务。

7. 衡量指标

  • 认领及时率 = 时限内认领的任务 / 新建任务，目标 ≥ 90%。
  • 按期完成率 = 按 DDL 关闭的任务 / 到期任务，目标 ≥ 80%。
  • 悬而未决率 = 超期 7 天且无更新的任务 / 在途任务，目标 ≤ 5%。
  • 群内催办消息数 = 每周“××呢/咋说”类消息数，目标逐月下降。

8. 低效诊断

  • 现象：项目人少、无专职项目经理，发起人只能反复 @ 要进度，执行方“每天都急但不知道急什么”｜依据：「LeapCore（archived）」2026-03
  • 现象：建议类事项提出后无人认领，存在烂尾风险｜依据：「【模态】综合部」2026-04
  • 现象：口头事项多被遗忘，个人清单只存在于群文本｜依据：「鼎慧产研决策部」2026-06
  • 现象：任务完成后不回报，需求停在中间态，靠反复追问｜依据：「Leap产研测」2026-06
  • 现象：@ 指派后无截止时间和状态，被转交他人后发起人不知情，隔段时间再追问｜依据：「鸽子群模态分群」2026-07、「鸽子群模态分群」2026-08
  • 现象：机器人记录的待办“老账”长期无人跟进，缺统一台账｜依据：「随便瞎聊啦～」2026-07

9. 分支变体

  • 群 AI 助手台账：机器人可记录待办，提醒类任务须 owner 确认后执行；每周同步进统一台账。
  • 高管直接 @ 员工：须标优先级；非 P0 事项经直属负责人派发。
  • 多人接力材料任务：需求提出时即指定唯一负责人，其余为协作者。
  • 人力不足项目：由项目管理岗代管进度，按日收集进度（见 CEO-12 冲刺期分支）。
  • 总经办事项：每周一、周四阶段性汇报，周三、周五前更新进度，卡点随时找总经办协调。

10. 待确认问题

  • 公司统一使用飞书任务还是多维表格作为任务台账？
  • P0/P1/P2 定义与认领时限是否可行？
  • 建议类事项“48 小时内认领”由谁负责指定认领人？
  • 群 AI 助手（Spock、NK AI）的待办是否同步进统一台账？
  • 是否设立专职项目经理岗位？
CEO-16重大项目/活动复盘待新建90

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨5 × 险3

  • 适用场景：大会、展会等重大活动结束，或客户项目交付出现问题后，需要复盘原因、沉淀经验并形成行动项时启动。
  • 负责人：主责——复盘负责人（项目/活动负责人，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户侧对接人（当前：吴琪·推断待确认）、市场同步人（当前：李铭熙·推断待确认）、各点名成员；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 触发并指定复盘负责人 → ② 用模板建文档、分板块 → ③ AI 拉取时间线与客户问题初稿 → ④ 分块填写 → ⑤ 复盘会对齐事实与根因 → ⑥ 定稿行动项 → ⑦ 发送去向、行动项转任务 → ⑧ 跟踪关闭
  • 交付结果：复盘文档（目标/结果/差距/原因/行动项）、客户问题清单、行动项任务、发给市场/产品的结论摘要。
  • 状态依据：05～06 月大会后有复盘文档和展区复盘，但靠个人临时发起，无模板、截止时间和输出去向；客户交付问题复盘因信息只在单一对接人手中无法开展；无固定复盘负责人和触发规则。

1. 场景判定

  • 触发条件：重大活动（生态大会、发布会、展会）结束；客户交付出现延期、返工或投诉；重点项目结项。
  • 典型说法：「趁现在印象还深，大家写个文档」「回顾，思考，写文档，就是今天的重点工作」「客户A 的问题我们能复盘一下吗」「公司要复盘的东西实在太多了」
  • 判断问题：这件事是否跨部门、影响客户或公司形象，且同类事情还会再发生？
  • 不归本流程管：线上故障复盘 → 请走 RND-75；赢丢单复盘 → 请走 SAL-03；活动后线索转化 → 请走 MKT-07；培训结营复盘 → 请走 ECO-28；新媒体数据复盘 → 请走 BRD-10；客户来访会后复盘 → 请走 SAL-08。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
复盘负责人 建文档、分板块、定截止、主持复盘会、定稿、跟踪行动项 A/R 项目/活动负责人（当前：杨萌·推断待确认）
发起人 判断需要复盘并指定负责人 C Leap 研发负责人（当前：王皓南·推断待确认）
板块填写人 按分工填写体会、问题、建议 R 点名成员
客户侧对接人 提供客户侧事实与时间线，参加复盘会 R（客户项目分支） 销售总监（当前：吴琪·推断待确认）
市场同步人 把客户问题清单和结论发给市场 R 研发（当前：李铭熙·推断待确认）
兜底 根因与责任有分歧时裁定 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 活动/项目目标与实际结果数据。
  • 原始材料：会议纪要、飞书会议记录、群聊时间线、客户反馈、现场照片/视频。
  • 参与人名单与板块分工（展区、演示、视频、客户沟通、技术）。
  • 复盘模板；参考已有“产品展区复盘”样例。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 触发复盘并指定唯一复盘负责人 发起人 活动结束或问题发生后 1 个工作日内 群 指派 👤人工判断
2 用模板建复盘文档，分配板块与截止日，写明输出去向 复盘负责人 指派后 1 个工作日内 飞书知识库模板 文档框架 🔧飞书固化
3 AI 从会议记录、群聊拉取时间线与客户提问清单作初稿，人工校对偏差 复盘负责人 建文档当天 LeapAll、飞书 CLI 时间线、客户问题初稿 🤖+👤
4 分块填写 板块填写人 建文档后 2 个工作日内 飞书文档 板块内容 👤人工判断
5 召开复盘会（可并入周例会），对齐事实与根因 复盘负责人 填写截止后 2 个工作日内 会议 会议结论 👤人工判断
6 定稿：行动项（事项/责任人/DDL） 复盘负责人 复盘会后 1 个工作日内 飞书文档 定稿复盘 👤人工判断
7 行动项建飞书任务；结论摘要发市场/产品/相关群，作为方向讨论输入 复盘负责人、市场同步人 定稿当天 飞书任务、群 任务、摘要 🔧飞书固化
8 跟踪行动项至关闭；下次同类活动立项时检查 复盘负责人 按 DDL；同类活动立项时 飞书任务 关闭记录 🔧飞书固化

5. 交付物与模板

  • 交付物：复盘文档、客户问题清单、行动项任务、结论摘要。
  • 建议模板/表单：
    • 通用复盘：目标、结果（数据）、差距、做得好的、问题与根因（技术/流程/外部）、行动项（事项/责任人/DDL）。
    • 活动复盘附加：客户问题清单（问题、频次、现有答复、是否进 FAQ）、竞品感知、客户认知分层/用户画像、物料与展示问题。
    • 客户项目复盘附加：时间线、需求变更记录、客户侧影响、信息掌握人与交接情况。

6. 异常与升级

  • 复盘负责人为本流程唯一负责人（A）；CTO 作为 A（升级）的条件：复盘会后对根因或责任仍有分歧，或关键信息掌握人无法参加复盘会，复盘负责人在 1 个工作日内提交 CTO 裁定。
  • 填写人认为无需写 → 复盘负责人决定是否豁免；未豁免按期提交。
  • AI 初稿方向偏离 → 填写人在复盘会前指出，复盘负责人修正。
  • 关键信息只在一人手中 → 该人必须参加复盘会并补齐时间线；无法参加 → 升级兜底人（1 个工作日内）。
  • 行动项超期 → 按 CEO-15 催办升级。

7. 衡量指标

  • 复盘启动及时率 = 2 个工作日内建文档的复盘 / 应复盘事项，目标 ≥ 90%。
  • 复盘定稿周期 = 触发到定稿的自然日，目标 ≤ 7 天。
  • 行动项按期关闭率 = 按期关闭行动项 / 到期行动项，目标 ≥ 80%。
  • 同类问题复发数 = 同类活动/项目中重复出现的问题数，目标逐次下降。

8. 低效诊断

  • 现象：需要复盘的事项多，但无固定负责人和触发规则｜依据：「鼎慧产研决策部」2026-05
  • 现象：复盘文档多人自由书写，无模板、截止时间和输出去向，是否必须写不清｜依据：「Leap产研测」2026-05
  • 现象：AI 总结方向偏离（偏向推销话术），需要人工纠正｜依据：「Leap产研测」2026-05
  • 现象：复盘文档与会上口径偏离，补写后发现写偏｜依据：「鼎慧产研决策部」2026-06
  • 现象：客户交付问题信息只在单一对接人手中，复盘无法开展｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 活动复盘：展区客户反馈与研发体验反馈分块；输出客户问题清单给市场做 FAQ 与统一报价口径。
  • 客户项目复盘：客户侧对接人必须参与；改进项进入交付 SOP 沉淀（X-DLV-36）。
  • 小型复盘：并入周例会，文档简化为“问题—原因—行动项”。

10. 待确认问题

  • 哪些活动/项目必须复盘（规模、客户等级、问题严重度阈值）？
  • 复盘负责人默认是活动负责人还是项目经理？
  • 复盘文档统一归档在哪个知识库目录？
  • 复盘结论是否必须在周例会上过一遍？
  • 个人复盘是否强制提交？
CEO-17政府部门对接、汇报演示与政策风险应对待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：政府部门、政府平台运营方或合作方领导临时通知开会、要看项目进度、下达合规/整改要求，或外部政策态度出现变化需要启动 PlanB 时启动
  • 负责人：主责——政府事务对接统筹（当前：陈梦琪·推断待确认）；协同——CEO 对外联络（当前：邴龙志·推断待确认）、CTO 方案与优先级（当前：丁震宇·推断待确认）、演示研发（当前：葛家和、裴建武·推断待确认）、商务汇报与运营（当前：杨朋伟·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 登记通知 → ② 确认议题 → ③ 指派参会人 → ④ 材料与演示准备 → ⑤ 参会汇报与纪要 → ⑥ 要求拆解登记 → ⑦ 跟踪闭环 → ⑧ 政策风险触发 PlanB
  • 交付结果：政府事务登记记录、汇报材料与演示环境、会议纪要、政府要求整改清单（已闭环）、政策风险预案
  • 状态依据：无登记表、无议程确认、无演示检查清单；2026-02 出现会前约 2 小时才通知且参会人不知议题，2026-03 汇报时间多次“待命”、前一晚补材料，整改要求靠群转发口头拆分，政策变化时临时改架构方案

1. 场景判定

  • 触发条件：科技主管部门等政府单位临时通知参会/派专家；政府平台运营方或领导要求看进度、做汇报演示；下达管理规则、追责条款、风险测试等整改要求；监管或领导对产品态度变化、网络侧出现屏蔽
  • 典型说法：「三点的会，十二点四十通知」「下周二要给领导汇报」「今天要给领导汇报吗」「要制定基本管理规则和追责条款」「得做好预案」「得单独起一个网站了」
  • 判断问题：对方是否为政府部门/政府平台/其上级领导？是否需要我方出人、出材料、出演示或整改？是否可能影响产品上线或存续？
  • 不归本流程管：政策项目申报与补贴材料 → 请走 POL-01（政策与补贴线索收集研判及申报决策）/ POL-04（科技项目申报）；生态活动、社区沙龙会务 → 请走 ECO-01（生态活动年度规划与 ROI 取舍）/ ECO-16（生态大会立项与总体筹备）；商业客户的售前演示 → 请走 SAL-11（客户演示准备与执行）；股东会/董事会汇报 → 请走 CEO-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
对接统筹 登记通知、确认议题、拆解要求、跟踪闭环 R 政府事务对接统筹（当前：陈梦琪·推断待确认）
对外联络与决策 对政府/合作方联络，决定参会级别与对外口径 A CEO（当前：邴龙志·推断待确认）
技术方案与 PlanB 评估 指派技术专家、定整改优先级、组织 PlanB 评估并提出建议、指挥执行 R CTO（当前：丁震宇·推断待确认）
演示研发 演示页面、mock 数据、冻结测试环境 R 演示研发（当前：葛家和、裴建武·推断待确认）
汇报与运营 汇报材料、社区内容准备 R 商务/项目经理（当前：杨朋伟·推断待确认）
参会技术专家 会上讲解、会后反馈 R 研发技术专家（当前：王皓南·推断待确认）
法务 审核规则、追责条款与对外承诺 C 法务负责人（当前：待指定）
测试/运维 风险测试、迁移与认证 C 测试负责人、运维（当前：邓乾·推断待确认，负责迁移）
品牌/社区 同行、物料与社媒同步 I 信创&Linux 适配负责人/开源布道（当前：李子遥·推断待确认）

3. 办之前请准备

  • 通知原文（截图或转述）：时间、地点、对方联系人、议题、要求的参会人身份
  • 最新版公司/产品一页纸介绍、标准汇报 PPT 模板、可用演示账号与环境
  • 本项目已有的方案文档（如 API 聚合站 × OPC 社区方案、渠道分销方案）链接
  • 政府要求反馈登记表、政策风险登记表（多维表格）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到通知后在“政府事务登记表”登记时间、地点、议题、要求人员、来源 对接统筹 收到通知后 30 分钟内 飞书多维表格 登记记录 🔧飞书固化
2 议题/议程不明时向对方联系人追问议题、参会级别、是否需演示和材料 对接统筹 登记后 1 小时内 电话/微信 议程确认 👤人工判断
3 按议题指派参会人（技术议题由 CTO 指派技术专家），发飞书日程含地点、出发时间、同行人 CTO/CEO 临时会 1 小时内；常规会 2 个工作日内 飞书日历 参会安排 🔧+👤
4 用发言要点模板生成初稿（背景、我方能力、案例、诉求、不可承诺事项），对外措辞人工审 参会人、对接统筹 临时会会前 30 分钟；正式汇报会前 2 个工作日定稿 飞书文档、AI 发言要点/汇报材料 🤖+👤
5 按演示环境检查清单准备：mock 数据、冻结测试数据窗口、账号、网络、备用录屏；通知研发测试冻结时段 演示研发 汇报前 1 个工作日 18:00 前 检查清单、飞书任务 检查清单（已勾选） 🔧飞书固化
6 参会/汇报；会后提交纪要：结论、对方要求、我方承诺、下次节点 参会人 会后当天 飞书妙记/文档 会议纪要 🤖自动化
7 把整改/合规/联调要求逐条登记到反馈表（要求、责任部门、截止、状态），建飞书任务指派 对接统筹 会后 1 个工作日内 多维表格+飞书任务 整改清单 🔧飞书固化
8 每周同步一次进度；到期前 1 个工作日向对方书面反馈 对接统筹 每周五 多维表格自动周报 闭环记录 🔧+🤖
9 出现政策风险信号时登记风险表，CTO 召集评估并提出是否启动 PlanB（拆分站点、独立域名、重新认证、物料更新），报 CEO 拍板 CTO 评估、CEO 拍板 信号出现后 24 小时内评估并拍板 风险登记表 预案决策纪要 👤人工判断
10 执行 PlanB：迁移、认证、商城跳转、物料同步，统一对外口径 研发/运营/法务 按决策纪要节点 飞书任务 迁移完成记录 🔧飞书固化

5. 交付物与模板

  • 交付物：政府事务登记记录、汇报材料、演示检查清单、会议纪要、整改清单、政策风险预案
  • 建议模板/表单：
    • 政府事务登记表：日期、来源单位、对方联系人、议题、要求身份、参会人、是否演示、材料链接、结论、后续事项
    • 政府要求反馈表：要求原文、类型（规则/追责/测试/联调）、责任部门、负责人、截止日、状态、反馈时间
    • 发言要点模板：一句话介绍、能力要点 3 条、案例 1～2 个、我方诉求、不可承诺事项
    • 政策风险登记表：风险描述、触发信号、影响产品、预案、预案负责人、启动条件、状态

6. 异常与升级

  • CEO 为本流程唯一最终决策人（A），负责参会级别、对外口径与 PlanB 启动拍板；CTO 对技术方案与整改优先级负责执行（R），CEO 不在时由 CTO 临时决定并于当天补报 CEO 确认
  • 通知距会议不足 3 小时且议题不明 → 先派熟悉产品的技术人员+对接统筹同行，发言控制在事实介绍 → 升级 CEO（即时）
  • 汇报时间未定、需研发待命 → 对接统筹每天 10:00 前同步一次最新状态，待命超过 2 个工作日 → 升级 CEO 与对方确认
  • 整改要求超出能力或涉及法律承诺 → 法务出意见 → 升级 CEO（1 个工作日内）
  • 演示环境故障 → 切备用录屏 → 会后 1 个工作日内复盘
  • 产品可能被下架/流量被屏蔽 → 立即启动步骤 9 → 升级 CEO+CTO（当天）

7. 衡量指标

  • 议题确认率 = 会前已确认议题的会议数 / 总会议数，目标 ≥ 90%
  • 汇报材料准时定稿率 = 会前 2 个工作日定稿的正式汇报数 / 正式汇报数，目标 ≥ 90%
  • 政府要求按期闭环率 = 截止日前完成并反馈的要求数 / 要求总数，目标 ≥ 90%
  • 演示一次成功率 = 无故障演示数 / 演示总数，目标 100%

8. 低效诊断

  • 现象：临时会议通知到开会约 2 小时，参会人不知议题和地点，到会后才知道对方真实诉求｜依据：「鼎慧产研决策部」2026-02
  • 现象：汇报时间长期“待命等通知”，研发测试多次追问是否今天汇报，汇报节点无人统一通知｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：汇报前一晚才补内容、临时用水帖填充社区板块，材料准备无提前量｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：政府整改要求在群里转发后口头拆分，无登记、无截止、无闭环反馈｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：政策态度变化前无风险登记与预案，信号出现后临时决定拆站迁移｜依据：「开源聚变入驻问题沟通群」2026-03

9. 分支变体

  • 政府部门（科技主管部门等）：临时专题会、派技术专家，重在议题确认与发言要点
  • 政府平台运营方：登录、支付、消费券等联调问题，走步骤 7 登记并指派研发
  • 合作方/群团组织：由 CEO 对外联络，结论同样入登记表
  • 政策风险 PlanB：产品拆分独立站点（使用模态跃迁域名）、从 OPC 作为商品跳转、重新认证、走专家评审或借壳，物料同步更新

10. 待确认问题

  • 政府事务对接统筹是否由研究院生态负责人担任？是否需要设一名固定备岗？
  • 临时会“收到通知 1 小时内指派参会人”是否可行？
  • 对外措辞与承诺的审批人是 CEO 还是法务？
  • 政策风险登记表由谁维护、多久复核一次（建议每月）？
  • 是否已有成文的政府关系或对外口径制度？
CEO-18高管日程与外部约见管理待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：外部人员或内部同事约高管见面、饭局、会议，或已排日程需要改期时启动
  • 负责人：主责——高管助理/总助（当前：待指定）；协同——被约高管（当前：邴龙志·推断待确认）、代为协调的高管（当前：丁震宇·推断待确认）、行政（会议室）（当前：待指定）；兜底——综合部负责人
  • 核心流程：① 约见请求登记 → ② 查冲突给时段 → ③ 高管确认 → ④ 写入日历订会议室 → ⑤ 提醒 → ⑥ 变更通知 → ⑦ 会后记录
  • 交付结果：高管共享日历中已确认的约见日程、约见登记记录、改期通知记录
  • 状态依据：无总助、无共享日历管理，约见靠个人记忆；2026-03 数日内出现约见被遗忘、对外“被鸽”、会议室临时改时间约 4 次

1. 场景判定

  • 触发条件：外部合作方、客户、投资人、政府人员约高管见面或吃饭；内部要占用高管时间开会；已定约见需要改期或取消
  • 典型说法：「已读已忘」「给人家鸽了」「不管理日程的后果」「速招总助」
  • 判断问题：这件事要不要占用高管的具体时段？对方是外部人员吗？如果被遗忘，会不会损害对外关系？
  • 不归本流程管：政府临时会议与汇报 → 请走 CEO-17；股东会/董事会会务 → 请走 CEO-22；普通部门例会 → 部门自行用飞书日程

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
总助 接收约见请求、查冲突、写日历、提醒、改期通知 R 高管助理/总助（当前：待指定）
被约高管 确认是否接受、优先级取舍 A CEO（当前：邴龙志·推断待确认）
协调高管 内部转达约见、在总助缺位时代为确认 C CTO（当前：丁震宇·推断待确认）
行政 会议室、餐厅预订 C 行政（当前：待指定）
约见发起人 提供事由、时长、参会人 I 申请人

3. 办之前请准备

  • 约见人姓名单位（内部记录用）、事由、期望时间段（至少 2 个）、时长、地点、是否饭局、同行人
  • 高管已开放共享的飞书日历（总助有编辑权限）
  • 会议室预订权限、常用餐厅清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有约见请求统一提交到“高管约见表单”（外部请求由接收人代填） 约见发起人/接收人 收到约见当天 飞书表单 约见登记 🔧飞书固化
2 查高管共享日历，判冲突，给出 2 个可选时段 总助 工作时间内 2 小时 飞书日历 可选时段 🔧+👤
3 高管确认；外部/重要约见须高管在日程上点“接受”，4 小时内未确认由总助当面或电话确认 被约高管、总助 4 小时内 飞书日历 确认结果 👤人工判断
4 写入飞书日程（含地点、议题、参会人），同步预订会议室或餐厅，回复约见人 总助、行政 确认后 1 小时内 飞书日历/会议室 正式日程 🔧飞书固化
5 机器人提醒：前一天 18:00 推送次日日程；开始前 1 小时再提醒 机器人 自动 飞书机器人 提醒消息 🤖自动化
6 需要改期/取消的，原定时间前至少 4 小时由总助通知对方并给新时段 总助 原定时间前 4 小时 电话/飞书 改期记录 👤人工判断
7 会后记录结论与待办，涉及后续事项转相关负责人 总助 会后当天 约见登记表 约见纪要 🤖自动化

5. 交付物与模板

  • 交付物：高管共享日历、约见登记表、改期通知记录
  • 建议模板/表单：高管约见表单——约见人、单位类型（客户/合作方/政府/投资人/内部）、事由、期望时段、时长、地点、是否饭局、同行人、优先级、确认状态、结论、后续待办

6. 异常与升级

  • 新约见与已有日程冲突 → 总助按优先级（政府/投资人/客户 > 合作方 > 内部）提出调整建议 → 被约高管拍板（2 小时内）
  • 高管 4 小时未确认外部约见 → 总助当面确认 → 仍无结果升级综合部负责人
  • 已发生爽约 → 总助当天致歉并改约 → 综合部负责人复盘原因（1 个工作日内）
  • 会议室被占用或临时变更 → 行政 30 分钟内给替代方案

7. 衡量指标

  • 爽约次数 = 当月因遗忘或冲突未到场的约见数，目标 0
  • 约见响应时长 = 请求提交到给出时段的工作小时，目标 ≤ 2 小时
  • 日程登记率 = 已入日历的约见数 / 实际发生约见数，目标 100%

8. 低效诊断

  • 现象：约见请求只在聊天中“已读”，未进入日历，事后遗忘｜依据：「鼎慧产研决策部」2026-03
  • 现象：同一天多个外部饭局/会面冲突，后约者被时间占用导致对外失约｜依据：「鼎慧产研决策部」2026-03
  • 现象：会议室临时改时间，缺统一的会议室与日程协调人｜依据：「鼎慧产研决策部」2026-03
  • 现象：没有总助岗位，日程管理依赖高管个人记忆与同事代问｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 外部约见：必须走步骤 3 的高管确认与步骤 6 的改期通知
  • 内部会议：可直接发飞书日程邀请，总助只做冲突检查
  • 饭局：额外确认餐厅、人数、是否需要报销预申请

10. 待确认问题

  • 是否设立专职总助岗位？在设立前由谁临时承担？
  • 哪些高管纳入本流程（仅 CEO，还是 CEO、COO、CTO）？
  • 高管是否同意向总助开放日历编辑权限？
  • “4 小时内确认”“提前 4 小时改期”是否可行？
CEO-19外部合作方/顾问评估与分成决策待新建96

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：外部合作方、顾问、代写/渠道伙伴的产出不达标，或合作满一个周期，需要评估是否继续合作及调整分成/付费方式时启动
  • 负责人：主责——合作方对接业务负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、用户对接（当前：杨萌·推断待确认）、法务（当前：待指定）、财务（当前：待指定）；决策——COO（当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 事实收集 → ② 对照合同条款 → ③ 评估打分 → ④ 真实用户反馈 → ⑤ 方案与测算 → ⑥ 决策会 → ⑦ 协议与结算落地 → ⑧ 台账归档
  • 交付结果：合作方评估表、决策纪要、补充协议或终止通知、更新后的合作方台账
  • 状态依据：无考核标准与分成调整规则；2026-03 群内对合作方表现集中评价约 5 次，口径不一、是否降分成无依据可循

1. 场景判定

  • 触发条件：合作方交付物长期未交或质量不达标；用户反馈与合作方承诺不符；合作周期到期；拟更换合作模式（分成改为顾问费等）
  • 典型说法：「做了一年都没打包文件」「听合作方的不如听真实付费用户的」「给顾问费」
  • 判断问题：是否有书面合同/分成约定？产出是否可以量化核对？调整会不会影响已签约用户或收入？
  • 不归本流程管：新合作方准入 → 请走 ECO-02（生态合作伙伴引入与内部对齐）；合作协议签约 → 请走 LEG-05（保密协议与外部合作协议拟定）；渠道返佣结算 → 请走 FIN-23（渠道/开发者分成结算、分润打款与开票）；采购供应商评估 → 请走 FIN-01（对公采购申请与付款审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
对接人 收集事实、填评估表、通知合作方 R 合作方对接业务负责人（当前：待指定）
技术评估 评估技术交付质量 C CTO（当前：丁震宇·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
用户反馈 组织用户群/访谈，提供真实反馈 C 产品总监（当前：杨萌·推断待确认）
决策 决定继续/调整/终止及分成比例 A COO（当前：常元和·推断待确认）
法务 核对条款、出补充协议或终止函 C 法务负责人（当前：待指定）
财务 测算分成影响、调整结算 C 财务负责人（当前：待指定）
兜底 重大合作（涉及股权或年度核心收入）终审 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 合作合同/协议及分成、交付、退出条款
  • 合作以来的交付清单（约定 vs 实际）、时间线
  • 合作带来的收入、用户数、投入人力
  • 真实用户反馈记录（用户群、访谈纪要）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 汇总事实：约定交付、实际交付、质量问题、响应情况 对接人 发起后 2 个工作日内 合作方台账 事实清单 👤人工判断
2 对照合同条款，标出可调整/可终止的依据 法务 1 个工作日内 合同库 条款意见 👤人工判断
3 填写合作方评估表并打分（交付达成、质量、响应、用户反馈、投入产出） 对接人+技术评估 2 个工作日内 多维表格 评估表 🔧飞书固化
4 拉用户群或访谈 3～5 个真实用户，记录反馈 用户反馈岗 与步骤 3 并行，3 个工作日内 用户群/妙记 用户反馈摘要 🤖自动化
5 提出方案选项（继续/降分成/改顾问费按次付费/终止），财务测算影响 对接人+财务 2 个工作日内 飞书文档 方案对比 👤人工判断
6 召开决策会，结论写入纪要 COO 方案完成后 3 个工作日内 飞书会议 决策纪要 👤人工判断
7 法务出补充协议/终止函，财务调整结算口径，对接人正式通知合作方 法务/财务/对接人 决策后 5 个工作日内 合同审批 签署文件 🔧飞书固化
8 更新合作方台账，设下次复评日期 对接人 落地当天 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：合作方评估表、方案对比、决策纪要、补充协议/终止函、台账记录
  • 建议模板/表单：合作方台账——合作方类型（渠道/顾问/代写/技术）、合同编号、分成或付费方式、约定交付、实际交付、评分、上次评估日、下次评估日、状态；评估表——五项各 1～5 分、证据链接、建议

6. 异常与升级

  • COO 为本流程唯一决策人（A）；CEO 作为 A（升级）的条件：合作涉及股权、属于年度核心收入来源，或调整/终止会导致已付费用户交付中断，由 COO 在决策会后 1 个工作日内提交 CEO 终审
  • 合同无分成调整或退出条款 → 法务评估协商方案 → 升级 COO（2 个工作日内）
  • 合作方对调整有异议 → 对接人记录诉求 → 法务+COO 再议（5 个工作日内）
  • 涉及已付费用户交付中断 → 先确保用户交付 → 升级 CEO（当天）
  • 群内出现针对合作方的情绪化评价 → 对接人收口到评估表，按事实处理

7. 衡量指标

  • 评估周期 = 发起到决策纪要的工作日，目标 ≤ 10 个工作日
  • 合作方覆盖率 = 已建台账并按期复评的合作方数 / 合作方总数，目标 100%
  • 交付达成率 = 实际交付项 / 约定交付项（按合作方统计）

8. 低效诊断

  • 现象：对合作方的评价分散在群聊，缺事实清单和评分，判断依赖个人印象｜依据：「鼎慧产研决策部」2026-03
  • 现象：是否降分成、是否改为顾问费在群内讨论，无决策人和留痕｜依据：「鼎慧产研决策部」2026-03
  • 现象：缺少真实用户反馈渠道，临时拉用户群补证据｜依据：「鼎慧产研决策部」2026-03
  • 现象：合同中无考核与分成调整条款，事后难以调整｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 渠道合作方：按渠道政策与返佣阶梯评估，调整走补充协议
  • 顾问：倾向按次/按月付顾问费，不给分成
  • 代写/内容合作：以真实付费用户反馈为主要评估依据

10. 待确认问题

  • 分成调整的最终决策人是 COO 还是 CEO？金额或比例超过多少需 CEO 终审？
  • 是否需要统一的合作方月度/季度考核？复评周期多久？
  • 现有合作合同是否包含考核与退出条款？需要法务补充模板吗？
  • 合作方对接人由业务线负责人兼任是否可行？
CEO-20内部管理系统与协作工具建设（内控/业财平台）待优化300

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：建设或改造内控与经营管理平台、业财系统、PRM/CRM/工单/合同等内部系统，或决定统一内部协作工具并强制推行时启动
  • 负责人：主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——总经办（当前：田杰·推断待确认）、CTO 系统架构（当前：丁震宇·推断待确认）、定制系统开发（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、工单系统研发（当前：王皓南·推断待确认）、各板块执行协同人（当前：黄梦婷、韩诗琪、杨明学·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 立项建议书 → ② 系统盘点与选型 → ③ CEO 决策 → ④ 组推进组 → ⑤ 需求与边界 → ⑥ 开发配置与权限 → ⑦ 每周同步 → ⑧ 跑测验收 → ⑨ 上线强制推行 → ⑩ 系统台账交接
  • 交付结果：项目建议书（含 MVP 范围）、选型打分表、推进表、系统台账（负责人/边界/权限）、上线公告与验收记录
  • 状态依据：已有治理体系方案、业财文档库、推进表和每周同步机制；但 2026-07～10 反复出现建议书返工（过重需拆 MVP）、牵头部门争议、系统边界多次讨论、权限遗漏、多套工具并存无人用

1. 场景判定

  • 触发条件：经营数据口径不统一、审计/尽调/融资需要系统支撑；新内部系统上线或交接；多套工具功能交叠需要统一；高管下达系统建设期限
  • 典型说法：「规则前置，大家慢慢就能越来越规范」「请每个板块明确 1 名执行层面的协同同学」「现在得划分清楚每个系统的核心需求」「没在 LeapCore 工作流上留档的工作不算有效工作」
  • 判断问题：是跨部门共用的内部系统/工具吗？会改变数据口径、审批链或考核依据吗？需要采购或投入研发人力吗？
  • 不归本流程管：对外销售的产品需求与研发排期 → 请走 X-PRD-09（需求提报登记与需求池管理）/ RND-06（迭代规划、工单拆分与排期）；单个飞书审批流开通 → 请走 X-SEC-34（飞书平台管理员事项）；财务报表口径 → 请走 FIN-41（月度结账与管理报表）；收入确认 → 请走 FIN-21（收入合同台账、回款跟进与收入确认）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目统筹 起草建议书、组推进组、周同步、验收组织 R 综合部负责人（当前：赵雪冰·推断待确认）
会议与跟进 会议纪要、待办跟进、催办 R 总经办（当前：田杰·推断待确认）
决策 范围、预算、厂商、牵头部门、期限 A CEO（当前：邴龙志·推断待确认）
系统架构 架构、自研/外购判断、权限配置、通知中心 R CTO（当前：丁震宇·推断待确认）
开发负责人 定制系统开发、PRM/CRM 开发 R 定制开发（当前：黄振锋、陈子康、裴建武·推断待确认）
工具统一 工单/工作流方案、推行与权限模板 R 产品总监（当前：杨萌·推断待确认）、工单研发（当前：王皓南·推断待确认）
板块协同人 本板块需求、跑测、验收确认 C 财务（当前：黄梦婷·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、IT（当前：杨明学·推断待确认）、渠道系统（当前：郭逸非·推断待确认）
法务/安全 合同审批链、数据权限与保密项目 C 法务负责人（当前：待指定）
全员 按要求使用新系统 I 各部门

3. 办之前请准备

  • 治理体系方案、现有系统盘点文档、业财融合文档库链接
  • 业务痛点与目标（为哪项审计/融资/管理诉求服务）、期限
  • 现有工具清单（飞书、Gitea、LeapCore 工单、任务流、渠道系统、各 SaaS）及使用情况
  • 各板块执行协同人名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草项目建议书：目标、范围、MVP 与分期、预算、期限、牵头部门 项目统筹 立项后 5 个工作日内 飞书文档 建议书 v1 🤖+👤
2 盘点现有系统与功能交叠；自研 vs 厂商按统一打分表比对（功能、价格、数据归属、集成） CTO+项目统筹 5 个工作日内 多维表格 选型打分表 🔧+👤
3 CEO 决策会：确定 MVP 范围、预算、厂商、牵头部门、上线期限 CEO 打分表完成后 3 个工作日内 飞书会议 决策纪要 👤人工判断
4 组推进组：每板块指定 1 名执行协同人，建推进表（事项、负责人、截止、状态） 总经办 决策后 2 个工作日内 多维表格+飞书任务 推进表 🔧飞书固化
5 需求收集与边界划分：各板块在多维表格提需求；产品整理 PRD；在系统台账写清每个系统的核心需求、边界、数据源 板块协同人、产品 5 个工作日内 多维表格、飞书文档 PRD、系统台账 🔧+🤖
6 开发/配置；上线前按权限检查清单配置（读全放开、写入按部门、保密项目例外、部门负责人可见全部） 开发负责人、CTO 上线前 2 个工作日完成权限检查 系统后台 权限检查清单 🔧+👤
7 每周同步：推进表自动生成周报，逾期项 @ 负责人 总经办 每周一 多维表格自动化 周报 🤖自动化
8 各部门跑测，板块协同人签字验收 板块协同人 跑测期 5 个工作日 飞书任务 验收记录 👤人工判断
9 上线公告：时间表、培训、旧入口关闭日期、使用要求（如工作量以工作流留档为准） 项目统筹+CEO 上线前 3 个工作日发布 飞书公告 上线公告 🔧飞书固化
10 系统台账登记业务负责人、开发负责人、权限角色；交接时同步更新 项目统筹 上线当天 系统台账 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：项目建议书、选型打分表、决策纪要、推进表、PRD、系统台账、权限检查清单、验收记录、上线公告
  • 建议模板/表单：
    • 系统台账：系统名、用途、核心需求、边界（不做什么）、数据源与口径、业务负责人、开发负责人、权限角色、上线日期、状态
    • 权限检查清单：角色、可读范围、可写范围、保密项目例外、超管、审核人、核对日期
    • 推进表：事项、板块、负责人、截止、状态、阻塞点、验收人

6. 异常与升级

  • 牵头部门有分歧（如业财由财务还是市场牵头）→ 项目统筹整理选项 → CEO 拍板（3 个工作日内）
  • 系统边界冲突（如 PRM 与研发工单）→ 组织对齐会，产品出边界结论 → CTO 确认（5 个工作日内）
  • 推进表事项逾期 2 次 → 总经办升级综合部负责人 → 仍逾期升级 CEO
  • 审计/融资急需材料 → 列入当周最高优先级，指定专人 → 当天升级 CEO
  • 上线后权限遗漏 → 申请人提交权限申请 → 开发负责人 1 个工作日内处理

7. 衡量指标

  • 里程碑按期率 = 按期完成的推进表事项 / 到期事项，目标 ≥ 85%
  • 系统台账完整率 = 负责人、边界、权限均填写的系统数 / 内部系统数，目标 100%
  • 上线权限问题数 = 上线后 2 周内的权限类问题数，目标 ≤ 2
  • 工具使用率 = 在指定工作流留档的任务数 / 实际任务数（抽样），目标 ≥ 90%

8. 低效诊断

  • 现象：建议书一次写成全量功能，评审认为过重，需返工拆 MVP｜依据：「董事会专项沟通群」2026-07
  • 现象：业财平台由哪个部门牵头存在分歧，推进期间反复讨论｜依据：「董事会专项沟通群」2026-08
  • 现象：推进表依赖人工催交，审计材料临近截止才集中补救｜依据：「全力突击经营管理平台」2026-08
  • 现象：多套 SaaS 功能交叠，“哪里接触真实现金”未成文｜依据：「全力突击经营管理平台」2026-08
  • 现象：系统上线后权限未开、负责人不明、系统边界多次重议，定制需求统一丢给单一系统｜依据：「项目管理系统（prm）交流群」2026-09、2026-10
  • 现象：工单与任务流两套并存，任务流看不到他人任务、无项目分组，导致无人使用｜依据：「Leap产研决策部」2026-10

9. 分支变体

  • 业财融合/经营管理平台：财报数据以财务系统为准，业务系统与之口径一致；合同审批增加财务审核，采购申请须写明用途与主体
  • PRM/CRM/研发工单/合同系统：重点是系统台账与权限检查清单
  • 协作工具统一：三档方案——直接替换为工单 / 以工单为基础补齐工作流 / 产品迭代+非产研优先推广；以关闭旧入口、工作量看工作流作为推行手段
  • 自研 vs 外部厂商；全量 vs MVP 分期

10. 待确认问题

  • 业财平台的牵头部门最终是财务还是综合部？
  • 内部系统的统一负责人（系统台账维护人）是谁？
  • “绩效和工作量以工作流留档为准”是否正式成为制度？何时生效、覆盖哪些部门？
  • 自研与外购的预算审批线是多少？
  • 权限配置是否可由 CTO 以外的人员执行，以解除单点？
CEO-21全员 AI 案例征集与积分激励宣贯待优化40

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗2 × 跨5 × 险2

  • 适用场景：总经办推出全员制度（如积分激励制度）需要宣贯，或面向全员发起案例征集、命名征集等活动时启动
  • 负责人：主责——总经办（当前：田杰·推断待确认）；协同——CEO 发起与评审（当前：邴龙志·推断待确认）、产品总监（案例收集与需求池）（当前：杨萌·推断待确认）、综合部负责人答疑（当前：赵雪冰·推断待确认）、问题收集（当前：宋祺睿·推断待确认）、人事（积分发放）（当前：待指定）；兜底——综合部负责人
  • 核心流程：① 方案与口径核对 → ② 发通知 → ③ 宣贯会 → ④ 答疑与 FAQ → ⑤ 征集收表 → ⑥ 统计催交 → ⑦ 评审 → ⑧ 积分发放与公示
  • 交付结果：宣贯通知与一页纸速览、FAQ、征集结果表、评审结论、积分发放与公示记录
  • 状态依据：已有一页纸速览版、征集表、宣贯会做法；但 2026-08 出现新旧积分关系口径不清、通知样式需重做、截止前多次催交未提交人员

1. 场景判定

  • 触发条件：新制度/激励政策需要全员知晓；需要全员提交材料（AI 应用案例、命名建议等）；征集结果要换算积分
  • 典型说法：「请每人至少提交 1 个已经实际使用的案例」「今晚将统计未提交人员」「之前的赛马积分和这个积分是一样的吗」
  • 判断问题：是否面向全员或多个部门？是否需要收集材料并评审/发奖励？
  • 不归本流程管：个人积分申报与复核 → 请走 HR-18（积分激励制度运行）；部门内部培训 → 部门自行组织；产品需求正式评审 → 请走 X-PRD-09（需求提报登记与需求池管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动统筹 方案、通知、宣贯会、统计催交、公示 R 总经办（当前：田杰·推断待确认）
发起与审批 批准活动方案与奖励规则，参与评审 A CEO（当前：邴龙志·推断待确认）
案例收集与评估 征集表、评估能否在 LeapCore 复现、入需求池 R 产品总监（当前：杨萌·推断待确认）
答疑 制度口径解释、FAQ 定稿 C 综合部负责人（当前：赵雪冰·推断待确认）
问题收集 会后问题表单汇总 R 问题收集人（当前：宋祺睿·推断待确认）
积分发放 积分系统录入与公示 R 人事（当前：待指定）
全员 参会、提交材料 I 全员

3. 办之前请准备

  • 制度或活动方案定稿、一页纸速览版、申报/提交路径指引
  • 与既有制度的关系说明（如旧赛马积分与新积分是否合并、如何折算）
  • 通知模板（当前样式）、征集表单、截止时间、奖励规则
  • 宣贯会会议室与线上会议链接、录屏安排

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 方案定稿并核对与既有制度的口径冲突，写入 FAQ 初稿 活动统筹+答疑 通知发布前 2 个工作日 飞书文档 方案+FAQ 初稿 👤人工判断
2 用最新通知模板发布通知（目的、范围、时间、路径、截止、奖励），全员群+飞书公告 活动统筹 宣贯会前 2 个工作日 飞书公告 通知 🔧飞书固化
3 召开宣贯会（线下+线上），录屏 活动统筹 按通知时间 飞书会议/妙记 录屏、纪要 🤖自动化
4 会后开问题表单，汇总后发布统一 FAQ 问题收集人+答疑 宣贯会后 3 个工作日内 飞书表单 FAQ 定稿 🔧+🤖
5 发征集表，设截止时间（建议发布后 3～5 个工作日） 案例收集 宣贯会当天 飞书表单/多维表格 征集表 🔧飞书固化
6 截止前 1 天自动统计未提交人员，机器人推送本人及部门负责人 机器人 截止前 1 天 多维表格自动化 未提交名单 🤖自动化
7 评审：评估案例价值、能否在 LeapCore 复现，入需求池 案例收集+CEO 截止后 5 个工作日内 视频会议、需求池 评审结论 👤人工判断
8 积分录入积分系统并公示，公示期接受复核 人事 评审后 3 个工作日内 积分系统 公示记录 🔧飞书固化
9 归档：通知、FAQ、结果表、评审结论 活动统筹 公示结束当天 飞书知识库 归档 🔧飞书固化

5. 交付物与模板

  • 交付物：通知、一页纸速览、宣贯录屏、FAQ、征集结果表、评审结论、积分公示
  • 建议模板/表单：
    • 全员通知模板：标题、目的、适用范围、时间地点、操作路径、截止时间、奖励、答疑人
    • 案例征集表：提交人、部门、场景描述、使用工具、效果（节省时间/提升质量）、截图或链接、可否复现
    • 评审表：案例编号、价值评分、可复现性、是否入需求池、积分建议

6. 异常与升级

  • 员工对新旧制度关系有疑问 → 答疑人 1 个工作日内在 FAQ 统一回复 → 涉及规则变更升级 CEO
  • 截止时提交率低于 80% → 延长 2 个工作日并通报部门负责人 → 升级综合部负责人
  • 积分争议 → 公示期内申请复核 → 人事 5 个工作日内答复
  • 通知样式/版本错误 → 撤回重发并注明更正

7. 衡量指标

  • 提交率 = 截止时提交人数 / 应提交人数，目标 ≥ 95%
  • 催办次数 = 单次活动人工催交次数，目标 ≤ 1
  • FAQ 发布时长 = 宣贯会到 FAQ 发布的工作日，目标 ≤ 3
  • 案例转化数 = 入需求池的案例数

8. 低效诊断

  • 现象：新积分与旧赛马积分关系未提前说明，宣贯后才被追问｜依据：「模态集团（全员群）」2026-08
  • 现象：通知沿用旧版样式，需要重做｜依据：「模态集团（全员群）」2026-08
  • 现象：截止前人工统计未提交人员并多次催交｜依据：「模态集团（全员群）」2026-08

9. 分支变体

  • 制度宣贯：重在 FAQ 与口径统一，不一定有征集
  • 案例征集：需评审并转入 LeapCore 需求池
  • 命名征集等小活动：同机制，奖励按固定积分发放

10. 待确认问题

  • 活动统筹默认由总经办承担，还是由发起部门承担？
  • 积分发放归人事还是总经办？积分系统由谁维护？
  • 通知模板的最新版本存放在哪里？
  • 评审是否需要固定评委组？
CEO-22股东会筹备与决议（含主体设立/注销材料）待优化200

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：召开母公司年度股东会、子公司股东会，或因设立全资子公司、注销旧主体需要股东会决议与配套材料时启动
  • 负责人：主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——COO 汇报材料与股权结构（当前：常元和·推断待确认）、CEO 议案与决议（当前：邴龙志·推断待确认）、CTO 子公司会议发起与技术保障（当前：丁震宇·推断待确认）、行政接待与物料（当前：侯明月·推断待确认）、财务清税证明（当前：黄梦婷·推断待确认）、摄影（当前：宫经喜·推断待确认）、技术保障（当前：游家豪·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 定会期与议案 → ② 发会议通知 → ③ 会务清单拆分到人 → ④ 议案/决议/汇报材料准备 → ⑤ 会前 3 天复核 → ⑥ 打印用印 → ⑦ 召开与表决 → ⑧ 签署归档与工商衔接
  • 交付结果：会议通知、议案与股东会决议（已签署）、签到表与表决表、汇报材料、会议纪要；设立/注销时附股权结构与清税证明
  • 状态依据：母公司股东会已形成“提前约两周列清单、按事项拆 ddl 到人、会前复核”的固定做法，但无模板与时间线、靠个人提醒；子公司会议前一天才通知、设立/注销材料散落群内（2026-05～08）

1. 场景判定

  • 触发条件：年度股东会临近；子公司股东会需出决议；设立全资子公司、注销旧主体、股权变更需要股东会决议
  • 典型说法：「到场股东后续的行程安排、餐饮住宿的对接、现场布置、审议材料、表决材料、汇报材料都要开始安排了」「在准备股东会材料了」「需要打印五份，准备好公司章」
  • 判断问题：是否需要形成股东会决议？是否涉及外部股东到场？是否涉及工商登记变更？
  • 不归本流程管：期权/股权激励方案本身的起草与审议 → 请走 CEO-23；工商变更办理 → 请走 GEN-15（工商变更与新机构设立手续）；日常董事会/管理层会议 → 不在本流程

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
总统筹 时间线、清单、材料、用印、归档 R 综合部负责人（当前：赵雪冰·推断待确认）
议案与决议 议案内容、决议模板、对外股东沟通 A CEO（当前：邴龙志·推断待确认）
汇报材料/股权结构 汇报 PPT、新公司股权结构 R COO（当前：常元和·推断待确认）
子公司会议发起 子公司股东会发起、视频会议链接 R CTO（当前：丁震宇·推断待确认）
接待与物料 餐饮住宿用车、现场布置、签到 R 行政（当前：侯明月·推断待确认）
摄影与技术保障 摄影、投屏、网络 R 摄影（当前：宫经喜·推断待确认）、技术保障（当前：游家豪·推断待确认）
财务 清税证明、财务数据 C 财务负责人（当前：黄梦婷·推断待确认）
法务 通知期限、决议合规性审核 C 法务负责人（当前：待指定）

3. 办之前请准备

  • 公司章程（通知期限、表决规则）、股东名册与联系人
  • 上一次股东会材料与决议模板（极简版决议模板）
  • 议案清单及各议案负责人；设立/注销时：新公司股权结构、名称、注册资本、清税证明
  • 母公司公章/子公司公章使用申请

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定会期、议案清单与负责人，建会务清单任务（复制模板） 总统筹+CEO 年度会会前 30 日；子公司会会前 5 个工作日 飞书任务/多维表格 会务清单 🔧飞书固化
2 按章程发出会议通知（有限公司一般会前 15 日，章程另有规定从其约定） 总统筹 按章程期限 邮件/飞书 会议通知 👤人工判断
3 清单拆分到人并设 ddl：汇报材料、通知、签到/表决表、餐饮酒店用车、现场物料、摄影与技术保障 总统筹 会前 14 日 飞书任务 带 ddl 的任务 🔧+🤖
4 收集股东到场名单及是否需安排住宿餐饮 行政 会前 7 日 表单 到场名单 🔧飞书固化
5 议案、决议、汇报 PPT 初稿完成；设立/注销补股权结构与清税证明 各议案负责人、COO、财务 会前 7 日初稿，会前 3 日定稿 飞书文档（统一入口） 定稿材料 🤖+👤
6 会前复核：股东到场名单、接待、布置、汇报内容、嘉宾需携带材料 总统筹 会前 3 日 复核清单 复核记录 🔧飞书固化
7 打印决议、签到表、表决表（按股东数+备份），申请用印，确认会议室与投屏 总统筹、行政 会前 1 个工作日 用印审批 打印件 🔧飞书固化
8 召开会议、签到表决；子公司线上会由发起人建视频会议链接 总统筹 会议当天 飞书会议 签署件、纪要 👤人工判断
9 决议签署扫描归档；需工商变更的转 GEN-15 总统筹 会后 3 个工作日内 档案库 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：会议通知、议案、股东会决议（签署版）、签到表、表决表、汇报 PPT、会议纪要、照片；设立/注销附股权结构说明与清税证明
  • 建议模板/表单：
    • 会务清单模板：事项、负责人、ddl、状态、备注（预置以上 9 步，按会期自动倒推日期）
    • 股东会决议模板（年度/设立/注销三版）、会议通知模板、签到表、表决表
    • 公司事务日历：股东会、年检、年报、注销进度

6. 异常与升级

  • 子公司会议仅提前 1 天告知 → 总统筹当天完成打印用印，并记录为异常 → 会后提醒发起人按本流程时限
  • 新公司股权结构未定 → 决议用占位并标明待定 → 升级 CEO 在会前 3 日前拍板
  • 汇报材料会前 1 日仍未定稿 → 总统筹升级 COO/CEO（当天）
  • 清税证明未出 → 财务向税务机关催办 → 注销决议延后并通知股东
  • 股东临时无法到场 → 确认委托书或线上参会方式（会前 1 日）

7. 衡量指标

  • 通知合规率 = 按章程期限发出通知的会议数 / 会议数，目标 100%
  • 材料准时定稿率 = 会前 3 日定稿的材料数 / 材料总数，目标 ≥ 95%
  • 归档时长 = 会后到签署件归档的工作日，目标 ≤ 3
  • 人工催办次数，目标 ≤ 1 次/场

8. 低效诊断

  • 现象：清单靠群内文字列出，逐项追问是否完成，缺可追踪任务｜依据：「董事会专项沟通群」2026-05
  • 现象：会前复核在会议前一天凌晨才发出，当天才确认是否有汇报 PPT｜依据：「董事会专项沟通群」2026-05
  • 现象：股东到场人数、是否安排住宿反复询问｜依据：「董事会专项沟通群」2026-05
  • 现象：子公司股东会前一天才通知打印和备章｜依据：「董事会专项沟通群」2026-07
  • 现象：新公司股权结构迟迟未定，决议、通知、期权材料并行且散落群内｜依据：「董事会」2026-05

9. 分支变体

  • 母公司年度股东会：现场+接待+摄影，完整走 9 步
  • 子公司股东会：线上视频+打印决议+用印，可从步骤 5 开始，会前 5 个工作日启动
  • 设立全资子公司：需新公司股权结构与决议，注册由综合部办理
  • 注销旧主体：需注销决议与财务提供的清税证明，可应股东要求提供查阅

10. 待确认问题

  • 母公司章程规定的股东会通知期限是多少天？
  • 母公司公章与子公司公章的保管与用印审批人是谁？
  • 子公司股东会是否统一由综合部发起，而非业务负责人？
  • 设立/注销是否需要单独的 SOP（与 GEN-15 工商变更合并）？
CEO-23股权/期权激励方案起草与审议发放待新建100

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗5 × 跨4 × 险5

  • 适用场景：需要制定或修订期权/限制性股权激励方案并提交董事会、股东会审议，或发放一批期权时启动
  • 负责人：主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——董事会成员（当前：邴龙志、丁震宇、常元和·推断待确认）、法务（当前：待指定）、人事（当前：待指定）、财务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 起草方案与授予协议 → ② 法务审阅 → ③ 待决事项清单 → ④ 董事会集中讲解与决议 → ⑤ 定稿 → ⑥ 股东会审议 → ⑦ 授予协议签署发放 → ⑧ 发放汇报与遗留问题处理
  • 交付结果：股东会审议通过的激励方案、董事会决议记录、签署的授予协议、发放名册与汇报纪要
  • 状态依据：无成文流程，2026-05 方案连续三版返工，批注事项催促确认；2026-07 管理层两次预约才凑齐，子公司与代持范围事后又被追问

1. 场景判定

  • 触发条件：拟推出或调整股权/期权激励计划；股东会议程包含激励方案议案；新一批期权授予
  • 典型说法：「待明确内容：文内批注标黄部分，需董事会决议」「批注的部分需要尽快确认完善」「关于这一批次的期权发放简单汇报下」
  • 判断问题：是否涉及股份/期权的授予、份额、行权规则或持股平台？是否需要董事会或股东会决议？
  • 不归本流程管：积分激励与积分兑换期权认购资格的日常申报 → 请走 HR-18（积分激励制度运行）；股东会会务 → 请走 CEO-22；外部投资人入股 → 请走 CEO-27（融资推进与投资者关系管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
起草与协调 方案、授予协议起草，待决清单，预约会议，版本管理 R 综合部负责人（当前：赵雪冰·推断待确认）
决议 份额、估值、行权规则、范围决策 A 董事会成员（当前：邴龙志、丁震宇、常元和·推断待确认）
法务 条款审核、持股平台/代持结构建议 C 法务负责人（当前：待指定）
人事 激励对象名单、在职状态、离职处理衔接 C 人事负责人（当前：待指定）
财务 股份支付与税务影响 C 财务负责人（当前：待指定）
激励对象 签署授予协议 I 被授予员工

3. 办之前请准备

  • 公司章程、当前股权结构、已有激励计划及历次授予记录
  • 方案要素：激励对象类别、总量、授予价格、等待期与行权条件、退出与回购、持股平台
  • 授予协议模板
  • 管理层可用时间（提前锁定会议）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草方案与授予协议初稿，复杂条款加批注 起草人 启动后 5 个工作日内 飞书文档 初稿 🤖+👤
2 法务审阅并给出结构建议（持股平台、员工与外部人员分开） 法务 3 个工作日内 飞书审批/文档评论 法务意见 🔧+👤
3 汇总“待决事项清单”（每项列选项与建议） 起草人 法务意见返回后 1 个工作日 飞书文档 待决清单 🔧飞书固化
4 发董事会成员并预约 15～20 分钟集中讲解；会议提前锁定，不用临时预约 起草人 发稿时同时发日程，会议在 5 个工作日内 飞书日历 会议日程 🔧飞书固化
5 集中讲解后逐项决议，决议结果写入纪要并由与会董事确认 董事会 会上 飞书妙记 决议纪要 👤人工判断
6 按决议改写定稿，标注版本号与变更点，再发群确认 起草人 会后 2 个工作日内 飞书文档 定稿 🔧飞书固化
7 作为股东会议案提交审议（会务走 CEO-22） 起草人 按股东会时间线 — 股东会决议 👤人工判断
8 完善授予协议，组织激励对象签署，形成发放名册 起草人+人事 审议通过后 10 个工作日内 电子签/纸质 签署协议、名册 🔧飞书固化
9 批次发放后向管理层集中汇报并处理遗留问题 起草人 发放完成后 5 个工作日内 飞书会议 汇报纪要 👤人工判断

5. 交付物与模板

  • 交付物：激励方案定稿、授予协议、待决事项清单、董事会决议纪要、股东会决议、发放名册、汇报纪要
  • 建议模板/表单：
    • 待决事项清单：编号、事项、选项、建议、决议结果、决议人、日期
    • 版本记录：版本号、日期、变更点、确认人
    • 发放名册：对象、类别（核心/普通）、批次、授予数量、签署状态（数量字段仅限授权人查看）

6. 异常与升级

  • 董事会成员 5 个工作日内无法凑齐 → 改为书面逐项确认（文档评论+签字）→ 升级 CEO 决定
  • 涉及子公司员工或外部人员 → 法务出意见，原则上走持股平台，不纳入员工期权 → 董事会决议
  • 未经决议的口头承诺（如对子公司承诺期权/代持）→ 不得对外承诺，统一由起草人回复“以决议为准”
  • 激励对象离职 → 按协议回购/作废条款处理 → 人事通知起草人（离职当天）

7. 衡量指标

  • 方案版本数 = 从初稿到定稿的版本数，目标 ≤ 3
  • 决议周期 = 初稿发出到董事会决议的工作日，目标 ≤ 10
  • 协议签署率 = 审议通过后 10 个工作日内签署人数 / 激励对象数，目标 100%

8. 低效诊断

  • 现象：方案一个月内连续三版，批注事项靠群内催促确认｜依据：「董事会专项沟通群」2026-05
  • 现象：管理层集中汇报需多次预约才能凑齐｜依据：「董事会专项沟通群」2026-07
  • 现象：子公司与代持适用范围未在决议中写清，后续反复被追问｜依据：「董事会专项沟通群」2026-07
  • 现象：决议多为口头确认，缺留痕｜依据：「董事会专项沟通群」2026-05

9. 分支变体

  • 核心员工与普通员工两类，授予条件不同
  • 对外生态伙伴/个人投资者：走代持或持股平台，不纳入员工期权
  • 分子公司员工：适用范围需单独决议（见 CEO-24）

10. 待确认问题

  • 激励方案的决议机构是董事会还是管理层会议，股东会审议是否每次都需要？
  • 是否设立固定月度管理层议题会，用于股权与治理事项？
  • 法务审阅是否走飞书审批留痕？
  • 发放名册由综合部还是人事保管？
CEO-24分子公司/关联主体边界与权限管理待新建225

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：关联公司（EG、鼎慧、深圳、苏州、参股合资公司、曜途等）涉及积分、期权、福利、飞书账号、办公用品、人员兼岗、招聘考勤、项目资料同步等事项，需要判断是否共享、如何切割及对外口径时启动
  • 负责人：主责——综合部负责人（当前：赵雪冰·推断待确认）；协同——CTO 口径决策（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）、人事（当前：黄莹·推断待确认）、EG 负责人（当前：徐莉·推断待确认）、子公司 CEO（当前：赵捷·推断待确认）、曜途技术负责人（当前：白立新·推断待确认）、财务/法务/行政（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 识别涉及关联主体的事项 → ② 查边界清单 → ③ 未覆盖事项出建议 → ④ 会签 → ⑤ 管理层决策 → ⑥ 书面同步子公司 → ⑦ 账号权限与费用切割 → ⑧ 子公司项目定期同步 → ⑨ 季度复核
  • 交付结果：《关联主体边界清单》（可共享/不共享）、对外口径说明、飞书组织架构与权限调整记录、子公司服务边界约定、子公司项目周报与资料归档
  • 状态依据：子公司管理方案尚未出台；2026-08～09 积分、期权、福利对子公司的适用范围口径不一，零食福利共用两个月后才考虑切割，兼岗人员归属无规则

1. 场景判定

  • 触发条件：新制度/福利发布时需判断是否覆盖子公司；子公司人员要用积分、期权、飞书、办公用品；员工同时在两家主体任职；母公司为子公司代招人员或代办人事；子公司承接项目需向母公司同步
  • 典型说法：「那边不能用积分」「对外口径一定是完全独立营运，我们只提供顾问服务」「有的人同时在两个公司任职怎么说」「微信发的文件在飞书这边也同步一份」
  • 判断问题：该事项的受益人或执行人是否属于另一法人主体？是否涉及成本、权益、数据权限或对外口径？母公司是控股还是参股？
  • 不归本流程管：子公司股东会与设立/注销 → 请走 CEO-22；期权方案本身 → 请走 CEO-23；子公司内部日常经营 → 由子公司自行管理

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
边界梳理与口径发布 维护边界清单、出建议、对外补充说明、组织架构与权限梳理 R 综合部负责人（当前：赵雪冰·推断待确认）
口径决策 治理与对外口径、股权相关安排 A CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）
人事 代招、兼岗岗位设置、考勤与入离职边界 R 人事负责人（当前：黄莹·推断待确认）
财务 费用分摊与切割、发薪主体 C 财务负责人（当前：待指定）
法务 服务边界协议、合规审查 C 法务负责人（当前：待指定）
行政 办公用品、福利共用的切割 C 行政负责人（当前：待指定）
IT 飞书组织架构与账号权限调整 R IT 运维（当前：杨明学·推断待确认）
子公司负责人 接收指导意见、反馈人事事项、按时同步项目 I/R EG 负责人（当前：徐莉·推断待确认）、子公司 CEO（当前：赵捷·推断待确认）、曜途技术负责人（当前：白立新·推断待确认）

3. 办之前请准备

  • 关联主体清单：主体名称、持股关系（控股/参股）、负责人、已拆分事项
  • 现行《关联主体边界清单》、福利制度说明（武汉模态跃迁主体，其他子公司参照）
  • 涉及人员名单（兼岗、代招、共用账号）
  • 飞书组织架构与系统账号现状

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新制度/福利/系统发布前，发起人勾选“是否涉及关联主体”，涉及则提交综合部 发起部门 发布前 3 个工作日 飞书表单 待判事项 🔧飞书固化
2 查边界清单；已有结论直接按清单执行 综合部负责人 1 个工作日内 边界清单（多维表格） 适用结论 🔧飞书固化
3 清单未覆盖：出建议（适用范围、成本分摊、对外口径、是否需协议） 综合部负责人 2 个工作日内 飞书文档 建议稿 🤖+👤
4 财务、法务、人事、行政会签 相关职能 2 个工作日内 飞书审批 会签意见 🔧飞书固化
5 管理层决策并留纪要；未决之前不对子公司做口头承诺 CTO/CEO 3 个工作日内 飞书会议 决策纪要 👤人工判断
6 更新边界清单，书面单向同步给子公司负责人（只给指导意见，不介入管理） 综合部负责人 决策后 1 个工作日 飞书消息/文档 同步记录 🔧飞书固化
7 执行切割：飞书组织架构与账号权限调整（兼岗设两个岗位；鼎慧保留业务与市场人员，产研不放）、福利与办公用品费用切割 人事、IT、行政、财务 决策后 10 个工作日内 飞书管理后台 调整记录 🔧飞书固化
8 子公司承接项目每周同步进度、纪要与资料；微信文件同步上传飞书；对外汇报材料经 CTO review 子公司负责人 每周五 飞书文档/知识库 项目周报、资料归档 🔧+🤖
9 每季度复核边界清单与账号权限，清理离开主体的人员账号 综合部负责人 每季度首月 10 日前 多维表格 复核记录 🔧飞书固化

5. 交付物与模板

  • 交付物：关联主体边界清单、对外口径说明、子公司服务边界约定、组织架构与权限调整记录、子公司项目周报
  • 建议模板/表单：
    • 边界清单：事项类别（积分/期权/福利/飞书/办公用品/招聘/考勤/薪资/系统）、主体、是否共享、成本承担方、依据（决策纪要链接）、生效日期、复核日期
    • 子公司服务边界约定：母公司提供的服务（代招、背调、顾问）、子公司自理事项（发薪、考勤、社保）、反馈渠道与时限
    • 子公司项目周报：进展、风险（含产品权属）、下周计划、资料链接、需母公司支持事项

6. 异常与升级

  • 已对子公司作出与清单不一致的口头承诺 → 综合部负责人 2 个工作日内书面更正 → 升级 CEO
  • 兼岗人员归属/薪资主体不清 → 人事+财务出方案 → 升级 CTO/CEO（5 个工作日内）
  • 子公司人事事项（考勤异常、入离职）无人反馈 → 人事按服务边界约定转子公司负责人，超过 5 个工作日无回应升级 CTO
  • 子公司项目存在产品权属或合规风险 → 暂停对外销售 → 法务评估后升级 CTO（当天）
  • 子公司人员无法连接内部系统/找不到对接人 → 按清单指定的 IT 对接人处理（1 个工作日内）

7. 衡量指标

  • 边界清单覆盖率 = 已有结论的事项类别数 / 应覆盖类别数，目标 100%
  • 口径冲突次数 = 每季度对子公司口径不一致被追问次数，目标 0
  • 事项判定周期 = 提交到决策的工作日，目标 ≤ 7
  • 子公司周报按时率，目标 ≥ 90%

8. 低效诊断

  • 现象：积分、期权对子公司的适用范围前后口径不一，出现未经决议的承诺｜依据：「董事会专项沟通群」2026-08、2026-09
  • 现象：口径讨论上下文只在小范围会议中，负责对外说明的岗位未获同步｜依据：「董事会专项沟通群」2026-08
  • 现象：福利与办公用品共用两个月后才考虑切割，属事后补流程｜依据：「董事会专项沟通群」2026-09
  • 现象：兼岗人员在哪个主体任职、如何管理无规则｜依据：「董事会专项沟通群」2026-08
  • 现象：子公司项目文件在外部即时通讯工具流转，内部系统账号不知找谁开通｜依据：「曜途同步群」2026-07

9. 分支变体

  • 控股子公司（EG、鼎慧、深圳、苏州）：财务、线下办公、营业投入、人事管理已拆分；飞书与办公用品按清单逐项切割
  • 参股合资公司：母公司人事可代招（含背调），但发薪、考勤、人事事务归子公司，子公司注册完成后再办入离职；需签服务边界约定
  • 承接外部产品的子公司：重点是项目周报、资料入飞书、产品权属核查，对外汇报材料经 CTO review
  • 对外口径：统一为“完全独立运营，母公司只提供顾问服务”

10. 待确认问题

  • 边界清单的维护人与决策人分别是谁（综合部负责人维护、CTO 还是 CEO 决策）？
  • 参股合资公司的社保公积金缴纳地、招聘代办费用如何约定？
  • 鼎慧兼岗人员“业务与市场留、产研不放”是否已成为正式规则？
  • 子公司管理手册计划何时出台？
  • 子公司人员是否继续使用母公司飞书租户？
CEO-25重大突发事件与危机应对（舆情、监管、重大事故）待新建推断125

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨5 × 险5

  • 适用场景：发生可能严重影响公司声誉、经营或合规的事件，如重大客户事故、大规模数据泄露、负面舆情、监管约谈/检查、人员安全事件、核心供应商断供
  • 负责人：主责——总经办负责人（当前：田杰·部门报送人）；协同——研发负责人、品牌负责人（当前：何思雨·部门报送人）、法务（当前：待指定）、销售负责人（当前：待指定）、人事（当前：待指定）；兜底——总经办（当前：田杰·部门报送人）
  • 核心流程：① 上报总经办 → ② 分级 → ③ 成立应急小组 → ④ 统一对内对外口径 → ⑤ 处置与定时同步 → ⑥ 宣告结束 → ⑦ 复盘整改
  • 交付结果：事件分级记录、应急小组名单、对外声明/口径、进展通报、复盘报告
  • 状态依据：已有 RND-75（线上故障响应与复盘）、BRD-12（媒体采访对外口径）、CEO-17（政府对接与政策风险应对）覆盖单类事件处置，本条补齐公司级突发事件分级与统一指挥（推断）

1. 场景判定

  • 触发条件：影响多家客户或重点客户的事故；媒体/社交平台负面报道；监管部门来电、约谈、检查；人员伤亡；核心模型或云供应商长时间不可用
  • 典型说法：「网上有人在发我们的负面」「监管部门打电话要我们说明情况」「重点客户全部用不了了」
  • 判断问题：是否超出单个部门处置能力，或需要公司统一对外表态？
  • 不归本流程管：常规技术故障 → 请走 RND-75；数据泄露技术处置 → 请走 X-SEC-44；日常政府对接 → 请走 CEO-17；媒体采访接待 → 请走 BRD-12；一般负面舆情的监测与回应 → 请走 BRD-18；监管问询与执法调证的法律处置 → 请走 LEG-33；停电/天气 → 请走 ADM-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
应急指挥 分级、拉组、决策 A CEO（当前：邴龙志·推断待确认）
应急协调 组织会议、跟进进展、记录 R 总经办负责人（当前：田杰·部门报送人）
技术处置 技术止损与恢复 R 研发负责人（当前：丁震宇·部门报送人）
发现人 发现后电话+飞书上报总经办 R 全体员工
应急小组 按分工处置并定时同步进展 R 由应急指挥按事件指定（上述各角色）
对外口径 声明起草、舆情监测 R 品牌负责人（当前：何思雨·部门报送人）
法务 法律风险评估与文本审核 C 法务（当前：待指定）
客户沟通 重点客户逐一通知 R 销售负责人（当前：待指定）

3. 办之前请准备

  • 事件发生时间、影响范围、已采取措施、已知外部反应
  • 应急联络表（各负责人电话与备份人），预先维护

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 任何人发现后电话+飞书上报总经办 发现人/部门负责人 发现后 30 分钟内 电话/飞书 事件上报 👤人工判断
2 按影响定一级（公司级）/二级（部门可控） 总经办负责人+CEO 上报后 30 分钟内 — 分级结论 👤人工判断
3 一级事件建应急群，明确指挥、技术、口径、客户、法务 总经办负责人 分级后 30 分钟内 飞书群 应急小组 🔧飞书固化
4 发布对内口径，未经授权不得对外发言 品牌负责人+法务 2 小时内 飞书 口径文本 👤人工判断
5 处置并每 2 小时在应急群同步进展 应急小组 持续至结束 飞书群 进展记录 🔧飞书固化
6 指挥宣告结束，对外发布结论（如需要） CEO 恢复后 1 个工作日内 官方渠道 结束声明 👤人工判断
7 复盘并分派整改任务 总经办负责人 结束后 5 个工作日内 知识库/飞书任务 复盘报告 🔧飞书固化

5. 交付物与模板

  • 交付物：事件记录、口径文本、进展记录、复盘报告
  • 建议模板/表单：事件记录字段——事件类型、级别、发现时间、影响范围、小组成员岗位、关键决策、对外动作、结束时间、整改项

6. 异常与升级

  • CEO 联系不上 → 按授权顺序由联合创始人代行指挥（顺序预先在 CEO-05 中明确）
  • 监管要求限期书面说明 → 法务牵头，按要求时限提交

7. 衡量指标

  • 分级响应时长 = 上报到成立应急小组，目标 ≤ 1 小时
  • 复盘整改项按期完成率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在事件发生时多人各自对外表态、口径不一、决策延误扩大损失的风险（推断）

9. 分支变体

  • 子公司/关联主体事件由主体负责人上报，涉及集团品牌时按本流程统一处理
  • 俱乐部资金类事件同步财务负责人

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 一级事件的判定标准与代行指挥顺序如何确定？
  • 对外发言人是否固定为某一岗位？
CEO-26年度经营预算审定与月度经营分析待新建推断180

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：年度开始前审定各部门、各主体经营预算（收入、人力、采购、云与模型成本、市场费用）；每月召开经营分析会，对比预算与实际并决策调整
  • 负责人：主责——总经办负责人（当前：田杰·部门报送人）；协同——财务负责人（当前：黄梦婷·部门报送人）、各部门负责人、各主体负责人；兜底——总经办（当前：田杰·部门报送人）
  • 核心流程：① 下发预算模板 → ② 各部门编报 → ③ 财务汇总测算 → ④ 管理层审定 → ⑤ 发布预算 → ⑥ 每月出经营数据 → ⑦ 经营分析会 → ⑧ 决议跟踪
  • 交付结果：年度预算表、月度经营数据包、经营分析会纪要与决议清单
  • 状态依据：已有 CEO-01（年度规划与目标分解）、HR-03（HC 与人力成本统计）、FIN-09（活动费用预算）覆盖目标与单项预算环节，本条补齐年度经营预算审定与月度经营分析会（推断）

1. 场景判定

  • 触发条件：每年 11 月启动下一年度预算；每月第 5 个工作日出上月数据；重大偏差或业务调整需调预算
  • 典型说法：「今年云和模型成本到底花了多少」「这个月各条线收入和预算差多少」
  • 判断问题：事项是否涉及全年/全公司资源总量或跨部门取舍？
  • 不归本流程管：年度目标规划 → 请走 CEO-01；HC 申请 → 请走 HR-03；预算模板、部门编报汇总与月度执行分析的财务执行 → 请走 FIN-43（本流程负责审定与经营分析会决策）；资金缺口与借款 → 请走 FIN-39；子公司月度营收 → 请走 FIN-34；云成本归集 → 请走 FIN-30；单笔采购付款 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
预算组织 下发模板、组织评审与分析会、跟踪决议 R 总经办负责人（当前：田杰·部门报送人）
财务 汇总测算、提供实际数据与偏差分析 R 财务负责人（当前：黄梦婷·部门报送人）
部门/主体负责人 编报预算、解释偏差 R 各部门/主体负责人
审定 批准预算与调整 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 上年度实际收入、成本、人力数据；CEO-01 的年度目标
  • 预算模板（收入、人力、采购、云/模型、市场、行政，按主体拆分）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 下发年度预算模板与编制口径 总经办负责人 每年 11 月 15 日前 飞书表格 模板 🔧飞书固化
2 各部门/主体编报 部门/主体负责人 下发后 10 个工作日内 飞书表格 部门预算 👤人工判断
3 汇总测算现金流与利润 财务负责人 收齐后 5 个工作日内 表格 汇总预算 🤖自动化
4 管理层评审审定并发布 CEO+总经办负责人 12 月底前 会议 年度预算 👤人工判断
5 出上月经营数据包（收入、成本、现金、人力、预算偏差） 财务负责人 每月第 5 个工作日前 金蝶/表格 数据包 🤖自动化
6 召开经营分析会，偏差超阈值部门说明原因与措施 总经办负责人 每月第 8 个工作日前 会议 纪要与决议 👤人工判断
7 决议录入台账并跟踪 总经办负责人 会后 1 个工作日内 飞书任务 决议台账 🔧飞书固化

5. 交付物与模板

  • 交付物：年度预算、月度数据包、分析会纪要、决议台账
  • 建议模板/表单：月度数据包字段——主体、部门、科目、预算数、实际数、偏差率、偏差原因、措施、责任岗位

6. 异常与升级

  • 单科目月度偏差超 20% → 部门负责人书面说明 → 分析会决策
  • 需追加预算 → 部门提调整申请 → CEO 审批（5 个工作日内）

7. 衡量指标

  • 数据包按期出具率，目标 100%
  • 预算执行偏差率（季度），目标 ≤ 10%

8. 低效诊断

  • 聊天中未见相关流程，存在成本总量失控、逐笔审批耗费管理层精力、跨主体资源无法统一取舍的风险（推断）

9. 分支变体

  • 子公司/合资主体单独编制预算并按股东要求报送
  • 研发费用需同时满足 FIN-31 归集口径

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 预算由总经办还是财务主导组织？
  • 偏差阈值 20% 与月度分析会频率是否合适？
CEO-27融资推进与投资者关系管理待新建推断100

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨4 × 险5

  • 适用场景：公司启动新一轮融资，或需向现有投资人定期报送经营信息、响应投资人问询与尽调
  • 负责人：主责——融资/投资者关系负责人（当前：待指定）；协同——财务负责人（当前：黄梦婷·部门报送人）、法务（当前：待指定）、研发负责人、总经办（当前：田杰·部门报送人）；兜底——总经办（当前：田杰·部门报送人）
  • 核心流程：① 融资启动决策 → ② 准备材料与数据室 → ③ 投资人接触与保密协议 → ④ 尽调响应 → ⑤ 条款谈判与决策 → ⑥ 交割 → ⑦ 投后定期报告
  • 交付结果：融资计划、商业计划书、数据室、尽调问答记录、交割文件、投后定期报告
  • 状态依据：已有 CEO-22（股东会筹备与决议）、CEO-23（期权激励方案）、FIN-36（审计与尽调财务资料准备）覆盖部分环节，本条补齐融资推进与投资者信息披露的统一管理（推断）

1. 场景判定

  • 触发条件：管理层决定启动融资；投资人来函问询或要求尽调；季度/年度投后报告到期
  • 典型说法：「投资人要最新的经营数据」「尽调清单下来了，谁来准备」
  • 判断问题：信息是否发给外部投资人或潜在投资人？是否涉及股权、估值或公司未公开经营数据？
  • 不归本流程管：股东会决议与会务 → 请走 CEO-22；审计/投标财务资料 → 请走 FIN-36；工商变更 → 请走 GEN-15；临时借款 → 请走 FIN-39；协议签署盖章 → 请走 LEG-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
融资负责人 计划、材料、投资人沟通、进度 R 融资/投资者关系负责人（当前：待指定）
财务 财务数据、预测模型、尽调财务部分 R 财务负责人（当前：黄梦婷·部门报送人）
法务 保密协议、条款审核、法律尽调 R 法务（当前：待指定）
研发负责人 技术尽调与产品数据 C 研发负责人（当前：丁震宇·部门报送人）
决策 启动、条款与签约决策 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 最新股权结构、期权池、历史融资文件
  • 近期财务报表、经营数据、客户与合同汇总（对外版本脱敏）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定融资目标、节奏、负责人 CEO+融资负责人 启动前 会议 融资计划 👤人工判断
2 准备商业计划书与数据室，统一数据口径 融资负责人+财务 启动后 15 个工作日内 受控云盘 BP/数据室 🤖自动化
3 接触前签保密协议，登记投资人与发出材料版本 融资负责人+法务 发材料前 多维表格 投资人台账 🔧飞书固化
4 按清单分派尽调问题并统一审核后答复 融资负责人 收到清单后 10 个工作日内 多维表格 尽调问答 🔧+🤖
5 条款谈判，法务审核，CEO 决策 法务+CEO 按谈判进度 — 条款清单 👤人工判断
6 交割：决议、协议签署、资金到账、工商变更 法务+财务 按协议约定 — 交割文件 👤人工判断
7 按约定向投资人报送季度/年度经营报告 融资负责人+财务 季度结束后 30 日内 邮件 投后报告 🔧飞书固化

5. 交付物与模板

  • 交付物：融资计划、BP、数据室、投资人台账、尽调问答、投后报告
  • 建议模板/表单：投资人台账字段——机构、对接人岗位、阶段、保密协议日期、已发材料及版本、下一步、负责人

6. 异常与升级

  • 投资人索取客户明细或源代码 → 法务审查后以脱敏或现场查阅方式提供 → CEO 批准
  • 对外数据口径冲突 → 以财务确认数据为准，融资负责人统一修正

7. 衡量指标

  • 尽调问题按期答复率，目标 ≥ 95%
  • 投后报告按期报送率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在对外数据口径不一、敏感信息未签保密即外发、投后报告逾期影响投资人关系的风险（推断）

9. 分支变体

  • 子公司/合资主体融资由主体负责人主责，集团总经办协同
  • 政府引导基金另需满足申报与合规材料要求

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 融资与投资者关系由哪个岗位主责？
  • 现有投资协议对信息披露频率与内容有何约定？

ADM 行政

报送人：胡则瑾 · 综合 · 36 条 · 已有 0 / 待优化 20 / 待新建 16
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
ADM-01办公场地选址、租赁、装修与搬迁现有场地工位饱和、租约到期/提前退租，或需新增办公点/展厅时，从选址评估一直走到装修验收、整体搬迁和原场地退租主责——行政负责人（当前：胡则瑾·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求立项 → ② 踩点与场地对比表 → ③ 决策会拍板 → ④ 商务谈判（租金/免租期/发票）→ ⑤ 合同审核与用印 → ⑥ 施工准备（物业三方签字、押金）→ ⑦ 施工跟踪与验收 → ⑧ 搬迁与退租已签署的租赁合同（含发票条款）、装修验收单与空气检测报告、搬迁完成通知、退租交接单及押金退还记录待新建250
ADM-02工位调整与座位安排组织调整、团队扩招、分区搬迁或新增场地，需要重新排座位、调整桌椅并同步全员时主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、CTO（当前：丁震宇·推断待确认）、行政专员（当前：侯明月·推断待确认）、各部门负责人（当前：杨萌、李凯、陈梦琪等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交工位变更申请 → ② 核对工位台账 → ③ 定分区方案 → ④ 发布座位表 → ⑤ 桌椅补齐 → ⑥ 统一搬迁 → ⑦ 更新台账已发布的最新座位表（多维表格）、完成搬迁的工位、更新后的工位台账待优化72
ADM-03新员工入职行政准备（工位、电脑、领用登记）人事确认新员工/实习生到岗日期后，到岗前备好工位、电脑/显示器/开发机及办公用品，到岗当天完成发放与领用登记主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、IT 运维负责人（当前：杨明学·推断待确认）、运维工程师（当前：游家豪·推断待确认）、行政专员（当前：侯明月·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职信息推送 → ② 工位确认 → ③ 配置判定 → ④ 库存核对/采购 → ⑤ 预装系统 → ⑥ 工牌门禁账号 → ⑦ 到岗发放与登记 → ⑧ 清单关闭到岗当天可用的工位和预装好的设备、已填写的领用登记、全部勾选完成的入职准备清单待优化144
ADM-04工牌制作与门禁/钥匙/临时密码管理新人领工牌、批量换版工牌、门禁指纹/NFC 录入、门卡遗失，以及装修/保洁/空调师傅或访客需要临时进门时主责——行政专员（当前：侯明月·推断待确认）；协同——行政助理（当前：丁蕊·推断待确认）、IT 运维/门锁管理员（当前：杨明学·推断待确认）、门锁 App 持有人（当前：宋祺睿·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——行政负责人（当前：胡则瑾·推断待确认）① 入职触发工牌采集 → ② 按月批次制作 → ③ 发放签收 → ④ 门禁录入 → ⑤ 临时授权（限时密码+登记）→ ⑥ 遗失补办/离职注销 → ⑦ 月度权限盘点已发放并签收的工牌、门禁权限台账（含临时授权记录和到期时间）待新建72
ADM-05会议室预约与公共空间使用规范开会、演示、培训、分享会、1v1 需要会议室，或出现会议室冲突、公共空间使用纠纷（不关灯关门、午休噪音）时主责——行政专员（当前：侯明月·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、人事负责人（当前：黄莹·推断待确认）、905 区域行政（当前：董蓝汐·推断待确认）、各会议组织者；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 飞书预约（按人数选房）→ ② 冲突处理 → ③ 签到/超时释放 → ④ 使用 → ⑤ 会后复原 → ⑥ 每日巡检 → ⑦ 月度复盘有记录的会议室预约、按规则释放的空闲时段、公示的公共空间使用规范与巡检记录待优化100
ADM-06外部来访接待与参观/拍摄报备客户、供应商、领导、院校、政府、媒体来访，外部朋友/合作方参观，或在办公点拍摄时，从报备到现场接待、费用与归档主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、CRM/接待表管理员（当前：闫登辉·推断待确认）、CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交接待申请 → ② 行政确认并预留资源 → ③ 分级审批（拍摄/政府/媒体）→ ④ 前一天同步物业与客户 → ⑤ 现场接待与场控 → ⑥ 宴请与费用 → ⑦ 当日归档接待登记记录（含照片、纪要、费用）、已确认的会议室与物业配合事项、拍摄审核记录待优化240
ADM-07面试会议室预约与候选人到访接待线下或线上面试排期确定后，预约合适会议室与设备，并在候选人到访时引导、接待直至送离主责——HR 招聘专员（当前：张欣怡·推断待确认）；协同——HR 招聘助理（当前：匡蓉·推断待确认）、面试官（当前：丁震宇、陈晖、王皓南、张东郅等·推断待确认）、IT 运维（当前：杨明学·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 排期确定 → ② 预约合适会议室 → ③ 前一天复核 → ④ 发到访指引 → ⑤ 到访接待 → ⑥ 面试进行 → ⑦ 送离并释放会议室已绑定会议室的面试日程、候选人到访登记、面试结束后释放的会议室待优化90
ADM-08办公设施故障报修与维修验收空调、门锁、门窗、灯具、插座、电闸、卫生间、漏水、网络/AP、机房过热、家具、咖啡机等设施损坏或异常时，从报修到师傅上门、验收、费用与复盘主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外部物业/厂家；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 表单报修 → ② 自动分派 → ③ 初判与预计时间 → ④ 比价/审批 → ⑤ 预约上门 → ⑥ 维修与现场验收 → ⑦ 关单记费用 → ⑧ 重复故障复盘关闭的报修工单（含照片、费用、供应商、质保期）、应急联系人表、重复/重大故障复盘记录待新建225
ADM-09停电/极端天气等突发事件通知与居家办公安排办公楼计划停电/修闸、突发断电断网、网络线路割接，或台风暴雨等极端天气影响通勤与办公时，统一发布通知并决定到岗、居家或换点办公。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——IT运维（当前：杨明学·推断待确认）、产研通知对接人（当前：杨萌·推断待确认）、管理层决策人（当前：丁震宇、常元和、邴龙志·推断待确认）；兜底——综合部负责人① 获知事件并分级 → ② 行政与 IT 拉齐影响范围 → ③ 管理层定到岗/居家方案 → ④ 发布唯一口径加急通知 → ⑤ 停电前按清单关服务 → ⑥ 员工报备与换点办公 → ⑦ 恢复确认与复盘一条统一口径、已加急并确认已读的通知；服务器按清单关停与恢复的记录；居家/换点办公报备记录；事件复盘记录待新建96
ADM-10下班及节假日离岗安全检查（断电、锁门、机房）每天下班最后离开办公区时，以及周末、长假前，完成关灯、空调、电视、电脑与电源，锁好门窗，并确认机房和远程机器的断电或保电安排。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月、丁蕊·推断待确认）、IT运维（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·推断待确认）、各区域最后离开者；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建分区域设备台账与关闭图文 → ② 门口张贴离岗清单 → ③ 最后离开者按清单检查 → ④ 次日早抽查与异常登记 → ⑤ 节前征询保电需求 → ⑥ IT 确认机房/远程机器保电范围 → ⑦ 节前通知与当晚巡检 → ⑧ 节后恢复确认张贴的离岗检查清单与空调等设备关闭图文；每日抽查与节前巡检记录；节假日断电范围与保电设备清单；纳入入职培训的办公区安全规范待新建160
ADM-11办公区保洁、值日、大扫除与虫害消杀办公区日常卫生维护、外包保洁、节前/夏季大扫除、装修后清理，以及出现蟑螂、蚊虫、异味、积水等卫生事件时，安排值日、保洁或消杀并验收。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——卫生委员（当前：侯明月、赵雪冰·推断待确认）、各组组长/卫生小组长、外包保洁、消杀服务商；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 划分区域并发布月度值日表 → ② 值日人每日整理 → ③ 外包保洁每周清洁拍照 → ④ 行政验收 → ⑤ 杂物清运 → ⑥ 定期大扫除 → ⑦ 定期消杀 → ⑧ 卫生事件即时处置月度值日表与完成记录；保洁验收记录（含照片）；大扫除与消杀日历及执行记录；卫生事件处置记录待优化48
ADM-12行政制度与办公规范制定发布需要建立或修订采购、接待、福利、报销等公司级行政制度，或发布办公室使用规范（卫生间、门、空调、会议室规则）时，统一由行政起草、相关部门会签、审批后发布并入库。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、行政助理（当前：丁蕊·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总助/总经办（当前：赵雪冰·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 提出制度/规范需求 → ② 行政登记立项 → ③ 起草初稿 → ④ 财务/人事/相关部门会签 → ⑤ 总助审核、CEO 审批 → ⑥ 发布公告与张贴 → ⑦ 入制度库并培训 → ⑧ 定期复审经审批的制度文件或规范（带编号与版本）、发布公告、现场张贴物、制度库条目待优化96
ADM-13行政事务归口、交接与行政日报快递、报修、打印、保洁、物品领用、会议室等行政杂务没有明确承接人，行政岗位变动、空缺或由实习/兼职助理承担，以及行政人员每日工作汇报时。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员/助理（当前：侯明月、丁蕊·推断待确认）、财务（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CTO（行政缺位时的临时协调，当前：丁震宇·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 编制行政事务归口清单 → ② 设统一受理入口 → ③ 公示岗位分工与在岗时间 → ④ 每日提交日报 → ⑤ 跨部门事项同步总经办 → ⑥ 岗位变动按清单交接 → ⑦ 空缺期指定代理人 → ⑧ 每周复盘未结事项行政事务归口清单（每项有主责、备岗、入口、时限）；行政服务受理台账；每日行政日报；岗位交接清单与签收记录待新建135
ADM-14办公物资/家具申购与行政服务需求受理员工需要桌椅、柜子、打印机、取暖设备、屏风等物资，消耗品（饮用水、纸巾、垃圾袋、洗手液）用完，需要占用场地放置物品，或需要行政配合摆放、清理、布置会场时，统一受理、选型、采购或授权垫付、交付验收并集中收票。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT运维（网络/设备/门锁，当前：杨明学·推断待确认）、总助（场地占用审批，当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、需求方；审批——预算审批人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求方提交申请单 → ② 行政受理分类 → ③ 选型比价并请需求方确认 → ④ 按金额阈值审批 → ⑤ 下单或授权垫付 → ⑥ 到货通知、签收、组装 → ⑦ 需求方验收 → ⑧ 订单与发票入表、报销或月度集中结算已验收交付的物资或服务；带订单号、下单人、供应商的需求台账；齐全的发票与报销/结算记录；公示的消耗品存放位置与库存表待优化180
ADM-15快递代收、公共物品借用与失物招领快递或供应商送货到公司、需要借用公共物品（U 盘、吸尘器、工具箱、拖车、清洗机、测试机等）、发现遗落物品，或有陌生人员上门推销、找人时，按规则登记、通知、借还、认领与引导。主责——行政专员（当前：侯明月·推断待确认）；协同——IT运维（IT 类公共设备，当前：杨明学·推断待确认）、运维/交付工程师（打印机与设备登记，当前：游家豪·推断待确认）、当日前台值守人；兜底——综合部负责人① 建公共物品台账与位置标签 → ② 发布办公指南 → ③ 快递到件登记并通知 → ④ 借用登记与按期归还 → ⑤ 遗落物品登记与限期认领 → ⑥ 陌生来访识别与引导 → ⑦ 月度盘点公共物品台账（含位置与保管人）；办公指南（打印机、会议室、物资位置、门禁获取方式）；快递登记与认领记录；借还记录；失物招领记录待新建72
ADM-16对外寄件与快递月结向客户或供应商寄送交付机器、签收单、合同材料，或设备寄修时，统一登记收件信息、使用公司快递月结账户发货、回填单号并同步相关人员，月底对账。主责——行政负责人（月结账户与寄件规则，当前：胡则瑾·推断待确认）；协同——IT运维/寄件执行（当前：杨明学·推断待确认）、交付统筹（收件信息确认，当前：杨萌·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（月结对账，当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 寄件人提交寄件登记 → ② 交付统筹确认收件信息 → ③ 打包与保价判断 → ④ 用公司月结账户下单 → ⑤ 回填单号并同步需求群 → ⑥ 跟踪签收 → ⑦ 月度对账寄件登记台账（含收件信息、物品、单号、签收状态）；按时签收的寄件；月结账单与台账核对记录待优化90
ADM-17零食福利月度采购与额度/报销管理每月员工零食饮料福利，从系统开放选购（或部门自行收集需求）到截单、统一采购、到货分发、发票核对与报销结算的全过程主责——行政负责人（当前：胡则瑾·推断待确认）；协同——总经办通知专员（当前：王欣·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、零食系统维护人（当前：丁震宇·推断待确认）、各部门零食汇总人（当前：杨萌、陈梦琪、杨明学、游家豪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 生成当月名单与额度 → ② 开放选购并通知 → ③ 截止前催确认 → ④ 锁单汇总 → ⑤ 统一下单 → ⑥ 到货分发 → ⑦ 收票报销 → ⑧ 月度复盘当月采购汇总单、到货分发记录、按部门/月份归档的“发票+付款凭证”报销包、更新后的需求与 BUG 看板待优化108
ADM-18节日福利与员工福利物资发放节日或公司决定向员工统一发放福利物资（节日礼盒、福利图书、定制周边等），从立项、意向收集/投票、采购或定制，到发放签收主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（周边打样与供应商对接）（当前：杨明学·推断待确认）、福利发起与定调人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定预算与截止 → ② 出方案/打样 → ③ 意向收集或投票（设默认方案）→ ④ 汇总下单 → ⑤ 到货验收 → ⑥ 发放签收 → ⑦ 报销归档福利方案（含预算上限、默认方案、截止时间）、选择/投票结果、采购订单与发票、发放签收表待优化36
ADM-19活动定制物料与对外礼品（工服、伴手礼、品牌周边赠送登记）大会、董事会等活动需要统一工服，或对外需要伴手礼、宣传册、品牌周边，以及样品借用和向合作伙伴赠送物品主责——行政负责人（当前：胡则瑾·推断待确认）；协同——市场/品牌需求方（当前：许君·推断待确认）、设计（当前：康紫馨·推断待确认）、行政专员（尺码统计、出入库登记）（当前：侯明月·推断待确认）、活动现场发放（当前：林子淇、康紫馨·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求提报 → ② 倒排排期 → ③ 询价并确认工期 → ④ 设计与文案定稿 → ⑤ 款式/尺码统计 → ⑥ 下单 → ⑦ 到货验收入库 → ⑧ 发放/赠送出库登记物料排期表、供应商工期确认单、定稿设计文件、到货验收记录、出入库（发放/赠送/借用）登记台账待新建72
ADM-20团建、聚餐与全员活动组织组织月度生日会、季度/破冰团建、周年庆、程序员节、年终聚餐、团队聚餐、培训日用餐等内部活动，从方案预算到通知报名、保险交通、订位执行和报销主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（通知与执行）（当前：侯明月·推断待确认）、行政助理（策划与保险）（当前：丁蕊·推断待确认）、人事负责人（人员名单）（当前：黄莹·推断待确认）、CEO（方案与预算拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项（目的、时间、预算）→ ② 方案与比价 → ③ CEO 审批 → ④ 通知与表单报名 → ⑤ 保险、交通、订位 → ⑥ 现场签到执行 → ⑦ 报销与复盘活动方案（含预算）、报名名单、保险名单、供应商合同/订单、签到表、发票报销单、复盘记录待优化108
ADM-21全员年会筹办公司决定举办全员年会/全员大会后，在约 2 周内完成定日期、找场地、设计流程与互动、发邀请函、订餐、物料与布置主责——行政（年会筹办牵头）（当前：侯明月·推断待确认）；协同——人事负责人（邀请与人员）（当前：黄莹·推断待确认）、创始人兼 CTO（内容、视频与 PPT）（当前：丁震宇·推断待确认）、CEO（形式、场地、流程拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定日期与预算 → ② 场地比价锁定 → ③ 流程与奖品方案 → ④ CEO 定稿 → ⑤ 邀请函发出 → ⑥ 订餐与物料 → ⑦ 布置彩排与当天签到 → ⑧ 报销复盘年会倒排表、场地合同/确认单、流程文档、奖品清单、邀请函、订餐确认、签到与人员清单、费用报销与复盘待新建60
ADM-22差旅订票与企业出行账户管理员工因公出行需要订票（含二等座售罄等例外），以及企业滴滴等出行账户的开通、余额充值与分主体对账主责——行政专员（差旅与企业出行账户）（当前：侯明月·推断待确认）；协同——财务专员（充值与报销）（当前：刘梦可·推断待确认）、CEO（差旅例外审批）（当前：邴龙志·推断待确认）、销售负责人（差旅高频部门代表）（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 出差审批 → ② 按标准订票 → ③ 例外在审批中说明并附证明 → ④ 报销按标准核对；企业出行账户：① 开通申请 → ② 按主体开通 → ③ 余额预警 → ④ 充值 → ⑤ 月度对账出差审批单、符合标准的票据与报销单、企业出行账户成员清单、充值记录、按主体的月度对账单待优化27
ADM-23公司证照与档案（印章/档案柜）保管调用业务需要营业执照、法人证件、资质等材料（小程序审核、合同、渠道资料、申报），或人事档案、公章、财务资料需要安全存放与借阅主责——行政专员（证照与印章保管）（当前：侯明月·推断待确认）；协同——总助助理（档案体系建设）（当前：董蓝汐·推断待确认）、人事负责人（人事档案）（当前：黄莹·推断待确认）、财务负责人（财务凭证）（当前：黄梦婷·推断待确认）、法务负责人（合同档案）（当前：李瑶·推断待确认）、CEO（档案室规划拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 建电子证照库 → ② 设权限与水印规则 → ③ 申请调用 → ④ 发放带水印版本/原件借出登记 → ⑤ 证照变更同步 → ⑥ 纸质档案编号入柜 → ⑦ 借阅登记 → ⑧ 季度盘点按主体分类的电子证照库（含版本与有效期）、证照调用记录、原件与档案借阅登记表、纸质档案目录、季度盘点报告待新建96
ADM-24IT设备与研发硬件采购申请新人入职、设备不足、研发换配置、测试机不足、需要工作站/CI 机/算力机/NAS/服务器、外设耗材、客户交付硬件备货、设备返修时的采购申请到配发入账主责——IT 运维/采购专员（当前：杨明学·推断待确认）；协同——创始人兼 CTO（IT 预算与配置审批）（当前：丁震宇·推断待确认）、CEO（付款审批）（当前：邴龙志·推断待确认）、行政专员（京东慧采下单）（当前：侯明月·推断待确认）、财务负责人（付款）（当前：黄梦婷·推断待确认）、运维/交付工程师（到货验收与领用核对）（当前：游家豪·推断待确认）；兜底——创始人兼 CTO① 提交“采购申请”审批 → ② 查库存可否调拨 → ③ 按分级标准选型询价 → ④ CTO 审配置预算、CEO 审付款 → ⑤ 下单 → ⑥ 财务付款 → ⑦ 到货验收 → ⑧ 入台账并领用签收信息完整的采购审批单、询价比价记录、订单与发票、验收单、IT 资产台账记录、领用签收记录待优化192
ADM-25交付用硬件备货采购与供应商比价交付库存（元和/源核/龙智/震宇等机型、周年版）低于安全库存，或新交付、客户采购意向需要服务器/工作站/机柜时，完成库存评估、成本核算、供应商比价压价和下单补货。主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——交付统筹（当前：杨萌·推断待确认）、销售/商务（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 库存预警/需求提出 → ② 库存与需求量评估 → ③ 规格确认与成本核算 → ④ 合格供应商比价压价 → ⑤ 采购审批 → ⑥ 下单与到货跟踪 → ⑦ 验收入库并更新库存已审批的补货采购单、供应商比价记录、按期到货并入库的交付硬件、更新后的库存与成本表待新建192
ADM-26调研/验证用设备临时采购与处置研发/产品为竞品调研或技术验证需要实机（如小米 NAS、懒猫微服、某存储设备厂商 NAS），完成临时采购或借用、领用登记，评估结束后按期保留、退货、转赠或出售。主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——需求方研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、设备保管运维（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 提出需求（用途/评估期/预算）→ ② 先查替代方案 → ③ 选采购方式并标注退货期 → ④ 小额快速审批 → ⑤ 下单、入库登记、领用 → ⑥ 评估期满前提醒 → ⑦ 处置（保留/退货/转赠/出售）并更新台账调研设备台账记录（含退货截止日、保管人、处置结果）、评估结论、退款或资产入账凭证待新建32
ADM-27IT设备到货验收、入库登记与调配变更采购的服务器、CI 机、内存、主板、迷你主机、电脑及外设到货，或设备在员工之间换人使用、退回时，完成验收、资产编号入库、分配和资产表变更。主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、需求方/验收人（当前：宋祺睿·推断待确认）、行政（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 到货通知 → ② 打印/生成验收单 → ③ 需求方验收签字 → ④ 分库入库并编号 → ⑤ 领用/分配登记 → ⑥ 调配或退回时提变更 → ⑦ 更新资产表并归档签字验收单、带资产编号的入库记录、领用/调配记录、账实一致的资产多维表格待优化144
ADM-28内部测试设备与资源借用登记研发、测试、交付需要借用公司闲置测试机、Mac mini、Windows 机、平板、录音卡、iPhone/iPad 真机、移动硬盘/U 盘/光盘等交付介质时，查台账、登记借用、按期归还。主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 查测试设备台账 → ② 提交借用登记 → ③ 确认/审批 → ④ 领取并记录配件 → ⑤ 到期提醒 → ⑥ 归还验收、清数据 → ⑦ 台账回写；无库存时转采购实时可查的测试设备与交付介质台账、每次借用/归还记录、按需补充的安全库存待新建96
ADM-29样机/设备外借（销售演示、展会、客户现场应急）销售/市场需要借 LeapCore 样机或其他设备用于客户演示、渠道/经销商试用、展会，或政府等客户现场应急需要终端时，完成借用审批、出库登记（含配件清单）和归还入账。主责——IT资产/样机管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、销售（当前：杨朋伟·推断待确认）、产品总监（当前：杨萌·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认），特殊情形加签 COO（当前：常元和·推断待确认）；兜底——综合部负责人① 提前 1～3 天确认样机存量 → ② 提交样机借用审批 → ③ 按常规/特殊分级审批 → ④ 出库登记配件并拍照 → ⑤ 领取或邮寄 → ⑥ 到期提醒 → ⑦ 归还核对配件并入账已审批的借用单、含配件清单和照片的出库/归还记录、样机台账状态更新待优化180
ADM-30信创测试机申请与厂商借机/归还信创适配或测试缺少海光/飞腾/鲲鹏/龙芯/兆芯等芯片或对应操作系统的实体机、虚拟机、构建服务器时，提需求审批，按内部资源、厂商借机、云租赁、采购四条路径获取，验收入库交测试，到期归还或转长期。主责——IT资源/资产管理员（当前：杨明学·推断待确认）；协同——信创适配负责人（当前：李子遥·推断待确认）、运维（当前：游家豪·推断待确认）、渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、测试（当前：潘浩伟·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 提交配置需求 → ② 审批并定路径（内部/借用/云/采购）→ ③ 指定到位日期与负责人 → ④ 获取资源（组装/开账号/向厂商借/采购）→ ⑤ 验收入库、交测试 → ⑥ 占用与转借登记 → ⑦ 到期归还或转长期可用的信创测试/构建环境、信创设备借用台账（来源、位置、保管人、归还日）、按期归还记录待优化300
ADM-31IT设备故障报修显示器、键盘、笔记本、mini PC、移动硬盘等 IT 设备出现故障或人为损坏时，统一报修登记，完成排障、维修或更换，必要时判定赔偿，并把退役/闲置设备回收再分配或处置；电脑、服务器、硬盘、U 盘、手机、测试机、客户退回的一体机等设备报废、出售、转赠、退租或返厂维修前，完成数据清除与资产注销。主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CTO（当前：丁震宇·推断待确认，审批）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交“设备维修”审批 → ② 远程/现场初步排查 → ③ 定级（换配件/送修/换新）→ ④ 维修或更换 → ⑤ 判定是否人为损坏 → ⑥ 验收交还并更新台账 → ⑦ 退役设备鉴定回收 → ⑧ 数据清除或物理销毁 → ⑨ 处置审批与执行 → ⑩ 资产注销与财务核销报修工单闭环记录、修复或替换后的设备、更新后的资产台账（含维修记录）、需要时的报损与赔偿判定记录；处置设备的数据清除记录（含序列号）、处置凭证与资产注销记录待优化54
ADM-32离职/换机设备回收员工（含实习生、外部合作者）离职、合作结束或更换设备时，按清单回收电脑、键鼠、充电线等公司资产，核对资产表并重新入库，同时联动账号收口。主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、运维（当前：游家豪·推断待确认）；认定——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 离职审批流转到运维节点/换机申请 → ② 按资产表生成回收清单 → ③ 约定回收时间 → ④ 逐项核对实物与编号 → ⑤ 数据清理与账号收口联动 → ⑥ 审批签字 → ⑦ 资产表回写并重新入库逐项核对的回收清单、运维节点已审批的离职单、更新后的资产表（状态“在库/闲置”）待优化72
ADM-33资产盘点、闲置回收与审计配合到了定期盘点节点（季度/年后），或审计、董事会、尽调需要账实资料，或发现外借、送测、闲置设备长期未归还时，启动全量或专项资产盘点与回收主责——IT 资产管理员（当前：杨明学·推断待确认）；协同——盘点执行人/IT 运维交付（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外借发起部门对接人（当前：李鹏为、闫登辉·推断待确认）、运维/云资源管理员（当前：宋祺睿·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 触发并发盘点通知 → ② 导出台账底表 → ③ 现场扫码盘点并补标签 → ④ 使用人确认 → ⑤ 外借与闲置追回 → ⑥ 差异处理 → ⑦ 与财务账核对 → ⑧ 出盘点报告并归档更新后的资产台账（账实相符）、盘点报告与差异清单、外借/闲置回收记录、提交审计或董事会的资产资料待新建240
ADM-34云服务与软件订阅等非实体资产申领与释放内部团队或子公司需要云服务、测试环境、域名、开放平台企业 ID、AI 工具订阅/兑换码/Token 等非实体资产，或这类资源不再使用需要释放回收时主责——云资源与权限管理员（当前：宋祺睿·推断待确认）；协同——审批人/创始人兼 CTO（当前：丁震宇·推断待确认）、资源原负责人（当前：按台账登记，待指定）、交付核对人（当前：杨云峰、游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申请人；兜底——创始人兼 CTO① 提交「非实体资产申领」审批 → ② 分类与主体判定 → ③ 审批 → ④ 采购付款（如需） → ⑤ 开通/发放 → ⑥ 登记资源台账 → ⑦ 释放申请与在用确认 → ⑧ 执行释放并更新台账已审批的申领单、开通完成并登记到资源台账的资源（含负责人、到期日、费用归属）、经确认的释放记录待优化96
ADM-35消防安全检查与应急疏散演练办公区、机房、库房的日常消防检查，每年至少一次的应急疏散演练，以及发生火情、冒烟、电池鼓包等险情时适用主责——行政专员（当前：待指定）；协同——IT/运维（当前：待指定）、人事（当前：待指定）、楼宇物业（外部）；兜底——行政负责人（当前：胡则瑾·部门报送人）① 消防设施台账 → ② 月度检查 → ③ 隐患整改 → ④ 年度疏散演练 → ⑤ 险情处置 → ⑥ 复盘与台账更新消防检查记录、隐患整改单、演练记录、险情处置报告待新建80
ADM-36场地租金、物业及水电网费用缴纳与租约到期提醒每月/每季度缴纳房租、物业费、水电费、宽带专线费，以及租赁、物业、宽带合同到期前的续约决策时适用主责——行政专员（当前：待指定）；协同——财务（当前：待指定）、IT/运维（当前：待指定）；兜底——行政负责人（当前：胡则瑾·部门报送人）① 建立固定费用台账 → ② 到期前提醒 → ③ 核对账单 → ④ 付款申请 → ⑤ 付款与收票 → ⑥ 合同到期前评估续约 → ⑦ 台账更新按期缴纳的付款记录与发票、续约或退租决定待新建72
ADM-01办公场地选址、租赁、装修与搬迁待新建250

状态：待新建｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：现有场地工位饱和、租约到期/提前退租，或需新增办公点/展厅时，从选址评估一直走到装修验收、整体搬迁和原场地退租
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 需求立项 → ② 踩点与场地对比表 → ③ 决策会拍板 → ④ 商务谈判（租金/免租期/发票）→ ⑤ 合同审核与用印 → ⑥ 施工准备（物业三方签字、押金）→ ⑦ 施工跟踪与验收 → ⑧ 搬迁与退租
  • 交付结果：已签署的租赁合同（含发票条款）、装修验收单与空气检测报告、搬迁完成通知、退租交接单及押金退还记录
  • 状态依据：每次选址/装修都从零摸索，没有选址评估清单和财务/发票前置要求；签约后才暴露房东不开票问题，施工许可因周末无人签字顺延，搬迁曾在前一天才通知

1. 场景判定

  • 触发条件：工位使用率接近满员且未来 3 个月有扩招计划；租约剩余 ≤ 3 个月；需新增办公点、展厅；公共空间需整体改造（休息室、大门、会议室桌椅）
  • 典型说法：「先把 1005 拿下吧」「这个预算只能租到这个」「到底要不要搞展厅」「我们周六搬一下吧」「由你们 905 内部票选好了告知我」
  • 判断问题：这件事是否涉及签租约、退租、施工改造或整体搬迁？金额是否需要对公付款或押金？
  • 不归本流程管：日常工位调整 → 请走 ADM-02；新人工位 → 请走 ADM-03；门锁/临时密码 → 请走 ADM-04；设施坏了报修 → 请走 ADM-08；单件家具采购 → 请走 ADM-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政负责人 踩点、对比表、谈判、施工与搬迁执行、退租交接 R 行政负责人（当前：胡则瑾·推断待确认）
综合部负责人 统筹节奏、组织决策会、督办进度 R 综合部负责人（当前：赵雪冰·推断待确认）
CEO 选址、预算、改造程度、是否建展厅最终拍板 A CEO（当前：邴龙志·推断待确认）
CTO 研发区、机房、网络需求评估 C CTO（当前：丁震宇·推断待确认）
财务负责人 发票类型与税点前置确认、押金与租金对公付款 C 财务负责人（当前：黄梦婷·推断待确认）
法务 租赁/装修/搬家合同审核、违约条款核对 C 法务负责人（当前：李瑶·推断待确认）
IT 运维 网络、机房、监控摄像头、门锁布设 R（IT 部分） IT 运维（当前：杨明学·推断待确认）
全员 接收搬迁通知、打包个人物品 I 各部门

3. 办之前请准备

  • 当前人数、未来 3～6 个月扩招计划（由人事提供），研发区/机房特殊需求
  • 预算上限（月租、装修、搬迁三项分开）、期望入驻日期
  • 发票要求：发票类型、税点（投资人/审计要求开票的，必须作为谈判前置条件）
  • 原场地合同（到期日、提前退租违约条款、押金金额）
  • 公共空间改造：预算上限和技术可行性（如玻璃门能否钻孔）先确认，再出方案投票

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交场地需求单（人数、预算、时间、特殊需求） 综合部负责人 租约到期前 ≥ 90 天或扩招确认后 5 个工作日内 飞书审批/文档 场地需求单 🔧飞书固化
2 中介踩点，候选 ≥ 3 个，按模板填对比表 行政负责人 需求单批准后 10 个工作日内 飞书多维表格 场地对比表 🔧+🤖
3 召开决策会，确定场地、改造程度、是否建展厅 综合部负责人组织，CEO 拍板 对比表完成后 3 个工作日内 飞书会议+妙记 决策纪要 👤人工判断
4 谈判租金、免租期、发票类型与税点，写入合同条款 行政负责人，财务负责人 决策后 5 个工作日内 — 谈判确认单 👤人工判断
5 合同审核、用印、押金/租金对公付款 法务、财务负责人 提交后 3 个工作日内 飞书合同/付款审批 已签合同、付款凭证 🔧飞书固化
6 施工准备：物业三方签字、施工许可、图纸、成品保护、断电/门锁协调 行政负责人，IT 运维 开工前 5 个工作日（避开周末办理） 飞书任务 施工许可、进度表 🔧飞书固化
7 施工日跟踪，落后 ≥ 1 天在群内预警 行政负责人 每日 18:00 前更新 多维表格+日报机器人 进度记录 🔧+🤖
8 竣工验收：质量、网络、监控、门锁、空气/甲醛检测 行政负责人，IT 运维 竣工后 3 个工作日内 验收清单 验收单、检测报告 👤人工判断
9 搬迁：搬家公司 3 家比价、设备清单、搬迁通知、搬迁期居家安排 行政负责人 通知提前 ≥ 5 个工作日；搬后 1 个工作日内复位 飞书公告 搬迁通知、设备清点表 🔧飞书固化
10 退租：核对违约条款、恢复原状、交接、押金退还跟踪 行政负责人，财务负责人 退租日前 10 个工作日启动 飞书任务 退租交接单 👤人工判断

5. 交付物与模板

  • 交付物：场地需求单、场地对比表、决策纪要、租赁合同、施工进度表、验收单与检测报告、搬迁通知、退租交接单
  • 建议模板/表单：
    • 场地对比表字段：地址、面积、可容纳工位数、月租单价/总价、免租期、发票类型/税点、物业费、改造程度、施工限制、合同期限、通勤/地段、是否可做展厅、网络/机房条件
    • 施工进度表字段：工项、计划开始/结束、实际完成、责任方、是否延期、照片
    • 公共空间改造决策卡：预算上限、技术可行性确认人、候选方案 A/B、投票截止日、执行人

6. 异常与升级

  • 房东/物业不配合开具发票 → 暂停签约，重新谈判或换备选场地 → 升级 CEO（1 个工作日内）
  • 施工许可/三方签字延误 → 改约工作日办理，调整进度表 → 升级综合部负责人（延误 ≥ 2 天时）
  • 施工方失联或进度落后 ≥ 3 天 → 书面催告并按合同扣款 → 升级综合部负责人（当天）
  • 提前退租涉及违约金 → 法务评估金额与谈判空间 → 升级 CEO（3 个工作日内）
  • 公共空间方案下单后发现不可行 → 退单并补做可行性确认 → 行政负责人当天处理

7. 衡量指标

  • 选址周期：需求单批准到合同签署的自然日，目标 ≤ 30 天
  • 装修按期率：按计划竣工的项目占比，目标 ≥ 90%
  • 发票合规率：租金/装修费用取得合规发票的比例，目标 100%
  • 搬迁通知提前量：通知发出到搬迁日的工作日数，目标 ≥ 5 个工作日
  • 公共空间改造退单次数：目标 0

8. 低效诊断

  • 发票口径未在谈判阶段前置，签约后才发现房东不配合开票，需事后补救｜依据：「【模态】综合部」2026-07
  • 施工许可依赖物业、房东、装修方三方签字，周末无人导致开工顺延｜依据：「【模态】综合部」2026-07
  • 装修进度靠群内口头通报，落后后才发现｜依据：「【模态】综合部」2026-08
  • 候选场地材料与是否建展厅分开讨论，决策反复｜依据：「董事会」2026-07
  • 整体搬迁前一天才通知，成员来不及准备设备｜依据：「跃玩项目组」2026-01
  • 门锁等施工由 IT 兼办，施工方失联需反复催｜依据：「忠橙星行星引擎」2026-01
  • 公共空间改造未先定预算和技术可行性，方案下单后退单重下｜依据：「公司建设大改造」2026-01、「公司建设大改造」2026-02

9. 分支变体

  • 新增办公点（如 1005）：走完整步骤 1～9
  • 退租（原场地到期、提前退租）：只走步骤 4、5、9、10，重点核对违约条款
  • 是否建展厅：并入步骤 3 一并决策，不单独另议
  • 公共空间改造（休息室软装、大门、会议室桌椅）：行政先定预算与可行性 → 发方案 → 飞书投票（截止 2 个工作日）→ 行政下单
  • 施工期断电：机房所在区域不可断电，需 IT 运维事先确认

10. 待确认问题

  • 选址最终决策人是 CEO 还是董事会？金额多少以上需董事会讨论？
  • 发票类型与税点的公司统一要求是什么（专票/普票、税点）？
  • 押金、租金的对公付款审批时限 3 个工作日是否可行？
  • 是否已有装修验收标准和空气检测要求的成文制度？
  • 法务岗位是否参与所有租赁/装修合同审核？
  • 公共空间改造多少金额以内由行政直接决定，无需投票？
ADM-02工位调整与座位安排待优化72

状态：待优化｜证据：有证据（卡片 10 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨4 × 险2

  • 适用场景：组织调整、团队扩招、分区搬迁或新增场地，需要重新排座位、调整桌椅并同步全员时
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、CTO（当前：丁震宇·推断待确认）、行政专员（当前：侯明月·推断待确认）、各部门负责人（当前：杨萌、李凯、陈梦琪等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交工位变更申请 → ② 核对工位台账 → ③ 定分区方案 → ④ 发布座位表 → ⑤ 桌椅补齐 → ⑥ 统一搬迁 → ⑦ 更新台账
  • 交付结果：已发布的最新座位表（多维表格）、完成搬迁的工位、更新后的工位台账
  • 状态依据：已有座位表 sheet 和采购申请流程，但座位表无统一维护人、与入职计划未联动；06 月、09～10 月多次“座位不够”“来回搬”，发布后撤回、反复调整

1. 场景判定

  • 触发条件：部门人数变化 ≥ 2 人；跨部门调整分区；新场地启用；现有工位空位 < 未来 2 周入职人数
  • 典型说法：「下午五点开搬」「这边座位不够了」「劳烦各位负责人确定一下各自工区需要增加几张桌椅」「得大变工位了」
  • 判断问题：是否涉及 2 人及以上换位或跨区域搬迁？是否需要新增桌椅？
  • 不归本流程管：单个新人入职座位 → 请走 ADM-03；新场地租赁与整体搬迁 → 请走 ADM-01；桌椅采购执行 → 请走 ADM-14；会议室占用 → 请走 ADM-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政负责人 维护工位台账、发布座位表、组织搬迁 R/A 行政负责人（当前：胡则瑾·推断待确认）
CTO/分区决策人 跨部门分区优先级拍板 A（升级） CTO（当前：丁震宇·推断待确认）
部门负责人 提交变更需求、部门内排座 R（部门内） 各部门负责人（当前：杨萌、李凯、陈梦琪等·推断待确认）
人事负责人 提供入职计划与在招人头 C 人事负责人（当前：黄莹·推断待确认）
行政专员 桌椅需求汇总、采购下单、安装 R（采购） 行政专员（当前：侯明月·推断待确认）
全员 按通知搬迁、交接设备 I 全员

3. 办之前请准备

  • 变更人员名单、所属部门、期望区域、生效日期
  • 未来 4 周入职计划（人事提供，含实习生）
  • 当前工位台账空位视图
  • 桌椅需求数量（不足时提前 ≥ 5 个工作日提采购，物流 3～5 天）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交工位变更申请（人员、区域、日期、原因） 部门负责人 生效日前 ≥ 3 个工作日 飞书表单 变更申请 🔧飞书固化
2 核对台账空位，与入职计划比对 行政负责人 收到申请后 1 个工作日内 工位多维表格 空位核对结果 🔧+🤖
3 跨部门分区按优先级定方案；部门内由负责人自排 CTO / 部门负责人 1 个工作日内 座位图 分区方案 👤人工判断
4 发布座位表（变动者标色），在相关群公告 行政负责人 搬迁前 ≥ 1 个工作日 多维表格+飞书公告 座位表 v 版本 🔧飞书固化
5 桌椅不足时汇总需求提采购 行政专员 发布当天 采购审批（ADM-14） 采购单 🔧飞书固化
6 统一搬迁（下班后或指定时段），设备/网络随人迁移 行政负责人，变动人员 按公告日期当天完成 — 搬迁完成 👤人工判断
7 更新台账并锁定，2 周内无审批不再变动 行政负责人 搬迁当天 工位多维表格 最新台账 🔧飞书固化

5. 交付物与模板

  • 交付物：工位变更申请、座位表（多维表格，含空位视图）、搬迁公告
  • 建议模板/表单：
    • 工位台账字段：场地（905/906/10 楼/K11 等）、工位编号、使用人、部门、人员类型（全职/实习/访客）、状态（在用/空/预留待入职）、预留入职日、桌椅配置、更新时间
    • 搬迁公告模板：变动名单、时间、新位置、需自行打包物品、网络/设备注意事项、联系人

6. 异常与升级

  • 方案发布后被要求推翻 → 由提出人走变更申请，说明理由 → 升级综合部负责人（1 个工作日内）
  • 空位不足且采购未到货 → 临时启用共享工位，不拆会议室桌椅 → 行政负责人当天处理
  • 部门间分区争议 → CTO 拍板；仍有争议升级 CEO（2 个工作日内）
  • 公共区域规则问题（吸烟、噪音）→ 行政发布公共空间规范 → 升级综合部负责人
  • 升级条件：涉及跨部门分区划分或部门间对分区有争议时，由 CTO 拍板（A（升级））；部门内微调由行政负责人确认即可

7. 衡量指标

  • 工位就绪率：新人到岗当天已有工位的比例，目标 100%
  • 二次变更率：座位表发布后 2 周内被推翻的次数，目标 ≤ 1 次/月
  • 申请响应时长：申请提交到座位表发布的工作日数，目标 ≤ 2 个工作日

8. 低效诊断

  • 分区决策反复，座位表发布后撤回、同一批人多次搬迁｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-06、「鼎慧产研决策部」2026-09
  • 不清楚谁负责排哪个团队的座位，需在群里反复问｜依据：「Leap产研测」2026-06
  • 新人到岗当天才讨论坐哪，临时拆会议室桌椅｜依据：「【模态】业务负责人」2026-07
  • 桌椅采购在入职前一天才提，赶不上物流周期｜依据：「【模态】综合部」2026-07
  • 座位表未标注待入职人员部门，无法预留｜依据：「【模态】综合部」2026-06
  • 办公事务由业务项目负责人兼任，依赖个人｜依据：「字字可研项目群」2026-03、「字字可研项目群」2026-04
  • 吸烟、噪音等公共规则缺失，在群里各说各话｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 跨部门分区（研发/鼎慧/市场/运营/销售/生态在 905/906/10 楼间划分）：需 CTO 拍板
  • 部门内微调：部门负责人自排，只需通知行政更新台账
  • 桌椅不足：联动 ADM-14 采购
  • 实习生/临时访客：使用共享工位，不占固定位
  • 销售拼工位：需部门负责人提出，行政评估

10. 待确认问题

  • 工位台账统一由行政维护还是人事维护（目前人事维护座位表 sheet）？
  • 跨部门分区优先级由 CTO 定还是 CEO 定？
  • “发布后 2 周内不变”的冻结规则是否可接受？
  • 是否允许“随机坐/不排工位”的区域？适用哪些团队？
  • 是否需要公共空间规范（禁烟、午休时段）？由谁发布？
ADM-03新员工入职行政准备（工位、电脑、领用登记）待优化144

状态：待优化｜证据：有证据（卡片 10 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：人事确认新员工/实习生到岗日期后，到岗前备好工位、电脑/显示器/开发机及办公用品，到岗当天完成发放与领用登记
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、IT 运维负责人（当前：杨明学·推断待确认）、运维工程师（当前：游家豪·推断待确认）、行政专员（当前：侯明月·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 入职信息推送 → ② 工位确认 → ③ 配置判定 → ④ 库存核对/采购 → ⑤ 预装系统 → ⑥ 工牌门禁账号 → ⑦ 到岗发放与登记 → ⑧ 清单关闭
  • 交付结果：到岗当天可用的工位和预装好的设备、已填写的领用登记、全部勾选完成的入职准备清单
  • 状态依据：已有 IT 资产管理多维表格、办公用品领用表单和工位表，但入职通知靠群消息、提前量不足；02～10 月反复出现到岗当天才问电脑、电脑缺货、借他人工位，约 20 次

1. 场景判定

  • 触发条件：候选人接受 offer 并确定到岗日；实习生转正/转组需补配设备；员工申请自带设备办公
  • 典型说法：「明天入职，需要配电脑」「905 没地方坐新人了」「下次缺的话需要提前说下呀」「转正通过了才给配」
  • 判断问题：此人是否在 5 个工作日内到岗？是否需要公司配发设备或工位？
  • 不归本流程管：工牌制作与门禁录入 → 请走 ADM-04；成批工位调整 → 请走 ADM-02；电脑故障维修 → 请走 ADM-31；系统账号权限开通 → 请走 X-SEC-01（新人入职 IT 账号一站式开通）；节假日断电值守 → 请走 ADM-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政负责人 入职准备清单总负责，工位确认，办公用品 A/R 行政负责人（当前：胡则瑾·推断待确认）
人事负责人 推送入职信息、提供人员类型与归属 R（触发） 人事负责人（当前：黄莹·推断待确认）
IT 运维负责人 库存核对、采购触发、资产台账 R（设备） IT 运维负责人（当前：杨明学·推断待确认）
运维工程师 拆机预装、发放、领用登记 R 运维工程师（当前：游家豪·推断待确认）
行政专员 办公用品与桌椅采购 R（采购） 行政专员（当前：侯明月·推断待确认）
CTO 特殊配置、实习生配机、自带设备审批 A（升级） CTO（当前：丁震宇·推断待确认）
用人部门负责人 确认归属小组、指定带教人 C 各部门负责人
带教人 到岗当日首日迎接与介绍 R（首日） 用人部门指定带教人

3. 办之前请准备

  • 新人姓名、岗位、部门/小组、人员类型（全职/试用/实习/借调）、到岗日、办公点、带教人
  • 是否研发岗、是否需要特殊配置（大内存、Mac、显示器数量）
  • 实习生：预计实习时长、是否拟转正、归属小组负责人是否确认
  • 当前库存与空位（资产多维表格、工位表）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入职审批通过后提交“入职准备”表单，自动建行政/IT 任务 人事负责人 到岗前 ≥ 5 个工作日 飞书审批+机器人 入职准备任务 🔧+🤖+👤
2 确认工位并在工位表标记“预留待入职” 行政负责人 任务创建后 1 个工作日内 工位多维表格 预留工位 🔧飞书固化
3 按岗位机型模板判定配置；实习生/自带设备/特殊配置提交审批 IT 运维负责人；例外由 CTO 审批 1 个工作日内 设备申请审批 配置单 🔧+👤
4 核对库存，不足立即触发采购 IT 运维负责人 到岗前 ≥ 3 个工作日到货 IT 资产多维表格 库存确认/采购单 🔧+🤖
5 拆机、预装系统、安装管控软件与常用工具 运维工程师 到岗前 1 个工作日完成 — 可用设备 👤人工判断
6 工牌信息采集、门禁录入、基础账号申请 行政专员 / IT 运维负责人 到岗前 1 个工作日 联动 ADM-04、X-SEC-01 门禁/账号就绪 🔧飞书固化
7 到岗当日发放设备与办公用品，领用人填领用登记 运维工程师、行政专员 到岗当日上午 飞书领用表单 领用记录 🔧飞书固化
8 勾选清单全部完成并关闭任务；带教人完成首日介绍 行政负责人、带教人 到岗当日下班前 飞书任务 已关闭清单 🔧飞书固化

5. 交付物与模板

  • 交付物：入职准备清单（每人一条）、设备领用登记、工位表更新
  • 建议模板/表单：
    • 入职准备表单字段：姓名、岗位、部门/小组、人员类型、到岗日、办公点、带教人、是否研发、建议机型、特殊配置说明、是否拟转正
    • 清单项：工位 ☐ 电脑 ☐ 显示器 ☐ 键鼠 ☐ 办公用品 ☐ 工牌 ☐ 门禁 ☐ 基础账号 ☐ 首日迎接人 ☐
    • 岗位机型模板：研发（高内存笔记本或 Mac mini + 显示器）、非研发（标准笔记本）、实习生（设备池共享机或按规则）、远程（不配）

6. 异常与升级

  • 到岗前 3 个工作日库存仍不足 → 启用备用机/设备池临时配发 → 升级 CTO（当天）
  • 工位不足 → 启用共享工位，同步启动 ADM-02 → 升级行政负责人（当天）
  • 实习生归属小组或转正状态未确认 → 先配共享机，确认后换正式机 → 升级用人部门负责人（1 个工作日内）
  • 申请自带设备办公 → 须同意安装公司管控软件 → CTO 审批（1 个工作日内）
  • 入职信息未提前推送（< 2 个工作日）→ 记为异常并计入指标 → 通报人事负责人
  • 升级条件：需要特殊配置、实习生配机、自带设备办公，或到岗前 3 个工作日库存仍不足需动用备用机时，由 CTO 审批拍板（A（升级））；其余按岗位机型模板由行政负责人统筹完成

7. 衡量指标

  • 到岗即用率：到岗当天上午已领到设备与工位的新人占比，目标 ≥ 95%
  • 入职通知提前量：入职准备表单提交到到岗日的工作日数，目标 ≥ 5 天
  • 领用登记完整率：发放设备有领用记录的比例，目标 100%
  • 库存预警响应：库存低于阈值到发起采购的工作日数，目标 ≤ 1 天

8. 低效诊断

  • 入职通知靠群消息，提前量不足，到岗当天才问电脑｜依据：「运维&综合对接群」2026-10
  • 拆机配系统未前置到入职前，新人到岗后等待｜依据：「运维&综合对接群」2026-02、「忠橙星行星引擎」2026-02
  • 研发电脑库存不足才发现，无库存预警｜依据：「运维&综合对接群」2026-03、「运维&综合对接群」2026-09
  • 到货后才核对采购单，机型/数量与实际需求不符，资产管理方式未定｜依据：「忠橙星行星引擎」2026-01、「忠橙星行星引擎」2026-02
  • 实习生配机规则未成文，对申请人的口径需临时统一｜依据：「鼎慧产研决策部」2026-03、「忠橙星行星引擎」2026-03
  • 办公点满员，新人临时借用他人工位｜依据：「开放平台招聘」2026-10
  • 电脑找谁要、是否走审批在群里讨论｜依据：「开放平台Only」2026-10
  • 领用表单需人工督促填写｜依据：「办公用品对接群」2026-03
  • 首日迎接人临时商量，新人入职两周仍不认识同事｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • 研发岗：高内存 Windows 笔记本或 Mac mini + 显示器，可选机型需 CTO 确认
  • 非研发岗：标准笔记本
  • 实习生：短期实习不配专用机，拟转正或满足期限后按规则配发；可建实习生设备池
  • 自带设备：须安装管控软件，CTO 审批
  • 异地办公点（模态空间/905/906/10 楼/K11）：设备由当地同事代领并在登记中备注
  • 线上远程：不配设备

10. 待确认问题

  • 入职准备清单的主责是行政还是人事？
  • 实习生配机条件：以“转正通过”还是“实习满一定期限”为准？由谁确认转正状态？
  • 到岗前 5 个工作日推送入职信息是否可行？
  • 是否设立实习生共享设备池？数量多少？
  • 各岗位标准机型模板由谁维护？
  • 库存预警阈值（研发/非研发机各多少台）？
ADM-04工牌制作与门禁/钥匙/临时密码管理待新建72

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：新人领工牌、批量换版工牌、门禁指纹/NFC 录入、门卡遗失，以及装修/保洁/空调师傅或访客需要临时进门时
  • 负责人：主责——行政专员（当前：侯明月·推断待确认）；协同——行政助理（当前：丁蕊·推断待确认）、IT 运维/门锁管理员（当前：杨明学·推断待确认）、门锁 App 持有人（当前：宋祺睿·推断待确认）、人事负责人（当前：黄莹·推断待确认）；兜底——行政负责人（当前：胡则瑾·推断待确认）
  • 核心流程：① 入职触发工牌采集 → ② 按月批次制作 → ③ 发放签收 → ④ 门禁录入 → ⑤ 临时授权（限时密码+登记）→ ⑥ 遗失补办/离职注销 → ⑦ 月度权限盘点
  • 交付结果：已发放并签收的工牌、门禁权限台账（含临时授权记录和到期时间）
  • 状态依据：工牌有信息收集表单但需多次催填、错过须等下一批；门禁开门靠群里找人；临时密码通过私下传递、门锁管理员与 App 持有人不一致且使用共用弱口令，无登记和过期机制

1. 场景判定

  • 触发条件：新人入职；工牌换版；指纹未录或门卡丢失；外部人员需在无人时段进入办公区
  • 典型说法：「是不是要做新工牌了，现在提交还来得及么」「谁来帮我开下模态空间的大门」「搞个临时密码发我吧」「谁的 NFC 卡落地上了」
  • 判断问题：是否涉及谁能进门、凭什么进门？是否需要发放或收回一项进门凭证？
  • 不归本流程管：访客接待与参观报备 → 请走 ADM-06；门锁损坏维修 → 请走 ADM-08；新场地门锁选型安装 → 请走 ADM-01；新人其他入职物资 → 请走 ADM-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政专员 工牌采集、批次制作、发放；临时授权登记 R/A 行政专员（当前：侯明月·推断待确认）
行政助理 表单发布、催填、发放执行 R 行政助理（当前：丁蕊·推断待确认）
门锁管理员 指纹/NFC 录入、生成限时密码、权限注销 R IT 运维（当前：杨明学·推断待确认）
门锁 App 持有人 移交或共享管理权限（目标：管理员统一） C 当前持有人（当前：宋祺睿·推断待确认）
人事 推送入职/离职信息 C 人事负责人（当前：黄莹·推断待确认）
员工 提交头像、保管工牌、遗失及时报告 I 全员

3. 办之前请准备

  • 工牌：本人头像（规格见表单）、姓名、部门、到岗日
  • 门禁：所属办公点（905/906/模态空间等）、需要的时段权限
  • 临时授权：外部人员单位、事由、进场时间段、陪同人/对接人
  • 遗失：遗失时间地点、工牌/卡编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入职信息触发工牌采集表单，新人提交头像 人事触发，行政助理跟进 到岗前 3 个工作日 飞书表单+机器人 工牌信息 🔧+🤖
2 每月固定日汇总给供应商制作；批量换版提前公告截止日 行政专员 每月 1 个批次，截止日前 2 次自动提醒 多维表格 制作清单 🔧+🤖
3 到货后发放，领取人签收 行政助理 到货后 2 个工作日内 领用表单 签收记录 🔧飞书固化
4 录入指纹/NFC 门禁，登记权限台账 门锁管理员 到岗当日 门禁系统+台账 权限记录 🔧飞书固化
5 临时授权：行政提申请 → 管理员生成限时密码 → 只发给对接人 → 登记 行政专员，门锁管理员 进场前 1 个工作日申请；密码到期自动失效 门锁 App+多维表格 临时授权记录 🔧+👤
6 遗失：当日注销旧卡/权限，补办；离职：离职当日注销并收回工牌 门锁管理员，行政助理 报告后 2 小时内注销 门禁系统 注销记录 🔧飞书固化
7 月度盘点门禁权限与临时密码，清理过期权限 门锁管理员 每月最后一个工作日 台账 盘点记录 🔧+🤖

5. 交付物与模板

  • 交付物：工牌发放签收表、门禁权限台账、临时授权记录
  • 建议模板/表单：
    • 工牌信息表单字段：姓名、部门、头像、背面图选项、到岗日、办公点
    • 门禁权限台账字段：人员/外部单位、类型（员工/外部师傅/访客）、办公点、凭证类型（指纹/NFC/密码）、生效时间、失效时间、授权人、状态
    • 临时授权申请字段：外部单位、事由、进场时段、对接人、是否需留门

6. 异常与升级

  • 新人到岗时工牌未到 → 先录指纹，工牌随下一批 → 行政专员处理
  • 门卡/工牌遗失 → 2 小时内注销 → 升级 IT 运维负责人（如无法远程注销）
  • 外部人员要求“晚上留门不锁” → 原则上不允许，改发限时密码；确需留门由行政负责人批准 → 升级综合部负责人
  • 发现使用共用或弱口令 → 当天更换为个人/限时密码 → 升级 IT 运维负责人
  • 门锁 App 只在一人手中且联系不上 → 启用第二管理员 → 升级行政负责人（当天）

7. 衡量指标

  • 工牌到手周期：到岗日到领取工牌的自然日，目标 ≤ 30 天
  • 门禁当日录入率：到岗当日完成门禁录入的比例，目标 100%
  • 临时授权登记率：发放的临时密码有登记记录的比例，目标 100%
  • 过期权限残留数：月度盘点发现的未注销过期权限，目标 0

8. 低效诊断

  • 工牌只按换版批次制作，截止后补交无入口，新人须等下一批｜依据：「随便瞎聊啦～」2026-04、「模态跃迁通知群」2026-04
  • 工牌信息表单需多次转发催填｜依据：「模态跃迁通知群」2026-03
  • 无门禁权限时靠群里喊人开门｜依据：「模态集团（全员群）」2026-01
  • 门卡遗落靠群内认领，无挂失注销｜依据：「模态集团（全员群）」2026-04
  • 指纹录入靠运维集中到现场，未纳入入职流程｜依据：「模态集团（全员群）」2026-05
  • 门锁管理员与 App 持有人不一致，找不到管理小程序；超级密码私下传递、多处共用同一口令｜依据：「公司建设大改造」2026-01、「公司建设大改造」2026-04

9. 分支变体

  • 新人领牌：走步骤 1～4
  • 批量换版：行政提前 ≥ 10 个工作日公告截止日，截止后转入月度批次
  • 模态空间门禁：按场地方规则办理（如 App 预约、扫码刷脸），行政负责代办
  • 外部师傅/保洁/空调清洗：走步骤 5，优先安排在工作时间由行政到场开门
  • 门常开设置：仅限活动期间，需行政负责人批准

10. 待确认问题

  • 工牌与门禁的唯一主责是行政专员还是行政负责人？
  • 门锁 App 管理权限是否统一移交给门锁管理员并设第二管理员？
  • 工牌按月批次制作是否可行？供应商最小起订量是多少？
  • 是否批量采购 NFC 卡/条用于门禁？
  • 现有共用口令何时全部更换？
  • 离职注销由人事触发还是行政主动核对？
ADM-05会议室预约与公共空间使用规范待优化100

状态：待优化｜证据：有证据（卡片 8 张 / 会话 6 个）｜优先级：频5 × 耗2 × 跨5 × 险2

  • 适用场景：开会、演示、培训、分享会、1v1 需要会议室，或出现会议室冲突、公共空间使用纠纷（不关灯关门、午休噪音）时
  • 负责人：主责——行政专员（当前：侯明月·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、人事负责人（当前：黄莹·推断待确认）、905 区域行政（当前：董蓝汐·推断待确认）、各会议组织者；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 飞书预约（按人数选房）→ ② 冲突处理 → ③ 签到/超时释放 → ④ 使用 → ⑤ 会后复原 → ⑥ 每日巡检 → ⑦ 月度复盘
  • 交付结果：有记录的会议室预约、按规则释放的空闲时段、公示的公共空间使用规范与巡检记录
  • 状态依据：飞书会议室预约和超时自动释放已上线，06 月新增线上会议间并更新规则；但 04～09 月仍反复出现不预约直接用、无效日程占位、长期批量占位、面试占大会议室、不关灯关门

1. 场景判定

  • 触发条件：需要使用 905/906/一楼/模态空间会议室或线上会议间；发现会议室被占或公共空间规则被违反
  • 典型说法：「905 会议室真需要一个管理」「他们一个会议室都没约」「要会议室自己约」「906 动不动不关灯不关门」
  • 判断问题：是否为内部会议/培训/1v1 的场地需求？是否涉及外部来访或面试？
  • 不归本流程管：外部来访接待 → 请走 ADM-06；面试会议室与候选人接待 → 请走 ADM-07；团餐聚餐报数 → 请走 ADM-20；会议室设施故障 → 请走 ADM-08；会议室遗留物 → 请走 ADM-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政专员 维护会议室配置与规则、冲突协调、巡检、知识库更新 R/A 行政专员（当前：侯明月·推断待确认）
区域行政 905 区域日常巡检与协调 R 区域行政（当前：董蓝汐·推断待确认）
综合部负责人 规则审批、长期占用审批、违规处理 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）
人事负责人 面试用房需求对接、规范纳入入职指引 C 人事负责人（当前：黄莹·推断待确认）
会议组织者 预约、签到、会后复原 R（自身会议） 全员

3. 办之前请准备

  • 会议时间、时长、人数、是否需投屏/视频会议设备
  • 是否为周期性会议（每周固定时段需审批）
  • 重要演示：来宾、门禁卡、Wi-Fi、投屏需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在飞书日程中绑定会议室预约；1～3 人优先线上会议间/小间 会议组织者 开会前 ≥ 2 小时；重要演示 ≥ 2 个工作日 飞书会议室 预约记录 🔧飞书固化
2 周期性占用（每周 ≥ 2 次同一时段）提交审批 会议组织者 → 行政专员 审批 1 个工作日内 飞书审批 长期占用批准 🔧飞书固化
3 冲突时以系统预约为准；无预约者让出；双方均预约由行政协调 行政专员 接到反馈 30 分钟内 飞书 协调结果 👤人工判断
4 开始 15 分钟未签到系统自动释放；无效日程由创建人及时删除 系统 / 会议组织者 自动 飞书会议室 释放时段 🤖自动化
5 会后复原：关灯关门、桌椅归位、擦白板、带走物品 会议组织者 会议结束后 5 分钟内 离场检查清单 复原的会议室 👤人工判断
6 每日下班巡检会议室与公共区，记录违规 行政专员 / 区域行政 每个工作日 19:00 前 巡检表 巡检记录 🔧+🤖
7 月度统计占用率、违规次数，调整规则并更新知识库 行政专员 每月第 1 个工作日 多维表格+知识库 月度报告 🔧+🤖

5. 交付物与模板

  • 交付物：会议室使用规范（知识库）、离场检查清单、巡检记录、月度占用报告
  • 建议模板/表单：
    • 会议室清单字段：位置、容纳人数、设备（投屏/摄像头/白板）、适用场景、预约方式（飞书/场地方 App）
    • 巡检表字段：日期、房间、灯/门/空调状态、遗留物、违规预约、处理人
    • 公共空间规范：午休安静时段、办公室禁烟、会议室不得当工位、借用桌椅须归还

6. 异常与升级

  • 会议室当工位长期占用 → 行政当场提醒并记录 → 同一部门月内 ≥ 3 次通报部门负责人
  • 单人批量占位多个时段 → 未审批的预约由行政取消 → 升级综合部负责人
  • 重要演示当天会议室/门禁卡未就绪 → 行政 15 分钟内调配备用房间 → 升级综合部负责人
  • 会议室被审计等专项长期征用 → 公告可用替代场地 → 综合部负责人决定
  • 不关灯关门屡次发生 → 通报+机器人提醒 → 升级综合部负责人（是否设处罚由其决定）
  • 升级条件：会议室使用规则新增或修改、单人批量占位需取消、专项长期征用、违规需处罚时，由综合部负责人拍板（A（升级））；日常预约冲突与周期性占用审批由行政专员决定

7. 衡量指标

  • 预约覆盖率：抽查时段内实际使用的会议室中有预约记录的比例，目标 ≥ 95%
  • 冲突次数：每月因占用冲突需行政协调的次数，目标逐月下降
  • 离场违规次数：巡检发现不关灯/不关门/未复原次数，目标 ≤ 2 次/月
  • 小会占大房比例：1～3 人会议使用大会议室的占比，目标 ≤ 10%

8. 低效诊断

  • 无效日程占位、周末会议室被占无人知晓｜依据：「Leap产研测」2026-08
  • 会议室长期无管理，个人批量预约固定时段，面试找不到房间｜依据：「鼎慧产研决策部」2026-04
  • 会议室管理改进事项被其他行政事务挤占优先级｜依据：「鼎慧产研决策部」2026-04
  • 部分团队不预约直接使用，会议室被当办公区｜依据：「鼎慧产研决策部」2026-06
  • 小规模面试占用大会议室，空间利用率低｜依据：「模态集团（全员群）」2026-04
  • 新上线的线上会议间位置需要问人｜依据：「模态集团（全员群）」2026-06
  • 重要演示会议室需多次追问进度，到场无门禁卡进电梯｜依据：「某央媒客户Leap突击」2026-05
  • 新成员不熟悉预约流程，会议室被占时临时改线上｜依据：「公司内FDE」2026-08、「公司内FDE」2026-09
  • 不关灯关门靠群内反复提醒，无责任人和后果｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 905/906/一楼会议室：飞书预约
  • 906 线上会议间（1～3 人）：面试、1v1 优先预约
  • 模态空间：场地方 App 预约，提交后等审批，到场扫码刷脸；统一由行政代约以免信息不同步
  • 重要演示：须同时确认投屏、门禁卡、Wi-Fi
  • 跨工区借用：按系统预约为准，不得借用管理层办公室作为常规方案

10. 待确认问题

  • 会议室管理主责是行政专员，还是按办公点分设区域行政？
  • 周期性占用审批阈值（每周 ≥ 2 次）是否合适？
  • 是否设置违规处罚？由谁执行？
  • 午休安静时段具体是几点？是否纳入员工手册？
  • 办公室禁烟是否成文？
ADM-06外部来访接待与参观/拍摄报备待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：客户、供应商、领导、院校、政府、媒体来访，外部朋友/合作方参观，或在办公点拍摄时，从报备到现场接待、费用与归档
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、CRM/接待表管理员（当前：闫登辉·推断待确认）、CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交接待申请 → ② 行政确认并预留资源 → ③ 分级审批（拍摄/政府/媒体）→ ④ 前一天同步物业与客户 → ⑤ 现场接待与场控 → ⑥ 宴请与费用 → ⑦ 当日归档
  • 交付结果：接待登记记录（含照片、纪要、费用）、已确认的会议室与物业配合事项、拍摄审核记录
  • 状态依据：已有接待办法、知识库接待申请入口、接待多维表格，并宣布会议预约统一找行政、拍摄需报备；但入口难找、信息靠群里口头通知，04～09 月仍多次出现找不到行政、研发自己倒茶、客人找不到停车、开拍才通知

1. 场景判定

  • 触发条件：任何外部人员计划进入办公点开会、参观、拍摄、采访；临时来访（含执法、司法人员）
  • 典型说法：「下午两点半有客人来，905 会议室，到时候安排一下茶水」「我不知道公司访客要找谁批准」「有拍摄计划的话可以和行政同步下」「公司酒水是领用还是买了再报销」
  • 判断问题：是否有外部人员进入办公区？是否涉及拍照拍摄、宴请或物业配合？
  • 不归本流程管：内部会议预约 → 请走 ADM-05；候选人面试到访 → 请走 ADM-07；临时门禁密码 → 请走 ADM-04；接待费用报销审批 → 请走 FIN-06（日常费用报销提交与审核）；对外宣传口径 → 请走 BRD-14（对外口径、品牌用语与发布前合规自查）；媒体采访拍摄的口径与受访安排 → 请走 BRD-12（媒体采访与外部拍摄接待）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政负责人 接待申请受理、资源预留、物业同步、现场接待 R/A 行政负责人（当前：胡则瑾·推断待确认）
行政专员 模态空间会议预约、拍照留档建档、物料准备 R 行政专员（当前：侯明月·推断待确认）
发起人/对接部门 提交申请、指定现场场控人、讲解 R 发起人（销售/市场/研发等）
市场销售负责人 商务接待规则、现场场控 C 市场销售负责人（当前：李鹏为·推断待确认）
接待表管理员 维护接待多维表格、关联客户记录 R（登记） 接待表管理员（当前：闫登辉·推断待确认）
CTO 研发画面、屏幕录制等拍摄内容技术保密审核 A（升级） CTO（当前：丁震宇·推断待确认）
综合部负责人 政府/领导/媒体来访审批与统筹 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）
CEO 重大来访出席、接待标准 I/C CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 来访方类型（客户/供应商/政府/院校/媒体/个人）、人数、时间、目的、我方接待人与场控人
  • 需求：会议室、投屏、茶水、停车、梯控/门禁、拍照、拍摄、宴请
  • 拍摄：拍摄区域、是否涉及研发画面或屏幕、是否会拍到客户信息
  • 车库指引与上楼指引（发给来访方）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“接待申请”表单 发起人 普通来访提前 ≥ 1 个工作日；政府/领导/大型参观 ≥ 3 个工作日；拍摄 ≥ 2 个工作日 飞书表单（工作台一键入口） 接待申请 🔧飞书固化
2 确认并预留会议室、茶水、停车、门禁卡，回复申请人 行政负责人 / 行政专员 申请后 4 个工作小时内 飞书会议室+表单 资源确认 🔧+🤖
3 拍摄内容技术保密审核；政府/媒体来访审批 CTO / 综合部负责人 1 个工作日内 飞书审批 审核意见 👤人工判断
4 同步物业前台（停车、梯控、门禁、备用会议室）；向来访方发指引卡；拍摄区域提前通知清屏 行政负责人 来访前 1 个工作日 飞书消息/公告 指引卡、通知 🔧+🤖
5 现场迎接、茶水、场控；按规则拍照留档 行政+发起人指定场控人 来访当日，提前 15 分钟到位 — 现场照片 👤人工判断
6 宴请/酒水：先领用库存，无库存再按标准报销 发起人 来访当日领用；报销按财务时限 领用表单/报销审批 领用/报销记录 🔧飞书固化
7 登记接待表（照片、纪要、费用、关联客户）；外借物品回收 发起人+接待表管理员 来访当日下班前 接待多维表格/CRM 接待档案 🔧+🤖

5. 交付物与模板

  • 交付物：接待申请、接待档案（多维表格）、拍摄审核意见、来访指引卡
  • 建议模板/表单：
    • 接待申请字段：来访方类型、单位（内部可写简称）、人数、时间、目的、我方接待人、场控人、所需资源（多选）、是否拍摄、是否宴请、预算
    • 来访指引卡：地址、车库入口与停车位、上楼路线、楼层门牌、联系人
    • 接待物料清单：茶水、矿泉水、纸杯、投屏线、Wi-Fi 卡、宣传册、门禁卡

6. 异常与升级

  • 未提前申请的临时来访 → 行政尽力安排，事后补登并计入指标 → 通报发起部门负责人
  • 行政不在场 → 按行政值班表找替补；无人时发起人自行接待并补登 → 升级综合部负责人
  • 执法/司法人员临时上门索要证照 → 首位接触人礼貌接待、核实身份，不擅自提供材料 → 立即通知综合部负责人，涉法事项转法务（30 分钟内）
  • 拍摄中发现屏幕有客户或技术信息 → 立即暂停相关画面 → 升级 CTO（当场）
  • 会议室被专项征用导致无接待场地 → 改用模态空间或备用场地 → 综合部负责人协调（当天）
  • 外借公共物品未归还 → 登记借出人，次日未还由行政追回
  • 升级条件：来访涉及拍摄/录屏且可能拍到研发画面或客户信息时，由 CTO 审核拍板（A（升级））；政府/领导/媒体等重大来访，或执法/司法人员上门时，由综合部负责人审批统筹（A（升级））；普通来访由行政负责人确认即可

7. 衡量指标

  • 接待提前申请率：有提前申请的来访占比，目标 ≥ 90%
  • 接待登记完整率：来访后当日完成登记的比例，目标 ≥ 95%
  • 拍摄报备率：拍摄活动提前报备并经审核的比例，目标 100%
  • 来访问题次数：客人找不到停车/上楼、无人接待等投诉次数，目标 0

8. 低效诊断

  • 来访当天行政不在场，研发自行倒茶接待，对外形象受影响｜依据：「鼎慧产研决策部」2026-05
  • 临时接待找不到行政，部分办公点无行政驻场｜依据：「【模态】综合部」2026-04
  • 接待申请入口不好找，提前通知靠群里口头｜依据：「【模态】综合部」2026-05
  • 客人找不到停车位和上楼路线｜依据：「【模态】综合部」2026-07
  • 接待酒水走领用还是报销口径不清｜依据：「【模态】市场销售」2026-04
  • 模态空间会议预约信息不同步，多头约场地｜依据：「【模态】市场销售」2026-05、「【模态】业务负责人」2026-05
  • 专项审计征用会议室后商务接待无场地｜依据：「【模态】业务负责人」2026-07
  • 媒体拍摄开拍才通知全员收拾｜依据：「模态集团全员群」2026-08
  • 外部人员上门要证照无对接人；外借桌子未归还｜依据：「模态集团全员群」2026-08、「模态集团全员群」2026-09

9. 分支变体

  • 普通客户/供应商来访：走步骤 1、2、4、5、7
  • 政府领导/工商联视察：步骤 3 审批，物业提前同步停车、梯控、备用会议室，指定场控人
  • 院校/朋友/合作方参观：提交申请报备行政，由熟悉对方行业的同事讲解
  • 媒体拍摄/采访：步骤 3 由 CTO 审核技术画面，品牌口径同步市场
  • 司法/执法人员临时上门：按异常处理，转综合部与法务
  • 商务宴请：费用标准按财务制度，酒水先领库存

10. 待确认问题

  • 接待主责是行政负责人，还是模态空间接待统一由行政专员负责？
  • 是否已有成文《接待办法》？接待费用标准由谁定？
  • 拍摄审核除 CTO 外是否还需品牌负责人？
  • 是否设立行政值班表覆盖各办公点？
  • 接待登记是否与 CRM 客户记录打通？
ADM-07面试会议室预约与候选人到访接待待优化90

状态：待优化｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频5 × 耗2 × 跨3 × 险3

  • 适用场景：线下或线上面试排期确定后，预约合适会议室与设备，并在候选人到访时引导、接待直至送离
  • 负责人：主责——HR 招聘专员（当前：张欣怡·推断待确认）；协同——HR 招聘助理（当前：匡蓉·推断待确认）、面试官（当前：丁震宇、陈晖、王皓南、张东郅等·推断待确认）、IT 运维（当前：杨明学·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）
  • 核心流程：① 排期确定 → ② 预约合适会议室 → ③ 前一天复核 → ④ 发到访指引 → ⑤ 到访接待 → ⑥ 面试进行 → ⑦ 送离并释放会议室
  • 交付结果：已绑定会议室的面试日程、候选人到访登记、面试结束后释放的会议室
  • 状态依据：已用飞书日历约会议室，但 04～09 月反复出现会议室被占、只约半小时被赶出、空调故障临时换房、借用管理层办公室或机房、候选人过早到场

1. 场景判定

  • 触发条件：面试官与候选人确认面试时间（线下或线上）
  • 典型说法：「会议室紧缺」「会议室只约了半小时」「没会议室怎么线下面试」「别约大会议室，太浪费了」
  • 判断问题：是否为招聘面试？候选人是否会到办公点？
  • 不归本流程管：面试轮次与面试官安排 → 请走 X-RCT-11（面试安排与面试官分配）；面评与晋级决策 → 请走 X-RCT-12；录用审批 → 请走 X-RCT-17；普通内部会议 → 请走 ADM-05；会议室设施故障报修 → 请走 ADM-08；其他外部来访 → 请走 ADM-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
HR 招聘专员 预约会议室、发到访指引、现场接待 R/A HR 招聘专员（当前：张欣怡·推断待确认）
HR 招聘助理 协助预约与接待 R HR 招聘助理（当前：匡蓉·推断待确认）
人事负责人 冲突协调、规则制定 A（升级） 人事负责人（当前：黄莹·推断待确认）
面试官 确认时间、按时到场、提前说明设备需求；面试提前结束时释放会议室 R（释放会议室） 面试官（当前：丁震宇、陈晖、王皓南、张东郅等·推断待确认）
行政 会议室故障处理、备用房间 C 行政负责人（当前：胡则瑾·推断待确认）
IT 运维 摄像头/视频会议设备 C IT 运维（当前：杨明学·推断待确认）

3. 办之前请准备

  • 面试时间、预计时长、面试官人数、是否需要摄像头/投屏、线上或线下
  • 候选人姓名（内部使用）、到达方式
  • 可用小会议室/线上会议间清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 与面试官确认时间与形式 HR 招聘专员 排期后 1 个工作小时内 飞书日程 面试日程 🔧飞书固化
2 在面试日程中绑定会议室：1v1 优先线上会议间/小间；时长默认 60 分钟+10 分钟缓冲 HR 招聘专员 与步骤 1 同时 飞书会议室 会议室预约 🔧+🤖
3 面试前 1 个工作日复核会议室状态与设备；冲突或故障即换房 HR 招聘助理 前 1 个工作日 17:00 前 飞书会议室 复核记录 🔧+🤖
4 发送到访指引：地址、楼层门牌、到达时间（不早于 10 分钟）、联系人 HR 招聘专员 前 1 个工作日 邀约短信/邮件模板 到访指引 🔧+🤖
5 候选人到达后迎接、登记，带至会议室，路线避开工作屏幕区 HR 招聘专员 到达后 5 分钟内 访客登记表 到访记录 👤人工判断
6 线上面试：会议链接提前发出，摄像头要求提前告知 HR 招聘专员 前 1 个工作日 飞书视频会议 会议链接 🔧飞书固化
7 面试结束送离，提前结束即释放会议室 HR 招聘专员 / 面试官 结束后 5 分钟内 飞书会议室 释放时段 👤人工判断

5. 交付物与模板

  • 交付物：面试日程（含会议室）、候选人到访指引、到访登记
  • 建议模板/表单：
    • 到访指引模板：公司地址、楼栋楼层、门牌/会议室名、停车与上楼方式、建议到达时间、现场联系人
    • 访客登记字段：姓名、应聘岗位、到达时间、接待人、离开时间

6. 异常与升级

  • 会议室当日被占 → 按系统预约协调；无预约者让出 → 仍无解时改线上或小间 → 升级人事负责人（15 分钟内）
  • 会议室设施故障（如空调滴水）→ 报行政走 ADM-08，同时换房 → 当场处理
  • 面试超时被下一场赶出 → 就近换空房继续 → 计入超时次数，调整默认时长
  • 候选人过早到达 → 安排在等候区，不进入工作区 → HR 招聘专员处理
  • 无任何可用房间 → 使用管理层办公室须事先征得同意，禁止使用机房 → 升级人事负责人
  • 升级条件：面试会议室当日冲突 15 分钟内无法协调、无任何可用房间需借用管理层办公室，或需调整面试默认时长等规则时，由人事负责人拍板（A（升级））；日常预约与接待由 HR 招聘专员负责到底

7. 衡量指标

  • 面试会议室冲突次数：每月因被占/故障临时换房次数，目标 ≤ 2 次/月
  • 面试超时被打断次数：目标 0
  • 到访指引发送率：线下面试提前发送指引的比例，目标 100%
  • 大房小用比例：1～2 名面试官使用大会议室的占比，目标 ≤ 10%

8. 低效诊断

  • 会议室紧缺，面试排期时找不到房间｜依据：「技术岗招聘沟通」2026-04
  • 预约信息不同步，已约会议室被占用｜依据：「技术岗招聘沟通」2026-05、「技术岗招聘沟通」2026-07
  • 会议室只约半小时，面试中途被赶出｜依据：「技术岗招聘沟通」2026-06
  • 面试前才发现会议室设施故障｜依据：「技术面试拉练小分队」2026-09
  • 面试官需自行找会议室｜依据：「技术部」2026-09
  • 无房时借用管理层办公室或机房；候选人过早到场并看到内部工作屏幕｜依据：「系统测试招聘」2026-08
  • 小规模面试预约大会议室造成浪费｜依据：「系统测试招聘」2026-08

9. 分支变体

  • 线下面试：走全部步骤
  • 线上面试：跳过步骤 4、5，执行步骤 6；面试官仍需安静房间时预约线上会议间
  • 多轮连续面试：一次预约整段时间，中间不释放
  • 不同办公点（905/906）：到访指引中写清楚具体楼栋

10. 待确认问题

  • 面试会议室由 HR 统一预约，还是面试官自约？
  • 默认 60 分钟时长是否适合各岗位？
  • 是否为面试固定保留线上会议间的时段？
  • 候选人到访是否需要签保密/访客登记？
  • 行政在面试场地保障中的对接人是谁？
ADM-08办公设施故障报修与维修验收待新建225

状态：待新建｜证据：有证据（卡片 9 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨3 × 险5

  • 适用场景：空调、门锁、门窗、灯具、插座、电闸、卫生间、漏水、网络/AP、机房过热、家具、咖啡机等设施损坏或异常时，从报修到师傅上门、验收、费用与复盘
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、CEO（当前：邴龙志·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外部物业/厂家；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 表单报修 → ② 自动分派 → ③ 初判与预计时间 → ④ 比价/审批 → ⑤ 预约上门 → ⑥ 维修与现场验收 → ⑦ 关单记费用 → ⑧ 重复故障复盘
  • 交付结果：关闭的报修工单（含照片、费用、供应商、质保期）、应急联系人表、重复/重大故障复盘记录
  • 状态依据：报修全靠群里 @，无工单和台账；03 月电闸烧毁造成停工和设备损坏，夜间无人掌握物业联系方式；01～10 月漏水、跳闸、断网、机房高温反复出现约 25 次以上，验收只看照片、进度需反复催

1. 场景判定

  • 触发条件：办公设施无法正常使用或存在安全隐患（漏电、冒烟、漏水、承重、机房高温）
  • 典型说法：「905 空调坏了，漏水」「公司好像又跳闸停电了」「师傅那边啥情况了，今天能好吗」「申请维修，不能天天下雨吧」「如遇物品损坏，第一时间告知行政」
  • 判断问题：坏的是办公场地/公共设施，还是个人使用的电脑等 IT 设备？是否有安全风险需要立即处理？
  • 不归本流程管：电脑/显示器等 IT 设备故障 → 请走 ADM-31；会议室遗留物 → 请走 ADM-15；节假日断电与值守 → 请走 ADM-10；新场地装修施工 → 请走 ADM-01；损坏后需新购 → 请走 ADM-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政负责人 设施类工单受理、联系物业/厂家、验收、关单 R/A 行政负责人（当前：胡则瑾·推断待确认）
行政专员 物业联络备份、战损统计、费用资料整理 R 行政专员（当前：侯明月·推断待确认）
IT 运维 网络、机房、电力负载、门锁等技术类判断与处理 R（技术类） IT 运维（当前：杨明学·推断待确认）
综合部负责人 督办超时工单、审批中等金额维修 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）
CEO 电路大修、结构改造等重大维修拍板；事故时决定居家办公 A（升级） CEO（当前：邴龙志·推断待确认）
CTO 机房温度异常等技术类故障的升级处理 C CTO（当前：丁震宇·推断待确认）
财务 维修费付款/报销 C 财务负责人（当前：黄梦婷·推断待确认）
报修人 提交报修、参与验收 R（报修） 全员

3. 办之前请准备

  • 故障位置（办公点/楼层/房间）、设施类别、现象、照片或视频
  • 是否紧急：漏电、冒烟、跳闸、漏水、机房温度异常、门无法上锁
  • 应急联系人表（物业、电工、电信、空调/门锁厂家、房东）——放知识库，行政与 IT 均可查
  • 已知质保信息（设备购买时间、维修供应商）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“设施报修”表单；紧急情况同时电话行政并在全员群告知 报修人 发现后立即 飞书表单 报修工单 🔧飞书固化
2 按类别自动派单：设施→行政，网络/机房/门锁/电力负载→IT 运维 系统 提交后即时 机器人+多维表格 已分派工单 🤖自动化
3 响应并初判（自修/物业/厂家），给出预计完成时间 行政负责人 / IT 运维 紧急 15 分钟内；一般 2 个工作小时内 多维表格 初判与预计时间 👤人工判断
4 超过自修范围的维修比价 ≥ 2 家；超出限额报综合部负责人，电路大修/结构改造报 CEO 行政负责人 1 个工作日内 飞书审批 审批结果 🔧+👤
5 预约师傅上门，尽量避开办公时段；安排人到场开门（临时门禁走 ADM-04） 行政负责人 一般故障 2 个工作日内上门 飞书任务 上门安排 👤人工判断
6 维修完成后报修人+行政现场验收，前后照片对比，确认质保期 行政负责人、报修人 完工当日 验收清单 验收记录 👤人工判断
7 关单：登记费用、供应商、质保；费用走对公付款或报销 行政专员 验收后 1 个工作日内 多维表格+付款/报销审批 关闭工单 🔧飞书固化
8 同一点位 30 天内重复故障 ≥ 2 次，或造成停工/设备损坏，组织复盘 行政负责人 3 个工作日内 飞书文档 复盘记录与整改项 👤人工判断

5. 交付物与模板

  • 交付物：报修工单台账、验收记录、应急联系人表、维修供应商库、复盘记录
  • 建议模板/表单：
    • 报修表单字段：报修人、办公点、具体位置、类别（空调/电力/门窗锁/水/灯具插座/网络/机房/家具/电器/保洁/其他）、紧急程度、照片、现象描述
    • 工单台账字段：工单号、类别、处理人、响应时间、预计完成、实际完成、维修方、费用、质保期、验收人、是否重复故障
    • 验收清单：功能恢复、现场清理、无安全隐患、前后照片、质保约定

6. 异常与升级

  • 漏电/冒烟/跳闸/电闸烧毁 → 先断电、疏散相关区域，联系物业电工 → 立即升级 CEO 决定是否居家办公（30 分钟内）
  • 机房温度异常 → IT 运维远程/现场降温，必要时关停非核心设备 → 升级 CTO（15 分钟内）
  • 夜间/周末无法联系行政 → 按应急联系人表直接联系物业 → 次日补登工单
  • 物业修不了或厂家不响应 → 转备选供应商 → 升级综合部负责人（超时 1 个工作日）
  • 工单超过预计完成时间 → 机器人提醒处理人 → 超时 2 个工作日升级综合部负责人
  • 事故导致员工个人设备损坏 → 登记损坏清单与照片 → 升级综合部负责人按赔付规则处理（5 个工作日内答复）
  • 计划停电/检修 → 行政提前 ≥ 1 个工作日在全员群公告
  • 升级条件：维修费用超出行政自主限额[阈值待财务确认]、工单超时 2 个工作日或物业/厂家不响应时，由综合部负责人审批督办（A（升级））；电路大修、结构改造或漏电/电闸烧毁等事故需决定是否居家办公时，由 CEO 拍板（A（升级））；其余由行政负责人受理到关单

7. 衡量指标

  • 首次响应时长：报修到处理人响应的时间，目标 紧急 ≤ 15 分钟、一般 ≤ 2 个工作小时
  • 修复周期：报修到验收完成的自然日，目标 一般故障 ≤ 3 天
  • 重复故障率：30 天内同点位重复报修工单占比，目标 ≤ 10%
  • 工单化率：设施故障中有工单记录的比例，目标 ≥ 95%
  • 事故答复时长：个人财产损坏到公司答复的工作日数，目标 ≤ 5 天

8. 低效诊断

  • 报修无统一入口，靠群里 @ 人，夜间只有个别人掌握物业联系方式｜依据：「模态集团（全员群）」2026-03
  • 电路重复故障、“修好又烧”，重大维修拍板滞后｜依据：「内务大主管」2026-03、「内务大主管」2026-04
  • 验收只看照片，返工（门换后对不齐等）｜依据：「鼎慧产研决策部」2026-01、「公司建设大改造」2026-01
  • 周五坏的设施到下周才修，阳台门坏一周以上｜依据：「鼎慧产研决策部」2026-01、「公司建设大改造」2026-01
  • 维修进度需反复追问，无预计完成时间｜依据：「公司建设大改造」2026-01、「公司建设大改造」2026-06
  • 漏水、跳闸、断网每周多次，靠全员群曝光｜依据：「模态集团全员群」2026-06、「模态集团全员群」2026-07
  • 机房高温靠人工观察发现，无温度告警｜依据：「鸽子群模态分群」2026-07
  • 停电无提前通知，员工到岗才发现｜依据：「随便瞎聊啦～」2026-08
  • 维修费先垫付再报销，战损靠群文本统计｜依据：「平台部」2026-01、「内务大主管」2026-03
  • 事故中个人设备损坏追问无答复｜依据：「模态集团（全员群）」2026-03
  • 报修在群里随口说，物资库存需问人｜依据：「【模态】综合部」2026-05、「【模态】综合部」2026-07

9. 分支变体

  • 物业可修（空调、漏水、电闸）：行政直接联系物业
  • 需厂家/外部师傅（空调清洗、门锁、咖啡机）：比价后预约，避开办公时段
  • 网络/机房类：IT 运维处理，电信等运营商故障由 IT 对接
  • 紧急电力事故：按异常第 1 条处理，事后必须复盘
  • 保洁类（缺纸、卫生）：公共区域由保洁负责，工区各组自理；行政按巡检补物资
  • 不同办公点（905/906/模态空间/K11）：按场地方物业分别联系

10. 待确认问题

  • 设施报修主责是行政负责人吗？IT 运维承担哪些类别？
  • 行政自主维修的金额上限、需综合部负责人审批的上限、需 CEO 拍板的上限分别是多少？
  • 维修费是否统一对公付款，取消员工垫付？
  • 事故中个人设备损坏的赔付规则由谁制定？
  • 机房是否加装温度监控告警？由谁负责？
  • 应急联系人表放在哪里、由谁维护？
ADM-09停电/极端天气等突发事件通知与居家办公安排待新建96

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：办公楼计划停电/修闸、突发断电断网、网络线路割接，或台风暴雨等极端天气影响通勤与办公时，统一发布通知并决定到岗、居家或换点办公。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——IT运维（当前：杨明学·推断待确认）、产研通知对接人（当前：杨萌·推断待确认）、管理层决策人（当前：丁震宇、常元和、邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 获知事件并分级 → ② 行政与 IT 拉齐影响范围 → ③ 管理层定到岗/居家方案 → ④ 发布唯一口径加急通知 → ⑤ 停电前按清单关服务 → ⑥ 员工报备与换点办公 → ⑦ 恢复确认与复盘
  • 交付结果：一条统一口径、已加急并确认已读的通知；服务器按清单关停与恢复的记录；居家/换点办公报备记录；事件复盘记录
  • 状态依据：无成文预案、通知模板与报备方式；2026-03 断电时口头批居家、临时找替代场地；2026-07 台风先通知"带电脑回家/可能居家"、两天后改"正常到岗"；2026-08 停电当天才讨论服务器预案，行政与产研重复通知且口径不一（相关讨论约 15 次）

1. 场景判定

  • 触发条件：物业/大楼发布停电、修闸、检修通知；办公区突发断电断网；运营商或 IT 计划网络割接；气象部门发布台风、暴雨、大风等预警；其他影响通勤或办公连续性的突发事件。
  • 典型说法：「明早九点断电修闸，预计持续半小时」「公司断电了，申请居家办公」「是否要通知大家周一居家办公」「速速通知，不然来不及了」「停电预案就是提前先关服务器」
  • 判断问题：这件事会不会让至少一个办公区在工作时间失去电力、网络或安全通勤条件？是否需要员工改变到岗方式，或需要提前关停服务器？两项都为"否"则不走本流程。
  • 不归本流程管：单个设备/工位故障 → 请走 ADM-08；下班及节假日日常断电锁门 → 请走 ADM-10；员工因个人原因申请居家/远程 → 请走 HR-11（请假、居家/远程办公与外勤报备）；办公网络故障本身的排障 → 请走 X-SEC-27；机房/服务器停机与故障应急 → 请走 X-SEC-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事件主责 登记分级、起草并发布唯一通知、跟进报备与复盘 R 行政负责人（当前：胡则瑾·推断待确认）
决策人 确定正常到岗/带电脑回家/居家/换点方案 A 管理层（当前：丁震宇、常元和、邴龙志·推断待确认）
IT 保障 评估机房与服务影响，按清单关停/恢复服务器与 CI，组织割接测试 R IT运维（当前：杨明学·推断待确认）
产研通知对接 在产研群转发行政通知、确认业务服务恢复 C 产研通知对接人（当前：杨萌·推断待确认）
人事 居家办公考勤口径 C 人事负责人（当前：黄莹·推断待确认）
全体员工 阅读确认、保存工作、按要求报备 I 全员

3. 办之前请准备

  • 物业/气象/运营商的原始通知（时间、范围、预计时长）
  • 受影响区域清单（905、906、10 楼）及机房、在运行服务器、远程机器清单
  • 物业与大楼联系人表（含备用联系人）
  • 替代办公点信息：地址、门禁方式、接待人、访客网络获取方式（不在群内公开凭据）
  • 通知模板：停电版 / 断网版 / 极端天气版
  • 服务器关停与启动顺序文档

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 获知事件，登记时间、范围、预计时长，按"计划内/突发/极端天气"分级 行政负责人 获知后 30 分钟内 飞书多维表格（事件登记） 事件记录 🔧飞书固化
2 向 IT 运维确认机房、服务器、CI、远程机器的影响范围和关停需求 行政负责人、IT运维 登记后 1 小时内 飞书群 影响范围说明 👤人工判断
3 需改变到岗方式时，带方案选项请决策人拍板 行政负责人 → 管理层 计划内事件提前 1 个工作日；突发 30 分钟内；预警发布当天 17:00 前 飞书加急消息 决策结论 👤人工判断
4 按模板发布唯一通知（时间、范围、到岗方式、报备方式、联系人），其他群只转发不另写 行政负责人 决策后 30 分钟内；计划停电至少提前 1 个工作日 飞书公告 + 加急 + 已读统计 统一通知 🔧+🤖
5 停电前保存数据、按清单关停服务器与 CI，记录关停时间 IT运维 停电前 1 小时完成 停电检查清单 关停记录 🔧飞书固化
6 需居家/换点/无法通勤的员工提交报备；换点办公由行政提前约接待与门禁 员工、行政负责人 通知规定时间前 飞书审批（居家/异地办公） 报备记录 🔧飞书固化
7 预警或停电时间变化时发补充通知，标明"替代上一条" 行政负责人 变化后 1 小时内，最迟前一天 21:00 飞书公告 更新通知 👤人工判断
8 来电/来网后按启动顺序恢复服务与 CI，在群内通知恢复 IT运维、产研通知对接人 来电后 1 小时内 启动顺序文档 恢复确认 🔧+🤖
9 补全事件记录，写明问题与改进项 行政负责人 事件结束后 2 个工作日内 飞书多维表格 复盘记录 🔧飞书固化

5. 交付物与模板

  • 交付物：统一通知（含已读统计）、服务器关停/恢复记录、居家/换点报备记录、事件登记与复盘记录
  • 建议模板/表单：
    • 突发事件登记表：事件类型、信息来源、开始/结束时间、影响区域、影响系统、决策结论、决策人、通知时间、已读率、问题与改进
    • 通知模板：事件说明｜生效时间｜影响范围｜到岗方式｜员工需做的事（保存文件、关机、带电脑）｜报备方式｜联系人
    • 停电检查清单：关停服务 → 确认备份 → 断开非必要设备 → 记录 → 来电后按序启动 → 验证 CI
    • 居家/异地办公审批：申请人、日期、原因（选项）、办公地点、可联系时段

6. 异常与升级

  • 联系不上物业 → 行政负责人改用备用联系人/大楼前台 → 30 分钟仍无结果升级综合部负责人
  • 决策人 30 分钟内未回复且影响当天通勤 → 行政负责人按"安全优先"默认方案（居家）发布并同步决策人
  • 未按清单关停导致服务或容器异常 → IT运维 2 小时内排查恢复，影响客户服务时同步研发负责人（当天）
  • 通知发布后出现口径冲突 → 以行政公告为准，行政负责人 1 小时内统一澄清
  • 替代办公点无法进入或无网络 → 现场同事联系行政，行政 30 分钟内协调接待与网络

7. 衡量指标

  • 计划内事件提前通知率 = 提前 ≥1 个工作日发布的计划内事件数 / 计划内事件总数，目标 100%
  • 通知改口次数 = 同一事件发布后更改到岗方式的次数，目标 ≤1 次
  • 通知已读率 = 生效前已读人数 / 应读人数，目标 ≥95%
  • 停电致服务异常次数 = 因未按清单关停导致的服务/数据异常次数，目标 0
  • 恢复时长 = 来电到服务与 CI 全部恢复的时间，目标 ≤1 小时

8. 低效诊断

  • 现象：停电预案在停电当天才临时讨论，服务器关停与恢复靠口头确认，曾出现断电后容器异常｜依据：「Leap产研测」2026-08
  • 现象：行政与产研分别发通知，网络保障时间口径不一致，员工无法判断以谁为准｜依据：「Leap产研测」2026-08、「【模态】综合部」2026-08
  • 现象：极端天气无判断标准与通知时点，先通知可能居家、两天后改为正常到岗，员工对"带电脑回家"有疑问｜依据：「模态跃迁通知群」2026-07、「【模态】综合部」2026-07
  • 现象：断电时居家申请与批准在群里口头完成无记录；替代办公点到场后才找人刷卡、问网络，网络凭据在群内公开｜依据：「⭐大模型基座事业群」2026-03
  • 现象：物业联系人不固定，事发当天需辗转找人｜依据：「Leap产研测」2026-08

9. 分支变体

  • 计划内停电/修闸：提前 ≥1 个工作日通知，重点是 IT 关停清单；多发生在非工作时间
  • 突发断电断网：30 分钟内决定居家或换点；默认替代点为合作空间（模态空间），需提前约接待与门禁
  • 网络线路割接：IT 运维提前预约集体测试时段，割接后 1 小时内验证
  • 极端天气：以气象预警触发，前一天 17:00 前发首条通知、21:00 前发最终通知；夜间突发无法通勤者走报备审批，不再私信
  • 是否放假/停工：仅由管理层决定，行政不得自行发布

10. 待确认问题

  • 事件主责是否定为行政负责人？服务器关停是否固定由 IT 运维负责，备岗是谁？
  • 到岗/居家由谁最终拍板？多位决策人均未响应时，是否默认"安全优先居家"？
  • 极端天气触发标准（如黄色及以上预警）和通知时点（前一天 17:00/21:00）是否可行？
  • 是否开通飞书"居家/异地办公"审批？考勤如何认定？
  • 合作空间作为替代办公点是否长期可用？接待与门禁对接人是谁？
  • 是否已有物业联系人表和服务器启动顺序文档？
ADM-10下班及节假日离岗安全检查（断电、锁门、机房）待新建160

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频5 × 耗2 × 跨4 × 险4

  • 适用场景：每天下班最后离开办公区时，以及周末、长假前，完成关灯、空调、电视、电脑与电源，锁好门窗，并确认机房和远程机器的断电或保电安排。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月、丁蕊·推断待确认）、IT运维（当前：杨明学·推断待确认）、人事负责人（当前：黄莹·推断待确认）、各区域最后离开者；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 建分区域设备台账与关闭图文 → ② 门口张贴离岗清单 → ③ 最后离开者按清单检查 → ④ 次日早抽查与异常登记 → ⑤ 节前征询保电需求 → ⑥ IT 确认机房/远程机器保电范围 → ⑦ 节前通知与当晚巡检 → ⑧ 节后恢复确认
  • 交付结果：张贴的离岗检查清单与空调等设备关闭图文；每日抽查与节前巡检记录；节假日断电范围与保电设备清单；纳入入职培训的办公区安全规范
  • 状态依据：2026-04 已要求行政跑通关灯锁门关空调 SOP 并写成文档，后续未见发布；2026-04～10 反复出现不锁门、不关灯、空调不会关、物品遗失；节前每次临时询问"放假断电吗"（相关讨论约 15 次）

1. 场景判定

  • 触发条件：每天下班办公区最后一人离开；周末、法定节假日或长假前最后一个工作日；施工或机房整理需要断电；发现门未锁、灯/空调未关、物品遗失、陌生人进入研发区。
  • 典型说法：「怎么经常不锁门不关灯」「谁走的时候不关灯不关空调」「放假断电吗」「离开办公室之前，在工位上多花两分钟」「要整一个下班巡检流程」
  • 判断问题：是不是"人离开办公区时"设备、门窗、电源状态的问题？是否需要确认机房或远程机器能不能断电？
  • 不归本流程管：停电/极端天气等突发事件 → 请走 ADM-09；设备损坏报修 → 请走 ADM-08；物品找寻与失物招领 → 请走 ADM-15；机房服务器停机维护与故障应急 → 请走 X-SEC-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
清单与规范主责 编写清单与设备关闭图文、张贴、节前通知、月度汇总 A 行政负责人（当前：胡则瑾·推断待确认）
行政巡检 次日早抽查、节前当晚巡检、登记异常 R 行政专员（当前：侯明月、丁蕊·推断待确认）
IT 保障 维护机房/远程机器保电清单，节前确认断电范围，维护监控与智能开关 R IT运维（当前：杨明学·推断待确认）
入职培训 把办公区安全规范纳入入职培训 R 人事负责人（当前：黄莹·推断待确认）
区域最后离开者 按清单逐项检查并关闭 R 各区域员工
机器使用人 节前申报需保电的远程机器 C 研发各组
兜底 制度审批与争议裁定 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 分区域设备台账：905、906（含二楼）、10 楼的灯、空调、电视、门窗、排插、冰箱位置与关闭方式
  • 空调等难关设备的图文/短视频关闭说明（必要时请物业现场演示）
  • 机房与远程机器保电清单：楼层、设备、用途、是否可断电、使用组
  • 门口张贴版离岗检查清单
  • 监控覆盖区域说明
  • 节前离岗通知模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建分区域设备台账与关闭图文，必要时请物业演示，放入知识库 行政负责人 本 SOP 发布后 5 个工作日内；设备变动后 2 个工作日内更新 飞书知识库 设备台账+图文 🔧飞书固化
2 打印离岗检查清单，张贴在各区域门口与会议室 行政专员 台账完成后 2 个工作日内 打印张贴 张贴物 👤人工判断
3 最后离开者按清单检查灯、空调、电视、电脑、门窗 区域最后离开者 离开前 张贴清单 关闭状态 👤人工判断
4 次日到岗检查或调取监控抽查，异常拍照登记并在区域群提醒（不点名） 行政专员 次日 10:00 前 飞书多维表格 + 监控 异常登记 🔧+🤖
5 节前向 IT 与各组推送保电需求征询 行政负责人 假期前 3 个工作日 飞书机器人定时推送 保电申报 🔧+🤖
6 确认机房/远程机器保电范围与各楼层断电方案；有施工同步时间 IT运维 假期前 2 个工作日 保电清单 断电范围确认 👤人工判断
7 发布节前离岗通知：断电范围、电脑关机、拔排插、清冰箱、带走物品、最后离开者检查 行政负责人 假期前 1 个工作日 12:00 前 飞书公告 节前通知 🔧飞书固化
8 放假当晚巡检门窗电源，拍照记录 行政专员 放假当天下班后 2 小时内 巡检表 巡检记录 🔧飞书固化
9 节后确认来电、机房与远程机器在线 IT运维 节后首个工作日 10:00 前 监控/远程检查 恢复确认 👤人工判断
10 汇总当月异常，评估智能插座、红外空调遥控、门状态告警等改造 行政负责人、IT运维 每月第 1 个工作日 多维表格 月度汇总 🤖自动化
11 将办公区安全与离岗规范加入入职培训 人事负责人 规范发布后的下一批入职起 入职培训材料 培训内容 🔧飞书固化

5. 交付物与模板

  • 交付物：离岗检查清单（张贴版+知识库版）、设备关闭图文、每日抽查与节前巡检记录、节假日保电清单、入职培训安全规范
  • 建议模板/表单：
    • 巡检表：日期、区域、检查人、灯/空调/电视/电脑/门窗/排插（是否关闭）、异常描述、照片、处理结果
    • 保电清单：楼层、设备、用途、使用组、是否可断电、断电前操作、节后验证人
    • 节前通知模板：放假时间｜断电楼层与保电设备｜员工需做的事｜施工安排｜巡检人

6. 异常与升级

  • 早上发现门未锁或门开着 → 行政专员查监控、清点公共物资 → 有遗失当天升级综合部负责人与 IT运维
  • 空调/设备无法关闭 → 行政 1 个工作日内联系物业 → 仍无法解决纳入智能开关改造
  • 研发区出现陌生人 → 在场员工询问来意并引导离开研发区 → 立即通知行政；有拍摄、踩点等可疑行为同步 IT运维与综合部负责人
  • 节前保电范围未确认 → 默认机房与在册远程机器不断电，IT运维当天补确认
  • 同一区域一个月内异常 ≥3 次 → 行政负责人约区域组长明确值守责任（5 个工作日内）

7. 衡量指标

  • 离岗合规率 = 抽查无异常天数 / 抽查天数，目标 ≥95%
  • 节前通知准时率 = 假期前 1 个工作日 12:00 前发布次数 / 节假日次数，目标 100%
  • 节前临时询问次数 = 群内"是否断电"类询问次数，目标 0
  • 办公区物品遗失事件数，目标每季度 ≤1
  • 机房/远程机器非计划断电次数，目标 0

8. 低效诊断

  • 现象：不关灯、不锁门靠全员群吐槽和口头提醒，没有检查人和检查记录｜依据：「模态集团（全员群）」2026-04、「公司全员群」2026-10
  • 现象：空调关闭方式无人掌握，已要求编写的关灯锁门 SOP 未见发布｜依据：「模态集团（全员群）」2026-04
  • 现象：下班巡检方案在"人工签字巡检"和"监控+智能开关"之间反复，未定稿｜依据：「【模态】综合部」2026-08
  • 现象：出现物品遗失、清洁人员早上发现门开着后才提出规范｜依据：「【模态】综合部」2026-10
  • 现象：节前断电范围、机房能否断电每次临时询问｜依据：「运维&综合对接群」2026-09、「公司全员群」2026-09

9. 分支变体

  • 905：一楼办公区按日常清单；二楼有十余台运行设备，节假日不断电
  • 906：机房所在楼层，节假日不断电；二楼单独检查
  • 10 楼：节假日断电，中央空调关闭
  • 会议室：电视、空调为重点检查项
  • 施工日（机房空调管道、线缆整理）：提前通知员工带走个人物品
  • 研发区陌生访客：按"异常与升级"处理

10. 待确认问题

  • 主责是否为行政负责人？日常采用"区域最后离开者"机制，还是行政值日？
  • 是否采购智能插座、红外空调遥控、门状态告警？预算由谁审批？
  • 节前时点（提前 3/2/1 个工作日）是否可行？
  • "9 楼不断电、10 楼断电"规则是否长期有效？
  • 安全规范是否纳入入职培训？由人事还是行政讲？
ADM-11办公区保洁、值日、大扫除与虫害消杀待优化48

状态：待优化｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频4 × 耗2 × 跨3 × 险2

  • 适用场景：办公区日常卫生维护、外包保洁、节前/夏季大扫除、装修后清理，以及出现蟑螂、蚊虫、异味、积水等卫生事件时，安排值日、保洁或消杀并验收。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——卫生委员（当前：侯明月、赵雪冰·推断待确认）、各组组长/卫生小组长、外包保洁、消杀服务商；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 划分区域并发布月度值日表 → ② 值日人每日整理 → ③ 外包保洁每周清洁拍照 → ④ 行政验收 → ⑤ 杂物清运 → ⑥ 定期大扫除 → ⑦ 定期消杀 → ⑧ 卫生事件即时处置
  • 交付结果：月度值日表与完成记录；保洁验收记录（含照片）；大扫除与消杀日历及执行记录；卫生事件处置记录
  • 状态依据：2026-01 已公告值日分区与每周保洁规则，2026-04 设卫生委员和小组长；但值日表"后续发放"、大扫除因人不齐改期、2026-06 虫害扩散后才外聘消杀、装修后保洁范围来回确认约 5 次

1. 场景判定

  • 触发条件：每月值日排班；每周保洁；节前、夏季前或装修后需要集中清理；员工报告虫害、异味、积水、垃圾堆积；纸箱等杂物需清运。
  • 典型说法：「周五统一安排大扫除，到时候给大家派活」「安排灭虫吧，后面把药用来长期避虫」「现在开始消杀，大家把个人物品收拾一下」「每周有保洁，和值日员不冲突」
  • 判断问题：问题是否属于"清洁、卫生、虫害"？是否需要人去打扫或消杀，而不是修理或采购？
  • 不归本流程管：设施损坏、漏水报修 → 请走 ADM-08；清洁用品、杀虫药等采购 → 请走 ADM-14；下班关灯锁门 → 请走 ADM-10；行政事务归口与交接 → 请走 ADM-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 排值日、对接保洁与消杀、定大扫除、处置卫生事件 A 行政负责人（当前：胡则瑾·推断待确认）
卫生委员 督导值日、验收保洁、组织大扫除分工 R 卫生委员（当前：侯明月、赵雪冰·推断待确认）
区域小组长 安排区域值日人、确认杂物可清运 R 各组组长/卫生小组长（当前：待指定）
值日人 每日整理公共区 R 区域员工
外包保洁 每周清洁并拍照反馈 R 外包保洁（外部）
消杀服务商 定期/应急消杀 R 服务商（外部，行政选定）
兜底 边界争议与费用审批 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 区域划分：905 一楼、906 一楼、906 二楼、10 楼及公共区（会议室、茶水间、卫生间）
  • 各区域人员名单与小组长
  • 外包保洁合同范围（频次、区域、是否含 905、是否含深度保洁）
  • 消杀服务商 2～3 家备选及报价方式
  • 保洁验收检查表、大扫除分工模板、通知模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按区域生成下月值日表，小组长确认值日人 行政负责人、小组长 每月最后 1 个工作日前 飞书任务（循环） 月度值日表 🔧飞书固化
2 值日人整理公共区（垃圾、桌面、会议室），完成后勾选任务 值日人 每日下班前 飞书任务 完成记录 🔧飞书固化
3 外包保洁每周五晚或周六白天清洁，拍照上传 外包保洁 每周 飞书多维表格 清洁照片 🔧飞书固化
4 对照检查表验收保洁，不合格项反馈保洁 卫生委员 保洁后首个工作日 12:00 前 多维表格 验收记录 👤人工判断
5 区域确认纸箱等杂物无用后报行政，安排清运 小组长、行政负责人 报备后 1 个工作日内 飞书表单 清运记录 🔧飞书固化
6 节前/季度大扫除：定时间、按区域分工、提前通知，人数不足按区域补位不改期 行政负责人、卫生委员 提前 5 个工作日通知 飞书日程 + 分工表 大扫除记录 🔧飞书固化
7 定期消杀：每季度 1 次，6～9 月每月 1 次；提前通知收好食物、杯具与个人物品 行政负责人 提前 1 个工作日通知 消杀日历 消杀记录 🔧飞书固化
8 卫生事件：员工表单上报 → 行政判断自行处理或外聘专业服务 → 通知相关区域 行政负责人 上报后 4 个工作小时内响应，2 个工作日内处置 飞书表单 处置记录 🔧+👤
9 汇总当月验收、事件与复发情况，调整保洁范围或频次 行政负责人 每月第 1 个工作日 多维表格 月度小结 🤖自动化

5. 交付物与模板

  • 交付物：月度值日表、保洁验收记录、大扫除分工与执行记录、消杀日历与记录、卫生事件处置记录
  • 建议模板/表单：
    • 保洁验收表：日期、区域、地面、桌面、垃圾、卫生间、茶水间、照片、是否合格、整改项
    • 卫生事件上报表：上报人、区域、类型（虫害/异味/积水/垃圾/其他）、描述、照片、紧急程度、处置方式、完成时间
    • 大扫除分工表：区域、负责人、任务项、所需工具、完成确认

6. 异常与升级

  • 值日连续 2 天未完成 → 卫生委员提醒小组长 → 一周内再发生升级行政负责人
  • 保洁不合格连续 2 次 → 行政负责人约谈保洁方 → 仍未改善报综合部负责人评估更换（1 个月内）
  • 虫害扩散（多个区域或连续 3 天出现）→ 当天外聘专业消杀，费用超行政权限报综合部负责人审批
  • 装修后保洁、设备摆放归属不清 → 行政负责人 1 个工作日内裁定，裁定不了升级综合部负责人
  • 卫生间异味、积水由设施问题引起 → 转 ADM-08 报修

7. 衡量指标

  • 值日完成率 = 已完成值日次数 / 应值日次数，目标 ≥95%
  • 保洁验收合格率 = 合格次数 / 验收次数，目标 ≥90%
  • 卫生事件响应时长 = 上报到行政首次响应的工作小时数，目标 ≤4 小时
  • 大扫除按期率 = 按通知日期执行次数 / 计划次数，目标 100%
  • 虫害复发次数 = 消杀后 30 天内同区域再次上报次数，目标 0

8. 低效诊断

  • 现象：大扫除已通知又因人不齐推迟，没有排班和分工｜依据：「模态集团（全员群）」2026-02
  • 现象：虫害扩散后才处理，先买药再改外聘，没有定期消杀计划｜依据：「公司建设大改造」2026-06
  • 现象：装修后保洁由谁负责、保洁是否覆盖 905、桌椅摆放归谁，来回确认多次｜依据：「行政统筹协作群」2026-01
  • 现象：值日表多次"晚点发""等通知"，规则只在群里｜依据：「工程咨询产研」2026-01
  • 现象：大扫除前一天才通知；卫生间异味由员工自行分析原因｜依据：「跃迁基座」2026-03、「公司建设大改造」2026-09

9. 分支变体

  • 日常值日：按 905 一楼 / 906 一楼 / 906 二楼 / 10 楼分区
  • 外包保洁：每周一次；深度保洁（装修后）目前由需求方自找并走报销，建议改为行政统一找服务商
  • 大扫除：节前、夏季前、装修后
  • 消杀：定期计划 vs 虫害应急
  • 卫生事件：蟑螂/蚊虫、异味、积水

10. 待确认问题

  • 主责是否为行政负责人？卫生委员与行政的分工是否保留？
  • 外包保洁合同是否覆盖 905 与 10 楼？频次是否每周一次？
  • 深度保洁由行政统一找服务商，还是继续由需求方自找走报销？
  • 消杀频次（季度 + 夏季每月）与预算是否可行？
  • 值日是否改用飞书任务循环派发？
ADM-12行政制度与办公规范制定发布待优化96

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨4 × 险3

  • 适用场景：需要建立或修订采购、接待、福利、报销等公司级行政制度，或发布办公室使用规范（卫生间、门、空调、会议室规则）时，统一由行政起草、相关部门会签、审批后发布并入库。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、行政助理（当前：丁蕊·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、总助/总经办（当前：赵雪冰·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 提出制度/规范需求 → ② 行政登记立项 → ③ 起草初稿 → ④ 财务/人事/相关部门会签 → ⑤ 总助审核、CEO 审批 → ⑥ 发布公告与张贴 → ⑦ 入制度库并培训 → ⑧ 定期复审
  • 交付结果：经审批的制度文件或规范（带编号与版本）、发布公告、现场张贴物、制度库条目
  • 状态依据：已有商业报销方案（飞书 wiki），2026-04 采购、接待制度已定稿并配 SOP；但 2026-01 初版行政通知有问题需重发，研发代行政起草张贴规范，2026-03 仍有人问"现有规章制度有哪些"，制度从起草到定稿约 3 个月

1. 场景判定

  • 触发条件：管理层要求建立某项制度；同类行政问题反复出现需要成文规则；办公区出现需张贴的使用规范；已有制度需要修订或废止。
  • 典型说法：「发行政通知前，先讨论过一遍」「行政通知还得重构一下，上一版发的有问题」「能让行政发通知吗」「公司的规章制度和文件目前有哪些」
  • 判断问题：这是否是一条要长期执行、对多人有约束力的规则？如果只是一次性事件通知，不走本流程。
  • 不归本流程管：突发事件临时通知 → 请走 ADM-09；人事类制度（考勤、入转调离、薪酬）→ 请走 HR-01（人事制度编制、意见征集与发布宣贯）；财务报销具体执行 → 请走 FIN-06；单条 SOP 的日常更新 → 由该 SOP 主责维护

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 立项登记、起草、组织会签、发布、入库 R 行政负责人（当前：胡则瑾·推断待确认）
起草协助 资料收集、初稿与张贴物制作 R 行政助理（当前：丁蕊·推断待确认）
需求人 提出制度/规范需求、说明问题 R（提需求） 各部门提出人
财务会签 采购、报销、费用条款 C 财务负责人（当前：黄梦婷·推断待确认）
人事会签 福利、培训、员工行为条款；涉及全员行为的制度纳入新人培训 C 人事负责人（当前：黄莹·推断待确认）
总助审核 与现有制度一致性、格式 C 总助/总经办（当前：赵雪冰·推断待确认）
审批 公司级制度最终签发 A CEO（当前：邴龙志·推断待确认）
全员 阅读确认、执行 I 全员

3. 办之前请准备

  • 需求说明：要解决的问题、适用范围、涉及部门、期望生效日期
  • 现有相关制度与文档（如商业报销方案、采购制度、接待管理）
  • 同类问题的发生记录（时间、次数、影响）
  • 制度模板与张贴物模板
  • 会签人名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交制度/规范需求，行政登记立项并定分类（公司级制度/办公规范） 需求人、行政负责人 收到后 2 个工作日内 飞书多维表格（制度台账） 立项记录 🔧飞书固化
2 检索现有制度，确认是新建、修订还是合并 行政负责人 立项后 1 个工作日内 飞书知识库 检索结论 🤖自动化
3 起草初稿（可用 AI 生成初稿再人工修改） 行政负责人、行政助理 公司级 5 个工作日；办公规范 1 个工作日 飞书文档 初稿 🤖+👤
4 发起会签：财务、人事、相关部门在文档内批注 行政负责人 会签期 3 个工作日 飞书文档评论 / 飞书审批 会签意见 🔧飞书固化
5 总助审核一致性后提交 CEO 审批；办公规范由行政负责人审批即可 总助、CEO 2 个工作日内 飞书审批 审批结论 🔧飞书固化
6 发布：飞书公告 + 需张贴的打印上墙，标注编号、版本、生效日期 行政负责人 审批后 1 个工作日内 飞书公告 / 打印 发布公告、张贴物 🔧飞书固化
7 入制度库，更新制度台账，关联相关 SOP 行政助理 发布当天 飞书知识库 制度库条目 🔧飞书固化
8 涉及全员行为的制度纳入新人培训材料 行政负责人、人事 发布后 5 个工作日内 培训材料 培训内容 🤖+👤
9 复审：制度台账到期提醒，评估是否修订 行政负责人 每 12 个月 多维表格提醒 复审记录 🔧+🤖

5. 交付物与模板

  • 交付物：制度/规范正文、审批记录、发布公告、张贴物、制度库条目与台账
  • 建议模板/表单：
    • 制度台账：编号、名称、分类、版本、主责部门、适用范围、会签人、审批人、生效日期、下次复审日期、关联 SOP、状态
    • 制度正文模板：目的｜适用范围｜职责｜规则条款｜流程｜例外｜生效与解释
    • 张贴物模板：标题、一句话规则、图示、联系人（行政）

6. 异常与升级

  • 会签超过 3 个工作日未回复 → 行政负责人提醒 → 再超 1 个工作日升级综合部负责人
  • 发布后发现错误或引起歧义 → 1 个工作日内撤回或发更正，新版本标注变更点
  • 非行政人员代拟或代发规范 → 转行政负责人按本流程补登记与审批
  • 新制度与现有制度冲突 → 综合部负责人 2 个工作日内裁定

7. 衡量指标

  • 制度发布周期 = 立项到发布的工作日数，目标：公司级 ≤12 个工作日，办公规范 ≤3 个工作日
  • 发布后更正/重发次数，目标每季度 ≤1 次
  • 制度入库率 = 已入库制度数 / 已发布制度数，目标 100%
  • "现有制度在哪"类询问次数，目标逐季下降

8. 低效诊断

  • 现象：初版行政通知发布后发现问题需重构，发布前没有会签｜依据：「鼎慧产研决策部」2026-01、「内务大主管」2026-01
  • 现象：办公室使用规范由研发、产品代为起草和张贴，发布权责不清｜依据：「鼎慧产研决策部」2026-01
  • 现象：现有制度、组织架构、部门职责没有统一入口，新人需逐一询问｜依据：「内务大主管」2026-03
  • 现象：采购、接待、福利制度从起草到定稿约 3 个月，过程靠群内推进｜依据：「内务大总管（2026版）」2026-04

9. 分支变体

  • 公司级制度（采购、接待、福利、报销）：全流程会签 + CEO 审批
  • 办公室使用规范（卫生间、门、空调、会议室）：简化流程，行政负责人审批后张贴 + 群公告
  • 接待制度涉及模态本部与模态空间两处场地，需分别写明接待人与流程

10. 待确认问题

  • 行政岗已由侯明月交接给胡则瑾，本流程主责按现任行政负责人填写，是否确认？
  • 哪些制度需 CEO 审批、哪些行政负责人可直接发布？
  • 制度库放在哪个飞书知识库空间？谁维护台账？
  • 会签 3 个工作日、发布周期目标是否可行？
  • 复审周期 12 个月是否合适？
ADM-13行政事务归口、交接与行政日报待新建135

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频5 × 耗3 × 跨3 × 险3

  • 适用场景：快递、报修、打印、保洁、物品领用、会议室等行政杂务没有明确承接人，行政岗位变动、空缺或由实习/兼职助理承担，以及行政人员每日工作汇报时。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员/助理（当前：侯明月、丁蕊·推断待确认）、财务（当前：黄梦婷·推断待确认）、人事负责人（当前：黄莹·推断待确认）、CTO（行政缺位时的临时协调，当前：丁震宇·推断待确认）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 编制行政事务归口清单 → ② 设统一受理入口 → ③ 公示岗位分工与在岗时间 → ④ 每日提交日报 → ⑤ 跨部门事项同步总经办 → ⑥ 岗位变动按清单交接 → ⑦ 空缺期指定代理人 → ⑧ 每周复盘未结事项
  • 交付结果：行政事务归口清单（每项有主责、备岗、入口、时限）；行政服务受理台账；每日行政日报；岗位交接清单与签收记录
  • 状态依据：2026-03～06 行政岗变动与空缺期间，快递、修门、打印、保洁无人承接，会议室门坏数月未修；行政工作转给人事兼做，兼职助理职责边界不明；2026-04 规定行政日报群和同步规则后，日报中断约 10 天才被发现

1. 场景判定

  • 触发条件：员工不知道某项行政杂务找谁；行政人员入职、离职、调岗、外勤或休假；新增实习/兼职行政助理；行政人员每日下班前汇报。
  • 典型说法：「没有行政」「等新行政来了再修门」「谁是管书包的」「活人家干了，又不让人家越权」「后续行政每日工作汇报在这个群里发」「日报已经很多天没见了」
  • 判断问题：问题是"这件事该谁管/谁接手"，还是"这件事具体怎么办"？前者走本流程，后者走对应业务 SOP。
  • 不归本流程管：具体的物资申购 → 请走 ADM-14；保洁值日 → 请走 ADM-11；快递代收与物品借用 → 请走 ADM-15；报修 → 请走 ADM-08；人员招聘补岗 → 请走 X-RCT-01（招聘需求提报与 HC 管理）；公司级日报/周报总规则 → 请走 CEO-12（本条为行政线分支）；人员离职手续 → 请走 HR-27（本条只管行政事务交接清单）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 维护归口清单与受理台账，分派助理，审阅日报，组织交接 A 行政负责人（当前：胡则瑾·推断待确认）
行政执行 按归口处理事项、提交日报 R 行政专员/助理（当前：侯明月、丁蕊·推断待确认）
财务线日报 财务出纳类事项日报 R 财务（当前：黄梦婷·推断待确认）
离岗人/接手人 岗位变动时按清单交接与签收 R（交接） 离岗的行政人员及其接手人
人事 与行政划清事务边界、补岗招聘 C 人事负责人（当前：黄莹·推断待确认）
临时协调 行政缺位时临时分派、催办 C CTO（当前：丁震宇·推断待确认）
要求与审阅 定日报规则、审阅跨部门事项 I CEO（当前：邴龙志·推断待确认）
兜底 空缺期指定代理人、裁定边界争议 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 行政事务全量清单：快递、报修、打印、保洁、物品领用、会议室、零食采购、接待、门禁、盖章等
  • 每项事务的现承接人、备岗、受理入口、处理时限
  • 实习/兼职助理在岗日与可处理事项
  • 日报模板、交接清单模板
  • 在办事项、供应商联系人、物品存放位置、未报销票据清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 编制归口清单（事项、主责、备岗、入口、时限），综合部负责人确认后公告 行政负责人 本 SOP 发布后 5 个工作日内 飞书知识库 + 群公告 归口清单 🔧飞书固化
2 设"行政服务申请"表单，按事项类型自动派给归口人 行政负责人 归口清单发布后 3 个工作日内 飞书表单 + 多维表格自动化 受理台账 🔧+🤖
3 公示行政人员与兼职助理在岗时间、可处理事项与需转正式行政的事项 行政负责人 人员到岗当天 群公告 分工公示 🔧飞书固化
4 提交日报：今日完成 / 进行中 / 阻塞 / 明日计划 行政专员/助理、财务 每个工作日 18:30 前 飞书汇报（日报模板） MMDD 日报 🔧飞书固化
5 日报中涉及跨部门的事项同步总经办 行政负责人 日报提交后当天 飞书汇报抄送 同步记录 🔧飞书固化
6 未提交日报自动提醒；连续 2 个工作日未提交提醒行政负责人 机器人 19:00 自动 飞书汇报提醒 提醒记录 🤖自动化
7 岗位变动：离岗人按清单交接（在办事项、供应商、账号权限、物品位置、未报销票据），接手人签收 离岗人、接手人 离岗前 3 个工作日完成 飞书文档 签收交接清单 🔧飞书固化
8 行政空缺或外勤：指定代理人并公告，更新归口清单 综合部负责人 空缺发生后 1 个工作日内 群公告 代理公告 👤人工判断
9 每周汇总未结与超时事项，AI 生成周报 行政负责人 每周五 18:00 前 多维表格 + AI 汇总 行政周报 🤖自动化

5. 交付物与模板

  • 交付物：行政事务归口清单、行政服务受理台账、日报与周报、交接清单与签收记录、代理公告
  • 建议模板/表单：
    • 归口清单：事项、说明、主责岗位、备岗、受理入口、响应时限、完成时限
    • 受理台账：编号、提出人、事项类型、描述、归口人、提交时间、状态、完成时间、超时标记
    • 日报模板：日期｜今日完成（编号列出）｜进行中及预计完成｜阻塞与需协助｜明日计划｜需同步总经办事项
    • 交接清单：在办事项及进度、供应商与物业联系人、系统账号与权限、物品与钥匙位置、未报销票据、待付款项

6. 异常与升级

  • 事项超过 1 个工作日无人承接 → 归口人或代理人认领；仍无人 → 综合部负责人当天指定
  • 行政与人事对某项事务边界有争议 → 综合部负责人 2 个工作日内裁定并更新归口清单
  • 日报连续 3 个工作日未提交 → 行政负责人升级综合部负责人
  • 离岗未完成交接 → 人事暂缓办理离岗手续，行政负责人督促 2 个工作日内补齐
  • 兼职助理不在岗期间的紧急事项 → 转行政负责人或代理人
  • 升级条件：行政岗空缺或外勤需指定代理人、事项超过 1 个工作日无人承接、行政与人事边界有争议、日报连续 3 个工作日未提交时，由综合部负责人拍板（A（升级））；其余由行政负责人统筹

7. 衡量指标

  • 归口覆盖率 = 已明确主责与备岗的行政事项数 / 行政事项总数，目标 100%
  • 行政事项超时率 = 超出完成时限的事项数 / 受理事项总数，目标 ≤10%
  • 日报提交率 = 实交日报数 / 应交日报数，目标 ≥95%
  • 空缺期代理指定时长 = 空缺发生到代理公告的工作日数，目标 ≤1
  • 交接遗留事项数 = 交接后 30 天内发现的未交接事项数，目标 0

8. 低效诊断

  • 现象：行政岗空缺期间快递、修门、打印无人承接，会议室门坏数月未修｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-06
  • 现象：行政工作转由人事兼做，兼职助理在岗时间与权限不明，员工只能拉群、@ 领导催办｜依据：「鼎慧产研决策部」2026-03
  • 现象：日报中断约 10 天无人提醒，靠管理层发现｜依据：「内务大总管（2026版）」2026-04
  • 现象：日报格式不统一，多线事项只在群消息里，缺少看板｜依据：「内务大主管」2026-01

9. 分支变体

  • 正式行政：承担全部归口事项
  • 实习/兼职助理：仅在公示的在岗日处理清单内事项，其余转正式行政
  • 外包保洁：由行政对接，见 ADM-11
  • 日报两条线：行政线与财务出纳线分别提交，模板一致
  • 行政空缺期：由综合部负责人指定代理人，事项不得默认"谁着急谁干"

10. 待确认问题

  • 现任行政负责人按观察填为胡则瑾，是否确认并作为本流程主责？财务线日报是否仍需单独提交？
  • 行政与人事的事务边界如何划分（活动组织、统计、通知等）？
  • 日报改用飞书"汇报"应用，还是继续在内务大总管（2026版）群发？提交时间 18:30 是否可行？
  • 是否开通"行政服务申请"统一表单？
  • 兼职助理可处理哪些事项、哪些必须由正式行政处理？
ADM-14办公物资/家具申购与行政服务需求受理待优化180

状态：待优化｜证据：有证据（卡片 9 张 / 会话 4 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：员工需要桌椅、柜子、打印机、取暖设备、屏风等物资，消耗品（饮用水、纸巾、垃圾袋、洗手液）用完，需要占用场地放置物品，或需要行政配合摆放、清理、布置会场时，统一受理、选型、采购或授权垫付、交付验收并集中收票。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT运维（网络/设备/门锁，当前：杨明学·推断待确认）、总助（场地占用审批，当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、需求方；审批——预算审批人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 需求方提交申请单 → ② 行政受理分类 → ③ 选型比价并请需求方确认 → ④ 按金额阈值审批 → ⑤ 下单或授权垫付 → ⑥ 到货通知、签收、组装 → ⑦ 需求方验收 → ⑧ 订单与发票入表、报销或月度集中结算
  • 交付结果：已验收交付的物资或服务；带订单号、下单人、供应商的需求台账；齐全的发票与报销/结算记录；公示的消耗品存放位置与库存表
  • 状态依据：已有置顶需求 todo 文档、遗留问题多维表格、订单/发票登记表，2026-07 起行政每月统一采购、财务集中收票；但 2026-01～10 仍有约 25 次进度追问、需求遗漏、"谁下的单""垃圾袋在哪"等问题，服务需求需反复催办

1. 场景判定

  • 触发条件：新增工位或物品损耗需要购置；消耗品低于存量或用完；员工想在公共区放置自费物品；活动、拍摄、讲座需要摆放桌椅、清理杂物、布置会场；采购物品需要售后。
  • 典型说法：「采买的东西发群里，没意见就下单」「一键查询桌子购买进度」「那到底换不换桌子，谁来拍板」「没饮用水了」「垃圾袋放在哪里」「你先找总助申请一下用地」「服务需求提了之后还要反复跟进」
  • 判断问题：是不是"买东西、补东西、用场地、请行政动手"？涉及电脑、服务器、网络设备的采购不走本流程。
  • 不归本流程管：电脑、服务器等 IT 设备采购 → 请走 ADM-24；物品损坏报修 → 请走 ADM-08；保洁值日与消杀 → 请走 ADM-11；快递代收与公共物品借用 → 请走 ADM-15；对外寄件 → 请走 ADM-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 受理、分派、跟进全部需求，维护台账与库存表 A 行政负责人（当前：胡则瑾·推断待确认）
采购执行 比价、下单、取件、组装、售后 R 行政专员（当前：侯明月·推断待确认）
需求方 写清需求、确认款式、验收 R 提出部门员工
场地审批 公共区放置物品、用地占用审批 C 总助（当前：赵雪冰·推断待确认）
设备协同 涉及网络、电源、门锁的安装配合 C IT运维（当前：杨明学·推断待确认）
预算审批 超阈值采购与款式争议拍板 A（升级） 预算审批人（当前：丁震宇·推断待确认）
财务 发票收集、报销与月度结算 C 财务负责人（当前：黄梦婷·推断待确认）
兜底 超时与争议升级 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 物品名称、规格、数量、用途、放置位置、期望到货日期
  • 关键参数（如桌子是否折叠、是否带滚轮、尺寸、颜色是否统一）或示意图
  • 参考链接与预算区间
  • 服务需求：时间、地点、布置示意图或照片、验收人
  • 场地占用：位置、尺寸、期限、是否影响通行与其他规划

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交"办公物资/服务申请"，选类型（家具大件/消耗品/服务/场地） 需求方 需要前至少 5 个工作日（服务需求至少 2 个工作日） 飞书表单 → 多维表格 需求单 🔧飞书固化
2 受理并分类，缺信息一次性退回补充；场地类转总助审批 行政负责人 提交后 1 个工作日内 多维表格 受理状态 🔧+👤
3 选型比价（至少 2 家），把候选链接或方案发需求方确认 行政专员 受理后 2 个工作日内 多维表格评论 确认方案 👤人工判断
4 超阈值或款式有争议时提交审批 行政负责人 → 预算审批人 1 个工作日内审批 飞书审批 审批结论 🔧飞书固化
5 下单（大件避免全额预付），回填订单号、下单人、供应商、预计到货日 行政专员 审批后 1 个工作日内 多维表格 订单记录 🔧飞书固化
6 到货后通知需求方，组织取件、组装、摆放 行政专员 到货当天 飞书机器人通知 到货交付 🔧+🤖
7 需求方验收；服务需求行政完成后拍照回传 需求方 交付后 1 个工作日内 多维表格 验收记录 🔧飞书固化
8 发票上传，按月集中交财务；垫付走报销审批 行政专员、财务 到货后 5 个工作日内上传；每月 5 日前集中交票 飞书审批（报销） 发票与结算记录 🔧飞书固化
9 消耗品：维护存放位置与库存，低于阈值自动提醒补货 行政专员 每周一检查 多维表格自动化 库存表、补货单 🔧+🤖
10 每周推送未结需求与超时提醒 机器人 每周一 10:00 多维表格自动化 未结清单 🤖自动化

5. 交付物与模板

  • 交付物：验收完成的物资或服务、需求台账、订单与发票记录、消耗品库存表、存放位置公示
  • 建议模板/表单：
    • 需求单：编号、提出人、部门、类型、物品与规格、关键参数、数量、预算区间、参考链接/示意图、放置位置、期望日期、紧急程度、审批状态、供应商、订单号、下单人、付款方式（统一采购/垫付）、预计/实际到货日、验收人、验收结果、发票状态、报销状态
    • 消耗品库存表：物品、存放位置（如前台柜子、906 仓库）、当前数量、补货阈值、常用供应商、最近补货日期
    • 服务需求附件：布置示意图、完成照片

6. 异常与升级

  • 需求超过期望日期未交付 → 机器人提醒行政负责人 → 超期 3 个工作日升级综合部负责人
  • 选型无人拍板或多方意见不一 → 行政负责人 1 个工作日内提交预算审批人裁定
  • 到货不符或质量问题 → 行政专员凭台账订单号 2 个工作日内发起售后
  • 行政人员外勤或休假 → 按 ADM-13 指定代理人接手未结需求
  • 员工未经申请自行购买 → 可垫付报销，但须 5 个工作日内补登需求单并附发票，逾期财务不予受理（规则待确认）
  • 升级条件：采购金额超过行政审批阈值[阈值待财务确认]，或选型/款式多方意见不一时，由预算审批人拍板（A（升级））；阈值内的常规申购由行政负责人决定

7. 衡量指标

  • 受理时长 = 提交到受理的工作日数，目标 ≤1
  • 交付周期 = 提交到验收的工作日数，目标：消耗品 ≤3，家具大件 ≤10，服务需求按约定日期 100%
  • 催办次数 = 群内追问进度的次数，目标逐月下降至每月 ≤2
  • 一次验收通过率 = 首次验收合格数 / 交付总数，目标 ≥90%
  • 发票齐全率 = 有发票的订单数 / 订单总数，目标 100%
  • 缺货报告次数 = 员工报缺消耗品次数，目标每月 ≤1

8. 低效诊断

  • 现象：采购进度靠群里反复追问，行政人员外勤后需求被遗漏｜依据：「公司建设大改造」2026-03、「公司建设大改造」2026-04
  • 现象：选型拍板人不明确，售后时需翻找是谁下单、订单号在哪｜依据：「忠橙星球建设计划」2026-03
  • 现象：采购靠熟人垫付，预算口径只有"不浪费就行"，没有阈值｜依据：「鼎慧产研决策部」2026-01
  • 现象：服务需求提交后仍需私聊和反复催促；需求未写明关键参数，买成不合适的款式｜依据：「鼎慧产研决策部」2026-05
  • 现象：消耗品存放位置不公示，"纸巾/垃圾袋在哪"反复提问｜依据：「公司建设大改造」2026-08、「公司建设大改造」2026-09
  • 现象：小额垫付靠微信截图报销，事后才想起报｜依据：「鼎慧产研决策部」2026-03
  • 现象：申购入口与行政接口人不明，场地占用不知找谁申请｜依据：「工程咨询产研」2026-04、「鼎慧产研决策部」2026-04

9. 分支变体

  • 家具大件：需示意图与关键参数，先小批量试用再批量；避免全额预付；线下可比价
  • 日常消耗品：库存阈值触发补货，订水单独约定周期
  • 行政每月统一采购：员工在系统提需求，行政每月固定一天统一下单，财务一次收票
  • 员工小额垫付：紧急且小额时允许，补登需求单 + 报销审批
  • 零食饮料：按组统计、每月 1～2 次统一采购，按每人月度额度执行（额度以制度为准）
  • 行政服务需求（摆放、清理、会场布置）：附示意图，完成拍照回传
  • 场地占用（放置自费物品、活动用场）：先经总助审批

10. 待确认问题

  • 采购金额审批阈值是多少？超阈值由谁审批？
  • 统一采购与员工垫付的边界：哪些情况允许垫付？补登时限 5 个工作日是否可行？
  • 现有置顶需求文档、遗留问题多维表格、订单/发票登记表是否合并为一张需求台账？
  • 零食额度、超额顺延规则是否已成文？
  • 场地占用审批人是否为总助？
ADM-15快递代收、公共物品借用与失物招领待新建72

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频4 × 耗2 × 跨3 × 险3

  • 适用场景：快递或供应商送货到公司、需要借用公共物品（U 盘、吸尘器、工具箱、拖车、清洗机、测试机等）、发现遗落物品，或有陌生人员上门推销、找人时，按规则登记、通知、借还、认领与引导。
  • 负责人：主责——行政专员（当前：侯明月·推断待确认）；协同——IT运维（IT 类公共设备，当前：杨明学·推断待确认）、运维/交付工程师（打印机与设备登记，当前：游家豪·推断待确认）、当日前台值守人；兜底——综合部负责人
  • 核心流程：① 建公共物品台账与位置标签 → ② 发布办公指南 → ③ 快递到件登记并通知 → ④ 借用登记与按期归还 → ⑤ 遗落物品登记与限期认领 → ⑥ 陌生来访识别与引导 → ⑦ 月度盘点
  • 交付结果：公共物品台账（含位置与保管人）；办公指南（打印机、会议室、物资位置、门禁获取方式）；快递登记与认领记录；借还记录；失物招领记录
  • 状态依据：2026-01～09 全员群内找物约 12 次（吸尘器、拖车、小圆桌、垃圾袋等），快递与硬件靠路过同事代收、无主包裹被随手挪放，打印机位置靠问，推销人员被引入办公区；无台账、无登记、无前台值守规则

1. 场景判定

  • 触发条件：快递、外卖或供应商货物到达公司；员工找不到或要借用公共物品；在公共区发现无主物品；陌生人到访前台；员工询问打印机、会议室、物资位置。
  • 典型说法：「有人看到吸尘器了吗」「公司拖车在哪」「公司门口那个包裹是什么」「这个是谁的，没人要就放二楼了」「打印机在哪」「推销的能不能赶走」
  • 判断问题：是不是"东西在哪/归谁/怎么借"或"门口来了人/货"的问题？
  • 不归本流程管：物资申购与消耗品补货 → 请走 ADM-14；对外寄件 → 请走 ADM-16；设备损坏 → 请走 ADM-08；下班安全巡检 → 请走 ADM-10；预约的客户/测评人员接待 → 请走 ADM-06（外部来访接待与参观/拍摄报备）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 维护台账与办公指南、快递登记、失物招领、月度盘点 A/R 行政专员（当前：侯明月·推断待确认）
IT 设备保管 U 盘、测试机、屏幕等 IT 类公共设备登记与借还 R IT运维（当前：杨明学·推断待确认）
打印设备 打印机位置、耗材、远程打印协助 R 运维/交付工程师（当前：游家豪·推断待确认）
前台值守 行政不在时代收快递、识别来访 R 当日前台值守人（当前：待指定）
借用人/收件人 登记、按期归还、及时认领 R 全员
兜底 遗失赔付、安全事件裁定 I 综合部负责人

3. 办之前请准备

  • 公共物品清单：名称、编号、存放位置、保管人、是否可外借
  • 位置标签（物品与柜子）
  • 办公指南：打印机位置、会议室、物资柜、门禁获取方式（找行政，不在群里公开密码）
  • 快递登记表、借还表、失物登记表
  • 前台值守排班（行政不在时）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 盘点公共物品，建台账、贴标签，IT 类由 IT 运维登记 行政专员、IT运维 本 SOP 发布后 10 个工作日内 飞书多维表格 物品台账 🔧飞书固化
2 发布办公指南并置顶各办公群 行政专员 台账完成后 2 个工作日内 飞书知识库 + 群置顶 办公指南 🔧飞书固化
3 快递/货物到达：值守人签收，拍照登记收件人、放置位置 行政专员/前台值守人 到达后 30 分钟内 快递登记表 到件记录 🔧飞书固化
4 机器人通知收件人；无收件人信息的发群认领 机器人 登记后自动 飞书机器人 到件通知 🤖自动化
5 借用公共物品：扫码登记借用人、预计归还时间，归还时勾选 借用人 借用当时 二维码 + 多维表格 借还记录 🔧飞书固化
6 逾期未还自动提醒借用人 机器人 到期次日 10:00 多维表格自动化 提醒 🤖自动化
7 公共区无主物品：拍照登记，放失物招领处，发认领通知 行政专员 发现当天 失物登记表 认领通知 🔧飞书固化
8 认领期满（5 个工作日）未认领：贵重物品交综合部负责人保管，其余按公共物品入库或处理 行政专员 期满后 1 个工作日内 失物登记表 处理记录 👤人工判断
9 陌生来访：询问来意与要找的人，联系被访人到前台；无预约推销直接婉拒，不引入办公区 前台值守人 来访当时 访客登记表 访客记录 👤人工判断
10 月度盘点台账，更新位置与状态，缺失项发起找寻 行政专员 每月最后 1 个工作日 多维表格 盘点记录 🔧飞书固化

5. 交付物与模板

  • 交付物：公共物品台账、办公指南、快递登记与认领记录、借还记录、失物招领记录、访客记录、月度盘点记录
  • 建议模板/表单：
    • 公共物品台账：编号、名称、类别（工具/清洁/IT/家具）、存放位置、保管人、可否外借、状态、照片
    • 快递登记表：到达时间、快递单号后 4 位、收件人、物品类型、放置位置、照片、通知时间、领取时间
    • 借还表：物品编号、借用人、借用时间、预计归还、实际归还、状态
    • 访客登记：时间、来访人单位、事由、被访人、是否进入办公区、离开时间

6. 异常与升级

  • 快递超过 2 个工作日无人认领 → 行政专员联系寄件方或在全员群最后一次认领 → 5 个工作日后按无主物品处理
  • 公共物品逾期 3 个工作日未归还 → 提醒借用人及其组长 → 遗失按综合部负责人裁定处理
  • 盘点发现 IT 设备缺失 → 当天通知 IT运维核查（涉及数据的设备视为安全事件）
  • 来访人强行进入或可疑拍摄 → 值守人通知行政与综合部负责人，必要时联系物业保安（立即）
  • 前台无人值守 → 由在场最近工位员工代为接待并通知行政

7. 衡量指标

  • 群内找物次数 = 全员/办公群中"有人看到 XX 吗"类消息数，目标每月 ≤2
  • 快递当日通知率 = 到件当天通知收件人的件数 / 到件总数，目标 ≥95%
  • 公共物品台账准确率 = 盘点账实相符项 / 台账总项，目标 ≥95%
  • 借用按期归还率 = 按期归还次数 / 借用次数，目标 ≥90%
  • 无预约人员进入办公区次数，目标 0

8. 低效诊断

  • 现象：吸尘器、拖车、小圆桌、垃圾袋等公共物品去向靠全员群广播寻找｜依据：「模态集团（全员群）」2026-03、「模态集团（全员群）」2026-05
  • 现象：遗落物品只做一次性限时认领通知，无登记与后续处理｜依据：「模态集团（全员群）」2026-01
  • 现象：快递和供应商硬件由路过同事代收，无主包裹被随手挪到其他楼层｜依据：「鸽子群模态分群」2026-05、「鸽子群模态分群」2026-06
  • 现象：前台无人值守，推销人员被引入办公区，接待责任不清｜依据：「鸽子群模态分群」2026-06
  • 现象：U 盘、清洗机、测试机在谁手里靠记忆；打印机位置与负责人靠群里问｜依据：「鸽子群模态分群」2026-02、「跃迁AI总动员」2026-09

9. 分支变体

  • 快递代收：个人快递与公司货物分开登记；供应商硬件需通知 IT 运维验收
  • 公共物品借还：工具/清洁类由行政保管；IT 类由 IT 运维保管
  • 失物招领：贵重物品与普通物品分开处理
  • 位置指引：905、906、10 楼分别列出打印机、会议室、物资柜位置
  • 陌生来访：推销婉拒；找财务等具体人员先联系被访人确认

10. 待确认问题

  • 主责是否为行政专员？行政不在时前台值守由谁轮值？
  • 公共物品台账是否与 IT 资产台账合并，还是分开维护？
  • 认领期 5 个工作日、到期后的处理方式是否可行？
  • 是否在门口启用飞书访客登记二维码？
  • 门禁密码的发放与更换由谁负责？
ADM-16对外寄件与快递月结待优化90

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨5 × 险3

  • 适用场景：向客户或供应商寄送交付机器、签收单、合同材料，或设备寄修时，统一登记收件信息、使用公司快递月结账户发货、回填单号并同步相关人员，月底对账。
  • 负责人：主责——行政负责人（月结账户与寄件规则，当前：胡则瑾·推断待确认）；协同——IT运维/寄件执行（当前：杨明学·推断待确认）、交付统筹（收件信息确认，当前：杨萌·推断待确认）、总经办（当前：田杰·推断待确认）、财务负责人（月结对账，当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 寄件人提交寄件登记 → ② 交付统筹确认收件信息 → ③ 打包与保价判断 → ④ 用公司月结账户下单 → ⑤ 回填单号并同步需求群 → ⑥ 跟踪签收 → ⑦ 月度对账
  • 交付结果：寄件登记台账（含收件信息、物品、单号、签收状态）；按时签收的寄件；月结账单与台账核对记录
  • 状态依据：已有寄件做法和快递单号记录，但 2026-08 寄件人以为月结未开通重新提需求，才发现账户早已开通但无人同步；收件信息和发货时间在群里反复索要与追问

1. 场景判定

  • 触发条件：交付机器、配件、签收单、纸质材料需要寄出；设备需寄回厂家或供应商维修；客户退回设备需安排上门取件。
  • 典型说法：「我们什么时候开通一下快递月结」「原来已经开了，没人同步」「收件人信息发一下」「这个啥时候发」
  • 判断问题：是否需要从公司寄出物品，且费用应由公司承担？
  • 不归本流程管：快递到公司的签收与认领 → 请走 ADM-15；硬件交付的装机、验收本身 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）；采购物品到货 → 请走 ADM-14；个人私人寄件 → 自理

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主责 管理月结账户与下单权限、公布寄件规则、维护台账 A 行政负责人（当前：胡则瑾·推断待确认）
寄件需求人 提交寄件登记（用途、物品、收件信息、期望到达日期） R（提需求） 项目/交付/研发等寄件需求人
寄件执行 打包、下单、回填单号、跟踪签收 R IT运维/寄件执行（当前：杨明学·推断待确认）
收件信息确认 提供并确认收件人、地址、电话、期望到达时间 R 交付统筹（当前：杨萌·推断待确认）
账户开通 月结账户开通与变更 C 总经办（当前：田杰·推断待确认）
财务 月结账单核对与付款 C 财务负责人（当前：黄梦婷·推断待确认）
需求群成员 获知单号与签收状态 I 项目相关人员

3. 办之前请准备

  • 收件信息：收件单位（可用客户代称登记）、收件人、电话、地址、期望到达日期
  • 物品清单：名称、数量、序列号（设备类）、是否需保价及保价金额依据
  • 寄件用途：交付 / 寄修 / 材料
  • 月结账户信息与下单方式（由行政公布，不在群里发账号密码）
  • 包装材料

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 公布月结账户的使用方式、下单权限人与寄件规则，账户变更时同步更新 行政负责人 本 SOP 发布后 3 个工作日内；变更后 1 个工作日内 飞书知识库 + 群公告 寄件规则 🔧飞书固化
2 提交寄件登记：用途、物品、收件信息、期望到达日期 寄件需求人 期望寄出前 1 个工作日 飞书表单 → 多维表格 寄件登记 🔧飞书固化
3 确认收件信息无误；同一客户信息复用台账，不再重复索要 交付统筹 登记后 4 个工作小时内 多维表格 已确认收件信息 🔧+🤖
4 打包；设备类判断是否保价、附签收单 寄件执行人 确认后当天 — 包裹 👤人工判断
5 用公司月结账户下单，回填单号 寄件执行人 确认后 1 个工作日内寄出 快递月结系统 + 多维表格 运单号 🔧飞书固化
6 机器人把单号推送到需求群 机器人 回填后自动 飞书机器人 单号通知 🤖自动化
7 跟踪物流，签收后更新状态；交付类提醒收回签收单 寄件执行人 预计到达日当天核对 多维表格 签收记录 🔧+🤖
8 月结账单与寄件台账逐单核对，交财务付款 行政负责人、财务 每月 10 日前 月结账单 + 多维表格 对账记录 🔧+🤖

5. 交付物与模板

  • 交付物：寄件台账、单号通知、签收记录、月度对账记录、公开的寄件规则
  • 建议模板/表单：
    • 寄件登记表：编号、需求人、用途（交付/寄修/材料）、项目或客户代称、物品与序列号、数量、是否保价、收件人、电话、地址、期望到达日期、寄件人、寄出日期、快递公司、运单号、签收日期、签收单是否收回、费用
    • 收件信息库：客户代称、收件人、电话、地址、最近使用日期（权限限项目相关人可见）

6. 异常与升级

  • 寄件人不知道月结是否可用 → 查寄件规则，仍不清楚问行政负责人（1 个工作小时内答复）
  • 物流超过预计到达 2 天未签收 → 寄件执行人联系快递查询，同步需求群；影响交付时同步交付负责人
  • 包裹丢失或损坏 → 当天发起快递理赔，行政负责人跟进，设备类同步 IT运维与财务
  • 月结账单与台账不符 → 财务列差异，行政负责人 3 个工作日内核清
  • 收件信息错误导致退回 → 交付统筹 1 个工作日内更正后重寄

7. 衡量指标

  • 寄出时效 = 收件信息确认到寄出的工作日数，目标 ≤1
  • 单号回填率 = 已回填单号的寄件 / 寄件总数，目标 100%
  • 收件信息重复索要次数，目标 0
  • 月结使用率 = 走月结的公司寄件 / 公司寄件总数，目标 100%
  • 对账差异单数，目标每月 0

8. 低效诊断

  • 现象：月结账户已开通但未同步，寄件人重新提开通需求｜依据：「Leapcore 客户项目群（客户A）」2026-08
  • 现象：收件信息在群里反复索要，发货时间被反复追问，单号只在群消息中｜依据：「Leapcore 客户项目群（客户A）」2026-08

9. 分支变体

  • 交付寄送：附签收单，签收后收回归档
  • 寄修：登记故障描述与序列号，跟踪返回；返回件按 ADM-15 签收
  • 寄材料（合同、发票）：同步财务或法务
  • 多主体（模态、鼎慧、跃竞等）：是否共用一个月结账户、如何分摊费用待确认

10. 待确认问题

  • 月结账户归属哪个主体？由谁管理、谁有下单权限？
  • 寄件主责放在行政还是交付/IT？
  • 设备类寄件的保价规则是什么？
  • 收件信息库放在哪里、谁可查看？
  • 各主体寄件费用如何分摊与对账？
ADM-17零食福利月度采购与额度/报销管理待优化108

状态：待优化｜证据：有证据（卡片 14 张 / 会话 12 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：每月员工零食饮料福利，从系统开放选购（或部门自行收集需求）到截单、统一采购、到货分发、发票核对与报销结算的全过程
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——总经办通知专员（当前：王欣·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、零食系统维护人（当前：丁震宇·推断待确认）、各部门零食汇总人（当前：杨萌、陈梦琪、杨明学、游家豪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 生成当月名单与额度 → ② 开放选购并通知 → ③ 截止前催确认 → ④ 锁单汇总 → ⑤ 统一下单 → ⑥ 到货分发 → ⑦ 收票报销 → ⑧ 月度复盘
  • 交付结果：当月采购汇总单、到货分发记录、按部门/月份归档的“发票+付款凭证”报销包、更新后的需求与 BUG 看板
  • 状态依据：7 月已发布部门零食福利报销规范，8 月零食采购系统上线并配有操作指引和 BUG 收集表；但 8～10 月仍反复出现额度是否计税无定论、开放期/截单日与采购节奏不一致、人员同步需手工增删、未选购人员需群内催办、订单拆单不发货等问题

1. 场景判定

  • 触发条件：每月系统开放日到达；部门或小组需要采购零食饮料；员工对额度、商品、到货、发票有疑问；节前需要集中下单
  • 典型说法：「完成选购后必须最终确认，不参加也要确认」「我们零食采购了吗」「额度选不了几个就没了」「零食报销找谁」「每月 25 日统一受理当月零食费用报销」
  • 判断问题：是否属于按人头额度、使用公司福利预算的月度零食/饮料采购？如果是个人自费或一次性节日福利，则不走本流程
  • 不归本流程管：节日礼盒、全员周边、福利图书 → 请走 ADM-18；团建聚餐餐费 → 请走 ADM-20；快递代取 → 请走 ADM-15；电脑、外设等 IT 设备 → 请走 ADM-24；个人自费零食 → 不报销

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规则制定人 制定额度标准、适用人员范围、报销周期；对规则负最终责任 A 综合部负责人（当前：赵雪冰·推断待确认）
流程运营人 维护商品池、审核员工推荐商品、锁单、统一下单、到货分发、整理报销包 R 行政负责人（当前：胡则瑾·推断待确认）
通知发布人 发布开放、截止、到货通知 R 总经办通知专员（当前：王欣·推断待确认）
财务核对人 核对发票与订单、付款、归档；给出额度计税口径 R/C 财务负责人（当前：黄梦婷·推断待确认）；财务专员（当前：刘梦可·推断待确认）
系统维护人 系统迭代、人员同步、BUG 修复 R 零食系统维护人（当前：丁震宇·推断待确认）
部门汇总人 部门自采模式下收集需求、下单、收集凭证并统一提交报销 R 各部门零食汇总人（当前：杨萌、陈梦琪、杨明学、游家豪·推断待确认）
人事 提供在册人员名单与入离职变动，参与福利计税口径 C 人事负责人（当前：黄莹·推断待确认）
员工 在开放期内选购并最终确认，或确认不参加 I 全体员工

3. 办之前请准备

  • 当月在册人员名单（以每月 5 日飞书通讯录为准，标出新入职、离职、兼职/实习、外部合作公司人员）
  • 当月额度标准与总预算（以综合部当期通知为准）
  • 商品池：仅限京东自营、可食用、可开发票的商品；线下集采通道的预留额度
  • 收货点清单（各办公地点地址与收货人岗位）
  • 系统操作指引、需求与 BUG 收集看板链接
  • 上月未结订单、未到货商品、未收发票清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 同步飞书通讯录生成当月名单与额度，人工核对入离职差异 系统维护人、流程运营人 每月 5 日前 零食采购系统、飞书通讯录 当月名单 🤖自动化
2 开放选购，发布通知（开放期、截止时间、收货点、指引链接） 通知发布人 开放当日 10:00 前 飞书群公告/机器人 开放通知 🔧飞书固化
3 员工选购并最终确认；推荐商品由流程运营人审核入池 员工；流程运营人 开放期内（建议 3 个工作日）；推荐商品 1 个工作日内审核 零食采购系统 个人确认单 👤人工判断
4 截止前提醒未确认人员 机器人 截止前 1 个工作日 飞书机器人 提醒记录 🔧+🤖
5 截单锁单，系统按“部门—收货点—渠道”生成汇总 流程运营人 截止日当天 零食采购系统 采购汇总单 🤖自动化
6 统一下单：京东自营用企业采购账号合单下单；线下集采按预留额度下单；均要求开票 流程运营人 锁单后 2 个工作日内 京东企业采购 订单 👤人工判断
7 到货核对数量，按收货点分发并通知领取；缺货、拆单登记 流程运营人 到货当日 群通知、零食采购系统 分发记录 👤人工判断
8 汇总发票、付款凭证、订单明细形成报销包提交（部门自采模式由部门汇总人提交） 流程运营人/部门汇总人 每月 25 日前（节假日顺延，逾期顺延次月） 飞书报销审批 报销单 🔧飞书固化
9 核对发票与订单、付款、归档 财务核对人 受理后 5 个工作日内 飞书审批、财务系统 凭证归档 👤人工判断
10 月度复盘：未确认率、超额、发票缺失、需求与 BUG 入看板排期 流程运营人 次月 5 日前 多维表格看板 复盘记录 🔧飞书固化

5. 交付物与模板

  • 交付物：当月名单、采购汇总单、订单与发票、分发记录、报销包、需求与 BUG 看板
  • 建议模板/表单：
    • 采购汇总单：月份、部门、收货点、商品、数量、单价、金额、渠道、订单号、发票号、到货状态、分发状态
    • 部门自采报销单：部门、月初在册人数、月份、金额、发票、付款截图、汇总人岗位
    • 需求与 BUG 看板：提出人岗位、类型（需求/BUG）、描述、截图、优先级、状态、处理人、完成日期

6. 异常与升级

  • 员工截止前未确认 → 视为本月不参加，剩余额度不结转 → 不升级
  • 新入职或离职人员系统未识别 → 流程运营人手工调整并在看板记录 → 系统维护人（2 个工作日内修复同步）
  • 系统 BUG（日期不更新、周期无法关闭、后台功能消失）→ 提交看板 → 系统维护人（1 个工作日内响应）
  • 订单拆单或缺货 3 天未发货 → 流程运营人改单或替换商品并通知 → 行政负责人
  • 商品非京东自营或无法开票 → 不允许入池 → 不升级
  • 额度计税、额度转移、共享等口径疑问 → 财务与人事出书面口径 → 综合部负责人（下一个月度周期开始前）
  • 报销材料缺发票或付款截图 → 退回补齐 → 逾期顺延次月

7. 衡量指标

  • 按时确认率 = 截止前完成确认（含确认不参加）人数 / 当月在册人数，目标 ≥ 95%
  • 下单及时性 = 锁单到下单的工作日数，目标 ≤ 2 个工作日
  • 到货分发周期 = 下单到全部分发的自然日，目标 ≤ 7 天
  • 发票齐全率 = 有合规发票的订单金额 / 当月采购总金额，目标 100%
  • 报销一次通过率 = 一次通过的报销单 / 提交报销单，目标 ≥ 95%
  • 群内人工催办次数：每月 ≤ 1 次

8. 低效诊断

  • 现象：需求收集载体反复切换（采购表、问卷、表单、群内口述），链接需重发，未填者口述补录，下单前还要再问一轮｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03、「工程咨询产研」2026-01
  • 现象：各组每月新建表单、格式不一；兼职、外部合作公司同事、线上办公人员是否享受额度需逐个询问｜依据：「行政统筹协作群」2026-01、「跃迁基座」2026-03
  • 现象：采购长期由业务人员兼任，采购日被遗忘，“谁负责买”反复追问，产研自行比价找集采商｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-04、「随便瞎聊啦～」2026-05
  • 现象：部门报销批次分散、周期不统一、材料不规范，费用归属月份口径不一｜依据：「【模态】综合部」2026-07、「【模态】业务负责人」2026-07、「鼎慧产研决策部」2026-02
  • 现象：系统上线后规则仍未定：额度是否计税、个人额度能否转移或合并、按人还是按办公室汇总｜依据：「公司建设大改造」2026-08、「模态跃迁通知群」2026-08
  • 现象：履约环节返工：商品类别错选需下架重提，订单等全部到货才发，分开发货有运费且开票麻烦｜依据：「模态跃迁通知群」2026-08、「公司建设大改造」2026-09

9. 分支变体

  • 系统集中采购（默认）vs 部门自主采购后月度统一报销（部门指定一人收集凭证，每月 25 日统一受理，按月初在册人数核算）
  • 线上京东自营 vs 线下集采通道（行政统一选品，走预留额度）
  • 多收货点：总部各楼层与模态空间等不同办公地点分别汇总
  • 跨部门联合采购、同部门合并额度
  • 7 月新旧规则衔接期：扣减重复报销
  • 跃竞人员按部门纳入；节前可增加一次集中下单

10. 待确认问题

  • 当前执行口径是系统集采为主，还是“系统集采 + 部门自采报销”并存？部门自采是否已停止？
  • 开放期以哪个为准：操作指引写每月 10 日启动，通知写 5 日开启、25 日结束，另有“每月只开放 3 天”的提议？采购日是 15/25 日还是 15/26 日？
  • 额度是否需要代扣个税？由财务给出书面结论的时限？
  • 个人额度是否允许转移、按部门或办公室共享？
  • 兼职、实习、外部合作公司人员、远程办公人员是否享受额度？
  • 系统后续维护人是否已移交？BUG 响应 1 个工作日是否可行？
  • 财务受理后 5 个工作日内完成付款是否可行？
ADM-18节日福利与员工福利物资发放待优化36

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨3 × 险2

  • 适用场景：节日或公司决定向员工统一发放福利物资（节日礼盒、福利图书、定制周边等），从立项、意向收集/投票、采购或定制，到发放签收
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（当前：侯明月·推断待确认）、IT 运维（周边打样与供应商对接）（当前：杨明学·推断待确认）、福利发起与定调人（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项定预算与截止 → ② 出方案/打样 → ③ 意向收集或投票（设默认方案）→ ④ 汇总下单 → ⑤ 到货验收 → ⑥ 发放签收 → ⑦ 报销归档
  • 交付结果：福利方案（含预算上限、默认方案、截止时间）、选择/投票结果、采购订单与发票、发放签收表
  • 状态依据：中秋礼盒已用“选择文档 + 截止时间 + 逾期默认方案一”，福利图书节点清晰；但全员定制周边无固定流程，打样两轮、选款争议持续约一个月，发放靠人工分货、补领拖到数月后

1. 场景判定

  • 触发条件：中秋、春节等节日福利；公司决定为某类员工统一赠送物品（如研发图书）；定制全员周边
  • 典型说法：「逾期未回复的同事，将默认按方案一购买」「意见反馈截止 15 号，16 号安排采购」「IT 和行政定基调，大家投票选最终方案」「来前台领取礼盒」
  • 判断问题：是否是面向全员或某类员工、一次性统一发放的福利物资？如果是每月按额度的零食，或对外赠送的礼品，则不走本流程
  • 不归本流程管：月度零食福利 → 请走 ADM-17；活动工服、对外伴手礼、合作伙伴赠礼 → 请走 ADM-19；生日会礼品 → 请走 ADM-20；IT 设备 → 请走 ADM-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
预算批准人 批准福利类型与预算上限 A 综合部负责人（当前：赵雪冰·推断待确认）
流程牵头人 立项、出方案、发起意向收集、采购、发放 R 行政负责人（当前：胡则瑾·推断待确认）
采购执行 下单、对接供应商、领取通知 R 行政专员（当前：侯明月·推断待确认）
打样与选款 定制类周边找供应商打样、组织投票 R IT 运维（当前：杨明学·推断待确认）
定调人 定福利原则、书单等内容基调 C 福利发起与定调人（当前：丁震宇·推断待确认）
财务 付款、发票核对 C 财务专员（当前：刘梦可·推断待确认）
员工 填写意向、投票、签收 I 全体员工

3. 办之前请准备

  • 福利类型、发放对象范围（全员/研发/在职满 N 天等）与人数
  • 预算上限（人均与总额），提前公布
  • 2～3 个备选方案（图片、规格、价格、供应商工期），定制类需实物样品
  • 意向收集方式与截止时间、逾期默认方案
  • 发放地点、出差/异地人员的寄送方案

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：确定对象、预算上限、发放日期，报批 流程牵头人 发放日前 15 个工作日 飞书审批 福利立项单 🔧飞书固化
2 出备选方案；定制类找供应商打样，检查水印、尺寸、工艺 流程牵头人/打样与选款 立项后 5 个工作日内 多维表格 方案对比表 👤人工判断
3 发布选择文档或投票，写明截止时间和逾期默认方案、平票规则 流程牵头人 方案确定当日 飞书文档/投票 意向收集 🔧飞书固化
4 截止前提醒未回复人员 机器人 截止前 1 个工作日 飞书机器人 提醒记录 🤖自动化
5 截止后汇总，未回复按默认方案计入，出采购清单 流程牵头人 截止后 1 个工作日内 多维表格 采购清单 🤖自动化
6 下单（要求开票），跟踪物流 采购执行 汇总后 1 个工作日内 京东企业采购/供应商 订单 👤人工判断
7 到货验收数量和质量，按人分装 采购执行 到货当日 — 验收记录 👤人工判断
8 通知领取，现场签收；出差/异地人员寄送或代领登记 采购执行 到货后 3 个工作日内发完 签收表单 签收表 🔧飞书固化
9 提交报销并归档方案、投票结果、签收表 流程牵头人 发放完成后 5 个工作日内 飞书报销审批 报销归档 🔧飞书固化

5. 交付物与模板

  • 交付物：福利立项单、方案对比表、意向/投票结果、采购清单与发票、签收表
  • 建议模板/表单：
    • 福利立项单：福利名称、对象范围、人数、人均预算、总预算、发放日期、截止时间、默认方案
    • 意向收集表：姓名、部门、所选方案、收货方式（现场/寄送）、地址（仅寄送）
    • 签收表：姓名、部门、物品、领取时间、签收方式（本人/代领）、代领人

6. 异常与升级

  • 样品不满意或有瑕疵（水印等）→ 换供应商重新打样，同步顺延截止 → 预算批准人（1 个工作日内决定是否延期）
  • 投票平票 → 按事先公布的平票规则（默认方案）处理 → 不升级
  • 超预算 → 降规格或减少款式 → 预算批准人（1 个工作日内）
  • 到货短缺或损坏 → 联系供应商补发，先发已到部分 → 行政负责人
  • 员工出差、离职 → 寄送或登记延后领取；离职人员按立项范围处理 → 行政负责人

7. 衡量指标

  • 意向回收率 = 截止前回复人数 / 应发人数，目标 ≥ 90%
  • 按期发放率 = 在计划发放日前完成发放的人数 / 应发人数，目标 ≥ 95%
  • 签收完整率 = 有签收记录人数 / 实发人数，目标 100%
  • 预算偏差 = |实际 − 预算| / 预算，目标 ≤ 10%

8. 低效诊断

  • 现象：定制周边无立项与预算上限，样品两轮打样、首版有水印，选款标准众口难调，讨论持续约一个月｜依据：「模态集团（全员群）」2026-01
  • 现象：没有留出调整时间，事后才提出“下次提前说”；补领拖到数月后仍在群里找｜依据：「模态集团（全员群）」2026-01、「模态集团（全员群）」2026-05
  • 现象：礼盒到货后人工分货，出差人员单独沟通，收货地址配置不全｜依据：「公司全员群」2026-09
  • 正向做法：福利图书“书单发布 → 征集意见 → 截止 → 采购 → 发放 → 重复替换”节点清晰，可作为模板｜依据：「技术部」2026-01

9. 分支变体

  • 节日礼盒：二选一选择文档，逾期默认方案一，前台统一领取
  • 福利图书：定调人先出书单，征集意见后定稿，采购后重复的书替换
  • 全员定制周边：IT 与行政定基调 → 打样 → 投票取前 N 款 → 批量定制；团队个性化版本需员工自费加价

10. 待确认问题

  • 节日福利预算由谁批准？人均标准是否有成文制度？
  • 福利物资采购主责是行政还是 IT（定制周边）？是否统一归行政？
  • 发放日前 15 个工作日立项是否可行？
  • 发放对象范围（实习、兼职、外部合作公司人员、试用期）如何界定？
  • 是否需要飞书“福利采购”审批模板？
ADM-19活动定制物料与对外礼品（工服、伴手礼、品牌周边赠送登记）待新建72

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：大会、董事会等活动需要统一工服，或对外需要伴手礼、宣传册、品牌周边，以及样品借用和向合作伙伴赠送物品
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——市场/品牌需求方（当前：许君·推断待确认）、设计（当前：康紫馨·推断待确认）、行政专员（尺码统计、出入库登记）（当前：侯明月·推断待确认）、活动现场发放（当前：林子淇、康紫馨·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 需求提报 → ② 倒排排期 → ③ 询价并确认工期 → ④ 设计与文案定稿 → ⑤ 款式/尺码统计 → ⑥ 下单 → ⑦ 到货验收入库 → ⑧ 发放/赠送出库登记
  • 交付结果：物料排期表、供应商工期确认单、定稿设计文件、到货验收记录、出入库（发放/赠送/借用）登记台账
  • 状态依据：伴手礼临近活动才下定、工期口径前后不一；工服在活动前几天才决定，当天多次催投票、尺码偏小需撤回；品牌周边赠送和样品借用无任何登记，事后对不上去向

1. 场景判定

  • 触发条件：活动/大会/董事会需要工作人员统一着装；对外活动、客户拜访需要伴手礼、宣传册；向合作伙伴赠送品牌周边；借用样品
  • 典型说法：「20 号不下定就赶不上月底活动了」「之前说的是 10 天工期」「工作服和尺码赶紧选一下，七点半下定」
  • 判断问题：物料是否用于活动或对外场景，并需要定制、排期或登记去向？如果是发给员工本人的福利，则不走本流程
  • 不归本流程管：员工节日福利、全员周边 → 请走 ADM-18；团建与活动本身的组织 → 请走 ADM-20；年会整体筹办 → 请走 ADM-21；品牌视觉与文案创作本身 → 由品牌/市场部门负责

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
物料牵头人 建排期表、找供应商、询价、确认工期、下单、验收 R 行政负责人（当前：胡则瑾·推断待确认）
需求方 提出用途、数量、到货日期、文案 R 市场/品牌需求方（当前：许君·推断待确认）
设计 出设计稿、确认打样效果 R 设计（当前：康紫馨·推断待确认）
统计与登记 工服款式尺码统计、物料出入库与赠送登记 R 行政专员（当前：侯明月·推断待确认）
现场发放 活动现场发放工服、工作牌、物料 R 活动现场发放（当前：林子淇、康紫馨·推断待确认）
预算审批 批准物料预算、对外赠送 A 综合部负责人（当前：赵雪冰·推断待确认）
财务 定金与尾款付款、发票 C 财务专员（当前：刘梦可·推断待确认）

3. 办之前请准备

  • 活动名称、日期、地点，物料必须到位的日期
  • 物料清单：品类、数量、规格、用途（内部着装/对外赠送）
  • 预算上限与承担部门
  • 文案与品牌素材（Logo、标语、包装文字）
  • 人员尺码（从尺码档案调取，没有则当天收集）
  • 对外赠送：受赠方类型、赠送事由、审批人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提报物料需求（用途、数量、到位日期、预算） 需求方 活动前不少于 20 个工作日；工服不少于 10 个工作日 多维表格表单 需求单 🔧飞书固化
2 按“到位日 − 物流 − 生产工期 − 设计确认”倒排节点，写入排期表 物料牵头人 收到需求后 1 个工作日内 多维表格 排期表 🔧+🤖
3 询价不少于 2 家，书面确认工期与报价（含加急费） 物料牵头人 2 个工作日内 供应商确认单 工期确认单 👤人工判断
4 出设计稿/文案定稿；需实物时先取样 设计、需求方 按排期表节点 Figma/飞书文档 定稿文件 👤人工判断
5 工服：发布款式与尺码收集，优先调用尺码档案；各尺码多备 统计与登记 收集期 1 个工作日 多维表格表单 尺码汇总 🔧飞书固化
6 预算审批后下单付定金 物料牵头人、财务 定稿后 1 个工作日内 飞书审批 订单 🔧飞书固化
7 到货验收（数量、印刷、尺码）并入库登记 统计与登记 到货当日 出入库台账 验收记录 👤人工判断
8 活动现场发放；对外赠送、样品借用逐笔出库登记 现场发放、统计与登记 发放/赠送当日 出入库台账 出库记录 🔧飞书固化
9 活动后盘点余量与借出未还，更新尺码档案 统计与登记 活动后 3 个工作日内 出入库台账 盘点结果 👤人工判断

5. 交付物与模板

  • 交付物：需求单、排期表、工期确认单、定稿文件、尺码汇总、验收记录、出入库台账
  • 建议模板/表单：
    • 物料排期表：物料名称、需求方岗位、数量、预算、需求到位日、设计定稿日、下单日、供应商工期、预计到货日、实际到货日、状态
    • 出入库台账：物品、规格、数量、类型（入库/发放/赠送/借出/归还）、领用或受赠方、事由、审批人岗位、经办人、日期、归还期限
    • 尺码档案：姓名、上装尺码、下装尺码、更新日期

6. 异常与升级

  • 供应商工期赶不上到位日 → 换供应商或改用现货款 → 需求方与预算审批人（当日）
  • 设计依赖实物样品导致延误 → 先按规格出初稿，样品到后微调 → 物料牵头人
  • 尺码不合适 → 用备用尺码调换，必要时补单 → 物料牵头人（活动前 2 个工作日内）
  • 对外赠送未经审批 → 先登记再补审批 → 综合部负责人（1 个工作日内）
  • 借出物品到期未还 → 提醒借用人，超 5 个工作日未还 → 综合部负责人

7. 衡量指标

  • 按期到位率 = 在需求到位日前到货的物料批次 / 总批次，目标 100%
  • 提前量 = 需求提报日到到位日的工作日数，目标伴手礼 ≥ 20、工服 ≥ 10
  • 尺码返工率 = 需调换件数 / 发放件数，目标 ≤ 5%
  • 出入库登记完整率 = 有登记的发放/赠送/借出笔数 / 实际笔数，目标 100%

8. 低效诊断

  • 现象：伴手礼没有倒排排期，临近活动才下定；供应商工期口径前后不一；设计等实物样品才能出稿，进度不透明｜依据：「模态跃迁 伴手礼群」2026-10
  • 现象：活动前几天才决定做工服，当天多次催投票；尺码依据旧数据偏小需撤回；活动后又临时征集一次｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：品牌周边、样品的对外赠送与借用没有出入库登记载体，事后无法核对去向｜依据：（推断）

9. 分支变体

  • 大会工服：投票选款 + 尺码统计 + 现场随工作牌发放
  • 董事会等小范围工服：按名单定向统计
  • 对外伴手礼：礼盒/铁盒包装 + 宣传册，需市场文案与设计稿
  • 合作伙伴赠礼与样品借用：仅做审批与出入库登记，与品牌/市场部门协同

10. 待确认问题

  • 活动物料主责是行政还是市场/品牌？伴手礼预算归哪个部门？
  • 伴手礼 20 个工作日、工服 10 个工作日的最低提前量是否可行？
  • 对外赠送是否需要审批？审批人是谁，是否设金额门槛？
  • 是否建立全员尺码档案（随入职收集）？
  • 样品、周边库存由谁保管、放在哪里？
ADM-20团建、聚餐与全员活动组织待优化108

状态：待优化｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：组织月度生日会、季度/破冰团建、周年庆、程序员节、年终聚餐、团队聚餐、培训日用餐等内部活动，从方案预算到通知报名、保险交通、订位执行和报销
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——行政专员（通知与执行）（当前：侯明月·推断待确认）、行政助理（策划与保险）（当前：丁蕊·推断待确认）、人事负责人（人员名单）（当前：黄莹·推断待确认）、CEO（方案与预算拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项（目的、时间、预算）→ ② 方案与比价 → ③ CEO 审批 → ④ 通知与表单报名 → ⑤ 保险、交通、订位 → ⑥ 现场签到执行 → ⑦ 报销与复盘
  • 交付结果：活动方案（含预算）、报名名单、保险名单、供应商合同/订单、签到表、发票报销单、复盘记录
  • 状态依据：已有团建方案/流程 wiki、通知模板，9 月成文生日会制度；但报名仍靠群消息“+1/-1”统计，家属证件信息私下收集，预算超出后才压缩，生日会发放形式因无发票被临时改，聚餐计划多次变更

1. 场景判定

  • 触发条件：每月生日会；CEO/部门提出团建或破冰（如新人较多时）；周年庆、程序员节等节点；年终或团队聚餐；培训日需统一订餐
  • 典型说法：「生日会人员不要遗漏不要重复」「带家属的回复 +1」「在哪里报名」「团建记得通知啊」「吃的有点超了」
  • 判断问题：是否为公司或部门出资、需要统计人数并组织执行的内部活动？
  • 不归本流程管：全员年会 → 请走 ADM-21；活动工服、伴手礼 → 请走 ADM-19；节日福利物资 → 请走 ADM-18；对外大会/生态活动 → 由生态市场条线负责

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动牵头人 立项、方案、预算、供应商、执行、报销 R 行政负责人（当前：胡则瑾·推断待确认）
通知与执行 发通知、报名统计、订大巴、现场签到 R 行政专员（当前：侯明月·推断待确认）
策划与保险 外包方案比价、保险投保 R 行政助理（当前：丁蕊·推断待确认）
名单提供 提供在职、寿星、新人名单，核对不漏不重 C 人事负责人（当前：黄莹·推断待确认）
审批人 拍板方案、时间、预算、家属规则 A CEO（当前：邴龙志·推断待确认）
把关人 审核方案与人员名单，统筹周年庆等大型环节 C 综合部负责人（当前：赵雪冰·推断待确认）
财务 备用金、付款、发票核对 C 财务专员（当前：刘梦可·推断待确认）
员工 报名、签到、签收 I 全体员工

3. 办之前请准备

  • 活动目的、日期（工作日/周末）、时长、地点范围
  • 人员名单（人事提供，标出新人、寿星、出差人员）
  • 预算上限与餐标（人均）
  • 家属/朋友规则：费用承担方式、是否需提前说明
  • 保险所需信息：通过受限权限表单收集，不在群内或私信传递证件信息
  • 交通方案、补休安排（周末活动）
  • 发票要求：所有支出须能取得发票

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：目的、日期、人数、预算上限 活动牵头人 团建提前 15 个工作日；生日会每月 10 日前 飞书文档 立项说明 👤人工判断
2 出方案并比价不少于 2 家（外包或自办），含预算明细与备选方案 策划与保险 立项后 3 个工作日内 活动方案模板 方案文档 🤖+👤
3 提交审批，确认时间、预算、家属规则、补休 活动牵头人、审批人 1 个工作日内 飞书审批 审批结果 🔧飞书固化
4 发全员通知并开放报名表单（参加、家属、交通、饮食禁忌），写明截止时间 通知与执行 活动前 7 个工作日 飞书群公告、多维表格表单 报名名单 🔧飞书固化
5 截止前提醒未报名者；与人事名单核对，不漏不重 通知与执行、名单提供 截止前 1 个工作日 飞书机器人 核对后名单 🔧+🤖
6 按名单投保、订车、订位/订蛋糕，签合同或下单 策划与保险、通知与执行 活动前 2 个工作日 供应商、保险平台 保单、订单 👤人工判断
7 现场签到、分组；生日会礼品本人签收 通知与执行 活动当天 签到表单 签到表、签收表 🔧飞书固化
8 收集发票报销或结算，并归档方案、名单、签到表 活动牵头人 活动后 5 个工作日内 飞书报销审批 报销单 🔧飞书固化
9 复盘：实际人数、费用对比预算、问题清单 活动牵头人 活动后 5 个工作日内 多维表格 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：立项说明、方案、审批记录、报名与保险名单、合同/订单、签到与签收表、报销单、复盘
  • 建议模板/表单：
    • 活动方案：目的、时间、地点、流程、分工、预算明细、备选方案、风险预案、补休安排
    • 报名表：姓名、部门、是否参加、携带家属人数、家属费用确认、交通方式、饮食禁忌
    • 保险信息表（仅限授权人员可见）：被保险人姓名、证件信息、活动日期
    • 复盘表：报名人数、实到人数、预算、实际费用、问题与改进

6. 异常与升级

  • 方案超预算 → 压缩项目或降低餐标后重新报批 → CEO（1 个工作日内）
  • 支出无法取得发票（如刮刮乐等形式）→ 改为可开票形式 → 财务确认后执行
  • 报名人数与名单不符 → 与人事核对差异 → 人事负责人（当日）
  • 天气、场地、订位变化 → 启用备选方案并通知 → 行政负责人（当日）
  • 现场安全事故 → 先处置并联系保险 → 综合部负责人（立即）

7. 衡量指标

  • 报名截止前回收率 = 截止前提交报名人数 / 应邀人数，目标 ≥ 95%
  • 预算偏差 = |实际费用 − 批准预算| / 批准预算，目标 ≤ 10%
  • 生日会覆盖率 = 当月签收寿星人数 / 当月在职寿星人数，目标 100%
  • 方案变更次数：审批后变更 ≤ 1 次
  • 报销及时性 = 活动结束到提交报销的工作日数，目标 ≤ 5

8. 低效诊断

  • 现象：报名靠群消息“+1/-1”统计，有人找不到报名入口，通知多次转发｜依据：「模态跃迁通知群」2026-04
  • 现象：保险所需的家属证件信息通过私下发送收集，存在个人信息泄露风险｜依据：「模态跃迁通知群」2026-04
  • 现象：预算无事先上限，超出后才压缩或“平帐”｜依据：「内务大总管（2026版）」2026-04、「鼎慧产研决策部」2026-01
  • 现象：生日会发放形式未事先确认开票合规，临近活动被否决后临时改｜依据：「【模态】综合部」2026-08
  • 现象：聚餐计划多次变更，排队、订位人员临时指派｜依据：「工程咨询产研」2026-01
  • 现象：周年庆环节方案仅在群内发布，部分演讲主题待定｜依据：「董事会专项沟通群」2026-07

9. 分支变体

  • 月度生日会：每月最后一周周三/周四举办，人事月初提供寿星名单，礼品+蛋糕，本人现场签收
  • 季度/破冰团建：可带家属（小孩费用公司承担，其余自付，需提前说明）；周末团建补休一天；需投保与订大巴
  • 周年庆、程序员节：增加宣讲/环节方案、主持与演讲人分工
  • 年终聚餐、团队聚餐：投票选餐、主备方案、人均餐标凭发票报销
  • 培训日用餐：按培训签到人数订餐

10. 待确认问题

  • 团建、生日会、聚餐的人均预算标准是否已有成文制度？
  • 团建提前 15 个工作日立项、7 个工作日发通知是否可行？
  • 部门自组织聚餐是否也走本流程审批，还是只做报销？
  • 保险信息表由谁保管，活动后多久删除？
  • 周末团建补休规则是否写入制度？
ADM-21全员年会筹办待新建60

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗5 × 跨4 × 险3

  • 适用场景：公司决定举办全员年会/全员大会后，在约 2 周内完成定日期、找场地、设计流程与互动、发邀请函、订餐、物料与布置
  • 负责人：主责——行政（年会筹办牵头）（当前：侯明月·推断待确认）；协同——人事负责人（邀请与人员）（当前：黄莹·推断待确认）、创始人兼 CTO（内容、视频与 PPT）（当前：丁震宇·推断待确认）、CEO（形式、场地、流程拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项定日期与预算 → ② 场地比价锁定 → ③ 流程与奖品方案 → ④ CEO 定稿 → ⑤ 邀请函发出 → ⑥ 订餐与物料 → ⑦ 布置彩排与当天签到 → ⑧ 报销复盘
  • 交付结果：年会倒排表、场地合同/确认单、流程文档、奖品清单、邀请函、订餐确认、签到与人员清单、费用报销与复盘
  • 状态依据：年会全靠临时沟通：日期改动约 3 次，场地从月中找到活动前几天才落定，方案只有手写稿，邀请函前一天才发；无场地预算标准、无时间线清单、无复用模板

1. 场景判定

  • 触发条件：CEO 提出举办年会、全员大会或全员培训日
  • 典型说法：「年会就定在 30 号了，场地我们来搞定，你们策划娱乐环节和奖品」「能省则省，有大屏就行」「邀请函图文结合」
  • 判断问题：是否为全员参加、需要外部场地和完整流程的大型内部活动？
  • 不归本流程管：团建、聚餐、生日会 → 请走 ADM-20；年会工服、伴手礼 → 请走 ADM-19；年会出行组织细节可参考 ADM-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
决策人 定形式、日期、场地要求、预算、流程 A CEO（当前：邴龙志·推断待确认）
筹办牵头人 倒排表、场地比价与对接、流程文档、奖品、订餐、布置 R 行政（年会筹办牵头）（当前：侯明月·推断待确认）
邀请与人员 邀请函、全员通知、外部合作公司与待入职人员邀请、人员清单 R 人事负责人（当前：黄莹·推断待确认）
内容支持 视频、PPT 等内容制作 C 创始人兼 CTO（当前：丁震宇·推断待确认）
统筹把关 审核倒排表与预算 C 综合部负责人（当前：赵雪冰·推断待确认）
财务 场地定金、餐费报销 C 财务专员（当前：刘梦可·推断待确认）

3. 办之前请准备

  • 年会形式（全天/半天、课程场次、娱乐环节）、候选日期 2 个
  • 参会人数（含外部合作公司员工、待入职人员）
  • 场地硬性要求：容量、大屏、桌椅可移动、交通
  • 预算上限：场地、餐饮（午/晚餐餐标）、奖品、物料
  • 往届资料：场地比价表、流程文档、奖品清单、邀请函模板、餐厅清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：确定形式、日期、人数、预算上限，建倒排表 决策人、筹办牵头人 T−14 天（T 为年会日） 多维表格 倒排表 🔧飞书固化
2 场地询价不少于 3 家（注意周末溢价），同时尝试合作方免费场地 筹办牵头人 T−12 天前 场地比价表 比价表 👤人工判断
3 锁定场地，签确认单或办手续 筹办牵头人 T−10 天前 飞书审批 场地确认单 👤人工判断
4 起草流程文档（环节、时长、主持、互动项目）和奖品清单 筹办牵头人 T−10 天前 飞书文档 流程初稿、奖品表 🤖+👤
5 决策人审定流程与互动项目，定稿后不再改日期 决策人 T−7 天前 飞书文档评论 流程定稿 👤人工判断
6 发邀请函与全员通知（时间、地点、着装、流程概要），单独确认外部与待入职人员 邀请与人员 T−7 天前 飞书群公告 邀请函 🤖+🔧
7 餐厅清单投票、按餐标订餐；奖品与物料下单 筹办牵头人 T−5 天前 飞书投票 订餐确认、订单 🔧飞书固化
8 内容（视频、PPT）交付并联调设备 内容支持 T−2 天前 — 内容文件 👤人工判断
9 布置场地、彩排 筹办牵头人 T−1 天 — 布置完成 👤人工判断
10 当天签到、分组、执行 筹办牵头人、邀请与人员 T 日 签到表单 签到表 🔧飞书固化
11 报销结算，整理人员清单，复盘并归档全部模板 筹办牵头人 T+5 个工作日内 飞书报销审批、多维表格 报销单、复盘 🔧飞书固化

5. 交付物与模板

  • 交付物：倒排表、场地比价表与确认单、流程文档、奖品清单、邀请函、订餐确认、签到表、报销单、复盘
  • 建议模板/表单：
    • 年会倒排表：事项、负责人岗位、截止日（以 T 为基准）、状态、备注
    • 场地比价表：场地名称、容量、大屏、桌椅、工作日/周末价格、交通、联系人岗位、询价日期
    • 复盘表：参会人数、各项费用对比预算、日期/场地变更次数、问题清单

6. 异常与升级

  • 日期需要变更 → 只允许在 T−10 天前变更，之后变更须决策人书面确认 → CEO（当日）
  • 场地超预算或 T−10 天仍未锁定 → 提供降级方案（公司内场地、合作方场地）→ CEO（当日）
  • 邀请对象范围不清（外部合作公司、待入职）→ 人事列清单请决策人确认 → CEO（1 个工作日内）
  • 餐费“发钱”与“凭票报销”口径冲突 → 统一凭发票报销，财务确认 → 综合部负责人
  • 设备故障 → 启用备用笔记本与投屏线 → 筹办牵头人现场处理

7. 衡量指标

  • 场地锁定提前量 = 场地确认日到年会日的天数，目标 ≥ 10 天
  • 定稿后日期变更次数，目标 0 次
  • 邀请函提前量 = 邀请函发出到年会日的天数，目标 ≥ 7 天
  • 预算偏差 = |实际 − 预算| / 预算，目标 ≤ 10%
  • 出席率 = 签到人数 / 应邀人数，目标 ≥ 95%

8. 低效诊断

  • 现象：年会日期在立项后改动约 3 次，下游场地、餐饮反复重来｜依据：「行政人事对接群」2026-01
  • 现象：没有场地预算标准，多家询价、还价，约 10 次沟通后在年会前几天才落定｜依据：「行政人事对接群」2026-01
  • 现象：流程与互动项目方案只有手写稿，决策人要求先看，临近当天才出完整流程文档｜依据：「行政人事对接群」2026-01
  • 现象：邀请函前一天才发，大量员工私下询问；外部与待入职人员邀请靠临时补充｜依据：「行政人事对接群」2026-01
  • 现象：餐费同时出现“发钱”与“凭票报销”两种做法｜依据：「行政人事对接群」2026-01

9. 分支变体

  • 外部合作公司员工、待入职人员：需人事单独确认并发邀请
  • 午餐与晚餐餐标不同；晚餐按人均上限凭发票报销
  • 合作方提供免费场地：行政对接场地方办理手续，确认使用时间与设备

10. 待确认问题

  • 年会是否每年固定举办？固定在哪个月份？
  • 场地、餐饮、奖品的预算上限是否需要成文？由谁审批？
  • 年会主责是行政还是人事？两者分工是否按本 SOP 划分？
  • T−14 天立项是否足够，是否应提前到 T−30 天？
  • 往届年会资料（奖品表、流程、PPT、餐厅清单）由谁归档？
ADM-22差旅订票与企业出行账户管理待优化27

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗1 × 跨3 × 险3

  • 适用场景：员工因公出行需要订票（含二等座售罄等例外），以及企业滴滴等出行账户的开通、余额充值与分主体对账
  • 负责人：主责——行政专员（差旅与企业出行账户）（当前：侯明月·推断待确认）；协同——财务专员（充值与报销）（当前：刘梦可·推断待确认）、CEO（差旅例外审批）（当前：邴龙志·推断待确认）、销售负责人（差旅高频部门代表）（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 出差审批 → ② 按标准订票 → ③ 例外在审批中说明并附证明 → ④ 报销按标准核对；企业出行账户：① 开通申请 → ② 按主体开通 → ③ 余额预警 → ④ 充值 → ⑤ 月度对账
  • 交付结果：出差审批单、符合标准的票据与报销单、企业出行账户成员清单、充值记录、按主体的月度对账单
  • 状态依据：已有企业滴滴账户及通勤福利使用规则；但差旅标准缺少例外条款，二等座售罄换一等座需在高管群临时请示；企业滴滴余额耗尽后才在全员群发现，充值人、所属主体账户需临时确认，开通申请在群里提

1. 场景判定

  • 触发条件：员工因公出差需订火车票/机票/酒店；标准舱位售罄或时间不合适需超标；企业滴滴余额不足；员工需要开通或重新开通企业滴滴
  • 典型说法：「二等售罄了，换一等应该可以吧」「企业滴滴没钱了」「给我再开通一下企业滴滴」
  • 判断问题：是否为因公出行产生的交通费用，或企业出行账户的管理事项？
  • 不归本流程管：差旅费用报销的财务审核细则 → 请走 FIN-07（差旅事前报备与差旅报销）；企业滴滴充值与通勤打车报销 → 请走 FIN-08；企业滴滴通勤福利的享受规则 → 以人事发布的员工福利补充通知为准；团建大巴 → 请走 ADM-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账户管理人 企业出行账户开通/停用、成员与主体维护、余额监控、差旅标准解释 R 行政专员（当前：侯明月·推断待确认）
财务 账户充值、差旅报销核对、分主体对账 R 财务专员（当前：刘梦可·推断待确认）
直属上级 审批例外条款内的升舱/改班次 R 出行人直属上级（当前：各部门负责人）
例外审批人 审批例外条款以外的超标准订票 A（升级） CEO（当前：邴龙志·推断待确认）
制度维护 差旅标准与例外条款的制定与发布 A 综合部负责人（当前：赵雪冰·推断待确认）
部门代表 反馈差旅高频场景的规则问题 C 销售负责人（当前：李鹏为·推断待确认）
出行人 提出差审批、按标准订票、提交报销 R 出行员工

3. 办之前请准备

  • 出差事由、行程、日期、所属主体与项目
  • 现行差旅标准（交通舱位、住宿标准、市内交通）
  • 超标准时：售罄或时间冲突的截图
  • 企业滴滴开通：姓名、手机号由本人在表单内填写（不在群内发送）、所属主体、用途（因公/通勤）
  • 账户余额与上月消费数据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起出差审批，写明行程、主体、项目 出行人 出发前 1 个工作日 飞书出差审批 出差审批单 🔧飞书固化
2 按标准订票；标准舱位售罄或无合适班次时，在审批中勾选“例外”并附截图 出行人 订票时 飞书审批 例外说明 🔧飞书固化
3 审批例外（符合例外条款的可由直属上级审批，不再临时请示高层） 直属上级；条款外由例外审批人 2 小时内 飞书审批 审批结果 🔧飞书固化
4 返回后提交报销，系统校验是否超标、是否有例外审批 出行人；财务 返回后 5 个工作日内提交 飞书报销审批 报销单 🔧+🤖+👤
5 企业滴滴开通申请提交表单，按主体加入对应企业账户 出行人；账户管理人 1 个工作日内开通 飞书表单、企业滴滴后台 成员清单 🔧飞书固化
6 设置余额预警阈值，低于阈值自动通知账户管理人与财务 账户管理人 一次性设置，每月检查 企业滴滴后台/飞书机器人 预警规则 🤖自动化
7 收到预警后充值到对应主体账户 财务 预警后 1 个工作日内 企业滴滴后台 充值记录 👤人工判断
8 月度导出账单，按主体对账，清理离职成员 账户管理人、财务 每月 5 日前 企业滴滴后台 月度对账单 🤖+👤

5. 交付物与模板

  • 交付物：出差审批单、例外说明、报销单、企业出行账户成员清单、充值记录、月度对账单
  • 建议模板/表单：
    • 出差审批：出行人、主体、项目、行程、交通方式、舱位、是否例外、例外原因、截图
    • 差旅例外条款：标准舱位售罄、无合适班次、紧急客户事项等可升一级的情形与审批人
    • 企业出行账户成员表：姓名、部门、所属主体、用途、开通日期、停用日期

6. 异常与升级

  • 标准舱位售罄且行程紧急 → 按例外条款订票并补审批 → 直属上级（当日）
  • 不在例外条款内的超标准 → 超出部分个人承担或单独审批 → CEO（1 个工作日内）
  • 企业滴滴余额耗尽影响出行 → 员工先自付打车凭票报销，财务当日充值 → 财务专员
  • 账户所属主体不清 → 账户管理人按成员清单确认 → 综合部负责人（1 个工作日内）
  • 离职人员未停用 → 月度对账时停用 → 账户管理人
  • 升级条件：超标准订票不属于例外条款（售罄、无合适班次、紧急客户事项）时，由例外审批人（CEO）拍板，即 RACI 中的“A（升级）”；差旅标准与例外条款本身的制定由制度维护（综合部负责人）最终负责

7. 衡量指标

  • 例外审批时长 = 提交到审批完成的小时数，目标 ≤ 2 小时
  • 余额中断次数 = 因余额不足导致无法用车的次数，目标每季度 0 次
  • 开通时效 = 申请到开通的工作日数，目标 ≤ 1
  • 对账完成率 = 按时完成月度分主体对账的月份 / 总月份，目标 100%

8. 低效诊断

  • 现象：差旅标准没有例外条款，二等座售罄是否可换一等座需临时向高层请示｜依据：「【跃迁】高管群」2026-09
  • 现象：企业滴滴余额耗尽后才由使用人在全员群发现，充值人临时认领｜依据：「模态集团（全员群）」2026-03
  • 现象：账户分属不同主体，余额不足时需临时确认是哪个主体的账户｜依据：「模态集团（全员群）」2026-03
  • 现象：开通/重新开通申请在全员群提出，无表单与成员清单｜依据：「模态集团（全员群）」2026-01

9. 分支变体

  • 主体差异：模态、鼎慧等主体分别有企业出行账户，充值与对账按主体分开
  • 因公出行 vs 通勤福利：通勤福利按员工福利补充通知中的企业滴滴使用规则执行
  • 火车票舱位例外：二等座售罄可升一等座（待写入制度）

10. 待确认问题

  • 公司是否已有成文差旅标准？例外条款由谁起草、何时发布？
  • 例外审批能否下放到直属上级？是否设金额上限？
  • 企业出行账户的管理人与充值人分别是谁（原经办人已交接）？
  • 各主体余额预警阈值设多少？
  • 是否使用飞书或企业滴滴的差旅模块实现自动校验？
ADM-23公司证照与档案（印章/档案柜）保管调用待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：业务需要营业执照、法人证件、资质等材料（小程序审核、合同、渠道资料、申报），或人事档案、公章、财务资料需要安全存放与借阅
  • 负责人：主责——行政专员（证照与印章保管）（当前：侯明月·推断待确认）；协同——总助助理（档案体系建设）（当前：董蓝汐·推断待确认）、人事负责人（人事档案）（当前：黄莹·推断待确认）、财务负责人（财务凭证）（当前：黄梦婷·推断待确认）、法务负责人（合同档案）（当前：李瑶·推断待确认）、CEO（档案室规划拍板）（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 建电子证照库 → ② 设权限与水印规则 → ③ 申请调用 → ④ 发放带水印版本/原件借出登记 → ⑤ 证照变更同步 → ⑥ 纸质档案编号入柜 → ⑦ 借阅登记 → ⑧ 季度盘点
  • 交付结果：按主体分类的电子证照库（含版本与有效期）、证照调用记录、原件与档案借阅登记表、纸质档案目录、季度盘点报告
  • 状态依据：无统一证照库，文件散在个人电脑和实物柜，同类求助约 5 次，保管人不在岗时需他人现场拍照，新旧版本营业执照混用；档案柜选型和购买来回确认，档案暂放、盘点发现缺失，尚无成文档案制度

1. 场景判定

  • 触发条件：需要营业执照、法人身份证件、资质证书、开户许可等材料；证照变更（地址、法人、经营范围）；人事、财务、合同纸质档案需要入柜或借阅
  • 典型说法：「营业执照谁发我一下，急」「最新的营业执照来一个」「新版执照在公司，谁拍一下」「公司资产和档案管理太乱了」
  • 判断问题：要的是公司主体的证照/档案材料，或需要存放、借阅纸质档案吗？
  • 不归本流程管：用印申请 → 请走 LEG-09（用章用印审批与盖章版本核对）；合同审核 → 请走 LEG-03（销售合同审查与多方会签）或 LEG-04（采购/服务及其他对外合同、承诺函起草与审核）；IT 资产台账 → 请走 ADM-27；工商变更办理本身 → 由总经办/法务负责

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
证照保管人 维护电子证照库、发放调用、原件保管与借出、变更同步 R 行政专员（当前：侯明月·推断待确认）
档案体系建设 档案分类标准、编号规则、档案室布局、借阅登记表 R 总助助理（当前：董蓝汐·推断待确认）
人事档案 人事档案入柜与借阅审批 R 人事负责人（当前：黄莹·推断待确认）
财务档案 财务凭证入柜与借阅审批 R 财务负责人（当前：黄梦婷·推断待确认）
合同档案 合同原件归档 C 法务负责人（当前：李瑶·推断待确认）
制度负责人 审批档案制度、敏感证件调用权限 A 综合部负责人（当前：赵雪冰·推断待确认）
决策 档案室、档案柜等投入 C CEO（当前：邴龙志·推断待确认）
申请人 说明用途、按期归还 I 业务、市场、销售等申请人

3. 办之前请准备

  • 主体清单：模态、模态跃迁、苏州模态、跃迁、鼎慧、跃竞等各主体
  • 每个主体的证照清单：营业执照（正副本）、开户许可、资质证书、法人证件（仅限授权）
  • 最新版本扫描件与有效期
  • 申请人需说明：主体、材料、用途、是否需要原件、使用期限
  • 带锁档案柜/档案室，钥匙保管人与备份人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在飞书云盘建“公司证照库”，按主体分文件夹，记录版本号、更新日期、有效期 证照保管人 一次性，10 个工作日内完成 飞书云盘、多维表格 证照库与目录 🔧飞书固化
2 设权限：营业执照等常用件全员可查看水印版；法人证件、开户许可仅授权人员可见 证照保管人、制度负责人 与第 1 步同步 飞书云盘权限 权限清单 🔧飞书固化
3 申请人提交调用申请（主体、材料、用途、期限） 申请人 使用前 飞书表单/机器人 申请记录 🔧飞书固化
4 常用件由机器人按关键词回复链接；敏感件由保管人发带“仅供××用途”水印版本 机器人/证照保管人 常用件即时；敏感件 2 小时内 飞书机器人 调用记录 🤖自动化
5 原件借出登记，约定归还日期，到期提醒 证照保管人 借出当日登记；到期前 1 天提醒 借阅登记表 借出记录 🔧+🤖
6 证照变更后替换电子版，旧版标“作废”归档，通知常用部门 证照保管人 拿到新证照后 1 个工作日内 飞书云盘、群通知 新版本 🔧飞书固化
7 纸质档案按分类编号入柜，登记目录 人事档案/财务档案/合同档案/证照保管人 文件产生后 5 个工作日内 档案目录表 档案目录 🔧飞书固化
8 档案借阅：申请 → 对应档案负责人审批 → 登记借出与归还 申请人、对应档案负责人（人事档案/财务档案/合同档案） 审批 1 个工作日内 飞书审批 借阅记录 🔧飞书固化
9 季度盘点证照有效期、档案目录与实物、借出未还 档案体系建设 每季度首月 10 日前 多维表格 盘点报告 👤人工判断

5. 交付物与模板

  • 交付物：电子证照库、证照目录、调用记录、借阅登记表、纸质档案目录、季度盘点报告
  • 建议模板/表单：
    • 证照目录：主体、证照名称、证照编号（内部存档，不对外展示）、版本、发证日期、有效期、存放位置（电子/实物）、可见范围
    • 调用/借阅登记：申请人岗位、主体、材料、用途、电子/原件、借出日期、应还日期、实际归还日期、审批人岗位
    • 纸质档案目录：档案编号、类别（人事/财务/合同/证照）、标题、所属主体、入柜日期、柜号、借阅状态

6. 异常与升级

  • 保管人不在岗、急需原件 → 由备份钥匙保管人办理并登记 → 综合部负责人（当日）
  • 发现新旧版本混用 → 立即替换库中版本并通知已调用部门 → 证照保管人（当日）
  • 证照即将到期（30 天内）→ 提醒办理续期 → 总经办/法务
  • 原件逾期未还 → 提醒申请人，超 3 个工作日 → 综合部负责人
  • 盘点发现档案缺失 → 登记缺失清单、追溯借阅记录 → 综合部负责人（5 个工作日内给出处理意见）

7. 衡量指标

  • 自助获取率 = 通过证照库/机器人自助取得的次数 / 证照调用总次数，目标 ≥ 80%
  • 敏感件响应时长 = 申请到发放的小时数，目标 ≤ 2 小时
  • 版本一致率 = 库中最新版与实物一致的证照数 / 证照总数，目标 100%
  • 原件按期归还率，目标 100%
  • 季度盘点差异数 = 目录与实物不符的档案数，目标 0

8. 低效诊断

  • 现象：没有统一证照库，需求人在群里@所有人求发营业执照，同类求助约 5 次｜依据：「内务大主管」2026-01
  • 现象：证照变更后新旧版本混用，新版只有实物，需有人现场拍照｜依据：「内务大主管」2026-01、「内务大主管」2026-03
  • 现象：保管人不在岗时无人可发，缺少备份人｜依据：「内务大主管」2026-03
  • 现象：档案柜由谁挑选、谁购买来回确认，档案先暂放小办公室｜依据：「行政人事对接群」2026-02
  • 现象：合同和档案盘点发现缺失，资产与档案管理无体系｜依据：「行政人事对接群」2026-03

9. 分支变体

  • 多主体：模态、模态跃迁、苏州模态、跃迁等主体证照分别维护；异地主体（苏州）地址变更后需同步
  • 敏感证件：法人身份证件仅授权人员可见，发放必须带用途水印，不在群内传播
  • 档案室建设：带锁档案柜 → 专门档案室兼财务室，与人事、财务、法务协同

10. 待确认问题

  • 证照与印章保管主责是行政专员还是综合部负责人？是否设备份人？
  • 法人证件的调用审批人是谁？
  • 档案分类标准和编号规则由谁评审、何时发布？
  • 档案室兼财务室的建设进度与位置是否已确定？
  • 合同原件归档归法务还是行政？
ADM-24IT设备与研发硬件采购申请待优化192

状态：待优化｜证据：有证据（卡片 15 张 / 会话 14 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：新人入职、设备不足、研发换配置、测试机不足、需要工作站/CI 机/算力机/NAS/服务器、外设耗材、客户交付硬件备货、设备返修时的采购申请到配发入账
  • 负责人：主责——IT 运维/采购专员（当前：杨明学·推断待确认）；协同——创始人兼 CTO（IT 预算与配置审批）（当前：丁震宇·推断待确认）、CEO（付款审批）（当前：邴龙志·推断待确认）、行政专员（京东慧采下单）（当前：侯明月·推断待确认）、财务负责人（付款）（当前：黄梦婷·推断待确认）、运维/交付工程师（到货验收与领用核对）（当前：游家豪·推断待确认）；兜底——创始人兼 CTO
  • 核心流程：① 提交“采购申请”审批 → ② 查库存可否调拨 → ③ 按分级标准选型询价 → ④ CTO 审配置预算、CEO 审付款 → ⑤ 下单 → ⑥ 财务付款 → ⑦ 到货验收 → ⑧ 入台账并领用签收
  • 交付结果：信息完整的采购审批单、询价比价记录、订单与发票、验收单、IT 资产台账记录、领用签收记录
  • 状态依据：3 月起推飞书“采购申请”审批，4 月明确“运维提单 → CTO 与 CEO 审批 → 行政下单 → 财务付款”，5 月新建“运维”审批类别；但急单仍口头批后垫付、审批单看不出买了什么、配置标准缺失差点买错、付款环节群催、台账靠补录与记忆

1. 场景判定

  • 触发条件：新人入职缺电脑；研发电脑内存/硬盘不足；Mac/Windows 测试机不足；CI runner、工作站、算力机、NAS、服务器需求；外设、UPS、打印机等；客户交付硬件备货；设备损坏返修或换货
  • 典型说法：「我开个审批单吧」「求集采 Mac」「采购得上点流程了，今天好多人提采购」「有货了还得走流程，走流程还得几天」「审批提一下，设备维修/退回」
  • 判断问题：要买的是电脑、服务器、外设、测试机等实物 IT 硬件吗？是否已经确认库存里没有可调拨的？
  • 不归本流程管：云服务器、模型 API、SaaS 订阅 → 请走 ADM-34（云服务与软件订阅等非实体资产申领与释放），涉及对公合同付款的按 FIN-01（对公采购申请与付款审批）；零食饮料 → 请走 ADM-17；活动物料 → 请走 ADM-19；到货入库与调配 → 请走 ADM-27；设备借用 → 请走 ADM-28；设备报修 → 请走 ADM-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
采购负责人 汇总需求、查库存、选型询价、提单、跟进到货、配发、维护台账 R IT 运维/采购专员（当前：杨明学·推断待确认）
配置与预算审批 审核配置是否符合分级标准、批准 IT 预算、定备货策略 A 创始人兼 CTO（当前：丁震宇·推断待确认）
付款审批 审批付款 A（升级） CEO（当前：邴龙志·推断待确认）
下单人 在京东慧采加购下单、跟踪物流 R 行政专员（当前：侯明月·推断待确认）
付款人 收到审批抄送后付款、收票 R 财务负责人（当前：黄梦婷·推断待确认）
验收人 依据参数出验收单、核对型号数量序列号 R 运维/交付工程师（当前：游家豪·推断待确认）
需求人 说明用途、配置、使用人、期望交付时间 C 各部门需求人

3. 办之前请准备

  • 需求说明：品名、型号/配置等级、数量、用途、使用人、存放地点、云还是实体机、期望交付时间、预算归属主体
  • 设备分级标准（研发/非研发、Windows/Mac、内存与硬盘档位）
  • 库存台账：是否有可调拨的同类设备
  • 询价记录：至少 2 个渠道报价与询价日期（价格有效期按 7 天计）
  • 供应商资质：能签对公合同、能开发票
  • 高价值设备（工作站、CI 机、算力机）：两套配置方案和到货后的使用与分配计划

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“采购申请”审批，必填字段完整（品名、型号、数量、用途、使用人、云/实体、预算主体） 需求人或采购负责人代提 需求产生当日 飞书审批 审批单 🔧飞书固化
2 查台账，能调拨的直接调拨并关闭申请 采购负责人 1 个工作日内 IT 资产台账 调拨或采购结论 🔧+🤖
3 按分级标准选型，询价不少于 2 家，高价值设备出 2 套方案 采购负责人 2 个工作日内 京东慧采、渠道报价 比价记录 🤖+👤
4 审批配置与预算 配置与预算审批 1 个工作日内 飞书审批 审批意见 👤人工判断
5 审批付款 付款审批 1 个工作日内 飞书审批 审批意见 👤人工判断
6 京东慧采加购下单；渠道采购签对公合同 下单人 审批通过后 1 个工作日内 京东慧采 订单号 🔧飞书固化
7 收到审批抄送后付款并收票 付款人 1 个工作日内 网银 付款流水 👤人工判断
8 到货按参数验收，核对型号、数量、序列号 验收人 到货 1 个工作日内 验收单模板 验收单 🔧飞书固化
9 登记台账（订单号、价格、序列号、使用人、存放点），通知领用并签收 采购负责人 验收当日 IT 资产台账、“运维”审批（资产领用） 台账记录、领用记录 🔧+🤖
10 退换与返修走“设备维修/退回”审批，进度更新到台账 采购负责人 提出当日登记 飞书审批 维修记录 🔧飞书固化

5. 交付物与模板

  • 交付物：采购审批单、比价记录、订单与发票、付款流水、验收单、资产台账记录、领用签收
  • 建议模板/表单：
    • 采购申请必填字段：品名、型号/配置等级、数量、单价预估、总价、用途、使用人、存放地点、云/实体、期望交付日、预算主体、是否急单、询价日期
    • 验收单：订单号、品名、型号、配置参数、数量、序列号、外观、开机检测、验收人、验收日期
    • IT 资产台账：资产编号、品名、型号、配置、序列号、采购日期、价格、订单号、所属主体、使用人、存放点、状态（在用/库存/借出/维修/报废）

6. 异常与升级

  • 急单（影响客户交付或 CI）：小额（阈值待定）可先买后补，24 小时内补审批；超阈值由 CTO 当日审批 → 创始人兼 CTO（当日）
  • 需求描述不清（云/实体、规格）→ 退回需求人补充，不重复开单 → 采购负责人
  • 缺货或涨价超过审批金额 10% → 重新报价并更新审批 → 创始人兼 CTO（1 个工作日内）
  • 付款审批超过 1 个工作日未处理 → 飞书审批自动催办 → CEO
  • 买后需求变化（设备闲置）→ 登记闲置，优先内部调拨，无法调拨则退货或转卖并登记 → 创始人兼 CTO
  • 供应商真伪存疑 → 只选能签对公合同、开发票的供应商 → 财务负责人
  • 个人自购补差 → 公司按标准额度采购，差额个人承担并书面确认 → 财务负责人
  • 升级条件：采购配置与 IT 预算由配置与预算审批（创始人兼 CTO）最终负责；付款环节按现行做法提交 CEO 审批，金额分级确定后，超过 [阈值待财务确认] 的采购由 CEO 拍板，即 RACI 中的“A（升级）”

7. 衡量指标

  • 采购周期 = 审批提交到设备领用的工作日数，目标常规件 ≤ 5、高价值件 ≤ 10
  • 审批单信息完整率 = 必填字段齐全的审批单 / 总审批单，目标 100%
  • 先买后补比例 = 先买后补审批的单数 / 总单数，目标 ≤ 10%
  • 台账一致率 = 盘点时台账与实物一致的设备数 / 设备总数，目标 ≥ 98%
  • 闲置率 = 到货 30 天仍未分配使用的设备数 / 到货设备数，目标 0
  • 群内催办次数：每月 ≤ 2 次

8. 低效诊断

  • 现象：需求描述未对齐（云还是实体机），同一需求开了两张审批单｜依据：「Leap产研测」2026-07
  • 现象：急单口头批准后先买再补单，审批单只写采购平台名，看不出买了什么｜依据：「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-04
  • 现象：采购执行人交接后流程不清，运维提单后还要转发，付款依赖单人持有的 U 盾｜依据：「运维&综合对接群」2026-04
  • 现象：没有设备分级标准，采购人差点买错配置；分级到 8 月才口头宣布｜依据：「鼎慧产研决策部」2026-05、「鸽子群模态分群」2026-08
  • 现象：付款审批与到货进度靠群内反复催问｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09、「鸽子群模态分群」2026-08
  • 现象：高价值设备在群里 review 后直接下单，到货后才规划用途，存在闲置风险；买后方向变化造成浪费｜依据：「Leap产研决策部」2026-08、「跃迁AI总动员」2026-09、「鸽子群模态分群」2026-01
  • 现象：库存靠记忆，设备数量、价格、流水号需事后补录，到货与台账不符｜依据：「跃迁生态大会筹备群」2026-05、「运维&综合对接群」2026-03
  • 现象：谁需要申请、谁可以免审口径不一；测试机不足时靠群里临时借｜依据：「随便瞎聊啦～」2026-08、「Leap产研测」2026-05

9. 分支变体

  • 办公电脑：研发 Windows、研发 Mac、非研发三类配置；Mac 集采需求可合并批次
  • 外设与备件：键鼠、显示器、耳机、UPS、打印机、线缆，按批次配发，问题统一走报修
  • 工作站、CI 机、算力机、NAS、服务器：万元级，必须两套方案 + 使用与分配计划，到货后分配席位并登记资源表
  • 测试机：Mac/Windows 真机，纳入资产台账统一借用；云机由研发自行开通
  • 客户交付硬件与备用机：滚动备货（常备台数由 CTO 确定，低于余量即补）
  • 渠道采购：对公合同、开票，付款走对公
  • 厂商送样机：登记入台账，标注“样机”

10. 待确认问题

  • 先买后补的小额阈值定多少？急单范围如何界定？
  • 金额分级审批：多少金额以下仅 CTO 审批，多少以上需 CEO？
  • 设备分级标准（内存、硬盘档位）由谁发布？是否成文？
  • 下单人是行政专员还是财务？U 盾付款是否设备份人？
  • 采购周期常规件 5 个工作日是否可行？
  • IT 资产台账以哪张多维表格为准（设备库存表、IT 资产管理表、资源需求表并存）？
  • 备用机常备台数和补货阈值是多少？
ADM-25交付用硬件备货采购与供应商比价待新建192

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：交付库存（元和/源核/龙智/震宇等机型、周年版）低于安全库存，或新交付、客户采购意向需要服务器/工作站/机柜时，完成库存评估、成本核算、供应商比价压价和下单补货。
  • 负责人：主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——交付统筹（当前：杨萌·推断待确认）、销售/商务（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 库存预警/需求提出 → ② 库存与需求量评估 → ③ 规格确认与成本核算 → ④ 合格供应商比价压价 → ⑤ 采购审批 → ⑥ 下单与到货跟踪 → ⑦ 验收入库并更新库存
  • 交付结果：已审批的补货采购单、供应商比价记录、按期到货并入库的交付硬件、更新后的库存与成本表
  • 状态依据：采购需求、审批、到货跟踪都没有载体，靠群聊推进；2026-04～10 多次出现“成本有核算吗”“尽快确认硬件成本”“供应商没人统一管”，备选供应商无响应，同配置单价多次不一致。

1. 场景判定

  • 触发条件：某交付机型库存低于安全库存（建议 = 近 4 周平均周出货量 × 2）；在谈/已签订单所需机型库存不足；客户提出采购意向需核算硬件成本；需要引入或更换供应商。
  • 典型说法：「和代工方砍价的策略搞好了吗，我们得尽快确认硬件成本」「成本有核算吗」「供应商是完全不缺的，主要是没人统一管」「补的那批卖得差不多了」
  • 判断问题：采购对象是不是面向客户交付或备货的整机、服务器、准系统、机柜？会不会占用交付库存、影响交付毛利？
  • 不归本流程管：员工办公电脑、研发工作站/CI 机采购 → 请走 ADM-24；新机型选型、BOM 设计、ODM 排期 → 请走 X-DLV-02；对客户出硬件报价 → 请走 SAL-20 / X-DLV-01；对公付款 → 请走 FIN-01；调研验证用设备 → 请走 ADM-26；库存台账口径 → 请走 X-DLV-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
采购执行 库存评估、询价比价、下单、到货跟踪、维护供应商库 R IT采购/资产专员（当前：杨明学·推断待确认）
审批人 批准采购数量、供应商与价格；大单谈判拍板 A CTO（当前：丁震宇·推断待确认）
需求方 提供订单预测与交付时间，确认补货机型 C 交付统筹（当前：杨萌·推断待确认）
商务 提供客户采购意向与目标售价，确认毛利 C 销售/商务（当前：吴琪·推断待确认）
渠道谈判支持 年度框架价、大客户量价谈判 C 市场销售负责人（当前：李鹏为·推断待确认）
财务 成本核算复核、付款、发票 C 财务负责人（当前：黄梦婷·推断待确认）
兜底 职责冲突、超预算协调 I 综合部负责人

3. 办之前请准备

  • 当前库存：按机型、批次、在途数量列出，附近 4 周出货量
  • 待交付订单清单及要求交付日期
  • 目标规格（桌面/机架 × 低/中/高配）与 BOM 版本号
  • 合格供应商库中至少 3 家的报价（急单至少 2 家）
  • 目标成本与客户售价（用于核对毛利）
  • 是否需要专票、交货地点、付款方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 库存低于安全线时自动提醒；或需求方提交补货/核价需求 系统 / 交付统筹 触发当日 库存多维表格 + 机器人 补货需求单 🔧+🤖
2 结合库存、在途和订单预测，确定补货机型与数量 采购执行 收到需求后 1 个工作日内 库存表 补货数量建议 👤人工判断
3 按规格-价格对照表核算单台成本，与商务对齐售价和毛利 采购执行 + 商务 1 个工作日内 规格-价格对照表 成本核算表 🤖自动化
4 从供应商库询价，≥3 家比价；按急单/非急单分级；批量单按年度预计量谈价 采购执行 非急单 3 个工作日内，急单 1 个工作日内 供应商库、比价表 比价记录 🔧飞书固化
5 提交采购审批，附比价表和成本核算表 采购执行 比价完成当日 飞书审批 采购审批单 🔧飞书固化
6 审批数量、供应商与价格 CTO 提交后 1 个工作日内 飞书审批 审批结论 👤人工判断
7 下单，同步发起对公付款（走 FIN-01），登记约定交期 采购执行 / 财务 审批通过后 1 个工作日内 飞书审批、供应商订单 订单号、付款单 🔧飞书固化
8 跟踪到货；超过交期 2 个工作日未到，催办并通知交付统筹 采购执行 按交期 库存表到货提醒 到货状态 🔧+🤖
9 到货验收、入库、更新批次与库存，移交装机 采购执行 → 交付 到货后 1 个工作日内 ADM-27 / X-DLV-13 入库记录 🔧飞书固化

5. 交付物与模板

  • 交付物：补货采购审批单、比价记录、成本核算表、入库记录、更新后的库存表
  • 建议模板/表单：
    • 补货需求单：机型、数量、用途（订单号/备货）、要求到货日、需求人、关联订单
    • 合格供应商库（多维表格）：供应商、可供品类（整机/准系统/配件/机柜）、交期、付款条件、开票能力、历史成交价、响应时效、质量问题记录、评级
    • 比价表：规格/BOM 版本、供应商 × 单价、交期、质保、含税与否、选择理由
    • 规格-价格对照表：桌面/机架 × 低/中/高配、最近成交价、更新日期，供报价自动计算

6. 异常与升级

  • 供应商 2 个工作日无回复 → 改用库内下一家 → 3 个工作日内仍无可用供应商，升级 CTO
  • 长期代工渠道量产周期（约 1 个月）赶不上交期 → 评估自行采购（约 3 个工作日）或合作方渠道 → 交付统筹与 CTO 当日决定
  • 报价比上次成交价高 10% 以上，或毛利低于目标 → 暂停下单，商务与 CTO 1 个工作日内确认是否调价或换配置
  • 到货故障、规格不符 → 2 个工作日内发起退换货，同时通知交付统筹评估交付影响
  • 客户采购意向密集、核算占用过多工时 → 改用规格表自动报价；外包给合作方报价时，必须留存报价记录

7. 衡量指标

  • 交付缺货次数：因库存不足导致交付延期的订单数，目标每季度 0 次
  • 补货周期：需求提出到入库的自然日，急单 ≤ 5 天，非急单 ≤ 35 天
  • 比价覆盖率：有 ≥3 家（急单 ≥2 家）比价记录的采购单占比，目标 ≥ 90%
  • 单价偏差：同规格本次单价与 90 天内最低成交价的偏差，目标 ≤ 5%
  • 核价响应时长：收到核价需求到给出成本的工作日，目标 ≤ 1 天

8. 低效诊断

  • 现象：硬件成本与压价策略迟迟定不下来，需求方多次催办｜依据：「交付订单通知群」2026-06
  • 现象：备选供应商不回复，没有替补名单，补货节奏只在执行人手里｜依据：「交付订单通知群」2026-07
  • 现象：客户采购意向的价格与需求测算集中压在采购执行岗，同一口径反复手算｜依据：「LeapCore（archived）」2026-04
  • 现象：成本核算没有固定口径和留档，需临时追问是否核算过｜依据：「LeapCore（archived）」2026-05
  • 现象：供应商无人统一管理，每次临时询价，同配置单价差异大，采购由 IT 兼任｜依据：「忠橙星行星引擎」2026-09、「忠橙星行星引擎」2026-10

9. 分支变体

  • 长期代工渠道采购机架式服务器：量产约 1 个月，用于计划性备货，需提前按订单预测下单
  • 自行采购（电商/现货）：约 3 个工作日，用于急单、小批量
  • 合作方报价渠道：客户采购意向可转合作方报价，商务确认毛利并留存记录
  • 急单与非急单：非急单优先走价格更低的渠道；批量按年度预计量（如年 500 台级）谈框架价
  • 整机与准系统；机柜等千元级小件可 2 家比价、简化审批

10. 待确认问题

  • 交付硬件采购的主责是否设专职采购，还是继续由 IT 兼任？
  • 安全库存按“近 4 周出货 × 2”设定是否合适？各机型是否需要不同阈值？
  • 采购审批金额分级：多少金额以下 IT 可直接下单，多少以上需 CEO 加签？
  • 供应商库由谁维护、多久复评一次？
  • 对客户的硬件核价是否统一交给规格表自动计算，再由商务复核？
  • 本流程与 X-DLV-02（选型/BOM/ODM）的分界是否认可？
ADM-26调研/验证用设备临时采购与处置待新建32

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗2 × 跨4 × 险2

  • 适用场景：研发/产品为竞品调研或技术验证需要实机（如小米 NAS、懒猫微服、某存储设备厂商 NAS），完成临时采购或借用、领用登记，评估结束后按期保留、退货、转赠或出售。
  • 负责人：主责——IT采购/资产专员（当前：杨明学·推断待确认）；协同——需求方研发负责人（当前：王皓南·推断待确认）、产品负责人（当前：杨萌·推断待确认）、设备保管运维（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 提出需求（用途/评估期/预算）→ ② 先查替代方案 → ③ 选采购方式并标注退货期 → ④ 小额快速审批 → ⑤ 下单、入库登记、领用 → ⑥ 评估期满前提醒 → ⑦ 处置（保留/退货/转赠/出售）并更新台账
  • 交付结果：调研设备台账记录（含退货截止日、保管人、处置结果）、评估结论、退款或资产入账凭证
  • 状态依据：2026-03、2026-08～09 每次临时处理：买完才问能否七天无理由退货，回答是“得走一堆流程”；设备放在哪、研究完怎么处置都没有规定。

1. 场景判定

  • 触发条件：为对标调研、技术方案验证、兼容性测试需要一台短期使用的实机，预期使用期 ≤ 3 个月，且非交付库存。
  • 典型说法：「这玩意验证完就没用了」「能不能七天无理由」「走采购估计要 2 天」「走领用拿来看看」
  • 判断问题：这台设备验证完是否还会长期使用？有没有内部虚拟机、自建、借用可以替代？
  • 不归本流程管：长期使用的研发硬件 → 请走 ADM-24；借用公司已有测试机 → 请走 ADM-28；信创芯片测试机 → 请走 ADM-30；云服务/订阅 → 请走 ADM-34；新工具高权限试用环境 → 请走 X-SEC-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
采购与台账 评估替代方案、下单、登记退货期、到期提醒、处置执行 R IT采购/资产专员（当前：杨明学·推断待确认）
审批人 批准采购与处置方式 A CTO（当前：丁震宇·推断待确认）
需求方 说明用途、评估期、预算；评估结束给出结论 R 研发负责人（当前：王皓南·推断待确认）
产品 竞品调研场景提出需求、评估是否保留 C 产品负责人（当前：杨萌·推断待确认）
保管 设备存放、发放与回收 C 运维（当前：游家豪·推断待确认）
财务 退款入账或资产入账 I 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 用途说明：调研什么、验证什么问题
  • 预计评估期（起止日期）与使用人
  • 预算上限、是否接受二手/租赁
  • 已排查的替代方案（虚拟机、自建、借客户或合作方设备）
  • 购买渠道是否支持七天无理由退货，退货截止日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交调研设备需求，填用途、评估期、预算 需求方 需要使用前 3 个工作日 飞书审批（调研设备申请） 需求单 🔧飞书固化
2 判断能否用虚拟机/自建/借用替代 采购与台账 收到后 0.5 个工作日内 资产台账 替代建议 👤人工判断
3 确定方式：新品（优先可七天无理由）/ 二手 / 租赁 采购与台账 + 需求方 同上 — 采购方式 👤人工判断
4 审批（小额走快速通道） 审批人（CTO） 1 个工作日内 飞书审批 审批结论 🔧飞书固化
5 下单；到货后登记台账，标注退货截止日、评估截止日、保管人 采购与台账 审批后当日下单，到货当日登记 资产多维表格 台账记录 🔧飞书固化
6 使用人领用登记 保管 领用当日 领用审批 领用记录 🔧飞书固化
7 退货截止前 2 天、评估截止前 3 天自动提醒需求方 系统 自动 多维表格提醒 提醒消息 🤖自动化
8 需求方给出结论：保留 / 退货 / 转赠 / 出售 需求方 评估截止日前 台账 处置申请 👤人工判断
9 执行处置并更新台账；财务处理退款或资产入账 采购与台账 / 财务 结论后 3 个工作日内 台账、报销/入账 处置记录 🔧飞书固化

5. 交付物与模板

  • 交付物：调研设备台账记录、评估结论（1 段文字即可）、处置记录与财务凭证
  • 建议模板/表单（调研设备申请）：设备名称/型号、用途、需求人、使用人、评估起止日、预算、购买渠道、是否支持无理由退货、退货截止日、替代方案说明、处置方式、处置日期、存放位置

6. 异常与升级

  • 已过退货期仍未给结论 → 默认转入研发资产保留，台账标记“闲置待分配” → 通知 CTO（1 个工作日内）
  • 设备找不到 → 保管人 1 个工作日内核查 → 仍无下落升级综合部负责人，按 ADM-33 处理
  • 采购周期赶不上验证节点 → 先用自建/借用方案，采购并行；超预算 → CTO 当日确认
  • 转赠或抽奖送出 → 必须先清除数据，并走资产处置审批后再出库

7. 衡量指标

  • 退货期内结论率：在退货截止日前给出处置结论的设备占比，目标 ≥ 90%
  • 调研设备台账完整率：有用途、保管人、处置结果三项的记录占比，目标 100%
  • 需求到可用时长：提交需求到设备可用的工作日，目标 ≤ 3 天

8. 低效诊断

  • 现象：设备买完才讨论能否退货，错过退货窗口的风险高，退货流程不清｜依据：「Leap产研测」2026-08
  • 现象：调研设备存放位置不明，需要时在群里问设备在哪｜依据：「Leap产研测」2026-09
  • 现象：研究结束后处置方式靠口头提议（如抽奖送出），没有审批与台账｜依据：「Leap产研测」2026-08
  • 现象：小额验证设备走常规采购约需 2 天，为赶进度临时改用自建方案｜依据：「某存储设备厂商需求对接」2026-03

9. 分支变体

  • 保留研究：转为研发资产，按 ADM-27 入库
  • 退货：在无理由退货期内完成，财务处理退款
  • 转赠/抽奖/出售：须清数据、审批后出库，财务确认账务处理
  • 替代方案：自建（如黑某存储设备厂商）、借合作方/客户设备、虚拟机，不发生采购

10. 待确认问题

  • 小额调研设备快速通道的金额上限定为多少（[阈值待财务确认]）？是否可由 CTO 单签？
  • 调研设备的处置（转赠/抽奖/出售）是否需要财务参与审批？
  • 退货流程中“需要走的一堆流程”具体包括哪些环节，能否简化？
  • 是否在飞书审批中单独设“调研设备申请”，还是并入 ADM-24 的采购申请加一个“用途=调研”选项？
ADM-27IT设备到货验收、入库登记与调配变更待优化144

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：采购的服务器、CI 机、内存、主板、迷你主机、电脑及外设到货，或设备在员工之间换人使用、退回时，完成验收、资产编号入库、分配和资产表变更。
  • 负责人：主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、需求方/验收人（当前：宋祺睿·推断待确认）、行政（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 到货通知 → ② 打印/生成验收单 → ③ 需求方验收签字 → ④ 分库入库并编号 → ⑤ 领用/分配登记 → ⑥ 调配或退回时提变更 → ⑦ 更新资产表并归档
  • 交付结果：签字验收单、带资产编号的入库记录、领用/调配记录、账实一致的资产多维表格
  • 状态依据：已有资产管理多维表格（采购/资产/申领/报修）、实体资产领用审批和纸质验收单，但行政库与研发库边界不清，设备换人靠群里提醒“记得变更资产表”，资产记在谁名下存在争议，CI 机配件连续退换货约 3 次。

1. 场景判定

  • 触发条件：采购设备送达公司；设备由 A 转给 B 使用；员工退回设备；闲置设备回收后再分配。
  • 典型说法：「打印一份验收单给需求方，找人做个验收」「记得找 IT 变更资产表」「申领成功的资产会在清单里减少库存量」「看是行政入行政库，还是 IT 入研发库」
  • 判断问题：这件设备是否已到公司、需要建立或变更资产记录？是否有资产编号？
  • 不归本流程管：采购申请与审批 → 请走 ADM-24 / ADM-25；设备故障报修 → 请走 ADM-31；离职回收 → 请走 ADM-32；定期盘点与审计 → 请走 ADM-33；交付库存（待交付整机）→ 请走 X-DLV-03；行政办公用品申购 → 请走 ADM-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资产管理员 入库编号、资产表维护、调配变更、退换货跟踪 R IT资产管理员（当前：杨明学·推断待确认）
审批人 设备分配与调拨审批、资产归属争议裁定 A CTO（当前：丁震宇·推断待确认）
验收单执行 收货、打印验收单、组织验收、实物交接 R 运维（当前：游家豪·推断待确认）
验收人/使用人 核对配置、试机、签字 C 需求方研发（当前：宋祺睿·推断待确认）
行政库管理 显示器、大屏、家具类等行政资产入库 C 行政（当前：侯明月·推断待确认）
财务 资产入账、发票核对、审计盘库对接 I 财务负责人（当前：黄梦婷·推断待确认）
兜底 行政/研发库分界争议 I 综合部负责人

3. 办之前请准备

  • 对应的采购审批单号、订单号、发票
  • 送货单/装箱清单（含序列号）
  • 需求方及最终使用人、用途、存放位置
  • 资产分类：研发资产 / 行政资产（按本 SOP 第 9 节划分）
  • 调配时：原使用人、新使用人、调配原因、设备现状（含数据是否已清理）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收货，核对数量与外包装，在群内/台账标记“已到货” 验收单执行（运维） 到货当日 资产多维表格（采购表） 到货记录 🔧飞书固化
2 生成验收单（关联采购单号、序列号） 验收单执行（运维） 到货当日 电子验收单 验收单 🔧+🤖
3 需求方开箱核对配置、试机，签字验收；不合格标记退换 验收人 到货后 1 个工作日内 验收单 验收结论 👤人工判断
4 按分类入研发库或行政库，生成资产编号与二级编号，贴标 资产管理员 / 行政库管理 验收后 1 个工作日内 资产多维表格（资产表） 入库记录 🔧飞书固化
5 使用人提交领用申请，审批通过后自动扣库存、记使用人 验收人/使用人；审批人 领用当日 飞书审批（实体资产领用） 领用记录 🔧飞书固化
6 设备换人、退回：原使用人或新使用人提交调配申请 验收人/使用人（原使用人或新使用人） 实物交接前 飞书审批（资产调拨） 调配申请 🔧飞书固化
7 审批通过后实物交接，原使用人清理个人数据 验收人/使用人（原使用人）/ 验收单执行（运维） 审批后 2 个工作日内 — 交接确认 👤人工判断
8 审批结果自动回写资产表（使用人、位置、状态），资产管理员抽查回写结果 系统；资产管理员 自动；抽查每周 1 次 审批 → 多维表格 更新后的资产记录 🤖+👤
9 验收单、发票归档，月末与财务核对新增资产 资产管理员 / 财务 每月最后 1 个工作日 资产表、财务账 月度新增清单 🔧飞书固化

5. 交付物与模板

  • 交付物：签字验收单、入库记录（含编号）、领用/调配审批记录、月度新增资产清单
  • 建议模板/表单：
    • 电子验收单：采购单号、设备名称、型号/配置、序列号、数量、外观、开机测试结果、验收结论（合格/退换）、验收人、日期
    • 资产表字段：资产编号、二级编号、分类（研发/行政）、名称型号、序列号、采购日期、金额区间、发票号、使用人、存放位置、用途、状态（在库/在用/借出/维修/闲置/处置）、保修截止日
    • 调配申请：资产编号、原使用人、新使用人、原因、数据是否已清理、交接日期

6. 异常与升级

  • 验收不合格（主板、内存故障等）→ 2 个工作日内发起退换货，资产表状态记为“退换中” → 同一批次第 2 次故障升级 CTO 评估是否更换供应商
  • 资产该入哪个库有争议 → 按第 9 节划分；仍不明确由综合部负责人 1 个工作日内裁定
  • 设备已换人但未提调配申请 → 盘点或领用时发现，资产管理员 1 个工作日内补登记，并提醒双方
  • 采购审批仍在“审批中”设备已到货 → 可先验收暂存，审批通过后再入库分配

7. 衡量指标

  • 入库及时率：到货后 2 个工作日内完成验收入库的占比，目标 ≥ 95%
  • 账实一致率：盘点时资产表使用人/位置与实物一致的比例，目标 ≥ 98%
  • 调配登记率：设备换人后 2 个工作日内完成资产表变更的占比，目标 100%
  • 到货返修率：验收阶段退换货的批次占比（用于评价供应商）

8. 低效诊断

  • 现象：验收单需线下打印并找人签字，验收与入库割裂｜依据：「忠橙星行星引擎」2026-08
  • 现象：CI 机内存、主板到货后连续故障退换，退换状态无处跟踪｜依据：「忠橙星行星引擎」2026-09
  • 现象：资产管理与运行管理口径不同，资产应记在谁名下有争议｜依据：「忠橙星行星引擎」2026-08
  • 现象：设备换人只在群里口头同意，需另行提醒变更资产表；办公设备与个人设备未区分｜依据：「鼎慧产研决策部」2026-08
  • 现象：显示器、大屏等该入行政库还是研发库没有规则；手机端多维表格不便填写｜依据：「模态跃迁资产管理」2026-01

9. 分支变体

  • 研发资产（IT 入库）：服务器、CI 机、工作站、测试机、开发用电脑、内存/硬盘等配件
  • 行政资产（行政入库）：家具、办公用品、会议室显示器/大屏、键鼠垫等消耗型外设（建议：放会议室和公共区的归行政，个人使用或研发用的归 IT）
  • 演示设备：入研发库，外借按 ADM-29
  • 闲置设备（如平板）：回收到 IT 后标记“闲置”，再分配走第 5 步
  • 批量小件采购（如鼠标垫）：可按批次入库、不逐件编号
  • 员工自带电脑：不入资产表，但须登记用于办公的设备清单（与 X-SEC-31 协同）

10. 待确认问题

  • 行政库与研发库的划分规则（第 9 节建议）是否认可？
  • 是否把纸质验收单改为电子验收单，并由审批流自动生成？
  • 资产调拨是否新增独立审批，还是复用“实体资产领用”审批？
  • 多少金额以下的配件不单独编号？
  • 与财务的月度资产对账是否可行，由谁发起？
ADM-28内部测试设备与资源借用登记待新建96

状态：待新建｜证据：有证据（卡片 7 张 / 会话 4 个）｜优先级：频4 × 耗2 × 跨4 × 险3

  • 适用场景：研发、测试、交付需要借用公司闲置测试机、Mac mini、Windows 机、平板、录音卡、iPhone/iPad 真机、移动硬盘/U 盘/光盘等交付介质时，查台账、登记借用、按期归还。
  • 负责人：主责——IT资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、后端/运维（当前：宋祺睿·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 查测试设备台账 → ② 提交借用登记 → ③ 确认/审批 → ④ 领取并记录配件 → ⑤ 到期提醒 → ⑥ 归还验收、清数据 → ⑦ 台账回写；无库存时转采购
  • 交付结果：实时可查的测试设备与交付介质台账、每次借用/归还记录、按需补充的安全库存
  • 状态依据：2026-03～10 每次都在群里喊“谁有闲置 Mac mini”“硬盘被其他项目组借走了”“.117 谁在用”，无借用台账；交付介质被占导致部署方反复催办，测试真机系统升级后无替代机。

1. 场景判定

  • 触发条件：需要一台物理测试设备或存储介质短期使用（≤ 30 天），且设备属于公司；或发现某台测试设备不知道在谁手里。
  • 典型说法：「有人有闲置的 Mac mini 嘛」「来 905 二楼领用一下」「俩硬盘都被其他项目组借用走了」「谁手头还有 mini 测试机，借研发测下代码」「别拿会议室的残次品，资产不好管理」
  • 判断问题：要的是公司已有的实物设备/介质吗？是短期借用，还是要长期配发？
  • 不归本流程管：内网测试服务器、GPU、PVE 虚拟机、SSH 开通 → 请走 X-SEC-17；测试环境地址与管理员账号 → 请走 X-SEC-09；付费测试资源（云虚拟机、AI 套餐）→ 请走 ADM-34 / X-SEC-14；长期配发 → 请走 ADM-27；样机对外借用 → 请走 ADM-29；信创厂商借机 → 请走 ADM-30；行政公共物品（工具、吸尘器）→ 请走 ADM-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账管理 维护测试设备与介质台账、确认借用、到期催还、安全库存补采 R IT资产管理员（当前：杨明学·推断待确认）
实物保管 发放、回收、检查配件与数据清理 R 运维（当前：游家豪·推断待确认）
审批人 超期借用、新购测试机、优先级冲突裁定 A CTO（当前：丁震宇·推断待确认）
测试侧代表 提出测试设备清单需求（Mac/Win/iOS/Android 等） C 测试负责人（当前：张东郅·推断待确认）
产研侧代表 研发/产品借用需求汇总，规定测试领新卡等规则 C 产品总监（当前：杨萌·推断待确认）
账号协同 测试设备上的测试服账号交接（按 X-SEC-09） C 后端/运维（当前：宋祺睿·推断待确认）
借用人 按期归还、保管配件 R 申请人

3. 办之前请准备

  • 需要的设备类型和系统版本（如 macOS/Windows/iOS 某版本、容量 ≥ 1TB 的移动固态）
  • 用途与关联项目/工单号
  • 借用起止日期（默认 ≤ 14 天）
  • 交付介质：拷贝内容（是否含客户部署包）、目的地
  • 本人在台账中是否还有逾期未还的设备

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在测试设备台账中查可借设备，不再在群里喊人 借用人 需要前 1 个工作日 多维表格（测试设备台账） 候选设备 🔧飞书固化
2 提交借用登记：设备编号、用途、起止日期 借用人 同上 多维表格表单 借用申请 🔧飞书固化
3 确认可借；≤ 14 天直接确认，> 14 天或冲突时 CTO 审批 台账管理 / 审批人（CTO） 0.5 个工作日内 飞书审批 确认结果 🔧+👤
4 领取，当面核对配件（电源、线、盒子），台账记“借出” 实物保管 + 借用人 确认后当日 台账 借出记录 🔧飞书固化
5 到期前 1 天机器人提醒；逾期每日提醒并抄送台账管理 系统 自动 多维表格自动化 提醒消息 🤖自动化
6 归还：清理个人数据和客户数据，核对配件，台账记“在库” 借用人 + 实物保管 到期当日 台账 归还记录 👤人工判断
7 无可借设备时，评估改用虚拟机/旧设备，或转采购 台账管理 1 个工作日内 ADM-24 / ADM-34 处理方案 👤人工判断
8 交付介质低于安全库存（建议 ≥ 3 块编号专用盘）时发起补采 台账管理 发现当日 飞书审批 采购申请 🔧飞书固化
9 每月核对一次台账与实物，清查“不明归属”设备 台账管理 每月第 1 个工作日 台账 核对记录 🔧+🤖

5. 交付物与模板

  • 交付物：测试设备与交付介质台账、借用/归还记录、月度核对记录
  • 建议模板/表单：
    • 台账字段：设备编号、类型（Mac mini/Win 机/平板/真机/录音卡/移动固态/U 盘/光驱）、型号与系统版本、配件清单、存放位置、状态（在库/借出/维修/报废）、当前借用人、借出日、应还日、关联项目、备注
    • 借用登记表：设备编号、借用人、用途、项目/工单号、起止日期、是否含客户数据、归还时数据是否已清理

6. 异常与升级

  • 同一设备多方争用 → 按交付 > 客户问题修复 > 测试 > 调研排序 → 争议由 CTO 0.5 个工作日内裁定
  • 交付介质被占用且现场部署赶时间 → 立即电商/同城采购，事后补审批 → 台账管理当日完成
  • 逾期 3 个工作日未还 → 抄送借用人直属上级；逾期 7 天升级综合部负责人
  • 发现不明归属设备 → 在台账登记“待认领”，群内通知 2 个工作日认领；无人认领回收入库
  • 测试真机系统升级后无法测试 → 测试负责人 1 个工作日内提出新真机需求，走 ADM-24
  • 介质含客户部署包 → 归还时必须清空，丢失按安全事件处理（X-SEC-42）

7. 衡量指标

  • 借用登记率：实际借出设备中有登记记录的占比，目标 100%
  • 按期归还率：在应还日前归还的借用次数占比，目标 ≥ 90%
  • 群内找设备次数：每月在群里询问“谁有/谁在用”的次数，目标逐月下降至 ≤ 2 次
  • 交付介质缺货次数：因无盘导致部署延误的次数，目标 0

8. 低效诊断

  • 现象：领用 Mac mini、键鼠靠口头指定楼层位置，设备“有点难找”，归属无登记｜依据：「Leap产研测」2026-05
  • 现象：反复在群里喊谁有闲置设备，测试机 ssh 账号遗忘后需重新创建｜依据：「Leap产研测」2026-07
  • 现象：测试人员使用会议室淘汰的录音卡，资产混用｜依据：「Leap产研测」2026-09
  • 现象：内网机器不知道谁在用，靠公钥备注、照片辨认｜依据：「Leap产研测」2026-10
  • 现象：oncall 专用设备、测试真机临时拼凑，没有设备池｜依据：「Leap产研决策部」2026-09
  • 现象：测试要 Mac 真机、付费账号每次在群里问，报销口径不明｜依据：「LeapAll（Deprecated）」2026-04
  • 现象：交付用移动硬盘被其他项目组借走，部署方多次催办；临时外采补位｜依据：「跃迁基座项目交付沟通」2026-03、「跃迁基座项目交付沟通」2026-04

9. 分支变体

  • 测试机/Mac mini/Windows 机：借期 ≤ 14 天；Mac 打包机建议固定专用，不外借
  • oncall 专用手机/平板：设固定设备池，交接班时转交并登记
  • 测试真机（iPhone/iPad）：至少保留一台不升级系统的版本机
  • 录音卡等测试耗材：测试一律领新品，不得挪用会议室设备
  • 交付介质（移动固态/U 盘/光盘）：编号专用、安全库存 ≥ 3 块，归还必须清空
  • 物理机/虚拟机/内网机器归属核查：按 X-SEC-17 登记 IP 与负责人

10. 待确认问题

  • 测试设备台账由 IT 统一维护，还是测试负责人维护测试侧子表？
  • 默认借期 14 天、交付介质安全库存 3 块是否合适？
  • 设备争用优先级排序是否认可？
  • oncall 设备与测试真机是否需要新购？预算由哪个部门承担？
  • 交付介质出公司是否需要额外审批（含客户部署包）？
ADM-29样机/设备外借（销售演示、展会、客户现场应急）待优化180

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：销售/市场需要借 LeapCore 样机或其他设备用于客户演示、渠道/经销商试用、展会，或政府等客户现场应急需要终端时，完成借用审批、出库登记（含配件清单）和归还入账。
  • 负责人：主责——IT资产/样机管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、销售（当前：杨朋伟·推断待确认）、产品总监（当前：杨萌·推断待确认）；审批——市场销售负责人（当前：李鹏为·推断待确认），特殊情形加签 COO（当前：常元和·推断待确认）；兜底——综合部负责人
  • 核心流程：① 提前 1～3 天确认样机存量 → ② 提交样机借用审批 → ③ 按常规/特殊分级审批 → ④ 出库登记配件并拍照 → ⑤ 领取或邮寄 → ⑥ 到期提醒 → ⑦ 归还核对配件并入账
  • 交付结果：已审批的借用单、含配件清单和照片的出库/归还记录、样机台账状态更新
  • 状态依据：2026-07 已发布《LeapCore 样机借用 SOP（2026.7 第一版）》和飞书“LeapCore 样机借用审批”，覆盖渠道、经销商、展会；但样机库存紧张导致无法及时交付，应急借用靠事后补审批，客户现场应急没有覆盖，2026-06 发生过外借设备配件丢失影响交付。

1. 场景判定

  • 触发条件：销售、市场、渠道需要把公司样机或设备带出公司（演示、试用、展会、客户现场应急）。
  • 典型说法：「以后样机借用和合同盖章一样，需要走审批流」「走流程之前，先找 IT 问一下样机情况」「一定要快」「明天走下流程，就可以出」「以后借走的设备要入账了」
  • 判断问题：设备是否要离开公司、交给外部或在外部场所使用？使用方是否为销售/市场/渠道？
  • 不归本流程管：内部研发测试借用 → 请走 ADM-28；给客户的正式交付发货 → 请走 X-DLV-13 / ADM-16；客户/渠道索要 root 与远程接入 → 请走 X-SEC-07；大会现场网络与设备保障 → 请走 X-SEC-32；样机采购补货 → 请走 ADM-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
样机管理 存量答复、出库登记、归还验收、台账维护 R IT资产/样机管理员（当前：杨明学·推断待确认）
出库执行 装箱、配件核对拍照、邮寄、现场部署 R 运维（当前：游家豪·推断待确认）
审批人 常规借用审批；客户应急是否出借 A 市场销售负责人（当前：李鹏为·推断待确认）
特殊加签 >3 天或需展示带系统样机 C COO（当前：常元和·推断待确认）/ 产品总监（当前：杨萌·推断待确认）
SOP 维护 维护样机借用 SOP 与审批表单 C 销售运营（当前：韩诗琪·推断待确认）
申请人 提交申请、保管、按期归还 R 销售（当前：杨朋伟·推断待确认）等申请销售

3. 办之前请准备

  • 用途（演示/渠道试用/经销商/展会/客户应急）、客户或展会名称（内部可写全称，对外沟通脱敏）
  • 需要的型号、数量、是否需预装系统和演示数据
  • 借用起止日期、取件方式（自取/邮寄）与收件地址
  • 客户应急：现场终端芯片/操作系统、数量、上线时间
  • 本人名下是否有未归还样机

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 向样机管理确认存量（或查样机台账） 申请人 使用前 1～3 个工作日 样机台账 可借型号 🔧飞书固化
2 提交“LeapCore 样机借用审批”，填申请人、时间、型号、用途 申请人 同上 飞书审批 借用单 🔧飞书固化
3 常规（≤3 天且无系统展示）：市场销售负责人 → 样机管理；特殊（>3 天或需带系统展示）：加签 COO/产品总监 审批人 1 个工作日内 飞书审批 审批结论 🔧+👤
4 审批通过自动通知样机管理，台账扣减；样机管理核对型号与存量后确认出库 系统；样机管理 自动；确认当日 审批 → 多维表格 台账“借出” 🤖+👤
5 出库：按配件清单核对（主机、电源、适配器、线材、包装盒），拍照留档 出库执行 领取当日 出库单 出库记录+照片 🔧飞书固化
6 自取或邮寄（邮寄按 ADM-16） 出库执行 审批后 1 个工作日内 快递月结 运单号 🔧飞书固化
7 到期前 1 天提醒申请人；逾期每日提醒 系统 自动 机器人 提醒 🤖自动化
8 归还：按出库清单逐项核对配件、拍照、检查系统与数据 出库执行 + 申请人 到期当日 归还单 归还记录 👤人工判断
9 台账回写“在库”，缺件登记并追责 样机管理 归还当日 样机台账 闭环记录 🔧飞书固化

5. 交付物与模板

  • 交付物：借用审批单、出库/归还记录（含照片）、样机台账
  • 建议模板/表单：
    • 样机台账：编号、型号、系统版本、配件清单、状态（在库/借出/维修/应急占用）、借用人、用途、借出日、应还日、位置
    • 出库/归还单：编号、配件逐项勾选（主机、电源、适配器、线材、包装盒、外设）、出库照片、归还照片、缺件说明、经办人
    • 客户应急设备包标准清单：终端（Windows/信创）、预装 LeapCore、网络配置说明、配件

6. 异常与升级

  • 样机库存不足 → 样机管理当日告知并给出可用日期 → 影响签单的，升级市场销售负责人协调优先级或启动 ADM-25 补货
  • 紧急借用来不及审批 → 市场销售负责人群内确认后先出库，24 小时内补审批；未补审批的不得再次借用
  • 客户现场应急（政府客户等）→ 销售当日提交，审批人 4 小时内确认是否出借及是否改用非信创终端；IT 评估库存或新购，次日出库
  • 归还缺件/损坏 → 当日登记，借用人 2 个工作日内找回；无法找回按 ADM-31 设备报损处理
  • 逾期 3 天未还 → 抄送审批人；逾期 7 天升级综合部负责人

7. 衡量指标

  • 审批覆盖率：外借出库中有审批记录的占比（含 24 小时内补审批），目标 100%
  • 配件完整归还率：归还时配件齐全的次数占比，目标 ≥ 98%
  • 样机可用率：申请当天有可借样机的比例，目标 ≥ 90%
  • 应急响应时长：客户应急需求提出到设备出库，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：审批流上线前样机借用无规则，SOP 发布后应急场景仍要事后补审批，特殊场景加签周期更长｜依据：「【模态】市场销售」2026-07
  • 现象：样机库存紧张，申请时才发现没有可借或可交付的机型｜依据：「【模态】市场销售」2026-08
  • 现象：客户现场应急需求临时提出，现场部署由谁负责、用什么终端在群里反复讨论｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-08
  • 现象：设备借到外部场所后电源、包装盒丢失，约 10 条消息追问下落，用闪送找回，期间交付受影响｜依据：「Leap产研测」2026-06

9. 分支变体

  • 渠道/经销商试用：按现行 SOP，试用期满前 3 天销售确认是否转采购
  • 展会：借用期含布展/撤展日，出库与归还均由出库执行人现场清点
  • 政府客户现场应急：可改用 Windows 终端先行上线（人工判断是否非信创），需要时派运维到现场调研芯片/OS/数量
  • 借给外部办公室或合作方使用：一律走本流程并拍照入账

10. 待确认问题

  • 现行《LeapCore 样机借用 SOP（2026.7 第一版）》是否扩展到“其他设备外借”和“客户现场应急”？
  • 应急 24 小时补审批的规则是否认可？
  • 样机台账由 IT 还是销售运营维护？审批通过后能否自动写入台账？
  • 样机安全库存按每个主力机型几台设定？
  • 外借配件丢失的赔偿口径是否与 ADM-31 的设备报损规则统一？
ADM-30信创测试机申请与厂商借机/归还待优化300

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：信创适配或测试缺少海光/飞腾/鲲鹏/龙芯/兆芯等芯片或对应操作系统的实体机、虚拟机、构建服务器时，提需求审批，按内部资源、厂商借机、云租赁、采购四条路径获取，验收入库交测试，到期归还或转长期。
  • 负责人：主责——IT资源/资产管理员（当前：杨明学·推断待确认）；协同——信创适配负责人（当前：李子遥·推断待确认）、运维（当前：游家豪·推断待确认）、渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、测试（当前：潘浩伟·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；审批——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 提交配置需求 → ② 审批并定路径（内部/借用/云/采购）→ ③ 指定到位日期与负责人 → ④ 获取资源（组装/开账号/向厂商借/采购）→ ⑤ 验收入库、交测试 → ⑥ 占用与转借登记 → ⑦ 到期归还或转长期
  • 交付结果：可用的信创测试/构建环境、信创设备借用台账（来源、位置、保管人、归还日）、按期归还记录
  • 状态依据：已有飞书审批表单，但审批结束后申请人看不到结果，路径不清，2026-07～10 群内“机子呢”“修了吗我真急了”类催办约 15 次；ARM 构建机从提出到到位约两个月，厂商测试机从申请到交测试约 5 周，10 月厂商突然通知全部收回。

1. 场景判定

  • 触发条件：适配、打包、测试需要特定芯片架构（x86 海光/兆芯、aarch64 飞腾/鲲鹏、龙芯）或指定国产 OS 的环境，而内部没有可用资源。
  • 典型说法：「机子呢」「审批挂个申请先」「还是得买一台长期用」「飞腾的机子啥时候到位」「你先验收检查下再给测试」「已经确定全部要收回」
  • 判断问题：缺的是不是“特定芯片/OS 组合”？内部现有设备、PVE、云资源能否满足？
  • 不归本流程管：普通 x86 内网测试机/虚拟机 → 请走 X-SEC-17；云服务器开通 → 请走 X-SEC-16；客户现场应急终端 → 请走 ADM-29；一般测试设备借用 → 请走 ADM-28；长期采购审批 → 请走 ADM-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资源负责人 评估路径、组装/PVE/云账号、采购、维护信创设备台账、归还收口 R IT资源/资产管理员（当前：杨明学·推断待确认）
审批人 审批需求与路径（采购 vs 借用）、设定优先级 A CTO（当前：丁震宇·推断待确认）
需求方 提交配置要求、到位后确认可用 R 信创适配负责人（当前：李子遥·推断待确认）
厂商对接 向芯片/OS 厂商、合作方申请借机或线上资源并跟进 R 渠道负责人（当前：闫登辉·推断待确认）
厂商关系升级 对接人催办无果时出面协调 C 市场销售负责人（当前：李鹏为·推断待确认）
收货验收 收货、验收、入库、交接给测试 R 运维（当前：游家豪·推断待确认）
占用方 测试使用、归还前备份数据 C 测试（当前：潘浩伟·推断待确认）
财务 采购/云费用确认 I 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 配置要求：芯片型号、架构（x86/aarch64/loongarch）、OS 及版本、核数/内存/磁盘、是否需 PVE 或图形界面
  • 用途：构建/打包、功能测试、出适配证明，预计使用时长
  • 需要到位的最晚日期及阻塞的工作项
  • 可接受的替代方案（云、远程虚拟机、借用）
  • 是否需对外出具适配证明（影响是否必须实体机）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“信创测试资源申请”，填配置、用途、最晚到位日 需求方 内部/云路径：需要前至少 5 个工作日；厂商借机或采购路径：需要前至少 15 个工作日（步骤 2、3 共 2 个工作日 + 借机/采购到位 ≤ 10 个工作日 + 验收交接 1 个工作日） 飞书审批 申请单 🔧飞书固化
2 资源负责人查台账与 PVE/云余量，给出路径建议与预计到位日 资源负责人 1 个工作日内 信创设备台账 路径建议 👤人工判断
3 审批路径与优先级；结果自动推送需求方与项目群 审批人（CTO）/ 系统 1 个工作日内 飞书审批 + 群机器人 审批结论 🔧+🤖+👤
4a 内部路径：组装/开 PVE 虚拟机/开子账号 资源负责人 3 个工作日内 PVE 可用环境 👤人工判断
4b 厂商借机：联系厂商申请，每 3 个工作日更新一次进度；5 个工作日无回复升级 厂商对接 申请后 10 个工作日内到位 台账进度字段 借机确认 👤人工判断
4c 云租赁：开通并记录额度与到期日 资源负责人 2 个工作日内 云控制台（X-SEC-16） 云资源 🔧飞书固化
4d 采购：走 ADM-24，与财务确认开票 资源负责人 审批通过后 1 个工作日内提交采购申请；到位 ≤ 10 个工作日 飞书审批 采购单 🔧飞书固化
5 实体机到货：验收（开机、芯片/OS 核对）、入库、登记位置与保管人，交接给测试 收货验收 到货当日 信创设备台账 验收入库记录 🔧飞书固化
6 需求方确认可用，台账状态改“使用中”；转借他人需登记 需求方 交接当日 台账 使用记录 🔧飞书固化
7 云资源到期前 7 天、借机归还日前 7 天自动提醒；评估是否转长期 系统 / 资源负责人 自动 多维表格提醒 续期/转购决定 🤖+👤
8 归还：通知占用方 2 个工作日内备份数据，清除数据后寄回，台账记“已归还” 资源负责人 / 收货验收 厂商通知后 3 个工作日内 台账、快递 归还记录 🔧飞书固化

5. 交付物与模板

  • 交付物：信创测试资源申请单、信创设备台账、验收记录、归还记录
  • 建议模板/表单：
    • 信创设备台账：编号、芯片/架构、OS 版本、来源（自购/厂商借/云/客户现场）、来源方、配置、当前位置、保管人、当前使用人、状态（申请中/在途/使用中/归还中/已归还）、预计到位日、到期/归还日、负责人、最近进度更新日
    • 设备管理员账号不得写入台账或群聊，按 X-SEC-10 存密码管理器

6. 异常与升级

  • 超过预计到位日 2 个工作日 → 机器人提醒负责人；超过 5 个工作日 → 升级 CTO 重新定路径（借用改云或采购）
  • 厂商对接 5 个工作日无回复 → 市场销售负责人出面协调
  • 云资源额度将尽 → 到期前 7 天评估“转购一台长期用”，CTO 3 个工作日内决定
  • 同一台信创机多方抢用（测试 vs 出适配证明）→ CTO 按对外承诺优先级裁定，当日完成
  • 设备故障 → 资源负责人 1 个工作日内给出修复或替代方案，按 ADM-31 报修
  • 厂商突然要求收回 → 当日通知占用方备份，评估替代资源，避免测试中断

7. 衡量指标

  • 资源到位周期：审批通过到需求方确认可用的工作日，内部/云 ≤ 3 天，厂商借机 ≤ 10 天，采购 ≤ 10 天
  • 申请提前量达标率：按路径提前量（内部/云 ≥ 5 个工作日，厂商借机/采购 ≥ 15 个工作日）提交申请的占比，目标 ≥ 80%
  • 按期到位率：在预计到位日前到位的申请占比，目标 ≥ 80%
  • 催办次数：每个申请在群内被催问的次数，目标 ≤ 1 次
  • 借机台账完整率：外部借入设备有位置、保管人、归还日记录的占比，目标 100%

8. 低效诊断

  • 现象：研发到岗后无信创机器可用，群内多次追问“机子呢”｜依据：「信创LeapCore客户端适配」2026-07
  • 现象：审批表单结束后申请人看不到提示，不知道审批结果和后续｜依据：「信创LeapCore客户端适配」2026-07
  • 现象：临时云资源额度用尽后才讨论是否长期采购｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-09
  • 现象：厂商借机需领导多次出面催，从申请到交测试约 5 周｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-08
  • 现象：机器“在谁桌上、是否已验收”无记录，靠桌面转手｜依据：「信创LeapCore客户端适配」2026-08
  • 现象：设备故障修复与 PVE 搭建没有时限，需求方反复催｜依据：「信创LeapCore客户端适配」2026-08、「信创LeapCore客户端适配」2026-09
  • 现象：厂商一次性通知全部收回，测试数据需临时备份｜依据：「信创LeapCore客户端适配」2026-10

9. 分支变体

  • 内部组装/PVE 虚拟机/子账号：最快，优先选择
  • 厂商借机（芯片厂商、整机厂商、合作方）：实体机或远程虚拟机；需登记归还条件
  • 云租赁（如云厂商 ARM 实例）：注意额度上限与到期
  • 长期采购：使用期预计 > 3 个月或需反复出适配证明时优先
  • 客户现场借用：只用于现场验证，不带回数据

10. 待确认问题

  • 信创资源的唯一主责是 IT，还是信创适配负责人自管、IT 只做执行？
  • 厂商借机的对接人是否固定为渠道负责人？
  • “预计使用 > 3 个月即采购”的规则是否认可？预算归研发还是市场？
  • 现有审批表单能否增加“结果推送到项目群”？
  • 需对外出适配证明时是否必须用实体机？
  • 按路径区分的申请提前量（内部/云 5 个工作日、厂商借机/采购 15 个工作日）是否可行？
ADM-31IT设备故障报修待优化54

状态：待优化｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨3 × 险3

  • 适用场景：显示器、键盘、笔记本、mini PC、移动硬盘等 IT 设备出现故障或人为损坏时，统一报修登记，完成排障、维修或更换，必要时判定赔偿，并把退役/闲置设备回收再分配或处置；电脑、服务器、硬盘、U 盘、手机、测试机、客户退回的一体机等设备报废、出售、转赠、退租或返厂维修前，完成数据清除与资产注销。
  • 负责人：主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——运维（当前：游家豪·推断待确认）、CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CTO（当前：丁震宇·推断待确认，审批）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交“设备维修”审批 → ② 远程/现场初步排查 → ③ 定级（换配件/送修/换新）→ ④ 维修或更换 → ⑤ 判定是否人为损坏 → ⑥ 验收交还并更新台账 → ⑦ 退役设备鉴定回收 → ⑧ 数据清除或物理销毁 → ⑨ 处置审批与执行 → ⑩ 资产注销与财务核销
  • 交付结果：报修工单闭环记录、修复或替换后的设备、更新后的资产台账（含维修记录）、需要时的报损与赔偿判定记录；处置设备的数据清除记录（含序列号）、处置凭证与资产注销记录
  • 状态依据：2026-05 已建飞书审批“设备维修”，但当时仍在内测、未发公告，员工“找不到报修表单”；排障靠反复换线，保修入口不清；人为损坏已发生 2 次，赔偿口径只有口头意见。

1. 场景判定

  • 触发条件：员工使用的 IT 设备（电脑、显示器、键鼠、mini PC、移动硬盘/U 盘）出现故障；设备进水、跌落等损坏；设备退役需处理；设备损坏无法维修或长期闲置无使用价值需报废；设备拟出售、转赠、退租、返厂；客户退回设备需清除数据。
  • 典型说法：「这台显示器按故障报」「报修」「表单哪个，我找不到」「填一下试试，审批里面刷新一下」「员工设备人为损坏怎么处理」
  • 判断问题：坏的是不是 IT 设备（而不是空调、门锁、网络）？是否影响当前工作？设备离开公司或报废前，是否有存储介质、是否曾存放代码、密钥或客户数据？
  • 不归本流程管：空调、门锁、灯具、插座等办公设施 → 请走 ADM-08；网络/WiFi 故障 → 请走 X-SEC-27；服务器/机房故障 → 请走 X-SEC-29；软件安装、新电脑初始化 → 请走 X-SEC-30；云资源、域名等非实体资产申请 → 请走 ADM-34；盘点中发现闲置 → 请走 ADM-33；离职回收 → 请走 ADM-32；交付硬件返修 → 请走 X-CS-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
报修受理 维护报修入口、派单、定级、台账记录、保修管理 R IT运维/资产管理员（当前：杨明学·推断待确认）
维修执行 现场排障、换线换件、送修、交还 R 运维（当前：游家豪·推断待确认）
审批人 换新、外修费用、闲置/报废设备处置审批 A CTO（当前：丁震宇·推断待确认）
行政资产协同 行政类资产报废处置的申请与凭证留存，参与处置方式确认 C 行政负责人（当前：胡则瑾·推断待确认）
法务 返厂需带盘且含客户数据时评估数据风险 C 法务负责人（当前：李瑶·推断待确认）
赔偿口径制定 人为损坏赔偿规则拍板 C CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）
人事复核 赔偿判定与员工沟通、制度合规 C 人事负责人（当前：黄莹·推断待确认）
财务 维修费用、处置收入入账、资产核销 C 财务负责人（当前：黄梦婷·推断待确认）
报修人 描述故障、配合排查、备份数据 R 申请人

3. 办之前请准备

  • 资产编号（设备标签上）、型号
  • 故障现象、出现时间、是否可复现，照片或短视频
  • 是否已自行尝试重启、换线、换接口
  • 是否为人为损坏（进水、跌落），发生经过
  • 送修前备份个人与工作数据
  • 报废/处置：资产编号、序列号、原使用人、拟处置方式（回收商、转赠、退租、返厂）、设备是否含客户数据或涉密数据的说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“设备维修”审批（群公告置顶入口；群内发“报修”机器人回复链接） 报修人 发现故障当日 飞书审批 + 机器人 报修单 🔧+🤖+👤
2 受理并派单，按排障知识库远程指导或现场排查（换线、换口、换屏验证） 报修受理 / 维修执行 受理 4 个工作小时内，影响工作的 2 小时内 排障知识库 初步结论 👤人工判断
3 定级：换配件 / 保修送修 / 外修 / 换新；提供备用机 报修受理 排查后 1 个工作日内 资产台账（保修截止日） 处理方案 👤人工判断
4 换新或外修费用超阈值时审批 审批人（CTO） 1 个工作日内 飞书审批 审批结论 🔧飞书固化
5 执行维修/换新，跟踪送修进度 维修执行 换件 1 个工作日；送修按服务商时限 报修表 修复设备 👤人工判断
6 人为损坏：报修人提交“设备报损”（照片、经过），人事复核责任 报修人 / 人事复核 报损后 3 个工作日内 飞书审批 责任判定 👤人工判断
7 交还设备，报修人确认，工单关闭，台账记维修记录 维修执行 / 报修人 修复当日 资产台账 闭环记录 🔧+🤖
8 无法修复或退役：技术鉴定存储介质与数据类型，回收并标记“闲置/待处置” 报修受理 / 维修执行 结论后 3 个工作日内 资产台账 鉴定意见、回收记录 👤人工判断
9 提交处置申请（再分配/出售/转赠/退租/返厂/报废），审批处置方式 报修受理；审批人（CTO） 每月集中处理 1 次，审批 2 个工作日内 飞书审批 处置审批单 🔧飞书固化
10 离开公司或报废前清除数据（多次覆写/加密擦除）；无法擦除的拆盘物理销毁；拍照记录序列号与清除结果 维修执行 处置前完成，清除当日登记 擦除工具、飞书表单 数据清除记录 🤖+👤
11 执行处置并取得回收/转赠/退租凭证 报修受理 审批后 10 个工作日内 线下 处置凭证 👤人工判断
12 资产台账注销，财务核销并处理处置收入 报修受理 / 财务 处置后 5 个工作日内 资产台账、财务系统 注销记录 🔧飞书固化

5. 交付物与模板

  • 交付物：报修单、维修记录、报损与责任判定记录、处置审批单、数据清除记录、处置凭证、台账注销记录
  • 建议模板/表单：
    • 设备维修：资产编号、设备类型、故障描述、照片、紧急程度、是否需要备用机、是否人为损坏、处理方式、费用、完成日期、报修人确认
    • 设备报损：资产编号、损坏经过、照片、首次/再次、责任判定（意外/主观）、承担方式、人事复核意见
    • 排障知识库：显示器闪断（先换线/换口）、键盘按键失灵、笔记本静电/无法开机、移动硬盘无法识别等常见处理步骤
    • 数据清除记录：资产编号、序列号、介质类型、数据类型（代码/密钥/客户数据/个人数据）、清除方式（覆写/加密擦除/物理销毁）、执行人、执行日期、照片

6. 异常与升级

  • 影响工作且 1 个工作日内修不好 → 先提供备用机；无备用机升级 CTO 决定是否紧急采购
  • 同一设备 30 天内重复报修 2 次 → 直接走换新评估
  • 人为损坏 → 按口头口径执行前需人事复核，口径成文前不直接扣款；有争议升级 CEO/COO
  • 处置的设备含数据 → 运维确认数据已清除后才能出售/转赠/寄出
  • 保修入口不明 → 报修受理 1 个工作日内在台账补全保修信息
  • 硬盘无法开机、无法擦除 → 拆盘物理销毁，不得返厂或出售 → 维修执行当周内完成并登记
  • 返厂维修必须带盘 → 先评估数据风险；含客户数据的由法务 2 个工作日内确认能否返厂
  • 客户退回的一体机 → 清除前先确认是否需要按合同把客户数据返还客户 → 交付或销售负责人当日确认

7. 衡量指标

  • 首次响应时长：报修提交到受理的工作小时数，目标 ≤ 4 小时
  • 修复周期：报修到交还的工作日，换件 ≤ 1 天，送修 ≤ 10 天
  • 报修入口使用率：通过审批报修的占全部故障反馈的比例，目标 ≥ 90%
  • 重复报修率：30 天内同一设备再次报修的占比，目标 ≤ 10%
  • 处置前数据清除率 = 有清除记录的处置设备 / 处置设备总数，目标 100%
  • 台账注销及时率：处置后 5 个工作日内完成注销的比例，目标 100%

8. 低效诊断

  • 现象：显示器问题反复换线排查，保修入口不明，最终才按故障报修｜依据：「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-08
  • 现象：员工被告知“报修”后找不到报修表单｜依据：「鸽子群模态分群」2026-04
  • 现象：报修与非实体资产审批已搭建但未发公告，靠群里提示才知道入口｜依据：「鸽子群模态分群」2026-05
  • 现象：新到设备和闲置设备在群里被口头认领、出售，去向无记录；寄出前才提醒清个人数据｜依据：「鸽子群模态分群」2026-03、「鸽子群模态分群」2026-04
  • 现象：人为损坏无成文赔偿标准，已遇 2 次逐案讨论｜依据：「忠橙星行星引擎」2026-07
  • 现象：设备报废、出售、返厂前没有数据清除与资产注销规则，存在代码、密钥、客户数据随旧设备流出及账实不符的风险｜依据：（推断）

9. 分支变体

  • 显示器/线缆：先换线换口，确认后按故障报
  • 键盘/鼠标等低值外设：直接以旧换新，不送修
  • 笔记本/mini PC：优先走厂商保修，期间提供备用机
  • 移动硬盘/U 盘：先尝试数据恢复，再报废
  • 人为损坏（口头口径，待成文）：意外首次由公司承担；再次及主观损坏由个人承担部分或全部维修费，具体须写入《办公设备管理办法》并经人事合规复核
  • 退役/闲置设备：再分配（走 ADM-27）、出售或销毁
  • 报废/出售/转赠：先走步骤 8～12，清除记录齐全后才能出库
  • 客户现场退回的一体机：清除前先确认是否需按合同返还客户数据
  • 租赁设备退租：按出租方要求清除数据后退还
  • 已合并原 ADM-37（IT 设备报废处置与存储介质数据清除）

10. 待确认问题

  • “设备维修”审批是否已正式公告？入口放在哪个群公告或工作台？
  • 换新/外修费用审批阈值是多少？
  • 人为损坏赔偿口径（首次公司承担、再次从奖金扣维修费）是否符合劳动法规？由人事出成文制度后再执行？
  • 闲置设备出售给员工或外部是否允许？定价与收款由谁负责？
  • 是否需要配置 2～3 台备用笔记本/显示器？
  • 设备报废与处置的审批人是 CTO（本条原口径）还是行政负责人（已合并的报废处置条目原口径）？是否按研发资产/行政资产分开审批？请管理层裁定
  • 是否有合作的回收商或数据销毁服务商？
  • 研发测试机与员工电脑的数据清除标准是否需要区分？
ADM-32离职/换机设备回收待优化72

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：员工（含实习生、外部合作者）离职、合作结束或更换设备时，按清单回收电脑、键鼠、充电线等公司资产，核对资产表并重新入库，同时联动账号收口。
  • 负责人：主责——IT运维/资产管理员（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、运维（当前：游家豪·推断待确认）；认定——CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 离职审批流转到运维节点/换机申请 → ② 按资产表生成回收清单 → ③ 约定回收时间 → ④ 逐项核对实物与编号 → ⑤ 数据清理与账号收口联动 → ⑥ 审批签字 → ⑦ 资产表回写并重新入库
  • 交付结果：逐项核对的回收清单、运维节点已审批的离职单、更新后的资产表（状态“在库/闲置”）
  • 状态依据：已有飞书离职审批含运维节点，人事会在群里通知回收；但 2026-10 出现“没收到离职流程但设备仍在外”的情况，非正式离职合作者、换机场景没有规则，快递寄回时设备编号对不上。

1. 场景判定

  • 触发条件：离职审批流转到运维节点；人事通知某人离职/合作结束；员工申请换机，旧设备需交回；外部合作者结束合作但未走离职流程。
  • 典型说法：「新来的同事办了离职，领取的设备安排回收下」「离职电脑要回收」「有几个离职流程到运维了，记得审批」「但是没收到离职」
  • 判断问题：此人名下资产表是否有设备？是否已经或即将不再使用这些设备？
  • 不归本流程管：离职手续整体办理与工作交接 → 请走 HR-27；账号与权限回收 → 请走 X-SEC-08；在职调配给他人 → 请走 ADM-27；设备故障更换 → 请走 ADM-31；外借样机归还 → 请走 ADM-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资产回收 生成回收清单、核对、审批运维节点、资产表回写 R IT运维/资产管理员（当前：杨明学·推断待确认）
回收执行 约时间、当面收回、检查外观与配件、清数据 R 运维（当前：游家豪·推断待确认）
离职发起 发起离职审批，通知运维，确认非正式人员“算离职” C 人事负责人（当前：黄莹·推断待确认）
认定人 非正式合作者是否回收、例外处理 A CTO（当前：丁震宇·推断待确认）
离职/换机人 备份并移交工作数据、交回设备 R 当事员工

3. 办之前请准备

  • 当事人姓名、部门、最后工作日（来自离职审批）
  • 资产表中其名下全部资产（电脑、显示器、键鼠、充电器、测试设备、借用中样机/介质）
  • 工作数据移交对象与方式（网盘/Agent 数据转移按 HR-27）
  • 远程人员：寄回地址、快递方式、装箱清单（含资产编号）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 离职审批流转到运维节点时自动创建回收任务；换机申请审批通过同样触发 系统；资产回收确认任务 自动；任务创建当日确认 飞书审批 → 飞书任务 回收任务 🔧+🤖+👤
2 从资产表拉出当事人名下资产，生成回收清单 资产回收 收到任务后 1 个工作日内 资产多维表格 回收清单 🤖自动化
3 与当事人约定回收时间（不晚于最后工作日） 回收执行 最后工作日前 2 个工作日 飞书消息 回收时间 👤人工判断
4 当面逐项核对实物、编号、配件、外观；远程人员核对快递签收的编号 回收执行 回收当日 回收清单 核对结果 👤人工判断
5 确认工作数据已移交后清除个人数据；通知账号收口（X-SEC-08） 回收执行 / 资产回收 回收当日 — 清理记录 👤人工判断
6 在离职审批运维节点签字通过；缺件写明并抄送人事 资产回收 核对后当日 飞书审批 审批结论 🔧飞书固化
7 资产表回写：使用人清空、状态改“在库/闲置/待修”，重新入库 资产回收 回收后 1 个工作日内 资产多维表格 更新记录 🔧飞书固化
8 每月核对一次：本月离职名单 vs 资产表仍挂在离职人员名下的设备 资产回收 + 离职发起（人事） 每月最后 1 个工作日 资产表、花名册 差异清单 🤖自动化

5. 交付物与模板

  • 交付物：回收清单（签字/确认）、离职审批运维节点记录、资产表回写记录、月度差异清单
  • 建议模板/表单（回收清单）：当事人、离职/换机类型、最后工作日、资产编号、名称、配件（充电器/线材/键鼠）、实物状态、是否归还、缺件说明、数据清理确认、回收人、日期

6. 异常与升级

  • 没收到离职流程但人员已离开或设备在外 → 运维当日询问人事确认状态 → 人事 1 个工作日内答复；非正式合作者由 CTO 认定后回收
  • 最后工作日未交回 → 人事暂缓办结离职手续 → 3 个工作日内未归还升级综合部负责人
  • 缺件/损坏 → 按 ADM-31 报损规则判定
  • 快递寄回编号不符 → 1 个工作日内与当事人核对，仍不符则登记差异并升级人事
  • 换机后旧机未交回 → 新机领用审批中设置“旧机交回”为必选项，未交回不发新机

7. 衡量指标

  • 离职当日回收率：最后工作日当天完成回收的离职人数占比，目标 ≥ 95%
  • 挂账离职人员资产数：月末资产表中仍挂在离职人员名下的设备数，目标 0
  • 回收清单完整率：有逐项核对记录的回收占比，目标 100%

8. 低效诊断

  • 现象：离职回收靠人事在群里逐个通知，运维再手动约时间｜依据：「运维&综合对接群」2026-03、「运维&综合对接群」2026-04
  • 现象：离职审批流转到运维节点后需额外提醒才处理｜依据：「运维&综合对接群」2026-07
  • 现象：非正式合作者结束合作时未走离职流程，设备仍在外，运维无从得知｜依据：「运维&综合对接群」2026-10
  • 现象：寄回设备签收时编号对不上，回收核对缺少清单｜依据：「运维&综合对接群」2026-10

9. 分支变体

  • 正式离职（含实习生）：走离职审批运维节点
  • 换机（如笔记本换 Mac mini）：新机领用与旧机交回绑定
  • 非正式合作结束（外部合作者、借调人员）：人事确认“视同离职”，CTO 认定后按本流程回收
  • 远程/异地人员：快递寄回，装箱清单写明资产编号，到货后再签审批

10. 待确认问题

  • 现行离职审批中运维节点的具体审批人是谁？是否已关联资产表？
  • 非正式合作者的“视同离职”由人事还是用人部门发起？
  • 最后工作日未交回设备时，暂缓办结离职手续是否符合人事制度？
  • 换机时旧机交回作为新机发放前置条件是否认可？
  • 月度离职名单与资产表核对由谁发起？
ADM-33资产盘点、闲置回收与审计配合待新建240

状态：待新建｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：到了定期盘点节点（季度/年后），或审计、董事会、尽调需要账实资料，或发现外借、送测、闲置设备长期未归还时，启动全量或专项资产盘点与回收
  • 负责人：主责——IT 资产管理员（当前：杨明学·推断待确认）；协同——盘点执行人/IT 运维交付（当前：游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、外借发起部门对接人（当前：李鹏为、闫登辉·推断待确认）、运维/云资源管理员（当前：宋祺睿·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 触发并发盘点通知 → ② 导出台账底表 → ③ 现场扫码盘点并补标签 → ④ 使用人确认 → ⑤ 外借与闲置追回 → ⑥ 差异处理 → ⑦ 与财务账核对 → ⑧ 出盘点报告并归档
  • 交付结果：更新后的资产台账（账实相符）、盘点报告与差异清单、外借/闲置回收记录、提交审计或董事会的资产资料
  • 状态依据：已有飞书多维表格设备台账和自研 IT 资管系统，但盘点没有固定周期（年后被提醒才启动，一周后仍有入库与贴标未完成）、资产标签已购未贴、外借客户与供应商送测的设备无统一台账，2026-01～10 群内反复找设备、确认归属约 20 余次，审计期间临时停掉对外业务救火

1. 场景判定

  • 触发条件：每季度首月第 1 周（定期盘点）；春节后复工首周；审计、董事会、尽调要求提供资产资料；外借/送测/试用设备超过约定归还日；机房或测试机出现闲置；资管岗位人员变动交接
  • 典型说法：「年后是不是还没有盘点资产」「走一下资产管理流程」「把机器都要回来吧，久了就都找不见了」「要做盘库和审计，对外业务先往后推」
  • 判断问题：这件事是不是要“核对一批资产的账和实物是否一致，或把不在库的资产要回来”？如果只是单台设备的入库、借用、维修或离职回收，不走本流程
  • 不归本流程管：新设备到货验收入库 → 请走 ADM-27；日常测试设备借用登记 → 请走 ADM-28；样机外借审批与出库 → 请走 ADM-29；信创厂商借机归还 → 请走 ADM-30；离职/换机回收 → 请走 ADM-32；云服务器、域名等非实体资源的盘点释放 → 请走 X-SEC-22 / ADM-34；审计所需财务报表与账务资料 → 请走 FIN-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 资产管理员 发起盘点、维护台账、汇总差异、出报告 R IT 资产管理员（当前：杨明学·推断待确认）
盘点执行人 现场扫码清点、补贴标签、分区存放 R IT 运维交付工程师（当前：游家豪·推断待确认）
设备使用人 确认名下设备在用状态与位置 R 全体员工
外借发起人/对接人 联系客户、渠道、供应商收回外借设备 R 销售/渠道负责人（当前：李鹏为、闫登辉·推断待确认）
运维/云资源管理员 确认机房闲置实例与测试机可回收 C 运维/云资源管理员（当前：宋祺睿·推断待确认）
财务 固定资产账与台账核对、调账、审计对接 C 财务负责人（当前：黄梦婷·推断待确认）
审批人 批准盘点结论、闲置处置、报废 A 创始人兼 CTO（当前：丁震宇·推断待确认）
部门负责人 知悉本部门资产差异并督促整改 I 各部门负责人

3. 办之前请准备

  • 资产台账最新导出（飞书多维表格设备库存、硬件清单、IT 资管系统报表）
  • 外借/送测/交付在途设备清单（含借出对象、经办人、约定归还日）
  • 上次盘点报告与未关闭差异
  • 资产标签、扫码工具；临时“待入库/交付货物”分区标识
  • 审计或董事会要求的资料清单与提交截止日
  • 财务固定资产明细账（金蝶导出）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发盘点通知：范围（实体 IT/外借/机房/待处置）、截止日、口径，审计/董事会场景同时说明需暂缓的事项 IT 资产管理员 触发后 1 个工作日内 飞书任务（季度自动生成）、群公告 盘点通知 🔧飞书固化
2 导出台账快照，生成盘点底表和超期外借清单 IT 资产管理员 通知当天 多维表格 / IT 资管系统 盘点底表 🤖自动化
3 现场逐台扫码核对编号、序列号、使用人、位置、状态；无标签当场补贴；公司资产与待交付货物分区存放 盘点执行人 通知后 3 个工作日内 资产标签 + 扫码 盘点记录 🔧+👤
4 推送名下设备清单给使用人确认在用/闲置/不在手 设备使用人 收到后 1 个工作日内 飞书表单/机器人 使用人确认记录 🔧+🤖
5 超期外借、送测、试用设备逐台联系收回；闲置设备收回入库；机房闲置实例确认无人使用后释放 外借发起人/对接人、运维/云资源管理员 发现后 2 个工作日内联系，10 个工作日内收回或给出书面结论 飞书任务 回收记录 👤人工判断
6 汇总盘盈、盘亏、找不到、归属不清，查明原因并逐条定责任岗位和关闭时间 IT 资产管理员 现场盘点结束后 3 个工作日内 多维表格 差异清单 👤人工判断
7 台账与财务固定资产账逐项核对，确认调账与报废 财务 收到差异清单后 5 个工作日内 金蝶 + 多维表格 账实核对表 🔧+🤖
8 出盘点报告，提交审计/董事会资料，闲置与报废处置走审批，报告归档 IT 资产管理员；审批人 盘点结束后 5 个工作日内 飞书文档 / 审批 盘点报告、处置审批 🤖+👤

5. 交付物与模板

  • 交付物：盘点报告、差异清单、更新后的资产台账、外借回收记录、审计/董事会资产资料包
  • 建议模板/表单：
    • 资产台账字段：资产编号（标签号）、类别（IT 设备/交付货物/机房设备/外借样机）、品牌型号、序列号、采购日期、财务卡片号、使用人、使用部门、存放位置、状态（在用/闲置/外借/维修/待处置/报废）、外借对象、约定归还日、最近盘点日
    • 盘点记录字段：资产编号、盘点结果（相符/位置不符/使用人不符/未找到/盘盈）、盘点人、照片、备注
    • 差异清单字段：资产编号、差异类型、原因、处理方式、责任岗位、关闭日期

6. 异常与升级

  • 设备找不到 → 查最近领用、借用、交付记录并联系相关人 → 3 个工作日仍未找到，升级 CTO 并通知财务，按丢失处理
  • 外借客户处设备超期且客户未回应 → 由销售负责人出面沟通，转为销售或结算 → 10 个工作日无结论升级 CTO
  • 审计时间与交付/对外业务冲突 → 资产管理员提前列出不可推迟事项 → 当天升级 CTO 决定优先级
  • 台账与财务账口径冲突（资产 vs 货物、无票设备） → 财务与资产管理员共同定口径 → 2 个工作日内升级财务负责人
  • 资产管理员岗位空缺或转岗 → 交接台账、在途外借、未关差异 → 交接未完成前由兜底人指定临时负责人

7. 衡量指标

  • 账实相符率 = 盘点相符资产数 / 台账资产总数，目标 ≥ 98%
  • 资产标签覆盖率 = 已贴标签资产 / 在册资产，目标 100%
  • 超期外借数 = 超过约定归还日 30 天仍未收回的设备台数，目标 0
  • 盘点按期完成率 = 按通知截止日完成的盘点次数 / 应盘点次数，目标 100%
  • 群内“找设备”次数 = 每月群里询问设备下落的次数，目标逐季下降

8. 低效诊断

  • 现象：盘点没有固定周期，靠提醒才启动，启动后入库、贴标仍拖延一周以上（触发环节）｜依据：「忠橙星行星引擎」2026-02、「忠橙星行星引擎」2026-03
  • 现象：台账位置与实物脱节，移动硬盘、取卡针、笔记本、平板等反复在群里找（台账维护环节）｜依据：「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-06
  • 现象：设备登记在谁名下、去留由谁定，需要多轮来回确认（使用人确认环节）｜依据：「忠橙星行星引擎」2026-02
  • 现象：资产管理随人员转岗无人接手，IT 同时承担交付与审计，审计期间被迫暂停对外业务（角色环节）｜依据：「忠橙星行星引擎」2026-08
  • 现象：外借客户、供应商送测机器没有外借台账，长期未结算、下落不明（外借回收环节）｜依据：「忠橙星行星引擎」2026-08、「忠橙星行星引擎」2026-10
  • 现象：新到货设备是否走资产领用口径不一，只能“先记一下”（入账口径环节）｜依据：「忠橙星行星引擎」2026-09
  • 现象：资产台账未与财务固定资产打通，审计时需人工逐项对账（账实核对环节）｜依据：「忠橙星行星引擎」2026-08

9. 分支变体

  • 年度/季度盘点：全量盘点，走步骤 1～8
  • 审计/董事会/尽调阶段：以资料清单和截止日倒排，步骤 7、8 优先，盘点报告需财务会签
  • 外借/送测专项回收：只盘外借清单，重点在步骤 5，客户处设备由销售负责人主导
  • 闲置机房资源回收：机房服务器、测试机、虚机实例由运维确认，云资源走 X-SEC-22
  • 外部办公点/空间设备：由驻点对接人代为扫码，资产管理员远程复核
  • 销售渠道资产与云资产：仅登记归属，不在本流程盘实物

10. 待确认问题

  • IT 资产管理员是否为当前主责？是否需要按此前提议设专职 IT 资产管理岗？
  • 盘点周期定为每季度一次是否可行？年后复工首周是否固定加一次？
  • IT 资产台账以飞书多维表格、办公软件平台的资产管理模块还是自研资管系统为准？迁入 LeapWorld 的时间点？
  • 资产台账与金蝶固定资产卡片如何打通？由财务哪个岗位负责核对？
  • 外借设备约定归还期默认多少天？超期后转销售或结算的口径由谁定？
  • 资产与交付货物分仓的物理位置和管理人是谁？
  • 闲置设备报废、转售、转赠的审批人与流程是否已有成文制度？
ADM-34云服务与软件订阅等非实体资产申领与释放待优化96

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：内部团队或子公司需要云服务、测试环境、域名、开放平台企业 ID、AI 工具订阅/兑换码/Token 等非实体资产，或这类资源不再使用需要释放回收时
  • 负责人：主责——云资源与权限管理员（当前：宋祺睿·推断待确认）；协同——审批人/创始人兼 CTO（当前：丁震宇·推断待确认）、资源原负责人（当前：按台账登记，待指定）、交付核对人（当前：杨云峰、游家豪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、申请人；兜底——创始人兼 CTO
  • 核心流程：① 提交「非实体资产申领」审批 → ② 分类与主体判定 → ③ 审批 → ④ 采购付款（如需） → ⑤ 开通/发放 → ⑥ 登记资源台账 → ⑦ 释放申请与在用确认 → ⑧ 执行释放并更新台账
  • 交付结果：已审批的申领单、开通完成并登记到资源台账的资源（含负责人、到期日、费用归属）、经确认的释放记录
  • 状态依据：已有飞书审批「非实体资产申领」且在用，但审批需在群里手动 @ 催办、审批卡片在部分客户端不可见；审批与资源台账未联动；小额 AI 工具低于采购门槛无渠道，兑换码私发；释放回收无审批和台账，出现过表格与实际组织 ID 不一致、险些注销在用资源

1. 场景判定

  • 触发条件：新项目/子公司项目需要云服务或测试环境；需要域名、开放平台企业 ID；团队想体验或采购 AI 工具、订阅、Token；服务废弃后需释放域名或回收测试组织/虚机
  • 典型说法：「领用类型：云服务开通」「可以，走采购流程」「这个域名可以释放给我不」「这个还有用吗？在哪台服务器上？」「这个回收了吗」
  • 判断问题：要申请或归还的是不是“看不见摸不着、按账号/实例/额度计的公司资源”？是否需要登记归属和到期日？
  • 不归本流程管：云服务器开通的技术配置细节 → 请走 X-SEC-16；内网测试机/GPU/PVE 虚机分配 → 请走 X-SEC-17；AI 编程工具订阅开通与防封 → 请走 X-SEC-14；域名购买与 ICP 备案 → 请走 X-SEC-20；云资源定期盘点与成本治理 → 请走 X-SEC-22；对公采购付款 → 请走 FIN-01 / FIN-02；密钥分发 → 请走 X-SEC-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
云资源与权限管理员 受理分类、开通发放、登记台账、执行释放 R 云资源与权限管理员（当前：宋祺睿·推断待确认）
审批人 判断是否必要、公司赞助还是采购、批准申领与释放 A 创始人兼 CTO（当前：丁震宇·推断待确认）
申请人 填写申领/释放单，按期使用和归还 R 各部门/子公司申请人（当前：王皓南、裴建武等·推断待确认）
资源原负责人 释放前确认是否仍在用 C 台账登记负责人（当前：李铭熙等·推断待确认）
交付核对人 核对企业 ID/组织、测试机是否已用于客户交付 C 交付部署工程师（当前：杨云峰、游家豪·推断待确认）
财务 付款、费用归属到项目或子公司 C 财务负责人（当前：黄梦婷·推断待确认）
相关部门负责人 知悉资源开通与释放 I 各部门负责人

3. 办之前请准备

  • 资源类型（云服务/测试环境/域名/开放平台企业 ID/AI 订阅/Token/兑换码）
  • 使用主体与项目（内部项目或子公司项目）、费用归属
  • 规格与数量、预计使用期限、到期处理方式（续费/释放）
  • 资源负责人（开通后谁对它负责）
  • 申请 AI 工具时：用途、人数、是否已有公司赞助渠道
  • 释放时：资源名称/ID、所在服务器或账号、关联服务、当前用户与访问情况

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交「非实体资产申领」审批，填领用类型、项目、主体、申领原因、期限、负责人 申请人 需要使用前 2 个工作日 飞书审批 申领单 🔧飞书固化
2 判定类型与主体，判断走公司赞助（统一购买发放）还是采购；技术类转对应开通流程 云资源与权限管理员 提交后 1 个工作日内 飞书审批 分类意见 👤人工判断
3 审批；审批卡片由机器人自动 @ 审批人，超时自动提醒 审批人 收到后 1 个工作日内 飞书审批 + 机器人 审批结论 🔧飞书固化
4 需付费的走采购付款；低于采购门槛的小额按约定口径集中采购或报销 申请人、财务 审批通过后 3 个工作日内 飞书审批（FIN-01/FIN-02） 付款记录 🔧飞书固化
5 开通资源或发放兑换码/账号，凭据通过私密通道或密码管理器下发 云资源与权限管理员 审批通过（或到账）后 1 个工作日内 云控制台 / 密码管理器 开通结果 🔧+🤖
6 写入资源台账：资源 ID、类型、主体、项目、负责人、开通日、到期日、费用归属、状态；发放名单同步登记 云资源与权限管理员 开通当天 多维表格（审批通过自动写入） 台账记录 🤖自动化
7 资源到期或不再使用时提交释放审批，写明资源、用途、所在服务器 申请人 / 资源原负责人 到期前 7 个自然日或停用后 3 个工作日内 飞书审批 释放单 🔧飞书固化
8 原负责人确认无用；企业 ID/组织与交付表、客户在用状态核对，查看近 30 天访问记录 资源原负责人、交付核对人 收到后 2 个工作日内 交付表 / 日志 在用确认 👤+🤖
9 执行解绑/注销/销毁，必要时先备份，更新台账状态为已释放 云资源与权限管理员 确认后 1 个工作日内 云控制台 / 域名控制台 释放记录 🔧飞书固化

5. 交付物与模板

  • 交付物：申领审批单、资源台账、AI 工具发放名单、释放审批单与释放记录
  • 建议模板/表单：
    • 申领单字段：申请人、使用主体（集团/子公司）、项目、领用类型、规格数量、使用期限、资源负责人、费用归属、赞助或采购、申领原因
    • 资源台账字段：资源 ID/名称、类型、云厂商或平台、所属账号、主体、项目、负责人、开通日、到期日、续费方式、月成本、状态（在用/待释放/已释放）、关联客户交付（是/否）
    • 释放单字段：资源 ID、所在服务器/账号、原用途、原负责人确认、交付核对结论、是否需备份、释放日期

6. 异常与升级

  • 审批卡片在客户端无法查看 → 改用飞书网页端或审批链接处理 → 当天仍无法处理的，由管理员直接在后台查看并通知审批人
  • 审批超过 1 个工作日未处理 → 机器人自动提醒 → 超过 2 个工作日升级兜底人
  • 小额低于采购门槛无渠道 → 按月集中采购或按报销口径处理 → 口径未定的，3 个工作日内由 CTO 与财务确定
  • 兑换码、密钥在群内明文发放 → 立即撤回并按 X-SEC-11 轮换 → 当天通知云资源与权限管理员
  • 释放前发现资源仍在用或归属不清 → 停止释放，补登记负责人 → 2 个工作日内找不到负责人的升级 CTO
  • 误释放影响客户或线上服务 → 立即恢复或重建，通知交付负责人 → 1 小时内升级 CTO 并复盘
  • 子公司费用归属不明 → 财务确认结算方式 → 付款前完成

7. 衡量指标

  • 申领审批时长 = 提交到审批通过的工作时长，目标 ≤ 1 个工作日
  • 开通时长 = 审批通过到资源可用，目标 ≤ 1 个工作日
  • 台账覆盖率 = 有台账记录的在用非实体资源 / 实际在用资源，目标 100%
  • 无主资源数 = 台账中负责人为空或已离职的资源数，目标 0
  • 误释放事件数 = 释放后被发现仍在用的次数，目标 0
  • 群内手动催审批次数 = 每月在群里 @ 催办申领审批的次数，目标 0

8. 低效诊断

  • 现象：审批卡片推到群后仍需人工 @ 审批人才会处理，部分客户端看不到卡片需截图转发（审批环节）｜依据：「鼎慧产研决策部」2026-09、「鼎慧产研决策部」2026-10
  • 现象：审批流改版后申请人不清楚新流程（申请环节）｜依据：「鼎慧产研决策部」2026-08
  • 现象：低于采购门槛的小额 AI 工具没有渠道，只能个人垫付或凑单（采购环节）｜依据：「leapagent赛马」2026-04
  • 现象：兑换码靠私发，发放名单靠人工记（发放登记环节）｜依据：「leapagent赛马」2026-04
  • 现象：释放域名时要在群里反复问用途、在哪台服务器、谁管理（台账缺失环节）｜依据：「Leap产研测」2026-08
  • 现象：表格中的组织 ID 与实际不一致，测试资源用于交付后未更新，释放前险些注销在用组织（在用确认环节）｜依据：「Leap产研测」2026-08
  • 现象：审批通过后不触发开通任务、不写台账，开通与审批两条线脱节（登记环节）｜依据：「鼎慧产研决策部」2026-09

9. 分支变体

  • 内部项目：费用归集团或项目，按步骤 1～9 执行
  • 子公司项目（如招投标系统测试环境）：申领单需填子公司主体，财务确认结算方式后再开通
  • AI 工具公司赞助：统一购买后发放兑换码，跳过步骤 4，发放名单必须登记
  • AI 工具/Token 自行采购：达到采购门槛走 FIN-02，低于门槛按小额口径处理
  • 域名释放：确认无解析在用后解绑，涉及备案的同步 X-SEC-20
  • 开放平台企业 ID/测试组织注销：必须完成与交付表、客户在用状态核对（步骤 8）后才能注销
  • 虚拟机/测试环境释放：先确认数据是否需备份，内网虚机按 X-SEC-17 回收

10. 待确认问题

  • 主责是否为云资源与权限管理员？审批人是否固定为 CTO，还是按金额/类型分级审批？
  • 「非实体资产申领」审批改版后的最新字段和审批链是什么？能否加机器人自动 @ 审批人和自动写台账？
  • 采购流程的起步金额门槛（聊天中有口头口径，[阈值待财务确认]）是否属实？低于门槛的小额工具走报销、备用金还是月度集中采购？
  • 资源台账以哪张表为准？与 FIN-30 云账号台账、X-SEC-22 云资源盘点是否合并维护？
  • 释放审批是否单独建审批类型，还是在「非实体资产申领」中增加“释放”选项？
  • 子公司申领的费用如何结算，由财务哪个岗位确认？
  • 开放平台企业 ID 注销前的核对责任人是谁（交付还是开放平台）？
ADM-35消防安全检查与应急疏散演练待新建推断80

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨4 × 险5

  • 适用场景：办公区、机房、库房的日常消防检查，每年至少一次的应急疏散演练，以及发生火情、冒烟、电池鼓包等险情时适用
  • 负责人：主责——行政专员（当前：待指定）；协同——IT/运维（当前：待指定）、人事（当前：待指定）、楼宇物业（外部）；兜底——行政负责人（当前：胡则瑾·部门报送人）
  • 核心流程：① 消防设施台账 → ② 月度检查 → ③ 隐患整改 → ④ 年度疏散演练 → ⑤ 险情处置 → ⑥ 复盘与台账更新
  • 交付结果：消防检查记录、隐患整改单、演练记录、险情处置报告
  • 状态依据：已有 ADM-09（停电等突发事件通知）、ADM-10（离岗断电与机房检查）覆盖部分环节，本条补齐消防检查、隐患整改与疏散演练；公司有机房、服务器、一体机库存与锂电设备（推断）

1. 场景判定

  • 触发条件：每月检查日；年度演练计划；新增机房/库房或搬迁；发现烟味、插线板过载、电池鼓包
  • 典型说法：「机房有股焦味」「插线板串了好几个」「灭火器是不是过期了」
  • 判断问题：是否有人身或财产安全威胁？是否需要立即疏散？
  • 不归本流程管：停电/极端天气 → 请走 ADM-09；日常下班断电检查 → 请走 ADM-10；服务器故障与数据恢复 → 请走 X-SEC-29；人员受伤 → 请走 HR-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
检查与组织 台账、检查、演练组织 R 行政专员（当前：待指定）
机房与设备 机房、库房用电及设备散热检查 R IT/运维（当前：待指定）
人员清点 演练与疏散时清点人数 C 人事（当前：待指定）
现场发现人 发现险情立即报警并通知行政 R 全体员工
审批与兜底 批准整改投入、险情决策 A 行政负责人（当前：胡则瑾·部门报送人）

3. 办之前请准备

  • 楼层平面图与疏散路线、消防设施位置
  • 灭火器、烟感、应急灯台账及有效期
  • 各楼层疏散引导人名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立消防设施与疏散责任人台账 行政专员 本流程确认后 10 个工作日内 飞书多维表格 台账 🔧飞书固化
2 月度检查（灭火器、通道、插线板、机房温度） 行政专员+IT/运维 每月首周 飞书表单 检查记录 🔧飞书固化
3 隐患整改并复查 行政专员 发现后 5 个工作日内 飞书任务 整改单 🔧飞书固化
4 年度疏散演练（含新人告知疏散路线） 行政专员+人事 每年至少 1 次 全员通知 演练记录 👤人工判断
5 险情处置：报警、断电、疏散、清点 现场发现人+行政专员 立即 电话/全员群 处置记录 👤人工判断
6 复盘并更新台账 行政专员 险情后 3 个工作日内 飞书文档 复盘报告 🔧飞书固化

5. 交付物与模板

  • 交付物：消防台账、月度检查记录、演练记录、险情复盘
  • 建议模板/表单：月度检查表（区域、灭火器有效期、通道是否堵塞、插线板负载、机房温度、电池类设备状态、问题、整改人、复查日期）

6. 异常与升级

  • 发现明火或冒烟 → 立即报警并疏散，同时报行政负责人与 CEO
  • 隐患超期未整改 → 报行政负责人（超期当天）

7. 衡量指标

  • 月度检查完成率：目标 100%
  • 隐患按期整改率：目标 ≥ 95%

8. 低效诊断

  • 聊天中未见相关流程，存在机房过热、插线板过载、库房设备堆放引发火情且无人熟悉疏散路线的风险（推断）

9. 分支变体

  • 多个办公点各自设检查人；展会与大会现场消防按场馆要求执行

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 物业是否已有消防检查与演练安排，公司是否需要单独组织？
  • 机房是否配置了适用于电气火灾的灭火设备？
ADM-36场地租金、物业及水电网费用缴纳与租约到期提醒待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：每月/每季度缴纳房租、物业费、水电费、宽带专线费，以及租赁、物业、宽带合同到期前的续约决策时适用
  • 负责人：主责——行政专员（当前：待指定）；协同——财务（当前：待指定）、IT/运维（当前：待指定）；兜底——行政负责人（当前：胡则瑾·部门报送人）
  • 核心流程：① 建立固定费用台账 → ② 到期前提醒 → ③ 核对账单 → ④ 付款申请 → ⑤ 付款与收票 → ⑥ 合同到期前评估续约 → ⑦ 台账更新
  • 交付结果：按期缴纳的付款记录与发票、续约或退租决定
  • 状态依据：已有 ADM-01（选址、租赁与搬迁）覆盖租赁签约环节，本条补齐周期性场地费用缴纳与租约到期续约提醒（推断）

1. 场景判定

  • 触发条件：账单到达；缴费日前 7 日；合同到期前 90 日
  • 典型说法：「物业说电费欠了」「宽带下个月到期」「房租合同什么时候到期」
  • 判断问题：该费用是否属于场地类固定周期费用？合同主体与付款主体是否一致？
  • 不归本流程管：选址、新租、搬迁 → 请走 ADM-01；网络带宽扩容 → 请走 X-SEC-28；一般采购付款 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账与付款申请 维护台账、核对账单、发起付款 R 行政专员（当前：待指定）
付款与收票 审核付款、入账、收票 R 财务（当前：待指定）
网络线路 宽带专线到期评估 C IT/运维（当前：待指定）
系统 缴费日前自动提醒 R 多维表格自动化（行政专员维护）
审批 续约/退租决定 A 行政负责人（当前：胡则瑾·部门报送人）

3. 办之前请准备

  • 租赁、物业、宽带合同及付款条款
  • 各办公点电表、水表户号与缴费方式
  • 历史缴费记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立固定费用台账（费用项、主体、周期、缴费日、合同到期日） 行政专员 本流程确认后 10 个工作日内 飞书多维表格 台账 🔧飞书固化
2 缴费日前自动提醒 系统 缴费日前 7 日 多维表格自动化 提醒 🤖自动化
3 核对账单（用量异常、单价变化） 行政专员 收到账单后 2 个工作日内 账单 核对结论 👤人工判断
4 发起付款申请 行政专员 缴费日前 5 日 飞书审批 付款申请 🔧飞书固化
5 付款并收取发票 财务 缴费日前 网银 付款凭证、发票 👤人工判断
6 合同到期前评估续约或退租 行政专员+IT/运维 到期前 90 日 文档 续约建议 👤人工判断
7 审批并更新台账 行政负责人 到期前 60 日 飞书审批 续约决定 🔧飞书固化

5. 交付物与模板

  • 交付物：固定费用台账、付款记录、续约决定
  • 建议模板/表单：台账字段（办公点、费用项、合同主体、供应方、周期、缴费日、合同到期日、自动续约条款、负责人、最近缴费日期）

6. 异常与升级

  • 收到欠费停电/断网预警 → 当天走加急付款（GEN-05）并报行政负责人
  • 用量环比异常升高 → 排查机房或设备异常用电（3 个工作日内）

7. 衡量指标

  • 按期缴费率：目标 100%
  • 合同到期提前决策率 = 到期前 60 日完成续约决定的合同比例，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在欠费停电断网影响研发与机房、租约到期被动续约的风险（推断）

9. 分支变体

  • 不同主体承租的场地由对应主体付款；共享场地的费用分摊按 FIN-32 处理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各办公点的合同主体与付款主体是否一致？
  • 电费是否由物业代收？是否可开通自动扣费？

FIN 财务

报送人：黄梦婷 · 综合 · 43 条 · 已有 1 / 待优化 24 / 待新建 18
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
FIN-01对公采购申请与付款审批业务需以公司名义向外部供应商采购 IT/网络/算力/软件服务/硬件/家宽专线等，需要签合同或对公付款时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购（当前：杨明学·推断待确认）、总经办采购发起（当前：田杰·推断待确认）、行政合同与用印（当前：侯明月·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 询价比价并确认可开票 → ② 提交“采购申请” → ③ 合同审核与用印 → ④ 技术审批与终审 → ⑤ 财务提“付款申请”制单 → ⑥ 复核打款 → ⑦ 回执给采购人提货/开工 → ⑧ 验收、发票回收入账审批留痕完整的采购申请、已盖章合同、付款回单、合规发票、验收/资产登记记录与入账凭证；交付类采购同时拿到回执完成提货。待优化320
FIN-02AI 工具订阅与第三方服务新购开通团队需要新购 AI 订阅席位、模型账号、第三方 API Key 或按量付费服务（含产品集成的第三方服务、内容团队试用的生成工具）时启动。主责——IT 资源与采购（当前：杨明学·推断待确认）；协同——CTO 用途与预算审批（当前：丁震宇·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、NewAPI 网关管理员（当前：望政韬·推断待确认）、行政报销对接（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CEO 超阈值审批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提需求（工具/用途/席位/预算）→ ② 官方渠道与付款主体核验 → ③ “AI 工具/服务开通申请”审批 → ④ 以公司账号开通并公司付款 → ⑤ 密钥接入 NewAPI/密钥库并限额 → ⑥ 登记服务台账 → ⑦ 到期/余额/封号提醒 → ⑧ 月度用量与成本复盘以公司主体开通、可用且登记在台账的订阅/账号/Key，明确负责岗位、额度上限、到期日与成本归属。待新建192
FIN-03上游模型/云服务/三方 API 账户充值与余额预警公司已有的云厂商、模型厂商、中转渠道、三方 API、SaaS 席位账户余额低于预警线、欠费或账期到期时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——云资源与账户监控（当前：宋祺睿·推断待确认）、IT 运维与渠道（当前：杨明学·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 余额自动监控告警 → ② 确认充值需求（金额/主体/账户）→ ③ 财务统一提“付款申请” → ④ 技术审批 + 终审 → ⑤ 核验账户后汇款 → ⑥ 到账确认并通知 → ⑦ 消耗后开票回收 → ⑧ 月度对账复盘账户恢复到目标余额且服务不中断；付款申请、回单、到账记录、发票在账户台账中一一对应。待优化225
FIN-04境外服务外币付款与无票支出处理需要向境外 AI 服务、网关、订阅、云服务支付外币，或支出无法取得国内合规发票时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CTO 需求审批（当前：丁震宇·推断待确认）、IT 运维流程指引（当前：杨明学·推断待确认）、CEO 例外审批与公司卡（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 先找可开票/对公替代渠道 → ② 提“境外/无票支出申请” → ③ CTO、财务、CEO 审批 → ④ 公司外币卡或对公外币付款 → ⑤ 平台账号登记台账 → ⑥ 留存 Invoice 与付款凭证 → ⑦ 按无票支出入账核销用公司支付工具完成的境外付款，附审批单、平台 Invoice/账单、付款凭证与无票说明，可入账、可审计。待新建240
FIN-05备用金/费用预支申请与核销研发/运维需先支付小额零散费用（硬件测试零件、算力、AI 账号、手机号卡、月付订阅），且来不及对公付款或暂时没有发票时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购申请人（当前：杨明学·推断待确认）、CTO 审批（当前：丁震宇·推断待确认）、CEO 特批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 判断是否适用备用金 → ② 提“备用金申请”并关联采购申请 → ③ CTO 审批（超限 CEO 特批）→ ④ 财务打款 → ⑤ 使用并取票 → ⑥ 提“备用金核销” → ⑦ 余额走还款退回公户审批留痕的备用金，按期核销、余额退回，每笔支出有发票或经批准的无票说明。待优化144
FIN-06日常费用报销提交与审核员工因公垫付办公采购、设备、餐费、耗材、零食福利、打车、通信、云服务等费用后需要报销时启动。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——行政（报销表单通知、票据收集、垫付打车报销，当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、各部门直属上级（当前：按申请人）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 对照可报销清单判断 → ② 取得合规发票（抬头为所属主体）→ ③ 飞书“费用报销”提单 → ④ 直属上级审批 → ⑤ 财务审核 → ⑥ 终审 → ⑦ 制单打款并回传回单 → ⑧ 票据整理归档已付款的报销单，附合规发票、付款凭证与回单，可入账、可审计。待优化180
FIN-07差旅事前报备与差旅报销员工因公到外地或境外出差、参会、拜访客户时，从事前报备到报销付款全程适用。主责——财务负责人（当前：黄梦婷·推断待确认）；协同——综合部（差旅制度与行程单简化，当前：赵雪冰·推断待确认）、销售负责人（审批链节点，当前：李鹏为·推断待确认）、COO 差旅标准制定（当前：常元和·推断待确认）、CEO 特批与制度梳理（当前：邴龙志·推断待确认）、市场部（报销填单 AI skill，当前：陈芷青·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 出差前提“出差报备” → ② 直属上级审批（超标/境外加特批）→ ③ 出行并收集电子发票 → ④ 生成往返闭环行程单 → ⑤ 提“费用报销”关联报备 → ⑥ 财务审核 → ⑦ 打款 → ⑧ 参会成果文档归档（如适用）已付款的差旅报销单，关联出差报备，附闭环行程单、发票和（如适用）特批记录与参会成果文档。待优化108
FIN-08企业滴滴充值与通勤打车报销员工通勤、加班返程、因公出行打车，以及企业滴滴账户月度充值、额度调整、余额不足时适用。主责——行政负责人（当前：胡则瑾·推断待确认）；协同——财务充值（当前：黄梦婷·推断待确认）、行政用车仪表盘（当前：侯明月·推断待确认）、CEO 标准制定（当前：邴龙志·推断待确认）、人事入离调同步（当前：黄莹·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职开通并宣讲 → ② 员工按入口用车 → ③ 行政月度汇总提交充值 → ④ 财务充值 → ⑤ 余额预警 → ⑥ 月度仪表盘与抽查 → ⑦ 余额不足时垫付报销 → ⑧ 入离调同步账户每月额度充足可用的企业滴滴账户、月度用车仪表盘与核查记录。待优化36
FIN-09活动/团建/大会费用预算与统计归集行政或业务小组组织团建、主题活动、生态大会等，需要事前报预算、事中按口径采购或垫付、事后报销，并按活动汇总实际花费主责——活动负责人（立项时指定；团建默认行政专员，当前：侯明月·推断待确认）；协同——大会费用汇总人（综合部负责人，当前：赵雪冰·推断待确认）、各组负责人、报销人、财务专员（当前：刘梦可·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项报预算 → ② 预算审批 → ③ 发布费用口径 → ④ 按口径采购/垫付 → ⑤ 报销时关联活动名 → ⑥ 各组登记明细 → ⑦ 预算对照汇总 → ⑧ 财务核对归档活动费用汇总表（预算 vs 实际，按科目/小组拆分），关联的报销单与发票齐全并归档待优化81
FIN-10员工 AI 工具补贴核发与超额报销每月按岗位核发员工 AI 工具补贴；员工因工作使用 AI 工具超出补贴需额外申请或报销；外部研发方、参赛者需要订阅支持；补贴资格复核与使用调研主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（补贴表核算，当前：黄莹·推断待确认）、创始人兼 CTO（口径解释与超额审批，当前：丁震宇·推断待确认）、CEO（标准与预算，当前：邴龙志·推断待确认）、产品负责人（LeapAll 充值核验，当前：杨萌·推断待确认）、行政专员（AI 采购登记，当前：侯明月·推断待确认）；兜底——综合部负责人① 冻结当月名单与分档 → ② 差异比对 → ③ 管理层审核 → ④ 计税并提付款 → ⑤ 每月 15 日打款 → ⑥ 超额申请审批 → ⑦ 发票审核报销 → ⑧ 充值/使用核验与月度统计当月 AI 补贴发放表与付款凭证（含个税代扣记录）、已审批的超额申请与合规票据报销单、充值/使用核验名单、按主体汇总的月度 AI 费用统计、一页式补贴制度待优化256
FIN-11飞书报销审批表单配置与应用问题处理财务新建或调整飞书费用报销、预付后补票、关联差旅报备等审批表单；员工提交时遇到退回、发票被占用、控件值为空、明细超行数、需撤回修改等应用问题主责——财务负责人（当前：黄梦婷·推断待确认）；协同——飞书审批管理员（当前：黄莹·推断待确认）、发票报销应用管理员（当前：丁震宇·推断待确认）、综合部负责人（报销自动化改造，当前：赵雪冰·推断待确认）、外部厂商客服；兜底——综合部负责人① 员工按 FAQ 自查 → ② 提交问题单 → ③ 财务排查 → ④ 转管理员/厂商 → ⑤ 表单变更测试 → ⑥ 发布 → ⑦ 通知 → ⑧ 沉淀 FAQ可用的报销类表单配置及变更记录、员工问题处理记录、《报销系统 FAQ》、应用管理员与插件余量台账待优化81
FIN-12进项发票索取、缺票催收与归档公司或员工产生采购、垫付、云服务/SaaS、订阅等支出后，向供应商索取合规发票，财务收集、去重、催收缺票并归档，集中处理抵扣票主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT/采购（云服务与海外订阅开票，当前：杨明学·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（SaaS 席位开票，当前：黄莹·推断待确认）、各支出经办人；兜底——综合部负责人① 支出时按开票信息卡索票 → ② 上传并登记台账 → ③ 识别去重 → ④ 重命名归档 → ⑤ 月度缺票清单 → ⑥ 催收补票 → ⑦ 无票/异常人工判定 → ⑧ 抵扣票汇总按主体、月份统一命名归档的进项发票库；发票台账（含是否已报销、是否抵扣）；月度缺票清单与催收结果待优化192
FIN-14劳务、顾问及奖金类报酬结算与个税兼职、劳务人员、外部顾问、驻场人员、外部技术服务方按月或按项目结算报酬，或比赛奖金发放，需要确认用工性质与工作量、签协议、开票或代扣个税并付款主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（台账与确认单汇总，当前：黄莹·推断待确认）、业务负责人（确认工作量，当前：杨萌·推断待确认）、CEO（结算方式决策，当前：邴龙志·推断待确认）、COO（合同签批，当前：常元和·推断待确认）、创始人兼 CTO（技术服务方需求，当前：丁震宇·推断待确认）、赛事组织负责人（当前：白福康·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人① 判定用工/合作性质 → ② 签合同或协议 → ③ 月度工作量确认 → ④ 开票或代扣个税 → ⑤ 付款申请关联合同 → ⑥ 付款 → ⑦ 台账更新与凭证归档外部人员结算台账、已签署的合同/协议、工作确认单、发票或完税凭证、付款回单、奖金归属确认书待新建144
FIN-15支付通道选型、商户进件与收款权限开通产品或新主体需要上线收款、分账，或已有商户需开通网银、微信/支付宝、公众号/小程序支付、临时额度，或渠道风控、资质异常导致支付失败主责——支付渠道负责人（汇付商户与渠道控台，当前：徐莉·推断待确认）；协同——创始人兼 CTO（需求发起与选型拍板，当前：丁震宇·推断待确认）、财务负责人（进件材料、流水与合同，当前：黄梦婷·推断待确认）、综合部负责人（主体证照与协议，当前：赵雪冰·推断待确认）、支付研发（当前：陈锦杰、王子明、张楠·推断待确认）、鼎慧商户管理员（当前：杨萌·推断待确认）、CEO（对接支付方高层，当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO① 登记收款需求 → ② 查台账/通道选型评估 → ③ 拍板主体与通道 → ④ 准备进件材料 → ⑤ 提交进件并跟进 → ⑥ 安全交接密钥 → ⑦ 沙箱 + 小额实测 → ⑧ 登记台账并持续监控资质已开通并实测通过的商户与通道；主体-商户号-appid-支付能力台账；选型评估记录；进件材料包；风控材料标准包待新建250
FIN-16内部测试与客户赠送额度申请审批内部测试、FDE、演示账号，或新交付、试用客户需要平台额度、词元、兑换券时的申请、审批、充值/发券、台账登记、成本归属与回收主责——额度审批人（产品负责人，当前：杨萌·推断待确认）；协同——后台充值执行（当前：柯逸飞、邓乾、宋祺睿·推断待确认）、商务负责人（客户特批，当前：李鹏为·推断待确认）、财务负责人（成本归属与渠道线下充值，当前：黄梦婷·推断待确认）、FDE 负责人（培训机额度标准，当前：吴亚军·推断待确认）、生态组负责人（社区卡密，当前：陈梦琪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交额度申请 → ② 按标准审批 → ③ 超标准特批 → ④ 后台充值/生成券 → ⑤ 申请人确认 → ⑥ 台账登记与成本归属 → ⑦ 月度对账 → ⑧ 到期回收经审批的额度申请记录、后台充值/发券记录、额度台账（对象、金额、用途、成本中心）、月度赠送额度成本汇总待新建128
FIN-17客户充值到账审核与额度开通企业/渠道客户为 LeapCore、LeapAll 付款充值（线上支付或线下对公转账），或新部署机器需预充、额度用尽需续充时，从确认到账到开通额度、对账闭环主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、额度充值执行人（当前：柯逸飞·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交充值订单/下载结算单 → ② 付款并上传汇款凭证 → ③ 财务审核到账 → ④ 接口开通额度（含赠送） → ⑤ 订单完结并通知 → ⑥ 日对账与客户/实例绑定 → ⑦ 退款/补发/错充处理已审核到账、额度到位且留痕的充值订单；订单—支付—到账—额度—客户/实例一一对应的充值台账与月度对账表待新建300
FIN-18客户充值订单开票客户在 LeapCore/LeapAll 线上或线下充值 Token 后申请发票，或需集中登记对外开票（含兑换券、集采）时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、LeapCore 发票功能研发（当前：魏宗浩·推断待确认）、渠道系统维护负责人（当前：郭逸非·推断待确认）、销售支持（当前：韩诗琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 订单已支付并已充值 → ② 客户提交开票信息 → ③ 同步渠道系统待开票 → ④ 财务判定票种并开具 → ⑤ 上传发票回写订单 → ⑥ 通知客户并登记台账 → ⑦ 错票红冲重开与充值订单一一对应、票种正确的电子发票，订单页可查看下载；对外开票台账完整待优化240
FIN-19销售合同开票申请与红冲销售合同签署、交付验收或约定预付款节点到达后，业务申请开票；以及错票红冲、客户催票、收款认款核销时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·合同台账（当前：韩诗琪·推断待确认）、总经办（当前：田杰·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 合同编号登记 → ② 业务提交开票申请 → ③ 财务校验开票条件与税率 → ④ 税务系统开具 → ⑤ 上传分发给申请人/客户 → ⑥ 回款认款与凭证核销 → ⑦ 错票红冲重开税目税率正确、与合同和收款对应的发票；认款核销完成的收款记录与凭证待优化300
FIN-20软硬一体合同分税率开票与硬件基准价维护LeapCore 等软硬一体销售合同起草、审核和开票时，按硬件 13%、软件及技术服务 6% 拆分金额；每月按采购价校准 SKU 硬件基准价主责——财务负责人（当前：黄梦婷·推断待确认）；协同——总经办（当前：田杰·推断待确认）、IT 价格维护（当前：游家豪·推断待确认）、渠道负责人·商务核价（当前：闫登辉·推断待确认）、法务负责人（当前：李瑶·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月度核定硬件基准价 → ② SKU 配置录入留痕 → ③ 合同生成按型号自动拆分 → ④ 法务审核核对拆分 → ⑤ 财务分税率开票 → ⑥ 月度校准提醒与变更通知软硬金额分列的合同、分税率发票；带生效时间和修改历史的 SKU 硬件基准价表待优化240
FIN-21收入合同台账、回款跟进与收入确认合同签订、交付验收、开票、回款各节点发生时登记收入合同台账，跟进回款，核对公户进款并按月确认收入，处理"已交付/已回款但无合同"业务主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·台账（当前：韩诗琪·推断待确认）、销售对接人（当前：闫登辉、吴琪、杜中瑞·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 合同签订登记台账 → ② 交付与验收单回传 → ③ 开票登记 → ④ 回款跟进与催款 → ⑤ 公户进款认领核对 → ⑥ 月末收入确认 → ⑦ 无合同业务清单处理字段完整的收入合同台账；每月收入确认清单与应收账龄表；无合同业务处理结论待优化240
FIN-22境外客户收款、形式发票与结汇海外客户按合同以外币付款时，开具形式发票（Proforma Invoice），到账后向银行补材料审核、结汇入账并存档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——业务对接人（当前：丁震宇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 业务提出收款需求并提供交易信息 → ② 签署对方盖章的英文合同 → ③ 开具形式发票并盖章 → ④ 发送客户并按对方时区跟进 → ⑤ 网银汇入汇款确认上传材料 → ⑥ 大额加强审核补材料 → ⑦ 结汇入账 → ⑧ 存档与台账结汇完成的人民币入账；合同、形式发票、银行审核材料、结汇凭证完整存档；境外回款台账待优化200
FIN-23渠道/开发者分成结算、分润打款与开票产品收款需按约定分给开发者、渠道、合作方，商城需向厂商或渠道平台结算，或用户支付后需退款冲正时主责——财务负责人（当前：黄梦婷·推断待确认）；协同——支付/分账研发（当前：陈锦杰·推断待确认）、LeapCore 产品负责人（当前：杨萌·推断待确认）、字字可研产品经理（当前：黄飞鹏·推断待确认）、商城对接研发（当前：葛家和·推断待确认）、COO（税务口径，当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 结算规则书面确认 → ② 系统计算待分成金额 → ③ 财务核对 → ④ 分账或批量打款 → ⑤ 开票/收票 → ⑥ 对账 → ⑦ 退款与冲正按书面规则完成的分账/打款记录、对应发票、月度结算对账单；退款审批与冲正记录待新建225
FIN-24支付渠道每日对账、手续费与差异处理每日支付、分账、提现、退款发生后核对系统与支付平台、公户到账；处理对账差异与失败重跑；每月核对收单与公户到账、申请手续费发票主责——财务负责人（当前：黄梦婷·推断待确认）；协同——跃竞后端负责人·对账开发（当前：王子明·推断待确认）、LeapPay 支付研发（当前：陈锦杰·推断待确认）、跃竞负责人·支付商户管理（当前：徐莉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 每日 20:00 机器人推送对账结果 → ② 判定账实平/差异/失败 → ③ 失败重跑 → ④ 差异分类与修复 → ⑤ 财务确认关闭 → ⑥ 月度收单与公户到账核对 → ⑦ 手续费发票申请与入账每日对账结论均有回执；差异清单逐条关闭；月度支付结算对账表；手续费发票按月取得待优化200
FIN-25资金/分账异常排查与数据修复支付回调异常、分账延迟或待结算队列积压、钱包/俱乐部账与支付平台余额不一致、资金任务告警触发时，启动排查、资金修复、客户告知与复盘主责——跃竞后端负责人（当前：王子明·推断待确认）；协同——跃竞后端研发（当前：张楠、蒋兴武·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、商户运营（当前：宫经喜·推断待确认）、财务专员（当前：刘梦可·推断待确认）、V5 后端研发（当前：陈锦杰·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 发现与登记 → ② 止损与定级 → ③ 根因排查 → ④ 资金影响清单 → ⑤ 修复方案审批 → ⑥ 执行修复/手动分账 → ⑦ 财务复核与客户告知 → ⑧ 复盘与监控补齐已闭环的资金异常工单（含影响清单、修复记录、财务复核结论）、对受影响商户/俱乐部的书面告知、复盘结论与新增监控项待新建500
FIN-26网关月度账单导出与财务对账每月初财务需要上月网关账单（token 类与非 token 类计费），或财务提出新的账单字段/导出需求时启动主责——网关计费研发（当前：柯逸飞·推断待确认）；协同——财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、产品总监（当前：杨萌·推断待确认）、研发工程师（提供单价，当前：魏宗浩·推断待确认）、支付研发（当前：陈锦杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 月初定时导出 → ② 研发自检 → ③ CTO 审核口径 → ④ 推送财务 → ⑤ 财务对账 → ⑥ 差异提工单 → ⑦ 归档上月网关账单包（按上游、按 Key、按 API 三份 CSV + 字段说明）、财务对账结论、差异工单待优化108
FIN-27客户按量计费月度账单核算与发送按工作量、token 或调用量向客户收费的项目或 API 客户，每个结算周期核算用量、计算折扣、出具账单并发送收款时启动主责——客户项目研发对接人（当前：葛家和、李铭熙·推断待确认）；协同——创始人兼 CTO（定价折扣把关，当前：丁震宇·推断待确认）、COO（商务定价口径，当前：常元和·推断待确认）、研发工程师（工时数据，当前：魏宗浩·推断待确认）、财务专员（开票收款，当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 月度提醒 → ② 导出用量/工时 → ③ 按合同口径核算 → ④ 折扣与报价审核 → ⑤ 发送客户 → ⑥ 开票收款 → ⑦ 归档经审核的客户月度账单（用量明细 + 应收金额）、发送记录、开票与收款记录待优化180
FIN-28模型成本价、计价倍率维护与成本收入核对新增/调整上游渠道、官方调价、汇率变化、产品定价调整，或怀疑计价与成本不一致时，维护成本价与汇率、确定倍率/毛利/额度包并定期核对成本与收入主责——IT 运维/上游渠道维护（当前：杨明学·推断待确认）；协同——创始人兼 CTO（价格谈判与定价拍板，当前：丁震宇·推断待确认）、产品总监（定价档位与毛利，当前：杨萌·推断待确认）、网关计费研发（当前：柯逸飞、邓乾、张康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售骨干（对外报价需求，当前：闫登辉·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 变更触发登记 → ② 更新成本价主表 → ③ 定价/倍率审批 → ④ dry-run 同步网关 → ⑤ 上线核对 → ⑥ 通知相关方 → ⑦ 月度成本收入对账最新成本价主表（模型-渠道-币种-折扣-汇率-生效日期）、售价/倍率配置记录、月度成本收入对账报告待优化320
FIN-29计费扣费异常核查与退补客户或内部用户质疑扣费异常、单次报告/对话消耗远超预期、误调用高成本模型时，核算真实成本、判断是否多收、决定退补并校准计价口径主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——网关计费研发（当前：柯逸飞、邓乾·推断待确认）、后端研发（当前：陈锦杰、宋祺睿·推断待确认）、产品总监（客户口径，当前：杨萌·推断待确认）、渠道/客户对接研发（当前：陈子康·推断待确认）、测试负责人（定性，当前：张东郅·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 定级 → ③ 拉日志与成本 → ④ 按定价公式核算 → ⑤ 定性（计费错误/正常消耗/误调用） → ⑥ 修复 → ⑦ 退补审批 → ⑧ 答复客户与沉淀扣费异议核查报告（数据、结论、多收金额）、修复版本、退补审批单、客户答复记录待新建400
FIN-30云/模型服务成本按项目归集与账号台账月度云账单出具、需按项目归集云/模型成本、统计个人与项目 API 用量，或维护多主体云账号台账与回收发票时启动主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、创始人兼 CTO（账号持有与归集口径，当前：丁震宇·推断待确认）、Leap 研发负责人（IaC 规范，当前：王皓南·推断待确认）、后端/运维研发（当前：宋祺睿·推断待确认）、网关计费研发（当前：柯逸飞·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月初下载各平台账单与回单 → ② 按项目/标签筛选导出 → ③ 未归集资源补归属 → ④ 内部 API 用量按人/项目统计 → ⑤ 成本分摊入账 → ⑥ 发票回收 → ⑦ 台账更新月度按项目云/模型成本表、账号台账（平台-主体-用途-开票规则）、发票回收记录待优化81
FIN-31研发项目立项与研发费用归集新增研发项目需立项，或审计、税务（研发加计扣除、软件退税）要求立项资料、研发工时划分、费用归集与阶段性成果说明时启动主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（技术口径与人员划分，当前：丁震宇·推断待确认）、研发人员（工时填报）、客户端研发（阶段性成果材料，当前：葛家和·推断待确认）、行政（材料保密，当前：侯明月·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项三件套起草 → ② 技术补充与审批 → ③ 设科目与项目辅助核算 → ④ 月度工时填报 → ⑤ 费用归集 → ⑥ 季度成果沉淀 → ⑦ 审计/税务材料输出各研发项目立项三件套（立项申请书、可行性报告、股东会纪要）、月度人工成本核算表、按项目研发费用明细、阶段性成果说明待优化240
FIN-32多主体业务归属与子公司成本隔离子公司或关联主体使用母公司资源、采购服务或对外签约时，确认合同签署主体与采购/出货主体一致、子公司支出走本主体采购并归集、跨主体成本分摊与账目隔离主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（资源与支出审批，当前：丁震宇·推断待确认）、IT 采购（当前：杨明学·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、子公司业务负责人（当前：赵捷·推断待确认）、COO（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 业务发起时确定签约主体 → ② 校验采购/出货主体 → ③ 子公司支出走本主体采购 → ④ 跨主体资源使用申请 → ⑤ 按主体分账号/分 key → ⑥ 月度消耗对账与分摊 → ⑦ 切换与归档主体一致的合同与采购记录、子公司资源与 API Key 台账、跨主体资源使用批准记录、月度分摊对账表待新建200
FIN-33关联主体资金划转与注资集团内某主体（子公司/关联公司）账户余额不足以支付工资、税费、货款，或需实缴注册资本时，由其他主体向其划转资金主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定性审批）、创始人兼 CTO（当前：丁震宇·推断待确认，付款执行/审批）、法务负责人（当前：李瑶·推断待确认，协议与决议）；兜底——CEO① 月度资金预警 → ② 缺口测算与方案（借款/投资款） → ③ 管理层定性审批 → ④ 协议或股东决定 → ⑤ 付款申请与打款 → ⑥ 入账与凭证留存 → ⑦ 台账登记与还款/实缴跟踪按审批定性完成的资金划转、对应借款协议或注资决议、银行回单与注资证明、关联往来台账更新待新建120
FIN-34子公司月度营收统计与汇报每月第一周，子公司（当前为跃竞）导出上月营收（交易手续费、会费）与流水，按统一口径向董事会汇报主责——跃竞负责人（当前：徐莉·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认，定口径）、CEO（当前：邴龙志·推断待确认，审阅追问）、财务负责人（当前：黄梦婷·推断待确认，口径复核）；兜底——CEO① 每月 1 日提醒 → ② 导出汇付流水与会费数据 → ③ 按口径剔除余额支付等 → ④ 填月报模板 → ⑤ 群内提交摘要+明细 → ⑥ 董事会审阅追问 → ⑦ 归档并用于分润/奖金核算月度营收报告（文字摘要 + 会费统计表 + 商户汇总净额表），存档于固定位置待优化81
FIN-35月度税务申报与税额确认每月/每季度法定申报期内，完成各主体增值税、附加税、印花税、个税、企业所得税的测算、管理层确认与申报缴纳主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，税额确认）、代账会计（当前：待指定，外部协助）、人事负责人（当前：黄莹·推断待确认，人员异动）；兜底——CEO① 申报日历提醒 → ② 下载回单、核对开票与进项勾选 → ③ 测算税额与税负 → ④ 群内提交管理层确认 → ⑤ 个税按人员异动更新 → ⑥ 申报扣款 → ⑦ 保存完税凭证 → ⑧ 遗漏检查各主体按期完成的申报表、扣款回单与完税凭证，月度税额测算表存档已有180
FIN-36审计、尽调与投标财务资料准备年度审计、融资尽调、投标或申报需要经审计财务报告或成套财务资料时，从需求确认到资料提交的全过程主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，对外提交前合规检查）、销售/人事等业务部门负责人（当前：待指定，补票与访谈）、政策申报负责人（当前：王蕊·推断待确认，政府补助资料）；兜底——CEO① 接收需求（用途、截止日、口径）→ ② 发资料清单 → ③ 资料收集与缺票催收 → ④ 差异调账与三表勾稽 → ⑤ 配合审计访谈 → ⑥ 管理层合规检查 → ⑦ 出具提交 → ⑧ 归档审计报告或尽调/投标财务资料包（报表、序时账、科目余额表、申报表、银行流水、合同、补充说明），提交记录与归档待优化250
FIN-37财务人员交接、代账交接与整顿期汇报财务人员更换，或代账公司/异地主体（武汉、苏州等）账务转回内部时，完成交接、建账、补账，并在整顿期定期汇报进度主责——财务负责人（接手方，当前：黄梦婷·推断待确认）；协同——原财务人员（移交方，当前：祁航·推断待确认）、代账会计（当前：待指定）、CEO（当前：邴龙志·推断待确认，下达交接与跟进汇报）；兜底——CEO① 下达交接指令 → ② 移交清单（账户、税务、社保公积金、网银、海外收付款）→ ③ 代账资料逐项核对 → ④ 建账（科目、期初、辅助核算）→ ⑤ 差异调账与勾稽 → ⑥ 补做往期账务 → ⑦ 整顿期日报/周报 → ⑧ 交接确认签字双方签字的交接清单、完整的资料与权限移交、内部建好的账套（期初平衡）、整顿期汇报记录待优化250
FIN-38主体工商税务登记变更与注销子公司注销（含简易注销）、营业执照补领、办税员添加等主体工商税务登记事项的材料准备、办理与结果归档主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，决策与签字）、COO（当前：常元和·推断待确认，结果接收方/签字人，推断）、法务负责人（当前：李瑶·推断待确认，决议文件）、总经办（当前：田杰·推断待确认，证照归档）；兜底——CEO① 事项发起与决策 → ② 材料清单与决议 → ③ 税务前置申报/清算 → ④ 取得清税证明 → ⑤ 工商办理（公示）→ ⑥ 银行、社保等配套注销/变更 → ⑦ 回执归档并通知相关人办理完成的登记结果（注销回执/新执照/办税员权限）、扫描件归档于证照台账，相关人确认已收到待新建72
FIN-39资金计划与临时周转借款按月编制滚动资金计划，预判阶段性资金缺口；确需通过借款或银行授信等方式短期周转时，完成方案审批、协议签署、到账入账与还款跟踪主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 滚动资金计划与预警 → ② 缺口测算 → ③ 方案比选（股东借款/外部机构借款/银行授信）→ ④ 审批 → ⑤ 协议签署与用印 → ⑥ 到账入账 → ⑦ 还款计划与跟踪 → ⑧ 结清归档滚动资金计划、经审批的周转方案、签署的借款或授信协议、到账回单与入账凭证、还款台账及结清证明待新建75
FIN-40银行账户、网银 UKey 管理与付款复核各主体银行账户开立、变更、销户，网银 UKey 与密码保管、授权变更，以及每笔对公付款的制单—复核分离时适用主责——出纳（当前：待指定）；协同——付款复核人（当前：待指定）、法务（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 账户台账 → ② 开户/变更/销户审批 → ③ UKey 分离保管 → ④ 制单 → ⑤ 复核授权 → ⑥ 回单核对 → ⑦ 月度余额对账多主体银行账户台账、UKey 保管登记、付款制单与复核记录、月度银行余额调节表待新建80
FIN-41月度结账与管理报表每月结束后，对各主体完成费用、收入、成本、往来的入账与核对，出具财务报表与管理报表供管理层决策时适用主责——总账会计（当前：待指定）；协同——出纳（当前：待指定）、各业务部门（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 结账日历 → ② 业务单据截止 → ③ 银行与支付渠道对账 → ④ 收入成本确认与费用计提 → ⑤ 往来核对 → ⑥ 关账出表 → ⑦ 管理报表与分析各主体月度资产负债表、利润表、管理报表（收入、毛利、模型成本、人力成本、现金余额）待新建144
FIN-42年度企业所得税汇算清缴与研发费用加计扣除每年 1 月起至 5 月 31 日前，各主体完成上一年度企业所得税汇算清缴、研发费用加计扣除及高新技术企业相关指标核对时适用主责——税务会计（当前：待指定）；协同——研发项目负责人（当前：待指定）、人事（当前：待指定）、外部税务师（如有）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 制定汇算计划 → ② 年度账务调整 → ③ 研发费用辅助账与项目资料核对 → ④ 纳税调整测算 → ⑤ 管理层确认 → ⑥ 申报与缴补税 → ⑦ 资料留存备查各主体年度企业所得税申报表、研发费用辅助账与备查资料、补退税记录待新建75
FIN-43年度预算编制与执行分析年度/季度开始前编制各部门与各主体的收入、成本、费用、人力、算力预算，以及每月对比实际执行、超预算审批时适用主责——财务预算专员（当前：待指定）；协同——各部门负责人（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 下发预算模板与假设 → ② 部门编报 → ③ 财务汇总平衡 → ④ 管理层审定 → ⑤ 预算分解发布 → ⑥ 月度执行分析 → ⑦ 超预算审批与季度调整经审定的年度预算（按部门、主体、科目）、月度预算执行分析表待新建160
FIN-44政府补助资金到账、专款核算与验收审计科技项目、人才计划、上云补贴等政府补助资金到账后，进行确认、专款核算、按要求使用，并配合项目验收与专项审计时适用主责——总账会计（当前：待指定）；协同——政策申报专员（当前：待指定）、项目负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）① 到账识别 → ② 对应项目与资金性质确认 → ③ 设专项辅助核算 → ④ 按预算使用并留证 → ⑤ 定期执行报告 → ⑥ 验收/专项审计配合 → ⑦ 结余处理与归档补助资金台账、专项核算明细、验收与审计资料、结余处理记录待新建120
FIN-01对公采购申请与付款审批待优化320

状态：待优化｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：业务需以公司名义向外部供应商采购 IT/网络/算力/软件服务/硬件/家宽专线等，需要签合同或对公付款时启动。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购（当前：杨明学·推断待确认）、总经办采购发起（当前：田杰·推断待确认）、行政合同与用印（当前：侯明月·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 询价比价并确认可开票 → ② 提交“采购申请” → ③ 合同审核与用印 → ④ 技术审批与终审 → ⑤ 财务提“付款申请”制单 → ⑥ 复核打款 → ⑦ 回执给采购人提货/开工 → ⑧ 验收、发票回收入账
  • 交付结果：审批留痕完整的采购申请、已盖章合同、付款回单、合规发票、验收/资产登记记录与入账凭证；交付类采购同时拿到回执完成提货。
  • 状态依据：已有飞书“采购申请”“付款申请”审批和已盖章的采购制度，但 2026-03～08 多个群反复出现催审批、催打款约 20 次；采购与付款两段串行，大额单更慢；无票/二手设备入账、供应商入库资料归口每次临时询问。

1. 场景判定

  • 触发条件：需要以公司名义对外购买商品或服务且需合同或对公转账；含交付硬件当天加急、周期性专线/家宽/话费缴费、供应商要求补入库/入网协议。
  • 典型说法：「这一堆审批合同和对公，没两天搞不定」「加急一下，后面还得审呢」「Review 一下，没问题就提流程明天打了」「终于找到家能对公开票签合同的」「供应商入库是不是销售那边统一处理」
  • 判断问题：是不是以公司名义对外付款？需不需要合同或对公转账？供应商能否开公司抬头发票？
  • 不归本流程管：AI 订阅/模型账号/第三方 API Key 新购 → 请走 FIN-02；已有云/模型账户余额充值 → 请走 FIN-03；境外外币付款、无票支出 → 请走 FIN-04；小额零散先支后核 → 请走 FIN-05；员工已垫付的费用 → 请走 FIN-06。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
采购发起人 询价比价、确认开票能力、提交采购申请、跟踪到货验收 R IT 运维/采购（当前：杨明学·推断待确认）；总经办（当前：田杰·推断待确认）
合同与用印 合同流转、盖章、整理供应商入库资料 R 行政（当前：侯明月·推断待确认）
法务 大额或非标合同条款审核 C 法务负责人（当前：李瑶·推断待确认）
技术审批 判断技术必要性、供应商选择；加急单超时时拍板放行 A（升级） CTO（当前：丁震宇·推断待确认）
财务 审核单据、制单、付款、发回执、发票回收入账 R 财务负责人（当前：黄梦婷·推断待确认）
终审 金额终审与付款复核 A CEO（当前：邴龙志·推断待确认）
兜底 超时协调、制度修订 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 报价单（常规至少 1 家，金额较大按制度要求 3 家），写明规格、数量、期限、含税价
  • 供应商能否开公司抬头发票、票种（专票/普票）与税点
  • 供应商营业执照、对公收款信息——作为审批附件提交，不在群里明文发送
  • 合同文本（优先使用公司标准模板）
  • 付款主体（武汉模态/苏州模态/鼎慧/跃竞等）与费用归属项目
  • 期望到货/开工时间；如加急，写明加急理由与最晚付款时间
  • 二手或无票货源须事前写明，并附入账方式说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 询价比价，确认可开票、可对公 采购发起人 需求确定后 2 个工作日内 供应商台账（多维表格） 报价对比 👤人工判断
2 提交“采购申请”（用途、主体、金额、是否有票、是否二手、是否加急、附报价） 采购发起人 比价完成当天 飞书审批“采购申请” 采购审批单 🔧飞书固化
3 合同审核与用印；大额/非标合同转法务 行政；法务 收到后 1 个工作日内（法务 2 个工作日内） 飞书审批“用印申请” 盖章合同 🔧飞书固化
4 技术审批 + 终审 CTO；CEO 各 1 个工作日内；加急 4 小时内 飞书审批 通过的采购单 🔧飞书固化（超时自动催办、设代理审批人）
5 关联采购单提“付款申请”，审核附件并制单 财务 采购通过后 1 个工作日内 飞书审批“付款申请”、网银 付款单 🔧+🤖（采购通过自动生成付款单草稿）
6 付款复核与打款 财务；CEO 制单后 1 个工作日内；加急当天 网银 付款回单 👤人工判断
7 回单回传审批单，通知采购人提货/厂商开工 财务 打款后 2 小时内 飞书审批评论/机器人 付款回执 🔧飞书固化
8 到货验收、资产登记 采购发起人 到货后 2 个工作日内 资产台账 验收记录 🔧飞书固化
9 发票回收、验真、入账归档 财务 付款后 30 天内 发票插件、账务系统 记账凭证 🤖自动化（发票识别验真）

5. 交付物与模板

  • 交付物：采购申请单、盖章合同、付款申请单与回单、发票、验收/资产登记记录。
  • 建议模板/表单：
    • “采购申请”：采购类别（硬件/网络专线/软件服务/算力/办公）、付款主体、项目、用途、供应商、报价附件、金额、是否可开票及票种、是否二手、是否加急及理由、期望交付日期、是否需法务审核
    • “供应商台账”：供应商、类别、开票能力、税点、资质文件、对公收款信息（附件）、对接岗位、合作记录、是否入库
    • “通信费台账”：线路/号码类型、所在办公点、归属主体、缴费周期、到期日、发票方式、责任岗位

6. 异常与升级

  • 审批节点超 1 个工作日未处理 → 机器人自动催办 → 再超 4 小时升级综合部负责人
  • 加急（客户交付当天提货、厂商当天下班前）→ 申请单标“加急”并在财务群通知 → 2 小时内未进入制单，升级 CTO 拍板，CEO 当天审完
  • 供应商不能开票 → 优先更换可开票供应商；确需采购 → 转 FIN-04 无票支出例外审批（1 个工作日内）
  • 二手设备 → 只走对公二手渠道并取得票据；个人卖家渠道须事前由财务负责人确认可入账（1 个工作日内），否则不采购
  • 供应商要求补入库/入网协议、证照 → 行政 2 个工作日内整理；法人证件外发须 CEO 同意
  • 周期性专线/家宽/话费 → 到期前 5 个工作日由行政提付款申请；缴费验证码不得在群里传递；话费开票走财务流程
  • 先签合同、先个人垫付后补流程 → 登记为例外，月度复盘时通报环节原因
  • 升级条件：常规单由 CEO 终审（A）；加急单 2 小时内未进入制单时，由 CTO 拍板放行（A（升级）），CEO 当天补审

7. 衡量指标

  • 采购审批周期：提交到全部审批通过，目标常规 ≤ 2 个工作日、加急 ≤ 4 小时
  • 付款周期：采购通过到打款完成，目标 ≤ 2 个工作日
  • 催办次数：群内催审批/催打款消息数/月，目标较当前下降 70%
  • 发票回收率：付款后 30 天内取得发票的单数占比，目标 ≥ 95%
  • 事后补流程率：先付款/先签合同后补审批的单数占比，目标 ≤ 5%

8. 低效诊断

  • 现象：采购审批走完才能提付款，两段串行，大额单等待更久｜依据：「董事会专项沟通群」2026-08
  • 现象：终审节点单点，无超时提醒与代理审批，交付硬件当天付款需反复催｜依据：「客户A硬件交付群」2026-05、「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-06
  • 现象：报价确认后卡在终审等待通过｜依据：「【模态】总经办」2026-08
  • 现象：可开票供应商靠临时寻找，网络/节点类服务大量不可开票，无统一处理口径｜依据：「鸽子群模态分群」2026-04
  • 现象：合同是否过法务取决于“熟不熟”，合同先行流程后补｜依据：「董事会专项沟通群」2026-08
  • 现象：供应商入库资料归销售、采购还是行政不清，来回两轮｜依据：「董事会专项沟通群」2026-08
  • 现象：专线/家宽缴费无台账、号码持有人分散，断网后才发现欠费｜依据：「运维&综合对接群」2026-03、「运维&综合对接群」2026-04

9. 分支变体

  • 常规 vs 加急：同一审批单打“加急”标记，审批时限缩短为 4 小时，财务当天打款并发回执
  • 设备类（服务器、网络设备、打印机）须资产登记；服务类（专线、节点、订阅）须登记合同周期与续费提醒
  • 软件/系统采购（如金蝶模块、接口）：报价写明用户数、期限、账套，由总经办发起
  • 物流月结：企业账号月付，月底与各部门核对往来单据
  • 周期缴费（家宽/专线/话费）：行政维护通信费台账；话费开票走财务，不再由行政代充
  • 二手/无票设备：对公二手渠道 + 财务事前确认
  • 供应商入库/入网协议：行政准备资料，法人证件外发须 CEO 同意
  • 主体差异：武汉模态、苏州模态、鼎慧、跃竞分别为付款主体，发票抬头与付款主体一致

10. 待确认问题

  • 主责由财务负责人担任，还是设独立采购岗？
  • 采购审批与付款审批能否合并（采购通过自动生成付款单）？
  • 金额分级授权阈值是多少？采购制度中“小额授权部门/项目负责人”的规则是否仍有效？
  • CEO 审批超 24 小时是否设置代理审批人？由哪个岗位代理？
  • 哪些合同必须过法务（按金额、类型）？
  • 是否允许采购二手设备？入账需要哪些凭证？
  • 供应商台账由财务还是 IT 采购维护？
  • 家宽/专线/话费台账归行政还是 IT 运维？
FIN-02AI 工具订阅与第三方服务新购开通待新建192

状态：待新建｜证据：有证据（卡片 9 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：团队需要新购 AI 订阅席位、模型账号、第三方 API Key 或按量付费服务（含产品集成的第三方服务、内容团队试用的生成工具）时启动。
  • 负责人：主责——IT 资源与采购（当前：杨明学·推断待确认）；协同——CTO 用途与预算审批（当前：丁震宇·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）、NewAPI 网关管理员（当前：望政韬·推断待确认）、行政报销对接（当前：侯明月·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、CEO 超阈值审批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提需求（工具/用途/席位/预算）→ ② 官方渠道与付款主体核验 → ③ “AI 工具/服务开通申请”审批 → ④ 以公司账号开通并公司付款 → ⑤ 密钥接入 NewAPI/密钥库并限额 → ⑥ 登记服务台账 → ⑦ 到期/余额/封号提醒 → ⑧ 月度用量与成本复盘
  • 交付结果：以公司主体开通、可用且登记在台账的订阅/账号/Key，明确负责岗位、额度上限、到期日与成本归属。
  • 状态依据：2026-01～10 多个群反复出现“个人先买—口头报销—封号重买”、买错主体、Key 绑在个人账号、按量服务无余额预警；仅 LeapAll 平台内部充值有成文 SOP，其余每次临时处理。

1. 场景判定

  • 触发条件：首次购买某 AI 工具订阅/团队席位；新开第三方 API Key 或公司账号；产品要接入新的按量付费服务；试用新的生图/视频/模型平台。
  • 典型说法：「公司出钱报销，先来两个」「这个谁来充值下」「不小心用另一个主体买了」「直接买，先找财务报备，所有成本计到文档里」「等下，先别充钱」
  • 判断问题：这是新开通（本流程），还是已有账户续费/充值（FIN-03）？付款方是公司还是个人？服务是否来自官方渠道？
  • 不归本流程管：已有账户余额充值与欠费 → 请走 FIN-03；需外币/境外卡付款或无发票 → 付款环节请走 FIN-04；个人已垫付后的报销 → 请走 FIN-06；AI 订阅报销口径 → 请走 FIN-10；LeapAll 平台内部账号充值点数 → 按已发布的《LeapAll 充值申请 SOP》。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 说明用途、席位数、套餐、预估月费、试用期 R 需求方成员（当前：按需求方）
IT 资源与采购 核验官方渠道、确定主体、开通公司账号、维护台账与到期 R IT 资源与采购（当前：杨明学·推断待确认）
用途与预算审批 判断必要性、套餐与周期（试用优先月付、最低套餐） A CTO（当前：丁震宇·推断待确认）
业务线预算 鼎慧线订阅的预算认可 C 鼎慧负责人（当前：杨萌·推断待确认）
密钥与计费接入 Key 接入 NewAPI，分测试/生产 Key，设额度与告警 R NewAPI 网关管理员（当前：望政韬·推断待确认）
财务 公司付款、发票、成本归集 R 财务负责人（当前：黄梦婷·推断待确认）
超阈值审批 超过预算阈值的订阅/服务终审 A（升级） CEO（当前：邴龙志·推断待确认）
报销对接 小额试用费用报销 C 行政（当前：侯明月·推断待确认）
兜底 超预算、归属争议协调 I 综合部负责人（当前：赵雪冰·推断待确认）
机器人 到期/余额/封号自动提醒 I 飞书机器人（由 IT 资源与采购维护）

3. 办之前请准备

  • 工具/服务名称、官网链接，确认为官方渠道（非第三方代充站、非卖号渠道）
  • 用途、使用人与席位数、试用期限
  • 套餐与计费方式（包月/包年/按量），预估月费
  • 付款主体（武汉模态/苏州模态/鼎慧/跃竞）与成本归属项目
  • 能否开公司发票、是否需境外支付
  • 是否用于生产（生产 Key 需 IP 白名单/限额方案；测试 Key 需单独限额）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“AI 工具/服务开通申请” 申请人 需求出现当天 飞书审批 申请单 🔧飞书固化
2 核验官方渠道，比较价格/开票/支付方式，确定主体 IT 资源与采购 1 个工作日内 服务台账 核验结论 👤人工判断
3 用途与预算审批；超阈值转 CEO CTO；CEO 1 个工作日内 飞书审批 审批结论 👤人工判断
4 以公司邮箱/公司主体注册或开通企业号 IT 资源与采购 审批后 1 个工作日内 服务商后台 公司账号 👤人工判断
5 公司付款（对公/公司卡）；无法公司付款转 FIN-04 财务 审批后 1 个工作日内 飞书审批“付款申请” 付款回单 🔧飞书固化
6 Key 接入 NewAPI 或密钥库，分测试/生产，设额度上限与告警；禁止在群里发明文 Key NewAPI 网关管理员 开通后 1 个工作日内 NewAPI Key 配置记录 🤖自动化
7 登记台账（服务、主体、账号归属、负责岗位、席位成员、额度、到期日、发票方式） IT 资源与采购 开通当天 多维表格 台账条目 🔧飞书固化
8 到期/余额/封号提醒；月度用量与成本统计 IT 资源与采购；机器人 每月 5 日前 多维表格 + 飞书机器人 月度成本表 🤖自动化
9 试用期满评估续订或停用 申请人；CTO 试用到期前 3 个工作日 飞书任务 续停结论 👤人工判断

5. 交付物与模板

  • 交付物：开通申请单、公司账号、Key 配置记录、台账条目、付款回单/发票、月度成本表。
  • 建议模板/表单：
    • “AI 工具/服务开通申请”：工具名称、官网、渠道类型（官方/中转/代充）、用途、使用人与席位数、套餐、计费方式、预估月费、付款主体、项目、是否可开票、是否境外支付、试用期、生产/测试
    • “第三方服务台账”：服务、主体、账号注册邮箱（公司邮箱）、负责岗位、席位成员、额度上限、当前余额、到期日、发票方式、状态（在用/停用/封禁）

6. 异常与升级

  • 买错主体 → 当天联系服务商退款或转主体；不能退的计入实际主体成本并在台账备注 → 财务 1 个工作日内定处理口径
  • Key 或服务挂在个人账号 → 3 个工作日内迁移到公司账号；迁移前个人账号费用走 FIN-06 → 逾期升级 CTO
  • 额度申请自动审批未关、额度被刷 → 立即关闭自动审批并限额；损失报 CTO（当天）
  • 站点疑似非官方 → 停止付款，台账标记黑名单 → 已付款的报 CTO 当天处理
  • 账号被封/降级 → 申请人当天报 IT 资源与采购，评估换官方渠道；灰色渠道（礼品卡、卖号）原则禁止，例外须 CTO + 财务负责人审批
  • 公司卡无法支付海外订阅 → 转 FIN-04
  • 服务不支持多 Key/限额 → 由网关拆分测试与生产 Key 并在网关侧限额
  • 升级条件：常规申请由 CTO 审批（A）；金额超过 [阈值待财务确认] 或超出年度预算时转 CEO 终审（A（升级））

7. 衡量指标

  • 台账覆盖率：在用 AI 工具/第三方服务中已登记的比例，目标 100%
  • 个人账号承载公司服务数：目标 0
  • 开通周期：申请到可用，目标 ≤ 3 个工作日
  • 封号/假站/买错主体事件：每季度目标 0
  • 月度成本统计按时率：目标 100%

8. 低效诊断

  • 现象：先买后口头授权报销，无申请单与成本归属；同类订阅各自找渠道，价格差异大，封号后重买｜依据：「模态AI探索小分队」2026-04、「模态AI探索小分队」2026-05
  • 现象：第三方 Key 绑在个人账号，额度耗尽时无人知道由谁充值｜依据：「Leap产研测」2026-10
  • 现象：用错主体购买无法退款；额度申请自动审批未及时关闭｜依据：「鼎慧产研决策部」2026-06
  • 现象：上游中转站各自寻找、测试 Key 在群里传递，每个渠道单独适配｜依据：「跃迁AI总动员」2026-05
  • 现象：按量付费服务无余额预警与调用上限，付费方式需现场登录后台才查得到｜依据：「鼎慧产研决策部」2026-01
  • 现象：采购靠口头拍板，开发用个人账号承担公司用量｜依据：「某政府客户需求对接群」2026-01
  • 现象：充值前才发现站点非官方｜依据：「Seedance API + Nano Banana」2026-02
  • 现象：模型额度只能“申请预算走报销”，谁出钱不清｜依据：「公司内FDE」2026-09

9. 分支变体

  • 订阅类（Claude、Codex/ChatGPT workspace、Qoder 等）：优先团队版/企业版，试用期月付、最低套餐起步
  • 模型 API/中转站：统一接入公司 NewAPI 计费与 fallback；渠道准入与充值按 FIN-03 台账管理
  • 按量付费第三方服务（PPT 生成、爬虫、企业信息查询）：产品侧设单用户调用上限；测试与生产分 Key
  • 内容团队生成工具试用：小额试用审批 + 官方渠道核验后再充值
  • LeapAll 平台内部账号充值点数：按《LeapAll 充值申请 SOP》（飞书表单 → 管理层三位负责人审批 → 对接人加额度）
  • 境外支付或无票：申请走本流程，付款环节转 FIN-04

10. 待确认问题

  • 主责是否为 IT 资源与采购岗？还是由 CTO 统一归口？
  • 小额试用免审阈值是多少？超过多少须 CEO 审批？
  • 灰色渠道（礼品卡、卖号、代充）是否一律禁止？
  • 台账放在哪个多维表格？是否合并现有“AI 产品采购表”“按量付费表”？
  • 个人 AI 补贴与公司订阅的边界如何划分？
  • 是否办理公司统一虚拟卡用于海外订阅？
FIN-03上游模型/云服务/三方 API 账户充值与余额预警待优化225

状态：待优化｜证据：有证据（卡片 21 张 / 会话 19 个）｜优先级：频5 × 耗3 × 跨3 × 险5

  • 适用场景：公司已有的云厂商、模型厂商、中转渠道、三方 API、SaaS 席位账户余额低于预警线、欠费或账期到期时启动。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——云资源与账户监控（当前：宋祺睿·推断待确认）、IT 运维与渠道（当前：杨明学·推断待确认）、CTO 技术审批（当前：丁震宇·推断待确认）、CEO 终审（当前：邴龙志·推断待确认）、鼎慧负责人（当前：杨萌·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 余额自动监控告警 → ② 确认充值需求（金额/主体/账户）→ ③ 财务统一提“付款申请” → ④ 技术审批 + 终审 → ⑤ 核验账户后汇款 → ⑥ 到账确认并通知 → ⑦ 消耗后开票回收 → ⑧ 月度对账复盘
  • 交付结果：账户恢复到目标余额且服务不中断；付款申请、回单、到账记录、发票在账户台账中一一对应。
  • 状态依据：已有飞书“付款申请”审批，财务已承担云充值提单；但 2026-01～10 多次因欠费导致生产服务宕机或用户报 402，财务群催打款约 12 次，余额靠人发现，提单人口径不一。

1. 场景判定

  • 触发条件：控制台/邮件/机器人余额预警；用户或测试报 402/401/欠费；云账期结算；SaaS 席位不足需加购；节假日前预充。
  • 典型说法：「上游没钱了，冲一下 asap」「充钱也很慢，要等审」「选右上角那个对公，然后把那串信息发给财务」「收到余额预警邮件，需要处理吗」「云厂商那边咋还没打款」
  • 判断问题：账户是否已在公司名下并登记台账？是充值/续费（本流程）还是新开通（FIN-02）？是否需外币支付？
  • 不归本流程管：新开账户/新订阅 → 请走 FIN-02；美元充值、境外信用卡、无票支出 → 请走 FIN-04；个人已垫付的报销 → 请走 FIN-06；客户回款入公司账户 → 请走 FIN-21（收入合同台账、回款跟进）；客户充值到账 → 请走 FIN-17。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账户监控 维护预警线、发现余额不足、提出充值需求（金额+原因+预计用量） R 云资源与账户监控（当前：宋祺睿·推断待确认）；IT 运维与渠道（当前：杨明学·推断待确认）
财务 统一提付款申请、核对收款账户与主体、汇款、到账确认、开票回收 R 财务负责人（当前：黄梦婷·推断待确认）
技术审批 判断用量与金额合理、渠道选择、排查异常用量；加急时授权先付 A（升级） CTO（当前：丁震宇·推断待确认）
终审 付款终审 A CEO（当前：邴龙志·推断待确认）
业务线负责人 鼎慧线预算认可、限制高价模型 C 鼎慧负责人（当前：杨萌·推断待确认）
对外沟通 服务中断时通知用户切换模型 I Leap 研发负责人（当前：王皓南·推断待确认）
兜底 超时升级协调 I 综合部负责人（当前：赵雪冰·推断待确认）
机器人 每日拉取余额并推送预警 I 飞书机器人（由账户监控岗位维护）

3. 办之前请准备

  • 账户台账信息：平台、主体（武汉模态/苏州模态/鼎慧/跃竞）、账户 ID、用途（生产/测试）
  • 平台生成的对公充值汇款信息截图，确认收款账户对应该账户 ID
  • 当前余额、近 30 天日均消耗、预计可用天数
  • 建议充值金额及依据（按 N 天用量计算）
  • 是否预付、能否开票及开票时点（预付多为消耗后开票）
  • 是否加急（预计 2 天内停服即为加急）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 每日拉取各账户余额，低于预警线推送群和负责人 机器人；账户监控 每日 多维表格 + 飞书机器人 预警消息 🤖自动化
2 确认充值需求（金额、主体、账户、是否加急）；用量异常先排查 账户监控；CTO 预警后 4 小时内 飞书任务 充值需求 👤人工判断
3 财务统一提“付款申请”（事由、主体、是否预付、附汇款信息与余额截图） 财务 收到需求 1 个工作日内；加急 2 小时内 飞书审批“付款申请” 申请单 🔧飞书固化
4 技术审批 + 终审 CTO；CEO 各 4 小时内；加急 1 小时内 飞书审批 审批通过 🔧飞书固化（超时自动催办）
5 汇款前核验收款账户、账户 ID 与主体，再打款 财务 审批通过当天 网银 回单 👤人工判断
6 到账确认，更新台账余额并在群里通知 财务；账户监控 打款后 1 个工作日内 账户台账 到账记录 🔧飞书固化
7 消耗后申请发票，回收入账 财务 每月 10 日前 平台发票中心 发票 🤖自动化
8 月度对账：充值、消耗、汇率、发票对齐，调整预警线 财务；账户监控 每月 10 日前 多维表格 / 账单分析脚本 月度对账报告 🤖自动化

5. 交付物与模板

  • 交付物：付款申请单、回单、到账记录、发票、月度账户对账报告。
  • 建议模板/表单：
    • “上游账户台账”：平台、主体、账户 ID、用途（生产/测试）、负责岗位、计费方式（预付/后付）、预警线、目标余额、近 30 天消耗、开票方式、发票接收邮箱（财务邮箱）、上次充值日期
    • “充值付款申请”固定字段：平台、主体、账户 ID、金额、是否预付（默认是）、是否加急、余额截图、汇款信息附件、预计可用天数

6. 异常与升级

  • 已欠费停服 → 研发先切备用渠道或禁用高价模型，并通知用户 → 走加急审批，1 小时未批升级 CEO
  • 加急且审批来不及 → 由 CTO 授权使用公司卡小额先付；个人垫付须登记台账并 3 个工作日内走 FIN-06 报销
  • 汇款未到账或被其他账户认领 → 财务当天联系平台客服挪账，不重复汇款 → 2 个工作日未解决升级 CTO
  • 用量异常暴涨 → 先限流/禁用高价模型 → CTO 当天排查
  • 节假日 → 节前 3 个工作日按假期天数预充
  • 供应商起充门槛、折扣申请 → 综合部与供应商协商，5 个工作日内反馈结果
  • 云账单发票邮箱与告警邮箱混用 → 发票统一进财务邮箱，告警进技术群
  • 升级条件：常规充值由 CEO 终审（A）；已停服或预计 2 天内停服且审批来不及时，由 CTO 授权公司卡小额先付（A（升级）），CEO 事后 1 个工作日内补审

7. 衡量指标

  • 欠费停服次数：每月目标 0
  • 预警到到账时长：目标 ≤ 1 个工作日（加急 ≤ 4 小时）
  • 催打款消息数：月度较当前下降 80%
  • 账户台账覆盖率：目标 100%
  • 发票回收率：消耗后 30 天内取得发票占比 ≥ 95%

8. 低效诊断

  • 现象：无余额监控，欠费靠用户报错才发现｜依据：「Leap反馈群」2026-06、「Leap产研测」2026-06
  • 现象：充值终审节点慢，生产服务停摆一天｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-07
  • 现象：谁来提充值单不统一，申请单“是否预付”等字段填错｜依据：「鼎慧产研决策部」2026-05
  • 现象：汇款后到账慢，靠反复催问｜依据：「财务部」2026-04、「财务部」2026-09
  • 现象：多层网关与测试环境余额难定位，测试额度过低频繁中断｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：渠道充值金额靠口头决定，发票推进靠上级提醒｜依据：「Leap产研测」2026-08
  • 现象：先垫付后找发票，第三方渠道开不了公司发票｜依据：「鼎慧产研决策部」2026-03、「New API Claw SKILL计划」2026-03
  • 现象：渠道选择与采购比例多次调整｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：业务群出现欠费不可用、供应商起充审批久无反馈｜依据：「【模态】行业版leapcore」2026-06、「【模态】开放生态」2026-07、「【模态】董事会&法务」2026-10

9. 分支变体

  • 按主体：武汉模态/苏州模态/鼎慧/跃竞各自账户；跃竞模型账号单独建，避免账目混用
  • 同一平台多个账户（如同一云厂商下多个账户）：汇款前按台账核对账户 ID
  • 预付充值（各云厂商）：消耗后出发票
  • 后付费账单（海外网关等）：账单日前 3 天提付款，外币支付转 FIN-04
  • 中转渠道：家数控制在约定上限内，控制单渠道充值金额，优先能开发票的渠道
  • SaaS 席位加购（如飞书席位）：用人部门提需求，同流程付款
  • 测试环境 Key：设预算上限与自动告警
  • 节前预充

10. 待确认问题

  • 云/模型充值是否统一由财务提单？零散小额是否由 IT 运维提？
  • 各账户预警线、目标余额按多少天用量设定？
  • 加急情况下公司卡小额先付的授权额度？
  • CEO 终审超时是否设代理审批人？
  • 余额监控机器人由哪个岗位开发维护？
  • 海外后付费账单归本流程还是 FIN-04？
  • 客户回款入账已分流至 FIN-21，本流程不再处理，是否认可？
FIN-04境外服务外币付款与无票支出处理待新建240

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：需要向境外 AI 服务、网关、订阅、云服务支付外币，或支出无法取得国内合规发票时启动。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CTO 需求审批（当前：丁震宇·推断待确认）、IT 运维流程指引（当前：杨明学·推断待确认）、CEO 例外审批与公司卡（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 先找可开票/对公替代渠道 → ② 提“境外/无票支出申请” → ③ CTO、财务、CEO 审批 → ④ 公司外币卡或对公外币付款 → ⑤ 平台账号登记台账 → ⑥ 留存 Invoice 与付款凭证 → ⑦ 按无票支出入账核销
  • 交付结果：用公司支付工具完成的境外付款，附审批单、平台 Invoice/账单、付款凭证与无票说明，可入账、可审计。
  • 状态依据：2026-04～10 境外充值多次依赖个人或他人信用卡，卡被风控后临时救火；公司 VISA 卡方案提出后至 10 月仍未落地；无票支出出现“用其他票据替代”的提议，无成文规则。

1. 场景判定

  • 触发条件：境外平台只支持信用卡/美元付款；境外供应商要求对公外币签合同；梯子、中转站等国内无票支出。
  • 典型说法：「后面公司想办法往里面打美元就行」「抛开合规不谈，不能开票最麻烦」「企业用的 VISA 卡有方案吗」「要走 4 个流程？也太复杂了」
  • 判断问题：有没有可开公司发票的国内替代渠道？金额与必要性是否值得走例外？能否用公司支付工具付款？
  • 不归本流程管：有国内发票的对公采购 → 请走 FIN-01；国内账户充值 → 请走 FIN-03；新订阅/新账号的需求审批 → 请走 FIN-02（付款环节回到本流程）；汇率成本核算 → 请走 FIN-28。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 说明平台、用途、外币金额、无票原因、已尝试替代渠道 R 需求方研发/产品（当前：按需求方）
需求审批 判断必要性与替代渠道 R CTO（当前：丁震宇·推断待确认）
财务 选择付款方式、付款、凭证留存、入账核销 R 财务负责人（当前：黄梦婷·推断待确认）
例外审批 批准无票支出、个人卡例外；公司卡持卡人 A CEO（当前：邴龙志·推断待确认）
外币渠道建设 协调银行办理公司外币卡、合作主体代付协议 R 综合部负责人（当前：赵雪冰·推断待确认）
流程指引 维护“境外/无票支出指引”、AI 补贴规范 R IT 运维（当前：杨明学·推断待确认）
法务 境外合同与代付合规意见 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 平台名称、官网、计费页截图
  • 币种、金额、付款周期、用途、使用人
  • 无法开票的原因，已尝试的国内可开票替代渠道
  • 平台账号注册邮箱（须为公司邮箱）
  • 平台能否下载 Invoice/Receipt
  • 归属主体与项目、核销期限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 检查替代渠道：国内可开票代理/对公中转 申请人；IT 运维 1 个工作日内 供应商台账 替代结论 👤人工判断
2 提“境外/无票支出申请”（一张单覆盖采购与预支，不再拆四个流程） 申请人 当天 飞书审批 申请单 🔧飞书固化
3 CTO 审批 → 财务审核 → CEO 例外审批 CTO；财务；CEO 各 1 个工作日内 飞书审批 审批通过 🔧飞书固化
4 公司外币卡/对公外币账户付款；无公司卡时由财务按审批指定代付方式 财务 审批后 1 个工作日内 公司外币卡/网银 付款凭证 👤人工判断
5 平台账号登记台账（平台、主体、注册邮箱、支付工具、余额、到期日） IT 运维 付款当天 多维表格 台账条目 🔧飞书固化
6 下载 Invoice/账单与付款截图上传审批单 申请人 付款后 3 个工作日内 飞书审批附件 凭证包 🤖+👤
7 按“无票支出”入账，月度汇总境外支出 财务 次月 10 日前 账务系统 入账凭证、月度汇总 👤人工判断

5. 交付物与模板

  • 交付物：审批单、平台 Invoice/Receipt、付款凭证、无票说明、台账条目、月度境外支出汇总。
  • 建议模板/表单：“境外/无票支出申请”——平台/供应商、所在国家地区、用途、币种与金额、折合人民币、付款方式（公司外币卡/对公外币/代付/个人卡例外）、是否预付、无票原因、已尝试替代渠道、核销期限、归属主体、项目、使用人。

6. 异常与升级

  • 公司卡被风控 → 财务当天联系发卡行；仍无法付款 → CEO 1 个工作日内决定是否合作主体代付
  • 个人卡垫付（例外）→ 须事前 CEO 审批；付款后 3 个工作日内凭 Invoice 走还款/报销
  • 发现用其他票据替代 → 一律退回，报财务负责人，月度通报环节问题
  • 平台账号被风控/封禁 → 申请人当天报 IT 运维评估迁移 → 余额损失报 CTO
  • 境外供应商改为对公签合同 → 合同环节转 FIN-01，付款仍按本流程外币支付
  • 申请人不清楚走哪个流程 → 先在财务群提问，财务当天给出路径并补进指引

7. 衡量指标

  • 公司支付工具占比：境外付款中用公司卡/对公外币的笔数占比，目标 ≥ 90%
  • 个人卡垫付次数：每月目标 0（例外须有审批）
  • 凭证完整率：审批单 + Invoice + 付款凭证齐全的占比，目标 100%
  • 境外付款周期：申请到付款完成 ≤ 3 个工作日
  • 替票事件：目标 0

8. 低效诊断

  • 现象：公司无境外支付工具，依赖个人或他人信用卡，卡被风控后临时救火｜依据：「鼎慧产研决策部」2026-05
  • 现象：无票支出无规则，出现用其他票据替代的提议；跨境支付路径过长｜依据：「随便瞎聊啦～」2026-04
  • 现象：无票海外采购需拆成采购申请、备用金申请、核销、退回四个流程，申请人不知走哪个｜依据：「LeapPPT」2026-05
  • 现象：公司外币卡方案长期未落地，供应商改为对公签合同后流程更长｜依据：「【模态】总经办」2026-04、「【模态】总经办」2026-05、「【模态】总经办」2026-10

9. 分支变体

  • 海外网关预充值（AI Gateway 等）：预付，平台出 Receipt
  • 海外后付费账单（云/网关）：账单日前付款
  • 编码工具订阅（月付）：开通申请走 FIN-02，付款走本流程
  • 对公外币合同供应商：合同走 FIN-01，付款走本流程
  • 合作主体代付：须有代付协议与法务意见
  • 国内无票支出（梯子、中转站等）：例外审批，设单笔与月度上限
  • 境外域名等小额年费

10. 待确认问题

  • 公司外币卡是否已办理？持卡与保管岗位是谁？
  • 无票支出的单笔、月度上限是多少？
  • 采购申请 + 备用金四个流程能否合并为一张“境外/无票支出申请”？
  • 是否允许个人卡例外？例外的审批人是谁？
  • 合作主体代付是否合规？是否需法务出具意见？
  • 汇率按付款日还是入账日计算？
FIN-05备用金/费用预支申请与核销待优化144

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：研发/运维需先支付小额零散费用（硬件测试零件、算力、AI 账号、手机号卡、月付订阅），且来不及对公付款或暂时没有发票时启动。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维/采购申请人（当前：杨明学·推断待确认）、CTO 审批（当前：丁震宇·推断待确认）、CEO 特批（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 判断是否适用备用金 → ② 提“备用金申请”并关联采购申请 → ③ CTO 审批（超限 CEO 特批）→ ④ 财务打款 → ⑤ 使用并取票 → ⑥ 提“备用金核销” → ⑦ 余额走还款退回公户
  • 交付结果：审批留痕的备用金，按期核销、余额退回，每笔支出有发票或经批准的无票说明。
  • 状态依据：已有飞书“采购申请”“备用金申请/核销/还款”审批，但 2026-05～09 出现一笔需求两张单被误认为重复、制度“不能提大额备用金”与硬件验证需求冲突、群内口头“已批”代替审批、财务不在岗导致打款顺延。

1. 场景判定

  • 触发条件：多批次小额采购；供应商只接受即时付款；月付订阅/号卡需要周期预支。
  • 典型说法：「申请一批备用金做实际验证」「备用金没办法关联采购审批」「自己垫资还是太原始了」「这东西不应该申请一下长期财务预支吗」
  • 判断问题：能否在 2 个工作日内对公付款？能就走 FIN-01。是否必须先付款后取票？上一笔备用金是否已核销？
  • 不归本流程管：可对公付款的采购 → 请走 FIN-01；已垫付的费用 → 请走 FIN-06；境外外币/无票 → 请走 FIN-04；核销时缺票 → 请走 FIN-12。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提申请、使用、收集票据、按期核销与退回 R IT 运维/采购（当前：杨明学·推断待确认）及其他研发申请人
审批 用途与额度审批 A CTO（当前：丁震宇·推断待确认）
特批 超限额、免票类特批 A（升级） CEO（当前：邴龙志·推断待确认）
财务 配置审批联动、审核、打款、核销、追缴 R 财务负责人（当前：黄梦婷·推断待确认）
兜底 逾期未核销协调 I 综合部负责人（当前：赵雪冰·推断待确认）
提醒机器人 到期未核销自动提醒 I 财务维护的提醒机器人

3. 办之前请准备

  • 采购清单：品类、数量、预估单价与合计
  • 用途与所属项目、归属主体
  • 预计使用期间与核销日期
  • 预计取票方式（能否开公司发票）
  • 是否为月付周期预支（写明周期与每期金额）
  • 名下是否有未核销备用金（有则先核销）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照指引判断是否适用备用金 申请人 采购前 财务指引/机器人 判断结论 🤖+👤
2 提“备用金申请”，在同一单关联“采购申请” 申请人 采购前 1 个工作日 飞书审批（联动表单） 申请单 🔧飞书固化
3 审批；超限额转 CEO 特批 CTO；CEO 1 个工作日内 飞书审批 审批通过 🔧飞书固化
4 审核并打款；财务不在岗时由 AB 角处理 财务 审批后 1 个工作日内 网银 打款回单 🔧+👤
5 使用并收集发票（抬头为归属主体）、订单、验收记录 申请人 使用期间 — 票据 👤人工判断
6 提“备用金核销”，附票据 申请人 使用结束后 15 天内；月付按月 飞书审批 核销单 🔧飞书固化
7 审核核销，余额走“还款”退回公户 财务 核销提交后 2 个工作日内 飞书审批、网银 核销完成 🔧飞书固化
8 到期前 3 天与到期当天自动提醒未核销 提醒机器人 自动 多维表格 + 机器人 提醒 🤖自动化

5. 交付物与模板

  • 交付物：备用金申请单（含关联采购单）、打款回单、核销单与票据、还款记录。
  • 建议模板/表单：“备用金申请”——申请人、部门、项目、归属主体、用途、采购清单、金额、类型（单笔/月付周期）、预计核销日期、预计取票方式、关联采购单、是否超限额及特批理由；“备用金台账”——申请单号、金额、打款日、已核销金额、余额、到期日、状态。

6. 异常与升级

  • 名下有未核销备用金 → 系统拦截新申请，先核销
  • 超出制度限额 → 写明理由走 CEO 特批，1 个工作日内答复
  • 核销缺票 → 转 FIN-12；无票支出 → 转 FIN-04
  • 核销逾期 → 机器人提醒；逾期 15 天升级 CTO 与财务负责人
  • 群内口头批准 → 财务不予打款，须补审批单
  • 财务人员不在岗 → AB 角当天接手
  • 升级条件：常规备用金由 CTO 审批（A）；超出制度限额或申请免票时转 CEO 特批（A（升级）），1 个工作日内答复

7. 衡量指标

  • 核销及时率：到期前完成核销的笔数占比，目标 ≥ 90%
  • 平均占用天数：打款到核销完成，目标 ≤ 30 天
  • 重复提单数：一笔需求多张单的次数，目标 0
  • 口头批准打款数：目标 0
  • 打款周期：审批通过到打款 ≤ 1 个工作日

8. 低效诊断

  • 现象：采购申请与备用金申请无法关联，一笔需求两张单，曾被误认重复作废｜依据：「财务小群」2026-05
  • 现象：制度不允许大额备用金，与硬件验证需求冲突，特批无模板｜依据：「财务小群」2026-07
  • 现象：申请人不知道如何申请预支，依赖他人代提；每次买号重新讨论付款方式｜依据：「跃迁基座许愿机」2026-05
  • 现象：群内口头批准代替审批，打款依赖财务在岗，节点缺位时顺延｜依据：「leapcore软硬件交付」2026-07、「leapcore软硬件交付」2026-09

9. 分支变体

  • 硬件验证类：多批次小额，按批次核销
  • 研发测试机/订单硬件：能对公的转 FIN-01
  • AI 账号、服务器、手机号卡等单笔预支：单笔核销
  • 月付订阅/续费：周期预支，按月核销；企业支付工具（如“模态用呗”）绑定固定负责岗位
  • 大额/免票：CEO 特批

10. 待确认问题

  • 备用金单笔与个人累计上限是多少？哪些场景可进特批白名单？
  • 采购申请与备用金申请能否在飞书配置为联动表单？
  • 核销期限 15 天是否可行？月付订阅的核销节奏？
  • 财务打款的 AB 角是谁？
  • 企业支付工具的使用范围与负责岗位？
  • 兜底岗位是否为综合部负责人？
FIN-06日常费用报销提交与审核待优化180

状态：待优化｜证据：有证据（卡片 15 张 / 会话 12 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：员工因公垫付办公采购、设备、餐费、耗材、零食福利、打车、通信、云服务等费用后需要报销时启动。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——行政（报销表单通知、票据收集、垫付打车报销，当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、各部门直属上级（当前：按申请人）、CEO 终审（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 对照可报销清单判断 → ② 取得合规发票（抬头为所属主体）→ ③ 飞书“费用报销”提单 → ④ 直属上级审批 → ⑤ 财务审核 → ⑥ 终审 → ⑦ 制单打款并回传回单 → ⑧ 票据整理归档
  • 交付结果：已付款的报销单，附合规发票、付款凭证与回单，可入账、可审计。
  • 状态依据：财务已于 2026-04 配置费用报销审批并编写费用报销 SOP，执行基本稳定；但 2026-01～08 员工反复在群里问“能不能报”“选哪个类型”“报销表在哪”，附件不全退回、主体选错、缺票较多。

1. 场景判定

  • 触发条件：员工个人先付款的因公费用，需要公司报销。
  • 典型说法：「能不能报销流量」「零食报销选哪个」「都要啥类目的发票呢」「报销流程的文件有发布吗？我找不到了」「有票吗？有的话提票报销最快」
  • 判断问题：是否因公？有没有合规发票、抬头是否为本人劳动关系所属主体？是不是差旅、AI 订阅或打车通勤？
  • 不归本流程管：差旅 → 请走 FIN-07；企业滴滴与通勤打车规则 → 请走 FIN-08；AI 订阅/模型费用报销口径 → 请走 FIN-10；无票支出 → 请走 FIN-04；备用金核销 → 请走 FIN-05；对供应商付款 → 请走 FIN-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 取票、提单、补件 R 全体员工（当前：按申请人）
直属上级 审真实性与必要性 R 部门负责人（当前：按申请人）
行政 发布表单入口、收集登记票据、处理企业滴滴不足时的垫付报销 R 行政（当前：侯明月·推断待确认）；行政负责人（当前：胡则瑾·推断待确认）
财务 审核附件与合规、制单打款、维护可报销清单、月度核对 R 财务负责人（当前：黄梦婷·推断待确认）
终审 按金额分级终审 A CEO（当前：邴龙志·推断待确认）
兜底 口径争议、超时协调 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 发票（电子 PDF 或纸质），抬头与税号为本人所属主体
  • 付款截图或订单记录
  • 用途说明、所属项目
  • 招待费：参与人名单（两人以上签字，单人由直属领导签字或附发票 + 付款记录）
  • 设备类：资产登记信息（型号、使用人）
  • 零食福利：所属项目组额度

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照“可报销清单”判断能否报、选哪个类型 申请人 消费前 知识库 FAQ / 答疑机器人 判断结论 🤖+👤
2 取票：抬头为所属主体；线下难开票优先网购 申请人 消费当天 — 发票 👤人工判断
3 提“费用报销”：选类型与归属公司，上传发票（自动识别金额），附付款截图 申请人 消费后 30 天内 飞书审批 + 发票插件 报销单 🔧+🤖
4 直属上级审批 直属上级 1 个工作日内 飞书审批 审批通过 🔧飞书固化
5 审核附件、金额、制度符合性；缺件一次性列清退回 财务 2 个工作日内 飞书审批 + 验真查重插件 审核结论 🤖+👤
6 按金额分级终审 CEO 1 个工作日内 飞书审批 终审通过 🔧飞书固化
7 制单打款，回单回传审批单 财务 终审后 2 个工作日内 网银 回单 🔧+👤
8 纸质票据集中整理贴票归档；月度与银行流水、审批数据核对 财务（可兼职协助） 每月 10 日前 多维表格 归档、对账表 🔧飞书固化

5. 交付物与模板

  • 交付物：费用报销单、发票、付款凭证、回单、月度对账表。
  • 建议模板/表单：
    • “费用报销”字段顺序：费用类型 → 归属公司（按人员所属主体自动带出）→ 项目 → 上传发票 → 金额（由发票识别带出）→ 付款截图 → 用途说明 → 招待参与人（类型为招待费时必填）
    • “可报销清单”：费用类型、可报/不可报、票据要求、额度、审批人、常见问题（如药品、流量、零食、工作餐、耗材是否入库）

6. 异常与升级

  • 归属主体选错 → 退回更正；人员跨主体调动时人事同步财务与审批表单
  • 缺票 → 转 FIN-12；无法取得发票 → 转 FIN-04 例外审批
  • 招待费单人 → 直属领导签字或附发票 + 付款记录
  • 员工个人设备转让给公司 → 不按普通报销，须事前审批并由财务评估个税
  • 提单后超 5 个工作日未付款 → 申请人在审批单催办 → 财务负责人 1 个工作日内答复
  • “能否报销”有争议 → 财务负责人 1 个工作日内答复，并补入可报销清单
  • 互借、拼凑他人发票 → 禁止，发现即退回
  • 企业滴滴余额不足导致的打车垫付 → 按本流程报销，用车规则见 FIN-08

7. 衡量指标

  • 报销周期：提单到打款，目标 ≤ 7 个自然日
  • 一次通过率：未被退回补件的报销单占比，目标 ≥ 85%
  • “能否报销”群内咨询次数：每月较当前下降 70%
  • 主体错误率：选错归属公司的单占比，目标 ≤ 2%
  • 月末缺票余额：逐月下降

8. 低效诊断

  • 现象：报销流程文件、表单入口找不到｜依据：「模态集团（全员群）」2026-04、「随便瞎聊啦～」2026-02
  • 现象：可报销范围没有清单，药品、流量、采购能否报靠群里问｜依据：「随便瞎聊啦～」2026-04、「随便瞎聊啦～」2026-07
  • 现象：报销类型选择与项目组零食额度口径不清，个人订阅与公司费用边界靠口头｜依据：「鼎慧产研决策部」2026-05
  • 现象：归属主体与人员劳动关系不一致，需人工提醒｜依据：「鼎慧产研决策部」2026-06
  • 现象：表单字段顺序误导、报销表格式损坏需重做｜依据：「【模态】综合部」2026-04、「鸽子群模态分群」2026-01
  • 现象：招待费签字规则员工不理解｜依据：「【模态】总经办」2026-04
  • 现象：附件不全被退回补充｜依据：「财务部」2026-06
  • 现象：先买后补票、垫付后忘记报销｜依据：「公司建设大改造」2026-03、「公司建设大改造」2026-04
  • 现象：供应商开票能力靠群里问｜依据：「鸽子群模态分群」2026-03

9. 分支变体

  • 按主体：鼎慧、武汉模态、苏州模态、跃竞人员按劳动关系所属主体报销
  • 零食福利：按项目组额度，跨组挪用须项目负责人确认
  • 招待费：两人以上签字
  • 办公采购/设备：须资产登记；3D 打印等耗材按材料记库存
  • 房租、押金：优先对公支付；房东不开票的按 CEO 决定的口径开普票
  • 无发票礼品：改用可开票的礼品卡/电子卡
  • 企业滴滴不足时打车垫付：截图 + 发票报销

10. 待确认问题

  • 终审的金额分级阈值是多少？小额是否由直属上级终审？
  • 可报销清单由财务发布在哪个知识库入口？
  • 零食额度是否按项目组划分？工作餐能否报？
  • 报销提交时限 30 天是否可行？跨月处理口径？
  • 员工个人设备转让给公司的处理规则？
  • 是否启用发票识别、验真查重插件为必选？
FIN-07差旅事前报备与差旅报销待优化108

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：员工因公到外地或境外出差、参会、拜访客户时，从事前报备到报销付款全程适用。
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——综合部（差旅制度与行程单简化，当前：赵雪冰·推断待确认）、销售负责人（审批链节点，当前：李鹏为·推断待确认）、COO 差旅标准制定（当前：常元和·推断待确认）、CEO 特批与制度梳理（当前：邴龙志·推断待确认）、市场部（报销填单 AI skill，当前：陈芷青·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 出差前提“出差报备” → ② 直属上级审批（超标/境外加特批）→ ③ 出行并收集电子发票 → ④ 生成往返闭环行程单 → ⑤ 提“费用报销”关联报备 → ⑥ 财务审核 → ⑦ 打款 → ⑧ 参会成果文档归档（如适用）
  • 交付结果：已付款的差旅报销单，关联出差报备，附闭环行程单、发票和（如适用）特批记录与参会成果文档。
  • 状态依据：飞书出差报备与费用报销审批已在用，住宿/餐费已统一为部门主管标准；但 2026-07 出现漏单程票整单退回、住宿超标争议、审批链需每天催，管理层提出加特批分支但尚未落地。

1. 场景判定

  • 触发条件：离开常驻城市因公出行；参加国内外会议；以公司名义参会展示。
  • 典型说法：「该省的省了，该报的报不下来」「加一个特批流程吧」「后面出差前提个出差报备」「发票丢进去，说帮我填表，会生成报销单」
  • 判断问题：是否离开常驻城市因公出行？是否已事前报备？是否超标准？
  • 不归本流程管：市内打车、通勤 → 请走 FIN-08；非差旅日常费用 → 请走 FIN-06；境外会议注册费等外币付款 → 请走 FIN-04。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
出差人 事前报备、收集票据、提报销、补说明 R 全体员工（当前：按出差人）
直属上级 审批出差必要性与费用合理性 A 部门负责人（当前：按出差人；销售线：李鹏为·推断待确认）
财务 审核合规与真实性、打款 R 财务负责人（当前：黄梦婷·推断待确认）
特批 超标、境外、以公司名义参会的特批 A（升级） CEO（当前：邴龙志·推断待确认）；COO（当前：常元和·推断待确认）
制度维护 差旅标准、行程单简化、分公司规则 R 综合部（当前：赵雪冰·推断待确认）
填单工具 维护发票生成报销单的 AI skill C 市场部（当前：陈芷青·推断待确认）

3. 办之前请准备

  • 出差事由、目的地、日期、同行人
  • 预算估算：交通、住宿、餐费，是否超标准及理由
  • 境外或以公司名义参会：会议说明、日期、预算、展示需求
  • 发票抬头与税号（所属主体）
  • 返程后：全部交通票、住宿发票、铁路电子发票邮件

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提“出差报备”（事由、行程、预算、是否超标） 出差人 出发前 1 个工作日 飞书审批“出差报备” 报备单 🔧飞书固化
2 直属上级审批；超标/境外/以公司名义参会走特批分支 直属上级；CEO/COO 1 个工作日内 飞书审批 审批通过 🔧飞书固化
3 订票住宿，保留发票（抬头为所属主体） 出差人 行程中 邮箱、差旅平台 发票 👤人工判断
4 生成往返闭环行程单；缺段写补充说明 出差人 返程后 3 个工作日内 AI skill / 飞书 行程单 🤖自动化
5 提“费用报销”关联出差报备，上传发票 出差人 返程后 10 个工作日内 飞书审批 + 发票识别 报销单 🔧+🤖
6 审核合规与真实性；缺件一次性列清，补件即可，不整单重走 财务 2 个工作日内 飞书审批 审核结论 👤人工判断
7 打款并回传回单 财务 审核通过后 3 个工作日内 网银 回单 🔧+👤
8 参会类提交成果分享文档作为附件 出差人 返程后 5 个工作日内 飞书文档 分享文档 👤人工判断

5. 交付物与模板

  • 交付物：出差报备单、闭环行程单、发票、差旅报销单、回单；参会类附成果文档。
  • 建议模板/表单：“出差报备”——事由、目的地、起止日期、同行人、交通方式、预估交通/住宿/餐费、是否超标及理由、是否境外、是否以公司名义参会；“差旅报销”——关联报备单、行程单、发票清单、超标说明、缺票说明。

6. 异常与升级

  • 未事前报备 → 补报备并写原因；同一人月内第 2 次须直属上级书面说明
  • 缺单程票 → 附补充说明 + 付款记录，财务审核放行或要求补件，不整单退回
  • 住宿超标 → 走特批分支（事由 + 预估），特批人 1 个工作日内答复
  • 审批链节点超 1 个工作日 → 自动催办；超 2 个工作日升级综合部负责人
  • 业务合理性争议 → 由直属上级判断，财务只审合规与真实性
  • 分公司人员 → 统一由总部财务审核；本地化需求纳入制度梳理
  • 升级条件：标准内差旅由直属上级审批（A）；超标准、境外或以公司名义参会时转 CEO/COO 特批（A（升级）），特批人 1 个工作日内答复

7. 衡量指标

  • 差旅报销周期：提单到打款，目标 ≤ 10 个自然日
  • 整单退回率：目标 ≤ 5%
  • 事前报备率：目标 100%
  • 特批占比：月度统计，用于调整标准
  • 审批链平均停留时长：每节点 ≤ 1 个工作日

8. 低效诊断

  • 现象：漏单程票导致整单退回、重走审批｜依据：「董事会」2026-07
  • 现象：住宿标准一刀切，没有特批/例外分支｜依据：「董事会」2026-07、「苏州模态跃迁」2026-07
  • 现象：报销审批链过长，需每天催｜依据：「苏州模态跃迁」2026-07
  • 现象：财务审核边界（合规 vs 合理性）不清，业务与财务判断冲突｜依据：「董事会」2026-07
  • 现象：每次手工填差旅报销单，重复劳动｜依据：「【模态】市场销售」2026-09

9. 分支变体

  • 武汉总部 vs 苏州子公司：标准统一，审批链按所属主体配置
  • 国内出差 vs 境外参会：境外及以公司名义参会须事前特批，返程后提交成果文档
  • 核心城市住宿：可走特批
  • 铁路出行：电子发票通过邮件获取，直接上传报销单，不经个人聊天转存

10. 待确认问题

  • 差旅标准是否按城市分级？核心城市清单？
  • 特批人是 CEO、COO 还是两人共同审批？境外参会是否须两位创始人同意？
  • 审批链能否改为直属上级 → 财务，去掉中间节点？
  • 行程单能否由系统/AI skill 自动生成并接入飞书报销？
  • 分公司是否设本地财务？
  • 报销提交时限 10 个工作日是否可行？
FIN-08企业滴滴充值与通勤打车报销待优化36

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨3 × 险2

  • 适用场景：员工通勤、加班返程、因公出行打车，以及企业滴滴账户月度充值、额度调整、余额不足时适用。
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——财务充值（当前：黄梦婷·推断待确认）、行政用车仪表盘（当前：侯明月·推断待确认）、CEO 标准制定（当前：邴龙志·推断待确认）、人事入离调同步（当前：黄莹·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 入职开通并宣讲 → ② 员工按入口用车 → ③ 行政月度汇总提交充值 → ④ 财务充值 → ⑤ 余额预警 → ⑥ 月度仪表盘与抽查 → ⑦ 余额不足时垫付报销 → ⑧ 入离调同步账户
  • 交付结果：每月额度充足可用的企业滴滴账户、月度用车仪表盘与核查记录。
  • 状态依据：《企业滴滴用车管理 SOP》于 2026-08 制定、2026-09 起执行，含通勤额度、四个入口、加班返程与核查机制；此前 2026-01～04 曾断供约一个月、员工不知对接谁；当前执行时间短，余额预警与用车仪表盘依赖的账单 API 尚未接入，用量数据整理仍靠手工，暂不满足“稳定执行”。

1. 场景判定

  • 触发条件：员工通勤时段打车；21:00 后加班返程；因公外出；账户余额不足或员工跨主体调动。
  • 典型说法：「已经一个月没有企业滴滴了」「每月充值经常充不上」「企业滴滴使用 SOP 9 月开始执行」「余额不足了，账单截图发我，转账报销」
  • 判断问题：属于哪个用车入口（因公出行 → 加班返程 → 员工通勤 → 自费）？是否在额度和时段内？
  • 不归本流程管：异地差旅交通 → 请走 FIN-07；其他垫付费用 → 请走 FIN-06。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行政 维护 SOP、开通/关闭账号、月度汇总充值、余额查看、抽查 R 行政负责人（当前：胡则瑾·推断待确认）
用车数据 月度用车仪表盘、超额与异常标记 R 行政（当前：侯明月·推断待确认）
财务 按申请充值、处理垫付报销 R 财务（当前：黄梦婷·推断待确认）
标准制定 通勤额度、董事会用车、加班池规则 A CEO（当前：邴龙志·推断待确认）
人事 入离调、跨主体调动同步行政 C 人事负责人（当前：黄莹·推断待确认）
员工 按入口用车、余额不足时垫付并报销 R 全体员工（当前：按用车人）
兜底 规则争议、断供协调 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 新员工：入职日期（当月 15 日后入职按半额）、所属主体
  • 用车人：入口选择依据（因公事由、加班时间）
  • 行政月度充值：上月各主体用量、下月预估、当前余额
  • 余额不足垫付：行程账单截图与发票

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入职开通账号并宣讲用车 SOP；外部人员原则上不开通 行政 入职当天 企业滴滴后台 账号 🔧+👤
2 按入口用车，因公出行填写必填信息 员工 用车时 企业滴滴 用车记录 👤人工判断
3 汇总上月用量，按主体提交充值申请 行政 每月前 3 个工作日 飞书审批“付款申请” 充值申请 🔧飞书固化
4 审批后充值 财务 审批后 1 个工作日内 企业滴滴后台/网银 充值完成 🔧+👤
5 每周查看余额，低于下月预估用量的 20% 时提醒财务加急充值（账单 API 接入后改为机器人自动提醒） 行政 每周一 企业滴滴后台 预警 👤人工判断
6 手工导出月度用量，更新用车仪表盘，抽查超额与因公出行（账单 API 接入后改为自动生成仪表盘） 行政 每月 10 日前 用车仪表盘（多维表格） 核查记录 🔧+👤
7 余额不足/未开通期间个人垫付，凭截图与发票报销 员工；财务 用车后 30 天内 飞书“费用报销” 报销单 🔧飞书固化
8 入离调、跨主体调动同步账户归属 人事 → 行政 变动当天 飞书人事 + 企业滴滴后台 账户更新 🔧飞书固化

5. 交付物与模板

  • 交付物：《企业滴滴用车管理 SOP》、月度充值申请与回单、月度用车仪表盘、核查记录。
  • 建议模板/表单：“月度充值申请”——主体、上月用量、下月预估、当前余额、充值金额；“账户台账”——员工、所属主体、开通日期、额度类型（通勤/加班池/董事会）、状态。

6. 异常与升级

  • 账户断供（余额为零）→ 行政当天提加急充值，财务当天处理 → 超 1 个工作日升级综合部负责人
  • 员工不知对接谁 → 统一找行政；SOP 与对接岗位放全员群置顶
  • 超额或非通勤时段用车 → 行政核实，非因公部分转自费
  • 跨主体员工 → 人事通知后行政 3 个工作日内转到对应主体账户
  • 套餐人数上限不足 → 行政评估升级版本，报 CEO 决定
  • 入口选择争议 → 行政按 SOP 判断顺序答复，仍有争议报综合部负责人

7. 衡量指标

  • 断供天数：每月目标 0
  • 充值准时率：每月前 5 个工作日内完成充值，目标 100%
  • 异常用车占比：抽查中不符合入口规则的用车占比，逐月下降
  • 垫付报销笔数：每月目标较当前下降 80%
  • 仪表盘出具及时率：每月 10 日前，目标 100%

8. 低效诊断

  • 现象：账户余额不足导致断供，按月充值经常不到位｜依据：「内务大主管」2026-03、「内务大主管」2026-04
  • 现象：出问题时不知道对接哪个岗位｜依据：「内务大主管」2026-04
  • 现象：规则出台前历史用车数据靠手工整理，通知发布等待确认｜依据：「【模态】综合部」2026-04、「【模态】综合部」2026-09
  • 现象：某主体企业滴滴余额不足，员工截图单发后转账报销｜依据：「公司建设大改造」2026-01

9. 分支变体

  • 普通通勤：每人每月固定额度，限通勤时段；当月 15 日后入职按半额
  • 加班返程：21:00 后，走专项池，不计通勤额度
  • 因公出行：单独入口，单独记录并抽查
  • 董事会用车：不限额
  • 自费入口：个人支付
  • 主体差异：模态、鼎慧、跃竞各自账户，跨主体员工归入劳动关系所属主体

10. 待确认问题

  • 余额预警阈值按下月预估 20% 是否合适？
  • 充值统一由行政提申请、财务执行，是否已形成固定日期？
  • 是否接入企业滴滴账单 API，实现余额自动预警与仪表盘自动生成？由哪个岗位开发？接入并稳定执行后，状态可复评为“已有”
  • 跨主体员工账户调整由人事还是行政发起？
  • 是否升级企业版以解除人数上限？
FIN-09活动/团建/大会费用预算与统计归集待优化81

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：行政或业务小组组织团建、主题活动、生态大会等，需要事前报预算、事中按口径采购或垫付、事后报销，并按活动汇总实际花费
  • 负责人：主责——活动负责人（立项时指定；团建默认行政专员，当前：侯明月·推断待确认）；协同——大会费用汇总人（综合部负责人，当前：赵雪冰·推断待确认）、各组负责人、报销人、财务专员（当前：刘梦可·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项报预算 → ② 预算审批 → ③ 发布费用口径 → ④ 按口径采购/垫付 → ⑤ 报销时关联活动名 → ⑥ 各组登记明细 → ⑦ 预算对照汇总 → ⑧ 财务核对归档
  • 交付结果：活动费用汇总表（预算 vs 实际，按科目/小组拆分），关联的报销单与发票齐全并归档
  • 状态依据：已有财务制度宣讲和飞书报销审批，但 2026-04 团建期间采购范围（零食是否算采购）、审批链路被反复追问约 5 次；2026-05～06 物料耗材的费用科目、发票类型靠群里问；2026-06 大会费用会后才统计，没有模板和预算对照，还需二次催办

1. 场景判定

  • 触发条件：计划组织团建、内部活动、对外大会；或活动中个人自购物料、耗材、礼品需要报销并计入活动成本
  • 典型说法：「采购零食算采购吗」「大家材料走报销」「料子报销算啥费用」「请各负责人统计本组筹办大会的各类费用及明细」
  • 判断问题：这笔支出是否挂在某个具体活动下、需要按活动统计总成本？是 → 走本流程；只是个人日常办公支出 → 不走
  • 不归本流程管：活动场地、流程、人员组织 → 请走 ADM-20 / ADM-21 / GEN-08；单笔达到采购阈值（[阈值待财务确认]）的采购 → 请走 FIN-01；定制物料与对外礼品登记 → 请走 ADM-19；普通个人报销提交与审核 → 请走 FIN-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动负责人 立项报预算、发布费用口径、活动后汇总 R 活动负责人（团建默认行政专员，当前：侯明月·推断待确认）
大会费用汇总人 多组协办时统一收集明细、催收、出汇总 R 综合部负责人（当前：赵雪冰·推断待确认）
各组负责人 统计本组费用明细并按时提交 R 各组负责人（当前：按活动指定）
报销人 按口径取票、提交报销并填写活动名称 R 参与员工
预算审批人 审批活动预算 A 直属上级/部门负责人（按飞书审批流配置）
财务专员 解释采购阈值、费用科目、发票口径；审核报销 R 财务专员（当前：刘梦可·推断待确认）
生态活动科目答疑 生态类活动费用科目口径 C 生态组负责人（当前：陈梦琪·推断待确认）
兜底 口径争议裁决、超支审批 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 活动名称、日期、参与人数、承担主体
  • 预算明细：场地、餐饮、物料耗材、礼品、交通、其他
  • 是否有单笔达到采购阈值（[阈值待财务确认]）的采购（需另走采购流程）
  • 开票信息：承担主体全称、税号
  • 上一次同类活动的实际花费（用于对照）
  • 活动费用统计表链接（见第 5 节模板）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交活动预算申请（活动名、主体、预算科目、金额、负责人） 活动负责人 活动前 5 个工作日 飞书审批 预算审批单 🔧飞书固化
2 审批预算；较上次同类活动明显增加的需写明理由 预算审批人 提交后 2 个工作日内 飞书审批 审批结果 👤人工判断
3 在活动群发布费用口径：采购阈值、可报科目、发票抬头、报销须填活动名 活动负责人 审批通过当天 飞书群公告/模板 口径公告 🔧飞书固化
4 单笔达到采购阈值（[阈值待财务确认]）的转采购流程；其余个人垫付并索取电子发票 报销人 支出发生时 飞书审批 发票 👤人工判断
5 提交报销，费用类型选"活动费用"，填写活动名称/编号 报销人 活动结束后 5 个工作日内 飞书报销审批 报销单 🔧飞书固化
6 各组在统计表登记本组明细 各组负责人 活动结束后 2 个工作日内 多维表格 本组明细 🔧飞书固化
7 汇总预算 vs 实际，标出超支项与未报销项 活动负责人/大会费用汇总人 活动结束后 5 个工作日内 多维表格 活动费用汇总表 🔧+🤖
8 按活动名核对报销单与汇总表，归档 财务专员 汇总后 3 个工作日内 飞书报销/多维表格 归档记录 🤖自动化

5. 交付物与模板

  • 交付物：活动预算审批单；活动费用汇总表；关联报销单与发票
  • 建议模板/表单：活动费用多维表格——活动编号、活动名称、承担主体、组别、费用科目（场地/餐饮/物料耗材/礼品/交通/其他）、金额、支付方式（个人垫付/对公）、发票类型、报销单号、报销状态、对应预算科目、备注
  • 建议补一页《活动费用口径 FAQ》：采购阈值的计算口径、零食/物料/自制礼品归哪个科目、专票还是普票

6. 异常与升级

  • 实际超出预算 10% 以上 → 活动负责人说明原因并补审批 → 部门负责人（发现后 2 个工作日内）
  • 某组逾期未报明细 → 汇总人提醒一次，次日仍未报 → 综合部负责人
  • 科目或发票类型拿不准 → 直接问财务专员，不在群里猜；财务 1 个工作日内答复并补进 FAQ
  • 审批人与预期不符（「我没审批」）→ 核对飞书审批流配置 → 飞书审批管理员（1 个工作日内）
  • 历史活动遗留未报销费用 → 单独提交并注明原活动名，不与本次合并 → 财务专员
  • 升级条件：费用口径争议财务专员无法裁定、或超支超过 10% 需补审批且部门负责人无法决定时，由综合部负责人拍板（A（升级））

7. 衡量指标

  • 预算覆盖率：有事前预算审批的活动数 / 活动总数，目标 100%
  • 汇总及时率：活动结束 5 个工作日内完成费用汇总的活动占比，目标 ≥ 90%
  • 预算偏差：|实际 − 预算| / 预算，目标 ≤ 10%
  • 口径追问数：每次活动群内关于科目/发票/采购范围的追问次数，目标 ≤ 1

8. 低效诊断

  • 现象：财务制度宣讲后，采购范围（零食是否算采购）、审批链路仍需在群里追问，口径没有可查的 FAQ｜依据：「鼎慧产研决策部」2026-04
  • 现象：活动经费规模较上次明显增长，但事前没有预算对照，只在事后讨论｜依据：「鼎慧产研决策部」2026-04
  • 现象：物料耗材的费用科目、发票类型靠群里问，上次活动未报销的费用与本次合并处理｜依据：「3D打印小组」2026-05、「3D打印小组」2026-06
  • 现象：大会费用会后才统计，没有模板和预算表，需二次催办｜依据：「跃迁生态大会筹备群」2026-06

9. 分支变体

  • 团建/内部活动：行政专员主责，预算按直属上级审批流
  • 多组协办的大会：综合部负责人作为汇总人，各组负责人分别登记；会前建预算表，会后对照
  • 小组自发活动（兴趣小组物料等）：小组负责人统计，金额小可简化为活动后一次性汇总
  • 研发采购等非活动采购：不在本流程

10. 待确认问题

  • 活动预算由谁审批？是否按金额分级（如 X 元以下直属上级，以上部门负责人/CEO）？
  • 采购阈值（[阈值待财务确认]）按单笔还是按单次活动合计？零食、物料是否计入？
  • 飞书报销审批能否新增"活动名称/活动编号"字段？
  • 活动后 5 个工作日内完成汇总是否可行？
  • 物料耗材、自制礼品统一归入哪个费用科目？是否要求专票？
  • 超支多少比例需要补审批？
FIN-10员工 AI 工具补贴核发与超额报销待优化256

状态：待优化｜证据：有证据（卡片 28 张 / 会话 27 个）｜优先级：频4 × 耗4 × 跨4 × 险4

  • 适用场景：每月按岗位核发员工 AI 工具补贴；员工因工作使用 AI 工具超出补贴需额外申请或报销；外部研发方、参赛者需要订阅支持；补贴资格复核与使用调研
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（补贴表核算，当前：黄莹·推断待确认）、创始人兼 CTO（口径解释与超额审批，当前：丁震宇·推断待确认）、CEO（标准与预算，当前：邴龙志·推断待确认）、产品负责人（LeapAll 充值核验，当前：杨萌·推断待确认）、行政专员（AI 采购登记，当前：侯明月·推断待确认）；兜底——综合部负责人
  • 核心流程：① 冻结当月名单与分档 → ② 差异比对 → ③ 管理层审核 → ④ 计税并提付款 → ⑤ 每月 15 日打款 → ⑥ 超额申请审批 → ⑦ 发票审核报销 → ⑧ 充值/使用核验与月度统计
  • 交付结果：当月 AI 补贴发放表与付款凭证（含个税代扣记录）、已审批的超额申请与合规票据报销单、充值/使用核验名单、按主体汇总的月度 AI 费用统计、一页式补贴制度
  • 状态依据：已有补贴表、每月 15 日发放、飞书费用报销卡片，但 2026-01 至 2026-10 补贴形式多次变更（报销 → 固定直发 → 与工资分开打款 → 联动自研产品充值），标准未成文；群内关于额度、凭证、发票、主体的追问上百次，出现名单漏发、连续多月多发和"凑发票"倾向

1. 场景判定

  • 触发条件：每月 15 日前补贴核发；员工询问标准或是否到账；员工 AI 工具费用超出补贴申请报销；外部研发方/参赛者需订阅支持；补贴资格复核或使用调研
  • 典型说法：「AI 补贴会根据订阅价格增长吗」「补贴是直接发现金吗」「超出部分怎么报」「订阅付款凭据拿什么发票冲」「我们组的 AI 补贴没发」「家宽 VPS 能进 AI 补贴吗」
  • 判断问题：这笔 AI 费用是员工个人使用（补贴/超额报销）吗？是 → 本流程；公司统一采购账号、团队订阅、API 对公充值 → 不是本流程
  • 不归本流程管：补贴标准与分档名单的制定调整 → 请走 HR-17；公司统一采购订阅/账号开通 → 请走 FIN-02；上游模型/API 对公充值 → 请走 FIN-03；境外无票支出 → 请走 FIN-04；自研产品内部推广与使用考核 → 请走 GEN-10；补贴并入工资的计税答疑 → 请走 HR-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
财务执行 计税、打款、超额报销审核、票据合规、主体归属、月度统计 R 财务负责人（当前：黄梦婷·推断待确认）
标准与预算决策 定分档标准、批准超预算与赶工月额外补贴 A（升级） CEO（当前：邴龙志·推断待确认）
口径解释与超额审批 解释规则；审批超额、外部研发方、参赛者订阅 A 创始人兼 CTO（当前：丁震宇·推断待确认）
补贴表核算 每月更新名单与分档、发起付款申请 R 人事负责人（当前：黄莹·推断待确认）
充值/使用核验 拉 LeapAll 后台未充值名单、收集使用反馈 R 产品负责人（当前：杨萌·推断待确认）
AI 采购登记 维护 AI 采购表、处理历史待报条目 C 行政专员（当前：侯明月·推断待确认）
跃竞主体核对 本主体补贴名单反馈与核对 C 跃竞负责人（当前：徐莉·推断待确认）
员工 按规则使用、超额申请、交票 R 全体享受补贴员工

3. 办之前请准备

  • 员工超额申请：工具名称、订阅/充值类型、月费、超出金额、用途、账单或使用截图、公司抬头发票（境外为 invoice）、使用感想或产出文档链接
  • 人事：当月入离调名单、上月发放表、赶工/加班名单、实习生与驻场人员确认结果、所属主体
  • 财务：分主体付款账户余额、福利计税口径、上月多发/漏发调整项
  • 一页式补贴制度（发布后作为所有答疑的唯一依据）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 冻结当月名单与分档（入离调、实习、驻场、跃竞/子公司主体） 人事负责人 每月 10 日前 飞书表格 当月补贴表 🔧飞书固化
2 与上月自动比对，标出新增、删除、档位变化 人事负责人 每月 10 日前 表格公式/脚本 差异清单 🤖自动化
3 管理层审核补贴表，无问题在表内留言确认 CEO/CTO 收到后 1 个工作日内 飞书表格评论 审核记录 👤人工判断
4 分主体发起付款申请；财务按福利口径计算代扣个税 人事负责人/财务负责人 每月 12 日前 飞书付款审批 付款单、计税表 🔧飞书固化
5 打款（与工资分开），群内通知已发放 财务负责人 每月 15 日 网银/飞书群 付款凭证、发放通知 🔧飞书固化
6 员工提交超额申请：工具、金额、用途、产出说明 员工 费用发生当月 飞书审批"AI 超额申请" 申请单 🔧飞书固化
7 审批超额合理性与可报额度；超预算转 CEO CTO 2 个工作日内 飞书审批 批复额度 👤人工判断
8 提交报销：类型"AI 工具费用"，附票据，主体与发票抬头一致 员工 批复后当月 25 日前 飞书费用报销 报销单 🔧飞书固化
9 审核票据与 AI 工具相关、按发票号查重后付款 财务负责人 收单后 3 个工作日内 飞书报销 + 发票识别 付款记录 🔧+🤖
10 核验自研产品充值/使用，推送未完成名单；月末仍未完成按制度处理 产品负责人 发放后次日 + 月末 LeapAll 后台/机器人 核验名单 🤖自动化
11 按主体汇总当月补贴与超额报销总额，报 CEO 财务负责人 次月 5 日前 多维表格 月度统计 🤖自动化

5. 交付物与模板

  • 交付物：月度补贴发放表（含审核记录）、付款凭证、个税代扣记录、超额申请单、报销单、月度统计表、一页式《AI 工具补贴制度》
  • 补贴表字段：月份、姓名、主体、岗位档、人员类型（正式/实习/驻场/外部）、基础额度、额外额度（赶工/加班）、扣减项、应发、审核人、付款单号、备注
  • 超额申请字段：申请人、主体、工具名称、类型（官方订阅/API/中转站/海外）、月费、超出金额、用途、使用截图、产出文档链接、票据类型、审批人
  • 制度一页纸章节：适用人员与分档、发放日与形式、计税口径、可报与不可报范围（VPS、共享账号、转卖额度等）、凭证要求、超额审批、违规处理、外部研发方与参赛者

6. 异常与升级

  • 名单漏发/多发 → 人事 1 个工作日内核实；漏发单独补发，多发与员工确认次月扣回 → 财务负责人（发现当日）
  • 员工反馈未到账 → 人事查表，1 个工作日内答复；确属漏发按上条处理
  • 平台不开票（海外、中转站）→ 用 invoice 或支付凭证按 FIN-04 处理；不得用无关发票替代 → 财务负责人
  • 用与 AI 工具无关的发票凑数 → 财务退回并告知；同一人再次发生 → CTO
  • 买额度转卖、共享账号被封等违规 → 停发下月补贴并追回 → CEO（发现后 1 个工作日内）
  • 跃竞/子公司人员无法由本主体直接付款 → 由所属主体账户发放，不经他人代转 → 财务负责人，口径见 FIN-32
  • 外部研发方额度不足 → 优先给公共账号额度；订阅费经 CTO 批准后凭票报销
  • 规则变化（形式、档位、充值要求）→ 生效前 5 个工作日发全员通知并更新制度文档 → 人事负责人
  • 升级条件：超额申请超出预算、赶工月额外补贴、分档标准调整或违规停发补贴时，由 CEO 拍板（A（升级））；其余超额审批与口径解释由 CTO 决定

7. 衡量指标

  • 准时发放率：在 15 日当天完成发放的月份占比，目标 100%
  • 发放差错：每月漏发 + 多发人次，目标 0
  • 超额报销周期：提交到付款的自然日，目标 ≤ 7 天
  • 票据退回率：因票据不符退回的 AI 报销单占比，目标 ≤ 5%
  • 口径追问数：群内关于补贴规则的提问次数/月，制度发布后目标 ≤ 3
  • 充值/使用核验完成率：目标 ≥ 95%

8. 低效诊断

  • 现象：补贴形式与规则多次口头变更，没有成文制度，员工在群里反复追问，过渡期的报销无人认领｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03、「【模态】综合部」2026-06
  • 现象：超出补贴部分靠"凑发票"报销，财务月度逐人追缴欠票，存在用无关发票冲抵的合规风险｜依据：「鼎慧产研决策部」2026-08、「Leap产研测」2026-08
  • 现象：补贴表人工维护，出现组内多人漏发、连续多月多发未被审核发现｜依据：「内务大主管」2026-03、「薪酬对接群」2026-10
  • 现象：研发/非研发、测试是否属研发、驻场顾问是否享受等分档口径不清，补贴表格是否继续填写没有通知｜依据：「模态起飞通知群-武汉」2026-02、「薪酬对接群」2026-08
  • 现象：AI 采购登记表新旧版本并行，员工填进旧表后条目找不到｜依据：「模态集团（全员群）」2026-02
  • 现象：自研产品充值核验靠每月手工拉后台名单、逐人督促，后台数据与实际充值不一致；通知中曾出现明文兑换码｜依据：「【模态】业务负责人」2026-06、「【模态】综合部」2026-06
  • 现象：新员工、外部研发方不知道补贴规则和申请渠道，在群里问｜依据：「跃迁AI总动员」2026-08、「手机端-录音卡」2026-09
  • 现象：没有统一用量看板，API 用量统计不准，凭证需临时找截图｜依据：「AI工具跃迁交流群」2026-03、「鼎慧产研决策部」2026-06

9. 分支变体

  • 人员档位：研发 / 非研发 / 实习生 / 驻场顾问 / 负责人与解决方案工程师，名单由人事确认
  • 发放形式：现金直发（与工资分开、按福利计个税）；联动自研产品充值；过渡月兑换码（须用领取表单，不在群内发明文）
  • 主体：武汉模态、湖北鼎慧、苏州模态、跃竞、曜途各自账户发放与报销；非 AI 补贴的其他费用按 FIN-32 走对应主体
  • 赶工月/加班额外补贴：CTO 提出、CEO 批准，按名单统一核算
  • 外部研发方：优先公共账号额度，订阅费凭票报销
  • 参赛者订阅：在赛事预算内报销；奖金发放见 FIN-14
  • 员工自购 API/中转站额度：先票后报；确需预支走 FIN-05
  • 与 HR-17 的分工：补贴标准、分档与名单以 HR-17（AI工具补贴发放与调整）为准，本条作为其财务执行分支，负责计税、打款、超额报销与月度统计

10. 待确认问题

  • 当前各档补贴标准与适用人员以哪份文件为准？是否已有成文制度？
  • 主责放在财务还是人事？补贴表核算与付款申请的分工是否如本文所写？
  • 超额报销审批人是 CTO 还是部门负责人？超额上限多少、超过多少转 CEO？
  • 福利计税口径是否所有主体一致？
  • "每月最低充值自研产品、未完成取消下月补贴"是否仍有效？
  • 海外订阅无发票时，财务接受哪些凭证？
  • 外部研发方、参赛者的订阅支持是否纳入本制度？
  • 本条是否按审阅建议并入 HR-17 作为财务分支？请管理层裁定
FIN-11飞书报销审批表单配置与应用问题处理待优化81

状态：待优化｜证据：有证据（卡片 4 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：财务新建或调整飞书费用报销、预付后补票、关联差旅报备等审批表单；员工提交时遇到退回、发票被占用、控件值为空、明细超行数、需撤回修改等应用问题
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——飞书审批管理员（当前：黄莹·推断待确认）、发票报销应用管理员（当前：丁震宇·推断待确认）、综合部负责人（报销自动化改造，当前：赵雪冰·推断待确认）、外部厂商客服；兜底——综合部负责人
  • 核心流程：① 员工按 FAQ 自查 → ② 提交问题单 → ③ 财务排查 → ④ 转管理员/厂商 → ⑤ 表单变更测试 → ⑥ 发布 → ⑦ 通知 → ⑧ 沉淀 FAQ
  • 交付结果：可用的报销类表单配置及变更记录、员工问题处理记录、《报销系统 FAQ》、应用管理员与插件余量台账
  • 状态依据：飞书费用报销审批与发票报销应用已在用，但 2026-04 至 2026-10 反复出现退回后发票被占用、控件值为空、15 行上限、提交错无法撤回、插件使用范围无权限等问题，需在外部服务群逐个问顾问，应用管理员是谁一度无人知道

1. 场景判定

  • 触发条件：要新增或调整报销类表单（关联差旅、金额条件分支、预付补票）；员工提交失败、退回后改不了、发票被占用、提示控件值为空、明细超行数、提交错要撤回；插件余量、续费、开票
  • 典型说法：「提费用报销时提示控件值为空是什么原因」「被退回了，里面的发票改不了」「提交错了删不了」「预付后来票了能补到原表单吗」「最多 15 行，只能拆成几个流程」
  • 判断问题：问题出在"系统和表单怎么用、怎么配"，而不是"这笔钱能不能报"？是 → 本流程
  • 不归本流程管：费用能否报销、科目口径 → 请走 FIN-06；差旅规则 → 请走 FIN-07；预支与补票的业务审批 → 请走 FIN-05；组织架构与审批人维护 → 请走 HR-02；飞书席位/插件的采购付款 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
表单负责人 设计/调整报销类表单、排查员工问题、维护 FAQ R/A 财务负责人（当前：黄梦婷·推断待确认）
飞书审批管理员 表单发布、可见范围与审批人配置 R 飞书审批管理员（当前：黄莹·推断待确认）
发票报销应用管理员 插件使用范围、余量/验证次数查询、续费 R 应用管理员（当前：丁震宇·推断待确认，建议移交财务）
报销自动化改造 发票自动处理 Agent、撤回规则改造 C 综合部负责人（当前：赵雪冰·推断待确认）
厂商客服 插件技术问题、远程协助、赠送验证次数 C 外部厂商
提交人 按 FAQ 自查、提供截图与单号 I 全体员工

3. 办之前请准备

  • 员工报问题：单据编号、报错截图、操作步骤、涉及发票号、单据当前状态（审批中/已退回/已通过）
  • 财务改表单：变更需求说明、受影响审批流、金额条件分支、是否关联差旅/预支单、测试账号
  • 应用管理员账号与后台入口、插件当前余量

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按 FAQ 自查（退回单先点确认/撤回释放发票；超 15 行拆单；控件为空先查必填项） 提交人 发现问题当场 FAQ 文档 自助解决 🔧飞书固化
2 未解决则提交问题单（截图 + 单号） 提交人 当天 飞书表单/服务台 问题单 🔧飞书固化
3 排查表单配置、插件使用范围、余量 财务负责人 1 个工作日内 飞书审批后台 排查结论 👤人工判断
4 属插件或权限问题的转应用管理员或厂商客服 财务负责人 排查后当天 外部服务群/服务台 厂商工单 👤人工判断
5 表单变更先在测试副本配置并自测（金额分支、关联单据、补票节点） 财务负责人 需求确认后 3 个工作日内 飞书审批 测试记录 👤人工判断
6 发布并调整可见范围 飞书审批管理员 自测通过后 1 个工作日内 飞书审批 发布记录 🔧飞书固化
7 发布变更通知（变更点、生效日、操作说明） 财务负责人 发布当天 飞书群公告 通知 🔧飞书固化
8 问题与答案沉淀进 FAQ；每周检查一次插件余量 财务负责人 解决后 1 个工作日内；每周一 飞书文档/机器人 FAQ、余量记录 🤖自动化

5. 交付物与模板

  • 交付物：表单配置清单与变更记录、报销系统 FAQ、应用管理员与插件余量台账、问题处理记录
  • 表单配置清单字段：表单名称、用途、适用主体、可见范围、关联单据、条件分支、审批节点、办理人上传发票节点、负责人、最近变更日期
  • 问题记录字段：日期、提交人部门、单号、问题类型（退回/发票占用/控件为空/超行数/撤回/权限/余量）、原因、处理方式、处理时长、是否已入 FAQ
  • FAQ 首批条目：退回后如何释放发票、"再次提交"复制旧单、15 行上限与拆单、审批流转前可撤回、"发票报销后台"只收票不报销、预付补票如何补到原单

6. 异常与升级

  • 插件余量/验证次数用尽、报销被阻断 → 应用管理员当天续费或申请临时次数 → CTO（当天）
  • 应用管理员不明或已离任 → 飞书主管理员查明并转交财务负责人 → 综合部负责人（3 个工作日内完成）
  • 厂商 2 个工作日未解决 → 申请远程协助 → 财务负责人升级厂商顾问
  • 错单无法撤回 → 审批人退回、提交人重提，原单评论注明作废 → 财务负责人
  • 表单改动影响在途单据 → 暂停发布，在途单走旧版 → 综合部负责人

7. 衡量指标

  • 问题平均解决时长：问题单提交到解决的工作日，目标 ≤ 2 个工作日
  • FAQ 自助解决率：未提交问题单即解决的比例（抽样），目标 ≥ 60%
  • 同类问题复发：同一问题类型每月出现次数，FAQ 发布后目标下降 50%
  • 系统原因退回重提单据数/月：目标逐月下降
  • 插件余量断供次数：目标 0

8. 低效诊断

  • 现象：退回单据无法修改、发票被占用，同一问题跨多日在外部服务群反复询问｜依据：「发票报销服务台」2026-05、「模态财务飞书对接群」2026-05
  • 现象：应用管理员是谁无人掌握，看不到发票余量｜依据：「发票报销服务台」2026-09
  • 现象：关联差旅、预付补票、插件使用范围、控件为空等配置边角问题依赖顾问逐个解答｜依据：「模态跃迁 - HR/行政飞书咨询群」2026-04、「模态跃迁 - HR/行政飞书咨询群」2026-09
  • 现象：明细超 15 行只能拆成多个流程｜依据：「发票报销服务台」2026-09
  • 现象：提交后不能撤回、发票上传步骤繁琐，员工期待邮件转发自动入单｜依据：「跃迁AI总动员」2026-10
  • 现象：官方产品与第三方插件的客服渠道不分；购买权限不在财务手里｜依据：「模态财务飞书对接群」2026-04、「模态-飞书」2026-06

9. 分支变体

  • 表单配置（财务主导）vs 员工侧问题（自助 → 财务 → 厂商）
  • 官方飞书产品问题找飞书顾问；第三方发票报销插件问题找插件厂商
  • 飞书席位/插件购买后开票：由管理员在费用中心在线申请发票和合同
  • 改造中：发票邮件转发 + OCR 自动入单、流转前撤回规则

10. 待确认问题

  • 发票报销应用管理员现在是谁？是否移交给财务？
  • 报销类表单的唯一配置人是否为财务负责人，审批管理员只负责发布？
  • 发票自动处理 Agent 的上线计划与负责人？
  • 是否需要"审批流转前可撤回"之外的撤回规则？
  • 插件余量低于多少提醒？
  • 预付补票采用原单补充还是独立"补充票据"审批关联原单？
FIN-12进项发票索取、缺票催收与归档待优化192

状态：待优化｜证据：有证据（卡片 9 张 / 会话 9 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：公司或员工产生采购、垫付、云服务/SaaS、订阅等支出后，向供应商索取合规发票，财务收集、去重、催收缺票并归档，集中处理抵扣票
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT/采购（云服务与海外订阅开票，当前：杨明学·推断待确认）、行政专员（当前：侯明月·推断待确认）、人事负责人（SaaS 席位开票，当前：黄莹·推断待确认）、各支出经办人；兜底——综合部负责人
  • 核心流程：① 支出时按开票信息卡索票 → ② 上传并登记台账 → ③ 识别去重 → ④ 重命名归档 → ⑤ 月度缺票清单 → ⑥ 催收补票 → ⑦ 无票/异常人工判定 → ⑧ 抵扣票汇总
  • 交付结果：按主体、月份统一命名归档的进项发票库；发票台账（含是否已报销、是否抵扣）；月度缺票清单与催收结果
  • 状态依据：已有飞书云盘票据收集文件夹和发票报销插件，但 2026-02 至 2026-08 多次出现"发票发谁""专票还是普票""这张报过没有"的追问，历史缺票长期挂账，2026-07 管理层提出缺票治理机制但无人认领

1. 场景判定

  • 触发条件：任何对公或个人垫付支出发生后需要发票；追问供应商开票进度；月末/季末抵扣票汇总；财务发现缺票；批量发票整理归档
  • 典型说法：「发票发谁来着」「大家记得开增值税专票，不是普票」「麻烦开一下发票，大概啥时候能开出来」「这张我忘记有没有报过了」「每个月开票压力很大」「现在太缺票了」
  • 判断问题：要解决的是"怎么拿到合规发票并交给财务"吗？是 → 本流程；"这笔钱怎么报/怎么付" → 去报销或付款流程
  • 不归本流程管：报销提交与审核 → 请走 FIN-06；对公付款 → 请走 FIN-01；境外无票支出 → 请走 FIN-04；预支后补票 → 请走 FIN-05；我方对客户开具销项发票 → 请走 FIN-18、FIN-19；月度税务申报 → 请走 FIN-35；报销系统操作问题 → 请走 FIN-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发票口径与归档 发布开票信息卡与口径、识别去重、缺票清单、归档、抵扣汇总 R/A 财务负责人（当前：黄梦婷·推断待确认）
缺票机制决策 批准缺票治理机制与奖惩 A（升级） CEO（当前：邴龙志·推断待确认）
云服务/海外订阅开票 在供应商后台申请开票、转交财务 R IT/采购（当前：杨明学·推断待确认）
大额垫付人 垫付后索票、上传、批量转交抵扣票 R 创始人兼 CTO（当前：丁震宇·推断待确认）及其他经办人
行政采购索票 行政采购索票、发票整理 R 行政专员（当前：侯明月·推断待确认）
SaaS 席位开票 在费用中心申请发票 R 人事负责人（当前：黄莹·推断待确认）
历史票据回溯 早期票据是否已报销的核对 C 前财务经办（当前：祁航·推断待确认）
合规意见 替票、二手无票设备的合规判断 C 法务负责人（当前：李瑶·推断待确认）
经办人 支出后索票、上传登记、补票或说明原因 R 各支出经办人

3. 办之前请准备

  • 开票信息卡（按主体）：公司全称、税号、地址电话、开户行及账号、发票接收邮箱——由财务固化发布
  • 票种要求：默认增值税专用发票；只能开普票的需注明原因
  • 支出凭证：订单号、付款截图、合同（如有）
  • 统一的发票接收渠道（云盘目录或发票邮箱）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按开票信息卡向供应商申请开票，要求发至公司发票邮箱 经办人 付款后 3 个工作日内 供应商后台/服务台 开票申请 🔧+👤
2 超 7 个自然日未开出 → 催供应商一次 经办人 第 7 个自然日 邮件/客服 催开记录 👤人工判断
3 发票上传收集目录并登记台账（或转发发票邮箱自动入台账） 经办人 收票后 2 个工作日内 飞书云盘 + 多维表格 台账记录 🔧+🤖
4 自动识别发票字段，按发票号去重，标记抬头/票种异常 财务负责人 每周一次 多维表格发票识别/Agent 校验结果 🤖自动化
5 按命名规范重命名并归档 财务负责人 每月 5 日前处理上月 云盘/skill 归档目录 🤖自动化
6 对照付款与报销记录生成缺票清单，分人推送 财务负责人 每月 5 日前 多维表格 + 机器人 缺票清单 🔧+🤖
7 补票，或说明无法取得的原因 经办人 收到清单后 10 个工作日内 台账 补票/说明 👤人工判断
8 无票、个人抬头、二手无票设备等情形判定处理方式 财务负责人（必要时法务） 说明提交后 3 个工作日内 — 判定记录 👤人工判断
9 汇总抵扣票，标记"已抵扣/仅收票不报销"，月末交账 财务负责人 每月末 台账 抵扣清单 🔧飞书固化

5. 交付物与模板

  • 交付物：分主体开票信息卡、进项发票台账、归档目录、月度缺票清单、《可报销票据与开票方法清单》
  • 台账字段：发票号、开票日期、销售方、购买方抬头、所属主体、票种（专票/普票/海外 invoice）、金额、税额、内容、关联单号（报销单/付款单）、经办人、是否已报销、是否抵扣、文件链接、异常标记
  • 命名规范（建议）：主体简称_YYYYMM_销售方_内容_金额元.pdf
  • 缺票清单字段：经办人、支出日期、事由、付款单号、缺票原因、预计补票日、状态

6. 异常与升级

  • 供应商超 15 个自然日仍未开票 → 经办人报财务负责人，评估是否暂停后续付款 → 财务负责人
  • 抬头错误或开成个人抬头 → 申请红冲重开；无法重开的由财务判定 → 财务负责人（3 个工作日内）
  • 应开专票却开了普票 → 能重开则重开，不能的在台账登记原因 → 财务负责人
  • 二手/无票设备 → 不自行找"替票"，提交说明，由财务和法务判断；设备须登记为公司资产 → 法务负责人
  • 疑似重复报销 → 台账查重后冻结后一张，通知经办人 → 财务负责人（当天）
  • 缺票逾期 30 天 → 通知部门负责人；逾期 60 天 → CEO
  • 海外订阅每月开票困难 → 优先转公司统一账号对公采购（FIN-02/FIN-04）
  • 批量下载邮箱发票 → 必须限定时间范围，人工确认清单后再下载
  • 升级条件：缺票逾期 60 天、需建立或调整缺票治理机制与奖惩、替票口径需公司定调时，由 CEO 拍板（A（升级））

7. 衡量指标

  • 缺票率：当月无票支出金额 / 当月支出总额，目标 ≤ 3%
  • 补票周期：支出发生到发票入台账的自然日，目标 ≤ 15 天
  • 重复报销漏网数：目标 0
  • 专票合规率：取得专票的支出 / 应取专票的支出，目标 ≥ 95%
  • 历史挂账缺票金额：逐月下降

8. 低效诊断

  • 现象：发票交给谁、开专票还是普票靠全员群临时通知，已开普票需重开｜依据：「模态集团（全员群）」2026-02、「模态集团（全员群）」2026-06
  • 现象：历史缺票长期挂账，收集靠临时通知和奖励设想，没有常态机制｜依据：「财务部」2026-06
  • 现象：缺票治理机制提出后无人认领，此前发过的收集说明找不到｜依据：「财务小群」2026-07
  • 现象：外卖、小商户、海外订阅需逐家索票，经办人每月开票压力大；二手设备"替票"口径口口相传｜依据：「鸽子群模态分群」2026-07、「鸽子群模态分群」2026-08
  • 现象：垫付、索票、报销三者没有联动记录，"是否已报销"要财务回查｜依据：「发票报销服务台」2026-04、「发票报销服务台」2026-07
  • 现象：云服务/SaaS 不知道在哪里开票｜依据：「薪酬对接群」2026-04、「模态-飞书」2026-06
  • 现象：大量 PDF 发票手工重命名，命名无规范，用 Agent 试做出现命名错误和越范围下载｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07

9. 分支变体

  • 对公采购票 vs 个人垫付票
  • 票种：专票（默认）/ 普票 / 电子票 / 海外 invoice
  • 仅抵扣不报销的票：直接入台账标记"仅收票"，不走报销
  • 个人抬头票：不能直接入账，由财务判定冲抵或退回
  • 劳务票：需确认完税，见 FIN-14
  • 多主体：按支出承担主体分别归档

10. 待确认问题

  • 统一发票接收渠道选云盘目录、发票邮箱还是发票报销插件？能否只保留一个？
  • 默认要求专票的范围（全部支出还是特定费用类型）？
  • 缺票补交时限与逾期处理（通知、暂停报销）是否可行？
  • 开票积分奖励是否落地？
  • 替票的公司口径（允许/禁止）由谁拍板？
  • 发票命名规范是否采用本文格式？
  • 各主体的开票信息卡是否已有成文版本？
FIN-14劳务、顾问及奖金类报酬结算与个税待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：兼职、劳务人员、外部顾问、驻场人员、外部技术服务方按月或按项目结算报酬，或比赛奖金发放，需要确认用工性质与工作量、签协议、开票或代扣个税并付款
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（台账与确认单汇总，当前：黄莹·推断待确认）、业务负责人（确认工作量，当前：杨萌·推断待确认）、CEO（结算方式决策，当前：邴龙志·推断待确认）、COO（合同签批，当前：常元和·推断待确认）、创始人兼 CTO（技术服务方需求，当前：丁震宇·推断待确认）、赛事组织负责人（当前：白福康·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人
  • 核心流程：① 判定用工/合作性质 → ② 签合同或协议 → ③ 月度工作量确认 → ④ 开票或代扣个税 → ⑤ 付款申请关联合同 → ⑥ 付款 → ⑦ 台账更新与凭证归档
  • 交付结果：外部人员结算台账、已签署的合同/协议、工作确认单、发票或完税凭证、付款回单、奖金归属确认书
  • 状态依据：每次靠临时沟通决定按工资、劳务还是合作款处理；2026-04 至 2026-10 出现上月漏发、付款周期说法不一、工作量确认人不清；比赛奖金每次临时拟付款协议

1. 场景判定

  • 触发条件：兼职/劳务/顾问月度结算；外部技术服务方完成交付需付款；驻场顾问结算；参赛或办赛产生奖金
  • 典型说法：「是以合作款的形式，不要考虑工资这个形式」「确认下他的用工关系，好确定费用怎么处理」「先走合同申请，再提付款申请关联合同申请」「确认大赛奖金发放流程」
  • 判断问题：收款人不在本公司工资表中，且报酬按工作量、项目或奖项结算？是 → 本流程
  • 不归本流程管：正式员工工资 → 请走 HR-15；用工主体判定与劳动合同 → 请走 HR-04；实习生管理 → 请走 HR-07；外部合作协议起草审核 → 请走 LEG-05；一般采购付款 → 请走 FIN-01；渠道/开发者分成 → 请走 FIN-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
结算与个税 判定计税方式、开票或代扣、付款、凭证归档 R 财务负责人（当前：黄梦婷·推断待确认）
台账与汇总 维护外部人员台账、每月收集工作确认单、发起付款 R 人事负责人（当前：黄莹·推断待确认）
工作量确认 确认确认单内容与交付 R 业务负责人（当前：杨萌、王皓南·推断待确认）
结算方式决策 合作款/劳务/工资的选择与金额 A CEO（当前：邴龙志·推断待确认）
合同签批 合同审核签批 C COO（当前：常元和·推断待确认）
技术服务方需求 发起技术服务合同与追加费用 R 创始人兼 CTO（当前：丁震宇·推断待确认）
赛事奖金 提供获奖名单与奖金标准 R 赛事组织负责人（当前：白福康·推断待确认）
合规 用工性质、奖金协议合规意见 C 法务负责人（当前：李瑶·推断待确认）
业务发起人 发起合同申请、提交工作确认单与付款申请 R 需求所在部门经办人
外部人员 提交工作确认单、开具发票 R 兼职/劳务/顾问/外部服务方
付款审批人 按飞书付款审批流审批付款 C 按飞书付款审批流配置

3. 办之前请准备

  • 收款方类型：个人 / 个体户 / 境内公司 / 境外公司；身份信息由人事安全保存，不在群里传
  • 合同或协议：劳务协议、顾问协议、技术服务合同、赛事奖金费用归属及付款协议
  • 当期工作确认单（工作内容、工作量、交付物链接、确认人）
  • 增值税发票（或个人代开），或代扣个税所需信息
  • 奖金：获奖名单、税前/税后口径、费用承担主体

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合作开始前判定性质（劳务个人/个体户/公司对公/赛事奖金），登记台账 人事负责人 + 财务负责人 合作开始前 多维表格 台账记录 👤人工判断
2 发起合同申请并签署对应协议 业务发起人 合作开始前 飞书合同审批 已签协议 🔧飞书固化
3 提交月度工作确认单 外部人员/业务发起人 次月 3 个工作日内 飞书表单 确认单 🔧飞书固化
4 确认工作量与应付金额 业务负责人 收到后 2 个工作日内 飞书审批 确认结果 👤人工判断
5 按性质处理税票：劳务个人预扣个税并开票；对公收增值税发票；奖金按偶然所得代扣 财务负责人 确认后 3 个工作日内 个税系统/发票 计税表、发票 👤人工判断
6 提交付款申请，关联合同，上传确认单与发票；先付后票的回票后在评论区补 人事负责人/业务发起人 每月 10 日前 飞书付款申请 付款单 🔧飞书固化
7 审批并付款 付款审批人/财务负责人 审批通过后 3 个工作日内 网银 付款回单 🔧+👤
8 更新台账：已付期数、终止日期；合作终止当月停止月结 人事负责人 付款当天 多维表格 台账 🤖自动化

5. 交付物与模板

  • 交付物：外部人员结算台账、协议、工作确认单、发票或完税凭证、付款回单、奖金归属确认书
  • 台账字段：编号、人员/单位、性质、所属主体、合作起止、计费方式（月固定/按工作量/按项目/奖金）、付款周期、业务确认人、合同编号、开票方式、当月状态、终止日期
  • 工作确认单字段：期间、工作内容、工作量、交付物链接、确认人、确认日期、应付金额
  • 用工性质决策树（建议）：是否受公司日常管理 → 是否长期 → 个人/个体户/公司 → 对应计税与票据要求

6. 异常与升级

  • 用工性质不清（实习/劳务/工资混用）→ 暂停付款，人事与财务 2 个工作日内出意见 → CEO 决策
  • 无法提供发票 → 不得自行改按工资申报，由财务提出替代方案 → CEO
  • 上月漏发 → 本月补发并在台账标注原因 → 人事负责人
  • 付款周期争议（按月/按季）→ 以合同条款为准，合同未约定的补签 → COO
  • 预付款只做了口头沟通 → 一律以付款申请为准，口头约定不付款 → 财务负责人
  • 奖金涉及跨主体付款 → 先签费用归属及付款协议 → 法务负责人

7. 衡量指标

  • 准时结算率：次月 10 日前完成付款的人次占比，目标 ≥ 95%
  • 漏发次数：目标 0
  • 协议覆盖率：有已签协议的外部人员占比，目标 100%
  • 税票合规率：有发票或完税凭证的付款占比，目标 100%
  • 奖金发放周期：公布获奖到付款的工作日，目标 ≤ 15 个工作日

8. 低效诊断

  • 现象：工作量由谁确认不清，出现上月漏发｜依据：「模态人事大主管」2026-05、「模态人事大主管」2026-06
  • 现象：合作款、劳务、工资的结算方式每次临时讨论，合规边界不明｜依据：「模态人事大主管」2026-07、「薪酬对接群」2026-05
  • 现象：财务需反问用工关系才能确定费用怎么处理｜依据：「薪酬对接群」2026-04
  • 现象：驻场顾问付款周期说法不一，预付款口头沟通未同步财务｜依据：「薪酬对接群」2026-07、「薪酬对接群」2026-09
  • 现象：比赛奖金每次临时拟付款协议、临时确认个税口径｜依据：「财务部」2026-06、「财务部」2026-08

9. 分支变体

  • 劳务个人：按劳务报酬预扣个税并开增值税发票
  • 个体户/外包公司：对公付款，收增值税发票
  • 境外公司（如香港公司）：按境外付款处理，见 FIN-04
  • 外部技术服务方：先合同申请，再付款申请关联合同；追加费用并入技术服务费，不单独报销
  • 驻场顾问：对公付款，周期按合同
  • 比赛奖金：签《赛事奖金费用归属及付款协议》，偶然所得代扣个税，留存入账凭证与奖金归属确认书；办赛主体与付款主体不同时先签费用归属协议

10. 待确认问题

  • 本流程主责放在财务还是人事？
  • 各业务线的工作量确认人名单？
  • 无发票的劳务能否按工资申报，公司口径是什么？
  • 驻场顾问付款按月还是按季？
  • 奖金税前/税后标准由谁定？
  • 是否需要法务出一份用工性质判定意见模板？
FIN-15支付通道选型、商户进件与收款权限开通待新建250

状态：待新建｜证据：有证据（卡片 12 张 / 会话 9 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：产品或新主体需要上线收款、分账，或已有商户需开通网银、微信/支付宝、公众号/小程序支付、临时额度，或渠道风控、资质异常导致支付失败
  • 负责人：主责——支付渠道负责人（汇付商户与渠道控台，当前：徐莉·推断待确认）；协同——创始人兼 CTO（需求发起与选型拍板，当前：丁震宇·推断待确认）、财务负责人（进件材料、流水与合同，当前：黄梦婷·推断待确认）、综合部负责人（主体证照与协议，当前：赵雪冰·推断待确认）、支付研发（当前：陈锦杰、王子明、张楠·推断待确认）、鼎慧商户管理员（当前：杨萌·推断待确认）、CEO（对接支付方高层，当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO
  • 核心流程：① 登记收款需求 → ② 查台账/通道选型评估 → ③ 拍板主体与通道 → ④ 准备进件材料 → ⑤ 提交进件并跟进 → ⑥ 安全交接密钥 → ⑦ 沙箱 + 小额实测 → ⑧ 登记台账并持续监控资质
  • 交付结果：已开通并实测通过的商户与通道；主体-商户号-appid-支付能力台账；选型评估记录；进件材料包；风控材料标准包
  • 状态依据：每次靠群内临时协调；2026-04 至 2026-10 出现商户号用错主体、商户被迁移后找不到、同一商户配置连续多次修改仍不匹配、支付权限未开通导致大量报错、资质受阻直到客户反馈才发现等问题，没有商户台账和资质监控

1. 场景判定

  • 触发条件：新产品/新主体要收款；需要分账；要开通网银 2B、微信/支付宝/公众号/小程序支付或临时额度；手续费压力或渠道警告需换通道；支付拉起失败、风控告警
  • 典型说法：「再进件一个商户」「生产收款账号是哪个」「不然没法开银行收款」「会费的商户换成这个，换完再测试」「支付拉起失败了」「要去找支付方处理」「记录一下，避免过两天忘了」
  • 判断问题：要解决的是"钱走哪个通道、进哪个主体的哪个商户"吗？是 → 本流程
  • 不归本流程管：每日对账与手续费差异 → 请走 FIN-24；资金/分账异常数据修复 → 请走 FIN-25；渠道/开发者分成结算 → 请走 FIN-23；客户充值到账与额度开通 → 请走 FIN-17；ICP 备案 → 请走 LEG-23；用户协议与支付条款 → 请走 LEG-18；支付分账合作协议审核与用印 → 请走 LEG-04、LEG-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
支付渠道负责人 维护商户台账、选型对比、进件跟进、资质监控、对接支付方 R 支付渠道负责人（当前：徐莉·推断待确认）
需求发起与拍板 提出收款需求，决定主体与通道，定风控话术 A 创始人兼 CTO（当前：丁震宇·推断待确认）
进件材料 银行流水、合同、开户材料 R 财务负责人（当前：黄梦婷·推断待确认）
证照与协议 主体证照、盖章协议扫描件 R 综合部负责人（当前：赵雪冰·推断待确认）、总经办（当前：田杰·推断待确认）
支付研发 接收密钥、配置商户、沙箱与实测、告警排查 R 支付研发（当前：陈锦杰、王子明、张楠·推断待确认）
测试 商户切换后支付回归测试 R 测试负责人（跃竞线当前：赵伟龙·推断待确认）
鼎慧商户管理 鼎慧主体汇付商户管理员 C 产品负责人（当前：杨萌·推断待确认）
高层催办 支付方审核卡顿时对接对方高层 C CEO（当前：邴龙志·推断待确认）
合规 分账协议、风控话术合规意见 C 法务负责人（当前：李瑶·推断待确认）
需求发起人 提交收款需求单、提供业务材料 R 产品/业务负责人（按需求指定）

3. 办之前请准备

  • 需求单：收款主体、产品/业务、收谁的钱（2B/2C）、预计流水、是否分账、计划上线日期
  • 主体材料：营业执照、法人证件（先核对有效期）、开户许可、ICP 备案截图
  • 业务材料：网站链接、测试账号、产品介绍与演示视频、价格说明（按"软件服务/订阅/充值服务"表述，避免只写"卖 token"）、交付证明
  • 流水材料：单笔最高一笔入账凭证、入账最多一天的全部流水、对应合同（合同主体须与入账主体一致）
  • 协议：平台备案支付分账合作协议等（签字盖章后扫描）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交收款需求单 需求发起人 计划上线前 20 个工作日 飞书表单 需求单 🔧飞书固化
2 查台账是否已有可用商户；需新开则做通道对比（费率、分账费、结算周期、合规、改造量） 支付渠道负责人 3 个工作日内 多维表格 + 云文档 选型评估表 👤人工判断
3 拍板主体与通道，结论存档；重大变更报 CEO CTO 评估后 2 个工作日内 云文档 决策记录 👤人工判断
4 发材料清单，各方补齐；盖章协议走用印 支付渠道负责人/财务/综合部 5 个工作日内 进件材料表单 材料包 🔧飞书固化
5 提交进件，每 3 个工作日跟进一次并在群内同步进度 支付渠道负责人 提交后持续至开通 支付方控台 进度记录 🔧+👤
6 开通后密钥、账密通过安全方式交给支付研发，不在群内明文 支付渠道负责人 开通当天 密码管理工具 交接记录 👤人工判断
7 配置商户，沙箱跑通后用小额真实支付验证到账主体与流水 支付研发 + 测试 2 个工作日内 测试服/支付方后台 实测报告 👤人工判断
8 更新台账；支付失败/风控类告警路由给支付渠道负责人并自动建任务 支付渠道负责人 上线当天 多维表格 + 告警机器人 台账、告警规则 🔧+🤖
9 每月核对商户资质、证件有效期、已开通能力 支付渠道负责人 每月 5 日前 多维表格 核对记录 🤖自动化

5. 交付物与模板

  • 交付物：商户台账、选型评估表、进件材料包、风控材料标准包、上线检查表、实测报告
  • 商户台账字段：主体、商户号、所属服务商、通道（微信/支付宝/网银/公众号/小程序）、appid、已开通能力、费率与分账费、用途/产品、管理员、密钥保管人、资质状态、证件到期日、关联协议编号与有效期、最近核对日
  • 选型评估表字段：通道、技术服务费、费率、分账费、结算周期、合规资质、对接支持、改造量、结论
  • 风控材料标准包：产品介绍、演示视频、交付证明、价格说明、敏感词清单
  • 上线检查表：主体匹配、展示名称、回调方式、分账、手续费、并发扣费、退款、发票

6. 异常与升级

  • 支付拉起失败/拒付告警 → 支付研发 30 分钟内初判；属资质/风控的由支付渠道负责人当天联系支付方并在群内同步结论 → CTO（4 小时未恢复）
  • 客户已无法支付 → 先引导切换可用通道，同步客户成功团队统一口径 → 支付渠道负责人
  • 风控审核要求整改 → 按风控材料包补材料，产品文案 2 个工作日内调整 → CTO
  • 支付方审核超 10 个工作日无进展 → CEO 对接支付方高层
  • 证件过期、必填项缺失 → 财务/综合部 3 个工作日内补齐
  • 商户号与主体不符、资金进错主体 → 立即停用并上报 → 财务负责人 + CTO，按 FIN-25、FIN-32 处理
  • 商户被迁移到其他服务商 → 重新入驻并更新台账 → 支付渠道负责人

7. 衡量指标

  • 进件周期：需求单提交到实测通过的工作日，目标 ≤ 20 个工作日
  • 一次通过率：开通/切换后无需返工配置的比例，目标 ≥ 90%
  • 资质类故障发现时长：首条告警到负责人确认的时长，目标 ≤ 2 小时
  • 台账完整率：字段完整的商户占比，目标 100%
  • 分通道支付成功率：目标 ≥ 98%

8. 低效诊断

  • 现象：支付通道方案多次变化（官方 → 第三方聚合 → 汇付），回调与分账反复返工，谁提供商户信息、钱进谁的账不清｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：主体与商户对应关系靠记忆，商户迁移服务商后找不到；进件进度靠反复"推一下"｜依据：「LeapPay」2026-07、「LeapPay」2026-10
  • 现象：开通银行收款材料没有通用清单，临时搭建收款网站，流水与合同主体对不上，材料卡在负责人处需反复催｜依据：「鼎慧产研决策部」2026-07、「模态2B支付」2026-07、「模态2B支付」2026-08
  • 现象：风控审核反复补材料，"卖 token"的表述触发风控，结果迟迟不回｜依据：「LeapPay」2026-05、「LeapPay」2026-08
  • 现象：商户切换连续多次修改配置仍不匹配，支付权限未开通导致大量报错｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-10
  • 现象：资质受阻引起的支付失败夜间才有人跟进，客户长期无法用微信支付，直到客户反馈才发现；与支付方的沟通结果未在群内同步｜依据：「告警通知群」2026-09
  • 现象：分账、手续费问题上线后才发现，测试范围不含分账｜依据：「LeapPPT」2026-05
  • 现象：选型调研结论散落在聊天中，需要提醒"记录下来"｜依据：「跃竞市场决策」2026-07

9. 分支变体

  • 2C 小额：当前口径走苏州模态主体；2B LeapCore：武汉模态主体；鼎慧新业务：鼎慧主体新开户（均待确认）
  • 企业进件：人工办理，不做接口
  • 跃竞：会费商户切换、小程序主体切换，需同步认证、备案、公众号/小程序支付权限
  • 海外收款（stripe/polar 等）：另行评估合规
  • 平台分账（MercAll/LeapPPT）：上线前须有分账与对账规则（见 FIN-23、FIN-24）
  • 微信渠道风控频繁：优先支付宝/网银，微信支付按风控结果决定是否暂缓

10. 待确认问题

  • 集团层面的支付渠道负责人是否为当前推断人选？鼎慧商户管理员是否仍由产品负责人担任？
  • 各主体与收款场景的对应口径是否如第 9 节？
  • 通道选型的重大变更是否需报 CEO 或股东？
  • 进件周期 20 个工作日是否现实？
  • 商户密钥用什么工具保管、谁保管？
  • 资质月度核对由支付渠道负责人还是财务执行？
FIN-16内部测试与客户赠送额度申请审批待新建128

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频4 × 耗2 × 跨4 × 险4

  • 适用场景：内部测试、FDE、演示账号，或新交付、试用客户需要平台额度、词元、兑换券时的申请、审批、充值/发券、台账登记、成本归属与回收
  • 负责人：主责——额度审批人（产品负责人，当前：杨萌·推断待确认）；协同——后台充值执行（当前：柯逸飞、邓乾、宋祺睿·推断待确认）、商务负责人（客户特批，当前：李鹏为·推断待确认）、财务负责人（成本归属与渠道线下充值，当前：黄梦婷·推断待确认）、FDE 负责人（培训机额度标准，当前：吴亚军·推断待确认）、生态组负责人（社区卡密，当前：陈梦琪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交额度申请 → ② 按标准审批 → ③ 超标准特批 → ④ 后台充值/生成券 → ⑤ 申请人确认 → ⑥ 台账登记与成本归属 → ⑦ 月度对账 → ⑧ 到期回收
  • 交付结果：经审批的额度申请记录、后台充值/发券记录、额度台账（对象、金额、用途、成本中心）、月度赠送额度成本汇总
  • 状态依据：内部测试、客户赠送、兑换券均靠群内口头申请和临时拍板，没有统一审批与台账；2026-06 测试工具调用管理员账号乱充值后删号，导致平台总账异常；2026-03 兑换券数量与发放对象未经审批即发布被叫停；客户预充额度约 20 次靠群内请求

1. 场景判定

  • 触发条件：测试/演示账号余额不足；FDE 培训机、演示环境需要额度；新交付客户预充、试用客户赠送；生成兑换券用于社区售卖或内部赠送；用户"执行失败"实为余额不足需要补发
  • 典型说法：「谁给我 LeapCore 充点额度」「走一下审批」「这个客户充多少」「需要这会就充上」「只有买的机子才送额度」「涉及钱的事能不能严谨一点」
  • 判断问题：这笔额度是公司"送出或内部消耗"的、没有对应客户付款？是 → 本流程；有客户付款 → 不是本流程
  • 不归本流程管：客户/渠道试用的判断、开通与转化跟进 → 请走 SAL-16（试用所需额度仍按本条审批）；客户付费充值到账与额度开通 → 请走 FIN-17；客户充值开票 → 请走 FIN-18；计费扣费异常与退补 → 请走 FIN-29；员工个人 AI 补贴与自研产品充值 → 请走 FIN-10；上游模型账户充值 → 请走 FIN-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
额度审批人 维护额度标准、审批常规申请、控制内部测试总额度 A 产品负责人（当前：杨萌·推断待确认）
后台执行 按审批充值、配置赠送额度、生成兑换券、回收 R 后台运维（当前：柯逸飞、邓乾、宋祺睿·推断待确认）
客户特批 超标准的客户赠送、重点客户 A（升级） 商务负责人（当前：李鹏为·推断待确认）
申请人 填写申请、确认到账 R 销售/交付/测试/FDE（当前：游家豪、张东郅等·推断待确认）
财务 成本归属、渠道线下充值记录、月度汇总 C 财务负责人（当前：黄梦婷·推断待确认）
FDE 标准 培训机/每人额度标准 C FDE 负责人（当前：吴亚军·推断待确认）
卡密运营 社区卡密录入与发放 R 生态组负责人（当前：陈梦琪·推断待确认）
兜底 资金相关争议、批量发券上游资金确认 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 对象：内部账号或客户（台账中用编号）、实例 ID/机器备注、账号
  • 用途：测试 / 演示 / 培训 / 交付预充 / 试用 / 补偿 / 社区售卖
  • 金额，或券面额 × 数量、有效期、是否一次性兑换
  • 凭证：交付单"预充额度"题、CRM 记录、合同或商务批示
  • 成本中心：销售成本（客户赠送）/ 研发测试 / 市场推广

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交额度申请（对象、实例 ID、金额、用途、依据、成本中心） 申请人 需要前 1 个工作日；紧急演示标注加急 飞书审批"额度申请" 申请单 🔧飞书固化
2 标准内审批（内部测试按人/席位上限；买机赠送按固定额度；未付款演示机小额） 产品负责人 工作时间 2 小时内 飞书审批 审批结果 👤人工判断
3 超标准或重点客户转商务负责人特批；批量生成兑换券须 CTO 确认上游资金 商务负责人/CTO 1 个工作日内 飞书审批 特批记录 👤人工判断
4 后台充值/配置赠送额度/生成券（一次性兑换、按人绑定），备注审批单号 后台执行 审批后 2 小时内 NewAPI/LeapCore 管理后台 充值记录 🤖+👤
5 确认到账并在审批单回复 申请人 当天 飞书审批评论 到账确认 🔧飞书固化
6 写入额度台账 后台执行 充值当天 多维表格 台账记录 🤖自动化
7 月度对账：台账 vs 后台实际 vs 上游消耗；赠送额度按成本中心汇总 财务负责人 次月 5 个工作日内 多维表格/脚本 月度成本表 🤖自动化
8 测试结束、人员离职、试用到期后回收或冻结额度 后台执行 到期后 3 个工作日内 管理后台 回收记录 🔧+👤

5. 交付物与模板

  • 交付物：额度申请单、额度台账、兑换券发放清单、月度赠送成本汇总、额度标准表
  • 额度台账字段：申请单号、日期、对象类型（内部/FDE/演示/客户/社区）、对象编号、实例 ID、平台（LeapAll/LeapCore）、金额或券面额 × 数量、用途、成本中心、审批人、执行人、到期/回收日、状态
  • 额度标准表：内部测试每人上限、内部测试总额度、FDE 培训机每机额度、买机赠送额度、未付款演示机额度、补偿额度——由审批人维护，具体数值待确认
  • 兑换券规则：一次性兑换、按领取人绑定、通知中不出现明文卡密、生成前确认上游资金

6. 异常与升级

  • 紧急演示需当场充值 → 允许先充后补单，2 小时内补审批 → 产品负责人
  • 测试误充值、删号导致总账异常 → 立即冻结相关账号，研发 1 个工作日内修复并加防护（余额未清不删号、充值可回滚）→ CTO
  • 兑换码可重复兑换或超发 → 暂停兑换，统计超发量与上游缺口 → CTO（当天）
  • 销售为渠道演示机自行垫付 → 不走个人报销，转渠道系统线下充值流程登记 → 财务负责人
  • 同一客户多台机器是否重复赠送不明 → 以合同/交付单为准，不明则问商务负责人
  • 用户额度用完报错 → 先查台账是否在标准内，补发须走申请 → 产品负责人
  • 管理后台只能加不能减、误输入 → 记录后由研发修正并纳入需求 → CTO
  • 升级条件：超出额度标准或重点/政府客户赠送，由商务负责人特批（A（升级））；批量生成兑换券、资金相关争议或总账异常，由创始人兼 CTO 拍板（A（升级））；标准内申请由产品负责人审批

7. 衡量指标

  • 审批留痕率：有审批单的赠送充值笔数 / 全部赠送充值笔数，目标 100%
  • 审批到充值时长：目标 ≤ 4 个工作小时
  • 台账与后台差异笔数/月：目标 0
  • 赠送额度成本：客户赠送额度 / 当月销售收入，按月监控
  • 到期未回收额度：逐月下降

8. 低效诊断

  • 现象：测试账号余额不足卡住测试，充值靠在群里点名后台人员｜依据：「Leap产研测」2026-05、「Leap产研测」2026-10
  • 现象：内部测试额度标准（席位、每人上限、总额度）多次口头变化，谁审批不明｜依据：「Leap产研测」2026-06
  • 现象：测试工具乱充值后删号导致总账异常，事后才补防护｜依据：「Leap产研测」2026-06
  • 现象：兑换券数量、面额、对象未经审批即发布，出现可重复兑换与超卖风险｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：客户预充额度未在交付单填写，紧急演示前临时要求充值；先充后补钱、先垫后报销｜依据：「某地方政府客户项目群」2026-07、「某研究院客户项目群」2026-09
  • 现象：余额不足报错显示为技术代码，用户无法自查余额，靠群内补发｜依据：「Leap反馈群」2026-07
  • 现象：赠送额度未明确计入销售成本，后台看不到总充值与余额｜依据：「某地方政府客户项目群」2026-08

9. 分支变体

  • 内部测试/开发：按每人上限与总额度，产品负责人审批
  • FDE 培训机/演示环境：按 FDE 负责人确认的每机标准
  • 客户：买机赠送固定额度；未付款演示机小额；重点/政府客户商务特批；渠道自用演示机走渠道系统线下充值流程
  • 兑换券：对外售卖（社区卡密库）/ 内部赠送 / 演示账号，须审批面额、数量、对象并确认上游资金
  • 用户补偿（误扣等）：走 FIN-29

10. 待确认问题

  • 额度审批人是否统一为产品负责人？客户特批是否为商务负责人？
  • 各类标准额度的当前数值是多少？
  • 赠送额度计入哪个成本科目/成本中心？
  • 是否已有"额度申请"飞书审批？名称是什么？
  • 后台充值执行以谁为主、谁为备份？
  • 批量生成兑换券的审批门槛（面额 × 数量）？
FIN-17客户充值到账审核与额度开通待新建300

状态：待新建｜证据：有证据（卡片 11 张 / 会话 10 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：企业/渠道客户为 LeapCore、LeapAll 付款充值（线上支付或线下对公转账），或新部署机器需预充、额度用尽需续充时，从确认到账到开通额度、对账闭环
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、额度充值执行人（当前：柯逸飞·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交充值订单/下载结算单 → ② 付款并上传汇款凭证 → ③ 财务审核到账 → ④ 接口开通额度（含赠送） → ⑤ 订单完结并通知 → ⑥ 日对账与客户/实例绑定 → ⑦ 退款/补发/错充处理
  • 交付结果：已审核到账、额度到位且留痕的充值订单；订单—支付—到账—额度—客户/实例一一对应的充值台账与月度对账表
  • 状态依据：线上充值 8 月底已上线，但线下对公充值（结算单+凭证+财务审核）到 10 月中仍在开发验收，此前由 IT 手工录额度；6～10 月多个群反复出现"充了没、充多少""统计不全""对不上客户"，金额靠口头确认，对账靠研发人工

1. 场景判定

  • 触发条件：客户在 LeapCore 管理后台提交线下对公充值订单或完成线上支付；交付部署完成需给企业账号预充；客户额度耗尽要求续充；渠道客户购买额度；出现充值未到账、统计不全、兑换券买错需退款
  • 典型说法：「对公汇款给我们，我们给他们发额度」「没传凭证就不给充值余额」「确认下现在具体充值的金额」「充值的人员统计不全面」「客户那边没额度了」
  • 判断问题：这笔额度是否对应客户真实到账的付款，或经批准的赠送/试用？金额是否已与合同或结算单核对？
  • 不归本流程管：充值后申请发票 → 请走 FIN-18；销售合同项目款回款与收入确认 → 请走 FIN-21；支付渠道每日对账差异与手续费 → 请走 FIN-24；渠道/开发者分润 → 请走 FIN-23；内部员工测试额度 → 走研发测试资源申请，不入收入台账

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
到账审核 核对公户到账、金额、付款方与订单一致，审核通过/驳回，月度对账 A/R 财务负责人（当前：黄梦婷·推断待确认）
产品口径 充值规则、结算单与提示文案、充赠与起充规则落地 R LeapCore 产品负责人（当前：杨萌·推断待确认）
额度执行 接口失败兜底充值、预充/续充执行并回图 R 额度充值执行人（当前：柯逸飞·推断待确认）
系统支撑 渠道系统待审核列表、充值接口、对账数据同步与实例绑定 R 渠道系统研发（当前：陈子康·推断待确认）
金额与赠送审批 确认合同金额、试用/预充额度上限 A（升级） 销售负责人（当前：李鹏为·推断待确认）
客户对接 告知流程、催传凭证、确认客户与实例归属 R 销售对接人（当前：待指定）
部署信息 提供组织指纹/实例 ID，换机时迁移原余额 C 交付部署工程师（当前：游家豪·推断待确认）
客户 提交充值订单、上传汇款凭证 I 外部客户（销售对接人协助）
兜底 跨部门争议、规则拍板 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 客户全称（与渠道系统认证主体一致）、客户编号、合同或充值结算单编号（CZJS 开头）
  • LeapCore 组织指纹/实例 ID 或 LeapAll 账号，确认为正式服而非测试服
  • 汇款凭证（银行回单或付款凭证截图）与付款方户名
  • 充值金额、是否适用充赠规则、经办销售
  • 预充/赠送类：已审批的赠送申请单及额度上限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 客户提交充值订单并下载盖章结算单（线下）；或线上支付 客户（销售对接人协助） 付款前 LeapCore 管理后台 充值订单、结算单 PDF 🔧+👤
2 转账后上传汇款凭证；未上传不进入审核 客户 转账后 1 个工作日内 LeapCore 管理后台 汇款凭证 🔧+👤
3 订单与凭证同步至渠道系统待审核列表，财务核对公户到账金额、付款方户名、订单号 财务负责人 同步后 1 个工作日内 渠道系统、企业网银 审核通过/驳回结论 👤人工判断
4 审核通过后渠道系统调用 LeapCore 充值接口充值，并按规则追加赠送额度；接口失败转人工充值并登记手工单号 渠道系统；额度充值执行人兜底 审核通过后 2 小时内 渠道系统、充值后台 充值记录 🤖自动化
5 预充/续充/试用赠送：销售提交赠送申请，销售负责人审批，执行人充值并回图 销售对接人→销售负责人→额度充值执行人 审批通过当日 飞书审批 审批单、充值截图 🔧飞书固化
6 订单置为已完成，机器人通知客户与销售，客户可申请发票 系统 充值完成即时 渠道系统、飞书机器人 完成通知 🔧+🤖
7 日对账：拉取正式服充值单与余额，与订单、到账比对；对不上客户的进入"待处理"，人工绑定实例 渠道系统研发出数，财务确认 每个工作日 12:00 前处理前一日 渠道系统 日对账结果、差异清单 🤖+👤
8 月末对账：充值台账与公户流水、收入台账核对 财务负责人 次月 5 个工作日内 渠道系统、多维表格 月度充值对账表 🔧飞书固化
9 退款、补发、错充、兑换券买错：提交退款/补发审批，财务审批后执行 销售对接人→财务负责人 收到申请后 2 个工作日内 飞书审批 审批单、退款回单 👤人工判断

5. 交付物与模板

  • 交付物：充值结算单、汇款凭证、审核记录、充值/赠送记录、日对账差异清单、月度充值对账表
  • 建议模板/表单：
    • 《客户额度充值/赠送申请》飞书审批：客户全称、客户编号、产品（LeapCore/LeapAll）、实例 ID/组织指纹、环境、类型（付款充值/试用赠送/合同预充/补发/迁移）、金额、赠送额度、合同或结算单编号、到账凭证、经办销售、执行人、复核人
    • 《充值台账》多维表格：订单号、客户、实例 ID、支付方式（线上/线下对公）、付款金额、到账日期、到账金额、充值额度、赠送额度、执行方式（接口/手工）、开票状态、对账状态、差异说明
    • 固定提示文案：「请上传汇款凭证，财务确认到账后为您充值」

6. 异常与升级

  • 已上传凭证但公户未见到账 → 标记"待到账"，销售对接人联系客户 → 3 个工作日仍未到账升级财务负责人
  • 合同总额与实际可充 API 额度不一致（部分款项用于其他产品） → 暂停充值，销售提供拆分依据 → 销售负责人 1 个工作日内确认
  • 充值接口失败 → 研发 2 小时内排查；当日未恢复转人工充值并补登手工单号 → 升级 LeapCore 产品负责人
  • 连续充值记录覆盖、到账延迟 → 研发修复，财务按流水补记 → 超 1 个工作日升级产品负责人
  • 充值对不上客户/实例 → 进入待处理清单，销售/交付 2 个工作日内确认归属
  • 换机后原余额不清 → 交付人员先查询原实例余额并提迁移申请，审批后迁移
  • 兑换券买错、错充 → 走退款审批，5 个工作日内退回或冲正
  • 升级条件：预充/赠送超出已审批上限、或合同金额与可充额度口径不一致时，由销售负责人确认（A（升级））；跨部门争议或充值规则需调整时，由综合部负责人拍板（A（升级））；其余到账审核由财务负责人决定

7. 衡量指标

  • 到账→开通时长：凭证上传到额度到位的工作小时，目标线下对公 ≤ 1 个工作日
  • 对账差异率 = 当月差异笔数 / 充值总笔数，目标 0；差异 3 个工作日内关闭
  • 无审批赠送/预充笔数：目标 0
  • 未绑定客户的充值单数：目标月末清零
  • 客户催问充值进度次数：按月统计，目标逐月下降

8. 低效诊断

  • 现象：充值金额靠群聊口头确认，合同总额与实际可充额度口径不一，事后改待办修正｜依据：「鼎慧产研决策部」2026-06
  • 现象：线下对公充值缺财务审核环节，由 IT 手工录额度；结算单/合同/充值订单名称和生成方反复争论，接口文档缺失、交接断档｜依据：「渠道系统优化」2026-09、「渠道系统优化」2026-10
  • 现象：充值统计不全、连续充值记录被覆盖、到账转人工，对账全靠研发｜依据：「Leap产研测」2026-06
  • 现象：上线支付后才验证能否充值，生产误用测试支付配置，实充前未记初始余额｜依据：「Leap产研测」2026-08
  • 现象：预充金额由谁定不清，额度耗尽客户才反馈，换机后原余额不清｜依据：「Leapcore 某客户服务群」2026-08、「Leapcore 某客户服务群」2026-09
  • 现象：企业每次充值都要走合同，对公充值进度归属不清，兑换券记录不在订单中｜依据：「Leap反馈群」2026-07
  • 现象：对不上客户的充值单需人工打标、绑定实例｜依据：「渠道系统优化」2026-09

9. 分支变体

  • LeapCore 线下对公转账：结算单 + 汇款凭证 + 财务审核（主流程），线上通道为汇付，线下为公户
  • 线上支付：自动到账，财务不逐笔审核，按日对账（差异走 FIN-24）
  • 渠道客户购买额度：按渠道合同执行，渠道采购合同可能附带首充
  • 试用赠送/新机器预充：走赠送审批并设上限；销售负责人明确"不预充、等客户自充"的客户不得预充
  • 充赠规则：大额充值附赠 token，比例由财务与销售负责人维护
  • LeapAll 兑换券（渠道合作方发售）：券台账导入正式服，买错退款走退款审批
  • 内测→正式服额度迁移：管理员迁移并登记
  • 独立实例余额不互通：按实例分别充值和对账

10. 待确认问题

  • 到账审核主责是否为财务负责人？接口失败时人工充值由研发还是 IT 执行？
  • 线下审核 1 个工作日、接口失败 2 小时恢复是否可行？
  • 充赠比例、起充门槛、试用赠送上限由谁定？是否已成文？
  • 渠道系统线下充值状态机是否已与财务端到端跑通？上线日期？
  • 内部测试充值是否单独账户、单独审批、不入收入台账？
  • 兑换券台账由哪个岗位维护？
  • 银行到账自动对账是否继续暂不建设？
FIN-18客户充值订单开票待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：客户在 LeapCore/LeapAll 线上或线下充值 Token 后申请发票，或需集中登记对外开票（含兑换券、集采）时
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——LeapCore 产品负责人（当前：杨萌·推断待确认）、LeapCore 发票功能研发（当前：魏宗浩·推断待确认）、渠道系统维护负责人（当前：郭逸非·推断待确认）、销售支持（当前：韩诗琪·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 订单已支付并已充值 → ② 客户提交开票信息 → ③ 同步渠道系统待开票 → ④ 财务判定票种并开具 → ⑤ 上传发票回写订单 → ⑥ 通知客户并登记台账 → ⑦ 错票红冲重开
  • 交付结果：与充值订单一一对应、票种正确的电子发票，订单页可查看下载；对外开票台账完整
  • 状态依据：8 月起 LeapCore 订单页申请发票、渠道系统转财务开票的链路已设计并于 9 月上线入口；但 7～9 月仍反复出现"开票找谁""发票功能何时上线"追问，订单自动开票曾把专票错开成普票，对外开票零散无统一登记

1. 场景判定

  • 触发条件：客户充值成功后在订单页点击"申请发票"；客户通过销售、群聊要求为充值开票；兑换券、集采等对外开票需归集
  • 典型说法：「有人充值了要开发票」「请问如何开发票」「现在没上发票功能」「没等选择票已经开出来了」
  • 判断问题：这张发票对应的是充值订单（本流程）还是销售合同（FIN-19）？订单是否已支付且已充值到账？
  • 不归本流程管：销售合同、项目款开票与红冲 → 请走 FIN-19；软硬一体合同分税率开票 → 请走 FIN-20；到账审核与额度开通 → 请走 FIN-17；支付手续费发票 → 请走 FIN-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
开票 判定票种、开具、上传发票、红冲、台账 A/R 财务负责人（当前：黄梦婷·推断待确认）
产品口径 开票入口规则、对外文案、开票时限承诺 R LeapCore 产品负责人（当前：杨萌·推断待确认）
前台功能 订单页开票信息提交、发票链接展示、失败重试 R LeapCore 发票功能研发（当前：魏宗浩·推断待确认）
系统对接 渠道系统接收订单、待开票列表、文件存储与权限 R 渠道系统维护负责人（当前：郭逸非·推断待确认）
客户答疑 转达客户需求、回复开票进度 C 销售支持（当前：韩诗琪·推断待确认）
客户 在订单页提交开票信息 I 外部客户
兜底 开票规则拍板、跨部门争议 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 订单号（已支付、已充值状态）
  • 开票抬头、税号（与渠道系统认证公司名一致）、接收邮箱
  • 票种需求：普票/专票；专票需已签合同或开口协议
  • 签约主体（模态/鼎慧），确认开票主体与收款主体一致

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 系统校验开票条件：已支付 + 已充值才显示开票入口 系统 实时 LeapCore 订单页 可开票订单 🤖自动化
2 客户填写抬头、税号、邮箱，提交申请；页面提示"预计 7 个工作日内开具" 客户 充值后任意时间 LeapCore 订单页 开票申请 🔧飞书固化
3 申请同步至渠道系统待开票列表；同步失败提示客户重试并告警研发 系统 实时 渠道系统 API 待开票记录 🤖自动化
4 财务判定票种：未签合同只开普票；已签合同可开专票；抬头与合同/认证主体不一致的退回 财务负责人 收到后 2 个工作日内 渠道系统 票种结论 👤人工判断
5 在税务系统开具，按周批量处理 财务负责人 申请后 7 个工作日内 税务系统 电子发票 👤人工判断
6 上传发票文件至渠道系统，状态回写订单，客户订单页可查看下载 财务负责人 开具后 1 个工作日内 渠道系统 已开票订单 🔧+🤖
7 机器人通知客户/销售"发票已开具"；登记对外开票台账 系统；财务复核 上传即时 飞书机器人、多维表格 通知、台账记录 🔧+🤖
8 错票：先红冲再按正确票种重开，说明原因 财务负责人 发现后 3 个工作日内 税务系统 红字发票、新发票 👤人工判断

5. 交付物与模板

  • 交付物：电子发票、订单开票状态、对外开票台账、红冲记录
  • 建议模板/表单：
    • 开票申请字段：订单号、产品、支付方式、金额、抬头、税号、票种、邮箱、合同/开口协议编号、签约主体
    • 《对外开票台账》多维表格：订单号、客户、开票日期、票种、税率、发票号、开票主体、来源（充值/兑换券/集采）、是否红冲、经办人
    • 对外口径（销售、产品统一使用）：「订单页未显示发票，即财务排队开具中，预计 7 个工作日内完成」

6. 异常与升级

  • 同步渠道系统失败（权限 403、环境变量漏配） → 研发 4 小时内修复 → 超 1 个工作日升级渠道系统维护负责人
  • 自动开票票种错误（专票被开成普票） → 红冲重开；已入账无法更正的登记说明 → 财务负责人当日决定
  • 客户要求企业专票但未签合同 → 引导签署开口协议后再开 → 销售负责人协调
  • 超过 7 个工作日未开 → 财务说明原因 → 升级综合部负责人
  • 客户找不到入口、无人对接 → 销售支持统一受理转财务，1 个工作日内答复
  • 升级条件：超过 7 个工作日未开具、开票规则（默认票种、个人票口径）需调整或出现跨部门争议时，由综合部负责人拍板（A（升级））

7. 衡量指标

  • 开票周期：申请提交到发票上传的工作日，目标 ≤ 7 个工作日
  • 错票率 = 红冲张数 / 开票张数，目标 ≤ 1%
  • 开票催办次数：按月统计，目标逐月下降
  • 台账完整率 = 台账登记张数 / 实际开出张数，目标 100%

8. 低效诊断

  • 现象：需求从"自管发票状态"改为"全部跳转渠道系统"，企业充值迟迟未提测，普票/专票口径反复｜依据：「Leap产研测」2026-08
  • 现象：外部用户充值后要开票，受理人、审批、填写信息均不明，事到临头才要求建 SOP｜依据：「鼎慧产研决策部」2026-07
  • 现象：发票功能上线前客户无处申请，只能找财务单独开，由销售和产品兼职客服｜依据：「Leapcore 某客户服务群」2026-09
  • 现象：订单推送后系统默认自动开普票，需专票时只能红冲重开，部分已入账放弃更正｜依据：「模态跃迁 - HR/行政飞书咨询群」2026-07
  • 现象：线上充值上线时不支持自动生成合同和电子发票，靠临时口径和单独签开口协议过渡｜依据：「Leap市场销售通知群」2026-08、「Leap市场销售通知群」2026-10
  • 现象：发票上线时间被反复追问，人工开票环节无法省略｜依据：「Leap产研测」2026-09

9. 分支变体

  • LeapCore 企业充值：普票为主，签合同可开专票
  • LeapAll 个人/企业充值：个人票暂不支持，按财务确认口径办理
  • 线下对公充值：到账审核后（FIN-17）方可申请
  • 兑换券、集采、补贴类对外开票：系统按月导出清单给财务集中开具并登记台账
  • 开票主体：模态/鼎慧按签约与收款主体开具

10. 待确认问题

  • 充值订单开票主责是否为财务负责人？渠道系统后续维护归属是否已确定？
  • 对客户承诺 7 个工作日是否可行？是否按周固定批量开票日？
  • 个人充值能否开企业抬头？个人票是否开放？
  • 订单系统自动开票的默认票种如何预设，谁定期复核？
  • 兑换券、集采开票的月度清单由谁导出？
FIN-19销售合同开票申请与红冲待优化300

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：销售合同签署、交付验收或约定预付款节点到达后，业务申请开票；以及错票红冲、客户催票、收款认款核销时
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·合同台账（当前：韩诗琪·推断待确认）、总经办（当前：田杰·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 合同编号登记 → ② 业务提交开票申请 → ③ 财务校验开票条件与税率 → ④ 税务系统开具 → ⑤ 上传分发给申请人/客户 → ⑥ 回款认款与凭证核销 → ⑦ 错票红冲重开
  • 交付结果：税目税率正确、与合同和收款对应的发票；认款核销完成的收款记录与凭证
  • 状态依据：飞书"开票申请审批"已于 5 月搭建，10 月确定合同编号规则；但税率口径（13%/6%）多次临时确认，客户逐级催票，认款要靠群里提醒，金蝶对接仍在规划

1. 场景判定

  • 触发条件：销售合同签署且到达开票节点（验收单回传或合同约定预付款）；客户/渠道催问发票；发现发票错误需红冲；大额中标项目需先开票后付款
  • 典型说法：「开票申请时，大家备注上付款的情况」「这笔是开 13% 还是 6%」「合同反馈还没开票」「没看到发票的就是财务还在排队开」
  • 判断问题：有无已签合同与合同编号？开票条件（验收/预付款/到账）是否满足？税目是软件、硬件还是技术服务？
  • 不归本流程管：充值订单开票 → 请走 FIN-18；软硬一体合同拆分税率 → 请走 FIN-20；收入台账与收入确认 → 请走 FIN-21；境外客户形式发票 → 请走 FIN-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
开票与核销 校验条件、开具、红冲、认款核销、额度申请 A/R 财务负责人（当前：黄梦婷·推断待确认）
申请人 提交开票申请、备注付款情况、跟进客户 R 销售对接人（当前：待指定）
销售审批 审批开票申请、确认税目与收入归属 R 销售负责人（当前：李鹏为·推断待确认）
合同编号与台账 合同编号发放、台账维护、票样提供 R 销售支持·合同台账（当前：韩诗琪·推断待确认）
规则制定 开票条件、编号规则、金蝶对接流程设计 C 总经办（当前：田杰·推断待确认）
合规会签 大额拆分合同、关联方出账方案审核 C 法务负责人（当前：李瑶·推断待确认）
兜底 规则拍板、争议升级 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 合同编号（规则：WHMT-LC-材料类型-年份-月日-流水号，类型用拼音缩写 DLXY/QDCG/QDXS/CZXY/CZJS/YSD）
  • 合同扫描件、验收单/签收单（或预付款条款页）
  • 客户开票信息：抬头、税号、地址电话、开户行账号、接收邮箱
  • 开票项目与税率：软件/词元 6%，硬件 13%，软硬一体按 FIN-20 拆分
  • 付款情况：未付/已付/部分付款及到账日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合同签署后登记台账、获取合同编号 销售对接人、销售支持 签署后 1 个工作日内 合同台账/渠道系统 合同编号 🔧+🤖
2 提交开票申请：合同号、开票项目、税率、票种、金额、付款情况（必填） 销售对接人 达到开票节点后 2 个工作日内 飞书审批 开票申请单 🔧飞书固化
3 销售负责人审批 销售负责人 1 个工作日内 飞书审批 审批结论 🔧飞书固化
4 财务校验开票条件（验收单已回传或合同约定预付款）、税目税率、抬头；不符退回 财务负责人 2 个工作日内 飞书审批、合同台账 校验结论 👤人工判断
5 税务系统开具；开票额度不足时向税务专管员申请调整 财务负责人 校验通过后 3 个工作日内 税务系统 发票 👤人工判断
6 上传发票至审批单/渠道系统，系统通知申请人，申请人转发客户 财务负责人 开具当日 飞书审批、渠道系统 已分发发票 🔧飞书固化
7 回款到账后认款：关联合同号，确认收入归属，做收款核销与凭证 财务负责人；销售对接人确认款项来源 到账后 3 个工作日内 网银、财务系统 认款记录、凭证 🔧+👤
8 错票红冲：申请人提交红冲申请说明原因，财务红冲后重开 销售对接人、财务负责人 发现后 3 个工作日内 飞书审批、税务系统 红字发票、新发票 👤人工判断

5. 交付物与模板

  • 交付物：发票、开票申请审批单、认款核销记录、记账凭证、红冲记录
  • 建议模板/表单：
    • 《开票申请》飞书审批字段：合同编号（关联台账）、客户全称、税号、开票项目（下拉：软件/技术服务/硬件/词元）、税率（随项目带出）、票种、金额、付款情况（必填）、验收单附件、红冲原发票号（红冲时）
    • 《税目税率口径表》：产品/服务 → 税目 → 税率 → 是否适用软件即征即退
    • 客户催票 FAQ：开票条件、时限、查询方式

6. 异常与升级

  • 税率口径不清（新产品、词元类） → 财务负责人 1 个工作日内答复并补入口径表
  • 开票额度不足 → 财务当日向税务专管员申请调整 → 影响客户付款时同步销售负责人
  • 客户逐级催票 → 统一口径答复，禁止开特殊通道；超 5 个工作日未开升级综合部负责人
  • 大额中标项目需先开票后付款、拟拆分合同或向合作方/关联方出账 → 方案书面化，经法务、财务会签留痕；禁止平进平出或无真实交易的出账 → 升级 CEO 决策
  • 进款来源不明 → 财务在业财对接群发起认款，销售 2 个工作日内认领
  • 升级条件：超 5 个工作日未开票、开票规则需调整或跨部门争议时，由综合部负责人拍板（A（升级））；大额拆分合同或关联方出账方案由 CEO 决策

7. 衡量指标

  • 开票周期：审批通过到发票分发的工作日，目标 ≤ 3 个工作日
  • 红冲率 = 红冲张数 / 开票张数，目标 ≤ 1%
  • 认款及时率 = 3 个工作日内完成认款的笔数 / 到账笔数，目标 ≥ 95%
  • 开票申请退回率：因信息缺失退回的比例，目标 ≤ 10%

8. 低效诊断

  • 现象：合同编号规则由财务单方制定后又改版，认款时要临时找人要编号，财务反复问款项来源｜依据：「【模态】市场销售」2026-09、「【模态】市场销售」2026-10
  • 现象：开票在税务系统完成，无接口，开完手动上传；金蝶对接数据主责未定，研发不清楚发票流程｜依据：「公司内FDE」2026-09
  • 现象：词元类产品税率 13% 还是 6% 临时确认，红冲重开；客户反馈合同未开票｜依据：「打赢这一仗」2026-07、「财务部」2026-07
  • 现象：客户催渠道、渠道催销售、销售催财务，多方各自解释；财务一度找不到上传入口｜依据：「渠道系统优化」2026-09、「渠道系统优化」2026-10
  • 现象：大额中标后才规划开票、合同拆分与出账，关键方案转电话沟通未留痕｜依据：「苏州模态跃迁」2026-07、「苏州模态跃迁」2026-08

9. 分支变体

  • 渠道采购、渠道销售、充值协议、结算单、验收单：按编号类型区分
  • 繁星计划试用合同：金额为 0，交付不计收入，不开票
  • 预付款合同：验收单可能未回传，按合同条款校验
  • 软件产品即征即退：需软著、检测报告等资质
  • 收单机构手续费发票：走 FIN-24
  • 金蝶对接（规划）：合同系统校验与审批 → 推送金蝶 → 税务系统开票后上传 → 系统分发 → 金蝶核销凭证回传；上线前保留手动流程兜底

10. 待确认问题

  • 开票申请审批中是否保留销售负责人审批节点？
  • 开票条件"验收单回传"对预付款类合同如何例外？
  • 税目税率口径表由谁维护、何时成文？
  • 大额项目合同拆分与出账的会签链路（法务+财务+CEO）是否可行？
  • 金蝶对接上线时间与数据主责矩阵？
FIN-20软硬一体合同分税率开票与硬件基准价维护待优化240

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：LeapCore 等软硬一体销售合同起草、审核和开票时，按硬件 13%、软件及技术服务 6% 拆分金额；每月按采购价校准 SKU 硬件基准价
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——总经办（当前：田杰·推断待确认）、IT 价格维护（当前：游家豪·推断待确认）、渠道负责人·商务核价（当前：闫登辉·推断待确认）、法务负责人（当前：李瑶·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 月度核定硬件基准价 → ② SKU 配置录入留痕 → ③ 合同生成按型号自动拆分 → ④ 法务审核核对拆分 → ⑤ 财务分税率开票 → ⑥ 月度校准提醒与变更通知
  • 交付结果：软硬金额分列的合同、分税率发票；带生效时间和修改历史的 SKU 硬件基准价表
  • 状态依据：10-08 起新合同模板已要求拆分、渠道系统已有 SKU 价格配置；但基准价曾长期未定，"标准化产品怎么拆没人定"，月度校准提醒未配置，节假日发票按新旧规则开需临时确认

1. 场景判定

  • 触发条件：签署含硬件一体机与软件/技术服务的销售合同；为此类合同开票；每月校准节点到达；采购价发生明显变化
  • 典型说法：「软硬件一体的合同，签署时须将硬件与软件拆分」「调整只是公司内部的价格拆分，对客户实际支付金额没影响」「现在怎么拆还没定」
  • 判断问题：合同是否同时含硬件与软件/技术服务？所选型号本月基准价是否已生效？
  • 不归本流程管：纯软件或纯充值合同开票 → 请走 FIN-18 / FIN-19；硬件采购与付款 → 请走 FIN-01；渠道分成结算 → 请走 FIN-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规则与开票 税率规则解释、分税率开票、基准价复核 A/R 财务负责人（当前：黄梦婷·推断待确认）
规则发布 起草与发布拆分规则、通知销售团队 R 总经办（当前：田杰·推断待确认）
基准价录入 按采购价提出硬件基准价并在 SKU 配置录入 R IT 价格维护（当前：游家豪·推断待确认）
商务核价 与 IT 共同核定渠道版/终端版基准价 R 渠道负责人·商务核价（当前：闫登辉·推断待确认）
合同模板与审核 模板拆分条款、审核时核对拆分金额 R 法务负责人（当前：李瑶·推断待确认）
系统 SKU 双价格配置、合同生成时自动拆分、价格留痕 R 渠道系统研发（当前：陈子康·推断待确认）
销售执行 按规则起草合同、向客户解释 C 销售负责人（当前：李鹏为·推断待确认）
销售对接人 按基准价起草拆分合同 R 各销售对接人
兜底 定价争议、非标款拍板 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 合同型号清单（对应 SKU）、合同总价、客户类型（渠道提货/终端出货）
  • 本月生效的硬件基准价（渠道采购价/渠道售卖价两套）
  • 新版合同模板（10-08 起启用）
  • 定制款：硬件成本依据与审批记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 飞书任务自动提醒月度校准；IT 按最新采购价提出各 SKU 两套基准价建议 IT 价格维护 每月固定校准日前 3 个工作日 飞书任务、多维表格 基准价建议表 🔧飞书固化
2 商务核价确认，财务复核税负合理性 渠道负责人、财务负责人 校准日前 1 个工作日 多维表格 确认版基准价 👤人工判断
3 录入渠道系统 SKU 配置，系统留存价格、生效时间、修改人和历史 IT 价格维护 校准日当天 渠道系统 SKU 配置 生效价格 🔧飞书固化
4 发布本月基准价变更通知给销售、法务、财务 总经办 生效当天 飞书群公告 变更通知 🤖自动化
5 起草合同：按型号取基准价为硬件金额（13%），总价减硬件为软件及技术服务金额（6%）；合同总价不变 销售对接人（系统自动计算） 起草时 渠道系统合同生成 拆分合同 🤖自动化
6 法务审核核对拆分金额与模板条款 法务负责人 2 个工作日内 合同审批 审核结论 👤人工判断
7 开票：同一发票分两行或分开开具，硬件 13%、软件及技术服务 6% 财务负责人 按 FIN-19 时限 税务系统 分税率发票 👤人工判断
8 已生成或已签署的合同不随校准调整；定制款一事一议并留审批记录 财务负责人 持续 合同台账 例外记录 👤人工判断

5. 交付物与模板

  • 交付物：拆分后的合同、分税率发票、月度基准价表、价格变更记录
  • 建议模板/表单：
    • 《SKU 硬件基准价表》多维表格：SKU/型号、渠道采购价、渠道售卖价、采购价依据、生效日期、失效日期、核定人、复核人、修改历史
    • 合同拆分条款：硬件金额（13%）、软件及技术服务金额（6%，词元归软件）、合同总价
    • 月度校准飞书任务模板：负责人、截止日、附件、确认人

6. 异常与升级

  • 当月基准价未按时确定 → 沿用上月价格并标注 → 超 3 个工作日升级综合部负责人
  • 销售对拆分口径理解偏差（如把额外充值算作 6%） → 财务 1 个工作日内书面答复并补 FAQ
  • 节假日或规则切换期发票按哪套规则开 → 以合同签署日期判定，财务负责人当日确认
  • 定制款无标准基准价 → 销售提交非标定价审批，综合部负责人拍板
  • 发现已开发票拆分错误 → 走 FIN-19 红冲重开
  • 升级条件：当月基准价超 3 个工作日未确定、定制款非标定价或定价争议时，由综合部负责人拍板（A（升级））；其余拆分规则与开票由财务负责人决定

7. 衡量指标

  • 基准价按时校准率 = 按时完成校准的月份 / 总月份，目标 100%
  • 合同拆分差错数：法务审核或开票时发现的拆分错误，目标 0
  • 拆分相关返工次数：合同金额调整次数，按月统计目标下降
  • 软硬一体合同分税率开票覆盖率：目标 100%

8. 低效诊断

  • 现象：规则下发后才发现标准化产品如何拆分无人定，基准价缺失导致合同模板"价格还没定下来"｜依据：「leapcore 合同审核群」2026-10
  • 现象：销售把"基准价"与"额外充值算 6%"混淆，税率口径需多次解释｜依据：「渠道系统优化」2026-09、「leapcore 合同审核群」2026-09
  • 现象：月度校准待办需"配置给 IT 推送"但尚未落实；节假日期间发票是否分级开需临时确认｜依据：「渠道系统优化」2026-09、「渠道系统优化」2026-10
  • 现象：SKU 两套价格改名后需财务与管理员逐一人工核对｜依据：「渠道系统优化」2026-10

9. 分支变体

  • 渠道提货（模态→渠道）用渠道采购价；终端出货（渠道→客户）用渠道售卖价
  • 标准机型：按基准价自动拆分；定制款：一事一议
  • 词元开口合同：全部按软件 6%
  • 拆分时点：合同起草阶段拆分（主流程）；历史未拆分合同开票按签署时规则

10. 待确认问题

  • 每月固定校准日定在哪天？实施起始日是否确为 10-08？
  • 基准价由 IT 提出、商务核价、财务复核的分工是否成立？
  • 渠道系统是否已在合同生成时自动拆分？
  • 定制款审批人是谁？
  • 规则是否已形成成文制度并同步全体销售？
FIN-21收入合同台账、回款跟进与收入确认待优化240

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：合同签订、交付验收、开票、回款各节点发生时登记收入合同台账，跟进回款，核对公户进款并按月确认收入，处理"已交付/已回款但无合同"业务
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——销售负责人（当前：李鹏为·推断待确认）、销售支持·台账（当前：韩诗琪·推断待确认）、销售对接人（当前：闫登辉、吴琪、杜中瑞·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 合同签订登记台账 → ② 交付与验收单回传 → ③ 开票登记 → ④ 回款跟进与催款 → ⑤ 公户进款认领核对 → ⑥ 月末收入确认 → ⑦ 无合同业务清单处理
  • 交付结果：字段完整的收入合同台账；每月收入确认清单与应收账龄表；无合同业务处理结论
  • 状态依据：财务已制作"收入合同台账_V1"并向业务讲解填写，但与业务自建台账并存；10 月集中梳理时发现多笔已交付/已回款无合同业务，收入确认需反复向销售追问，回款与交付、使用量无联动

1. 场景判定

  • 触发条件：合同签署；硬件签收单/验收单回传；开票完成；约定回款日到期；公户出现进款；月末结账
  • 典型说法：「ERP 上线前要先用这个表格来跟踪业务和财务」「第一笔款已经到账了」「尚无合同，但已发生交付、回款或开票的业务」「这三笔对应的销售找财务确认收入」
  • 判断问题：这笔业务是否有合同和验收依据？款项属于哪份合同？是否为试用或特批？
  • 不归本流程管：开票申请本身 → 请走 FIN-19；充值到账开通额度 → 请走 FIN-17；境外收款结汇 → 请走 FIN-22；支付渠道对账 → 请走 FIN-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账与确收 设计台账字段、审核合同财务条款、认款、月末确认收入 A/R 财务负责人（当前：黄梦婷·推断待确认）
销售复核 复核合同条款、界定试用/特批、督促补合同 A（升级） 销售负责人（当前：李鹏为·推断待确认）
市场口台账 维护市场/销售口台账字段与进度 R 销售支持·台账（当前：韩诗琪·推断待确认）
回款跟进 填写台账、催款、确认进款来源 R 销售对接人（当前：闫登辉、吴琪、杜中瑞·推断待确认）
渠道/运营对账 渠道平台收入对账 R 生态组负责人（当前：陈梦琪·推断待确认）
其他板块台账 维护非市场口项目进度 R IT 运维（当前：杨明学·推断待确认）
兜底 规则拍板、跨部门争议 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 合同编号与扫描件、合同类型（项目款/充值型/渠道/试用/特批）
  • 硬件签收单、验收单
  • 发票号与开票日期
  • 回款计划（期数、日期、金额条款）
  • 收款渠道登记表（渠道、收款主体、结算周期、后台管理员）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合同签署后在台账新增记录，填写合同、回款计划字段 销售对接人 签署后 2 个工作日内 收入合同台账（多维表格） 台账记录 🔧飞书固化
2 财务审核合同财务条款（预付比例、发票条款、验收机制、费用边界） 财务负责人 合同审批中 2 个工作日内 合同审批 审核意见 👤人工判断
3 交付后上传签收单/验收单，更新履约字段 销售对接人 交付后 3 个工作日内 台账 履约依据 🔧飞书固化
4 回款到期前 5 个工作日机器人提醒销售；逾期每周提醒并抄送销售负责人 系统；销售对接人跟进 到期前 5 个工作日起 飞书机器人 催款记录 🤖自动化
5 公户进款后财务发起认领，销售认领对应合同；来源不明的按收款渠道登记表查询 财务负责人、销售对接人 到账后 3 个工作日内 网银、业财对接群 认款结果 🔧+👤
6 月末自动生成"无合同已交付/已回款/已开票"清单与"待确认是否试用"清单 系统；财务复核 每月最后 3 个工作日 多维表格 两张清单 🤖自动化
7 销售逐条回复：是否试用、是否特批、合同推进状态 销售对接人；销售负责人复核 清单发出后 2 个工作日内 业财对接群 核实结论 👤人工判断
8 财务据合同、验收、回款确认当月收入；特批无合同的不确认，限期补签 财务负责人 次月 5 个工作日内 台账、财务系统 收入确认清单 👤人工判断
9 渠道平台、运营类收入与对方对账 生态组负责人、财务负责人 每月 10 日前 对账单 对账结论 🔧飞书固化

5. 交付物与模板

  • 交付物：收入合同台账、月度收入确认清单、应收账龄表、无合同业务清单及处理结论
  • 建议模板/表单：
    • 《收入合同台账》字段：合同编号、客户、合同类型、签约主体、合同金额、签署日期、交付日期、验收单（附件）、开票日期/发票号、回款计划、已回款、未回款、确收月份、成本、负责销售、状态
    • 《收款渠道登记表》：渠道、收款主体、结算周期、到账账户、后台管理员
    • 《无合同业务核实表》：客户、交付/回款/开票事实、是否试用、是否特批、补签责任人、补签截止日

6. 异常与升级

  • 已交付或已回款但无合同 → 销售 10 个工作日内补签；逾期升级销售负责人，财务暂不确认收入
  • 是否属于试用无法界定 → 销售负责人 2 个工作日内书面确认（含赠机条款的不属于试用）
  • 回款逾期 30 天 → 销售负责人介入；逾期 60 天 → 升级 CEO
  • 公户来源不明进款 → 财务按收款渠道登记表查询，3 个工作日查不清在业财对接群公开认领
  • 充值金额与合同金额不一致 → 销售说明并更新台账
  • 升级条件：业务是否属于试用/特批无法界定、无合同业务逾期未补签或回款逾期 30 天时，由销售负责人确认（A（升级））；台账规则或跨部门争议由综合部负责人拍板（A（升级））；回款逾期 60 天报 CEO

7. 衡量指标

  • 台账完整率 = 必填字段齐全的合同数 / 已签合同数，目标 100%
  • 无合同已交付业务数：月末统计，目标 0
  • 回款及时率 = 按期回款金额 / 应回款金额，目标 ≥ 90%
  • 收入确认时效：次月第 5 个工作日前完成，目标 100%
  • 认款及时率：到账 3 个工作日内认领比例，目标 ≥ 95%

8. 低效诊断

  • 现象：财务台账与业务自建台账两套并存，字段需反复商量｜依据：「全力突击经营管理平台」2026-07、「全力突击经营管理平台」2026-08
  • 现象：收入确认后置，回款信息不对称，合同履约依据分散；渠道平台收入"得有人去对"｜依据：「财务部」2026-06、「财务部」2026-08
  • 现象：先交付后补合同，同一客户是否属于试用需销售逐条界定，财务反复追问｜依据：「业财一体对接」2026-10
  • 现象：催款靠群里提醒；充值与合同金额不对应；回款与交付、使用量无联动看板｜依据：「【模态】市场销售」2026-05、「【模态】市场销售」2026-07、「【模态】市场销售」2026-08

9. 分支变体

  • 项目款：多期回款，按验收节点确认收入
  • 充值型：首充+续充，销售引导客户预充，部署后跟进续充
  • 渠道预充：原则上由渠道自行充值
  • 繁星计划试用：合同金额为 0，交付不计收入
  • 尾款：不做验收的尾款优先一次性收完
  • 特批合同后补：限期补签
  • 收款渠道：C 端产品经支付机构结算至对公户（多个主体商户）；美元收款走 FIN-22；对公转账

10. 待确认问题

  • ERP 上线前台账以财务版为准还是业务版？是否迁移为多维表格？
  • 无合同业务补签时限 10 个工作日是否可行？
  • 回款逾期升级阈值（30/60 天）是否合适？
  • 收入确认月度节点（次月第 5 个工作日）是否可行？
  • 收款渠道登记表由谁建立维护？软著、检测报告等资质材料由谁统一保管？
FIN-22境外客户收款、形式发票与结汇待优化200

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：海外客户按合同以外币付款时，开具形式发票（Proforma Invoice），到账后向银行补材料审核、结汇入账并存档
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——业务对接人（当前：丁震宇·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 业务提出收款需求并提供交易信息 → ② 签署对方盖章的英文合同 → ③ 开具形式发票并盖章 → ④ 发送客户并按对方时区跟进 → ⑤ 网银汇入汇款确认上传材料 → ⑥ 大额加强审核补材料 → ⑦ 结汇入账 → ⑧ 存档与台账
  • 交付结果：结汇完成的人民币入账；合同、形式发票、银行审核材料、结汇凭证完整存档；境外回款台账
  • 状态依据：已有"海外收付款情况"操作说明与形式发票样例，但 4～8 月仍出现形式发票日期与汇款附言不一致重开、对方抬头变更、大额加审补材料、扫描件不清重扫等返工，缺境外回款台账

1. 场景判定

  • 触发条件：海外客户要求开 invoice；网银提示有外币汇入；银行来电要求补充材料；需替换旧回款合同
  • 典型说法：「对面需要我们开一个 invoice」「美元收款现在需要对方盖章的合同才行」「银行说金额大于 5 万美元需加强审核」「这个太糊了，存档啥都看不清」
  • 判断问题：付款方是否为境外主体、以外币付款？是否已有对方签章的英文合同？
  • 不归本流程管：境内客户回款与收入确认 → 请走 FIN-21；向境外供应商付款 → 请走 FIN-04（超等值 5 万美元需税务备案表）；境内开票 → 请走 FIN-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
收款与结汇 核对材料、网银经办、结汇入账、存档 A/R 财务负责人（当前：黄梦婷·推断待确认）
网银复核 汇入汇款确认复核 R 财务复核人（当前：待指定）
业务对接 提供交易信息、对接对方财务、补充情况说明与验收单 R 业务对接人（当前：丁震宇·推断待确认）
合同审核 英文合同条款、主体名称变更说明 C 法务负责人（当前：李瑶·推断待确认）
兜底 存档规范、跨部门协调 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 买方信息：公司全称、地址、联系人（名称变更需提供说明）
  • 交易信息：产品/授权内容、版本、数量、单价、币种、付款条件、授权期限、交付方式
  • 对方签章的英文合同清晰扫描件（原件需邮寄时同步跟进）
  • 汇款参考号/附言约定
  • 已发货的实物：运输单据、报关单
  • 大额：情况说明、交付验收单（对方签章）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 业务提交境外收款申请，附交易信息与合同 业务对接人 对方付款前 5 个工作日 飞书审批 收款申请 🔧飞书固化
2 财务核对合同签章、抬头与付款方一致 财务负责人 2 个工作日内 飞书审批 核对结论 👤人工判断
3 按模板开具形式发票（编号 MTYQ-xxxx），日期、金额、汇款参考号与合同一致，盖章 业务对接人起草，财务复核 1 个工作日内 形式发票生成网页 盖章形式发票 🤖+👤
4 发送客户，按对方时区跟进付款进度 业务对接人 每周至少跟进 1 次 邮件 付款进度记录 👤人工判断
5 到账后经办人在网银"国际业务 > 汇入汇款确认"上传合同、形式发票（已发货加运输单据、报关单），复核人审核 财务负责人、财务复核人 到账提示后 1 个工作日内 企业网银 汇入确认 👤人工判断
6 大额加强审核：业务补情况说明、对方签章验收单；名称变更补说明 业务对接人 银行要求后 2 个工作日内 邮件、网银 补充材料 👤人工判断
7 在线结汇：服务款选计算机服务交易编码，货款选一般贸易 财务负责人 审核通过后 1 个工作日内 企业网银 结汇凭证 👤人工判断
8 全套材料归档，更新境外回款台账 财务负责人 结汇后 2 个工作日内 多维表格、档案库 存档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：英文合同、盖章形式发票、银行审核材料、结汇凭证、境外回款台账记录
  • 建议模板/表单：
    • 形式发票模板字段：发票号/日期、卖方信息、买方信息、交易条款（贸易术语、付款条件、交付方式、授权期限、币种）、产品明细（序号/描述/版本/数量/单价/合计）、备注（付款确认、含维保、电子交付视为完成、增值税率、汇款参考号）、签字盖章
    • 境外收款材料包：合同 + 形式发票 + 情况说明 + 验收单
    • 《境外回款台账》：合同编号、客户、币种、金额、形式发票号、到账日期、银行审核状态、结汇日期、存档位置

6. 异常与升级

  • 形式发票日期与汇款附言不一致 → 重开形式发票并说明 → 财务 1 个工作日内处理
  • 对方抬头变更 → 业务补名称变更说明，法务确认 → 2 个工作日内
  • 银行要求加强审核 → 业务 2 个工作日内补齐材料；超 5 个工作日未通过升级综合部负责人
  • 扫描件不清晰 → 退回重扫，必要时邮寄原件
  • 款项滞留银行超过 10 个工作日 → 升级综合部负责人与 CEO
  • 升级条件：银行加审超 5 个工作日未通过、款项滞留或存档规范需跨部门协调时，由综合部负责人拍板（A（升级））；其余收款与结汇由财务负责人决定

7. 衡量指标

  • 到账→结汇周期：外币到账提示到结汇完成的工作日，目标 ≤ 5 个工作日（不含银行加审）
  • 形式发票重开率：目标 0
  • 材料一次通过率 = 无需补材料的笔数 / 总笔数，目标 ≥ 80%
  • 存档完整率：目标 100%

8. 低效诊断

  • 现象：形式发票日期与汇款附言不一致需重开，对方抬头变更需补说明｜依据：「财务部」2026-04、「财务部」2026-08
  • 现象：银行规则变化（需对方盖章合同、大额加审）事先未知，到账后才补材料｜依据：「财务部」2026-08
  • 现象：存档人缺交易背景，需另找财务对上下文；扫描件模糊需重扫｜依据：「董事会专项沟通群」2026-08
  • 现象：合同和发票由业务自行发出，没有境外回款台账｜依据：「董事会专项沟通群」2026-08

9. 分支变体

  • 未发货（软件授权、服务）：合同 + 形式发票
  • 已发货（实物）：另需运输单据与报关单，结汇选一般贸易
  • 大额（超等值 5 万美元）：银行加强审核，提前准备情况说明与验收单
  • 对方名称变更、替换旧回款合同：补变更说明并重签

10. 待确认问题

  • 境外收款的业务对接人是否固定为某岗位？
  • 网银复核人由谁担任？
  • 形式发票由业务起草、财务复核的分工是否合适？
  • 现有"海外收付款情况"文档是否需要按最新银行要求更新？
  • 境外回款台账是否并入收入合同台账？
FIN-23渠道/开发者分成结算、分润打款与开票待新建225

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：产品收款需按约定分给开发者、渠道、合作方，商城需向厂商或渠道平台结算，或用户支付后需退款冲正时
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——支付/分账研发（当前：陈锦杰·推断待确认）、LeapCore 产品负责人（当前：杨萌·推断待确认）、字字可研产品经理（当前：黄飞鹏·推断待确认）、商城对接研发（当前：葛家和·推断待确认）、COO（税务口径，当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 结算规则书面确认 → ② 系统计算待分成金额 → ③ 财务核对 → ④ 分账或批量打款 → ⑤ 开票/收票 → ⑥ 对账 → ⑦ 退款与冲正
  • 交付结果：按书面规则完成的分账/打款记录、对应发票、月度结算对账单；退款审批与冲正记录
  • 状态依据：分账方案、渠道结算公式、退款做法均只在群聊口头确定；比例按成本还是毛利算有分歧、分账因比例上限失败；退款靠研发私下联系合作方要回；曾出现以个人渠道回补成本的安排，缺财务制度化流程

1. 场景判定

  • 触发条件：开发者/Skill Store 订单产生分账；渠道合作方要求按周期结算分润；商城对厂商、渠道平台结算；用户申请退款或测试付款需退回
  • 典型说法：「支付机构的分润方式不支持我们的商业模式」「之前那个包走的多少税的票」「如果额度比较大，我可以帮忙再要回来」「退款流程是怎么走的」
  • 判断问题：是否存在书面结算规则（合同或规则文档）？资金流向的接收方是否为已签约的主体？
  • 不归本流程管：客户充值到账与额度 → 请走 FIN-17；支付渠道每日对账差异 → 请走 FIN-24；员工个人垫付公司成本 → 请走 FIN-05 / FIN-06，不得通过产品收款分账回补个人

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
结算与打款 核对待分成金额、审批打款、收发票、对账 A/R 财务负责人（当前：黄梦婷·推断待确认）
分账系统 分账规则配置、分账执行、订单与分账数据导出 R 支付/分账研发（当前：陈锦杰·推断待确认）
产品口径 产品零售价、渠道抽成规则提出 R LeapCore 产品负责人（当前：杨萌·推断待确认）
结算公式 渠道供货价计算口径说明 C 字字可研产品经理（当前：黄飞鹏·推断待确认）
商城对接 对接渠道平台退款、冲正、券发放 R 商城对接研发（当前：葛家和·推断待确认）
税务口径 开票税率、分账合规判断 C COO（当前：常元和·推断待确认）
退款申请人 提交退款申请 R 客服或产品对接人
兜底 分账方案、比例与接收人拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已签署的分成/渠道合同或结算规则文档（比例、计算基数、结算周期、税率、开票方向）
  • 分账接收方主体信息与进件状态、收款账户
  • 订单明细：订单号、实收金额、可分账金额（未确认金额）
  • 历史开票税率记录
  • 退款：订单号、原因、支付渠道、金额

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 结算规则书面化（比例按毛利还是成本、计算公式、周期、税率），变更需审批 产品负责人起草，财务负责人、COO 会签 合作上线前 飞书审批、规则文档 结算规则 🔧飞书固化
2 分账规则配置进系统；分账前先查询订单可分账金额再调用分账 支付/分账研发 规则审批后 3 个工作日内 支付分账系统 分账配置 🤖自动化
3 按周期生成待分成清单（订单、金额、接收方、账户） 系统 每月 5 日前（或合同约定周期） 渠道系统/支付后台 待分成清单 🤖自动化
4 财务核对清单与到账流水、规则一致 财务负责人 清单生成后 3 个工作日内 渠道系统、网银 核对结论 👤人工判断
5 执行分账或批量打款（渠道分润不走支付机构分账时，由财务批量打款） 财务负责人 核对后 2 个工作日内 网银、支付分账系统 打款回单 🔧+👤
6 收取或开具对应发票，按规则税率核对 财务负责人 打款前后 10 个工作日内 税务系统 发票 👤人工判断
7 生成月度结算对账单发给接收方确认 财务负责人 每月 10 日前 多维表格 对账确认 🔧飞书固化
8 退款：提交退款审批，财务审批后由对应渠道退回，消费券同步冲正 退款申请人→财务负责人→商城对接研发 收到申请后 3 个工作日内 飞书审批 退款回单、冲正记录 🔧+👤

5. 交付物与模板

  • 交付物：结算规则文档、待分成清单、分账/打款回单、发票、月度结算对账单、退款审批单
  • 建议模板/表单：
    • 《结算规则》字段：合作方、产品、计算公式（如供货价 = 零售价 ×（1 − 税点 − 渠道抽成））、比例基数、结算周期、开票方向与税率、生效日期、审批人
    • 《退款申请》飞书审批：订单号、支付渠道、金额、原因、是否卡密类、是否需券冲正、经办人
    • 《分成结算台账》：周期、接收方、订单数、应分金额、实分金额、打款日期、发票号、确认状态

6. 异常与升级

  • 分账失败（超出支付机构比例上限、接收方未进件） → 研发 1 个工作日内排查，必要时改为批量打款 → 升级财务负责人
  • 比例口径争议（成本/毛利） → 暂停结算，创始人兼 CTO 与 COO 3 个工作日内拍板
  • 合作方提出变更结算公式 → 走规则变更审批，未审批不执行
  • 测试付款真实扣款落入合作方账户 → 提退款申请，由商城对接研发向对方申请退回，财务跟进到账
  • 卡密类商品申请退款 → 原则不退，特例由合作方客服处理，财务登记
  • 拟通过分账向个人账户回补成本 → 禁止，转 FIN-05 / FIN-06
  • 升级条件：分账方案、比例口径或接收人需新定或变更时，由创始人兼 CTO 拍板（A（升级））；其余结算、打款与对账由财务负责人决定

7. 衡量指标

  • 结算按时率 = 按期完成结算的合作方数 / 应结算合作方数，目标 100%
  • 分账失败笔数：目标 0
  • 无书面规则的结算笔数：目标 0
  • 退款处理周期：申请到退回的工作日，目标 ≤ 5 个工作日

8. 低效诊断

  • 现象：谁处理退款、谁冲正、谁发券不清；订单页显示"已退款"却无退款入口；退回靠研发私下联系对方｜依据：「开源聚变入驻问题沟通群」2026-02、「开源聚变入驻问题沟通群」2026-03
  • 现象：历史开票税率靠回忆，渠道结算口径变更只在群里讨论，无合同或规则文档｜依据：「字字可研项目群」2026-09
  • 现象：分账比例按成本还是毛利算未定，分账因比例上限失败，个人垫付资金口头安排｜依据：「LeapPay」2026-05、「LeapPay」2026-08

9. 分支变体

  • 开发者分账（Skill Store）：先收至分账商户再归集主商户，由余额支付分给开发者，不走延迟支付
  • 渠道分润：不走支付机构分账，财务周期性从渠道系统拉取待分润金额与账户批量打款
  • 渠道平台结算（政府平台类商城）：对厂商 T+1 结账；消费券由平台发放、一券一用户
  • 卡密类商品：不退款
  • 公司成本垫付回补：走 FIN-05 / FIN-06，不纳入分账

10. 待确认问题

  • 分成结算主责是否为财务负责人？规则拍板人是 CTO 还是 CEO？
  • 结算周期是否统一为月结？
  • 现有合作方是否都已签署书面结算规则？
  • 已发生的个人垫付回补安排是否需要补走 FIN-05 / FIN-06？
  • 退款审批的金额分级和审批人？
FIN-24支付渠道每日对账、手续费与差异处理待优化200

状态：待优化｜证据：有证据（卡片 7 张 / 会话 4 个）｜优先级：频5 × 耗2 × 跨4 × 险5

  • 适用场景：每日支付、分账、提现、退款发生后核对系统与支付平台、公户到账；处理对账差异与失败重跑；每月核对收单与公户到账、申请手续费发票
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——跃竞后端负责人·对账开发（当前：王子明·推断待确认）、LeapPay 支付研发（当前：陈锦杰·推断待确认）、跃竞负责人·支付商户管理（当前：徐莉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 每日 20:00 机器人推送对账结果 → ② 判定账实平/差异/失败 → ③ 失败重跑 → ④ 差异分类与修复 → ⑤ 财务确认关闭 → ⑥ 月度收单与公户到账核对 → ⑦ 手续费发票申请与入账
  • 交付结果：每日对账结论均有回执；差异清单逐条关闭；月度支付结算对账表；手续费发票按月取得
  • 状态依据：支付对账机器人每日 20:00 稳定推送（8～10 月约 57 次账实平），但差异由开发自行判断、失败需开发手动重跑，财务未在群内确认；月度对账每次现拉数据，手续费导致发票与流水不一致的口径分散在聊天中

1. 场景判定

  • 触发条件：机器人推送"有差异"或"对账失败/对账单未就绪"；月末结账；客户付款与公户到账金额对不上；每月 12 日后可申请上月手续费发票
  • 典型说法：「支付机构每日对账（账实平）」「对账单尚未就绪，请稍后重跑」「我们收的钱和客户给的钱对不上」「开了 1000 的票，实际只有 999 的银行流水」
  • 判断问题：差异是真实账务差异，还是对比口径（手续费、笔数）问题？涉及哪个产品、哪个商户？
  • 不归本流程管：客户充值到账开通额度 → 请走 FIN-17；渠道/开发者分成结算 → 请走 FIN-23；客户充值开票 → 请走 FIN-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
对账确认 确认日报回执、差异定性、账务调整、月度核对、手续费发票 A/R 财务负责人（当前：黄梦婷·推断待确认）
对账开发 对账任务维护、失败排障重跑、差异技术排查（跃竞线） R 跃竞后端负责人·对账开发（当前：王子明·推断待确认）
LeapPay 数据 各产品账单导出、分账与结算配置（Leap 线） R LeapPay 支付研发（当前：陈锦杰·推断待确认）
商户管理 支付商户后台管理、向支付机构咨询、手续费发票申请协助 C 跃竞负责人·支付商户管理（当前：徐莉·推断待确认）
兜底 规则拍板、长期差异升级 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 当日对账卡片与差异明细 CSV（COS 归档位置）
  • 支付机构结算对账单、消费者支付明细流水（统一订单号口径）
  • 公户银行流水
  • 商户与产品映射表（哪个商户收哪个产品的款、结算方式、附言）
  • 手续费规则：外扣方式、网银单笔手续费、开票入口

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 机器人对前一日账期执行对账，推送交易笔数、净流水、分账组、出金匹配及手续费口径差 系统 每日 20:00 对账机器人、告警群 对账卡片 🤖自动化
2 账实平：财务在卡片点"已确认"回执 财务负责人 次日 12:00 前 飞书卡片 确认回执 🔧飞书固化
3 失败（对账单未就绪、查询超时、出金账单查询失败）：系统于 D+1 12:00 后自动重试；仍失败由开发排障手动重跑 系统；对账开发 次日 15:00 前 对账任务 重跑结果 🤖自动化
4 有差异：系统建差异待办，开发判断是口径问题还是真实账差，AI 先对差异明细归类（手续费口径/漏单/重复） 对账开发 次日 18:00 前 多维表格、差异 CSV 差异定性 🤖+👤
5 口径问题由开发修正对账逻辑；真实差异由财务认定原因，需补偿或调账的走审批 对账开发、财务负责人 定性后 3 个工作日内 飞书审批 修复/调账记录 👤人工判断
6 差异关闭：财务在待办中确认关闭 财务负责人 修复后 1 个工作日内 多维表格 已关闭差异 🔧飞书固化
7 月度核对：导出各产品账单与支付机构结算单，与公户实际到账核对，按产品区分收入 LeapPay 支付研发导出，财务核对 次月 5 个工作日内 支付后台、网银 月度结算对账表 🤖+👤
8 申请上月手续费发票（每月 12 日后，商户控台"发票管理"或商户发票助手小程序），约 2 周到票后入账 财务负责人（商户管理协助） 每月 12～15 日 支付商户后台 手续费发票 🔧+👤

5. 交付物与模板

  • 交付物：每日对账回执、差异处理记录、月度支付结算对账表、手续费发票
  • 建议模板/表单：
    • 《对账差异台账》多维表格：账期、产品/商户、差异类型（口径/漏单/重复/手续费/未清分）、笔数、金额、定性人、处理方式、调账审批号、关闭人、关闭日期
    • 《商户与产品映射表》：商户号、主体、产品、结算方式（自动/手动）、打款附言、结算周期、后台管理员
    • 《支付手续费与开票规则》：手续费外扣；收入按扣费前金额申报并开全额发票、备注手续费；线下汇款必带合同且只开对应公司发票；线上支付不带合同只开普票，带合同可开专票

6. 异常与升级

  • 对账连续 2 日失败 → 对账开发当日排障，必要时联系支付机构 → 升级综合部负责人
  • 真实差异金额无法解释超过 3 个工作日 → 财务负责人升级综合部负责人
  • 支付机构对账单频繁不稳定 → 评估替换支付渠道，由跃竞负责人与 CTO 决策
  • 多产品共用商户、打款附言混在一起 → 拆分独立商户或配置附言，财务每月手动拆分过渡
  • 延迟分账产品款项堆积在支付机构未清分 → 开发 2 个工作日内排查分账任务
  • 客户付款与发票金额因手续费不一致 → 按手续费规则开全额发票并备注
  • 升级条件：对账连续 2 日失败、真实差异超 3 个工作日无法解释或对账规则需调整时，由综合部负责人拍板（A（升级））；其余差异定性与关闭由财务负责人决定

7. 衡量指标

  • 日报确认及时率 = 次日 12:00 前确认的日报数 / 总日报数，目标 ≥ 95%
  • 差异关闭时长：发现到关闭的工作日，目标 ≤ 3 个工作日
  • 对账失败率 = 失败天数 / 总天数，目标 ≤ 3%
  • 月度对账完成时效：次月第 5 个工作日前，目标 100%
  • 手续费发票按月取得率：目标 100%

8. 低效诊断

  • 现象：历史分账异常导致系统余额与支付平台不一致，开发多轮人工修复补偿；月末对账失败、手续费口径多次修正｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-06、「跃玩项目组」2026-07
  • 现象：日报笔数不一致却标"账实平"，口径事后才改；对账单 D+1 中午才生成，20:00 前仍可能未就绪；失败需开发手动重跑｜依据：「告警通知群」2026-06、「告警通知群」2026-07、「告警通知群」2026-08
  • 现象：差异只有开发看，财务未在群内确认和关闭｜依据：「告警通知群」2026-08、「告警通知群」2026-10
  • 现象：财务不了解商户结算方式需开发解释，每次对账现拉数据，延迟分账款堆积未清分｜依据：「LeapPay」2026-06、「LeapPay」2026-07
  • 现象：手续费内扣/外扣、流水与发票对不上讨论近 40 条，规则分散在聊天｜依据：「LeapPay」2026-07、「LeapPay」2026-08、「LeapPay」2026-09
  • 现象：多产品共用商户导致打款附言混在一起，财务无法区分｜依据：「LeapPay」2026-10

9. 分支变体

  • 跃竞（跃玩）线：交易、分账对账已自动化，提现对账待实现
  • Leap 线（LeapPay）：即时入账产品（字字可研、LeapAll、LeapOne）与延迟分账产品（LeapPPT，T+1）分开核对
  • 有出金日/无出金日：卡片注明
  • 多主体商户：武汉、苏州、鼎慧主体商户分别对账；LeapAll 与 LeapCore 需区分附言或独立商户

10. 待确认问题

  • 每日对账回执由财务确认是否可行？还是只确认差异与失败？
  • 跃竞线与 Leap 线对账是否由同一财务岗位负责？
  • 提现对账何时补齐？
  • 手续费规则是否已形成成文制度？
  • 是否新建独立商户区分 LeapAll 与 LeapCore 收款？
FIN-25资金/分账异常排查与数据修复待新建500

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频4 × 耗5 × 跨5 × 险5

  • 适用场景：支付回调异常、分账延迟或待结算队列积压、钱包/俱乐部账与支付平台余额不一致、资金任务告警触发时，启动排查、资金修复、客户告知与复盘
  • 负责人：主责——跃竞后端负责人（当前：王子明·推断待确认）；协同——跃竞后端研发（当前：张楠、蒋兴武·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、商户运营（当前：宫经喜·推断待确认）、财务专员（当前：刘梦可·推断待确认）、V5 后端研发（当前：陈锦杰·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 发现与登记 → ② 止损与定级 → ③ 根因排查 → ④ 资金影响清单 → ⑤ 修复方案审批 → ⑥ 执行修复/手动分账 → ⑦ 财务复核与客户告知 → ⑧ 复盘与监控补齐
  • 交付结果：已闭环的资金异常工单（含影响清单、修复记录、财务复核结论）、对受影响商户/俱乐部的书面告知、复盘结论与新增监控项
  • 状态依据：已有支付平台每日对账机器人、对账定时任务和 V5 资金告警通道，但只比对账实、不监控结算时效；2026-03～10 多次由商户上门或业务追问才发现问题（队列积压近 6 个月无人发现），修复后靠口头同步，财务未参与确认

1. 场景判定

  • 触发条件：分账批次失败/变慢告警；待结算队列持续增长；商户/俱乐部反馈「几天没进账」「钱包金额不对」；退款失败或重复；支付回调异常；余额对账/预占回收/实时转写对账告警；商户更换主商户或结算账户后分账失败
  • 典型说法：「商户三天没有进账」「分账延迟有点久」「陪玩钱包资金不对等」「我们的钱落在了延迟户」「俱乐部换账户，自动分账会出问题」
  • 判断问题：是否涉及真实资金的金额、到账时间或归属与预期不一致？若只是页面展示错误且资金流水正确，按普通缺陷处理
  • 不归本流程管：客户对计费扣费金额有异议 → 请走 FIN-29；模型成本价/倍率配置 → 请走 FIN-28；网关月度账单导出 → 请走 FIN-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事件负责人 定级、组织排查、审定修复方案、对结果负责 A 跃竞后端负责人（当前：王子明·推断待确认）
首个发现人 告警或反馈进入后登记异常工单 R 告警值班人/商户运营/研发（当前：按发现人）
排查与修复 查日志/对账脚本、出影响清单、执行修复或手动分账 R 跃竞后端研发（当前：张楠、蒋兴武·推断待确认）
测试验证 在测试环境验证修复脚本与补偿逻辑 R 测试负责人（当前：赵伟龙·推断待确认）
业务统筹 判断客户影响优先级、批准修复执行、对外口径、兜底决策 A（升级） 跃竞负责人（当前：徐莉·推断待确认）
商户沟通 通知受影响商户/俱乐部、收集反馈 R 商户运营（当前：宫经喜·推断待确认）
财务复核 核对修复金额与平台流水、调账确认、入账 R 财务专员（当前：刘梦可·推断待确认）
V5 资金告警处理 处理 V5 Cloud 余额对账、预占回收告警 R V5 后端研发（当前：陈锦杰·推断待确认）
V5 负责人 V5 资金告警升级对象 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 告警截图或商户反馈原文（商户/俱乐部标识、反馈时间、涉及订单号）
  • 支付平台后台查询权限（只读）与对账任务最近一次运行结果
  • 待结算队列长度、最老一笔记录时间、最近批次完成时间
  • 资金口径定义：实际结算额、实际到手额、俱乐部收益、邀请佣金与手续费的计算公式
  • 最近一次涉及支付/分账的发版记录、商户换户记录
  • 请求最少包含字段：来源（告警/商户/自查）、主体/产品线、商户或俱乐部标识、涉及订单号或批次号、异常类型、首次发现时间、涉及金额区间与商户数、截图或告警原文；缺项由首个发现人在登记时补齐

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 告警或反馈进入后在资金异常表登记，@事件负责人 首个发现人 发现后 30 分钟内 告警通知群、多维表格 资金异常工单（多维表格，@事件负责人；1 小时未定级→跃竞负责人） 🔧+🤖 告警自动建单
2 定级：影响金额/商户数/是否持续扩大；P0 立即暂停相关自动分账或提现 跃竞后端负责人 登记后 1 小时内 工单 等级与止损动作（回写工单；P0 同步跃竞负责人与财务） 👤人工判断
3 根因排查：回调日志、对账任务、队列限速、换户影响 跃竞后端研发 P0 当日；其他 1 个工作日内 支付平台后台、数据库、AI 查询工具 根因说明（工单评论） 🤖自动化
4 输出影响清单：按商户/俱乐部列出差额、订单数、应到未到金额 跃竞后端研发 根因确认后 1 个工作日内 对账脚本、Excel 影响清单（附件挂工单，抄送财务专员） 🤖自动化
5 修复方案（重放分账/修正流水/手动分账/退款补偿）在测试环境验证 跃竞后端研发、测试负责人 方案出具后 1 个工作日内 测试服 验证记录（测试服截图挂工单） 👤人工判断
6 财务复核影响清单与修复金额，跃竞负责人批准执行 财务专员、跃竞负责人 收到后 4 小时内 飞书审批 修复审批单（飞书审批，编号回写工单；超时→财务负责人） 🔧飞书固化
7 执行修复，逐笔记录到修复台账 跃竞后端研发 审批通过当日 生产库、支付平台 修复台账（多维表格，逐笔关联工单） 🔧+👤
8 按影响程度排序告知商户/俱乐部，说明原因、到账时间 商户运营 修复完成后 4 小时内 客户群 书面告知（客户群，告知时间记录到工单） 👤人工判断
9 财务对修复后流水与平台余额再次对账并关单 财务专员 修复后 2 个工作日内 支付平台、对账报表 复核结论（对账报表 + 工单关单） 🔧+🤖
10 复盘：补监控项（队列长度、最老记录时长、批次耗时）、补测试用例 跃竞后端负责人 关单后 5 个工作日内 飞书文档 复盘记录（飞书文档，链接回写工单） 👤人工判断

5. 交付物与模板

  • 交付物：资金异常工单、影响清单、修复审批单、修复台账、商户告知记录、复盘记录
  • 建议模板/表单：资金异常台账（多维表格）字段——编号、发现时间、来源（告警/商户/自查）、主体/产品线、异常类型（回调/分账延迟/余额不平/退款/换户）、影响商户数、影响金额区间、等级、根因、修复方式、财务复核人、告知时间、关单时间、复盘链接
  • 资金口径说明文档：各金额字段定义与公式，变更需财务确认

6. 异常与升级

  • 影响持续扩大或无法 4 小时内定位 → 暂停相关自动分账 → 升级跃竞负责人（立即）
  • 修复需调整平台侧限速或通道权限 → 由后端负责人联系支付平台 → 升级跃竞负责人（1 个工作日内）
  • 修复金额与财务对账不一致 → 停止执行、重算 → 升级财务负责人（当日）
  • 处理人下班/休假 → 由值班后端接手，工单内有完整上下文 → 升级跃竞后端负责人（1 小时内无人接手）
  • 商户投诉升级或涉及纠纷 → 跃竞负责人统一对外口径（当日）
  • 事件负责人登记后 1 小时未定级 → 首个发现人直接升级跃竞负责人（即刻）
  • 财务专员 4 小时未复核 → 事件负责人电话提醒 → 升级财务负责人（当日）
  • 商户运营修复后 4 小时未告知商户 → 事件负责人代发告知并记录工单 → 通报跃竞负责人（当日）
  • 升级条件：修复需调整真实资金（重放分账、手动分账、退款补偿）、影响持续扩大或需对外统一口径时，由跃竞负责人拍板（A（升级））；V5 资金告警 1 个工作日内未闭环时，由 Leap 研发负责人拍板（A（升级））

7. 衡量指标

  • 发现时延 = 异常首次发生到登记的时长，目标：监控覆盖项 ≤ 1 小时
  • 修复周期 = 登记到财务复核关单的自然日，目标 P0 ≤ 2 天、其他 ≤ 5 天
  • 商户主动发现占比 = 由商户反馈触发的工单数 / 总工单数，目标逐季下降至 ≤ 20%
  • 待结算最老记录时长，目标 ≤ 结算周期 + 1 天
  • 修复返工率 = 二次修复工单数 / 修复工单数，目标 ≤ 10%

8. 低效诊断

  • 现象：现有对账只比账实，不监控结算时效，队列积压数月靠商户上门才发现｜依据：「告警通知群」2026-09
  • 现象：资金口径（结算额/到手额/收益/佣金手续费）没有成文定义，导出表公式反复推翻｜依据：「跃玩项目组」2026-06
  • 现象：分账重放脚本口径不对导致金额偏高，深夜临时处理｜依据：「跃玩项目组」2026-03
  • 现象：资金问题研发自查发现后未主动上报，修复完成靠业务追问和口头同步｜依据：「跃玩项目组」2026-08
  • 现象：商户换主户后分账失败需研发每天手动分，处理人休息时无人接手｜依据：「告警通知群」2026-08
  • 现象：V5 资金告警通道已联调，但响应人与处置闭环未定义｜依据：「研发通知」2026-10

9. 分支变体

  • 会费分账未决、退款失败：重点核查退款幂等与补偿任务，修复后需跑一次历史巡检
  • 陪玩钱包/俱乐部账不平：按俱乐部出异常人员清单，修复后才开放提现，按催办紧急度排序告知
  • 待结算队列积压：检查消费端限速参数与跑批耗时，是否提速需与支付平台沟通
  • 商户更换主商户/结算账户：业务侧应提前发起换户申请通知研发与财务，换户期间手动分账逐笔留痕
  • V5 Cloud 余额对账、过期预占回收、实时转写对账告警：由 V5 后端研发处理，写入修正流水前需财务二次确认
  • 协作协议：遵循 ALL-02（消息分级与响应时限）、ALL-03（决策记录与发布）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 主责是否为跃竞后端负责人？财务侧由谁对接跃竞与 V5 的资金复核？
  • 修复执行前财务复核 4 小时内是否可行？小额差异是否可以先修后补审批，阈值多少？
  • 是否已有资金口径成文文档？如无，由谁起草、谁确认？
  • 商户换户是否纳入飞书审批并自动通知研发和财务？
  • 队列积压、批次耗时告警阈值设多少？告警值班如何排班？
  • 本流程实际由跃竞后端主责，却编在财务（FIN）序列下：归属跃竞/研发还是财务，请管理层裁定
FIN-26网关月度账单导出与财务对账待优化108

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：每月初财务需要上月网关账单（token 类与非 token 类计费），或财务提出新的账单字段/导出需求时启动
  • 负责人：主责——网关计费研发（当前：柯逸飞·推断待确认）；协同——财务负责人（当前：黄梦婷·推断待确认）、财务专员（当前：刘梦可·推断待确认）、产品总监（当前：杨萌·推断待确认）、研发工程师（提供单价，当前：魏宗浩·推断待确认）、支付研发（当前：陈锦杰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 月初定时导出 → ② 研发自检 → ③ CTO 审核口径 → ④ 推送财务 → ⑤ 财务对账 → ⑥ 差异提工单 → ⑦ 归档
  • 交付结果：上月网关账单包（按上游、按 Key、按 API 三份 CSV + 字段说明）、财务对账结论、差异工单
  • 状态依据：已有导出功能、README 和 LEAP 工单跟踪，但仍需管理员人工导出、字段含义需当面讲解，2026-09～10 出现催办约 4 次、需求漏记 1 次

1. 场景判定

  • 触发条件：每月 1 日后；财务对账发现差异；财务新增字段或导出方式需求；上游/计费项新增（如 OCR、企查查、视频按秒）
  • 典型说法：「财务那边不止需要钱，还需要数量和单价」「能不能导个九月的」「做好财务需求的工单管理」
  • 判断问题：需要的是网关层面（上游成本/Key/API 调用）的月度汇总吗？若是面向客户的账单，不归本流程
  • 不归本流程管：向客户出具用量账单 → 请走 FIN-27；模型成本价/倍率维护 → 请走 FIN-28；云资源成本归集 → 请走 FIN-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账单导出 导出账单、维护导出功能、自检 R 网关计费研发（当前：柯逸飞·推断待确认）
口径审核 审核字段完整性、格式、口径 A 创始人兼 CTO（当前：丁震宇·推断待确认）
财务对账 核对账单与付款/充值记录，提差异 R 财务负责人（当前：黄梦婷·推断待确认）；财务专员（当前：刘梦可·推断待确认）
需求协调 财务需求转工单、字段取舍 C 产品总监（当前：杨萌·推断待确认）
单价提供 维护非 token 计费项单价/倍率 C 研发工程师（当前：魏宗浩·推断待确认）
支付附言 支付相关字段（附言等） C 支付研发（当前：陈锦杰·推断待确认）
知会 了解发版与工单进展 I Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 账单月份、需覆盖的网关（LeapCore 总路由 / 企业网关 / VPN 网关）
  • 非 token 计费项单价表（OCR、企查查、视频秒数、API 次数），含单位与生效日期
  • 字段词典（金额、数量、单价、赠送/非赠送额度）
  • 上月财务对账遗留差异清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 定时任务导出上月账单三份 CSV（上游/Key/API），非 token 项单列金额+数量+单价 网关计费研发 每月 3 日前 网关后台、定时脚本 账单包 v1 🤖自动化
2 自检：总额与上游充值/扣费日志一致，无“-”或缺单价 网关计费研发 导出后 1 个工作日内 脚本 自检记录 🤖自动化
3 审核字段完整性与格式 创始人兼 CTO 收到后 1 个工作日内 飞书群 审核通过 👤人工判断
4 推送财务（附字段词典链接），首次使用的字段线上讲解一次 网关计费研发 每月 5 日前 飞书云盘、机器人 账单包定稿 🔧飞书固化
5 财务对账：与充值、付款、发票核对 财务专员 收到后 3 个工作日内 财务系统、Excel 对账结论 👤人工判断
6 差异或新需求提 LEAP 工单（财务需求单独标签） 财务专员/产品总监 发现当日 工单系统 工单 🔧飞书固化
7 修复差异并补发更正版 网关计费研发 工单受理后 3 个工作日内 网关后台 账单 v2 👤人工判断
8 账单定稿归档（按月份） 财务专员 对账完成当日 飞书云盘 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：月度账单包（3 份 CSV + README）、对账结论、差异工单
  • 建议模板/表单：字段词典——字段名、含义、单位、来源表、是否含赠送额度、计算公式；非 token 单价表——计费项、单位（次/秒）、单价、倍率、生效日期、维护人

6. 异常与升级

  • 每月 5 日未推送 → 机器人提醒导出人 → 升级 CTO（逾期 2 个工作日）
  • 账单总额与上游账单偏差 > 5% → 暂停定稿，查原因 → 升级 CTO（1 个工作日内）
  • 财务无法自助导出 → 由导出人代导，同时推进网页导出按钮与只读权限 → 升级 CTO（当月）
  • 历史数据未区分赠送/非赠送额度 → 在 README 标注口径差异 → 财务负责人确认处理方式

7. 衡量指标

  • 账单准时率 = 每月 5 日前推送财务的月份数 / 总月份数，目标 100%
  • 对账差异数 = 每月财务提出的差异工单数，目标 ≤ 2
  • 财务需求响应周期 = 工单创建到上线的工作日，目标 ≤ 10 天
  • 催办次数 = 财务/管理层在群内追问账单次数，目标 0

8. 低效诊断

  • 现象：财务口径（只要金额 vs 金额+数量+单价）在开发中途才对齐，统计页另需返工｜依据：「Leap产研测」2026-09
  • 现象：非 token 计费项单价散在个人手里，需在评论区临时补｜依据：「Leap产研测」2026-09
  • 现象：财务需求被漏记、进度需多次催办｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：财务无管理员权限，只能每月人工代导；字段含义需当面讲解｜依据：「AI API」2026-10

9. 分支变体

  • token 类账单：按上游成本、按 Key 两个维度
  • 非 token 类（OCR、企查查、视频按秒、API 按次）：单独导出，单位用次或秒
  • LeapCore 总路由 vs 企业网关 vs VPN 网关：分别导出或在账单中分 sheet
  • 用户侧展示统一称“工具调用费用”，不在客户侧展示单价倍率

10. 待确认问题

  • 主责是否为网关计费研发？是否需要财务侧指定唯一对接人？
  • 每月 3 日导出、5 日推送是否可行？
  • 财务是否开通网关后台只读导出权限（LEAP-1848 导出按钮）？
  • 非 token 单价表由谁维护，是否并入 FIN-28 成本价主表？
  • 财务需求是否单独建项目/标签管理？
FIN-27客户按量计费月度账单核算与发送待优化180

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：按工作量、token 或调用量向客户收费的项目或 API 客户，每个结算周期核算用量、计算折扣、出具账单并发送收款时启动
  • 负责人：主责——客户项目研发对接人（当前：葛家和、李铭熙·推断待确认）；协同——创始人兼 CTO（定价折扣把关，当前：丁震宇·推断待确认）、COO（商务定价口径，当前：常元和·推断待确认）、研发工程师（工时数据，当前：魏宗浩·推断待确认）、财务专员（开票收款，当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 月度提醒 → ② 导出用量/工时 → ③ 按合同口径核算 → ④ 折扣与报价审核 → ⑤ 发送客户 → ⑥ 开票收款 → ⑦ 归档
  • 交付结果：经审核的客户月度账单（用量明细 + 应收金额）、发送记录、开票与收款记录
  • 状态依据：已有飞书提醒机器人与月度账单表，但提醒周期设错（应每月 15 日后，实际每周）、负责人借调后无人接手；API 客户账单靠研发自行想起、价格口径临时问人

1. 场景判定

  • 触发条件：合同约定按量/按人日计费的项目进入结算周期；提醒机器人触发；客户索要账单
  • 典型说法：「算账单了」「是不是该给客户发账单了」「上个月的报价给一下，累计开发了多少人日」
  • 判断问题：该客户是否按实际用量或工作量计费，而非一次性买断？
  • 不归本流程管：内部网关账单给财务 → 请走 FIN-26；客户对扣费有异议 → 请走 FIN-29；一次性合同回款 → 请走 FIN-21（收入合同台账与回款跟进）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
账单核算 导出用量、按口径算应收、出账单 R 客户项目研发对接人（当前：葛家和、李铭熙·推断待确认）
折扣与报价审核 确认折扣、报价口径 A 创始人兼 CTO（当前：丁震宇·推断待确认）
商务口径 成本价是否披露、加价策略 C COO（当前：常元和·推断待确认）
收费决策 计费方式（按人日/按 token）拍板 C CEO（当前：邴龙志·推断待确认）
工时数据 提供开发人日 C 研发工程师（当前：魏宗浩·推断待确认）
开票收款 开票、跟踪回款 R 财务专员（当前：刘梦可·推断待确认）
提醒机器人 按结算日推送账单提醒 I 飞书机器人（由客户项目研发对接人维护）

3. 办之前请准备

  • 合同或报价单中的计费方式、单价、折扣、结算周期
  • 本周期用量导出（按账号分表）或开发人日统计
  • 按量付费客户清单（多维表格）
  • 对外报价口径（不对客户披露上游供应商与真实成本）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 机器人按合同结算日提醒（默认每月 15 日后） 飞书机器人 结算日当天 飞书机器人 提醒 🔧飞书固化
2 导出周期用量（token/调用量，按账号）或汇总人日 客户项目研发对接人 提醒后 2 个工作日内 网关后台、多维表格 用量明细 🤖自动化
3 按合同口径与折扣计算应收，生成账单草稿 客户项目研发对接人 用量导出后 1 个工作日内 账单模板 账单草稿 🤖自动化
4 审核折扣与报价口径，涉及成本价披露问 COO 创始人兼 CTO 收到后 1 个工作日内 飞书审批 审核通过 👤人工判断
5 通过客户群发送给客户对接人，同步财务 客户项目研发对接人 审核通过当日 客户群 发送记录 🔧飞书固化
6 客户确认后开票并跟踪回款 财务专员 客户确认后 3 个工作日内开票 财务系统 发票、收款记录 🔧飞书固化
7 账单、确认记录、收款状态登记到按量付费清单 财务专员 收款当日 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：客户月度账单、发送与确认记录、发票、收款登记
  • 建议模板/表单：按量付费客户台账字段——客户代号、合同编号、计费方式（token/调用/人日）、单价、折扣、结算日、研发对接人、本期用量、应收、审核人、发送日、开票日、收款日、状态

6. 异常与升级

  • 负责人调岗/借调 → 交接时必须在台账更换对接人 → 升级 CTO（调岗当周）
  • 客户要求披露成本价 → 不直接回复 → 升级 COO（1 个工作日内）
  • 开发人日无记录需事后估算 → 标注“估算”并由 CEO 确认 → 下期起按周记录人日
  • 客户超 30 天未确认或未回款 → 财务提醒研发对接人 → 升级销售负责人

7. 衡量指标

  • 账单准时率 = 结算日后 5 个工作日内发出的账单数 / 应发账单数，目标 ≥ 95%
  • 漏发账单数 = 应发未发周期数，目标 0
  • 回款周期 = 账单发送到收款的自然日，目标 ≤ 30 天
  • 账单返工次数 = 客户或审核退回次数，目标每月 ≤ 1

8. 低效诊断

  • 现象：提醒机器人周期设置与实际结算口径不一致（每周 vs 每月 15 日后），长期误报｜依据：「某政府客户需求对接群」2026-02
  • 现象：负责人借调后账单无人接手，只能暂停提醒｜依据：「某政府客户需求对接群」2026-03
  • 现象：开发人日缺少过程记录，结算时事后估算｜依据：「某政府客户需求对接群」2026-01
  • 现象：API 客户账单无系统记录，靠个人记忆触发；对客户报真实成本还是加价无成文口径｜依据：（推断）

9. 分支变体

  • 政府类项目（智搜/爬虫）：按人日计费为主，toG 报价可适当上浮以覆盖损耗
  • 对外 API/生图客户：按调用量导出，按约定折扣计算；成本价口径由 COO 决定，不对客户提及上游供应商
  • 积分体系客户：按基准模型倍率折算积分

10. 待确认问题

  • 主责是否为各客户的研发对接人？是否应由销售或财务统一负责发送账单？
  • 折扣审核是否保留在 CTO，还是转由 COO/销售负责人？
  • 结算日是否统一为每月 15 日？
  • 按量计费合同是否已有台账？谁负责维护？
  • 开票与收款由哪位财务人员对接？
FIN-28模型成本价、计价倍率维护与成本收入核对待优化320

状态：待优化｜证据：有证据（卡片 8 张 / 会话 5 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：新增/调整上游渠道、官方调价、汇率变化、产品定价调整，或怀疑计价与成本不一致时，维护成本价与汇率、确定倍率/毛利/额度包并定期核对成本与收入
  • 负责人：主责——IT 运维/上游渠道维护（当前：杨明学·推断待确认）；协同——创始人兼 CTO（价格谈判与定价拍板，当前：丁震宇·推断待确认）、产品总监（定价档位与毛利，当前：杨萌·推断待确认）、网关计费研发（当前：柯逸飞、邓乾、张康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售骨干（对外报价需求，当前：闫登辉·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 变更触发登记 → ② 更新成本价主表 → ③ 定价/倍率审批 → ④ dry-run 同步网关 → ⑤ 上线核对 → ⑥ 通知相关方 → ⑦ 月度成本收入对账
  • 交付结果：最新成本价主表（模型-渠道-币种-折扣-汇率-生效日期）、售价/倍率配置记录、月度成本收入对账报告
  • 状态依据：已有成本价文档、价格多维表格与自动查价 skill，“谈价格/维护价格”分工已明确；但 2026-05～09 仍多次出现倍率漏调、批量改价致服务异常、汇率口径不一、两张对账表格式不同

1. 场景判定

  • 触发条件：上游渠道新增/切换/调价；海外上游充值（汇率变化）；产品定价档位或毛利调整；生产网关切换；月度成本收入核对；业务需报告成本数据用于报价
  • 典型说法：「AIAPI 就只管成本不管售价」「triple check 一下现在计费有没有问题」「隔一段时间成本得拉出来对账一下」「这个计费是谁管，在哪里操作倍率」
  • 判断问题：本次变化是否会改变某个模型的成本价、售价或倍率？若只是单个客户扣费争议，先走 FIN-29
  • 不归本流程管：客户扣费异议与退补 → 请走 FIN-29；网关账单导出 → 请走 FIN-26；上游充值付款审批 → 请走 FIN-03（账户充值）/ FIN-01（对公采购付款）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
成本价维护 维护成本价主表、汇率、同步网关 R IT 运维/上游渠道维护（当前：杨明学·推断待确认）
价格谈判与定价拍板 上游谈价、汇率策略、倍率方案审批 A 创始人兼 CTO（当前：丁震宇·推断待确认）
产品定价 档位、毛利比例、额度包规则，提交售价/倍率方案 R（售价方案） 产品总监（当前：杨萌·推断待确认）
网关配置 下游 LeapCore/LeapAll 倍率与计费层实现 R 网关计费研发（当前：柯逸飞、邓乾、张康·推断待确认）
核对 上线后计价抽检、差异核查 R 测试负责人（当前：张东郅·推断待确认）
架构与口径 计费分层、汇率版本设计 C Leap 研发负责人（当前：王皓南·推断待确认）、基座组架构（当前：陈晖·推断待确认）
取数 报告成本/扣费统计 R（取数） 后端研发（当前：陈锦杰、宋祺睿·推断待确认）
对外报价 获取最新价格 I 销售骨干（当前：闫登辉·推断待确认）
财务 月度成本收入报表、汇率偏差入账 C 财务专员（当前：刘梦可·推断待确认）

3. 办之前请准备

  • 上游官方价格页/合同折扣、渠道名称（区分测试与生产）
  • 当前成本价主表、LeapCore/LeapAll 价格表版本
  • 充值记录与当日汇率（预充美元渠道）
  • 定价规则：毛利比例、倍率公式、缓存读写价、图片/视频计价单位
  • 回滚方案与 dry-run 结果

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记变更：渠道/模型/原因/生效日期 IT 运维/上游渠道维护 获知变更当日 多维表格 变更记录 🔧飞书固化
2 更新成本价主表（币种、折扣、汇率版本） IT 运维/上游渠道维护 1 个工作日内 多维表格、自动查价 skill 成本价 v+1 🤖自动化
3 按毛利规则计算售价与倍率，提交审批 产品总监 成本更新后 1 个工作日内 飞书审批 定价审批单 🔧+👤
4 dry-run 同步到网关，核对差异清单后正式下发 网关计费研发 审批通过当日 价格同步脚本 下发记录 🤖+👤
5 上线核对：抽检各档位模型，按“成本×倍率”算应扣与实扣比对 测试负责人 下发后 4 小时内 NewAPI 日志、脚本 核对记录 🤖自动化
6 机器人推送变更到通知群（不含成本价明细给非授权人员） IT 运维/上游渠道维护 核对通过后 飞书机器人 变更通知 🔧飞书固化
7 生产网关切换/发版时将“倍率与价格核对”列入发布检查单 网关计费研发 每次切换前 发布检查单 勾选记录 🔧飞书固化
8 月度对账：各模型消耗成本 vs 收入，输出毛利与异常 后端研发、财务专员 每月 10 日前 脚本、报表 成本收入对账报告 🤖+👤
9 业务取数需求（报告平均/最大成本）走固定报表 后端研发 需求提出后 2 个工作日内 BI/多维表格 成本 insight 报表 🤖自动化

5. 交付物与模板

  • 交付物：成本价主表、定价审批单、下发与核对记录、月度成本收入对账报告、成本 insight 报表
  • 建议模板/表单：成本价主表字段——模型、渠道（测试/生产）、币种、官方价、折扣（=实际成本价/刊例价，分输入/输出/缓存读写）、汇率版本、人民币成本价、生效日期、维护人；售价表字段——产品线、档位、模型、倍率、分组倍率、毛利比例、审批单号
  • 汇率版本表：上游、充值日期、充值汇率、对客折算汇率（默认 7）、偏差率

6. 异常与升级

  • 渠道变化导致无对应价格、落入默认高价 → 立即回滚 → 升级 CTO（1 小时内）
  • 批量改价导致服务不可用或额度异常 → 回滚并通知受影响产品线 → 升级 Leap 研发负责人（立即）
  • 汇率偏差 > 5% → 财务确认入账口径（计入研发费用或调整） → 升级 CTO（当月）
  • 月度对账发现某产品线持续亏损 → 产品总监提出调价方案 → 升级 CTO（5 个工作日内）
  • 成本价/折扣表需发给外部（供应商谈判）→ CTO 审核后再发 → 不得直接转发

7. 衡量指标

  • 价格同步准确率 = 上线核对一次通过的变更数 / 总变更数，目标 ≥ 95%
  • 计价事故数 = 倍率漏调、默认高价等引发的事故次数，目标每季度 0
  • 成本价更新时效 = 上游调价到主表更新的工作日，目标 ≤ 1 天
  • 月度对账准时率 = 每月 10 日前出报告，目标 100%
  • 汇率偏差率 = |实际充值汇率 − 对客折算汇率| / 实际汇率，目标 ≤ 5%

8. 低效诊断

  • 现象：生产网关切换后倍率未调，客户侧计价混乱，“计费谁管、在哪操作”无人能答｜依据：「Leap产研测」2026-07
  • 现象：市场频繁找技术要模型价格，模型→渠道映射拿不到；批量改价后服务瘫痪、渠道变化落默认高价｜依据：「AI API」2026-06
  • 现象：上游与下游两张对账表格式不同，渠道名重复、公式写死倍率｜依据：「AI API」2026-07
  • 现象：汇率口径 7/7.25/6.76/6.74 并存，充值汇率无人登记，网关无计费规则快照｜依据：「AI API」2026-08
  • 现象：定价、毛利、额度包规则只在群内口头确认，无成文定价文档｜依据：「LeapCore（archived）」2026-05
  • 现象：成本收入无定期对账，报告成本异常后才发现计费问题；取数口径（公网价 vs 内部账）不一｜依据：「【行业版Leapcore】工程版」2026-08、「工程咨询产研」2026-07
  • 现象：供应商折扣表每次手工加急导出｜依据：「AI API」2026-09

9. 分支变体

  • 海外上游预充美元：每次充值记录当日汇率并写入汇率版本表；人民币余额按上游汇率扣费的渠道按月更新汇率
  • B 端 API 计费：成本基础事实以云端中转为准，客户侧只展示 token 用量，不展示倍率与毛利；额度包与赠送额度单列
  • 行业版按调用计费：月度成本收入对账，阈值告警
  • 视频/图片模型（按秒、分辨率）：网关表达困难的单独建表计价
  • 供应商谈判折扣表：对商务用最低折扣表、对财务用成本表、对销售用对外报价，三者分开发放

10. 待确认问题

  • 主责是否为上游渠道维护岗？售价/倍率的最终审批人是 CTO 还是产品总监？
  • 对客汇率统一按 7 是否仍有效？偏差超 5% 如何处理？
  • 成本价主表是否作为唯一数据源，旧价格表何时下线？
  • 月度成本收入对账由研发还是财务出具？
  • 成本价的查看权限范围是否已成文？
FIN-29计费扣费异常核查与退补待新建400

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：客户或内部用户质疑扣费异常、单次报告/对话消耗远超预期、误调用高成本模型时，核算真实成本、判断是否多收、决定退补并校准计价口径
  • 负责人：主责——Leap 研发负责人（当前：王皓南·推断待确认）；协同——网关计费研发（当前：柯逸飞、邓乾·推断待确认）、后端研发（当前：陈锦杰、宋祺睿·推断待确认）、产品总监（客户口径，当前：杨萌·推断待确认）、渠道/客户对接研发（当前：陈子康·推断待确认）、测试负责人（定性，当前：张东郅·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 受理登记 → ② 定级 → ③ 拉日志与成本 → ④ 按定价公式核算 → ⑤ 定性（计费错误/正常消耗/误调用） → ⑥ 修复 → ⑦ 退补审批 → ⑧ 答复客户与沉淀
  • 交付结果：扣费异议核查报告（数据、结论、多收金额）、修复版本、退补审批单、客户答复记录
  • 状态依据：2026-06～07 至少 5 次同类事件，每次临时查日志、逐个对令牌，结论散在群聊与机器人回复中，退补无审批链

1. 场景判定

  • 触发条件：客户/用户反馈“扣得多、越用越少”；单篇报告消耗异常（数亿词元）；短时间高消耗；高成本模型被误调用
  • 典型说法：「一个半小时用掉 20M token」「一个普通报告花了好几百」「看下计费正常吗」「同一个对话跑了几十块」
  • 判断问题：是针对具体用户/客户的扣费是否正确？若是全局价格配置变更，转 FIN-28
  • 不归本流程管：模型成本价、倍率日常维护 → 请走 FIN-28；支付/分账资金异常 → 请走 FIN-25；客户月度账单出具 → 请走 FIN-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事件负责人 定级、核算结论、修复方案 R Leap 研发负责人（当前：王皓南·推断待确认）
日志核查 查 NewAPI 日志、令牌映射、缓存命中率 R 网关计费研发（当前：柯逸飞、邓乾·推断待确认）
数据与修复 拉 settlement/ai_usages 数据、修计价口径、发 hotfix R 后端研发（当前：陈锦杰、宋祺睿·推断待确认）
客户口径 对客沟通、结论确认 R（对外） 产品总监（当前：杨萌·推断待确认）、渠道/客户对接研发（当前：陈子康·推断待确认）
定性 判断是否属计费错误 C 测试负责人（当前：张东郅·推断待确认）
退补审批 是否退费、补偿金额的最终决定；流程兜底 A 创始人兼 CTO（当前：丁震宇·推断待确认）
财务 退款/补额度入账 R（执行） 财务专员（当前：刘梦可·推断待确认）

3. 办之前请准备

  • 用户/企业标识、机器或令牌、时间段、对话或报告 ID、截图
  • 当时生效的价格与倍率版本（成本价主表）
  • 模式（标准/专家）、是否带附件、缓存命中率
  • 生产数据库只读查询权限（提前开通给值班研发）
  • 请求最少包含字段：用户/企业标识、令牌或机器码、时间段、对话或报告 ID、模型与模式、余额/消耗截图、客户性质（内部/外部）、期望答复时限；缺项由受理人补齐后再登记

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 受理并按模板登记异议（用户/企业/时间/模型/截图） 产品总监或客户对接研发 反馈后 2 小时内 工单系统 异议工单（工单系统，工单号回复反馈人） 🔧飞书固化
2 定级：外部客户或疑似全局问题为 P0 Leap 研发负责人 登记后 2 小时内 工单 等级（工单字段；P0 同步 CTO） 👤人工判断
3 拉日志与成本数据：请求数、token、缓存命中率、模式占比 网关计费研发、后端研发 P0 当日；P1 1 个工作日内 NewAPI 日志、数据库、AI 汇总 数据表（挂工单附件；超时→CTO） 🤖自动化
4 按定价公式重算应扣，与实扣比对，算出差额 Leap 研发负责人 数据到位后 4 小时内 脚本 核算结论（工单评论：应扣/实扣/差额） 🤖+👤
5 定性：计费错误 / 正常消耗 / 误调用 / 产品缺陷 测试负责人 核算后当日 工单 定性结论（工单字段） 👤人工判断
6 修复：计价口径、缓存配置、高成本动作二次确认等，发 hotfix 后端研发 P0 2 个工作日内 Gitea、发版流程 修复版本号（Gitea PR 关联工单） 👤人工判断
7 退补审批：多收金额、退款或补额度方式 创始人兼 CTO、财务专员 结论出具后 1 个工作日内 飞书审批 退补审批单（飞书审批，编号回写工单） 🔧飞书固化
8 答复客户（结论、修复、退补），执行退补 产品总监、财务专员 审批通过后 1 个工作日内 客户群、后台 答复记录（客户群 + 工单）+ 退补执行凭证（财务留痕） 👤人工判断
9 核查报告归档，计价问题同步 FIN-28 校准 Leap 研发负责人 关单后 2 个工作日内 飞书文档 核查报告（飞书文档，链接回写工单并同步 FIN-28 负责人） 🔧飞书固化

5. 交付物与模板

  • 交付物：异议工单、核查报告、修复版本号、退补审批单、客户答复记录
  • 建议模板/表单：扣费异议核查模板字段——用户/企业、令牌/机器、时间段、模型与模式、请求数、token、缓存命中率、应扣、实扣、差额、定性、根因、修复版本、退补方式、审批人、答复时间

6. 异常与升级

  • 无法将用户对应到本地网关令牌 → 由客户对接研发补映射 → 升级 Leap 研发负责人（当日）
  • 开发无生产库权限 → 按权限申请流程临时授权只读 → 升级 CTO（2 小时内）
  • 确认多收且涉及多个客户 → 暂停相关计费项或回滚倍率 → 升级 CTO（立即）
  • 核查阶段只查不操作；未经审批不得改余额或退款
  • 客户情绪升级或要求书面说明 → 产品总监出具 → 销售负责人知会
  • 受理人 2 小时未登记工单 → 产品总监代为登记 → 升级 Leap 研发负责人（当日）
  • P1 数据超 1 个工作日未到位 → 事件负责人催办 → 升级 CTO（次日）
  • 退补审批超 1 个工作日未处理 → 产品总监电话提醒审批人，并先给客户阶段性答复记录工单 → 超 2 个工作日由财务负责人共同催办

7. 衡量指标

  • 异议核查周期 = 登记到核算结论的工作时长，目标 P0 ≤ 1 天、P1 ≤ 3 天
  • 计费错误率 = 定性为计费错误的工单数 / 异议工单数（按月）
  • 重复事故数 = 同一根因再次引发的异议数，目标 0
  • 退补闭环周期 = 结论到客户收到退补的工作日，目标 ≤ 3 天

8. 低效诊断

  • 现象：每次需逐个对用户令牌、企业、机器查日志，结论在机器人回复里未沉淀；用户反复追问“修了没”｜依据：「Leap反馈群」2026-07
  • 现象：标准/专家模式成本差异大用户事先不知，高成本模型可被直接误调用秒扣｜依据：「Leap反馈群」2026-07
  • 现象：客户单篇报告扣费异常，数据出了两版，“固定毛利”口径当天才对齐，退款无审批链｜依据：「工程咨询产研」2026-07
  • 现象：计价按未缓存命中价计算；开发无生产库权限需另找人，缺成本看板｜依据：「字字可研项目群」2026-06

9. 分支变体

  • 内部员工高消耗：不退补，仅出核查结论与使用建议
  • 外部企业客户（如某高校实训课客户）：必须出书面结论，退补走审批
  • 客户侧受理与答复：客户经客服渠道提出的扣费疑问，先按 X-CS-09 受理登记与安抚，核算、定性、退补回到本流程（本条为计费异常主条）
  • LeapAll 个人用户：兑换券购买在订单页不显示、账单才有，答复时注明口径
  • 字字可研/行业版按词元扣费：区分成本价口径与扣费口径、是否带附件
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-03（决策记录与发布）、ALL-04（跨部门交接契约）

10. 待确认问题

  • 主责是否为 Leap 研发负责人？字字可研线是否由鼎慧侧负责人主责？
  • 退补审批人是 CTO 还是需财务负责人共签？金额阈值多少？
  • 生产库只读权限是否给值班研发常开？
  • 管理后台“分用户/分模型消耗”报表与高消耗告警由谁排期？
FIN-30云/模型服务成本按项目归集与账号台账待优化81

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：月度云账单出具、需按项目归集云/模型成本、统计个人与项目 API 用量，或维护多主体云账号台账与回收发票时启动
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、创始人兼 CTO（账号持有与归集口径，当前：丁震宇·推断待确认）、Leap 研发负责人（IaC 规范，当前：王皓南·推断待确认）、后端/运维研发（当前：宋祺睿·推断待确认）、网关计费研发（当前：柯逸飞·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 月初下载各平台账单与回单 → ② 按项目/标签筛选导出 → ③ 未归集资源补归属 → ④ 内部 API 用量按人/项目统计 → ⑤ 成本分摊入账 → ⑥ 发票回收 → ⑦ 台账更新
  • 交付结果：月度按项目云/模型成本表、账号台账（平台-主体-用途-开票规则）、发票回收记录
  • 状态依据：已有财务平台台账、“非实体资产申领”审批和云厂商 A 项目维度导账口径，但历史资源靠手动打标、账号有遗漏、登录验证码依赖个人、内部用量每次临时导出

1. 场景判定

  • 触发条件：每月初云账单出具；财务需要按项目成本表；需统计内部 aiapi/LeapCore 用量；新开云账号或充值后需开票
  • 典型说法：「要把云厂商支出都分配到对应项目，不然财务没法整」「统计一下每个人从 aiapi 用了多少额度，财务需要归到项目」「我们目前有的云服务账号挺多的」
  • 判断问题：是公司内部使用的云/模型资源成本归集吗？若是给客户的账单或网关账单，转对应流程
  • 不归本流程管：网关账单导出 → 请走 FIN-26；研发费用立项与归集口径 → 请走 FIN-31；子公司/跨主体资源使用 → 请走 FIN-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
成本归集与台账 下载账单回单、按项目归集、入账、台账维护 A 财务负责人（当前：黄梦婷·推断待确认）
账单下载与发票 逐平台下载账单、查余额、索取发票 R 财务专员（当前：刘梦可·推断待确认）
资源归属 云支出分配到项目、梳理未审批历史资源 R IT 运维（当前：杨明学·推断待确认）
归集口径与账号 账号用途说明、手动打标；无审批历史资源归属与口径争议拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
IaC 规范 新资源项目/标签/分账标签规范 C Leap 研发负责人（当前：王皓南·推断待确认）
IaC 执行 新资源按规范打标 R 后端/运维研发（当前：宋祺睿·推断待确认）
用量统计 导出内部用量按人/档位/项目 R 网关计费研发（当前：柯逸飞·推断待确认）
申请人 新资源开通时提交“非实体资产申领”并填写项目归属 R 资源申请人（各部门）

3. 办之前请准备

  • 云账号台账（平台、主体、登录方式、开票规则、付款周期）
  • 财务只读子账号或已绑定企业手机/邮箱的登录方式
  • 项目清单与编号、用户→项目映射表
  • 上月“非实体资产申领”审批记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用财务只读子账号登录各平台，下载上月账单、回单、余额 财务专员 每月 5 日前 各云控制台 账单与回单 🤖自动化（账单邮件推送）
2 按“项目”维度筛选导出成本表 财务专员 每月 7 日前 云厂商控制台 项目成本表 🤖自动化
3 未归属资源清单交 IT，按审批单补归属；无审批的历史资源由 CTO 定归属 IT 运维 收到后 3 个工作日内 多维表格、审批 归属补全 🔧+👤
4 导出内部 API 用量（按人、档位、项目） 网关计费研发 每月 5 日前 网关后台、脚本 用量表 🤖自动化
5 按分摊规则入账（研发/经营、项目） 财务负责人 每月 15 日前 财务系统 记账凭证 👤人工判断
6 按平台开票规则索取发票，个人充值与对公分开 财务专员 每月 15 日前 各平台 发票 🔧飞书固化（月度提醒）
7 更新账号台账：新增/停用账号、余额、负责人 财务负责人 每月 15 日前 多维表格 台账 🔧飞书固化
8 新资源开通必须走“非实体资产申领”并按 IaC 打项目、普通标签、分账标签 申请人、后端/运维研发 开通时 飞书审批、IaC 带标签资源 🔧飞书固化

5. 交付物与模板

  • 交付物：月度项目成本表、内部用量表、账号台账、发票回收清单
  • 建议模板/表单：云账号台账字段——平台、主体、账号用途、负责人、登录方式（企业手机/子账号）、开票规则（专票/普票、是否需消耗额度）、付款周期、状态（在用/停用）、最近账单月；资源归属表字段——资源 ID、项目、标签、审批单号、负责人

6. 异常与升级

  • 登录需个人验证码 → 推动改为企业手机或财务子账号 → 升级 CTO（当月完成改造）
  • 发现台账外账号 → 当日补登并确认是否停用 → 升级 CTO
  • 资源无法确定项目 → 先挂“待归属”并于下月前清零 → 升级 IT 运维负责人
  • 平台开票需先消耗额度、开不出票 → 记录待开票金额，下月跟进 → 升级财务负责人
  • 不再使用的平台仍有余额 → CTO 确认停用并申请退款或转用
  • 升级条件：无审批单的历史资源无法确定归属，或财务与 IT 对研发/经营、项目归集口径有争议时，由创始人兼 CTO 拍板（A（升级））

7. 衡量指标

  • 项目归集率 = 已归属项目的云成本 / 云成本总额，目标 ≥ 95%
  • 账单下载准时率 = 每月 5 日前完成的平台数 / 平台总数，目标 100%
  • 发票回收率 = 已回收发票金额 / 应开票金额（按季），目标 ≥ 95%
  • 依赖个人验证码的账号数，目标 0

8. 低效诊断

  • 现象：项目/普通标签/分账标签口径争论，历史资源只能手动打标｜依据：「鼎慧产研决策部」2026-08
  • 现象：内部用量每次临时导出，币种混用，生产数据在内网机器｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：账号分散有遗漏，逐平台下载回单，验证码与账号在群里流转｜依据：「财务部」2026-04、「财务部」2026-07
  • 现象：历史业务未走审批，月度靠手工分配到项目｜依据：「忠橙星行星引擎」2026-08

9. 分支变体

  • 云厂商 A：统一按“项目”维度导账；云厂商 B、C 的代金券另行记录
  • 已计划弃用的平台：确认余额后停用并归档
  • 内部用量估算：经济档按日用量 × 22 估算月成本，需注明为估算
  • 个人充值与对公充值：分开开票、分开入账

10. 待确认问题

  • 主责是否为财务负责人？IT 运维在资源归属上的职责边界是否认可？
  • 云账号是否统一改为企业主体 + 财务只读子账号？时间表？
  • 云成本在研发与经营之间如何分摊，是否与 FIN-31 统一？
  • 每月 5 日/15 日节点是否可行？
FIN-31研发项目立项与研发费用归集待优化240

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：新增研发项目需立项，或审计、税务（研发加计扣除、软件退税）要求立项资料、研发工时划分、费用归集与阶段性成果说明时启动
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（技术口径与人员划分，当前：丁震宇·推断待确认）、研发人员（工时填报）、客户端研发（阶段性成果材料，当前：葛家和·推断待确认）、行政（材料保密，当前：侯明月·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项三件套起草 → ② 技术补充与审批 → ③ 设科目与项目辅助核算 → ④ 月度工时填报 → ⑤ 费用归集 → ⑥ 季度成果沉淀 → ⑦ 审计/税务材料输出
  • 交付结果：各研发项目立项三件套（立项申请书、可行性报告、股东会纪要）、月度人工成本核算表、按项目研发费用明细、阶段性成果说明
  • 状态依据：已有立项三件套与月度人工成本核算表（临时表格），但工时需多月补填、阶段性成果在审计前用 AI 扫代码临时补，云费用研发/经营难拆

1. 场景判定

  • 触发条件：新研发项目启动；每月工资核算后；审计或税务要求补材料；新增支出需判断归属研发项目
  • 典型说法：「4-8 月的项目及研发工时需要填一下」「这个是用于哪个研发项目呢」「请协助提供相关项目的阶段性成果说明」
  • 判断问题：该支出或人员工时是否属于已立项研发项目？
  • 不归本流程管：云成本按项目日常归集 → 请走 FIN-30；子公司研发成本隔离 → 请走 FIN-32；政策申报材料 → 请走 POL-01（政策研判与申报决策）/ POL-04（科技项目申报）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
归集负责人 起草立项材料、设科目、归集费用、对接审计 A 财务负责人（当前：黄梦婷·推断待确认）
技术口径 补项目成员/分工/预算、审批立项技术内容、确认研发人员与工时归属；分摊口径争议时拍板 R / A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
工时填报 每月填写项目与工时 R 研发人员（当前：待指定）
成果材料 基于代码仓库/工单生成阶段性成果说明 R 客户端研发（当前：葛家和·推断待确认）
保密 立项材料的保密与存档提醒 C 行政（当前：侯明月·推断待确认）
申请人 提交采购/报销等单据时标注所属研发项目 R 单据申请人（各部门）

3. 办之前请准备

  • 项目名称、编号、起止时间、成员与分工、预算
  • 工资表与研发人员名单
  • 月度人工成本核算表模板
  • 云费用、服务器等单据及其用途说明
  • 代码仓库、工单系统访问权限（生成成果材料用）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草立项三件套 财务负责人 项目启动后 5 个工作日内 立项模板 立项草稿 🔧飞书固化（模板）
2 补充成员、分工、预算与技术内容，审批 创始人兼 CTO 收到后 3 个工作日内 飞书审批 立项定稿 👤人工判断
3 设置研发支出明细科目与项目辅助核算，分配项目编号 财务负责人 立项后 3 个工作日内 财务系统 科目与编号 👤人工判断
4 研发人员按项目填报当月工时 研发人员 每月 5 日前 多维表格 工时表 🔧飞书固化（自动提醒）
5 CTO 确认研发人员名单与工时归属 创始人兼 CTO 每月 8 日前 多维表格 确认记录 👤人工判断
6 编制月度人工成本核算表，归集云费用等到项目 财务负责人 每月 15 日前 财务系统 研发费用明细 🔧+👤
7 新增单据标注所属研发项目（采购审批必填） 申请人 提交时 飞书审批 带项目字段单据 🔧飞书固化
8 每季度由仓库/工单自动生成阶段性成果摘要，技术确认后归档 客户端研发、创始人兼 CTO 季度结束后 10 个工作日内 代码仓库、AI 阶段性成果说明 🤖+👤
9 审计/税务要求时汇总输出材料包 财务负责人 按审计要求日期前 3 个工作日 飞书云盘 材料包 👤人工判断

5. 交付物与模板

  • 交付物：立项三件套、研发项目台账、月度工时表、月度人工成本核算表、研发费用明细账、季度阶段性成果说明
  • 建议模板/表单：研发项目台账字段——项目编号、名称、主体、立项日期、预算、成员、里程碑、状态；工时表字段——月份、人员、项目编号、工时占比、确认人；单据归属字段——单据号、金额区间、所属项目、研发/经营判定

6. 异常与升级

  • 工时未按时填报 → 机器人提醒 → 逾期 3 个工作日升级 CTO
  • 费用研发/经营无法拆分 → 按 CTO 签字的分摊口径处理 → 升级综合部负责人（当月）
  • 审计临时要求补材料且无过程记录 → 用仓库/工单生成材料并由 CTO 确认真实性 → 不得编造
  • 新主体是否做研发未定 → 立项前由 CEO 确认
  • 升级条件：研发/经营费用分摊、研发人员或工时归属在财务与业务间无法达成一致时，由创始人兼 CTO 拍板（A（升级））

7. 衡量指标

  • 工时填报准时率 = 每月 5 日前完成填报人数 / 研发人数，目标 ≥ 95%
  • 立项及时率 = 启动 10 个工作日内完成立项的项目数 / 新项目数，目标 100%
  • 审计补材料次数 = 审计期间临时补材料项数，目标逐年下降
  • 研发费用归集完整率 = 已标注项目的研发相关单据 / 研发相关单据总数，目标 100%

8. 低效诊断

  • 现象：工时数月未填，需集中补填 4～8 月数据｜依据：「财务部」2026-09
  • 现象：无系统，用临时表格统计，项目归属需逐次询问｜依据：「财务部」2026-06、「财务部」2026-10
  • 现象：研发过程资料不成体系，审计前才临时补阶段性成果；云费用研发/经营难拆｜依据：（推断）

9. 分支变体

  • 项目维度：LeapAll、LeapBase、LeapCore 等；需同时支持按项目与按产品双维度
  • 云费用：未明确前先统一归入一个基座类项目，后续按 FIN-30 结果细分
  • 多主体（武汉模态、苏州模态、湖北鼎慧）：是否开展研发及立项需分别判断

10. 待确认问题

  • 主责是否为财务负责人？研发人员名单与工时由谁最终签字？
  • “尽量多立项”的原则是否有上限或审批要求？
  • 工时填报是否用多维表格替代 Excel？是否与考勤/工单联动？
  • 各主体是否分别立项和归集？
  • 阶段性成果材料的保密与对外提供范围如何规定？
FIN-32多主体业务归属与子公司成本隔离待新建200

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：子公司或关联主体使用母公司资源、采购服务或对外签约时，确认合同签署主体与采购/出货主体一致、子公司支出走本主体采购并归集、跨主体成本分摊与账目隔离
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——创始人兼 CTO（资源与支出审批，当前：丁震宇·推断待确认）、IT 采购（当前：杨明学·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）、子公司业务负责人（当前：赵捷·推断待确认）、COO（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务专员（当前：刘梦可·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 业务发起时确定签约主体 → ② 校验采购/出货主体 → ③ 子公司支出走本主体采购 → ④ 跨主体资源使用申请 → ⑤ 按主体分账号/分 key → ⑥ 月度消耗对账与分摊 → ⑦ 切换与归档
  • 交付结果：主体一致的合同与采购记录、子公司资源与 API Key 台账、跨主体资源使用批准记录、月度分摊对账表
  • 状态依据：子公司资源与成本归属口径只存在于个别沟通中，采购“这次先批、后面尽量走采购”；已出现销售合同主体与进货主体不一致导致出入账不平，由财务事后发现

1. 场景判定

  • 触发条件：子公司需购买 AI 接口、算力、云服务；子公司项目借用母公司服务器、域名、API、备案；销售签约主体与采购/出货主体不同
  • 典型说法：「后面尽量还是走本主体采购，不然账务会乱」「导致出入账不平」「不然后面研发投入账会乱」
  • 判断问题：本次签约、付款或资源使用的主体，与最终受益/出货/记账主体是否一致？
  • 不归本流程管：同一主体内的项目成本归集 → 请走 FIN-30；研发项目立项 → 请走 FIN-31；合同条款审核 → 请走 LEG-03（销售合同）/ LEG-04（采购及其他对外合同）；我方签约主体选择与印章信息 → 请走 LEG-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主体口径负责人 主体一致性校验、分摊规则、账目隔离 R 财务负责人（当前：黄梦婷·推断待确认）
资源与支出审批 跨主体资源使用、例外支出的日常审批 R（审批） 创始人兼 CTO（当前：丁震宇·推断待确认）
集团主体安排 签约主体、直销主体规则的最终决定 A CEO（当前：邴龙志·推断待确认）
采购与交付表单 硬件采购主体、交付表单签约主体字段 R IT 采购（当前：杨明学·推断待确认）
销售签约 按规定主体签合同 R 销售负责人（当前：李鹏为·推断待确认）
子公司申请 发起采购、开账号、企业认证 R 跃竞负责人（当前：徐莉·推断待确认）、子公司技术负责人（当前：白立新·推断待确认）
子公司出资 子公司对公充值与费用承担 C 子公司业务负责人（当前：赵捷·推断待确认）
ERP 与系统 主体校验系统化建议 C COO（当前：常元和·推断待确认）
法务 关联交易与合同主体合规 C 法务负责人（当前：李瑶·推断待确认）
付款执行 按服务类型对公付款或先买后开票 R 财务专员（当前：刘梦可·推断待确认）

3. 办之前请准备

  • 集团各主体清单与用途（直销硬件主体、研发主体、子公司）
  • 合同、采购单、交付表单中的签约主体信息
  • 子公司采购申请表（含归属研发/经营活动）
  • 跨主体资源清单（服务器、域名备案、COS、API Key）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 交付/合同表单必填签约主体，按集团规则选择 销售负责人 合同起草时 交付表单、飞书审批 主体确定 🔧飞书固化
2 采购与出货主体自动比对签约主体，不一致则拦截 IT 采购、财务负责人 采购提交时 飞书审批 校验结果 🔧+🤖
3 子公司支出填采购申请（含归属研发/经营），走本主体采购 子公司申请人 支出前 采购申请表 采购单 🔧飞书固化
4 按服务类型付款：支持对公的直接对公；中转类先买后开票；以本主体注册企业认证账号 财务专员 审批通过后 2 个工作日内 银行、平台 付款记录 👤人工判断
5 跨主体借用资源须提交使用申请，写明期限与切换计划 子公司技术负责人 使用前 飞书审批 批准记录 🔧飞书固化
6 按主体与用途分 key（生产/测试/自用），登记台账 子公司技术负责人 开通当日 多维表格 Key 台账 🔧飞书固化
7 月度导出各 key 消耗，按主体对账分摊 财务负责人 每月 10 日前 网关后台、财务系统 分摊对账表 🤖自动化
8 到期资源切换到子公司自有账号（域名、备案、云账号）并归档 子公司技术负责人 按申请期限 各平台 切换记录 👤人工判断

5. 交付物与模板

  • 交付物：主体一致的合同/采购记录、子公司采购单、跨主体资源使用批准、Key 台账、月度分摊对账表
  • 建议模板/表单：跨主体资源台账字段——资源类型、所属主体、使用主体、用途（生产/测试/自用）、开始日期、计划切换日期、批准人、月度消耗、分摊方式；采购审批增加字段——采购主体、归属活动（研发/经营）、所属项目

6. 异常与升级

  • 合同主体与进货主体不一致已发生 → 财务出具影响说明与调整方案 → 升级 CEO（5 个工作日内）
  • 子公司未走采购先支出 → 补采购单，标注例外 → 升级 CTO；同类例外每季度超过 2 次升级 CEO
  • 借用资源超期未切换 → 财务提醒子公司 → 升级 CTO（逾期 10 个工作日）
  • 涉及关联交易定价或审计问询 → 法务与财务共同出具意见 → 升级 CEO

7. 衡量指标

  • 主体一致率 = 签约、采购、出货主体一致的合同数 / 合同总数，目标 100%
  • 例外支出次数 = 未走本主体采购的子公司支出笔数，目标每季度 0
  • 跨主体资源超期数 = 超过计划切换日期仍未切换的资源数，目标 0
  • 分摊对账准时率 = 每月 10 日前完成的月份数，目标 100%

8. 低效诊断

  • 现象：子公司采购怎么走需申请人临时询问，审批靠创始人当次口头说明，“先批后补规则”｜依据：「跃竞模态董事会」2026-08
  • 现象：销售合同主体与进货主体不一致致出入账不平，谁决定签约主体不明确，财务事后发现｜依据：「leapcore 交付财务问题」2026-07
  • 现象：子公司借用母公司域名、云资源、API，归属口径未成文，同一事项反复协调｜依据：（推断）

9. 分支变体

  • 跃竞：AI 接口、算力优先走跃竞采购，以跃竞名义企业认证并对公付款
  • 曜途：测试开发阶段可暂用模态资源，生产前切到曜途自有云账号、API 账号与备案，曜途对公充值
  • 硬件销售：建议由武汉模态统一存直销硬件，其他主体对外签约时从武汉模态采购，或合同统一以武汉模态签署（需 CEO 确认）

10. 待确认问题

  • 主责是否为财务负责人？签约主体规则由谁最终发布？
  • 硬件直销是否统一由武汉模态签约和存货？鼎慧等主体何时可签约？
  • 子公司借用母公司资源的期限上限与结算方式（是否收费）？
  • 是否引入 ERP 或在交付表单中实现主体自动校验？
  • 关联交易是否需要法务出具标准协议？
FIN-33关联主体资金划转与注资待新建120

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：集团内某主体（子公司/关联公司）账户余额不足以支付工资、税费、货款，或需实缴注册资本时，由其他主体向其划转资金
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，定性审批）、创始人兼 CTO（当前：丁震宇·推断待确认，付款执行/审批）、法务负责人（当前：李瑶·推断待确认，协议与决议）；兜底——CEO
  • 核心流程：① 月度资金预警 → ② 缺口测算与方案（借款/投资款） → ③ 管理层定性审批 → ④ 协议或股东决定 → ⑤ 付款申请与打款 → ⑥ 入账与凭证留存 → ⑦ 台账登记与还款/实缴跟踪
  • 交付结果：按审批定性完成的资金划转、对应借款协议或注资决议、银行回单与注资证明、关联往来台账更新
  • 状态依据：「财务部」2026-06～07 约 3 次划转，均为发薪前临时发现余额不足，借款还是投资款每次现场讨论决定，没有资金计划和划转规则

1. 场景判定

  • 触发条件：任一主体在发薪日、纳税申报扣款日、大额付款日前余额低于应付金额；或章程约定的实缴期限临近
  • 典型说法：「XX 主体本月发薪需要资金划转」「可以从母公司以借款名义划转」「按子公司投资款打款」
  • 判断问题：资金是否在集团内部主体之间流动？收款方是否为集团控股或关联主体？是否需要明确是借款还是出资？
  • 不归本流程管：集团外部借款或整体资金计划 → 请走 FIN-39；子公司日常支出归属与成本分摊 → 请走 FIN-32；工资核算本身 → 请走 HR-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资金测算与方案 发现缺口、测算金额、提出划转性质建议、执行账务处理 R 财务负责人（当前：黄梦婷·推断待确认）
定性审批 决定借款/投资款、额度与期限 A CEO（当前：邴龙志·推断待确认）
付款审批/执行 审批或操作付款主体网银 C 创始人兼 CTO（当前：丁震宇·推断待确认）
法务 出具关联方借款协议、股东决定/出资决议模板 C 法务负责人（当前：李瑶·推断待确认）
人事 提供发薪金额与发薪日 I 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 各主体当日银行余额与未来 30 天应付清单（工资、社保公积金、税款、货款）
  • 收款主体章程中的认缴额、已实缴额、实缴期限
  • 付款主体与收款主体的关联往来余额（历史借款未还金额）
  • 划转性质建议及理由（借款：期限、是否计息；投资款：计入实收资本还是资本公积）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 每月初更新集团资金计划表，标出余额不足主体 财务负责人 每月第 3 个工作日前 多维表格 资金计划表 🔧+🤖
2 发现缺口后测算金额、提出划转方案（来源主体、性质、金额、期限） 财务负责人 发现后 1 个工作日内；至少在付款日前 5 个工作日 飞书文档 划转方案 👤人工判断
3 管理层确认划转性质与额度 CEO 收到方案后 1 个工作日内 飞书审批 审批记录 🔧飞书固化
4 借款：签关联方借款协议；投资款：出具股东决定/出资决议 法务负责人 审批后 2 个工作日内 合同模板、用印审批 协议或决议 🔧飞书固化
5 提付款申请，银行附言写明“借款”或“投资款” 财务负责人 协议签署当日 飞书付款审批、网银 银行回单 🔧飞书固化
6 双方主体分别入账（其他应收/应付或实收资本），留存注资证明 财务负责人 到账后 2 个工作日内 财务系统 记账凭证、注资证明 👤人工判断
7 登记关联往来台账，借款设还款提醒，投资款更新实缴进度 财务负责人 入账当日 多维表格 往来台账 🔧飞书固化

5. 交付物与模板

  • 交付物：划转方案、审批记录、借款协议或股东决定、银行回单、注资证明、记账凭证、关联往来台账
  • 建议模板/表单：资金划转审批单（付款主体、收款主体、金额、性质〔借款/投资款〕、用途、期限、是否计息、还款来源、附件：余额截图、应付清单）；集团资金计划表（主体、日期、期初余额、预计流入、预计流出、缺口、处理方案）

6. 异常与升级

  • 发薪日前 3 个工作日内才发现缺口 → 先按借款性质加急审批打款，事后 5 个工作日内补协议 → 升级 CEO（当日）
  • 划转性质事后需变更（借款转投资款）→ 财务出调整方案、法务出补充决议 → 升级 CEO（1 周内）
  • 集团内各主体均无法覆盖 → 转入 FIN-39 资金计划流程 → 升级 CEO（当日）

7. 衡量指标

  • 临时救火次数：付款日前 3 个工作日内才发现缺口的次数，目标 0 次/季度
  • 划转留痕率：有审批 + 协议/决议 + 回单的划转笔数 / 总笔数，目标 100%
  • 关联借款逾期率：超过约定期限未还或未转增资本的借款笔数，目标 0

8. 低效诊断

  • 现象：发薪前才发现主体余额不足，缺少按月的集团资金计划，只能临时救火｜依据：「财务部」2026-07
  • 现象：划转是“借款”还是“投资款”每次临时讨论，没有规则，影响税务处理和实缴口径｜依据：「财务部」2026-07
  • 现象：划转缺少协议/决议模板，留痕只靠付款审批和回单｜依据：「财务部」2026-06、「财务部」2026-07

9. 分支变体

  • 借款：签关联方借款协议，约定期限与是否计息，按期还款或转增资本；注意关联方无息借款的税务口径
  • 投资款：对应章程认缴与实缴进度，出具股东决定，银行附言注明“投资款”，保留注资证明
  • 涉及主体：模态、鼎慧、苏州模态等主体之间划转，适用同一流程

10. 待确认问题

  • 划转性质是否形成规则（如：用于发薪等经营支出默认借款，用于实缴默认投资款）？
  • 定性审批人是否固定为 CEO？付款主体网银由谁操作？
  • 关联方借款是否计息、期限上限多长？是否已有税务顾问意见？
  • 资金计划表每月第 3 个工作日更新是否可行？
FIN-34子公司月度营收统计与汇报待优化81

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：每月第一周，子公司（当前为跃竞）导出上月营收（交易手续费、会费）与流水，按统一口径向董事会汇报
  • 负责人：主责——跃竞负责人（当前：徐莉·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认，定口径）、CEO（当前：邴龙志·推断待确认，审阅追问）、财务负责人（当前：黄梦婷·推断待确认，口径复核）；兜底——CEO
  • 核心流程：① 每月 1 日提醒 → ② 导出汇付流水与会费数据 → ③ 按口径剔除余额支付等 → ④ 填月报模板 → ⑤ 群内提交摘要+明细 → ⑥ 董事会审阅追问 → ⑦ 归档并用于分润/奖金核算
  • 交付结果：月度营收报告（文字摘要 + 会费统计表 + 商户汇总净额表），存档于固定位置
  • 状态依据：「跃竞模态董事会」2026-07 起已规定每月第一周导出并持续执行到 2026-10，但口径靠群内解释（流水含余额支付），出现过需提醒“记得整”，月报无固定字段模板

1. 场景判定

  • 触发条件：每月 1 日起的第一周；或董事会临时要求查看某月营收
  • 典型说法：「以后每个月的第一周导出一下上个月的营收」「汇付显示的流水额包含余额支付」「X 月营收（交易手续费+陪玩会费）」
  • 判断问题：是否是子公司对董事会的月度营收汇报？数据是否来自支付通道/业务系统导出？
  • 不归本流程管：支付通道每日对账与差异 → 请走 FIN-24；渠道/开发者分润打款 → 请走 FIN-23；资金异常排查 → 请走 FIN-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
汇报人 导出数据、按口径整理、提交月报 R 跃竞负责人（当前：徐莉·推断待确认）
口径制定 规定营收口径与汇报节奏 A 创始人兼 CTO（当前：丁震宇·推断待确认）
审阅 追问成本、预测与奖金分配 C CEO（当前：邴龙志·推断待确认）
财务复核 复核营收口径与账务一致 C 财务负责人（当前：黄梦婷·推断待确认）

3. 办之前请准备

  • 汇付控台上月交易流水、手续费、分账明细（注意剔除余额支付）
  • 会费统计表（会员数、会费金额、退款）
  • 商户汇总表（净额口径）
  • 上月月报，用于环比；当月成本数据（如需回答成本追问）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 飞书任务/机器人提醒提交月报 机器人 每月 1 日 10:00 飞书任务 提醒 🔧飞书固化
2 从汇付控台和业务后台导出上月流水、会费、商户汇总 跃竞负责人 每月第 3 个工作日前 汇付控台、业务后台 原始数据 🤖自动化
3 按口径计算：营收 = 交易手续费 + 陪玩会费；剔除余额支付等不抽费流水 跃竞负责人 同上 多维表格 口径化数据 🔧+🤖
4 填写月报模板，AI 生成文字摘要（环比、异常说明） 跃竞负责人 每月第 4 个工作日前 多维表格、AI 月报初稿 🤖自动化
5 人工核对关键数字与原始导出一致 跃竞负责人 同上 — 核对后月报 👤人工判断
6 在董事会群提交摘要 + 明细附件 跃竞负责人 每月第 5 个工作日前 飞书群 月报 🔧飞书固化
7 审阅追问（成本、年底月收入预估、奖金） CEO、创始人兼 CTO 提交后 3 个工作日内 飞书群 审阅意见 👤人工判断
8 答复追问，月报归档；超计划部分进入奖金核算 跃竞负责人 追问后 2 个工作日内 飞书知识库 归档月报 🔧飞书固化

5. 交付物与模板

  • 交付物：月度营收报告（摘要 + 明细）、会费统计表、商户汇总表（净额口径）
  • 建议模板/表单：月度营收月报（月份、交易流水总额、其中余额支付、计费流水、交易手续费收入、会费收入、退款、营收合计、环比、主要成本、计划值、超计划额、异常说明、数据来源与导出时间）

6. 异常与升级

  • 每月第 5 个工作日未提交 → 机器人二次提醒 → 升级创始人兼 CTO（第 6 个工作日）
  • 口径争议（是否含余额支付、分润是否扣除）→ 按口径说明执行，新情形由创始人兼 CTO 裁定并写入口径说明（3 个工作日内）
  • 营收与账面收入差异超过 5% → 财务负责人复核 → 升级 CEO（1 周内）

7. 衡量指标

  • 月报按时率：每月第 5 个工作日前提交的月数 / 总月数，目标 100%
  • 口径返工次数：月报提交后因口径问题更正的次数，目标 0 次/季度
  • 提醒依赖度：需人工催办的月数，目标 0

8. 低效诊断

  • 现象：支付通道流水含余额支付，直接使用会高估营收，口径靠群内临时解释｜依据：「跃竞模态董事会」2026-07
  • 现象：月报需人工提醒才提交，没有固定触发｜依据：「跃竞模态董事会」2026-08
  • 现象：每月手工导出并整理，字段和文件格式不固定（会费表、商户汇总表格式各异）｜依据：「跃竞模态董事会」2026-09、「跃竞模态董事会」2026-10

9. 分支变体

  • 跃竞：营收两块（交易手续费 + 陪玩会费），余额支付不抽费需剔除
  • 其他子公司如需按月向董事会汇报，套用同一模板，营收口径由各自负责人与财务另定

10. 待确认问题

  • 营收口径是否以“交易手续费 + 会费，剔除余额支付”为准并成文？
  • 月报提交截止定为每月第 5 个工作日是否可行？
  • 财务是否需要复核子公司月报，与账面收入核对？
  • 超计划营收提取奖金的比例与规则是否已有成文制度？
FIN-35月度税务申报与税额确认已有180

状态：已有｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：每月/每季度法定申报期内，完成各主体增值税、附加税、印花税、个税、企业所得税的测算、管理层确认与申报缴纳
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，税额确认）、代账会计（当前：待指定，外部协助）、人事负责人（当前：黄莹·推断待确认，人员异动）；兜底——CEO
  • 核心流程：① 申报日历提醒 → ② 下载回单、核对开票与进项勾选 → ③ 测算税额与税负 → ④ 群内提交管理层确认 → ⑤ 个税按人员异动更新 → ⑥ 申报扣款 → ⑦ 保存完税凭证 → ⑧ 遗漏检查
  • 交付结果：各主体按期完成的申报表、扣款回单与完税凭证，月度税额测算表存档
  • 状态依据：「财务部」2026-04～09 每月稳定执行，申报前在群内征求确认；但 5 月因季中升级一般纳税人手工更正申报表，进项抵扣不匹配等问题约 8 次，流程依赖单人

1. 场景判定

  • 触发条件：每月 1 日进入申报期（截止日通常为 15 日，遇节假日顺延）；季度末次月为企业所得税预缴期
  • 典型说法：「合计缴税 X 元，增值税税负控制在 X% 左右，你们看下可以不」「因季中升级一般纳税人，增值税需手工填写申报表」
  • 判断问题：是否是法定周期申报？税额是否需要管理层确认？是否涉及多个主体？
  • 不归本流程管：员工个税退补咨询与工资核算 → 请走 HR-15；销售开票与红冲 → 请走 FIN-19；进项发票催收 → 请走 FIN-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申报执行 对账、测算、申报、扣款、存档 R 财务负责人（当前：黄梦婷·推断待确认）
税额确认 确认税额与税负水平 A CEO（当前：邴龙志·推断待确认）
外部协助 复杂申报表填写、口径咨询 C 代账会计（当前：待指定）
人员异动 提供入离职、调薪、补贴变动 C 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 各主体上月银行回单、销项开票明细、进项发票勾选清单
  • 上月工资表及 AI 补贴发放表、人员入离职名单
  • 印花税计税合同清单（上月新签合同）
  • 纳税人身份（小规模/一般纳税人）及变更时间
  • 上月税额测算表，用于对比

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 申报日历提醒（各主体、各税种、截止日） 机器人 每月 1 日 飞书日历/任务 提醒 🔧飞书固化
2 下载银行回单，核对销项开票与收入，完成进项发票勾选确认 财务负责人 每月第 3 个工作日前 电子税务局、网银 勾选清单、对账结果 🤖+👤
3 测算增值税、附加、印花税、所得税，计算税负率 财务负责人 每月第 5 个工作日前 税额测算表 测算表 🤖自动化
4 人员异动名单确认，更新个税申报人员与收入（工资 + AI 补贴） 人事负责人、财务负责人 每月第 5 个工作日前 个税系统 个税申报数据 👤人工判断
5 群内发测算摘要（各主体税额、税负率、与上月差异原因）请求确认 财务负责人 截止日前 5 个工作日 飞书群/审批 确认请求 🔧飞书固化
6 确认或提出调整意见 CEO 收到后 1 个工作日内 飞书群/审批 确认记录 👤人工判断
7 申报、扣款，下载申报表与完税凭证存档 财务负责人 截止日前 2 个工作日 电子税务局 申报表、完税凭证 🔧飞书固化
8 按检查清单核对是否遗漏税种/主体 财务负责人 申报完成当日 检查清单 已勾选清单 🔧飞书固化

5. 交付物与模板

  • 交付物：申报表、扣款回单、完税凭证、税额测算表、申报检查清单
  • 建议模板/表单：税额测算表（主体、所属期、纳税人身份、销项税额、进项税额、应纳增值税、附加、印花税、个税、所得税、合计、税负率、上月对比、差异说明）；申报检查清单（主体 × 税种 × 是否申报 × 是否扣款 × 凭证是否存档）

6. 异常与升级

  • 管理层截止前 2 个工作日仍未确认 → 电话提醒，按测算数申报并书面报备 → 升级 CEO（当日）
  • 纳税人身份变更、申报表需手工更正 → 咨询代账会计或主管税务机关 → 1 个工作日内报 CEO
  • 进项发票与抵扣不匹配 → 当月不勾选存疑票，转 FIN-12 补票/换票 → 3 个工作日内回复
  • 逾期申报或漏报 → 当日补申报，记录原因 → 升级 CEO（当日）

7. 衡量指标

  • 按期申报率：按期完成申报的主体税种数 / 应申报数，目标 100%
  • 更正申报次数：目标 0 次/季度
  • 确认时效：提交确认到回复的小时数，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：季中升级一般纳税人，申报表需手工填写更正，身份变更没有提前预案｜依据：「财务部」2026-06
  • 现象：进项抵扣与发票不匹配，需反复查找，缺进项勾选核对表｜依据：「财务部」2026-06、「财务部」2026-08
  • 现象：测算、确认、申报都依赖单人，无复核与备岗｜依据：「财务部」2026-08、「财务部」2026-09

9. 分支变体

  • 小规模纳税人：按季申报增值税，无进项抵扣
  • 一般纳税人：按月申报，需进项勾选；季中升级当月注意申报表口径
  • 多主体：各主体分别测算、分别确认，测算摘要按主体分列

10. 待确认问题

  • 税额确认人是否固定为 CEO？是否需要改为飞书审批留痕而非群内回复？
  • 税负率控制目标（各主体）是否有成文口径？
  • 代账会计目前还承担哪些主体的申报？
  • 申报复核与备岗由谁承担？
FIN-36审计、尽调与投标财务资料准备待优化250

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：年度审计、融资尽调、投标或申报需要经审计财务报告或成套财务资料时，从需求确认到资料提交的全过程
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，对外提交前合规检查）、销售/人事等业务部门负责人（当前：待指定，补票与访谈）、政策申报负责人（当前：王蕊·推断待确认，政府补助资料）；兜底——CEO
  • 核心流程：① 接收需求（用途、截止日、口径）→ ② 发资料清单 → ③ 资料收集与缺票催收 → ④ 差异调账与三表勾稽 → ⑤ 配合审计访谈 → ⑥ 管理层合规检查 → ⑦ 出具提交 → ⑧ 归档
  • 交付结果：审计报告或尽调/投标财务资料包（报表、序时账、科目余额表、申报表、银行流水、合同、补充说明），提交记录与归档
  • 状态依据：「财务部」2026-06～08 约 20 次讨论，有审计资料清单但一次性运动式推进，期初数勾稽不上需重做、缺票催办、政府补助 3 项无负责人

1. 场景判定

  • 触发条件：年度审计启动；投资方尽调；投标/供应商入库/政策申报要求经审计财务报告或财务资料
  • 典型说法：「市场那边投标需要经审计的财务报告」「按审计资料清单完成 3 家公司审计资料整理」「政府补助 3 项尚未确认具体负责人」
  • 判断问题：是否需要对外提供财务数据或报告？是否需要第三方审计机构出具意见？
  • 不归本流程管：标书整体编制 → 请走 SAL-22；申报基础资料与口径 → 请走 POL-03；研发费用归集 → 请走 FIN-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资料统筹 清单、调账、勾稽、对接审计机构 R 财务负责人（当前：黄梦婷·推断待确认）
对外审批 对外提交前检查合规硬伤并批准 A CEO（当前：邴龙志·推断待确认）
业务资料 补发票、合同、接受审计访谈 C 销售/人事等部门负责人（当前：待指定）
政府补助 补助项目文件、验收与资金用途说明 C 政策申报负责人（当前：王蕊·推断待确认）
需求方 提出用途、截止日、格式要求 I 投标/融资对接人（当前：待指定）

3. 办之前请准备

  • 需求说明：用途（审计/尽调/投标）、涉及主体、所属期间、截止日、是否需审计机构盖章
  • 审计资料清单（申报表、银行流水与对账单、合同台账、记账凭证、固定资产与研发项目资料）
  • 上一期审计报告与期末数，用于期初勾稽
  • 缺票清单、政府补助项目清单及负责人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记需求：用途、主体、期间、截止日、格式 财务负责人 收到需求当日 多维表格 需求登记 🔧飞书固化
2 按模板生成资料清单并分派到人 财务负责人 1 个工作日内 飞书任务 分派任务 🔧飞书固化
3 业务部门补交发票、合同、补助资料 各部门负责人 分派后 3 个工作日内 缺票看板 补交资料 🔧飞书固化
4 差异调账，编制补充说明 财务负责人 截止日前 10 个工作日 财务系统 调账凭证、说明 👤人工判断
5 科目余额表、序时账、报表三方勾稽，核对期初数 财务负责人 截止日前 7 个工作日 勾稽核对表 勾稽结果 🤖自动化
6 安排审计访谈（销售、人事等） 财务负责人 审计机构要求后 2 个工作日内 飞书日程 访谈记录 🔧飞书固化
7 对外提交前请管理层检查合规硬伤 CEO 截止日前 3 个工作日 飞书审批 审批记录 👤人工判断
8 提交审计机构/需求方，资料包与报告归档 财务负责人 审批后 1 个工作日内 飞书云盘 提交记录、归档 🔧飞书固化

5. 交付物与模板

  • 交付物：审计报告或财务资料包、补充说明、勾稽核对表、提交记录
  • 建议模板/表单：审计资料目录（资料名称、主体、期间、负责人、状态、存放链接）；缺票看板（单据号、金额区间、业务部门、责任人、催收次数、截止日）；勾稽核对表（科目、期初、本期借贷、期末、报表数、差异、调整说明）

6. 异常与升级

  • 期初数勾稽不上 → 追溯上一期账务，必要时联系原代账/审计机构 → 2 个工作日内报 CEO
  • 业务部门 3 个工作日未补票 → 看板标红并通知部门负责人 → 升级 CEO（第 5 个工作日）
  • 资料项无负责人（如政府补助）→ 财务提名、CEO 指定 → 1 个工作日内
  • 截止日无法满足 → 提前 5 个工作日告知需求方并协商延期 → 升级 CEO

7. 衡量指标

  • 资料准备周期：需求登记到提交的工作日数，目标审计 ≤ 15 天、投标 ≤ 5 天（已有当年审计报告时）
  • 勾稽返工次数：每次项目中重做报表次数，目标 0
  • 缺票数：资料准备期缺票张数，目标逐期下降

8. 低效诊断

  • 现象：期初数勾稽不上，报表重做，日常账务底子不规范，审计时集中补救｜依据：「财务部」2026-07
  • 现象：缺票需逐一催办，无缺票看板｜依据：「财务部」2026-07、「财务部」2026-08
  • 现象：政府补助等资料项没有明确负责人，职责不清｜依据：「财务部」2026-08
  • 现象：投标急需审计报告时才启动，没有提前准备当年度审计报告｜依据：「财务部」2026-07

9. 分支变体

  • 年度审计：多主体并行，按审计机构清单准备，含访谈
  • 融资尽调：范围更广（股权、合同、诉讼），需与法务协同，资料对外前须管理层批准
  • 投标：通常只需最近年度审计报告与财务报表，时效要求高，需求来自销售

10. 待确认问题

  • 年度审计固定在每年几月启动？审计机构是否固定？
  • 对外提交前的合规检查是否固定由 CEO 审批？
  • 政府补助资料归财务还是政策申报岗？
  • 是否建立常态化缺票看板，避免审计时集中补票？
FIN-37财务人员交接、代账交接与整顿期汇报待优化250

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：财务人员更换，或代账公司/异地主体（武汉、苏州等）账务转回内部时，完成交接、建账、补账，并在整顿期定期汇报进度
  • 负责人：主责——财务负责人（接手方，当前：黄梦婷·推断待确认）；协同——原财务人员（移交方，当前：祁航·推断待确认）、代账会计（当前：待指定）、CEO（当前：邴龙志·推断待确认，下达交接与跟进汇报）；兜底——CEO
  • 核心流程：① 下达交接指令 → ② 移交清单（账户、税务、社保公积金、网银、海外收付款）→ ③ 代账资料逐项核对 → ④ 建账（科目、期初、辅助核算）→ ⑤ 差异调账与勾稽 → ⑥ 补做往期账务 → ⑦ 整顿期日报/周报 → ⑧ 交接确认签字
  • 交付结果：双方签字的交接清单、完整的资料与权限移交、内部建好的账套（期初平衡）、整顿期汇报记录
  • 状态依据：「财务部」2026-03 起有交接指令与交接资料清单，整顿期日报稳定执行；但「财务部」2026-05 核对发现资料不全、银行余额不对、纸质凭证缺发票附件，补账调账返工多

1. 场景判定

  • 触发条件：财务岗位人员离职/调岗/新入职接手；代账公司合同终止或主体账务转内部；新并入主体需建账
  • 典型说法：「把你这边的财务工作逐步交接给新财务」「初步核对发现资料不全，银行余额不对」「每天写一个简单的工作汇报，方便我们时刻跟进」
  • 判断问题：是否涉及账务、账户权限、税务社保等责任的转移？是否需要在内部重新建账？
  • 不归本流程管：一般员工离职交接 → 请走 HR-27；日常日报/周报机制 → 请走 CEO-12；审计调账 → 请走 FIN-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
接手方 核对资料、建账、调账补账、整顿期汇报 R 财务负责人（当前：黄梦婷·推断待确认）
移交方 按清单移交资料、账户与权限，答疑 R 原财务人员（当前：祁航·推断待确认）
代账方 提供账套、凭证、申报记录 C 代账会计（当前：待指定）
监交与跟进 下达指令、监督交接、阅汇报 A CEO（当前：邴龙志·推断待确认）
人事/法务 社保公积金账户变更、代账合同终止 C 人事负责人（当前：黄莹·推断待确认）、法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 交接清单模板（见第 5 节）与代账公司交接资料清单
  • 各主体银行账户、U 盾/网银权限、电子税务局、社保、公积金、个税系统账号的权限变更方式（不在清单中写密码）
  • 截至交接日的银行对账单与余额
  • 纸质凭证、合同原件、发票的存放位置
  • 海外收付款操作说明与形式发票模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 下达交接指令，明确交接截止日与监交人 CEO 人员变动确认当日 飞书群/任务 交接任务 🔧飞书固化
2 移交方按清单整理资料，完成账户与权限变更 原财务人员 指令后 5 个工作日内 交接清单 移交资料 🔧飞书固化
3 向代账公司获取交接资料清单，逐项核对完整性 财务负责人 收到资料后 3 个工作日内 交接资料清单 缺失清单 👤人工判断
4 建账：科目体系、期初余额、辅助核算 财务负责人 核对后 5 个工作日内 财务系统 账套 👤人工判断
5 银行余额、往来、税务数据差异调账，三方勾稽 财务负责人 建账后 10 个工作日内 勾稽核对表 调账凭证 🤖自动化
6 补做往期账务，纸质凭证缺发票的列清单转 FIN-12 财务负责人 按补账计划，每周汇报 财务系统 补账记录 👤人工判断
7 整顿期汇报：前 2 周每日、之后每周 2 次 财务负责人 每日 18:30 前 / 每周二、五 飞书汇报/多维表格 日报/周报 🔧+🤖
8 交接完成确认，双方与监交人签字，结束整顿期 三方 账务勾稽通过后 2 个工作日内 飞书审批 签字清单 🔧飞书固化

5. 交付物与模板

  • 交付物：交接清单（三方签字）、代账资料核对表、账套与期初余额表、调账记录、整顿期汇报记录
  • 建议模板/表单：财务交接清单（主体、银行账户与网银权限、U 盾、税务账号、社保公积金账号、个税系统、海外收付款权限〔经办/复核〕、凭证与发票存放、合同原件、未结事项、待付款、待开票、已知差异、移交人、接手人、监交人、日期）；整顿期日报（日期、完成事项、问题与阻塞、需协调事项、明日计划）
  • 参考资料：海外收付款操作说明（汇入汇款确认、结汇交易编码、汇出汇款单据要求，超等值 5 万美元需税务备案表）；形式发票模板

6. 异常与升级

  • 资料不全或余额对不上 → 列缺失清单发移交方/代账方，3 个工作日内补齐 → 逾期升级 CEO
  • 移交方已离职无法联系 → 由 CEO 协调，必要时向银行、税务局调取记录（1 周内）
  • 纸质凭证缺发票附件 → 列清单转 FIN-12 补票，无法补的出具情况说明 → 报 CEO
  • 权限未能在截止日变更 → 当日报 CEO，暂停相关账户操作

7. 衡量指标

  • 交接完成周期：指令下达到三方签字的工作日数，目标 ≤ 20 个工作日（含代账交接）
  • 资料完整率：首次移交即完整的清单项 / 总项，目标 ≥ 90%
  • 期初平衡：建账后余额与银行对账单差异，目标 0

8. 低效诊断

  • 现象：代账交接资料不全、银行余额不对，交接前没有按清单预核对｜依据：「财务部」2026-05
  • 现象：异地主体纸质凭证多笔报销无发票附件，需补账调账｜依据：「财务部」2026-05
  • 现象：整顿期日报量大、同一内容重复发送、无结构化字段，难以聚合｜依据：「财务部」2026-04、「财务部」2026-09
  • 现象：财务关键工作集中于单人，交接期间存在断档｜依据：「财务部」2026-03

9. 分支变体

  • 个人岗位交接：重点在账户权限、未结事项与资料移交
  • 代账公司交接：重点在账套、凭证、申报记录的完整性核对
  • 主体建账（武汉、苏州等异地主体）：需新建科目体系与期初，纸质凭证需寄回或扫描
  • 整顿期汇报：前 2 周每日；体系化后每周 2 次；跨部门内容同步总经办

10. 待确认问题

  • 整顿期何时结束、由谁判定？目前日报已持续数月，是否改为 CEO-12 周报？
  • 交接监交人是否固定为 CEO，还是综合部负责人？
  • 武汉、苏州主体是否已全部转为内部记账？还有哪些主体由代账公司负责？
  • 海外收付款的经办/复核人当前分别是谁？
FIN-38主体工商税务登记变更与注销待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：子公司注销（含简易注销）、营业执照补领、办税员添加等主体工商税务登记事项的材料准备、办理与结果归档
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认，决策与签字）、COO（当前：常元和·推断待确认，结果接收方/签字人，推断）、法务负责人（当前：李瑶·推断待确认，决议文件）、总经办（当前：田杰·推断待确认，证照归档）；兜底——CEO
  • 核心流程：① 事项发起与决策 → ② 材料清单与决议 → ③ 税务前置申报/清算 → ④ 取得清税证明 → ⑤ 工商办理（公示）→ ⑥ 银行、社保等配套注销/变更 → ⑦ 回执归档并通知相关人
  • 交付结果：办理完成的登记结果（注销回执/新执照/办税员权限）、扫描件归档于证照台账，相关人确认已收到
  • 状态依据：「财务部」2026-05～10 推进子公司简易注销等事项约 5 次，无成文流程与清单，结果回执需另行单独转发给相关人，群内通知未触达

1. 场景判定

  • 触发条件：管理层决定注销某主体；营业执照遗失/损毁需补领；新增办税员或变更办税人员
  • 典型说法：「推进 XX 公司简易注销事项」「XX 公司注销回执」「营业执照需要补领」
  • 判断问题：是否需要到税务局或市场监管部门办理登记类手续？是否改变主体存续或登记信息？
  • 不归本流程管：增资扩股、新设机构、工商变更 → 请走 GEN-15；证照年检与年报 → 请走 GEN-14；股东会决议本身 → 请走 CEO-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
经办 准备材料、税务申报、工商办理、归档 R 财务负责人（当前：黄梦婷·推断待确认）
决策 决定注销/变更，签署决议 A CEO（当前：邴龙志·推断待确认）
签字/接收 法定代表人签字、接收回执（推断） C COO（当前：常元和·推断待确认）
决议文件 出具股东决定、清算报告等 C 法务负责人（当前：李瑶·推断待确认）
证照归档 更新证照台账 I 总经办（当前：田杰·推断待确认）

3. 办之前请准备

  • 事项类型与理由；主体营业执照、章程、股东信息
  • 注销：未结债权债务、银行账户、社保公积金账户、发票结存情况；确认无欠税、无未结发票
  • 补领：遗失说明或损毁原件
  • 办税员添加：新办税员身份信息与实名认证方式（不在群内发送证件号）
  • 法定代表人、股东的签字/电子签认证安排

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起事项登记，管理层确认是否办理 财务负责人、CEO 发起后 3 个工作日内 飞书审批 审批记录 🔧飞书固化
2 按事项类型生成材料清单，法务出具决议文件 财务负责人、法务负责人 审批后 5 个工作日内 主体生命周期 checklist 材料包 🔧飞书固化
3 注销：完成前置申报、清算所得税申报，缴销发票 财务负责人 材料齐后 10 个工作日内 电子税务局 申报表 👤人工判断
4 取得清税证明 财务负责人 申报完成后按税务局时限 电子税务局 清税证明 👤人工判断
5 工商办理：简易注销公示（20 天）后申请注销；或补领执照、添加办税员 财务负责人 公示期满后 3 个工作日内 市场监管平台 回执/新执照 👤人工判断
6 配套注销/变更：银行账户、社保公积金账户 财务负责人、人事负责人 工商完成后 10 个工作日内 银行、社保系统 注销证明 👤人工判断
7 回执归档到证照台账，在飞书任务中 @ 相关人确认收到 财务负责人 取得回执当日 飞书任务、云盘 归档链接、确认记录 🔧飞书固化

5. 交付物与模板

  • 交付物：审批记录、决议文件、申报表、清税证明、注销回执/新执照、证照台账更新记录
  • 建议模板/表单：主体生命周期 checklist（主体名称、事项类型、发起日、决策人、材料清单、税务状态、工商状态、银行/社保状态、公示起止日、回执链接、相关人确认）

6. 异常与升级

  • 税务发现欠税、未缴销发票或异常 → 先补缴/缴销，无法当期处理的报 CEO（2 个工作日内）
  • 简易注销公示期被提出异议 → 转一般注销程序，法务评估 → 升级 CEO（1 周内）
  • 法定代表人/股东签字或认证无法按时完成 → 1 个工作日内报 CEO 协调
  • 相关人 2 个工作日未确认收到回执 → 电话或加急提醒（GEN-05）

7. 衡量指标

  • 办理周期：简易注销从决策到取得回执的自然日，目标 ≤ 60 天（含公示期）
  • 结果送达率：回执归档并经相关人确认的事项数 / 总事项数，目标 100%
  • 配套遗漏：注销后仍未关闭的银行/社保账户数，目标 0

8. 低效诊断

  • 现象：注销等登记事项每次临时处理，无材料清单与进度台账｜依据：「财务部」2026-07
  • 现象：结果回执发群后相关人未看到，需另行单独转发，缺少确认机制｜依据：「财务部」2026-10
  • 现象：事项跨度数月，进度只散落在日报中，难以追踪｜依据：「财务部」2026-05、「财务部」2026-10

9. 分支变体

  • 简易注销：无债权债务、无欠税，适用前置申报 → 清算所得税 → 清税证明 → 工商公示 → 注销
  • 一般注销：需成立清算组、登报公告，周期更长，法务深度参与
  • 营业执照补领、办税员添加：不涉及清算，按登记机关材料要求办理即可

10. 待确认问题

  • 注销/变更类事项的决策人是否固定为 CEO？
  • 回执接收人是谁（法定代表人还是总经办）？是否统一由总经办归档证照？
  • 本流程是否与 GEN-15 合并，由综合部统一归口？
  • 简易注销的子公司当前进度如何，是否还有银行或社保账户未关闭？
FIN-39资金计划与临时周转借款待新建推断75

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频1 × 耗3 × 跨5 × 险5

  • 适用场景：按月编制滚动资金计划，预判阶段性资金缺口；确需通过借款或银行授信等方式短期周转时，完成方案审批、协议签署、到账入账与还款跟踪
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——CEO（当前：邴龙志·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 滚动资金计划与预警 → ② 缺口测算 → ③ 方案比选（股东借款/外部机构借款/银行授信）→ ④ 审批 → ⑤ 协议签署与用印 → ⑥ 到账入账 → ⑦ 还款计划与跟踪 → ⑧ 结清归档
  • 交付结果：滚动资金计划、经审批的周转方案、签署的借款或授信协议、到账回单与入账凭证、还款台账及结清证明
  • 状态依据：未见成文的资金计划、周转借款审批规则与协议模板；本条按财务常规流程补全，需财务负责人确认后执行

1. 场景判定

  • 触发条件：滚动资金计划显示未来 60 天内可用资金低于公司设定的安全线；计划内资金流入时间发生变化；大额支出前需确认资金安排
  • 判断问题：资金是否来自集团外部（股东、机构、银行）？是否形成公司对外负债？
  • 不归本流程管：集团内主体之间的借款或注资 → 请走 FIN-33；融资协议本身与股东会决议 → 请走 LEG-06；协议用印 → 请走 LEG-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
财务负责人 维护滚动资金计划、测算缺口、比选方案、入账与还款跟踪 R 财务负责人（当前：黄梦婷·推断待确认）
CEO 审批周转方案（金额、利率、期限、出借方） A CEO（当前：邴龙志·推断待确认）
法务负责人 起草/审核借款或授信协议，评估关联交易与合规要求 R（协议） 法务负责人（当前：李瑶·推断待确认）
综合部负责人 协议用印与归档 C 综合部负责人（当前：赵雪冰·推断待确认）
董事会 超出 CEO 权限的方案决议 I 董事会（当前：待指定）

3. 办之前请准备

  • 滚动 13 周资金计划（期初余额、确定流入、确定流出、计划内流入的预计日期）
  • 缺口金额、需要的时间点、预计还款来源与日期
  • 候选方案：股东借款、外部机构借款、银行授信，各自成本与条件
  • 出借方主体信息与收付款方式；涉及关联方的，准备关联交易说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 每周更新滚动资金计划，低于安全线自动预警 财务负责人 每周一 多维表格 + 机器人 资金计划、预警 🔧+🤖
2 测算缺口金额、时点、还款来源 财务负责人 预警后 1 个工作日内 资金计划表 缺口测算 👤人工判断
3 比选方案并提交审批（出借方类型、金额、利率、期限、担保） 财务负责人 测算后 2 个工作日内 飞书审批 周转审批单 🔧飞书固化
4 审批方案；超出权限的报董事会决议 CEO 1 个工作日内 飞书审批 审批记录 👤人工判断
5 起草/审核协议并提交用印 法务负责人 审批后 2 个工作日内 合同模板、用印审批 签署版协议 🔧飞书固化
6 确认到账、入账并留存回单 财务负责人 到账后 1 个工作日内 网银 回单、凭证 👤人工判断
7 登记还款台账，设置到期前 15 天提醒 财务负责人 入账当日 多维表格 还款台账 🔧飞书固化
8 按期还款，取得结清确认并归档 财务负责人 到期日前 网银、云盘 结清证明 🔧+👤

5. 交付物与模板

  • 交付物：滚动资金计划、周转审批单、借款或授信协议、到账回单与凭证、还款台账、结清证明
  • 建议模板/表单：周转审批单（缺口原因、金额、出借方类型、利率、期限、还款来源、担保方式、是否关联交易、附件：资金计划截图）；还款台账（编号、出借方类型、本金、利率、到账日、到期日、已还、未还、提醒人、状态）

6. 异常与升级

  • 未经审批或无协议的资金到账 → 当日报财务负责人与法务负责人，3 个工作日内补齐审批与协议，无法补齐的原路退回 → 升级 CEO
  • 方案涉及关联方 → 法务负责人评估关联交易披露要求后再签署（2 个工作日内）
  • 方案超出 CEO 审批权限 → 报董事会决议后再执行
  • 到期无法按期还款 → 到期前 15 天与出借方协商展期并签补充协议 → 升级 CEO

7. 衡量指标

  • 预警提前量：资金缺口被资金计划提前识别的天数，目标 ≥ 30 天
  • 留痕完整率：有审批 + 协议 + 回单的周转笔数 / 总笔数，目标 100%
  • 逾期还款笔数：目标 0

8. 低效诊断

  • 现象：未见滚动资金计划，资金缺口难以提前识别｜依据：（推断）
  • 现象：周转借款缺少统一的审批规则与协议模板，留痕不完整｜依据：（推断）
  • 现象：资金事务未明确财务、法务的参与节点｜依据：（推断）

9. 分支变体

  • 股东借款：按关联交易处理，需协议与披露，利率参照市场
  • 外部机构借款：法务审核协议条款，财务核对资金来源与收款主体
  • 银行授信：提前申请应急授信额度，作为常备方案

10. 待确认问题

  • 资金安全线定为多少个月运营支出？由谁审批？
  • 周转借款审批权限：哪一档以上需董事会决议？[阈值待财务确认]
  • 是否已有银行应急授信？是否需要提前申请？
  • 资金计划的编制频率与报送对象是否需要纳入月度经营会？
FIN-40银行账户、网银 UKey 管理与付款复核待新建推断80

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨2 × 险5

  • 适用场景：各主体银行账户开立、变更、销户，网银 UKey 与密码保管、授权变更，以及每笔对公付款的制单—复核分离时适用
  • 负责人：主责——出纳（当前：待指定）；协同——付款复核人（当前：待指定）、法务（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）
  • 核心流程：① 账户台账 → ② 开户/变更/销户审批 → ③ UKey 分离保管 → ④ 制单 → ⑤ 复核授权 → ⑥ 回单核对 → ⑦ 月度余额对账
  • 交付结果：多主体银行账户台账、UKey 保管登记、付款制单与复核记录、月度银行余额调节表
  • 状态依据：已有 FIN-01（对公采购付款审批）、FIN-15（支付通道与收款权限开通）覆盖部分环节，本条补齐银行账户、网银 UKey 管理与付款制单—复核分离（推断）

1. 场景判定

  • 触发条件：新主体设立需开户；预留印鉴、操作员变更；UKey 遗失或人员离职；每笔对公付款
  • 典型说法：「子公司要开个基本户」「UKey 在谁手上」「这笔款谁来复核」
  • 判断问题：是否涉及资金实际划出或账户权限变化？
  • 不归本流程管：支付通道/商户号 → 请走 FIN-15；付款业务审批 → 请走 FIN-01；关联主体资金划转 → 请走 FIN-33

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
制单 按已审批单据制单、取回单 R 出纳（当前：待指定）
复核授权 核对收款方、金额与审批一致后授权 R 付款复核人（当前：待指定）
账户审批 开户、销户、操作员与权限变更 A（升级） CEO（当前：邴龙志·推断待确认）
印鉴与证照 用印配合 C 法务（当前：待指定）
兜底 规则维护、复核人指定与例外处理 A 财务负责人（当前：黄梦婷·部门报送人）

3. 办之前请准备

  • 各主体营业执照、法人身份信息、预留印鉴（按 LEG-09 用印）
  • 账户清单（主体、开户行、账户性质、操作员、UKey 持有人）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立并维护银行账户与 UKey 台账 出纳 本流程确认后 10 个工作日内 飞书多维表格（限权限） 台账 🔧飞书固化
2 开户/变更/销户提交审批 出纳 需求发生后 2 个工作日内 飞书审批 审批结论 🔧飞书固化
3 制单 UKey 与复核 UKey 分人保管 出纳+付款复核人 持续 保险柜 保管登记 👤人工判断
4 依据已审批单据制单 出纳 审批通过后 1 个工作日内 网银 待复核付款 👤人工判断
5 复核收款方账户、金额与审批一致后授权 付款复核人 制单当天 网银 已付款 👤人工判断
6 下载回单并关联审批单 出纳 付款后 1 个工作日内 飞书审批附件 回单 🤖+👤（自动匹配，人工核对）
7 月末银行余额核对 出纳 每月结束后 3 个工作日内 网银+账簿 余额调节表 🤖+👤

5. 交付物与模板

  • 交付物：账户台账、UKey 保管登记、付款复核记录、余额调节表
  • 建议模板/表单：账户台账字段（主体、开户行、账号末四位、账户性质、制单人、复核人、UKey 编号与保管人、网银限额、开户日期、状态）

6. 异常与升级

  • UKey 遗失或持有人离职 → 当天挂失或变更操作员，报财务负责人
  • 收到变更收款账户的邮件或消息 → 电话回拨供应商核实后再付款（防诈骗）
  • 发现未经审批的付款 → 立即报财务负责人与 CEO
  • 升级条件：银行账户开立/销户、网银操作员与 UKey 授权变更、网银限额调整 → CEO 作为 A（升级）审批；日常制单复核与例外处理由财务负责人负责

7. 衡量指标

  • 付款复核覆盖率 = 经双人复核的付款笔数 / 总付款笔数，目标 100%
  • 银行余额对账按期完成率：目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在一人掌握全部 UKey、收款账户被冒充变更导致资金损失的风险（推断）

9. 分支变体

  • 各主体分别设台账与复核人；外币账户付款同时遵循 FIN-04

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各主体目前有几个银行账户？UKey 由谁保管？
  • 网银是否已设置单笔/日累计限额与复核级别？
FIN-41月度结账与管理报表待新建推断144

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗4 × 跨3 × 险4

  • 适用场景：每月结束后，对各主体完成费用、收入、成本、往来的入账与核对，出具财务报表与管理报表供管理层决策时适用
  • 负责人：主责——总账会计（当前：待指定）；协同——出纳（当前：待指定）、各业务部门（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）
  • 核心流程：① 结账日历 → ② 业务单据截止 → ③ 银行与支付渠道对账 → ④ 收入成本确认与费用计提 → ⑤ 往来核对 → ⑥ 关账出表 → ⑦ 管理报表与分析
  • 交付结果：各主体月度资产负债表、利润表、管理报表（收入、毛利、模型成本、人力成本、现金余额）
  • 状态依据：已有 FIN-24（支付渠道对账）、FIN-30（云/模型成本归集）、FIN-34（子公司营收汇报）覆盖分散的对账与统计环节，本条补齐统一的月结时间表、关账出表与管理报表（推断）

1. 场景判定

  • 触发条件：每月最后一个工作日起进入月结
  • 典型说法：「这个月花了多少钱」「上个月毛利是多少」「报销单什么时候截止」
  • 判断问题：是否是月度周期性的全账套关账与出表？
  • 不归本流程管：税务申报 → 请走 FIN-35；子公司营收汇报 → 请走 FIN-34；支付渠道日对账 → 请走 FIN-24；云成本归集 → 请走 FIN-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
关账出表 入账、计提、出表 R 总账会计（当前：待指定）
资金对账 银行与支付渠道余额核对 R 出纳（当前：待指定）
单据提交 按截止日提交报销、签收单、合同 C 各业务部门（当前：待指定）
审核 审核报表并向管理层汇报 A 财务负责人（当前：黄梦婷·部门报送人）

3. 办之前请准备

  • 本月报销与付款单据、收入合同台账（FIN-21）、交付签收单（X-DLV-29）
  • 云厂商与模型账单（FIN-26、FIN-30）、工资表（HR-15）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布月结日历与单据截止日 总账会计 每月 25 日前 飞书群 月结通知 🔧飞书固化
2 业务部门提交单据截止 各业务部门 次月第 2 个工作日 飞书审批 单据 🔧飞书固化
3 银行与支付渠道余额核对 出纳 次月第 3 个工作日 网银/渠道后台 调节表 🤖+👤
4 收入成本确认、费用计提与分摊 总账会计 次月第 5 个工作日 财务软件 凭证 🔧+🤖
5 往来与内部关联交易核对 总账会计 次月第 6 个工作日 财务软件 往来核对表 👤人工判断
6 关账出具各主体报表 总账会计 次月第 7 个工作日 财务软件 财务报表 🔧飞书固化
7 编制管理报表并汇报 财务负责人 次月第 10 个工作日 飞书文档 管理报表 🔧+🤖

5. 交付物与模板

  • 交付物：各主体财务报表、合并口径管理报表、月结检查清单
  • 建议模板/表单：管理报表（收入按产品线、毛利、模型/云成本、人力成本、费用前十、现金余额、应收账龄、预算执行偏差）

6. 异常与升级

  • 单据逾期未交 → 计入下月并通知部门负责人；重大金额报财务负责人
  • 对账差异未查明 → 挂账并在 5 个工作日内追查，超期报财务负责人

7. 衡量指标

  • 关账时效：次月第几个工作日完成关账，目标 ≤ 7
  • 跨期调整次数：每月目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在管理层无法按月掌握成本收入、跨期入账影响税务与审计的风险（推断）

9. 分支变体

  • 代账主体按代账机构时间表获取报表并纳入合并管理报表；子公司由各主体会计关账

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 当前使用的财务软件是哪一个？各主体是否都在内部做账？
  • 管理报表需要哪些口径（按产品线还是按主体）？
FIN-42年度企业所得税汇算清缴与研发费用加计扣除待新建推断75

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨3 × 险5

  • 适用场景：每年 1 月起至 5 月 31 日前，各主体完成上一年度企业所得税汇算清缴、研发费用加计扣除及高新技术企业相关指标核对时适用
  • 负责人：主责——税务会计（当前：待指定）；协同——研发项目负责人（当前：待指定）、人事（当前：待指定）、外部税务师（如有）；兜底——财务负责人（当前：黄梦婷·部门报送人）
  • 核心流程：① 制定汇算计划 → ② 年度账务调整 → ③ 研发费用辅助账与项目资料核对 → ④ 纳税调整测算 → ⑤ 管理层确认 → ⑥ 申报与缴补税 → ⑦ 资料留存备查
  • 交付结果：各主体年度企业所得税申报表、研发费用辅助账与备查资料、补退税记录
  • 状态依据：已有 FIN-31（研发项目立项与费用归集）、FIN-35（月度税务申报）覆盖部分环节，本条补齐年度企业所得税汇算清缴与研发费用加计扣除的组织安排（推断）

1. 场景判定

  • 触发条件：年度结账完成后；税务机关提醒；需享受研发加计扣除或高新企业优惠
  • 典型说法：「今年汇算清缴什么时候做」「研发费用能加计扣除多少」
  • 判断问题：是否为年度所得税申报？涉及哪些主体？
  • 不归本流程管：研发项目立项与费用归集 → 请走 FIN-31；月度/季度申报 → 请走 FIN-35；审计资料 → 请走 FIN-36；高新技术企业资质认定与年报 → 请走 POL-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
汇算执行 调整测算、申报 R 税务会计（当前：待指定）
研发资料 项目立项、工时、成果说明 C 研发项目负责人（当前：待指定）
人员数据 研发人员名单、工时与社保 C 人事（当前：待指定）
确认 确认税额与优惠口径 A 财务负责人（当前：黄梦婷·部门报送人）

3. 办之前请准备

  • 年度财务报表与账簿、全年发票与合同
  • 研发项目立项文件、研发工时记录、研发人员名单
  • 上年度汇算申报表与税务机关通知

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定各主体汇算计划与资料清单 税务会计 1 月 31 日前 飞书任务 汇算计划 🔧飞书固化
2 年度账务调整与结账 税务会计 2 月底前 财务软件 年度报表 👤人工判断
3 研发辅助账与项目资料核对 税务会计+研发项目负责人+人事 3 月 31 日前 文档 研发备查资料 🔧+🤖
4 纳税调整与税额测算 税务会计 4 月 15 日前 申报系统 测算表 👤人工判断
5 管理层确认税额与优惠口径 财务负责人 4 月 30 日前 飞书审批 确认结论 🔧飞书固化
6 申报并缴补税/申请退税 税务会计 5 月 31 日前（法定） 电子税务局 申报回执 🔧飞书固化
7 资料归档备查 税务会计 申报后 10 个工作日内 档案 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：申报表、纳税调整明细、研发费用辅助账、留存备查资料目录
  • 建议模板/表单：研发项目清单（项目名称、立项日期、负责人、参与人员、工时占比、费用类别、成果形式）

6. 异常与升级

  • 研发资料缺失 → 由研发项目负责人在 10 个工作日内补齐，否则不享受该项目加计扣除
  • 汇算结果需大额补税 → 提前报 CEO 并纳入资金计划（FIN-39）

7. 衡量指标

  • 按期申报率：各主体 5 月 31 日前完成申报，目标 100%
  • 研发加计扣除覆盖率 = 已享受加计扣除的合规研发项目 / 全部研发项目

8. 低效诊断

  • 聊天中未见相关流程，存在错过申报期、研发资料不足无法享受加计扣除、被税务机关调整补税的风险（推断）

9. 分支变体

  • 高新技术企业主体需同时核对研发费用占比、高新收入占比等指标；小型微利主体按对应优惠申报；代账主体由代账机构执行、内部复核

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 哪些主体是高新技术企业或计划申请？
  • 是否聘请外部税务师事务所出具鉴证报告？
FIN-43年度预算编制与执行分析待新建推断160

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗4 × 跨5 × 险4

  • 适用场景：年度/季度开始前编制各部门与各主体的收入、成本、费用、人力、算力预算，以及每月对比实际执行、超预算审批时适用
  • 负责人：主责——财务预算专员（当前：待指定）；协同——各部门负责人（当前：待指定）、人事（当前：待指定）、研发负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）
  • 核心流程：① 下发预算模板与假设 → ② 部门编报 → ③ 财务汇总平衡 → ④ 管理层审定 → ⑤ 预算分解发布 → ⑥ 月度执行分析 → ⑦ 超预算审批与季度调整
  • 交付结果：经审定的年度预算（按部门、主体、科目）、月度预算执行分析表
  • 状态依据：已有 HR-03（HC 申请与人力成本统计）、FIN-09（活动费用预算与归集）覆盖单项预算环节，本条补齐公司级年度预算编制与月度执行分析；模型与云成本波动大（推断）

1. 场景判定

  • 触发条件：年度规划（CEO-01）完成后；季度初调整；月度结账后执行分析；单项支出超预算
  • 典型说法：「明年各部门要报多少预算」「这个月模型成本超了」「这笔不在预算里能不能花」
  • 判断问题：是否涉及公司级或部门级预算额度的编制、调整或超支？
  • 不归本流程管：HC 与人力成本 → 请走 HR-03；活动费用 → 请走 FIN-09；市场条线计划与预算 → 请走 MKT-19（结果汇入本流程）；临时资金缺口 → 请走 FIN-39；规划目标 → 请走 CEO-01；月度经营分析会与经营决策 → 请走 CEO-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
组织汇总 模板、汇总、执行分析 R 财务预算专员（当前：待指定）
部门编报 提交本部门预算与说明 R 各部门负责人（当前：待指定）
人力预算 编制、薪酬与 HC 预算 C 人事（当前：待指定）
算力与云预算 模型、云资源、硬件预算 C 研发负责人（当前：待指定）
审定 年度预算审定、超出部门权限的调整 A CEO（当前：邴龙志·推断待确认）
兜底 预算规则维护、超预算审批复核 R 财务负责人（当前：黄梦婷·部门报送人）

3. 办之前请准备

  • 年度经营目标与重点项目（CEO-01）
  • 上年度实际支出与收入分析（FIN-41）
  • 预算模板（科目、主体、月度分解）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 下发预算模板与编制假设 财务预算专员 年度开始前 30 日 飞书多维表格 模板 🔧飞书固化
2 部门编报并说明依据 各部门负责人 下发后 10 个工作日内 多维表格 部门预算 👤人工判断
3 汇总平衡与差异沟通 财务预算专员 编报后 5 个工作日内 多维表格 汇总预算 🔧+🤖
4 管理层审定 CEO 年度开始前 会议 审定预算 👤人工判断
5 分解发布并配置到审批 财务预算专员 审定后 5 个工作日内 飞书审批 预算控制规则 🔧飞书固化
6 月度执行分析并推送部门负责人 财务预算专员 月结后 3 个工作日内 多维表格 执行分析表 🤖自动化
7 超预算审批与季度调整 部门负责人+财务负责人 发生时/季度初 飞书审批 调整记录 🔧飞书固化

5. 交付物与模板

  • 交付物：年度预算表、月度执行分析、预算调整记录
  • 建议模板/表单：预算表字段（主体、部门、科目、月份、预算数、实际数、差异、差异说明）

6. 异常与升级

  • 单科目执行率超预算一定比例（比例由部门确定）→ 预警部门负责人并报财务负责人
  • 模型/云成本单月异常增长 → 联动 FIN-28、FIN-30 排查（3 个工作日内）
  • 超预算或季度调整超出部门与财务负责人审批权限 → 报 CEO 审定（5 个工作日内）

7. 衡量指标

  • 预算编制按期完成率：目标 100%
  • 预算执行偏差率 = |实际 − 预算| / 预算，按部门月度监控

8. 低效诊断

  • 聊天中未见相关流程，存在支出无总量约束、模型与云成本失控、审批只看单笔不看总额的风险（推断）

9. 分支变体

  • 各主体单独编制并合并汇总；子公司预算报集团财务审核

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 预算按自然年还是按财年？按主体还是按部门优先？
  • 超预算审批权限如何分级？
FIN-44政府补助资金到账、专款核算与验收审计待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：科技项目、人才计划、上云补贴等政府补助资金到账后，进行确认、专款核算、按要求使用，并配合项目验收与专项审计时适用
  • 负责人：主责——总账会计（当前：待指定）；协同——政策申报专员（当前：待指定）、项目负责人（当前：待指定）；兜底——财务负责人（当前：黄梦婷·部门报送人）
  • 核心流程：① 到账识别 → ② 对应项目与资金性质确认 → ③ 设专项辅助核算 → ④ 按预算使用并留证 → ⑤ 定期执行报告 → ⑥ 验收/专项审计配合 → ⑦ 结余处理与归档
  • 交付结果：补助资金台账、专项核算明细、验收与审计资料、结余处理记录
  • 状态依据：已有 POL-04（科技项目申报）、POL-07（补贴申领资料归集）覆盖申报环节，本条补齐补助资金到账后的专款核算、使用跟踪与验收审计配合（推断）

1. 场景判定

  • 触发条件：银行收到政府部门来款；项目进入中期检查或验收；收到专项审计通知
  • 典型说法：「账上来了一笔财政款是哪个项目的」「项目验收要资金使用明细」
  • 判断问题：资金是否附有使用范围或验收要求？属于与资产相关还是与收益相关的补助？
  • 不归本流程管：项目申报 → 请走 POL-04；补贴申领资料归集 → 请走 POL-07；获批项目的执行跟踪与验收组织 → 请走 POL-15（本流程负责财务核算部分）；研发费用归集 → 请走 FIN-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
核算 到账识别、专项核算、报表 R 总账会计（当前：待指定）
项目对应 提供申报书、任务书、预算 C 政策申报专员（当前：待指定）
使用执行 按预算使用并提供佐证 R 项目负责人（当前：待指定）
审核 审核核算口径与验收资料 A 财务负责人（当前：黄梦婷·部门报送人）

3. 办之前请准备

  • 项目申报书、任务书/合同书、资金预算表、拨款文件
  • 到账银行回单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别到账并通知政策申报专员 总账会计 到账后 1 个工作日内 飞书群 到账通知 🔧飞书固化
2 确认对应项目、资金性质与使用要求 政策申报专员 通知后 2 个工作日内 补助台账 台账记录 👤人工判断
3 设立专项辅助核算 总账会计 确认后 3 个工作日内 财务软件 辅助核算项目 🔧飞书固化
4 支出时在审批单标注项目，留存佐证 项目负责人 每笔支出时 飞书审批字段 带项目标签的支出 🔧飞书固化
5 按季度出具资金使用执行表 总账会计 季度结束后 10 个工作日内 多维表格 执行表 🤖自动化
6 验收/专项审计资料准备与配合 总账会计+政策申报专员 通知后按要求时限 文档 审计资料包 👤人工判断
7 结余处理与资料归档 总账会计 验收结束后 10 个工作日内 档案 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：补助资金台账、专项核算明细、季度执行表、验收审计资料包
  • 建议模板/表单：补助台账字段（项目名称、主管部门、承担主体、资金性质、到账日期、预算科目、已使用、剩余、验收时间、是否需专项审计、负责人）

6. 异常与升级

  • 来款无法对应项目 → 3 个工作日内联系拨款部门核实，未核实前不得使用
  • 实际支出与预算科目偏离 → 报财务负责人评估调整程序（5 个工作日内）

7. 衡量指标

  • 到账识别时效：到账到确认项目的工作日数，目标 ≤ 3
  • 验收资料一次通过率：目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在补助资金混用、验收时无法提供使用明细被要求退回资金的风险（推断）

9. 分支变体

  • 联合申报项目需与合作单位分别核算并按约定划拨；不同主体承担的项目在对应主体核算

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 目前在执行的补助项目有哪些？是否都有专项核算？
  • 验收审计是否委托外部会计师事务所？

LEG 法务

报送人：李瑶 · 综合 · 33 条 · 已有 0 / 待优化 12 / 待新建 21
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
LEG-01合同模板库建设、版本维护与发布产品、价格、税点、渠道政策发生变化，或新业务、新系统（渠道系统、线上充值）上线需要合同模板时，由法务修订或新建模板，定稿后编号发布到唯一模板库，旧版同时作废主责——法务负责人（当前：李瑶·推断待确认）；协同——模板版本维护人/渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、总经办（当前：田杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交模板变更/新建申请 → ② 法务评估影响并列出待定规则 → ③ 业务、财务答复规则 → ④ 法务修订 → ⑤ 销售/产品/财务会签 → ⑥ 定版编号入库、旧版作废 → ⑦ 发布并同步系统模板 → ⑧ 抽查使用情况唯一模板库中的定稿模板（带版本号、生效日期、变更摘要、适用场景），发布通知，以及渠道系统、电子签中同步更新的模板待优化225
LEG-02我方签约主体选择与印章信息登记起草合同或报价、申请用印、试用转正式时，集团内有多个主体（模态跃迁、鼎慧、渠道公司等）都可能签约，需要定下我方签约主体及结算路径；主体资料与印章信息需要在系统里新增、变更或关闭时主责——法务负责人（当前：李瑶·推断待确认）；协同——起草合同的销售（当前：吴琪·推断待确认）、产品/鼎慧负责人（当前：杨萌·推断待确认）、财务（当前：待指定）、总经办（当前：田杰·推断待确认）、CMS 研发（当前：裴建武·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 起草前填写主体判断要素 → ② 按主体决策表初判 → ③ 财务确认收款、开票与集团内采购路径 → ④ 法务确认 → ⑤ 例外情形审批 → ⑥ 合同审批单选主体并带出资料 → ⑦ 主体与印章主数据维护每份合同的主体确认结论（含集团内采购/结算安排），以及系统内准确的“签约主体—印章”主数据待新建120
LEG-03销售合同审查与多方会签销售或商务起草、或客户修改销售类合同（LeapCore 一体机、行业版、渠道代理、试用、词元充值、设备借用、战略框架）后，在签署前由法务、产品、技术/交付、财务会审定稿主责——法务负责人（当前：李瑶·推断待确认）；协同——销售/商务起草人（当前：闫登辉、杜中瑞、时建、杨朋伟、陈名赞、汪家诺、吴琪、刘昱潇·推断待确认）、产品负责人（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 硬件审核（当前：杨明学·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 按现行模板起草并自查 → ② AI 预审并判定通道 → ③ 提交审核 → ④ 标准合同快速核对 / 非标合同多方并联会审 → ⑤ 起草人修订留痕 → ⑥ 非标与让步终审 → ⑦ 提交飞书合同审批并用印签署 → ⑧ 归档经会审定稿、与报价单/配置单一致的销售合同，飞书合同审批记录，修订记录与审查报告待优化375
LEG-04采购/服务及其他对外合同、承诺函起草与审核我方采购 API/大模型服务、硬件或技术服务，签一体机交付与服务合同、网络施工/装修/搬家/场地等工程类合同、保密协议模板，以及向客户出具承诺函、质保函等非销售类对外文件时，由法务审核定稿（含配套验收单/结算单）主责——法务负责人（当前：李瑶·推断待确认）；协同——总经办（当前：田杰·推断待确认）、业务负责人（当前：丁震宇、常元和·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、IT 硬件（当前：杨明学·推断待确认）、市场/渠道（当前：闫登辉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 提交合同审核申请并写清交易背景 → ② 选模板或提交对方文本起草 → ③ 业务确认内容一致性 → ④ 法务审核并配套验收单/结算单 → ⑤ 财务核对付款开票税点 → ⑥ 定稿 → ⑦ 用印签署与付款 → ⑧ 归档法务审定的对外合同（附验收单/结算单）、承诺函或质保函，飞书合同审核记录，后续用印与付款依据待优化144
LEG-05保密协议与外部合作（合作开发/非劳务）协议拟定与客户、外部公司或非员工个人开展合作前，需要交换敏感资料（脱敏数据、PRD、代码方案）或界定合作关系时，先签保密协议、合作开发保密与知识产权协议或非劳务合作协议，再开放资料与权限主责——法务负责人（当前：李瑶·推断待确认）；协同——客户对接商务（当前：杨朋伟·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、人事负责人（当前：黄莹·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、COO（当前：常元和·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 业务提出合作与资料交换需求 → ② 法务问询合作性质 → ③ 选模板起草或审对方文本 → ④ 业务与人事确认商务与人员安排 → ⑤ 跟踪对方审批节点 → ⑥ 用印寄送 → ⑦ 签署后开放资料与权限 → ⑧ 归档并设到期提醒双方签署的保密协议/合作开发协议/非劳务合作协议，协议节点跟踪记录，资料与权限开放记录待新建120
LEG-06股东会/董事会决议与合资合伙协议签署召开股东会/董事会表决，设立合伙企业或合资公司，签署对外补充协议或期权激励方案等公司治理类文件时，由管理层先读、法务审阅，按签署检查清单完成签署盖章主责——总经办（当前：田杰·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、协议起草人（当前：陈晖·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 登记文件与签署截止日 → ② 管理层在同一份文档批注商业意见 → ③ AI 风险初筛 → ④ 法务审阅 → ⑤ 定稿并按签署清单检查 → ⑥ 会议表决（如需） → ⑦ 签名用印 → ⑧ 归档并启动后续变更法务审定并签署盖章的决议、合伙/合资协议、补充协议或期权文件，表决记录，签署检查清单待新建120
LEG-07云厂商合同与代付协议电子签署各云厂商/办公软件平台通过电子签平台发来合同变更、三方代付协议、代付合同等签署待办时，确认变更内容、按需法务审阅后完成电子签署并归档主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 收到签署待办并登记 → ② 拉取变更摘要 → ③ 判定快速签或法务审 → ④ 法务、财务确认（需要时） → ⑤ 授权签署人在平台签署 → ⑥ 下载归档并登记到期日 → ⑦ 通知财务与供应商台账更新已签署的云厂商合同/代付协议 PDF、变更摘要、合同台账记录待优化18
LEG-08业务电子合同（电子签）接入与线上签约产品或业务需要在线签约（LeapCore 词元充值、行业版客户、渠道硬件合同、俱乐部与陪玩代签）时，接入电子签平台、配置并授权法务定稿的合同模板，上线后批量出具电子合同并存档主责——业务线产品负责人（当前：杨萌·推断待确认；跃竞线：徐莉·推断待确认）；协同——电子签接入研发（当前：陈锦杰、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部/合同模板（当前：赵雪冰·推断待确认）、销售模板起草（当前：吴琪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、前端（当前：魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、运营执行（当前：刘安达、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 立项明确签约场景 → ② 评估复用与平台采购 → ③ 法务定稿模板并定可变字段 → ④ 控制台配置与授权 → ⑤ 开发接入 → ⑥ 测试验收 → ⑦ 上线并发布操作手册 → ⑧ 运行存档与模板变更管控上线可用的电子签约功能、已授权的合同模板、电子合同 PDF 存档、接入与授权手册、操作 SOP待优化160
LEG-09用章用印审批与盖章版本核对合同、协议、报价表、股东会/董事会决议、证明、函件、申报材料、授权文件等需要加盖公司印章（公章/合同章/法人章/骑缝章）时，先按类型和分级走审批，再核对版本后盖章、回传扫描件并归档主责——行政负责人（当前：胡则瑾·推断待确认）；协同——印章保管与盖章执行（当前：侯明月·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、总经办（当前：田杰·推断待确认）、飞书审批管理员（当前：黄莹·推断待确认）、各部门申请人；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 判定审批类型 → ② 法务/财务前置审核 → ③ 发起飞书审批 → ④ 分级审批 → ⑤ 锁定最终版 → ⑥ 打印并比对审批附件 → ⑦ 盖章登记 → ⑧ 回传扫描件 → ⑨ 原件交行政归档与审批附件一致的盖章文件、上传至审批单的盖章扫描件、用印登记记录、交行政归档的纸质原件待优化240
LEG-10公司证照、授权委托书与负责人签字材料提供ICP/网站备案、软件分发认证、企业开发者注册、短信签名、云服务开通、合作协议签署等需要营业执照、授权委托书、承诺书、在职证明，或需法定代表人/指定负责人签字盖章时，出具合规的盖章版材料主责——行政/印章管理（当前：侯明月·推断待确认）；协同——综合部证照提供（当前：赵雪冰·推断待确认）、苏州主体资料对接（当前：刘昱潇·推断待确认）、申请人（IT 运维/后端运维，当前：杨明学、宋祺睿·推断待确认）、授权签字人（当前：待指定）、协议审核（当前：邴龙志、常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 申请人列材料清单 → ② 确认主体与签字人 → ③ 从证照库取最新版 → ④ 套模板起草授权书/承诺书 → ⑤ 发起用章用印申请 → ⑥ 签字盖章 → ⑦ 回传并登记符合平台要求的盖章版证照复印件/扫描件、授权委托书、承诺书、在职证明，签字人与用印记录可追溯待优化81
LEG-11合同编号、台账与原件归档合同（含订货单、战略/三方协议、云厂商电子合同）签署前需要编号，签署完成后需登记台账、归档原件；或尽调、报销、审计、查账需要查找合同时主责——总经办合同管理（当前：田杰·推断待确认）；协同——编号规则拍板（当前：丁震宇·推断待确认）、系统对接研发（当前：陈锦杰·推断待确认）、合同经办人（销售，当前：吴琪、时建、刘昱潇·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 审批通过时取号 → ② 编号写入合同正文与订货单 → ③ 双签后上传扫描件并登记台账 → ④ 原件交行政入柜并记录位置 → ⑤ 借阅登记 → ⑥ 每季度核对补录全公司唯一编号的合同台账（可按主体、对方、类型、状态检索）、扫描件云盘、原件存放位置可查的档案柜待新建144
LEG-14专利审查意见答复与状态同步代理师发来修改意见、国家知识产权局下发审查意见通知书/补正通知/受理通知等官文时，指派发明人在期限内答复，并同步全部在途案件状态主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——发明人/技术答复（当前：丁震宇·推断待确认）、专利转让对接（当前：常元和·推断待确认）、外部代理师；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 官文/意见统一接收 → ② 登记台账并算期限 → ③ 指派发明人 → ④ 发明人答复 → ⑤ 代理提交 → ⑥ 核对代理系统状态 → ⑦ 每周推送汇总 → ⑧ 结案每件官文均在期限内完成答复，专利台账状态与代理系统一致，每周一份在途案件状态汇总待优化108
LEG-15专利挖掘培训与知识产权激励申报公司推动员工进行专利挖掘与交底撰写时，组织专利培训，并在专利/软著达到节点后按知识产权激励办法申报、核验、兑现奖金或积分主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——培训组织（总经办，当前：王欣·推断待确认）、激励口径与技术把关（当前：丁震宇·推断待确认）、人事（积分/奖金发放，当前：待指定）、财务（当前：待指定）、研发员工（当前：季学森、郭逸非·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 制定激励办法与积分口径 → ② 发布并宣贯 → ③ 组织专利挖掘培训（线下 + 录屏）→ ④ 收集专利线索 → ⑤ 节点达成后员工申报 → ⑥ 按台账核验 → ⑦ 审批 → ⑧ 公示与兑现成文的知识产权激励办法、培训录屏与资料、专利线索清单、经审批的激励兑现记录待新建32
LEG-16商标查询、注册申请与驳回复审新品牌、新产品命名或改名时，在对外使用前完成商标近似检索、确定主体与类别群组、委托申请，并跟进受理、初审公告、驳回复审、注册证与续展，同时按类别保存使用证据主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——产品负责人（当前：杨萌、徐莉·推断待确认）、类别预选与技术口径（当前：丁震宇·推断待确认）、开源社区负责人（当前：陈梦琪、葛家和·推断待确认）、复审与主体决策（当前：常元和·推断待确认）、外部商标代理；兜底——CEO（当前：邴龙志·推断待确认）① 命名前近似检索 → ② 代理出风险评估 → ③ 决定申请（主体、类别、群组）→ ④ 准备标样 → ⑤ 委托代理提交 → ⑥ 台账登记与进度跟进 → ⑦ 驳回复审决策 → ⑧ 注册证归档、使用证据保存、续展提醒商标台账（名称、主体、类别群组、申请号、状态、期限、使用证据）及注册在正确主体名下的商标注册证待新建144
LEG-17被抄袭/侵权线索处置员工发现外部网站、产品或社区页面抄袭、1:1 复刻公司官网内容/设计、产品界面或功能，或冒用公司品牌时，启动登记、取证、定性和维权主责——法务（当前：待指定）；协同——发现人（任一员工）、品牌/官网负责人（当前：待指定）、研发取证支持（当前：待指定）、对外沟通与处置决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人① 线索登记 → ② 证据固定 → ③ 权属与相似度评估 → ④ 查明对方主体 → ⑤ 定性并审批处置方案 → ⑥ 先礼后兵对外沟通 → ⑦ 投诉/律师函/诉讼升级 → ⑧ 结案归档与补权侵权线索登记记录、证据包（截图、录屏、存证或公证）、经审批的处置方案与对外函件、结案记录；需要时触发专利/软著/商标补申待新建48
LEG-18用户协议、隐私政策、EULA 与免责文案编制及变更管控产品、官网、社区、App 或安装包面向外部用户上线前，或新增个人信息收集、UGC、IP 属地、第三方 SDK、储值退款等功能，或产品内法律提示被改动时，编制/更新用户协议、隐私政策、社区公约、EULA、AI 免责文案，并管控后续变更主责——产品线协议负责人（产品经理）（当前：Leap 系列为杨黔昆、跃玩为樊九辰·推断待确认）；协同——法务（当前：待指定）、产品负责人（当前：杨萌·推断待确认）、客户端研发（当前：岳阳·推断待确认）、社区/生态运营（当前：陈梦琪·推断待确认）、合规负责人（当前：常元和·推断待确认）；兜底——法务负责人① 需求评审触发登记 → ② 按模板起草/修订 → ③ 法务审核 → ④ 产品与合规会签 → ⑤ 研发上线展示 → ⑥ 版本归档与告知 → ⑦ 受保护文案变更守卫 → ⑧ 半年复核经法务审核的协议/政策/EULA/免责文案定稿（含版本号、生效日）、在线链接与产品内展示位、协议版本台账、必备法律文案清单待新建180
LEG-19新产品/新功能上线合规评估产品对外发布，或研发/产品提出可能涉及合规风险的功能（第三方数据抓取或展示、读取 cookie、视频下载、云端读取客户文件、字体/素材版权、境外或未备案模型、API 对外转售、商城上架第三方产品），在开发前由法务出具合规结论与整改要求主责——法务（当前：待指定）；协同——需求提出产品经理（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、数据来源与合规责任人（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 需求评审合规勾选 → ② 补齐评估材料 → ③ AI 初筛 → ④ 法务出结论 → ⑤ 争议事项决策 → ⑥ 按整改要求实现与验收 → ⑦ 上线门禁 → ⑧ 结论入库与抽检合规评估单与合规结论书（可做/附条件可做/不可做 + 整改项）、整改验收记录、合规结论库待新建240
LEG-20AIGC 内容安全审核与 AI 生成标识合规面向国内用户的 AI 生成产品（LeapPPT、LeapAll 等）正式推广前，或出现内容审核误杀、漏放、演示被拦截、需要向监管或客户说明时，落实内容审核链路、手机号实名注册、AI 生成标识、违规处置与复盘主责——产品线内容安全负责人（当前：LeapPPT 为李凯·推断待确认）；协同——审核链路研发（当前：马漳毓·推断待确认）、云资源与审核服务开通（当前：杨明学·推断待确认）、法务（当前：待指定）、运营审核员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 推广前合规门禁 → ② 审核链路接入 → ③ AI 生成标识 → ④ 分级策略配置与回归 → ⑤ 误杀/漏放处置 → ⑥ 疑似内容人工复核 → ⑦ 违规处置与留痕 → ⑧ 月度复盘推广前检查单、审核策略配置记录、AI 生成标识实现、误杀/漏放处置记录、违规处置台账、《内容安全与隐私规范》待新建320
LEG-21营销短信与推广内容合规审核向用户发送含营销性质（优惠、免费额度包、活动、拉新、召回）的短信、站内信、邮件或推广文案前，完成分类、对象核查和文案合规审核后再发送主责——发送需求方运营（当前：待指定）；协同——法务（当前：待指定）、短信通道管理员（当前：待指定）、风险提示与技术支持 CTO（当前：丁震宇·推断待确认）；兜底——运营负责人① 提交发送申请 → ② 通知类/营销类分类 → ③ 接收对象核查 → ④ 文案合规检查 → ⑤ 通道模板报备 → ⑥ 小批量试发与正式发送 → ⑦ 投诉与退订监控 → ⑧ 模板入库审核通过的短信/推广文案与发送名单、通道模板、发送与投诉记录、合规文案模板库待新建48
LEG-22业务合规红线与灰色业务风险隔离业务中出现批量私信获客、代理 IP 池、购买/租用账号、数据买卖或交换等请求，或与外部合作方沟通涉及合规边界的话题时，按红线清单判断能否做，并让公司与员工远离违法风险主责——法务（当前：待指定）；协同——业务发起方负责人（跃竞：徐莉·推断待确认）、研发/IT（当前：待指定）、销售负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别请求 → ② 对照红线清单自查 → ③ 提交风险评审 → ④ 法务出结论（禁止/附条件可做） → ⑤ 争议决策 → ⑥ 附条件执行与留痕 → ⑦ 对外沟通口径 → ⑧ 登记台账与季度复查业务合规红线清单、风险评审结论、附条件执行的合同与授权证明、对外沟通口径、风险评审台账待新建120
LEG-23ICP/网站/App 备案办理与备案信息维护新域名、展示站、产品站或 App 需要对外使用，或云厂商发来备案核查通知、备案信息（主体、负责人、电话）需要变更时，完成 ICP 备案、公安联网备案、App 备案及备案信息维护主责——备案专员/IT 运维（当前：杨明学·推断待确认）；协同——证照与授权委托材料、签章（当前：赵雪冰·推断待确认）、苏州主体材料提供人（当前：刘昱潇·推断待确认）、法人/主体负责人（当前：邴龙志·推断待确认）、站点研发（当前：宋祺睿·推断待确认）、App 上架产品经理（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 备案需求登记 → ② 查台账判断是否需新备案 → ③ 确定主体与负责人 → ④ 备齐材料包 → ⑤ 云厂商提交与管局审核 → ⑥ 公安联网备案与备案号展示 → ⑦ 登记台账 → ⑧ 核查响应与信息变更ICP 备案号、公安联网备案号、App 备案号；备案台账（域名/App、主体、负责人、联系人、状态）；备案材料包模板待优化240
LEG-24增值电信业务许可证办理与年报每年 1～3 月持证主体办理增值电信业务经营许可证年报（3 月 31 日截止），或业务需要新办、增项、续期、变更增值电信许可（ICP、EDI、国内互联网虚拟专用网 B13 等，如 LeapVPN 对外经营）时，完成证照核查、材料与方案准备、填报提交、跟进审查和归档主责——综合部证照资质管理（当前：赵雪冰·推断待确认）；协同——年报填报执行（当前：杨明学·推断待确认）、新办/增项证照申报岗（总经办，当前：田杰·推断待确认）、技术方案编写人（当前：吴世豪·推断待确认）、业务说明起草与技术审核 CTO（当前：丁震宇·推断待确认）、往年材料与经验提供（当前：常元和·推断待确认）、财务（上年财务报表，当前：待指定）、行政协助（当前：侯明月·推断待确认）；审定——CEO（当前：邴龙志·推断待确认）① 合规日历自动提醒 → ② 核对持证清单与系统账号 → ③ 收集财务、业务与网络安全材料 → ④ 填报 → ⑤ CTO 核对业务类别与数据、CEO 审定 → ⑥ 提交并留存回执 → ⑦ 新办/增项：确认许可类别、咨询材料清单、确认上游云服务商合规支持 → ⑧ 编写可研报告与技术、安全方案，核验各类负责人 → ⑨ 内部审批后提交并跟进审查 → ⑩ 领证、证照原件与材料归档按期提交的年报回执、网络与信息安全管理制度文件、业务说明；新办/增项的可行性研究报告、网络技术方案、安全保障方案与申报进度表；新办、增项或续期后的许可证（电子与纸质）、资质台账与年度材料包；产品“有证经营”上线确认待新建160
LEG-25算法备案、办学许可、3C 认证等专项资质办理产品上线前需做算法备案（或已提交的算法备案材料被打回需补正、备案信息需变更）、拟开展对外收费培训需判断是否申领办学许可、新机型或新供应商硬件出货（尤其渠道批量）需要 3C 证书时，先判断是否必须办理，再组织办理并维护资质台账主责——综合部负责人（资质合规统筹）（当前：赵雪冰·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总经办专员（当前：田杰·推断待确认）、IT 运维/采购资产（当前：杨明学·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、产品负责人（当前：杨萌·推断待确认）、交付工程师（当前：游家豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、算法备案材料负责人（当前：陈子康·推断待确认）、研发改造（当前：王皓南·推断待确认）；决策与兜底——CEO（当前：邴龙志·推断待确认）① 需求登记 → ② 是否需办理判定 → ③ 定主体与责任人 → ④ 准备材料 → ⑤ 内部审核对齐 → ⑥ 提交/送检跟进 → ⑦ 取证入台账 → ⑧ 到期与变更提醒取得的算法备案号/办学许可证/3C 证书；资质台账（含机型—证书对应表）；可对外提供的证书资料包待新建200
LEG-26境外主体设立与海外 AI 服务采购合规国内主体无法直接采购企业版海外 AI 服务，或需要境外账号、IP、支付方式，有人提出设立境外公司或用个人/境外账户、支付渠道付款时，先做合规评估，再决定是否设立境外主体及采用何种付款路径主责——COO/联合创始人（当前：常元和·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总助（当前：刘昱潇·推断待确认）、财务负责人（当前：待指定）、法务负责人（当前：李瑶·推断待确认）、需求方研发负责人（当前：王皓南、宋祺睿·推断待确认）、架构/风险评估（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交需求单 → ② 境内替代方案排查 → ③ 法务+财务合规会签 → ④ CEO 决策 → ⑤ 境外主体设立与开户 → ⑥ 以公司主体开通服务账号 → ⑦ 付款入账 → ⑧ 登记台账并年度维护境外采购合规评估单（结论与条件）；获批时设立的境外主体与银行/支付账户；企业版海外 AI 服务账号；境外主体与账号台账待新建100
LEG-27开源与保密规范制定、评审与发布公司首次出台或修订开源规范、保密规范（资产分级、个人开源项目、远程操作责任等）时，经多部门评审与法务确认后全员发布，并配套落地 SOP 与表单；是 LEG-28～LEG-31 的上位制度主责——创始人兼 CTO（规范起草与决策）（当前：丁震宇·推断待确认）；协同——研发评审人（当前：王皓南、宋祺睿、李子遥、陈晖、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、配套 SOP 搭建人（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 立项定范围 → ② 起草初稿 → ③ 法务预审 → ④ 多部门逐条评审 → ⑤ 改稿并关闭意见 → ⑥ 法务终审与 CEO 批准 → ⑦ HR 发布与签收 → ⑧ 配套 SOP 上线与年度复审正式生效的保密规范、开源工作管理规范、速查卡与入口页；评审意见清单（含处理结果）；配套 SOP、表单与审批流；全员签收记录待优化100
LEG-28开源组件引入与许可证合规评估在产品、Agent 容器或交付物中引入/集成/二开第三方开源组件，复制开源 UI 代码，把员工业余开源项目引入公司项目，或二开后改名换 Logo 对外分发时，先评估许可证义务并确定使用条件主责——研发技术负责人（当前：王皓南·推断待确认）；协同——引入方研发（申请人）、许可证初审人（当前：岳阳、柯逸飞·推断待确认）、开源负责人（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、品牌负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提交开源组件引入申请 → ② CI 自动扫描许可证 → ③ 技术初审（使用方式与隔离） → ④ 法务判定 → ⑤ 定使用条件（署名、命名、隔离、开源义务） → ⑥ 登记台账并 fork 备份 → ⑦ 发版前复核第三方声明开源组件引入审批记录；开源组件台账；每个组件的使用条件（版权声明、about 页署名、对外命名、是否需公开源码）；发版包内的第三方声明文件待优化135
LEG-29员工开源账号备案与对外开源发布审批员工入职报备个人开源账号；员工或团队拟把公司代码、Skill、模板、模型对外开源、向上游贡献，或在 GitHub/HuggingFace 发布；公司孵化开源项目立项时，完成备案、分级审批、署名与发布主责——开源事务管理员（当前：陈晖·推断待确认）；协同——申请人（项目主要维护者）、分级复核人（非申请人的研发同事）、技术负责人/审批人（当前：丁震宇·推断待确认）、研发技术负责人（当前：王皓南、宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、开源负责人/公司开源组织管理员（当前：常元和·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 开源账号报备 → ② 提交开源申请表单 → ③ 分级复核 → ④ 按级别审批 → ⑤ 发布前检查（敏感信息、许可证、署名） → ⑥ 在公司组织下发布 → ⑦ 登记台账与激励 → ⑧ 立项后按月跟进开源账号报备表；开源申请审批记录；公司 GitHub/HuggingFace 组织下的公开仓库（含许可证、署名、维护者）；开源项目台账待优化144
LEG-30对外提供材料与代码权限的保密审查需要把含真实客户信息的材料（可研报告、方案、数据样例）发给外部人员，对外披露渠道/供应商/灰度产品信息，或合作方索取代码库/源码时，先做保密审查，决定脱敏、签 NDA、限定授权方式或拒绝主责——法务负责人（当前：李瑶·推断待确认）；协同——发起人所在产品/研发负责人（当前：杨萌、王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 发起外发申请 → ② 密级与敏感信息判定 → ③ 选择提供方式 → ④ 签署 NDA → ⑤ 审批 → ⑥ 受控交付 → ⑦ 登记并到期回收对外资料/源码授权审批记录；已签 NDA；脱敏材料或限时只读代码权限；外发台账待新建100
LEG-31代码与机密资产外泄管控及事件处置获得或形成高价值代码、Skill、提示词等机密资产需要控制流转范围，或发现员工把公司代码/资产放到个人公开仓库、外部平台时，执行登记管控与泄露事件处置主责——创始人兼 CTO（机密资产管控负责人）（当前：丁震宇·推断待确认）；协同——资产所属业务线技术负责人（当前：王皓南·推断待确认）、资产登记员（当前：王满·推断待确认）、清洗改写研发（当前：陈锦杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 资产定级登记 → ② 权限化分发与拷贝登记 → ③ 清洗确认后方可扩散 → ④ 定期扫描公开仓库 → ⑤ 发现泄露立即止损 → ⑥ 取证与影响评估 → ⑦ 按规范定性处理 → ⑧ 复盘整改机密资产登记表（含拷贝持有人）；泄露事件处置记录（止损、证据、影响、处理结论）；整改项清单待新建160
LEG-32诉讼、仲裁与法律纠纷应对公司收到律师函、起诉状、仲裁申请、法院传票，或需要对客户欠款、供应商违约、侵权方等发起法律主张时启动主责——法务专员（当前：待指定）；协同——涉事业务部门负责人（当前：待指定）、财务（当前：待指定）、外部律师（如有）；兜底——法务负责人（当前：李瑶·部门报送人）① 文书接收与期限登记 → ② 事实与证据收集 → ③ 风险评估与策略 → ④ 管理层决策 → ⑤ 协商/发函/应诉/起诉 → ⑥ 执行与回款 → ⑦ 结案复盘纠纷台账、证据目录、处理策略与决策记录、和解协议或裁判文书及执行结果待新建100
LEG-33监管问询、执法调证与约谈应对网信、公安、通信管理、市场监管等部门对公司产品或用户数据发出问询、调取证据、协助调查、约谈或整改通知时启动主责——法务专员（当前：待指定）；协同——研发/运维负责人（当前：待指定）、产品负责人（当前：待指定）、政策申报对接人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 接收与身份核验 → ② 登记期限 → ③ 法律评估调取范围 → ④ 审批 → ⑤ 最小范围提供数据或材料 → ⑥ 整改落实 → ⑦ 归档与复盘经核验的执法文书登记、数据提供记录、整改报告、约谈纪要待新建80
LEG-34个人信息权利请求与数据安全事件合规处置用户请求查询、复制、更正、删除个人信息或注销账号，或发生用户个人信息、客户数据泄露、篡改、丢失等数据安全事件需要法律评估、告知与报告时启动主责——法务专员（当前：待指定）；协同——客服/运营（当前：待指定）、研发/运维负责人（当前：待指定）、安全负责人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 受理与身份核验 → ② 分类（权利请求/安全事件）→ ③ 影响评估 → ④ 执行请求或止损 → ⑤ 告知个人/客户 → ⑥ 必要时向监管报告 → ⑦ 留痕归档权利请求处理记录、数据安全事件评估报告、告知与报告留档待新建120
LEG-35合同履约节点与到期续约管理已签署的销售、采购、服务、合作合同中存在验收期、质保期、付款节点、自动续约、到期终止通知期等关键节点，需要提前提醒和决策时适用主责——合同管理员（当前：待指定）；协同——合同经办人（当前：待指定）、财务（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）① 签约时提取关键节点 → ② 录入台账 → ③ 节点前自动提醒 → ④ 经办人确认履约状态 → ⑤ 续约/终止/变更决策 → ⑥ 发函或签署补充协议 → ⑦ 台账更新带关键节点的合同台账、续约或终止决定、相关函件与补充协议待新建96
LEG-01合同模板库建设、版本维护与发布待优化225

状态：待优化｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：产品、价格、税点、渠道政策发生变化，或新业务、新系统（渠道系统、线上充值）上线需要合同模板时，由法务修订或新建模板，定稿后编号发布到唯一模板库，旧版同时作废
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——模板版本维护人/渠道负责人（当前：闫登辉·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、总经办（当前：田杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统研发（当前：陈子康·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交模板变更/新建申请 → ② 法务评估影响并列出待定规则 → ③ 业务、财务答复规则 → ④ 法务修订 → ⑤ 销售/产品/财务会签 → ⑥ 定版编号入库、旧版作废 → ⑦ 发布并同步系统模板 → ⑧ 抽查使用情况
  • 交付结果：唯一模板库中的定稿模板（带版本号、生效日期、变更摘要、适用场景），发布通知，以及渠道系统、电子签中同步更新的模板
  • 状态依据：2026-08 已启动全公司模板归集，合同审核群置顶了最新模板，渠道系统也能按模板自动填充；但模板仍主要靠群里传文件。07～10 月多个版本并存、销售误用旧版，到 10 月仍有人在群里要“最新模板”，这类情况约 10 余次；版本维护只靠一个人

1. 场景判定

  • 触发条件：产品版本调整（如删除电竞版、独家改为钻石等级）；价格、税点（硬件/软件分税率）、保护期等商务条款变化；新业务需要标准合同（词元充值、VPN 流量、付费 API 等）；新系统上线需要能自动生成的模板（渠道代理协议、销售合同、充值协议、结算单、验收单）；法务定期复核模板
  • 典型说法：「版本维护得有专人管，不然会乱」「请在 9 月 11 日更新的代理合同模板基础上修改」「谁发我一份现在最新的模板销售合同」「这个产品需要一份合规、正式、后续能批量用的合同」
  • 判断问题：这次改动会不会影响“以后所有同类合同”？会 → 走本流程；只影响某个客户的某一份合同 → 走个案审查
  • 不归本流程管：单份销售合同的个案修改与审核 → 请走 LEG-03；采购、服务等非销售类对外合同的个案 → 请走 LEG-04；合同编号分配、台账与原件归档 → 请走 LEG-11；电子签平台的技术接入与模板授权 → 请走 LEG-08；用户协议、隐私政策 → 请走 LEG-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
法务 评估影响、修订条款、定稿、抽查使用 R/A 法务负责人（当前：李瑶·推断待确认）
模板版本维护人 入库、编号、作废旧版、发布通知 R 渠道负责人（当前：闫登辉·推断待确认）
需求方 提出变更、提供业务规则 R 市场销售负责人（当前：李鹏为·推断待确认）、总经办（当前：田杰·推断待确认）、销售（当前：吴琪、时建、陈芷青·推断待确认）
产品 确认功能、交付、等级权益相关表述 C 产品负责人（当前：杨萌·推断待确认）
财务 确认税点、付款、开票、退款条款 C 财务负责人（当前：黄梦婷·推断待确认）
业务规则确认 词元/充值类规则（开票、退款、赠送）拍板 C COO（当前：常元和·推断待确认）
系统同步 渠道系统/电子签模板替换、字段标识符维护 R 渠道系统研发（当前：陈子康·推断待确认）
技术需求方 提出可批量、可自动生成的模板需求 C 创始人兼 CTO（当前：丁震宇·推断待确认）
兜底/统筹 归集组织、跨部门协调、超时裁决 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）
使用者 按现行版本起草合同 I 全体销售、商务

3. 办之前请准备

  • 变更说明：变更原因、期望生效日期、受影响模板清单、新旧条款对照
  • 已对齐的业务规则：付款、发票、验收、退款、赠送、税点拆分口径、保护期、渠道等级权益（业务和财务先对好）
  • 当前在用版本（从模板库取，不用聊天记录里的文件）
  • 需系统生成的模板：可变字段清单（抬头、金额大写、硬件明细、地址、编号）及每个字段的数据来源
  • 归集场景：按“部门名称+协议类型+版本号”命名的文件，并注明适用场景和已知问题

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交模板变更/新建申请，写清原因、受影响模板、新条款要点、期望生效日 需求方 政策确定后 1 个工作日内 飞书审批/表单 模板变更申请 🔧飞书固化
2 评估影响范围（受影响的模板、系统、在途合同），把需要业务或财务先定的规则问题一次列给需求方 法务 收到申请后 1 个工作日内 飞书云文档 影响清单、问题清单 👤人工判断
3 答复规则问题（付款、发票、验收、退款、赠送、税点、保护期） 需求方、财务 收到问题清单后 2 个工作日内 飞书文档评论 规则确认记录 👤人工判断
4 用修订模式修订模板并附变更摘要；需要系统生成的模板，把可变位置替换为填充标识符 法务 规则确认后 3 个工作日内（新建模板 5 个工作日内） Word 修订模式/飞书云文档 修订稿 🤖+👤
5 会签：销售确认商务条款，产品确认功能与交付表述，财务确认税点与开票条款 需求方、产品、财务 收到修订稿后 2 个工作日内 飞书审批会签 会签意见 🔧飞书固化
6 定稿：编版本号（模板类型-YYMMDD-Vn），写生效日期和变更摘要，存入唯一模板库；旧版标“已作废”并移到历史目录 法务、模板版本维护人 会签通过当天 飞书知识库 + 多维表格模板台账 定稿模板、台账记录 🔧飞书固化
7 发布：在合同审核群、销售群发通知并置顶，写明“X 日起新签合同一律用新版”；渠道系统、电子签模板同步替换并重新授权 模板版本维护人、渠道系统研发 定稿后 1 个工作日内 群公告/机器人、渠道系统、电子签控制台 发布通知、系统更新记录 🔧+🤖
8 抽查：发布后审核合同时核对版本号，发现旧版直接退回 法务 发布后 10 个工作日内 合同审核记录 抽查结果 🤖自动化

5. 交付物与模板

  • 交付物：定稿模板文件、模板台账、变更摘要、发布通知、系统模板同步记录、作废旧版的历史目录
  • 建议模板/表单：
    • 模板台账字段：模板编号、模板名称、类型（渠道代理/销售/试用/充值/结算单/验收单/采购/保密/服务/OEM-ODM/质保函/承诺函）、适用主体、适用产品线、适用场景、版本号、生效日期、状态（在用/作废）、变更摘要、上一版本链接、审定人、系统同步状态
    • 模板变更申请字段：申请人、变更原因、受影响模板、新条款要点、期望生效日、是否影响系统模板、是否影响在途合同
    • 模板文件命名：部门名称＋协议类型＋版本号（日期）

6. 异常与升级

  • 业务、财务规则 2 个工作日内定不下来 → 法务先出“待定条款”标注版，不发布 → 升级综合部负责人协调，由其作为 A（升级）当天裁决；其余情况由法务负责人拍板
  • 销售发现已发布模板有错 → 立即在发布群通知暂停使用 → 法务 1 个工作日内出勘误版并重新发布
  • 系统模板与法务定稿不一致 → 渠道系统研发 1 个工作日内修正 → 未修正前系统暂停下载该模板
  • 模板版本维护人请假或离岗 → 由法务负责人代为维护 → 兜底人 2 个工作日内指定新维护人
  • 在途合同受新版条款影响（如保护期变更） → 法务列出在途清单 → 由市场销售负责人决定是否补签（3 个工作日内）

7. 衡量指标

  • 旧版误用率 = 审核中发现使用非现行版本的合同数 / 审核合同总数，目标 ≤ 2%
  • 模板变更周期 = 申请提交到发布的工作日数，目标 ≤ 7 个工作日（新建 ≤ 10 个工作日）
  • 群内索要模板次数 = 每月群里询问“最新模板”的次数，目标为 0
  • 模板库覆盖率 = 已入库模板覆盖的合同类型数 / 实际签约的合同类型数，目标 100%
  • 系统模板同步时效 = 定稿到系统替换完成的工作日数，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：模板散落在聊天记录、多个知识库和群文件里，销售找不到最新版，发布后仍有人在群里要（模板存放环节）｜依据：「【模态】市场销售」2026-08、「【模态】市场销售」2026-10
  • 现象：多个版本并存，新版只靠群消息通知，旧版没有作废标记，销售用旧版被退回（发布与作废环节）｜依据：「leapcore 合同审核群」2026-09、「【模态】市场销售」2026-10
  • 现象：版本维护只靠一个人，知识库上传权限不足还要别人代传（权限与维护环节）｜依据：「【模态】市场销售」2026-08
  • 现象：归集通知要求当天交，次日还要催；各部门模板重复（归集环节）｜依据：「【模态】业务负责人」2026-08
  • 现象：新业务合同开写时付款、发票、退款、赠送规则还没定，各方对“是否已合规”判断不一（规则输入环节）｜依据：「【模态】总经办」2026-08
  • 现象：独家/非独家是否分两个版本反复讨论，等级改名后模板跟着返工（条款设计环节）｜依据：「leapcore 合同审核群」2026-07、「leapcore 合同审核群」2026-08
  • 现象：结算单、合同、充值订单叫法对不上，地址字段没有数据来源，代理协议下载入口开放晚且只有管理员可见（系统模板衔接环节）｜依据：「渠道系统优化」2026-09、「渠道系统优化」2026-10

9. 分支变体

  • 渠道系统自动生成系列（渠道代理协议、试用合同、销售合同、充值协议、充值结算单、验收单）：模板中的可变位置改为标识符，由系统按渠道资料自动填抬头、金额大写、硬件明细、地址；合同编号在“确认下载”时生成，格式 WHMT-LC-[材料类型]-[年份]-[月日]-[流水号]，材料类型缩写为 DLXY/QDCG/QDXS/CZXY/CZJS/YSD（编号规则管理见 LEG-11）；文件标“待签署版/已签署版”；现行规则不支持退款，条款不按退款设计
  • 渠道采购（模态—渠道）由系统自动生成；渠道销售（渠道—客户）由渠道下载后填写；LeapCore 线下充值结算单由 LeapCore 侧生成
  • LeapCore 线上词元充值标准合同：开口合同，除金额、甲方名称、日期外其余条款固定；须先定个人/企业开票、随充随用、退未使用部分、赠送不退等规则并经财务确认；电子签上线见 LEG-08
  • 销售合同税点区分版：硬件与软件/服务金额分列，须财务确认（开票口径见 FIN-20）
  • 渠道代理协议：独家与非独家共用一个通用版本，用等级条款区分；保护期等条款修改要同步全部渠道模板
  • 全公司模板归集：按渠道、采购、保密、标品销售、客户服务、运营活动、服务交付、OEM/ODM 分类，优先完善特殊渠道协议
  • 特殊文书（质保函、承诺函、开口充值合同）：模板入库；个案出具走 LEG-04

10. 待确认问题

  • 主责是否为法务负责人？模板版本维护人是否另设（目前由渠道侧兼任）？备岗是谁？
  • 唯一模板库放在哪里：飞书知识库、多维表格，还是建设中的合同及履约管理系统？合同审核群置顶是否作为过渡保留？
  • 变更 7 个工作日、新建 10 个工作日的时限是否可行？
  • 付费 API 转售、VPN 流量与词元充值是否共用一份合同？
  • 是否已有成文的合同模板管理制度？2026-08 归集的结果是否已形成分类清单？
LEG-02我方签约主体选择与印章信息登记待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：起草合同或报价、申请用印、试用转正式时，集团内有多个主体（模态跃迁、鼎慧、渠道公司等）都可能签约，需要定下我方签约主体及结算路径；主体资料与印章信息需要在系统里新增、变更或关闭时
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——起草合同的销售（当前：吴琪·推断待确认）、产品/鼎慧负责人（当前：杨萌·推断待确认）、财务（当前：待指定）、总经办（当前：田杰·推断待确认）、CMS 研发（当前：裴建武·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 起草前填写主体判断要素 → ② 按主体决策表初判 → ③ 财务确认收款、开票与集团内采购路径 → ④ 法务确认 → ⑤ 例外情形审批 → ⑥ 合同审批单选主体并带出资料 → ⑦ 主体与印章主数据维护
  • 交付结果：每份合同的主体确认结论（含集团内采购/结算安排），以及系统内准确的“签约主体—印章”主数据
  • 状态依据：试用转正式时“跟我们哪个公司签”无人能当场答复，先部署后定主体，采购路径事后改动；签约主体与印章规则目前只在 CMS 测试环境的需求里定义，没有线下制度；个人客户能否直接购买也没有书面规则

1. 场景判定

  • 触发条件：新客户首份合同；试用转正式；同一订单涉及软件与硬件且由不同主体出；客户或渠道要求换签约主体；个人或个体户要购买产品；新设主体、新刻或停用印章
  • 典型说法：「这个合同是跟我们哪个公司签」「客户和鼎慧签，鼎慧再向出机器的公司采购」「用过的印章不能删，只能关闭」「能不能直接卖给个人」
  • 判断问题：这份合同我方由谁签、钱进哪个主体、设备由谁出，三件事是否都已明确且一致？任何一项不明确 → 走本流程
  • 不归本流程管：具体的用印申请与盖章 → 请走 LEG-09；营业执照、授权委托书等证照材料出具 → 请走 LEG-10；合同条款审查 → 请走 LEG-03 / LEG-04；用工主体判定 → 请走 HR-04；主体设立与注销 → 请走 CEO-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
法务 维护主体决策表，确认主体结论，判断合规风险（个人客户、备案） R/A 法务负责人（当前：李瑶·推断待确认）
起草人 填写主体判断要素，按结论起草 R 销售（当前：吴琪·推断待确认）
产品线负责人 说明产品归属主体、交付安排 C 产品/鼎慧负责人（当前：杨萌·推断待确认）
财务 确认收款主体、开票、集团内关联采购与付款前置 C 财务（当前：待指定）
硬件/交付 说明设备由哪个主体采购、出库 C IT 运维/资产（当前：杨明学·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）
主数据需求方 定义主体与印章字段、规则 R 总经办（当前：田杰·推断待确认）
系统实现 CMS 签约主体板块开发与维护 R CMS 研发（当前：裴建武·推断待确认）
例外审批 个人客户销售、非常规主体安排拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 客户信息：客户类型（企业/个体户/个人）、客户全称、统一社会信用代码
  • 交易信息：产品线（LeapCore、鼎慧行业产品、渠道产品等）、是否含硬件、设备由哪个主体出、试用还是正式、金额区间
  • 开票与收款要求：专票/普票、客户指定的付款主体
  • 现有主体清单（含各主体经营范围、可用印章、是否开放使用）
  • 涉及生成式 AI 服务时，该主体的备案情况

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草前填写主体判断要素（客户类型、产品线、硬件来源、开票要求） 起草人 起草合同前，至少在计划部署日前 3 个工作日 合同申请表单 主体判断要素 🔧飞书固化
2 按主体决策表初判我方主体；涉及多主体时写明集团内采购关系（如客户与产品主体签，产品主体向硬件主体采购） 起草人 填表当天 主体决策表 主体初判 🤖自动化
3 确认收款主体、开票主体、集团内采购合同与付款时点是否会卡交付 财务 收到后 1 个工作日内 飞书审批 财务确认意见 👤人工判断
4 确认主体结论；检查经营范围、备案、关联交易文件是否齐全 法务 收到后 1 个工作日内 飞书审批 主体结论 👤人工判断
5 例外情形（个人客户、个体户转售、主体不在授权清单）提交审批 法务 发现当天 飞书审批 例外审批结论 👤人工判断
6 在合同审批单选择主体，自动带出主体资料，合同归入该主体名下 起草人 起草时 合同审批/CMS 带主体信息的合同审批单 🔧飞书固化
7 主数据维护：新增主体或印章时录入基础信息与印章信息（公章、法人章、财务章、是否开放）；同一主体同类印章只登记一枚；用过的印章只能关闭不能删除；历史合同保留原数据 财务或系统管理员 变更发生后 1 个工作日内 CMS 签约主体板块 主数据变更记录 🔧+🤖
8 主体或印章变更后通知销售、财务、行政，更新决策表 法务 变更后 1 个工作日内 群公告/机器人 变更通知 🤖自动化

5. 交付物与模板

  • 交付物：主体决策表、每单主体确认记录、主体与印章主数据、变更审计记录
  • 建议模板/表单：
    • 主体决策表字段：产品线、客户类型、是否含硬件、我方签约主体、硬件出货主体、集团内采购是否需签内部合同、开票主体、备注（备案、资质限制）
    • 主体主数据字段：主体名称、统一社会信用代码、注册地址、开户行与账号（仅系统内可见）、可签产品线、备案情况、状态
    • 印章信息字段：所属主体、印章类型（公章/法人章/财务章/合同章）、是否开放使用、保管人岗位、启用/关闭日期

6. 异常与升级

  • 起草时主体仍不明确、计划部署日临近 → 起草人当天报法务 → 法务 4 个工作小时内给结论，否则升级兜底人
  • 财务付款前置未完成导致交付要延期 → 财务与交付当天对齐 → 升级创始人兼 CTO 决定是否先行交付（当天）
  • 个人客户坚持以个人名义购买 → 原则上建议对方以企业主体采购 → 确需销售的提交例外审批，由创始人兼 CTO 或 CEO 作为 A（升级）拍板（2 个工作日内）；个人客户、个体户转售、主体不在授权清单三类例外均按此升级，其余主体结论由法务负责人拍板
  • 发现已签合同主体错误 → 法务评估补充协议或重签 → 1 个工作日内通知财务暂停开票
  • 系统里印章信息与实物不符 → 暂停该印章在系统中的使用 → 当天通知用印管理人（见 LEG-09）

7. 衡量指标

  • 主体返工率 = 签约后因主体错误补签或重签的合同数 / 合同总数，目标 0
  • 主体确认时长 = 提交主体判断要素到法务出结论的工作小时数，目标 ≤ 8 个工作小时
  • 因主体未定导致的交付延期次数，目标 0
  • 主数据准确率 = 抽查一致的主体与印章记录数 / 抽查数，目标 100%

8. 低效诊断

  • 现象：签试用合同时没人能确定我方签约主体，只能在项目群里临时讨论（主体决策环节）｜依据：「Leapcore 客户项目群（客户B）」2026-07
  • 现象：先部署后定主体，采购路径事后改为由产品主体采购，财务未付款导致交付推迟（财务确认环节）｜依据：「Leapcore 客户项目群（客户B）」2026-07
  • 现象：设备由谁出说法不一（统一由集团主体采购还是由产品主体出）（集团内采购口径环节）｜依据：「Leapcore 客户项目群（客户B）」2026-07
  • 现象：主体板块初稿含授权人等不必要字段，返工删除；变更审计被推到后期（主数据设计环节）｜依据：「cms反馈」2026-09
  • 现象：员工不能新建用印申请，但导航栏仍有入口，权限与入口不一致（系统权限环节）｜依据：「cms反馈」2026-09

9. 分支变体

  • 试用合同转正式：试用阶段签约主体与正式合同保持一致；产品主体对客户签约，再向硬件主体采购设备，配置与金额由技术方填写
  • 集团内关联交易：涉及集团内采购的，同时出内部采购合同，财务确认关联交易定价与付款时点
  • 渠道公司签约：渠道代理协议的签约主体以渠道系统为准，渠道销售给终端客户时由渠道自行签约
  • 个人客户或个体户：原则上不对个人销售（涉及生成式 AI 备案与面向个人的监管要求），特殊情形经例外审批；优先请对方以企业主体采购
  • 系统主数据：已在合同或用印记录中使用过的印章不能删除，只能关闭

10. 待确认问题

  • 主责是否为法务负责人？主体与印章主数据由财务还是总经办维护？
  • 是否可以出一份成文的“产品线—签约主体”对照表，由谁审定？
  • “原则上不对个人销售，特殊情形审批”是否作为正式规则？例外审批人是谁？
  • 通过个体户做隔离销售主体是否可行，需要哪些合规评估？
  • CMS 签约主体板块何时上线？上线前是否用飞书多维表格过渡？
LEG-03销售合同审查与多方会签待优化375

状态：待优化｜证据：有证据（卡片 9 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨5 × 险5

  • 适用场景：销售或商务起草、或客户修改销售类合同（LeapCore 一体机、行业版、渠道代理、试用、词元充值、设备借用、战略框架）后，在签署前由法务、产品、技术/交付、财务会审定稿
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——销售/商务起草人（当前：闫登辉、杜中瑞、时建、杨朋伟、陈名赞、汪家诺、吴琪、刘昱潇·推断待确认）、产品负责人（当前：杨萌·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、IT 硬件审核（当前：杨明学·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、COO（当前：常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 按现行模板起草并自查 → ② AI 预审并判定通道 → ③ 提交审核 → ④ 标准合同快速核对 / 非标合同多方并联会审 → ⑤ 起草人修订留痕 → ⑥ 非标与让步终审 → ⑦ 提交飞书合同审批并用印签署 → ⑧ 归档
  • 交付结果：经会审定稿、与报价单/配置单一致的销售合同，飞书合同审批记录，修订记录与审查报告
  • 状态依据：已有 LeapCore 合同审核群、飞书合同审批流程和 AI 审查报告，07～10 月审了 60 余份合同；但公司名称、金额大小写、法定代表人、地址、型号等低级错误反复出现约 40 次，模板版本混用，硬件配置与可交付不一致，早期还出现过签完才发现口头承诺与合同不符

1. 场景判定

  • 触发条件：客户确认采购意向，需要出正式合同；客户返回修改稿；试用转正式；续签或追加
  • 典型说法：「标准合同，请审核」「合同要按实际交付的硬件写，不要搞错」「这些有争议的条款帮忙一起看下」「请尽快审核，今天要签署寄出」「每个人确认 OK 我就发过去」
  • 判断问题：这是我方作为卖方、向客户或渠道收钱的合同吗？是 → 走本流程
  • 不归本流程管：模板本身要改 → 请走 LEG-01；我方作为买方的采购、服务、施工合同及承诺函、质保函 → 请走 LEG-04；我方签约主体不确定 → 先走 LEG-02；报价单编制与审批 → 请走 SAL-19；硬件配置单 → 请走 X-DLV-01；用印 → 请走 LEG-09；合同编号与归档 → 请走 LEG-11；签约后客户提出合同外需求 → 请走 SAL-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
起草人 按模板起草、自查、AI 预审、提交、修订 R 销售/商务（当前：闫登辉、杜中瑞、时建、杨朋伟、陈名赞、汪家诺、吴琪、刘昱潇·推断待确认）
法务 条款审查、快速核对、汇总意见、放行 R/A 法务负责人（当前：李瑶·推断待确认）
合规协调 跨部门意见协调、超时催办 C 综合部负责人（当前：赵雪冰·推断待确认）
产品 核对功能、模型范围、赠送、服务承诺能否兑现 C 产品负责人（当前：杨萌·推断待确认）
技术 核对技术可行性、源码/软著/迭代升级/验收判定 C 创始人兼 CTO（当前：丁震宇·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）
硬件/交付 核对硬件型号、配置、数量、交付期 C IT 硬件审核（当前：杨明学·推断待确认）
财务 核对价格、税点、付款方式、开票条款 C 财务负责人（当前：黄梦婷·推断待确认）
商务终审 非标条款、价格让步、红线外让步 A（升级） 市场销售负责人（当前：李鹏为·推断待确认）、COO（当前：常元和·推断待确认）
特例拍板 赠送设备是否签合同等特例 A（升级） CEO（当前：邴龙志·推断待确认）
合同保管 原件接收与保管 I 行政负责人（当前：胡则瑾·推断待确认）

3. 办之前请准备

  • 从模板库取的现行版本模板（核对版本号）
  • 已审批的报价单、硬件配置单（型号、数量、RAID/存储方案、席位、交付日期）
  • 客户主体信息：全称、统一社会信用代码、法定代表人、地址、开票信息（以营业执照或企查查截图为准）
  • 修改项清单：相对标准模板改了哪些条款（逐条列出）
  • AI 合同审查报告（用公司合同审核 skill 生成）
  • 期望签署日与是否加急的原因
  • 请求最少包含字段（提交审核时）：合同类型、客户全称与我方主体、CRM 商机编号、模板版本号、是否改动条款与修改项清单、报价单链接与版本号、硬件配置单链接、付款方式与税点、期望签署日与加急原因、AI 审查报告链接；缺项法务一次性退回，不在群里逐条追问

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用现行模板起草，信息与报价单、配置单逐项一致；自查主体名称、金额大小写、法定代表人、地址、型号、盖章页 起草人 客户确认意向后 1 个工作日内 模板库、合同自查清单 合同初稿（挂 CRM 商机页/合同系统，文件名含版本号；自查清单勾选完成） 🔧飞书固化
2 跑 AI 预审，出审查报告；标出相对模板的修改项；判定通道：仅替换客户信息 → 快速通道，有条款改动 → 完整会审 起草人 起草当天 合同审核 skill 审查报告、修改项清单（作为审批附件，与合同同处存放） 🤖自动化
3 在合同审核群或飞书合同审批提交合同、报价单/配置单、审查报告、修改项清单、期望签署日 起草人 至少在期望签署日前 2 个工作日 飞书审批 审核申请（飞书审批单为唯一受理入口，群内只发审批链接）；4 个工作小时无人受理→综合部负责人 🔧飞书固化
4 快速通道：核对版本号、主体、地址、金额、交付期，无问题即放行 法务 提交后 4 个工作小时内 飞书审批 放行或退回意见（审批节点内填写，退回列全部缺项）；超时→综合部负责人 🤖+👤
5 完整会审（并联）：产品核对功能与服务承诺；技术核对可行性与源码/软著/验收条款；硬件核对配置与交付期；财务核对价格、税点、付款、开票；法务审全部条款 产品、技术、硬件/交付、财务、法务 各方收到后 1 个工作日内 飞书审批会签 各方意见（各自审批节点内填写，不在群里给口头意见）；超时见第 6 节 🔧+👤
6 法务汇总意见一次性退回；起草人修订并附修订记录（V2、V3…），争议条款对照“标准条款+红线+可让步清单”处理 法务、起草人 退回后 1 个工作日内修订完成 修订模式 修订稿、修订记录（同一文档的版本记录，不另发新文件）；超时→市场销售负责人 👤人工判断
7 非标条款、价格让步、超出可让步清单的条款由商务终审；必要时交 COO 再审 市场销售负责人、COO 1 个工作日内 飞书审批 终审结论（审批节点内写明让步项与理由，作为决策记录）；超时→起草人 @ COO 👤人工判断
8 定稿后提交飞书合同审批、用印签署（见 LEG-09），签署件交保管并登记台账（见 LEG-11） 起草人 定稿后 1 个工作日内 飞书合同审批 已签合同（扫描件上传合同台账并取得合同编号；原件交行政保管；合同编号回填 CRM 商机与交付工单） 🔧飞书固化

5. 交付物与模板

  • 交付物：定稿合同、AI 审查报告、修订记录、会签意见、飞书审批记录
  • 建议模板/表单：
    • 合同审核申请字段：合同类型、客户全称、我方主体、模板版本号、是否改动条款、修改项清单、金额、税点、付款方式、硬件配置单链接、报价单链接、期望签署日、加急原因
    • 合同自查清单：主体名称、统一社会信用代码、法定代表人、地址、金额大小写一致、型号与配置单一致、交付期、盖章页、附件齐全
    • 标准条款+红线+可让步清单：源码是否交付、软著归属、迭代升级定义、验收完成判定、退款、服务中断赔偿、涨价通知、违约责任

6. 异常与升级

  • 当天要签的加急合同 → 起草人写明加急原因 → 法务 2 个工作小时内处理；同一起草人每月加急超过 2 次，通报市场销售负责人
  • 合同硬件配置与可交付不一致 → 以可交付硬件为准修改合同，不先改配置迁就合同 → 当天升级创始人兼 CTO
  • 报价单与合同不一致（模型范围、赠送数量） → 退回起草人重新对齐 → 涉及价格变动升级市场销售负责人（1 个工作日内）
  • 客户坚持保留无法兑现的条款（如服务中断赔偿、源码交付） → 按红线清单拒绝或给替代方案 → 升级 COO 决定（2 个工作日内）
  • 会审方 1 个工作日未回复 → 系统自动催办 → 再过 4 个工作小时升级综合部负责人
  • 拍板口径：标准合同与快速通道由法务负责人放行（A）；出现非标条款、价格让步或超出可让步清单的条款时，升级市场销售负责人终审，充值合同或红线争议再交 COO，作为 A（升级）在 1 个工作日内给结论；赠送设备、战略框架、生态联盟协议等是否签合同的特例，升级 CEO 作为 A（升级）拍板（2 个工作日内）
  • 提交材料不齐（缺报价单、配置单、修改项清单或审查报告）→ 法务不进入审核，一次性退回并列出缺项 → 起草人补齐后重新提交，时限从重新提交起算
  • 签署件 1 个工作日未登记台账或未回填合同编号 → 法务提醒起草人 → 再 1 个工作日未完成，通报市场销售负责人；交付与财务一律以合同台账中的编号和扫描件为准，不接受群内转发的合同文件

7. 衡量指标

  • 合同审核周期 = 提交到定稿的工作日数，目标快速通道 ≤ 0.5 天，完整会审 ≤ 3 天
  • 低级错误退回率 = 因主体、金额、地址、型号等信息错误退回的次数 / 提交次数，目标 ≤ 5%
  • 合同与报价单/配置单一致率 = 一致合同数 / 抽查合同数，目标 100%
  • 加急合同占比 = 要求当天审完的合同 / 全部合同，目标 ≤ 10%
  • 签约后发现的条款与承诺不符事件，目标 0

8. 低效诊断

  • 现象：合同前一天深夜发、次日就要，硬件类型写错，审合同与调货同时进行（提交时限与硬件核对环节）｜依据：「Leap产研测」2026-06
  • 现象：源码交付、软著、迭代升级、验收判定等争议条款在产研群临时讨论，法务未参与，谈判底牌被误当成可承诺（条款评审环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：签约后才发现口头承诺与合同条款不符，合同由谁审没有明确（审查职责环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：甲方名称、金额大小写、法定代表人、地址等低级错误反复退回（起草自查环节）｜依据：「leapcore 合同审核群」2026-07、「leapcore 合同审核群」2026-09、「leapcore 合同审核群」2026-10
  • 现象：标准合同逐份人工逐字比对，用旧版模板被退回（标准合同通道环节）｜依据：「leapcore 合同审核群」2026-08、「leapcore 合同审核群」2026-09
  • 现象：合同与报价单在模型范围、赠送数量上不一致，部分条款超出产品能力只能删除或模糊处理（一致性核对环节）｜依据：「leapcore合同审查」2026-06
  • 现象：修订靠群里发版本，必审人和会签清单没有固定（会签留痕环节）｜依据：「leapcore充值标准合同沟通」2026-09、「leapcore合同审查」2026-06
  • 现象：当天要签寄出时在群里催审（时限管理环节）｜依据：「leapcore 合同审核群」2026-09

9. 分支变体

  • 标准模板仅替换客户信息：起草人声明“标准模板、仅替换信息”并标出修改项，走快速通道报备核对，无意见即放行；一旦有条款改动转完整会审
  • 一体机/工作站销售合同：必须附硬件配置单，硬件审核为必审人；交付期以 IT 确认的可交付日期为准
  • 含定制开发（FDE）或新媒体、电竞等额外工作的合同：额外工作定价由技术负责人批注，报价走 SAL-21
  • 渠道代理协议：独家/非独家/钻石等级按 LEG-01 现行通用版
  • 试用合同：签约主体按 LEG-02 确定，转正式时同步核对
  • 词元充值服务合同：线上标准化部分走 LEG-08；线下签署附充值结算单、验收单
  • 赠送设备、战略框架、生态联盟协议：是否需要签合同由 CEO 拍板
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-03（决策记录与发布）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 主责是否为法务负责人？合同审核群与飞书合同审批两条入口，是否统一以飞书审批为准？
  • 快速通道 4 个工作小时、完整会审 3 个工作日是否可行？
  • 必审人清单：一体机合同是否都要硬件审核？充值合同是否都要 COO 再审？
  • “标准条款+红线+可让步清单”由谁起草、谁审定？
  • AI 预审报告是否作为提交的必备附件？
LEG-04采购/服务及其他对外合同、承诺函起草与审核待优化144

状态：待优化｜证据：有证据（卡片 8 张 / 会话 9 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：我方采购 API/大模型服务、硬件或技术服务，签一体机交付与服务合同、网络施工/装修/搬家/场地等工程类合同、保密协议模板，以及向客户出具承诺函、质保函等非销售类对外文件时，由法务审核定稿（含配套验收单/结算单）
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——总经办（当前：田杰·推断待确认）、业务负责人（当前：丁震宇、常元和·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、IT 硬件（当前：杨明学·推断待确认）、市场/渠道（当前：闫登辉·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 提交合同审核申请并写清交易背景 → ② 选模板或提交对方文本起草 → ③ 业务确认内容一致性 → ④ 法务审核并配套验收单/结算单 → ⑤ 财务核对付款开票税点 → ⑥ 定稿 → ⑦ 用印签署与付款 → ⑧ 归档
  • 交付结果：法务审定的对外合同（附验收单/结算单）、承诺函或质保函，飞书合同审核记录，后续用印与付款依据
  • 状态依据：飞书合同审核流程和用印流程已在使用，法务审条款、财务核付款开票已成习惯；但缺“业务内容一致性”确认节点和时限，04～10 月催法务、计费口径现场追问、一天改 3 版的情况约 10 次；非法务人员用 AI 起草合同后在群里找人看，首次出具质保函还跳过了审核

1. 场景判定

  • 触发条件：上游模型/云/API 服务需对公签约后充值；采购硬件或技术服务；一体机交付与服务合同；工程类合同（网络施工、装修、搬家、年会场地）；对方发来 NDA 模板；客户要求我方出具承诺函、质保函；合同附件需法务过目
  • 典型说法：「麻烦审核下这个合同」「有没有懂合同的帮我看看」「AI 写的合同像不像真合同」「业务内容是谁来审核一致性」「以后市场提质保函需求，先找 IT 填型号、参数、SN」
  • 判断问题：这份文件是对外有约束力的承诺或合同，且我方不是在“卖产品收款”吗？是 → 走本流程
  • 不归本流程管：销售合同 → 请走 LEG-03；客户项目 NDA、合作开发协议 → 请走 LEG-05；股东会决议、合资合伙协议 → 请走 LEG-06；云厂商在线发来的合同变更与代付协议 → 请走 LEG-07；用印 → 请走 LEG-09；采购申请与付款审批 → 请走 FIN-01；上游供应商询价与折扣谈判 → 请走 X-OTH-01；合同归档 → 请走 LEG-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提交申请、说明背景、与对方谈判、定稿 R 总经办（当前：田杰·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、IT 硬件（当前：杨明学·推断待确认）、研发（当前：王皓南·推断待确认）
法务 审核修订、配套验收单/结算单、提示需业务评估的条款 R/A 法务负责人（当前：李瑶·推断待确认）
业务负责人 确认标的、范围、SLA、计费模式、金额与预付款与实际一致；风险条款取舍、加急先行的升级决策 R/A（升级） 业务负责人（当前：丁震宇、常元和·推断待确认）
财务 核对付款、开票、税点条款，执行付款 C 财务负责人（当前：黄梦婷·推断待确认）
流程协调 流转合同、催办、跨部门协调 C 综合部负责人（当前：赵雪冰·推断待确认）
项目销售 交付与服务类合同由对应项目销售起草 R 对应项目销售（由市场销售负责人指派，当前：李鹏为·推断待确认）
质保函出文 出具质保函、核对与合同条款一致 R 市场/渠道（当前：闫登辉·推断待确认）
质保函技术复核 核对型号、参数、SN、响应时间 C 研发（当前：岳阳、宋祺睿·推断待确认）、产品负责人（当前：杨萌·推断待确认）
系统建设 合同及履约管理系统落地 I CMS 研发（当前：裴建武·推断待确认）

3. 办之前请准备

  • 对方主体全称、过往交易与开票回款情况
  • 计费模式（预充值/后付费/按月账单）、金额、预付款比例、付款与开票方式、税点
  • 对方文本或我方模板（优先模板库现行版本）；AI 生成的初稿须注明
  • 业务需求说明：标的、服务范围、SLA、对下游客户的承诺（用于核对上游条款能否兜住下游）
  • 质保函：机器型号、硬件参数、SN、对应销售合同的响应时间与质保条款
  • 期望签署日；工程类须写明施工/入场日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交飞书合同审核申请，必填对方主体、既往交易、计费模式、金额与预付款、我方主体、期望签署日，上传对方文本或模板稿 申请人 期望签署日前至少 3 个工作日（工程类至少 2 个工作日） 飞书合同审核流程 审核申请 🔧飞书固化
2 起草：优先用模板库；对方制式文本直接提交；非法务起草（含 AI 生成）标注“AI 初稿”并走完整审核；交付与服务合同由对应项目销售起草 申请人、项目销售 提交申请前完成 模板库、AI 合同 skill 合同初稿 🤖+👤
3 确认标的、范围、SLA、计费模式、金额与预付款与实际一致 业务负责人 收到后 1 个工作日内 飞书审批节点 业务确认 🔧+👤
4 审条款并出修订版与意见；标出需业务评估的条款（故障补偿、上游免责与下游承诺穿透）；配套验收单/结算单，写清当次结算金额 法务 业务确认后 2 个工作日内（加急 4 个工作小时） 修订模式、飞书审批 修订稿、验收单/结算单 🤖+👤
5 核对付款、开票、税点条款 财务 收到后 1 个工作日内 飞书审批 财务意见 👤人工判断
6 与对方确认修改；文件名加日期版本号；定稿 申请人 2 个工作日内 飞书云文档 定稿合同 🔧飞书固化
7 用印（鲜章或电子章，见 LEG-09）；付款或充值走 FIN-01 申请人、财务 定稿后 1 个工作日内 飞书用印审批、付款审批 已签合同、付款记录 🔧飞书固化
8 签署件与验收单/结算单归档并登记台账（见 LEG-11） 申请人 签署后 2 个工作日内 合同台账 台账记录 🔧飞书固化

5. 交付物与模板

  • 交付物：定稿合同、验收单/结算单、法务修订意见、承诺函/质保函、审核与用印记录
  • 建议模板/表单：
    • 合同审核申请字段：合同类型（采购/技术服务/交付与服务/工程/NDA/承诺函/质保函）、对方主体、既往交易、计费模式、金额、预付款、我方主体、对下游的承诺、期望签署日、是否 AI 初稿
    • 结算单/验收单字段：合同编号、结算期间、当次结算金额、计量依据（账单或用量）、双方确认签章
    • 质保函必填字段：客户全称、机器型号、CPU/内存/硬盘参数、数量、SN、质保期限、响应时间（与合同一致）、出具日期
    • 常用模板：采购合同、技术服务合同、一体机交付与服务合同、NDA（精简版）、质保函、承诺函

6. 异常与升级

  • 法务 2 个工作日未出意见 → 系统催办 → 再过 1 个工作日升级综合部负责人
  • 上游条款免责而我方对下游有服务保障 → 法务标出风险 → 升级业务负责人作为 A（升级）决定接受、改条款或调整下游承诺（2 个工作日内）；无此类风险时由法务负责人定稿放行
  • 预付款或金额在审核中调整 → 退回步骤 3 重新确认 → 财务同步更新付款计划
  • 周末或夜间紧急施工、紧急充值 → 先走加急通道 4 个工作小时内审完 → 无法完成的升级业务负责人决定是否先行（当天）
  • 质保函任一字段与合同或出货单不一致 → 立即拦截、不发客户 → 当天交技术复核后重出

7. 衡量指标

  • 审核周期 = 提交到定稿的工作日数，目标 ≤ 4 个工作日
  • 单份合同修订轮次 = 定稿前版本数，目标 ≤ 3
  • 追问率 = 法务因背景信息缺失而追问的合同数 / 合同总数，目标 ≤ 10%
  • 未经法务审核即签署的对外文件数，目标 0
  • 质保函一次通过率 = 复核无错误的质保函 / 出具总数，目标 100%

8. 低效诊断

  • 现象：非法务人员用 AI 起草采购合同、交付与服务合同，在群里找人看，没有法务审核记录（起草与审核衔接环节）｜依据：「模态集团（全员群）」2026-05、「鼎慧产研决策部」2026-06、「随便瞎聊啦～」2026-06
  • 现象：交付合同该由销售还是研发起草不清楚，没有模板每次重写（起草职责环节）｜依据：「随便瞎聊啦～」2026-06
  • 现象：合同交法务后进度看不到，靠协调人反复催（审核时限环节）｜依据：「【模态】总经办」2026-04
  • 现象：业务内容一致性由谁审核无人明确，预付款评估后下调导致合同再改（业务确认环节）｜依据：「【模态】总经办」2026-10
  • 现象：计费是预充值还是后付费要现场再问业务，一天内合同改了 3 版，夜间提交要求次日上午出（申请信息环节）｜依据：「【模态】董事会&法务」2026-10
  • 现象：周末网络施工、工程合同当晚才提交审核（提前量环节）｜依据：「【模态】综合部」2026-07、「【模态】总经办」2026-08
  • 现象：首次出具质保函跳过审核直接发销售，型号、内存、数量、SN、公司名、响应时间多处错误被紧急拦截（质保函复核环节）｜依据：「Leapcore 客户项目群（客户A）」2026-08
  • 现象：起草—审批—用印—归档全链路仍是飞书审批过渡，CRM 与合同系统双录（系统衔接环节）｜依据：「公司内FDE」2026-09

9. 分支变体

  • 海外 API 供应商：要求对公签合同后再充值，付款方式见 FIN-04
  • 大模型技术服务合同：上游制式条款难改，法务需对照我方对下游客户的承诺做穿透评估
  • AI 服务采购：以验收单/结算单作为结算依据，后付费按月账单结算，不必写余额
  • 工程类合同（施工、装修、搬家、场地）：由行政发起；押金类支出达到财务规定门槛的改为对公支付
  • NDA 模板：对方长模板需精简，客户项目 NDA 走 LEG-05
  • 质保函：市场提需求 → IT 填型号、参数、SN → 技术复核 → 市场复核与合同条款对照 → 法务审 → 盖章发客户；质保函必须与销售合同的响应时间、质保期一致
  • 承诺函/合同附件：同样提交飞书审核，不通过线下转送
  • 合同及履约管理系统上线后：按“上级 → 部门负责人 → 法务 → 财务”四级审批，提交人不能审自己的单；已签合同不改，通过补充、变更、续签、终止等衍生合同处理

10. 待确认问题

  • 主责是否为法务负责人？“业务内容一致性”确认人是否固定为业务负责人？
  • 外部法务顾问是否仍参与？是否统一在飞书内审核留痕？
  • 审核 2 个工作日、加急 4 个工作小时的时限是否可行？
  • 质保函由市场还是 IT 出具？是否需要单独的质保函模板与审批？
  • 合同及履约管理系统的上线时间，上线前飞书合同审核流程是否加“业务确认”节点？
LEG-05保密协议与外部合作（合作开发/非劳务）协议拟定待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 5 个）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：与客户、外部公司或非员工个人开展合作前，需要交换敏感资料（脱敏数据、PRD、代码方案）或界定合作关系时，先签保密协议、合作开发保密与知识产权协议或非劳务合作协议，再开放资料与权限
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——客户对接商务（当前：杨朋伟·推断待确认）、子公司负责人（当前：徐莉·推断待确认）、人事负责人（当前：黄莹·推断待确认）、FDE Leader（当前：黄振锋·推断待确认）、COO（当前：常元和·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 业务提出合作与资料交换需求 → ② 法务问询合作性质 → ③ 选模板起草或审对方文本 → ④ 业务与人事确认商务与人员安排 → ⑤ 跟踪对方审批节点 → ⑥ 用印寄送 → ⑦ 签署后开放资料与权限 → ⑧ 归档并设到期提醒
  • 交付结果：双方签署的保密协议/合作开发协议/非劳务合作协议，协议节点跟踪记录，资料与权限开放记录
  • 状态依据：客户项目 NDA 有法审版本但节点不透明，项目方反复催问，协议未签导致测试数据给不出；子公司与外部公司合作开发时没有直通法务渠道，二次开发的界定靠口头；非员工按成果计酬的协议“晚点再整”，每次都是临时处理

1. 场景判定

  • 触发条件：客户项目启动前需对方提供数据或我方提供方案；子公司或业务线与外部公司合作开发，需交付 PRD、代码技术方案；与非员工个人（按成果计酬人员、外部借调研发）建立合作；合资公司设立前的技术合作
  • 典型说法：「现在卡在保密协议，在走法审」「保密协议加速」「提供 PRD 和代码方案，数据资产怎么保护」「明面上不能是劳务关系」
  • 判断问题：合作开始前，对方或我方要拿到对方的非公开资料，或要明确成果归谁、关系是不是劳务？是 → 走本流程
  • 不归本流程管：采购、服务合同中附带的保密条款 → 请走 LEG-04；对外发送材料、代码权限的保密审查 → 请走 LEG-30；员工劳动合同、实习、劳务用工判定 → 请走 HR-04；劳务、顾问报酬结算 → 请走 FIN-14；软著申请 → 请走 POL-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
法务 问询合作性质、起草或审核协议、给出权属建议 R/A 法务负责人（当前：李瑶·推断待确认）
业务发起人 提出需求、提供背景、调整商务条款 R 客户对接商务（当前：杨朋伟·推断待确认）、子公司负责人（当前：徐莉·推断待确认）
对方节点跟踪 跟踪客户法审、立项、盖章、寄回 R 客户对接商务（当前：杨朋伟·推断待确认）
资料需求方 说明需要的数据范围，协议生效后接收 C FDE/运营负责人（当前：李凯·推断待确认）
人事 非劳务人员协议拟定、接入手续 R 人事负责人（当前：黄莹·推断待确认）
用人方 定合作方式与验收标准、挂靠项目 C FDE Leader（当前：黄振锋·推断待确认）
合作方式拍板 合作模式、二次开发界定、计酬方式 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
催办与升级 协议卡点时推动 C COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 合作对象全称及类型（客户/外部公司/个人）
  • 交换资料清单与密级（脱敏数据、PRD、代码方案、账号）
  • 合作性质：是否二次开发、成果是否用于其他项目、是否直接出售代码或授权使用
  • 计划开始提供资料的日期
  • 非员工合作：合作内容、按成果计酬方式、验收表、挂靠项目的立项文件
  • 对方文本（如由客户起草）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交合作协议申请：对象、资料清单、合作性质、计划日期，直接提给法务（不经创始人群中转） 业务发起人 计划提供资料前至少 5 个工作日 飞书审批/表单 协议申请 🔧飞书固化
2 问询：是否二次开发、成果用途、背景知识产权、是否涉及个人；必要时拉合作方式拍板人确认 法务 收到后 1 个工作日内 飞书群/文档 合作性质结论 👤人工判断
3 选模板起草（NDA / 合作开发协议 / 非劳务合作协议）或审核对方文本，写清保密范围、背景知识产权、成果归属、软著与授权使用 法务 问询完成后 2 个工作日内 模板库、修订模式 协议草稿 🤖+👤
4 业务按实际调整商务条款；非员工合作由人事确认不构成劳务关系的安排与接入手续 业务发起人、人事 2 个工作日内 飞书云文档 定稿协议 👤人工判断
5 跟踪对方节点（对方法审、立项、上会、盖章），在跟踪表更新状态 客户对接商务 每 2 个工作日更新一次 多维表格 节点跟踪记录 🔧+🤖
6 我方用印并寄出（见 LEG-09），登记寄出日期与快递单号 业务发起人 定稿后 1 个工作日内 飞书用印审批 寄出记录 🔧飞书固化
7 协议双签生效前不提供敏感资料、不开账号；生效后按资料清单开放并登记 业务发起人 生效当天 权限系统、资料外发记录 开放记录 👤人工判断
8 协议归档并设到期提醒（见 LEG-11） 业务发起人 收回原件后 2 个工作日内 合同台账 台账记录、到期提醒 🤖自动化

5. 交付物与模板

  • 交付物：签署的协议、节点跟踪表、资料与权限开放记录、到期提醒
  • 建议模板/表单：
    • 协议申请字段：合作对象、对象类型、协议类型、交换资料清单与密级、是否二次开发、成果用途、计划开始日期、我方主体
    • 节点跟踪表字段：协议名称、对方、当前节点（草稿/我方法审/对方法审/对方立项/盖章/寄出/签收/生效）、节点日期、卡点说明、下次跟进日
    • 模板：双向 NDA、合作开发保密与知识产权协议（背景知识产权、开发成果归属、授权使用）、非劳务合作协议（按成果计酬、验收表、不构成劳动关系条款）

6. 异常与升级

  • 对方内部审批超过 5 个工作日无进展 → 商务约对方对接人确认卡点 → 升级 COO 与对方高层沟通
  • 项目急需数据而协议未签 → 不提供资料、冻结账号 → 业务发起人可申请先签简版 NDA（法务 1 个工作日内出）
  • 二次开发或成果归属双方分歧、合作模式或计酬方式超出模板 → 法务给可选方案 → 升级合作方式拍板人（创始人兼 CTO）作为 A（升级）2 个工作日内决定；其余协议由法务负责人定稿
  • 非员工合作可能被认定为劳务关系 → 法务与人事评估 → 调整为外包或劳务合同（转 HR-04）

7. 衡量指标

  • 协议签署周期 = 申请提交到双签生效的工作日数，目标我方模板 ≤ 10 个工作日
  • 因协议未签导致项目延期的次数，目标 0
  • 协议生效前资料外发次数，目标 0
  • 节点跟踪表更新及时率 = 按时更新的协议数 / 在途协议数，目标 100%

8. 低效诊断

  • 现象：客户方法审、立项、盖章节点不透明，我方反复在群里问“流程走完没有”（节点跟踪环节）｜依据：「某基金客户项目群」2026-08
  • 现象：协议未签导致脱敏数据给不出，技能测试停滞（生效前管控环节）｜依据：「某基金客户项目群」2026-08
  • 现象：子公司没有直通法务的渠道，先在创始人群里问，再由创始人拉法务进群（申请入口环节）｜依据：「跃竞模态董事会」2026-10、「跃竞法务协助」2026-10
  • 现象：是否二次开发、成果是否用于其他项目靠口头判断，没有书面框架，只能请法务按通用模板现起草（模板与问询环节）｜依据：「跃竞法务协助」2026-10

9. 分支变体

  • 客户项目 NDA：客户起草时由我方法务审，客户内部还需立项、上会；后续正式合同与客户签，不直接与客户的出资方签
  • 合作开发：提供 PRD、代码方案前签保密与知识产权条款；建议同步申请软著并以授权方式给合作方或新公司使用；合资公司股权比例在合作协议中确定
  • 非劳务合作（按成果计酬人员）：按成果量计酬，保底与补贴写清，协议参照验收表；不写成劳务关系
  • 外部借调研发：面试后挂靠已立项项目，接入手续与账号开通走人事与 IT，协议须在开账号前签署

10. 待确认问题

  • 主责是否为法务负责人？子公司是否也直接对接集团法务？
  • 资料提供前 5 个工作日提交申请是否可行？
  • 非劳务合作协议是否已有成文模板？由法务还是人事拟定？
  • 外部借调人员挂靠项目的做法是否需要法务评估合规风险？
  • 是否需要建立“对外合作/资料外发”审批，并自动关联协议状态？
LEG-06股东会/董事会决议与合资合伙协议签署待新建120

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨3 × 险5

  • 适用场景：召开股东会/董事会表决，设立合伙企业或合资公司，签署对外补充协议或期权激励方案等公司治理类文件时，由管理层先读、法务审阅，按签署检查清单完成签署盖章
  • 负责人：主责——总经办（当前：田杰·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、协议起草人（当前：陈晖·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 登记文件与签署截止日 → ② 管理层在同一份文档批注商业意见 → ③ AI 风险初筛 → ④ 法务审阅 → ⑤ 定稿并按签署清单检查 → ⑥ 会议表决（如需） → ⑦ 签名用印 → ⑧ 归档并启动后续变更
  • 交付结果：法务审定并签署盖章的决议、合伙/合资协议、补充协议或期权文件，表决记录，签署检查清单
  • 状态依据：公司治理类文件在群里传阅，没有统一版本和审批流；合伙协议多处未填写就准备盖章，法务审查缺位，靠 AI 报告和合伙人逐条提意见；签署形式要求只是一条群消息，没有成文清单

1. 场景判定

  • 触发条件：股东会/董事会召开；子公司设立或注销决议；合伙企业、合资公司设立；对外补充协议；期权激励方案与授予协议；发现历史合作需要补协议
  • 典型说法：「给一套股东会/决议最小化文件实施方案」「没问题的话就去盖章走流程」「期权方案这周讨论出来，再让法务改」「这个得补协议」
  • 判断问题：文件是否涉及股权、出资、控制权、分成或需要股东/董事表决？是 → 走本流程
  • 不归本流程管：股东会会务筹备与材料准备 → 请走 CEO-22；期权方案的起草与审议 → 请走 CEO-23（本流程只管签署环节）；普通销售、采购合同 → 请走 LEG-03 / LEG-04；用印审批 → 请走 LEG-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程负责人 登记、收集意见、组织审阅、签署推进 R 总经办（当前：田杰·推断待确认）
法务 条款与形式审阅、签署清单把关 R 法务负责人（当前：李瑶·推断待确认）
管理层 商业条款意见（控股、技术出资作价、分成） C 创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
最终决策 是否签署、关键条款取舍 A CEO（当前：邴龙志·推断待确认）
协议起草 我方起草的协议、方案初稿 R 协议起草人（当前：陈晖·推断待确认）
发起人 引入对外合伙/合资事项、对接对方 R 市场销售负责人（当前：李鹏为·推断待确认）
签署要求与用印 定签署形式要求、盖章 R 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 文件草稿（Word 可编辑版）与对方版本来源
  • 文件类型、需签署的主体与签署人名单、签署截止日
  • 股权结构、出资方式与作价依据（技术出资需第三方鉴定方案）
  • 对应的股东会/董事会通知及材料
  • AI 风险分析报告（可选，作为参考）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记文件：类型、对方、签署主体、签署人、截止日，建立唯一在线版本 总经办 收到草稿当天 飞书云文档 + 台账 登记记录、唯一版本 🔧飞书固化
2 管理层在同一份在线文档批注商业意见（控股、技术出资作价、分成比例等） CTO、COO、发起人 3 个工作日内 飞书云文档评论 商业意见 👤人工判断
3 AI 风险初筛，列出未填写条款与风险点 总经办 与步骤 2 并行，1 个工作日内 AI 审查工具 风险清单 🤖自动化
4 法务审阅条款与形式，给出修改稿 法务 收到意见后 3 个工作日内 修订模式 法务修改稿 👤人工判断
5 定稿并按签署检查清单核对：无空白条款、不用授权委托书和签到表、骑缝章仅盖模态、日期一律手填、逐页检查空白页 总经办、法务 定稿当天 签署检查清单 定稿与核对记录 🔧飞书固化
6 需表决的：发会议通知，参会人实名入会、提前 10 分钟入会，逐项开麦表决并记录 总经办 会前 3 个工作日发通知 腾讯会议 表决记录 🔧飞书固化
7 签名与用印（可用手写签名电子印章，减少重复手签；用印见 LEG-09） 总经办、综合部负责人 表决或决策后 2 个工作日内 飞书用印审批 签署件 🔧飞书固化
8 归档并启动后续动作（工商变更、主体变更、授予通知），见 LEG-11 / CEO-22 总经办 签署后 3 个工作日内 档案台账 归档记录、后续待办 🔧飞书固化

5. 交付物与模板

  • 交付物：签署件、表决记录、法务意见、签署检查清单、归档记录
  • 建议模板/表单：
    • 治理文件台账字段：文件名称、类型（决议/合伙协议/合资协议/补充协议/期权文件）、签署主体、对方、签署人、截止日、当前状态、法务审阅人、归档位置
    • 签署检查清单：条款无空白；签署人与名单一致；授权委托书、签到表是否取消；骑缝章盖章主体；日期手填；空白页检查；附件齐全；股东会材料齐全
    • 会议表决记录：议题、表决人、同意/反对/弃权、时间

6. 异常与升级

  • 管理层 3 个工作日内意见未收齐 → 总经办催办 → 升级 CEO 决定是否先交法务
  • 文件仍有空白条款或未定事项 → 不得盖章 → 退回发起人补齐（2 个工作日内）
  • 技术出资作价、控股权有分歧 → 法务给方案 → CEO 召集管理层决定（5 个工作日内）
  • 事后发现历史合作缺协议 → 法务评估补签方案 → 总经办 5 个工作日内完成补签

7. 衡量指标

  • 签署周期 = 登记到签署完成的工作日数，目标 ≤ 10 个工作日
  • 形式瑕疵率 = 签署后发现漏签、空白、盖章错误的文件数 / 签署文件数，目标 0
  • 法务审阅覆盖率 = 经法务审阅的治理文件 / 签署的治理文件，目标 100%

8. 低效诊断

  • 现象：签署形式要求只是一条群消息，没有成文检查清单（签署检查环节）｜依据：「【模态】董事会&法务」2026-10
  • 现象：合伙协议在群里传阅，多处条款还没填写就准备盖章（定稿环节）｜依据：「【跃迁】合伙人会议」2026-04
  • 现象：法务审查缺位，靠 AI 风险报告和合伙人逐条提意见（法务审阅环节）｜依据：「【跃迁】合伙人会议」2026-05
  • 现象：方案在董事之间轮转，没有截止时间，先讨论完再交法务（意见收集环节）｜依据：「董事会」2026-03、「董事会」2026-05
  • 现象：事后才发现某销售公司的合作有问题需要补协议（事前审查环节）｜依据：「董事会」2026-06

9. 分支变体

  • 股东会/董事会决议：按签署检查清单走最小化方案；线上会议须实名入会并逐项表决
  • 合伙企业、合资公司设立：对方起草时须法务审阅，技术出资需第三方鉴定与作价依据
  • 期权激励：方案起草与审议见 CEO-23，授予协议签署走本流程
  • 对外补充协议、销售代理补协议：管理层先读后交法务，签署前确认主体是否变更

10. 待确认问题

  • 主责是否为总经办？签署要求是否由综合部负责人统一制定？
  • 签署检查清单中的“骑缝章仅模态”“日期手填”是否适用于全部主体？
  • 治理类文件是否都必须经法务审阅？外部律师何时介入？
  • 手写签名电子印章的使用范围与授权是否已有书面规定？
LEG-07云厂商合同与代付协议电子签署待优化18

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频2 × 耗1 × 跨3 × 险3

  • 适用场景：各云厂商/办公软件平台通过电子签平台发来合同变更、三方代付协议、代付合同等签署待办时，确认变更内容、按需法务审阅后完成电子签署并归档
  • 负责人：主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、IT 运维（当前：杨明学·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 收到签署待办并登记 → ② 拉取变更摘要 → ③ 判定快速签或法务审 → ④ 法务、财务确认（需要时） → ⑤ 授权签署人在平台签署 → ⑥ 下载归档并登记到期日 → ⑦ 通知财务与供应商台账更新
  • 交付结果：已签署的云厂商合同/代付协议 PDF、变更摘要、合同台账记录
  • 状态依据：云厂商平台自带电子签流程，签署能完成；但合同改了什么靠口头问，“不重要，签吧”直接通过，没有法务环节；签署记录只在签署人的个人通知里，没有统一归档

1. 场景判定

  • 触发条件：电子签平台推送签署待办；云厂商通知合同变更（折扣、价格目录、新增模型）；新增三方代付关系；需要对接新的电子签平台
  • 典型说法：「上云平台确认下合同」「合同改了啥，直接通过吗」「您有一个签署待办：三方长期代付协议」
  • 判断问题：是不是云厂商或其平台发起、我方只需确认签署的标准合同？是 → 走本流程
  • 不归本流程管：新增上游供应商的询价、折扣谈判与首签 → 请走 X-OTH-01；云账户充值付款 → 请走 FIN-03；需要我方大幅改条款的服务合同 → 请走 LEG-04；业务产品接入电子签 → 请走 LEG-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
云资源管理员 登记待办、拉变更摘要、判定通道、归档 R 云资源管理员（当前：宋祺睿·推断待确认）
业务确认 判断变更对业务的影响 C 研发技术负责人（当前：王皓南·推断待确认）
电子签对接 平台对接、账号与签署人配置 C IT 运维（当前：杨明学·推断待确认）
法务 审阅付款责任、代付、违约、数据条款 C 法务负责人（当前：李瑶·推断待确认）
财务 确认代付关系、付款与开票 C 财务负责人（当前：黄梦婷·推断待确认）
授权签署人 在平台加盖电子章与骑缝章 A 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 签署待办链接、云厂商名称、我方签约主体
  • 上一版合同（用于对比）
  • 本次变更说明（折扣、价格、新增模型、代付三方、付款方式）
  • 代付协议：被代付方、代付范围、期限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到待办后转发到合同受理入口并登记厂商、主体、协议类型、截止日 收到待办的人 收到当天 飞书表单/群 待办登记 🔧飞书固化
2 对比上一版，写变更摘要（折扣、价格、新增模型、付款、代付、违约、数据条款） 云资源管理员 1 个工作日内 电子签平台、AI 比对 变更摘要 🤖自动化
3 判定通道：仅价格目录或折扣更新且对我方无不利 → 快速签；涉及付款责任、代付、违约、数据、主体变更 → 法务审 云资源管理员、研发技术负责人 摘要完成当天 判定规则 通道结论 👤人工判断
4 法务审阅；财务确认代付关系与付款、开票 法务、财务 1 个工作日内 飞书审批 审阅意见 👤人工判断
5 授权签署人在平台签署（电子章、骑缝章） 授权签署人 通过后 1 个工作日内，且不晚于平台截止日 电子签平台 已签合同 🔧飞书固化
6 下载已签 PDF，存入合同库并登记到期日、代付关系（见 LEG-11） 云资源管理员 签署后 1 个工作日内 合同台账 归档记录 🤖自动化
7 通知财务与供应商台账更新 云资源管理员 归档当天 机器人通知 更新记录 🤖自动化

5. 交付物与模板

  • 交付物：已签 PDF、变更摘要、台账记录
  • 建议模板/表单：
    • 云厂商合同登记字段：厂商、我方主体、协议类型（主合同/变更/三方代付/代付合同）、变更摘要、通道（快速签/法务审）、签署人、签署日期、到期日、代付对象、存档链接
    • 快速签判定规则：仅价格目录更新、折扣不降、无新增付款义务、无主体变更

6. 异常与升级

  • 待办临近平台截止日仍未完成审阅 → 云资源管理员当天提醒签署人 → 升级创始人兼 CTO 决定是否先签
  • 变更含对我方不利的条款（折扣下降、责任加重） → 转法务审并与厂商商务沟通 → 3 个工作日内无结果升级创始人兼 CTO
  • 同一待办多次提醒仍未处理 → 机器人每日催办 → 超过 3 个工作日升级兜底人
  • 签署人不在岗 → 按授权名单由备签人签署 → 无备签人时升级兜底人

7. 衡量指标

  • 待办处理时长 = 收到到签署完成的工作日数，目标 ≤ 3 个工作日
  • 归档率 = 已归档的云厂商合同 / 已签署的云厂商合同，目标 100%
  • 变更摘要覆盖率 = 有变更摘要的签署 / 全部签署，目标 100%

8. 低效诊断

  • 现象：合同改了什么靠口头询问，判断“不重要”后直接通过，没有变更摘要和法务环节（变更确认环节）｜依据：「鼎慧产研决策部」2026-08
  • 现象：电子签平台对接要临时拉人建群，签署人与对接人不固定（平台对接环节）｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 合同变更确认：多为折扣或价格目录更新，满足快速签规则即可签
  • 三方代付协议、代付合同：必须经财务确认代付关系，并由法务审阅付款责任
  • 对外服务协议模板随签署待办附带：转 LEG-01 入模板库，不在个人聊天中留存

10. 待确认问题

  • 主责是否为云资源管理员？各云厂商的平台账号与签署人是否已登记？
  • 电子章授权签署人是否只有一人？是否需要设备签人（备签人）？
  • 快速签判定规则是否需要法务认可？
  • 云厂商合同是否纳入统一合同台账？
LEG-08业务电子合同（电子签）接入与线上签约待优化160

状态：待优化｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨5 × 险4

  • 适用场景：产品或业务需要在线签约（LeapCore 词元充值、行业版客户、渠道硬件合同、俱乐部与陪玩代签）时，接入电子签平台、配置并授权法务定稿的合同模板，上线后批量出具电子合同并存档
  • 负责人：主责——业务线产品负责人（当前：杨萌·推断待确认；跃竞线：徐莉·推断待确认）；协同——电子签接入研发（当前：陈锦杰、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、综合部/合同模板（当前：赵雪冰·推断待确认）、销售模板起草（当前：吴琪·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、前端（当前：魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、运营执行（当前：刘安达、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 立项明确签约场景 → ② 评估复用与平台采购 → ③ 法务定稿模板并定可变字段 → ④ 控制台配置与授权 → ⑤ 开发接入 → ⑥ 测试验收 → ⑦ 上线并发布操作手册 → ⑧ 运行存档与模板变更管控
  • 交付结果：上线可用的电子签约功能、已授权的合同模板、电子合同 PDF 存档、接入与授权手册、操作 SOP
  • 状态依据：LeapCore 侧已采购第三方电子签平台并跑通充值合同，跃竞侧已上线俱乐部合同代签；但正式批量合同模板、授权签署人、验收口径未定，模板授权规则只在口头流转，另一条业务线要重新接入时找不到原来的接入负责人

1. 场景判定

  • 触发条件：产品要上线线上充值或线上购买；客户合同要随订单自动生成；俱乐部入驻需开通合同代签；已上线的电子合同模板条款要改
  • 典型说法：「我们得接入电子合同上线功能了」「之前你们电子合同是谁接的」「模板改了就会失效，需要重新授权」「合同申请时不要让客户自己填名称」
  • 判断问题：是否需要由系统按模板批量生成合同、并在线完成签署？是 → 走本流程
  • 不归本流程管：合同模板条款本身的制定与修订 → 请走 LEG-01；云厂商发来的电子签待办 → 请走 LEG-07；单份销售合同审查 → 请走 LEG-03；俱乐部入驻与会员端配置 → 请走 X-DLV-38；支付联调与收款商户 → 请走 RND-66；充值开票 → 请走 FIN-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品负责人 立项、定签约场景与验收口径、上线 R/A 业务线产品负责人（当前：杨萌·推断待确认；跃竞线：徐莉·推断待确认）
接入研发 控制台模板配置、接口开发、授权维护 R 电子签接入研发（当前：陈锦杰、王子明·推断待确认）
前端 代签配置页、合同管理页 R 前端（当前：魏小东、陈真炎·推断待确认）
法务 模板定稿、模板变更审批 R 法务负责人（当前：李瑶·推断待确认）
模板起草 测试模板与业务规则 C 综合部（当前：赵雪冰·推断待确认）、销售（当前：吴琪·推断待确认）
财务 合同作为开票依据、额度充值与付款凭证核对 C 财务负责人（当前：黄梦婷·推断待确认）
测试 线上测试与验收 R 测试（当前：赵伟龙·推断待确认）
运营执行 俱乐部开通代签、充值额度 R 运营执行（当前：刘安达、宫经喜·推断待确认）
平台采购与授权 平台选型采购、授权签署人 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
条款终审 批量模板上线前终审 A（升级） COO（当前：常元和·推断待确认）
前期配置 平台账号、主体认证 C 云资源管理员（当前：宋祺睿·推断待确认）、IT 运维（当前：杨明学·推断待确认）

3. 办之前请准备

  • 签约场景说明：合同类型、签约双方、预计份数、是否需对方签署回传、是否作为开票依据
  • 法务定稿模板（来自 LEG-01 模板库）及可变字段清单（金额、甲方名称、日期、编号等）
  • 平台情况：公司已有电子签账号、主体认证、可复用的接入代码与经验
  • 授权签署人名单
  • 附件模板：充值结算单、验收单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：写清签约场景、份数、是否需对方回签、是否作为开票依据、上线日期 产品负责人 需求确定后 2 个工作日内 需求文档/工单 立项说明 👤人工判断
2 评估复用已有电子签接入（查接入手册与参考代码）；需新采购的走采购流程（FIN-01），先申请试用 接入研发、平台采购与授权人 5 个工作日内 接入手册、电子签平台 复用/采购结论 👤人工判断
3 法务定稿模板并确认固定条款与可变字段；产品确认；批量模板经条款终审 法务、产品负责人、COO 5 个工作日内 模板库 定稿模板、字段清单 🔧+👤
4 控制台配置“企业自有模板”：模板只放自动填充内容，不含需授权方手填内容；完成授权 接入研发 模板定稿后 2 个工作日内 电子签控制台 已授权模板 🔧飞书固化
5 开发接入：企业名称从渠道系统或客户资料拉取，不让客户手填；合同编号自动生成；签署顺序为客户先签、我方授权签署人复核后签 接入研发、前端 按迭代排期 业务系统、电子签接口 接入功能 🤖自动化
6 测试验收：企业名称注入、动态签署人、撤回、权限、附件生成；用试用额度测完再切正式 测试、产品负责人 上线前 3 个工作日 测试环境 验收记录 🤖+👤
7 上线并发布操作手册（含授权签署人名单、俱乐部开通步骤），更新接入与授权手册 产品负责人、接入研发 上线当天 飞书知识库 操作手册、接入手册 🔧飞书固化
8 运行：签完自动下载 PDF 存档并登记台账（见 LEG-11），作为开票依据；模板任何改动先经法务审批，改后重新授权 接入研发、财务 每份签署后自动；模板变更前 电子签平台、合同台账 存档、变更记录 🤖+👤

5. 交付物与模板

  • 交付物：电子签约功能、已授权模板、合同 PDF 存档、接入与授权手册、操作 SOP
  • 建议模板/表单：
    • 接入与授权手册字段：平台、主体账号、接口清单、模板 ID 与版本、模板授权状态、授权签署人、参考代码路径、维护人岗位
    • 电子合同台账字段：合同编号、模板版本、客户名称、金额、签署状态（待客户签/待我方签/已完成/已撤回）、签署日期、PDF 链接、关联订单、是否已开票
    • 俱乐部代签开通 SOP：对公打款并提供回单 → 获取俱乐部合同模板 → 后台配置模板并让俱乐部授权 → 在小助手中绑定合同与俱乐部 → 后台【平台管理】-【合同代签】开启开关并充值额度 → 把新手教程发给俱乐部

6. 异常与升级

  • 模板改动导致授权失效、签约中断 → 立即回滚到上一授权版本 → 接入研发当天完成重新授权
  • 试用额度过期、采购未完成，无法测试 → 产品负责人 1 个工作日内催办采购 → 升级平台采购与授权人
  • 是否需要对方签署回传等口径有分歧 → 产品负责人列选项、法务给意见 → 升级创始人兼 CTO 作为 A（升级）2 个工作日内定
  • 需新采购电子签平台、新增或变更授权签署人 → 升级创始人兼 CTO 作为 A（升级）审批；批量合同模板上线前 → 升级 COO 作为 A（升级）做条款终审（2 个工作日内）；其余上线与验收事项由业务线产品负责人拍板
  • 客户名称与订单主体不一致 → 阻断签署 → 回到客户资料修正后重发
  • 付款凭证人工核对不一致 → 暂停开通代签 → 财务 1 个工作日内核实

7. 衡量指标

  • 电子签约成功率 = 签署完成的合同 / 发起的合同，目标 ≥ 98%
  • 合同存档率 = 已自动存档 PDF / 已完成签署，目标 100%
  • 模板未经法务审批即变更的次数，目标 0
  • 代签开通时长 = 俱乐部打款到代签开通的工作日数，目标 ≤ 1 个工作日
  • 重复接入次数 = 新业务线重新从零接入的次数，目标 0

8. 低效诊断

  • 现象：另一业务线要接入时不知道原来谁接的，模板授权规则只在口头，需要重新问（经验沉淀环节）｜依据：「跃玩项目组」2026-07
  • 现象：合同模板与签署主体的法务审核在开发群里没有体现，付款凭证靠人工预览确认（模板审核与付款核对环节）｜依据：「跃玩项目组」2026-09
  • 现象：充值合同模板多轮改标点和错字，通用版由谁出不清楚（模板定稿环节）｜依据：「leapcore 合同审核群」2026-08、「leapcore 合同审核群」2026-09
  • 现象：是否需要对方签署回传反复讨论；试用过期无法测试、采购未完成（立项与采购环节）｜依据：「LeapPay」2026-07、「LeapPay」2026-08
  • 现象：合同填写逻辑多次调整，迟迟没有可批量出具的正式合同（模板与开发衔接环节）｜依据：「LeapPay」2026-08
  • 现象：俱乐部代签开通步骤只写在群消息里，执行人反复询问（操作手册环节）｜依据：「市场部」2026-08、「市场部」2026-09

9. 分支变体

  • LeapCore 词元充值：开口合同，除金额、甲方名称、日期外条款不变；附充值结算单、验收单；线上带合同可开专票，线下汇款另附合同
  • LeapCore 行业版客户、渠道硬件合同：企业名称从渠道系统拉取，可复用同一平台授权
  • 鼎慧产品：出货次数少时暂不接入，按 LEG-03 线下签署
  • 跃竞俱乐部合同代签：俱乐部付费代签，动态签署人；后台设合同管理页权限；与陪玩自签方式的差异待确认
  • 合同撤回：签署前可撤回，撤回记录保留

10. 待确认问题

  • 主责是否为业务线产品负责人？电子签接入维护人是否已随渠道系统开发交接？
  • 授权签署人是谁，是否需要备签人？
  • 正式批量合同模板何时定稿，是否需要 COO 终审？
  • 是否需要对方签署回传？电子合同能否作为专票开票依据？
  • 跃竞与 LeapCore 是否共用同一电子签主体账号？
LEG-09用章用印审批与盖章版本核对待优化240

状态：待优化｜证据：有证据（卡片 8 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：合同、协议、报价表、股东会/董事会决议、证明、函件、申报材料、授权文件等需要加盖公司印章（公章/合同章/法人章/骑缝章）时，先按类型和分级走审批，再核对版本后盖章、回传扫描件并归档
  • 负责人：主责——行政负责人（当前：胡则瑾·推断待确认）；协同——印章保管与盖章执行（当前：侯明月·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、总经办（当前：田杰·推断待确认）、飞书审批管理员（当前：黄莹·推断待确认）、各部门申请人；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 判定审批类型 → ② 法务/财务前置审核 → ③ 发起飞书审批 → ④ 分级审批 → ⑤ 锁定最终版 → ⑥ 打印并比对审批附件 → ⑦ 盖章登记 → ⑧ 回传扫描件 → ⑨ 原件交行政归档
  • 交付结果：与审批附件一致的盖章文件、上传至审批单的盖章扫描件、用印登记记录、交行政归档的纸质原件
  • 状态依据：2026-09 总经办已发布《合同申请&用章用印申请流程说明》，飞书审批「合同申请」「用章用印申请」「采购申请」齐备；但 2026-02 提出的“文件类型 × 金额”分级审批仍停留在聊天中，未写进审批条件；2026-06～08 仍有直接在群里发文件找人盖章、反复提醒约 4 次；合同金额/数字填错退回约 5 次；2026-09 出现合同多次修改后最终版未同步审批流，需人工比对

1. 场景判定

  • 触发条件：采购/销售/渠道合同、战略合作协议、咨询协议需要签署盖章；股东会/董事会决议、报价表（含配合第三方询价）、证明、函件、申报材料、授权文件、劳动合同等需要用印；对方要求骑缝章、法人章或在甲方位置盖章
  • 典型说法：「这个合同打印下来，最后盖个公司章加骑缝章，出个扫描件发群里」「其实有盖章申请的，你要不提一个试试」「合同类统一通过合同申请办理，无需另行发起用章」「最终的版本最好在审批流同步下」
  • 判断问题：① 这份文件要不要加盖公司实体章或电子章？② 它是合同类（走合同申请）还是非合同类（走用章用印申请）？③ 现在要盖的版本，是不是审批里通过的那一版？
  • 不归本流程管：合同条款起草与审查 → 请走 LEG-03（销售）/ LEG-04（采购及其他）；我方签约主体怎么选 → 请走 LEG-02；云厂商/电子签平台线上签署 → 请走 LEG-07 / LEG-08；合同编号、台账与原件查找 → 请走 LEG-11；营业执照、授权委托书、负责人签字材料 → 请走 LEG-10；采购申请与付款 → 请走 FIN-01；劳动合同主体与签署 → 请走 HR-04；印章与证照实物保管调用 → 请走 ADM-23；股东会/董事会决议、合资合伙协议的审阅、表决与签署组织 → 请走 LEG-06（本流程只管其中的用印环节）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 判定审批类型、准备定稿、发起审批、领取盖章件、对外交换并上传双签扫描件 R 各部门业务申请人
直属上级/部门负责人 审核业务必要性与条款合理性 R 各部门负责人
法务 合同类与高风险非合同类文件的条款、合规审核 R 法务负责人（当前：李瑶·推断待确认）
财务 金额、付款/开票条款、收付款主体审核 C 财务负责人（当前：黄梦婷·推断待确认）
分级审批人 按文件类型 × 金额终审 A 创始人团队（当前：邴龙志、常元和、丁震宇·推断待确认）
行政/印章管理 比对版本、盖章、用印登记、回传扫描件、纸质归档 R 行政负责人（当前：胡则瑾·推断待确认）；盖章执行（当前：侯明月·推断待确认）
总经办 维护流程说明、发布规则变更、合同台账衔接 R（规则） 总经办（当前：田杰·推断待确认）
审批流配置 按分级规则配置飞书审批条件分支 R 飞书审批管理员（当前：黄莹·推断待确认）
兜底 规则争议、加急与例外裁决 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 定稿文件电子版（docx/pdf），且与准备上传审批的附件是同一版本；多轮修改的附修订说明
  • 我方签约主体（武汉模态、模态跃迁、鼎慧、苏州主体等）与印章类型：公章/合同章/法人章/骑缝章，份数，是否需要法人签字
  • 采购合同：已通过的「采购申请」审批编号
  • 合同类：直属上级、法务、财务的前置审核意见
  • 对方主体全称、合同类型、合同金额（用于分级）
  • 回传要求：扫描件发给谁、原件是否要寄出及寄送地址

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定类型：合同类（采购/销售/渠道合同、战略合作协议）走「合同申请」，采购先走「采购申请」并关联；非合同类（证明、函件、申报材料、授权文件、决议、报价表）走「用章用印申请」 申请人 需求出现当天 飞书审批 正确的申请类型 🔧飞书固化
2 前置审核：合同类发法务、财务确认条款；核对正文金额、数量、主体与表单一致 申请人、法务、财务 提交审批前；法务、财务各 2 个工作日内反馈 飞书文档评论 前置审核意见 👤+🤖
3 发起审批：填主体、印章类型、份数、是否骑缝、合同类型、对方主体、金额，上传定稿并关联前置审批 申请人 前置审核通过后 1 个工作日内 飞书审批 审批单 🔧飞书固化
4 分级审批：按文件类型 × 金额自动路由到对应审批人，逐项核对关键信息后同意或退回 分级审批人 每个节点 1 个工作日内 飞书审批条件分支 审批结论 🔧+👤
5 版本锁定：审批中如需修改，撤回重提或更新审批附件；审批通过后正文不得再改，改了就重新提审 申请人 修改当天 飞书审批 唯一最终版附件 🔧飞书固化
6 打印并交行政；行政逐页比对打印件与审批附件（主体、金额、页数、签字页、骑缝要求） 申请人、行政 审批通过后 1 个工作日内 飞书审批 + 比对工具 比对通过记录 🤖+👤
7 盖章（含骑缝章、法人章），同步登记用印 行政/印章管理 收件当天；加急 2 小时内 用印登记表 盖章件、用印记录 🔧飞书固化
8 扫描盖章件，上传审批单并通知申请人；需寄出的登记快递单号 行政/印章管理 盖章当天 飞书审批附件 盖章扫描件 🔧飞书固化
9 双方签署完成后上传双签扫描件，纸质原件交行政归档，并触发合同台账登记 申请人 → 行政 双签后 3 个工作日内 飞书审批 / 合同台账 归档原件 🔧+🤖

5. 交付物与模板

  • 交付物：审批单（含最终版附件）、盖章件、盖章扫描件、双签扫描件、用印登记记录、纸质原件
  • 建议模板/表单：
    • 用印/合同申请表单字段：申请类型、我方主体、印章类型（多选）、份数、是否骑缝、是否需法人签字、文件类型（框架协议/业务合同/大额合同/入职协议/非合同类）、对方主体、金额、关联采购申请、前置审核意见附件、定稿附件、回传与寄送要求
    • 用印登记表字段：日期、审批单号、主体、印章类型、文件名称、份数、盖章人、比对结果、扫描件链接、原件去向（归档/寄出）

6. 异常与升级

  • 审批通过后合同又被修改 → 行政拒绝盖未审批版本，申请人撤回重提 → 涉及对方当天签署的，升级部门负责人协调加急审批（当天）
  • 表单金额/数字与正文不一致 → 审批人直接退回并注明差异 → 同一单退回 2 次以上，抄送部门负责人（1 个工作日内）
  • 盖章人不在岗 → 由印章 B 角盖章 → 无备岗时升级综合部负责人（半天内）
  • 先盖章后补流程 → 原则禁止；发现后 1 个工作日内补审批并记入用印登记 → 月度由综合部通报到流程环节
  • 盖章后发现缺签字页或缺页 → 补签替换页，被替换页作废登记 → 涉及对方已签版本的，告知法务（1 个工作日内）
  • 配合第三方询价的报价表、熟人采购是否可免法务 → 不得由申请人自行决定，按非合同类用印走部门负责人 + 法务审核 → 有争议升级综合部负责人
  • 拍板口径：正常用印由分级审批人按文件类型终审（A）；出现规则争议、加急插队、先盖章后补流程、盖章人无备岗等例外时，升级综合部负责人作为 A（升级）当天裁决

7. 衡量指标

  • 用印周期：审批通过到盖章扫描件上传的时长，目标 ≤ 1 个工作日
  • 审批外用印率：无审批单的盖章次数 / 总盖章次数，目标 0
  • 版本不一致拦截：盖章前比对发现不一致的件数 / 总件数，目标 ≤ 5%；盖章后才发现的件数目标 0
  • 退回率：因金额、主体、数字错误退回的审批数 / 总审批数，目标 ≤ 10%
  • 双签扫描件回传率：双签后 7 日内上传扫描件的合同 / 已双签合同，目标 100%

8. 低效诊断

  • 现象：用印需求在群里直接发文件找人盖章，无审批、无登记，需多次提醒才完成，盖章依赖单人在场｜依据：「董事会专项沟通群」2026-06、「董事会专项沟通群」2026-07
  • 现象：用印审批卡片已上线，但分级规则只在讨论中提出，初设“多人均审批”对低风险文件过重，未落到审批条件｜依据：「行政人事对接群」2026-02
  • 现象：合同审批表单数字填错靠审批人肉眼发现后退回，审批人同时审多份合同造成排队｜依据：「忠橙星行星引擎」2026-06
  • 现象：合同多轮修改后最终版未同步审批流，盖章前只能人工比对｜依据：「leapcore 合同审核群」2026-09
  • 现象：规则统一前采购、销售、战略协议审批类型混用、重复填写，纸质与电子分离，合同台账靠手动录入｜依据：「【模态】市场销售」2026-08、「【模态】业务负责人」2026-09
  • 现象：盖章后发现缺签字页需补盖替换；印章保管集中在一个岗位，有人不知道公章放在哪｜依据：「内务大主管」2026-01、「内务大主管」2026-02

9. 分支变体

  • 合同类审批链：申请人 → 直属上级 → 部门负责人 → 法务 → 财务 → 按类型分支到管理层或董事会 → 行政盖章归档
  • 非合同类审批链：申请人 → 直属上级 → 部门负责人 → 法务 → 对应印章负责人 → 行政
  • 分级档位（聊天中提出，待成文）：框架协议由单一负责人审；业务合同（初步线 [阈值待财务确认] 以内）由对应业务负责人审；大额合同由三位创始人共审；入职/劳动协议一人审
  • 多主体：武汉模态、模态跃迁、鼎慧、苏州主体各有印章，必须在表单中选对主体；苏州主体的协议由苏州负责人对接当地盖章寄送
  • 批量用印：子公司股东会决议等多份同类文件可一次审批、逐份登记
  • 繁星计划试用合同等走特批；云厂商/办公软件平台合同下载确认后走 LEG-07

10. 待确认问题

  • 主责是行政负责人，还是由盖章执行岗直接负责？印章 A/B 角分别是谁？
  • 分级四档和金额阈值（初步线 [阈值待财务确认]）是否定稿？大额合同是否仍由三位创始人共审？谁负责写入飞书审批条件？
  • 法务、财务前置审核各 2 个工作日、盖章 1 个工作日的时限是否可行？
  • 步骤 2 的法务、财务前置审核与审批链中的法务、财务节点是否重复？是否合并为审批链内一次审核？
  • 用印登记表是否已存在？若无，是否用多维表格并与审批单自动联动？
  • 配合第三方询价出具的报价表盖章、熟人采购是否可免法务审，口径是什么？
  • 是否计划引入电子签章，哪些文件类型优先电子化？
LEG-10公司证照、授权委托书与负责人签字材料提供待优化81

状态：待优化｜证据：有证据（卡片 2 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：ICP/网站备案、软件分发认证、企业开发者注册、短信签名、云服务开通、合作协议签署等需要营业执照、授权委托书、承诺书、在职证明，或需法定代表人/指定负责人签字盖章时，出具合规的盖章版材料
  • 负责人：主责——行政/印章管理（当前：侯明月·推断待确认）；协同——综合部证照提供（当前：赵雪冰·推断待确认）、苏州主体资料对接（当前：刘昱潇·推断待确认）、申请人（IT 运维/后端运维，当前：杨明学、宋祺睿·推断待确认）、授权签字人（当前：待指定）、协议审核（当前：邴龙志、常元和·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 申请人列材料清单 → ② 确认主体与签字人 → ③ 从证照库取最新版 → ④ 套模板起草授权书/承诺书 → ⑤ 发起用章用印申请 → ⑥ 签字盖章 → ⑦ 回传并登记
  • 交付结果：符合平台要求的盖章版证照复印件/扫描件、授权委托书、承诺书、在职证明，签字人与用印记录可追溯
  • 状态依据：已有「用章用印申请」审批，但证照没有统一存放库：2026-04～07 每次办备案、认证都要在群里问谁有最新营业执照，因不清晰、带水印被平台退回约 3 次；出现先在群里盖章、后被提醒补申请；2026-10 短信签名授权委托书的负责人未指定，签字人难联系，临时讨论代签

1. 场景判定

  • 触发条件：外部平台（云厂商、应用商店、短信服务商、备案系统）要求上传营业执照、授权委托书、承诺书、法人/负责人签字件；合作协议或研究院协议要求盖章寄送；员工在职证明
  • 典型说法：「营业执照申请一份」「有没有不带水印的」「新增短信签名有个授权委托书，这个负责人有指定么」「负责人联系不上，能不能找人代签」
  • 判断问题：外部平台要的是公司身份材料或签字授权，而不是一份需要双方谈判的合同？如果要签的是合同正文，走 LEG-09
  • 不归本流程管：证照原件保管、版本更新与借阅登记 → 请走 ADM-23；ICP/App 备案办理本身 → 请走 LEG-23；域名购买与备案 → 请走 X-SEC-20；合同盖章 → 请走 LEG-09；平台账号、年检与年报 → 请走 GEN-14；申报用公司基础资料 → 请走 POL-03；营业执照补领、工商变更 → 请走 FIN-38

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 列明平台要求、套模板起草、发起申请、上传平台并反馈结果 R 申请部门经办人（当前：杨明学、宋祺睿·推断待确认）
行政/印章管理 提供证照扫描件、盖章（含电子章）、用印登记、寄送 R/A 行政/印章管理（当前：侯明月·推断待确认）
证照库维护 保证证照库为最新、高清、无水印版本 R 综合部（当前：赵雪冰·推断待确认）
子公司资料对接 提供苏州等主体的证照与印章 R 苏州主体负责人（当前：刘昱潇·推断待确认）
授权签字人 法定代表人或被授权负责人签字 R 授权签字人（当前：待指定）
审核人 协议类材料内容审核 C 管理层（当前：邴龙志、常元和·推断待确认）
兜底 签字人、代签与主体争议裁决 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 平台的材料要求原文或截图（格式、清晰度、是否需水印、是否需彩色盖章、是否需手写签字）
  • 办理主体（武汉模态跃迁、苏州模态、鼎慧等）及平台上登记的负责人/联系人
  • 平台提供的授权委托书、承诺书模板；在职证明使用公司模板
  • 签字人姓名与联系方式（向综合部确认，不在群里公开证件信息）
  • 用途说明与截止日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 列材料清单：哪个主体、要哪些证照/文件、格式要求、截止日 申请人 平台提出要求当天 飞书文档/备案材料清单模板 材料清单 🔧飞书固化
2 确认主体和签字人：对照授权签字人名单确定由法定代表人还是指定负责人签字；名单中没有的，提交综合部指定 申请人、综合部 1 个工作日内 授权签字人名单 签字人确认 👤人工判断
3 从证照库下载最新、高清、无水印版本；库中没有或过期的，由证照库维护人补齐 申请人、证照库维护 当天；补齐 1 个工作日内 飞书云盘证照库 证照文件 🔧飞书固化
4 按平台模板填写授权委托书/承诺书，或用公司模板生成在职证明 申请人 当天 模板库 待签文件 🤖自动化
5 发起「用章用印申请」，附平台要求、待签文件、签字人、用途 申请人 起草完成当天 飞书审批 审批单 🔧飞书固化
6 签字人签字（线下或电子签），行政盖章；使用电子章或签字章须在审批单中注明 授权签字人、行政 审批通过后 1 个工作日内 线下 / 电子签 签字盖章件 👤人工判断
7 扫描回传并上传审批单；需寄送的登记单号；平台审核结果回填 行政、申请人 盖章当天；平台结果出来后 1 个工作日内 飞书审批 扫描件、结果记录 🔧飞书固化

5. 交付物与模板

  • 交付物：盖章版证照扫描件、授权委托书、承诺书、在职证明、用印记录、平台审核结果
  • 建议模板/表单：
    • 证照库字段：主体、证照类型、版本日期、是否高清无水印、文件链接、有效期、维护人
    • 授权签字人名单字段：主体、法定代表人、被授权负责人、可签事项范围、是否允许代签、签字章保管人
    • 常用材料清单：ICP 备案、软件分发认证、开发者注册、短信签名、云服务开通各需哪些材料

6. 异常与升级

  • 平台退回（不清晰、带水印、过期）→ 证照库维护人 1 个工作日内补高清版 → 同一主体第 2 次退回，升级综合部负责人检查证照库
  • 平台要求的负责人未指定 → 申请人提交综合部 → 1 个工作日内由综合部负责人指定
  • 签字人联系不上 → 不得私下代签；需代签的，先取得签字人书面授权并在审批单注明 → 2 个工作日仍无法签字，升级综合部负责人
  • 群内已先盖章 → 1 个工作日内补「用章用印申请」并登记
  • 不同主体章、法人不同 → 以主体在平台登记信息为准，由子公司资料对接人核对
  • 拍板口径：常规材料出具由行政/印章管理岗确认放行（A）；签字人未指定、需代签、主体归属有争议或同一主体被平台二次退回时，升级综合部负责人作为 A（升级）在 1 个工作日内裁决

7. 衡量指标

  • 材料一次通过率：首次提交即被平台接受的次数 / 总次数，目标 ≥ 90%
  • 材料出具周期：提出需求到拿到盖章签字件的工作日，目标 ≤ 2 个工作日
  • 补流程率：先盖章后补申请的次数 / 总次数，目标 0
  • 证照库完整率：各主体常用证照在库且为最新版本的比例，目标 100%

8. 低效诊断

  • 现象：不知道谁手里有最新营业执照，每次办理都在群里逐个问｜依据：「网站备案材料筹备」2026-04、「网站备案材料筹备」2026-07
  • 现象：营业执照不够清晰或带水印被云厂商、平台退回，多次返工｜依据：「网站备案材料筹备」2026-04、「网站备案材料筹备」2026-05
  • 现象：先在群里盖章，事后被提醒应走盖章申请，用印不留痕｜依据：「网站备案材料筹备」2026-04
  • 现象：外部平台要求的负责人未指定、签字人难联系，临时讨论代签，合规边界不清｜依据：「忠橙星行星引擎」2026-10
  • 现象：不同主体的章与法定代表人不同，经办人需反复确认找谁盖、寄到哪里｜依据：「苏州模态跃迁」2026-07

9. 分支变体

  • 主体差异：苏州模态、武汉模态跃迁、鼎慧文跃分别使用各自的证照、印章和法定代表人
  • 签字方式：法定代表人亲签 / 被授权负责人签字 / 签字章 / 电子签
  • 在职证明：使用 WPS 模板，可用电子章
  • 研究院合作协议：盖章后按对方要求寄送，寄送信息记入审批单

10. 待确认问题

  • 主责是行政/印章管理岗，还是综合部？证照库由谁维护、放在哪个云盘目录？
  • 各主体的授权签字人名单是否已有？是否允许代签，代签需要什么书面授权？
  • 签字章是否存在、由谁保管、使用是否需单独审批？
  • 2 个工作日出具周期是否可行？
  • 是否需要把常见平台（ICP、软件分发、短信签名）的材料清单做成固定模板？
LEG-11合同编号、台账与原件归档待新建144

状态：待新建｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：合同（含订货单、战略/三方协议、云厂商电子合同）签署前需要编号，签署完成后需登记台账、归档原件；或尽调、报销、审计、查账需要查找合同时
  • 负责人：主责——总经办合同管理（当前：田杰·推断待确认）；协同——编号规则拍板（当前：丁震宇·推断待确认）、系统对接研发（当前：陈锦杰·推断待确认）、合同经办人（销售，当前：吴琪、时建、刘昱潇·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、财务（当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 审批通过时取号 → ② 编号写入合同正文与订货单 → ③ 双签后上传扫描件并登记台账 → ④ 原件交行政入柜并记录位置 → ⑤ 借阅登记 → ⑥ 每季度核对补录
  • 交付结果：全公司唯一编号的合同台账（可按主体、对方、类型、状态检索）、扫描件云盘、原件存放位置可查的档案柜
  • 状态依据：2026-08 提出“合同编号、订货单编号谁统一管理发放”，答复为“暂时没有，只能手搓”，两套编号规则并存；2026-08 启动合同整理时只能在群里问谁签过合同；战略合作协议签完后被要求“做好归档”但未指定归档人和位置；没有原件存放位置记录

1. 场景判定

  • 触发条件：合同审批通过需要编号；双方签署完成；对方寄回原件；尽调、报销、审计、查账、验收需要调阅合同；季度合同清理
  • 典型说法：「合同编号，订货单编号，这些谁在统一管理和发放」「现在做合同整理，看有没有历史合同要处理」「做好协议归档」「这份协议签好了，最终版发群里了」
  • 判断问题：这件事是在“给合同一个身份、记下来、放好、找得到”吗？如果是在谈条款或走盖章，不走本流程
  • 不归本流程管：合同条款审查 → 请走 LEG-03 / LEG-04；用印审批 → 请走 LEG-09；收入合同回款与收入确认 → 请走 FIN-21；开票 → 请走 FIN-19；集团档案管理办法与非合同档案 → 请走 GEN-11；电子签平台接入 → 请走 LEG-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
合同管理员 维护编号规则与台账、季度核对、借阅登记 R/A 总经办合同管理（当前：田杰·推断待确认）
编号规则决策 确定全公司统一编号规则 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
系统对接 在业财一体/渠道系统实现自动编号与台账同步 R 研发（当前：陈锦杰·推断待确认）
合同经办人 取号、上传双签扫描件、交原件、填台账必填字段 R 合同经办人（当前：吴琪、时建、刘昱潇·推断待确认）
销售负责人 督促销售合同按时归档 C 销售负责人（当前：李鹏为·推断待确认）
行政 原件入柜、记录存放位置 R 行政（当前：待指定）
财务 使用台账做开票、对账、审计 I 财务（当前：待指定）
申请人/各部门 调阅借阅登记与归还；历史合同清理时申报手头合同 R 各部门调阅人、经办人
兜底 归档责任争议、缺失合同追索 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 已通过的合同审批单号
  • 合同类型（销售/渠道/项目制/充值/采购/战略/三方/云厂商电子合同）、我方主体、对方主体
  • 双签扫描件（PDF）或电子合同下载件
  • 纸质原件份数
  • 查找时：合同对方、大致签署时间、用途（尽调/报销/审计）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合同审批通过时自动生成合同编号（订货单编号同规则另设类型码） 系统 / 合同管理员 审批通过即时 多维表格自动编号 / 业财一体系统 合同编号 🤖+👤
2 编号写入合同正文首页和订货单，盖章前由行政核对 合同经办人 盖章前 合同模板 带编号定稿 🔧飞书固化
3 双签后上传扫描件，填写台账必填字段 合同经办人 双签后 3 个工作日内 合同台账 台账记录 🔧飞书固化
4 原件交行政入柜，台账回填存放位置；云厂商等电子合同下载 PDF 存入云盘 合同经办人、行政 收到原件后 3 个工作日内 档案柜 + 云盘 原件位置记录 👤人工判断
5 调阅：申请人在台账查编号与位置，借原件需登记，用完归还 申请人、行政 借阅不超过 5 个工作日 借阅登记表 借阅记录 🔧飞书固化
6 每季度首月：台账与审批单、财务收付款记录比对，追补缺失扫描件和原件 合同管理员 每季度首月 10 日前 多维表格 缺失清单 🤖+👤
7 历史合同一次性清理：各部门申报手头合同，补编号、补登记 合同管理员、各部门 启动后 15 个工作日内 多维表格表单 历史合同台账 🔧+👤

5. 交付物与模板

  • 交付物：合同台账、扫描件云盘目录、原件档案柜、借阅登记、季度缺失清单
  • 建议模板/表单：
    • 编号规则（待确认）：主体代码-合同类型-年份-四位序号，例如“模态跃迁-销售-2026-0001”；产品线如需区分，在类型码中加产品系列
    • 台账字段：合同编号、审批单号、合同名称、合同类型、我方主体、对方主体（客户可用代号）、签署日期、起止日期、状态（履行中/已完结/终止）、经办人、扫描件链接、原件份数、存放位置、借阅状态
    • 云盘目录：主体 / 年份 / 合同类型 / 编号_对方_名称.pdf

6. 异常与升级

  • 合同找不到原件 → 查台账与审批单，联系经办人 → 3 个工作日找不到，用双签扫描件替代并记录缺失，升级综合部负责人
  • 有合同无审批（历史遗留）→ 补登记并标注“历史补录”，由法务补看 → 涉及在履约的，5 个工作日内补审批
  • 编号冲突或重复 → 以台账为准作废后发的号 → 合同管理员当天修正，通知财务
  • 经办人超期未上传 → 系统提醒经办人 → 再超 3 个工作日，抄送其部门负责人
  • 拍板口径：日常编号、登记、归档由合同管理员负责（A）；需新定或变更全公司编号规则时，升级创始人兼 CTO 作为 A（升级）决定；归档责任争议、原件 3 个工作日仍找不到时，升级综合部负责人作为 A（升级）裁决（1 个工作日内）

7. 衡量指标

  • 归档及时率：双签后 3 个工作日内完成扫描件 + 台账登记的合同 / 已双签合同，目标 ≥ 95%
  • 原件可定位率：台账中有明确存放位置的合同 / 全部纸质合同，目标 100%
  • 查找时长：从提出调阅到拿到文件的时间，目标电子件 ≤ 10 分钟、原件 ≤ 1 个工作日
  • 编号覆盖率：有统一编号的合同 / 全部合同，目标 100%

8. 低效诊断

  • 现象：合同编号、订货单编号无人统一发放，只能手工编，出现两套规则提议｜依据：「leapcore 合同审核群」2026-08、「leapcore 合同审核群」2026-09
  • 现象：合同散落在各经办人手里，启动合同整理时没有集中台账，只能在群里问谁签过哪些合同｜依据：「字字可研项目群」2026-08
  • 现象：战略/三方协议签完只在群里发最终文件，版本靠文件名日期区分，归档人和位置未指定｜依据：「某金控客户项目总协调沟通」2026-08、「某金控客户项目总协调沟通」2026-10

9. 分支变体

  • 合同类型：销售 / 渠道 / 项目制 / 充值 / 采购 / 战略合作 / 三方协议，编号类型码区分
  • 云厂商电子合同：从平台下载存档，台账标注“电子合同”，无纸质原件
  • 多主体：武汉模态、模态跃迁、鼎慧、苏州主体分别编号或在编号中带主体码
  • 系统化：后续集成到业财一体系统/渠道系统自动编号，LeapCore 侧只展示已出合同

10. 待确认问题

  • 合同管理员是总经办还是法务？原件由行政还是法务保管？
  • 编号规则选哪一套（主体-类型-年份-序号，或产品+渠道+日期+随机码）？订货单是否独立编号？
  • 是否已有集团档案管理办法覆盖合同台账，与 GEN-11 如何分工？
  • 业财一体系统上线前，是否先用飞书多维表格自动编号过渡？
  • 历史合同一次性清理的截止时间和范围？
LEG-14专利审查意见答复与状态同步待优化108

状态：待优化｜证据：有证据（卡片 1 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：代理师发来修改意见、国家知识产权局下发审查意见通知书/补正通知/受理通知等官文时，指派发明人在期限内答复，并同步全部在途案件状态
  • 负责人：主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——发明人/技术答复（当前：丁震宇·推断待确认）、专利转让对接（当前：常元和·推断待确认）、外部代理师；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 官文/意见统一接收 → ② 登记台账并算期限 → ③ 指派发明人 → ④ 发明人答复 → ⑤ 代理提交 → ⑥ 核对代理系统状态 → ⑦ 每周推送汇总 → ⑧ 结案
  • 交付结果：每件官文均在期限内完成答复，专利台账状态与代理系统一致，每周一份在途案件状态汇总
  • 状态依据：答复动作固定（代理邮件 → 群里提醒发明人 → 发明人回复 → 总经办核对），但没有统一看板：2026-04 双方都不确定是谁没回复；2026-05 代理把多篇专利混淆，发明人不知道要改什么；2026-10 仍在问代理是否已联系发明人；状态汇总靠人工问答

1. 场景判定

  • 触发条件：代理师发来调整意见或初稿修改建议；官文到达（受理通知、手续合格通知、补正通知、审查意见通知书、授权/驳回通知）；外部受让专利进入实审
  • 典型说法：「代理师发了调整意见没收到你回复」「专利状态更新」「这件显示发明人修改中」「是不是这个代理还没联系你」
  • 判断问题：案件是否已经递交（或已发代理撰写）且有一份待处理的意见/官文？还没递交的新提案走 POL-11
  • 不归本流程管：新提案、交底与首次递交 → 请走 POL-11；专利激励兑现 → 请走 LEG-15；商标官文 → 请走 LEG-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识产权归口 接收官文、登记期限、指派、催办、核对状态、周报 R/A 总经办（当前：赵雪冰·推断待确认）
发明人 针对意见做技术答复或修改 R 发明人（当前：丁震宇·推断待确认）
外部代理师 转达官文、起草答复、提交 R（外部） 专利代理机构
转让对接 受让专利的权利人变更与后续审查对接 C COO（当前：常元和·推断待确认）
兜底 逾期风险、放弃/撤回决策 A（升级） 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 官文或代理意见原件（PDF/邮件），标注内部编号与案号
  • 官方答复期限（以官文载明为准）和代理要求的内部回复日
  • 该案的最新定稿与历次修改记录
  • 发明人对应关系（台账中查）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 要求代理所有邮件发往统一知识产权邮箱，官文卡片推送到知识产权群，标题带内部编号和案号 知识产权归口 长期规则 共享邮箱 + 群机器人 统一入口 🔧+🤖
2 登记台账：官文类型、到达日、官方期限、内部回复截止日（官方期限前 15 个自然日） 知识产权归口 到达后 1 个工作日内 多维表格 期限记录 🔧+🤖
3 指派发明人，在群里或任务中写清“哪一件、改什么、何时前” 知识产权归口 登记当天 飞书任务 指派任务 🔧飞书固化
4 发明人答复：代理修改意见 5 个工作日内；审查意见在内部截止日前给出技术答复 发明人 见左 邮件/文档 答复意见 👤人工判断
5 代理整理答复并提交，回传提交回执 外部代理 内部截止日后 5 个工作日内，且早于官方期限 邮件 提交回执 👤人工判断
6 核对代理系统状态与台账一致，更新“下一步责任人” 知识产权归口 收到回执后 1 个工作日内 台账 更新后状态 🤖自动化
7 每周一机器人推送：待发明人回复、代理处理中、临近期限（14 天内）清单 知识产权归口 每周一 飞书机器人 周状态汇总 🤖自动化
8 结案：授权（转缴年费提醒）、驳回（评估复审）、撤回/放弃（记录原因） 知识产权归口 结果到达后 3 个工作日内 台账 结案记录 👤人工判断

5. 交付物与模板

  • 交付物：答复意见、提交回执、更新后的专利台账、每周状态汇总
  • 建议模板/表单：
    • 官文登记字段：内部编号、案号、名称、官文类型、到达日、官方期限、内部截止日、指派发明人、代理师、状态（待发明人/代理处理中/已提交/已结案）、回执链接
    • 周汇总格式：已定稿提交 N 件｜待发明人回复 N 件｜代理优化中 N 件｜14 天内到期 N 件

6. 异常与升级

  • 发明人超过内部截止日未答复 → 知识产权归口当天提醒并抄送 CTO → 距官方期限 7 天仍未答复，升级综合部负责人决定延期请求或放弃
  • 代理混淆案件 → 要求代理按内部编号重发并书面确认 → 再次出错，评估更换代理
  • 不清楚是发明人没改还是代理没改 → 以台账状态与邮件时间线为准，1 个工作日内澄清
  • 审查意见认为创造性低、客体不适格 → 发明人与代理评估答复胜算，不建议继续的提交综合部负责人决定放弃
  • 拍板口径：常规答复与状态同步由知识产权归口负责（A）；距官方期限 7 天仍未答复需决定延期或放弃、或案件拟撤回/放弃时，升级综合部负责人作为 A（升级）在 1 个工作日内决定

7. 衡量指标

  • 按期答复率：在官方期限内提交答复的官文 / 全部需答复官文，目标 100%
  • 内部截止日达成率：发明人在内部截止日前答复的比例，目标 ≥ 90%
  • 状态一致率：台账状态与代理系统一致的案件 / 在途案件，目标 100%
  • 周报准时率：每周一推送的周数 / 总周数，目标 100%

8. 低效诊断

  • 现象：代理意见发出后双方都不确定是谁没回复，需要来回确认｜依据：「【模态】知识产权」2026-04
  • 现象：代理把多篇专利混淆，发明人不知道要改哪一件｜依据：「【模态】知识产权」2026-05
  • 现象：在途案件状态靠人工在群里问答后汇总｜依据：「【模态】总经办」2026-04、「【模态】综合部」2026-04
  • 现象：新案件分配后代理是否已联系发明人无人知晓｜依据：「【模态】知识产权」2026-10

9. 分支变体

  • 代理撰写阶段的修改意见：内部流转，无官方期限，按 5 个工作日处理
  • 国知局审查意见：以官文期限为准，最高优先级
  • 受让专利：先完成权利人变更，再进入实审跟进
  • 不建议继续的提案（创造性低、客体风险）：由技术负责人筛选后结案

10. 待确认问题

  • 主责与兜底目前是同一人，是否设立知识产权专员，由综合部负责人兜底？
  • 是否已有共享知识产权邮箱？代理能否改为发往共享邮箱？
  • 内部截止日设为官方期限前 15 个自然日是否合适？
  • 发明人答复是否全部需 CTO 复核，还是发明人可直接回复代理？
LEG-15专利挖掘培训与知识产权激励申报待新建32

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗2 × 跨4 × 险2

  • 适用场景：公司推动员工进行专利挖掘与交底撰写时，组织专利培训，并在专利/软著达到节点后按知识产权激励办法申报、核验、兑现奖金或积分
  • 负责人：主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——培训组织（总经办，当前：王欣·推断待确认）、激励口径与技术把关（当前：丁震宇·推断待确认）、人事（积分/奖金发放，当前：待指定）、财务（当前：待指定）、研发员工（当前：季学森、郭逸非·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 制定激励办法与积分口径 → ② 发布并宣贯 → ③ 组织专利挖掘培训（线下 + 录屏）→ ④ 收集专利线索 → ⑤ 节点达成后员工申报 → ⑥ 按台账核验 → ⑦ 审批 → ⑧ 公示与兑现
  • 交付结果：成文的知识产权激励办法、培训录屏与资料、专利线索清单、经审批的激励兑现记录
  • 状态依据：2026-07 已组织代理机构专利培训并宣布试行激励、专利申请费用由公司承担；但激励细则没有成文，软著是否有奖励在群里即时口头回答，积分手册仍在编写，申报与核验流程空白

1. 场景判定

  • 触发条件：公司启动年度/批次专利挖掘；新员工或新研发组需要专利撰写培训；员工的专利递交、授权或软著下证，需申报激励
  • 典型说法：「帮公司写专利有奖金」「软著暂无奖金，应该有积分」「公司特邀合作专利代理机构讲师开展专题培训」
  • 判断问题：这件事是“教员工挖专利”或“给做出知识产权的员工兑现激励”吗？具体专利怎么写、怎么报，走 POL-11
  • 不归本流程管：专利申报流转 → 请走 POL-11；审查意见答复 → 请走 LEG-14；积分制度通用运行（预算、兑换）→ 请走 HR-18；内部培训的场地与通知通用流程 → 请走 HR-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识产权归口 起草激励办法、维护积分手册、核验申报 R 总经办（当前：赵雪冰·推断待确认）
培训组织 邀请代理讲师、安排场地、录屏、发通知 R 总经办（当前：王欣·推断待确认）
激励口径 解释专利/软著奖励口径、判断线索价值 C 创始人兼 CTO（当前：丁震宇·推断待确认）
人事 积分入账与奖金随薪发放 R 人事（当前：待指定）
财务 奖金预算与支付 C 财务（当前：待指定）
研发员工 参加培训、提交线索、申报激励 R 研发员工（当前：季学森、郭逸非等·推断待确认）
综合部负责人（审批/兜底） 激励办法与奖金/积分标准审批、争议裁决 A 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 激励办法草案：适用对象、专利/软著各阶段（递交、授权、下证）的奖励形式与积分口径、多人发明的分配规则
  • 培训讲师与课件（代理机构）、技术交底模板
  • 专利台账（用于核验）
  • 年度奖金/积分预算

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草激励办法与积分口径（专利、软著分别规定），经财务、人事会签 知识产权归口 30 个自然日内成稿 飞书文档 激励办法草案 👤人工判断
2 审批并发布，在通知群和知识库置顶，附 FAQ 知识产权归口 审批后 2 个工作日内 飞书审批 + 知识库 正式办法 🔧飞书固化
3 组织专利挖掘培训（线下 + 线上），录屏归档 培训组织 每半年至少 1 次；新批次挖掘启动前 飞书会议 录屏、课件 🔧飞书固化
4 培训后 2 周内收集专利线索，进入 POL-11 提案 研发员工 培训后 10 个工作日内 多维表格表单 线索清单 🔧飞书固化
5 员工在节点达成后提交激励申报（关联台账编号） 研发员工 节点达成后 30 个自然日内 飞书审批 申报单 🔧飞书固化
6 核验台账状态、发明人及分配比例 知识产权归口 收到后 5 个工作日内 专利/软著台账 核验结果 🤖自动化
7 审批奖金/积分标准 综合部负责人 3 个工作日内 飞书审批 审批结论 👤人工判断
8 公示后兑现：积分入账，奖金随当月工资发放 人事、财务 公示 3 个工作日无异议后，次月发放 积分系统 / 工资 兑现记录 🔧飞书固化

5. 交付物与模板

  • 交付物：知识产权激励办法、积分手册知识产权章节、培训录屏、线索清单、激励申报与兑现记录
  • 建议模板/表单：
    • 激励申报字段：申报人、台账编号、类型（专利/软著）、节点（递交/授权/下证）、发明人及分配比例、证明材料链接
    • 线索表字段：线索名称、提出人、所属产品、技术要点、是否已公开、建议类型、处理状态

6. 异常与升级

  • 激励口径不明（如软著有无奖金）→ 统一以成文办法为准，群内不做口头承诺 → 办法未覆盖的情形提交综合部负责人在 5 个工作日内书面答复
  • 多名发明人分配有争议 → 由技术负责人给出贡献意见 → 仍有争议提交综合部负责人裁决
  • 申请撤回或被驳回 → 按办法规定处理已发奖励，不追溯的需在办法中写明
  • 预算超支 → 暂停兑现并提交管理层调整预算

7. 衡量指标

  • 培训覆盖率：参加或回看培训的研发人员 / 研发总人数，目标 ≥ 80%
  • 线索转化率：培训后转为正式提案的线索 / 收集线索，目标 ≥ 30%
  • 兑现周期：申报到兑现的自然日，目标 ≤ 45 天
  • 口径一致性：激励相关口头答复后又被纠正的次数，目标 0

8. 低效诊断

  • 现象：专利培训已开、激励已宣布试行，但细则未成文，软著是否算奖励在群里即时口头回答｜依据：「模态跃迁通知群」2026-07
  • 现象：积分手册尚在编写，员工无法知道申报入口和兑现时间｜依据：「模态跃迁通知群」2026-07

9. 分支变体

  • 发明专利：有奖金，申请费用由公司承担
  • 软著：暂无奖金，计入积分（以正式办法为准）
  • 外部受让专利：不纳入员工激励

10. 待确认问题

  • 激励办法由总经办还是人事牵头起草？是否已有初稿？
  • 专利奖金按递交、授权哪个节点发放？软著积分标准是多少？
  • 培训频率每半年 1 次是否合适？是否纳入新人培训？
  • 奖金审批人是综合部负责人还是 CEO？
LEG-16商标查询、注册申请与驳回复审待新建144

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：新品牌、新产品命名或改名时，在对外使用前完成商标近似检索、确定主体与类别群组、委托申请，并跟进受理、初审公告、驳回复审、注册证与续展，同时按类别保存使用证据
  • 负责人：主责——知识产权归口（总经办，当前：赵雪冰·推断待确认）；协同——产品负责人（当前：杨萌、徐莉·推断待确认）、类别预选与技术口径（当前：丁震宇·推断待确认）、开源社区负责人（当前：陈梦琪、葛家和·推断待确认）、复审与主体决策（当前：常元和·推断待确认）、外部商标代理；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 命名前近似检索 → ② 代理出风险评估 → ③ 决定申请（主体、类别、群组）→ ④ 准备标样 → ⑤ 委托代理提交 → ⑥ 台账登记与进度跟进 → ⑦ 驳回复审决策 → ⑧ 注册证归档、使用证据保存、续展提醒
  • 交付结果：商标台账（名称、主体、类别群组、申请号、状态、期限、使用证据）及注册在正确主体名下的商标注册证
  • 状态依据：缺少“命名 → 检索 → 申请 → 主体 → 使用证据 → 续展”的前置规则：2026-06 字字跃迁、字字妙因显著性被驳；2026-08 发现 LeapCore、ModaLeap 近似难以注册，产品已对外使用后才暴露；部分商标注册到哪个主体无人清楚；经办人交接断档后 2026-08、2026-09 两次被追问“商标现在归谁管”；2026-09 才提出系统规划品牌商标保护

1. 场景判定

  • 触发条件：新产品、新品牌、新子品牌或社区命名；产品改名；收到受理、初审公告、驳回、注册证、续展通知；发现商标被抢注或近似
  • 典型说法：「我们这个商标好像没申下来」「商标这块工作，现在归谁管呢」「不建议复审」「请相应产品负责人在后续使用时保存使用证据」
  • 判断问题：这个名称/Logo 是否会对外长期使用？是否已经做过近似检索？没检索的名称不应对外发布
  • 不归本流程管：产品命名与更名决策 → 请走 BRD-01；命名与术语规范 → 请走 X-PRD-15；App/ICP 备案 → 请走 LEG-23；域名购买与备案 → 请走 X-SEC-20；被抄袭/侵权处置 → 请走 LEG-17；Logo 设计 → 请走 BRD-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
知识产权归口 委托检索与申请、台账维护、官文同步、到期提醒 R/A 总经办（当前：赵雪冰·推断待确认）
产品负责人 提出名称与使用范围、提供标样、保存使用证据 R 产品负责人（当前：杨萌、徐莉·推断待确认）；开源社区（当前：陈梦琪、葛家和·推断待确认）
类别预选 用 AI 根据产品资料预选核心/防御类别与群组，人工复核 C 创始人兼 CTO（当前：丁震宇·推断待确认）
主体决策人（主体与复审） 决定注册主体、是否复审 A（升级） COO（当前：常元和·推断待确认）
外部代理 近似检索、风险评估、递交、复审 R（外部） 商标代理机构
兜底 品牌商标整体规划与重大争议 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 拟用名称（中英文）、Logo 图样，标样标准（字号、字体、图片），申请形式（文字/图形/组合）
  • 产品介绍与使用范围，用于选类别和细分群组
  • 拟注册主体（模态跃迁、鼎慧、子公司等）及理由
  • 近似检索结果与代理风险评级（低/中/高）
  • 已有商标台账中同名或近似记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 命名候选确定前提交检索申请（每次 2～3 个备选名） 产品负责人 对外使用前至少 10 个工作日 多维表格表单 检索申请 🔧飞书固化
2 委托代理近似检索，回传风险评级与近似商标 知识产权归口 收到后 3 个工作日内 代理 检索报告 🤖+👤
3 预选类别与群组：核心类（如 9/42/35）、防御类、可选类，细分到群组编号 产品负责人、类别预选 检索后 2 个工作日内 AI 检索 + 人工复核 类别群组清单 🤖+👤
4 决定是否申请、注册主体、类别范围；高风险名称回到命名环节 主体决策人 2 个工作日内 飞书审批 申请决定 👤人工判断
5 准备标样并委托代理递交，统一缴费 知识产权归口、产品负责人 决定后 5 个工作日内 代理 申请号 🔧飞书固化
6 登记台账；受理、初审公告（3 个月异议期）、注册证等通知同步并 @产品负责人 知识产权归口 通知到达后 1 个工作日内 台账 + 群机器人 状态更新 🔧+🤖
7 被驳回：代理给出驳回理由、复审费用与通过率评估，提交决策是否复审或改名 知识产权归口、主体决策人 收到驳回后 5 个自然日内决策（法定复审期 15 日） 飞书审批 复审决定 👤人工判断
8 注册后：证书归档，产品负责人按注册类别每月上传使用证据（含时间），到期前 12 个月提醒续展 产品负责人、知识产权归口 每月 5 日前上传 共享文件夹 + 机器人提醒 使用证据、续展记录 🔧+🤖

5. 交付物与模板

  • 交付物：检索报告、申请决定、申请号、商标注册证、使用证据档案、商标台账
  • 建议模板/表单：
    • 商标台账字段：商标名称、图样、注册主体、类别、群组、申请号、申请日、状态（检索/已递交/受理/初审公告/驳回/复审中/注册/无效）、初审公告日、注册日、到期日、产品负责人、代理机构、使用证据链接
    • 使用证据规范：按类别保存带日期的产品界面截图、宣传物料、合同/发票中的商标使用页

6. 异常与升级

  • 检索风险高但产品已对外使用 → 暂停新增投放，提交 CEO 决定改名或加注区别要素（3 个工作日内）→ 改名转 BRD-01
  • 被驳回 → 5 个自然日内完成复审决策，超时由知识产权归口提交 COO 当天拍板，避免错过 15 日复审期
  • 发现商标注册在非预期主体 → 查清来源与授权，提交 COO 决定是否转让 → 10 个工作日内给结论
  • 经办人变动 → 台账与代理联系人须在交接当天移交给知识产权归口，无交接不得办离岗
  • 代理服务质量差、反复出错 → 评估更换代理，由综合部负责人决定
  • 拍板口径：常规检索、申请、台账与续展由知识产权归口负责（A）；需决定注册主体、是否复审或转让时，升级 COO 作为 A（升级）拍板（时限见上）；已对外使用的高风险名称改名、品牌商标整体规划等重大事项，升级 CEO 作为 A（升级）决定

7. 衡量指标

  • 命名前检索率：对外使用前完成检索的新名称 / 全部新名称，目标 100%
  • 注册成功率：最终注册的申请 / 全部申请，目标 ≥ 70%
  • 状态响应时效：官文到达到群内同步的时长，目标 ≤ 1 个工作日
  • 使用证据合规率：按月上传使用证据的已注册商标 / 全部已注册商标，目标 ≥ 90%
  • 台账覆盖率：有主体、类别、状态、到期日的商标 / 全部商标，目标 100%

8. 低效诊断

  • 现象：命名在先、检索在后，多款产品名因缺乏显著性或近似被驳回，复审通过率低｜依据：「【模态】知识产权」2026-06、「【模态】知识产权」2026-08
  • 现象：商标注册到哪个主体无人清楚，主体决策没有前置规则｜依据：「【模态】知识产权」2026-08
  • 现象：经办人交接断档，进度无人跟进，业务方多次追问归谁管、能否加急｜依据：「模态商标」2026-02、「模态商标」2026-08、「模态商标」2026-09
  • 现象：要求整理“哪些商标在哪个主体下申请了哪些类目”的汇总表，但台账长期缺失｜依据：「模态商标」2026-01
  • 现象：品牌商标保护缺乏整体规划，大面积驳回后才提出系统规划｜依据：「【模态】知识产权」2026-09

9. 分支变体

  • 模态跃迁主体：9/37/38/41/42 类
  • 鼎慧文跃/鼎慧通：鼎慧主体申请
  • 字字妙/字字跃迁：显著性被驳，评估改名或复审
  • LeapCore：拟申请 9/38/42 类（另建议 35 类），名称含通用词难注册，需评估组合商标
  • 开源聚变 AI 社区：38/41 类
  • 核心类 / 防御类 / 可选类分层申请；使用证据规范面向所有业务线

10. 待确认问题

  • 商标由总经办统一归口是否确认？产品负责人与知识产权归口的分工是否如上？
  • 注册主体规则是什么（按产品线所属公司，还是统一由集团主体持有再授权）？
  • 复审决策由 COO 还是 CEO 拍板？复审费用由谁承担？
  • “对外使用前至少 10 个工作日提交检索”是否可执行？
  • 是否需要启动全公司品牌与产品体系商标规划，由谁牵头、何时完成？
LEG-17被抄袭/侵权线索处置待新建48

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频1 × 耗3 × 跨4 × 险4

  • 适用场景：员工发现外部网站、产品或社区页面抄袭、1:1 复刻公司官网内容/设计、产品界面或功能，或冒用公司品牌时，启动登记、取证、定性和维权
  • 负责人：主责——法务（当前：待指定）；协同——发现人（任一员工）、品牌/官网负责人（当前：待指定）、研发取证支持（当前：待指定）、对外沟通与处置决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人
  • 核心流程：① 线索登记 → ② 证据固定 → ③ 权属与相似度评估 → ④ 查明对方主体 → ⑤ 定性并审批处置方案 → ⑥ 先礼后兵对外沟通 → ⑦ 投诉/律师函/诉讼升级 → ⑧ 结案归档与补权
  • 交付结果：侵权线索登记记录、证据包（截图、录屏、存证或公证）、经审批的处置方案与对外函件、结案记录；需要时触发专利/软著/商标补申
  • 状态依据：2026-03 官网被抄、OPC 社区页面被 1:1 复刻两次事件，都只在群里讨论，处置步骤靠问答机器人给出，决策停在口头（“先礼后兵”“重拳出击”）；没有登记入口、取证动作、函件模板，也没有后续结果记录

1. 场景判定

  • 触发条件：外部网站/页面的文案、设计、布局与公司官网高度一致；外部产品 1:1 复刻我方产品页面、交互或社区功能；他人冒用公司名称、产品名、Logo；应用商店、社交媒体、开源平台出现盗用我方内容
  • 典型说法：「有人抄我们网站怎么办」「我们的 OPC 社区被抄了，1:1 复刻」「先礼后兵」「让法务重拳出击」
  • 判断问题：被抄的是不是我方享有权利的具体表达（官网文案、设计稿、代码、产品界面、商标/名称）？对方是否已公开使用？只是功能思路相近、没有复制具体表达的，先登记观察，不启动对外动作
  • 不归本流程管：需要补申专利 → 请走 POL-11（专利申请与代理对接）；补申软著 → 请走 POL-10（软件著作权申请）；商标注册、驳回复审 → 请走 LEG-16；员工泄露代码、内部资产外流 → 请走 LEG-31；我方使用他人字体/素材的版权核查 → 请走 LEG-19；开源许可证争议 → 请走 LEG-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发现人 登记线索、提供链接与截图，不在公开渠道表态 R 任一员工
法务 取证、定性、起草处置方案与函件、投诉/诉讼 R 法务（当前：待指定）
研发取证支持 页面存档、录屏、代码/界面比对、技术特征分析 R 研发取证支持（当前：待指定）
品牌/官网负责人 提供原始设计稿、上线时间、版权证明，评估品牌影响 C 品牌/官网负责人（当前：待指定）
CEO 决定处置力度，对外沟通（尤其对方为政府或合作方时） A/R CEO（当前：邴龙志·推断待确认）
综合部负责人 法务缺位时兜底，跟进结案 I 综合部负责人

3. 办之前请准备

  • 侵权页面链接、全页截图、录屏、发现时间
  • 我方原始作品证明：设计源文件、Git 提交记录、官网/产品首次上线时间、ICP 备案信息、已有软著/商标/专利证书
  • 对方主体线索：ICP 备案查询结果、域名 whois、企业工商信息
  • 影响说明：是否误导客户、是否涉及政府合作项目口径、是否影响招投标或宣传

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在「侵权线索」表登记链接、截图、被抄内容、发现时间，并@法务；不在群内讨论对外措辞 发现人 发现当天 飞书多维表格/表单 线索记录 🔧飞书固化
2 固定证据：全页截图 + 录屏 + 网页存档 + 时间戳存证；准备发函或起诉的，关键页面做公证 法务、研发取证支持 登记后 1 个工作日内（对方随时可能下线） 存证平台、存档脚本 证据包 🤖+👤
3 调取我方原始证明，AI 比对文案/界面/代码相似度，列出复制点清单 研发取证支持、品牌/官网负责人 登记后 2 个工作日内 AI 比对 比对报告 🤖自动化
4 查明对方主体及类型：企业、政府或事业单位、个人、平台内用户 法务 登记后 2 个工作日内 ICP 备案查询、工商信息 主体信息 🤖自动化
5 定性并提出处置方案（不处理/沟通/发函/平台投诉/联系托管商/诉讼），走审批 法务起草，CEO 决定 评估完成后 2 个工作日内 飞书审批 处置方案审批单 👤人工判断
6 先礼后兵：按模板发沟通函或邮件，要求 5 个工作日内下线或注明来源 CEO 指定的对外沟通人，法务审措辞 审批通过后 2 个工作日内 函件模板、企业邮箱 沟通记录 🔧+👤
7 对方逾期未改：向平台/托管商投诉、发律师函；仍无效时评估诉讼成本与收益 法务 期限届满后 3 个工作日内 平台投诉通道、外部律所 投诉回执/律师函 👤人工判断
8 结案：更新线索状态，判断是否补申专利/软著/商标、官网是否加版权声明 法务 结案后 5 个工作日内 多维表格 结案记录、补权任务 🔧飞书固化

5. 交付物与模板

  • 交付物：线索登记记录、证据包、比对报告、处置方案审批单、沟通函/律师函、结案记录
  • 建议模板/表单：
    • 侵权线索表字段：线索编号、发现日期、发现人、侵权链接、被抄内容类型（文案/设计/界面/代码/品牌）、对方主体、主体类型、证据包链接、相似度结论、处置方式、当前状态、结案日期
    • 沟通函模板：我方权利说明、侵权内容对照、要求（下线/注明来源/停止使用）、期限、联系人
    • 证据包目录：截图、录屏、存证编号、我方原始证明、比对报告

6. 异常与升级

  • 对方为政府、事业单位、合作方或潜在客户 → 不直接发函，由法务出风险说明 → 1 个工作日内升级 CEO 决定沟通方式
  • 对方已下线、原始页面取不到 → 以已存证材料为准，结案并持续监测 → 法务决定是否继续
  • 对方反称我方抄袭或我方权属证明不足 → 立即暂停对外动作 → 当天升级 CEO，必要时委托外部律师
  • 员工在公开渠道发表攻击性言论 → 法务提醒删除并统一口径 → 当天
  • 侵权源头疑似内部泄露 → 转 LEG-31，同步 CTO
  • 拍板口径：处置方式（不处理/沟通/发函/投诉/诉讼）由 CEO 作为唯一 A 决定；法务负责取证、定性与执行（R）

7. 衡量指标

  • 线索登记率 = 进入线索表的侵权事件 / 群内提及的侵权事件，目标 100%
  • 取证时效 = 登记到证据包完成的工作日，目标 ≤ 1 个工作日
  • 处置闭环率 = 已结案线索 / 登记线索，目标 ≥ 90%
  • 结案周期 = 登记到结案的自然日，目标 ≤ 30 天（诉讼除外）

8. 低效诊断

  • 现象：发现侵权后只在群里讨论和吐槽，处置步骤靠问答机器人临时给出，没有登记入口（发现环节）｜依据：「随便瞎聊啦～」2026-03、「鸽子群模态分群」2026-03
  • 现象：决策停在口头，对外沟通由谁做、何时做靠机器人次日提醒（决策环节）｜依据：「随便瞎聊啦～」2026-03、「鸽子群模态分群」2026-03
  • 现象：没有截图存证、公证等取证动作，事后无处置结果记录（取证与结案环节）｜依据：「鸽子群模态分群」2026-03
  • 现象：对方为政府网站或背景更强的主体时怎么应对，没有口径（定性环节）｜依据：「随便瞎聊啦～」2026-03

9. 分支变体

  • 普通企业网站：按步骤 1～8 执行，沟通函优先
  • 政府/事业单位网站：不发律师函，由 CEO 决定是否沟通及沟通方式，法务只出风险说明
  • 平台内侵权（应用商店、社交媒体、开源平台）：优先走平台投诉通道，附权属证明
  • 产品功能/页面 1:1 复刻（如纯前端复刻）：重点比对界面与前端代码，同时评估是否补申软著或专利
  • 冒用品牌名称/Logo：结合商标状态处理，未注册的同步走 LEG-16

10. 待确认问题

  • 侵权处置主责是否由法务承担？对外沟通由 CEO 本人还是由法务出面？
  • 是否采购第三方存证或公证服务？发函是否需要外部律所？
  • “先礼后兵”的沟通期限 5 个工作日是否合适？
  • 对方为政府或合作方时的统一口径是什么？
  • 官网、产品是否统一加版权声明与内容原创说明？
LEG-18用户协议、隐私政策、EULA 与免责文案编制及变更管控待新建180

状态：待新建｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：产品、官网、社区、App 或安装包面向外部用户上线前，或新增个人信息收集、UGC、IP 属地、第三方 SDK、储值退款等功能，或产品内法律提示被改动时，编制/更新用户协议、隐私政策、社区公约、EULA、AI 免责文案，并管控后续变更
  • 负责人：主责——产品线协议负责人（产品经理）（当前：Leap 系列为杨黔昆、跃玩为樊九辰·推断待确认）；协同——法务（当前：待指定）、产品负责人（当前：杨萌·推断待确认）、客户端研发（当前：岳阳·推断待确认）、社区/生态运营（当前：陈梦琪·推断待确认）、合规负责人（当前：常元和·推断待确认）；兜底——法务负责人
  • 核心流程：① 需求评审触发登记 → ② 按模板起草/修订 → ③ 法务审核 → ④ 产品与合规会签 → ⑤ 研发上线展示 → ⑥ 版本归档与告知 → ⑦ 受保护文案变更守卫 → ⑧ 半年复核
  • 交付结果：经法务审核的协议/政策/EULA/免责文案定稿（含版本号、生效日）、在线链接与产品内展示位、协议版本台账、必备法律文案清单
  • 状态依据：LeapAll 已有 2026-05 发布的用户协议与隐私策略，但 2026-02～10 字字可研、LeapAll、LeapCore、开源聚变社区、跃玩、官网、信创安装包都在上线或上架前后才补协议；未见法务审核节点；2026-08 出现 AI 免责提示被删、靠人工发现的事故；EULA 两次询问无人认领

1. 场景判定

  • 触发条件：新产品/新端（Web、客户端、App、小程序、社区、API 站点）计划对外上线；新增收集个人信息的功能（注册方式、IP 属地、动态/UGC、上传文件、支付/储值）；接入第三方 SDK 或内容审核服务；打包上架应用商店/信创商店需要 EULA；官网页脚条款更新；产品内法律提示被修改或删除；相关法规变化
  • 典型说法：「用户协议、隐私政策、AI 生成免责文案可以开始准备了」「现在有隐私协议吗」「有没有纯 TXT 格式的 EULA」「加的提示小字被删了，有法律风险」「法务还没写好相关的文档」
  • 判断问题：这次改动是否改变了“向用户收集什么、怎么用、和谁共享、存多久、用户有什么权利、我们免什么责”？是 → 走本流程
  • 不归本流程管：功能本身能不能做（数据抓取、境外模型、版权） → 请走 LEG-19；内容审核策略与 AI 生成标识 → 请走 LEG-20；B 端销售合同免责条款 → 请走 LEG-03；开源许可证声明 → 请走 LEG-28；帮助中心日常内容 → 请走 OPS-03；App/网站备案 → 请走 LEG-23；营销短信文案 → 请走 LEG-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品线协议负责人 登记、起草/修订、整理数据流向清单、维护版本台账 R 产品经理（当前：Leap 系列为杨黔昆、跃玩为樊九辰·推断待确认）
法务 审核定稿，维护模板库与必备法律文案清单，半年复核 A 法务（当前：待指定）
产品负责人 确认文本与功能实际一致，决定上线 C 产品负责人（当前：杨萌·推断待确认）
客户端/前端研发 上线在线链接、勾选同意、免责文案写死与 CI 守卫 R 客户端研发（当前：岳阳·推断待确认）
社区/生态运营 社区管理规则、追责条款、帮助中心入口内容 C 社区/生态运营（当前：陈梦琪·推断待确认）
合规负责人 确认协议中的主体、联系人与备案信息一致 C 合规负责人（当前：常元和·推断待确认）
测试 上线前检查协议入口与勾选逻辑 I 测试负责人（当前：张东郅·推断待确认）

3. 办之前请准备

  • 功能说明/PRD 与数据流向清单：收集项、用途、第三方 SDK 与共享方、存储地点与期限、注销与删除方式
  • 现有协议版本（如 LeapAll 用户协议与隐私策略、MerCall 旧协议）及修订对照
  • 运营主体、联系人、备案号
  • 上架平台对 EULA 的格式要求（如纯 TXT、元数据字段）
  • 内容审核服务、支付、储值退款、税务责任等需写入条款的业务规则

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 需求评审勾选“涉及协议/隐私/免责”，登记协议变更台账并明确负责人 产品线协议负责人 需求评审当场；最迟上线前 15 个工作日 需求评审模板、多维表格 变更登记 🔧飞书固化
2 按模板库起草或修订，AI 生成初稿，附数据流向清单与修订对照 产品线协议负责人 登记后 5 个工作日内 模板库 + AI 草稿、修订对照表 🤖+👤
3 法务审核条款合法性、完整性，出修改意见或定稿 法务 收到后 3 个工作日内（加急 1 个工作日） 飞书审批 审核意见/定稿 🔧+👤
4 会签：产品负责人核对文本与实际采集一致；合规负责人核对主体、联系人、备案信息 产品负责人、合规负责人 法务定稿后 1 个工作日内 飞书审批会签 会签记录 👤人工判断
5 上线：在线链接托管、登录注册页勾选同意、关于页入口、EULA 随安装包；免责提示客户端写死为受保护常量 客户端/前端研发 随版本，发布前完成 代码仓库、文档站 上线版本 🔧+🤖
6 归档版本号、生效日、变更摘要；新增收集项或第三方共享的，提前 7 天公告并弹窗重新同意 产品线协议负责人 生效前 7 天 文档站、产品公告 版本台账、公告 🔧飞书固化
7 变更守卫：必备法律文案清单内容被修改或删除，须法务 + 产品负责人审批；CI 检测缺失即阻断合并 客户端/前端研发 每次合并 Gitea CI 检查记录 🤖+👤
8 半年复核：法规变化、功能变化与协议一致性 法务 每年 1 月、7 月 飞书任务 复核记录 🔧+👤

5. 交付物与模板

  • 交付物：协议/政策/EULA/免责文案定稿、在线链接、协议版本台账、必备法律文案清单
  • 建议模板/表单：
    • 模板库：C 端用户协议、隐私政策、社区公约/UGC 规则、商城交易规则、API 服务条款、EULA（含纯 TXT 版）、AI 生成内容免责、数据备份提醒
    • 协议版本台账字段：产品线、文档类型、版本号、生效日、变更摘要、是否需重新同意、法务审核单号、在线链接、负责人
    • 必备法律文案清单字段：文案位置（页面/组件）、文案内容、依据、代码常量名、是否受 CI 保护、变更审批人

6. 异常与升级

  • 产品已上线但没有协议 → 24 小时内上线已审核模板的临时版本，5 个工作日内补完整审核 → 升级产品负责人
  • 法务超 3 个工作日未回复 → 协议负责人催办；再超 2 个工作日 → 升级法务负责人/综合部负责人
  • 免责提示被删或被改 → 当天 hotfix 恢复，追溯变更来源并补 CI 规则 → 当天通知产品负责人
  • 缺少账号注销等法定功能 → 先提供客服注销通道并在协议写明，功能排入下个迭代 → 升级产品负责人
  • 协议描述与实际数据处理不一致 → 暂停发布，改功能或改协议 → 1 个工作日内由法务与产品负责人定

7. 衡量指标

  • 上线前协议完备率 = 上线时已有法务审核版协议的对外产品/版本数 / 对外上线总数，目标 100%
  • 法务审核周期 = 提交到定稿的工作日，目标 ≤ 3 天
  • 受保护文案误删次数 = 每季度必备法律文案被删除或改错次数，目标 0
  • 协议版本台账覆盖率 = 已登记产品线 / 对外产品线，目标 100%

8. 低效诊断

  • 现象：产品内测或已对外发布后才开始准备协议与免责文案（触发环节）｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：协议由产品或运营起草，合规判断由研发口头决定，如注销功能“没人找就不急”（审核环节）｜依据：「工程咨询产研」2026-02、「跃玩项目组」2026-10
  • 现象：法律免责提示被删无人知道是谁删的，靠个人记忆发现，事后提工单（变更管控环节）｜依据：「跃迁AI总动员」2026-08
  • 现象：前端预留了条款与帮助中心入口，上线前才发现内容为空（上线环节）｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：上架需要 EULA，两次询问无人认领，旧文档不知是否仍在用（版本管理环节）｜依据：「信创LeapCore客户端适配」2026-07
  • 现象：官网条款与素材合规咨询法务无答复时限，需要反复催（咨询环节）｜依据：「模态跃迁 官网研发」2026-08、「模态跃迁 官网研发」2026-09
  • 现象：协议中的合规负责人、备案责任人临时指定（角色环节）｜依据：「Leap产研测」2026-06、「开源聚变入驻问题沟通群」2026-03

9. 分支变体

  • LeapAll/LeapCore（C 端）：复用 MerCall 旧协议须重新走法务审核；登录注册页必须展示在线链接
  • 字字可研（工程咨询）：账号注销与个人信息删除须写入协议并有对应功能
  • 跃玩/跃竞：动态发布、IP 属地、背景图/签名、第三方 SDK、内容审核、储值退款与税务责任条款，社区公约发布前确认
  • 开源聚变社区/OPC：社区管理规则、追责条款、用户勾选同意、帮助中心内容
  • 信创/Linux 安装包与应用商店：纯 TXT EULA 随包分发；LeapAll 与 LeapCore 是否分版待定
  • 官网：页脚服务条款与隐私政策；地图素材须使用带审图号的标准地图且不得修改，否则不用

10. 待确认问题

  • 协议起草主责是否为各产品线产品经理，法务只负责审核？
  • 法务审核 3 个工作日（加急 1 天）是否可行？是否走飞书审批固化？
  • 是否建立统一模板库和协议在线托管地址？
  • EULA 按产品线分版还是统一一版？
  • 账号注销是否作为 C 端上线必备项？
  • 必备法律文案清单和 CI 守卫由谁维护？
  • 协议中的“合规负责人/联系人”统一填哪个岗位？
LEG-19新产品/新功能上线合规评估待新建240

状态：待新建｜证据：有证据（卡片 10 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：产品对外发布，或研发/产品提出可能涉及合规风险的功能（第三方数据抓取或展示、读取 cookie、视频下载、云端读取客户文件、字体/素材版权、境外或未备案模型、API 对外转售、商城上架第三方产品），在开发前由法务出具合规结论与整改要求
  • 负责人：主责——法务（当前：待指定）；协同——需求提出产品经理（当前：杨萌·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、数据来源与合规责任人（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求评审合规勾选 → ② 补齐评估材料 → ③ AI 初筛 → ④ 法务出结论 → ⑤ 争议事项决策 → ⑥ 按整改要求实现与验收 → ⑦ 上线门禁 → ⑧ 结论入库与抽检
  • 交付结果：合规评估单与合规结论书（可做/附条件可做/不可做 + 整改项）、整改验收记录、合规结论库
  • 状态依据：2026-01～10 至少 10 次合规疑问（数据抓取、境外模型、字体版权、API 转售、开源许可、上传客户文件等）都是研发群里临时讨论、技术负责人口头判断，多次“先开工再问合规”，法务意见靠转述，工单“在等法务”悬而未决，没有评估入口和书面结论

1. 场景判定

  • 触发条件：需求或 PRD 命中合规清单任一项——个人信息与用户授权；抓取或展示第三方数据；读取用户 cookie、本地文件或上传到云端；下载第三方视频/内容；引入字体、图片、素材、第三方网盘；引入开源组件；使用境外或未备案模型；把上游模型 API 封装对外售卖；用户内容公开展示；商城上架第三方 AI 产品；可能需要资质（如 VPN）
  • 典型说法：「合规风险在哪」「如果直接公开出来，会有什么法律后果吗」「我们签的是可对外提供 API 吗」「C 端只能卖备案过的模型」「注意版权，很多常见字体需要购买商用版权」
  • 判断问题：这个功能上线后，是否会让公司处理他人数据、使用他人作品、对外提供他人服务或触及资质要求？任一为“是”就先评估再开发
  • 不归本流程管：协议文本编制与变更 → 请走 LEG-18；内容审核与 AI 生成标识 → 请走 LEG-20；开源组件许可证细评 → 请走 LEG-28；增值电信许可 → 请走 LEG-24；算法备案等专项资质 → 请走 LEG-25；销售/长期产品合同审查 → 请走 LEG-03；业务红线（数据买卖、批量私信） → 请走 LEG-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求提出产品经理 判断是否命中清单，提交评估单，准备材料，跟进整改 R 产品经理（当前：杨萌·推断待确认）
法务 评估并出具书面结论与整改要求，维护结论库 A 法务（当前：待指定）
研发负责人 提供技术方案、数据流向、开源依赖清单，落实整改 R 研发负责人（当前：王皓南·推断待确认）
数据来源与合规责任人 确认数据来源授权、模型备案情况、上游条款 C 合规责任人（当前：常元和·推断待确认）
测试负责人 按合规整改项验收，发现未评估风险时提出 R 测试负责人（当前：张东郅·推断待确认）
创始人兼 CTO 高风险或业务与法务意见不一致事项决策 C/A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • PRD 或功能说明，目标用户（B 端/C 端）、上线范围
  • 数据流向图：数据来源、是否离开客户本地、存储位置、共享对象
  • 第三方数据/素材/字体的来源与授权证明；上游模型或 API 服务条款
  • 依赖清单与开源许可扫描结果
  • 所用模型清单及备案情况
  • 竞品或行业通行做法（可选）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 需求评审时逐项勾选合规清单，命中即提交合规评估单；未提交不得进入开发 需求提出产品经理 需求评审当场；最迟开发启动前 PRD 模板、飞书审批 合规评估单 🔧飞书固化
2 补齐材料：数据流向图、来源授权、上游条款、开源许可扫描、模型备案情况 产品经理、研发负责人 提交后 2 个工作日内 许可扫描脚本、多维表格 评估材料包 🤖自动化
3 AI 初筛：对照合规清单与结论库标出风险点和相似先例 法务 材料齐后 1 个工作日内 AI + 结论库 初筛清单 🤖自动化
4 出书面结论：可做/附条件可做/不可做，列整改项（授权弹窗、协议条款、输入审查、水印、一键下架、数据最小化） 法务 材料齐后 3 个工作日内；需外部律师的 10 个工作日内 飞书审批 合规结论书 👤人工判断
5 高风险或业务与法务意见不一致的，组织决策 创始人兼 CTO 结论出具后 2 个工作日内 飞书会议 决策记录 👤人工判断
6 按整改项开发，测试逐项验收 研发负责人、测试负责人 随迭代 工单系统 整改验收记录 🔧飞书固化
7 上线门禁：合规整改项未关闭不得发布；需要改协议的同步走 LEG-18 产品经理 发布前 1 个工作日 发布检查单 放行记录 🔧飞书固化
8 结论入库，按问题类型可检索；上线后变化（换模型、换数据源）触发复评，按季度抽检 法务 结论出具后 2 个工作日内入库；每季度抽检 多维表格 合规结论库、抽检记录 🔧+🤖

5. 交付物与模板

  • 交付物：合规评估单、合规结论书、整改验收记录、合规结论库
  • 建议模板/表单：
    • 合规评估单字段：需求名称、产品线、B 端/C 端、命中清单项、数据流向说明、第三方来源与授权、所用模型及备案、开源依赖、期望上线日、提交人
    • 合规结论书字段：风险点、法律依据、结论（可做/附条件/不可做）、整改项、责任人、复评触发条件
    • 字体/素材白名单：名称、来源、授权类型、可商用范围、到期日

6. 异常与升级

  • 已开发未评估就要上线 → 先停在发布门禁，按加急 1 个工作日评估 → 结论为不可做时升级 CTO
  • 法务超时未出结论 → 产品经理催办，再超 2 个工作日升级 CTO 决定是否延期发布
  • 对外宣传口径与实际数据处理不一致（如宣称“数据不出网”但需上传） → 改功能或改口径，未统一前不得对外宣传 → 升级产品负责人与销售负责人
  • 上线后发现数据来源侵权或被投诉 → 启用一键下架，24 小时内下线相关内容 → 当天升级 CTO 与法务
  • 第三方上架产品被发现调用未备案模型 → 下架并要求整改 → 当天升级运营负责人
  • 升级拍板：合规结论由法务作为 A 出具；出现以下任一情形时由创始人兼 CTO 作为 A（升级）决策——结论为高风险或不可做但业务坚持推进、业务与法务意见不一致、法务超时需决定是否延期发布

7. 衡量指标

  • 评估前置率 = 开发启动前完成评估的命中需求 / 全部命中需求，目标 ≥ 95%
  • 评估周期 = 材料齐全到出结论的工作日，目标 ≤ 3 天
  • 上线后合规返工次数 = 每季度因合规问题下线或回滚的功能数，目标 0
  • 结论复用率 = 引用结论库先例直接判定的评估单 / 评估单总数，目标逐季上升

8. 低效诊断

  • 现象：研发先开工，功能做完才追问“合规风险在哪”（触发环节）｜依据：「Leap产研测」2026-10、「Leap产研测」2026-05
  • 现象：数据公开、模型选用等法律风险由技术负责人口头判断，没有书面结论（评估环节）｜依据：「工程咨询产研」2026-01、「鼎慧产研决策部」2026-06、「Leap产研测」2026-08
  • 现象：法务意见靠转述，相关工单长时间“在等法务”无人跟进（交接环节）｜依据：「Leap产研测」2026-05
  • 现象：数据来源与 Skill 合规责任人临时指定（角色环节）｜依据：「Leap产研测」2026-05
  • 现象：字体版权、境外模型等同类顾虑反复出现，靠同事临场提醒（知识沉淀环节）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：长期产品合同在研发群里请人“看一眼”，没有走法务审查（合同环节，应转 LEG-03）｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 第三方公开资料展示：核实原文是否来自官方公开渠道，注明来源，标配一键下架
  • 读取客户文件/上传云端：优先 local-first；必须上传的，按“用户明确同意 > 只传必要片段”取舍；B 端写入合同授权，C 端弹窗授权；对外口径与实际一致
  • 字体、素材、第三方网盘：只用白名单字体；商用字体先采购授权；接入第三方服务由商务签合作
  • 境外/未备案模型：C 端仅提供已备案模型；B 端使用境外模型须在合同中约定并经法务确认
  • 上游模型 API 封装转售：核对上游条款是否允许对外提供，接入输入审查、日志留存、生成内容可追溯
  • 视频下载、读取 cookie 等：须用户授权，评估平台条款与著作权风险
  • AI 商城上架第三方产品：厂商签合规承诺书（模型来源、备案、不经未授权中转站），上架前用风险题库测试拦截，上架后按季度抽检
  • 开源组件：转 LEG-28；需要资质（如 VPN）：转 LEG-24

10. 待确认问题

  • 合规评估主责是否由法务承担？法务人力不足时是否委托外部律师，预算怎么定？
  • 合规清单的命中项是否完整？是否增加“出海/数据出境”项？
  • 3 个工作日出结论是否可行？
  • 本条与 X-PRD-17“风险功能准入与合规需求评估”如何分工（建议产品侧发起、法务侧出结论）？
  • “C 端仅提供已备案模型、B 端可用境外模型”是否作为公司正式口径？
  • 合规结论库放在哪个系统，谁维护？
LEG-20AIGC 内容安全审核与 AI 生成标识合规待新建320

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：面向国内用户的 AI 生成产品（LeapPPT、LeapAll 等）正式推广前，或出现内容审核误杀、漏放、演示被拦截、需要向监管或客户说明时，落实内容审核链路、手机号实名注册、AI 生成标识、违规处置与复盘
  • 负责人：主责——产品线内容安全负责人（当前：LeapPPT 为李凯·推断待确认）；协同——审核链路研发（当前：马漳毓·推断待确认）、云资源与审核服务开通（当前：杨明学·推断待确认）、法务（当前：待指定）、运营审核员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 推广前合规门禁 → ② 审核链路接入 → ③ AI 生成标识 → ④ 分级策略配置与回归 → ⑤ 误杀/漏放处置 → ⑥ 疑似内容人工复核 → ⑦ 违规处置与留痕 → ⑧ 月度复盘
  • 交付结果：推广前检查单、审核策略配置记录、AI 生成标识实现、误杀/漏放处置记录、违规处置台账、《内容安全与隐私规范》
  • 状态依据：2026-05～06 LeapPPT 公测后才补审核与手机号注册；演示和外部试用至少 4 次被误拦，拦截等级随反馈临时调整，测试服曾下掉审核；AI 水印是否需要显式标识口径不一；安全负责人临时填写，复核与封号规则散落群聊

1. 场景判定

  • 触发条件：AI 生成产品计划正式推广或对外演示；接入新的生成能力（生图、视频、PPT）；用户反馈被误拦或发现违规内容漏放；客户/专家/监管问到内容安全措施；法规或国家标准更新
  • 典型说法：「审核是底线，一票否决制，容不得出一点错」「正式推广前，手机号注册和审核一定要加上」「新国标好像强制要求 AI 生成图片与视频打水印，我们有吗」「演示的时候被审核拦截了」「兜底预案：删数据、封号」
  • 判断问题：用户输入或生成的内容会不会被他人看到或带出平台？是否面向国内公众？是 → 本流程必须覆盖
  • 不归本流程管：社区帖子、评论、入驻资料的日常审核 → 请走 OPS-23；功能是否可做、境外模型能否使用 → 请走 LEG-19；协议与免责条款文本 → 请走 LEG-18；算法备案 → 请走 LEG-25；等保整改 → 请走 X-SEC-43

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品线内容安全负责人 推广前检查、策略配置审批、误杀/漏放处置、封号决定、月度复盘 R/A 内容安全负责人（当前：LeapPPT 为李凯·推断待确认）
审核链路研发 接入文本/图片/视频审核、长文本分段、标识实现、拦截日志 R 研发（当前：马漳毓·推断待确认）
云资源管理员 开通审核服务、短信服务权限，控制成本 R IT 运维（当前：杨明学·推断待确认）
法务 标识与审核义务的法律结论、规范审定、监管沟通口径 C 法务（当前：待指定）
运营审核员 疑似内容保密复核，记录结论 R 运营审核员（当前：待指定）
创始人兼 CTO 审核策略总原则、重大违规处置决策；为演示或客户放宽正式服策略的审批 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 产品生成能力清单（文本、图片、视频、PPT）与对外开放范围
  • 审核服务账号与权限、计费预估
  • 风险题库（涉政、涉黄、暴恐、违法违规等类别）和演示用例集
  • 用户注册方式与短信服务
  • 现行用户协议、隐私政策、免责声明版本
  • 监管或客户对内容安全的具体要求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 推广前检查：内容审核已接入、手机号注册、日志留存、协议与免责、AI 标识、模型名展示口径、安全负责人登记，任一未完成不得推广 内容安全负责人 正式推广前 5 个工作日 检查单（飞书多维表格） 放行记录 🔧飞书固化
2 接入审核：用户 prompt 与润色后 prompt 先审再生成；输出图片/视频审核；用户名、头像、签名审核；超长文本分段送审 审核链路研发 发布前完成 云内容安全服务 审核链路、拦截日志 🤖自动化
3 AI 生成标识：图片/视频/PPT 加隐式标识（元数据或隐水印），按法务结论加显式标识；客户端写死 AI 生成提示 审核链路研发 发布前完成 客户端/服务端 标识实现 🤖自动化
4 分级配置策略：C 端正式服保守；测试服可放宽但不得对外开放；演示和政企客户策略调整须审批；每次调整用风险题库与演示用例回归 内容安全负责人、审核链路研发 上线前 2 个工作日；调整当天回归 审核控制台、题库脚本 策略配置记录 🤖+👤
5 误杀/漏放处置：登记工单，判断调等级、加白、改提示词或补规则，回归后关闭 内容安全负责人 演示场景 2 小时内；一般 1 个工作日内 工单系统 处置记录 👤人工判断
6 机审疑似内容进入复核队列，运营保密复核，不得外传或公开 运营审核员 24 小时内 运营后台 复核结论 👤人工判断
7 违规处置：删除内容 → 标记高危账号 → 封号 → 留存证据；严重违法内容由法务决定是否报告 产品线内容安全负责人决定，法务协同 确认违规后 2 小时内删除，24 小时内完成封禁 运营后台 违规处置台账 👤人工判断
8 月度复盘：误杀率、漏放数、策略变更、题库更新，修订规范 内容安全负责人 每月第 1 周 多维表格 复盘记录、规范修订 🤖+👤

5. 交付物与模板

  • 交付物：推广前检查单、审核策略配置记录、AI 标识实现说明、处置记录与违规处置台账、《内容安全与隐私规范》
  • 建议模板/表单：
    • 推广前检查单字段：产品线、版本、审核覆盖范围（输入/输出/用户资料）、注册方式、日志留存期限、协议版本、标识方式、模型名展示口径、安全负责人、放行人
    • 策略配置记录字段：环境（测试/正式/客户私有化）、类目与等级、调整原因、审批人、回归结果、生效时间
    • 处置台账字段：时间、账号、内容类型、命中类目、机审结论、复核结论、处置动作、处置人

6. 异常与升级

  • 对外演示前审核误拦 → 演示负责人提前 1 个工作日用演示用例走查；现场被拦，2 小时内定位并回归 → 不得为演示临时关闭正式服审核，需放宽的升级 CTO 审批
  • 漏放违规内容被外部发现 → 2 小时内删除并封禁，留存证据 → 当天升级 CTO 与法务
  • 审核服务故障或欠费 → 暂停对应生成能力，不得裸跑 → 1 小时内升级云资源管理员与 CTO
  • 外包人工审核 → 先签保密协议，最小权限访问 → 法务确认
  • 法规或国家标准更新 → 法务 10 个工作日内出适用结论，研发按结论排期
  • 升级拍板：日常策略配置、误杀/漏放处置与封号由内容安全负责人作为 A 决定；出现以下任一情形时由创始人兼 CTO 作为 A（升级）决策——需放宽正式服审核策略、漏放违规内容被外部发现、审核服务故障需暂停生成能力、审核策略总原则调整

7. 衡量指标

  • 推广前门禁通过率 = 推广前完成检查单的产品 / 推广产品总数，目标 100%
  • 误杀率 = 被复核判定为误拦的请求 / 拦截请求总数，目标逐月下降，演示场景误拦 0 次
  • 漏放数 = 每月事后发现的违规生成内容条数，目标 0
  • 违规处置时效 = 确认违规到删除的时间，目标 ≤ 2 小时

8. 低效诊断

  • 现象：产品公测后才补内容审核和手机号注册（门禁环节）｜依据：「跃迁AI总动员」2026-05、「LeapPPT」2026-05
  • 现象：是否需要显式水印、是否展示底层模型名称口径不一，没有法务结论（合规判断环节）｜依据：「模态AI探索小分队」2026-05、「跃迁AI总动员」2026-05
  • 现象：演示和外部试用多次被误拦，“该拦的没拦住，不该拦的拦了很多”（策略配置环节）｜依据：「LeapPPT」2026-05、「LeapPPT」2026-06
  • 现象：拦截等级随反馈临时调整，测试服曾下掉审核，调整无记录（变更环节）｜依据：「LeapPPT」2026-05
  • 现象：超长文本不分段进不了审核，风险记录误标（技术接入环节）｜依据：「LeapPPT」2026-05
  • 现象：安全负责人临时填写，人工复核、封号规则散落在群聊（角色与规范环节）｜依据：「LeapPPT」2026-05

9. 分支变体

  • C 端公开产品：最保守策略，手机号注册，输入输出双审
  • 政企客户/私有化部署：审核策略按合同与客户要求配置，变更须法务确认并留档
  • 测试服 vs 正式服：测试服可放宽，但不得对外开放或用于外部演示
  • 文本审核 / 图片审核 / 视频审核：分别配置等级与回归用例
  • 图片、视频、PPT 的标识方式分别确定
  • 面向国内用户使用海外模型：先按 LEG-19 评估，界面是否展示模型名按法务结论

10. 待确认问题

  • 各产品线内容安全负责人分别是谁？是否需要公司级安全负责人统一对外？
  • 法务能否就 AI 生成内容标识（显式 + 隐式）适用范围出正式结论？
  • 日志留存期限定多久？
  • 是否允许为演示或特定客户放宽审核，审批人是谁？
  • 人工复核由内部运营做还是外包，保密协议由谁签？
  • 封号与申诉规则是否写入用户协议？
LEG-21营销短信与推广内容合规审核待新建48

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗2 × 跨3 × 险4

  • 适用场景：向用户发送含营销性质（优惠、免费额度包、活动、拉新、召回）的短信、站内信、邮件或推广文案前，完成分类、对象核查和文案合规审核后再发送
  • 负责人：主责——发送需求方运营（当前：待指定）；协同——法务（当前：待指定）、短信通道管理员（当前：待指定）、风险提示与技术支持 CTO（当前：丁震宇·推断待确认）；兜底——运营负责人
  • 核心流程：① 提交发送申请 → ② 通知类/营销类分类 → ③ 接收对象核查 → ④ 文案合规检查 → ⑤ 通道模板报备 → ⑥ 小批量试发与正式发送 → ⑦ 投诉与退订监控 → ⑧ 模板入库
  • 交付结果：审核通过的短信/推广文案与发送名单、通道模板、发送与投诉记录、合规文案模板库
  • 状态依据：2026-01 一条含“领取免费额度包”的短信文案，靠知识问答追溯此前讨论才发现属于营销性质、可能被投诉和拦截；没有分类规则、审核清单和模板库

1. 场景判定

  • 触发条件：短信、站内信、邮件、推送中出现优惠、免费、额度包、代金券、活动邀请、拉新、召回、续费引导等内容；批量向用户发送推广文案
  • 典型说法：「领取免费额度包」「发个短信通知用户来领」「这条算营销短信吗」
  • 判断问题：这条信息的目的是让用户“买、领、来、续”，还是只告知其账户或订单状态？前者是营销类，走本流程完整审核；后者为通知类，只需确认不夹带营销内容
  • 不归本流程管：营销活动方案、裂变玩法与预算审批 → 请走 MKT-14；新媒体日常内容发布 → 请走 BRD-08；对客户的政策/通知口径 → 请走 SAL-10；验证码、通知类短信技术接入 → 请走 RND-23；用户协议条款 → 请走 LEG-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发送需求方运营 提交申请、准备文案与名单、发送、监控投诉 R 运营（当前：待指定）
法务 审核营销类文案，维护合规检查清单 A 法务（当前：待指定）
短信通道管理员 模板与签名报备，区分营销/通知通道，导出退订名单 R 通道管理员（当前：待指定）
创始人兼 CTO 通道资源与风险提示，重大投诉处理决策 C 创始人兼 CTO（当前：丁震宇·推断待确认）
运营负责人 审批批量发送，兜底 I 运营负责人

3. 办之前请准备

  • 发送目的、对象范围、预计数量、计划发送时间
  • 文案初稿、跳转链接（须为公司已备案域名）
  • 接收对象的营销信息同意记录与退订名单
  • 活动规则（额度、期限、领取条件），用于核对文案承诺是否真实

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交发送申请：目的、对象、文案、链接、时间、数量 发送需求方运营 计划发送前 3 个工作日 飞书表单 发送申请 🔧飞书固化
2 分类：含优惠、免费、活动、拉新、召回即为营销类；通知类不得夹带营销内容 发送需求方运营（AI 预判） 提交当天 AI 检查 分类结果 🤖自动化
3 核查对象：营销类只发给已同意接收营销信息的用户，剔除已退订用户 短信通道管理员 1 个工作日内 用户库、退订名单 发送名单 🤖自动化
4 文案检查：签名为公司/产品名；带“拒收请回复 R”等退订方式；无绝对化用语；“免费”等承诺与活动规则一致；链接为自有备案域名 法务 1 个工作日内 合规检查清单 审核意见 🔧+👤
5 通道报备：营销类走推广短信签名与模板，不得放进验证码或通知模板 短信通道管理员 通道审核 1～2 个工作日 云短信控制台 模板审核通过 🔧飞书固化
6 先向内部账号小批量试发，确认展示与链接后正式发送，发送时间避开 21:00～次日 8:00（以通道商规则为准） 发送需求方运营 计划发送时间 云短信控制台 发送记录 🔧飞书固化
7 监控投诉、退订率、拦截率；收到投诉 24 小时内回复并加入退订名单 发送需求方运营 发送后 3 天 控制台报表 效果与投诉记录 🤖自动化
8 审核通过的文案入模板库，注明适用场景与审核日期 发送需求方运营 发送后 2 个工作日内 飞书文档/多维表格 合规文案模板 🔧飞书固化

5. 交付物与模板

  • 交付物：发送申请与审核记录、发送名单、通道模板、发送与投诉记录、合规文案模板库
  • 建议模板/表单：
    • 发送申请字段：发送目的、类型（通知/营销）、渠道（短信/站内信/邮件/推送）、对象范围、数量、文案、链接、计划时间、申请人、审核人
    • 合规检查清单：签名、退订方式、用户同意记录、绝对化用语、承诺真实性、链接域名、发送时段、频次上限

6. 异常与升级

  • 营销内容被误放进通知类模板 → 立即停止发送，改走营销通道 → 当天升级运营负责人
  • 收到用户向运营商或工信部投诉 → 24 小时内联系用户致歉并退订，留存记录 → 当天升级法务与运营负责人
  • 通道被封禁或签名被暂停 → 暂停全部营销发送，配合通道商整改 → 当天升级 CTO
  • 紧急发送来不及走 3 个工作日 → 用模板库已审文案；需新文案的由法务加急 4 小时内审核

7. 衡量指标

  • 营销短信审核覆盖率 = 经审核发送的营销类批次 / 营销类发送批次，目标 100%
  • 投诉率 = 投诉数 / 发送量，目标 ≤ 0.01%
  • 退订率 = 退订数 / 营销发送量，按月跟踪，异常升高时复盘文案
  • 模板复用率 = 使用模板库文案的批次 / 总批次，目标逐季上升

8. 低效诊断

  • 现象：含“领取免费额度包”的短信文案在准备发送时未经合规检查，靠知识问答追溯历史讨论才发现营销性质（审核环节）｜依据：「鼎慧产研决策部」2026-01
  • 现象：通知类与营销类短信没有区分规则，存在被拦截和被投诉的风险（分类环节）｜依据：「鼎慧产研决策部」2026-01
  • 现象：历史合规结论只留在聊天里，没有模板库可直接复用（沉淀环节）｜依据：「鼎慧产研决策部」2026-01

9. 分支变体

  • 通知类短信（账户、订单、额度到账）：只做“不夹带营销内容”检查，可走通知模板
  • 营销类短信：完整走步骤 1～8，必须有退订方式
  • 站内信与应用推送：不受短信通道约束，但同样需要文案合规检查与关闭入口
  • 邮件营销：需提供退订链接，发件域名使用公司域名

10. 待确认问题

  • 营销短信由哪个运营岗位主责？是否设专人管理短信通道？
  • 法务是否审每一批，还是只审新文案、模板库文案由运营自检？
  • 现有用户注册流程是否取得了营销信息接收同意？
  • 投诉率目标 0.01% 是否合适？
  • 本流程是否与 MKT-14 合并为“营销活动与触达合规”？
LEG-22业务合规红线与灰色业务风险隔离待新建120

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险5

  • 适用场景：业务中出现批量私信获客、代理 IP 池、购买/租用账号、数据买卖或交换等请求，或与外部合作方沟通涉及合规边界的话题时，按红线清单判断能否做，并让公司与员工远离违法风险
  • 负责人：主责——法务（当前：待指定）；协同——业务发起方负责人（跃竞：徐莉·推断待确认）、研发/IT（当前：待指定）、销售负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别请求 → ② 对照红线清单自查 → ③ 提交风险评审 → ④ 法务出结论（禁止/附条件可做） → ⑤ 争议决策 → ⑥ 附条件执行与留痕 → ⑦ 对外沟通口径 → ⑧ 登记台账与季度复查
  • 交付结果：业务合规红线清单、风险评审结论、附条件执行的合同与授权证明、对外沟通口径、风险评审台账
  • 状态依据：对接外部线索工具时仅有一次“不合规的东西少在飞书聊”的口头提醒，没有说明哪些事不能做；获客工具、IP 池、数据请求等风险判断依赖个人经验，没有红线清单和评审入口

1. 场景判定

  • 触发条件：有人提出或外部合作方要求：批量私信/群发获客；使用代理 IP 池或多账号规避平台风控；购买、租用、借用他人账号或批量注册账号；买卖、交换、代为撮合用户数据或线索名单；用员工个人账号或个人名义承接公司业务；对外沟通中出现规避监管、绕过备案或资质的说法
  • 典型说法：「不合规的东西少在飞书聊」「这个话题挺敏感的，能不沾就不沾」「要做就得把风险隔离出去」「不建议做」
  • 判断问题：这件事如果被平台、用户或监管看到完整记录，公司能否坦然说明？如果需要“换个地方聊”“换个主体做”才敢做，就必须先走本流程，而不是先换渠道
  • 不归本流程管：具体产品功能的合规评估 → 请走 LEG-19；外包数据采集委托 → 请走 RND-88；正常主动获客渠道（社群、短视频、私域、邮件） → 请走 SAL-01；对外提供含客户信息的材料 → 请走 LEG-30；营销短信 → 请走 LEG-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
业务发起方 识别请求、对照清单自查、提交评审、按结论执行 R 业务发起方负责人（跃竞：徐莉·推断待确认）
法务 维护红线清单，出评审结论与条件，审定对外口径 A 法务（当前：待指定）
研发/IT 说明技术实现（账号、IP、数据流向），落实技术限制 C 研发/IT（当前：待指定）
销售负责人 涉及客户线索与数据合作时参与评估 C 销售负责人（当前：待指定）
创始人兼 CTO 争议事项最终决策，红线清单发布 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
全体员工 遇到红线请求不承接、不经手并上报 I 全体员工

3. 办之前请准备

  • 请求来源（客户、合作方、内部）与具体内容
  • 业务目的、预计规模、涉及的平台及其规则
  • 涉及的数据来源与授权证明（如有）
  • 拟合作方主体信息与资质
  • 技术实现方式（账号、IP、自动化工具）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别请求，暂不承诺、不报价、不试做 业务发起方 收到请求当天 — 暂缓答复 👤人工判断
2 对照红线清单自查：命中“禁止”项直接婉拒；命中“需评审”项进入步骤 3 业务发起方 收到请求当天 红线清单（飞书文档） 自查结果 🔧+🤖
3 提交风险评审单，写明目的、规模、数据来源、技术方式、合作方 业务发起方 自查后 1 个工作日内 飞书审批 风险评审单 🔧飞书固化
4 法务出结论：禁止 / 附条件可做（合同、来源授权、用户同意、平台规则符合、留痕要求） 法务 3 个工作日内 飞书审批 评审结论 👤人工判断
5 业务方对结论有异议或涉及重大收入的，提请决策 创始人兼 CTO 2 个工作日内 飞书会议 决策记录 👤人工判断
6 附条件执行：与有资质合作方签书面合同明确合规责任；保留授权与同意证明；不使用员工个人账号或个人名义 业务发起方 按结论执行 合同（LEG-04） 合同与授权证明 🔧+👤
7 对外沟通：使用公司正式渠道，按法务审定口径答复，不承诺违规事项；不以更换沟通渠道代替合规评估 业务发起方 每次对外沟通 企业邮箱/飞书 沟通记录 👤人工判断
8 评审结论入台账；每季度复查附条件事项是否仍满足条件，并更新红线清单 法务 结论后 2 个工作日入台账；每季度首月 多维表格 风险评审台账、清单更新 🔧+🤖

5. 交付物与模板

  • 交付物：《业务合规红线清单》、风险评审单与结论、合同与授权证明、风险评审台账
  • 建议模板/表单：
    • 红线清单结构：禁止项（买卖或交换个人信息与未授权数据；未经同意批量私信、群发；购买、租用他人实名账号或批量注册账号；用代理 IP 池规避平台风控进行群发或抓取；用员工个人账号/个人名义承接公司业务或收款；借用外部主体或他人名义规避监管责任；绕过备案或资质对外提供服务）；需评审项（线索工具与获客工具对接、数据合作、自动化触达工具、代理 IP 用于正常网络测试）
    • 风险评审单字段：请求来源、业务目的、规模、命中清单项、数据来源与授权、技术方式、合作方、评审结论、条件、复查日期

6. 异常与升级

  • 已经开始做才发现命中红线 → 立即停止，保留现有记录，不删除证据 → 当天升级法务与 CTO
  • 客户或合作方坚持要求 → 按法务口径婉拒，必要时终止合作 → 由业务负责人 2 个工作日内决定
  • 员工以个人身份承接相关业务 → 法务提示风险并要求停止 → 当天升级 CTO
  • 平台或监管问询 → 统一由法务答复，其他人不单独回应 → 当天升级 CEO
  • 升级拍板：评审结论由法务作为 A 出具；出现以下任一情形时由创始人兼 CTO 作为 A（升级）决策——业务方对结论有异议、涉及重大收入、已开始执行才发现命中红线、红线清单发布或修订

7. 衡量指标

  • 红线请求上报率 = 进入评审台账的请求 / 已知相关请求，目标 100%
  • 评审时效 = 提交到结论的工作日，目标 ≤ 3 天
  • 红线违规事件 = 每年因违规获客、数据、账号问题被平台处罚或被投诉的次数，目标 0
  • 红线清单年度更新次数，目标 ≥ 2 次

8. 低效诊断

  • 现象：与外部线索工具方沟通涉及合规敏感内容时，只有“换个地方聊”的口头提醒，没有说明什么能做、什么不能做（沟通环节）｜依据：「线索工具对接」2026-07
  • 现象：获客工具、IP 池、数据请求等是否可做靠个人经验口头判断，没有清单和评审入口，结论不留痕（评估环节）｜依据：「线索工具对接」2026-07
  • 现象：没有红线清单，业务人员不知道何时该上报，只能事后被提醒（识别环节）｜依据：「线索工具对接」2026-07

9. 分支变体

  • 批量私信/获客工具：只允许在用户同意和平台规则范围内的触达，自动化工具上线前评审
  • 数据买卖或交换：公司不买卖个人信息；外部方要求撮合数据交易的，一律婉拒，不经手、不转介
  • 代理 IP 池与多账号：仅限正常网络测试和合规采集，须说明用途；规避平台风控的用途禁止
  • 跃竞获客线索工具：对外销售前须完成评审，产品功能部分同步走 LEG-19

10. 待确认问题

  • 红线清单的禁止项与需评审项是否完整？由谁签发？
  • 风险评审主责是否由法务承担？业务量大的条线（如跃竞）是否需要指定合规接口人？
  • 对外沟通涉及合规边界时，是否统一要求使用公司正式渠道并留痕？
  • 已经在进行的相关业务是否需要做一次存量排查？
LEG-23ICP/网站/App 备案办理与备案信息维护待优化240

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：新域名、展示站、产品站或 App 需要对外使用，或云厂商发来备案核查通知、备案信息（主体、负责人、电话）需要变更时，完成 ICP 备案、公安联网备案、App 备案及备案信息维护
  • 负责人：主责——备案专员/IT 运维（当前：杨明学·推断待确认）；协同——证照与授权委托材料、签章（当前：赵雪冰·推断待确认）、苏州主体材料提供人（当前：刘昱潇·推断待确认）、法人/主体负责人（当前：邴龙志·推断待确认）、站点研发（当前：宋祺睿·推断待确认）、App 上架产品经理（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 备案需求登记 → ② 查台账判断是否需新备案 → ③ 确定主体与负责人 → ④ 备齐材料包 → ⑤ 云厂商提交与管局审核 → ⑥ 公安联网备案与备案号展示 → ⑦ 登记台账 → ⑧ 核查响应与信息变更
  • 交付结果：ICP 备案号、公安联网备案号、App 备案号；备案台账（域名/App、主体、负责人、联系人、状态）；备案材料包模板
  • 状态依据：备案已跑过多次、有实际执行人，但 2026-01～09 约 40 次相关讨论中反复出现管局退回、签章加急、多人重复购买站点、联系人电话打不通被云厂商限期整改、App 上架前才补备案号；依赖个人经验，无台账和检查表

1. 场景判定

  • 触发条件：新购域名或新站点准备对外访问；新 App 或小程序准备上架；云厂商发备案核查电话/邮件或限期整改通知；备案主体、网站负责人、联系电话变化；域名换主体或停用需注销
  • 典型说法：「备案材料都交了先」「为啥备案备到我这里了」「上架需要备案号」「备案急速审核，2 小时」「如果后续还是无法打通电话就要变更备案」
  • 判断问题：这个域名或 App 是否要在中国大陆对公众提供访问？已备案主域名下的子域名不需要另行备案，先查台账
  • 不归本流程管：域名购买与 DNS 解析（含品牌域名选购） → 请走 X-SEC-20 / X-SEC-19；证书与域名到期续期 → 请走 X-SEC-21；软著申请 → 请走 POL-10（软件著作权申请）；算法备案 → 请走 LEG-25；增值电信许可 → 请走 LEG-24；用印审批 → 请走 LEG-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求方 登记备案需求（域名/App、用途、拟用主体、上线日期） R 站点/App 需求部门
备案专员/IT 运维 查台账、提交备案、跟进审核、维护台账、响应核查 R 备案专员（当前：杨明学·推断待确认）
综合部证照管理 营业执照、授权委托书、核验单盖章与签字流转 R 综合部（当前：赵雪冰·推断待确认）
苏州主体材料提供人 提供苏州主体证照与负责人材料 C 苏州主体负责人（当前：刘昱潇·推断待确认）
法人/主体负责人 签字、配合核验，知悉备案事项 C 法人（当前：邴龙志·推断待确认）
站点研发 网站内容上线、页脚展示备案号 R 站点研发（当前：宋祺睿·推断待确认）
App 上架产品经理 提供包名、证书指纹、SDK 清单、上架时间 C 产品经理（当前：杨萌·推断待确认）
创始人兼 CTO 决定用哪个主体备案，处理撤销风险 A 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 域名证书/域名持有人信息（须与备案主体一致）、站点用途与内容说明
  • 主体营业执照、法人证件、网站负责人证件（须为最新版）
  • 授权委托书、核验单（盖章、法人签字）
  • 核验视频或人脸核验所需人员到场或在线配合
  • App 备案另需：App 名称（与软著、上架名称一致）、包名、公钥/证书指纹、SDK 清单、服务器 IP 或域名
  • 网站负责人、应急联系人的可接通手机号与公共邮箱

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记备案需求：域名/App、用途、拟用主体、对外上线日期 需求方 对外上线前 20 个工作日 飞书表单 备案申请 🔧飞书固化
2 查台账：是否已备案、能否用已备案主域名的子域名、同主体是否已有同类站点 备案专员 1 个工作日内 备案台账 是否需新备案的结论 🤖自动化
3 确定备案主体与网站负责人；负责人须知情、能接听核验电话 创始人兼 CTO 1 个工作日内 飞书审批 主体与负责人确认 👤人工判断
4 按材料包模板备齐材料，盖章签字走用印审批 备案专员、综合部证照管理 2 个工作日内 材料包模板、LEG-09 材料包 🔧飞书固化
5 在云厂商提交（每批不超过 2 个域名），跟进初审与管局审核；退回 1 个工作日内补正 备案专员 提交后每 2 个工作日查一次状态 云厂商备案控制台 ICP 备案号 🔧飞书固化
6 网站开通后 30 日内办理公安联网备案；页脚展示 ICP 与公安备案号并链接；App 在上架资料中填写备案号 备案专员、站点研发 取得备案号后 30 日内 公安备案平台 公安联网备案号、页脚展示 🔧飞书固化
7 登记台账：域名/App、主体、备案号、负责人、联系人、云厂商、状态、下次自查日期 备案专员 取得备案号后 1 个工作日内 多维表格 备案台账 🔧+🤖
8 信息维护：核查电话/邮件当天响应；人员离职、电话变化、主体变更 10 个工作日内提交变更；根域名保持有实际内容；每半年自查一次 备案专员 核查当天响应；按通知时限整改 云厂商控制台、飞书任务 变更记录、自查记录 🔧+👤

5. 交付物与模板

  • 交付物：备案号（ICP、公安联网、App）、备案台账、材料包、变更与自查记录
  • 建议模板/表单：
    • 备案台账字段：域名/App 名称、类型（网站/App/小程序）、用途、备案主体、ICP 备案号、公安备案号、云厂商、网站负责人、应急联系人、联系电话归属、备案日期、最近核查日期、状态（审核中/已备案/变更中/已注销）
    • 材料包模板：按主体分别准备营业执照、法人证件、授权委托书模板、核验单模板、证件有效期提醒
    • App 备案清单：App 名称、包名、公钥/证书指纹、SDK 清单、服务器信息、软著登记号

6. 异常与升级

  • 管局退回 → 1 个工作日内按退回原因补正；同一原因退回 2 次 → 升级综合部负责人核对材料口径
  • 公章或法人签字流转卡住 → 用印审批加急 → 超 2 个工作日升级 CTO
  • 云厂商核验电话打不通、被通知整改 → 当天联系负责人回电，同步启动联系人变更 → 有撤销风险时当天升级 CTO
  • 被登记为联系人但不知情 → 当天按“知悉并配合”回复云厂商，3 个工作日内变更为正确负责人 → 备案专员负责
  • 需求方要求规避备案或使用非正规“加速”手段 → 拒绝；可使用云厂商官方加急服务 → 升级 CTO 决定上线时间

7. 衡量指标

  • 备案一次通过率 = 首次提交即通过的备案数 / 提交总数，目标 ≥ 80%
  • 备案周期 = 提交到取得备案号的自然日，目标 ≤ 20 天
  • 核查响应时效 = 收到核查通知到回复的时间，目标当天
  • 台账准确率 = 自查中信息与云厂商备案一致的条目 / 总条目，目标 100%
  • 因备案导致的上线延误次数，目标 0

8. 低效诊断

  • 现象：管局多次退回（如负责人证件不是最新版），材料准备靠个人经验（材料环节）｜依据：「忠橙星行星引擎」2026-04、「忠橙星行星引擎」2026-05
  • 现象：一次备案多个网站需额外录制视频、打印扫描盖章，签字章流转需要加急（签章环节）｜依据：「忠橙星行星引擎」2026-04
  • 现象：联系人默认填写不接陌生电话的人，云厂商核验打不通被要求限期整改（联系人环节）｜依据：「忠橙星行星引擎」2026-07
  • 现象：同一用途的站点有人已有正式站、有人另买展示站备案，信息不同步（台账环节）｜依据：「鸽子群模态分群」2026-07
  • 现象：讨论用技巧绕开备案或买加速服务，缺少合规口径（合规环节）｜依据：「鸽子群模态分群」2026-06、「鸽子群模态分群」2026-07
  • 现象：App 到上架阶段才补备案号与软著，App 名称大小写多版本不一致（App 环节）｜依据：「手机端-录音卡」2026-09

9. 分支变体

  • 云厂商 A 备案（当前以苏州模态为主体）：按云厂商建议每批 2 个域名
  • 云厂商 B 备案（武汉模态旧备案）：联系人与电话需尽快变更为在职可接通人员
  • App 备案：iOS/Android/鸿蒙分平台准备包名与证书指纹；名称与软著一致，软著部分走 POL-10
  • 新增 / 变更 / 注销：域名停用或换主体时先注销或迁移备案，避免空壳备案被核查
  • 公安联网备案：网站开通后 30 日内办理

10. 待确认问题

  • 备案主责是否由 IT 运维承担，还是归口综合部/法务？
  • 本条与 X-SEC-20“域名购买与 ICP/算法备案、主体迁移”（已含原 BRD-03）如何划分（建议：域名购买与解析归 X-SEC，备案办理与信息维护归本条）？
  • 网站负责人与应急联系人统一登记哪个岗位？是否配公司座机或公共邮箱？
  • 各域名分别用哪个主体备案的规则是什么？
  • 对外上线前 20 个工作日提交是否可行？
LEG-24增值电信业务许可证办理与年报待新建160

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：每年 1～3 月持证主体办理增值电信业务经营许可证年报（3 月 31 日截止），或业务需要新办、增项、续期、变更增值电信许可（ICP、EDI、国内互联网虚拟专用网 B13 等，如 LeapVPN 对外经营）时，完成证照核查、材料与方案准备、填报提交、跟进审查和归档
  • 负责人：主责——综合部证照资质管理（当前：赵雪冰·推断待确认）；协同——年报填报执行（当前：杨明学·推断待确认）、新办/增项证照申报岗（总经办，当前：田杰·推断待确认）、技术方案编写人（当前：吴世豪·推断待确认）、业务说明起草与技术审核 CTO（当前：丁震宇·推断待确认）、往年材料与经验提供（当前：常元和·推断待确认）、财务（上年财务报表，当前：待指定）、行政协助（当前：侯明月·推断待确认）；审定——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 合规日历自动提醒 → ② 核对持证清单与系统账号 → ③ 收集财务、业务与网络安全材料 → ④ 填报 → ⑤ CTO 核对业务类别与数据、CEO 审定 → ⑥ 提交并留存回执 → ⑦ 新办/增项：确认许可类别、咨询材料清单、确认上游云服务商合规支持 → ⑧ 编写可研报告与技术、安全方案，核验各类负责人 → ⑨ 内部审批后提交并跟进审查 → ⑩ 领证、证照原件与材料归档
  • 交付结果：按期提交的年报回执、网络与信息安全管理制度文件、业务说明；新办/增项的可行性研究报告、网络技术方案、安全保障方案与申报进度表；新办、增项或续期后的许可证（电子与纸质）、资质台账与年度材料包；产品“有证经营”上线确认
  • 状态依据：2026-01 年报靠外部通知和临时指派“谁负责”启动，网络安全管理制度缺失需临时起草，业务类别（ICP/EDI）描述写偏重写，往年材料靠个人保存；2026-08 新办许可时证书原件下落不明、不知此前由谁办理；2026-08～09 首次完成 VPN 类许可申报并获批，但技术方案图表格式返工、负责人人选到填表时才发现不满足条件，材料清单与方案模板未沉淀

1. 场景判定

  • 触发条件：每年 1 月（年报窗口 1 月 1 日～3 月 31 日）；业务新增需要许可的类别（如虚拟专用网、在线数据处理），或新产品对外提供 VPN、跨网组网、网络加速等可能属于增值电信的业务；现有许可需增加业务类别或覆盖范围；云服务商、渠道或客户要求出示许可；许可证有效期届满前 90 日以上需续期；主体名称、地址、法人、股权等变更；通信管理局抽查或通知
  • 典型说法：「增值电信业务许可证，每年 1～3 月份年审哦」「模态的 ICP、EDI 也记得年审一下」「我们之前有各类网络安全相关的制度文档吗」「记得整虚拟网增值电信」「之前 ICP 是谁在整」
  • 判断问题：这件事是不是“以公司名义持有或申请电信业务经营许可证”？产品是否向第三方经营增值电信业务、现有许可是否已覆盖该业务类别和地域？网站 ICP 备案不是许可证，走 LEG-23
  • 不归本流程管：ICP 备案、App 备案 → 请走 LEG-23；算法备案、办学许可、3C 等其他资质 → 请走 LEG-25；工商年报与证照年检 → 请走 GEN-14（公司对外账号、证照年检与年报管理）；等保测评 → 请走 X-SEC-43；系统账号密码分发 → 请走 X-SEC-10；员工远程办公 VPN 接入 → 请走 X-SEC-25；海外出口线路运维 → 请走 X-SEC-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
综合部证照资质管理 维护资质台账与合规日历，统筹年报与新办，保管原件 R 综合部（当前：赵雪冰·推断待确认）
年报填报执行 在工信部系统填报、上传材料、留存回执 R 填报执行（当前：杨明学·推断待确认）
证照申报岗 新办/增项：咨询通信管理局、写可行性报告、核验负责人、系统填报、跟进审查、领证 R 总经办（当前：田杰·推断待确认）
技术方案编写人 编写网络技术方案、网络与信息安全保障方案 R 对应产品技术负责人（当前：吴世豪·推断待确认）
许可登记负责人 作为安全、许可、客服负责人登记（须满足在本主体在职、缴纳社保等条件） C 安全/许可/客服负责人（当前：吴世豪、杨朋伟、赵雪冰·推断待确认）
创始人兼 CTO 起草/核对业务说明与业务类别，核对用户数等技术数据；确认新办业务模式、上游云服务商合规支持，Review 技术与安全方案 R 创始人兼 CTO（当前：丁震宇·推断待确认）
往年材料提供人 提供往年年报材料包与经验 C 材料提供人（当前：常元和·推断待确认）
财务 提供上年财务报表与经营数据 R 财务（当前：待指定）
行政 协助查找原件、盖章、快递 C 行政（当前：侯明月·推断待确认）
CEO 年报与新办/增项审定，最终兜底 A CEO（当前：邴龙志·推断待确认）
云服务商 确认上游资源合规支持 C 云服务商（外部）

3. 办之前请准备

  • 持证清单：各主体（模态、苏州模态、跃迁等）持有的许可类别、证号、有效期
  • 工信部电信业务市场综合管理系统账号（按 X-SEC-10 由保管人私密提供，不在群里发）
  • 上年度财务报表与经营数据
  • 用户数、业务开展情况等真实业务数据
  • 网络与信息安全管理制度、应急预案、算法安全主体责任材料
  • 往年年报材料包与回执
  • 新办/增项另需：业务说明（服务对象、覆盖范围、业务模式、收费方式）；上游云服务商合规支持确认（书面或邮件留痕）；主体营业执照、注册资本、股东信息；安全、许可、客服负责人人选及其在本主体在职、缴纳社保的证明（提前核验）；系统架构、网络拓扑、安全措施资料（日志留存、实名、应急处置）；政务系统账号与验证码接收人（参考 X-SEC-12）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合规日历在每年 1 月第 1 周按主体、按证自动生成年报任务并指定执行人 综合部证照资质管理 每年 1 月 1 日～7 日 飞书任务/多维表格 年报任务 🔧飞书固化
2 核对持证清单、有效期与系统账号可登录 年报填报执行 任务生成后 3 个工作日内 工信部系统、资质台账 核对结果 🔧飞书固化
3 收集材料：财务报表、业务数据、网络与信息安全制度（缺失的用模板 + AI 起草后人工审定） 财务、创始人兼 CTO、年报填报执行 1 月 31 日前 材料库、AI 年报材料包 🤖+👤
4 在系统填报，业务说明与许可类别（ICP/EDI 等）严格对应，数据如实填写 年报填报执行 2 月 28 日前 工信部系统 填报草稿 🔧飞书固化
5 CTO 核对业务类别与技术数据，CEO 审定 创始人兼 CTO、CEO 收到后 3 个工作日内 飞书审批 审定记录 👤人工判断
6 提交并截图回执，回执与材料包归档 年报填报执行 3 月 15 日前（截止 3 月 31 日） 工信部系统、飞书云文档 年报回执 🔧飞书固化
7 新办/增项/续期/变更：确认业务类型与许可类别（如 B13），判断新申请还是增项，决定自办或代理；续期、变更按通信管理局要求准备材料提交 证照申报岗、创始人兼 CTO 新办在产品立项后 3 个工作日内启动；续期在有效期届满前 90 日以上提交 飞书文档 申报决策 👤人工判断
8 向通信管理局咨询材料清单与口径；同步与上游云服务商确认合规支持 证照申报岗；创始人兼 CTO 决策后 3 个工作日内 电话/官网、邮件/工单 材料清单、云服务商确认记录 👤人工判断
9 起草网络技术方案、安全保障方案（AI 基于需求与代码仓库起草，图表须在 Word 中可正常查看）与业务可行性研究报告；CTO Review 后转为政府审核口径 技术方案编写人、证照申报岗、创始人兼 CTO 清单确定后 5 个工作日内起草，收稿后 3 个工作日内定稿 AI 工具 + 方案模板 方案与可研定稿 🤖+👤
10 确认安全/许可/客服负责人并核验在职、社保等条件 证照申报岗 清单确定后 2 个工作日内 社保与在职核对 负责人名单 👤人工判断
11 内部审批（含用印，LEG-09）后在系统提交，必要时申请加急；跟进受理（约 5 个工作日）与审查（最长约 60 个工作日），每周更新进度表，补正 3 个工作日内回复 证照申报岗 材料齐后 2 个工作日内提交；每周更新 飞书审批、通信管理局政务平台、进度表 提交回执、进度记录 🔧+👤
12 证照原件入档案柜并登记保管人；新证下载电子证照、申请纸质证照邮寄，通知产品可有证经营；更新资质台账与下次年报/续期日期 综合部证照资质管理、证照申报岗 取得或提交后 2 个工作日内 档案台账、多维表格 资质台账更新、证照归档 🔧飞书固化

5. 交付物与模板

  • 交付物：年报回执、年度材料包、网络与信息安全管理制度、业务说明、许可证原件与电子版、资质台账
  • 建议模板/表单：
    • 资质台账字段：主体、许可类别、证号、发证机关、发证日、有效期至、年报截止日、续期提醒日（到期前 120 天）、原件保管位置、保管人、系统账号保管人、最近年报回执
    • 年度材料包目录：财务报表、业务说明、用户与经营数据、网络与信息安全制度清单、应急预案、上年回执

6. 异常与升级

  • 3 月 15 日仍未提交 → 综合部证照资质管理每日催办 → 升级 CEO
  • 系统账号无法登录或保管人离职 → 按找回流程处理，2 个工作日内完成 → 升级综合部负责人
  • 业务说明类别与实际业务不符 → 不得照抄往年，由 CTO 重写后再审定 → 当周完成
  • 证书原件找不到 → 查档案台账与行政记录，3 个工作日内未找到 → 升级 CEO 决定是否补办
  • 新办许可自办遇阻 → 评估代理（预算需审批） → 升级 CEO
  • 新办/增项负责人人选不满足在职、社保等条件 → 在步骤 10 提前核验，不满足则 1 个工作日内换人 → 升级综合部负责人
  • 收到补正要求 → 3 个工作日内回复 → 涉及技术内容升级 CTO
  • 审查超过 60 个工作日无结果 → 证照申报岗致电通信管理局 → 升级综合部负责人
  • 产品上线时间早于获批 → 不得对外经营收费 → 升级 CTO、CEO
  • 上游云服务商不支持 → 暂停申报，重评业务模式 → 升级 CTO
  • 政务平台验证码接收人不在岗 → 按 X-SEC-12 代收
  • 拍板口径：年报与新办/增项的提交前审定由 CEO 作为唯一 A；综合部证照资质管理、证照申报岗负责执行（R），CTO 负责业务类别与技术方案把关（R）

7. 衡量指标

  • 年报按期完成率 = 3 月 15 日前提交的许可证数 / 应报许可证数，目标 100%
  • 不良名单记录 = 因年报或许可问题被列入不良名单的次数，目标 0
  • 资质台账完整率 = 有效期、保管人、账号保管人齐全的许可证 / 持证总数，目标 100%
  • 材料复用率 = 年报材料从材料库直接复用的比例，目标 ≥ 80%
  • 新办/增项材料准备周期 = 立项到系统提交的工作日数，目标 ≤ 15 个工作日；补正次数 ≤ 1 次；方案返工轮次 ≤ 1 次
  • 无证经营天数 = 需要许可的业务在获批前对外经营的天数，目标 0

8. 低效诊断

  • 现象：网络安全管理制度缺失，年报前临时起草（材料环节）｜依据：「忠橙星行星引擎」2026-01
  • 现象：业务类别（ICP/EDI）说明写偏，需要重写（填报环节）｜依据：「忠橙星行星引擎」2026-02
  • 现象：每年重新找往年材料，依赖个人保存的材料包（沉淀环节）｜依据：「忠橙星行星引擎」2026-01
  • 现象：年报提醒来自外部通知，再临时问“谁负责”指派（触发与角色环节）｜依据：「内务大主管」2026-01
  • 现象：系统账号信息在群里问答（账号保管环节）｜依据：「内务大主管」2026-01
  • 现象：新办许可时证书原件下落不明，此前办理经验无人记录（证照保管环节）｜依据：「董事会专项沟通群」2026-08
  • 现象：新办 VPN 类许可时技术方案图表在 Word 中无法正常查看，需返工重出（方案编写环节）｜依据：（推断）
  • 现象：安全/许可/客服负责人人选到填表时才发现不满足条件，临时更换（负责人核验环节）｜依据：（推断）
  • 现象：方案移交办理人员后进度靠口头同步，材料清单与方案模板未沉淀（进度跟踪环节）｜依据：（推断）

9. 分支变体

  • 多主体：模态、苏州模态、跃迁等主体分别核对持证情况、分别年报
  • 许可类别：ICP（信息服务）、EDI（在线数据处理与交易处理）、国内互联网虚拟专用网（B13）等，类别以通信管理局最新目录为准
  • 新办方式：自办（官网政务平台申请）或代理（预算需审批）
  • 新申请 vs 增项：已有增值电信许可时按增项办理，可复用主体资质材料；办理阶段为初审 → 受理（约 5 个工作日）→ 审查（最长约 60 个工作日）→ 批复 → 电子证照 + 纸质证照邮寄
  • 续期与变更：有效期届满前 90 日以上提出续期；主体信息变更后按要求办理变更
  • 新办/增项材料模板：网络技术方案（业务概述、网络架构与拓扑、节点与资源、接入方式、运维体系）；网络与信息安全保障方案（组织与负责人、日志留存、实名与身份核验、内容与访问控制、应急处置）；申报进度表（许可类别、主体、申报日、受理日、审查状态、补正要求、批准日、证照编号、有效期、年报日期、负责人）
  • 已合并原 POL-13（增值电信（VPN）业务许可申请）：其新办/增项的材料清单咨询、云服务商合规确认、方案编写、负责人核验、提交跟进与领证步骤已并入步骤 7～12

10. 待确认问题

  • 资质与年报主责是否为综合部？年报执行人是否固定为 IT 运维？
  • 合并原 POL-13 后，增值电信许可新办/增项归口政策申报、总经办还是综合部/法务？证照申报岗是否固定为总经办？请管理层裁定
  • 安全/许可/客服负责人的任职条件（在职、社保等）是否有成文清单？
  • 电子证照有效期与下载留存要求是什么？
  • 新办/增项立项到提交 15 个工作日是否可行？LeapVPN 之外是否还有产品需要评估增值电信许可？
  • 各主体实际持有哪些许可证、有效期分别到何时？
  • 虚拟专用网业务许可是否确需办理、类别如何认定？是否需要外部咨询？
  • 网络与信息安全管理制度由谁维护，是否与等保材料合并？
  • 是否建立覆盖 ICP、许可证、工商年报、商标续展的公司级合规日历？
LEG-25算法备案、办学许可、3C 认证等专项资质办理待新建200

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：产品上线前需做算法备案（或已提交的算法备案材料被打回需补正、备案信息需变更）、拟开展对外收费培训需判断是否申领办学许可、新机型或新供应商硬件出货（尤其渠道批量）需要 3C 证书时，先判断是否必须办理，再组织办理并维护资质台账
  • 负责人：主责——综合部负责人（资质合规统筹）（当前：赵雪冰·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总经办专员（当前：田杰·推断待确认）、IT 运维/采购资产（当前：杨明学·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、产品负责人（当前：杨萌·推断待确认）、交付工程师（当前：游家豪·推断待确认）、法务负责人（当前：李瑶·推断待确认）、算法备案材料负责人（当前：陈子康·推断待确认）、研发改造（当前：王皓南·推断待确认）；决策与兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 需求登记 → ② 是否需办理判定 → ③ 定主体与责任人 → ④ 准备材料 → ⑤ 内部审核对齐 → ⑥ 提交/送检跟进 → ⑦ 取证入台账 → ⑧ 到期与变更提醒
  • 交付结果：取得的算法备案号/办学许可证/3C 证书；资质台账（含机型—证书对应表）；可对外提供的证书资料包
  • 状态依据：2026-06～09「【模态】总经办」中 3C 证书催办约 5 次，内部对“3C 是否强制”出现相反口径；算法备案材料多版往返修改（2026-02 首次提交因材料自相矛盾、自评估超期、缺截图被打回，2026-05 新一轮备案仍无明确材料负责人），办学许可申领主体未定；无资质清单、无机型—证书对应表，合规判断靠口头

1. 场景判定

  • 触发条件：新产品/新功能以生成式 AI 或推荐算法向公众提供服务；拟开展社会化收费培训、认证课程；新机型、核心配置（CPU/主板/电源）变更或更换 ODM 供应商后准备出货；渠道或客户要求出示 3C；已有资质临近到期或主体、产品信息变更
  • 典型说法：「3C 非强制，硬件渠道才需要」「没有就是非法的」「渠道大批量出没有 3C 可能有问题」「落实算法安全主体责任基本情况」「社会化收费培训要申领办学许可证」
  • 判断问题：上线或出货前是否需要监管部门的备案、许可或强制认证？不办是否会被处罚、被渠道拒收？
  • 不归本流程管：ICP/网站/App 备案 → 请走 LEG-23；域名购买与备案主体迁移 → 请走 X-SEC-20；增值电信业务许可证 → 请走 LEG-24；新产品上线整体合规评估 → 请走 LEG-19；软著 → 请走 POL-10（软件著作权申请）；AI 生成标识等内容安全的产品规范 → 请走 LEG-20；商标 → 请走 LEG-16；等保测评 → 请走 X-SEC-43

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资质合规统筹 维护资质台账、组织判定、跟进办理、到期提醒 R 综合部负责人（当前：赵雪冰·推断待确认）
算法备案技术审核 起草/审核算法机制机理、安全自评估、负责人证明；指定材料负责人；审核一致性并在备案系统提交 R 创始人兼 CTO（当前：丁震宇·推断待确认）
算法备案材料负责人 起草拟公示内容、自评估报告等，一致性核对，跟踪审核并负责补正 R 研发（当前：陈子康·推断待确认）
研发改造 按备案要求局部改造产品（显性生成标识、用户权益入口），提供截图，展示备案号 R 研发负责人（当前：王皓南·推断待确认）
产品信息与材料修改支持 提供产品全称、功能、展示形态、上线计划；文字润色与对外口径修改 C 产品总监、后端、销售骨干（当前：杨萌、宋祺睿、闫登辉·推断待确认）
总经办专员 政策研究（办学许可）、材料格式与提交 R 总经办专员（当前：田杰·推断待确认）
机型配置判断 提供机型配置、联系 ODM 确认证书兼容 R IT 运维/采购资产（当前：杨明学·推断待确认）
渠道需求方 提出出货渠道与数量、确认是否必须持证 C 市场销售负责人（当前：李鹏为·推断待确认）
供应商证书跟进 按承诺日向供应商催收证书 R 交付工程师（当前：游家豪·推断待确认）
对外资料维护 证书进入交付/销售资料包 R 产品负责人（当前：杨萌·推断待确认）
法务 出具是否强制的书面意见、审核承诺书 C 法务负责人（当前：李瑶·推断待确认）
决策 确定申领主体、无证出货或无备案上线是否放行 A CEO（当前：邴龙志·推断待确认）
需求方 登记资质需求，提供业务/机型信息 R 产品、销售、采购需求人

3. 办之前请准备

  • 资质需求说明：产品/业务名称、上线或出货时间、服务对象（公众/企业/渠道）、运营主体
  • 算法备案：算法机制机理说明、半年内有效的算法安全自评估报告、算法安全负责人证明、承诺书、产品设计稿、用户协议与合同相关条款；备案平台账号与主体资质；产品全称、算法名称、版本、上线地址（从 POL-03 资料库取，统一口径）；历史成功备案材料包（作起草模板）；输入/输出模态、展示形态、应用场景说明；显性 AI 生成标识与用户权益入口截图
  • 办学许可：培训形式（社会化收费/公益/高校或企业内训）、拟申领主体、课程与收费方案
  • 3C：机型型号、核心配置清单、ODM 供应商、已有证书扫描件及有效期、出货渠道与数量
  • 现有资质台账（增值电信、ICP、已有 3C 等）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在资质台账登记需求，注明类型（算法/办学/3C/其他）与截止日期 需求方（产品/销售/采购） 发现需求后 1 个工作日内 飞书多维表格 资质需求记录 🔧飞书固化
2 判定是否必须办理：列法规依据、出货渠道（直销/渠道）、能否沿用已有证书（同核心同线程等兼容情况须 ODM 书面确认） 资质合规统筹 + 法务；3C 由 IT 采购提供技术判断 登记后 3 个工作日内 飞书文档 书面判定（需办/可沿用/不需） 👤人工判断
3 确定申领主体、内部执行人、目标完成日；算法备案由 CTO 指定材料负责人并设截止日 资质合规统筹；CEO 确认主体；CTO 指定算法备案材料负责人 判定后 2 个工作日内（材料负责人立项当日指定） 多维表格、飞书任务 责任人与计划 👤人工判断
4 准备材料：算法备案由材料负责人基于历史成功材料包用 AI 起草拟公示内容、算法安全自评估报告等，技术负责人补技术材料；办学许可由总经办研究政策与材料；3C 由交付向供应商索取证书或送检计划 各分支执行人（算法备案：算法备案材料负责人） 材料初稿 5 个工作日内 飞书文档 + AI + 模板 材料初稿 🤖自动化（AI 辅助起草）
5 算法备案：按材料要求局部改造产品（显性 AI 生成标识、投诉/关闭推荐/注销等用户权益入口）并截图 研发改造 与步骤 4 并行，5 个工作日内 代码仓库、测试环境 截图证明 👤人工判断
6 算法备案：一致性核对——算法名称、产品全称、主体、展示形态、输入输出模态在各份材料与产品中一致，自评估在半年内 算法备案材料负责人 1 个工作日内 核对清单 + AI 比对 核对记录 🤖+👤
7 内部审核：与产品设计、用户协议、合同条款逐项对齐，修改意见一次性汇总；算法备案由 CTO 审核一致性与合规口径 资质合规统筹、法务、产品负责人；算法备案加 CTO 收到初稿后 3 个工作日内 飞书文档批注 定稿 👤人工判断
8 提交/送检，每周五更新进度；供应商承诺日前 3 天提醒；监管打回的逐条对应审核意见整改并重新提交 分支执行人（算法备案由 CTO 在备案系统提交） 定稿后 2 个工作日内提交；打回后 3 个工作日内补正 监管平台/供应商；飞书任务 受理回执/送检单、补正材料 🔧+👤
9 取证后上传证书、录入编号与有效期；3C 同步更新机型—证书对应表；算法备案号在产品显著位置展示；证书进入对外资料包 资质合规统筹；产品负责人；研发改造 取证后 2 个工作日内（备案号展示 5 个工作日内） 多维表格、产品页面 台账更新、资料包、备案号展示 🔧飞书固化
10 到期前 90 天、主体或配置变更时自动提醒；新机型下单前自动比对对应表 资质合规统筹 持续 多维表格自动化 续期/重做任务 🔧+🤖

5. 交付物与模板

  • 交付物：备案号/许可证/3C 证书及附件；资质台账；机型—证书对应表；书面判定记录
  • 建议模板/表单：
    • 资质台账：资质类型、持证主体、产品或机型、证书/备案编号、颁发机关、取得日期、有效期、状态、责任人、附件、下次复核日
    • 机型—证书对应表：机型、CPU/核心配置、ODM 供应商、3C 证书号、覆盖型号范围、有效期、是否可用于渠道出货
    • 资质需求单：需求方、业务/机型、上线或出货日期、服务对象、判定结论、法规依据
    • 算法备案一致性核对清单：算法名称、产品全称、主体、输入模态、输出模态、展示形态、应用场景、自评估日期、标识截图、用户权益截图
    • 算法备案材料包模板：基于成功备案材料脱敏整理

6. 异常与升级

  • 上线/出货日前无法取得资质 → 推迟上线或暂停渠道批量出货（直销须在合同中约定风险）→ 当天升级 CEO 决策
  • 内部对是否强制意见不一 → 法务出具书面意见 → 2 个工作日内无结论升级 CEO
  • 供应商证书逾期 → 交付工程师书面催办 → 逾期 5 个工作日升级市场销售负责人与 CTO 评估换型或送检
  • 申领主体未定 → 资质合规统筹列出主体选项与利弊 → 5 个工作日内由 CEO 拍板
  • 监管退回补正 → 5 个工作日内补交（算法备案 3 个工作日内）→ 二次退回升级法务与 CTO，算法备案由 CTO 逐条过稿
  • 算法备案立项后无人承接 → 资质合规统筹 1 个工作日内报 CTO 指定；材料负责人经验不足、外包不可用 → CTO 提供成功模板并在 2 个工作日内定稿
  • 算法安全自评估报告超过半年 → 重做自评估，不得沿用
  • 备案所需产品改造排不进迭代 → 研发负责人 → CTO 定优先级（须在上线前完成）
  • 产品上线日期早于备案通过 → 暂缓对公众开放相关功能 → 升级 CTO、CEO
  • 拍板口径：申领主体、无证出货或无备案上线是否放行由 CEO 作为唯一 A 决定；资质合规统筹负责组织与跟进（R），算法备案由 CTO 负责技术审核与提交（R）

7. 衡量指标

  • 资质前置率 = 上线/出货前已取得所需资质的项目数 / 需资质项目数，目标 100%
  • 判定周期 = 需求登记到书面判定结论的工作日，目标 ≤ 3 天
  • 材料返工轮次 = 内部审核往返轮数，目标 ≤ 2 轮
  • 台账完整率 = 有附件与有效期的在用资质 / 在用资质总数，目标 100%
  • 过期在用数 = 已过期仍在使用的资质数，目标 0
  • 算法备案一次通过率 = 首次提交即通过的比例，目标 ≥ 70%；补正轮次 ≤ 1
  • 算法备案起草周期 = 立项到提交的工作日数，目标 ≤ 10 个工作日；材料负责人指派 ≤ 1 个工作日
  • 无备案上线次数，目标 0

8. 低效诊断

  • 现象：3C 证书交付靠群里反复催问，承诺日一再顺延（供应商跟进环节）｜依据：「【模态】总经办」2026-06、「【模态】总经办」2026-07
  • 现象：对“3C 是否强制”出现相反结论，渠道批量出货风险迟迟未定（判定环节缺书面依据）｜依据：「【模态】总经办」2026-07
  • 现象：3C 盯办人中途更换，责任不清（责任人环节）｜依据：「【模态】总经办」2026-08
  • 现象：合规议题以线下口头讨论定结论，未书面留存（判定留痕环节）｜依据：「【模态】总经办」2026-08
  • 现象：新机型能否沿用旧证书靠个人判断和找 ODM 口头咨询，无机型—证书对应表（台账环节）｜依据：「【模态】总经办」2026-08
  • 现象：算法备案材料多版往返修改，与产品设计、合同条款对齐靠反复审（材料审核环节）｜依据：「【模态】总经办」2026-09
  • 现象：办学许可的申领主体悬而未决（主体确定环节）｜依据：「【模态】总经办」2026-09
  • 现象：算法备案多份材料在展示形态、算法名称、输入输出模态上互相矛盾，自评估超期、缺显性标识与用户权益截图，被打回（材料一致性环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：打回后临时找外包，失败后改用通用 AI 起草，成功材料未沉淀为模板（模板沉淀环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：备案材料“谁来写、谁来改”临时指派，产品全称等基础信息需在群里临时询问（责任人与基础信息环节）｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 算法备案（鼎慧通、学小助等）：技术负责人起草技术材料，总经办反馈修改并与产品设计、合同条款对齐；备案主体为产品运营主体
  • 办学许可：社会化收费培训需向人社部门申领；公益培训、高校/企业内训一般不需；建议以研究院为申领主体（待确认）
  • 3C：直销且合同有约定的风险相对可控；渠道大批量出货必须持证；同核心同线程新机型是否沿用须 ODM 书面确认
  • 增值电信许可持有情况核对 → 衔接 LEG-24
  • 算法备案场景：首次备案走完整步骤；打回补正从步骤 8 开始，逐条对应审核意见并重做步骤 6 核对；备案变更（主体迁移、算法名称/功能变化）重新走步骤 4～8；鼎慧、Leap 系列分别备案，由各自产品线指定材料负责人；与软著同期准备时产品全称、功能描述共用 POL-03 资料库，软著走 POL-10
  • 已合并原 POL-12（算法备案材料编制与补正）：其材料负责人指定、产品改造截图、一致性核对、打回补正、备案号展示等内容已并入步骤 3～9

10. 待确认问题

  • 资质台账主责是否放在综合部？3C 是否改由 IT 采购主责、综合部仅维护台账？
  • 公司对 3C 的统一口径：直销是否允许无证出货？需法务出书面意见
  • 办学许可申领主体是否确定为研究院？
  • 算法备案内部审核 3 个工作日、材料初稿 5 个工作日是否可行？
  • 是否还有其他专项资质（如网络文化、出版、数据出境评估等）需纳入台账？
  • 敏感合规议题的书面留痕方式（受限权限文档）如何确定？
  • 合并原 POL-12 后，算法备案归口综合部（资质合规）、政策申报还是法务？材料负责人岗位放在研发、产品还是综合部？请管理层裁定
  • 公司当前哪些产品需要算法备案、已备案，是否有清单？历史成功备案材料能否脱敏沉淀为模板？
  • 算法备案平台账号由谁保管（参考 X-SEC-12）？
LEG-26境外主体设立与海外 AI 服务采购合规待新建100

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频1 × 耗4 × 跨5 × 险5

  • 适用场景：国内主体无法直接采购企业版海外 AI 服务，或需要境外账号、IP、支付方式，有人提出设立境外公司或用个人/境外账户、支付渠道付款时，先做合规评估，再决定是否设立境外主体及采用何种付款路径
  • 负责人：主责——COO/联合创始人（当前：常元和·推断待确认）；协同——创始人兼 CTO（当前：丁震宇·推断待确认）、总助（当前：刘昱潇·推断待确认）、财务负责人（当前：待指定）、法务负责人（当前：李瑶·推断待确认）、需求方研发负责人（当前：王皓南、宋祺睿·推断待确认）、架构/风险评估（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 提交需求单 → ② 境内替代方案排查 → ③ 法务+财务合规会签 → ④ CEO 决策 → ⑤ 境外主体设立与开户 → ⑥ 以公司主体开通服务账号 → ⑦ 付款入账 → ⑧ 登记台账并年度维护
  • 交付结果：境外采购合规评估单（结论与条件）；获批时设立的境外主体与银行/支付账户；企业版海外 AI 服务账号；境外主体与账号台账
  • 状态依据：2026-04 讨论以境外公司、个人账户或支付渠道付款，过程中出现 KYC、洗钱、外汇、员工无工作许可被查等风险提示，但法务、财务未参与，“个人行为/公司行为”口径模糊；设立美国公司由个人推进，进度被追问约 3 次，无台账

1. 场景判定

  • 触发条件：需采购仅对境外主体开放的企业版 AI 服务（订阅、API、云）；需要境外稳定 IP、境外手机号或境外支付方式；有人提出以员工个人名义、境外公司或第三方支付渠道代付；已设境外主体的年审、报税、变更、注销
  • 典型说法：「美国公司咋样了」「个人开美国公司在搞吗」「银行 KYC 是大头」「说不定还会被 check」
  • 判断问题：是否要用公司以外的主体（个人、境外公司、代付商）为公司业务付款或持有账号？是否涉及资金出境或新设境外主体？
  • 不归本流程管：已有渠道下的 AI 编程工具订阅开通、充值与防封 → 请走 X-SEC-14；模型 API Key 与内部 NewAPI 额度 → 请走 RND-27；海外出口线路与代理节点 → 请走 X-SEC-26；境内股东会决议与合资协议 → 请走 LEG-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
境外事务负责人 牵头评估、对接注册代理与银行、推进设立 R COO/联合创始人（当前：常元和·推断待确认）
需求发起 提出采购需求与技术必要性 R 创始人兼 CTO（当前：丁震宇·推断待确认）；需求方研发负责人（当前：王皓南、宋祺睿·推断待确认）
注册执行 资料准备、代理沟通、进度更新、台账维护 R 总助（当前：刘昱潇·推断待确认）
财务 外汇、税务、付款路径、入账评估 C 财务负责人（当前：待指定）
法务 KYC、反洗钱、用工许可、数据出境评估 C 法务负责人（当前：李瑶·推断待确认）
风险提示 技术与账户风控经验输入 C 架构/预研负责人（当前：陈晖·推断待确认）
决策 批准主体、路径、预算与法人/董事人选 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 需求说明：服务名称、版本、用途、用户数、预计年费、为何境内无法采购
  • 已尝试的境内路径（国内代理、云市场、已签约渠道）及结果
  • 拟用主体方案：境外公司（法域/州别）、银行或支付渠道、拟任法人/董事
  • 资金路径：境内出资方式、是否涉及 ODI 备案、付款币种
  • 账号管理方案：公司邮箱、管理员、凭据保管位置

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“境外采购/主体需求单” 需求方研发负责人 发现需求后 2 个工作日内 飞书审批 需求单 🔧飞书固化
2 排查境内替代方案并对比成本、合规性 需求方 + 财务 3 个工作日内 飞书文档 替代方案对比 🤖+👤
3 合规会签：主体（个人方案默认否决）、外汇与 ODI、银行 KYC、税务、数据出境、员工境外用工许可 法务 + 财务 收到后 5 个工作日内 飞书审批会签 评估结论与条件 👤人工判断
4 决策：批准/否决，确定主体、预算、法人/董事 CEO 评估后 3 个工作日内 飞书审批 决策记录 👤人工判断
5 委托注册代理设立主体、申请税号、开立银行或支付账户；每周五更新进度 总助执行，境外事务负责人负责 按代理周期，每周更新 飞书任务 注册文件、账户 🔧飞书固化
6 以公司主体和公司邮箱开通服务账号，凭据进入密码管理，不使用个人账号 需求方研发负责人 账户可用后 2 个工作日内 账号台账/密码管理 服务账号 🔧飞书固化
7 付款取得发票或收据，按跨境付款入账 财务 每期账单后 5 个工作日内 财务系统 记账凭证 🔧飞书固化
8 登记境外主体台账：注册地、年审日、报税日、账户、账号、负责人；年审前 60 天提醒 总助 设立后 2 个工作日内 多维表格自动化 台账 🔧+🤖

5. 交付物与模板

  • 交付物：需求单、合规评估会签记录、CEO 决策记录、境外主体注册文件、账户与服务账号清单、境外主体台账
  • 建议模板/表单：
    • 需求单：服务、用途、用户数、年费预估、境内路径尝试结果、紧急程度
    • 合规评估单：主体类型、法域/州别、资金路径、KYC 材料、税务影响、数据出境、用工许可、结论、附加条件、会签人
    • 境外主体台账：主体名称、注册地、注册日期、税号、董事/法人、注册代理、银行/支付账户、年审日、报税日、关联服务账号、负责人

6. 异常与升级

  • 有人已以个人名义付款或注册 → 立即停止新增付款，补提需求单 → 当天升级法务与财务评估是否迁移到公司主体
  • 银行 KYC 被拒或账户被风控 → 境外事务负责人联系代理换渠道 → 2 周无进展升级 CEO 决定是否放弃
  • 境外 IP/账号被封 → 需求方停用并记录 → 1 个工作日内报境外事务负责人评估替代方案
  • 推进停滞（连续 2 周无更新） → 飞书任务自动提醒 → 升级 COO 与 CEO
  • 年审、报税临近未办 → 到期前 30 天升级财务负责人

7. 衡量指标

  • 评估周期 = 需求单提交到 CEO 决策的工作日，目标 ≤ 10 天
  • 个人名义付款数 = 以个人账户为公司业务付款的笔数，目标 0
  • 设立进度准时率 = 按计划节点完成的节点数 / 总节点数，目标 ≥ 80%
  • 境外主体合规事项按期率 = 按期完成的年审、报税次数 / 应办次数，目标 100%

8. 低效诊断

  • 现象：设立境外公司无计划和进度表，相关人员多次询问进度（推进跟踪环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：执行人同时承担其他事务，推进慢且交接断档（执行环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：以个人或境外账户代付的高风险想法直接进入执行讨论，法务、财务未参与（评估入口环节）｜依据：「鸽子群模态分群」2026-04
  • 现象：“个人行为”与“公司行为”口径不清，风险提示靠个别同事经验（主体判定环节）｜依据：「鸽子群模态分群」2026-04
  • 现象：卡在稳定的州 IP、注册州选择等技术细节上，靠个人私下研究（方案设计环节）｜依据：「鸽子群模态分群」2026-04

9. 分支变体

  • 个人行为 vs 公司行为：公司业务付款一律走公司主体；个人自用订阅不属本流程，但不得用于公司数据
  • 银行开户 vs 第三方支付渠道商：渠道商需额外评估反洗钱与资金安全
  • 注册州/法域选择（如怀俄明州等低成本州）：由注册代理建议、法务与财务确认
  • 员工赴境外实际办公：须评估工作许可，否则不得以境外主体名义安排工作

10. 待确认问题

  • 主责是否为 COO？总助是否作为固定执行人？
  • 已在推进的美国公司目前状态如何，是否需补走合规评估？
  • 是否涉及 ODI 备案，由财务还是外部顾问负责？
  • 个人名义采购海外 AI 服务的公司口径（禁止/限额/报销）是什么？
  • 境外主体的年度维护费用归属哪个部门预算？
LEG-27开源与保密规范制定、评审与发布待优化100

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗4 × 跨5 × 险5

  • 适用场景：公司首次出台或修订开源规范、保密规范（资产分级、个人开源项目、远程操作责任等）时，经多部门评审与法务确认后全员发布，并配套落地 SOP 与表单；是 LEG-28～LEG-31 的上位制度
  • 负责人：主责——创始人兼 CTO（规范起草与决策）（当前：丁震宇·推断待确认）；协同——研发评审人（当前：王皓南、宋祺睿、李子遥、陈晖、王子明·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、配套 SOP 搭建人（当前：陈晖·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 立项定范围 → ② 起草初稿 → ③ 法务预审 → ④ 多部门逐条评审 → ⑤ 改稿并关闭意见 → ⑥ 法务终审与 CEO 批准 → ⑦ HR 发布与签收 → ⑧ 配套 SOP 上线与年度复审
  • 交付结果：正式生效的保密规范、开源工作管理规范、速查卡与入口页；评审意见清单（含处理结果）；配套 SOP、表单与审批流；全员签收记录
  • 状态依据：规范已成文并于 2026-05-10 生效，入口页和速查卡齐备；但 2026-04 评审全靠群聊和文档批注，出现条款自相矛盾、报备与豁免写法冲突、署名权表述不严，需多轮改稿；法务在评审尾声才介入，配套 SOP 在规则发布后才开始补

1. 场景判定

  • 触发条件：发生代码/资产外泄或未经审批开源事件；投资人、客户或监管要求公司说明保密与开源管理；业务新增资产类型（如 Skill、提示词、模型）未被现有分级覆盖；现行条款执行中出现明显冲突；年度复审
  • 典型说法：「我今天会出一版公司级的开源规范和保密规范」「审阅一下，没问题就全公司实行」「审批也要有法可依」「对着这个条款建立一下 SOP 文档」
  • 判断问题：要改的是公司级规则本身（条款、分级、罚则），还是按现有规则办一件具体的事？
  • 不归本流程管：引入开源组件的许可证评估 → 请走 LEG-28；员工账号报备与开源申请 → 请走 LEG-29；对外提供材料/代码 → 请走 LEG-30；外泄事件处置 → 请走 LEG-31；人事类制度 → 请走 HR-01；终端安全与锁屏保密 → 请走 X-SEC-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
起草人 立项、起草、统一改稿、回复意见 R 创始人兼 CTO（当前：丁震宇·推断待确认）
研发评审人 逐条评审分级、GPL、报备、豁免等条款 C 研发/基座/信创负责人（当前：王皓南、宋祺睿、李子遥、陈晖、王子明·推断待确认）
法务 预审硬约束、终审出书面意见；存在合法性问题时可要求暂停发布 C 法务负责人（当前：李瑶·推断待确认）
HR 规章程序复核、全员发布、签收、入职纳入 R 人事负责人（当前：黄莹·推断待确认）
配套 SOP 搭建 按条款建 SOP、表单、审批与自动化 R 架构/预研负责人（当前：陈晖·推断待确认）
批准 批准发布 A CEO（当前：邴龙志·推断待确认）
全员 阅读、签收、执行 I 全体员工

3. 办之前请准备

  • 出台/修订原因（事件、外部要求、业务变化）与要解决的问题清单
  • 现行规范版本、执行中暴露的问题与案例（脱敏）
  • 资产分级口径（L1 核心资产 / L2 通用组件 / L3 低风险通用资产）及覆盖的资产类型
  • 评审人名单（研发、IT 安全、HR、法务）与评审截止日
  • 规范存放位置：飞书 wiki 入口页 + Gitea 规则仓库

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：写明原因、范围、上位/下位关系、目标生效日 起草人 触发后 3 个工作日内 飞书文档 立项说明 👤人工判断
2 起草：保密与开源分为两个文件（保密为基础、开源为上层），含分级、个人项目边界、过渡规定、违规后果 起草人 立项后 5 个工作日内 飞书 wiki + Gitea 初稿 🤖自动化（AI 辅助起草）
3 法务预审：知识产权归属、署名权、劳动规章边界等硬约束 法务 初稿后 3 个工作日内 文档批注 预审意见 👤人工判断
4 发起评审：@评审人并附评审清单；意见逐条录入意见表 起草人；评审人 评审期 3 个工作日 文档批注 + 多维表格 意见清单 🔧飞书固化
5 改稿：逐条标注采纳/不采纳及理由；AI 做条款交叉引用和矛盾检查 起草人 评审截止后 3 个工作日内 飞书文档 修订稿、已关闭意见 🤖+👤
6 终审：法务书面确认，CEO 批准 法务、CEO 2 个工作日内 飞书审批 终审记录 🔧飞书固化
7 发布：HR 复核规章程序，全员公告并签收，写明生效日与报备截止日；纳入入职签收 HR 终审后 2 个工作日内 飞书公告 + 签收 发布通知、签收记录 🔧飞书固化
8 配套落地：按条款建 SOP、表单、审批流和提醒；每年或重大事件后复审 配套 SOP 搭建人 发布后 10 个工作日内上线 多维表格 + 审批 SOP 与表单 🔧+👤

5. 交付物与模板

  • 交付物：保密规范、开源工作管理规范、保密红线速查卡、开源怎么走速查卡、入口页；评审意见清单；终审记录；签收记录；配套 SOP
  • 建议模板/表单：
    • 评审意见表：条款号、意见内容、提出人、类型（矛盾/表述/范围/可执行性）、处理（采纳/不采纳/待议）、理由、状态
    • 规范版本记录：版本号、变更条款、生效日、批准人、通知日期

6. 异常与升级

  • 条款间冲突或报备与豁免口径冲突 → 起草人在 2 个工作日内给出统一写法 → 评审人仍有异议升级 CEO
  • 法务认为存在合法性问题 → 暂停发布并改稿 → 改稿超过 5 个工作日升级 CEO
  • 发布后签收率低 → HR 每周提醒未签收人员 → 2 周后仍未签收报部门负责人
  • 规则发布但配套 SOP 未上线 → 起草人指定临时处理口径 → 超 10 个工作日升级 CEO

7. 衡量指标

  • 规范制定周期 = 立项到正式发布的自然日，目标 ≤ 20 天
  • 意见关闭率 = 已处理意见数 / 意见总数，发布前目标 100%
  • 法务前置率 = 法务在评审前完成预审的规范数 / 规范总数，目标 100%
  • 全员签收率 = 已签收人数 / 在职人数，生效日后 2 周目标 100%
  • 配套到位时差 = 规范生效到配套 SOP/表单上线的工作日，目标 ≤ 10 天

8. 低效诊断

  • 现象：评审意见散在群聊和批注中，作者统一改稿需多轮复审（意见收集环节）｜依据：「开源&保密规范评审」2026-04
  • 现象：条款间自相矛盾、报备与豁免写法冲突，发布前反复修改（起草环节缺一致性检查）｜依据：「开源&保密规范评审」2026-04
  • 现象：法务在评审尾声才介入，署名权等表述需返工（法务介入环节偏后）｜依据：「开源&保密规范评审」2026-04
  • 现象：规则先发，配套 SOP 和表单随后才补，需群内催办进度（配套落地环节）｜依据：「开源&保密规范评审」2026-04

9. 分支变体

  • 保密规范为基础，开源规范为上层；资产默认按 L1 管理，经分级后放开
  • 远程操作公司系统需有监护人
  • 过渡规定：入职前的个人贡献与此前公开仓库贡献不追溯；入职后的个人仓库需报备；老员工报备截止 2026-05-30，新员工入职一个月内；不报备不享受开源积分与现金奖励，泄露公司资产追责
  • 修订而非新建时：只评审变更条款，评审期可缩短为 2 个工作日

10. 待确认问题

  • 规范的主责是否固定为 CTO，还是转由法务或综合部维护？
  • 是否需要按劳动规章程序进行民主程序与公示？由 HR 确认
  • 年度复审时间点定在何时？
  • 非技术人员产出的 Skill、提示词、文档是否已纳入分级覆盖？
  • 外部投资人要求的说明材料由谁出具？
LEG-28开源组件引入与许可证合规评估待优化135

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨3 × 险5

  • 适用场景：在产品、Agent 容器或交付物中引入/集成/二开第三方开源组件，复制开源 UI 代码，把员工业余开源项目引入公司项目，或二开后改名换 Logo 对外分发时，先评估许可证义务并确定使用条件
  • 负责人：主责——研发技术负责人（当前：王皓南·推断待确认）；协同——引入方研发（申请人）、许可证初审人（当前：岳阳、柯逸飞·推断待确认）、开源负责人（当前：常元和·推断待确认）、法务负责人（当前：李瑶·推断待确认）、品牌负责人（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交开源组件引入申请 → ② CI 自动扫描许可证 → ③ 技术初审（使用方式与隔离） → ④ 法务判定 → ⑤ 定使用条件（署名、命名、隔离、开源义务） → ⑥ 登记台账并 fork 备份 → ⑦ 发版前复核第三方声明
  • 交付结果：开源组件引入审批记录；开源组件台账；每个组件的使用条件（版权声明、about 页署名、对外命名、是否需公开源码）；发版包内的第三方声明文件
  • 状态依据：已有飞书“开源审批”流程和 wiki 说明，但 2026-01～07 多个群中研发不清楚入口，靠资深同事凭经验提示 GPL/AGPL 风险，法务未参与；二开改名、版权信息、对外命名往往到交付前才讨论

1. 场景判定

  • 触发条件：新增依赖（尤其 GPL/LGPL/AGPL/SSPL 或非商用协议）；复制第三方 UI 或代码片段；Fork 二开开源产品；对外分发含开源组件的安装包、镜像或私有化交付；二开后改名、去除或替换 Logo；员工个人仓库代码进入公司仓库；基于开源组件对外提供网盘/存储服务
  • 典型说法：「这个依赖算是专有软件了，系统包管理装不上我建议别装」「Cloudreve 是 GPL3.0，直接做二开需要开源」「删了你就要遵从 AGPL」「不能删掉 NewAPI 这个软件名字」「对外别叫 KIMI，统一改成 LEAP」「做好隔离，不然 GPL v3 会很麻烦」
  • 判断问题：这段代码不是公司员工在职期间写的吗？它会随产品分发、对外提供网络服务，或改名后对外展示吗？
  • 不归本流程管：把公司自有代码对外开源或向上游贡献 → 请走 LEG-29；产品上线整体合规（数据、内容监管） → 请走 LEG-19；用户协议/EULA → 请走 LEG-18；产品商标注册 → 请走 LEG-16；规范条款本身修订 → 请走 LEG-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填写引入申请、登记台账、按条件实施 R 引入方研发（当前：按项目）
许可证初审人 判断使用方式、隔离方案、是否需法务 R 资深研发（当前：岳阳、柯逸飞·推断待确认）
决策人 综合技术与法务意见拍板使用条件 A 研发技术负责人（当前：王皓南·推断待确认）
法务 copyleft、商用限制、对外分发、归属判定 C 法务负责人（当前：李瑶·推断待确认）
开源负责人 对外开源节奏、署名口径、与上游关系 C 开源负责人（当前：常元和·推断待确认）
品牌 对外产品名、Logo 使用 C 品牌负责人（当前：待指定）
兜底 争议拍板、规则维护 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
发版负责人 发版前生成第三方声明（NOTICE），核对版权信息与 about 页 R 各产品线发版负责人（当前：按项目）

3. 办之前请准备

  • 组件名称、版本、仓库地址、许可证原文链接
  • 使用方式：运行时调用 / 静态或动态链接 / 同进程 / 容器内分发 / 复制代码 / Fork 二开
  • 是否对外分发、是否对外提供网络服务、是否改名或替换 Logo
  • 改动范围与是否计划回馈上游
  • 员工业余项目：创建时间、是否在职期间用公司设备或工作时间开发
  • 是否涉及央国企数据或对外存储服务

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交飞书“开源审批”引入申请，按准备清单填写 申请人 代码合入前；新增依赖的 PR 提交当天 飞书审批 申请单 🔧飞书固化
2 CI 扫描依赖树许可证，标记 copyleft、非商用和未知协议，结果回写申请单 CI（研发技术负责人维护规则） PR 提交即时 CI 许可证扫描 扫描报告 🤖自动化
3 技术初审：宽松协议（MIT/Apache/BSD）且不涉及改名的直接通过；copyleft 评估隔离方案（独立进程、API 封装、由用户运行时自行安装） 许可证初审人 1 个工作日内 飞书审批 初审意见 👤人工判断
4 法务判定：GPL/AGPL/商用限制、对外分发、改名去标、业余项目归属 法务 3 个工作日内 飞书审批会签 法务结论 👤人工判断
5 定使用条件：保留版权声明、about 页与“Powered by”、保留原软件名、开源部分与闭源服务拆分；对外名称由品牌确认 研发技术负责人；品牌 法务结论后 1 个工作日内 飞书审批 使用条件 👤人工判断
6 登记组件台账；关键依赖 fork 稳定版到公司 Gitea 备份 申请人 批准后 2 个工作日内 多维表格 + Gitea 台账记录、fork 仓库 🤖+👤
7 发版前生成第三方声明（NOTICE），核对版权信息与 about 页 发版负责人 发版前 1 个工作日 CI + 发版清单 第三方声明 🤖+👤

5. 交付物与模板

  • 交付物：引入审批记录、法务结论、组件台账、使用条件、第三方声明文件
  • 建议模板/表单：
    • 开源组件台账：组件、版本、许可证、来源仓库、使用方式、是否改动、是否对外分发、是否对外服务、署名要求、对外名称、法务结论、批准人、使用项目、fork 地址、复核日期
    • 引入申请单：同准备清单字段 + 申请人、所属项目、计划合入日期

6. 异常与升级

  • 已合入或已交付后才发现 copyleft 组件 → 当天冻结对外分发，研发技术负责人评估替换或隔离 → 1 个工作日内升级 CTO 与法务
  • 法务与技术意见不一 → 研发技术负责人组织 30 分钟对齐会 → 仍无结论 2 个工作日内升级 CTO
  • 对外交付临近但命名/署名未定 → 默认保留原组件名与版权声明发版 → 同步品牌负责人后续调整
  • 业余项目归属存疑 → 暂不引入，fork 留存 → 法务 3 个工作日内出归属意见
  • 升级拍板：使用条件由研发技术负责人作为 A 拍板；出现以下任一情形时由创始人兼 CTO 作为 A（升级）裁定——法务与技术意见对齐会后仍无结论、已合入或已交付后才发现 copyleft 组件、需要调整引入规则

7. 衡量指标

  • 审批覆盖率 = 走过引入审批的新增第三方依赖 / 扫描发现的新增依赖，目标 ≥ 95%
  • 审批周期 = 提交到使用条件确定的工作日，宽松协议目标 ≤ 1 天，copyleft 目标 ≤ 5 天
  • 事后发现数 = 发版后才发现许可证问题的组件数，目标 0
  • 第三方声明齐全率 = 附带完整 NOTICE 的对外发版次数 / 对外发版次数，目标 100%

8. 低效诊断

  • 现象：研发不知道“开源审批”入口，靠翻 wiki 才找到，决策归属模糊（申请入口环节）｜依据：「Leap产研测」2026-07
  • 现象：GPL/AGPL 风险靠资深同事凭经验提示，结论在群里当场拍板，无法务参与（判定环节）｜依据：「Leap产研测」2026-07
  • 现象：GPL 隔离、网盘服务的数据监管责任由技术同事随口提醒，无人确认、以管理层口头兜底代替法务意见（法务审查环节缺位）｜依据：「⭐大模型基座事业群」2026-01
  • 现象：开源组件二开后到对外交付前才说明对外命名（命名与署名环节滞后）｜依据：「某水利企业公司研发」2026-07

9. 分支变体

  • Agent 容器/产品集成依赖：copyleft 组件不直接内置，由 Skill 运行前检查并引导用户自行安装，或在对应 Skill 中提供安装脚本
  • 复制第三方 UI（如 Cloudreve 前端）：GPL3 代码视同二开，须评估开源义务
  • 二开换 Logo 对外分发：GPL3 组件二开需开源，或拆分开源部分与自有闭源服务；AGPL 组件不得删除原软件名；可采用“核心区自有 Logo + 角落 Powered by + about 页挂原项目”；商业 Pro 版不得二次分发
  • MIT 等宽松协议组件：可用，对外按品牌统一命名（如对外统一称 LEAP），保留许可声明
  • 员工业余开源项目引入：确认入职前后与是否使用公司资源，fork 稳定版到公司 Gitea；报价中是否注明开源由商务口径决定
  • 基于开源组件对外提供网盘/存储服务、涉及央国企数据：叠加数据脱敏与监管责任评估 → 衔接 LEG-19

10. 待确认问题

  • 主责是否为研发技术负责人？跃竞、鼎慧线是否各设初审人？
  • 现有飞书“开源审批”是否覆盖“引入”场景，还是仅覆盖“对外开源”？是否需要新建独立审批？
  • CI 许可证扫描由谁负责接入，覆盖哪些仓库？
  • 法务 3 个工作日的判定时限是否可行？是否需要外部律所支持？
  • 对外命名与 Logo 使用由品牌还是产品负责人决定？
LEG-29员工开源账号备案与对外开源发布审批待优化144

状态：待优化｜证据：有证据（卡片 9 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：员工入职报备个人开源账号；员工或团队拟把公司代码、Skill、模板、模型对外开源、向上游贡献，或在 GitHub/HuggingFace 发布；公司孵化开源项目立项时，完成备案、分级审批、署名与发布
  • 负责人：主责——开源事务管理员（当前：陈晖·推断待确认）；协同——申请人（项目主要维护者）、分级复核人（非申请人的研发同事）、技术负责人/审批人（当前：丁震宇·推断待确认）、研发技术负责人（当前：王皓南、宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、开源负责人/公司开源组织管理员（当前：常元和·推断待确认）、产品负责人（当前：杨萌·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 开源账号报备 → ② 提交开源申请表单 → ③ 分级复核 → ④ 按级别审批 → ⑤ 发布前检查（敏感信息、许可证、署名） → ⑥ 在公司组织下发布 → ⑦ 登记台账与激励 → ⑧ 立项后按月跟进
  • 交付结果：开源账号报备表；开源申请审批记录；公司 GitHub/HuggingFace 组织下的公开仓库（含许可证、署名、维护者）；开源项目台账
  • 状态依据：2026-05 起已有《开源项目申请 SOP》、申请表单、账号收集表和多维表格自动流转；但此前出现员工未经审批公开公司代码与 Skill、模板先开到个人 GitHub 后才被提醒；规则发布后孵化项目立项后进度无人跟进，执行率待观察

1. 场景判定

  • 触发条件：新员工入职（一个月内报备）；员工新建与工作相关的公开仓库；拟把公司项目、模板、Skill、模型、数据集公开；向外部开源项目提交 bugfix 或功能；公司决定孵化开源项目；抓取第三方平台内容上架到自有商城
  • 典型说法：「对外开源贡献规范有啥想法没」「要开源出去得让公司知情，或者公司直接下命令开源」「公司项目开源得是老板们同意」「合规的话还要签 CCLA」「开源备案目前需要处理的」「入职之后的个人仓库需要报备」
  • 判断问题：要公开的东西是否在职期间产生、用了公司资源，或属于公司业务资产（含非技术人员做的 Skill）？
  • 不归本流程管：引入第三方开源组件 → 请走 LEG-28；规范条款修订 → 请走 LEG-27；已发生的未经审批公开、外泄事件 → 请走 LEG-31；向外部合作方提供代码权限 → 请走 LEG-30；专利、论文类产出 → 请走 POL-11（专利申请与代理对接）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 报备账号、提交开源申请、发布前自检、发布后维护 R 项目主要维护者
分级复核人 确认项目分级（L1/L2/L3） R 非申请人的研发同事
审批人 L2 决定通过或组织评审；L3 指定复核责任人 A 技术负责人（当前：丁震宇·推断待确认）
业务线技术把关 判断是否含业务核心代码、客户相关内容 C 研发技术负责人（当前：王皓南、宋祺睿·推断待确认）
法务 许可证选择、CCLA、署名权、第三方内容侵权 C 法务负责人（当前：李瑶·推断待确认）
开源事务管理员 维护表单、审批流、自动化、台账、提醒 R 架构/预研负责人（当前：陈晖·推断待确认）
HR 入职推送报备、签收、积分激励配合 R 人事负责人（当前：黄莹·推断待确认）
公司开源组织管理员 管理 GitHub/HuggingFace 公司组织与成员 R 开源负责人（当前：常元和·推断待确认）
产品负责人 涉及产品功能、Skill 商城上架内容把关 C 产品负责人（当前：杨萌·推断待确认）

3. 办之前请准备

  • 个人开源平台账号（GitHub、HuggingFace、Gitee 等），没有也需填写“无”
  • 拟开源项目名、内部仓库地址、对外项目名、拟用许可证、开源后维护者（一主一副）
  • 项目分级自评与理由；是否包含第三方组件（已走 LEG-28）
  • 向上游贡献：目标项目、贡献内容、是否需签 CCLA
  • 发布前自检结果：密钥、内部地址、客户数据、内部文档链接已清除

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在开源平台账号收集表报备账号（无账号也填写）；入职流程自动推送，未报备定期提醒 员工；HR 推送 入职后 1 个月内 多维表格 + 入职流程 报备记录 🔧+🤖
2 按《开源项目申请 SOP》提交申请表单，注明类型（自有开源/向上游贡献/模板/Skill/模型） 申请人 计划公开日前至少 10 个工作日 飞书表单 申请单 🔧飞书固化
3 分级复核：确认 L1 核心资产 / L2 通用组件 / L3 低风险通用资产 分级复核人 收到后 2 个工作日内 飞书审批 分级结论 👤人工判断
4 审批：L3 指定复核责任人，分级后 10 天无操作视为默示批准；L2 由技术负责人决定或开评审会并记录；L1 原则上不开源；涉及 CCLA、署名或许可证选择争议时法务会签 技术负责人；法务 L2 在分级后 5 个工作日内 飞书审批自动流转 审批结论 🔧+👤
5 发布前检查：扫描密钥与敏感配置，补许可证文件、NOTICE、Powered by 署名 申请人；扫描脚本 发布前 1 个工作日 扫描脚本 + 检查清单 检查记录 🤖自动化
6 在公司 GitHub/HuggingFace 组织下发布（个人账号不作主仓）；向上游贡献在台账留痕 申请人；公司开源组织管理员 批准后按计划 GitHub/HuggingFace 公开仓库/PR 链接 🔧飞书固化
7 登记开源项目台账，关联开源积分与激励 开源事务管理员 发布后 2 个工作日内 多维表格自动化 台账记录 🔧+🤖
8 孵化项目每月更新进度，每季度复盘继续维护或归档 项目维护者；管理员提醒 每月最后一周 飞书任务 进度记录 🔧飞书固化

5. 交付物与模板

  • 交付物：账号报备表、开源申请与审批记录、评审会记录（L2）、发布前检查记录、开源项目台账
  • 建议模板/表单：
    • 账号报备：姓名、部门、平台、账号名、主页链接、入职日期、报备日期、是否有入职后个人仓库
    • 开源申请：项目名、分级、分级复核人、内部仓库地址、对外项目名、许可证、维护者（主/副）、开源类型、计划公开日、是否含第三方组件
    • 开源项目台账：项目、对外地址、分级、许可证、维护者、发布日期、最近更新、积分记录、状态（维护/归档）

6. 异常与升级

  • 发现未经审批已公开 → 转 LEG-31 先止损，再补走本流程
  • 工作流触发顺序错乱、审批卡住 → 开源事务管理员当日人工处理 → 2 个工作日内修复，不能修复报技术负责人
  • L3 默示批准后发现分级有误 → 审批人可在发布前撤回 → 已发布的转 LEG-31 评估
  • 对上班时间写个人项目、豁免条件有争议 → 申请人提交说明 → 技术负责人与 HR 在 5 个工作日内裁定
  • 孵化项目连续 2 个月无进度 → 管理员提醒 → 第 3 个月提交技术负责人决定是否归档

7. 衡量指标

  • 账号报备率 = 已报备人数 / 应报备人数，报备截止日后目标 100%
  • 先审后发率 = 先审批后公开的项目数 / 新公开项目数，目标 100%
  • 审批周期 = 申请提交到审批结论的自然日，L2 目标 ≤ 7 天
  • 发布前扫描通过率 = 首次扫描即无敏感信息的项目 / 提交扫描项目，目标 ≥ 90%
  • 孵化项目月度更新率 = 当月有进度更新的孵化项目 / 在孵项目数，目标 100%

8. 低效诊断

  • 现象：对外开源贡献无规范，只给出口头署名建议（规则缺位环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：项目模板先开到个人 GitHub，事后才被提醒需审批、选协议、签 CCLA（申请入口环节）｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：抓取第三方平台 Skill 上架是否侵权，靠口头判断代替法务意见（第三方内容评估环节）｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：公司资助的代码与 Skill 被公开后才补协议、补通知，资产分级对非技术人员产出覆盖不到（分级与审批环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：待备案项靠人工汇总，谁上报、谁审核不清（备案环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：飞书工作流触发顺序不固定、无锁机制，搭建时反复踩坑；规则先发、SOP 后补（工具落地环节）｜依据：「开源&保密规范评审」2026-04
  • 现象：上班时间写个人项目的边界在群里反复辩论（口径环节）｜依据：「开源&保密规范评审」2026-04
  • 现象：孵化项目技术选型靠群聊长篇争论，立项后进度无人跟进（立项后管理环节）｜依据：「模态跃迁开源项目孵化群」2026-09、「模态跃迁开源项目孵化群」2026-10

9. 分支变体

  • 员工个人项目：入职前的个人贡献不管；入职后的个人仓库须报备；上班时间用于个人项目的工时边界（如不超过 10%）需人工判断；带公司 title 的公开项目可申请豁免
  • 公司资助的 Skill、模板：属业务资产，非技术人员同样适用本流程
  • 向上游提交代码：须备案，必要时由法务签 CCLA，可带“Powered by”署名
  • 模型/数据集发布：统一使用公司 HuggingFace 组织（ModaLeap）
  • 公司孵化开源项目：自用版与开源版分仓（如 LeapHaven / haven），公司项目私有仓库先设 Private
  • 抓取第三方平台 Skill 上架自有商城：评估来源协议、致谢与侵权风险 → 衔接 LEG-19

10. 待确认问题

  • 开源事务管理员是否固定为现任 SOP 搭建人？是否需要备岗？
  • L1 资产是否绝对禁止开源，还是 CEO+CTO+法务 特批？
  • 上班时间个人项目工时边界、带公司 title 豁免的具体条件是什么？
  • 入职流程是否已加入账号报备推送与 HR 说明？
  • 开源积分与现金奖励的发放口径由谁维护（衔接 HR-18）？
  • 申请提前 10 个工作日是否可行？
LEG-30对外提供材料与代码权限的保密审查待新建100

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗2 × 跨5 × 险5

  • 适用场景：需要把含真实客户信息的材料（可研报告、方案、数据样例）发给外部人员，对外披露渠道/供应商/灰度产品信息，或合作方索取代码库/源码时，先做保密审查，决定脱敏、签 NDA、限定授权方式或拒绝
  • 负责人：主责——法务负责人（当前：李瑶·推断待确认）；协同——发起人所在产品/研发负责人（当前：杨萌、王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 发起外发申请 → ② 密级与敏感信息判定 → ③ 选择提供方式 → ④ 签署 NDA → ⑤ 审批 → ⑥ 受控交付 → ⑦ 登记并到期回收
  • 交付结果：对外资料/源码授权审批记录；已签 NDA；脱敏材料或限时只读代码权限；外发台账
  • 状态依据：2026-02～03 曾讨论材料是否涉密、是否先签 NDA，最终未签 NDA 直接外发真实客户项目材料；合作方索要代码时需另行确认是否为管理层授意；无审批入口、无脱敏样例库、无 NDA 标准动作

1. 场景判定

  • 触发条件：向外部专家、合作方、候选供应商、媒体发送含客户名称、项目数据、合同或内部方案的材料；对外说明合作云厂商、渠道或供应商信息（尤其灰度/未公开产品）；合作方或客户要求访问代码库、获取源码或技术文档
  • 典型说法：「这个是真实项目，会不会有涉密问题」「用 AI 生成一个保密协议给他」「尽量低调」「别给人用户数据漏了就行」
  • 判断问题：发出去的内容里是否有客户信息、用户数据、源码或未公开的合作信息？对方是否已签 NDA？
  • 不归本流程管：NDA/合作协议本身的拟定 → 请走 LEG-05；外部协作方访问内网与联调环境 → 请走 X-SEC-06；客户索要设备 root/远程接入 → 请走 X-SEC-07；敏感数据导出与 AI 分析 → 请走 X-SEC-35；把代码公开开源 → 请走 LEG-29；提供营业执照等证照 → 请走 LEG-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 提交申请、准备脱敏材料、受控发送 R 对接人（按业务）
初判 判定材料密级与是否必要外发 R 产品/研发负责人（当前：杨萌、王皓南·推断待确认）
保密审查 复核密级、提供 NDA、出审查结论 R/A 法务负责人（当前：李瑶·推断待确认）
技术资料授权 源码、架构文档外发的必要性与范围 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
仓库管理员 开只读账号、设到期、回收 R 代码仓库管理员（当前：待指定）
合作授意确认 确认对外合作是否已获授意；业务坚持外发原件等争议裁定 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 接收方单位、联系人、用途、是否已签 NDA
  • 材料清单或仓库/目录范围，是否含客户名称、项目数据、用户数据、合同、报价
  • 可替代方案：演示视频、截图、脱敏样例
  • 提供期限与回收方式
  • 对外合作的授意来源（书面）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“对外资料/源码授权”申请 发起人 外发前至少 1 个工作日 飞书审批 申请单 🔧飞书固化
2 判定密级：客户涉密项目、用户数据默认不外发；按保密规范分级 初判（产品/研发负责人），保密审查（法务）复核 半个工作日内 飞书审批 密级结论 👤人工判断
3 选择提供方式：优先演示视频/截图/脱敏样例；确需原件或源码则限定最小范围 发起人；源码由 CTO 确认 判定后半个工作日内 脱敏样例库 提供方案 🤖+👤（AI 辅助脱敏）
4 签 NDA：使用法务标准模板，不临时自拟 法务 1 个工作日内 电子签 已签 NDA 🔧飞书固化
5 审批：客户材料由法务批；源码由 CTO+法务批，涉及合作授意须 CEO 书面确认 保密审查（法务）；源码加技术资料授权（CTO）；合作授意确认（CEO） 1 个工作日内 飞书审批 审批结论 🔧飞书固化
6 受控交付：文档加水印、链接设有效期、禁止下载；代码开指定仓库只读账号，不打包发送整库 发起人；仓库管理员 审批通过后 1 个工作日内 飞书云文档 / Gitea 交付记录 🔧飞书固化
7 登记外发台账，到期自动提醒回收权限或要求删除 仓库管理员；发起人 到期当日 多维表格自动化 回收记录 🤖自动化

5. 交付物与模板

  • 交付物：审批记录、NDA、脱敏材料或权限开通记录、外发台账、回收记录
  • 建议模板/表单：
    • 外发申请：接收方、用途、材料/仓库范围、密级、是否含客户/用户数据、提供方式、NDA 编号、期限、授意来源
    • 外发台账：编号、日期、接收方、内容摘要、密级、方式、审批人、到期日、回收状态
    • 脱敏样例库：按产品线的演示材料、虚构客户的可研样例、演示视频

6. 异常与升级

  • 已未经审批外发 → 发起人当天报法务，要求对方删除并补签 NDA → 涉及客户涉密项目或源码转 LEG-31，当天升级 CEO
  • 对方拒签 NDA → 只能提供公开或脱敏材料 → 业务坚持需原件时 1 个工作日内升级 CEO
  • 合作授意来源不清 → 暂停交付，向 CEO 书面确认 → 1 个工作日无回复则不提供
  • 云厂商灰度/未公开产品信息被询问 → 统一回复“以公开信息为准” → 对外宣传前报 CTO 确认
  • 升级拍板：外发审查结论由法务作为 A 出具；源码、架构文档外发时由 CTO 作为 A（升级）确认必要性与范围；涉及合作授意、对方拒签 NDA 而业务坚持外发原件、已未经审批外发涉及客户涉密项目或源码时，由 CEO 作为 A（升级）裁定

7. 衡量指标

  • 先审后发率 = 经审批外发次数 / 外发总次数，目标 100%
  • NDA 覆盖率 = 含 L2 及以上材料的外发中已签 NDA 的次数 / 该类外发次数，目标 100%
  • 审批周期 = 申请到可交付的工作日，目标 ≤ 2 天
  • 到期回收率 = 按期回收的权限/材料数 / 到期数，目标 100%

8. 低效诊断

  • 现象：是否涉密、是否先签 NDA 在群里讨论后以“直接发”收尾（审批与 NDA 环节缺位）｜依据：「鼎慧产研决策部」2026-02
  • 现象：谁有权批准对外发资料不清，真实项目与脱敏样例口径不一（判定环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：未公开合作产品信息、用户数据外泄靠个人职业道德与口头提醒约束（规则环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：曾设想用 AI 临时生成保密协议，无法务标准模板可直接用（NDA 模板环节）｜依据：「鼎慧产研决策部」2026-02

9. 分支变体

  • 客户项目材料（可研报告等）：默认用脱敏样例；必须原件时需客户同意并签 NDA
  • 云厂商灰度产品、渠道/供应商信息：不对外宣传，确需披露的报 CTO
  • 数据库用户数据：禁止外发
  • 合作方要源码：先问清用途，优先提供演示视频/图片；确需源码时开指定仓库只读权限并限期，不打包整库发送

10. 待确认问题

  • 主责放在法务是否可行？法务带宽不足时初判是否由业务线负责人兜？
  • 是否已有法务标准 NDA 模板（衔接 LEG-05）？
  • 源码外发的审批人是否为 CEO+CTO+法务 三方？
  • 外发材料水印与有效期设置是否用飞书云文档能力即可？
  • 脱敏样例库由哪个部门建立与维护？
LEG-31代码与机密资产外泄管控及事件处置待新建160

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：获得或形成高价值代码、Skill、提示词等机密资产需要控制流转范围，或发现员工把公司代码/资产放到个人公开仓库、外部平台时，执行登记管控与泄露事件处置
  • 负责人：主责——创始人兼 CTO（机密资产管控负责人）（当前：丁震宇·推断待确认）；协同——资产所属业务线技术负责人（当前：王皓南·推断待确认）、资产登记员（当前：王满·推断待确认）、清洗改写研发（当前：陈锦杰·推断待确认）、产品负责人（当前：杨萌·推断待确认）、法务负责人（当前：李瑶·推断待确认）、人事负责人（当前：黄莹·推断待确认）、代码仓库管理员（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 资产定级登记 → ② 权限化分发与拷贝登记 → ③ 清洗确认后方可扩散 → ④ 定期扫描公开仓库 → ⑤ 发现泄露立即止损 → ⑥ 取证与影响评估 → ⑦ 按规范定性处理 → ⑧ 复盘整改
  • 交付结果：机密资产登记表（含拷贝持有人）；泄露事件处置记录（止损、证据、影响、处理结论）；整改项清单
  • 状态依据：2026-04 出现员工公开公司代码的事件，当时规范尚在法务审核，处理无依据，只能先止损再补规范，且同类问题“说了不止一次”；2026-10 高价值 Skill 先分发、后宣布登记，登记表尚未建立、名单由谁维护不清

1. 场景判定

  • 触发条件：取得或开发出高价值代码、Skill、提示词、数据（如已在生产产生真实流水的业务代码）；L1/L2 资产需要分发给更多人或改造成插件；扫描或举报发现公司代码、Skill 出现在个人公开仓库或外部平台；员工离职前后发现异常拷贝
  • 典型说法：「每个有 copy 的人必须登记」「得控制下这份 skill 的流出」「用公司的资产做的东西就不能发，除非审批通过」「洗了开源也要申请的」「这个事说了不止一次了吧」
  • 判断问题：这份资产泄露后是否会损害公司竞争力或客户利益？它现在在谁手里、能否追踪？
  • 不归本流程管：账号密钥泄露与轮换 → 请走 X-SEC-11；Gitea 账号与仓库权限开通 → 请走 X-SEC-02；离职账号回收 → 请走 X-SEC-08；员工违规的人事处置流程 → 请走 HR-20；外部方抄袭我方 → 请走 LEG-17；正常申请开源 → 请走 LEG-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
管控负责人 定规则、事件总指挥、定性 A 创始人兼 CTO（当前：丁震宇·推断待确认）
资产 owner 定级、批准分发、评估泄露影响 R 业务线技术负责人（当前：王皓南·推断待确认）
登记员 维护机密资产与拷贝持有人名单、发保密提示 R 业务专家（当前：王满·推断待确认）
清洗执行 扩散前清洗改写，AI 比对无原版痕迹 R 研发（当前：陈锦杰·推断待确认）
风险排查 排查产品与交付侧暴露面 R 产品负责人（当前：杨萌·推断待确认）
法务 定性、对外发函、证据保全 C 法务负责人（当前：李瑶·推断待确认）
HR 按规范进行员工处置 R 人事负责人（当前：黄莹·推断待确认）
仓库管理员 权限收紧、公开仓库扫描、审计日志 R 代码仓库管理员（当前：待指定）
兜底 重大事件决策与对外口径 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 资产清单：名称、类型（源码/Skill/提示词/数据）、价值说明、所在仓库或文档
  • 当前持有拷贝人员名单与获取方式
  • 保密规范与资产分级条款（衔接 LEG-27）
  • 事件处置时：泄露地址、发现时间、截图与 web archive 存档、涉事账号
  • 员工账号报备表（LEG-29）用于扫描比对

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 资产定级并登记，L1/L2 标注可接触人员范围 资产 owner 资产形成或取得后 2 个工作日内 多维表格 机密资产登记 🔧+👤
2 只通过仓库/文档权限分发，不发压缩包；每个拷贝持有人登记并确认保密提示 登记员 每次分发前 多维表格 + Gitea/飞书权限 拷贝持有人名单 🔧飞书固化
3 扩大范围或对外前完全清洗改写，AI 比对确认无原版痕迹，资产 owner 确认后发布 清洗执行 + 资产 owner 按计划，发布前 2 个工作日完成确认 AI 比对 清洗确认记录 🤖+👤
4 每周扫描员工报备账号与公司关键词的公开仓库 仓库管理员 每周一 扫描脚本 扫描报告 🤖自动化
5 发现泄露：通知当事人设为 private 或删除，保留截图和存档证据，轮换涉及密钥 管控负责人指定处置人；当事人 发现后 2 小时内 Gitea / 外部平台 止损记录 👤人工判断
6 影响评估：内容、级别、暴露时长、是否被 fork/下载、客户影响 资产 owner + 法务；产品负责人排查交付侧 1 个工作日内 飞书文档 影响评估 🤖+👤
7 按保密规范条款定性；员工处置走 HR 流程；涉及外部方由法务发函 管控负责人、法务、HR 评估后 3 个工作日内 飞书审批 处理结论 👤人工判断
8 复盘：收紧权限（如组织创建权限）、补规则、全员提醒 管控负责人 结案后 5 个工作日内 飞书文档 + 公告 整改项 🔧飞书固化

5. 交付物与模板

  • 交付物：机密资产登记表、拷贝持有人名单、清洗确认记录、公开仓库扫描报告、事件处置记录、复盘整改清单
  • 建议模板/表单：
    • 机密资产登记：资产名、类型、级别（L1/L2/L3）、owner、存放位置、可接触范围、登记日期、复核日期
    • 拷贝持有人：资产、持有人、获取日期、获取方式、用途、保密提示确认、回收日期
    • 事件处置记录：发现时间、发现方式、泄露位置、资产及级别、止损时间、证据链接、影响评估、定性条款、处理结论、整改项

6. 异常与升级

  • 当事人 2 小时内未配合下架 → 仓库管理员停用其公司仓库权限 → 当天升级 CEO，法务评估平台投诉下架
  • 资产已被外部 fork 或下载 → 法务 1 个工作日内评估发函/平台投诉 → 涉客户信息时当天通知客户对接人并报 CEO
  • 归属有争议（个人项目先于公司项目开发、与公司无关的个人仓库） → 暂按私有处理 → 法务 3 个工作日内出归属意见
  • 事件发生时规范未覆盖 → 先止损、对当事人说明将按统一规范处理 → 规范发布后补定性，不临时加重处罚
  • 升级拍板：资产管控规则与事件定性由创始人兼 CTO 作为 A 决定；出现以下任一情形时由 CEO 作为 A（升级）决策——当事人 2 小时内未配合下架、资产已被外部 fork 或下载且涉及客户信息、需要对外发声或发函

7. 衡量指标

  • 止损时效 = 发现到下架/私有化的小时数，目标 ≤ 2 小时
  • 登记覆盖率 = 已登记的 L1/L2 资产 / 识别出的 L1/L2 资产，目标 100%
  • 拷贝可追溯率 = 有登记的拷贝持有人 / 实际持有人，目标 100%
  • 重复事件数 = 同类外泄事件次数，目标每季度 0
  • 扫描执行率 = 实际执行扫描周数 / 应执行周数，目标 100%

8. 低效诊断

  • 现象：发现员工公开公司代码时规范尚在审核，处理缺乏依据，只能先止损再补规则（规则前置环节）｜依据：「leapagent赛马」2026-04
  • 现象：同类公开仓库问题多次口头提醒仍重复发生，开源审批人未成文（预防环节）｜依据：「leapagent赛马」2026-04
  • 现象：个人项目与公司项目的归属边界无判定规则，需逐案讨论（定性环节）｜依据：「leapagent赛马」2026-04
  • 现象：高价值 Skill 先分发后补登记，“开个表登记”尚未落地，名单由谁维护不清（分发环节）｜依据：「工程咨询产研」2026-10

9. 分支变体

  • Skill 包 vs 源码/提示词压缩包：Skill 通过平台权限下发；压缩包禁止私下传，必须登记
  • 招投标等高价值业务资产：清洗改写并经 AI 比对后才可在更大范围使用
  • 员工个人 GitHub 放公司相关代码：一律先 private，再按 LEG-29 申请；“洗过”的代码开源仍需申请
  • 个人项目先于公司项目开发：按创建时间与是否使用公司资源认定，法务出意见
  • 与公司无关的个人仓库：仅需报备，不视为公司资产

10. 待确认问题

  • 管控负责人是否为 CTO？是否需设独立的信息安全/保密专员？
  • 代码仓库管理员与公开仓库扫描由谁负责？
  • 机密资产分级是否覆盖 Skill、提示词等非代码资产？
  • 员工处置的罚则是否已写入保密规范并经 HR 公示？
  • 2 小时止损时限是否可行（夜间/节假日如何处理）？
LEG-32诉讼、仲裁与法律纠纷应对待新建推断100

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨4 × 险5

  • 适用场景：公司收到律师函、起诉状、仲裁申请、法院传票，或需要对客户欠款、供应商违约、侵权方等发起法律主张时启动
  • 负责人：主责——法务专员（当前：待指定）；协同——涉事业务部门负责人（当前：待指定）、财务（当前：待指定）、外部律师（如有）；兜底——法务负责人（当前：李瑶·部门报送人）
  • 核心流程：① 文书接收与期限登记 → ② 事实与证据收集 → ③ 风险评估与策略 → ④ 管理层决策 → ⑤ 协商/发函/应诉/起诉 → ⑥ 执行与回款 → ⑦ 结案复盘
  • 交付结果：纠纷台账、证据目录、处理策略与决策记录、和解协议或裁判文书及执行结果
  • 状态依据：已有 LEG-17（被抄袭/侵权线索登记取证）、FIN-21（收入合同台账与回款跟进）覆盖部分环节，本条补齐对外法律纠纷的统一受理、期限管理与诉讼仲裁应对（推断）

1. 场景判定

  • 触发条件：收到法律文书或律师函；应收款逾期且催收无果；合作方违约；发现侵权已造成损失
  • 典型说法：「客户收到货一直不付款」「收到一封律师函」「供应商交付延期造成损失」
  • 判断问题：是否已有或可能产生法律程序？是否有明确期限？
  • 不归本流程管：劳动争议 → 请走 HR-29；侵权线索初步处置 → 请走 LEG-17；日常回款跟进 → 请走 FIN-21；外部来文的统一收文登记 → 请走 GEN-20（法律文书登记后转入本流程）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主办 登记期限、组织证据、出策略、对接律师 R 法务专员（当前：待指定）
事实提供 合同、沟通记录、交付证据 C 涉事业务部门负责人（当前：待指定）
账务数据 付款、回款、开票记录 C 财务（当前：待指定）
外部律师 复杂案件的策略意见与诉讼代理 C 外部律师（如有，由法务负责人委托）
决策 是否起诉、和解底线 A CEO（当前：邴龙志·推断待确认）
兜底 规则维护、律所管理与案件把关 R 法务负责人（当前：李瑶·部门报送人）

3. 办之前请准备

  • 合同原件与补充协议、往来邮件与聊天记录、交付签收单、发票与付款凭证
  • 文书原件及送达日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 文书接收后登记期限，前台/行政收到法律文书当天转法务 法务专员 收到当天 飞书多维表格（纠纷台账） 台账记录 🔧飞书固化
2 收集并固定证据 法务专员+业务部门 登记后 5 个工作日内 文档 证据目录 🔧+🤖
3 风险评估与处理策略 法务专员/外部律师 证据齐后 3 个工作日内 文档 策略意见 👤人工判断
4 管理层决策 CEO 策略提交后 2 个工作日内 飞书审批 决策记录 🔧飞书固化
5 执行：协商、发函、应诉或起诉 法务专员 按文书期限前 3 个工作日完成提交 律所协作 函件/诉讼材料 👤人工判断
6 裁判或和解后的执行与回款入账 法务专员+财务 生效后按期限 网银 执行记录 👤人工判断
7 结案复盘，回写合同模板风险点 法务专员 结案后 10 个工作日内 文档 复盘与模板修订建议 👤人工判断

5. 交付物与模板

  • 交付物：纠纷台账、证据目录、决策记录、结案复盘
  • 建议模板/表单：纠纷台账字段（案件类型、对方、我方主体、争议事由、程序阶段、关键期限、代理律师、状态、结果）

6. 异常与升级

  • 期限不足 5 个工作日 → 当天报法务负责人与 CEO，必要时委托外部律师
  • 涉及财产保全、账户冻结 → 立即通知财务与 CEO

7. 衡量指标

  • 期限遵守率：目标 100%
  • 应收类纠纷回款率 = 纠纷结案回收额 / 主张额（只统计比例）

8. 低效诊断

  • 聊天中未见相关流程，存在文书无人接收错过期限、证据未及时固定、应收款超过诉讼时效的风险（推断）

9. 分支变体

  • 不同主体作为当事方分别登记；境外纠纷需评估适用法律与争议解决地，优先委托外部律师

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 是否有常年法律顾问？律所费用由哪个主体承担？
  • 应收款逾期多久后转入法律催收？
LEG-33监管问询、执法调证与约谈应对待新建推断80

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗4 × 跨4 × 险5

  • 适用场景：网信、公安、通信管理、市场监管等部门对公司产品或用户数据发出问询、调取证据、协助调查、约谈或整改通知时启动
  • 负责人：主责——法务专员（当前：待指定）；协同——研发/运维负责人（当前：待指定）、产品负责人（当前：待指定）、政策申报对接人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）
  • 核心流程：① 接收与身份核验 → ② 登记期限 → ③ 法律评估调取范围 → ④ 审批 → ⑤ 最小范围提供数据或材料 → ⑥ 整改落实 → ⑦ 归档与复盘
  • 交付结果：经核验的执法文书登记、数据提供记录、整改报告、约谈纪要
  • 状态依据：已有 CEO-17（政府部门对接与政策风险应对）、POL-02（政府部门日常对接）覆盖部分环节，本条补齐执法调证、监管问询与约谈的法律处置口径；AIGC 与网关业务涉及用户数据（推断）

1. 场景判定

  • 触发条件：收到调取证据通知书、协助调查函、约谈通知、整改通知；监管电话要求提供用户信息
  • 典型说法：「派出所来电话要某个账号的注册信息」「网信办要求整改」「平台说要约谈」
  • 判断问题：对方身份与文书是否真实合法？要求的数据范围是否明确？
  • 不归本流程管：政府日常业务对接 → 请走 POL-02；政府临时开会、汇报演示与政策态度变化 → 请走 CEO-17；用户举报与监管平台转办的消费投诉受理 → 请走 OPS-31；AIGC 内容审核策略 → 请走 LEG-20；资质办理与年报 → 请走 LEG-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主办 核验、登记、评估、对外答复 R 法务专员（当前：待指定）
数据调取 按审批范围导出数据并留痕 R 研发/运维负责人（当前：待指定）
整改 产品功能与策略整改 R 产品负责人（当前：待指定）
决策 批准提供范围与整改方案 A CEO（当前：邴龙志·推断待确认）
兜底 规则维护、身份存疑事项把关 R 法务负责人（当前：李瑶·部门报送人）
接收人 接到来电/来函当天转法务，不自行答复 R 全体员工

3. 办之前请准备

  • 执法文书原件或扫描件、办案人员证件信息
  • 涉及产品、账号、时间范围的说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 任何员工接到监管来电/来函，当天转法务，不自行答复 接收人 当天 飞书 转办记录 🔧飞书固化
2 核验对方身份与文书真实性，登记期限 法务专员 1 个工作日内 台账 核验记录 👤人工判断
3 评估调取范围与法律依据 法务专员 核验后 1 个工作日内 文档 评估意见 👤人工判断
4 审批提供范围 CEO 评估后当天 飞书审批 审批结论 🔧飞书固化
5 按最小范围导出数据，双人核对后提供 研发/运维负责人+法务专员 按文书期限 受控导出 提供记录 🔧+🤖
6 约谈或整改：准备说明材料，落实整改并回复 法务专员+产品负责人 按通知期限 文档 整改报告 👤人工判断
7 归档并复盘制度与产品改进 法务专员 结束后 5 个工作日内 档案 复盘记录 🔧飞书固化

5. 交付物与模板

  • 交付物：监管事项台账、数据提供记录、整改报告、约谈纪要
  • 建议模板/表单：台账字段（机关、文书类型、文号、接收日期、期限、涉及产品/主体、提供范围、审批人、提供日期、状态）

6. 异常与升级

  • 无法核验身份或无书面文书 → 礼貌要求补充正式文书，不提供数据，报法务负责人
  • 涉及重大整改或下架要求 → 当天报 CEO，按 CEO-17 启动应对

7. 衡量指标

  • 期限遵守率：目标 100%
  • 未经审批对外提供数据次数：目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在员工直接对外提供用户数据、错过整改期限导致处罚或下架的风险（推断）

9. 分支变体

  • 不同主体运营的产品由对应主体答复；涉及客户私有化部署的数据，公司无访问权时如实说明并指引至客户

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各产品的监管联系人是否已在备案系统中登记？与本流程是否一致？
  • 用户数据导出是否已有受控工具与日志？
LEG-34个人信息权利请求与数据安全事件合规处置待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：用户请求查询、复制、更正、删除个人信息或注销账号，或发生用户个人信息、客户数据泄露、篡改、丢失等数据安全事件需要法律评估、告知与报告时启动
  • 负责人：主责——法务专员（当前：待指定）；协同——客服/运营（当前：待指定）、研发/运维负责人（当前：待指定）、安全负责人（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）
  • 核心流程：① 受理与身份核验 → ② 分类（权利请求/安全事件）→ ③ 影响评估 → ④ 执行请求或止损 → ⑤ 告知个人/客户 → ⑥ 必要时向监管报告 → ⑦ 留痕归档
  • 交付结果：权利请求处理记录、数据安全事件评估报告、告知与报告留档
  • 状态依据：已有 LEG-18（隐私政策编制）、X-SEC-11（凭据泄露技术处置）覆盖部分环节，本条补齐个人信息权利请求的统一法律口径与数据安全事件的法律评估、告知与报告（推断）

1. 场景判定

  • 触发条件：用户经客服、邮件、产品内入口提出个人信息请求或注销；技术侧确认用户/客户数据被未授权访问或外泄
  • 典型说法：「请删除我的所有数据」「我要注销账号」「数据库被扫了，可能泄露了用户手机号」
  • 判断问题：是否涉及可识别个人或客户业务数据？影响人数与数据敏感程度？
  • 不归本流程管：密钥凭据泄露的技术处置 → 请走 X-SEC-11；内网安全事件溯源 → 请走 X-SEC-42；数据泄露事件的技术响应与内部报告 → 请走 X-SEC-44；隐私政策更新 → 请走 LEG-18
  • 口径分工：本条是个人信息权利请求的唯一法律口径（答复时限、身份核验、留存例外、拒绝理由）；产品用户请求的受理执行 → 请走 OPS-29；数据分类分级与保留期限 → 请走 X-SEC-45；招聘候选人信息 → 请走 X-RCT-24；以上执行流程均引用本条口径

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
法律评估与告知 判断义务、拟定告知与报告 R 法务专员（当前：待指定）
受理 接收请求、核验身份、回复用户 R 客服/运营（当前：待指定）
执行 删除/导出数据、止损、出技术报告 R 研发/运维负责人（当前：待指定）
事件研判 影响范围与原因 C 安全负责人（当前：待指定）
决策 数据安全事件是否对外告知与向监管报告 A（升级） CEO（当前：邴龙志·推断待确认）
兜底 权利请求口径、例外判断与规则维护 A 法务负责人（当前：李瑶·部门报送人）

3. 办之前请准备

  • 用户账号标识与身份核验材料
  • 事件时间线、受影响数据类型与数量、技术处置记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 受理登记并核验身份 客服/运营 收到后 1 个工作日内 工单 受理记录 🔧飞书固化
2 权利请求：研发按请求导出/删除并确认 研发/运维负责人 受理后 10 个工作日内 后台工具 执行记录 🤖自动化
3 回复用户处理结果 客服/运营 受理后 15 个工作日内（以法务确认的法定时限为准） 邮件/站内信 回复留档 🔧飞书固化
4 安全事件：技术止损同时通知法务 安全负责人 发现后 1 小时内 飞书 事件通知 👤人工判断
5 法律评估影响范围与告知/报告义务 法务专员 通知后 1 个工作日内 文档 评估报告 👤人工判断
6 审批并告知受影响个人/客户、向监管报告 法务专员+CEO 按法定时限 邮件/监管平台 告知与报告留档 👤人工判断
7 归档并推动整改 法务专员 结束后 5 个工作日内 档案 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：请求处理台账、事件评估报告、告知文本、监管报告留档
  • 建议模板/表单：事件评估表（发现时间、数据类型、涉及人数、是否含敏感个人信息、原因、已采取措施、是否需告知、是否需报告、负责人）

6. 异常与升级

  • 涉及敏感个人信息或大量用户 → 立即报 CEO 与法务负责人（1 小时内）
  • 涉及私有化客户数据 → 当天通知客户对接人并按合同约定通报
  • 升级条件：发生数据安全事件且需对受影响个人/客户告知或向监管报告 → CEO 作为 A（升级）决定；日常权利请求与拒绝/例外判断由法务负责人决定

7. 衡量指标

  • 权利请求按期处理率：目标 100%
  • 事件评估时效：从技术确认到法律评估完成的时长，目标 ≤ 1 个工作日

8. 低效诊断

  • 聊天中未见相关流程，存在注销/删除请求无人受理、数据泄露未按时告知和报告引发监管处罚的风险（推断）

9. 分支变体

  • 境外用户（如海外分站）需按适用地法律评估；企业客户的员工数据请求，由客户作为处理者先行受理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各产品是否已提供账号注销与个人信息请求入口？
  • 是否已指定个人信息保护负责人？
  • OPS-29、X-SEC-45、X-RCT-24 已改为引用本条口径，是否认可本条作为个人信息权利请求的唯一口径来源？
LEG-35合同履约节点与到期续约管理待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：已签署的销售、采购、服务、合作合同中存在验收期、质保期、付款节点、自动续约、到期终止通知期等关键节点，需要提前提醒和决策时适用
  • 负责人：主责——合同管理员（当前：待指定）；协同——合同经办人（当前：待指定）、财务（当前：待指定）；兜底——法务负责人（当前：李瑶·部门报送人）
  • 核心流程：① 签约时提取关键节点 → ② 录入台账 → ③ 节点前自动提醒 → ④ 经办人确认履约状态 → ⑤ 续约/终止/变更决策 → ⑥ 发函或签署补充协议 → ⑦ 台账更新
  • 交付结果：带关键节点的合同台账、续约或终止决定、相关函件与补充协议
  • 状态依据：已有 LEG-11（合同编号、台账与原件归档）覆盖台账环节，本条补齐合同履约节点与到期续约的提醒与决策（推断）

1. 场景判定

  • 触发条件：合同归档入台账时；节点前 30/60 日；对方发出续约或终止通知
  • 典型说法：「这个云服务合同会不会自动续费」「客户的质保期什么时候到」「验收期过了客户还没签单」
  • 判断问题：合同是否有时间敏感的权利义务？错过节点是否会产生费用或丧失权利？
  • 不归本流程管：合同编号与原件归档 → 请走 LEG-11；办公场地租约 → 请走 ADM-36；回款催收 → 请走 FIN-21；客户额度/维保到期的续费推进 → 请走 X-CS-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账维护 提取节点、设置提醒 R 合同管理员（当前：待指定）
履约确认 确认履约状态、提出续约建议 R 合同经办人（当前：待指定）
付款回款 付款/回款节点核对 C 财务（当前：待指定）
系统 节点前自动提醒 R 飞书机器人（合同管理员维护）
审批 续约/终止/变更 A 法务负责人（当前：李瑶·部门报送人）

3. 办之前请准备

  • 已签合同扫描件与合同台账（LEG-11）
  • 合同中的期限、续约、终止通知、违约条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签约归档时提取关键节点 合同管理员 归档后 2 个工作日内 AI 提取+人工核对 节点清单 🤖+👤
2 录入台账并设置提醒 合同管理员 同上 飞书多维表格自动化 提醒规则 🔧飞书固化
3 节点前提醒经办人 系统 节点前 30 日（续约/终止前 60 日） 飞书机器人 提醒 🤖自动化
4 经办人确认履约状态与续约意见 合同经办人 提醒后 5 个工作日内 多维表格 履约状态 👤人工判断
5 审批续约/终止/变更 法务负责人 确认后 3 个工作日内 飞书审批 审批结论 🔧飞书固化
6 发出通知函或签署补充协议 合同经办人+法务 通知期届满前 电子签/用印 函件/协议 🔧飞书固化
7 更新台账状态 合同管理员 完成后 2 个工作日内 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：合同节点台账、续约/终止记录
  • 建议模板/表单：台账增加字段（验收期限、质保到期日、付款节点、合同到期日、是否自动续约、终止通知期、经办人、节点状态）

6. 异常与升级

  • 已错过终止通知期 → 法务评估协商退出方案（3 个工作日内）
  • 经办人离职 → 合同管理员按交接清单指定新经办人（HR-27 联动）

7. 衡量指标

  • 节点按期处理率：目标 100%
  • 非预期自动续约次数：目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在云服务和订阅类合同被动自动续费、验收与质保节点失控影响回款与责任认定的风险（推断）

9. 分支变体

  • 云厂商与 AI 订阅类线上协议也纳入台账；不同主体合同按签约主体分台账管理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 合同台账目前在哪个系统？是否能增加节点字段与提醒？
  • 合同管理员由法务还是行政承担？

HR 人事

报送人：黄莹 · 综合 · 33 条 · 已有 0 / 待优化 17 / 待新建 16
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
HR-01人事制度编制、意见征集与发布宣贯公司需要新出台或修订人事类制度（员工手册、考勤、休假、年假、加班、实习/试用期规范、放假与福利通知等）时启动，覆盖起草、评审、意见征集、定稿发布、宣贯答疑全过程。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、法务（当前：待指定）、各部门负责人及部门意见汇总人；终审——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 立项定框架 → ② 起草初稿 → ③ 管理层/法务批注 → ④ 部门负责人评审 → ⑤ 全员解读与归口征集 → ⑥ 定稿终审 → ⑦ 发布并配置飞书规则 → ⑧ 宣贯答疑与归档经终审、带版本号和生效日的正式制度文档；全员发布通知；已配置的飞书假勤/审批规则；意见处理表；宣贯签到记录与 FAQ。待优化300
HR-02组织架构调整与飞书架构/审批人维护部门新设、更名、合并、负责人调整，或飞书审批上线/改版需要明确直属上级与审批人时启动，确保组织架构表、飞书通讯录、审批流三者一致。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、财务（当前：陈雅萍、黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、各部门负责人；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 调整决策 → ② 更新组织架构表 → ③ 发布调整通知 → ④ 部门负责人逐一沟通 → ⑤ 飞书通讯录与直属上级同步 → ⑥ 审批流审批人复核 → ⑦ 全员反馈确认 → ⑧ 关联方同步与归档最新版组织架构表（含岗位、直属上级、部门负责人、人员类型）；已同步的飞书通讯录与审批人配置；调整通知与反馈表汇总。待优化72
HR-03HC申请与人力成本统计部门需要新增人员编制（HC），或管理层索要人员清单、岗位清单、人力成本数据时启动，按统一模板测算、审批并输出花名册与成本表。主责——人事负责人（当前：黄莹·推断待确认）；协同——申请部门负责人（当前：杨萌、徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 部门提出 HC 需求 → ② 按模板测算预算与 ROI → ③ HR 核对人力成本基数 → ④ CEO 审批 → ⑤ 获批转招聘 → ⑥ 花名册/成本表月度更新 → ⑦ 按需出数据报表已审批的 HC 申请单；实时更新的员工花名册与月度人力成本表；按需输出的人员/岗位/成本报表。待新建81
HR-04用工主体判定与劳动合同/协议签署新员工入职、补签、转正改签或出现特殊用工（在读学生、未成年人、远程试用、另有劳动关系、多公司法人入职、对外任职）时启动，确定劳动关系主体与用工类型，签署劳动合同/实习/劳务协议及保密、竞业、对外任职承诺。主责——人事负责人（当前：黄莹·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、行政（用印）（当前：侯明月·推断待确认）、用人部门负责人（当前：徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 收集用工信息 → ② 判定用工类型 → ③ 判定合同主体 → ④ 特殊情形法务咨询 → ⑤ 拟定合同并群内审核 → ⑥ 用章审批 → ⑦ 入职当日签署 → ⑧ 归档与主数据登记主体与类型正确、双方签署并盖章的劳动合同/实习协议/劳务协议，配套保密、竞业、知识产权、对外任职承诺；员工主数据中的主体、合同类型、期限、到期日。待新建180
HR-05新员工入职准备与办理候选人确认到岗日后启动，由 HR 发出入职通知单，统一协调工位、电脑、飞书账号/组织层级/席位、邮箱、代码仓库与终端软件、门禁工牌、拉群、福利告知，直至到岗当天接待完成。主责——人事负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、行政（当前：胡则瑾、侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、用人部门负责人；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 用人部门提交入职通知单 → ② HR 发候选人入职通知 → ③ 采集入职信息并核对证件 → ④ 设备采购/调配 → ⑤ 工位、门禁、名片 → ⑥ 飞书席位与组织归位 → ⑦ 账号与权限开通 → ⑧ 到岗接待与介绍 → ⑨ 清单核验入职清单全部勾完：合同已签、工位与设备到位、飞书账号在正确部门与直属上级下、邮箱/代码仓库/终端软件/产品账号已开通、已拉入对应群、导师已指定、新人已在部门群介绍。待优化225
HR-06新人入职培训、带教与首周上手新员工或实习生到岗后启动，完成通用入职培训（价值观、架构、制度、作息）、指定导师、发放岗位学习资料与环境指引、安排首周任务并明确权限边界，直到 30 天回顾。主责——人事负责人（当前：黄莹·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、用人部门负责人（当前：杨萌、王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认）、导师（当前：岳阳、宋祺睿、陈晖·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 到岗前指定导师与首周任务 → ② 发放入职资料包 → ③ 首日作息与制度告知 → ④ 岗位环境与规范上手 → ⑤ 首周任务与每日跟进 → ⑥ 集中入职培训 → ⑦ 首周与 30 天回顾新人入职交接卡（导师、首周任务、权限边界）；首周任务完成记录；集中入职培训签到；30 天回顾记录（作为转正评估输入）。待新建108
HR-07实习生用工管理录用和管理在校/应届实习生时启动，涵盖协议类型、观察期、出勤确认与按天结算、导师与归属调整、学校材料（三方协议、实习证明、日志）配合，直至转正或离职。主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、导师/直属上级（当前：李子遥·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 核验在校身份 → ② 签实习协议并定档 → ③ 指定导师与出勤方式 → ④ 每日出勤记录 → ⑤ 月末导师确认出勤 → ⑥ HR 核算、财务发放 → ⑦ 学校材料办理 → ⑧ 观察期满转正/转岗/离职签署的实习协议；实习生台账（身份、档位、导师、观察期、出勤方式）；导师确认的月度出勤表；按时足额发放的实习薪酬；学校所需证明材料。待新建144
HR-08试用期/实习观察期考核与转正新员工入职（试用期 3 个月）或实习生入职（观察期 2 个月）后启动：入职即定考核指标，期间设检查点，期满前 HR 发起评估，由直属上级给结论、决策人定转正薪资，完成转正、延长或不通过处理。主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/评估人（当前：杨萌、王皓南、张东郅、王子明·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；转正定薪——CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 入职定考核指标 → ② 2 周/1 个月检查点 → ③ HR 月度到期名单 → ④ 员工交转正报告 → ⑤ 直属上级评估 → ⑥ 定薪定级 → ⑦ 三方面谈与书面通知 → ⑧ 签约变更与归档每人一份考核指标；转正报告与评估表；转正/延长/不通过结论与书面通知；转正薪资确认；花名册与合同同步更新。待优化108
HR-09薪酬定级与调薪制定或调整薪酬带宽与实习生统一档位；员工转正定级、表现突出或到季度调薪时点需要调薪；管理层口头决定调薪或补贴变更、需要 HR 落地时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——创始人兼 CTO（研发岗评估，当前：丁震宇·推断待确认）、产品/业务负责人（当前：杨萌·推断待确认）、技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 维护薪酬带宽与实习档位 → ② 直属负责人提交定级/调薪申请 → ③ CTO/业务负责人评估 → ④ CEO 审批 → ⑤ 写明生效月与实发月 → ⑥ 告知员工 → ⑦ 写入异动表推送财务 → ⑧ 首个实发月核对并归档审批通过的定级/调薪单（级别或区间、生效月、实发月、理由）、更新后的人员异动表与工资表、员工告知记录、现行薪酬带宽与实习档位表待新建180
HR-10日常考勤打卡、补卡与到岗规范员工日常上下班打卡与到岗；飞书打卡失败、漏打卡需要补卡；超过最晚到岗时间未到且未报备需要提醒或按规扣罚；团队进入或结束冲刺期需要调整到岗规则时主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、站会组织人（当前：李铭熙、宋祺睿·推断待确认）、规则拍板人创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 发布公司考勤规则与组内弹性约定 → ② 配置飞书考勤 → ③ 员工每日打卡 → ④ 异常自动提醒本人 → ⑤ 员工提补卡 → ⑥ 直属上级审批 → ⑦ 到岗异常提醒与警告 → ⑧ 扣罚进入月度核对一页纸《考勤打卡与补卡指引》、飞书考勤规则配置、每日异常提醒与补卡审批记录、到岗警告记录待优化90
HR-11请假、居家/远程办公与外勤报备员工需要请事假/病假/年假/调休，或申请居家/远程办公、外勤、外出办事与外出培训时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/团队负责人（当前：杨萌、王皓南·推断待确认）、研发线审批人创始人兼 CTO（当前：丁震宇·推断待确认）、非研发审批人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 员工事前提交对应假勤审批 → ② 直属上级审批（按部门自动路由） → ③ 审批通过自动通知团队群与项目负责人 → ④ 交接与紧急联系 → ⑤ 居家期间站会与日报 → ⑥ 变更在审批内撤回/修改 → ⑦ 额度与余额维护 → ⑧ 数据进入月度考勤核对审批通过的请假/居家/外勤单、团队群同步通知、交接记录、居家日报、员工可自查的年假与调休余额待优化60
HR-12加班申请、工时登记与调休/加班费结算项目赶工、上线、大会、客户线下加急需要晚间/周末/法定节假日加班，或公司宣布紧急赶工期时，从事前申请到事后折算调休、加班费、补贴或积分全程适用主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、研发加班审批人创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 制度成文并经法务审定 → ② 事前提交加班申请或名单 → ③ 直属上级审批 → ④ 加班打卡 → ⑤ 事后提交工时与成果 → ⑥ 上级确认工时 → ⑦ HR 月度汇总 → ⑧ 折算调休/加班费/积分 → ⑨ 落账并告知经法务审定的《加班管理制度》、审批通过的加班单与名单、确认后的加班工时明细、月度加班结算清单、员工可查的调休余额与工资条加班项待新建320
HR-13节假日放假调休与值守安排通知春节、五一、中秋国庆等法定节假日或公司统一调休日前，需要确定放假/补班/调休/居家办公方案、收集各项目组值守与 oncall，并向全员发正式通知时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（方案决策，当前：邴龙志·推断待确认）、创始人兼 CTO（研发侧方向与值守，当前：丁震宇·推断待确认）、各项目组负责人（当前：杨萌、陈梦琪、徐莉、王皓南·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 年初发布全年放假日历 → ② 长假前发起方案收集 → ③ 各项目组上报居家/到岗/值守 → ④ CEO 拍板 → ⑤ HR 发正式通知并要求已读 → ⑥ 飞书假勤配置补班与调休扣减 → ⑦ 节中值守 → ⑧ 节后考勤与加班处理年度放假与调休日历；节前正式通知（放假与补班、公司调休日抵扣规则、居家安排与工作时间、值守/oncall 表、节日福利、加班结算口径）；节后调休扣减记录待优化90
HR-14月度考勤核对与请假扣薪核定每月初核对上月出勤，通知员工补卡补请假，由直属上级确认缺卡、事假、病假、迟到是否扣薪，输出考勤结果供工资核算时启动；考勤试运行期按周执行主责——人事负责人（当前：黄莹·推断待确认）；协同——各直属上级/组长（当前：杨萌、王皓南·推断待确认）、扣薪审核人创始人兼 CTO（当前：丁震宇·推断待确认）、口径决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 每周推送异常给上级 → ② 月初导出上月考勤并比对审批 → ③ 推送个人异常与补卡截止 → ④ 员工补卡/补请假 → ⑤ 直属上级确认扣薪意见 → ⑥ HR 按制度核定 → ⑦ 审核 → ⑧ 锁定考勤结果提交工资核算月度考勤结果表（每人应出勤、实出勤、缺卡、事假、病假、迟到、旷工、扣薪天数）、直属上级确认记录、补卡截止通知、扣薪说明待优化180
HR-15月度工资核算发放与员工个税答疑每月发薪周期内，人事确定薪资明细后由财务测算个税，经管理层审核审批后发放并推送工资条；处理错发、金额异常、个税申报异常与员工退补税咨询主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（薪资明细与工资条，当前：黄莹·推断待确认）、CEO（审核审批，当前：邴龙志·推断待确认）、COO（审核，当前：常元和·推断待确认）、创始人兼 CTO（审核，当前：丁震宇·推断待确认）、跃竞负责人（跃竞薪酬核对，当前：徐莉·推断待确认）；兜底——综合部负责人① 1 日收集异动 → ② 3 日薪资表定稿 → ③ 管理层审核 → ④ 5 日前测税反写 → ⑤ 付款审批 → ⑥ 8 日双人复核发放 → ⑦ 推送工资条确认 → ⑧ 个税申报与答疑经审核的分主体工资表、付款回单、员工已确认的飞书工资条、个税申报回执、异常处理记录待优化180
HR-16社保公积金缴纳与增减员员工入职、离职、在模态/鼎慧/苏州/跃竞等主体间变更劳动关系，或缴费基数调整、员工咨询缴纳情况、税务系统发出社保与个税口径差异预警时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——社保办理人（当前：侯明月·推断待确认，拟交接至人事）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（口径，当前：丁震宇·推断待确认）、COO（主体规划，当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 入离职/主体变更自动进入当月增减员清单 → ② 20 日前核对主体、基数、比例 → ③ 25 日前办理增减员与申报 → ④ 财务付款 → ⑤ 扣款对账 → ⑥ 更新员工缴纳台账 → ⑦ 每季度盘点应缴未缴 → ⑧ 税务预警处置月度增减员清单与办理回执、社保公积金明细表、员工缴纳台账（主体、基数、比例、起缴/停缴月）、付款记录、季度盘点报告、预警处置记录待优化180
HR-17AI工具补贴发放与调整每月为员工发放 AI 工具补贴，以及新入职、实习、岗位变化、警告取消、离职、超额申请、规则调整等需要核定或变更补贴档位时启动主责——人事专员（当前：黄莹·推断待确认）；协同——财务专员（当前：黄梦婷·推断待确认）、IT 核定人（当前：杨明学·推断待确认）、补贴制度制定人（当前：丁震宇·推断待确认）、法务（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）；档位例外审批——CEO（当前：邴龙志·推断待确认）① 月初更新名单与档位 → ② 例外调档审批 → ③ 出补贴发放表 → ④ 财务 15 日打款 → ⑤ 发放通知与 FAQ → ⑥ 月底员工提交支出凭证 → ⑦ IT 核定达标并记录暂停/恢复 → ⑧ 超额部分走报销当月按时到账的 AI 补贴；与工资分开的《AI 补贴发放表》；《AI 补贴名单与核定台账》（含档位、达标结果、暂停/恢复月份）；单一版本的补贴规则 wiki + FAQ待优化144
HR-18积分激励制度运行积分激励、期权激励、知识产权激励等制度发布后，需要宣贯答疑、编制积分预算、组织申报、核验公示、登记台账、兑换发放时启动主责——积分运营组牵头人（总经办，当前：赵雪冰·推断待确认）；协同——人事负责人（当前：黄莹·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）、积分系统负责人（当前：丁震宇·推断待确认）、各一级部门负责人；决策——积分管理委员会（董事会成员 + 一级部门负责人，召集人当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 制度发布与宣贯（写明适用范围）→ ② 季度积分预算 → ③ 个人/部门申报 → ④ 运营组初核 → ⑤ 委员会审议 → ⑥ 公示与异议复核 → ⑦ 登记台账 → ⑧ 兑换发放带适用范围和 FAQ 的制度宣贯包；季度积分预算；经委员会决议并公示的积分结果；积分台账（个人、部门、来源、余额）；与财务对接的兑换/发放清单待新建225
HR-19研发绩效评价与质量奖惩每个迭代结束或每月初，需要统计研发/测试工作量（故事点、任务点数）、评级，统计线上 Bug 并认定责任，据此确定奖金、扣款、积分或 AI 补贴调整时启动主责——研发团队负责人（Leap 线当前：王皓南·推断待确认；跃竞线当前：徐莉·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、绩效汇总人（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）① 迭代前公示参与人与点数 → ② 迭代后统计工作量 → ③ 上线后 Bug 定级归因 → ④ 公示责任比例 → ⑤ 申诉与终裁 → ⑥ 月度评级汇总 → ⑦ 人事合规复核 → ⑧ 结果应用与结算每迭代工作量统计表；每次发布的 Bug 定级与责任认定公示；月度研发/测试绩效总表（评级 + 主观评分）；经人事复核的奖惩结算清单（交财务随工资结算）待优化180
HR-20员工绩效/行为问题访谈与处置员工出现产出持续不足、交付质量问题影响他人、多次迟到、失联、不配合或态度问题，需要访谈调查、书面警告、改进期、调岗/降薪转岗或终止时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——直属负责人（当前：各团队负责人，如王皓南、杨萌·推断待确认）、带教人（实习生，当前：待指定）、法务负责人（当前：李瑶·部门报送人）；处置决策——研发负责人/CEO（当前：丁震宇、邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 记录事实 → ② 直属负责人首次沟通 → ③ 人事访谈调查 → ④ 分级判定 → ⑤ 处置决策 → ⑥ 书面告知与签收 → ⑦ 改进期跟踪 → ⑧ 结论归档（终止则转离职交接）问题事实记录；访谈纪要（权限受限）；处置决定（警告函/改进计划/调岗通知/终止通知）及本人签收；改进期复盘结论；人事档案归档待新建180
HR-21年度/阶段总结收集与1v1面谈年终或阶段节点（季度、集中加班后），需要下发总结通知与模板、按名册收集、组织互读评论、安排管理者与员工 1v1 面谈并沉淀结论时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——年度通知发起人与访谈人（CEO，当前：邴龙志·推断待确认）、技术部总结组织人（当前：丁震宇·推断待确认）、产研阶段总结组织人（当前：杨萌·推断待确认）、各模块负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 拟通知、模板与名册 → ② 管理层审阅 → ③ 按名册发布并建待办 → ④ 提交并回填汇总表 → ⑤ 自动催交 → ⑥ 互读评论与批注 → ⑦ 1v1 预约与面谈 → ⑧ 纪要归档与结果应用全员总结提交汇总表（100% 覆盖名册）；管理者批注与互评记录；1v1 排期表与面谈纪要（权限受限）；用于绩效、调薪参考的结论清单待优化72
HR-22员工福利：体检与商业保险公司开通或年度发放体检、团体商业保险、中医问诊等福利，需要方案选型、对接机构、发卡、组织预约、收集体检报告、更新参保名单、解答理赔问题时启动主责——福利统筹（行政，当前：侯明月·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、财务（当前：待指定）、各组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 年度方案对比 → ② CEO 选定 → ③ 付款开通 → ④ 发卡与参保名单 → ⑤ 发布使用指引与 FAQ → ⑥ 统一/自行预约 → ⑦ 体检报告收集（限授权查看）→ ⑧ 理赔答疑与季度名单更新年度福利方案与对比文档；体检卡发放台账；团险参保名单（按季度更新）；《体检与保险使用指引 + 理赔 FAQ》；体检报告提交记录（仅授权人员可见）待优化96
HR-23内部培训与分享会组织有内部培训或分享需求（价值观、AI 工具、FDE、信创、专利、LeapCore/LeapAll、周五分享、销售演示等），需要选题排期、报名或参训确认、场地与线上会议、通知、录屏、资料归档和反馈收集时启动主责——内部培训统筹人（学习委员，当前：杨萌·推断待确认）；协同——总经办培训专员（当前：王欣·推断待确认）、综合部负责人（参训确认，当前：赵雪冰·推断待确认）、行政（场地，当前：胡则瑾·推断待确认）、课程体系负责人（当前：李凯·推断待确认）、FDE 培训组织人（当前：陈梦琪·推断待确认）、讲师（当前：王皓南、马漳毓、陈子康等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 提交分享/培训申请 → ② 统筹人确认选题与排期 → ③ 讲师备课（大纲、软件清单、海报必填项）→ ④ 发通知与报名/参训确认 → ⑤ 订场地并建飞书会议（默认录制）→ ⑥ 实施与签到 → ⑦ 1 个工作日内归档妙记与课件 → ⑧ 反馈汇总进入选题池培训日历上的场次；报名/参训确认记录；签到记录；录屏、妙记、课件归档在知识库“内部课程”目录；反馈汇总与下期选题待优化120
HR-24员工活动：年会、团建与委员/兴趣小组组织年度全员大会、户外团建、联合团建、节日或非工作活动，以及学习/卫生/文体委员和兴趣小组开展活动、申请经费时启动主责——活动后勤负责人（行政，当前：侯明月·推断待确认）；协同——人事负责人（请假与人员名单，当前：黄莹·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、卫生委员（当前：侯明月、赵雪冰·推断待确认）、学习委员（当前：杨萌·推断待确认）、各项目组小组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）① 年度活动日历 → ② 活动立项与预算 → ③ 时间投票（选项完整）→ ④ 提前 7 天发正式通知 → ⑤ 报名/请假/饮食一表收集 → ⑥ 后勤落实 → ⑦ 前一天提醒、当天签到 → ⑧ 复盘归档与费用报销年度活动日历；活动方案与预算审批；正式通知（时间、地点、路线、环节、请假方式）；报名与签到记录；活动复盘与费用凭证；委员活动记录（用于积分）待优化108
HR-25人员调岗、借调与汇报线确认员工要从一个组/业务线长期调到另一个组，或被临时借调（含按比例投入，如 0.5 人力），或实习生被其他组拉去干活，或组织调整后直属上级变化时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——调出方负责人、调入/借调方负责人（当前：按个案指定）、资源裁定人：创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人① 调入方提需求 → ② 先与调出方负责人对齐 → ③ 有冲突时资源裁定 → ④ 提交调岗/借调审批 → ⑤ 明确汇报线、派活人、绩效归属与期限 → ⑥ 工作交接与权限调整 → ⑦ HR 更新飞书架构并通知 → ⑧ 借调到期归还或续期已审批的调岗/借调单（含汇报线、派活人、绩效归属、期限、投入比例）、接手人签收的交接清单、更新后的飞书组织架构与人员异动记录、原组和新组群内通知待新建108
HR-26人事异动同步通知入职、转正、调岗/借调、调薪、离职任一人事异动确定（审批通过或生效日确定）后，把信息同步给 CEO、财务、行政、IT、直属上级和相关群主责——人事负责人（当前：黄莹·推断待确认）；协同——财务（当前：祁航·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人① 异动审批通过 → ② 人事当天登记 → ③ 机器人按类型推送 CEO/财务/行政/IT/直属上级 → ④ 各方 1 个工作日内回执 → ⑤ 人事群同步、有无特殊处理 → ⑥ 先通知再改飞书架构 → ⑦ 月度异动表审核后交财务每条异动都有登记和各接收方回执；月度人员异动表审核通过并作为工资核算依据；飞书组织架构与实际一致待新建120
HR-27员工离职办理与交接正式员工、实习生、兼职或顾问提出离职、被劝退、合作到期终止，或发现未办手续离岗时启动；长假前、业务系统移交、换账号时参照其中交接与数据转移步骤主责——人事负责人（当前：黄莹·推断待确认）；协同——离职人直属上级（当前：按个案）、财务负责人（当前：黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CEO（当前：邴龙志·推断待确认，审定离职文件、决定竞业）；兜底——综合部负责人① 飞书提交离职申请 → ② 直属上级审批、定 last day 与接手人 → ③ 写交接文档、接手人确认 → ④ 财务核查未完结事项 → ⑤ 离职文件拟定审定 → ⑥ last day 回收资产、停账号、退群 → ⑦ 清理席位、结算最后工资 → ⑧ 归档审批通过的离职单、接手人签收的交接文档、财务/行政/IT 回执、《离职声明》《员工离职单》《离职证明》、最后工资结算记录待优化225
HR-28人事档案管理与信息权限分级新员工入职建档、全员档案补齐或盘点、档案保管人变更、新岗位（行政助理、会计、总助等）进群或需要查看人事表单、对外提供劳动合同等材料时启动主责——人事负责人（当前：黄莹·推断待确认）；协同——行政（当前：侯明月·推断待确认）、分级标准审定：CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 制定分级标准并由创始人评审 → ② 入职 3 个工作日内建档校验 → ③ 纸质入带锁档案柜、电子入台账 → ④ 按级配置表单与文档权限 → ⑤ 权限变更先通知后执行 → ⑥ 季度盘点与权限审计 → ⑦ 调阅与对外提供登记员工档案/合同台账（多维表格，标出缺项）、《人事信息分级与可见范围表》、上锁档案柜及目录索引、季度盘点与权限审计记录、调阅登记待新建120
HR-29员工申诉与劳动争议处理员工对考勤扣薪、绩效、调岗、解除、加班费等提出异议或投诉，或收到劳动监察投诉、劳动仲裁申请时启动主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 受理登记 → ② 事实核查与证据固定 → ③ 法务风险评估 → ④ 内部沟通调解 → ⑤ 形成处理决定并书面告知 → ⑥ 仲裁/诉讼应对（如进入）→ ⑦ 结案归档与制度改进书面处理结论或调解协议；进入仲裁的，完整证据目录与答辩材料；争议台账一条待新建100
HR-30工伤与员工意外事件处理员工在工作时间、工作场所或因公外出（含出差、上门交付、展会搭建）期间受伤或突发疾病时启动主责——人事专员（当前：待指定）；协同——行政（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 现场救助与报告 → ② 事故信息登记 → ③ 判断是否申请工伤认定 → ④ 法定期限内提交申请 → ⑤ 商保理赔协同 → ⑥ 停工留薪与复岗安排 → ⑦ 隐患整改与归档事故报告、工伤认定申请回执或不申请的书面说明、复岗记录、隐患整改记录待新建60
HR-31劳动合同到期续签与终止员工劳动合同、实习协议或劳务协议即将到期，需要决定续签、变更或终止时启动主责——人事专员（当前：待指定）；协同——员工所在部门负责人（当前：待指定）、法务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 到期前提醒 → ② 部门续签意见 → ③ 审批决定 → ④ 与员工沟通 → ⑤ 签署续签合同或出具终止通知 → ⑥ 异动同步 → ⑦ 归档续签的劳动合同或书面终止通知；合同到期台账更新待新建32
HR-32非研发岗位周期绩效考核与结果应用每季度（或半年）对综合、市场、生态、运营等非研发岗位开展绩效考核，并将结果用于调薪、奖金、晋升与改进时启动主责——人事专员（当前：待指定）；协同——各部门负责人（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 期初目标设定 → ② 期中跟进 → ③ 期末自评 → ④ 上级评价与校准 → ⑤ 结果面谈 → ⑥ 结果应用（调薪/奖金/改进计划）→ ⑦ 归档每位员工的考核表与等级、校准后的部门结果汇总、结果应用清单待新建72
HR-33竞业限制启动、豁免与补偿支付已签竞业限制协议的员工离职时，决定是否启动竞业限制、如何支付补偿、离职后如何跟踪履约时启动主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、原部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 离职时识别竞业协议 → ② 评估是否启动 → ③ 书面通知员工 → ④ 按月支付补偿 → ⑤ 定期确认履约 → ⑥ 违约处置或期满结束竞业启动/不启动书面通知、补偿支付记录、履约确认记录待新建45
HR-01人事制度编制、意见征集与发布宣贯待优化300

状态：待优化｜证据：有证据（卡片 11 张 / 会话 12 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：公司需要新出台或修订人事类制度（员工手册、考勤、休假、年假、加班、实习/试用期规范、放假与福利通知等）时启动，覆盖起草、评审、意见征集、定稿发布、宣贯答疑全过程。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、法务（当前：待指定）、各部门负责人及部门意见汇总人；终审——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 立项定框架 → ② 起草初稿 → ③ 管理层/法务批注 → ④ 部门负责人评审 → ⑤ 全员解读与归口征集 → ⑥ 定稿终审 → ⑦ 发布并配置飞书规则 → ⑧ 宣贯答疑与归档
  • 交付结果：经终审、带版本号和生效日的正式制度文档；全员发布通知；已配置的飞书假勤/审批规则；意见处理表；宣贯签到记录与 FAQ。
  • 状态依据：考勤管理制度、休假管理办法已成文并于 2026-05 生效，有征集表单与宣讲会；但 2026-04～09 聊天中反复出现草稿在终审环节停留、多轮改稿、征集口径中途由“全员直报”改为“部门归口”、合并通知需催约 3 次才发布等信号，约 12 次，缺固定评审节点、版本管理和发布授权。

1. 场景判定

  • 触发条件：管理层提出需统一某项人事规则；各团队对同一规则口径不一（如上下班时间、加班认定）；法规或合规风险需要补制度；节假日、福利需要全员通知。
  • 典型说法：「有的制度不能是我们几个单方面决定」「得定一个标准，然后通知下去」「制度搞好发群里，我们先批注看一下」「逾期未反馈默认无异议」
  • 判断问题：这项规则是否对全员或某类人员长期生效，并可能影响薪酬、考勤或劳动关系？是 → 走本流程完整版；只是一次性事务通知 → 走简化版（见分支变体）。
  • 不归本流程管：积分激励制度的宣贯与运营 → 请走 HR-18；组织架构调整通知与飞书架构设置 → 请走 HR-02；实习生薪酬档位 → 请走 HR-09；各业务部门自己的业务 SOP → 由对应部门编写。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
制度起草人 起草、改稿、整理意见、配置规则、发布、宣贯 R 人事负责人（当前：黄莹·推断待确认）
终审人 给框架、终审内容与生效日 A CEO（当前：邴龙志·推断待确认）
管理层评审 批注草稿、提修改意见 C CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
合规审核 审核工时、加班费、旷工解除等条款 C 法务（当前：待指定）
部门负责人 评审草稿，组织本部门解读与意见收集 C 各部门负责人（当前：杨萌、李鹏为、陈梦琪·推断待确认）
部门意见汇总人 截止前汇总本部门意见归口上报 R 部门指定汇总人（当前：杨明学、杨黔昆·推断待确认）
发布推动 审核通知文本、推动按期发布 C 综合部负责人（当前：赵雪冰·推断待确认）
全体员工 学习、反馈、参加宣贯并签到 I 全员

3. 办之前请准备

  • 立项说明：要解决的问题、适用范围（全员/某主体/某岗位）、拟生效日。
  • 各团队现行做法与口径差异清单。
  • 相关法规要点（工时、加班费比例、休假、旷工解除条件）；涉及时先约法务。
  • 制度模板（版本号、生效日、解释部门、修订记录）。
  • 意见征集飞书表单 + 各部门汇总人名单。
  • 需同步上线的飞书假勤/审批项清单（加班申请、补卡、外出报备、差旅报备等）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提出制度需求与框架（目标、范围、生效日） 终审人 立项当日 飞书文档 立项说明/框架 👤人工判断
2 按模板起草初稿，标出待决条款 起草人 立项后 5 个工作日内 飞书文档（制度模板） 初稿 V0.1 🔧+🤖
3 管理层批注；涉及工时/加班/解除条款同步送法务 管理层评审、法务 收到后 3 个工作日内 飞书文档评论 批注稿 🔧飞书固化
4 发负责人群评审（标注“草稿勿外传”），逐条讨论分歧 起草人、部门负责人 3 个工作日内 飞书文档、负责人群 修订稿、分歧清单 👤人工判断
5 易误解条款（如年假折算）发表单试填，收集可理解性反馈 起草人 2 个工作日内 飞书表单 试填反馈 🔧飞书固化
6 全员解读并公布截止时间；意见由部门内部收集、汇总人统一上报，不受理个人零散直报，逾期视为无异议 起草人、汇总人 征集期 3～5 个自然日 飞书表单、部门群 各部门汇总意见 🔧+🤖
7 逐条处理意见，形成定稿与意见回复 起草人 截止后 2 个工作日内 飞书文档 定稿 V1.0、意见处理表 🤖自动化
8 终审定稿与生效日 终审人 提交后 2 个工作日内 飞书审批（制度发布） 审批记录 🔧飞书固化
9 配置飞书假勤/审批规则，与条文逐条对应 起草人 生效日前 3 个工作日 飞书假勤、审批 规则配置清单 🔧飞书固化
10 全员群发布正式通知（附原文链接、生效日、答疑渠道） 起草人 终审后 1 个工作日内 全员群、知识库 发布通知 🔧飞书固化
11 线上+线下宣贯会：会前 1 天预告、会议签到；无法参会提前向直属负责人报备 起草人 发布后 5 个工作日内 飞书会议 签到、录屏、FAQ 🔧+🤖
12 入制度库，登记版本与修订历史 起草人 宣贯后 2 个工作日内 飞书知识库 制度库条目 🔧飞书固化

5. 交付物与模板

  • 交付物：正式制度文档（含版本）、发布通知、意见处理表、宣贯签到与录屏、FAQ、飞书规则配置清单。
  • 建议模板/表单：
    • 制度模板：制度名称、版本号、适用范围、生效日、解释部门、正文条款、附则、修订记录。
    • 意见征集表单：部门、汇总人、条款编号、意见类型（疑问/修改/反对）、具体内容、提交时间。
    • 意见处理表：意见编号、来源部门、结论（采纳/部分采纳/不采纳）、理由、回复人。
    • 制度库索引：制度名、版本、生效日、负责部门、原文链接、关联审批流。

6. 异常与升级

  • 草稿在终审环节超过 3 个工作日未批 → 起草人在负责人群提醒一次 → 仍未批升级综合部负责人协调（再 2 个工作日）。
  • 法务对条款有异议 → 暂停发布，组织管理层+法务专项讨论 → 终审人 3 个工作日内拍板。
  • 某部门截止前未提交汇总 → 视为无异议；发布后新意见进入下一版修订池，不做临时增补。
  • 草稿定稿前外传 → 起草人在负责人群重申以正式版为准；影响较大时报综合部负责人。
  • 发布后发现条文与飞书规则不一致 → 起草人 1 个工作日内修正配置并发更正说明。

7. 衡量指标

  • 制度出台周期：立项到正式发布的自然日，目标 ≤ 20 天。
  • 终审等待时长：提交终审到批复的工作日，目标 ≤ 2 天。
  • 改稿轮次：定稿前修订版本数，目标 ≤ 3 轮。
  • 宣贯覆盖率：签到人数 / 适用人数，目标 ≥ 95%。
  • 规则一致率：已配置飞书规则的条款 / 需配置条款，目标 100%。
  • 发布后 30 天内同一条款重复咨询次数，目标逐月下降。

8. 低效诊断

  • 现象：草稿与合并通知在终审/发布环节停留，需多次催办，发布依赖个人记忆，缺发布节点与授权｜依据：「模态人事大主管」2026-04、「【模态】综合部」2026-09
  • 现象：征集口径中途从“全员直报”改为“部门汇总归口”，前期零散意见重复处理｜依据：「【模态】业务负责人」2026-05、「【模态】市场销售」2026-05、「⭐大模型基座事业群」2026-05
  • 现象：到岗时间、核心工作时间、加班换调休等定义多轮改动，各团队原有作息认知不一｜依据：「董事会」2026-04、「鼎慧人事」2026-02、「【模态】业务负责人」2026-04
  • 现象：加班申请单等配套审批在讨论后期才上线，员工找不到入口｜依据：「【模态】业务负责人」2026-04
  • 现象：宣贯会签到入口难找、会前 5 分钟才全员提醒、制度原文未随会议发布、无阅读回执｜依据：「模态集团（全员群）」2026-05、「跃迁AI总动员」2026-08
  • 现象：法务介入时点不固定，合规条款（加班费、旷工解除）后期才被追问｜依据：「模态人事大主管」2026-04、「【模态】综合部」2026-05

9. 分支变体

  • 考勤/休假/年假等全员制度：走完整 12 步。
  • 加班制度：加班由主管发起、不由个人申请；强制加班按加班费或调休结算，现金/调休/积分三种结算方式须在条文写清，法务必审。
  • 销售/市场人员：以日报+外出报备替代打卡，出差走差旅报备，需在制度中单列。
  • 节假日放假、福利类通知：走简化版（起草 → 综合部审核 → 终审 → 发布），不做全员征集；建议年初一次性排期。
  • 子公司、跃竞等主体：适用范围单独确认；涉及制度切分时提前同步该主体负责人。
  • 含个案特例的规范（如特殊试用期安排）：不写入公开制度，另设受控附件。

10. 待确认问题

  • 终审人是否统一为 CEO？终审后能否授权综合部直接发布，避免卡在个人？
  • 法务是否为所有人事制度的必经节点，还是仅限工时/加班/解除类条款？
  • 征集期 3～5 天、终审 2 个工作日是否可行？
  • 各部门意见汇总人是否固定并公示？
  • 是否以飞书知识库建统一制度库作为唯一原文入口？旧版如何下线？
  • 宣贯后是否要求员工签阅确认（文档阅读确认或审批回执）？
HR-02组织架构调整与飞书架构/审批人维护待优化72

状态：待优化｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：部门新设、更名、合并、负责人调整，或飞书审批上线/改版需要明确直属上级与审批人时启动，确保组织架构表、飞书通讯录、审批流三者一致。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、财务（当前：陈雅萍、黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、各部门负责人；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 调整决策 → ② 更新组织架构表 → ③ 发布调整通知 → ④ 部门负责人逐一沟通 → ⑤ 飞书通讯录与直属上级同步 → ⑥ 审批流审批人复核 → ⑦ 全员反馈确认 → ⑧ 关联方同步与归档
  • 交付结果：最新版组织架构表（含岗位、直属上级、部门负责人、人员类型）；已同步的飞书通讯录与审批人配置；调整通知与反馈表汇总。
  • 状态依据：组织架构表已建立，2026-04 完成飞书初始设置，2026-07 有完整调整通知与反馈表；但 2026-03～09 出现直属上级空缺、部门负责人未在表中体现、生效后才确认飞书设置、因架构调整延后通知、关联主体要求补同步等，约 4 次，缺固定同步机制。

1. 场景判定

  • 触发条件：管理层决定部门新设/更名/合并、负责人变更、汇报线调整；飞书审批上线或改版；发现审批卡点源于审批人错置。
  • 典型说法：「飞书的审批设置需要明确下对应角色」「直属上级只能写一个人」「请于截止时间前填写反馈表单」「之后制度上有调整或者切分，辛苦提前同步」
  • 判断问题：这次变化是否改变了某人的部门归属、直属上级或某审批节点的审批人？是 → 走本流程。
  • 不归本流程管：单个新员工入职拉入部门 → 请走 HR-05；因主体切分带来的制度调整 → 请走 HR-01；财务类审批流本身的设计 → 由财务负责（FIN 对应流程）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
架构维护人 维护架构表、配置飞书通讯录与审批人 R 人事负责人（当前：黄莹·推断待确认）
调整决策人 决定调整方案与生效时间、签发通知 A CEO（当前：邴龙志·推断待确认）
管理层补充 补充直属上级、部门负责人 C CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
审批流设计 按架构设计财务等审批流 C 财务（当前：陈雅萍、黄梦婷·推断待确认）
部门负责人 与本部门成员逐一沟通、完成交接 R 各部门负责人
综合部 通知发布协助、反馈表汇总 C 综合部负责人（当前：赵雪冰·推断待确认）
关联主体负责人 接收涉及本主体的调整 I 跃竞/协游负责人（当前：徐莉·推断待确认）
全体员工 阅读通知、填写反馈 I 全员

3. 办之前请准备

  • 调整方案：涉及部门、新旧名称、新负责人、生效时间。
  • 当前组织架构表（A～F 列为飞书设置字段）。
  • 受影响人员清单（含人员类型：全职/实习/线上实习/外包/荣誉岗）。
  • 受影响审批流清单（考勤、报销、付款、用章等各节点审批人）。
  • 架构问题反馈表单。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定调整方案与生效日 决策人 生效日前 7 个自然日 会议/飞书文档 调整决定 👤人工判断
2 更新架构表：岗位、直属上级（只写一人）、部门负责人、人员类型 架构维护人 决定后 1 个工作日内 飞书 wiki 架构表 架构表新版 🔧飞书固化
3 管理层补全空缺的直属上级与负责人 管理层 2 个工作日内 架构表评论 无空缺的架构表 👤人工判断
4 全员发布调整通知（内容、生效时间、反馈截止时间） 决策人 生效日前 3 个自然日 全员群 调整通知 🔧飞书固化
5 部门负责人与受影响成员逐一沟通、完成交接 部门负责人 通知后 5 个工作日内 面谈 沟通完成确认 👤人工判断
6 飞书后台同步部门、直属上级、部门负责人 架构维护人 生效日前 1 个工作日完成 飞书管理后台 通讯录同步 🔧飞书固化
7 复核受影响审批流审批人，并通知财务等审批流设计方 架构维护人、财务 生效日当天 飞书审批 审批人复核记录 🔧+👤
8 员工填反馈表，汇总问题并处理 综合部 反馈截止后 2 个工作日内 飞书表单 反馈汇总与处理结果 🤖自动化
9 涉及关联主体的调整同步对方负责人；归档 架构维护人 生效后 2 个工作日内 飞书文档 同步记录、归档 🔧飞书固化

5. 交付物与模板

  • 交付物：组织架构表新版、调整通知、飞书通讯录与审批人配置、审批人复核记录、反馈汇总。
  • 建议模板/表单：
    • 架构表字段：姓名、主体、部门、岗位、直属上级（唯一）、部门负责人、人员类型、办公地点、生效日期、变更备注。
    • 调整通知字段：调整内容、新负责人、生效时间、交接要求、反馈方式与截止时间。
    • 审批人复核表字段：审批流名称、节点、原审批人、新审批人、复核人、复核时间。

6. 异常与升级

  • 直属上级或部门负责人空缺 → 维护人在架构表标红并@决策人 → 2 个工作日内仍空缺，临时由上一级负责人代审。
  • 生效日飞书设置未完成导致审批卡住 → 维护人当天手动转交审批 → 报综合部负责人。
  • 外包、荣誉岗、线上实习生身份不明 → 暂不纳入审批节点，报决策人确认。
  • 关联主体（跃竞/协游）未提前收到调整 → 维护人 1 个工作日内补发汇总文件并致歉说明。

7. 衡量指标

  • 同步及时率：飞书设置完成日 ≤ 生效日的次数 / 调整次数，目标 100%。
  • 审批卡点数：因审批人错置导致的卡单次数，目标 0。
  • 架构外人员数：未归入任何部门的在职飞书账号数，目标 0。
  • 反馈问题闭环时长：反馈截止到全部处理的工作日，目标 ≤ 3 天。

8. 低效诊断

  • 现象：飞书审批上线前才发现直属上级空缺、部门负责人未在表中体现｜依据：「【模态】综合部」2026-04
  • 现象：调整生效后才确认飞书后台设置，审批人短期错位｜依据：「模态集团全员群」2026-07
  • 现象：因架构调整频繁，相关通知被迫延后发布｜依据：「【模态】综合部」2026-08
  • 现象：关联主体的制度切分、人事制度未提前同步，对方追要汇总文件｜依据：「模态-协游沟通群」2026-09
  • 现象：外包、荣誉岗、线上实习生在架构中身份标注不一｜依据：「【模态】综合部」2026-04

9. 分支变体

  • 全职、实习：正常纳入部门与审批节点。
  • 线上实习生、外包、荣誉岗：架构表单独标注人员类型，默认不担任审批节点。
  • 跃竞/协游等关联主体：制度、福利、架构切分需提前同步该主体负责人，并单独出汇总文件。
  • 子公司人员：放入对应子公司部门，避免停留在架构最外层。

10. 待确认问题

  • 飞书通讯录是否作为唯一架构源，组织架构 wiki 表是否改为由通讯录导出？
  • 飞书管理员权限由谁归口（人事、CTO、IT 运维目前都有操作）？
  • 生效日前 3 天发通知、前 1 天完成设置是否可行？
  • 外包、荣誉岗是否需要进入飞书组织？
  • 关联主体同步的对接人是谁？
HR-03HC申请与人力成本统计待新建81

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：部门需要新增人员编制（HC），或管理层索要人员清单、岗位清单、人力成本数据时启动，按统一模板测算、审批并输出花名册与成本表。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——申请部门负责人（当前：杨萌、徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；审批——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 部门提出 HC 需求 → ② 按模板测算预算与 ROI → ③ HR 核对人力成本基数 → ④ CEO 审批 → ⑤ 获批转招聘 → ⑥ 花名册/成本表月度更新 → ⑦ 按需出数据报表
  • 交付结果：已审批的 HC 申请单；实时更新的员工花名册与月度人力成本表；按需输出的人员/岗位/成本报表。
  • 状态依据：HC 申请目前靠口头询问，无申请流程与模板；花名册与成本表已有但分散在 xlsx 与多维表格，2026-01～09 管理层多次临时索要人员清单、档案、岗位清单与成本数据，HR 需现算、重发，约 8 次。

1. 场景判定

  • 触发条件：部门负责人提出增加人手；管理层要求查看人员清单、平均年龄、部门岗位、人员成本；预算编制或月度经营复盘需要人力成本数据。
  • 典型说法：「HC 怎么申请」「我们组现在人力成本是多少，拉个单子」「现在的人事和岗位清单发一下」
  • 判断问题：是要“增加编制”（走 HC 申请）还是“要现有人员数据”（走数据输出）？两者都由本流程管。
  • 不归本流程管：HC 获批后的招聘执行 → 请走 X-RCT-01（招聘需求提报与 HC/预算/优先级管理）；个人薪酬档位与调薪 → 请走 HR-09；转正定薪 → 请走 HR-08。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据与流程维护 维护花名册、成本表，核对 HC 测算，出报表 R 人事负责人（当前：黄莹·推断待确认）
HC 申请人 说明岗位需求、按模板测算预算与 ROI R 申请部门负责人（当前：杨萌、徐莉·推断待确认）
规则口径 给出测算口径与模板示范 C CTO（当前：丁震宇·推断待确认）
成本核对 提供工资、社保公积金实发数据 C 财务（当前：待指定）
审批人 审批 HC 与预算 A CEO（当前：邴龙志·推断待确认）
招聘执行 获批后启动招聘 I 招聘专员（当前：待指定）

3. 办之前请准备

  • 岗位说明：岗位名称、职责、所属组、汇报对象、期望到岗时间、用工类型。
  • 预算测算：拟定薪资区间、年度人力成本、对应产品/项目 ROI。
  • 本部门现有人员与成本清单（由 HR 提供最新版本）。
  • 已有的部门预算与已占用 HC 数。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写 HC 申请（岗位、数量、理由、预算、ROI） 申请人 需求确定后 2 个工作日内 飞书审批「HC 申请」 HC 申请单 🔧飞书固化
2 提供本部门最新人员与成本基数 人事负责人 申请提交后 1 个工作日内 多维表格 部门成本快照 🤖自动化
3 核对测算口径（与统一模板一致） 人事负责人、CTO 1 个工作日内 飞书审批评论 核对意见 👤人工判断
4 审批 HC 与预算 CEO 2 个工作日内 飞书审批 通过/驳回/调整 👤人工判断
5 获批后转招聘并登记在招清单 人事负责人 审批通过当日 多维表格 在招清单条目 🔧飞书固化
6 入职/离职/调岗当日更新花名册 人事负责人 变动当日 多维表格（人员信息 base） 实时花名册 🔧飞书固化
7 拉取上月工资与社保数据，更新月度人员成本表 人事负责人、财务 每月 10 日前 多维表格 月度人员成本表 🔧+🤖
8 管理层临时要数时，从仪表盘直接导出 人事负责人 收到需求后 4 个工作小时内 多维表格仪表盘 报表 🤖自动化

5. 交付物与模板

  • 交付物：HC 申请单、在招清单、员工花名册、月度人员成本表、人员/岗位/成本仪表盘。
  • 建议模板/表单：
    • HC 申请：部门、岗位、数量、用工类型、期望到岗、薪资区间、年度成本、ROI 说明、替补/新增。
    • 花名册：姓名、主体、部门、岗位、直属上级、人员类型、入职日期、转正日期、合同到期日、状态。
    • 成本表：部门、人数、应发合计、社保公积金、补贴、月度合计（按部门汇总，个人明细限权查看）。

6. 异常与升级

  • 申请人测算口径与模板不一致 → HR 退回并附示范版本 → 2 次退回仍不一致，报 CTO 协助。
  • CEO 审批超过 2 个工作日 → HR 提醒一次 → 再超 2 个工作日报综合部负责人。
  • 花名册与工资表数据不一致 → HR 以财务实发数据为准，1 个工作日内修正并记录原因。
  • 未经审批先招人 → 暂停 offer 发放，补走 HC 申请。

7. 衡量指标

  • HC 审批周期：提交到审批完成的工作日，目标 ≤ 3 天。
  • 花名册准确率：抽查与实际在职一致的比例，目标 100%。
  • 临时要数响应时长：需求到交付的工作小时，目标 ≤ 4 小时。
  • 月度成本表按时率：每月 10 日前完成的月份占比，目标 100%。

8. 低效诊断

  • 现象：花名册、人员信息 base、成本表分散，管理层临时要数需现算、重复发送｜依据：「模态人事大主管」2026-02、「模态人事大主管」2026-06
  • 现象：员工名单以月度 xlsx 文件流转，版本多、无法实时反映入离职｜依据：「模态人事大主管」2026-01
  • 现象：月度人员成本表与成本估算表并存，取数周期与口径需反复说明｜依据：「模态人事大主管」2026-09
  • 现象：HC 申请没有入口与模板，测算口径不统一（本条为流程缺口判断，聊天中未见成文做法）｜依据：「模态人事大主管」2026-06

9. 分支变体

  • 新增 HC：走完整步骤 1～5。
  • 组内人力成本核算：跳过审批，直接走步骤 2、7、8。
  • 管理层临时要人员名册/岗位清单/在招清单：走步骤 8。
  • 子公司 HC：由子公司负责人提交，CEO 审批（待确认）。

10. 待确认问题

  • HC 审批是否只需 CEO 一级，还是先经条线负责人？
  • ROI 测算口径以哪个部门的版本为统一模板？
  • 个人成本明细的查看权限范围（管理层/财务/HR）？
  • 月度成本表由 HR 还是财务主导更新？
  • 是否需要每月固定向管理层推送人员与成本仪表盘？
HR-04用工主体判定与劳动合同/协议签署待新建180

状态：待新建｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：新员工入职、补签、转正改签或出现特殊用工（在读学生、未成年人、远程试用、另有劳动关系、多公司法人入职、对外任职）时启动，确定劳动关系主体与用工类型，签署劳动合同/实习/劳务协议及保密、竞业、对外任职承诺。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——法务负责人（当前：李瑶·推断待确认）、行政（用印）（当前：侯明月·推断待确认）、用人部门负责人（当前：徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 收集用工信息 → ② 判定用工类型 → ③ 判定合同主体 → ④ 特殊情形法务咨询 → ⑤ 拟定合同并群内审核 → ⑥ 用章审批 → ⑦ 入职当日签署 → ⑧ 归档与主数据登记
  • 交付结果：主体与类型正确、双方签署并盖章的劳动合同/实习协议/劳务协议，配套保密、竞业、知识产权、对外任职承诺；员工主数据中的主体、合同类型、期限、到期日。
  • 状态依据：主体由管理层口头决定，用工类型边界靠口头；2026-02～10 出现劳动关系与社保缴纳主体不一致、入职近 2 个月才补签、“以前都没签过合同”、未成年人用工无政策、先入职后补资料等，约 15 次，无判定规则与检查清单。

1. 场景判定

  • 触发条件：确定录用并约定到岗日；员工调动主体；实习转正；涨薪需书面确认；候选人为在读学生、16～18 周岁、另有劳动关系、远程试用、在外开设公司或兼职；员工申请在职证明。
  • 典型说法：「合规来讲，在哪边就签在哪边」「签劳动合同还是劳务？」「新员工合同都提前准备，发群里审完再打印签」「该备好的合规材料得备好」
  • 判断问题：这个人与哪个主体建立什么关系？社保交在哪？是否存在学生身份、年龄、竞业或利益冲突风险？
  • 不归本流程管：工位、账号、设备等入职准备 → 请走 HR-05；实习生出勤与薪酬结算 → 请走 HR-07；转正评估 → 请走 HR-08；Demo 稿酬（成果采购）派单与验收 → 请走 研发（暂无对应 SOP，待新建），相关合作协议拟定 → 请走 LEG-05；合同模板本身的起草 → 请走 LEG-01（合同模板库建设、版本维护与发布）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
合同经办 收集信息、判定类型、拟合同、组织签署、归档 R 人事负责人（当前：黄莹·推断待确认）
主体与特殊安排决策 拍板合同主体、特殊用工 A CEO（当前：邴龙志·推断待确认）
合规顾问 特殊用工、在职证明、利益披露、承诺函条款 C 法务负责人（当前：李瑶·推断待确认）
字段确认 确认岗位名称、试用期、起薪、入职日期 C 用人部门负责人（当前：徐莉·推断待确认）、CTO（当前：丁震宇·推断待确认）
用印 用章审批后盖章 R 行政（当前：侯明月·推断待确认）
员工 提供材料、签署、如实披露 I 新员工

3. 办之前请准备

  • 候选人信息：身份证、最高学历与毕业时间（在读需学校与预计毕业时间）、出生日期、现单位社保状态、离职证明。
  • 对外任职/持股/兼职情况自述（用于利益冲突与竞业判断）。
  • 录用信息：所属业务线、岗位名称、试用期、起薪、入职日期、工作方式（现场/远程）。
  • 合同模板：劳动合同、实习协议、劳务协议、保密协议、竞业协议、对外任职承诺函、监护人知情书。
  • 用工类型与主体决策表（见第 9 节）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过入职表单一次性采集合同字段与身份信息 合同经办 到岗日前 5 个工作日 飞书表单/多维表格 合同字段记录 🔧飞书固化
2 对照决策表判定用工类型（劳动/实习/劳务/兼职） 合同经办 1 个工作日内 决策表 类型结论 👤人工判断
3 判定合同主体，确保与社保缴纳主体一致；非常规的报决策人 合同经办、决策人 1 个工作日内 决策表 主体结论 👤人工判断
4 特殊情形（未成年、另有劳动关系、多公司法人、利益冲突）提交法务意见 合同经办、法务 法务 2 个工作日内回复 人事&法务群 法务意见 👤人工判断
5 向用人负责人确认主体、岗位、试用期、起薪、入职日期 合同经办 到岗日前 3 个工作日 飞书文档 确认字段 🔧飞书固化
6 拟定合同及配套协议草稿，发群审核 合同经办 到岗日前 3 个工作日 飞书文档 合同草稿 🤖自动化
7 发起用章用印申请（可按批集中） 合同经办 到岗日前 2 个工作日 飞书审批「用章用印申请」 审批通过 🔧飞书固化
8 打印、盖章，入职当日完成全部签署 合同经办、行政 到岗当日 纸质/电子签 签署合同 🔧飞书固化
9 登记主体、类型、期限、到期日并归档原件与扫描件 合同经办 签署后 2 个工作日内 多维表格、档案柜 合同台账 🔧+🤖
10 合同到期前 30 天提醒续签/改签 合同经办 到期前 30 天 多维表格提醒 续签任务 🤖自动化

5. 交付物与模板

  • 交付物：签署完成的合同及配套协议、合同台账、法务意见记录（特殊情形）。
  • 建议模板/表单：
    • 合同字段表：姓名、证件号（限权）、主体、用工类型、岗位、试用期、起薪、入职日期、合同期限、社保缴纳主体、签署日期、到期日。
    • 用工类型决策表：情形 → 合同类型 → 是否缴社保 → 必附协议（保密/知识产权/竞业）→ 是否进飞书。
    • 对外任职披露表：是否在外任职/持股/兼职、业务是否与公司相关、披露日期。

6. 异常与升级

  • 到岗当日合同未签 → 当天不开通生产权限，经办人 1 个工作日内补签 → 超过 3 个工作日报综合部负责人。
  • 表单入职日期与实际不一致 → 以实际到岗日为准，经办人与本人核对后修正合同。
  • 主体与社保缴纳主体不一致 → 经办人 1 周内报决策人确定整改方案，必要时咨询法务。
  • 候选人仍在原单位缴社保或存在利益冲突 → 暂缓签署，法务 2 个工作日内给意见。
  • 发现竞业、知识产权条款缺失 → 3 个工作日内补签。

7. 衡量指标

  • 到岗当日签约率：到岗当天完成签署的人数 / 入职人数，目标 100%。
  • 主体一致率：合同主体与社保缴纳主体一致的人数占比，目标 100%。
  • 合同信息返工率：因字段错误重拟的合同占比，目标 ≤ 5%。
  • 特殊用工法务意见覆盖率：特殊情形中有书面法务意见的占比，目标 100%。

8. 低效诊断

  • 现象：主体靠口头决定，劳动关系主体与实际管理、社保缴纳主体错位，需反复追问｜依据：「模态人事大主管」2026-04、「模态人事大主管」2026-08、「模态人事大主管」2026-10
  • 现象：劳动/实习/劳务/兼职边界靠口头，合同发起与归档人起初不明｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-04
  • 现象：入职后近 2 个月才补签合同，入职日期在表单与实际不一致需口头核对｜依据：「行政人事对接群」2026-02
  • 现象：未成年候选人用工无政策，临时查法规、讨论替代方案｜依据：「技术岗招聘沟通」2026-04
  • 现象：先入职、资料后补；在职证明、利益披露等每次个案咨询，无模板｜依据：「人事&法务群」2026-10

9. 分支变体

  • 主体：按业务线归属签对应主体（模态跃迁/鼎慧文跃/跃竞协游/某工程咨询客户/苏州模态）；跃竞人员签跃竞主体；异地员工放对应子部门；人数达到一定规模时需考虑残疾人就业比例等合规因素。
  • 正式员工：劳动合同+保密+知识产权，按需竞业；涨薪需补书面确认。
  • 在校学生：签实习协议；非在校学生不得签实习协议，改签劳务或劳动合同（实习细则见 HR-07）。
  • 远程试用/到岗晚：可先签短期劳务协议（如 3 个月），劳务不缴社保；正式到岗时重新按正职签约。
  • 16～18 周岁：仅可兼职，每天不超过 4 小时、22:00～6:00 禁止工作，需向人社部门备案、定期体检、签监护人知情书；16 周岁以下不得用工，可考虑稿酬/成果采购，由法务审核。
  • 外部协作人员、外包、个体驻场：不属于员工，签合作协议另存，不进飞书组织。
  • 在职对外任职/开设公司：签对外任职承诺函，入职时统一披露、每年更新。
  • 在职证明：据实开具、写明用途，经法务审阅后盖章。

10. 待确认问题

  • 业务线→主体的对应关系是否可以成文为决策表？由谁最终拍板？
  • 特殊用工法务回复时限 2 个工作日是否可行？
  • 是否引入电子签替代纸质签署？
  • 对外任职披露是否对全员每年执行一次？
  • 未成年/高中生合作是否一律不建立劳动或劳务关系，统一走成果采购？
HR-05新员工入职准备与办理待优化225

状态：待优化｜证据：有证据（卡片 21 张 / 会话 24 个）｜优先级：频5 × 耗3 × 跨5 × 险3

  • 适用场景：候选人确认到岗日后启动，由 HR 发出入职通知单，统一协调工位、电脑、飞书账号/组织层级/席位、邮箱、代码仓库与终端软件、门禁工牌、拉群、福利告知，直至到岗当天接待完成。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、行政（当前：胡则瑾、侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、用人部门负责人；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 用人部门提交入职通知单 → ② HR 发候选人入职通知 → ③ 采集入职信息并核对证件 → ④ 设备采购/调配 → ⑤ 工位、门禁、名片 → ⑥ 飞书席位与组织归位 → ⑦ 账号与权限开通 → ⑧ 到岗接待与介绍 → ⑨ 清单核验
  • 交付结果：入职清单全部勾完：合同已签、工位与设备到位、飞书账号在正确部门与直属上级下、邮箱/代码仓库/终端软件/产品账号已开通、已拉入对应群、导师已指定、新人已在部门群介绍。
  • 状态依据：已有入职信息表、用章审批、研发新人首日安排文档、研发福利清单，但无统一入职清单；2026-01～09 反复出现新人到岗无座位/电脑、飞书未划分部门或在架构最外层、邮箱漏分配、飞书席位每周临时加购、HR 被临时告知入职、账号密码群内明文等，约 30 次。

1. 场景判定

  • 触发条件：候选人接受录用并约定到岗日；实习生/线上实习生/子公司人员加入；外部协作人员需要开通部分权限。
  • 典型说法：「新人明天 10 点来了坐哪」「没人和我说过，入职资料我需要提前准备」「飞书组织层级没配好，新来这位在最外面」「入职相关流程怎么说？签协议、入飞书、办公设备这些」
  • 判断问题：到岗日、所属组、直属上级、导师、用工类型是否已确定？确定 → 立即提交入职通知单走本流程。
  • 不归本流程管：合同主体与类型判定、签署 → 请走 HR-04；入职培训、导师带教与首周任务 → 请走 HR-06；设备库存与领用登记 → 请走 ADM-03（新员工入职行政准备（工位、电脑、领用登记））/ ADM-27（IT设备到货验收、入库登记与调配变更）；候选人招聘与 offer → 请走 X-RCT-17（定薪谈薪、录用审批与 Offer 发放）；接受 offer 到入职首日的衔接 → 请走 X-RCT-19。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
入职统筹 发通知、采集信息、派任务、核验清单 R/A 人事负责人（当前：黄莹·推断待确认）
招聘协同 传递候选人信息、联系候选人 R HR 招聘专员（当前：张欣怡·推断待确认）
用人部门 提交入职通知单、确定组别/直属上级/导师 R 用人部门负责人（当前：杨萌、王皓南、徐莉、陈梦琪·推断待确认）
工位与行政 工位、门禁/工牌、名片、接待 R 行政（当前：胡则瑾、侯明月·推断待确认）
设备与终端 电脑配置、IOA、VPN 客户端、办公网络 R IT 运维（当前：杨明学·推断待确认）
研发权限 邮箱、Gitea/GitHub、开发资源授权 R CTO（当前：丁震宇·推断待确认）
席位采购 飞书席位不足时购买 C 财务负责人（当前：黄梦婷·推断待确认）
兜底协调 工位紧张、跨部门卡点 C 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 入职通知单：姓名、岗位、所属组、直属上级、导师、用工类型、到岗日与时间、办公点（eg/905/K11 等）、设备需求、所需账号清单。
  • 候选人简历与联系方式。
  • 入职信息表链接（飞书多维表格）及需携带材料清单。
  • 当前飞书剩余席位数、空余工位表、可用电脑库存。
  • 按岗位的账号开通清单（研发/测试/运维/运营/销售/职能）。
  • 研发新人首日安排文档、福利清单、常用群与入口清单。

4. 步骤

（D = 到岗日）

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交入职通知单（组别、直属上级、导师、设备、账号） 用人部门负责人 D-7 前 飞书审批「入职通知单」 通知单 🔧飞书固化
2 发候选人入职通知（地点、上班时间、携带材料、社保起缴规则） 入职统筹 D-5 前 模板消息/邮件 入职通知 🔧+🤖
3 候选人填入职信息表，HR 核对证件信息 入职统筹 D-3 前 飞书多维表格 已核对信息 🔧飞书固化
4 设备采购或调配需求报 IT，按标准配置 IT 运维 需求提前 7 天报，D-1 前到位 飞书审批（设备申请） 配置好的电脑 🔧飞书固化
5 确认工位、门禁/工牌、名片（子公司区分主体） 行政 D-2 前 座位表 工位与门禁 🔧飞书固化
6 检查飞书席位，不足时通知财务购买 入职统筹、财务 D-3 前 飞书管理后台 可用席位 🔧+🤖
7 邀请飞书账号并放入正确部门与直属上级 入职统筹 D-1 前 飞书管理后台 组织归位 🔧飞书固化
8 按岗位清单开通邮箱、代码仓库、VPN 客户端、IOA、产品账号；凭据私密发送并要求首次登录改密 IT 运维、CTO D-1 前，最迟 D 当天上午 飞书任务 开通记录 🔧+🤖
9 到岗接待：签合同（HR-04）、领设备、福利与作息告知、发入职文档 入职统筹、行政 D 当天上午 现场 签到与领用记录 👤人工判断
10 拉入部门群与对应群；部门群发布介绍（姓名、职责、座位、导师） 用人部门负责人 D 当天 飞书群 到岗介绍 🔧+🤖
11 核验入职清单，未完成项指派并追踪 入职统筹 D+1 飞书任务 清单 100% 完成 🔧飞书固化

5. 交付物与模板

  • 交付物：入职通知单、候选人入职通知、入职信息记录、入职清单（全部勾完）、设备领用记录、账号开通记录、到岗介绍消息。
  • 建议模板/表单：
    • 入职通知单：姓名、岗位、主体、所属组、直属上级、导师、用工类型、到岗日期与时间、办公点、电脑需求、账号清单、备注。
    • 入职清单任务：合同、工位、电脑、门禁/工牌、名片、飞书席位、飞书部门、邮箱、Gitea/GitHub、VPN 客户端、IOA、产品账号、部门群、福利告知、导师确认；每项带负责人与截止日。
    • 候选人入职通知：报到地点与时间、日常上班时间、携带材料、社保起缴说明、联系人。

6. 异常与升级

  • 用人部门未提前 7 天提交通知单 → HR 当天补收并标注“紧急”，到岗日不可调整时，未就绪项先用备用设备/临时工位 → 同一部门一个月内第二次发生报综合部负责人。
  • 工位不足 → 行政 1 个工作日内给临时方案（会议室/共享区）→ 无法解决报综合部负责人。
  • 设备未到 → IT 提供备用机；无备用机时新人先做文档学习，到货当天补配。
  • 飞书席位不足 → 财务 1 个工作日内购买；建议按季度预测批量采购。
  • 新人到岗后发现组织层级/账号缺失 → 当天补齐，并在清单模板中追加该项。
  • 凭据在群内明文发送 → 立即重置密码，由开通人私密重发。

7. 衡量指标

  • 首日就绪率：到岗当天清单全部完成的人数 / 入职人数，目标 ≥ 95%。
  • 提前通知率：D-7 前提交入职通知单的占比，目标 ≥ 90%。
  • 组织归位及时率：D-1 前进入正确飞书部门的占比，目标 100%。
  • 入职漏项数：到岗后才发现的缺项（邮箱、账号、权限等）次数，目标每月 0。
  • 新人入职体验评分：首周问卷 1～5 分，目标 ≥ 4。

8. 低效诊断

  • 现象：HR 被临时告知入职，资料来不及准备；新人到岗同事不知是谁｜依据：「墨跃启智招聘」2026-04、「技术岗招聘沟通」2026-02
  • 现象：新人到岗才问坐哪、无电脑可用，工位紧张临时占会议室｜依据：「鼎慧人事」2026-01、「鼎慧产研决策部」2026-02、「墨跃启智招聘」2026-04
  • 现象：飞书未划分部门、停留在组织最外层，导致审批与申请流程打不开｜依据：「模态人事大主管」2026-03、「技术岗招聘沟通」2026-05、「跃迁基座」2026-03
  • 现象：飞书席位每周“+5”临时加购，重复四次｜依据：「【模态】综合部」2026-07
  • 现象：邮箱、产品账号、终端软件、内网账号到岗后才补，账号逐一向不同人索要｜依据：「模态人事大主管」2026-09、「系统测试招聘」2026-07、「鸽子群模态分群」2026-04、「工程咨询产研」2026-02
  • 现象：入职通知内容不全（上班时间、地点），每次流程不同｜依据：「模态人事大主管」2026-01、「鼎慧产研决策部」2026-01
  • 现象：账号密码在群内告知，存在泄露风险｜依据：「技术岗招聘沟通」2026-03

9. 分支变体

  • 正式员工：完整清单；研发按研发福利与设备标准配置，超标准差价自付（标准待确认）。
  • 在校实习生：转正前自带电脑并安装终端安全软件，满 3 个月且转正通过后配公司电脑；观察期与薪酬见 HR-07。
  • 线上实习生：不办现场入职，拉群对接，开通最小权限账号。
  • 兼职/外部协作人员：不配设备，不进飞书组织，使用飞书外部群或微信群。
  • 子公司（深圳、苏州、上海、跃竞）：进对应飞书组织与群，不进总部全员群/闲聊群；名片区分主体；需要时开独立代码组织。
  • 研发：额外开通代码仓库、开发机、AI 工具、VPN 客户端；非研发：开通产品账号与测试环境账号。
  • 多办公点：入职通知单注明报到地点，模态空间报到的上午先到 HR 处签合同、交资料、领电脑。

10. 待确认问题

  • 入职通知单由用人部门负责人还是招聘专员提交？D-7 提前量是否可行？
  • 邮箱、Gitea、飞书管理员权限是否能从 CTO 下放给 IT 运维，减少单点？
  • 飞书席位是否按季度预测批量采购，预算谁审？
  • 研发电脑标准、实习生配机规则是否已成文？
  • 设备库存与领用登记是否正式移交行政，由谁维护台账？
HR-06新人入职培训、带教与首周上手待新建108

状态：待新建｜证据：有证据（卡片 18 张 / 会话 13 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：新员工或实习生到岗后启动，完成通用入职培训（价值观、架构、制度、作息）、指定导师、发放岗位学习资料与环境指引、安排首周任务并明确权限边界，直到 30 天回顾。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——综合部负责人（当前：赵雪冰·推断待确认）、用人部门负责人（当前：杨萌、王皓南·推断待确认）、CTO（当前：丁震宇·推断待确认）、导师（当前：岳阳、宋祺睿、陈晖·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 到岗前指定导师与首周任务 → ② 发放入职资料包 → ③ 首日作息与制度告知 → ④ 岗位环境与规范上手 → ⑤ 首周任务与每日跟进 → ⑥ 集中入职培训 → ⑦ 首周与 30 天回顾
  • 交付结果：新人入职交接卡（导师、首周任务、权限边界）；首周任务完成记录；集中入职培训签到；30 天回顾记录（作为转正评估输入）。
  • 状态依据：已有研发新人首日安排、Git 规范、后端开发规范、AI 编码指北、新人入职素材等零散文档，但 2026-01～10 反复出现“没有入职培训”、新人不知道今天做什么、不知找谁、导师不明确、实习生无人布置任务、作息规则靠群里问等，约 40 次，无统一培训与带教机制。

1. 场景判定

  • 触发条件：新人到岗（含实习、转岗、借调）；新人发问“今天做什么”“找谁”；部门发现新人空转。
  • 典型说法：「请问今天的工作安排大概是什么呀」「没有入职培训」「入职到现在全靠口口相传」「提前设计一下给他安排啥工作吧」
  • 判断问题：新人是否已有明确导师、首周任务和需要掌握的规则清单？任一缺失 → 走本流程。
  • 不归本流程管：工位、设备、账号开通 → 请走 HR-05；转正考核 → 请走 HR-08；积分制度宣贯 → 请走 HR-18；销售专业培训 → 由销售部门负责。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
培训统筹 维护资料包与通用模块，首日告知，跟踪回顾 R/A 人事负责人（当前：黄莹·推断待确认）
集中培训组织 半月/月度集中培训，排讲师 R 综合部负责人（当前：赵雪冰·推断待确认）
用人部门负责人 到岗前指定导师、设计首周任务 R 用人部门负责人（当前：杨萌、王皓南·推断待确认）
导师 每日跟进、答疑、把关权限边界 R 导师（当前：岳阳、宋祺睿、陈晖·推断待确认）
研发材料 提供研发通用材料与规范 C CTO（当前：丁震宇·推断待确认）
IT 支持 环境、终端、网络问题 C IT 运维（当前：杨明学·推断待确认）
新人 完成任务、每日简报、补充 FAQ I 新员工/实习生

3. 办之前请准备

  • 通用资料包：作息与考勤规则、请假与报销入口、福利清单、组织架构与“问题找谁”表、常用群与产品入口清单、FAQ。
  • 岗位资料包：研发（仓库结构、Git 规范、开发规范、AGENTS.md、AI 工具指南、开发环境配置说明）；测试；运维；运营；销售；职能。
  • 入职交接卡模板与首周任务模板。
  • 集中培训排期与讲师名单。

4. 步骤

（D = 到岗日）

# 动作 执行人 时限 工具/系统 产出 提效方式
1 指定导师、填写入职交接卡（岗位、首周任务、权限边界） 用人部门负责人 D-5 前 多维表格 入职交接卡 🔧飞书固化
2 向导师和新人推送通用+岗位资料包 培训统筹 D-1 飞书知识库、机器人 资料包链接 🤖自动化
3 首日讲清作息（上下班、弹性规则、午休、打卡）、请假报销入口、福利、问题找谁 培训统筹 D 当天 30 分钟 线下/飞书会议 首日告知签到 🔧+🤖
4 导师带新人跑通环境、讲仓库与规范（研发须完成 Git 101） 导师 D～D+2 知识库、代码仓库 环境跑通确认 👤人工判断
5 执行首周任务，新人每日简报，导师当日反馈 新人、导师 D+1～D+5 每日下班前 飞书任务/日报 每日进度 🔧飞书固化
6 新人遇到资料未覆盖的问题记入 FAQ，由文档负责人更新 新人、导师 发现后 2 个工作日内更新 飞书知识库 FAQ 新条目 🤖自动化
7 参加集中入职培训（价值观、架构、部门职能、产品、制度） 集中培训组织 每半月或每月一次 飞书会议 培训签到、录屏 🔧飞书固化
8 首周回顾：导师与新人 15 分钟面谈，确定次月目标 导师 D+5 面谈记录 首周回顾 👤人工判断
9 30 天回顾，结果转给 HR 作为转正评估输入 导师、培训统筹 D+30 多维表格 30 天回顾 🔧飞书固化

5. 交付物与模板

  • 交付物：入职交接卡、资料包、首日告知签到、每日简报、首周回顾、集中培训签到、30 天回顾。
  • 建议模板/表单：
    • 入职交接卡：新人、岗位、所属组、导师、首周任务（3～5 项，含验收标准）、需要的权限、禁止独立操作事项、回顾日期。
    • 每日简报：今日完成、遇到问题、明日计划、需要的协助。
    • 30 天回顾：任务完成度、上手程度、导师评价、改进点、是否需调整岗位。

6. 异常与升级

  • 到岗前未指定导师 → HR 在 D-3 提醒用人部门负责人 → D 当天仍无，由部门负责人本人临时带教并报 CTO/部门上级。
  • 导师因出差等原因无法带教 → 导师 1 个工作日内报部门负责人指定替补。
  • 新人连续 2 天无任务或空转 → 导师须当日汇报部门负责人重新派活；新人也应主动上报。
  • 实习生/新人需要做生产部署、权限变更 → 必须导师审核后执行，不得独立操作。
  • 培训资料过期或缺失 → 新人反馈后，文档负责人 2 个工作日内更新。

7. 衡量指标

  • 导师到位率：D-1 前指定导师的人数占比，目标 100%。
  • 首日任务明确率：首日拿到首周任务的新人占比，目标 100%。
  • 环境跑通时长（研发）：到岗到本地开发环境跑通的工作日，目标 ≤ 2 天。
  • 集中培训覆盖率：入职 30 天内参加集中培训的占比，目标 ≥ 95%。
  • 新人重复提问数：同类问题在群内被重复问的次数，目标逐月下降。

8. 低效诊断

  • 现象：公司层面没有入职培训，产品新人靠临时书单、实习生被遗忘｜依据：「鼎慧产研决策部」2026-09、「董事会专项沟通群」2026-07
  • 现象：新人从群聊获知作息、午休、弹性规则，口径不一｜依据：「鸽子群模态分群」2026-04、「鸽子群模态分群」2026-02
  • 现象：导师临时看谁有空指定，核心成员忙时无人可带，实习生独立做生产部署出问题｜依据：「鼎慧产研决策部」2026-05
  • 现象：新人不知今天做什么、找谁拉群、某系统在谁手上｜依据：「Leap产研测」2026-10、「鼎慧产研决策部」2026-04
  • 现象：开发环境配置、仓库说明、账号用法散落群里，每次口头重复讲｜依据：「工程咨询产研」2026-02、「工程咨询产研」2026-03、「技术部」2026-01
  • 现象：新人入组无人介绍，团队不知其岗位与来历；节后入职的产品新人无人通知｜依据：「Leap产研决策部」2026-09、「鼎慧产研决策部」2026-04
  • 现象：实习生长期无人布置任务，进度信息不透明｜依据：「Leap产研决策部」2026-10、「鼎慧产研决策部」2026-07

9. 分支变体

  • 研发：Git 101 必修、开发规范、AI 编码工具指南、环境一键脚本；新人首周可从工单修复入手，但需导师把关。
  • 测试：先学业务 2～3 天再搭测试框架；跨组共用测试先服务一组再轮转。
  • 运维：先跑通配置再沉淀文档；首周跟随现场部署。
  • 运营/产品：产品入口清单、反馈表单、内容规范；导师为对应产品负责人。
  • 实习生：竞品分析等考察任务+每日进度文档；不得独立负责生产变更。
  • 子公司成员：额外提供“业务问题找谁”表与入口文档。

10. 待确认问题

  • 主责是否为 HR（通用部分）+ 用人部门负责人（岗位部分）分段负责？
  • 集中入职培训按半月还是按月？讲师轮值名单由谁定？
  • 导师是否需要书面指定并有带教激励？
  • 研发资料包由谁维护（CTO 指定文档负责人）？
  • 实习生生产操作权限边界是否需要写入研发规范？
HR-07实习生用工管理待新建144

状态：待新建｜证据：有证据（卡片 6 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：录用和管理在校/应届实习生时启动，涵盖协议类型、观察期、出勤确认与按天结算、导师与归属调整、学校材料（三方协议、实习证明、日志）配合，直至转正或离职。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）、导师/直属上级（当前：李子遥·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 核验在校身份 → ② 签实习协议并定档 → ③ 指定导师与出勤方式 → ④ 每日出勤记录 → ⑤ 月末导师确认出勤 → ⑥ HR 核算、财务发放 → ⑦ 学校材料办理 → ⑧ 观察期满转正/转岗/离职
  • 交付结果：签署的实习协议；实习生台账（身份、档位、导师、观察期、出勤方式）；导师确认的月度出勤表；按时足额发放的实习薪酬；学校所需证明材料。
  • 状态依据：规则零散在聊天中：观察期、配电脑条件、按出勤计薪（2026-04 起）等均靠口头；2026-01～10 出现实习薪资口径多次反复确认、签约类型判断反复、三方协议需催办、学校材料无模板、出勤统计缺固定表单等，约 25 次，无《实习生管理办法》。

1. 场景判定

  • 触发条件：录用在校/应届学生；每月实习薪酬结算；实习生调岗、借调；学校要求三方协议、实习证明、实习日志、就业信息；实习生提出离职或转正。
  • 典型说法：「实习生 2 个月，正式 3 个月」「现在公司开始正规化了，得按出勤实际算工资」「实习生就是按天算，不用整那么复杂」「我怎么又要交一个实习证明」
  • 判断问题：此人是否为在校学生？是 → 走本流程；已毕业或非在校 → 不得签实习协议，请走 HR-04 改签劳务/劳动合同。
  • 不归本流程管：实习薪酬档位标准 → 请走 HR-09；转正评估 → 请走 HR-08；离职交接 → 请走 HR-27；入职准备 → 请走 HR-05；未成年人/高中生合作 → 请走 HR-04。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
实习生管理 身份核验、协议、台账、出勤核算、学校材料 R/A 人事负责人（当前：黄莹·推断待确认）
规则与定档 研发实习生规则与定档、口径解释 C CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
制度拍板 实习生管理办法终审；失联结算等规则外个案裁定 A（升级） CEO（当前：邴龙志·推断待确认）
导师/直属上级 每日确认工作、月末确认出勤、评价 R 导师（当前：李子遥·推断待确认）
证明盖章/兼职项目 社会实践证明盖章；兼职项目派活 C 生态组负责人（当前：陈梦琪·推断待确认）
发放 按核算结果发放 R 财务（当前：待指定）
实习生 每日日报/打卡、提交学校材料需求 I 实习生

3. 办之前请准备

  • 学籍证明（学生证/在读证明）、预计毕业时间、学校实习要求（三方、分段实习、日志）。
  • 实习协议模板；薪酬档位（见 HR-09）。
  • 实习生台账（多维表格）。
  • 出勤记录方式：现场实习用飞书打卡；线上实习用日报+代码提交记录。
  • 实习证明、实习日志盖章模板。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 核验在校身份与毕业时间，判定可否签实习协议 实习生管理 录用确认后 1 个工作日内 飞书表单 身份核验结论 👤人工判断
2 签实习协议，登记档位、观察期（2 个月）、导师、出勤方式 实习生管理 到岗当日 实习生台账 协议与台账条目 🔧飞书固化
3 告知计薪规则（按实际出勤日结算、8 小时计 1 天）、补贴、配机规则 实习生管理 到岗当日 书面告知 规则确认回执 🔧飞书固化
4 每日打卡或提交日报（线上：日报+提交记录） 实习生 每个工作日 飞书打卡/日报 出勤原始记录 🔧+🤖
5 月初机器人提醒导师确认上月出勤 实习生管理 每月 1 日 飞书机器人 提醒 🤖自动化
6 导师确认出勤天数并标注异常（请假、缺勤、失联） 导师 每月 3 日前 多维表格 确认出勤表 🔧飞书固化
7 核算薪酬并与在册名单对账（防漏发、多发） 实习生管理 每月 5 日前 多维表格 核算表 🤖自动化
8 发放实习薪酬及补贴 财务 按公司发薪日 工资系统 发放记录 🔧飞书固化
9 办理三方协议、实习证明、日志盖章 实习生管理 收到申请后 3 个工作日内 飞书审批（用章） 盖章材料 🔧飞书固化
10 调岗/借调时更新台账归属与评价人 实习生管理 调整当日 实习生台账 归属变更记录 🔧飞书固化
11 观察期满前 15 天发起转正评估（HR-08）或续实习/离职（HR-27） 实习生管理 观察期满前 15 天 飞书审批 评估任务 🔧飞书固化

5. 交付物与模板

  • 交付物：实习协议、实习生台账、月度出勤确认表、薪酬核算表、学校材料、计薪规则告知回执。
  • 建议模板/表单：
    • 实习生台账：姓名、学校、预计毕业时间、主体、岗位、所属组、导师、档位、观察期起止、出勤方式、配机状态、状态（在岗/转正/离职）。
    • 月度出勤表：日期、出勤（1/0.5/0）、类型（出勤/事假/病假/缺勤）、导师确认人、确认时间；字段说明写明 1 = 8 小时。
    • 学校材料申请：材料类型、用途、截止日期、学校模板附件。

6. 异常与升级

  • 导师 3 日前未确认出勤 → 机器人再提醒 → 5 日仍未确认，HR 报部门负责人。
  • 在册实习生当月无核算记录（疑似漏发）→ HR 对账发现后 2 个工作日内补发并报 CTO/部门负责人。
  • 实习生失联 → 导师当日报 HR，按已确认出勤结算，结算方式报 CEO 确认。
  • 发现非在校身份签了实习协议 → HR 2 个工作日内按 HR-04 改签。
  • 实习生对计薪方式有异议 → HR 依书面规则解释，无法解决报综合部负责人。
  • 升级拍板：日常实习生管理（身份核验、协议、出勤核算、学校材料）由人事负责人作为 A 负责；出现以下任一情形时由 CEO 作为 A（升级）拍板——《实习生管理办法》首次发布或修订、实习生失联后的结算方式、现行规则未覆盖的计薪或补贴个案

7. 衡量指标

  • 出勤确认及时率：每月 3 日前完成导师确认的占比，目标 100%。
  • 发薪准确率：无漏发、多发、返工的实习生人数占比，目标 100%。
  • 学校材料办理时长：申请到盖章完成的工作日，目标 ≤ 3 天。
  • 规则咨询次数：每月实习生就计薪/出勤口径的咨询数，目标逐月下降。

8. 低效诊断

  • 现象：观察期、配机条件、补贴等规则多次反复确认，演变过程未书面化｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-04
  • 现象：三方协议流程需管理层多次催推，未固定｜依据：「模态人事大主管」2026-01、「模态人事大主管」2026-06
  • 现象：学校要求的实习证明、日志由实习生自行处理，公司无模板｜依据：「鸽子群模态分群」2026-02、「鸽子群模态分群」2026-03
  • 现象：计薪方式调整为按出勤结算后无书面通知与固定出勤提报表，日薪档、观察期后评估等口径需多次确认｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-10
  • 现象：兼职项目人员任务靠私信沟通，缺任务看板｜依据：「兼职沟通群」2026-03

9. 分支变体

  • 研发全职实习：按日计薪，享研发 AI 补贴；满 3 个月且转正通过后配公司电脑，此前自带电脑并安装终端安全软件。
  • 线上实习：出勤以日报+代码提交记录为准，由导师确认。
  • 非研发实习（运营、职能）：按岗位档位，不享研发补贴（待确认）。
  • 毕业前转正：薪酬按公司约定比例执行，毕业后改签劳动合同并缴纳五险一金（比例见 HR-09）。
  • 暑期/短期实习：可不设观察期转正，期满出具实习证明。
  • 兼职项目协作人员：HR 介绍项目经理，项目经理发任务清单与总表，规定文件命名与工时记录，问题统一在项目群提。
  • 借调：绩效由直属上级与借调上级共同评价。

10. 待确认问题

  • 是否尽快成文《实习生管理办法》？终审人为 CEO 还是 CTO？
  • 病假、事假在按天结算中如何处理，是否与实习协议一致？
  • 失联实习生的结算规则？
  • 三方协议、实习证明盖章由 HR 统一办理，还是保留生态组负责人盖章？
  • 非研发实习生是否适用补贴与配机规则？
HR-08试用期/实习观察期考核与转正待优化108

状态：待优化｜证据：有证据（卡片 14 张 / 会话 13 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：新员工入职（试用期 3 个月）或实习生入职（观察期 2 个月）后启动：入职即定考核指标，期间设检查点，期满前 HR 发起评估，由直属上级给结论、决策人定转正薪资，完成转正、延长或不通过处理。
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/评估人（当前：杨萌、王皓南、张东郅、王子明·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）；转正定薪——CTO（当前：丁震宇·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 入职定考核指标 → ② 2 周/1 个月检查点 → ③ HR 月度到期名单 → ④ 员工交转正报告 → ⑤ 直属上级评估 → ⑥ 定薪定级 → ⑦ 三方面谈与书面通知 → ⑧ 签约变更与归档
  • 交付结果：每人一份考核指标；转正报告与评估表；转正/延长/不通过结论与书面通知；转正薪资确认；花名册与合同同步更新。
  • 状态依据：已有《新员工转正报告》、研发转正评估表、财务等岗位考核评分表，HR 每月拉到期名单；但 2026-01～10 反复出现 HR 需主动@才有答复、评估人不明、考核指标定得不具体或多轮改稿、实习转正薪资条件口头、问题拖到试用期末才提出等，约 30 次，缺固定节点与审批。

1. 场景判定

  • 触发条件：新人入职（需定指标）；入职满 2 周/1 个月（检查点）；试用期或观察期到期前 30 天；导师/组长反馈新人表现明显不符；发现简历与实际不符。
  • 典型说法：「这个月到期人员，确认下是否转正」「最好一周左右能评估下是否合适」「他的转正指标谁写」「怎么评估研发」
  • 判断问题：该人员是否处于试用期/观察期内？是 → 走本流程；已转正员工的绩效改进 → 不在本流程（见分支 PIP）。
  • 不归本流程管：转正后的劳动合同签署/改签 → 请走 HR-04；实习生出勤结算 → 请走 HR-07；薪酬档位标准 → 请走 HR-09；离职交接 → 请走 HR-27；入职前背调 → 请走 X-RCT-18（拟录用背景调查）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程统筹 指标格式统一、到期提醒、汇总结论、面谈、归档 R 人事负责人（当前：黄莹·推断待确认）
评估人 写考核指标、检查点面谈、给转正结论 A 直属上级（当前：杨萌、王皓南、张东郅、王子明·推断待确认）
职能岗指标 起草综合部各岗位考核指标 R 综合部负责人（当前：赵雪冰·推断待确认）
财务岗指标 起草财务岗考核评分表 R 财务负责人（当前：黄梦婷·推断待确认）
跃竞线评估 作为跃竞人员的评估人给出转正/不通过结论 R 跃竞负责人（当前：徐莉·推断待确认）
转正定薪 研发线定薪，按 HR-09 口径给出定薪结论 R CTO（当前：丁震宇·推断待确认）
升级裁定 全公司定薪口径；评估结论或定薪有争议时裁定 A（升级） CEO（当前：邴龙志·推断待确认）
员工 提交转正报告、参加面谈 I 试用期员工/实习生

3. 办之前请准备

  • 岗位考核指标模板（周期、维度、权重、验收标准、加分项、转正标准）。
  • 《新员工转正报告》模板；研发转正评估表；职能岗评分表。
  • 花名册中的入职日期、试用期/观察期到期日。
  • 检查点面谈记录（2 周、1 个月）、30 天回顾（来自 HR-06）。
  • 转正薪资口径（定级对标表，见 HR-09）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草考核指标，HR 统一格式，管理层确认后告知本人 评估人、流程统筹 入职后 5 个工作日内 飞书文档（指标模板） 考核指标 🔧飞书固化
2 2 周与 1 个月检查点面谈，记录问题与改进要求 评估人 入职第 10、22 个工作日 面谈记录表 检查点记录 🔧飞书固化
3 每月 1 日生成次月到期名单并@评估人 流程统筹 每月 1 日 多维表格+机器人 到期名单 🤖自动化
4 发起转正审批，员工提交转正报告 员工 到期前 15 个工作日发起，10 个工作日前提交 飞书审批「转正申请」 转正报告 🔧飞书固化
5 填写评估表，给出结论（通过/延长/不通过）；借调人员由双方上级共同评 评估人 到期前 7 个工作日 飞书审批 评估表 👤人工判断
6 确定转正薪资与定级 转正定薪（非研发线由升级裁定人定） 到期前 5 个工作日 飞书审批 定薪结论 👤人工判断
7 组织员工、评估人、HR 三方面谈（5～10 分钟），说明结论、改进点、生效月 流程统筹 到期前 3 个工作日 会议室/飞书会议 面谈记录 👤人工判断
8 发书面转正通知；实习转正改签劳动合同、调薪补书面确认（HR-04） 流程统筹 到期日前 飞书审批/合同 转正通知、签约 🔧飞书固化
9 更新花名册与工资表，归档全部材料 流程统筹 转正后 2 个工作日内 多维表格 归档记录 🔧+🤖

5. 交付物与模板

  • 交付物：考核指标、检查点记录、转正报告、评估表、定薪结论、面谈记录、书面通知。
  • 建议模板/表单：
    • 考核指标：岗位、考核周期、维度、权重、验收标准、加分项、转正标准、制定人、确认人。
    • 转正评估表：任务完成度、专业能力、协作与沟通、价值观、导师评语、直属上级结论、建议定级。
    • 转正申请审批：员工、岗位、入职日、到期日、评估人、结论、转正薪资（限权可见）、生效月。

6. 异常与升级

  • 评估人到期前 7 个工作日未反馈 → HR 提醒一次 → 再 2 个工作日未反馈报部门上级/CTO，不得默认转正。
  • 评估人不明（借调、组织调整）→ 默认直属上级；仍不明报 CTO 1 个工作日内指定。
  • 不通过 → HR 与法务确认依据充分，期满前书面通知；跃竞线由跃竞负责人决定是否重启招聘。
  • 延长试用 → 须在原期满前书面告知并约定新目标，延长总期限不超过法定上限。
  • 升级拍板：转正结论由评估人（直属上级，跃竞线为跃竞负责人）作为 A 给出；出现以下任一情形时由 CEO 作为 A（升级）裁定——评估人与定薪人意见冲突、结论为“不通过”且员工有异议、转正薪资超出 HR-09 定级口径、非研发线定薪
  • 试用期内发现简历与实际不符 → 当日暂停代码仓库等权限，HR 与用人部门收集材料，法务评估后处理；同时反馈招聘流程补强背调。

7. 衡量指标

  • 指标按时制定率：入职 5 个工作日内有书面考核指标的占比，目标 100%。
  • 按时评估率：到期前完成评估的占比，目标 100%；默认转正数为 0。
  • 评估催办次数：每人评估所需 HR 提醒次数，目标 ≤ 1。
  • 转正通知提前量：书面通知距到期日的工作日，目标 ≥ 3 天。

8. 低效诊断

  • 现象：HR 每月发到期名单后需主动@才有答复，多次提醒“别忘啦”｜依据：「模态人事大主管」2026-03、「鼎慧人事」2026-03
  • 现象：评估人不明、转正指标谁写反复追问，评估结论与定薪分两路易混｜依据：「模态人事大主管」2026-05、「鼎慧产研决策部」2026-06
  • 现象：同一岗位考核指标多轮改稿，是否设权重意见不一｜依据：「综合&总经招聘考核沟通」2026-06、「综合&总经招聘考核沟通」2026-07
  • 现象：表现问题拖到试用期末才提出，无检查点，失败后重新招聘｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-05
  • 现象：实习生转正后享受正式薪资的条件靠口头，管理层要求成文｜依据：「董事会」2026-02、「鼎慧人事」2026-04
  • 现象：研发评估依据缺失，只说“让+1 评估”；实习生转正后闲置无人派活｜依据：「鼎慧产研决策部」2026-06、「鼎慧产研决策部」2026-07

9. 分支变体

  • 研发：使用研发转正评估表，评估人为直属上级+导师，CTO 定薪。
  • 职能岗：综合部负责人起草指标，转正报告+直属上级与 HR 共同评估。
  • 财务岗：财务负责人编制考核评分表。
  • 市场销售：KPI 以用户量、流水等业务指标为主。
  • 实习生观察期（2 个月）：实习满一定期限可折抵部分试用期（规则待确认）；转正后签劳动合同。
  • 跃竞：跃竞负责人决定转正与否；技术负责人代码评审作为依据。
  • 绩效改进计划（PIP）：转正后不达标员工另行处理，不在本流程内。
  • 子公司人员：由子公司自行评估（待确认）。

10. 待确认问题

  • 转正结论由直属上级决定、薪资由 CTO/CEO 决定的分工是否正式确认？
  • 到期前 15 个工作日发起、7 个工作日完成评估是否可行？
  • 实习期折抵试用期、实习转正享受正式薪资的条件如何成文？
  • 是否在飞书上线“转正申请”审批并自动按到期日触发？
  • 入职前背调由招聘流程负责到什么程度（学历、前雇主）？
HR-09薪酬定级与调薪待新建180

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：制定或调整薪酬带宽与实习生统一档位；员工转正定级、表现突出或到季度调薪时点需要调薪；管理层口头决定调薪或补贴变更、需要 HR 落地时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——创始人兼 CTO（研发岗评估，当前：丁震宇·推断待确认）、产品/业务负责人（当前：杨萌·推断待确认）、技术负责人（当前：王皓南·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 维护薪酬带宽与实习档位 → ② 直属负责人提交定级/调薪申请 → ③ CTO/业务负责人评估 → ④ CEO 审批 → ⑤ 写明生效月与实发月 → ⑥ 告知员工 → ⑦ 写入异动表推送财务 → ⑧ 首个实发月核对并归档
  • 交付结果：审批通过的定级/调薪单（级别或区间、生效月、实发月、理由）、更新后的人员异动表与工资表、员工告知记录、现行薪酬带宽与实习档位表
  • 状态依据：已有《薪酬及人员管理体系2.0》规定职级与实习基准，但没有调薪申请审批单和通知落实步骤；2026-01～09 调薪多为群聊口头决定，“几月生效、几月实发”反复确认，事后查不到书面记录，报给财务的数据与合同不一致导致多发，同类问题约 12 次

1. 场景判定

  • 触发条件：① 新设岗位或年度复核时需要制定/调整薪酬带宽、实习生统一档位；② 试用期或实习期转正需要定级；③ 直属负责人认为员工表现突出，申请调薪；④ 到季度（每三个月）调薪评估时点；⑤ CEO/CTO 在群里口头决定某人调薪或补贴（如学历补贴）变更，需要 HR 落地
  • 典型说法：「全栈实习薪资统一了」「他转正给多少 package」「给她个区间谈」「本月通知 下月生效」「三月生效指的是三月开始发还是四月开始发」「发薪体系还是正规一点」
  • 判断问题：这件事是不是在改变一名在职员工（或一类在职岗位）的薪酬标准？如果对象还是候选人、尚未入职，不走本流程
  • 不归本流程管：新候选人定薪谈薪与 Offer → 请走 X-RCT-17；转正考核是否通过 → 请走 HR-08；实习生用工协议与出勤 → 请走 HR-07；绩效评价与一次性奖惩 → 请走 HR-19；积分激励 → 请走 HR-18；AI 工具补贴 → 请走 HR-17；月度工资计算发放 → 请走 HR-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
薪酬标准维护人 维护薪酬带宽、实习档位表，解释口径，落实调薪通知与记录 R 人事负责人（当前：黄莹·推断待确认）
申请发起人（直属负责人） 提出定级/调薪建议，附产出材料与建议区间 R 产品/业务负责人（当前：杨萌·推断待确认）、技术负责人（当前：王皓南·推断待确认）
研发岗评估人 评估研发人员产出与级别，给出建议幅度 C 创始人兼 CTO（当前：丁震宇·推断待确认）
审批人 拍板定级、幅度、生效月；批准薪酬带宽 A CEO（当前：邴龙志·推断待确认）
财务 按异动表调整发薪，发现与合同不一致时反馈 I 财务负责人（当前：黄梦婷·推断待确认）
员工本人 接收告知并确认 I 全体员工

3. 办之前请准备

  • 现行《薪酬及人员管理体系2.0》职级表（技术 T 序列、管理 M 序列、实习基准）及最新薪酬带宽表
  • 员工当前职级、薪资、上次调薪时间（人员异动表）
  • 评估材料：工作汇报或产出清单、实际派活人/评价人意见
  • 建议级别或谈判区间、建议生效月
  • 实习生：岗位归属（研发/非研发）、形式（线下全职/在校）、地域（武汉/外地）
  • 批量调薪：名单、批次、预算总额

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 维护薪酬带宽与实习档位表，研发/非研发、线下全职/在校、武汉/外地分档写清，经 CEO 批准后在受限权限文档发布 人事负责人 每年 1 月复核 1 次；规则变更后 3 个工作日内更新 飞书文档（限权限） 薪酬带宽表（带版本号） 🔧飞书固化
2 提交“定级/调薪申请”：员工、类型（转正定级/绩效调薪/季度调薪/补贴变更）、建议级别或区间、理由与产出材料、建议生效月 直属负责人 转正到期前 5 个工作日；季度调薪于季度末月 10 日前 飞书审批 申请单 🔧飞书固化
3 评估：研发岗由 CTO 评估，非研发由业务负责人评估，对照带宽给出建议；评价人须包含实际派活人 CTO / 业务负责人 收到后 3 个工作日内 飞书审批节点 评估意见 👤人工判断
4 审批幅度与生效月；超出带宽须写明理由 CEO 收到后 3 个工作日内 飞书审批 审批结论 👤人工判断
5 按统一口径写明“生效月（从该月工资起算）/实发月（次月 8 日发放）”；群聊口头决定的调薪，由 HR 补录审批单并抄送决策人 人事负责人 审批通过当天；口头决定后 1 个工作日内补录 飞书审批 生效/实发月确认 🔧飞书固化
6 面谈或书面告知员工新级别、生效月、实发月，员工回复确认 人事负责人 / 直属负责人 审批通过后 3 个工作日内，且不晚于生效月 25 日 飞书消息 / 面谈 告知记录 👤人工判断
7 审批结果自动写入人员异动表，随月度异动推送财务 人事负责人 每月 1 日前 多维表格 异动表记录 🤖+👤
8 首个实发月核对工资条新薪资，审批单与告知记录归档 人事负责人 / 财务 实发当月 8 日前 飞书工资单 核对记录 🤖+👤

5. 交付物与模板

  • 交付物：定级/调薪审批单、薪酬带宽与实习档位表、人员异动表记录、员工告知记录
  • 建议模板/表单：
    • 定级/调薪申请字段：员工、部门、现职级、现薪资（仅审批人可见）、申请类型、建议级别/区间、调整理由、产出材料链接、评价人、建议生效月、实发月（自动 = 生效月次月 8 日）、是否超带宽及理由
    • 告知话术模板：调整原因、新级别、生效月、实发月、疑问联系人
    • 异动表字段：员工、异动类型、原值、新值、生效月、实发月、审批单号、录入人

6. 异常与升级

  • 群聊口头决定未走审批 → HR 补录审批单并抄送决策人；未补录不进异动表 → 2 个工作日内未补录升级 CEO
  • 生效月与实发月表述不清 → 按“本月审批、下月生效、次月 8 日实发”默认口径执行 → 有争议当天升级 CEO
  • 评价人与实际派活人不一致 → 增加实际派活人会签 → 意见冲突升级 CTO（2 个工作日）
  • 发现多发/少发 → HR 与财务核对合同与异动表，确定补发或扣回，书面告知员工 → 3 个工作日内未定升级财务负责人
  • 员工对结果有异议 → 直属负责人与 HR 面谈 → 5 个工作日未解决升级 CEO
  • 实习档位归属争议（研发/非研发） → 按岗位所属部门判定 → HR 无法判定时升级 CTO 与业务负责人共同决定

7. 衡量指标

  • 调薪书面化率 = 走审批的调薪数 / 实际调薪数，目标 100%
  • 调薪审批周期 = 提交申请到审批通过的自然日，目标 ≤ 7 天
  • 调薪发放差错数 = 因调薪导致的多发/少发次数，目标每月 0 次
  • 告知及时率 = 生效月前完成告知的调薪数 / 调薪总数，目标 100%
  • 生效口径追问次数 = 群内询问“几月生效/几月发”的次数，目标每季度 ≤ 1 次

8. 低效诊断

  • 现象：实习薪酬标准只在群里宣布，研发/非研发、全职/在校如何分档争论约 20 分钟，边界不清（标准制定环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：转正定级由谁拍板、谈判区间由谁给不明确，在群里随口讨论（审批授权环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：“生效”与“发放”月份混用，需反复确认（生效口径环节）｜依据：「董事会」2026-02、「模态人事大主管」2026-02
  • 现象：调薪口头决定后没有书面记录，事后翻遍聊天也查不到同步信息（记录环节）｜依据：「模态人事大主管」2026-03
  • 现象：报给财务的数据与合同不一致，出现多发需更正（与财务衔接环节）｜依据：「模态人事大主管」2026-04
  • 现象：谁通知、何时通知不明确，实习转正涨薪无制度，担心引发员工情绪（告知环节）｜依据：「董事会」2026-01
  • 现象：每次调薪都要在群里重新确认生效时点（规则沉淀环节）｜依据：「模态人事大主管」2026-06

9. 分支变体

  • 实习生统一档：研发线下全职 / 在校（偶尔回校） / 非研发 / 暑期，武汉与外地基准不同；面试官按档位报价，不议价，档位认定由 HR 按岗位归属判定
  • 转正定级：技术负责人提议级别 → 业务负责人与 CTO 共同定级 → 给 HR 谈判区间 → HR 沟通；实习转正按体系规定的比例折算
  • 绩效/季度调薪：每三个月评估一次；未评估者待考核完成后统一通知
  • 批量调薪（多批名单）：CEO、CTO、COO 先定名单与批次，先整体预告再一对一沟通，异动表按批次区分
  • 补贴变更（学历补贴等）：走同一审批单，类型选“补贴变更”
  • 奖金与调薪区分：一次性奖金不进本流程，走 HR-19 / FIN-14
  • 跃竞主体：由跃竞负责人审批，HR 只记录异动（待确认）

10. 待确认问题

  • 调薪最终审批人：是否统一由 CEO 审批？研发岗是否授权 CTO 在带宽内直接批准？
  • 季度（每三个月）调薪周期是否作为正式制度？
  • 默认口径“本月审批、下月生效、次月 8 日实发”是否确认？
  • 实习档位是否需要研发与非研发拉开差价？由谁最终定？
  • 薪酬带宽表的查看权限范围（HR、CEO、CTO、业务负责人？）
  • 飞书“定级/调薪申请”审批由谁配置（飞书审批管理员是否为人事负责人）？
  • 跃竞是否纳入统一调薪流程？
HR-10日常考勤打卡、补卡与到岗规范待优化90

状态：待优化｜证据：有证据（卡片 13 张 / 会话 6 个）｜优先级：频5 × 耗2 × 跨3 × 险3

  • 适用场景：员工日常上下班打卡与到岗；飞书打卡失败、漏打卡需要补卡；超过最晚到岗时间未到且未报备需要提醒或按规扣罚；团队进入或结束冲刺期需要调整到岗规则时
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、站会组织人（当前：李铭熙、宋祺睿·推断待确认）、规则拍板人创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 发布公司考勤规则与组内弹性约定 → ② 配置飞书考勤 → ③ 员工每日打卡 → ④ 异常自动提醒本人 → ⑤ 员工提补卡 → ⑥ 直属上级审批 → ⑦ 到岗异常提醒与警告 → ⑧ 扣罚进入月度核对
  • 交付结果：一页纸《考勤打卡与补卡指引》、飞书考勤规则配置、每日异常提醒与补卡审批记录、到岗警告记录
  • 状态依据：已有飞书考勤与补卡申请，但最晚到岗时间在 2026-01～09 先后口头定为 10:30、11:00、冲刺期 9～11 点区间，各组不一；补卡是否要申请、动态/极速打卡怎么用靠同事互教，群内重复询问约 15 次；考勤异常在群里公示、到岗靠群里点名

1. 场景判定

  • 触发条件：每日上下班打卡；飞书未自动打卡、漏打卡、跨零点加班导致下班卡被记为上班卡；超过最晚到岗时间未打卡且无请假/外出/外勤审批；团队调整弹性时间或进入/结束冲刺期
  • 典型说法：「上班没打卡怎么办」「缺卡是不是必须要单独拉个申请」「要‘打开’飞书，不是开着飞书」「十一点还没到得扣半天考勤工资」「上午都找不到人」
  • 判断问题：这是不是“某一天的打卡记录或到岗时间”的问题？是 → 本流程；如果是半天/整天不来、居家或外出 → 走请假流程
  • 不归本流程管：请假、居家、外勤 → 请走 HR-11；加班申请与工时 → 请走 HR-12；节假日调休上班通知 → 请走 HR-13；月度考勤核对与扣薪核定 → 请走 HR-14；员工屡次违规的面谈处置 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
规则维护人 写考勤规则、配置飞书考勤、发布指引、执行到岗核查与警告 R 人事负责人（当前：黄莹·推断待确认）
规则拍板人 批准到岗时间、扣罚标准、冲刺期规则 A 创始人兼 CTO（当前：丁震宇·推断待确认）
团队负责人 在公司规则内约定组内弹性时间，审批补卡，到岗异常第一提醒人 R 团队负责人（当前：杨萌、王皓南·推断待确认）
站会组织人 站会时确认到岗，发现未到报团队负责人 C 站会组织人（当前：李铭熙、宋祺睿·推断待确认）
员工 按时打卡、及时补卡、迟到提前报备 R 全体员工
综合部 知悉规则变更，处理扣罚争议 I 综合部负责人（当前：赵雪冰·推断待确认）

3. 办之前请准备

  • 公司考勤制度：工作时间、弹性区间、最晚到岗时间、迟到/旷工定义、扣罚标准、加班次日豁免
  • 本组弹性约定（如站会时间、CR 时间），须在公司规则范围内
  • 飞书考勤配置：打卡地点与范围（含多个办公点）、极速打卡/动态打卡、自动打卡、跨零点规则
  • 补卡入口与要求：工作台 → 假勤 → 补卡；原因与凭证
  • 冲刺期/加班次日豁免名单（来自加班审批）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布一页纸考勤指引：工作时间、弹性区间、最晚到岗时间、加班次日豁免、打卡方式（到点打开飞书触发极速打卡、失败改手动）、补卡入口与时限、扣罚标准；团队弹性约定变更需报 HR 备案 人事负责人 规则变更后 1 个工作日内发布并在各群置顶 飞书文档 + 群公告 考勤指引 🔧飞书固化
2 配置飞书考勤：打卡范围、弹性规则、跨零点下班卡、加班次日豁免、多办公点 人事负责人 规则发布前完成 飞书假勤后台 考勤规则配置 🔧飞书固化
3 员工每日打卡；自动/极速打卡失败或加班晚归时手动打卡 员工 每日上下班 飞书打卡 打卡记录 👤人工判断
4 缺卡、迟到由考勤机器人推送本人并抄送直属上级，不在群里公示个人异常 人事负责人（配置） 次日 10:00 前自动推送 飞书考勤提醒 / 机器人 异常提醒 🤖自动化
5 员工提交补卡申请，写明原因、附凭证（如加班记录） 员工 缺卡后 2 个工作日内，最迟月度补卡截止日 飞书补卡审批 补卡单 🔧飞书固化
6 直属上级审批补卡 团队负责人 收到后 1 个工作日内 飞书审批 审批结果 👤人工判断
7 到岗核查：超过最晚到岗时间未打卡且无请假/外出/外勤审批，团队负责人私信询问；14:00 仍未到且无说明，HR 发书面警告 团队负责人 / 人事负责人 当日 飞书考勤看板 警告记录 🔧+👤
8 再犯按制度扣考勤工资（前一天有加班审批的豁免），结果进入月度考勤核对 人事负责人 月度核对时 考勤汇总表 扣罚清单 👤人工判断

5. 交付物与模板

  • 交付物：考勤打卡与补卡指引、飞书考勤配置、补卡审批记录、到岗警告记录
  • 建议模板/表单：
    • 考勤指引目录：工作时间与弹性、最晚到岗、打卡方式与常见故障、补卡流程、迟到与扣罚、加班次日豁免、冲刺期规则、咨询人
    • 补卡申请字段：日期、缺卡类型（上班/下班）、原因（忘打/系统故障/跨零点加班/外出）、凭证、审批人
    • 到岗警告记录字段：日期、员工、未到岗时长、是否有审批、提醒人、警告次数、处理结果

6. 异常与升级

  • 飞书打卡系统故障或全员未自动打卡 → HR 当日群公告统一补卡口径 → 影响超过 1 天升级综合部负责人
  • 跨零点加班导致下班卡被记为上班卡 → 当日补卡并备注加班 → 次日由 HR 统一处理
  • 早到被统计为异常等口径争议 → HR 按指引解释 → 指引未覆盖时 2 个工作日内升级 CTO 定口径
  • 冲刺期规则与常规规则冲突 → 以冲刺公告为准，公告须写明起止日期；结束当天 HR 发恢复通知
  • 同一员工当月迟到/未到岗达 3 次 → 团队负责人面谈 → 转 HR-20
  • 扣罚争议 → HR 核对打卡与审批证据 → 3 个工作日未解决升级综合部负责人

7. 衡量指标

  • 缺卡率 = 缺卡人次 / 应打卡人次，目标 ≤ 2%
  • 补卡及时率 = 缺卡后 2 个工作日内提交的补卡数 / 补卡总数，目标 ≥ 90%
  • 考勤咨询次数 = 群内询问打卡、补卡规则的次数，目标每月 ≤ 2 次
  • 群内点名/催到岗次数 = 每月在群里点名未到岗的次数，目标 0
  • 迟到率 = 迟到人次 / 应出勤人次，目标 ≤ 5%

8. 低效诊断

  • 现象：规则在问题出现后才口头宣布，最晚到岗时间先后变动多次、各组不一（规则发布环节）｜依据：「工程咨询产研」2026-01、「Leap产研测」2026-05、「Leap产研测」2026-09
  • 现象：补卡是否需要单独申请、动态打卡何时开始，员工互相问且答案不一（指引环节）｜依据：「鸽子群模态分群」2026-04、「鸽子群模态分群」2026-05
  • 现象：极速打卡必须打开 App 才触发，用法靠同事口传（工具使用环节）｜依据：「跃迁AI总动员」2026-08、「鸽子群模态分群」2026-05
  • 现象：漏打卡反复发生，没有当天提醒（提醒环节）｜依据：「鸽子群模态分群」2026-07、「Leap产研测」2026-08
  • 现象：考勤异常在群里按人公示，到岗靠群里点名、追问“还没来上班的什么情况”（核查环节）｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：扣罚规则只口头宣布，无成文制度与系统衔接（扣罚环节）｜依据：「鼎慧产研决策部」2026-07
  • 现象：早到打卡是否算异常口径不清，引发争议（统计口径环节）｜依据：「Leap产研测」2026-08
  • 现象：多个办公点之间切换，领导不清楚人在哪、召回指令被误解（办公地点环节）｜依据：「鸽子群模态分群」2026-04

9. 分支变体

  • 常规期：公司统一最晚到岗时间 + 组内弹性约定；站会时间与到岗时间对齐
  • 冲刺/紧急赶工期：按公告执行（如每日出勤时长要求、到岗区间），公告写明起止日；结束后发恢复通知
  • 加班次日：有加班审批的可晚到并豁免扣罚
  • 跨零点加班：下班卡走补卡
  • 多办公点（K11、模态空间等）：飞书考勤配置多个打卡地点；去外部地点走外勤（HR-11）
  • 市场侧不打卡、以周报统计：在月度核对中处理，见 HR-14

10. 待确认问题

  • 公司统一最晚到岗时间是 10:30 还是 11:00？各组可否自定弹性时间？
  • “11 点未到扣半天考勤工资”“中午未到先警告、再犯扣考勤工资”是否已写入正式《考勤管理制度》并公示？
  • 补卡次数上限与凭证要求（草案曾写“暂不限次数”）是否沿用？
  • 到岗核查由 HR 执行还是团队负责人执行？
  • 冲刺期规则由谁发布：CTO、团队负责人还是 HR？
  • 考勤异常提醒能否改为只推本人和直属上级，停止群内公示？
HR-11请假、居家/远程办公与外勤报备待优化60

状态：待优化｜证据：有证据（卡片 16 张 / 会话 7 个）｜优先级：频5 × 耗2 × 跨3 × 险2

  • 适用场景：员工需要请事假/病假/年假/调休，或申请居家/远程办公、外勤、外出办事与外出培训时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——直属上级/团队负责人（当前：杨萌、王皓南·推断待确认）、研发线审批人创始人兼 CTO（当前：丁震宇·推断待确认）、非研发审批人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 员工事前提交对应假勤审批 → ② 直属上级审批（按部门自动路由） → ③ 审批通过自动通知团队群与项目负责人 → ④ 交接与紧急联系 → ⑤ 居家期间站会与日报 → ⑥ 变更在审批内撤回/修改 → ⑦ 额度与余额维护 → ⑧ 数据进入月度考勤核对
  • 交付结果：审批通过的请假/居家/外勤单、团队群同步通知、交接记录、居家日报、员工可自查的年假与调休余额
  • 状态依据：已有飞书假勤审批（请假、外勤、居家、外出），但 2026-01～10 员工习惯先在群里或私下口头说再补审批，研发与非研发找谁批不清，审批通过后项目负责人不知情，极端天气居家各组自己问老板，年假口径靠同事解释，同类问题约 30 次

1. 场景判定

  • 触发条件：事假、病假、年假、调休；居家/远程办公（极端天气、毕业返校或答辩、外地）；外勤、外出办事、外出培训；短时离开（半小时至半天）
  • 典型说法：「我下午请个假…要走申请吗」「他没审批就是没请」「下次让他们请假先全群同步一下」「居家得找老板吗」「不满一年不能休年假吗」
  • 判断问题：员工是否在工作时间内不在工位、或不在正常工作状态？是 → 本流程；只是漏打卡 → HR-10
  • 不归本流程管：漏打卡与补卡 → 请走 HR-10；加班申请与加班转调休登记 → 请走 HR-12；公司统一放假/调休安排 → 请走 HR-13；请假扣薪核定 → 请走 HR-14；差旅费用 → 请走 FIN-07；长期驻外或调岗 → 请走 HR-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 事前提交审批、写交接与紧急联系、居家期间提交日报 R 全体员工
直属上级 审批、确认交接人与工作量，居家期间跟进产出 A 团队负责人（当前：杨萌、王皓南·推断待确认）
研发线审批人 研发人员超过 3 天的请假、远程办公加签；直属上级超时未批时代批 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
非研发审批人 非研发人员超过 3 天的请假、远程办公加签；直属上级超时未批时代批 A（升级） CEO（当前：邴龙志·推断待确认）
HR 配置审批路由与自动通知、写假勤规范、维护年假与调休余额、答疑 R 人事负责人（当前：黄莹·推断待确认）
项目负责人 被抄送知情，调整站会、会议与验收安排 I 各项目负责人

3. 办之前请准备

  • 假别、起止时间与时长（小时/半天/整天）
  • 居家/远程：理由、期间产出计划、可联系时段、站会参加方式（开摄像头）
  • 外勤/外出：地点与事由（不必写细节）
  • 交接：在途任务、会议与验收代理人、紧急联系方式
  • 本人年假与调休余额（飞书假勤自查）
  • 病假凭证（按制度要求）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 选择对应类型提交审批（事假/病假/年假/调休/居家/外勤/外出），群里口头说明不算请假 申请人 事假、年假提前 1 个工作日；居家前一日 18:00 前；病假与突发情况当天上班前 飞书假勤审批 申请单 🔧飞书固化
2 审批按部门自动路由到直属上级；超过 3 天或超出居家规则的，研发加签 CTO、非研发加签 CEO 直属上级 / 研发线或非研发审批人（加签） 收到后 4 小时内；当天请假 1 小时内 飞书审批 审批结果 🔧+👤
3 审批通过自动推送团队群与项目负责人，并在日历上标记不在岗 HR（配置） 审批通过即时 飞书审批机器人 + 日历 群通知 🤖+👤
4 在审批备注中写明交接人、在途任务、紧急联系方式；超过 3 天的长假在飞书任务中转交 申请人 离岗前 飞书任务 交接记录 👤人工判断
5 居家/远程期间参加站会（开摄像头），下班前提交当日日报；直属上级确认工作量 申请人 / 直属上级 每个居家日 日报模板 / 站会 日报 🔧+👤
6 计划变更在审批流内撤回或修改，不在群里口头改 申请人 变更当时 飞书审批 变更记录 🔧飞书固化
7 按制度（司龄口径）维护年假额度，调休余额由加班审批自动累加，员工自助查询 HR 每月 5 日前更新 飞书假勤 假期余额 🤖+👤
8 月末请假、外勤数据进入月度考勤核对 人事负责人 每月 1 日 飞书假勤统计 假勤明细 🤖自动化

5. 交付物与模板

  • 交付物：假勤审批单、团队群自动通知、交接记录、居家日报、假期余额
  • 建议模板/表单：
    • 一页纸《假勤规范》：各假别适用情形与审批类型、提前时限、审批路由、居家/远程条件与上限、年假计算口径（司龄）、病假凭证、调休来源与有效期、常见问题“我该走哪个审批”
    • 居家/远程申请字段：日期、理由、产出计划、可联系时段、站会方式、直属上级
    • 居家日报字段：日期、完成事项、产出链接、遇到的阻塞、次日计划

6. 异常与升级

  • 先休后批或未提审批 → 视为未请假，直属上级当天提醒补提 → 当月第二次由 HR 书面提醒，按制度口径处理，争议升级综合部负责人
  • 审批人超时未批 → 4 小时自动提醒 → 1 个工作日未批升级加签人（CTO/CEO）
  • 极端天气 → HR 当日 8:00 前发全员统一通知（到岗或居家） → 未发通知时团队负责人可临时决定并报 HR 备案
  • 居家期间联系不上或产出明显不足 → 直属上级记录并次日面谈 → 再次发生取消该员工远程许可，报 HR
  • 年假、调休口径争议 → HR 按制度答复 → 制度未覆盖时 3 个工作日内升级综合部负责人
  • 不清楚该走哪个审批 → 先查《假勤规范》，仍不清楚问 HR → HR 当日答复
  • 升级拍板：3 天以内的请假、居家、外勤由直属上级作为 A 审批；出现以下任一情形时，研发线由 CTO、非研发线由 CEO 作为 A（升级）加签——请假或远程办公超过 3 天、超出居家规则上限、直属上级 1 个工作日未审批

7. 衡量指标

  • 事前审批率 = 离岗前已提交审批的假勤单 / 假勤单总数，目标 ≥ 95%
  • 审批时长 = 提交到审批通过的时长中位数，目标 ≤ 4 小时
  • 请假知情追问次数 = 项目负责人在群里追问“某人是否请假”的次数，目标每月 0 次
  • 居家日报提交率 = 提交日报的居家日 / 居家日总数，目标 100%
  • 假勤规则咨询次数 = 群内或向 HR 询问“要不要走审批/找谁批”的次数，目标逐月下降

8. 低效诊断

  • 现象：研发与非研发请假找谁批不清，出现先休后批（审批路由环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：群里口头说一句就当请假，未走审批，站会缺席无人知道原因（申请环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：审批通过不通知项目负责人，找人加急时才发现已请假，需要另行要求抄送（同步环节）｜依据：「鼎慧产研决策部」2026-06
  • 现象：极端天气、春节前居家由各组自己问老板，没有统一决策（居家决策环节）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-05
  • 现象：居家期间状态与工作量难掌握，站会是否开摄像头、工作时间临时讨论（居家管理环节）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-02
  • 现象：节前请假靠负责人 @所有人统计，请假期间验收由谁接未明确（交接环节）｜依据：「工程咨询产研」2026-04、「工程咨询产研」2026-07
  • 现象：加班后算调休还是补卡分不清，调休余额需要私下问 HR（余额环节）｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-06
  • 现象：年假按工龄还是司龄靠同事在群里解释（规则环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：冲刺期居家、外勤只在群里口头告知，无代理人（报备环节）｜依据：「Leap产研测」2026-06

9. 分支变体

  • 事假/病假/年假/调休：年假按司龄计算；调休来自加班审批（HR-12）
  • 居家/远程：与本人既定产出相关的工作才可远程，否则走请假；居家次数按公司规范上限执行
  • 极端天气：以 HR 当日统一通知为准
  • 毕业答辩/返校的实习生：直属上级批准远程并约定产出与日报
  • 外勤：外出办事、客户现场、出差替代、外出培训，统一走外勤审批
  • 短时离开（≤ 2 小时）：走小时假
  • 研发与非研发：审批路由不同；市场部考勤由市场侧指定人员统一管理

10. 待确认问题

  • 审批路由：直属上级一级审批是否足够？超过 3 天加签 CTO/CEO 的门槛是否合适？
  • 居家/远程上限（如每月不超过 1 天）是否为公司统一规范？入职时有特殊约定的如何处理？
  • 年假是否按司龄、入职满一年起算？
  • 提前提交时限（事假提前 1 个工作日、居家前一日 18:00）是否可行？
  • 极端天气通知由 HR 还是行政发布？
  • 审批通过自动推送团队群需要飞书管理员配置，由谁负责？
  • 外出培训归外勤还是出差？
HR-12加班申请、工时登记与调休/加班费结算待新建320

状态：待新建｜证据：有证据（卡片 24 张 / 会话 11 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：项目赶工、上线、大会、客户线下加急需要晚间/周末/法定节假日加班，或公司宣布紧急赶工期时，从事前申请到事后折算调休、加班费、补贴或积分全程适用
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——团队负责人（当前：杨萌、王皓南·推断待确认）、研发加班审批人创始人兼 CTO（当前：丁震宇·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 制度成文并经法务审定 → ② 事前提交加班申请或名单 → ③ 直属上级审批 → ④ 加班打卡 → ⑤ 事后提交工时与成果 → ⑥ 上级确认工时 → ⑦ HR 月度汇总 → ⑧ 折算调休/加班费/积分 → ⑨ 落账并告知
  • 交付结果：经法务审定的《加班管理制度》、审批通过的加班单与名单、确认后的加班工时明细、月度加班结算清单、员工可查的调休余额与工资条加班项
  • 状态依据：已有飞书加班申请，但 2026-02～10 加班多在群里点名、私下报工时，强制/自愿、深夜/日常延时、是否设上限各组口径不一；3～4 月按 1:1 及时结算，8～9 月大加班改为“年底再说”，员工在工资条日追问加班费；9 月才出规范草案，尚未成文，同类问题约 40 次，且有劳动争议风险

1. 场景判定

  • 触发条件：负责人需要员工在工作日晚间、周末、法定节假日额外工作；公司宣布紧急赶工期；客户要求线下加急或机房整修；员工想补记已发生的加班；月底核对或员工离职需要结算
  • 典型说法：「加班必须要申请和审核」「周末要加班的找我申请加班补贴或者后续调休」「正常开发任务没做完加班不算」「其实申请加班很麻烦」「加班统计对非 HR 来说是迷雾」
  • 判断问题：这段工作是不是负责人事前安排或事前批准的额外工作？如果只是当天任务没做完的自行延时，不算加班
  • 不归本流程管：迟到与补卡 → 请走 HR-10；用调休余额休假 → 请走 HR-11；公司统一放假、调休、节中值守 → 请走 HR-13；积分发放与兑换 → 请走 HR-18；AI 工具补贴 → 请走 HR-17；工资发放 → 请走 HR-15；离职时结清 → 请走 HR-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
加班发起人 判断加班必要性，确定名单、任务、时段 R 团队负责人（当前：杨萌、王皓南·推断待确认）
员工 本人提交申请、加班打卡、报工时与成果 R 全体员工
直属上级 审批加班申请、判断是否属于安排的加班、确认工时 R 各团队直属上级（当前：杨萌、王皓南·推断待确认）
研发加班审批人 研发线名单外加班加签；加班认定与工时争议裁定 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
规则与出资决策人 定倍率、调休优先、强制与否、结算周期、补贴标准；确认月度加班结算清单 A CEO（当前：邴龙志·推断待确认）
HR 起草制度、统计工时、折算、维护调休余额、答疑 R 人事负责人（当前：黄莹·推断待确认）
财务 加班费随工资发放、核对金额 C 财务负责人（当前：黄梦婷·推断待确认）
法务 审定加班制度合规性、处理争议 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 《加班管理制度》（或现行草案）：申请审核要求、倍率、休息时间扣除、调休优先、强制/自愿界定、结算周期、上限
  • 加班事由、任务清单、预计时段与时长
  • 批量加班：名单（多维表格），区分核心/可选人员
  • 本月已有加班与调休余额
  • 成果证明形式（提交记录、演示结果、工单链接）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制度成文：申请审核、倍率、周末/节假日扣除休息时间、周末优先调休、强制/自愿界定、结算周期、月度上限；法务审定后发布并培训 人事负责人 / 法务 制度发布 1 次；修订后 3 个工作日内宣贯 飞书文档 《加班管理制度》 🔧飞书固化
2 事前申请：员工本人提交（日期、预计时长、任务、安排人）；批量赶工由团队负责人提交名单，名单外人员需单独申请 员工 / 团队负责人 加班开始前；周末加班于周五 18:00 前 飞书加班审批 / 多维表格名单 申请单 / 名单 🔧飞书固化
3 审批并判断是否属于安排的加班；审批结果抄送 HR 与项目负责人 直属上级（争议或名单外研发加班由研发加班审批人加签） 收到后 1 个工作日内，且不晚于加班开始 飞书审批 审批结果 👤人工判断
4 加班期间手动打卡上下班 员工 加班当日 飞书打卡 打卡记录 🔧飞书固化
5 在原申请单补充实际时段、时长、成果证明；扣除用餐与休息时间 员工 加班结束后 1 个工作日内；当月加班最晚于次月第 1 个工作日 18:00 前补充 飞书审批 工时记录 🔧飞书固化
6 确认工时，不认可的写明原因 直属上级 收到后 1 个工作日内；当月加班最晚于次月第 2 个工作日 12:00 前确认 飞书审批 确认工时 👤人工判断
7 审批与打卡自动比对，生成月度加班明细 人事负责人 次月第 2 个工作日 18:00 前 多维表格 加班月报 🤖+👤
8 折算：周末加班优先转调休；工作日、法定节假日按制度倍率计加班费或积分；清单报 CEO 确认 人事负责人 / CEO 次月第 3 个工作日 12:00 前（早于 HR-15 工资表审核） 多维表格 加班结算清单 👤人工判断
9 调休余额写入飞书假勤；加班费进入当月工资表并在工资条单列；书面告知结算口径 人事负责人 / 财务 随当月工资（每月 8 日） 飞书假勤 / 工资单 余额与工资条 🔧+🤖

5. 交付物与模板

  • 交付物：《加班管理制度》、加班审批单与名单、月度加班明细、加班结算清单、调休余额
  • 建议模板/表单：
    • 加班申请字段：申请人、日期、类型（工作日/周末/法定节假日/居家）、预计时段、事由与任务、安排人、是否强制、实际时段、实际时长、扣除时长、成果证明链接、确认人
    • 赶工名单字段：项目、成员、角色（核心/可选）、起止日期、每日工时要求、结算方式
    • 结算清单字段：员工、加班类型、确认工时、折算方式（调休/加班费/积分）、倍率、调休时长、结算月、CEO 确认

6. 异常与升级

  • 事后补报、未事前申请 → 直属上级 2 个工作日内确认是否属于安排；不认可不计 → 争议升级 CTO
  • 名单漏人或多人 → 发起人 1 个工作日内更正名单并通知 HR
  • 调休在有效期内未休完 → HR 到期前 1 个月提醒 → 到期按制度清算，需例外的升级 CEO
  • 规则未定导致结算延期 → HR 书面告知员工预计结算时间 → 延期超过 1 个月升级 CEO
  • 员工离职时有未结加班或调休 → 并入离职结算（HR-27）
  • 员工提出加班费争议或劳动风险 → HR 收集审批与打卡证据 → 法务 3 个工作日内出意见，升级 CEO
  • 飞书审批一单只能放一人 → 统一由员工本人提交，负责人只维护名单
  • 次月第 2 个工作日 12:00 前仍未完成补充或确认的工时 → 不进入本月工资，顺延至下月结算，HR 书面告知员工
  • 升级拍板：加班规则与月度结算清单由 CEO 作为 A 确认；研发线名单外加班、事后补报或工时认定有争议时，由 CTO 作为 A（升级）裁定

7. 衡量指标

  • 事前申请率 = 事前提交的加班单 / 加班单总数，目标 ≥ 90%
  • 结算准时率 = 按制度周期完成结算的加班工时 / 应结算工时，目标 100%
  • 工时确认及时率 = 次月第 2 个工作日 12:00 前完成确认的当月加班工时 / 当月加班工时，目标 ≥ 95%
  • 调休余额可查率 = 能在飞书假勤自查余额的员工 / 有加班员工，目标 100%
  • 加班结算追问次数 = 员工询问“加班费呢/何时发”的次数，目标每月 ≤ 1 次
  • 人均月加班时长 = 确认工时 / 加班人数，超过法定上限自动预警

8. 低效诊断

  • 现象：加班申请在群里 @负责人、口头同意，不走系统（申请环节）｜依据：「鼎慧产研决策部」2026-04、「LeapAll（Deprecated）」2026-03
  • 现象：强制/自愿、深夜/日常延时、任务未完成是否算加班口径不一（认定环节）｜依据：「Leap产研测」2026-05、「工程咨询产研」2026-08
  • 现象：工时在群里或私下逐条报，每周还要把历史再汇总一遍（统计环节）｜依据：「Leap产研测」2026-04、「Leap产研测」2026-05
  • 现象：飞书审批一条只能放一人，负责人逐个代录，代录单他人看不到（工具环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：赶工期名单反复修改、漏人多人，未安排的人也被通知（名单环节）｜依据：「Leap产研测」2026-08、「鼎慧产研决策部」2026-08
  • 现象：结算口径前后不一，从及时结算变为年底统一处理，员工在工资条日追问（结算环节）｜依据：「模态人事大主管」2026-04、「模态人事大主管」2026-09
  • 现象：加班转调休和积分后工资单不显示，规则不透明，人人都要问（告知环节）｜依据：「鼎慧产研决策部」2026-09
  • 现象：线下客户加急补贴、周末加班费只口头承诺，谁统计谁审批不清（补贴环节）｜依据：「忠橙星行星引擎」2026-02、「忠橙星行星引擎」2026-03
  • 现象：加班审批人不明确，需要临时加签转给他人（审批环节）｜依据：「鼎慧产研决策部」2026-10
  • 现象：赶工结束时间与后续处理口径不清，名单靠人工维护（收尾环节）｜依据：「薪酬对接群」2026-06、「薪酬对接群」2026-09
  • 现象：项目紧急时深夜临时拉人，加班人数靠群里互相问（排班环节）｜依据：「鸽子群模态分群」2026-03

9. 分支变体

  • 工作日晚间临时赶工：按制度倍率计费或积分，不可调休（以正式制度为准）
  • 周末加班：优先转调休，可由公司统筹安排调休；扣除休息时间
  • 法定节假日加班：按法定倍率结算，不转调休
  • 紧急赶工期（如 2026-08-08 至 09-08）：公告写明每日工时、出勤要求、名单、结算方式；名单由技术负责人维护；结束后统一统计转调休余额
  • 大会/演示冲刺：点名加班须写明“强制”或“自愿”
  • 客户线下加急、机房整修：按次补贴或安排调休，标准由 CEO 定
  • 赛马等活动：设申报上限（如单日最多 6 小时），须附成果证明
  • 居家加班：单独报工时并附成果
  • 实习生：按日薪或实际出勤结算
  • 与积分衔接：加班可折算积分 → HR-18

10. 待确认问题

  • 2026-09 规范草案（申请审核、倍率、扣除休息时间、周末优先调休、年底统一结算）是否已经法务审定并正式发布？
  • 加班审批人：直属上级、CTO 还是 CEO？研发与非研发是否统一？
  • “当天任务没做完的延时不算加班”是否写入制度？
  • 调休有效期与每月可调休上限（如每月最多 3 天）是否确定？
  • 结算周期是月度、季度还是年底？与工资节点如何衔接？
  • 加班折算积分的比例由谁定？
  • 客户线下加急补贴标准由谁定、是否写入制度？
HR-13节假日放假调休与值守安排通知待优化90

状态：待优化｜证据：有证据（卡片 8 张 / 会话 10 个）｜优先级：频2 × 耗3 × 跨5 × 险3

  • 适用场景：春节、五一、中秋国庆等法定节假日或公司统一调休日前，需要确定放假/补班/调休/居家办公方案、收集各项目组值守与 oncall，并向全员发正式通知时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CEO（方案决策，当前：邴龙志·推断待确认）、创始人兼 CTO（研发侧方向与值守，当前：丁震宇·推断待确认）、各项目组负责人（当前：杨萌、陈梦琪、徐莉、王皓南·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 年初发布全年放假日历 → ② 长假前发起方案收集 → ③ 各项目组上报居家/到岗/值守 → ④ CEO 拍板 → ⑤ HR 发正式通知并要求已读 → ⑥ 飞书假勤配置补班与调休扣减 → ⑦ 节中值守 → ⑧ 节后考勤与加班处理
  • 交付结果：年度放假与调休日历；节前正式通知（放假与补班、公司调休日抵扣规则、居家安排与工作时间、值守/oncall 表、节日福利、加班结算口径）；节后调休扣减记录
  • 状态依据：综合部已能 @全员发放假与调休上班提醒，2026-09 中秋国庆通知已成文；但 2026-02 春节调休无官方通告、各组自行传达，员工追问“明天上不上班”；2026-09 放假日期迟发影响 oncall 排班和买票；各项目组方案分散在群里回复，长假安排临近才讨论

1. 场景判定

  • 触发条件：法定节假日前；法定调休上班日前；公司额外放假或统一调休日；春节错峰/居家办公安排；子公司自定假期方案需备案
  • 典型说法：「到现在也没人通知」「能不能早点通知日期」「技术过年一周的调休是5天还是7天」「得提前规划好节前节后工作安排和节中出现问题的处理方案」「2月28日为法定调休上班日，大家正常出勤」
  • 判断问题：这件事是否涉及全公司或整个项目组的放假、补班、调休或居家安排？个人休假走请假流程
  • 不归本流程管：个人请假、居家 → 请走 HR-11；节假日加班申请与结算 → 请走 HR-12；积分规则 → 请走 HR-18；企业滴滴通勤 → 请走 FIN-08；节日福利物资采购与发放 → 请走 ADM-18（节日福利与员工福利物资发放）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
方案决策人 决定放假天数、公司调休日、抵扣顺序、居家规则 A CEO（当前：邴龙志·推断待确认）
研发侧建议人 提出研发侧休假方向、节中应急要求 C 创始人兼 CTO（当前：丁震宇·推断待确认）
通知发布人 发起收集、汇总、起草与发布通知、配置假勤、追踪已读 R 人事负责人（当前：黄莹·推断待确认）
通知审核人 审核通知措辞并转发各群 C 综合部负责人（当前：赵雪冰·推断待确认）
项目组负责人 上报本组居家/到岗日期、值守人与 oncall、节后计划 R 项目组负责人（当前：杨萌、陈梦琪、王皓南·推断待确认）
子公司负责人 制定跃竞方案并报 HR 备案 R 跃竞负责人（当前：徐莉·推断待确认）
值守人 节中按值守表响应故障，按备份人 → 项目负责人 → CTO 升级 R 各项目组值守人（按值守表）
员工 已读确认，按通知执行 I 全体员工

3. 办之前请准备

  • 国务院当年放假安排
  • 员工调休余额、年假余额（飞书假勤）
  • 各项目组节前交付节点与节中可能出故障的系统清单
  • 上一次长假通知与值守表（作为模板）
  • 节日福利、通勤福利、加班结算的现行口径

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布全年放假与调休日历，员工订阅 人事负责人 国务院公布后 5 个工作日内 飞书日历 + 公告 年度假期日历 🔧飞书固化
2 发起长假方案收集：居家/到岗日期、值守人、oncall、节后计划 人事负责人 春节前 45 天；其他长假前 30 天 多维表格 收集表 🔧飞书固化
3 项目组负责人填报本组方案 项目组负责人 收到后 5 个工作日内 多维表格 各组方案 👤人工判断
4 汇总差异，CEO 拍板：放假天数、公司调休日、抵扣顺序（先调休余额、再年假、后结清）、居家工作时间 人事负责人 / CEO 汇总后 3 个工作日内，且不晚于节前 15 天 飞书文档 决策记录 👤人工判断
5 起草正式通知（放假与补班、公司调休日抵扣、居家安排、值守表、福利、加班结算、离岗关电源门窗），综合部审核后发全员群并开启已读 人事负责人 节前 10 天前；法定调休上班日前 2 天另发提醒 飞书公告 + 文档 正式通知 🔧飞书固化
6 配置飞书假勤：补班日、公司调休日自动扣减余额 人事负责人 通知发布后 2 个工作日内 飞书假勤 假勤配置 🔧+🤖
7 节中值守：值守人按表响应，问题按备份人 → 项目负责人 → CTO 升级 值守人 节中 飞书日历 / 值班群 值守记录 👤人工判断
8 节后核对补班日考勤与调休扣减；节中加班转 HR-12 人事负责人 节后 5 个工作日内 飞书假勤统计 扣减记录 🤖自动化

5. 交付物与模板

  • 交付物：年度假期日历、节前正式通知、值守/oncall 表、调休扣减记录
  • 建议模板/表单：
    • 节前通知模板：放假时间、补班日、公司调休日及抵扣顺序、居家办公日期与工作时间、值守表链接、节日福利、加班结算口径、离岗安全提醒、咨询人
    • 方案收集表字段：项目组、负责人、到岗日期、居家日期、值守人、oncall 时段、紧急联系方式、节前必须完成事项、节后计划
    • 值守表字段：日期、系统/项目、值守人、备份人、升级人

6. 异常与升级

  • 节前 15 天仍无决策 → HR 书面提醒 CEO；研发先按最长可能假期预排 oncall → 节前 10 天仍无结论升级综合部负责人督办
  • 各组方案冲突 → HR 列出差异与影响 → CEO 1 个工作日内裁决
  • 员工调休余额不足以抵扣 → 依次抵扣年假，仍不足由 HR 与员工确认处理方式 → 争议升级综合部负责人
  • 节中故障值守人联系不上 → 备份人 → 项目负责人 → CTO（30 分钟内逐级）
  • 通知发出后需变更 → 发更正通知并 @全员，重新开启已读
  • 子公司口径与母公司不同 → 子公司负责人节前 10 天报 HR 备案

7. 衡量指标

  • 通知提前天数 = 正式通知发布日到放假首日的天数，目标 ≥ 10 天（春节 ≥ 20 天）
  • 通知已读率 = 发布后 2 天内已读人数 / 全员，目标 100%
  • 放假追问次数 = 节前群内询问“上不上班/放几天”的次数，目标 0
  • 值守覆盖率 = 有值守人的系统/项目 / 需值守系统，目标 100%
  • 节中故障响应时长 = 故障发现到值守人响应，目标 ≤ 30 分钟

8. 低效诊断

  • 现象：春节挪用工作日只口头说明，没有官方通告，各组各自传达、员工追问是否上班（发布环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：放假日期迟发，研发只能先按最长假期排 oncall，员工无法提前买票（时效环节）｜依据：「Leap产研决策部」2026-09
  • 现象：各项目组居家方案在群里分别回复，节奏不同，需要逐个转发汇总（收集环节）｜依据：「【跃迁】高管群」2026-01、「模态人事大主管」2026-01
  • 现象：春节调休是 5 天还是 7 天需追问老板确认（口径环节）｜依据：「模态人事大主管」2026-04
  • 现象：调休与加班费结算此前口头约定，6 月才在全员群补规则（结算衔接环节）｜依据：「模态集团（全员群）」2026-06
  • 现象：员工的加班天数、调休缺失对员工不透明，事后找 HR 手动补（余额环节）｜依据：「Leap产研决策部」2026-09
  • 现象：长假安排临近才讨论，节中应急由谁负责不明确（规划环节）｜依据：「跃竞模态董事会」2026-09、「跃迁基座」2026-01
  • 现象：调休上班日是否要提醒需临时确认（提醒环节）｜依据：「行政人事对接群」2026-02
  • 现象：放假、通勤、生日会、加班费集中在一次节前通知里同步，加班费细则仍待落地（通知内容环节）｜依据：「公司全员群」2026-09

9. 分支变体

  • 春节：允许错峰回家，节前盘点需线下处理的事务并排日期；居家办公周须同时提交 Q1 计划
  • 中秋国庆连休：公司调休日可选休年假或远程办公，按“先调休、再年假、后结清”抵扣
  • 法定调休上班日：提前 2 天提醒正常出勤
  • 子公司（跃竞）：自定方案，母公司方案仅供参考，报 HR 备案
  • 实习生：按实际出勤结算，不参与调休抵扣
  • 赶工期与节假日冲突：节中加班按 HR-12 处理

10. 待确认问题

  • 放假方案最终决策人是否为 CEO？研发侧安排可否由 CTO 决定？
  • 通知由 HR 还是综合部发布？是否需 CEO 审核后发？
  • 公司调休日“先调休、再年假、后结清”的抵扣顺序是否写入制度？
  • 春节居家办公的工作时间标准是否成文？
  • 节中值守/oncall 是否给补贴或调休？
  • 子公司是否纳入统一通知与假勤配置？
HR-14月度考勤核对与请假扣薪核定待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：每月初核对上月出勤，通知员工补卡补请假，由直属上级确认缺卡、事假、病假、迟到是否扣薪，输出考勤结果供工资核算时启动；考勤试运行期按周执行
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——各直属上级/组长（当前：杨萌、王皓南·推断待确认）、扣薪审核人创始人兼 CTO（当前：丁震宇·推断待确认）、口径决策人 CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 每周推送异常给上级 → ② 月初导出上月考勤并比对审批 → ③ 推送个人异常与补卡截止 → ④ 员工补卡/补请假 → ⑤ 直属上级确认扣薪意见 → ⑥ HR 按制度核定 → ⑦ 审核 → ⑧ 锁定考勤结果提交工资核算
  • 交付结果：月度考勤结果表（每人应出勤、实出勤、缺卡、事假、病假、迟到、旷工、扣薪天数）、直属上级确认记录、补卡截止通知、扣薪说明
  • 状态依据：已有飞书考勤、补卡入口、请假统计多维表格和《考勤管理制度》，但每月仍由 HR 手工导表、标黄、拆分给各负责人，2026-06、09 重复群发同样的补卡提醒；请假扣不扣薪由谁定口径不一，市场侧以周报替代打卡等特例未成文，统计表权限曾设置错误

1. 场景判定

  • 触发条件：每月 1 日核对上月考勤；考勤试运行期每周核对；管理层临时要求导出未打卡名单；员工对考勤扣薪提出异议
  • 典型说法：「请需要补卡的同事在明天下午2点前完成补卡申请」「如果在工资发放前没补的一律视为放弃」「每个人的考勤信息需要跟对应的直属上级对齐」「市场侧统一不做考勤」「导出一下到现在为止谁没打卡」
  • 判断问题：是不是在为工资核算确认一个周期的出勤结果？单日漏卡的补救走日常打卡流程
  • 不归本流程管：日常打卡与补卡操作 → 请走 HR-10；请假申请 → 请走 HR-11；加班工时统计与结算 → 请走 HR-12；工资计算与发放 → 请走 HR-15；人事数据权限 → 请走 HR-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
考勤核对人 导出、比对、推送异常、核定扣薪、锁定结果 R 人事负责人（当前：黄莹·推断待确认）
直属上级/组长 确认本组异常真实情况与扣薪意见，反馈真实工作时间 R 团队负责人（当前：杨萌、王皓南·推断待确认）
扣薪审核人 审核研发线扣薪项与特例 R 创始人兼 CTO（当前：丁震宇·推断待确认）
口径决策人 决定考勤口径（如只计请假和旷工、市场不打卡）；扣薪争议最终裁定 A CEO（当前：邴龙志·推断待确认）
通知协同 审核并转发月度补卡通知，审核非研发扣薪项，处理扣薪申诉 C 综合部负责人（当前：赵雪冰·推断待确认）
员工 自查考勤、在截止前补卡补请假 R 全体员工

3. 办之前请准备

  • 飞书假勤上月统计（工作台 → 假勤 → 统计）
  • 请假、外勤、出差、补卡、加班审批记录
  • 当月人员异动：入转调离；离职人员与顾问设“不参与考勤”
  • 特例名单：市场侧周报考勤、异地人员、线上实习生（带教确认）、集体外出活动
  • 考勤制度扣薪口径、员工带薪假余额
  • 部门-直属上级对照表（用于按权限分发）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 日常：每周一把上周缺卡、迟到、未请假缺勤推送本人与直属上级 人事负责人（配置） 每周一 10:00 飞书考勤机器人 周异常提醒 🤖自动化
2 导出上月考勤，与审批记录自动比对，标记缺卡、事假、病假、迟到、旷工 人事负责人 每月 1 日 飞书假勤统计 + 多维表格 异常清单 🤖+👤
3 机器人推送个人异常与补卡截止时间；通知群同步发布截止时间、补卡路径、逾期视为放弃并影响工资 人事负责人 每月 1 日 机器人 + 通知群 补卡通知 🔧+🤖
4 员工自查并补卡、补请假；直属上级当日审批 员工 / 直属上级 补卡截止每月 2 日 14:00；审批截止 2 日 18:00 飞书补卡/请假审批 补卡单 🔧飞书固化
5 直属上级在多维表格（只看本组）确认剩余异常的真实情况与扣薪意见；有带薪假余额的先抵扣 直属上级 每月 3 日 12:00 前 多维表格（按人员权限） 确认记录 👤人工判断
6 按制度核定扣薪；逾期未补卡按缺勤处理；特例按清单处理 人事负责人 每月 3 日 多维表格 扣薪核定表 👤人工判断
7 审核扣薪项与特例 CTO（研发线）/ 综合部负责人（其他） 每月 3 日 17:00 前 飞书审批 审核意见 👤人工判断
8 锁定考勤结果，提交工资核算；扣薪在工资条单列原因 人事负责人 每月 3 日下班前 多维表格 → 工资表 月度考勤结果表 🔧+🤖

5. 交付物与模板

  • 交付物：月度考勤结果表、直属上级确认记录、补卡截止通知、扣薪说明
  • 建议模板/表单：
    • 考勤结果表字段：员工、部门、直属上级、考勤类型（打卡/周报/不参与）、应出勤天数、实出勤天数、缺卡次数、迟到次数、事假、病假、年假/调休、旷工、带薪假抵扣、扣薪天数、上级意见、HR 核定、审核人
    • 补卡通知模板：考勤月份、截止时间、补卡路径、逾期后果、特殊情况联系人
    • 权限规则：直属上级仅能查看本组成员，HR 与审核人可看全部

6. 异常与升级

  • 员工逾期未补卡 → 按通知视为放弃，按缺勤处理 → 有正当理由的，由直属上级说明后 HR 复核
  • 集体活动（如大会）导致集体缺卡 → 组织方事先提交集体外出/外勤申请；未提交的由组织方在补卡截止前提供名单，HR 统一补录
  • 直属上级未按时确认 → 按制度默认口径执行并抄送其上级
  • 特例岗位（市场周报、异地、线上实习生）未提交出勤确认 → 部门负责人每月 2 日前提交 → 未提交升级综合部负责人
  • 员工对扣薪有异议 → 发薪后 5 个工作日内向 HR 申诉，HR 与直属上级复核，确属错误的下月补回 → 未解决升级综合部负责人
  • 统计表权限错误、他人可见 → 立即收回权限并报综合部负责人
  • 拍板口径：考勤口径与扣薪规则由 CEO 作为唯一 A 决定；月度扣薪项由 CTO（研发线）、综合部负责人（其他线）审核执行，扣薪申诉经综合部负责人仍未解决的报 CEO 裁定

7. 衡量指标

  • 考勤锁定准时率 = 在每月 3 日前锁定的月份 / 总月份，目标 100%
  • 截止前补卡完成率 = 截止前处理的异常 / 月初异常总数，目标 ≥ 90%
  • 扣薪更正次数 = 发薪后因考勤错误补回的人次，目标每月 0
  • 月度考勤处理工时 = HR 每月在考勤核对上的投入，目标 ≤ 半个工作日
  • 重复催办次数 = 每月群发补卡提醒的次数，目标 ≤ 1 次

8. 低效诊断

  • 现象：HR 每月手工导出、标黄、拆分部门考勤表，导出后数据更新还要重新导（导出环节）｜依据：「【模态】综合部」2026-06
  • 现象：同样的补卡提醒每月群发，再由负责人在部门内转达（催办环节）｜依据：「【模态】业务负责人」2026-06、「【模态】业务负责人」2026-09、「模态跃迁通知群」2026-09
  • 现象：请假直接扣薪还是由直属上级评估后决定不明确，过渡期先评估不扣（扣薪判定环节）｜依据：「模态人事大主管」2026-05
  • 现象：技术、市场、异地考勤口径不一，市场不打卡改以周报统计，有人整月无考勤记录（口径环节）｜依据：「模态人事大主管」2026-06、「【模态】综合部」2026-06
  • 现象：考勤信息未与直属上级对齐就进入工资单（确认环节）｜依据：「模态人事大主管」2026-04
  • 现象：集体活动当天缺卡如何处理，靠同事在群里回答（特例环节）｜依据：「模态跃迁通知群」2026-06
  • 现象：管理层临时要求导出未打卡名单，缺日常看板（看板环节）｜依据：「模态人事大主管」2026-07
  • 现象：考勤试运行期每周人工汇总情况（试运行环节）｜依据：「模态人事大主管」2026-01

9. 分支变体

  • 全职员工：按飞书打卡统计
  • 实习生：线下按打卡；线上实习生由带教人确认出勤
  • 市场侧：以周报/日报统计出勤，不打卡，由部门负责人确认
  • 异地人员（如苏州）：由当地负责人确认
  • 顾问、已离职人员、子公司人员：设“不参与考勤”
  • 考勤试运行期：每周出报告，只提醒不扣薪
  • 新员工入职首月：按实际入职日计算应出勤

10. 待确认问题

  • 扣薪判定权：按制度直接执行，还是先由直属上级评估？
  • 是否采纳“只计请假和旷工、不计迟到”的建议？
  • 每月 2 日 14:00 补卡截止、3 日锁定，能否与工资节点（4 日出工资条、8 日发薪）衔接？
  • 补卡次数上限与凭证要求是否写入正式制度？
  • 市场侧不打卡是否作为正式制度？
  • 子公司人员考勤由谁负责？
HR-15月度工资核算发放与员工个税答疑待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨3 × 险5

  • 适用场景：每月发薪周期内，人事确定薪资明细后由财务测算个税，经管理层审核审批后发放并推送工资条；处理错发、金额异常、个税申报异常与员工退补税咨询
  • 负责人：主责——财务负责人（当前：黄梦婷·推断待确认）；协同——人事负责人（薪资明细与工资条，当前：黄莹·推断待确认）、CEO（审核审批，当前：邴龙志·推断待确认）、COO（审核，当前：常元和·推断待确认）、创始人兼 CTO（审核，当前：丁震宇·推断待确认）、跃竞负责人（跃竞薪酬核对，当前：徐莉·推断待确认）；兜底——综合部负责人
  • 核心流程：① 1 日收集异动 → ② 3 日薪资表定稿 → ③ 管理层审核 → ④ 5 日前测税反写 → ⑤ 付款审批 → ⑥ 8 日双人复核发放 → ⑦ 推送工资条确认 → ⑧ 个税申报与答疑
  • 交付结果：经审核的分主体工资表、付款回单、员工已确认的飞书工资条、个税申报回执、异常处理记录
  • 状态依据：2026-03 起已形成"人事定薪 → 财务录入测税 → CEO 审核"的分工，2026-05 起有飞书工资条，但 2026-03 至 2026-09 仍多次出现发薪延期、审批等待、公式重复扣减、错发到他人账户、个税申报反复作废重报，发薪相关追问约 25 次

1. 场景判定

  • 触发条件：每月发薪周期开始；员工询问发薪时间、扣税原因、工资明细；发现错发、少发、多发；个税 App 申报被拒或预扣与预期不符
  • 典型说法：「啥时候发工资」「发薪进度卡谁那了」「是不是扣多了」「我们没工资单」「税务老是作废重报」「财务是哪位」
  • 判断问题：问题与"本月工资多少、何时到账、扣了多少税"有关吗？是 → 本流程
  • 不归本流程管：定级与调薪 → 请走 HR-09；考勤与请假扣薪核定 → 请走 HR-14；薪资明细编制与人员异动细则 → 请走 HR-15；社保公积金 → 请走 HR-16；AI 补贴发放 → 请走 FIN-10；劳务/顾问/奖金 → 请走 FIN-14；子公司余额不足发薪 → 请走 FIN-33；企业税种申报 → 请走 FIN-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
测税与发放 测算个税反写工资表、核对余额、执行打款、个税申报、答疑 R 财务负责人（当前：黄梦婷·推断待确认）
薪资明细 异动表、薪资表、发起付款流程、推送工资条 R 人事负责人（当前：黄莹·推断待确认）
最终审批 审核工资表、审批付款 A CEO（当前：邴龙志·推断待确认）
审核 审核基数与计算口径 C COO（当前：常元和·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认）
跃竞薪酬 核对跃竞主体名单与金额 C 跃竞负责人（当前：徐莉·推断待确认）
员工 确认工资条、反馈异常 I 全体员工

3. 办之前请准备

  • 人事：当月异动表（入离转调、试用期、实习/兼职）、考勤结果、上月工资表
  • 财务：分主体工资表模板（公式锁定）、专项附加扣除信息、累计个税数据、各主体账户余额
  • 审核人：与上月的差异清单
  • 员工咨询个税：个税 App 截图（遮挡证件号）、问题描述、所属主体

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收集当月异动与考勤，建立当月薪资表 人事负责人 每月 1 日 飞书表格 异动表 🔧飞书固化
2 薪资表定稿（公式模板锁定，禁止手改公式），生成与上月差异清单 人事负责人 每月 3 日 飞书表格 定稿表、差异清单 🔧+🤖
3 审核差异与基数，表内评论确认 CEO/COO/CTO 收到后 1 个工作日内 飞书表格 审核记录 👤人工判断
4 测算个税并反写工资表，分主体核对余额 财务负责人 每月 5 日前 个税系统/表格 含税工资表 👤人工判断
5 分主体发起付款审批（附汇总，明细另存） 人事负责人 每月 6 日 飞书付款审批 付款单 🔧飞书固化
6 审批付款；超 24 小时未批自动提醒 CEO 提交后 1 个工作日内 飞书审批 审批通过 🔧飞书固化
7 打款前双人复核收款账户与金额，执行打款 财务负责人（复核：人事负责人） 每月 8 日 网银 付款回单 👤人工判断
8 推送飞书工资条，员工点击确认 人事负责人 发放当天 飞书工资条 确认记录 🔧飞书固化
9 个税申报；员工咨询 2 个工作日内答复，共性问题进 FAQ 财务负责人 申报期内；咨询后 2 个工作日 个税系统/FAQ 申报回执、FAQ 🔧+🤖

5. 交付物与模板

  • 交付物：分主体工资表、差异清单、付款回单、工资条确认记录、个税申报回执、《工资与个税 FAQ》、异常处理记录
  • 发薪日历（建议）：1 日筹备、3 日定稿、5 日测税、8 日发放
  • 差异清单字段：姓名、主体、本月应发、上月应发、差额、变动原因（异动/考勤/补贴/扣款）、审核意见
  • FAQ 首批条目：补贴并入工资计税、福利计税、发放日与申报口径导致的"看似扣多"、年度汇算补退税、工资条查看方式、财务对接入口

6. 异常与升级

  • 付款审批超过 1 个工作日未处理 → 人事飞书加急提醒 → COO 协调（最迟发薪日上午）
  • 预计不能按时发放 → 财务提前 1 个工作日在全员群通知原因和新日期 → CEO
  • 主体账户余额不足 → 当天上报 CEO，按 FIN-33 处理
  • 错发到非本人账户 → 当天联系收款人退回，复盘复核环节 → 财务负责人（当日）
  • 少发、重复扣减 → 核实后 3 个工作日内补发 → 人事负责人
  • 多发 → 与员工确认，次月扣回或退回 → 财务负责人
  • 个税申报被拒或需作废重报 → 财务查明原因，1 个工作日内告知员工 → 外部代账/税务顾问
  • 员工向公司出售个人资产 → 不通过工资发放，按资产采购 + 发票处理 → 财务负责人

7. 衡量指标

  • 准时发放率：在约定发薪日当天发放的月份占比，目标 100%
  • 薪资差错：每月错发、少发、多发人次，目标 0
  • 审批等待时长：付款审批提交到通过的小时数，目标 ≤ 24 小时
  • 个税咨询答复时长：目标 ≤ 2 个工作日
  • 工资条确认率：发放后 3 日内确认比例，目标 ≥ 95%

8. 低效诊断

  • 现象：发薪付款审批集中在单一审批人，没有到期提醒，需多次人工催办，员工在群里追问发薪时间｜依据：「鼎慧产研决策部」2026-03
  • 现象：发薪进度不可见，"卡在谁那"要追问，每月存在延期｜依据：「薪酬对接群」2026-05、「薪酬对接群」2026-09
  • 现象：薪资表计算公式混用，按天数比例重复扣减｜依据：「薪酬对接群」2026-06
  • 现象：早期没有工资单，员工不清楚额外款项用途；补贴并入工资后的计税口径没人说明｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-05
  • 现象：员工不知道财务对接人，个税问题由同事凭经验解答｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-05
  • 现象：大批量人员异动靠手工处理，人工量大｜依据：「薪酬对接群」2026-03

9. 分支变体

  • 主体：武汉模态、湖北鼎慧、苏州模态、跃竞分别核算发放；跃竞名单与跃竞负责人单独核对
  • 用工类型：正式员工走工资；实习生按实习协议；兼职、劳务、顾问不进工资表（见 FIN-14）
  • 员工向公司出售个人资产：不走工资，按采购 + 发票结算
  • AI 补贴：与工资分开打款，但并入计税

10. 待确认问题

  • 发薪日是否固定为每月 8 日？1/3/5/8 日历是否可行？
  • 本流程主责是财务还是人事？付款审批由谁发起？
  • 是否设置 CEO 不在时的代理审批人？
  • 个税申报自办还是外部代账？作废重报的原因是否已查清？
  • 员工个税咨询的统一入口（服务台/机器人/指定岗位）？
  • 员工向公司出售资产的结算规则是否成文？
HR-16社保公积金缴纳与增减员待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：员工入职、离职、在模态/鼎慧/苏州/跃竞等主体间变更劳动关系，或缴费基数调整、员工咨询缴纳情况、税务系统发出社保与个税口径差异预警时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——社保办理人（当前：侯明月·推断待确认，拟交接至人事）、财务负责人（当前：黄梦婷·推断待确认）、创始人兼 CTO（口径，当前：丁震宇·推断待确认）、COO（主体规划，当前：常元和·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 入离职/主体变更自动进入当月增减员清单 → ② 20 日前核对主体、基数、比例 → ③ 25 日前办理增减员与申报 → ④ 财务付款 → ⑤ 扣款对账 → ⑥ 更新员工缴纳台账 → ⑦ 每季度盘点应缴未缴 → ⑧ 税务预警处置
  • 交付结果：月度增减员清单与办理回执、社保公积金明细表、员工缴纳台账（主体、基数、比例、起缴/停缴月）、付款记录、季度盘点报告、预警处置记录
  • 状态依据：月度增减员已在执行（2026-08 已完成各公司增减员及申报），但没有统一增减员台账和基数/比例规则；2026-04 盘点发现多人多月未缴，入职时说要交却没交；办理职责在行政与人事之间有分歧、交接断档；人员主体频繁变更导致工资与公积金不在同一主体，同类问题约 20 次

1. 场景判定

  • 触发条件：新员工入职；员工离职；员工劳动关系主体变更；年度基数调整或员工申请特殊基数；员工咨询缴纳基数与起缴月；税务/社保系统发出口径差异预警；社保办理人变更
  • 典型说法：「社保是当月入职就买吗」「公积金后续统一一个标准吧」「变的话工资发放、社保公积金也要配套操作，合同也应该配套」「已完成本月各公司社医保公积金增减员及申报」
  • 判断问题：这件事是否改变某位员工的社保、医保、公积金缴纳状态、主体或基数？
  • 不归本流程管：劳动合同签署与用工主体判定 → 请走 HR-04；入职办理 → 请走 HR-05；离职办理 → 请走 HR-27；工资中的个人扣款 → 请走 HR-15；商业保险与体检 → 请走 HR-22；月度税务申报 → 请走 FIN-35；子公司成本隔离 → 请走 FIN-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
增减员负责人 生成清单、核对主体与基数、维护台账、季度盘点 R 人事负责人（当前：黄莹·推断待确认）
社保办理人 在社保、医保、公积金系统办理增减员与基数申报 R 社保办理人（当前：侯明月·推断待确认，拟交接至人事）
决策人 决定缴纳主体、基数口径、比例、补缴与特殊情况 A CEO（当前：邴龙志·推断待确认）
口径协同 主体规划、残保金与人员分布、对外口径 C 创始人兼 CTO（当前：丁震宇·推断待确认）、COO（当前：常元和·推断待确认）
财务 付款缴费、扣款对账、接收并分析税务预警、对接代账机构 R 财务负责人（当前：黄梦婷·推断待确认）
员工 提供参保材料，确认起缴月 I 全体员工

3. 办之前请准备

  • 入离职审批单与劳动合同主体（应与发薪主体一致）
  • 参保所需个人信息（通过表单收集，限 HR 与办理人可见，不在群里传）
  • 基数口径（按武汉最新最低基数或实际工资，以制度为准）与各主体公积金比例
  • 社保公积金明细表、员工主表
  • 各主体社保/公积金账户与 U 盾（含异地账户）
  • 当月办理截止日（约每月 25 日）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入职、离职、主体变更审批通过后自动写入当月增减员清单 人事负责人（配置） 审批通过当天 多维表格（与入离职审批联动） 增减员清单 🤖+👤
2 核对缴纳主体（与发薪、合同主体一致）、基数、比例、起缴/停缴月；特殊基数须审批 人事负责人 每月 20 日前 多维表格 核对后清单 👤人工判断
3 办理社保、医保、公积金增减员与基数申报 社保办理人 每月 25 日前 社保 / 公积金系统 办理回执 🔧飞书固化
4 提交付款审批并缴费 财务 扣款日前 飞书付款审批 付款记录 🔧飞书固化
5 扣款明细与清单逐人对账，个人部分同步给工资核算 人事负责人 / 财务 扣款后 3 个工作日内 社保公积金明细表 对账结果 🤖自动化
6 更新员工缴纳台账：主体、基数、比例、起缴/停缴月、状态 人事负责人 对账完成当天 员工主表 缴纳台账 🔧飞书固化
7 盘点应缴未缴、主体不一致名单，提出补缴与调整方案报 CEO 人事负责人 每季度首月 10 日前 多维表格 季度盘点报告 🤖+👤
8 税务/社保预警：财务转 HR，双方分析原因与后果，CEO 决策并书面记录 财务 / 人事负责人 / CEO 收到预警 1 个工作日内转出，3 个工作日内出处置意见 飞书文档 预警处置记录 👤人工判断

5. 交付物与模板

  • 交付物：月度增减员清单与回执、社保公积金明细表、员工缴纳台账、季度盘点报告、预警处置记录
  • 建议模板/表单：
    • 增减员清单字段：员工、类型（增员/减员/主体变更/基数调整）、缴纳主体、基数、社保比例、公积金比例、起缴或停缴月、来源审批单号、办理人、办理日期、回执
    • 员工缴纳台账字段：员工、劳动合同主体、发薪主体、社保主体、公积金主体、基数、比例、起缴月、状态（正常/未缴/补缴中/停缴）、备注
    • 办理日历：每月 20 日核对、25 日前办理、扣款后 3 个工作日对账

6. 异常与升级

  • 入职晚于当月办理截止日 → 次月增员，HR 书面告知员工起缴月
  • 发现应缴未缴 → HR 列出补缴月份与费用测算 → CEO 5 个工作日内决策
  • 员工要求不缴纳或折现 → 不接受口头约定，需 CEO 书面审批并附法务意见
  • 主体变更 → 工资、社保、公积金、合同同月配套变更；只变一项的需 CEO 书面确认
  • 异地账户 U 盾丢失或不可用 → 当日报财务负责人，补办期间由当地经办或代账机构协助
  • 办理人变更 → 交接清单（账户、U 盾、在途事项、台账）完成前由原办理人继续办理 → 职责分歧升级 CEO 拍板
  • 代账机构未按期办理 → 财务负责人跟进 → 影响扣款时升级 CEO

7. 衡量指标

  • 增减员按期办理率 = 当月截止日前办理的人次 / 应办理人次，目标 100%
  • 应缴未缴人数 = 季度盘点发现的应缴未缴人数，目标 0
  • 主体一致率 = 工资、社保、公积金、合同同一主体的人数 / 总人数，目标 100%
  • 扣款对账差异 = 扣款与清单不一致的人次，目标每月 0
  • 预警处置时长 = 收到预警到形成书面决策的工作日，目标 ≤ 3 个工作日

8. 低效诊断

  • 现象：当月入职是否当月缴纳、基数比例多少没有成文规则，员工询问时靠回忆（口径环节）｜依据：「行政人事对接群」2026-02
  • 现象：办理职责在行政与人事之间有分歧，人员信息权限收回后才提出交接，在群里公开争执（职责与交接环节）｜依据：「行政人事对接群」2026-03
  • 现象：盘点发现多名员工多月未缴，入职承诺与实际缴纳不符（台账环节）｜依据：「模态人事大主管」2026-04、「模态人事大主管」2026-05
  • 现象：各主体公积金基数比例不同，个人特殊基数临时处理（标准环节）｜依据：「模态人事大主管」2026-02、「模态人事大主管」2026-04
  • 现象：人员主体频繁变更，工资在一个主体、公积金在另一个主体，口径混乱（主体环节）｜依据：「薪酬对接群」2026-04、「薪酬对接群」2026-05、「薪酬对接群」2026-07
  • 现象：人数增长涉及残保金提档，主体人员安排需管理层临时讨论（规划环节）｜依据：「薪酬对接群」2026-06
  • 现象：税务预警只做一次性决策，没有处置规则（预警环节）｜依据：「财务部」2026-06

9. 分支变体

  • 模态 / 鼎慧 / 苏州分公司：按各主体账户办理，基数比例逐步统一
  • 跃竞：暂不统一，由跃竞自行办理，HR 备案
  • 主体间调动：工资、社保、公积金、合同同月配套变更
  • 实习生、兼职、劳务、外包：按协议不缴纳
  • 特殊基数：基数可按个人调整，比例保持统一
  • 个别折现：须书面审批
  • 残保金：主体人员分布由管理层规划

10. 待确认问题

  • 社保办理人是行政还是人事？交接是否已完成？
  • 增员截止日（每月 25 日）与“当月入职当月缴纳”的规则是否确定？
  • 基数口径：按最低基数还是实际工资？对外口径如何统一？
  • 各主体公积金比例是否统一？跃竞何时纳入？
  • 是否继续委托代账机构办理？由谁对接？
  • 税务预警的处置原则是否需要法务出具意见？
  • 员工缴纳台账放在哪个系统，谁有查看权限？
HR-17AI工具补贴发放与调整待优化144

状态：待优化｜证据：有证据（卡片 9 张 / 会话 12 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：每月为员工发放 AI 工具补贴，以及新入职、实习、岗位变化、警告取消、离职、超额申请、规则调整等需要核定或变更补贴档位时启动
  • 负责人：主责——人事专员（当前：黄莹·推断待确认）；协同——财务专员（当前：黄梦婷·推断待确认）、IT 核定人（当前：杨明学·推断待确认）、补贴制度制定人（当前：丁震宇·推断待确认）、法务（当前：李瑶·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）；档位例外审批——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 月初更新名单与档位 → ② 例外调档审批 → ③ 出补贴发放表 → ④ 财务 15 日打款 → ⑤ 发放通知与 FAQ → ⑥ 月底员工提交支出凭证 → ⑦ IT 核定达标并记录暂停/恢复 → ⑧ 超额部分走报销
  • 交付结果：当月按时到账的 AI 补贴；与工资分开的《AI 补贴发放表》；《AI 补贴名单与核定台账》（含档位、达标结果、暂停/恢复月份）；单一版本的补贴规则 wiki + FAQ
  • 状态依据：已有每月 15 日发放的固定做法、讨论稿制度《公司 AI 补贴落实与核定规则》和核定表格；但 2026-01～10 规则变了至少 6 次（报销制改直接发、调整发放日、要求充值自有产品后又暂停、改为月底核定），员工反复追问“有没有补贴/还填不填报销表/包不包含某工具”约 20 次，新人首月漏发、发放日要靠人提醒

1. 场景判定

  • 触发条件：每月发放周期开始（每月 1 日）；有员工入职、转正、调岗、离职、实习开始/结束；员工被警告需暂停补贴或恢复；员工当月支出超过补贴额度要申请补充；公司调整补贴口径
  • 典型说法：「补贴是无条件，报销是申请制」「AI 补贴统一调整为每月 15 号发放」「今天入职，他这个月有 AI 补贴吗」「那还填报销表吗」「要基本用够 AI 补贴额度吧」
  • 判断问题：这笔钱是不是“按月、按档位、用于员工自购 AI 工具”的补贴？如果是公司统一采购的账号/API 额度或项目体验类 AI 产品费用，就不归本流程
  • 不归本流程管：公司统一采购的 AI 账号、订阅与号池 → 请走 X-SEC-14（AI 编程工具订阅账号开通、充值与防封管理）；模型 API Key → 请走 RND-27；算力等其他非实体资产申领 → 请走 ADM-34（云服务与软件订阅等非实体资产申领与释放）；体验类 AI 产品、项目用 AI 费用报销 → 请走 FIN-06（日常费用报销提交与审核）；因质量问题扣减补贴的事实认定 → 请走 HR-19；警告、调岗等处置本身 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
名单维护与发放统筹 维护名单与档位、出发放表、发通知、答疑 R 人事专员（当前：黄莹·推断待确认）
打款 审核发放表，按时打款，单独记账（与工资分开） R 财务专员（当前：黄梦婷·推断待确认）
支出核定 核对凭证、汇总合规支出、抽查使用情况、记录达标结果 R IT 核定人（当前：杨明学·推断待确认）
规则制定 定档位原则、核定口径、抽查标准，解释规则 A 补贴制度制定人（当前：丁震宇·推断待确认）
例外审批 个人调档异议、特殊月份预支、规则重大变更 A（升级） CEO（当前：邴龙志·推断待确认）
合规审核 审补贴性质（非工资组成）、个税口径、制度条款 C 法务（当前：李瑶·推断待确认）
部门确认 确认本部门人员岗位类别（研发相关/职能） C 各部门负责人（当前：待指定）
员工 自购官方 AI 套餐，月底前提交凭证 I/R 全体适用员工

3. 办之前请准备

  • 当月人员变动清单：入职（含到岗日）、转正、调岗、离职（含最后工作日）、实习开始/结束
  • 当月需暂停或恢复补贴的人员清单（附审批或处置记录链接）
  • 现行补贴规则 wiki 的版本号；本月是否有规则变更
  • 上月核定结果（未达标人员名单）
  • 员工凭证材料：官方套餐付费截图、商家 Invoice/发票；超额申请需附发票

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 从人员主表同步当月入转调离，按岗位类别自动带出档位；当月 15 日（含）前到岗计入当月 人事专员 每月 8 日前 多维表格「AI 补贴名单」 当月草稿名单 🔧+🤖
2 汇总例外项（调档、特殊预支、暂停/恢复）发起审批 人事专员 每月 10 日前 飞书审批 例外审批单 🔧飞书固化
3 审批例外项 补贴制度制定人 / CEO 提交后 1 个工作日内 飞书审批 审批结论 👤人工判断
4 合并上月核定结果（未达标者本月暂停），锁定名单，生成《AI 补贴发放表》交财务 人事专员 每月 12 日前 多维表格导出 发放表 🤖自动化
5 审核发放表并打款，与工资分开单独入账；15 日遇节假日提前到前一个工作日 财务专员 每月 15 日 网银 / 财务系统 到账记录 👤人工判断
6 机器人推送发放通知，附规则 wiki 与 FAQ 链接；当月新入职员工单独私信说明 人事专员 发放当天 飞书机器人 发放通知 🔧+🤖
7 员工提交当月支出凭证（官方套餐截图、Invoice），机器人在 25 日提醒未提交者 员工 每月最后一个工作日前 飞书表单 月度申报记录 🔧飞书固化
8 核对凭证，汇总合规支出，判断是否达到当月补贴 80%；随机抽查使用情况；记录暂停/恢复月份 IT 核定人 次月 5 日前 多维表格「核定台账」 核定结果 🤖+👤
9 通知未达标员工下月暂停，并同步给人事专员进入下月名单 IT 核定人 核定后 1 个工作日内 飞书机器人 暂停通知 🤖自动化
10 超出额度部分（不超过当月补贴 30%）凭发票走报销 员工 → 财务专员 次月 10 日前提交 飞书报销审批 报销单 🔧飞书固化
11 规则变更：改 wiki 并升版本号，法务审条款，全员公告并更新 FAQ 补贴制度制定人、人事专员 生效前 5 个工作日公告 飞书 wiki + 公告 新版规则 👤+🔧

5. 交付物与模板

  • 交付物：《AI 补贴名单》、例外审批单、《AI 补贴发放表》、到账记录、月度申报记录、《核定台账》、规则 wiki + FAQ
  • 建议模板/表单：
    • 多维表格「AI 补贴名单」：员工、主体、部门、岗位类别（研发相关/职能/实习）、档位、到岗日、离职日、当月是否发放、暂停原因、审批链接、发放月份
    • 飞书表单「月度 AI 支出申报」：员工、月份、工具名称、套餐类型（官方/非官方）、付费金额、付费截图、Invoice、是否申请超额报销
    • 「核定台账」：员工、月份、补贴额、合规支出、达标比例、是否抽查、抽查结论、下月是否暂停、恢复月份
    • FAQ 至少包含：谁有补贴、入职当月怎么算、哪些支出计入、年付怎么算、超额怎么报、个税怎么处理、子公司是否适用

6. 异常与升级

  • 新人入职当月漏发 → 人事专员 2 个工作日内补发审批，财务 3 个工作日内补打款 → 超时升级综合部负责人
  • 员工对档位有异议 → 人事专员收集岗位说明，提交补贴制度制定人裁定（3 个工作日内）→ 仍有异议升级 CEO
  • 升级拍板：常规例外项由补贴制度制定人（A）审批；出现以下任一情形时由 CEO 作为 A（升级）审批——档位异议经制定人裁定后仍未解决、特殊月份预支、规则重大变更（改档位额度、改发放方式、改核定门槛）
  • 凭证不全或疑似虚假 → IT 核定人退回补交（3 个工作日内）；逾期按未达标处理；疑似造假转人事专员按 HR-20 处置
  • 员工提出“补贴是否算工资/个税”争议 → 人事专员转法务给书面口径（5 个工作日内）
  • 打款失败或 15 日未到账 → 财务专员当日告知人事专员，1 个工作日内补打并在群内说明

7. 衡量指标

  • 按时到账率：15 日（含）前到账人数 ÷ 应发人数，目标 100%
  • 新人首月漏发次数：目标每月 0 次
  • 名单差错率：补发、错发、多发人次 ÷ 应发人数，目标 ≤ 1%
  • 核定及时率：次月 5 日前完成核定的月份占比，目标 100%
  • 规则类追问次数：群内/私聊关于补贴口径的提问次数，目标每月 ≤ 3 次（FAQ 上线后）
  • 达标率：当月合规支出 ≥ 80% 的人数 ÷ 应发人数（观察指标）

8. 低效诊断

  • 现象：新人入职当月是否有补贴、名单截止日以哪天为准反复确认，发放前需要专人提醒人事与财务（名单生成环节没有和入职流程打通）｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-09
  • 现象：补贴规则多次变更（发放日、是否充值自有产品、暂停充值），每次变更后员工反复追问适用范围（规则只靠群公告发布，没有单一版本的 wiki + FAQ）｜依据：「模态跃迁通知群」2026-03、「模态跃迁通知群」2026-06、「模态跃迁通知群」2026-09
  • 现象：由报销制改为直接发放后，员工不清楚还要不要填报销表（变更公告未说明新旧衔接）｜依据：「技术部」2026-02
  • 现象：补贴覆盖哪些订阅、封号后怎么处理没有说明（制度未成文，额度调整只在群里口头宣布）｜依据：「Leap产研测」2026-08
  • 现象：档位口径不一，部门负责人层级、销售/FDE 岗位档位反复讨论（岗位类别没有写进人员主表）｜依据：「模态人事大主管」2026-05、「人事&法务群」2026-10
  • 现象：核定规则“二选一”“最低标准”理解不同，子公司是否适用不清（核定规则草案未定稿即执行）｜依据：「忠橙星行星引擎」2026-10
  • 现象：固定按月发放的补贴有被认定为工资的风险，制度在已发放后才补法务评审（制度上线缺法务前置审核）｜依据：「人事&法务群」2026-10

9. 分支变体

  • 研发相关岗位及部门负责人：高档；职能岗位：低档；具体额度以现行规则 wiki 为准
  • 实习生：是否发放、按哪一档由例外审批确定
  • 销售 / FDE：档位单独议定，未定前按例外审批处理
  • 子公司：跃竞、曜途自行决定是否适用；鼎慧默认复用母公司规则
  • 自有产品使用要求：曾要求发放当日充值 LeapALL 并核查，2026-09 起暂停；如恢复，在步骤 8 增加“自有产品使用核查”
  • 年付套餐：由 IT 核定人个案处理，按月分摊计入合规支出
  • 特殊月份预支：经 CEO 审批后在步骤 2 例外项中登记

10. 待确认问题

  • 主责是人事专员还是 IT 核定人？名单维护、核定、打款三段是否按本 SOP 分工？
  • 入职截止日以“当月 15 日（含）前到岗”计入当月是否确认？离职当月、请假期间是否照发？
  • 80% 达标门槛、超额 30% 内可报销、未达标暂停下月，这三条是否已定稿？
  • 补贴是否随工资计税还是单独发放？法务对“非工资组成、实报实销、公司有权调整”的条款是否已审定？
  • 销售、FDE、实习生、部门负责人的档位如何确定？“部门负责人”指一级还是二级以上？
  • 是否继续要求使用/充值公司自有产品？如恢复，核查标准是什么？
  • 子公司（跃竞、曜途、鼎慧）是否需要各自的版本？
HR-18积分激励制度运行待新建225

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：积分激励、期权激励、知识产权激励等制度发布后，需要宣贯答疑、编制积分预算、组织申报、核验公示、登记台账、兑换发放时启动
  • 负责人：主责——积分运营组牵头人（总经办，当前：赵雪冰·推断待确认）；协同——人事负责人（当前：黄莹·部门报送人）、财务负责人（当前：黄梦婷·部门报送人）、积分系统负责人（当前：丁震宇·推断待确认）、各一级部门负责人；决策——积分管理委员会（董事会成员 + 一级部门负责人，召集人当前：邴龙志·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 制度发布与宣贯（写明适用范围）→ ② 季度积分预算 → ③ 个人/部门申报 → ④ 运营组初核 → ⑤ 委员会审议 → ⑥ 公示与异议复核 → ⑦ 登记台账 → ⑧ 兑换发放
  • 交付结果：带适用范围和 FAQ 的制度宣贯包；季度积分预算；经委员会决议并公示的积分结果；积分台账（个人、部门、来源、余额）；与财务对接的兑换/发放清单
  • 状态依据：积分激励制度 2.0、知识产权激励办法、委员会与运营组职责已成文发布；但积分系统未开测、台账待建、申报与核验流程尚未跑过一个完整周期，2026-07～08 宣发材料重做多次，适用范围、子公司、期权认购等口径在宣贯后才补说明

1. 场景判定

  • 触发条件：新制度或制度修订发布；季度开始需编制积分预算；员工或部门有可计分的贡献（有效产品反馈、FDE/案例、研发工作量、创新成果、知识产权）；季度末评估；员工申请兑换积分或认购期权
  • 典型说法：「积分那个有没有省流版」「积分的文件在哪」「我们组的也能用于买期权吗」「有效反馈纳入后面的积分体系和年度绩效」「各部门申报，总经办统筹，委员会决策，运营组执行」
  • 判断问题：这件事是否涉及“积分的预算、获得、核验、公示、兑换”？如果只是研发日常绩效评级或质量扣款，不归本流程
  • 不归本流程管：研发迭代绩效评级、Bug 质量奖惩 → 请走 HR-19；AI 工具补贴 → 请走 HR-17；工资单与月度薪酬发放 → 请走 HR-15（月度工资核算与发放）；专利申报与权属管理 → 请走 POL-11（专利申请与代理对接）；知识产权激励的申报与兑现节点 → 请走 LEG-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
运营组牵头 制度宣贯、汇总预算、组织申报、初核、公示、台账、异议受理 R 积分运营组牵头人（总经办，当前：赵雪冰·推断待确认）
委员会 审议预算与贡献等级，集体决议；利益相关者回避 A 积分管理委员会（召集人当前：邴龙志·推断待确认）
部门负责人 提交部门预算与申报，部门积分分配到个人 R 各一级部门负责人（当前：待指定）
人事 核对人员在职状态、主体归属，对接年度绩效 C 人事负责人（当前：黄莹·部门报送人）
财务 核对兑换资金预算，积分兑奖金随工资发放 R 财务负责人（当前：黄梦婷·部门报送人）
系统 积分系统开发、权限下放、数据导出 R 积分系统负责人（当前：丁震宇·推断待确认）
法务 期权认购、知识产权权属条款审核 C 法务负责人（当前：李瑶·部门报送人）
员工 了解规则，提交个人申报，提出异议 I 适用主体在职员工

3. 办之前请准备

  • 现行制度全文、一页纸省流版、FAQ，并在首页写明适用主体（当前仅武汉模态跃迁主体）
  • 本季度积分预算表（按部门）
  • 申报材料：贡献事实、产出链接（文档/PR/反馈记录/专利受理通知）、关联项目、建议分值
  • 上季度台账余额与未结异议
  • 积分系统是否可用；不可用时使用多维表格台账作为唯一记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制度发布前完成：适用范围、一页纸省流版、FAQ；先给部门负责人预读，再在已有例会中加议程做全员宣贯 运营组牵头 发布前 5 个工作日 飞书文档 + 例会议程 宣贯包、宣贯记录 👤+🔧
2 宣贯后收集问题，统一发布补充说明并更新 FAQ 运营组牵头 宣贯后 2 个工作日内 飞书公告 / FAQ 机器人 补充说明 🔧+🤖
3 各部门提交季度积分预算，运营组汇总 部门负责人、运营组牵头 每季度首月 10 日前 多维表格「积分预算」 预算汇总 🔧飞书固化
4 员工/部门在申报窗口提交申报（产品有效反馈可随时登记，季度汇总） 员工、部门负责人 每季度末月 1～10 日 飞书审批 / 积分系统 申报单 🔧飞书固化
5 初核：材料完整性、是否重复计分、是否属于适用主体；AI 辅助比对重复申报 运营组牵头、人事 窗口关闭后 5 个工作日内 多维表格 + AI 初审 初核意见 🤖+👤
6 委员会审议预算与贡献等级，利益相关者回避，形成决议 委员会 次季度首月 15 日前 委员会会议 决议纪要 👤人工判断
7 公示结果（不含个人薪酬信息） 运营组牵头 决议后 2 个工作日内，公示 3 个工作日 飞书公告 公示 🔧飞书固化
8 受理异议，复核并回复；必要时提交委员会终裁 运营组牵头 收到后 5 个工作日内 飞书审批 复核结论 👤人工判断
9 登记台账，部门积分由部门负责人分配到个人后回填 运营组牵头、部门负责人 公示结束后 3 个工作日内 积分系统 / 多维表格 积分台账 🔧+🤖
10 兑换：积分兑奖金随次月工资发放；期权认购按补充说明办理 财务、人事 随次月工资 财务系统 兑换清单 🔧飞书固化

5. 交付物与模板

  • 交付物：制度宣贯包、补充说明、季度预算、申报单、初核意见、委员会决议纪要、公示、积分台账、兑换清单
  • 建议模板/表单：
    • 制度发布模板（必填）：适用主体、适用人员、生效日期、与其他激励制度的关系、FAQ 链接、解释部门
    • 多维表格「积分台账」：员工、主体、部门、积分来源（产品反馈/FDE 案例/研发工作量/创新成果/知识产权/部门分配）、分值、对应申报单、决议批次、公示日期、已兑换、余额
    • 申报审批单：申报人、贡献类型、事实描述、产出链接、建议分值、部门负责人意见
    • 委员会决议纪要：参会人、回避人员、审议事项、结论、表决结果

6. 异常与升级

  • 非适用主体员工（子公司）申报或询问期权 → 运营组牵头 1 个工作日内按补充说明答复，并登记需求 → 汇总后提交管理层决定子公司方案
  • 部门积分分配到个人有争议 → 部门负责人说明分配依据 → 运营组 5 个工作日内复核 → 委员会终裁
  • 积分系统故障或未上线 → 以多维表格台账为准，系统上线后一次性导入并核对
  • 知识产权或其他重大创新成果 → 运营组提交委员会“一事一议”，不走常规分值表
  • 兑换资金超预算 → 财务负责人 2 个工作日内告知运营组 → 升级 CEO 决定延期或调整

7. 衡量指标

  • 申报按期完成率：窗口内提交的部门数 ÷ 应提交部门数，目标 100%
  • 结果发布周期：申报窗口关闭到公示的工作日数，目标 ≤ 15 个工作日
  • 异议率：异议件数 ÷ 申报件数，目标 ≤ 5%
  • 制度口径类追问次数：宣贯后 1 个月内的口径类提问次数，目标逐季下降
  • 台账一致率：台账与财务兑换记录一致的比例，目标 100%

8. 低效诊断

  • 现象：制度文本过长，管理层要求省流版，宣发材料（PDF、PPT、HTML）多次重做（制度起草缺“发布包”标准）｜依据：「董事会专项沟通群」2026-08
  • 现象：部门负责人难以集中宣贯，只能在其他会议上加议程（宣贯缺固定会议入口）｜依据：「董事会专项沟通群」2026-08
  • 现象：宣贯会上才被问到子公司是否适用、积分能否换期权，次日补发官方说明（制度模板未强制写适用范围）｜依据：「【模态】业务负责人」2026-08、「董事会专项沟通群」2026-08
  • 现象：积分系统还没开测，宣发先行，部门积分如何分到个人被追问（运营机制与系统未就绪即发布）｜依据：「董事会专项沟通群」2026-08
  • 现象：产品反馈积分、用量奖励只在群里口头说明，细则“本月内推出”（计分规则未成文）｜依据：「模态集团（全员群）」2026-04、「模态集团（全员群）」2026-06
  • 现象：知识产权激励与积分激励边界反复调整，金额当天修改（两个制度同时起草未对齐）｜依据：「董事会专项沟通群」2026-07

9. 分支变体

  • 武汉模态跃迁主体在职员工：适用；分子公司员工：暂不适用，另出方案
  • 个人积分：员工申报，运营组核验
  • 部门积分：以部门为单位发放，负责人有一定自由裁量权，季度评估后上报委员会
  • 研发工作量积分（需求点数、组长部分权限）：计分依据来自 HR-19 的工作量统计
  • 产品有效反馈积分：只计有效反馈，不鼓励刷量，由学习委员/产品侧判断有效性
  • 知识产权激励：专利受理/授权现金奖励按季度合并到工资发放；其他创新成果纳入积分；重大成果一事一议
  • 期权认购：按补充说明的范围和窗口办理

10. 待确认问题

  • 积分运营组牵头是否确定为总经办？人事、财务、行政在运营组中的具体分工是什么？
  • 申报窗口按季度是否合适？产品反馈积分是否需要月度结算？
  • 委员会成员名单与回避规则是否已成文？决议采用多数制还是一致制？
  • 积分系统上线时间？上线前是否以多维表格为唯一台账？
  • 子公司员工的积分与期权方案由谁负责、预计何时出？
  • 积分兑奖金的税务处理口径是否已与财务确认？
HR-19研发绩效评价与质量奖惩待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨3 × 险5

  • 适用场景：每个迭代结束或每月初，需要统计研发/测试工作量（故事点、任务点数）、评级，统计线上 Bug 并认定责任，据此确定奖金、扣款、积分或 AI 补贴调整时启动
  • 负责人：主责——研发团队负责人（Leap 线当前：王皓南·推断待确认；跃竞线当前：徐莉·推断待确认）；协同——测试负责人（当前：张东郅·推断待确认）、绩效汇总人（当前：杨萌·推断待确认）、人事负责人（当前：黄莹·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——研发负责人（创始人兼 CTO，当前：丁震宇）
  • 核心流程：① 迭代前公示参与人与点数 → ② 迭代后统计工作量 → ③ 上线后 Bug 定级归因 → ④ 公示责任比例 → ⑤ 申诉与终裁 → ⑥ 月度评级汇总 → ⑦ 人事合规复核 → ⑧ 结果应用与结算
  • 交付结果：每迭代工作量统计表；每次发布的 Bug 定级与责任认定公示；月度研发/测试绩效总表（评级 + 主观评分）；经人事复核的奖惩结算清单（交财务随工资结算）
  • 状态依据：已有《线上发布质量奖惩机制（研发侧）v1.0》、测试工作量统计表、月度 Bug 统计与责任会；但 2026-02～08 各团队各自设计评级方案，研发绩效“记在哪、报到哪”无人知晓，质量奖惩条款改了约 4 轮，评审靠口头追问，绩效规则发布前缺评审环节

1. 场景判定

  • 触发条件：迭代结束；版本上线后出现线上 Bug；对账发现因 Bug 造成损失；每月初需要汇总上月绩效；绩效结果要用于奖金、扣款、积分或 AI 补贴调整
  • 典型说法：「每迭代统计每个人完成的故事点」「看看上个月的 bug 统计，有没有异议」「出 bug 了测试要背多一点」「你们都是怎么记产研绩效的」「故事点和绩效挂钩很容易被执行坏」
  • 判断问题：这是对研发/测试产出与质量的周期性评价和奖惩吗？如果是针对某个员工的行为、态度或持续不达标，需要访谈和处置，就不归本流程
  • 不归本流程管：个人行为问题、警告、改进计划、调岗终止 → 请走 HR-20；积分申报、公示与兑换 → 请走 HR-18；AI 补贴发放与核定 → 请走 HR-17；年度总结与 1v1 → 请走 HR-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
团队负责人 迭代前公示参与人与点数，统计工作量，主观评分，主持 Bug 归因会 R 研发团队负责人（Leap 线当前：王皓南·推断待确认；跃竞线当前：徐莉·推断待确认）
测试负责人 统计测试工作量、关键 Bug、漏测事件，参与 Bug 定级 R 测试负责人（当前：张东郅·推断待确认）
汇总人 维护统一绩效总表，月度汇总 R 绩效汇总人（当前：杨萌·推断待确认）
终裁人 评审绩效与奖惩规则，申诉终裁 A 研发负责人（创始人兼 CTO，当前：丁震宇）
人事 复核扣款与奖惩合规，结果归档，对接薪酬 C 人事负责人（当前：黄莹·推断待确认）
法务 审核奖惩、扣款条款的劳动法合规 C 法务（当前：待指定）
财务 按清单随当月工资结算 R 财务（当前：待指定）
研发/测试人员 认领任务、确认统计、可申诉 I 研发、测试人员

3. 办之前请准备

  • 本迭代任务清单与故事点/任务点数（来自工单/需求系统）
  • 本次发布参与人员名单（前端、后端、测试）
  • 线上 Bug 记录：等级（P0～P3）、发现时间、修复时间、关联提交（git 证据）、客户影响与损失
  • 测试工作量表：功能 issue 数、点数、关键 Bug、漏测事件
  • 现行规则版本：质量奖惩机制版本号、评级基线、容错额度

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 迭代开始：公示参与人员、任务点数，员工自行认领任务 团队负责人 迭代首日 工单系统 + 多维表格 迭代任务表 🔧飞书固化
2 迭代结束：自动汇总个人完成故事点、测试工作量 团队负责人、测试负责人 迭代结束后 2 个工作日内 工单系统导出 → 多维表格 工作量统计 🤖自动化
3 线上 Bug：定级与归因短会，按责任链路（提交人、把关人、测试）确定比例 团队负责人、测试负责人 上线后 24 小时内 缺陷表 + 飞书会议 定级归因记录 👤人工判断
4 公示责任比例与 git 证据 团队负责人 上线后 48 小时内 飞书群公告 / 多维表格 Bug 责任公示 🔧飞书固化
5 受理申诉并终裁 终裁人 公示后 48 小时内可申诉，收到后 24 小时内终裁 飞书审批 终裁结论 👤人工判断
6 月度汇总：工作量评级（以基线点数划 A/B/C/D）+ 主观过程评分 + Bug 结果，组内公示（不叫“通报”） 汇总人、团队负责人 每月 5 日前 多维表格「产研绩效总表」 月度绩效总表 🤖+👤
7 团队确认：上月 Bug 统计与评级有无异议 研发/测试人员 公示后 2 个工作日内 飞书群 / 多维表格评论 确认记录 👤人工判断
8 人事复核扣款、奖励是否符合已公示规则和劳动法要求 人事 每月 8 日前 飞书审批 复核意见 👤人工判断
9 输出结果应用清单：奖金/扣款（交财务）、积分（交 HR-18）、AI 补贴调整（交 HR-17） 汇总人 每月 10 日前 多维表格导出 结算清单 🤖自动化
10 随当月工资结算，归档 财务、人事 当月工资发放日 财务系统 结算记录 🔧飞书固化
11 规则修订：起草 → 相关负责人评审 → 法务/人事合规审 → 终裁人批准 → 发布并升版本 团队负责人 生效前 5 个工作日完成评审 飞书 wiki + 审批 新版规则 👤+🔧

5. 交付物与模板

  • 交付物：迭代任务表、工作量统计、Bug 定级归因记录与公示、申诉终裁记录、月度绩效总表、人事复核意见、结算清单、规则版本记录
  • 建议模板/表单：
    • 多维表格「产研绩效总表」：周期、团队、员工、角色（前端/后端/测试）、完成点数、评级、主观评分、关键 Bug 数、漏测事件、Bug 责任比例、奖惩结果、积分、AI 补贴调整建议、确认状态
    • 「线上缺陷表」：Bug 编号、等级、发现时间、修复时间、发布版本、提交人、把关人、测试、git 链接、客户影响、是否在容错额度内
    • 规则文档头部：版本号、生效日期、适用人员、评审人、法务意见、变更说明

6. 异常与升级

  • 线上 Bug 需要赔偿客户 → 团队负责人当天报研发负责人，按机制先用个人部分、不足由公司补齐；损失认定 2 个工作日内完成
  • 员工对评级或责任比例有异议 → 48 小时内提交申诉 → 终裁人 24 小时内裁定；仍有争议转人事处理
  • 扣款条款涉嫌违反劳动法 → 人事暂停执行该项，3 个工作日内提交法务意见
  • 某团队（如基座组）工作量难以量化 → 团队负责人提出替代指标，经研发负责人确认后试行一个周期
  • 规则未经评审就执行并引发异议 → 暂停该规则，补走步骤 11

7. 衡量指标

  • 绩效统计准时率：每月 5 日前完成总表的团队数 ÷ 团队总数，目标 100%
  • Bug 归因及时率：24 小时内完成定级归因的线上 Bug 占比，目标 ≥ 90%
  • 申诉率：申诉件数 ÷ 公示件数，观察指标；终裁 24 小时内完成率目标 100%
  • 线上 Bug 率：每次发布的 P0/P1 Bug 数，目标逐季下降
  • 规则评审覆盖率：经评审后发布的绩效/奖惩规则占比，目标 100%

8. 低效诊断

  • 现象：各团队各自设计评级与激励方案（故事点评级、需求点数、DRV），研发激励长期未定稿（缺统一的绩效规则归口）｜依据：「鼎慧人事」2026-02、「董事会」2026-04、「董事会」2026-06
  • 现象：没有绩效工资，评价反馈周期长，管理者只能口头约束（绩效规范未出台）｜依据：「鼎慧产研决策部」2026-04
  • 现象：产研绩效“记哪里、报到哪”无人知晓，临时起总表（缺统一落点）｜依据：「Leap产研决策部」2026-08
  • 现象：质量奖惩条款多轮修改（系数、抵消规则），评审人未及时看需多次追问（规则修订缺正式评审节点）｜依据：「跃竞模态董事会」2026-04
  • 现象：月度 Bug 统计和责任会临时组织，需要开会才能确定责任人（责任认定标准未书面化）｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10
  • 现象：任务点数挂钩绩效的制度发布前未与相关负责人对齐，事后才出现异议（规则发布缺评审环节）｜依据：「董事会」2026-06、「鼎慧产研决策部」2026-04

9. 分支变体

  • Leap 研发：按故事点评级（以基线点数划 A/B/C/D），组长有部分积分权限
  • 测试：按功能 issue 数、点数、关键 Bug、漏测事件统计，与 AI 补贴调整挂钩（“客观工作量 + 主观过程表现”，仅供参考）
  • 跃竞（跃玩）：按《线上发布质量奖惩机制（研发侧）》执行，发布前冻结个人基数并由公司配套，P3 级每人每周期有容错额度；生效首月按缓冲强度执行
  • 基座组：全员做平台类工作难量化，由产品侧参与评估替代指标
  • 实习生：只统计工作量，不适用扣款（待确认）
  • 对账亏损：在步骤 3 中一并认定责任

10. 待确认问题

  • 本 SOP 主责是各研发团队负责人，还是需要一个统一的研发绩效归口人？
  • 故事点评级基线、A/B/C/D 比例是否全线统一？评级结果用于奖金的权重是多少？
  • 质量奖惩中“冻结个人基数、扣款”是否已经法务审核？是否只在跃竞线执行？
  • 绩效总表统一放在哪个多维表格？是否与积分系统、AI 补贴台账打通？
  • 实习生是否适用扣款与奖励？
  • 规则修订的评审人名单（哪些负责人必须参与）是否可以确定？
HR-20员工绩效/行为问题访谈与处置待新建180

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨3 × 险5

  • 适用场景：员工出现产出持续不足、交付质量问题影响他人、多次迟到、失联、不配合或态度问题，需要访谈调查、书面警告、改进期、调岗/降薪转岗或终止时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——直属负责人（当前：各团队负责人，如王皓南、杨萌·推断待确认）、带教人（实习生，当前：待指定）、法务负责人（当前：李瑶·部门报送人）；处置决策——研发负责人/CEO（当前：丁震宇、邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 记录事实 → ② 直属负责人首次沟通 → ③ 人事访谈调查 → ④ 分级判定 → ⑤ 处置决策 → ⑥ 书面告知与签收 → ⑦ 改进期跟踪 → ⑧ 结论归档（终止则转离职交接）
  • 交付结果：问题事实记录；访谈纪要（权限受限）；处置决定（警告函/改进计划/调岗通知/终止通知）及本人签收；改进期复盘结论；人事档案归档
  • 状态依据：目前靠管理者个人观察发起，先口头处理后补文件，警告、调岗、取消补贴、终止均无模板；2026-03～09 各团队约 20 余次在群内讨论此类问题，没有 PIP、升级门槛和时限

1. 场景判定

  • 触发条件：同一问题出现 2 次及以上（迟到、交付质量、改坏功能、未同步信息）；产出连续 2 个周期低于团队基线；失联超过 1 个工作日；与同事冲突后拒绝工作；直属负责人沟通无效
  • 典型说法：「要安排人事谈话了」「你先都简单访谈一下吧」「事不过三，真控制不住让 HR 约谈吧」「相当于 PIP，但是现在显然没这个东西」「有没有什么合法合规的方式管一下」
  • 判断问题：这是针对某个员工个人的行为或持续不达标问题，且直属负责人已沟通过一次仍未改善吗？如果是周期性绩效评级或 Bug 奖惩，不归本流程
  • 不归本流程管：迭代绩效评级、Bug 扣款 → 请走 HR-19；AI 补贴暂停的发放执行 → 请走 HR-17；离职手续与账号停用 → 请走 HR-27（员工离职办理与交接）；员工主动提出的诉求或投诉 → 请走 HR-29（员工申诉与劳动争议处理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
统筹 立案、访谈调查、起草文书、面谈告知、跟踪改进期、归档 R 人事负责人（当前：黄莹·推断待确认）
直属负责人 记录事实证据、首次沟通、提出处置建议、改进期辅导与评估 R 直属负责人（当前：各团队负责人，如王皓南、杨萌·推断待确认）
带教人 实习生问题的事实确认与终止确认 C 带教人（当前：待指定）
决策 决定处置等级（观察培训/警告/改进期/调岗/终止） A 研发负责人/CEO（当前：丁震宇、邴龙志·推断待确认）
法务 审文书模板，终止、降薪、扣款前审合规 C 法务负责人（当前：李瑶·部门报送人）
被访谈同事 提供事实信息，身份匿名保护 C 相关同事
员工本人 陈述意见、签收文书、执行改进计划 I 当事员工

3. 办之前请准备

  • 事实证据：时间、事件、影响、记录链接（考勤记录、工单、提交记录、聊天截图），只写事实不写评价
  • 岗位 JD、近 2 个周期的产出记录与评级（来自 HR-19）
  • 直属负责人首次沟通的时间和内容记录
  • 劳动合同类型（正式/试用期/实习）与入职日期
  • 已发布的相关规范（考勤制度、交付质量规范）及员工是否已知悉

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 记录问题事实，填写问题登记表；人事个案不在工作群讨论 直属负责人 问题发生当天 飞书表单（权限受限） 问题登记 🔧飞书固化
2 首次 1v1 沟通：指出事实、明确期望、确认员工规划，记录沟通要点 直属负责人 登记后 2 个工作日内 线下/飞书会议 沟通记录 👤人工判断
3 仍未改善或问题严重 → 提交人事立案 直属负责人 第 2 次发生当天 飞书审批 立案单 🔧飞书固化
4 人事访谈：收集 JD 与产出，访谈 2～4 名相关同事（每人约 15 分钟，匿名），访谈本人 人事 立案后 3 个工作日内 访谈纪要模板 访谈纪要 👤人工判断
5 分级判定：能力差态度好 → 观察 + 培训；能力强态度差 → 引导 + 警告；能力差态度差 → 警告 + 改进期或终止；附处置建议 人事、直属负责人 访谈完成后 1 个工作日内 分级判定表 处置建议 👤人工判断
6 决策处置等级；涉及终止、降薪、扣款的先过法务 决策人、法务 收到建议后 2 个工作日内 飞书审批 处置决定 👤人工判断
7 按模板出具文书，人事与直属负责人共同面谈告知，员工签收 人事、直属负责人 决定后 2 个工作日内 文书模板 + 电子签 签收文书 🔧+👤
8 改进期：设定目标、演示节点、辅导人；中期检查一次 直属负责人 改进期 30 天（试用期可缩短），第 15 天中期检查 飞书任务 改进计划与检查记录 🔧+👤
9 改进期结束评估：通过/延长/调岗/终止，提交决策人确认 直属负责人、人事 期满后 3 个工作日内 飞书审批 评估结论 👤人工判断
10 归档；如调岗/终止，转交接与离职流程，同步 IT 停用账号（工单系统只停用不删除） 人事 结论后 1 个工作日内 人事档案 + 离职流程 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：问题登记表、沟通记录、访谈纪要、处置决定、签收文书、改进计划与检查记录、评估结论、档案
  • 建议模板/表单（法务审一次后人事直接使用）：
    • 问题登记表：员工、部门、问题类型（考勤/交付质量/沟通协作/失联/态度）、发生时间、事实描述、影响、证据链接、第几次、登记人
    • 书面警告函：事实、违反的制度条款、改进要求、再次发生的后果、申诉渠道、签收栏
    • 改进计划（PIP）：目标（可衡量）、演示节点、辅导人、资源支持、检查日期、评估标准
    • 调岗/转部门通知、取消补贴通知、实习终止通知
    • 访谈纪要：访谈对象（匿名编号）、时间、问题、事实陈述

6. 异常与升级

  • 直属负责人沟通 2 次无效或无法处理冲突 → 上报部门负责人（1 个工作日内）→ 部门负责人 3 个工作日内仍未解决 → 上报 CEO；决策人出差时由兜底人代为推进，不得超过 5 个工作日无回应
  • 员工失联超过 1 个工作日 → 人事按合同地址/紧急联系人书面联系并留痕 → 3 个工作日仍失联转法务
  • 员工拒绝签收 → 人事邀请第三人在场见证并记录，或通过邮件/快递送达留痕
  • 员工对处置有异议 → 5 个工作日内向人事书面申诉 → 兜底人组织复核
  • 涉及解除劳动关系 → 法务先审证据链与补偿口径，不得仅凭聊天口头结论执行

7. 衡量指标

  • 立案处理周期：立案到处置决定的工作日数，目标 ≤ 7 个工作日
  • 书面留痕率：有处置的个案中具备签收文书的比例，目标 100%
  • 改进期通过率：改进期结束后评估“通过”的比例（观察指标）
  • 劳动争议数：因处置引发的仲裁/投诉数，目标 0
  • 群内讨论人事个案次数：目标逐月下降至 0

8. 低效诊断

  • 现象：问题靠管理者个人观察发起，没有定期评估，常在问题积累后才处理（缺立案入口和评估节点）｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-09
  • 现象：处置决定在群里口头作出（警告、取消补贴），书面文件事后补拟（缺文书模板与“先审后发”环节）｜依据：「模态人事大主管」2026-06、「模态人事大主管」2026-08
  • 现象：迟到、改坏功能等问题在工作群集中讨论“警告还是扣钱”（无分级规则，人事个案在公开群流转）｜依据：「鼎慧产研决策部」2026-05
  • 现象：想给员工改进机会但没有 PIP 机制，只能口头“最后一次机会”（缺改进计划流程）｜依据：「鼎慧产研决策部」2026-08、「鼎慧产研决策部」2026-09
  • 现象：警告与直接处理界限不清，人员离开后任务无人接、转岗去向归谁定不清（分级规则与交接未成文）｜依据：「Leap产研决策部」2026-09
  • 现象：低质量交付影响同事，先要讨论“哪些行为算问题”才起草规范（行为定义缺失）｜依据：「【模态】综合部」2026-09

9. 分支变体

  • 试用期员工：改进期可缩短为 2 周，评估不通过按试用期不合格处理（需法务确认证据要求）
  • 转正后员工：必须完整走警告 → 改进期 → 评估，调岗/降薪需书面协商
  • 实习生：带教人确认事实后，可直接走实习终止通知，人事沟通并结算
  • 外包/借调人员：通知其所属单位，按合作协议处理
  • 问题类型：考勤（自动统计后提醒）、交付质量（按《AI 时代交付质量规范》定义）、沟通协作/冲突（先 1v1 调解）
  • 处置附加项：暂停次月 AI 补贴（执行转 HR-17）、积分扣减（转 HR-18）

10. 待确认问题

  • 本流程主责是否为人事负责人？直属负责人与人事在访谈、告知中的分工是否认可？
  • 处置决策权：研发线由 CTO 决定、其他线由 CEO 决定，是否这样划分？
  • 改进期默认 30 天、中期检查一次是否可行？
  • 警告函、改进计划、调岗通知、实习终止通知四类模板是否由法务统一审定？
  • 《AI 时代交付质量规范》是否已正式发布？“警告 → 暂停补贴 → 改进期”的三级处理是否采纳？
  • 问题登记表与访谈纪要的查看权限给到哪些岗位？
HR-21年度/阶段总结收集与1v1面谈待优化72

状态：待优化｜证据：有证据（卡片 11 张 / 会话 9 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：年终或阶段节点（季度、集中加班后），需要下发总结通知与模板、按名册收集、组织互读评论、安排管理者与员工 1v1 面谈并沉淀结论时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——年度通知发起人与访谈人（CEO，当前：邴龙志·推断待确认）、技术部总结组织人（当前：丁震宇·推断待确认）、产研阶段总结组织人（当前：杨萌·推断待确认）、各模块负责人；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 拟通知、模板与名册 → ② 管理层审阅 → ③ 按名册发布并建待办 → ④ 提交并回填汇总表 → ⑤ 自动催交 → ⑥ 互读评论与批注 → ⑦ 1v1 预约与面谈 → ⑧ 纪要归档与结果应用
  • 交付结果：全员总结提交汇总表（100% 覆盖名册）；管理者批注与互评记录；1v1 排期表与面谈纪要（权限受限）；用于绩效、调薪参考的结论清单
  • 状态依据：年度总结通知与模板已有（两阶段：个人总结 + 互读评论 3～5 份），阶段总结有汇总表机制；但 2026-01 技术/非技术截止日不同导致看错通知、新人未入群漏收通知，多次 @所有人 催交，模板不统一，1v1 靠群里“+1 排队”且无记录载体

1. 场景判定

  • 触发条件：每年 1 月初（年度）；季度末或重大项目/集中加班结束后（阶段）；管理者计划新一轮 1v1；团队冲突后需要逐一沟通
  • 典型说法：「请大家按时完成年度总结」「后天截止提交了」「记得看看别人的文档然后都评论一下」「年度约谈大家可以跟我约时间」「这周内会依次找大家聊聊」
  • 判断问题：这是面向一批员工的周期性总结与沟通吗？如果是针对某个员工的问题沟通，不归本流程
  • 不归本流程管：个人绩效/行为问题的约谈处置 → 请走 HR-20；迭代绩效评级 → 请走 HR-19；年度体检与保险 → 请走 HR-22；年会筹办 → 请走 HR-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
统筹 起草通知与模板、维护名册、建待办、催交、统计、排期、归档 R 人事负责人（当前：黄莹·推断待确认）
发起与访谈 审定年度通知，作为 1v1 访谈人 A CEO（当前：邴龙志·推断待确认）
技术线组织 技术部总结收集、逐一批注、组织互评 R 技术部总结组织人（当前：丁震宇·推断待确认）
产研线组织 阶段总结与下阶段计划收集、逐一 1v1 R 产研阶段总结组织人（当前：杨萌·推断待确认）
模块负责人 补充团队总结，参与本团队 1v1 R 各模块负责人（当前：待指定）
行政 协助访谈场地与时间协调 C 行政（当前：待指定）
员工 按模板提交总结、互读评论、预约 1v1 I/R 全体员工

3. 办之前请准备

  • 名册：从人事主表按组织架构导出，标明技术/非技术、正式/实习、入职日期（明确截止日前多少天入职的新人是否需要写）
  • 模板：年度成果、经验教训、可复用成果、下阶段计划、个人成长、想请教的问题；阶段总结增加“团队总结”模块
  • 截止日：个人总结截止日、互读截止日（技术/非技术如不同，分别写明）
  • 汇总表：飞书多维表格，含名册与提交链接字段
  • 1v1 提纲与纪要模板；访谈人可预约时段

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草通知（目的、范围、模板、截止日、互读要求），导出名册 人事 年度：1 月第 1 个工作日前；阶段：节点前 5 个工作日 飞书文档 + 人事主表 通知草稿、名册 🔧+🤖
2 管理层审阅通知（措辞、范围、是否同步福利事项） CEO / 技术线组织 1 个工作日内 飞书文档评论 定稿通知 👤人工判断
3 按名册发布：全员群公告 + 给名册中每人建飞书任务（含截止日），技术/非技术分别推送 人事 定稿当天 飞书公告 + 飞书任务 通知与待办 🔧飞书固化
4 员工在飞书文档写总结，把链接填入汇总表 员工 年度：通知后 10 个自然日内；阶段：通知后 5 个工作日内 飞书文档 + 多维表格 提交记录 🔧飞书固化
5 截止前 2 天、前 1 天机器人提醒未提交者，截止后发未交名单给其负责人 人事 自动 飞书机器人 催交记录 🤖自动化
6 管理者阅读并批注；员工互读评论 3～5 份；AI 汇总各人要点 技术线/产研线组织、员工 提交截止后 3 个自然日内 飞书文档评论 + AI 摘要 批注、互评、要点汇总 👤+🤖
7 发布 1v1 预约：访谈人开放时段，员工自选（优先上轮未访谈的老员工和新员工），每人约 30 分钟 人事 互读截止后 2 个工作日内发布 飞书日历预约 / 多维表格排期 1v1 排期表 🔧飞书固化
8 1v1 面谈：复盘、职业规划、意见建议、贡献与问题；当天填写纪要 访谈人 排期内完成，纪要当天提交 纪要模板（权限受限） 面谈纪要 👤人工判断
9 汇总待办与结论：需跟进事项分派负责人；绩效/调薪参考转 HR-19 与薪酬流程 人事 1v1 全部结束后 3 个工作日内 多维表格 跟进清单 🔧+👤
10 归档总结与纪要，设置查看权限；复盘本轮问题 人事 结束后 5 个工作日内 飞书知识库 归档 🔧飞书固化

5. 交付物与模板

  • 交付物：通知、名册、汇总表、批注与互评、要点汇总、1v1 排期表、面谈纪要、跟进清单
  • 建议模板/表单：
    • 多维表格「总结汇总表」：员工、部门、技术/非技术、正式/实习、截止日、提交链接、提交时间、批注人、互评数、1v1 时间、访谈人、纪要链接、跟进事项
    • 总结模板：本期成果（附链接）、经验教训、可复用成果、下阶段计划、个人成长、需要的支持/想请教的问题
    • 1v1 纪要模板：日期、访谈人、员工、复盘要点、职业规划、意见建议、风险提示、跟进事项（负责人 + 截止日）

6. 异常与升级

  • 员工不在名册或未入群漏收通知 → 人事 1 个工作日内补发并给 2 个工作日宽限 → 名册错误源头修正人事主表
  • 截止后仍未提交 → 推送给其直属负责人，2 个工作日内仍未交，升级部门负责人
  • 访谈人行程冲突无法按期完成 1v1 → 人事调整排期，整体推迟不超过 2 周，否则由兜底人决定是否由部门负责人代行
  • 1v1 中发现个人问题或风险 → 访谈人在纪要中标注，人事判断是否转 HR-20
  • 1v1 中出现团队冲突 → 产研线组织人 1 周内安排相关方逐一沟通

7. 衡量指标

  • 按时提交率：截止日前提交人数 ÷ 名册人数，目标 ≥ 95%
  • 通知覆盖率：收到待办的人数 ÷ 名册人数，目标 100%
  • 互评完成率：完成 3 份以上评论的人数 ÷ 名册人数，目标 ≥ 80%
  • 1v1 覆盖率：本轮完成 1v1 人数 ÷ 计划人数，目标 100%
  • 跟进事项关闭率：1v1 跟进事项在约定期限内关闭的比例，目标 ≥ 80%

8. 低效诊断

  • 现象：新员工是否需要写、截止日是哪天靠口头问，同事之间互相提醒（通知未附名册和适用范围）｜依据：「鼎慧产研决策部」2026-01
  • 现象：技术与非技术截止日不同，有人未被归入技术部看错通知，新人未入群漏收通知（通知按群发，不按组织架构名册发）｜依据：「技术部」2026-01
  • 现象：多次 @所有人 提醒交总结，阶段总结也要点名催交（缺按人待办和自动催办）｜依据：「技术部」2026-01、「Leap产研测」2026-10
  • 现象：总结形式不统一，有人用网页或其他格式（模板未固化）｜依据：「技术部」2026-01
  • 现象：1v1 靠在群里“+1 排队”、临场协调，面谈结果没有记录载体（缺预约工具和纪要模板）｜依据：「模态集团（全员群）」2026-02、「模态集团（全员群）」2026-05
  • 现象：年度总结、人事档案完善、体检报告提交都要多次催办（年度事项缺统一人事日历）｜依据：「模态跃迁通知群」2026-01、「模态跃迁通知群」2026-03

9. 分支变体

  • 年度总结：个人总结 + 互读评论两阶段，CEO 发起，后续年度 1v1；年终通知常同时带 13 薪、年终奖、补充医疗、体检和年会，福利事项分别转 HR-22、HR-24
  • 技术部：以技术群方案为准，无需另交；由技术线组织人逐一批注
  • 阶段总结（季度/集中加班后）：阶段回顾 + 下阶段计划 + 个人成长，模块负责人补团队总结，节后逐一 1v1
  • 新一轮 1v1（非总结驱动）：每人 30 分钟，优先未访谈员工
  • 实习生、新入职员工：入职不满 1 个月的是否需要写，按通知中的范围执行
  • 跃竞组等单独团队：由其负责人自行组织，提交结果回填汇总表

10. 待确认问题

  • 主责是否为人事负责人？技术线、产研线分别组织时，是否仍统一用一张汇总表？
  • 阶段总结是否固定为季度一次？
  • 入职多久以内的新员工可以不写年度总结？
  • 1v1 纪要的查看权限给到哪些岗位？是否纳入人事档案？
  • 总结结果在调薪、奖金中的使用方式是否需要在通知中写明？
HR-22员工福利：体检与商业保险待优化96

状态：待优化｜证据：有证据（卡片 7 张 / 会话 8 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：公司开通或年度发放体检、团体商业保险、中医问诊等福利，需要方案选型、对接机构、发卡、组织预约、收集体检报告、更新参保名单、解答理赔问题时启动
  • 负责人：主责——福利统筹（行政，当前：侯明月·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、财务（当前：待指定）、各组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 年度方案对比 → ② CEO 选定 → ③ 付款开通 → ④ 发卡与参保名单 → ⑤ 发布使用指引与 FAQ → ⑥ 统一/自行预约 → ⑦ 体检报告收集（限授权查看）→ ⑧ 理赔答疑与季度名单更新
  • 交付结果：年度福利方案与对比文档；体检卡发放台账；团险参保名单（按季度更新）；《体检与保险使用指引 + 理赔 FAQ》；体检报告提交记录（仅授权人员可见）
  • 状态依据：已有方案对比 → 老板拍板 → 行政开通的做法，有体检预约操作流程、体检报告表单和《武汉模态跃迁福利制度说明参考》；但 2026-01～04 体检通知多次重发，机构上门无人对接，产研负责人兜底批量预约、逐个报手机号，试用期是否发卡无规则，理赔同类问题反复问，完整 SOP 至今未发布

1. 场景判定

  • 触发条件：年度福利周期开始（每年 1 月）；年会发放体检卡；新员工入职或转正；每季度团险名单更新；员工预约体检或改期；员工就医后咨询理赔；子公司要求对齐福利
  • 典型说法：「全员体检月底到 2 月初安排一下」「没有体检的可以填问卷我一起预约」「你们的体检卡都没绑定」「请大家在规定日期前完成体检并提交体检报告表单」「请出一个补牙报销 SOP」
  • 判断问题：这件事是不是公司统一提供的健康类福利（体检、团险、问诊）？如果是节日礼品、零食、通勤等，不归本流程
  • 不归本流程管：节日礼盒、文化衫等福利物资 → 请走 ADM-18（节日福利与员工福利物资发放）；零食 → 请走 ADM-17；生日会 → 请走 ADM-20；通勤出行 → 请走 ADM-22；社保公积金 → 请走 HR-16（社保公积金缴纳与增减员）；年会筹办 → 请走 HR-24；AI 补贴 → 请走 HR-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
福利统筹 方案对比、机构对接、开通、发卡台账、预约、名单更新、理赔答疑 R 福利统筹（行政，当前：侯明月·推断待确认）
人事 提供在职/转正名单、发通知、维护体检报告表单与权限 R 人事负责人（当前：黄莹·推断待确认）
行政负责人 复核方案与预算，子公司福利对齐 C 行政负责人（当前：胡则瑾·推断待确认）
决策 选定方案与预算 A CEO（当前：邴龙志·推断待确认）
财务 付款、开票、费用入账 R 财务（当前：待指定）
组长 传达本组通知，组织团体预约意愿 C 各组长（当前：待指定）
员工 激活/绑定卡、预约、体检、提交报告、自行理赔 I 全体适用员工

3. 办之前请准备

  • 在职名单（含主体、入职日期、转正日期、员工类型、工作地）
  • 年度预算与上年使用情况（体检完成率、理赔反馈）
  • 至少 2 家机构的方案对比（套餐项目、价格、网点、预约方式、上门服务）
  • 机构固定对接人及联系方式（写入台账，不写入公开群）
  • 体检报告提交表单及保密声明（仅授权人员查阅）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对比至少 2 家机构方案，写入 wiki 对比文档，提交决策 福利统筹 每年 1 月 10 日前 飞书 wiki 方案对比 👤人工判断
2 选定方案与预算 CEO 提交后 3 个工作日内 飞书审批 决策记录 👤人工判断
3 签约付款、开通；登记机构对接人 福利统筹、财务 决策后 5 个工作日内 合同/付款审批 开通确认 🔧飞书固化
4 发卡：按名单发放体检卡并登记台账；团险提交参保名单 福利统筹、人事 开通后 5 个工作日内（或随年会发放） 多维表格「福利台账」 发卡台账、参保名单 🔧飞书固化
5 发布《体检与保险使用指引 + 理赔 FAQ》，必要时请机构现场讲解开卡 福利统筹、人事 发卡当天 飞书知识库 + 公告 指引与 FAQ 🔧+🤖
6 预约：员工自行预约；想统一时间的填表，统筹人汇总后一次性提交机构；表单内校验“是否已绑卡” 福利统筹 表单截止后 2 个工作日内提交机构 飞书表单 + 多维表格 预约名单 🔧+🤖
7 体检前 1 天机器人提醒（证件、禁食、地址）；改期由员工直接联系机构，统筹人只处理批量改期 福利统筹 体检前 1 天 飞书机器人 提醒 🤖自动化
8 收集体检报告，表单仅授权人员可见；截止前 7 天、前 1 天提醒未提交者 人事 按通知截止日 飞书表单（权限受限） 报告提交记录 🔧+🤖
9 理赔答疑：先查 FAQ，FAQ 未覆盖的由统筹人 1 个工作日内答复并补充到 FAQ 福利统筹 1 个工作日内 知识库 / 答疑机器人 更新后的 FAQ 🔧+🤖
10 季度更新团险名单（新入职正式员工、满 1 个月的实习生加入，离职人员移出） 福利统筹、人事 每季度首月 8 日前 多维表格 → 机构 更新名单 🔧飞书固化
11 年度复盘：完成率、反馈、费用，形成下年建议 福利统筹 每年 12 月 飞书文档 复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：方案对比、决策记录、发卡台账、参保名单、使用指引与 FAQ、预约名单、体检报告提交记录、年度复盘
  • 建议模板/表单：
    • 多维表格「福利台账」：员工、主体、员工类型、入职日、转正日、体检卡号（后 4 位）、发卡日期、是否绑定、是否完成体检、报告是否提交、团险参保状态、参保生效季度
    • 统一预约表：员工、期望日期、期望网点、是否已绑卡、手机号（仅统筹人可见）
    • 理赔 FAQ：可报范围、不可报范围（如正畸）、就医建议（公立医院）、材料清单（诊断单/病历、支付凭证）、病历书写注意事项、申请入口、新员工生效时间

6. 异常与升级

  • 机构来访或来电找不到对接人 → 前台/接待引导至福利统筹；统筹人不在时由行政负责人对接（当天）
  • 员工未绑卡导致预约失败 → 统筹人当天通知本人补绑，并纳入下一批
  • 试用期或年会后入职员工要求发卡 → 按规则处理；规则未覆盖的提交行政负责人当天决定并补充规则
  • 体检报告被非授权人员查看或外传 → 人事立即收回权限，1 个工作日内上报综合部负责人和法务
  • 理赔被拒有争议 → 统筹人 2 个工作日内与保险方核实并回复员工
  • 子公司要求对齐福利 → 行政负责人 5 个工作日内提供母公司福利说明，子公司按各自主体执行采购

7. 衡量指标

  • 体检完成率：截止日前完成体检人数 ÷ 发卡人数，目标 ≥ 90%
  • 报告提交率：截止日前提交报告人数 ÷ 完成体检人数，目标 ≥ 95%
  • 参保名单准确率：季度更新后应参保未参保人数，目标 0
  • 福利类重复提问数：群内同类问题次数，FAQ 上线后目标每月 ≤ 3 次
  • 通知重发次数：同一事项的通知次数，目标 ≤ 2 次（发布 + 截止前提醒）

8. 低效诊断

  • 现象：年度体检通知要多次重发，福利、保险名单信息散落在不同群（缺统一福利日历与知识库入口）｜依据：「内务大主管」2026-01、「内务大主管」2026-02
  • 现象：体检机构上门询问方案，对接人未回复、现场无人接待（机构对接人未固定、无备岗）｜依据：「鼎慧产研决策部」2026-01
  • 现象：产研负责人兜底组织批量预约，发现大量体检卡未绑定，只能逐个报手机号给机构（预约缺统一表单与绑定校验）｜依据：「工程咨询产研」2026-04、「字字可研项目群」2026-04
  • 现象：试用期员工是否发卡无统一规则，需逐人确认谁领过卡（缺发卡规则与台账）｜依据：「行政人事对接群」2026-03
  • 现象：补牙等理赔同类问题反复问，新员工不知道有商业医保，完整 SOP 承诺后未发布（理赔指引未文档化）｜依据：「模态集团（全员群）」2026-04
  • 现象：子公司福利与母公司对齐要多次催要汇总文件（福利制度未集中发布）｜依据：「模态-协游沟通群」2026-09

9. 分支变体

  • 体检：随年会发卡；年会后入职员工由人事通知领卡；是否“转正后统一发”待确认
  • 团险：正式员工与入职满 1 个月的实习生纳入；按季度统一添加名单
  • 中医问诊等其他健康福利：参照团险流程开通与答疑
  • 预约方式：统一预约（团体时段、可约周末）/ 自行预约（服务号、App、热线）
  • 武汉 / 非武汉员工：非武汉员工按机构异地网点预约（待确认）
  • 子公司（如跃竞相关团队）：参照母公司《福利制度说明》，采购按各自主体处理

10. 待确认问题

  • 本流程主责归行政还是人事？发卡、预约归行政，通知和报告收集归人事，这样分工是否认可？
  • 试用期员工是否发体检卡？是否统一为“转正后发放”？
  • 体检报告的授权查看范围（董事会、行政部管理人员）是否需要缩小？收集体检报告的目的与保存期限是否已书面告知员工？
  • 团险名单季度更新的截止日是否固定？
  • 非武汉员工的体检与保险如何安排？
  • 子公司是否需要独立的福利方案？
HR-23内部培训与分享会组织待优化120

状态：待优化｜证据：有证据（卡片 12 张 / 会话 9 个）｜优先级：频4 × 耗3 × 跨5 × 险2

  • 适用场景：有内部培训或分享需求（价值观、AI 工具、FDE、信创、专利、LeapCore/LeapAll、周五分享、销售演示等），需要选题排期、报名或参训确认、场地与线上会议、通知、录屏、资料归档和反馈收集时启动
  • 负责人：主责——内部培训统筹人（学习委员，当前：杨萌·推断待确认）；协同——总经办培训专员（当前：王欣·推断待确认）、综合部负责人（参训确认，当前：赵雪冰·推断待确认）、行政（场地，当前：胡则瑾·推断待确认）、课程体系负责人（当前：李凯·推断待确认）、FDE 培训组织人（当前：陈梦琪·推断待确认）、讲师（当前：王皓南、马漳毓、陈子康等·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 提交分享/培训申请 → ② 统筹人确认选题与排期 → ③ 讲师备课（大纲、软件清单、海报必填项）→ ④ 发通知与报名/参训确认 → ⑤ 订场地并建飞书会议（默认录制）→ ⑥ 实施与签到 → ⑦ 1 个工作日内归档妙记与课件 → ⑧ 反馈汇总进入选题池
  • 交付结果：培训日历上的场次；报名/参训确认记录；签到记录；录屏、妙记、课件归档在知识库“内部课程”目录；反馈汇总与下期选题
  • 状态依据：已形成“预告 → 问卷报名 → 按人数定场地 → 线上同步 → 反馈问卷”的做法，FDE 初级培训有参训确认表；但 2026-04～10 讲者多次不知找谁安排，群多信息漏看，录屏无责任人反复“求回放”，会议链接进不去、没有日程分享，资料存放位置不明，培训归属一度“没人管”

1. 场景判定

  • 触发条件：员工或管理者提出要分享/开课；公司要求全员或某类岗位参训（价值观、FDE 初级、产品使用）；新工具需要推广到非技术岗；外部培训内容要内部宣贯（专利、信创）；每周五固定分享
  • 典型说法：「我下周要开一个分享会，谁安排一下」「现在内部培训归谁管来着」「想参加的赶紧填问卷报名」「记得录屏」「有没有日程分享」「参训确认表」
  • 判断问题：受众是公司内部员工，目的是能力提升或制度宣贯吗？如果受众是客户、渠道或社区，就不归本流程
  • 不归本流程管：对外宣讲、OPC 课程、社区活动 → 请走 ECO-01（生态活动年度规划与 ROI 取舍）/ ECO-16（生态大会立项与总体筹备）；新人入职带教 → 请走 HR-06（新人入职培训、带教与首周上手）；AI 资讯跟踪与评测分享的内容生产 → 请走 GEN-17；制度宣贯中的积分规则答疑 → 请走 HR-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
培训统筹 受理申请、排期、发通知与报名、确认场地、指定录屏人、归档、反馈汇总 A/R 内部培训统筹人（学习委员，当前：杨萌·推断待确认）
总经办培训 制度类/外部类培训（专利、信创）的组织与资料整理 R 总经办培训专员（当前：王欣·推断待确认）
参训确认 强制培训按人事库名单出参训确认表，督促各负责人 R 综合部负责人（当前：赵雪冰·推断待确认）
场地 会议室预订与设备 R 行政（当前：胡则瑾·推断待确认）
课程体系 维护课程目录、讲师库、年度培训计划 C 课程体系负责人（当前：李凯·推断待确认）
FDE 培训 FDE 系列培训组织与反馈 R FDE 培训组织人（当前：陈梦琪·推断待确认）
讲师 提交申请（讲者/发起人）、备课、讲授、提供课件与软件清单 R 讲师（当前：王皓南、马漳毓、陈子康等·推断待确认）
录屏/妙记负责人 每场录制、整理妙记并归档课件 R 培训统筹每场指定的参训员工
部门负责人 确认本部门参训名单，转达通知 C 各部门负责人（当前：待指定）
员工 报名/确认、参训、反馈 I 全体员工

3. 办之前请准备

  • 分享/培训申请：主题、讲师、目标受众（技术/非技术/全员）、是否强制、预计时长、期望日期
  • 大纲与课前准备清单：需安装的软件、账号注册、网络要求、是否带电脑
  • 海报/公告必填项：主题、讲师、时间、地点、线上会议链接、报名截止
  • 是否录屏、是否可对外传播；涉及他人作品或外部内容时准备免责声明
  • 强制培训：人事库名单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交分享/培训申请 讲者/发起人 期望日期前至少 7 天 飞书表单「培训申请」 申请记录 🔧飞书固化
2 判断选题价值与受众，确认排期，写入培训日历；与同周其他活动错开 培训统筹 收到后 2 个工作日内 多维表格 + 飞书日历 排期 👤人工判断
3 讲师提交大纲、课前准备清单；统筹人用模板生成公告和海报（必填项校验） 讲师、培训统筹 开课前 5 天 公告模板 + AI 生图 公告、海报 🤖+👤
4 发通知：在通知群发布并创建飞书日程邀请对应人群；自愿类开报名，强制类发参训确认表 培训统筹 / 参训确认 开课前 5 天；报名截止为开课前 2 天中午 飞书日程 + 表单/多维表格 通知、报名/确认记录 🔧飞书固化
5 按报名人数订会议室，同步创建飞书会议并开启自动录制；指定 1 名录屏/妙记负责人 培训统筹、行政 报名截止当天 会议室预订 + 飞书会议 场地与会议链接 🔧飞书固化
6 开课前 1 天、前 1 小时提醒（会议链接、软件准备、场地）；先测试会议链接 培训统筹 开课前 1 天、1 小时 飞书机器人 提醒 🤖自动化
7 实施：线下 + 线上同步；签到；必到者优先线下座位 讲师、培训统筹 开课当天 飞书会议签到 签到记录 🔧飞书固化
8 归档：妙记、录屏、课件放入知识库“内部课程”目录，链接回帖到通知群 录屏/妙记负责人 结课后 1 个工作日内 飞书知识库 + 妙记 课程资料 🔧+🤖
9 发反馈问卷，汇总评分与下期选题建议 培训统筹 结课当天发，3 个工作日后汇总 飞书问卷 + 多维表格 反馈汇总 🔧+🤖
10 强制培训：统计缺席人员，要求 5 个工作日内看回放并确认 参训确认 结课后 1 个工作日内 多维表格 补训记录 🔧飞书固化
11 月度：更新培训日历和选题池，复盘参训率与满意度 培训统筹、课程体系 每月最后一周 多维表格 月度培训计划 👤人工判断

5. 交付物与模板

  • 交付物：培训申请、培训日历、公告/海报、报名或参训确认记录、签到记录、录屏与妙记、课件、反馈汇总、补训记录
  • 建议模板/表单：
    • 多维表格「培训日历」：场次、主题、类型（价值观/AI 工具/FDE/信创/专利/产品/周五分享/销售演示）、讲师、受众、是否强制、日期时间、地点、会议链接、报名人数、签到人数、录屏负责人、资料链接、满意度
    • 「培训申请」表单：主题、讲师、受众、强制/自愿、时长、期望日期、课前准备、是否录屏、是否可外传、免责声明
    • 公告模板：主题、讲师、对象、时间、地点、会议链接、报名方式与截止、课前准备
    • 反馈问卷：内容评分、讲师评分、实用性、改进建议、希望的下期主题

6. 异常与升级

  • 讲者不知道找谁 → 一律提交“培训申请”表单，统筹人 2 个工作日内回复；统筹人不在时由兜底人指定代理
  • 报名人数超过场地容量 → 必到者优先线下，其余线上；仍超出则加场
  • 会议链接失效 → 统筹人 5 分钟内在群里补发新链接；线下开讲不中断
  • 强制培训与紧急工作冲突（如修线上 Bug）→ 直属负责人批准后可改看回放，5 个工作日内补训
  • 讲师内容偏离框架或案例不足 → 统筹人在反馈汇总中指出，下期开课前 3 天预审大纲
  • 讲师同时承担开发任务时间冲突 → 直属负责人与统筹人协调排期，必要时延后一周

7. 衡量指标

  • 准时归档率：结课后 1 个工作日内完成资料归档的场次占比，目标 100%
  • 参训率：强制培训签到 + 补训人数 ÷ 应训人数，目标 100%；自愿培训签到人数 ÷ 报名人数，目标 ≥ 80%
  • 满意度：反馈问卷平均分，目标 ≥ 4 分（5 分制）
  • 提前通知率：开课前 5 天发出通知的场次占比，目标 ≥ 90%
  • “找谁安排”类咨询次数：目标每月 0 次

8. 低效诊断

  • 现象：讲者不知道找谁安排，得到多个不同答案，培训归属一度“没人管”（未指定培训统筹人，也没有申请入口）｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-07
  • 现象：讲者在技术群说的话，组织人没看到（群太多，申请没有固定入口）｜依据：「鼎慧产研决策部」2026-04
  • 现象：海报缺主讲人和时间，文案改两轮；报名截止后才发现场地容量不匹配（公告缺必填项校验，场地确认靠后）｜依据：「鼎慧产研决策部」2026-04
  • 现象：多人反复提醒“记得录屏”“求回放”，课件和录屏存放位置不明（录屏和归档无责任人）｜依据：「跃迁AI总动员」2026-04、「模态跃迁通知群」2026-07
  • 现象：会议链接进不去、有人问“有没有日程分享”，同一培训多次预告（通知未用飞书日程统一推送）｜依据：「模态跃迁通知群」2026-06、「模态跃迁通知群」2026-10
  • 现象：报名表单无人填，分享因同周活动太多被迫延期（缺统一培训日历，活动排期冲突）｜依据：「鼎慧产研决策部」2026-04
  • 现象：强制听课与修 Bug 冲突，缺席后只能会后看录屏，没有签到记录（强制培训缺签到与补训机制）｜依据：「Leap产研测」2026-06
  • 现象：参训确认靠各负责人转发部门群（参训确认未直接推送给个人）｜依据：「【模态】综合部」2026-10
  • 现象：课程讲师同时负责开发，做课与开发抢时间（讲师排期未纳入工作量）｜依据：「模态AI探索小分队」2026-04

9. 分支变体

  • 强制培训（价值观、FDE 初级、LeapCore/LeapAll 产研课）：综合部按人事库名单出参训确认表，缺席需补看回放；FDE 初级作为全员 AI 素养达标基准
  • 自愿报名（AI 总动员讲座、技术 Webinar、周五分享）：问卷/日程报名，按人数定场地
  • 面向非技术岗的 AI 工具培训：内容需“保姆级”，课前提供软件清单和账号注册指引，案例由业务侧补充
  • 外部或制度类培训（专利、信创）：由总经办组织，资料由总经办统一整理
  • 学习委员轮值：各项目组学习小组长负责本组分享，结果汇入统一培训日历
  • 团队文化类（MBTI 收集、员工培训文稿整理）：人事负责，按本流程归档资料

10. 待确认问题

  • 内部培训统筹人是否正式指定为学习委员？与课程体系负责人、总经办的分工如何划分？
  • 周五分享是否固定为每周一次？固定时段是哪个？
  • 哪些培训属于强制？缺席补训的期限 5 个工作日是否可行？
  • 课程资料统一放在哪个知识库目录？查看权限如何设置？
  • 讲师备课和授课时间是否计入工作量或积分（HR-18）？
HR-24员工活动：年会、团建与委员/兴趣小组待优化108

状态：待优化｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：组织年度全员大会、户外团建、联合团建、节日或非工作活动，以及学习/卫生/文体委员和兴趣小组开展活动、申请经费时启动
  • 负责人：主责——活动后勤负责人（行政，当前：侯明月·推断待确认）；协同——人事负责人（请假与人员名单，当前：黄莹·推断待确认）、文体委员（当前：王皓南、黄莹·推断待确认）、卫生委员（当前：侯明月、赵雪冰·推断待确认）、学习委员（当前：杨萌·推断待确认）、各项目组小组长；决策——CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·部门报送人）
  • 核心流程：① 年度活动日历 → ② 活动立项与预算 → ③ 时间投票（选项完整）→ ④ 提前 7 天发正式通知 → ⑤ 报名/请假/饮食一表收集 → ⑥ 后勤落实 → ⑦ 前一天提醒、当天签到 → ⑧ 复盘归档与费用报销
  • 交付结果：年度活动日历；活动方案与预算审批；正式通知（时间、地点、路线、环节、请假方式）；报名与签到记录；活动复盘与费用凭证；委员活动记录（用于积分）
  • 状态依据：年会、团建、委员活动已跑通并任命了各类委员；但 2026-01～05 投票漏选项重发，员工在活动前一天还在问时间地点，外部团建报名走私聊，委员制度细则、经费额度与审批方式未出，活动时间调整只靠群通知

1. 场景判定

  • 触发条件：年度大会、春季/秋季团建、与合作单位的联合团建、节日活动（如六一）；委员或兴趣小组要办活动或申请经费；新任命委员
  • 典型说法：「征求一下大家的意见，年度大会安排在周末还是工作日」「咱还没通知时间地点呢吧」「请假的提前说」「我们将会有专项经费支持大家学习、娱乐和团建」「什么时候补充一下小组的经费」
  • 判断问题：这是以团队凝聚与员工生活为目的的活动吗？如果是业务培训或对外市场活动，不归本流程
  • 不归本流程管：内部培训与分享会 → 请走 HR-23；对外会议、展会、渠道沙龙 → 请走 MKT-03（参展/大会报名与现场执行统筹）/ ECO-01（生态活动年度规划与 ROI 取舍）；年度总结与 1v1 → 请走 HR-21；年会发放的体检卡 → 请走 HR-22；办公环境卫生日常管理 → 请走 ADM-11（办公区保洁、值日、大扫除与虫害消杀）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
活动后勤 场地、交通、餐饮、物料、游戏规则、通知与提醒、费用报销 R 活动后勤负责人（行政，当前：侯明月·推断待确认）
人事 参会名单、请假登记、调休口径 R 人事负责人（当前：黄莹·推断待确认）
决策 定年度活动、日期、预算；任命委员 A CEO（当前：邴龙志·推断待确认）
文体委员 文体/兴趣小组活动策划、投票、通知 R 文体委员（当前：王皓南、黄莹·推断待确认）
卫生委员 卫生管理活动与规则同步 R 卫生委员（当前：侯明月、赵雪冰·推断待确认）
学习委员 学习小组活动、招募 R 学习委员（当前：杨萌·推断待确认）
小组长 本项目组的学习/卫生/文体活动执行 R 各项目组小组长（当前：待指定）
财务 活动经费付款与报销 C 财务（当前：待指定）
员工 投票、报名、请假、参与、反馈 I 全体员工

3. 办之前请准备

  • 活动目的、候选日期（至少 3 个，含“都可以/都不行”选项）、是否占用周末及调休口径
  • 预算估算（场地、餐饮、交通、物料、奖品），委员活动注明经费来源
  • 人员名单（含子公司/合作团队是否参加、新入职人员）
  • 后勤清单：场地、路线图、交通班次、餐饮（含忌口）、证件要求、天气、保险
  • 环节安排：讲话、团体互动、游戏规则、福利发放

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定年度活动日历（年会、两次团建、节日活动），委员提交各自季度活动计划 活动后勤、各委员 每年 1 月 15 日前；委员每季度首月 10 日前 多维表格 + 飞书日历 年度活动日历 🔧飞书固化
2 活动立项：方案 + 预算，提交审批（小额委员活动由综合部负责人批，额度待确认） 活动后勤 / 委员 活动前 3 周（年会）/ 1 周（委员活动） 飞书审批 审批通过的方案 🔧飞书固化
3 时间投票：发布前另一人核对选项完整，投票 48 小时截止 活动后勤 / 文体委员 立项后 2 个工作日内 飞书投票 投票结果 🔧+👤
4 定稿后发正式通知：时间、地点、路线图、时长、餐饮、环节、着装、请假方式，同时发飞书日程 活动后勤 活动前 7 天 飞书公告 + 日程 正式通知 🔧飞书固化
5 一表收集：是否参加、请假原因、饮食忌口、交通方式；外部/联合团建也用表单报名，不走私聊 活动后勤、人事 活动前 4 天截止 飞书表单 报名/请假名单 🔧飞书固化
6 落实后勤：场地、交通班次、餐饮、物料、分组卡、福利；外出活动购买保险 活动后勤 活动前 2 天 采购/付款审批 后勤清单 👤人工判断
7 前一天提醒：集合时间地点、天气、证件、交通班次；倒计时机器人推送 活动后勤 活动前 1 天 17:00 前 飞书机器人 提醒 🤖自动化
8 当天签到、执行环节；变更即时在通知群和日程同步更新 活动后勤、委员 活动当天 飞书签到 签到记录 🔧飞书固化
9 复盘：照片、参与人数、反馈、费用；委员活动登记到活动计分表（转 HR-18） 活动后勤 / 委员 活动后 3 个工作日内 飞书文档 + 多维表格 复盘与计分 🔧+👤
10 费用报销与凭证归档 活动后勤 → 财务 活动后 5 个工作日内 飞书报销审批 报销单 🔧飞书固化

5. 交付物与模板

  • 交付物：年度活动日历、活动方案与预算审批、投票结果、正式通知与日程、报名/请假名单、后勤清单、签到记录、复盘与计分、报销凭证
  • 建议模板/表单：
    • 活动方案模板：目的、日期、地点、对象、环节、预算明细、交通、餐饮、安全预案、负责人分工
    • 通知模板（必填）：时间、地点、路线图、集合时间、时长、餐饮、环节、着装/证件、请假方式与截止
    • 报名表单：姓名、是否参加、请假原因、饮食忌口、交通方式、紧急联系人（外出活动）
    • 委员活动申请表：委员类型、小组、活动内容、时间、预计人数、经费申请、是否计积分
    • 活动计分表：活动、组织人、参与人、时长、积分

6. 异常与升级

  • 投票选项遗漏或冲突 → 当天撤回重发，并在群里说明（不超过 1 次）
  • 活动前 3 天仍未定地点或时间 → 活动后勤升级综合部负责人当天决定，必要时延期
  • 天气或交通原因需改期 → 活动前 1 天 12:00 前决定，同步更新通知和日程
  • 活动中出现安全或健康事件 → 现场负责人立即处置并通知综合部负责人，当天上报 CEO
  • 委员活动经费超出预先征求的额度 → 先提交审批，未批不得先垫付
  • 请假人员较多影响活动 → 人事汇总后报 CEO 决定是否调整日期

7. 衡量指标

  • 通知提前量：正式通知距活动的天数，目标 ≥ 7 天
  • 活动前一日追问次数：群内关于时间地点的提问次数，目标 0
  • 参与率：签到人数 ÷ 应参加人数，目标 ≥ 90%（年会）
  • 满意度：活动反馈平均分，目标 ≥ 4 分（5 分制）
  • 预算执行偏差：实际费用 ÷ 预算，目标在 90%～110%
  • 委员活动执行率：计划活动场次中实际举办的比例，目标 ≥ 80%

8. 低效诊断

  • 现象：年度大会时间投票漏选项，重新发多日期投票（投票发布前没有核对环节）｜依据：「模态集团（全员群）」2026-01
  • 现象：活动前一天员工还在问时间地点，路线图傍晚才补发（正式通知时间点未固定）｜依据：「模态集团（全员群）」2026-01
  • 现象：请假口头告知行政或人事，外部联合团建报名走私聊（缺统一报名/请假表单）｜依据：「模态集团（全员群）」2026-01、「模态集团（全员群）」2026-04
  • 现象：委员制度宣布后，经费、活动审批、记录方式未定，小组追问经费（细则后置）｜依据：「模态集团（全员群）」2026-04
  • 现象：活动时间调整只在群里通知，参与者容易错过（变更未同步日程）｜依据：「模态双语幼儿园」2026-05、「模态文体委员群」2026-05

9. 分支变体

  • 年度全员大会：CEO 主讲，含讲课、团体互动、年庆福利；如占用周末需人事明确调休口径
  • 户外团建：增加交通班次、证件、天气、保险
  • 联合团建（与合作单位）：只发邀请，有意愿者用表单报名，名额与费用分摊另行确认
  • 非工作活动（办公室节日快闪、KTV 等）：委员发起，时长和场地需行政确认不影响办公
  • 委员与兴趣小组：学习/卫生/文体三类委员由 CEO 任命，每个项目组设对应小组长；兴趣小组（如英语小组）自助报名、固定活动日；活动按计分表计入积分激励
  • 子公司或合作团队人员参加：由活动后勤确认名单与费用归属

10. 待确认问题

  • 活动主责归行政还是人事？行政负责人交接后，后勤是否仍由原负责人承担？
  • 委员活动经费的额度、审批人、报销方式是否已定？是否需要成文的委员制度细则？
  • 委员活动是否计入积分？计分标准由谁定？
  • 年度团建次数（暂按两次）是否合理？
  • 占用周末的活动如何调休？
HR-25人员调岗、借调与汇报线确认待新建108

状态：待新建｜证据：有证据（卡片 6 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：员工要从一个组/业务线长期调到另一个组，或被临时借调（含按比例投入，如 0.5 人力），或实习生被其他组拉去干活，或组织调整后直属上级变化时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——调出方负责人、调入/借调方负责人（当前：按个案指定）、资源裁定人：创始人兼 CTO（当前：丁震宇·推断待确认）；兜底——综合部负责人
  • 核心流程：① 调入方提需求 → ② 先与调出方负责人对齐 → ③ 有冲突时资源裁定 → ④ 提交调岗/借调审批 → ⑤ 明确汇报线、派活人、绩效归属与期限 → ⑥ 工作交接与权限调整 → ⑦ HR 更新飞书架构并通知 → ⑧ 借调到期归还或续期
  • 交付结果：已审批的调岗/借调单（含汇报线、派活人、绩效归属、期限、投入比例）、接手人签收的交接清单、更新后的飞书组织架构与人员异动记录、原组和新组群内通知
  • 状态依据：没有调岗/借调申请表和审批，靠口头商量和群内一句话宣布；2026-01～06 多次出现越过原负责人直接找老板要人、同一人被多人派活、调走后仍被@处理原工作、交接进度靠催问

1. 场景判定

  • 触发条件：
    • 某组想长期调入其他组成员（如调往 FDE、水利 AI、基座组、生态组）
    • 项目缺人，需要从其他组临时借人，或按比例分出人力
    • 组织架构调整后，员工的直属上级或归属组发生变化
    • 发现一名员工同时被两个以上负责人派活，汇报线说不清
  • 典型说法：「把之前的工作和XX对接一下，好像已经调你俩去FDE组了」「你们组哪个研发能来帮帮忙」「应该先跟我通好气再跟老板说」「在组织架构未调整前，严谨的说法就是借调」
  • 判断问题：这个人的直属上级、日常派活人、绩效评定人，三者中有没有任一项会变？变化是否超过 2 周？有一项会变，就走本流程
  • 不归本流程管：
    • 部门新设、更名、负责人整体调整 → 请走 CEO-06、HR-02
    • 需要新增编制（专属 HC）→ 请走 HR-03
    • 调岗同时调薪 → 请走 HR-09
    • 研发代码、工单、环境的细项交接 → 请走 RND-85
    • 账号与权限回收 → 请走 X-SEC-08
    • 因绩效问题调岗或降薪转岗 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
调入/借调方负责人 提出需求，说明工作内容、投入比例、期限；借调期间按约定派活 R 各组负责人（当前：按个案指定）
调出方负责人（直属上级） 评估影响并答复；安排交接；借调期间仍是直属上级 R 各组负责人（当前：按个案指定）
资源裁定人 双方不一致或涉及战略优先级时裁定；批准长期调岗 A 创始人兼 CTO（当前：丁震宇·推断待确认）
CEO 跨条线调动、需新增专属 HC 时审批 C CEO（当前：邴龙志·推断待确认）
业务分管高管 新负责人接手后向其汇报 I COO（当前：常元和·推断待确认）
人事 登记审批，更新飞书架构、直属上级与花名册，发通知，借调到期提醒 R 人事负责人（当前：黄莹·推断待确认）
被调人员 填写交接清单；按新汇报线工作；收到第三方派活先上报 R 本人
接手人 逐项确认接收交接事项 C 由调出方负责人指定
IT/行政 账号权限、工位设备调整 C IT 运维、行政（当前：待指定）

3. 办之前请准备

  • 被调人员现直属上级、现负责事项清单（进行中任务、负责系统、对外联系人）
  • 调入方说明：工作内容、项目角色（如主程、IT 负责人、API 支持）、投入比例（全职 / 0.5 人力）、起止日期
  • 是否需要长期占用（长期占用建议同时申请专属 HC）
  • 借调期间绩效由谁评定、怎么分比例
  • 交接清单初稿（模板见第 5 节）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 调入方先向调出方负责人提出需求，不得先越级找老板 调入方负责人 期望到岗日前至少 5 个工作日 飞书消息/会议 需求说明 👤人工判断
2 调出方评估对本组影响，答复同意、有条件同意或不同意 调出方负责人 收到需求后 2 个工作日内 飞书消息 答复结论 👤人工判断
3 双方不一致，或同一人被多线争夺，提交裁定（按公司战略优先级） 资源裁定人 提交后 3 个工作日内 飞书审批 裁定结论 👤人工判断
4 发起“调岗/借调”审批：类型、直属上级、派活人、绩效归属、期限、投入比例，自动抄送双方负责人和本人 调入方负责人 达成一致后 1 个工作日内 飞书审批 审批单 🔧飞书固化
5 被调人员填交接清单，接手人逐项确认 被调人员、接手人 生效日前完成，最迟生效后 3 个工作日 飞书文档模板 签收的交接清单 🔧+👤
6 调整代码仓库、业务系统权限、群成员、工位设备 IT、行政、群主 生效日当天 飞书管理后台、Gitea 权限变更记录 🔧飞书固化
7 更新飞书组织架构、直属上级、审批人；登记人员异动表（按 HR-26 同步） 人事 生效后 1 个工作日内 飞书管理后台、多维表格 架构与异动记录 🔧飞书固化
8 在原组群、新组群发通知：谁、调往哪、自何日起原事项找谁 人事或调入方负责人 生效日当天 飞书群/机器人 群通知 🔧+🤖
9 借调到期前提醒；借调方确认“暂无需求”后归还，或发起续期 人事（机器人提醒）、借调方负责人 到期前 5 个工作日 多维表格提醒 归还/续期记录 🔧+🤖

5. 交付物与模板

  • 交付物：调岗/借调审批单、交接清单、飞书架构变更、人员异动记录、群通知、借调台账
  • 建议模板/表单：
    • “调岗/借调”审批字段：被调人员、类型（长期调岗/临时借调/实习生借用/顾问支援）、调出组、调入组、直属上级（变更后）、日常派活人、绩效评定人及比例、投入比例、起止日期、是否需专属 HC、交接接手人、裁定意见
    • 交接清单字段：进行中事项与截止日、负责系统与账号、文档位置、对外联系人/客户、待处理问题、接手人确认时间
    • 借调台账（多维表格）：人员、借出组、借入组、比例、到期日、状态（借调中/已归还/已续期），用于每周资源占用看板

6. 异常与升级

  • 调入方越过原负责人直接找老板要人 → 老板或裁定人退回，要求先完成第 1～2 步 → 不受理直至双方对齐（1 个工作日内退回）
  • 借调人员被第三方（市场或其他组）直接派活 → 本人不接，转告直属上级和借调方 → 双方 1 个工作日内决定；再次发生升级资源裁定人
  • 调走后仍被@处理原工作 → 本人回复转给接手人；接手人不明确时，调出方负责人 1 个工作日内指定
  • 生效后 3 个工作日交接仍未签收 → 人事提醒 → 升级调出方负责人
  • 借调到期未归还也未续期 → 人事提醒双方负责人 → 3 个工作日内仍无结论升级资源裁定人
  • 被调人员对调动有异议 → 人事 2 个工作日内与本人沟通 → 升级综合部负责人

7. 衡量指标

  • 调动审批覆盖率 = 走审批的调岗/借调数 ÷ 实际发生数，目标 100%
  • 汇报线清晰率 = 抽查被调人员能准确说出直属上级、派活人、绩效评定人的比例，目标 100%
  • 交接完成时长 = 生效日到交接清单签收的工作日数，目标 ≤ 3 个工作日
  • 调走后被@回原工作次数 = 每人生效后 1 个月内次数，目标 ≤ 1 次
  • 架构同步时效 = 生效到飞书架构更新，目标 ≤ 1 个工作日

8. 低效诊断

  • 需求发起环节：调入方通过老板直接要人，原负责人事后才知道，影响团队信任，事后再评估影响｜依据：「鼎慧产研决策部」2026-01
  • 派活环节：借调人员同时接收直属上级、借调方、市场侧三方派活，汇报线混乱，需要高层多次出面重申“借调”口径与绩效归属｜依据：「鼎慧产研决策部」2026-06
  • 交接环节：调岗在群内一句话宣布，没有交接清单，调走后仍被@处理原负责系统，其他同事事后才知负责人已变，交接进度靠催问｜依据：「Leap产研测」2026-06
  • 组织同步环节：借调与归属口径没有登记，需要在群内专门捋清“直属上级是谁、借调给谁、职责如何转交”后再通知相关人｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 长期调岗（调往 FDE、水利 AI、基座组、生态组）：需资源裁定人批准，人事改飞书架构；调入方长期占用的，同时申请专属 HC（HR-03）
  • 临时借调（运营人员借调到 LeapAll/LeapCore；研发跨组按 0.5 人力支援）：直属上级不变，借调期间向借调方汇报；绩效、转正由直属上级评定，借调方提供意见；到期归还
  • 实习生被他组使用：一律按借调处理，派活前须先向直属上级和借调方报备
  • 顾问式支援（只答疑、不占人力）：不走审批，在项目角色表登记即可
  • 跨主体调动（模态、鼎慧、跃竞之间）：涉及用工主体变化，另走 HR-04

10. 待确认问题

  • 本流程主责是人事，还是调入方负责人？长期调岗的批准人是 CTO 还是 CEO？
  • 借调期绩效：由直属上级评定，还是直属上级与借调方共同评定？比例如何？
  • 借调超过多长时间应转为正式调岗（建议 3 个月）？
  • 是否在飞书新建“调岗/借调”审批，并配借调台账与每周资源占用看板？
  • 需求至少提前 5 个工作日提出是否可行？紧急项目的例外口径是什么？
HR-26人事异动同步通知待新建120

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险5

  • 适用场景：入职、转正、调岗/借调、调薪、离职任一人事异动确定（审批通过或生效日确定）后，把信息同步给 CEO、财务、行政、IT、直属上级和相关群
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——财务（当前：祁航·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）；兜底——综合部负责人
  • 核心流程：① 异动审批通过 → ② 人事当天登记 → ③ 机器人按类型推送 CEO/财务/行政/IT/直属上级 → ④ 各方 1 个工作日内回执 → ⑤ 人事群同步、有无特殊处理 → ⑥ 先通知再改飞书架构 → ⑦ 月度异动表审核后交财务
  • 交付结果：每条异动都有登记和各接收方回执；月度人员异动表审核通过并作为工资核算依据；飞书组织架构与实际一致
  • 状态依据：2026-02 离职信息在中间环节断档，CEO 与财务不知情，险些多发工资；同步规则只是群内口述三条，未成文、无回执；2026-07 仍出现架构调整后未同步、多人不知情

1. 场景判定

  • 触发条件：入职到岗日确定；转正审批通过；调岗/借调审批通过；调薪审批通过；离职审批通过或 last day 确定；组织架构调整
  • 典型说法：「以后人事变动的同步规范得改改了」「CEO到现在都不知道XX离职了」「这个是3月的人员异动表请审核」「组织架构调整完了记得同步 不然好多人都不知道」
  • 判断问题：这次变动是否影响工资、社保、资产、账号权限、汇报线中任意一项？影响就必须走本流程同步
  • 不归本流程管：
    • 异动本身的办理 → 请走 HR-05（入职）、HR-08（转正）、HR-25（调岗）、HR-09（调薪）、HR-27（离职）
    • 工资核算发放 → 请走 HR-15；社保公积金增减员 → 请走 HR-16
    • 飞书组织架构与审批人设置 → 请走 HR-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事 登记异动、触发通知、追回执、出月度异动表 R 人事负责人（当前：黄莹·推断待确认）
规则制定与审核 制定同步规则，审核月度异动表 A 创始人兼 CTO（当前：丁震宇·推断待确认）
CEO 接收离职、调薪、关键岗位异动 I CEO（当前：邴龙志·推断待确认）
财务 接收异动与考勤，调整、停发工资奖金，回执 R 财务（当前：祁航·推断待确认）
行政 入职发放、离职清点回收资产，回执 R 行政（当前：侯明月·推断待确认）
IT 运维 账号开通、停用，回执 R IT 运维（当前：杨明学·推断待确认）
直属上级/业务负责人 接收通知，提出特殊处理 C 各组负责人

3. 办之前请准备

  • 异动类型、生效日期、所属主体（模态/鼎慧/跃竞等）、部门、直属上级
  • 对应审批单链接
  • 是否影响工资、社保、资产、账号（逐项勾选）；涉及薪资只写“自 X 月起调整/停发”，金额不进群
  • 入职发放或离职回收的资产、账号清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 异动审批通过或生效日确定后，在“人员异动登记表”新增记录 人事 当天 多维表格 异动记录 🔧飞书固化
2 按类型自动推送：离职、调薪 → CEO + 财务；入职、离职 → 行政 + IT；全部 → 直属上级 机器人 登记后自动 飞书机器人 推送消息 🔧+🤖
3 各接收方在记录中点“已知悉/已处理” 财务、行政、IT 1 个工作日内 多维表格 回执 🔧飞书固化
4 未回执自动再提醒；第 2 个工作日人事单独确认 机器人、人事 第 2 个工作日 飞书机器人 补齐回执 🔧+🤖
5 在人事管理群同步异动（不含薪资），确认有无特殊处理 人事 当天 飞书群 群消息 🔧飞书固化
6 架构类变动：先在相关群通知，再改飞书组织架构 人事 通知后 1 个工作日内 飞书管理后台 架构更新 🔧飞书固化
7 汇总上月人员异动表，发群审核 人事 每月第 3 个工作日前 多维表格视图 月度异动表 🔧+🤖
8 审核通过后交财务，作为工资核算依据 规则制定与审核、财务 审核后 1 个工作日内 多维表格 工资依据 🔧飞书固化

5. 交付物与模板

  • 交付物：异动登记记录（含回执）、月度人员异动表、群通知
  • 建议模板/表单：
    • 人员异动登记表字段：姓名、主体、部门、异动类型、生效日、审批单链接、影响项（工资/社保/资产/账号/汇报线）、通知对象、财务回执时间、行政回执时间、IT 回执时间、CEO 已知悉、备注
    • 通知模板：「【人事异动】XX（部门）自 X 月 X 日起 入职/转正/调至XX/离职，请财务、行政、IT 在 1 个工作日内处理并回执」

6. 异常与升级

  • 财务 1 个工作日未回执且临近发薪日 → 人事直接联系财务负责人 → 当天仍未确认升级 CEO
  • 发现已离职人员仍在发薪名单 → 财务暂停发放 → 人事与 CEO 当天核实
  • 信息只告诉了中间人 → 规则：人事直接通知 CEO 与财务，不依赖转述；发现断档当天补发
  • 架构调整后业务群不知情 → 人事 1 个工作日内补发通知
  • 月度异动表审核发现与实际不一致 → 人事 2 个工作日内核对修正，同步财务

7. 衡量指标

  • 同步及时率 = 1 个工作日内全部回执的异动数 ÷ 异动总数，目标 ≥ 95%
  • 薪资差错数 = 因异动未同步导致的多发、漏发次数，目标 0
  • 月度异动表按期率 = 第 3 个工作日前提交审核的月数 ÷ 总月数，目标 100%
  • 架构同步时效 = 生效到飞书架构更新，目标 ≤ 1 个工作日

8. 低效诊断

  • 通知链路环节：离职信息只告知了中间环节，未继续传到 CEO 和财务，险些多发工资，事后才重新梳理离职流程｜依据：「鼎慧产研决策部」2026-02
  • 规则载体环节：同步要求只是群内口述三条（行政回收资产、考勤给财务、同步到群），无成文规范、无回执｜依据：「模态人事大主管」2026-02
  • 月度汇总环节：异动表按月人工整理后发群审核，只覆盖部分主体｜依据：「模态人事大主管」2026-04
  • 架构变更环节：组织架构调整后未及时通知，多人不知道新的归属｜依据：「模态人事大主管」2026-07

9. 分支变体

  • 入职：通知行政备工位设备、IT 开账号、财务登记起薪日
  • 转正、调薪：只通知财务、直属上级和 CEO，不在公共群发布薪资信息
  • 调岗、借调：通知原组群和新组群，更新直属上级与审批人
  • 离职：CEO、财务（停薪）、行政（资产）、IT（账号）四方必须回执
  • 主体差异：月度异动表目前只覆盖模态和鼎慧，跃竞等其他主体由谁登记同步待确认

10. 待确认问题

  • 同步规则是否由人事正式成文并发布？
  • 财务接口人是否已变更（人员表显示早期财务已交接）？行政接口人是谁？
  • 哪些异动必须通知 CEO？是否包括所有入职？
  • 月度异动表审核人是谁？第 3 个工作日前是否可行？
  • 飞书人事模块能否直接触发通知，替代人工登记？
  • 跃竞等其他主体是否纳入月度异动表？
HR-27员工离职办理与交接待优化225

状态：待优化｜证据：有证据（卡片 8 张 / 会话 10 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：正式员工、实习生、兼职或顾问提出离职、被劝退、合作到期终止，或发现未办手续离岗时启动；长假前、业务系统移交、换账号时参照其中交接与数据转移步骤
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——离职人直属上级（当前：按个案）、财务负责人（当前：黄梦婷·推断待确认）、行政（当前：侯明月·推断待确认）、IT 运维（当前：杨明学·推断待确认）、CEO（当前：邴龙志·推断待确认，审定离职文件、决定竞业）；兜底——综合部负责人
  • 核心流程：① 飞书提交离职申请 → ② 直属上级审批、定 last day 与接手人 → ③ 写交接文档、接手人确认 → ④ 财务核查未完结事项 → ⑤ 离职文件拟定审定 → ⑥ last day 回收资产、停账号、退群 → ⑦ 清理席位、结算最后工资 → ⑧ 归档
  • 交付结果：审批通过的离职单、接手人签收的交接文档、财务/行政/IT 回执、《离职声明》《员工离职单》《离职证明》、最后工资结算记录
  • 状态依据：已有飞书离职审批、三份离职文件模板和离职交接清单 wiki；但 2026-01～09 仍多次出现账号残留、财务行政不知情、付款未回票人已离职、实习生未办手续离岗、交接对象临时改派

1. 场景判定

  • 触发条件：
    • 员工在飞书提交离职申请，或已决定劝退、试用不通过（决定过程见 HR-20、HR-08）
    • 实习、兼职、顾问合作到期终止
    • 发现员工未办手续已不到岗
    • 员工换账号需转移网盘、Agent 数据（只做第 5 步）
    • 毕业长假或系统移交其他团队（只做第 4、9 步）
  • 典型说法：「他会在飞书提交离职申请流程 批好了我处理其他的」「怎么直接就走了，离职流程也没做」「公司人员离职前可以过一下财务嘛」「账号先别删」「企业微信XX还在」
  • 判断问题：此人是否不再为公司（该主体）工作？名下是否有工作、客户、数据、账号、资产、未结费用？有任一项就按本流程逐项关闭
  • 不归本流程管：
    • 是否劝退、是否终止试用的决定 → 请走 HR-20、HR-08
    • 内部调岗、借调 → 请走 HR-25
    • 异动通知规则 → 请走 HR-26
    • 研发代码、工单、环境细项交接 → 请走 RND-85
    • 账号回收技术操作 → 请走 X-SEC-08；设备回收入库 → 请走 ADM-32
    • 社保公积金减员 → 请走 HR-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
离职人 提交申请、写交接文档、归还资产、删除个人设备中的公司资料 R 本人
直属上级 审批、确定 last day、指定接手人（工作/客户/数据）、确认交接完成 A 各组负责人
接手人 接收工作、客户关系、数据并逐项确认 R 由直属上级指定
人事 流程总控、拟离职文件、分派清单、核出勤、清席位、归档 R 人事负责人（当前：黄莹·推断待确认）
CEO 审定离职文件，决定竞业是否执行与特殊补偿 A（升级） CEO（当前：邴龙志·推断待确认）
财务 核查报销、借款、付款回票、加班费；停薪与最后工资结算 R 财务负责人（当前：黄梦婷·推断待确认）；早期财务（当前：祁航·推断待确认）
行政 清点回收电脑、门禁卡等资产 R 行政（当前：侯明月·推断待确认）
IT 运维 封 Gitea，停飞书/企业微信/云/服务器账号，移出群 R IT 运维（当前：杨明学·推断待确认）
业务系统管理员 系统账号停用或加入过滤名单；LeapCore 管理后台数据转移 R 后端/运维研发（当前：宋祺睿·推断待确认）
群主 将离职人移出所管理的飞书群、微信项目群 R 各群群主
飞书/Gitea 管理员兜底 管理员权限兜底，研发侧系统移交说明 C 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 离职人：last day、名下工作清单、客户/渠道联系人、账号清单、资产清单、未完结报销/借款/付款
  • 直属上级：工作、客户关系、数据三类各由谁接手
  • 人事：离职文件模板、离职交接清单、出勤记录、加班与调休余额
  • 财务岗、核心岗：保密承诺、需删除资料清单、需退出的外部合作群
  • 研发岗：仓库、服务器、云平台、NewAPI 等账号清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在飞书提交离职申请（实习生、兼职同样提交） 离职人 正式员工 last day 前 30 天；试用期 3 天；实习生至少 5 个工作日 飞书审批 离职申请 🔧飞书固化
2 审批，确定 last day、各类接手人；人事确认 直属上级、人事 收到后 2 个工作日内 飞书审批 审批结论 🔧+👤
3 审批通过自动生成离职清单任务，分派财务、行政、IT、接手人；按 HR-26 通知 CEO 与财务 机器人、人事 审批通过当天 飞书任务/机器人 清单任务 🤖+👤
4 按模板写交接文档（进行中事项、文档位置、账号、对外联系人），发接手人逐项确认；客户关系由直属上级确认接手人 离职人、接手人 last day 前 3 个工作日 飞书 wiki 模板 签收的交接文档 🔧+👤
5 网盘资料、LeapCore Agent 数据用管理后台“转移资料并删除”转给接手人；未确认接手人不得直接删除 离职人、业务系统管理员 last day 前 1 个工作日 LeapCore 管理后台 转移记录 🔧+👤
6 核查报销、借款、付款未回票、预付费用、加班，出结论 财务 last day 前 3 个工作日 飞书审批会签 财务回执 🔧飞书固化
7 拟《离职声明》《员工离职单》《离职证明》，报 CEO 审；是否执行竞业由 CEO 决定 人事、CEO last day 前 2 个工作日 docx 模板 审定文件 👤人工判断
8 财务岗、核心岗：现场监督删除个人设备中的公司资料，退出外部合作群，签保密承诺 人事、直属上级 last day 当天 现场 保密承诺 👤人工判断
9 回收资产；封 Gitea，停飞书、企业微信、云平台、服务器、业务系统账号，移出飞书与微信项目群；因代码依赖需保留的账号改为停用或加入过滤名单 行政、IT 运维、业务系统管理员、群主 last day 当天下班前 资产表、各系统后台 回收/停权回执 🔧+👤
10 清理飞书席位 人事 last day 后 1 个工作日内 飞书管理后台 释放席位 🔧飞书固化
11 按实际出勤折算最后工资；无法调休的加班按加班费结算；停薪 人事、财务 下一发薪日前 考勤、工资表 结算记录 🔧飞书固化
12 离职资料归档，出具离职证明 人事 last day 后 3 个工作日内 人事档案 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：离职审批单、离职清单（各方回执齐全）、交接文档、三份离职文件、结算记录
  • 建议模板/表单：
    • 离职清单（多维表格，审批通过自动生成）字段：离职人、主体、部门、类型（正式/实习/兼职/顾问）、last day、工作接手人、客户接手人、数据接手人、交接文档链接、财务核查结论、资产回收、账号逐项（飞书、企业微信、Gitea、云平台、服务器、NewAPI、业务系统、飞书群、微信项目群）、席位释放、竞业决定、保密承诺、最后工资结算、完成时间
    • 交接文档模板：进行中事项及截止日、文档与代码位置、负责系统与账号、对外联系人与客户、已知风险与待办、接手人确认

6. 异常与升级

  • 未提交申请就不到岗（多见实习生）→ 直属上级当天报人事，人事 1 个工作日内联系本人确认是请假还是离职；确认离职则补走流程，账号先冻结 → 联系不上升级综合部负责人
  • 到 last day 交接仍未签收 → 不关闭审批，账号延迟停用至交接完成（最长 3 个工作日）→ 升级直属上级
  • 客户关系无人接 → 直属上级 1 个工作日内指定 → 仍不明确升级销售负责人
  • 离职后才发现付款未回票或报销超额度 → 财务联系本人追补，人事协助 → 无法解决升级 CEO
  • last day 后账号仍可用或人仍在群内 → 发现人报 IT，当天处理，纳入月度复盘
  • 竞业、特殊补偿有争议 → CEO 决定，征求法务意见
  • 升级拍板：日常离职（last day、接手人、交接完成确认）由直属上级作为 A 拍板；出现以下任一情形时由 CEO 作为 A（升级）裁决——离职文件需审定、关键岗位是否执行竞业、特殊补偿、离职后未结费用经财务追补仍无法解决
  • 交接对象被改派 → 以直属上级最终指定为准，当天更新清单

7. 衡量指标

  • 离职清单闭环率 = last day 当天各方回执齐全的人数 ÷ 离职人数，目标 ≥ 95%
  • 账号残留数 = last day 后 1 个工作日仍可登录的账号数，目标 0
  • 离职后才发现的未结费用数，目标 0
  • 交接签收率 = 有接手人签收交接文档的离职数 ÷ 离职人数，目标 100%
  • 未走流程离岗次数，目标 0
  • 席位释放时效 = last day 到席位释放，目标 ≤ 1 个工作日

8. 低效诊断

  • 账号回收环节：离职后企业微信等账号仍在，靠同事偶然发现提醒｜依据：「鼎慧产研决策部」2026-01
  • 费用核查环节：离职前未经财务核查，事后才发现报销额度争议｜依据：「鼎慧产研决策部」2026-01
  • 费用核查环节：离职人员提交的付款未回票人已离开，财务事后才提出“离职前过一下财务”｜依据：「薪酬对接群」2026-09
  • 通知环节：财务、行政未及时得知离职，资产与停薪靠事后补｜依据：「模态人事大主管」2026-02、「模态人事大主管」2026-03
  • 资料删除环节：财务岗公司资料存在个人通讯工具中，删除只能现场监督，难以确认｜依据：「模态人事大主管」2026-03
  • 客户与系统账号环节：离职工程师的客户关系不知交给谁；系统账号因代码依赖不能直接删，只能改过滤名单；离职信息靠后台名单变化才知道｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 数据转移环节：网盘、Agent 数据转移的分工当天改派，“不需要的资料也要转移吗”口径争论｜依据：「Leap产研测」2026-06

9. 分支变体

  • 正式员工：完整 12 步
  • 实习生、兼职：通知期按协议；重点是成果交接、账号回收、加班结算；兼职实习可按“合作到期终止”处理
  • 财务岗、核心岗：增加第 8 步（资料删除监督、退外部群、保密承诺）
  • 顾问、外部咨询清退：无劳动关系文件，只做账号、群、数据、客户交接
  • 研发岗：代码、工单、环境交接按 RND-85；Gitea 封号必做
  • 换账号：只做第 5 步数据转移
  • 长假、系统移交：只做第 4 步交接和第 9 步中的权限调整
  • 竞业：只针对关键岗位，由 CEO 逐人决定

10. 待确认问题

  • 通知期口径是否为：正式员工 30 天、试用期 3 天、实习生 5 个工作日？
  • 账号停权的总负责人是 IT 运维还是 CTO？企业微信、Gitea、飞书是否统一由一人操作？
  • 财务是否已加入飞书离职审批会签（已提出“加个审批”）？
  • 离职文件审定人是 CEO 还是综合部负责人？
  • 竞业执行的岗位范围是什么？
  • 席位不足时是否允许直接加购席位？
  • 最后工资按出勤折算的口径是否已成文？
  • 现有离职交接清单 wiki 是否为最新版，能否与离职审批关联自动生成？
HR-28人事档案管理与信息权限分级待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：新员工入职建档、全员档案补齐或盘点、档案保管人变更、新岗位（行政助理、会计、总助等）进群或需要查看人事表单、对外提供劳动合同等材料时启动
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——行政（当前：侯明月·推断待确认）、分级标准审定：CEO（当前：邴龙志·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 制定分级标准并由创始人评审 → ② 入职 3 个工作日内建档校验 → ③ 纸质入带锁档案柜、电子入台账 → ④ 按级配置表单与文档权限 → ⑤ 权限变更先通知后执行 → ⑥ 季度盘点与权限审计 → ⑦ 调阅与对外提供登记
  • 交付结果：员工档案/合同台账（多维表格，标出缺项）、《人事信息分级与可见范围表》、上锁档案柜及目录索引、季度盘点与权限审计记录、调阅登记
  • 状态依据：已有全员档案完善通知与表单，但 2026-02 盘点发现缺档案、合同签署情况不明；2026-03～06 多次提出信息分层隔离与分级论证，至今无书面分级标准；档案位置一度无人能答

1. 场景判定

  • 触发条件：新员工入职；全员档案补齐；档案保管人变更后的盘点；新岗位进群或申请人事表单权限；有人询问档案位置或调阅合同；招投标、资质申报需提供劳动合同
  • 典型说法：「现需全体员工于X月X日前完成个人人事档案完善工作」「盘点了档案合同，问题有点多」「要做信息分层隔离」「人事档案的文件现在在哪」「各种文档做个重要及分级」
  • 判断问题：是否涉及员工个人信息、合同、薪酬、体检等敏感信息的收集、保存、查看或外发？是就走本流程
  • 不归本流程管：
    • 劳动合同、协议签署 → 请走 HR-04
    • 公司证照、公章保管 → 请走 ADM-23
    • 集团合同、制度、项目档案 → 请走 GEN-11、LEG-11
    • 对外材料的保密审查 → 请走 LEG-30
    • 工资核算 → 请走 HR-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分级标准审定 确定信息分级与各级可见岗位；召集论证会 A（升级） CEO（当前：邴龙志·推断待确认）
创始人评审 参与分级论证；确认特殊入职人员身份与主体 C 创始人兼 CTO（当前：丁震宇·推断待确认）
人事 建档、维护台账、配置权限、盘点、调阅登记 R 人事负责人（当前：黄莹·推断待确认）
行政 纸质档案柜上锁、钥匙管理；按去敏副本办事 R 行政（当前：侯明月·推断待确认）
综合部负责人 档案室规划落地；审批对外提供合同；监督盘点 A 综合部负责人（当前：赵雪冰·推断待确认）
财务 只获取应发工资等必要数据 I 财务（当前：待指定）
员工 按时提交真实、完整的档案材料 R 本人

3. 办之前请准备

  • 档案材料清单：应聘登记表（纸质签字）、身份材料、高中后全部学历证书、劳动合同/实习协议、保密协议、入职资料
  • 分级草案：基础信息、合同、薪酬、体检与证件四类，各自可见岗位
  • 现有人事表单、多维表格、文档清单及当前权限名单
  • 带锁档案柜和目录索引表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 起草《人事信息分级与可见范围表》（建议：基础信息—行政可见；合同—人事与综合部；完整薪酬—三位创始人与人事，财务只见应发；体检与证件—仅人事） 人事 2 周内 飞书文档 分级草案 👤人工判断
2 召开论证会评审定稿并发布 CEO 召集 草案提交后 1 周内 会议 定稿分级表 👤人工判断
3 入职当天推送档案表单；员工提交后人事校验完整性，缺项自动标红提醒 人事、员工 入职 3 个工作日内 飞书表单+多维表格 档案记录 🔧+🤖
4 纸质材料放入带锁档案柜，更新目录索引；电子件存入受限空间 人事 材料收齐后 2 个工作日内 档案柜、飞书云空间 台账更新 🔧飞书固化
5 按分级表配置多维表格字段权限与文档权限；给行政等岗位提供去敏副本 人事 定稿后 5 个工作日；新岗位进群当天 飞书多维表格高级权限 权限清单 🔧飞书固化
6 权限新增或收回：提前通知受影响者并说明依据 人事 变更前 1 个工作日 飞书消息/群 变更通知 🔧飞书固化
7 季度盘点：档案缺项、合同签署与到期、权限名单、档案柜上锁检查 人事 每季度首月 10 日前 多维表格 盘点报告 🔧+🤖
8 调阅或对外提供：登记调阅人、用途、范围、审批人、归还时间；对外提供合同须去敏并经综合部负责人批准 人事、综合部负责人 当次办理 飞书审批 调阅记录 🔧飞书固化

5. 交付物与模板

  • 交付物：档案/合同台账、分级与可见范围表、档案目录索引、季度盘点报告、权限审计记录、调阅登记
  • 建议模板/表单：
    • 档案/合同台账字段：工号、姓名、主体、用工类型、入职日、各档案项是否齐全、合同类型、签署日、到期日、保密协议、存放位置（柜号/电子路径）、缺项说明、最近盘点日
    • 档案填报表单：增加“工号+姓名”唯一性校验，防止重复提交
    • 调阅登记字段：调阅人、事由、调阅范围、审批人、调阅日期、归还日期

6. 异常与升级

  • 重复提交 → 表单唯一性校验拦截；已发生的，人事保留最新一条、删除错误记录（1 个工作日内）
  • 盘点发现缺档案 → 2 个工作日内通知员工补交，逾期报直属上级
  • 盘点发现未签合同 → 当天报综合部负责人，按 HR-04 补签
  • 特殊入职（推荐入职、外部驻场、挂靠其他主体）→ 人事向创始人确认身份与用工主体，档案单独存放
  • 发现档案柜未上锁或权限过宽 → 当天整改，报综合部负责人
  • 权限调整引起异议 → 先按分级表执行，综合部负责人协调，仍有争议报 CEO（3 个工作日内）
  • 疑似人事信息泄露 → 当天报 CEO 与法务，按 LEG-31 处置
  • 升级拍板：日常建档、权限配置、调阅与对外提供合同由综合部负责人作为 A 审批；出现以下任一情形时由 CEO 作为 A（升级）拍板——分级标准首次定稿或调整可见岗位、权限争议经综合部负责人协调 3 个工作日仍未解决、疑似人事信息泄露

7. 衡量指标

  • 档案完整率 = 档案项齐全人数 ÷ 在职人数，目标 ≥ 98%
  • 合同签署率 = 已签合同人数 ÷ 在职人数，目标 100%
  • 入职建档时效 = 到岗到档案齐全的工作日数，目标 ≤ 3 个工作日
  • 权限审计偏差 = 季度审计中超出分级范围的权限数，目标 0
  • 档案可查性 = 抽查任一员工档案，10 分钟内说出存放位置的比例，目标 100%

8. 低效诊断

  • 交接环节：档案和合同保管人变更时没有台账，接手后盘点对不上，部分人员缺档案、不确定是否签过合同｜依据：「行政人事对接群」2026-02
  • 收集环节：表单无唯一性校验，重复提交需人工让员工重交并删除错误记录｜依据：「行政人事对接群」2026-02
  • 入职同步环节：推荐入职等特殊人员入职未同步人事，档案与合同按“听命行事”补办｜依据：「行政人事对接群」2026-02
  • 保管环节：档案柜曾发现未上锁，档案位置一度无人能答｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-04
  • 权限环节：新岗位进群前未定分级，权限收回前未通知受影响者，引发争执｜依据：「行政人事对接群」2026-03
  • 标准环节：多次提出“做好信息保密分级”“文档做重要及分级”，仍未形成书面标准｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-06

9. 分支变体

  • 纸质档案：带锁档案柜，钥匙专人保管，借阅登记
  • 电子档案：飞书受限空间与多维表格，按字段分级授权，开启水印
  • 薪酬明细：完整信息只限三位创始人和人事；财务只见应发；行政、总助只见各自工作所需
  • 跃竞主体：人事档案已收回统一管理，按本流程执行
  • 特殊身份人员（外部驻场开发、兼职外包、挂靠其他主体员工）：档案单独存放
  • 对外提供劳动合同（招投标、资质）：去敏、登记、综合部负责人审批

10. 待确认问题

  • 信息分为几级？每级哪些岗位可见？论证会何时召开、由谁召集？
  • 纸质档案保管主责是人事、行政，还是总经办档案管理岗？档案室规划进度如何？
  • 电子档案统一存放在哪个飞书空间？是否需要水印与下载限制？
  • 季度盘点频率是否合适？
  • 对外提供劳动合同的审批人是综合部负责人还是 CEO？
  • 入职材料清单是否以全员档案通知为准（含高中后全部学历证书）？
HR-29员工申诉与劳动争议处理待新建推断100

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨4 × 险5

  • 适用场景：员工对考勤扣薪、绩效、调岗、解除、加班费等提出异议或投诉，或收到劳动监察投诉、劳动仲裁申请时启动
  • 负责人：主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 受理登记 → ② 事实核查与证据固定 → ③ 法务风险评估 → ④ 内部沟通调解 → ⑤ 形成处理决定并书面告知 → ⑥ 仲裁/诉讼应对（如进入）→ ⑦ 结案归档与制度改进
  • 交付结果：书面处理结论或调解协议；进入仲裁的，完整证据目录与答辩材料；争议台账一条
  • 状态依据：已有 HR-20（员工绩效/行为问题访谈与处置）、HR-14（月度考勤核对与扣薪核定）覆盖公司发起的处置与核定环节，本条补齐员工主动申诉与劳动争议的统一受理与应诉（推断）

1. 场景判定

  • 触发条件：员工书面或口头提出对人事决定的异议；收到劳动监察、仲裁委文书；离职员工主张补偿
  • 典型说法：「这个月扣薪我不认可」「我要申请劳动仲裁」「加班费为什么没算」
  • 判断问题：是否涉及劳动关系权利义务（工资、工时、解除、社保、补偿）？是否已有外部机关介入？
  • 不归本流程管：日常绩效/行为问题访谈 → 请走 HR-20；考勤与扣薪的月度核定 → 请走 HR-14（员工对核定结果有异议再进入本流程）；正常离职办理 → 请走 HR-27；对制度、管理或同事行为的一般意见与违规举报 → 请走 GEN-19；非劳动类对外纠纷 → 请走 LEG-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
受理与核查 登记、调取考勤/薪资/审批记录、约谈 R 人事专员（当前：待指定）
风险评估与应诉 判断法律风险、拟定答辩、对接律师 C 法务（当前：待指定）
处理决定 批准调解方案或应诉策略 A 人事负责人（当前：黄莹·部门报送人）
数据支持 提供工资、个税、社保缴纳记录 C 财务（当前：待指定）
部门说明 提供事实经过与沟通记录 C 员工所在部门负责人（当前：待指定）

3. 办之前请准备

  • 员工劳动合同、入职材料、相关制度（员工手册、考勤制度）的签收记录
  • 争议期间的考勤、薪资、审批、绩效记录导出
  • 外部文书原件（如有）及送达日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 受理登记，确认诉求与涉及期间 人事专员 收到后 1 个工作日内 飞书多维表格（争议台账） 台账记录 🔧飞书固化
2 调取并固定证据，访谈部门负责人 人事专员 受理后 3 个工作日内 飞书考勤/审批导出 证据清单 🔧+🤖
3 风险评估，给出处理建议 法务 证据齐后 2 个工作日内 文档 风险评估意见 👤人工判断
4 与员工沟通调解 人事专员+部门负责人 评估后 3 个工作日内 线下面谈 沟通纪要 👤人工判断
5 出具书面处理决定或签署调解协议 人事负责人 调解结束后 2 个工作日内 飞书审批+用印（LEG-09） 处理决定/协议 🔧飞书固化
6 进入仲裁/诉讼的，按文书期限提交答辩与证据 法务 文书规定期限前 3 个工作日 律所协作 答辩材料 👤人工判断
7 结案归档，复盘制度漏洞 人事专员 结案后 5 个工作日内 人事档案 结案记录与改进项 🔧飞书固化

5. 交付物与模板

  • 交付物：争议台账、证据目录、处理决定书/调解协议、结案复盘
  • 建议模板/表单：争议登记表（员工岗位、主体、争议类型、诉求、涉及期间、外部文书期限、状态、结论）

6. 异常与升级

  • 收到仲裁/法院文书 → 当天转法务并登记期限 → 升级人事负责人与 CEO（1 个工作日内）
  • 员工在群内或对外公开发布争议信息 → 法务评估回应口径 → 升级 CEO（当天）

7. 衡量指标

  • 争议内部化解率 = 未进入仲裁即结案数 / 争议总数，目标 ≥ 80%
  • 期限遵守率 = 按外部文书期限完成提交的案件比例，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在仓促应诉、证据缺失、错过答辩期限的风险（推断）

9. 分支变体

  • 不同用工主体的员工，以其劳动合同签约主体作为当事方；实习/劳务人员争议按合同性质单独评估

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 是否有常年法律顾问或合作律所承接劳动案件？
  • 调解方案的审批权限是否需要按金额分级（具体额度由部门确定）？
HR-30工伤与员工意外事件处理待新建推断60

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗4 × 跨3 × 险5

  • 适用场景：员工在工作时间、工作场所或因公外出（含出差、上门交付、展会搭建）期间受伤或突发疾病时启动
  • 负责人：主责——人事专员（当前：待指定）；协同——行政（当前：待指定）、员工所在部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 现场救助与报告 → ② 事故信息登记 → ③ 判断是否申请工伤认定 → ④ 法定期限内提交申请 → ⑤ 商保理赔协同 → ⑥ 停工留薪与复岗安排 → ⑦ 隐患整改与归档
  • 交付结果：事故报告、工伤认定申请回执或不申请的书面说明、复岗记录、隐患整改记录
  • 状态依据：已有 HR-22（体检与团体商业保险）覆盖商保投保环节，本条补齐工伤认定申报与员工意外事件处置；交付外勤、展会搭建、机房作业存在实际风险（推断）

1. 场景判定

  • 触发条件：员工报告受伤/突发疾病；外勤、上门部署、搭建现场发生意外；交通事故涉及因公出行
  • 典型说法：「搬机器时把腰扭了」「出差路上出了车祸」「同事在工位晕倒了」
  • 判断问题：是否发生在工作时间、工作场所或因工作原因？是否需要立即送医？
  • 不归本流程管：体检与商业保险日常理赔指引 → 请走 HR-22；设施损坏维修 → 请走 ADM-08；火灾等场所安全事件 → 请走 ADM-35；线下活动的安全预案与现场应急 → 请走 ECO-30（人员受伤后转入本流程）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
现场处置 救助、送医、报告 R 员工所在部门负责人（当前：待指定）
在场同事 部门负责人不在场时先行救助与报告 R 全体员工
工伤申报 登记、收集材料、提交认定申请 R 人事专员（当前：待指定）
现场证据与整改 拍照留存现场、排查隐患 C 行政（当前：待指定）
决策与审批 确认申报、停工留薪安排 A 人事负责人（当前：黄莹·部门报送人）

3. 办之前请准备

  • 员工身份信息、劳动合同、社保缴纳主体
  • 事故时间、地点、经过、目击人，现场照片
  • 就诊病历、诊断证明、费用票据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 现场救助，必要时拨打急救，报告人事 部门负责人/在场同事 发生后 1 小时内报告 电话/飞书 口头报告 👤人工判断
2 填写事故登记表，留存现场证据 人事专员+行政 发生后 1 个工作日内 飞书表单 事故登记表 🔧飞书固化
3 判断是否属于工伤情形并决定申报 人事负责人 登记后 2 个工作日内 文档 申报决定 👤人工判断
4 向社保所在地提交工伤认定申请 人事专员 事故发生之日起 30 日内（法定） 当地人社系统 申请回执 👤人工判断
5 同步商业保险报案与理赔材料 人事专员 报案按保单约定时限 保险机构 理赔受理记录 🔧飞书固化
6 安排停工留薪、复岗或调整工作 人事专员+部门负责人 医嘱期满前 3 个工作日 飞书审批 复岗记录 👤人工判断
7 隐患整改、通报与归档 行政 事故后 5 个工作日内 飞书文档 整改记录 🔧飞书固化

5. 交付物与模板

  • 交付物：事故登记表、工伤认定申请回执、理赔记录、复岗记录、隐患整改单
  • 建议模板/表单：事故登记表（时间、地点、经过、伤情、目击人、是否因公、送医情况、社保主体、处理状态）

6. 异常与升级

  • 重伤或群体性事件 → 立即报人事负责人与 CEO（1 小时内）
  • 员工社保缴纳主体与实际用工主体不一致 → 法务评估申报主体（1 个工作日内）

7. 衡量指标

  • 工伤申报及时率 = 30 日内提交的需申报案件比例，目标 100%
  • 同类隐患复发数：整改后 6 个月内同类事故次数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在错过工伤认定申请期限、由公司承担全部工伤待遇、现场证据缺失的风险（推断）

9. 分支变体

  • 外地出差或客户现场发生的，同时通知客户现场对接人并留存客户方记录；实习生与劳务人员不适用工伤保险，按商业保险或合同约定处理

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 各主体是否都已为员工缴纳工伤保险？实习生是否有单独意外险？
  • 外勤、搭建、机房作业是否需要额外的安全作业规范？
HR-31劳动合同到期续签与终止待新建推断32

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨2 × 险4

  • 适用场景：员工劳动合同、实习协议或劳务协议即将到期，需要决定续签、变更或终止时启动
  • 负责人：主责——人事专员（当前：待指定）；协同——员工所在部门负责人（当前：待指定）、法务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 到期前提醒 → ② 部门续签意见 → ③ 审批决定 → ④ 与员工沟通 → ⑤ 签署续签合同或出具终止通知 → ⑥ 异动同步 → ⑦ 归档
  • 交付结果：续签的劳动合同或书面终止通知；合同到期台账更新
  • 状态依据：已有 HR-04（用工主体判定与劳动合同签署）覆盖首次签署环节，本条补齐合同到期提醒与续签/终止决策（推断）

1. 场景判定

  • 触发条件：合同台账显示 60 日内到期；实习生毕业转正或协议到期；劳务协议到期
  • 典型说法：「他的合同下个月到期了要不要续」「实习协议到期了能不能转正式」
  • 判断问题：是否属于连续第二次固定期限合同到期（员工可能有权要求无固定期限）？是否处于医疗期、孕期等不得终止情形？
  • 不归本流程管：首次签订与用工主体判定 → 请走 HR-04；试用期转正 → 请走 HR-08；主动离职办理 → 请走 HR-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账与提醒 维护到期台账、发提醒、准备合同 R 人事专员（当前：待指定）
续签意见 评估员工是否续签及条件 C 员工所在部门负责人（当前：待指定）
特殊情形评估 判断能否终止、是否需支付补偿 C 法务（当前：待指定）
决定 批准续签/终止 A 人事负责人（当前：黄莹·部门报送人）

3. 办之前请准备

  • 合同到期台账（主体、合同类型、起止日期、签订次数）
  • 员工近期绩效与考勤情况
  • 合同模板最新版本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 系统按到期日自动提醒人事与部门负责人 人事专员 到期前 60 日 飞书多维表格自动化 提醒消息 🔧+🤖
2 部门负责人提交续签意见 部门负责人 提醒后 5 个工作日内 飞书审批 续签意见 🔧飞书固化
3 特殊情形法律评估 法务 意见提交后 3 个工作日内 文档 评估意见 👤人工判断
4 审批续签/终止决定 人事负责人 到期前 30 日 飞书审批 审批结论 🔧飞书固化
5 与员工沟通并签署续签合同或送达终止通知 人事专员 到期前 15 日 电子签/纸质 合同或通知 🔧飞书固化
6 同步财务、行政及账号相关方 人事专员 签署或送达后 1 个工作日内 飞书群 异动通知（HR-26） 🔧飞书固化
7 归档并更新台账 人事专员 签署后 3 个工作日内 人事档案 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：续签合同、终止通知书、到期台账
  • 建议模板/表单：续签意见表（员工、主体、到期日、已签次数、续签建议、续签期限、岗位/薪资是否变化、理由）

6. 异常与升级

  • 合同已到期未续签仍在用工 → 立即补签并报人事负责人（当天）
  • 员工拒绝续签或对终止有异议 → 转 HR-29

7. 衡量指标

  • 到期合同按期处理率 = 到期前完成续签或终止的比例，目标 100%
  • 超期未签人数：每月末统计，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在合同过期未续导致未签书面合同双倍工资、违法终止的风险（推断）

9. 分支变体

  • 实习生毕业转正式员工时需重新签订劳动合同并办理社保增员（HR-16）；劳务/顾问协议到期同步财务停止结算

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 现有合同期限一般为几年？是否已有完整的合同到期台账？
  • 是否统一使用电子签完成续签？
HR-32非研发岗位周期绩效考核与结果应用待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：每季度（或半年）对综合、市场、生态、运营等非研发岗位开展绩效考核，并将结果用于调薪、奖金、晋升与改进时启动
  • 负责人：主责——人事专员（当前：待指定）；协同——各部门负责人（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 期初目标设定 → ② 期中跟进 → ③ 期末自评 → ④ 上级评价与校准 → ⑤ 结果面谈 → ⑥ 结果应用（调薪/奖金/改进计划）→ ⑦ 归档
  • 交付结果：每位员工的考核表与等级、校准后的部门结果汇总、结果应用清单
  • 状态依据：已有 HR-19（研发绩效评价）、SAL-34（销售业绩考核与提成）覆盖研发与销售岗位，本条补齐非研发岗位的周期绩效考核与结果应用（推断）

1. 场景判定

  • 触发条件：考核周期开始或结束；新员工转正后纳入考核周期
  • 典型说法：「市场这边怎么评绩效」「季度奖金按什么定」
  • 判断问题：员工是否属于研发或销售岗位（已有专门考核）？本周期是否已设定目标？
  • 不归本流程管：研发绩效 → 请走 HR-19；销售提成 → 请走 SAL-34；年终总结与 1v1 → 请走 HR-21；行为问题处置 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
组织与汇总 发起周期、收集表单、汇总结果 R 人事专员（当前：待指定）
目标与评价 设定目标、评价打分、面谈 R 各部门负责人（当前：待指定）
校准与审批 跨部门校准等级分布 A 人事负责人（当前：黄莹·部门报送人）
奖金核算 按结果计算奖金并入工资 C 财务（当前：待指定）
被考核员工 确认目标、自评并附依据 R 被考核员工

3. 办之前请准备

  • 部门本周期重点工作与 CEO 分解目标（CEO-01）
  • 考核表模板与等级定义
  • 周报/日报记录（CEO-12）作为评价依据

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起周期，下发目标表 人事专员 周期开始后 5 个工作日内 飞书绩效/多维表格 目标表 🔧飞书固化
2 部门负责人与员工确认目标 部门负责人 周期开始后 10 个工作日内 飞书绩效 已确认目标 👤人工判断
3 员工自评并附依据 员工 周期结束后 3 个工作日内 飞书绩效 自评 🔧+🤖
4 上级评价打分 部门负责人 自评后 3 个工作日内 飞书绩效 评价结果 👤人工判断
5 跨部门校准会 人事负责人 评价后 3 个工作日内 会议 校准后等级 👤人工判断
6 结果面谈 部门负责人 校准后 5 个工作日内 1v1 面谈记录 👤人工判断
7 结果应用并通知财务 人事专员 面谈结束后 3 个工作日内 飞书审批 应用清单 🔧飞书固化

5. 交付物与模板

  • 交付物：考核表、校准结果、面谈记录、结果应用清单
  • 建议模板/表单：考核表（目标项、权重、衡量标准、完成情况、自评、上级评分、等级、改进建议）

6. 异常与升级

  • 部门逾期未提交评价 → 人事催办，超 3 个工作日报人事负责人
  • 员工对结果有异议 → 先由部门负责人复核，仍有异议转 HR-29

7. 衡量指标

  • 按期完成率 = 按时完成考核的员工比例，目标 ≥ 95%
  • 目标设定覆盖率 = 期初有确认目标的员工比例，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在非研发岗位评价无依据、调薪与奖金口径不一致的风险（推断）

9. 分支变体

  • 子公司主体员工由其负责人评价，结果报集团人事校准；实习生仅做观察期评价（HR-08）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 考核周期是季度还是半年？是否设定等级比例？
  • 是否使用飞书绩效模块？
HR-33竞业限制启动、豁免与补偿支付待新建推断45

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗3 × 跨3 × 险5

  • 适用场景：已签竞业限制协议的员工离职时，决定是否启动竞业限制、如何支付补偿、离职后如何跟踪履约时启动
  • 负责人：主责——人事专员（当前：待指定）；协同——法务（当前：待指定）、财务（当前：待指定）、原部门负责人（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 离职时识别竞业协议 → ② 评估是否启动 → ③ 书面通知员工 → ④ 按月支付补偿 → ⑤ 定期确认履约 → ⑥ 违约处置或期满结束
  • 交付结果：竞业启动/不启动书面通知、补偿支付记录、履约确认记录
  • 状态依据：已有 HR-04（劳动合同/协议签署，含竞业协议）覆盖签署环节，本条补齐离职时竞业启动评估、补偿支付与履约跟踪（推断）

1. 场景判定

  • 触发条件：签有竞业协议的员工提出离职或被解除；离职员工疑似加入竞争对手
  • 典型说法：「他签过竞业，要不要启动」「听说他去了竞品公司」
  • 判断问题：员工是否签有竞业协议？是否属于核心技术、管理或掌握商业秘密人员？
  • 不归本流程管：协议签署 → 请走 HR-04；离职交接 → 请走 HR-27；代码与机密外泄事件 → 请走 LEG-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
识别与通知 查协议、发起评估、送达通知 R 人事专员（当前：待指定）
必要性评估 评估岗位接触的秘密与竞争风险 C 原部门负责人（当前：待指定）
法律把关 通知文本、违约处置 C 法务（当前：待指定）
决定 批准启动或不启动 A 人事负责人（当前：黄莹·部门报送人）
补偿支付 按月支付并留存凭证 R 财务（当前：待指定）

3. 办之前请准备

  • 竞业协议原件、约定期限与补偿标准
  • 员工岗位与接触的核心资产说明
  • 竞争对手清单（由业务部门维护）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 离职审批时自动提示是否签有竞业协议 人事专员 离职申请当日 飞书审批字段 提示 🔧飞书固化
2 部门负责人与法务评估是否启动 部门负责人+法务 离职申请后 5 个工作日内 文档 评估意见 👤人工判断
3 审批并在最后工作日前书面通知员工 人事负责人/人事专员 最后工作日前 电子签/书面 启动或不启动通知 🔧飞书固化
4 启动的，按月支付补偿 财务 每月固定发薪日 网银 支付记录 👤人工判断
5 定期请员工提供就业情况说明 人事专员 每季度 邮件/电子签 履约确认 🤖自动化
6 发现违约线索，固定证据并评估追责 法务 发现后 5 个工作日内 律所协作 处置方案 👤人工判断
7 期满或解除后停止支付并归档 人事专员 期满当月 人事档案 结束记录 🔧飞书固化

5. 交付物与模板

  • 交付物：竞业通知书、竞业台账、补偿支付记录、履约确认书
  • 建议模板/表单：竞业台账（员工、主体、离职日、竞业期限、启动状态、支付周期、最近履约确认日、异常）

6. 异常与升级

  • 补偿漏付 → 当月补付并报人事负责人（连续漏付可能导致协议失效）
  • 在职期间决定豁免 → 法务评估豁免的补偿后果后再通知（3 个工作日内）

7. 衡量指标

  • 补偿按期支付率 = 按月按时支付次数 / 应支付次数，目标 100%
  • 离职识别率 = 离职时完成竞业评估的已签协议员工比例，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在补偿漏付导致协议失效、核心人员流向竞品无法约束的风险（推断）

9. 分支变体

  • 不同主体签订的协议由对应主体支付补偿；外包/顾问人员一般不适用竞业，按保密协议处理（LEG-05）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 目前哪些岗位签有竞业协议？竞争对手清单由谁维护？
  • 是否默认离职时不启动、仅对核心人员启动？

X-CS 售后 / 客户成功

报送人：待定 · 归属待定 · 29 条 · 已有 0 / 待优化 10 / 待新建 19
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-CS-01售后服务体系、分工与值班排班产品交付或上线后，需要明确谁对客户负责、谁值班首响、谁兜底研发问题，以及制定和发布日常/节假日值班排班时启动主责——售后统筹（产品负责人兼）（当前：杨萌·推断待确认）；协同——研发负责人（排研发 oncall，当前：王皓南·推断待确认）、产品值班（当前：陈震、黄飞鹏·推断待确认）、研发 oncall（当前：宋祺睿、吴世豪等·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 定售后分工与 SLA → ② 出月度产品/研发值班表 → ③ 发布并告知销售与客户 → ④ 机器人每日提醒当日值班 → ⑤ 值班首响与分流（转 X-CS-05） → ⑥ 节假日排班提前发布 → ⑦ 月度复盘修订成文的《售后服务制度》（分工、呼叫规则、SLA、升级路径）、飞书多维表格值班表（含节假日）、每日值班提醒、售后月报待优化240
X-CS-02客户试用/正式账号开通、封停溯源与席位扩容潜在客户申请试用账号或加额度、需为客户在正式环境开号、发现来源不明的客户账号需溯源或封停、已交付客户申请增加席位时启动主责——客户账号管理员（后端/运维）（当前：宋祺睿·推断待确认）；协同——申请人（销售/产品，当前：杜中瑞、杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（特批，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 提交开通/扩容/封停申请 → ② 审核客户来源与资源 → ③ 执行开通或调整 → ④ 登记台账 → ⑤ 通知申请人与客户 → ⑥ 月度对账与到期提醒 → ⑦ 异常账号溯源封停生效的账号/席位，并在客户账号台账中留痕（客户、来源、开通人、额度、席位、并发上限、到期日）待新建144
X-CS-03客户额度充值到账、分配与补发客户购买额度需要到账、新用户默认额度发错需补发、客户反馈"额度已耗尽"或统计不符、为挽留/推广/项目交付赠送额度时启动主责——额度操作员（NewAPI/后端）（当前：宋祺睿·推断待确认）；协同——销售总监/客户经理（当前：吴琪·推断待确认）、业务对接（当前：王满·推断待确认）、充值发起人（当前：王皓南·推断待确认）、操作备岗（当前：张康·推断待确认）、后端研发（当前：杨云峰、陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交充值/补发/赠送/扣减申请 → ② 财务确认到账或审批赠送 → ③ 确认产品线与单位口径 → ④ 在 NewAPI/后台执行并截图 → ⑤ 校验 token 启用与分配 → ⑥ 登记台账 → ⑦ 通知客户并确认 → ⑧ 月度对账额度准确到账并按组织/个人分配，台账留痕（来源、口径、审批、执行截图、客户确认）待新建180
X-CS-04客户私有化实例登记与在线监控告警客户（含渠道代发）LeapCore 实例首次注册上线、渠道把机器分给终端客户、实例需改名，以及实例掉线或服务异常需要主动告警时启动主责——交付部署工程师（当前：游家豪·推断待确认）；协同——后端研发（cloud 改名与监控，当前：宋祺睿·推断待确认）、研发负责人（命名规则，当前：王皓南·推断待确认）、产品负责人（渠道系统对接，当前：杨萌·推断待确认）、研发排查（当前：吴世豪、杨云峰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发货/部署前分配实例名 → ② cloud 注册并填客户/渠道字段 → ③ 写入实例台账 → ④ 渠道分机后回填终端客户 → ⑤ 监控在线与服务状态 → ⑥ 异常告警并主动联系客户 → ⑦ 月度核对台账每台客户实例在台账和 cloud 中都能查到客户、渠道、编号、版本、联系人；掉线/服务异常 10 分钟内推送飞书告警待新建144
X-CS-05客户问题受理、分流与工单流转客户、内测/种子用户、销售或内部使用者通过反馈群、客户群、产品内"报告问题"或右下角反馈提出问题，需要首响、补全信息、分类、转工单并回告客户时启动主责——当日产品值班（当前：陈震、黄飞鹏·推断待确认）；协同——售后统筹（当前：杨萌·推断待确认）、研发 oncall/一线技术答疑（当前：岳阳、宋祺睿、杨云峰·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、客户对接（当前：吴琪、王满、闫登辉、杨朋伟·推断待确认）、Badcase 收集（当前：黄霆瑄·推断待确认）、FAQ 维护（当前：许君、韩诗琪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一入口收单 → ② 1 小时内首响 → ③ 按模板补全信息 → ④ 分级分类 → ⑤ 咨询类按 FAQ 答复，Bug 转研发工单 → ⑥ 跟进修复与发版 → ⑦ 回告客户并确认 → ⑧ 关单与 FAQ 沉淀每个客户问题都有工单编号、分级、分类、负责人、状态和对客回复；同类问题沉淀为 FAQ待优化400
X-CS-06客户现场问题分级排查与日志/诊断包收集一线无法判断的客户故障（死机、模型无响应、Agent 中断、容器创建失败、断电后异常、VPN/网络异常、定时任务异常），需要按顺序收集日志/诊断包、远程排查、定位根因并修复（含批量修复）时启动主责——当日研发 oncall（当前：吴世豪、杨云峰、岳阳·推断待确认）；协同——产品值班/对客转接（当前：黄飞鹏、陈震·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、服务端与发版（当前：宋祺睿·推断待确认）、NewAPI 查询（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、远程访问与日志归集（当前：郭逸非·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 一线按排查顺序自查 → ② 导出客户端诊断包 → ③ 研发初判 → ④ 必要时取服务端日志或远程上机 → ⑤ 给止血方案 → ⑥ 出书面结论与影响面 → ⑦ 修复或批量修复 → ⑧ 回访并关单每个现场故障有书面结论（现象-根因-验证-修复-影响面），附诊断包和工单号；批量问题有经评审的修复脚本和受影响客户清单待优化320
X-CS-07客户端安装、更新与模型服务连接问题一线支持客户安装/更新失败、被安全软件拦截、签名校验失败、系统不兼容、连错服务器、网页提示模型服务不可用时，由一线按手册远程指导解决，解决不了再升级主责——一线售后支持（当前：韩诗琪·推断待确认）；协同——客户端研发（当前：岳阳、葛家和·推断待确认）、服务端/运维（当前：宋祺睿·推断待确认）、IT 网络（当前：杨明学·推断待确认）、产品值班（当前：张东郅·推断待确认）；兜底——售后统筹（当前：杨萌·推断待确认）① 核对系统要求与版本 → ② 按排障手册判类（安装/更新/连接/模型服务） → ③ 远程指导客户可操作的步骤 → ④ 收集截图、时间、版本、环境 → ⑤ 升级研发/运维 → ⑥ 回复客户并补充 FAQ客户恢复使用；或 1 小时内带完整信息升级；《系统要求+安装排障》手册和话术库持续更新待优化72
X-CS-08账号登录失败与密码找回用户或企业管理员登录失败、忘记密码、重置短信收不到、报错提示模糊、客户实际连到错误实例，需要核验身份后重置或纠正连接地址时启动主责——账号密码重置管理员（后端）（当前：宋祺睿·推断待确认）；协同——产品值班（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、销售（重置申请发起，当前：陈名赞·推断待确认）、测试（当前：张东郅·推断待确认）、CTO（审批规则，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）① 一线引导自查（提示、实例地址、账号是否注册） → ② 普通用户找本企业管理员重置 → ③ 管理员忘记时提交重置申请 → ④ 三方核验 → ⑤ 重置为随机密码并私密交付 → ⑥ 客户首登改密 → ⑦ 留档客户恢复登录；超管密码重置有审批和操作留档；初始/重置密码不在群里明文传递待新建96
X-CS-09计费余额异常核查、对账修复与退款客户或用户反馈充值未到账、扣费异常（失败仍扣费、扣得过快）、余额为 0 或为负、充值/消费/剩余三者对不上、Token 消耗异常激增，或额度充错对象时启动。主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、服务端研发（当前：邓乾、杨云峰、岳阳·推断待确认）、网关上游维护（当前：杨明学·推断待确认）、运维（当前：宋祺睿·推断待确认）、一线客户对接人（当前：杜中瑞、杨朋伟、游家豪、闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 分类定级 → ③ 查订单/账单/网关日志 → ④ 定位根因 → ⑤ 出修复或补偿方案并审批 → ⑥ 备份后执行修复/退款 → ⑦ 客户验收与答复 → ⑧ 复盘并沉淀 FAQ结案的计费异常工单（含根因、影响范围、修复/退款记录、客户确认），P0/P1 事件的复盘文档，更新后的计费 FAQ。待新建400
X-CS-10C 端用户售后入口、退款与客诉处理C 端用户（LeapAll、OPC 商城卡密、消费券等）申请或催退款、反馈卡密过期、查不到订单、找不到售后联系方式，或客诉直接打到公司人员电话时启动。主责——C 端客服/运营专员（当前：陈震·推断待确认）；协同——社区运营负责人（当前：陈梦琪·推断待确认）、电话客服（当前：胡橙橙·推断待确认）、平台开发（当前：葛家和、吴世豪、邓乾·推断待确认）、测试（当前：张东郅·推断待确认）、财务专员（当前：待指定）、外部退款审批合作方；兜底——运营负责人（当前：李凯·推断待确认）① 统一入口受理 → ② 查单核实 → ③ 判断退款条件 → ④ 提交合作方/财务审批 → ⑤ 跟踪进度并定期回告 → ⑥ 到账确认与答复 → ⑦ 结案归档与话术更新结案的售后工单（退款到账或给出明确不予退款理由），用户确认记录，持续更新的客服话术库。待新建225
X-CS-11定制客户特殊配置台账与售后范围界定客户使用了魔改版本、自带模型、自接 NewAPI、本地算力路由或临时脚本等非标配置，出现问题需要判断是否属于标品售后、给出诊断报告与对客口径时启动；新增任何非标配置时也需登记。主责——Leap 研发/技术负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、排查研发（当前：宋祺睿、柯逸飞·推断待确认）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 非标配置特批与登记 → ② 问题来时查台账 → ③ 判定标品/非标 → ④ 定响应优先级 → ⑤ 出诊断报告 → ⑥ 销售按统一口径对客回复 → ⑦ 收费/修复决定 → ⑧ 更新台账定制客户特殊配置台账（客户、定制点、负责人、版本、是否收费）；每次问题对应的诊断报告与对客回复记录。待新建96
X-CS-12硬件设备售后、返修与上门维保已交付的一体机/工作站/服务器出现故障（硬盘、掉线、网口、断电、IP 变化、无法访问），需要远程判断、上门处理、返修或换机时启动；销售一体机时界定售后责任与运维成本也按本流程的责任矩阵执行。主责——硬件运维负责人（当前：杨明学·推断待确认）；协同——现场运维/交付工程师（当前：游家豪·推断待确认）、软件运维（当前：宋祺睿、杨云峰·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、产品与交付统筹（当前：杨萌·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 受理登记 → ② 远程初判（硬件/软件/网络/客户操作）→ ③ 远程指导处理 → ④ 派运维上门 → ⑤ 返修判断与备机替换 → ⑥ 返厂寄送与跟踪 → ⑦ 修复验收与回寄 → ⑧ 费用与责任界定、结案结案的硬件售后工单（故障原因、处理方式、返厂物流、费用归属、客户确认），更新后的设备台账与客户须知。待新建400
X-CS-13客户反馈转缺陷/需求与修复验收闭环反馈群、客户群、试点客户、内部试用或测试中发现的问题与 badcase，需要判定是 Bug、需求、Badcase 还是定制，进入 Issue/需求池，修复后验收并回告反馈人时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——反馈值班提单人/测试（当前：黄霆瑄、张东郅、潘浩伟·推断待确认）、研发（当前：岳阳、柯逸飞、陈晖·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、一线对接人（销售/FDE/交付，当前：杜中瑞、王满、吴琪、季学森·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、运维（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一收集 → ② 值班人每日汇总提单 → ③ 判定 Bug/需求/Badcase/定制 → ④ 新包验证与去重 → ⑤ 分级指派或进需求池 → ⑥ 修复并指派验收人 → ⑦ 验收 → ⑧ 回告反馈人并回写状态 → ⑨ 周期复盘每条反馈都有去向（Issue 编号、需求池条目或"不处理"理由），修复项有验收记录并已回告客户；按月输出反馈分析报告。待优化180
X-CS-14客户新需求承诺前可行性确认与变更响应已交付客户或合作客户提出新功能、活动规则、重度使用要求，对接人准备答应或客户已在等待答复时启动；对客承诺任何非现有功能前必须先走本流程。主责——客户项目负责人（当前：徐莉〔跃竞线〕·推断待确认；Leap 线当前：待指定）；协同——一线对接人（当前：陈雁、张康·推断待确认）、技术可行性评估人（当前：丁震宇·推断待确认）、产品负责人（当前：待指定）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 一线不当场承诺，登记需求 → ② 判断是否 Bug / 合同范围内 → ③ 技术可行性与工作量评估 → ④ 定答复方案（做/折中/加价/拒绝）→ ⑤ 按模板对客答复 → ⑥ 进入需求池或变更报价 → ⑦ 记录承诺并跟踪兑现每条客户新需求的可行性确认单（结论、答复口径、是否收费、负责人），以及对客的书面答复记录。待新建144
X-CS-15版本更新/停机客户通知与更新日志服务端或客户端版本上线、停机升级、额度/数据迁移等会影响客户使用时，需要提前通知销售、售后和客户群避开更新窗口，并在帮助中心发布更新日志时启动。主责——产品负责人（发版统筹）（当前：杨萌·推断待确认）；协同——产品经理（更新日志）（当前：陈震·推断待确认）、产品经理（客户群通知）（当前：黄飞鹏·推断待确认）、研发技术负责人（停机窗口）（当前：王皓南·推断待确认）、运维发版（当前：宋祺睿·推断待确认）、帮助中心部署（当前：葛家和·推断待确认）、销售（当前：杜中瑞·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 确定发版/停机窗口 → ② 起草通知与更新日志 → ③ 内部先通知销售/售后/市场 → ④ 按时限通知客户群 → ⑤ 时间变动即时补发 → ⑥ 执行更新 → ⑦ 发布完成通知与更新日志 → ⑧ 更新后 1 小时观察客户反馈已送达所有受影响客户群的更新/停机通知（含时间窗、影响、注意事项），帮助中心更新日志，通知送达清单。待优化160
X-CS-16服务迁移中的客户账号与余额迁移测试服转正式服、旧网关（如旧 NewAPI）下线切换到新网关、服务器迁移或服务停用时，需要迁移客户账号、数据、余额并统一对外口径、提前通知客户时启动。主责——发起迁移的技术负责人（当前：王皓南·推断待确认）；协同——对外口径收口（当前：韩诗琪·推断待确认）、产品负责人（当前：杨萌·推断待确认）、额度迁移管理员（当前：邓乾〔LeapAll〕、柯逸飞〔LeapCore/网关〕·推断待确认）、运维（当前：宋祺睿·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、测试（当前：张东郅·推断待确认）、定制软件负责人（当前：望政韬·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 依赖与客户盘点 → ② 定迁移方案与继承规则 → ③ 定对外口径与 FAQ → ④ 提前通知客户（含截止日）→ ⑤ 迁移账号/余额并核对总额 → ⑥ 灰度关停旧服务 → ⑦ 观察期 → ⑧ 销毁旧资源并登记迁移完成且余额核对一致的客户清单、已送达的客户通知与 FAQ、旧资源下线与销毁记录、新的系统负责人边界。待新建200
X-CS-17对外沟通口径、FAQ 话术与对外信息脱敏客户或销售/渠道问“为什么慢/贵/失败”“选哪个模型”“支不支持某环境/某功能”、需要解释数据异常，或要把内部截图/通知转给客户时，先查 FAQ 口径库，查不到再按本流程定口径，对外内容先脱敏主责——FAQ/口径库维护人（产品，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售/渠道负责人（当前：闫登辉·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 查 FAQ 口径库 → ② 未命中则提口径申请 → ③ 研发核对技术事实 → ④ 口径负责人定稿 → ⑤ 对外回复（含脱敏检查）→ ⑥ 入库并通知销售/渠道 → ⑦ 每次发版复核一条已入库、标注适用范围与生效日期的 FAQ 口径；一次符合口径、已脱敏的对外回复待新建160
X-CS-18帮助中心、使用手册与交付注意事项维护客户/员工索要使用手册，客户或销售反馈帮助中心内容缺失、过时，交付现场或售后反复遇到同类使用问题（登录、网口、IP、飞连）时，更新帮助中心与交付注意事项手册并发布主责——帮助中心内容负责人（产品，当前：杨萌·推断待确认）；协同——交付部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、销售（当前：杜中瑞·推断待确认）、测试负责人（当前：张东郅·推断待确认）、运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 收集问题与内容需求 → ② 分类（帮助中心/注意事项手册/运营推文/转研发）→ ③ 撰写或修订 → ④ 技术核对 → ⑤ 发布并更新入口 → ⑥ 通知销售与交付 → ⑦ 每迭代复核已更新的帮助中心页面与交付注意事项手册（含版本号与更新日期），并在产品内、交付群公布入口待优化135
X-CS-19重点客户回访与使用推进重点客户交付上线后，按固定节点回访；或发现客户关键使用人（尤其决策人）没用起来、商务推进被卡时，安排客访推动使用，并把反馈分类传回产品主责——客户经理（当前：按客户分配，吴琪、杨朋伟·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）① 交付后建回访计划 → ② 看后台使用数据 → ③ 按节点回访/客访 → ④ 填回访记录 → ⑤ 反馈分类并转产品 → ⑥ 制定推进动作 → ⑦ 回告客户更新 → ⑧ 月度复盘每个重点客户的回访记录（多维表格）、反馈处理去向、使用推进动作及结果待优化135
X-CS-20客户成功案例与效果文档制作项目出现效果好的客户使用场景，或销售/品牌需要展示材料时，按统一模板整理成功案例与效果文档，经真实性核查、客户授权和脱敏后对外使用主责——项目研发/FDE（当前：张康·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户经理（当前：待指定）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提出案例需求 → ② 采集真实输入输出 → ③ 按模板撰写 → ④ 真实性核查 → ⑤ 客户授权与脱敏 → ⑥ 定稿入库 → ⑦ 分发销售/品牌一份标注“内部可用/对外可用”的案例文档（场景、输入、输出、效果数据、客户反馈、授权状态），入案例库待新建120
X-CS-21VIP 客户“一键增强”人工代写服务白名单内的特殊/VIP 客户在产品内点击“一键增强”后，由内部人员用 Claude Code 人工优化可研报告并回写到客户侧，在约定时限内交付主责——增强写作执行人（后端/全栈研发，当前：徐鑫宇·推断待确认）；协同——前端研发（当前：侯怡辰·推断待确认）、前端负责人（当前：季学森·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户经理（当前：待指定）；兜底——Leap/鼎慧研发负责人（当前：王皓南·推断待确认）① 白名单申请与开通 → ② 客户点击触发通知 → ③ 认领 → ④ 人工增强写作 → ⑤ 质量审核 → ⑥ 回写数据库 → ⑦ 通知客户 → ⑧ 登记交付时长经质量审核的增强版可研报告已更新到客户账号，并在工单中记录认领、完成时间待新建200
X-CS-22俱乐部/商户入驻与会员端配置对接新俱乐部/商户确定入驻跃玩、星域或会员端时，收集入驻材料、开通商户、配置会员等级与权益、导入客户名单、完成操作教学，并持续接收配置类咨询主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、销售/商务（当前：飞书用户8994FW·推断待确认）、获客/客户教学（当前：刘安达·推断待确认）、产品经理（当前：段涵·推断待确认）、网页端前端（当前：陈真炎·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 签约后建入驻工单 → ② 发材料清单与信息收集表 → ③ 材料审核与商户开通 → ④ 会员端配置 → ⑤ 客户名单批量导入 → ⑥ 操作教学 → ⑦ 上线确认 → ⑧ 首月跟进与问题入台账已开通并完成会员体系配置的俱乐部/商户账号，客户名单导入完成，教学记录与入驻台账状态为“已上线”待优化135
X-CS-23俱乐部客户反馈受理与转研发排查俱乐部、陪玩、老板反馈使用问题、入账/分账异常、余额支付或提现失败、积分/成长值未同步时，统一受理、收齐要素、按客户等级与资金影响分级，转研发排查，修复后回告客户主责——客户反馈受理（运营，当前：陈雁·推断待确认）；协同——商户入驻专员（当前：宫经喜·推断待确认）、产品经理（当前：段涵·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠、蒋兴武、魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 受理登记（必填订单号/UID 等）→ ② AI 助手自查 → ③ 分级分派 → ④ 研发排查与复现 → ⑤ 修复/补正（涉资金人工确认）→ ⑥ 回告客户 → ⑦ 根因归类入排查手册一条要素完整、有优先级、有处理人和根因的问题记录；客户收到处理结果；重复问题沉淀为排查手册或 FAQ待新建300
X-CS-24俱乐部账务类工单处理俱乐部提出主户更换、实名更换、剩余资金迁移、资金调账、罚款强制划扣或账单疑问时，通过统一工单受理，涉资金操作经审批后由研发执行并留痕主责——俱乐部工单受理（客服/运营，当前：宫经喜·推断待确认）；协同——后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 俱乐部提交工单 → ② 材料核验 → ③ 审批（按类型分级）→ ④ 研发执行 → ⑤ 复核 → ⑥ 通知俱乐部 → ⑦ 归档留痕一张完成审批、执行、复核的工单，附执行前后数据截图和通知记录待新建225
X-CS-25订单投诉受理与售后缓冲规则跃玩平台顾客对订单或陪玩服务不满发起投诉，或自助订单陪玩提交服务凭证后进入 48 小时售后缓冲期时启动主责——平台客服/售后主管（当前：待指定）；协同——俱乐部接待、平台超管（当前：待指定）、产品经理（当前：樊九辰、段涵·推断待确认）、后端投诉域开发（当前：张楠、王子明·推断待确认）、财务专员（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 顾客发起投诉/售后申请 → ② 接待首响与首次处理 → ③ 顾客确认或二次申诉 → ④ 管理员升级复核 → ⑤ 超管终局裁定 → ⑥ 退款/罚款/补偿分级审批执行 → ⑦ 结案留痕；无异议订单缓冲期满自动完单结算有完整处理轮次、事实快照与审计留痕的投诉单；已执行的退款/罚款/补偿凭证；按规则自动完单结算的自助订单待优化225
X-CS-26客户续约续费与维保到期管理客户的额度包、订阅、席位、软件授权或硬件维保即将到期时，提前提醒、评估续约意向并推动续签，避免服务中断与收入流失主责——客户成功专员（当前：待指定）；协同——客户对接销售、财务专员、交付负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 到期台账维护 → ② 到期前 60 天提醒 → ③ 使用情况与健康度分析 → ④ 续约沟通 → ⑤ 报价与合同 → ⑥ 续费到账开通 → ⑦ 未续约处置续约合同或续费到账记录；未续约客户的流失原因记录待新建72
X-CS-27B 端客户投诉升级处理与满意度回访企业/政府/渠道客户对产品质量、交付延期、服务态度或计费结果正式表达不满、要求赔偿或威胁解约时，按等级受理、升级、给出处理方案并回访主责——客户成功专员（当前：待指定）；协同——客户对接销售、交付负责人、研发值班、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 投诉登记 → ② 分级（一般/严重/重大）→ ③ 指定处理人与时限 → ④ 调查原因 → ⑤ 出处理方案并内部审批 → ⑥ 对客答复 → ⑦ 满意度回访 → ⑧ 月度复盘投诉处理记录、对客书面答复、回访结果、整改项待新建96
X-CS-28售后访问客户环境与数据的授权留痕售后、交付、研发为排查问题需远程登录客户私有化实例、查看客户业务数据/对话记录/文件、导出日志或诊断包时，先取得客户授权、限定范围，并在操作后留痕主责——售后负责人（当前：待指定）；协同——研发值班、交付工程师、客户对接销售、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 判定是否需访问客户数据 → ② 向客户申请书面授权（范围、时限）→ ③ 内部登记 → ④ 最小范围访问 → ⑤ 操作记录 → ⑥ 关闭临时通道与删除导出数据 → ⑦ 告知客户结束客户授权记录、访问登记与操作记录、通道关闭与数据删除确认待新建200
X-CS-29客户服务终止、账号注销与数据返还销毁客户合同到期不续、解约、试用结束未转化，或客户/用户申请注销账号时，按约定停止服务、返还或导出客户数据、销毁我方留存数据并出具确认主责——售后负责人（当前：待指定）；协同——客户对接销售、研发值班、交付负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 终止触发确认 → ② 结清费用 → ③ 通知客户数据导出窗口 → ④ 协助导出/返还 → ⑤ 停服与账号/席位注销 → ⑥ 销毁我方留存数据与备份 → ⑦ 出具确认函 → ⑧ 台账关闭数据返还/导出记录、账号与实例注销记录、数据销毁确认函、台账状态关闭待新建60
X-CS-01售后服务体系、分工与值班排班待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：产品交付或上线后，需要明确谁对客户负责、谁值班首响、谁兜底研发问题，以及制定和发布日常/节假日值班排班时启动
  • 负责人：主责——售后统筹（产品负责人兼）（当前：杨萌·推断待确认）；协同——研发负责人（排研发 oncall，当前：王皓南·推断待确认）、产品值班（当前：陈震、黄飞鹏·推断待确认）、研发 oncall（当前：宋祺睿、吴世豪等·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 定售后分工与 SLA → ② 出月度产品/研发值班表 → ③ 发布并告知销售与客户 → ④ 机器人每日提醒当日值班 → ⑤ 值班首响与分流（转 X-CS-05） → ⑥ 节假日排班提前发布 → ⑦ 月度复盘修订
  • 交付结果：成文的《售后服务制度》（分工、呼叫规则、SLA、升级路径）、飞书多维表格值班表（含节假日）、每日值班提醒、售后月报
  • 状态依据：2026-09 已宣布产品+研发双轮岗，有机器人每日提醒和轮岗表；但研发轮岗表滞后、值班人靠追问确认，售后专职岗长期空缺由产研兼任，节假日排班以图片发布，2026-04 起多次提出"售后没有对应制度"

1. 场景判定

  • 触发条件：新客户上线/交付完成需指定售后承接；每月排下月值班；放假通知发布后排节假日值班；值班人员变动；新客户群或渠道接入
  • 典型说法：「现在开始实行产品研发双轮岗制度」「研发排一个产品排一个，产品解决不了转研发」「你轮岗表出来了吗，今天谁」「售后似乎没有对应的制度」「假期产品使用售后排班表」
  • 判断问题：这件事是在定"谁负责、谁值班、怎么排班、怎么呼叫"吗？如果是在处理某个具体客户问题，不走本流程
  • 不归本流程管：具体客户问题受理与分流 → 请走 X-CS-05；现场故障排查与日志 → 请走 X-CS-06；交付期现场问题 → 请走 X-DLV-34；保修与运维边界口径 → 请走 X-DLV-30；合同范围外需求 → 请走 SAL-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
售后统筹 制定售后分工与 SLA、排产品值班、发布节假日排班、月度复盘 A/R 售后统筹（产品负责人兼）（当前：杨萌·推断待确认）
研发负责人 排研发 oncall 表，定"谁可以呼叫研发 oncall"的规则 R 研发负责人（当前：王皓南·推断待确认）
产品值班 当日反馈群/客户群首响，承接使用与分配类问题 R 产品经理（当前：陈震、黄飞鹏·推断待确认）
研发 oncall 承接排查类问题，只接受客户与产品值班呼叫 R 研发工程师（当前：宋祺睿、吴世豪等·推断待确认）
销售负责人 向客户公布售后入口与排班，推动客户群迁移到企业微信公共号，界定商务类售后 C 销售负责人（当前：李鹏为·推断待确认）
FDE 解决方案型客户的现场与方案支持 C FDE（当前：李凯·推断待确认）
CTO 制度审批、售后招聘与资源拍板、重大事件兜底 C CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已交付/已上线客户清单（客户、产品线、客户群、对接销售），取自 X-DLV-31 台账
  • 可值班的产品与研发人员名单、请假与出差安排
  • 公司放假通知（节假日排班用）
  • 公共企业微信售后号的持有人与登录设备
  • 上月值班数据：首响超时次数、转研发次数、高频问题

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定/修订《售后服务制度》：分工（产品值班→研发 oncall→模块负责人）、SLA（普通 1 小时首响、紧急立即响应）、可呼叫研发 oncall 的角色、对客口径负责人 售后统筹 首版 10 个工作日内；此后每季度修订 飞书文档 售后服务制度 👤人工判断
2 出下月研发 oncall 表和产品值班表，写入同一张多维表格，每天配一名备班 研发负责人、售后统筹 每月 25 日前 飞书多维表格 下月值班表 🔧飞书固化
3 值班表发布到研发群、反馈群、市场销售通知群，说明呼叫方式 售后统筹 定稿当日 飞书群公告 群公告 🔧飞书固化
4 机器人每个工作日 9:30 在反馈群 @当日产品值班和研发 oncall，附 SLA 机器人（维护：售后统筹） 每个工作日 9:30 飞书机器人 当日值班提醒 🤖自动化
5 值班人按 X-CS-05 首响与分流；产品值班解决不了转研发 oncall，研发 oncall 再转模块负责人 产品值班、研发 oncall 普通 1 小时内首响；紧急立即 反馈群/工单 首响记录 👤人工判断
6 出节假日值班表（多维表格+群公告，不用图片），销售同步转告客户 售后统筹、研发负责人 放假通知发布后 2 个工作日内，且不晚于节前 3 个工作日 飞书多维表格 节假日值班表 🔧飞书固化
7 换班/请假：值班人自行找替班并在表中改人，机器人按新表提醒 值班人 至少提前 1 个工作日 飞书多维表格 换班记录 🔧飞书固化
8 月度复盘：首响超时、转研发量、高频问题，调整分工、SLA 和 FAQ 售后统筹 每月第 1 周 多维表格仪表盘 售后月报 🔧+🤖

5. 交付物与模板

  • 交付物：《售后服务制度》、月度值班表、节假日值班表、售后月报
  • 值班表字段：日期、产品值班、研发 oncall、备班、是否节假日、覆盖产品线（LeapCore/LeapAll/字字可研）、换班原因
  • 售后服务制度要素：服务范围、角色分工、呼叫规则、各级 SLA、升级路径、对客口径负责人、客户入口（企业微信公共号/客户群）、节假日规则

6. 异常与升级

  • 当日无人值班或值班表未出 → 上一位值班人顺延，售后统筹 1 小时内补排 → 升级研发负责人
  • 值班人超 1 小时未首响 → 机器人二次提醒并 @备班 → 再过 1 小时仍无响应，升级售后统筹
  • 多个客户同时不可用 → 立即拉研发 oncall 和研发负责人 → 30 分钟内升级 CTO
  • 客户在个人微信群、值班人进不去 → 销售当天转述，并在 1 周内把客户迁移到企业微信公共号群 → 售后统筹跟进
  • 商务、收费、合同类问题 → 转销售负责人，值班人不答复

7. 衡量指标

  • 值班表准时率 = 按期发布次数 / 应发布次数，目标 100%
  • 首响达标率 = 1 小时内首次回复的反馈数 / 总反馈数，目标 ≥ 90%
  • 研发 oncall 越级呼叫占比 = 非产品值班、非客户直接呼叫研发的次数 / 研发 oncall 总呼叫数，目标 ≤ 10%
  • "今天谁值班"类追问次数，目标每月 0 次

8. 低效诊断

  • 现象：软件售出后没有成文售后制度和专职岗位，售后由商务或产研临时兜底，影响回款｜依据：「【跃迁】合伙人会议」2026-04
  • 现象：已上线客户的使用问题默认找某个后端研发，客户对接人外出时无人兜底；回不回、谁来回复客户无规则｜依据：「鼎慧产研决策部」2026-06
  • 现象：反馈处理先后由不同人兼任，研发被迫当客服，"人员不够"｜依据：「Leap产研决策部」2026-08
  • 现象：双轮岗宣布后研发轮岗表滞后一天，值班人靠追问确认；值班范围争议成"所有人永久 oncall"｜依据：「Leap产研测」2026-09、「Leap产研决策部」2026-09
  • 现象：没有公司售后号，临时用平板或个人小号登录企业微信；放假通知晚发影响排班｜依据：「Leap产研决策部」2026-09
  • 现象：节假日排班以图片发布，不可检索、不能自动提醒｜依据：「Leap市场销售通知群」2026-09

9. 分支变体

  • 售后专职岗未到位：产品+研发双轮岗兜底（当前模式）；到位后改为售后专员一线、产研二线
  • 节假日：长假按"出 bug 才响应"轻值班，研发 oncall 远程待命；普通咨询节后处理，并提前在客户群告知
  • 产品线：LeapCore 私有部署客户、LeapAll 个人用户、字字可研客户的客户群不同，值班表需标明覆盖范围
  • 重点解决方案型客户：可配"解决方案型产品 + FDE + 售后"三角色小组（目前为提议）

10. 待确认问题

  • 售后统筹是否长期由产品负责人兼任？是否招售后专员，计划何时到岗？
  • 普通 1 小时首响、紧急立即响应的 SLA 是否适用于所有客户和节假日？
  • 研发 oncall 是否全员参与？"只有客户和产品值班才能呼叫研发 oncall"是否写入制度？
  • 公共企业微信售后号由谁持有、在哪台设备登录？
  • "To G/To B 售后由商务负责"与产研轮岗如何分界？
  • 超出保修范围的远程服务是否对客户收费？
X-CS-02客户试用/正式账号开通、封停溯源与席位扩容待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：潜在客户申请试用账号或加额度、需为客户在正式环境开号、发现来源不明的客户账号需溯源或封停、已交付客户申请增加席位时启动
  • 负责人：主责——客户账号管理员（后端/运维）（当前：宋祺睿·推断待确认）；协同——申请人（销售/产品，当前：杜中瑞、杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（特批，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 提交开通/扩容/封停申请 → ② 审核客户来源与资源 → ③ 执行开通或调整 → ④ 登记台账 → ⑤ 通知申请人与客户 → ⑥ 月度对账与到期提醒 → ⑦ 异常账号溯源封停
  • 交付结果：生效的账号/席位，并在客户账号台账中留痕（客户、来源、开通人、额度、席位、并发上限、到期日）
  • 状态依据：开号、加额度、扩席位全靠群里零散请求，无申请单、无台账；出现过测试数据混入正式环境被客户看到、陌生账号需翻聊天记录溯源、席位与并发混淆导致资源不足

1. 场景判定

  • 触发条件：销售/产品提出试用或开号；试用账号需加额度；后台发现来源不明或异地异常使用的账号；客户申请增加席位
  • 典型说法：「这个号帮忙加点额度吧」「你给他们开个号用用」「我想知道这个客户哪来的」「客户申请席位扩充到 25 个」「席位是席位，并发是并发」
  • 判断问题：是否涉及客户侧账号或席位的生效、变更、停用？
  • 不归本流程管：付费额度充值与补发 → 请走 X-CS-03；登录失败与忘记密码 → 请走 X-CS-08；交付期客户组织初始化开通 → 请走 X-DLV-15；扩容涉及硬件或合同变更 → 请走 X-DLV-33；内部员工后台账号 → 请走 X-SEC-03；演示账号 → 请走 SAL-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提交申请，写明客户、用途、期限、席位；向客户告知结果 R 销售（当前：杜中瑞·推断待确认）、产品负责人（当前：杨萌·推断待确认）
客户账号管理员 审核、执行开通/扩容/封停、维护台账、月度对账 A/R 后端/运维（当前：宋祺睿·推断待确认）
后端研发 评估席位扩容的内存与并发，修改实例配置 R 后端研发（当前：杨云峰·推断待确认）
交付部署工程师 私有部署客户硬件确认、服务重启窗口协调 C 交付部署工程师（当前：游家豪·推断待确认）
研发负责人 封停决定，测试/正式环境隔离规则 C 研发负责人（当前：王皓南·推断待确认）
CTO 超标准试用额度与资源特批 C CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户名称、对接销售、客户来源渠道
  • 使用人手机号（只填入申请单，不在群里转发）
  • 用途（试用/正式）、额度、有效期
  • 扩容：当前席位、目标席位、机型与内存、客户预期并发
  • 封停：异常账号 ID、异常现象、是否已联系客户

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交「客户账号/席位申请单」（类型：试用/正式/加额度/扩容/封停） 申请人 需求出现当天 飞书表单 申请单 🔧飞书固化
2 核对客户来源、是否已有账号、额度是否超试用标准；超标准转 CTO 特批 客户账号管理员 1 个工作日内 飞书多维表格 审核结论 👤人工判断
3 开通：在白名单网络登录管理后台，在正式环境创建账号，设额度与到期日；不用测试数据 客户账号管理员 审核通过后 1 个工作日内 管理后台 生效账号 🤖+👤
4 扩容：按单席位内存估算口径核对硬件；够则改组织最大用户数配置，在约定低峰窗口重启 user 服务；不够转 X-DLV-33 后端研发、交付部署工程师 申请后 2 个工作日内 部署脚本 扩容记录 🤖+👤
5 登记台账：客户、来源、开通人、账号、额度、席位、并发上限、到期日 客户账号管理员 执行当天 飞书多维表格 台账记录 🔧飞书固化
6 通知申请人，由申请人告知客户；扩容须讲清"席位≠并发"及并发上限 客户账号管理员→申请人 执行当天 飞书消息 结果通知 🔧飞书固化
7 月度对账：后台账号与台账比对，列出无主账号；到期前 3 天提醒申请人续期或停用 客户账号管理员 每月第 1 周 脚本+多维表格 对账清单 🤖自动化
8 封停：查台账确认来源与对接销售，销售 1 个工作日内联系客户；确认无授权后封停并通知客户 客户账号管理员（决定：研发负责人） 发现后 2 个工作日内 管理后台 封停记录 👤人工判断

5. 交付物与模板

  • 交付物：生效账号/席位、客户账号台账、封停记录、扩容记录
  • 申请单字段：申请类型、客户名称、来源渠道、对接销售、使用人手机号、产品线、额度、席位、有效期、用途说明、是否特批
  • 台账字段：账号 ID、客户、来源、开通人、开通日期、环境（正式/测试）、额度、席位、并发上限、到期日、状态（有效/到期/封停）

6. 异常与升级

  • 执行人不在白名单网络、后台访问受限 → 回到白名单网络执行，不临时放开白名单 → 网络问题转 X-SEC-25
  • 发现测试数据出现在正式环境 → 当天清理并查来源 → 1 个工作日内报研发负责人
  • 扩容后服务异常或资源不足 → 回滚到原席位配置 → 2 小时内升级交付与研发负责人
  • 客户要求当天生效 → 销售说明原因，管理员评估可行性 → 不可行时升级 CTO
  • 来源不明账号正在使用 → 不直接封停，先由销售联系；2 个工作日无人认领再封停

7. 衡量指标

  • 开通周期 = 申请提交到账号生效的工作日数，目标 ≤ 1 天
  • 台账覆盖率 = 台账内客户账号数 / 后台客户账号数，目标 100%
  • 无主账号数 = 月度对账发现的无来源账号，目标 0
  • 扩容事故数 = 扩容后因资源不足导致服务异常的次数，目标 0

8. 低效诊断

  • 现象：手机号和开号需求在群里转发，开通后无记录，谁有账号查不到｜依据：「鼎慧产研决策部」2026-02
  • 现象：测试数据混入正式环境，客户给上级演示时被看到｜依据：「鼎慧产研决策部」2026-02
  • 现象：管理后台限白名单访问，执行人不在白名单网络时开通卡住｜依据：「鼎慧产研决策部」2026-02
  • 现象：发现陌生客户账号要翻聊天记录找开通人，先封停后溯源，且未通知客户｜依据：「鼎慧产研决策部」2026-03
  • 现象：席位与并发概念混用；扩容按"当天要"临时操作，部署人员不熟悉后续调整，资源不足导致服务异常｜依据：「某客户项目群」2026-07、「某客户项目群」2026-08、「某客户项目群」2026-09

9. 分支变体

  • 试用账号：默认额度与有效期上限（待定），到期自动提醒
  • 正式账号：需关联合同/订单号
  • 内部员工、演示账号：分别走 X-SEC-03、SAL-13，不进客户台账
  • 私有部署席位扩容：改实例配置并重启服务；SaaS 席位扩容：后台直接调整
  • 多机部署的大客户：扩容需确认容器在多台机器上均匀分配

10. 待确认问题

  • 试用账号默认额度、有效期和审批人是谁？
  • 席位扩容是否必须有合同/订单变更？收费由谁确认？
  • "单席位约 1.2G 内存"的估算口径能否作为正式标准？
  • 封停决定权归研发负责人还是销售负责人？封停前是否必须通知客户？
  • 客户账号管理员是否需要备岗？
X-CS-03客户额度充值到账、分配与补发待新建180

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险5

  • 适用场景：客户购买额度需要到账、新用户默认额度发错需补发、客户反馈"额度已耗尽"或统计不符、为挽留/推广/项目交付赠送额度时启动
  • 负责人：主责——额度操作员（NewAPI/后端）（当前：宋祺睿·推断待确认）；协同——销售总监/客户经理（当前：吴琪·推断待确认）、业务对接（当前：王满·推断待确认）、充值发起人（当前：王皓南·推断待确认）、操作备岗（当前：张康·推断待确认）、后端研发（当前：杨云峰、陈锦杰·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交充值/补发/赠送/扣减申请 → ② 财务确认到账或审批赠送 → ③ 确认产品线与单位口径 → ④ 在 NewAPI/后台执行并截图 → ⑤ 校验 token 启用与分配 → ⑥ 登记台账 → ⑦ 通知客户并确认 → ⑧ 月度对账
  • 交付结果：额度准确到账并按组织/个人分配，台账留痕（来源、口径、审批、执行截图、客户确认）
  • 状态依据：充值、补发、赠送都在群里口头发起；单位与金额口径需反复确认；字字可研与 LeapCore 两套额度系统需手工配置；赠送由管理层口头同意，无审批、无台账

1. 场景判定

  • 触发条件：收款到账需充值；客户反馈额度耗尽、显示异常或统计不符；新用户额度发放错误；销售或管理层提出赠送
  • 典型说法：「新用户应该是 100M 词元的，怎么批量补啊」「组织充值」「额度相应减」「显示额度已耗尽」「送点额度挽留一下」
  • 判断问题：是否涉及客户可用额度的增加、扣减或分配？
  • 不归本流程管：账号开通与席位 → 请走 X-CS-02；赠送额度的商务报备 → 请走 SAL-17；API/额度类分销订单 → 请走 SAL-26；交付期首次组织开通与充值 → 请走 X-DLV-15；套餐与计费规则设计 → 请走 X-PRD-23；内部员工 API 额度 → 请走 RND-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提交申请，附订单或到账凭证；执行后通知客户并确认可用 R 销售总监/客户经理（当前：吴琪·推断待确认）、充值发起人（当前：王皓南·推断待确认）
财务 确认付费充值已到账，参与月度对账 C 财务（当前：待指定）
赠送审批人 审批赠送与补发（原因、额度上限） A（升级） CTO（当前：丁震宇·推断待确认）
额度操作员 执行充值/扣减/补发、截图留证、登记台账 A/R NewAPI/后端（当前：宋祺睿·推断待确认）；备岗（当前：张康·推断待确认）
后端研发 排查统计、缓存、token 启用规则，必要时 hotfix R 后端研发（当前：杨云峰、陈锦杰·推断待确认）
业务对接 发现异常、与客户确认问题已解决 C 业务对接（当前：王满·推断待确认）

3. 办之前请准备

  • 客户名称、组织 ID、产品线（字字可研/LeapCore）
  • 单位口径（按金额还是按词元）、充值/扣减数量
  • 合同/订单号、到账凭证（付费）或赠送原因（赠送）
  • 分配方式：组织共享、个人、指定管理员
  • 异常类：截图、发生时间、涉及账号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交「额度变更申请」（付费充值/补发/赠送/扣减） 申请人 到账或需求出现当天 飞书审批 申请单 🔧飞书固化
2 付费：财务确认到账；赠送/补发：审批人审批，写明原因与上限 财务/赠送审批人 1 个工作日内 飞书审批 审批结论 🔧+👤
3 确认产品线与单位口径（两套额度系统分离），有疑问一次问清 额度操作员 审批通过后 2 小时内 飞书消息 口径确认 👤人工判断
4 在 NewAPI/后台执行，截图留证；批量补发用脚本，先抽 1～2 个账号验证再全量 额度操作员 审批通过后 1 个工作日内 NewAPI/脚本 执行截图 🤖自动化
5 校验：额度为 0 时被自动禁用的 token 已手动恢复；组织/个人分配符合申请 额度操作员 执行当天 NewAPI 校验结果 🔧+🤖
6 登记台账并附截图 额度操作员 执行当天 飞书多维表格 台账记录 🔧飞书固化
7 通知申请人，申请人告知客户并确认可用 申请人 执行当天 客户群 客户确认 🔧飞书固化
8 显示耗尽/统计不符：后端排查缓存或统计逻辑，必要时 hotfix，修复后与客户确认 后端研发、业务对接 1 个工作日内给结论 工单 排查结论 👤人工判断
9 月度对账：台账 vs 系统额度 vs 收款 额度操作员、财务 每月第 5 个工作日前 脚本+多维表格 对账表 🤖自动化

5. 交付物与模板

  • 交付物：到账的额度、额度台账、执行截图、月度对账表
  • 申请单字段：类型、客户、组织 ID、产品线、单位、数量、分配方式、合同/订单号、到账凭证、赠送原因、审批人
  • 台账字段：日期、客户、产品线、类型、数量、单位、审批单号、操作人、截图、客户确认时间、备注

6. 异常与升级

  • 单位/金额口径不明 → 暂停执行，申请人当天补充 → 超 1 个工作日未补充，退回申请
  • 充值后客户仍不可用 → 先查 token 是否仍被禁用 → 2 小时内未解决转后端研发
  • 批量发错 → 立即停止发放并评估影响范围，补发或扣回须重新审批 → 当天报 CTO
  • 无审批的赠送请求 → 额度操作员拒绝执行，退回申请人走步骤 1
  • 客户质疑消耗过快（计费争议） → 转 X-CS-05 建单，研发查计费明细
  • A（升级）说明：付费充值、扣减等常规额度变更由额度操作员负最终责任；凡属赠送、补发，或批量发错需补发/扣回的，拍板权升级到 CTO（赠送审批人），未经其审批不得执行

7. 衡量指标

  • 到账时效 = 到账确认到客户可用的时长，目标 ≤ 1 个工作日
  • 台账一致率 = 月度对账无差异的客户数 / 总客户数，目标 100%
  • 无审批赠送次数，目标 0
  • 额度发放差错次数（发错、配错对象），目标每季度 0

8. 低效诊断

  • 现象：新用户默认额度口径发错，需要手工批量补发｜依据：「字字可研项目群」2026-05
  • 现象：两套额度系统互不相通，交付时手工配置，额度被全部配给管理员｜依据：「字字可研项目群」2026-05、「LeapCore（archived）」2026-05
  • 现象：充值单位与金额口径需二次确认，"额度这个事解决了吗"反复追问｜依据：「LeapCore（archived）」2026-05
  • 现象：额度为 0 时 token 自动禁用，充值后不自动启用，客户"充了也用不了"｜依据：「LeapCore（archived）」2026-05
  • 现象：组织额度充足却显示耗尽，统计合计与总额度不符｜依据：「字字可研项目群」2026-06、「LeapCore（archived）」2026-06
  • 现象：挽留/推广赠送凭口头同意，无记录｜依据：「字字可研项目群」2026-08

9. 分支变体

  • 字字可研额度 vs LeapCore 额度：分别在各自系统操作，台账按产品线分列
  • 组织额度（全员共享） vs 个人额度：管理员分配功能上线前由操作员代配
  • 赠送类型：新用户默认赠送 / 客户挽留赠送 / 推广赠送 / 项目交付赠送，均需审批
  • 赠送与付费额度的消耗顺序：以合同约定为准

10. 待确认问题

  • 赠送与补发的审批人、单次额度上限是多少？
  • 财务是否每次参与到账确认，还是只做月度对账？
  • 两套额度系统是否计划合并？
  • "充值后 token 不自动启用"是否已排期修复？
  • 管理员分配额度功能何时上线？
X-CS-04客户私有化实例登记与在线监控告警待新建144

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：客户（含渠道代发）LeapCore 实例首次注册上线、渠道把机器分给终端客户、实例需改名，以及实例掉线或服务异常需要主动告警时启动
  • 负责人：主责——交付部署工程师（当前：游家豪·推断待确认）；协同——后端研发（cloud 改名与监控，当前：宋祺睿·推断待确认）、研发负责人（命名规则，当前：王皓南·推断待确认）、产品负责人（渠道系统对接，当前：杨萌·推断待确认）、研发排查（当前：吴世豪、杨云峰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发货/部署前分配实例名 → ② cloud 注册并填客户/渠道字段 → ③ 写入实例台账 → ④ 渠道分机后回填终端客户 → ⑤ 监控在线与服务状态 → ⑥ 异常告警并主动联系客户 → ⑦ 月度核对台账
  • 交付结果：每台客户实例在台账和 cloud 中都能查到客户、渠道、编号、版本、联系人；掉线/服务异常 10 分钟内推送飞书告警
  • 状态依据：只有口头命名规则；渠道批量拿货后没有分机台账，故障时凭名字猜客户；监控与告警尚未建设，机器掉线要等客户反馈

1. 场景判定

  • 触发条件：新实例注册上线；渠道把机器分给终端客户；客户更新后登不上需定位是哪台机器；实例掉线或服务异常
  • 典型说法：「群名叫…完全不知道是哪家」「实例名字尽量按交付用户来，不行就渠道+编号」「做个飞书机器人，某客户的机器掉线啦」「我们应该知情，可以第一时间帮助用户」
  • 判断问题：问题是否属于"不知道这台机器属于谁"或"不知道这台机器现在是否在线"？
  • 不归本流程管：已交付设备与客户信息归档 → 请走 X-DLV-31；客户网络与远程接入配置 → 请走 X-DLV-16；故障排查本身 → 请走 X-CS-06；版本升级 → 请走 X-DLV-32；渠道报备与订单 → 请走 SAL-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付部署工程师 分配实例名、cloud 注册、维护实例台账、月度核对 A/R 交付部署工程师（当前：游家豪·推断待确认）
后端研发 cloud 改名与渠道字段、服务状态检查、告警机器人 R 后端研发（当前：宋祺睿·推断待确认）
研发负责人 定命名规则与告警阈值 C 研发负责人（当前：王皓南·推断待确认）
产品负责人 推动渠道通过渠道系统提单并回填终端客户，cloud 展示需求 C 产品负责人（当前：杨萌·推断待确认）
值班/研发排查 认领告警、判断原因、转故障排查 R 研发（当前：吴世豪、杨云峰·推断待确认）
对接销售/渠道 提供终端客户信息，接到告警后联系客户 C 销售（当前：待指定）

3. 办之前请准备

  • 发货单或订单号、终端客户名称、渠道名称
  • 机器序列号、机型、软件版本
  • 部署地址与网络方式（VPN 节点、内网/公网）
  • 客户联系人、对接销售
  • 是否有计划停机（节假日关机、搬迁）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按规则分配实例名：已知终端客户用"客户名-编号"；未知时用"渠道名-编号" 交付部署工程师 发货/部署前 飞书多维表格 实例名 👤人工判断
2 在 cloud 注册，填写客户、渠道、编号字段（字段上线后设为必填） 交付部署工程师 部署当天 LeapCore cloud 注册记录 🔧飞书固化
3 写入实例台账 交付部署工程师 部署当天 飞书多维表格 台账记录 🔧飞书固化
4 渠道分机：渠道通过渠道系统提单回填终端客户，交付部署工程师同步在 cloud 改名 对接销售、交付部署工程师 分机后 2 个工作日内 渠道系统/cloud 更新后的台账 🔧飞书固化
5 后台定时检查 VPN 在线和核心服务健康；工作时间离线超 30 分钟即触发 后端研发 持续运行 监控脚本 状态记录 🤖自动化
6 飞书机器人推送告警到售后群，附实例名、客户、渠道、最后在线时间、对接销售 机器人 触发后 10 分钟内 飞书机器人 告警卡片 🤖自动化
7 值班认领告警，先排除计划停机/断电，必要时由销售联系客户；确认故障转 X-CS-06 值班/研发排查 工作时间 30 分钟内认领 飞书 处理记录 👤人工判断
8 月度核对 cloud 实例清单与台账，补齐差异 交付部署工程师 每月第 1 周 脚本+多维表格 差异清单 🤖自动化

5. 交付物与模板

  • 交付物：实例台账、cloud 实例记录、告警记录、月度差异清单
  • 台账字段：实例 ID、实例名、终端客户、渠道、编号、机型、序列号、版本、部署日期、地址/网络方式、客户联系人、对接销售、监控状态、计划停机标记

6. 异常与升级

  • 实例名与客户对不上 → 查 VPN 上线记录和发货单 → 1 个工作日内找销售/渠道确认
  • 告警误报（客户节假日关机） → 在台账标"计划停机"，静默期间不告警
  • 同一客户名有多种写法 → 以台账为准，在 cloud 统一改名
  • 渠道不回填终端客户 → 升级渠道负责人（5 个工作日内）
  • 上报信息不足以判断服务状态 → 提需求增加上报字段 → 请走 RND-04

7. 衡量指标

  • 台账覆盖率 = 台账内实例数 / cloud 注册实例数，目标 100%
  • 实例定位时长 = 报障到确认是哪家客户哪台机器的时间，目标 ≤ 10 分钟
  • 主动发现率 = 告警早于客户反馈的掉线故障数 / 全部掉线故障数，目标 ≥ 80%
  • 告警认领时长，目标工作时间 ≤ 30 分钟

8. 低效诊断

  • 现象：渠道批量拿货后实例以渠道名命名，分给终端客户后无记录，故障时凭群名猜客户｜依据：「Leap产研测」2026-10
  • 现象：登记名与口头名写法不一致，检索不到｜依据：「Leap产研测」2026-10
  • 现象：排查只能靠 VPN 在线状态和上线记录推测是否关机｜依据：「Leap产研测」2026-10
  • 现象：后台不检查服务状态、没有告警，掉线要等客户反馈；设备上报信息少｜依据：「某客户项目群」2026-07

9. 分支变体

  • 直销客户：部署前即知终端客户，直接用"客户名-编号"
  • 渠道客户：先用"渠道名-编号"，分机后改名并回填终端客户
  • FDE 培训机：用"FDE-班级-编号"，可设为不告警
  • 客户自备设备：同样注册登记，监控能力视客户网络而定

10. 待确认问题

  • 主责是交付部署工程师还是售后统筹？
  • 命名规则是否定稿？是否允许中文名？
  • cloud 改名与渠道字段何时上线？
  • 告警阈值 30 分钟是否合适？非工作时间是否告警、发给谁？
  • 渠道系统能否强制渠道回填终端客户？
X-CS-05客户问题受理、分流与工单流转待优化400

状态：待优化｜证据：有证据（卡片 24 张 / 会话 12 个）｜优先级：频5 × 耗4 × 跨5 × 险4

  • 适用场景：客户、内测/种子用户、销售或内部使用者通过反馈群、客户群、产品内"报告问题"或右下角反馈提出问题，需要首响、补全信息、分类、转工单并回告客户时启动
  • 负责人：主责——当日产品值班（当前：陈震、黄飞鹏·推断待确认）；协同——售后统筹（当前：杨萌·推断待确认）、研发 oncall/一线技术答疑（当前：岳阳、宋祺睿、杨云峰·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、客户对接（当前：吴琪、王满、闫登辉、杨朋伟·推断待确认）、Badcase 收集（当前：黄霆瑄·推断待确认）、FAQ 维护（当前：许君、韩诗琪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 统一入口收单 → ② 1 小时内首响 → ③ 按模板补全信息 → ④ 分级分类 → ⑤ 咨询类按 FAQ 答复，Bug 转研发工单 → ⑥ 跟进修复与发版 → ⑦ 回告客户并确认 → ⑧ 关单与 FAQ 沉淀
  • 交付结果：每个客户问题都有工单编号、分级、分类、负责人、状态和对客回复；同类问题沉淀为 FAQ
  • 状态依据：2026-07 已发布《Leap 反馈渠道及提报规范》，反馈群有机器人卡片和 AI triage，2026-09 起双轮岗值班；但入口仍多头（反馈群、订单群、客户微信群、私聊），信息不全反复追问，一线答疑集中在少数研发，缺分级 SLA 和回告闭环

1. 场景判定

  • 触发条件：反馈群或客户群出现报错、无法使用、功能疑问；产品内反馈卡片推送；销售或合作方转述客户问题
  • 典型说法：「麻烦看一下这个问题」「这个怎么说，让他们退出重进试试吗」「一句话传好几手」「别在这个群说了，换内部售后群说」「第一步先别乱发，第二步发的时候发齐上下文」「你们别把自己搞成售后了」
  • 判断问题：这是某个客户/用户遇到的具体问题吗？一线能否在 1 小时内答复？不能则分类后转研发
  • 不归本流程管：需要日志深挖的现场故障 → 请走 X-CS-06；安装、更新、连接问题 → 请走 X-CS-07；登录与密码 → 请走 X-CS-08；账号与席位 → 请走 X-CS-02；额度 → 请走 X-CS-03；缺陷分级与修复排期 → 请走 RND-03；需求回流产研 → 请走 X-PRD-07；Badcase → 请走 X-PRD-08；合同外定制 → 请走 SAL-25；交付期现场问题 → 请走 X-DLV-34；培训学员反馈 → 请走 X-FDE-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈人/客户对接 按模板上报（客户、版本、现象、完整截图/录屏、时间）；修复后回告客户 R 客户对接/销售（当前：吴琪、王满、闫登辉、杨朋伟·推断待确认）
产品值班 首响、补信息、分级分类、咨询类答复、建单派单、关单 A/R 产品经理（当前：陈震、黄飞鹏·推断待确认）
研发 oncall Bug 排查，给结论（缺陷/客户操作/配置）和预计修复版本 R 研发（当前：岳阳、宋祺睿、杨云峰·推断待确认）
测试 复现、提缺陷单、验证修复 R 测试（当前：张东郅、李国庆·推断待确认）
售后统筹 对外统一口径、分级争议裁定、重大客诉跟进 C 售后统筹（当前：杨萌·推断待确认）
Badcase 收集 归集 AI 效果类问题 C 测试/评测（当前：黄霆瑄·推断待确认）
FAQ 维护 高频问题整理入 FAQ 与机器人 C 生态市场/销售运营（当前：许君、韩诗琪·推断待确认）
CTO 重大客诉与 P0 升级 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户/企业名（内部使用写"内部"）、产品与客户端版本号、模型档位
  • 现象描述、发生时间、复现步骤
  • 完整客户端截图或录屏（不要局部截图）
  • 网络环境（公司网/客户内网/外网/VPN）
  • 日志、诊断包或 traceid（如已有）
  • 影响范围（几人、是否阻断使用）和客户期望时间
  • 请求最少包含字段：客户/企业简称（内部写"内部"）、产品与客户端版本号、现象一句话 + 发生时间、完整截图或录屏、影响范围（几人/是否阻断）、期望时限、反馈人岗位；缺任一项由产品值班退回补齐，不进入分级

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通用问题发 Leap 反馈群或用产品内"报告问题"；客户专属问题由客户对接人从客户售后群转到反馈群并标客户名；不在研发群和私聊处理 反馈人/客户对接 发现当天 飞书群/产品内反馈 反馈帖（Leap 反馈群帖子或产品内反馈记录，带客户名） 🔧飞书固化
2 机器人识别新帖，缺字段时自动回复补充清单，生成工单草稿 机器人 实时 飞书机器人+多维表格 工单草稿（客户问题工单多维表格，含工单号） 🤖自动化
3 认领并首响 产品值班 普通 1 小时内；P0 立即 反馈群 首响回复（原帖回复，写工单号 + 预计答复时间；超时→售后统筹） 👤人工判断
4 分级（P0 多客户或核心功能不可用；P1 单客户阻断；P2 有绕过办法；P3 咨询/建议）和分类（咨询/账号/Bug/需求/Badcase/商务） 产品值班 首响后 1 小时内 飞书多维表格 工单分级与分类字段（多维表格） 🤖+👤
5 咨询或已知问题：按 FAQ 答复（重启客户端、检查更新、切换模型等）后关单 产品值班 分类后 2 小时内 FAQ/机器人 答复（原帖回复 + 工单关单记录） 🤖自动化
6 Bug：测试复现并提缺陷单，@研发 oncall；研发给结论和预计版本 测试、研发 oncall P0 30 分钟响应、4 小时止血；P1 当天结论；P2 3 个工作日内 Gitea issues 缺陷单（Gitea issues，关联工单号）+ 研发结论与预计版本（回写工单；超时→售后统筹） 👤人工判断
7 需求转需求池，Badcase 转收集表，收费/合同问题转销售 产品值班 1 个工作日内 需求池/收集表 转单记录（需求池/Badcase 收集表条目，关联编号回填工单，原帖回复去向） 🔧飞书固化
8 修复发版后，产品值班给对客口径，客户对接告知客户；稳定 24 小时后关单 产品值班、客户对接 发版当天通知；24 小时后关单 客户群/工单 对客口径（写入工单）+ 客户群回告 + 关单记录 👤人工判断
9 每周汇总高频问题，更新 FAQ 与机器人知识库 FAQ 维护、售后统筹 每周五 多维表格+AI 归纳 FAQ 更新（帮助中心 FAQ + 机器人知识库） 🤖自动化

5. 交付物与模板

  • 交付物：客户问题工单、缺陷单（关联）、对客回复记录、每周 FAQ 更新
  • 「客户问题工单」字段：工单号、来源入口、客户/企业、产品与版本、模型档位、网络环境、现象、截图/录屏、日志/traceid、分级、分类、产品值班、研发负责人、关联缺陷单号、预计修复版本、对客回复、状态、首响时间、关单时间

6. 异常与升级

  • 信息不全 → 机器人自动追问；2 小时未补齐则挂起并通知反馈人
  • 同一问题多人重复报 → 合并到已有工单，回复工单号和当前状态
  • P0（多个客户不可用、新版本大面积问题） → 立即拉研发负责人，指定一名修复负责人，30 分钟内发对外统一口径 → 同时报 CTO
  • 研发 24 小时未给结论 → 售后统筹催办 → 升级研发负责人
  • 客户直接呼叫研发或拉研发进私聊 → 引导回反馈群；非 Bug 由客户对接答复
  • 涉及收费或合同外内容 → 转销售，产研不做口头承诺
  • 产品值班 1 小时未首响（P0 15 分钟）→ 机器人提醒，售后统筹接手首响 → 升级售后统筹（超时即刻）
  • 测试 4 个工作小时未复现或未建缺陷单 → 产品值班直接建单并 @研发 oncall → 升级测试负责人（当日）
  • 发版后 24 小时内客户对接未回告客户 → 产品值班代为回告并记录工单 → 通报售后统筹（次日）

7. 衡量指标

  • 首响达标率 = 1 小时内首响的工单数 / 总工单数，目标 ≥ 90%
  • 信息一次完整率 = 首次上报即含客户名、版本、完整截图的工单比例，目标 ≥ 80%
  • P1 结论时长 = 建单到研发给结论的时间，目标 ≤ 1 个工作日
  • 回告闭环率 = 已回告客户的关单数 / 关单总数，目标 100%
  • FAQ 可答比例 = 按 FAQ 直接答复的工单 / 总工单，逐月上升
  • 一线答疑集中度 = 回复最多的单人回复数 / 研发回复总数，目标 ≤ 40%

8. 低效诊断

  • 现象：问题先在业务群、私聊或外部微信群出现，再多手转述，"一句话传好几手"，上下文丢失｜依据：「工程咨询产研」2026-01、「Leap产研测」2026-06、「Leap产研测」2026-07、「Leap产研测」2026-09
  • 现象：研发每次都要追问版本、环境、日志、"哪家客户"，截图不全｜依据：「Leap产研测」2026-08、「Leap反馈群」2026-09、「Leap产研决策部」2026-09
  • 现象：客户问题夹在研发群里讨论，谁对客回复不清；研发被客户直接追问，被迫当客服｜依据：「鼎慧产研决策部」2026-05、「Leap产研测」2026-07、「Leap产研决策部」2026-08
  • 现象：入口多头（反馈群、订单群、测试群、AI 群、表单），发到哪里意见相反｜依据：「模态跃迁通知群」2026-05、「Leap产研决策部」2026-09
  • 现象：一线答疑集中在单个研发，同类问题（会话消失、网络异常、导出失败）一个月内被重复问 10 次以上，答案多为"重启客户端"｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：无工单号和完成标准，"进度怎么样了"反复催；修复后谁告知客户不固定｜依据：「某客户项目群」2026-09、「Leap产研决策部」2026-10
  • 现象：产品内反馈要手工查数据库，后台看不到反馈图片｜依据：「工程咨询产研」2026-03、「工程咨询产研」2026-06
  • 现象：高频问题收集表无人填写，靠导出聊天记录补｜依据：「【模态】市场销售」2026-10
  • 现象：社区产品客诉直接点名个人处理，无入口和值班｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：演示中途出故障才暴露问题，客户流失｜依据：「Leap产研测」2026-06

9. 分支变体

  • 已交付私有部署客户：客户在企业微信售后群提问，客户对接人转反馈群；咨询类由客户对接答复，确认是 Bug 才找研发
  • 内测/种子用户、内部员工：直接发反馈群或用产品内"报告问题"
  • LeapAll 个人付费用户客诉（兑换券、计费）：产品值班处理，补券/额度走 X-CS-03
  • 政企内网客户：需要远程或现场排查时转 X-CS-06
  • 渠道/合作方转述：必须带终端客户名
  • 社区/开源产品（Claw）：先给自救指引（重启网关、查日志）和急救文档，再分级处理
  • 新版本集中爆 Bug：指定一名修复负责人，统一对外告知"更新到 X 版本"
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-06（卡点升级阶梯）、ALL-09（状态看板与进度同步）

10. 待确认问题

  • 主责是否定为当日产品值班？售后统筹与产品值班如何分工？
  • P0～P3 分级和对应时限是否可行？
  • 客户专属问题发订单群还是反馈群？（目前有相反意见）
  • 客户层台账用飞书多维表格，缺陷仍在 Gitea issues，两者如何关联？
  • FAQ 放帮助中心还是机器人，由谁维护？
  • "稳定 24 小时即关单"是否作为统一完成标准？
X-CS-06客户现场问题分级排查与日志/诊断包收集待优化320

状态：待优化｜证据：有证据（卡片 11 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：一线无法判断的客户故障（死机、模型无响应、Agent 中断、容器创建失败、断电后异常、VPN/网络异常、定时任务异常），需要按顺序收集日志/诊断包、远程排查、定位根因并修复（含批量修复）时启动
  • 负责人：主责——当日研发 oncall（当前：吴世豪、杨云峰、岳阳·推断待确认）；协同——产品值班/对客转接（当前：黄飞鹏、陈震·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、服务端与发版（当前：宋祺睿·推断待确认）、NewAPI 查询（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、远程访问与日志归集（当前：郭逸非·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 一线按排查顺序自查 → ② 导出客户端诊断包 → ③ 研发初判 → ④ 必要时取服务端日志或远程上机 → ⑤ 给止血方案 → ⑥ 出书面结论与影响面 → ⑦ 修复或批量修复 → ⑧ 回访并关单
  • 交付结果：每个现场故障有书面结论（现象-根因-验证-修复-影响面），附诊断包和工单号；批量问题有经评审的修复脚本和受影响客户清单
  • 状态依据：已提出排查顺序（先教用法→已知问题→客户端日志→服务端日志），客户端已有"导出诊断信息"，也有过高质量书面结论；但未成文，日志靠逐句追问、常发错，远程访问手工开通回收，批量修复脚本未评审

1. 场景判定

  • 触发条件：X-CS-05 分类为 Bug 且一线无法判断；客户无法使用或演示前出故障；升级后多台客户机异常
  • 典型说法：「他们说好像有点死掉了」「日志发我看看」「机器断过电吗」「这个客户的诊断包，加急修」「给一个结论，是 bug 待修吗」「影响多少，不多的话手工修下」「排查顺序也加入售后 SOP」
  • 判断问题：已按 FAQ 自查仍未解决？必须看日志或上机才能判断？
  • 不归本流程管：首次受理与分类 → 请走 X-CS-05；安装、更新失败 → 请走 X-CS-07；远程权限审批与回收 → 请走 X-SEC-07；客户网络与远程接入配置 → 请走 X-DLV-16；缺陷修复排期 → 请走 RND-03；线上回滚 → 请走 RND-59；强制更新策略 → 请走 RND-53；交付期现场问题 → 请走 X-DLV-34

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发 oncall 初判、取日志、止血方案、书面结论、修复 A/R 研发（当前：吴世豪、杨云峰、岳阳·推断待确认）
产品值班/对客转接 引导客户自查与导出诊断包、传递对客口径 R 产品经理（当前：黄飞鹏、陈震·推断待确认）
交付部署工程师 客户机远程/现场操作、手动打包日志 R 交付部署工程师（当前：游家豪·推断待确认）
服务端与发版 评估影响面、hotfix、批量脚本下发 R 后端/运维（当前：宋祺睿·推断待确认）
NewAPI 查询 查模型网关调用与余额记录 C NewAPI 研发（当前：柯逸飞·推断待确认）
测试 复现、挂缺陷单、验证修复 C 测试（当前：张东郅·推断待确认）
远程访问与日志归集 开放平台侧日志查询、远程访问通道支持 C 开放平台负责人（当前：郭逸非·推断待确认）
研发负责人 加急决策、数据库类止血操作确认、批量修复审批 C 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 工单号（来自 X-CS-05）、客户/实例名（查 X-CS-04 台账）、客户端版本
  • 客户端诊断包 diagnose-*.zip（用"导出诊断信息"导出；经企业微信传输后确认不是 .temp 临时文件）
  • 故障时间、使用的模型/入口、复现步骤、完整截图
  • 是否断电、重启、刚更新；网络环境（客户内网/VPN）
  • 远程访问授权（需上机时）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按排查顺序自查：是否使用方法问题 → 是否已知问题（查 FAQ/工单）→ 重启客户端、检查更新 产品值班 受理后 1 小时内 FAQ 自查结果 🤖+👤
2 未解决：指导客户导出诊断包，直接上传到工单，不经私聊转发 产品值班 自查后 1 小时内 客户端/工单 诊断包 🔧飞书固化
3 初判（客户网络、安全软件、版本过旧、余额不足、上游模型故障、产品缺陷），AI 先按日志关键词归类 研发 oncall 收到诊断包后 P0 30 分钟、P1 4 小时内 日志检索/AI 初判结论 🤖+👤
4 客户端提示服务端异常时取服务端/NewAPI/容器日志；需上机先走远程审批，用完当天回收 研发 oncall、NewAPI 查询 初判后当天 wg/更新平台 服务端证据 👤人工判断
5 给止血方案；涉及数据库或删数据的操作须研发负责人确认后执行 研发 oncall P0 4 小时内 工单 止血步骤 👤人工判断
6 书面结论写入工单：现象、根因、验证、修复建议，以及属于"缺陷待修/客户环境/未推更新"哪一类、影响面 研发 oncall 初判后 1 个工作日内 工单 书面结论 👤人工判断
7 修复：单客户手工处理；多客户写带保护逻辑的批量脚本，经另一名研发评审，先在 1 台客户机验证再批量下发 研发 oncall、服务端与发版 按缺陷分级时限 更新平台/脚本仓库 修复记录 🤖+👤
8 产品值班给对客口径，客户对接告知客户；稳定 24 小时后关单 产品值班 修复当天通知 工单 关单 👤人工判断

5. 交付物与模板

  • 交付物：诊断包、书面结论、修复/批量脚本（入库）、受影响客户清单
  • 书面结论模板：客户/实例、版本、现象、时间线、根因、验证方法、修复方式（手工/脚本/hotfix/下版本）、影响面（客户数、部署时间段）、对客口径、是否需客户操作
  • 批量修复记录字段：脚本仓库路径、评审人、试点机器、下发范围、执行结果、回滚方式

6. 异常与升级

  • 诊断包不完整或客户断网无法导出 → 手动打包日志目录，或下发带增强日志的更新 → 仍不行转交付部署工程师远程/现场（1 个工作日内）
  • 客户机无法远程 → 交付部署工程师现场处理，或请客户 IT 配合
  • 演示前或重要客户紧急故障 → 研发负责人加急并指定专人 → 2 小时无进展升级 CTO
  • 根因在第三方平台或客户自有算力 → 出书面结论后转销售确认是否收费
  • 疑似影响多台客户机 → 立即评估影响面，批量修复前通知售后统筹

7. 衡量指标

  • 日志一次获取成功率 = 首次提供即可用于定位的诊断包数 / 总数，目标 ≥ 80%
  • P1 结论时长 = 收到诊断包到书面结论的时间，目标 ≤ 1 个工作日
  • 书面结论覆盖率 = 有书面结论的现场故障单 / 总数，目标 100%
  • 批量脚本评审率，目标 100%；修复后 7 天复发率，目标 ≤ 10%
  • 远程权限当天回收率，目标 100%

8. 低效诊断

  • 现象：每次都要追问哪台机器、哪个模型、有没有日志，问题经转发聊天记录传递｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：日志发错（桌面端日志与 Agent 日志混淆）、目录复杂，诊断包经企业微信变成临时文件需重发｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09、「Leap产研测」2026-10
  • 现象："一键传日志"多次提出，产品早期没有日志导出｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • 现象：报错一律显示"网络错误"，定位费时，多人私聊问同一类问题｜依据：「某客户项目群」2026-07、「某客户项目群」2026-09
  • 现象：一线在客户群与研发群之间当传声筒；之前谁对接过不清楚｜依据：「Leap产研测」2026-09
  • 现象：结论迟迟不出，管理层追问"是缺陷待修还是没推更新"｜依据：「Leap产研测」2026-09
  • 现象：批量修复脚本直接在群里发，影响面口头判断｜依据：「Leap产研测」2026-09
  • 现象：远程访问依赖客户配合，权限手工回收；看日志要上服务器｜依据：「Leap产研决策部」2026-08

9. 分支变体

  • 自有机器（可 ssh/wg） / 客户自有算力（日志只在客户侧） / 国企、政府内网（只能现场）
  • LeapCore 旧版客户（无导出功能，需手动打包） / 新版客户（有"导出诊断信息"）
  • 演示前排查：同时走演示版本冻结 → 请走 RND-61
  • 升级后批量异常：按步骤 7 走批量脚本评审
  • 断电导致数据库锁：止血步骤须研发负责人确认后执行
  • 对客内容不透露上游模型供应商

10. 待确认问题

  • 主责是否为当日研发 oncall？VPN/网络类问题是否固定由 VPN 负责人处理？
  • P0 30 分钟响应、4 小时止血、P1 1 个工作日出结论是否可行？
  • 批量修复脚本的评审人和存放仓库定在哪里？
  • 远程访问审批归 X-SEC-07 还是本流程？
  • 客户端强制升级策略由谁定？
  • "Agent 自读日志生成工单"是否立项？
X-CS-07客户端安装、更新与模型服务连接问题一线支持待优化72

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗2 × 跨3 × 险3

  • 适用场景：客户安装/更新失败、被安全软件拦截、签名校验失败、系统不兼容、连错服务器、网页提示模型服务不可用时，由一线按手册远程指导解决，解决不了再升级
  • 负责人：主责——一线售后支持（当前：韩诗琪·推断待确认）；协同——客户端研发（当前：岳阳、葛家和·推断待确认）、服务端/运维（当前：宋祺睿·推断待确认）、IT 网络（当前：杨明学·推断待确认）、产品值班（当前：张东郅·推断待确认）；兜底——售后统筹（当前：杨萌·推断待确认）
  • 核心流程：① 核对系统要求与版本 → ② 按排障手册判类（安装/更新/连接/模型服务） → ③ 远程指导客户可操作的步骤 → ④ 收集截图、时间、版本、环境 → ⑤ 升级研发/运维 → ⑥ 回复客户并补充 FAQ
  • 交付结果：客户恢复使用；或 1 小时内带完整信息升级；《系统要求+安装排障》手册和话术库持续更新
  • 状态依据：已有 help.leapcore.cn 下载页和"更新失败三类原因"整理，有口头排查套路；但系统要求和安装排障没有成文手册，同类问题在群里重复问二十余次，回复客户靠临时现编话术

1. 场景判定

  • 触发条件：安装报错；更新被阻止或签名校验失败；客户系统为 Win7/Intel Mac 等；登录时连到错误服务器；网页提示模型服务不可用
  • 典型说法：「我怎么回复客户」「更新包签名校验失败」「请先关掉页面等一分钟重新登录再试」「是的，不支持 Win7」「把截图和时间发我」
  • 判断问题：问题是否发生在安装、更新、连接环节？账号密码错误不走本流程
  • 不归本流程管：账号与密码 → 请走 X-CS-08；功能 Bug → 请走 X-CS-05；需日志深查 → 请走 X-CS-06；安装包打包签名 → 请走 RND-52；OTA 与强制更新策略 → 请走 RND-53

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
一线售后支持 按手册远程指导、收集信息、升级、回复客户 A/R 一线售后支持（当前：韩诗琪·推断待确认）
客户端研发 判断安装/更新/签名问题，维护排障手册 R 客户端研发（当前：岳阳、葛家和·推断待确认）
服务端/运维 模型服务不可用时排查并重启服务 R 后端/运维（当前：宋祺睿·推断待确认）
IT 网络 网络拦截、局域网发现类问题支持 C IT 运维（当前：杨明学·推断待确认）
产品值班 复现与提缺陷单 C 测试/产品（当前：张东郅·推断待确认）
售后统筹 话术审定、兜底 I 售后统筹（当前：杨萌·推断待确认）

3. 办之前请准备

  • 客户操作系统及版本；Mac 需确认是否 M 系列芯片
  • 客户端版本、完整报错截图、发生时间
  • 安全软件情况（360、火绒、企业安全策略、Win11 智能应用控制）
  • 网络环境（公司网/外网/手机热点）、企业服务器地址
  • 使用的模型与入口（网页/客户端）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 核对系统要求：Windows 10 及以上、macOS 11 及以上且 M 系列芯片；不支持 Win7、Intel Mac；信创系统用专门安装包 一线售后支持 受理后 15 分钟内 系统要求公告 核验结果 🔧飞书固化
2 安装/更新失败：弱网重试 → 从帮助中心手动下载最新版 → 安全软件放行 → 重启 一线售后支持 30 分钟内 help.leapcore.cn 指导记录 👤人工判断
3 连接问题：核对企业服务器地址、是否在公司网外、agent 进程是否被防火墙拦截 一线售后支持 30 分钟内 排障手册 指导记录 👤人工判断
4 模型服务不可用：先说明不是客户电脑坏了；完全退出等 1 分钟重登 → 换浏览器或无痕模式 → 用手机热点排除网络拦截；客户不碰日志和配置 一线售后支持 30 分钟内 话术库 指导记录 🤖+👤
5 仍未解决：收集截图、开始时间、模型/入口、版本、环境，在反馈群建单并 @客户端研发或运维 一线售后支持 自查结束后 1 小时内 反馈群/工单 升级单 🔧飞书固化
6 研发/运维判断：服务端问题重启服务；客户端问题给办法或排入下个版本 客户端研发、服务端/运维 P1 4 小时内回复 工单 处理结论 👤人工判断
7 回复客户；新出现的问题补进排障手册和 FAQ 机器人 一线售后支持、客户端研发 回复当天；手册 2 个工作日内更新 帮助中心/机器人 FAQ 更新 🤖自动化

5. 交付物与模板

  • 交付物：帮助中心《系统要求+安装排障》、对客话术库、错误提示→处理办法映射表
  • 升级单字段：客户、系统及版本、芯片、客户端版本、报错截图、发生时间、安全软件、网络环境、服务器地址、已尝试步骤

6. 异常与升级

  • 客户系统不支持 → 明确告知并建议换设备，同时通知对接销售（售前应核验机型）
  • 多台客户机批量更新失败 → 转 X-CS-06 走批量修复
  • 服务端故障影响多个客户 → 按 P0 立即转研发 oncall
  • 信创/麒麟安装包问题 → 转信创负责人，1 个工作日内给结论
  • 客户反复操作仍失败、无法远程 → 约交付部署工程师远程或现场

7. 衡量指标

  • 一线解决率 = 一线不升级即解决的单数 / 总单数，目标 ≥ 70%
  • 升级信息完整率 = 升级时字段齐全的单数 / 升级总数，目标 ≥ 90%
  • 一线处理时长 = 受理到解决或升级的时间，目标 ≤ 1 小时
  • 同类问题群内重复提问次数，目标每月 ≤ 3 次

8. 低效诊断

  • 现象：一线不知道如何回复客户，靠研发临时判断；默认密码有两套口径｜依据：「Leap产研测」2026-06
  • 现象：更新被阻止、签名校验失败约 6 次，系统要求被重复问约 5 次｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：客户实际装的是旧版本，却按新版本排查｜依据：「Leap反馈群」2026-08
  • 现象：模型服务不可用的对客话术每次靠机器人临时生成，运维响应人不明，排查悬而未决｜依据：「随便瞎聊啦～」2026-07
  • 现象：信创安装包问题定位困难，长时间未解决｜依据：「Leap反馈群」2026-09

9. 分支变体

  • Windows / macOS（不支持 Intel 芯片）/ 麒麟等信创系统 / 手机端微信绑定
  • 个人版 vs 企业服务器版：企业版需核对服务器地址
  • 公司网内 vs 外网：外网需确认远程访问方式
  • 发布者名称变更的版本：只能手动下载安装，不能自动更新

10. 待确认问题

  • 一线主责由销售运营兼任还是产品值班承担？
  • 系统要求（Win10+、macOS 11+、仅 M 系列）是否为最终口径？
  • 模型服务故障的运维响应人是谁？
  • 局域网自动发现（OOBE/mDNS）何时上线？
  • 是否要求销售/交付在发货前强制核验客户机型？
X-CS-08账号登录失败与密码找回待新建96

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：用户或企业管理员登录失败、忘记密码、重置短信收不到、报错提示模糊、客户实际连到错误实例，需要核验身份后重置或纠正连接地址时启动
  • 负责人：主责——账号密码重置管理员（后端）（当前：宋祺睿·推断待确认）；协同——产品值班（当前：陈震·推断待确认）、产品负责人（当前：杨萌·推断待确认）、后端研发（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、销售（重置申请发起，当前：陈名赞·推断待确认）、测试（当前：张东郅·推断待确认）、CTO（审批规则，当前：丁震宇·推断待确认）；兜底——研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 一线引导自查（提示、实例地址、账号是否注册） → ② 普通用户找本企业管理员重置 → ③ 管理员忘记时提交重置申请 → ④ 三方核验 → ⑤ 重置为随机密码并私密交付 → ⑥ 客户首登改密 → ⑦ 留档
  • 交付结果：客户恢复登录；超管密码重置有审批和操作留档；初始/重置密码不在群里明文传递
  • 状态依据：LeapCore 为独立账户体系、无手机验证码，管理员忘记密码"找售后"但没有方案，曾临时改数据库硬重置；多次排查最后发现是记错密码、账号未注册或连到测试机；收费口径未定

1. 场景判定

  • 触发条件：登录提示手机号或密码错误；忘记密码；重置短信收不到；强制改密后进不去；管理员忘记密码且没有其他管理员
  • 典型说法：「忘记密码就找管理员」「管理员忘记密码就找售后」「说忘记密码，找我重置，还是不行」「直接重置密码吧」「后面走个 SOP 提审留档吧」
  • 判断问题：是不是客户/用户账号的登录或密码问题？账号还没开通走 X-CS-02
  • 不归本流程管：账号开通与席位 → 请走 X-CS-02；内部员工后台账号密码 → 请走 X-SEC-03；客户索要设备 root/管理员权限 → 请走 X-SEC-07；安装与连接问题 → 请走 X-CS-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品值班 引导自查、判断是否连错实例或账号未注册、告知找本企业管理员 R 产品经理（当前：陈震·推断待确认）
销售 发起管理员重置申请、收集客户方确认、私密交付新密码 R 销售（当前：陈名赞·推断待确认）
账号密码重置管理员 审核申请、执行重置、留档 A/R 后端（当前：宋祺睿·推断待确认）
后端研发 连接实例逻辑排查、短信发送排查 C 后端研发（当前：杨云峰·推断待确认）
交付部署工程师 需上机重置时现场/远程操作 C 交付部署工程师（当前：游家豪·推断待确认）
产品负责人 登录提示、忘记密码页、实例名显示等改进需求 C 产品负责人（当前：杨萌·推断待确认）
测试 复现登录问题 C 测试（当前：张东郅·推断待确认）
研发负责人 兜底；批准无后台功能时直接改数据库等非常规重置 A（升级） 研发负责人（当前：王皓南·推断待确认）
CTO 审批规则与收费口径 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 企业名/实例名、登录地址或服务器 IP、账号（手机号）、客户端版本、报错截图
  • 管理员重置另需：客户发起人申请、商务负责人确认、客户 IT 负责人确认、合同/订单号
  • SaaS 短信问题另需：手机号运营商、发送时间

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 引导自查：看清报错提示；核对登录地址/实例名（是否连到测试机）；确认账号已在该企业注册；换版本后是否需重新登录 产品值班 受理后 30 分钟内 排障手册 自查结果 👤人工判断
2 普通员工忘记密码：告知找本企业管理员在后台重置，公司不直接改 产品值班 30 分钟内 管理后台 答复 👤人工判断
3 管理员忘记且无其他管理员：提交「管理员密码重置申请」 销售 当天 飞书审批 申请单 🔧飞书固化
4 三方核验：客户发起人、商务负责人、客户 IT 负责人确认 销售、账号密码重置管理员 1 个工作日内 飞书审批 核验通过 👤人工判断
5 执行重置为随机密码；设备支持按钮确认时优先用按钮确认方式 账号密码重置管理员 审批后 1 个工作日内 LeapAuth 后台 重置记录 👤人工判断
6 新密码私信发给客户发起人，不进群；要求首次登录修改 销售 重置当天 飞书私信 交付记录 👤人工判断
7 建议客户为员工新建超管，不再共用一个超管号；留档 销售、账号密码重置管理员 重置当天 飞书多维表格 留档记录 🔧飞书固化
8 SaaS 短信收不到：查短信发送回执，换号或由运营后台代重置 后端研发 1 个工作日内 短信平台/后台 处理结论 👤人工判断

5. 交付物与模板

  • 交付物：重置申请单、重置留档、对客说明
  • 申请单字段：企业名、实例名、合同/订单号、需重置账号、客户发起人、商务负责人、客户 IT 负责人、原因、是否收费
  • 留档字段：申请单号、操作人、操作方式（后台/按钮/数据库）、操作时间、交付方式、客户确认改密时间

6. 异常与升级

  • 重置后仍无法登录 → 检查是否连错实例或账号未注册 → 转 X-CS-07
  • 无法核验客户身份 → 不重置，升级销售负责人
  • 无后台功能需直接改数据库 → 研发负责人批准，两人在场操作并留档
  • 是否收费有争议 → 按交付服务承诺口径判定 → 请走 X-DLV-30
  • 短信渠道故障影响多人 → 按 P1 转后端研发，当天给结论
  • A（升级）说明：常规重置由账号密码重置管理员负最终责任；没有后台功能、需要直接改数据库或其他非常规方式重置时，拍板权升级到研发负责人，批准后两人在场操作并留档

7. 衡量指标

  • 普通登录问题处理时长，目标 ≤ 4 小时
  • 管理员重置周期 = 申请到客户可登录，目标 ≤ 2 个工作日
  • 重置留档率，目标 100%
  • 密码明文进群次数，目标 0
  • 登录类工单中"记错密码/连错实例/未注册"占比，产品改进后逐季下降

8. 低效诊断

  • 现象：管理员忘记密码没有预设方案，临时直接改数据库｜依据：「某客户项目群」2026-09
  • 现象：重置后仍登不上，实际是企业地址错误自动连到测试机｜依据：「Leap产研测」2026-09
  • 现象：登录排查来回多轮，最后多为记错密码或账号未注册；"现在管理员是谁"说不清｜依据：「Leap反馈群」2026-06、「Leap反馈群」2026-07、「Leap产研决策部」2026-09
  • 现象：为防撞库，手机号与密码错误同一提示，引发客诉｜依据：「LeapCore（archived）」2026-06
  • 现象：重置后的初始口令在群里明文发送｜依据：「LeapCore（archived）」2026-07、「Leap反馈群」2026-07
  • 现象：重置短信收不到，本地复测不出、日志查不到、无人负责，缺代重置功能｜依据：「鼎慧产研决策部」2026-04
  • 现象："忘记密码时显示管理员联系方式"设计未做完｜依据：「Leap反馈群」2026-07
  • 现象：管理员忘记密码"找售后"的规则定了，但售后方案未留｜依据：「Leap产研测」2026-06

9. 分支变体

  • LeapCore 私有部署：独立账户体系、无短信，员工找本企业管理员，管理员走三方核验
  • LeapAll/字字可研 SaaS：手机号+短信，优先自助找回，短信异常由后台代重置
  • 交付机初始超管 vs 员工账号：初始超管重置须三方核验
  • 设备有物理按钮确认能力 vs 无：有则优先按钮确认
  • 内部员工账号：走 X-SEC-03

10. 待确认问题

  • 管理员密码重置是否收费？收费标准由谁定？
  • 三方核验是否必须？客户没有 IT 负责人时由谁替代？
  • 物理按钮重置是否纳入产品规划？
  • 登录页显示实例名、忘记密码页显示管理员联系方式何时上线？
  • 主责是后端管理员还是售后岗（售后岗到位后是否移交）？
X-CS-09计费余额异常核查、对账修复与退款待新建400

状态：待新建｜证据：有证据（卡片 5 张 / 会话 8 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：客户或用户反馈充值未到账、扣费异常（失败仍扣费、扣得过快）、余额为 0 或为负、充值/消费/剩余三者对不上、Token 消耗异常激增，或额度充错对象时启动。
  • 负责人：主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、服务端研发（当前：邓乾、杨云峰、岳阳·推断待确认）、网关上游维护（当前：杨明学·推断待确认）、运维（当前：宋祺睿·推断待确认）、一线客户对接人（当前：杜中瑞、杨朋伟、游家豪、闫登辉·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 受理登记 → ② 分类定级 → ③ 查订单/账单/网关日志 → ④ 定位根因 → ⑤ 出修复或补偿方案并审批 → ⑥ 备份后执行修复/退款 → ⑦ 客户验收与答复 → ⑧ 复盘并沉淀 FAQ
  • 交付结果：结案的计费异常工单（含根因、影响范围、修复/退款记录、客户确认），P0/P1 事件的复盘文档，更新后的计费 FAQ。
  • 状态依据：充值回调延迟、生成失败仍扣费、预占规则不透明、对账口径不一、大客户缓存未命中等问题在 2026-06～10 反复出现约 20 次，每次靠群内临时拉人排查；无客服入口、无退款规则、无数据修复规范，仅在一次大客户事故后补了复盘文档。

1. 场景判定

  • 触发条件：
    • 充值后余额未增加或只到账一部分；同一笔支付出现两笔订单
    • 生成失败或中途终止仍被扣费，或额度被冻结未释放
    • 余额显示为 0、负数，或接口返回 402（余额不足）而客户认为仍有余额
    • 管理端"充值—消费—剩余"三项对不上，或消费明细与汇总不一致
    • 某客户/某 Key 单日消耗突增、缓存命中率骤降（账单告警或人工发现）
    • 额度充错对象（如充到演示机、测试机）
  • 典型说法：「充了钱只到了一部分」「中途终止了也会扣钱吗」「为什么余额是负的」「消费金额跟明细对不上」「看看谁在猛刷 Token」
  • 判断问题：
    1. 是"钱/额度数字不对"，还是"功能用不了"？后者先按连接/环境问题排查。
    2. 手上有没有订单号、账户或实例标识、异常时间点和截图？
    3. 是单个用户还是同一时段多人报告？多人 = 系统性故障，直接按 P0。
  • 不归本流程管：
    • 正常充值到账审核与额度开通 → 请走 X-CS-03 / FIN-17
    • C 端商城卡密、消费券退款与客诉 → 请走 X-CS-10
    • 模型售价、倍率调整 → 请走 X-PRD-22 / RND-69
    • 充值订单开票 → 请走 FIN-18
    • 服务迁移中的账号与余额迁移 → 请走 X-CS-16
    • 客户端连接失败、模型服务连不上 → 请走 X-CS-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
一线受理人 收集信息、登记工单、对客同步进展 R 销售/交付对接人（当前：杜中瑞、杨朋伟、游家豪、闫登辉·推断待确认）
计费排查主责 查订单、账单、网关日志，定位根因，出修复方案，跟到结案 A/R 模型网关与计费研发（当前：柯逸飞·推断待确认）
服务端研发 支付回调、钱包、冻结回滚等代码修复 R 服务端研发（当前：邓乾、杨云峰、岳阳·推断待确认）
上游验证 验证上游渠道计价、缓存是否正常 C 网关上游维护（当前：杨明学·推断待确认）
口径与补偿决策 定对客口径、批准补偿/退款方案 A（升级） 产品负责人（当前：杨萌·推断待确认）
财务 退款打款、账务调整留痕、与充值记录对账 R 财务专员（当前：待指定）
运维 客户内网访问开通、数据库备份 C 运维（当前：宋祺睿·推断待确认）
兜底 P0 事故、改企业库、大客户沟通拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户/账户标识：企业名称、实例 ID、机器码或 UID（手机号等个人信息填工单字段，不在群里发）
  • 订单号、支付时间、支付方式、支付成功截图
  • 异常时间段、涉及的模型或功能（对话、生图、视频等）
  • 管理端余额页、消费明细截图
  • 接入方式：客户端还是 API；API 需注明接口类型（chat/completions 或 messages）和所用工具
  • 是否已有关联工单（先查，避免重复排查）
  • 请求最少包含字段：客户/实例标识、订单号或令牌、异常类型（未到账/误扣/余额异常/对账不平/异常消耗/错充）、异常时段、余额页与消费明细截图、接入方式、影响范围（单用户/多人）、期望时限；缺项由一线受理人补齐后再登记，不直接 @研发

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按"办之前请准备"收齐信息，登记计费异常工单，回复客户"已受理、正在核查" 一线受理人 收到反馈后 2 个工作小时内 飞书表单 → 多维表格 计费异常工单（多维表格，工单编号回复客户） 🔧飞书固化
2 定级：P0＝同一时段多人报告或资损持续扩大；P1＝单客户资金差错；P2＝规则解释类 计费排查主责 受理后 1 小时内 多维表格 定级结果（工单字段；P0 同步 CTO） 👤人工判断
3 P2 规则解释类（预占、最低余额门槛、失败扣费口径）按 FAQ 答复后结案 一线受理人 定级后当日 帮助中心 FAQ、AI 客服 答复记录（工单 + 客户群） 🤖自动化
4 查证：支付回调、钱包流水、网关请求日志、缓存读写字段、充值对象 计费排查主责 + 服务端研发 P0 2 小时内出初判；P1 1 个工作日内 管理后台、网关日志、数据库只读账号 排查记录（工单评论：时间线 + 证据链接；超时→产品负责人） 👤+🤖（日志检索）
5 异常消耗类：同一时刻对链路各环节（客户端→内网网关→总网关→上游）分别调用对比，定位参数丢失或渠道类型错误 计费排查主责 + 上游验证 发现当日给结论 接口调试工具、网关日志 根因结论（回写工单根因分类） 👤人工判断
6 出方案：影响范围、差额口径（以企业余额为准）、修复脚本、回滚步骤、仅报障客户修还是全量修 计费排查主责 根因确认后 1 个工作日内 Issue 系统 修复/补偿方案（Issue 系统，链接回写工单） 👤人工判断
7 审批：补偿/退款由产品负责人批准并抄送财务；P0 或改企业内网数据库需 CTO 确认 产品负责人 / CTO 方案提交后 4 个工作小时内 飞书审批 退补审批单（飞书审批，编号回写工单；超时→CTO） 🔧飞书固化
8 执行：先备份数据库，在业务低峰执行脚本；退款/补额度由财务或管理员操作并留痕 服务端研发 / 财务 审批后 1 个工作日内 数据库、管理后台、支付后台 执行记录与备份位置（工单）+ 退款/补额凭证（财务留痕） 👤人工判断
9 客户核对余额与明细；确认后说明原因与结果，不把责任推给用户 一线受理人 + 产品负责人 执行后 1 个工作日内 客户群、工单 客户确认（工单附客户确认回复） 👤人工判断
10 P0/P1 写复盘；新口径补进 FAQ 与接入指南；可监控项提告警/对账脚本需求 计费排查主责 结案后 3 个工作日内 飞书 wiki、帮助中心 复盘文档（飞书 wiki，链接回写工单）+ FAQ 更新（帮助中心） 🤖自动化

5. 交付物与模板

  • 交付物：计费异常工单、排查记录、修复/退款审批单、数据修复方案、复盘文档、FAQ 条目、对客接入说明（如有）
  • 建议模板/表单「计费异常登记」：工单号、客户/实例、反馈渠道、异常类型（未到账/误扣/余额异常/对账不平/异常消耗/错充）、订单号、异常时段、涉及模型/功能、接入方式、定级、根因分类（回调延迟/上游失败未回滚/价格同步时差/统计口径/渠道配置/客户使用方式）、处理方式（解释/补额/退款/改数）、审批人、执行人、客户确认时间
  • 建议模板「数据修复方案」：影响范围、修复前后对比、备份位置、回滚步骤、执行时间窗、验收人

6. 异常与升级

  • 同一时段 ≥3 人报告充值/扣费异常 → 按 P0 处理，必要时暂停相关入口并发公告 → 30 分钟内升级 CTO
  • 单客户单日消耗明显超出历史水平或缓存命中骤降 → 先提醒客户暂停/限流再排查 → 2 小时内升级 CTO，当日给结论
  • 客户提出投诉或外部投诉意向 → 产品负责人当日回访 → 同步 CTO
  • 排查需访问客户内网 → 向运维申请访问，4 个工作小时内开通 → 超时升级 CTO
  • 排查人 2 小时内无响应（加急无回复）→ 兜底指定备岗接手
  • 修复失败或无法回滚 → 立即停止，恢复备份 → 当即升级 CTO
  • 一线受理人 2 个工作小时未登记工单 → 产品值班代为登记 → 升级产品负责人（当日）
  • 审批人 4 个工作小时未处理 → 一线受理人电话提醒 → 再超 4 个工作小时升级 CTO
  • 财务 1 个工作日内未执行退款/补额 → 产品负责人催办 → 升级财务负责人（次日）
  • A（升级）说明：计费异常从排查到结案由计费排查主责负最终责任；需要补偿、退款或调整对客口径时，方案审批权升级到产品负责人；P0 事故、需改企业内网数据库、仅修报障客户还是全量修、大客户沟通，拍板权升级到 CTO

7. 衡量指标

  • 首次响应时长：反馈到受理回复的工作小时数，目标 ≤ 2 小时
  • 结案周期：受理到客户确认，P0 ≤ 1 个自然日，P1 ≤ 3 个工作日
  • 同根因复发数：同一根因分类的季度工单数，目标逐季下降
  • FAQ 自助解决率：P2 不需研发介入的比例，目标 ≥ 60%
  • 修复二次返工次数：改数后需再次修复的次数，目标 0

8. 低效诊断

  • 现象：无统一客服入口，集中充值日回调延迟时多人同时在大群报告，缺人收口，研发和产品被打断｜依据：「跃迁AI总动员」2026-06
  • 现象：退款规则无成文，现场临时表态"只能人工退"；到账延迟时长口径不一｜依据：「跃迁AI总动员」2026-06
  • 现象：预占额度、最低余额门槛等扣费规则未对外说明，一线每次截图问研发；后台功能下线后一线仍在旧入口找｜依据：「Leap反馈群」2026-08、2026-09；「某地方政府客户对接群」2026-08
  • 现象：网关日志只能定位到企业，定位到个人和判断是否 bug 依赖个别研发经验｜依据：「某芯片企业客户对接群」2026-07；「某科研院所客户对接群」2026-09
  • 现象：大客户异常消耗缺事前提醒和告警，事后多轮加急催办、多人并行猜测；客户内网日志需临时申请访问｜依据：「AI API」2026-07
  • 现象：对账问题排查一半无工单跟踪而中断，消费统计口径（部分生成类消费未计入）反复解释｜依据：「客户对接群（客户B）」2026-09
  • 现象：额度错充到演示机后再手工扣回，充值对象无核对｜依据：「Leap反馈群」2026-09

9. 分支变体

  • 生成失败仍扣费/冻结：确认上游失败后回滚冻结额度并补偿；长期应由代码自动回滚
  • 演示机/测试机错充：核对充值对象与设备台账，扣回后重新充值，同步财务留痕
  • 大客户异常消耗与缓存：如 Hermes 走 chat/completions 接口导致缓存参数被过滤，改用 Anthropic 类型渠道/messages 接口，并给客户发接入说明；新客户接入前先发《接入指南》
  • 企业级客户对账修复：仅修报障客户还是全量修由 CTO 决定；企业方案少删数据，改库前必须备份
  • C 端（LeapAll）与 B 端（LeapCore 实例）：C 端退款走支付渠道原路退回；B 端以企业余额为准做补额
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 主责是否为网关计费研发？是否需要设客服/客户成功岗作为统一受理人？
  • 补偿与退款的审批权限：多少额度内产品负责人可批，超出由谁批？财务由谁对接？
  • 退款与补额度的适用规则（何时原路退、何时补额度）是否已有成文口径？
  • P0 判定阈值（同时报告人数、单日消耗超常倍数）是否合适？
  • 是否立项做"客户 Key 日消耗/缓存命中率"告警和自动对账脚本，由谁排期？
  • 扣费规则（预占、最低余额、失败扣费）对外以哪份 FAQ 为准，谁维护？
X-CS-10C 端用户售后入口、退款与客诉处理待新建225

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：C 端用户（LeapAll、OPC 商城卡密、消费券等）申请或催退款、反馈卡密过期、查不到订单、找不到售后联系方式，或客诉直接打到公司人员电话时启动。
  • 负责人：主责——C 端客服/运营专员（当前：陈震·推断待确认）；协同——社区运营负责人（当前：陈梦琪·推断待确认）、电话客服（当前：胡橙橙·推断待确认）、平台开发（当前：葛家和、吴世豪、邓乾·推断待确认）、测试（当前：张东郅·推断待确认）、财务专员（当前：待指定）、外部退款审批合作方；兜底——运营负责人（当前：李凯·推断待确认）
  • 核心流程：① 统一入口受理 → ② 查单核实 → ③ 判断退款条件 → ④ 提交合作方/财务审批 → ⑤ 跟踪进度并定期回告 → ⑥ 到账确认与答复 → ⑦ 结案归档与话术更新
  • 交付结果：结案的售后工单（退款到账或给出明确不予退款理由），用户确认记录，持续更新的客服话术库。
  • 状态依据：2026-03 预售阶段才发现"没有售后"，由开发临时兼任；2026-04～07 退款依赖第三方合作方审批，用户反复催办、客诉打到公司负责人个人电话，平台展示的厂商售后联系方式曾为个人手机号；无售后文档、话术和升级路径。

1. 场景判定

  • 触发条件：
    • 用户在平台提交退款申请，或在群/电话/邮箱催退款
    • 订单状态显示"已退款"但用户称未到账
    • 卡密/消费券过期、无法兑换、查不到订单
    • 用户找不到售后入口，或社区运营发出客诉预警
  • 典型说法：「没收到退款，卡密也过期了」「退款是手动的吗」「这个人一直在催退款」「给我一个售后联系方式」
  • 判断问题：
    1. 是 C 端个人用户的订单/卡密/券问题吗？企业客户计费问题不走这里。
    2. 订单是否经第三方合作方结算（需其审批）？
    3. 用户诉求是退款、补发、兑换，还是使用问题？
  • 不归本流程管：
    • 企业客户余额、扣费、对账异常 → 请走 X-CS-09
    • 产品使用故障、登录问题 → 请走 X-CS-05 / X-CS-08
    • 俱乐部订单投诉 → 请走 X-CS-25
    • API/额度类分销订单与第三方商城上架 → 请走 SAL-26

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客服主责 受理、查单、提交审批、跟踪、答复、结案 A/R C 端客服/运营专员（当前：陈震·推断待确认）
电话客服 接听统一客服电话，登记工单 R 电话客服（当前：胡橙橙·推断待确认）
社区运营 社区内客诉预警、协助安抚与转单 C 社区运营负责人（当前：陈梦琪·推断待确认）
平台开发 查订单与退款状态、配置平台售后联系方式、修复退款链路 R 平台开发（当前：葛家和、吴世豪、邓乾·推断待确认）
测试 发版时回归退款功能 C 测试（当前：张东郅·推断待确认）
财务 自营渠道退款打款、对账 R 财务专员（当前：待指定）
合作方 经其结算的订单退款审批与执行 C 外部退款审批合作方
首接人员 接到用户电话/私信时不自行处理，转登记工单 R 接到的任何内部人员（含管理层）
兜底 超期、升级客诉、退款争议拍板 A（升级） 运营负责人（当前：李凯·推断待确认）

3. 办之前请准备

  • 订单号（如 ZNYX-日期 格式）、下单时间、商品名称、支付方式
  • 用户账号标识（UID 或注册邮箱；手机号只填工单，不在群里转发）
  • 是否已使用券/卡密、使用记录截图
  • 退款申请提交时间、平台显示的退款状态截图
  • 用户诉求（退款/补发/延期/解释）
  • 合作方当前的退款处理时限说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 统一入口受理（客服电话、售后邮箱、平台反馈入口、售后群），登记工单并告知用户受理编号 客服主责 / 电话客服 收到后 4 个工作小时内 飞书表单 → 多维表格 售后工单 🔧飞书固化
2 内部人员（含管理层）接到用户电话/私信时，不自行处理，转登记工单 首接人员（接到的任何内部人员） 当日 飞书表单 工单 🔧飞书固化
3 查单：核对订单、支付、券/卡密使用状态、退款申请时间 客服主责 + 平台开发 受理后 1 个工作日内 平台后台 查单结论 👤人工判断
4 判断：符合退款条件 → 进入审批；不符合 → 按话术说明原因；常见问题用 AI 客服先答 客服主责 查单后当日 话术库、AI 客服 处理决定 🤖+👤
5 提交审批：经合作方结算的订单提交合作方并记录提交时间；自营订单提交财务 客服主责 判断后当日 合作方渠道 / 飞书审批 审批单 🔧飞书固化
6 对用户回复：只说已确定的事实（已提交、合作方处理时限、查询方式），不承诺无法确定的到账时间 客服主责 提交后当日 话术库 回复记录 👤人工判断
7 跟踪：每 2 个工作日查一次进度并主动回告用户；超过合作方承诺时限即催办 客服主责 每 2 个工作日 多维表格提醒 跟踪记录 🔧飞书固化
8 到账确认：请用户确认到账；"已退款未到账"时核对退款流水并告知用户查询路径 客服主责 + 财务 退款执行后 2 个工作日内 支付后台 用户确认 👤人工判断
9 结案归档，新问题补进话术库；退款链路问题提缺陷，发版时回归测试 客服主责 / 测试 结案后 2 个工作日内 多维表格、Issue 话术更新、缺陷单 🤖自动化

5. 交付物与模板

  • 交付物：售后工单、退款审批记录、用户到账确认、客服话术库、平台公示的统一客服联系方式
  • 建议模板/表单「C 端售后工单」：工单号、入口渠道、用户标识、订单号、商品/券类型、是否已使用、诉求类型、退款条件判断、结算方（自营/合作方）、提交审批时间、合作方承诺时限、最近跟进时间、到账时间、用户确认、满意度
  • 建议话术：受理确认、退款已提交（含合作方时限与查询方式）、不予退款说明、到账确认、超期致歉

6. 异常与升级

  • 超过合作方承诺时限仍未退款 → 客服主责书面催办合作方 → 超期 2 个工作日升级运营负责人
  • 用户威胁投诉或在公开渠道发帖 → 当日升级运营负责人，由其统一对外回应
  • 客诉打到管理层或个人电话 → 接到人转工单，客服主责 2 小时内回电
  • 平台退款状态与实际到账不一致 → 提缺陷给平台开发，1 个工作日内给结论
  • 涉及政府补贴客户或批量用户 → 当日升级运营负责人并同步销售/生态负责人
  • A（升级）说明：C 端售后工单从受理到结案由客服主责负最终责任；退款超过合作方承诺时限 2 个工作日仍未解决、用户威胁投诉或公开发帖、退款规则存在争议、涉及政府补贴客户或批量用户时，拍板权升级到运营负责人

7. 衡量指标

  • 首次响应时长：受理到首次回复，目标 ≤ 4 个工作小时
  • 退款结案周期：申请到到账确认的自然日，目标 ≤ 合作方承诺时限 + 3 天
  • 重复催办率：同一工单用户主动催 ≥2 次的比例，目标 ≤ 10%
  • 绕过入口的客诉数：打到个人电话/私聊的客诉数，目标月度为 0

8. 低效诊断

  • 现象：预售上线前未建售后入口和联系方式，社区运营发出客诉预警后才临时指定开发兼任｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：平台展示的厂商售后联系方式为个人手机号，客诉直接打到公司负责人，再转群查单｜依据：「平台部」2026-07
  • 现象：退款最后环节由第三方合作方执行，平台无跟踪渠道，只能"催一催"，用户多次催办｜依据：「平台部」2026-07
  • 现象：订单状态显示"已退款"但用户未到账，对用户口径不一致｜依据：「平台部」2026-07

9. 分支变体

  • 已用券 / 未用券：已使用部分的退款规则需单独确认
  • 测试退款 vs 真实用户退款：测试单在发版时回归，不进入客服工单
  • 用户类型：学生用户、政府领导客户、OPC 开发者——后两者升级优先级提高一档
  • 结算方：经第三方合作方结算的订单退款由合作方审批，自营订单由财务处理

10. 待确认问题

  • C 端客服主责是否为产品/运营岗？统一客服电话和售后邮箱由谁维护？
  • 退款规则（可退条件、已用券如何退）是否有成文？由谁审批？
  • 与合作方的退款时限约定是多少天？是否写进合作协议？
  • 首次响应 4 个工作小时、每 2 个工作日回告是否可行？
  • 是否接入 AI 客服做初筛，话术库由谁维护？
X-CS-11定制客户特殊配置台账与售后范围界定待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：客户使用了魔改版本、自带模型、自接 NewAPI、本地算力路由或临时脚本等非标配置，出现问题需要判断是否属于标品售后、给出诊断报告与对客口径时启动；新增任何非标配置时也需登记。
  • 负责人：主责——Leap 研发/技术负责人（当前：王皓南·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、排查研发（当前：宋祺睿、柯逸飞·推断待确认）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 非标配置特批与登记 → ② 问题来时查台账 → ③ 判定标品/非标 → ④ 定响应优先级 → ⑤ 出诊断报告 → ⑥ 销售按统一口径对客回复 → ⑦ 收费/修复决定 → ⑧ 更新台账
  • 交付结果：定制客户特殊配置台账（客户、定制点、负责人、版本、是否收费）；每次问题对应的诊断报告与对客回复记录。
  • 状态依据：2026-09 两次集中讨论中，现有约 3 家定制客户的差异只在聊天中口头列举，内部人员不知道某客户的专家模型是否由我方提供；"魔改是否在售后范围""免费接入还是收维护费"说法不一；临时脚本无版本控制、交接时无人知道用途。

1. 场景判定

  • 触发条件：
    • 客户报错，且该客户使用了自带模型、自接 NewAPI、本地小模型路由或定制开发
    • 不确定某客户的某项配置/模型是否由我方提供和维护
    • 销售或交付拟答应客户一项非标方案
  • 典型说法：「这种特殊情况都得有个文档管一下」「自己接 API 的不用优先响应」「第一时间出报告，说明原因」「这个算魔改，不在售后范围」
  • 判断问题：
    1. 出问题的组件是否在标品交付清单内？
    2. 台账里有没有这家客户的定制记录？谁负责？
    3. 是否涉及资金损失（如缓存失效导致消耗暴涨）？涉及则不论标品与否都按紧急处理。
  • 不归本流程管：
    • 客户新定制需求的评估与报价 → 请走 X-PRD-11 / SAL-21
    • 定制需求的拆解排期与交付 → 请走 X-DLV-10
    • 客户本地 NewAPI 部署与日常维护 → 请走 X-DLV-21
    • 已交付客户提新功能 → 请走 X-CS-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账与范围主责 维护台账、判定标品/非标、定响应优先级、审核诊断报告 A/R Leap 研发/技术负责人（当前：王皓南·推断待确认）
排查研发 复现问题、出诊断报告、维护定制脚本 R 排查研发（当前：宋祺睿、柯逸飞·推断待确认）
产品负责人 对接客户需求，确认是否转标品或收维护费 C 产品负责人（当前：杨萌·推断待确认）
销售/商务 对客统一回复，沟通售后范围与收费 R 销售/商务（当前：待指定）
提出方 拟对客答应非标方案前提交特批 R 销售/研发（当前：按客户对接人）
特批人 非标方案准入、收费与免责口径拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户名称与实例/版本号
  • 报错现象、时间、请求与响应样例（脱敏）
  • 客户侧接入信息：模型来源、NewAPI 地址/渠道类型、是否经本地路由或脚本
  • 台账中该客户的定制记录与负责人
  • 合同或报价中关于售后、维护费的条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 任何非标方案先提特批，批准后登记台账；相关脚本/配置纳入 Gitea 版本管理 提出方（销售/研发）→ 特批人 对客答应前 飞书审批、多维表格、Gitea 特批记录、台账条目 🔧飞书固化
2 存量定制客户补登台账（客户、定制点、模型/部署差异、负责人、是否收费） 台账与范围主责 SOP 发布后 10 个工作日内 多维表格 完整台账 👤人工判断
3 问题进来先查台账，判定标品问题还是非标配置问题 台账与范围主责 收到后 4 个工作小时内 多维表格 判定结论 👤人工判断
4 定优先级：涉及资损的立即处理；客户自接 API 且非资损的排在标品问题之后 台账与范围主责 判定同时 工单 优先级 👤人工判断
5 复现与诊断：对比请求/响应，形成兼容性结论（问题在哪一环、是否我方组件） 排查研发 资损类当日；其他 2 个工作日内 接口调试工具、日志 诊断报告 🤖+👤
6 诊断报告经主责审核后交销售，按统一口径对客回复（陈述事实与修复计划，不推责） 台账与范围主责 → 销售 报告完成后 1 个工作日内 客户群 回复记录 👤人工判断
7 决定处理方式：标品缺陷→提单修复；非标→免费小修 / 收维护费 / 转定制项目，需特批 产品负责人 + 特批人 诊断后 2 个工作日内 飞书审批 处理决定 👤人工判断
8 更新台账（问题记录、脚本版本、负责人变化） 排查研发 处理后 1 个工作日内 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：定制客户特殊配置台账、非标方案特批记录、诊断报告、对客回复记录
  • 建议模板「定制客户台账」字段：客户、实例/版本、定制类型（自带模型/自接 NewAPI/本地模型路由/定制开发/临时脚本）、定制内容说明、脚本或配置仓库地址、技术负责人、对客负责人、是否收维护费、合同条款位置、特批记录、最近问题与日期
  • 建议模板「诊断报告」：现象、复现步骤、请求/响应对比、兼容性矩阵（我方组件/客户组件/上游）、结论、建议修复方、预计时间

6. 异常与升级

  • 非标配置导致资损（消耗异常、缓存失效）→ 立即按 X-CS-09 的 P0 处理 → 30 分钟内升级 CTO
  • 客户不接受"非标准售后范围"的结论 → 销售 1 个工作日内升级 CTO 与商务协商
  • 台账中无记录的定制配置 → 当日补登并追查谁批准，报 CTO
  • 临时脚本负责人离岗或转岗 → 交接前必须更新台账并纳入版本管理
  • A（升级）说明：台账维护、标品/非标判定和诊断报告由台账与范围主责负最终责任；新增非标方案准入、非标问题是否收费或转定制项目、客户不接受售后范围结论、非标配置导致资损时，拍板权升级到 CTO（特批人）

7. 衡量指标

  • 台账覆盖率：有非标配置的客户中已登记的比例，目标 100%
  • 诊断报告时效：问题受理到报告交付的工作日数，非资损类目标 ≤ 2 天
  • 未经特批的非标方案数：目标为 0
  • 对客口径争议次数：内部关于"谁回复、怎么说"的反复讨论次数，目标季度下降

8. 低效诊断

  • 现象：定制客户差异只在聊天里口头梳理，内部对接人不清楚某客户的模型是否由我方提供｜依据：「Leap产研决策部」2026-09
  • 现象：魔改是否属于售后、免费接入还是收维护费，内部说法不一｜依据：「Leap产研决策部」2026-09
  • 现象：客户自接 API 报错时，谁对客回复、怎样说明不是我方问题反复讨论｜依据：「Leap产研测」2026-09
  • 现象：临时路由脚本无版本控制，交接时接手人不知用途｜依据：「Leap产研测」2026-09

9. 分支变体

  • 客户自有 NewAPI 转接第三方模型：我方只诊断接口兼容，模型侧问题由客户负责
  • 本地算力经济档路由（本地模型 + 适配脚本）：脚本纳入 Gitea，由台账中技术负责人维护
  • 定制开发：单独起项目，另收维护费/FDE 费用，售后范围由商务另行约定
  • 渠道代理商客户：售后范围以代理协议为准

10. 待确认问题

  • 台账主责是否为 Leap 技术负责人，还是由产品或交付维护？
  • 非标方案特批人是否统一为 CTO？是否需要商务/法务会签？
  • 维护费、FDE 费用标准是否已有？由谁报价？
  • 对客回复统一由销售发出是否可行？没有销售对接的客户由谁回复？
  • 现有约 3 家定制客户的台账由谁在多长时间内补齐？
X-CS-12硬件设备售后、返修与上门维保待新建400

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：已交付的一体机/工作站/服务器出现故障（硬盘、掉线、网口、断电、IP 变化、无法访问），需要远程判断、上门处理、返修或换机时启动；销售一体机时界定售后责任与运维成本也按本流程的责任矩阵执行。
  • 负责人：主责——硬件运维负责人（当前：杨明学·推断待确认）；协同——现场运维/交付工程师（当前：游家豪·推断待确认）、软件运维（当前：宋祺睿、杨云峰·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、产品与交付统筹（当前：杨萌·推断待确认）、销售负责人（当前：李鹏为·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 受理登记 → ② 远程初判（硬件/软件/网络/客户操作）→ ③ 远程指导处理 → ④ 派运维上门 → ⑤ 返修判断与备机替换 → ⑥ 返厂寄送与跟踪 → ⑦ 修复验收与回寄 → ⑧ 费用与责任界定、结案
  • 交付结果：结案的硬件售后工单（故障原因、处理方式、返厂物流、费用归属、客户确认），更新后的设备台账与客户须知。
  • 状态依据：2026-07 起多次提出需要售后 SOP，08 月两次催办后仍只有两条占位内容的草稿；05～10 月客户设备掉线、IP 变化、断电无法访问等约 20 余次，每次群内临时拉人，分工靠口头约定"硬件找运维、软件找后端"；返厂地址、联系人、上门收费均未成文。

1. 场景判定

  • 触发条件：
    • 客户或内部反馈设备连不上、管理后台显示离线
    • 硬件告警：硬盘、内存、网口、电源故障，机器无法开机
    • 客户现场断电、更换网线/路由、网络施工后无法访问
    • 销售签单前需要明确硬件售后责任与年运维成本
  • 典型说法：「IP 又变了」「机器连不上了」「负责维保的同事去现场看看吧」「每年运维成本有没有估算」
  • 判断问题：
    1. 是硬件坏了、软件服务异常，还是网络/客户操作导致的离线？
    2. 设备是自销、代理商销售，还是演示/试用机？保修责任方是谁？
    3. 远程能不能解决？必须上门吗？
  • 不归本流程管：
    • 新交付设备的网络与远程接入配置 → 请走 X-DLV-16
    • 交付期（未验收）现场问题 → 请走 X-DLV-34
    • 软件功能故障、日志诊断包收集 → 请走 X-CS-06
    • 实例在线监控告警规则 → 请走 X-CS-04
    • 保修与运维边界的对外承诺口径制定 → 请走 X-DLV-30

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
售后主责 受理分派、返修判断、对接硬件厂商、结案 A/R 硬件运维负责人（当前：杨明学·推断待确认）
现场运维 上门排查、换件、备机替换、设备回收 R 现场运维/交付工程师（当前：游家豪·推断待确认）
软件运维 远程调 WG、重启服务、下发修复脚本、数据迁移 R 软件运维（当前：宋祺睿、杨云峰·推断待确认）
客户经理 约客户时间、通知客户、沟通上门费 R 销售总监/客户经理（当前：吴琪·推断待确认）
统筹 督促 SOP 与台账维护、跨团队协调 C 产品与交付统筹（当前：杨萌·推断待确认）
销售负责人 签单前确认售后责任、运维成本测算 C 销售负责人（当前：李鹏为·推断待确认）
兜底 派研发上门、费用规则、重大故障拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户名称、设备序列号/机器码、机型（工作站/服务器）、交付日期
  • 故障现象、发生时间、截图或现场照片
  • 最近是否断电、换网、移动设备、有人操作过按钮
  • 管理后台在线状态、当前 IP、WG 配置状态
  • 设备销售方式（自销/代理商）与保修期
  • 客户现场联系人与可上门时间
  • 请求最少包含字段：客户名称、设备序列号/机器码、故障现象 + 发生时间、现场照片或截图、是否断电/换网/移动过设备、销售方式与保修期、客户现场联系人与可上门时间、期望恢复时限；缺项由客户经理补齐后再登记

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 统一入口受理（售后邮箱、服务热线、反馈群），登记售后工单 客户经理 / 售后主责 收到后 2 个工作小时内 飞书表单 → 多维表格 硬件售后工单（多维表格，工单号回复客户） 🔧飞书固化
2 远程初判：查后台在线状态、IP、WG；按"硬件→售后主责，软件/网络→软件运维"分派 售后主责 受理后 2 个工作小时内 管理后台、设备台账 分类与指派（工单字段，@被指派人；超时→现场运维接手） 👤人工判断
3 远程处理：指导客户开机/拍照，远程(UU/向日葵)下发新 IP、重启服务或修复脚本 软件运维 分派后当日 远程工具、WG 处理记录（工单；未解决须写明已试步骤） 👤人工判断
4 远程无法解决 → 约客户时间，派运维上门（非必要不派研发） 客户经理 + 售后主责 本市 2 个工作日内；外省先评估寄修 飞书日历 上门安排（飞书日历邀约 + 工单登记上门人与时间） 👤人工判断
5 处理方式判断：按远程/上门排查结果分支——现场可修复（换件、改配置、恢复网络）的就地修复后转步骤 7；需厂商维修的走返修（步骤 6）；返修周期长或客户核心业务停摆的先换备机（服务器先把数据迁到库存备机）再返修；超保或无修复价值的提换机方案 售后主责 上门或远程排查结束后 1 个工作日内 设备台账、备机池 处理方式决定（工单处理方式字段；备机编号登记设备台账） 👤人工判断
6 返厂：按厂商返修清单（寄送地址、联系人、所需材料）寄出，登记物流单号 售后主责 决定后 2 个工作日内 快递月结、多维表格 物流记录（工单登记物流单号、寄出日期、厂商联系人） 🔧飞书固化
7 修复回寄或备机换回，现场或远程验收，客户确认可用 现场运维 到货后 2 个工作日内 售后工单 客户确认（工单附客户确认记录） 👤人工判断
8 责任与费用界定：质量原因免费；客户原因（断电、换网、误操作）按上门服务费标准收费 客户经理 + 兜底（CTO） 客户确认可用后 2 个工作日内 飞书审批 费用结论（飞书审批，结论回写工单） 👤人工判断
9 结案：关闭售后工单，更新设备台账（状态、IP、换件记录），新问题补进客户须知 售后主责 客户确认可用（步骤 7）且费用结论（步骤 8）确定后 1 个工作日内 多维表格、客户须知 台账与须知更新（设备台账多维表格、客户须知文档） 🔧飞书固化

5. 交付物与模板

  • 交付物：售后工单、返厂物流记录、客户确认、设备台账更新、客户须知（别断电、别换网、别按按钮等）、硬件售后责任矩阵、年运维成本测算表
  • 建议模板「硬件售后工单」字段：工单号、客户、设备序列号、机型、销售方式、保修期、故障类型（硬盘/掉线/网口/电源/IP 变化/其他）、初判分类、处理方式（远程/上门/返修/换机）、返厂物流单号、备机编号、责任归属（质量/客户原因）、是否收费、客户确认时间
  • 建议模板「售后责任矩阵」：硬件保修（硬件厂商/代理商）、软件运维与在线更新（我方）、网络环境（客户 IT）、上门服务（我方，收费条件）

6. 异常与升级

  • 客户核心业务停摆 → 当日上门或换备机 → 2 小时内升级 CTO
  • 外省客户需上门 → 先评估寄修或远程，需出差时由售后主责报 CTO 审批
  • 备机池无可用机器 → 当日通知采购补货（X-DLV-02）并告知客户预计时间
  • 同一设备 30 天内重复离线 ≥3 次 → 列为重点问题，安排固定 IP/路由器等根治方案
  • 售后主责 4 个工作小时未响应 → 由现场运维接手，同步 CTO
  • 软件运维分派后当日未处理 → 售后主责改派或自行远程处理 → 升级 CTO（次日）
  • 客户经理 1 个工作日未约到上门时间 → 售后主责直接联系客户现场联系人 → 升级销售负责人（第 2 个工作日）
  • 返厂超过厂商承诺周期 → 售后主责催厂商并告知客户新预计时间 → 超期 3 个工作日升级 CTO
  • A（升级）说明：硬件售后工单从受理到结案由售后主责（硬件运维负责人）负最终责任；客户核心业务停摆、需派研发上门或外省出差、上门费用与责任归属有争议、需制定或调整收费规则时，拍板权升级到 CTO

7. 衡量指标

  • 首次响应时长：受理到初判的工作小时数，目标 ≤ 2 小时
  • 恢复时长：受理到客户可用（含备机替换），本市目标 ≤ 2 个工作日
  • 远程解决率：无需上门即解决的比例，目标 ≥ 70%
  • 重复故障率：同一设备 30 天内再报修比例，目标 ≤ 10%
  • 返厂周期：寄出到回寄的自然日，按厂商记录统计

8. 低效诊断

  • 现象：客户设备故障时没有售后 SOP，临时救火；此后多次催办仍只有两条占位草稿，返厂寄哪、联系谁无记录｜依据：「LeapCore（archived）」2026-05
  • 现象：分工靠口头约定，一度准备派研发上门，后改为运维｜依据：「LeapCore（archived）」2026-05
  • 现象：远程排障多轮确认"开机了吗""断过电没"，缺标准问询清单｜依据：「LeapCore（archived）」2026-05；「Leap反馈群」2026-09
  • 现象：同一使用方设备 IP 反复变化约 5 次，每次重新下发配置；获取 WG 配置需临时开群找人｜依据：「Leap反馈群」2026-09、2026-10
  • 现象：售后邮箱与服务热线已建，但硬件/软件售后责任边界、客户原因是否收上门费仍停留在群内提议，无责任矩阵与收费标准｜依据：「leapcore市场对接」2026-05；「LeapCore（archived）」2026-05

9. 分支变体

  • 自销一体机：硬件保修由硬件合作厂商负责，我方负责软件运维与在线更新
  • 渠道代理商：代理商包办硬件采购、测试、销售与售后，我方只做软件支持
  • 工作站返厂 vs 服务器返厂：服务器周期长，必须先迁数据到备机
  • 公司内部/演示机：内部机器故障也走工单，但不收费
  • 客户原因 vs 质量原因：前者拟收上门服务费
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 售后主责是硬件运维负责人，还是成立专门售后团队？
  • 本市 2 个工作日上门、外省先寄修的时限是否可行？
  • 上门服务费的收费条件和标准由谁定？是否写进合同？
  • 各硬件厂商的返修地址、联系人、保修期由谁整理成清单？
  • 备机池保留几台、放在哪里、谁管理？
  • 年运维成本测算口径由谁提供给销售？
X-CS-13客户反馈转缺陷/需求与修复验收闭环待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 8 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：反馈群、客户群、试点客户、内部试用或测试中发现的问题与 badcase，需要判定是 Bug、需求、Badcase 还是定制，进入 Issue/需求池，修复后验收并回告反馈人时启动。
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——反馈值班提单人/测试（当前：黄霆瑄、张东郅、潘浩伟·推断待确认）、研发（当前：岳阳、柯逸飞、陈晖·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、一线对接人（销售/FDE/交付，当前：杜中瑞、王满、吴琪、季学森·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、运维（当前：杨明学·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 统一收集 → ② 值班人每日汇总提单 → ③ 判定 Bug/需求/Badcase/定制 → ④ 新包验证与去重 → ⑤ 分级指派或进需求池 → ⑥ 修复并指派验收人 → ⑦ 验收 → ⑧ 回告反馈人并回写状态 → ⑨ 周期复盘
  • 交付结果：每条反馈都有去向（Issue 编号、需求池条目或"不处理"理由），修复项有验收记录并已回告客户；按月输出反馈分析报告。
  • 状态依据：已有 Issue 系统、反馈群和飞书表单，且做过一次反馈群全量分析；但 2026-07～09 反复出现"反馈群 bug 没人负责提""看工单看不出是否修了""排查一半忘了""不知道怎么验收"，表单提交后无人查看，客户在群里吐槽而不提单。

1. 场景判定

  • 触发条件：
    • 客户/内部用户在反馈群、客户群、表单中报告问题或提改进
    • 试点客户使用后集中提出问题，FDE/销售带回
    • 测试或评测发现 badcase/goodcase
    • 客户现场发生故障，需要研发修复
  • 典型说法：「现在反馈群的 bug 谁负责提？」「问题请提单，只在群里说不便跟踪」「历史 badcase 梳理一下转需求和 bug」「问题已经反馈给开发了」
  • 判断问题：
    1. 这是现有功能出错（Bug）、效果不好（Badcase）、缺功能（需求），还是只对单个客户的定制？
    2. 在最新版本上还能复现吗？已有工单吗？
    3. 是否影响客户正常使用或涉及资金？涉及则走紧急工单。
  • 不归本流程管：
    • 客户问题首次受理与分流（是否售后问题）→ 请走 X-CS-05
    • 内部 dogfood 反馈收集 → 请走 X-PRD-06
    • 缺陷复现、分级与指派的研发内部规范 → 请走 RND-03
    • 客户新需求是否承诺、是否加价 → 请走 X-CS-14
    • 计费异常 → 请走 X-CS-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 定分类标准与优先级、管需求池、组织复盘 A 产品负责人（当前：杨萌·推断待确认）
值班提单人 每日汇总各渠道反馈、验证复现、提 Issue/登记需求 R 反馈值班提单人/测试（当前：黄霆瑄、张东郅、潘浩伟·推断待确认）
一线对接人 转述客户问题、补充现场信息、回告客户 R 销售/FDE/交付（当前：杜中瑞、王满、吴琪、季学森·推断待确认）
研发 修复缺陷、标注修复版本、指派验收人 R 研发（当前：岳阳、柯逸飞、陈晖·推断待确认）
技术负责人 研发侧分级与指派、工单系统规范 C 研发技术负责人（当前：王皓南·推断待确认）
产品经理 行业版需求工单整理、迭代排入 R 产品经理（当前：黄飞鹏·推断待确认）
运维 现场故障类工单协同 C 运维（当前：杨明学·推断待确认）
验收人 按验收标准在目标版本复核并给出验收结论 R 原反馈对接人或测试（由研发在工单中指派）
兜底 优先级争议、紧急插单拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 反馈来源（群名/客户/内部用户）与反馈人
  • 问题描述、截图或录屏、发生时间、操作步骤
  • 产品与版本号（LeapAll/LeapCore/行业版，客户端版本、服务端版本）
  • 客户实例或环境（测试服/正式服/私有化）
  • 是否有关联 Issue（先搜索去重）
  • 影响范围（单人/多人/全客户）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有渠道反馈汇入统一入口（反馈群机器人、飞书表单、一线转述），不接受只在私聊转达 一线对接人 收到当日 飞书表单、反馈群机器人 反馈记录 🔧+🤖
2 值班人每日汇总，AI 先做分类和去重，生成工单草稿 值班提单人 每工作日 18:00 前 多维表格、反馈整理 Skill 当日反馈清单 🤖自动化
3 判定类型：Bug / Badcase / 需求 / 定制；有争议的交主责定 值班提单人 → 流程主责 汇总后 1 个工作日内 多维表格 分类结果 👤人工判断
4 Bug：在最新包上验证，能复现则提 Issue（附复现步骤）；不确定是否已修的先验证再提 值班提单人 判定后 1 个工作日内 Issue 系统 LEAP-xxx 工单 👤人工判断
5 紧急（客户无法使用、数据或资金问题）直接提紧急工单并在研发群 @ 技术负责人 值班提单人 / 一线对接人 发现后 1 小时内 Issue 系统 紧急工单 🔧飞书固化
6 需求/Badcase/定制：登记需求池，注明来源客户；定制转 X-CS-11/X-CS-14 判断 流程主责 / 产品经理 判定后 2 个工作日内 需求池 需求条目 👤人工判断
7 分级与指派：按影响定 P0～P3，指派研发；需求进入迭代评审 技术负责人 / 流程主责 提单后 1 个工作日内 Issue 系统 指派记录 👤人工判断
8 修复后标注修复版本，指派验收人（原反馈对接人或测试），写明验收标准 研发 修复完成当日 Issue 系统 待验收工单 🔧飞书固化
9 验收：按验收标准在目标版本复核；数据类问题由业务方核对数据 验收人 指派后 2 个工作日内 目标环境 验收结论 👤人工判断
10 回告反馈人/客户，工单状态回写反馈群 一线对接人 验收通过后 1 个工作日内 反馈群、客户群 回告记录 🤖自动化
11 月度复盘：反馈量、类型分布、系统性问题、未闭环项 流程主责 每月首周 飞书 wiki 反馈分析报告 🤖自动化

5. 交付物与模板

  • 交付物：反馈登记表、Issue 工单、需求池条目、验收记录、回告记录、月度反馈分析报告
  • 建议模板「客户反馈登记」字段：编号、来源渠道、客户/反馈人类型（核心共创/普通/试点客户）、产品与版本、环境、问题描述、附件、类型（Bug/Badcase/需求/定制/goodcase）、严重度、关联 Issue/需求、指派人、修复版本、验收人、验收结果、是否已回告
  • Issue 必填项：复现步骤、期望结果、实际结果、版本、来源反馈编号、验收人、验收标准

6. 异常与升级

  • 当日反馈无人汇总 → 由流程主责指定临时值班人 → 次日仍无人升级 CTO
  • 工单 3 个工作日未指派 → 值班提单人在研发群提醒 → 再 2 个工作日升级技术负责人
  • 修复后 5 个工作日未验收 → 提醒验收人 → 升级流程主责
  • 类型或优先级争议（如"是 badcase 还是质量问题"）→ 流程主责 1 个工作日内裁定 → 仍有异议升级 CTO
  • 客户群出现同一问题多人反馈 → 按紧急工单处理并通知一线对接人统一回复
  • A（升级）说明：反馈分类标准、优先级和需求池由流程主责（产品负责人）负最终责任；类型或优先级争议经流程主责裁定后仍有异议、需要紧急插单、当日反馈连续两天无人汇总时，拍板权升级到 CTO

7. 衡量指标

  • 反馈入池率：各渠道反馈中已登记的比例，目标 100%
  • 提单时效：反馈到 Issue/需求登记的工作日数，目标 ≤ 1 天
  • 修复闭环率：已修复且完成验收与回告的比例，目标 ≥ 90%
  • 验收时效：修复到验收的工作日数，目标 ≤ 2 天
  • 重复反馈率：同一问题被多次反馈的比例，目标逐月下降

8. 低效诊断

  • 现象：反馈群的 bug 无固定提单人，客户问题由一线在群里转述后无人接｜依据：「鼎慧产研决策部」2026-07
  • 现象：工单状态看不出是否已修复，需要人工翻查｜依据：「鼎慧产研决策部」2026-07
  • 现象：历史 badcase 是否已修、跨产品线无法复现时优先级如何定，需逐条请示｜依据：「Leap产研测」2026-07
  • 现象：客户反馈散在客户群，靠个人转发截图到研发群｜依据：「工程咨询产研」2026-01
  • 现象：同类文档格式问题多次出现，内部对"是否属于 badcase"有争议｜依据：「【行业版Leapcore】工程版」2026-08、2026-09
  • 现象：故障在群里吐槽不提单；排查到一半无工单跟踪而中断；修复后不知如何验收｜依据：「LeapCore 内部用户对接群」2026-09；「客户对接群（客户B）」2026-09

9. 分支变体

  • Bug：走 Issue，修复后验收回告
  • Badcase / goodcase：沉淀到 badcase 库，按周期聚类转需求或评测集
  • 需求（如权限类）：进需求池论证；UI 定制类等开放平台能力
  • 紧急工单：客户无法使用或数据问题，跳过日汇总直接提单
  • 数据修复：按 X-CS-09 的备份与审批规则执行，由业务方核对数据验收
  • 跨产品线（LeapAll 有、LeapCore 无法复现）：降一级处理并注明

10. 待确认问题

  • 值班提单人由测试轮值还是产品轮值？每周排班谁来定？
  • Bug / Badcase / 需求 / 定制的判定标准能否成文？争议由产品负责人裁定是否可行？
  • 是否部署反馈群机器人一键生成工单草稿，工单状态自动回写反馈群？
  • 验收人默认是谁：原反馈对接人、测试还是客户方业务人员？
  • 现有飞书反馈表单是否保留，与反馈群如何合并为统一入口？
X-CS-14客户新需求承诺前可行性确认与变更响应待新建144

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：已交付客户或合作客户提出新功能、活动规则、重度使用要求，对接人准备答应或客户已在等待答复时启动；对客承诺任何非现有功能前必须先走本流程。
  • 负责人：主责——客户项目负责人（当前：徐莉〔跃竞线〕·推断待确认；Leap 线当前：待指定）；协同——一线对接人（当前：陈雁、张康·推断待确认）、技术可行性评估人（当前：丁震宇·推断待确认）、产品负责人（当前：待指定）、销售/商务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 一线不当场承诺，登记需求 → ② 判断是否 Bug / 合同范围内 → ③ 技术可行性与工作量评估 → ④ 定答复方案（做/折中/加价/拒绝）→ ⑤ 按模板对客答复 → ⑥ 进入需求池或变更报价 → ⑦ 记录承诺并跟踪兑现
  • 交付结果：每条客户新需求的可行性确认单（结论、答复口径、是否收费、负责人），以及对客的书面答复记录。
  • 状态依据：2026-01～03 至少 3 次在客户已对外宣发或已执行后才发现旧系统做不了（抽奖资格、优惠券领取条件、批量核销），只能事后折中；已交付客户持续加需求时是否响应全靠个人口头判断，内部评审流程和变更单未成文。

1. 场景判定

  • 触发条件：
    • 客户要求新增功能、改活动/规则逻辑、批量操作或定制报表
    • 客户要求在有限算力上做重量级使用
    • 对接人被问"这个能不能做""之前说过能做"
    • 客户准备对外宣发依赖某功能的活动
  • 典型说法：「之前一直说是能做」「这个功能下周要上」「我们只响应 bug，新增需求要走内部评审」「没有人力做定制」
  • 判断问题：
    1. 这是现有功能出错（Bug）还是新增能力？
    2. 是否在合同/交付清单范围内？
    3. 涉及的系统是否已冻结（只修 bug 不加功能）？
    4. 客户是否已经或即将对外宣发？
  • 不归本流程管：
    • 现有功能的缺陷修复 → 请走 X-CS-13
    • 定制需求的标品化判断与报价测算 → 请走 X-PRD-11 / SAL-21
    • 合同范围外需求的商务拦截与预期管理 → 请走 SAL-25
    • 已排入迭代后的需求变更控制 → 请走 X-PRD-29
    • 已有非标配置出问题 → 请走 X-CS-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户项目负责人 登记需求、汇总评估、确定答复方案、跟踪兑现 A/R 客户项目负责人（当前：徐莉〔跃竞线〕·推断待确认；Leap 线：待指定）
一线对接人 收集需求细节、按模板答复客户 R 一线对接人（当前：陈雁、张康·推断待确认）
技术评估人 可行性、工作量、折中方案、系统冻结判断 C 技术可行性评估人（当前：丁震宇·推断待确认）
产品负责人 判断是否纳入标品需求池 C 产品负责人（当前：待指定）
销售/商务 合同范围核对、加价报价 C 销售/商务（当前：待指定）
兜底 拒绝/特批/免费承诺拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求原话与业务目的（为什么要、给谁用）
  • 期望上线时间，是否已/将对外宣发
  • 涉及系统与版本（新系统/已冻结的旧系统）
  • 合同或交付清单中相关条款
  • 客户历史已承诺事项（避免重复或冲突）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对客只回复"已记录，评估后答复"，不当场承诺能做或时间；登记可行性确认单 一线对接人 收到需求当日 飞书表单 → 多维表格 确认单 🔧飞书固化
2 初判：Bug 转 X-CS-13；属合同范围的进入评估；超出范围标注"需报价" 客户项目负责人 登记后 1 个工作日内 合同/交付清单 初判结论 👤人工判断
3 技术评估：可行性、工作量、所涉系统是否冻结、可行的折中做法 技术评估人 初判后 2 个工作日内；客户已宣发的当日 确认单 评估结论 👤人工判断
4 定答复方案：做（排期）/ 折中（如改为人工核验）/ 加价做 / 不做；免费做或特批需兜底确认 客户项目负责人 + 兜底 评估后 1 个工作日内 飞书审批 答复方案 👤人工判断
5 按模板对客答复：Bug 才走免费修复；新增需求经内部评审后答复；算力受限时说明当前配置不支持并给出扩容选项 一线对接人 方案确定当日 回复模板 书面答复 🤖+👤
6 要做的：进需求池或变更单；需加价的转销售报价并补签 客户项目负责人 / 销售 答复后 2 个工作日内 需求池、报价单 需求条目/报价 🔧飞书固化
7 记录对客承诺（内容、时间），到期前 3 天检查兑现情况 客户项目负责人 按承诺时间 多维表格提醒 承诺台账 🔧飞书固化

5. 交付物与模板

  • 交付物：需求可行性确认单、对客书面答复、变更单或报价单、对客承诺台账、已冻结系统功能清单
  • 建议模板「需求可行性确认」字段：编号、客户、需求描述、业务目的、期望时间、是否已宣发、涉及系统、合同范围（是/否）、类型（Bug/新增/重度使用）、技术结论、工作量、答复方案（做/折中/加价/拒绝）、报价、审批人、答复时间、承诺兑现日期
  • 回复模板：已记录待评估、纳入排期、折中方案说明、需额外费用、暂不支持（含原因与替代方案）

6. 异常与升级

  • 客户已对外宣发而功能做不了 → 当日升级兜底，出折中方案并由项目负责人当面/电话沟通
  • 客户不接受"新增需求需评审/收费" → 2 个工作日内升级销售负责人与 CTO 协商
  • 客户绕过对接人直接找研发要功能 → 研发不直接答应，转回本流程登记
  • 新接手对接人口径不被客户认可 → 由项目负责人出面确认口径
  • A（升级）说明：客户新需求的登记、评估汇总和答复方案由客户项目负责人负最终责任；拟免费承诺合同范围外需求、需特批、明确拒绝重要客户、客户已对外宣发而功能做不了、客户不接受评审/收费口径时，拍板权升级到 CTO

7. 衡量指标

  • 承诺前确认率：对客承诺的新功能中经过确认单的比例，目标 100%
  • 答复时效：需求登记到对客答复的工作日数，目标 ≤ 3 天
  • 事后补救次数：承诺后发现做不了的次数，目标季度为 0
  • 免费需求占比：未收费的新增需求数/新增需求总数，按季度跟踪

8. 低效诊断

  • 现象：活动规则在客户已对内宣发后才确认旧系统不支持，只能改为核销时人工检查｜依据：「跃玩会员端」2026-03
  • 现象：优惠券领取资格、批量核销等需求事先未评估，答复为无此逻辑或无人力定制｜依据：「跃玩会员端」2026-01、2026-02
  • 现象：旧系统"只修 bug 不加功能"的规则未对外统一，对接人仍按"能做"沟通｜依据：「跃玩会员端」2026-02

9. 分支变体

  • 跃竞/跃玩线（会员端、报备系统）：旧报备系统冻结，只修 bug；新需求由项目负责人统一答复
  • LeapCore 已交付客户：已交付版本功能齐全即视为履约，新增需求走内部评审与报价
  • 算力受限的重度使用请求：说明当前配置不支持，给出扩容/升级报价
  • 活动规则、优惠券资格、批量核销、开关类权益等运营类需求：优先考虑人工折中方案

10. 待确认问题

  • Leap 线客户新需求的项目负责人是谁？是产品负责人还是销售客户经理？
  • 内部评审流程是否已有固定节奏（每周一次）？由谁主持？
  • 免费响应的边界（Bug、小改动工时上限）如何界定？
  • 已冻结系统清单由谁维护并对外公布？
  • 技术评估是否必须由 CTO 本人做，能否下放到技术负责人？
X-CS-15版本更新/停机客户通知与更新日志待优化160

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗2 × 跨5 × 险4

  • 适用场景：服务端或客户端版本上线、停机升级、额度/数据迁移等会影响客户使用时，需要提前通知销售、售后和客户群避开更新窗口，并在帮助中心发布更新日志时启动。
  • 负责人：主责——产品负责人（发版统筹）（当前：杨萌·推断待确认）；协同——产品经理（更新日志）（当前：陈震·推断待确认）、产品经理（客户群通知）（当前：黄飞鹏·推断待确认）、研发技术负责人（停机窗口）（当前：王皓南·推断待确认）、运维发版（当前：宋祺睿·推断待确认）、帮助中心部署（当前：葛家和·推断待确认）、销售（当前：杜中瑞·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 确定发版/停机窗口 → ② 起草通知与更新日志 → ③ 内部先通知销售/售后/市场 → ④ 按时限通知客户群 → ⑤ 时间变动即时补发 → ⑥ 执行更新 → ⑦ 发布完成通知与更新日志 → ⑧ 更新后 1 小时观察客户反馈
  • 交付结果：已送达所有受影响客户群的更新/停机通知（含时间窗、影响、注意事项），帮助中心更新日志，通知送达清单。
  • 状态依据：已有固定分工（统筹、写日志、发客户群），但无模板与触发条件；2026-08～09 出现停机时间窗来回改、客户通知由谁发不明、发布延迟后客户通知未同步，以及一次后台更新未通知导致客户登录失败后才发现。

1. 场景判定

  • 触发条件：
    • 计划上线新版本（全量或灰度）
    • 需要停机升级、迁移额度或数据
    • 后台热更新可能导致登录/调用中断
    • 已通知的发布时间发生变化
  • 典型说法：「在各个客户群发一下更新通知，让他们几点之后避免使用」「更新的时候会停机 30 分钟」「以后更新提前通知一下市场和售后」
  • 判断问题：
    1. 本次更新客户会不会感知（中断、重新登录、需要升级客户端）？
    2. 是否停机？停多久？
    3. 影响哪些客户（全部标品客户/私有化客户/内部 102 环境）？
  • 不归本流程管：
    • 版本封版、发布上线的研发流程 → 请走 RND-50 / RND-51
    • 更新日志内容编写规范与迭代预告 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）
    • 内测公告与内部通知分发 → 请走 X-PRD-35（版本发布公告、更新日志与迭代预告同步）
    • 已交付/演示机的版本升级与回退操作 → 请走 X-DLV-32
    • 服务迁移中的账号与余额迁移 → 请走 X-CS-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发版统筹 定发版计划、确认通知发出、跟进延期 A/R 产品负责人（当前：杨萌·推断待确认）
更新日志 起草更新日志并发布到帮助中心 R 产品经理（当前：陈震·推断待确认）
客户群通知 按清单在各客户群发通知并登记 R 产品经理（当前：黄飞鹏·推断待确认）
停机窗口 确定是否停机、窗口时长、回滚预案 C 研发技术负责人（当前：王皓南·推断待确认）
发版执行 执行升级，完成后通知统筹 R 运维发版（当前：宋祺睿·推断待确认）
帮助中心 部署帮助中心更新 R 帮助中心部署（当前：葛家和·推断待确认）
销售/售后 转告自己负责的客户，收集更新后反馈 I 销售（当前：杜中瑞·推断待确认）
兜底 未通知即更新的追责、紧急停机拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 版本号、更新内容摘要、是否需要客户端升级
  • 发布时间、是否停机及时长、预计恢复时间
  • 受影响客户清单（客户群列表、私有化客户、内部环境）
  • 客户需注意的事项（提前保存数据、避开时段、重新登录）
  • 回滚预案与延期时的通知人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发版计划确定：时间窗、是否停机、受影响范围；各需求负责人报风险 发版统筹 + 停机窗口 普通更新提前 1 个工作日；停机提前 2 个工作日 飞书任务（发版 checklist） 发版计划 🔧飞书固化
2 按模板起草客户通知（时间窗、影响、保存数据提示、更新内容、恢复时间）和更新日志 更新日志 计划确定后 4 个工作小时内 通知模板、AI 起草 通知稿、日志稿 🤖自动化
3 通知稿由统筹审核后，先在销售/售后/市场群发内部通知 发版统筹 对客通知前 飞书群 内部通知 👤人工判断
4 客户群通知：停机类提前 24 小时；普通更新提前 4 小时；逐群发送并在清单打勾 客户群通知 按左述时限 飞书/微信客户群、机器人群发 送达清单 🔧+🤖
5 发布时间变动或延期：立即补发更正通知（内部+客户群） 发版统筹 → 客户群通知 变动确定后 30 分钟内 同上 更正通知 🔧飞书固化
6 执行更新；内部环境可先升级验证 发版执行 按窗口 发布系统 发布结果 👤人工判断
7 完成后发恢复通知；发布更新日志到帮助中心；公司群同步新包 客户群通知 / 更新日志 / 帮助中心 发布完成后 1 小时内 帮助中心、飞书群 恢复通知、日志 🔧飞书固化
8 更新后 1 小时内关注客户群报错，异常转 X-CS-13 紧急工单 销售/售后 发布后 1 小时 客户群 观察记录 👤人工判断

5. 交付物与模板

  • 交付物：发版 checklist、内部通知、客户通知、更正通知（如有）、恢复通知、帮助中心更新日志、通知送达清单
  • 建议模板「停机升级通知」：标题、产品与版本、停机开始与结束时间、影响范围、需客户操作（保存数据/避开时段/升级客户端）、主要更新内容（3～5 条）、恢复后如何确认、联系人入口
  • 建议表单「通知送达清单」字段：客户/群名、通知人、预告发送时间、更正发送时间、恢复通知时间、客户回执

6. 异常与升级

  • 未发通知已开始更新 → 发版执行暂停（可暂停的情况下）并补发通知 → 当日报 CTO
  • 更新超出预计恢复时间 → 每 30 分钟向客户群更新进展 → 超 1 小时升级 CTO 决定是否回滚
  • 更新后客户批量报错 → 按紧急工单处理，统筹 15 分钟内在客户群发说明
  • 客户要求改期（重要使用时段）→ 统筹与技术负责人评估，1 个工作小时内答复
  • A（升级）说明：发版通知与更新日志由发版统筹（产品负责人）负最终责任；未发通知已开始更新、更新超出预计恢复时间 1 小时需决定是否回滚、需要紧急停机时，拍板权升级到 CTO

7. 衡量指标

  • 提前通知达标率：按时限（停机 24 小时/普通 4 小时）通知的发版次数占比，目标 100%
  • 客户群覆盖率：送达清单中已通知群数/受影响群数，目标 100%
  • 未通知导致的客诉数：每月目标 0
  • 更新日志及时率：发布后 1 小时内上线日志的比例，目标 ≥ 95%

8. 低效诊断

  • 现象：后台更新前未通知市场和售后，客户登录失败后才发现是在更新｜依据：「客户对接群（客户C）」2026-09
  • 现象：停机时间窗来回修改，对内只能通知销售，对客户由谁发不明确｜依据：「Leap产研决策部」2026-08
  • 现象：发布时间变动后客户通知未同步，客户已被告知而全量未发；新包发布需反复催｜依据：「Leap产研测」2026-09
  • 现象：每次现写通知，无模板；客户逐个询问后才说明｜依据：「Leap产研决策部」2026-08；「客户对接群（客户B）」2026-09

9. 分支变体

  • 停机升级（如需迁移额度）vs 无停机更新：前者提前 24 小时并写明保存数据提示
  • 全量 vs 灰度：灰度只通知灰度范围内客户；内部环境先升级
  • 客户群类型：飞书外部群、微信群；微信群暂需人工发送
  • 私有化客户：不随公有云发版，按 X-DLV-32 单独约时间

10. 待确认问题

  • 客户群通知是否统一由一人发，还是各销售/对接人负责各自客户群？
  • 停机提前 24 小时、普通更新提前 4 小时的时限是否合适？
  • 是否用飞书机器人按模板群发，微信客户群如何覆盖？
  • 是否建立发布日历，让销售和售后能自助查看更新计划？
  • 热更新（无感更新）何时可实现？实现前哪些更新可以免通知？
X-CS-16服务迁移中的客户账号与余额迁移待新建200

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：测试服转正式服、旧网关（如旧 NewAPI）下线切换到新网关、服务器迁移或服务停用时，需要迁移客户账号、数据、余额并统一对外口径、提前通知客户时启动。
  • 负责人：主责——发起迁移的技术负责人（当前：王皓南·推断待确认）；协同——对外口径收口（当前：韩诗琪·推断待确认）、产品负责人（当前：杨萌·推断待确认）、额度迁移管理员（当前：邓乾〔LeapAll〕、柯逸飞〔LeapCore/网关〕·推断待确认）、运维（当前：宋祺睿·推断待确认）、销售负责人（当前：李鹏为·推断待确认）、测试（当前：张东郅·推断待确认）、定制软件负责人（当前：望政韬·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 依赖与客户盘点 → ② 定迁移方案与继承规则 → ③ 定对外口径与 FAQ → ④ 提前通知客户（含截止日）→ ⑤ 迁移账号/余额并核对总额 → ⑥ 灰度关停旧服务 → ⑦ 观察期 → ⑧ 销毁旧资源并登记
  • 交付结果：迁移完成且余额核对一致的客户清单、已送达的客户通知与 FAQ、旧资源下线与销毁记录、新的系统负责人边界。
  • 状态依据：2026-05～06 测试服与正式服账号、积分不互通，外部用户误用测试服、兑换码用错环境、充值额度"谁来管"反复出现；2026-08 旧网关关闭渠道前未通知客户导致调用失败，余额转出又转回，事后才开会明确负责人；迁移前无盘点、无口径、无检查清单。

1. 场景判定

  • 触发条件：
    • 内测/测试服停用或用户需转到正式服
    • 旧网关、旧服务下线，客户仍在调用
    • 服务器降级、迁移或资源释放
    • 新旧环境账号、余额、数据不互通，客户来问
  • 典型说法：「内测充了钱，转正式服后额度谁来管」「迁移需要有 SOP，避免客户反复来问」「我需要把旧服务的依赖迁走」「数据全没了」
  • 判断问题：
    1. 有哪些客户/用户还在用旧环境？是否有余额、积分或数据？
    2. 哪些东西继承、哪些不继承？客户需要做什么？
    3. 旧资源下线后能否恢复（是否有回收站/观察期）？
  • 不归本流程管：
    • 产品改版导致的数据迁移与版本切换 → 请走 X-PRD-33
    • 普通版本更新/停机通知 → 请走 X-CS-15
    • 机房/服务器停机维护与故障应急 → 请走 X-SEC-29
    • 云资源闲置盘点与回收 → 请走 X-SEC-22
    • 迁移后单个客户余额异常 → 请走 X-CS-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
迁移主责 依赖盘点、迁移方案、关停节奏、跟到销毁 A/R 发起迁移的技术负责人（当前：王皓南·推断待确认）
对外口径收口 统一话术、FAQ、对客通知 R 对外口径收口（当前：韩诗琪·推断待确认）
产品负责人 继承规则、充值额度处理细则审核 C 产品负责人（当前：杨萌·推断待确认）
额度迁移管理员 账号与余额迁移、核对总额 R 额度迁移管理员（当前：邓乾〔LeapAll〕、柯逸飞〔LeapCore/网关〕·推断待确认）
运维 服务器降级、关机观察、销毁与待办登记 R 运维（当前：宋祺睿·推断待确认）
销售负责人 政企/试点客户同步与重装安排 R 销售负责人（当前：李鹏为·推断待确认）
测试 迁移方案验证、环境标识核对 C 测试（当前：张东郅·推断待确认）
定制软件负责人 非标客户定制部分的迁移配合 C 定制软件负责人（当前：望政韬·推断待确认）
兜底 迁移窗口、对客沟通、资源销毁拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 旧环境调用方清单：客户、账号/UID、Key、调用量、余额/积分
  • 新旧环境地址与环境标识（测试服/正式服域名、新旧网关地址）
  • 继承规则：账号、数据、余额、积分各自是否迁移，客户需做的操作（备份、重装、换地址）
  • 非标客户与定制部分负责人（查 X-CS-11 台账）
  • 旧资源清单（服务器、数据库、redis、域名）与回滚方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 依赖盘点：从日志拉取旧环境近 30 天调用方与余额，形成客户清单 迁移主责 + 额度迁移管理员 关停前至少 10 个工作日 网关日志、数据库 迁移客户清单 🤖自动化
2 定方案：继承规则、迁移方式（批量脚本/人工）、关停时间表、回滚预案；指定各系统负责人 迁移主责 + 产品负责人 盘点后 2 个工作日内 飞书文档 迁移方案 👤人工判断
3 方案审批：涉及客户余额或关停对外服务的需 CTO 确认 兜底 方案提交后 1 个工作日内 飞书审批 审批记录 🔧飞书固化
4 定口径：话术、FAQ（继承什么、客户怎么做、截止日、联系谁），经产品负责人审核，审核前不外发 对外口径收口 审批后 2 个工作日内 飞书文档 话术与 FAQ 🤖+👤
5 通知客户：先内部销售/售后，再逐个客户群/试点单位通知，登记送达 对外口径收口 + 销售负责人 关停前至少 5 个工作日 客户群、送达清单 通知记录 🔧飞书固化
6 迁移账号/余额：按清单批量迁移，核对迁移前后总额一致；客户需提供新环境账号的单独收集 额度迁移管理员 通知后、关停前完成 管理后台、迁移脚本 迁移核对表 👤+🤖（批量脚本）
7 灰度关停：先关新增入口，再关调用；关停后 24 小时内监控失败调用并逐个联系 迁移主责 按时间表 网关日志 关停记录 👤人工判断
8 观察期：旧服务器先关机不删，观察至少 7 天无依赖 运维 关停后 7 天 云控制台 观察记录 👤人工判断
9 销毁资源并登记；新旧环境加醒目环境标识；更新资产与负责人台账 运维 + 迁移主责 观察期结束后 2 个工作日内 飞书待办、资产台账 销毁记录 🔧飞书固化

5. 交付物与模板

  • 交付物：迁移客户清单、迁移方案、话术与 FAQ、通知送达清单、迁移核对表、关停与销毁记录、更新后的负责人台账
  • 建议模板「迁移下线检查清单」：依赖盘点 → 方案审批 → 口径审核 → 客户通知（送达率）→ 余额迁移核对 → 灰度关停 → 观察期 → 销毁登记，每项写负责人和完成时间
  • 建议表单「迁移核对表」字段：客户/UID、旧环境余额/积分、新环境账号、迁移后余额、差额、操作人、客户确认

6. 异常与升级

  • 关停后出现未登记的调用方失败 → 立即恢复旧渠道或回补余额 → 1 小时内升级 CTO 并补通知
  • 迁移前后余额总额不一致 → 暂停迁移，额度迁移管理员核对 → 当日报 CTO
  • 客户无法在截止日前完成迁移 → 销售负责人申请延期，由 CTO 决定是否保留旧环境
  • 迁移过程中发现负责人边界不清（无人认领某客户或某系统）→ 当日由 CTO 指定
  • 资源销毁后发现仍有依赖 → 从回收站恢复，复盘盘点遗漏原因
  • A（升级）说明：迁移从盘点到销毁由迁移主责负最终责任；方案涉及客户余额或关停对外服务、迁移前后余额总额不一致、客户申请延期保留旧环境、负责人边界不清需指定、关停后出现未登记调用方失败时，拍板权升级到 CTO

7. 衡量指标

  • 通知覆盖率：已通知客户数/盘点客户数，目标 100%
  • 余额迁移准确率：迁移后差额为 0 的客户比例，目标 100%
  • 迁移相关客诉数：迁移期间因未通知或余额问题的投诉，目标 0
  • 环境混淆反馈数：用户用错环境的反馈次数，迁移后逐月下降

8. 低效诊断

  • 现象：测试服转正式服时，客户端是覆盖还是共存、账号余额是否继承，内部说法互相矛盾；对外收口人迟迟未指定｜依据：「跃迁AI总动员」2026-06
  • 现象：测试服充值额度迁移无人负责，靠用户追问后临时指定管理员人工迁移｜依据：「Leap反馈群」2026-06
  • 现象：网页端无环境标识，同一手机号在两个环境各有账号，用户反复混淆；兑换码用错环境｜依据：「Leap反馈群」2026-06；「LeapPPT」2026-05
  • 现象：测试服拦截一刀切，把公司内部用户也拦掉，再改用使用码｜依据：「LeapPPT」2026-05
  • 现象：旧网关关渠道前未通知客户，导致调用失败，余额转出又转回｜依据：「AI API」2026-08
  • 现象：客户相关系统边界不清（谁负责网关、定制软件），事后开会才划分｜依据：「AI API」2026-09

9. 分支变体

  • 测试服 → 正式服：数据由用户自行备份导入，有充值的由管理员迁移额度；客户端与网页端需显示环境标识
  • 政府/试点单位试用版：由销售负责人逐家同步并安排重装
  • 旧网关 → 新网关：标品客户批量迁移；非标客户按 X-CS-11 台账由对应负责人迁移
  • 服务器降级与释放：先关机观察，销毁有回收站兜底
  • 内部同事：只需公告，无需逐个通知

10. 待确认问题

  • 迁移主责是否默认为发起下线/迁移的技术负责人？
  • 对外口径收口人是否固定为销售运营岗？
  • 关停前 10 个工作日盘点、5 个工作日通知、7 天观察期是否合适？
  • 余额迁移是否允许折算？例外情况由谁审批？
  • 测试服的对外策略（白名单、使用码、IP 跳转）最终采用哪一种？
X-CS-17对外沟通口径、FAQ 话术与对外信息脱敏待新建160

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗2 × 跨5 × 险4

  • 适用场景：客户或销售/渠道问“为什么慢/贵/失败”“选哪个模型”“支不支持某环境/某功能”、需要解释数据异常，或要把内部截图/通知转给客户时，先查 FAQ 口径库，查不到再按本流程定口径，对外内容先脱敏
  • 负责人：主责——FAQ/口径库维护人（产品，当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售/渠道负责人（当前：闫登辉·推断待确认）、CI/LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 查 FAQ 口径库 → ② 未命中则提口径申请 → ③ 研发核对技术事实 → ④ 口径负责人定稿 → ⑤ 对外回复（含脱敏检查）→ ⑥ 入库并通知销售/渠道 → ⑦ 每次发版复核
  • 交付结果：一条已入库、标注适用范围与生效日期的 FAQ 口径；一次符合口径、已脱敏的对外回复
  • 状态依据：话术散落在多个群，模型档位口径 08～10 月变化约 6 次；同类问题（root、Win7、集群、响应慢）反复临时讨论约 7 次；2026-09 出现内部通知含激活码被转发给客户、客户误入他人实例的事故；FAQ 文档只被口头提及，未见落地

1. 场景判定

  • 触发条件：客户/渠道提出性能、价格、模型选择、数据安全、记忆与存储、技术文件、兼容环境（Win7、鸿蒙、超融合、多机集群、OA 对接、MCP）、root 权限等问题；客户质疑数据对不上需要解释；准备把内部截图、通知、文档转给客户或客户群
  • 典型说法：「我可以这样说吗？」「得跟市场那边统一口径」「只回官方回复」「得加进 FAQ 文档里」「专家其实就比标准贵一点点」「为什么你们把公司群的截图直接发给客户」
  • 判断问题：这个问题对外回答后会不会形成承诺（支持/不支持、价格、时效、补偿）？FAQ 里有没有现成口径？要发出去的内容是否来自内部群或后台？
  • 不归本流程管：具体故障排查与日志收集 → 请走 X-CS-06；计费扣费异常核查与退补 → 请走 X-CS-09；客户提出新功能/定制需求 → 请走 X-CS-14 或 SAL-21；品牌用语与宣发文案合规 → 请走 BRD-14；客户索要 root/管理员账号的审批 → 请走 X-SEC-07；密钥泄露后的轮换处置 → 请走 X-SEC-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
FAQ/口径库维护人 维护口径库、起草新口径、发布与通知、发版复核 R 产品（当前：杨萌·推断待确认）
研发负责人 核对技术事实，确认“支持/不支持/需 FDE” C Leap 研发负责人（当前：王皓南·推断待确认）
客户端核心研发 模型档位、性能与客户端相关口径的技术确认 C 客户端核心研发（当前：岳阳·推断待确认）
测试负责人 涉及性能对比、兼容性的实测数据 C 测试负责人（当前：张东郅·推断待确认）
CTO 新类型口径、涉及承诺/价格/补偿的口径拍板 A CTO（当前：丁震宇·推断待确认）
销售/渠道 提口径申请、按口径对外回复、反馈客户新问题 R（对外回复） 销售/渠道负责人（当前：闫登辉·推断待确认）
内部通知发布人 内部通知标注“仅内部”、敏感信息打码 R（脱敏） CI/LeapVPN 负责人（当前：吴世豪·推断待确认）
运维/研发一线 不在客户群直接回答口径类问题，转口径负责人 I 各研发成员

3. 办之前请准备

  • 客户原话截图或文字（去掉客户名称与联系人）、客户类型（渠道客户 IT/终端企业/政府/C 端）
  • 客户使用的产品与版本（LeapCore/LeapAll）、模型档位、部署形态
  • 已查过的 FAQ 条目链接（证明未命中或口径过期）
  • 自己拟的回复草稿
  • 要外发的截图/文档原件，标出其中可能的敏感项（激活码、后台地址、账号、内部群名、其他客户信息）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按关键词查 FAQ 口径库，命中则直接按口径回复客户 销售/渠道 收到问题后 30 分钟内 飞书多维表格 FAQ + 群机器人检索 对外回复 🔧+🤖
2 未命中：在口径申请表提交（客户原话、类型、草稿），客户侧先回“已收到，正在确认” 销售/渠道 收到问题后 1 小时内 飞书表单 口径申请记录 🔧飞书固化
3 AI 基于口径库与产品文档生成候选口径 口径维护人 申请提交后 2 小时内 LeapCore/AI 助手 口径草稿 🤖自动化
4 研发核对技术事实，标注“支持/不支持/需 FDE/需付费定制” 研发负责人或客户端核心研发 1 个工作日内 申请表评论 技术确认 👤人工判断
5 涉及承诺、价格、补偿、新类型问题由 CTO 拍板；其余口径维护人直接定稿 口径维护人，CTO 技术确认后 0.5 个工作日内 申请表 定稿口径 👤人工判断
6 对外回复前做脱敏检查：去掉激活码、后台地址、账号、内部群名、其他客户信息 销售/渠道（对外回复人） 每次外发前 脱敏检查清单 已脱敏内容 🔧+👤
7 定稿口径入库（适用范围、生效日期、负责人），推送到销售/渠道通知群 口径维护人 定稿当天 多维表格 + 群机器人 FAQ 条目、通知 🔧飞书固化
8 每次发版或模型档位/价格变化时复核相关条目，过期条目下线 口径维护人 发版后 2 个工作日内 多维表格“复核日期”字段 更新记录 🔧+🤖

5. 交付物与模板

  • 交付物：FAQ 口径库（多维表格）、口径申请记录、对外回复、发版复核记录
  • 建议模板/表单：
    • FAQ 口径字段：问题分类（性能/价格/模型选择/兼容环境/数据安全/记忆存储/技术文件/补偿）、标准问法、对外口径、禁止说法、适用客户类型、适用产品与版本、是否需 FDE、技术确认人、拍板人、生效日期、下次复核日期、状态（有效/过期）
    • 口径申请表字段：申请人、客户类型、客户原话（已去名）、产品与版本、草稿回复、紧急程度、期望回复时间
    • 脱敏检查清单：激活码/授权码、后台/管理地址、账号密码、内部群名与人名、其他客户名称与数据、价格底价、未发布功能
    • 内部通知模板：标题前缀“【仅内部】”，敏感字段默认打码

6. 异常与升级

  • 客户催促且口径 1 个工作日内定不下 → 先发“正在核实，X 点前回复”的过渡口径 → 升级 CTO（当天）
  • 发现已对外说过与事实不符的口径（如对不支持项说了“支持”）→ 口径维护人拟更正说明，销售当面/电话修正 → 升级 CTO（发现当天）
  • 内部信息（激活码、后台、账号）已外发 → 立即撤回消息、作废并更换激活码 → 按 X-SEC-11 处置，同时报 CTO（1 小时内）
  • 客户要求补偿 → 不先承诺，先收日志定位，确认解决不了再按补偿规则报批 → 升级 CTO（1 个工作日内）
  • 运维/研发在客户群被直接追问 → 只回“已收到，同事稍后统一答复”，转口径维护人 → 当天处理

7. 衡量指标

  • FAQ 命中率：销售/渠道提问中直接命中口径库的比例，目标 ≥ 70%
  • 新口径定稿时长：申请提交到定稿的工作小时数，目标 ≤ 8 小时
  • 口径更正次数：因对外说法与事实不符而发出更正的次数，目标每月 0
  • 对外信息泄露事件数：激活码、后台信息等外泄次数，目标 0
  • 口径过期率：超过复核日期仍未复核的条目占比，目标 ≤ 10%

8. 低效诊断

  • 口径只在群聊里口头给出，没有沉淀，同类问题（root、Win7、集群、MCP）每次重新讨论｜依据：「Leap产研决策部」2026-09、「Leap产研决策部」2026-10
  • 模型档位推荐口径随版本反复变化，销售拿到的说法前后不一致，有人要求“严肃复制并转发”｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 对外解释数据异常前需在群里临时问“这样说行吗”，回复时效依赖研发是否在线｜依据：「Leap产研决策部」2026-08
  • 是否补偿没有规则，回复前临时争论｜依据：「鼎慧产研决策部」2026-06
  • 运维/研发直接在客户群回答，产品名称和功能说法与市场不一致｜依据：「忠橙星行星引擎」2026-05、「忠橙星行星引擎」2026-07
  • 内部通知与对外资料没有分级，未打码的内部截图被转给客户，事后才补规则｜依据：「Leap产研测」2026-09

9. 分支变体

  • 渠道客户 IT（“技术懂哥”）：只回官方口径，不展开技术细节；root 一律不开放，按 X-SEC-07 处理
  • 终端企业客户：用业务语言回答（如“都支持，部分需要 FDE 定制”），避免技术名词
  • OA 对接：企业微信等标准对接与自有 OA 区分，后者标注“需 FDE”，转 X-FDE-03
  • 模型档位选择：按“演示/普通任务/复杂任务”给推荐，同时说明成本、速度、质量三者取舍
  • 数据异常解释（账单/列表对不上）：先由研发确认事实，再出口径
  • 内部通知发布范围：管理员群可含敏感信息但需打码；全员群不发 VPN、激活码等内部信息；客户群只发脱敏后的正式口径

10. 待确认问题

  • 口径库主责放在产品还是售后/客户成功岗位？是否需要单设客户成功负责人？
  • 哪些口径必须 CTO 拍板（价格、补偿、支持范围），哪些产品可直接定？
  • 新口径 1 个工作日内定稿是否可行？
  • 补偿规则（是否补、补多少、谁批）是否已有成文制度？
  • 已提到的“FAQ 文档”是否存在，链接在哪里，是否可直接作为口径库底稿？
  • 与 SAL-10、BRD-14 的边界：销售侧口径统一与本流程是否合并维护？
X-CS-18帮助中心、使用手册与交付注意事项维护待优化135

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：客户/员工索要使用手册，客户或销售反馈帮助中心内容缺失、过时，交付现场或售后反复遇到同类使用问题（登录、网口、IP、飞连）时，更新帮助中心与交付注意事项手册并发布
  • 负责人：主责——帮助中心内容负责人（产品，当前：杨萌·推断待确认）；协同——交付部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、销售（当前：杜中瑞·推断待确认）、测试负责人（当前：张东郅·推断待确认）、运营（当前：待指定）、生态市场总监（当前：许君·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 收集问题与内容需求 → ② 分类（帮助中心/注意事项手册/运营推文/转研发）→ ③ 撰写或修订 → ④ 技术核对 → ⑤ 发布并更新入口 → ⑥ 通知销售与交付 → ⑦ 每迭代复核
  • 交付结果：已更新的帮助中心页面与交付注意事项手册（含版本号与更新日期），并在产品内、交付群公布入口
  • 状态依据：已有帮助站（help.leapall.cn、help.leapcore.cn）和交付 SOP、飞连文档，但帮助中心被指“好久没更新”，入口不为人知；IP、网口、飞连登录等问题 07～10 月反复出现，文档不够详细被客户误读

1. 场景判定

  • 触发条件：有人索要产品使用手册；客户/销售反馈帮助中心找不到答案或内容过时；同一使用问题 2 周内出现 ≥ 2 次；交付现场培训发现共性操作问题；新版本发布涉及操作变化
  • 典型说法：「来个产品使用手册，help 网站有没有」「交付遇到的问题都维护在注意事项手册上，持续迭代」「你的文档这块不太详细」「得让以后个人买的都能解决」
  • 判断问题：这个问题是“不会用/找不到说明”，还是“功能本身有缺陷”？答案是否适合长期放在帮助中心，还是只是一次性的活动宣传？
  • 不归本流程管：功能缺陷（网盘、文件选择器异常）→ 请走 X-CS-13；活动、新功能宣传推文 → 请走 OPS-18；版本更新日志 → 请走 X-PRD-35；交付现场培训本身的组织 → 请走 X-DLV-28；对外 FAQ 口径 → 请走 X-CS-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
帮助中心内容负责人 分类判定、撰写修订、发布、迭代复核 R/A 产品（当前：杨萌·推断待确认）
交付部署工程师 汇总交付现场问题、提供截图与步骤、维护注意事项手册条目 R（手册条目） 交付部署工程师（当前：游家豪·推断待确认）
IT 运维 网络、飞连、远程访问类文档的技术核对与改写 C IT 运维（当前：杨明学·推断待确认）
销售 收集客户（含个人用户）使用问题并提交 R（提交） 销售（当前：杜中瑞·推断待确认）
客服 汇总售后/值班中遇到的共性使用问题并提交 R（提交） 客服/售后值班（当前：待指定）
测试负责人 按文档实操验证步骤可行 C 测试负责人（当前：张东郅·推断待确认）
运营 承接宣传类内容出推文 C 运营（当前：待指定）
生态市场 面向渠道/个人用户的说明书形态建议 C 生态市场总监（当前：许君·推断待确认）
CTO 帮助中心与手册归口争议拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 问题描述、出现次数、客户类型（企业交付/渠道自装/个人家庭部署）
  • 现场截图、报错信息、操作步骤（去掉客户名称、IP 地址、账号与激活码）
  • 当前帮助中心或手册中相关页面链接（如有）
  • 涉及的产品版本号
  • 已有交付 SOP、飞连文档链接，确认是修订还是新增

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过统一表单提交内容需求或共性问题（不走私聊） 销售、交付部署工程师、客服 问题发生后 1 个工作日内 飞书表单 → 多维表格 内容需求记录 🔧飞书固化
2 分类：帮助中心/注意事项手册/运营推文/转研发缺陷 帮助中心内容负责人 提交后 1 个工作日内 多维表格 分类结果与去向 👤人工判断
3 基于问题库与竞品文档生成初稿 帮助中心内容负责人 分类后 2 个工作日内 AI 助手 + 帮助中心后台 文档初稿 🤖自动化
4 技术核对（网络/飞连类由 IT 运维，其余由研发）并按步骤实操验证 IT 运维、测试负责人 初稿后 1 个工作日内 测试设备 核对意见 👤人工判断
5 发布到帮助中心/手册，写版本号与更新日期 帮助中心内容负责人 核对通过当天 帮助中心、飞书 wiki 已发布页面 🔧飞书固化
6 在产品内“帮助”入口、交付群公告、销售群同步链接 帮助中心内容负责人 发布当天 群机器人 发布通知 🔧+🤖
7 交付现场培训结束时，把客户新提问补进注意事项手册 交付部署工程师 交付后 2 个工作日内 注意事项手册 手册新增条目 👤人工判断
8 每个迭代发版前按 checklist 复核受影响页面 帮助中心内容负责人 发版前 1 个工作日 发版 checklist 复核记录 🔧飞书固化

5. 交付物与模板

  • 交付物：帮助中心页面、交付注意事项手册、个人用户部署说明书、内容需求台账、发版复核记录
  • 建议模板/表单：
    • 内容需求表字段：提交人、来源（客户/销售/交付/内部）、客户类型、产品与版本、问题描述、出现次数、截图、分类、去向、负责人、发布链接、关闭日期
    • 注意事项手册条目字段：场景（企业交付/渠道自装/家庭部署）、现象、原因、处理步骤、预防提示、适用版本、更新日期
    • 帮助中心页面头部：适用产品与版本、最后更新日期、负责人岗位

6. 异常与升级

  • 帮助中心与运营推文边界争议 → 按“长期可查=帮助中心，阶段性宣传=推文”判定 → 仍有争议升级 CTO（1 个工作日内）
  • 同一问题 1 个月内复发 ≥ 3 次且已有文档 → 判断是否产品体验问题，转 X-CS-13 → 升级 CTO（发现当周）
  • 客户误读文档导致操作失败 → 当天改写相关段落并补截图 → 通知交付与销售群
  • 帮助站无法访问或入口失效 → 转运维排查 → 当天恢复
  • A（升级）说明：内容分类、撰写与发布由帮助中心内容负责人最终负责；帮助中心与运营推文/手册的归口边界有争议，或同一问题 1 个月内复发 ≥ 3 次需判断是否转产品体验问题时，拍板权升级到 CTO

7. 衡量指标

  • 内容需求处理周期：提交到发布的工作日，目标 ≤ 5 个工作日
  • 帮助中心时效：发版后 2 个工作日内完成复核的版本占比，目标 100%
  • 共性问题复发率：已入手册问题在 1 个月内再次被咨询的次数，目标逐月下降
  • 交付注意事项新增率：每次交付后补充条目的比例，目标 ≥ 80%

8. 低效诊断

  • 客诉入口分散在微信、群、私聊，帮助中心缺少统一需求入口｜依据：「鼎慧产研决策部」2026-08、「鼎慧产研决策部」2026-09
  • 帮助中心与运营推文职责边界不清，内容长期未更新｜依据：「鼎慧产研决策部」2026-09
  • 帮助站已存在但入口未宣传，使用者需要在群里问地址｜依据：「跃迁AI总动员」2026-08
  • 交付问题（IP、网口、飞连登录）每次单独处理，“头疼医头”，文档细节不足被误读｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-10

9. 分支变体

  • 企业交付：现场约 20 分钟基础培训，按交付 SOP 五步（客户设备、先演示、客户操作、讲异常、验收并更新手册），培训后更新手册
  • 渠道自装：手册需包含装机、联网、注册全流程，面向非技术人员
  • 个人家庭部署：单独出说明书，重点写网口接路由器、IP 变化、远程访问激活码使用
  • LeapAll 与 LeapCore 分站维护（help.leapall.cn / help.leapcore.cn），注意不要混用

10. 待确认问题

  • 帮助中心主责是否确定为产品？与 OPS-03、X-PRD-36 是否合并为一条？
  • 交付注意事项手册的主维护人是交付部署工程师还是产品？
  • 个人用户说明书由谁出、何时出？
  • 帮助中心更新是否纳入每个迭代的发版 checklist？
  • 内容需求统一表单是否可与客户问题受理入口（X-CS-05）共用？
X-CS-19重点客户回访与使用推进待优化135

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：重点客户交付上线后，按固定节点回访；或发现客户关键使用人（尤其决策人）没用起来、商务推进被卡时，安排客访推动使用，并把反馈分类传回产品
  • 负责人：主责——客户经理（当前：按客户分配，吴琪、杨朋伟·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、CTO（当前：丁震宇·推断待确认）；兜底——市场销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 交付后建回访计划 → ② 看后台使用数据 → ③ 按节点回访/客访 → ④ 填回访记录 → ⑤ 反馈分类并转产品 → ⑥ 制定推进动作 → ⑦ 回告客户更新 → ⑧ 月度复盘
  • 交付结果：每个重点客户的回访记录（多维表格）、反馈处理去向、使用推进动作及结果
  • 状态依据：已有回访文档和 badcase 登记表雏形，但回访频率、责任人、闭环未固定；政府客户“领导没用起来”被反复追问约 6 次，培训由谁去不清；反馈散在群消息与文档中

1. 场景判定

  • 触发条件：重点客户交付上线满 7/14/30 天；客户后台活跃度连续 7 天低于约定阈值；商务侧反馈客户决策人未使用；产品有客户相关的重要更新；付费用户首次充值
  • 典型说法：「刚刚和客户做了一个使用回访」「领导还是没用起来」「不用催，但是你得做一下客访」「目标就是尽快让领导本人用」
  • 判断问题：客户是否已交付上线？问题是“没用起来/不会用”，还是“功能坏了”？
  • 不归本流程管：客户报故障 → 请走 X-CS-05；客户提出新需求 → 请走 X-CS-14；客户反馈转缺陷/需求的闭环 → 请走 X-CS-13；部署后试点陪跑与分层培训 → 请走 X-FDE-11；C 端付费用户挽留 → 请走 OPS-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户经理 制定回访计划、执行回访与客访、填记录、回告客户 R/A 客户经理（当前：吴琪、杨朋伟·推断待确认）
产品总监 接收反馈、分类登记 badcase、优秀案例并入培训演示 R（反馈处理） 产品总监（当前：杨萌·推断待确认）
产品经理 跟进具体客户的测试计划与需求 C 产品经理（当前：黄飞鹏·推断待确认）
业务专家 行业客户的使用培训、业务场景演示 C 工程咨询业务专家（当前：王满·推断待确认）
交付部署工程师 上门部署、环境类问题处理 C 交付部署工程师（当前：游家豪·推断待确认）
CTO 推进策略（是否加送额度、补设备、升级模型）拍板，产品定位决策 A（升级） CTO（当前：丁震宇·推断待确认）
市场销售负责人 兜底、决策人层面沟通策略 C 市场销售负责人（当前：李鹏为·推断待确认）

3. 办之前请准备

  • 客户台账：合同范围、交付日期、席位与额度、关键使用人与决策人角色（不写个人联系方式到群里）
  • 后台使用数据：近 7/30 天活跃人数、调用次数、主要功能使用情况
  • 上次回访记录与未关闭事项
  • 本期产品更新清单（可以告诉客户的新功能）
  • 可动用的推进资源及审批情况（赠送额度、补设备、升级模型）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 交付验收后建回访计划（7/14/30 天节点，之后每月 1 次） 客户经理 验收后 2 个工作日内 多维表格 + 飞书任务提醒 回访计划 🔧飞书固化
2 每周拉取客户后台活跃度，低于阈值自动提醒 客户经理 每周一 后台使用日志 + 机器人 活跃度周报 🤖自动化
3 按节点回访（电话/线上/上门），决策人未使用时做客访：告知更新、现场演示、约试用 客户经理，业务专家 节点当天 ±2 个工作日 飞书会议/上门 回访纪要 👤人工判断
4 填回访记录模板 客户经理 回访后 1 个工作日内 多维表格 回访记录 🔧飞书固化
5 反馈分类（缺陷/需求/定制/咨询/优秀案例），AI 预分类后产品确认 产品总监 记录提交后 2 个工作日内 多维表格 + AI 分类结果 🔧+🤖
6 缺陷进 badcase 表、需求转 X-CS-14、优秀案例转 X-CS-20 产品总监 分类当天 多维表格 处理去向 🔧飞书固化
7 制定推进动作（培训、加送额度、补设备、升级模型），涉及资源由 CTO 拍板 客户经理，CTO 回访后 3 个工作日内 飞书审批 推进方案 👤人工判断
8 向客户回告处理结果与更新，约定下次回访日期 客户经理 处理完成后 1 个工作日内 客户群/电话 回告记录 👤人工判断
9 月度复盘：活跃度变化、反馈消化率、未用起来客户名单 客户经理，产品总监 每月第 1 周 多维表格看板 复盘结论 🔧+🤖

5. 交付物与模板

  • 交付物：回访计划、回访记录、反馈分类台账、推进方案、月度复盘
  • 建议模板/表单：
    • 回访记录字段：客户（代号）、客户类型、回访节点、方式、参与岗位、活跃度、使用中的主要场景、问题与反馈、反馈分类、处理去向、客户满意度（1～5）、下次回访日期
    • 推进方案字段：未用起来的原因、推进动作、所需资源、审批人、预计见效日期、结果

6. 异常与升级

  • 决策人连续 2 个回访周期未使用 → 客户经理与市场销售负责人制定沟通策略，避免频繁催促客户 → 升级市场销售负责人（1 个工作日内）
  • 客户个性化需求引发产品路线争议 → 先记录不承诺，提交产品评审 → 升级 CTO（1 周内拍板）
  • 内部对“本地版要不要做得好用”等策略意见不一 → 停止各自对客户表态 → 升级 CTO（3 个工作日内）
  • 回访发现客户有流失或不续约迹象 → 当天报市场销售负责人
  • A（升级）说明：回访计划与执行由客户经理最终负责；推进动作需要投入资源（加送额度、补设备、升级模型），或出现产品路线、本地版策略争议时，拍板权升级到 CTO

7. 衡量指标

  • 回访按期率：按计划节点完成回访的比例，目标 ≥ 90%
  • 重点客户 30 天活跃率：交付 30 天后有活跃使用的席位占比，目标 ≥ 60%
  • 反馈消化率：回访反馈 30 天内有明确去向（修复/排期/拒绝）的比例，目标 ≥ 90%
  • 决策人使用率：重点客户决策人 30 天内至少使用 1 次的比例

8. 低效诊断

  • 交付后没有固定回访节点，靠商务侧每隔几天追问“用得怎么样”｜依据：「某地方政府客户项目群」2026-07、「某地方政府客户项目群」2026-08
  • 培训由谁去、上门由谁去临时决定｜依据：「某地方政府客户项目群」2026-08
  • 内部对推进策略（本地版易用程度）意见分歧，没有拍板机制｜依据：「某地方政府客户项目群」2026-08
  • 回访反馈散在群消息和单独文档中，缺少分类与闭环｜依据：「字字可研项目群」2026-04、「字字可研项目群」2026-06
  • 存量客户内部推广机制临时制定，口径不一｜依据：「字字可研市场运营」2026-03

9. 分支变体

  • 政府客户（决策人为关键使用人）：不催促，以“告知更新+邀请试用”方式客访，策略由市场销售负责人把关
  • 大型设计院类客户：常要求模板个性化，个性化需求一律先记录，优先推标品方案
  • 中小咨询公司：侧重培训与模板，可配合客户内部推广（客户主导的强制使用、考核）
  • C 端付费用户：转 OPS-15 跟踪挽留

10. 待确认问题

  • 回访主责是客户经理还是需设专职客户成功岗？
  • 重点客户的认定标准是什么（合同金额、行业、战略意义）？
  • 7/14/30 天回访节点是否可行？活跃度阈值定多少？
  • 加送额度、补设备等推进资源的审批人和上限是什么？
  • 回访文档与 badcase 登记表是否可合并到一张多维表格？
X-CS-20客户成功案例与效果文档制作待新建120

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：项目出现效果好的客户使用场景，或销售/品牌需要展示材料时，按统一模板整理成功案例与效果文档，经真实性核查、客户授权和脱敏后对外使用
  • 负责人：主责——项目研发/FDE（当前：张康·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、客户经理（当前：待指定）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提出案例需求 → ② 采集真实输入输出 → ③ 按模板撰写 → ④ 真实性核查 → ⑤ 客户授权与脱敏 → ⑥ 定稿入库 → ⑦ 分发销售/品牌
  • 交付结果：一份标注“内部可用/对外可用”的案例文档（场景、输入、输出、效果数据、客户反馈、授权状态），入案例库
  • 状态依据：目前由领导临时布置，研发当天用更好模型和云机器跑样例、截图写文档；没有案例模板，测试环境产出的样例对外使用存在真实性风险，也没有客户授权环节

1. 场景判定

  • 触发条件：项目上线后客户使用产生明显效果；销售、品牌、申报需要某行业案例；领导要求整理“效果好的案例”
  • 典型说法：「留效果好的就行」「写一个飞书文档，体现这个系统效果很好」「也整一点 good case」
  • 判断问题：案例来自客户真实使用还是内部测试？要不要对外展示？客户是否同意公开？
  • 不归本流程管：品牌白皮书与案例授权核查的统一管理 → 请走 BRD-15；销售物料与标杆案例库建设 → 请走 SAL-15；运营侧用户案例宣传 → 请走 OPS-20；内部 FDE 成果案例 → 请走 X-FDE-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目研发/FDE 采集真实输入输出、跑样例、撰写案例 R 项目研发/FDE（当前：张康·推断待确认）
CTO 提出需求、审核真实性与对外可用性 A CTO（当前：丁震宇·推断待确认）
客户经理 取得客户授权、收集客户反馈 R（授权） 客户经理（当前：待指定）
品牌 对外版本排版、品牌用语检查 C 品牌（当前：待指定）
法务 授权书模板、涉密/涉军等敏感客户的公开限制 C 法务负责人（当前：李瑶·推断待确认）
销售 使用案例 I 销售各岗位

3. 办之前请准备

  • 案例用途与受众（销售内部参考/对外展示/申报材料）
  • 真实客户使用记录：输入材料、输出结果、使用时间（去掉客户敏感数据）
  • 效果数据（耗时对比、准确率、节省人力等）及其来源
  • 客户联系人对公开范围的初步意见
  • 如需补跑样例：所用环境、模型和配置说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提出案例需求（用途、受众、截止日期） 需求方（销售/品牌/CTO） 使用前 ≥ 5 个工作日 飞书表单 案例需求单 🔧飞书固化
2 采集真实输入输出；如需补跑，标注环境与模型配置 项目研发/FDE 需求后 2 个工作日内 生产环境/项目环境 素材包 👤人工判断
3 按模板生成案例初稿 项目研发/FDE 素材齐后 1 个工作日内 AI 助手 + 飞书文档 案例初稿 🤖自动化
4 真实性核查：样例来源、效果数据可复现、标注是否测试环境 CTO 初稿后 1 个工作日内 飞书文档评论 核查结论 👤人工判断
5 对外版本取得客户书面授权，按授权范围脱敏（客户名、数据、人名） 客户经理，法务 3 个工作日内 授权书模板 授权记录、脱敏版 👤人工判断
6 定稿入案例库，标注“内部可用/对外可用”与有效期 项目研发/FDE 授权完成当天 多维表格案例库 案例条目 🔧飞书固化
7 推送给销售/品牌，按 SAL-15、BRD-15 纳入物料 项目研发/FDE 入库当天 群机器人 分发通知 🔧+🤖

5. 交付物与模板

  • 交付物：案例文档（内部版、对外脱敏版）、客户授权记录、案例库条目
  • 建议模板/表单：
    • 案例文档字段：行业、客户类型（代号）、业务场景、使用前痛点、输入材料、产出结果（截图）、效果数据及来源、客户反馈原话（已授权）、使用产品与版本、环境说明（生产/测试）、授权状态、可用范围、有效期
    • 案例库字段：案例名、行业、产品、可用范围、授权到期日、负责人岗位、文档链接

6. 异常与升级

  • 只有测试环境样例、无真实客户使用 → 只能标“内部演示样例”，不得作为客户案例对外 → CTO 当天确认
  • 客户不同意公开 → 仅限内部参考，不入对外物料
  • 涉密、军工、政府等敏感客户 → 默认不公开，需法务意见 → 升级 CTO（3 个工作日内）
  • 已对外使用的案例被发现数据不实 → 立即下线并通知销售 → 升级 CTO（当天）

7. 衡量指标

  • 案例产出周期：需求提出到定稿的工作日，目标 ≤ 5 个工作日
  • 对外案例授权率：对外使用案例中有书面授权的比例，目标 100%
  • 案例真实性问题数：目标 0
  • 案例库覆盖：主要行业版至少各 1 个对外可用案例

8. 低效诊断

  • 案例需求由领导临时布置，当天赶出，没有提前规划｜依据：「某水务客户研发群」2026-08
  • 为“看起来效果好”在更好模型和云机器上补跑，环境与客户实际不一致，真实性存疑｜依据：「某水务客户研发群」2026-08
  • 没有案例模板和客户授权环节，案例能否对外不明确｜依据：「某水务客户研发群」2026-08

9. 分支变体

  • 内部演示样例：可用测试环境，但必须标注“演示样例”，不得写客户名
  • 对外客户案例：必须真实使用 + 书面授权 + 脱敏
  • 申报/投标材料引用：需额外确认客户是否允许列名，按申报要求盖章证明

10. 待确认问题

  • 案例主责是项目研发/FDE、客户经理还是品牌？
  • 案例库是否与 BRD-15、SAL-15 共用一张表？
  • 客户授权书是否已有模板？由法务还是销售出？
  • 测试环境样例对外使用的红线是否需要写入制度？
X-CS-21VIP 客户“一键增强”人工代写服务待新建200

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗5 × 跨5 × 险4

  • 适用场景：白名单内的特殊/VIP 客户在产品内点击“一键增强”后，由内部人员用 Claude Code 人工优化可研报告并回写到客户侧，在约定时限内交付
  • 负责人：主责——增强写作执行人（后端/全栈研发，当前：徐鑫宇·推断待确认）；协同——前端研发（当前：侯怡辰·推断待确认）、前端负责人（当前：季学森·推断待确认）、测试负责人（当前：张东郅·推断待确认）、客户经理（当前：待指定）；兜底——Leap/鼎慧研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 白名单申请与开通 → ② 客户点击触发通知 → ③ 认领 → ④ 人工增强写作 → ⑤ 质量审核 → ⑥ 回写数据库 → ⑦ 通知客户 → ⑧ 登记交付时长
  • 交付结果：经质量审核的增强版可研报告已更新到客户账号，并在工单中记录认领、完成时间
  • 状态依据：被定位为临时功能但已进入客户交付；白名单靠改代码配置，开通需找开发；通知 @所有人但没有认领人和响应时限（“人工响应速度够吗”）；写完后回写数据库全靠人工

1. 场景判定

  • 触发条件：通知群收到“「一键增强」功能触发通知”卡片（项目名、ID、报告类型）；销售/客户经理申请把某客户加入白名单
  • 典型说法：「点了之后发飞书通知，然后人工用 Claude Code 写可研」「这人工响应速度够吗」「需要个夜猫子」
  • 判断问题：触发用户是否在已批准的白名单内？报告类型是否在服务范围内？
  • 不归本流程管：普通用户的报告生成质量问题 → 请走 X-CS-13；提示词与报告类型配置调整 → 请走 X-PRD-25；客户新增定制需求 → 请走 X-CS-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
增强写作执行人 认领通知、人工增强写作、回写数据库 R 后端/全栈研发（当前：徐鑫宇·推断待确认）
研发负责人 白名单审批、值守排班、质量最终负责 A Leap/鼎慧研发负责人（当前：王皓南·推断待确认）
前端研发 按钮、状态展示与通知卡片功能维护 C 前端研发（当前：侯怡辰·推断待确认）
前端负责人 功能演示视频、客户说明素材 C 前端负责人（当前：季学森·推断待确认）
测试负责人 功能上线测试、交付质量抽检 C 测试负责人（当前：张东郅·推断待确认）
客户经理 申请白名单、对客户说明交付时限、交付后回访 R（客户沟通） 客户经理（当前：待指定）
系统自动执行 客户点击后推送通知卡片、自动生成增强工单、超时提醒 R 通知机器人与多维表格（由前端研发维护）

3. 办之前请准备

  • 白名单申请：客户（代号）、账号标识、服务期限、申请理由、审批人（不在群里贴手机号，填进申请表）
  • 服务承诺：交付时限（如 1～2 个工作日）、服务范围（报告类型）
  • 写作环境：Claude Code 及增强写作 skill/提示词、数据库回写权限
  • 值守排班表（含夜间、周末）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交白名单申请，研发负责人审批后在后台添加（替代改代码） 客户经理，研发负责人 申请后 1 个工作日内 飞书审批 + 管理后台 白名单记录 🔧飞书固化
2 客户点击后机器人推送通知卡片，自动生成工单 系统 实时 通知机器人 + 多维表格 增强工单 🤖自动化
3 值守人点“认领”，超时未认领自动提醒研发负责人 增强写作执行人 工作时间 1 小时内认领；非工作时间次日 10:00 前 卡片认领按钮 认领记录 🔧+🤖
4 用 Claude Code + 增强 skill 生成初稿，人工修订 增强写作执行人 认领后 1 个工作日内 Claude Code 增强稿 🤖+👤
5 质量审核（结构、数据、行业规范） 研发负责人或指定审核人 初稿后 0.5 个工作日内 审核清单 审核结论 👤人工判断
6 回写数据库并在客户侧确认已更新 增强写作执行人 审核通过当天 数据库/回写脚本 已更新报告 🤖自动化
7 通知客户经理，由其告知客户 增强写作执行人，客户经理 回写后 2 小时内 群机器人 交付通知 🔧飞书固化
8 工单记录完成时间、耗时，关闭工单 增强写作执行人 交付当天 多维表格 关闭工单 🔧飞书固化

5. 交付物与模板

  • 交付物：白名单记录、增强工单、增强版报告、审核记录
  • 建议模板/表单：
    • 白名单申请字段：客户代号、账号标识、服务期限、报告类型范围、申请人、审批人、到期自动移除日期
    • 增强工单字段：项目名、项目 ID、报告类型、触发时间、认领人、认领时间、完成时间、审核人、审核结论、回写时间、客户确认

6. 异常与升级

  • 触发后超过认领时限无人认领 → 机器人提醒研发负责人 → 研发负责人当场指派
  • 预计无法在承诺时限内交付 → 客户经理提前告知客户新时间 → 升级研发负责人（发现当天）
  • 回写数据库失败或覆盖错误 → 立即停止，从备份恢复 → 升级研发负责人（1 小时内）
  • 非白名单用户看到并触发按钮 → 视为配置缺陷，转 X-CS-13 → 研发负责人当天处理
  • 服务期结束 → 按到期日从白名单移除，功能入口下线

7. 衡量指标

  • 认领时长：通知到认领的时长，目标工作时间 ≤ 1 小时
  • 交付时长：触发到回写完成的工作日，目标 ≤ 2 个工作日
  • 审核通过率：一次审核通过的比例，目标 ≥ 90%
  • 回写差错数：目标 0

8. 低效诊断

  • 白名单写在代码配置里，新增客户需找开发改代码再发版｜依据：「工程咨询产研」2026-03
  • 通知 @所有人但没有认领机制和响应时限，非工作时间响应没人兜底｜依据：「工程咨询产研」2026-03
  • 写作完成后回写数据库全靠人工，交接容易断档｜依据：「工程咨询产研」2026-03
  • 功能定位为“临时”，但已被设为最高优先级进入客户交付，测试进度靠追问｜依据：「工程咨询产研」2026-03

9. 分支变体

  • 仅限特殊/VIP 客户，服务期结束即下线功能入口和白名单
  • 如后续扩大到更多客户：应评估改为产品化自动增强，人工仅做质量审核

10. 待确认问题

  • 该服务是否仍在运行？是否已到期下线？
  • 白名单审批人是研发负责人还是销售负责人？
  • 交付时限承诺 1～2 个工作日是否可行？夜间/周末是否需要值守？
  • 是否计划把人工增强改成自动化（skill/沙盒）？
  • 主责是否应从研发转到客户成功或行业业务专家？
X-CS-22俱乐部/商户入驻与会员端配置对接待优化135

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：新俱乐部/商户确定入驻跃玩、星域或会员端时，收集入驻材料、开通商户、配置会员等级与权益、导入客户名单、完成操作教学，并持续接收配置类咨询
  • 负责人：主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、销售/商务（当前：飞书用户8994FW·推断待确认）、获客/客户教学（当前：刘安达·推断待确认）、产品经理（当前：段涵·推断待确认）、网页端前端（当前：陈真炎·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 签约后建入驻工单 → ② 发材料清单与信息收集表 → ③ 材料审核与商户开通 → ④ 会员端配置 → ⑤ 客户名单批量导入 → ⑥ 操作教学 → ⑦ 上线确认 → ⑧ 首月跟进与问题入台账
  • 交付结果：已开通并完成会员体系配置的俱乐部/商户账号，客户名单导入完成，教学记录与入驻台账状态为“已上线”
  • 状态依据：已有信息收集表单、产品使用网站、客户批量录入功能（2026-10 上线）和晚间操作教学，但入驻流程、问题台账、与研发需求联动未固化；每天重复“客户咨询”“商户入驻”，需求多经私聊/电话流转

1. 场景判定

  • 触发条件：新俱乐部/电竞俱乐部/商户签约或确定合作；已入驻俱乐部开通会员端；需要导入已有客户名单或从其他系统迁移会员数据；俱乐部要求修改平台信息
  • 典型说法：「对接入驻材料」「配合俱乐部配置会员端」「准备晚上操作教学」「客户信息批量录入」
  • 判断问题：俱乐部是否已确定合作？需要的是“开通和配置”，还是“已用系统出了问题”？
  • 不归本流程管：已入驻俱乐部的使用问题与故障 → 请走 X-CS-23；账务类变更（主户、实名、资金）→ 请走 X-CS-24；会员端活动上新与积分权益调整 → 请走 OPS-24；商户支付进件 → 请走 FIN-15；星域商户开通与数据迁移的技术实施 → 请走 X-DLV-38

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
商户入驻专员 建工单、发材料清单、审核材料、开通商户、维护入驻台账 R 商户入驻专员（当前：宫经喜·推断待确认）
销售/商务 合作确认、对接俱乐部负责人、收集初始材料 R（前期） 销售/商务（当前：飞书用户8994FW·推断待确认）
会员端产品经理 配置会员等级、权益、商品图片，跟进使用并引导 R（配置） 会员端产品经理（当前：陈雁·推断待确认）
客户教学 组织操作教学、日常咨询答疑 R（教学） 获客/客户教学（当前：刘安达·推断待确认）
产品经理 批量录入模板与字段规范、配置需求转研发 C 产品经理（当前：段涵·推断待确认）
网页端前端/测试 导入异常排查、功能验证 C 网页端前端（当前：陈真炎·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）
跃竞负责人 兜底、入驻优先级与特殊条件拍板 A 跃竞负责人（当前：徐莉·推断待确认）
俱乐部 提交入驻材料、自助导入客户名单并修正失败数据、参加操作教学 R（自助导入） 外部

3. 办之前请准备

  • 合作确认（合同或负责人确认记录）、俱乐部等级（重点/普通）
  • 入驻材料清单：主体资质、负责人实名信息、收款账户信息（走系统填写，不在群里发）、门店/俱乐部基本信息、Logo 与商品图片
  • 会员体系方案：等级、成长规则、权益、商品
  • 已有客户名单（按 Excel 模板整理，至少有手机号或微信号之一）
  • 教学时间（常在晚间）与参加人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合作确认后建入驻工单，记录俱乐部等级与对接人岗位 销售/商务 确认当天 多维表格入驻台账 入驻工单 🔧飞书固化
2 发材料清单与信息收集表 商户入驻专员 工单建立后 1 个工作日内 飞书表单 材料收集表 🔧飞书固化
3 材料审核，缺项一次性告知 商户入驻专员 收齐后 1 个工作日内 入驻台账 审核结论 👤人工判断
4 开通商户/俱乐部账号 商户入驻专员 审核通过后 1 个工作日内 管理后台 已开通账号 👤人工判断
5 配置会员等级、权益、商品图片 会员端产品经理 开通后 2 个工作日内 会员端后台 配置截图与清单 👤人工判断
6 按模板导入客户名单，核对匹配成功/失败，失败数据回给俱乐部修正 俱乐部（自助）+ 商户入驻专员协助 开通后 3 个工作日内 批量录入功能 + 操作日志 导入结果 🤖自动化
7 操作教学（管理端、会员端、日常查账），留录屏 客户教学 配置完成后 2 个工作日内 飞书会议 教学记录、录屏 👤人工判断
8 上线确认，台账状态改“已上线”，拉入客户服务群 商户入驻专员 教学后 1 个工作日内 入驻台账 上线确认 🔧飞书固化
9 首月每周跟进使用；咨询先查知识库，配置类需求登记台账并转产品 客户教学，会员端产品经理 上线后 30 天内每周 1 次 微信客服知识库 + 问题台账 跟进记录 🔧+🤖

5. 交付物与模板

  • 交付物：入驻台账、材料收集表、会员体系配置清单、客户名单导入结果、教学记录与录屏
  • 建议模板/表单：
    • 入驻台账字段：俱乐部（代号）、类型（俱乐部/电竞俱乐部/商户）、等级、对接销售、入驻专员、材料状态、开通日期、会员端配置状态、名单导入状态、教学日期、上线日期、当前阶段、卡点
    • 客户名单整理规范：使用官方 Excel 模板；手机号与微信号至少填一项；不得包含身份证号等无关个人信息；导入后原始文件按隐私要求删除或加密保存
    • 配置需求登记字段：俱乐部、需求描述、紧急程度、是否标品可配、转研发编号、状态

6. 异常与升级

  • 材料 5 个工作日仍未收齐 → 销售/商务跟进俱乐部负责人 → 升级跃竞负责人（第 6 个工作日）
  • 俱乐部要求超出标品的配置或功能 → 登记需求，不当场承诺 → 转 X-PRD-11，跃竞负责人拍板（1 周内）
  • 名单导入请求超时或结果未知 → 先查操作日志再重新识别，不重复提交 → 仍失败转网页端前端（当天）
  • 从其他系统迁移会员数据 → 按 X-DLV-38 走数据迁移方案，产品经理与后端评估 → 跃竞负责人确认
  • 涉及个人信息批量处理的异议 → 暂停导入 → 升级法务负责人（当前：李瑶·推断待确认）

7. 衡量指标

  • 入驻周期：合作确认到上线的自然日，目标 ≤ 7 天
  • 材料一次通过率：首次提交即通过审核的比例，目标 ≥ 70%
  • 名单导入成功率：匹配成功记录占比，目标 ≥ 95%
  • 上线后首月活跃：入驻 30 天内有订单/会员活跃的俱乐部占比
  • 重复咨询占比：可由知识库回答的咨询占全部咨询比例，逐月下降

8. 低效诊断

  • 入驻材料、配置教程分散，每家俱乐部重复沟通同样问题｜依据：「跃玩项目组」2026-06、「跃玩项目组」2026-07
  • 客户需求与问题多在私聊/电话处理，进入研发需求的路径不透明｜依据：「跃玩项目组」2026-06
  • 客户名单导入模板版式多次返工，导入结果未知时需人工引导查日志｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10
  • 入驻专员、产品、教学分工靠临时协调，缺统一台账看进度｜依据：「跃玩项目组」2026-07

9. 分支变体

  • 普通俱乐部入驻：走完整步骤 1～9
  • 电竞俱乐部：额外确认赛事/陪玩相关配置
  • 会员端客户（已有会员体系、需迁移数据或小程序优化）：步骤 6 改为数据迁移，按 X-DLV-38 处理
  • 平台信息修改：只走步骤 2～4，用“平台信息修改收集表”

10. 待确认问题

  • 入驻主责是商户入驻专员还是销售/商务？两者如何交接？
  • 7 天入驻周期是否可行？
  • 微信客服知识库由谁维护、多久更新？
  • 客户名单中个人信息的保存与删除规则是否已有成文制度？
  • 与 X-DLV-38 的边界：本流程管客户对接，X-DLV-38 管技术开通与迁移，是否认可？
X-CS-23俱乐部客户反馈受理与转研发排查待新建300

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：俱乐部、陪玩、老板反馈使用问题、入账/分账异常、余额支付或提现失败、积分/成长值未同步时，统一受理、收齐要素、按客户等级与资金影响分级，转研发排查，修复后回告客户
  • 负责人：主责——客户反馈受理（运营，当前：陈雁·推断待确认）；协同——商户入驻专员（当前：宫经喜·推断待确认）、产品经理（当前：段涵·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠、蒋兴武、魏小东·推断待确认）、测试负责人（当前：赵伟龙·推断待确认）、CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 受理登记（必填订单号/UID 等）→ ② AI 助手自查 → ③ 分级分派 → ④ 研发排查与复现 → ⑤ 修复/补正（涉资金人工确认）→ ⑥ 回告客户 → ⑦ 根因归类入排查手册
  • 交付结果：一条要素完整、有优先级、有处理人和根因的问题记录；客户收到处理结果；重复问题沉淀为排查手册或 FAQ
  • 状态依据：已有内测反馈收集表和机器人卡片、AI 小助手，但客户问题多经各俱乐部群和微信转述，订单号常缺失需来回追问；资金类问题无分诊和 SLA，研发离线时无人可查；积分同步异常 08～10 月重复 5 次以上，排查依赖个人记忆

1. 场景判定

  • 触发条件：俱乐部群/客服/销售转来客户问题；内测反馈表新记录；客户反馈分账多日未到账、余额支付失败、提现失败、红包/退款未到账；会员端客户反馈消费未计入积分或成长值
  • 典型说法：「最近的分账是不是有一点问题？」「这个订单不能余额支付」「消费没有计入积分，说是普遍有问题」「TOP1 群里的问题，上班先优先处理一下」
  • 判断问题：是否涉及资金（分账、提现、退款、余额）？是否重点俱乐部？能否提供订单号/UID？
  • 不归本流程管：主户更换、实名更换、资金调账、罚款划扣 → 请走 X-CS-24；顾客对订单/陪玩的投诉 → 请走 X-CS-25；资金/分账数据修复的财务侧处理 → 请走 FIN-25；新入驻与配置 → 请走 X-CS-22；新需求 → 请走 X-PRD-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户反馈受理（运营） 受理登记、补齐要素、AI 自查、回告客户 R 会员端产品经理/运营（当前：陈雁·推断待确认）
商户入驻专员 协助受理所对接俱乐部的问题 R（协助） 商户入驻专员（当前：宫经喜·推断待确认）
跃竞负责人 分级分派、资金类结论确认、兜底 A 跃竞负责人（当前：徐莉·推断待确认）
后端负责人 支付分账、汇付相关排查，修复发版 R（排查） 后端负责人（当前：王子明·推断待确认）
后端/前端研发 订单、会员、钱包、小程序问题排查 R（排查） 后端研发（当前：张楠、蒋兴武·推断待确认）、前端负责人（当前：魏小东·推断待确认）
测试负责人 问题复现与修复验证 C 测试负责人（当前：赵伟龙·推断待确认）
CTO 会员端积分同步数据核查与部署 C CTO（当前：丁震宇·推断待确认）
产品经理 失败原因展示等体验改进评估 C 产品经理（当前：段涵·推断待确认）
财务 涉及退款、补款的资金确认 C 财务（当前：待指定）

3. 办之前请准备

  • 必填：俱乐部（代号）、端（会员端/小程序/管理后台）、订单号或 UID、发生时间、现象描述、截图
  • 资金类加填：涉及笔数、支付方式（余额/储值/微信）、是否已联系支付通道
  • 积分同步类加填：老板编号、星域 UID、填写的微信号（核对是否填错）
  • 是否已问过 AI 小助手/星域 bot 及其结论
  • 客户等级（重点/普通）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在问题受理表登记，必填项不全则一次性向客户索取 客户反馈受理 收到后 30 分钟内（工作时间） 飞书表单 → 多维表格 + 机器人卡片 问题记录 🔧飞书固化
2 用 AI 小助手/星域 bot 查库自查，常见问题（余额不足、结算延迟、微信号填错）按 FAQ 直接回复 客户反馈受理 登记后 30 分钟内 AI 小助手 自查结论 🤖自动化
3 分级：P0 资金类或重点俱乐部批量问题；P1 单客户功能不可用；P2 体验/咨询；按类型分派 跃竞负责人（机器人按规则预分级） 自查后 30 分钟内 多维表格规则 优先级、处理人 🔧+🤖
4 研发查日志与数据、给出根因；测试复现 后端负责人/研发，测试负责人 P0 2 小时内给初步结论；P1 1 个工作日；P2 3 个工作日 数据库、日志、告警 根因说明 👤人工判断
5 修复或补正状态；涉及退款、补款、补积分须人工确认后执行 研发；资金类由跃竞负责人+财务确认 根因确认后按优先级时限 管理后台/Gitea issue 修复记录 👤人工判断
6 用回复模板告知客户结果，必要时请客户复核（积分小程序可能有约半小时延迟） 客户反馈受理 修复后 2 小时内 客户群 回告记录 🔧飞书固化
7 根因归类（填错/接口变更/规则/积压/缺陷），重复问题写入排查手册与 FAQ 客户反馈受理，研发 关闭后 2 个工作日内 排查手册（飞书文档） 手册条目 🔧+🤖

5. 交付物与模板

  • 交付物：问题受理台账、根因说明、客户回告记录、排查手册、FAQ
  • 建议模板/表单：
    • 问题受理表字段：提交时间、俱乐部、客户等级、端、订单号/UID、问题类型（分账/支付/提现/退款/积分同步/功能/咨询）、现象、截图、AI 自查结论、优先级、处理人、根因分类、处理结果、是否涉资金、资金确认人、回告时间、关闭时间
    • 排查手册条目：现象、检查顺序、查询方式（不写库密码）、常见根因、处理方法、需谁确认
    • 客户回复模板：已收到 / 正在排查（预计时间）/ 已处理（原因 + 结果）/ 需客户配合（补充信息）

6. 异常与升级

  • P0 资金问题 2 小时内无初步结论 → 跃竞负责人电话联系后端负责人 → 同步财务（当天）
  • 夜间/节假日 P0 → 按值班表联系值班研发，联系不上直接电话跃竞负责人 → 1 小时内
  • 根因在支付通道（汇付）→ 后端负责人对接通道工单 → 当天给客户阶段性回复
  • AI 小助手/模型不可用 → 退回人工查询，记录故障 → 转研发恢复（当天）
  • 同类问题一周内 ≥ 3 次 → 视为系统性问题，转缺陷修复与告警配置 → 跃竞负责人当周安排

7. 衡量指标

  • 要素完整率：受理时订单号/UID 等必填项齐全的比例，目标 ≥ 95%
  • 首次响应时长：客户反馈到首次回复，目标工作时间 ≤ 30 分钟
  • P0 解决时长：目标 ≤ 1 个工作日
  • AI 自查解决率：在步骤 2 直接解决的比例，目标 ≥ 30%
  • 同类问题复发次数：同一根因 30 天内复发次数，逐月下降

8. 低效诊断

  • 客户在各俱乐部群提问，运营转述，订单号缺失需来回追问，误判问题类型｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-06
  • 资金类问题没有受理和分诊，研发离线时无人能查，夜间节假日找不到人｜依据：「告警通知群」2026-09、「告警通知群」2026-10
  • 积分同步异常重复出现，每次人工比对微信号与接口数据，没有排查手册｜依据：「跃玩会员端」2026-08、「跃玩会员端」2026-10
  • 接口地址被变更后数据中断才被客户发现，缺少同步异常告警｜依据：「跃玩会员端」2026-08
  • 提现失败原因在陪玩侧不展示，同一问题反复被问｜依据：「跃玩项目组」2026-08
  • 重点俱乐部优先级靠口头要求｜依据：「跃玩项目组」2026-01

9. 分支变体

  • 分账/结算延迟：先查待结算队列积压与消费端限速，再看通道
  • 余额支付失败：先查储值余额是否足够，避免误判为优惠券/储值规则问题
  • 提现失败：常见为银行卡限额，按失败原因回复；需展示失败原因的转产品评估
  • 会员端积分/成长值未同步：依次查微信号是否填错/未填、接口地址是否变更、联盟范围配置、历史消费是否计积分规则、大小号合并
  • 重点俱乐部（如 TOP1 俱乐部、重点会员端客户）：自动提升一级优先级

10. 待确认问题

  • 受理主责放在运营（会员端产品经理）还是设专职客服？
  • P0/P1/P2 的时限是否可行？夜间是否需要研发值班？
  • 资金类结论的确认人是跃竞负责人还是财务？
  • 内测反馈收集表能否直接升级为正式问题受理表？
  • 是否为会员端客户做“按微信号查同步状态”的自助查询？
X-CS-24俱乐部账务类工单处理待新建225

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：俱乐部提出主户更换、实名更换、剩余资金迁移、资金调账、罚款强制划扣或账单疑问时，通过统一工单受理，涉资金操作经审批后由研发执行并留痕
  • 负责人：主责——俱乐部工单受理（客服/运营，当前：宫经喜·推断待确认）；协同——后端负责人（当前：王子明·推断待确认）、后端研发（当前：张楠·推断待确认）、财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 俱乐部提交工单 → ② 材料核验 → ③ 审批（按类型分级）→ ④ 研发执行 → ⑤ 复核 → ⑥ 通知俱乐部 → ⑦ 归档留痕
  • 交付结果：一张完成审批、执行、复核的工单，附执行前后数据截图和通知记录
  • 状态依据：主户更换、实名更换、资金迁移、调账 08～10 月约 12 次，均由研发手工处理，来源和进展不在群内可见；资金调账由研发直接执行，缺审批；罚款强制划扣到 2026-10 才改为工单制

1. 场景判定

  • 触发条件：俱乐部申请更换主账户、更换实名主体；申请把剩余资金迁移到新账户；需要资金调账；平台需对俱乐部执行罚款强制划扣；俱乐部对账单有疑问
  • 典型说法：「处理俱乐部工单」「俱乐部主户更换」「处理更换实名工单」「罚款强制划扣申请改为工单制」
  • 判断问题：是否涉及账户归属或资金变动？申请人是否为俱乐部有权人？
  • 不归本流程管：分账/入账异常排查 → 请走 X-CS-23；平台罚款申诉 → 请走 OPS-25；渠道/合作方分成结算 → 请走 FIN-23；支付通道每日对账差异 → 请走 FIN-24；资金/分账数据修复 → 请走 FIN-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
工单受理 受理、材料核验、账单问题答复、通知俱乐部、归档 R 客服/运营（当前：宫经喜·推断待确认）
跃竞负责人 主户/实名更换审批，资金类工单业务审批 A 跃竞负责人（当前：徐莉·推断待确认）
财务 资金迁移、调账、罚款划扣的金额核对与会签 R（资金会签） 财务（当前：待指定）
后端负责人 按审批结果执行变更，留执行记录 R（执行） 后端负责人（当前：王子明·推断待确认）
后端研发 会费对账、账单数据核查 C 后端研发（当前：张楠·推断待确认）
俱乐部 提交申请与证明材料，确认结果 I 外部

3. 办之前请准备

  • 俱乐部（代号）、商户号、申请类型
  • 申请人身份与授权证明（原主户/新主户双方确认、实名变更证明材料，走系统上传，不在群里发证件）
  • 涉资金：金额、来源账户、目标账户、原因说明、相关订单或罚款依据
  • 罚款划扣：罚款决定、申诉期是否已过（申诉走 OPS-25）
  • 账单疑问：账单期间、疑问项

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 俱乐部经客服入口提交工单，选择类型并上传材料 俱乐部，工单受理 收到申请当天 飞书表单/多维表格工单 工单 🔧飞书固化
2 核验材料完整性与申请人权限，缺项一次性告知 工单受理 提交后 1 个工作日内 工单 核验结论 👤人工判断
3 审批：账户类由跃竞负责人批；资金类由跃竞负责人 + 财务双签 跃竞负责人，财务 核验后 1 个工作日内 飞书审批 审批记录 🔧飞书固化
4 按审批内容执行变更，执行前后截图或导出数据 后端负责人 审批通过后 1 个工作日内 管理后台/数据库 执行记录 👤人工判断
5 复核执行结果（资金类核对金额与账户） 财务或后端研发（非执行人） 执行当天 后台/对账数据 复核结论 👤人工判断
6 通知俱乐部结果，请其确认 工单受理 复核后 2 小时内 客户群/系统通知 通知记录 🔧+🤖
7 工单关闭归档，月底汇总给财务 工单受理 关闭当天；月度汇总每月 5 日前 多维表格 归档工单、月度汇总 🔧+🤖

5. 交付物与模板

  • 交付物：工单、审批记录、执行前后数据、复核结论、俱乐部确认记录、月度账务工单汇总
  • 建议模板/表单：
    • 工单字段：工单号、俱乐部、商户号、类型（主户更换/实名更换/资金迁移/资金调账/罚款划扣/账单咨询）、申请人、材料附件、金额、来源账户、目标账户、原因、审批人、审批时间、执行人、执行时间、复核人、结果、俱乐部确认时间
    • 账单咨询回复模板：账单期间、疑问项、核对结果、是否需调账

6. 异常与升级

  • 材料不全或申请人权限存疑 → 暂停，不执行 → 升级跃竞负责人（1 个工作日内）
  • 新旧主户有争议 → 冻结变更，要求双方书面确认 → 升级跃竞负责人并征求法务意见（法务负责人当前：李瑶·推断待确认）
  • 执行后金额与审批不符 → 立即停止后续操作，按 FIN-25 修复 → 升级跃竞负责人与财务（1 小时内）
  • 未经审批的紧急资金操作 → 原则上禁止；确需先做的，跃竞负责人口头批准后 24 小时内补审批
  • 同类工单每月 ≥ 5 次 → 评估做成后台自助功能 → 跃竞负责人提需求
  • A 说明：账户类与资金类工单的最终审批人均为跃竞负责人；资金类由财务会签核对金额，财务会签不通过时不得执行，由跃竞负责人与财务当日共同复核后再定

7. 衡量指标

  • 工单处理周期：提交到关闭的工作日，目标 ≤ 3 个工作日
  • 资金类工单审批覆盖率：执行前完成审批的比例，目标 100%
  • 执行差错数：目标 0
  • 工单可见率：账务类变更全部有工单记录，目标 100%

8. 低效诊断

  • 工单来源与进展不在群内可见，只出现在研发日报里｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10
  • 资金调账、资金迁移由研发直接执行，缺财务审批与复核｜依据：「跃玩项目组」2026-09
  • 罚款强制划扣原先无工单，事后才补流程｜依据：「跃玩项目组」2026-10
  • 主户更换、实名更换每次手工处理，没有后台功能｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09

9. 分支变体

  • 主户更换 / 实名更换：账户类，跃竞负责人单签，需新旧双方确认
  • 剩余资金迁移 / 资金调账：资金类，跃竞负责人 + 财务双签，执行与复核分离
  • 罚款强制划扣：需罚款依据且申诉期已过，资金类双签
  • 账单咨询：工单受理与后端研发核对后答复，发现差错转资金调账

10. 待确认问题

  • 俱乐部工单的提交入口现在是什么（客服群、系统工单还是其他）？
  • 资金类审批的财务岗是谁？金额多大需要更高层审批？
  • 主户更换、实名更换需要哪些证明材料？是否已有成文规则？
  • 是否计划把主户更换、实名更换做成后台功能，减少研发手工操作？
  • 罚款强制划扣工单制（2026-10 起）的具体规则是否已成文？
X-CS-25订单投诉受理与售后缓冲规则待优化225

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：跃玩平台顾客对订单或陪玩服务不满发起投诉，或自助订单陪玩提交服务凭证后进入 48 小时售后缓冲期时启动
  • 负责人：主责——平台客服/售后主管（当前：待指定）；协同——俱乐部接待、平台超管（当前：待指定）、产品经理（当前：樊九辰、段涵·推断待确认）、后端投诉域开发（当前：张楠、王子明·推断待确认）、财务专员（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 顾客发起投诉/售后申请 → ② 接待首响与首次处理 → ③ 顾客确认或二次申诉 → ④ 管理员升级复核 → ⑤ 超管终局裁定 → ⑥ 退款/罚款/补偿分级审批执行 → ⑦ 结案留痕；无异议订单缓冲期满自动完单结算
  • 交付结果：有完整处理轮次、事实快照与审计留痕的投诉单；已执行的退款/罚款/补偿凭证；按规则自动完单结算的自助订单
  • 状态依据：订单投诉系统已于 2026-09 上线、《自助订单自动确认完成PRD》已成文，但首响/处理时限、赔付权限、对俱乐部的规则发布未见成文制度；上线后接口/状态/可见范围连续修复约 15 次，48 小时缓冲期计时口径在上线后的 10 月才补齐

1. 场景判定

  • 触发条件：顾客在订单详情页点“投诉”并提交诉求/附件；自助订单陪玩提交服务凭证后，顾客在 48 小时缓冲期内发起售后申请；投诉超时未处理触发首响预警或升级
  • 典型说法：「这单陪玩没按约定打，我要投诉」「订单投诉功能已正式上线」「凭证齐了，48 小时没异议就自动完单结算」「顾客对首次处理不满意，要二次申诉」
  • 判断问题：是否针对已存在的具体订单？订单是自助还是非自助？是否仍在 48 小时缓冲期内？该订单投诉次数是否已用尽？订单是否已退款（已退款只受理行为类投诉）？
  • 不归本流程管：陪玩/俱乐部入驻与资质 → 请走 X-CS-22（俱乐部/商户入驻与会员端配置对接）；支付失败、分账异常等技术故障 → 请走 X-CS-23（俱乐部客户反馈受理与转研发排查），大面积服务不可用走 RND-75（线上/测试环境故障响应与复盘）；非订单类的咨询与功能建议 → 请走 X-CS-05（客户问题受理、分流与工单流转）；投诉系统本身的需求变更 → 请走 X-PRD-09（需求提报登记与需求池管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 制定时限与赔付权限、监控超时与升级、月度复盘 A 平台客服/售后主管（当前：待指定）
首次处理人 首响、核实事实、给出首次处理结论 R 俱乐部接待（当前：待指定）
复核人 处理二次申诉与升级复核 R 平台管理员（当前：待指定）
终局裁定人 对争议单做终局裁定，结论不再申诉 R 平台超管（当前：待指定）
投诉发起方 发起投诉、确认结案或二次申诉 I 顾客
系统自动执行 校验投诉次数、生成事实快照、推送待办与预警、缓冲期计时与自动完单 R 订单投诉系统（由后端投诉域开发维护）
被投诉方 提供服务凭证与情况说明 C 陪玩
规则与系统 维护投诉规则、缓冲期计时口径、PRD 与原型 C 产品经理（当前：樊九辰、段涵·推断待确认）
技术支持 状态异常、计时错误、退款失败排查 C 后端投诉域开发（当前：张楠、王子明·推断待确认）
资金执行 退款、罚款、补偿凭证的核对与入账 C 财务专员（当前：待指定）
兜底 规则争议、重大赔付、对外口径拍板 I/A（升级） 跃竞负责人（当前：徐莉·推断待确认）

3. 办之前请准备

  • 订单号、订单类型（自助/非自助）、单陪玩或多陪玩、订单金额与支付/存单方式
  • 顾客诉求（退款/罚款/补偿/仅反馈）及附件（截图、录屏、聊天记录）
  • 陪玩提交的服务凭证及提交时间；如有退回/重传，记录每次时间
  • 系统自动生成的事实快照、历史处理轮次和该订单剩余投诉次数
  • 当前赔付权限表（各角色可批准的退款/补偿额度）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 顾客在订单详情发起投诉，系统校验投诉次数、订单状态（已退款仅开放行为类），生成事实快照 顾客、系统 实时 订单投诉系统 投诉单＋事实快照 🤖自动化
2 系统向接待、陪玩推送待办角标与定向通知，启动首响倒计时 系统 实时 订单投诉系统 待办与首响预警 🤖自动化
3 接待首响，向顾客确认诉求，向陪玩调取凭证与说明 俱乐部接待 投诉提交后 2 小时内（营业时间） 订单投诉系统 首响记录 👤人工判断
4 接待给出首次处理结论（驳回/退款/罚款/补偿），超出本人权限的转审批 俱乐部接待 投诉提交后 24 小时内 订单投诉系统 首次处理结论 👤+🤖（AI 归类与回复草稿）
5 顾客确认结案或发起二次申诉；逾期未操作按规则自动关闭 顾客、系统 收到结论后 48 小时内 订单投诉系统 确认/申诉记录 🔧飞书固化
6 管理员对二次申诉升级复核，必要时联系双方补证 平台管理员 申诉后 1 个工作日内 订单投诉系统 复核结论 👤人工判断
7 仍有争议的提交超管终局裁定，结论写明依据 平台超管 升级后 2 个工作日内 订单投诉系统 终局裁定书 👤人工判断
8 退款/罚款/补偿按权限分级审批后执行，财务核对资金流 出具结论的俱乐部接待/平台管理员/平台超管、财务专员 结论生效后 1 个工作日内 订单投诉系统、飞书审批 退款/罚款记录、系统外补偿凭证 🔧飞书固化
9 自助订单：凭证齐全后启动 48 小时售后缓冲期，期满无售后申请自动完单结算；有申请转入步骤 3 系统 凭证齐全后 48 小时 订单系统（俱乐部自动确认开关＋金额阈值） 自动完单结算记录 🤖自动化
10 投诉次数用尽、超时自动关闭或系统异常的单，转平台客服人工跟进 平台客服/售后主管 当日内 订单投诉系统 人工跟进记录 👤人工判断
11 每月汇总投诉量、类型、时效、赔付金额，回流规则与产品需求 平台客服/售后主管 次月 5 个工作日内 多维表格 投诉月报 🔧+🤖

5. 交付物与模板

  • 交付物：投诉单（含处理轮次、事实快照、审计日志）；终局裁定书；退款/罚款/补偿记录；自动完单结算记录；投诉月报
  • 建议模板/表单：投诉处理结论模板（订单号、订单类型、投诉类型〔行为类/服务质量/退款诉求〕、事实摘要、证据清单、处理结论、赔付类型与金额档位、审批人、依据条款、处理人、时间）；赔付权限表（角色、可批准上限、超限审批人）；对俱乐部发布的售后规则公告（缓冲期、计时口径、例外情形、申诉路径）

6. 异常与升级

  • 首响超时 → 系统预警推送接待及平台客服 → 超 4 小时未响应升级平台客服/售后主管（当日）
  • 赔付超出处理人权限 → 暂停执行，按权限表提交飞书审批 → 重大金额升级跃竞负责人（1 个工作日内）
  • 凭证退回/重传导致缓冲期计时争议 → 以 PRD 计时口径为准，系统记录核实 → 口径不明确时升级产品经理（1 个工作日内）
  • 投诉状态卡死、可见范围错误、退款失败 → 提交研发故障单 → 后端投诉域开发 4 小时内响应
  • 顾客威胁外部投诉/舆情 → 停止常规流程，提交平台超管与跃竞负责人（2 小时内）
  • 涉及俱乐部系统性违规（同一俱乐部月内多次被投诉成立）→ 平台客服/售后主管汇总 → 跃竞负责人决定处置（周内）
  • A（升级）说明：日常投诉处理由流程主责（平台客服/售后主管）负最终责任；单个争议单的终局结论由平台超管出具；出现赔付超出权限表上限、投诉规则本身有争议、顾客威胁外部投诉/舆情、俱乐部系统性违规四种情况时，拍板权升级到跃竞负责人

7. 衡量指标

  • 首响达标率 = 2 小时内首响的投诉单 / 全部投诉单，目标 ≥ 95%
  • 投诉平均结案周期 = 提交到结案的自然时长，目标 ≤ 3 天
  • 二次申诉率 = 发起二次申诉的投诉单 / 首次处理结案单，目标 ≤ 15%
  • 终局裁定占比 = 进入超管终局的单 / 全部投诉单，目标 ≤ 5%
  • 自动完单准确率 = 缓冲期满自动结算且后续无纠纷的订单 / 自动完单总数，目标 ≥ 99%
  • 超时自动关闭占比 = 因处理方超时被关闭的单 / 全部投诉单，目标 ≤ 2%

8. 低效诊断

  • 现象：投诉系统上线前后，接口、状态流转、各角色可见范围连续修复约 15 次，属“先上线后补规则”导致的返工｜依据：「跃玩项目组」2026-09
  • 现象：谁受理、谁终局裁定在上线前需多次对齐，角色权责未先成文｜依据：「跃玩项目组」2026-09
  • 现象：自动确认功能 9 月已上线，凭证退回/重传、多陪玩订单的计时规则到 10 月才补齐，口径前后不一｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10
  • 现象：与俱乐部对齐的规则靠会后由产品整理，未形成对外统一公告与客服话术｜依据：「跃玩项目组」2026-10
  • 现象：系统有首响预警，但首响/处理时限、赔付权限未写入管理制度，预警缺乏考核口径｜依据：「跃玩项目组」2026-09
  • 现象：系统上线前投诉靠线下沟通，无留痕（推断）｜依据：「跃玩项目组」2026-09

9. 分支变体

  • 自助订单：凭证齐全后统一进入 48 小时售后缓冲期，无异议自动完单结算；售后申请进入本流程步骤 3
  • 非自助订单：不适用 48 小时缓冲期，按原有确认方式结算，投诉直接走步骤 1～8
  • 多陪玩订单：缓冲期按最后一位陪玩提交凭证的时间起算；凭证被退回后重传，按 PRD 规定的重新计时口径执行
  • 俱乐部开关：俱乐部可配置是否开启自动确认及金额阈值，超阈值订单不自动完单
  • 已退款订单：只受理行为类投诉，不再受理退款诉求
  • 投诉次数用尽：不再开放线上投诉，转平台客服人工处理

10. 待确认问题

  • 平台侧主责岗位是谁（客服/售后主管还是运营负责人）？俱乐部接待与平台客服的分工边界如何定？
  • 首响 2 小时、首次处理 24 小时、复核 1 个工作日、终局 2 个工作日是否可行？系统现有预警阈值是多少？
  • 退款/罚款/补偿的分级审批额度如何设定？系统外补偿凭证由谁签发、财务如何核对？
  • 超时自动关闭的时长是多少？关闭后顾客是否还能通过客服申诉？
  • 每单投诉次数上限是多少？
  • 48 小时缓冲期及计时规则是否已写入俱乐部服务协议或对外公告？客服话术是否同步？
  • 凭证退回/重传时是重新计时 48 小时还是顺延剩余时长？以哪版 PRD 为准？
  • 是否需要 AI 辅助投诉归类与回复草稿？终局裁定是否明确禁止自动化？
X-CS-26客户续约续费与维保到期管理待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨3 × 险4

  • 适用场景：客户的额度包、订阅、席位、软件授权或硬件维保即将到期时，提前提醒、评估续约意向并推动续签，避免服务中断与收入流失
  • 负责人：主责——客户成功专员（当前：待指定）；协同——客户对接销售、财务专员、交付负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 到期台账维护 → ② 到期前 60 天提醒 → ③ 使用情况与健康度分析 → ④ 续约沟通 → ⑤ 报价与合同 → ⑥ 续费到账开通 → ⑦ 未续约处置
  • 交付结果：续约合同或续费到账记录；未续约客户的流失原因记录
  • 状态依据：已有 X-CS-19（重点客户回访与使用推进）、SAL-24（首单回款跟踪）覆盖部分环节，本条补齐到期台账、续约提醒与续签推进（推断）

1. 场景判定

  • 触发条件：到期台账显示 60 天内到期；客户额度余额低于月均消耗；客户询问续费
  • 典型说法：「客户的维保什么时候到期？」「额度快用完了要不要提醒」「到期了服务会不会停」
  • 判断问题：该客户是否有带期限的服务或授权？到期后是否影响使用？
  • 不归本流程管：额度充值到账操作 → 请走 X-CS-03、FIN-17；扩容加席位 → 请走 X-DLV-33；客户主动解约 → 请走 SAL-36；重点客户日常回访与使用推进 → 请走 X-CS-19；合同文本的到期终止通知期管理 → 请走 LEG-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
续约负责人 维护台账、发提醒、做健康度分析 A/R 客户成功专员（当前：待指定）
销售 续约谈判、报价、签约 R 客户对接销售（当前：待指定）
财务 确认到账、开票 C 财务专员（当前：待指定）
交付 续期授权、延长维保、开通额度 C 交付负责人（当前：待指定）
机器人 到期前自动提醒 R 飞书机器人（由客户成功专员维护）

3. 办之前请准备

  • 客户合同到期日、维保期、授权期、额度包有效期
  • 近 3 个月使用数据（活跃人数、Token 消耗、工单数）
  • 历史投诉与未闭环问题

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 交付/签约后登记到期信息 客户成功专员 交付验收后 3 个工作日内 多维表格 到期台账 🔧飞书固化
2 到期前 60 天机器人提醒 机器人 自动 飞书机器人 提醒消息 🤖自动化
3 输出客户健康度（使用、问题、满意度） 客户成功专员 提醒后 5 个工作日内 运营后台 健康度报告 🤖+👤
4 与客户沟通续约意向 客户对接销售 到期前 45 天 电话/拜访 意向记录 👤人工判断
5 续约报价与合同 客户对接销售 到期前 30 天 SAL-19、SAL-23 续约合同 👤人工判断
6 到账确认并延期授权/维保/额度 财务专员、交付负责人 到账后 1 个工作日内 后台 续期记录 👤人工判断
7 未续约：确认是否宽限、到期停服并走 X-CS-29 客户成功专员 到期前 7 天 飞书 处置结论 👤人工判断

5. 交付物与模板

  • 交付物：到期台账、健康度报告、续约合同、流失原因记录
  • 建议模板/表单：到期台账（客户、产品/服务、到期类型、到期日、合同号、对接销售、客户成功专员、健康度、续约意向、状态、流失原因）

6. 异常与升级

  • 客户明确不续约 → 记录原因并组织挽留 → 升级销售负责人（3 个工作日内）
  • 到期已过仍未付款但客户在用 → 按宽限规则处理，超过宽限期停服 → 升级管理层（1 个工作日内）
  • 维保到期后客户报硬件故障 → 按付费维修报价 → 升级交付负责人

7. 衡量指标

  • 续约率 = 到期客户中续约数 / 到期客户数，目标 ≥ 80%
  • 到期前 30 天完成续约沟通率，目标 100%
  • 因到期未续导致的意外停服次数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在维保或额度到期无人提醒、客户被动停服或公司免费超期服务的风险（推断）

9. 分支变体

  • 渠道客户：提醒发给渠道，由渠道推动续约
  • 按量计费 API 客户：以余额预警代替到期提醒

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 客户成功岗位是否存在？由销售还是售后承担续约？
  • 到期后是否给宽限期？宽限多少天？
  • 硬件维保默认期限与续保报价口径？
X-CS-27B 端客户投诉升级处理与满意度回访待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：企业/政府/渠道客户对产品质量、交付延期、服务态度或计费结果正式表达不满、要求赔偿或威胁解约时，按等级受理、升级、给出处理方案并回访
  • 负责人：主责——客户成功专员（当前：待指定）；协同——客户对接销售、交付负责人、研发值班、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 投诉登记 → ② 分级（一般/严重/重大）→ ③ 指定处理人与时限 → ④ 调查原因 → ⑤ 出处理方案并内部审批 → ⑥ 对客答复 → ⑦ 满意度回访 → ⑧ 月度复盘
  • 交付结果：投诉处理记录、对客书面答复、回访结果、整改项
  • 状态依据：已有 X-CS-05（客户问题受理与工单流转）、X-CS-25（俱乐部订单投诉）覆盖部分环节，本条补齐 B 端客户正式投诉的分级升级、处理方案与满意度回访（推断）

1. 场景判定

  • 触发条件：客户书面或口头表达不满；要求赔偿、退款、减免；威胁解约或向上级/媒体反映；同一问题重复反馈 3 次以上未解决
  • 典型说法：「你们再不解决我们就不付尾款了」「这个问题说了好几次了」「我们领导很不满意」
  • 判断问题：客户表达的是“问题”还是“不满”？是否涉及赔偿、解约或声誉？
  • 不归本流程管：单纯功能 bug 或咨询 → 请走 X-CS-05；俱乐部订单投诉 → 请走 X-CS-25；合同变更/退货 → 请走 SAL-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
投诉负责人 登记、分级、跟进到关闭 A/R 客户成功专员（当前：待指定）
销售 维护客户关系、参与答复 C 客户对接销售（当前：待指定）
交付/研发 调查技术原因、给整改方案 R 交付负责人、研发值班（当前：待指定）
法务 涉及赔偿、违约、声誉时审核答复 C 法务专员（当前：待指定）
管理层 重大投诉决策 I 部门负责人（当前：待指定）
首个接到投诉者 登记投诉并首次回应 R 任何接到投诉的员工

3. 办之前请准备

  • 客户合同、SLA 承诺与历史工单
  • 投诉原话或书面材料（截图、邮件）
  • 相关故障记录与日志（X-CS-06）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记投诉并首次回应客户 首个接到投诉者 2 小时内 投诉表单 投诉记录 🔧飞书固化
2 分级并指定处理人 客户成功专员 登记后 4 小时内 多维表格 等级与处理人 👤人工判断
3 调查原因、出整改方案 交付负责人/研发值班 一般 3 个工作日、严重 1 个工作日内 工单 原因分析 👤人工判断
4 形成处理方案（含补偿），涉及补偿走审批 客户成功专员 原因明确后 1 个工作日内 飞书审批 处理方案 🔧飞书固化
5 对客书面答复（统一口径，X-CS-17） 客户对接销售 审批后 1 个工作日内 邮件/客户群 答复记录 👤人工判断
6 整改完成后满意度回访 客户成功专员 关闭后 7 天内 电话/问卷 回访结果 🔧飞书固化
7 月度投诉复盘，输出整改项给产品/研发 客户成功专员 每月第 5 个工作日前 会议 复盘纪要 👤人工判断

5. 交付物与模板

  • 交付物：投诉台账、对客答复、回访记录、月度复盘
  • 建议模板/表单：投诉登记表（客户、渠道、投诉内容、等级、涉及合同、诉求、处理人、原因、方案、补偿、答复时间、回访结果、关闭时间）

6. 异常与升级

  • 重大投诉（解约、赔偿、媒体/上级部门介入）→ 当天升级部门负责人与管理层，法务参与
  • 超时未答复 → 机器人提醒处理人 → 升级部门负责人（超时 1 个工作日）
  • 客户对处理方案不接受 → 二次评估 → 升级管理层（3 个工作日内）

7. 衡量指标

  • 首次回应时效 = 投诉到首次回应，目标 ≤ 2 小时
  • 投诉关闭周期，一般 ≤ 5 个工作日，严重 ≤ 3 个工作日
  • 回访满意率，目标 ≥ 80%；重复投诉率，目标 ≤ 10%

8. 低效诊断

  • 聊天中未见相关流程，存在客户不满在群内发酵、补偿口径不一、回款受阻的风险（推断）

9. 分支变体

  • 渠道客户投诉：经渠道转达，由渠道经理参与答复
  • 政府客户：答复以正式函件形式，需用印（LEG-09）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 投诉三级划分标准是否合适？
  • 补偿（减免、赠额度）的审批权限归谁？
  • 是否建立定期满意度调查（季度/半年）？
X-CS-28售后访问客户环境与数据的授权留痕待新建推断200

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨5 × 险5

  • 适用场景：售后、交付、研发为排查问题需远程登录客户私有化实例、查看客户业务数据/对话记录/文件、导出日志或诊断包时，先取得客户授权、限定范围，并在操作后留痕
  • 负责人：主责——售后负责人（当前：待指定）；协同——研发值班、交付工程师、客户对接销售、法务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 判定是否需访问客户数据 → ② 向客户申请书面授权（范围、时限）→ ③ 内部登记 → ④ 最小范围访问 → ⑤ 操作记录 → ⑥ 关闭临时通道与删除导出数据 → ⑦ 告知客户结束
  • 交付结果：客户授权记录、访问登记与操作记录、通道关闭与数据删除确认
  • 状态依据：已有 X-CS-06（远程排查与诊断包收集）、X-SEC-07（客户索要 root 与远程接入的审批回收）覆盖部分环节，本条补齐我方访问客户环境与数据前的授权与操作留痕（推断）

1. 场景判定

  • 触发条件：排查需远程登录客户实例、查看客户账号下对话/文件/知识库、导出含客户数据的日志或数据库
  • 典型说法：「能不能远程上去看一下」「把他们的日志/数据导出来我们复现」
  • 判断问题：本次操作是否会看到或带走客户业务数据？是否会改动客户环境？
  • 不归本流程管：客户主动发来的截图/日志 → 请走 X-CS-06；客户索要设备 root → 请走 X-SEC-07；将数据带回用于开发 → 请走 X-FDE-22；现场变更操作 → 请走 X-DLV-42

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批人 确认访问必要性与范围 A 售后负责人（当前：待指定）
操作人 申请授权、按范围访问、记录操作 R 研发值班/交付工程师（当前：待指定）
销售 协助取得客户授权 C 客户对接销售（当前：待指定）
法务 提供授权模板、处理争议 C 法务专员（当前：待指定）

3. 办之前请准备

  • 问题工单号与排查目的
  • 需访问的系统、账号、数据范围与预计时长
  • 客户授权模板（邮件或客户群书面确认即可）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判断能否用脱敏日志替代访问 操作人 排查开始时 工单 判定结论 👤人工判断
2 向客户发送授权申请（范围、时长、操作人） 操作人/客户对接销售 访问前 邮件/客户群 客户书面同意 🔧飞书固化
3 内部登记访问申请 操作人 访问前 飞书审批 访问登记 🔧飞书固化
4 审批 售后负责人 提交后 2 小时内 飞书审批 审批结果 🔧飞书固化
5 按范围访问，不下载无关数据，记录操作 操作人 授权时长内 远程工具 操作记录 👤人工判断
6 关闭临时通道/账号，删除本地导出数据 操作人 结束后 1 个工作日内 — 关闭与删除确认 👤人工判断
7 告知客户访问结束及结论 操作人 结束后 1 个工作日内 客户群 结束通知 🔧飞书固化

5. 交付物与模板

  • 交付物：客户授权记录、访问审批单、操作记录、删除确认
  • 建议模板/表单：客户环境访问申请（客户、实例、工单号、目的、访问方式、数据范围、是否导出、预计时长、操作人、客户授权凭证、结束时间、删除确认）

6. 异常与升级

  • 紧急故障无法等待书面授权 → 先取得客户口头同意并在 24 小时内补书面 → 升级售后负责人（当时）
  • 访问中误看到超范围敏感数据 → 停止操作、不留存、如实告知 → 升级法务（当天）
  • 客户拒绝授权 → 改为指导客户自行导出脱敏日志 → 升级客户对接销售

7. 衡量指标

  • 有授权记录的访问占比，目标 100%
  • 临时通道按时关闭率，目标 100%
  • 客户数据相关投诉数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在未经授权查看客户数据、远程通道长期不关、客户数据滞留个人电脑的合规风险（推断）

9. 分支变体

  • 涉密/国企客户：只允许客户人员陪同下现场操作，不允许远程与导出
  • 公有云 SaaS 客户：访问生产数据还需走 X-SEC-18

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 合同中是否已有运维授权条款，可覆盖常规排查？
  • 客户群书面确认是否足以作为授权凭证？
  • 操作记录是否需要录屏或堡垒机审计？
X-CS-29客户服务终止、账号注销与数据返还销毁待新建推断60

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗3 × 跨4 × 险5

  • 适用场景：客户合同到期不续、解约、试用结束未转化，或客户/用户申请注销账号时，按约定停止服务、返还或导出客户数据、销毁我方留存数据并出具确认
  • 负责人：主责——售后负责人（当前：待指定）；协同——客户对接销售、研发值班、交付负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 终止触发确认 → ② 结清费用 → ③ 通知客户数据导出窗口 → ④ 协助导出/返还 → ⑤ 停服与账号/席位注销 → ⑥ 销毁我方留存数据与备份 → ⑦ 出具确认函 → ⑧ 台账关闭
  • 交付结果：数据返还/导出记录、账号与实例注销记录、数据销毁确认函、台账状态关闭
  • 状态依据：已有 X-CS-02（账号封停溯源）、X-CS-16（服务迁移中的账号与余额迁移）覆盖部分环节，本条补齐客户离网后的数据返还、账号注销与数据销毁（推断）

1. 场景判定

  • 触发条件：X-CS-26 确认不续约；SAL-36 解约生效；试用到期未转化；企业客户申请注销组织或账号
  • 典型说法：「客户不续了，他们的数据怎么处理」「用户要求注销账号删除数据」
  • 判断问题：客户/用户是否在我方系统中留有数据（账号、对话、文件、知识库、备份）？
  • 不归本流程管：异常账号封停 → 请走 X-CS-02；系统迁移 → 请走 X-CS-16；私有化硬件回收 → 请走 SAL-36；C 端个人用户的账号注销与个人信息删除请求 → 请走 OPS-29（法律口径以 LEG-34 为准）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
终止负责人 组织终止流程、出具确认函 A 售后负责人（当前：待指定）
销售 通知客户、确认结算 R 客户对接销售（当前：待指定）
研发/交付 数据导出、注销账号、销毁数据与备份 R 研发值班/交付负责人（当前：待指定）
财务 确认费用结清或退款 C 财务专员（当前：待指定）
法务 依据合同与个人信息保护要求确认处置方式 C 法务专员（当前：待指定）

3. 办之前请准备

  • 合同中数据归属、返还、保留期限条款
  • 客户在我方的账号、组织、实例、存储、备份清单
  • 费用结清情况

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认终止原因与生效日 售后负责人 触发后 2 个工作日内 台账 终止确认 👤人工判断
2 确认费用结清或退款安排 财务专员 确认后 3 个工作日内 金蝶 结算结论 👤人工判断
3 书面通知客户导出窗口（建议不少于 15 天） 客户对接销售 生效前 15 天 邮件 通知记录 🔧飞书固化
4 协助客户导出/返还数据 研发值班/交付负责人 导出窗口内 后台 导出记录 🤖自动化
5 停服、注销账号/组织/席位，回收指纹授权 研发值班/交付负责人 生效日当天 后台 注销记录 🤖+👤
6 删除生产数据与备份中的客户数据 研发值班 生效后 15 个工作日内（或按合同） 存储/备份 删除记录 🤖自动化
7 出具数据处置确认函 售后负责人 删除完成后 3 个工作日内 用印 确认函 👤人工判断
8 关闭客户台账与实例台账 售后负责人 确认函发出后 1 个工作日内 多维表格 台账关闭 🔧飞书固化

5. 交付物与模板

  • 交付物：终止通知、导出记录、注销记录、删除记录、数据处置确认函
  • 建议模板/表单：服务终止清单（客户、合同号、终止原因、生效日、费用结清、数据范围、导出方式、导出完成时间、注销项、删除项、备份删除、确认函编号）

6. 异常与升级

  • 客户逾期未导出 → 再次书面提醒，超期按合同删除 → 升级售后负责人（逾期当天）
  • 法律要求必须保留的数据（如日志留存）→ 按法定期限隔离保存，到期删除 → 升级法务
  • 费用未结清 → 暂缓删除、保留数据并冻结访问 → 升级销售负责人与财务（3 个工作日内）

7. 衡量指标

  • 终止客户数据处置完成率，目标 100%
  • 用户注销申请处理时效 = 申请到注销完成，目标 ≤ 15 个工作日

8. 低效诊断

  • 聊天中未见相关流程，存在客户数据在离网后长期留存、违反个人信息保护要求、测试/试用账号无人清理的风险（推断）

9. 分支变体

  • 私有化部署客户：数据在客户侧，我方仅删除远程诊断留存与备份
  • C 端用户注销：走产品内注销入口，按 OPS-29 受理执行，时限与留存口径以 LEG-34 为准

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 现有合同与隐私政策中数据保留期限如何约定？
  • 备份中的数据能否单独删除？若不能，按什么周期自然过期？
  • 是否需要向客户出具盖章的数据销毁确认函？

X-PRD 产品

报送人：待定 · 归属待定 · 42 条 · 已有 0 / 待优化 24 / 待新建 18
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-PRD-01产品方向、路线图与新产品形态决策出现新商机、新范式/竞品冲击、前沿热点，或产品定位（B端/C端、标品/行业版、产品形态）说法不一致时，启动方向研判，产出季度路线图或新产品形态决策。主责——产品总监（当前：杨萌·推断待确认）；决策——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、基座架构/预研负责人（当前：陈晖·推断待确认）、COO（当前：常元和·推断待确认）、IT/采购（当前：杨明学·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 机会登记 → ② AI 初研 → ③ 周研判会 → ④ 方案与可行性 → ⑤ 决策评审留 ADR → ⑥ 纳入路线图/立项 → ⑦ dogfood 验证 → ⑧ 季度复盘机会池条目、决策记录（ADR）、季度产品路线图（版本、节点、负责人）、新品立项卡待新建192
X-PRD-02竞品调研与对标评测发现竞品、竞品发布新品、行业出现同类产品、竞品申请入驻自家商城或疑似抄袭自家功能时，启动登记、评测与对标，产出可复用的对标结论。主责——产品运营（当前：杨黔昆·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）① 发现登记 → ② 分级 → ③ 基准任务评测 → ④ 对标结论 → ⑤ 结论分流 → ⑥ 月度简报 → ⑦ 任务集更新竞品档案（多维表格）、单品对标评测报告、月度竞品简报、基准任务集待新建96
X-PRD-03用户调研、专家访谈与场景案例沉淀需要验证产品价值、挖掘用户痛点、定义质量标准（如“什么是好可研”），或客户反复问“有哪些场景案例”时，组织用户访谈、专家对话、顾问群运营，并沉淀调研结论与场景案例库。主责——产品总监（当前：杨萌·推断待确认）；协同——COO（当前：常元和·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营负责人（当前：李凯·推断待确认）、研发/运维（当前：宋祺睿·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、运营/客服（当前：胡橙橙·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 调研计划 → ② 对象筛选 → ③ 约访发提纲 → ④ 访谈与转写 → ⑤ 纪要入库 → ⑥ 结论打标签分流 → ⑦ 案例入库 → ⑧ 月度简报调研计划、访谈纪要、调研结论（含用户画像判断）、场景案例库、用户/专家联系台账待优化108
X-PRD-04行业版需求摸排与产品规划新行业版（科研、投资人、法律、工程、水利、电竞、招投标、产学研等）启动或推进时，摸排行业需求，判断走标品/行业包/项目定制/暂缓，形成行业版规划和固定迭代排期。主责——产品总监（当前：杨萌·推断待确认）；协同——行业版负责人（当前：徐莉、闫登辉、吴琪、杨朋伟·推断待确认）、工程版产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、插件研发（当前：陈锦杰、季学森、侯怡辰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 行业版登记 → ② 需求摸排 → ③ 四去向分流 → ④ 规划编写 → ⑤ 规划评审 → ⑥ 排期与功能清单 → ⑦ 插件需求客户确认 → ⑧ 试用验收 → ⑨ 周度台账更新行业版需求管理表（版本详情+需求详情）、行业版规划文档、迭代排期表/功能清单、客户需求台账、行业插件需求文档待优化192
X-PRD-05需求统一收口与提需入口规则市场、销售、客户、领导、FDE、研发、合作方等任何人要对产品提功能/优化/定制需求时，一律经产品统一入口受理、评审、排期，并把结果回告提出人；禁止绕过产品直接找研发。主责——产品总监（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认，辅助审核）、客户端研发（当前：李铭熙·推断待确认，辅助审核）、测试负责人（当前：张东郅·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认，FDE 侧需求汇总）、COO（当前：常元和·推断待确认）、各业务线兼职产品对接人（当前：刘昱潇·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认，业务线需求对接）、研发（当前：杨云峰、张康、裴蔬桐、岳阳·推断待确认）、CEO（当前：邴龙志·推断待确认，战略需求提出）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认，加急审批与收口仲裁）① 表单提报 → ② 产品受理 → ③ 归类定侧 → ④ 周需求评审 → ⑤ 排入迭代 → ⑥ 开工前对齐 → ⑦ 验收 → ⑧ 回告提出人需求池中状态完整的需求单（含来源、优先级、产品确认人、验收标准、迭代、处理结果），及对提出人的回告待优化400
X-PRD-06内测与内部试用（dogfood）反馈收集分流新产品或新版本（LeapPPT、LeapAll、LeapCore、内部 AI 小站等）进入内测或全员试用时，组织内部先用起来，统一收集 bug、体验问题、需求和 Badcase，并分流到工单或需求池，结果回告反馈人。主责——产品运营（当前：杨黔昆·推断待确认）；协同——LeapAll 研发（当前：邓乾、李铭熙、岳阳·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）、研发/发版（当前：宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认，对外准入把关）；兜底——产品总监（当前：杨萌·推断待确认）① 内测公告 → ② 推动使用 → ③ 统一入口反馈 → ④ 每日 triage → ⑤ 研发认领修复 → ⑥ 发版回告 → ⑦ 周报 → ⑧ 内测复盘与准入判定内测反馈表（含状态与关联工单）、已知问题公示表、每周内测周报、内测复盘与对外准入结论待优化108
X-PRD-07外部用户、客户与销售反馈收集回流产研外部用户、客户、销售/市场一线、培训学员、内部业务系统（CRM、渠道系统）使用者提出问题或建议时，统一登记、triage（bug/体验/需求/Badcase/咨询）、回流产研，并把处理结果回告反馈人。主责——产品总监（当前：杨萌·推断待确认）；协同——产品运营（当前：杨黔昆·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态市场总监（当前：许君·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、渠道系统/CRM 负责人（当前：郭逸非·推断待确认）、渠道系统/CRM 研发（当前：陈子康·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 按规范提报 → ② 机器人入表查重 → ③ triage 定类定级 → ④ 转工单/需求池 → ⑤ 修复或答复 → ⑥ 回告与 FAQ 更新 → ⑦ 销售周汇总 → ⑧ 月度复盘反馈总表（含类型、优先级、状态、关联工单、回告情况）、客户 FAQ、销售客户问题周汇总、月度反馈复盘报告待优化300
X-PRD-08Agent Badcase 收集与转需求/缺陷工单Agent 能跑通但效果差（理解偏差、规划失败、工具调用错误、Skill 效果差、缓存命中率低等）时，保留对话样本作为 Badcase 沉淀，用于评测回归，并分流为需求或 bug 工单。主责——评测工程师（当前：黄霆瑄·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、Agent/模型研发（当前：岳阳·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）；兜底——测试负责人（当前：张东郅·推断待确认）① 提交样本 → ② 初筛 → ③ 分类分流 → ④ 入样本库标注 → ⑤ 转 Agent 能力 issue → ⑥ 修复与回归 → ⑦ 月度评测报告Badcase 样本库（含对话、标注、状态）、“Agent 能力”项目 issue、月度 Badcase 评测报告、并入基准评测集的回归用例待新建24
X-PRD-09需求提报登记与需求池管理任何人（用户、销售、交付、运营、高层、研发、测试）提出新功能或体验优化需求（非缺陷），需要查重、登记入需求池、指派负责人、跟踪状态，直到上线后通知提出人主责——产品经理（当前：杨萌·推断待确认）；协同——需求池维护/产品助理（当前：杨黔昆、陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞线产品经理（当前：徐莉、段涵、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 统一入口提报 → ② 查重归并 → ③ 登记需求池并回执 → ④ 产品评估（采纳/待定/不做） → ⑤ 入工作台指派负责人 → ⑥ 进迭代转工单并通知测试 → ⑦ 上线自动通知提出人 → ⑧ 双周查漏清理状态准确的需求池（多维表格），每条需求都有来源、提出人、负责人、评估结论、状态与上线日期；上线时自动通知提出人待优化180
X-PRD-10需求优先级评估与紧急插单高层、客户、销售或市场提出“急需求”，或多个需求争抢同一迭代时，按统一分级标准决定插单、后置、转 FDE 或拒绝主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、销售/客户经理（当前：杨朋伟、杜中瑞、闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 高优表单提报 → ② 产品按分级标准定级 → ③ 研发评估工作量与对当前迭代的影响 → ④ 决策（插单/下迭代/转 FDE/拒绝） → ⑤ 回执提出人 → ⑥ 插单则等量移出并通知测试 → ⑦ 每周同步重点队列带分级、决策结论和理由的“重点需求队列”；插单决定附“移出项清单”；提出人收到书面答复待新建192
X-PRD-11客户定制需求评估、标品化判断与报价估算大客户、渠道或客户 Demo 提出定制需求时，先澄清需求，再判断标品吸收、开关隔离、FDE Skill 还是项目定制，输出范围、人日、成本价和排期，交商务定价主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、基座研发/FDE（当前：望政韬、黄振锋、张康·推断待确认）、商务负责人（当前：常元和·推断待确认）、销售（当前：刘昱潇、吴琪、杨朋伟、闫登辉·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 定制需求提报 → ② 需求澄清（问卷+资料格式） → ③ 标品化判定 → ④ 范围与人日评估（含研发 Review） → ⑤ 输出成本价与兜底规则 → ⑥ 商务定价与立项 → ⑦ 隔离开发与按版本冒烟 → ⑧ 客户确认版需求清单发出定制需求评估单（范围、标品化结论、人日、成本价、售后边界、排期），以及发给客户确认的需求清单待新建300
X-PRD-12跨产品线/版本线能力同步与适配决策某产品线上线新能力，或主线客户端发布新版本时，决定是否、何时、以何种范围同步到其他产品线、信创版或基座组件主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座架构负责人（当前：陈晖·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发版或新能力触发 → ② 自动生成能力变更清单 → ③ 产品逐项标注同步决策 → ④ 各线评估工作量与依赖 → ⑤ 按跟版规则定适配窗口 → ⑥ 测试排期 → ⑦ 登记同步台账并通知跨线同步台账（能力项 × 产品线 × 是否同步 × 目标版本），以及每次主线发版对应的适配排期待新建81
X-PRD-13PRD 撰写与需求评审需求进入开发前，按模板写 PRD/原型并做 AI 预审，召开评审会确认技术可行性，发布评审结论和需求文档，让研发拿到能直接实现的需求主责——产品经理（当前：杨萌·推断待确认）；协同——产品专员（当前：陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、前端/后端评审代表（当前：季学森、侯怡辰、宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、UI 设计（当前：康紫馨·推断待确认）、跃竞线产品经理（当前：段涵、徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 判定是否需写 PRD → ② 按模板撰写 → ③ AI Review 与追问澄清 → ④ 前后端技术初评 → ⑤ 评审会宣讲与结论记录 → ⑥ 已读确认 → ⑦ 拆 issue 并关联 PRD → ⑧ 会议结论转行动清单与任务评审通过的 PRD（含评审结论、字段变更、不做什么、验收标准）、评审会纪要与行动清单、关联 PRD 的 issue待优化192
X-PRD-14业务规则与统计口径定义需求未写清的业务规则（额度归属、折扣、分账、状态定义、支付限额等），或同一指标在不同端、不同报表的计算不一致时，由产品定义规则/口径并全链路统一主责——对应产品线产品经理（当前：鼎慧线黄飞鹏、跃竞线徐莉·推断待确认）；协同——Leap 线产品经理（当前：杨萌·推断待确认）、跃竞产品（当前：段涵、樊九辰·推断待确认）、后端研发（当前：蒋兴武、王子明、张楠、陈锦杰、王皓南·推断待确认）、测试（当前：赵伟龙、李国庆·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 发现规则/口径疑问 → ② 工单打“待产品确认”标签提问 → ③ 产品给出结论（资金类会签） → ④ 写入业务规则与口径词典 → ⑤ 通知研发/测试/运营 → ⑥ 测试按口径验证 → ⑦ 存量数据影响处理 → ⑧ 上线公告业务规则与统计口径词典（每条有定义、公式、取值区间、生效版本），以及对应的实现与测试验证记录待优化144
X-PRD-15产品命名、术语与用户可见文案规范新产品、模块、型号需要命名，或出现说法不一、内部技术名词外露、报错与提示文案不清时，统一命名与术语表，规范对外口径和用户可见文案主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品专员（当前：陈震·推断待确认）、前端研发（当前：葛家和、侯怡辰·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 命名/文案需求提出 → ② 生成候选并查重（重名、商标、域名、禁用词） → ③ 拍板定名 → ④ 登记命名与术语表 → ⑤ 发布通知与改名影响清单 → ⑥ 代码/界面/文档统一修改 → ⑦ 用户可见文案对照表维护 → ⑧ 发版前禁用词扫描命名与术语表（内部名/对外名/中文名/代码字段/禁用词/商标状态）、错误码—文案对照表、改名影响清单完成记录待新建72
X-PRD-16UI/UX 设计需求、评审与设计走查新功能/页面需要设计，或界面风格不一致时，提设计需求、评审设计稿或方案、前端还原、设计走查并完成 UI 验收，规范和素材统一沉淀主责——产品经理（当前：杨萌；跃竞线段涵·推断待确认）；协同——UI 设计师（当前：康紫馨、史家宜、陈伟康·推断待确认）、前端研发（当前：岳阳、葛家和、季学森、侯怡辰、郝智豪、魏小东、陈真炎·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品专员（当前：杨黔昆、陈震、黄飞鹏、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提设计需求单 → ② 设计排期（无设计资源时 AI 原型） → ③ 开发前草图/方案评审 → ④ 高保真稿交付（标注、切图、状态稿、版本号） → ⑤ 前端还原 → ⑥ 设计走查 → ⑦ 产品 UI 验收 → ⑧ 规范与素材归档评审定稿的设计稿（统一入口、带版本号）、设计走查记录、UI 验收结论，以及持续更新的设计规范（色卡、组件、图标）与素材库待优化72
X-PRD-17风险功能准入与合规需求评估产品功能可能带来安全或法务风险（加载本机插件、执行系统命令、对外开放数据接口），客户 IT 提出安全合规要求（禁用命令、防批量拷贝、操作审计），或用户协议/隐私政策首次上线、内容更新、需要用户重新同意时，进开发排期前先完成风险评估和准入决策主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、LeapCore 后端（当前：杨云峰·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、协议功能研发（当前：魏宗浩·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 登记风险/合规需求 → ② 风险分级 → ③ 技术路径与成本评估 → ④ 法务与合同条款评审 → ⑤ 准入决策 → ⑥ 落地风险提示、开关或协议版本 → ⑦ 上线前复核 → ⑧ 归档并答复客户风险评估单（结论为准入/有条件准入/不准入）、上线的风险提示组件与功能开关（如开发者模式）、合同免责条款或对客承诺边界说明、协议版本台账与用户同意记录待新建150
X-PRD-18模型选型、档位配置与评测出现新模型或新渠道、现有模型不稳定、上游成本或折扣变化、客户反馈体验问题时，评估并决定用户可选模型上下架、经济/标准/专家档位背后的模型与思考强度、企业版开放的模型和 Skill 范围主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、测试与评测负责人（当前：张东郅·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、NewAPI 配置（当前：张康·推断待确认）、客户端/Skill Store（当前：李铭熙·推断待确认）、后端（当前：杨云峰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提出候选模型/调整 → ② 接入测试服并配成本 → ③ 跑评测集与试用 → ④ 输出评测结论 → ⑤ 决策档位映射与上下架 → ⑥ 测试环境验证后生产切换 → ⑦ 更新档位方案一页纸并通知 → ⑧ 上线后观察与回退评测报告、当前档位方案一页纸（档位/模型/渠道/思考强度/倍率/生效日期）、生产配置变更记录、对客档位说明口径、企业版模型与 Skill 开放清单待优化192
X-PRD-19第三方能力与外部方案调研选型接入产品需要接入外部 API、SaaS 或新能力（OCR、视频生成、企业信息查询、电子签、外呼、客户远程访问等）时，完成调研对比、成本与合规评估、选型决策，并交出接入清单与排期主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、接入研发（当前：魏宗浩·推断待确认）、后端/核价（当前：宋祺睿·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、网关（当前：吴世豪·推断待确认）、总经办采购（当前：待指定）、市场商务对接（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 提需求并写清场景 → ② 归类入接入清单 → ③ 调研 2～4 个方案 → ④ PoC 实测 → ⑤ 成本、定价与合规评估 → ⑥ 选型评审决策 → ⑦ 采购开户与凭据入库 → ⑧ 接入开发、计费配置与上线排期选型对比表、PoC 结论、选型决策记录、第三方接入清单条目（类别、计费方、对接人、状态）、接口清单与计费 ID、采购/开户记录待新建240
X-PRD-20Skill 上架审核、开发者入驻与分润客户、OPC 开发者或第三方申请在开放平台/Skill Store/OPC 平台上架 Skill 或应用，需要入驻审核、竞品准入判断、按次扣费配置和分润结算规则时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill Store/客户端（当前：李铭熙·推断待确认）、商城研发（当前：邓乾·推断待确认）、网关研发（当前：岳阳、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开发者入驻申请 → ② 资质与协议签署 → ③ 提交 Skill 与扣费声明 → ④ 自动预检 → ⑤ 人工审核（含竞品与安全） → ⑥ 上架与计费配置 → ⑦ 调用计量与分润结算 → ⑧ 更新/下架/注销处理入驻记录与开发者协议、审核记录、上架的 Skill 商品（名称、描述、分类、价格、扣费规则）、调用量统计、分润结算单待优化180
X-PRD-21内置技能评估与技能商店内容维护公司自研的 Skill/插件新开发或更新后，评估是内置进客户端、由开放平台下发还是只上技能商店；以及技能商店里的描述、分类、版本维护，和开放平台下发技能/场景包/行业参数的接口契约对接主责——Skill 负责人（当前：李凯·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill 开发（当前：邓乾、魏宗浩·推断待确认）、builtin 审查（当前：岳阳·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、客户端与 LeapAuth/Update（当前：宋祺睿、杨云峰·推断待确认）、Skill Store/私有 Hub（当前：李铭熙·推断待确认）、产品排期（当前：陈震·推断待确认）、测试（当前：潘浩伟·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 提交 Skill 及测试结果 → ② 安全与格式审查 → ③ 内置/下发/商店评审 → ④ 建工单排期 → ⑤ 填写商店内容并上架或内置 → ⑥ 发版验收 → ⑦ 商店内容日常维护 → ⑧ 下发接口契约变更同步Skill 评审记录（结论为内置/开放平台下发/仅商店/不上线）、排期工单、上架或内置的 Skill（名称、描述、分类、版本、计费说明）、技能商店内容台账、下发接口契约文档待优化108
X-PRD-22模型/API 售价、倍率调整与对外价格表同步上游模型成本、汇率、折扣变化，或新模型/新能力（视频、OCR、企业信息查询）上线，或平台首次上线需要定价时，测算毛利、确定倍率与档位售价、配置网关计费，并同步对外价格表与模型清单主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、v5 后端与发布（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、AIAPI 渠道维护（当前：杨明学、吴世豪·推断待确认）、NewAPI 配置（当前：邓乾·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务（当前：待指定）；定价批准——COO（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别价格变动 → ② 更新成本价 → ③ 测算毛利与建议售价 → ④ 定价审批 → ⑤ 提 PR 改网关价格并补测试 → ⑥ 测试环境验证后发布 → ⑦ 同步对外价格表与模型清单 → ⑧ 通知销售与财务对账价格主表新版本（成本价、倍率、售价、生效时间）、定价审批记录、合并发布的计费配置、对外价格表与模型清单、价格变更通知待优化240
X-PRD-23产品套餐、积分/额度定价与计费规则产品商业化、公测、新增付费档位（如 Pro/高画质）、上线充值、邀请奖励、注册赠送或额度包时，完成成本测算，确定积分/词元/额度单价、套餐与赠送规则、计费口径，并落到开发与验收主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/扣费实现（当前：宋祺睿、邓乾·推断待确认）、LeapPPT 研发（当前：马漳毓、黄振锋·推断待确认）、运营方案（当前：李凯·推断待确认）、产品经理（当前：杨黔昆、黄飞鹏·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 立项定价需求 → ② 真实场景成本测算 → ③ 拟定价与激励方案 → ④ 定价评审拍板 → ⑤ 出计费口径单 → ⑥ 开发实现并引用口径单 → ⑦ 口径对账与上线检查 → ⑧ 发布说明与上线后监控成本测算表、定价决策记录、计费口径单（售价、成本、毛利、换算比例、赠送、并发限制）、已上线的套餐/额度包配置、对用户的计费说明待新建300
X-PRD-24硬件产品配置选型、成本评估与供应商问题反馈出现新机型或供应商新报价、硬件配置要变更（CPU、RAID、新增屏幕或外壳开模）、客户询问能跑多大模型或硬件跑不动、渠道系统需要标准席位与增配规则，以及录音卡等硬件出现固件问题需要反馈工厂时启动主责——硬件负责人（当前：杨明学·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、供应商对接与成本核算（当前：闫登辉·推断待确认）、配置文档维护（当前：游家豪·推断待确认）、商务定价（当前：李鹏为、常元和·推断待确认）、模型规格评估（当前：望政韬·推断待确认）、后端（当前：杨云峰·推断待确认）、外包硬件对接人（当前：吕振·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 登记触发事项 → ② 技术方案与成本核算 → ③ 选型/变更评审 → ④ 商务拍板售价 → ⑤ 更新标准配置与席位 SKU 表 → ⑥ 发布对外口径、作废旧版 → ⑦ 有效期到期复核 → ⑧ 硬件问题反馈工厂并闭环硬件选型/变更评审记录、标准配置表（带版本与有效期）、“型号×内存×硬盘→席位/并发/参考价”标准表、对外配置与价格口径、模型×硬件基线表、硬件问题清单与工厂反馈记录待优化180
X-PRD-25AI 报告提示词与报告类型配置变更字字可研等 AI 报告产品要新增报告类型或项目类型、调整提示词（目录或正文），或者业务专家提交新的提示词、专业类型、法规类型等配置时启动。主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——业务专家/提示词作者（当前：王满·推断待确认）、后端研发（当前：王皓南·推断待确认）、平台研发（当前：宋祺睿·推断待确认）、前端研发（当前：待指定）、测试（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 登记变更 → ② 产品审核类型与字段 → ③ 自动通知并校验覆盖率 → ④ 研发接入/配置 → ⑤ 在测试环境生成验证 → ⑥ 业务专家验收 → ⑦ 不通过的开整改单 → ⑧ 随版本上线并标记版本提示词库中带版本号、状态为“已上线”的提示词记录；对应报告类型能在生产环境正常生成；变更记录和整改记录都能追溯。待优化81
X-PRD-26行业案例、测试数据与知识库素材获取产品或行业 Skill 开发需要真实案例、测试数据、评判标准或行业资料，要向合作方、客户、外包爬虫或自有数据源获取，并清洗入库时启动。主责——需求方产品经理（当前：杨萌·推断待确认）；协同——数据/爬虫研发（当前：魏宗浩·推断待确认）、后端研发/查库（当前：王皓南·推断待确认）、业务专家（当前：王满·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、FDE/Skill 研发（当前：邓乾、李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、平台研发（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 写数据需求单 → ② 盘点现有库存与缺口 → ③ 选定来源并约定截止日 → ④ 获取并留痕 → ⑤ 脱敏、清洗、转换 → ⑥ 入 test 库，抽样检查 → ⑦ 产品验收后入 prod 或评测集 → ⑧ 登记素材台账按类型分好、已脱敏、有标签的案例集、测试数据集或知识库数据（test/prod），以及一份记录来源、范围、覆盖率的素材台账。待新建180
X-PRD-27迭代规划、故事拆分与排期每个迭代开始前（两周或一周一迭代），汇总评审通过的需求，拆成 issue 或故事卡，估点数，分配到人，确定迭代范围和交付日；迭代中插入需求或迭代末迁移未完成项时也适用。主责——产品负责人/迭代负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、段涵·推断待确认）、研发复杂度评估（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 产品出下迭代需求（D-5）→ ② 研发估点（D-3）→ ③ 按容量砍需求、低优先级移入待评估池 → ④ 迭代计划会 → ⑤ 建 milestone/issue 并分配到人 → ⑥ 成员按天拆任务 → ⑦ 迭代末迁移未完成项一份迭代计划，含需求清单、点数、负责人、交付日、待评估池；每个需求有对应 issue 并挂在 milestone 上；工作台任务视图更新完毕。待优化108
X-PRD-28开发中需求澄清与产品拍板研发或测试在开发、测试中遇到需求细节没定义、预期行为不确定（看起来像 bug 又像设计）、术语或权限语义有分歧、新集成要选技术方案，需要产品澄清或拍板时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 在工单按模板提问 → ② 自动 @ 模块产品 → ③ 产品限时答复或拍板 → ④ 有争议的开 15 分钟对齐会 → ⑤ 结论回写工单和决策记录表 → ⑥ 涉及术语、规则的同步更新术语表或规则台账 → ⑦ 通知相关研发和测试工单里有明确的产品结论（谁定、何时定、结论是什么）；决策记录表新增一条；需要时同步更新需求文档、术语表、权限矩阵或业务规则台账。待优化135
X-PRD-29需求变更控制开发中的需求要被砍、范围或文案调整、临时追加，或实现与原型不一致需要改，包括演示和发布前体验者提的新需求、前线口头协商的需求时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、前线/解决方案（当前：李凯·推断待确认）、发布冻结期变更审批人（当前：常元和·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交变更单 → ② 研发评估影响 → ③ 产品决定（本迭代/下迭代/拒绝）→ ④ 冻结期另需审批人同意 → ⑤ 更新需求文档、原型和工单 → ⑥ 机器人通知研发和测试 → ⑦ 调整排期和测试点 → ⑧ 判断是否重新评审一条已审批的需求变更记录（变更内容、影响、决定、决策人）；需求文档、工单、原型都已同步更新；研发、测试收到通知，排期已调整。待优化192
X-PRD-30迭代站会、进度追踪与交付节点管理迭代执行期的日常站会和迭代回顾；多项目、多客户、多版本并行时，需要统一追踪关键交付节点、发布进度和延期预警时启动。主责——项目经理/进度负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、技术顾问（当前：望政韬·推断待确认）、后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/部署（当前：杨明学·推断待确认）、商务对接（当前：闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、CEO（知会）（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 站会前更新 issue 和任务状态 → ② 固定时间开站会 → ③ 站会决议写入迭代文档 → ④ 维护“客户×版本×节点”里程碑台账 → ⑤ 机器人每日汇总进度 → ⑥ 节点前 2 天预警 → ⑦ 延期决策并通知 → ⑧ 迭代末开回顾会每日站会纪要；实时更新的里程碑台账（客户、版本、模块、截止日、负责人、状态）；延期通报；迭代回顾的改进待办。待优化240
X-PRD-31产品验收研发完成需求、准备转测试（ready-for-test）前，或新版本上线前，需要产品逐项或逐模块确认实现符合需求（含计费口径和文案）时启动。主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、提交验收的研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：涂维轩、黄霆瑄、潘浩伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 研发自测后附录屏和验收地址，改状态为“待产品验收” → ② 机器人 @ 指定验收人 → ③ 产品按验收标准走查 → ④ 通过：留痕并流转测试 → ⑤ 不通过：评论问题并退回 → ⑥ 技术单改由研发负责人和测试联合验收 → ⑦ 迭代末清点状态 → ⑧ 发版前内测，同步已知问题每张功能工单上都有“验收人 + 结论 + 截图/录屏 + 日期”的留痕；通过的进入测试，不通过的有明确问题清单；发版前有已知问题清单。待优化180
X-PRD-32AI 生成质量评测与领域专家验收字字可研等 AI 报告产品出了新版本或新生成能力（仿写、套模板、先审后生、测算规则），需要工程师、领域专家或客户审核人评价，做双盲对比，或业务规则不明需要领域专家澄清并验收时启动。主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——领域专家（当前：王满·推断待确认）、后端研发/方案（当前：王皓南·推断待确认）、测算与功能研发（当前：季学森、陈锦杰、侯怡辰·推断待确认）、外部可研工程师（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 明确评测目标和验收标准 → ② 准备评测样本 → ③ 生成多版本样稿 → ④ 隐去来源做双盲 → ⑤ 专家按评分表打分并写一句话感受 → ⑥ 汇总结论，AI 解析客户修订痕迹 → ⑦ 整改项进缺陷单 → ⑧ 复测，结论归档一份评测结论（各版本得分、优劣、是否达到上线或客户审核标准），一份整改清单（负责人、截止日、复测状态），评测样本和评分表归档后可复用。待新建240
X-PRD-33产品改版数据迁移与版本切换产品结构改版（如建议书/可研拆为独立项目类型）或业务体系升级（如会员体系从单俱乐部升级为联盟级、品牌端迁移），需要把存量业务数据迁到新结构并切换到新版本主责——所属产品线产品负责人（当前：杨萌（鼎慧/Leap）、段涵（跃玩）·推断待确认）；协同——后端研发（当前：宋祺睿、蒋兴武·推断待确认）、研发核对人（当前：王皓南·推断待确认）、前端（当前：郝智豪、魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、知识库数据研发（当前：魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 迁移立项与影响面评估 → ② 产品拍板迁移规则 → ③ 编写迁移方案（含回档/回滚） → ④ 测试环境演练与对账 → ⑤ 抽检验收 → ⑥ 择时生产迁移（灰度） → ⑦ 迁移后对账巡检 → ⑧ 关闭旧逻辑并归档一份经产品签核的《数据迁移方案》、测试与生产两次迁移的数量对账记录、抽检记录、迁移后 7 天巡检报告；新版本切换完成且旧逻辑下线待新建160
X-PRD-34功能分批上线、入口隐藏与提审模式某功能的依赖（正式合同、发票、渠道系统 API、正式环境密钥）未就绪，或小程序需要过平台审核，需要拆分上线、隐藏入口或开启审核模式，待条件满足后再放开主责——产品总监（当前：杨萌·推断待确认）；协同——研发（当前：陈锦杰、魏宗浩、宋祺睿、王皓南·推断待确认）、渠道系统负责人（当前：丁震宇·推断待确认）、小程序前端（当前：郝智豪、魏小东·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、法务/财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 上线前依赖检查 → ② 判定拆分/隐藏/审核模式 → ③ 登记功能开关 → ④ 研发隐藏入口或配置审核模式 → ⑤ 验收隐藏效果 → ⑥ 依赖就绪评审 → ⑦ 放开入口并通知 → ⑧ 清理开关一张功能开关清单（每个被隐藏/延后功能的原因、依赖、放开条件、负责人、状态），以及按清单执行的上线版本或提审包待优化144
X-PRD-35产品发版/内测公告与通知分发新产品或新版本进入内测、公测、正式发布，或计费/会费等规则变更、官网变更、故障停机时，按统一模板和渠道对内（全员、市场、销售）、对外（用户、俱乐部、内测客户）发布公告与安装包/升级通知主责——产品发布负责人（当前：杨萌·推断待确认）；协同——运营宣发（当前：李凯·推断待确认）、对外口径审核（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、跃竞线对外通知（当前：徐莉·推断待确认）、研发发布（当前：王皓南·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发布就绪检查 → ② 定性（内测/公测/正式）与发布时间 → ③ 按模板起草公告 → ④ 口径、福利、保密审核 → ⑤ 按渠道表分发 → ⑥ 统一下载页更新与客户版本登记 → ⑦ 反馈收集与问题跟进审核通过并按渠道发出的公告（内部群、市场/销售群、公众号/推文、俱乐部公告、客户群），统一下载页的最新链接，以及发布记录待优化240
X-PRD-36产品手册与使用说明维护产品发版、新功能开放、客户/渠道索要使用手册，或新产品/硬件交付缺少说明时，维护用户手册、管理员手册、操作说明、授权教程和随机说明书，统一存放在知识库并保证版本一致主责——所属产品线产品经理（当前：杨萌（LeapCore/字字可研/MercAll）、段涵与陈雁（跃玩/星域/会员端）·推断待确认）；协同——手册站点开发（当前：魏小东·推断待确认）、产品使用网站（当前：宫经喜·推断待确认）、文档编写研发（当前：邓乾、李铭熙、张康·推断待确认）、销售渠道（当前：闫登辉、王满·推断待确认）、交付（当前：游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 发版或索要触发 → ② 确认手册唯一来源 → ③ 起草/更新（AI 草稿） → ④ 研发核对 → ⑤ 产品审核并标注“可外发” → ⑥ 发布到知识库/帮助中心/手册站点 → ⑦ 通知销售客服 → ⑧ 定期巡检每条产品线一套带版本号的手册（用户手册、管理员手册、更新说明），存放在唯一指定的知识库位置，并标注是否可对外分享待优化72
X-PRD-37小产品/实验产品快速内测与发布用 AI 快速做出的小产品/实验产品（如 OPC-MBTI 测评、论文工具、八字等）需要确定目的、评审数据采集需求、内部测试、收集反馈并对内外发布或上架售卖主责——小产品产品负责人（当前：杨黔昆·推断待确认）；协同——研发（当前：岳阳·推断待确认）、测试（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、运营宣发（当前：李凯、陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 一页立项（目的、用户、渠道） → ② 需求与数据采集评审 → ③ 研发部署测试链接 → ④ 产品验收+测试过一遍 → ⑤ 清理测试数据、上线前检查 → ⑥ 内测邀请+表单收反馈 → ⑦ 反馈筛选入排期 → ⑧ 对外发布/上架与售后规则一份小产品立项单、一张上线前检查表、一张内测反馈多维表格与排期结果、对外发布物料；付费产品附定价与售后条款待优化108
X-PRD-38内部业务系统建设归口与数据主责边界内部系统（CRM、渠道系统、合同系统、项目系统、金蝶、运营中台等）新建或扩功能时出现功能重复、数据冲突或多个团队各自建设，需要划定单一数据源和系统边界，统一归口建设并约定数据同步规则主责——内部系统归口负责人（当前：丁震宇·推断待确认）；协同——综合部负责人/业财主数据标准（当前：赵雪冰·推断待确认）、总经办（当前：田杰·推断待确认）、内部系统研发负责人（当前：陈子康·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、产品总监（名词统一，当前：杨萌·推断待确认）、需求方（当前：徐莉、陈梦琪、李凯、吴琪、李鹏为、杜中瑞·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 新系统/新功能需求进入统一需求池 → ② 查重与归属判定 → ③ 对照数据主责矩阵 → ④ 边界与同步规则评审 → ⑤ 财务/业务口径书面确认 → ⑥ 指定系统负责人建设 → ⑦ 迁移“先同步、再校验、后停写” → ⑧ 更新矩阵并公告一张《数据主责矩阵》（每类数据的唯一写入系统、同步方向、负责人）、一页“系统职责边界说明”（如 CRM vs 渠道系统）、统一的内部系统需求池待新建160
X-PRD-39产品使用数据统计与导出产品或业务需要用户使用数据（用户数、活跃、使用情况）做分析或汇报，需从后台导出，或把重复的导出固化为后台报表/定时推送主责——后端研发（数据导出/报表）（当前：宋祺睿·推断待确认）；协同——产品总监（需求方/口径定义，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 提交取数申请（口径、范围、用途、截止时间） → ② 判断是否已有报表 → ③ 有则自助导出 → ④ 无则研发导出并保存脚本 → ⑤ 交付结果 → ⑥ 同类需求第 2 次出现即排期固化为后台报表 → ⑦ 开通查看权限按约定口径的统计文件或后台报表/看板，以及可重复执行的导出脚本待新建36
X-PRD-40产品/研发岗位工作交接产品负责人将缺席迭代、人员调岗、新人接手，或小产品中途换负责人时，需要按交接清单移交需求、反馈、代码与资料，并经带教确认接手人能独立工作主责——交出方直属负责人（当前：产品线杨萌、研发线宋祺睿·推断待确认）；协同——交出人、接手人、研发技术负责人（当前：王皓南·推断待确认）、人事（当前：黄莹·推断待确认）、小产品接手人（当前：岳阳、杨黔昆·推断待确认）、需求发起方（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）① 确认交接事项与接手人 → ② 交出人按清单写交接文档 → ③ 打包仓库/账号/资料 → ④ 交接会议（文档+当面） → ⑤ 带教期跟做 → ⑥ 接手人独立完成一项任务 → ⑦ 三方确认交接完成 → ⑧ 公告并更新职责表一份经交出人、接手人、直属负责人三方确认的交接文档（含职责、需求池、反馈分流、仓库、环境、账号、待办、联系人），以及更新后的职责分工表待新建144
X-PRD-41私有化版本支持策略与旧版本停止维护LeapCore 等产品同时存在多个私有化/一体机/信创/行业版客户版本时，明确支持哪些版本、维护多久、何时强制升级、何时停止修复，并对内对外公布主责——产品总监（当前：待指定）；协同——研发负责人、交付负责人、售后负责人、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 统计在网版本分布 → ② 制定支持策略（如支持最近 N 个大版本）→ ③ 评审发布 → ④ 版本到期前通知 → ⑤ 推动升级 → ⑥ 停止维护 → ⑦ 例外审批版本支持策略文档、在网版本分布表、停止维护通知待新建96
X-PRD-42产品/功能下线（EOL）与停服通知公司决定停止某个产品、产品线、站点或付费功能（含实验产品、分站、旧网关、套餐）时，评估影响、制定迁移与退款方案、提前通知用户并有序下线主责——产品总监（当前：待指定）；协同——研发负责人、运营负责人、售后负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 下线提议 → ② 影响评估（用户、付费、合同、数据）→ ③ 决策 → ④ 迁移/退款方案 → ⑤ 提前公告 → ⑥ 停止售卖 → ⑦ 停服下线 → ⑧ 数据处置与资源释放下线决策记录、对外公告、迁移/退款完成记录、资源释放记录待新建120
X-PRD-01产品方向、路线图与新产品形态决策待新建192

状态：待新建｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：出现新商机、新范式/竞品冲击、前沿热点，或产品定位（B端/C端、标品/行业版、产品形态）说法不一致时，启动方向研判，产出季度路线图或新产品形态决策。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；决策——创始人兼 CTO（当前：丁震宇·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、基座架构/预研负责人（当前：陈晖·推断待确认）、COO（当前：常元和·推断待确认）、IT/采购（当前：杨明学·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）、苏州销售负责人（当前：刘昱潇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 机会登记 → ② AI 初研 → ③ 周研判会 → ④ 方案与可行性 → ⑤ 决策评审留 ADR → ⑥ 纳入路线图/立项 → ⑦ dogfood 验证 → ⑧ 季度复盘
  • 交付结果：机会池条目、决策记录（ADR）、季度产品路线图（版本、节点、负责人）、新品立项卡
  • 状态依据：全年未见成文路线图；「鼎慧产研决策部」2026-01 提出做路线图时无方法、无模板；「模态AI探索小分队」2026-01～03、「开源聚变入驻问题沟通群」2026-03 的方向结论在群聊中边聊边定，本地/云端等路线反复争论约 3 次；「模态集团（全员群）」2026-03 集中反映热点反应慢、决策链长、研判无人负责。

1. 场景判定

  • 触发条件：（a）每季度末前 2 周需定下季度路线；（b）出现可能改变路线的竞品、新范式或技术热点（如 Claw 类 Agent、Agent OS）；（c）商务带来新产品形态或新客群（高端礼品、硬件分发、学生版等）；（d）内部对目标客户、B/C 定位出现冲突说法。
  • 典型说法：「该做roadmap了」「看完人家在做的事情之后得回来想我们要怎么做」「做2C时间一定不能拉长」「好的信息出现的早，但都行动晚」「我们公司本身自己就应该是目标用户」
  • 判断问题：这件事会不会改变“做什么产品 / 给谁用 / 以什么形态交付 / 本季度资源投向”？会 → 本流程；只是某个功能做不做 → 需求流程。
  • 不归本流程管：单个竞品的体验评测 → 请走 X-PRD-02；用户访谈执行 → 请走 X-PRD-03；行业版需求摸排与迭代排期 → 请走 X-PRD-04；具体功能需求提报 → 请走 X-PRD-05。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
方向流程 owner 维护机会池、组织研判会、起草方案/路线图/ADR R 产品总监（当前：杨萌·推断待确认）
方向决策人 评审会拍板，确认 ADR A 创始人兼 CTO（当前：丁震宇·推断待确认）
战略终审 主体定位、重大投入、对外承诺类决策终审 A（升级） CEO（当前：邴龙志·推断待确认）
初研研究人 生成初研稿并逐条人工核验来源 R 产品总监指定的研究人（按议题指定）
技术可行性 技术路线、工作量、底座复用评估 C 研发技术负责人（当前：王皓南·推断待确认）；基座架构负责人（当前：陈晖·推断待确认）
路线一致性 判断是否偏离公司主线、商业是否成立 C COO（当前：常元和·推断待确认）；苏州销售负责人（当前：刘昱潇·推断待确认）
硬件可行性 ODM 询价、开模与成本评估 C IT/采购（当前：杨明学·推断待确认）
客户信号 提供订单/意向、首批试用 C 销售总监/客户经理（当前：吴琪·推断待确认）；市场销售负责人（当前：李鹏为·推断待确认）
全员 提交机会线索、参与 dogfood I 全员

3. 办之前请准备

  • 机会描述：来源链接、发现日期、一句话说明“它改变了什么”
  • 竞品/热点事实材料，全部附原始来源（AI 生成的竞品信息必须可溯源、经人工核验）
  • 目标客群假设与已有订单/意向信号（用客户A/客户B 指代）
  • 粗略成本：研发人周、硬件投入、外部采购
  • 与现有路线图的冲突点（会挤占哪个版本/哪些人）
  • 本次会议要产出的结论清单（定位选项、场景功能点、形态、负责人）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 把机会/热点登记到“机会池”，标来源、类型、紧急度 任一发现人 发现后 1 个工作日内 飞书多维表格（机会池） 机会条目 🔧飞书固化
2 生成初研稿：竞品做法、技术路线、市场信号，人工核验来源 产品总监指定的研究人 登记后 2 个工作日内 deep research 类 AI + 飞书文档 1～2 页研判稿 🤖+👤
3 周研判会（30 分钟）过新增条目，给出跟进/观察/放弃 产品总监主持，CTO、研发技术负责人参加 每周固定 1 次；紧急热点 48 小时内加开 飞书会议 + 智能纪要 研判结论写回机会池 👤人工判断
4 “跟进”条目出方案：定位、目标客群、形态备选对比（如本地/云端、安装包/U盘）、成本、可行性 产品总监 + 研发技术负责人；涉硬件拉 IT/采购 研判会后 5 个工作日内 飞书文档（方案模板） 方案稿（含 ≥2 个备选） 🤖+👤
5 决策评审：提前 1 个工作日发材料，会上只讨论待决事项并当场拍板 决策人 CTO；重大事项 CEO 终审 方案完成后 3 个工作日内 飞书会议 ADR 决策记录 👤人工判断
6 ADR 归档，在相关群发布结论；已定事项本季度不重开，除非有新证据 产品总监 评审后 1 个工作日内 飞书知识库 ADR 目录 + 群公告 结论公告 + ADR 链接 🔧飞书固化
7 纳入季度路线图或新建立项卡，拆里程碑与负责人 产品总监 评审后 3 个工作日内 多维表格（路线图/立项卡） 路线图新版本 🔧飞书固化
8 内部 dogfood 或首批用户试用，收集反馈 产品总监组织，全员/客户代表参与 首个可用版本后 2 周 反馈表单（见 X-PRD-06） 验证结论 🔧+👤
9 季度复盘：路线图兑现情况、方向是否调整、下季度路线 产品总监，CTO、CEO 参加 每季度最后 2 周内 路线图多维表格 下季度路线图 👤人工判断

5. 交付物与模板

  • 交付物：机会池条目；研判稿；方案稿；ADR；季度路线图；新品立项卡
  • 机会池字段：标题、来源链接、发现人、发现日期、类型（竞品/热点/商机/定位冲突）、紧急度、研判结论（跟进/观察/放弃）、负责人、关联 ADR
  • ADR 模板：背景、待决问题、备选方案（≥2）、决策、理由、明确不做什么、生效日期、决策人、复审触发条件
  • 季度路线图字段：产品线、版本、目标客群、核心能力、发布节点、负责人、依赖、状态
  • 新品立项卡字段：定位、目标客群、场景与功能点、形态（软件/软硬一体）、成本估算、订单/意向、可行性结论、首批用户、责任人、硬件投入门槛是否满足

6. 异常与升级

  • 热点窗口期短（预计 2 周内失效）→ 跳过周会，48 小时内开快速决策会 → CTO 当场拍板，当天知会 CEO
  • 已有 ADR 的路线被重复争论 → 先查 ADR，无新证据不重开 → 坚持重开者提交复审申请给 CTO，3 个工作日内答复
  • 涉及硬件开模或大额采购 → 无订单/意向不进入开模 → 升级 CEO 审批（5 个工作日内）
  • AI 生成的竞品材料无法溯源 → 退回补来源，不得进入评审 → 产品总监把关
  • 方向与公司主线冲突（ToC vs ToB/ToG）→ 提交 CEO、COO 联合决策（1 周内）
  • A（升级）说明：常规方向研判与路线图由方向决策人（CTO）拍板；涉及主体定位变更、硬件开模或大额投入、对外承诺、与公司主线冲突四类事项时，拍板权升级到 CEO 终审

7. 衡量指标

  • 热点响应时长：机会登记到研判结论的自然日，目标 ≤ 3 天（紧急 ≤ 2 天）
  • 决策留痕率：方向性决策有 ADR 的比例，目标 100%
  • 无新证据重开次数：季度内重开已定 ADR 的次数，目标 0
  • 路线图兑现率：季度内按期发布项 / 计划项，目标 ≥ 70%
  • 立项卡完整率：新品立项卡关键字段齐全的比例，目标 100%

8. 低效诊断

  • 现象：无路线图文档，季度目标临时口头商定，承接环节缺方法与模板｜依据：「鼎慧产研决策部」2026-01
  • 现象：竞品/新范式出现后“快速出 demo”类想法多次提出，但无立项与跟进记录；公司路线说法不一｜依据：「模态AI探索小分队」2026-01、2026-02、2026-03
  • 现象：同一技术路线（本地 vs 云端、分发形态）在群聊多次重开，目标客户在学生/政企/渠道之间摇摆，结论散落在长线程｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：热点信息出现早但行动晚，情报淹没在多个 AI 频道，研判无固定角色、决策链长｜依据：「模态集团（全员群）」2026-03、「开源聚变入驻问题沟通群」2026-03
  • 现象：新品形态评审后才发现竞品图为 AI 生成、产品不存在；硬件投入门槛无人事先定义，事后才提出“无订单不开模”｜依据：「【龙智】高端礼品渠道沟通群」2026-08
  • 现象：核心卖点不清，调研与决策跨两个群，背景需要反复解释｜依据：「LeapCore（archived）」2026-04

9. 分支变体

  • 季度路线图制定：按步骤 7、9 的固定节奏执行，季度末前 2 周启动。
  • 前沿热点快速研判：步骤 1 → 3（48 小时内加开）→ 5，可先给“观察 / 小规模试做”结论，试做不超过 1 周。
  • 新产品形态（纯软件，只改 LeapCore 配置）：可省略硬件可行性评估。
  • 新产品形态（软硬一体：定制壳、外显屏、录音卡等）：必须过 IT/采购可行性评估和“有订单/意向再投入”门槛。
  • B端/C端定位重梳：CEO、COO 参与，结论写入 ADR 并同步销售口径。
  • 方向不清时 dogfood 辅助决策：先以公司内部为第一用户试用 2 周再定。
  • 产品线差异：LeapCore（B端企业）、LeapAll（C端）、手机端、盒子、字字可研（垂类）。

10. 待确认问题

  • 方向决策人是 CTO 还是 CEO？哪些事项（金额、主体、对外承诺）必须 CEO 终审？
  • 是否设立固定的“前沿研判小组”？成员和周会时间如何定？
  • 季度路线图由产品总监统一维护，还是各产品线维护后汇总？
  • 硬件投入的“有订单/意向”门槛如何量化（意向数量或金额）？
  • “已定 ADR 本季度不重开”的规则是否可行？ADR 放在哪个知识库目录？
X-PRD-02竞品调研与对标评测待新建96

状态：待新建｜证据：有证据（卡片 9 张 / 会话 7 个）｜优先级：频4 × 耗2 × 跨4 × 险3

  • 适用场景：发现竞品、竞品发布新品、行业出现同类产品、竞品申请入驻自家商城或疑似抄袭自家功能时，启动登记、评测与对标，产出可复用的对标结论。
  • 负责人：主责——产品运营（当前：杨黔昆·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——产品总监（当前：杨萌·推断待确认）
  • 核心流程：① 发现登记 → ② 分级 → ③ 基准任务评测 → ④ 对标结论 → ⑤ 结论分流 → ⑥ 月度简报 → ⑦ 任务集更新
  • 交付结果：竞品档案（多维表格）、单品对标评测报告、月度竞品简报、基准任务集
  • 状态依据：全年无竞品档案和评测模板；「跃迁AI总动员」2026-05～06 多人各自做同类对比、标准主观；「LeapCore（archived）」2026-04 采购的竞品硬件试用后无结论沉淀；「字字可研项目群」2026-03～08 对比散在群聊。

1. 场景判定

  • 触发条件：（a）有人在群里转发竞品/新品链接；（b）竞品发布会或版本更新；（c）同类产品申请入驻自家商城；（d）发现自家功能、页面或计算逻辑被竞品参考；（e）采购了竞品硬件/账号需要试用。
  • 典型说法：「竞品来了」「可以做同一个任务对比一下leapall」「玩完写使用心得」「大家都体验一下，和我们的产品也做一下对比和思考」「现在的重点不是能不能 而是值不值得」
  • 判断问题：这次是要“了解对手、找差距或出宣传素材”吗？是 → 本流程；要据此决定公司做不做新产品/改方向 → 交 X-PRD-01。
  • 不归本流程管：方向/新产品形态决策 → 请走 X-PRD-01；把可借鉴点做成需求 → 请走 X-PRD-05；对外宣传稿发布 → 请走 BRD-08（新媒体日常内容生产与发布）/ BRD-09（事件型宣发稿与新闻稿）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
竞品档案 owner 登记、分级、指派评测、出月度简报 R 产品运营（当前：杨黔昆·推断待确认）
对标结论审批 审评测结论，决定“值不值得跟” A 产品总监（当前：杨萌·推断待确认）
技术评测 架构、Skill、Agent 能力拆解 R 研发技术负责人（当前：王皓南·推断待确认）；研发（当前：宋祺睿、邓乾·推断待确认）
基准任务集 维护中文任务集与评分口径 R 测试负责人（当前：张东郅·推断待确认）；比赛/案例组长（当前：白福康·推断待确认）
评测人 按指派做同任务对比、起草对标报告 R 产品运营从技术评测、业务场景评测成员中指派
业务场景评测 以客户场景做对比 C FDE/运营负责人（当前：李凯·推断待确认）；苏州销售负责人（当前：刘昱潇·推断待确认）；工程咨询业务专家（当前：王满·推断待确认）
情报纪要 竞品发布会纪要与转发 C 开放平台负责人（当前：郭逸非·推断待确认）
入驻/抄袭应对 商城入驻申请把关、防抄处置 C 生态组负责人（当前：陈梦琪·推断待确认）；法务负责人（当前：李瑶·推断待确认）
方向升级 涉及路线时拍板 I 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 竞品名称、官网/下载链接、版本号、价格档位、试用账号（账号放密码管理工具，不贴群）
  • 本次评测目的：找差距 / 出宣传素材 / 应对入驻 / 应对抄袭
  • 从基准任务集中选定的任务（如 PPT、海报、可研报告、Agent 多步任务）
  • 自家对照版本（LeapAll/LeapCore/LeapPPT/字字可研的具体版本）
  • 截图与录屏工具；购买付费版需先走采购（FIN-01）或报销（FIN-06）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现即登记竞品档案（名称、链接、版本、发现人），群里只贴档案链接 任一发现人 发现当天 飞书多维表格（竞品档案）+ 群机器人一键登记 档案条目 🔧飞书固化
2 分级：情报类（只存档）/ 评测类 / 威胁类（入驻申请、疑似抄袭），评测类指派 1 名评测人 产品运营 登记后 1 个工作日内 竞品档案 分级与指派 👤人工判断
3 用基准任务集做同任务对比，记录过程截图与耗时 评测人 指派后 3 个工作日内 基准任务集 + 录屏 评测原始记录 🤖+👤
4 按模板写对标结论：功能、质量、稳定性、价格、可借鉴点、值不值得跟 评测人起草，产品总监审 评测后 2 个工作日内 飞书文档（评测模板） 对标报告 🤖+👤
5 结论分流：可借鉴点进需求池（X-PRD-05）；可作宣传的对比给市场；涉方向的转 X-PRD-01 产品运营 审批后 1 个工作日内 需求池 / 市场素材库 分流记录 🔧飞书固化
6 威胁类处理：入驻申请先暂缓受理并提交管理层决定；疑似抄袭交研发查日志、交法务评估 生态组负责人 / 研发技术负责人 / 法务 发现后 1 个工作日内启动 登录日志、商城后台 处置记录 👤人工判断
7 月度竞品简报：本月新增、重点变化、对我方影响 产品运营 每月第 1 周 AI 汇总档案 + 群消息 月度简报 🤖自动化
8 基准任务集更新，补充新场景与评分口径 测试负责人 每季度 1 次 任务集仓库/多维表格 任务集新版本 👤人工判断

5. 交付物与模板

  • 交付物：竞品档案、对标报告、月度简报、基准任务集
  • 竞品档案字段：竞品名、所属类别（通用 Agent/PPT/垂类/硬件）、链接、版本、价格、发现日期、发现人、分级、评测人、结论摘要、截图附件、更新日期
  • 对标报告模板：评测目的、版本与环境、任务清单、逐项对比表（功能/质量/稳定性/速度/价格）、可借鉴点、不建议跟进项、是否值得做、来源链接
  • 基准任务集字段：任务 ID、场景、输入、期望产出、评分维度与分值、适用产品

6. 异常与升级

  • 竞品信息无法核实（疑似 AI 生成或盗版站）→ 标“未核实”，不得进入报告结论 → 产品运营复核（1 个工作日内）
  • 竞品申请入驻自家商城 → 暂缓受理，不对外表态 → 管理层决策（5 个工作日内）
  • 发现账号异常转借、异地登录、功能被抄 → 研发查日志并冻结异常账号 → 研发技术负责人当天决策；法律动作升级法务和 CEO
  • 需要爬取竞品数据 → 先提交法务评估，未批准不得执行 → 法务（3 个工作日内）
  • 评测需付费购买 → 请走 FIN-01（对公采购申请与付款审批）或 FIN-06（日常费用报销提交与审核） → 部门负责人审批

7. 衡量指标

  • 档案覆盖率：群内出现的竞品被登记的比例，目标 ≥ 90%
  • 评测周期：指派到对标报告审批的工作日，目标 ≤ 5 天
  • 重复评测次数：同一竞品同一版本被重复评测次数，目标 0
  • 结论转化率：对标报告中可借鉴点进入需求池的比例（统计口径，不设硬目标，按月观察）
  • 月度简报准时率：目标 100%

8. 低效诊断

  • 现象：成员各自试用、截图讨论，看过的页面翻不到，对竞品版本有争议｜依据：「鼎慧产研决策部」2026-04、2026-05
  • 现象：同一竞品多人重复做对比，评价标准偏主观（审美/稳定性/价格），无共享评测表｜依据：「跃迁AI总动员」2026-05、2026-06
  • 现象：竞品发布会纪要和对比信息淹没在群聊，后续找不到｜依据：「跃迁AI总动员」2026-08、2026-09
  • 现象：采购的竞品硬件试用后没有沉淀评测结论｜依据：「LeapCore（archived）」2026-04
  • 现象：竞品申请入驻商城时无既定规则，临时口头处理｜依据：「LeapAll（Deprecated）」2026-04
  • 现象：垂类竞品对比散落群聊，无结论归档｜依据：「字字可研项目群」2026-04、2026-06、2026-08
  • 现象：发现被参考/抄袭后一天内临时救火，爬取竞品数据的合规边界无人判断｜依据：「工程咨询产研」2026-03
  • 现象：多人重复转发同类热点，无汇总机制｜依据：「开源聚变入驻问题沟通群」2026-03

9. 分支变体

  • 软件竞品（Genspark、Manus、WorkBuddy、QoderWork、Kimi、Claude Code 套壳类）：标准流程。
  • 行业垂类竞品（标书 AI、可研/报告生成、Skill 类）：评测人加入工程咨询业务专家，任务集用行业样例。
  • 竞品硬件试用：采购走 FIN-01，评测模板增加“部署难度、隔离性、对 LeapCore 的启示”。
  • 竞品申请入驻自家商城：商城入驻审核增加“同业审核”项，是否合作由管理层判断。
  • 被抄袭/账号转借：账号异常登录告警、计算逻辑后端化、专利评估，法律动作必须人工决策。

10. 待确认问题

  • 竞品档案 owner 放在产品运营是否合适？还是由 FDE/评测岗承担？
  • 基准任务集由测试负责人维护是否可行？是否需要外部数据集合作？
  • 竞品入驻商城的“同业审核”规则由谁定、写入哪份商城规则？
  • 爬取公开数据的合规边界是否已有法务意见？
  • 月度简报是否并入公司周报/月报？
X-PRD-03用户调研、专家访谈与场景案例沉淀待优化108

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：需要验证产品价值、挖掘用户痛点、定义质量标准（如“什么是好可研”），或客户反复问“有哪些场景案例”时，组织用户访谈、专家对话、顾问群运营，并沉淀调研结论与场景案例库。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——COO（当前：常元和·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认）、运营负责人（当前：李凯·推断待确认）、研发/运维（当前：宋祺睿·推断待确认）、销售骨干（当前：闫登辉·推断待确认）、运营/客服（当前：胡橙橙·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 调研计划 → ② 对象筛选 → ③ 约访发提纲 → ④ 访谈与转写 → ⑤ 纪要入库 → ⑥ 结论打标签分流 → ⑦ 案例入库 → ⑧ 月度简报
  • 交付结果：调研计划、访谈纪要、调研结论（含用户画像判断）、场景案例库、用户/专家联系台账
  • 状态依据：字字可研线已有访谈问题文档和调研方式汇总 wiki，「字字可研市场运营」2026-01～03 执行较完整；但「鼎慧产研决策部」2026-02 “找专家算谁的工作”反复讨论、无调研计划表，「LeapPPT」2026-05 目标用户口径不一，「LeapCore（archived）」2026-06 案例集尚未成型。

1. 场景判定

  • 触发条件：（a）新产品/新版本上线前需验证价值；（b）对质量标准或目标客户有争议；（c）获得可访谈的用户、专家、客户走访机会；（d）客户反复询问场景案例。
  • 典型说法：「需要非常深度的调研用户，把最好的可研的标准梳理出来」「当务之急是找专家」「第一次先聊三位」「我给上次的用户拉个群」「我们要尽快整理一份leapcore场景利用案例集」
  • 判断问题：我是要“主动去问用户/专家来回答一个产品问题”吗？是 → 本流程；用户主动来报 bug/提需求 → 走反馈流程（X-PRD-07）。
  • 不归本流程管：用户主动提交的问题与 bug → 请走 X-PRD-07；内部员工试用反馈 → 请走 X-PRD-06；行业版需求摸排 → 请走 X-PRD-04；方向决策 → 请走 X-PRD-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
调研 owner 立计划、定提纲、汇总结论、维护台账 R/A 产品总监（当前：杨萌·推断待确认）
目标用户筛选 圈定代表性用户、提供客户资源 C COO（当前：常元和·推断待确认）；销售总监/客户经理（当前：吴琪·推断待确认）
行业访谈执行 约访工程师/专家、行业专业判断 R 工程咨询业务专家（当前：王满·推断待确认）
运营访谈与日报 C 端用户访谈、客服日报 R 运营负责人（当前：李凯·推断待确认）；运营/客服（当前：胡橙橙·推断待确认）
技术陪访 现场判断技术可行性 C 研发技术负责人（当前：王皓南·推断待确认）
案例库维护 场景案例整理入库 R 研发/运维（当前：宋祺睿·推断待确认）；销售骨干（当前：闫登辉·推断待确认）
结论使用 根据结论调整路线/需求 I 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 调研目的与要验证的 1～3 个假设
  • 目标用户画像（如：愿付费的白领、业主类、工程师类、职业代写、设计院、超级个人用户）
  • 访谈提纲（≤10 题，提前发给受访者预告方向）
  • 受访者的产品使用记录（如有）
  • 录音/转写工具与受访者同意；客户资料保密要求
  • 专家评审时准备待评样例与评分表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 写调研计划：目的、假设、画像、样本数（首轮 3 位起）、负责人、截止日 调研 owner 启动后 2 个工作日内 飞书文档（调研计划模板） 调研计划 🔧飞书固化
2 筛选受访者并登记台账；查其使用记录 调研 owner + 客户资源提供方 计划后 3 个工作日内 多维表格（用户/专家台账） 受访名单 👤人工判断
3 约访，提前 1 天发提纲 访谈执行人 访谈前 1 个工作日 飞书日程 访谈日程 🔧飞书固化
4 访谈，全程录音并 AI 转写 访谈执行人（技术陪访可选） 按约定时间 飞书会议妙记 转写稿 🤖自动化
5 纪要入库：关键原话、痛点、期望、是否目标用户 访谈执行人 访谈后 1 个工作日内 飞书知识库 + 台账回填 访谈纪要 🤖+👤
6 汇总结论并打标签（画像/痛点/严重度），可落地的进需求池，方向性的转 X-PRD-01 调研 owner 一轮访谈结束后 3 个工作日内 多维表格 + 需求池 调研结论 👤人工判断
7 客户场景整理成案例（场景、原做法、用产品后做法、效果、可演示素材），入案例库 案例库维护人 走访后 5 个工作日内 案例库多维表格 场景案例 🔧+🤖
8 用户顾问群固定每周 1 次访谈时段，问题与回答入台账 调研 owner 每周 飞书群 + 台账 周访谈记录 🔧飞书固化
9 月度调研简报：本月访谈数、主要结论、画像变化 调研 owner 每月第 1 周 AI 汇总台账 月度简报 🤖自动化

5. 交付物与模板

  • 交付物：调研计划、访谈纪要、调研结论、场景案例库、用户/专家台账
  • 台账字段：对象类型（用户/专家/客户）、画像、所属行业、来源、访谈日期、执行人、是否目标用户、关键结论、纪要链接、后续动作
  • 访谈纪要模板：背景、使用现状、痛点 Top3、原话摘录、对竞品看法、付费意愿、结论标签
  • 案例模板：行业、部门、场景、原流程与耗时、产品方案、效果、演示素材、可对外程度
  • 质量评分表（专家评审用）：可自动检查项（字数、引用、政策文号是否有效）+ 专家打分项

6. 异常与升级

  • 约不到合适受访者 → 扩大到销售/COO 客户资源 → 调研 owner 3 个工作日内仍无进展升级 CTO
  • 受访者明显不是目标用户 → 纪要标注“非目标”，不计入结论 → 画像争议提交 X-PRD-01 定口径
  • 内部业务同事反馈主观、无法量化 → 改用评分表 → 调研 owner
  • 访谈涉及客户保密资料 → 只在授权范围内存档，不转发外部群 → 销售总监/客户经理确认
  • 案例素材缺失 → 在案例库标“缺素材”并指派 → 5 个工作日未补齐升级产品总监

7. 衡量指标

  • 访谈纪要入库率：访谈后 1 个工作日内入库的比例，目标 100%
  • 月度有效访谈数：目标客群访谈数，目标 ≥ 4 次/月（按产品线）
  • 结论转化率：调研结论进入需求池或路线图的条数 / 结论总数，按月观察
  • 场景案例数：案例库可对外案例数，目标每季度新增 ≥ 5 个
  • 画像一致性：纪要中“是否目标用户”字段填写率，目标 100%

8. 低效诊断

  • 现象：没有“好可研”的评判标准，内部反馈主观、部分不反馈，各自总结后才同步｜依据：「鼎慧产研决策部」2026-01、2026-02
  • 现象：“找专家”归属不清反复讨论，靠个人人脉推进，无调研计划表｜依据：「鼎慧产研决策部」2026-02
  • 现象：用户顾问群建立后访谈过程无记录｜依据：「鼎慧产研决策部」2026-03
  • 现象：对“谁是目标用户”未统一，反馈分散在不同群｜依据：「LeapPPT」2026-05
  • 现象：目标客户定义不清，访谈前需反复讨论约谁｜依据：「字字可研市场运营」2026-03
  • 现象：客户反复问有哪些场景，案例集尚未成型｜依据：「LeapCore（archived）」2026-06

9. 分支变体

  • 字字可研/工程咨询：受访者分业主类、工程师类、职业代写、设计院、超级个人用户；专家评审报告需配评分表。
  • 用户顾问群：只拉配合度高的用户，研发可直接提问，但问答须回填台账。
  • 运营访谈与客服日报：客服 AI 日报作为输入，每周由运营挑选深访对象。
  • 客户走访：以场景需求为主，产出直接进入场景案例库与需求池。
  • 内部业务同事反馈：作为参考，不替代外部用户访谈。

10. 待确认问题

  • 调研 owner 是否统一由产品总监承担，还是按产品线拆分？
  • 各产品线的目标用户画像谁来最终定义？是否走 X-PRD-01 的 ADR？
  • 场景案例库归产品还是归市场维护？
  • 每月 ≥ 4 次访谈的目标是否合理？
  • 外部专家的合作方式（兼职顾问/按次付费）是否已有制度？
X-PRD-04行业版需求摸排与产品规划待优化192

状态：待优化｜证据：有证据（卡片 5 张 / 会话 6 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：新行业版（科研、投资人、法律、工程、水利、电竞、招投标、产学研等）启动或推进时，摸排行业需求，判断走标品/行业包/项目定制/暂缓，形成行业版规划和固定迭代排期。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——行业版负责人（当前：徐莉、闫登辉、吴琪、杨朋伟·推断待确认）、工程版产品经理（当前：黄飞鹏·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）、插件研发（当前：陈锦杰、季学森、侯怡辰·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 行业版登记 → ② 需求摸排 → ③ 四去向分流 → ④ 规划编写 → ⑤ 规划评审 → ⑥ 排期与功能清单 → ⑦ 插件需求客户确认 → ⑧ 试用验收 → ⑨ 周度台账更新
  • 交付结果：行业版需求管理表（版本详情+需求详情）、行业版规划文档、迭代排期表/功能清单、客户需求台账、行业插件需求文档
  • 状态依据：已有行业版需求管理表、填写规则和需求池流转做法（某组已稳定使用），但「【模态】行业版leapcore」2026-06 需反复催填，「【行业版Leapcore】投资人版」2026-08 规划被连续追问约 9 次并多次返工，「工程咨询产研」2026-10 插件需求缺素材与模板。

1. 场景判定

  • 触发条件：（a）决定切出新的独立行业版；（b）行业版负责人需要标品支持；（c）为某行业客户新做插件（监理规划、初步设计、专项债、围标串标识别、效果图等）；（d）行业版需求积压需排入迭代。
  • 典型说法：「请各行业版负责人按下面格式在群里回复」「我需要一个跟leap产品一样的迭代排期表」「市场侧过来的需求需要走工作台我来评审」「根据已有资料编写需求文档初稿，并发客户各板块工程师确认」
  • 判断问题：这条需求是否属于某个行业版的规划范围？需要判断“进标品还是行业定制”吗？是 → 本流程。
  • 不归本流程管：通用需求提报入口与收口规则 → 请走 X-PRD-05；是否新开一条产品线的方向决策 → 请走 X-PRD-01；客户项目交付与验收 → 请走 X-DLV-19（客户现场/远程部署实施与上门安排）/ X-DLV-29（交付签收单、验收单与开票跟进）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
行业版需求总负责 维护需求管理表、分流四去向、组织评审 R 产品总监（当前：杨萌·推断待确认）
行业版立项与规划审批 定是否切独立行业版、指定负责人、审规划 A CEO（当前：邴龙志·推断待确认）
行业版负责人 填摸排与需求、维护客户需求台账、提供订单信息 R 跃竞负责人（当前：徐莉·推断待确认）；销售骨干（当前：闫登辉·推断待确认）；销售总监/客户经理（当前：吴琪·推断待确认）；商务/项目经理（当前：杨朋伟·推断待确认）
工程版产品 功能清单与排期表维护 R 工程版产品经理（当前：黄飞鹏·推断待确认）
行业需求编写与验收 写插件需求初稿、客户确认、试用反馈 R 工程咨询业务专家（当前：王满·推断待确认）
插件研发 方案对齐、模板/demo、发测试环境 R 研发（当前：陈锦杰、季学森、侯怡辰·推断待确认）
评审 参与规划/需求评审 C FDE/运营负责人（当前：李凯·推断待确认）；创始人兼 CTO（当前：丁震宇·推断待确认）；COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 行业版名称、负责人、目标客户类型、已签/拟签订单（用客户A 指代，订单额填区间）
  • 已做内容与进度、需要标品支持的能力
  • 高频、高 token、可持续付费的场景清单（规划必填）
  • 插件需求：输入材料、预期输出、样例（含客户方真实样例或替代样例）
  • 合作方依赖与其可投入时间

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 行业版登记：是否切独立行业版、负责人、目标客户 行业版负责人提出，CEO 确认 提出后 3 个工作日内 需求管理表（版本详情页） 行业版条目 🔧+👤
2 需求摸排：表单提交场景、已做、进度、需标品支持、负责人、预估订单额、颗粒度、优先级（题目 ≤10） 行业版负责人 摸排发起后 3 个工作日内 飞书表单 → 多维表格 需求详情 🔧飞书固化
3 分流四去向：标品 / 行业包 / 项目定制 / 暂不处理；有订单的优先 产品总监 收齐后 3 个工作日内 需求管理表 分流结论 👤人工判断
4 编写行业版规划：目标客户、高频付费场景、MVP、迭代节奏、标准能力清单（通用+行业 skill+行业微调） 产品总监或工程版产品经理，行业版负责人协同 立项后 10 个工作日内出初版 飞书文档（规划模板） 规划初版 🤖+👤
5 规划评审，不通过的写明具体缺项 CEO 主持，产品总监、行业版负责人参加 初版提交后 3 个工作日内 飞书会议 评审结论 👤人工判断
6 建排期表/功能清单，按周迭代，展示进度、状态、节点 工程版产品经理/产品总监 评审通过后 2 个工作日内 多维表格（各行业版统一排期视图） 排期表 🔧飞书固化
7 插件需求：业务专家写需求文档初稿 → 客户方各板块工程师确认 → 交研发；必要时现场对需求 工程咨询业务专家 初稿 3 个工作日；客户确认 5 个工作日内 需求模板 + 多维表格 已确认需求文档 🤖+👤
8 研发出模板/demo 发测试环境，业务专家试用反馈，通过后排上线 插件研发 / 业务专家 每个迭代内 测试环境 试用结论 👤人工判断
9 需求池状态流转：状态 + 当前负责人字段，状态变化自动通知产研，修改意见写在条目评论；不再做的置“关闭” 产品总监 持续；每周评审 1 次 多维表格 + 飞书工作流 状态更新 🔧飞书固化
10 周度提醒未填/未更新负责人，周报汇总各行业版进度 机器人 + 产品总监 每周一 飞书机器人 周报 🤖自动化

5. 交付物与模板

  • 交付物：行业版需求管理表、规划文档、排期表/功能清单、客户需求台账、插件需求文档
  • 需求管理表字段：行业版、需求标题、场景、来源客户、预估订单额区间、颗粒度、优先级（P0 不得超过 20%）、去向、当前负责人、状态、迭代、评论
  • 规划模板：目标客户、核心场景（高频/高 token/持续付费）、MVP 范围、标准能力清单、迭代节奏、里程碑、依赖与风险
  • 插件需求模板：输入材料、预期输出、样例、验收标准、客户确认人、保密级别

6. 异常与升级

  • 行业版负责人超期未填 → 机器人第 2 次提醒仍未填 → 升级 CEO（周会点名环节，不在群里点名）
  • 规划被评“太泛” → 评审必须列出具体缺项 → 二次评审仍不通过由 CEO 指定补写人（1 周内）
  • 依赖合作方无时间 → 标记阻塞并评估自研替代 → CEO 决定（5 个工作日内）
  • 客户方无样例素材 → 业务专家与客户约定替代样例 → 3 个工作日无果升级产品总监
  • 项目定制需求挤占标品 → 定制排在标品后，确需插队须 CEO 审批

7. 衡量指标

  • 摸排回收率：截止日前提交的行业版比例，目标 100%（无需催办）
  • 规划首版周期：立项到规划评审通过的工作日，目标 ≤ 15 天
  • 迭代准时率：周迭代按期交付比例，目标 ≥ 80%
  • 需求分流时效：需求提交到给出去向的工作日，目标 ≤ 3 天
  • 插件返工率：插件需求确认后因理解偏差重做的比例，目标 ≤ 10%

8. 低效诊断

  • 现象：首次摸排问卷题目过多，“演示案例”与“核心用例”口径不一｜依据：「鼎慧产研决策部」2026-06
  • 现象：需求管理表依赖反复催填，摸排信息过简被要求补充，订单信息不在表内｜依据：「【模态】行业版leapcore」2026-06、2026-08
  • 现象：行业版规划进度被连续追问，“太泛”“需要完整”标准不明，规划多次重写，依赖合作方时间｜依据：「【行业版Leapcore】投资人版」2026-08
  • 现象：高频需求判断依赖临时追问，功能清单到后期才建立｜依据：「【行业版Leapcore】工程版」2026-07、2026-09
  • 现象：各组各自搭需求表，驳回规则不统一｜依据：「【跃迁】高管群」2026-03
  • 现象：插件开发缺素材要在群里临时问，报告类插件因设计过重重做｜依据：「工程咨询产研」2026-10

9. 分支变体

  • 工程版：由工程咨询客户驱动，插件需求必须经客户方工程师确认；功能清单由工程版产品经理维护。
  • 投资人版：依赖合作伙伴 skill 与客户数据，规划需列明合作方交付节点。
  • 招投标版：涉及外部 SaaS 接入时，先评估“外部接入 vs 自研插件”，由 CEO 决策。
  • 法律版、电竞版、产学研版等：首次登记后按标准流程执行；已有订单的需求优先。
  • 需求池流转：研发需求不设驳回；测试驳回改状态并写评论；市场侧需求先过产品评审再进池。

10. 待确认问题

  • 是否切独立行业版、指定负责人的决策权是否统一在 CEO？
  • 各行业版是否统一使用一张需求管理表和一套排期视图？
  • “每周一个迭代”对所有行业版是否都适用？
  • P0 占比上限 20% 是否可接受？
  • 客户资料（样例、内部文件）在测试环境中的保密要求由谁定？
X-PRD-05需求统一收口与提需入口规则待优化400

状态：待优化｜证据：有证据（卡片 13 张 / 会话 12 个）｜优先级：频5 × 耗4 × 跨5 × 险4

  • 适用场景：市场、销售、客户、领导、FDE、研发、合作方等任何人要对产品提功能/优化/定制需求时，一律经产品统一入口受理、评审、排期，并把结果回告提出人；禁止绕过产品直接找研发。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——研发技术负责人（当前：王皓南·推断待确认，辅助审核）、客户端研发（当前：李铭熙·推断待确认，辅助审核）、测试负责人（当前：张东郅·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认，FDE 侧需求汇总）、COO（当前：常元和·推断待确认）、各业务线兼职产品对接人（当前：刘昱潇·推断待确认）、销售总监/客户经理（当前：吴琪·推断待确认，业务线需求对接）、研发（当前：杨云峰、张康、裴蔬桐、岳阳·推断待确认）、CEO（当前：邴龙志·推断待确认，战略需求提出）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认，加急审批与收口仲裁）
  • 核心流程：① 表单提报 → ② 产品受理 → ③ 归类定侧 → ④ 周需求评审 → ⑤ 排入迭代 → ⑥ 开工前对齐 → ⑦ 验收 → ⑧ 回告提出人
  • 交付结果：需求池中状态完整的需求单（含来源、优先级、产品确认人、验收标准、迭代、处理结果），及对提出人的回告
  • 状态依据：收口原则已多次口头宣布（「鼎慧产研决策部」2026-05～06、「LeapCore（archived）」2026-05、「Leap产研测」2026-10），市场需求准入规则在「【模态】行业版leapcore」2026-06～07 执行一致；但入口在群聊、表单、Gitea、需求池多处并存，绕过产品、临时加急、研发自行加功能后被砍等情况仍反复出现。

1. 场景判定

  • 触发条件：（a）任何人想让研发做/改一个功能；（b）客户、合作方提出新 Skill 或定制；（c）销售/市场想拉产研参加客户会；（d）研发想自行调整产品逻辑；（e）旧需求入口要切换到新系统。
  • 典型说法：「不要随口提需求」「非产品提需求统一给产品收口」「产研非必要不开外部会」「有啥提需求的通道吗」「别一句话提完需求就没了 都得闭环起来」「别增加噪声，确定好是FDE侧的需求还是基座的需求」
  • 判断问题：这件事做完会改变产品功能或研发排期吗？会 → 必须进需求池；只是使用咨询或已知 bug → 走反馈流程（X-PRD-06 / X-PRD-07）。
  • 不归本流程管：bug 与体验问题 → 请走 X-PRD-06（内部）/ X-PRD-07（外部）；Agent 效果差 → 请走 X-PRD-08；行业版规划 → 请走 X-PRD-04；方向性决策 → 请走 X-PRD-01；合同内外与付费增项判断 → 请走 X-PRD-11（客户定制需求评估、标品化判断与报价估算）；已交付客户对新需求的承诺确认 → 请走 X-CS-14。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求唯一入口 owner 受理、归类、组织评审、排期、回告 R/A 产品总监（当前：杨萌·推断待确认）
提出人 按表单提交需求、补齐必填项、接收回告 R（提报） 任何提需求的同事、客户对接人、合作方对接人
辅助审核 技术可行性、工作量、拆工单 C 研发技术负责人（当前：王皓南·推断待确认）；客户端研发（当前：李铭熙·推断待确认）
验收 验收标准把关、测试 C 测试负责人（当前：张东郅·推断待确认）
FDE 侧汇总 汇总 FDE 侧/基座侧技术需求，周度交产品 R 开放平台负责人（当前：郭逸非·推断待确认）
业务线需求对接 本业务线需求整理成单、跟进闭环 R 苏州销售负责人（兼水利项目产品对接，当前：刘昱潇·推断待确认）；销售总监/客户经理（当前：吴琪·推断待确认）
全员意见收口 “人人都是产品经理”意见池的归口 C COO（当前：常元和·推断待确认）
研发执行 只接已确认需求，开工前同步理解 R 研发（当前：杨云峰、张康、裴蔬桐、岳阳·推断待确认）
加急审批/仲裁 加急插队审批、收口争议仲裁 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
战略需求 业务线方向性需求提出与优先级 C CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 需求一句话标题 + 场景说明（谁在什么情况下要做什么）
  • 来源：客户（客户A/订单号）、内部、合作方、竞品对标
  • 客户阶段：已购 / 拟下单 / 洽谈中 / 无订单
  • 期望结果与验收标准、截止日期及理由
  • 依赖（数据、第三方接口、权限）与截图/原型
  • 属于哪一侧：标品 / 行业包 / 定制 / FDE 侧 / 基座侧 / 内部业务系统
  • 请求最少包含字段：标题、场景（谁在什么情况下要做什么）、提出人岗位、来源与客户阶段、期望日期及理由、验收标准、所属侧；缺项由机器人退回补充，不进入受理

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过唯一表单提交需求（群里提的由机器人一键转单，提出人补必填项） 提出人 产生需求当天 飞书表单 → 需求池多维表格 需求单（需求池多维表格，自动编号回复提出人） 🔧+🤖
2 受理：查重、补问、AI 补全上下文与验收标准草稿 产品总监 提交后 1 个工作日内 需求池 + AI 助手 已受理/退回补充（需求池状态，自动通知提出人；超时→CTO 指定代受理人） 🤖+👤
3 归类定侧：标品/行业包/定制/FDE 侧/基座侧/内部系统；FDE 侧由 FDE 汇总人每周汇总后进入 产品总监、FDE 侧汇总人 受理后 2 个工作日内 需求池“来源侧”字段 归属侧（需求池“来源侧”字段） 👤人工判断
4 每周需求评审会：定做/不做/暂缓、优先级；定制与合作方需求排在标品后 产品总监主持，研发技术负责人、测试负责人参加 每周 1 次 飞书会议 + 需求池 评审结论（需求池状态 + 评审纪要链接） 👤人工判断
5 排入迭代，状态变化自动通知提出人与研发 产品总监 评审后 1 个工作日内 需求池 + 飞书工作流 → Gitea 工单 迭代排期（需求池迭代字段 + Gitea 工单号回填） 🔧飞书固化
6 开工前对齐：原型/界面要什么不要什么、验收标准；研发同步理解与方案 产品总监 + 研发 开工前 1 个工作日 原型/Gitea issue 已确认的 issue（Gitea，含原型链接与验收标准） 👤人工判断
7 开发中研发不得自行增删功能；需变更时回到产品确认 研发 发现需变更当天提出 Gitea issue 评论 变更记录（Gitea issue 评论 + 需求池备注） 👤人工判断
8 验收：按验收标准走查，必要时录屏 产品总监 + 测试负责人 提测后 2 个工作日内 测试环境 验收结论（需求池状态：待验收→已上线/打回） 👤人工判断
9 回告提出人：已上线版本 / 不做原因 / 暂缓到何时 产品总监（机器人自动推送） 状态关闭当天 飞书机器人 闭环回告（机器人推送提出人，需求池记录回告时间） 🤖自动化

5. 交付物与模板

  • 交付物：需求单、周评审结论、迭代排期、验收记录、回告消息
  • 需求单字段：标题、场景、提出人、来源（客户/内部/合作方/竞品）、客户阶段、订单号、来源侧、优先级、期望日期、验收标准、产品确认人、当前负责人、状态（待受理/已受理/评审中/已排期/开发中/待验收/已上线/关闭）、关联工单、处理结果
  • 加急申请字段：加急理由、影响客户、被挤出的需求、审批人
  • 市场需求准入规则：只收集需求时由产品对接整理，不拉研发；客户推进到下单/拟下单阶段才安排产研参会

6. 异常与升级

  • 有人绕过产品直接找研发 → 研发不接，回复“请先提需求单并告知产品” → 重复发生报产品总监，再升级 CTO
  • 领导或客户要求当天完成 → 走加急申请，写明挤出的需求 → CTO 2 小时内审批
  • 研发与产品对需求理解冲突 → 以已确认 issue 为准，未写明的按变更处理 → 产品总监当天裁定
  • 归属侧争议（FDE 侧 vs 基座侧）→ 先由 FDE 汇总人判断 → 1 个工作日内无共识由产品总监定
  • 旧入口切换 → 至少提前 5 个工作日群公告 + 培训录屏，切换后 2 周内旧入口的需求由产品代为转录
  • 产品总监 1 个工作日未受理 → 机器人提醒 → 超 2 个工作日升级 CTO 指定代受理人
  • 评审后 1 个工作日未排期或未通知提出人 → 提出人在需求单评论催办 → 升级研发技术负责人（次日）
  • 需求关闭后未回告 → 机器人自动补推 → 产品总监在周评审会核查漏回告条目
  • A（升级）说明：需求受理、评审、排期由需求唯一入口 owner（产品总监）拍板；出现加急插队（要求打破已排迭代）、绕过入口屡次发生、产品与业务方对收口或归属侧争议无法在 1 个工作日内达成共识三种情况时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 入口合规率：进入研发的需求中有需求单的比例，目标 100%
  • 受理时效：提交到受理的工作时长，目标 ≤ 1 个工作日
  • 闭环回告率：关闭的需求中已回告提出人的比例，目标 100%
  • 加急占比：每迭代加急需求数 / 总需求数，目标 ≤ 10%
  • 需求返工率：因需求理解偏差返工的 issue 比例，目标 ≤ 10%

8. 低效诊断

  • 现象：业务侧绕过产品直接找研发改需求，高层临时加急打断研发节奏，承诺前后不一｜依据：「鼎慧产研决策部」2026-05、2026-06
  • 现象：商务谈到快成交才拉产研，产研临时接客户咨询，部署口径临时对齐｜依据：「鼎慧产研决策部」2026-03
  • 现象：研发自由加功能后被砍，迭代需求归谁负责被反复追问，产品验收缺位｜依据：「鼎慧产研决策部」2026-05
  • 现象：需求随口提，研发与产品对需求是否写明发生争执，返工｜依据：「LeapCore（archived）」2026-05、2026-06
  • 现象：FDE 侧与基座侧需求归口争论多轮，汇总在个人手里不透明｜依据：「Leap反馈群」2026-07
  • 现象：一句话提需求后无闭环，已实现的功能提出人不知道｜依据：「某水利企业公司研发」2026-07、「新媒体/电竞版Leapcore」2026-06
  • 现象：群里一句话提需求，谁收、谁排期不明｜依据：「跃迁AI总动员」2026-08、2026-09
  • 现象：全员产品意见收口人未明确｜依据：「公司全员群」2026-09
  • 现象：新旧提需入口并行，使用侧培训参与度低｜依据：「渠道系统优化」2026-09、2026-10
  • 现象：市场销售侧仍直接找产研测人员提供支持｜依据：「Leap产研测」2026-10

9. 分支变体

  • 客户定制需求：先判断是否合同内、是否付费增项，再进需求池；排在标品之后。
  • 合作方自开发需求：先提需求单再谈，按排期执行。
  • 市场需求准入：只收集需求不拉研发；客户到下单/拟下单阶段才安排产研参加外部会。
  • FDE 侧 / 基座侧需求：需求单增加“来源侧”字段，FDE 侧由 FDE 汇总人周度汇总后交产品；定制版走开放平台，UI 做成可配置项。
  • 内部业务系统（渠道系统、CRM）：系统内“流程修改意见”入口生成工单草稿，同样进需求池；旧飞书提单入口关闭前提前通知。
  • 研发自行改产品逻辑：一律先与产品对齐；借调人员接活须直属上级与借调上级同时知情。
  • 原型优先：中小需求可不写 PRD，直接出原型 + 验收标准。
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-06（卡点升级阶梯）、ALL-09（状态看板与进度同步）

10. 待确认问题

  • 全员产品意见的最终收口人是产品总监还是 COO？两者如何分工？
  • 唯一需求入口选飞书多维表格还是 Gitea？两者如何同步？
  • 加急审批人是否为 CTO？2 小时审批时限是否可行？
  • FDE 侧需求汇总人是否确定为开放平台负责人？
  • 各业务线（水利、渠道系统、CRM）是否都需要指定兼职产品对接人？
X-PRD-06内测与内部试用（dogfood）反馈收集分流待优化108

状态：待优化｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：新产品或新版本（LeapPPT、LeapAll、LeapCore、内部 AI 小站等）进入内测或全员试用时，组织内部先用起来，统一收集 bug、体验问题、需求和 Badcase，并分流到工单或需求池，结果回告反馈人。
  • 负责人：主责——产品运营（当前：杨黔昆·推断待确认）；协同——LeapAll 研发（当前：邓乾、李铭熙、岳阳·推断待确认）、LeapPPT 研发（当前：马漳毓·推断待确认）、研发/发版（当前：宋祺睿·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、创始人兼 CTO（当前：丁震宇·推断待确认，对外准入把关）；兜底——产品总监（当前：杨萌·推断待确认）
  • 核心流程：① 内测公告 → ② 推动使用 → ③ 统一入口反馈 → ④ 每日 triage → ⑤ 研发认领修复 → ⑥ 发版回告 → ⑦ 周报 → ⑧ 内测复盘与准入判定
  • 交付结果：内测反馈表（含状态与关联工单）、已知问题公示表、每周内测周报、内测复盘与对外准入结论
  • 状态依据：已有飞书反馈表单、Badcase 表单、Gitea 工单和工作台，但「跃迁AI总动员」2026-05～10 反馈在群聊、表单、需求池多处并存，重复提交、找不到表单、反馈无回执反复出现；「Leap产研测」2026-05 群聊与工单重复描述。

1. 场景判定

  • 触发条件：（a）新产品/新版本发内测包或内部体验链接；（b）全员试用中发现问题；（c）产品方主动征集体验反馈；（d）内测包要给销售/客户试用。
  • 典型说法：「先做到内部都用起来吧，dogfood」「改进点找个地方统一提」「反馈入口：填写表单，描述反馈场景及问题」「我今天群里反应的，不用再在表格中写一下了吧」「现在还是内测版，还不能对外售卖」
  • 判断问题：反馈人是公司内部同事（含内部 FDE）且产品处于内测/内部试用期吗？是 → 本流程。
  • 不归本流程管：外部客户、销售现场、培训学员反馈 → 请走 X-PRD-07；Agent 效果样本沉淀 → 请走 X-PRD-08；正式需求提报 → 请走 X-PRD-05。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
内测 owner 发公告、维护表单与已知问题表、每日 triage、周报 R 产品运营（当前：杨黔昆·推断待确认）
产品统筹 内测目标、优先级裁定、复盘 A 产品总监（当前：杨萌·推断待确认）
定级 bug P 级判定 C 研发技术负责人（当前：王皓南·推断待确认）
修复 认领工单、修复、在工单回填版本 R LeapAll 研发（当前：邓乾、李铭熙、岳阳·推断待确认）；LeapPPT 研发（当前：马漳毓·推断待确认）
发版答复 发版状态答复 C 研发/发版（当前：宋祺睿·推断待确认）
对外准入 内测包能否给销售/客户 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
内测用户 按清单体验、按入口反馈 I 全员（重度用户如测试、FDE）

3. 办之前请准备

  • 内测版本号、安装包/链接、适用系统（Windows/Mac/Web）
  • 体验重点清单（速度、适配、文案、核心任务）与内测周期
  • 唯一反馈入口链接（表单，只给填写权限，防止误改）
  • 已知问题公示表
  • 反馈必填项说明：产品、版本、环境、步骤、截图/日志、类型

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发内测公告并置顶：版本、范围、体验清单、唯一入口、已知问题表 内测 owner 发包当天 飞书群公告 内测公告 🔧飞书固化
2 设内部使用目标，给重度场景部门（如市场部之于 PPT）安排 30 分钟培训 产品总监 发包后 3 个工作日内 飞书会议 使用目标与名单 👤人工判断
3 反馈：优先填表单；群里吐槽由机器人/AI 一键转为反馈记录，不要求反馈人重填 内测用户 / 机器人 发现当天 飞书表单 + 多维表格 + 群机器人 反馈记录 🔧+🤖
4 每日 triage：去重；bug → Gitea（P0/P1/P2）；需求 → 需求池；Badcase → X-PRD-08；已知/已修复 → 回复版本号 内测 owner，P 级由研发技术负责人确认 每个工作日 11:00、17:00 两次 多维表格 + Gitea 分流结果 🤖+👤
5 研发认领修复：P0 当天、P1 3 个工作日、P2 下个迭代 对应研发 按 P 级 Gitea 修复与版本号 👤人工判断
6 发版后更新已知问题表，机器人回告反馈人“已在 x.y.z 修复” 内测 owner / 机器人 发版当天 飞书机器人 回告 🤖自动化
7 内测周报：活跃人数、反馈数、未关闭数、Top 问题、未体验提醒 内测 owner 每周五 多维表格仪表盘 + AI 摘要 周报 🤖自动化
8 内测结束复盘，判定发布级别（内测/公测/商用）与能否给销售/客户 产品总监 + CTO 内测周期结束后 3 个工作日内 准入清单 复盘与准入结论 👤人工判断

5. 交付物与模板

  • 交付物：内测公告、反馈表、已知问题公示表、周报、复盘与准入结论
  • 反馈表字段：反馈人、产品、版本、系统环境、类型（bug/体验/需求/Badcase）、描述、复现步骤、截图/日志、严重度、状态、关联工单、修复版本、是否已回告
  • 已知问题表字段：问题、影响范围、规避方法、计划修复版本、状态
  • 准入清单：P0 清零、P1 ≤ 约定数、安全能力检查、安装包签名、帮助文档就绪

6. 异常与升级

  • P0（崩溃、数据丢失、无法登录）→ 内测 owner 立即 @研发并建工单 → 2 小时无人认领升级研发技术负责人
  • 重要演示/方案用户的问题 → 标“高优”，按 P1 处理 → 当天无进展升级产品总监
  • 同一问题被重复反馈 ≥3 次 → 置顶到已知问题表 → 内测 owner
  • 表单被误改或失效 → 恢复版本并收回编辑权限 → 内测 owner 当天处理
  • 有人要求把内测包给客户 → 未通过准入不得外发 → CTO 决定
  • A（升级）说明：内测目标、反馈优先级与内部复盘由产品统筹（产品总监）拍板；内测包要提供给销售、客户或任何外部人员，以及内测结束后判定能否进入公测/商用时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 反馈入表率：群内反馈被转为记录的比例，目标 ≥ 95%
  • triage 时效：反馈到分流的工作时长，目标 ≤ 1 个工作日
  • 回告率：已关闭反馈中回告反馈人的比例，目标 100%
  • 重复反馈率：重复记录 / 总记录，目标 ≤ 10%
  • 内部活跃率：内测周期内至少使用 3 次的人数 / 目标名单人数，目标 ≥ 60%

8. 低效诊断

  • 现象：同一问题在群里与工单中重复描述，新功能无人通知，问题无分级｜依据：「Leap产研测」2026-05
  • 现象：同一 bug 多人重复提交，“反馈表在哪”反复被问，已修复的问题仍被再报，重要用户问题靠 @人催｜依据：「跃迁AI总动员」2026-05、2026-06
  • 现象：内部使用度低，每次发邀请都要重写体验清单，员工忘记链接｜依据：「跃迁AI总动员」2026-04、2026-05
  • 现象：群里已反馈又被要求填表，整理时漏记关键反馈，表单被误改，反馈到排期无回执｜依据：「跃迁AI总动员」2026-06、2026-07
  • 现象：P0 问题“解决没有”靠追问，发版状态不透明｜依据：「跃迁AI总动员」2026-07、2026-08
  • 现象：建议散落在闲聊群、表单、需求池三处，需全员催填｜依据：「跃迁AI总动员」2026-09、2026-10
  • 现象：内测包能否装到同事电脑、能否卖给客户，口径不一｜依据：「鼎慧产研决策部」2026-03

9. 分支变体

  • LeapPPT：工作台记录迭代 + 表单收反馈。
  • LeapAll：早期工单只管 bug，需求从工单筛入工作台。
  • LeapCore：专家/标准/经济模式问题（计费、卡顿、上下文）需附模式与会话信息；集成问题（飞书授权）单独标签。
  • 外部内测用户（如基石计划用户）：统一使用“外部内测用户”口径沟通，反馈仍入本表。
  • 内部 FDE 功能建议：FDE 需求表单收集，汇入需求池（见 X-PRD-05）。
  • 系统差异：Windows / Mac / Web 版需在反馈中注明。

10. 待确认问题

  • 内测 owner 是否固定为产品运营？各产品线是否需要各自的 owner？
  • P0/P1/P2 的修复时限是否可行？
  • 群消息一键转反馈的机器人由谁开发维护？
  • 内测/公测/商用的准入清单由 CTO 还是产品总监签发？
  • 内部使用目标是否纳入部门考核？
X-PRD-07外部用户、客户与销售反馈收集回流产研待优化300

状态：待优化｜证据：有证据（卡片 10 张 / 会话 9 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：外部用户、客户、销售/市场一线、培训学员、内部业务系统（CRM、渠道系统）使用者提出问题或建议时，统一登记、triage（bug/体验/需求/Badcase/咨询）、回流产研，并把处理结果回告反馈人。
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——产品运营（当前：杨黔昆·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态市场总监（当前：许君·推断待确认）、生态组负责人（当前：陈梦琪·推断待确认）、渠道系统/CRM 负责人（当前：郭逸非·推断待确认）、渠道系统/CRM 研发（当前：陈子康·推断待确认）、工程咨询业务专家（当前：王满·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 按规范提报 → ② 机器人入表查重 → ③ triage 定类定级 → ④ 转工单/需求池 → ⑤ 修复或答复 → ⑥ 回告与 FAQ 更新 → ⑦ 销售周汇总 → ⑧ 月度复盘
  • 交付结果：反馈总表（含类型、优先级、状态、关联工单、回告情况）、客户 FAQ、销售客户问题周汇总、月度反馈复盘报告
  • 状态依据：已有 Leap 反馈群、提报规范（2026-07 发布）、AI triage 机器人和需求池，但「Leap产研测」2026-06 统计约 45 条有效反馈中约 25 条未闭环，「【模态】市场销售」2026-07 仍问“新客户问题往哪登记”，「跃迁CRM反馈群」2026-09～10 同类问题重复反馈约 10 次、“待评估”后无排期反馈。

1. 场景判定

  • 触发条件：（a）用户在反馈群发问题；（b）销售在客户现场或演示中遇到故障；（c）培训现场学员暴露问题；（d）客户无法使用产品；（e）CRM、渠道系统试用者反馈缺功能或报错；（f）运营收到生成内容缺陷（政策过时、标准不存在等）。
  • 典型说法：「纯反馈的分流到工单或者需求池」「先不提，这算badcase」「在群里发就行，群里有机器人自动抓取反馈」「学员反馈的所有意见都记得整理一下，给到产品这边做产品优化」「收到，待评估」「哪家客户，情况持续多久，请反馈的时候带齐上下文」
  • 判断问题：反馈来自外部用户/客户/一线销售/业务系统使用者，且需要产研处理或答复吗？是 → 本流程。
  • 不归本流程管：内部内测期反馈 → 请走 X-PRD-06；主动需求提报 → 请走 X-PRD-05；Agent 效果样本 → 请走 X-PRD-08；客户投诉与售后服务 → 请走 X-CS-05（客户问题受理、分流与工单流转）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
反馈归口 owner 规范、分类口径、优先级裁定、月度复盘 A 产品总监（当前：杨萌·推断待确认）
triage 执行 每日审核机器人分类、需求池记录、客诉答复 R 产品运营（当前：杨黔昆·推断待确认）
AI triage 机器人 抓取反馈入表、查重、给分类建议（不直接建工单） R（自动） 反馈群机器人（分类规则由产品运营维护）
修复 认领工单、修复或给出不修复理由并回填 R 对应产品线研发（按工单指派）
定级与排查 P 级判定、远程排查 R 研发技术负责人（当前：王皓南·推断待确认）；值班研发（当前：待指定）
复现 补充复现、拆分工单 R 测试负责人（当前：张东郅·推断待确认）
销售侧汇总 每周汇总客户问题 Top 清单 R 销售运营（当前：韩诗琪·推断待确认）
FAQ 维护 根据反馈更新对外 FAQ 与话术 R 生态市场总监（当前：许君·推断待确认）
培训现场汇总 学员问题收集与回流 R 生态组负责人（当前：陈梦琪·推断待确认）；会务（当前：郭昊·推断待确认）
业务系统反馈 CRM/渠道系统反馈受理与修复 R 渠道系统/CRM 负责人（当前：郭逸非·推断待确认）；研发（当前：陈子康·推断待确认）
垂类反馈收集 工程咨询用户反馈整理 R 工程咨询业务专家（当前：王满·推断待确认）
业务裁决 系统规则类争议裁决 C 创始人兼 CTO（当前：丁震宇·推断待确认）；COO（当前：常元和·推断待确认）
提报人 按规范提报 I 销售市场、渠道、客户

3. 办之前请准备

  • 客户（客户A/订单号，不写真实名称到公开群）、产品与版本、部署环境
  • 问题持续时间、影响范围（几人/全部无法使用）
  • 复现路径、提示词、截图/录屏、日志或会话 ID
  • 功能诉求：场景、依赖、预期结果
  • 演示现场：先升级到最新版再判断

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按提报规范发到统一反馈群（或表单）；高优同时填表并 @产品；客户无法使用时带齐订单上下文 提报人 发现当天 反馈群 + 飞书表单 反馈原文 🔧飞书固化
2 机器人抓取入反馈总表，自动查重、给分类建议（不直接建工单） AI triage 机器人 实时 多维表格 反馈记录 🤖自动化
3 人工 triage：确认类型（bug/体验/需求/Badcase/咨询/已知）与优先级，多问题拆分 产品运营，P 级由研发技术负责人确认 每个工作日 11:00、17:00 两次 多维表格 已分类记录 👤人工判断
4 分流：bug → Gitea（P0/P1/P2）；需求 → 需求池（X-PRD-05）；Badcase → X-PRD-08；咨询/已知 → 直接答复 产品运营 / 测试负责人 triage 后 1 个工作日内 Gitea + 需求池 关联工单号 🔧+👤
5 演示现场故障：保留现场，立即飞书会议联系研发远程排查 销售 + 值班研发 30 分钟内响应 飞书会议 排查结论 👤人工判断
6 修复或给出不修复理由，回填版本号/理由 对应研发 按 P 级：P0 当天、P1 3 个工作日、P2 下个迭代 Gitea 处理结果 👤人工判断
7 回告反馈人；高频问题更新 FAQ 与话术 产品运营 / 生态市场总监 关闭当天；FAQ 每周更新 机器人 + FAQ 文档 回告 + FAQ 新版 🤖+👤
8 销售侧周汇总：问题/建议/咨询分类、Top 问题、连续出现的问题 销售运营 每周一 飞书 CLI/机器人抓取 + 表格 周汇总 🤖自动化
9 月度反馈复盘：总数、闭环率、系统性问题、核心共创用户，作为迭代主线输入 产品总监 每月第 1 周 AI 生成草稿 + 管理面板数据 月度复盘报告 🤖+👤

5. 交付物与模板

  • 交付物：反馈总表、Gitea 工单、需求池条目、回告记录、FAQ、销售周汇总、月度复盘报告
  • 反馈总表字段：反馈人、身份（客户/销售/学员/内部业务）、客户代号、订单号、产品、版本、环境、类型、模块、描述、复现路径、附件、优先级、状态、关联工单、处理结果、是否回告、来源群
  • 提报规范要点：上下文、复现路径、提示词必填；功能需求写场景、依赖、预期；客户想接入的三方软件/API 同步到对接清单
  • 月度复盘模板：数据口径说明、分类统计、系统性问题 Top5、未闭环清单、核心共创/回访/深访用户分层、下迭代建议

6. 异常与升级

  • 客户整体无法使用 → 按 P0，产品运营立即拉研发 → 1 小时无进展升级研发技术负责人，2 小时升级 CTO
  • 演示现场故障无法复现 → 保留现场、收集日志 → 值班研发 30 分钟内接入
  • AI triage 合并或分类错误 → 人工拆分并记录错例用于改进 → 产品运营
  • 反馈信息不全 → 退回提报人补齐，24 小时未补则关闭并说明 → 产品运营
  • 业务系统（渠道/CRM）规则争议、涉及分润资金 → 暂停相关功能使用 → CTO 裁决，涉及资金同步财务负责人

7. 衡量指标

  • 闭环率：已闭环反馈 / 有效反馈（按月），目标 ≥ 80%
  • 首次响应时长：反馈到 triage 完成的工作时长，目标 ≤ 4 小时
  • 回告率：已闭环反馈中回告反馈人的比例，目标 100%
  • 重复反馈率：同一问题重复反馈条数 / 总条数，目标 ≤ 15%
  • 复发率：已修复问题连续两周再出现的比例，目标 ≤ 5%

8. 低效诊断

  • 现象：AI triage 把多问题合成一个工单、归类错误需人工拆分；enhancement/badcase/需求边界不清；大量反馈未闭环｜依据：「Leap产研测」2026-06
  • 现象：反馈散落在多个群，人工整理；同类 bug 连续多周复发；新客户问题不知往哪登记；自动抓取因机器人付费暂停｜依据：「【模态】市场销售」2026-07、2026-08
  • 现象：靠人工定期抓取群聊整理，信息都在群里但无人整理｜依据：「公司内FDE」2026-07、2026-08
  • 现象：培训现场问题散在执行群、反馈群、专班群，日志需单独索取｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：客户无法使用时反馈缺少客户、持续时间、上下文，需连续追问｜依据：「Leap市场销售通知群」2026-09
  • 现象：同类问题多人重复反馈，“待评估”后无排期回复，一期范围与业务诉求反复拉扯｜依据：「跃迁CRM反馈群」2026-09、2026-10
  • 现象：系统上线初配置依赖未预置导致流程走不通，规则隐蔽导致结果异常｜依据：「渠道系统反馈群」2026-09、2026-10
  • 现象：多环境使用数据无法一起统计，复盘靠人工从群聊归纳｜依据：「Leap反馈群」2026-07
  • 现象：用户反馈经整理后录入工作台，低级错误靠催办修复｜依据：「字字可研市场运营」2026-03、2026-04

9. 分支变体

  • Leap 反馈群：AI 机器人先 triage 到产研群，由人确认后再建工单。
  • 字字可研内容缺陷（政策过时、标准不存在、大纲遗漏）：按“内容合规类”标签，是否本迭代修复由产品与技术负责人判断，结论回告运营与客户。
  • 销售现场与演示故障：先升级最新版，不能复现的保留现场远程排查；非演示问题走反馈群。
  • 培训现场：助教口语记录、会后书面归类，统一填反馈收集页，次日复盘会过一遍。
  • 跃迁 CRM：Bug 当天修复；体验类建议每周固定窗口集中评审并公示更新说明；一期未做的功能进需求池排期；与渠道系统重叠的功能划归渠道系统。
  • 渠道系统：上线前 UAT 清单与初始数据（标品 SKU）预置；审批与飞书通知联动；涉及分润的问题同步财务。
  • 客户无法使用：可在订单群处理，但处理结果须回填反馈总表。

10. 待确认问题

  • 反馈归口 owner 是产品总监，还是按产品线（Leap、字字可研、CRM/渠道系统）分设？
  • AI triage 机器人是否允许直接建工单？谁负责维护其分类规则？
  • 销售侧周汇总与反馈群机器人是否合并为一份数据？
  • P0 值班研发如何排班？
  • 多环境（不同部署空间）使用数据由谁打通？
X-PRD-08Agent Badcase 收集与转需求/缺陷工单待新建24

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨2 × 险2

  • 适用场景：Agent 能跑通但效果差（理解偏差、规划失败、工具调用错误、Skill 效果差、缓存命中率低等）时，保留对话样本作为 Badcase 沉淀，用于评测回归，并分流为需求或 bug 工单。
  • 负责人：主责——评测工程师（当前：黄霆瑄·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、Agent/模型研发（当前：岳阳·推断待确认）、FDE/运营负责人（当前：李凯·推断待确认）；兜底——测试负责人（当前：张东郅·推断待确认）
  • 核心流程：① 提交样本 → ② 初筛 → ③ 分类分流 → ④ 入样本库标注 → ⑤ 转 Agent 能力 issue → ⑥ 修复与回归 → ⑦ 月度评测报告
  • 交付结果：Badcase 样本库（含对话、标注、状态）、“Agent 能力”项目 issue、月度 Badcase 评测报告、并入基准评测集的回归用例
  • 状态依据：「Leap产研测」2026-07 负责收集的岗位自述“SOP 还没想好”，旧收集表杂乱、多渠道收集；「Leap产研决策部」2026-07～08 仅口头约定“交给评测同学维护再流转 issue”，期间仍有人直接批量提工单，负责岗为短期岗位，存在交接断档风险。

1. 场景判定

  • 触发条件：（a）使用 Agent/Skill 时结果明显不符合预期但无报错；（b）同类任务在竞品上效果更好；（c）模型缓存命中率、成本异常；（d）反馈 triage 中被判定为 Badcase。
  • 典型说法：「badcase主要收集agent能力的问题，产品需求转给产品，bug转给bug」「有badcase直接给评测同学，他会打回没价值的」「先不提，这算badcase」「做 Skill 时效果不理想的对话记录能不能发我看看」
  • 判断问题：功能正常运行、没有报错，只是“做得不好”吗？是 → Badcase；有报错/崩溃 → bug；缺功能 → 需求。
  • 不归本流程管：程序错误与崩溃 → 请走 X-PRD-06 / X-PRD-07 的 bug 分流；缺失功能 → 请走 X-PRD-05；竞品整体对标 → 请走 X-PRD-02。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Badcase owner 维护入口与样本库、初筛、标注、月报 R 评测工程师（当前：黄霆瑄·推断待确认）
分流规则与优先级 定 Badcase/需求/bug 边界，排修复优先级 A 研发技术负责人（当前：王皓南·推断待确认）
需求转化 把 Badcase 中的产品需求整理入需求池 C 产品总监（当前：杨萌·推断待确认）
修复 模型/提示词/缓存/Skill 优化 R Agent/模型研发（当前：岳阳·推断待确认）
样本提供 提供对话记录与场景 I FDE/运营负责人（当前：李凯·推断待确认）；全体使用者
兜底与评测集 owner 缺位时接管，样本并入评测集 R（兜底） 测试负责人（当前：张东郅·推断待确认）

3. 办之前请准备

  • 会话 ID 或对话导出（完整上下文、提示词）
  • 产品与版本、模型、模式、使用的 Skill
  • 期望结果 vs 实际结果，截图
  • 是否含客户数据或敏感信息（含则先脱敏再提交）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过 Badcase 表单提交，自动带出会话 ID、模型、版本 使用者 发现当天 飞书表单 → 多维表格（或产品内“分享会话”） 样本记录 🔧+🤖
2 初筛：AI 先去重和预分类，评测工程师判定有无价值；无价值的归档（不删除）并注明理由 评测工程师 提交后 2 个工作日内 多维表格 + AI 初筛结论 🤖+👤
3 分流：Agent 能力问题留在 Badcase；产品需求转需求池；bug 转 Gitea 评测工程师，边界争议由研发技术负责人定 初筛当天 需求池 / Gitea 分流记录 👤人工判断
4 入样本库并标注：任务类型、失败环节（理解/规划/工具/输出质量/成本）、严重度 评测工程师 分流后 1 个工作日内 样本库（git 仓库或多维表格） 标注样本 🤖+👤
5 有价值样本转“Agent 能力”项目 issue，附样本链接 评测工程师 标注后 1 个工作日内 Gitea issue 👤人工判断
6 研发修复后用原样本回归，通过则关闭并回告提交人 Agent/模型研发 + 评测工程师 按迭代 评测脚本 回归结果 🤖自动化
7 月度报告：新增数、失败环节分布、已修复率；典型样本并入基准评测集 评测工程师 每月第 1 周 AI 汇总 + 评测集 月度报告 🤖+👤

5. 交付物与模板

  • 交付物：Badcase 样本库、Agent 能力 issue、月度报告、回归用例
  • Badcase 表单字段：提交人、产品、版本、模型、模式、Skill、会话 ID/导出、任务描述、期望结果、实际结果、截图、是否已脱敏
  • 标注字段：任务类型、失败环节、严重度、可复现性、是否入评测集、关联 issue、状态（待筛/归档/已分流/修复中/已回归）

6. 异常与升级

  • 同一 Badcase 被多人从不同渠道提交 → 合并到一条，补充来源 → 评测工程师
  • 有人绕过入口直接提工单 → 转回 Badcase 入口并归档原工单 → 评测工程师当天处理
  • 样本含客户敏感数据 → 退回脱敏，不入库 → 产品总监确认
  • 评测工程师岗位变动或离开 → 样本库与规则移交测试负责人（交接前 5 个工作日完成）
  • 同类 Badcase 月内 ≥5 条未处理 → 升级研发技术负责人排入下个迭代

7. 衡量指标

  • 初筛时效：提交到初筛完成的工作日，目标 ≤ 2 天
  • 有效率：有价值样本 / 提交总数，按月观察，用于改进提交指引
  • 修复回归率：已转 issue 的 Badcase 中回归通过的比例，目标每季度 ≥ 50%
  • 评测集增量：每月并入基准评测集的样本数，目标 ≥ 10 条
  • 单一入口率：经表单提交的 Badcase 比例，目标 ≥ 90%

8. 低效诊断

  • 现象：Badcase 从多个渠道收集，旧收集表杂乱，Badcase 与 bug 的边界不清，收集环节无 SOP｜依据：「Leap产研测」2026-07
  • 现象：仅口头约定由评测岗维护再流转 issue，产品侧仍直接批量提工单后再归档，负责岗为短期岗位，存在交接断档｜依据：「Leap产研决策部」2026-07、2026-08

9. 分支变体

  • Agent 能力问题：留在 Badcase 样本库，走评测回归。
  • 产品需求：转需求池（X-PRD-05）。
  • Bug：转 Gitea 工单（X-PRD-06/07 的 bug 通道）。
  • 入口可与 X-PRD-06/07 的反馈表共用，但类型为 Badcase 时必须附对话样本。

10. 待确认问题

  • Badcase owner 当前为短期岗位，长期负责人是谁？兜底是否为测试负责人？
  • 样本库用 git 仓库还是多维表格？客户数据如何脱敏？
  • 是否在产品内增加“一键分享会话为 Badcase”功能？
  • 修复优先级由研发技术负责人还是产品总监定？
  • 每月 ≥10 条并入评测集的目标是否合理？
X-PRD-09需求提报登记与需求池管理待优化180

状态：待优化｜证据：有证据（卡片 17 张 / 会话 7 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：任何人（用户、销售、交付、运营、高层、研发、测试）提出新功能或体验优化需求（非缺陷），需要查重、登记入需求池、指派负责人、跟踪状态，直到上线后通知提出人
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——需求池维护/产品助理（当前：杨黔昆、陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞线产品经理（当前：徐莉、段涵、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 统一入口提报 → ② 查重归并 → ③ 登记需求池并回执 → ④ 产品评估（采纳/待定/不做） → ⑤ 入工作台指派负责人 → ⑥ 进迭代转工单并通知测试 → ⑦ 上线自动通知提出人 → ⑧ 双周查漏清理
  • 交付结果：状态准确的需求池（多维表格），每条需求都有来源、提出人、负责人、评估结论、状态与上线日期；上线时自动通知提出人
  • 状态依据：Leap 线已有需求池/工作台，跃竞线已有“需求管理”多维表格和新增/上线机器人；但 Leap 线入口在群聊、工单、表单、工作台之间并存，05～10 月反复出现“报过多次无人理会”“谁又偷偷加需求”“同一需求多人重复提”，跃竞线状态靠事后批量点击，上线通知滞后数周

1. 场景判定

  • 触发条件：提出一个当前产品没有、或希望改变现有行为的功能/体验点；Bug 排查后确认为“设计如此、需新增能力”；产品例行查漏
  • 典型说法：「加到需求池」「先进需求池吧」「你可以给产品提需求后面做」「已记录需求，待评估」「工单里面没写就不做」「加需求通知一下测试，不然没人测」
  • 判断问题：这是现有功能坏了（缺陷），还是要新增/改变能力（需求）？是否已有同类需求在池里？
  • 不归本流程管：功能报错、与设计不符 → 请走 RND-03；反馈群原始反馈的分拣 → 请走 RND-01 / X-PRD-06 / X-PRD-07；紧急插单与优先级争议 → 请走 X-PRD-10；客户定制与报价 → 请走 X-PRD-11；入迭代拆故事点 → 请走 X-PRD-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 需求池唯一下发人：评估、定优先级、确认入工作台、关闭不做的需求 A/R 产品经理（当前：杨萌·推断待确认）
需求池维护/产品助理 登记、查重归并、回执提出人、维护状态、双周查漏 R 需求池维护/产品助理（当前：杨黔昆、陈震、黄飞鹏·推断待确认）
研发负责人 评估技术可行性与工作量，拆工单，拒绝未入池的口头需求 C 研发负责人（当前：王皓南·推断待确认）
测试负责人 接收“需求进迭代”通知，安排测试 I/C 测试负责人（当前：张东郅·推断待确认）
跃竞线产品经理 跃竞各端需求登记与状态维护 R（跃竞线） 跃竞线产品经理（当前：徐莉、段涵、陈雁·推断待确认）
需求提出人 按模板填写需求，接收回执与上线通知 R（提报） 各部门提出人
机器人 登记回执、状态变更时通知测试与提出人 R（自动） 多维表格自动化（由需求池维护人配置）
CTO 优先级原则制定、跨线争议兜底 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求描述：背景（谁在什么场景下遇到什么问题）、期望效果、对标参考（截图/竞品链接）
  • 来源：内部使用 / 客户（写客户代号）/ 渠道 / 运营 / 高层；是否有交付或演示时间窗口
  • 先在需求池搜索关键词，确认无同类需求；有则在原需求下“+1”并补充场景
  • 所属产品线与端：LeapAll / LeapCore / LeapNew / LeapPPT / 跃竞各端

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过“需求提报表单”提交；群里口头提出的，由需求池维护人代填并回贴链接 提出人 / 需求池维护人 群内提出后 1 个工作日内落表 飞书表单→多维表格 需求记录（状态=已记录） 🔧+🤖
2 查重归并：相似需求合并、计票，重复项关联原记录 需求池维护人 登记后 1 个工作日内 多维表格 + AI 查重 归并结果 🤖自动化
3 机器人回执提出人：编号、当前状态、预计评估日期 机器人 登记即时 多维表格自动化 回执消息 🔧飞书固化
4 产品评估：采纳（定 P0～P3、所属迭代窗口）/ 待定 / 不做（写原因） 产品经理 登记后 5 个工作日内；客户/有时间窗口的 2 个工作日内 每周需求池过会 评估结论 👤人工判断
5 采纳需求入工作台，指派产品负责人、研发负责人、测试负责人 产品经理 评估当天 工作台多维表格 已指派需求 🔧飞书固化
6 进迭代时由研发负责人拆工单并关联需求编号；未入池、未写入工单的不做 研发负责人 迭代规划会当天 Gitea / issues 工单 👤人工判断
7 状态改为“开发中/待测试”时自动 @测试负责人 机器人 状态变更即时 多维表格自动化 测试通知 🔧飞书固化
8 发版后状态改“已上线”，回填上线日期，机器人通知提出人和反馈群 研发负责人 / 产品经理 发版当天 多维表格 + 机器人 功能上线通知 🔧+🤖
9 双周查漏：清理超 30 天无进展需求、核对状态与实际一致、征集遗漏需求 需求池维护人 每两周迭代结束前 1 个工作日 多维表格视图 查漏清单 🔧+🤖

5. 交付物与模板

  • 交付物：需求池多维表格、需求回执、评估结论、上线通知、双周查漏清单
  • 建议模板/表单：需求池字段——编号、标题、描述、来源（内部/客户/渠道/运营/高层）、提出人、客户代号、产品线/端、需求分类（新功能/体验改进/技术优化/功能迁移）、相似需求关联、票数、优先级（P0～P3）、评估结论、不做原因、产品负责人、研发负责人、测试负责人、关联工单、迭代、状态（已记录/评估中/已排期/开发中/待测试/已上线/不做）、上线日期
  • 状态流转规则：“延期”只表示开发未按期完成，产品调整迭代时不得改为延期，需在评论说明；已推测试环境的需求直接改“测试待验收”

6. 异常与升级

  • 提出人 5 个工作日未收到评估结论 → 需求池维护人催办产品经理 → 仍无结论升级研发负责人（2 个工作日内）
  • 研发或测试绕过需求池直接提功能单 → 产品经理关闭或转入需求池，并在周会通报
  • 需求池中同一需求被多人以不同描述登记 → 维护人合并、保留最早编号，通知各提出人
  • 高层或客户要求跳过评估立即开发 → 转 X-PRD-10 走插单评估
  • 状态与实际进度不一致超过 1 个迭代 → 产品经理组织当周核对，研发负责人负责更新
  • A（升级）说明：需求是否采纳、定级与关闭由产品经理最终负责；跨产品线争抢资源、优先级原则需要调整，或产品与研发对是否入池意见不一时，拍板权升级到 CTO

7. 衡量指标

  • 回执及时率：登记后 1 个工作日内回执的占比，目标 ≥ 95%
  • 评估周期：登记到评估结论的工作日数，目标 ≤ 5 天
  • 重复需求率：被合并需求数 / 新登记需求数，持续下降
  • 群聊直提占比：未经表单、由维护人代填的需求占比，目标 ≤ 30%
  • 上线通知滞后：实际上线到通知发出的自然日，目标 ≤ 1 天

8. 低效诊断

  • 需求入口不统一，提给不同的人都算“提过”，需求反复上报无人回应，最终绕过需求池直接发工单｜依据：「Leap产研测」2026-06、「跃迁AI总动员」2026-06
  • 工作台只覆盖部分产品线，部分本轮需求不进工作台，研发和测试对工作台是否在用认知不一｜依据：「Leap产研测」2026-05
  • 反馈只在群里，开发担心记不清；进度没有公开视图，提出人只能反复追问“什么时候上”｜依据：「LeapPPT」2026-05、「Leap反馈群」2026-07
  • 同一需求被多人重复提出、描述重复，缺少查重环节｜依据：「Leap反馈群」2026-08、「Leap产研决策部」2026-08
  • 评估类需求未经确认就进开发，也没通知测试，造成漏测与“谁提单”互相推｜依据：「Leap产研决策部」2026-10
  • 状态更新依赖人工事后批量点击，上线通知滞后数周、重复通知｜依据：「跃玩项目组」2026-04、「跃玩项目组」2026-07
  • 研发自行提功能单，与产品走查单、测试单重复｜依据：「Leap产研测」2026-08
  • 状态口径被误用（产品调迭代改为“延期”）｜依据：「工程咨询产研」2026-01

9. 分支变体

  • Leap 系列（LeapAll/LeapCore/LeapNew/LeapPPT）：需求池统一一张表，按产品线字段区分视图；LeapPPT 不再单独维护收集表
  • 跃竞线：沿用现有“需求管理”多维表格与机器人，补“提测/测试中/待验收”必填状态和超时提醒
  • V5/新架构期：研发发现缺失功能不得自行提功能单，统一找产品经理提，提单 skill 必须含查重步骤
  • Bug 实为需求：关闭原缺陷单，由测试或产品转入需求池，保留原单链接
  • 体验优化单：允许研发直接提，打“UX”标签，产品每两周集中评审一次；是否计额外点数见待确认问题

10. 待确认问题

  • 需求池唯一载体选飞书多维表格还是 issues 系统？Gitea/issues 与多维表格谁为准、是否需要自动同步？
  • 产品经理是 Leap 全线需求唯一下发人吗？LeapPPT、LeapCore 各线是否另设需求池维护人？
  • 评估时限 5 个工作日（客户需求 2 个工作日）是否可行？
  • UX 优化单奖励额外点数是否纳入研发绩效（RND-12）？
  • 跃竞线与 Leap 线需求池是否需要统一字段与状态口径？
X-PRD-10需求优先级评估与紧急插单待新建192

状态：待新建｜证据：有证据（卡片 8 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：高层、客户、销售或市场提出“急需求”，或多个需求争抢同一迭代时，按统一分级标准决定插单、后置、转 FDE 或拒绝
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、销售/客户经理（当前：杨朋伟、杜中瑞、闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 高优表单提报 → ② 产品按分级标准定级 → ③ 研发评估工作量与对当前迭代的影响 → ④ 决策（插单/下迭代/转 FDE/拒绝） → ⑤ 回执提出人 → ⑥ 插单则等量移出并通知测试 → ⑦ 每周同步重点队列
  • 交付结果：带分级、决策结论和理由的“重点需求队列”；插单决定附“移出项清单”；提出人收到书面答复
  • 状态依据：只有口头原则（“能卖钱、少亏钱的先做”“致命 bug ＞ 运营需求 ＞ 交互优化 ＞ 其他”），07 月起才有“高优需求正式提报”表单；高层、业务方需求仍经转述进入，多位管理者分别下达指令，“没人筛需求”“天天改需求”反复出现

1. 场景判定

  • 触发条件：提出人要求本周/本迭代上线；客户或销售项目有明确时间窗口；开放平台、交付或演示被卡；迭代容量已满仍要加需求
  • 典型说法：「这个急急急，排一下」「这周一定要上线」「有一丢丢着急」「再急能急过标品交付跑通吗」「给钱了再说，可以做」
  • 判断问题：不做会不会造成生产事故、资金损失或丢单？有没有可验证的客户和截止日期？是否必须挤掉本迭代已承诺的内容？
  • 不归本流程管：普通需求登记与回执 → 请走 X-PRD-09；客户定制的标品化判断与报价 → 请走 X-PRD-11；生产故障本身的处置 → 请走 RND-03；迭代内已开发需求的变更 → 请走 X-PRD-29；法律/合规风险功能 → 请走 X-PRD-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 按分级表定级，给出插单/后置/拒绝结论并回执 A/R 产品经理（当前：杨萌·推断待确认）
研发负责人 评估工作量、对当前迭代影响，提出移出项 R（评估） 研发负责人（当前：王皓南·推断待确认）
CTO 维护分级原则；产品与研发不一致或高层需求冲突时仲裁 A（升级） CTO（当前：丁震宇·推断待确认）
销售/客户经理 填写客户、业务影响、截止日期，向客户传达结论 R（提报） 销售/客户经理（当前：杨朋伟、杜中瑞、闫登辉、吴琪·推断待确认）
测试负责人 接收插单通知，调整测试计划 I 测试负责人（当前：张东郅·推断待确认）
高层需求方 需求经产品经理统一入口提交，不直接给研发下任务 C CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 业务影响：影响哪个客户/渠道/演示、涉及金额区间档位（不写具体金额）、不做的后果
  • 截止日期及依据（合同节点、活动日期、演示日期）
  • 是否已对客户承诺；承诺内容截图或纪要
  • 是否标品需求：讲给中小企业老板听，能否提高买单概率？不能则考虑转 FDE Skill

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写“高优需求正式提报”表单；高层口头需求由产品经理代填并请其确认 提出人（销售/客户经理、高层需求方）/ 产品经理 提出当天 飞书表单→多维表格 高优需求记录 🔧飞书固化
2 按分级表定级：P0 生产事故/价格或资金错误；P1 影响可售卖交付或有签约客户时间窗口；P2 运营需求、交互优化；P3 重构、小问题、其他 产品经理 收到后 4 个工作小时内（P0 即时） 分级表 级别 👤人工判断
3 评估工作量、依赖和对本迭代已承诺内容的影响，列出可移出项 研发负责人 定级后 1 个工作日内 迭代看板 影响评估 👤人工判断
4 决策：P0 立即插单；P1 本迭代插单需等量移出，否则排下迭代；P2/P3 进需求池；非标品转 FDE；合规禁区直接拒绝 产品经理，争议时 CTO 评估后 1 个工作日内 决策记录 决策结论 👤人工判断
5 书面回执提出人：结论、预计时间、理由；正式提报不等于承诺排期 产品经理 决策当天 机器人卡片 回执 🔧+🤖
6 插单：更新迭代范围，移出项标记“下迭代”，@测试负责人与相关研发 研发负责人 决策当天 工作台 / 工单 迭代变更记录 🔧飞书固化
7 每周同步重点队列状态（客户、截止日期、进度、风险） 产品经理 每周迭代例会 多维表格视图 重点队列周报 🔧+🤖

5. 交付物与模板

  • 交付物：高优需求记录、分级结论、迭代变更记录、回执、重点队列周报
  • 建议模板/表单：高优提报字段——需求标题、提出人、来源（高层/客户/销售/市场/开放平台）、客户代号、业务影响、截止日期及依据、是否已承诺客户、标品/定制判断、建议级别、产品定级、研发工作量（人日）、影响的已排需求、决策（插单/下迭代/转 FDE/拒绝）、决策人、决策日期、理由

6. 异常与升级

  • 多位管理者对同一需求给出不同指令 → 产品经理汇总冲突点，请 CTO 召集 30 分钟对齐会 → 当天出唯一结论
  • 销售已对客户承诺时间但研发评估做不到 → 产品经理给出可行时间，销售当天向客户更正 → 升级销售负责人（1 个工作日内）
  • 高层要求本周上线且影响版本质量 → 研发负责人书面列出风险 → 升级 CTO 决定（当天）
  • 插单后迭代仍超载 → 研发负责人提出再移出项 → 产品经理当天确认
  • 需求涉及法律风险（如抓取、解析他人聊天记录、绕过系统限制）→ 直接拒绝并转 X-PRD-17
  • A（升级）说明：定级与插单结论由产品经理最终负责；产品与研发对插单影响评估不一致，或多个高层需求冲突、需要调整分级原则时，拍板权升级到 CTO

7. 衡量指标

  • 插单率：迭代内插入的故事点 / 迭代总故事点，目标 ≤ 20%
  • 插单定级时效：提报到出结论的工作小时数，目标 ≤ 1 个工作日
  • 高优表单使用率：高优需求中经表单提报的占比，目标 ≥ 90%
  • 对客承诺偏差：对客户承诺日期与实际上线相差超过 3 天的次数，目标逐月下降
  • 迭代承诺完成率：迭代开始时承诺内容的完成比例，目标 ≥ 80%

8. 低效诊断

  • 急需求经转述进入，“多急”反复确认，谁定优先级不清｜依据：「Leap产研测」2026-06
  • 每次开会带回一批需求，无分级表，研发被技术细节带偏｜依据：「鼎慧产研决策部」2026-06
  • 多个需求争抢同一迭代，取舍靠群内争论，对外承诺时间点未经产研确认｜依据：「鼎慧产研决策部」2026-06
  • 无人筛需求，迭代内需求不断追加，研发感觉“天天改需求”｜依据：「鼎慧产研决策部」2026-03
  • 高层临时要求本周上线，多位管理者口径不一，研发要求先统一再下达｜依据：「Leap产研决策部」2026-08、「Leap产研决策部」2026-09
  • 客户定制与标品之间无准入规则，产品与销售反复争论｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-10
  • 规则出台前，销售只能在群里 @ 催促｜依据：「Leap反馈群」2026-07

9. 分支变体

  • 高层需求：同样走表单和分级，产品经理代填；结论同步 CTO，避免多头下达
  • 客户/销售项目：必须填客户代号和截止依据，进入重点队列每周跟踪
  • 开放平台依赖、演示或交付卡点：默认按 P1 评估
  • 大客户专项（如预装渠道客户）：按客户节点倒排，一般排下迭代，不打断当前迭代
  • 非标品需求：转 FDE 做 Skill，或走 X-PRD-11 定制报价

10. 待确认问题

  • 分级表 P0～P3 定义是否认可？“能否提高中小企业老板买单概率”是否作为标品准入的正式判据？
  • 插单上限 20% 迭代容量是否合适？超过时由谁批准？
  • 高层需求是否一律由产品经理代填入表？CEO/COO 是否同意不直接给研发下任务？
  • 产品经理与研发负责人意见不一致时，CTO 是唯一仲裁人吗？
  • 重点队列周报发给谁（销售负责人、CEO）？
X-PRD-11客户定制需求评估、标品化判断与报价估算待新建300

状态：待新建｜证据：有证据（卡片 11 张 / 会话 12 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：大客户、渠道或客户 Demo 提出定制需求时，先澄清需求，再判断标品吸收、开关隔离、FDE Skill 还是项目定制，输出范围、人日、成本价和排期，交商务定价
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、基座研发/FDE（当前：望政韬、黄振锋、张康·推断待确认）、商务负责人（当前：常元和·推断待确认）、销售（当前：刘昱潇、吴琪、杨朋伟、闫登辉·推断待确认）、测试负责人（当前：张东郅·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 定制需求提报 → ② 需求澄清（问卷+资料格式） → ③ 标品化判定 → ④ 范围与人日评估（含研发 Review） → ⑤ 输出成本价与兜底规则 → ⑥ 商务定价与立项 → ⑦ 隔离开发与按版本冒烟 → ⑧ 客户确认版需求清单发出
  • 交付结果：定制需求评估单（范围、标品化结论、人日、成本价、售后边界、排期），以及发给客户确认的需求清单
  • 状态依据：每次定制都临时讨论；标品与定制边界在发版前才争论，定制逻辑曾带入标准版；销售前期报的并发等关键参数与实际差距很大；产研曾被要求直接给售价，定价归属不清

1. 场景判定

  • 触发条件：客户/渠道提出标准版没有的能力；渠道要求关闭充值入口、去除模态痕迹、数据脱敏；客户只给接口文档、白皮书或 AI 生成的需求文档；客户 Demo 反馈后追加模块；需要 Logo/产品名定制报价；政府或集团客户要求出人日估算
  • 典型说法：「如果有些能复用就标，不能就当定制版」「新手引导根本不是通用需求，是某渠道 only」「你把需求一个个列出来，排一下优先级」「定价不归产研管」「来报工作量文档 人日」
  • 判断问题：这个能力其他客户也会要吗？只给这一个客户用时，能否通过配置开关或渠道打包隔离？客户是否有付费意向？
  • 不归本流程管：已签约项目的定制交付执行 → 请走 X-DLV-10；行业版整体规划 → 请走 X-PRD-04；定制 Skill 承接与定价 → 请走 X-FDE-08；硬件配置报价 → 请走 X-DLV-01；新项目研发立项分工 → 请走 RND-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 统一受理、标品化判定、输出评估单和客户需求清单 A/R 产品经理（当前：杨萌·推断待确认）
CTO 大项目范围与人日估算、技术边界拍板、成本价规则 A（升级）/C CTO（当前：丁震宇·推断待确认）
研发负责人 常规定制工作量评估、短期/长期方案 R 研发负责人（当前：王皓南·推断待确认）
基座研发/FDE 写 MVP 需求文档、Review 人日估算、Demo 实现 R 基座研发/FDE（当前：望政韬、黄振锋、张康·推断待确认）
商务负责人 在成本价之上谈价，决定是否转项目 R（商务定价） 商务负责人（当前：常元和·推断待确认）
销售 提报、补齐客户资料、对客沟通 R（提报） 销售（当前：刘昱潇、吴琪、杨朋伟、闫登辉·推断待确认）
测试负责人 按渠道/版本做隔离冒烟 C 测试负责人（当前：张东郅·推断待确认）

3. 办之前请准备

  • 客户代号、行业、采购阶段、预算档位、付费意向（是否已有明确买单意向）
  • 业务场景描述（客户的话，而非裸接口文档）；并发用户数、数据量、是否离线/内网、部署位置、模型来源
  • 客户已有资料：接口文档、知识库样例、交付格式要求；缺失项清单
  • 期望交付日期及依据；已对客户做过的口头承诺

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写定制需求评估单（客户、场景、需求清单、优先级、期望时间） 销售 客户提出后 1 个工作日内 飞书多维表格 评估单草稿 🔧飞书固化
2 澄清：发需求澄清问卷，明确资料格式；资料不全或不符合格式即退回补充 产品经理，基座研发/FDE 受理后 2 个工作日内发问卷 问卷 + 澄清会 MVP 需求文档 🤖+👤
3 标品化判定：标品吸收 / 开关或渠道隔离 / FDE Skill / 项目定制 / 拒绝（合规禁区） 产品经理 澄清完成后 2 个工作日内 判定表 判定结论 👤人工判断
4 范围与人日评估：常规由研发负责人；大项目由 CTO 先估中位数，研发至少 2 人 Review（周期、模型来源、OTA 运维、部署位置） 研发负责人 / CTO 判定后 3 个工作日内 评估文档 人日与风险清单 🤖+👤
5 输出产研三项：预期需求范围、预期人日与成本价、兜底规则（何时算售后、再次改动另计） 产品经理 评估后 1 个工作日内 评估单 成本价报告 🔧飞书固化
6 商务定价：售价不得低于成本价；决定立项、转项目或放弃 商务负责人 收到成本价后 3 个工作日内 评估单 报价与立项结论 👤人工判断
7 立项后排期；需求单标注适用范围（标准/渠道/客户），按渠道 flavor 打包，发版前对每个 flavor 冒烟 研发负责人，测试负责人 按排期；发版前 1 个工作日完成冒烟 工单 + CI 隔离开发记录、冒烟结果 🔧+🤖
8 会后整理可发给客户的需求清单版本，请客户确认 产品经理 对接会后 24 小时内 飞书文档 客户确认版需求清单 🤖+👤

5. 交付物与模板

  • 交付物：定制需求评估单、MVP 需求文档、人日评估文档、成本价报告、客户确认版需求清单
  • 建议模板/表单：评估单字段——客户代号、来源渠道、场景、需求条目、适用范围（标准/渠道/客户）、标品化结论、复用度、维护成本、人日（乐观/中位/悲观）、浮动系数、成本价、售后边界、前置条件（资料、环境、模型）、风险、商务结论、排期、负责人
  • 需求澄清问卷：使用场景、角色、并发、数据类型与规模、是否离线、部署位置、模型来源、验收标准、资料格式要求

6. 异常与升级

  • 销售前期参数与实际偏差大（如并发量差一个数量级）→ 以澄清会结论为准重估 → 通知销售负责人（1 个工作日内）
  • 客户资料迟迟不到 → 评估暂停，状态改“待客户资料” → 超 5 个工作日由销售向客户书面催告
  • 定制逻辑泄漏到标准版 → 发版前阻断，产品经理当天决定隔离方式 → 升级研发负责人
  • 产研被要求直接给售价 → 只提供成本价，定价转商务负责人
  • 人日评估与客户预算差距大 → 商务负责人决定缩范围或放弃（3 个工作日内）
  • A（升级）说明：评估单、标品化判定与成本价报告由产品经理最终负责；大项目（需 CTO 先估人日中位数的项目）的范围、人日与技术边界拍板升级到 CTO；售价与是否立项由商务负责人在成本价之上决定，不得低于成本价

7. 衡量指标

  • 评估周期：受理到输出成本价的工作日数，目标 ≤ 8 天
  • 人日偏差率：实际人日 / 评估人日 − 1，目标在 ±30% 以内
  • 定制泄漏次数：定制功能出现在标准版的次数，目标 0
  • 客户确认率：需求清单经客户书面确认后才开工的项目占比，目标 100%
  • 定制转标品率：定制需求最终被标品吸收的占比（观察指标）

8. 低效诊断

  • 定制功能是否进标准版到发版前才争论，标准版带入渠道专属功能｜依据：「Leap产研测」2026-07
  • 大客户需求文档常为 AI 生成，标品与定制边界模糊，谁排期不清｜依据：「Leap产研决策部」2026-08、「Leap产研决策部」2026-09
  • 渠道需求散落群聊，每次靠人喊才推进，标品还是插件意见反复｜依据：「某渠道合作方项目群」2026-09
  • 客户只给裸接口文档，一开始没告诉客户需要什么格式；销售前期参数与实际不符｜依据：「跃迁基座项目交付沟通」2026-05、「跃迁基座项目交付沟通」2026-06
  • Demo 追加需求边界口头传达，需追问“是静态占位还是带 view”｜依据：「⭐大模型基座事业群」2026-01
  • 人日估算当天要，“我们”指代不清｜依据：「忠橙星行星引擎」2026-03
  • 研发不给时间、销售已对客户承诺，产品 owner 临时由销售兼｜依据：「某客户项目群」2026-07、「某客户项目群」2026-08
  • 行业版定制“先有客户还是先有功能”无统一标准，项目卡在 Demo 阶段｜依据：「【模态】市场销售」2026-06、「【模态】市场销售」2026-07
  • 预装渠道客户专项会议靠 @ 协调时间｜依据：「某渠道预装专项对接群」2026-07

9. 分支变体

  • 预装渠道客户：仅 Windows，按渠道 flavor 打包；新手引导等渠道专属功能默认隔离
  • 能源集团类大客户：定制 API 与通用 Channel 分开定义；新架构不兼容其定制 API 时单独维护（边车）；确认转项目前，产研不承接其非标需求
  • 渠道客户（关充值、去品牌痕迹、脱敏）：先给短期方案（环境变量/配置），长期方案并入下周发布
  • 一次性外观定制（Logo、产品名）：按固定成本价，一次性交付，再次改动另收费；页面定制按设计图另估
  • 政府/集团大型平台：人日按中位数估算并加浮动系数，硬件成本单列不计入
  • 客户 Demo：区分纯展示、可交互、评审用三类，验收清单在开工前确认

10. 待确认问题

  • 定制需求统一受理人是产品经理，还是 FDE 负责人？与 X-FDE-02 如何划界？
  • 人日成本价标准和浮动系数（如上浮 50%）是否成文？由财务还是 CTO 维护？
  • 大项目人日评估是否必须 CTO 主估？阈值是多少人日？
  • 售价审批：低于成本价的特批是否允许？由谁批准？
  • 渠道 flavor 隔离与冒烟由研发还是测试负责？
X-PRD-12跨产品线/版本线能力同步与适配决策待新建81

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：某产品线上线新能力，或主线客户端发布新版本时，决定是否、何时、以何种范围同步到其他产品线、信创版或基座组件
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、客户端核心研发（当前：岳阳·推断待确认）、信创适配负责人（当前：李子遥·推断待确认）、测试负责人（当前：张东郅·推断待确认）、基座架构负责人（当前：陈晖·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发版或新能力触发 → ② 自动生成能力变更清单 → ③ 产品逐项标注同步决策 → ④ 各线评估工作量与依赖 → ⑤ 按跟版规则定适配窗口 → ⑥ 测试排期 → ⑦ 登记同步台账并通知
  • 交付结果：跨线同步台账（能力项 × 产品线 × 是否同步 × 目标版本），以及每次主线发版对应的适配排期
  • 状态依据：LeapAll→LeapCore 同步、LeapPPT 并入、信创跟版均无规则，每次靠群内争论后拍板；信创版本曾因版本变动导致已测内容作废，测试排期被反复追问

1. 场景判定

  • 触发条件：主线客户端打 tag 或正式发布（如 1.4/1.5/1.6）；某产品线新增 Skill、Agent、页面功能；一个产品要并入另一个产品；客户项目需求与基座组件重叠
  • 典型说法：「LeapAll 到 LeapCore 的更新要形成一套 SOP」「是不是得开始做信创适配了」「跳过 1.4」「重叠度高是好事情，能考虑复用」
  • 判断问题：这个能力在另一条线是否也有用户需要？依赖的 runtime/接口版本是否一致？目标线当前是否在积极开发期？
  • 不归本流程管：新产品方向决策 → 请走 X-PRD-01；信创厂商与国产算力协同 → 请走 X-DLV-25；集成方案的技术选型争议 → 请走 RND-14；通用能力复用规范 → 请走 RND-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 同步决策（同步/不同步/延后）、维护台账 A/R 产品经理（当前：杨萌·推断待确认）
研发负责人 评估同步工作量、排入迭代 R 研发负责人（当前：王皓南·推断待确认）
客户端核心研发 说明 runtime/接口版本依赖，提供变更清单 C 客户端核心研发（当前：岳阳·推断待确认）
信创适配负责人 按跟版规则出信创包 R（信创） 信创适配负责人（当前：李子遥·推断待确认）
测试负责人 跨线测试排期 R（测试） 测试负责人（当前：张东郅·推断待确认）
基座架构负责人 评估客户需求与基座组件复用 C 基座架构负责人（当前：陈晖·推断待确认）
CTO 集成方案争议与跳版决定拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 主线版本号、发布日期、更新日志与能力变更清单
  • 目标线当前版本、所依赖的 runtime/接口版本
  • 市场节点（大会、认证、客户交付日期）
  • 测试人力情况（本周可投入人日）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 主线打 tag 或正式发布时自动生成能力变更清单（Skill、Agent、页面、接口） CI 机器人 / 客户端核心研发 发版当天 CI + 机器人 变更清单 🤖自动化
2 产品逐项标注：同步 / 不同步 / 延后，说明理由 产品经理 发版后 2 个工作日内 同步台账 同步决策 👤人工判断
3 评估同步工作量与依赖；目标线锁定所依赖的 runtime 版本，不强追最新 研发负责人，客户端核心研发 决策后 2 个工作日内 工单 工作量评估 👤人工判断
4 信创跟版：默认晚一个版本；主线正式发布且关键特性和依赖冻结后启动，正式发布后约定时间内出包 信创适配负责人 正式发布后 3 个工作日内出包 CI 构建 信创安装包 🔧+🤖
5 测试排期：构建完成自动通知测试负责人；人力不足时可跳版，须记录理由 测试负责人 收到通知后 1 个工作日内给排期 机器人 + 测试计划 测试排期 🔧飞书固化
6 产品并入或客户需求并入基座：各方写需求文档→合并→评估复用→设计确认会 产品经理，基座架构负责人 触发后 10 个工作日内开设计确认会 飞书文档 + 会议纪要 并入方案与纪要 👤人工判断
7 更新同步台账并在产研群通知 产品经理 每次决策当天 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：能力变更清单、跨线同步台账、信创适配排期、并入方案纪要
  • 建议模板/表单：同步台账字段——能力项、来源产品线/版本、目标产品线、决策（同步/不同步/延后）、理由、依赖版本、目标版本、负责人、测试状态、完成日期
  • 发版 checklist 增加一项：“跨线同步/信创跟版节点”

6. 异常与升级

  • 集成方案（复用原后端还是重写）各方争执不下 → 提交 RND-14 技术评审 → CTO 2 个工作日内拍板
  • 主线版本节奏突变导致已测内容作废 → 测试负责人提出跳版 → 产品经理当天确认并记录
  • 市场节点与跟版规则冲突（需提前适配）→ 产品经理汇总成本 → 升级 CTO（1 个工作日内）
  • 版本节奏信息经第三方传话变形 → 以台账和发版群公告为准，产品经理当天更正
  • A（升级）说明：同步/不同步/延后的决策由产品经理最终负责；集成方案有技术争议，或信创/目标线需要跳版时，拍板权升级到 CTO

7. 衡量指标

  • 同步决策时效：发版到完成逐项标注的工作日数，目标 ≤ 2 天
  • 信创出包时效：主线正式发布到信创包可测的工作日数，目标 ≤ 3 天
  • 测试作废工作量：因版本变动作废的测试人日，目标 0
  • 台账覆盖率：主线新能力中已有同步决策的占比，目标 100%

8. 低效诊断

  • LeapAll→LeapCore 无同步清单，谁负责同步不明；并入方案争论多轮后才拍板，存在重复建设｜依据：「Leap产研测」2026-05
  • 信创是否跟版每次临时争论，版本口径经传话变形，已测内容因版本变动作废，测试排期被反复追问｜依据：「信创LeapCore客户端适配」2026-07、「信创LeapCore客户端适配」2026-09
  • 客户项目需求与基座组件重叠，靠技术负责人临时合并｜依据：「某集团客户智库项目群」2026-01

9. 分支变体

  • LeapAll→LeapCore（B 端）：LeapCore 锁定对应 runtime 版本自行拉取，只加企业功能
  • 产品并入（如 LeapPPT 并入 LeapAll Agent）：先统一计费方式，再定插件协议/extension 方案
  • 信创版：现阶段晚一个版本发布；积极开发期不做适配；关键客户跳版由 CTO 决定
  • LeapAll 已暂停维护的，只做安全修复，不再同步新能力
  • 客户项目需求并入基座：建立“需求池—基座组件映射表”

10. 待确认问题

  • 跨线同步决策人是产品经理，还是各产品线负责人？
  • “信创晚一个版本”是否作为长期规则写入发版 checklist？出包时限 3 个工作日是否可行？
  • LeapAll 当前是否正式停止新能力同步？
  • 跨线同步台账放在需求池里，还是单独建表？
X-PRD-13PRD 撰写与需求评审待优化192

状态：待优化｜证据：有证据（卡片 15 张 / 会话 9 个）｜优先级：频4 × 耗4 × 跨3 × 险4

  • 适用场景：需求进入开发前，按模板写 PRD/原型并做 AI 预审，召开评审会确认技术可行性，发布评审结论和需求文档，让研发拿到能直接实现的需求
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——产品专员（当前：陈震、黄飞鹏·推断待确认）、研发负责人（当前：王皓南·推断待确认）、前端/后端评审代表（当前：季学森、侯怡辰、宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、UI 设计（当前：康紫馨·推断待确认）、跃竞线产品经理（当前：段涵、徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 判定是否需写 PRD → ② 按模板撰写 → ③ AI Review 与追问澄清 → ④ 前后端技术初评 → ⑤ 评审会宣讲与结论记录 → ⑥ 已读确认 → ⑦ 拆 issue 并关联 PRD → ⑧ 会议结论转行动清单与任务
  • 交付结果：评审通过的 PRD（含评审结论、字段变更、不做什么、验收标准）、评审会纪要与行动清单、关联 PRD 的 issue
  • 状态依据：已有 PRD 模板、需求表和每周/每迭代评审会；但临发布才发现无 PRD、需求与测试用例不匹配、“需求讲过两遍仍不知道”、术语与字段不一致、对外文档全部送 CTO 审导致单点瓶颈等问题在 01～10 月反复出现

1. 场景判定

  • 触发条件：需求已在需求池中采纳、准备进迭代；新产品方向开工前；业务讨论会形成新结论；赶工期新功能要交给 AI 开发；对外文档/话术/方案要发出
  • 典型说法：「写到研发看了能直接实现的程度」「现在需求表里面的需求是完整的吗」「你们写完需求文档后可以让 AI Review 一下」「看完点 checkmark」「你得做记录好吧」
  • 判断问题：研发拿到这份文档，是否不用再问就能实现？验收标准和不做的范围写清楚了吗？
  • 不归本流程管：需求登记与入池 → 请走 X-PRD-09；开发中的临时澄清 → 请走 X-PRD-28；评审后的需求变更 → 请走 X-PRD-29；技术方案设计 → 请走 RND-13；UI 设计稿评审 → 请走 X-PRD-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 PRD 终稿负责，主持评审，发布结论 A/R 产品经理（当前：杨萌·推断待确认）
产品专员 撰写或细化 PRD、原型，维护需求表 R 产品专员（当前：陈震、黄飞鹏·推断待确认）
研发负责人 组织技术初评、估点、拆 issue R 研发负责人（当前：王皓南·推断待确认）
前端/后端评审代表 技术可行性、字段与性能风险评审 C 前端/后端评审代表（当前：季学森、侯怡辰、宋祺睿·推断待确认）
测试负责人 评审验收标准，据此写测试用例 C 测试负责人（当前：张东郅·推断待确认）
UI 设计 提供设计稿或原型 C UI 设计（当前：康紫馨·推断待确认）
CTO 对外技术/价格类文档审阅、方向偏差纠偏 A（升级） CTO（当前：丁震宇·推断待确认）
跃竞线产品经理 跃竞线 PRD 与评审会组织 R（跃竞线） 跃竞线产品经理（当前：段涵、徐莉·推断待确认）

3. 办之前请准备

  • 需求池编号与评估结论、需求来源和业务讨论纪要
  • 用户场景（角色、目标、触发条件、预期结果）、对标产品截图
  • 涉及的业务规则与统计口径（见 X-PRD-14 词典），术语以 X-PRD-15 术语表为准
  • 做在哪条产品线/哪个架构（如 LeapNew 还是 LeapLite），不确定的先问产品经理

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定文档级别：大需求/跨端/客户相关写完整 PRD；体验类小需求用 issue 需求模板 产品经理 需求采纳后 1 个工作日内 需求池 文档级别 👤人工判断
2 按模板撰写 PRD（背景、场景、功能清单、业务规则与口径、边界与异常、不做什么、验收标准、埋点、设计稿） 产品专员 / 产品经理 评审会前 ≥ 3 个工作日完成初稿 飞书文档模板 PRD 初稿 🔧飞书固化
3 AI Review：检查规则冲突、状态机缺失、术语不一致、歧义，并追问到无歧义 产品专员 初稿后 1 个工作日内 AI 评审清单 / 追问 skill 修订稿 🤖自动化
4 技术初评：至少 1 名前端 + 1 名后端阅读并标注可行性与风险（性能、SQL 复杂度、依赖） 前端/后端评审代表 评审会前 1 个工作日 文档评论 技术意见 👤人工判断
5 评审会：会前 1 个工作日发文档；会上宣讲，逐条确认，记录结论、字段变更、范围调整 产品经理主持 迭代开始前 ≥ 2 个工作日；高优需求当场拉人评审 飞书日程 + 妙记 评审结论 🔧+🤖
6 评审结论写入 PRD 固定章节；参评人在文档点“已读确认” 产品经理，各参评人 会后 1 个工作日内 飞书文档 / 任务 已确认 PRD 🔧飞书固化
7 拆 issue，关联 PRD 链接；设计以 issue 为准，PRD 每迭代结束归档 研发负责人 评审后 1 个工作日内 Gitea / issues issue 清单 🤖+👤
8 业务讨论会结论：会后整理“结论 + 待确认项 + 截止时间”，建行动清单和飞书任务 产品经理 会后 24 小时内 飞书文档 + 任务 行动清单 🔧+🤖
9 对外文档分级审阅：涉及技术边界、价格、对外承诺的送 CTO 审；其余产品经理自审后直接发 产品经理，CTO CTO 审阅 1 个工作日内回复 飞书文档批注 审阅意见 👤人工判断

5. 交付物与模板

  • 交付物：PRD（含评审结论章节）、评审纪要、已读确认记录、关联 issue、行动清单
  • 建议模板/表单：PRD 模板——版本记录、需求背景、用户场景表（场景/角色/目标/触发条件/预期结果）、功能清单（功能/说明/优先级/上线版本）、功能详情（业务规则/口径/边界异常/示意图）、不做什么、验收标准、非功能需求、埋点需求、设计稿链接、评审结论与字段变更清单
  • AI 评审清单：规则冲突、状态机完整性、权威文档优先级、术语一致性、异常分支、验收标准可测性

6. 异常与升级

  • 临发布才发现无 PRD → 测试负责人当天通报产品经理，按现网补写最小 PRD 再测 → 升级研发负责人
  • 测试用例先于需求确认完成、与需求不符 → 以评审通过的 PRD 为准重修用例 → 产品经理 1 个工作日内确认
  • 开发中发现 PRD 缺失细节 → 走 X-PRD-28，产品经理 4 个工作小时内答复
  • 多位管理者对同一需求口径不一 → 产品经理汇总分歧 → CTO 当天召集对齐
  • CTO 审阅超 1 个工作日未回 → 产品经理按分级规则判断可否先发；对外价格/承诺类不得先发
  • A（升级）说明：PRD 终稿与评审结论由产品经理最终负责；对外文档涉及技术边界、价格或对外承诺，或需求方向明显偏离产品规划时，拍板权升级到 CTO

7. 衡量指标

  • PRD 覆盖率：进迭代的大需求中有评审通过 PRD 的占比，目标 100%
  • 评审前置天数：PRD 发出到评审会的工作日数，目标 ≥ 1 天
  • 需求返工率：因需求不清导致返工的 issue 占比，目标 ≤ 10%
  • 已读确认率：参评人完成已读确认的比例，目标 100%
  • CTO 审阅量：每月送 CTO 审阅的文档数，目标逐月下降

8. 低效诊断

  • 需求描述粗、改动频繁，交互“谁定的”找不到，同一需求冲突｜依据：「Leap产研测」2026-08
  • 任务拆得不够细，大需求下遗漏点长期推不上线；评审参会人每次现定｜依据：「鼎慧产研决策部」2026-01
  • 需求会宣讲后无留痕，“讲过两遍仍不知道”；字段与产品术语不一致｜依据：「工程咨询产研」2026-01
  • 评审时机与参会角色争论，文档与 issue 两套设计内容并存｜依据：「工程咨询产研」2026-01
  • 业务讨论结论未记录，口头传达导致研发方向理解错误｜依据：「鼎慧产研决策部」2026-07
  • 需求各方来、方案出完又被全改，未形成共识就开发｜依据：「鼎慧产研决策部」2026-05
  • 需求写不到“研发可直接实现”的程度，术语不一致导致返工｜依据：「鼎慧产研决策部」2026-07
  • 其他部门写的 PRD 无人评审，规则冲突导致 Agent 无法实现｜依据：「董事会专项沟通群」2026-08
  • 评审召集靠手工 @，评审前文档来不及发，历史需求分散在多个表｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09
  • 技术风险在故障后才暴露给产品，评审缺技术风险项｜依据：「告警通知群」2026-09
  • 原型缺页面和逻辑，外部开发逐页提问｜依据：「手机端-录音卡」2026-09

9. 分支变体

  • 赶工期新功能交 AI 开发：先用 AI 追问式澄清到无歧义，输出详细需求说明书再开发；合规相关功能一律“先审后发”
  • 跃竞线：每迭代（约两周）固定需求评审会，需求文档带“口径”章节，评审前用仓库内产品经理 skill 预审
  • 政府/外部甲方口头需求：由对接人整理成文并请对方确认后再开发；频繁变更走 X-PRD-29
  • 手机端/硬件配套：原型标 P0/P1/P2 和版本号，更新后通知外部开发刷新
  • 业务部门自建系统 PRD（如积分、CRM）：写完先做 AI Review，再请 CTO 或指定技术人员评审

10. 待确认问题

  • 评审会固定参会角色（产品 + 前端 1 + 后端 1 + 测试）是否认可？
  • 哪些文档必须送 CTO 审？是否按“对外/价格/技术边界”分级，其余免审？
  • PRD 与 issue 以谁为准？PRD 归档周期是否为每迭代？
  • 业务部门的 PRD 由谁评审？
  • PRD 前置 3 个工作日在赶工月是否可行？
X-PRD-14业务规则与统计口径定义待优化144

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：需求未写清的业务规则（额度归属、折扣、分账、状态定义、支付限额等），或同一指标在不同端、不同报表的计算不一致时，由产品定义规则/口径并全链路统一
  • 负责人：主责——对应产品线产品经理（当前：鼎慧线黄飞鹏、跃竞线徐莉·推断待确认）；协同——Leap 线产品经理（当前：杨萌·推断待确认）、跃竞产品（当前：段涵、樊九辰·推断待确认）、后端研发（当前：蒋兴武、王子明、张楠、陈锦杰、王皓南·推断待确认）、测试（当前：赵伟龙、李国庆·推断待确认）、财务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发现规则/口径疑问 → ② 工单打“待产品确认”标签提问 → ③ 产品给出结论（资金类会签） → ④ 写入业务规则与口径词典 → ⑤ 通知研发/测试/运营 → ⑥ 测试按口径验证 → ⑦ 存量数据影响处理 → ⑧ 上线公告
  • 交付结果：业务规则与统计口径词典（每条有定义、公式、取值区间、生效版本），以及对应的实现与测试验证记录
  • 状态依据：能找到产品拍板，跃竞线已有部分口径文档；但口径细节散落聊天，同一指标多次修订，开发与测试各有记忆，规则收紧后才发现老用户受影响，支付限额等规则“没人讨论决策过”

1. 场景判定

  • 触发条件：开发或测试对规则有疑问；报表数字被质疑；同一指标在管理端、排行榜、数据大屏不一致；规则变更需全链路统一；支付限额、超时等参数需要确定
  • 典型说法：「这个数据的口径是什么？」「以产品为主」「有这个需求吗，我有点记不清了」「测试验收的口径，累计消费包含哪些？」「订单 24 小时，支付尝试 2 小时」
  • 判断问题：这个问题的答案会影响金额、结算、额度或报表吗？是否已有词典条目？
  • 不归本流程管：套餐、积分、额度定价 → 请走 X-PRD-23；模型价格倍率 → 请走 X-PRD-22；计费余额异常核查 → 请走 X-CS-09；产品数据统计导出 → 请走 X-PRD-39；需求变更 → 请走 X-PRD-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
对应产品线产品经理 规则与口径拍板，维护词典 A/R 对应产品线产品经理（当前：鼎慧线黄飞鹏、跃竞线徐莉·推断待确认）
Leap 线产品经理 Leap 线（含支付）规则定义，按“对应产品线产品经理”职责执行 R（Leap 线） Leap 线产品经理（当前：杨萌·推断待确认）
跃竞产品 状态规则、大屏字段口径整理 R 跃竞产品（当前：段涵、樊九辰·推断待确认）
后端研发 提出疑问、解释现有实现、按口径修改 R（实现） 后端研发（当前：蒋兴武、王子明、张楠、陈锦杰、王皓南·推断待确认）
测试 按口径设计用例并验证 R（验证） 测试（当前：赵伟龙、李国庆·推断待确认）
财务 涉及结算、分账、收入统计的口径会签 C 财务（当前：待指定）
CTO 无人决策时的规则拍板（如支付限额） A（升级） CTO（当前：丁震宇·推断待确认）
机器人 词典条目更新后通知研发、测试、运营 R（自动） 多维表格自动化（由产品经理配置）

3. 办之前请准备

  • 疑问的具体场景：哪个页面/接口/报表、示例数据、当前实现结果、预期结果
  • 已查过的词典条目和需求文档链接
  • 影响范围：涉及哪些端、报表、是否涉及金额或存量用户
  • 可参考的成熟做法（电商、支付平台惯例）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 issue 中提问，打“待产品确认”标签，写清场景和候选答案；群里只贴链接 提问的研发/测试 发现当天 Gitea / issues 待确认问题 👤人工判断
2 产品给出结论；涉及金额、结算、分账的需财务会签 产品经理 1 个工作日内；资金类 2 个工作日内 issue 评论 规则结论 👤人工判断
3 复杂规则（结算、卡点支付等）拉 30 分钟评审会，优先参考成熟经验 产品经理 2 个工作日内 飞书会议 评审结论 👤人工判断
4 写入词典：编号、定义、公式、取值区间（如统一左闭右开）、包含/排除项、生效版本、影响范围 产品经理 结论当天 飞书文档 / 多维表格 词典条目 🔧飞书固化
5 机器人通知研发、测试、运营；需求模板引用词典编号 机器人 条目更新即时 多维表格自动化 变更通知 🔧+🤖
6 实现修改；测试按口径设计覆盖场景（含退款、回滚、部分结算）并验证 后端研发，测试 按迭代 工单 / 测试用例 验证记录 👤人工判断
7 评估存量数据与老用户影响，制定补发/迁移/引导方案 产品经理，后端研发 上线前 1 个工作日 方案文档 存量处理方案 👤人工判断
8 上线公告写明口径变化，回填词典生效日期 产品经理 上线当天 上线通知机器人 上线公告 🔧+🤖

5. 交付物与模板

  • 交付物：业务规则与统计口径词典、规则结论 issue、评审结论、存量处理方案、上线公告
  • 建议模板/表单：词典字段——编号、产品线、规则/指标名称、定义、计算公式、时间区间、包含项、排除项（退款、红包、券等）、适用端、示例、决策人、会签人、生效版本、生效日期、变更历史、关联需求/issue
  • 支付参数表：单笔上下限、起充金额、订单有效期、支付尝试有效期、支持支付方式、金额精度、每日收款额度；参数进配置中心，不写死在代码里

6. 异常与升级

  • 产品 1 个工作日未答复 → 研发负责人催办 → 升级 CTO（再 1 个工作日）
  • 已上线口径被发现错误且影响结算/报表 → 产品经理当天评估影响 → 涉及资金时同步财务并升级 CTO
  • 规则收紧影响存量用户（如额度不可用）→ 上线前必须出存量处理方案，否则不得发布
  • 开发与测试对同一口径理解不同 → 以词典为准；词典缺失时按步骤 1 提问
  • 外部渠道限额触发收款失败 → 先开临时额度或分流商户 → 升级 CTO 当天决定
  • A（升级）说明：业务规则与统计口径由对应产品线产品经理拍板（Leap 线由 Leap 线产品经理按同一职责执行）；无人能决策、跨产品线口径冲突，或涉及支付限额等外部渠道约束时，拍板权升级到 CTO

7. 衡量指标

  • 口径答复时效：提问到产品结论的工作小时数，目标 ≤ 8 小时
  • 词典覆盖率：涉及金额/报表的需求中引用词典编号的占比，目标 100%
  • 口径返工次数：同一指标上线后再修订的次数，目标每指标 ≤ 1 次
  • 重复提问数：已在词典中却仍在群里提问的次数，持续下降

8. 低效诊断

  • 组织额度与个人额度能否混用，研发与测试各有记忆；规则收紧后才提醒手动补发额度，用户因引导不足报额度不足｜依据：「工程咨询产研」2026-04、「工程咨询产研」2026-06
  • 接待业绩、累计消费等指标多端口径不一致，至少 5 次修订，测试完成后仍有口径统一需求｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-09
  • 折扣算法按开发理解实现后当天返工；结算公式多次推翻；业务规则只存在聊天中｜依据：「跃玩项目组」2026-02、「跃玩项目组」2026-06
  • 回滚、分账、累计消费口径被反复追问，测试场景覆盖不全导致遗漏｜依据：「跃玩项目组」2026-07、「跃玩项目组」2026-08
  • 支付上下限、超时时间无人正式决策，反复询问｜依据：「LeapPay」2026-08

9. 分支变体

  • 鼎慧/工程版：个人空间只用个人额度、组织空间只用组织额度；渠道用户另有限制（禁止查看组织页、禁止退出）
  • 跃竞线：订单、存单（6 种状态）、罚款与合规、业绩统计、会员等级、成长值各设词典分册；商业模式类问题（买断制/订阅制）由跃竞负责人决定
  • 支付规则：支付宝/网银/微信分别配置；个人支付与企业支付分开；过期订单不得计入充值限额
  • 线索分发类规则：分发去重粒度、是否允许部分重复写入需求文档规则章节

10. 待确认问题

  • 词典放飞书文档还是多维表格？Leap 线和跃竞线是否共用一套结构？
  • 涉及结算、分账的口径是否必须财务会签？由哪位财务负责？
  • 产品答复时效 1 个工作日是否可行？
  • 支付参数（限额、起充、超时）的最终决策人是产品经理还是 CTO？
  • 是否要求所有涉及金额的需求在 PRD 中引用词典编号？
X-PRD-15产品命名、术语与用户可见文案规范待新建72

状态：待新建｜证据：有证据（卡片 9 张 / 会话 6 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：新产品、模块、型号需要命名，或出现说法不一、内部技术名词外露、报错与提示文案不清时，统一命名与术语表，规范对外口径和用户可见文案
  • 负责人：主责——产品经理（当前：杨萌·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品专员（当前：陈震·推断待确认）、前端研发（当前：葛家和、侯怡辰·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 命名/文案需求提出 → ② 生成候选并查重（重名、商标、域名、禁用词） → ③ 拍板定名 → ④ 登记命名与术语表 → ⑤ 发布通知与改名影响清单 → ⑥ 代码/界面/文档统一修改 → ⑦ 用户可见文案对照表维护 → ⑧ 发版前禁用词扫描
  • 交付结果：命名与术语表（内部名/对外名/中文名/代码字段/禁用词/商标状态）、错误码—文案对照表、改名影响清单完成记录
  • 状态依据：命名靠群内头脑风暴和口头通知，产品名多次更换；术语（容器/团队 Agent、插件/技能、点数/词元/额度）各说各话；内部名（如 VPN 类名词）外露给客户；报错文案“让优化但没说优化成什么”；仅鼎慧线有“统一语言文档”，Leap 线刚把部分规则固化到代码

1. 场景判定

  • 触发条件：新产品/模块/型号需要名字；客户要求不出现开源品牌或特定字样；同一概念出现多种叫法；UI 出现英文技术名、内部代号；报错只显示错误码或“出现错误”；短信、弹窗、引导文案需要定稿
  • 典型说法：「概念要统一」「决定叫团队 Agent 了就不要叫别的」「不要用 LeapVPN 这个词，选个中文名字」「对外名称有定吗，我这边很多资料要填」「人性化的报错消息是很重要的」
  • 判断问题：这个名字/说法客户会看到吗？术语表里有没有？是否涉及商标或客户禁用词？
  • 不归本流程管：对外 FAQ 与销售话术 → 请走 X-CS-17；品牌视觉与 Logo 设计 → 请走 BRD-02（品牌视觉设计评审与源文件取用），产品内界面设计走 X-PRD-16；商标注册 → 请走 LEG-16（商标查询、注册申请与驳回复审）；更新日志撰写 → 请走 X-PRD-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 对外名称、用户可见文案拍板，维护术语表 A/R 产品经理（当前：杨萌·推断待确认）
CTO 产品概念定义、对外口径（含禁用词）决策 A（升级） CTO（当前：丁震宇·推断待确认）
研发负责人 维护“统一语言”，保证代码名与用户名一致、查重名 R 研发负责人（当前：王皓南·推断待确认）
产品专员 撰写提示与报错文案 R 产品专员（当前：陈震·推断待确认）
前端研发 文案集中配置、禁用词扫描规则固化 R（实现） 前端研发（当前：葛家和、侯怡辰·推断待确认）
开放平台负责人 上架 Skill 命名审核 R（开放平台） 开放平台负责人（当前：郭逸非·推断待确认）
品牌 / 法务 对外品类名、商标与重名检索 C 品牌（当前：待指定）、法务负责人（当前：李瑶·推断待确认）
提出人 提交命名/文案需求，说明对象、面向与截止日期 R（提报） 各部门提出人

3. 办之前请准备

  • 命名对象：产品/模块/型号/功能/内部组件；面向对象（C 端/B 端/内部）
  • 定位一句话、后续迭代规划（型号命名要预留等级和后缀）
  • 候选名 3 个以上，附理由
  • 客户禁用词要求（如不得出现开源品牌名、俗称）
  • 涉及界面、仓库、域名、备案、文档、Logo 的清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交命名/文案需求（对象、面向、候选、截止日期） 提出人 需要前 ≥ 5 个工作日 飞书表单 命名需求 🔧飞书固化
2 生成候选并检索：重名、商标、域名、禁用词、竞品相似度 研发负责人 / 法务 2 个工作日内 AI + 商标检索 候选检索表 🤖自动化
3 定名：对外产品名、品类名由 CTO 与产品经理定，品牌参与；功能名由产品经理定（可飞书投票） 产品经理，CTO 检索后 1 个工作日内 飞书投票 定名结论 👤人工判断
4 登记术语表：中文名、英文名、内部名、代码字段、定义、禁用说法、面向对象 产品经理 定名当天 多维表格（置顶） 术语条目 🔧飞书固化
5 发布通知并生成改名影响清单（界面、仓库、域名、文档、Logo、对外资料），逐项指派 产品经理 定名当天 飞书任务 影响清单 🔧飞书固化
6 代码字段与用户名不一致的，原则上改为一致；确需保留的在术语表标注 研发负责人 下一个迭代内 Gitea 统一记录 👤人工判断
7 维护错误码—文案对照表、短信与弹窗模板；缺陷单要求“优化文案”时必须附目标文案 产品专员 开发前提供；缺陷单 1 个工作日内 多维表格 / 配置 文案对照表 🤖+👤
8 发版前扫描 UI 字符串中的禁用词和内部名；开放平台上架时审核命名 前端研发，开放平台负责人 每次发版 / 每次上架 CI 脚本 + 上架审核 扫描报告 🤖自动化

5. 交付物与模板

  • 交付物：命名与术语表、改名影响清单、错误码—文案对照表、文案模板库、禁用词扫描报告
  • 建议模板/表单：术语表字段——术语、英文名、中文名、内部名/代号、代码字段、定义（一句话）、面向对象（C/B/内部）、禁用说法、商标状态、启用日期、决策人、备注
  • 文案对照表字段——错误码/场景、用户可见文案、是否可重试、引导动作、适用端、负责人

6. 异常与升级

  • 已定名后又有人提议改名 → 需提交理由与影响评估，CTO 批准方可改 → 否则维持原名
  • 客户发现界面出现禁用词或内部名 → 产品经理当天定替换文案 → 研发以热修复处理
  • 候选名商标冲突 → 法务当天告知 → 回到步骤 2
  • 研发与产品对术语叫法不一致 → 以术语表为准；术语表缺失时产品经理 1 个工作日内补充
  • A（升级）说明：功能名与用户可见文案由产品经理拍板；对外产品名、品类名、产品概念定义和对外禁用词，拍板权升级到 CTO，品牌与法务参与检索把关

7. 衡量指标

  • 术语表覆盖率：对外材料中出现的产品/功能名在术语表中的占比，目标 100%
  • 改名次数：同一产品对外名称年度变更次数，目标 ≤ 1 次
  • 禁用词外露：发版后客户发现的禁用词/内部名数量，目标 0
  • 文案缺失返工：因未给目标文案导致的缺陷单来回次数，目标 0

8. 低效诊断

  • 产品名多次更换，命名靠口头定案，导致仓库、界面、域名反复改｜依据：「Leap产研测」2026-04、「Leap产研测」2026-05
  • 对外名称定名后只在群里通知，资料填写人不知道正式名称｜依据：「LeapCore（archived）」2026-04
  • 容器、团队 Agent、节点等概念反复改叫法，产品定位靠争论澄清｜依据：「鼎慧产研决策部」2026-05、「鼎慧产研决策部」2026-06
  • 一个功能三个名字，素材图定稿后才发现与代码命名不一致｜依据：「工程咨询产研」2026-01
  • 插件、技能、项目等概念对内对外讲法不同，品类名临时头脑风暴｜依据：「Leap产研决策部」2026-09
  • 内部技术名词外露到用户界面和开放平台，需多处逐个修改｜依据：「Leap产研测」2026-09
  • 缺陷单只写“优化文案”不给目标文案，开发需要再找产品｜依据：「Leap产研测」2026-08
  • 短信、弹窗、点数称呼等文案每次临时决定，散落在代码和群消息中｜依据：「工程咨询产研」2026-03、「工程咨询产研」2026-04
  • 型号命名无风格标准｜依据：「随便瞎聊啦～」2026-04

9. 分支变体

  • C 端 / B 端 / 内部组件三套命名口径，在术语表“面向对象”字段区分
  • B 端客户禁用词：不得出现开源品牌名及俗称，对 B 端统一使用正式产品名
  • 硬件型号：采用“等级体系 + 后缀”结构，预留迭代空间
  • 对外品类名：可由市场按“好卖”原则选，但须登记术语表并经 CTO 确认技术描述无误
  • 开放平台 Skill：客户可见名称不带内部产品前缀，官方/非官方需标记

10. 待确认问题

  • 术语表统一维护人是产品经理，还是品牌岗？鼎慧线已有的“统一语言文档”是否并入？
  • 对外产品名的最终决策人：CTO、CEO 还是 COO？品牌岗是否参与？
  • 禁用词扫描是否纳入 CI 必过检查？
  • 商标/重名检索由法务做，还是研发先用工具初筛？
X-PRD-16UI/UX 设计需求、评审与设计走查待优化72

状态：待优化｜证据：有证据（卡片 14 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨3 × 险2

  • 适用场景：新功能/页面需要设计，或界面风格不一致时，提设计需求、评审设计稿或方案、前端还原、设计走查并完成 UI 验收，规范和素材统一沉淀
  • 负责人：主责——产品经理（当前：杨萌；跃竞线段涵·推断待确认）；协同——UI 设计师（当前：康紫馨、史家宜、陈伟康·推断待确认）、前端研发（当前：岳阳、葛家和、季学森、侯怡辰、郝智豪、魏小东、陈真炎·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品专员（当前：杨黔昆、陈震、黄飞鹏、陈雁·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提设计需求单 → ② 设计排期（无设计资源时 AI 原型） → ③ 开发前草图/方案评审 → ④ 高保真稿交付（标注、切图、状态稿、版本号） → ⑤ 前端还原 → ⑥ 设计走查 → ⑦ 产品 UI 验收 → ⑧ 规范与素材归档
  • 交付结果：评审定稿的设计稿（统一入口、带版本号）、设计走查记录、UI 验收结论，以及持续更新的设计规范（色卡、组件、图标）与素材库
  • 状态依据：已有设计稿、Figma、UI/UX 反馈文档，跃竞线有稳定的“初稿→产品评审→还原→验收”做法；但 Leap 线常由研发先自行生成界面、上线后才评审，设计规范与色卡缺失，设计稿版本不清，走查要临时打包，反馈文档与工单割裂

1. 场景判定

  • 触发条件：新页面/新功能有界面；界面风格与其他端不一致；需要 Logo、卡片图、图标等素材；品牌色调整；测试与正式环境需要视觉区分；开发完成需设计走查
  • 典型说法：「做有 UI 的产品之前先把 UI 草图发出来吧」「风格不分端」「直接放设计稿吧，置顶的」「色卡在哪里看」「设计完成初稿（共 N 页），待产品评审」
  • 判断问题：用户能看到这个界面吗？有没有现成组件和规范可套用？是否需要设计师出稿，还是按规范由前端直接做？
  • 不归本流程管：功能需求评审 → 请走 X-PRD-13；产品验收整体流程 → 请走 X-PRD-31；文案与命名 → 请走 X-PRD-15；营销物料设计 → 请走 BRD-13（宣传物料制作与校对）；组件库技术选型 → 请走 RND-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品经理 提设计需求、主持评审、UI 验收拍板 A/R 产品经理（当前：杨萌；跃竞线段涵·推断待确认）
UI 设计师 出稿、维护设计规范与素材库、设计走查 R UI 设计师（当前：康紫馨、史家宜、陈伟康·推断待确认）
前端研发 按稿还原，问题反馈，切图使用 R（实现） 前端研发（当前：岳阳、葛家和、季学森、侯怡辰、郝智豪、魏小东、陈真炎·推断待确认）
研发负责人 方案可行性、排期，决定 UI 修改优先级 C 研发负责人（当前：王皓南·推断待确认）
测试负责人 为设计走查提供可安装包，记录 UI 缺陷 C 测试负责人（当前：张东郅·推断待确认）
产品专员 原型、交互规格、UI 反馈汇总与提单 R 产品专员（当前：杨黔昆、陈震、黄飞鹏、陈雁·推断待确认）
CTO 风格原则（如 B 端交互基于 C 端）、设计资源配置 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求文档/原型链接、页面清单、优先级、截止日期
  • 参考对象：现有规范、成熟产品截图；C 端与 B 端的风格基准
  • 涉及的状态：空状态、加载、错误、权限不足、移动端/窄窗口
  • 涉及品牌/主题（多品牌适配时列出品牌清单）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交设计需求单（页面、场景、优先级、截止、参考、涉及品牌） 产品经理 / 产品专员 开发前 ≥ 5 个工作日 多维表格“设计需求单” 设计需求 🔧飞书固化
2 设计排期；设计资源不足时，用 AI 原型工具按规范出稿，由产品确认 UI 设计师 / 产品经理 收到后 1 个工作日内回复排期 设计台账 排期 🤖+👤
3 开发前草图或多方案评审：发方案与理由，必要时飞书投票，产品拍板并记录结论 产品经理主持 开发前 ≥ 2 个工作日 飞书文档 / 投票 评审结论 👤人工判断
4 高保真稿交付：标注尺寸、切图、空/错误/加载状态稿、版本号，置顶到统一入口 UI 设计师 按排期；评审后 3 个工作日内 Figma + 置顶链接 定稿设计稿 🔧飞书固化
5 前端按稿还原；与稿不符或稿缺失时在工单提问，不在群里凭记忆讨论 前端研发 按迭代 Gitea 还原实现 👤人工判断
6 提供走查环境：nightly 包或测试环境地址，设计专用测试账号 测试负责人 / CI 前端提测当天 CI nightly + 机器人推送 可用安装包 🔧+🤖
7 设计走查：按清单比对（间距、色值、图标、字重、状态稿、风格一致性），问题提 UI 工单附截图与预期 UI 设计师 提测后 2 个工作日内 走查清单 + 工单 走查记录 🤖+👤
8 产品 UI 验收；功能缺陷修完后批量处理 UI 问题，小改动直接改不另提单 产品经理 走查后 1 个工作日内 工单 验收结论 👤人工判断
9 规范与素材归档：色卡、组件、图标、Logo、卡片图更新到设计规范和素材库，附目录导览 UI 设计师 每迭代结束前 飞书文档 / 云盘素材库 规范更新 🔧飞书固化

5. 交付物与模板

  • 交付物：设计需求单、评审结论、定稿设计稿（带版本号）、走查记录、UI 验收结论、设计规范、素材库
  • 建议模板/表单：设计台账字段——页面/素材、产品线/品牌、需求链接、优先级、截止日期、设计负责人、前端负责人、稿件版本、评审状态（待评审/已评审/已定稿）、走查状态、验收结论
  • 设计走查清单：布局与间距、色值与色卡、字体字重、图标一致性、空/错/加载状态、窄窗口与移动端、深浅色模式、文案溢出、与其他端风格一致
  • 设计规范最小集：色卡（含品牌色、状态色）、组件库、图标库、布局原则（卡片不嵌套、少用圆角阴影、简洁）、测试环境视觉标识

6. 异常与升级

  • 研发未经评审直接上线有界面的功能 → 产品经理要求补走查，问题入下一迭代 → 重复发生升级研发负责人
  • 设计稿版本不清、实现与稿冲突 → 以置顶入口最新版本为准；设计师 4 个工作小时内确认
  • 设计资源被占用、排期超过截止日期 → 产品经理决定改用 AI 原型或调整优先级 → 资源长期不足升级 CTO
  • nightly 包不可用导致无法走查 → 测试负责人当天通知研发修复 CI，临时手动打包
  • 测试与正式后台视觉无法区分 → 研发当天加环境水印或配色区分
  • A（升级）说明：设计需求、方案评审结论与 UI 验收由产品经理拍板；涉及全产品风格原则调整，或设计资源不足需要跨团队调配时，拍板权升级到 CTO

7. 衡量指标

  • 开发前评审率：有界面的需求中开发前完成草图/方案评审的占比，目标 ≥ 90%
  • 还原一致性返工：走查发现的偏差项数 / 页面数，目标逐迭代下降
  • 走查及时率：提测后 2 个工作日内完成走查的占比，目标 ≥ 90%
  • 设计需求周期：需求单提交到定稿的工作日数，目标 ≤ 5 天
  • 规范可查率：色卡、组件、图标均在统一入口可查，目标 100%

8. 低效诊断

  • 各端由不同开发自行生成页面，风格不一致，上线后才评审，登录页、Logo 位置等反复返工｜依据：「Leap产研测」2026-04、「Leap产研测」2026-05
  • 研发按自己理解先做界面，状态含义、英文过多等问题上线后才被评｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • UI/UX 反馈文档与工单割裂，设计不知道哪个分支是最新样式｜依据：「Leap产研测」2026-05
  • 多方案投票缺设计师参与，样式反复修改｜依据：「Leap产研测」2026-06
  • 缺统一色卡，设计稿与实现尺寸不一致，设计请假时无人对稿｜依据：「Leap产研测」2026-07、「Leap产研测」2026-09
  • 设计稿版本不清，图标在仓库与设计稿不一致｜依据：「Leap产研测」2026-09
  • 设计走查需要安装包，每次临时打包，nightly 包不可用｜依据：「Leap产研测」2026-08
  • 缺 UI 规范与设计角色，每个功能重新讨论布局；改图需排期，环境靠记忆区分｜依据：「工程咨询产研」2026-01、「工程咨询产研」2026-04
  • 尺寸标注缺失，前端自行量取；多品牌样式并行需反复修色｜依据：「跃玩项目组」2026-06、「跃玩项目组」2026-07
  • 设计稿评审状态只在日报中体现，无统一台账｜依据：「跃玩项目组」2026-08
  • 卡片图、图标重复提需求，素材分散无目录｜依据：「鼎慧通-UI」2026-01、「鼎慧通-UI」2026-03

9. 分支变体

  • Leap 系列：C 端（LeapAll/LeapNew）与 B 端（LeapCore）风格不分端，B 端交互基于 C 端，只增加企业功能；暂无专职设计时按规范用 AI 原型
  • 跃竞线：设计需求文档→初稿（标页数）→产品评审→定稿→前端还原→设计配合切图→产品 UI 验收；多品牌（星域、会员端、弈荟等）用主题 Token 减少重复设计
  • 鼎慧/字字可研：卡片图、Banner、图标素材走设计需求单，统一归档到素材库
  • 品牌色或 Logo 变更：先更新色卡与 Logo 包，再列出受影响页面统一替换，官网与落地页图片同步
  • 测试/正式环境：测试后台使用灰色或水印标识，正式后台保持正式 Logo
  • Win/Mac 渲染差异：走查需在两个平台各看一遍

10. 待确认问题

  • Leap 线是否设专职 UI/UX？若无，设计规范由谁维护？
  • 设计台账放在需求池里，还是单独建表？
  • “有界面功能开发前必须评审草图”是否作为硬性门槛？小改动的豁免标准是什么？
  • 设计走查是否纳入 X-PRD-31 产品验收的必经环节？
  • 素材库统一放 Figma 还是飞书云盘？由谁归档？
X-PRD-17风险功能准入与合规需求评估待新建150

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨5 × 险5

  • 适用场景：产品功能可能带来安全或法务风险（加载本机插件、执行系统命令、对外开放数据接口），客户 IT 提出安全合规要求（禁用命令、防批量拷贝、操作审计），或用户协议/隐私政策首次上线、内容更新、需要用户重新同意时，进开发排期前先完成风险评估和准入决策
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、LeapCore 后端（当前：杨云峰·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、协议功能研发（当前：魏宗浩·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记风险/合规需求 → ② 风险分级 → ③ 技术路径与成本评估 → ④ 法务与合同条款评审 → ⑤ 准入决策 → ⑥ 落地风险提示、开关或协议版本 → ⑦ 上线前复核 → ⑧ 归档并答复客户
  • 交付结果：风险评估单（结论为准入/有条件准入/不准入）、上线的风险提示组件与功能开关（如开发者模式）、合同免责条款或对客承诺边界说明、协议版本台账与用户同意记录
  • 状态依据：本机插件的风险提示和开发者模式是功能上线后才补的，随后紧急发 hotfix；客户安全需求没有需求单，技术方案在群里反复约 4 轮；协议更新由产品直接拍板“不检测更新”，没有法务审核，也没有版本留痕。三类情况都靠临时讨论，没有上线前的安全/法务评审环节

1. 场景判定

  • 触发条件：
    • 新功能涉及加载本地或第三方代码（插件、Skill 脚本）、执行系统命令、对用户开放 API/WebDAV 等数据通道、采集个人信息
    • 客户（尤其国企、政企）IT 提出安全要求：禁用指定命令（如 rm）、只读挂载、禁止批量导出、操作审计
    • 用户协议、隐私政策、EULA 需要首次展示，或者内容变更后要决定是否让用户重新同意
  • 典型说法：「加载本地插件的风险提示+开发者模式」「让实例禁用某些系统命令行不行」「我们应该禁止别人从 NAS 里直接批量拷贝数据」「后面协议更新了，怎么检测更新让用户重新同意」「其实进了也没用，得写进合同里」
  • 判断问题：这个功能或承诺一旦出问题，会不会造成客户设备中毒、数据泄露、合同违约或法律责任？会，就先走本流程，再进迭代
  • 不归本流程管：协议/隐私政策正文的法律起草与审定 → 请走 LEG-18；整个新产品上线前的全面合规评估 → 请走 LEG-19；Agent 权限控制的技术设计与实现 → 请走 RND-20；普通客户定制需求的评估与报价 → 请走 X-PRD-11；上线前安全测试与漏洞修复 → 请走 RND-44

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求登记人 带回客户要求或提出风险功能，填写风险评估单 R 提出方（产品/研发/销售对接人）
产品负责人 风险分级、组织评估、出准入结论、管理需求 R/A 产品总监（当前：杨萌·推断待确认）
技术评估人 给出至少 2 种技术路径、复杂度、工期和副作用 R Leap 研发负责人（当前：王皓南·推断待确认）、LeapCore 后端（当前：杨云峰·推断待确认）
基础设施/安全 评估存储、网络、命令权限类方案的可行性 C IT 运维/基础设施（当前：杨明学·推断待确认）
法务 判断法律风险、合同免责条款、协议文本与同意机制 C 法务负责人（当前：李瑶·推断待确认）
实现人 落地风险提示、开关、协议版本与同意记录 R 协议功能研发（当前：魏宗浩·推断待确认）、插件研发（当前：侯怡辰·推断待确认）
终审 高风险项或产品与法务意见冲突时拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
测试 上线前对照评估单复核提示、开关、协议链接是否生效 R 测试负责人（当前：张东郅·推断待确认）
销售/交付对接人 向客户答复承诺边界，同步合同条款 I 客户对接人（当前：待指定）

3. 办之前请准备

  • 功能说明或客户原始要求（截图、邮件、会议纪要），写明涉及哪些版本和客户
  • 风险点清单：可能的攻击面、数据流向、谁受影响
  • 现有同类能力与已发布版本情况（是否已上线、已有多少客户在用）
  • 现行用户协议/隐私政策版本（当前以飞书文档维护的 LeapCore 用户协议和隐私政策为准）
  • 涉及合同的客户：合同中已有的安全、保密、免责条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记风险/合规需求，附原始材料，禁止只在群里转述 需求登记人 发现或收到客户要求后 1 个工作日内 飞书多维表格（风险评估单）/工单 风险评估单 🔧飞书固化
2 按“安全/数据/法务/合规”分类并定级（高/中/低），高风险项在研发开工前冻结 产品负责人 登记后 1 个工作日内 风险评估单 风险等级、是否冻结开发 👤人工判断
3 给出至少 2 种技术路径（如 exec 黑白名单、只读挂载、关闭 WebDAV 对外开放），写明复杂度、工期和副作用 技术评估人、基础设施/安全 定级后 3 个工作日内 风险评估单、技术方案文档 方案对比 🤖自动化（AI 生成方案对比初稿）+👤人工判断
4 法务评审：判断是否需要合同免责、风险提示文案、协议更新、重新同意 法务 方案提交后 2 个工作日内 风险评估单、合同模板 法务意见、条款修改建议 👤人工判断
5 召开 30 分钟准入评审或线上审批，出结论：准入/有条件准入（开发者模式、风险提示、仅内部可用）/不准入 产品负责人；高风险由终审拍板 法务意见出具后 1 个工作日内 飞书审批 准入决策记录 🔧飞书固化
6 落地：统一风险提示组件、功能开关、协议版本号与生效日期、用户同意记录 实现人 按迭代排期，高风险项不得晚于功能上线 代码仓库、配置后台 已合并的 PR、配置项 🤖+👤
7 上线前复核：对照评估单逐项检查提示、开关、协议链接是否生效 产品负责人、测试 发版前 1 个工作日内 发版检查清单 复核记录 🔧飞书固化
8 归档评估单；对客户书面答复能做/不能做/替代方案，同步给合同经办人 产品负责人、销售/交付对接人 上线或决策后 2 个工作日内 多维表格、客户群 对客答复、归档记录 👤人工判断

5. 交付物与模板

  • 交付物：风险评估单、准入决策记录、风险提示组件与开关、协议版本台账、对客承诺边界说明
  • 建议模板/表单：
    • 风险评估单：编号、来源（内部/客户A）、功能描述、风险类型、风险等级、影响版本与客户、技术路径对比（路径/复杂度/工期/副作用）、法务意见、合同条款调整、结论、决策人、生效版本、复核日期
    • 协议版本台账：版本号、更新日期、生效日期、变更摘要、法务审批记录、适用产品（企业版/个人版）、是否需重新同意、发布位置

6. 异常与升级

  • 功能已上线才发现风险 → 先加风险提示或关闭入口，补评估单 → 当天升级给终审，决定是否发 hotfix
  • 客户安全要求技术上无法完全满足 → 给替代方案和书面承诺边界，不口头答应 → 2 个工作日内升级给终审
  • 产品与法务意见冲突 → 暂停上线 → 1 个工作日内升级给终审
  • 协议文本需更新但法务暂缺 → 先冻结文本变更 → 升级给综合部负责人协调外部法务
  • A（升级）说明：风险分级与准入结论由产品负责人（产品总监）最终负责；评定为高风险的项、产品与法务意见冲突、功能已上线才发现风险、客户安全要求无法完全满足时，拍板权升级到终审（创始人兼 CTO）

7. 衡量指标

  • 上线前评估覆盖率 = 上线前完成评估单的风险功能数 ÷ 风险功能总数，目标 100%
  • 事后补救次数 = 上线后才补风险提示或紧急 hotfix 的次数，目标每季度 0 次
  • 客户安全需求答复周期 = 登记到书面答复的工作日，目标 ≤ 7 个工作日
  • 协议版本留痕率 = 有版本号、生效日期和法务审批的协议变更数 ÷ 协议变更总数，目标 100%

8. 低效诊断

  • 现象：风险功能先上线后补提示，开发者模式与风险提示是事后加的，随后紧急 hotfix；根因是开发前缺少安全/法务评审节点｜依据：「Leap产研测」2026-09
  • 现象：客户安全要求在群内转述，技术方案从多种机制来回讨论，最后退回“先做黑白名单”；根因是没有需求单和评估模板，评估顺序不清｜依据：「LeapCore（archived）」2026-04
  • 现象：协议更新是否需要重新同意由产品直接决定，跳转外部文档的合规风险是事后才有人指出；根因是协议变更没有法务审批和版本记录｜依据：「Leap产研测」2026-07

9. 分支变体

  • 本机插件/开发者模式：默认关闭，开启前展示风险提示，合同写明风险自担条款
  • 客户 IT 安全要求：命令黑白名单、只读挂载、防批量导出（关闭 API/WebDAV 对用户开放，仅内部服务使用）、操作审计；对客承诺以书面答复为准
  • 用户协议/隐私政策：企业版与个人版内容应区分；协议由公司维护，不交给企业客户修改；更新时按版本判断是否重新同意
  • Skill 市场上架的脚本安全审核 → 归 X-PRD-20

10. 待确认问题

  • 主责放在产品总监还是另设安全合规专员？法务是否必须参与每一项评估？
  • 风险分级标准是否可以采用“涉及代码执行/数据外流/个人信息/合同承诺任一项即为高风险”？
  • 协议更新后是否必须让存量用户重新同意？登录页跳转飞书文档是否符合 EULA 要求？
  • 客户安全需求的书面答复由产品出还是由销售出？
  • 步骤时限（技术评估 3 个工作日、法务 2 个工作日）是否可行？
X-PRD-18模型选型、档位配置与评测待优化192

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：出现新模型或新渠道、现有模型不稳定、上游成本或折扣变化、客户反馈体验问题时，评估并决定用户可选模型上下架、经济/标准/专家档位背后的模型与思考强度、企业版开放的模型和 Skill 范围
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、测试与评测负责人（当前：张东郅·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、NewAPI 配置（当前：张康·推断待确认）、客户端/Skill Store（当前：李铭熙·推断待确认）、后端（当前：杨云峰·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提出候选模型/调整 → ② 接入测试服并配成本 → ③ 跑评测集与试用 → ④ 输出评测结论 → ⑤ 决策档位映射与上下架 → ⑥ 测试环境验证后生产切换 → ⑦ 更新档位方案一页纸并通知 → ⑧ 上线后观察与回退
  • 交付结果：评测报告、当前档位方案一页纸（档位/模型/渠道/思考强度/倍率/生效日期）、生产配置变更记录、对客档位说明口径、企业版模型与 Skill 开放清单
  • 状态依据：已有测试服先切、评测 skill、LEAP 工单、群内“最新决策”同步等固定做法，但决策在群里多次变化（经济是否切、标准是否开 high），切换后又回退，有人明确表示“不知道现在的模型方案”；评测靠个人自编题，没有统一评测集和负责人

1. 场景判定

  • 触发条件：新模型发布或新渠道报价；现有模型出现工具调用异常、无视觉能力、速度慢等问题；上游降价/折扣/自部署方案出现；客户反馈某档位“变蠢”；演示前需要临时换模型；企业版交付前要定可见模型与 Skill
  • 典型说法：「只设三档：快速/标准/专业，不暴露模型型号」「标准切 high，经济不切了」「加入测试版豪华套餐」「现在给用户的模型清单发我一下，下架一点模型」「这个是内部模型，不应该可选」
  • 判断问题：这次变化会不会改变用户可选的模型、某个档位实际调用的模型或思考强度？会，就走本流程
  • 不归本流程管：模型售价和倍率调整 → 请走 X-PRD-22；新渠道 API 的技术接入与连通验证 → 请走 RND-67；路由与渠道切换的技术操作 → 请走 RND-71；上游故障临时降级 → 请走 RND-72；Agent 评测体系的技术建设 → 请走 RND-82

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
提出人 提出候选模型或调整需求，建工单写明触发原因 R 提出方（产品/研发/评测/售后）
方案负责人 维护档位方案一页纸，组织评测与决策，管理上下架清单 R 产品总监（当前：杨萌·推断待确认）
决策人 批准档位映射、上下架、专家档定位 A 创始人兼 CTO（当前：丁震宇·推断待确认）
接入与配置 接入候选模型、配成本、执行测试服和生产切换 R 模型网关与计费研发（当前：柯逸飞·推断待确认）、NewAPI 配置（当前：张康·推断待确认）
评测负责人 维护评测集，跑分，组织试用，出评测报告 R 测试与评测负责人（当前：张东郅·推断待确认）
路由与 Agent 参数 档位路由、标签切模型、思考开关等参数 C Leap 研发负责人（当前：王皓南·推断待确认）、后端（当前：杨云峰·推断待确认）
企业版范围 企业管理员可见模型、默认 Skill 配置 C 客户端/Skill Store（当前：李铭熙·推断待确认）
销售/客服 按统一口径向客户解释档位 I 销售与客户对接人（当前：待指定）

3. 办之前请准备

  • 候选模型信息：渠道、单价、上下文长度、是否支持工具调用与视觉、合规属性（境内/海外）
  • 当前档位方案一页纸与生产配置截图
  • 评测集（public/private 题库）和上一次评测得分
  • 触发原因的证据：客户反馈、错误日志、成本变化
  • 涉及的产品线与版本：C 端 LeapAll、B 端 LeapCore、演示版、定制客户版

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提出候选模型或调整需求，建 LEAP 工单，写明触发原因和期望档位 提出人 发现后 1 个工作日内 工单系统 模型变更工单 🔧飞书固化
2 接入测试服（测试版可放更多模型），配置成本价 接入与配置 工单创建后 2 个工作日内 NewAPI/v5 网关测试环境 测试服可用模型 👤人工判断
3 跑评测集（private 题库为主），组织不少于 3 人试用常见任务 评测负责人 接入后 3 个工作日内 评测 skill、多维表格题库 得分与试用反馈 🤖自动化
4 输出评测报告：效果、速度、稳定性、成本、合规，给出推荐档位 评测负责人、方案负责人 跑分后 1 个工作日内 评测报告模板 评测报告 🤖+👤
5 决策档位映射、上下架、是否进企业版；C 端只保留三档并隐藏型号 决策人 报告提交后 1 个工作日内 工单评论/飞书审批 决策记录 👤人工判断
6 测试环境复制配置并验证（含思考开关、内部模型不可选），再切生产；保留一键回退 接入与配置、路由与 Agent 参数 决策后 2 个工作日内 NewAPI、配置后台、hotfix 生产变更记录 🤖+👤
7 更新档位方案一页纸，在产研群和销售群发变更通知卡片 方案负责人 生产切换当天 飞书文档、群机器人 方案一页纸新版本、通知 🔧飞书固化
8 上线后 3 天观察报错率与用户反馈，异常则回退并重新评测 评测负责人、接入与配置 切换后 3 个自然日 监控看板、反馈群 观察结论 🤖自动化

5. 交付物与模板

  • 交付物：模型变更工单、评测报告、档位方案一页纸、生产变更记录、企业版开放清单
  • 建议模板/表单：
    • 评测报告：模型/渠道、评测集版本、各题得分、平均响应时长、失败率、单任务成本、合规说明、推荐档位、评测人、日期
    • 档位方案一页纸：档位名（经济/标准/专家）、对应模型、渠道、思考强度、倍率、适用任务、生效日期、上一版本、决策人
    • 企业版开放清单：模型分组（如领导/普通/实习组）、默认可见档位、默认 Skill、收费 Skill 是否上线、审核规则

6. 异常与升级

  • 切换后体验明显下降或报错率升高 → 一键回退上一版本 → 当天告知决策人
  • 内部模型或不应暴露的模型出现在用户选择列表 → 当天下架并补检查项 → 告知方案负责人
  • 演示前临时要换模型 → 只在演示版/测试服切换，不动生产 → 演示前 1 个工作日报决策人
  • 新能力（视频/生图）无负责人 → 方案负责人 1 个工作日内指定接口人 → 指定不了升级给兜底人

7. 衡量指标

  • 档位变更回退率 = 上线后回退的变更数 ÷ 档位变更总数，目标 ≤ 10%
  • 评测覆盖率 = 有评测报告的上线模型数 ÷ 上线模型总数，目标 100%
  • 方案同步时效 = 生产切换到一页纸更新的小时数，目标 ≤ 4 小时
  • 档位决策周期 = 工单创建到决策的工作日，目标 ≤ 7 个工作日

8. 低效诊断

  • 现象：档位决策在群里多次变化，切换后回退，部分成员不知道当前方案；根因是没有单一的档位方案文档和变更记录｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：模型好坏靠个人自编题和体感判断，每次新模型都各自出题；根因是缺统一的评测集和评测负责人｜依据：「模态AI探索小分队」2026-04、「Leap产研测」2026-05
  • 现象：不应暴露的内部模型出现在选择列表，“是否对用户暴露型号”前后说法不一；根因是上架前没有检查项，对客口径没有成文｜依据：「Leap产研测」2026-05、「leapcore市场对接」2026-04
  • 现象：B/C 端 Skill 池和企业可见模型到交付前一晚才定，现场演示后临时调整；根因是没有成文的 B 端能力清单｜依据：「LeapCore（archived）」2026-05
  • 现象：视频生成渠道接入时找不到负责人；根因是新能力类别没有接口人｜依据：「Leap产研测」2026-06

9. 分支变体

  • C 端 LeapAll：只设三档，不暴露型号，后台动态配置；测试版可提供更多模型用于评测
  • B 端 LeapCore：经济（低思考）、标准（high）、专家（高能力模型）；企业版先开放 3 个档位，其余禁用；后续按用户分组开放
  • 演示版：可使用演示专用快速模型，与生产隔离
  • 多模态：识图、生图、视频生成单独评测、单独设接口人
  • 对客档位说明：只讲价格、速度、效果和适合的任务，不说背后具体模型

10. 待确认问题

  • 档位方案负责人是产品总监还是模型网关研发？评测负责人是否固定为测试负责人？
  • 评测集是否分 public/private，private 题库由谁保管、多久更新一次？
  • 生产切换是否必须先在测试服跑满 2 个工作日？
  • 企业版用户分组开放模型的规则是否已定？
  • 海外模型的合规准入由谁判断？
X-PRD-19第三方能力与外部方案调研选型接入待新建240

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：产品需要接入外部 API、SaaS 或新能力（OCR、视频生成、企业信息查询、电子签、外呼、客户远程访问等）时，完成调研对比、成本与合规评估、选型决策，并交出接入清单与排期
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、接入研发（当前：魏宗浩·推断待确认）、后端/核价（当前：宋祺睿·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）、网关（当前：吴世豪·推断待确认）、总经办采购（当前：待指定）、市场商务对接（当前：待指定）、法务负责人（当前：李瑶·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提需求并写清场景 → ② 归类入接入清单 → ③ 调研 2～4 个方案 → ④ PoC 实测 → ⑤ 成本、定价与合规评估 → ⑥ 选型评审决策 → ⑦ 采购开户与凭据入库 → ⑧ 接入开发、计费配置与上线排期
  • 交付结果：选型对比表、PoC 结论、选型决策记录、第三方接入清单条目（类别、计费方、对接人、状态）、接口清单与计费 ID、采购/开户记录
  • 状态依据：企业信息接口清单多轮修改（5→6→9→7 个），倍率由谁定不清，CTO 明确要求“后续接任何此类接口都要有 SOP”；OCR 选型的价格、限额、效果只在聊天里，需求原因要反复追问；远程访问方案调研已做但未形成决策和排期；谁去和供应商谈、谁采购都要临时指定

1. 场景判定

  • 触发条件：产品规划要新增外部能力；客户场景需要处理海量文档或特殊数据；现有供应商效果、价格不满足；客户需要外网访问本地 LeapCore 服务器等基础能力
  • 典型说法：「我现在要排一个之后要接的三方和能力进来」「要有 SOP」「先出调研文档」「这个合作谁来谈」「什么需求？为什么要这么多内容去跑」
  • 判断问题：要解决的能力是不是必须依赖外部厂商（付费 API、SaaS、硬件方案）？是，就走本流程
  • 不归本流程管：大模型及渠道的选型与档位 → 请走 X-PRD-18；第三方服务的付费开通与充值 → 请走 FIN-02 / FIN-03；上游供应商的询价、折扣谈判与签约 → 请走 X-OTH-01；接入后的技术连通验证 → 请走 RND-67；客户现场网络与远程接入配置 → 请走 X-DLV-16；凭据保管 → 请走 X-SEC-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求方 写清场景、用量、预期效果，参与 PoC 验收 R 提出方（产品/研发/销售）
选型负责人 维护接入清单，组织调研、评审和排期 R 产品总监（当前：杨萌·推断待确认）
调研与接入研发 调研接口、做 PoC、封装端点与计费 ID R 接入研发（当前：魏宗浩·推断待确认）、IT 运维/基础设施（当前：杨明学·推断待确认）
技术评审 判断归属（开放平台/网关/skill）、架构与工期 C Leap 研发负责人（当前：王皓南·推断待确认）、网关（当前：吴世豪·推断待确认）
核价 核算成本、砍价、给出倍率建议 C 后端/核价（当前：宋祺睿·推断待确认）
采购与商务 签约、企业认证、法人材料、充值 R 总经办采购（当前：待指定）、市场商务对接（当前：待指定）
决策人 批准选型、预算和倍率 A 创始人兼 CTO（当前：丁震宇·推断待确认）
法务 数据合规、电子签/外呼等合规审查 C 法务负责人（当前：李瑶·推断待确认）

3. 办之前请准备

  • 需求说明：业务场景、预计调用量或页数、效果要求、谁来付费（公司/用户钱包/客户自有账号）
  • 已有的接入清单（飞书 wiki 第三方能力规划页）和历史调研结论
  • 候选厂商的公开价格页、接口文档、限额说明
  • 2～5 份真实样本（如扫描 PDF、手写件、表格）用于 PoC
  • 如需采购：主体、预算、法人材料清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交接入需求，写明场景、用量、付费方 需求方 需求出现后 2 个工作日内 多维表格（第三方接入清单） 需求条目 🔧飞书固化
2 归类：消息集成 / API 数据源 / 服务集成 / LeapCore 依赖，确定放开放平台、网关还是 skill 选型负责人、技术评审 提交后 2 个工作日内 接入清单 类别与归属 👤人工判断
3 调研 2～4 个方案，填选型对比表（价格、限额、效果、并发、合规、自研/外包） 调研与接入研发 归类后 5 个工作日内 选型对比表 调研文档 🤖自动化（AI 整理公开资料）
4 用真实样本做 PoC，按事先定好的验收标准打分 调研与接入研发、需求方 调研后 5 个工作日内 测试环境、试用账号 PoC 结论 👤人工判断
5 成本与定价评估：单价、预计月成本、倍率建议；合规评估 核价、法务 PoC 后 3 个工作日内 选型对比表 成本与合规结论 🤖+👤
6 选型评审：定厂商、接口范围（砍掉过贵或面议接口）、预算、排期 决策人主持 评估后 2 个工作日内 飞书审批/评审会 选型决策记录 🔧飞书固化
7 采购签约、企业认证、充值；凭据存入密钥管理，不发聊天 采购与商务 决策后 5 个工作日内 飞书采购审批、密钥管理 开户记录、凭据入库 🔧飞书固化
8 接入开发：专用端点、每个 endpoint 设计费 ID，排入迭代，更新接入清单状态 调研与接入研发 按迭代排期 网关、代码仓库 上线接口、计费配置 🔧+🤖

5. 交付物与模板

  • 交付物：接入清单条目、选型对比表、PoC 结论、选型决策记录、接口清单与计费 ID、采购开户记录
  • 建议模板/表单：
    • 第三方接入清单（多维表格）：能力名称、类别、需求方、场景、付费方、候选厂商、选定厂商、对接人、状态（调研/PoC/评审/采购/接入/上线/暂缓）、排期、决策日期
    • 选型对比表：厂商、方案、单价、计费单位、限额、效果得分、并发、合规说明、自研/外包、集成工期、推荐结论
    • 接口接入单：接口 ID、端点、单价、倍率、计费 ID、缓存策略、压测结果

6. 异常与升级

  • 调研完成超过 10 个工作日仍无决策 → 选型负责人在周会提出 → 升级给决策人限期拍板
  • PoC 效果不达标（如扫描件、手写识别差） → 给出“预处理+人工标注”等替代方案或暂缓 → 告知需求方
  • 谁去谈、谁采购不明确 → 默认采购由总经办执行，产品只提需求 → 1 个工作日内由兜底人指定
  • 凭据在聊天中出现 → 立即轮换并入库 → 按 X-SEC-11 处理

7. 衡量指标

  • 选型周期 = 需求提交到选型决策的工作日，目标 ≤ 15 个工作日
  • 调研转决策率 = 有决策结论的调研数 ÷ 完成调研数，目标 ≥ 90%
  • 接口清单返工次数 = 决策后接口范围变更次数，目标 ≤ 1 次
  • 凭据入库率 = 存入密钥管理的第三方凭据数 ÷ 全部第三方凭据数，目标 100%

8. 低效诊断

  • 现象：接口清单多轮增减，面议接口能不能用、倍率由谁定都要临时问；根因是没有接入模板和定价决策人｜依据：「Leap产研测」2026-08
  • 现象：选型的价格、页数限制、效果数据只在聊天里，核价时还要反复追问需求原因；根因是需求单没有写场景和用量｜依据：「Leap产研测」2026-09
  • 现象：远程访问方案调研已做，但在自研还是外包、工期估算上反复，迟迟没有排期；根因是调研后没有评审节点和验收标准｜依据：「忠橙星行星引擎」2026-07
  • 现象：和供应商谁来谈、谁提供法人材料不清，历史账号资料散落在转发消息里；根因是采购职责和凭据保管没有规定｜依据：「Leap产研决策部」2026-08、「鼎慧产研决策部」2026-10

9. 分支变体

  • API 数据源（如企业信息查询）：以“技能+API”形式提供，网关专用端点按 endpoint 单独计费，我们付费、向用户收费
  • 服务集成（电子签、在线文档）：用户使用自己的账号，我们不计费；电子签、外呼需法务合规审查
  • 新模型类能力（OCR、视频生成）：费用记到用户钱包，需先确认按页/按次的计费单位
  • 客户远程访问：软硬一体、纯软件、自建隧道三类，先买测试设备 PoC 再定
  • 采购：一律由总经办执行，产品只对接需求

10. 待确认问题

  • 选型负责人是产品总监，还是按能力类别分别指定？
  • 第三方 API 的倍率由谁批准？是否统一参考 X-PRD-22 的定价规则？
  • 选型评审是否需要财务参与预算确认？金额超过多少需要 CEO 审批？
  • 客户远程访问方案是否已有最终结论？
  • 时限（调研 5 个工作日、PoC 5 个工作日）是否可行？
X-PRD-20Skill 上架审核、开发者入驻与分润待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：客户、OPC 开发者或第三方申请在开放平台/Skill Store/OPC 平台上架 Skill 或应用，需要入驻审核、竞品准入判断、按次扣费配置和分润结算规则时启动
  • 负责人：主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill Store/客户端（当前：李铭熙·推断待确认）、商城研发（当前：邓乾·推断待确认）、网关研发（当前：岳阳、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、法务负责人（当前：李瑶·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 开发者入驻申请 → ② 资质与协议签署 → ③ 提交 Skill 与扣费声明 → ④ 自动预检 → ⑤ 人工审核（含竞品与安全） → ⑥ 上架与计费配置 → ⑦ 调用计量与分润结算 → ⑧ 更新/下架/注销处理
  • 交付结果：入驻记录与开发者协议、审核记录、上架的 Skill 商品（名称、描述、分类、价格、扣费规则）、调用量统计、分润结算单
  • 状态依据：已有《SKILL 开发者入驻规范》《付费 SKILL 流程与 API 规范》草稿和后台商品管理审核功能，但审核标准、更新/下架/注销规则仍是口头约定；商城、Skill Store、LeapCore 商店三套入口反复混淆；上架后发现非标准格式装不上；分润方案曾设计后被否、搁置；竞品界定和审核人分配靠临场判断

1. 场景判定

  • 触发条件：企业客户想自己上传 Skill 并下发给员工；OPC 开发者想上架付费 Skill；第三方应用申请上架 OPC 平台；需要决定开发者分成比例或调用计量方式
  • 典型说法：「开给客户让他们自己上传 skills 然后下发」「审核权限本来就应该捏在我们手里」「要有个 SKILL 平台入驻规范」「这个算我们竞品吗」「我们怎么给做 skill 的开发者分润」
  • 判断问题：上架的 Skill/应用是不是由公司以外的人（客户、开发者、第三方）提供，或涉及收费和分成？是，就走本流程
  • 不归本流程管：公司自研 Skill 是否内置、商店描述分类维护 → 请走 X-PRD-21；Skill 开发评审与内置发布的技术流程 → 请走 RND-56；OPC 商城实物商家入驻 → 请走 ECO-07；分润打款与开票 → 请走 FIN-23；开放平台业务归属口径 → 请走 ECO-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
开发者/申请方 提交资质、Skill 包、说明和扣费声明 R 企业客户、OPC 开发者、第三方
平台负责人 维护入驻规范与审核清单，执行审核，管理上下架 R/A 开放平台负责人（当前：郭逸非·推断待确认）
产品负责人 竞品准入判断、商店入口边界、上架节奏 R 产品总监（当前：杨萌·推断待确认）
商城与 Skill Store 研发 后台上架、审核流、批量导入、格式预检 R 商城研发（当前：邓乾·推断待确认）、Skill Store（当前：李铭熙·推断待确认）
网关与计量 统一网关 key、调用计量、按次扣费 C 网关研发（当前：岳阳、吴世豪·推断待确认）
测试 抽检安装、调用和扣费 C 测试负责人（当前：张东郅·推断待确认）
法务/财务 开发者协议、侵权判断、分成结算口径 C 法务负责人（当前：李瑶·推断待确认）、财务（当前：待指定）
规则决策 批准入驻规范、分润比例、平台服务费 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）；分润比例报 COO（当前：常元和·推断待确认）

3. 办之前请准备

  • 入驻主体资料：企业/OPC 主体信息、对公结算账户（第一阶段仅企业/OPC 可上架）
  • Skill 压缩包（符合标准 Skill 格式，大小不超过平台上限）、名称、描述、分类、适用岗位、版本号
  • 扣费声明：按次/按 token/按积分，单价，由平台扣费还是 Skill 背后平台自行扣费
  • 依赖的外部 API 与密钥使用方式（默认使用统一网关 key，用户自带 key 暂不支持）
  • 现行《SKILL 开发者入驻规范》《付费 SKILL 流程与 API 规范》

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交入驻申请（主体、联系人、结算方式） 开发者/申请方 — 飞书表单/开放平台 入驻申请 🔧飞书固化
2 资质审核，签署开发者协议 平台负责人、法务 申请后 3 个工作日内 飞书审批、电子签 入驻记录、协议 🔧飞书固化
3 上传 Skill 包、填写商品信息和扣费声明 开发者/申请方 — 开放平台/商城后台 待审商品 👤人工判断
4 自动预检：格式是否标准、包大小、脚本安全扫描、敏感信息、命名重复 商城与 Skill Store 研发 提交后即时 预检脚本/CI 预检报告 🤖自动化
5 人工审核：功能与描述一致、是否竞品、是否侵权（抓取第三方内容）、扣费是否合理；按规则分配审核人 平台负责人；竞品由产品负责人判断 预检通过后 3 个工作日内 后台商品管理审核 审核结论（通过/驳回附原因） 👤人工判断
6 上架：配置分类、价格、计费 ID，安装抽检 商城与 Skill Store 研发、测试 审核通过后 1 个工作日内 商城后台、网关 上架商品 🤖+👤
7 计量与分润：网关记录付费调用，按月出调用量和分润明细 网关与计量、财务 每月 5 日前 网关用量统计、看板 分润结算单 🤖自动化
8 更新、下架、注销：更新在原商品链接发布新版本；违规下架；开发者注销后按协议处理余额与分成 平台负责人 收到申请或发现违规后 2 个工作日内 商城后台 变更记录 👤人工判断

5. 交付物与模板

  • 交付物：入驻记录、开发者协议、预检报告、审核记录、上架商品、月度调用量与分润结算单
  • 建议模板/表单：
    • 入驻申请表：主体名称、主体类型（企业/OPC/个人）、联系人、结算账户、计划上架内容、是否付费
    • 上架审核清单：格式合规、包大小、脚本扫描结果、描述与功能一致、分类正确、竞品冲突、第三方授权、扣费方式与单价、审核人、结论
    • 分润结算单：Skill、开发者、计费周期、调用次数、收入、平台服务费比例、应结金额、财务确认

6. 异常与升级

  • 上架后发现装不上或非标准格式 → 立即下架，通知开发者修改 → 补进预检规则
  • 发现违规、侵权或安全问题（如泄露密钥） → 当天下架并冻结结算 → 升级给规则决策人和法务
  • 竞品冲突无法判断 → 先按“与当前商品无冲突可上架”处理，标记复评 → 产品负责人 3 个工作日内给结论
  • 扣费纠纷 → 暂停该 Skill 计费 → 2 个工作日内升级给财务与平台负责人
  • A（升级）说明：入驻审核与上下架由平台负责人最终负责；入驻规范、平台服务费等规则的制定或变更，以及违规、侵权、安全事件的处置，拍板权升级到规则决策（创始人兼 CTO）；分润比例由创始人兼 CTO 审定后报 COO

7. 衡量指标

  • 审核周期 = 提交到上架/驳回的工作日，目标 ≤ 4 个工作日
  • 上架后问题率 = 上架后因格式/安全问题下架的数量 ÷ 上架总数，目标 ≤ 5%
  • 分润按时结算率 = 按期出结算单的月份数 ÷ 应结算月份数，目标 100%
  • 规则成文率 = 已成文并发布的规则项（入驻、审核、扣费、更新、下架、注销）÷ 6，目标 100%

8. 低效诊断

  • 现象：客户自传 Skill 由谁记调用次数、网关与计费层是什么关系反复问；根因是计量与扣费规则没有成文｜依据：「Leap产研测」2026-08
  • 现象：竞品界定靠临场判断，审核人随机还是自选没有规则；根因是缺上架准入标准和审核分配规则｜依据：「鼎慧产研决策部」2026-03
  • 现象：分润方案设计后被否，之后搁置，开发者生态规则至今没有；根因是规则决策没有时限和跟进人｜依据：「模态AI探索小分队」2026-07
  • 现象：入驻需求边界不清，研发“到底要做啥没搞懂”，多方技术栈争论；根因是规范只停留在口头定调｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：多套商店入口混淆，上架后发现部分 Skill 非标准格式装不上；根因是缺商店边界说明和自动预检｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04

9. 分支变体

  • 企业客户自有 Skill：平台保留审核权，审核后由企业管理员下发给本企业员工
  • OPC/C 端开发者：第一阶段仅企业/OPC 主体（对公结算）可上架；个人上架待分账渠道合规后开放
  • 平台扣费：开发者声明扣费规则，平台扣调用者 API 余额后结算分成
  • 第三方扣费：Skill 背后平台自行扣费，平台只管安装规范和审核
  • OPC 应用上架：与现有商品无冲突直接上；未来冲突时重新评估（封禁或调整排序）

10. 待确认问题

  • Skill 审核主责是开放平台负责人还是产品总监？两套规范文档的发布版本放在哪里？
  • 平台服务费比例、注销后余额“默认充公”是否已有书面决定？
  • 个人开发者上架的开放条件和时间？
  • 商城、Skill Store、LeapCore 商店三套入口的边界是否统一？
  • 是否可以抓取第三方公开 Skill 上架，需要法务给出结论
X-PRD-21内置技能评估与技能商店内容维护待优化108

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：公司自研的 Skill/插件新开发或更新后，评估是内置进客户端、由开放平台下发还是只上技能商店；以及技能商店里的描述、分类、版本维护，和开放平台下发技能/场景包/行业参数的接口契约对接
  • 负责人：主责——Skill 负责人（当前：李凯·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、Skill 开发（当前：邓乾、魏宗浩·推断待确认）、builtin 审查（当前：岳阳·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、客户端与 LeapAuth/Update（当前：宋祺睿、杨云峰·推断待确认）、Skill Store/私有 Hub（当前：李铭熙·推断待确认）、产品排期（当前：陈震·推断待确认）、测试（当前：潘浩伟·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 提交 Skill 及测试结果 → ② 安全与格式审查 → ③ 内置/下发/商店评审 → ④ 建工单排期 → ⑤ 填写商店内容并上架或内置 → ⑥ 发版验收 → ⑦ 商店内容日常维护 → ⑧ 下发接口契约变更同步
  • 交付结果：Skill 评审记录（结论为内置/开放平台下发/仅商店/不上线）、排期工单、上架或内置的 Skill（名称、描述、分类、版本、计费说明）、技能商店内容台账、下发接口契约文档
  • 状态依据：有私有 Hub 和使用文档、商店有人维护分类、接口方案文档和工单，但上架名称不审核、出现重复 Skill、内置遗漏要靠 hotfix 补；内置需求要群里催“速捞”；描述与分类不符、版本号不更新；接口字段反复改约 20 次；有成员直接说“现在 skills 没人管”

1. 场景判定

  • 触发条件：
    • 自研 Skill/插件开发完成或更新（如 word、OCR、企业信息查询、招投标爬虫）
    • 插件依赖某个 Skill，需要它内置
    • 用户或客户反馈商店里的描述不清、分类错误、版本不一致、重复安装
    • LeapCore/LeapLite 需要从开放平台拉取技能、场景包、行业版 logo/产品名，字段要统一
  • 典型说法：「word skills 更新了，可以考虑内置」「OCR 忘记改内置 skill 了」「你的 builtin 格式不对，请参考现有 skills 写法」「后续分类问题可以在这条消息下回复」「场景包、标题、logo、skill 这些东西，你们讨论好怎么定义，别一个人写一份」「现在谁管 skills」
  • 判断问题：这个 Skill 是不是公司自己（或公司 Skill 小组）出的，要决定放哪里、怎么展示？是，走本流程；如果是外部开发者或客户上架，走 X-PRD-20
  • 不归本流程管：外部开发者入驻、付费 Skill 分润 → 请走 X-PRD-20；Skill 开发编码与发版技术流程 → 请走 RND-56；外部伙伴把 Skill/插件接入开放平台 → 请走 ECO-06；技能命名与对外文案规范 → 请走 X-PRD-15；正式版本发布 → 请走 RND-51

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Skill 负责人 维护 Skill 清单与商店内容台账，组织评审 R Skill 负责人（当前：李凯·推断待确认）
Skill 开发者 提交 Skill、自测、按 builtin 格式整改 R Skill 开发（当前：邓乾、魏宗浩·推断待确认）
格式与安全审查 审查 builtin 格式、脚本安全、密钥暴露 R builtin 审查（当前：岳阳·推断待确认）
产品决策 决定内置/下发/仅商店，及上线节奏 A 产品总监（当前：杨萌·推断待确认）
开放平台 下发配置、接口契约 owner R 开放平台负责人（当前：郭逸非·推断待确认）
客户端与更新服务 对接下发接口，带上内置变化 C 客户端与 LeapAuth/Update（当前：宋祺睿、杨云峰·推断待确认）
排期 捞工单、分配研发 R 产品排期（当前：陈震·推断待确认）
测试 验收安装、下发和展示 C 测试（当前：潘浩伟·推断待确认）

3. 办之前请准备

  • Skill 包与自测记录（典型任务 3 条以上）
  • 依赖说明：是否调用付费 API（会扣用户 LeapCore 钱包）、是否依赖插件、是否需要网络
  • 商店信息：名称、一句话描述、详细说明、分类、适用岗位、图标、版本号（递增纯数字或语义版本）
  • 现有同类 Skill 列表，避免重复上架
  • 涉及接口变更的：当前契约文档链接与变更字段清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交 Skill 评审申请，附自测结果和商店信息 Skill 开发者 开发/更新完成后 1 个工作日内 多维表格（Skill 台账） 评审申请 🔧飞书固化
2 格式与安全审查：builtin 格式、脚本扫描、密钥与敏感信息、包大小（不超过 50 MiB） 格式与安全审查 申请后 2 个工作日内 CI 校验、扫描脚本 审查结论 🤖自动化
3 评审放置方式：内置 / 开放平台默认下发 / 仅商店 / 不上线；查重 产品决策、Skill 负责人 审查通过后 2 个工作日内 评审会或工单评论 评审记录 👤人工判断
4 需研发配合的（内置、下发配置）建工单并排入迭代 排期 评审后 1 个工作日内 工单系统 排期工单 🔧飞书固化
5 上架或内置：按台账信息填写名称、描述、分类、版本；内置随版本或 hotfix 发出 Skill 开发者、开放平台 按迭代排期 开放平台、客户端仓库 上线 Skill 🔧+🤖
6 发版验收：测试服与生产服分别验证安装、展示、扣费说明，确认与标品一致 测试 发版前 1 个工作日内 测试环境 验收记录 👤人工判断
7 商店内容维护：汇总反馈，修正描述、分类、版本，每两周巡检一次 Skill 负责人 反馈后 3 个工作日内；每两周巡检 技能商店后台、反馈群 更新后的台账 🔧+👤
8 下发接口契约变更：在单一契约文档更新字段，指定定义负责人，同步客户端与测试 开放平台、客户端与更新服务 契约变更当天 飞书 wiki/OpenAPI 文档 契约新版本、变更通知 🔧+🤖

5. 交付物与模板

  • 交付物：Skill 评审记录、排期工单、Skill 台账、上线 Skill、下发接口契约文档
  • 建议模板/表单：
    • Skill 台账（多维表格）：Skill 名称、负责人、类型（官方/个人/企业）、放置方式、分类、适用岗位、描述、版本号、是否扣费、依赖插件、上线环境（测试/生产）、状态、最近巡检日期
    • 接口契约变更单：接口名、变更字段（id/slug/name/display_name 等）、旧值/新值、影响端（客户端/开放平台/测试）、生效版本、定义负责人

6. 异常与升级

  • 内置遗漏或上架错误（重复、命名暴露内部信息） → 当天下架或在 hotfix 中补 → 告知产品决策人
  • 内置需求排期超过 5 个工作日未捞 → Skill 负责人在站会提出 → 升级给兜底人
  • 下发接口字段不一致导致客户端异常 → 冻结契约变更，回到单一文档对齐 → 1 个工作日内升级给开放平台负责人与兜底人
  • Skill 发现安全问题（如暴露密钥） → 立即下架并轮换密钥 → 按 X-SEC-11 处理

7. 衡量指标

  • 上架问题率 = 上线后因重复、格式、命名问题返工的 Skill 数 ÷ 上线 Skill 数，目标 ≤ 5%
  • 内置排期周期 = 评审通过到进入迭代的工作日，目标 ≤ 5 个工作日
  • 商店内容准确率 = 巡检中描述、分类、版本正确的 Skill 数 ÷ 抽检数，目标 ≥ 95%
  • 契约变更返工次数 = 联调中因字段理解不一致返工的次数，目标每个需求 ≤ 1 次

8. 低效诊断

  • 现象：上架名称不审核、出现两个同类 Skill、内置遗漏只能 hotfix 补；根因是没有上架查重和发版检查清单｜依据：「Leap产研测」2026-09
  • 现象：内置需求测试通过后，要靠群里催“速捞”才进排期；根因是评审结论不自动生成工单｜依据：「Leap产研测」2026-09
  • 现象：描述与分类不符、版本号一直不变、上传大小限制没有文档；根因是缺商店内容规范与定期巡检｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-10
  • 现象：下发接口字段反复改，测试仍用旧字段验收，一人写一份定义；根因是契约没有单一事实来源和变更通知｜依据：「Leap产研测」2026-07
  • 现象：Skill 没有 owner，开放平台换负责人就要重做，Skill 范围与内嵌优先级反复；根因是 Skill 管理职责未划分｜依据：「Leap产研决策部」2026-10、「LeapCore（archived）」2026-03

9. 分支变体

  • 内置 Skill：在 agent 内置或开放平台默认下发，需符合 builtin 格式，随版本发出
  • 开放平台下发：标品与客户定制版下发内容需比对一致
  • 私有 Hub：C 端/OPC 版走 Skill Store，B 端经集中网关，并标“是否内购”
  • 客户定制 Skill：由 Skill 小组承接，只在该客户侧上线
  • 开放平台职责边界：需改 LeapCore 的部分由 LeapCore 管且必须知情，纯对外部分（风控、验证码等）由开放平台自管

10. 待确认问题

  • Skill 负责人是否正式指定为 Skill 小组负责人？Skill 小组成员与职责是否成文？
  • 是否同意由研发做一层“Skill 插件管理”，开放平台作为上游之一？
  • 内置技能的分类是否继续统一为“其他”，还是按部门分类？
  • 版本号统一采用递增纯数字还是语义版本？
  • 插件规范是否公开给公司内部同事，由谁维护？
X-PRD-22模型/API 售价、倍率调整与对外价格表同步待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：上游模型成本、汇率、折扣变化，或新模型/新能力（视频、OCR、企业信息查询）上线，或平台首次上线需要定价时，测算毛利、确定倍率与档位售价、配置网关计费，并同步对外价格表与模型清单
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——模型网关与计费研发（当前：柯逸飞·推断待确认）、v5 后端与发布（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、AIAPI 渠道维护（当前：杨明学、吴世豪·推断待确认）、NewAPI 配置（当前：邓乾·推断待确认）、测试负责人（当前：张东郅·推断待确认）、财务（当前：待指定）；定价批准——COO（当前：常元和·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别价格变动 → ② 更新成本价 → ③ 测算毛利与建议售价 → ④ 定价审批 → ⑤ 提 PR 改网关价格并补测试 → ⑥ 测试环境验证后发布 → ⑦ 同步对外价格表与模型清单 → ⑧ 通知销售与财务对账
  • 交付结果：价格主表新版本（成本价、倍率、售价、生效时间）、定价审批记录、合并发布的计费配置、对外价格表与模型清单、价格变更通知
  • 状态依据：已有网关渠道价格表（被称为“唯一事实来源”）、对外价格表、AIAPI 价格表和默认倍率口径，但对外表没人按时更新，被催“表更新了吗”约 8 次，最后只能拿旧表公示；倍率、毛利率、官渠价三种口径混用；价格表在个人手里，计费逻辑反复改；改价格不改测试，客户看到了不该看到的模型

1. 场景判定

  • 触发条件：上游渠道调价、折扣变化、汇率月度变化；新模型或新能力上线；供应商切换或签新定价合同；平台首次上线需定模型价格与计费最小单位；对外价格表与实际扣费不一致
  • 典型说法：「v5 价格修正」「云端只设置价格，不用倍率」「API 定价口径一定要统一，不用到处问」「表格麻烦更新下，包括接的模型」「毛利率不等于倍率」「现在大模型价格从谁那看」
  • 判断问题：这次变化会不会改变用户调用某个模型/API 时被扣的钱，或对外展示的价格？会，就走本流程
  • 不归本流程管：产品套餐、积分/额度单价与赠送规则 → 请走 X-PRD-23；模型档位映射与上下架 → 请走 X-PRD-18；财务侧成本价维护与成本收入核对 → 请走 FIN-28；计费准确性测试与对账 → 请走 RND-70；扣费异常核查与退补 → 请走 FIN-29 / X-CS-09；整体价格体系与对客报价 → 请走 SAL-18 / SAL-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
价格表负责人 维护价格主表与对外视图，发起定价审批，发通知 R 产品总监（当前：杨萌·推断待确认）
成本与配置 更新成本价、汇率，提价格 PR，配网关 R 模型网关与计费研发（当前：柯逸飞·推断待确认）、NewAPI 配置（当前：邓乾·推断待确认）
渠道价格 维护 AIAPI 渠道成本表 R AIAPI 渠道维护（当前：杨明学、吴世豪·推断待确认）
计费逻辑评审 计费规则、预扣费、cloud/edge 计价、PR 评审与发布 C Leap 研发负责人（当前：王皓南·推断待确认）、v5 后端与发布（当前：宋祺睿·推断待确认）
定价批准 批准倍率、售价和折扣 A COO（当前：常元和·推断待确认）
测试 验证扣费金额、最小计费单位、模型可见性 C 测试负责人（当前：张东郅·推断待确认）
财务 毛利复核、对账影响确认 C 财务（当前：待指定）
销售/客服 使用新版对外价格表 I 销售与客户对接人（当前：待指定）

3. 办之前请准备

  • 上游价格来源：渠道报价、官方价格页、合同或折扣通知、汇率来源
  • 价格主表当前版本（含成本价、倍率、售价、生效时间）
  • 受影响的模型/接口清单与产品线（LeapCore/LeapAll/AIAPI/对外 API）
  • 当前对外价格表与模型清单
  • 本月是否有客户账单在测试环境产生、是否影响对账

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别价格变动：渠道调价、折扣、汇率（每月第 1 个工作日更新） 成本与配置、渠道价格 变动发生后 1 个工作日内 价格主表、监控脚本 变动记录 🤖自动化
2 更新价格主表的成本价与生效时间 成本与配置 识别后 1 个工作日内 多维表格（价格主表） 成本价更新 🔧飞书固化
3 测算：按统一口径算毛利和建议售价（区分倍率与毛利率），给出调价/不调价建议 价格表负责人、计费逻辑评审 成本更新后 2 个工作日内 价格主表公式 测算结果 🤖自动化
4 定价审批：成本、建议倍率/售价、生效日期、对账影响 定价批准 提交后 2 个工作日内 飞书审批 审批记录 🔧飞书固化
5 提价格 PR：网关价格、预扣费、最小计费单位；同步修改测试用例 成本与配置 审批后 1 个工作日内 v5 仓库、NewAPI PR 🤖自动化
6 评审合并，测试环境验证扣费金额与模型可见性，再发布（必要时 hotfix） 计费逻辑评审、测试 PR 提交后 2 个工作日内 测试环境、发布系统 已发布配置、测试记录 👤人工判断
7 同步对外价格表与模型清单（自动生成倍率后价、上下文档位、缓存读写价） 价格表负责人 发布当天 多维表格对外视图、官网/文档 对外价格表新版本 🔧+🤖
8 发变更通知卡片给销售、客服、财务；说明生效时间和对账注意事项 价格表负责人 发布当天 群机器人 变更通知 🔧飞书固化

5. 交付物与模板

  • 交付物：价格主表新版本、定价审批记录、计费配置 PR、测试记录、对外价格表、变更通知
  • 建议模板/表单：
    • 价格主表（多维表格，单一事实来源）：模型/接口、渠道、产品线、计费单位、成本价、汇率、倍率、售价、毛利率（自动算）、上下文档位、缓存读/写价、生效时间、审批编号、维护人
    • 对外视图：从主表自动生成，隐藏成本列
    • 定价审批单：调整原因、涉及模型、原售价、新售价、毛利变化、生效日期、对账影响、申请人

6. 异常与升级

  • 扣费异常（金额过高、四舍五入错误、最小单位导致价格失真） → 当天回退配置 → 升级给计费逻辑评审，按 FIN-29 处理退补
  • 客户看到不应可见的模型 → 当天下架 → 告知价格表负责人补检查项
  • 上游涨价导致毛利为负 → 先暂停该模型对外售卖或切换渠道 → 1 个工作日内升级给定价批准人
  • 对外价格表与实际扣费不一致 → 以审批后的价格主表为准，当天修正对外表 → 告知销售

7. 衡量指标

  • 对外价格表同步时效 = 计费配置发布到对外表更新的小时数，目标 ≤ 24 小时
  • 价格变更审批覆盖率 = 有审批记录的价格变更数 ÷ 价格变更总数，目标 100%
  • 计费配置回退次数 = 因价格配置错误回退的次数，目标每月 0 次
  • 价格表催办次数 = 群内追问“价格表是否最新”的次数，目标每月 0 次

8. 低效诊断

  • 现象：对外价格表没有更新责任人，多次被追问后仍滞后，最后用旧表公示；根因是价格变更后没有触发对外表更新的机制｜依据：「AI API」2026-08
  • 现象：价格从谁那里看、系数是否调整都要在群里问；根因是价格表分散在个人手中，没有单一数据源｜依据：「鼎慧产研决策部」2026-06、「鼎慧产研决策部」2026-08
  • 现象：倍率、毛利率、官渠价三种口径混用，调价讨论没有依据，最后“先不动”；根因是缺书面定价规则和调价触发阈值｜依据：「AI API」2026-09、「AI API」2026-10
  • 现象：计费逻辑一周内多次修改，改价格不改测试，测试因实例欠费失败；根因是计费变更没有走测试用例和评审｜依据：「Leap产研测」2026-08、「Leap产研测」2026-09
  • 现象：平台上线前折扣方案多变，计费最小单位导致价格失真；根因是上线前没有定价评审和价格测试｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04

9. 分支变体

  • v5 网关：cloud 只设售价不设倍率，edge 直接用 cloud 价格；余额挂在实例上，后台调余额只能加减不能改记录，并留审计日志
  • 能力类型：LLM（含汇率月更）、视频（按分辨率/时长）、OCR（按页）、企业信息查询（按 endpoint）
  • 产品线：LeapCore 套餐内 API 可含软件增值；单独卖 API 不得高于市场价，否则不卖
  • 客户专属价：走 SAL-19 报价审批，不改通用价格主表

10. 待确认问题

  • 定价最终批准人是 COO 还是 CTO？倍率是否有默认值（如 ×1.6）可以免审批？
  • 价格主表由谁维护：网关研发还是产品？对外视图由谁发布？
  • 调价触发阈值（如成本变动超过 10%）是否可行？
  • 汇率是否按月第 1 个工作日统一更新？
  • 账单与对账影响由财务还是后端负责评估？
X-PRD-23产品套餐、积分/额度定价与计费规则待新建300

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：产品商业化、公测、新增付费档位（如 Pro/高画质）、上线充值、邀请奖励、注册赠送或额度包时，完成成本测算，确定积分/词元/额度单价、套餐与赠送规则、计费口径，并落到开发与验收
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、后端/扣费实现（当前：宋祺睿、邓乾·推断待确认）、LeapPPT 研发（当前：马漳毓、黄振锋·推断待确认）、运营方案（当前：李凯·推断待确认）、产品经理（当前：杨黔昆、黄飞鹏·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 立项定价需求 → ② 真实场景成本测算 → ③ 拟定价与激励方案 → ④ 定价评审拍板 → ⑤ 出计费口径单 → ⑥ 开发实现并引用口径单 → ⑦ 口径对账与上线检查 → ⑧ 发布说明与上线后监控
  • 交付结果：成本测算表、定价决策记录、计费口径单（售价、成本、毛利、换算比例、赠送、并发限制）、已上线的套餐/额度包配置、对用户的计费说明
  • 状态依据：计费口径开会讲过、文档有，研发仍按自己理解实现（把词元当 token 1:1 扣），事后纠偏改代码；额度包未上架导致注册不送词元；“次/词元/点数/额度”叫法不统一，数量级反复对数；支付打通后无人配套餐；研发等产品定数值，被问“这个决策卡谁那了”；每次定价都现算，没有测算模板

1. 场景判定

  • 触发条件：产品准备公测或商业化；新增付费档位；上线充值、邀请奖励、注册赠送、学生包、订阅；计费方式变更（按次→按 token/词元）；市场或合作方询问“充一笔[金额已隐去]能用多久”、License 怎么收
  • 典型说法：「PPT 的定价似乎也没人做」「词元是我们定义的概念，不是 token」「不要额度了，只有 token」「我们只要定利润率多少就行了」「记住用钱定价」「你都生成十张，列一下平均成本」
  • 判断问题：要定的是用户购买和消耗的单位（积分、词元、额度、套餐）及其换算规则吗？是，走本流程；如果只是某个模型/API 的单价或倍率，走 X-PRD-22
  • 不归本流程管：模型/API 售价与倍率 → 请走 X-PRD-22；整体价格体系与对客报价 → 请走 SAL-18 / SAL-19；客户充值到账与额度开通 → 请走 FIN-17 / X-CS-03；计费余额异常与退款 → 请走 X-CS-09；B 端硬件与 License 合同价 → 请走 X-PRD-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
定价负责人 发起定价、组织测算与评审、维护计费口径单 R 产品总监（当前：杨萌·推断待确认）
成本测算 用真实场景测单次成本，提供 token 用量与渠道价 R LeapPPT 研发（当前：马漳毓·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）
运营激励方案 设计积分制、邀请奖励、注册赠送 R 运营方案（当前：李凯·推断待确认）
定价拍板 批准售价、毛利目标、赠送额度 A 创始人兼 CTO（当前：丁震宇·推断待确认）
开发实现 按口径单实现扣费、额度包、并发限制 R 后端/扣费实现（当前：宋祺睿、邓乾·推断待确认）、LeapPPT 研发（当前：黄振锋·推断待确认）
产品经理 需求梳理、用户可见文案、后台配置 C 产品经理（当前：杨黔昆、黄飞鹏·推断待确认）
测试 口径对账、极端值测试、额度包上架检查 R 测试（当前：张东郅、李国庆·推断待确认）
财务 毛利复核、充值与赠送对账口径 C 财务（当前：待指定）

3. 办之前请准备

  • 产品形态与计费对象：按页/按篇/按张/按人日，普通版与专家版的底层模型差异
  • 真实场景测算样本：每档至少 10 次（文生图与图生图、2K 分辨率、真实 Prompt 长度）
  • 渠道成本价（引用 X-PRD-22 价格主表，不另找个人表格）
  • 竞品与参考定价资料（如公司已有的 AI 产品定价参考）
  • 现行计费方案文档、额度包配置、历史赠送规则

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：写明产品、计费对象、上线日期、需定的数值清单（单价、赠送、套餐、并发） 定价负责人 上线前不少于 15 个工作日 飞书文档/工单 定价需求单 🔧飞书固化
2 成本测算：按真实场景各档跑 10 次以上，算平均成本 成本测算 立项后 3 个工作日内 测算脚本、网关用量 成本测算表 🤖自动化
3 拟方案：用人民币定价、积分/词元做运营单位；给出售价、毛利、换算比例、赠送与激励、学生包 定价负责人、运营激励方案 测算后 2 个工作日内 测算表 定价方案（含敏感性分析） 🤖+👤
4 定价评审：拍板全部数值，未定项写明截止日，不留口头结论 定价拍板 方案提交后 2 个工作日内 飞书审批/评审会 定价决策记录 👤人工判断
5 出计费口径单：统一术语与单位（如 m=百万），写清扣费公式与示例 定价负责人、产品经理 决策后 1 个工作日内 飞书文档（单一事实来源） 计费口径单 🔧飞书固化
6 开发实现：PR 必须引用口径单版本；先合测试环境 开发实现 按迭代排期 Gitea、测试环境 PR、测试环境配置 🤖+👤
7 口径对账：用一次真实任务核对扣量；测极端值；检查额度包/套餐已上架、注册赠送生效 测试 上线前 2 个工作日内 测试用例、后台 对账记录、上线检查单 🤖自动化
8 发布用户可见的计费说明；上线后 7 天监控日消耗、毛利和用户反馈 定价负责人、财务 上线当天起 7 个自然日 产品内说明、成本监控机器人 计费说明、监控报告 🤖自动化

5. 交付物与模板

  • 交付物：定价需求单、成本测算表、定价决策记录、计费口径单、上线检查单、上线后监控报告
  • 建议模板/表单：
    • 成本测算表：产品、档位、场景、样本数、平均 token、渠道单价、平均成本、测算人、日期
    • 计费口径单：版本号、术语表（积分/词元/额度/点数）、人民币与运营单位换算、每档售价与消耗、成本、毛利率、赠送规则（注册/邀请/学生包）、额度优先级（企业池/个人）、并发限制、生效日期、决策人
    • 上线检查单：额度包已上架、赠送生效、扣量与口径一致、产品内说明一致、极端值通过

6. 异常与升级

  • 发现实现与口径不一致 → 暂停上线或关闭支付入口 → 当天升级给定价负责人与 Leap 研发负责人
  • 定价数值到上线前 5 个工作日仍未定 → 定价负责人提交拍板 → 升级给兜底人，未定项先用占位并隐藏入口
  • 上线后成本倒挂或用户误以为涨价 → 发说明或临时调整 → 1 个工作日内重新评审
  • 第三方请求意外路由导致扣费 → 当天止损并核查 → 按 X-CS-09 退补

7. 衡量指标

  • 口径一致率 = 上线前对账一次通过的计费规则数 ÷ 计费规则总数，目标 100%
  • 定价决策周期 = 立项到拍板的工作日，目标 ≤ 7 个工作日
  • 计费返工次数 = 因口径误解返工的 PR 数，目标每个产品 ≤ 1 次
  • 毛利达标率 = 上线后 30 天实际毛利率达到目标的产品数 ÷ 上线产品数，目标 100%

8. 低效诊断

  • 现象：口径开会讲过、文档有，研发仍按自己理解实现，事后当场重讲再改代码；根因是 PR 不需要引用口径单，上线前没有口径对账｜依据：「鼎慧产研决策部」2026-04
  • 现象：同一个“充一笔[金额已隐去]能用多久”的问题被反复追问，每次现算；根因是没有产品-成本-毛利-额度对照表｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：支付打通后没人配套餐，研发等产品定数值；根因是定价没有主责和截止日｜依据：「鼎慧产研决策部」2026-05、「LeapPPT」2026-05
  • 现象：额度包未上架导致注册不送，数量级 40w/40m 反复对数，叫法不统一；根因是缺统一术语和上线检查清单｜依据：「工程咨询产研」2026-04
  • 现象：缓存计费到公测前才补，用户以为涨价是 bug；根因是计费规则与产品内说明不同步｜依据：「跃迁AI总动员」2026-05、「跃迁AI总动员」2026-06

9. 分支变体

  • LeapPPT：积分制，生成与修改按不同积分扣，Pro 档双倍；新用户赠送积分；后续可做订阅含积分包
  • 字字可研/工程咨询：以每篇报告为基准，按词元池计费；普通版与专家版底层模型和售价不同；企业额度池优先，用尽后用个人额度，一人只属一个组织；限制同时生成数量
  • LeapAll：模态币，按官方原价换算；内测期原价，公测后统一折扣
  • 新增档位（如高画质）：先测算后定积分，再全局开启
  • 对市场与合作方：市场不看成本，只给标准化方案和最低折扣；License 费与软件成本分开计算

10. 待确认问题

  • 定价拍板人是 CTO 还是 COO？毛利率底线是多少？
  • 积分、词元、额度、点数是否统一为一个对外术语？
  • 计费口径单放在哪个飞书空间，由谁维护版本？
  • 赠送额度（注册、邀请、客户试用）是否需要走审批，额度上限是多少？
  • 立项需在上线前 15 个工作日提出是否可行？
X-PRD-24硬件产品配置选型、成本评估与供应商问题反馈待优化180

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：出现新机型或供应商新报价、硬件配置要变更（CPU、RAID、新增屏幕或外壳开模）、客户询问能跑多大模型或硬件跑不动、渠道系统需要标准席位与增配规则，以及录音卡等硬件出现固件问题需要反馈工厂时启动
  • 负责人：主责——硬件负责人（当前：杨明学·推断待确认）；协同——产品总监（当前：杨萌·推断待确认）、供应商对接与成本核算（当前：闫登辉·推断待确认）、配置文档维护（当前：游家豪·推断待确认）、商务定价（当前：李鹏为、常元和·推断待确认）、模型规格评估（当前：望政韬·推断待确认）、后端（当前：杨云峰·推断待确认）、外包硬件对接人（当前：吕振·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记触发事项 → ② 技术方案与成本核算 → ③ 选型/变更评审 → ④ 商务拍板售价 → ⑤ 更新标准配置与席位 SKU 表 → ⑥ 发布对外口径、作废旧版 → ⑦ 有效期到期复核 → ⑧ 硬件问题反馈工厂并闭环
  • 交付结果：硬件选型/变更评审记录、标准配置表（带版本与有效期）、“型号×内存×硬盘→席位/并发/参考价”标准表、对外配置与价格口径、模型×硬件基线表、硬件问题清单与工厂反馈记录
  • 状态依据：已有硬件配置表、价格对照表和标准交付配置文档，但同一硬件成本被报出多个数字、对外售价“变了好几次”、对外资料盘位写错、交付知识库里旧版配置未作废；席位数前后变化多次，渠道 SKU 反复确认；配置变更时技术与市场互相推决策，要 CTO 点名才拍板；客户能跑多大模型每次现算

1. 场景判定

  • 触发条件：供应商报价或新机型；配置调整（CPU 升级、单盘+增量备份替代双盘、新增小屏、外壳开模）；渠道系统上线需要默认席位和增配规则；客户询问能否上更大模型或反映速度慢；录音卡等硬件出现时间错乱、断连、文件命名等问题
  • 典型说法：「到底啥是最新的，统一让对接人说一下」「再给一版 CPU 好一点的方案吧」「我需要一个标准表」「市场这块听商务的，技术给方案参考就行」「模型最大塞多少进去」「大概率是出厂默认固件的问题」
  • 判断问题：这件事会不会改变我们卖的标准硬件配置、席位、对外价格，或需要把硬件缺陷反馈给供应商？会，就走本流程
  • 不归本流程管：具体客户的硬件配置咨询与报价单 → 请走 X-DLV-01 / SAL-20；供应商采购、BOM 与补货 → 请走 X-DLV-02；已交付客户扩容加席位 → 请走 X-DLV-33；已交付设备的售后返修 → 请走 X-CS-12；软硬一体合同开票与硬件基准价 → 请走 FIN-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发起人 登记新报价、配置变更、规格咨询或硬件缺陷事项 R 提出方（产品/销售/交付/售后）
硬件负责人 出技术方案、维护标准配置与席位公式、模型×硬件基线 R 硬件负责人（当前：杨明学·推断待确认）
供应商对接与成本 拿报价、核算成本（含开模、组装、税费按批量摊销） R 供应商对接与成本核算（当前：闫登辉·推断待确认）
产品负责人 组织评审、定对外口径、维护渠道 SKU、知识库作废旧版 R 产品总监（当前：杨萌·推断待确认）
商务定价 决定售价、是否做配置变更 A 商务定价（当前：李鹏为、常元和·推断待确认）
文档维护 更新配置表与对外文档 R 配置文档维护（当前：游家豪·推断待确认）
模型规格 评估模型显存、并发与最低配置 C 模型规格评估（当前：望政韬·推断待确认）、后端（当前：杨云峰·推断待确认）
硬件问题对接 复现问题、确认固件版本、对接工厂 R 外包硬件对接人（当前：吕振·推断待确认）
技术把关与兜底 给技术建议、催决策、冲突裁决 C 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 供应商报价单（裸机价，内存、硬盘单价分开）、报价有效期
  • 当前标准配置表与价格对照表版本号
  • 变更方案对比：成本增量、替代方案、对软件开发的影响（如 RAID 策略）、认证（3C）影响
  • 席位测算输入：内存、可用容量、目标席位与并发
  • 硬件问题：设备型号、固件版本、复现步骤、发生次数、影响客户

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记触发事项（新报价/配置变更/规格咨询/硬件缺陷） 发起人 当天 多维表格（硬件事项台账） 事项记录 🔧飞书固化
2 出技术方案并核算成本，至少给 1 个替代方案 硬件负责人、供应商对接与成本 登记后 3 个工作日内 选型对比表 方案与成本对比 👤人工判断
3 评审会或线上评审：成本、性能、认证、对软件影响 产品负责人组织 方案出具后 2 个工作日内 飞书会议/审批 评审记录 🔧飞书固化
4 商务拍板：售价、是否采纳变更；技术侧只提建议不拍板 商务定价 评审后 1 个工作日内 飞书审批 决策记录 👤人工判断
5 更新标准配置表与席位 SKU 表（版本号、有效期），同步渠道系统 SKU 文档维护、产品负责人 决策后 2 个工作日内 多维表格、渠道系统后台 新版配置表、SKU 🔧+👤
6 发布对外口径（只写售价不写成本），旧版文档标“已作废”并移入归档目录 产品负责人 更新当天 交付知识库、对外资料 对外版文档 🔧飞书固化
7 报价有效期到期前 5 个工作日提醒，重新询价并复核 供应商对接与成本 到期前 5 个工作日 多维表格提醒 复核记录 🤖自动化
8 硬件缺陷：复现、确认固件版本、反馈工厂、每周跟进直到关闭，结论同步售后 硬件问题对接 复现后 2 个工作日内反馈；每周跟进 硬件问题清单 问题闭环记录 🔧飞书固化

5. 交付物与模板

  • 交付物：硬件事项台账、选型对比与评审记录、标准配置表、席位 SKU 标准表、对外配置口径、模型×硬件基线表、硬件问题清单
  • 建议模板/表单：
    • 标准配置表：型号、CPU、内存、硬盘/盘位、RAID、网口、对外售价、成本（内部视图）、供应商、版本号、生效日期、有效期
    • 席位标准表：型号×内存×硬盘 → 默认席位、并发、可增配件、增配后席位、参考价；席位公式写入表内
    • 模型×硬件基线表：模型、精度、显存需求、最低配置、并发、实测速度
    • 硬件问题清单：设备型号、固件版本、问题描述、复现步骤、影响客户数、反馈日期、工厂回复、状态

6. 异常与升级

  • 同一硬件出现多个成本或售价数字 → 以最新版本配置表为准，其他版本冻结 → 当天告知产品负责人
  • 技术与商务互相推决策 → 评审后 1 个工作日内仍未拍板 → 升级给兜底人点名决策
  • 供应商改配置要加价 → 重新评审，不口头接受 → 2 个工作日内报商务定价
  • 工厂超过 10 个工作日无回复，或问题影响已交付客户 → 升级给兜底人，评估更换固件或供应商，并同步 X-CS-12

7. 衡量指标

  • 对外口径错误次数 = 对外资料中配置或价格写错的次数，目标每季度 0 次
  • 配置表版本唯一率 = 交付知识库中有效版本数，目标每款机型 1 个
  • 配置变更决策周期 = 登记到商务拍板的工作日，目标 ≤ 6 个工作日
  • 硬件问题闭环周期 = 反馈工厂到关闭的自然日，目标 ≤ 30 天

8. 低效诊断

  • 现象：同一硬件成本被报出多个数字，对外售价多次变化，对外资料盘位写错，旧版配置文档仍在知识库；根因是配置表没有版本、有效期和作废流程｜依据：「leapcore软硬件交付」2026-06、「leapcore软硬件交付」2026-09
  • 现象：默认席位多次变化，公式非技术人员看不懂，SKU 数量被反复确认；根因是没有成文的席位标准表｜依据：「leapcore软硬件交付」2026-07、「leapcore软硬件交付」2026-08
  • 现象：供应商来回改配置要加钱，硬件方案与软件逻辑相互影响；根因是缺选型评审和对比模板｜依据：「leapcore市场对接」2026-04、「leapcore市场对接」2026-05
  • 现象：配置变更时技术与市场互相推决策，要靠点名才拍板；根因是没有明确拍板人｜依据：「Leapcore硬件内部讨论群」2026-04
  • 现象：客户能跑多大模型每次现算；根因是没有模型×硬件基线表｜依据：「跃迁基座项目交付沟通」2026-04
  • 现象：白牌硬件没有说明书，固件问题信息链长、复现难；根因是没有硬件问题清单和工厂对接表｜依据：「手机端-录音卡」2026-09、「手机端-录音卡」2026-10

9. 分支变体

  • 标品三款（小型主机/4 盘位/8 盘位）与行业版定价口径不同；教育、新媒体等未稳定版本单独标注
  • 合同价框架：硬件价（型号+增配）+ 软件 License 费（标准版/行业版）+ 词元套餐包
  • 标品供应商与定制供应商分开评审；定制件（外壳开模、小屏）需按批量摊销算单台成本
  • 渠道系统只开放“推荐款”组合，直销可定制配置
  • 录音卡等外购白牌硬件：问题反馈走外包对接人和工厂，不走 RND-03（缺陷提报、复现、分级与指派）

10. 待确认问题

  • 硬件负责人是否正式由 IT 运维兼任？是否需要 AB 角？
  • 硬件售价拍板人是市场销售负责人还是 COO？
  • 标准配置表和席位表以哪个飞书表格为唯一来源？对外版由谁发布？
  • 供应商报价有效期按约 50 天管理是否合适？
  • 录音卡类外购硬件的工厂对接是否转给交付或售后负责？
X-PRD-25AI 报告提示词与报告类型配置变更待优化81

状态：待优化｜证据：有证据（卡片 4 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：字字可研等 AI 报告产品要新增报告类型或项目类型、调整提示词（目录或正文），或者业务专家提交新的提示词、专业类型、法规类型等配置时启动。
  • 负责人：主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——业务专家/提示词作者（当前：王满·推断待确认）、后端研发（当前：王皓南·推断待确认）、平台研发（当前：宋祺睿·推断待确认）、前端研发（当前：待指定）、测试（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记变更 → ② 产品审核类型与字段 → ③ 自动通知并校验覆盖率 → ④ 研发接入/配置 → ⑤ 在测试环境生成验证 → ⑥ 业务专家验收 → ⑦ 不通过的开整改单 → ⑧ 随版本上线并标记版本
  • 交付结果：提示词库中带版本号、状态为“已上线”的提示词记录；对应报告类型能在生产环境正常生成；变更记录和整改记录都能追溯。
  • 状态依据：已有飞书提示词表和提示词库，但 2026-01～04 群里反复追问“是不是最新版本”“文件格式太乱”“谁来改”“缺某类型提示词”，约 20 次。整改建议要重复告知多次，也没有版本号和缺陷单。

1. 场景判定

  • 触发条件：新增报告类型（如项目建议书、专项债、通用报告-其他）；调整某类型提示词的目录或正文；专业类型、投资类型、项目类型字段变化；测试发现生成质量问题需要改提示词。
  • 典型说法：「提示词表里的是最新版本吗」「最新的专业类型列表是啥」「现在提示词谁来改」「通用报告-其他是不是没提示词」
  • 判断问题：这次改动是否只涉及提示词内容或报告类型/字段配置，不用改产品功能逻辑？是 → 走本流程；还要做新功能或改交互 → 走 X-PRD-09（需求提报登记与需求池管理）。
  • 不归本流程管：新功能需求 → 请走 X-PRD-09；报告整体质量评测、双盲评价 → 请走 X-PRD-32；案例和知识库素材获取 → 请走 X-PRD-26；通用 Agent Skill 开发上架 → 请走 RND-56

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 审核变更、维护类型字典、决定是否上线 A 字字可研产品经理（当前：杨萌·推断待确认）
提示词作者 按模板编写和修改提示词，参与验收 R 业务专家（当前：王满·推断待确认）
后端接入 替换或配置提示词，同步类型字段 R 后端研发（当前：王皓南·推断待确认）
配置后台 建设提示词配置后台，负责版本回滚 C 平台研发（当前：宋祺睿·推断待确认）
前端 更新报告分类和类型选项 R 前端研发（当前：待指定）
测试 在测试环境生成验证，检查覆盖率 R 测试（当前：待指定）
机器人/脚本 审核通过后通知研发，校验格式与覆盖率 R（自动） 飞书机器人、校验脚本（由产品经理维护规则）
兜底 职责争议、资源冲突时拍板 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 变更说明：报告类型、投资类型、专业类型，以及变更性质（新增/修改/删除）和原因
  • 提示词正文（纯文本或 Markdown，不收 .doc 散件）和上一版本号
  • 影响范围：涉及哪些报告章节，是否联动测算
  • 验收样例：至少 1 个真实或脱敏项目的基础信息，用来生成对比
  • 期望上线日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在提示词多维表格登记变更（类型字段、正文、版本号、原因） 业务专家 需求产生后 1 个工作日内 飞书多维表格 变更记录（状态：待审核） 🔧飞书固化
2 审核类型命名和字段是否与类型字典一致；缺失的类型先补进字典 产品经理 提交后 1 个工作日内 多维表格、类型字典 审核结论（通过/退回） 👤人工判断
3 审核通过后自动通知研发；脚本校验格式并检查各类型覆盖率 机器人/脚本 审核通过后即时 飞书机器人、校验脚本 通知、覆盖率报告 🔧+🤖
4 后端替换或配置提示词，前端同步分类选项；同一变更前后端同批合并 后端/前端研发 审核后 2 个工作日内 Gitea、配置后台 已合并的 PR 或配置记录 👤人工判断
5 用验收样例在测试环境生成，检查目录是否完整、有无冲突提示词、测算联动是否正常 测试 部署后 1 个工作日内 测试环境 生成样稿、问题清单 🤖自动化
6 阅读样稿，给出“通过/不通过 + 问题点” 业务专家 收到样稿后 2 个工作日内 多维表格评论 验收结论 👤人工判断
7 不通过的问题记入缺陷表，写明整改方式、负责人、复测日期，并把链接发到群里留痕 产品经理 验收当日 缺陷多维表格 整改单 🔧飞书固化
8 通过后随版本上线，记录状态改为“已上线”，旧版本标“已废弃” 后端研发 跟随最近一次发版 发版流程、多维表格 已上线版本记录 🔧飞书固化

5. 交付物与模板

  • 交付物：提示词版本记录、报告类型字典、生成验收样稿、整改单
  • 建议模板/表单（提示词多维表格）：编号｜报告类型｜投资类型｜专业类型｜章节｜提示词正文｜版本号｜上一版本｜变更原因｜作者｜审核人｜状态（草稿/待审核/待接入/测试中/待验收/已上线/已废弃）｜上线日期｜关联缺陷
  • 类型字典：报告类型 × 投资类型（企业投资/政府专项债/政府其他）× 专业类型，逐项标注是否已有提示词

6. 异常与升级

  • 发现某类型没有提示词 → 先用最接近的类型临时兜底，并在字典标“待替换” → 产品经理 1 个工作日内指定补写人和完成日期
  • 同一整改建议被问了 2 次以上 → 必须写进整改单并 @ 负责人 → 超过 3 个工作日未闭环，升级给 CTO
  • 对“谁来改提示词”有争议 → 按本 SOP 分工：内容由业务专家改，接入由研发改 → 仍有争议升级 CTO，1 个工作日内拍板
  • 业务专家不在 → 产品经理代审 → 上线后 3 个工作日内由业务专家补复核

7. 衡量指标

  • 变更周期：从提交到上线的工作日数，目标 ≤ 5 个工作日
  • 提示词覆盖率：已有提示词的类型组合数 ÷ 类型字典全部组合数，目标 100%
  • 一次验收通过率：首次业务专家验收就通过的变更数 ÷ 总变更数，目标 ≥ 70%
  • 版本追问次数：群里问“是不是最新版”的次数，目标每月 0 次

8. 低效诊断

  • 现象：提示词以 .doc、.txt 散件交付，格式乱、版本不明，研发要先清洗，再反复确认是不是最新版（约 5 次）｜依据：「鼎慧产研决策部」2026-01
  • 现象：提示词“谁写、谁替换”没有明确分工，替换全靠单个研发手工完成，前后端还要同时更新才生效｜依据：「鼎慧产研决策部」2026-01
  • 现象：报告类型、投资类型、专业类型字段混用，到接入时才发现缺“企业投资项目建议书”等类型，只能先用相近类型兜底｜依据：「鼎慧产研决策部」2026-02
  • 现象：测算联动的整改方法口头说了多次仍未执行，没有缺陷单和复测日期，只能在群里“再说一遍留痕”｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 业务专家提供配置（提示词、专业类型、法规类型、文件类型）：从步骤 1 起走完整流程。
  • 新增报告类型（环评、节能、水保、社会稳定风险、通用等）：先在类型字典登记，再写提示词。
  • 测算联动问题整改：按步骤 7 开整改单，由业务专家复测。
  • 提示词配置后台上线后：步骤 4 改为产品或业务专家在后台自助发布，研发只负责审核和回滚。

10. 待确认问题

  • 提示词内容的主责是否为业务专家，流程主责是否为字字可研产品经理？
  • 是否建设提示词配置后台（带版本、可回滚）？由谁负责，何时完成？
  • 现有飞书 wiki 提示词表是否迁移成多维表格并统一字段，旧表是否废弃？
  • 研发接入 2 个工作日、业务专家验收 2 个工作日是否可行？
  • 字字可研前端研发和测试的固定对接人是谁？
X-PRD-26行业案例、测试数据与知识库素材获取待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险3

  • 适用场景：产品或行业 Skill 开发需要真实案例、测试数据、评判标准或行业资料，要向合作方、客户、外包爬虫或自有数据源获取，并清洗入库时启动。
  • 负责人：主责——需求方产品经理（当前：杨萌·推断待确认）；协同——数据/爬虫研发（当前：魏宗浩·推断待确认）、后端研发/查库（当前：王皓南·推断待确认）、业务专家（当前：王满·推断待确认）、商务/项目经理（当前：杨朋伟·推断待确认）、FDE/Skill 研发（当前：邓乾、李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、平台研发（当前：宋祺睿·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 写数据需求单 → ② 盘点现有库存与缺口 → ③ 选定来源并约定截止日 → ④ 获取并留痕 → ⑤ 脱敏、清洗、转换 → ⑥ 入 test 库，抽样检查 → ⑦ 产品验收后入 prod 或评测集 → ⑧ 登记素材台账
  • 交付结果：按类型分好、已脱敏、有标签的案例集、测试数据集或知识库数据（test/prod），以及一份记录来源、范围、覆盖率的素材台账。
  • 状态依据：每次都是临时处理：案例类型清单没有沉淀，爬虫站点范围靠微信和视频会确认，投资人版 Skill 缺测试数据和评判标准。2026-01～10 反复出现“又一周过去了”“没法测试效果”。

1. 场景判定

  • 触发条件：AI 报告要按专业类型补真实案例；知识库要接入新的行业站点；行业 Skill 要拿真实客户数据做测试、定评判标准。
  • 典型说法：「别让对方选类型了，让他选又一周过去」「爬虫的截止时间大概是啥时候」「没有这个基础，Skill 完全没法测试效果」「找一家他们投过的公司，把投融资所需文件都给一份」
  • 判断问题：缺的是“数据或素材本身”，还是“功能”？缺素材 → 走本流程；缺功能 → 走 X-PRD-09（需求提报登记与需求池管理）。
  • 不归本流程管：知识库的技术清洗和入库管道 → 请走 RND-84；评测集和评测体系建设 → 请走 RND-82；生成质量评测 → 请走 X-PRD-32；行业 Skill 上架下发 → 请走 X-FDE-09；客户数据导出授权 → 请走 X-SEC-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
需求主责 写需求单，定类型和数量，验收入库结果 A 需求方产品经理（当前：杨萌·推断待确认）
查库 统计现有案例的类型分布和缺口 R 后端研发（当前：王皓南·推断待确认）
爬虫与清洗 写爬虫需求、对接外包、清洗转换、入库 R 数据/爬虫研发（当前：魏宗浩·推断待确认）
环境支持 test/prod 环境、内容查看入口 C 平台研发（当前：宋祺睿·推断待确认）
业务确认 确认站点范围、案例类型，提供行业资料 C 业务专家（当前：王满·推断待确认）
外部对接 向合作方或客户索取数据和 Skill 包 R 商务/项目经理（当前：杨朋伟·推断待确认）
Skill 测试 用数据测 Skill、拆分优化 R FDE/Skill 研发（当前：邓乾、李凯·推断待确认）
标准检查 检查 Skill 是否符合开放平台标准 C 开放平台负责人（当前：郭逸非·推断待确认）
兜底 外包渠道和预算审批、争议拍板 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 用途：用于生成参考、测试、评测还是知识库检索
  • 类型和数量：如“投资类型 + 专业类型”取案例数量前 5 的类型，每类 N 份
  • 来源候选：内部库、合作方或客户、公开站点（附站点清单和下级页面范围）
  • 截止日期和验收标准（字段完整率、抽样准确率）
  • 涉及客户数据的，先准备脱敏规则和授权证明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填数据需求单：用途、类型、数量、来源、截止日、验收标准 需求方产品经理 需求确定后 1 个工作日内 飞书多维表格 数据需求单 🔧飞书固化
2 查测试库和生产库的案例分布，输出缺口清单 后端研发 2 个工作日内 生产库、查询脚本 类型分布表、缺口清单 🤖自动化
3 由产品直接圈定类型和数量，不交给提供方选；需求清单发给提供方 需求方产品经理 缺口清单出来后 1 个工作日内 飞书文档 对外提数清单 👤人工判断
4 选来源：合作方/客户由商务对接；公开站点写爬虫需求文档，评审后找外包 商务/数据研发 2 个工作日内启动 飞书文档、外包群 获取任务（含截止日） 👤人工判断
5 范围变化一律在需求文档评论区确认，不只靠微信或口头 全体参与人 变化当日 飞书文档评论 范围变更留痕 🔧飞书固化
6 脱敏、清洗、格式转换、打标签 数据研发 拿到数据后 3 个工作日内 清洗脚本 标准化数据 🤖自动化
7 增量写入 test 库（新增数据不删除原有数据），脚本抽样，通知产品检查 数据研发 清洗后 1 个工作日内 test 环境、内容查看入口 抽样报告 🔧+🤖
8 产品或业务专家验收；通过后迁移到 prod 或评测集，并清理无效数据 产品经理/数据研发 验收后 2 个工作日内 prod 环境 已入库数据 👤人工判断
9 更新素材台账：来源、范围、数量、覆盖率、授权情况 需求方产品经理 入库当日 多维表格 素材台账 🔧飞书固化

5. 交付物与模板

  • 交付物：数据需求单、缺口清单、爬虫需求文档、抽样报告、入库数据、素材台账
  • 建议模板/表单（数据需求单）：需求编号｜用途｜产品线｜类型维度（投资类型/专业类型/行业）｜数量｜来源｜对接人｜截止日｜验收标准｜是否含客户数据｜脱敏方式｜状态（待获取/获取中/清洗中/test 待验/已入 prod/已入评测集）
  • 爬虫清单字段：站点｜页面范围｜负责人｜外包方｜截止日｜确认人｜增量或全量｜状态

6. 异常与升级

  • 提供方超过截止日 3 个工作日仍未交 → 商务/项目经理追一次并换备选来源 → 再超 2 个工作日升级 CTO
  • 产品和数据研发对站点范围记忆不一致 → 以需求文档评论为准 → 没有留痕的，由产品当日补确认
  • 客户数据没有授权或无法脱敏 → 停止使用 → 走 X-SEC-35 授权
  • 外包质量不达标（抽样错误率 > 5%）→ 退回重做 → 2 次不达标由 CTO 决定是否更换外包

7. 衡量指标

  • 素材获取周期：需求单创建到入库的自然日，目标 ≤ 10 天
  • 按期交付率：在截止日前入库的需求单数 ÷ 总数，目标 ≥ 80%
  • 类型覆盖率：已有案例的常用类型数 ÷ 常用类型总数，目标 ≥ 90%
  • 抽样准确率：抽样合格条数 ÷ 抽样总数，目标 ≥ 95%

8. 低效诊断

  • 现象：把“选哪些专业类型”交给案例提供方决定，迟迟不回，一拖就是一周；筛选后的案例长期没拿到｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：“专业类型”和“建设内容类型”口径不统一，类型清单没有沉淀，下次还要重新讨论｜依据：「鼎慧产研决策部」2026-03
  • 现象：爬虫站点范围靠视频会和微信确认，交付时双方对“少了”还是“纯新增”说法不一；文件没打标签导致搜不到｜依据：「工程咨询产研」2026-01
  • 现象：行业 Skill 缺测试数据和评判标准，版本包在专用和通用之间多次流转；该由谁拆分 Skill 不明确，交接时 FDE 人手紧张｜依据：「【行业版Leapcore】投资人版」2026-07、「【行业版Leapcore】投资人版」2026-09

9. 分支变体

  • 工程咨询案例：按“投资类型 + 专业类型”取数量前 5 的类型；投资类型分企业投资、政府专项债、政府其他。
  • 行业知识库：外包爬虫、自有清洗转换两种方式；分增量更新和全量更新，增量更新不能删除原有数据。
  • 投资人版/行业版 Skill：合作伙伴 Skill 包加客户脱敏数据，配评判标准（参考输入、期望结论、专家过程说明），作为 Eval 雏形；专用版（某投资机构客户）和通用投资版分开管理。

10. 待确认问题

  • 素材获取的主责是各产品线产品经理，还是设一个统一的数据负责人？
  • 外包爬虫的预算审批和渠道由谁管？是否有成文制度？
  • 合作方或客户数据的授权、脱敏标准由谁审核（法务是否参与）？
  • 素材台账和 RND-82 评测集是否合并成一张表？
  • 截止日超期 3 个工作日即升级是否可行？
X-PRD-27迭代规划、故事拆分与排期待优化108

状态：待优化｜证据：有证据（卡片 14 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：每个迭代开始前（两周或一周一迭代），汇总评审通过的需求，拆成 issue 或故事卡，估点数，分配到人，确定迭代范围和交付日；迭代中插入需求或迭代末迁移未完成项时也适用。
  • 负责人：主责——产品负责人/迭代负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、段涵·推断待确认）、研发复杂度评估（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞测试（当前：赵伟龙·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 产品出下迭代需求（D-5）→ ② 研发估点（D-3）→ ③ 按容量砍需求、低优先级移入待评估池 → ④ 迭代计划会 → ⑤ 建 milestone/issue 并分配到人 → ⑥ 成员按天拆任务 → ⑦ 迭代末迁移未完成项
  • 交付结果：一份迭代计划，含需求清单、点数、负责人、交付日、待评估池；每个需求有对应 issue 并挂在 milestone 上；工作台任务视图更新完毕。
  • 状态依据：已有工作台多维表格、Gitea milestone、迭代文档和计划会，但流程没有成文。2026-01～10 多条产品线反复出现催填迭代文档、迭代开始后才评估、需求散在三处、P0 泛滥等问题，约 60 次。

1. 场景判定

  • 触发条件：上一迭代剩 3～5 个工作日；产研决策会定了新的冲刺目标；客户定制方案需要拆成研发任务；迭代中有人要求插入需求。
  • 典型说法：「先开会在工作台过一下下个迭代的需求」「先做一下故事点」「不能按理论点数，得按实际点数规划」「把任务拆到迭代文档里，具体到天」「这个迭代会做完吗」
  • 判断问题：要回答的是“这一迭代做哪些、谁做、哪天交”吗？是 → 走本流程。还在讨论“做不做、需求怎么写” → 先走 X-PRD-09（需求池）和 X-PRD-13（PRD 撰写与需求评审）。
  • 不归本流程管：需求提报入池 → 请走 X-PRD-09；优先级判定与紧急插单 → 请走 X-PRD-10；PRD 撰写与需求评审 → 请走 X-PRD-13；迭代执行期站会与进度追踪 → 请走 X-PRD-30；客户定制需求承接 → 请走 X-DLV-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
迭代负责人 定迭代目标和范围，组织计划会，拍板优先级 A 产品负责人（当前：杨萌·推断待确认）
需求提供 按时出下迭代需求和原型，录入需求表 R 产品经理（当前：黄飞鹏、段涵·推断待确认）
拆分估点 拆 issue/故事卡，估点数，按容量排期，分工到人 R 研发负责人（当前：王皓南·推断待确认）
复杂度评估 评估技术复杂度，必要时出技术方案或 ADR C 研发（当前：宋祺睿·推断待确认）
测试 评审时过测试点，确认 P0 范围 C 测试负责人（当前：张东郅·推断待确认）
跃竞线 星域/会员端迭代的组织，跃竞线内需求取舍的一线决定 R 跃竞产品负责人（当前：徐莉·推断待确认）；会员端产品经理（当前：陈雁·推断待确认）
跃竞测试 评审前写新迭代测试点 C 跃竞测试（当前：赵伟龙·推断待确认）
研发成员 按天拆任务、填写每日目标 R 各产品线研发成员
机器人 定时提醒未填任务的人 R（自动） 飞书机器人（由迭代负责人维护规则）
兜底 跨产品线资源冲突、方向分歧拍板 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求池中“已评审”状态的需求清单（含来源、优先级、验收标准、关联文档）
  • 上迭代未完成项和原因
  • 本迭代可用点数：按实际在岗人天折算，不按理论满额
  • 已知依赖：设计稿、数据连接、第三方接口、测试环境
  • 迭代起止日期和发版目标日

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 机器人提醒产品提交下迭代需求；产品把需求录入工作台，状态改“待估点” 产品经理 迭代开始前 5 个工作日（D-5） 工作台多维表格、飞书机器人 下迭代候选需求清单 🔧飞书固化
2 拆 issue/故事卡并估点；需求里的隐含工作量（反复提交、版本、权限）要单列 研发负责人 D-3 前 Gitea issue、AI 拆卡 skill 故事卡、点数 🤖+👤
3 按可用点数（约理论值的 80%）排；超出部分由产品砍掉或移入“待评估池” 迭代负责人 D-2 前 工作台看板 迭代范围草案 👤人工判断
4 召开迭代计划会（产品、研发、测试参加；缺席者看纪要和录像），确认范围、负责人、交付日 迭代负责人 D-1，60 分钟内 飞书日程循环事件、妙记 会议纪要、迭代计划 🔧飞书固化
5 建 milestone，issue 挂到 milestone；工作台填“研发负责人”（必填）并关联 issue 研发负责人 计划会当日 Gitea、工作台 milestone、已分配 issue 🔧+👤
6 成员把任务按天拆进迭代任务视图，写明每日目标 研发成员 迭代第 1 天下班前 工作台任务视图 按天任务 🔧飞书固化
7 机器人每日检查未填任务的人并点名提醒 机器人 每日 10:00 飞书机器人 提醒消息 🤖自动化
8 迭代末把未完成项自动迁移到下迭代，状态标“顺延”并写原因 迭代负责人 迭代最后 1 个工作日 工作台自动化 顺延清单 🔧+🤖

5. 交付物与模板

  • 交付物：迭代计划（目标、范围、点数、负责人、交付日）、milestone、故事卡/issue、待评估池、顺延清单
  • 建议模板/表单（工作台需求表字段）：需求编号｜标题｜来源（客户/销售/产品自提/高层/测试）｜产品线｜优先级（P0～P3，附判定规则）｜需求文档链接｜验收标准｜点数｜研发负责人（必填）｜测试负责人｜迭代号｜关联 issue｜状态（待估点/已排期/开发中/待产品验收/测试中/已上线/顺延/待评估）
  • 故事卡模板：用户故事｜验收标准｜点数｜依赖｜不做项

6. 异常与升级

  • D-3 产品仍未出需求 → 机器人提醒，并抄送迭代负责人 → D-1 仍未出，由研发负责人从待评估池选技术债填满，同时报 CTO
  • 估点超出容量且优先级冲突（如支付与组织） → 迭代负责人当场拍板 → 跨产品线冲突 1 个工作日内升级 CTO
  • 迭代中插入需求 → 走 X-PRD-10 判定 → 插入时必须同时移出等量点数
  • 迭代负责人请假或交接 → 出发前在工作台指定代理人 → 未指定时由研发负责人代管
  • 拍板权说明：各产品线迭代范围的最终拍板为迭代负责人（A）；跃竞线由跃竞产品负责人按本流程组织并做线内取舍（R），跨产品线资源冲突升级 CTO

7. 衡量指标

  • 计划按期率：D-1 前完成估点的迭代数 ÷ 总迭代数，目标 100%
  • 迭代完成率：迭代内完成点数 ÷ 计划点数，目标 ≥ 80%
  • 插单率：迭代中新增点数 ÷ 计划点数，目标 ≤ 15%
  • 任务填写及时率：第 1 天下班前完成按天拆分的人数 ÷ 应填人数，目标 ≥ 95%

8. 低效诊断

  • 现象：产品方向在会前反复改，计划与执行人不同步（“手机版从哪冒出来的”）；架构决策一开始没落工单，后来才规定“以工单为准”｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：迭代流程只在群里口头提出、没有成文；产品人手不足，需求靠口头记忆，出现“以为你自己记着”而没建 issue｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-03
  • 现象：按理论点数规划后不得不砍需求；反复提交审核等隐含工作量没计入点数｜依据：「鼎慧产研决策部」2026-03
  • 现象：迭代文档、工作台填写全靠催（约 8 次），颗粒度不统一，迭代内改期也不告知｜依据：「工程咨询产研」2026-01
  • 现象：需求分散在 wiki、工作台、Gitea issue 三处，研发问“这需求哪来的”；“当前负责人”和“研发负责人”字段混用，按字段过滤看不到任务｜依据：「工程咨询产研」2026-02、「工程咨询产研」2026-03
  • 现象：迭代开始后才评估需求，迭代负责人交接后无人组织，迭代只完成约四成｜依据：「工程咨询产研」2026-04
  • 现象：需求评审日期反复调整，研发要求产品给出固定出需求的时间点｜依据：「鼎慧产研决策部」2026-04
  • 现象：周迭代中紧急需求频繁插入、P0 占比过高，同一功能多次重做；评审会时间不固定，任务填写每周都要催｜依据：「跃玩项目组」2026-04、「跃玩项目组」2026-07、「跃玩remote工作组」2026-06

9. 分支变体

  • LeapCore/LeapAll：两周冲刺，Gitea milestone + 故事点；研发完成后找产品验收，再转测试。
  • 字字可研/工程咨询线：大需求在工作台需求表管理，具体任务写进迭代文档并按天拆分。
  • 跃竞（星域、会员端）：一周或两周一迭代，按“迭代需求文档 + 原型 + 评审会”推进，评审前测试先过测试点。
  • 客户定制方案：先由技术负责人区分“我方做的”和“客户 IT 做的”，再拆成研发条目进入本流程。
  • 教育组等外部协作需求：单独评审，不和内部迭代混排。

10. 待确认问题

  • 各产品线的迭代负责人是否固定为产品负责人？跃竞线是否单独指定？
  • D-5 出需求、D-3 估点、D-1 计划会的节奏是否适用于一周迭代的跃竞线？
  • 工作台多维表格是否作为唯一需求载体？wiki 迭代文档是否停用？
  • P0 判定规则（资金、线上故障、客户合同）由谁制定发布？
  • 可用点数按理论值 80% 折算是否合适？
X-PRD-28开发中需求澄清与产品拍板待优化135

状态：待优化｜证据：有证据（卡片 14 张 / 会话 4 个）｜优先级：频5 × 耗3 × 跨3 × 险3

  • 适用场景：研发或测试在开发、测试中遇到需求细节没定义、预期行为不确定（看起来像 bug 又像设计）、术语或权限语义有分歧、新集成要选技术方案，需要产品澄清或拍板时启动。
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震·推断待确认）、研发负责人（当前：王皓南·推断待确认）、测试负责人（当前：张东郅·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞会员端产品经理（当前：陈雁·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 在工单按模板提问 → ② 自动 @ 模块产品 → ③ 产品限时答复或拍板 → ④ 有争议的开 15 分钟对齐会 → ⑤ 结论回写工单和决策记录表 → ⑥ 涉及术语、规则的同步更新术语表或规则台账 → ⑦ 通知相关研发和测试
  • 交付结果：工单里有明确的产品结论（谁定、何时定、结论是什么）；决策记录表新增一条；需要时同步更新需求文档、术语表、权限矩阵或业务规则台账。
  • 状态依据：群里有随问随答的习惯，但 2026-02～09 同类问题反复问，结论只留在群聊。“谁改的需求”“需求工作台也不一定准”“这个话题昨晚已经重复过了”这类情况约 150 次，没有术语表、权限矩阵和决策记录。

1. 场景判定

  • 触发条件：实现时发现需求没写到的细节；测试发现行为和预期不符，但不确定是不是 bug；同一个名词各方理解不同（场景与部门、内置与官方 Skill、只读是否含下载）；新集成要选方案（连接器还是 Skill）；运营要求调整上传规格等限制。
  • 典型说法：「这是产品预期还是 bug」「具体预期行为需要产品拍板一下」「统一一下语言」「需要决策一下技术实现」「这个需求是谁改的」
  • 判断问题：需求范围本身没变，只是细节或口径不清？是 → 走本流程。要新增或砍掉功能、改变范围 → 走 X-PRD-29（需求变更控制）。
  • 不归本流程管：新增、删减需求或调整范围 → 请走 X-PRD-29；术语与命名规范的制定 → 请走 X-PRD-15；业务规则与统计口径的正式定义 → 请走 X-PRD-14；确认是缺陷后的提报修复 → 请走 RND-03；UI 设计走查 → 请走 X-PRD-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
最终拍板 产品行为、命名、取舍的最终决定 A 产品负责人（当前：杨萌·推断待确认）
模块答复 本模块问题的一线答复和记录 R 模块产品经理（当前：黄飞鹏、陈震·推断待确认）
技术方案 技术实现方案拍板，纠正术语 R 研发负责人（当前：王皓南·推断待确认）
提问与验证 按模板提问，按结论测试 C 测试负责人（当前：张东郅·推断待确认）
提问研发 按模板在工单提问，按结论实现；技术方案类写 1 页方案 R 各模块研发
机器人 按模块 @ 产品经理，推送结论给相关研发和测试 R（自动） 飞书机器人（由产品负责人维护规则）
跃竞线答复 星域/会员端规则口径和规格的一线决定 R 跃竞产品负责人（当前：徐莉·推断待确认）；会员端产品经理（当前：陈雁·推断待确认）
跃竞技术 提醒新人先问再做，评估规则变更影响 C 跃竞后端负责人（当前：王子明·推断待确认）
兜底 产品与技术意见僵持时拍板 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 工单号和需求文档链接（指明哪一段不清楚）
  • 现象截图或录屏、复现环境
  • 可选方案（至少 2 个）及各自的影响（工作量、数据、计费、客户体验）
  • 参考：权限设计文档、术语表、竞品或旧版本（如 LeapLite）的行为
  • 期望答复时间（是否阻塞开发）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在工单评论按“现象/需求出处/可选方案/影响/是否阻塞”提问，标签选“待产品确认” 提问的研发或测试 发现当日 Gitea/工单系统 澄清请求 👤人工判断
2 机器人按模块自动 @ 对应产品经理；群里只转发工单链接 机器人 即时 飞书机器人 通知 🤖自动化
3 先查术语表、决策记录表有无现成结论，有就直接引用 模块产品经理 2 个工作小时内 决策记录表 引用结论 🤖+👤
4 给出结论：阻塞类 4 个工作小时内，非阻塞 1 个工作日内 模块产品经理 见左 工单评论 产品结论 👤人工判断
5 群里来回超过 3 轮仍有分歧 → 停止打字讨论，拉 15 分钟当面或线上对齐会 产品负责人 当日 飞书会议 对齐结论 👤人工判断
6 技术方案类：研发写 1 页方案（方案、取舍理由、风险），研发负责人拍板后再开 feat 工单 研发/研发负责人 2 个工作日内 飞书文档 方案文档 👤人工判断
7 结论回写工单，写入决策记录表；涉及命名、权限、规则的同步更新术语表、权限矩阵或规则台账 模块产品经理 结论当日 工单、多维表格 决策记录 🔧+🤖
8 机器人把结论推送给工单相关研发和测试；测试据此更新测试点 机器人/测试 即时 飞书机器人 已同步结论 🤖自动化

5. 交付物与模板

  • 交付物：工单产品结论、决策记录、方案文档（技术类）、更新后的术语表、权限矩阵或规则台账
  • 建议模板/表单（决策记录表）：编号｜产品线/模块｜问题｜可选方案｜结论｜决策人｜日期｜关联工单｜影响（文档/测试点/数据迁移）｜是否需改需求文档
  • 澄清提问模板：现象｜需求出处（链接+段落）｜方案 A/B｜影响｜是否阻塞｜期望答复时间

6. 异常与升级

  • 产品超时未答复且阻塞开发 → 提问人 @ 产品负责人 → 再过 4 个工作小时仍未答复，由研发负责人按影响最小的方案先做，并标“待产品追认”
  • 产品负责人请假 → 请假前在工作台指定代理产品经理 → 没有指定的，由研发负责人临时代决，事后补追认
  • 产品与研发意见僵持（如数据迁移成本、只读语义） → 双方各写 3 行理由 → 1 个工作日内升级 CTO 拍板
  • 同一问题第 2 次被问到 → 产品当日把结论补进 FAQ 或术语表
  • 拍板权说明：产品行为、命名、取舍的最终拍板为产品负责人（A）；跃竞线由跃竞产品负责人/会员端产品经理做线内一线决定（R），与 Leap 线规则冲突或产品与技术僵持时升级 CTO

7. 衡量指标

  • 澄清响应时长：提问到产品给结论的工作小时数，阻塞类目标 ≤ 4 小时
  • 结论留痕率：有工单结论的澄清数 ÷ 群里出现的澄清数，目标 ≥ 90%
  • 重复提问率：月内重复问同一问题的次数 ÷ 澄清总数，目标 ≤ 10%
  • 澄清导致的返工工单数：每迭代统计，目标逐迭代下降

8. 低效诊断

  • 现象：内置/官方 Skill、场景与部门等术语反复争论（约 8 次）；没有权限设计矩阵，需求里没写的功能被泛化做出来｜依据：「Leap产研测」2026-07
  • 现象：产品不在时研发自己决定或搁置；外部叫“全员空间”内部叫“企业空间”，只改了一半；没人认领的工单成了“孤儿”｜依据：「Leap产研测」2026-08
  • 现象：结论只在群聊和迭代会口头确认，“昨晚已经重复过了”第二天又讨论，负责的研发直到提测还不知道怎么做｜依据：「Leap产研测」2026-08
  • 现象：只读是否含下载、视频参数、附件上限等语义争议在群里连续 40 多条，没有变更记录，RTF 预览一天内删了又加｜依据：「Leap产研测」2026-09
  • 现象：研发直接用 AI 编码工具自行发挥做新功能，做完才被发现方向不对；规则只是口头宣布，没有决策记录模板｜依据：「Leap产研测」2026-05、「Leap产研测」2026-06
  • 现象：产品请假后由谁拍板要临时口头指定；方案争议在群里长聊，结论难以追溯｜依据：「工程咨询产研」2026-02
  • 现象：需求方向（如知识图谱）三方理解各不相同，细节在私下聊天中定｜依据：「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-08
  • 现象：需求文档按客户视角写，开发理解出现偏差；昵称审核、价格口径等规则改了 5 次，每次都要靠测试发现不一致｜依据：「跃玩remote工作组」2026-04、「跃玩remote工作组」2026-06、「跃玩remote工作组」2026-07

9. 分支变体

  • 权限类：以产品权限设计文档为准（“可阅读”只能预览，不能下载）；要扩展语义的视为加需求，走 X-PRD-29。
  • 交互一致性：LeapNew 和 LeapLite 行为不一致时，默认以产品最新确认的版本为准，并写入决策记录。
  • 新集成方案（如财务软件集成、空间文档）：研发先做 PoC，再按步骤 6 出方案文档；默认走用户自己的账号授权。
  • 跃竞规则类（审核、价格/抽成、抢单状态）：结论写入业务规则台账，变更时产品、测试、开发三方确认。
  • 小程序图片等上传规格：由产品定阈值，同步输出运营图片规格说明（尺寸、大小、压缩方式），并在上传页提示。

10. 待确认问题

  • 阻塞类 4 个工作小时、非阻塞 1 个工作日的答复时限是否可行？
  • 决策记录表放在哪个空间、由谁维护？是否和需求池合并？
  • 产品请假时的代理人制度由谁发布？
  • 研发负责人是否有权在产品超时时“先做后追认”？
  • 跃竞线的业务规则台账是否已有雏形？
X-PRD-29需求变更控制待优化192

状态：待优化｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：开发中的需求要被砍、范围或文案调整、临时追加，或实现与原型不一致需要改，包括演示和发布前体验者提的新需求、前线口头协商的需求时启动。
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、产品经理（当前：黄飞鹏、陈震·推断待确认）、测试负责人（当前：张东郅·推断待确认）、前线/解决方案（当前：李凯·推断待确认）、发布冻结期变更审批人（当前：常元和·推断待确认）、跃竞产品负责人（当前：徐莉·推断待确认）、跃竞产品经理（当前：段涵·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交变更单 → ② 研发评估影响 → ③ 产品决定（本迭代/下迭代/拒绝）→ ④ 冻结期另需审批人同意 → ⑤ 更新需求文档、原型和工单 → ⑥ 机器人通知研发和测试 → ⑦ 调整排期和测试点 → ⑧ 判断是否重新评审
  • 交付结果：一条已审批的需求变更记录（变更内容、影响、决定、决策人）；需求文档、工单、原型都已同步更新；研发、测试收到通知，排期已调整。
  • 状态依据：有工单和口头确认习惯，也有需求提报表单，但 2026-05～10 临时需求常绕过流程，变更在群里口头提出、文档事后补，“谁改的需求”“你俩到底谁做”这类问题约 70 次；计费类变更还出现过没有用户提示的情况。

1. 场景判定

  • 触发条件：已排期或开发中的需求被砍、改范围、改文案；有人临时“加个需求”；前线或客户口头协商的需求要求马上做；验收发现实现与原型不一致，要改需求而不是修 bug；大会或发布前要关掉、隐藏某些功能。
  • 典型说法：「这个需求砍了，请确认」「这是需求，给产品评估」「需求就这一句话」「大会后做吧，没空做新功能」「需求文档改完了，看看要不要重新评审」
  • 判断问题：改动会不会改变已评审需求的范围、验收标准或工作量？会 → 走本流程；只是澄清细节 → 走 X-PRD-28。
  • 不归本流程管：需求细节澄清 → 请走 X-PRD-28；全新需求入池 → 请走 X-PRD-09；紧急插单的优先级判定 → 请走 X-PRD-10；客户承诺前的可行性确认 → 请走 X-CS-14；线上缺陷的紧急修复 → 请走 RND-54

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
变更决策 接受、延后或拒绝变更 A 产品负责人（当前：杨萌·推断待确认）
变更登记 代前线或研发建变更单，更新文档 R 产品经理（当前：黄飞鹏、陈震·推断待确认）
影响评估 评估工作量、已写代码、下游影响 R 研发负责人（当前：王皓南·推断待确认）
测试同步 更新测试点，评估回归范围 C 测试负责人（当前：张东郅·推断待确认）
前线提出 写清客户、场景、验收标准 C 前线/解决方案（当前：李凯·推断待确认）
冻结期审批 大会或发布冻结期内的变更审批 A（升级） 发布冻结期变更审批人（当前：常元和·推断待确认）
跃竞线 星域/会员端需求变更的线内决定与文档更新 R 跃竞产品负责人（当前：徐莉·推断待确认）；跃竞产品经理（当前：段涵·推断待确认）
提出人/接收人 填变更单；口头提出的由接收人代填 R 变更提出人或接收人（研发、测试、前线、高层均可）
机器人 推送变更摘要给相关研发、测试和群 R（自动） 飞书机器人（由产品负责人维护规则）
兜底 跨线冲突、重大取舍 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 原需求编号、工单号、需求文档或原型链接
  • 变更内容：改前、改后、原因、提出人、来源（客户/内部/大会）
  • 是否涉及计费、扣费、对外文案、数据结构
  • 期望生效时间（本迭代/下迭代/大会后）
  • 如来自客户：客户类型、是否标品需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填需求变更单（多维表格或提报表单），自动生成草稿工单并 @ 产品；口头提出的由接收人代填 提出人/接收人 提出当日 飞书多维表格、提报表单 变更单 🔧飞书固化
2 评估影响：剩余工作量、已写代码是否作废、上下游（分账、SKU、数据迁移）、对测试的影响 研发负责人 1 个工作日内 工单评论 影响评估 👤人工判断
3 决定：本迭代做（同时移出等量点数）/ 下迭代 / 拒绝；计费类必须同时确认用户提示方案 产品负责人 评估后 1 个工作日内 变更单 变更决定 👤人工判断
4 大会或发布冻结期内的变更，另需冻结期审批人在变更单上签字确认 冻结期审批人 1 个工作日内 飞书审批 审批记录 🔧飞书固化
5 更新需求文档、原型、工单描述，标注变更版本；被砍的需求关闭工单并写原因 产品经理 决定当日 飞书文档、工单 已更新文档 🔧飞书固化
6 机器人推送变更摘要给相关研发、测试和群（流程性决策必须全员同步） 机器人 即时 飞书机器人 变更通知 🤖自动化
7 调整排期，更新测试点和回归范围 研发负责人/测试 通知后 1 个工作日内 工作台、测试用例 新排期、测试点 🔧飞书固化
8 变更累计超过原需求 30% 工作量，或影响多端时，重新评审 产品负责人 下次评审会 评审会 重新评审结论 👤人工判断

5. 交付物与模板

  • 交付物：需求变更单、影响评估、变更通知、更新后的需求文档/原型/工单
  • 建议模板/表单（需求变更单）：变更编号｜原需求/工单号｜变更类型（新增/删减/修改/下架/文案）｜改前｜改后｜原因｜提出人｜来源｜影响端（前端/后端/小程序/管理后台）｜工作量变化｜是否涉及计费或对外文案｜决定（本迭代/下迭代/拒绝）｜决策人｜冻结期审批｜日期｜是否需重新评审

6. 异常与升级

  • 口头变更已经开工 → 当日补变更单 → 连续 2 次绕过流程的，由研发负责人在迭代回顾中通报流程问题
  • 已确认的需求被砍但没通知开发 → 开发在工单发“请确认”→ 产品 4 个工作小时内答复
  • 计费或扣费变更没有用户提示方案 → 一律不得上线 → 产品负责人当日补提示方案，必要时找 CTO
  • 产品与冻结期审批人意见不一致 → 冻结期以“只修 bug”为默认 → 1 个工作日内升级 CTO
  • A（升级）说明：平时需求变更由产品负责人最终决定；进入大会或发布冻结期后，任何变更在产品负责人同意的基础上还须冻结期变更审批人签字确认，未签字不得进入开发；跃竞线由跃竞产品负责人做线内决定（R），涉及跨线影响时回到产品负责人

7. 衡量指标

  • 变更留痕率：有变更单的变更数 ÷ 实际发生的变更数，目标 ≥ 90%
  • 变更处理时长：变更单创建到做出决定的工作日数，目标 ≤ 2 个工作日
  • 迭代内变更率：迭代中变更涉及的点数 ÷ 计划点数，目标 ≤ 20%
  • 变更导致的返工工时：每迭代统计，目标逐迭代下降

8. 低效诊断

  • 现象：发布前体验者在群里提需求后被当场拍板，已在改的 UI 被叫停、做完的功能又被砍（约 4 次）；网页版没同步删除，被删功能又“塞回来”；需求变更负责人多头｜依据：「Leap产研测」2026-05
  • 现象：前线需求只有一句话，没有卡片；研发按线下口头做，测试“只是有印象”；需求文档和实现不一致，还要追问“是不是先这样做”｜依据：「Leap产研测」2026-07
  • 现象：需求前一晚才变更，同一需求出现重复工单；计费功能开启即扣费但事先没有用户提示；“你俩到底谁做”这类归属不清的问题反复出现｜依据：「Leap产研测」2026-09
  • 现象：变更在群里口头提出、文档事后更新，实现与原型不一致直到验收才发现（约 4 次）｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-10

9. 分支变体

  • 大会或发布前：进入冻结期，只修 bug；新需求一律标“大会后”，以 P2/P3 入池。
  • 前线或客户临时需求（标品或定制客户）：先判断有多少企业需要，再决定是入标品还是走定制，见 X-PRD-11。
  • 跃竞线：变更由产品负责人直接 @ 开发提出，开发回复影响后执行；赶不上本期的改为“下期加”；功能下架要同步各端。
  • 计费/扣费类变更：必须附用户提示和确认方案，产品负责人确认后才能开发。

10. 待确认问题

  • 需求变更的统一决策人是否为产品负责人？冻结期审批人是否固定？
  • 变更单用现有需求提报表单扩展，还是新建一张表？
  • “超过 30% 工作量需重新评审”的阈值是否合适？
  • 跃竞线是否也采用同一张变更单？
  • 计费类变更是否需要财务会签？
X-PRD-30迭代站会、进度追踪与交付节点管理待优化240

状态：待优化｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：迭代执行期的日常站会和迭代回顾；多项目、多客户、多版本并行时，需要统一追踪关键交付节点、发布进度和延期预警时启动。
  • 负责人：主责——项目经理/进度负责人（当前：杨萌·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、技术顾问（当前：望政韬·推断待确认）、后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）、IT 运维/部署（当前：杨明学·推断待确认）、商务对接（当前：闫登辉、吴琪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、CEO（知会）（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 站会前更新 issue 和任务状态 → ② 固定时间开站会 → ③ 站会决议写入迭代文档 → ④ 维护“客户×版本×节点”里程碑台账 → ⑤ 机器人每日汇总进度 → ⑥ 节点前 2 天预警 → ⑦ 延期决策并通知 → ⑧ 迭代末开回顾会
  • 交付结果：每日站会纪要；实时更新的里程碑台账（客户、版本、模块、截止日、负责人、状态）；延期通报；迭代回顾的改进待办。
  • 状态依据：站会和进度同步会已经形成节奏，但 2026-01～05 时间和召集人不固定，延期只在口头通报，多客户多版本没有统一台账，“到底几个客户几个版本什么时候要”这类追问约 40 次；里程碑看板尚未建立。

1. 场景判定

  • 触发条件：迭代进行中的每个工作日；有对外交付或发布节点（如云端体验版、客户版本）；同时有 2 个以上客户或版本在推进；出现可能延期的信号。
  • 典型说法：「站会没」「感觉你需要拉个时间节点出来」「截止日可能要延期」「到底几个客户、几个版本、什么时候要」「需求和进度统一对齐到产品负责人」
  • 判断问题：要解决的是“已经定下的事做到哪了、会不会延期”吗？是 → 走本流程。还在定“做什么” → 走 X-PRD-27。
  • 不归本流程管：迭代范围规划与排期 → 请走 X-PRD-27；交付项目现场进度与卡点 → 请走 X-DLV-35；客户定制需求承接拆解 → 请走 X-DLV-10；正式发版操作 → 请走 RND-51

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
进度主责 召集站会，维护里程碑台账，预警和通报延期 A 项目经理/进度负责人（当前：杨萌·推断待确认）
研发进度 主持技术站会，确认任务状态和卡点 R 研发负责人（当前：王皓南·推断待确认）
技术咨询 解答技术问题 C 技术顾问（当前：望政韬·推断待确认）
交付执行 更新部署和版本进度 R 后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）；IT 运维（当前：杨明学·推断待确认）
客户信息 提供客户、版本、Logo/名称、截止日变化 C 商务对接（当前：闫登辉、吴琪·推断待确认）
测试节点 提供测试计划和验收节点 C 测试负责人（当前：张东郅·推断待确认）
全体研发 站会前更新 issue 和任务状态 R 各项目研发成员
机器人 提醒未更新状态的人，每日汇总进度并 @ 责任人 R（自动） 飞书机器人（由进度负责人维护规则）
知会 接收关键节点和延期通报 I CEO（当前：邴龙志·推断待确认）
兜底 延期决策、资源调配、决策分歧 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 当期迭代计划和 milestone
  • 每人站会前更新好的 issue 状态（昨天完成、今天计划、卡点）
  • 客户、版本清单：客户类型、版本形态（云服务/硬件+服务/私有部署/特供）、模块开关、Logo 和名称、截止日
  • 上次站会遗留的决议和待办

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用飞书日程循环事件固定站会时间和会议室，召集人写在日程里 进度负责人 迭代启动当日 飞书日程 循环站会日程 🔧飞书固化
2 站会前更新 issue 和任务状态，机器人提醒未更新的人 全体研发/机器人 站会前 30 分钟 工作台、Gitea、机器人 已更新状态 👤+🤖
3 开站会（≤ 15 分钟）：只讲进度、卡点、需要谁帮忙 研发负责人 每个工作日固定时间 现场或飞书会议 卡点清单 👤人工判断
4 站会决议（延期、换人、顺延）写入迭代文档或工作台 进度负责人 站会后 1 小时内 飞书妙记、工作台 站会纪要 🔧+🤖
5 维护里程碑台账：客户新增或变更时更新版本、模块、截止日、负责人 进度负责人 变化当日 飞书多维表格 里程碑台账 🔧飞书固化
6 机器人每日汇总各项目进度和未完成项，推送到群并 @ 责任人 机器人 每日 18:00 飞书机器人、AI 汇总 每日进度简报 🤖自动化
7 节点前 2 个工作日检查完成度，低于 80% 的发延期预警 进度负责人 D-2 里程碑台账 延期预警 🔧+👤
8 延期决策：砍范围、加人或改日期；结论通知商务和相关负责人 CTO/进度负责人 预警后 1 个工作日内 飞书群、台账 延期通报 👤人工判断
9 迭代末开回顾会（做得好/问题/改进），改进项进待办 进度负责人 迭代最后 1 个工作日 飞书文档 回顾纪要、改进待办 🔧飞书固化

5. 交付物与模板

  • 交付物：站会纪要、每日进度简报、里程碑台账、延期通报、回顾纪要
  • 建议模板/表单（里程碑台账）：客户（匿名编号）｜版本形态｜包含模块（API/Skills 商城/NAS/字字可研等开关）｜定制项（Logo、名称）｜截止日｜负责人｜商务对接人｜状态（未开始/进行中/待测试/已交付/延期）｜完成度｜延期原因｜最近更新
  • 站会纪要：日期｜参会｜卡点｜决议｜负责人｜截止

6. 异常与升级

  • 站会召集人缺席 → 由研发负责人代开 → 连续 2 天没开站会，报 CTO
  • 客户方案变更 → 商务当日更新台账并 @ 研发 → 影响截止日的走步骤 8
  • 节点当日仍未完成 → 进度负责人当日通报 → 对外承诺类节点同步商务，由商务通知客户
  • 多人同时向研发提需求、抢进度 → 统一经进度负责人排序 → 分歧找 CTO

7. 衡量指标

  • 节点按期率：按期完成的节点数 ÷ 到期节点数，目标 ≥ 85%
  • 延期提前预警率：提前 ≥ 2 个工作日预警的延期数 ÷ 全部延期数，目标 ≥ 80%
  • 站会准时率：按日程准时召开的站会数 ÷ 应开数，目标 ≥ 90%
  • 台账时效：客户或版本变更到台账更新的时长，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：站会时间和召集人不固定，反复问“站会没、什么时候站会”（约 6 次）；站会定下的延期只在口头说，事后还要在群里解释｜依据：「工程咨询产研」2026-01
  • 现象：关键交付（云端体验版、工程 Agent）没有里程碑看板，要靠临时指定专人催进度，截止日变化只在口头通报｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：多产品并行，需求来自多人，上下文流失，线上沟通差异大只好改成线下说；多维表格管理任务提出后迟迟没有落地｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：同时推进多个客户、四种版本形态，客户、版本、截止日没有统一台账，研发不清楚到底几个客户、几个版本、什么时候要；客户中途换方案，需要临时加班赶工｜依据：「LeapCore（archived）」2026-03、「LeapCore（archived）」2026-04
  • 现象：项目经理缺位时，迭代需求够不够要临时判断，交付日靠同事提醒，进度会邀请漏人，只能临时指定专人“当项目经理催进度”｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 日站会、迭代回顾会、新迭代启动会：三类会议都用飞书日程固定。
  • 项目经理缺位时：由 CTO 指定临时进度负责人，并在群公告中写明“需求和进度找谁、技术咨询找谁、决策分歧找谁”。
  • 多客户多版本（云服务版、硬件+服务版、私有部署版、特供版）：必须使用里程碑台账；Logo 和名称由市场出统一版本，客户定制版由我方切换。
  • 多产品并行收束（MercAll、ClawLite、MerCoder、LeapCore）：按产品分组汇总，每周一次进度同步会。

10. 待确认问题

  • 产研线是否设专职项目经理？目前由产品负责人兼任是否可持续？
  • 站会固定时间和时长是否统一（各线目前 10:20、10:30、14:30 不等）？
  • 里程碑台账与 X-DLV-35 交付台账是否合并？
  • 节点前 2 个工作日、完成度 80% 的预警阈值是否合适？
  • 延期决策权在 CTO 还是进度负责人？
X-PRD-31产品验收待优化180

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：研发完成需求、准备转测试（ready-for-test）前，或新版本上线前，需要产品逐项或逐模块确认实现符合需求（含计费口径和文案）时启动。
  • 负责人：主责——产品负责人（当前：杨萌·推断待确认）；协同——模块产品经理（当前：黄飞鹏、陈震、段涵·推断待确认）、研发负责人（当前：王皓南·推断待确认）、提交验收的研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）、测试负责人（当前：张东郅·推断待确认）、测试（当前：涂维轩、黄霆瑄、潘浩伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 研发自测后附录屏和验收地址，改状态为“待产品验收” → ② 机器人 @ 指定验收人 → ③ 产品按验收标准走查 → ④ 通过：留痕并流转测试 → ⑤ 不通过：评论问题并退回 → ⑥ 技术单改由研发负责人和测试联合验收 → ⑦ 迭代末清点状态 → ⑧ 发版前内测，同步已知问题
  • 交付结果：每张功能工单上都有“验收人 + 结论 + 截图/录屏 + 日期”的留痕；通过的进入测试，不通过的有明确问题清单；发版前有已知问题清单。
  • 状态依据：2026-02 已重新定义“待产品验收”状态并要求录屏，但 2026-01～09 仍有绕过验收直接转测试、留痕散在聊天里、技术单“不知道怎么算通过”、测试反复催验收等问题，约 115 次。

1. 场景判定

  • 触发条件：功能类工单开发完成；新版本（如 LeapNew）要逐模块走查；新产品（如 LeapVPN 后台和客户端）有计费、文案、交互需要确认；版本上线前的内测验收。
  • 典型说法：「需求做完先发截图给产品验收」「这俩还没有产品验收」「产品验收在哪留痕，无法判断」「不知道怎么算通过验收」「先走查出问题，才能过会」
  • 判断问题：要确认的是“做出来的东西是否符合需求和产品预期”吗？是 → 走本流程。要确认“功能有没有缺陷” → 走 RND-39（提测、产品验收与测试验收流转）。
  • 不归本流程管：测试验收与提测流转 → 请走 RND-39；缺陷提报与修复 → 请走 RND-03；正式发版 → 请走 RND-51；UI 设计走查 → 请走 X-PRD-16；计费规则的制定 → 请走 X-PRD-23；更新日志与发布说明 → 请走 X-PRD-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
验收主责 定验收规则，最终判定，迭代末清点 A 产品负责人（当前：杨萌·推断待确认）
模块验收 按需求和验收标准走查，留痕改状态 R 模块产品经理（当前：黄飞鹏、陈震、段涵·推断待确认）
发起验收 自测后附录屏和地址，提交验收 R 研发（当前：岳阳、宋祺睿、吴世豪·推断待确认）
技术单验收 技术类工单与测试联合验收 R 研发负责人（当前：王皓南·推断待确认）
测试衔接 等产品验收通过后测试，提出验收缺失 C 测试负责人（当前：张东郅·推断待确认）；测试（当前：涂维轩、黄霆瑄、潘浩伟·推断待确认）
机器人 @ 验收人，每日推送“待产品验收”清单 R（自动） 飞书机器人（由产品负责人维护规则）
兜底 验收归属争议、发版放行冲突 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 工单号及需求文档中的验收标准（要点清单）
  • 录屏或截图（覆盖主路径和关键边界）
  • 可访问的验收环境地址和测试账号（已部署，不接受本地截图代替部署）
  • 涉及计费的：计费规则文档版本、扣费提示文案和弹窗截图
  • 已知未实现项和原因

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建单时指定“验收人/验收方式”（产品验收/技术联合验收/测试直验） 产品经理 建单时 工单系统 验收归属 🔧飞书固化
2 研发自测后部署到验收环境，附录屏和地址，把状态改为“待产品验收”（录屏和地址为必填，不能从开发直接跳到待测试） 研发 开发完成当日 工单状态机 验收申请 🔧飞书固化
3 机器人 @ 验收人，每日 10:00 推送“待产品验收”清单 机器人 即时 + 每日 飞书机器人 待验收清单 🤖自动化
4 对照验收标准逐项走查，计费类核对规则和提示文案 产品经理 申请后 1 个工作日内 验收环境 走查结果 👤人工判断
5 通过：在工单评论写“产品验收通过 + 日期”，验收人自己改状态为“待测试”，自动通知测试 产品经理 走查当日 工单系统 验收留痕 🔧+🤖
6 不通过：逐条评论问题，退回“开发中”；属于缺陷的进缺陷表 产品经理 走查当日 工单、缺陷表 问题清单 👤人工判断
7 技术类工单（鉴权、后台、基础设施）由研发负责人和测试联合验收，产品不参与 研发负责人/测试 1 个工作日内 工单系统 技术验收结论 👤人工判断
8 迭代末清点需求池状态，列出未验收、验收未通过项 产品负责人 迭代最后 1 个工作日 工作台 验收清点表 🔧飞书固化
9 发版前组织内测验收，输出变更清单和已知问题清单，随发布说明同步 产品负责人/测试负责人 发版前 1 个工作日 反馈群、工单 已知问题清单 🔧+🤖

5. 交付物与模板

  • 交付物：工单验收留痕、问题清单、迭代验收清点表、发版前已知问题清单
  • 建议模板/表单（工单验收字段）：验收人｜验收方式（产品/技术联合/测试直验）｜验收标准（要点清单）｜录屏或截图链接｜验收环境｜验收结论（通过/不通过/部分通过）｜问题清单｜验收日期
  • 走查单（新版本逐模块）：模块｜参考清单项｜与旧版本是否一致｜问题｜截止日｜负责人

6. 异常与升级

  • 研发绕过验收直接改为“待测试” → 测试退回 → 同一人一迭代内 2 次以上，由研发负责人在回顾会通报
  • 产品 1 个工作日内未验收、阻塞测试 → 测试 @ 产品负责人 → 再过 1 个工作日由产品负责人亲自验收或指定代理人
  • 多个产品对同一需求意见不一致 → 以需求文档责任产品为准 → 仍有分歧由产品负责人当日拍板
  • 计费或扣费功能未达规则要求 → 一律不得通过 → 规则本身有疑问时升级 CTO

7. 衡量指标

  • 验收留痕率：有验收字段留痕的功能工单数 ÷ 已关闭功能工单数，目标 100%
  • 验收时长：从“待产品验收”到给出结论的工作日数，目标 ≤ 1 个工作日
  • 一次验收通过率：首次通过数 ÷ 提交验收数，目标 ≥ 70%
  • 验收后被测试打回率：产品通过后测试按“不符需求”打回的比例，目标 ≤ 10%

8. 低效诊断

  • 现象：产品验收结果只在聊天里回复，测试找不到在哪留痕、是谁验收的；验收标准不明，“设计如此”和“这是 bug”反复争论（约 6 次）｜依据：「Leap产研测」2026-07
  • 现象：技术类工单产品无法判断，验收归属不清；验收人没改状态，测试反复问“验了没有”｜依据：「Leap产研测」2026-08、「LeapVPN网络预研」2026-08
  • 现象：研发没部署、没演示就把状态从开发直接改到待测试；状态选项太少，被随意选择；多项需求验收不通过，测试无法推进｜依据：「工程咨询产研」2026-02
  • 现象：验收问题在群里截图零散提出，同一问题多天反复提；前后端互相推诿｜依据：「工程咨询产研」2026-01
  • 现象：产品需求返工率高，两位产品对同一需求意见不一致｜依据：「Leap产研决策部」2026-08
  • 现象：新版本没有同步变更清单，使用者被动发现功能变化；多个客户端并行，未公开发布的版本被误用｜依据：「Leap反馈群」2026-08、「Leap反馈群」2026-09
  • 现象：开发完成后产品才推翻部分设计，计费口径（超量限速还是停用）前后不一致｜依据：「LeapVPN网络预研」2026-08、「LeapVPN网络预研」2026-09

9. 分支变体

  • 小需求（如导出字段单位）：建单时标“测试直验”，由测试按需求直接验收，不单独走产品验收。
  • 技术类工单（云端管理后台、权限鉴权）：研发负责人和测试联合验收。
  • 新版本逐模块走查（如 LeapNew）：产品按参考清单分模块走查，问题挂到走查工单下，设截止日，开会逐项过。
  • 新产品带计费（如 LeapVPN）：管理后台和客户端分开验收；计费规则、风险提示弹窗（首次或每次、冷静期）必须对照规则文档；测试另做安全验收。
  • 客户端并行期（LeapAll 只修 bug，新需求只在 LeapNew 做）：验收前确认目标客户端。

10. 待确认问题

  • 本 SOP 与 RND-39（提测、产品验收与测试验收流转）如何分工：是否以本 SOP 管“产品验收”，RND-39 管“测试验收”？
  • 工单系统能否把“录屏 + 验收环境”设为必填，并限制从开发直接跳到待测试？
  • 产品验收 1 个工作日的时限是否可行？
  • 技术类工单的联合验收是否需要 CTO 确认？
  • 发版前已知问题清单由产品还是测试输出？
X-PRD-32AI 生成质量评测与领域专家验收待新建240

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：字字可研等 AI 报告产品出了新版本或新生成能力（仿写、套模板、先审后生、测算规则），需要工程师、领域专家或客户审核人评价，做双盲对比，或业务规则不明需要领域专家澄清并验收时启动。
  • 负责人：主责——字字可研产品经理（当前：杨萌·推断待确认）；协同——领域专家（当前：王满·推断待确认）、后端研发/方案（当前：王皓南·推断待确认）、测算与功能研发（当前：季学森、陈锦杰、侯怡辰·推断待确认）、外部可研工程师（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 明确评测目标和验收标准 → ② 准备评测样本 → ③ 生成多版本样稿 → ④ 隐去来源做双盲 → ⑤ 专家按评分表打分并写一句话感受 → ⑥ 汇总结论，AI 解析客户修订痕迹 → ⑦ 整改项进缺陷单 → ⑧ 复测，结论归档
  • 交付结果：一份评测结论（各版本得分、优劣、是否达到上线或客户审核标准），一份整改清单（负责人、截止日、复测状态），评测样本和评分表归档后可复用。
  • 状态依据：每次评测都临时发起：没有评分标准，没有双盲机制，没有验收模板和优质案例库。2026-02～07 出现评价多为客套话、该以哪方标准为准不统一、“几个迭代了仍未完成”等问题，约 28 次。

1. 场景判定

  • 触发条件：新生成方案（如换用新的编码 Agent 生成可研）要和现有版本比较；产出要过客户审核人的审核；领域专家要对提示词或 skill 优化结果验收；研发遇到业务规则不明（利率单利还是复利、历史版本保留数等）。
  • 典型说法：「该做双盲测试了」「我想要的是看完说说感受，不是写评测报告」「我分辨不出新写的可研比现在版本好在哪」「等领域专家测试」「明天跟产品确认」
  • 判断问题：要回答的是“生成结果质量好不好、是否达标”吗？是 → 走本流程。要改提示词本身 → 走 X-PRD-25。
  • 不归本流程管：提示词和报告类型配置变更 → 请走 X-PRD-25；评测用案例和数据获取 → 请走 X-PRD-26；底层模型选型评测 → 请走 X-PRD-18；Agent 通用评测集 → 请走 RND-82；业务规则正式定义 → 请走 X-PRD-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
评测主责 定目标和标准，组织评测，出结论 A 字字可研产品经理（当前：杨萌·推断待确认）
领域评审 打分、写感受、澄清业务规则、验收 R 领域专家（当前：王满·推断待确认）
样稿生成 生成多版本样稿，分析差距，提出方案 R 后端研发（当前：王皓南·推断待确认）
规则实现 实现测算和功能规则，更新单测 R 测算与功能研发（当前：季学森、陈锦杰、侯怡辰·推断待确认）
外部评审 有偿外部评审或重做对照稿 C 外部可研工程师（当前：待指定）
兜底 标准分歧、外部评审预算审批 I CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 评测目标：上线判断、方案对比，还是对齐客户审核标准
  • 评测样本：至少 2 个正在做的真实项目（附项目基础信息文件），或已脱敏的历史项目
  • 优质参考案例和客户认可的模板
  • 客户审核人返回的修订稿（带修改痕迹）
  • 评分表（见第 5 节），并约定评审截止日

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 写评测单：目标、对比版本、样本、标准（自定标准或客户审核标准）、截止日 产品经理 发起前 1 个工作日 飞书多维表格 评测单 🔧飞书固化
2 生成各版本样稿（如参考案例仿写版、套模板版、先审后生版），统一附项目基础信息 后端研发 2 个工作日内 测试环境 样稿集 🤖自动化
3 隐去版本来源，编号后分发给评审人 产品经理 样稿出来当日 飞书云盘 双盲样稿 🔧+🤖
4 按评分表打分（准确性、结构、时效、数据一致性、可用性），每项附一句话感受和最大问题 领域专家/外部评审 3 个工作日内 评分表 评分结果 👤人工判断
5 AI 解析客户修订痕迹，生成问题清单，作为对照 产品经理 与步骤 4 并行 修订痕迹解析 Skill AI 问题清单 🤖自动化
6 汇总揭盲，输出评测结论和整改项（提示词/测算/模板/流程） 产品经理 评分收齐后 1 个工作日内 飞书文档 评测结论 👤人工判断
7 整改项进缺陷单，写明负责人、截止日、复测人；业务规则疑问写入 issue 评论，结论当日回写 产品经理/研发 结论当日 缺陷表、Gitea 整改单 🔧+👤
8 整改后由领域专家复测，给出“通过/基本满意/不通过” 领域专家 整改完成后 2 个工作日内 测试环境 复测结论 👤人工判断
9 样本、评分表、结论归档到评测样本库，供下次复用 产品经理 复测后 1 个工作日内 多维表格 评测样本库 🔧飞书固化

5. 交付物与模板

  • 交付物：评测单、双盲样稿、评分结果、评测结论、整改单、评测样本库
  • 建议模板/表单（评分表）：样稿编号｜评审人｜准确性（1-5）｜结构完整（1-5）｜信息时效（1-5）｜数据与测算一致（1-5）｜可直接使用程度（1-5）｜一句话感受｜最大问题｜是否达到客户审核标准
  • 评测单字段：评测编号｜报告类型｜投资类型｜对比版本｜样本｜标准来源｜评审人｜截止日｜结论｜整改单链接

6. 异常与升级

  • 评审意见只有客套话、没有打分 → 退回并要求按评分表补齐 → 2 次仍不合格，由产品经理改约外部评审
  • 自定标准和客户审核标准冲突 → 产品经理先定本轮以哪方为准并写进评测单 → 有争议 1 个工作日内升级 CTO
  • 领域专家单点不可用，超过截止日 2 个工作日 → 启用外部评审或第二名业务人员 → 外部评审预算报 CTO 审批
  • 同一整改建议重复提出 3 次以上仍未执行 → 产品经理在整改单标红并 @ 负责人 → 3 个工作日未处理升级 CTO

7. 衡量指标

  • 评测周期：评测单创建到结论输出的工作日数，目标 ≤ 7 个工作日
  • 评分表完整率：按评分表完整打分的评审份数 ÷ 回收份数，目标 100%
  • 整改闭环率：按期复测通过的整改项 ÷ 整改项总数，目标 ≥ 80%
  • 客户审核一次通过率：首次提交客户审核即通过的报告数 ÷ 提交数，按季度跟踪

8. 低效诊断

  • 现象：新旧生成方案“分辨不出好在哪”，邀请领域人员评价，返回的多是客套话；没有评分标准，提示词版本和生成版本混用｜依据：「鼎慧产研决策部」2026-02
  • 现象：仿写验收缺少四样东西：客户认可模板、验收标准、优质案例、AI 编制流程；以客户审核人标准还是其他用户标准没有统一，“几个迭代了”仍在改｜依据：「鼎慧产研决策部」2026-04
  • 现象：同一整改建议口头告知多次未执行，提示词谁删、谁测说法不一；催进度来自市场侧压力，无留痕｜依据：「鼎慧产研决策部」2026-04
  • 现象：业务规则澄清在私下或口头进行，群里只见结论；提示词和测算规则多次“等领域专家优化”，跨类型提示词混入冲突内容；外部确认迟迟没有回复｜依据：「研发通知」2026-06、「研发通知」2026-07

9. 分支变体

  • 方案对比评测（新生成方式与现有版本）：必须双盲，至少 2 个样本、2 名评审人。
  • 对齐客户审核标准：以客户返回的修订记录为主要依据，由 AI 解析成验收清单，再由人工复核。
  • 报告类型差异：项目建议书、企业投资可研、政府投资可研分开评测；政府投资类和银行融资类可研标准不同，外部评审要先说明适用类型。
  • 测算规则澄清（债务利率、二类费、经营收入等）：领域专家给结论，研发写进 issue 和单测；拿不准的可两种都做，交给用户选择。

10. 待确认问题

  • 评测主责是否为字字可研产品经理？领域专家是否需要备岗，以消除单点？
  • 评分表的五个维度和 1-5 分制是否合适？由谁最终定稿？
  • 本产品的验收标准以客户审核人标准为准，还是以内部标准为准？
  • 外部可研工程师有偿评审的预算和审批流程是否已有？
  • 评测样本库是否与 X-PRD-26 素材台账、RND-82 评测集合并管理？
X-PRD-33产品改版数据迁移与版本切换待新建160

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：产品结构改版（如建议书/可研拆为独立项目类型）或业务体系升级（如会员体系从单俱乐部升级为联盟级、品牌端迁移），需要把存量业务数据迁到新结构并切换到新版本
  • 负责人：主责——所属产品线产品负责人（当前：杨萌（鼎慧/Leap）、段涵（跃玩）·推断待确认）；协同——后端研发（当前：宋祺睿、蒋兴武·推断待确认）、研发核对人（当前：王皓南·推断待确认）、前端（当前：郝智豪、魏小东、陈真炎·推断待确认）、测试（当前：赵伟龙·推断待确认）、知识库数据研发（当前：魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 迁移立项与影响面评估 → ② 产品拍板迁移规则 → ③ 编写迁移方案（含回档/回滚） → ④ 测试环境演练与对账 → ⑤ 抽检验收 → ⑥ 择时生产迁移（灰度） → ⑦ 迁移后对账巡检 → ⑧ 关闭旧逻辑并归档
  • 交付结果：一份经产品签核的《数据迁移方案》、测试与生产两次迁移的数量对账记录、抽检记录、迁移后 7 天巡检报告；新版本切换完成且旧逻辑下线
  • 状态依据：项目类型拆分迁移无迁移方案文档，默认类型规则反复改了 3 次、测试库需回档重跑；会员体系迁移虽有迁移方案文档，但迁移后连续出现登录失败、权益死锁、接口报错等约 6 次救火，缺少回滚、灰度与验收清单，属“出过事故”

1. 场景判定

  • 触发条件：需求评审结论涉及“已有数据要换结构/换归属/换品牌端”；或版本发布说明中出现“旧数据如何处理”未决项
  • 典型说法：「旧数据咋处理来的」「测试环境数据拆了，但好像不全」「会员体系联盟级迁移」
  • 判断问题：新版本上线后，存量客户的历史数据（报告、项目、等级、权益、成长值）是否需要改结构或改归属才能继续使用？迁错是否会影响客户登录、资产或历史成果？
  • 不归本流程管：普通功能的表结构变更和迁移脚本评审 → 请走 RND-34；业务主体/商户迁移、服务器迁移与线上异常数据订正 → 请走 RND-80；生产变更审批与备份灰度通用规则 → 请走 RND-58；上线后整体版本回滚 → 请走 RND-59；行业知识库数据清洗入库 → 请走 RND-84

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品负责人 定迁移范围、默认值与拆分规则，签核方案与验收结果，决定生产迁移窗口 A 所属产品线产品负责人（当前：杨萌、段涵·推断待确认）
迁移执行 写迁移脚本与对账脚本，测试环境演练，生产执行与回档 R 后端研发（当前：宋祺睿、蒋兴武·推断待确认）
核对人 审脚本、核对拆分/迁移结果，评估回滚方案可行性 C 研发核对人（当前：王皓南·推断待确认）
前端迁移 多品牌端、多入口的前端适配与切换 R 前端（当前：郝智豪、魏小东、陈真炎·推断待确认）
测试 按验收清单回归登录、权限、权益、历史数据可见性 R 测试（当前：赵伟龙·推断待确认）
关联数据 知识库等附属数据的同步导入 R 知识库数据研发（当前：魏宗浩·推断待确认）
客户告知 迁移窗口与影响对客户/客服同步 I 客服/售后（当前：待指定）
兜底 规则争议、高风险迁移是否放行 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 改版需求文档或评审结论，写明新旧数据结构对照
  • 迁移范围清单：涉及的表/实体、客户数、记录数（迁移前基线计数）
  • 业务规则：默认值、拆分规则（如“有啥拆啥”还是统一默认某类型）、冲突处理规则，由产品书面确认
  • 测试账号与真实账号的区分名单（哪些是测试数据可删，哪些是客户数据必须保留）
  • 数据库备份或回档点；回滚步骤和预计耗时
  • 影响面评估：登录、权限、权益、计费、报表、对账任务是否受影响

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在迁移登记表新建迁移批次，填写范围、影响面、计划窗口 产品负责人 改版需求评审通过后 2 个工作日内 飞书多维表格 迁移批次记录 🔧飞书固化
2 拍板迁移规则（默认值、拆分、冲突处理），写入方案，不在群聊口头改 产品负责人 登记后 2 个工作日内 迁移方案模板（飞书文档） 规则定稿 👤人工判断
3 编写迁移脚本、迁移前后数量对账脚本与回滚脚本 迁移执行 规则定稿后 3 个工作日内 Gitea 脚本 PR 🤖自动化
4 核对人评审脚本与回滚方案 核对人 PR 提交后 1 个工作日内 Gitea 评审意见 👤人工判断
5 测试环境演练：先备份→跑迁移→对账→抽检；不通过则回档重跑 迁移执行、测试 评审通过后 2 个工作日内 测试环境、对账脚本 演练对账结果 🤖自动化
6 抽检验收：重点抽“多类型都有数据”“跨主体/跨俱乐部”等边界样本，结果填入登记表 产品负责人、测试 演练后 1 个工作日内 飞书多维表格 抽检记录、签核 👤人工判断
7 发布迁移窗口通知（优先周末或低峰），同步客服 产品负责人 生产迁移前 2 个工作日 飞书群/客户通知 迁移通知 🔧飞书固化
8 生产迁移：备份→灰度（先内部或少量客户）→全量→对账 迁移执行 按窗口执行，当日完成 生产环境 生产对账记录 🔧+🤖
9 迁移后 7 天每日对账/巡检报表，异常按第 6 节处理 迁移执行 迁移后连续 7 天 定时报表/机器人 巡检报告 🤖自动化
10 确认无异常后下线旧逻辑与临时同步开关，归档方案与记录 产品负责人 巡检结束后 3 个工作日内 知识库 归档 🔧飞书固化

5. 交付物与模板

  • 交付物：《数据迁移方案》、迁移脚本与回滚脚本、测试/生产对账记录、抽检记录、7 天巡检报告
  • 建议模板/表单：迁移登记表（批次号、产品线、改版需求链接、迁移范围、基线数量、规则摘要、回滚方案、演练结果、抽检结论、生产窗口、执行人、对账结果、遗留问题、状态）
  • 迁移方案模板章节：背景与范围｜新旧结构对照｜业务规则｜测试/真实数据区分｜备份与回滚｜灰度策略｜验收清单（登录、权限、权益、历史数据、报表）｜客户告知｜时间表

6. 异常与升级

  • 测试环境对账数量不一致 → 回档测试库、修脚本重跑，不得带差异进生产 → 升级核对人（当日）
  • 默认值/拆分规则出现分歧 → 停止执行，由产品负责人在方案中重定 → 仍有争议升级创始人兼 CTO（1 个工作日内）
  • 生产迁移后出现登录失败、无权限、接口报错 → 立即止血（关闭新逻辑或回滚）→ 升级产品负责人与兜底人（30 分钟内），按 RND-59 回滚
  • 死锁、重复数据等数据层问题 → 暂停相关定时任务，修复后补对账 → 当日同步测试复核
  • 巡检报表发现等级/权益差异 → 记录到登记表，权益补发或清理须产品负责人人工确认后执行（1 个工作日内）
  • A（升级）说明：迁移方案、窗口与验收由产品负责人拍板；迁移规则经产品负责人重定后仍有争议，或迁移涉及登录、资产等高风险数据需决定是否放行、生产迁移后需回滚时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 迁移对账一致率 = 迁移后计数与预期计数一致的批次数 / 迁移批次数，目标 100%
  • 迁移引发线上事故数 = 迁移后 7 天内因迁移导致的 P0/P1 问题数，目标 0
  • 规则变更次数 = 方案定稿后迁移规则被改的次数，目标 ≤ 1
  • 迁移周期 = 登记到旧逻辑下线的工作日数，目标 ≤ 15 个工作日（复杂体系迁移另定）

8. 低效诊断

  • 现象：迁移规则（默认类型）在执行中反复改动，规则拍板环节缺失，研发边写边问｜依据：「工程咨询产研」2026-01
  • 现象：测试库拆分结果不全，需回档重测，演练前缺备份与对账脚本｜依据：「工程咨询产研」2026-01
  • 现象：账号中测试数据与客户数据混杂，无法判断哪些可以处理，数据重要性口径不一｜依据：「工程咨询产研」2026-01
  • 现象：会员体系迁移后连续出现门禁阻断、联盟字段为空、权益死锁等问题，验收清单与灰度环节缺失｜依据：「跃玩项目组」2026-09、「跃玩项目组」2026-10
  • 现象：配置变更自动同步上线后又改回手动同步，切换策略未在方案阶段评估｜依据：「跃玩项目组」2026-10

9. 分支变体

  • 项目类型拆分（鼎慧字字可研）：重点抽检同一项目下多类型都有内容的样本；附属的测算数据、知识库数据一并迁移
  • 会员体系单俱乐部→联盟级（跃玩）：须先评估登录/门禁、权益、等级、成长值四类影响面；迁移后对账以每日定时报表代替实时告警；同步按钮上线前保留人工确认
  • 品牌端迁移（PeRo→麦特、猩球、弈荟等）：各前端端分别验收，逐端切换，不一次性全量

10. 待确认问题

  • 主责是否按产品线由产品负责人担任，还是统一由研发技术负责人担任？
  • 生产迁移是否强制要求灰度和周末窗口？客户通知由谁发出？
  • 迁移后巡检 7 天是否合适？会员类迁移是否需要更长？
  • 本 SOP 与 RND-34、RND-80 的边界是否认可（本条只管“产品改版引起”的迁移）？
  • 是否已有 PeRo 会员迁移方案文档可作为模板基础？
X-PRD-34功能分批上线、入口隐藏与提审模式待优化144

状态：待优化｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：某功能的依赖（正式合同、发票、渠道系统 API、正式环境密钥）未就绪，或小程序需要过平台审核，需要拆分上线、隐藏入口或开启审核模式，待条件满足后再放开
  • 负责人：主责——产品总监（当前：杨萌·推断待确认）；协同——研发（当前：陈锦杰、魏宗浩、宋祺睿、王皓南·推断待确认）、渠道系统负责人（当前：丁震宇·推断待确认）、小程序前端（当前：郝智豪、魏小东·推断待确认）、测试（当前：张东郅、赵伟龙·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、法务/财务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 上线前依赖检查 → ② 判定拆分/隐藏/审核模式 → ③ 登记功能开关 → ④ 研发隐藏入口或配置审核模式 → ⑤ 验收隐藏效果 → ⑥ 依赖就绪评审 → ⑦ 放开入口并通知 → ⑧ 清理开关
  • 交付结果：一张功能开关清单（每个被隐藏/延后功能的原因、依赖、放开条件、负责人、状态），以及按清单执行的上线版本或提审包
  • 状态依据：已有 feature flag/隐藏入口、小程序 review 配置和存储桶开关文件，但决策靠群聊临时商量（发票关不关、合同隐不隐反复确认），无上线前依赖检查表和提审检查清单

1. 场景判定

  • 触发条件：产品验收时发现部分子功能依赖未完成；上线涉及资金、合同、发票等对外交易功能而依赖方（法务、财务、外部系统）未确认；小程序准备提交微信审核
  • 典型说法：「发票和合同还没好，要分开上线」「那我主分支先把他隐藏掉」「把发票关了」「降低小程序提审时被误判的风险」
  • 判断问题：这个版本里有没有“用户点进去会用不了或会产生对外交易后果”的入口？审核方看到某入口是否可能判定违规？
  • 不归本流程管：小程序/App 提审本身（类目、主体变更、驳回申诉）→ 请走 RND-60；正式发布部署 → 请走 RND-51；线上紧急修复 → 请走 RND-54；风险功能能否做的准入判断 → 请走 X-PRD-17；支付通道与商户开通 → 请走 FIN-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
决策人 判定拆分上线/隐藏/审核模式，定放开条件 A 产品总监（当前：杨萌·推断待确认）
功能研发 主分支隐藏入口、配置开关、放开时回归 R 研发（当前：陈锦杰、魏宗浩、宋祺睿·推断待确认）
技术核对 判断依赖关系（如充值是否依赖渠道系统）与开关实现方式 C 研发技术负责人（当前：王皓南·推断待确认）
外部依赖方 提供渠道系统正式环境密钥、接口就绪确认 R 渠道系统负责人（当前：丁震宇·推断待确认）
小程序前端 审核模式配置、清理 mock、存储桶开关 R 小程序前端（当前：郝智豪、魏小东·推断待确认）
测试 验收隐藏效果（前端不可见、接口不可调用），放开前补测边界项 R 测试（当前：张东郅、赵伟龙·推断待确认）
资质/保证金决策 小程序保证金、认证缴纳时机 A（升级） 跃竞负责人（当前：徐莉·推断待确认）
法务/财务 合同模板、发票口径确认后才允许放开 C 法务/财务（当前：待指定）
兜底 争议裁决 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 本版本功能清单及每项的依赖（内部模块、外部系统、法务/财务确认、正式环境密钥）
  • 依赖就绪状态（已就绪/未就绪/预计日期/负责人）
  • 被隐藏功能的入口位置截图（顶部导航、按钮、菜单）
  • 小程序提审：需屏蔽的敏感入口清单、mock 内容清单、测试账号、隐私协议版本
  • 已有开关方式：feature flag、review 配置、存储桶开关文件路径

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按依赖检查表逐项核对本版本功能依赖 产品总监 发版前 3 个工作日 上线依赖检查表 依赖核对结果 🔧飞书固化
2 对未就绪项判定：延后上线/隐藏入口/审核模式，写明放开条件 产品总监 核对当日 功能开关清单 决策记录 👤人工判断
3 在功能开关清单登记（功能、方式、原因、放开条件、负责人） 产品总监 决策当日 飞书多维表格 开关记录 🔧飞书固化
4 主分支隐藏入口或配置开关；入口和后端接口都需关闭，防止直链访问 功能研发 登记后 1 个工作日内 Gitea、配置中心 开关 PR 👤人工判断
5 验收：确认前端不可见、接口不可调用、无残留文案 产品总监、测试 发版前 1 个工作日 测试环境 验收记录 👤人工判断
6 小程序提审：开启审核模式，隐藏登录、客服、余额、下单等敏感入口，清理 mock 展示，按提审检查表自检 小程序前端 提审前 1 个工作日 review 配置、存储桶开关 提审包与自检记录 🔧+🤖
7 依赖方完成后在清单中标记就绪，产品组织放开前评审（含法务/财务确认） 外部依赖方、产品总监 依赖就绪后 2 个工作日内 功能开关清单 放开决定 👤人工判断
8 放开入口，补测边界项（最小金额、小数位、网银等） 功能研发、测试 放开决定后 2 个工作日内 测试/生产环境 回归记录 👤人工判断
9 通知市场销售与客服：哪些功能已开放 产品总监 放开当日 通知群 开放通知 🔧飞书固化
10 功能稳定后 1 个迭代内删除临时开关代码，清单状态置为关闭 功能研发 放开后 1 个迭代内 Gitea 清理 PR 🤖自动化

5. 交付物与模板

  • 交付物：功能开关清单、上线依赖检查记录、小程序提审自检记录、放开通知
  • 建议模板/表单：功能开关清单（功能名、产品线、开关方式（隐藏/延后/审核模式）、原因、依赖项、依赖负责人、放开条件、预计放开日期、当前状态、放开日期、清理状态）
  • 提审检查表：敏感入口（登录、客服、余额、历史订单、下单）、mock 内容、测试账号、隐私协议、类目与主体、保证金/认证状态

6. 异常与升级

  • 外部依赖（如正式环境密钥）超预计日期 5 个工作日未就绪 → 产品总监催办并重估放开日期 → 升级兜底人
  • 隐藏后发现可通过直链/旧版本访问 → 补接口层关闭，当日修复 → 升级研发技术负责人
  • 合同/发票功能在法务、财务未确认前被要求放开 → 不放开 → 升级兜底人裁决（2 个工作日内）
  • 小程序审核被驳回 → 按 RND-60 处理申诉与整改，同步本清单
  • 保证金/认证提示出现 → 由资质决策人 3 个工作日内书面决定缴纳时机，记入资质台账
  • A（升级）说明：开关决策（拆分/隐藏/审核模式、放开条件）由产品总监拍板；小程序涉及保证金、认证缴纳等资金与资质事项时，拍板权升级到跃竞负责人；外部依赖超期、合同/发票未确认被要求放开或其他争议时，升级到创始人兼 CTO 裁决

7. 衡量指标

  • 依赖检查覆盖率 = 发版前完成依赖检查的版本数 / 发版总数，目标 100%
  • 隐藏泄漏数 = 被隐藏功能被用户访问到的次数，目标 0
  • 开关滞留时长 = 依赖就绪到放开的工作日，目标 ≤ 5 个工作日
  • 小程序一次提审通过率，目标 ≥ 80%

8. 低效诊断

  • 现象：验收阶段才发现发票与合同未完成，上线依赖检查环节前置缺失｜依据：「Leap产研测」2026-08
  • 现象：发票关、充值开、合同隐藏的决定在深夜群聊中多人反复确认，开关决策无单一拍板与记录｜依据：「Leap产研测」2026-08
  • 现象：充值最小额、小数位、网银等边界未测即准备放开，放开前回归环节缺失｜依据：「Leap产研测」2026-08
  • 现象：外部系统正式环境由谁负责不清，依赖方版本落后｜依据：「Leap产研测」2026-08
  • 现象：审核模式规则只出现在开发日报，无提审检查清单；保证金与认证结论停留在群内口头｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-06

9. 分支变体

  • 交易类功能（充值/发票/合同）：放开前必须有财务、法务确认；合同模板确认后才接入
  • 小程序提审模式：跃玩小程序、会员端/星域小程序、弈荟小程序、专属版小程序各自维护 review 配置；主体迁移期间资质与保证金统一由跃竞负责人决策
  • 企业名称自动注入等依赖其他系统数据的功能：同按依赖检查处理

10. 待确认问题

  • 开关决策是否统一由产品总监拍板，跃玩线是否由跃竞负责人拍板？
  • 合同、发票功能放开前，法务与财务的确认人分别是谁？
  • 是否要求所有开关统一用 feature flag 实现，禁止注释代码式隐藏？
  • 小程序资质与保证金到期提醒是否纳入 GEN-14 公司账号证照管理？
  • 临时开关“1 个迭代内清理”是否可行？
X-PRD-35产品发版/内测公告与通知分发待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：新产品或新版本进入内测、公测、正式发布，或计费/会费等规则变更、官网变更、故障停机时，按统一模板和渠道对内（全员、市场、销售）、对外（用户、俱乐部、内测客户）发布公告与安装包/升级通知
  • 负责人：主责——产品发布负责人（当前：杨萌·推断待确认）；协同——运营宣发（当前：李凯·推断待确认）、对外口径审核（当前：常元和·推断待确认）、新媒体运营（当前：李宣昊·推断待确认）、跃竞线对外通知（当前：徐莉·推断待确认）、研发发布（当前：王皓南·推断待确认）、CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发布就绪检查 → ② 定性（内测/公测/正式）与发布时间 → ③ 按模板起草公告 → ④ 口径、福利、保密审核 → ⑤ 按渠道表分发 → ⑥ 统一下载页更新与客户版本登记 → ⑦ 反馈收集与问题跟进
  • 交付结果：审核通过并按渠道发出的公告（内部群、市场/销售群、公众号/推文、俱乐部公告、客户群），统一下载页的最新链接，以及发布记录
  • 状态依据：已有内测公告模板和对内发布习惯；但内测/公测叫法不一、福利写进公告后被叫停、文案发出后紧急修改、发错群、反复问"最新链接是哪个"、发版前需提醒才能准备俱乐部公告

1. 场景判定

  • 触发条件：版本或产品对某一人群开放；计费、会费、支付等规则变化；官网下架/变更；计划停机或故障；内测客户需要新安装包
  • 典型说法：「请大家根据自己的实际情况修改和传播」「你应该发市场群」「定好发版之前提前通知我，我给他们发个公告」「最新的下载链接是哪个」「比较大的新功能更新可走推文」
  • 判断问题：这次变化要让谁知道？是否对外？是否涉及福利、价格或保密信息？
  • 不归本流程管：帮助中心与更新日志内容 → 请走 OPS-03；全员使用推动与反馈收集 → 请走 OPS-05；版本向市场销售的功能培训 → 请走 MKT-16 / SAL-29；对外宣发稿、新闻稿 → 请走 BRD-09；拉新活动方案 → 请走 OPS-13；客户端打包签名 → 请走 RND-52

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品发布负责人 就绪检查、起草公告、选渠道、发布 R 产品总监（当前：杨萌·推断待确认）
CTO 定性内测/公测、确认发布渠道 A CTO（当前：丁震宇·推断待确认）
对外口径审核 对外公告与媒体口径终审 A（对外） COO（当前：常元和·推断待确认）
运营宣发 传播文案、物料、全员转发 R（宣发） 运营负责人（当前：李凯·推断待确认）
新媒体运营 公众号推文 R（推文） 新媒体运营（当前：李宣昊·推断待确认）
跃竞线负责人 俱乐部公告与定向通知 R（跃竞） 跃竞负责人（当前：徐莉·推断待确认）
研发发布 提供正式版链接、发版时间、已知问题 C 研发负责人（当前：王皓南·推断待确认）
CEO 福利口径、发布节奏（如大会发布）拍板 C CEO（当前：邴龙志·推断待确认）
市场、销售、全员 接收并按口径转发 I 各部门

3. 办之前请准备

  • 发布性质（内测/公测/正式）与开放人群
  • 正式版下载链接（确认正式服）、企业连接地址、前置条件（如需连飞连）
  • 使用入口、帮助文档、反馈入口、额度/券码获取方式
  • 福利与额度口径（是否已审批，见 OPS-07）
  • 已知问题与升级方式（OTA/重装）
  • 是否涉密、是否可外发（不得发到 GitHub 等公开平台）
  • 发布渠道表：哪些群、公众号、俱乐部、客户群

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布就绪检查：产品、客服、额度、文档、下载链接 产品发布负责人 发布前 2 个工作日 就绪检查表 检查结果 🔧飞书固化
2 确定发布性质、时间和人群；需配合大会的由 CEO 定 CTO 发布前 2 个工作日 飞书文档 发布决定 👤人工判断
3 发版计划确定后机器人提醒各线准备公告 研发发布 计划确定当天 飞书机器人 提醒消息 🔧+🤖
4 按模板起草对内/对外公告，AI 初稿后人工改写 产品发布负责人、运营宣发 发布前 1 个工作日 公告模板 公告稿 🤖+👤
5 审核：对外口径、福利表述、保密、去除 AI 痕迹 对外口径审核 收稿后 4 小时内 飞书文档评论 审定稿 👤人工判断
6 按渠道表分发（全员群/市场群/销售群/公众号/俱乐部/客户群） 产品发布负责人、新媒体运营、跃竞线负责人 发布当天 飞书群、公众号、后台公告 已发公告 🔧飞书固化
7 更新统一下载页，登记内测客户当前版本 研发发布、产品发布负责人 发布当天 下载页、客户版本表 最新链接、版本台账 🔧+🤖
8 下线过期公告，收集反馈并转 RND-01 产品发布负责人 发布后 3 个工作日内 后台公告管理、反馈表 反馈汇总 🔧飞书固化

5. 交付物与模板

  • 交付物：就绪检查表、公告（对内/对外）、发布渠道记录、统一下载页、客户版本台账
  • 建议模板/表单：
    • 公告模板字段：标题（【内测公告】/【版本更新】/【停机通知】）、产品与版本、开放人群、入口与下载链接、企业地址与前置条件、额度/券码获取、帮助文档、反馈入口、已知问题、保密提醒
    • 发布渠道表：信息类型（版本公告/规则变更/停机/排班）→ 目标群/渠道 → 审核人
    • 客户版本台账字段：客户代号、环境（测试/正式）、当前版本、最近通知日期、是否已 OTA

6. 异常与升级

  • 公告发出后发现口径错误 → 30 分钟内撤回或发更正 → 升级对外口径审核
  • 福利额度未审批写进公告 → 撤回该段，按 OPS-07 审批后再发 → 升级 CTO
  • 发错群或漏发市场/销售 → 当天补发到正确渠道 → 产品发布负责人处理
  • 给内测客户发了测试服版本 → 当天发正确链接并协助重装 → 升级研发发布
  • 发版时间不确定但运营已排期 → 暂缓对外发布 → 升级 CTO 拍板（1 个工作日内）
  • 内容涉密外泄 → 立即删除 → 升级 CTO 与法务（当天）

7. 衡量指标

  • 公告一次通过率 = 发布后无需更正的公告数 / 公告总数，目标 ≥ 95%
  • 提前通知达标率 = 发版前 ≥ 1 个工作日通知到运营/俱乐部的次数占比，目标 ≥ 90%
  • 下载链接询问次数 = 群内询问"最新链接"次数（每月），目标 ≤ 1
  • 发错渠道次数（每月），目标 0

8. 低效诊断

  • 内测/公测口径不一致，公告发出后需事后统一｜依据：「跃迁AI总动员」2026-05
  • 公告发出后发现文案带 AI 痕迹，全站紧急修改｜依据：「跃迁AI总动员」2026-05
  • 福利金额直接写进公告后被叫停；上线日期不定导致运营被动｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 对内发布后才补使用手册，销售不知道需连飞连｜依据：「Leap产研测」2026-06
  • 内测客户索要最新安装包反复询问，测试服与正式服混淆｜依据：「Leap产研测」2026-06
  • 产品更新是否写推文、发给谁没有口径｜依据：「字字可研市场运营」2026-04
  • 发版前需提醒才能准备俱乐部公告，旧公告需手动下线｜依据：「跃玩项目组」2026-07、「跃玩项目组」2026-10

9. 分支变体

  • LeapAll（安装包）与 LeapPPT（网页）：前者按内测发布，后者按公测发布；LeapPPT 面向学生、校园大使、小红书渠道
  • 对内通知：全员群、市场群、销售群三种口径，销售版必须含企业地址和前置条件
  • 内测客户：只发正式服链接，同时登记客户版本台账
  • 跃竞俱乐部：发版前 ≥ 1 个工作日通知运营，公众号或后台公告（可设"可见人群"）发布，个别俱乐部电话沟通
  • 大功能更新：额外走公众号推文，并用企业微信通知重点用户
  • 大会配合发布：发布时间由 CEO 定，提前卡好节点

10. 待确认问题

  • 公告发布主责是否固定为产品总监？对外审核人是否为 COO？
  • 内测/公测/正式发布的定义是否成文？由谁定性？
  • 是否设立固定的"版本公告群"与"售后值班群"，代替临时选群？
  • 统一下载页放官网还是飞书文档？由谁维护？
  • 跃竞线"发版前提前通知"的时限 1 个工作日是否够用？
X-PRD-36产品手册与使用说明维护待优化72

状态：待优化｜证据：有证据（卡片 5 张 / 会话 7 个）｜优先级：频3 × 耗2 × 跨4 × 险3

  • 适用场景：产品发版、新功能开放、客户/渠道索要使用手册，或新产品/硬件交付缺少说明时，维护用户手册、管理员手册、操作说明、授权教程和随机说明书，统一存放在知识库并保证版本一致
  • 负责人：主责——所属产品线产品经理（当前：杨萌（LeapCore/字字可研/MercAll）、段涵与陈雁（跃玩/星域/会员端）·推断待确认）；协同——手册站点开发（当前：魏小东·推断待确认）、产品使用网站（当前：宫经喜·推断待确认）、文档编写研发（当前：邓乾、李铭熙、张康·推断待确认）、销售渠道（当前：闫登辉、王满·推断待确认）、交付（当前：游家豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 发版或索要触发 → ② 确认手册唯一来源 → ③ 起草/更新（AI 草稿） → ④ 研发核对 → ⑤ 产品审核并标注“可外发” → ⑥ 发布到知识库/帮助中心/手册站点 → ⑦ 通知销售客服 → ⑧ 定期巡检
  • 交付结果：每条产品线一套带版本号的手册（用户手册、管理员手册、更新说明），存放在唯一指定的知识库位置，并标注是否可对外分享
  • 状态依据：已有使用手册 wiki、管理员手册、操作手册站点、产品使用网站，且已指定“客户统一发这两份”；但多处并行维护、多在发版后补写，2026-03～10 仍反复出现“有没有更新后的手册”“机器怎么用”

1. 场景判定

  • 触发条件：正式发版且有用户可见变更；客户、渠道、销售索要手册；新产品/新硬件首批交付；运营、测试或新成员需要使用说明
  • 典型说法：「有没有更新后的产品手册」「客户要使用手册统一发这两个」「需要产品使用说明文档了」「leapcore需要一个产品说明书」
  • 判断问题：用户或内部同事是否因为缺少说明而无法自助使用？现有手册是否与当前版本一致？
  • 不归本流程管：版本公告与更新日志发布 → 请走 X-PRD-35；客户安装与连接问题一线支持 → 请走 X-CS-07；知识库空间与权限治理 → 请走 GEN-12；销售话术、案例与竞品材料 → 请走 SAL-15；研发开发者文档 → 由各研发负责人维护

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
手册责任人 指定唯一来源，起草/审核手册，标注可外发 A/R 所属产品线产品经理（当前：杨萌、段涵、陈雁·推断待确认）
研发核对 编写技术类说明（授权、部署、接口），核对操作步骤准确性 R/C 文档编写研发（当前：邓乾、李铭熙、张康·推断待确认）
站点维护 手册站点部署与样式维护 R 手册站点开发（当前：魏小东·推断待确认）
学习站点 产品使用网站与教学视频 R 产品使用网站（当前：宫经喜·推断待确认）
使用方 对外分发只用指定手册，反馈缺失内容 I/C 销售渠道（当前：闫登辉、王满·推断待确认）
交付 硬件随机说明书随货放置 R 交付（当前：游家豪·推断待确认）
兜底 手册归属争议、对外口径 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 本版更新日志或需求/PRD 链接
  • 当前手册唯一来源链接及版本号
  • 目标读者（终端用户/管理员/渠道/内部）与使用场景
  • 环境要求口径（如推荐 2025 及更新版本的 Chrome/Edge/Safari）
  • 截图与操作视频素材（来自测试环境，去除测试数据与内部信息）
  • 硬件说明：开机、联网、扫码激活、访问地址获取方式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发版检查单中“手册更新”项触发文档更新任务 手册责任人 发版当日 飞书任务/机器人 更新任务 🔧飞书固化
2 确认本次修改的唯一来源文档（不新建副本） 手册责任人 任务创建当日 知识库 来源链接 👤人工判断
3 用 AI 根据需求/PRD/更新日志生成手册更新草稿 手册责任人 发版后 2 个工作日内 AI 手册 skill 草稿 🤖自动化
4 研发核对操作步骤、授权与部署说明 研发核对 收到草稿后 1 个工作日内 飞书文档评论 核对意见 👤人工判断
5 审核对外口径，标注“可外发/仅内部”，更新版本号与日期 手册责任人 核对后 1 个工作日内 知识库 定稿手册 👤人工判断
6 同步到帮助中心、手册站点、产品使用网站（从唯一来源发布） 站点维护、学习站点 定稿后 1 个工作日内 帮助中心/站点 线上手册 🤖自动化
7 通知销售、客服与渠道：最新链接与主要变化 手册责任人 发布当日 通知群 通知 🔧飞书固化
8 手册内容同步给产品内置客服/Agent 作为知识来源 研发核对 发布后 2 个工作日内 LeapAgent 配置 内置更新 🤖自动化
9 硬件随机说明书印制/放入包装与帮助中心 交付 首批交付前 交付清单 随机说明书 👤人工判断
10 每月巡检一次手册与线上版本是否一致 手册责任人 每月第 1 周 知识库 巡检记录 🔧飞书固化

5. 交付物与模板

  • 交付物：用户手册、管理员手册、操作说明/授权教程、随机产品说明书、手册目录与版本记录
  • 建议模板/表单：手册登记表（产品线、手册类型、唯一来源链接、版本号、对应产品版本、责任人、可外发标识、最后更新日期、下次巡检日期）
  • 知识库目录规范：产品概述｜用户手册｜管理员手册｜常见问题｜更新日志｜授权与部署说明｜对外介绍

6. 异常与升级

  • 客户拿到旧版手册 → 手册责任人当日发送最新链接，并检查分发渠道是否引用旧副本
  • 同一产品出现多份冲突手册 → 保留唯一来源，其他副本改为跳转链接（3 个工作日内）→ 有争议升级兜底人
  • 新硬件交付时无说明书 → 交付暂附临时说明，手册责任人 5 个工作日内补齐
  • 文档编写任务指派后 3 个工作日无进展 → 手册责任人催办 → 仍未完成升级兜底人
  • A（升级）说明：手册内容与“可外发”标注由手册责任人（所属产品线产品经理）拍板；同一产品多份手册的归属有争议、对外口径存在分歧或文档任务催办后仍未完成时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 手册同步时效 = 发版到手册更新上线的工作日数，目标 ≤ 3 个工作日
  • 手册一致率 = 巡检中与线上版本一致的手册数 / 手册总数，目标 ≥ 95%
  • 索要次数 = 每月群内索要“最新手册/怎么用”的次数，目标逐月下降
  • 唯一来源覆盖率 = 有唯一来源登记的产品线数 / 产品线总数，目标 100%

8. 低效诊断

  • 现象：更新日志、操作手册、产品使用网站、官网多处维护，手册多在发版后补，缺单一来源｜依据：「跃玩项目组」2026-03、「跃玩项目组」2026-07
  • 现象：使用说明需多次催办，多份说明文档分散在群文件，信息归集环节缺失｜依据：「LeapAll（Deprecated）」2026-03、「LeapAll（Deprecated）」2026-04
  • 现象：销售/客户反复询问“有没有更新后的产品手册”，需临时转发指定 wiki｜依据：「Leapcore某工程咨询客户」2026-08
  • 现象：客户希望安装后自带手册，产品内无入口｜依据：「Leapcore某企业客户」2026-07
  • 现象：硬件随货无说明书，外部伙伴与客户反复问“机器怎么用、地址是什么”｜依据：「交付订单通知群」2026-09、「交付订单通知群」2026-10

9. 分支变体

  • 跃玩网页后台、跃玩小程序、星域、会员端各有一套手册，各由对应产品经理负责；星域手册以可部署站点形式发布
  • LeapCore：使用手册与管理员手册两份为唯一对外版本，内置到 Agent 系统提示词
  • MercAll/ClawLite：授权教程、使用说明面向开发者与 C 端用户
  • 硬件随机说明书：软件说明由产品负责，硬件说明由交付负责
  • 新负责人资料检索（产品清单、组织架构、出货表）：以知识库目录与“全员办事找谁”文档为入口

10. 待确认问题

  • 每条产品线的手册责任人是否按上述分配？硬件说明书由谁写？
  • 帮助中心、手册站点、产品使用网站能否以知识库为唯一来源自动同步？
  • “可外发”标识由产品经理单独确认，还是需要市场或法务复核？
  • 是否把“手册更新”加入 RND-50/RND-51 的发版检查单？
X-PRD-37小产品/实验产品快速内测与发布待优化108

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：用 AI 快速做出的小产品/实验产品（如 OPC-MBTI 测评、论文工具、八字等）需要确定目的、评审数据采集需求、内部测试、收集反馈并对内外发布或上架售卖
  • 负责人：主责——小产品产品负责人（当前：杨黔昆·推断待确认）；协同——研发（当前：岳阳·推断待确认）、测试（当前：张东郅·推断待确认）、产品总监（当前：杨萌·推断待确认）、运营宣发（当前：李凯、陈梦琪·推断待确认）、财务（当前：待指定）；决策——CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·部门报送人）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 一页立项（目的、用户、渠道） → ② 需求与数据采集评审 → ③ 研发部署测试链接 → ④ 产品验收+测试过一遍 → ⑤ 清理测试数据、上线前检查 → ⑥ 内测邀请+表单收反馈 → ⑦ 反馈筛选入排期 → ⑧ 对外发布/上架与售后规则
  • 交付结果：一份小产品立项单、一张上线前检查表、一张内测反馈多维表格与排期结果、对外发布物料；付费产品附定价与售后条款
  • 状态依据：2026-04 已形成“测试过一遍→内测邀请→表单收反馈→排期”的做法，但需求目的在开发后才澄清，反馈曾经私信个人，付费上架缺定价审批和售后规则，题库多轮返工

1. 场景判定

  • 触发条件：同事或领导快速做出小产品并准备开源、发群、上架商城；小产品需增加用户数据采集或邮件发送
  • 典型说法：「开源了」「发布的速度一定要快」「反馈建个多维表」「我们做这个产品的最主要的目的能不能再给我强调一下」
  • 判断问题：它是否会被公司外部用户使用、是否收费、是否采集用户信息？若是，必须走本流程的检查与评审
  • 不归本流程管：正式产品研发立项 → 请走 RND-05；正式产品内测与 dogfood → 请走 X-PRD-06；正式产品 PRD 与需求评审 → 请走 X-PRD-13；正式产品定价 → 请走 X-PRD-23；小产品负责人确定与交接 → 请走 X-PRD-40

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
产品负责人 立项单、需求与数据采集方案、验收、内测组织、反馈筛选 R 小产品产品负责人（当前：杨黔昆·推断待确认）
研发 部署测试链接、发信服务评估、修复、上线 R 研发（当前：岳阳·推断待确认）
测试 上线前过一遍主流程，判断有无阻塞 R 测试（当前：张东郅·推断待确认）
产品把关 发布标准把关、反馈表单格式 C 产品总监（当前：杨萌·推断待确认）
目的与资源决策 产品目的、覆盖目标、积分激励、定价 A CEO（当前：邴龙志·推断待确认）、创始人兼 CTO（当前：丁震宇·部门报送人）
宣发 内测邀请与对外宣发 R 运营宣发（当前：李凯、陈梦琪·推断待确认）
财务 付费产品定价与退款口径确认 C 财务（当前：待指定）

3. 办之前请准备

  • 立项单：产品目的（如能力评测、私域留存、引流）、目标用户、上线渠道、是否收费、负责人、里程碑
  • 测试链接与 Gitea 仓库地址
  • 数据采集清单：采集字段（性别、年龄段、方向、邮箱是否可选）、采集时机、用途说明
  • 发信服务：是否需要发邮件，使用公司统一发信服务还是临时方案
  • 题库/内容来源及质量自查结果
  • 备案号、隐私说明、售后条款（付费时）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写一页立项单，由决策人确认目的与优先级 产品负责人 开工前或首个 Demo 后 1 个工作日内 飞书文档模板 立项单 🔧飞书固化
2 需求与数据采集评审：写清目的、采集字段、时机、发信方式；研发评估实现 产品负责人、研发 立项后 2 个工作日内 评审会/文档 评审结论 👤人工判断
3 研发部署测试链接 研发 评审后按里程碑 测试环境 测试链接 🤖自动化
4 产品验收，测试过主流程；“无阻塞使用、无严重影响体验”即可进入内测 产品负责人、测试 链接就绪后 1 个工作日内 测试链接 验收结论 👤人工判断
5 上线前检查：清理测试数据、备案号、隐私说明、内容质量、分享链接 产品负责人 内测前 上线前检查表 检查记录 🔧飞书固化
6 发内测邀请（含重点检查项与反馈表单链接），反馈只走表单不走私信 产品负责人、运营宣发 检查通过当日 公司群/通知群 内测邀请 🔧飞书固化
7 反馈汇总、去重、筛选，形成排期表；采纳的反馈按规则发积分 产品负责人 内测期每 2 个工作日一次 飞书多维表格 排期表、积分记录 🔧+🤖
8 评估内测反响（参与率目标）决定是否对外发布 目的与资源决策 内测满 5 个工作日 多维表格统计 发布决定 👤人工判断
9 付费上架：定价与售后条款经财务确认后上架商城 产品负责人、财务 上架前 2 个工作日 商城后台 上架记录 👤人工判断
10 对外宣发并持续迭代，迭代版本在群内同步 运营宣发、产品负责人 发布决定后按排期 公众号/社群 宣发物料 🔧飞书固化

5. 交付物与模板

  • 交付物：立项单、评审结论、上线前检查表、内测邀请、反馈多维表格与排期表、定价与售后条款
  • 立项单字段：名称、目的、目标用户、上线渠道、是否收费、负责人、研发、里程碑、数据采集需求
  • 反馈表单字段（尽量少）：反馈类型（bug/体验/内容）、描述、截图、联系方式（可选）
  • 上线前检查表：测试数据已清理、备案号在页脚、隐私说明、内容去重与质量自查、分享卡片、数据埋点、售后条款

6. 异常与升级

  • 开发中发现目的不清或需求变更超过 2 次 → 暂停开发，产品负责人 1 个工作日内找决策人重新确认
  • 公司邮箱无法主动发信 → 申请统一发信服务，暂不用个人邮箱 → 升级创始人兼 CTO（2 个工作日内）
  • 内容（题库等）被反馈重复、质量差 → 暂停扩大内测，修订后再发
  • 付费用户要求退款 → 按上架时确认的售后条款处理；条款未覆盖的升级财务与兜底人（1 个工作日内）
  • 采集用户信息涉及合规疑问 → 停止采集，转 X-PRD-17 评估
  • 说明：本流程唯一拍板角色为“目的与资源决策”（产品目的、优先级、是否对外发布、定价与积分激励）；产品负责人负责执行与组织，产品总监只做发布标准把关，不单独拍板

7. 衡量指标

  • 立项到内测周期 = 立项到发出内测邀请的工作日数，目标 ≤ 10 个工作日
  • 内部参与率 = 提交反馈或完成体验的员工数 / 邀请员工数，目标 ≥ 2/3
  • 反馈处理率 = 已判定（采纳/不采纳）反馈数 / 反馈总数，目标内测结束时 100%
  • 需求返工次数 = 立项后需求目的或核心字段变更次数，目标 ≤ 1

8. 低效诊断

  • 现象：小产品先做后问目的，邮件、采集需求反复调整，需求评审环节缺失｜依据：「AI OPC —— MBTI」2026-04
  • 现象：研发无正式发信服务，临时找邮箱方案｜依据：「AI OPC —— MBTI」2026-04
  • 现象：反馈先私信个人，再改表单，表单字段过多又删减｜依据：「AI OPC —— MBTI」2026-04
  • 现象：题库重复感强、多轮调整版本，上线前内容质量自查缺失｜依据：「模态集团（全员群）」2026-02、「模态集团（全员群）」2026-04
  • 现象：付费上架后才说明“不支持退款”，定价与售后规则未事先确认｜依据：「模态集团（全员群）」2026-03

9. 分支变体

  • 免费产品：可跳过步骤 9；对外发布仍需完成上线前检查
  • 付费产品（商城 credit 计价）：定价与售后条款必须经财务确认
  • 专业版（能力评测）与引流版（娱乐向）：数据采集字段与宣发渠道不同，立项单中分别写明
  • 仅内部使用、不对外：可简化为步骤 3～7

10. 待确认问题

  • 小产品的主责是否固定由产品团队指派，还是作者本人兼任？
  • “目的与资源决策”由 CEO 还是创始人兼 CTO 单一拍板？两人意见不一致时以谁为准？
  • 内部参与率 2/3 是否作为对外发布的硬门槛？
  • 积分激励规则（反馈被采纳发积分）由谁审批、是否纳入 HR-18？
  • 公司统一发信服务由谁申请和维护？
  • 虚拟商品统一售后条款是否由财务、法务出模板？
X-PRD-38内部业务系统建设归口与数据主责边界待新建160

状态：待新建｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨5 × 险4

  • 适用场景：内部系统（CRM、渠道系统、合同系统、项目系统、金蝶、运营中台等）新建或扩功能时出现功能重复、数据冲突或多个团队各自建设，需要划定单一数据源和系统边界，统一归口建设并约定数据同步规则
  • 负责人：主责——内部系统归口负责人（当前：丁震宇·推断待确认）；协同——综合部负责人/业财主数据标准（当前：赵雪冰·推断待确认）、总经办（当前：田杰·推断待确认）、内部系统研发负责人（当前：陈子康·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、产品总监（名词统一，当前：杨萌·推断待确认）、需求方（当前：徐莉、陈梦琪、李凯、吴琪、李鹏为、杜中瑞·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 新系统/新功能需求进入统一需求池 → ② 查重与归属判定 → ③ 对照数据主责矩阵 → ④ 边界与同步规则评审 → ⑤ 财务/业务口径书面确认 → ⑥ 指定系统负责人建设 → ⑦ 迁移“先同步、再校验、后停写” → ⑧ 更新矩阵并公告
  • 交付结果：一张《数据主责矩阵》（每类数据的唯一写入系统、同步方向、负责人）、一页“系统职责边界说明”（如 CRM vs 渠道系统）、统一的内部系统需求池
  • 状态依据：“单一数据源、全链条汇集、不重复操作”原则和 CRM/渠道系统边界刚在 2026-09～10 群聊中形成，矩阵与同步规则未成文；渠道需求在 CRM 中重复提出约 6 次，运营中台需求原本多个团队各做各的

1. 场景判定

  • 触发条件：有人提出新建内部系统或在现有系统加模块；同一数据（客户、渠道、合同、订单、收入）在两个系统都能录入；系统数据对不上；两个团队准备做功能相近的工具
  • 典型说法：「定好大平台的主数据标准，保证唯一来源」「CRM 是渠道系统的超集」「机器和算力的精细化管理走渠道系统」「那就不单独招人做重复工作了」「统一一下名词」
  • 判断问题：这条数据/这个功能，公司里是否已有系统在管？如果两边都录，以哪边为准？
  • 不归本流程管：单个系统内部的需求登记与排期 → 请走 X-PRD-09；跨系统接口的技术对接 → 请走 RND-18；CRM 录入规范 → 请走 SAL-04；渠道报备到交付的业务流程 → 请走 SAL-31；收入确认等财务口径本身 → 由财务制度规定

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
归口负责人 判定系统归属与边界，指定系统负责人，维护矩阵 A 内部系统归口负责人（当前：丁震宇·推断待确认）
业财主数据 制定主数据标准，组织业务方评审 R 综合部负责人（当前：赵雪冰·推断待确认）
业务确认 内部系统评审邀请人与业务结论确认 C 总经办（当前：田杰·推断待确认）
系统研发 需求汇集、设计文档、数据同步实现 R 内部系统研发负责人（当前：陈子康·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）
财务口径 书面确认订单区分、应收、算力摊销等口径 R（口径确认） 财务负责人（当前：黄梦婷·推断待确认）
名词统一 系统与模块命名、术语统一 C 产品总监（当前：杨萌·推断待确认）
需求方 提出需求、参与评审与验收 C/I 需求方（当前：徐莉、陈梦琪、李凯、吴琪、李鹏为、杜中瑞·推断待确认）
兜底 跨部门冲突与重复建设叫停 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 需求描述：要解决的业务问题、使用人、涉及的数据对象
  • 现有系统清单及各自已覆盖功能（可查数据主责矩阵）
  • 涉及数据的现状：在哪些系统录入、谁录入、是否已有冲突样例
  • 财务相关口径问题（如机器与算力订单如何区分、何时确认应收、如何摊销）
  • 相关方案文档（如合同及履约管理系统建设方案）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新系统/新模块需求统一提交到内部系统需求池，不在各系统群零散提 需求方 有需求当日 飞书多维表格 需求记录 🔧飞书固化
2 查重：对照现有系统功能与矩阵，标出重复或冲突项 系统研发 提交后 2 个工作日内 需求池、矩阵 查重结论 🤖自动化
3 判定归属：放入哪个系统/是否新建，指定系统负责人 归口负责人 查重后 2 个工作日内 需求池 归属决定 👤人工判断
4 涉及跨系统数据的，起草边界与同步规则（唯一写入方、同步方向、频率、冲突处理） 系统研发、业财主数据 归属后 3 个工作日内 边界说明模板 规则草案 👤人工判断
5 组织评审：业务方、财务、归口负责人参加；评审邀请人由业务确认人定 业财主数据 草案后 5 个工作日内 评审会 评审结论 👤人工判断
6 财务口径书面确认（订单区分、应收、摊销） 财务口径 评审后 3 个工作日内 飞书文档 口径确认 👤人工判断
7 更新数据主责矩阵与系统职责边界说明并公告 归口负责人 确认后 1 个工作日内 飞书多维表格/知识库 矩阵新版本 🔧飞书固化
8 功能迁移按“先同步、再校验、后停写”执行；同步脚本化 系统研发 按排期 同步脚本 迁移记录 🤖自动化
9 旧系统对应功能停写并通知使用人 系统研发 校验通过后 2 个工作日内 通知群 停写通知 🔧飞书固化
10 每季度复核矩阵与系统实际一致性 归口负责人 每季度首月 矩阵 复核记录 👤人工判断

5. 交付物与模板

  • 交付物：数据主责矩阵、系统职责边界说明（每对易混系统一页）、内部系统需求池、同步规则与脚本、评审结论
  • 数据主责矩阵字段：数据对象（客户、渠道、商机、合同、订单、回款、发票、算力消耗、机器）、唯一写入系统、读取/同步系统、同步方向与频率、数据负责人、口径说明、生效日期
  • 内部系统需求池字段：需求名、提出部门、业务问题、涉及数据、查重结果、归属系统、系统负责人、评审状态、优先级

6. 异常与升级

  • 发现两个团队在做相同功能 → 归口负责人 2 个工作日内叫停其一或合并 → 有争议升级 CEO
  • 两系统数据不一致 → 以矩阵中的唯一写入系统为准，另一方修正；矩阵未覆盖的升级归口负责人（1 个工作日内）
  • 财务口径未确认前就上线涉及收入/应收的功能 → 不上线 → 升级财务负责人与 CEO
  • 系统名词不统一引发误解 → 产品总监 3 个工作日内出统一术语并更新矩阵
  • A（升级）说明：系统归属、边界与数据主责矩阵由归口负责人拍板，财务口径由财务负责人书面确认后作为评审输入；两个团队对重复建设的叫停或合并有争议、财务口径未确认却要求上线涉及收入/应收的功能时，拍板权升级到 CEO

7. 衡量指标

  • 矩阵覆盖率 = 已登记唯一写入系统的核心数据对象数 / 核心数据对象总数，目标 100%
  • 重复建设数 = 每季度发现的功能重复系统/模块数，目标 0
  • 跨系统数据差异数 = 每月对账发现的不一致记录数，目标逐月下降
  • 需求归属时效 = 需求提交到归属决定的工作日数，目标 ≤ 4 个工作日

8. 低效诊断

  • 现象：CRM、渠道、合同系统存在重复功能，“同步”与“打通”概念混用｜依据：「公司内FDE」2026-09、「公司内FDE」2026-10
  • 现象：“渠道”在 CRM 与渠道系统口径不同，使用人在 CRM 重复提渠道需求，渠道状态无处显示｜依据：「跃迁CRM反馈群」2026-09
  • 现象：机器测试、算力充值与普通订单的财务区分只在群聊讨论，未成文｜依据：「跃迁CRM反馈群」2026-09
  • 现象：多个团队原本各自规划运营/客服/知识库工具，需求统筹人不明，名词前后不一｜依据：「统一运营平台开发」2026-05
  • 现象：内部系统评审邀请人不清，需临时指定业务确认人｜依据：「公司全员群」2026-09

9. 分支变体

  • 业财系统：CRM/渠道负责前端业务数据，合同系统负责合同审批，金蝶负责财务；系统间按“数据同步”而非“打通”
  • CRM 与渠道系统：标品渠道（含 LeapCore）走渠道系统；非标客户的“渠道介绍”来源留在 CRM；机器测试/使用区分与算力充值摊销走渠道系统
  • 运营中台：鼎慧、生态组、星域运营等需求统一归口一个研发负责人，底层复用 LeapBase；先定目标客户与商业模式再决定纳入 LeapCore 还是 LeapBase 体系
  • 内部提效系统与对外 2B 产品：对外产品化需另走产品立项

10. 待确认问题

  • 内部系统归口负责人是否由创始人兼 CTO 担任，还是由综合部负责人担任？
  • 数据主责矩阵首版由谁起草、何时完成？
  • 算力充值摊销、交付即应收等口径是否已有财务书面规定？
  • 渠道系统与 CRM 的数据同步由哪个系统负责人实现？
  • 运营中台需求池是否并入统一内部系统需求池？
X-PRD-39产品使用数据统计与导出待新建36

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨3 × 险2

  • 适用场景：产品或业务需要用户使用数据（用户数、活跃、使用情况）做分析或汇报，需从后台导出，或把重复的导出固化为后台报表/定时推送
  • 负责人：主责——后端研发（数据导出/报表）（当前：宋祺睿·推断待确认）；协同——产品总监（需求方/口径定义，当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 提交取数申请（口径、范围、用途、截止时间） → ② 判断是否已有报表 → ③ 有则自助导出 → ④ 无则研发导出并保存脚本 → ⑤ 交付结果 → ⑥ 同类需求第 2 次出现即排期固化为后台报表 → ⑦ 开通查看权限
  • 交付结果：按约定口径的统计文件或后台报表/看板，以及可重复执行的导出脚本
  • 状态依据：每次都在群里 @ 研发手工导出，无现成脚本和导出功能，需求方无管理后台权限，导出范围（单客户还是全部用户）前后不一致，2026-01 一天内催办多次

1. 场景判定

  • 触发条件：需要用户统计、使用情况数据用于汇报、复盘、客户沟通或运营分析
  • 典型说法：「后台用户数据统计能导出一份吗」「能导出吗今天」「没有现成的脚本吗」
  • 判断问题：要的数据后台是否已有页面或报表能自己导？是否涉及用户个人信息？
  • 不归本流程管：运营数据看板与统计口径体系建设 → 请走 OPS-17；业务规则与指标口径定义 → 请走 X-PRD-14；计费与账单对账 → 请走 RND-70

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据导出 评估、导出、保存脚本、固化报表，对交付结果负责 R/A 后端研发（当前：宋祺睿·推断待确认）
需求方 写清口径与用途，验收数据，提出固化需求 R（口径定义与验收） 产品总监（当前：杨萌·推断待确认）
权限审批 管理后台查看/导出权限开通、个人信息明细导出审批、延期争议处理 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）
使用人 运营、管理层等使用统计结果 I 运营/管理层（当前：待指定）

3. 办之前请准备

  • 指标与口径：统计哪些字段（注册数、活跃数、调用次数、消耗等），活跃如何定义
  • 范围：全部用户还是某个客户/企业；是否排除测试账号与内部账号
  • 时间区间与截止时间
  • 用途：内部汇报/对外提供（对外需脱敏）
  • 是否会定期需要（每周/每月）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用取数申请表提交需求（口径、范围、用途、截止时间） 需求方 需要前至少 1 个工作日 飞书表单 取数申请 🔧飞书固化
2 判断后台是否已有报表；有则告知需求方自助导出 数据导出 收到申请后 2 小时内 管理后台 回复 👤人工判断
3 无报表时编写导出脚本，排除测试/内部账号后导出 数据导出 申请后 1 个工作日内 数据库、脚本 统计文件 🤖自动化
4 脚本提交到仓库并登记在取数申请中，便于复用 数据导出 导出当日 Gitea 脚本 🤖自动化
5 交付统计文件，注明口径和数据截止时间 数据导出 导出当日 飞书云文档 交付物 🔧飞书固化
6 需求方核对口径，确认可用 需求方 收到后 1 个工作日内 — 验收 👤人工判断
7 同类需求第 2 次出现，排期做后台导出按钮或定时推送到多维表格 需求方、数据导出 第 2 次出现后进入下个迭代 需求池、机器人 后台报表 🔧+🤖
8 为需求方开通后台只读/导出权限 权限审批 报表上线后 1 个工作日内 管理后台 权限 👤人工判断

5. 交付物与模板

  • 交付物：统计文件（含口径说明）、导出脚本、后台报表或定时推送
  • 取数申请表字段：申请人、产品线、指标清单、口径说明、用户范围、是否排除测试账号、时间区间、用途（内部/对外）、截止时间、是否周期性、处理人、交付链接、脚本链接

6. 异常与升级

  • 口径不清（如只含单客户还是全部用户）→ 数据导出 2 小时内向需求方确认，不按猜测导出
  • 截止时间前无法交付 → 提前告知并给出时间 → 需求方可升级兜底人
  • 涉及手机号、邮箱等个人信息 → 默认脱敏；需明细须兜底人审批
  • 需求方无后台权限 → 按步骤 8 申请，不借用他人账号
  • A（升级）说明：日常取数由数据导出人（后端研发）对交付负责；开通管理后台查看/导出权限、导出含手机号/邮箱等个人信息的明细、截止时间无法交付需裁定优先级时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 取数交付时效 = 申请到交付的工作时长，目标 ≤ 1 个工作日
  • 重复手工导出次数 = 同类需求未固化而重复手工导出的次数，目标 ≤ 1
  • 自助率 = 需求方自助导出次数 / 取数总次数，目标逐季提升

8. 低效诊断

  • 现象：每次导出都在群里 @ 研发手工处理，同日多次催办，无现成脚本｜依据：「鼎慧产研决策部」2026-01
  • 现象：上次只导出单个客户的数据，这次要全部，范围口径未在申请时写清｜依据：「鼎慧产研决策部」2026-01
  • 现象：需求方没有管理后台权限，只能依赖研发｜依据：「鼎慧产研决策部」2026-01

9. 分支变体

  • 全部用户统计 vs 单个客户统计：单客户数据对外提供时需脱敏并经产品确认
  • 内部汇报 vs 客户汇报：客户汇报只提供该客户自己的数据

10. 待确认问题

  • 各产品线管理后台的查看/导出权限由谁审批？
  • 常用指标（注册、活跃、调用、消耗）是否可直接纳入 OPS-17 的数据看板？
  • 导出脚本统一放在哪个仓库？
  • “第 2 次即固化”的规则是否可行？
X-PRD-40产品/研发岗位工作交接待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频3 × 耗4 × 跨4 × 险3

  • 适用场景：产品负责人将缺席迭代、人员调岗、新人接手，或小产品中途换负责人时，需要按交接清单移交需求、反馈、代码与资料，并经带教确认接手人能独立工作
  • 负责人：主责——交出方直属负责人（当前：产品线杨萌、研发线宋祺睿·推断待确认）；协同——交出人、接手人、研发技术负责人（当前：王皓南·推断待确认）、人事（当前：黄莹·推断待确认）、小产品接手人（当前：岳阳、杨黔昆·推断待确认）、需求发起方（当前：邴龙志·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 确认交接事项与接手人 → ② 交出人按清单写交接文档 → ③ 打包仓库/账号/资料 → ④ 交接会议（文档+当面） → ⑤ 带教期跟做 → ⑥ 接手人独立完成一项任务 → ⑦ 三方确认交接完成 → ⑧ 公告并更新职责表
  • 交付结果：一份经交出人、接手人、直属负责人三方确认的交接文档（含职责、需求池、反馈分流、仓库、环境、账号、待办、联系人），以及更新后的职责分工表
  • 状态依据：交接反复发生但每次临时商量，“文档为主”还是“会议为主”意见不一，出现接手人拿不到旧版资料、做过的事无人记得、基座知识集中在一人等情况，2026-02～07 约 20 次讨论

1. 场景判定

  • 触发条件：产品或研发人员调岗、请长假、缺席一个以上迭代；新人接手某产品线/客户端/基座模块；小产品负责人更换
  • 典型说法：「还是要有明确的交接和信息收口」「没啥交接的，进来干活就行了」「每次交接都感觉在另起炉灶」「没有实际责任人是这样的」
  • 判断问题：交出人离开后，接手人是否能在不问交出人的情况下继续推进其需求、反馈和代码？
  • 不归本流程管：研发工单释放、代码/环境/账号的技术交接细则 → 请走 RND-85；离职手续与资产回收 → 请走 HR-27；调岗汇报线确认 → 请走 HR-25；运营岗位交接 → 请走 OPS-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交接组织 确定接手人、交接范围与截止日，签核交接完成 A 交出方直属负责人（当前：产品线杨萌、研发线宋祺睿·推断待确认）
交出人 写交接文档、打包资料、参加交接会、带教期答疑 R 交出人（当前：按实际）
接手人 阅读文档、跟做、独立完成验证任务、确认接收 R 接手人（当前：按实际；小产品为岳阳、杨黔昆·推断待确认）
技术把关 研发交接中代码、环境、知识单点的核对 C 研发技术负责人（当前：王皓南·推断待确认）
人事 调岗/离岗的组织变更与时间节点 I/C 人事（当前：黄莹·推断待确认）
需求发起方 小产品目标、责任人确认 C 需求发起方（当前：邴龙志·推断待确认）
兜底 接手人争议、单点知识风险处置 A（升级） 创始人兼 CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 交出人负责的产品线/模块/客户清单
  • 需求池中本人负责的需求及状态、待评估需求
  • 反馈分流规则与正在处理的反馈、badcase
  • 代码仓库、环境、账号、密钥存放位置（只写位置，不写明文）
  • 进行中待办、截止日期、外部联系人（岗位/单位，不含私人联系方式）
  • 已有文档：产品交接文档、研发团队分工文档、任务清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认交接范围、接手人、交接截止日，在群内公告“谁接什么” 交接组织 得知调岗/缺席后 1 个工作日内 飞书群/任务 交接任务 🔧飞书固化
2 按交接清单模板写交接文档，可用 AI 根据群聊/工单生成初稿后本人确认 交出人 确认后 3 个工作日内 飞书文档 + AI 交接文档 🤖自动化
3 打包仓库、题库、素材、链接、账号位置，转移文件与文档所有权 交出人 与步骤 2 同期 知识库、Gitea 资料包 🔧+👤
4 召开交接会议（文档+当面），逐项过需求、反馈、待办、单点知识 交接组织 文档完成后 2 个工作日内 会议 会议纪要 👤人工判断
5 需求池、工单、反馈群值班的负责人字段改为接手人 交出人 会议当日 需求池、工单系统 负责人变更 🔧飞书固化
6 带教期：接手人跟做（如带着理一次需求、做一次评审） 交出人、接手人 1～2 周 — 带教记录 👤人工判断
7 接手人独立完成一项验证任务（独立理需求/修一个问题） 接手人 带教期结束前 — 验证结果 👤人工判断
8 三方确认交接完成；交出人保留 2 周答疑 交接组织 验证通过后 1 个工作日内 交接文档签核 确认记录 🔧飞书固化
9 更新职责分工表与“办事找谁”文档；区分对外公开版和内部版 交接组织 确认后 1 个工作日内 知识库 新版分工表 🔧飞书固化

5. 交付物与模板

  • 交付物：交接文档、资料包、交接会议纪要、三方确认记录、更新后的职责分工表
  • 交接清单模板字段：职责范围｜产品线与客户｜需求池（负责需求与状态）｜反馈分流与在办反馈｜研发机制（迭代、验收、发版）｜仓库与环境｜账号与权限位置｜进行中待办与截止日｜单点知识说明｜联系人（岗位）｜遗留风险
  • 小产品补充字段：立项目标、目标用户、上线渠道、旧版链接、代码、题库、内测评价人

6. 异常与升级

  • 交出人截止日前未完成交接文档 → 直属负责人催办；离岗日前仍未完成升级兜底人
  • 接手人不明确或多人推诿 → 直属负责人 1 个工作日内指定 → 有争议升级兜底人
  • 发现某知识只有交出人掌握且无文档 → 列为单点风险，安排专项录屏/文档，2 周内补齐
  • 接手人带教期结束未通过验证任务 → 延长带教 1 周，并由直属负责人评估是否换人
  • 岗位定位不清（如运营还是产品）→ 先由直属负责人与人事确认岗位，再交接
  • A（升级）说明：交接范围、接手人和交接完成签核由交出方直属负责人拍板；交出人离岗日前仍未完成交接、接手人指定有争议、发现单点知识风险需专项处置时，拍板权升级到创始人兼 CTO

7. 衡量指标

  • 交接完成时效 = 确定接手人到三方确认的工作日数，目标 ≤ 10 个工作日
  • 交接文档覆盖率 = 有三方确认交接文档的交接次数 / 交接总次数，目标 100%
  • 交接后追问次数 = 交接确认后 1 个月内接手人回问交出人的次数，目标 ≤ 5
  • 需求断档数 = 交接期间被遗漏或评审后无人跟进的需求数，目标 0

8. 低效诊断

  • 现象：交接要多细意见不一，有时只交文档、有时只开会，缺统一交接清单｜依据：「鼎慧产研决策部」2026-07
  • 现象：谁接哪块工作反复讨论，模块先由谁接再派给谁不清楚｜依据：「鼎慧产研决策部」2026-07
  • 现象：做过的工作无人记得、代码难以理解，基座知识集中在一人，单点知识缺记录｜依据：「鼎慧产研决策部」2026-07
  • 现象：带教接手人前岗位定位不清，已评审的需求后续无人跟进｜依据：「鼎慧产研决策部」2026-02
  • 现象：小产品长期无实际责任人，换人后拿不到旧版资料，交接“另起炉灶”｜依据：「AI OPC —— MBTI」2026-04

9. 分支变体

  • 产品→产品：重点交需求池、反馈分流、验收与发版口径
  • 研发→研发：重点交仓库、环境、在办工单，按 RND-85 补技术细则
  • 小产品换负责人：先补立项单（目标用户、上线渠道、里程碑），再交资料包；进度 1～2 天一报
  • 分工文档：对外公开版去掉“骨干”等内部措辞，内部版保留详细分工

10. 待确认问题

  • 主责是否统一为交出方直属负责人？研发线直属负责人是谁？
  • 带教期 1～2 周、交出人答疑 2 周是否可行？
  • 是否以现有产品交接文档为模板基础？
  • 小产品负责人更换是否需要需求发起方书面确认？
  • 本 SOP 与 RND-85 是否合并为一条“产研岗位交接”？
X-PRD-41私有化版本支持策略与旧版本停止维护待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：LeapCore 等产品同时存在多个私有化/一体机/信创/行业版客户版本时，明确支持哪些版本、维护多久、何时强制升级、何时停止修复，并对内对外公布
  • 负责人：主责——产品总监（当前：待指定）；协同——研发负责人、交付负责人、售后负责人、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 统计在网版本分布 → ② 制定支持策略（如支持最近 N 个大版本）→ ③ 评审发布 → ④ 版本到期前通知 → ⑤ 推动升级 → ⑥ 停止维护 → ⑦ 例外审批
  • 交付结果：版本支持策略文档、在网版本分布表、停止维护通知
  • 状态依据：已有 X-PRD-12（跨版本线能力同步）、X-DLV-32（已交付机升级与回退）覆盖部分环节，本条补齐私有化版本的支持期限与停止维护策略（推断）

1. 场景判定

  • 触发条件：大版本发布；季度版本盘点；客户在旧版本上报缺陷要求修复
  • 典型说法：「这个客户还在老版本，要不要给他单独修」「老版本还要维护多久」
  • 判断问题：客户所用版本是否仍在支持期内？
  • 不归本流程管：具体升级操作 → 请走 X-DLV-32、RND-53；产品/功能整体下线 → 请走 X-PRD-42；跨产品线能力同步 → 请走 X-PRD-12；研发侧版本生命周期表登记与补丁范围执行 → 请走 RND-91（本流程负责对外支持策略与客户例外审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
策略负责人 制定与发布支持策略、审批例外 A 产品总监（当前：待指定）
研发 评估各版本维护成本、执行 hotfix C 研发负责人（当前：待指定）
交付/售后 提供在网版本分布、推动客户升级 R 交付负责人、售后负责人（当前：待指定）
销售 通知客户、处理商务影响 C 客户对接销售（当前：待指定）

3. 办之前请准备

  • 在网实例版本分布（X-DLV-31 台账、OTA 数据）
  • 各版本差异与升级路径
  • 合同中关于升级与维护的承诺

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 统计在网版本分布 交付负责人 每季度首周 台账/OTA 后台 版本分布表 🤖自动化
2 拟定支持策略（支持版本数、维护期、安全修复期） 产品总监 首次制定 2 周内，之后随大版本更新 文档 策略草案 👤人工判断
3 研发、交付、销售评审后发布 产品总监 草案后 1 周内 评审会 支持策略 👤人工判断
4 停止维护前 90 天通知客户与渠道 售后负责人、客户对接销售 到期前 90 天 客户群/邮件 通知记录 🔧飞书固化
5 制定升级计划并推动客户升级 交付负责人 到期前 X-DLV-32 升级计划 👤人工判断
6 到期后旧版本只做安全修复或不再修复 研发负责人 到期日 工单 维护状态更新 🔧飞书固化
7 例外申请（客户无法升级）审批并评估收费 产品总监 收到后 3 个工作日内 飞书审批 例外结论 👤人工判断

5. 交付物与模板

  • 交付物：版本支持策略、版本分布表、停止维护通知、例外台账
  • 建议模板/表单：版本支持表（产品、版本号、发布日期、支持状态〔全面支持/仅安全修复/停止维护〕、维护截止日、在网实例数、升级路径）

6. 异常与升级

  • 合同承诺长期维护某版本 → 按合同执行并计入例外 → 升级产品总监
  • 客户网络隔离无法升级 → 安排离线升级包（X-DLV-23）→ 升级交付负责人
  • 旧版本出现高危安全漏洞 → 无论是否到期均评估修复 → 升级研发部门报送人（当天）

7. 衡量指标

  • 支持期内版本覆盖的在网实例占比，目标 ≥ 90%
  • 同时维护的版本数，目标 ≤ 策略上限
  • 旧版本专项修复工时占比，目标逐季下降

8. 低效诊断

  • 聊天中未见相关流程，存在多版本并行维护拖垮研发、客户无限期停留旧版本、对客承诺不一的风险（推断）

9. 分支变体

  • 信创版、行业版、白牌版：可单独约定支持期，但需在策略中列明
  • 渠道客户：由渠道转达通知

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 支持最近几个大版本合适？
  • 销售合同中是否已承诺升级/维护期限？
  • 停止维护后是否提供付费延长支持？
X-PRD-42产品/功能下线（EOL）与停服通知待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：公司决定停止某个产品、产品线、站点或付费功能（含实验产品、分站、旧网关、套餐）时，评估影响、制定迁移与退款方案、提前通知用户并有序下线
  • 负责人：主责——产品总监（当前：待指定）；协同——研发负责人、运营负责人、售后负责人、法务专员、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 下线提议 → ② 影响评估（用户、付费、合同、数据）→ ③ 决策 → ④ 迁移/退款方案 → ⑤ 提前公告 → ⑥ 停止售卖 → ⑦ 停服下线 → ⑧ 数据处置与资源释放
  • 交付结果：下线决策记录、对外公告、迁移/退款完成记录、资源释放记录
  • 状态依据：已有 X-PRD-33（改版数据迁移）、X-CS-16（服务迁移中的账号与余额迁移）、RND-17（技术侧下线报备）覆盖部分环节，本条补齐产品/功能下线的影响评估、停服公告与退款收尾（推断）

1. 场景判定

  • 触发条件：产品/功能使用量低、成本高、战略调整、合规要求、被新产品替代
  • 典型说法：「这个站点还要不要继续维护」「这个功能没人用，直接下了吧」
  • 判断问题：是否有付费用户、合同客户或未用完的额度/卡密受影响？
  • 不归本流程管：版本停止维护 → 请走 X-PRD-41；功能分批上线与隐藏 → 请走 X-PRD-34；单个客户服务终止 → 请走 X-CS-29；产品改版的存量数据迁移 → 请走 X-PRD-33；迁移中的客户账号与余额迁移 → 请走 X-CS-16；研发侧删改功能、下线接口的报备 → 请走 RND-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
下线负责人 影响评估、方案、推进到关闭 A/R 产品总监（当前：待指定）
研发 停止售卖、下线、数据处理、资源释放 R 研发负责人（当前：待指定）
运营/售后 公告、用户答疑、迁移协助 R 运营负责人、售后负责人（当前：待指定）
法务 审核公告、合同与用户协议影响 C 法务专员（当前：待指定）
财务 退款与未消耗额度处理 C 财务专员（当前：待指定）
管理层 下线决策 I 部门负责人（当前：待指定）

3. 办之前请准备

  • 用户数、活跃度、付费用户与剩余额度、合同客户清单
  • 替代产品或迁移路径
  • 用户协议中关于停服的条款
  • 关联的域名、服务器、上游账号、支付商户清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交下线提议与数据 产品总监 — 文档 下线提议 👤人工判断
2 影响评估（用户、收入、合同、数据、依赖） 产品总监、研发负责人 提议后 5 个工作日内 后台/台账 影响评估 🤖+👤
3 决策并记录（CEO-04） 管理层 评估后 1 周内 会议 决策记录 👤人工判断
4 制定迁移、退款、数据导出方案 产品总监、财务专员、法务专员 决策后 1 周内 文档 下线方案 👤人工判断
5 对内同步销售/市场/客服，对外公告（建议提前 30 天） 运营负责人 停服前 30 天 站内信/邮件/群 公告 🔧飞书固化
6 停止新购与续费 研发负责人 公告当天 后台 售卖关闭 👤人工判断
7 协助迁移、处理退款 售后负责人、财务专员 公告期内 后台 迁移/退款记录 🤖+👤
8 停服下线，处置数据，释放域名/服务器/账号/商户 研发负责人 停服日后 10 个工作日内 云平台 资源释放记录 👤人工判断

5. 交付物与模板

  • 交付物：影响评估、下线决策、公告、迁移/退款记录、资源释放清单
  • 建议模板/表单：下线方案（产品/功能、原因、受影响用户数、付费用户数、剩余额度、合同客户、替代方案、公告日、停售日、停服日、退款口径、数据处置方式、需释放资源清单、负责人）

6. 异常与升级

  • 合同客户不同意停服 → 评估继续服务至合同到期或补偿 → 升级管理层（1 周内）
  • 用户集中投诉或舆情 → 统一口径答复，必要时延期 → 升级产品总监与法务（当天）
  • 资源释放遗漏导致持续扣费 → 补释放并核对账单（X-SEC-22）→ 升级研发负责人

7. 衡量指标

  • 公告提前天数，目标 ≥ 30 天
  • 退款/迁移完成率（停服日前），目标 100%
  • 下线后 30 天内遗留资源数，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在直接关站导致付费用户投诉、未用额度无法退还、服务器与域名持续扣费的风险（推断）

9. 分支变体

  • 内部/实验产品（无外部用户）：简化为内部通知 + 资源释放
  • 第三方商城上架的商品：需同步商城下架与卡密处理（OPS-11、OPS-10）

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 下线决策由谁拍板？
  • 剩余额度/卡密的退款口径？
  • 公告提前期 30 天是否合适？

X-DLV 项目交付 / 实施

报送人：待定 · 归属待定 · 42 条 · 已有 0 / 待优化 18 / 待新建 24
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-DLV-01一体机硬件配置咨询、配置单与报价客户、销售或渠道询问 LeapCore 一体机/服务器的配置、席位并发与价格，或客户要求扩容（存储/内存/多办公点）需要重新出配置与报价时启动。主责——硬件配置与采购工程师（当前：杨明学·推断待确认）；协同——研发负责人（配置审核，当前：王皓南·推断待确认）、交付/产品负责人（售价核定，当前：杨萌·推断待确认）、后端运维（软件容量口径，当前：杨云峰·推断待确认）、销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交配置需求 → ② 套标品配置 → ③ 非标技术评估 → ④ 供应商询价核成本 → ⑤ 核定售价 → ⑥ 审核出配置单 → ⑦ 签约前报价-合同-BOM 三方核对 → ⑧ 归档与版本更新经审核、带版本号的配置单（含 BOM、成本、售价、报价有效期），写入合同附件且与采购 BOM 一致待优化192
X-DLV-02硬件供应商选型、BOM 与采购补货演示/交付需要新机型，或库存将尽、销量预测上升需要补货，或现有供应商成本偏高、起订量/供货受限需要新增供应商或自组装时启动。主责——硬件采购工程师（当前：杨明学·推断待确认）；协同——销售负责人（供应商商务谈判，当前：李鹏为·推断待确认）、交付/产品负责人（需求节奏，当前：杨萌·推断待确认）、销售（供应商对接，当前：闫登辉、杨朋伟·推断待确认）、交付部署工程师（到货装机，当前：游家豪·推断待确认）、财务（打款，当前：待指定）；决策——CEO（下单数量与金额，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 补货/选型需求 → ② 选型与 BOM → ③ 询比价（≥3 家）→ ④ 商务谈判 → ⑤ 采购评审与审批 → ⑥ 签约下单打款 → ⑦ 排期与到货跟踪 → ⑧ 到货验收入库经审批的采购单与供应商合同、留痕的询比价记录、按期到货并验收入库的设备待新建300
X-DLV-03硬件库存与资产台账维护硬件采购入库、在产、待交付、已交付、自用、租出、赠送、回收，或在公司/机房/客户处之间上下架运输时，统一更新库存与资产台账及看板。主责——交付部署工程师（库存管理员，当前：游家豪·推断待确认）；协同——硬件采购工程师（采购与到货，当前：杨明学·推断待确认）、交付/产品负责人（交付表与看板，当前：杨萌·推断待确认）、后端运维（渠道系统库存接入，当前：宋祺睿·推断待确认）、财务（资产对账，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 到货入库登记 → ② 状态流转登记 → ③ 关联订单/客户 → ④ 出库与运输记录 → ⑤ 回收入库 → ⑥ 每周盘点与看板更新 → ⑦ 每月与财务对账一张以设备序列号为主键、与订单和客户关联的库存/资产台账，以及按机型、按状态拆分的库存看板待优化192
X-DLV-04出货排期、机器调配与延期通知多个订单抢机、库存不足、供应商延期或硬件故障，需要决定发货优先级与机器分配、处理销售预定留机、向销售/客户发出延期或承诺变更通知时启动。主责——交付/产品负责人（排期统筹，当前：杨萌·推断待确认）；协同——硬件采购工程师（库存与到货，当前：杨明学·推断待确认）、交付部署工程师（装机部署，当前：游家豪·推断待确认）、销售负责人（发货报备、先款后货特批、承诺变更，当前：李鹏为·推断待确认）、销售（当前：杨朋伟、杜中瑞、刘昱潇·推断待确认）、模型网关研发（压测，当前：柯逸飞·推断待确认）；决策——CEO（库存优先原则，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 每周排期会更新库存与到货 → ② 新订单可交性评估并回复交付日 → ③ 按优先级分配机器 → ④ 预留/调拨/回收 → ⑤ 发货前席位与收款核对 → ⑥ 延期或承诺变更判定 → ⑦ 通知销售与客户 → ⑧ 回写台账每台机器有明确的订单归属与承诺交付日；延期与承诺变更有审批记录和书面通知待新建300
X-DLV-05样机/演示机借用与演示环境管理销售、渠道、展会需要借用龙智/源核等样机或演示机，或需要配置高质量演示环境（演示、跑分、送检）时启动；不属于正式交付。主责——样机管理员（当前：汪家诺·推断待确认）；协同——销售负责人（审批与特批，当前：李鹏为·推断待确认）、硬件运维（参展/外借出库，当前：杨明学·推断待确认）、交付部署工程师（借用栏与库存关联，当前：游家豪·推断待确认）、销售运营（SOP 维护，当前：韩诗琪·推断待确认）、测试负责人（演示环境，当前：张东郅·推断待确认）、交付/产品负责人（当前：杨萌·推断待确认）；特批——CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）① 判定借用类型 → ② 提交借用审批 → ③ 审批/特批 → ④ 确认库存并配置演示环境 → ⑤ 出库交接登记 → ⑥ 到期提醒 → ⑦ 归还验收 → ⑧ 台账更新每台样机有审批记录、借用人、预计与实际归还日；演示机按统一“豪华演示版”配置可用待优化96
X-DLV-06展会与大型活动现场设备保障展会、会场演示，或数百人同时使用 LeapCore 的培训/发布活动，需要准备设备、现场网络和并发容量时启动。主责——硬件与 IT 运维（当前：杨明学·推断待确认）；协同——交付/产品负责人（方案决策，当前：杨萌·推断待确认）、销售（现场演示，当前：闫登辉·推断待确认）、行政（会场网络对接，当前：侯明月·推断待确认）、交付部署工程师（打包运输，当前：游家豪·推断待确认）、CTO（容量评估，当前：丁震宇·推断待确认）、CEO（冗余标准，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 活动登记（T-14）→ ② 容量与设备评估（T-10）→ ③ 会场网络确认（T-7）→ ④ 硬件就位联调（T-7～T-3）→ ⑤ 降级预案与清单确认（T-3）→ ⑥ 打包运输（T-1）→ ⑦ 现场保障 → ⑧ 回收复盘（T+1）签核的现场保障清单（设备、网络、降级预案、负责人），活动顺利完成并回收全部设备待新建72
X-DLV-07交付订单受理、建群与派工销售/渠道为客户购买的 LeapCore 一体机（或充值、行业版）提交交付订单后，自动建专属交付群、确认信息、回复交付时间并按硬件/软件/充值/开放平台/现场分工派单。主责——交付负责人（当前：杨萌·推断待确认）；协同——交付部署工程师（部署发货总跟进，当前：游家豪·推断待确认）、硬件采购工程师（备机，当前：杨明学·推断待确认）、后端运维（实例 ID、网络配置，当前：杨云峰·推断待确认）、模型网关与计费研发（充值，当前：柯逸飞·推断待确认）、开放平台负责人（实例注册、行业版下发，当前：郭逸非·推断待确认）、研发负责人（机器人维护，当前：王皓南·推断待确认）、后端（v5 cloud，当前：宋祺睿·推断待确认）、销售提单人（当前：吴琪、闫登辉、杜中瑞、杨朋伟、刘昱潇等·推断待确认）、销售运营（现场培训，当前：韩诗琪·推断待确认）、财务（收款确认，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 销售提单（必填校验）→ ② 机器人发卡片并自动建群 → ③ 群内确认订单信息与订单类型 → ④ 回复预计交付日 → ⑤ 按角色派工 → ⑥ 各节点完成即群内通知并更新状态 → ⑦ 交付培训与验收单上传 → ⑧ 关闭订单每个订单有专属交付群、完整的订单记录（状态、预计交付日、实例 ID、充值、验收单），并以验收单为准关闭待优化300
X-DLV-08交付项目台账与立项留痕出现外包项目、POC、定制化项目或市场/销售 Demo 服务器部署需求时，统一登记项目台账、确认已走商务流程、指定责任人，并做技术留痕与工时登记直至结项。主责——FDE Leader/项目业务负责人（当前：黄振锋·推断待确认）；协同——CTO（台账与评审，当前：丁震宇·推断待确认）、COO（商务，当前：常元和·推断待确认）、基座研发负责人（水利类项目，当前：望政韬·推断待确认）、硬件与 IT 运维（Demo 服务器部署，当前：杨明学·推断待确认）、总经办（工时口径与需求整理，当前：田杰·推断待确认）、综合部负责人（合规与财务视角，当前：赵雪冰·推断待确认）、PRM 开发（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 填写项目开发申请 → ② 商务确认 → ③ 立项评审与指定专班责任人 → ④ PRM/台账登记 → ⑤ Demo/服务器部署申请 → ⑥ 每周工时登记与进度更新 → ⑦ 材料与会议归档 → ⑧ 验收结项或手动结束每个项目在 PRM/台账中有唯一记录（商务状态、责任人、里程碑、工时、材料、验收单），结项后工时转运维成本待优化180
X-DLV-09交付项目启动会与客户资料收集客户合同双方盖章生效（或首款到账）后，需要拉齐双方对接人与职责、交付里程碑、开票安排，并向客户收齐数据集/业务样例/参考资料时启动主责——交付项目经理（当前：王皓南·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、商务负责人（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、业务专家（当前：王满·推断待确认）、IT 运维（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 签约生效通知 → ② 开票申请 → ③ 内部预备会定分工 → ④ 发启动会邀请与资料清单 → ⑤ 召开启动会 → ⑥ 纪要与任务下发 → ⑦ 资料签收与催办 → ⑧ 资料可用性确认并转入部署/培训启动会纪要（双方对接人表、项目 RACI、里程碑、验收口径）、客户资料签收表、已提交的开票申请、指派到人的飞书任务待新建180
X-DLV-10客户定制需求承接、拆解与排期签约客户或合作伙伴提出合同约定的交付内容，或超出标品的定制功能（账单/计费口径、账号打通、专属管理页、API Key 统计限量、客服机器人、特定模型部署等）时，从需求对齐到拆单、派工、排期、验收全程管理主责——交付需求收口人/产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、对客窗口商务负责人（当前：常元和·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、研发工程师（当前：邓乾、宋祺睿、魏宗浩·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 需求登记 → ② 合同范围核对 → ③ 可行性与技术路线评估 → ④ 范围与对客口径确定 → ⑤ 对客书面确认 → ⑥ 拆单绑迭代派工 → ⑦ 周度进度同步 → ⑧ 验收闭环客户需求登记条目（关联合同条款）+ Gitea 工单（迭代、唯一负责人、点数）+ 客户确认的范围与交付日期 + 验收记录待优化320
X-DLV-11行业版与白牌定制交付订单要求行业版、特殊 Skill/场景包，或客户/渠道要求专属品牌（名称、Logo、帮助中心、客户端安装包、管理后台）时，完成定制配置、打包发版与交付主责——交付产品负责人（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、客户端打包/OTA（当前：葛家和·推断待确认）、管理后台与部署（当前：杨云峰、宋祺睿·推断待确认）、测试（当前：李国庆、张东郅·推断待确认）、行业 Skill 提供（当前：陈锦杰·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 订单评审识别定制项 → ② 能力评估 → ③ 素材收集 → ④ 开放平台注册企业与配置下发 → ⑤ 管理后台/客户端包定制 → ⑥ 行业 Skill 与渠道切换 → ⑦ 测试服验证 → ⑧ 放行发包 → ⑨ 定制配置归档客户可用的定制版本（品牌、帮助中心、行业 Skill 均生效）、定制检查清单验收记录、企业定制配置台账待新建240
X-DLV-12批量装机镜像（ISO/OOBE）制作与发版协同批量出货、新机型首批出货或客户要求扩容时，需要确定出厂规格、制作并验收 ISO/OOBE 镜像，并与软件发版节奏对齐主责——镜像/OOBE 负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件规格（当前：杨明学·推断待确认）、存储方案（当前：吴世豪·推断待确认）、发版（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付工程师（当前：游家豪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 出厂规格确认 → ② 预装版本冻结 → ③ ISO/OOBE 制作 → ④ 镜像验收 → ⑤ 试产 3 台 → ⑥ 批量烧录出厂 → ⑦ 规格台账登记 → ⑧ 扩容预案经验收的 ISO/OOBE 镜像（含版本说明）、出厂规格表、每台设备的规格与镜像版本记录、扩容方案待新建120
X-DLV-13一体机出厂装机、预装与测试验收新机器到货或交付订单提单后，完成来料检验、装系统、部署 LeapCore、注册充值、自动化测试与出厂检查，验证合格后发货或安排上门主责——交付工程负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、交付工程师（当前：游家豪·推断待确认）、部署研发（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付统筹（当前：杨萌·推断待确认）、网关额度（当前：柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 交付单信息收齐 → ② 到货组装与来料检验 → ③ 装系统与环境确认 → ④ 硬件→软件交接 → ⑤ 部署 LeapCore → ⑥ 注册与充值 → ⑦ 自动化测试出报告 → ⑧ 出厂检查 → ⑨ 发货/上门 → ⑩ 台账回写通过出厂检查的整机（系统、版本、席位、注册、额度、网络均就绪）、测试报告、出厂检查单、发货记录、设备台账条目待优化400
X-DLV-14设备指纹注册与平台登记每台新装/新增机器（客户、演示、测试、内部研发、集群主从）上线前，需要采集设备指纹（DMI UUID + SN / TPM）、在平台注册组织与机器、网关登记、开放平台登记组织 ID 并配置席位时启动主责——平台注册负责人（当前：杨云峰·推断待确认）；协同——交付工程师（当前：游家豪·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、网关研发（当前：柯逸飞·推断待确认）、平台配置（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、厂商对接（当前：闫登辉·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 来料指纹采集与唯一性校验 → ② 提交注册申请 → ③ 平台注册组织/机器/实例 → ④ 网关登记指纹 → ⑤ 开放平台登记组织 ID → ⑥ 席位配置 → ⑦ 机器端验证 → ⑧ 台账回写 → ⑨ 变更与注销已在 LeapUpdate、网关、开放平台三处登记且机器端验证通过的设备，指纹—机器—组织 ID—客户/用途对应台账待优化96
X-DLV-15客户组织、账号开通与额度充值交付上线前，或客户/内部提出时，为客户或设备建组织、批量导入用户与初始密码、开管理员与灰度权限、设置人均额度/容量上限、充值词元额度或席位主责——交付开通负责人（当前：宋祺睿·推断待确认）；协同——额度充值执行（当前：柯逸飞·推断待确认）、交付统筹/额度决策（当前：杨萌·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）、灰度开关（当前：侯怡辰·推断待确认）、测试（当前：李国庆·推断待确认）、IT 资产（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 提交开通申请（关联订单/用途）→ ② 额度审批 → ③ 建组织与管理员 → ④ 名单批量导入 → ⑤ 额度/容量/灰度/开关配置 → ⑥ 充值 → ⑦ 冒烟测试 → ⑧ 对客窗口验看后交付 → ⑨ 回写台账与财务同步客户管理员与成员可登录、额度与权限正确的组织；充值回执；冒烟记录；回写到订单表的开通与充值信息待优化192
X-DLV-16客户网络与远程接入配置客户设备需接入公司网关、需外网/分公司访问、云端需回连客户本地服务，或研发/售后需远程进入客户内网排障时，完成方案选型、WireGuard/frp/域名/LeapVPN 配置、客户间隔离、客户 IT 协调与访问回收主责——客户接入配置管理员（当前：游家豪·推断待确认）；协同——网关策略/IT 运维（当前：杨明学·推断待确认）、隔离方案与平台（当前：宋祺睿·推断待确认）、WG 部署（当前：杨云峰·推断待确认）、代理实例（当前：王皓南·推断待确认）、LeapVPN 管理员（当前：吴世豪·推断待确认）、对外技术窗口（当前：李铭熙·推断待确认）、现场排查（当前：望政韬·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 发客户环境要求清单 → ② 接入方案选型 → ③ 分配端口/网段并生成配置 → ④ 部署与隔离校验 → ⑤ LeapVPN 开通（如需）→ ⑥ 登记接入台账 → ⑦ 远程访问审批与配置下发 → ⑧ 客户 IT 协调与统一口径 → ⑨ 用后关闭客户设备可稳定接入且与其他客户隔离；客户接入台账（客户、机器、配置、端口、负责人、客户 IT 联系人）；每次远程访问的审批与关闭记录待新建300
X-DLV-17客户自备/第三方设备部署准入评估客户自备电脑/服务器，或市场、渠道要求在非我方硬件上部署 LeapCore/OpenClaw 时，在预约部署前完成配置、网络与需求范围的准入评估。主责——IT 运维/交付硬件负责人（当前：杨明学·推断待确认）；协同——销售对接人（当前：李鹏为·推断待确认）、部署工程师（当前：游家豪·推断待确认）、信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 销售发起准入并收客户环境确认表 → ② 对照最低配置核对 → ③ 评估授权与防破解 → ④ 判定标准/非标需求 → ⑤ 出具准入结论 → ⑥ 非标升级拍板 → ⑦ 告知客户并约部署 → ⑧ 归档审批通过的《非自有设备部署准入评估单》（结论、限制条件、免责说明），作为 X-DLV-19 部署工单的前置附件。待新建96
X-DLV-18部署方式决策与现场部署前预检合同签订后、出发现场前，确定交付方式（上门/寄送/公司装好再送），并完成硬件方案确认、客户网络与机房条件预检、关键链路（登录、网盘、计费等）在真实或等效环境的联调。主责——交付统筹（当前：杨萌·推断待确认）；协同——IT 运维/硬件负责人（当前：杨明学·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/发布（当前：宋祺睿·推断待确认）、销售对接人（当前：吴琪、韩诗琪·推断待确认）、部署工程师（当前：游家豪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 签约触发交付前检查单 → ② 硬件清单经硬件负责人确认 → ③ 决定交付方式 → ④ 客户网络/机房预检 → ⑤ staging 关键链路联调 → ⑥ 编写现场预案 → ⑦ 交付前一天预检会放行 → ⑧ 转实施放行的《交付前检查单》（硬件方案、交付方式、网络/机房条件、联调用例结果、现场预案、到场人员），作为进入 X-DLV-19 的放行凭证。待新建300
X-DLV-19客户现场/远程部署实施与上门安排订单通过交付前检查（X-DLV-18）后，排外勤并上门或远程完成 LeapCore/一体机装机部署、端口/内网/账号/配置下发、联调演示、培训与验收；也覆盖已交付设备的远程修复、搬迁与现场维护。主责——交付部署负责人/IT 运维（当前：杨明学·推断待确认）；协同——部署工程师（当前：游家豪·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、后端/发布与远程运维（当前：宋祺睿·推断待确认）、交付统筹（当前：杨萌·推断待确认）、项目牵头研发（当前：李铭熙·推断待确认）、高级部署（当前：望政韬·推断待确认）、销售/项目经理（当前：韩诗琪、闫登辉、杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 交付工单排班 → ② 约客户与外出审批 → ③ 公司内按《软件部署手册》装机自测 → ④ 物料与出发 → ⑤ 现场/远程部署与配置下发 → ⑥ 账号开通与交接 → ⑦ 联调演示与培训 → ⑧ 验收单 → ⑨ 复盘与回流客户可正常使用的 LeapCore 环境（访问地址、管理员账号、安装包已交付）、签字或回执验收单、部署记录（版本、IP、端口、配置、远程通道）、培训录像（如有）与复盘记录。待优化400
X-DLV-20集群版交付部署客户集群硬件到货或需扩展从机（sub 节点）时，完成上电联网、IP 下发、设备身份注册（TPM/指纹）、主从关联、OOBE 交付与席位配置。主责——LeapCore 部署研发（当前：杨云峰·推断待确认）；协同——后端/v5 云端（当前：宋祺睿·推断待确认）、部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 到货/扩容登记并指派 → ② 客户侧上电联网说明 → ③ 云端配置身份与 IP、注册指纹 → ④ 主机部署与 OOBE → ⑤ 从机预部署 → ⑥ 角色关联与席位配置 → ⑦ 两轮验收 → ⑧ 发货/接入与记录主从节点均注册并关联的集群、OOBE 完成、席位按合同配置、两轮验收全部 PASS 的记录、客户侧操作说明。待新建160
X-DLV-21客户模型/API 能力接入与本地 NewAPI 维护客户需要使用海外模型/搜索、指定自有云算力或本地定制模型接入 LeapCore，或客户本地独立部署的 NewAPI 需要同步价格、峰谷配置、新模型并提供调用示例时。主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——上游渠道维护/IT 运维（当前：杨明学·推断待确认）、客户环境配置研发（当前：李铭熙·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售（当前：闫登辉·推断待确认）、远程环境/WG（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAgent 研发（当前：岳阳·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 销售填确认信息表 → ② 技术评估与路由方案 → ③ 分批上线计划拆任务 → ④ 上游渠道接入 → ⑤ 客户本地 NewAPI 配置 → ⑥ 测试 → ⑦ 调用示例、接入文档与知情书 → ⑧ 对客与异常初判 → ⑨ 变更同步核对客户可用的模型清单与渠道配置、调用示例与接入文档、客户环境配置清单（地址、访问方式、同步项）、必要的体验受限知情书；每次调价/上新后的同步核对记录。待优化180
X-DLV-22OpenClaw/龙虾批量装机与上门部署客户采购盒子/Mac mini 需批量预装 OpenClaw/ClawLite/LeapAgent，或政企客户要求上门安装"龙虾"并演示/科普时，完成安装包获取、批量预装、API 与飞书/微信绑定、Skill 与 Logo 定制、测试和交付。主责——部署工程师（当前：游家豪·推断待确认）；协同——安装包与镜像（当前：杨明学·推断待确认）、安装包与绑定教程（当前：李铭熙·推断待确认）、ClawLite 维护与人设/API（当前：邓乾·推断待确认）、容器与环境变量（当前：杨云峰·推断待确认）、销售对接（当前：闫登辉、李鹏为·推断待确认）、上门讲解与部署（当前：李子遥、魏宗浩·推断待确认）、交付需求方（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求清单与免责确认 → ② 定方案与唯一负责人 → ③ 从统一出处取版本化安装包 → ④ 跑通样机并写参数表 → ⑤ 批量写盘/安装 → ⑥ 逐台测试入台账 → ⑦ 解绑移交或上门部署 → ⑧ 需求与问题回流按台账逐台通过测试的设备（版本、Skill、绑定、Logo 符合需求）、客户签收/验收单、移交拉群或绑定完成记录、更新后的部署包。待新建240
X-DLV-23离线/私有化部署包准备与预演客户要求本地化/国产化/内网离线部署或 POC 时，在出发前完成可行性评估、测试环境申请、依赖梳理、按目标架构打包镜像/模型/rpm、同款环境离线预演与放行，并推进一键化部署。主责——IT 运维/镜像打包负责人（当前：杨明学·推断待确认）；协同——业务研发（当前：李玄冰、葛家和·推断待确认）、基座研发/部署（当前：望政韬·推断待确认）、架构评估（当前：陈晖·推断待确认）、部署工程师（当前：游家豪·推断待确认）、后端/部署（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、商务（当前：杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 离线可行性问卷 → ② 评估与承接决定 → ③ 申请同款测试环境 → ④ 梳理依赖与配置 → ⑤ 按目标架构打包 → ⑥ md5 校验与离线预演 → ⑦ 测试文档与手册 → ⑧ 放行通过放行清单的离线部署包（镜像/模型/rpm/一键脚本/配置模板，含 md5）、预演记录、测试文档与用户手册、推荐配置。待新建180
X-DLV-24离线/私有化项目现场部署实施项目到交付节点，把知识库/RAG/ChatBI/大模型/文档解析/embedding 等部署到客户内网、离线或国产硬件，完成现场测试、验收、上线及补丁更新；含数天内紧急交付和非标本地大模型一体机。主责——交付运维负责人（当前：杨明学·推断待确认）；协同——基座研发/现场部署主力（当前：望政韬·推断待确认）、部署工程师（当前：游家豪·推断待确认）、应用研发（当前：李玄冰、张康·推断待确认）、模型部署与路由（当前：柯逸飞·推断待确认）、验收测试（当前：陈晖、黄振锋、裴蔬桐·推断待确认）、客户接口（当前：常元和、杨朋伟、李鹏为·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——CTO/项目总协调（当前：丁震宇·推断待确认）① 交付任务单与时间窗 → ② 核对放行包 → ③ 介质与入场手续 → ④ 现场部署/升级 → ⑤ 逐项测试 → ⑥ 客户验收与汇报 → ⑦ 问题回传与补丁回归 → ⑧ 文档沉淀在客户环境运行并经客户验收的系统；部署记录（版本、哈希、配置、回滚包）；遗留问题清单与反馈表；更新后的部署文档。待优化375
X-DLV-25信创/国产算力适配与厂商协同客户、渠道或厂商联合宣发提出信创/国产算力要求（国产 CPU/OS/GPU/一体机），需要确定适配版本、完成测试、向厂商升级问题并统一对外"是否已适配"口径时启动主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、产品总监（当前：杨萌·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 需求登记 → ② 定适配版本、负责人与 DDL → ③ 拿机/备环境 → ④ 打包与部署测试 → ⑤ 厂商问题登记与升级 → ⑥ 出测试结论并更新适配矩阵 → ⑦ 对外口径同步适配矩阵中一条"平台×产品×版本×结论"记录、信创测试报告、厂商问题跟踪记录，以及可直接转给销售/市场的适配口径待新建400
X-DLV-26客户现场准入材料准备要进入国企、央企、军队或涉密客户的生产环境部署前，需要准备人员入场材料和软件准入材料时启动主责——项目交付负责人（当前：丁震宇·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、部署工程师（当前：游家豪、张康、邓乾·推断待确认）、基座研发（当前：望政韬·推断待确认）、法务（当前：待指定）、人事（当前：待指定）；兜底——研发条线负责人（当前：丁震宇·推断待确认）① 获取客户准入要求 → ② 拆成人员/软件/合规三类清单 → ③ 私密收集人员材料 → ④ 生成组件依赖清单与安全说明 → ⑤ 合规材料（算法备案号等）核对 → ⑥ 打包提交客户 → ⑦ 安排考试/登记并归档客户认可的准入材料包（人员登记、电子签、考试记录、组件依赖清单/SBOM、安全加固说明、算法备案信息）和准入名单待新建150
X-DLV-27客户 POC/演示环境搭建与交付销售演示后客户要求限期 POC，或客户领导来演示/验收，需要拉研发定方案、搭演示/试用环境、按意见修改并交付甲方时启动主责——POC 实施负责人/FDE Leader（当前：黄振锋·推断待确认）；协同——销售/客户对接（当前：刘昱潇、杨朋伟·推断待确认）、研发排期（当前：王皓南·推断待确认）、Skill 研发（当前：李凯·推断待确认）、演示环境部署（当前：望政韬、魏宗浩·推断待确认）、Demo 开发（当前：裴蔬桐·推断待确认）、数据入库（当前：李玄冰·推断待确认）、现场支持（当前：杨明学·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① POC 立项登记 → ② 技术评估与方案选型 → ③ 与客户确认截止、验收口径 → ④ 搭环境与开发 → ⑤ 需求—功能对表与内部彩排 → ⑥ 交付甲方并出测试报告 → ⑦ 收集反馈与商务跟进可访问的 POC/演示环境、使用文档或演示视频、POC 测试报告，以及客户书面/记录在案的验收意见待优化375
X-DLV-28客户培训与使用手册准备产品交付上线或阶段验收后，需要给客户（管理员/员工）做使用培训，并准备手册、视频、演示场景时启动主责——培训总负责人/产品总监（当前：杨萌·推断待确认）；协同——培训主讲/业务专家（当前：王满·推断待确认）、客户经理（当前：吴琪·推断待确认）、研发讲师（当前：杨云峰、岳阳·推断待确认）、文档站维护（当前：杨黔昆·推断待确认）、交付研发（当前：宋祺睿·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 与客户约培训（验收后） → ② 指定主讲与材料负责人 → ③ 研发内部培训交付人员 → ④ 准备手册/视频/演示场景 → ⑤ 彩排与流程跑通 → ⑥ 客户培训执行 → ⑦ 收集反馈并更新手册分角色用户手册（管理员/员工）、操作讲解视频、培训演示脚本、培训签到与反馈记录待优化120
X-DLV-29交付签收单、验收单与开票跟进硬件或软件交付到客户后，需要用签收单/验收单/交接单取得客户书面确认、回收原件、上传系统，作为开票和回款依据时启动主责——硬件交付收口/部署工程师（当前：游家豪·推断待确认）；协同——IT 运维/发货（当前：杨明学·推断待确认）、客户经理/销售（当前：吴琪、常元和、闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）① 按合同取模板生成单据 → ② 随货寄送签收单 → ③ 客户签收盖章并回寄 → ④ 软件验收单签署 → ⑤ 核对原件 → ⑥ 上传渠道系统并通知财务 → ⑦ 财务按合同阶段开票 → ⑧ 纸质原件归档客户签字盖章的签收单/验收单（电子版已上传渠道系统、纸质原件归档），以及据此开出的发票待优化240
X-DLV-30交付服务承诺口径（保修、运维边界、客户须知）硬件随软件销售或批量出货前，需要统一保修时长、运维主体与远程售后边界、客户侧注意事项与免责声明时启动；或发生客户误操作导致离线等责任争议后需要补口径时启动主责——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、研发（当前：杨云峰、王皓南、宋祺睿·推断待确认）、销售与渠道（当前：李鹏为、闫登辉、常元和·推断待确认）、法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 收集待决问题 → ② 对齐厂商保修信息 → ③ 开会定运维主体与售后边界 → ④ 起草客户须知与免责声明 → ⑤ 法务审阅 → ⑥ 发布并写入合同/交付单据 → ⑦ 交付时签署并贴机身标签《交付服务承诺口径》一页纸（保修时长、运维主体、远程售后范围、收费情形）、《客户使用须知与免责声明》（交付时客户签署）、机身标签/二维码待新建80
X-DLV-31已交付设备与客户信息登记归档每交付一台 LeapCore 或项目交付完成后，登记设备与客户的唯一信息源（指纹、渠道、客户全称、版本、管理员地址、Skill 下发），归档客户材料与验收单，并在客户反馈问题时据此定位设备与交付人主责——部署工程师/设备登记（当前：游家豪·推断待确认）；协同——交付 SOP 统筹（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、企业更新与设备指纹（当前：宋祺睿、杨云峰·推断待确认）、模型网关与计费（当前：柯逸飞·推断待确认）、IT/硬件交付（当前：杨明学·推断待确认）、销售（当前：吴琪、杨朋伟·推断待确认）；兜底——产品总监/交付 SOP 统筹（当前：杨萌·推断待确认）① 成单写入交付订单表 → ② 部署后登记设备（指纹、版本、IP、渠道） → ③ 行业版到开放平台登记 → ④ 补管理员地址等交付信息并同步客户 → ⑤ 上传验收单与材料 → ⑥ 订单—设备关联校验 → ⑦ 定期核对与离线跟进一张以设备 ID 为主键、与交付订单关联的"已部署设备台账"（唯一信息源），以及按项目归档的客户交付材料待优化192
X-DLV-32已交付/演示机版本升级与回退新版本发布后要给客户机、演示机、伙伴机推送更新，或次日要交付/演示需确认机器已在可用版本上，并在升级失败时回退主责——发版/运维（当前：宋祺睿·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、部署工程师/现场（当前：游家豪·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）① 确定升级范围与优先级 → ② 预检（在线、环境变量、磁盘、依赖） → ③ 分批推送 → ④ 探测验证 → ⑤ 失败回退 → ⑥ 修复后重推 → ⑦ 更新升级状态表目标机器全部处于可用版本（或已回退到上一稳定版本），升级状态表记录每台机器的版本、结果与遗留问题待新建108
X-DLV-33已交付客户扩容与加席位变更已交付 LeapCore 一体机/系统的客户要求加席位、多开账号、升级扩容或自行加装内存，或内部核对发现客户系统席位与合同/席位表不一致时启动主责——交付统筹（当前：杨萌·推断待确认）；协同——LeapCore 部署/后端工程师（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、IT 运维/硬件负责人（当前：杨明学·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、后端/运维发版（当前：宋祺睿·推断待确认）、销售（当前：吴琪、李鹏为·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 受理变更申请 → ② 核对合同席位与硬件规格 → ③ 按政策判定（是否允许/席位上限/是否收费）→ ④ 审批 → ⑤ 远程改席位或返厂扩容 → ⑥ 通知客户并验证 → ⑦ 登记席位台账已生效且与合同一致的席位配置、更新后的席位台账记录、客户确认记录（收费时附补充合同/订单）待新建180
X-DLV-34交付期现场问题反馈与故障闭环交付/驻场期间（尚未验收转入常规售后），客户反馈系统异常（解析失败、问答超时、推理服务不可用、显卡/驱动掉线、IP 变化、系统慢）或提出优化需求时启动，直到问题关闭并正式回复客户主责——现场交付工程师（当前：游家豪·推断待确认）；协同——项目负责人（当前：丁震宇·推断待确认，定口径与优先级）、IT 运维/现场排查（当前：杨明学·推断待确认）、研发对接人（当前：李玄冰、张康·推断待确认）、商务/合同（当前：闫登辉·推断待确认）、客户关系（当前：常元和·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 统一入口登记 → ② 分级 → ③ 健康检查与日志收集 → ④ 研发定位根因 → ⑤ 修复封包或临时方案 → ⑥ 现场部署验证 → ⑦ 按口径回复客户 → ⑧ 沉淀根因并关闭已关闭的问题登记记录（含根因、处理方式、修复版本）、客户正式回复、必要时的新版本包与更新后的部署/测试文档待新建400
X-DLV-35交付进度跟踪与卡点盘点交付订单从受理到客户验收期间，按“采购/装机→软件部署→测试→充值→发货/上门”逐环节接力并同步进度；每周盘点卡点与遗漏；订单激增积压时调配人力主责——交付总负责人（当前：游家豪·推断待确认）；协同——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）、IT 运维/硬件采购（当前：杨明学·推断待确认）、LeapCore 部署/网络配置（当前：杨云峰·推断待确认）、充值负责人（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、后端/订单答疑（当前：宋祺睿·推断待确认）、定制项目负责人（当前：望政韬·推断待确认）、整理纪要（当前：吴琪·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 订单入台账并倒排节点 → ② 各环节完成即改状态并同步订单群 → ③ 自动提醒下一环节 → ④ 每日逾期推送 → ⑤ 每周盘点与例会 → ⑥ 积压时调配人力 → ⑦ 验收后关闭状态实时可见的交付订单看板、每周卡点盘点清单与处理结论、定制项目周简报待优化240
X-DLV-36部署 SOP 与交付文档沉淀每次交付/部署完成后补漏，或新版本、新机型、新部署形态首次交付前，需要编写或更新部署 SOP、部署手册、使用教程、现场测试流程并组织演练时启动主责——部署 SOP 维护人（当前：杨云峰·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、研发文档作者（当前：李玄冰、张康、邓乾、望政韬·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）、技术审核（当前：王皓南·推断待确认）、测试（当前：张东郅·推断待确认）、商务口径（当前：闫登辉·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 识别更新需求 → ② 分工并按模板起草 → ③ 技术审核 → ④ 非作者演练 → ⑤ 修订发布并记版本 → ⑥ 放入固定空间/随包分发 → ⑦ 交付后复盘补遗固定 wiki 空间中带版本号的“部署 SOP + 使用手册 + 现场测试流程”三件套（必要时含录屏）、交付记录与变更日志待优化81
X-DLV-37交付负责人 AB 角与项目交接交付负责人/项目负责人请假、调岗、离职，或新人入职接手客户项目时启动；平时为每种交付形态和每个在做项目预设 AB 角主责——交付统筹（当前：杨萌·推断待确认）；协同——交付负责人 A 角（当前：杨云峰·推断待确认）、B 角/备选操作人（当前：宋祺睿、游家豪、杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、原/新项目负责人（当前：黄振锋、望政韬、李铭熙·推断待确认）、项目拉人方（当前：常元和·推断待确认）、开发协助（当前：张康·推断待确认）、HR（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 建 AB 角台账 → ② B 角轮流上机演练 → ③ 触发代岗或交接 → ④ 按清单准备交接包 → ⑤ 交接会与签字 → ⑥ 公告新负责人 → ⑦ 跟岗答疑与回访AB 角台账（每种交付形态/项目一名负责人 + 至少一名已实操的 B 角）、双方确认的项目交接清单、群内新负责人公告待新建128
X-DLV-38星域俱乐部商户入驻、开通与数据迁移意向电竞俱乐部/工作室确定合作后，从收集入驻材料、签约、开户，到开通会员端模块与配置、旧系统会员数据迁移、客服/接待培训并上线的全过程主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端开发（当前：张楠·推断待确认）、管理端开发（当前：陈真炎·推断待确认）、培训教学（当前：刘安达·推断待确认）、迁移方案（当前：蒋兴武·推断待确认）、会员体系（当前：林瑾鸿·推断待确认）、小程序/H5（当前：魏小东·推断待确认）、法务/财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）① 建档并收集入驻材料 → ② 签约 → ③ 开户与管理员开通 → ④ 会员端模块与配置 → ⑤ 旧系统数据迁移（如有）→ ⑥ 客服/接待培训 → ⑦ 上线冒烟与回访入驻台账中状态为“已上线”的商户记录（含合同、账户、模块开关、配置清单、迁移对账结果、培训记录）、商户展示素材待新建240
X-DLV-39外部数据集交付（构建验证、质检与外发保密）向外部客户交付强化学习环境、代码任务、游戏数据等数据包时启动，覆盖保密确认、制作、构建验证、反作弊与难度测试、外发审批、打包交付、客户反馈修订与成果展示主责——数据交付负责人（当前：丁震宇·推断待确认）；协同——研发/数据工程（当前：待指定）、商务（当前：待指定）、法务（当前：待指定）、外部协作者对接人（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认，与主责重合，建议另设）① 需求与保密确认 → ② 定价与分派（含外部协作）→ ③ 制作 → ④ 构建验证（x86/arm）→ ⑤ 反作弊与难度测试 → ⑥ 外发审批 → ⑦ 打包交付 → ⑧ 反馈修订与成果复盘通过构建、判分、反作弊与难度测试的数据包（含版本号、清单与校验值）、外发审批记录、客户验收反馈、成果展示材料（录屏/PDF）与 ROI 复盘结论待新建250
X-DLV-40项目结项、交付转售后移交与复盘交付项目取得验收（或标品订单完成签收）后，正式结项：资料归档、成本核算、把客户环境与承诺移交售后，并做项目复盘主责——交付负责人（当前：待指定）；协同——交付工程师、售后负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 验收确认 → ② 交付资料归档 → ③ 售后移交会 → ④ 售后签收移交清单 → ⑤ 项目成本与工时核算 → ⑥ 复盘 → ⑦ 交付群转售后群/关闭结项报告、售后签收的移交清单、归档资料、复盘纪要待新建144
X-DLV-41一体机发运包装、物流保价与到货异常处理一体机、服务器、集群节点等高价值硬件需寄送客户或渠道时，按规范包装、保价发运、跟踪物流，并处理到货破损、丢件、错发主责——交付工程师（当前：待指定）；协同——行政专员、交付负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 出库核对（序列号、配件清单）→ ② 拍照留证 → ③ 规范包装 → ④ 保价下单 → ⑤ 运单同步 → ⑥ 物流跟踪 → ⑦ 到货开箱确认 → ⑧ 异常理赔与补发带序列号的发货单、开箱照片、运单号与保价凭证、客户到货确认待新建96
X-DLV-42客户现场作业规范（变更确认、操作留痕、备份回退）交付、售后、FDE 人员在客户现场或远程对客户环境做部署、升级、配置变更、数据迁移、断电重启等操作时，事前确认方案与客户同意、事中备份留痕、事后验证并可回退主责——交付负责人（当前：待指定）；协同——交付工程师、FDE 工程师、研发值班、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 变更方案与回退方案 → ② 客户确认操作窗口 → ③ 操作前备份 → ④ 按步骤操作并记录 → ⑤ 功能验证 → ⑥ 失败回退 → ⑦ 客户确认 → ⑧ 记录归档客户确认的变更单、操作记录、验证结论待新建150
X-DLV-01一体机硬件配置咨询、配置单与报价待优化192

状态：待优化｜证据：有证据（卡片 7 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：客户、销售或渠道询问 LeapCore 一体机/服务器的配置、席位并发与价格，或客户要求扩容（存储/内存/多办公点）需要重新出配置与报价时启动。
  • 负责人：主责——硬件配置与采购工程师（当前：杨明学·推断待确认）；协同——研发负责人（配置审核，当前：王皓南·推断待确认）、交付/产品负责人（售价核定，当前：杨萌·推断待确认）、后端运维（软件容量口径，当前：杨云峰·推断待确认）、销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交配置需求 → ② 套标品配置 → ③ 非标技术评估 → ④ 供应商询价核成本 → ⑤ 核定售价 → ⑥ 审核出配置单 → ⑦ 签约前报价-合同-BOM 三方核对 → ⑧ 归档与版本更新
  • 交付结果：经审核、带版本号的配置单（含 BOM、成本、售价、报价有效期），写入合同附件且与采购 BOM 一致
  • 状态依据：已有 3C 配置单、产品配置清单和《Leapcore 总表》中的三档配置与内存估算口径，但 2026-04～09 反复出现“没有标准配置单”“配置单还是旧版”、内存算法两套口径、配置描述反复修改；2026-05 出现合同附表沿用旧配置、交付时成本超出评估的事故。

1. 场景判定

  • 触发条件：客户/渠道询问配置、并发或价格；销售准备报价单或合同硬件附件；客户要求增配存储/内存或多办公点部署；合作伙伴索要参考部署配置；公司自用机上架需定配置。
  • 典型说法：「多少人使用建议多少内存」「现在龙智的配置是怎么样，配置清单有吗」「配置和价格你填一下」「有合作伙伴想要一份参考本地部署配置」
  • 判断问题：是否需要给出“机型 + 规格 + 价格”的书面结论？这个结论是否会进入报价单或合同？
  • 不归本流程管：已确定要买、需要选供应商和下单 → 请走 X-DLV-02；有没有现货、什么时候能发 → 请走 X-DLV-04；样机/演示机借用 → 请走 X-DLV-05；已签约订单的提单与部署 → 请走 X-DLV-07；软件订阅、词元套餐定价 → 请走 SAL-18（产品定价与价格体系管理）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
配置与成本 出配置、询价核成本、维护标品配置库 R 硬件配置与采购工程师（当前：杨明学·推断待确认）
配置审核 审核配置是否满足席位、并发与模型需求，签发配置单 A 研发负责人（当前：王皓南·推断待确认）
售价核定 按毛利规则核定对外售价 R（价格） 交付/产品负责人（当前：杨萌·推断待确认）
软件容量口径 给出人数→内存/硬盘需求，软件发版后复核 C 后端运维（当前：杨云峰·推断待确认）
需求与报价 收集客户需求、对外报价、写入合同附件 R（报价） 销售（当前：吴琪、闫登辉、杨朋伟·推断待确认）
商务特批 折扣、低于底价、供应商砍价 C 销售负责人（当前：李鹏为·推断待确认）、COO（当前：常元和·推断待确认）
财务 成本与毛利口径核对 I 财务（当前：待指定）
兜底 口径争议裁决、非标方案拍板 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户使用人数（席位）、同时在线并发、办公点数量
  • 模型需求（本地大模型/云端 API）、是否信创（国产卡、国产操作系统）
  • 存储需求（知识库体量、是否需外接存储）、是否需机架式
  • 用途：POC/试用/正式采购；期望交付日期
  • 销售渠道（直销/渠道）与预算区间
  • 若为扩容：原订单号与原配置单编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按第 3 节字段提交配置需求 销售 客户询价当天 飞书表单/多维表格 配置需求记录 🔧飞书固化
2 按“人数—内存—硬盘—机型”映射套标品（标品/标品Plus/顶配），落在标品范围内直接出配置 硬件配置工程师 收到需求后 4 个工作小时内 标品配置库 配置初稿 🔧+🤖
3 超出标品（大并发、GPU 本地模型、信创、扩容、多点）时做技术评估：显存、并发按 2～3 档、卡型 硬件配置工程师 + 研发负责人 1 个工作日内 评估表 评估结论 👤人工判断
4 向合作供应商询价，记录报价、有效期和对公/个人价 硬件配置工程师 1 个工作日内 硬件报价表 成本单（带有效期） 🔧飞书固化
5 按统一毛利规则核定售价（标品价 + 行业版溢价 + 配件），折扣超阈值报商务特批 交付/产品负责人；销售负责人 成本出具后 1 个工作日内 报价模板 售价与折扣记录 👤人工判断
6 审核配置，生成带版本号的配置单发给销售 研发负责人 0.5 个工作日内 配置单模板 配置单 V 号 🔧飞书固化
7 签约前做“报价单—合同附件—采购 BOM”三方核对，不一致不得发起合同审批 销售 + 硬件配置工程师 合同审批发起前 合同审批 核对记录 🔧+👤
8 配置单、成本单挂到客户/订单；标品变化或软件发版后复核标品配置库并通知销售群 硬件配置工程师；后端运维 签约后 1 个工作日内；发版后 3 个工作日内 多维表格、群机器人 版本记录、变更通知 🔧+🤖

5. 交付物与模板

  • 交付物：配置单（含 BOM）、成本单、对外报价单、合同硬件附件、三方核对记录
  • 建议模板/表单：
    • 配置需求表：客户代号、席位数、并发、模型、是否信创、存储、办公点数、用途、期望交付日、提单人
    • 标品配置库：机型（龙智/源核/元和/震宇/信创机）、适用人数区间、CPU、内存、硬盘、GPU、标称/可用容量、3C 状态、成本、标准售价、生效版本、更新日期、维护人
    • 报价单：配置单编号、成本、售价、折扣、报价有效期、审批人
    • 三方核对清单：型号、内存、硬盘规格（HDD/SSD、容量）、GPU 数量、可用容量说明、供应商、交期

6. 异常与升级

  • 内存/硬盘估算口径分歧 → 以标品配置库为准并记录分歧 → 研发负责人 1 个工作日内裁定，仍有争议升级 CTO
  • 客户压价低于底价 → 销售不得自行承诺 → 销售负责人当天审批，毛利低于规则线升级 COO
  • 供应商报价过期或涨价 → 重新询价并更新成本库 → 当天通知正在报价的销售
  • 签约前发现合同附件与 BOM 不一致 → 暂停合同审批、重新出配置单 → 销售负责人
  • 交付时发现合同配置无法按原成本采购 → 评估原厂/替代件成本与违约风险 → CTO 当天拍板，转 X-DLV-02 采购
  • 客户质疑可用容量 → 配置单统一写明“标称/可用”两个数 → 无需升级
  • A（升级）说明：配置单日常由研发负责人签发（A）；出现以下情况升级 CTO 拍板：口径争议经研发负责人裁定后仍有分歧、非标方案（GPU 本地模型、信创、多点）需取舍、交付时合同配置无法按原成本采购

7. 衡量指标

  • 配置报价周期 = 需求提交到配置单发出的工作小时数，目标：标品 ≤ 4 小时，非标 ≤ 2 个工作日
  • 标品覆盖率 = 直接套标品出单数 / 配置需求总数，目标 ≥ 80%
  • 合同-BOM 一致率 = 三方核对一次通过数 / 签约数，目标 100%
  • 配置单返工率 = 发出后被修改的配置单数 / 发出总数，目标 ≤ 10%
  • 硬件成本偏差 = |实际采购成本 − 报价成本| / 报价成本，目标 ≤ 5%

8. 低效诊断

  • 现象：人数→内存换算存在两套口径，举例计算出错，规则只在群内口头说明｜依据：「鼎慧产研决策部」2026-06
  • 现象：标品配置单未随软件版本更新，研发侧不知道有标准配置单，为内存配置反复争论｜依据：「LeapCore（archived）」2026-06、「leapcore市场对接」2026-04
  • 现象：配置清单每次需临时整理，可用容量口径未统一对外说明｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：同一客户配置描述多次修改（CPU、硬盘规格），成本价与售价混用，价格靠催｜依据：「Leapcore 客户交付群（某工程咨询客户）」2026-07、2026-08
  • 现象：谁来预估硬件在商务、研发、运维之间来回推，多个客户重复估算｜依据：「软件硬化工程实施协助群」2026-01、2026-04
  • 现象：合同附件沿用旧版配置，签约时无人核对，交付时成本超出评估、存在违约风险｜依据：「某客户硬件交付群」2026-05
  • 现象：硬件报价与砍价口径归属不清，变更未同步给统筹岗｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 机型：龙智（小团队，需说明标称与可用容量）、源核（大存储）、元和/震宇、机架式；3C 机 CPU 和电源因认证固定，只可增配内存与硬盘
  • 信创：国产卡 + 国产操作系统，需研发评估适配后再出配置
  • GPU 本地模型：按并发分 2～3 档报价，卡型（消费级/数据中心级/国产卡）由研发评估
  • 扩容/多办公点：重新出配置与成本，不沿用原报价
  • 合作伙伴索要参考配置：发放参考配置文档（不含成本与售价）
  • 公司自用机：按标品Plus 配置，入账走 X-DLV-03

10. 待确认问题

  • 主责是否为硬件配置工程师？售价核定归交付/产品负责人还是销售负责人？
  • 内存估算统一采用哪套口径（每人约 1.2G 向上取整 vs 每人 1G 加预留 1/4）？
  • 对外加价比例、硬件毛利规则是否已有成文制度，由谁维护和审批？
  • 标品配置库以哪张表为唯一来源（3C 配置单 / 产品配置清单 / Leapcore 总表）？
  • “标品 4 小时、非标 2 个工作日”的时限是否可行？
  • 三方核对放在合同审批节点是否可行，由谁签字确认？
X-DLV-02硬件供应商选型、BOM 与采购补货待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 1 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：演示/交付需要新机型，或库存将尽、销量预测上升需要补货，或现有供应商成本偏高、起订量/供货受限需要新增供应商或自组装时启动。
  • 负责人：主责——硬件采购工程师（当前：杨明学·推断待确认）；协同——销售负责人（供应商商务谈判，当前：李鹏为·推断待确认）、交付/产品负责人（需求节奏，当前：杨萌·推断待确认）、销售（供应商对接，当前：闫登辉、杨朋伟·推断待确认）、交付部署工程师（到货装机，当前：游家豪·推断待确认）、财务（打款，当前：待指定）；决策——CEO（下单数量与金额，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 补货/选型需求 → ② 选型与 BOM → ③ 询比价（≥3 家）→ ④ 商务谈判 → ⑤ 采购评审与审批 → ⑥ 签约下单打款 → ⑦ 排期与到货跟踪 → ⑧ 到货验收入库
  • 交付结果：经审批的采购单与供应商合同、留痕的询比价记录、按期到货并验收入库的设备
  • 状态依据：2026-03～09 采购均靠群内临时讨论：急单催办约 10 次、对公价在下单后才发现偏贵、供应商对接人一度不清、临时加机型导致混乱、工厂不接单需重新询价；无采购审批、无 BOM 模板、无备货计划。

1. 场景判定

  • 触发条件：库存低于安全线；销量预测或待交付订单超过在库+在途；需要新机型/原型机；现有供应商涨价、起订量过高或交期不满足。
  • 典型说法：「今晚就采购」「出两份 BOM 清单，一版适合 20 人内公司」「新的 25 台尽快下单」「现在有几个方案：贴牌代工、自研产出、手搓」
  • 判断问题：这次是否要花钱买硬件（整机或配件）？是否涉及选择或变更供应商？
  • 不归本流程管：给客户出配置与报价 → 请走 X-DLV-01；到货后的库存登记与资产台账 → 请走 X-DLV-03；现有库存如何分配给订单 → 请走 X-DLV-04；办公设备、IT 耗材采购 → 请走 ADM-24（IT 设备与研发硬件采购申请）；办公物资申购 → 请走 ADM-14（办公物资/家具申购）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
选型与询价 选型、出 BOM、询比价、下单、跟进到货 R 硬件采购工程师（当前：杨明学·推断待确认）
商务谈判 价格、账期、起订量、ODM 条款谈判 R 销售负责人（当前：李鹏为·推断待确认）
供应商对接 日常跟进供应商群、催报价与交期 R 销售（当前：闫登辉、杨朋伟·推断待确认）
需求方 提出交付节奏与机型需求 C 交付/产品负责人（当前：杨萌·推断待确认）
方案建议 技术方案取舍（自组/ODM/开模） C CTO（当前：丁震宇·推断待确认）
下单审批 批准采购数量、金额与供应商 A CEO（当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）
付款 审核发票与打款 R（付款） 财务（当前：待指定）
到货装机 到货验收、组装、贴标 R（验收） 交付部署工程师（当前：游家豪·推断待确认）

3. 办之前请准备

  • 采购理由：待交付订单数、近 4 周出货量、在库与在途数量
  • 机型与配置（引用 X-DLV-01 标品配置单编号）
  • 期望到货日期与可接受的最晚日期
  • 预算与目标进货价（参考：进货价占售价比例目标，待确认）
  • 是否需要 3C 认证、对公开票、定制外观（Logo、外壳、包装）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 库存低于安全线或预测缺口时发起补货需求；新机型由需求方发起 硬件采购工程师 / 交付/产品负责人 触发当天 库存看板（X-DLV-03） 采购需求单 🔧+🤖
2 选型并出 BOM（按人数分档，对公价/个人价双列） 硬件采购工程师 2 个工作日内 BOM 多维表格模板 BOM 清单 🔧飞书固化
3 向至少 3 家供应商询价，登记报价、MOQ、交期、3C、开票、有效期，并对照公开渠道价 硬件采购工程师 3 个工作日内 询比价表 比价表 🔧+🤖
4 商务谈判（价格、账期、起订量、交期、违约条款） 销售负责人 比价表出具后 3 个工作日内 线下/会议 谈判纪要 👤人工判断
5 采购评审：方案取舍（现货/自组装/ODM/开模）、数量与金额；开模等重大投入按公司章程上会 CEO/COO；CTO 建议 1 个工作日内 飞书审批（设备采购） 审批通过的采购单 🔧+👤
6 签约下单，提交付款申请，财务核对发票后打款 硬件采购工程师；财务 审批后 1 个工作日内下单；付款 2 个工作日内 合同审批、付款审批 合同、付款凭证 🔧飞书固化
7 跟踪排产与物流，每周一更新预计到货日；延期当天同步交付群 硬件采购工程师 每周一；延期当天 采购跟踪表 到货预测 🔧+🤖
8 到货验收（配置核对、3C 标识、外观、压测）、贴标组装后入库 交付部署工程师 到货后 2 个工作日内 验收清单、资产台账 验收记录、入库单 🔧飞书固化

5. 交付物与模板

  • 交付物：采购需求单、BOM 清单、询比价表、谈判纪要、采购审批单、供应商合同、付款凭证、验收入库记录
  • 建议模板/表单：
    • 询比价表：供应商、机型、配置、单价（对公/个人）、MOQ、交期、3C、开票、报价有效期、公开渠道对照价、备注
    • 供应商名录：供应商、供货线（整机/ODM/配件）、对接人岗位、合作状态、历史交付准时率
    • 采购跟踪表：采购单号、机型、数量、下单日、承诺到货日、实际到货日、付款状态、延期原因
    • 装机 SOP 与验收清单：驱动、GPU、自启、重启测试、压测结果、贴标

6. 异常与升级

  • 急单（需 3 日内到货）→ 走加急审批，允许现货采购或自组装兜底 → CTO 当天批准
  • 供应商不接单/起订量过高 → 启动备选供应商或自组装方案 → 销售负责人 2 个工作日内给出替代方案
  • ODM 物料缺货导致延期 → 更新到货日并通知 X-DLV-04 排期 → 延期超 7 天升级 CEO
  • 下单后发现对公价/开票价差异 → 暂停付款、重新核价 → 财务 + 销售负责人 1 个工作日内处理
  • 垫资方/合资方付款责任不清 → 付款前书面确认付款主体 → CEO
  • 到货验收不合格 → 拒收或退换，记录供应商质量问题 → 硬件采购工程师 2 个工作日内联系供应商

7. 衡量指标

  • 采购周期 = 采购需求提交到到货入库的自然日，目标：现货 ≤ 7 天，ODM ≤ 供应商承诺交期
  • 询比价覆盖率 = 有 ≥3 家报价留痕的采购单 / 采购单总数，目标 100%（急单除外）
  • 到货准时率 = 按承诺日到货批次 / 总批次，目标 ≥ 90%
  • 急单占比 = 加急采购单 / 采购单总数，目标 ≤ 20%
  • 缺货天数 = 在库为 0 且有待交付订单的天数，目标每月 ≤ 3 天

8. 低效诊断

  • 现象：采购需求多为当天提、当晚下单，群内催办约 10 次，对公开票价在下单后才发现偏贵｜依据：「硬件供货」2026-03
  • 现象：供应商商务对接人一度不明确，报价靠反复催；临时加机型导致需求方与商务口径混乱｜依据：「硬件供货」2026-07
  • 现象：补货无滚动预测与安全库存，管理层多次追问下单进度；工厂不接单需重新询价，交期从约一个月拉长到约 45 天｜依据：「硬件供货」2026-08
  • 现象：采购打款需等待财务，付款主体（垫资方/合资方）说法不一｜依据：「硬件供货」2026-08

9. 分支变体

  • 供应商：合作 ODM 供应商（带 3C、起订量较高）、其他整机/组装供应商（供应商 A/B/C 等）；名录化管理，变更需审批
  • 方式：现货采购（原型机，可拆原厂 Logo 贴公司标识）/ 自组装（手搓，兜底）/ ODM 贴牌代工 / 自研开模（重大投入，需上会）
  • 机型：龙智/元和（源核）不同供货线；标准款与尊享款
  • 学习样机采购：需确认可开票后再下单

10. 待确认问题

  • 采购主责是否为硬件采购工程师？商务谈判是否统一归销售负责人？
  • 采购审批金额阈值如何划分（多少以内 CTO 批、多少以上 CEO/董事会）？
  • 安全库存线（如某机型常备 5 台）由谁定、多久复核？
  • 是否已有成文的供应商准入与比价制度？
  • 进货价占售价比例目标是否作为硬性红线？
  • 垫资采购的付款主体与审批链如何规定？
X-DLV-03硬件库存与资产台账维护待优化192

状态：待优化｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：硬件采购入库、在产、待交付、已交付、自用、租出、赠送、回收，或在公司/机房/客户处之间上下架运输时，统一更新库存与资产台账及看板。
  • 负责人：主责——交付部署工程师（库存管理员，当前：游家豪·推断待确认）；协同——硬件采购工程师（采购与到货，当前：杨明学·推断待确认）、交付/产品负责人（交付表与看板，当前：杨萌·推断待确认）、后端运维（渠道系统库存接入，当前：宋祺睿·推断待确认）、财务（资产对账，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 到货入库登记 → ② 状态流转登记 → ③ 关联订单/客户 → ④ 出库与运输记录 → ⑤ 回收入库 → ⑥ 每周盘点与看板更新 → ⑦ 每月与财务对账
  • 交付结果：一张以设备序列号为主键、与订单和客户关联的库存/资产台账，以及按机型、按状态拆分的库存看板
  • 状态依据：已有交付表、资产表和多维表格，但 2026-06～08 库存靠口头同步、机器位置记错、管理层看不懂文档、龙智与元和合并展示；渠道系统只有 SKU 未接库存，库存归属（运维/供应链/IT 系统）有争议。

1. 场景判定

  • 触发条件：设备到货、组装完成、分配给订单、发货/上门交付、借出/归还、回收、转自用/租出/赠送、上下架或运输、月度盘点。
  • 典型说法：「还有多少存货？多少正在生产？即将交付？已交付？」「现在 LeapCore 的来源就很乱」「包装盒和标签还在吗，后面交付给客户要带着」
  • 判断问题：这台设备的位置、状态或归属是否发生了变化？
  • 不归本流程管：采购下单与供应商 → 请走 X-DLV-02；某台机器给哪个订单 → 请走 X-DLV-04；样机借用审批 → 请走 X-DLV-05；资产与交付的边界判定 → 请走 X-DLV-15；办公电脑等 IT 资产 → 请走 ADM-27（IT 设备到货验收、入库登记与调配变更）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
库存管理员 入库、出库、状态变更登记、每周盘点 R/A 交付部署工程师（当前：游家豪·推断待确认）
采购到货 维护在途数量与预计到货日 R 硬件采购工程师（当前：杨明学·推断待确认）
交付表维护 维护订单与交付状态，与台账关联 R 交付/产品负责人（当前：杨萌·推断待确认）
系统集成 渠道系统接入库存、SKU 与库存联动 C 后端运维（当前：宋祺睿·推断待确认）；CTO（当前：丁震宇·推断待确认）
客户资产要求 提醒保留包装、标签供客户资产归档 C COO（当前：常元和·推断待确认）
对账 月度资产与成本对账 C 财务（当前：待指定）
查看 查看库存看板 I CEO（当前：邴龙志·推断待确认）、销售

3. 办之前请准备

  • 设备序列号/机器码、机型、配置（引用配置单编号）
  • 来源：直接采购/自组装/渠道组装；采购单号与供应商
  • 用途：销售/自用/租出/赠送/演示/测试
  • 关联订单号与客户代号（若有）
  • 存放位置（公司/机房/客户现场）与包装、标签保存情况

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 到货验收后登记入库：序列号、机型、配置、来源、采购单号、位置、包装标签保存位置 库存管理员 到货当天 资产台账（多维表格） 入库记录 🔧飞书固化
2 采购下单后登记在途：数量、预计到货日；延期时更新 硬件采购工程师 下单当天；变化当天 采购跟踪表 在途记录 🔧飞书固化
3 设备分配到订单时填订单号，状态改为“预留/部署中” 库存管理员 分配当天 交付表—关联表—资产表 关联记录 🔧+🤖
4 出库/发货/上门交付登记：日期、去向、运输方式、随附包装标签；状态改“已交付” 库存管理员 出库当天 资产台账 出库记录 🔧飞书固化
5 上下架与机房流转：与机房约定时间，登记位置变化 硬件采购工程师 操作当天 资产台账 位置记录 👤人工判断
6 回收入库：确认数据已备份/清除、外观与配件完整后改状态 库存管理员 回收后 1 个工作日内 资产台账、回收确认单 回收记录 🔧飞书固化
7 每周五盘点抽检，更新看板（存货/在产/即将交付/已交付，按机型拆分），状态变更自动通知销售群 库存管理员 每周五 18:00 前 多维表格仪表盘、群机器人 周库存快报 🔧+🤖
8 每月与财务对账（数量、用途、成本） 库存管理员 + 财务 每月 5 日前 资产台账 对账记录 👤人工判断

5. 交付物与模板

  • 交付物：资产台账、交付-资产关联表、周库存快报、月度对账记录、回收确认单
  • 建议模板/表单（资产台账字段）：序列号/机器码（主键）、机型、配置单编号、来源（采购/自组装/渠道组装）、供应商、采购单号、入库日期、状态（在途/在库/预留/部署中/已交付/借出/自用/租出/赠送/回收/报废）、位置（公司/机房/客户）、关联订单号、客户代号、付款状态、包装标签位置、负责人岗位、更新时间
  • 看板：按机型（龙智/元和(源核)/震宇等）× 状态的数量矩阵，设库存预警线

6. 异常与升级

  • 盘点数与台账不符 → 当天追查最近出入库记录 → 差异 1 台以上报 CTO（1 个工作日内）
  • 找不到某台设备/位置记错 → 查出库与回收记录，联系最后经手岗位 → 交付/产品负责人当天
  • 设备归属有争议（销售/自用/租出）→ 按 X-DLV-15 判定 → CTO
  • 客户需要包装、标签做资产归档但已丢失 → 记录并告知销售 → 销售与客户沟通
  • 渠道系统与台账数据不一致 → 以台账为准，记录差异 → 后端运维 3 个工作日内修复

7. 衡量指标

  • 台账准确率 = 盘点一致设备数 / 盘点设备数，目标 ≥ 98%
  • 登记及时率 = 状态变更当天登记数 / 状态变更总数，目标 ≥ 95%
  • 看板更新频率 = 每周至少 1 次，目标 100% 按时
  • 库存问询次数 = 群内询问“还有几台”的次数，目标逐月下降

8. 低效诊断

  • 现象：库存数据靠采购岗在群里口头同步，需求方反复在群里重新罗列待交付机器，机器位置记错（实际早已被供应商回收）｜依据：「硬件供货」2026-07、2026-08
  • 现象：部分批次的付款与交付状态只在个别人记忆中，未进台账｜依据：「硬件供货」2026-08
  • 现象：管理层看不懂交付文档，龙智与元和合并展示，多次要求尽快梳理库存｜依据：「硬件供货」2026-08
  • 现象：设备来源（采购/自组装/渠道组装）与用途（销售/自用/租出）混在一起，渠道系统只有 SKU 无库存，库存归属有争议｜依据：「渠道系统优化」2026-08

9. 分支变体

  • 来源：直接采购 / 自组装 / 渠道组装，分别记录
  • 用途：销售交付 / 自用（标品Plus）/ 租出 / 赠送 / 演示样机 / 测试机，分状态管理
  • GPU 服务器：在公司、机房、客户处之间上下架，需记录运输方式与机房约定时间；部分设备运入后不可取出，需在台账注明
  • 交付时需随附原包装与标签的客户，入库时即单独登记保存位置

10. 待确认问题

  • 库存与资产台账主责是交付部署工程师，还是采购岗/行政？
  • 资产台账最终放在渠道系统、IT 资产系统还是多维表格，切换时间点？
  • 每周盘点、每月对账的时间节点是否可行？
  • 回收设备的数据清除标准由谁制定？
  • 自用、租出、赠送设备是否需要财务单独入账？
X-DLV-04出货排期、机器调配与延期通知待新建300

状态：待新建｜证据：有证据（卡片 7 张 / 会话 8 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：多个订单抢机、库存不足、供应商延期或硬件故障，需要决定发货优先级与机器分配、处理销售预定留机、向销售/客户发出延期或承诺变更通知时启动。
  • 负责人：主责——交付/产品负责人（排期统筹，当前：杨萌·推断待确认）；协同——硬件采购工程师（库存与到货，当前：杨明学·推断待确认）、交付部署工程师（装机部署，当前：游家豪·推断待确认）、销售负责人（发货报备、先款后货特批、承诺变更，当前：李鹏为·推断待确认）、销售（当前：杨朋伟、杜中瑞、刘昱潇·推断待确认）、模型网关研发（压测，当前：柯逸飞·推断待确认）；决策——CEO（库存优先原则，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 每周排期会更新库存与到货 → ② 新订单可交性评估并回复交付日 → ③ 按优先级分配机器 → ④ 预留/调拨/回收 → ⑤ 发货前席位与收款核对 → ⑥ 延期或承诺变更判定 → ⑦ 通知销售与客户 → ⑧ 回写台账
  • 交付结果：每台机器有明确的订单归属与承诺交付日；延期与承诺变更有审批记录和书面通知
  • 状态依据：2026-07～10 反复出现抢机、临时抽调研发机和客户机、同一台机器多次改期、出发前才发现压测损坏；2026-09 才提出“要定交付优先级规范”，至今无书面优先级、预定与承诺变更规则。

1. 场景判定

  • 触发条件：可交付机器少于待交付订单；供应商到货延期；压测或部署发现硬件故障；销售申请预定/留机；试用机需收回转交付；临近节假日需截单。
  • 典型说法：「现在机器有限，得排优先级」「交付机器不太够了，这台能不能先拿回来」「我预定一台元核一台龙智」「现在的重点是今天要交付东西」
  • 判断问题：这台机器能否按原承诺日交给原定客户？如果不能，或有多个客户在等同一台，就走本流程。
  • 不归本流程管：补货下单 → 请走 X-DLV-02；台账登记 → 请走 X-DLV-03；样机/演示机借用 → 请走 X-DLV-05；订单提交与建群 → 请走 X-DLV-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
排期统筹 维护排期表、分配机器、发延期通知 R/A 交付/产品负责人（当前：杨萌·推断待确认）
库存与到货 报告可用机器、在途与预计到货 R 硬件采购工程师（当前：杨明学·推断待确认）
装机部署 回报每周实际装机产能 R 交付部署工程师（当前：游家豪·推断待确认）
压测 发货前压测与故障报告 R 模型网关研发（压测执行，当前：柯逸飞·推断待确认）
商务特批 先款后货特批、发货报备、降配/换型与承诺变更 A（升级） 销售负责人（当前：李鹏为·推断待确认）
客户沟通 提单、预定、向客户告知新日期 R 销售（当前：杨朋伟、杜中瑞、刘昱潇·推断待确认）
原则制定 制定库存优先供应规则；订单超过合同交付日时裁决 A（升级） CEO（当前：邴龙志·推断待确认）
兜底 优先级争议、抽调研发机裁决 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 订单号、客户代号、机型、席位数、合同约定交付日
  • 收款状态（全款/定金/未付）与付款时间
  • 客户等级与是否有书面承诺（如双卡、本地大模型）
  • 预定/留机：用途、预计提货日、合同状态
  • 回收机：客户数据是否需备份的确认

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 每周一召开排期会：更新在库、在途、预计到货与本周装机产能（应出/实出） 排期统筹 + 采购 + 部署 每周一 12:00 前 排期看板 周排期表 🔧飞书固化
2 新订单提交后评估是否有货，回复预计交付日；不提单不排期 排期统筹 订单提交后 1 个工作日内 交付订单表 交付日回执 🔧+🤖
3 按优先级分配机器：全款 > 定金 > 已签未付 > 试用/伙伴；同级按付款时间；未付款发货须销售负责人特批 排期统筹 每次分配当天 排期看板 分配记录 🔧+👤
4 销售预定/留机：提交预留申请，写明客户、合同状态、提货日；默认留存 7 天，到期自动释放 销售；排期统筹审批 申请后 0.5 个工作日内回复 飞书审批“机器预留” 预留记录 🔧+🤖
5 机器不足时调拨：优先用常备库存，其次回收试用机；回收前确认客户数据并备份、重置 排期统筹；部署 回收前 1 个工作日确认 回收确认单 调拨记录 👤人工判断
6 发货前核对：收款状态、席位数与订单一致、压测通过；源核类发货向销售负责人报备 部署 + 销售 发货前 1 个工作日 席位核对表、发货清单 核对记录 🔧飞书固化
7 延期/故障判定：确认新日期并留 1～2 个工作日余量；降配或换型交付须销售负责人批准并经客户书面确认 排期统筹；销售负责人 发现当天 订单群 变更审批 👤人工判断
8 通知：机器人在订单群和销售群发布延期/变更（原因、新日期、补救方案），销售当天告知客户 排期统筹；销售 发现后 2 小时内 群机器人 通知记录 🔧+🤖

5. 交付物与模板

  • 交付物：周排期表、交付日回执、机器预留记录、回收确认单、发货前核对记录、延期/承诺变更通知
  • 建议模板/表单：
    • 排期看板字段：订单号、客户代号、机型、席位、收款状态、付款日期、优先级、分配机器序列号、承诺日、预计日、状态、延期次数
    • 机器预留申请：申请人、客户代号、机型、数量、合同状态、预计提货日、留存期限、用途（商用/非商用）
    • 延期通知模板：订单号、原承诺日、新预计日、原因（物料/物流/故障）、补救方案、是否需客户确认
    • 回收确认单：客户确认无重要数据/已备份、回收日期、重置人

6. 异常与升级

  • 优先级冲突（两单同级、销售互争）→ 排期统筹按规则裁定 → 仍有争议当天升级 CTO
  • 需抽调研发机 → 评估对研发迭代影响 → CTO 批准
  • 客户要求加钱插队 → 记录并按优先级规则评估 → 销售负责人批准
  • 未付款要求发货 → 默认不发 → 销售负责人特批
  • 发货前压测发现硬件故障 → 联系渠道退换、查库存备件 → 当天通知销售；降配交付需销售负责人批准
  • 同一订单延期 2 次及以上 → 销售负责人当天与客户沟通 → 超过合同交付日升级 CEO
  • 节前集中 → 截单日后提单统一排到节后，要求客户付定金 → 截单日由销售负责人提前 5 个工作日公布
  • A（升级）说明：日常排期与机器分配由排期统筹拍板（A）；未付款发货、降配/换型交付、客户加钱插队等商务例外升级销售负责人；优先级争议排期统筹裁定后仍不服或需抽调研发机时升级 CTO；订单超过合同交付日或需调整库存优先原则时升级 CEO

7. 衡量指标

  • 按期交付率 = 按首次承诺日交付订单数 / 交付订单数，目标 ≥ 85%
  • 交付日回执及时率 = 1 个工作日内回复交付日的订单数 / 订单数，目标 ≥ 95%
  • 平均改期次数 = 交付日变更总次数 / 交付订单数，目标 ≤ 0.3
  • 延期通知及时率 = 2 小时内发出通知的延期次数 / 延期总次数，目标 100%
  • 逾期预留释放率 = 到期自动释放的预留 / 到期预留数，目标 100%

8. 低效诊断

  • 现象：机器有限时临时按“谁先付钱先给谁”口头排序，节前才提出要定优先级规范；同一台机器多次改期，销售反复催交付约 8 次｜依据：「交付订单通知群」2026-07、2026-09
  • 现象：“产能”与“机器”概念不统一，库存、在途、预留信息集中在个别岗位，订单到了才问有没有机器｜依据：「交付订单通知群」2026-07、2026-09
  • 现象：交付机不足时临时从其他客户处收回机器，延期口径未同步，有客户加钱插队｜依据：「Leapcore 客户交付群（客户A）」2026-07、「Leapcore 客户交付群（客户B）」2026-07
  • 现象：出发前一小时才发现压测损坏显卡；销售自写硬件方案与技术不一致，只能降配先交付再返工｜依据：「某地方政府客户交付群」2026-07
  • 现象：销售预定留机靠群消息，无台账，先留机后补流程｜依据：「硬件供货」2026-08
  • 现象：未付款客户的机器需临时找理由带回；发货前席位核对需反复催办｜依据：「【模态】市场销售」2026-08、2026-10

9. 分支变体

  • 客户类型：直销付费客户 / 渠道商预订 / 试用与伙伴类（原则上延迟发货，需报备）
  • 机型缺货：经客户同意可换老款或自组装机
  • 交付方式：线下上门 vs 邮寄 + 远程部署；标品 vs 定制 ISO（周期不同）
  • 信创适配需要另配国产机型，单独排期
  • 试用机回收转交付：必须先完成数据确认与重置

10. 待确认问题

  • 排期主责是交付/产品负责人还是硬件采购工程师？
  • 优先级规则（全款 > 定金 > 已签未付 > 试用）是否认可？客户等级是否参与排序？
  • 常备库存数量（如每机型 5 台）是否成为制度？
  • 预留默认 7 天、到期自动释放是否可行？
  • 降配/换型交付的审批人是销售负责人还是 CTO？
  • 是否已有先款后货的成文制度？
X-DLV-05样机/演示机借用与演示环境管理待优化96

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：销售、渠道、展会需要借用龙智/源核等样机或演示机，或需要配置高质量演示环境（演示、跑分、送检）时启动；不属于正式交付。
  • 负责人：主责——样机管理员（当前：汪家诺·推断待确认）；协同——销售负责人（审批与特批，当前：李鹏为·推断待确认）、硬件运维（参展/外借出库，当前：杨明学·推断待确认）、交付部署工程师（借用栏与库存关联，当前：游家豪·推断待确认）、销售运营（SOP 维护，当前：韩诗琪·推断待确认）、测试负责人（演示环境，当前：张东郅·推断待确认）、交付/产品负责人（当前：杨萌·推断待确认）；特批——CEO（当前：邴龙志·推断待确认）；兜底——销售负责人（当前：李鹏为·推断待确认）
  • 核心流程：① 判定借用类型 → ② 提交借用审批 → ③ 审批/特批 → ④ 确认库存并配置演示环境 → ⑤ 出库交接登记 → ⑥ 到期提醒 → ⑦ 归还验收 → ⑧ 台账更新
  • 交付结果：每台样机有审批记录、借用人、预计与实际归还日；演示机按统一“豪华演示版”配置可用
  • 状态依据：2026-09 已形成《各类型样机借用/试用 SOP（9 月第一版）》和借用审批，但此前出现机器已借出才补流程、演示机被给客户试用、借用与交付表混用；样机管理人多次交接，外借口径（保证每个销售一台 vs 不做实体机试用）不统一。

1. 场景判定

  • 触发条件：参展需要整机或外壳；客户要求实体机试用；远程试用需开账号；销售自管样机外借演示；需要演示专用环境。
  • 典型说法：「没单子怎么提机器的」「纯借机子的话就别填交付表」「开一个演示专用服务器」
  • 判断问题：机器最终是否要归还公司？如果要归还，走本流程；如果卖给客户或托管给渠道，走交付。
  • 不归本流程管：正式交付和渠道托管式交付 → 请走 X-DLV-07；演示机充值与资产边界 → 请走 X-DLV-15；渠道演示机白标 → 请走 X-DLV-11；展会现场网络与打包 → 请走 X-DLV-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
样机管理 维护借用台账、跟进归还、自管样机出库 R 样机管理员（当前：汪家诺·推断待确认）
审批 审批外借试用与自管样机外借 A 销售负责人（当前：李鹏为·推断待确认）
特批 实体机试用等例外 A（升级） CEO（当前：邴龙志·推断待确认）
出库 参展、外借试用机器出库与部署 R 硬件运维（当前：杨明学·推断待确认）
库存关联 借用栏与设备库存关联 C 交付部署工程师（当前：游家豪·推断待确认）
演示环境 演示专用模型/API 配置与版本同步 R 测试负责人（当前：张东郅·推断待确认）
SOP 维护 维护借用 SOP 与表单 C 销售运营（当前：韩诗琪·推断待确认）
借用人 保管、按期归还、异常告知 R 销售/渠道（申请人）

3. 办之前请准备

  • 借用类型：参展 / 外借试用 / 远程试用 / 自管样机外借演示
  • 机型、数量、是否只需外壳
  • 用途、客户代号或展会名称、起止日期
  • 是否需要随身 WiFi、演示账号与额度
  • 外借试用：是否已获负责人同意、是否签试用合同

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按第 3 节信息提交借用审批；远程试用只填账号申请表 借用人 使用前至少 2 个工作日 飞书审批（样机借用） 借用申请 🔧飞书固化
2 审批：参展与自管外借由销售负责人审批；实体机外借试用原则上不批，需 CEO 特批 销售负责人；CEO 申请后 1 个工作日内 飞书审批 审批结果 👤人工判断
3 确认库存可借，不占用已预留交付机 样机管理员 审批通过当天 资产台账 可借确认 🔧飞书固化
4 配置演示环境：统一“豪华演示版”（演示专用模型/API、示例数据），远程试用开账号 测试负责人；硬件运维 出库前 1 个工作日 部署脚本 可用演示机/账号 🔧+🤖
5 出库交接：清点机器、配件、随身 WiFi，借用人签收，台账改“借出” 样机管理员/硬件运维 出库当天 资产台账 签收记录 🔧飞书固化
6 到期前提醒；需续借重新走审批 系统机器人；借用人 到期前 2 个工作日 多维表格自动化 提醒记录 🤖+👤
7 归还验收：外观、配件、数据清理、演示额度回收，台账改“在库” 样机管理员 归还当天 资产台账 归还记录 👤人工判断

5. 交付物与模板

  • 交付物：借用审批单、出库签收记录、借用台账、归还验收记录
  • 建议模板/表单：
    • 借用审批：借用类型、机型、设备编号、数量、借用人、部门、用途、客户代号/展会、起止日期、配件（外壳/WiFi）、是否特批
    • 借用台账：设备编号、当前状态、借用人、借出日、预计归还日、实际归还日、超期天数、演示额度是否回收
    • 演示环境清单：模型/API 版本、示例数据、演示账号、额度上限、配置脚本版本

6. 异常与升级

  • 未审批先借出 → 样机管理员当天补登并通知审批人 → 销售负责人决定是否收回
  • 演示机被给客户长期试用 → 视同外借试用补走特批，不批则 3 个工作日内收回 → CEO
  • 超期未归还 → 超期第 1 天提醒，超 3 天通知借用人主管 → 销售负责人
  • 设备损坏或丢失 → 借用人当天告知样机管理员 → 销售负责人与财务按资产制度处理
  • 交付缺机需动用样机 → 转 X-DLV-04 排期 → CTO 批准
  • 演示额度被误当“无限额度”使用 → 立即停用并核对额度归属 → 交付/产品负责人
  • A（升级）说明：参展与自管样机外借由销售负责人审批（A）；实体机外借试用、演示机被客户长期使用需补特批时升级 CEO

7. 衡量指标

  • 先审后借率 = 有审批记录的借出次数 / 借出总次数，目标 100%
  • 按期归还率 = 按期归还次数 / 应归还次数，目标 ≥ 90%
  • 样机可用率 = 演示前一天可用样机数 / 计划演示所需数，目标 100%
  • 台账准确率 = 盘点一致的样机数 / 样机总数，目标 100%

8. 低效诊断

  • 现象：销售口头答应客户外借两周，机器已到客户处才发现未审批；规则与特批口径前后不一，管理人多次交接｜依据：「【模态】市场销售」2026-09、2026-10
  • 现象：借用与正式交付混用一张表，新装好的自用机被临时取走；演示机被给客户试用，演示额度被误认为“无限额度”｜依据：「交付订单通知群」2026-07、2026-09
  • 现象：演示专用环境只停留在群内一句待办，演示机归还无人跟踪｜依据：「AI API」2026-08

9. 分支变体

  • 参展：整机或外壳，研发/IT 侧借出，紧急情况可先借后补（24 小时内补审批）
  • 外借试用：先向负责人请示额度与时长，填交付信息问卷后部署；原则上不做实体机试用，需特批
  • 远程试用：部署后远程分配账号，不出库实体机
  • 自管样机外借演示：确认库存后走审批，通常配随身 WiFi
  • 繁星计划等特殊项目：按特批处理

10. 待确认问题

  • 样机管理员当前是谁？借出端在研发/IT 还是行政？
  • 实体机试用“原则上不做”是否成为正式制度？特批人是 CEO 还是销售负责人？
  • 是否保证每个销售有一台自管样机？
  • 借用申请提前 2 个工作日、超期 3 天升级是否可行？
  • 豪华演示版的模型与额度成本由哪个部门承担？
X-DLV-06展会与大型活动现场设备保障待新建72

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：展会、会场演示，或数百人同时使用 LeapCore 的培训/发布活动，需要准备设备、现场网络和并发容量时启动。
  • 负责人：主责——硬件与 IT 运维（当前：杨明学·推断待确认）；协同——交付/产品负责人（方案决策，当前：杨萌·推断待确认）、销售（现场演示，当前：闫登辉·推断待确认）、行政（会场网络对接，当前：侯明月·推断待确认）、交付部署工程师（打包运输，当前：游家豪·推断待确认）、CTO（容量评估，当前：丁震宇·推断待确认）、CEO（冗余标准，当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 活动登记（T-14）→ ② 容量与设备评估（T-10）→ ③ 会场网络确认（T-7）→ ④ 硬件就位联调（T-7～T-3）→ ⑤ 降级预案与清单确认（T-3）→ ⑥ 打包运输（T-1）→ ⑦ 现场保障 → ⑧ 回收复盘（T+1）
  • 交付结果：签核的现场保障清单（设备、网络、降级预案、负责人），活动顺利完成并回收全部设备
  • 状态依据：每次活动临时准备：2026-06 展会前一晚才确认演示方案、谁联系会场网络不清；2026-09 培训规模从 300 人临时改为 500 人冗余，硬件规格当场评估；无清单、无提前踏勘。

1. 场景判定

  • 触发条件：参加展会或会议需现场演示；举办培训/发布活动且预计 100 人以上同时使用 LeapCore；需要在会场交付演示机。
  • 典型说法：「最坏的结果就是现场只做静态展示，连公司的 LeapCore 做演示」「300 个人同时在公网使用 LeapCore 有足够的硬件吗」
  • 判断问题：活动现场是否依赖我方设备或我方服务正常运行？
  • 不归本流程管：样机借用审批 → 请走 X-DLV-05；活动策划、会务与物料 → 请走 MKT-03（参展/大会报名与现场执行统筹）；生态大会整体筹备 → 请走 ECO-16（生态大会立项与总体筹备）；活动后硬件转为他用 → 请走 X-DLV-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
现场保障 设备、网络、清单与现场技术保障 R/A 硬件与 IT 运维（当前：杨明学·推断待确认）
方案决策 演示方案（整机/外壳/远程环境）取舍 C 交付/产品负责人（当前：杨萌·推断待确认）
容量评估 人数→硬件与公网容量评估 C CTO（当前：丁震宇·推断待确认）
冗余标准 确认人数冗余与追加预算 A（升级） CEO（当前：邴龙志·推断待确认）
会场对接 联系会场网络、电源、场地 R 行政（当前：侯明月·推断待确认）
打包运输 清点、打包、运输、回收 R 交付部署工程师（当前：游家豪·推断待确认）
现场演示 现场讲解与演示 R 销售（当前：闫登辉·推断待确认）
活动发起人 登记活动保障需求 R 活动所属部门（申请人）

3. 办之前请准备

  • 活动名称、日期、地点、主办方联系人岗位
  • 预计到场人数与同时使用人数峰值
  • 演示内容与形式（实机/外壳/连公司环境）
  • 会场网络条件（有线/无线/带宽/是否限制）、电源位置
  • 是否需要在会场交付设备给客户

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记活动需求（第 3 节字段） 活动发起人 活动前 14 天 飞书表单 活动保障需求 🔧飞书固化
2 按人数换算配置与公网容量，按峰值人数加冗余（参考：300 人按 500 人准备），确认是否新购或复用 硬件与 IT 运维；CTO 活动前 10 天 人数→配置换算表 容量评估 🔧+👤
3 确认会场网络与电源，必要时实地踏勘 行政 + 硬件与 IT 运维 活动前 7 天 会场沟通 网络确认记录 👤人工判断
4 硬件就位并联调、压测 硬件与 IT 运维 活动前 7～3 天 压测脚本 联调报告 🤖自动化
5 确认演示方案与降级预案（CPE、手机热点、静态展示、连公司环境） 交付/产品负责人；销售 活动前 3 天 保障清单 签核清单 👤人工判断
6 按清单打包，约定集合时间与运输方式 交付部署工程师 活动前 1 天 18:00 前 打包清单 装箱记录 🔧飞书固化
7 到场先测网络与设备，异常即启用降级预案 硬件与 IT 运维；销售 开场前 1 小时 现场 现场检查记录 👤人工判断
8 回收设备、回报交付/回收清单，写 5 行复盘 交付部署工程师；硬件与 IT 运维 活动后 1 个工作日 资产台账 回收记录、复盘 🔧飞书固化

5. 交付物与模板

  • 交付物：活动保障需求、容量评估、现场保障清单、装箱记录、回收与复盘记录
  • 建议模板/表单（现场保障清单）：活动信息、设备清单（演示机/展示外壳/CPE/网络设备/备用硬盘/线材/电源）、网络方案（主用/备用）、降级预案、各项负责人岗位、联系方式（内部）、集合时间、运输方式、回收确认
  • 人数→配置换算表：同时使用人数、内存、CPU、硬盘、带宽、建议机型

6. 异常与升级

  • 会场无法保障网络 → 启用 CPE 或热点，再不行静态展示 + 连公司环境 → 当场告知交付/产品负责人
  • 活动规模临时上调 → 重新评估容量与采购 → CTO 当天确认，追加预算报 CEO
  • 设备联调失败 → 换备用机，活动前 3 天仍未解决 → 升级 CTO
  • 活动后设备未回收 → 1 个工作日内追回并登记 → 交付/产品负责人
  • A（升级）说明：现场保障方案与清单由硬件与 IT 运维签核（A）；活动规模上调或冗余方案需要追加采购预算时升级 CEO 确认

7. 衡量指标

  • 清单提前完成率 = 活动前 3 天完成签核的活动数 / 活动总数，目标 100%
  • 现场故障次数 = 每场活动因设备/网络导致演示中断次数，目标 0
  • 设备回收率 = 活动后 1 个工作日内回收设备数 / 带出设备数，目标 100%

8. 低效诊断

  • 现象：演示方案（演示机 + 展示外壳还是全外壳）在活动前一晚才确认，会场网络由谁联系不清，降级预案靠口头｜依据：「6.29展会交付」2026-06
  • 现象：数百人培训活动规模从 300 人临时上调到 500 人，硬件特殊规格与二手方案当天临时评估｜依据：「忠橙星行星引擎」2026-09

9. 分支变体

  • 展会演示：以设备与网络为主，可只带外壳 + 远程连公司环境
  • 数百人培训/发布：以并发容量与公网接入为主，需提前一周调试；硬件事后可复用给开放平台/FDE 调试（走 X-DLV-03 登记）
  • 会场自带设备 vs 我方自带设备

10. 待确认问题

  • 现场保障主责是硬件与 IT 运维，还是活动所属部门？
  • T-14/T-7/T-3 的时间节点是否可行？
  • 冗余比例是否统一为“峰值人数上浮约 2/3”？
  • 活动专用硬件的采购预算归市场/生态还是研发？
X-DLV-07交付订单受理、建群与派工待优化300

状态：待优化｜证据：有证据（卡片 12 张 / 会话 16 个）｜优先级：频5 × 耗3 × 跨5 × 险4

  • 适用场景：销售/渠道为客户购买的 LeapCore 一体机（或充值、行业版）提交交付订单后，自动建专属交付群、确认信息、回复交付时间并按硬件/软件/充值/开放平台/现场分工派单。
  • 负责人：主责——交付负责人（当前：杨萌·推断待确认）；协同——交付部署工程师（部署发货总跟进，当前：游家豪·推断待确认）、硬件采购工程师（备机，当前：杨明学·推断待确认）、后端运维（实例 ID、网络配置，当前：杨云峰·推断待确认）、模型网关与计费研发（充值，当前：柯逸飞·推断待确认）、开放平台负责人（实例注册、行业版下发，当前：郭逸非·推断待确认）、研发负责人（机器人维护，当前：王皓南·推断待确认）、后端（v5 cloud，当前：宋祺睿·推断待确认）、销售提单人（当前：吴琪、闫登辉、杜中瑞、杨朋伟、刘昱潇等·推断待确认）、销售运营（现场培训，当前：韩诗琪·推断待确认）、财务（收款确认，当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售提单（必填校验）→ ② 机器人发卡片并自动建群 → ③ 群内确认订单信息与订单类型 → ④ 回复预计交付日 → ⑤ 按角色派工 → ⑥ 各节点完成即群内通知并更新状态 → ⑦ 交付培训与验收单上传 → ⑧ 关闭订单
  • 交付结果：每个订单有专属交付群、完整的订单记录（状态、预计交付日、实例 ID、充值、验收单），并以验收单为准关闭
  • 状态依据：已有《交付 SOP（产研）》、交付订单表单、机器人卡片与自动建群，2026-06～10 稳定运行约 80+ 单；但缺“交付时间回执”和状态流转，机器码/实例 ID/充值/行业版靠群内人工接力，自动建群告警约 45 次且曾静默漏转 12 单，销售未提单即排期等问题反复出现。

1. 场景判定

  • 触发条件：合同签订或款项确认后需交付 LeapCore 一体机；渠道下单（含充值、行业版）；渠道托管式交付（机器放公司由渠道使用）。
  • 典型说法：「有新的 LeapCore 交付订单，请查收信息准备部署」「所有要交付的机子都需要先填表」「这种应该走什么流程」
  • 判断问题：机器或服务是否要交给客户/渠道使用并计入销售？是则提单走本流程。
  • 不归本流程管：纯样机借用 → 请走 X-DLV-05；配置与报价 → 请走 X-DLV-01；无货时排期与延期 → 请走 X-DLV-04；外包/POC/Demo 项目 → 请走 X-DLV-08；资产与交付边界 → 请走 X-DLV-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付负责人 维护表单与规则、确认订单、回复交付日、监督进度、关闭订单 A 交付负责人（当前：杨萌·推断待确认）
提单 提交订单、补充信息、现场发手册与收集需求 R 销售（当前：吴琪、闫登辉、杜中瑞、杨朋伟、刘昱潇等·推断待确认）
部署发货 装机、部署、测试、发货/上门、远程支持 R 交付部署工程师（当前：游家豪·推断待确认）
备机 采购、配置、驱动、压测 R 硬件采购工程师（当前：杨明学·推断待确认）
实例与网络 返回实例 ID、网络/WG 配置 R 后端运维（当前：杨云峰·推断待确认）
充值 按订单充值、测试额度 R 模型网关与计费研发（当前：柯逸飞·推断待确认）
开放平台 注册实例、下发行业版与 Logo R 开放平台负责人（当前：郭逸非·推断待确认）
机器人维护 建群机器人、告警修复 R 研发负责人（当前：王皓南·推断待确认）
机器人值班 每日对账订单表与建群结果、处理告警 R 机器人值班人（当前：待指定）
收款确认 确认收款后放行充值 C 财务（当前：待指定）
兜底 非标订单归属、分工争议 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户公司全称（与合同一致）、内部对接人、客户对接人岗位
  • 机型、版本（标准版/行业版/工程版）、席位数、充值金额、是否赠送词元包
  • 交付期限（不得早于提单当天）、交付方式（线上/线下/邮寄）、收货地址
  • 合同/款项状态（未付款须销售负责人特批）
  • 客户网络环境（是否限制外网、是否固定 IP）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在交付订单表单提交（第 3 节字段必填并校验）；不提单不排期 销售 合同签订/款到当天 多维表格表单 / 渠道系统 订单记录 🔧飞书固化
2 机器人发“新订单”卡片，自动建群（群名【Leapcore】+ 客户全称），拉固定成员与内部对接人，转发卡片，回写群链接 建群机器人 提单后 10 分钟内 机器人、多维表格自动化 订单群 🤖自动化
3 群内确认订单信息：行业版、充值额度是否写入合同/CRM、客户网络环境；判定订单类型 交付负责人 提单后 1 个工作日内 订单群 确认记录 👤人工判断
4 结合库存（X-DLV-04）回复预计交付日并写回订单表 交付负责人 提单后 1 个工作日内 订单表 交付日回执 🔧+🤖
5 派工：备机→部署→实例 ID→充值→开放平台注册；各执行人在表中认领并更新状态 交付负责人 回执当天 订单表状态字段 派工记录 🔧飞书固化
6 硬件组装完成、软件部署并跑自动化测试、充值完成，每个节点完成即在订单群通知并更新状态 各执行人 节点完成当天 订单群、测试脚本 测试报告、状态更新 🔧+🤖
7 交付（线上/线下）：设备联电联网，按五步做约 20 分钟培训，发使用/管理员手册 交付部署工程师；销售 承诺交付日 培训手册 培训记录 👤人工判断
8 上传验收单，订单表同步金额，关闭订单；交付后转运维 销售；交付负责人 交付后 3 个工作日内 订单表 验收单、关闭记录 🔧飞书固化
9 每日对账“订单表 vs 已建群/已转发卡片”，处理机器人告警 机器人值班人 每日 10:00 前 告警卡、对账脚本 对账结果 🤖自动化

5. 交付物与模板

  • 交付物：订单记录、订单群、交付日回执、测试报告、充值记录、培训记录、验收单
  • 建议模板/表单：
    • 交付订单表字段：订单号、订单类型（标品/行业版/渠道托管/定制 ISO/联合开发/充值）、客户全称、内部对接人、机型、版本、席位、充值金额、交付期限、交付方式、收货地址、收款状态、状态（待评估/待采购/待部署/待测试/待充值/待交付/已验收/已关闭）、预计交付日、机器码、实例 ID、群链接、验收单附件
    • 建群规则配置表：群名格式、固定成员岗位清单、头像、同一客户多订单是否复用群（默认新建）
    • 机器人告警值班表：值班人、重试次数、升级对象

6. 异常与升级

  • 未提单就要求排期 → 不排期，要求当天补单 → 交付负责人；销售坚持则报销售负责人
  • 提单信息缺失或明显错误（如期限早于当天）→ 退回提单人补全 → 1 个工作日未补自动提醒
  • 自动建群失败或卡片未转发 → 值班人 2 小时内人工拉群并修复 → 当天未恢复升级研发负责人
  • 订单表字段变更 → 变更前通知机器人维护人 → 研发负责人确认后再改
  • 非标订单（联合开发/上门部署/定制 ISO）→ 交付负责人判定类型，商业性质订单仍走交付单 → 无法判定升级 CTO
  • 二级代理要机器 → 先签合同再提单 → 销售负责人
  • 销售查询进度 → 查看订单表状态，不在群内催问 → 超预计交付日未完成由交付负责人当天说明
  • A（升级）说明：订单确认、派工与关闭由交付负责人拍板（A）；非标订单类型无法判定、跨团队分工争议在交付负责人处 1 个工作日内未解决时升级 CTO

7. 衡量指标

  • 交付日回执及时率 = 1 个工作日内回复交付日的订单 / 订单总数，目标 ≥ 95%
  • 订单交付周期 = 提单到验收单上传的自然日，目标：现货标品 ≤ 7 天
  • 自动建群成功率 = 10 分钟内成功建群订单 / 订单总数，目标 ≥ 98%
  • 提单信息一次完整率 = 无需补充信息的订单 / 订单总数，目标 ≥ 90%
  • 验收单回收率 = 有验收单的已交付订单 / 已交付订单，目标 100%

8. 低效诊断

  • 现象：提单后缺少“交付时间回执”，表格无状态流转，出现忘记跟进、空订单、交付期限填错｜依据：「LeapCore 交付订单通知群」2026-06、2026-07、2026-09
  • 现象：建群机器人反复出错（漏拉人、群名不规范、同客户两单混群），权限与机器人互通限制调试多日，规则靠聊天追加｜依据：「交付订单通知群」2026-06、2026-07
  • 现象：自检告警约 45 次且只通知单一岗位，提交时间格式错误导致 12 个订单卡片约 3 周未转发｜依据：「交付订单通知群」2026-08、2026-09
  • 现象：每台机器都需在群里手工贴机器码、要实例 ID、催充值，行业版是否部署到部署时才问，销售反复催“给个准确时间”约 10 次｜依据：「某客户交付群」2026-08、2026-09，「某地方政府客户交付群」2026-07
  • 现象：销售未提单就口头要货，排期发出后被迫撤回｜依据：「leapcore软硬件交付」2026-09
  • 现象：渠道系统与 v5 cloud 交付流程重复建设，企业信息在多个系统各存一份，合同与发票未接入｜依据：「鼎慧产研决策部」2026-07、2026-08，「Leap产研决策部」2026-09
  • 现象：渠道订单与拉群机制未打通，渠道里无法区分谁卖出，二级代理不知找谁拿机器｜依据：「公司内FDE」2026-09、2026-10
  • 现象：非标订单（联合开发、上门部署、定制 ISO）出现后才问走什么流程｜依据：「交付订单通知群」2026-09

9. 分支变体

  • 标品订单 vs 行业版/工程版订单（需开放平台下发行业版）vs 充值订单（只走充值与开通）
  • 渠道订单：渠道系统提单 → IT 配置预审 → 商务审核 → 财务确认收款 → 硬件准备 → 部署/充值/开通 → 验收关闭；需绑定商务人员
  • 支付方式：线上个人扫码 / 企业网银收银台 / 线下汇款（财务确认收款后充值）
  • 客户自有机器部署（硬件限制席位）/ 源核一体机发货 / 渠道托管式交付（也走交付单）
  • 内部测试订单：标注“测试勿动”，不计入指标

10. 待确认问题

  • 交付负责人是否为唯一主责？部署发货是否成立独立交付团队？
  • 交付订单最终以渠道系统还是多维表格为唯一入口？切换时间？
  • 建群机器人值班人是谁？告警只通知交付负责人是否改为值班制？
  • 交付日回执 1 个工作日、验收单 3 个工作日内上传是否可行？
  • 非标订单分类规则由谁制定？是否已有成文制度？
  • 《交付 SOP（产研）》中含设备默认凭据，是否需要移出并脱敏？
X-DLV-08交付项目台账与立项留痕待优化180

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：出现外包项目、POC、定制化项目或市场/销售 Demo 服务器部署需求时，统一登记项目台账、确认已走商务流程、指定责任人，并做技术留痕与工时登记直至结项。
  • 负责人：主责——FDE Leader/项目业务负责人（当前：黄振锋·推断待确认）；协同——CTO（台账与评审，当前：丁震宇·推断待确认）、COO（商务，当前：常元和·推断待确认）、基座研发负责人（水利类项目，当前：望政韬·推断待确认）、硬件与 IT 运维（Demo 服务器部署，当前：杨明学·推断待确认）、总经办（工时口径与需求整理，当前：田杰·推断待确认）、综合部负责人（合规与财务视角，当前：赵雪冰·推断待确认）、PRM 开发（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；决策——CEO（当前：邴龙志·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 填写项目开发申请 → ② 商务确认 → ③ 立项评审与指定专班责任人 → ④ PRM/台账登记 → ⑤ Demo/服务器部署申请 → ⑥ 每周工时登记与进度更新 → ⑦ 材料与会议归档 → ⑧ 验收结项或手动结束
  • 交付结果：每个项目在 PRM/台账中有唯一记录（商务状态、责任人、里程碑、工时、材料、验收单），结项后工时转运维成本
  • 状态依据：已有项目台账多维表格、《项目开发申请填写 SOP》和 PRM 系统，但 2026-02～10 台账状态不全（显示“都是未开工”）、有项目未走商务流程即开工、文档难找；PRM 上线后负责人一度不明、与 CRM/合同系统边界不清。

1. 场景判定

  • 触发条件：客户提出定制开发、POC、方案报价需求；市场/销售需要 Demo 或客户试用服务器；研发准备为客户投入人力。
  • 典型说法：「以后咱们手上的项目都要统一管理」「最近很多 Demo 客户想要试用，有服务器部署需求」「最终没签约的项目如何正式结束」
  • 判断问题：这项工作是否为特定客户投入定制人力或服务器资源？是否不属于标品一体机交付？
  • 不归本流程管：标品一体机交付 → 请走 X-DLV-07；样机借用 → 请走 X-DLV-05；标准化商机直接签约 → 请走 SAL-23（销售合同起草、条款谈判与用印）；合同审核 → 请走 LEG-03（销售合同审查与多方会签）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目业务负责人 审核方案/报价、分配技术人员、推进立项 A FDE Leader（当前：黄振锋·推断待确认）
商务/市场负责人 填写项目申请、推进商务与合同、未签约项目手动结束 R 销售/市场（当前：时建·推断待确认）；COO（当前：常元和·推断待确认）
专班责任人 项目执行、进度与里程碑更新 R 技术负责人（当前：按项目指定，如水利类：望政韬·推断待确认）
技术人员 文档化、每周登记工时 R 研发/FDE（当前：按项目指定）
Demo 部署 Demo/试用服务器部署 R 硬件与 IT 运维（当前：杨明学·推断待确认）
工时与合规 工时口径、虚拟项目归集、审计要求 C 总经办（当前：田杰·推断待确认）；综合部负责人（当前：赵雪冰·推断待确认）
系统 PRM 维护与对接 C PRM 开发（当前：陈子康·推断待确认）
台账与评审 参与立项评审、指定或暂缓无责任人项目 C CTO（当前：丁震宇·推断待确认）
决策 未签约提前投入特批、无收入项目是否推进 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 市场负责人、客户全称、项目名（客户简称 + 主题）、一句话需求、附件
  • 商务状态：是否已报价、是否已签合同；未签约需说明为何提前投入
  • 预计投入人力与周期、是否需要服务器/Demo 环境
  • 项目分级建议：已签约 / POC / 无收入
  • 关联的会议记录与客户材料

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写“项目开发申请”表单；同一项目不重复提交，后续补充到原项目 商务/市场负责人 需求出现后 1 个工作日内 项目申请表单 / PRM 项目记录 🔧飞书固化
2 商务确认：确认报价/合同状态；未签合同不得开工，客户要求提前投入走特批 商务/市场负责人；CEO（特批） 提交后 2 个工作日内 飞书审批 商务确认/特批记录 🔧+👤
3 立项评审：分级（已签约/POC/无收入）、指定专班责任人与里程碑；无责任人的项目不启动 项目业务负责人；CTO 商务确认后 2 个工作日内 PRM 立项记录 👤人工判断
4 方案/报价材料审批（可加签） 项目业务负责人 提交后 2 个工作日内 PRM 审批 审批通过的方案/报价 🔧飞书固化
5 需要 Demo/试用服务器时提交部署申请，运维部署并登记资源 专班责任人；硬件与 IT 运维 申请后 2 个工作日内 部署申请、资源台账 可用 Demo 环境 🔧飞书固化
6 每周登记工时、更新状态与里程碑；POC/无合同工时计入虚拟项目，签约后划入合同项目 技术人员；专班责任人 每周五 18:00 前 PRM、通知中心提醒 工时与进度记录 🔧+🤖
7 客户会议、方案、报价、案例按项目名归档 专班责任人 会议/产出后 1 个工作日内 会议记录表单、材料录入表单 归档材料 🔧飞书固化
8 结项：上传验收单经法务审核后结束，之后工时计运维成本；未签约项目由市场负责人手动结束，管理员兜底 专班责任人；商务/市场负责人 验收后 3 个工作日内；未签约确认后 5 个工作日内 PRM 结项记录 👤人工判断

5. 交付物与模板

  • 交付物：项目申请记录、商务确认/特批记录、立项记录、方案报价审批、Demo 资源登记、周工时记录、会议与材料归档、验收单与结项记录
  • 建议模板/表单（项目台账字段）：项目编号、项目名、客户全称、市场负责人、专班责任人、分级（已签约/POC/无收入）、商务状态（未报价/已报价/合同审核中/已签约/特批）、阶段（申请/立项/实施/验收/结项/终止）、里程碑与计划日期、累计工时、Demo 资源、是否 LeapCore 相关、最近更新时间

6. 异常与升级

  • 未走商务流程已开工 → 立即补商务确认，补不了暂停投入 → CEO 2 个工作日内决定继续或终止
  • 项目无专班责任人 → 不进入实施 → CTO 指定或暂缓
  • 工时连续 2 周未登记 → 系统提醒并抄送专班责任人 → 项目业务负责人
  • PRM 与 CRM/合同系统数据不一致 → 以合同系统为准，记录差异 → 综合部负责人
  • 项目超期或状态 2 周未更新 → 专班责任人说明 → 项目业务负责人，持续 4 周升级 CEO
  • A（升级）说明：立项、分级与方案报价审批由项目业务负责人拍板（A）；未签合同需提前投入、无收入项目是否推进、未走商务流程已开工、项目持续 4 周停滞时升级 CEO

7. 衡量指标

  • 先立项后开工率 = 立项后才投入人力的项目 / 项目总数，目标 100%
  • 台账状态新鲜度 = 近 14 天内有更新的在建项目 / 在建项目，目标 ≥ 95%
  • 工时登记率 = 按周登记工时的人周 / 应登记人周，目标 ≥ 95%
  • 项目结项及时率 = 验收后 3 个工作日内结项的项目 / 已验收项目，目标 ≥ 90%

8. 低效诊断

  • 现象：项目汇总文档入口隐蔽，管理层需展开侧边知识库才能找到｜依据：「董事会」2026-02
  • 现象：台账中项目均显示“未开工”，状态不全；有项目未走商务流程即启动，项目没有专班责任人｜依据：「董事会」2026-08
  • 现象：PRM 上线后负责人一度不明，角色命名（负责人/主管）混乱，与 CRM、合同系统、研发工单边界不清导致统计口径不一致，未签约项目不知如何结束｜依据：「项目管理系统（prm）交流群」2026-09、2026-10

9. 分支变体

  • 标准化商机直接进合同系统；非标商机进 PRM
  • 商务主导项目 / 研发直接带的 POC（须补商务确认）/ 水利、教育等行业项目（由对应技术负责人任专班）
  • 报价阶段与实施阶段分开计工时；POC 工时归虚拟项目
  • 市场/销售 Demo 试用：只需部署申请 + 资源登记，转正式项目时补立项

10. 待确认问题

  • 项目台账主责是 FDE Leader 还是 CTO？PRM 系统归属哪个部门？
  • “未签合同不得开工、特批例外”是否已成文？特批人是谁？
  • 项目分级标准（有收入/无收入）及无收入项目的审批门槛？
  • 工时每周五登记是否可行？虚拟项目工时口径是否经财务确认？
  • Demo 服务器部署 SOP 由谁维护，是否并入本流程？
X-DLV-09交付项目启动会与客户资料收集待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：客户合同双方盖章生效（或首款到账）后，需要拉齐双方对接人与职责、交付里程碑、开票安排，并向客户收齐数据集/业务样例/参考资料时启动
  • 负责人：主责——交付项目经理（当前：王皓南·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、商务负责人（当前：常元和·推断待确认）、产品总监（当前：杨萌·推断待确认）、业务专家（当前：王满·推断待确认）、IT 运维（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 签约生效通知 → ② 开票申请 → ③ 内部预备会定分工 → ④ 发启动会邀请与资料清单 → ⑤ 召开启动会 → ⑥ 纪要与任务下发 → ⑦ 资料签收与催办 → ⑧ 资料可用性确认并转入部署/培训
  • 交付结果：启动会纪要（双方对接人表、项目 RACI、里程碑、验收口径）、客户资料签收表、已提交的开票申请、指派到人的飞书任务
  • 状态依据：无固定启动清单。2026-05 签约后由客户经理在群里临时提议开票、拉启动会，培训案例临时“asap”索要；2026-02 客户数据集未到，研发停工待料，靠管理层亲自催约 4 次；2026-04 政企项目会议未通知相关方，需会后人工补同步

1. 场景判定

  • 触发条件：合同盖章完成或首款到账；POC 转正式合同；长周期政企项目进入新阶段
  • 典型说法：「那边已经盖章，我们要开发票过去了，拉一个项目启动会」「什么时候催他们给语音数据集」「有项目管理还是太重要了」
  • 判断问题：合同是否已生效？是否包含硬件安装、部署、培训、训练/测试等交付动作（纯 API/额度销售不走本流程）？是否需要客户提供数据、样例或环境信息？
  • 不归本流程管：订单受理与建交付群 → 请走 X-DLV-07；项目立项台账 → 请走 X-DLV-08；定制需求拆解排期 → 请走 X-DLV-10；装机与部署 → 请走 X-DLV-13 / X-DLV-19；客户培训 → 请走 X-DLV-28；合同开票 → 请走 FIN-19；合同外新增需求 → 请走 SAL-25

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付项目经理 召集预备会与启动会、定分工与里程碑、发纪要、跟踪任务 A/R 交付项目经理（当前：王皓南·推断待确认）
客户经理 对客约时间、发资料清单、催收资料、发起开票 R 客户经理（当前：吴琪·推断待确认）
商务负责人 政企/大客户高层对接，资料逾期时向客户高层催办 R 商务负责人（当前：常元和·推断待确认）
产品总监 讲解方案、确认交付范围、参会 C 产品总监（当前：杨萌·推断待确认）
业务专家 准备培训案例与脚本 C 业务专家（当前：王满·推断待确认）
IT 运维 确认硬件安装排期与现场条件 C IT 运维（当前：杨明学·推断待确认）
研发接收人 接收客户资料并确认可用 C 研发工程师（当前：杨云峰、陈晖·推断待确认）
财务专员 按合同节点开票 R 财务专员（当前：待指定）
研发负责人 交付优先级冲突拍板 I 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已盖章合同及附件：交付范围、配置、交付期、验收条款、开票与付款节点
  • 客户侧对接人：业务负责人、IT/网络负责人、系统管理员、财务（开票信息）
  • 已建立的交付群/项目群（未建先走 X-DLV-07）
  • 《客户资料清单》草稿：数据集、业务表头样例、参考报告、用户名单、网络环境信息
  • 内部参与人员档期（硬件、部署、培训、产品）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在交付群发“签约生效”通知，附合同交付条款摘要 客户经理 盖章当日 飞书群 / CRM 签约通知 🔧飞书固化
2 按合同开票节点提交开票申请 客户经理 盖章后 1 个工作日内 飞书审批 开票申请 🔧飞书固化
3 内部预备会：指定交付项目经理、分工、里程碑草案，定稿资料清单 交付项目经理 盖章后 2 个工作日内 飞书会议 / 多维表格 内部分工表 👤人工判断
4 向客户发启动会邀请与《客户资料清单》，约定资料交付日期 客户经理 预备会后 1 个工作日内 企业微信 / 邮件 邀请 + 清单 🔧+🤖
5 召开启动会：双方对接人与职责、里程碑、验收口径、资料交付日、沟通窗口（客户急事统一由客户经理接） 交付项目经理 盖章后 5 个工作日内 飞书会议 + 妙记 会议记录 👤人工判断
6 发启动会纪要，待办转飞书任务指派到唯一负责人，抄送全部相关方（含未参会方） 交付项目经理 会后 1 个工作日内 飞书妙记 / 任务 纪要 + 任务 🤖自动化
7 资料签收登记；到期前 1 天自动提醒；逾期由客户经理催，逾期 2 个工作日升级商务负责人 客户经理 按约定日期 多维表格 + 提醒机器人 资料签收表 🔧飞书固化
8 研发确认资料格式与完整性，可用即转入部署/开发/培训 研发接收人 收到后 2 个工作日内 飞书云盘 可用性确认 👤人工判断

5. 交付物与模板

  • 交付物：启动会纪要、项目 RACI 表、里程碑计划、客户资料签收表、开票申请记录
  • 建议模板/表单：
    • 启动会纪要模板：客户、合同编号、交付范围、双方对接人（姓名/岗位/职责/联系渠道）、里程碑（硬件安装、部署、培训、验收）、验收口径、风险、待办（负责人/截止日）
    • 资料清单与签收表：资料名称、用途、格式要求、客户提供人、约定日期、实际到达日期、存放位置、研发确认人、可用性结论

6. 异常与升级

  • 合同已盖章但 3 个工作日内未开启动会 → 交付项目经理补开 → 升级研发负责人（第 4 个工作日）
  • 客户资料逾期 → 客户经理催办 → 逾期 2 个工作日升级商务负责人，影响里程碑的同步调整交付期并书面告知客户
  • 资料不可用（格式错、样本不足） → 研发列出补充要求 → 客户经理 1 个工作日内转客户
  • 会议出现职责争议 → 当场记录争议项 → 会后 1 个工作日内由交付项目经理定 RACI，必要时升级研发负责人
  • 培训素材未就绪 → 业务专家按启动会日期倒排，晚于培训前 3 个工作日未就绪升级交付项目经理

7. 衡量指标

  • 启动会及时率 = 盖章后 5 个工作日内完成启动会的项目数 / 新签交付项目数，目标 ≥ 90%
  • 资料按期到达率 = 按约定日期到达的资料项 / 全部资料项，目标 ≥ 80%
  • 待料停工天数 = 研发因客户资料未到无法开工的工作日数，目标 ≤ 3 天/项目
  • 纪要到位率 = 会后 1 个工作日内发出纪要并建任务的会议数 / 项目会议数，目标 100%

8. 低效诊断

  • 现象：签约后启动动作无清单，开票、启动会、培训素材靠临时提议，培训脚本“asap”临时索要｜依据：「字字可研项目群」2026-05
  • 现象：客户数据集、样例未到，研发待料停工，需管理层反复催办｜依据：「跃迁基座项目交付沟通」2026-02
  • 现象：长周期政企项目会议大量时间用于厘清责任，会后需人工给相关方补同步｜依据：「鼎慧产研决策部」2026-04
  • 现象：客户沟通在企业微信、内部协同在飞书，对客承诺与内部排期割裂｜依据：「字字可研项目群」2026-05

9. 分支变体

  • 本地机器/一体机交付：启动会后转 X-DLV-13 装机与 X-DLV-19 上门部署，启动会需明确安装日期与客户机房条件
  • 云端部署交付：无硬件环节，启动会重点为组织账号开通（X-DLV-15）与培训日期
  • 训练/测试类项目：资料清单必须含数据集、业务样例、验收样本，资料未齐不排开发
  • 政企/长周期项目：固定周会 + 纪要模板 + 项目 RACI，所有相关方必须在会议邀请名单中

10. 待确认问题

  • 交付项目经理由谁担任：研发侧交付总调度，还是由产品/交付统筹担任？
  • 启动会“盖章后 5 个工作日内”是否可行？首款未到账是否也启动？
  • 开票节点是否统一为“盖章后开票”，还是按合同分期？发起人是客户经理还是财务？
  • 客户沟通是否允许继续用企业微信？对客记录如何回流飞书？
  • 是否已有成文的启动会模板或交付总 SOP 中的“合同签订”阶段可直接复用？
X-DLV-10客户定制需求承接、拆解与排期待优化320

状态：待优化｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频4 × 耗4 × 跨5 × 险4

  • 适用场景：签约客户或合作伙伴提出合同约定的交付内容，或超出标品的定制功能（账单/计费口径、账号打通、专属管理页、API Key 统计限量、客服机器人、特定模型部署等）时，从需求对齐到拆单、派工、排期、验收全程管理
  • 负责人：主责——交付需求收口人/产品总监（当前：杨萌·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、对客窗口商务负责人（当前：常元和·推断待确认）、产品经理（当前：黄飞鹏·推断待确认）、研发工程师（当前：邓乾、宋祺睿、魏宗浩·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 需求登记 → ② 合同范围核对 → ③ 可行性与技术路线评估 → ④ 范围与对客口径确定 → ⑤ 对客书面确认 → ⑥ 拆单绑迭代派工 → ⑦ 周度进度同步 → ⑧ 验收闭环
  • 交付结果：客户需求登记条目（关联合同条款）+ Gitea 工单（迭代、唯一负责人、点数）+ 客户确认的范围与交付日期 + 验收记录
  • 状态依据：已有“对外统一收口”“迭代/milestone 排期”“AI 建工单”等做法；但 2026-03～07 同一需求“谁做”反复变更约 4 次，合同交付项靠口头对齐，需求未评估可行性就先投入调研，进度同步对象不明

1. 场景判定

  • 触发条件：合同条款/附件约定交付功能；客户或合作伙伴在群里提出新功能或改造；客户临时询问能否部署某模型或采用某技术方案
  • 典型说法：「客户的一切进度安排和问题都需要同步给对客负责人」「这个客户的交付需求应该优先级大于所有」「明天重新对一下需求吧」「要的是最终的效果，你跟他聊技术方案没意义」
  • 判断问题：是否已签约、有合同依据？需求在合同范围内还是范围外？标品配置能否满足？是否需要另行报价？
  • 不归本流程管：售前 Demo → 请走 SAL-14；定制评估与报价特批 → 请走 SAL-21 / X-PRD-11；合同外需求拦截 → 请走 SAL-25；通用需求池 → 请走 X-PRD-09；品牌/白牌定制 → 请走 X-DLV-11；已交付客户的新功能承诺 → 请走 X-CS-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付需求收口人 登记需求、核对合同范围、确定范围、验收闭环 A/R 产品总监（当前：杨萌·推断待确认）
Leap 研发负责人 指定评估人、定技术路线、派工、优先级冲突初裁 R Leap 研发负责人（当前：王皓南·推断待确认）
对客窗口 唯一对客沟通口，书面确认范围与日期 R 商务负责人（当前：常元和·推断待确认）
产品经理 拆单、绑迭代、周度进度同步 R 产品经理（当前：黄飞鹏·推断待确认）
研发工程师 可行性评估、开发、自测 R 研发工程师（当前：邓乾、宋祺睿、魏宗浩·推断待确认）
研发负责人 路线分歧与跨项目优先级终裁 C 研发负责人（当前：丁震宇·推断待确认）
客户经理 提供合同与客户背景 C 客户经理（当前：吴琪·推断待确认）

3. 办之前请准备

  • 合同文件及交付条款（交付期、交付物、验收标准）
  • 需求原文（会议纪要、聊天截图、客户需求清单），注明提出人与期望日期
  • 客户环境信息：测试/生产环境、账号、网络条件
  • 可复用模块清单（已有仓库、行业资料、同类客户方案）
  • 当前迭代容量与在途客户需求列表

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记需求：客户、来源、合同条款号、期望日期、对客窗口、环境（测试/生产） 交付需求收口人 收到后 1 个工作日内 多维表格“客户需求登记” 需求条目 🔧飞书固化
2 核对合同范围；合同外需求转 SAL-25 / SAL-21 交付需求收口人 + 客户经理 登记后 1 个工作日内 合同 / CRM 范围判定 🤖+👤（AI 抽取合同交付条款）
3 可行性与技术路线评估：复用模块、方案选项、外部限制、点数；调研超过 0.5 天须先报研发负责人 研发负责人指定的评估人 登记后 2 个工作日内 Gitea / 飞书文档 评估结论 👤人工判断
4 确定范围（做/分期/不做）与对客口径：技术路线由研发负责人定，话术由对客窗口出 交付需求收口人 + Leap 研发负责人 评估后 1 个工作日内 飞书文档 范围确认单 👤人工判断
5 对客书面确认范围与交付日期 对客窗口 范围确定后 2 个工作日内 企业微信 / 邮件 客户确认记录 👤人工判断
6 拆单：每项一个工单，绑迭代/milestone，指定唯一负责人与点数，关联需求条目 产品经理 客户确认后 1 个工作日内 Gitea（可由 NK AI 建单） 工单 🤖自动化
7 每周推送进度到对客窗口与交付群；预计延期提前 2 个工作日预警 产品经理 每周一 进度机器人 进度周报 🔧+🤖
8 工单完成后验收（测试 + 业务），通知对客窗口回告客户，关闭需求条目 交付需求收口人 工单关闭后 1 个工作日内 Gitea / 飞书任务 验收记录 🔧飞书固化

5. 交付物与模板

  • 交付物：客户需求登记表、评估结论、范围确认单、工单、进度周报、验收记录
  • 建议模板/表单：
    • 客户需求登记：需求编号、客户、来源渠道、合同条款号、合同内/外、需求描述、期望日期、对客窗口、环境、评估人、点数、迭代、负责人、状态、验收结论
    • 范围确认单：需求项、做/分期/不做、理由、交付日期、对客话术、确认人

6. 异常与升级

  • 派工后负责人变更 → 产品经理更新工单并通知 → 同一需求第 2 次变更升级 Leap 研发负责人（当日）
  • 客户诉求与内部技术路线冲突 → 研发负责人定路线、对客窗口出口径 → 1 个工作日内答复
  • 合同交付期内多个需求冲突 → Leap 研发负责人初裁 → 仍冲突升级研发负责人（1 个工作日）
  • 客户绕过窗口直接问研发 → 研发不直接答复非软件故障问题，转对客窗口
  • 评估结论为不可行 → 停止调研，对客窗口给替代方案或说明 → 2 个工作日内

7. 衡量指标

  • 需求登记率 = 已登记客户需求 / 群内识别出的客户需求，目标 100%
  • 评估时长 = 登记到出评估结论的工作日，目标 ≤ 2 天
  • 负责人变更次数 = 派工后负责人变更次数/需求，目标 ≤ 1
  • 合同交付项按期率 = 按合同日期验收的需求项 / 到期需求项，目标 ≥ 90%

8. 低效诊断

  • 现象：派工环节同一需求“谁做”反复调整约 4 次，派工后需管理层追问是否闭环｜依据：「鼎慧产研决策部」2026-07
  • 现象：受理环节未先评估可行性，开发调研后才发现渠道限制无法实现，需求需重新对齐｜依据：「鸽子群模态分群」2026-03
  • 现象：合同条款转需求靠口头对齐，“还有什么是交付需要的”需反复确认，进度靠催问｜依据：「鼎慧产研决策部」2026-04
  • 现象：进度同步给谁不明确，客户需求靠会议和群转述，测试账号与生产账号混淆｜依据：「Leap产研测」2026-06
  • 现象：客户诉求与内部路线不一致，方案靠转发确认，可复用模块靠口头推荐｜依据：「董事会」2026-07

9. 分支变体

  • 合作伙伴预装：订单计费口径、账单、账号打通（OIDC），可分期，先做显示类改动
  • 燃气类企业客户：API 管理页、Key 统计限量、余额并入企业余额；对外统一由对客窗口收口
  • 工程咨询客户合同：初期交付（专家版报告）+ 三个月交付期内其余需求分迭代排入，迭代会后复核风险
  • 超出现有能力的需求：转技术咨询，给出可行性结论后再决定是否砍
  • 客户坚持模型训练：先做小规模 PoC 盲测，再决定是否训练

10. 待确认问题

  • 客户定制需求的主责是产品总监还是 Leap 研发负责人？对客窗口是否固定为商务负责人？
  • 评估时限 2 个工作日、调研上限 0.5 天是否可行？
  • 客户需求登记表是否与 X-PRD-09 需求池合并，还是独立维护？
  • 合同交付项优先级是否一律高于常规迭代需求？
  • 对客书面确认是否必须（邮件/企业微信截图哪种算数）？
X-DLV-11行业版与白牌定制交付待新建240

状态：待新建｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：订单要求行业版、特殊 Skill/场景包，或客户/渠道要求专属品牌（名称、Logo、帮助中心、客户端安装包、管理后台）时，完成定制配置、打包发版与交付
  • 负责人：主责——交付产品负责人（当前：杨萌·推断待确认）；协同——开放平台负责人（当前：郭逸非·推断待确认）、客户端打包/OTA（当前：葛家和·推断待确认）、管理后台与部署（当前：杨云峰、宋祺睿·推断待确认）、测试（当前：李国庆、张东郅·推断待确认）、行业 Skill 提供（当前：陈锦杰·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 订单评审识别定制项 → ② 能力评估 → ③ 素材收集 → ④ 开放平台注册企业与配置下发 → ⑤ 管理后台/客户端包定制 → ⑥ 行业 Skill 与渠道切换 → ⑦ 测试服验证 → ⑧ 放行发包 → ⑨ 定制配置归档
  • 交付结果：客户可用的定制版本（品牌、帮助中心、行业 Skill 均生效）、定制检查清单验收记录、企业定制配置台账
  • 状态依据：交付 SOP 被要求补充行业版分支，但群内仍问“真的有这个 SOP 吗”；2026-07～09 每次定制发包逐项人工确认，出现 Logo 白底、思考提示仍显示原产品名、基于过新版本打包混入未上线功能、在正式服传测试包等返工；渠道演示机反复“改头换面”约 8 次

1. 场景判定

  • 触发条件：订单勾选行业版/特殊 Skill/场景包/界面定制；客户要求换名称或 Logo；渠道要求演示机去除本公司品牌痕迹
  • 典型说法：「交付 SOP 补充一下，对于行业版……要通知开放平台注册」「改客户端包 -> 让他们下新包」「需要明早把机子换成甲方 logo，下午再换成另一家的」
  • 判断问题：定制项能否通过开放平台配置下发（不打包）？是否涉及管理后台或安装包？距交付日是否 ≥ 5 个工作日？渠道品牌使用是否有授权？
  • 不归本流程管：定制工作量评估与报价 → 请走 SAL-21 / X-PRD-11；Skill 审核上架与下发 → 请走 X-FDE-09；常规打包签名 → 请走 RND-52；OTA 推送 → 请走 RND-53；hotfix 准入 → 请走 RND-54；样机借用 → 请走 X-DLV-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付产品负责人 识别定制项、维护清单、发包给客户、归档 A/R 交付产品负责人（当前：杨萌·推断待确认）
Leap 研发负责人 能力评估、发版方式（迭代/hotfix）拍板、放行 R Leap 研发负责人（当前：王皓南·推断待确认）
开放平台负责人 注册企业、配置 Logo/名称/提示词/帮助中心 URL、云控切换 R 开放平台负责人（当前：郭逸非·推断待确认）
客户端打包 Win/Mac 定制包、OTA 渠道配置 R 客户端研发（当前：葛家和·推断待确认）
后台与部署 管理后台定制、行业渠道切换、帮助中心部署 R 后端研发（当前：杨云峰、宋祺睿·推断待确认）
测试 按定制检查清单验收 R 测试（当前：李国庆、张东郅·推断待确认）
行业 Skill 提供 提供并打包行业 Skill C 研发工程师（当前：陈锦杰·推断待确认）
客户经理 收集客户素材、对客确认 C 客户经理（当前：吴琪·推断待确认）
渠道需求方 提交演示机品牌切换预约 C 区域销售负责人（当前：刘昱潇·推断待确认）
交付工程师 指定演示/交付机器与实例 C 交付工程师（当前：游家豪·推断待确认）

3. 办之前请准备

  • 订单与定制项清单（行业版类型、Skill/场景包、名称、Logo、帮助中心、安装包、管理后台）
  • 素材：透明底 Logo（SVG + PNG）、产品名（≤ 8 字）、身份提示词、帮助中心内容
  • 当前生产基线版本号（打包须基于该版本）
  • 企业 ID / 机器实例 ID
  • 渠道演示：品牌授权依据、演示时间、机器、余额

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 订单评审时在交付表勾选定制项，自动 @ 开放平台负责人和研发负责人 交付产品负责人 订单受理后 1 个工作日内 多维表格交付表 定制项清单 🔧飞书固化
2 能力评估：可配置下发项 / 需打包项 / 未支持项；未支持项回 SAL-21 或调整交付日 Leap 研发负责人 识别后 2 个工作日内，且距交付日 ≥ 5 个工作日 Gitea 工单 评估结论 👤人工判断
3 收集并校验素材（透明底、尺寸、名称字数），存入素材库 客户经理 评估后 2 个工作日内 飞书云盘素材库 素材包 👤人工判断
4 开放平台注册企业，配置 Logo/名称/提示词/帮助中心 URL 开放平台负责人 素材到齐后 1 个工作日内 开放平台 企业配置 🔧+👤
5 管理后台定制走 hotfix（基于生产基线，不得基于开发中版本）；客户端 Win/Mac 包定制、签名公证、OTA 渠道配置 客户端打包 + 后台研发 交付日前 3 个工作日 CI / OTA 定制包 🤖+👤
6 行业版：镜像内置行业 Skill，LeapUpdate 注册时切换行业渠道，版本对齐 后台与部署 部署当日 LeapUpdate 渠道配置记录 🔧+🤖
7 测试服按定制检查清单验证（安装包图标、快捷方式、侧栏/标题/站点图标、思考提示文案、帮助中心链接、行业 Skill、提示词） 测试 交付日前 2 个工作日 测试服 验收记录 🤖+👤
8 放行后发包 / 云控切换，代码合入主分支 Leap 研发负责人放行，交付产品负责人发包 交付日 OTA / 开放平台云控 交付记录 👤人工判断
9 归档企业定制配置（企业 ID、配置项、包版本、帮助中心 URL、素材位置） 交付产品负责人 交付后 1 个工作日内 多维表格 定制台账 🔧飞书固化

5. 交付物与模板

  • 交付物：定制项清单、评估结论、定制包、测试验收记录、企业定制配置台账
  • 建议模板/表单：
    • 定制检查清单：企业 ID、基线版本、名称、Logo（客户端/后台/站点/安装包/快捷方式）、思考提示文案、身份提示词、帮助中心 URL、行业渠道、行业 Skill、OTA 渠道、签名公证、验收人、结论
    • 演示机品牌预约表：日期时段、品牌、机器/实例 ID、余额、申请人、授权依据、切回时间、回收状态

6. 异常与升级

  • 定制项距交付日不足 5 个工作日 → 交付产品负责人与客户经理协商分期交付 → 升级 Leap 研发负责人（当日）
  • 打包失败或 CI 不支持定制包 → 改为配置下发或管理员后台上传 Logo → 1 个工作日内给替代方案
  • 定制包混入未上线功能或发错渠道 → 立即撤回，按 RND-54 重发 → 升级 Leap 研发负责人（2 小时内）
  • 误配导致暴露其他客户品牌或信息 → 立即回滚配置 → 升级研发负责人与安全负责人（1 小时内）
  • 渠道要求去除本公司品牌但无授权依据 → 暂停切换 → 升级销售负责人判断（当日）

7. 衡量指标

  • 定制一次验收通过率 = 测试服首次验收全部通过的定制单 / 定制单总数，目标 ≥ 85%
  • 定制按期交付率 = 按约定日期交付的定制单 / 定制单总数，目标 ≥ 90%
  • 定制返工次数 = 交付后因品牌/配置错误重发的次数，目标 0
  • 演示切换提前量 = 预约时间早于演示时间的小时数，目标 ≥ 24 小时

8. 低效诊断

  • 现象：订单已排期才评估定制能力，管理后台定制尚未支持，临近交付紧急开发｜依据：「Leap产研测」2026-07
  • 现象：打包发版环节基线版本选错、在正式服传测试包，“发迭代还是 hotfix”口径不一｜依据：「Leap产研测」2026-08
  • 现象：验收不全，Logo 白底、思考提示仍显示原产品名，靠产品人员事后发现｜依据：「Leapcore〔燃气客户〕交付群」2026-08
  • 现象：行业版交付步骤找不到 SOP 实体，部署时漏配渠道、容器未启动｜依据：「Leapcore〔工程咨询客户〕交付群」2026-07、2026-09
  • 现象：帮助中心谁改谁部署不清、忘提单，Logo 文件在群里反复传｜依据：「【行业版Leapcore】工程版」2026-08
  • 现象：渠道演示机频繁换品牌，演示前一晚才准备，不清楚机器与实例对应，内网地址账号在群里发｜依据：「〔渠道伙伴〕合作群」2026-09

9. 分支变体

  • 燃气类企业客户白牌：客户端包 + 管理后台 + 开放平台三线并行，Mac 包需签名公证与隔离属性处理
  • 工程咨询行业版：企业名称 + Logo + 差异化帮助中心 URL（开放平台按企业透传），更新日志/OTA 弹窗需适配
  • 行业版（工程版）交付：镜像内置行业 Skill、注册时切换行业渠道、部署后用提示词验证
  • 渠道演示机白标：按预约切换品牌（名称 ≤ 8 字），切换后重新登录刷新，检查余额，演示后切回，机器回收后台账注销
  • 投资人版等尚无品牌素材的行业版：先用默认品牌，素材到位后走步骤 3～8

10. 待确认问题

  • 主责是交付产品负责人还是开放平台负责人？演示机白标是否由销售侧主责？
  • “距交付日 ≥ 5 个工作日”的定制评估门槛是否可行？
  • 管理后台定制是否统一走 hotfix？是否规划“企业配置后台”替代逐个打包？
  • 渠道使用自有品牌演示我方产品，是否需要合同或授权书作为前提？
  • 行业版交付 SOP 现存文档位置在哪？由谁维护？
X-DLV-12批量装机镜像（ISO/OOBE）制作与发版协同待新建120

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨3 × 险5

  • 适用场景：批量出货、新机型首批出货或客户要求扩容时，需要确定出厂规格、制作并验收 ISO/OOBE 镜像，并与软件发版节奏对齐
  • 负责人：主责——镜像/OOBE 负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件规格（当前：杨明学·推断待确认）、存储方案（当前：吴世豪·推断待确认）、发版（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付工程师（当前：游家豪·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 出厂规格确认 → ② 预装版本冻结 → ③ ISO/OOBE 制作 → ④ 镜像验收 → ⑤ 试产 3 台 → ⑥ 批量烧录出厂 → ⑦ 规格台账登记 → ⑧ 扩容预案
  • 交付结果：经验收的 ISO/OOBE 镜像（含版本说明）、出厂规格表、每台设备的规格与镜像版本记录、扩容方案
  • 状态依据：无书面 SOP。2026-09 出货后才发现一批单盘 ext4 设备（约 19 台）无法平滑扩容，管理层要求“现在就得定一版 SOP”；2026-08～10 交付等发版出新 ISO 导致延期，OOBE 未经测试即计划上生产，镜像验收责任人不明

1. 场景判定

  • 触发条件：批量订单确认；新机型/新盘位首批出货；软件大版本发布需更新出厂镜像；客户提出扩容
  • 典型说法：「现在就得定一版 SOP，以后客户要扩容怎么整」「如果周末前搞不定我就安排原版 debian 镜像了」「不是说等周一发版出新 ISO 一起交付吗」
  • 判断问题：本批机器规格（盘位、文件系统）是否已登记？预装版本是否已正式发布？镜像是否验收通过？
  • 不归本流程管：单台出厂装机与测试 → 请走 X-DLV-13；正式版本发布 → 请走 RND-51；已交付客户扩容与加席位 → 请走 X-DLV-33；硬件选型采购 → 请走 X-DLV-02

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
镜像/OOBE 负责人 制作 ISO/OOBE、维护自动部署脚本与版本说明 A/R 后端/部署研发（当前：杨云峰·推断待确认）
IT 运维 定义出厂硬件规格、ISO 烧录 R IT 运维（当前：杨明学·推断待确认）
存储方案 文件系统与存储池方案、扩容方案 R CI/基础设施研发（当前：吴世豪·推断待确认）
Leap 研发负责人 预装版本与发版排期决策 R Leap 研发负责人（当前：王皓南·推断待确认）
发版 提供正式版本制品 C 后端/运维研发（当前：宋祺睿·推断待确认）
测试负责人 镜像功能与服务验收 R 测试负责人（当前：张东郅·推断待确认）
交付工程师 部署路径验证、试产、批量烧录、台账登记 R 交付工程师（当前：游家豪·推断待确认）
研发负责人 镜像未达标时是否延期/回退的终裁 I 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 订单数量、机型、交付日期
  • 出厂规格：盘位数、系统盘/数据盘、文件系统（ext4 / zfs）、RAID 方案、是否预留扩容盘位
  • 已发布的正式软件版本号与制品
  • 自动部署脚本与 OOBE 分支最新状态
  • 测试机至少 1 台（与出货机型一致）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定出厂规格：型号 × 盘位 × 文件系统 × 数据盘 × 扩容方式，写入规格表 IT 运维 + 存储方案 采购下单前 多维表格“出厂规格表” 规格条目 🔧飞书固化
2 确定预装版本：只用已发布正式版本，与发版日历对齐 Leap 研发负责人 批量订单确认后 2 个工作日内 发版日历 预装版本号 👤人工判断
3 制作 ISO/OOBE 镜像（分区方案、自动部署脚本、版本固定，禁用 latest 标签） 镜像/OOBE 负责人 版本确定后 3 个工作日内 CI / 镜像仓库 镜像 + 版本说明 🤖自动化
4 镜像验收：部署路径（交付工程师）、服务功能（测试）、集群组网、扩容路径 测试负责人 出包后 2 个工作日内 测试机 + 自动化脚本 ISO 验收报告 🤖+👤
5 试产 3 台全流程跑通 交付工程师 验收通过后 1 个工作日内 烧录工具 试产记录 👤人工判断
6 批量烧录出厂（机器 key 仅可获取一次，重置视为返厂） 交付工程师 按订单排期 烧录工具 出厂记录 🤖自动化
7 逐台登记规格与镜像版本 交付工程师 出厂当日 设备台账 台账记录 🔧飞书固化
8 维护扩容预案：采购盘（按方案要求的数量）、上门装盘、配置存储池、事前数据备份与风险确认 存储方案 客户提出扩容后 2 个工作日内出方案 上门服务工单 扩容方案 👤人工判断

5. 交付物与模板

  • 交付物：ISO/OOBE 镜像及版本说明、ISO 验收报告、出厂规格表、设备规格台账、扩容方案
  • 建议模板/表单：
    • 出厂规格表：机型、盘位、系统盘、数据盘、文件系统、RAID、可扩容方式、适用订单、生效日期
    • ISO 验收清单：镜像版本、预装软件版本、分区校验、OOBE 流程、服务启动、注册换 Key、集群组网、扩容演练、验收人、结论

6. 异常与升级

  • OOBE/镜像未通过验收 → 不得用于生产出货，回退“原版 Debian + 手工部署” → 升级 Leap 研发负责人（当日）
  • 发版延期影响交付日 → Leap 研发负责人与交付项目经理联合决定用旧版出货或延期 → 交付日前 3 个工作日内定
  • 出货后发现规格不可扩容 → 存储方案出补救方案 → 升级研发负责人（2 个工作日内）
  • 机器 key 被重置/丢失 → 按返厂处理 → 升级 IT 运维
  • 镜像依赖的制品缺失 → 镜像负责人修正固定版本 → 1 个工作日内

7. 衡量指标

  • 单台装机时长 = 上电到部署完成的小时数，目标 ≤ 1 小时（手工基线约 6 小时）
  • 镜像一次验收通过率 = 首次验收通过的镜像版本 / 镜像版本总数，目标 ≥ 80%
  • 规格登记完整率 = 已登记规格的出货设备 / 出货设备总数，目标 100%
  • 镜像/发版导致的交付延期次数，目标 0 次/季度

8. 低效诊断

  • 现象：出厂规格未事先定义，出货后才发现单盘 ext4 设备无法平滑扩容，不同批次规格不一｜依据：「Leap产研测」2026-09
  • 现象：交付等发版出新 ISO，交付日一再后延；镜像未测试即计划上生产｜依据：「Leap产研测」2026-09
  • 现象：镜像验收责任人不明，测试不熟悉 OOBE 流程｜依据：「Leap产研测」2026-09
  • 现象：定制 ISO 走通后才询问预装哪个版本，制作与发版各自推进｜依据：「Leap产研测」2026-08

9. 分支变体

  • 标准一体机通用镜像 vs 客户定制镜像（定制镜像须额外记录客户与定制项）
  • 单盘 ext4 / 多盘 zfs / 5 盘位机型：扩容方式不同，规格表须分别登记
  • 原版 Debian + 手工部署（兜底方案）vs ISO + OOBE（标准方案）
  • 集群主/从机：镜像相同，注册角色在 X-DLV-14 区分

10. 待确认问题

  • 出厂规格由硬件（IT 运维）定还是由研发定？谁最终签字？
  • 预装版本是否一律为“最近正式版”？是否允许发版后补 OTA 方式出货？
  • 已出货的单盘 ext4 设备是否需要主动告知客户扩容限制？
  • 镜像验收是否固定由测试负责人牵头？交付工程师负责部署路径是否认可？
  • 扩容上门服务是否收费、由谁报价？
X-DLV-13一体机出厂装机、预装与测试验收待优化400

状态：待优化｜证据：有证据（卡片 11 张 / 会话 5 个）｜优先级：频4 × 耗5 × 跨4 × 险5

  • 适用场景：新机器到货或交付订单提单后，完成来料检验、装系统、部署 LeapCore、注册充值、自动化测试与出厂检查，验证合格后发货或安排上门
  • 负责人：主责——交付工程负责人（当前：杨云峰·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、交付工程师（当前：游家豪·推断待确认）、部署研发（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付统筹（当前：杨萌·推断待确认）、网关额度（当前：柯逸飞·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 交付单信息收齐 → ② 到货组装与来料检验 → ③ 装系统与环境确认 → ④ 硬件→软件交接 → ⑤ 部署 LeapCore → ⑥ 注册与充值 → ⑦ 自动化测试出报告 → ⑧ 出厂检查 → ⑨ 发货/上门 → ⑩ 台账回写
  • 交付结果：通过出厂检查的整机（系统、版本、席位、注册、额度、网络均就绪）、测试报告、出厂检查单、发货记录、设备台账条目
  • 状态依据：已有《交付 SOP（产研）》《软件部署 SOP》、部署 skill、测试脚本与 OOBE 镜像；但 2026-06～10 交付信息分散在硬件、软件、订单三张表，进度靠群里追问约 15 次；硬件→软件交接缺检查单（缺 SSH/软件源无法远程）；部署后测试责任人不固定；SOP 落后于版本，出现“SOP 都走不明白”的交付差错

1. 场景判定

  • 触发条件：交付订单提单；采购机器到货；内部 FDE 培训机、演示机需要装机；新版本要求重装或交付演练
  • 典型说法：「谁部署完软件就跑一下自动化测试」「SOP 里没有」「别到时候去了发现没带机子」
  • 判断问题：是否有订单号或内部用途审批？标品还是定制机型？单机还是集群？客户网络与交付方式（寄送/上门）是否已确认？
  • 不归本流程管：订单受理与建群 → 请走 X-DLV-07；镜像制作 → 请走 X-DLV-12；指纹注册 → 请走 X-DLV-14；账号与额度 → 请走 X-DLV-15；网络接入 → 请走 X-DLV-16；客户自备设备 → 请走 X-DLV-17；上门部署实施 → 请走 X-DLV-19；集群交付 → 请走 X-DLV-20；签收验收单 → 请走 X-DLV-29；部署 SOP 文档维护 → 请走 X-DLV-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付工程负责人 维护流程与检查单、部署验收、带教备岗 A 交付工程负责人（当前：杨云峰·推断待确认）
IT 运维 调货采购、组装、来料检验、机器存放登记 R IT 运维（当前：杨明学·推断待确认）
交付工程师 装系统、部署、出厂检查、发货、台账 R 交付工程师（当前：游家豪·推断待确认）
部署研发 平台配置、特殊硬件适配、部署故障处理 R 后端/运维研发（当前：宋祺睿·推断待确认）
测试负责人 提供测试脚本、复核测试报告 R 测试负责人（当前：张东郅·推断待确认）
交付统筹 收齐订单信息、维护交付单、对接客户经理 R 交付统筹（当前：杨萌·推断待确认）
网关额度 指纹登记与充值执行 C 网关研发（当前：柯逸飞·推断待确认）
Leap 研发负责人 排期、发货放行 C Leap 研发负责人（当前：王皓南·推断待确认）
研发负责人 交付差错追责与资源调配 I 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 交付单（统一一张多维表格）：客户、订单号、机型、席位（合同未写按标准默认值）、存储、机架/机房、网络环境（固定 IP/出网限制）、管理员与用户清单、交付方式、交付日期
  • 对应规格的 ISO/OOBE 镜像与部署 SOP 当前版本
  • 测试脚本仓库与测试账号
  • 配件清单：电源适配器、网线、安装介质
  • 凭据传递方式（私密渠道，不在群内发）
  • 请求最少包含字段（提单给交付统筹时必填，缺一项退回，不另行追问）：订单号/合同编号、客户简称（内部代号）、交付群链接、机型与配置（CPU/内存/存储/GPU）、席位数、目标软件版本号、网络环境（固定 IP/出网限制/是否需 WG）、交付方式（寄送/上门/公司装好再送）、期望交付日、客户对接人岗位与联系方式所在位置、管理员清单附件位置、是否行业版/定制

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收齐订单交付信息，写入交付单；缺项退回客户经理 交付统筹 订单受理后 1 个工作日内 飞书表单 → 多维表格 交付单（交付订单看板一行，状态“待备机”，自动通知 IT 运维）；超时→交付工程负责人 🔧飞书固化
2 到货/组装，来料检验（DMI UUID/SN 唯一、内存、磁盘、配件），登记存放位置 IT 运维 到货后 1 个工作日内 来料检验清单 + 指纹脚本 检验记录（挂到交付单，含 SN 与存放位置）；超时→交付工程负责人 🤖+👤
3 装系统与环境确认：系统版本、国内源、SSH、网卡/DHCP、时区、RAID 与数据盘挂载、磁盘预留 交付工程师 OOBE 标准路径单台 ≤ 1 小时；手工兜底装机单台 ≤ 6 小时（当个工作日内完成） ISO / OOBE 环境确认单（交付单附件，含 SSH 地址与访问方式所在位置） 🤖自动化
4 交付单状态改“系统就绪”，自动通知部署人 交付工程师 完成即改 多维表格自动化 交接通知（交付单状态 + 机器人@部署人）；部署人 1 个工作日未接手→交付工程负责人 🔧飞书固化
5 部署 LeapCore：组织、管理员、席位、行业渠道（行业版见 X-DLV-11） 交付工程师 / 部署研发 系统就绪后 1 个工作日内 deploy-skill / OOBE 部署记录（交付单附件：软件版本、组织 ID、席位数）；超时→Leap 研发负责人 🤖自动化
6 转交注册与充值：按 X-DLV-14 提交指纹注册申请、按 X-DLV-15 发起开通充值；收到两项完成回执后贴入交付单（本流程不直接操作注册与充值） 交付工程师 部署当日提交；回执到达当日确认 飞书表单 / 交付单 注册与充值完成确认（两张回执链接贴入交付单）；回执 1 个工作日未到→交付工程负责人催网关额度岗 🔧飞书固化
7 跑自动化测试（登录、加用户、企业/个人空间上传、OTA、上报），在交付群发测试报告 交付工程师执行，测试负责人复核 部署后 1 个工作日内 测试脚本仓库 测试报告（交付群 + 交付单链接，复核人署名）；复核 1 个工作日未回→交付工程负责人 🤖自动化
8 出厂检查单逐项勾选（版本、席位、指纹、额度、网络/WG、配件、使用手册、凭据已私发） 交付工程师 发货前，且不晚于交付日前 1 个工作日 飞书任务模板 出厂检查单（交付单附件，状态改“可发货”） 🔧+👤
9 发货（快递单号）或上门排期，同步客户经理 交付工程师 检查通过当日 交付群 发货记录（交付单：快递单号或上门日期，交付群同步客户经理） 🔧飞书固化
10 回写设备台账：机器—客户—版本—规格—执行人 交付工程师 发货当日 多维表格 台账条目（设备台账 X-DLV-31，交付单状态改“已发货”） 🔧飞书固化

5. 交付物与模板

  • 交付物：交付单、来料检验记录、环境确认单、测试报告、出厂检查单、发货记录、设备台账
  • 建议模板/表单：
    • 交付单字段：订单号、客户、交付群、机型、席位、存储、网络环境、管理员、交付方式、交付日、硬件负责人、部署人、测试人、当前阶段、阻塞原因
    • 出厂检查单字段：系统版本、软件版本、时区、SSH、数据盘挂载、磁盘预留、指纹已注册、组织 ID 已登记、额度已充、测试报告链接、WG/网络、配件、使用手册、凭据交付方式、检查人

6. 异常与升级

  • 系统环境不达标（无 SSH/软件源，部署方无法远程） → 退回硬件环节修复 → 当日完成，否则升级交付工程负责人
  • 特殊硬件（存储布局不同的定制机） → 部署研发出专用镜像或调整脚本 → 升级 Leap 研发负责人（1 个工作日内）
  • 自动化测试不通过 → 不得发货，提工单 → Leap 研发负责人决定是否延期，当日通知客户经理
  • 交付规格临时变更 → 客户经理书面更新交付单后才执行 → 影响交付日的升级交付统筹
  • 凭据发到群里 → 立即改密 → 请走 X-SEC-10（密钥与凭据分发保管规范），疑似外泄同时走 X-SEC-11（凭据泄露应急处置与密钥轮换）（当日）
  • 交付差错追溯不到执行人 → 交付单“执行人”字段为必填 → 升级研发负责人
  • 任一环节交接后下游超过该步时限未接手（交付单状态停滞） → 交付统筹在交付单标红并 @ 执行人 → 再过 1 个工作日仍无动作升级交付工程负责人；影响交付日的当天通知客户经理
  • 提单字段不全（缺订单号、机型、网络环境、交付日等） → 不进入备机，退回客户经理补齐 → 补齐超 2 个工作日由交付统筹升级销售负责人

7. 衡量指标

  • 交付周期 = 订单受理到发货的工作日，目标 ≤ 5 天（不含采购在途）
  • 出厂一次验收通过率 = 首次测试通过台数 / 出厂台数，目标 ≥ 90%
  • 单台装机工时 = 步骤 3 上电到环境确认完成的小时数，目标：OOBE 标准路径 ≤ 1 小时，手工兜底 ≤ 6 小时；OOBE 路径占比逐月提升
  • 出厂检查单完整率，目标 100%
  • 发货后 7 日内故障率 = 发货 7 日内报故障台数 / 发货台数，目标 ≤ 5%

8. 低效诊断

  • 现象：订单、硬件、软件三张表人工联动，进度靠群里反复追问｜依据：「Leap产研测」2026-06
  • 现象：硬件→软件交接无检查单，系统装完缺 SSH/软件源，部署方无法远程，双方争议边界｜依据：「Leap产研测」2026-06
  • 现象：部署后测试谁负责无人应答，OOBE 未测试即计划直接上生产｜依据：「Leap产研测」2026-07、2026-09
  • 现象：SOP 落后于版本，检查项（定时任务、时区）SOP 中缺失｜依据：「Leap产研测」2026-08
  • 现象：交付差错时订单无交付群、表格来源不明、凭据发在群里｜依据：「Leap产研决策部」2026-10
  • 现象：机器存放位置只有个别人知道，出发时间一晚改 3 次｜依据：「LeapCore（archived）」2026-04、2026-05
  • 现象：部署仅少数人会，管理层需安排带教轮流交付；交付流程手工操作多｜依据：「Leap产研测」2026-06、「鼎慧产研决策部」2026-06

9. 分支变体

  • 标品一体机 / 工作站 / 塔式：按规格表默认配置（席位与内存对应关系见规格表）
  • 定制高配机：存储布局不同，需专用镜像，部署前由部署研发确认
  • 开箱即用（我方配好再交付）vs OOBE（通用镜像直发、客户激活时设置管理员密码）
  • 工厂/ODM 灌装 vs 手工装机：ODM 需确认主板写入 SN/UUID 与出厂脚本
  • FDE 培训用机：组织/席位按培训班分配，用完关机搬走前须在交付群确认
  • 集群交付 → X-DLV-20；客户自备硬件 → X-DLV-17
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 本流程主责是交付工程负责人还是交付统筹？硬件与软件交付边界以“系统就绪”为界是否认可？
  • 硬件、软件、订单三张表是否合并为一张交付单？由谁维护？
  • 部署后测试由交付工程师跑脚本、测试负责人复核，是否可行？
  • 交付周期目标 5 个工作日、单台装机 OOBE ≤ 1 小时 / 手工兜底 ≤ 6 小时是否合理？
  • 《交付 SOP（产研）》《软件部署 SOP》的维护人和更新触发条件是什么？
X-DLV-14设备指纹注册与平台登记待优化96

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频4 × 耗2 × 跨3 × 险4

  • 适用场景：每台新装/新增机器（客户、演示、测试、内部研发、集群主从）上线前，需要采集设备指纹（DMI UUID + SN / TPM）、在平台注册组织与机器、网关登记、开放平台登记组织 ID 并配置席位时启动
  • 负责人：主责——平台注册负责人（当前：杨云峰·推断待确认）；协同——交付工程师（当前：游家豪·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、网关研发（当前：柯逸飞·推断待确认）、平台配置（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、厂商对接（当前：闫登辉·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 来料指纹采集与唯一性校验 → ② 提交注册申请 → ③ 平台注册组织/机器/实例 → ④ 网关登记指纹 → ⑤ 开放平台登记组织 ID → ⑥ 席位配置 → ⑦ 机器端验证 → ⑧ 台账回写 → ⑨ 变更与注销
  • 交付结果：已在 LeapUpdate、网关、开放平台三处登记且机器端验证通过的设备，指纹—机器—组织 ID—客户/用途对应台账
  • 状态依据：群内 @ 接力的做法已固定（2026-07～09 至少 12 次），但手工接力易错：注册加错位置、改库还是新开实例口径不一；交付前一天才发现批量盒子指纹相同；组织 ID 未登记导致登录 401；仅两人会注册，同时请假即停摆

1. 场景判定

  • 触发条件：装机完成待部署；演示机/测试机/内部机新上线；集群新增从机；机器复制或重装导致指纹变化；机器回收
  • 典型说法：「人工交付只能用主板的指纹」「交付 SOP 后面需要把组织 id 也给开放平台一份注册」「厂家没刷 DMI」「注册了没绑定实例，绑」
  • 判断问题：机器用途是什么（客户/演示/测试/内部）？有无订单号或用途审批？指纹是否唯一？主控还是从机？
  • 不归本流程管：账号开通与额度充值 → 请走 X-DLV-15；LeapVPN 后台注册 → 请走 X-DLV-16；已交付设备信息归档 → 请走 X-DLV-31；测试环境地址与账号登记 → 请走 X-SEC-09

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
平台注册负责人 建组织、注册机器、绑定实例、主从角色、席位 A/R 后端/部署研发（当前：杨云峰·推断待确认）
交付工程师 采集指纹、提交申请、机器端验证、回写台账 R 交付工程师（当前：游家豪·推断待确认）
网关研发 NewAPI 登记指纹、按审批额度配置 R 网关研发（当前：柯逸飞·推断待确认）
开放平台负责人 登记组织 ID 并备注用途 R 开放平台负责人（当前：郭逸非·推断待确认）
平台配置（备岗） 注册负责人不在时代办、核对 R 后端/运维研发（当前：宋祺睿·推断待确认）
IT 运维 来料指纹校验、硬件问题 C IT 运维（当前：杨明学·推断待确认）
厂商对接 要求厂商刷写 DMI/SN、提供刷写工具 C 渠道/销售（当前：闫登辉·推断待确认）
Leap 研发负责人 注册方案（人工/批量/TPM）与改库审批 I Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 机器名称、用途类型、订单号或内部用途审批
  • 设备指纹（脚本输出的 DMI UUID + SN），唯一性校验结果
  • 客户公司信息（企业名称、组织名），用于绑定
  • 主控/从机角色、席位数、额度档位
  • 集群：主控机 ID 与从机清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 来料采集指纹并校验唯一性；重复则由厂商刷写或我方合成 IT 运维 到货后 1 个工作日内 指纹采集脚本 指纹清单 🤖自动化
2 提交注册申请：机器名、用途、订单号/审批、指纹、主/从、席位、额度档位、公司信息 交付工程师 装机完成当日 飞书表单 申请记录 🔧飞书固化
3 平台注册：建组织（每组织仅一台主控）、注册机器、绑定实例、从机设为 sub、配席位 平台注册负责人 申请后 4 个工作小时内 LeapUpdate 组织 ID / 实例 ID 🔧+👤
4 网关登记指纹并按审批档位配额度 网关研发 申请后 4 个工作小时内 NewAPI 登记回执 🔧+👤
5 开放平台登记组织 ID 并备注用途（生产客户/测试/联调） 开放平台负责人 注册后 1 个工作日内 开放平台 登记记录 🔧+👤
6 机器端验证：首次启动用指纹换取 Key 成功、Skill 与场景包可拉取、无 401 交付工程师 登记完成当日 机器端 验证记录 🤖自动化
7 回写台账：指纹—机器—组织 ID—实例 ID—客户/用途—负责人 交付工程师 当日 多维表格设备台账 台账条目 🔧飞书固化
8 变更/注销：误注册、指纹冲突、机器回收走申请；原则上不直接改库，确需改库须双人确认并留痕 平台注册负责人 发现当日 Gitea 工单 变更记录 👤人工判断

5. 交付物与模板

  • 交付物：指纹清单、注册申请记录、三处登记回执、机器端验证记录、设备注册台账
  • 建议模板/表单：
    • 注册申请表：机器名、用途类型、订单号/审批号、指纹、主/从、所属集群、席位、额度档位、公司信息、申请人
    • 设备注册台账：指纹、机器名、组织 ID、实例 ID、LeapUpdate 状态、网关状态、开放平台状态、客户/用途、负责人、位置、注销日期

6. 异常与升级

  • 来料指纹重复（厂家未刷 DMI） → 不得出货，厂商对接人要求刷写或提供工具 → 升级 IT 运维（当日）
  • 开放平台未登记导致 401 → 开放平台负责人当日补登 → 2 小时无响应升级 Leap 研发负责人
  • 注册负责人与备岗同时不在 → 按备岗表找第三人 → 升级 Leap 研发负责人（当日）
  • 从机身份缓存未更新、注册后持续 404 → 平台注册负责人排查 → 1 个工作日未解决升级 Leap 研发负责人
  • 离线部署需要授权码 → 升级研发负责人确认签发人（离线授权签发归研发，暂无对应 SOP，待新建）
  • 收到来源不明的组织 ID → 开放平台负责人查台账，不明则拒绝登记

7. 衡量指标

  • 注册时效 = 申请提交到三处登记完成的工作小时，目标 ≤ 4 小时
  • 注册差错数 = 加错位置、绑错实例、需改库的次数/月，目标 ≤ 1
  • 台账覆盖率 = 台账中登记的在用设备 / 实际在用设备，目标 100%
  • 出货前指纹重复检出率 = 出货前发现的重复 / 全部重复，目标 100%

8. 低效诊断

  • 现象：申请入口为群内 @ 接力，无表单，处理方需追问机器用途｜依据：「Leap产研测」2026-07、2026-09
  • 现象：执行环节注册加错位置，开新实例还是改库口径不一｜依据：「Leap产研测」2026-08
  • 现象：来料未检验，交付前一天才发现批量盒子指纹全部相同｜依据：「leapcore市场对接」2026-06
  • 现象：组织 ID 未登记开放平台导致 401，测试人员不知道 ID 属于哪个企业｜依据：「Leap产研测」2026-08
  • 现象：注册技能集中在两人，同时请假即无人能注册｜依据：「鼎慧产研决策部」2026-08
  • 现象：公司信息绑定字段险些漏设计；复制测试机导致指纹冲突需单独改｜依据：「Leap产研测」2026-08、「LeapCore（archived）」2026-05

9. 分支变体

  • 人工交付：取主板指纹 → 云端注册 → 首启用指纹换 Key
  • 批量/ODM 交付：工厂写入指定 SN/UUID（或 TPM），云端批量导入注册
  • 客户机 / 演示机 / 内部研发机 / 公司集群：用途类型不同，额度档位与审批不同（见 X-DLV-15）
  • 主控/从机：每组织一台主控，从机注册后改为 sub
  • 离线部署：出厂采集指纹 → 私钥签发 license → 设备内置公钥验签；演示版可跳过，交付版必须

10. 待确认问题

  • 平台注册主责是否固定为一人并指定备岗？备岗是谁？
  • 是否把注册动作内置进部署 skill/OOBE 实现自动注册，取消人工申请？
  • 直接改库的审批人是谁？是否一律禁止？
  • 离线 license 由谁签发、台账由谁维护？
  • 厂商交付规格是否已写明 DMI/SN 刷写要求？
X-DLV-15客户组织、账号开通与额度充值待优化192

状态：待优化｜证据：有证据（卡片 9 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：交付上线前，或客户/内部提出时，为客户或设备建组织、批量导入用户与初始密码、开管理员与灰度权限、设置人均额度/容量上限、充值词元额度或席位
  • 负责人：主责——交付开通负责人（当前：宋祺睿·推断待确认）；协同——额度充值执行（当前：柯逸飞·推断待确认）、交付统筹/额度决策（当前：杨萌·推断待确认）、客户经理（当前：吴琪·推断待确认）、交付工程师（当前：游家豪·推断待确认）、灰度开关（当前：侯怡辰·推断待确认）、测试（当前：李国庆·推断待确认）、IT 资产（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 提交开通申请（关联订单/用途）→ ② 额度审批 → ③ 建组织与管理员 → ④ 名单批量导入 → ⑤ 额度/容量/灰度/开关配置 → ⑥ 充值 → ⑦ 冒烟测试 → ⑧ 对客窗口验看后交付 → ⑨ 回写台账与财务同步
  • 交付结果：客户管理员与成员可登录、额度与权限正确的组织；充值回执；冒烟记录；回写到订单表的开通与充值信息
  • 状态依据：已有后台批量导入、订单表“充值金额”字段、交付群通知；但 2026-04～10 额度标准靠群里口头约定，约定的清零重充未执行；谁充值、谁定额度、测试机充多少反复询问；账号密码与手机号名单在群里传；灰度开关遗漏；资产与交付边界无书面定义

1. 场景判定

  • 触发条件：交付订单部署完成待上线；客户新开组织/渠道接入；内部、外包、合作伙伴机器需要额度；演示机余额不足
  • 典型说法：「交付一个组织要把前后端都发个版本」「给的名单需要姓名手机号就行了是吧」「测试机充多少」「演示机到底是我们销售用还是客户用」
  • 判断问题：是否有订单（客户交付）？无订单的属于研发投入（资产）还是会产生收入（交付）？额度是否在标准档位内？
  • 不归本流程管：测试账号与测试额度 → 请走 RND-47；内部/赠送额度审批 → 请走 FIN-16；客户付款到账开通 → 请走 FIN-17；已交付客户加席位 → 请走 X-DLV-33；演示账号管理 → 请走 SAL-13；售后额度补发 → 请走 X-CS-03；品牌类定制 → 请走 X-DLV-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付开通负责人 建组织、管理员、名单导入、权限与上限配置、通知 A/R 后端/运维研发（当前：宋祺睿·推断待确认）
额度充值执行 按审批充值、清理测试余额、回写 R 网关研发（当前：柯逸飞·推断待确认）
交付统筹 提交申请、按订单定额度、维护订单表 R 交付统筹（当前：杨萌·推断待确认）
客户经理 收集客户名单、对客交付、登记承诺日期 R 客户经理（当前：吴琪·推断待确认）
交付工程师 设备测试通过后通知充值 C 交付工程师（当前：游家豪·推断待确认）
灰度开关 开通字字可研侧灰度/功能开关 R 前端研发（当前：侯怡辰·推断待确认）
测试 开通后冒烟 R 测试（当前：李国庆·推断待确认）
IT 资产 判定无订单设备的资产/交付归属 C IT 运维（当前：杨明学·推断待确认）
财务专员 超档额度与成本归集确认 C 财务专员（当前：待指定）
Leap 研发负责人 超标准额度、无订单、无限额度审批 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 订单号与合同中的席位、额度条款；无订单的写明用途类型（研发自用/外包研发/合作伙伴适配/市场演示）与审批
  • 组织名称、管理员（姓名、联系方式由客户经理私密提供）
  • 成员名单 Excel（姓名 + 手机号，单次 ≤ 200 行，已校验格式）
  • 人均额度、容量上限、功能开关/灰度需求
  • 部署完成的机器指纹与组织 ID（X-DLV-14）
  • 对客承诺的上线日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交开通申请：订单号或用途类型、组织、席位、人均额度、容量、功能开关、管理员、承诺日期 交付统筹 计划上线日前 2 个工作日 飞书审批 申请单 🔧飞书固化
2 额度审批：标准档位内自动通过；超档、无订单、无限额度须 Leap 研发负责人审批并抄送财务 Leap 研发负责人 提交后 1 个工作日内 飞书审批 审批结果 🔧+👤
3 建组织与管理员；初始密码随机生成，经私密渠道发给客户管理员 交付开通负责人 审批后 1 个工作日内 LeapCore 管理后台 / LeapAuth 组织 + 管理员 🔧+👤
4 名单批量导入（模板校验手机号，错误行退回，不单独手建） 交付开通负责人 名单到位后 1 个工作日内 导入模板 / 脚本 导入结果 🤖自动化
5 配置人均额度、容量上限、灰度与功能开关（配置化，不改代码） 交付开通负责人 + 灰度开关负责人 与步骤 4 同日 管理后台 配置记录 🔧+👤
6 按审批金额充值；先清理测试残留余额；完成后自动回写订单表 额度充值执行 审批后 4 个工作小时内 NewAPI / 管理后台 充值回执 🤖+👤
7 冒烟：管理员登录、成员登录、额度显示、上传与跳转 测试 开通后 1 个工作日内 测试脚本 冒烟记录 🤖自动化
8 通知客户经理先验看，再由客户经理交付客户；非阻塞问题不拖延开通 交付开通负责人 冒烟通过当日 交付群 / 飞书任务 交付通知 🔧飞书固化
9 回写台账（组织、席位、额度、充值人、时间），同步财务 交付统筹 当日 多维表格 台账条目 🔧飞书固化

5. 交付物与模板

  • 交付物：开通申请与审批记录、组织与账号、配置记录、充值回执、冒烟记录、开通台账
  • 建议模板/表单：
    • 开通申请：订单号、用途类型（客户交付/研发投入/外包/合作伙伴/市场演示）、组织名、席位、人均额度、容量、功能开关、灰度、管理员、承诺日期、申请人、审批人
    • 名单导入模板：姓名、手机号（格式校验）、角色（管理员/成员）、部门
    • 额度标准档位表：用途类型 × 档位 × 审批人（具体数值由业务确认）

6. 异常与升级

  • 对客承诺日期早于研发预估 → 先开通账号让客户登录，非阻塞问题另排期 → 冲突升级 Leap 研发负责人（当日）
  • 名单手机号错误 → 退回客户经理修正，不手工单建 → 1 个工作日内
  • 已约定的充值未执行或金额不符 → 额度充值执行人当日纠正 → 升级 Leap 研发负责人并抄送财务
  • 演示机/测试机申请无限额度 → 默认拒绝，改为标准档位 + 余额预警 → 升级 Leap 研发负责人
  • 无订单设备归属不清 → IT 资产与 Leap 研发负责人按“研发投入算资产、会产生收入算交付”判定 → 1 个工作日内
  • 余额不足导致调用报错 → 余额预警提前通知客户经理 → 当日处理
  • A（升级）说明：组织开通、权限与标准档位内额度配置由交付开通负责人拍板（A）；额度超出标准档位、无订单设备充值、申请无限额度、已约定充值未执行或金额不符时升级 Leap 研发负责人审批并抄送财务

7. 衡量指标

  • 开通时效 = 审批通过到客户可登录的工作日，目标 ≤ 1 天
  • 充值差错数 = 金额不符、未执行、重复充值次数/月，目标 0
  • 凭据群发次数 = 在群内明文出现密码/手机号名单的次数，目标 0
  • 冒烟一次通过率，目标 ≥ 95%
  • 充值回写率 = 已回写订单表的充值 / 全部充值，目标 100%

8. 低效诊断

  • 现象：额度标准靠群内口头约定，约定的清零重充未执行，测试残留余额未清｜依据：「Leap产研测」2026-06
  • 现象：谁充值、谁定额度、测试机充多少反复询问，执行人不知道机器来源｜依据：「交付订单通知群」2026-06、2026-07
  • 现象：每个客户手工发前后端版本，忘建组织需补建，口头事项遗忘｜依据：「鼎慧产研决策部」2026-06
  • 现象：账号密码、手机号名单在群内传递，手机号错误导致单建、初始密码不一致｜依据：「鼎慧产研决策部」2026-06、「LeapCore（archived）」2026-05
  • 现象：灰度开关由他人掌握，现场才发现未开通｜依据：「LeapCore（archived）」2026-05
  • 现象：按组织 ID 写死前端可见性，新增组织靠改代码，漏配导致不可用｜依据：「工程咨询产研」2026-04、2026-06
  • 现象：无订单设备充值备注一律写“自用”，资产与交付无书面边界｜依据：「Leap产研测」2026-09
  • 现象：演示机“无限额度”被误解，额度由谁决定不清｜依据：「【模态】市场销售」2026-09
  • 现象：对客承诺日期研发不知情，内部预估与对客口径不一致｜依据：「研发通知」2026-06

9. 分支变体

  • 客户订单：按合同席位与额度执行；合同未写席位按默认标准
  • 测试机/演示机：标准小额档位，禁止无限额度，开启余额预警；演示机为销售自用，不交给客户带走
  • 研发自用/外包研发/合作伙伴适配：先判定资产还是交付，非商业走部门内部流程，商业走本流程
  • 渠道用户接入字字可研（OIDC/LeapAuth）：需在测试环境用渠道账号验证跳转与额度显示
  • 公有云客户 vs 局域网私有化客户：后者需整理环境信息，开通随部署进行
  • 附带定制（标签页图标、登录页、域名转发）→ 转 X-DLV-11

10. 待确认问题

  • 主责是交付开通负责人（研发）还是交付统筹（产品）？充值执行是否固定一人并设备岗？
  • 额度标准档位（客户/测试/演示/内部）的具体数值和审批人是谁？财务是否需要审批？
  • 是否上线“开通申请”飞书审批并自动回写订单表？
  • 初始密码统一随机 + 私发是否可行？私发渠道用什么？
  • 与 IT 资产台账（ADM-27、X-SEC-30）的边界如何划？
X-DLV-16客户网络与远程接入配置待新建300

状态：待新建｜证据：有证据（卡片 7 张 / 会话 11 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：客户设备需接入公司网关、需外网/分公司访问、云端需回连客户本地服务，或研发/售后需远程进入客户内网排障时，完成方案选型、WireGuard/frp/域名/LeapVPN 配置、客户间隔离、客户 IT 协调与访问回收
  • 负责人：主责——客户接入配置管理员（当前：游家豪·推断待确认）；协同——网关策略/IT 运维（当前：杨明学·推断待确认）、隔离方案与平台（当前：宋祺睿·推断待确认）、WG 部署（当前：杨云峰·推断待确认）、代理实例（当前：王皓南·推断待确认）、LeapVPN 管理员（当前：吴世豪·推断待确认）、对外技术窗口（当前：李铭熙·推断待确认）、现场排查（当前：望政韬·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 发客户环境要求清单 → ② 接入方案选型 → ③ 分配端口/网段并生成配置 → ④ 部署与隔离校验 → ⑤ LeapVPN 开通（如需）→ ⑥ 登记接入台账 → ⑦ 远程访问审批与配置下发 → ⑧ 客户 IT 协调与统一口径 → ⑨ 用后关闭
  • 交付结果：客户设备可稳定接入且与其他客户隔离；客户接入台账（客户、机器、配置、端口、负责人、客户 IT 联系人）；每次远程访问的审批与关闭记录
  • 状态依据：2026-04～10 外网访问方案多次口头变更；远程访问靠群里 @ 人下发配置，配置归属说不清、密码靠回忆和私发，申请人等数小时；防火墙规则触顶后才调整；客户网络问题多人对客口径不一，均无台账与成文流程

1. 场景判定

  • 触发条件：新设备交付需接入网关/OTA；客户要求外网或分公司访问；云端服务需访问客户本地网盘；研发需进客户内网排障、升级模型；客户侧 WG 被禁、IP 变更、UDP 被拦、代理/防火墙导致异常
  • 典型说法：「来个 wg conf」「一个客户两个，一个 tcp 一个 udp」「以后新机器交付的 SOP 要加一个绑定 LeapVPN 的步骤吗？」
  • 判断问题：是交付时的接入配置，还是交付后的远程访问？访问是否已过“Leap 生产资源访问”审批？问题根因在我方还是客户网络？
  • 不归本流程管：员工远程办公与内网访问 → 请走 X-SEC-25；生产资源访问审批规则 → 请走 X-SEC-18；客户索要 root/远程权限 → 请走 X-SEC-07；客户故障分级排查 → 请走 X-CS-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
客户接入配置管理员 维护接入台账、生成/下发配置、现场改网络、用后回收 A/R 交付工程师（当前：游家豪·推断待确认）
网关策略 公司网关、防火墙规则、端口段规划 R IT 运维（当前：杨明学·推断待确认）
隔离方案与平台 客户间隔离设计、云资源与域名 R 后端/运维研发（当前：宋祺睿·推断待确认）
WG 部署 早期客户 WG 配置、交接历史配置 C 后端/部署研发（当前：杨云峰·推断待确认）
代理实例 客户本地代理实例部署与文档 R Leap 研发负责人（当前：王皓南·推断待确认）
LeapVPN 管理员 企业 VPN 实例、激活码 R CI/VPN 负责人（当前：吴世豪·推断待确认）
对外技术窗口 统一回复客户 IT、发放行需求与话术 R 客户技术对接（当前：李铭熙·推断待确认）
现场排查 客户中间设备问题定位 C 基座研发（当前：望政韬·推断待确认）
研发负责人 接入方案选型、客户不配合时对客高层沟通 R 研发负责人（当前：丁震宇·推断待确认）
客户经理 发放《客户环境要求清单》并催客户 IT 回填 R 客户经理（当前：按订单指定）
远程访问申请人 提交访问审批、用后关闭并回复 R 研发/售后申请人

3. 办之前请准备

  • 《客户环境要求清单》回填：固定 IP、出网策略、UDP/WG 放行、端口、代理/nginx 是否支持长连接（HTTP/1.1、WS/SSE）、域名与证书、客户 IT 联系人
  • 客户机器信息：实例 ID、指纹、主控/从机
  • 端口/网段分配表当前占用情况
  • 远程访问：已通过的生产资源访问审批单
  • 话术库（常见网络问题对客说明）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发《客户环境要求清单》并取得客户 IT 回填 客户经理 + 客户接入配置管理员 发货/出发前 3 个工作日 飞书文档模板 回填清单 🔧飞书固化
2 方案选型：标准 = WG 接入公司网关；安全版/云中转/LeapVPN 作为报价项；未批准的第三方方案不用 研发负责人 回填后 1 个工作日内 — 接入方案 👤人工判断
3 从分配表取端口/网段，按客户生成独立配置（客户机只能访问网关） 网关策略 方案确定后 1 个工作日内 配置脚本 配置文件 🤖自动化
4 部署并校验：握手、连通性、OTA 可达、跨客户不可达；代理实例输出健康/握手/连通回执 客户接入配置管理员 / 代理实例负责人 部署当日 脚本回执 校验回执 🤖自动化
5 如需 LeapVPN：创建企业实例、登记主节点指纹、生成激活码发企业管理员 LeapVPN 管理员 申请后 1 个工作日内 LeapVPN 后台 激活记录 🔧+👤
6 登记接入台账：客户、机器、配置类型、端口、配置负责人、客户 IT 联系人、到期 客户接入配置管理员 部署当日 多维表格 台账条目 🔧飞书固化
7 远程访问：审批通过后自动 @ 台账中的配置负责人，下发配置（凭据走私密渠道，不在群发） 客户接入配置管理员 审批后 2 个工作小时内 飞书审批 + 机器人 配置下发 🔧+🤖+👤
8 客户侧网络问题：研发判断根因 → 起草话术 → 对外技术窗口统一回复，放行需求（IP、端口、协议）一次给全 对外技术窗口 当日 话术库 / 企业微信 对客消息 👤+🤖
9 用后关闭访问，在审批群回复“已关闭”，台账更新 申请人 使用结束当日 飞书审批群 关闭记录 🔧飞书固化

5. 交付物与模板

  • 交付物：客户环境要求清单回填、接入方案、配置文件（存密钥库）、校验回执、接入台账、远程访问审批与关闭记录
  • 建议模板/表单：
    • 客户接入台账：客户、机器/实例 ID、接入方式（WG/frp/LeapVPN/代理实例）、端口/网段、配置负责人、配置存放位置、客户 IT 联系人、开通日期、最近访问、到期/回收
    • 网络问题对客话术：现象、根因、需要客户做的动作（IP、端口、协议逐条列出）、预计恢复时间

6. 异常与升级

  • 配置无法连接 → 按台账找配置负责人 → 1 个工作小时无响应升级网关策略负责人
  • 客户 IP 变更/UDP 被拦/WG 被禁 → 对外技术窗口发放行需求，必要时改用 TCP 或另发安装包 → 当日
  • 客户 IT 不配合影响交付或验收 → 书面留痕需求与时间 → 升级研发负责人与客户负责人沟通（1 个工作日内）
  • 防火墙规则使用率达 80% → 网关策略负责人提前合并规则或改端口段 → 1 周内
  • 需要上客户现场改网络 → 客户接入配置管理员判断 → 当日排期并告知申请人预计时间
  • 配置或凭据在群里外泄 → 立即轮换密钥 → 升级研发负责人（1 小时内）

7. 衡量指标

  • 远程接入响应时长 = 审批通过到配置下发的工作小时，目标 ≤ 2 小时
  • 接入台账覆盖率 = 台账内客户设备 / 已交付需接入的设备，目标 100%
  • 隔离校验通过率 = 跨客户不可达校验通过的设备 / 新接入设备，目标 100%
  • 客户网络问题单一窗口率 = 由对外技术窗口统一回复的问题 / 全部客户网络问题，目标 ≥ 95%
  • 访问关闭率 = 已关闭的远程访问 / 已开通的远程访问，目标 100%

8. 低效诊断

  • 现象：外网访问方案多次口头变更，配置文件在群聊/私聊发送，每客户现场手工配置｜依据：「LeapCore（archived）」2026-04、2026-05
  • 现象：远程访问靠群里 @ 人下发配置，配置归属说不清、密码靠回忆，申请人等待数小时｜依据：「Leap 生产资源访问审批群」2026-07、2026-08、2026-10
  • 现象：每客户独立规则导致防火墙规则数触顶才处理，隔离方案有分歧，云权限难配｜依据：「忠橙星行星引擎」2026-08
  • 现象：新增客户代理实例依赖单人，配置位置反复追问，测试/正式环境差异导致重来｜依据：「鼎慧产研决策部」2026-05
  • 现象：客户网络问题多人对客口径不一，白名单、端口需往返多次补充｜依据：「Leap产研测」2026-07
  • 现象：客户中间设备为黑盒，排查约 3 小时，责任边界事前未确认｜依据：「跃迁基座项目交付沟通」2026-04
  • 现象：交付 SOP 未纳入 LeapVPN 绑定步骤，开通由谁执行未定｜依据：「LeapVPN网络预研」2026-09

9. 分支变体

  • 本地代理实例接入（工程咨询客户）：proxy 仓库新增实例 → 回执 → OIDC/LeapAuth 适配；测试环境先在测试 WG 加对端，正式环境需 hotfix
  • 云端访问客户本地网盘：WG 回连，按客户独立配置
  • 政府类客户：固定 IP 网卡、需客户 IT 配合解锁，常需上门改网络配置
  • 运营商系客户：接入时顺带处理弱密码与 root 登录（转 X-SEC-07）
  • LeapVPN：公网 IP 直连 / 单点 / 云端 relay 三种部署；激活码有效期短，发放留痕
  • 隔离方式：一客户一 WG vs 共享端口段 + WG 侧隔离

10. 待确认问题

  • 客户接入配置的主责是否为交付工程师？网关策略与隔离方案的最终决定人是谁？
  • “能跑版/安全版”是否已作为报价项写入合同模板？
  • 是否在“Leap 生产资源访问”审批中增加“客户名 → 自动 @ 配置负责人”字段？
  • WG 配置与凭据统一存放在哪里（密钥库/飞书加密文档）？
  • 新机器交付是否默认绑定 LeapVPN？由交付工程师还是 VPN 管理员执行？
  • 对外技术窗口是否固定一人？与商务对客窗口如何分工？
X-DLV-17客户自备/第三方设备部署准入评估待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：客户自备电脑/服务器，或市场、渠道要求在非我方硬件上部署 LeapCore/OpenClaw 时，在预约部署前完成配置、网络与需求范围的准入评估。
  • 负责人：主责——IT 运维/交付硬件负责人（当前：杨明学·推断待确认）；协同——销售对接人（当前：李鹏为·推断待确认）、部署工程师（当前：游家豪·推断待确认）、信创&Linux 适配负责人（当前：李子遥·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售发起准入并收客户环境确认表 → ② 对照最低配置核对 → ③ 评估授权与防破解 → ④ 判定标准/非标需求 → ⑤ 出具准入结论 → ⑥ 非标升级拍板 → ⑦ 告知客户并约部署 → ⑧ 归档
  • 交付结果：审批通过的《非自有设备部署准入评估单》（结论、限制条件、免责说明），作为 X-DLV-19 部署工单的前置附件。
  • 状态依据：没有准入标准与环境确认单；2026-03 某企业客户自备机器（低内存国产 CPU 机、无线网络写死、网卡损坏、环境已被其他 Agent 污染）导致现场部署失败并连夜重装，事后对"硬件问题算谁的"产生争议；2026-07 第三方设备能否部署靠群内临时决策，无可复用规则。

1. 场景判定

  • 触发条件：客户提出用自己的电脑/服务器安装；渠道商或市场部要求在渠道演示机、第三方服务器上安装 LeapCore；客户要在已有软件环境上叠加部署。
  • 典型说法：「评估下能不能给第三方装」「就是他们自备硬件我们部署一下」「以后这种对面提供电脑的场景还是要在硬件配置稍微强硬一些」
  • 判断问题：部署用的机器是不是我方采购/预装的？不是就走本流程。部署前能否拿到机器配置和网络信息？
  • 不归本流程管：我方一体机/服务器交付 → 请走 X-DLV-19；盒子/龙虾批量装机 → 请走 X-DLV-22；交付方式决策与联调预检 → 请走 X-DLV-18；离线/内网部署包准备 → 请走 X-DLV-23。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
准入评估主责 核对配置与网络，出具准入结论 A/R IT 运维/交付硬件负责人（当前：杨明学·推断待确认）
销售对接人 发起申请、收集客户环境表、对客告知结论与免责 R 销售（当前：李鹏为·推断待确认）
部署工程师 远程看机、现场复核、部署后补记实际环境 C 部署工程师（当前：游家豪·推断待确认）
信创/国产系统评估 国产系统、低配机器的可行性意见 C 信创&Linux 适配负责人（当前：李子遥·推断待确认）
授权与防破解 机器码绑定、联网追踪方案 C Leap 研发负责人（当前：王皓南·推断待确认）
兜底拍板 非标需求、不通过但客户坚持时的承接决定 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户环境确认表：操作系统及版本、CPU 架构/型号、内存、硬盘与剩余空间、显卡、网络方式（有线/无线）、能否访问公网、是否已安装其他 Agent 或虚拟化软件。
  • 需求范围：单 Agent / 多 Agent、使用人数、接入渠道（飞书/微信/企微）、算力来源（客户自有套餐/公司提供/本地模型）。
  • 订单号、销售对接人、客户侧 IT 联系人。
  • 我方最低配置要求清单（注明版本号）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到非自有设备部署需求，发起准入评估并附客户填写的环境确认表 销售对接人 预约部署前至少 3 个工作日 飞书表单/多维表格 准入申请 🔧飞书固化
2 对照最低配置逐项核对（内存、CPU 架构、系统、网络、存储、环境是否干净），必要时远程看机或要截图 交付硬件负责人 收到申请后 1 个工作日内 多维表格、远程工具 配置核对结果 🔧+👤
3 评估授权方式：联网设备启用机器码绑定+追踪；离线设备确认授权方案 Leap 研发负责人 与第 2 步同步，1 个工作日内 LeapAuth/Update 平台 授权方案 👤人工判断
4 判定需求是否标准（多 Agent、信创系统、定制 Skill 视为非标） 销售对接人 + 交付硬件负责人 与第 2 步同步 准入单 标准/非标标记 👤人工判断
5 出具结论：通过 / 有条件通过（客户整改或换机）/ 不通过（建议改用我方一体机） 交付硬件负责人 申请后 2 个工作日内 飞书审批 准入结论 🔧飞书固化
6 非标需求、或不通过但客户坚持时，升级决定是否承接及免责条款 研发负责人/CTO 升级后 1 个工作日内 飞书审批 承接决定 👤人工判断
7 书面告知客户结论、限制条件与免责说明，客户确认后约部署时间 销售对接人 结论出具后 1 个工作日内 飞书/邮件 客户确认记录 👤人工判断
8 准入单挂到部署工单；部署完成后补记实际环境与问题 部署工程师 部署完成当天 多维表格 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：《非自有设备部署准入评估单》；客户确认的免责说明；最低配置要求清单。
  • 建议模板/表单：准入评估单字段——客户代号、订单号、设备来源（客户自备/渠道/第三方）、OS 及版本、CPU 架构、内存、硬盘、显卡、网络（有线/无线/公网）、现有软件环境、需求范围（单/多 Agent、渠道、算力来源）、最低配置逐项是否满足、授权方式、是否非标、结论、限制条件、评估人、审批人、日期。

6. 异常与升级

  • 机器不满足最低配置 → 建议客户整改或改用我方一体机；客户坚持 → 1 个工作日内升级 CTO，并写入免责说明。
  • 现场发现环境与填报不符（已装其他 Agent、网卡损坏等）→ 部署工程师暂停部署、拍照记录，当天回报销售与交付硬件负责人，由销售与客户确认重装系统或改期。
  • 现场临时追加需求（如多 Agent）→ 不当场承诺，记录后回公司评估，2 个工作日内答复。
  • 硬件责任争议 → 以准入单与免责说明为准，销售负责人当天裁定。
  • A（升级）说明：准入结论日常由交付硬件负责人拍板（A）；非标需求（多 Agent、信创系统、定制 Skill）、不通过但客户坚持部署、需写入免责条款时升级 CTO 决定是否承接。

7. 衡量指标

  • 准入覆盖率 = 走过准入单的非自有设备部署数 / 非自有设备部署总数，目标 100%。
  • 首次上门成功率 = 首次上门即完成部署的数量 / 非自有设备部署总数，目标 ≥ 90%。
  • 准入评估周期 = 提交申请到出结论的工作日，目标 ≤ 2 个工作日。

8. 低效诊断

  • 现象：部署前没有获取客户机器配置与网络情况，到现场才发现内存不足、无线网络写死、网卡损坏，只能现场重装｜依据：「Claw布道/案例组」2026-03
  • 现象：需求范围（多 Agent）在部署前未确认，现场临时增加非标需求｜依据：「Claw布道/案例组」2026-03
  • 现象：失败后在群内争论硬件责任，缺少事前约定的免责与准入规则｜依据：「Claw布道/案例组」2026-03
  • 现象：第三方设备能否部署靠临时讨论拍板，讨论分散在多个群，无标准可复用｜依据：（推断）

9. 分支变体

  • 客户自备电脑/服务器：重点核对配置、网络、环境是否干净。
  • 渠道演示机/第三方服务器：重点核对授权与防破解（机器码绑定、联网追踪），防止安装包外流。
  • 信创/国产系统设备：额外走 X-DLV-23 的适配评估。

10. 待确认问题

  • 主责是否为交付硬件负责人，还是由交付统筹岗统一负责？
  • 最低配置要求的具体数值（内存、CPU 架构、系统版本）由谁定稿？
  • 非自有设备部署是否一律要求客户签免责说明？模板是否由法务提供？
  • 机器码绑定+联网追踪是否已成为标准能力？
  • 不通过但客户坚持时，最终拍板人是销售负责人还是 CTO？
X-DLV-18部署方式决策与现场部署前预检待新建300

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：合同签订后、出发现场前，确定交付方式（上门/寄送/公司装好再送），并完成硬件方案确认、客户网络与机房条件预检、关键链路（登录、网盘、计费等）在真实或等效环境的联调。
  • 负责人：主责——交付统筹（当前：杨萌·推断待确认）；协同——IT 运维/硬件负责人（当前：杨明学·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、后端/发布（当前：宋祺睿·推断待确认）、销售对接人（当前：吴琪、韩诗琪·推断待确认）、部署工程师（当前：游家豪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 签约触发交付前检查单 → ② 硬件清单经硬件负责人确认 → ③ 决定交付方式 → ④ 客户网络/机房预检 → ⑤ staging 关键链路联调 → ⑥ 编写现场预案 → ⑦ 交付前一天预检会放行 → ⑧ 转实施
  • 交付结果：放行的《交付前检查单》（硬件方案、交付方式、网络/机房条件、联调用例结果、现场预案、到场人员），作为进入 X-DLV-19 的放行凭证。
  • 状态依据：2026-04、2026-05 两次工程咨询类客户现场交付，分别暴露无人确认 IP/网络/客户 IT、关键链路（读网盘、认证、存储分支）未联调即上现场；2026-05 硬件交付后出现断电、网络环回、无 UPS、无数据库备份；2026-07 方案定后才实测内网带宽远低于要求、机架无空位。研发明确表示"SOP 不够健全"，硬件交付 SOP 被要求编写但未成文。

1. 场景判定

  • 触发条件：合同/订单签订且含部署交付；客户要求线下上门部署；交付含我方硬件（一体机/服务器）；客户多办公点共用设备或需远程访问。
  • 典型说法：「硬件机器交付前，要让我们的硬件和对方it沟通出一个方案」「这个流程为什么没打通就去部署了」「先去调查他们内网能不能通再给结论」「肯定得装好调试好再送过去」
  • 判断问题：合同里的硬件配置是否经硬件负责人确认？关键链路是否在与客户一致的环境跑通过？客户 IT 联系人、机器位置、网络是否已确认？
  • 不归本流程管：客户自备/第三方设备准入 → 请走 X-DLV-17；装机实施与上门安排 → 请走 X-DLV-19；集群到货部署 → 请走 X-DLV-20；离线/内网部署包打包与预演 → 请走 X-DLV-23。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付统筹 发起检查单、决定交付方式、主持预检会、放行 A/R 交付统筹（当前：杨萌·推断待确认）
硬件负责人 确认硬件清单、供电/UPS/备份方案、网络与机房预检 R IT 运维/硬件负责人（当前：杨明学·推断待确认）
软件部署 staging 部署、软件部署方案 R LeapCore 部署研发（当前：杨云峰·推断待确认）
后端/发布 认证接入、配置与发布版本 R 后端/发布（当前：宋祺睿·推断待确认）
技术放行 维护联调用例、技术层面签字（作为放行前置条件） R（技术） Leap 研发负责人（当前：王皓南·推断待确认）
销售对接人 对客收集信息、约时间、统一对客口径 R 销售（当前：吴琪、韩诗琪·推断待确认）
部署工程师 踩点、准备现场执行 C 部署工程师（当前：游家豪·推断待确认）
兜底 交付方式口径、成本/毛利与争议拍板 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 合同/订单：硬件配置、交付范围、交付日期、是否含培训。
  • 客户侧信息：IT 联系人、机器放置位置、供电与 UPS、IP 段与 DNS、能否访问公网、内网带宽、机架空间、门禁与到访方式。
  • 软件版本号与需联调的功能清单（登录、网盘、计费、模型、升级；有跨产品联动时一并列出）。
  • 使用手册、管理员手册最新版；《交付方式决策表》。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 签约后在交付订单表登记，自动生成《交付前检查单》任务并指定唯一对接人 销售对接人 签约后 1 个工作日内 多维表格/飞书任务 检查单任务 🔧飞书固化
2 核对硬件配置（不得直接沿用旧文档），补齐 UPS、来电自启、数据备份方案 硬件负责人 收到任务后 2 个工作日内 多维表格 已确认硬件清单 👤人工判断
3 按决策表定交付方式：默认在公司装好调试后寄送/送达；客户坚持上门的，确定上门人员与销售现场三件事（发手册、演示、收需求） 交付统筹 第 2 步完成后 1 个工作日内 决策表 交付方式结论 🔧+👤
4 网络/机房预检：内网互通、带宽实测（iperf3，参考门槛 ≥ 800Mbps）、IP/DNS、机架空间、供电，远程或踩点完成 硬件负责人/部署工程师 出发前至少 3 个工作日 测速脚本、远程会议 网络预检记录 🤖+👤
5 在 staging（与客户一致的版本、认证、存储分支）部署，逐条跑通联调用例：登录、网盘读写、计费、模型调用、OTA 升级 LeapCore 部署研发 + 后端/发布 出发前至少 2 个工作日 staging、Gitea 联调用例通过记录 🤖自动化
6 编写现场预案：到场人员与分工、携带物料、断网/断电备选、客户 IT 联系方式、对客口径（统一由销售对客） 交付统筹 出发前 1 个工作日 飞书文档模板 现场预案 🔧飞书固化
7 召开 15 分钟预检会逐项勾检查单，任一必选项未过不放行 交付统筹主持，研发负责人技术放行 交付前 1 个工作日 飞书会议 放行结论 👤人工判断
8 检查单链接挂到交付工单，转入 X-DLV-19 实施 交付统筹 放行当天 多维表格 交付工单 🔧飞书固化

5. 交付物与模板

  • 交付物：已确认硬件清单、网络预检记录、联调用例通过记录、现场预案、放行结论。
  • 建议模板/表单：《交付前检查单》——订单号、客户代号、交付方式（寄送/装好送达/上门）、销售对接人、客户 IT 联系人、硬件清单（确认人/日期）、放置位置、供电/UPS/来电自启、备份方案、IP 段/DNS/公网、内网带宽实测值、机架空间、软件版本、联调用例（登录/网盘/计费/模型/升级各 1 条及结果）、到场人员、预案链接、放行人、放行时间。
  • 《交付方式决策表》：硬件归属（我方/客户）、客户位置、网络条件、是否含培训 → 推荐交付方式。

6. 异常与升级

  • 合同硬件配置不可行或成本偏差大 → 硬件负责人当天反馈交付统筹与销售负责人，2 个工作日内与客户确认变更；影响毛利的升级 CTO。
  • 内网带宽不达标/机架无位 → 销售协调客户 IT 整改，暂缓出发；无法整改的 1 个工作日内由交付统筹与 CTO 决定调整方案。
  • 联调用例未通过 → 不放行；研发负责人当天指定修复人并给新日期，销售当天向客户说明改期。
  • 客户坚持上门但条件不满足 → 销售负责人与 CTO 决定，客户书面确认风险。
  • 现场被客户发现功能缺失 → 现场人员不直接回应，由销售统一对客，研发 1 小时内给出处理方案。
  • A（升级）说明：交付方式与放行由交付统筹拍板（A），Leap 研发负责人技术签字是放行前置条件；合同硬件配置影响毛利、网络/机房条件无法整改需调整方案、客户坚持上门但条件不满足时升级 CTO。

7. 衡量指标

  • 检查单覆盖率 = 走完检查单放行的交付数 / 交付总数，目标 100%。
  • 现场一次成功率 = 无需二次上门的交付数 / 交付总数，目标 ≥ 90%。
  • 现场暴露关键链路缺陷数 = 每次交付现场发现的登录/网盘/计费类缺陷数，目标 0。
  • 预检提前量 = 放行时间距出发时间，目标 ≥ 1 个工作日。

8. 低效诊断

  • 现象：合同硬件配置在商务环节直接填写，签约后硬件环节才得知，缺少签约前的硬件确认节点｜依据：「鼎慧产研决策部」2026-05
  • 现象：客户机房条件（供电、网络环回、UPS、数据库备份）未预检，交付后出现断电和网络故障｜依据：「鼎慧产研决策部」2026-05
  • 现象：交付前夜才发现无人确认 IP、网络和客户 IT 联系人，各模块只确认自己那部分｜依据：「鼎慧产研决策部」2026-04
  • 现象：关键链路只在测试环境自测，部署分支与认证配置错误到现场才暴露｜依据：「LeapCore（archived）」2026-05
  • 现象：内网带宽和机架空间在方案确定后才实测，方案返工｜依据：「Leapcore 客户B项目群」2026-07
  • 现象：交付方式每单重新讨论，对接人不明确，客户把安装与培训混为一谈，方案改多版｜依据：「Leapcore 客户E项目群」2026-07

9. 分支变体

  • 我方硬件交付：硬件负责人主导硬件方案，必须做机房、电源、网络预检。
  • 纯软件部署（客户已有机器）：先走 X-DLV-17 准入，再走本流程联调。
  • 公网部署 vs 内网部署：内网部署需额外确认 IP 段、DNS、远程维护通道。
  • 跨产品联动（如统一登录、读网盘）：联调用例必须覆盖跨产品链路。
  • 多办公点共用设备：必须实测各点之间内网带宽。
  • 小客户与大客户同样走检查单，不因订单小省略。

10. 待确认问题

  • 主责是交付统筹岗还是硬件负责人？大客户与小客户是否分设 owner？
  • 内网带宽 ≥ 800Mbps 是否作为硬性门槛？
  • staging 环境是否已建成？由谁维护？
  • 联调用例清单由测试负责人还是研发负责人维护？
  • 是否在合同签订前增加"硬件配置技术确认"节点，与销售合同流程衔接？
  • "默认公司装好再送"是否已成为对客统一口径？
X-DLV-19客户现场/远程部署实施与上门安排待优化400

状态：待优化｜证据：有证据（卡片 11 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：订单通过交付前检查（X-DLV-18）后，排外勤并上门或远程完成 LeapCore/一体机装机部署、端口/内网/账号/配置下发、联调演示、培训与验收；也覆盖已交付设备的远程修复、搬迁与现场维护。
  • 负责人：主责——交付部署负责人/IT 运维（当前：杨明学·推断待确认）；协同——部署工程师（当前：游家豪·推断待确认）、LeapCore 部署研发（当前：杨云峰·推断待确认）、后端/发布与远程运维（当前：宋祺睿·推断待确认）、交付统筹（当前：杨萌·推断待确认）、项目牵头研发（当前：李铭熙·推断待确认）、高级部署（当前：望政韬·推断待确认）、销售/项目经理（当前：韩诗琪、闫登辉、杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 交付工单排班 → ② 约客户与外出审批 → ③ 公司内按《软件部署手册》装机自测 → ④ 物料与出发 → ⑤ 现场/远程部署与配置下发 → ⑥ 账号开通与交接 → ⑦ 联调演示与培训 → ⑧ 验收单 → ⑨ 复盘与回流
  • 交付结果：客户可正常使用的 LeapCore 环境（访问地址、管理员账号、安装包已交付）、签字或回执验收单、部署记录（版本、IP、端口、配置、远程通道）、培训录像（如有）与复盘记录。
  • 状态依据：已有《软件部署SOP》（依赖清单、环境确认、设备注册、部署、用户导入、部署检查单、WG 部署、客户信息上报）、Deploy-Skill 与交付订单表；但 2026-03～09 多个群反复出现"谁装/找谁""交付前一天才问能否搞定""谁能下发配置"、外勤无人可用、每次向研发索要 IP 与账号、上门约时间靠群内追问等问题。

1. 场景判定

  • 触发条件：交付订单为"待部署"且检查单已放行；客户要求现场培训/演示；已交付设备需远程修复、升级或搬迁；同期多单需排外勤。
  • 典型说法：「周末谁来加个班跟我部署一下服务」「明天有哪几单要现场部署培训吗」「现在还有谁可以下发leapcore配置吗」「明天早上十点我们过来部署方便吗」「机器放哪，网络怎么连，会议室」
  • 判断问题：交付前检查单是否已放行？本次是首次部署、远程修复还是搬迁？本单唯一执行人是谁？
  • 不归本流程管：交付方式决策与联调预检 → 请走 X-DLV-18；集群主从部署与 OOBE → 请走 X-DLV-20；OpenClaw/龙虾盒子批量装机 → 请走 X-DLV-22；离线/内网项目型部署 → 请走 X-DLV-24；客户使用中的报修 → 请走 X-CS-05（客户问题受理、分流与工单流转）；已交付硬件故障 → 请走 X-CS-12（硬件设备售后、返修与上门维保）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付部署负责人 排班、指派执行人、协调研发支援、复盘与 SOP 更新 A IT 运维/交付部署负责人（当前：杨明学·推断待确认）
部署工程师 公司内装机、现场部署、账号交接、验收单回收 R 部署工程师（当前：游家豪·推断待确认）
部署研发 部署 SOP 与 Deploy-Skill 维护、复杂部署支援 C/R LeapCore 部署研发（当前：杨云峰·推断待确认）
后端/远程运维 配置下发、远程修复与升级 R 后端/发布（当前：宋祺睿·推断待确认）
交付统筹 订单排期、追踪交付状态 R 交付统筹（当前：杨萌·推断待确认）
项目牵头研发 定制项目的环境自测与更新 R（定制项目） 研发（当前：李铭熙·推断待确认）
高级部署 复杂环境现场支援 C 基座研发（当前：望政韬·推断待确认）
销售/项目经理 约客户、对客口径、现场培训三件事 R 销售（当前：韩诗琪、闫登辉、杨朋伟·推断待确认）
兜底 改期、加班、优先级与人手调配拍板 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已放行的交付前检查单与交付工单（订单号、客户代号、交付方式、地址、客户 IT/管理员、时间窗）。
  • 部署 SOP 最新版与 Deploy-Skill（出发前拉取最新）。
  • 软件版本号、安装包（Win/Mac）、配置项（端口、域名、白名单、认证）。
  • 企业用户清单 CSV、管理员手机号。
  • 远程通道方案（WG 配置、远程工具）及客户远程维护授权。
  • 物料清单（机器、网线、显示器、交换机、U 盘），大件货运安排；外出审批；使用手册、管理员手册、验收单、培训材料。
  • 请求最少包含字段（销售/交付统筹发起部署请求时必填，缺一项不排班、不另行追问）：订单号、客户代号、交付方式（上门/远程/销售自行交付）、现场地址与门禁要求、客户 IT 联系人岗位与管理员岗位（联系方式放工单不发群）、客户网络条件（固定 IP/出网限制/是否允许远程通道）、机器来源与当前位置、目标软件版本号、期望时间窗（日期 + 上下午）、是否含培训与录像、截止日与客户侧原因、检查单放行链接。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认本周待部署订单，指定唯一执行人与备岗，写入外勤排班表 交付统筹 + 交付部署负责人 交付日前 3 个工作日 多维表格/飞书日历 排班表（外勤排班表一行 + 交付群公告执行人/备岗）；超时→CTO 决定改期或调人 🔧飞书固化
2 约客户时间，确认地址、门禁、客户 IT 与管理员并回填工单；执行人提交外出审批 销售对接人、部署工程师 交付日前 2 个工作日 飞书审批 预约记录（回填交付工单：时间窗、地址、客户 IT 岗位）、外出审批号；销售超时未约→交付统筹升级销售负责人 🔧飞书固化
3 在公司按《软件部署手册》装机或更新版本：环境确认、设备注册、部署、用户导入，完整跑一遍部署检查单 部署工程师（部署研发支援） 交付日前 1 个工作日 Deploy-Skill、部署 SOP 自测通过的部署检查单（交付工单附件，含版本号与 IP/端口）；不通过→当天报部署研发，仍不通过升级交付部署负责人改期 🤖自动化
4 核对携带物料与出发安排，服务器等大件货运直送门口 部署工程师 出发前一天 出发模板 物料清单勾选（交付群置顶出发模板：出发时间、人员、物料、货运单号） 🔧飞书固化
5 现场/远程部署：上架接电，配置 IP/端口/DNS/白名单；配置经 Update 平台下发并留痕；远程只用公司指定通道并取得客户授权 部署工程师（远程修复由后端执行） 预约时间窗内 Update 平台、WG 部署记录（交付工单附件 + Update 平台下发记录）；需研发支援 30 分钟无响应→升级研发负责人 🔧+👤
6 开通管理员账号、导入用户、分发安装包与访问地址；按交接模板给客户（不在群内发明文密码） 部署工程师 部署当天 管理后台、交接模板 账号交接单（交付工单附件，凭据经私密渠道交付，工单只记账号名） 🔧+👤
7 联调演示：登录、网盘、模型对话、计费、升级逐项演示；现场缺陷只记录不承诺 部署工程师 + 销售 部署当天 验收用例 演示记录（验收用例逐项结果，附遗留问题清单，回交付群） 👤人工判断
8 培训：发手册、演示、收集需求；按约定全程录像 销售对接人 部署当天 手册、录像设备 培训记录/录像（录像存交付项目文件夹，链接贴交付工单；需求进需求池 X-PRD-09） 👤人工判断
9 客户签验收单或回执照片，工单状态改"已交付" 部署工程师 交付当天 多维表格 验收单（扫描件/照片上传交付工单，转 X-DLV-29 跟开票）；当天未取得→交付统筹次日跟进销售 🔧飞书固化
10 复盘：问题进研发工单、需求进需求池；部署 SOP 有变更的同步更新 交付部署负责人 复盘 1 个工作日内，SOP 更新 3 个工作日内 工单系统、飞书 wiki 复盘记录（交付工单附件）、研发工单编号、SOP 新版（wiki 版本号）；超时→研发负责人 🔧+🤖

5. 交付物与模板

  • 交付物：部署记录、账号交接单、验收单、培训录像、复盘记录。
  • 建议模板/表单：
    • 外勤排班表：日期、订单号、客户代号、地点、执行人、备岗、到场时间、交通方式、外出审批号、状态。
    • 部署记录：软件版本、硬件序列号、IP/端口/域名、配置下发记录、远程通道、管理员账号名（不记密码）、部署人、时间。
    • 验收单：功能用例结果、遗留问题、客户签字、日期、现场照片。

6. 异常与升级

  • 交付前一天仍未确认执行人 → 交付统筹当天升级交付部署负责人重派；无人可派升级 CTO 决定改期或调人。
  • 现场网络/端口不通 → 先联系客户 IT；30 分钟内未解决 @ 部署研发远程支援；仍不通则改期，销售当天对客说明。
  • 找不到人下发配置 → 工单预设下发人与备岗；1 小时内无人响应升级研发负责人。
  • 远程访问被客户网络拦截或协议未约定 → 停止远程操作，销售补签远程维护授权后再执行。
  • 客户提出合同外需求 → 不当场答应或拒绝，集中记录回公司评估，3 个工作日内答复。
  • 周末/夜间紧急交付 → 交付部署负责人报 CTO 批准，按加班审批发补贴。
  • 硬件故障（RAID 失败、电力不足）→ 拍照留证，当天回报硬件负责人，24 小时内给出换件/重装方案。
  • 部署请求字段不全（无订单号、时间窗、客户 IT 联系人或网络条件）→ 不排班，交付统筹退回发起人补齐 → 补齐超 1 个工作日且影响交付日的，升级销售负责人。
  • 交付工单状态超过该步时限未更新（如自测检查单、验收单未上传）→ 交付统筹在工单标红并 @ 执行人 → 再过 1 个工作日无动作升级交付部署负责人。
  • A（升级）说明：排班、执行人指派与复盘由交付部署负责人拍板（A）；交付前一天无人可派需改期或调人、周末/夜间紧急交付需批准时升级 CTO。

7. 衡量指标

  • 按期交付率 = 按约定日期完成验收的订单 / 交付订单，目标 ≥ 95%。
  • 二次上门率 = 需再次上门的订单 / 交付订单，目标 ≤ 10%。
  • 验收单回收率 = 有验收单的订单 / 已交付订单，目标 100%。
  • 排班提前量 = 排班确定时间距交付日，目标 ≥ 2 个工作日。
  • 现场呼叫研发次数/单：目标逐月下降。

8. 低效诊断

  • 现象：现场执行依赖少数人，部署人员常被其他任务占用，排班靠群里询问，出现无人可派｜依据：「跃迁基座项目交付沟通」2026-03
  • 现象：谁负责装、谁能下发配置不清楚，对接方临时找人｜依据：「Leap产研测」2026-07
  • 现象：交付前一天才确认能否完成，周末加班赶部署｜依据：「Leap产研测」2026-07
  • 现象：每次交付都向研发索要 IP 与管理账号再转发客户，交接无模板｜依据：「Leap产研测」2026-07
  • 现象：默认端口与客户端不兼容、配置中心改动未下发，到现场才暴露｜依据：「Leap产研测」2026-07
  • 现象：首次现场交付无人确认客户网络与 IT 联系人，现场改 IP、连夜改发布计划｜依据：「鼎慧产研决策部」2026-04
  • 现象：出发时间、人员、硬件谁带前一晚反复变更，到场进不了门｜依据：「LeapCore（archived）」2026-04、2026-05
  • 现象：远程维护工具与客户授权未统一，临时选工具｜依据：「鼎慧产研决策部」2026-06、2026-07
  • 现象：客户侧联系人、机柜电力、RAID 等现场条件未确认导致交付失败或返工｜依据：「忠橙星行星引擎」2026-01、2026-07
  • 现象：上门时间靠群内追问，前一天才确认需求｜依据：「交付订单通知群」2026-07、2026-09
  • 现象：默认仅内网访问的策略未提前告知客户，客户在外访问超时｜依据：「客户H项目群」2026-08

9. 分支变体

  • 上门部署（工程咨询、零售类客户）：需外出审批、物料清单与出发模板。
  • 远程部署/修复（异地单机、定制项目）：用 WG 或 Update 平台终端；用户协议需写明"必要时远程维修"。
  • 单机（如高校客户约 50 人，配 WG 远程）vs 集群（转 X-DLV-20）。
  • 客户机器带回公司装版本后再送达，并演练行业版流程。
  • 销售自行交付：客户有网络与 IT 人力的标准培训单，由销售按手册交付，部署工程师远程支援。
  • 保密/军队类客户：提前预约入室、联系客户指定人员（见 X-DLV-24）。
  • 服务器/Mac mini 搬迁：按客户时间窗关机、搬迁、重新上电并做开机自检。
  • 内网访问 vs 远程隧道：默认仅内网访问；客户需外部访问时另行评估隧道方案。
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）、ALL-09（状态看板与进度同步）

10. 待确认问题

  • 主责是 IT 运维（硬件+部署协调）还是交付统筹？部署工程师是否为默认唯一执行人？
  • 现有《软件部署SOP》维护人是谁？文中明文凭据是否已去除？
  • 外出审批、加班补贴审批流是否已在飞书配置？
  • 远程维护工具统一为 WG 还是 Update 终端（wss）？客户授权条款由法务何时提供？
  • 销售自行交付的条件和范围是否需要书面化？
  • 培训是否默认全程录像？录像存放位置在哪？
X-DLV-20集群版交付部署待新建160

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗4 × 跨4 × 险5

  • 适用场景：客户集群硬件到货或需扩展从机（sub 节点）时，完成上电联网、IP 下发、设备身份注册（TPM/指纹）、主从关联、OOBE 交付与席位配置。
  • 负责人：主责——LeapCore 部署研发（当前：杨云峰·推断待确认）；协同——后端/v5 云端（当前：宋祺睿·推断待确认）、部署工程师（当前：游家豪·推断待确认）、IT 运维（当前：杨明学·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 到货/扩容登记并指派 → ② 客户侧上电联网说明 → ③ 云端配置身份与 IP、注册指纹 → ④ 主机部署与 OOBE → ⑤ 从机预部署 → ⑥ 角色关联与席位配置 → ⑦ 两轮验收 → ⑧ 发货/接入与记录
  • 交付结果：主从节点均注册并关联的集群、OOBE 完成、席位按合同配置、两轮验收全部 PASS 的记录、客户侧操作说明。
  • 状态依据：2026-08 集群客户到货时，运维侧明确"TPM 和指纹现在没 SOP"，对接人不明、客户侧需要做什么反复确认、OOBE 设计图需找回；从机预部署步骤靠对话告知 AI，席位数在群里临时确认。

1. 场景判定

  • 触发条件：集群/多机硬件到达客户现场；已有集群需增加从机；单机客户升级为集群。
  • 典型说法：「客户的集群到了」「要下发ip，先让他们开机」「得到客户那边才能添加」「tpm 和指纹现在没 sop」「兜底一定要全，这是2B」
  • 判断问题：是否有两台及以上机器共同提供服务（存在 master/sub 角色）？
  • 不归本流程管：单机部署 → 请走 X-DLV-19；交付前预检 → 请走 X-DLV-18；客户本地 NewAPI 配置 → 请走 X-DLV-21。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
集群部署主责 主机部署、OOBE、角色与席位配置、验收 A/R LeapCore 部署研发（当前：杨云峰·推断待确认）
云端身份与寻址 v5 云端机器身份、IP 配置、寻址服务 R 后端/v5 云端（当前：宋祺睿·推断待确认）
从机预部署 从机预部署、验收脚本执行、打包发货 R 部署工程师（当前：游家豪·推断待确认）
硬件与指纹 TPM/设备指纹采集、网络 C/R IT 运维（当前：杨明学·推断待确认）
统筹 到货通报、指派对接人与 FDE；注册失败等当天未解决问题的裁决 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）
客户对接 转达客户操作说明、协调客户开机联网 R 销售/客户对接 FDE（按项目指定）
兜底 流程设计、兜底要求与争议拍板 I 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 合同席位数与节点规划（master/sub、每节点席位）。
  • 各节点硬件序列号、TPM/指纹采集脚本。
  • 客户网络信息：IP 段、mDNS 是否可用、是否跨网段。
  • v5 云端寻址服务与交付人员的机器身份/IP 配置权限。
  • Deploy-Skill 最新版、Update 平台权限、OOBE 设计图、客户侧操作说明模板。
  • 已指派的对接人/FDE。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 到货或扩容需求登记交付工单，指定部署主责与客户对接 FDE Leap 研发负责人 到货当天 多维表格 工单与对接人 🔧飞书固化
2 向客户发送操作说明：只需上电、接网；确认 IP 段与 mDNS 可用性 部署主责（经销售/FDE 转达） 到货后 1 个工作日内 说明模板 客户确认 🔧飞书固化
3 在 v5 云端为交付人员配置机器身份与 IP，采集各节点 TPM/指纹并注册 后端/v5 云端 + IT 运维 开机后 1 个工作日内 v5 cloud、指纹脚本 注册记录 🤖自动化
4 主机部署并走 OOBE：交换 apikey → 等待首次 mDNS 连接自动改 IP；跨网段时手动填 IP 部署主责 第 3 步完成当天 Deploy-Skill、OOBE 主节点上线 🤖+👤
5 从机预部署：deploy skill 指定 sub 节点模式，清理旧 node 绑定 部署工程师 发货前 Deploy-Skill 从机预部署完成 🤖自动化
6 Update 平台设置节点角色并关联 master；按合同配置席位（如 2 节点 × 60 = 120） 部署主责 与第 5 步同日 Update 平台 角色/席位配置记录 🔧+👤
7 跑两轮验收脚本，全部 PASS 才发货/交付；兜底项必须覆盖断电重启、从机掉线、IP 变更 部署工程师 + 部署主责 发货前 1 个工作日 验收脚本 验收报告 🤖自动化
8 打包发货或现场接入；交付后更新部署记录并通知客户 部署工程师 验收后 1 个工作日内 多维表格 交付记录 🔧飞书固化

5. 交付物与模板

  • 交付物：节点注册记录、OOBE 完成记录、角色/席位配置记录、两轮验收报告、客户侧操作说明。
  • 建议模板/表单：集群部署记录——客户代号、节点序列号、角色（master/sub）、TPM/指纹注册状态、IP、关联 master、席位数、软件版本、验收结果（逐项 PASS/FAIL）、部署人、日期。

6. 异常与升级

  • OOBE 卡在等待 mDNS → 部署主责远程手动下发 IP；2 小时内未解决升级后端负责人。
  • TPM/指纹注册失败 → IT 运维与后端联查；当天不能解决升级 Leap 研发负责人。
  • 席位数与合同不一致 → 暂停发货，交付统筹与销售 1 个工作日内核对合同。
  • 客户侧无人配合开机 → 销售/FDE 协调；超过 2 个工作日升级销售负责人。
  • 从机关联 master 失败 → 清理绑定后重做，原因补进 SOP。
  • A（升级）说明：集群部署方案、席位配置与验收发货由部署主责拍板（A）；OOBE/寻址 2 小时内未解决、TPM/指纹注册当天未解决、对接人或交付归属不清时升级 Leap 研发负责人裁决。

7. 衡量指标

  • 到货至可用时长 = 到货到 OOBE 完成的工作日，目标 ≤ 3 个工作日。
  • 验收一次通过率：目标 100%（不通过不发货）。
  • 席位配置差错数：目标 0。
  • 客户侧额外操作次数（上电、联网之外）：目标 0。

8. 低效诊断

  • 现象：TPM 与设备指纹注册无 SOP，靠找人问｜依据：「Leap产研测」2026-08
  • 现象：到货后才确认由谁对接、交付流程归谁负责｜依据：「Leap产研测」2026-08
  • 现象：客户侧需要做什么（是否只需插电联网）反复确认｜依据：「Leap产研测」2026-08
  • 现象：OOBE 设计资料存放分散，需临时找回｜依据：「Leap产研测」2026-08
  • 现象：从机预部署靠对话告知 AI 完成，无清单；席位数在群里临时确认｜依据：「Leapcore 客户D项目群」2026-08

9. 分支变体

  • 集群客户：第二台作为 sub 节点预部署，到客户现场后才能关联添加，需下发 IP。
  • 一体机/单机：转 X-DLV-19。
  • 跨网段：mDNS 不可用，需手填 IP 或依赖云端寻址服务。

10. 待确认问题

  • 主责是部署研发还是交付部署负责人？
  • v5 云端寻址服务是否已上线？
  • TPM/指纹 SOP 由谁编写，何时完成？
  • 集群交付是否默认指派 FDE？
  • 验收脚本的 PASS 项（当前 8 项）是否已入库固化？
X-DLV-21客户模型/API 能力接入与本地 NewAPI 维护待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：客户需要使用海外模型/搜索、指定自有云算力或本地定制模型接入 LeapCore，或客户本地独立部署的 NewAPI 需要同步价格、峰谷配置、新模型并提供调用示例时。
  • 负责人：主责——模型网关与计费研发（当前：柯逸飞·推断待确认）；协同——上游渠道维护/IT 运维（当前：杨明学·推断待确认）、客户环境配置研发（当前：李铭熙·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、销售（当前：闫登辉·推断待确认）、远程环境/WG（当前：宋祺睿·推断待确认）、测试负责人（当前：张东郅·推断待确认）、LeapAgent 研发（当前：岳阳·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 销售填确认信息表 → ② 技术评估与路由方案 → ③ 分批上线计划拆任务 → ④ 上游渠道接入 → ⑤ 客户本地 NewAPI 配置 → ⑥ 测试 → ⑦ 调用示例、接入文档与知情书 → ⑧ 对客与异常初判 → ⑨ 变更同步核对
  • 交付结果：客户可用的模型清单与渠道配置、调用示例与接入文档、客户环境配置清单（地址、访问方式、同步项）、必要的体验受限知情书；每次调价/上新后的同步核对记录。
  • 状态依据：已有《LeapCore 接自有算力确认信息表》、《自有算力环境产品使用体验受限知情书》、分批上线计划与飞书待办；但 2026-07～09 接入进度多次靠催问、谁配客户本地 API 反复确认、本地 NewAPI 价格与峰谷配置手动同步且曾漏配模型、环境地址与凭据私下传递、每个模型临时写调用示例。

1. 场景判定

  • 触发条件：合同含海外模型/搜索能力；国央企/政府要求指定云算力；渠道商要搭载自有算力销售 LeapCore；公司总 NewAPI 调价/上新后需同步到客户本地；客户反馈某模型调用异常。
  • 典型说法：「LeapCore接自有算力确认信息表」「客户要用指定云端算力，需要重新配置他们的算力的 apikey」「你还要记得在客户那边本地同步一份峰谷配置」「你写个example吧」
  • 判断问题：客户是否有独立部署的 NewAPI 或自有算力？问题属于接入、配置、文档，而不是产品缺陷？
  • 不归本流程管：LeapCore 部署本身 → 请走 X-DLV-19；本地大模型一体机部署 → 请走 X-DLV-24；公司总 NewAPI 定价 → 请走 X-PRD-22（模型/API 售价、倍率调整与对外价格表同步）；上游渠道采购 → 请走 X-OTH-01（上游模型/云服务供应商询价、折扣谈判与签约）；客户充值到账 → 请走 FIN-17（客户充值到账审核与额度开通）；客户按量账单 → 请走 FIN-27（客户按量计费月度账单核算与发送）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
接入主责 拆任务、总 NewAPI 渠道与价格、调用示例、变更同步 A/R 模型网关与计费研发（当前：柯逸飞·推断待确认）
上游渠道 上游 aiapi 渠道接入与分组开通 R IT 运维/渠道维护（当前：杨明学·推断待确认）
客户环境配置 客户本地 NewAPI 模型、价格、峰谷配置 R 研发（当前：李铭熙·推断待确认）
技术评估 确认信息表设计、路由方案、接入文档技术审核 C Leap 研发负责人（当前：王皓南·推断待确认）
销售 收集需求与客户接口文档、填信息表 R 销售（当前：闫登辉·推断待确认）
远程环境 WG 访问与客户环境申请 C 后端/运维（当前：宋祺睿·推断待确认）
测试 模型调用测试 C 测试负责人（当前：张东郅·推断待确认）
技术意见 接口与文档技术审阅 C LeapAgent 研发（当前：岳阳·推断待确认）
兜底 需求与日期争议、知情书与对客承诺、错误计费与断供处置 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 《LeapCore 接自有算力确认信息表》：是否开源、是否后训练、tok/s、并发、是否支持 Responses API、缓存、思考、联网搜索、并行工具调用。
  • 客户接口文档与 API Key（经安全渠道提供，不在群内明文）。
  • 模型需求清单、上线批次与截止日期、使用人数。
  • 客户本地 NewAPI 地址、访问方式（WG）；管理员凭据由负责人统一保管。
  • 公司定价规则与峰谷配置；调用示例/接入文档模板。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收集客户需求（模型、人数、搜索、算力来源），填写确认信息表 销售 需求明确后 1 个工作日内 飞书表单/多维表格 信息表记录 🔧飞书固化
2 技术评估：可否接入、路由方式（当前仅能把经济/标准/专家之一路由到本地）、是否需签知情书 Leap 研发负责人 + 接入主责 入表后 2 个工作日内 信息表 评估结论 👤人工判断
3 制定分批上线计划并拆成飞书任务（渠道接入、渠道添加、客户本地配置、测试），设依赖和截止日 接入主责 评估后 1 个工作日内 飞书任务 任务清单 🔧飞书固化
4 上游渠道接入，总 NewAPI 添加渠道与价格 上游渠道 + 接入主责 按批次计划 NewAPI 渠道配置 🔧+👤
5 客户本地 NewAPI 配置模型、价格规则、峰谷；自有算力客户配置 apikey 与路由 客户环境配置 渠道就绪后 1 个工作日内 本地 NewAPI、WG 客户环境配置清单 👤人工判断
6 按接口类型（chat/images/messages）逐模型调用测试并记录 测试 / 接入主责 配置完成当天 probe 脚本 测试记录 🤖自动化
7 生成调用示例与接入文档（AI 起草、人工校对），需要时同步提交知情书 接入主责起草，Leap 研发负责人审核；含知情书或对客承诺的报 CTO 测试通过后 1 个工作日内 文档模板 接入文档 PDF/MD 🤖+👤
8 发客户；客户反馈异常时先判定是客户调错、模型故障还是文档错误 接入主责/销售（需对客结论的报 CTO） 收到反馈 4 小时内初判 工单 处理记录 👤人工判断
9 总 NewAPI 调价/上新/峰谷调整后，脚本比对客户本地差异并同步，机器人推送结果 接入主责 变更后 1 个工作日内 差异脚本、飞书机器人 同步核对记录 🤖自动化

5. 交付物与模板

  • 交付物：确认信息表、评估结论、客户环境配置清单、测试记录、接入文档与调用示例、知情书、同步核对记录。
  • 建议模板/表单：
    • 客户环境配置清单：客户代号、NewAPI 地址、访问方式、负责人与备岗、模型列表、价格规则、峰谷配置、自动同步项/手动同步项、最近同步时间、核对人。
    • 调用示例页：模型名、接口类型、请求示例、返回示例、计费说明、常见错误。
    • 自有算力客户台账：客户代号、算力来源、模型、路由档位、部署方式、交接文档链接、负责人。

6. 异常与升级

  • 渠道商未开放分组或断供 → 上游渠道当天通知接入主责与 CTO，调整批次，销售 1 个工作日内告知客户。
  • 客户本地价格与总 NewAPI 不一致 → 接入主责当天修正；已产生错误计费的升级 CTO 与财务。
  • WG 或访问失效 → 向远程环境负责人申请，4 小时内恢复；不能恢复升级研发负责人。
  • 自有算力不支持 Responses API 或不稳定 → 评估阶段标注风险并签知情书；交付后故障升级研发负责人。
  • 负责人不在岗 → 备岗按配置清单接手，不靠私下转交凭据。
  • A（升级）说明：接入方案、配置与同步由接入主责拍板（A）；涉及知情书与对客承诺、渠道断供需调整批次、已产生错误计费、需求或上线日期有争议时升级 CTO。

7. 衡量指标

  • 模型上线按期率 = 按批次截止日上线的模型数 / 计划数，目标 ≥ 90%。
  • 价格同步时效 = 总 NewAPI 变更到客户本地同步完成，目标 ≤ 1 个工作日。
  • 同步差错数 = 抽查发现的价格/模型不一致项，目标 0。
  • 调用示例覆盖率 = 有示例页的已上架模型 / 已上架模型，目标 100%。

8. 低效诊断

  • 现象：接入进度靠反复催问，任务未拆分、未设依赖｜依据：「AI API」2026-07
  • 现象：谁配客户本地 API 反复确认，负责人响应慢时临时换人接手｜依据：「AI API」2026-07
  • 现象：客户本地 NewAPI 价格、峰谷配置手动同步，曾漏配模型，是否自动同步口径不一｜依据：「AI API」2026-07、2026-08
  • 现象：客户环境地址与凭据私下传递，无统一保管；远程通道失效需临时排查｜依据：「AI API」2026-08
  • 现象：每个模型的调用示例临时编写，渠道分组配错导致生图不通｜依据：「AI API」2026-08
  • 现象：不清楚共有几家自有算力客户及其配置原文，每家重新沟通；销售侧缺技术信息收集工具｜依据：「AI API」2026-09

9. 分支变体

  • 客户本地独立 NewAPI（集群客户）：部分价格定时从总 NewAPI 同步，峰谷价与新模型需手动同步。
  • 国央企/政府指定云算力：配置客户 apikey，签体验受限知情书。
  • 区域渠道自有算力（某通信服务渠道商、某区政府客户）：本地 vLLM 部署，交接文档入库。
  • 云端 LeapCore：无需本地同步，仅配置总 NewAPI。
  • 生图（chat 与 images 接口）、Claude 类（messages 接口）需要不同的调用示例。

10. 待确认问题

  • 主责是否为网关研发？客户本地 NewAPI 的长期维护人与备岗是谁？
  • 客户本地价格规则是否已成文？由谁审批？
  • 哪些配置项自动同步、哪些手动？能否全部自动化？
  • 确认信息表是否已放进销售侧飞书表单？
  • 客户环境凭据统一存放在哪个工具？
  • 知情书模板是否经法务确认？
X-DLV-22OpenClaw/龙虾批量装机与上门部署待新建240

状态：待新建｜证据：有证据（卡片 8 张 / 会话 7 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：客户采购盒子/Mac mini 需批量预装 OpenClaw/ClawLite/LeapAgent，或政企客户要求上门安装"龙虾"并演示/科普时，完成安装包获取、批量预装、API 与飞书/微信绑定、Skill 与 Logo 定制、测试和交付。
  • 负责人：主责——部署工程师（当前：游家豪·推断待确认）；协同——安装包与镜像（当前：杨明学·推断待确认）、安装包与绑定教程（当前：李铭熙·推断待确认）、ClawLite 维护与人设/API（当前：邓乾·推断待确认）、容器与环境变量（当前：杨云峰·推断待确认）、销售对接（当前：闫登辉、李鹏为·推断待确认）、上门讲解与部署（当前：李子遥、魏宗浩·推断待确认）、交付需求方（当前：杨萌·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求清单与免责确认 → ② 定方案与唯一负责人 → ③ 从统一出处取版本化安装包 → ④ 跑通样机并写参数表 → ⑤ 批量写盘/安装 → ⑥ 逐台测试入台账 → ⑦ 解绑移交或上门部署 → ⑧ 需求与问题回流
  • 交付结果：按台账逐台通过测试的设备（版本、Skill、绑定、Logo 符合需求）、客户签收/验收单、移交拉群或绑定完成记录、更新后的部署包。
  • 状态依据：2026-03～04 多次批量/上门交付靠群内口述的"临时 SOP"（8 步）完成，研发已明确提出要形成盒子交付 SOP 但未成文；上门部署全靠核心人员个人经验，信创现场反复重装；安装包获取靠在群里 @ 人，无统一出处与台账。

1. 场景判定

  • 触发条件：客户下单一批盒子/Mac mini（如 25 台、50 台）；政企领导要求上门安装龙虾（Windows/Mac/信创）；销售需要一键安装包对外提供；预装机需绑定微信/飞书。
  • 典型说法：「下周客户想要25个尊贵版盒子」「纯SOP流水线工作 差不多十分钟装一台」「我们有安装小龙虾的SOP吗」「有没有安装包」「明天我们要过去给那个老板装小龙虾」
  • 判断问题：交付物是 OpenClaw/ClawLite/LeapAgent 客户端或预装盒子，而不是 LeapCore 服务端？
  • 不归本流程管：LeapCore 服务端部署 → 请走 X-DLV-19；客户自备机器准入 → 请走 X-DLV-17；离线一体机能力对标等新需求 → 请走 X-PRD-09（需求提报登记与需求池管理）；安装包研发与发版 → 请走 RND-51（正式版本发布上线）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付主责 样机跑通、批量装机、测试、台账、移交与上门 R 部署工程师（当前：游家豪·推断待确认）
安装包/镜像 打包、写盘克隆方案、版本发布 R IT 运维（当前：杨明学·推断待确认）
安装包与教程 可复用安装包、飞书绑定教程、签名导出 R 研发（当前：李铭熙·推断待确认）
ClawLite 维护 Windows 版维护、人设、API 配置 C 研发（当前：邓乾·推断待确认）
容器配置 容器创建与环境变量注入 C LeapCore 部署研发（当前：杨云峰·推断待确认）
销售对接 需求清单、免责声明、客户沟通、移交拉群 R 销售（当前：闫登辉、李鹏为·推断待确认）
上门讲解 现场科普讲解、复杂系统部署支援 C 研发（当前：李子遥、魏宗浩·推断待确认）
需求方 提交交付需求、追踪进度 I 交付统筹（当前：杨萌·推断待确认）
方案拍板 交付方案、唯一负责人、优先级与预算（如搜索 API）拍板 A 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户需求清单：台数、硬件型号、系统、接入渠道（飞书机器人/微信/企微）、API 平台与套餐（客户自购或公司提供）、预装 Skill、人设、Logo、是否关闭自动更新、公网版/内网版。
  • 带版本号的安装包、Skill 包、人设模板（统一存放位置）。
  • 飞书 Bot 配置参数（appId/appSecret 由负责人统一管理，不在群内明文）。
  • 测试用例 1～3（如飞书收发文件、整理新闻成 Word、联网搜索）。
  • 部署前提与免责声明（同网段、网络边界、运维责任）；客户侧对接人与拉群对象。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 与客户确认需求清单与部署前提，签免责声明 销售对接 下单后 1 个工作日内 飞书表单 需求清单 🔧飞书固化
2 确定交付方案（临时方案/正式方案）并指定唯一交付负责人与备岗 CTO 需求清单后 1 个工作日内 — 方案与负责人 👤人工判断
3 从统一制品库取带版本号的安装包、Skill 包、人设模板；缺失时向打包负责人提单 交付主责 方案确定当天 制品库/飞书云盘 版本清单 🔧飞书固化
4 跑通一台样机：安装、配置 API 与搜索 key、绑定飞书 Bot（群聊白名单、@ 触发等）、改 Logo、预装 Skill、关闭自动更新，形成参数表 交付主责 + 安装包负责人 1 个工作日内 样机 样机通过记录、参数表 👤人工判断
5 批量：PE 写盘克隆或脚本批量安装，按参数表为每台生成配置 交付主责 约 10 分钟/台，按交付日倒排 写盘工具、配置脚本 批量装机 🤖自动化
6 逐台跑测试用例 1～3，序列号、版本、结果写入台账 交付主责 装机当天 多维表格 设备台账 🔧+🤖
7 寄送/自取：交付前解绑测试账号并群内确认，附扫码绑定说明；全部通过后移交客户对接人拉群 交付主责 + 销售 交付日 台账 移交记录 👤人工判断
8 上门：携带部署包（U 盘/镜像、Skill 包、人设、验收清单），按系统执行并完成功能验证 交付主责（讲解人员随行） 预约时间 部署包 验收单 👤人工判断
9 客户新需求登记 CRM，不当场承诺；问题回流工单，部署包与 SOP 更新 销售 + 交付主责 回流 1 个工作日内，更新 3 个工作日内 CRM、工单 需求与问题记录 🔧飞书固化

5. 交付物与模板

  • 交付物：需求清单、参数表、设备台账、签收/验收单、移交记录、更新后的部署包。
  • 建议模板/表单：
    • 设备台账：序号、硬件序列号、系统、安装包版本、Skill 版本、绑定渠道（Bot 名称）、API 平台、测试用例 1～3 结果、解绑状态、交付日期、操作人。
    • 上门部署包清单：安装包/镜像版本、Skill 包、人设模板、API key 发放方式、验收检查单、常见问题。

6. 异常与升级

  • 拿不到安装包或打包人在外场 → 从制品库取上一个稳定版；制品库也没有的 2 小时内升级研发负责人。
  • 飞书群聊权限不通（白名单、监听地址）→ 对照参数表核对；30 分钟内未解决联系容器配置研发。
  • 现场系统特殊（信创、低内存）→ 暂停并走 X-DLV-17 准入；当天无法完成则改期。
  • 客户要求超出交付范围（多 Agent、定制功能）→ 记录回公司评估，CTO 1 个工作日内答复。
  • API key 泄露 → 立即更换 key，记录事件并通知 CTO。
  • 交付与主线研发抢人 → 交付负责人当天报 CTO 定优先级。

7. 衡量指标

  • 单台装机时长（批量）：目标 ≤ 15 分钟。
  • 交付后 7 日返修率 = 返修台数 / 交付台数，目标 ≤ 5%。
  • 上门一次成功率：目标 ≥ 90%。
  • 核心研发上门次数/月：目标逐月下降，由部署工程师独立完成。

8. 低效诊断

  • 现象：先下单后想流程，步骤只在群内口述，无文档、无台账｜依据：「LeapCore（archived）」2026-04
  • 现象：交付范围（只装 CLI 还是连机器人一起配、谁提供飞书账号）交付前未明确｜依据：「LeapCore（archived）」2026-04
  • 现象：交付方案、网络边界与运维责任临近交付才拍板｜依据：「Leap产研测」2026-04、2026-05
  • 现象：环境变量名、监听地址、群聊白名单等配置只在聊天记录里，环节之间对不上导致返工｜依据：「LeapCore（archived）」2026-03
  • 现象：上门部署依赖核心人员亲自出马，现场按系统现学，信创现场长时间反复重装｜依据：「Claw布道/案例组」2026-03
  • 现象：安装包无统一出处，靠在群里 @ 打包人，打包人同时在外场交付｜依据：「模态AI探索小分队」2026-03、「鼎慧产研决策部」2026-03
  • 现象：客户次日要机器当天赶工，安装包路径、token 问题返工｜依据：「忠橙星行星引擎」2026-03

9. 分支变体

  • Windows 盒子批量（如 25 台一周内）：临时方案为 ClawLite + 包月模型，后续升级 LeapAgent。
  • 50 台级批量流水线：PE 写盘克隆，区分公网版/内网版，保留 OTA 升级。
  • Mac mini 预装机：装微信插件、预装办公 Skill，客户扫码绑定，交付前解绑。
  • 上门部署（Windows/Mac/信创）：政企领导场景含 AI 科普讲课，市场部介绍产品，客户自购模型套餐由我方配置。
  • 运行时差异：OpenClaw 自带飞书能力；Hermes 需另装 CLI。
  • 云端体验版（账号组 + token 额度 + 模板）可替代本地盒子。
  • 现场设备故障修理导致交付人被占用：按台账与看板交接给备岗。

10. 待确认问题

  • 主责是部署工程师还是安装包负责人？
  • 统一制品库放在哪里（Gitea release / 飞书云盘）？由谁发布？
  • 测试用例 1～3 的标准内容由谁定？
  • 客户模型套餐默认客户自购还是公司提供？key 如何发放？
  • "U 盘即装"的上门部署包是否立项？何时完成？
  • 免责声明模板是否由法务提供？
X-DLV-23离线/私有化部署包准备与预演待新建180

状态：待新建｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗4 × 跨3 × 险5

  • 适用场景：客户要求本地化/国产化/内网离线部署或 POC 时，在出发前完成可行性评估、测试环境申请、依赖梳理、按目标架构打包镜像/模型/rpm、同款环境离线预演与放行，并推进一键化部署。
  • 负责人：主责——IT 运维/镜像打包负责人（当前：杨明学·推断待确认）；协同——业务研发（当前：李玄冰、葛家和·推断待确认）、基座研发/部署（当前：望政韬·推断待确认）、架构评估（当前：陈晖·推断待确认）、部署工程师（当前：游家豪·推断待确认）、后端/部署（当前：宋祺睿·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、商务（当前：杨朋伟·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 离线可行性问卷 → ② 评估与承接决定 → ③ 申请同款测试环境 → ④ 梳理依赖与配置 → ⑤ 按目标架构打包 → ⑥ md5 校验与离线预演 → ⑦ 测试文档与手册 → ⑧ 放行
  • 交付结果：通过放行清单的离线部署包（镜像/模型/rpm/一键脚本/配置模板，含 md5）、预演记录、测试文档与用户手册、推荐配置。
  • 状态依据：2026-03～04 多次"带去才发现不行"：镜像架构与现场不符、新增依赖挤掉原有依赖导致现场起不来、模型镜像依赖版本不支持；研发质问"打包完镜像不测不验"；依赖梳理和文档要靠提醒；部署一套环境手工繁琐，交付人员无法独立出货；没有离线交付标准。

1. 场景判定

  • 触发条件：客户要求内网/离线/国产化部署或 POC；参赛或客户指定系统需要测试机；私有化部署手工繁琐需要一键化。
  • 典型说法：「如果没有公网事情会变得非常复杂」「得把配置和依赖捋出来 然后他才可以帮忙打包」「你们这打包完镜像不测不验的吗」「测试文档和用户手册记得整」「后面得想办法一键部署」
  • 判断问题：目标环境能否访问公网？目标 CPU 架构、系统、容器运行时是否与公司默认一致？
  • 不归本流程管：现场实施 → 请走 X-DLV-24；客户自备设备准入 → 请走 X-DLV-17；联网环境的交付前联调 → 请走 X-DLV-18。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
打包主责 测试环境开通、按目标架构打包、md5、组织预演 R IT 运维/镜像打包负责人（当前：杨明学·推断待确认）
业务研发 梳理依赖与配置、出推荐配置、写测试文档与手册 R 业务研发（当前：李玄冰、葛家和·推断待确认）
预演/部署 同款环境预演、现场使用验证 R 基座研发（当前：望政韬·推断待确认）、部署工程师（当前：游家豪·推断待确认）
架构评估 离线可行性与外部依赖评估 C 架构/预研负责人（当前：陈晖·推断待确认）
交付配置 LeapCore 交付规格与部署脚本 C 后端/部署（当前：宋祺睿·推断待确认）
技术建议 打包方式与本地部署方案 C Leap 研发负责人（当前：王皓南·推断待确认）
商务 提需求、填问卷、对客确认 R 商务（当前：杨朋伟·推断待确认）
承接与放行 承接决定、资源申请、放行签字 A 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 离线可行性问卷：场地是否封闭、有无公网、数据库/对象存储/外部服务/模型是否需本地化、目标硬件（CPU 架构、GPU 型号，含国产卡）、系统（如麒麟 V10）、容器运行时限制（docker/podman/k8s）、带入介质（U 盘/光盘/硬盘，是否有光驱）。
  • 合同交付范围与验收标准。
  • 目标架构的测试服务器/虚拟机申请信息（配置、系统）。
  • 依赖清单、配置模板（docker-compose、env）、多档推荐配置。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提出离线/私有化需求并填写可行性问卷 商务 需求提出后 1 个工作日内 飞书表单 问卷 🔧飞书固化
2 评估外部依赖（云存储、外部服务、模型）、本地化方案与工作量，决定是否承接 架构评估 + CTO 2 个工作日内 — 评估结论 👤人工判断
3 申请同款测试环境（配置、系统、架构）并开通 业务研发提单，打包主责开通 1 个工作日内 飞书审批、PVE/云 测试环境 🔧飞书固化
4 梳理依赖与配置：构建依赖全部本地化，IP/端口/环境变量可配置，不写死；出推荐配置 业务研发 1～2 个工作日 代码仓库 依赖清单、配置模板 👤+🤖
5 按目标架构打包镜像/模型/rpm/一键部署脚本，模型与镜像分开；CI 产出多架构包 打包主责 1 个工作日内 CI、内网 NAS 部署包 🤖自动化
6 计算 md5 上传内网 NAS；在同款纯离线环境从零执行一键脚本，跑关键 API curl 与业务用例 打包主责 + 预演/部署 出发前至少 2 个工作日 NAS、测试环境 预演记录 🤖+👤
7 编写测试文档与用户手册（AI 起草初稿），含回滚步骤 业务研发 3 个工作日内 文档模板 测试文档、手册 🤖+👤
8 对照放行清单逐项勾选，签字后方可带包出发，转 X-DLV-24 CTO（不在岗时由 Leap 研发负责人代签） 出发前 1 个工作日 多维表格 放行记录 🔧+👤

5. 交付物与模板

  • 交付物：离线部署包（带版本号、md5）、依赖清单、预演记录、测试文档、用户手册、推荐配置、放行记录。
  • 建议模板/表单：
    • 交付镜像放行清单：包名与版本、目标架构、md5、启动自测结果、关键 API curl 结果、依赖版本、模型文件、配置模板、一键脚本、回滚包、预演环境、放行人。
    • 离线可行性问卷：字段同"办之前请准备"第一项。

6. 异常与升级

  • 打包架构与目标不符 → 立即在目标架构（云端/CI）重打，不得带包出发，原因记录入清单。
  • 预演失败或依赖冲突 → 修复后重新预演，出发日顺延，商务当天告知客户。
  • 目标环境禁止 docker → 改用 podman/k8s/rpm 方案，补 K8s 部署文档，重新评估工期报 CTO。
  • 外部依赖无法本地化 → 向客户确认能否开公网白名单，否则缩减范围并书面确认。
  • 测试资源 1 个工作日未开通 → 升级 CTO。

7. 衡量指标

  • 放行清单覆盖率 = 走放行清单的离线交付 / 离线交付总数，目标 100%。
  • 包问题导致的二次出差次数：目标 0。
  • 准备周期 = 依赖梳理开始到放行的工作日，目标 ≤ 5 个工作日。
  • 一键化率 = 无需手敲命令即可完成部署的项目比例，目标逐季提升。

8. 低效诊断

  • 现象：在本机架构打包，与目标服务器架构不符，返工重打｜依据：（推断）
  • 现象：镜像打包后未在同款环境预演就带去，现场依赖冲突、模型依赖版本不支持｜依据：「跃迁基座项目交付沟通」2026-03、2026-04
  • 现象：大体积镜像无法现场重下，补依赖只能回公司｜依据：「跃迁基座项目交付沟通」2026-04
  • 现象：由谁梳理依赖不明确，依赖数量说不清｜依据：「思政演示项目群」2026-03
  • 现象：测试文档、用户手册靠提醒才写｜依据：「平台部」2026-03
  • 现象：部署一套环境手工繁琐，关键步骤依赖研发，交付人员无法独立出货｜依据：「生态大会筹备-硬件」2026-05

9. 分支变体

  • 军队院校封闭内网 POC：先填可行性问卷，参照军队客户"构建镜像拷贝启动"方式。
  • 信创终端/国产芯片：麒麟测试机，出多套推荐配置。
  • 国产卡（海光 DCU）镜像 vs 英伟达镜像；文档解析 vLLM 版 vs CPU 版。
  • 包形态：docker 离线包 / Electron 安装包 / rpm。
  • 参赛指定系统测试机。
  • 一键化：先简化到部署工程师能独立部署出货，再到自动化出货（交付规格模板如 4c8g）。

10. 待确认问题

  • 主责是运维打包负责人还是业务研发？
  • 放行签字人是 CTO 还是研发负责人？
  • CI 多架构构建与冒烟测试是否已具备？
  • 离线可行性问卷是否作为签约前必填项？
  • 一键部署脚本归属哪个仓库、由谁维护？
X-DLV-24离线/私有化项目现场部署实施待优化375

状态：待优化｜证据：有证据（卡片 6 张 / 会话 5 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：项目到交付节点，把知识库/RAG/ChatBI/大模型/文档解析/embedding 等部署到客户内网、离线或国产硬件，完成现场测试、验收、上线及补丁更新；含数天内紧急交付和非标本地大模型一体机。
  • 负责人：主责——交付运维负责人（当前：杨明学·推断待确认）；协同——基座研发/现场部署主力（当前：望政韬·推断待确认）、部署工程师（当前：游家豪·推断待确认）、应用研发（当前：李玄冰、张康·推断待确认）、模型部署与路由（当前：柯逸飞·推断待确认）、验收测试（当前：陈晖、黄振锋、裴蔬桐·推断待确认）、客户接口（当前：常元和、杨朋伟、李鹏为·推断待确认）、产品（当前：杨萌·推断待确认）；兜底——CTO/项目总协调（当前：丁震宇·推断待确认）
  • 核心流程：① 交付任务单与时间窗 → ② 核对放行包 → ③ 介质与入场手续 → ④ 现场部署/升级 → ⑤ 逐项测试 → ⑥ 客户验收与汇报 → ⑦ 问题回传与补丁回归 → ⑧ 文档沉淀
  • 交付结果：在客户环境运行并经客户验收的系统；部署记录（版本、哈希、配置、回滚包）；遗留问题清单与反馈表；更新后的部署文档。
  • 状态依据：已有 docker-compose/env 模板、一键部署脚本、部署文档与反馈表；但 2026-01～08 现场反复救火：国产卡机器拉取失败通宵改方案、IP 写死搬机后失效、未预演镜像现场起不来、同一问题多次往返现场、部署文档反复被催、命令靠翻聊天记录；本地大模型交付多轮返工且部署要点未纳入运维 SOP。

1. 场景判定

  • 触发条件：合同到交付/更新节点；客户临时要求数天内交付可运行版本；非标"本地部署模型"一体机需上线；已部署系统需带补丁再到现场。
  • 典型说法：「机子运进去了就基本出不来了，能打成镜像的都尽量打镜像」「他们那边不让装 docker」「一定要保证离线环境能跑」「周五 or 周六 or 周日就得现场交付一版能跑的网页了」「你得形成一下SOP文档」
  • 判断问题：部署包是否已按 X-DLV-23 放行？本次是首次部署、更新还是紧急交付？
  • 不归本流程管：部署包准备与预演 → 请走 X-DLV-23；联网 LeapCore 部署 → 请走 X-DLV-19；客户本地 NewAPI 价格/模型同步 → 请走 X-DLV-21。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付主责 任务单、时间窗、硬件与驱动、部署文档维护 A/R 交付运维负责人（当前：杨明学·推断待确认）
现场部署主力 现场部署/升级、程序适配 R 基座研发（当前：望政韬·推断待确认）
部署工程师 刻盘/介质、现场执行、客户试用反馈收集 R 部署工程师（当前：游家豪·推断待确认）
应用研发 出镜像、修复补丁、远程结对排查 R 应用研发（当前：李玄冰、张康·推断待确认）
本地模型 模型下载、本地 NewAPI 路由、压测 R（本地模型分支） 网关研发（当前：柯逸飞·推断待确认）
验收测试 内部测试、试用反馈 C 测试/评估（当前：陈晖、黄振锋、裴蔬桐·推断待确认）
客户接口 约时间、对客沟通、催办与验收协调 R 商务/销售（当前：常元和、杨朋伟、李鹏为·推断待确认）
产品 本地模型选型 C 产品（当前：杨萌·推断待确认）
兜底 项目节奏、优先级、对客户领导沟通 A（升级） CTO/项目总协调（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已放行的部署包（版本、md5/哈希、旧镜像回滚包）。
  • 介质：U 盘/移动硬盘/光盘（先确认客户可插 U 盘、有无光驱）。
  • 交付任务单：客户代号、硬件、镜像版本、责任人、时间窗。
  • 入场材料：身份证、笔记本、客户联系人、机房手续；需下架搬运时的运输安排。
  • 一键部署与升级脚本（禁止现场手敲长命令）。
  • 测试用例：转换、解析、向量化、AI 对话、合同功能清单；本地模型另加模型切换、推理压测、重启自启、稳定性。
  • 反馈表链接。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建交付任务单，约客户时间窗，确认入场手续 交付主责 + 客户接口 交付前 3 个工作日（紧急交付当天） 多维表格 任务单 🔧飞书固化
2 核对放行记录与哈希，未放行不出发；紧急交付当天召开方案会，定模型清单与分工 交付主责 出发前 1 个工作日 放行清单、飞书日程 出发确认 👤人工判断
3 携带介质与设备出发；需搬机的按机房手续下架、运输 部署工程师/交付主责 按时间窗 — 物料清单 👤人工判断
4 首次部署执行一键脚本；升级按"停止→删除旧容器→删除旧镜像→导入→启动"脚本执行，保留旧镜像用于回滚 现场部署主力 时间窗内 一键脚本 部署日志 🤖自动化
5 逐项跑测试用例并记录；本地模型做推理压测与重启测试 现场部署 + 验收测试 部署当天 用例表 测试记录 🤖+👤
6 客户验收（合同内功能必须通过，合同外不强求），向项目总协调报告"部署完、验收完" 现场部署 + 客户接口 部署当天 验收单 验收单 👤人工判断
7 遗留问题登记反馈表并分派，远程结对排查；修复合并后回归、重新放行，约下次上门 应用研发 登记后 1 个工作日内分派，补丁按约定 1～2 周 反馈表、工单 补丁版本 🔧飞书固化
8 把现场问题与命令补进部署文档；大版本升级提前告知客户"数据需重新导入" 交付主责 交付后 3 个工作日内 飞书 wiki 文档更新 🤖+👤

5. 交付物与模板

  • 交付物：部署记录、测试记录、验收单、反馈表、部署文档更新版。
  • 建议模板/表单：
    • 交付任务单：客户代号、硬件（型号、国产卡）、系统与容器运行时、镜像版本、哈希、回滚包、介质、时间窗、入场手续、责任人、状态。
    • 现场测试用例表：功能、步骤、结果、截图、是否合同内。
    • 本地模型发货前清单：GPU 可见、权重预置、推理压测、重启后就绪时间、开机自启、本地模型单价设为极小值（设为 0 会被当成默认高价）。

6. 异常与升级

  • 现场镜像起不来/依赖冲突 → 先回滚旧镜像保证客户可用；当天远程结对排查，修不好则约下次上门，CTO 对客户说明。
  • 国产硬件驱动/适配问题 → 交付主责当天联系厂商，每日同步进度；超过 3 个工作日升级 CTO。
  • 客户环境限制（禁 docker、浏览器版本旧）→ 当场记录并回传 X-DLV-23 更新包规格。
  • 紧急交付人手不足 → CTO 宣布优先级并调人，周末加班走审批调休。
  • 补丁被后续合并覆盖 → 研发负责人当天恢复并补回归。
  • A（升级）说明：任务单、时间窗与现场部署结论由交付主责拍板（A）；现场修不好需对客户说明、国产硬件适配超过 3 个工作日、紧急交付需定优先级与调人时升级 CTO。

7. 衡量指标

  • 现场一次部署成功率 = 无需二次上门的交付 / 交付总数，目标 ≥ 90%。
  • 同一问题往返现场次数：目标 ≤ 1 次。
  • 遗留问题关闭周期 = 登记到关闭的工作日，目标 ≤ 10 个工作日。
  • 部署文档更新及时率 = 交付后 3 个工作日内完成更新的比例，目标 100%。

8. 低效诊断

  • 现象：打包、拉取进度靠反复催问；国产卡机器上拉取失败，现场改源改方案到通宵｜依据：「跃迁基座项目交付沟通」2026-01、2026-02
  • 现象：IP 写死，搬机后全部失效｜依据：「跃迁基座项目交付沟通」2026-02
  • 现象：部署文档多次被催仍未成文，线下部署只能依赖个别人｜依据：「跃迁基座项目交付沟通」2026-02、2026-03
  • 现象：镜像未在同款环境验证就带去，现场起不来，同一问题多次往返；命令靠翻聊天记录｜依据：「跃迁基座项目交付沟通」2026-03、2026-04
  • 现象：紧急交付临时插单，设备分批到货、机房手续与环境依赖不明，进展反复催问｜依据：「⭐大模型基座事业群」2026-01、2026-02
  • 现象：合并代码后补丁被覆盖，试用反馈分散｜依据：「某水利客户研发群」2026-07、2026-08
  • 现象：本地大模型部署多轮返工（CPU 推理、量化模型过弱、接口错误），本地 NewAPI 部署未纳入运维 SOP，价格默认值踩坑｜依据：「某区政府客户项目群」2026-07、2026-08

9. 分支变体

  • 军队客户：国产卡（壁仞+海光），光盘/内网带入，不可联网，刻盘需算哈希，入室需预约。
  • 水利/院校类客户：国产化，只能 k8s/podman，达梦数据库，需打 rpm。
  • 电力央企客户：可插 U 盘，不允许 docker/conda，需 k8s 或直接运行，需提供算法备案号与组件依赖清单。
  • 算力机房客户（多卡一体机）：交付带包装盒/标签，做资产归档。
  • 紧急交付（数天内）：国产卡与 5090 一体机两条环境并行，公司内测后机房上架。
  • 非标本地大模型一体机：企业本地 NewAPI 加渠道路由，客户端可选本地模型；选型由产品与 CTO 定，单人使用场景可用单卡。
  • 标准商务版（轻量/标准）部署。

10. 待确认问题

  • 主责是交付运维负责人还是基座研发？两者如何分工？
  • 合同内功能清单是否在交付任务单中列明并作为验收依据？
  • 已补充的本地大模型部署 SOP 存放在哪里？本地 NewAPI 部署是否纳入运维 SOP？
  • 补丁回访周期 1～2 周是否可行？
  • 紧急交付的加班调休规则是否已有制度？
  • 涉密客户的介质管理（刻盘、哈希、带入带出）是否需要保密审批？
X-DLV-25信创/国产算力适配与厂商协同待新建400

状态：待新建｜证据：有证据（卡片 7 张 / 会话 8 个）｜优先级：频4 × 耗5 × 跨5 × 险4

  • 适用场景：客户、渠道或厂商联合宣发提出信创/国产算力要求（国产 CPU/OS/GPU/一体机），需要确定适配版本、完成测试、向厂商升级问题并统一对外"是否已适配"口径时启动
  • 负责人：主责——信创&Linux 适配负责人（当前：李子遥·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、信创主测（当前：潘浩伟·推断待确认）、产品总监（当前：杨萌·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求登记 → ② 定适配版本、负责人与 DDL → ③ 拿机/备环境 → ④ 打包与部署测试 → ⑤ 厂商问题登记与升级 → ⑥ 出测试结论并更新适配矩阵 → ⑦ 对外口径同步
  • 交付结果：适配矩阵中一条"平台×产品×版本×结论"记录、信创测试报告、厂商问题跟踪记录，以及可直接转给销售/市场的适配口径
  • 状态依据：已有《Leap信创上下文》文档覆盖打包与测试 SOP，但需求入口、版本/DDL 指派、厂商问题升级、对外口径均无固定做法；03～10 月海光、壁仞、麒麟等厂商问题靠口头"抽鞭子"催办约 25 次，适配 owner 与 DDL 多次被追问

1. 场景判定

  • 触发条件：客户/渠道要求在国产 CPU（海光、飞腾、兆芯、龙芯等）、国产 OS（麒麟、统信、盘古OS）或国产 GPU/DCU（海光 K100、壁仞）上运行公司产品；信创厂商发起联合宣发或互认证；国产卡上新模型/镜像/驱动跑不起来
  • 典型说法：「后面得安排测试一下 LeapCore 的国产服务器部署了」「跳过 1.4 直接给信创上 1.5」「记得问厂商能不能给我们搞点新的小模型」「拿着这个报告去找厂商的人，让他们自己修」
  • 判断问题：要求是否落在"国产软硬件平台"上？问题根因是平台/驱动/厂商系统，还是我方产品通用缺陷？
  • 不归本流程管：申请厂商样机、测试卡、填生态合作申请表 → 请走 ECO-04；信创打包流水线的研发实现细节 → 请走 RND-63；客户自备第三方设备是否能部署的准入评估 → 请走 X-DLV-17；离线/私有化现场部署实施 → 请走 X-DLV-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
信创适配负责人 统一受理、定版本/DDL、维护适配矩阵、对接厂商技术窗口、出对外口径 A/R 信创&Linux 适配负责人（当前：李子遥·推断待确认）
部署研发 在目标平台部署、排查镜像/依赖/内核问题 R LeapCore 部署研发（当前：杨云峰·推断待确认）
IT 运维/硬件 拿机、装系统、上架、网络 R IT 运维（当前：杨明学·推断待确认）
测试 按客户硬件实测、出测试报告、判定 P1 缺陷 R 测试负责人（当前：张东郅·推断待确认）；信创主测（当前：潘浩伟·推断待确认）
产品 确认适配版本与优先级 C 产品总监（当前：杨萌·推断待确认）
销售/市场 提需求、提供厂商商务渠道、按口径对外答复 C/I 市场销售负责人（当前：李鹏为·推断待确认）
研发负责人/CTO 拍板版本取舍、厂商高层升级、兜底 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求来源与客户/项目名称（用内部代号）、期望上线或演示日期
  • 目标平台：CPU 架构（x86_64/aarch64/loongarch）、OS 名称与版本、内核版本、GPU/DCU 型号与驱动版本
  • 要适配的产品与版本（客户端/服务端，建议优先客户端）、需运行的模型清单
  • 机器来源（厂商借测/渠道原型机/客户现场）与存放位置、远程访问方式
  • 客户对"适配"的验收口径（能启动/核心功能无 P1/性能指标）
  • 请求最少包含字段（登记信创适配需求表时必填，缺一项不立项、不另行追问）：需求来源（客户代号/渠道/厂商宣发）、商机或订单编号、目标平台四要素（CPU 架构与型号、OS 及版本、内核版本、GPU/DCU 型号与驱动版本）、要适配的产品与版本号、必须运行的模型清单、机器来源与位置及远程访问方式、客户验收口径、期望完成日与原因（演示/交付/宣发日期）、需求方岗位

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在"信创适配需求表"登记需求，自动通知信创负责人 销售/市场或需求方 收到客户要求当天 飞书多维表格（表单） 需求记录（需求表一行，状态“待受理”，自动 @ 信创适配负责人） 🔧飞书固化
2 查适配矩阵：已有结论直接按口径答复；无结论进入适配 信创适配负责人 登记后 1 个工作日内 适配矩阵 / 答疑机器人 答复（回写需求表 + 回复需求方）或立项（需求表状态“已立项”）；超时→研发负责人 🔧+🤖
3 确定适配版本、负责人、DDL，写入适配计划（跨版本取舍由研发负责人拍板） 信创适配负责人；研发负责人 立项后 1 个工作日内 多维表格 + 飞书任务 适配计划行（版本/owner/DDL，飞书任务指派到 owner，需求方可见） 🔧飞书固化
4 拿机、装系统、开远程，机器登记到原型机台账 IT 运维 计划确定后 2 个工作日内 原型机台账 可用环境（原型机台账一行：位置、远程方式、系统版本，凭据走密码库）；超时→信创适配负责人，再 1 个工作日→研发负责人 👤人工判断
5 按 RND-63（信创适配开发、打包与验收）的打包规范构建产物并部署（优先容器化规避环境差异） 部署研发 环境就绪后 3 个工作日内 LeapNix/Hydra、Docker 可运行实例（适配计划行回填产物版本与实例地址，通知测试）；超时→信创适配负责人升级研发负责人 🤖自动化
6 按测试模板实测并出报告，判定是否存在 P1 缺陷 测试 部署后 2 个工作日内 信创测试报告模板 测试报告（链接贴入适配计划行，P1 列表同步部署研发）；超时→测试负责人，再 1 个工作日→研发负责人 🔧+🤖
7 平台/驱动/厂商系统问题登记"厂商问题跟踪表"，附复现报告，向厂商技术窗口提交 信创适配负责人 发现后 1 个工作日内 厂商问题跟踪表、工单 厂商问题单（跟踪表一行：提交日期、厂商窗口、预期回复日） 🔧飞书固化
8 厂商 5 个工作日无实质回复，升级研发负责人走厂商高层/商务渠道；同时评估临时方案 信创适配负责人 → 研发负责人 第 5 个工作日 飞书任务提醒 升级记录（跟踪表“升级记录”列）、临时方案（写入适配计划行） 👤人工判断
9 更新适配矩阵结论（可用/有条件可用/不可用 + 已知问题）并在 Linux&信创交流群同步口径 信创适配负责人 测试报告出具后 1 个工作日内 适配矩阵、群公告 对外口径（适配矩阵一行 + 群公告 + 回复需求表发起人，需求表状态“已关闭”） 🔧+🤖

5. 交付物与模板

  • 交付物：适配矩阵记录、信创测试报告、厂商问题单、对外适配口径
  • 建议模板/表单：
    • 适配矩阵：CPU 架构｜CPU 型号｜OS 及版本｜内核｜GPU/驱动｜产品｜产品版本｜结论｜已知问题｜测试报告链接｜更新日期
    • 适配计划：需求来源｜目标平台｜适配版本｜负责人｜DDL｜状态
    • 厂商问题跟踪表：问题现象｜厂商｜平台版本｜我方临时方案｜是否阻塞验收｜提交日期｜厂商回复｜催办记录｜升级记录｜关闭日期
    • 对外口径：按"通用计算平台（架构+glibc）"表述，"能跑"定义为"核心功能无 P1 缺陷"，未实测平台标注"推知可用、不作保证"

6. 异常与升级

  • 适配无 owner 或 DDL 超期 → 信创负责人当天在计划表标红 → 升级研发负责人（1 个工作日内重新指派）
  • 厂商镜像/驱动不可用、修复周期长 → 先上临时方案（内置浏览器、降级镜像等）→ 是否作为验收阻塞项由信创负责人与测试负责人共同判定，分歧报研发负责人（2 个工作日内）
  • 客户投诉国产卡速度/并发差 → 用硬件性能基线说明属硬件限制 → 必要时由研发负责人与客户高层沟通
  • 适配工作是否属于厂商义务存在争议 → 写入项目约定或合作协议 → 报研发负责人决策
  • 需求登记字段不全（缺目标平台四要素、产品版本或期望完成日） → 不立项，信创适配负责人退回需求方补齐 → 补齐超 2 个工作日且有演示/宣发日期的，升级市场销售负责人
  • 适配计划行状态超过该步时限未更新（环境、产物、报告任一停滞） → 信创适配负责人标红并 @ owner → 再过 1 个工作日无动作升级研发负责人；影响客户日期的当天通知需求方

7. 衡量指标

  • 适配周期 = 需求登记到适配矩阵出结论的工作日，目标 ≤ 10 个工作日
  • 适配计划完整率 = 有 owner 且有 DDL 的适配项 / 全部适配项，目标 100%
  • 厂商问题平均关闭时长 = 提交到关闭的自然日，按厂商统计，季度回顾
  • 适配口径自助率 = 由矩阵/机器人直接答复的咨询 / 全部咨询，目标 ≥ 70%

8. 低效诊断

  • 现象：适配版本在群内讨论后定下，但适配 owner 不明、无 DDL，被追问"向谁汇报"（立项环节缺指派）｜依据：「Leap产研决策部」2026-09
  • 现象：客户临近要看效果才排国产服务器测试，事后补流程（需求入口缺失，无兼容性记录）｜依据：「LeapCore（archived）」2026-05
  • 现象：国产 DCU 上镜像/驱动问题反复靠口头催厂商，无问题清单，厂商义务与我方义务边界不清（缺厂商问题跟踪与升级机制）｜依据：「跃迁基座项目交付沟通」2026-03、2026-04、2026-05
  • 现象：厂商迟迟不更新驱动/模型，现场每 1～2 周白跑一次（缺升级路径）｜依据：「（某水务客户）公司研发」2026-07、2026-08
  • 现象：销售/市场反复问"某硬件适配没有"，技术与市场语言不一致（缺统一口径与矩阵）｜依据：「Linux&信创交流群」2026-07、「New API Claw SKILL计划」2026-03
  • 现象：厂商系统缺陷需走厂商销售立项，追踪靠人记忆、反复请领导督办（缺厂商问题台账与定期汇总）｜依据：「信创LeapCore客户端适配」2026-07、2026-09、2026-10

9. 分支变体

  • 国产 GPU/DCU（海光 K100、壁仞）：重点是驱动、推理镜像、模型版本；问题直接走厂商驻场/技术窗口，超期由研发负责人升级厂商高层
  • 国产 CPU 服务器（兆芯 x86、龙芯、飞腾）：先确认架构，x86_64 可沿用 Docker 部署，loongarch/aarch64 走信创打包流水线
  • 信创一体机原型机（盘古OS/银河麒麟）：机器入原型机台账，客户端优先，下载产物放对象存储
  • 厂商 OS/浏览器缺陷（麒麟外链、奇安信浏览器、统信镜像慢）：出事故报告 + 临时方案，经销售/市场渠道推动厂商立项
  • 厂商联合宣发：按宣发时间倒排，适配版本由研发负责人拍板
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 信创适配主责是否确认为信创&Linux 适配负责人？观察中另有"兼信创负责人"的说法，需统一
  • 厂商问题"5 个工作日无回复即升级"是否可行？升级对象是研发负责人还是销售/市场负责人？
  • 适配矩阵与需求表放在哪个飞书空间，由谁维护？是否接入答疑机器人？
  • "能跑"的对外定义（无 P1 缺陷 / 推知可用不保证）是否需要市场、产品、法务共同确认？
  • 厂商义务与我方义务边界是否写入厂商合作协议或项目合同？
X-DLV-26客户现场准入材料准备待新建150

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨5 × 险5

  • 适用场景：要进入国企、央企、军队或涉密客户的生产环境部署前，需要准备人员入场材料和软件准入材料时启动
  • 负责人：主责——项目交付负责人（当前：丁震宇·推断待确认）；协同——IT 运维/硬件（当前：杨明学·推断待确认）、部署工程师（当前：游家豪、张康、邓乾·推断待确认）、基座研发（当前：望政韬·推断待确认）、法务（当前：待指定）、人事（当前：待指定）；兜底——研发条线负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 获取客户准入要求 → ② 拆成人员/软件/合规三类清单 → ③ 私密收集人员材料 → ④ 生成组件依赖清单与安全说明 → ⑤ 合规材料（算法备案号等）核对 → ⑥ 打包提交客户 → ⑦ 安排考试/登记并归档
  • 交付结果：客户认可的准入材料包（人员登记、电子签、考试记录、组件依赖清单/SBOM、安全加固说明、算法备案信息）和准入名单
  • 状态依据：无清单和模板；02～03 月到现场才知道不能带手机、不能用 Docker/conda、需算法备案号，身份证号与电子签直接在群里明文收集

1. 场景判定

  • 触发条件：客户要求在其生产环境部署软件，并发来准入要求（人员登记、电子签、安全考试、软件组件申报、算法备案等）
  • 典型说法：「用的模型还得整个算法备案号」「列一下组件和依赖，他们还得申请」「身份证+电子签发我一份」「后面需要轮流去客户那边部署东西」
  • 判断问题：客户是否对"进场的人"或"进场的软件"有审批？没有材料是否会被拒绝入场？
  • 不归本流程管：算法备案本身的办理 → 请走 LEG-25；离线部署包制作与预演 → 请走 X-DLV-23；现场部署实施 → 请走 X-DLV-24；客户索要设备 root/管理员账号 → 请走 X-SEC-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目交付负责人 对接客户获取准入要求、拆清单、分派、提交材料 A/R 项目交付负责人（当前：丁震宇·推断待确认）
IT 运维/硬件 列组件与依赖清单、向厂商要部署包 R IT 运维（当前：杨明学·推断待确认）
基座研发 安全加固说明、模型与算法说明 R 基座研发负责人（当前：望政韬·推断待确认）
入场人员 按表单提交个人材料、参加客户考试 R 部署工程师（当前：游家豪、张康、邓乾·推断待确认）
法务 核对算法备案号、保密承诺文本 C 法务（当前：待指定）
人事 提供在职证明、社保证明等人员资质材料 C 人事（当前：待指定）

3. 办之前请准备

  • 客户准入要求原文（图片/文件），注明客户联系人和截止日期
  • 拟入场人员名单与入场时间段
  • 本次部署的产品、版本、模型清单（含算法备案号或备案状态）
  • 部署形态（容器/裸机/K8s）及客户禁用项（如禁用 Docker/conda、禁带手机、只能光盘/U 盘介质）
  • 公司资质：营业执照、保密协议模板、安全加固说明模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 向客户索取完整准入要求，登记到项目准入清单 项目交付负责人 确定进场日期后 1 个工作日内 飞书多维表格 准入要求清单 🔧飞书固化
2 按"人员/软件/合规/介质"四类拆项并指派责任人和截止日 项目交付负责人 拿到要求当天 飞书任务 分工清单 👤人工判断
3 用飞书私密表单收集人员身份证、电子签等材料，仅交付负责人可见，禁止群内发送 入场人员 表单发出后 1 个工作日内 飞书表单（权限受限） 人员材料 🔧飞书固化
4 生成组件与依赖清单（SBOM）及版本 IT 运维 2 个工作日内 依赖扫描脚本 组件依赖清单 🤖自动化
5 编写安全加固说明、模型/算法说明，核对算法备案号 基座研发；法务 3 个工作日内 模板文档 安全说明、备案信息 👤人工判断
6 汇总材料包并提交客户，记录提交时间与客户回执 项目交付负责人 进场前 5 个工作日 加密压缩包/客户指定渠道 提交记录 👤人工判断
7 安排客户考试/登记，结果更新到准入名单 项目交付负责人；入场人员 按客户排期 准入名单 准入名单 🔧飞书固化
8 进场后，个人敏感材料按客户要求留存或销毁，准入材料包归档至项目目录 项目交付负责人 部署完成后 3 个工作日内 飞书云盘项目目录 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：准入材料包、准入名单、客户回执
  • 建议模板/表单：
    • 客户准入清单：客户代号｜要求项｜类别（人员/软件/合规/介质）｜责任人｜截止日｜状态｜客户回执
    • 人员入场表单（私密）：姓名｜证件类型｜电子签上传｜考试状态｜入场时段（证件号仅存表单，不外传）
    • 组件依赖清单：组件名｜版本｜许可证｜来源｜是否联网｜是否容器
    • 安全加固说明模板：部署架构、端口、账号策略、日志、数据存储位置、离线运行说明

6. 异常与升级

  • 到现场才发现新要求 → 现场人员当天回传要求 → 交付负责人补入清单并评估是否延期（当天告知客户）
  • 软件被要求禁用容器/conda → 转 X-DLV-23 制作裸机包 → 研发负责人决定排期（1 个工作日内）
  • 算法备案号缺失 → 法务确认可否用上游模型备案信息替代 → 无法替代则升级研发负责人与客户协商（2 个工作日内）
  • 人员材料在群内明文发出 → 立即撤回并转私密表单 → 告知安全负责人（当天）

7. 衡量指标

  • 准入一次通过率 = 首次提交即被客户接受的项目 / 全部需准入项目，目标 ≥ 90%
  • 准入准备周期 = 拿到要求到材料提交的工作日，目标 ≤ 5 个工作日
  • 敏感信息群内明文发送次数，目标 0

8. 低效诊断

  • 现象：区域禁带手机、禁 Docker/conda、需算法备案号等约束到现场才知道（要求获取环节缺失）｜依据：「跃迁基座项目交付沟通」2026-03
  • 现象：人员身份证号与电子签在群里直接发送（材料收集缺私密通道）｜依据：「跃迁基座项目交付沟通」2026-03
  • 现象：组件依赖清单、安全说明临时分派、靠手写记录（缺模板与自动生成脚本）｜依据：「跃迁基座项目交付沟通」2026-03

9. 分支变体

  • 军队/涉密客户：介质只能光盘，现场手写记录，不得线上交接涉密材料
  • 某电力央企客户：可用 U 盘，不允许 Docker/conda，需身份证+电子签+安全考试，人员轮流入场
  • 某水利设计院客户：K8s + 运维平台部署，按客户运维平台要求申报

10. 待确认问题

  • 主责是否下放给专职项目交付经理，而非由研发条线负责人亲自收集？
  • 人员证件材料由谁保管、保留多久、何时销毁？是否需人事出具统一授权？
  • 是否已有统一的安全加固说明与组件清单模板？是否需要法务审阅？
  • "进场前 5 个工作日提交"是否符合常见客户审批周期？
X-DLV-27客户 POC/演示环境搭建与交付待优化375

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：销售演示后客户要求限期 POC，或客户领导来演示/验收，需要拉研发定方案、搭演示/试用环境、按意见修改并交付甲方时启动
  • 负责人：主责——POC 实施负责人/FDE Leader（当前：黄振锋·推断待确认）；协同——销售/客户对接（当前：刘昱潇、杨朋伟·推断待确认）、研发排期（当前：王皓南·推断待确认）、Skill 研发（当前：李凯·推断待确认）、演示环境部署（当前：望政韬、魏宗浩·推断待确认）、Demo 开发（当前：裴蔬桐·推断待确认）、数据入库（当前：李玄冰·推断待确认）、现场支持（当前：杨明学·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① POC 立项登记 → ② 技术评估与方案选型 → ③ 与客户确认截止、验收口径 → ④ 搭环境与开发 → ⑤ 需求—功能对表与内部彩排 → ⑥ 交付甲方并出测试报告 → ⑦ 收集反馈与商务跟进
  • 交付结果：可访问的 POC/演示环境、使用文档或演示视频、POC 测试报告，以及客户书面/记录在案的验收意见
  • 状态依据：演示与 POC 已形成习惯做法（先测、录屏、写文档、发客户），但 01～09 月多次出现截止日在群里反复变动、方案边聊边定、交付前夜返工，缺立项评估、验收口径和交付检查清单

1. 场景判定

  • 触发条件：客户演示后提出限期 POC；客户领导来访演示/验收；客户会后提修改意见需限时改 Demo；水利、地质、电力等项目节点前需要试用环境
  • 典型说法：「先走 SOP，我等下看看」「今天就催我确定 POC 交付周期」「先完成后完美，先录视频发群里看一下再优化」「明天要给领导演示，就走马观花一下」
  • 判断问题：客户是否要"亲手试用/验收"一个专门搭建的环境？是否有明确截止日和验收口径？
  • 不归本流程管：一般售前演示准备与执行 → 请走 SAL-11；演示机/样机借用 → 请走 X-DLV-05；演示前版本冻结 → 请走 RND-61；展会/大会演示 → 请走 MKT-05；正式交付部署 → 请走 X-DLV-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
POC 实施负责人 方案落地、人力调度、进度、测试报告 A/R FDE Leader（当前：黄振锋·推断待确认）
销售/客户对接 立项登记、客户原话与材料归档、确认截止/验收口径、对外发送 R 销售负责人（当前：刘昱潇、杨朋伟·推断待确认）
研发负责人/CTO 是否做、选哪条产品线、算力与外包资源审批 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
研发排期 协调研发人力与版本 C Leap 研发负责人（当前：王皓南·推断待确认）
开发/部署 Skill 能力包、Demo 前端、环境部署、数据入库 R Skill 负责人（当前：李凯·推断待确认）；前端（当前：裴蔬桐·推断待确认）；基座研发（当前：望政韬、魏宗浩·推断待确认）；知识库研发（当前：李玄冰·推断待确认）
现场支持 现场网络、设备、离线环境 R IT 运维（当前：杨明学·推断待确认）

3. 办之前请准备

  • 客户需求原文件、客户原话记录（会议纪要/录音）、预算区间与是否后续招投标
  • POC 截止日、验收口径（由客户书面确认）、竞争对手情况
  • 客户环境限制：本地模型/公网 API、离线、国产系统、涉密
  • 脱敏样例数据、演示场景清单与示例问答
  • 是否需要先签保密协议或盖章文件

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在 POC 看板登记：客户、截止日、预算、环境限制、需求文件、客户原话 销售/客户对接 客户提出后当天 飞书多维表格（POC 看板）+ 专项群 POC 立项记录 🔧飞书固化
2 技术评估：是否有卡点、产品线（LeapCore/LeapBase+Skill）、人力与算力额度；决定做/不做 POC 实施负责人；研发负责人 登记后 1 个工作日内 评估模板 方案与资源结论 👤人工判断
3 与客户书面确认截止日、验收口径、交付形式，结论回填看板 销售/客户对接 方案确定后 1 个工作日内 邮件/飞书 确认记录 👤人工判断
4 搭建环境（域名、端口、账号、模型 API）、开发功能、数据入库 开发/部署 按截止日倒排，交付前 2 个工作日完成 云服务器、Gitea、NewAPI 可用环境 🔧+👤
5 按"需求—功能—证据"对表检查，冒烟测试，开演示账号 POC 实施负责人 交付前 1 个工作日 检查清单 对表结果 🔧飞书固化
6 录屏、写使用文档；演示场景内部彩排，不稳定功能不演示 开发/部署；销售 交付前 1 个工作日 录屏工具、飞书文档 视频、使用文档 🤖自动化
7 生成 POC 测试报告初稿并人工审核 POC 实施负责人 交付当天 测试报告模板 + AI 测试报告 🔧+🤖
8 交付甲方（环境地址、文档、报告），涉密项目改线下说明 销售/客户对接 截止日当天 客户指定渠道 交付记录 👤人工判断
9 客户反馈逐条建任务，修改后重复步骤 5～8；POC 结束复盘并更新看板 POC 实施负责人 反馈后 1 个工作日内建任务 飞书任务 反馈清单、复盘 🔧飞书固化

5. 交付物与模板

  • 交付物：POC 环境、使用文档、演示视频、POC 测试报告、客户反馈清单、复盘记录
  • 建议模板/表单：
    • POC 看板：客户代号｜来源销售｜截止日｜验收口径｜产品线｜实施负责人｜环境地址｜材料清单｜状态｜是否转招投标
    • 交付检查清单：部署｜域名/端口｜账号｜示例数据｜文档｜冒烟测试｜录屏｜涉密检查
    • POC 测试报告：背景与目标｜环境｜测试用例｜结果｜问题与限制｜结论

6. 异常与升级

  • 截止日不可能完成 → 实施负责人当天提出缩减范围方案 → 销售与客户协商，研发负责人拍板（1 个工作日内）
  • 客户环境缺容器/IT 不配合 → 销售请客户 IT 负责人介入 → 升级研发负责人与客户高层沟通（2 个工作日内）
  • 演示前环境重启/功能故障 → 切兜底录屏 → 事后复盘
  • 涉密材料 → 不线上传输，改线下说明或由客户自行脱密
  • A（升级）说明：POC 日常方案落地、人力调度与交付由 POC 实施负责人拍板（A）；决定做/不做、选择产品线、需要追加算力或外包资源、截止日无法完成需缩减范围时升级研发负责人/CTO

7. 衡量指标

  • POC 准时交付率 = 截止日前交付的 POC / 全部 POC，目标 ≥ 90%
  • 截止日变更次数，每个 POC ≤ 1 次
  • POC 转化率 = 进入招投标或签约的 POC / 完成的 POC，按季度统计
  • 交付后返工轮次，目标 ≤ 2 轮

8. 低效诊断

  • 现象：客户演示后次周即催周期，截止日在群里反复变动约 3 次（客户确认环节缺书面记录）｜依据：「（某投资集团客户）poc」2026-08
  • 现象：谁接手、用哪条产品线边聊边定（立项评估缺模板）｜依据：「（某投资集团客户）poc」2026-08
  • 现象：项目负责人不明、配置问题反复问、测试报告无模板（启动清单缺失）｜依据：「某合作方-模态合作」2026-08
  • 现象：Demo 漏掉规则配置展示、不清楚此前给客户的版本、测试环境重启致录制中断（交付前缺需求对表与版本记录）｜依据：「（某车企客户）抢救」2026-09
  • 现象：演示前一晚通宵准备示例数据与账号（缺演示脚本与示例库）｜依据：「跃迁基座项目交付沟通」2026-01、2026-02

9. 分支变体

  • 云端/通用（LeapCore）与私有化（LeapBase+Skill，客户本地模型受限）按客户环境二选一
  • 外包团队参与：需先开代码库、脱敏数据与算力额度，明确我方项目负责人
  • 涉密/离线（国产系统）客户：彩排纯离线安装，请客户 IT 预装容器环境，材料不线上交接
  • 客户领导演示/验收：只演示稳定功能，提前入库示例文档，开冒烟账号，现场由客户代表验收
  • 需先签约盖章才启动的客户：先走 SAL-23

10. 待确认问题

  • POC 主责是否统一为 FDE Leader？纯演示类（非 POC）是否由销售主责？
  • 做不做 POC 的决策人与门槛（预算、竞争、转化可能性）是否需要成文？
  • POC 看板放在哪个空间，是否与 CRM 商机关联？
  • 测试报告模板与 AI 生成 Skill 是否已存在？
  • "交付前 2 个工作日完成开发"在两周 POC 中是否可行？
X-DLV-28客户培训与使用手册准备待优化120

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨5 × 险3

  • 适用场景：产品交付上线或阶段验收后，需要给客户（管理员/员工）做使用培训，并准备手册、视频、演示场景时启动
  • 负责人：主责——培训总负责人/产品总监（当前：杨萌·推断待确认）；协同——培训主讲/业务专家（当前：王满·推断待确认）、客户经理（当前：吴琪·推断待确认）、研发讲师（当前：杨云峰、岳阳·推断待确认）、文档站维护（当前：杨黔昆·推断待确认）、交付研发（当前：宋祺睿·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 与客户约培训（验收后） → ② 指定主讲与材料负责人 → ③ 研发内部培训交付人员 → ④ 准备手册/视频/演示场景 → ⑤ 彩排与流程跑通 → ⑥ 客户培训执行 → ⑦ 收集反馈并更新手册
  • 交付结果：分角色用户手册（管理员/员工）、操作讲解视频、培训演示脚本、培训签到与反馈记录
  • 状态依据：已有培训方案会议、帮助中心文档站雏形和功能演示文档，交付 SOP 中也写了现场培训五步；但 05～06 月手册负责人、视频由谁录反复商量，培训日期因 bug 和验收反复变化，管理层提出"企业培训流程该固化成 SOP"

1. 场景判定

  • 触发条件：客户验收通过或交付上线，需要组织全员/管理员培训；新版本发布后交付人员需要先学会再去培训客户
  • 典型说法：「手册给谁做你想好了吗」「约一个 1 小时培训教一下怎么用」「一个详细的演示操作讲解视频还是要有」「明天要能验收就周五培训」
  • 判断问题：培训对象是不是已签约/已交付的客户（或要去培训客户的内部交付/销售人员）？
  • 不归本流程管：渠道与销售的产品培训赋能 → 请走 SAL-29；FDE 课程与培训班 → 请走 X-FDE-16、X-FDE-17；客户试点驻场陪跑 → 请走 X-FDE-11；帮助中心日常维护 → 请走 X-CS-18

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
培训总负责人 定主讲与材料负责人、审核培训流程与材料 A 产品总监（当前：杨萌·推断待确认）
培训主讲 梳理培训流程、演示场景、现场讲解 R 业务专家/FDE（当前：王满·推断待确认）
客户经理 与客户约时间、确认对象与人数、收集反馈 R 销售总监/客户经理（当前：吴琪·推断待确认）
研发讲师 新版本内部培训、Agent 用法讲解、现场技术支持 R LeapCore 研发（当前：杨云峰、岳阳·推断待确认）
文档站维护 手册上线到帮助中心 R 产品/运营（当前：杨黔昆·推断待确认）
交付研发 培训环境稳定、账号准备 C 后端/发版（当前：宋祺睿·推断待确认）
研发负责人 版本冻结点与培训日期协调 C/兜底 Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 客户验收状态、培训日期候选、地点（现场/线上）、网络条件
  • 培训对象名单与人数，按管理员/普通用户分层
  • 培训使用的版本号（须为已冻结、已验收版本）与培训账号
  • 现有帮助中心文档、功能演示文档、历史培训录屏
  • 客户行业版本差异（工程咨询版/通用版）及重点场景

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 验收通过后与客户确认培训日期、对象、人数、形式，登记培训排期表 客户经理 验收通过后 2 个工作日内 飞书多维表格（培训排期） 培训排期 🔧飞书固化
2 指定主讲、手册负责人、视频负责人，写入排期表 培训总负责人 排期登记后 1 个工作日内 飞书任务 分工 👤人工判断
3 研发对主讲和交付人员做内部培训（版本须已冻结） 研发讲师 客户培训前 5 个工作日 飞书会议/日程 内部培训录屏 👤人工判断
4 编写分角色手册（飞书文档），AI 根据 PRD/更新日志出初稿 主讲；文档站维护 客户培训前 3 个工作日 飞书文档、帮助中心 用户手册 🔧+🤖
5 梳理培训流程与演示脚本，发培训总负责人审核 主讲 客户培训前 3 个工作日 演示脚本模板 培训流程 👤人工判断
6 用客户实际设备/staging 环境跑通全流程，录制操作讲解视频 主讲；交付研发 客户培训前 1 个工作日 录屏工具 视频、彩排记录 🤖自动化
7 执行培训：交付人员先演示 → 客户亲自操作 → 讲清异常提醒 → 现场答疑 主讲；研发讲师（现场支持） 培训当天 客户设备 签到表 👤人工判断
8 发放反馈问卷，问题转工单，手册与 FAQ 更新 客户经理；文档站维护 培训后 3 个工作日内 飞书问卷、工单 反馈记录、更新后手册 🔧飞书固化

5. 交付物与模板

  • 交付物：管理员手册、员工手册、操作讲解视频、演示脚本、签到表、反馈汇总
  • 建议模板/表单：
    • 培训排期表：客户代号｜验收状态｜培训日期｜形式｜对象分层｜人数｜主讲｜手册负责人｜视频负责人｜版本号｜状态
    • 用户手册结构：登录与账号｜核心功能操作｜常见问题｜注意事项（断电/断网等）｜求助渠道
    • 培训前检查清单：版本已冻结｜账号已开｜网络测速｜演示数据｜视频已录｜手册已发

6. 异常与升级

  • 培训前核心功能不稳定 → 主讲当天报研发负责人 → 决定修复或改期（培训前 2 个工作日内定）
  • 验收未通过 → 培训顺延，客户经理当天通知客户
  • 现场网络慢导致无法演示 → 切离线录屏 → 事后补线上答疑
  • 主讲/讲师无人认领 → 培训总负责人 1 个工作日内指定

7. 衡量指标

  • 培训准时率 = 按首次约定日期完成的培训 / 全部培训，目标 ≥ 80%
  • 材料齐备率 = 培训前 1 个工作日手册+视频+脚本均就绪的场次比例，目标 100%
  • 培训满意度 = 问卷平均分，目标 ≥ 4/5
  • 培训后 2 周内同类使用问题工单数，持续下降

8. 低效诊断

  • 现象：手册由谁做、网页帮助文档还是飞书文档在群里反复争论，培训临时推迟（分工环节缺指定）｜依据：「鼎慧产研决策部」2026-05
  • 现象：要求研发培训交付人员时新版本尚未开发完，讲师人选反复商量（版本冻结点未与培训日期联动）｜依据：「鸽子群模态分群」2026-05
  • 现象：培训前部分功能不稳定，视频录不录、何时录意见不一（缺培训前检查清单）｜依据：「LeapCore（archived）」2026-05
  • 现象：培训与验收日期因 bug 反复变化，大纲未定稿（验收与培训未串联）｜依据：「LeapCore（archived）」2026-05、2026-06

9. 分支变体

  • 管理员培训 / 员工全员培训 / 内部工程组培训分开准备材料
  • 现场培训、线上培训课、渠道培训：渠道培训按"产研先培训销售，销售再培训客户与渠道"执行
  • 工程咨询版与通用版手册分版本维护

10. 待确认问题

  • 培训总负责人是否确认为产品总监？培训主讲是否固定为业务专家/FDE？
  • 手册统一用飞书文档还是帮助中心文档站？两者如何同步？
  • "验收通过后才培训"是否作为硬规则？
  • 培训反馈问卷是否已有模板？
X-DLV-29交付签收单、验收单与开票跟进待优化240

状态：待优化｜证据：有证据（卡片 6 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：硬件或软件交付到客户后，需要用签收单/验收单/交接单取得客户书面确认、回收原件、上传系统，作为开票和回款依据时启动
  • 负责人：主责——硬件交付收口/部署工程师（当前：游家豪·推断待确认）；协同——IT 运维/发货（当前：杨明学·推断待确认）、客户经理/销售（当前：吴琪、常元和、闫登辉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、渠道系统负责人（当前：郭逸非·推断待确认）、市场销售负责人（当前：李鹏为·推断待确认）；兜底——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）
  • 核心流程：① 按合同取模板生成单据 → ② 随货寄送签收单 → ③ 客户签收盖章并回寄 → ④ 软件验收单签署 → ⑤ 核对原件 → ⑥ 上传渠道系统并通知财务 → ⑦ 财务按合同阶段开票 → ⑧ 纸质原件归档
  • 交付结果：客户签字盖章的签收单/验收单（电子版已上传渠道系统、纸质原件归档），以及据此开出的发票
  • 状态依据：已有服务器交付运维交接单模板，10 月渠道系统已支持验收单上传且开票以验收单回传为条件；但 05～09 月仍出现早期交付无签收单、模板分散、客户全称临时找人问、原件去向不明、"已开票还是未开票"口径不一

1. 场景判定

  • 触发条件：设备发货、现场交付完成、软件阶段验收、客户反馈"合同没开票"
  • 典型说法：「硬件交付前做一个签收单」「我们要做标准的签收单和验收单，不然扯皮会特别多」「随第二台一起发签收单」「验收单拿到后走渠道系统流程上传」
  • 判断问题：这次交付是否需要客户书面确认，才能开票、起算质保或证明已交付？
  • 不归本流程管：开票申请与红冲操作 → 请走 FIN-19；软硬一体分税率开票 → 请走 FIN-20；回款跟进与收入确认 → 请走 FIN-21；对外寄件与快递月结 → 请走 ADM-16；合同原件归档 → 请走 LEG-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
硬件交付收口 生成单据、跟踪签收、核对原件、上传系统、归档 A/R 部署工程师（当前：游家豪·推断待确认）
发货 发货并随货附签收单，录物流单号 R IT 运维（当前：杨明学·推断待确认）
客户经理/销售 提供客户全称与合同阶段、推动客户盖章、核对开票阶段 R 客户经理/销售（当前：吴琪、常元和、闫登辉·推断待确认）
财务 依据验收单与合同阶段开票、对账 R 财务负责人（当前：黄梦婷·推断待确认）
渠道系统 维护验收单上传功能与开票条件校验 C 渠道系统负责人（当前：郭逸非·推断待确认）
销售负责人 签收/验收规则制定；客户超期不回签时推动 A（升级） 市场销售负责人（当前：李鹏为·推断待确认）
交付统筹 模板入交付知识库、单据口径维护 C 产品总监/交付 SOP 统筹（当前：杨萌·推断待确认）

3. 办之前请准备

  • 合同编号、客户公司全称（以合同为准）、交付清单（型号、数量、序列号）
  • 合同付款/开票阶段（全款/预付款/分期）
  • 签收单、验收单、质保函、交接单最新模板（交付知识库）
  • 收件人、地址、电话（客户提供）
  • 软件交付范围（账号、培训项）是否需并入交接单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 从交付知识库取模板，客户全称从合同自动带入，生成签收单/验收单（一单多台按实际台数） 硬件交付收口 发货前 1 个工作日 交付知识库、渠道系统 待签单据 🔧+🤖
2 打印单据随货寄出，物流单号录入交付订单表 发货 发货当天 快递月结、多维表格 物流记录 🔧飞书固化
3 现场交付时当场签字盖章；邮寄交付则请客户签收后 3 个工作日内回寄 客户经理/销售 到货后 3 个工作日内 — 已签单据 👤人工判断
4 软件部署调试完成后签软件验收单（阶段验收），与硬件签收单分别留存 客户经理/销售；硬件交付收口 验收通过当天 验收单模板 软件验收单 👤人工判断
5 核对签收/验收单：全称、台数、序列号、盖章、日期 硬件交付收口 收到后 1 个工作日内 — 核对结果 👤人工判断
6 上传扫描件到渠道系统订单（支持 PDF/Word），系统机器人通知财务 硬件交付收口 核对通过当天 渠道系统、飞书机器人 上传记录 🔧+🤖
7 按合同阶段开票，与销售确认本次为第几期 财务 收到通知后 2 个工作日内 开票系统 发票 👤人工判断
8 纸质原件交档案管理归档，交付订单表状态改为"已验收" 硬件交付收口 收到原件后 3 个工作日内 档案柜、多维表格 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：签收单、验收单、质保函、交接单（扫描件 + 纸质原件）、发票
  • 建议模板/表单：
    • 交付单据包（合并）：合同编号｜客户全称｜交付日期｜设备型号/数量/序列号｜软件版本｜账号与培训项｜质保起算日｜客户签字盖章
    • 交付订单表字段：签收单状态｜验收单状态｜物流单号｜原件位置｜开票阶段｜开票状态

6. 异常与升级

  • 已交付但无签收单 → 1 个工作日内补发单据请客户补签 → 超 5 个工作日未回升级市场销售负责人
  • 客户交付期间持续提新需求导致验收卡住 → 区分合同内/外需求（合同外走 SAL-25）→ 客户经理与研发负责人确定验收边界（2 个工作日内）
  • 预付款订单验收单晚到 → 按合同规则先开预付款部分发票，尾款待验收单
  • 客户反馈"未开票" → 销售核对合同阶段与财务记录 → 1 个工作日内答复客户
  • A（升级）说明：单据生成、核对、上传与归档由硬件交付收口（部署工程师）负责到底（A）；客户超 5 个工作日未回签、签收/验收规则需调整时升级市场销售负责人

7. 衡量指标

  • 签收单回收率 = 已回收签收单的交付批次 / 全部交付批次，目标 100%
  • 验收单回传周期 = 交付完成到验收单上传系统的自然日，目标 ≤ 10 天
  • 开票及时率 = 验收单上传后 2 个工作日内开票的比例，目标 ≥ 95%

8. 低效诊断

  • 现象：交接单签署日期因软件调试拖延多次改期，现场谁走签字流程临时确认（硬件与软件验收节点未拆分）｜依据：「LeapCore（archived）」2026-05
  • 现象：签收单只写一台需重发两台的单子，原件在谁手上、谁打印不清（缺单据核对与原件登记）｜依据：「Leapcore（某燃气客户）」2026-08、2026-09
  • 现象：销售"不知道签收单长啥样"，已开票/未开票说法不一（模板分散、开票阶段不透明）｜依据：「财务部」2026-08、「（某人才服务客户）硬件交付群」2026-07
  • 现象：系统未支持上传时验收单靠飞书转发财务（系统功能滞后于流程）｜依据：「渠道系统优化」2026-08、2026-09
  • 现象：客户在交付/验收期持续提需求，转述与客户原意不一致，验收迟迟未过（缺需求台账与验收清单）｜依据：「鼎慧产研决策部」2026-05、2026-06

9. 分支变体

  • 硬件签收（到货即签）与软件验收（阶段验收后才开展全员培训）分开签署
  • 试用机与正式交付：试用机只签借用/签收单，不触发开票
  • 全款/预付款/分期开票：按合同阶段对应单据
  • 纸质签收与电子签：电子签需法务评估后启用

10. 待确认问题

  • 签收单/验收单统一由硬件交付收口岗负责，还是由客户经理负责推动客户盖章？
  • 合并后的"交付单据包"模板由谁定稿？是否需法务审阅质保条款？
  • 是否启用电子签？
  • 纸质原件归档到行政档案还是交付侧保管？
  • 客户 3 个工作日内回寄的要求是否现实？
X-DLV-30交付服务承诺口径（保修、运维边界、客户须知）待新建80

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频2 × 耗2 × 跨5 × 险4

  • 适用场景：硬件随软件销售或批量出货前，需要统一保修时长、运维主体与远程售后边界、客户侧注意事项与免责声明时启动；或发生客户误操作导致离线等责任争议后需要补口径时启动
  • 负责人：主责——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）；协同——客户经理（当前：吴琪·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、研发（当前：杨云峰、王皓南、宋祺睿·推断待确认）、销售与渠道（当前：李鹏为、闫登辉、常元和·推断待确认）、法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 收集待决问题 → ② 对齐厂商保修信息 → ③ 开会定运维主体与售后边界 → ④ 起草客户须知与免责声明 → ⑤ 法务审阅 → ⑥ 发布并写入合同/交付单据 → ⑦ 交付时签署并贴机身标签
  • 交付结果：《交付服务承诺口径》一页纸（保修时长、运维主体、远程售后范围、收费情形）、《客户使用须知与免责声明》（交付时客户签署）、机身标签/二维码
  • 状态依据：04～06 月多次讨论保修是否需与厂商对齐、运维由谁负责、客户须知如何收口，两次要求整理客户注意事项但未见成文，客户误关机/换网导致离线的同类问题再次发生

1. 场景判定

  • 触发条件：新硬件产品或打包方案上市；批量出货前；客户问保修与售后；客户误断电、换网线、换网络导致机器离线引发责任争议
  • 典型说法：「不是得我们对外提供保修时长和厂商的对齐吗」「简单留给用户，复杂留给自己」「压货是渠道负责的」「别断电、别换网、别断网、别按任何按钮」
  • 判断问题：是否涉及"我们对客户承诺什么、不承诺什么"？
  • 不归本流程管：具体硬件故障返修与上门维保 → 请走 X-CS-12；合同条款谈判 → 请走 SAL-23；用户协议/EULA 文案 → 请走 LEG-18；定制客户特殊配置的售后范围 → 请走 X-CS-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付 SOP 统筹 收集待决问题、组织决策会、发布口径 A/R 产品总监（当前：杨萌·推断待确认）
客户经理 起草客户须知、安装时同步客户管理员 R 销售总监/客户经理（当前：吴琪·推断待确认）
IT 运维/硬件 厂商保修信息、硬件风险项、参考市面做法 R IT 运维（当前：杨明学·推断待确认）
研发 列软件侧注意事项、备份恢复与磁盘监控等能力说明 C LeapCore 研发（当前：杨云峰、王皓南、宋祺睿·推断待确认）
销售与渠道 渠道运维与压货分工、对客户口径 C 销售/渠道负责人（当前：李鹏为、闫登辉、常元和·推断待确认）
法务 审阅保修条款与免责话术 C 法务负责人（当前：李瑶·推断待确认）
研发负责人/CTO 关键边界拍板 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
交付人员 交付时请客户管理员签署须知、贴标签 R 部署工程师（当前：游家豪·推断待确认）

3. 办之前请准备

  • 各硬件型号的厂商保修条款（时长、范围、送修方式）
  • 销售模式：直销/渠道/集成商，渠道协议中运维与压货条款
  • 产品能力现状：远程售后、备份恢复、硬盘监控、智能节电启停
  • 已发生的客户误操作与售后争议案例
  • 现行合同模板中的保修与服务条款

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 汇总待决问题清单（保修、运维主体、磁盘管理开放、远程售后、交付方式等） 交付 SOP 统筹 出货计划确定后 2 个工作日内 飞书文档 问题清单 🔧飞书固化
2 整理厂商保修信息表，对齐对外保修时长 IT 运维 1 周内 多维表格 保修信息表 🔧飞书固化
3 召开决策会，逐条定结论与负责人，会议纪要用妙记生成 交付 SOP 统筹；研发负责人 问题清单完成后 1 周内 飞书会议、妙记 决策纪要 🔧+🤖
4 研发列软件侧注意事项，客户经理汇总成《客户使用须知与免责声明》草稿 研发；客户经理 决策会后 3 个工作日内 飞书文档 须知草稿 🤖自动化
5 法务审阅保修条款与免责话术 法务 收到后 3 个工作日内 飞书文档评论 审定稿 👤人工判断
6 发布口径一页纸，同步销售/渠道/售后；更新合同模板与交付单据包 交付 SOP 统筹 审定后 2 个工作日内 交付知识库 发布版本 🔧飞书固化
7 交付时由客户管理员签署须知，机身贴标签/二维码 交付人员 每次交付当天 交付单据包 签署记录 👤人工判断
8 新争议发生后 5 个工作日内评估是否修订口径 交付 SOP 统筹 争议后 5 个工作日内 — 修订记录 👤人工判断

5. 交付物与模板

  • 交付物：服务承诺口径一页纸、客户使用须知与免责声明、厂商保修信息表、机身标签
  • 建议模板/表单：
    • 服务承诺口径：产品/型号｜保修时长与范围｜保修责任方（厂商/渠道/我方）｜运维主体｜远程售后范围｜收费情形｜生效日期
    • 客户使用须知：供电与关机｜网络与网线｜智能节电启停说明｜磁盘与数据｜禁止操作｜违规操作后果与收费｜求助渠道｜客户签字
    • 厂商保修信息表：型号｜厂商｜保修时长｜送修方式｜联系人渠道

6. 异常与升级

  • 客户因误操作导致故障要求免费处理 → 售后依据客户使用须知判定 → 有争议报交付统筹（产品总监，1 个工作日内），涉及收费报销售负责人
  • 渠道与我方运维分工争议 → 按渠道协议 → 报研发负责人与销售负责人决策（3 个工作日内）
  • 厂商保修条款变化 → IT 运维更新信息表 → 交付 SOP 统筹评估是否改口径
  • A（升级）说明：口径收集、决策会组织与发布由交付 SOP 统筹拍板（A）；保修时长、运维主体、远程售后范围等关键边界在决策会上无法达成一致，或渠道与我方运维分工争议时升级研发负责人/CTO

7. 衡量指标

  • 须知签署覆盖率 = 签署须知的交付台数 / 全部交付台数，目标 100%
  • 因客户误操作引发的售后争议次数，按季度统计并持续下降
  • 口径更新时效 = 争议发生到口径修订发布的工作日，目标 ≤ 10 个工作日

8. 低效诊断

  • 现象：对外保修是否需与厂商对齐存在分歧，未形成口径（缺保修信息表与决策人）｜依据：「鼎慧产研决策部」2026-04
  • 现象：批量出货前待决问题被供应商会议带偏，大半内容与实际情况对不上（缺决策清单与纪要）｜依据：「LeapCore（archived）」2026-06
  • 现象：要求统一收口客户注意事项两次仍未见成文，同类离线问题再次发生（产出物无负责人与截止日）｜依据：「LeapCore（archived）」2026-05、2026-06

9. 分支变体

  • 直销与渠道销售：渠道负责压货与一线运维，我方只提供技术支持
  • 开箱即用与 OOBE：OOBE 模式须在引导页展示须知
  • 是否向客户开放部分磁盘管理：默认"简单留给用户，复杂留给自己"，开放项需研发负责人确认
  • 软件强制项：备份恢复与硬盘状态上传默认启用，写入须知

10. 待确认问题

  • 主责是否确认为交付 SOP 统筹？客户须知是否由客户经理执笔？
  • 对外保修时长是否与厂商一致，或我方另设统一时长？
  • 违规操作收费标准由谁定？
  • 法务审阅由谁承接？
  • 须知是作为交付单据包一页随签，还是写入合同附件？
X-DLV-31已交付设备与客户信息登记归档待优化192

状态：待优化｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：每交付一台 LeapCore 或项目交付完成后，登记设备与客户的唯一信息源（指纹、渠道、客户全称、版本、管理员地址、Skill 下发），归档客户材料与验收单，并在客户反馈问题时据此定位设备与交付人
  • 负责人：主责——部署工程师/设备登记（当前：游家豪·推断待确认）；协同——交付 SOP 统筹（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）、企业更新与设备指纹（当前：宋祺睿、杨云峰·推断待确认）、模型网关与计费（当前：柯逸飞·推断待确认）、IT/硬件交付（当前：杨明学·推断待确认）、销售（当前：吴琪、杨朋伟·推断待确认）；兜底——产品总监/交付 SOP 统筹（当前：杨萌·推断待确认）
  • 核心流程：① 成单写入交付订单表 → ② 部署后登记设备（指纹、版本、IP、渠道） → ③ 行业版到开放平台登记 → ④ 补管理员地址等交付信息并同步客户 → ⑤ 上传验收单与材料 → ⑥ 订单—设备关联校验 → ⑦ 定期核对与离线跟进
  • 交付结果：一张以设备 ID 为主键、与交付订单关联的"已部署设备台账"（唯一信息源），以及按项目归档的客户交付材料
  • 状态依据：已有"交付订单"多维表格、已部署产品清单和交付 SOP 文档；但 07～10 月信息仍分散在渠道系统、企业更新、开放平台、交付表等多处，关联字段缺失、客户全称不统一，出现客户反馈问题时清单里查不到这家公司

1. 场景判定

  • 触发条件：交付完成一台设备或一个项目；行业版需开放平台下发 Skill；客户反馈问题需确认设备归属；迁移/升级前需统计真实客户与实例
  • 典型说法：「所有卖出去的 LeapCore 信息，要有唯一来源」「登记在哪个公司名下？谁交付的」「在哪能找到一个所有真实客户的列表」「只要他这辈子有可能用得到，就要记下来」
  • 判断问题：这台设备/这个客户的信息是否已在唯一台账里且字段完整？
  • 不归本流程管：出厂前设备指纹注册 → 请走 X-DLV-14；客户私有化实例在线监控告警 → 请走 X-CS-04；硬件库存与资产台账 → 请走 X-DLV-03；签收单/验收单获取 → 请走 X-DLV-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
设备登记 交付后填写台账、上传验收单、同步客户 R 部署工程师（当前：游家豪·推断待确认）
交付 SOP 统筹 定义台账字段与规则、兜底 A 产品总监（当前：杨萌·推断待确认）
研发负责人 校验订单—设备—实例关联、推动系统读写唯一源 C Leap 研发负责人（当前：王皓南·推断待确认）
开放平台 行业版设备登记与 Skill 下发 R 开放平台负责人（当前：郭逸非·推断待确认）
企业更新/设备指纹 提供指纹、版本、IP、在线状态 C 后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）
计费对账 校验机器注册名与合同全称一致 C 模型网关与计费研发（当前：柯逸飞·推断待确认）
硬件交付 提供序列号、出库信息 C IT 运维（当前：杨明学·推断待确认）
销售 提供客户全称、联系人、送测/成交性质 C 销售（当前：吴琪、杨朋伟·推断待确认）

3. 办之前请准备

  • 合同或订单编号、客户公司全称（与合同一致）、客户联系人
  • 设备序列号、设备指纹/实例 ID、产品版本与更新渠道
  • 设备 IP、远程接入配置、所属网络环境
  • 版本类型：标品/行业版（需下发的 Skill 清单）
  • 管理员面板地址、企业地址（账号凭据只记存放位置，不明文写入表格）
  • 验收单扫描件

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 成单后在交付订单表建记录（"卖一台建一条"），客户全称从合同带入 销售 合同签订后 1 个工作日内 渠道系统 → 多维表格 订单记录 🔧+🤖
2 部署完成后登记设备：指纹、序列号、版本、渠道、IP、关联订单 设备登记 部署当天 已部署设备台账 设备记录 🔧飞书固化
3 行业版：提交开放平台登记，确认 Skill 自动下发；标品跳过 设备登记 → 开放平台 部署当天 开放平台 下发确认 🔧+🤖
4 机器注册名统一为合同公司全称，计费侧校验一致 设备登记；计费对账 部署当天 NewAPI/注册平台 校验结果 🤖自动化
5 补填管理员面板地址、企业地址，并书面同步给客户管理员 设备登记 交付后 1 个工作日内 台账、交付群 客户确认 👤人工判断
6 上传验收单附件，项目材料放云盘标准目录 设备登记 拿到验收单后 1 个工作日内 多维表格附件、飞书云盘 归档 🔧飞书固化
7 每周自动比对台账与后台在线实例，标出未登记、字段缺失、关联为空的记录并派单 研发负责人（规则）；机器人 每周一 多维表格自动化、机器人 异常清单 🤖自动化
8 离线超过 7 天的客户设备推送给客户经理跟进原因 机器人 → 销售 触发后 2 个工作日内 心跳同步、机器人 跟进记录 🔧+🤖

5. 交付物与模板

  • 交付物：已部署设备台账（唯一信息源）、交付订单表关联、项目归档目录
  • 建议模板/表单：
    • 设备台账字段：设备 ID/指纹｜序列号｜客户全称｜性质（成交/送测/渠道/内部）｜渠道｜关联订单｜产品版本｜更新渠道｜版本类型（标品/行业版）｜下发 Skill｜IP/接入方式｜管理员面板地址｜企业地址｜凭据存放位置｜交付人｜交付日期｜验收单附件｜在线状态｜最后在线时间
    • 项目归档目录：合同/订单｜交付单据｜部署记录｜客户材料｜培训资料｜往来纪要

6. 异常与升级

  • 客户反馈问题但台账查无此设备 → 售后当天在交付群追问销售与交付人并补登 → 超 1 个工作日未查明报交付 SOP 统筹
  • 注册名与合同全称不一致 → 计费侧当天提示 → 设备登记 1 个工作日内修正
  • 行业版登记后 Skill 未下发 → 开放平台 1 个工作日内处理 → 升级研发负责人
  • 客户设备长期离线 → 客户经理联系客户 → 无回应报交付 SOP 统筹

7. 衡量指标

  • 台账完整率 = 必填字段齐全且已关联订单的设备 / 全部已交付设备，目标 ≥ 98%
  • 登记时效 = 部署完成到台账登记的小时数，目标 ≤ 24 小时
  • 台账与后台实例一致率，目标 100%
  • 客户反馈时"查不到设备"次数，目标 0

8. 低效诊断

  • 现象：已售设备信息分散多处各自维护，行业版每卖一台要手动去开放平台登记并人工通知（缺唯一信息源与系统读写约定）｜依据：「鼎慧产研决策部」2026-07
  • 现象：为迁移临时导出实例表，客户全称/渠道不统一，数据噪音大，限期当晚确认（缺持续维护的台账）｜依据：「Leap产研测」2026-08
  • 现象：设备离线二十多天无人感知（缺心跳同步与离线提醒）｜依据：「Leap产研测」2026-08
  • 现象：客户反馈问题时已部署清单里没有这家公司，不知道谁交付、配置在哪（送测设备未登记）｜依据：「Leap反馈群」2026-08、2026-10
  • 现象：交付订单与已部署清单关联字段为空，机器注册名与合同公司名对不上（缺强制关联与命名校验）｜依据：「交付订单通知群」2026-07、2026-10
  • 现象：交付材料归档"其实没人负责"（归档责任未指定）｜依据：「鼎慧产研决策部」2026-06

9. 分支变体

  • 标品：不需开放平台登记，字段不全时默认按标品处理
  • 行业版：多一步开放平台登记，登记后自动下发 Skill；组合行业版尚未销售，出现时按行业版逐项登记
  • 设备性质：成交设备 / 公司送测设备 / 渠道设备 / 研发与市场自用设备，均需登记，性质字段区分
  • 软件交付项目（无硬件）：以实例 ID 为主键登记

10. 待确认问题

  • 唯一信息源用多维表格还是工单系统？渠道系统、开放平台、企业更新、NewAPI 是否都改为从它读取？
  • 设备登记主责是否确认为部署工程师？送测设备由谁负责登记？
  • 管理员地址等交付信息是否全部记录？凭据存放在哪里、谁可见？
  • 离线提醒阈值 7 天是否合适？
  • 归档责任人与云盘目录规范是否由交付 SOP 统筹指定？
X-DLV-32已交付/演示机版本升级与回退待新建108

状态：待新建｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：新版本发布后要给客户机、演示机、伙伴机推送更新，或次日要交付/演示需确认机器已在可用版本上，并在升级失败时回退
  • 负责人：主责——发版/运维（当前：宋祺睿·推断待确认）；协同——部署研发（当前：杨云峰·推断待确认）、部署工程师/现场（当前：游家豪·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）；兜底——Leap 研发负责人（当前：王皓南·推断待确认）
  • 核心流程：① 确定升级范围与优先级 → ② 预检（在线、环境变量、磁盘、依赖） → ③ 分批推送 → ④ 探测验证 → ⑤ 失败回退 → ⑥ 修复后重推 → ⑦ 更新升级状态表
  • 交付结果：目标机器全部处于可用版本（或已回退到上一稳定版本），升级状态表记录每台机器的版本、结果与遗留问题
  • 状态依据：已有后台控制台、LeapUpdate、canary 渠道与部署 Skill，但无预检与回退规范；09 月交付前夜才发现 3 台机器部分升级失败（环境变量未配置、init 容器退出），靠手动回退热修；更新依赖个人人工推送

1. 场景判定

  • 触发条件：正式版发布后需推送已交付机器；次日有交付、演示、现场培训；外部伙伴机器请求升级；机器 IP/网络变更后需重新下发配置
  • 典型说法：「明天交付那几台更新了没」「最好 6 点后一直通电，等更新后验证没问题再打包」「先热修那 3 台，保证明天能演示」「推了，等两分钟生效」
  • 判断问题：要升级的是否为已出厂/已交付/演示用的实机，而非研发测试环境？
  • 不归本流程管：正式版本发布上线 → 请走 RND-51；测试环境部署更新 → 请走 RND-49；客户端安装与更新问题一线支持 → 请走 X-CS-07；版本更新的客户通知 → 请走 X-CS-15；演示前版本冻结 → 请走 RND-61

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发版/运维 查在线状态、推送更新、汇总结果、修复后重推 A/R 后端/发版运维（当前：宋祺睿·推断待确认）
部署研发 预检脚本、回退镜像、IP/配置重新下发 R LeapCore 部署研发（当前：杨云峰·推断待确认）
现场 机器通电联网、登录探测、现场验证 R 部署工程师（当前：游家豪·推断待确认）
交付统筹 提供次日交付/演示机清单、提醒提前通电 C 产品总监/交付 SOP 统筹（当前：杨萌·推断待确认）
研发负责人 定优先级、决定热修、重装或改期 A（升级） Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 目标机器清单（来自 X-DLV-31 设备台账）：设备 ID、客户/用途、当前版本、更新渠道、在线状态
  • 目标版本号、更新日志、所需新增环境变量/配置项
  • 上一稳定版本镜像与回退脚本
  • 次日交付/演示时间表与机器对应关系
  • 离线机器的远程接入方式或离线 ISO/U 盘

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 列出本次升级机器与优先级（次日交付/演示 > 客户机 > 伙伴机 > 内部机） 发版/运维；交付统筹 发版当天或交付前 1 个工作日 12:00 前 设备台账 升级清单 🔧飞书固化
2 通知现场将交付/演示机通电联网，保持至验证完成 交付统筹 → 现场 交付前 1 个工作日 18:00 前 飞书机器人提醒 在线机器 🔧+🤖
3 运行预检：在线、磁盘、依赖、新增环境变量/配置是否齐全 部署研发 推送前 预检脚本/部署 Skill 预检报告 🤖自动化
4 先推 1 台金丝雀机器，验证通过再批量推送 发版/运维 预检通过后 后台控制台、LeapUpdate 推送记录 🔧+👤
5 探测各机器升级结果与核心业务可用性 现场；发版/运维 推送后 30 分钟内 探测 Skill 探测结果 🤖自动化
6 失败或部分升级的机器立即回退上一稳定镜像，交付/演示机须在当天 18:00 前恢复可用 部署研发 发现后 1 小时内 回退脚本 回退记录 🔧+🤖
7 定位并修复后重推，复验通过后标记"OK" 发版/运维 交付/演示前 后台控制台 复验结果 👤人工判断
8 更新升级状态表：版本、结果、离线/需补配置/需远程机器及跟进人 发版/运维 当天 升级状态表 状态表 🔧飞书固化

5. 交付物与模板

  • 交付物：升级清单、预检报告、升级状态表、回退记录
  • 建议模板/表单：
    • 升级状态表：设备 ID｜客户/用途｜优先级｜当前版本｜目标版本｜在线｜预检结果｜推送时间｜结果（成功/部分/失败/回退）｜遗留问题｜跟进人
    • 预检清单：在线与网络｜磁盘空间｜必需环境变量与配置项｜依赖服务｜容器状态｜回退镜像就绪

6. 异常与升级

  • 机器不在线无法推送 → 通知现场或客户通电联网 → 交付/演示前仍不在线报研发负责人决定远程处理或带离线包上门
  • 升级失败且回退也失败 → 当天报研发负责人 → 决定重装（ISO）或改期，交付统筹通知客户（交付前 12 小时内）
  • 外部伙伴网络/IP 变化需重新下发配置 → 部署研发 1 个工作日内处理，并推动自动化
  • 过渡版本引入新问题 → 暂停批量推送，交付前 24 小时冻结版本
  • A（升级）说明：推送、回退与重推由发版/运维拍板执行（A）；机器交付/演示前仍不在线、升级与回退均失败需重装或改期、多台机器争优先级时升级 Leap 研发负责人

7. 衡量指标

  • 升级一次成功率 = 一次推送即成功的机器 / 推送机器，目标 ≥ 95%
  • 交付/演示前就绪率 = 交付/演示前 1 个工作日 18:00 前已验证可用的机器比例，目标 100%
  • 回退时长 = 发现失败到恢复可用的分钟数，目标 ≤ 60 分钟
  • 人工推送占比，持续下降

8. 低效诊断

  • 现象：交付前夜才发现部分机器升级失败、业务不完整，需连夜热修回退（缺预检与交付前冻结）｜依据：「Leap产研测」2026-09
  • 现象：机器账号信息靠私下发送、逐台人工检查（缺状态登记表与统一接入方式）｜依据：「Leap产研测」2026-09
  • 现象：机器不在线无法更新，伙伴办公网络变化需多次重新下发配置（缺离线告警与配置自动下发）｜依据：「交付订单通知群」2026-07、2026-09
  • 现象：更新完全依赖单人手动推送（缺更新 Skill 与自动化）｜依据：「交付订单通知群」2026-07

9. 分支变体

  • 客户机器 / 演示机 / 外部伙伴机器 / 内部自用机：按优先级排序，演示机与次日交付机优先
  • 联网机器走在线推送；离线机器用 ISO/U 盘离线升级，需提前备足介质
  • 内网测试机与客户机：内网机先行验证作为金丝雀

10. 待确认问题

  • 主责是否确认为发版运维岗？是否需要 AB 角避免单点？
  • "交付前 24 小时冻结版本"是否可执行？
  • 预检脚本与回退脚本由谁维护？是否纳入部署 Skill？
  • 外部伙伴机器的升级是否由我方负责，还是交给伙伴自助？
X-DLV-33已交付客户扩容与加席位变更待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：已交付 LeapCore 一体机/系统的客户要求加席位、多开账号、升级扩容或自行加装内存，或内部核对发现客户系统席位与合同/席位表不一致时启动
  • 负责人：主责——交付统筹（当前：杨萌·推断待确认）；协同——LeapCore 部署/后端工程师（当前：杨云峰·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、IT 运维/硬件负责人（当前：杨明学·推断待确认）、Leap 研发技术负责人（当前：王皓南·推断待确认）、后端/运维发版（当前：宋祺睿·推断待确认）、销售（当前：吴琪、李鹏为·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 受理变更申请 → ② 核对合同席位与硬件规格 → ③ 按政策判定（是否允许/席位上限/是否收费）→ ④ 审批 → ⑤ 远程改席位或返厂扩容 → ⑥ 通知客户并验证 → ⑦ 登记席位台账
  • 交付结果：已生效且与合同一致的席位配置、更新后的席位台账记录、客户确认记录（收费时附补充合同/订单）
  • 状态依据：08～10 月在客户项目群、销售通知群、产研决策群反复讨论“能否自加内存”“席位上限多少”“谁拍板”，规则停留在口头；10 月发现出厂默认席位无人核对，需批量 hotfix 修正，缺“签约席位→系统配置”固定核对流程和成文硬件改动政策

1. 场景判定

  • 触发条件：客户要求加席位/多开账号；客户询问升级机型、加硬盘、加内存；客户已自行改硬件后要求同步席位；席位表与系统实际值核对出差异
  • 典型说法：「我们要不要允许他自己加」「他们想多开几个账号，这一台能支持吗？」「龙智不支持外接硬盘等所有方式扩容」「直接按表格改」
  • 判断问题：客户是否已交付在用？变更对象是席位/账号数、硬件配置，还是两者都有？是否改变合同金额？
  • 不归本流程管：新购设备选型与报价 → 请走 X-DLV-01；云端试用/正式账号开通与席位扩容 → 请走 X-CS-02；硬件故障返修 → 请走 X-CS-12；额度充值 → 请走 X-DLV-15；版本升级/回退 → 请走 X-DLV-32

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付统筹 受理、核对、组织判定、跟到生效 A 交付统筹（当前：杨萌·推断待确认）
交付部署工程师 填申请、通知客户、更新台账 R 交付部署工程师（当前：游家豪·推断待确认）
LeapCore 部署/后端工程师 远程执行席位变更 R LeapCore 部署/后端工程师（当前：杨云峰·推断待确认）
研发技术负责人 评估席位上限与技术限制 C Leap 研发技术负责人（当前：王皓南·推断待确认）
IT 运维/硬件负责人 硬件改动政策、返厂扩容 C/R IT 运维/硬件负责人（当前：杨明学·推断待确认）
后端/运维发版 批量修正时推送更新 R 后端/运维发版（当前：宋祺睿·推断待确认）
销售 对接客户诉求、收费与补充合同 R 销售（当前：吴琪、李鹏为·推断待确认）
财务 收费变更的开票与回款确认 C 财务（当前：待指定）
研发负责人 超上限、让利、口径分歧拍板 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户主体、合同编号、合同约定席位数
  • 设备型号（龙智/源核/震宇）、设备指纹或序列号、当前内存/硬盘规格
  • 硬件来源：公司售出 / 客户自购 / 渠道自有
  • 系统当前实际席位数（控制台截图）
  • 客户诉求：目标席位数或目标配置、期望生效时间
  • 客户是否已自行改动硬件（改动时间、配件规格）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到客户诉求，按准备清单提交席位变更申请 销售/交付部署工程师 收到诉求当天 飞书审批（席位变更） 变更申请单 🔧飞书固化
2 核对合同席位、席位台账与系统实际值，标出差异 交付统筹 申请后 1 个工作日内 席位台账（多维表格）、控制台 核对结果 🔧+🤖
3 查型号×内存的席位上限表判定可行性；硬件改动按政策：公司售出硬件不允许客户自改，只能寄回返厂；客户自购硬件可自改但须报规格 研发技术负责人、IT 运维/硬件负责人 申请后 1 个工作日内 席位上限表 可行性结论、建议席位数 🤖+👤
4 确定是否收费、价格与是否让利；超上限或让利报研发负责人 销售、交付统筹 判定后 1 个工作日内 飞书审批 审批结论 👤人工判断
5 收费的补签补充合同/订单，确认回款节点 销售、财务 审批通过后 2 个工作日内 合同/CRM 补充合同或订单 🔧飞书固化
6 执行变更：远程改席位；硬件扩容安排返厂 LeapCore 部署/后端工程师；IT 运维 审批通过（收费的确认回款）后 1 个工作日内 控制台、更新推送 变更记录 🔧+🤖
7 通知客户生效，请客户验证账号数可用 交付部署工程师 变更完成当天 客户群 客户确认 👤人工判断
8 更新席位台账（原值、新值、硬件规格、费用、审批号、执行时间） 交付部署工程师 变更完成当天 多维表格 台账记录 🔧飞书固化

5. 交付物与模板

  • 交付物：席位变更审批单、更新后的席位台账、客户确认记录、（收费时）补充合同/订单
  • 建议模板/表单：席位变更申请——客户、主体、合同编号、设备型号、硬件来源、当前规格、合同席位、系统实际席位、目标席位、是否改硬件、是否收费、金额、让利说明、审批人、执行人、生效时间
  • 席位上限表：型号、内存规格、席位上限、建议值、评估人、更新日期

6. 异常与升级

  • 客户已自行改动公司售出硬件 → 告知不在保修范围，暂不调席位 → 交付统筹 1 个工作日内报研发负责人
  • 申请席位超过规格上限 → 不执行，说明内存不足导致机器卡死的风险 → 客户坚持的报研发负责人（1 个工作日内）
  • 台账与系统不一致且涉及少收费/多开席位 → 冻结该客户变更 → 交付统筹当天报研发负责人与财务，按“批量修正”分支处理
  • 是否通知客户、话术有分歧 → 交付统筹定口径，涉及收入的当天报研发负责人拍板
  • 渠道商要求自改硬件 → 收费规则未定，逐单报研发负责人与销售负责人（2 个工作日内）
  • A（升级）说明：扩容/加席位的受理、核对与执行由交付统筹拍板（A）；申请超规格上限、客户自改硬件、涉及让利或少收费、是否通知客户涉及收入、渠道商自改硬件收费时升级研发负责人

7. 衡量指标

  • 席位变更周期：申请提交到客户确认生效的工作日，目标 ≤ 3 个工作日（返厂除外）
  • 席位一致率：系统席位与合同/台账一致的客户数 ÷ 已交付客户数，每月核对，目标 100%
  • 无审批变更数：未走审批直接改席位的次数，目标 0
  • 超上限导致的机器故障数，目标 0

8. 低效诊断

  • 现象：缺成文硬件改动政策，“是否允许客户自加内存”隔数周重复讨论，同一客户两次改配置｜依据：「某芯片科技客户项目群」2026-08、「某芯片科技客户项目群」2026-09
  • 现象：席位数量由谁拍板不清，群内同意未被执行人看到；先改硬件还是先改席位口径不一｜依据：「某芯片科技客户项目群」2026-08
  • 现象：客户先改硬件再告知，流程事后补｜依据：「某芯片科技客户项目群」2026-09
  • 现象：多开账号需求从项目群零散提出，没有统一受理入口｜依据：「某区政府客户项目群」2026-08
  • 现象：扩容范围需反复对客说明；多规格版本受采购与管理体系限制无法提供｜依据：「Leap市场销售通知群」2026-09
  • 现象：出厂默认席位无人核对，事后批量修正，是否通知客户内部有分歧｜依据：「Leap产研决策部」2026-10

9. 分支变体

  • 公司售出硬件：默认不允许客户自改，扩容只能寄回返厂；龙智款不支持外接硬盘等任何方式扩容，需升级机型或迁移新机并加价
  • 客户自购硬件：允许客户自改，须先报规格，按上限表定席位（如 8G 内存机型曾评估上限后再上调，以上限表现行值为准）
  • 渠道自有硬件：是否收手续费未定，暂逐单报批
  • 批量席位修正：以席位表为准；已确认客户由运维在低峰时段（如凌晨）推送更新，客户端可定期拉取；未确认客户暂不动，确认后在控制台改；销售对已扣减客户逐个复核
  • 震宇款 8 盘位可扩到 12 盘位，按硬件规格单独评估

10. 待确认问题

  • 主责是交付统筹还是销售？席位数量最终拍板人是否为研发负责人？
  • 各型号×内存的席位上限表能否成文？现行值是多少？
  • 渠道/客户自加内存是否收手续费？标准多少？
  • 批量修正时是否通知客户、话术由谁定？
  • 签约/订单能否通过渠道系统接口自动同步席位到系统配置，并由机器人出差异报表？
  • 席位变更审批是否纳入飞书审批，审批人是谁？
X-DLV-34交付期现场问题反馈与故障闭环待新建推断400

状态：待新建｜证据：推断（来源为单聊，不对外引用）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：交付/驻场期间（尚未验收转入常规售后），客户反馈系统异常（解析失败、问答超时、推理服务不可用、显卡/驱动掉线、IP 变化、系统慢）或提出优化需求时启动，直到问题关闭并正式回复客户
  • 负责人：主责——现场交付工程师（当前：游家豪·推断待确认）；协同——项目负责人（当前：丁震宇·推断待确认，定口径与优先级）、IT 运维/现场排查（当前：杨明学·推断待确认）、研发对接人（当前：李玄冰、张康·推断待确认）、商务/合同（当前：闫登辉·推断待确认）、客户关系（当前：常元和·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 统一入口登记 → ② 分级 → ③ 健康检查与日志收集 → ④ 研发定位根因 → ⑤ 修复封包或临时方案 → ⑥ 现场部署验证 → ⑦ 按口径回复客户 → ⑧ 沉淀根因并关闭
  • 交付结果：已关闭的问题登记记录（含根因、处理方式、修复版本）、客户正式回复、必要时的新版本包与更新后的部署/测试文档
  • 状态依据：02～09 月同类问题多次靠电话、口头转达和群内临时 @ 人处理，无故障单、无分级、日志仅 info 级；出现交付介质与机型不符、代码已提交未封包等交付差错

1. 场景判定

  • 触发条件：交付后、验收或转运维前，客户/现场人员反馈：文件无法解析、问答约 5 分钟被掐断、推理服务不可用、显卡失联、IP 变化导致服务连不上、响应慢；或客户提出优化/新增功能
  • 判断问题：项目是否已验收并转运维？反馈是故障（功能不可用）、性能问题还是新需求？是否必须上门（离线/涉密环境）？
  • 不归本流程管：已验收转运维客户的问题 → 请走 X-CS-05、X-CS-06；新需求承诺与收费 → 请走 X-CS-14、SAL-25；版本升级/回退 → 请走 X-DLV-32；公司线上环境故障 → 请走 RND-75

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
现场交付工程师 登记、分级、现场检查、部署修复、起草回复、关闭 R 现场交付工程师（当前：游家豪·推断待确认）
项目负责人 确认级别与优先级、审定对客口径 A 项目负责人（当前：丁震宇·推断待确认）
IT 运维 上门排查、重启容器、显卡/网络检查 R IT 运维（当前：杨明学·推断待确认）
研发对接人 日志分析、根因定位、修复与封包 R 研发对接人（当前：李玄冰、张康·推断待确认）
商务/合同 合同外需求、回款前置条件确认 C 商务（当前：闫登辉·推断待确认）
客户关系 重大问题对客沟通 I 客户关系负责人（当前：常元和·推断待确认）
研发负责人 P0 超时升级、资源调配 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户/项目名、部署环境（联网/离线/涉密）、设备型号、当前版本号
  • 现象描述、首次出现时间、复现步骤、截图或浏览器 F12 报错
  • 近期变更：重启、断电、换 IP、改配置
  • 日志：任务 worker、backend、文档解析服务、网关；显卡状态；容器状态
  • 使用的模型、OCR/解析组件、并发量
  • 客户侧联络人、可上门时间与准入要求
  • 请求最少包含字段（登记问题或转给研发时必填，缺一项由首接人补齐后再转，不让研发反问）：客户代号与项目编号、环境类型（联网/离线/涉密）、设备型号与当前版本号、现象一句话 + 首次出现时间 + 复现步骤、截图或报错原文位置、近期变更、日志包位置、影响范围（全部不可用/部分功能/变慢）、客户期望答复时间、现场联络人岗位、是否需上门

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 所有反馈统一登记；电话/微信来的由首接人代填 首接人 收到后 2 小时内 飞书表单→多维表格 问题记录（交付问题表一行，编号自动生成，状态“待分级”，自动 @ 现场交付工程师） 🔧飞书固化
2 分级：P0 服务不可用；P1 部分功能异常或明显变慢；P2 优化需求 现场交付工程师，项目负责人确认 登记后 2 小时内 多维表格 级别、处理人（回写问题表，P0 同步项目群置顶）；项目负责人 2 小时未确认按现场定级先行处理 👤人工判断
3 跑健康检查脚本（模型/embedding/解析服务连通、IP、显卡、容器），打包日志 现场交付工程师/IT 运维 P0 4 小时内；P1 1 个工作日内；需上门的 P0 次日到场 健康检查脚本 检查结果、日志包（上传问题表附件或指定网盘目录，链接回写问题表并 @ 研发对接人）；超时→项目负责人 🤖自动化
4 远程定位根因（网关超时、写死 IP、反向代理配置、驱动掉卡、服务未自启等），给修复或绕过方案 研发对接人 P0 收到日志后 4 小时内；P1 2 个工作日内 远程/项目群 根因与方案（回写问题表“根因/处理方式”列，不只在群里说）；超时→研发负责人 👤人工判断
5 需改代码的：修复→封包（版本号、变更清单、介质格式与目标机型核对）→按 X-DLV-36（部署 SOP 与交付文档沉淀）中的现场测试清单自测 研发对接人 P0 1 个工作日内；P1 随下个版本 Git、打包脚本 带版本号的包（存指定发布目录，封板清单贴问题表，@ 现场交付工程师）；超时→研发负责人 🔧+🤖
6 现场部署修复版并验证，保留回滚包 现场交付工程师 包到后 1 个工作日内（离线刻盘的按上门安排） 现场/远程 验证结果（问题表“修复版本/验证结论”列，失败回到步骤 4）；超时→项目负责人 👤人工判断
7 回复客户：能做的给排期；大改动明确本期不做；合同外的标“需商务确认” 现场交付工程师起草，项目负责人审定 定位后 1 个工作日内 回复模板（AI 起草） 客户回复（正式渠道发出，原文贴问题表“回复口径”列）；审定超 4 小时→现场交付工程师直接报研发负责人 🤖+👤
8 记录根因，按 X-DLV-36 补进部署 SOP 与现场测试清单后关闭；同根因出现 ≥2 次转研发改进 现场交付工程师 关闭当天 多维表格、部署 SOP 关闭记录（问题表状态“已关闭”+ 客户确认，SOP 变更链接；复发项转研发工单编号） 🔧飞书固化

5. 交付物与模板

  • 交付物：问题登记记录、客户回复、修复版本包及封板清单、更新后的部署/测试文档
  • 建议模板/表单：问题登记——编号、客户/项目、环境类型、设备型号、版本、反馈渠道、反馈时间、现象、级别、是否需上门、处理人、根因、处理方式、修复版本、是否合同外、回复口径、客户确认、关闭时间
  • 客户回复模板：问题现状、处理结果、后续安排、需客户配合事项
  • 交付封板清单：版本号、包校验值、介质格式、目标机型、自测结果

6. 异常与升级

  • P0 4 小时未定位 → 现场交付工程师报项目负责人 → 当天拉研发负责人
  • 需上门涉密机房 → 项目负责人当天确认人员与准入 → 次日内到场
  • 现场与研发联系不上（时段错开）→ 约定固定联调窗口；研发超 1 个工作日未响应 → 升级研发负责人
  • 交付介质错误（格式/机型不符）→ 当天重做并按封板清单复核 → 项目负责人对客说明
  • 客户未回款却提新增需求 → 不排期，转商务确认（2 个工作日内）
  • 客户持续反馈慢 → 记录性能基线（模型、OCR 组件、耗时），研发 2 个工作日内出评估
  • 转研发时字段不全（无版本号、日志包、复现步骤）→ 研发对接人退回问题表并标“待补充”，不在群里追问 → 首接人 2 小时内补齐；P0 可先远程定位再补
  • 问题表状态超过该步时限未更新 → 项目负责人（或交付统筹）标红并 @ 处理人 → P0 再过 2 小时、P1 再过 1 个工作日无动作升级研发负责人
  • A（升级）说明：故障级别、优先级与对客口径由项目负责人拍板（A）；P0 4 小时未定位、研发超 1 个工作日未响应需调配资源时升级研发负责人

7. 衡量指标

  • P0 恢复时长：登记到服务恢复，目标 ≤ 1 个工作日（需上门 ≤ 2 个工作日）
  • 登记率：登记问题数 ÷ 实际反馈数（抽查群聊），目标 100%
  • 重复故障率：同根因 30 天内复发次数，目标 0
  • 首次正式回复时效：登记到首次回复，目标 ≤ 1 个工作日
  • 封包/介质差错数，目标 0

8. 低效诊断

  • 现象：客户问题经电话/口头转达后再在群里 @ 运维和研发，没有故障单，状态无法追踪｜依据：（推断）
  • 现象：日志只有 info 级，排查路径靠问研发；IP 变化、网关超时、推理服务未起、显卡失联等同类故障一个月内约 6 次｜依据：（推断）
  • 现象：现场人员与研发联络时段错开，排查拖延；一线需亲自赶往涉密机房｜依据：（推断）

9. 分支变体

  • 军队/涉密类客户：离线环境，必须上门；修复包需刻盘，介质格式与机型提前核对；文档随盘提供 Word 版
  • 政府/安全类客户：合同盖章、设备采购为付款前提；未回款前不承接额外需求
  • 算力受限客户：回复口径明确“不支持重度使用”
  • 远程可达客户（高校/水利类）：远程排查为主
  • 线下交付设备反馈慢：先记录模型、OCR 组件与耗时基线再排查
  • 已验收转运维：移交 X-CS-05（客户问题受理、分流与工单流转）
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）

10. 待确认问题

  • 交付期与售后期的分界：以验收单签署为准，还是以转运维交接为准？
  • 主责是否为现场交付工程师，项目负责人只管口径与优先级？
  • P0/P1 时限是否可行？涉密现场上门时限多少合适？
  • 是否已有健康检查脚本可复用？由谁维护？
  • 客户反馈入口是否统一为飞书表单（客户无飞书时由首接人代填）？
  • 日志分级与关键字规范由研发哪个岗位负责？
X-DLV-35交付进度跟踪与卡点盘点待优化240

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：交付订单从受理到客户验收期间，按“采购/装机→软件部署→测试→充值→发货/上门”逐环节接力并同步进度；每周盘点卡点与遗漏；订单激增积压时调配人力
  • 负责人：主责——交付总负责人（当前：游家豪·推断待确认）；协同——交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）、IT 运维/硬件采购（当前：杨明学·推断待确认）、LeapCore 部署/网络配置（当前：杨云峰·推断待确认）、充值负责人（当前：柯逸飞·推断待确认）、测试（当前：张东郅·推断待确认）、后端/订单答疑（当前：宋祺睿·推断待确认）、定制项目负责人（当前：望政韬·推断待确认）、整理纪要（当前：吴琪·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 订单入台账并倒排节点 → ② 各环节完成即改状态并同步订单群 → ③ 自动提醒下一环节 → ④ 每日逾期推送 → ⑤ 每周盘点与例会 → ⑥ 积压时调配人力 → ⑦ 验收后关闭
  • 交付结果：状态实时可见的交付订单看板、每周卡点盘点清单与处理结论、定制项目周简报
  • 状态依据：07 月已发布产研侧交付 SOP，要求每步在订单群同步，但 06～10 月仍约 15 次追问进度，出现部署后无人测试、统计漏单、表格无状态流转；07～08 月订单激增积压，无专职技术售后

1. 场景判定

  • 触发条件：订单已建群派工进入执行；每周固定盘点时点；管理层追问进度；待交付订单超出交付人力
  • 典型说法：「每个交付步骤完成后，需要在该订单对应的群内通知」「现在部署之后没人测试」「会出现有一些单子忘记跟进的情况」「不要等问了再同步，不然有点信息黑洞」「待交付订单积压较多」
  • 判断问题：订单是否已受理并有专属群？现在卡在哪个环节、谁在等谁？是否超过节点期限？
  • 不归本流程管：订单受理、建群与派工 → 请走 X-DLV-07；项目立项台账 → 请走 X-DLV-08；出货排期与延期通知 → 请走 X-DLV-04；现场部署实施 → 请走 X-DLV-19；验收签收与开票 → 请走 X-DLV-29；通用会议纪要 → 请走 CEO-10；研发日报周报 → 请走 RND-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付总负责人 维护台账、推进各环节、联系客户、每周盘点 R 交付总负责人（当前：游家豪·推断待确认）
交付 SOP 统筹 对交付按期负责、主持例会、处理卡点与人力调配 A 交付 SOP 统筹/产品总监（当前：杨萌·推断待确认）
IT 运维/硬件采购 硬件采购、装机验证 R IT 运维/硬件采购（当前：杨明学·推断待确认）
部署/网络配置 软件部署、WG/网络配置 R LeapCore 部署/网络配置（当前：杨云峰·推断待确认）
测试 部署后测试并发报告 R 测试（当前：张东郅·推断待确认）
充值负责人 企业额度充值并群内确认 R 充值负责人（当前：柯逸飞·推断待确认）
后端/订单答疑 订单系统与数据问题答疑 C 后端（当前：宋祺睿·推断待确认）
定制项目负责人 定制项目周简报 R 项目负责人（当前：望政韬·推断待确认）
纪要整理 专项会纪要整理与负责人确认 R 纪要整理（当前：吴琪·推断待确认）
研发负责人 积压时人力调配拍板 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 交付订单台账（多维表格）字段齐全：订单号、客户、型号与台数、交付方式、合同交付日、当前环节、环节负责人、环节截止、卡点、状态
  • 订单专属群已建，各环节负责人已入群
  • 交付 SOP（产研）最新版链接
  • 客户网络条件、上门时间、充值金额是否写入合同/CRM
  • 自动化测试脚本与测试报告模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 订单入台账，按合同交付日倒排各环节截止 交付总负责人 受理后 1 个工作日内 多维表格 节点计划 🔧飞书固化
2 硬件采购/装机完成，改状态“硬件就绪”，自动通知订单群 IT 运维/装机人 完成当时 多维表格+群机器人 状态变更通知 🔧+🤖
3 软件部署与网络配置完成，改状态并自动给测试人派测试任务 部署工程师/网络配置 完成当时 飞书任务 测试任务 🔧+🤖
4 跑自动化测试脚本，测试报告发订单群 测试 部署完成后 1 个工作日内 测试脚本 测试报告 🤖自动化
5 宣布“软硬件就绪”，通知充值；充值完成后群内确认 交付总负责人；充值负责人 就绪当天通知；充值 1 个工作日内 订单群/后台 充值确认 🔧+👤
6 联系客户确认上门时间/网络/发货方式，执行发货或上门 交付总负责人 充值完成后 2 个工作日内 订单群 交付记录 👤人工判断
7 每个工作日 10:00 推送逾期及 24 小时内到期环节，@ 环节负责人 机器人 每个工作日 飞书自动化 逾期清单 🤖自动化
8 每周一盘点全部未完成订单，列卡点与待决策事项并 @ 交付统筹；周例会逐项处理 交付总负责人；交付统筹 每周一 12:00 前出清单 看板视图、例会 卡点盘点清单 🔧+👤
9 定制项目每周五发周简报（本周安排、进展、问题）到项目群 定制项目负责人 每周五 18:00 前 AI 汇总+人工补充 周简报 🤖+👤
10 待交付量超出交付人力，提调配申请，决定借调/外协/顺延并通知销售 交付统筹 → 研发负责人 盘点当天提出，2 个工作日内定 例会 人力调配结论 👤人工判断

5. 交付物与模板

  • 交付物：交付订单看板（“未完成”“已逾期”视图按截止排序）、每周卡点盘点清单、周简报、例会纪要（待办转飞书任务）
  • 建议模板/表单：状态枚举——待采购/装机中/硬件就绪/部署中/待测试/测试通过/待充值/待交付/已交付/已验收
  • 卡点盘点清单字段：订单、客户、当前环节、卡点描述、等待对象、需要的决策、预计解除时间、责任人
  • 周简报字段：本周完成、下周计划、问题与风险、需客户/内部配合

6. 异常与升级

  • 环节超期 1 个工作日 → 机器人提醒；超期 2 个工作日 → 交付统筹介入；影响合同交付日 → 当天报研发负责人并按 X-DLV-04 通知客户
  • 部署后 1 个工作日无人测试 → 交付总负责人指派测试人，交付统筹兜底
  • 采购付款未到位导致到货延误 → 交付统筹当天找财务确认付款时间
  • 统计结果与台账不一致（机器人读群漏单）→ 以台账为准，交付总负责人当天补登
  • 交付总负责人请假 → 按 X-DLV-37 由 B 角接手
  • A（升级）说明：交付进度与卡点处理由交付 SOP 统筹拍板（A）；环节超期影响合同交付日、订单积压需跨组调配人力时升级研发负责人

7. 衡量指标

  • 按期交付率：合同交付日前完成交付的订单 ÷ 当期应交订单，目标 ≥ 90%
  • 环节逾期数：每周超期环节数，目标逐周下降
  • 进度追问次数：管理层在群内追问进度次数，目标每周 ≤ 1
  • 待交付积压：已受理未交付台数，周度跟踪
  • 状态同步率：有状态变更记录的环节 ÷ 实际完成环节，目标 100%

8. 低效诊断

  • 现象：交付 SOP 已要求逐步同步，但部署完成后无人测试，上一环节未同步拖慢下一环节｜依据：「交付订单通知群」2026-07
  • 现象：订单表没有状态流转，进度不可见，只能反复追问；部署记录口径单一被质疑｜依据：「交付订单通知群」2026-06、「交付订单通知群」2026-07
  • 现象：待交付统计依赖机器人读历史消息，出现漏单；盘点结果靠人工 @，统筹环节易漏信息｜依据：「交付订单通知群」2026-07
  • 现象：交付任务集中在单一交付岗位，订单激增后积压，且无专职技术售后｜依据：「交付订单通知群」2026-07、「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-08
  • 现象：采购付款延误导致测试机到货延迟｜依据：「鼎慧产研决策部」2026-08
  • 现象：会议结论无人同步，“一键查询进度”类催办至少 8 次，两个群信息混乱｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • 现象：项目进展不主动同步，管理层按日追问，周报无模板｜依据：「某水利客户研发群」2026-07、「某水利教育客户项目群」2026-08

9. 分支变体

  • 交付方式：上门部署（需客户网络、固定 IP 等条件）/ 客户自取 / 发货寄送
  • 客户方有网络运维人力的，可由销售完成交付，交付总负责人远程支持
  • 标品一体机订单按本流程；定制项目另加每周简报，加急项目按日同步
  • 专项交付会：交付节点前用飞书日程拉会，纪要机器人出纪要并抽取待办到飞书任务（负责人+截止时间）

10. 待确认问题

  • 交付总负责人是否为单一岗位？是否已设 B 角？
  • 订单多维表格的状态字段与自动化通知是否已落地？由谁维护？
  • 部署后测试由哪个岗位固定负责？
  • 每周盘点与例会是否定在周一？
  • 积压阈值（每周可交付台数）是多少？借调/外协人力的审批人是谁？
  • 定制项目周简报归本流程还是归 RND-10？
X-DLV-36部署 SOP 与交付文档沉淀待优化81

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨3 × 险3

  • 适用场景：每次交付/部署完成后补漏，或新版本、新机型、新部署形态首次交付前，需要编写或更新部署 SOP、部署手册、使用教程、现场测试流程并组织演练时启动
  • 负责人：主责——部署 SOP 维护人（当前：杨云峰·推断待确认）；协同——后端/运维（当前：宋祺睿·推断待确认）、IT 运维/硬件（当前：杨明学·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、研发文档作者（当前：李玄冰、张康、邓乾、望政韬·推断待确认）、交付 SOP 统筹（当前：杨萌·推断待确认）、技术审核（当前：王皓南·推断待确认）、测试（当前：张东郅·推断待确认）、商务口径（当前：闫登辉·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 识别更新需求 → ② 分工并按模板起草 → ③ 技术审核 → ④ 非作者演练 → ⑤ 修订发布并记版本 → ⑥ 放入固定空间/随包分发 → ⑦ 交付后复盘补遗
  • 交付结果：固定 wiki 空间中带版本号的“部署 SOP + 使用手册 + 现场测试流程”三件套（必要时含录屏）、交付记录与变更日志
  • 状态依据：已有《软件部署SOP》《交付 SOP（产研）》wiki 并在使用，但 02～06 月出现 SOP 漏步骤跑到一半才发现、文档找不到、两套重复文档、新版本后旧文档失效、文档被催 3 次以上未见成稿

1. 场景判定

  • 触发条件：部署中发现 SOP 遗漏或环境差异；新版本/新机型/新部署形态（集群、信创、离线）首次交付；客户要用户手册、部署文档或视频；交付完成需交给他人复用
  • 典型说法：「找到SOP漏洞了」「这版SOP还需要再优化一下」「趁交付这台 打磨一下SOP」「记得整个使用教程 word和视频都行 然后放服务器里」「从下次交付开始做好文档记录」
  • 判断问题：文档读者是内部部署人员还是客户？换一个人只拿这份文档能否独立完成？
  • 不归本流程管：客户培训组织与培训材料交付 → 请走 X-DLV-28；帮助中心/对外 FAQ → 请走 X-CS-18；批量装机镜像制作 → 请走 X-DLV-12；研发岗位交接 → 请走 RND-85

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
部署 SOP 维护人 维护变更池、分工、发布版本、标废旧文档 A/R 部署 SOP 维护人（当前：杨云峰·推断待确认）
文档作者 按分工起草部署/使用/测试文档、录屏 R 研发文档作者（当前：李玄冰、张康、邓乾、望政韬·推断待确认）；后端/运维（当前：宋祺睿·推断待确认）；IT 运维/硬件（当前：杨明学·推断待确认）
技术审核 审步骤完整、凭据脱敏、回滚方案 C 技术审核（当前：王皓南·推断待确认）
演练人 非作者按文档独立跑一遍 R 交付部署工程师（当前：游家豪·推断待确认）；测试（当前：张东郅·推断待确认）
交付 SOP 统筹 跟进截止、汇总交付总 SOP C 交付 SOP 统筹（当前：杨萌·推断待确认）
商务口径 对客文档中服务范围与口径 C 商务（当前：闫登辉·推断待确认）
研发负责人 分工争议与逾期拍板 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 当前部署 SOP 链接与版本号
  • 本次部署现场记录：环境、命令（现场即记，不依赖 shell history）、报错与处理、耗时
  • compose/env 配置、网络拓扑、磁盘规划（RAID、数据盘挂载）
  • 最新代码仓库地址与版本 tag
  • 文档空间编辑权限（提前申请）
  • 凭据一律用占位符，不写明文

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 部署中/交付后把遗漏点与新经验登记到“SOP 变更池” 部署执行人 交付完成后 1 个工作日内 多维表格 变更条目 🔧飞书固化
2 新版本/新形态交付前确定所需文档并分工（硬件侧、软件侧、测试侧、商务口径），每份指定唯一作者与截止 部署 SOP 维护人 交付启动后 1 个工作日内 飞书任务 分工表 👤人工判断
3 先出框架 SOP（拿到机器→测系统→装镜像→测镜像→激活→交付前复测），细节分层补充；用 AI 依据 compose/env 和聊天记录出初稿 文档作者 分工后 3 个工作日内 飞书文档+AI 初稿 🤖+👤
4 技术审核：步骤完整、凭据脱敏、回滚方案齐全 技术审核 收到后 1 个工作日内 文档评论 审核意见 👤人工判断
5 非作者按文档独立演练一遍，记录卡点 交付部署工程师/测试 审核后 2 个工作日内 测试机 演练记录 👤人工判断
6 修订后发布到固定 wiki 空间，更新版本号与变更日志；对客文档同步放服务器可访问位置或随盘 部署 SOP 维护人 演练后 1 个工作日内 wiki 发布版本 🔧飞书固化
7 归档交付记录（时间、客户、内容、环境、问题、兜底方案） 部署执行人 交付后 24 小时内 飞书文档模板 交付记录 🔧+🤖
8 月度检查变更池清零情况，过期文档标“已废弃”并指向新版 部署 SOP 维护人 每月最后一个工作日 wiki 月度检查记录 🔧飞书固化

5. 交付物与模板

  • 交付物：部署 SOP、使用手册（含录屏）、现场测试流程、交付记录、变更日志
  • 建议模板/表单：部署 SOP——适用版本/机型、依赖清单、环境确认、设备注册、部署步骤（含集群）、用户导入、检查单、网络/WG、回滚方案、常见问题、变更日志
  • 使用手册：功能入口、操作步骤截图、常见问题、录屏链接
  • 现场测试流程：服务连通项、核心功能用例、性能基线、通过标准
  • 交付记录：时间、客户、交付内容、环境、命令摘要、问题与处理、兜底方案、联系人

6. 异常与升级

  • 文档到截止未交 → 作者当天报风险 → 超 2 个工作日由交付 SOP 统筹升级研发负责人
  • 部署中发现 SOP 漏步骤 → 现场先处理并记录 → 1 个工作日内补进 SOP 并通知维护人
  • 新版本导致旧文档失效 → 发布新版时同步标废旧文档；新版本无文档不得进入客户交付
  • 文档出现明文凭据 → 立即删除，按 X-SEC-11 评估是否轮换
  • 文档权限未开 → 维护人 2 小时内开通
  • A（升级）说明：SOP 变更、分工与版本发布由部署 SOP 维护人拍板（A）；文档逾期超 2 个工作日、分工争议无法协调时升级研发负责人

7. 衡量指标

  • 文档覆盖率：有现行部署 SOP/手册/测试流程的交付形态数 ÷ 交付形态总数，目标 100%
  • 演练通过率：非作者首次按文档独立完成的比例，目标 ≥ 80%
  • 变更池积压：超 2 周未处理条目数，目标 0
  • 交付记录归档率：24 小时内归档次数 ÷ 交付次数，目标 100%
  • 因文档缺失导致的现场返工次数，目标逐月下降

8. 低效诊断

  • 现象：部署 SOP 漏掉组织 ID 生成等步骤，跑到一半才发现；补充经验靠口头要求，文档权限未及时开放｜依据：「Leap产研测」2026-06
  • 现象：交付 SOP 被催 3 次以上仍未见成稿，硬件/软件分工需二次点名，旧部署文档对新版本无效｜依据：「LeapCore（archived）」2026-04
  • 现象：使用文档找不到、两套重复文档并存、版本变化后文档过期，现场测试流程临时补写｜依据：「跃迁基座项目交付沟通」2026-02、「跃迁基座项目交付沟通」2026-03
  • 现象：部署命令依赖 shell history，最新代码仓库位置反复询问｜依据：「跃迁基座项目交付沟通」2026-03、「跃迁基座项目交付沟通」2026-06

9. 分支变体

  • LeapCore 标品：框架 SOP 与细节分层；硬件侧（规格、装机、RAID）与软件侧（镜像、WG、域名、认证配置）分文档
  • 离线/涉密客户：Word 版手册随光盘，录屏离线提供
  • 远程可达客户：wiki + 视频
  • 集群、信创/国产算力（K8s、ASR、海光等）：单独部署文档
  • 定制项目：部署、使用、测试三件套 + 交付记录

10. 待确认问题

  • 部署 SOP 唯一维护人是谁？技术审核是否固定为研发技术负责人？
  • 固定 wiki 空间的位置与目录结构？现有分散文档如何合并？
  • 演练是否作为新版本交付的硬性门槛？
  • 交付记录 24 小时内归档是否可行？
  • AI 生成初稿用哪个工具？是否允许读取客户环境配置？
X-DLV-37交付负责人 AB 角与项目交接待新建128

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：交付负责人/项目负责人请假、调岗、离职，或新人入职接手客户项目时启动；平时为每种交付形态和每个在做项目预设 AB 角
  • 负责人：主责——交付统筹（当前：杨萌·推断待确认）；协同——交付负责人 A 角（当前：杨云峰·推断待确认）、B 角/备选操作人（当前：宋祺睿、游家豪、杨明学·推断待确认）、研发技术负责人（当前：王皓南·推断待确认）、原/新项目负责人（当前：黄振锋、望政韬、李铭熙·推断待确认）、项目拉人方（当前：常元和·推断待确认）、开发协助（当前：张康·推断待确认）、HR（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 建 AB 角台账 → ② B 角轮流上机演练 → ③ 触发代岗或交接 → ④ 按清单准备交接包 → ⑤ 交接会与签字 → ⑥ 公告新负责人 → ⑦ 跟岗答疑与回访
  • 交付结果：AB 角台账（每种交付形态/项目一名负责人 + 至少一名已实操的 B 角）、双方确认的项目交接清单、群内新负责人公告
  • 状态依据：06 月唯一熟悉部署的负责人请假时客户交付卡住，“别人能否部署”口径不一；02、06～07 月项目交接靠口头和消息记录，接手人预设失败后项目无人、接手人称未收到需求，无交接清单

1. 场景判定

  • 触发条件：负责人请假 ≥ 1 个工作日且期间有交付/部署；调岗、离职、项目重新分配；新人入职被指定接手；某交付形态只有 1 人能操作
  • 典型说法：「交付能不能整个专人专岗来做」「交付的操作人可以有好几个 但是交付负责人只能有一个」「春节之后把这个项目交接给他」「你后面全权负责」「怕你们私聊太多我不清楚」
  • 判断问题：要交接的是交付操作能力（AB 角）还是整个项目的负责权？是否有在途订单或客户承诺？
  • 不归本流程管：员工离职手续 → 请走 HR-27；账号权限回收 → 请走 X-SEC-08；FDE 驻场人员调配 → 请走 X-FDE-05；研发代码与岗位交接 → 请走 RND-85；新人入职培训 → 请走 HR-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
交付统筹 维护 AB 角台账、组织交接会、公告、回访 A 交付统筹（当前：杨萌·推断待确认）
交付负责人 A 角 对交付结果和 SOP 负责，带教 B 角 R 交付负责人（当前：杨云峰·推断待确认）
B 角/操作人 演练、代岗期间执行部署 R 备选操作人（当前：宋祺睿、游家豪、杨明学·推断待确认）
原项目负责人 准备交接包、跟岗答疑 R 原项目负责人（当前：黄振锋、李铭熙·推断待确认）
新项目负责人 核对清单、签字接手、提资源缺口 R 新项目负责人（当前：望政韬·推断待确认）
研发技术负责人 定 AB 角规则、评估 B 角能力 C 研发技术负责人（当前：王皓南·推断待确认）
项目拉人方/开发协助 新人引入、协助开发 C 项目拉人方（当前：常元和·推断待确认）；开发协助（当前：张康·推断待确认）
HR 新人到岗与离职节点同步 I 人事负责人（当前：黄莹·推断待确认）
研发负责人 人员调配与招聘决定 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 在做项目/订单清单：客户、阶段、承诺日期、待办
  • 客户基础信息：公司名、机器数量与型号、网络环境、额度充值金额、对接人
  • 环境与账号清单：服务器、仓库、控制台、VPN/WG（只列名称和管理位置，凭据走密码管理工具）
  • 文档：部署 SOP、交付记录、项目文档/SKILL、需求与问题清单
  • 遗留问题、风险、对客户的口头承诺
  • 接手人到岗状态（新人须已入职）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 为每种交付形态和每个在做项目登记唯一负责人与 ≥1 名 B 角 交付统筹 立项/新形态出现后 2 个工作日内；每月复核 多维表格 AB 角台账 🔧飞书固化
2 B 角在 A 角带领下按 X-DLV-19（客户现场/远程部署实施）及最新部署 SOP 完成至少 1 次完整部署 A 角、B 角 登记后 2 周内 测试机/真实订单 演练记录 👤人工判断
3 A 角请假/变动提前报备，交付统筹确认期间由 B 角操作 A 角 → 交付统筹 请假前 1 个工作日；突发当天 飞书请假审批+群 代岗安排 🔧飞书固化
4 需正式交接时，原负责人按清单填交接包；AI 汇总群消息生成交接摘要初稿 原负责人 决定交接后 2 个工作日内 交接清单模板+AI 交接包 🤖+👤
5 召开交接会（原、新负责人、交付统筹）逐项确认，新负责人签字 交付统筹 交接包完成后 1 个工作日内 会议 签字清单 👤人工判断
6 在项目群/客户群公告新负责人与生效日期，更新台账；私聊中的需求与决定转到项目群 交付统筹 交接会当天 群公告 公告 🔧飞书固化
7 原负责人跟岗答疑 原负责人 交接后 2 周内 项目群 答疑记录 👤人工判断
8 回访新负责人与客户，确认无断档后关闭 交付统筹 交接后第 2 周 — 关闭记录 👤人工判断

5. 交付物与模板

  • 交付物：AB 角台账、签字交接清单、新负责人公告、演练记录
  • 建议模板/表单：AB 角台账——交付形态/项目、负责人、B 角、B 角最近实操日期、客户、阶段、备注
  • 交接清单——项目/客户、阶段与里程碑、在途订单、客户对接人、环境与账号清单（名称+管理位置）、文档链接、代码仓库与版本、需求/问题清单、客户承诺、风险、交接日期、双方确认
  • 公告模板：项目名、新负责人、生效日期、原负责人跟岗截止日、问题反馈方式

6. 异常与升级

  • A 角突发不可用且 B 角未演练 → 交付统筹当天报研发负责人 → 按 X-DLV-04 通知客户调整交付日
  • 预设接手人未到岗或放弃 → 项目不移交，原负责人继续负责 → 交付统筹 2 个工作日内重新指定
  • 交接资料只有聊天记录 → 原负责人 2 个工作日内补齐 → 逾期升级研发负责人
  • 新负责人反映未收到需求 → 交付统筹 1 个工作日内核对群消息与需求清单，补齐后再关闭
  • 人手不足需补人 → 新负责人提缺口 → 研发负责人 3 个工作日内决定调人或招聘
  • A（升级）说明：AB 角指定与交接安排由交付统筹拍板（A）；A 角突发不可用且 B 角未演练、交接资料逾期未补、需调人或招聘时升级研发负责人

7. 衡量指标

  • B 角覆盖率：有已实操 B 角的交付形态/项目数 ÷ 总数，目标 100%
  • 因负责人缺席导致的交付延期次数，目标 0
  • 交接清单签字率：签字交接次数 ÷ 交接总次数，目标 100%
  • 交接后 30 天内因资料缺失返工次数，目标 0

8. 低效诊断

  • 现象：部署能力集中在单一负责人，请假期间无人能部署，“没人能部署”与“谁都能部署”口径不一｜依据：「鼎慧产研决策部」2026-06
  • 现象：接手人未到岗即被预设接手项目，未成功后项目退回原负责人，新人带教计划未定｜依据：「⭐大模型基座事业群」2026-02
  • 现象：负责人变更后资料只有消息记录，过程依赖私下沟通，接手人称未收到需求，负责权归属反复确认｜依据：「某水利客户研发群」2026-06、「某水利客户研发群」2026-07

9. 分支变体

  • 标品 LeapCore 交付：负责人唯一、操作人可多个；公司自有环境可由内部 B 角部署，外部客户先由 A 角或已演练的 B 角执行
  • 信创/非信创、联网/内网部署：分别配 B 角
  • 新人入职接手：入职前提供预读资料包（项目文档、SKILL），入职后再正式交接
  • 组内调整：多项目并行（水利、教育、军队等）时按项目台账逐项交接

10. 待确认问题

  • AB 角台账由交付统筹还是项目部维护？
  • B 角最低实操要求（1 次完整部署）是否足够？
  • 请假报备能否与飞书请假审批联动自动提醒交付统筹？
  • 交接清单是否需要研发负责人签字？
  • 本流程是否与 RND-85、HR-27 合并维护？
X-DLV-38星域俱乐部商户入驻、开通与数据迁移待新建240

状态：待新建｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：意向电竞俱乐部/工作室确定合作后，从收集入驻材料、签约、开户，到开通会员端模块与配置、旧系统会员数据迁移、客服/接待培训并上线的全过程
  • 负责人：主责——商户入驻专员（当前：宫经喜·推断待确认）；协同——会员端产品经理（当前：陈雁·推断待确认）、后端负责人（当前：王子明·推断待确认）、后端开发（当前：张楠·推断待确认）、管理端开发（当前：陈真炎·推断待确认）、培训教学（当前：刘安达·推断待确认）、迁移方案（当前：蒋兴武·推断待确认）、会员体系（当前：林瑾鸿·推断待确认）、小程序/H5（当前：魏小东·推断待确认）、法务/财务（当前：待指定）；兜底——跃竞负责人（当前：徐莉·推断待确认）
  • 核心流程：① 建档并收集入驻材料 → ② 签约 → ③ 开户与管理员开通 → ④ 会员端模块与配置 → ⑤ 旧系统数据迁移（如有）→ ⑥ 客服/接待培训 → ⑦ 上线冒烟与回访
  • 交付结果：入驻台账中状态为“已上线”的商户记录（含合同、账户、模块开关、配置清单、迁移对账结果、培训记录）、商户展示素材
  • 状态依据：08～10 月约 30 次入驻推进只在日报里一句话记录，状态用词不一；05～06 月会员端开通“谁来配置”无答案、迁移“谁来搞”无人认领、方案开 3 轮会才定，无入驻台账和通用迁移流程

1. 场景判定

  • 触发条件：俱乐部确认合作意向；新版本上线模块需为已有俱乐部开通；新俱乐部要从旧会员系统迁移数据
  • 典型说法：「商户入驻（已完成）」「到时候谁配这家的配置啊，网页不敢点啊」「会员商品模块开关至关重要」「得先把数据要回来，最好是系统源代码也看看」「用手机号也可以把两边的数据对应起来」
  • 判断问题：俱乐部是否已确认合作？是否需要会员端？是否有旧系统数据（含余额）要迁？
  • 不归本流程管：支付通道与收款商户进件 → 请走 FIN-15；入驻后会员端配置日常调整 → 请走 X-CS-22；俱乐部日常反馈 → 请走 X-CS-23；俱乐部账务工单 → 请走 X-CS-24；LeapCore 一体机交付 → 请走 X-DLV-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
商户入驻专员 建档、材料、进度跟踪、展示素材、上线回访 R 商户入驻专员（当前：宫经喜·推断待确认）
会员端产品经理 对接俱乐部确认配置内容与迁移需求 R 会员端产品经理（当前：陈雁·推断待确认）
后端负责人 开户、权限、迁移执行方案 R 后端负责人（当前：王子明·推断待确认）
后端/管理端开发 模块开关、配置落地 R 后端开发（当前：张楠·推断待确认）；管理端开发（当前：陈真炎·推断待确认）
迁移方案/会员体系 迁移评估、方案文档、等级与余额处理 R 迁移方案（当前：蒋兴武·推断待确认）；会员体系（当前：林瑾鸿·推断待确认）；小程序/H5（当前：魏小东·推断待确认）
培训教学 客服/接待培训 R 培训教学（当前：刘安达·推断待确认）
法务/财务 合同条款与资金账户审核 C 法务/财务（当前：待指定）
跃竞负责人 方案拍板、异常决策 A 跃竞负责人（当前：徐莉·推断待确认）

3. 办之前请准备

  • 入驻材料：主体资质、门店信息、联系人、单主体/多主体结构、品牌形式（平台版/独立品牌）
  • 合同模板与报价
  • 需开通模块清单（如会员商品 memberGoods）、等级/权益/分类设置、美工图（门头、前台、会员素材）
  • 旧系统信息：系统类型、数据结构、导出方式、唯一标识（是否有手机号）、余额与累计消费口径、可停机窗口
  • 客服/接待人员名单与培训时间
  • 网页版使用教程、入驻演示视频

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 意向确认后在入驻台账建条目，发材料清单 商户入驻专员 确认后 1 个工作日内 多维表格 入驻条目 🔧飞书固化
2 收集并核对材料；多主体等特殊情形报产品经理定方案 商户入驻专员；产品经理 材料齐后 2 个工作日内 入驻台账 核对结果 👤人工判断
3 签署合同，人工审核条款与资金账户 商务对接人；法务/财务 核对后 5 个工作日内 合同/电子签 已签合同 🔧+👤
4 开户与管理员账号开通，超管勾选接待等权限 后端负责人 签约后 1 个工作日内 管理端 账号与权限 🔧飞书固化
5 按开通清单配置模块开关（club config moduleCode）、等级、权益、分类、美工图；配置内容由产品经理与俱乐部确认，可自配的由俱乐部管理员自配 产品经理、后端开发 开户后 2 个工作日内（美工图未齐标“待素材”） 管理端 配置清单勾选 🔧+👤
6 有旧系统数据的做迁移评估（唯一标识、余额处理、历史范围、停机窗口），出方案报跃竞负责人拍板 迁移方案、后端负责人 立项后 3 个工作日内 迁移方案文档（AI 辅助起草） 迁移方案 🤖+👤
7 隔离环境试迁 → 停旧系统 → 正式迁移 → 余额用 CDK/接待代充 → 与俱乐部对账确认 后端负责人、会员体系 按约定停机窗口；对账 1 个工作日内 迁移工具 对账确认单 🤖+👤
8 客服/接待培训，交付教程与演示视频 培训教学 配置完成后 3 个工作日内 线上/线下 培训记录 👤人工判断
9 上线冒烟（模块可见、昵称审核、红点、会员商品），制作展示素材，台账置“已上线”，7 天后回访 商户入驻专员 培训后 1 个工作日内；回访 7 天后 入驻台账 上线与回访记录 🔧+🤖

5. 交付物与模板

  • 交付物：入驻台账记录、已签合同、开通配置清单、迁移方案与对账确认单、培训记录、商户展示素材
  • 建议模板/表单：入驻台账——商户、主体结构、类型（俱乐部/工作室）、品牌形式、对接人、材料状态、合同状态、账户、开通模块、配置完成度、素材、迁移状态、培训状态、上线日期、回访结果；状态统一枚举：意向/材料中/待签约/已签约/开通中/迁移中/培训中/已上线
  • 开通清单：模块开关、权限、等级、权益、分类、美工图
  • 迁移评估清单：旧系统类型、数据字段、唯一标识、余额与累计消费处理、历史范围、停机窗口、回滚方案、对账方式

6. 异常与升级

  • 材料不齐超 5 个工作日 → 商户入驻专员报跃竞负责人决定是否暂停
  • 配置人不明确或无人敢操作生产配置 → 产品经理当天确认配置内容并交后端负责人执行
  • 旧系统数据拿不到（在第三方手上）→ 产品经理 2 个工作日内协调俱乐部提供 → 仍拿不到报跃竞负责人
  • 迁移对账有差异（余额/消费）→ 冻结相关账户，后端负责人当天排查 → 跃竞负责人决定补偿或回滚
  • 各端判断“是否开通会员端”的逻辑不一 → 统一以后端接口为准，研发 1 个迭代内修正

7. 衡量指标

  • 入驻周期：意向确认到已上线的自然日，目标 ≤ 14 天（含迁移的另计）
  • 状态口径一致率：台账使用统一状态枚举的比例，目标 100%
  • 配置遗漏数：上线后发现的模块/权限遗漏，目标 0
  • 迁移准确率：对账无差异账户 ÷ 迁移账户，目标 100%
  • 培训完成率：上线前完成培训的商户比例，目标 100%

8. 低效诊断

  • 现象：入驻进度只在日报里一句话，销售→入驻→培训→技术开通无统一台账，状态用词不一（已入驻/已完成/待签约）｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-10
  • 现象：每个商户重复准备材料与培训内容｜依据：「跃玩项目组」2026-09
  • 现象：会员端开通需手动配置，谁来配置没有明确答案；无会员端俱乐部的判断逻辑各端不统一｜依据：「跃玩remote工作组」2026-05、「跃玩remote工作组」2026-06
  • 现象：旧系统迁移无人认领，旧系统结构与唯一标识长期不清，方案经多轮会议才定｜依据：「跃玩remote工作组」2026-06

9. 分支变体

  • 单主体 vs 多主体；工作室 vs 俱乐部；平台版 vs 独立品牌
  • 有会员端 vs 无会员端俱乐部：昵称审核、红点逻辑不同
  • 迁移路径：授权登录 / 手机号匹配 / 迁移码 / 人工代充；首个迁移客户（俱乐部客户A）采用强制跳转绑定方案，余额不直接迁，用 CDK 或接待代充，迁移前停旧系统
  • 与 LeapCore 交付属不同产品线，后续可单列分组

10. 待确认问题

  • 入驻主责是商户入驻专员还是会员端产品经理？
  • 会员端配置由俱乐部管理员自配还是公司代配？
  • 入驻周期 14 天目标是否可行？
  • 是否开发通用迁移工具（Excel 导入 + 绑定码）？由谁负责？
  • 合同与资金账户审核是否走法务/财务审批？
  • 本 SOP 是否与 X-CS-22 合并？
X-DLV-39外部数据集交付（构建验证、质检与外发保密）待新建250

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：向外部客户交付强化学习环境、代码任务、游戏数据等数据包时启动，覆盖保密确认、制作、构建验证、反作弊与难度测试、外发审批、打包交付、客户反馈修订与成果展示
  • 负责人：主责——数据交付负责人（当前：丁震宇·推断待确认）；协同——研发/数据工程（当前：待指定）、商务（当前：待指定）、法务（当前：待指定）、外部协作者对接人（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认，与主责重合，建议另设）
  • 核心流程：① 需求与保密确认 → ② 定价与分派（含外部协作）→ ③ 制作 → ④ 构建验证（x86/arm）→ ⑤ 反作弊与难度测试 → ⑥ 外发审批 → ⑦ 打包交付 → ⑧ 反馈修订与成果复盘
  • 交付结果：通过构建、判分、反作弊与难度测试的数据包（含版本号、清单与校验值）、外发审批记录、客户验收反馈、成果展示材料（录屏/PDF）与 ROI 复盘结论
  • 状态依据：10 月首次外部数据合作 5 天内约 25 次往返：客户测出判分可被绕过的 P0 漏洞、任务难度不足被模型快速解出、游戏类项目体量过大需砍、保密与可外发范围临时询问，缺交付清单与外发审批

1. 场景判定

  • 触发条件：向外部客户交付数据/任务包；客户反馈漏洞或难度问题需修订；需要外部协作者参与制作；需外发需求文档或造数据方法
  • 典型说法：「发现一个 P0 漏洞：奖励可以被骗」「需求文档不保密，可外发」「我造数据的方法和你的需求文档是保密的吗」「Game 抓紧时间搞一下」「如果ROI打得正 我就把我的SOP复用给一大波人」
  • 判断问题：交付物是数据/任务包而不是软件部署吗？包内是否含公司方法、客户需求文档或第三方素材？
  • 不归本流程管：外包数据采集委托与验收 → 请走 RND-88；保密协议签署 → 请走 LEG-05；对外材料保密审查通用规则 → 请走 LEG-30；数据合作定价 → 请走 SAL-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
数据交付负责人 对交付质量与保密负责，对接客户，分级反馈 A/R 数据交付负责人（当前：丁震宇·推断待确认）
研发/数据工程 制作、构建验证、反作弊与难度测试、打包 R 研发/数据工程（当前：待指定）
外部协作者对接人 外部协作者分派、进度与保密协议 R 外部协作者对接人（当前：待指定）
商务 定价、ROI 评估、合同 R 商务（当前：待指定）
法务 保密级别判断、外发审批 C 法务（当前：待指定）
研发负责人 范围调整与继续/终止决策 A（升级） 研发负责人（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 合作协议与保密条款；客户需求文档及其保密级别（书面确认）
  • 任务规格：平台（Android/KMP、iOS、UE5 游戏等）、架构（x86/arm）、判分方式、难度目标、规模上限
  • 构建环境与 CI 配置
  • 外部协作者名单及已签保密协议
  • 版本号规则、打包格式、加密传输方式
  • 客户验收标准与成果展示形式

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 书面确认需求文档、造数据方法、产出物的保密级别与可外发范围（双向） 数据交付负责人、法务 启动前；新增外发内容前 1 个工作日 邮件/群内书面 保密确认记录 👤人工判断
2 评估规模与 ROI 并定价；外部协作者签保密协议后分派，规模过大先砍范围 商务、数据交付负责人 启动后 2 个工作日内 合同 报价与分派表 👤人工判断
3 制作任务/数据，按规则记录版本 研发/外部协作者 按排期 Git 数据包初版 👤人工判断
4 构建验证：x86/arm 双架构构建、判分脚本运行 研发/数据工程 每版提交后 1 个工作日内 CI 构建报告 🤖自动化
5 反作弊测试：检查可绕过判分的路径（如忽略失败开关、篡改测试）；难度测试：用主流模型试解，被快速解出的退回加难 研发/数据工程 构建通过后 1 个工作日内 检查脚本+模型 质检报告 🤖+👤
6 外发审批：核对包内无未授权内部代码、凭据、第三方受限素材 数据交付负责人、法务 质检通过后 1 个工作日内 飞书审批 外发审批记录 🔧飞书固化
7 打包（清单、版本号、校验值），加密传输并通知客户 研发/数据工程 审批通过当天 邮件/文件传输 交付包 🔧+🤖
8 客户反馈分级：P0（判分漏洞、构建失败）修复后重走 4～7；难度/范围意见排期回复 数据交付负责人 P0 1 个工作日内修复；其他 3 个工作日内回复 合作群 修订版 👤人工判断
9 按约定形式做成果展示（录屏/PDF），复盘 ROI，决定方法是否沉淀为可复用 SOP 数据交付负责人、商务 交付完成后 5 个工作日内 文档 展示材料、复盘结论 👤人工判断

5. 交付物与模板

  • 交付物：数据包、交付清单、质检报告、外发审批记录、成果展示材料、复盘结论
  • 建议模板/表单：数据交付清单——任务 ID、平台、架构、构建状态、判分结果、反作弊检查项、难度测试结果、版本、校验值、外发审批号
  • 外发审批表单——交付对象、内容清单、保密级别、是否含公司方法/客户文档/第三方素材、对方保密协议状态、审批人
  • 成果展示模板——任务样例、关键指标、录屏链接

6. 异常与升级

  • 客户报告 P0 漏洞 → 当天暂停同批次交付，排查同类任务 → 1 个工作日内修复重发
  • 保密级别不明 → 书面确认前不外发 → 法务 1 个工作日内给出判断
  • 项目体量超出排期（如游戏类）→ 数据交付负责人 1 个工作日内与客户确认缩减范围
  • 外部协作者延期 2 个工作日 → 对接人升级数据交付负责人，决定更换或内部接手
  • 复盘 ROI 为负 → 商务与研发负责人决定是否继续合作
  • A（升级）说明：交付质量、外发与分级反馈由数据交付负责人拍板（A）；项目范围需大幅调整、复盘 ROI 为负需决定继续或终止合作时升级研发负责人

7. 衡量指标

  • 首轮通过率：客户首轮未发现 P0 问题的任务比例，目标 ≥ 95%
  • 外发审批覆盖率：走审批的外发次数 ÷ 总外发次数，目标 100%
  • P0 修订周期：客户反馈到修复版交付，目标 ≤ 1 个工作日
  • 难度达标率：未被主流模型直接解出的任务比例，目标按合同约定
  • ROI 复盘覆盖率：完成复盘的数据合作项目比例，目标 100%

8. 低效诊断

  • 现象：交付前缺反作弊检查，客户测出判分可被绕过的 P0 漏洞｜依据：「模态跃迁 x 客户B 数据合作群」2026-10
  • 现象：交付前缺难度测试，任务被模型快速解出后才补题加难｜依据：「模态跃迁 x 客户B 数据合作群」2026-10
  • 现象：保密与可外发范围在交付中途临时询问，无外发审批｜依据：「模态跃迁 x 客户B 数据合作群」2026-10
  • 现象：游戏类数据由外部协作者制作，体量过大需返工砍范围，客户多次催进度｜依据：「模态跃迁 x 客户B 数据合作群」2026-10
  • 现象：成果展示形式未提前约定，临时改为录屏｜依据：「模态跃迁 x 客户B 数据合作群」2026-10

9. 分支变体

  • Android/KMP 任务、iOS 任务：需对应构建环境（iOS 需 macOS 构建机）
  • UE5 游戏数据：体量大，需外部协作者，启动前先定规模上限
  • 海外客户：沟通时差、跨境数据传输合规需法务确认

10. 待确认问题

  • 是否另设数据交付负责人，与研发负责人分开？
  • 法务是否参与每次外发审批，还是只审首次与新增内容？
  • 外部协作者保密协议是否已签？费用如何结算、由谁审批？
  • 是否建设自动化 CI 复核（构建+判分+反作弊+难度）？由谁维护？
  • 本次方法是否沉淀为可复用 SOP，复用范围和对外口径是什么？
X-DLV-40项目结项、交付转售后移交与复盘待新建推断144

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：交付项目取得验收（或标品订单完成签收）后，正式结项：资料归档、成本核算、把客户环境与承诺移交售后，并做项目复盘
  • 负责人：主责——交付负责人（当前：待指定）；协同——交付工程师、售后负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 验收确认 → ② 交付资料归档 → ③ 售后移交会 → ④ 售后签收移交清单 → ⑤ 项目成本与工时核算 → ⑥ 复盘 → ⑦ 交付群转售后群/关闭
  • 交付结果：结项报告、售后签收的移交清单、归档资料、复盘纪要
  • 状态依据：已有 X-DLV-29（签收单与验收单）、X-DLV-31（已交付设备与客户信息登记）覆盖部分环节，本条补齐项目结项、交付转售后移交与复盘（推断）

1. 场景判定

  • 触发条件：取得签收单/验收单；项目最后一个里程碑完成
  • 典型说法：「这个项目交完了以后客户找谁？」「交付群一直没人关」「这个客户当时怎么配的没人知道」
  • 判断问题：交付义务是否已全部完成？是否还有未关闭的现场问题？
  • 不归本流程管：签收与开票 → 请走 X-DLV-29；设备信息登记 → 请走 X-DLV-31；部署 SOP 更新 → 请走 X-DLV-36

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
结项负责人 组织结项、移交与复盘 A 交付负责人（当前：待指定）
交付工程师 整理资料、讲清环境与遗留问题 R 交付工程师（当前：待指定）
售后 审核并签收移交清单、接管客户 R 售后负责人（当前：待指定）
销售 确认对客承诺与回款状态 C 客户对接销售（当前：待指定）
财务 提供项目收入、采购成本 C 财务专员（当前：待指定）

3. 办之前请准备

  • 签收单/验收单、合同与技术附件
  • 客户环境信息（实例、网络、账号、管理员、特殊配置）
  • 遗留问题清单与对客承诺
  • 项目工时与采购记录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认验收完成、遗留问题清单 交付负责人 验收后 2 个工作日内 交付群 结项启动 👤人工判断
2 归档合同、方案、部署记录、手册、验收单 交付工程师 启动后 3 个工作日内 知识库 项目档案 🔧飞书固化
3 召开售后移交会（环境、配置、承诺、遗留问题、联系人） 交付负责人 启动后 5 个工作日内 会议 移交清单 👤人工判断
4 售后签收移交清单，录入定制配置台账（X-CS-11） 售后负责人 移交会后 2 个工作日内 多维表格 签收记录 🔧飞书固化
5 汇总工时与采购成本，算项目毛利 交付负责人、财务专员 结项后 10 个工作日内 台账 成本核算 🤖自动化
6 项目复盘（计划 vs 实际、问题、经验） 交付负责人 结项后 10 个工作日内 会议 复盘纪要 👤人工判断
7 交付群改为售后服务群或解散，更新项目台账为已结项 交付负责人 签收后 1 个工作日内 飞书 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：结项报告、移交清单、项目档案、成本核算、复盘纪要
  • 建议模板/表单：售后移交清单（客户、合同号、交付范围、实例/设备与指纹、网络接入方式、管理员账号存放位置、特殊配置、对客承诺、维保期、遗留问题与预计关闭时间、客户联系人、交付联系人、售后接收人）

6. 异常与升级

  • 存在未关闭遗留问题 → 明确责任人与关闭时间后仍可移交 → 升级交付负责人
  • 售后拒收（资料不全）→ 3 个工作日内补齐 → 升级研发部门报送人
  • 项目毛利为负或明显超工时 → 复盘中单列原因 → 升级管理层

7. 衡量指标

  • 结项及时率 = 验收后 10 个工作日内完成结项的项目比例，目标 ≥ 90%
  • 移交后 30 天内回流交付人员的客户问题数，目标逐月下降
  • 复盘完成率，目标 100%（项目制），标品订单抽样

8. 低效诊断

  • 聊天中未见相关流程，存在客户环境信息只在个人脑中、交付人员长期被售后问题占用、项目盈亏不清的风险（推断）

9. 分支变体

  • 标品一体机订单：简化为移交清单 + 台账更新，不开复盘会
  • 渠道交付订单：移交对象为渠道售后，我方保留二线支持
  • 私有化/离线项目：额外移交离线升级包与现场准入材料

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 售后团队是否已独立？移交给谁？
  • 项目工时是否已有登记口径（X-DLV-08）？
  • 哪类项目必须做复盘？
X-DLV-41一体机发运包装、物流保价与到货异常处理待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：一体机、服务器、集群节点等高价值硬件需寄送客户或渠道时，按规范包装、保价发运、跟踪物流，并处理到货破损、丢件、错发
  • 负责人：主责——交付工程师（当前：待指定）；协同——行政专员、交付负责人、客户对接销售、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 出库核对（序列号、配件清单）→ ② 拍照留证 → ③ 规范包装 → ④ 保价下单 → ⑤ 运单同步 → ⑥ 物流跟踪 → ⑦ 到货开箱确认 → ⑧ 异常理赔与补发
  • 交付结果：带序列号的发货单、开箱照片、运单号与保价凭证、客户到货确认
  • 状态依据：已有 ADM-16（对外寄件与快递月结）覆盖一般寄件环节，本条补齐高价值硬件的包装、保价发运与到货异常处理（推断）

1. 场景判定

  • 触发条件：X-DLV-18 确定寄送方式；渠道/客户订单需发货；返修件回寄
  • 典型说法：「机器寄过去要不要保价」「客户说收到的机器外壳坏了」「少了一根电源线」
  • 判断问题：寄送物品是否为整机、服务器、GPU 等高价值设备？
  • 不归本流程管：文件/签收单/小件寄送 → 请走 ADM-16；出货排期 → 请走 X-DLV-04；硬件故障返修 → 请走 X-CS-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发运负责人 出库核对、包装、下单、跟踪 A/R 交付工程师（当前：待指定）
行政 物流合同与月结、理赔对接 C 行政专员（当前：待指定）
销售 确认收货信息、通知客户验收 C 客户对接销售（当前：待指定）
交付负责人 异常补发决策 C 交付负责人（当前：待指定）
财务 运费与保价费入账、理赔款核对 I 财务专员（当前：待指定）

3. 办之前请准备

  • 订单号、收货人、地址、电话（脱敏存放）
  • 设备序列号、指纹登记记录、配件清单
  • 包装材料（原厂箱或定制防震箱）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按配件清单出库核对并登记序列号 交付工程师 发货前 1 个工作日 资产台账 出库记录 🔧飞书固化
2 整机外观与配件拍照、封箱照 交付工程师 封箱时 手机/交付群 留证照片 👤人工判断
3 按规范防震包装，贴易碎/向上标识 交付工程师 封箱时 — 合格包装 👤人工判断
4 按设备价值足额保价下单 交付工程师 封箱当天 物流月结 运单与保价凭证 🔧飞书固化
5 运单号同步交付群与销售 交付工程师 下单后 1 小时内 交付群 运单通知 🤖自动化
6 提醒客户当面开箱验货、异常拒收或拍照 客户对接销售 到货前 1 天 客户群 提醒记录 🔧飞书固化
7 客户确认到货完好，更新台账为已送达 交付工程师 签收后 1 个工作日内 资产台账 到货确认 🔧飞书固化
8 异常：取证、报物流理赔、决定补发或换机 交付工程师、行政专员 发现后 1 个工作日内 物流平台 理赔单、补发单 👤人工判断

5. 交付物与模板

  • 交付物：发货单、留证照片、运单与保价凭证、到货确认、异常理赔记录
  • 建议模板/表单：发货单（订单号、客户、设备型号、序列号、配件清单逐项、包装方式、承运商、运单号、保价、发货人、发货时间、签收时间、开箱结果）

6. 异常与升级

  • 到货破损/丢件 → 24 小时内取证报理赔，同步交付负责人决定补发 → 升级交付负责人（当天）
  • 物流超时未达 → 每日跟催承运商 → 超 2 天升级行政专员
  • 配件少发/错发 → 3 个工作日内补寄 → 升级交付负责人

7. 衡量指标

  • 保价覆盖率 = 保价发运单数 / 高价值设备发运单数，目标 100%
  • 到货异常率，目标 ≤ 2%
  • 异常补发周期，目标 ≤ 3 个工作日

8. 低效诊断

  • 聊天中未见相关流程，存在高价值设备未保价损坏无法理赔、配件漏发反复补寄的风险（推断）

9. 分支变体

  • 集群/机柜级设备：走专业设备物流或专车，必要时随车人员
  • 渠道发货：发至渠道仓库，由渠道负责末端配送与开箱

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 当前合作物流商与保价规则？是否需要定制防震包装？
  • 发运由交付还是行政执行？
  • 理赔周期内是否先行补发？
X-DLV-42客户现场作业规范（变更确认、操作留痕、备份回退）待新建推断150

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨5 × 险5

  • 适用场景：交付、售后、FDE 人员在客户现场或远程对客户环境做部署、升级、配置变更、数据迁移、断电重启等操作时，事前确认方案与客户同意、事中备份留痕、事后验证并可回退
  • 负责人：主责——交付负责人（当前：待指定）；协同——交付工程师、FDE 工程师、研发值班、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 变更方案与回退方案 → ② 客户确认操作窗口 → ③ 操作前备份 → ④ 按步骤操作并记录 → ⑤ 功能验证 → ⑥ 失败回退 → ⑦ 客户确认 → ⑧ 记录归档
  • 交付结果：客户确认的变更单、操作记录、验证结论
  • 状态依据：已有 X-DLV-32（已交付机升级与回退）、X-DLV-34（交付期现场问题闭环）覆盖部分环节，本条补齐客户环境作业的变更确认、操作留痕与备份回退（推断）

1. 场景判定

  • 触发条件：在客户环境执行部署、升级、配置修改、数据迁移、重启/断电、网络改动
  • 典型说法：「我直接上去改一下配置」「先升级再说，有问题再回退」
  • 判断问题：本次操作是否可能导致客户服务中断或数据丢失？客户是否知情？
  • 不归本流程管：访问客户数据的授权 → 请走 X-CS-28；我方生产环境变更 → 请走 RND-58；现场准入材料 → 请走 X-DLV-26；版本升级推送与回退的具体操作 → 请走 X-DLV-32（本流程管变更单、客户确认与留痕）；交付期故障排查 → 请走 X-DLV-34

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批人 审核变更与回退方案 A 交付负责人（当前：待指定）
操作人 编写方案、备份、操作、记录、验证 R 交付工程师/FDE 工程师（当前：待指定）
研发支持 远程待命、处理异常 C 研发值班（当前：待指定）
销售 与客户确认窗口、通知最终用户 C 客户对接销售（当前：待指定）

3. 办之前请准备

  • 变更内容、影响范围、预计时长
  • 回退方案与回退所需安装包/镜像
  • 客户环境当前版本、配置与数据量

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 编写变更单（步骤、影响、回退方案） 操作人 操作前 1 个工作日 变更模板 变更单 🔧飞书固化
2 审核变更单 交付负责人 提交后 4 小时内 飞书审批 审核结论 🔧飞书固化
3 与客户确认操作窗口并通知最终用户 客户对接销售 操作前 1 个工作日 客户群 客户确认 👤人工判断
4 备份配置、数据与当前版本 操作人 操作开始前 备份工具 备份记录 🤖自动化
5 按步骤操作，记录命令与结果 操作人 窗口内 终端/记录模板 操作记录 👤人工判断
6 按检查项验证（登录、模型、网盘、计费等） 操作人 操作完成后 30 分钟内 检查清单 验证结论 🤖+👤
7 验证失败按回退方案恢复 操作人、研发值班 窗口结束前 备份 回退记录 👤人工判断
8 客户确认结果，记录归档到客户档案 操作人 操作后 1 个工作日内 知识库 归档记录 🔧飞书固化

5. 交付物与模板

  • 交付物：变更单、备份记录、操作记录、验证结论、客户确认
  • 建议模板/表单：客户环境变更单（客户、实例/设备、变更类型、内容、影响范围、窗口、备份方式、回退方案、操作人、审核人、客户确认人、验证结果、是否回退）

6. 异常与升级

  • 回退失败或数据异常 → 立即停止操作，研发值班介入 → 升级交付负责人与研发部门报送人（当时）
  • 超出操作窗口 → 告知客户并确认是否延长 → 升级交付负责人
  • 现场发现与方案不符的环境 → 暂停，重新评估 → 升级交付负责人（当天）

7. 衡量指标

  • 有变更单的客户环境操作占比，目标 100%
  • 变更导致客户故障次数，目标 0
  • 回退成功率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在现场直接改配置无备份、出问题无法回退、客户不知情导致投诉的风险（推断）

9. 分支变体

  • 涉密/国企客户：按客户运维制度执行，必要时客户人员陪同
  • 紧急故障修复：可先口头确认后执行，24 小时内补变更单

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 哪些操作可免变更单（例如只读排查）？
  • 标准验证检查项由谁维护（可并入 X-DLV-36）？
  • 是否需要统一的客户环境操作记录工具？

X-FDE FDE

报送人：待定 · 归属待定 · 23 条 · 已有 0 / 待优化 10 / 待新建 13
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-FDE-01非标客户项目报备与技术留痕市场/销售人员对接到任何非标或定制项目需求（无论最终是否成交）时，在留痕系统报备立项，并把后续方案、报价、案例、交付文档关联归档。主责——FDE Leader/项目部负责人（当前：黄振锋·推断待确认）；协同——各市场/销售负责人（当前：闫登辉、刘昱潇、杨朋伟、吴琪、杜中瑞、时建、朱文瑜·推断待确认）、PRM 开发支撑（当前：裴蔬桐、张康、望政韬·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 识别非标需求 → ② 提交项目开发申请 → ③ 机器人通知 → ④ 受理并分派评估人 → ⑤ 材料文档持续关联 → ⑥ 工时按项目归集 → ⑦ 状态更新与月度核对留痕台（后续为 Leap PRM）中带唯一项目编号的项目记录，挂齐需求、方案、报价、案例、交付文档、研发工时和当前状态。待优化96
X-FDE-02客户需求入口受理与分层分流FDE、客户或内部同事提出新需求（含"许愿机"群许愿）时，按 FDE → 开放平台 → 产研分层确定入口和接单人，禁止绕过分层直接向产研加塞。主责——开放平台负责人（需求统一受理口，当前：郭逸非·推断待确认）；协同——FDE 负责人（当前：李凯·推断待确认）、许愿机项目组总负责人（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、内部需求接单人（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 统一表单提需求 → ② 受理分类 → ③ FDE 层先解 → ④ 开放平台层评估 → ⑤ 产研每周评审 → ⑥ 指定接单人并回执 → ⑦ 状态播报、验收关闭需求池中每条需求都有来源、类型、优先级、接单人、状态；需求方收到受理回执和最终结果。待新建135
X-FDE-03客户需求澄清、可行性评估与技术答复客户提出技术问题、系统打通或新需求（含客户自拟的长篇需求文档）时，由 FDE 澄清范围、验证可行性、编写内部版/外部版文档后统一答复，不提前承诺。主责——FDE 负责人（需求评估，当前：李凯·推断待确认）；协同——项目经理/销售（当前：杨朋伟、闫登辉、刘昱潇·推断待确认）、开放平台（当前：郭逸非·推断待确认）、商务负责人（对外材料审核，当前：常元和·推断待确认）、技术顾问（当前：望政韬·推断待确认）、IT 公共账号管理（当前：游家豪·推断待确认）、总助（第三方资质申请，当前：赵雪冰·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 受理并约定答复时间 → ② 写内部版需求摘要 → ③ FDE 逐项评估 → ④ 索取样例 → ⑤ Demo 验证 → ⑥ 第三方账号/API 登记 → ⑦ 写外部版答复 → ⑧ 商务审核后发送并留痕内部版需求摘要、需求评估单、Demo/录屏（如需）、经审核的外部版答复或需求文档，并关联到 X-FDE-01 项目记录。待新建240
X-FDE-04定制项目技术方案、硬件选型报价与内部审核行业版或本地化部署客户需要技术方案与报价时，设计方案、按并发/模型规模/国产化要求选型硬件并询价，对外发出前经一审、二审。主责——FDE Leader/项目部负责人（方案报价一审，当前：黄振锋·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、方案研发（当前：邓乾·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、开放平台（当前：郭逸非·推断待确认）、硬件/算力评估（当前：杨明学、望政韬·推断待确认）、标品对接（当前：杨萌、王皓南·推断待确认）；兜底——研发负责人/CTO（二审，当前：丁震宇·推断待确认）① 需求清单定稿 → ② 技术路线评估 → ③ 方案初稿 → ④ 硬件选型与询价 → ⑤ 编制报价 → ⑥ AI 预审 → ⑦ 一审/二审 → ⑧ 客户技术确认并留痕经审核的技术方案、硬件 BOM 与报价单、审查报告，对外发送并关联到 X-FDE-01 项目。待优化400
X-FDE-05FDE 人员派驻、调配与项目交接客户场景落地需要 FDE 派驻、项目人手不足、人员转岗或换项目时，申请并安排 FDE 派驻或借调/外包补位，完成背景交接与权限管理；需要引入外包或合作公司人员（驻场或远程）参与研发、测试，涉及协议、工位、账号、仓库权限与交付范围时也走本流程。主责——FDE 部门负责人（人力调配，当前：郭逸非·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、接收方负责人（当前：黄振锋、王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapCore FDE（当前：李凯·推断待确认）、人事负责人（当前：黄莹·推断待确认）、法务负责人（当前：李瑶·推断待确认）、技术对接人（外包监工，当前：岳阳·推断待确认）、权限开通负责人（当前：宋祺睿·推断待确认）、行政（工位，当前：待指定）、财务（付款主体，当前：待指定）；决策——CEO（外包合作形式与付费主体，当前：邴龙志·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提交派驻/借调/外包申请 → ② 查负荷看板选人（外包面试确认）→ ③ 外包确定合作形式与付费主体 → ④ 书面通知接收方与本人 → ⑤ 签协议与保密协议 → ⑥ 外包定首期范围与接口文档 → ⑦ 新任 FDE 模拟交付 → ⑧ 按清单交接 → ⑨ 最小化开通权限与工位 → ⑩ 入场培训 → ⑪ 周更负荷与验收、结束回收已审批的派驻/借调/外包记录、确认回执、已签合作协议与保密协议（外包/借调）、首期范围与接口文档（外包研发）、交接清单、权限开通与回收记录、人力负荷看板更新。待新建192
X-FDE-06客户模型接入与模型路由配置服务客户因合规只能使用自有 API 或本地算力，或希望降低模型成本时，由 FDE 远程/上门接入客户模型、配置各档位路由规则，并出具成本或体验影响说明。主责——LeapCore 网关/标品技术负责人（当前：王皓南·推断待确认）；协同——模型网关实施（当前：柯逸飞·推断待确认）、adapter 开发（当前：宋祺睿·推断待确认）、Agent 约束（当前：岳阳·推断待确认）、商务（当前：闫登辉、杨萌·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 售前识别 → ② 客户填信息表 → ③ 适配评估 → ④ 降本测算（如需）→ ⑤ 商务确认与知情书 → ⑥ 配置路由/代理 → ⑦ 测试切换 → ⑧ 交接归档入台账客户模型接入台账记录、适配评估单、路由配置（含防覆盖脚本）、测试记录、handoff 文档；降本场景另附成本节省说明。待新建300
X-FDE-07客户业务系统数据对接的授权与限流需要对接客户内部业务系统（如投管系统、数据库）读写业务数据时，先取得书面授权、明确读写范围与限流策略，再接入并全程留痕。主责——FDE 项目技术负责人（当前：邓乾·推断待确认）；协同——项目经理（当前：杨朋伟·推断待确认）、开放平台（当前：郭逸非·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、安全/法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 取得书面授权 → ② 确认接入方式 → ③ 并发与限流设计 → ④ 鉴权设计 → ⑤ 安全评审 → ⑥ 最小化取数并登记 → ⑦ 写回经客户确认 → ⑧ 缺陷沟通与结项处置客户书面授权、接入确认单、流量调度与鉴权设计、客户数据访问日志、项目结束的数据处置记录。待新建150
X-FDE-08定制 Skill 需求承接、评估定价与交付跟进客户或内部同事提出定制 Skill 需求、内部发现可产品化的好用场景时，统一受理、查重、评估工作量与定价、排期开发、适配测试并交付跟进。主责——产品总监（Skill 需求统筹，当前：杨萌·推断待确认）；协同——Skill 交付研发（当前：邓乾·推断待确认）、Skill 开发/业务专家（当前：王满、王蕊·推断待确认）、适配测试（当前：佘天禾·推断待确认）、客户对接销售（当前：刘昱潇、杨朋伟·推断待确认）、Skill 负责人/运营（当前：李凯·推断待确认）、Skill 开发（当前：李铭熙、马漳毓、裴蔬桐·推断待确认）、容器环境（当前：岳阳、宋祺睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 提交 Skill 需求单 → ② 查重复用 → ③ 评估工作量与依赖 → ④ 定价或定优先级 → ⑤ 指派开发 → ⑥ 按规范提交 → ⑦ 适配测试与补依赖 → ⑧ 内置/交付并跟进反馈Skill 需求池记录、评估单与报价审批、符合格式规范的 Skill 包与测试记录、上架/交付记录及反馈结论。待优化180
X-FDE-09行业版 Skill/插件提交审核、开放平台上架与下发FDE、行业团队、客户或第三方 SaaS 开发完成 Skill/MCP/插件，需要经 LeapOpen 开放平台审核后，按全局/行业/企业/部门范围上架或下发到客户 LeapCore 实例时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——开放平台账号与架构（当前：吴亚军·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、插件规范与开发辅导（当前：邓乾·推断待确认）、LeapCore 接入研发（当前：杨云峰、柯逸飞·推断待确认）、行业版 Skill 开发 FDE（当前：李凯、陈锦杰、季学森·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开通开发者账号/Developer Key → ② 按 LeapSkill/插件规范开发并自检 → ③ 打包提交 LeapOpen → ④ lint+Agent 初审 → ⑤ 中高风险人工二审 → ⑥ 发布并设定可见范围 → ⑦ 客户侧验证安装运行 → ⑧ 上线抽检与迭代通过审核、带签名和版本号的 Skill/插件包，已按指定 scope 对目标企业/行业可见，并在客户 LeapCore 上验证可安装可运行；下发记录可查待优化180
X-FDE-10OpenClaw/龙虾/龙智一体机部署配置交付政企客户、企业老板或俱乐部客服场景购买或要求部署 OpenClaw 智能体（龙虾）/龙智旗舰版，需要定制配置（人设、飞书多机器人、模型 Key、Skill 包、启动脚本）并接入客户工作流时启动主责——部署交付工程师（当前：游家豪、魏宗浩·推断待确认）；协同——客户经理/销售（当前：吴琪、李鹏为、闫登辉·推断待确认）、专属 FDE（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 订单与需求确认 → ② 部署方式与资源决策 → ③ 环境准备（镜像/版本/模型 Key）→ ④ 配置人设、飞书机器人与 Skill 包 → ⑤ 内部全量验收 → ⑥ 交付（上门/寄送/安装包）→ ⑦ 需求沟通会与工作流接入 → ⑧ 经验入踩坑库客户可用的 OpenClaw/龙智实例（版本固定、模型 Key 归属客户、飞书/微信通道可用），部署清单与交付确认记录，需求优先级清单与会议纪要，踩坑库更新待新建300
X-FDE-11客户试点开通、驻场陪跑与分层培训行业版进入客户试点、客户部署后“不会用”、或客户高层/政府单位需要授课时，开通席位、分层培训并安排 FDE 驻场陪跑主责——FDE 子部门负责人（当前：李凯·推断待确认）；协同——产品总监/试点统筹（当前：杨萌·推断待确认）、客户经理（当前：吴琪、闫登辉、杜中瑞·推断待确认）、驻场 FDE（当前：王满·推断待确认）、部署交付工程师（当前：游家豪·推断待确认）、人事（驻场打卡，当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 试点立项与 FDE 指派 → ② 客户需求调研 → ③ 开通席位并分配 → ④ 交付当天基础操作教学 → ⑤ 分层正式培训 → ⑥ 驻场陪跑与需求评审 → ⑦ 反馈汇总回流开发 → ⑧ 试点复盘已开通并分配的席位清单、各部门需求调研表、培训记录与资料、驻场周报、试点反馈清单与复盘结论待新建180
X-FDE-12FDE/开发者 LeapCore 调试环境与额度发放开放平台批准插件开发者入驻，或 FDE 开始真实开发，需要一个 LeapCore 调试环境和模型额度时启动主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——云资源与运维（当前：宋祺睿·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、模型网关与渠道（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；额度政策终裁——CEO（当前：邴龙志·推断待确认）① 开发者入驻审批通过 → ② 提交环境申请 → ③ 判定环境类型与名额 → ④ 创建云端实例并发 VPN → ⑤ 发放赠送额度 → ⑥ 讲解插件调试方法 → ⑦ 登记台账 → ⑧ 到期回收开发者可登录的 LeapCore 调试实例（或本地 mock 环境）、VPN 账号、到账的赠送额度，以及环境与额度台账待新建24
X-FDE-13内部 FDE 需求挖掘、开发与验收公司内部 FDE 计划推进中各部门挖掘 AI 场景，或业务部门提出内部系统需求（合同、积分、CMS、CRM、考勤、采购等），需要澄清、开发 Skill 或业务系统并验收时启动主责——内部 FDE 统筹（当前：杨萌·推断待确认）；协同——需求评估与 Skill 验收（当前：佘天禾·推断待确认）、FDE 子部门负责人/产品设计（当前：李凯·推断待确认）、内部 FDE 开发（当前：裴建武、陈子康、邓乾、郭逸非·推断待确认）、部署运维（当前：杨睿·推断待确认）、业务拍板人（当前：田杰、赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、各部门 FDE；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；方向发起——CEO（当前：邴龙志·推断待确认）① 统一入口提需求 → ② FDE 追问澄清并画业务流程图 → ③ 分级与采纳评估 → ④ 指定负责人与排期 → ⑤ AI 拆工单并群内评审 → ⑥ 开发（Skill 或系统 MVP）→ ⑦ preview 部署与业务验收 → ⑧ 每日进度同步与按天迭代带分级和负责人的需求台账；业务确认的流程图与需求文档（需求描述＋技术约束）；通过验收的 Skill 或上线的内部系统；测试验收记录；每日进度汇总文档待优化300
X-FDE-14内部 FDE 成果评测与阶段性案例收集部门 Skill 通过验收后需验证改进效果并与竞品对比，或内部 FDE 进入阶段性周报（每周功能点对比与场景化案例）时启动主责——FDE 成果归集专员（当前：佘天禾·推断待确认）；协同——FDE 评测（当前：盛亦舒·推断待确认）、内部 FDE 统筹（当前：杨萌·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）、市场内容（当前：韩诗琪、许君·推断待确认）、各部门 FDE；兜底——CEO（当前：邴龙志·推断待确认）① 已验收 Skill 进入评测 → ② 前测后测并录屏 → ③ 与竞品对比 → ④ 结果入表并派优化 → ⑤ 收敛 Skill 输出后重测 → ⑥ 各部门按周提交功能点与案例 → ⑦ 自动统计缺口并提醒 → ⑧ 优秀案例转市场与产品评测多维表格（前后测与竞品对比结论、录屏链接）；每周各部门功能点对比、3 好 3 坏评价、场景化案例；案例转市场推文与产品改进的清单待优化90
X-FDE-15内部 FDE 与 LeapCore 培训组织及补课新工具/新能力上线、内部 FDE 阶段启动，或部分同事错过培训需要补课时，组织面向内部员工的 FDE/LeapCore 培训主责——FDE 培训主讲（当前：李凯·推断待确认）；协同——内部 FDE 统筹（当前：杨萌·推断待确认）、培训 QA 整理（当前：佘天禾·推断待确认）、研发负责人（研发参训点名，当前：丁震宇·推断待确认）、各部门 FDE；兜底——CEO（发起人，当前：邴龙志·推断待确认）① 确定主题与对象 → ② 约时间与会议室并发日程 → ③ 授课并录制妙记 → ④ 发资料包 → ⑤ 布置作业与成果展示 → ⑥ 缺课补课 → ⑦ 培训总结入 wiki培训录像与妙记纪要、资料包（PDF、教程 wiki、skill 压缩包）、参训与缺课名单、作业与成果展示记录、培训总结 wiki待优化60
X-FDE-16FDE 课程体系开发与评审面向渠道、合作伙伴、政府、高校需要分级（初/中/高级）FDE 课程，或具体开班前课程内容（PPT、实操任务、Skill 制作）需要开发与评审时启动主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——FDE 课程体系设计（当前：李凯·推断待确认）、中级大纲与讲师（当前：郭逸非·推断待确认）、高级课程（当前：黄振锋·推断待确认）、讲师（当前：陈子康、张家瑞·推断待确认）、宣传与活动（当前：陈梦琪·推断待确认）、课程框架与标准底座（当前：丁震宇·推断待确认）；兜底——CEO（需求方与终审，当前：邴龙志·推断待确认）① 需求方填课程需求单 → ② 出初版框架 → ③ 专家/开放平台研讨定稿 → ④ 讲师开发课件与实操任务（先自跑一轮）→ ⑤ 按检查表评审 → ⑥ 试讲与设备测试 → ⑦ 开课 → ⑧ 课后回流更新标准版分级课程体系文档（标准版＋本期定制版）、课件 PPT、实操任务 spec 说明书、讲稿与主持稿、评审记录、教学资料包（入 FDE 课程仓库）待优化240
X-FDE-17FDE 培训班筹备与开课保障外部 FDE 培训班（官方认证班、线下百人班、高校实训课）开课日期确定后，从立项到首课开讲、再到课后账单收口的全部筹备与保障工作。主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——培训技术统筹（当前：王皓南·推断待确认）、开放平台后端/权限（当前：杨睿·推断待确认）、交付/IT 现场支持（当前：李奎星、杨云峰·推断待确认）、IT 网络（当前：杨明学·推断待确认）、会务（当前：丁蕊·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态组（当前：陈梦琪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 立项建群定 DDL → ② 名单锁定与筛选 → ③ 师资/助教排班 → ④ 会场勘察与网络验收 → ⑤ 平台/账号/额度开通 → ⑥ 课前彩排与预案 → ⑦ 发通知并开课值守 → ⑧ 课后账单与复盘按期开课、现场环境可用的一期培训班，以及锁定名单、助教排班表、会场验收记录、账号开通台账、应急预案、培训通知、课后账单与复盘纪要。待新建250
X-FDE-18培训现场问题与学员反馈收集FDE 培训班/实训课/内部初级 FDE 培训会进行期间，需要课堂出题、收集学员现场问题（远程访问失效、文件被占用、下载挂起等）与课后反馈，并转产研修复。主责——培训班主任/AI 讲师（当前：张家瑞·推断待确认）；协同——助教/讲师（当前：梅立、杜中瑞、吴琪、李奎星·推断待确认）、产品负责人（当前：杨萌·推断待确认）、现场 oncall 研发（当前：宋祺睿、杨云峰·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 课前指定出题人与反馈表 → ② 课前环境验证 → ③ 现场登记问题 → ④ 研发判定已知/新问题 → ⑤ 现场权宜处理 → ⑥ 当日提 bug → ⑦ 课后汇总反馈与调研报告 → ⑧ 回复学员并纳入下期改进课堂题目、现场问题登记表（含诊断日志）、对应 bug 工单、课后反馈汇总与调研报告、下期改进项清单。待新建90
X-FDE-19FDE 认证考试与结课发证学员完成 FDE 初级班课程后，组织认证考试、审核成绩并颁发初级 FDE 证书；中高级认证沿用同一流程。主责——培训班主任/题库负责人（当前：张家瑞·推断待确认）；协同——FDE 课程负责人/开放平台（当前：吴亚军·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、生态组（当前：陈梦琪·推断待确认）、讲师（当前：郭逸非·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）① 题库设计 → ② 内部试做校验 → ③ 公布认证规则 → ④ 学员上传 Skill 并答题 → ⑤ 成绩汇总与人工复核 → ⑥ 收集邮箱并审核名单 → ⑦ 生成并邮件发证 → ⑧ 申诉处理与归档通过名单、成绩记录、已发放的初级 FDE 电子证书、申诉处理记录。待优化120
X-FDE-20内部业务系统上线内测、业务验收与发布内部自研系统（CRM、渠道系统、合同、采购等）开发完成或出新版本后，组织按岗跑测、Agent/E2E 测试提单、账号开通与使用培训、业务方验收，并发布到预览/正式环境。主责——内部系统负责人（当前：郭逸非、陈子康·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、总经办（当前：王欣、田杰·推断待确认）、各业务角色代表（销售：闫登辉、吴琪；IT：杨明学、游家豪；财务：黄梦婷；合规：赵雪冰·推断待确认）、后端/权限（当前：宋祺睿、杨睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 开发自测与 E2E → ② 出验收报告与手册 → ③ 发布预览环境并分配角色账号 → ④ 按岗跑测 + Agent 测试提单 → ⑤ 问题分级修复与复测 → ⑥ 业务验收与培训 → ⑦ 正式发布与账号开通 → ⑧ 常态化反馈业务方确认的验收记录、更新后的用户手册、正式环境可用的系统版本与已开通账号、版本更新通知、反馈表进入常态化运转。待优化240
X-FDE-21定制交付成果复用沉淀与知识产权归属确认FDE 为客户开发的 Skill、工作流、提示词、插件、脚本或行业方案交付后，确认知识产权归属与可复用范围，把可复用部分脱敏入公司资产库主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、产品经理、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 签约前约定 IP 归属 → ② 交付后成果盘点 → ③ 判定可复用范围 → ④ 脱敏与通用化 → ⑤ 入资产库 → ⑥ 评估产品化 → ⑦ 记录复用次数成果盘点表、IP 归属结论、入库的通用资产、产品化建议待新建96
X-FDE-22客户数据带离现场与开发使用审批FDE、交付、产品为开发定制 Skill、调试提示词、做评测或训练需要把客户提供的样例文件、业务数据、对话记录带回公司或上传到外部模型时，先取得授权、脱敏，限定用途并在用后销毁主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、客户对接销售、研发值班（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 识别数据与用途 → ② 客户书面授权 → ③ 内部登记审批 → ④ 脱敏 → ⑤ 指定位置存放 → ⑥ 限定用途使用 → ⑦ 到期销毁 → ⑧ 销毁确认客户授权记录、数据登记、脱敏记录、销毁确认待新建120
X-FDE-23FDE 工时登记与项目成本核算FDE 人员投入客户项目、售前 Demo、内部 FDE 与培训时，按项目登记工时，月度核算项目人力成本与收入对比，为报价校准与人员调配提供依据主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、财务专员、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 项目编码建立 → ② 每周登记工时 → ③ 周度核对 → ④ 月度汇总成本 → ⑤ 对比报价与收入 → ⑥ 偏差复盘与报价校准项目工时表、月度项目成本报表、报价校准建议待新建72
X-FDE-01非标客户项目报备与技术留痕待优化96

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：市场/销售人员对接到任何非标或定制项目需求（无论最终是否成交）时，在留痕系统报备立项，并把后续方案、报价、案例、交付文档关联归档。
  • 负责人：主责——FDE Leader/项目部负责人（当前：黄振锋·推断待确认）；协同——各市场/销售负责人（当前：闫登辉、刘昱潇、杨朋伟、吴琪、杜中瑞、时建、朱文瑜·推断待确认）、PRM 开发支撑（当前：裴蔬桐、张康、望政韬·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别非标需求 → ② 提交项目开发申请 → ③ 机器人通知 → ④ 受理并分派评估人 → ⑤ 材料文档持续关联 → ⑥ 工时按项目归集 → ⑦ 状态更新与月度核对
  • 交付结果：留痕台（后续为 Leap PRM）中带唯一项目编号的项目记录，挂齐需求、方案、报价、案例、交付文档、研发工时和当前状态。
  • 状态依据：已有飞书「项目开发申请填写 SOP」、填写入口和「客户项目技术留痕台」机器人，约 20 余个项目经此提交；但 2026-07～10 群内反复出现"不走 SOP 就混乱""必须严格遵守 SOP"的提醒，存在通知范围不够、附件被消息挤掉找不到、迁移进度反复追问等问题，且审计要求研发工时对应到项目，因此判定待优化。

1. 场景判定

  • 触发条件：客户提出标品之外的定制开发、本地化部署、行业版定制、软硬件整包等需求；首次正式对接后即触发，不以成交为前提。
  • 典型说法：「走 SOP」「都进 SOP」「这种项目都得留痕」「不走 SOP 肯定混乱」
  • 判断问题：这个需求是否需要研发/FDE 投入工时，或需要出方案、报价？如果需要，必须先有项目编号。
  • 不归本流程管：
    • 标品直接售卖、无任何定制 → 走销售订单流程
    • 需求入口分流与接单 → 请走 X-FDE-02
    • 需求澄清、可行性评估与技术答复 → 请走 X-FDE-03
    • 方案、硬件选型报价与内部审核 → 请走 X-FDE-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
市场/销售负责人 识别需求、提交项目开发申请、更新商务状态 R 销售/客户经理（当前：闫登辉、刘昱潇、杨朋伟、吴琪、杜中瑞、时建、朱文瑜·推断待确认）
FDE Leader 维护留痕体系、受理申请、分派评估人、月度核对 A FDE Leader/项目部负责人（当前：黄振锋·推断待确认）
技术统筹 关键项目评估与审核、跨项目资源决策、流程兜底 C 研发负责人/CTO（当前：丁震宇·推断待确认）
PRM 开发支撑 留痕系统迁移、PRM 功能开发与运维 R（系统） 研发（当前：裴蔬桐、张康、望政韬·推断待确认）
财务 按项目编号归集研发工时与费用，对接审计 I 财务负责人（当前：待指定）
项目相关研发/FDE 接收通知、按项目登记工时、上传产出 I 项目研发（当前：待指定）

3. 办之前请准备

  • 客户代号、行业、签约主体（模态/鼎慧/跃迁等）
  • 需求简述（3～5 句：做什么、为什么、期望时间）
  • 市场负责人、客户侧对接人岗位、预计规模档位（人天或金额区间档）
  • 已有材料：客户需求文档、会议纪要、截图（附件或链接）
  • 项目类型初判：纯项目制 FDE / LeapCore 产品 FDE

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别为非标需求，填写「项目开发申请」（客户、需求、负责人、类型、附件） 市场/销售负责人 首次正式对接后 1 个工作日内 飞书表单 → Leap PRM 项目开发申请记录 🔧飞书固化
2 机器人推送"新项目开发申请"卡片到核心项目群，@ 技术负责人、项目相关人及知会名单 留痕台机器人 提交后即时 留痕台机器人 群通知卡片 🤖自动化
3 受理：确认项目类型、生成项目编号、指定评估人并在卡片下回复 FDE Leader 通知后 1 个工作日内 留痕台/PRM 项目编号、评估人 👤人工判断
4 方案、报价、案例、审查报告、交付文档定稿后通过「材料文档录入」关联项目 文档产出人 文档定稿当天 材料文档录入表单 项目关联材料记录 🔧飞书固化
5 机器人推送"新增材料文档"卡片 留痕台机器人 录入后即时 留痕台机器人 群通知卡片 🤖自动化
6 研发/FDE 按项目编号登记工时 项目相关研发 每周五下班前 工时表/PRM 项目工时记录 🔧飞书固化
7 更新项目状态（评估中/报价中/成交/搁置/关闭） 市场/销售负责人 状态变化当天 留痕台/PRM 最新状态 🔧飞书固化
8 月度核对：项目清单对照合同、报价、工时，补漏并通报未报备项目 FDE Leader 每月 5 日前 PRM 报表 月度留痕核对表 🔧+🤖

5. 交付物与模板

  • 交付物：项目开发申请记录、项目关联材料清单、项目工时记录、月度留痕核对表。
  • 建议模板/表单：
    • 项目开发申请：项目编号（自动）、客户代号、行业、签约主体、项目类型、需求简述、市场负责人、技术评估人、预计规模档位、期望时间、附件、知会人。
    • 材料文档录入：项目编号、材料类型（方案/报价/案例/审查报告/交付文档/合同）、版本号、作者岗位、链接、是否已对外发送、发送日期。

6. 异常与升级

  • 未报备就已投入研发工时 → 市场负责人 1 个工作日内补报，工时补挂项目编号 → 超期未补升级 FDE Leader，并在月度核对中通报
  • 附件/文档被群消息刷掉找不到 → 一律从留痕台/PRM 按项目编号检索，不在群里重复索要 → 系统中缺失的报 PRM 开发支撑，2 个工作日内补齐
  • 迁移期间飞书留痕台与 PRM 数据不一致 → 迁移完成前双写，以飞书留痕台为准 → 差异超过 3 条升级 CTO
  • 项目负责人被临时抽调、项目无人 owner → FDE Leader 2 个工作日内指定接替人 → 无法指定的升级 CTO
  • 机器人未推送 → 提交人在群里手动 @ 相关人并贴链接 → 当天报 PRM 开发支撑

7. 衡量指标

  • 报备及时率 = 首次对接后 1 个工作日内提交申请的项目数 / 新增非标项目数，目标 ≥ 90%
  • 材料留痕完整率 = 已关联方案和报价的成交项目数 / 成交项目数，目标 100%
  • 工时-项目映射率 = 挂有项目编号的非标项目研发工时 / 非标项目研发总工时，目标 100%（审计口径）
  • 受理时长 = 申请提交到指定评估人的工作日数，目标 ≤ 1 天

8. 低效诊断

  • 现象：通知只覆盖项目负责人，相关非负责人不知道项目存在，事后重复沟通（环节：通知范围）｜依据：「核心项目群」2026-07
  • 现象：附件和文档靠群消息传递，被后续消息挤到底部找不到（环节：材料归档）｜依据：「核心项目群」2026-08
  • 现象：项目量增长后飞书审批+机器人承载吃力，迁移 PRM 的进度被反复追问（环节：系统承载）｜依据：「核心项目群」2026-09、「核心项目群」2026-10
  • 现象：迁移中重复新建代码仓库，系统建设口径不统一（环节：系统建设）｜依据：「核心项目群」2026-10
  • 现象：项目负责人被抽调后项目无人 owner（环节：受理与分派）｜依据：「核心项目群」2026-09
  • 现象：审计到场时才强调严格执行，日常执行依赖口头提醒（环节：全流程）｜依据：「核心项目群」2026-08

9. 分支变体

  • 纯项目制 FDE（独立客户定制项目）：走本流程完整留痕。
  • LeapCore 产品 FDE（标品实施）：目前归档路径不同，由 LeapCore FDE 负责人归口，计划后期合并到同一 PRM。
  • 迁移完成后：销售只与 Leap PRM 一个系统交互，PRM 承接"项目打分—报价生成—进度管理"，并与需求报价方案 Agent 打通；底线是系统或 Agent 故障时仍可人工走完全部流程。

10. 待确认问题

  • 主责是否为 FDE Leader？LeapCore 产品 FDE 线由谁对接本流程？
  • "首次对接后 1 个工作日内报备"是否可行？是否需要设报备门槛（如预计投入人天）？
  • 知会名单（非负责人也应知道）具体包括哪些岗位？
  • 飞书留痕台迁移到 Leap PRM 的截止时间？迁移期间以哪个系统为准？
  • 研发工时登记口径（周报还是 PRM 内登记）是否已与财务、审计对齐？
  • 未报备项目的处理规则是否需要写入正式制度？
X-FDE-02客户需求入口受理与分层分流待新建135

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗3 × 跨5 × 险3

  • 适用场景：FDE、客户或内部同事提出新需求（含"许愿机"群许愿）时，按 FDE → 开放平台 → 产研分层确定入口和接单人，禁止绕过分层直接向产研加塞。
  • 负责人：主责——开放平台负责人（需求统一受理口，当前：郭逸非·推断待确认）；协同——FDE 负责人（当前：李凯·推断待确认）、许愿机项目组总负责人（当前：黄振锋·推断待确认）、产品总监（当前：杨萌·推断待确认）、内部需求接单人（当前：陈子康·推断待确认）、销售（当前：时建·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 统一表单提需求 → ② 受理分类 → ③ FDE 层先解 → ④ 开放平台层评估 → ⑤ 产研每周评审 → ⑥ 指定接单人并回执 → ⑦ 状态播报、验收关闭
  • 交付结果：需求池中每条需求都有来源、类型、优先级、接单人、状态；需求方收到受理回执和最终结果。
  • 状态依据：分层入口规则只有口头约定（2026-07），实际仍有 FDE 直接向产研加塞；2026-10 新建的许愿机群首日即出现提需求者"下错平台"、接单人临时口头指定的情况，入口、受理标准、排期、验收都没有，因此判定待新建。

1. 场景判定

  • 触发条件：任何人提出需要开发、配置或定制的新需求（产品功能、Skill、UI 定制、案例/演示、内部工具等）。
  • 典型说法：「FDE 先跟开放平台对，开放平台再跟你们对，不要 FDE 直接跟产研对」「甲方许愿 → 许愿机 → 给他交付」「他一直跟我对需求，给我这边加塞」
  • 判断问题：需求是谁提的（外部甲方/内部同事/FDE）？是否必须改产品？只是现有能力配置或 Skill 的，能否在 FDE 或开放平台层解决？
  • 不归本流程管：
    • 非标项目立项留痕 → 请走 X-FDE-01
    • 需求澄清、可行性评估与技术答复 → 请走 X-FDE-03
    • 定制 Skill 评估定价与交付 → 请走 X-FDE-08
    • 已上线产品的缺陷与客诉 → 请走 X-CS-05（客户问题受理、分流与工单流转）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
统一受理口 分类、分流、去重、维护需求池、回执需求方 A 开放平台负责人（当前：郭逸非·推断待确认）
FDE 第一层处理：配置、Skill、现有能力解决；客户需求向上转交 R FDE 负责人（当前：李凯·推断待确认）
许愿机项目组 承接外部甲方许愿需求 R 项目组总负责人（当前：黄振锋·推断待确认）
内部 FDE 承接内部同事的工具类需求 R 内部需求接单人（当前：陈子康·推断待确认）
产研评审 每周评审、定优先级、决定是否进迭代 C 产品总监（当前：杨萌·推断待确认）
销售/需求方 按表单提交、补充信息、验收 R 销售（当前：时建·推断待确认）；其他提需求同事（当前：待指定）
兜底 分层规则制定、争议与插队裁决 C 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求描述：使用场景、现状、期望效果（最好附截图或样例）
  • 需求方身份：外部甲方（客户代号）/ 内部同事（部门）/ FDE 转交
  • 是否关联已立项项目（X-FDE-01 项目编号）
  • 期望完成时间；如要求插队，写明紧急理由和影响
  • 类型初判：产品功能 / Skill / UI 定制 / 案例演示 / 内部工具

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写「需求受理表单」（群内许愿也需补填） 需求方 提出当天 飞书表单/多维表格需求池 需求记录 🔧飞书固化
2 受理分类并分流：外部甲方许愿 → 许愿机项目组；内部需求 → 内部 FDE 群；客户产品/配置需求 → FDE；Skill 定制 → X-FDE-08；同类需求去重合并 统一受理口 提交后 1 个工作日内 多维表格 分类与去向 🤖+👤
3 FDE 判断能否用现有能力、配置或 Skill 解决，能则直接承接 FDE 分派后 2 个工作日内 需求池 处理方案或上转 👤人工判断
4 FDE 层解决不了的，开放平台评估平台/插件层能否解决；必须改产品的整理成产研需求卡 开放平台 上转后 3 个工作日内 需求池 产研需求卡 👤人工判断
5 产研需求评审：定优先级，进入迭代或拒绝；未经评审不得插入当前迭代 产品总监 每周固定评审会 飞书项目/需求池 评审结论 👤人工判断
6 指定接单人，机器人向需求方回执接单人、预计时间、能否承诺（不保证能做的需写明） 统一受理口 分派或评审后当天 需求池机器人 受理回执 🔧+🤖
7 状态变化自动播报；交付后需求方验收并关闭 接单人、需求方 交付后 3 个工作日内验收 多维表格+机器人 关闭记录 🔧+🤖
8 月度统计各入口需求量、插队次数、关闭周期，供绩效管理系统使用 统一受理口 每月 5 日前 多维表格仪表盘 需求月报 🤖自动化

5. 交付物与模板

  • 交付物：需求池记录、受理回执、产研评审结论、需求月报。
  • 建议模板/表单（需求受理单）：需求编号、提交日期、需求方类型、需求方部门/客户代号、关联项目编号、需求类型、场景描述、期望效果、附件、期望时间、紧急理由、分流去向、接单人、优先级、状态（待受理/处理中/评审中/开发中/待验收/已关闭/不承接）、关闭日期、验收结论。

6. 异常与升级

  • 客户交付受阻需要插队 → 受理口确认影响后报产品总监，24 小时内决定 → 有争议升级 CTO
  • 绕过入口直接找产研提需求 → 产研不接，退回受理口登记 → 同一来源每月超过 2 次，升级 CTO 通报
  • 需求提到了错误的群或平台 → 受理口当天转到正确入口并告知需求方 → 无
  • 需求超出能力或明显需付费定制 → 告知需求方不直接承接，转 X-FDE-03 评估 → 涉及客户承诺的升级 FDE 负责人
  • 开放平台与产研层级对不上、多头对需求 → 以需求池记录为唯一口径 → 组织归属问题升级 CTO

7. 衡量指标

  • 受理时长 = 提交到完成分类分流的工作日数，目标 ≤ 1 天
  • 插队次数 = 每月未经评审插入迭代的需求数，目标 0
  • 回执率 = 已发受理回执的需求数 / 提交需求数，目标 100%
  • 需求关闭周期 = 提交到关闭的自然日中位数，按类型统计，目标由产品总监设定

8. 低效诊断

  • 现象：分层规则仅口头约定，开放平台组织上挂在 FDE 下，需求仍由 FDE 直接加塞给产研（环节：入口分层）｜依据：「鼎慧产研决策部」2026-07
  • 现象：开放平台与产研的需求层级对不上，同一需求多头对接（环节：评估）｜依据：「鼎慧产研决策部」2026-07、「鼎慧产研决策部」2026-08
  • 现象：案例、演示、白皮书类需求同样入口混乱（环节：入口）｜依据：「鼎慧产研决策部」2026-08
  • 现象：提需求者不知道该在哪提，提到了错误的群（环节：入口）｜依据：「AI项目许愿机2.0」2026-10
  • 现象：接单人靠群内临时口头指定，无排期与验收标准（环节：分派）｜依据：「AI项目许愿机2.0」2026-10

9. 分支变体

  • 外部甲方许愿 → 许愿机项目组（分工：总负责、算法、工程、运维兼开发、全栈、销售）。
  • 内部同事需求（如考勤统计等工具需求）→ 内部 FDE 群受理。
  • Skill 层级/分类需求 → X-FDE-08。
  • UI 定制需求 → FDE 先出页面方案，再由研发评审发版。
  • 案例/演示/白皮书需求 → 走市场案例流程，不进入产研迭代。

10. 待确认问题

  • 统一受理口是开放平台还是 FDE？开放平台与 FDE 的组织隶属是否调整？
  • 需求池用多维表格还是飞书项目？是否与产研现有需求池合并？
  • 每周产研需求评审会的时间与主持人？
  • "紧急插队"的判定标准与审批人？
  • 许愿机群的需求是否纳入绩效管理系统？口径如何？
X-FDE-03客户需求澄清、可行性评估与技术答复待新建240

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：客户提出技术问题、系统打通或新需求（含客户自拟的长篇需求文档）时，由 FDE 澄清范围、验证可行性、编写内部版/外部版文档后统一答复，不提前承诺。
  • 负责人：主责——FDE 负责人（需求评估，当前：李凯·推断待确认）；协同——项目经理/销售（当前：杨朋伟、闫登辉、刘昱潇·推断待确认）、开放平台（当前：郭逸非·推断待确认）、商务负责人（对外材料审核，当前：常元和·推断待确认）、技术顾问（当前：望政韬·推断待确认）、IT 公共账号管理（当前：游家豪·推断待确认）、总助（第三方资质申请，当前：赵雪冰·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 受理并约定答复时间 → ② 写内部版需求摘要 → ③ FDE 逐项评估 → ④ 索取样例 → ⑤ Demo 验证 → ⑥ 第三方账号/API 登记 → ⑦ 写外部版答复 → ⑧ 商务审核后发送并留痕
  • 交付结果：内部版需求摘要、需求评估单、Demo/录屏（如需）、经审核的外部版答复或需求文档，并关联到 X-FDE-01 项目记录。
  • 状态依据：2026-07 已宣布"先写内部版再写外部版""发客户的所有材料先过商务"的规则，但没有模板和审批节点；技术口径集中在少数技术骨干，前期口径与评估结论不一致、公共第三方账号无人管的问题反复出现，因此判定待新建。

1. 场景判定

  • 触发条件：客户或销售提出"能不能做""怎么接入""多久能做"类问题；客户发来需求文档；需求涉及外部接口、第三方 API 或资质。
  • 典型说法：「先研究这些需求，哪些能搞、哪些不能搞、哪些需要接口配合」「以后应该先写一版内部版，再基于内部版写外部版」「发客户所有材料之前先问一遍」
  • 判断问题：这个问题能否用已有标准答复直接回答？如果不能，是否涉及范围、工期、价格承诺？涉及的就必须先评估再答复。
  • 不归本流程管：
    • 需求入口与接单分流 → 请走 X-FDE-02
    • 评估通过后的方案设计、硬件选型与报价 → 请走 X-FDE-04
    • 定制 Skill 的评估定价 → 请走 X-FDE-08
    • 已交付客户的售后技术问题 → 请走 X-CS-05（客户问题受理、分流与工单流转）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
FDE 评估负责人 逐项评估可行性、技术路线、Demo 验证 A FDE 负责人（当前：李凯·推断待确认）
项目经理/销售 受理、写内部版和外部版、向客户索取样例、发送答复 R 项目经理/销售（当前：杨朋伟、闫登辉、刘昱潇·推断待确认）
开放平台 评估平台/API/插件层可行性 R 开放平台负责人（当前：郭逸非·推断待确认）
商务审核 对外材料发出前审核口径与承诺，可退回修改 C（发送前必审） 商务负责人（当前：常元和·推断待确认）
技术顾问 复杂技术问题口径把关 C 技术骨干（当前：望政韬·推断待确认）
IT/总助 公共第三方账号归集、外部资质申请 R（账号） IT 运维（当前：游家豪·推断待确认）、总助（当前：赵雪冰·推断待确认）
兜底 边界原则、口径分歧裁决 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 客户原始需求（文档、聊天记录摘要、会议纪要）
  • 客户现有系统情况：系统名称类别、是否开放 API、是否有测试环境、接口文档
  • 样例数据：询价单、图纸、合同/标书模板等（脱敏后）
  • 客户期望时间、预算档位、是否已有口头承诺
  • X-FDE-01 项目编号（未报备的先补报）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 受理并回复客户"已收到、评估中"，约定答复日期；不当场承诺能做、工期、价格 项目经理/销售 收到当天 飞书 受理回复 👤人工判断
2 编写内部版需求摘要：目标、范围、不做项、需技术产品提供的支持、数据与接口条件；客户长文档先用 AI 压缩出要点 项目经理 2 个工作日内 飞书文档模板 + AI 内部版需求摘要 🔧+🤖
3 逐项评估：能做 / 不能做 / 需接口配合 / 需外部付费 API / 需业务专家；标注技术路线（官方 API、OCR、Skill、MCP） FDE 评估负责人、开放平台 内部版完成后 3 个工作日内 需求评估单 需求评估单 👤人工判断
4 向客户索取缺失样例（询价单、图纸、API 信息、测试账号） 项目经理 评估中发现缺口当天 飞书 样例资料 👤人工判断
5 做 Demo/录屏验证，标明"验证用，不代表生产可用" FDE 评估负责人 样例到位后 5 个工作日内 Demo 环境 Demo/录屏 🤖自动化
6 涉及第三方账号、商家应用资质、外部 API：账号归集 IT 管理并登记台账；API 费用按毛利规范计价 IT 运维、总助 发现需求后 1 个工作日内登记 第三方账号台账 台账记录 🔧飞书固化
7 编写外部版答复/需求文档：只承诺边界内事项；接口由甲方协调；边界外需求与业务规则梳理另行报价 项目经理 + FDE 评估负责人 评估完成后 2 个工作日内 飞书文档模板 外部版文档 👤人工判断
8 对外发送前提交商务审核，通过后发送，文档关联 X-FDE-01 项目 项目经理 审核 1 个工作日内 飞书审批 + 留痕台 已发送答复、留痕 🔧飞书固化

5. 交付物与模板

  • 交付物：内部版需求摘要、需求评估单、Demo/录屏、外部版答复文档、第三方账号台账记录。
  • 建议模板/表单：
    • 内部版需求摘要：项目编号、客户代号、目标、范围、不做项、验收标准、依赖（接口/数据/资质）、需技术产品提供的支持。
    • 需求评估单：需求项、结论（能做/不能做/需接口配合/需付费）、技术路线、数据条件、风险、预估工时、外部费用、评估人岗位、评估日期。
    • 第三方账号台账：平台、账号用途、归属主体、管理人岗位、开通日期、费用、关联项目。

6. 异常与升级

  • 客户催结论 → 给阶段性答复（评估进度、预计日期），不给结论 → 超过约定日期 2 个工作日升级 FDE 负责人
  • 评估发现需求实质是定制 SaaS、范围远超前期口径 → 停止答复，重新定性 → 2 个工作日内升级商务负责人与 CTO
  • 客户系统接口不开放 → 答复写明"接口由甲方协调"，无法协调的列入不做项 → 无
  • 公共第三方账号、资质无人管理 → 当天交 IT 运维登记 → 超 2 个工作日未落实升级综合部负责人
  • 技术口径分歧 → 记录分歧点 → 1 个工作日内由 CTO 裁决
  • A（升级）说明：可行性与技术答复结论由 FDE 评估负责人拍板（A），对外发送前须经商务负责人审核；技术口径分歧、需求实质超出前期口径需重新定性时升级 CTO 裁决

7. 衡量指标

  • 答复周期 = 收到需求到发出正式答复的工作日数，目标 ≤ 7 天（含 Demo）
  • 对外材料审核覆盖率 = 经商务审核后发送的答复数 / 对外答复总数，目标 100%
  • 口径变更率 = 正式答复后范围/承诺被推翻的项目数 / 答复项目数，目标 ≤ 10%
  • 评估单完整率 = 有评估单的答复数 / 涉及新需求的答复数，目标 100%

8. 低效诊断

  • 现象：客户自拟的需求文档篇幅长、无重点、混入无关需求，研发无法判断落地范围（环节：需求澄清）｜依据：「投资客户B项目群」2026-07
  • 现象：前期口径为"几个 Skill"，评估后变成定制 SaaS，口径前后不一（环节：评估与答复）｜依据：「投资客户B项目群」2026-07
  • 现象：对客户发材料前由谁审不明确，事后才补"先过商务"的要求（环节：对外发送）｜依据：「投资客户B项目群」2026-07
  • 现象：公共第三方商家账号归属不清，评估过程中才追问由谁管理（环节：外部资源）｜依据：「LeapCoreFDE」2026-07
  • 现象：图纸翻译等 Demo 效果离生产差距大，"做开发还是只提供 API"口径不一（环节：验证）｜依据：「LeapCoreFDE」2026-07

9. 分支变体

  • 场景验证类（询价单填写、PDF 图纸翻译、合同/标书模板生成）：重在样例 + Demo，外部 API 按毛利规范收费，余额互通。
  • 投资行业客户需求文档：必须先内部版、后外部版，外部文档涉及落地时不再让客户自拟。
  • 销售转来的客户技术问题（系统接口不开放、本地模型升级成本、流程挖掘等新需求）：按"只做边界内、接口甲方协调、边界外加价"原则答复。
  • Skill 接入上架类需求：格式遵循《LeapSkill 格式规范 1.0.0》（SKILL.md、MANIFEST.json、selfcheck 必选）。

10. 待确认问题

  • 主责是 FDE 负责人，还是需要设专职 FDE/售前技术岗？
  • 对外材料审核由商务负责人统一审，还是按金额/客户类型分级？
  • 答复周期 7 个工作日是否可行？简单问题是否允许 1 个工作日内直接答复？
  • 是否建立客户技术 FAQ/标准答复库并接入知识库机器人？由谁维护？
  • 公共第三方账号统一归 IT 管理是否已成文？费用由哪个部门承担？
X-FDE-04定制项目技术方案、硬件选型报价与内部审核待优化400

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频4 × 耗4 × 跨5 × 险5

  • 适用场景：行业版或本地化部署客户需要技术方案与报价时，设计方案、按并发/模型规模/国产化要求选型硬件并询价，对外发出前经一审、二审。
  • 负责人：主责——FDE Leader/项目部负责人（方案报价一审，当前：黄振锋·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、方案研发（当前：邓乾·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、开放平台（当前：郭逸非·推断待确认）、硬件/算力评估（当前：杨明学、望政韬·推断待确认）、标品对接（当前：杨萌、王皓南·推断待确认）；兜底——研发负责人/CTO（二审，当前：丁震宇·推断待确认）
  • 核心流程：① 需求清单定稿 → ② 技术路线评估 → ③ 方案初稿 → ④ 硬件选型与询价 → ⑤ 编制报价 → ⑥ AI 预审 → ⑦ 一审/二审 → ⑧ 客户技术确认并留痕
  • 交付结果：经审核的技术方案、硬件 BOM 与报价单、审查报告，对外发送并关联到 X-FDE-01 项目。
  • 状态依据：已形成"产出人提交—一审—关键项目二审"的固定习惯，且有 AI 预审先例；但无统一方案模板和硬件 BOM 库，技术路线反复争论、每个项目重新估算和询价，审核人单点排队，审核后仍出现条款疏漏返工，因此判定待优化。

1. 场景判定

  • 触发条件：X-FDE-03 评估结论为"可做"且客户要方案或报价；客户要求本地化部署需确定 GPU/算力卡/服务器；任何方案、报价单、技术评审意见对外发出前。
  • 典型说法：「你先写一份 md 理一下，我们审一下你再发过去」「硬件配置大概需要个什么水平」「甲方需要国产化硬件替代，出一个方案」「来 Review 一下，没问题就发」
  • 判断问题：这份材料是否会发给客户并形成承诺？是否涉及硬件采购、源码交付、免费运维范围？是的就必须走审核。
  • 不归本流程管：
    • 需求是否能做的前期评估 → 请走 X-FDE-03
    • 客户自有模型/算力接入配置 → 请走 X-FDE-06
    • 客户业务系统数据对接的授权与限流 → 请走 X-FDE-07
    • 合同审核与签署 → 请走 LEG-03（销售合同审查与多方会签）；用印 → 请走 LEG-09（用章用印审批与盖章版本核对）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
一审 逐项审技术、报价、条款口径 A FDE Leader/项目部负责人（当前：黄振锋·推断待确认）
二审 重大/敏感项目兜底把关、路线拍板 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
项目经理 需求清单、报价单、外部方案与合同、对客沟通 R 项目经理（当前：杨朋伟、闫登辉·推断待确认）
方案研发 技术路线与方案初稿、与客户技术确认 R 研发（当前：邓乾·推断待确认）
Skill/开放平台 评估哪些靠 Skill、哪些需 MCP/插件/系统对接 C Skill 负责人（当前：李凯·推断待确认）、开放平台负责人（当前：郭逸非·推断待确认）
硬件/算力评估 硬件规格估算、国产化指标核实、询价 R（硬件） IT/基础设施（当前：杨明学·推断待确认）、基座研发（当前：望政韬·推断待确认）
标品对接 确认标品能力边界 C 产品总监（当前：杨萌·推断待确认）、Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • X-FDE-03 的内部版需求摘要与需求评估单
  • 客户需求清单（以飞书版为唯一口径）
  • 部署参数：使用人数、并发量、上下文长度、模型规模、是否国产化、TTFT/TPS 指标（没有就写"无"）
  • 客户环境：网络、机房、现有硬件、数据源与接入方式
  • 预算档位与总包约束、是否涉及源码交付与运维承诺
  • 请求最少包含字段（向方案研发/硬件评估/一审提交时）：X-FDE-01 项目编号与客户代号、需求清单链接（飞书版）、部署参数（人数、并发、上下文、模型规模、国产化、TTFT/TPS 或“无”）、客户环境摘要、预算档位、是否源码交付与运维承诺、客户期望答复日期、本次要对方产出什么（路线建议/BOM/审核意见）；缺项接收方一次性退回项目经理补齐

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 定稿需求清单与部署参数（飞书版为唯一口径） 项目经理 立项后 3 个工作日内 方案模板（模板上线前用飞书文档按第 5 节字段编写） 需求清单（飞书文档，挂 X-FDE-01 项目记录；PDF 等外部版本只作导出） 🔧飞书固化
2 评估技术路线：Skill / MCP / 插件 / 系统对接（数据网关或业务网关） 方案研发、Skill 负责人、开放平台 2 个工作日内 飞书文档 路线建议（写在需求清单同一文档“技术路线”节，结论由一审人签认）；超时→一审人，争论超 2 轮→CTO 👤人工判断
3 写方案初稿（需求、数据源、接入方式、风险、工时、不做项），命名按 Flex-{行业}-{客户代号}，文件名不得出现客户真名 方案研发 3 个工作日内 md/飞书文档 + AI 方案初稿（项目留痕目录下，挂项目记录；群内只发链接）；超时→项目经理催办，再超 1 个工作日→一审人 🤖+👤
4 硬件选型：按"并发—模型规模—硬件 BOM"对照表估算；国产化先核实 TTFT/TPS 再换算显存与算力 硬件/算力评估 2 个工作日内 多维表格对照表 硬件 BOM 草案（硬件对照表新增一行，项目记录挂链接）；超时→项目经理，再超 1 个工作日→CTO 🔧+👤
5 向 2～3 家固定硬件渠道/集成商询价比价，历史报价留档 硬件/算力评估 3 个工作日内 询价台账 询价对比表（询价台账记录，含报价有效期与供货周期）；超时→项目经理，再超 2 个工作日→CTO 协调渠道 🔧飞书固化
6 编制报价单：定制费、词元分配、硬件、运维范围、源码交付范围 项目经理 2 个工作日内 报价模板 报价初稿（挂项目记录，版本号写入项目记录） 👤人工判断
7 AI 预审方案与报价（口径、风险条款、前后矛盾），出审查报告 项目经理 提交一审前 AI 审查 审查报告（随方案、报价一并作为审核任务附件） 🤖自动化
8 一审；重大/敏感项目转二审 一审、二审 一审 1 个工作日内，二审再 1 个工作日内 飞书任务 审核意见（飞书任务评论或文档评论，结论“通过/退回”写回项目记录）；超时见第 6 节 👤人工判断
9 审核通过后与客户技术确认方案，出外部方案与报价，材料关联留痕 方案研发、项目经理 2 个工作日内 留痕台/PRM 对外方案与报价（终版挂 X-FDE-01 项目记录与 PRM，客户确认记录一并留痕；报价转 SAL-19 台账登记） 🔧飞书固化

5. 交付物与模板

  • 交付物：技术方案、硬件 BOM、询价对比表、报价单、审查报告、审核意见。
  • 建议模板/表单：
    • 方案模板：项目编号、客户代号、需求清单、数据源、接入方式、技术路线、部署架构、风险、工时、不做项、验收标准。
    • 硬件对照表：并发量、使用人数、模型规模、上下文、TTFT/TPS、推荐配置（Nvidia/国产化）、价格区间、供货周期、已知限制、更新日期。
    • 审核检查单：口径一致性、源码交付范围、免费运维边界、付款节点、违约责任、硬件供货周期。

6. 异常与升级

  • 客户无 TTFT/TPS 指标 → 用统一口径"客户只对并发和上下文有需求，暂无 TTFT 和 TPS 需求"，按底线配置报价 → 无
  • 厂商只卖卡不卖整机 → 转固定集成商组装报价 → 3 个工作日无结果升级 CTO 协调渠道
  • 审核超 1 个工作日未完成 → 提交人提醒 → 超 2 个工作日升级 CTO 或由第二审核人代审
  • 技术路线争论超过 2 轮 → 停止讨论 → 由 CTO 1 个工作日内拍板
  • 方案无测试环境可验收 → 在方案中列为前置依赖并写入报价 → 客户拒绝的升级商务负责人
  • A（升级）说明：常规项目由一审（FDE Leader）放行（A）；重大/敏感项目（国企客户、源码交付、免费运维承诺）、技术路线争论超过 2 轮、审核超 2 个工作日无人处理时升级 CTO 二审或拍板
  • 提交审核的材料不齐（缺需求清单、部署参数、审查报告或报价）→ 一审人不进入审核，一次性退回列出缺项 → 项目经理 1 个工作日内补齐，审核时限从补齐起算
  • 跨角色交接（路线建议、BOM、询价）到期未交付且未说明原因 → 项目经理在项目记录标“卡住”并 @ 对应负责人 → 1 个工作日无回应升级一审人，再 1 个工作日升级 CTO

7. 衡量指标

  • 审核等待时长 = 提交到出审核意见的工作日数，目标一审 ≤ 1 天、二审 ≤ 1 天
  • 对外返工率 = 发出后需修改条款再发的方案/报价数 / 发出总数，目标 ≤ 10%
  • 硬件报价偏差率 = |实际采购成本 − 报价成本| / 报价成本，目标 ≤ 10%
  • 硬件询价周期 = 发起询价到拿到比价结果的工作日数，目标 ≤ 3 天

8. 低效诊断

  • 现象：需求清单飞书版与 PDF 版口径不一（环节：需求定稿）｜依据：「投资客户A项目群」2026-08
  • 现象：Skill/MCP/插件路线多次争论，总包有限情况下人力浪费（环节：路线评估）｜依据：「投资客户A项目群」2026-07
  • 现象：每个项目重新估算并发与硬件换算、重新找多家询价（环节：硬件选型）｜依据：「核心项目群」2026-07、「核心项目群」2026-10
  • 现象：客户无 TTFT/TPS 指标导致报价难收敛（环节：硬件选型）｜依据：「核心项目群」2026-10
  • 现象：审核人单点，"晚点看""下午晚点审"导致排队（环节：审核）｜依据：「核心项目群」2026-08
  • 现象：审核后才发现运维范围等条款疏漏，需二次修改（环节：审核）｜依据：「核心项目群」2026-10
  • 现象：方案确认后无测试环境，验收衔接断档（环节：交付衔接）｜依据：「投资客户A项目群」2026-08

9. 分支变体

  • 企业定制 SaaS 网关类（如投资客户A）：重点在数据网关/业务网关设计，先保企业定制版交付。
  • 通用版 + Skill 类（如投资客户B）：以标品 + Skill 组合为主，报价按总包分配定制费与词元。
  • Nvidia 标准方案 vs 国产化方案（海光、昇腾等）：性能、成本、供货周期差异大，需注明 CPU/PCIe 等限制。
  • 常规项目由一审放行；重大/敏感项目（国企客户、源码交付、免费运维承诺）必须二审。
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-04（跨部门交接契约）、ALL-06（卡点升级阶梯）、ALL-08（信息归档与单一事实来源）

10. 待确认问题

  • 一审是否固定为 FDE Leader？是否培养第二审核人分担？
  • "重大/敏感项目"的判定标准（金额档、客户类型、条款类型）？
  • 固定硬件集成商名单由谁维护？历史报价存放在哪里？
  • 方案模板、硬件对照表由谁建立，何时上线？
  • AI 预审是否作为提交一审的强制前置？
X-FDE-05FDE 人员派驻、调配与项目交接待新建192

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：客户场景落地需要 FDE 派驻、项目人手不足、人员转岗或换项目时，申请并安排 FDE 派驻或借调/外包补位，完成背景交接与权限管理；需要引入外包或合作公司人员（驻场或远程）参与研发、测试，涉及协议、工位、账号、仓库权限与交付范围时也走本流程。
  • 负责人：主责——FDE 部门负责人（人力调配，当前：郭逸非·推断待确认）；协同——项目经理（当前：杨朋伟、闫登辉·推断待确认）、接收方负责人（当前：黄振锋、王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、LeapCore FDE（当前：李凯·推断待确认）、人事负责人（当前：黄莹·推断待确认）、法务负责人（当前：李瑶·推断待确认）、技术对接人（外包监工，当前：岳阳·推断待确认）、权限开通负责人（当前：宋祺睿·推断待确认）、行政（工位，当前：待指定）、财务（付款主体，当前：待指定）；决策——CEO（外包合作形式与付费主体，当前：邴龙志·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交派驻/借调/外包申请 → ② 查负荷看板选人（外包面试确认）→ ③ 外包确定合作形式与付费主体 → ④ 书面通知接收方与本人 → ⑤ 签协议与保密协议 → ⑥ 外包定首期范围与接口文档 → ⑦ 新任 FDE 模拟交付 → ⑧ 按清单交接 → ⑨ 最小化开通权限与工位 → ⑩ 入场培训 → ⑪ 周更负荷与验收、结束回收
  • 交付结果：已审批的派驻/借调/外包记录、确认回执、已签合作协议与保密协议（外包/借调）、首期范围与接口文档（外包研发）、交接清单、权限开通与回收记录、人力负荷看板更新。
  • 状态依据：2026-06～10 人员安排多靠群里点名或喊话，接收方和相关产品方事后才知道；调入人员角色反复确认、交接资料未到；外包/借调先上岗后补手续；FDE 管理体系与汇报标准缺失，因此判定待新建。

1. 场景判定

  • 触发条件：项目进度因人手不足阻塞；市场需要场景 Demo/落地；新任命 FDE 上岗；人员转岗、换项目、实习生离岗；决定引入外包/合作公司人员参与开发、测试或驻场工作。
  • 典型说法：「现在 FDE 那边有谁可以安排过来」「背景信息跟他交接一下」「下次这种阻塞进度的问题早点反馈」「下下周安排两个人去跟着做 FDE」「来了俩外包 看看怎么管理」「只给开一个仓库权限」
  • 判断问题：是否需要把某人的工作时间投入到某个客户项目或换人接手？是的就走本流程，不在群里口头点名。对方是否为非本公司员工、且需要接触我方代码、数据、账号或办公场地？是的同时按外包分支办理协议与权限。
  • 不归本流程管：
    • 正式招聘新员工 → 请走 X-RCT-01（招聘需求提报与 HC 管理）；入职办理 → 请走 HR-05（新员工入职准备与办理）
    • 项目立项留痕 → 请走 X-FDE-01
    • 员工离职交接 → 请走 HR-27（员工离职办理与交接）
    • 硬件/软件采购 → 请走 FIN-01（对公采购申请与付款审批）/ ADM-24（IT 设备与研发硬件采购申请）
    • 项目整体外包交付合同（不涉及人员入场）→ 请走 LEG-04（采购/服务及其他对外合同审核）
    • 外部协作方访问内网与联调环境的授权细则 → 请走 X-SEC-06（外部协作方访问内网与数据授权）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人力调配 维护负荷看板、选人、发通知、审批派驻 A FDE 部门负责人（当前：郭逸非·推断待确认）
申请方 识别缺口并提交申请、明确工作内容 R 项目经理（当前：杨朋伟、闫登辉·推断待确认）
接收方 确认人选、安排面试/带教、分配任务 R 接收方负责人（当前：黄振锋、王皓南·推断待确认）
场景需求方 提出市场场景落地优先级 C 产品总监（当前：杨萌·推断待确认）
LeapCore FDE LeapCore 线派驻与模拟交付 R（LeapCore 线） LeapCore FDE（当前：李凯·推断待确认）
人事/法务 外包/借调用工手续、合作或外派协议、保密协议、入场培训 R（手续） 人事负责人（当前：黄莹·推断待确认）、法务负责人（当前：李瑶·推断待确认）
技术对接 外包面试、接口文档、监工与代码评审 R（外包） 技术对接人（当前：岳阳·推断待确认）
技术把关 外包权限边界与接口方案（只给接口文档还是开放代码）拍板 C Leap 研发负责人（当前：王皓南·推断待确认）
权限开通 按最小权限开通/回收仓库、账号、环境权限 R 权限开通负责人（当前：宋祺睿·推断待确认）
工位与付款 驻场工位门禁；外包付款主体与结算 I 行政（当前：待指定）、财务（当前：待指定）
外包合作形式 FDE 任命；外包外派/合作形式与付费主体拍板 A（升级） CEO（当前：邴龙志·推断待确认）
兜底 无可用人选时跨部门资源协调 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
移交人 按清单交接资料与待办 R（交接） 原负责人（当前：陈锦杰等·推断待确认）
被派驻人 每周登记工时、结束时交还资料 R 被派驻/借调/外包人员

3. 办之前请准备

  • 项目编号、所需技能（系统研发 / Skill 打磨 / 部署 / 前端等）、人数、周期、期望到岗日期
  • 工作内容说明（写清做什么，避免到岗后角色反复确认）
  • 外包/借调：来源（合作方/兄弟公司/外包公司）、是否已签合同或协议、驻场还是远程、紧急程度
  • 外包：对方资质与人员简历；协议模板（劳务外派协议/合作协议，默认用我方模板）与保密协议模板
  • 外包研发：首期范围说明与接口文档（或代码可见范围说明）；所需权限清单（仓库、测试环境、飞书账号、VPN）
  • 交接：项目背景、文档链接、待办清单、客户侧联系人岗位、需开通的权限

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交派驻/借调/外包申请（项目、技能、人数、周期、工作内容；外包另填合作公司、驻场/远程、到岗日期、紧急程度） 项目经理 发现缺口当天；阻塞进度的不晚于 1 个工作日；外包至少在到岗前 5 个工作日 飞书审批 派驻申请 🔧飞书固化
2 查人力负荷看板，在 FDE 池 / 其他组借调 / 外包三类中选人；外包人选由项目经理与技术对接人面试确认 FDE 部门负责人；技术对接人 申请后 2 个工作日内 多维表格负荷看板、面试记录 人选方案 👤人工判断
3 外包/外派：确定合作形式（劳务外派/合作）与付费主体 CEO 申请后 2 个工作日内（与第 2 步并行） 飞书审批 审批结论 👤人工判断
4 书面通知接收方负责人、被派驻人员及相关产品方，收到确认后执行 FDE 部门负责人 选定当天 飞书任务 + 群公告 确认回执 🔧飞书固化
5 外包/借调人员：签署合作/外派协议与保密协议（默认用我方模板，参照 LEG-05），明确可接触资料范围 人事负责人、法务负责人 到岗前 2 个工作日完成签署 合同模板、飞书合同审批 已签协议、用工手续 🔧+👤
6 外包研发：删减首期范围，产出接口文档或代码可见范围说明 产品总监、技术对接人 到岗前 2 个工作日 文档、AI 扫代码生成 API 文档 范围说明、接口文档 🤖+👤
7 新任 FDE 先在公司内部模拟一次上门交付，通过后上岗 LeapCore FDE/接收方负责人 上岗前 1 周内 模拟交付记录 模拟交付记录 👤人工判断
8 移交人按交接清单交接背景、资料、待办、联系人；资料未到的由移交人当天催齐 移交人 上岗/转岗前 2 个工作日 交接清单模板 已签收交接清单 🔧飞书固化
9 协议签署后按最小权限开通代码仓库（外包用独立仓库/组织）、客户资料、环境权限；驻场人员准备工位门禁 权限开通负责人；行政 到岗前 1 个工作日（须在第 5 步完成后） Gitea、飞书（外部联系人/不分配部门） 权限开通记录 🔧+👤
10 外包/借调人员入场培训（保密、代码规范、协作方式），指定监工 人事负责人、技术对接人 到岗当天 培训材料 培训记录 🔧飞书固化
11 派驻期间每周更新工时与负荷，外包每周进度对接与代码评审；阶段验收后、结束当天回收全部权限并交还资料（按 X-SEC-08 收口） 被派驻人、技术对接人、FDE 部门负责人、权限开通负责人 每周五；结束当天 多维表格、PR 评审、权限清单 工时、验收与回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：派驻/借调/外包审批记录、确认回执、已签协议及保密协议、首期范围与接口文档、交接清单、权限开通与回收记录、验收单、负荷看板。
  • 建议模板/表单：
    • 派驻申请：项目编号、申请人岗位、技能要求、人数、起止日期、工作内容、优先级、人员来源类型、审批人；外包另加合作公司、形式（驻场/远程）、合作类型（外派/合作）、付费主体、到岗日期、紧急程度、所需权限。
    • 交接清单：项目背景、当前进度、文档与代码链接、待办与截止日期、客户侧联系人岗位、权限清单、风险点、接收人签收日期。
    • 负荷看板：人员、所属组、当前项目、投入比例、可释放日期、技能标签。
    • 外包人员登记表：人员代号、所属公司、协议编号、权限清单、开通日期、回收日期、监工岗位。

6. 异常与升级

  • 项目已阻塞才上报 → FDE 部门负责人 1 个工作日内出补位方案 → 无可用人选升级 CTO 协调跨部门资源
  • 接收方事先不知情 → 暂停上岗，补发书面通知并确认 → 当天无法确认升级 CTO
  • 外包/借调人员未签协议 → 不开通客户资料与代码权限 → 3 个工作日未补齐升级人事与 CTO
  • 交接资料未到 → 移交人 1 个工作日内补齐 → 超期升级移交人所属负责人
  • 调入人员任务与申请不符（角色反复确认）→ 申请人、接收方、本人三方 1 个工作日内对齐 → 无法对齐升级 FDE 部门负责人
  • 外包当天通知、次日开工 → 先签保密协议并只开最小权限，其余手续 3 个工作日内补齐 → 升级 CEO 确认紧急性
  • 外包只给接口文档还是开放代码有争议 → Leap 研发负责人 1 个工作日内拍板，默认只给接口文档与独立仓库
  • 对方无协议模板 → 使用我方模板 → 法务负责人 2 个工作日内审完
  • 外包人员离场或合作终止 → 当天回收所有权限并登记
  • A（升级）说明：派驻、借调与外包人选由 FDE 部门负责人拍板（A）；外包/外派需确定合作形式与付费主体、FDE 任命、外包紧急入场需确认紧急性时升级 CEO；无可用人选需跨部门协调、接收方当天无法确认、手续超期未补齐时升级 CTO

7. 衡量指标

  • 补位响应时长 = 申请提交到人员确认的工作日数，目标 ≤ 3 天
  • 书面通知率 = 有确认回执的派驻数 / 派驻总数，目标 100%
  • 交接完整率 = 签收交接清单的人员变动数 / 人员变动总数，目标 100%
  • 手续前置率 = 上岗前完成用工手续的外包/借调人数 / 外包借调总人数，目标 100%
  • 外包提前申请率 = 到岗前 ≥ 5 个工作日提交申请的外包人数 / 外包总人数，目标 ≥ 90%
  • 协议先行率 = 到岗前 2 个工作日已签协议与保密协议的外包人数 / 外包总人数，目标 100%
  • 权限回收及时率 = 结束当天回收全部权限的人数 / 结束人数，目标 100%

8. 低效诊断

  • 现象：人员安排通知只发在一个群，相关产品方未看到，事后再问"有人通知过吗"（环节：通知）｜依据：「鼎慧产研决策部」2026-06
  • 现象：FDE 管理体系与汇报标准缺失，归属多次变化（环节：组织）｜依据：「鼎慧产研决策部」2026-06
  • 现象：人力调配靠群里询问谁有空，实习生离岗后人手骤减（环节：调配）｜依据：「【行业版Leapcore】投资人版」2026-09
  • 现象：调入人员角色在系统研发与 Skill 打磨之间反复确认，任务偏移（环节：任务定义）｜依据：「【行业版Leapcore】投资人版」2026-09
  • 现象：交接资料未到，接手人无法完整接手（环节：交接）｜依据：「【行业版Leapcore】工程版」2026-10
  • 现象：项目人力缺口上报滞后，接收方事后才得知补位安排（环节：预警）｜依据：「核心项目群」2026-07、「核心项目群」2026-09
  • 现象：外包/借调人员先上岗、后补手续（环节：合规）｜依据：「核心项目群」2026-07
  • 现象：外包引入决定口头传达，人事临时询问办公方式和协议模板，当天通知次日开工（环节：申请）｜依据：「模态人事大主管」2026-07
  • 现象：外包紧急程度判断失误，按“急”处理后发现并不急（环节：申请）｜依据：「模态人事大主管」2026-03、「模态人事大主管」2026-07
  • 现象：合作形式（外派 vs 合作）临时讨论，无协议模板（环节：合规）｜依据：「模态人事大主管」2026-07
  • 现象：远程外包的接口文档与代码权限边界临时争论，范围与对接人临时确定（环节：权限）｜依据：「Leap产研决策部」2026-08

9. 分支变体

  • 项目制 FDE 与 LeapCore FDE 分开管理；FDE 已改为归市场直管，汇报线以最新任命为准。
  • 新任 FDE：公司内部模拟交付 → 客户上门交付；可按 3 角色组队。
  • 人员来源：FDE 池内调配 / 研发组间借调 / 合作方或兄弟公司借调（需补协议）/ 正式外包。
  • 交接类型：研发间交接、FDE 借调、实习生离岗。
  • 驻场外包：人事拟协议、安排工位与入场培训，飞书账号不分配部门。
  • 远程外包研发（如手机端 LeapCore）：开独立 Gitea 仓库/组织，提供 API 文档而非完整代码，首期范围不要求覆盖桌面端全部能力。
  • 劳务外派协议 vs 合作协议：由 CEO 判断，影响付费主体与用工风险。
  • 已合并原 X-OTH-04（外包/合作方研发人员引入与对接）。

10. 待确认问题

  • 人力调配主责是 FDE 部门负责人还是 CTO？FDE 各线（项目制、LeapCore）分别由谁统筹？
  • 人力负荷看板由谁建立和维护，更新频率是否为每周？
  • 合作方/兄弟公司借调的用工形式和保密要求是否已成文？
  • 新任 FDE 模拟交付的通过标准是什么？
  • 派驻审批是否需要接收方负责人会签？
  • 外包人员引入原由用人部门自行发起，合并入本流程后归口 FDE 部门负责人还是人事负责人统筹，请管理层裁定。
  • 外包引入是否每次都需要 CEO 审批合作形式与付费主体，还是按金额/人数分级？
  • 是否已有成文的劳务外派协议、合作协议与保密协议模板？
  • 外包人员飞书账号用外部联系人还是内部账号不分配部门？
  • 默认是否只向外包提供接口文档、不开放主仓库代码？
  • 外包费用的付费主体由财务还是用人部门确定？
X-FDE-06客户模型接入与模型路由配置服务待新建300

状态：待新建｜证据：有证据（卡片 2 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险5

  • 适用场景：客户因合规只能使用自有 API 或本地算力，或希望降低模型成本时，由 FDE 远程/上门接入客户模型、配置各档位路由规则，并出具成本或体验影响说明。
  • 负责人：主责——LeapCore 网关/标品技术负责人（当前：王皓南·推断待确认）；协同——模型网关实施（当前：柯逸飞·推断待确认）、adapter 开发（当前：宋祺睿·推断待确认）、Agent 约束（当前：岳阳·推断待确认）、商务（当前：闫登辉、杨萌·推断待确认）、FDE（当前：李凯·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 售前识别 → ② 客户填信息表 → ③ 适配评估 → ④ 降本测算（如需）→ ⑤ 商务确认与知情书 → ⑥ 配置路由/代理 → ⑦ 测试切换 → ⑧ 交接归档入台账
  • 交付结果：客户模型接入台账记录、适配评估单、路由配置（含防覆盖脚本）、测试记录、handoff 文档；降本场景另附成本节省说明。
  • 状态依据：2026-09～10 至少 3 家客户需要接入自有模型，每家都临时写代理，产品升级后可能被覆盖；信息表以聊天文字传递，体验受限知情书无模板；降本路由服务 2026-06 仅为提案，方案、报价、交付人未定，因此判定待新建。

1. 场景判定

  • 触发条件：客户（国企、电信体系、政府等）提出只能用自有模型 API 或本地算力；客户反映专家模式成本高，希望更换底层模型。
  • 典型说法：「客户要用自己的模型 API」「LeapCore 接自有算力确认信息表」「提供 FDE 远程/上门，根据实际使用场景配置模型和模型路由规则」
  • 判断问题：客户是否不允许或不愿使用我方默认模型通道？是否需要改变档位到模型的映射？是的就走本流程。
  • 不归本流程管：
    • 硬件/算力选型与采购报价 → 请走 X-FDE-04
    • 已交付客户自接模型的故障诊断 → 请走 X-CS-11
    • 标品网关版本发布 → 请走 RND-51（正式版本发布上线）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
网关技术负责人 信息表口径、适配评估、路由方案、长期配置化方案 A LeapCore 网关/标品技术负责人（当前：王皓南·推断待确认）
实施工程师 配置路由与代理、测试切换、记录指标、写 handoff R 模型网关实施（当前：柯逸飞·推断待确认）
adapter/Agent 研发 兼容层代码、工具调用适配、Agent 约束 R 研发（当前：宋祺睿、岳阳·推断待确认）
商务 售前识别、发放信息表、收费与 SLA、知情书签署 R（商务） 商务（当前：闫登辉、杨萌·推断待确认）
FDE 降本场景诊断与成本说明 R（降本） FDE（当前：李凯·推断待确认）
兜底 承接范围决策、重大故障协调 C 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已回收的《自有算力确认信息表》：是否开源、模型名称、是否后训练、tok/s、并发、是否支持 Responses API、缓存、思考模式、联网搜索、并行工具调用
  • 客户平台访问方式与测试账号、部署环境（本地/私有云）
  • 客户使用场景与当前用量（降本场景必备）
  • 当前部署版本号、是否有已存在的代理或脚本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 售前确认客户是否要求自有模型或降本路由，提前告知技术并在项目记录打标 商务 签约前，最迟部署前 5 个工作日 X-FDE-01 留痕台 需求标记 👤人工判断
2 发送信息表给客户填写并回收 商务 3 个工作日内回收 飞书表单 自有算力确认信息表 🔧飞书固化
3 适配评估：各档位（经济/标准/专家/生图/视频）路由方案、联网搜索旁路、不兼容项与体验影响 网关技术负责人 回收后 2 个工作日内 评估模板 适配评估单 🤖+👤
4 降本场景：按使用场景出模型替换方案和成本节省说明 FDE 2 个工作日内 成本测算表 成本节省说明 🤖自动化
5 商务确认是否收费、是否承诺 SLA；客户不使用我方非语言模型 API 的，签署体验受限知情书 商务 评估后 2 个工作日内 飞书审批 报价/知情书 👤人工判断
6 配置路由：优先配置文件/白名单；当前版本须加代理的，代码入库并部署防覆盖自检脚本 实施工程师 约定上线窗口内 Gitea/客户服务器 路由配置、代理、脚本 🤖+👤
7 功能测试，记录客户平台 TPS、TTFT；切换后观察 24 小时 实施工程师 切换当天起 24 小时 监控 测试记录 👤人工判断
8 写 handoff（路由表、代理位置、脚本、回滚步骤），登记客户模型接入台账，并加入发版前检查清单 实施工程师 切换后 1 个工作日内 台账/文档 handoff、台账记录 🔧飞书固化

5. 交付物与模板

  • 交付物：信息表、适配评估单、成本节省说明（降本场景）、知情书、路由配置与脚本、测试记录、handoff 文档、台账记录。
  • 建议模板/表单：
    • 客户模型接入台账：客户代号、部署版本、各档位对应模型、接入方式（配置/代理）、代理与脚本位置、TPS/TTFT、上线日期、负责人岗位、最近一次升级验证日期。
    • 体验受限知情书：受限功能清单、原因、客户确认、签署日期。

6. 异常与升级

  • 版本升级或 hotfix 覆盖代理导致客户掉线 → 立即重跑脚本或回滚，30 分钟内恢复 → 超时升级网关技术负责人，影响超 2 小时升级 CTO
  • 客户平台兼容性差（工具调用、思考模式不支持）→ 记录不兼容项并告知客户，纳入知情书 → 客户不接受的升级商务
  • 信息表回收不全 → 商务 2 个工作日内补问 → 仍缺失则暂停评估
  • 客户代号混淆 → 一律以台账客户代号为准 → 无

7. 衡量指标

  • 升级掉线次数 = 版本升级后自接模型客户掉线次数，目标 0
  • 接入周期 = 信息表回收到切换上线的工作日数，目标 ≤ 10 天
  • 信息表一次回收完整率，目标 ≥ 80%
  • 台账覆盖率 = 已登记台账的自接模型客户数 / 自接模型客户总数，目标 100%

8. 低效诊断

  • 现象：每家客户临时写代理，多套代理需手工维护（环节：实施）｜依据：「某区政府客户项目群」2026-09、「某供应链客户项目群」2026-09
  • 现象：hotfix 或新镜像下发后需重新登录机器跑脚本（环节：升级运维）｜依据：「某区政府客户项目群」2026-09
  • 现象：信息表以聊天文字发送，未做成表单（环节：信息收集）｜依据：「某供应链客户项目群」2026-09
  • 现象：切换细节只在 handoff 文件中，客户较多时容易混淆（环节：交接）｜依据：「某供应链客户项目群」2026-09
  • 现象：体验受限知情书没有模板，临时拟定（环节：商务确认）｜依据：「某供应链客户项目群」2026-09
  • 现象：降本路由服务停留在提案，方案、报价、交付人均未定（环节：服务定义）｜依据：「跃迁AI总动员」2026-06

9. 分支变体

  • 本地开源模型替换经济档（区级政府类客户）。
  • 经济/标准/专家/生图全部走客户自建 API 网关（央企供应链类客户），联网搜索旁路。
  • 降本路由：LeapAll 个人版与 LeapCore 企业版分别配置。
  • 网关新版本上线自定义模型功能后，改为配置化接入，不再逐家改代理。

10. 待确认问题

  • 主责是网关技术负责人，还是由 FDE 负责实施、网关团队只做支撑？
  • 自定义模型配置功能的上线时间？上线前代理如何统一维护？
  • 接入服务和降本路由服务是否收费？是否承诺 SLA？
  • 体验受限知情书由谁拟定模板、是否需法务审核？
  • 发版前检查清单是否已纳入自接模型客户列表？
X-FDE-07客户业务系统数据对接的授权与限流待新建150

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨5 × 险5

  • 适用场景：需要对接客户内部业务系统（如投管系统、数据库）读写业务数据时，先取得书面授权、明确读写范围与限流策略，再接入并全程留痕。
  • 负责人：主责——FDE 项目技术负责人（当前：邓乾·推断待确认）；协同——项目经理（当前：杨朋伟·推断待确认）、开放平台（当前：郭逸非·推断待确认）、Skill 负责人（当前：李凯·推断待确认）、安全/法务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 取得书面授权 → ② 确认接入方式 → ③ 并发与限流设计 → ④ 鉴权设计 → ⑤ 安全评审 → ⑥ 最小化取数并登记 → ⑦ 写回经客户确认 → ⑧ 缺陷沟通与结项处置
  • 交付结果：客户书面授权、接入确认单、流量调度与鉴权设计、客户数据访问日志、项目结束的数据处置记录。
  • 状态依据：单个项目中的做法已较清晰（只读账号、网关排队限流、取数留痕、令牌换账号），但取数留痕靠口头要求、限流要求无书面记录、三方接口责任不清，未形成"客户数据访问清单—留痕表—问题上报话术"的固化流程，因此判定待新建。

1. 场景判定

  • 触发条件：方案中包含读取或写回客户业务系统数据；需要客户提供数据库账号、接口或生产系统访问权限。
  • 典型说法：「你在我们这记一笔，什么时间从他们那拿了什么数据」「请求可以在这一层排队，也可以在这一层限流、做缓存」「希望我们的 Agent 不要并发请求把系统弄崩」
  • 判断问题：是否会接触客户生产数据或对客户系统产生请求压力？是的就必须先授权、再限流、全程留痕。
  • 不归本流程管：
    • 接入方式的方案设计与报价 → 请走 X-FDE-04
    • 客户模型/算力接入 → 请走 X-FDE-06
    • 公司内部数据安全事件处置 → 请走 X-SEC-44（数据泄露（含个人信息）事件响应与报告）；内网异常与安全告警 → 请走 X-SEC-42（内网安全事件与异常请求溯源处置）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
项目技术负责人 接入设计、限流鉴权、取数登记、缺陷处置 R FDE 项目技术负责人（当前：邓乾·推断待确认）
项目经理 取得书面授权、对客户沟通、三方责任约定 R 项目经理（当前：杨朋伟·推断待确认）
开放平台/Skill 接口与 MCP 接入规范、Agent 调用约束 C 开放平台负责人（当前：郭逸非·推断待确认）、Skill 负责人（当前：李凯·推断待确认）
安全/法务 保密协议、授权书审核、风险分级 C 安全负责人（当前：待指定）、法务负责人（当前：李瑶·推断待确认）
安全评审与兜底 安全要求制定、接入方案安全评审放行、客户沟通口径 A 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已签保密协议（或合同中的保密条款）
  • 客户书面授权：数据范围、读/写权限、用途、期限
  • 客户技术对接人岗位、只读账号、接口文档、测试环境（没有的需书面说明）
  • Agent 并发预估与业务峰值时段
  • 涉及的数据类别清单（是否含个人信息或敏感经营数据）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 取得客户书面授权（范围、读/写、用途、期限），核对保密条款 项目经理 开发前完成 客户函件/协议 书面授权 👤人工判断
2 与客户技术确认接入方式：只读账号、接口文档、测试环境；无测试环境的书面记录风险并约定生产访问窗口 项目技术负责人 授权后 3 个工作日内 飞书文档 接入确认单 👤人工判断
3 并发与限流设计：预估 Agent 并发和可压缩上限，在业务网关做排队、缓存、限流；限流阈值请客户书面确认 项目技术负责人 2 个工作日内 设计文档 流量调度设计 👤人工判断
4 鉴权设计：平台身份令牌转换为客户系统账号，密码不落库 项目技术负责人 与第 3 步同步 业务网关 鉴权方案 👤人工判断
5 安全评审：授权、限流、鉴权、取数范围逐项过审 CTO 或其指定评审人 提交后 1 个工作日内 飞书任务 评审意见 👤人工判断
6 最小化取数，只取代表性数据；每次取数登记时间、数据项、数量、用途、操作岗位 项目技术负责人 每次取数当天 客户数据访问日志 + 网关自动记录 访问日志 🔧+🤖
7 需要写回时走客户接口，并经客户侧员工确认后执行 项目技术负责人 每次写回前 业务网关 写回确认记录 👤人工判断
8 发现客户系统缺陷：以"请问是否是我们操作有误"方式沟通，网关侧先加防护并内部登记；结项后回收账号、删除本地缓存数据 项目技术负责人 + 项目经理 发现后 1 个工作日内；结项后 5 个工作日内 问题登记表 沟通记录、数据处置记录 👤人工判断

5. 交付物与模板

  • 交付物：书面授权、接入确认单、流量调度与鉴权设计、客户数据访问日志、缺陷沟通记录、数据处置记录。
  • 建议模板/表单：
    • 客户数据访问日志：日期时间、客户代号、系统、数据项、数据量、用途、读/写、操作岗位、是否经客户确认。
    • 接入确认单：接入方式、账号类型、接口文档版本、测试环境有无、限流阈值、访问窗口、三方责任（客户/客户外包/我方）、客户确认日期。

6. 异常与升级

  • 客户无测试环境、无接口文档 → 书面记录风险，只在约定窗口低频访问生产 → 当天报 CTO 备案
  • 请求压力导致客户系统变慢或报错 → 立即降低并发或暂停调用 → 1 小时内告知项目经理与客户，升级 CTO
  • 发现客户系统疑似安全缺陷 → 不对外定性，网关侧先加防护 → 1 个工作日内由项目经理按标准话术告知客户，升级 CTO
  • 客户外包方接口责任不清 → 列入三方责任表请客户确认 → 3 个工作日未确认升级商务负责人
  • 发现未登记的取数 → 当天补登记 → 重复发生升级 CTO
  • A 说明：接入方案以 CTO（或其指定评审人）安全评审通过为准（A），项目技术负责人负责设计与日常执行（R）；上述异常均直接报 CTO 处理

7. 衡量指标

  • 授权前置率 = 开发前取得书面授权的数据对接项目数 / 数据对接项目数，目标 100%
  • 取数留痕率 = 已登记的取数次数 / 网关记录的取数次数，目标 100%
  • 客户系统受影响次数 = 因我方请求导致客户系统异常的次数，目标 0
  • 结项数据处置率 = 结项 5 个工作日内完成账号回收与数据删除的项目数 / 结项项目数，目标 100%

8. 低效诊断

  • 现象：客户无测试系统、无 API 文档，开发直接面对生产系统（环节：接入确认）｜依据：「投资客户A项目群」2026-07
  • 现象：取数留痕靠口头要求，事后补记（环节：取数留痕）｜依据：「投资客户A项目群」2026-07
  • 现象：限流要求是否由客户提出没有书面记录（环节：限流设计）｜依据：「投资客户A项目群」2026-08
  • 现象：客户、客户外包方、我方三方接口责任不清（环节：接入确认）｜依据：「投资客户A项目群」2026-08
  • 现象：发现客户系统缺陷时缺统一沟通口径与上报路径（环节：问题上报）｜依据：「投资客户A项目群」2026-08

9. 分支变体

  • 客户系统外网可访问、提供只读账号：按本流程全量执行，重点在限流与留痕。
  • 客户业务数据在飞书等协作平台内：授权以平台应用授权为准，取数登记同样执行。
  • 只读与需要写回：写回必须经客户员工确认，且优先走客户正式接口。

10. 待确认问题

  • 主责是项目技术负责人，还是由安全负责人统一把关？公司是否有安全负责人岗位？
  • 书面授权的标准模板由谁起草？是否需法务审核？
  • 客户数据访问日志放在哪里？是否能由网关自动生成、人工只做补充？
  • 结项数据删除的标准（保留期、删除证明）是否需要写入合同？
  • 安全评审是否必须由 CTO 本人做，还是可指定评审人？
X-FDE-08定制 Skill 需求承接、评估定价与交付跟进待优化180

状态：待优化｜证据：有证据（卡片 3 张 / 会话 6 个）｜优先级：频4 × 耗3 × 跨5 × 险3

  • 适用场景：客户或内部同事提出定制 Skill 需求、内部发现可产品化的好用场景时，统一受理、查重、评估工作量与定价、排期开发、适配测试并交付跟进。
  • 负责人：主责——产品总监（Skill 需求统筹，当前：杨萌·推断待确认）；协同——Skill 交付研发（当前：邓乾·推断待确认）、Skill 开发/业务专家（当前：王满、王蕊·推断待确认）、适配测试（当前：佘天禾·推断待确认）、客户对接销售（当前：刘昱潇、杨朋伟·推断待确认）、Skill 负责人/运营（当前：李凯·推断待确认）、Skill 开发（当前：李铭熙、马漳毓、裴蔬桐·推断待确认）、容器环境（当前：岳阳、宋祺睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交 Skill 需求单 → ② 查重复用 → ③ 评估工作量与依赖 → ④ 定价或定优先级 → ⑤ 指派开发 → ⑥ 按规范提交 → ⑦ 适配测试与补依赖 → ⑧ 内置/交付并跟进反馈
  • 交付结果：Skill 需求池记录、评估单与报价审批、符合格式规范的 Skill 包与测试记录、上架/交付记录及反馈结论。
  • 状态依据：已有"Skill 反馈群"和"fde 亲卫队"专群收口，并有临时承接小组；但 2026-10 仍明确"内部场景上架、客户 Skill 定制没有完整机制和跟进人"，提交规范（如 README）不统一，评估与定价由谁出不明确，容器依赖缺失时互相转交，因此判定待优化。

1. 场景判定

  • 触发条件：客户提出 Skill 层面定制（项目开发组不承接此类需求）；内部发现可上架 LeapCore 的好用场景；运营/产品需要临时制作演示 Skill。
  • 典型说法：「需要评估工作量，给出定价；确认合作后再安排交付」「之后和 Skill 相关的问题请统一在此群反馈」「内部发现的好用场景开发成 Skill 上架，没有完整的机制和跟进人」
  • 判断问题：需求能否用 Skill 包形式交付、无需改产品主体？是的走本流程；需要改产品功能的走 X-FDE-02。
  • 不归本流程管：
    • 产品功能需求与入口分流 → 请走 X-FDE-02
    • 定制项目整体方案与报价 → 请走 X-FDE-04
    • Skill 上架后的质量评分、安全门禁与审核发布 → 请走 X-FDE-09（行业版 Skill/插件提交审核、开放平台上架与下发）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
统筹 需求池维护、优先级、指派承接人、上架前效果核对 A 产品总监（当前：杨萌·推断待确认）
交付研发 客户定制 Skill 开发与交付 R Skill 交付研发（当前：邓乾·推断待确认）
Skill 开发/业务专家 内部场景 Skill 开发、业务规则与提示词 R 业务专家/FDE（当前：王满、王蕊·推断待确认）；研发（当前：李铭熙、马漳毓、裴蔬桐·推断待确认）
适配测试 评估工作量、适配 LeapCore、测试验收 R FDE 成员（当前：佘天禾·推断待确认）
查重与运营 Skill 市场查重、难度初判、反馈群收口 C Skill 负责人/运营（当前：李凯·推断待确认）
销售 收集客户真实需求、报价沟通 R（客户需求） 销售（当前：刘昱潇、杨朋伟·推断待确认）
容器环境 补齐运行依赖并发版 R（依赖） 研发（当前：岳阳、宋祺睿·推断待确认）
兜底 资源冲突与临时突击任务指派 C 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求来源（客户定制 / 内部场景 / 运营演示）、客户代号与是否愿意付费
  • 场景描述、输入输出样例、期望效果、期望时间
  • 已在 Skill 市场/集市搜索过的类似 Skill 名称
  • 客户定制：X-FDE-01 项目编号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填写 Skill 需求单（来源、客户、场景、样例、期望时间） 需求方/销售 提出当天 多维表格 Skill 需求池 需求记录 🔧飞书固化
2 查重：在 Skill 市场/集市找类似 Skill，能复用的先试用或复刻 Skill 负责人/运营 1 个工作日内 Skill 市场 查重结论 🤖+👤
3 评估工作量、技术难度与运行依赖（容器包） 适配测试 + 交付研发 2 个工作日内 评估单 人天与依赖清单 👤人工判断
4 客户定制：给出定价并走报价审批；内部场景：统筹定优先级 销售 + 产品总监 评估后 2 个工作日内 飞书审批 报价/优先级 👤人工判断
5 确认合作或排期后指派承接人，建飞书任务 产品总监 确认当天 飞书任务 开发任务 🔧飞书固化
6 按《LeapSkill 格式规范 1.0.0》提交：SKILL.md、MANIFEST.json、selfcheck 脚本，另附 README、测试样例、依赖清单 Skill 开发 按排期 Gitea/zip Skill 包 🤖+👤
7 适配 LeapCore 并测试；缺运行依赖的提交依赖清单，由容器环境补包发版 适配测试、容器环境 测试 3 个工作日内；补依赖 2 个工作日内 测试环境 测试记录、依赖更新 👤人工判断
8 内置/上架前核对效果；交付客户并跟进 2 周使用反馈 产品总监、交付研发 交付后 2 周内 Skill 反馈群 验收与反馈记录 👤人工判断

5. 交付物与模板

  • 交付物：需求池记录、评估单、报价审批、Skill 包（含 README 与测试样例）、测试记录、上架/交付记录、反馈结论。
  • 建议模板/表单：
    • Skill 需求池：需求编号、来源、客户代号、场景、样例链接、查重结论、工作量（人天）、报价、优先级、承接人、状态、交付日期、反馈。
    • Skill 提交清单：SKILL.md、MANIFEST.json、selfcheck、README、测试样例、依赖清单（含版本）、适配版本号。

6. 异常与升级

  • 客户定制需求无人承接 → 统筹 1 个工作日内指派 → 无可用人力升级 CTO
  • 提交缺 README/测试样例 → 退回补齐，不进入测试 → 无
  • 容器依赖缺失、多人互相转交 → 统一由容器环境负责人接单，2 个工作日内补包 → 超期升级 Leap 研发负责人
  • 临时突击演示 Skill → 管理者指派、产品给需求，先查重再开发 → 与在排期需求冲突的由 CTO 裁决
  • 定价有争议 → 销售与统筹协商 → 2 个工作日未定升级商务负责人

7. 衡量指标

  • 需求承接率 = 已指派承接人的需求数 / 有效需求数，目标 100%
  • 评估定价周期 = 提交到给出报价/优先级的工作日数，目标 ≤ 5 天
  • 提交一次通过率 = 首次提交即符合格式规范的 Skill 数 / 提交总数，目标 ≥ 80%
  • 交付后 2 周反馈收集率，目标 100%

8. 低效诊断

  • 现象：内部场景上架和客户 Skill 定制两类需求没有完整机制和跟进人，项目开发组不承接（环节：承接）｜依据：「【模态】开放生态」2026-10
  • 现象：提交的 Skill 缺 README，提交规范靠测试时临时提醒（环节：提交）｜依据：「fde亲卫队」2026-10
  • 现象：评估与定价由谁出不明确（环节：评估定价）｜依据：「fde亲卫队」2026-10
  • 现象：需求先经个人转发再进群，未直接进入统一入口（环节：受理）｜依据：「fde亲卫队」2026-10
  • 现象：容器依赖（PDF、文档模板等包）缺失时互相转交（环节：适配测试）｜依据：「Skill 反馈群」2026-07
  • 现象：临时突击赶制演示 Skill，缺优先级与排期（环节：排期）｜依据：「SKILL突击」2026-05
  • 现象：销售收集客户需求的载体不明确（环节：需求收集）｜依据：「Leap市场销售通知群」2026-09

9. 分支变体

  • 内部 Skill（如会议全链路、政策申报信息抓取）：先内置 LeapCore，由统筹核对效果。
  • 外部客户 Skill：必须评估 + 定价，确认合作后由交付研发负责交付；分行业版与非行业版。
  • 运营/演示临时 Skill：管理者指派，先查重复刻，按演示需求验证。
  • 销售动员：每位销售提交至少 1 位愿投入成本做 FDE 开发的客户，并收集 3～5 个真实需求，统一进入需求池。

10. 待确认问题

  • 主责是产品总监，还是 FDE 部门负责人？fde 亲卫队与 Skill 反馈群是否合并？
  • 客户定制 Skill 的定价规则（按人天或按 Skill 档位）由谁制定？
  • Skill 需求池用多维表格还是并入产研需求池？
  • 《LeapSkill 格式规范 1.0.0》是否作为内部和客户 Skill 的强制提交标准？
  • 容器依赖补包是否纳入固定发版节奏？
X-FDE-09行业版 Skill/插件提交审核、开放平台上架与下发待优化180

状态：待优化｜证据：有证据（卡片 5 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨5 × 险4

  • 适用场景：FDE、行业团队、客户或第三方 SaaS 开发完成 Skill/MCP/插件，需要经 LeapOpen 开放平台审核后，按全局/行业/企业/部门范围上架或下发到客户 LeapCore 实例时启动
  • 负责人：主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——开放平台账号与架构（当前：吴亚军·推断待确认）、开放平台后端（当前：杨睿·推断待确认）、插件规范与开发辅导（当前：邓乾·推断待确认）、LeapCore 接入研发（当前：杨云峰、柯逸飞·推断待确认）、行业版 Skill 开发 FDE（当前：李凯、陈锦杰、季学森·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 开通开发者账号/Developer Key → ② 按 LeapSkill/插件规范开发并自检 → ③ 打包提交 LeapOpen → ④ lint+Agent 初审 → ⑤ 中高风险人工二审 → ⑥ 发布并设定可见范围 → ⑦ 客户侧验证安装运行 → ⑧ 上线抽检与迭代
  • 交付结果：通过审核、带签名和版本号的 Skill/插件包，已按指定 scope 对目标企业/行业可见，并在客户 LeapCore 上验证可安装可运行；下发记录可查
  • 状态依据：已有 LeapOpen 平台（审核台/FDE 操作台/发放台/企业台初版）、《FDE 接入 LeapOpen 技术文档》v0.1.1、LeapSkill 格式规范 1.0.0 与插件 DevKit，但审核分级标准、迭代交付规则、客户自助入驻未成文；2026-07～09 多次出现“怎么持续交付到平台还没定”“上架企业级怎么做”的重复提问

1. 场景判定

  • 触发条件：行业版 Skill/插件开发完成需交付客户；客户想把自有 Skill/插件上架为企业级；外部 SaaS 想以插件形式接入 LeapCore；已上架能力需要发新版本
  • 典型说法：「FDE 提交 skill 到 LeapOpen，审核完毕下发给 LeapCore」「如何上架企业级的 skill」「进开放平台成为 FDE 然后下发给他们公司」「LeapOpen 账号找开放平台的同事给你开一下」
  • 判断问题：要交付的是否是 Skill/MCP/插件包（而不是改产品内置功能）？目标是特定企业/行业/部门而不是全量用户？开发者是否已有开放平台账号？
  • 不归本流程管：产品官方内置 Skill 的开发与随版本发布 → 请走 RND-56；行业版插件的技术开发规范与研发验收 → 请走 RND-64；面向 C 端/OPC 开发者的上架分润 → 请走 X-PRD-20；开发者需要调试用 LeapCore 环境 → 请走 X-FDE-12；客户提出定制 Skill 的评估与报价 → 请走 X-FDE-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 维护上架/下发规则、审核标准、发放台，处理例外 A 开放平台负责人（当前：郭逸非·推断待确认）
账号与资质 开通开放平台账号、FDE/开发者身份审核、发 Developer Key R 开放平台账号与架构（当前：吴亚军·推断待确认）
平台运维 存储桶、接口、审核台可用性，容灾降级 R 开放平台后端（当前：杨睿·推断待确认）
开发辅导 讲解插件规范、DevKit、自检脚本，答疑 C 插件规范负责人（当前：邓乾·推断待确认）
提交人 开发、自检、打包、填写提交信息、客户侧验证 R 行业版 Skill 开发 FDE（当前：李凯、陈锦杰、季学森·推断待确认）/客户或第三方开发者
客户端接入 LeapCore 从开放平台拉取、安装、静默更新逻辑 C LeapCore 接入研发（当前：杨云峰、柯逸飞·推断待确认）
人工二审 中高风险包的安全与权限审查 R 开放平台负责人＋CTO 指定审核人（当前：待指定）
业务口径 行业 scope、上线时机、是否标品化 C 产品总监（当前：杨萌·推断待确认）
兜底 争议、高风险放行、范围冲突拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
客户管理员 决定启用/默认安装/自动更新，配合客户侧验证 C 客户方 LeapCore 管理员

3. 办之前请准备

  • 开放平台账号与 Developer Key（未开通先走步骤 1）
  • 按《LeapSkill 格式规范 1.0.0》/《Leap 插件生态开发指南》组织的包：SKILL.md、MANIFEST.json、scripts/selfcheck.py（必选），README/INSTALL（推荐）
  • 自检通过截图或日志；ZIP 包不超过 100MB
  • 提交信息：名称、版本号、目标客户/行业/部门、安装与更新建议（默认安装/可选/静默更新）、所需权限与敏感数据说明、变更说明
  • 目标客户企业的组织 ID（LeapUpdate UUIDv7）与 LeapCore 版本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交开发者/FDE 入驻申请，审核身份后开通账号与 Developer Key 开发者；开放平台账号负责人 申请后 1 个工作日内 飞书表单→LeapOpen 账号、Developer Key 🔧飞书固化
2 按规范开发，运行 selfcheck 与 lint，修正 frontmatter/MANIFEST 错误 提交人 提交前 DevKit、selfcheck 自检通过记录 🤖自动化
3 先上传测试环境，在测试 LeapCore 验证安装运行 提交人 提交正式审核前 LeapOpen 测试环境 测试结果 👤人工判断
4 在 FDE 操作台提交正式包与提交信息 提交人 测试通过当天 LeapOpen FDE 操作台 提交单 🔧飞书固化
5 自动 lint＋Agent 初审，给出风险等级（低/中/高） 系统 提交后 2 小时内 LeapOpen 审核台 初审报告 🤖自动化
6 中高风险包人工二审（权限最小化、外联地址、敏感数据），打回附原因 人工二审人 初审后 1 个工作日内 LeapOpen 审核台＋飞书审批通知 通过/打回意见 👤人工判断
7 发布：生成摘要与签名，设定可见范围（全局/行业/企业/部门），进入版本桶 开放平台负责人 审核通过当天 LeapOpen 发放台 已发布版本 🔧飞书固化
8 通知客户管理员决定启用/默认安装/自动更新；FDE 在客户侧验证可见、下载、安装、运行 提交人；客户管理员 发布后 2 个工作日内 LeapCore、客户群 客户侧验证记录 👤人工判断
9 登记下发记录（包名、版本、客户、scope、日期、负责人） 开放平台负责人 发布当天 多维表格 下发台账 🔧+🤖
10 已上线包按比例人工抽检；新版本重复步骤 2～9 开放平台负责人 每月 1 次 LeapOpen 抽检记录 👤人工判断

5. 交付物与模板

  • 交付物：已签名发布的 Skill/插件版本；初审/二审记录；下发台账；客户侧验证记录
  • 建议模板/表单：开发者入驻申请（主体、联系人、开发方向、所属渠道/客户、是否 FDE）；提交单（包名、版本、类型 Skill/MCP/插件、目标 scope、权限声明、敏感数据说明、安装与更新建议、变更说明、自检结果）；下发台账（包名、版本、客户组织 ID、scope、发布日期、验证结论、负责人）

6. 异常与升级

  • 审核被打回 → 提交人按意见修改后重提 → 同一包打回 2 次以上升级开放平台负责人会审（2 个工作日内）
  • 客户侧插件加载失败且无报错 → 提交人收集日志 → 转 LeapCore 接入研发（1 个工作日内响应）
  • 开放平台不可用导致 LeapCore 场景配置拉取失败 → 开放平台后端立即处理 → 30 分钟内未恢复升级 CTO
  • 不确定是否该下发（如工程版、含插件版本）→ 暂停发布 → 产品总监＋开放平台负责人决定（1 个工作日内）
  • 发现已上线包有安全问题 → 立即下架或回滚版本 → 当天升级 CTO
  • A（升级）说明：上架、下发与可见范围由开放平台负责人拍板（A）；高风险包放行、范围冲突或会审后仍有争议、开放平台故障 30 分钟未恢复、已上线包出现安全问题时升级 CTO

7. 衡量指标

  • 审核周期 = 提交到发布的工作时长，目标：低风险 ≤ 1 个工作日，中高风险 ≤ 3 个工作日
  • 一次通过率 = 首次提交即通过的包 / 提交总数，目标 ≥ 70%
  • 客户侧安装成功率 = 发布后客户验证成功的下发 / 下发总数，目标 ≥ 95%
  • 下发台账完整率 = 有台账记录的下发 / 实际下发，目标 100%
  • 入驻响应时长 = 申请到开通账号，目标 ≤ 1 个工作日

8. 低效诊断

  • 现象：行业版内容如何持续交付、迭代到平台没有规则，开发者反复询问｜依据：「Leap产研测」2026-07
  • 现象：开放平台/开发平台/LeapSkill 叫法混用，规范文档靠私下转发，部门清单靠手工整理同步｜依据：「Leap产研测」2026-07
  • 现象：“如何上架企业级 skill”被销售在不同日期重复提问，没有使用说明，客户无法自助注册｜依据：「Leap反馈群」2026-09
  • 现象：客户需求是“自己管理 Skill”还是“装好的 Skill”未先对齐，导致返工；规范文档以 Word 到处发｜依据：「Leapcore 某燃气客户项目群」2026-08
  • 现象：新开发者需先找人开账号，审核分级与下发边界（工程版是否下发）未定｜依据：「星域」2026-09、「某研究院客户项目群」2026-08
  • 现象：LeapCore 场景配置实时依赖开放平台，无缓存降级，单点风险｜依据：「Leap反馈群」2026-09

9. 分支变体

  • 行业版 Skill（FDE/行业团队开发）：走完整步骤，scope 选行业或指定企业
  • 客户自有 Skill/插件上架企业级：客户先成为开发者/FDE，scope 只开到本企业；兜底方案为我方整理后代为提交下发
  • 插件（含工程版）：须在设置中开启开发者模式本地调试，再提交审核；涉及外联和权限的一律人工二审
  • MCP：当前阶段内置在 Skill 中随包提交
  • 第三方 SaaS（如星域）接入：先开 1～2 小时启动对齐会（业务背景、LeapCore 能力、需求范围、交付周期），提供 MCP 测试用例数据，权限用 OAuth 签发的 JWT 识别，开发者参加 FDE 班后再走本流程

10. 待确认问题

  • 本条与 ECO-06（开放平台第三方接入上架）、RND-64（行业版插件）是否合并？主责是否统一为开放平台负责人？
  • 风险分级口径（低/中/高）与人工二审人是谁？二审 1 个工作日是否可行？
  • 客户自有 Skill 是否允许客户直接提交，还是必须经我方 FDE 代提？
  • 工程版/含插件版本是否下发、由谁决定？
  • 签名方案何时从“组织 ID 弱凭据”升级为强凭据？
  • 开放平台是否需要缓存降级方案作为上线前置条件？
X-FDE-10OpenClaw/龙虾/龙智一体机部署配置交付待新建300

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗5 × 跨5 × 险4

  • 适用场景：政企客户、企业老板或俱乐部客服场景购买或要求部署 OpenClaw 智能体（龙虾）/龙智旗舰版，需要定制配置（人设、飞书多机器人、模型 Key、Skill 包、启动脚本）并接入客户工作流时启动
  • 负责人：主责——部署交付工程师（当前：游家豪、魏宗浩·推断待确认）；协同——客户经理/销售（当前：吴琪、李鹏为、闫登辉·推断待确认）、专属 FDE（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 订单与需求确认 → ② 部署方式与资源决策 → ③ 环境准备（镜像/版本/模型 Key）→ ④ 配置人设、飞书机器人与 Skill 包 → ⑤ 内部全量验收 → ⑥ 交付（上门/寄送/安装包）→ ⑦ 需求沟通会与工作流接入 → ⑧ 经验入踩坑库
  • 交付结果：客户可用的 OpenClaw/龙智实例（版本固定、模型 Key 归属客户、飞书/微信通道可用），部署清单与交付确认记录，需求优先级清单与会议纪要，踩坑库更新
  • 状态依据：2026-03～06 多次为不同政企客户部署，尚无成文的部署手册与踩坑库；版本升级致通道崩溃需重装、Key 归属不清、当天必须装完等临时救火反复出现

1. 场景判定

  • 触发条件：客户（政企领导、企业老板、俱乐部）下单或要求部署 OpenClaw/龙智旗舰版；已交付实例需要换人设、加 Agent、接新数据
  • 典型说法：「这位是你的专属 FDE」
  • 判断问题：客户要的是 OpenClaw/龙智类智能体（不是 LeapCore 一体机标品）？是否需要定制人设、多机器人或接入客户数据？标品安装包能否满足？
  • 不归本流程管：批量盒子/Mac mini 预装龙虾 → 请走 X-DLV-22；LeapCore 一体机出厂装机 → 请走 X-DLV-13；内部群机器人部署 → 请走 RND-81；对客户高层讲课培训 → 请走 X-FDE-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
部署主责 环境搭建、配置、内部验收、交付与远程运维 R/A 部署交付工程师（当前：游家豪、魏宗浩·推断待确认）
客户对接 提交订单、约时间、传达需求、管理客户预期 R 客户经理/销售（当前：吴琪、李鹏为、闫登辉·推断待确认）
专属 FDE 老板版需求沟通、优先级排序、工作流与数据接入 R 专属 FDE（当前：王皓南·推断待确认）
会议与记录 组织需求会、会议记录、跨部门需求征集 C 产品总监（当前：杨萌·推断待确认）
资源与拍板 服务器/镜像/Key 资源审批，新增需求是否承接 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
客户 购买模型订阅、提供人设与权限、确认交付 C 客户方对接人

3. 办之前请准备

  • 订单信息：客户主体、版本（政企/老板版/客服版）、台数、交付方式、期望日期
  • 部署清单：机型或云服务器规格、网络（能否远程桌面）、操作系统（Mac/Windows/容器）、指定 OpenClaw 版本
  • 模型 Key 来源：客户自购订阅或公司临时 Key（须注明转交日期）
  • 人设与职责说明、飞书机器人数量与 AppID、需接入的渠道（飞书/微信）
  • 需打包的 Skill 清单、启动脚本、clawlite 安装包
  • 客户需求清单初稿（公司手册、数据接入、权限、知识沉淀等）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交订单并填写部署需求单 客户经理 签约/确认后 1 个工作日内 飞书表单/多维表格 部署需求单 🔧飞书固化
2 判断能否用标品安装包（clawlite）；可以则直接发包让客户自助充值调试，结束 部署交付工程师 收单后 1 个工作日内 — 方式结论 👤人工判断
3 确定部署方式（现场/带回配置后寄送/云服务器）与资源，申请服务器或镜像 部署交付工程师；CTO 审批 收单后 2 个工作日内 云厂商 OpenClaw 镜像 资源清单 👤人工判断
4 按指定版本安装，锁定版本禁止自动升级；配置模型 Key（优先客户自购） 部署交付工程师 部署日 部署脚本、Deploy-Skill 仓库 可运行实例 🤖自动化
5 创建飞书机器人，把人设、职责、AppID 配入；安装 Skill 包；桌面放启动脚本并标明顺序 部署交付工程师 部署日 飞书开放平台、Skill 包 已配置实例 🔧+🤖
6 按检查表全量自测（各机器人对话、通道、Skill、重启后恢复），确认可远程桌面 部署交付工程师 交付前 1 个工作日 部署检查表 验收记录 👤人工判断
7 交付：上门安装/寄送/远程；现场接入微信等通道，客户确认 部署交付工程师、客户经理 约定交付日 — 交付确认单 👤人工判断
8 老板版/定制版：召开需求沟通会，列优先级，记会议纪要，征集各部门 Skill/插件级需求 专属 FDE、产品总监 交付后 5 个工作日内 飞书日程、妙记 需求优先级清单、纪要 🔧+🤖
9 新增需求逐条评估承接/砍掉，承接项转 X-FDE-08 或产研 专属 FDE；CTO 拍板 收到需求后 2 个工作日内 多维表格 需求结论 👤人工判断
10 记录本次踩坑与配置差异，更新部署手册与踩坑库 部署交付工程师 交付后 2 个工作日内 飞书 wiki 踩坑库条目 🔧飞书固化

5. 交付物与模板

  • 交付物：运行中的实例；交付确认单；部署检查表；需求优先级清单；会议纪要；踩坑库条目
  • 建议模板/表单：部署需求单（客户、版本、台数、机型/云、系统、OpenClaw 版本号、交付方式、模型 Key 来源与转交日期、飞书机器人数与人设、渠道、Skill 清单、期望日期）；部署检查表（各机器人可回复、通道可用、Skill 可调用、重启恢复、远程可达、版本已锁定）；踩坑库（现象、环境、原因、解决办法、日期）

6. 异常与升级

  • 版本升级导致飞书/微信通道崩溃 → 回退到锁定版本重装 → 半天未恢复升级 CTO
  • 公司临时 Key 失效或额度用尽 → 立即通知客户经理推动客户自购 → 当天内恢复，费用归属争议升级 CTO
  • Windows 环境不兼容 → 改用 Mac 或容器部署 → 由部署交付工程师 1 个工作日内给方案
  • 客户领导不断加需求 → 专属 FDE 记录并评估，做不了明确答复做不了 → CTO 2 个工作日内拍板
  • 偶发上下文溢出等原因不明故障 → 收集日志入踩坑库 → 转研发排查（3 个工作日内）
  • A（升级）说明：部署方式、配置与交付验收由部署交付工程师拍板（A）；需申请服务器/镜像/公司临时 Key 等资源、新增需求是否承接、通道崩溃半天未恢复、Key 费用归属有争议时升级 CTO

7. 衡量指标

  • 部署周期 = 收单到交付确认的自然日，目标 ≤ 5 天
  • 一次交付成功率 = 交付后 7 天内无需重装的实例 / 交付实例数，目标 ≥ 90%
  • 客户 Key 自持率 = 使用客户自购 Key 的实例 / 交付实例数，目标 100%（交付后 7 天内）
  • 标品包占比 = 用 clawlite 安装包自助交付的单 / 全部单，持续提升
  • 踩坑库更新率 = 有踩坑记录的交付 / 交付总数，目标 100%

8. 低效诊断

  • 现象：老板版首例交付中，数据迁移方式（复制还是迁移）返工，与现有 LeapCore 的区别客户不清楚｜依据：「Leapcore 龙智旗舰版试用群」2026-09
  • 现象：需求会、会议记录靠提醒才发生，后续开发能否跟上没人确认｜依据：「Leapcore 龙智旗舰版试用群」2026-09
  • 现象：每台机器靠个人经验部署，无部署手册与踩坑库，交接后要重新摸索｜依据：（推断）
  • 现象：版本未锁定，升级后通道崩溃需重装；模型 Key 归属与费用不清｜依据：（推断）

9. 分支变体

  • 老板版龙智（私人 AI 秘书）：指派专属 FDE，重点在人设、公司手册、数据接入与权限，需评估能否串联企业 LeapCore
  • 政府领导装机：多为当天上门，优先求稳，版本锁定，Key 由客户自购
  • 带回配置后寄送：确认全部可用后再寄，保证可远程桌面修复
  • 现场部署（如军校类客户）：提前确认网络与外设限制
  • 俱乐部客服场景：稳定后改为定制 Agent 运行在容器
  • 标品可满足：直接给 clawlite 安装包，客户自助充值调试，不投入现场人力

10. 待确认问题

  • 本条与 X-DLV-22（龙虾批量装机）的边界：是否以“是否需要定制配置/专属 FDE”划分？
  • 主责是部署交付工程师还是 FDE？两位当前人员如何分工？
  • 公司临时 Key 最长允许使用多久？费用由谁承担？
  • 锁定的 OpenClaw 版本由谁维护、多久评估升级一次？
  • 部署手册与 Deploy-Skill 仓库何时可用？是否已有成文版本？
X-FDE-11客户试点开通、驻场陪跑与分层培训待新建180

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险3

  • 适用场景：行业版进入客户试点、客户部署后“不会用”、或客户高层/政府单位需要授课时，开通席位、分层培训并安排 FDE 驻场陪跑
  • 负责人：主责——FDE 子部门负责人（当前：李凯·推断待确认）；协同——产品总监/试点统筹（当前：杨萌·推断待确认）、客户经理（当前：吴琪、闫登辉、杜中瑞·推断待确认）、驻场 FDE（当前：王满·推断待确认）、部署交付工程师（当前：游家豪·推断待确认）、人事（驻场打卡，当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 试点立项与 FDE 指派 → ② 客户需求调研 → ③ 开通席位并分配 → ④ 交付当天基础操作教学 → ⑤ 分层正式培训 → ⑥ 驻场陪跑与需求评审 → ⑦ 反馈汇总回流开发 → ⑧ 试点复盘
  • 交付结果：已开通并分配的席位清单、各部门需求调研表、培训记录与资料、驻场周报、试点反馈清单与复盘结论
  • 状态依据：2026-07～09 每个试点客户临时安排；培训讲师与内容临时追问“定好了吗”、需求调研表要追问位置、驻场打卡临时找人事设置；客户要求“形成一个 SOP”但团队术语未对齐

1. 场景判定

  • 触发条件：行业版签约或进入试点；客户反馈“装好了但不会用”；客户高层/政府单位邀请讲课；客户续费前需陪跑提升使用深度
  • 典型说法：「请帮忙协调多方时间」「培训的内容和谁去讲，定好了吗」「他们看文档也用不来标品」「需要形成一个 SOP」「教他们董事长用小龙虾」
  • 判断问题：对象是已部署或试点中的客户？目的是让客户用起来（而不是对外招生授课）？是否需要 FDE 到场？
  • 不归本流程管：对外 FDE 培训班开课 → 请走 X-FDE-17；交付上线时的使用手册与全员培训 → 请走 X-DLV-28；渠道/销售产品培训 → 请走 SAL-29；对外布道讲课排班 → 请走 ECO-13；账号/组织开通操作 → 请走 X-DLV-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 定试点方案、指派 FDE、确定培训分层与讲师 A FDE 子部门负责人（当前：李凯·推断待确认）
试点统筹 立项、节点跟踪、需求评审会组织 R 产品总监（当前：杨萌·推断待确认）
客户协调 协调客户时间、对接人、客户预期管理 R 客户经理（当前：吴琪、闫登辉、杜中瑞·推断待确认）
驻场 FDE 需求调研、陪跑、收集与汇总反馈 R 驻场 FDE（当前：王满·推断待确认）
基础教学 交付当天教对接人基础操作 R 部署交付工程师（当前：游家豪·推断待确认）
驻场考勤 设置驻场地点打卡 C 人事专员（当前：待指定）
兜底 资源冲突、对高层授课人选拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
讲师 按层级授课、准备课件与演示环境 R 培训讲师（按场次由 FDE 子部门负责人指定）

3. 办之前请准备

  • 合同/试点协议中的席位数、试点周期、交付内容
  • 客户组织架构、各部门对接人与可培训时段
  • 需求调研表与问卷模板（部门、场景、频次、现有工具、期望产出）
  • 培训分层课件：基础功能 / 用 Agent 解决简单任务 / 用 skill-creator 沉淀流程 / 系统对接定制
  • 演示环境与内测包（先在虚拟机测通）、视频教程链接
  • 驻场地点、到场方式、打卡设置

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建试点任务，指派驻场 FDE，客户经理约客户时间 产品总监、FDE 子部门负责人、客户经理 签约/立项后 2 个工作日内 飞书任务、多维表格 试点任务卡 🔧飞书固化
2 发放调研表与问卷，收集各部门需求与原始材料 驻场 FDE 立项后 5 个工作日内 飞书表单 需求调研一览表 🔧+🤖
3 开通席位，按工程/业务特性优先分配给适配部门 驻场 FDE、客户经理 部署完成当天 LeapCore 管理后台 席位分配清单 👤人工判断
4 交付当天教对接人基础操作，并发视频教程 部署交付工程师 交付当天 视频教程 基础教学记录 🔧飞书固化
5 确定培训日期、讲师与层级，提前 3 个工作日通知；现场环境提前测通 FDE 子部门负责人 交付后 10 个工作日内开课 飞书日程 培训计划 👤人工判断
6 分层培训：基础功能→Agent 解决简单任务→skill-creator 沉淀→系统对接（需驻场 FDE） 讲师、驻场 FDE 按计划 课件、演示环境 培训签到与资料 👤人工判断
7 驻场陪跑：帮客户梳理业务、做 Skill，召开驻场需求评审会（提前 1 天通知到场方式与打卡） 驻场 FDE、产品总监 试点期内每周 飞书日程、考勤 评审纪要 👤人工判断
8 每周汇总试点反馈（问题、需求、使用度），转开发 驻场 FDE 每周五前 多维表格 试点周报、反馈清单 🔧+🤖
9 试点结束复盘：使用成熟度、续费/扩容建议、培训资料沉淀 FDE 子部门负责人 试点结束后 5 个工作日内 飞书文档 试点复盘报告 👤人工判断

5. 交付物与模板

  • 交付物：试点任务卡；需求调研一览表；席位分配清单；培训计划与签到；驻场周报；试点复盘报告
  • 建议模板/表单：试点跟踪多维表格（客户、行业版、席位数、驻场 FDE、当前阶段、培训层级完成情况、反馈数、下一节点、日期）；客户成熟度评估表（基础使用/Agent 简单任务/Skill 沉淀/系统对接，各层是否达成）；现场问题记录表（问题、部门、处理人、状态）

6. 异常与升级

  • 培训因内部事务延期 → 客户经理当天告知客户并重新约期 → 延期超 1 周升级 FDE 子部门负责人
  • 客户把产品“当豆包用”、使用度低 → 驻场 FDE 安排第二层培训并做 1 个示范 Skill → 2 周无改善升级产品总监
  • 驻场需求超出试点范围 → 记录并转 X-FDE-08 评估 → 不当场承诺
  • 对外演示/授课环境故障 → 切换备用环境 → 课后 1 个工作日内复盘
  • 客户催部署 → 转 X-DLV-19（客户现场/远程部署实施与上门安排）→ 客户经理当天回复预计时间
  • A（升级）说明：试点方案、FDE 指派与培训分层由 FDE 子部门负责人拍板（A）；FDE 资源与其他项目冲突、对客户高层/政府单位授课人选需定夺时升级 CTO

7. 衡量指标

  • 席位激活率 = 试点期内登录使用的席位 / 开通席位，目标 ≥ 80%
  • 开课及时率 = 交付后 10 个工作日内完成首次正式培训的客户 / 试点客户，目标 ≥ 90%
  • 成熟度达标率 = 达到第三层（自建 Skill）的部门 / 参训部门，目标 ≥ 30%
  • 反馈闭环率 = 已回复处理结论的反馈 / 反馈总数，目标 ≥ 90%
  • 试点转化率 = 试点后续费或扩容的客户 / 试点客户

8. 低效诊断

  • 现象：对领导/董事长授课靠临时分配与现场随机应变，无培训材料和演示环境清单｜依据：「鼎慧产研决策部」2026-03
  • 现象：培训内容与讲师在开课前仍未定，需追问｜依据：「【行业版Leapcore】工程版」2026-07
  • 现象：需求调研表需反复追问存放位置；驻场打卡在事后临时设置｜依据：「【行业版Leapcore】工程版」2026-07、2026-09
  • 现象：FDE、标准版、行业版术语不统一，内部争论近 20 轮仍未形成 SOP；“FDE 不管这个”的边界不清｜依据：「LeapCoreFDE」2026-07

9. 分支变体

  • 行业版试点（如某工程咨询客户）：完整走步骤 1～9，内部销售培训优先于客户培训
  • 小范围试用客户：跳过驻场，只做步骤 3～6 与反馈汇总
  • 政府/中小企业服务机构试跑：以培训和示范为主，驻场 FDE 帮梳理业务后做 Skill，可收费
  • 客户高层/政府单位授课：内测包先在虚拟机测通，突出实操与价值演示；政府客户可评估“赠送走生态”
  • 老板版龙智：并入 X-FDE-10 的需求沟通环节

10. 待确认问题

  • 主责是 FDE 子部门负责人还是产品总监（试点统筹）？
  • 驻场 FDE 是否收费？收费标准与合同口径由谁定？
  • 四层培训分层是否作为公司统一口径？各层课件由谁维护？
  • 10 个工作日内首次开课是否可行？
  • 试点期标准时长（如 4 周）是否需要约定？
X-FDE-12FDE/开发者 LeapCore 调试环境与额度发放待新建24

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗2 × 跨3 × 险2

  • 适用场景：开放平台批准插件开发者入驻，或 FDE 开始真实开发，需要一个 LeapCore 调试环境和模型额度时启动
  • 负责人：主责——开放平台负责人（当前：郭逸非·推断待确认）；协同——云资源与运维（当前：宋祺睿·推断待确认）、研发负责人（当前：王皓南·推断待确认）、产品总监（当前：杨萌·推断待确认）、模型网关与渠道（当前：杨明学·推断待确认）、财务专员（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；额度政策终裁——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 开发者入驻审批通过 → ② 提交环境申请 → ③ 判定环境类型与名额 → ④ 创建云端实例并发 VPN → ⑤ 发放赠送额度 → ⑥ 讲解插件调试方法 → ⑦ 登记台账 → ⑧ 到期回收
  • 交付结果：开发者可登录的 LeapCore 调试实例（或本地 mock 环境）、VPN 账号、到账的赠送额度，以及环境与额度台账
  • 状态依据：2026-09 才开始设计“给 FDE 批准调试环境”的特殊交付流程，需求未入工单、提给谁不清；额度政策仅群内口头拍板“首次赠送[金额已隐去]，其余自充”，未成文

1. 场景判定

  • 触发条件：开放平台审批通过开发者/团队；FDE 开始为客户真实开发需要调试；合作伙伴签约需要开发环境
  • 典型说法：「就是特殊交付流程，给 FDE 批准一个调试环境」「一个开发者或一个团队需要一个 LeapCore 环境」「FDE 要自己买 LeapCore 余额吗」
  • 判断问题：申请人是否已通过开放平台/FDE 资质审核？用途是开发调试（不是上课、不是演示、不是客户生产）？
  • 不归本流程管：内部测试/演示账号额度 → 请走 FIN-16；研发调用模型 API Key → 请走 RND-27；培训班学员账号与额度 → 请走 X-FDE-17；客户购买额度 → 请走 X-CS-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 审核申请、判定环境类型与名额、维护台账 A 开放平台负责人（当前：郭逸非·推断待确认）
实例与 VPN 通过 v5 cloud 创建实例、发 VPN、回收 R 云资源与运维（当前：宋祺睿·推断待确认）
成本把关 评估环境成本、是否人均一台 C 研发负责人（当前：王皓南·推断待确认）
额度发放 按政策充值赠送额度、设成本价倍率 R 模型网关与渠道（当前：杨明学·推断待确认）
成本归集 赠送额度与环境成本入账 I 财务专员（当前：待指定）
工单入口 维护申请入口与说明 C 产品总监（当前：杨萌·推断待确认）
兜底 环境成本超预算、人均配置等流程争议拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
额度政策终裁 赠送额度政策与追加赠送审批 A（升级） CEO（当前：邴龙志·推断待确认）
申请人 提交调试环境申请、按期续期或归还 R 内部 FDE / 外部开发者 / 合作伙伴

3. 办之前请准备

  • 开放平台账号与入驻审批结果
  • 申请人类型：内部 FDE / 外部开发者个人 / 团队 / B 端合作伙伴
  • 用途说明：开发对象（Skill/插件/MCP）、对应客户或项目、预计使用周期
  • 是否已有自购 LeapCore 设备（合作伙伴）
  • 额度需求估算

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入驻审批通过后，申请人提交调试环境申请 申请人 审批通过后 飞书表单 环境申请单 🔧飞书固化
2 判定类型：本地 mock / 云端 LeapCore＋VPN / 合作伙伴自购；按团队核定名额（默认一个团队一个） 开放平台负责人 申请后 1 个工作日内 飞书审批 审批结论 👤人工判断
3 审批通过自动生成实例创建工单 系统 实时 飞书审批→工单 实例工单 🤖+👤
4 通过 v5 cloud 创建 LeapCore 实例、发 VPN 账号 云资源与运维 工单后 1 个工作日内 v5 cloud、LeapVPN 实例地址、VPN 账号 🤖自动化
5 按政策发放额度：真实开发首次赠送[金额已隐去]，其余自充，倍率按成本价；上课场景走培训额度 模型网关与渠道 实例开通当天 额度后台 充值记录 🔧+👤
6 发送开发指引：插件开发指南、DevKit、本地调试方法 开放平台负责人 实例开通当天 飞书 wiki 开通通知 🔧飞书固化
7 登记台账（申请人、类型、实例、VPN、额度、开通与到期日） 开放平台负责人 开通当天 多维表格 环境台账 🔧+🤖
8 到期前 7 天提醒续期；无续期则回收实例与 VPN 系统；云资源与运维 到期日 多维表格提醒 回收记录 🤖自动化

5. 交付物与模板

  • 交付物：调试实例与 VPN 账号；额度充值记录；环境台账；回收记录
  • 建议模板/表单：环境申请单（申请人/团队、类型、开放平台账号、用途、对应客户/项目、周期、是否自购设备、额度需求）；环境台账（以上字段＋实例 ID、VPN 账号、赠送额度、累计自充、到期日、状态）；《FDE 额度规则》（赠送额度、倍率、上课与真实开发区分、超额处理）

6. 异常与升级

  • 申请不知道提给谁 → 统一走飞书表单入口 → 入口失效时找开放平台负责人（当天）
  • 环境成本超预算或申请人均一台 → 研发负责人评估 → CTO 2 个工作日内决定
  • 额度不足仍需开发 → 申请人自充；有业务价值需追加赠送 → 报 CEO 审批（3 个工作日内）
  • 实例长期闲置 → 提醒 1 次后回收 → 有争议升级开放平台负责人
  • A（升级）说明：环境类型、名额与台账由开放平台负责人拍板（A）；环境成本超预算或要求人均一台时升级 CTO；需在政策外追加赠送额度或调整额度政策时升级 CEO

7. 衡量指标

  • 环境开通时长 = 申请提交到可登录的工作时长，目标 ≤ 2 个工作日
  • 台账覆盖率 = 已登记实例 / 实际在用实例，目标 100%
  • 闲置实例率 = 30 天无调用的实例 / 在用实例，目标 ≤ 10%
  • 赠送额度成本 = 每月赠送额度合计，按月报给财务

8. 低效诊断

  • 现象：开发者调试环境需求在群里讨论，未进工单，不清楚该提给谁｜依据：「Leap产研决策部」2026-09
  • 现象：开放平台负责人阶段性不在岗时分工混乱；是否人均一台、FDE 是否去客户处口径不一｜依据：「Leap产研决策部」2026-09
  • 现象：FDE 额度由谁买单（FDE 自付 vs 公司承担）意见分歧，只在群内口头拍板未沉淀｜依据：「Leapcore 龙智旗舰版试用群」2026-09

9. 分支变体

  • 本地 mock 环境：适合轻量 Skill 开发，不占云资源
  • 云端 LeapCore＋VPN：默认方案，适合插件与系统对接开发
  • B 端合作伙伴：要求自购一台 LeapCore，不发云端实例
  • 上课 vs 真实开发：上课用培训额度（走 X-FDE-17），真实开发走本流程赠送＋自充

10. 待确认问题

  • 首次赠送额度（[金额已隐去]）是否一次性，还是按月赠送？“干得好再送”的标准是什么？
  • 一个团队一个环境是否为正式口径？环境默认有效期多长？
  • v5 cloud 自动创建实例何时可用？之前由谁手工创建？
  • 赠送额度与环境成本计入哪个成本中心？
X-FDE-13内部 FDE 需求挖掘、开发与验收待优化300

状态：待优化｜证据：有证据（卡片 9 张 / 会话 8 个）｜优先级：频5 × 耗4 × 跨5 × 险3

  • 适用场景：公司内部 FDE 计划推进中各部门挖掘 AI 场景，或业务部门提出内部系统需求（合同、积分、CMS、CRM、考勤、采购等），需要澄清、开发 Skill 或业务系统并验收时启动
  • 负责人：主责——内部 FDE 统筹（当前：杨萌·推断待确认）；协同——需求评估与 Skill 验收（当前：佘天禾·推断待确认）、FDE 子部门负责人/产品设计（当前：李凯·推断待确认）、内部 FDE 开发（当前：裴建武、陈子康、邓乾、郭逸非·推断待确认）、部署运维（当前：杨睿·推断待确认）、业务拍板人（当前：田杰、赵雪冰·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）、各部门 FDE；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）；方向发起——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 统一入口提需求 → ② FDE 追问澄清并画业务流程图 → ③ 分级与采纳评估 → ④ 指定负责人与排期 → ⑤ AI 拆工单并群内评审 → ⑥ 开发（Skill 或系统 MVP）→ ⑦ preview 部署与业务验收 → ⑧ 每日进度同步与按天迭代
  • 交付结果：带分级和负责人的需求台账；业务确认的流程图与需求文档（需求描述＋技术约束）；通过验收的 Skill 或上线的内部系统；测试验收记录；每日进度汇总文档
  • 状态依据：已有工作框架、需求多维表格与仪表盘、验收文档、Gitea 仓库与 preview 环境，但 2026-07～10 反复催办、需求“填了不做”、需求无负责人无排期、业务反馈“和预想不一样”返工约 8 次

1. 场景判定

  • 触发条件：内部 FDE 阶段任务启动（如“每个部门找 10 个最痛的小场景”）；业务部门提出系统需求或一句话需求；已上线系统需要新功能
  • 典型说法：「下周每个部门先找 10 个最痛的小场景」「经典一句话需求」「先 AI+grilling 拆成工单，传上来大家 Review 再执行」「先自己捋明白业务流程」「报过需求啊没后续了」
  • 判断问题：需求方是公司内部部门？目标是内部提效（不是对客户交付）？能否先用飞书现成能力（共享日历、多维表格）解决？
  • 不归本流程管：产品功能需求 → 请走 X-PRD-05、RND-04；系统开发完成后的内测、业务验收与正式发布 → 请走 X-FDE-20；Skill 效果前后测与竞品对比 → 请走 X-FDE-14；研发日报规范 → 请走 RND-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 维护需求入口与台账、催进度、标出落后部门 A 内部 FDE 统筹（当前：杨萌·推断待确认）
需求评估与验收 判断可采纳、拆解大需求、Skill 验收、统计 R 需求评估与 Skill 验收（当前：佘天禾·推断待确认）
产品设计 合需求、砍需求、指定系统负责人 R FDE 子部门负责人（当前：李凯·推断待确认）
开发 澄清、画流程图、拆工单、开发、测试、用户手册 R 内部 FDE 开发（当前：裴建武、陈子康、邓乾、郭逸非·推断待确认）
部署 preview 域名、服务器、Caddy 配置 R 部署运维（当前：杨睿·推断待确认）
业务拍板 确认流程图与业务验收；合规口径冲突时裁定 A（升级） 业务拍板人（当前：田杰、赵雪冰·推断待确认）
提需人 通过统一表单提需求、提供材料、参与对齐 R 业务部门提需人
合规口径 审批层级、确收规则、合同模板 C 财务负责人（当前：黄梦婷·推断待确认）、法务负责人（当前：李瑶·推断待确认）
部门 FDE 挖掘本部门场景、提供脱敏材料、做 Skill R 各部门 FDE
兜底 方法论、优先级冲突、技术方向拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 需求描述：场景、频次、当前做法、期望产出（越详细越好，可直接语音转文字）
  • 脱敏真实材料与样例文件
  • 现有工作流程图或思维导图（没有就由 FDE 先画）
  • 业务拍板人与合规负责人（涉及合同、资金、人事时必填）
  • 是否已有类似系统或飞书能力可复用

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 通过统一表单提需求，附材料与流程图 业务提需人/部门 FDE 随时 飞书表单→多维表格 需求单 🔧飞书固化
2 追问背景，用 AI（grilling）结构化需求；画业务流程图（泳道图），变动直接标注 内部 FDE 开发 提交后 1 个工作日内 AI、飞书画板 结构化需求＋流程图 🤖+👤
3 分级：浅层（与豆包等对比划边界）/深度（Skill/工作流/定制系统）；能用飞书现成能力的直接给方案 需求评估人 提交后 2 个工作日内 多维表格 分级与采纳结论 👤人工判断
4 指定负责人与排期，回写台账并通知提需人 FDE 子部门负责人 采纳当天 多维表格 负责人、排期 🔧飞书固化
5 约业务方与合规负责人对齐流程图（不超过 2 小时） 内部 FDE 开发 开发前 飞书会议 确认版流程图、纪要 👤人工判断
6 需求文档拆两块（需求描述＋技术约束），AI 拆工单，上传群内评审 内部 FDE 开发 对齐后 1 个工作日内 飞书文档、工单系统 评审通过的工单 🤖+👤
7 开发：Skill 先做 1～2 个送验收；系统先做 MVP（20/80），含单测、E2E、冒烟、用户手册 内部 FDE 开发/部门 FDE 按排期 Gitea、Codex 等 可测版本 🤖自动化
8 部署 preview 域名，拉反馈群；业务白天反馈，下班前拟好工单，夜间 Agent 跑，次日验收 部署运维、内部 FDE 开发 按天迭代 preview 环境、反馈群 迭代版本 🔧+🤖
9 每日在群里同步：已完成/正在做/将要做，汇总到置顶日报文档，不用 AI 黑话 内部 FDE 开发 每个工作日 18:00 前 飞书文档、机器人 日报 🔧+🤖
10 Skill/系统验收：填测试验收记录（流程截图、问题、产出文件），通过后进入下一需求或转 X-FDE-20 上线 需求评估人/业务拍板人 提交验收后 2 个工作日内 验收文档 验收记录 👤人工判断
11 每周标出进度落后部门与逾期需求 内部 FDE 统筹 每周一 仪表盘 周进度看板 🤖自动化

5. 交付物与模板

  • 交付物：需求台账；确认版业务流程图；需求文档；工单；Skill 或系统版本；测试验收记录；每日进度汇总
  • 建议模板/表单：需求单（部门、提需人、场景、频次、当前做法、期望产出、材料链接、流程图、业务拍板人、合规负责人、分级、是否采纳、负责人、排期、状态）；验收记录（需求编号、流程截图、问题描述、产出结果、结果文件链接、结论、验收人）；日报（日期、系统、已经做了/正在做/将要做、阻塞与需要协助）

6. 异常与升级

  • 需求无负责人超过 3 个工作日 → 内部 FDE 统筹点名 → FDE 子部门负责人当天指定
  • 需求过大无法用 Skill 实现 → 需求评估人拆解 → 拆不动的转定制系统排期
  • 业务反馈与预期差距大 → 停止开发，重新对齐流程图 → 2 个工作日内完成
  • 审批层级、确收规则等口径冲突 → 财务/法务负责人给书面口径 → 仍冲突升级业务拍板人
  • 跨团队接口依赖无响应 → 群内提醒并建工单 → 超 2 个工作日升级 CTO
  • 当日未同步进度 → 次日 10:00 前机器人提醒 → 连续 2 次升级 FDE 子部门负责人
  • A（升级）说明：需求入口、分级排期与进度由内部 FDE 统筹拍板（A）；审批层级、确收规则等合规口径经财务/法务给出书面意见后仍冲突时升级业务拍板人；跨团队依赖超 2 个工作日无响应、优先级冲突或技术方向分歧时升级 CTO

7. 衡量指标

  • 需求响应时长 = 提交到给出分级与负责人，目标 ≤ 2 个工作日
  • 需求采纳转化率 = 已做成 Skill/系统并验收的需求 / 采纳需求，目标 ≥ 60%
  • 返工率 = 因需求理解偏差重做的工单 / 总工单，目标 ≤ 15%
  • 日报按时率 = 按时同步的工作日 / 应同步工作日，目标 ≥ 95%
  • 部门落地数 = 每部门已验收 Skill 数，按月统计

8. 低效诊断

  • 现象：需求质量参差，“很多需求填了但不做 Skill”，表格更新滞后导致状态显示错误｜依据：「公司内FDE」2026-07、「公司内FDE」2026-08
  • 现象：部分部门需求挖掘与落地进度落后，靠群内反复催办｜依据：「公司内FDE」2026-07、「公司内FDE」2026-08
  • 现象：系统需求“谁负责沟通和写方案”不清，无负责人就无排期，需求报了没后续｜依据：「公司内FDE」2026-08、「公司内FDE」2026-10
  • 现象：未先画业务流程图就开发，权限、草稿计逾期、报价审批层级前后冲突反复修改｜依据：「cms反馈」2026-09、「cms反馈」2026-10
  • 现象：进度不主动同步，靠“进度呢”催问；AI 生成汇报含大量黑话｜依据：「公司内FDE」2026-09、「公司内FDE」2026-10
  • 现象：会后材料要催、文档链接打不开需重发｜依据：「cms反馈」2026-09

9. 分支变体

  • 部门 AI 场景（Skill）：浅层需求只做对比划边界；深度需求先做 1～2 个 Skill 送验收再扩展
  • 合同/CMS 系统：涉及法务、财务四级审批，流程图必须经财务与法务确认
  • 积分系统：涉及董事会或签审批
  • CRM/渠道系统：销售与财务共同确认，注意与 CMS 打通
  • 零食/集采等行政小工具：工具可先行，但上线前补流程确认；账号用飞书 SSO，避免名单快照
  • 与飞书/终端管控平台/审批深耦合的系统：拆出业务逻辑，通过数据流 API 打通

10. 待确认问题

  • 内部 FDE 主责是产品总监（统筹）还是 FDE 子部门负责人？
  • 是否以多维表格作为唯一需求入口，私聊提需一律不受理？
  • 流程图对齐会是否作为开发前强制节点？
  • 日报 18:00 前同步是否作为考核项？
  • 本条与 X-FDE-20、RND-04 的边界是否按“开发完成后转 X-FDE-20”划分？
X-FDE-14内部 FDE 成果评测与阶段性案例收集待优化90

状态：待优化｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨5 × 险2

  • 适用场景：部门 Skill 通过验收后需验证改进效果并与竞品对比，或内部 FDE 进入阶段性周报（每周功能点对比与场景化案例）时启动
  • 负责人：主责——FDE 成果归集专员（当前：佘天禾·推断待确认）；协同——FDE 评测（当前：盛亦舒·推断待确认）、内部 FDE 统筹（当前：杨萌·推断待确认）、FDE 子部门负责人（当前：李凯·推断待确认）、市场内容（当前：韩诗琪、许君·推断待确认）、各部门 FDE；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 已验收 Skill 进入评测 → ② 前测后测并录屏 → ③ 与竞品对比 → ④ 结果入表并派优化 → ⑤ 收敛 Skill 输出后重测 → ⑥ 各部门按周提交功能点与案例 → ⑦ 自动统计缺口并提醒 → ⑧ 优秀案例转市场与产品
  • 交付结果：评测多维表格（前后测与竞品对比结论、录屏链接）；每周各部门功能点对比、3 好 3 坏评价、场景化案例；案例转市场推文与产品改进的清单
  • 状态依据：已有多维表格、归集 wiki 目录与模板，周节奏固定，但 2026-08 反复点名未交部门约 5 次，云文档格式不统一靠人工统计，评测无统一标准导致 Skill 输出格式随机

1. 场景判定

  • 触发条件：部门 Skill 通过 X-FDE-13 验收；阶段任务要求每周提交功能点对比与案例；产品需要评估 LeapCore 相对竞品的表现
  • 典型说法：「改进之后的 LeapCore 效率比 WorkBuddy 高，已录屏对比」「第二阶段产出收集未交：人事、财务」「大家云文档格式不太一致，数量是我自己统计的」
  • 判断问题：评测对象是内部 FDE 产出的 Skill 或场景？目的是内部评估与案例沉淀（不是产品发版评测）？
  • 不归本流程管：产品级竞品调研 → 请走 X-PRD-02；Agent 评测集与 Benchmark → 请走 RND-82；Skill 开发与验收 → 请走 X-FDE-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 归集产出、统计数量与缺口、催交 A FDE 成果归集专员（当前：佘天禾·推断待确认）
评测执行 前测后测、录屏、竞品对比 R FDE 评测（当前：盛亦舒·推断待确认）
派优化 根据评测结果指派优化、维护竞品对比表 R 内部 FDE 统筹（当前：杨萌·推断待确认）
输出稳定性 给出格式约束、示例写死等方案 C FDE 子部门负责人（当前：李凯·推断待确认）
提交人 每周提交功能点、对比、案例 R 各部门 FDE
案例使用 案例转推文与宣传 I 市场内容（当前：韩诗琪、许君·推断待确认）
兜底 阶段要求与评价口径 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 已验收的 Skill 及对应原始流程（改进前做法）
  • 测试输入样例（同一组输入用于前测、后测、竞品）
  • 竞品账号（豆包、WorkBuddy、Codex 等）
  • 录屏工具；评测多维表格链接
  • 周提交模板与统一归集目录

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 Skill 验收通过后自动进入评测队列 系统 验收当天 多维表格 评测任务 🔧飞书固化
2 用同一组输入做前测（原做法）与后测（Skill），记录耗时、质量并录屏 FDE 评测 入队后 3 个工作日内 LeapCore、录屏 前后测记录 👤人工判断
3 同输入在竞品上跑一遍对比 FDE 评测 同上 竞品产品 对比结果 👤人工判断
4 结果写入评测表，AI 生成对比摘要 FDE 评测 测完当天 多维表格、AI 评测结论 🤖自动化
5 根据结论派优化项给部门 FDE 内部 FDE 统筹 结论后 1 个工作日内 飞书任务 优化任务 🔧飞书固化
6 收敛 Skill：固定输出格式、示例写死、通用格式加占位符，改完重测 部门 FDE、成果归集专员 3 个工作日内 Skill 新版 Skill、重测记录 🤖+👤
7 各部门每周提交：10 个功能点对比、3 好 3 坏、3 个场景化案例 各部门 FDE 每周五 18:00 前 多维表格表单 周产出 🔧飞书固化
8 自动统计各部门提交数量与缺口，按人推送提醒；AI 检查格式 系统；成果归集专员 每周一 10:00 多维表格自动化 缺口清单 🤖自动化
9 评选优秀案例，转市场做推文、转产品做改进 成果归集专员、内部 FDE 统筹 每周一 飞书文档 案例转出清单 👤人工判断

5. 交付物与模板

  • 交付物：评测表（含录屏链接）；优化任务；每周部门产出；缺口清单；案例转出清单
  • 建议模板/表单：评测记录（Skill 名称、部门、测试输入、前测耗时与结果、后测耗时与结果、竞品结果、结论、录屏链接、评测人、日期）；周产出表单（部门、提交人、周次、功能点×10〔功能、LeapCore 表现、竞品表现〕、3 好、3 坏、案例×3〔场景、过程、结果、截图〕）

6. 异常与升级

  • 改进后效果反而变差 → 回退旧版 Skill 并重测 → 2 个工作日内找出原因，必要时请 FDE 子部门负责人支持
  • 输出格式随机不稳定 → 用示例写死与格式约束 → 重测仍不稳定转产品评估
  • 部门连续 2 周未交 → 成果归集专员点名 → 升级内部 FDE 统筹，再不交报 CEO
  • 数量满足但质量差 → 打回补充 → 计入未交
  • A（升级）说明：评测结论归集、缺口统计与催交由 FDE 成果归集专员负责（A）；部门经内部 FDE 统筹催办后仍连续未交、阶段要求或评价口径需调整时升级 CEO

7. 衡量指标

  • 评测完成时长 = 验收到评测结论，目标 ≤ 3 个工作日
  • 后测提效幅度 = (前测耗时 − 后测耗时) / 前测耗时，按 Skill 统计
  • 周提交按时率 = 按时足量提交的部门 / 应提交部门，目标 ≥ 90%
  • 案例转化数 = 每月转为市场内容或产品需求的案例数

8. 低效诊断

  • 现象：某 Skill 改进后效果反而变差需重测；某 Skill 每次输出格式随机，缺统一评测标准与格式规范｜依据：「公司内FDE」2026-07
  • 现象：分工表未更新，评测状态与实际不符｜依据：「公司内FDE」2026-08
  • 现象：人事、财务、行政等部门反复被点名未交或数量不足｜依据：「公司内FDE」2026-08
  • 现象：各部门云文档格式不一致，数量靠人工统计，排版需返工｜依据：「公司内FDE」2026-08

9. 分支变体

  • 评测对象不同：反馈群日报抓取、UI 走查验收、活动执行方案生成、JD 优化等 Skill，测试输入与评价维度按场景定制
  • 浅层需求：只做与竞品的对比以划定 AI 能力边界，不做前后测

10. 待确认问题

  • 主责为成果归集专员是否合适？评测执行是否固定为专人？
  • 周提交“10 个功能点 + 3 好 3 坏 + 3 个案例”是否仍为当前要求？
  • 是否统一用多维表格表单替代各部门云文档？
  • 评测维度（耗时、质量评分、稳定性）是否需要成文标准？
X-FDE-15内部 FDE 与 LeapCore 培训组织及补课待优化60

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗2 × 跨5 × 险2

  • 适用场景：新工具/新能力上线、内部 FDE 阶段启动，或部分同事错过培训需要补课时，组织面向内部员工的 FDE/LeapCore 培训
  • 负责人：主责——FDE 培训主讲（当前：李凯·推断待确认）；协同——内部 FDE 统筹（当前：杨萌·推断待确认）、培训 QA 整理（当前：佘天禾·推断待确认）、研发负责人（研发参训点名，当前：丁震宇·推断待确认）、各部门 FDE；兜底——CEO（发起人，当前：邴龙志·推断待确认）
  • 核心流程：① 确定主题与对象 → ② 约时间与会议室并发日程 → ③ 授课并录制妙记 → ④ 发资料包 → ⑤ 布置作业与成果展示 → ⑥ 缺课补课 → ⑦ 培训总结入 wiki
  • 交付结果：培训录像与妙记纪要、资料包（PDF、教程 wiki、skill 压缩包）、参训与缺课名单、作业与成果展示记录、培训总结 wiki
  • 状态依据：已有教程 wiki、启动会纪要、培训总结 wiki 和固定节奏，但同一培训多次补做、启动会临时改期、“示例文档在哪”找不到等问题反复出现

1. 场景判定

  • 触发条件：内部 FDE 阶段启动；LeapCore 或 AI 工具出新能力；新研发/新部门加入；有同事缺课
  • 典型说法：「下午 2 点会议室做 LeapCore 入门级教程」「把没听的同事全部再做一次培训」「暂定下周三成果展示」「LeapCore 产品培训，你们也来学习」
  • 判断问题：受众是内部员工？内容是 FDE 方法或 LeapCore/AI 工具使用？
  • 不归本流程管：公司级内部培训与分享会（价值观、制度等） → 请走 HR-23；对外 FDE 培训班 → 请走 X-FDE-17；新人入职培训 → 请走 HR-06；客户培训 → 请走 X-FDE-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
主讲 设计内容、授课、出作业、补课 R/A FDE 培训主讲（当前：李凯·推断待确认）
统筹 约时间、启动会说明分工、通知 R 内部 FDE 统筹（当前：杨萌·推断待确认）
QA 整理 整理问答、写培训总结 R 培训 QA 整理（当前：佘天禾·推断待确认）
研发参训 点名研发参加产品培训 C 研发负责人（当前：丁震宇·推断待确认）
学员 参训、完成作业 R 各部门 FDE
兜底 培训方向与优先级 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 培训主题、对象名单、预期产出（如每人做 1 个可复用 Skill）
  • 会议室＋线上会议链接；开启妙记录制
  • 资料：课件 PDF、教程 wiki、安装教程、skill-creator 压缩包、示例文档
  • 作业说明与成果展示日期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定主题、对象与日期，批量发飞书日程（线下＋线上） 内部 FDE 统筹 培训前 3 个工作日 飞书日程 日程邀请 🔧飞书固化
2 资料放入固定资料索引页 FDE 培训主讲 培训前 1 个工作日 飞书 wiki 资料索引 🔧飞书固化
3 授课并开启妙记录制；记录参会名单 FDE 培训主讲 培训当天 飞书会议、妙记 录像、参会名单 🔧+🤖
4 发纪要、录像与资料链接到群 内部 FDE 统筹 培训后当天 飞书群 纪要卡片 🤖自动化
5 布置作业，定成果展示会日期 FDE 培训主讲 培训当天 飞书任务 作业任务 🔧飞书固化
6 对缺课人员推送录像，必要时集中补课一次 内部 FDE 统筹、主讲 培训后 5 个工作日内 妙记、飞书日程 补课记录 🔧飞书固化
7 召开成果展示会，点评作业 FDE 培训主讲 培训后约 1 周 飞书会议 展示记录 👤人工判断
8 整理 QA 与培训总结入 wiki，补充 AI 助教知识库 培训 QA 整理 展示后 3 个工作日内 飞书 wiki 培训总结 🔧+🤖

5. 交付物与模板

  • 交付物：日程邀请；录像与妙记纪要；资料索引页；作业与展示记录；补课记录；培训总结
  • 建议模板/表单：培训记录表（主题、日期、主讲、对象、应到/实到、缺课名单、录像链接、资料链接、作业、展示日期、补课完成情况）；资料索引页（按主题列出课件、教程、示例文档、压缩包与更新日期）

6. 异常与升级

  • 主讲出差/冲突 → 改线上或换讲师 → 提前 1 个工作日通知；无法安排升级内部 FDE 统筹
  • 缺课人数超过 30% → 安排集中补课 → 统筹 5 个工作日内完成
  • 资料找不到 → 统一到资料索引页 → 主讲 1 个工作日内补齐
  • 作业完成率低 → 统筹在展示前 2 天提醒 → 仍未完成报部门负责人
  • A（升级）说明：培训内容、作业与补课安排由 FDE 培训主讲拍板（A）；培训方向调整、与其他工作优先级冲突无法排期时升级 CEO

7. 衡量指标

  • 到课率 = 实到 / 应到，目标 ≥ 85%
  • 补课闭环率 = 缺课人员完成录像学习或补课 / 缺课人数，目标 100%
  • 作业完成率 = 完成作业人数 / 应完成人数，目标 ≥ 80%
  • 资料可查率 = 培训后 1 天内上传至索引页的培训 / 全部培训，目标 100%

8. 低效诊断

  • 现象：同一培训因有人未听而多次补做｜依据：「公司内FDE」2026-07
  • 现象：启动会因出差临时改时间｜依据：「公司内FDE」2026-07
  • 现象：培训示例文档找不到，需在群里追问｜依据：「公司内FDE」2026-07
  • 现象：新加入研发需点名补学产品培训，未纳入固定节奏｜依据：「公司内FDE」2026-09

9. 分支变体

  • 对内员工培训：走本流程
  • 对外客户培训（销售带出去）：走 X-FDE-11
  • 渠道 FDE 培训：走 SAL-29 或 X-FDE-17
  • 新研发产品培训：并入本流程，由研发负责人点名参训

10. 待确认问题

  • 本条与 HR-23（内部培训与分享会）是否合并，主责归人事还是 FDE？
  • 缺课者看录像是否算完成，还是必须参加补课？
  • 是否建立 FDE AI 助教知识库，由谁维护？
X-FDE-16FDE 课程体系开发与评审待优化240

状态：待优化｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：面向渠道、合作伙伴、政府、高校需要分级（初/中/高级）FDE 课程，或具体开班前课程内容（PPT、实操任务、Skill 制作）需要开发与评审时启动
  • 负责人：主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——FDE 课程体系设计（当前：李凯·推断待确认）、中级大纲与讲师（当前：郭逸非·推断待确认）、高级课程（当前：黄振锋·推断待确认）、讲师（当前：陈子康、张家瑞·推断待确认）、宣传与活动（当前：陈梦琪·推断待确认）、课程框架与标准底座（当前：丁震宇·推断待确认）；兜底——CEO（需求方与终审，当前：邴龙志·推断待确认）
  • 核心流程：① 需求方填课程需求单 → ② 出初版框架 → ③ 专家/开放平台研讨定稿 → ④ 讲师开发课件与实操任务（先自跑一轮）→ ⑤ 按检查表评审 → ⑥ 试讲与设备测试 → ⑦ 开课 → ⑧ 课后回流更新标准版
  • 交付结果：分级课程体系文档（标准版＋本期定制版）、课件 PPT、实操任务 spec 说明书、讲稿与主持稿、评审记录、教学资料包（入 FDE 课程仓库）
  • 状态依据：已有专班群、方案 wiki、课程仓库与评审做法，但 2026-08～10 方案多次被催（“拖拖拉拉一个月了”），PPT 被评“太入门”“完全不行”需重做，培训对象水平未先定就出框架导致反复修订

1. 场景判定

  • 触发条件：CEO 或业务方提出新级别/新人群课程；与政府、高校、渠道达成培训合作；具体班次开课前 2 周需要课件定稿
  • 典型说法：「具体的全套培训内容和体系希望下周能见到第一版」「我们是 FDE 培训，不是 AI 入门通识课」「要讲师自己亲自跑一轮，出一个 spec 说明书」「先有一版标准版，再根据每次课改定制版」「先定好需求，不然没法写」
  • 判断问题：要做的是课程内容/体系（不是会务、名单、账号）？培训对象与级别是否已明确？
  • 不归本流程管：开课筹备（名单、助教、会场、账号额度）→ 请走 X-FDE-17；现场问题与学员反馈 → 请走 X-FDE-18；认证考试与发证 → 请走 X-FDE-19；报名筛选与分层 → 请走 ECO-22；内部员工培训 → 请走 X-FDE-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
流程主责 课程总牵头、任务设计、评审组织、版本管理 A FDE 课程负责人（当前：吴亚军·推断待确认）
体系设计 初/中/高级体系方案、大课 R FDE 课程体系设计（当前：李凯·推断待确认）
分级大纲 中级、高级课程大纲 R 中级大纲（当前：郭逸非·推断待确认）、高级课程（当前：黄振锋·推断待确认）
讲师 课件、实操任务、自跑、试讲 R 讲师（当前：陈子康、张家瑞、郭逸非·推断待确认）
框架底座 标准版框架、“底座＋定制＋回流”方法 C 创始人兼 CTO（当前：丁震宇·推断待确认）
宣传 对外宣传与活动配合 I 宣传与活动（当前：陈梦琪·推断待确认）
需求与终审 提需求、对接政府/高校；新级别课程与政府合作课程终审 A（升级） CEO（当前：邴龙志·推断待确认）
班主任 主持稿、开课衔接与学员通知 R 班主任（当前：张家瑞·推断待确认）

3. 办之前请准备

  • 课程需求单：对象（渠道/政府/高校/IT/制造业）、学员水平、级别、课时、期望产出、是否认证
  • 现有标准版课程与历史班次资料包
  • 合作方要求（如政府配套文件）
  • 评审检查表；FDE 课程仓库权限
  • 讲师可用时间与试讲场地

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 需求方填写课程需求单，对象与水平未填不启动 CEO/业务方 开课前 4 周 飞书表单 课程需求单 🔧飞书固化
2 建项目看板：交付物、负责人（逐一 @ 到人）、截止日 FDE 课程负责人 需求单后 1 个工作日内 飞书任务/多维表格 课程看板 🔧飞书固化
3 基于标准版出本期框架初稿（可 AI 辅助），发预览 FDE 课程体系设计 需求单后 5 个工作日内 飞书 wiki、AI 框架初稿 🤖+👤
4 与需求方、开放平台、外部专家研讨，定稿框架 FDE 课程负责人 初稿后 5 个工作日内 飞书会议、妙记 定稿框架、纪要 👤人工判断
5 讲师开发课件与实操任务；任务由讲师先亲自跑一轮，出 spec 说明书和短 PPT 讲师 开课前 10 个工作日 课程仓库 课件、spec 👤人工判断
6 按检查表评审（目标人群、实操占比、Skill 制作、验收方式），一次集中给意见 FDE 课程负责人、CEO 开课前 7 个工作日 评审检查表 评审意见 👤人工判断
7 讲师修改后定稿入仓库，打版本号；讲稿与主持稿分工 讲师、班主任 开课前 3 个工作日 课程仓库 定稿资料包 🔧飞书固化
8 到会场试讲，测试网络与设备 讲师 开课前 1 个工作日 会场 试讲记录 👤人工判断
9 课后收集问题与反馈，回流更新标准版 FDE 课程负责人 课后 5 个工作日内 课程仓库 新版标准课程 🔧+🤖

5. 交付物与模板

  • 交付物：课程需求单；课程看板；分级课程框架；课件与 spec 说明书；评审记录；定稿资料包；更新后的标准版
  • 建议模板/表单：课程需求单（需求方、对象、学员水平、级别、人数、课时、期望产出、是否认证、开课日期）；评审检查表（目标人群匹配、实操占比 ≥ 50%、包含 Skill 制作、任务已自跑、有验收标准、非通识内容、时长分配）；版本记录（版本号、日期、变更点、适用班次）

6. 异常与升级

  • 需求方未定对象与水平 → 不启动框架编写，退回需求单 → 当天告知需求方
  • 方案超期未交 → 看板自动提醒负责人 → 超 3 个工作日升级 CEO
  • 评审判定“方向不对/太入门” → 讲师 2 个工作日内按意见重做 → 再不通过由 FDE 课程负责人接手调整
  • 讲师时间冲突 → 课程负责人 1 个工作日内换讲师或调场次
  • 大课课件临近开课仍未交 → 开课前 3 天未定稿即升级 CEO
  • A（升级）说明：课程框架、评审与版本由 FDE 课程负责人拍板（A）；新级别课程或政府/高校合作课程需终审、方案超期 3 个工作日、开课前 3 天仍未定稿时升级 CEO

7. 衡量指标

  • 课件按时定稿率 = 开课前 3 个工作日定稿的课程 / 全部课程，目标 100%
  • 评审一次通过率 = 首次评审即通过的课件 / 全部课件，目标 ≥ 60%
  • 学员满意度 = 课后问卷平均分，目标 ≥ 4.5/5
  • 标准版复用率 = 本期课程中沿用标准版的内容占比，目标 ≥ 70%

8. 低效诊断

  • 现象：课程体系方案多次被催，任务未 @ 到具体人，外部对接与内部设计并行冲突｜依据：「模态跃迁培训课程专班」2026-08
  • 现象：课件方向偏通识，开课前被评“太入门”“完全不行”需重做；资料包多个版本｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：大课 PPT 迟至开课前才交付，讲师冲突需临时换场｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：培训对象水平未先定就出框架，导致返工（推断）｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 初级班：一天大课＋实操＋Skill 制作，课后衔接 X-FDE-19 认证
  • 中级/高级：需开放平台与专家研讨，实操侧重插件与系统对接
  • 政府合作（如园区、人才局）：需对齐配套文件与认证口径
  • 高校/IT/制造业等人群：在标准版底座上做行业定制
  • 渠道培训：偏产品与交付实操

10. 待确认问题

  • 课程主责是 FDE 课程负责人（课程总牵头）还是 FDE 课程体系设计（体系方案）？
  • 开课前 4 周提需求、3 个工作日定稿的节点是否可行？
  • 评审检查表中“实操占比 ≥ 50%”是否合适？
  • 标准版课程的版本管理是否统一用课程仓库？
  • 政府合作的认证标准由谁对接、谁拍板？
X-FDE-17FDE 培训班筹备与开课保障待新建250

状态：待新建｜证据：有证据（卡片 8 张 / 会话 6 个）｜优先级：频2 × 耗5 × 跨5 × 险5

  • 适用场景：外部 FDE 培训班（官方认证班、线下百人班、高校实训课）开课日期确定后，从立项到首课开讲、再到课后账单收口的全部筹备与保障工作。
  • 负责人：主责——FDE 课程负责人（当前：吴亚军·推断待确认）；协同——培训技术统筹（当前：王皓南·推断待确认）、开放平台后端/权限（当前：杨睿·推断待确认）、交付/IT 现场支持（当前：李奎星、杨云峰·推断待确认）、IT 网络（当前：杨明学·推断待确认）、会务（当前：丁蕊·推断待确认）、销售运营（当前：韩诗琪·推断待确认）、生态组（当前：陈梦琪·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 立项建群定 DDL → ② 名单锁定与筛选 → ③ 师资/助教排班 → ④ 会场勘察与网络验收 → ⑤ 平台/账号/额度开通 → ⑥ 课前彩排与预案 → ⑦ 发通知并开课值守 → ⑧ 课后账单与复盘
  • 交付结果：按期开课、现场环境可用的一期培训班，以及锁定名单、助教排班表、会场验收记录、账号开通台账、应急预案、培训通知、课后账单与复盘纪要。
  • 状态依据：已有专项群、飞书日程、智能纪要和培训通知 PDF，但没有统一筹备清单；2026-07 高校实训与 2026-10 百人班都靠群聊临时分工，开课前 2 天才发现会场网络不达标且明确"没有预案"，开课后才暴露上游 429 限流，账号初始密码在群内明文流转，属于每次临时处理且出过漏项。

1. 场景判定

  • 触发条件：确定了开课日期的外部 FDE 培训（认证班、线下大班、高校实训、渠道 FDE 班），或同一课程开下一批次。
  • 典型说法：「17号第一次课」「FDE上课特供版测试进度和需求在这个群对就行」「学员的空间大小和额度给多少」「会务搞不定才到我们自己上硬件」「FDE培训班需要销售们去跟班当助教」
  • 判断问题：是否有外部学员要现场或远程使用 LeapCore/开放平台？开课日期是否已定？两者都是 → 走本流程。
  • 不归本流程管：课程进行中的学员问题与反馈 → 请走 X-FDE-18；认证考试、评分与发证 → 请走 X-FDE-19；名单中潜在客户的后续跟进与转化 → 请走 ECO-28（培训结营复盘与学员转化）；线索录入与分发 → 请走 SAL-02（入站线索接入、背调与分发认领）；内部系统账号开通 → 请走 X-FDE-20。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
课程总负责 立项、定 DDL、课程与师资、筹备清单验收、开课放行 A/R FDE 课程负责人（当前：吴亚军·推断待确认）
技术统筹 测试环境、容量评估、预案、现场 IT 排班、交接实践课负责人 R 培训技术统筹（当前：王皓南·推断待确认）
平台与权限 开放平台压测、CLI 登录、预登记与提权、用户组 R 开放平台后端（当前：杨睿·推断待确认）
账号与现场支持 学员批量导入、额度配置、现场装机与试机 R 交付/IT（当前：李奎星、杨云峰·推断待确认）
网络保障 会场测速、网络决策、备用路由/热点 R IT 网络（当前：杨明学·推断待确认）
会务 会场联系、培训通知、场地工程协调 R 会务（当前：丁蕊·推断待确认）
名单与助教 名单筛选标准、潜在客户标注、助教排班 R 销售运营（当前：韩诗琪·推断待确认）；各销售（助教）
报名渠道 报名表收集、生态侧学员沟通 C 生态组（当前：陈梦琪·推断待确认）
讲师 课件与 FDE 文档定版、授课 R 讲师（按期次由课程总负责指定）
授课 QA 客户授课 QA 与知识库 C FDE 成员（当前：佘天禾·推断待确认）
安全 凭据发放方式、权限分层审查 C 后端/权限（当前：宋祺睿·推断待确认）
兜底决策 预算外采购、开课延期、跨部门冲突裁决 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 开课日期、地点、形式（线下/线上/高校驻场）、预计人数与是否分批。
  • 报名表：姓名、手机号（必填，且与登录手机号一致）、单位、职位、行业、是否自带电脑。
  • 课程大纲、课件与 FDE 文档版本号；主讲与后备师资名单。
  • 会场信息：会务联系人、场地工程联系人、带宽、AP 数量、是否独立线路、桌位电源。
  • 账号开通参数：空间大小、模型额度、有效期、角色（讲师/学员）、是否开放 Skill 上传。
  • 预算预案：备用路由/热点、租电脑、模型额度费用，需审批的提前发起。
  • 上一期复盘纪要与问题清单。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建专项群（技术、会务、交付、销售、生态各至少 1 人），建飞书日程，按筹备清单逐项指派负责人 课程总负责 开课前 21 天 飞书群、任务看板 筹备任务看板 🔧飞书固化
2 收报名表；AI 按职位+行业初筛；与销售确认筛选标准（决策权、行业适配）；缺信息者由销售认领补问卷 生态组、销售运营 开课前 10 天起 飞书表格 初筛名单 🔧+🤖
3 锁定名单，截止后报名转下一期；名单锁定后导出给账号开通方 课程总负责 开课前 5 天 飞书表格 锁定名单 👤人工判断
4 按行业分班，标注潜在客户，排销售助教并同步日历；冲突可互换但须改表 销售运营 开课前 5 天 多维表格+日历 助教排班表 🔧飞书固化
5 确认主讲、后备师资与授课模式（讲解/答疑/成果展示），统一口径只在专项群发布 课程总负责 开课前 14 天 专项群 师资表 👤人工判断
6 携机器到会场首测网络（带宽、Wi-Fi、AP、运营商限速）；不达标走"两条线"：会务协调场地加线/路由，同时准备自备硬件方案 IT 网络、交付/IT 首测开课前 7 天；复测前 3 天 测速工具 会场验收记录 👤人工判断
7 开放平台压测、沙盒、CLI 登录、测试环境/mock 网关全部测完 技术统筹、平台与权限 开课前 2 天 Gitea、CI 压测结论 🤖自动化
8 按开通模板批量导入账号：身份平铺（讲师=企业管理员、学员=基层人员）；名单内手机号预登记幂等提权；学员对全员空间只读 账号与现场支持、平台与权限 开课前 2 天 实例管理后台、CLI 账号开通台账 🤖+👤
9 初始凭据经一次性链接或单独渠道发放，首登强制改密；禁止在群内贴密码 账号与现场支持 开课前 1 天 一次性链接 发放记录 🔧飞书固化
10 按并发人数评估模型上游限流与额度，提前调大上游配额 技术统筹 开课前 2 天 模型网关 容量确认 👤人工判断
11 客户端安装包放局域网文件服务器并提前发给学员；课件、FDE 文档定版 交付/IT、讲师 开课前 1 天 文件服务器 安装包与课件 🤖自动化
12 会务出培训通知草稿，专项群征求意见 1 个工作日后发学员 会务 开课前 3 天 通知模板 培训通知 🔧飞书固化
13 彩排：上午跑通全流程；确认应急预案与现场 IT 排班；交接实践课负责人 技术统筹 开课前 1 天 预案模板 预案、排班表 👤人工判断
14 开课值守：签到、现场装机、网络监控；新增学员先同步名单再开号 账号与现场支持 开课当日 现场支持群 值守记录 👤人工判断
15 课后连续 3 天监控模型调用账单；回收/冻结额度；清理未授权上传的 Skill；开复盘会 课程总负责、技术统筹 结课后 3 个工作日内 账单后台、纪要 账单与复盘纪要 🤖+👤

5. 交付物与模板

  • 交付物：锁定名单、助教排班表、会场验收记录、账号开通台账、应急预案、培训通知、课后账单汇总、复盘纪要。
  • 建议模板/表单：
    • 培训筹备清单（多维表格）：事项、负责人、DDL、状态、验收人、备注（设备/网络/账号/课程/通知/备份六类）。
    • 会场准入清单：带宽实测值、AP 数、是否独立线路、备用热点、场地工程联系人、测试时间。
    • 培训开通模板：期次、人数、角色、空间、模型额度、有效期、是否开 Skill 上传、到期处理方式。
    • 应急预案模板：故障类型（网络/机器/上游限流/账号）、触发阈值、切换方案、执行人、决策人。

6. 异常与升级

  • 会场首测带宽不达标 → 会务当日联系场地工程，复测仍不达标则启用自备硬件 → 升级课程总负责决定采购（24 小时内）。
  • 开课前 3 天名单仍缺手机号 → 销售认领补齐，未补齐者走现场扫码预登记 → 升级平台与权限确认兜底提权（当日）。
  • 开课中出现 429/上游限流 → 技术统筹调大上游额度或限流降级 → 升级研发负责人/CTO（30 分钟内）。
  • 现场机器故障且无备机 → 切换录屏/演示模式 → 升级技术统筹（15 分钟内）。
  • 课后账单超出开通模板预估 → 冻结学员额度 → 升级课程总负责与财务（1 个工作日内）。
  • A（升级）说明：筹备清单验收与开课放行由 FDE 课程负责人拍板（A）；需预算外采购、开课延期、跨部门资源冲突，或开课中上游限流 30 分钟内无法缓解时升级研发负责人/CTO。

7. 衡量指标

  • 筹备清单完成率 = 开课前 1 天已完成项/总项，目标 100%。
  • 会场网络首测提前量 = 首测日到开课日天数，目标 ≥ 7 天。
  • 开课当日账号可用率 = 首次登录成功学员/到场学员，目标 ≥ 98%。
  • 课中严重故障次数（网络中断、上游限流、批量登录失败），目标 0 次。
  • 额度执行偏差 = 实际账单/开通模板预估，目标 ≤ 110%。

8. 低效诊断

  • 现象：会场网络到开课前 2 天才实测，发现不达标后临时找场地、准备自带硬件，且没有现成预案｜依据：「百人上课特供版leapcore」2026-10
  • 现象：谁联系会场、谁在会务群不清，开会前才发现关键人员不在群里，压测账号信息也"不在这个群"｜依据：「百人上课特供版leapcore」2026-10
  • 现象：空间与额度标准反复口头询问、数值前后不一，开课后才发现上游限流｜依据：「百人上课特供版leapcore」2026-10
  • 现象：名单缺手机号导致无法导入，新增学员未同步名单就要账号，初始密码在群里明文传递｜依据：「FDE培训班专班沟通群」2026-10、「开放平台Only」2026-10
  • 现象：名单当日才定稿、助教如何落地需临时讨论，名单靠转发文件流转｜依据：「【模态】市场销售」2026-09
  • 现象：开课前基础设施压力集中，沙盒方案不知道该找谁，平台侧依赖单人｜依据：「公司内FDE」2026-09、「公司内FDE」2026-10
  • 现象：高校实训多方对同一安排理解不一，被要求先在群里对齐口径｜依据：「【模态】开放生态」2026-07

9. 分支变体

  • 百人线下班：全量执行本流程，重点是步骤 6、10、13；无电脑学员需提前确认租机或手机端方案。
  • 官方认证班首课：额外完成 FDE 文档定版、CLI 登录、普通用户/FDE 权限分层，结课衔接 X-FDE-19。
  • 高校实训：校方对接人由业务人员确认并拉专项群；模式为首日讲解、中期答疑、末日成果展示；充值采用人均定额，后续用券；学生成果评分后可上架行业版商店。
  • 名单含潜在客户：销售按行业分班担任助教，课后转销售线索跟进。
  • 远程学员：机器回公司接入，重点保障远程访问组件与账号额度。

10. 待确认问题

  • 培训班总负责是否为 FDE 课程负责人？FDE 部门负责人目前多头，兜底人是否为研发负责人/CTO？
  • 筹备时间表（开课前 21/14/7/3/1 天）是否可行？名单锁定是否统一为开课前 5 天？
  • 学员空间与模型额度的标准口径是多少？是否按期次写入开通模板，由谁审批？
  • 会场网络达标线（带宽、AP 数）定为多少？自备硬件的采购审批走谁？
  • 初始凭据发放是否统一改用一次性链接，并开启首登强制改密？
  • 现场 IT 值守由交付还是 IT 网络主责？是否需要固定排班表？
  • 是否已有成文的培训筹备制度或课前须知可直接沿用？
X-FDE-18培训现场问题与学员反馈收集待新建90

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频2 × 耗3 × 跨5 × 险3

  • 适用场景：FDE 培训班/实训课/内部初级 FDE 培训会进行期间，需要课堂出题、收集学员现场问题（远程访问失效、文件被占用、下载挂起等）与课后反馈，并转产研修复。
  • 负责人：主责——培训班主任/AI 讲师（当前：张家瑞·推断待确认）；协同——助教/讲师（当前：梅立、杜中瑞、吴琪、李奎星·推断待确认）、产品负责人（当前：杨萌·推断待确认）、现场 oncall 研发（当前：宋祺睿、杨云峰·推断待确认）、LeapVPN 负责人（当前：吴世豪·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）
  • 核心流程：① 课前指定出题人与反馈表 → ② 课前环境验证 → ③ 现场登记问题 → ④ 研发判定已知/新问题 → ⑤ 现场权宜处理 → ⑥ 当日提 bug → ⑦ 课后汇总反馈与调研报告 → ⑧ 回复学员并纳入下期改进
  • 交付结果：课堂题目、现场问题登记表（含诊断日志）、对应 bug 工单、课后反馈汇总与调研报告、下期改进项清单。
  • 状态依据：现场问题靠在反馈群贴截图和 diagnose 日志，事后才提 bug；2026-10 培训开课前两天才发现无人出题，FDE 培训无明确负责人和反馈回收机制。

1. 场景判定

  • 触发条件：培训课进行中出现学员使用问题；培训需要课堂练习题、调研或课后反馈。
  • 典型说法：「FDE课程学员反馈」「这个地方很多人一起下载容易挂」「多数学员都会出现这个问题」「实际上后天就培训了」
  • 判断问题：问题是否发生在培训课期间、由学员或助教报告？是否需要产研处理或纳入课程改进？
  • 不归本流程管：开课前的会场、账号、额度准备 → 请走 X-FDE-17；认证考试题库与发证 → 请走 X-FDE-19；非培训场景的客户产品问题 → 请走 X-CS-05（客户问题受理、分流与工单流转）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
班主任 出题协调、反馈表维护、现场问题汇总、课后报告 A/R 培训班主任/AI 讲师（当前：张家瑞·推断待确认）
助教/讲师 现场发现与登记问题、收集诊断日志、执行权宜方案 R 助教/讲师（当前：梅立、杜中瑞、吴琪、李奎星·推断待确认）
产品 判定已知问题与版本、调研报告评审、出题配合 C 产品负责人（当前：杨萌·推断待确认）
现场 oncall 现场故障排查、机器埋点数据查看 R 后端/部署研发（当前：宋祺睿、杨云峰·推断待确认）
组件负责人 远程访问组件等专项问题解答 C LeapVPN 负责人（当前：吴世豪·推断待确认）
业务出题 提供贴近业务的练习题 C 工程咨询业务专家/FDE（当前：王满·推断待确认）
兜底 培训期间资源调配与优先级裁决 A（升级） FDE 课程负责人（当前：吴亚军·推断待确认）

3. 办之前请准备

  • 课程表、讲师与助教名单、现场 oncall 排班。
  • 课堂题目与评分要点（含出题人、定稿日期）。
  • 学员客户端版本号、已知问题清单（含已修复版本）。
  • 反馈表单链接（现场问题表、课后满意度表）。
  • 诊断日志导出方法说明（发给助教）。
  • 现场支持群（含助教、oncall、产品）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在培训排期表中指定出题人与定稿日，出题人确认接单 班主任 开课前 7 天 多维表格、飞书任务 出题任务 🔧飞书固化
2 题目定稿并交讲师试做 出题人、讲师 开课前 3 天 飞书文档 课堂题目 👤人工判断
3 课前环境验证：多人并发下载、远程访问组件、文件读写；整理已知问题清单与预装包 现场 oncall 开课前 1 天 测试机、清单 环境验证记录 🤖自动化
4 建现场支持群，公布反馈表单与 oncall 排班 班主任 开课前 1 天 飞书群、表单 支持群与表单 🔧飞书固化
5 现场问题登记：现象、影响人数、客户端版本、diagnose 日志、截图 助教/讲师 发现后 10 分钟内 多维表格 问题记录 🔧飞书固化
6 判定已知问题（给出修复版本与升级方式）或新问题（开始排查） 产品、组件负责人 登记后 30 分钟内 已知问题清单 判定结论 👤人工判断
7 执行权宜方案（如群发安装包、改用局域网下载、换机），影响 ≥ 30% 学员时同步讲师调整进度 助教、现场 oncall 判定后 15 分钟内 现场支持群 处理结果 👤人工判断
8 新问题当日提 bug 工单，关联问题记录 现场 oncall 当日下班前 Gitea issue bug 工单 🔧+👤
9 发放课后反馈表，回收学员与助教意见 班主任 结课当日发放，3 天内回收 飞书表单 反馈数据 🔧飞书固化
10 汇总问题与反馈，AI 生成初稿，形成调研报告并评审 班主任、产品 结课后 3 个工作日内 多维表格、AI 调研报告 🤖自动化
11 改进项写入下期筹备清单（X-FDE-17）与需求池，向学员同步修复情况 班主任 结课后 5 个工作日内 需求池 改进项清单 👤人工判断

5. 交付物与模板

  • 交付物：课堂题目、现场问题登记表、bug 工单、课后反馈汇总、培训调研报告、改进项清单。
  • 建议模板/表单：
    • 现场问题登记表：时间、课程/期次、现象、影响人数、客户端版本、系统环境、日志附件、登记人、判定（已知/新）、处理方式、工单号、关闭时间。
    • 课后反馈表：课程内容评分、讲师评分、环境稳定性评分、最想改进的一点、是否愿意深入合作。
    • 培训排期表：期次、日期、出题人、定稿日、讲师、助教、oncall。

6. 异常与升级

  • 同一问题影响 ≥ 30% 学员 → 讲师暂停实操、改演示 → 升级现场 oncall 与 FDE 课程负责人（15 分钟内）。
  • 新问题 30 分钟内无法定位 → 记录并启用权宜方案 → 升级产品负责人排期（当日）。
  • 开课前 3 天题目未定稿 → 班主任直接指派业务出题人 → 升级 FDE 课程负责人（当日）。
  • 学员对课程或环境有投诉 → 班主任 1 个工作日内回复 → 升级 FDE 课程负责人。
  • A（升级）说明：现场问题登记、反馈汇总与课后报告由培训班主任拍板（A）；同一问题影响 ≥ 30% 学员、开课前 3 天题目未定稿、学员投诉未能化解时升级 FDE 课程负责人调配资源。

7. 衡量指标

  • 现场问题响应时长 = 登记到首次判定，目标 ≤ 30 分钟。
  • 现场问题入表率 = 登记表记录数/群内报告问题数，目标 100%。
  • 新问题转工单率 = 当日提单数/新问题数，目标 100%。
  • 课后反馈回收率 = 回收份数/到课人数，目标 ≥ 60%。
  • 同类问题复发率 = 下期重复出现的已知问题数，目标 0。

8. 低效诊断

  • 现象：培训前没有指定出题人，开课前两天才发现无人配合出题｜依据：「Leap产研决策部」2026-10
  • 现象：FDE 培训归哪个组、谁牵头不清，临时直接拉人干活｜依据：「Leap产研决策部」2026-10
  • 现象：培训日才集中暴露多人同时下载挂起、远程访问组件失效、文件被占用，课前没有环境演练｜依据：「Leap反馈群」2026-10
  • 现象：已在新版本修复的问题仍在现场反复出现，学员客户端版本未统一｜依据：「Leap反馈群」2026-10
  • 现象：问题散落在群聊截图，事后才补提 bug，缺统一汇总｜依据：「Leap反馈群」2026-10

9. 分支变体

  • 线下实训课：设现场支持群和 oncall，全量执行。
  • 线上培训：以远程访问与客户端安装问题为主，登记表必填网络环境。
  • 内部初级 FDE 培训会：重点是出题与调研报告，可让成员以 FDE 身份到客户现场待一天收集反馈。
  • 客户大课（数百人）：问题按影响人数分级，优先处理批量问题。

10. 待确认问题

  • 培训现场问题的主责是班主任还是 FDE 课程负责人？
  • 内部 FDE 培训由哪个组牵头？出题人默认是谁？
  • 现场 oncall 是否需要固定排班？响应时限 30 分钟是否可行？
  • 现场问题是否统一登记到一张多维表格，并由机器人自动转工单？
  • 课后调研报告由谁评审，是否需要固定模板？
X-FDE-19FDE 认证考试与结课发证待优化120

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨5 × 险4

  • 适用场景：学员完成 FDE 初级班课程后，组织认证考试、审核成绩并颁发初级 FDE 证书；中高级认证沿用同一流程。
  • 负责人：主责——培训班主任/题库负责人（当前：张家瑞·推断待确认）；协同——FDE 课程负责人/开放平台（当前：吴亚军·推断待确认）、UI/UX 设计师（当前：康紫馨·推断待确认）、生态组（当前：陈梦琪·推断待确认）、讲师（当前：郭逸非·推断待确认）；兜底——FDE 课程负责人（当前：吴亚军·推断待确认）
  • 核心流程：① 题库设计 → ② 内部试做校验 → ③ 公布认证规则 → ④ 学员上传 Skill 并答题 → ⑤ 成绩汇总与人工复核 → ⑥ 收集邮箱并审核名单 → ⑦ 生成并邮件发证 → ⑧ 申诉处理与归档
  • 交付结果：通过名单、成绩记录、已发放的初级 FDE 电子证书、申诉处理记录。
  • 状态依据：已有《FDE人才培养标准及分级评价结课办法（试行）》、问卷星考试和证书设计，流程刚成型；2026-10 出现试题无编号、弹窗终止作答需返工，学员对 AI 打分公平性提出质疑。

1. 场景判定

  • 触发条件：一期 FDE 认证班课程结束（或进入结课周），需要考核与发证。
  • 典型说法：「skill打分达到70分以上、答题80分以上」「获取初级FDE证书的两个必要前提条件」「学员问打分的问题，还是严谨回答下」
  • 判断问题：学员是否参加了认证班课程？是否需要授予 FDE 等级证书？
  • 不归本流程管：课堂练习题与现场反馈 → 请走 X-FDE-18；开课筹备与账号开通 → 请走 X-FDE-17；非认证类活动的参与证明 → 请走研究院生态（暂无对应 SOP，待新建）。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
题库与考务 题库设计、考试链接、成绩汇总、发证执行 R 培训班主任/题库负责人（当前：张家瑞·推断待确认）
规则制定 认证门槛、开放平台 Skill 评分、名单审核放行 A FDE 课程负责人（当前：吴亚军·推断待确认）
证书设计 证书版式（svg）与编号规则 R UI/UX 设计师（当前：康紫馨·推断待确认）
学员沟通 规则说明、评分问题答复 C 生态组（当前：陈梦琪·推断待确认）
讲师 试做试题、Skill 评分人工复核 C 讲师（当前：郭逸非·推断待确认）
学员 上传 Skill、答题、留邮箱 I 外部学员

3. 办之前请准备

  • 《FDE人才培养标准及分级评价结课办法（试行）》当前版本。
  • 各课程模块题库（含题目编号、答案、所属模块）。
  • 考试平台账号与防作弊设置（切屏、弹窗、限时）。
  • 开放平台 Skill 评分规则说明与复核人名单。
  • 证书模板与编号规则、发件邮箱。
  • 学员名单（与 X-FDE-17 锁定名单一致）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模块抽题组卷（现行：20 题 × 5 分，80 分及格），每题编号 题库与考务 结课前 7 天 问卷星 试卷 🤖自动化
2 内部人员试做，校验难度、题目编号、弹窗与防作弊设置，修正后定稿 讲师、规则制定 结课前 4 天 问卷星 试做反馈与定稿卷 👤人工判断
3 向学员公布认证规则：开放平台上传 Skill 且评分 ≥ 70、现场答题 ≥ 80，两项缺一不可 规则制定 结课前 2 天 培训群、课前须知 认证规则公告 🔧飞书固化
4 学员在开放平台上传 Skill，系统打分 学员 考试日前 开放平台 Skill 评分 🤖自动化
5 现场答题，限时提交 学员 考试日 问卷星 答题成绩 🤖自动化
6 汇总两项成绩；边界分（Skill 65～75、答题 75～85）由讲师人工复核 题库与考务、讲师 考试后 2 个工作日内 多维表格 成绩表 🔧+👤
7 学员在开放平台留邮箱，核对名单与邮箱一致 题库与考务 考试后 2 个工作日内 开放平台 发证名单 🔧飞书固化
8 审核通过名单并放行 规则制定 名单提交后 1 个工作日内 多维表格 审核结论 👤人工判断
9 按模板批量生成带编号证书，邮件发放 题库与考务 审核后 2 个工作日内 证书 svg、邮件 已发证书 🤖自动化
10 受理成绩/评分申诉，复核后书面答复 规则制定、讲师 收到后 3 个工作日内 申诉表单 申诉记录 👤人工判断
11 成绩、名单、证书编号归档，统计通过率，题库更新 题库与考务 发证后 5 个工作日内 多维表格 认证台账 🔧飞书固化

5. 交付物与模板

  • 交付物：定稿试卷、认证规则公告、成绩表、发证名单、电子证书、申诉记录、认证台账。
  • 建议模板/表单：
    • 认证台账：期次、学员姓名、单位、Skill 名称与评分、答题分、复核人、是否通过、证书编号、发证日期、邮箱。
    • 申诉表单：学员、期次、申诉项（Skill 评分/答题）、理由、复核人、复核结论、答复日期。
    • 试做校验清单：题目编号、难度分布、各模块覆盖、弹窗/切屏设置、限时、答案核对。

6. 异常与升级

  • 考试中弹窗终止作答或链接故障 → 现场重开链接并记录受影响学员 → 升级规则制定决定是否补考（当日）。
  • 学员质疑 AI 评分 → 讲师人工复核，统一口径回复 → 升级 FDE 课程负责人（3 个工作日内）。
  • 邮箱缺失或错误导致证书退信 → 题库与考务联系学员补正 → 5 个工作日未补正则暂缓发证。
  • 发现作弊 → 取消当次成绩 → 升级 FDE 课程负责人裁定（2 个工作日内）。

7. 衡量指标

  • 发证周期 = 考试日到证书发出的工作日数，目标 ≤ 5 个工作日。
  • 试卷返工次数 = 开考后发现题目问题需修正的次数，目标 0。
  • 申诉率 = 申诉人数/参考人数，目标 ≤ 5%；申诉按时答复率目标 100%。
  • 证书错发率 = 错发/退信证书数/发证总数，目标 0。

8. 低效诊断

  • 现象：试卷未编号、弹窗会终止作答，需在内部试做后返工修正｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：学员对 AI 打分公平性有疑问，缺固定复核与答复口径｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：认证门槛临近考试才对学员说明，学员对两项前提理解不一｜依据：「FDE培训班专班沟通群」2026-10
  • 现象：成绩汇总、邮箱收集、发证均为手工操作，无自动化｜依据：「FDE培训班专班沟通群」2026-10

9. 分支变体

  • 初级认证：Skill 评分 + 答题两项门槛（现行口径）。
  • 中高级认证：沿用本流程，门槛与考核形式按结课办法另行规定。
  • 高校实训：学生成果评分后可上架行业版商店，是否发证待确认。

10. 待确认问题

  • 发证主责是班主任还是 FDE 课程负责人？名单最终审核放行人是谁？
  • 及格线（Skill ≥ 70、答题 ≥ 80）是否已写入试行办法并对外公布？
  • 边界分人工复核区间是否合适？复核人是谁？
  • 证书是否需要编号与在线核验？是否加盖公司主体名义？
  • 能否实现"两项达标自动发邮件证书"？
  • 未通过学员是否允许补考，补考规则如何？
X-FDE-20内部业务系统上线内测、业务验收与发布待优化240

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨5 × 险4

  • 适用场景：内部自研系统（CRM、渠道系统、合同、采购等）开发完成或出新版本后，组织按岗跑测、Agent/E2E 测试提单、账号开通与使用培训、业务方验收，并发布到预览/正式环境。
  • 负责人：主责——内部系统负责人（当前：郭逸非、陈子康·推断待确认）；协同——产品负责人（当前：杨萌·推断待确认）、测试负责人（当前：张东郅·推断待确认）、总经办（当前：王欣、田杰·推断待确认）、各业务角色代表（销售：闫登辉、吴琪；IT：杨明学、游家豪；财务：黄梦婷；合规：赵雪冰·推断待确认）、后端/权限（当前：宋祺睿、杨睿·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 开发自测与 E2E → ② 出验收报告与手册 → ③ 发布预览环境并分配角色账号 → ④ 按岗跑测 + Agent 测试提单 → ⑤ 问题分级修复与复测 → ⑥ 业务验收与培训 → ⑦ 正式发布与账号开通 → ⑧ 常态化反馈
  • 交付结果：业务方确认的验收记录、更新后的用户手册、正式环境可用的系统版本与已开通账号、版本更新通知、反馈表进入常态化运转。
  • 状态依据：已有跑测反馈多维表格、反馈群、账号注册审批、培训提需会和验收报告，但 2026-07～09 反复催填无人响应、用户误入旧版环境导致意见作废、手册更新跟不上、测试 Bot 假红率高，正式发布流程未成文。

1. 场景判定

  • 触发条件：内部系统首次上线、出预览版或正式版新版本、底座升级需业务回归。
  • 典型说法：「大家每个人假设自己是一个渠道，跑一遍，明天收集一下反馈」「渠道系统已经内部测试完毕，请有关的同事查看运转流程」「大家本周多测测，每个人至少提出一个问题」「测试应该人手一个grok bot」
  • 判断问题：是内部自研、给公司员工或渠道使用的系统吗？是否已开发完成、等待业务使用？是 → 走本流程。
  • 不归本流程管：内部系统的需求提出与开发排期 → 请走 X-FDE-13；对外商业产品（LeapCore 等）发版 → 请走 RND-51（正式版本发布上线）；外部培训学员账号 → 请走 X-FDE-17。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
系统负责人 组织内测、维护环境与账号、整理问题、修复、发布 release A/R 内部系统负责人（当前：郭逸非、陈子康·推断待确认）
产品 发起跑测、定义角色用例、验收标准、手册审定 R 产品负责人（当前：杨萌·推断待确认）
测试 E2E 用例、Agent 测试 Bot 运行与假红复核、测试培训 R 测试负责人（当前：张东郅·推断待确认）
业务角色代表 按岗位跑完整流程、填反馈、签验收 R 销售（当前：闫登辉、吴琪·推断待确认）、IT（当前：杨明学、游家豪·推断待确认）、财务（当前：黄梦婷·推断待确认）
总经办 发跑测通知、催填、组织培训与提需会 R 总经办（当前：王欣、田杰·推断待确认）
合规视角 流程合规、手册需求 C 综合部负责人（当前：赵雪冰·推断待确认）
安全与权限 安全测试、账号权限、凭据分发 C 后端/权限（当前：宋祺睿、杨睿·推断待确认）
发布审批与底座 底座更新冲突裁决、例外放行、对外开放决策 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
业务推动 要求全员使用、确认业务优先级 I 销售负责人（当前：李鹏为·推断待确认）、CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 版本号、更新说明（新增/修改/已知问题）。
  • 预览环境地址，与正式/旧版环境的区分说明。
  • 角色清单与对应测试账号（每个角色一个，不共用、不在群里贴密码）。
  • 按角色的测试用例/跑测脚本（业务全流程）。
  • 用户手册（AI 按角色模拟操作截图生成初稿）。
  • 跑测反馈多维表格（部门跑测记录/需求反馈/Bug 反馈）。
  • 验收与流程报告（飞书文档，不用 PPT）。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 开发自测，补全 E2E；AI 按角色模拟操作，截图生成用户手册初稿 系统负责人 提测前 Gitea、E2E、AI 自测记录、手册初稿 🤖自动化
2 输出验收与流程报告（飞书文档），管理后台由研发负责人过一遍 系统负责人、发布审批 提测前 1 个工作日 飞书文档 验收与流程报告 👤人工判断
3 部署预览环境；在多维表格登记环境地址与角色账号分配，经安全渠道发放凭据；群公告置顶入口 系统负责人 提测当日 preview 环境、多维表格 测试入口表 🔧飞书固化
4 发跑测通知：每个角色至少 1 名代表按岗位跑完整流程，反馈填表；机器人按角色定向提醒 总经办、产品 通知后 3 个工作日内完成 飞书群、机器人 跑测记录 🔧飞书固化
5 Agent 测试 Bot 夜间跑 E2E，持测试人员 token 自动提单 测试 提测当晚起每晚 Grok Bot、Gitea 缺陷工单 🤖自动化
6 人工核实 Bot 工单，剔除假红后分派；统计假红原因 测试 次日 12:00 前 Gitea 有效缺陷清单 👤人工判断
7 安全测试（权限、越权、凭据） 安全与权限 跑测期内 测试工具 安全测试结论 👤人工判断
8 汇总反馈与缺陷，分 P0/P1/P2；P0 必须修复后复测 系统负责人、产品 跑测结束后 1 个工作日 多维表格 问题优先级清单 👤人工判断
9 召开跑测/培训提需会：每角色一人现场模拟全流程，确认业务契合 总经办、系统负责人 修复后 2 个工作日内 飞书会议、妙记 会议纪要、新需求 👤人工判断
10 业务角色代表在验收记录上确认通过；手册同步更新到当前版本 业务角色代表、产品 会后 2 个工作日内 多维表格、手册 验收记录、更新手册 🔧+🤖
11 发布 release：preview 稳定后合入，配置 license、飞书回调，准备回滚方案；清理测试数据 系统负责人 验收通过后 1 个工作日 Gitea、服务器 正式版本 👤人工判断
12 正式账号经飞书审批开通并配置身份 系统负责人 申请后 1 个工作日内 飞书审批 已开通账号 🔧飞书固化
13 推送"系统已升级"通知与更新说明 系统负责人 发布当日 飞书机器人 版本通知 🤖自动化
14 进入常态化反馈：反馈群消息机器人转工单，按版本回复 系统负责人 持续，工单 3 个工作日内回复 多维表格、机器人 反馈台账 🔧+🤖
15 内部稳定运行后再评估是否开放给外部渠道/客户 发布审批与底座 正式上线满 2 周后 评审会 开放决策 👤人工判断

5. 交付物与模板

  • 交付物：验收与流程报告、测试入口表、跑测记录、有效缺陷清单、安全测试结论、验收记录、更新后的用户手册、release 版本与回滚方案、版本通知。
  • 建议模板/表单：
    • 测试入口表：系统、版本、环境（preview/release）、地址、角色、账号分配人、凭据发放方式、有效期。
    • 跑测反馈表（三张子表）：部门跑测记录（角色、跑测人、流程是否走通、耗时）；需求反馈（描述、业务理由、优先级）；Bug 反馈（步骤、截图、环境、版本、状态）。
    • 验收记录：版本、角色、验收人、验收结论（通过/有条件通过/不通过）、遗留问题、日期。
    • 发布检查表：PR 已合并、自动测试通过、P0 清零、license/回调配置、测试数据清理、回滚方案、批准人。

6. 异常与升级

  • 跑测通知后 3 个工作日内角色未完成 → 机器人二次提醒并抄送部门负责人 → 升级总经办（第 4 个工作日）。
  • 用户误入旧版/正式环境提意见 → 系统负责人核对版本后作废并重新指引 → 当日在群公告更新入口。
  • Bot 假红率 > 50% → 暂停自动提单、修 E2E 用例 → 升级测试负责人（2 个工作日内）。
  • 底座更新与业务代码冲突 → 冻结底座推送，按分支/PR 合入 → 升级研发负责人/CTO（当日）。
  • release 后出现阻断性问题 → 按回滚方案回退 → 升级研发负责人/CTO（1 小时内）。
  • 业务方验收不通过 → 列遗留问题与修复日期 → 升级产品负责人重新排期（2 个工作日内）。
  • A（升级）说明：内测组织、验收汇总与按发布检查表放行由内部系统负责人拍板（A）；底座更新与业务代码冲突、P0 未清零需例外放行、release 后出现阻断性问题、拟开放给外部渠道/客户时升级研发负责人/CTO。

7. 衡量指标

  • 角色跑测完成率 = 按期完成跑测的角色数/角色总数，目标 100%。
  • 提测到正式发布周期 = 自然日，目标 ≤ 10 天（视版本大小调整）。
  • Bot 工单有效率 = 人工核实有效工单/Bot 提单总数，目标 ≥ 60%。
  • 手册同步率 = 发版时手册已更新的版本数/发版数，目标 100%。
  • 上线后 2 周 P0 缺陷数，目标 0。
  • 反馈 3 个工作日回复率，目标 ≥ 90%。

8. 低效诊断

  • 现象：多次在群里催"用了系统没""有没有反馈"，反馈表基本无人填写｜依据：「渠道系统优化」2026-08、「【模态】市场销售」2026-09
  • 现象：用户不知道 CRM 从哪进、渠道账号怎么配、反馈发到哪；渠道系统与 CRM 两套入口口径混乱｜依据：「【模态】市场销售」2026-09
  • 现象：用户误入线上旧版而非测试环境，已提的修改意见被撤回｜依据：「渠道系统优化」2026-09
  • 现象：测试账号密码在群里被反复询问和发送｜依据：「渠道系统优化」2026-07、「渠道系统优化」2026-08
  • 现象：内部没人真正把系统用明白，就计划开放给外部渠道｜依据：「渠道系统优化」2026-08
  • 现象：手册更新跟不上版本，业务方要最新手册拿不到｜依据：「公司内FDE」2026-09
  • 现象：Agent 测试方案已有，但测试团队未跑通，假红率高、提单很多无效｜依据：「公司内FDE」2026-09
  • 现象：新用户登录后只提交了注册审批，等管理员人工配置身份，急用需单独加急｜依据：「【模态】市场销售」2026-09

9. 分支变体

  • 渠道系统：8 个角色（销售/财务/IT/软件/总经办等）跑测；内部跑通后才开放外部渠道试用。
  • CRM：各部门按业务线跑测，填"跑测反馈表"三张子表。
  • 合同系统：法务、财务为验收主角色。
  • 采购系统：行政作为真实使用者兼测试。
  • 外部客户项目系统：由客户方测试，内部只做预验收。
  • 预览版内测 vs 正式上线：预览版只走步骤 1～10；正式上线全量执行。
  • 底座更新：只推送底座、不改业务代码，需业务做回归跑测。

10. 待确认问题

  • 内部系统负责人以谁为准（渠道系统交接后归属是否已明确）？release 发布人与批准人分别是谁？
  • 跑测期限 3 个工作日、提测到发布 10 天是否可行？
  • 各系统的验收人（每个角色）是否固定？验收标准是否需要成文？
  • 测试账号凭据改用什么安全渠道发放？
  • 正式账号开通能否由飞书审批自动完成身份配置？
  • Agent 测试 Bot 是否作为每个版本的必选环节？假红复核由谁负责？
  • 安全测试由谁执行？是否每个版本必做？
  • 开放给外部渠道/客户的放行标准和决策人是谁？
X-FDE-21定制交付成果复用沉淀与知识产权归属确认待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：FDE 为客户开发的 Skill、工作流、提示词、插件、脚本或行业方案交付后，确认知识产权归属与可复用范围，把可复用部分脱敏入公司资产库
  • 负责人：主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、产品经理、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 签约前约定 IP 归属 → ② 交付后成果盘点 → ③ 判定可复用范围 → ④ 脱敏与通用化 → ⑤ 入资产库 → ⑥ 评估产品化 → ⑦ 记录复用次数
  • 交付结果：成果盘点表、IP 归属结论、入库的通用资产、产品化建议
  • 状态依据：已有 X-FDE-08（定制 Skill 承接与交付）、X-FDE-09（Skill 审核上架）、X-FDE-14（内部 FDE 案例收集）覆盖部分环节，本条补齐定制成果的知识产权归属确认与复用入库（推断）

1. 场景判定

  • 触发条件：定制项目进入合同阶段；定制项目交付完成；发现多个客户需求相似
  • 典型说法：「上次给某客户做的那个能不能直接用」「这个 Skill 是客户的还是我们的」
  • 判断问题：这份成果是否可能用于其他客户？合同是否限制我方复用？
  • 不归本流程管：定制 Skill 需求承接、定价与交付 → 请走 X-FDE-08；Skill 上架开放平台 → 请走 X-FDE-09、RND-56；客户案例对外宣传 → 请走 BRD-15；内部 FDE 成果评测 → 请走 X-FDE-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
资产负责人 组织盘点、决定入库 A FDE 负责人（当前：待指定）
FDE 工程师 盘点成果、脱敏与通用化 R FDE 工程师（当前：待指定）
法务 合同 IP 条款与复用合规判断 C 法务专员（当前：待指定）
产品 评估是否进入标品 C 产品经理（当前：待指定）
销售 签约时按标准条款谈 IP C 客户对接销售（当前：待指定）

3. 办之前请准备

  • 合同中知识产权、保密、成果归属条款
  • 交付成果清单（代码、Skill、提示词、文档）
  • 成果中含有的客户数据与客户专有信息清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 合同采用标准 IP 条款（通用能力归我方、客户专有数据归客户） 客户对接销售、法务专员 签约前 合同模板 IP 条款 🔧飞书固化
2 交付后盘点成果 FDE 工程师 交付后 5 个工作日内 盘点表 成果清单 🔧飞书固化
3 判定每项成果的归属与可复用范围 FDE 负责人、法务专员 盘点后 3 个工作日内 盘点表 归属结论 👤人工判断
4 去除客户数据、名称、专有规则，通用化 FDE 工程师 判定后 5 个工作日内 Gitea 通用版本 🤖+👤
5 入资产库（说明、适用行业、依赖、版本） FDE 工程师 通用化后 2 个工作日内 知识库/Gitea 资产条目 👤人工判断
6 季度评估高复用资产是否产品化 产品经理 每季度末 资产库 产品化建议 👤人工判断

5. 交付物与模板

  • 交付物：成果盘点表、归属结论、资产库条目、产品化建议
  • 建议模板/表单：FDE 资产条目（名称、类型、来源项目代号、适用行业、功能说明、依赖、IP 归属、可复用范围、脱敏确认人、版本、复用次数）

6. 异常与升级

  • 合同约定成果全部归客户 → 不入库，仅记录经验 → 升级 FDE 负责人
  • 发现资产中残留客户数据 → 立即下架并清理 → 升级法务（当天）
  • 客户要求独家使用 → 评估定价并在合同中明确 → 升级销售负责人

7. 衡量指标

  • 定制项目成果盘点率，目标 100%
  • 资产复用率 = 新项目中使用资产库内容的项目数 / 新项目数，目标逐季提升
  • 标准 IP 条款覆盖率，目标 ≥ 90%

8. 低效诊断

  • 聊天中未见相关流程，存在同类定制重复开发、成果权属不清引发纠纷、客户数据随成果外流的风险（推断）

9. 分支变体

  • 内部 FDE 项目：成果默认归公司，直接走入库与产品化评估
  • 合作伙伴联合开发：按 LEG-05 合作协议约定归属

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 销售合同模板中是否已有 IP 归属条款？
  • 资产库放在开放平台、Gitea 还是知识库？
  • 复用资产是否计入 FDE 绩效？
X-FDE-22客户数据带离现场与开发使用审批待新建推断120

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频3 × 耗2 × 跨4 × 险5

  • 适用场景：FDE、交付、产品为开发定制 Skill、调试提示词、做评测或训练需要把客户提供的样例文件、业务数据、对话记录带回公司或上传到外部模型时，先取得授权、脱敏，限定用途并在用后销毁
  • 负责人：主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、法务专员、客户对接销售、研发值班（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 识别数据与用途 → ② 客户书面授权 → ③ 内部登记审批 → ④ 脱敏 → ⑤ 指定位置存放 → ⑥ 限定用途使用 → ⑦ 到期销毁 → ⑧ 销毁确认
  • 交付结果：客户授权记录、数据登记、脱敏记录、销毁确认
  • 状态依据：已有 X-FDE-07（对接客户业务系统的授权与限流）、X-PRD-26（测试数据与行业素材获取）覆盖部分环节，本条补齐客户数据带离现场后的授权、脱敏、限定使用与销毁（推断）

1. 场景判定

  • 触发条件：客户发来样例/数据集用于开发；从客户环境导出数据；拟把客户数据送入第三方模型或评测集
  • 典型说法：「客户给了一批报告样例，拿回来调一下」「把客户的数据跑一下效果」
  • 判断问题：这份数据是否来自客户？是否含个人信息或商业秘密？是否会离开客户环境或进入第三方模型？
  • 不归本流程管：在客户环境内排查 → 请走 X-CS-28；直连客户业务系统读写数据 → 请走 X-FDE-07；向合作方获取案例与测试数据的渠道 → 请走 X-PRD-26；研发评测/微调中的数据集登记 → 请走 RND-92；对外提供材料的保密审查 → 请走 LEG-30；公开数据采集 → 请走 RND-88

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
审批人 审批数据使用申请 A FDE 负责人（当前：待指定）
使用人 申请、脱敏、按用途使用、到期销毁 R FDE 工程师（当前：待指定）
法务 提供授权模板、判定敏感数据 C 法务专员（当前：待指定）
销售 协助取得客户授权 C 客户对接销售（当前：待指定）
研发 提供受控存储位置 C 研发值班（当前：待指定）

3. 办之前请准备

  • 数据内容说明、数据量、是否含个人信息
  • 使用目的、使用人、使用期限
  • 是否会调用第三方/境外模型

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 向客户取得书面授权（用途、范围、期限、是否可用第三方模型） 客户对接销售、使用人 取数前 邮件/授权函 客户授权 🔧飞书固化
2 提交数据使用登记 使用人 取数前 飞书审批 登记单 🔧飞书固化
3 审批，含个人信息或敏感数据的转法务 FDE 负责人 提交后 1 个工作日内 飞书审批 审批结果 🔧飞书固化
4 脱敏（姓名、证件、联系方式、金额、单位名称） 使用人 入库前 脱敏脚本 脱敏数据 🤖自动化
5 存放到指定受控位置，不存个人电脑和公共群 使用人 脱敏后 受控网盘/仓库 存放记录 🔧飞书固化
6 仅按授权用途使用，不进入公共评测集或训练集 使用人 使用期内 — — 👤人工判断
7 到期或项目结束销毁并登记 使用人 到期后 5 个工作日内 登记表 销毁确认 🤖+👤（到期提醒，人工销毁确认）

5. 交付物与模板

  • 交付物：客户授权、数据使用登记、销毁确认
  • 建议模板/表单：客户数据使用登记（客户代号、数据内容、数据量、是否含个人信息、来源方式、用途、使用人、存放位置、是否调用第三方模型、授权凭证、到期日、销毁日期、销毁确认人）

6. 异常与升级

  • 未授权数据已带回 → 立即停止使用并补授权或销毁 → 升级 FDE 负责人与法务（当天）
  • 客户数据误发到公共群或上传外部平台 → 撤回、删除、评估影响 → 升级法务与研发部门报送人（当时），按 X-SEC-11 处置
  • 客户不同意带离 → 改为在客户环境内开发或使用合成数据

7. 衡量指标

  • 客户数据带离登记率，目标 100%
  • 到期销毁按时率，目标 100%
  • 客户数据外泄事件，目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在客户数据散落个人电脑与群聊、被送入境外模型、违反客户保密约定的风险（推断）

9. 分支变体

  • 涉密/国企客户：数据不得带离，只能在客户环境内开发
  • 内部 FDE 项目：使用公司内部业务数据时按 X-SEC-35 审批

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 公司是否有指定的客户数据受控存储位置？
  • 客户数据能否调用境外模型？由谁判断？
  • 销毁是否需要第二人复核？
X-FDE-23FDE 工时登记与项目成本核算待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨3 × 险3

  • 适用场景：FDE 人员投入客户项目、售前 Demo、内部 FDE 与培训时，按项目登记工时，月度核算项目人力成本与收入对比，为报价校准与人员调配提供依据
  • 负责人：主责——FDE 负责人（当前：待指定）；协同——FDE 工程师、财务专员、客户对接销售（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 项目编码建立 → ② 每周登记工时 → ③ 周度核对 → ④ 月度汇总成本 → ⑤ 对比报价与收入 → ⑥ 偏差复盘与报价校准
  • 交付结果：项目工时表、月度项目成本报表、报价校准建议
  • 状态依据：已有 X-DLV-08（交付项目台账与立项留痕，含工时登记）、X-FDE-04（定制项目方案与报价审核）覆盖部分环节，本条补齐 FDE 按项目工时登记、月度成本核算与报价回看（推断）

1. 场景判定

  • 触发条件：FDE 投入任何有编码的项目；每周五；每月初
  • 典型说法：「这个项目到底投了多少人天」「报价是不是报低了」
  • 判断问题：本周工作是否属于某个客户/内部项目？
  • 不归本流程管：研发项目研发费用归集 → 请走 FIN-31；FDE 派驻与调配 → 请走 X-FDE-05；全员日报周报 → 请走 CEO-12；项目台账登记与立项留痕 → 请走 X-DLV-08；定制项目报价编制 → 请走 X-FDE-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
核算负责人 建项目编码、审核工时、出报表 A FDE 负责人（当前：待指定）
FDE 工程师 每周按项目填报工时 R FDE 工程师（当前：待指定）
财务 提供人力成本单价、项目收入 C 财务专员（当前：待指定）
销售 依据报表校准报价 I 客户对接销售（当前：待指定）

3. 办之前请准备

  • 项目编码表（客户项目、售前、内部 FDE、培训、公共事务）
  • 各项目报价人日与合同收入
  • 人力成本单价口径（由财务提供，按岗位级别，不对个人公开）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 项目立项时建项目编码 FDE 负责人 立项当天 多维表格 项目编码 🔧飞书固化
2 按项目填报本周工时（半天为单位） FDE 工程师 每周五 18:00 前 多维表格/日报 工时记录 🔧+🤖
3 核对工时与项目进度是否匹配 FDE 负责人 下周一 12:00 前 多维表格 核对结论 👤人工判断
4 汇总月度项目人天与成本 FDE 负责人 每月第 3 个工作日前 报表 月度成本报表 🤖自动化
5 对比报价人天、合同收入，标出超支项目 FDE 负责人、财务专员 每月第 5 个工作日前 报表 偏差清单 🤖自动化
6 超支项目复盘，输出报价校准建议 FDE 负责人 每月第 10 个工作日前 会议 校准建议 👤人工判断

5. 交付物与模板

  • 交付物：工时表、月度项目成本报表、偏差清单、报价校准建议
  • 建议模板/表单：工时记录（日期、人员、项目编码、工作类型〔开发/现场/沟通/培训/售前〕、时长、说明）

6. 异常与升级

  • 工时未按期填报 → 机器人提醒 → 连续 2 周未填升级 FDE 负责人
  • 项目实际人天超报价 30% → 冻结非必要投入，评估追加收费（SAL-21）→ 升级销售负责人（3 个工作日内）
  • 无编码工时占比过高 → 复盘工作分配 → 升级研发部门报送人

7. 衡量指标

  • 工时填报率，目标 100%
  • 报价偏差率 = （实际人天 − 报价人天）/ 报价人天，目标 ≤ 20%
  • 可计费工时占比，目标按部门定

8. 低效诊断

  • 聊天中未见相关流程，存在定制项目亏本不自知、报价长期偏低、人员负荷不透明的风险（推断）

9. 分支变体

  • 交付工程师参与项目时同口径登记（可并入 X-DLV-08）
  • 内部 FDE 项目：工时用于评估提效收益，不核算收入

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 工时登记是否可以从 DailyWork 日报自动提取？
  • 人力成本单价口径由谁提供、保密范围如何？
  • 工时数据是否用于绩效？

X-RCT 招聘

报送人：待定 · 归属待定 · 26 条 · 已有 0 / 待优化 12 / 待新建 14
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-RCT-01招聘需求提报与 HC/预算/优先级管理业务或技术负责人判断需要补人、提前备人、扩招，或需要缓招、暂停、关闭岗位时，形成经审批的岗位需求和 HC 台账主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（技术岗 HC 与优先级，当前：丁震宇·推断待确认）、CEO（非技术岗与总编制，当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、用人部门负责人（当前：王皓南、杨萌、杨明学、张东郅、陈梦琪等·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 用人部门提交招聘需求单 → ② 人事查重并核对 HC 余量 → ③ 技术岗由 CTO、非技术岗由 CEO 审批（含预算带宽）→ ④ 写入 HC 台账并定优先级 → ⑤ 转入 JD 编写与挂岗 → ⑥ 每周评审优先级 → ⑦ 招满、暂停或取消时关闭岗位并通知经审批的招聘需求单；实时更新的 HC 台账（岗位、人数、优先级、预算带宽、HC 归属、状态）；每周优先级清单与 HC 周报待优化192
X-RCT-02岗位 JD 编写评审与挂网上下架岗位需求获批后需要起草或修改 JD，或岗位要挂网、更新、暂停、下架，或招聘效果差需要迭代 JD 时主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：王皓南、陈晖、杨明学、吴世豪、张东郅、葛家和等·推断待确认）、CTO（技术岗 JD 审核，当前：丁震宇·推断待确认）、CEO（非技术岗定薪区间，当前：邴龙志·推断待确认）、综合部负责人（职能岗 JD 起草，当前：赵雪冰·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、官网维护（当前：季学森·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求单获批 → ② 套用模板起草或复用旧版 → ③ 评审（职责、画像、bar、岗位名、薪资带宽）→ ④ 人事定稿，入岗位库并编版本 → ⑤ 各渠道挂岗，官网与清单同步 → ⑥ 每 2 周看效果并迭代 → ⑦ 暂停或下架时全渠道同步岗位库中带版本号的终版 JD；各渠道挂岗链接；与官网一致的《在招岗位清单》；岗位上下架记录待优化108
X-RCT-03招聘账号与签约主体管理模态、鼎慧、跃竞（协游）、子公司共用 BOSS、牛客等招聘账号时，用来决定岗位挂哪个账号、谁有权限、充值归谁、录用后与哪个主体签约，以及对候选人怎么说主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（账号注册与充值预算，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务（当前：待指定）、招聘专员（当前：张欣怡、陈雁·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 需求获批时确定用工/签约主体 → ② 按账号台账选定挂岗账号 → ③ JD 和沟通话术写明签约主体 → ④ 沟通、面试、Offer 全程用签约主体口径 → ⑤ 充值、VIP、道具走审批，按月汇总费用 → ⑥ 每季度复核账号和权限招聘账号与权限登记表；岗位-账号-签约主体对照；对外话术卡；月度渠道费用汇总待新建96
X-RCT-04招聘渠道拓展与招聘物料运营被动投递的量或质量不够，需要新增或调整招聘渠道（小红书、知乎、脉脉、牛客、开源社区、技术社群、官网招聘页等）、投放付费道具，或制作招聘海报、易拉宝、电梯海报、活动物料时主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（渠道付费预算和技术社区资源，当前：丁震宇·推断待确认）、技术招聘协调人（技术向文案与精准搜索，当前：陈晖·推断待确认）、运营（官网招聘页与宣发，当前：鲁周毅·推断待确认）、生态组负责人（活动现场物料，当前：陈梦琪·推断待确认）、CEO（活动资源，当前：邴龙志·推断待确认）、设计师（当前：待指定）、行政（物料张贴，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 月度渠道复盘，找出缺口 → ② 提渠道/投放方案 → ③ 预算审批 → ④ AI 出文案或物料初稿，设计复核 → ⑤ 对外口径审核 → ⑥ 发布、投放、张贴，统一投递入口 → ⑦ 登记渠道效果 → ⑧ 月度复盘 ROI 并调整渠道清单与月度渠道效果表；审核通过的招聘文案和物料；统一的简历投递入口待优化108
X-RCT-05主动寻访与开源人才外联发现优秀开源作者、技术博主或行业专家，或急岗需要主动寻访，决定建联、批量邮件外联、跟进回信，并转入招聘或顾问合作时主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（批量外联审批、技术建联，当前：丁震宇·推断待确认）、技术招聘协调人（识别人才、评估，当前：陈晖·推断待确认）、外联执行人（当前：李凯·推断待确认）、文案审核（当前：郭逸非·推断待确认）、用人部门负责人（当前：王皓南、李子遥等·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记线索 → ② 匹配岗位并判断优先级 → ③ 批量外联先审核（名单、模板、退订、发送量）→ ④ 小批量试发后分批发送 → ⑤ 24 小时内分类回复 → ⑥ 有意向的转入候选人台账 → ⑦ 顾问/外包合作分流 → ⑧ 每轮活动复盘寻访线索表（来源、状态、负责人、下一步）；经审核的外联模板；每轮外联复盘（发送量、回复率、简历数、投诉数）待新建192
X-RCT-06员工内推受理与内推奖励员工推荐熟人、同学或开源圈朋友应聘公司在招岗位时，从登记、初筛、面试、回复推荐人，一直到按节点认定和发放内推奖励主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人/面试官（当前：李子遥、郭逸非、王子明、吴亚军等·推断待确认）、CTO（技术岗内推初判，当前：丁震宇·推断待确认）、CEO（制度与特殊情形认定，当前：邴龙志·推断待确认）、财务负责人（奖励随工资发放，当前：黄梦婷·推断待确认）、运营（招聘推文扩散积分，当前：鲁周毅·推断待确认）、招聘专员（当前：王丽菲、张欣怡·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）① 推荐人查《在招岗位清单》→ ② 填内推表单 → ③ 人事登记、查重、分发 → ④ 用人方 2 个工作日内初筛 → ⑤ 7 个工作日内优先面试 → ⑥ 结果回复推荐人 → ⑦ 按节点认定奖励 → ⑧ 公示和异议期 → ⑨ 随工资发放内推台账（推荐人、候选人、岗位、状态、奖励节点）；给推荐人的结果回复；奖励公示和发放清单待优化96
X-RCT-07简历收集、初筛与分发各渠道每个工作日进来新简历时，由人事收集、去重、入库，经 AI 快筛和硬条件过滤后分发给指定筛选人，在约定时限内拿到“约面/待定/淘汰”结论主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡、匡蓉、王丽菲·推断待确认）、岗位筛选人（当前：陈晖、望政韬、王皓南、杨明学、宋祺睿、张东郅、王子明、葛家和等·推断待确认）、CTO（技术岗筛选标准与终筛，当前：丁震宇·推断待确认）、AI 打分工具维护（当前：季学森、魏宗浩·推断待确认）、子主体负责人（当前：徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 每日从各渠道收简历 → ② 去重、规范命名、入候选人台账 → ③ AI 按岗位筛选清单打分分档 → ④ 人事按硬条件剔除 → ⑤ 推送给岗位筛选人 → ⑥ 筛选人 1 个工作日内标结论 → ⑦ 人事按结论联系候选人 → ⑧ 每周抽检 AI 结果，校准标准每份简历在候选人台账中都有岗位、来源、AI 分档、筛选人结论和日期；每日约面名单；按岗位分版本的筛选清单待优化180
X-RCT-08简历真实性核验与 AI 代答识别简历、笔试或面试中出现真实性疑点时启动，包括经历时间线冲突、GitHub/开源贡献对不上、简历含隐藏提示词或有 AI 生成痕迹、疑似代考代答、培训班包装项目、疑似竞对派遣、换身份重复投递。核验完成并给出放行/加验/淘汰结论后才继续推进主责——招聘 HR（当前：黄莹·推断待确认）；协同——技术面试官（当前：陈晖、望政韬、吴世豪、王皓南、王子明·推断待确认）、技术初筛人（当前：张楠·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、法务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 查重并标注疑点 → ② 对照红线快速判断 → ③ HR 核实基础信息 → ④ 技术核验 GitHub/作品 → ⑤ 笔试/面试中定向追问 → ⑥ 出结论（放行/加验/淘汰）→ ⑦ 留痕入台账候选人真实性核验记录（疑点、核验手段、证据、核验人、结论），候选人台账上的“放行/加验/淘汰/拉黑”标签待新建144
X-RCT-09候选人预沟通与意向登记简历通过用人方二筛或笔试初步合格后、约面前，HR 电话/微信联系候选人确认意向和基本条件，按固定字段写回台账，由用人方决定是否约面主责——招聘专员（当前：张欣怡·推断待确认）；协同——招聘助理（当前：匡蓉、陈雁·推断待确认）、用人方/面试官（当前：丁震宇、陈晖、王皓南·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 用人方提交待沟通名单与附加问题 → ② HR 按标准问题清单沟通 → ③ 结果录入台账并通知用人方 → ④ 用人方决定约面/淘汰/暂缓 → ⑤ HR 回复候选人并保温 → ⑥ 超时提醒每位候选人一条字段完整的预沟通记录，以及用人方的下一步决定待优化90
X-RCT-10笔试与技术实操考核候选人通过初筛（或预沟通）后，需要用笔试、上机题或实操题验证真实能力；也包括题库的出题、审题、改版主责——技术笔试负责人（当前：陈晖·推断待确认，需确认是否已变更）；协同——招聘 HR（当前：黄莹、张欣怡、匡蓉·推断待确认）、各岗位出题人（当前：王皓南、望政韬、张东郅、王子明、张楠、吴世豪·推断待确认）、IT 运维负责人（运维岗实操与笔试系统，当前：杨明学·推断待确认）、阅卷复核人（当前：岳阳·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 岗位绑定题目（题库维护）→ ② 确认笔试意向并查重 → ③ 按岗位批量发题 → ④ 截止提醒与回收 → ⑤ AI 预审 → ⑥ 阅卷定档 → ⑦ 结论回写并触发下一步 → ⑧ 题库复盘每位候选人的笔试档次与处置建议（面/可面可不面/暂缓入池/淘汰），按岗位、版本管理的题库与评分标准待优化180
X-RCT-11面试安排与面试官分配候选人通过预沟通或笔试、进入面试环节时，确定轮次与面试官，协调时间、线上/线下、会议室、是否带电脑，创建日程并通知到位主责——招聘专员（当前：张欣怡·推断待确认）；协同——用人部门负责人（指派面试官，当前：丁震宇、王皓南、徐莉·推断待确认）、面试官（当前：陈晖、望政韬、吴世豪、岳阳、杨云峰、魏宗浩、王子明、张楠、张东郅·推断待确认）、招聘助理（当前：匡蓉、陈雁·推断待确认）、到面接待（当前：宫经喜·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）① 按“岗位×轮次面试官表”确定主面/副面 → ② 查面试官空闲给出时段 → ③ 约候选人并确定线上/线下 → ④ 建日程、订会议室、发到面指引 → ⑤ 面试前 1 个工作日发资料包 → ⑥ 面试前 1 小时双向确认 → ⑦ 改期与爽约处理已发出的面试日程（标题“岗位-候选人-第 N 面”，含会议链接或会议室）、发给候选人的到面/线上指引、发给面试官的资料包待优化180
X-RCT-12面试执行、面评与晋级决策面试当天按统一规范进行（时长、摄像头、录制、内部讨论边界），结束后面试官按模板提交面评，用人部门负责人据此决定进入二面、终面、录用、入池或淘汰主责——用人部门负责人（当前：技术岗丁震宇、跃竞徐莉·推断待确认）；协同——面试官（当前：陈晖、望政韬、王皓南、吴世豪、岳阳、宋祺睿、张东郅、杨明学、魏小东、康紫馨、段涵、陈梦琪、杨朋伟·推断待确认）、招聘 HR（当前：黄莹·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 面前看资料包、按题库备题 → ② 开场规范（录制、摄像头、纪要权限）→ ③ 分阶段执行，明显不符 20 分钟内收尾 → ④ 24 小时内提交结构化面评 → ⑤ HR 汇总并提醒 → ⑥ 负责人 1 个工作日内做晋级决策 → ⑦ 回写台账并转下游每场面试一份结构化面评（维度评分、强弱项、风险、结论、建议），每位候选人一条晋级决策记录（二面/终面/录用/入池/淘汰及决策人）待优化180
X-RCT-13面试官培养与考察标准新面试官上岗、新岗位开招前考察点不清，或面试评价质量不稳定时，明确各岗位考察标准和题型，按“旁听 → 副面 → 主面”培养面试官，并定期更新面试官手册主责——面试官手册负责人（当前：王皓南·推断待确认）；协同——面试辅导人（当前：岳阳·推断待确认）、AI 实操考官（当前：季学森·推断待确认）、测试岗标准负责人（当前：张东郅·推断待确认）、人事负责人（当前：黄莹·推断待确认）、新面试官（当前：杨云峰、魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 开招前建岗位考察标准卡 → ② 指定新面试官并安排旁听 → ③ 副面带教 → ④ 认证为主面 → ⑤ 面试规则与安全培训 → ⑥ HR 观摩学习 → ⑦ 每季度校准与手册更新岗位考察标准卡、面试官手册（题库 + 评分要点 + 面试规则）、面试官名册（认证状态、可面岗位）待新建36
X-RCT-14跨组面试支援与候选人转推/归属分配多个业务线（鼎慧、跃竞、AI 教育、基座、Leap、开放平台/FDE 等）同时招人，需要确定简历归属；候选人不适合本组但可能适合别组；某组缺面试官需要借调主责——人事负责人（当前：黄莹·推断待确认）；协同——各组用人负责人（当前：王皓南、王子明、徐莉·推断待确认）、被借调面试官（当前：张楠、吴世豪、葛家和、杨明学·推断待确认）、技术复筛人（当前：陈晖、望政韬·推断待确认）、招聘专员（当前：张欣怡·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 简历按岗位标签分配业务线 → ② 不对口候选人标“建议转推”与理由 → ③ 通知目标组负责人 → ④ 24 小时内回应要/不要 → ⑤ 接收组复用已有面评，只补差异轮次 → ⑥ 借调面试官登记 → ⑦ 无人接收的入人才池台账中每位候选人有明确“归属组/负责面试官”，转推与借调有记录和结论待新建48
X-RCT-15面试结果通知与不录用处理笔试、一面、二面或终面有结论后，由 HR 按时限和话术通知候选人（通过/婉拒/暂缓入池），对需要留证的不录用写明原因，对主动联系的不合适候选人礼貌回复主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡·推断待确认）、面试官（当前：陈晖、望政韬、王皓南·推断待确认）、用人部门负责人（当前：丁震宇·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 面试官只把结论交 HR，不当场拒 → ② HR 按结论类型选话术 → ③ 在时限内通知候选人（内推同时回复推荐人）→ ④ 二面及以上淘汰补写正式不录用原因 → ⑤ 流程失误时正式致歉并处理路费 → ⑥ 收集候选人反馈 → ⑦ 台账回写，入池或拉黑候选人收到的结果通知、内部留存的不录用原因（需要时）、台账状态更新（录用/淘汰/入池/拉黑）待新建120
X-RCT-16候选人台账、人才池与招聘系统维护同时推进多名候选人（全职/实习/远程/内推），需要统一登记候选人状态、面试官和面评；或候选人放弃、失联、已有别家 offer、被淘汰、暂缓时，需结案或打标签放入人才池，以便日后回捞主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、匡蓉、陈雁·推断待确认）、技术岗候选人池维护人（当前：丁震宇·推断待确认）、面试官（当前：王皓南、望政韬、岳阳、王子明·推断待确认）、招聘系统开发（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 定唯一主数据源 → ② 新简历建档并查重 → ③ 阶段变更回写 → ④ 面评挂接 → ⑤ 结案或打标签入人才池 → ⑥ 每日待跟进推送 → ⑦ 月度人才池回捞与清理一份唯一、实时的候选人主台账（含阶段、面试官、面评链接、结论与原因），可按标签检索的人才池视图，每日待跟进摘要待优化108
X-RCT-17定薪谈薪、录用审批与 Offer 发放候选人终面通过后，需要确定岗位名称、职级、用工类型与主体，核定试用期与转正薪资、补贴，完成审批并发出录用通知书主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人/面试官（当前：王皓南、杨萌、张东郅、葛家和、徐莉、王子明·推断待确认）、技术岗定薪审批人（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 面试官出分项评价 → ② HR 摸底期望与现薪 → ③ 先定职能、职级与主体 → ④ 对照薪酬带宽出方案 → ⑤ 录用审批 → ⑥ HR 单一出口谈薪 → ⑦ 录用通知书审核并邮件发出 → ⑧ 归档并更新人力成本表已审批的录用审批单（定薪理由、试用期、转正薪资、补贴、主体）、经审核并发出的录用通知书、候选人确认回执与到岗日期待优化400
X-RCT-18拟录用背景调查候选人终面通过、薪资意向谈妥并口头接受后、正式发 offer 前，按岗位风险等级核实学历、工作经历、薪资流水和离职情况；或资料中出现疑点需要追加核实主责——HR 负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：徐莉、王子明·推断待确认）、面试官（当前：葛家和、张东郅·推断待确认）、法务（当前：待指定）、背调结论决策人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 判定背调等级 → ② 取得候选人授权与材料 → ③ 材料一致性核验 → ④ 前司与学历核实 → ⑤ 疑点追加核实 → ⑥ 出背调结论表 → ⑦ 决策并归档一份背调结论表（核实项、结果、疑点、结论：通过/有条件通过/不通过），作为发 offer 的前置条件留档待新建108
X-RCT-19录用确认到入职衔接候选人接受 offer 后到入职首日之间，确认到岗日期、用工形式、挂靠团队、直属上级与带教人、座位、设备与账号，完成交接并发出入职欢迎主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、王丽菲·推断待确认）、用人部门负责人（当前：丁震宇、陈子康·推断待确认）、带教人（当前：岳阳、王皓南、杨萌、李凯·推断待确认）、座位与行政协调（当前：杨萌·推断待确认）、IT 账号开通（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 书面确认到岗日期与用工形式 → ② 定挂靠团队、直属上级与带教人 → ③ 自动派发入职任务清单 → ④ 到岗前 1 天提醒候选人 → ⑤ 首日交接给带教人 → ⑥ 首个任务与首周跟进候选人到岗确认记录、已全部关闭的入职任务清单（座位、设备、账号权限、带教人、首个任务），新人按时到岗并被带教人接住待新建144
X-RCT-20实习生、兼职与校园招聘业务组需要长期实习生、暑期实习生、远程实习生或短期兼职；或有高校合作批量实习机会、校园宣讲、熟人推荐、开源社区与黑客松等来源的实习候选人，需要快速汇总需求、筛选、简化面试并录用主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人（当前：杨萌、张东郅、陈梦琪、徐莉、李鹏为·推断待确认）、高校合作发起人（当前：邴龙志·推断待确认）、宣讲人与宣讲材料（当前：马漳毓、李铭熙、王皓南·推断待确认）、市场岗初面（当前：杨朋伟、闫登辉·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 用人部门提交实习/兼职用工申请 → ② HR 汇总需求（高校批次导出给学院）→ ③ 多渠道收简历统一入台账 → ④ HR 硬条件预筛 → ⑤ 30 分钟简化面试 → ⑥ 1 个工作日内出结论 → ⑦ 按实习生标准出薪 → ⑧ 转入职衔接实习/兼职需求汇总表、按期到岗的实习生或兼职人员（含带教人与任务说明），高校批次的岗位需求清单与反馈记录待新建72
X-RCT-21急岗推进、招聘进度同步与漏斗复盘关键岗位被定为急岗（如 Agent 负责人、Agent 全栈、子公司技术负责人、后端、产品），或业务负责人关心招聘进度、春节前/月初到岗节点需要汇总漏斗，或连续面试通过率过低需要复盘渠道和面试策略主责——HR 负责人（当前：黄莹·推断待确认）；协同——技术招聘筛选与笔试（当前：陈晖·推断待确认）、HR 招聘专员（当前：张欣怡、陈雁、匡蓉·推断待确认）、用人部门负责人（当前：王皓南、徐莉、杨萌·推断待确认）、面试官（当前：望政韬、吴世豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 定急岗等级与目标 → ② 建岗位×阶段看板 → ③ 按流水线推进（收→筛→笔试→面试）→ ④ 急岗每日、常规岗每周自动推送进度 → ⑤ 超时自动提醒 → ⑥ 节点汇总 → ⑦ 月度或触发式漏斗复盘 → ⑧ 策略调整与 HC 变更留痕实时招聘看板、急岗日报与常规周报、月度漏斗复盘纪要（数据、共性问题、调整动作）待优化180
X-RCT-22招聘团队分工与交接招聘执行人员（招聘专员、招聘助理）或岗位面试官更换、新主体或新项目组开始招聘、职责边界不清（谁筛简历、谁约面、谁谈薪、谁背调）时，重新界定分工并完成候选人与台账交接主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员/招聘助理（当前：张欣怡、匡蓉、陈雁·推断待确认）、主体业务负责人（当前：徐莉·推断待确认）、各岗位面试官（当前：王子明、张楠、魏小东、段涵、陈晖、康紫馨、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）① 识别人员变动或职责空白 → ② 更新招聘分工矩阵 → ③ 群公告置顶 → ④ 交接在途候选人与账号权限 → ⑤ 新成员开权限 → ⑥ 双方确认交接 → ⑦ 一周后回查最新版招聘分工矩阵（岗位 → 简历筛选人 → 一面 → 二面 → 谈薪人 → 背调人 → offer 发放人）、交接清单与确认记录待新建72
X-RCT-23高管与子公司负责人招聘合资公司或子公司需要总经理兼技术负责人、CTO，或需要高薪的 Agent 专家、招投标 AI 方向负责人等关键岗位，需要从需求确认、寻访到多轮高层面试、定薪与签约的完整招聘主责——高管招聘发起人/创始人兼 CTO（当前：丁震宇·推断待确认）；协同——HR 负责人（当前：黄莹·推断待确认）、技术面试官（当前：王皓南·推断待确认）、技术筛选与笔试（当前：陈晖·推断待确认）、业务方/合资方对接人（当前：常元和·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求确认与预期管理 → ② 岗位定位与 JD → ③ 多渠道寻访 → ④ 预筛与笔试 → ⑤ 多轮高层面试 → ⑥ A 级背调 → ⑦ 薪酬与股权方案审批 → ⑧ offer 与签约主体确认 → ⑨ 退出原因复盘岗位定位说明与 JD、候选人评估记录、经审批的薪酬与股权方案、签约的关键岗位人选（或退出原因复盘与下一步方案）待新建100
X-RCT-24候选人个人信息与简历数据合规管理收集、存储、转发、用 AI 筛选候选人简历与面评，以及定期删除不再需要的候选人信息时适用主责——招聘专员（当前：待指定）；协同——法务（当前：待指定）、IT 管理员（当前：待指定）、面试官（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 收集时告知与同意 → ② 统一存放与权限控制 → ③ AI 处理前脱敏或确认工具合规 → ④ 内部流转限范围 → ⑤ 定期清理 → ⑥ 候选人查询/删除请求响应候选人信息存放清单与访问权限表、AI 处理规则、定期清理记录待新建96
X-RCT-25猎头与外部招聘服务商合作及费用结算急岗、高端岗位或管理岗需要委托猎头、RPO 或其他外部招聘服务商推荐候选人，及其后续保证期与费用结算时启动主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 判断是否需要外部服务 → ② 服务商比选 → ③ 签署合作协议 → ④ 下发岗位与推荐规则 → ⑤ 候选人归属判定 → ⑥ 入职与保证期跟踪 → ⑦ 对账付款已签合作协议、服务商台账、推荐归属记录、付款与保证期记录待新建72
X-RCT-26Offer 变更、撤回与候选人未到岗处理Offer 发出后需要修改条件、因岗位冻结或背调问题撤回 Offer，或候选人延期、爽约、拒绝到岗时启动主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、行政（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）① 识别变更情形 → ② 评估影响与法律风险 → ③ 审批 → ④ 书面告知候选人 → ⑤ 取消入职准备 → ⑥ 更新台账与人才池 → ⑦ 启动补位书面变更/撤回通知或候选人确认记录；已取消的工位、设备、账号准备；更新后的招聘台账待新建48
X-RCT-01招聘需求提报与 HC/预算/优先级管理待优化192

状态：待优化｜证据：有证据（卡片 17 张 / 会话 11 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：业务或技术负责人判断需要补人、提前备人、扩招，或需要缓招、暂停、关闭岗位时，形成经审批的岗位需求和 HC 台账
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（技术岗 HC 与优先级，当前：丁震宇·推断待确认）、CEO（非技术岗与总编制，当前：邴龙志·推断待确认）、COO（当前：常元和·推断待确认）、用人部门负责人（当前：王皓南、杨萌、杨明学、张东郅、陈梦琪等·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 用人部门提交招聘需求单 → ② 人事查重并核对 HC 余量 → ③ 技术岗由 CTO、非技术岗由 CEO 审批（含预算带宽）→ ④ 写入 HC 台账并定优先级 → ⑤ 转入 JD 编写与挂岗 → ⑥ 每周评审优先级 → ⑦ 招满、暂停或取消时关闭岗位并通知
  • 交付结果：经审批的招聘需求单；实时更新的 HC 台账（岗位、人数、优先级、预算带宽、HC 归属、状态）；每周优先级清单与 HC 周报
  • 状态依据：已有《在招岗位清单》wiki，2026-06 也建了招聘优先级分级，但 HC 仍在群里口头给。01～10 月多个群反复对账“还有多少 HC”“这个岗位还招吗”，也反复出现“HC 被砍”“先暂停”和催办，累计 40 次以上

1. 场景判定

  • 触发条件：团队持续缺人（长期加班、交付排队、单点无备岗）；季度或月度规划要新增角色；业务方要为 1～2 个月后的工作量提前备人；新项目、新子公司或新产品线启动；场地、成本或业务变化，需要缓招、暂停或关闭岗位
  • 典型说法：「该招新交付工程师了」「现在基座还有多少 HC」「真得收束一下招聘优先级了」「直接跟我说还要招几个人」「名额保 2 争 3」「已经没 HC 了」
  • 判断问题：这次是否要新增或变更“岗位 × 人数 × 预算”？如果只改 JD 文案或换渠道，不走本流程
  • 不归本流程管：JD 撰写与挂网 → 请走 X-RCT-02；年度人力成本测算与编制统计 → 请走 HR-03；具体候选人定薪与 Offer → 请走 X-RCT-17；高管与子公司负责人招聘 → 请走 X-RCT-23；实习生/校招计划 → 请走 X-RCT-20；急岗进度追踪与漏斗复盘 → 请走 X-RCT-21

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用人部门负责人 填需求单，写清缺口原因、来了做什么、人数、到岗时间和面试官 R 用人部门负责人（当前：王皓南、杨萌、杨明学、张东郅、陈梦琪等·推断待确认）
人事负责人 受理、查重、核对 HC 余量、维护台账、关闭岗位、发周报 R 人事负责人（当前：黄莹·推断待确认）
CTO 审核技术岗需求是否合理，定预算带宽和技术岗优先级 R（技术岗审批） CTO（当前：丁震宇·推断待确认）
CEO 审批非技术岗；对总编制、总包和场地约束拍板，最终裁定 A CEO（当前：邴龙志·推断待确认）
COO 对紧急岗位的期限、商务类岗位给意见 C COO（当前：常元和·推断待确认）
财务负责人 核对预算口径和人力成本影响 C 财务负责人（当前：黄梦婷·推断待确认）
子主体负责人 提报子主体的岗位需求，确认预算归属 R（子主体） 跃竞负责人（当前：徐莉·推断待确认）
行政 确认工位、场地能否承接 C 行政专员（当前：待指定）
招聘专员 接收台账变更，执行挂岗和下架 I 招聘专员（当前：张欣怡、匡蓉·推断待确认）

3. 办之前请准备

  • 缺口说明：为什么缺人、来了做什么、活怎么分、不招会有什么后果
  • 岗位画像草稿：岗位名、职级、正职/实习、技术栈、是否要做交付
  • 人数、建议优先级（P0/P1/P2）、期望到岗日期
  • 建议预算/薪资带宽（只写在需求单里，不在群里公开）
  • HC 归属：所属组和主体（模态本部/鼎慧/跃竞/子公司），是否占用其他组的 HC
  • 至少 2 名面试官及其每周可投入时间
  • 与行政确认工位是否够用

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交招聘需求单（新增/扩招/缓招/暂停/关闭） 用人部门负责人 发现缺口后 2 个工作日内 飞书审批 需求单 🔧飞书固化
2 查重：核对 HC 余量、同类在招岗位、可内部调剂的候选人 人事负责人 收单后 1 个工作日内 HC 台账（多维表格） 核对意见 🔧+🤖
3 审批：技术岗由 CTO 审，非技术岗由 CEO 审；超出总编制或跨主体的由 CEO 终审 CTO / CEO 提交后 2 个工作日内 飞书审批 审批结论、预算带宽 👤人工判断
4 写入 HC 台账，标注优先级和“急”，生成岗位编号 人事负责人 审批通过当天 多维表格 台账记录 🔧飞书固化
5 通知用人部门启动 JD（转 X-RCT-02），同步招聘专员 人事负责人 审批通过当天 飞书机器人 启动通知 🔧+🤖
6 每周优先级评审：按 P0/P1/P2 排序，决定新增、缓招或暂停 CTO 主持，人事负责人记录 每周固定 1 次，30 分钟内 飞书会议 + 台账视图 本周优先级清单 👤人工判断
7 自动汇总 HC 余量、在招、已录用和缺口，推送管理层 人事负责人 每周五 18:00 前 多维表格自动化 HC 周报 🤖自动化
8 招满、暂停或取消时：台账改状态，下架岗位，告知在途候选人和内推人 人事负责人 决定后 1 个工作日内 台账 + 招聘平台 关闭记录 🔧飞书固化

5. 交付物与模板

  • 交付物：招聘需求单、HC 台账、每周优先级清单、HC 周报、岗位关闭记录
  • 建议模板/表单：
    • 招聘需求单字段：申请类型、主体、所属组、岗位名、人数、用工类型（正职/实习）、优先级、缺口原因、到岗目标日期、预算带宽档（不公开）、HC 归属、面试官、是否复用已有 JD
    • HC 台账字段：岗位编号、主体、组、岗位、批准人数、已录用、在途 Offer、剩余 HC、优先级、状态（在招/暂缓/暂停/已关闭）、审批人、审批日期、最近变更原因

6. 异常与升级

  • 技术岗需求由 CTO 在带宽内审批即可执行；超出总编制、跨主体或超出预算带宽的 → 升级 CEO 终审（2 个工作日内）
  • 群里口头要 HC 但没提交需求单 → 人事回复需求单链接，暂不挂岗 → 用人部门 1 个工作日内补单
  • 多个组同时争招聘资源，优先级冲突 → 先按台账优先级执行，冲突事项提交周会 → 升级 CTO（当周）；涉及非技术岗的升级 CEO
  • HC 归属不清（如基座 HC 与资管 HC，全职归公司还是实习归组） → 台账标“待定归属” → CTO 2 个工作日内裁定
  • HC 被削减或暂停，但已有候选人在推进 → 人事 1 个工作日内告知候选人和内推人 → 需要保留例外人选时升级 CEO
  • 预算超出带宽或场地不足 → 标暂缓并登记原因 → CEO 3 个工作日内决定
  • 编制规模接近与人数挂钩的法定成本节点（如残保金） → 人事在周报中提示 → CEO

7. 衡量指标

  • 需求单覆盖率 = 走需求单的新开岗位数 / 新开岗位总数，目标 100%
  • 需求审批周期 = 从提交到出审批结论的工作日数，目标 ≤ 2 个工作日
  • HC 台账准确率 = 每月抽查台账与平台在挂岗位一致的比例，目标 ≥ 95%
  • 岗位关闭及时率 = 招满或暂停后 1 个工作日内下架的比例，目标 ≥ 95%
  • 优先级稳定度 = 同一岗位每月优先级变更次数，目标 ≤ 1 次

8. 低效诊断

  • 现象：需求没有统一入口，都在群里 @ 人事“急急急”，人事带宽被同时占满｜依据：「鼎慧产研决策部」2026-06、「模态人事大主管」2026-06
  • 现象：HC 余量和缺口数只能靠群内反复对账｜依据：「技术岗招聘沟通」2026-02、「技术岗招聘沟通」2026-06
  • 现象：岗位人数和优先级一周内多次变化（5 人→4 人→2 人，缓招又改成暂停），已推进的候选人被迫放弃｜依据：「鼎慧产研决策部」2026-04、「跃竞招聘群」2026-09
  • 现象：HC 归属不清、JD 找不到，补人迟迟启动不了｜依据：「Leap产研测」2026-08
  • 现象：急岗提出几个月仍未到岗，没有进度和优先级回看｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：编制“先不管，招到再说”，谁有权批 HC 不清楚｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-04
  • 现象：JD 和岗位画像迟迟定不下来，人事无法启动｜依据：「鼎慧产研决策部」2026-01、「忠橙星行星引擎」2026-01

9. 分支变体

  • 技术岗：CTO 审合理性和预算。研发团队可按季度提交“团队现状/Q1/Q2”规划（P0/P1/P2），再由需求单拆成具体岗位
  • 非技术岗（财务、总助、产品、运营、行政）：CEO 审批
  • 跃竞：子主体负责人提出各岗位名额和预算区间，人事按台账执行；预算归子主体，人事话语权受合资方约束
  • 独立公司主体/子公司（如招投标子公司）：向该主体负责人申请 HC 后自行招聘，可复用集团 JD
  • 正职和实习分开计 HC，实习 HC 可能与转正名额绑定
  • 合作公司代招：预算由对方承担，需书面确认
  • 外部公司推荐或借调人员：先评估是否需要、有没有预算，再决定是否进入本流程

10. 待确认问题

  • 技术岗 HC 是否由 CTO 审批，非技术岗是否由 CEO 审批？跨主体和超出总编制的需求是否统一由 CEO 终审？
  • 是否启用飞书审批“招聘需求单”，并用多维表格 HC 台账取代现在的在线表格和 wiki 清单？
  • 每周优先级评审由谁主持？固定在周几？
  • 正职和实习是否分开计 HC？实习生是否占用转正 HC？
  • 跃竞、鼎慧、子公司的 HC 和预算是否纳入集团台账统一可见？
  • “2 个工作日内补单、2 个工作日内审批”是否可行？
X-RCT-02岗位 JD 编写评审与挂网上下架待优化108

状态：待优化｜证据：有证据（卡片 13 张 / 会话 11 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：岗位需求获批后需要起草或修改 JD，或岗位要挂网、更新、暂停、下架，或招聘效果差需要迭代 JD 时
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：王皓南、陈晖、杨明学、吴世豪、张东郅、葛家和等·推断待确认）、CTO（技术岗 JD 审核，当前：丁震宇·推断待确认）、CEO（非技术岗定薪区间，当前：邴龙志·推断待确认）、综合部负责人（职能岗 JD 起草，当前：赵雪冰·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、官网维护（当前：季学森·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 需求单获批 → ② 套用模板起草或复用旧版 → ③ 评审（职责、画像、bar、岗位名、薪资带宽）→ ④ 人事定稿，入岗位库并编版本 → ⑤ 各渠道挂岗，官网与清单同步 → ⑥ 每 2 周看效果并迭代 → ⑦ 暂停或下架时全渠道同步
  • 交付结果：岗位库中带版本号的终版 JD；各渠道挂岗链接；与官网一致的《在招岗位清单》；岗位上下架记录
  • 状态依据：已有 wiki JD、《在招岗位清单》和共享需求表，但 JD 版本散落多处。谁来写反复推诿，同一岗位在两个账号挂出且薪资口径不同，岗位名和定位多次返工，01～10 月约 40 次

1. 场景判定

  • 触发条件：X-RCT-01 审批通过的新岗位；岗位定位、技术栈或用工类型变化；连续 2 周投递量少或匹配度低；官网或招聘站更新；岗位招满、暂停或取消
  • 典型说法：「你们写 JD 吧」「记得发 JD 我也 review 一下」「写个 JD 给我」「新版 JD，旧的不要删，改成初级测试」「先挂上去就是了」「我们有在招岗位列表吗」
  • 判断问题：岗位和人数已经批了吗？没批先走 X-RCT-01。本次只改 JD 内容或挂网状态吗？
  • 不归本流程管：HC 和人数变更 → 请走 X-RCT-01；挂哪个招聘账号、签约主体 → 请走 X-RCT-03；渠道投放和招聘海报 → 请走 X-RCT-04；具体候选人谈薪 → 请走 X-RCT-17；简历筛选标准 → 请走 X-RCT-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用人部门负责人 用模板起草技术岗 JD，确认画像、必须项和 bar R 用人部门负责人（当前：王皓南、陈晖、杨明学、吴世豪、张东郅、葛家和等·推断待确认）
CTO 审核技术岗 JD 的定位、岗位名和薪资带宽 R（技术岗评审） CTO（当前：丁震宇·推断待确认）
CEO 确认非技术岗的岗位要求和定薪区间；对带宽调整和评审争议最终拍板 A CEO（当前：邴龙志·推断待确认）
综合部负责人 起草行政、总助等职能岗 JD R（职能岗） 综合部负责人（当前：赵雪冰·推断待确认）
人事负责人 统一版本、补福利段、入岗位库、决定挂网和下架 R 人事负责人（当前：黄莹·推断待确认）
招聘专员 在 BOSS、牛客等渠道发布、更新、下架 R（执行） 招聘专员（当前：张欣怡·推断待确认）
官网维护 官网招聘页和招聘站同步 R（官网） 官网维护（当前：季学森·推断待确认）
财务负责人 起草财务类岗位 JD C 财务负责人（当前：黄梦婷·推断待确认）
面试官 获知 JD 版本，按 JD 考察 I 各面试官

3. 办之前请准备

  • 已批准的需求单编号（岗位、人数、用工类型、优先级、预算带宽）
  • 岗位画像：要什么样的人、bar 在哪、汇报给谁、入职后前 3 个月做什么
  • 必须项和加分项各不超过 5 条，写明技术栈或业务要求（如 Go、TypeScript、AI 编程工具经验）
  • 可参考的旧版 JD 或同行 JD 链接
  • 用工主体与工作地点（与 X-RCT-03 口径一致）
  • 是否需要单独的实习版、初级/高级版

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板起草 JD；能复用旧版的先复用再修改 用人部门负责人（职能岗由综合部负责人） 需求获批后 2 个工作日内 JD 模板（飞书文档）+ AI 初稿 JD 草稿 🤖自动化
2 评审定位、岗位名、bar、必须项，确认薪资带宽 技术岗 CTO / 非技术岗 CEO 收到草稿后 1 个工作日内 飞书文档评论 / 审批 评审意见 👤人工判断
3 定稿：补公司介绍、福利段、用工主体，编版本号，入岗位库 人事负责人 评审通过后 1 个工作日内 岗位库（多维表格） 终版 JD 🔧飞书固化
4 在 BOSS、牛客等渠道挂岗，岗位名统一，薪资口径与岗位库一致 招聘专员 定稿后 1 个工作日内 招聘平台 渠道链接回填岗位库 🔧飞书固化
5 同步《在招岗位清单》和官网招聘页 人事负责人、官网维护 定稿后 2 个工作日内 wiki + 官网 清单与官网一致 🔧+🤖
6 看效果：投递量、匹配率；不理想时出简版或另一版做 A/B 人事负责人、用人部门负责人 每 2 周 1 次 岗位库 + 漏斗数据 迭代版 JD（旧版保留） 🔧+🤖
7 暂停或下架：全部渠道同步，岗位库改状态 招聘专员 收到决定后 1 个工作日内 招聘平台 + 岗位库 下架记录 🔧飞书固化

5. 交付物与模板

  • 交付物：终版 JD（含版本号）、岗位库记录、渠道链接、上下架记录
  • 建议模板/表单：
    • JD 模板字段：岗位名（方向-岗位-级别，如“网关-运维开发-初级”）、用工主体、所属组、汇报线、工作地点、用工类型、岗位画像、职责、必须项、加分项、bar/淘汰线、AI 工具使用要求、薪资带宽（对外口径）、福利段（统一复用）、面试流程说明
    • 岗位库字段：岗位编号、需求单编号、JD 链接、版本号、负责人、评审人、薪资带宽、渠道及链接、挂网日期、状态、最近修改原因

6. 异常与升级

  • 技术岗 JD 经 CTO 评审通过即可定稿；CTO 与用人部门意见不一，或需突破已批薪资带宽的 → 升级 CEO 拍板（2 个工作日内）
  • 草稿超过 2 个工作日未交 → 人事在台账标红并提醒 → 升级 CTO 或 CEO（第 3 个工作日）
  • 发现同一岗位在多个账号挂出且薪资口径不一 → 当天下架多余版本，以岗位库为准 → 人事负责人当天处理
  • 岗位名或定位与实际业务不符（如行业写错、社招和实习混在一个 JD） → 立即下线修改 → 由评审人 1 个工作日内确认
  • 岗位要求和薪资带宽明显不匹配、长期招不到 → 下次效果回看时提出弱化要求或调带宽 → CEO/CTO 拍板
  • 官网岗位删减前未确认是否真不招 → 官网维护先向人事核实 → 人事 1 个工作日内答复

7. 衡量指标

  • JD 出稿周期 = 需求获批到挂网的工作日数，目标 ≤ 4 个工作日
  • 口径一致率 = 抽查渠道、官网、清单三处岗位名和薪资带宽一致的比例，目标 100%
  • 简历匹配率 = 进入约面档的简历 / 收到简历，按岗位每 2 周统计，作为迭代依据
  • 下架及时率 = 决定后 1 个工作日内全渠道下架的比例，目标 ≥ 95%

8. 低效诊断

  • 现象：JD 由谁写反复推诿，需多次催“JD 整完了吗”｜依据：「鼎慧产研决策部」2026-01、「技术岗招聘沟通」2026-01
  • 现象：同一 JD 在两个招聘账号挂出，薪资口径不同｜依据：「技术岗招聘沟通」2026-03
  • 现象：岗位名或定位写错，社招和校招实习混在同一 JD，引来候选人投诉｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-05
  • 现象：同一岗位有多版 JD，或面试时发现没有 JD、找不到招聘要求｜依据：「技术部」2026-06、「技术部」2026-08、「技术部」2026-09
  • 现象：JD 画像不清，引来大量海投和错配简历，事后才拆分或重写｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-03
  • 现象：岗位名称来回改，预算由谁定没人说得清｜依据：「系统测试招聘」2026-04、「系统测试招聘」2026-05
  • 现象：职能岗 JD 要求和薪资不匹配，多轮改稿后取消招聘｜依据：「综合&总经招聘考核沟通」2026-07
  • 现象：JD 在教育侧和 AI 侧之间来回改，岗位名多次调整｜依据：「墨跃启智招聘」2026-01、「鼎慧人事」2026-03

9. 分支变体

  • 技术岗：用人团队起草后交 CTO 评审，再交人事挂网
  • 非技术岗（行政主管、总经办助理、COO 助理、运营）：由综合部或人事起草，@领导确认定薪区间
  • 财务类岗位：由财务负责人起草，管理层确认
  • 交付工程师/全干工程师：JD 写明交付占比、成长路径，并说明面试含“模拟客户需求沟通”；筛选时单独确认候选人是否愿意做交付
  • 跃竞岗位：按跃竞业务口径写（电竞行业 SaaS，岗位名不带“游戏”）；UI 岗由 UI 面试官把关
  • 网关运维和网关开发分成两个 JD，命名上区分“偏运维/偏开发”
  • 正职和实习分开挂；测试岗按初级、高级、实习拆分
  • 招聘效果差时出简版或“青春版”试投，再配合 AI 筛选

10. 待确认问题

  • 技术岗 JD 的终审人是否为 CTO？薪资带宽由用人部门提出还是 CTO/CEO 定？
  • 岗位库以多维表格为唯一信息源，wiki 清单和官网都从中同步，是否可行？
  • 官网招聘页和招聘站由谁负责同步？2 个工作日的时限能否做到？
  • 对外 JD 是否公开薪资区间？口径以哪份为准？
  • 是否要求用人部门在需求获批后 2 个工作日内交 JD 初稿？
X-RCT-03招聘账号与签约主体管理待新建96

状态：待新建｜证据：有证据（卡片 2 张 / 会话 2 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：模态、鼎慧、跃竞（协游）、子公司共用 BOSS、牛客等招聘账号时，用来决定岗位挂哪个账号、谁有权限、充值归谁、录用后与哪个主体签约，以及对候选人怎么说
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（账号注册与充值预算，当前：丁震宇·推断待确认）、跃竞负责人（当前：徐莉·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、法务（当前：待指定）、招聘专员（当前：张欣怡、陈雁·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 需求获批时确定用工/签约主体 → ② 按账号台账选定挂岗账号 → ③ JD 和沟通话术写明签约主体 → ④ 沟通、面试、Offer 全程用签约主体口径 → ⑤ 充值、VIP、道具走审批，按月汇总费用 → ⑥ 每季度复核账号和权限
  • 交付结果：招聘账号与权限登记表；岗位-账号-签约主体对照；对外话术卡；月度渠道费用汇总
  • 状态依据：没有成文规则，主体、账号、充值和对外话术都靠群里口头约定。已有候选人从模态号投递、最后入职跃竞，又被认出之前在模态被拒过；也曾因没有子主体账号导致招聘停顿

1. 场景判定

  • 触发条件：新岗位挂网，签约主体不是模态本部；子主体想开独立账号；账号要充值、开 VIP、买道具；招聘人员入职或离职需要开关权限；候选人询问“到底是哪家公司”
  • 典型说法：「这个岗位不能用模态的号挂吗」「还是倾向挂在模态招，模态名气大一点，只不过入职的是子公司」「给跃竞招人就按跃竞沟通就好」「新号还是模态认证」
  • 判断问题：这个岗位录用后和谁签合同？候选人看到的公司名称与签约主体一致吗？
  • 不归本流程管：劳动合同签署主体的最终判定与签约 → 请走 HR-04；渠道投放策略和效果 → 请走 X-RCT-04；JD 内容 → 请走 X-RCT-02；跨主体候选人归属分配 → 请走 X-RCT-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事负责人 维护账号台账、分配权限、定岗位挂哪个号、维护话术卡 R 人事负责人（当前：黄莹·推断待确认）
CTO 审批新开账号、充值和付费道具预算 A CTO（当前：丁震宇·推断待确认）
子主体负责人 确认子主体岗位的签约主体，决定自招还是代招 R（子主体岗位） 跃竞负责人（当前：徐莉·推断待确认）
财务负责人 执行充值付款，按月归集渠道费用到主体 R（付款） 财务负责人（当前：黄梦婷·推断待确认）
法务 审核对外话术和主体披露 C 法务（当前：待指定）
招聘专员 按话术沟通，按权限使用账号 R（执行） 招聘专员（当前：张欣怡、陈雁·推断待确认）

3. 办之前请准备

  • 岗位的签约主体全称、对外简称、所属业务
  • 现有账号清单：平台、认证主体、VIP 席位、管理员、使用人
  • 该主体本月渠道费用和余额
  • 子主体是否由合资方主导招聘（需要提前沟通）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 岗位需求获批时在台账写明签约主体 人事负责人 需求获批当天 HC 台账 主体字段 🔧飞书固化
2 按规则选挂岗账号：默认用模态认证账号；子主体有独立账号的优先用独立账号 人事负责人 挂岗前 账号登记表 岗位-账号对照 👤人工判断
3 JD 首段和首次沟通话术写明签约主体全称 招聘专员 挂岗时 话术卡 合规 JD / 话术 🔧飞书固化
4 候选人跨主体查重：查同一人是否在其他主体面试过，有记录的提前告知面试官 招聘专员 约面前 候选人台账 查重结论 🤖自动化
5 充值、VIP、道具：提交申请（主体、平台、金额、用途岗位） 人事负责人 需要时，提前 2 个工作日 飞书审批 审批单 🔧飞书固化
6 审批后付款并按主体记账 财务负责人 审批后 2 个工作日内 飞书付款审批 付款凭证 🔧飞书固化
7 汇总各账号消耗、席位和效果 人事负责人 每月 5 日前 多维表格 月度渠道费用表 🔧+🤖
8 复核账号权限：离职或转岗人员当天收回 人事负责人 每季度 1 次；人员变动当天 账号登记表 权限复核记录 👤人工判断

5. 交付物与模板

  • 交付物：招聘账号与权限登记表、对外话术卡、月度渠道费用表、权限复核记录
  • 建议模板/表单：
    • 账号登记表字段：平台、账号名、认证主体、VIP/席位、管理员、使用人、开通日期、可挂岗位类型、充值余额、到期日
    • 话术卡字段：签约主体全称、对外简称、与集团关系的标准说法、业务一句话介绍、常见问答（社保缴纳主体、办公地点、品牌关系）
    • 充值申请字段：主体、平台、金额、用途岗位、预期简历量、费用归属

6. 异常与升级

  • 候选人投诉主体不一致或感觉被误导 → 招聘专员按话术卡解释，并在台账备注 → 人事负责人当天跟进
  • 子主体缺账号导致岗位挂不出去 → 临时用模态号代挂，并在 JD 写明签约主体 → CTO 2 个工作日内决定是否开独立号
  • 合资方主导的子公司要招人 → 由子主体负责人先与合资方对齐 → 有分歧时升级 CEO
  • 充值费用超出当月预算 → 暂停投放 → CTO 审批追加

7. 衡量指标

  • 主体披露合规率 = JD 和首次沟通写明签约主体的岗位占比，目标 100%
  • 账号权限准确率 = 季度复核时权限与在职名单一致的比例，目标 100%
  • 渠道费用归集率 = 按主体归集的渠道费用占比，目标 100%
  • 主体口径投诉 = 候选人对主体口径的投诉次数，目标 0 次/季度

8. 低效诊断

  • 现象：候选人从模态号投递，最后入职子主体，且被认出之前在另一主体被拒过｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-07
  • 现象：同一账号挂的职位太多，入职主体和账号主体不一致｜依据：「跃竞招聘群」2026-01
  • 现象：对外公司名称说法不统一｜依据：「跃竞招聘群」2026-01
  • 现象：子主体没有招聘账号，招聘一度停顿；子公司招聘由合资方主导，沟通成本高｜依据：「模态人事大主管」2026-01
  • 现象：充值和消耗没有台账，需要反复追问花了多少｜依据：「模态人事大主管」2026-02

9. 分支变体

  • 模态号代挂、子主体签约：研发、UI、产品岗可用模态认证账号挂岗，借助品牌影响力，但 JD 与沟通须写明签约主体
  • 子主体独立账号：费用归子主体，由子主体人员自筛
  • 合资方主导的子公司：招聘以合资方为主，集团只做支持
  • 市场类岗位：由相关主体自行招聘，不占用集团账号
  • 鼎慧：可单独开号，由专人每天打包简历

10. 待确认问题

  • 默认挂岗账号规则（模态号代挂 vs 子主体独立号）是否认可？
  • 渠道充值费用由哪个主体承担？是否按岗位主体分摊？
  • 对外话术卡是否需要法务审核？法务由谁对接？
  • 账号管理员是否统一由人事负责人担任？CTO 是否仍保留注册和充值审批权？
X-RCT-04招聘渠道拓展与招聘物料运营待优化108

状态：待优化｜证据：有证据（卡片 6 张 / 会话 4 个）｜优先级：频3 × 耗3 × 跨4 × 险3

  • 适用场景：被动投递的量或质量不够，需要新增或调整招聘渠道（小红书、知乎、脉脉、牛客、开源社区、技术社群、官网招聘页等）、投放付费道具，或制作招聘海报、易拉宝、电梯海报、活动物料时
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（渠道付费预算和技术社区资源，当前：丁震宇·推断待确认）、技术招聘协调人（技术向文案与精准搜索，当前：陈晖·推断待确认）、运营（官网招聘页与宣发，当前：鲁周毅·推断待确认）、生态组负责人（活动现场物料，当前：陈梦琪·推断待确认）、CEO（活动资源，当前：邴龙志·推断待确认）、设计师（当前：待指定）、行政（物料张贴，当前：待指定）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 月度渠道复盘，找出缺口 → ② 提渠道/投放方案 → ③ 预算审批 → ④ AI 出文案或物料初稿，设计复核 → ⑤ 对外口径审核 → ⑥ 发布、投放、张贴，统一投递入口 → ⑦ 登记渠道效果 → ⑧ 月度复盘 ROI 并调整
  • 交付结果：渠道清单与月度渠道效果表；审核通过的招聘文案和物料；统一的简历投递入口
  • 状态依据：BOSS、牛客、脉脉、内推等渠道一直在用，也试过小红书、社群、黑客松，但没有渠道效果统计，文案和物料各自试、多轮返工，发帖方式被外部批评后才调整

1. 场景判定

  • 触发条件：某岗位连续 2 周有效简历不足；急岗需要补量；有线下活动或黑客松可以引才；官网或招聘站上线、改版；需要内部或楼宇招聘海报
  • 典型说法：「换池子」「得尝试小红书捕捞了」「充的钱就是用来花的」「直接到处贴」「宣发后有大量的人投递过来，是不是要给个网站做收口」
  • 判断问题：问题出在“简历量或质量不够”吗？如果是 JD 写得不准，先走 X-RCT-02
  • 不归本流程管：点对点主动寻访和批量邮件外联 → 请走 X-RCT-05；内推 → 请走 X-RCT-06；账号权限和充值归属 → 请走 X-RCT-03；品牌通用物料制作 → 请走 BRD-13；官网整体改版 → 请走 BRD-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事负责人 维护渠道清单、提投放方案、登记效果、月度复盘 R 人事负责人（当前：黄莹·推断待确认）
CTO 批准付费渠道预算，提供技术社区资源 A CTO（当前：丁震宇·推断待确认）
技术招聘协调人 写技术向文案，在知乎、脉脉等平台精准搜索 R（技术岗） 技术招聘协调人（当前：陈晖·推断待确认）
运营 官网招聘页、公众号/小红书发布，统一投递入口 R（发布） 运营（当前：鲁周毅·推断待确认）
设计师 海报、易拉宝的设计复核和定稿 R（物料） 设计师（当前：待指定）
招聘专员 在招聘平台发布、投放 R（执行） 招聘专员（当前：张欣怡·推断待确认）
生态组负责人 整理活动现场物料和岗位信息 R（活动） 生态组负责人（当前：陈梦琪·推断待确认）
CEO 提供黑客松等活动资源 C CEO（当前：邴龙志·推断待确认）
行政 张贴物料，协调场地 R（张贴） 行政专员（当前：待指定）

3. 办之前请准备

  • 目标岗位、本月缺口、现有渠道近 2 周的简历量和有效率
  • 投放方案：渠道、岗位、预算、预期简历数、起止日期
  • 统一投递入口（表单/邮箱/招聘站）和简历归集位置
  • 文案要点：公司一句话介绍、岗位亮点、投递方式；不写未经确认的待遇承诺
  • 物料规格：易拉宝、A3 电梯版、传单的尺寸和张贴点位

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按岗位统计渠道效果，找出量或质量不足的岗位 人事负责人 每月 5 日前 渠道效果表（多维表格） 渠道缺口清单 🔧+🤖
2 提渠道或投放方案（新渠道、道具、社群付费发帖） 人事负责人 / 技术招聘协调人 发现缺口后 2 个工作日内 飞书文档 投放方案 👤人工判断
3 付费项目审批 CTO 提交后 1 个工作日内 飞书审批 审批结论 🔧飞书固化
4 AI 生成文案或物料初稿，设计复核、统一品牌视觉 技术招聘协调人 / 设计师 审批后 3 个工作日内 AI 工具 + Figma 文案/物料终稿 🤖自动化
5 审核对外口径：公司名、岗位、待遇说法、平台规则 人事负责人 收稿后 1 个工作日内 审核清单 审核通过稿 👤人工判断
6 发布、投放或张贴，投递入口统一指向简历归集位置 运营 / 招聘专员 / 行政 审核通过后 2 个工作日内 各平台 + 表单 发布记录 🔧飞书固化
7 登记每条渠道的曝光、简历数、有效数、成本 人事负责人 每周五 渠道效果表 周数据 🤖自动化
8 月度复盘：停掉低效渠道，加投高效渠道 人事负责人，CTO 参会 每月 1 次 飞书会议 调整决定 👤人工判断

5. 交付物与模板

  • 交付物：渠道清单、投放方案、文案和物料终稿、发布记录、渠道效果表
  • 建议模板/表单：
    • 渠道效果表字段：渠道、岗位、上线日期、费用、曝光、简历数、进入约面数、录用数、单份有效简历成本、负责人
    • 招聘文案审核清单：公司全称与签约主体、岗位名与 JD 一致、待遇说法已确认、无夸大或冒犯性表述、符合平台规则（防限流/封号）、投递入口有效
    • 物料模板：易拉宝和 A3 电梯版统一版式（岗位速览 + 二维码 + 一句话定位）

6. 异常与升级

  • 帖子被外部批评或引发舆情 → 当天下线或修改，统一回应口径 → 升级 CTO 和品牌负责人（当天）
  • 平台限流、封号 → 暂停该账号发帖，按平台规则整改 → 人事负责人 1 个工作日内评估
  • 付费渠道 1 个月内无有效简历 → 停止续费 → 月度复盘时记录
  • 投递入口失效（链接错、邮箱不收件） → 当天修复 → 运营负责

7. 衡量指标

  • 有效简历数 = 按渠道、按岗位每周进入约面档的简历数
  • 单份有效简历成本 = 渠道费用 / 有效简历数，按月统计
  • 渠道效果登记率 = 有效果记录的渠道 / 在用渠道，目标 100%
  • 物料出稿周期 = 审批到终稿的工作日数，目标 ≤ 3 个工作日

8. 低效诊断

  • 现象：主渠道简历质量低、方向不符的占比高，渠道效果没有统计｜依据：「技术岗招聘沟通」2026-05、「技术岗招聘沟通」2026-06
  • 现象：渠道和文案各自试，对公司号和个人号、发帖尺度意见不一，被网友批评后才调整｜依据：「技术岗招聘沟通」2026-03
  • 现象：简历回收入口不清，“哪个邮箱收简历”要反复问｜依据：「技术岗招聘沟通」2026-03
  • 现象：付费道具被要求“多投点”，但没有评估｜依据：「技术岗招聘沟通」2026-04、「技术岗招聘沟通」2026-05
  • 现象：招聘海报由技术人员用 AI 反复迭代，没走设计流程，终稿通过群文件传递｜依据：「技术岗招聘沟通」2026-03
  • 现象：寻访和投放进度集中在个人邮箱或微信，转化层层延迟｜依据：「技术部」2026-08、「技术部」2026-09

9. 分支变体

  • 被动渠道（BOSS、牛客、脉脉）：量大质低，靠道具补量，需要精准搜索
  • 内容渠道（小红书、知乎、技术社群）：先起号，个人号发非硬广帖须经审核
  • 付费社群发帖：与群主约定内容和费用，走付费审批
  • 活动引才（黑客松、AI 活动）：设企业命题赛道或面试直通车，现场只收简历和项目，技术初筛后再约面
  • 线下物料：易拉宝用于展位，A3 电梯版用于楼宇；由设计出稿、行政张贴
  • 官网招聘页或独立投递站：可先快速搭一版，再并入官网，投递直接写入简历库

10. 待确认问题

  • 渠道运营归人事，还是另设招聘运营或由运营部承担？
  • 付费渠道审批人是否为 CTO？单次和月度额度各多少需要审批？
  • 招聘物料是否必须走品牌设计？由谁指定设计师？
  • 个人账号发招聘帖是否需要人事审核？
  • 线下活动是否允许现场面试，还是只收简历？
X-RCT-05主动寻访与开源人才外联待新建192

状态：待新建｜证据：有证据（卡片 5 张 / 会话 3 个）｜优先级：频3 × 耗4 × 跨4 × 险4

  • 适用场景：发现优秀开源作者、技术博主或行业专家，或急岗需要主动寻访，决定建联、批量邮件外联、跟进回信，并转入招聘或顾问合作时
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——CTO（批量外联审批、技术建联，当前：丁震宇·推断待确认）、技术招聘协调人（识别人才、评估，当前：陈晖·推断待确认）、外联执行人（当前：李凯·推断待确认）、文案审核（当前：郭逸非·推断待确认）、用人部门负责人（当前：王皓南、李子遥等·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记线索 → ② 匹配岗位并判断优先级 → ③ 批量外联先审核（名单、模板、退订、发送量）→ ④ 小批量试发后分批发送 → ⑤ 24 小时内分类回复 → ⑥ 有意向的转入候选人台账 → ⑦ 顾问/外包合作分流 → ⑧ 每轮活动复盘
  • 交付结果：寻访线索表（来源、状态、负责人、下一步）；经审核的外联模板；每轮外联复盘（发送量、回复率、简历数、投诉数）
  • 状态依据：主动寻访全靠个人发起，没有线索登记、发送前审核和统一口径。批量邮件发出后，开源圈多人询问是否为垃圾邮件；回信、加微信、要简历都在个人邮箱和微信里，由管理层手写回复

1. 场景判定

  • 触发条件：在 GitHub、X、技术社区、活动中发现合适人才；急岗靠被动投递迟迟招不到；准备按画像批量外联开发者；需要引入外部专家做顾问或外包
  • 典型说法：「试试去挖一下人」「问问他来不来」「开始海投」「已经六十多回信了」「急需一个运营大手子，速速内推」
  • 判断问题：候选人是我们主动找的，而不是他投递或员工推荐的吗？
  • 不归本流程管：员工推荐熟人 → 请走 X-RCT-06；平台渠道投放和发帖 → 请走 X-RCT-04；建联后的简历筛选 → 请走 X-RCT-07；顾问/外包合同与付款 → 请走 FIN-14；高管寻访 → 请走 X-RCT-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
发现人 登记线索（来源、主页、推荐理由） R（登记） 全体员工
人事负责人 维护线索表、跟踪回信时限、转入台账、组织复盘 R 人事负责人（当前：黄莹·推断待确认）
CTO 批准批量外联方案，亲自与高价值候选人建联 A CTO（当前：丁震宇·推断待确认）
技术招聘协调人 识别人才，判断技术匹配度，写技术向话术 R（评估） 技术招聘协调人（当前：陈晖·推断待确认）
外联执行人 私信或社交平台首次接触，拿到联系方式 R（外联） 外联执行人（当前：李凯·推断待确认）
文案审核 审核外联模板措辞和对外形象 C 文案审核（当前：郭逸非·推断待确认）
用人部门负责人 判断候选人适合哪个组 C 用人部门负责人（当前：王皓南、李子遥等·推断待确认）
品牌负责人 处理外联引发的舆情 I 品牌负责人（当前：待指定）

3. 办之前请准备

  • 目标岗位和画像（引用岗位库 JD）
  • 线索来源与公开主页链接，只记录对方公开的职业信息
  • 外联模板：自我介绍、为什么找对方、岗位链接、退订或拒绝方式
  • 批量外联方案：名单规模、筛选规则、发送账号、分批计划
  • 回信分类规则和负责人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记线索：来源、主页、推荐理由、目标岗位、发现人 发现人 发现后 1 个工作日内 寻访线索表（多维表格） 线索记录 🔧飞书固化
2 判断匹配度和优先级，指定外联负责人 技术招聘协调人 登记后 2 个工作日内 线索表 匹配结论 👤人工判断
3 批量外联先审核名单范围、模板措辞、退订方式、发送量 文案审核 → CTO 批准 发送前 1 个工作日 审核清单 批准的外联方案 👤人工判断
4 先小批量试发（约 5%），看回复和负面反馈，再分批发送 外联执行人 / 自动化工具 试发后观察 1～2 天 邮件 Agent 发送记录 🤖自动化
5 回信按“感兴趣/婉拒/顾问合作/投诉”分类，24 小时内回复 外联执行人，AI 起草回信 收到后 24 小时内 邮件 + 线索表 回复记录 🔧+🤖
6 有意向的索要简历或主页，转入候选人台账走筛选 人事负责人 意向确认后 1 个工作日内 候选人台账 台账记录 🔧飞书固化
7 只愿意做顾问或外包的，转用人部门评估并走合作流程 用人部门负责人 3 个工作日内 线索表 合作意向 👤人工判断
8 每轮结束后复盘：发送量、回复率、简历数、面试数、投诉数 人事负责人 每轮结束后 5 个工作日内 线索表统计 复盘记录 🤖自动化

5. 交付物与模板

  • 交付物：寻访线索表、外联方案与审核记录、外联模板库、每轮复盘
  • 建议模板/表单：
    • 寻访线索表字段：线索编号、来源平台、公开主页、目标岗位、发现人、外联负责人、首次联系日期、回复类型、下一步、状态、是否转入台账
    • 外联审核清单：名单只用公开职业信息；不发到对方现任公司邮箱；称呼和措辞礼貌、不涉隐私（不写“看了你最近的提交”之类）；链接可用；带退订或拒绝方式；同一人 30 天内不重复发送

6. 异常与升级

  • 收到投诉或外部质疑“是不是垃圾邮件” → 暂停后续批次，统一回应口径 → 升级 CTO 和品牌负责人（当天）
  • 回信超过 24 小时未回复 → 线索表标红并自动提醒 → 人事负责人当天分派
  • 对方明确拒绝或要求不再联系 → 标记“勿扰”，永久剔出名单 → 外联执行人当天处理
  • 外联涉及抓取非公开个人信息 → 立即停止 → 升级法务和 CTO

7. 衡量指标

  • 回信响应时效 = 24 小时内回复的回信占比，目标 ≥ 90%
  • 外联转化率 = 进入面试人数 / 外联人数，按每轮统计
  • 投诉率 = 投诉或负面反馈数 / 发送数，目标 ≤ 0.5%
  • 线索登记率 = 登记在线索表的寻访对象占比，目标 100%

8. 低效诊断

  • 现象：批量外联模板反复修订（排版、语气、错链）约 6 次，发出后开源圈多人询问是否为垃圾邮件｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 现象：回信、微信、简历都在个人邮箱和微信里，没有统一池子，靠管理层逐封手写回复｜依据：「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 现象：外联主责不清，靠在群里点名“去抓人”，联系方式靠个人关系｜依据：「模态AI探索小分队」2026-01、「模态AI探索小分队」2026-03
  • 现象：引荐的人才没有登记，“问问他来不来”之后没有跟进记录｜依据：「模态AI探索小分队」2026-05、「模态AI探索小分队」2026-06
  • 现象：外部专家由谁联系不清，背景核实靠熟人｜依据：「鼎慧产研决策部」2026-04
  • 现象：寻访奖励靠口头承诺｜依据：「跃迁AI总动员」2026-08

9. 分支变体

  • Agent 批量外联：按 GitHub 贡献画像筛选，自动生成个性化邮件，必须先过审核清单并小批量试发
  • 人工点对点：在 X、B 站、技术社区私信，拿到联系方式后再由 CTO 或技术负责人出面
  • 同事在社区或活动中遇到人才：按本流程登记；如果是员工熟人并申请内推奖励，转 X-RCT-06
  • 外部专家：以顾问或外包形式合作，走合作和付款流程
  • 活动引才：在黑客松设企业命题赛道和面试直通车
  • 第三方人才报告（如脉脉）：仅作参考

10. 待确认问题

  • 主动寻访的主责是人事，还是需要设专门的技术招聘专员？
  • 批量外联是否必须由 CTO 批准？单批发送上限设多少？
  • 外联邮件用个人邮箱还是公司统一招聘邮箱？
  • 主动寻访来的候选人入职后，发现人是否享受内推奖励？
  • 采集公开联系方式群发邮件的合规边界，是否需要法务出具意见？
X-RCT-06员工内推受理与内推奖励待优化96

状态：待优化｜证据：有证据（卡片 18 张 / 会话 17 个）｜优先级：频4 × 耗2 × 跨4 × 险3

  • 适用场景：员工推荐熟人、同学或开源圈朋友应聘公司在招岗位时，从登记、初筛、面试、回复推荐人，一直到按节点认定和发放内推奖励
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——用人部门负责人/面试官（当前：李子遥、郭逸非、王子明、吴亚军等·推断待确认）、CTO（技术岗内推初判，当前：丁震宇·推断待确认）、CEO（制度与特殊情形认定，当前：邴龙志·推断待确认）、财务负责人（奖励随工资发放，当前：黄梦婷·推断待确认）、运营（招聘推文扩散积分，当前：鲁周毅·推断待确认）、招聘专员（当前：王丽菲、张欣怡·推断待确认）；兜底——综合部负责人（当前：赵雪冰·推断待确认）
  • 核心流程：① 推荐人查《在招岗位清单》→ ② 填内推表单 → ③ 人事登记、查重、分发 → ④ 用人方 2 个工作日内初筛 → ⑤ 7 个工作日内优先面试 → ⑥ 结果回复推荐人 → ⑦ 按节点认定奖励 → ⑧ 公示和异议期 → ⑨ 随工资发放
  • 交付结果：内推台账（推荐人、候选人、岗位、状态、奖励节点）；给推荐人的结果回复；奖励公示和发放清单
  • 状态依据：《内推管理制度（跃迁伯乐计划）V1.0》已于 2026-08-01 施行，在招岗位清单和内推表单也已齐备。但简历仍常被直接丢进群里或私发，同一份简历被多人重复转发，推荐人追问进展，联系方式缺失要补，执行还不稳定

1. 场景判定

  • 触发条件：员工（含实习生）推荐候选人；外部朋友托员工转简历；员工询问内推规则或在招岗位；内推候选人入职满 1 个月、转正，或实习满 3 个月，到了奖励节点
  • 典型说法：「内推成功有内推费吗」「简历发我就行，我来安排」「这是别人内推的」「要是通过了内推奖金发一下」「推荐人需通过指定内推表单」
  • 判断问题：推荐人是公司在职员工吗？推荐的岗位在《在招岗位清单》上吗？
  • 不归本流程管：公司主动找来的人才 → 请走 X-RCT-05；简历的通用筛选 → 请走 X-RCT-07；奖励金额计入工资和个税 → 请走 HR-15；伯乐积分兑换 → 请走 HR-18；外部公司整批推荐人员 → 先走 X-RCT-01 判断是否有需求

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
推荐人 查岗位，填表单，提供候选人有效联系方式，说明与候选人的关系 R 全体员工
人事负责人 登记、查重、分发、跟踪时限、回复推荐人、认定奖励、公示 R 人事负责人（当前：黄莹·推断待确认）
招聘专员 联系候选人、约面，补全缺失信息 R（执行） 招聘专员（当前：王丽菲、张欣怡·推断待确认）
用人部门负责人/面试官 2 个工作日内给初筛结论，安排面试 R 用人部门负责人（当前：李子遥、郭逸非、王子明、吴亚军等·推断待确认）
CTO 技术岗内推的快速判断和岗位调剂 C CTO（当前：丁震宇·推断待确认）
CEO 制度修订、特殊情形认定、亲友推荐把关 A CEO（当前：邴龙志·推断待确认）
财务负责人 按发放清单随工资发放，代扣个税 R（发放） 财务负责人（当前：黄梦婷·推断待确认）
运营 管理招聘推文扩散的积分奖励 R（积分） 运营（当前：鲁周毅·推断待确认）

3. 办之前请准备

  • 先查《在招岗位清单》，确认岗位开放、不属于关联公司岗位
  • 候选人简历和有效联系方式（不能隐藏），以及 GitHub 或作品链接
  • 推荐人与候选人的关系（同学、前同事、亲友），推荐理由
  • 亲友或关系推荐：先与用人部门负责人沟通

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 填内推表单（不在群里或私聊直接丢简历） 推荐人 推荐当天 飞书内推表单 表单记录 🔧飞书固化
2 登记、查重（是否已在台账、其他主体是否面过），信息缺失时退回补全 人事负责人 提交后 1 个工作日内 内推台账（多维表格） 登记结果 🔧+🤖
3 按岗位分发给用人部门；没有匹配岗位的，询问兄弟团队要不要 人事负责人 登记当天 机器人通知 分发记录 🔧+🤖
4 初筛给结论：约面 / 不合适 / 转其他岗位 用人部门负责人 收到后 2 个工作日内 内推台账 初筛结论 👤人工判断
5 安排面试，与社招同标准，可优先排期 招聘专员、面试官 初筛通过后 7 个工作日内 飞书日程 面试记录 🔧飞书固化
6 把各节点结果回复推荐人，不透露面评细节 人事负责人 每个节点出结果后 1 个工作日内 机器人通知 推荐人回复 🤖自动化
7 到节点（入职满 1 个月、转正；实习满 3 个月；转正补差）时认定奖励档位 人事负责人 节点到达后 5 个工作日内 内推台账自动提醒 认定清单 🔧+🤖
8 公示认定结果，设异议期 人事负责人 公示 5 个自然日 飞书公告 公示记录 🔧飞书固化
9 异议期满后，随当月工资税前发放 财务负责人 当月工资发放日 薪酬流程 发放凭证 🔧飞书固化

5. 交付物与模板

  • 交付物：内推表单记录、内推台账、推荐人回复、奖励认定清单、公示记录、发放凭证
  • 建议模板/表单：
    • 内推表单字段：推荐人、推荐人部门、候选人姓名、联系方式（必填）、目标岗位（从清单选）、关系、推荐理由、简历附件、作品链接
    • 内推台账字段：编号、推荐人、候选人、岗位、主体、登记日、初筛人、初筛结论及日期、面试日期、结果、入职日、奖励节点 1/2 日期、岗位层级（S/A/B/C）、公示日、发放月、状态

6. 异常与升级

  • 简历直接发在群里或私聊 → 收到人回复表单链接，人事代为登记并备注 → 人事负责人当天处理
  • 联系方式缺失或隐藏 → 退回推荐人 1 个工作日内补全 → 逾期标“暂停”
  • 用人方超过 2 个工作日未初筛 → 台账自动提醒 → 第 3 个工作日升级用人部门负责人的上级
  • 亲友或关系推荐 → 必须走完整面试，由用人部门负责人和上级共同点头 → 存疑时升级 CEO
  • 推荐人或被推荐人在节点前离职，或对认定有异议 → 按制度处理；异议期内提出的由人事复核 → 特殊情形升级 CEO（5 个工作日内）
  • 外部非员工推荐人申请奖励 → 按制度不适用的直接答复；确需支付的由财务确定合规方式，不经新员工代转 → 升级 CEO
  • 背景经核实与简历不符 → 终止流程，回复推荐人 → 记入台账

7. 衡量指标

  • 表单登记率 = 走内推表单的内推数 / 内推总数，目标 100%
  • 初筛及时率 = 2 个工作日内给结论的占比，目标 ≥ 90%
  • 面试及时率 = 初筛通过后 7 个工作日内面试的占比，目标 ≥ 90%
  • 推荐人回复率 = 每个节点都已回复推荐人的占比，目标 100%
  • 奖励发放准时率 = 按节点在当月发放的占比，目标 100%
  • 内推入职占比 = 内推入职人数 / 总入职人数，按季度统计

8. 低效诊断

  • 现象：简历直接丢群或私聊，同一份简历被多人重复转发，事后记不清是谁推的｜依据：「跃竞招聘群」2026-03、「跃竞招聘群」2026-08、「技术岗招聘沟通」2026-03
  • 现象：员工不知道内推规则和在招岗位，要在群里问｜依据：「跃迁AI总动员」2026-09
  • 现象：制度出台前，奖励口径、发放时间、适用范围（是否只限研发）都是口头说法，过往内推到 8 月才补公示｜依据：「技术岗招聘沟通」2026-03、「【模态】综合部」2026-05、「模态人事大主管」2026-07
  • 现象：推荐人追问进展，反馈时限要靠人事提醒｜依据：「技术岗招聘沟通」2026-08、「技术岗招聘沟通」2026-09
  • 现象：内推简历联系方式被隐藏，需要补发｜依据：「开放平台招聘」2026-10
  • 现象：内推候选人背景靠熟人核实，出现过经历不实｜依据：「技术岗招聘沟通」2026-05
  • 现象：招聘提醒机器人误催办发起人自己｜依据：「跃迁AI总动员」2026-09
  • 现象：官网岗位靠手动同步，删减岗位前没核实｜依据：「模态跃迁 官网研发」2026-09

9. 分支变体

  • 全职内推：入职满 1 个月和转正两个节点发放
  • 实习生内推：连续实习满 3 个月发放；之后转正的补差
  • 开源社区实习生：按商业价值、影响力、社会责任、培养四类综合评估，可先笔试
  • 亲友或关系推荐：上级同意，走完整面试，不降低标准
  • 关联公司岗位（跃竞、招投标子公司等）：不适用本制度，由该主体自定
  • 人事招聘团队成员推荐：不享受现金奖励
  • 招聘推文扩散：由运营按群聊数发放公司积分，与现金奖励分开

10. 待确认问题

  • 制度规定的“2 个工作日初筛、7 个工作日面试”是否已对所有用人部门宣贯？超时由谁追责？
  • 私聊或群里收到的内推简历，是否一律要求推荐人补填表单才计奖励？
  • 外部非员工推荐的奖励是否支付？用什么方式支付？
  • 岗位层级（S/A/B/C）的确认流程，是否需要每个岗位挂网时就定好？
  • 内推台账是否与候选人台账（X-RCT-16）合并？
X-RCT-07简历收集、初筛与分发待优化180

状态：待优化｜证据：有证据（卡片 28 张 / 会话 19 个）｜优先级：频5 × 耗4 × 跨3 × 险3

  • 适用场景：各渠道每个工作日进来新简历时，由人事收集、去重、入库，经 AI 快筛和硬条件过滤后分发给指定筛选人，在约定时限内拿到“约面/待定/淘汰”结论
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡、匡蓉、王丽菲·推断待确认）、岗位筛选人（当前：陈晖、望政韬、王皓南、杨明学、宋祺睿、张东郅、王子明、葛家和等·推断待确认）、CTO（技术岗筛选标准与终筛，当前：丁震宇·推断待确认）、AI 打分工具维护（当前：季学森、魏宗浩·推断待确认）、子主体负责人（当前：徐莉·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 每日从各渠道收简历 → ② 去重、规范命名、入候选人台账 → ③ AI 按岗位筛选清单打分分档 → ④ 人事按硬条件剔除 → ⑤ 推送给岗位筛选人 → ⑥ 筛选人 1 个工作日内标结论 → ⑦ 人事按结论联系候选人 → ⑧ 每周抽检 AI 结果，校准标准
  • 交付结果：每份简历在候选人台账中都有岗位、来源、AI 分档、筛选人结论和日期；每日约面名单；按岗位分版本的筛选清单
  • 状态依据：每日上传简历、颜色或档位标记、AI 快筛已成固定动作。但简历要逐个下载打包，文件名串号、重复投递，标签含义不一，筛选标准只存在于聊天里，简历常滞留在单一筛选人处。人事几乎每天追问，候选人因等待过久接了别家 offer，01～10 月约 300 次相关沟通

1. 场景判定

  • 触发条件：招聘平台、邮箱、官网、招聘站、活动有新简历；用人部门要求“再来一批”；投递量突增需要批量处理
  • 典型说法：「再来一批全栈简历吧」「今天的运维和 Agent 简历上传啦，可以看看」「昨天的简历有可以的吗」「红色的重点看看」「先把只会 Java 的筛掉吧」
  • 判断问题：这份简历是否还没有筛选结论？内推简历走 X-RCT-06 登记后，也进入本流程的台账
  • 不归本流程管：简历真实性核验和 AI 代答识别 → 请走 X-RCT-08；电话预沟通 → 请走 X-RCT-09；笔试 → 请走 X-RCT-10；面试排期 → 请走 X-RCT-11；候选人台账与招聘系统维护 → 请走 X-RCT-16；跨组转推 → 请走 X-RCT-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
招聘专员 每日收简历、下载、命名、去重、入台账，推送筛选人 R 招聘专员（当前：张欣怡、匡蓉、王丽菲·推断待确认）
人事负责人 维护筛选人名单和时限，非技术岗初筛，按结论联系候选人 R 人事负责人（当前：黄莹·推断待确认）
岗位筛选人 按筛选清单 1 个工作日内给结论 R 岗位筛选人（当前：陈晖、望政韬、王皓南、杨明学、宋祺睿、张东郅、王子明、葛家和等·推断待确认）
CTO 确认技术岗筛选清单，裁定争议简历 A（技术岗标准） CTO（当前：丁震宇·推断待确认）
AI 打分工具维护 维护筛选 Prompt 和打分脚本，结果回写台账 R（工具） AI 打分工具维护（当前：季学森、魏宗浩·推断待确认）
子主体负责人 指定子主体岗位的筛选人，确认标准 R（子主体） 跃竞负责人（当前：徐莉·推断待确认）
用人部门负责人 获知每日筛选进度 I 各用人部门负责人

3. 办之前请准备

  • 岗位库中的 JD 和该岗位的筛选清单（硬性淘汰项、加分项、需追问项）
  • 每个岗位指定的筛选人和备份筛选人
  • 候选人台账的访问权限（新筛选人加入当天开通）
  • 统一档位定义：一档=直接约面；二档=先笔试或电话问；三档=淘汰（不再用颜色表达）
  • 文件命名规则：岗位_城市_日期_姓名

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 从 BOSS、牛客、邮箱、官网等收取新简历，按规则命名 招聘专员 每个工作日 11:00 前 招聘平台 + 简历库 当日简历包 🔧+🤖
2 去重（同名、重复投递、其他主体或岗位已面）后入台账，记来源和岗位 招聘专员 当日 12:00 前 候选人台账（多维表格） 台账新行 🤖自动化
3 AI 按岗位筛选清单打分分档，输出理由 AI 打分工具 入台账后 2 小时内 打分脚本，结果回写台账 AI 分档 + 理由 🤖自动化
4 硬条件剔除（学历、用工类型、到岗时间、明显不符的技术栈）；技术内容不由人事判断 人事负责人 当日 台账 剔除标记 🔧+👤
5 机器人推送当日待筛清单给岗位筛选人（只发台账链接，不在群里发简历文件） 招聘专员 当日 14:00 前 飞书机器人 待筛通知 🔧飞书固化
6 筛选人在台账勾选“约面/待定/淘汰”，必要时写一句追问点；多人评分的按岗位规则汇总 岗位筛选人 推送后 1 个工作日内 台账 筛选结论 👤人工判断
7 超时未筛的自动提醒；仍未处理的转备份筛选人 招聘专员 超时后当天 机器人 催办/转派记录 🤖自动化
8 按结论联系候选人，转预沟通、笔试或面试 人事负责人 / 招聘专员 结论后 1 个工作日内 台账 联系记录 🔧飞书固化
9 抽检 AI 淘汰和高分简历，校准筛选清单和 Prompt 岗位筛选人、AI 工具维护 每周 1 次，每岗位抽 10 份 台账 校准记录 👤人工判断

5. 交付物与模板

  • 交付物：每日简历包、候选人台账记录、AI 分档结果、筛选结论、每日约面名单、筛选清单（分岗位版本）、每周校准记录
  • 建议模板/表单：
    • 候选人台账筛选字段：候选人编号、岗位、主体、来源渠道、投递日期、是否重复、AI 分档及理由、硬条件结论、筛选人、筛选结论、筛选日期、追问点、下一步
    • 筛选清单：硬性淘汰项（如只有 Java/Spring 关键词且近两年无 AI 实践、培训班包装项目、技术栈与岗位不符）、加分项（完整项目、架构经历、上线的 AI 工具、开源贡献）、需追问项（经历空档、两版简历不一致）、版本号、维护人
    • 多人评分规则（适用于开启的岗位）：每位筛选人打 1～5 分，总分超过约定阈值进入下一轮，评语 20 字以内

6. 异常与升级

  • 筛选人超过 1 个工作日未给结论 → 机器人提醒并转备份筛选人 → 连续 3 次超时的升级 CTO 或子主体负责人
  • 优质候选人表示已有其他 offer → 标“急”，当天约面 → 人事负责人当天协调筛选人
  • 简历信息前后矛盾或疑似造假 → 标“疑点”，转 X-RCT-08 核验 → 人事负责人
  • 某岗位连续 2 周没有一档简历 → 提示 JD 或渠道调整 → 转 X-RCT-02 / X-RCT-04
  • AI 抽检误杀率超过 10% → 暂停该岗位自动淘汰，改为人工复核 → AI 工具维护 3 个工作日内修正 Prompt
  • 简历文件被转发到无关群聊 → 撤回并提醒 → 人事负责人当天处理

7. 衡量指标

  • 筛选时效 = 推送到给出结论的时长，目标 ≤ 1 个工作日，达成率 ≥ 90%
  • 入库完整率 = 有来源、岗位、结论三字段的简历占比，目标 100%
  • 重复简历检出率 = 入库时识别出的重复简历 / 实际重复简历，目标 ≥ 95%
  • 简历→约面转化率 = 按岗位、按渠道每周统计
  • AI 误杀率 = 抽检中被 AI 淘汰但人工判为可约面的比例，目标 ≤ 10%
  • 人事追问次数 = 每周人事在群里催筛选结果的次数，目标逐月下降

8. 低效诊断

  • 现象：招聘平台上的简历要逐个点“索取/同意”再下载打包，属于体力活｜依据：「技术岗招聘沟通」2026-03
  • 现象：文件名与内文姓名对不上，同名简历、重复投递难以识别，常问“简历在哪”｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-05
  • 现象：颜色标签含义因人而异，事后要解释，甚至自己也忘了｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-03
  • 现象：筛选标准只在聊天里，方向不符和包装简历反复进入面试，人事不确定该不该筛技术简历｜依据：「技术岗招聘沟通」2026-01、「跃竞招聘群」2026-04、「跃竞招聘群」2026-07
  • 现象：简历滞留在单一筛选人处，人事几乎每天追问，候选人因等待接了其他 offer｜依据：「技术岗招聘沟通」2026-07、「技术岗招聘沟通」2026-08
  • 现象：某岗位只有一名筛选人，堆积到“看不动了”｜依据：「系统测试招聘」2026-04
  • 现象：AI 打分后仍要人工再标“通过/不通过”，评委间评分口径不一｜依据：「技术面试拉练小分队」2026-09、「技术面试拉练小分队」2026-10
  • 现象：新加入的筛选人没有权限，看不到历史简历｜依据：「墨跃启智招聘」2026-04、「跃竞招聘群」2026-07
  • 现象：简历截图在群里被围观评论，涉及个人信息｜依据：「开源聚变入驻问题沟通群」2026-03
  • 现象：招聘卡点集中在“进简历”环节，人事带宽不足，渠道简历积压｜依据：「模态人事大主管」2026-09、「Leap产研决策部」2026-09

9. 分支变体

  • 技术岗：人事不判断技术内容，只做去重和硬条件过滤；由技术筛选人先剔除，再二筛
  • 非技术岗（产品、运营、财务等）：人事初筛后推送业务负责人。产品岗可要求作品集；财务岗可请外部顾问做专业面
  • 测试岗：每日上传，实习和正职分开发；高级测试候选人少，可以不笔试直接约面
  • 跃竞岗位：后端、前端由跃竞技术负责人筛，UI 由 UI 面试官筛，产品实习由产品经理筛
  • 教育组、开放平台等：由各组指定筛选人，人事按台账分发
  • 大批量投递（官网、宣发、外联回流）：先进多维表格，AI 打分后再分发；开启多人评分的岗位按总分阈值晋级
  • 邮箱直投的资深候选人：由技术负责人先判断专业匹配，避免人事用通用话术沟通
  • 内推简历 → 先走 X-RCT-06 登记；主动寻访 → 先走 X-RCT-05

10. 待确认问题

  • 技术岗是否明确“人事不筛技术内容，只做去重和硬条件”？
  • 各岗位的筛选人和备份筛选人名单由谁维护？是否与需求单里的面试官一致？
  • 筛选时效 1 个工作日是否可行？超时自动转备份筛选人能否接受？
  • 统一档位（一档/二档/三档）是否取代颜色标签？
  • AI 打分阈值、多人评分规则和抽检比例由谁拍板？token 成本由哪个预算承担？
  • 招聘平台简历收取能否接入官方自动化服务，以规避封号风险？
X-RCT-08简历真实性核验与 AI 代答识别待新建144

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：简历、笔试或面试中出现真实性疑点时启动，包括经历时间线冲突、GitHub/开源贡献对不上、简历含隐藏提示词或有 AI 生成痕迹、疑似代考代答、培训班包装项目、疑似竞对派遣、换身份重复投递。核验完成并给出放行/加验/淘汰结论后才继续推进
  • 负责人：主责——招聘 HR（当前：黄莹·推断待确认）；协同——技术面试官（当前：陈晖、望政韬、吴世豪、王皓南、王子明·推断待确认）、技术初筛人（当前：张楠·推断待确认）、招聘专员（当前：张欣怡·推断待确认）、法务（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 查重并标注疑点 → ② 对照红线快速判断 → ③ HR 核实基础信息 → ④ 技术核验 GitHub/作品 → ⑤ 笔试/面试中定向追问 → ⑥ 出结论（放行/加验/淘汰）→ ⑦ 留痕入台账
  • 交付结果：候选人真实性核验记录（疑点、核验手段、证据、核验人、结论），候选人台账上的“放行/加验/淘汰/拉黑”标签
  • 状态依据：2026-01～10 技术岗招聘、跃竞招聘、技术部三个群反复出现简历造假、GitHub 顶包、AI 代答、隐藏提示词等情况，讨论约 48 次。红线只在聊天里口头给出，HR 初筛时无法执行；出现过已约面后才发现 GitHub 账号不是本人的情况；核验手段分散，没有记录

1. 场景判定

  • 触发条件：
    • 简历：工作/教育经历时间重叠或断档没有解释；技术名词、模型名不存在；关键词堆砌（如整份只有单一语言关键词）；证件照疑似 AI 生成；简历里有白色文字或图片形式的隐藏提示词
    • 开源/作品：GitHub 主页与面试表现不匹配；contributors、commit 作者、绑定邮箱对不上；来源不明的“开源大牛”
    • 笔试/面试：答卷疑似 AI 代答或代考；线上面试开虚化背景、回答无停顿、视线始终盯屏
    • 身份：同一人换昵称/真名重复投递；不留手机号或邮箱；疑似竞对派遣（实习岗尤其要注意）
    • 项目：简历以培训班通用项目（“外卖”“商城”类）为主
  • 典型说法：「GitHub 又不是实名制」「这个简历能不能先做一下背调」「那种带外卖字眼的简历直接扔」「怀疑请人代考了」「简历拿过来一看就是一眼假」
  • 判断问题：这个疑点是“信息真不真”，还是“能力够不够”？只有前者走本流程，后者走笔试或面试评价
  • 不归本流程管：常规简历初筛与打分 → 请走 X-RCT-07；笔试出题、阅卷与定档 → 请走 X-RCT-10；面试评价与晋级 → 请走 X-RCT-12；拟录用人选的正式背景调查（需候选人授权）→ 请走 X-RCT-18；不录用通知与留痕 → 请走 X-RCT-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
招聘 HR 发起核验、电话核实基础信息、汇总结论、台账留痕 A/R 人事负责人（当前：黄莹·推断待确认）
招聘专员 查重复投递、跑 AI 初筛、标注疑点 R 招聘专员（当前：张欣怡·推断待确认）
技术初筛人 按红线快判，维护本组红线 R 用人组技术骨干（当前：张楠、王子明·推断待确认）
技术面试官 核验 GitHub/作品、面试中定向追问、给真实性结论 R 技术面试官（当前：陈晖、望政韬、吴世豪、王皓南·推断待确认）
法务 确定核查信息的隐私边界、造假留痕口径 C 法务（当前：待指定）
兜底决策人 争议结论拍板、竞对派遣判断、红线发布 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
用人部门负责人 知悉核验结论 I 各用人部门负责人

3. 办之前请准备

  • 简历原件（保留 PDF 原文件，便于检查隐藏文字和图片）、投递渠道与投递时间
  • 候选人台账中的历史记录：是否投递过、是否做过笔试、是否曾被淘汰或拉黑
  • 候选人提供的 GitHub、作品、博客链接或截图
  • 简历真实性红线清单（见第 5 节）
  • 笔试答卷与作答过程材料（AI 协作截图、提交时间）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 查台账确认是否重复投递、是否做过笔试或被淘汰；用 AI 初筛扫描隐藏提示词、关键词堆砌、培训班项目、AI 生成痕迹，命中红线的标注疑点 招聘专员 简历下载后 1 个工作日内 多维表格台账 + AI 初筛提示词 疑点标签 🤖自动化
2 对照红线快速判断：命中“直接淘汰”项的直接淘汰；命中“需核验”项的进入步骤 3 技术初筛人 标注后 1 个工作日内 台账 快判结论 👤人工判断
3 HR 电话核实学历（学信网）、在职起止时间、离职原因；面试官要问的非技术疑点提前整理给 HR 一并问 招聘 HR 快判后 2 个工作日内，且在面试前完成 电话、学信网 基础信息核实记录 👤人工判断
4 技术核验：查 GitHub 提交者、commit 时间分布、issue/PR 讨论、gpg 签名、绑定邮箱，与简历项目逐项对照；可用 AI 按统一模板生成“开源经历分析”初稿，人工复核；只看公开的职业信息 技术面试官 收到核验请求后 2 个工作日内 GitHub、AI 分析模板 开源/作品核验结论 🤖+👤
5 仍有疑点的，在笔试或面试中定向追问：现场展示本人 commit 并讲修改原因、讲清项目细节和 git 基本操作、复述笔试答案思路；线上面试要求关闭背景虚化 技术面试官 下一轮笔试/面试中 飞书会议 追问记录 👤人工判断
6 出结论：放行 / 加验（加笔试、改线下）/ 淘汰；疑似竞对派遣的报兜底人决定 技术面试官 核验完成当天 群内 @HR + 台账 核验结论 👤人工判断
7 把疑点、证据截图、结论写入台账“真实性核验”字段；淘汰的转 X-RCT-15 通知；确认造假或顶包的标记“拉黑” 招聘 HR 结论当天 多维表格 核验记录 🔧飞书固化

5. 交付物与模板

  • 交付物：真实性核验记录、台账标签、拉黑名单
  • 建议模板/表单：
    • 红线清单（写入 AI 初筛提示词，由兜底人确认后发布）：直接淘汰——简历含操纵筛选的隐藏提示词、确认造假、AI 生成且无法提供任何可核实作品；需核验——时间线冲突、GitHub 不匹配、培训班项目为主、单一语言关键词堆砌、证件照疑似 AI 生成、无联系方式
    • 核验记录字段：候选人编号、岗位、疑点类型（时间线/学历/开源/AI 生成/隐藏提示词/代答/重复投递/竞对）、核验手段、证据链接、核验人、结论（放行/加验/淘汰/拉黑）、日期
    • 开源经历分析模板：仓库清单、本人提交占比、代表性 PR、提交时间分布、与简历描述的一致性、待追问点

6. 异常与升级

  • 升级条件：面试官对真实性结论意见相反、疑似竞对派遣、红线清单需新增或修改 → 由招聘 HR 升级兜底决策人（CTO）拍板；其余核验结论由招聘 HR 汇总后直接执行
  • 已约面后才发现顶包或造假 → 面试官 20 分钟内礼貌结束，结果由 HR 统一回复 → 当天告知兜底人，台账标记拉黑
  • 候选人拒绝提供作品链接或拒绝解释疑点 → 按未通过核验处理 → HR 1 个工作日内回复并结束流程
  • 需要做正式背调 → 不在本流程私下进行，转 X-RCT-18（需候选人授权）
  • 核查涉及社交账号或非公开信息 → 立即停止 → 2 个工作日内请法务确认边界
  • 疑似竞对派遣 → 暂停推进 → 兜底人 1 个工作日内决定；如仍录用，入职前不提供项目代码，签保密协议（HR-04），按最小权限开账号
  • 面试官对真实性意见相反 → 兜底人 1 个工作日内拍板

7. 衡量指标

  • 疑点前置识别率 = 约面前识别出的造假/顶包人数 ÷ 全部发现的造假/顶包人数，目标 ≥ 90%
  • 约面后才发现造假的次数：每月 ≤ 1 次
  • 核验周期 = 标注疑点到出结论的工作日，目标 ≤ 3 个工作日
  • 核验留痕率 = 台账有核验记录的人数 ÷ 发生核验的人数，目标 100%

8. 低效诊断

  • 现象：红线只在群里口头说，HR 初筛执行不了，培训班项目和单一语言关键词简历反复推给技术（初筛环节）｜依据：「跃竞招聘群」2026-04、「跃竞招聘群」2026-05、「技术岗招聘沟通」2026-06
  • 现象：约面后才发现 GitHub 账号不是本人，因“没敢直接否”只能面完（核验时机环节）｜依据：「技术岗招聘沟通」2026-01
  • 现象：每次靠人工逐个翻 GitHub、博客，没有统一核查清单和模板（技术核验环节）｜依据：「技术岗招聘沟通」2026-01、「技术部」2026-08
  • 现象：核验该由面试官还是 HR 做不明确，来回确认（分工环节）｜依据：「技术岗招聘沟通」2026-01
  • 现象：AI 代答、代考的候选人进入面试，面了很久才确认（笔试→面试衔接环节）｜依据：「技术岗招聘沟通」2026-04、「技术岗招聘沟通」2026-05
  • 现象：是否招实习生的口径前后不一（防竞对 vs 补人手）（规则环节）｜依据：「跃竞招聘群」2026-02、「跃竞招聘群」2026-05
  • 现象：查看候选人社交账号的边界没有规定，存在隐私合规风险（合规环节）｜依据：「技术部」2026-09

9. 分支变体

  • 开源贡献者：重点核验 commit 归属，面试时要求现场展示本人提交，必要时请圈内人确认
  • 应届/实习：学历与毕业时间走学信网核验；实习岗有竞对风险，入职前不提供代码、签保密协议
  • 内推候选人：可免 AI 初筛，但仍需笔试与技术核验
  • 重复投递：查台账，历史淘汰原因仍成立的直接沿用结论
  • 跃竞主体：初筛红线由跃竞后端负责人维护，HR 按其清单执行
  • 拟录用正职：真实性核验通过后，正式背调走 X-RCT-18

10. 待确认问题

  • 主责是否为人事负责人？技术核验是否固定由一面面试官承担？
  • 红线清单的“直接淘汰”项能否由 CTO 一次性确认后写入 AI 初筛提示词？
  • 实习生的竞对风险口径：是否限制数量？是否所有实习生入职前都签保密协议？
  • 查看候选人公开社交账号是否允许？需法务给出边界
  • 简历含隐藏提示词是否一律淘汰？
  • 拉黑名单由谁维护、保留多久、是否跨主体共享？
X-RCT-09候选人预沟通与意向登记待优化90

状态：待优化｜证据：有证据（卡片 3 张 / 会话 2 个）｜优先级：频5 × 耗2 × 跨3 × 险3

  • 适用场景：简历通过用人方二筛或笔试初步合格后、约面前，HR 电话/微信联系候选人确认意向和基本条件，按固定字段写回台账，由用人方决定是否约面
  • 负责人：主责——招聘专员（当前：张欣怡·推断待确认）；协同——招聘助理（当前：匡蓉、陈雁·推断待确认）、用人方/面试官（当前：丁震宇、陈晖、王皓南·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）
  • 核心流程：① 用人方提交待沟通名单与附加问题 → ② HR 按标准问题清单沟通 → ③ 结果录入台账并通知用人方 → ④ 用人方决定约面/淘汰/暂缓 → ⑤ HR 回复候选人并保温 → ⑥ 超时提醒
  • 交付结果：每位候选人一条字段完整的预沟通记录，以及用人方的下一步决定
  • 状态依据：群里已形成 4～6 项编号格式并被所有 HR 沿用，但没有模板固化和统一存放；2026-01～08 用人方反复追问“有进展吗”“跟进没”约 18 次；早期漏问学历、毕业时间、能否到武汉，后续补问约 6 次

1. 场景判定

  • 触发条件：用人方在群里或台账里标记“问问情况/问问预期”；笔试结果为可面档次；内推候选人进入约面前
  • 典型说法：「先问问预期，预期太高了就不面了，省点时间」「问问啥时候毕业」「最好给个初步反馈保温一下」「这个有后续联系吗」
  • 判断问题：用人方是否已同意“可以考虑约面”，只差候选人意向和条件？是的话走本流程
  • 不归本流程管：简历初筛打分 → 请走 X-RCT-07；真实性疑点核实 → 请走 X-RCT-08；约面试时间与面试官 → 请走 X-RCT-11；面试通过后的谈薪定薪 → 请走 X-RCT-17

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
招聘专员 按清单沟通、录入台账、通知用人方、回复候选人 A/R 招聘专员（当前：张欣怡·推断待确认）
招聘助理 批量电话沟通、补录信息 R 招聘助理（当前：匡蓉、陈雁·推断待确认）
用人方/面试官 提名单与附加问题，看记录后决定约面 R 用人方负责人/面试官（当前：丁震宇、陈晖、王皓南·推断待确认）
人事负责人 维护问题清单与话术、带教、处理超时 A（升级） 人事负责人（当前：黄莹·推断待确认）
交付/FDE 负责人 交付岗附加问题（出差、转技术栈意愿） C 交付负责人（当前：待指定）

3. 办之前请准备

  • 候选人简历、二筛意见或笔试档次
  • 标准问题清单（见第 5 节）和用人方本次附加问题
  • 岗位基本信息：工作地点、是否接受实习、薪资带宽（只用于判断，不告诉候选人具体数字）
  • 公司招聘联系账号（让候选人主动添加，避免个人微信加人过多被限制）
  • 收简历阶段的快筛问题文档（职业方向、优势、对岗位与行业的理解）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 用人方在台账里把候选人状态改为“待预沟通”，有附加问题的写在备注栏 用人方 二筛/阅卷完成当天 多维表格台账 待沟通名单 🔧飞书固化
2 按标准清单电话沟通；电话打不通的发短信/BOSS 消息并请其主动加招聘账号 招聘专员/招聘助理 名单产生后 1 个工作日内 电话、BOSS、企业招聘账号 通话要点 👤人工判断
3 结果按固定字段录入台账（可用妙记或 AI 从通话要点生成），自动通知用人方 招聘专员 沟通当天 多维表格表单 + 机器人 预沟通记录 🔧+🤖
4 用人方查看记录，决定约面/淘汰/暂缓 用人方 收到通知后 1 个工作日内 台账 下一步决定 👤人工判断
5 约面的转 X-RCT-11；淘汰的转 X-RCT-15；暂缓的给候选人初步反馈并约定下次联系日期 招聘专员 决定后 1 个工作日内 台账、电话 候选人反馈记录 👤人工判断
6 候选人反馈有其他 offer 或截止日期的，标“紧急”并当天 @用人方 招聘专员 获知当天 机器人提醒 加急提醒 🔧飞书固化
7 状态停留超过 2 个工作日未更新的，机器人提醒 HR 与用人方 系统 每个工作日 10:00 多维表格自动化 超时提醒 🤖自动化

5. 交付物与模板

  • 交付物：预沟通记录、用人方决定、候选人反馈记录
  • 建议模板/表单（预沟通字段）：候选人编号、岗位、来源、在职状态、离职原因/空档原因、当前与期望薪资（受限字段，仅 HR 与用人方负责人可见）、最快到岗时间与离职交接周期、所在城市与能否到武汉、线上/线下面试偏好、全职/实习、实习时长与每周出勤天数、学历与毕业时间、其他 offer 与答复截止日、交付岗出差/转技术栈意愿、可面试时间段、沟通人、沟通日期、用人方决定
  • 标准话术：开场说明来电目的与招聘流程（职位匹配 → 1～2 轮技术面 → 终面 → offer）；结尾告知预计反馈时间

6. 异常与升级

  • 升级条件：候选人 3 天内需答复其他 offer、用人方超过 2 个工作日未给决定、问题清单或话术需调整 → 招聘专员升级人事负责人处理；其余由招聘专员直接闭环
  • 候选人期望明显超出岗位带宽 → 记录后交用人方判断，不当场承诺 → 用人方 1 个工作日内决定
  • 候选人 2 次联系不上 → 发消息留言，3 个工作日无回复标“失联”，转人才池（X-RCT-16）
  • 候选人已有其他 offer 且将在 3 天内截止 → 当天升级人事负责人，协调用人方加急约面
  • 同一候选人反复改决定（约/不约）→ 以台账最新决定为准，改动需写原因 → 超过 1 次时人事负责人提醒用人方
  • 候选人动机信息分散在多人私聊 → 一律补录到台账备注，不在私聊里传

7. 衡量指标

  • 预沟通时效 = 进入“待预沟通”到台账回填的工作日，目标 ≤ 1 个工作日
  • 字段完整率 = 必填字段齐全的记录 ÷ 预沟通记录总数，目标 ≥ 95%
  • 用人方追问次数 = 每月群里追问“有进展吗”的次数，目标逐月下降，季度末 ≤ 2 次/月
  • 面试后因预期/到岗/地点不符淘汰占比，目标 ≤ 10%

8. 低效诊断

  • 现象：用人方反复在群里追问 HR 沟通进展（反馈回路环节）｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-05
  • 现象：问题清单靠 HR 自己延续，早期漏问学历、毕业时间、能否到武汉，后续补问（清单环节）｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-04
  • 现象：沟通结果只在群里口述，不回填台账，候选人信息需要翻聊天记录（记录环节）｜依据：「技术岗招聘沟通」2026-03、「跃竞招聘群」2026-08
  • 现象：同一候选人前一天说不面、第二天又安排（决策环节）｜依据：「技术岗招聘沟通」2026-03
  • 现象：跟进慢，候选人先拿到其他 offer 后放弃（时效环节）｜依据：「技术岗招聘沟通」2026-04、「技术岗招聘沟通」2026-05
  • 现象：曾提出面试前做 10～15 分钟电话技术快面，因超出 HR 能力范围没有落地（分工环节）｜依据：「技术岗招聘沟通」2026-01

9. 分支变体

  • 社招：重点问在职状态、离职交接周期、年终奖等离职顾虑
  • 应届/实习：问毕业时间、实习时长、每周出勤天数、能否线下、是否接受实习薪资标准
  • 异地候选人：问能否到武汉、来武汉的原因、面试方式偏好（异地默认线上）
  • 交付/FDE 岗：加问出差意愿、是否愿意做交付或转技术栈
  • 跃竞主体：由跃竞招聘群对应 HR 执行，同一套字段

10. 待确认问题

  • 主责是否为招聘专员？人事负责人是否只做兜底与带教？
  • 预沟通是否放在笔试前（先确认意向与预期再发笔试）还是笔试后？
  • 薪资字段的可见范围怎么定？
  • 是否开通公司统一的招聘联系账号，替代 HR 个人微信？
  • 用人方 1 个工作日内给决定是否可行？
  • 是否需要 HR 先做简单的技术快问（如“哪年开始用 AI”），还是统一交给笔试？
X-RCT-10笔试与技术实操考核待优化180

状态：待优化｜证据：有证据（卡片 10 张 / 会话 5 个）｜优先级：频5 × 耗4 × 跨3 × 险3

  • 适用场景：候选人通过初筛（或预沟通）后，需要用笔试、上机题或实操题验证真实能力；也包括题库的出题、审题、改版
  • 负责人：主责——技术笔试负责人（当前：陈晖·推断待确认，需确认是否已变更）；协同——招聘 HR（当前：黄莹、张欣怡、匡蓉·推断待确认）、各岗位出题人（当前：王皓南、望政韬、张东郅、王子明、张楠、吴世豪·推断待确认）、IT 运维负责人（运维岗实操与笔试系统，当前：杨明学·推断待确认）、阅卷复核人（当前：岳阳·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 岗位绑定题目（题库维护）→ ② 确认笔试意向并查重 → ③ 按岗位批量发题 → ④ 截止提醒与回收 → ⑤ AI 预审 → ⑥ 阅卷定档 → ⑦ 结论回写并触发下一步 → ⑧ 题库复盘
  • 交付结果：每位候选人的笔试档次与处置建议（面/可面可不面/暂缓入池/淘汰），按岗位、版本管理的题库与评分标准
  • 状态依据：已有多套笔试题（Agent/Harness、全栈交付、测试、技术负责人）和面试官手册，但题库没有版本与岗位对照，2026-05 出现发错题约 3 次；发题、收卷、下载靠手工（抱怨约 8 次）；评分标准只在出题人脑中，阅卷人切换后无人能解释评分意图；笔试系统在建但未定稿

1. 场景判定

  • 触发条件：候选人通过初筛进入考核；新开岗位需要题目；旧题被 AI 几分钟答完、区分度不足或候选人反馈太长；同一候选人再次投递
  • 典型说法：「新来的一律先让 HR 给他们发题」「笔试总体时长不要超过两小时」「出题目的是筛选伪人和滥竽充数的」「我埋了反 AI 的坑」「本应发 Agent 笔试题的，但发了技术负责人的题」
  • 判断问题：这个岗位是否需要笔试？候选人是否已做过同一套题？要发的是哪个岗位、哪个版本的题？
  • 不归本流程管：笔试中发现代考、简历造假 → 请走 X-RCT-08；面试中的上机题与面评 → 请走 X-RCT-12；面试官考察标准与培养 → 请走 X-RCT-13；笔试淘汰通知 → 请走 X-RCT-15；候选人笔试用模型 Key/token 申请 → 请走 RND-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
技术笔试负责人 维护题库与评分标准、分配阅卷、主阅技术岗笔试 A/R 技术笔试负责人（当前：陈晖·推断待确认）
出题人 按岗位出题、审题、给评分要点 R 各岗位出题人（当前：王皓南、望政韬、张东郅、王子明、张楠、吴世豪·推断待确认）
招聘 HR 确认笔试意向、按岗位发题、提醒、回收、回写台账 R 人事负责人与招聘专员（当前：黄莹、张欣怡、匡蓉·推断待确认）
阅卷复核人 复核有争议或高分答卷 R 技术面试官（当前：岳阳、望政韬·推断待确认）
IT 运维负责人 运维岗实操考核、笔试系统建设 R IT 运维负责人（当前：杨明学·推断待确认）
兜底决策人 拍板题型与时长、阅卷人缺位时指定替代 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 岗位—题目对照表（岗位、题目名称、版本、时长、有效期、评分标准链接）
  • 候选人名单与台账记录（是否做过笔试、上次档次）
  • 专用笔试邮箱或笔试链接（与 HR 日常邮箱分开）
  • 告知话术：时长、截止时间、是否允许使用 AI（如允许，需提交 AI 协作过程）、线下笔试路费规则
  • 答卷回收位置（飞书问卷/表单，自动按人归档）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新岗位开招前出题；出题人提交题目 + 评分标准 + 建议时长（总时长 ≤ 2 小时），由技术笔试负责人和另一名面试官审题后登记入题库，标岗位与版本 出题人 岗位开招前 3 个工作日内 飞书 wiki + 题库多维表格 已登记题目 🔧飞书固化
2 发题前确认候选人愿意参加笔试并查重：做过同岗位题的不重复发，直接沿用档次 招聘 HR 发题前 台账 笔试名单 🤖自动化
3 按“岗位—题目对照表”选题，同批 ≤ 15 人，尽量集中在固定时间点统一发送；告知截止时间（默认发出后 7 天内）和作答规则 招聘 HR 名单确认后 1 个工作日内 专用笔试邮箱 / 限时链接 发题记录 🔧飞书固化
4 截止前 1 天提醒未交者；逾期给一次补交机会（延 2 天），仍未交的标“放弃”；发现转发题目链接的直接淘汰 招聘 HR 截止前 1 天、截止当天 机器人提醒 回收清单 🔧+🤖
5 答卷自动按人归档；AI 预审标出疑似代答、过度包装、字数超限、与题意无关等疑点 系统 提交后自动 飞书问卷自动化 + AI 预审意见 🤖自动化
6 阅卷定档：按评分标准给第一～第四档或不合格，写点评与处置建议；有争议或第一档的由复核人复核 技术笔试负责人 / 复核人 收卷后 2 个工作日内 评分表 档次 + 建议 👤人工判断
7 档次与建议写回台账并通知 HR：第一、二档约面（转 X-RCT-09/11），第三档暂缓入池，第四档及不合格淘汰（转 X-RCT-15） 技术笔试负责人 定档当天 多维表格 + 机器人 处置结论 🔧飞书固化
8 每月复盘：统计各题回收率、各档面试通过率，题目被 AI 秒答或区分度不足的改版，旧版本下线 技术笔试负责人 每月第 1 周 题库表 题库变更记录 👤人工判断

5. 交付物与模板

  • 交付物：题库（按岗位/版本/难度）、评分标准、笔试档次记录、发题与回收记录
  • 建议模板/表单：
    • 题库字段：题目编号、适用岗位、版本、难度、时长、是否允许 AI、评分要点（分档描述）、出题人、审题人、启用/停用日期
    • 笔试记录字段：候选人编号、岗位、题目编号与版本、发出日期、截止日期、提交时间、AI 预审疑点、档次、点评、处置建议、阅卷人
    • 档次—动作映射：第一档→尽快约面；第二档→约面；第三档→暂缓入池；第四档/不合格→淘汰
    • 题目要求：不得在题目里收集与考核无关的个人信息；可加一题“是否使用 AI 及如何使用”作为诚实度参考

6. 异常与升级

  • 升级条件：题型或总时长要突破“≤ 2 小时”规则、阅卷人缺位超过 2 个工作日、出题人与笔试负责人对档次有争议 → 技术笔试负责人升级兜底决策人（CTO）拍板；日常出题、发题、定档由技术笔试负责人决定
  • 发错题 → HR 当天补发正确题目并致歉，延长截止时间 → 记录到题库复盘
  • 阅卷人缺位或离开岗位 → 待阅答卷超过 2 个工作日 → 兜底人指定替代阅卷人，并要求出题人补齐评分标准
  • 疑似代考/代答 → 标疑点转 X-RCT-08，面试中定向追问
  • 回收率连续两批低于 40% → 技术笔试负责人检查题量与时长，HR 调整发放人数或沟通方式
  • 候选人对笔试负担有负面反馈 → HR 记录，月度复盘时评估是否缩短
  • 线上 coding 不可控 → 改为线下笔试或面试中投屏实操，需提前告知带电脑

7. 衡量指标

  • 笔试回收率 = 按时提交人数 ÷ 发题人数，目标 ≥ 60%
  • 阅卷时效 = 收卷到定档的工作日，目标 ≤ 2 个工作日
  • 发错题次数：目标 0 次/月
  • 笔试区分度 = 第一、二档候选人一面通过率，目标 ≥ 50%
  • 题目有评分标准的比例，目标 100%

8. 低效诊断

  • 现象：每个岗位的题都临时出，题量和考察目标反复争论，交付题“谁出”互相推（出题环节）｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-03
  • 现象：题库没有岗位与版本对照，技术负责人题错发给应届生（选题环节）｜依据：「技术岗招聘沟通」2026-05、「工程咨询产研」2026-03
  • 现象：手动记候选人方便的时间、逐个发题，周末早上也要人工发（发题环节）｜依据：「技术岗招聘沟通」2026-06
  • 现象：答卷要一份份手动下载，飞书打包下载会混在一起（回收环节）｜依据：「技术岗招聘沟通」2026-06
  • 现象：评分标准只在出题人脑中，阅卷人变更后要猜评分意图（阅卷环节）｜依据：「技术部」2026-08、「技术部」2026-09
  • 现象：旧题被 AI 几分钟答完或筛选力不足，被迫反复改题（题库维护环节）｜依据：「系统测试招聘」2026-04、「技术岗招聘沟通」2026-04
  • 现象：笔试收尾遗漏、有效期没有规定，导致提交率低（回收环节）｜依据：「系统测试招聘」2026-04、「系统测试招聘」2026-06
  • 现象：是否笔试、何时笔试靠个人判断，二面前才问要不要笔试（规则环节）｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-05
  • 现象：笔试题里混入与考核无关的个人信息收集（题目质量环节）｜依据：「鼎慧产研决策部」2026-08

9. 分支变体

  • Agent/Harness 岗：画架构图 + 简答，限字数；负责人岗另发“技术负责人题”（流程图 + 带队协作）
  • 全栈/交付岗：小项目 + 提交 AI 协作过程截图，限时交卷
  • 测试岗：由测试负责人出题与评分，用正式环境让候选人设计测试；高级测试不笔试
  • 运维岗：由 IT 运维负责人到面实操（排查网络、安装 AI 工具等），不走书面笔试
  • 跃竞主体：一面开放题表现好可免笔试（由后端负责人判定）；线下小项目笔试不通过不报销路费，HR 须事前告知
  • UI/设计岗：邮件发题，约 2 天截止，未回复视为放弃
  • 运营岗：改为发 token 做 AI 实操，Key 发放与回收走 RND-27
  • 再次投递：做过同岗位题的不重复发题，沿用上次档次

10. 待确认问题

  • 技术笔试负责人现由谁担任？是否需要每类题至少两名能阅卷的人？
  • 是否所有技术岗都先笔试再面试？哪些情况可免笔试？
  • 笔试有效期统一为 7 天是否可行？
  • 在建的网页笔试系统是否继续推进、由谁验收上线？
  • 是否允许候选人用 AI 作答？允许的话是否统一要求提交 AI 协作过程？
  • 线下笔试路费规则各主体是否统一？
X-RCT-11面试安排与面试官分配待优化180

状态：待优化｜证据：有证据（卡片 12 张 / 会话 8 个）｜优先级：频5 × 耗3 × 跨4 × 险3

  • 适用场景：候选人通过预沟通或笔试、进入面试环节时，确定轮次与面试官，协调时间、线上/线下、会议室、是否带电脑，创建日程并通知到位
  • 负责人：主责——招聘专员（当前：张欣怡·推断待确认）；协同——用人部门负责人（指派面试官，当前：丁震宇、王皓南、徐莉·推断待确认）、面试官（当前：陈晖、望政韬、吴世豪、岳阳、杨云峰、魏宗浩、王子明、张楠、张东郅·推断待确认）、招聘助理（当前：匡蓉、陈雁·推断待确认）、到面接待（当前：宫经喜·推断待确认）；兜底——人事负责人（当前：黄莹·推断待确认）
  • 核心流程：① 按“岗位×轮次面试官表”确定主面/副面 → ② 查面试官空闲给出时段 → ③ 约候选人并确定线上/线下 → ④ 建日程、订会议室、发到面指引 → ⑤ 面试前 1 个工作日发资料包 → ⑥ 面试前 1 小时双向确认 → ⑦ 改期与爽约处理
  • 交付结果：已发出的面试日程（标题“岗位-候选人-第 N 面”，含会议链接或会议室）、发给候选人的到面/线上指引、发给面试官的资料包
  • 状态依据：已用飞书日程和会议，2026-05 已有面试流程 SOP 初稿（两轮制、本地二面线下、外地全程线上），但“谁面”每次现问约 27 次，HR 反复催面试官给时间约 22 次，临时改期、候选人进错会议或走错楼约 10 次，并出过一次异地候选人线下面试后不录用的路费事故

1. 场景判定

  • 触发条件：用人方在台账里把候选人标为“约面”；需要约二面/终面；面试官临时冲突需改期或换人
  • 典型说法：「谁要面这个人」「面试时间是稀缺资源」「一面看技术，二面看团队匹配」「线上的会议室需要你们自己约一下哦」「集中几个能复试的安排在一起，不要独苗」
  • 判断问题：用人方是否已经决定要面这个人，只差“谁、何时、在哪”？是的话走本流程
  • 不归本流程管：预沟通意向与期望 → 请走 X-RCT-09；会议室预约规则与到访前台接待 → 请走 ADM-07；面试过程与面评 → 请走 X-RCT-12；跨组借调面试官、转推候选人 → 请走 X-RCT-14；面试官带教 → 请走 X-RCT-13

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
招聘专员 约候选人、建日程、订会议室、发指引与资料包、处理改期 A/R 招聘专员（当前：张欣怡·推断待确认）
招聘助理 协助约面与确认到场 R 招聘助理（当前：匡蓉、陈雁·推断待确认）
用人部门负责人 维护“岗位×轮次面试官表”，指派主面/副面 R 研发负责人/跃竞负责人（当前：丁震宇、王皓南、徐莉·推断待确认）
面试官 在日历上维护可面时段，1 个工作日内确认时间 R 技术面试官（当前：陈晖、望政韬、吴世豪、岳阳、杨云峰、魏宗浩、王子明、张楠、张东郅·推断待确认）
到面接待 候选人到场引导 R 跃竞内容运营（当前：宫经喜·推断待确认）、行政（当前：待指定）
人事负责人 规则维护、冲突协调兜底 A（升级） 人事负责人（当前：黄莹·推断待确认）

3. 办之前请准备

  • 候选人预沟通记录（所在城市、可面时间、线上/线下偏好）与笔试档次
  • 岗位×轮次面试官表（主面、副面、二面、终面）
  • 面试官飞书日历忙闲
  • 会议室占用情况
  • 到面指引模板（地址、楼层、前台、带电脑、应聘登记表）与线上面试指引模板

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按岗位×轮次面试官表确定主面与副面；表里没有的岗位由用人部门负责人当场指定并补进表 招聘专员 / 用人部门负责人 收到“约面”后当天 多维表格 面试官名单 🔧飞书固化
2 查面试官日历给出 2～3 个时段；面试官 1 个工作日内确认，不确认的按表换备选面试官 招聘专员、面试官 1 个工作日内 飞书日历忙闲 确认时段 🔧+🤖
3 约候选人：本地一面线上、二面线下；外地全程线上；外地确需线下的，须面试官与 HR 双确认并事先书面告知路费规则 招聘专员 时段确认后 1 个工作日内 电话、消息 候选人确认 👤人工判断
4 建日程（标题“岗位-候选人-第 N 面”），一次性加主面、副面、旁听人；线上附飞书会议链接；线下同时订会议室，订不到的当天升级 招聘专员 候选人确认当天 飞书日程 + 会议室 面试日程 🔧飞书固化
5 给候选人发指引：线下发地址、楼层、前台、需带电脑、提前填应聘登记表；线上发链接与入会说明 招聘专员 日程创建当天 固定消息模板 候选人指引 🔧飞书固化
6 给面试官发资料包：简历、预沟通记录、笔试档次与点评、本轮考察重点 招聘专员 面试前 1 个工作日 机器人推送 资料包 🤖自动化
7 每天 9:00 推送“今日面试”清单；面试前 1 小时与面试官、候选人双向确认 系统 / 招聘助理 每天 9:00；面试前 1 小时 机器人 今日面试清单 🤖自动化
8 改期或爽约：面试官改期须提前 4 小时通知 HR；候选人爽约记入台账，第二次爽约不再约 招聘专员 发生当时 台账 改期记录 👤人工判断

5. 交付物与模板

  • 交付物：面试日程、候选人指引、面试官资料包、今日面试清单
  • 建议模板/表单：
    • 岗位×轮次面试官表字段：岗位、主体、轮次、主面、副面、备选面试官、默认形式（线上/线下）、默认时长、考察重点
    • 排期规则：技术岗尽量避开周一、周五；首场不早于 9:30；连续面试间隔 ≥ 30 分钟；同岗位候选人集中在同一时段面；新面试官先旁听或副面
    • 面试官匹配规则：按岗位考察能力匹配，运营、产品岗不安排两名研发去面 AI 能力
    • 到面指引模板：日期时间、地址与楼层、到前台报岗位和面试官、带电脑、应聘登记表二维码、联系人

6. 异常与升级

  • 升级条件：同一天面试官排不过来、多个岗位抢同一面试官或会议室、排期规则需调整 → 招聘专员升级人事负责人当天协调；常规排期由招聘专员直接决定
  • 面试官 1 个工作日内不确认时间 → 换备选面试官 → 仍无人时升级用人部门负责人（当天）
  • 会议室不足 → 先改线上或借用其他空间 → 当天找行政协调（ADM-07）
  • 候选人进错会议、走错楼 → 招聘助理电话引导 → 同类问题当月复盘到指引模板
  • 外地候选人已线下到面但流程有误 → 按 X-RCT-15 正式致歉，路费按兜底人决定处理（FIN-07）
  • 面试官临时无法参加 → 提前 4 小时通知 HR，由副面主持或换人；不足 4 小时的由用人部门负责人决定改期或顶替
  • 同一天多场面试面试官排不过来 → 人事负责人当天调整顺序，不让同一面试官连排超过 3 场

7. 衡量指标

  • 约面时效 = 标“约面”到日程发出的工作日，目标 ≤ 2 个工作日
  • 改期率 = 改期场次 ÷ 安排场次，目标 ≤ 15%
  • “谁面”询问次数 = 每月群里询问面试官人选的次数，目标 ≤ 2 次/月
  • 候选人爽约率，目标 ≤ 10%
  • 面试官资料包按时发出率，目标 ≥ 95%

8. 低效诊断

  • 现象：“谁面”每次现问，面试官临时被指定且没人交代背景（面试官分配环节）｜依据：「技术岗招聘沟通」2026-03、「技术岗招聘沟通」2026-05、「技术岗招聘沟通」2026-07
  • 现象：HR 反复催面试官确认时间、催负责人给准信（时间确认环节）｜依据：「技术岗招聘沟通」2026-01、「跃竞招聘群」2026-02
  • 现象：面试官临时开会、外出，候选人迟到或爽约，频繁改期（改期环节）｜依据：「跃竞招聘群」2026-02、「技术岗招聘沟通」2026-07
  • 现象：会议室被占用或不够，线上会议谁发起不清（场地环节）｜依据：「技术岗招聘沟通」2026-01、「系统测试招聘」2026-08
  • 现象：候选人不知道办公地点、误以为线上，需要多人指路（指引环节）｜依据：「跃竞招聘群」2026-04
  • 现象：异地候选人被安排线下面试，面试官不知道对方在异地，之后不录用引发路费问题（形式选择环节）｜依据：「技术岗招聘沟通」2026-04
  • 现象：面试官与岗位不匹配，如运营岗安排两名研发面 AI 能力（匹配环节）｜依据：「Leap产研测」2026-09
  • 现象：面试时间与例会冲突，开发被动接受排期，反复改时间（排期规则环节）｜依据：「工程咨询产研」2026-02、「工程咨询产研」2026-04
  • 现象：候选人是否来、几点来靠群里问，面试官收到的信息不全（信息同步环节）｜依据：「鸽子群模态分群」2026-04、「鼎慧产研决策部」2026-02

9. 分支变体

  • 研发技术岗：一面技术（线上 30 分钟）→ 二面研发负责人/CTO（本地线下）→ 负责人岗加三面
  • 跃竞主体：技术一面由跃竞技术骨干面，二面由跃竞负责人主面，CEO/CTO 视情况参加谈薪；本地候选人终面必须线下
  • 实习生：一般一轮，由用人团队负责人面
  • 财务等专业岗：可借外部顾问专业面，HR 统计顾问面试次数
  • 行政、总助岗：综合部初面，CEO 终面
  • 运维岗：到面实操
  • 外部投递的 FDE 简历：先确认 FDE 负责人再约面（见 X-RCT-14）

10. 待确认问题

  • 主责是否为招聘专员？各主体（鼎慧、跃竞、Leap）是否各自一名约面负责人？
  • 面试流程 SOP 初稿（两轮制、外地全程线上、线下路费自理）是否已正式发布？与跃竞“笔试不过不报销”、异地事故“报销来回”如何统一？
  • 岗位×轮次面试官表由谁维护、多久更新一次？
  • 面试官改期至少提前 4 小时是否可行？
  • 线上面试会议由 HR 统一发起还是面试官发起？
X-RCT-12面试执行、面评与晋级决策待优化180

状态：待优化｜证据：有证据（卡片 12 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：面试当天按统一规范进行（时长、摄像头、录制、内部讨论边界），结束后面试官按模板提交面评，用人部门负责人据此决定进入二面、终面、录用、入池或淘汰
  • 负责人：主责——用人部门负责人（当前：技术岗丁震宇、跃竞徐莉·推断待确认）；协同——面试官（当前：陈晖、望政韬、王皓南、吴世豪、岳阳、宋祺睿、张东郅、杨明学、魏小东、康紫馨、段涵、陈梦琪、杨朋伟·推断待确认）、招聘 HR（当前：黄莹·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 面前看资料包、按题库备题 → ② 开场规范（录制、摄像头、纪要权限）→ ③ 分阶段执行，明显不符 20 分钟内收尾 → ④ 24 小时内提交结构化面评 → ⑤ HR 汇总并提醒 → ⑥ 负责人 1 个工作日内做晋级决策 → ⑦ 回写台账并转下游
  • 交付结果：每场面试一份结构化面评（维度评分、强弱项、风险、结论、建议），每位候选人一条晋级决策记录（二面/终面/录用/入池/淘汰及决策人）
  • 状态依据：已在用飞书妙记/智能纪要和面评文档，2026-05 有面试流程 SOP 初稿（一面 ≥ 30 分钟、1 个工作日内反馈），但面评格式、评分量表、存放位置不统一，2026-01～10 面评迟交被催、结论“总结在哪看”、谁有权决定录用反复询问约 25 次；同一候选人不同面试官评价相反；出现过面试纪要把内部评价暴露给候选人的情况

1. 场景判定

  • 触发条件：已排期的面试开始；一面/二面结束需要给结论；需要决定是否加面、谁二面、是否录用
  • 典型说法：「昨天的面评理一下呗」「先看诚实，再看简历，然后看工程思维」「发现很菜之后快速结束就行」「技术这边过了的话，最终由用人负责人决定录不录用」「面试真得写代码」
  • 判断问题：面试是否已经在进行或刚结束，需要形成“评价 + 下一步”？是的话走本流程
  • 不归本流程管：约面、改期、会议室 → 请走 X-RCT-11；面试官考察标准与带教 → 请走 X-RCT-13；结果通知候选人与拒信 → 请走 X-RCT-15；录用后的定薪与 offer → 请走 X-RCT-17；面试中发现造假 → 请走 X-RCT-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用人部门负责人 晋级与录用决策，指定二面/终面人选 A/R 研发负责人/CTO、跃竞负责人（当前：丁震宇、徐莉·推断待确认）
主面试官 按规范主持面试、24 小时内提交面评 R 技术面试官（当前：陈晖、望政韬、王皓南、吴世豪、岳阳、宋祺睿、张东郅·推断待确认）
专业岗面试官 运维、UI、产品、教育等岗位面试与面评 R 岗位面试官（当前：杨明学、康紫馨、段涵、魏小东、陈梦琪、杨朋伟·推断待确认）
副面/旁听 补充提问、补充面评 C 各组面试官
招聘 HR 开场接待、会议纪要权限设置、催面评、汇总、回写台账 R 人事负责人（当前：黄莹·推断待确认）
兜底决策人 高薪/负责人岗终面，超授权范围录用决策 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 资料包：简历、预沟通记录、笔试档次与点评
  • 本岗位面试题与考察标准（面试官手册、岗位标准卡，见 X-RCT-13）
  • 上机题环境：候选人自带电脑，面试官准备投屏
  • 面评模板链接
  • 会议录制与纪要设置：确认候选人入会后不能看到内部纪要

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 阅读资料包，从岗位题库选题（基础题、场景题、迁移题），标出要追问的疑点 主面试官 面试前 1 小时 面试官手册 提问提纲 👤人工判断
2 开场：开录制与智能纪要（线下也开会议录音）；摄像头规则为面试官开则双方都开；内部评论不在面试会议里说，另用内部群；候选人能否查看纪要的权限设为否 招聘 HR / 主面试官 开场 5 分钟内 飞书会议 录制与纪要 🔧飞书固化
3 分阶段执行：一面 30～60 分钟（基本认知 → 项目经验 → 代码/实操），技术岗含上机题（限时，如 45 分钟）；候选人反问控制在 2 分钟内；明显不符的 20 分钟内礼貌收尾，不当场拒绝 主面试官 面试中 飞书会议、候选人电脑 面试记录 👤人工判断
4 按模板提交面评：可用妙记 AI 摘要做底稿，面试官修改后提交；必须给出结论（推进/不推进/待定）和建议 主面试官、副面 面试结束后 24 小时内 面评表单 + 妙记 结构化面评 🔧+🤖
5 面评提交后自动通知 HR 与用人部门负责人；超过 24 小时未提交的机器人提醒 系统 / 招聘 HR 自动；超时当天 多维表格自动化 提醒记录 🤖自动化
6 晋级决策：二面/终面/录用/入池/淘汰；同一候选人评价相反时，负责人看录像后决定或安排加面 用人部门负责人 收到面评后 1 个工作日内 台账 决策记录 👤人工判断
7 回写台账：进入下一轮的转 X-RCT-11 排期；录用转 X-RCT-17；淘汰或入池转 X-RCT-15；二面及以上淘汰的面试官补写正式不录用原因 招聘 HR 决策当天 多维表格 状态更新 🔧飞书固化

5. 交付物与模板

  • 交付物：结构化面评、面试录制与纪要（仅内部可见）、晋级决策记录
  • 建议模板/表单（面评字段）：候选人编号、岗位、轮次、面试官、日期、维度评分（1～5 分：认知、技术/上机、工程思维、AI 使用能力、执行力/潜力、沟通与稳定性、诚实度、预期匹配）、强项、短板、风险、结论（推进/不推进/待定）、建议岗位与级别、纪要链接
  • 决策权限说明：技术岗一面过 → 二面由研发负责人/CTO；跃竞技术面过 → 跃竞负责人在已批 package 范围内决定录用，超范围找 CTO；实习生由用人团队负责人一轮拍板；负责人岗和高薪岗由 CTO/COO/CEO 终面

6. 异常与升级

  • 升级条件：负责人岗、高薪岗或超出已批 package 的录用，以及面试官评价相反 1 个工作日内仍定不下的 → 用人部门负责人升级兜底决策人（CEO）终面或拍板；其余晋级决策由用人部门负责人直接做
  • 面评 24 小时未交 → 机器人提醒 → 48 小时仍未交，HR 升级用人部门负责人
  • 面试官评价相反 → 负责人看录像或安排加面 → 1 个工作日内仍无法定，升级兜底人
  • 内部评价被录入候选人可见的纪要 → HR 当天关闭外部访问权限、删除不当内容 → 同类第二次发生时按 X-SEC-34 在飞书管理后台固化默认设置
  • 候选人追问结果、面试官迟迟不给结论 → HR 按 X-RCT-15 时限先给“仍在评估”的回复，同时升级负责人
  • 线上面试疑似作弊 → 当场要求关闭虚化、共享屏幕；仍可疑的转 X-RCT-08
  • 同岗位多人“赛马”试用 → 录用时写明考核期目标与淘汰规则，由用人部门负责人决定并转 HR-08

7. 衡量指标

  • 面评按时提交率 = 24 小时内提交的面评 ÷ 面试场次，目标 ≥ 95%
  • 面评模板使用率，目标 100%
  • 面试到结论周期 = 面试结束到晋级决策的工作日，目标 ≤ 2 个工作日
  • 评价分歧率 = 同一候选人两名面试官结论相反的比例，目标 ≤ 10%
  • 录用质量 = 试用期转正率，目标 ≥ 85%

8. 低效诊断

  • 现象：面评迟交，负责人催着要面评才能安排后续面试和入职（面评提交环节）｜依据：「技术岗招聘沟通」2026-01、「墨跃启智招聘」2026-01
  • 现象：各面试官评价维度不同，没有评分表，事后才想到要统一面评维度（模板环节）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-05、「技术岗招聘沟通」2026-04
  • 现象：面评散在群消息、文档和私下转述里，“总结在哪看来着”（存放环节）｜依据：「跃竞招聘群」2026-02、「鼎慧产研决策部」2026-05
  • 现象：谁有权决定录用、谁来二面反复在群里问（决策权限环节）｜依据：「跃竞招聘群」2026-03、「墨跃启智招聘」2026-03
  • 现象：一面时长口径互相矛盾，有面一个半小时才发现不行的情况（执行规范环节）｜依据：「技术岗招聘沟通」2026-04、「技术岗招聘沟通」2026-06
  • 现象：一面没写代码，二面再补；面试会议纪要找不到是谁开的（执行规范环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：内部吐槽被录进纪要，候选人能看到会议纪要（纪要权限环节）｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-03
  • 现象：岗位画像与面试预期错位，面来的人后来被推给别的组（岗位定义环节）｜依据：「Leap产研决策部」2026-09、「Leap产研决策部」2026-10
  • 现象：面试后 HR 需要反复追问评估结果和是否推进（反馈环节）｜依据：「系统测试招聘」2026-08、「系统测试招聘」2026-09

9. 分支变体

  • 研发技术岗：一面技术 + 上机题 → 二面研发负责人/CTO（团队匹配 + 补一面未覆盖点）→ 负责人岗加终面
  • 跃竞主体：技术一面打分（满分 10 分维度）→ 跃竞负责人 + CEO/CTO 二面（沟通、稳定性、配合度）并谈薪
  • 产品岗：产品总监主面，业务组旁听补问
  • 测试岗：笔试 + 现场 coding + 测试流程思路；系统测试由测试负责人面
  • 运维岗：硬件 + 软件一轮技术面，到面实操
  • 教育/产品方向：初面打百分制综合分，二面由 CEO 统一安排并主面
  • 实习生：一轮即可，用人团队负责人拍板
  • 同岗多人：可“赛马”试用，按一个月产出决定去留

10. 待确认问题

  • 主责是否为用人部门负责人？技术岗晋级决策是否统一由 CTO 做，还是授权给研发负责人？
  • 一面时长统一为 30 分钟还是 30～60 分钟？
  • 面评维度与 1～5 分量表是否可用？各岗位是否需要不同维度？
  • 面试纪要默认设置为仅内部可见是否已在飞书管理后台可配置，由谁设置？
  • 跃竞录用授权 package 的范围由谁维护？
  • “赛马”录用是否需要提前告知候选人？
X-RCT-13面试官培养与考察标准待新建36

状态：待新建｜证据：有证据（卡片 4 张 / 会话 5 个）｜优先级：频2 × 耗3 × 跨2 × 险3

  • 适用场景：新面试官上岗、新岗位开招前考察点不清，或面试评价质量不稳定时，明确各岗位考察标准和题型，按“旁听 → 副面 → 主面”培养面试官，并定期更新面试官手册
  • 负责人：主责——面试官手册负责人（当前：王皓南·推断待确认）；协同——面试辅导人（当前：岳阳·推断待确认）、AI 实操考官（当前：季学森·推断待确认）、测试岗标准负责人（当前：张东郅·推断待确认）、人事负责人（当前：黄莹·推断待确认）、新面试官（当前：杨云峰、魏宗浩·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 开招前建岗位考察标准卡 → ② 指定新面试官并安排旁听 → ③ 副面带教 → ④ 认证为主面 → ⑤ 面试规则与安全培训 → ⑥ HR 观摩学习 → ⑦ 每季度校准与手册更新
  • 交付结果：岗位考察标准卡、面试官手册（题库 + 评分要点 + 面试规则）、面试官名册（认证状态、可面岗位）
  • 状态依据：已有面试官手册（AI Fluency 4D 框架面试题），但只覆盖 AI 研发岗；运营、测试、开源社区岗考察点靠个人判断；新面试官靠每次口头交代（“让他自由发挥”）；“AI 使用能力作为招人门槛”“反问 2 分钟”“发 token 实操”等规则只在聊天中提出，未成文；2026-05 有人入职后才发现 git 基础不足

1. 场景判定

  • 触发条件：新面试官第一次被安排面试；新岗位开招；面试评价分歧大或误招；发现新的考察缺口（如 git 技能、AI 使用能力）；每季度末
  • 典型说法：「再招聘的时候能不能着重考察下 git 技能」「我们以后招人的门槛就是 AI 使用能力」「面试者要反问的话控制在两分钟内」「其实如果你有一套题库，面的时候压力会小一些」「感觉我的面试官手册得更新了」
  • 判断问题：问题出在“面试官不知道考什么、怎么评”吗？是的话走本流程；若只是某场面试的执行或面评，走 X-RCT-12
  • 不归本流程管：单场面试执行与面评 → 请走 X-RCT-12；笔试题库与阅卷 → 请走 X-RCT-10；面试官排期 → 请走 X-RCT-11；面试中给候选人开 Key/token → 请走 RND-27；入职后试用期考核标准 → 请走 HR-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
面试官手册负责人 维护手册与题库、组织季度校准 A/R 研发负责人（当前：王皓南·推断待确认）
面试辅导人 新面试官面前辅导、副面带教 R 资深面试官（当前：岳阳·推断待确认）
岗位标准负责人 写本岗位考察标准卡（测试、AI 实操、运营等） R 测试负责人、前端负责人（当前：张东郅、季学森·推断待确认）
新面试官 旁听、副面、按标准主面 R 研发骨干（当前：杨云峰、魏宗浩·推断待确认）
人事负责人 观摩学习、记录面试官名册、提醒校准 C 人事负责人（当前：黄莹·推断待确认）
用人部门负责人 指定新面试官，确认其可面岗位 R 各用人部门负责人
兜底决策人 定招人门槛与规则、批准手册发布 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 岗位 JD 与用人方对该岗位的“必须会/加分/一票否决”项
  • 现有面试官手册与题库
  • 近一个季度的面评与试用期结果（用于校准）
  • 新面试官名单与可面时间
  • 面试中如需实操发放 token 的额度与回收规则

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新岗位开招前写考察标准卡：考察维度、必问题、实操题、加分项、一票否决项、评分要点 岗位标准负责人 JD 发布前 飞书 wiki 岗位标准卡 🔧飞书固化
2 指定新面试官，先旁听 ≥ 2 场，旁听后写一份试评与正式面评对照 用人部门负责人 / 新面试官 上岗后 2 周内 飞书会议 旁听记录 👤人工判断
3 副面 ≥ 2 场：面前由辅导人讲本场重点；新人主问、老人辅问并补漏 面试辅导人 旁听完成后 2 周内 面试官手册 带教记录 👤人工判断
4 辅导人确认可独立主面，登记进面试官名册（可面岗位、轮次） 面试辅导人 / 人事负责人 副面完成后 1 个工作日内 多维表格 名册更新 🔧飞书固化
5 规则培训：反问 ≤ 2 分钟、不对候选人做承诺（拿不准的请其找负责人）、不当场拒绝、内部评论不进会议纪要、只看公开信息、实操发 token 按 RND-27 申请并在面试后回收 面试官手册负责人 新面试官主面前 手册 + 培训 培训记录 🔧飞书固化
6 HR 观摩若干场技术/AI 能力面试，了解各岗位 AI 能力边界，用于预沟通与初筛 人事负责人 每季度至少 2 场 飞书会议 观摩笔记 👤人工判断
7 季度校准：抽查面评，对比试用期表现，找出漏考项（如 git、AI 使用能力），更新手册与标准卡 面试官手册负责人 每季度末 10 个工作日内 面评表 + 试用期结果 手册新版本 🤖+👤

5. 交付物与模板

  • 交付物：岗位考察标准卡、面试官手册（含版本号）、面试官名册、季度校准记录
  • 建议模板/表单：
    • 岗位考察标准卡字段：岗位、维度（AI 使用能力、git 与工程基本功、工程思维、业务理解、沟通与诚实度）、必问题、实操题、一票否决项、评分要点（好/坏回答示例）、更新日期
    • 面试官名册字段：姓名、可面岗位、可面轮次、认证状态（旁听/副面/主面）、认证日期、近一季度面试场次
    • 面试规则清单：时长、反问时长、摄像头与录制、不承诺不当场拒、隐私边界、token 发放与回收

6. 异常与升级

  • 升级条件：手册改版涉及招人门槛（如 AI 使用能力是否全岗位适用）、面试官对考察口径有分歧 → 面试官手册负责人升级兜底决策人（CTO）定口径并批准发布；题目、评分要点等常规更新由手册负责人直接发布
  • 新面试官未经旁听被临时安排主面 → 改为副面或由老面试官陪同 → 无法调整时当天告知用人部门负责人
  • 岗位没有标准卡就开始面试 → 先用手册通用题，面后 3 个工作日内补标准卡
  • 面试官对“是否所有岗位都考 AI 能力”有异议 → 记录分歧 → 由兜底人 5 个工作日内定口径
  • 季度校准发现某面试官评价与试用期结果偏差大 → 辅导人复盘并安排回到副面 → 同一面试官连续两季度偏差，升级用人部门负责人
  • 实操 token 未回收或超额 → 面试官当天回收 → 按 X-SEC-11 处置

7. 衡量指标

  • 面试官认证覆盖率 = 已认证主面的面试官 ÷ 实际主面过的面试官，目标 100%
  • 岗位标准卡覆盖率 = 有标准卡的在招岗位 ÷ 在招岗位，目标 100%
  • 评价分歧率（同 X-RCT-12 口径），目标 ≤ 10%
  • 新员工试用期内因基本技能不足被提出问题的次数，目标逐季下降
  • 手册更新频率：每季度至少 1 次

8. 低效诊断

  • 现象：考察点靠面试官个人，入职后才发现 git 等基本功不足（标准制定环节）｜依据：「鸽子群模态分群」2026-05
  • 现象：“AI 使用能力是门槛”只是口头提出，各岗位是否都适用存在争议（标准口径环节）｜依据：「Leap产研决策部」2026-09
  • 现象：新面试官每次靠口头交代注意事项（带教环节）｜依据：「技术面试拉练小分队」2026-09、「技术岗招聘沟通」2026-09
  • 现象：面试中直接给候选人开 Key 做实操，额度与回收无规则（实操安全环节）｜依据：「技术面试拉练小分队」2026-09
  • 现象：测试岗招聘提出高要求，但考核标准没有落地，负责带人的一方不知道如何判断（标准落地环节）｜依据：「LeapPPT」2026-05

9. 分支变体

  • AI 研发岗：用面试官手册 4D 框架题（Coding Agent 过程、从零交付、45 分钟实现、处理“看起来能跑”的结果、展示改过的 AI 代码）
  • 前端岗：增加审美/taste 与 AI 工具实操
  • 测试岗：用例设计、每日测试内容与产出的可说明性
  • 运营/开源社区岗：考 AI 使用能力（如 Vibe Coding 实操），由运营或社区负责人主面，研发只做副面
  • FDE/运维岗：现场排障、客户沟通模拟

10. 待确认问题

  • 面试官手册负责人是否为研发负责人？其他主体（跃竞、鼎慧）是否各自维护手册？
  • “旁听 2 场 + 副面 2 场”再主面是否可行？
  • AI 使用能力是否作为全岗位门槛？非技术岗用什么题考？
  • 面试实操发 token 的额度上限与回收规则由谁定？
  • 是否已有其他团队写过的招聘 SOP 可直接合并？
X-RCT-14跨组面试支援与候选人转推/归属分配待新建48

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨4 × 险2

  • 适用场景：多个业务线（鼎慧、跃竞、AI 教育、基座、Leap、开放平台/FDE 等）同时招人，需要确定简历归属；候选人不适合本组但可能适合别组；某组缺面试官需要借调
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——各组用人负责人（当前：王皓南、王子明、徐莉·推断待确认）、被借调面试官（当前：张楠、吴世豪、葛家和、杨明学·推断待确认）、技术复筛人（当前：陈晖、望政韬·推断待确认）、招聘专员（当前：张欣怡·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 简历按岗位标签分配业务线 → ② 不对口候选人标“建议转推”与理由 → ③ 通知目标组负责人 → ④ 24 小时内回应要/不要 → ⑤ 接收组复用已有面评，只补差异轮次 → ⑥ 借调面试官登记 → ⑦ 无人接收的入人才池
  • 交付结果：台账中每位候选人有明确“归属组/负责面试官”，转推与借调有记录和结论
  • 状态依据：跨组转推和借调面试官频繁发生（2026-01～05 约 29 次），但只靠群里 @ 和喊话；转推后无人回应约 3 次、追问招人进度约 5 次；同一人在两个组分别从头面；各组招聘群边界不清，出现过“这个业务线的招聘不归你管”的争议

1. 场景判定

  • 触发条件：简历同时可能匹配多条业务线；本组面试后判断“人不错但不适合本组”；某组赶工无人可面；候选人主动想转投别的岗位
  • 典型说法：「这个看上去比较适合你们那边」「这三个你看要不要转到别的组问问」「借人帮教育组初面一下」「所有 Java 来投递的就打包给游戏这边看看」「先问问愿不愿意转到我们这个岗位」
  • 判断问题：这个候选人或这场面试的“归属组”是否不清楚，或需要另一个组出人？是的话走本流程
  • 不归本流程管：岗位需求与 HC 优先级 → 请走 X-RCT-01；简历初筛与分发 → 请走 X-RCT-07；常规面试官指派与排期 → 请走 X-RCT-11；招聘人员分工交接 → 请走 X-RCT-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事负责人 按岗位标签分配归属、发起转推通知、跟踪回应 A/R 人事负责人（当前：黄莹·推断待确认）
招聘专员 台账登记归属、转推与借调记录 R 招聘专员（当前：张欣怡·推断待确认）
发起组用人负责人 写转推理由、发起借调申请 R 各组用人负责人（当前：王皓南、王子明、徐莉·推断待确认）
接收组用人负责人 24 小时内决定要/不要，指定面试官 R 各组用人负责人
被借调面试官 按约定完成面试并提交面评 R 研发骨干（当前：张楠、吴世豪、葛家和、杨明学·推断待确认）
技术复筛人 对跨线简历给出技术判断 C 技术面试官（当前：陈晖、望政韬·推断待确认）
兜底决策人 归属争议、借调冲突拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 各业务线在招岗位清单与用人偏好（技术栈、年限、是否接受 Java 等）
  • 候选人已有的面评、笔试档次、预沟通记录
  • 各组招聘群/负责人名单（哪条业务线由谁管招聘）
  • 借调需求：岗位、轮次、时间、预计时长

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 简历按岗位标签分配到业务线，台账填“归属组”；匹配多组的标“多组可选”并同时通知 人事负责人 简历入库当天 多维表格 + AI 标签 归属组 🤖自动化
2 本组判断不对口但值得推荐的，在台账标“建议转推至 X 组”并写理由 发起组用人负责人 面试/复筛结论当天 台账 转推申请 👤人工判断
3 机器人 @目标组负责人，附简历、面评、预沟通记录 系统 标注后自动 机器人 转推通知 🔧飞书固化
4 接收组回应要/不要；要的指定面试官，不要的写理由 接收组用人负责人 24 小时内 台账 接收结论 👤人工判断
5 转岗位前由 HR 征得候选人同意；接收组复用已有面评与薪资预期，只补本组需要的轮次 招聘专员 / 接收组 接收后 1 个工作日内联系 电话 + 台账 候选人同意记录 👤人工判断
6 借调面试官：申请方向对方组负责人说明岗位、轮次、时间，对方 1 个工作日内答复；台账登记借调人 发起组用人负责人 1 个工作日内 多维表格 借调记录 🔧飞书固化
7 24 小时无回应自动提醒；所有组都不要的入人才池（X-RCT-16）并按 X-RCT-15 通知 系统 / 人事负责人 超时当天 机器人 入池记录 🤖自动化

5. 交付物与模板

  • 交付物：台账归属字段、转推记录、借调记录
  • 建议模板/表单：
    • 转推记录字段：候选人编号、原组、目标组、转推理由、已有面评链接、发起人、接收结论（要/不要）与理由、回应时间、候选人是否同意
    • 借调记录字段：申请组、借调面试官、所属组、岗位、轮次、日期、面评是否提交
    • 招聘群边界：各业务线的招聘需求与简历讨论在本线招聘群进行；跨线转推统一在台账里发起，不在私聊里决定；“要/不要”必须写理由

6. 异常与升级

  • 升级条件：转推 48 小时无回应、两个组争同一候选人且候选人意愿不明、借调面试官所在组拒绝支援 → 人事负责人升级兜底决策人（CTO）拍板；常规归属分配由人事负责人直接决定
  • 目标组 24 小时不回应 → 机器人再提醒 → 48 小时仍无回应，人事负责人升级兜底人
  • 两个组都要同一候选人 → 先尊重候选人意愿 → 意愿不明时兜底人 1 个工作日内决定
  • 借调面试官所在组赶工无法支援 → 对方负责人当天说明 → 由兜底人协调其他组
  • 归属争议转入私聊 → 回到台账记录理由 → 争议由兜底人裁决
  • 走关系、“后门”推荐 → 按 X-RCT-06 内推流程登记，同样过笔试与面试

7. 衡量指标

  • 转推响应时长 = 发出转推到接收组回应，目标 ≤ 24 小时
  • 转推后重复面试轮次 = 接收组重新面的轮次中与原组重复的部分，目标 0
  • 转推成功率 = 转推后被接收组录用人数 ÷ 转推人数（观察值，不设硬目标）
  • 借调登记率 = 有记录的借调 ÷ 实际借调次数，目标 100%

8. 低效诊断

  • 现象：转推后对方无人回应，候选人悬着（回应环节）｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-03
  • 现象：借调面试官靠群里喊话，谁可以支援要临时问（借调环节）｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-02
  • 现象：同一候选人在两个组分别从头面（复用环节）｜依据：「跃竞招聘群」2026-04
  • 现象：各业务线招聘由谁管不清，统筹人以为全部归他管，争议转到私聊（边界环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：“直接要了”不给理由，筛选标准不透明（决策环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：各组用人偏好不同（有的组不要 Java），简历反复在组间流转（分配环节）｜依据：「跃竞招聘群」2026-02

9. 分支变体

  • 基座 → 鼎慧/教育/跃竞：基座不对口的后端、全栈候选人转推
  • Java/后端简历：统一打包给接受 Java 的组先看
  • 运维 → 硬件交付：偏交付的运维候选人转交付岗
  • 转岗面试：候选人从别组岗位转来，需征得本人同意，沿用一面结论，补一轮二面
  • 鼎慧主体：在鼎慧专门招聘群内处理，不经技术岗招聘群统筹
  • 外部投递的 FDE 简历：先确认由开放平台/FDE 哪位负责人接收

10. 待确认问题

  • 主责是否为人事负责人？跨线归属争议是否由 CTO 统一裁决？
  • 各业务线招聘的负责人名单是否可以固定公布？
  • 转推 24 小时回应是否可行？
  • 借调面试官是否需要计入被借调组工作量？
  • Java 等技术栈偏好是否写进各组岗位标签？
X-RCT-15面试结果通知与不录用处理待新建120

状态：待新建｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频5 × 耗2 × 跨3 × 险4

  • 适用场景：笔试、一面、二面或终面有结论后，由 HR 按时限和话术通知候选人（通过/婉拒/暂缓入池），对需要留证的不录用写明原因，对主动联系的不合适候选人礼貌回复
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——招聘专员（当前：张欣怡·推断待确认）、面试官（当前：陈晖、望政韬、王皓南·推断待确认）、用人部门负责人（当前：丁震宇·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 面试官只把结论交 HR，不当场拒 → ② HR 按结论类型选话术 → ③ 在时限内通知候选人（内推同时回复推荐人）→ ④ 二面及以上淘汰补写正式不录用原因 → ⑤ 流程失误时正式致歉并处理路费 → ⑥ 收集候选人反馈 → ⑦ 台账回写，入池或拉黑
  • 交付结果：候选人收到的结果通知、内部留存的不录用原因（需要时）、台账状态更新（录用/淘汰/入池/拉黑）
  • 状态依据：面试流程 SOP 初稿写了“通过 2 个工作日内通知、未通过按话术回复”，但没有话术库和原因库；2026-01 出现面试官当场拒绝引发“有损公司形象”的讨论，2026-04 出现异地候选人线下面试后不录用、需事后道歉和报销路费的事故；HR 追问“还推进吗”约 10 次，候选人面完长期悬着

1. 场景判定

  • 触发条件：X-RCT-10 笔试定档、X-RCT-12 晋级决策产生“淘汰/入池/通过”；候选人追问结果；不合适的候选人主动反复联系
  • 典型说法：「得有个规范，我们自己还是得有礼貌」「让他回去等消息，定个预期反馈时间」「那你下午反馈一下，说遗憾落选」「回他就说经过决定，不匹配公司业务」「内推是 2 天内给反馈」「SOP 礼貌送走」
  • 判断问题：候选人的结论是否已定（或已超时），需要对外答复？是的话走本流程
  • 不归本流程管：通过后的定薪与 offer → 请走 X-RCT-17；人才池维护与回捞 → 请走 X-RCT-16；内推奖励 → 请走 X-RCT-06；路费报销单据 → 请走 FIN-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事负责人 维护话术库与原因库、对外通知、处理反馈与投诉 A/R 人事负责人（当前：黄莹·推断待确认）
招聘专员 发送通知、回写台账、通知内推人 R 招聘专员（当前：张欣怡·推断待确认）
面试官 给出结论；二面及以上淘汰写正式不录用原因 R 技术面试官（当前：陈晖、望政韬、王皓南·推断待确认）
用人部门负责人 确认结论，流程失误时决定补救方式 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）
法务 不录用留痕口径 C 法务（当前：待指定）
内推人 知悉结果 I 推荐员工

3. 办之前请准备

  • 台账里的结论、轮次、面评摘要
  • 话术库（按笔试/一面/二面/入池/候选人放弃分类）
  • 原因库（内部用）：技术不达标、经验不匹配、预期差距、稳定性、真实性存疑、岗位变更
  • 内推人信息（如是内推）
  • 候选人所在地与面试形式（判断是否涉及路费）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 面试官只把结论交给 HR，不当场拒绝；明显不符的按 X-RCT-12 在 20 分钟内礼貌收尾，告知“结果由 HR 联系” 面试官 面试结束时 台账 结论 👤人工判断
2 结论写入台账后自动生成“通知任务”，带截止日期 系统 结论写入时 多维表格自动化 通知任务 🤖自动化
3 按结论类型选话术通知：通过 2 个工作日内；淘汰在结论后 3 个工作日内，面试后最长不超过 7 天；超过 7 天仍无结论的按未通过处理，不再回头；回复时间在 9:00～21:00 招聘专员 见左 电话/消息/邮件 通知记录 🔧飞书固化
4 内推候选人：2 个工作日内同时回复推荐人 招聘专员 2 个工作日内 消息 内推反馈 🔧飞书固化
5 二面及以上淘汰、线下面试淘汰、异地候选人淘汰：面试官写正式不录用原因（内部留档，不发给候选人） 面试官 结论后 1 个工作日内 台账附件 不录用原因 👤人工判断
6 流程失误（如异地候选人未告知路费规则就线下面）：通知结果时正式说明并致歉，路费按负责人决定走报销，车票交 HR 转交 人事负责人 结论后 2 个工作日内 消息 + 飞书报销 致歉与报销记录 👤人工判断
7 收集候选人对面试流程的反馈，汇总给用人部门负责人 人事负责人 收到后 2 个工作日内 反馈表 反馈记录 🔧飞书固化
8 台账回写：录用转 X-RCT-17；暂缓的入人才池并设回访日期；确认造假或骚扰的标“拉黑” 招聘专员 通知当天 多维表格 状态更新 🔧飞书固化

5. 交付物与模板

  • 交付物：通知记录、不录用原因（内部）、候选人反馈记录、台账状态
  • 建议模板/表单：
    • 话术库：通过（告知下一步与时间）；笔试未通过（感谢投入、不展开原因）；面试未通过（“经综合评估与岗位要求不完全匹配，感谢参加”）；暂缓入池（说明岗位变化时会再联系）；候选人放弃（确认并感谢）；不合适的主动联系者（一次礼貌回复，不再展开）
    • 不录用原因字段：候选人编号、岗位、轮次、原因类别（取自原因库）、具体事实（面评要点）、面试官、日期
    • 通知规则：对外只说“不匹配/有更合适人选”，不给详细理由；不在深夜回复；不当场拒绝

6. 异常与升级

  • 升级条件：结论超时未出、流程失误需决定补救方式（如路费报销）、候选人对结果有争议 → 人事负责人升级用人部门负责人决定；涉及公司形象的再升级兜底人（CTO）；常规通知由人事负责人直接执行
  • 结论超时未出、候选人追问 → HR 先回复“仍在评估，预计 X 日前答复” → 当天升级用人部门负责人
  • 候选人对结果或流程不满、在外部传播 → 人事负责人当天了解情况并回应 → 涉及公司形象的升级兜底人
  • 候选人要求说明详细理由 → 只给原因类别 → 坚持索要或涉及争议的咨询法务（2 个工作日内）
  • 异地线下面试事故 → 正式致歉、按决定报销 → 当周复盘到 X-RCT-11 排期规则
  • 候选人被拒后反复联系 → 一次礼貌回复后不再回应 → 有骚扰的标“拉黑”
  • 面试官当场拒绝候选人 → HR 事后补正式通知 → 同一面试官再次发生时由辅导人按 X-RCT-13 重申规则

7. 衡量指标

  • 通知及时率 = 按时限通知的人数 ÷ 有结论的人数，目标 ≥ 95%
  • 面试后超过 7 天未获通知的人数，目标 0
  • 不录用原因留存率 = 二面及以上淘汰中留有原因的比例，目标 100%
  • 内推 2 个工作日反馈率，目标 100%
  • 候选人负面反馈数：每月统计，目标逐季下降

8. 低效诊断

  • 现象：有人当场拒、有人拖几天，结果反馈没有统一时限和话术（通知规则环节）｜依据：「技术岗招聘沟通」2026-01
  • 现象：出事后才补规范，异地候选人线下面试后才发现路费和流程问题，需要事后道歉（事前告知环节）｜依据：「技术岗招聘沟通」2026-04
  • 现象：没有拒信模板和原因库，需要留证时临时补写（留痕环节）｜依据：「技术岗招聘沟通」2026-04
  • 现象：HR 反复追问“还推进吗”，候选人面完长期悬着（结论→通知衔接环节）｜依据：「技术岗招聘沟通」2026-07、「技术岗招聘沟通」2026-09
  • 现象：已约面后才发现预期极低，只能“流程走完”（前置筛选环节）｜依据：「技术岗招聘沟通」2026-07
  • 现象：候选人对面试流程的负面反馈没有闭环（反馈环节）｜依据：「技术岗招聘沟通」2026-05
  • 现象：不合适的候选人反复主动联系，深夜回复占用时间（主动联系处理环节）｜依据：「跃迁AI总动员」2026-10

9. 分支变体

  • 笔试淘汰：用笔试话术，不需要写正式原因
  • 一面淘汰：用面试话术，原因类别写入台账即可
  • 二面及以上淘汰、线下面试淘汰：必须由面试官写正式不录用原因
  • 内推候选人：2 个工作日内同时回复推荐人
  • 暂缓入池：说明会在岗位变化时联系，设回访日期（X-RCT-16）
  • 加面后的结论：加面结束后重新计算时限
  • 实习生：一轮结束即通知；外地候选人只做线上，不涉及路费

10. 待确认问题

  • 主责是否为人事负责人？面试官是否一律不允许当场拒绝？
  • 通知时限“通过 2 个工作日、淘汰 3 个工作日、最长 7 天”是否可行？
  • 不录用原因留存是否需要法务确认口径与保存期限？
  • 异地线下面试路费规则（自理/通过才报/一律报销）以哪条为准？
  • 话术库由谁定稿？是否需要按主体（模态、跃竞）分别准备？
  • 拉黑名单是否与 X-RCT-08 共用？
X-RCT-16候选人台账、人才池与招聘系统维护待优化108

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨3 × 险3

  • 适用场景：同时推进多名候选人（全职/实习/远程/内推），需要统一登记候选人状态、面试官和面评；或候选人放弃、失联、已有别家 offer、被淘汰、暂缓时，需结案或打标签放入人才池，以便日后回捞
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、匡蓉、陈雁·推断待确认）、技术岗候选人池维护人（当前：丁震宇·推断待确认）、面试官（当前：王皓南、望政韬、岳阳、王子明·推断待确认）、招聘系统开发（当前：杨明学·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 定唯一主数据源 → ② 新简历建档并查重 → ③ 阶段变更回写 → ④ 面评挂接 → ⑤ 结案或打标签入人才池 → ⑥ 每日待跟进推送 → ⑦ 月度人才池回捞与清理
  • 交付结果：一份唯一、实时的候选人主台账（含阶段、面试官、面评链接、结论与原因），可按标签检索的人才池视图，每日待跟进摘要
  • 状态依据：已有云文档“招聘台账”、技术岗人才库自制表、飞书多维表格候选人池和自建 jobs 招聘系统（内测），但四处并行、未定主数据源，更新靠人；2026-01～10 群内反复贴状态清单、找简历约 10 次以上，出现全职/实习/同名混淆和跨主体重复约面

1. 场景判定

  • 触发条件：收到新简历需要登记；候选人进入新阶段（约面、笔试、面试、结论）；候选人放弃/失联/已有 offer/被淘汰/暂缓；简历不错但时机不对（如下一届实习、岗位暂停）；有人询问某候选人进度或历史面评；新岗位开放需要先查人才池
  • 典型说法：「真需要一个招聘系统了」「都在上面有状态」「先进人才池」「他已经拿到 offer 了，pass」「能不能说名字，太乱了」「之前的表在哪」
  • 判断问题：这件事是不是“记录、查询或变更某个候选人的状态与历史”？如果是在做筛选、面试、谈薪本身，只把结果回写到本台账，动作本身走对应流程
  • 不归本流程管：简历收集、初筛与分发 → 请走 X-RCT-07；简历真实性核验 → 请走 X-RCT-08；面试执行与面评撰写 → 请走 X-RCT-12；不录用通知与话术 → 请走 X-RCT-15；招聘进度同步与漏斗复盘 → 请走 X-RCT-21；入职后员工档案 → 请走 HR-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
台账负责人 定字段与规则、确保唯一主数据源、每月清理人才池 A HR 负责人（当前：黄莹·推断待确认）
招聘专员 建档查重、更新阶段、记录放弃/失联原因、发待跟进提醒 R HR 招聘专员（当前：张欣怡、匡蓉、陈雁·推断待确认）
技术岗候选人池维护 技术岗简历归类、标签维护、从池子挑人 R 技术岗候选人池维护人（当前：丁震宇·推断待确认）
面试官 回写面评链接与结论，决定是否入人才池 R 面试官（当前：王皓南、望政韬、岳阳、王子明·推断待确认）
招聘系统开发 系统功能迭代、权限开通、查重与自动回写 R 招聘系统开发（当前：杨明学·推断待确认）
兜底决策 主数据源选型、跨主体共享范围拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）
用人部门负责人 查看本岗位候选人状态 I 各用人部门负责人

3. 办之前请准备

  • 已确定的主数据源（jobs 招聘系统或飞书多维表格二选一）及访问权限（内网 HR 面板需开通飞连权限）
  • 阶段字典：新简历 / 初筛通过 / 待约面 / 待笔试 / 一面 / 二面 / 待定薪 / 已发 offer / 已入职 / 不通过 / 候选人放弃 / 失联 / 暂缓
  • 标签字典：方向（数字人、基座、Java、交付、Agent、测试等）、用工类型（全职/实习/远程实习/兼职）、届别、可回捞时间
  • 候选人唯一 ID 规则与查重字段（系统生成 ID，比对姓名+联系方式，联系方式仅系统内可见）
  • 在招岗位清单、各岗位面试官名单、面评模板链接

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确定唯一主数据源，其余云文档台账、自制表转只读并迁移历史记录；群里只发候选人 ID 和链接，不再贴状态清单 台账负责人提方案，兜底决策拍板 本 SOP 发布后 5 个工作日内 jobs 系统 / 多维表格 主台账与迁移记录 👤人工判断
2 新简历入库：建档、生成候选人 ID，自动查重并带出历史投递、面评、结论（含其他主体） 招聘专员 收到简历当天 招聘系统查重 候选人记录 🤖自动化
3 阶段变更回写：约面、笔试、面试完成由日程和笔试系统自动回写；无法自动的由招聘专员手动更新 招聘专员 状态变化当天 飞书日程联动 / 多维表格 最新阶段 🔧+🤖
4 面试官填写面评并把链接、结论回写到候选人记录 面试官 面试结束后 1 个工作日内 面评模板 面评链接、结论 🔧飞书固化
5 结案：放弃/失联/已有 offer/不通过填写原因；有潜力或时机不对的，由面试官决定入池并打标签、写可回捞时间 招聘专员、面试官 结论产生后 1 个工作日内 多维表格 结案记录、人才池条目 👤人工判断
6 机器人每天 10:00 推送“超过 3 个工作日无更新”的候选人给对应招聘专员和面试官 招聘系统 每个工作日 飞书机器人 待跟进摘要 🤖自动化
7 新 HC 或岗位重开时先按标签检索人才池；每月清理超过 6 个月无动作的条目（标记过期，不删除历史面评） 招聘专员 岗位开放当天；每月第 1 周 多维表格视图 回捞名单、清理记录 🔧+👤
8 收集系统使用问题（上传权限、题组、渲染、预览），按“先完整流程、再 AI 简历提取与打分”节奏迭代 招聘系统开发 每 2 周发布一次 jobs 系统 / wiki 迭代记录 🤖自动化

5. 交付物与模板

  • 交付物：候选人主台账、人才池视图、每日待跟进摘要、月度人才池清理记录
  • 建议模板/表单：
    • 候选人主台账字段：候选人 ID、姓名、应聘岗位、用工类型、所属主体（模态/鼎慧/跃竞等）、来源渠道、内推人、当前阶段、负责招聘专员、面试官、面评链接、结论、放弃/淘汰原因、答复日期、标签、可回捞时间、最近更新时间
    • 人才池视图：按方向标签、用工类型、届别、可回捞时间筛选，显示历史面评摘要

6. 异常与升级

  • 升级条件：主数据源选型、跨主体共享与查看权限范围、面评 3 个工作日仍未回写 → 台账负责人升级兜底决策（创始人兼 CTO）拍板；字段、标签和日常清理规则由台账负责人直接决定
  • 查重命中“曾在其他主体被淘汰” → 招聘专员附上历史面评提示本次面试官 → 由面试官 1 个工作日内决定是否继续；有争议升级 HR 负责人
  • 同名或全职/实习混淆 → 群内沟通一律使用候选人 ID + 用工类型 → 已造成错约的当天更正并通知候选人
  • 面评超过 1 个工作日未回写 → 机器人次日催办 → 3 个工作日仍未回写升级创始人兼 CTO
  • 系统无法访问或权限不足（内网面板、安全网关拦截） → 当天联系招聘系统开发处理 → 半个工作日未恢复，临时在多维表格登记并事后补录
  • 候选人信息被转发到非招聘群 → 招聘专员提醒撤回并改发台账链接 → 再次发生升级 HR 负责人

7. 衡量指标

  • 台账更新及时率 = 状态变化后 1 个工作日内更新的记录数 / 状态变化总数，目标 ≥ 95%
  • 面评挂接率 = 有面评链接的已面候选人数 / 已面候选人数，目标 100%
  • 重复约面次数 = 已被淘汰候选人未经查重再次约面的次数，目标 0
  • 群内找信息次数 = 每月群里询问“简历在哪/状态是什么”的次数，目标逐月下降
  • 人才池回捞率 = 从人才池回捞并进入面试的人数 / 当月进入面试总人数，作为参考指标

8. 低效诊断

  • 现象：云文档台账、自制人才库、多维表格、招聘系统并行，没有约定以哪个为准，简历同时散落在群、表、系统三处（主数据源环节）｜依据：「技术岗招聘沟通」2026-01、「技术部」2026-06
  • 现象：候选人状态靠在群里反复贴清单口头同步，同一清单重复发 5 次以上（状态同步环节）｜依据：「技术岗招聘沟通」2026-03、「技术部」2026-09
  • 现象：全职、实习、同名候选人在群里讨论时串在一起，面试官要求“说名字”（标识环节）｜依据：「技术部」2026-09
  • 现象：面试官找不到简历和以前的表，需要反复问（查询环节）｜依据：「技术岗招聘沟通」2026-01
  • 现象：候选人曾在一个主体被淘汰，另一个主体又约面，靠偶然发现（查重环节）｜依据：「跃竞招聘群」2026-07、「技术部」2026-10
  • 现象：放弃、失联、已有 offer 的原因只在群里一句话，没有集中记录（结案环节）｜依据：「跃竞招聘群」2026-02、「跃竞招聘群」2026-08
  • 现象：招聘系统内测阶段只有 HR 能上传、题目无人录入、渲染和预览不完善，研发试用感觉“没做完”（系统建设环节）｜依据：「技术岗招聘沟通」2026-07、「技术部」2026-06

9. 分支变体

  • 人才池按方向标签管理：数字人、基座、Java 外包、交付、Agent、测试等
  • 时机不对（如下一届实习、岗位暂停）：标“暂缓”并写可回捞时间；岗位暂停时对待面试者统一告知“暂不安排面试”
  • 候选人放弃（已有别家 offer）、失联（未到场）、不通过、进人才池：结案原因分别记录
  • 用工类型：全职 / 实习 / 远程实习 / 内推 / 开源社区来源，统一用“用工类型”“来源”字段区分
  • 系统形态：公网 jobs 站（候选人投递）与内网 HR 面板（HR 与面试官使用）

10. 待确认问题

  • 主数据源定为自建 jobs 招聘系统还是飞书多维表格？是否仍考虑采购飞书招聘？
  • 模态、鼎慧、跃竞等主体是否共用一个候选人库？跨主体查看历史面评的权限范围如何定？
  • 查重使用哪些字段，联系方式等个人信息的可见范围如何控制？
  • 人才池条目的保留期限是否为 6 个月？到期后如何处理？
  • 招聘系统中笔试题目由谁录入维护（用人部门负责人还是 HR）？
  • 技术岗候选人池日常维护是否由 HR 接手，减少创始人兼 CTO 的事务负担？
X-RCT-17定薪谈薪、录用审批与 Offer 发放待优化400

状态：待优化｜证据：有证据（卡片 10 张 / 会话 10 个）｜优先级：频5 × 耗4 × 跨4 × 险5

  • 适用场景：候选人终面通过后，需要确定岗位名称、职级、用工类型与主体，核定试用期与转正薪资、补贴，完成审批并发出录用通知书
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人/面试官（当前：王皓南、杨萌、张东郅、葛家和、徐莉、王子明·推断待确认）、技术岗定薪审批人（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 面试官出分项评价 → ② HR 摸底期望与现薪 → ③ 先定职能、职级与主体 → ④ 对照薪酬带宽出方案 → ⑤ 录用审批 → ⑥ HR 单一出口谈薪 → ⑦ 录用通知书审核并邮件发出 → ⑧ 归档并更新人力成本表
  • 交付结果：已审批的录用审批单（定薪理由、试用期、转正薪资、补贴、主体）、经审核并发出的录用通知书、候选人确认回执与到岗日期
  • 状态依据：已有招聘 SOP（含试用期规范）、录用通知书模板和邮箱发放的固定做法，但没有岗位薪酬带宽表和录用审批单，定薪逐人在群里请示；2026-01～10 多个招聘群反复出现口径不一、试用期折扣现问、岗位名称现问、多层级各自报价、出薪卡点不透明，合计 30 次以上

1. 场景判定

  • 触发条件：候选人终面通过并进入谈薪；候选人期望高于预算；需要确定实习生薪资档、出勤要求或实习转正 HC；录用通知书需要起草或审核；候选人对已报条件还价
  • 典型说法：「先定职能，才能出薪」「输出一个评价，给到负责人参考定薪用」「出薪卡在哪个环节了」「试用期按九折？」「岗位名称写什么」「后面变工资都说几月实发吧，免得有歧义」
  • 判断问题：候选人是否已通过全部面试？现在要决定的是不是“给多少钱、什么条件、以什么岗位和主体录用”？
  • 不归本流程管：HC 与岗位预算申请 → 请走 X-RCT-01 / HR-03；在职员工定级调薪 → 请走 HR-09；拟录用背景调查 → 请走 X-RCT-18；用工主体判定与劳动合同签署 → 请走 HR-04；AI 工具补贴发放 → 请走 HR-17；高管与子公司负责人定薪 → 请走 X-RCT-23；接受 offer 后的入职衔接 → 请走 X-RCT-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
面试官 出分项评价、给能力级别建议 C 面试官（当前：葛家和、张东郅、王皓南·推断待确认）
用人部门负责人 定职能、职级、挂靠团队，提出薪资建议 R 用人部门负责人（当前：王皓南、杨萌、徐莉、王子明·推断待确认）
HR 负责人 汇总期望、出定薪方案、带宽内确认出价、唯一谈薪出口、起草与发放通知书 R HR 负责人（当前：黄莹·推断待确认）
招聘专员 摸底期望与到岗时间、发 offer、收回执 R HR 招聘专员（当前：张欣怡·推断待确认）
技术岗定薪审批人 审批产研技术岗超带宽定薪、审核通知书 R（审批） 创始人兼 CTO（当前：丁震宇·推断待确认）
主体负责人 在已批 package 内定本主体岗位薪资 R（审批） 跃竞负责人（当前：徐莉·推断待确认）
CEO 非技术岗、实习生统一标准、实习转正 HC、超档特批终审 A CEO（当前：邴龙志·推断待确认）
财务 核对预算与人力成本表 C 财务（当前：待指定）
法务 一次性审定通知书模板关键条款 C 法务（当前：待指定）

3. 办之前请准备

  • 面试官分项评价与结论（面评链接）
  • 候选人信息：现薪与近 6 个月薪资流水、期望薪资、到岗时间、离职原因、手上其他 offer 及答复截止日
  • 岗位名称字典、职级说明、用工类型（全职/实习/兼职劳务）与签约主体规则
  • 岗位薪酬带宽表（受限查看）、实习生薪资标准、试用期规则（时长与折扣）、补贴口径（AI 补贴、交通补贴等）
  • 本岗位 HC 与预算审批记录；当前人力成本表
  • 录用通知书模板（法务已审定版本）
  • 请求最少包含字段（用人部门发起出薪）：候选人 ID、面评链接、拟定岗位名称（从字典选）、职级、用工类型、签约主体、挂靠团队与直属上级、期望到岗日、竞争 offer 截止日；缺项由 HR 退回，不进入出薪

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 终面后按模板给出分项评价和能力级别建议；不通过也写原因 面试官 终面后 1 个工作日内 面评模板 分项评价（面评模板，链接挂候选人台账；超时→用人部门负责人） 🔧飞书固化
2 电话摸底现薪、流水、期望、到岗时间、离职原因、竞争 offer，写入候选人记录 招聘专员 终面通过后 1 个工作日内 候选人台账 候选人薪资信息卡（候选人台账受限字段） 👤人工判断
3 先定职能、岗位名称（从字典选）、职级、用工类型、签约主体和挂靠团队；定位不清时先退回用人部门，不进入出薪 用人部门负责人 收到信息卡后 1 个工作日内 岗位名称字典 定岗结论（候选人台账定岗字段，通知 HR 负责人） 👤人工判断
4 对照薪酬带宽出方案：试用期时长与折扣、转正薪资、补贴、生效月统一写“X 月实发”；AI 根据带宽和信息卡生成报价建议 HR 负责人 定岗后 1 个工作日内 薪酬带宽表 + AI 定薪方案（录用审批单草稿） 🤖自动化
5 提交飞书“录用审批”：带宽内由 HR 负责人与用人负责人确认即可；超带宽、负责人岗、跨主体发薪、实习转正 HC 按授权走 CTO/主体负责人 → CEO；有竞争 offer 的标“加急” HR 负责人 审批人 2 个工作日内处理；加急当天 飞书审批 已批录用审批单（飞书审批，编号回写候选人台账；超时→CEO） 🔧飞书固化
6 HR 作为唯一出口与候选人谈薪；其他人不直接向候选人报价；还价超出已批范围，回到第 5 步补批 HR 负责人 / 招聘专员 审批通过后 1 个工作日内 电话 / 邮件 谈薪结果（候选人台账谈薪记录） 👤人工判断
7 用模板自动填字段生成录用通知书，发用人负责人（技术岗另发 CTO）核对岗位名称、主体、试用期、薪资 HR 负责人 谈妥后 1 个工作日内起草；审核 1 个工作日内 通知书模板 待发通知书（模板生成 PDF，审核意见记录在审批单评论） 🔧+🤖
8 需背调的岗位背调通过后，从 HR 邮箱发出录用通知书，写明答复期限（3 个工作日）和到岗日期 招聘专员 审核通过后 1 个工作日内 HR 邮箱 已发 offer（HR 邮箱发出，台账记录发出时间与答复期限） 🔧飞书固化
9 审批单、通知书、候选人回执归档到候选人记录与人事档案，更新人力成本表；内推岗位记录内推人 HR 负责人 候选人确认当天 台账 / 人事档案 归档记录（候选人台账 + 人事档案 + 人力成本表） 🤖+👤

5. 交付物与模板

  • 交付物：录用审批单、录用通知书（PDF）、候选人确认回执、更新后的人力成本表
  • 建议模板/表单：
    • 录用审批单字段：候选人 ID、岗位名称、职级、用工类型、签约主体、挂靠团队、直属上级、面评链接、现薪与期望（区间）、拟定试用期时长与折扣、转正薪资、补贴项、生效月（写“X 月实发”）、是否超带宽及理由、竞争 offer 截止日、拟到岗日
    • 岗位薪酬带宽表字段：岗位族、职级、用工类型、地区（本地/远程）、薪资区间、试用期规则、标准补贴、可直接出价人
    • 录用通知书模板固定字段：岗位名称、主体、试用期、薪资结构、福利条款（AI 工具订阅等统一写入）、报到时间与材料

6. 异常与升级

  • 审批授权：带宽内由 HR 负责人与用人负责人确认后直接出价；技术岗超带宽由技术岗定薪审批人审批，跃竞岗位在已批 package 内由主体负责人审批；超出 package、负责人岗、跨主体发薪、实习转正 HC 及超档特批，一律由 CEO 终审
  • 期望明显超出带宽 → HR 先判断能否在带宽内说服；不能则由用人负责人说明破格理由走特批 → 2 个工作日无结论视为不批，转下一个候选人
  • 候选人有竞争 offer 且时间紧 → 审批标“加急” → 审批人当天处理，超时 HR 直接电话升级 CEO
  • 有人越过 HR 直接向候选人报价 → 以审批单为准，HR 当天提醒并在审批单备注 → 再次发生升级 CEO
  • 职能或岗位名称定不下来 → 暂停出薪，退回用人部门 → 2 个工作日未定升级兜底人
  • 跨主体发薪（合作方或子公司承担成本）→ 审批中加主体方确认节点 → 3 个工作日内未确认升级 CEO
  • 背调或资料核验发现经历不实 → 暂停发 offer，转 X-RCT-18 → 结论由用人负责人与 CEO 当天决定
  • 候选人入职后要求重谈待遇 → 不在本流程受理，转 HR-09 按调薪流程处理
  • 面试官 1 个工作日未出面评 → 招聘专员催办 → 升级用人部门负责人（第 2 个工作日）
  • 用人部门负责人 1 个工作日未定岗 → HR 负责人提醒 → 升级技术岗定薪审批人或主体负责人（第 2 个工作日）
  • 通知书审核超 1 个工作日 → HR 负责人电话提醒审核人 → 有竞争 offer 时当天升级 CEO
  • 面试官或用人部门问“出薪卡在哪”→ 先查候选人台账状态字段，不在群里追问（建议）

7. 衡量指标

  • 出薪周期 = 终面通过到录用通知书发出的工作日数，目标 ≤ 5 个工作日（加急 ≤ 2 个工作日）
  • 带宽内直出率 = 无需特批的录用数 / 录用总数，目标 ≥ 80%
  • offer 接受率 = 接受数 / 发出数，按岗位族每月统计
  • 通知书差错次数 = 因岗位名称、主体、薪资写错而重发的次数，目标 0
  • 口径冲突事件 = 同岗同级定薪偏离带宽且无审批理由的次数，目标 0

8. 低效诊断

  • 现象：没有岗位薪酬带宽表，每个候选人都要逐个请示决策人，等待审批成为常态（审批环节）｜依据：「技术岗招聘沟通」2026-01、「墨跃启智招聘」2026-02
  • 现象：同一岗位、同类实习生在不同时间被报出不同标准，再回头拉齐，候选人因此拒绝（定薪口径环节）｜依据：「技术岗招聘沟通」2026-03、「跃竞招聘群」2026-08
  • 现象：多个层级各自向候选人出价，HR 提醒“流程别乱了”（谈薪出口环节）｜依据：「模态人事大主管」2026-01
  • 现象：试用期长短与折扣、薪资生效月说法不统一，每次现问（条件口径环节）｜依据：「鼎慧人事」2026-01、「模态人事大主管」2026-02、「模态人事大主管」2026-03
  • 现象：职能未定就开始谈薪，高薪人选来回多日；岗位名称每次发 offer 前现问（定岗环节）｜依据：「鼎慧人事」2026-02、「模态人事大主管」2026-10
  • 现象：面完才发现期望超预算，前置的“预算内”确认不稳定（预筛环节）｜依据：「技术岗招聘沟通」2026-01
  • 现象：出薪卡在哪个环节没人知道，面试官追问（进度透明环节）｜依据：「系统测试招聘」2026-04
  • 现象：“谁来谈薪”“转正 HC 跟谁要”反复在群里问（职责环节）｜依据：「跃竞招聘群」2026-02、「墨跃启智招聘」2026-04
  • 现象：试用期标准提出要补进 SOP，但仍未成文（制度环节）｜依据：「技术岗招聘沟通」2026-05

9. 分支变体

  • 用工类型：全职社招（月薪 + 年终 + 补贴）；应届（控制留任薪资预期，避免提前拉高）；实习（研发实习按日薪档、产品实习按经验分档，前期统一试用标准后看表现评估）；兼职劳务；高端人才（工资可折算期权）
  • 审批授权：产研技术岗由创始人兼 CTO 定；非技术岗与实习生统一标准由 CEO 定；跃竞在已批 package 内由主体负责人直接定，超出再请示；产研侧集团定、市场侧由合作方按既定标准定
  • 实习转正：业务负责人先核算团队预算与收益，再报 CEO 审批 HC
  • 补充考核：高薪或偏市场/售前岗位，定薪前可加笔试（如评审一份 AI 生成的报告）
  • 负责人岗/子公司岗位：股权、分红由子公司承担，按子公司预算，必须人工逐案审批
  • 实习协议不写具体岗位；子公司员工由子公司出合同
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-04（跨部门交接契约）、ALL-09（状态看板与进度同步）

10. 待确认问题

  • 岗位薪酬带宽表由谁建、谁维护、谁可查看？首版能否在 1 个月内完成？
  • 带宽内 HR 直接出价的授权是否成立？超带宽审批链按 CTO/主体负责人 → CEO 是否正确？
  • 试用期统一为几个月、折扣统一为多少？实习生前期试用期限统一为几个月？
  • 录用通知书是否需要法务逐份审核，还是只审定模板、每份由用人负责人核对？
  • 合作方承担成本的岗位，审批节点放在哪一步？
  • 岗位名称字典和签约主体判定规则由谁维护（与 HR-04 如何分工）？
X-RCT-18拟录用背景调查待新建108

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗3 × 跨3 × 险4

  • 适用场景：候选人终面通过、薪资意向谈妥并口头接受后、正式发 offer 前，按岗位风险等级核实学历、工作经历、薪资流水和离职情况；或资料中出现疑点需要追加核实
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——用人部门负责人（当前：徐莉、王子明·推断待确认）、面试官（当前：葛家和、张东郅·推断待确认）、法务（当前：待指定）、背调结论决策人（当前：丁震宇·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 判定背调等级 → ② 取得候选人授权与材料 → ③ 材料一致性核验 → ④ 前司与学历核实 → ⑤ 疑点追加核实 → ⑥ 出背调结论表 → ⑦ 决策并归档
  • 交付结果：一份背调结论表（核实项、结果、疑点、结论：通过/有条件通过/不通过），作为发 offer 的前置条件留档
  • 状态依据：已有“先谈薪、确定入职再背调”的执行习惯和应聘登记表，但没有分岗位背调清单、触发点和结论留痕；2026-01～07 出现关键岗位靠提醒才背调、漏做被追问、可疑经历临时决定是否追加、复试通过后才发现经历不实

1. 场景判定

  • 触发条件：候选人已接受薪资意向、即将发 offer；财务、总助、核心技术负责人等关键岗位拟录用；非内推社招拟录用；简历出现两版不一致、薪资流水明显低于自述、短期任职疑似试用期未过、学历存疑
  • 典型说法：「先谈薪，接受确定入职再背调」「非内推的候选人背景调查需要更严格全面」「记得背调」「这位的背调也没做吧」「资料和背调核实都没问题」
  • 判断问题：这个人是否马上要发 offer？他所在岗位按清单属于哪一级背调？资料里有没有对不上的地方？
  • 不归本流程管：简历阶段的真实性核验与 AI 代答识别 → 请走 X-RCT-08；定薪与发 offer → 请走 X-RCT-17；入职后试用期考核 → 请走 HR-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
背调执行人 判定等级、收材料、联系前司、出结论表 R HR 负责人（当前：黄莹·推断待确认）
面试官 提供面评中记录的疑点，必要时补问 C 面试官（当前：葛家和、张东郅·推断待确认）
用人部门负责人 提出追加背调需求，参与有条件通过的判断 C 用人部门负责人（当前：徐莉、王子明·推断待确认）
结论决策人 对存疑结论做录用与否决定 A 创始人兼 CTO（当前：丁震宇·推断待确认）
法务 审定背调授权书与信息使用边界 C 法务（当前：待指定）
兜底 关键岗位存疑结论终审 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 背调等级清单（见步骤 1）与本岗位等级
  • 候选人签署的背调授权书、应聘登记表
  • 候选人提供的近 6 个月薪资流水、上家离职证明（或在职证明）、学历学位证书
  • 面评中记录的疑点、投递过的所有简历版本（从候选人台账查重带出）
  • 前司 HR 或直属上级的联系方式（由候选人提供并授权）；关键岗位的第三方背调服务账号

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定背调等级：A 级（财务、总助、核心技术负责人、高管、接触资金或保密信息）深度背调；B 级（非内推社招）标准背调；C 级（内推且前司规模较大）只核离职证明与学历；D 级（实习/应届）只核学历学籍 背调执行人 候选人接受薪资意向当天 背调清单 背调等级 🔧飞书固化
2 发送授权书和材料清单，候选人回传 背调执行人 判定后 1 个工作日内发出；候选人 3 个工作日内回传 飞书表单 / 邮件 授权书、材料包 🔧飞书固化
3 核对简历、应聘登记表、流水、离职证明的一致性（任职时间、职位、薪资）；比对多版简历 背调执行人 收到材料后 1 个工作日内 AI 比对 + 人工复核 一致性核验记录 🤖自动化
4 联系前司 HR/直属上级核实任职与离职原因；学历在官方平台核验；A 级可下单第三方背调或现场核查 背调执行人 B/C/D 级 3 个工作日内；A 级 5 个工作日内 电话 / 学历核验平台 / 第三方背调 核实记录 👤人工判断
5 对短期任职、流水偏低、两版简历对不上等疑点追加核实，必要时请面试官补问 背调执行人、面试官 发现后 2 个工作日内 电话 / 补面 疑点说明 👤人工判断
6 填写背调结论表：核实项、结果、疑点、结论（通过/有条件通过/不通过），附在候选人记录 背调执行人 核实完成当天 候选人台账 背调结论表 🔧飞书固化
7 通过的进入发 offer；有条件通过或不通过的发给结论决策人当面或书面决定，结论只陈述事实 结论决策人 收到结论表后 1 个工作日内 飞书审批备注 录用决定 👤人工判断

5. 交付物与模板

  • 交付物：背调授权书、材料包、背调结论表、决策记录
  • 建议模板/表单：
    • 背调结论表字段：候选人 ID、岗位、背调等级、核实项（学历/每段工作经历/薪资流水/离职证明/前司评价）、核实方式、核实对象岗位、结果（一致/不一致/无法核实）、疑点描述、结论、执行人、完成日期
    • 材料清单：身份证明、学历学位证书、近 6 个月薪资流水、离职证明、应聘登记表、背调授权书

6. 异常与升级

  • 升级条件：A 级岗位（财务、总助、核心技术负责人、高管等）出现“有条件通过/不通过/无法核实”结论，或结论决策人与用人部门意见不一 → 当天升级兜底（CEO）终审；其余岗位的存疑结论由结论决策人决定
  • 候选人拒绝授权或拒交流水 → 说明背调是录用前置条件 → 仍拒绝的，结论记“无法核实”，A/B 级岗位交结论决策人 1 个工作日内决定
  • 无法联系到前司（倒闭、前司负责人不配合）→ 改用社保缴纳记录、个税记录等替代材料 → 仍无法核实的交决策人
  • 发现经历或学历不实 → 立即暂停 offer → 当天报结论决策人，A 级岗位同时报 CEO
  • 候选人仍在职、担心惊动现单位 → 现单位核实延后到离职后、入职前完成，其余项先做 → 入职前仍未完成的，录用通知书注明“以背调通过为准”
  • 面试官私下向熟人打听候选人 → 结果只能作为线索，须由背调执行人正式核实后才写入结论

7. 衡量指标

  • 背调覆盖率 = 按等级完成背调的录用人数 / 应背调录用人数，目标 100%（A 级必须 100%）
  • 背调周期 = 授权材料齐全到出结论的工作日数，B/C/D 级 ≤ 3 天、A 级 ≤ 5 天
  • 入职后发现履历不实次数 = 入职后才发现与背调结论不符的人数，目标 0
  • 结论留痕率 = 有背调结论表的录用人数 / 已背调人数，目标 100%

8. 低效诊断

  • 现象：各岗位背调要求不一，有的免、有的深挖，全凭个案判断（标准环节）｜依据：「模态人事大主管」2026-01、「模态人事大主管」2026-02
  • 现象：关键岗位靠管理层提醒才想起要背调（触发环节）｜依据：「模态人事大主管」2026-03
  • 现象：已确定推进面试或录用时才发现背调没做（时机环节）｜依据：「跃竞招聘群」2026-03
  • 现象：疑似短期任职是否追加背调，需在群里临时讨论（疑点处理环节）｜依据：「跃竞招聘群」2026-01
  • 现象：背调结果只口头回报一句“没问题”，没有结论留档（留痕环节）｜依据：「跃竞招聘群」2026-03
  • 现象：复试已通过后才发现工作经历不实，前置核验不足（核验环节）｜依据：「薪酬对接群」2026-09

9. 分支变体

  • 内推候选人：原则上同样背调；前司规模较大的可只核离职证明与学历（C 级）
  • 财务、总助、高管、核心技术负责人：A 级深度背调，可用第三方背调或现场核查
  • 涉及竞争业务的岗位（如游戏业务相关）：A 级背调时加查是否来自直接竞争对手、有无竞业限制
  • 实习生/应届生：以学历学籍核验为主（D 级）
  • 仍在职候选人：现单位核实放到离职后、入职前

10. 待确认问题

  • A/B/C/D 四级的岗位划分是否认可？内推候选人是否一律降为 C 级？
  • 是否采购第三方背调服务？预算与适用岗位范围？
  • 背调授权书是否需要法务出标准文本？背调材料保存期限多久？
  • 存疑结论的决策人：技术岗由创始人兼 CTO、其他岗位由 CEO，是否可行？
  • 背调是否必须在发 offer 前完成，还是允许“以背调通过为准”的附条件 offer？
X-RCT-19录用确认到入职衔接待新建144

状态：待新建｜证据：有证据（卡片 3 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨4 × 险3

  • 适用场景：候选人接受 offer 后到入职首日之间，确认到岗日期、用工形式、挂靠团队、直属上级与带教人、座位、设备与账号，完成交接并发出入职欢迎
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡、王丽菲·推断待确认）、用人部门负责人（当前：丁震宇、陈子康·推断待确认）、带教人（当前：岳阳、王皓南、杨萌、李凯·推断待确认）、座位与行政协调（当前：杨萌·推断待确认）、IT 账号开通（当前：待指定）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 书面确认到岗日期与用工形式 → ② 定挂靠团队、直属上级与带教人 → ③ 自动派发入职任务清单 → ④ 到岗前 1 天提醒候选人 → ⑤ 首日交接给带教人 → ⑥ 首个任务与首周跟进
  • 交付结果：候选人到岗确认记录、已全部关闭的入职任务清单（座位、设备、账号权限、带教人、首个任务），新人按时到岗并被带教人接住
  • 状态依据：录用与入职衔接散落在群聊口头确认；2026-06～10 挂哪个组、谁带、坐哪里每次现问约 5 次，入职日期口头确认无交接清单，候选人信息在非招聘群流转，多名实习生同日到岗座位紧张

1. 场景判定

  • 触发条件：候选人回复接受 offer；负责人宣布“那就招/安排入职”；实习生确定到岗时间；候选人提出延期或犹豫
  • 典型说法：「安排入职」「他主要跟谁对接工作呀，安排坐哪里」「他下周二入职」「明天要来三个实习」「最早 7 月 20 号能线下到岗」
  • 判断问题：候选人是否已接受 offer、还没到岗？现在要做的是不是“让他到岗那天有人接、有座位、有账号、有活干”？
  • 不归本流程管：定薪与 offer 发放 → 请走 X-RCT-17；入职手续、合同签署与资料收集 → 请走 HR-05 / HR-04；入职培训与首周带教内容 → 请走 HR-06；实习生在岗管理与离岗 → 请走 HR-07；员工内推受理 → 请走 X-RCT-06

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
入职衔接负责人 确认到岗、派发任务清单、跟踪关闭 R/A HR 负责人（当前：黄莹·推断待确认）
招聘专员 与候选人确认到岗时间、实习周期、到岗提醒 R HR 招聘专员（当前：张欣怡、王丽菲·推断待确认）
用人部门负责人 定挂靠团队、直属上级、带教人和首个任务 R 用人部门负责人（当前：丁震宇、陈子康·推断待确认）
带教人 首日接人、安排首个任务、首周跟进 R 带教人（当前：岳阳、王皓南、杨萌、李凯·推断待确认）
座位与行政协调 安排座位、工牌、门禁 R 座位与行政协调（当前：杨萌·推断待确认）
IT 账号开通 飞书账号、代码仓库与内网权限、设备 R IT 账号开通（当前：待指定）
兜底 带教人或挂靠团队有分歧时拍板 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 已审批的录用审批单与候选人确认回执（岗位、主体、用工类型、到岗日期）
  • 候选人到岗前需要确认的信息：实习周期、每周出勤天数、课程冲突、能否线下
  • 团队-负责人对照表（如开放平台、Leap、FDE 等各自负责人）
  • 座位图与空位情况；设备库存
  • 入职任务清单模板（见第 5 节）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 以邮件或飞书书面确认到岗日期、用工形式、实习周期与出勤安排，写入候选人记录 招聘专员 候选人接受 offer 后 1 个工作日内 邮件 / 候选人台账 到岗确认记录 🔧飞书固化
2 确定挂靠团队、直属上级、带教人和首个任务（实习生先给独立、非关键任务观察） 用人部门负责人 到岗确认后 1 个工作日内 入职任务清单 带教安排 👤人工判断
3 自动派发入职任务：座位与工牌（行政）、设备与账号权限（IT）、带教准备（带教人）、入职手续（HR），每项带截止时间 入职衔接负责人 到岗前 3 个工作日内派发；各项到岗前 1 个工作日内关闭 飞书任务 / 多维表格 任务清单 🔧+🤖
4 机器人检查同日到岗人数与空位，冲突时提醒行政调整或错开到岗日 座位与行政协调 派发当天 多维表格 座位安排 🤖自动化
5 向候选人发到岗提醒：时间、地点、联系人、需带材料 招聘专员 到岗前 1 个工作日 短信 / 邮件模板 到岗提醒 🤖自动化
6 首日 HR 办手续后把新人交给带教人；在所属部门群发欢迎（只写姓名、岗位、带教人） HR 负责人、带教人 到岗首日上午 部门群 交接完成 👤人工判断
7 带教人确认首个任务已布置，首周末反馈一次适应情况 带教人 首日内布置；首周最后一个工作日反馈 飞书任务 首周反馈 🔧飞书固化

5. 交付物与模板

  • 交付物：到岗确认记录、入职任务清单（全部关闭）、首周反馈
  • 建议模板/表单：
    • 入职任务清单字段：候选人 ID、到岗日期、用工类型、挂靠团队、直属上级、带教人、首个任务、座位号、工牌/门禁、设备、飞书账号、代码仓库/内网权限、各项负责人、截止时间、完成状态
    • 到岗提醒模板：到岗时间、地址、接待联系人岗位、需携带材料、首日安排

6. 异常与升级

  • 升级条件：挂靠团队或带教人到岗前 2 个工作日仍未定、账号设备超过 1 个工作日未就绪 → 入职衔接负责人升级兜底（创始人兼 CTO）拍板；其余衔接事项由入职衔接负责人直接协调
  • 候选人犹豫或多次改主意 → 招聘专员 1 个工作日内确认最终答复 → 仍不确定的尊重候选人，回到候选人台账结案，通知用人部门启动下一位
  • 候选人延期到岗 → 书面确认新日期，同步调整任务清单 → 延期超过 2 周报用人部门负责人决定是否保留
  • 挂靠团队或带教人定不下来 → 到岗前 2 个工作日仍未定，升级创始人兼 CTO 当天拍板
  • 座位不足 → 行政协调临时工位或错开到岗日 → 无法解决升级 HR 负责人
  • 账号、设备首日未就绪 → IT 当天补齐 → 超过 1 个工作日升级兜底人
  • 候选人个人信息、简历被发到非招聘群或闲聊群 → 立即提醒撤回 → 再次发生报 HR 负责人
  • 候选人在外部平台发布与公司相关内容 → 转品牌部门评估雇主口碑回应，不在招聘群讨论

7. 衡量指标

  • 首日就绪率 = 到岗首日座位、账号、带教人全部就绪的人数 / 当月到岗人数，目标 ≥ 95%
  • 到岗确认书面率 = 书面确认到岗日期的人数 / 接受 offer 人数，目标 100%
  • 接受后未到岗率 = 接受 offer 后未到岗人数 / 接受 offer 人数，按月统计
  • 群内“谁带/坐哪/挂哪组”询问次数，目标每月 ≤ 1 次

8. 低效诊断

  • 现象：新人挂哪个组、跟谁对接、谁带教每次现问（团队与带教分配环节）｜依据：「技术岗招聘沟通」2026-07、「技术录用沟通」2026-10
  • 现象：入职日期在闲聊中口头确认，没有入职交接清单（到岗确认环节）｜依据：「随便瞎聊啦～」2026-08
  • 现象：多名实习生同日到岗，座位临时协调（资源准备环节）｜依据：「技术岗招聘沟通」2026-07
  • 现象：候选人信息和简历在闲聊群传播（信息管控环节）｜依据：「随便瞎聊啦～」2026-08、「鸽子群模态分群」2026-07
  • 现象：候选人多次改变决定，后续安排反复（录用确认环节）｜依据：「技术录用沟通」2026-10
  • 现象：雇主口碑内容（外部平台搜索结果）无人负责（雇主品牌环节）｜依据：「随便瞎聊啦～」2026-08
  • 现象：实习生离岗靠群里道别，无交接（离岗衔接环节）｜依据：「鸽子群模态分群」2026-07

9. 分支变体

  • 正式员工：完整任务清单，含合同与社保（HR-04/HR-05）
  • 暑期实习/长期线上实习/远程实习：远程实习免座位与工牌，需开通远程权限与线上带教频次；实习生先做独立非关键任务观察，表现优秀才考虑转正
  • 内推候选人：衔接时同步内推人，便于后续内推奖励核算
  • 实习生带教统一分配：由创始人兼 CTO 或用人部门负责人统一指定，不由实习生自行找人

10. 待确认问题

  • 座位、工牌由行政负责还是由团队负责人协调？行政对接岗位是谁？
  • IT 账号与权限开通由哪个岗位负责？是否已有开通清单？
  • 带教人由用人部门负责人指定，还是统一由创始人兼 CTO 分配？
  • 雇主品牌（外部平台公司口碑内容）由哪个部门负责？
  • 入职任务清单是否与 HR-05 的入职准备清单合并为同一张表？
X-RCT-20实习生、兼职与校园招聘待新建72

状态：待新建｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨4 × 险2

  • 适用场景：业务组需要长期实习生、暑期实习生、远程实习生或短期兼职；或有高校合作批量实习机会、校园宣讲、熟人推荐、开源社区与黑客松等来源的实习候选人，需要快速汇总需求、筛选、简化面试并录用
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员（当前：张欣怡·推断待确认）、用人部门负责人（当前：杨萌、张东郅、陈梦琪、徐莉、李鹏为·推断待确认）、高校合作发起人（当前：邴龙志·推断待确认）、宣讲人与宣讲材料（当前：马漳毓、李铭熙、王皓南·推断待确认）、市场岗初面（当前：杨朋伟、闫登辉·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 用人部门提交实习/兼职用工申请 → ② HR 汇总需求（高校批次导出给学院）→ ③ 多渠道收简历统一入台账 → ④ HR 硬条件预筛 → ⑤ 30 分钟简化面试 → ⑥ 1 个工作日内出结论 → ⑦ 按实习生标准出薪 → ⑧ 转入职衔接
  • 交付结果：实习/兼职需求汇总表、按期到岗的实习生或兼职人员（含带教人与任务说明），高校批次的岗位需求清单与反馈记录
  • 状态依据：已有高校实习需求飞书表格，但需求口径、简历流转、面试和录用全靠群聊临时推动；2026-01～07 出现用人需求未事先说明、宣讲临时抓人、简历经微信转发、兼职需求晚间临时提出次日要人、实习要求口头变化等情况

1. 场景判定

  • 触发条件：业务组提出实习或兼职用人需求；高校或学院提供批量实习机会；校园宣讲排期；熟人、开源社区、黑客松、其他岗位转介实习候选人；业务杂活堆积需要短期兼职承接
  • 典型说法：「你们列一下岗位需求，我发过去」「列一下要求，报 HR」「帮教育组快速招几个兼职」「先来个简历」「实习生半个小时就行了」「有一个实习生直接走入职流程，看下怎么走」「测试小弟招哪去了」
  • 判断问题：要招的是不是实习生、兼职或校园批量人选？用人部门是否已经写清任务、周期和带教人？
  • 不归本流程管：全职社招需求与 HC → 请走 X-RCT-01；常规简历初筛与分发 → 请走 X-RCT-07；实习生定薪超出标准档 → 请走 X-RCT-17；实习生到岗衔接 → 请走 X-RCT-19；实习生在岗管理、考勤与离岗 → 请走 HR-07；跨组候选人转推 → 请走 X-RCT-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
用人部门负责人 提交用工申请（任务、周期、出勤、带教人），主持简化面试，决定录用 R 用人部门负责人（当前：杨萌、张东郅、陈梦琪、徐莉、李鹏为·推断待确认）
HR 负责人 汇总需求、统一入口、硬条件预筛、出薪、市场实习二面 R/A HR 负责人（当前：黄莹·推断待确认）
招聘专员 收简历、确认到岗时间与课程冲突、约面 R HR 招聘专员（当前：张欣怡·推断待确认）
高校合作发起人 对接学院、发起批量实习机会 C 高校合作发起人（当前：邴龙志·推断待确认）
宣讲人 校园宣讲执行与材料准备 R 宣讲人与宣讲材料（当前：马漳毓、李铭熙、王皓南·推断待确认）
市场岗初面 市场实习生初面 R 市场岗初面（当前：杨朋伟、闫登辉·推断待确认）
兜底 需求优先级与实习生统一标准拍板 A（升级） CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 实习/兼职用工申请（类型、任务说明、班次或每周出勤天数、周期、到岗时间、带教人、保密要求、预算档）
  • 该任务已有的操作 SOP 或说明文档（杂活类兼职必须先有，再招人）
  • 实习生统一标准：实习期不少于 6 个月、每周出勤不少于 4 天、薪资档（按岗位类型）
  • 校园宣讲：宣讲排班表、宣讲 PPT（末页放招聘联系方式，使用公司招聘账号而非个人联系方式）
  • 实习生面试简表（30 分钟版评价项）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交实习/兼职用工申请，区分长期/暑期短期/远程/兼职，写清任务与带教人；杂活类先附操作说明 用人部门负责人 期望到岗前 10 个工作日（兼职应急前 3 个工作日） 飞书审批 / 表单 用工申请 🔧飞书固化
2 汇总各组需求到同一张多维表格；高校批次按学院要求导出字段发给学院初筛 HR 负责人 每月第 1 周；高校批次收到后 3 个工作日内 多维表格 需求汇总表 🤖自动化
3 多渠道收简历（校园宣讲、学院初筛、熟人/开源社区推荐、黑客松现场、其他岗位转介），全部录入候选人台账并标注来源，不在群里传简历文件 招聘专员 收到当天 候选人台账 实习候选人记录 🔧飞书固化
4 硬条件预筛：实习周期、每周出勤、到岗时间、课程冲突、能否线下；不满足 6 个月的长期实习需求直接说明 招聘专员 录入后 1 个工作日内 电话 / 表单 预筛结果 🤖自动化
5 简化面试：用人部门 1 轮约 30 分钟；市场实习生由业务初面、HR 二面 用人部门负责人 / HR 负责人 预筛通过后 3 个工作日内完成 飞书会议 / 线下 面试简评 👤人工判断
6 出结论并回写台账；熟人或高管推荐的，同步反馈给推荐人 用人部门负责人 面试后 1 个工作日内 候选人台账 录用结论 🔧飞书固化
7 按实习生标准档出薪并发录用通知（超出标准档转 X-RCT-17 审批） HR 负责人 结论后 1 个工作日内 通知模板 实习录用通知 🔧+👤
8 校园宣讲：提前排定宣讲人与备份人，材料由用人方提供 用人部门负责人 宣讲前 10 个工作日定人；前 3 个工作日定稿 排班表 宣讲安排 🔧飞书固化
9 转入职衔接（X-RCT-19）与实习生管理（HR-07） 招聘专员 候选人接受当天 任务清单 入职任务 🔧飞书固化

5. 交付物与模板

  • 交付物：用工申请、实习/兼职需求汇总表、候选人记录与面试简评、实习录用通知、宣讲排班表
  • 建议模板/表单：
    • 实习/兼职用工申请字段：用人部门、用工类型（长期实习/暑期实习/远程实习/兼职）、人数、任务说明与操作文档链接、班次或每周出勤天数、周期、期望到岗日、学历专业要求、带教人、保密要求、薪资档
    • 实习生面试简表：基础能力、岗位认知、稳定性（周期与课程）、到岗时间、结论与理由

6. 异常与升级

  • 升级条件：多个组的实习/兼职需求冲突需排优先级、实习生统一标准（周期、出勤、薪资档）需调整或破例 → HR 负责人升级兜底（CEO）拍板；标准内的录用由 HR 负责人与用人部门负责人直接办理
  • 用人需求未写清任务和带教人 → HR 退回申请，不启动招聘 → 2 个工作日仍未补齐，报该部门负责人的上级
  • 应急兼职需在 3 个工作日内到位 → HR 优先从学生渠道招募，用人部门当天补全需求 → 3 个工作日未到位，与用人部门商定替代方案并报兜底人
  • 候选人周期不足 6 个月或出勤不足 → 原则上不录用；确需例外的由用人部门负责人说明理由，HR 负责人批准
  • 候选人未通知即未到场 → 台账记“失联”结案 → 同一来源反复出现，反馈给推荐人或渠道
  • 宣讲人临时无法出席 → 启用排班表备份人 → 备份也无法出席时当天报用人部门负责人
  • 兼职人员接触内部文件 → 文件只在飞书内发放，按保密要求设置权限

7. 衡量指标

  • 实习需求满足周期 = 用工申请提交到实习生到岗的自然日数，目标长期实习 ≤ 20 天、兼职应急 ≤ 3 个工作日
  • 实习简化面试结论时效 = 面试后 1 个工作日内出结论的比例，目标 ≥ 95%
  • 实习生按期留存率 = 完成约定周期的实习生数 / 到岗实习生数，目标 ≥ 80%
  • 群内传简历文件次数，目标 0

8. 低效诊断

  • 现象：熟人推荐实习时用人需求和岗位没有事先说明，临时判断“要不要”（需求环节）｜依据：「鼎慧产研决策部」2026-07
  • 现象：高校批量实习需要多轮汇总各组需求，简历通过微信转给学院（需求汇总与简历流转环节）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-04
  • 现象：校园宣讲临时找人替代，宣讲人当场指定（宣讲排期环节）｜依据：「Leap产研测」2026-05
  • 现象：兼职需求晚间临时提出、次日要人，业务需求未明确前 HR 无法开始（应急招募环节）｜依据：「墨跃启智招聘」2026-03
  • 现象：实习生周期、学校、出勤等要求口头变化，候选人不通知就不到场（预筛环节）｜依据：「系统测试招聘」2026-06、「系统测试招聘」2026-07
  • 现象：实习生面试信息只在日报中零散出现，没有反馈记录（面试记录环节）｜依据：「【模态】市场销售」2026-04、「【模态】市场销售」2026-05
  • 现象：实习生面试通过后入职流程多久没人说得清，靠催（入职衔接环节）｜依据：「Leap产研测」2026-06

9. 分支变体

  • 长期实习（不少于 6 个月、每周不少于 4 天）/ 暑期短期实习（原则上不招，确有任务的走例外审批）/ 远程实习
  • 高校批量实习：按飞书表格汇总岗位需求导出给学院，学院初筛后统一安排面试
  • 市场实习生：业务初面 + HR 二面
  • 测试实习：可接收研发岗、产品岗、黑客松现场的简历转介，由测试负责人面试
  • 短期兼职：学生优先，分白班/晚班，3 个工作日内到位；杂活先沉淀 SOP 再招人，实习生按 SOP 执行而不是由实习生形成 SOP
  • 主体：模态、鼎慧、跃竞的实习生统一标准，薪资档按岗位类型区分

10. 待确认问题

  • 实习期不少于 6 个月、每周出勤不少于 4 天是否作为硬性标准写入制度？
  • 暑期短期实习是否一律不招，还是按任务例外审批？
  • 实习/兼职用工申请是否需要审批？审批人是用人部门负责人还是 CEO？
  • 校园宣讲由 HR 统筹还是由用人部门自行安排？
  • 高校合作的对接窗口固定为哪个岗位？
X-RCT-21急岗推进、招聘进度同步与漏斗复盘待优化180

状态：待优化｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：关键岗位被定为急岗（如 Agent 负责人、Agent 全栈、子公司技术负责人、后端、产品），或业务负责人关心招聘进度、春节前/月初到岗节点需要汇总漏斗，或连续面试通过率过低需要复盘渠道和面试策略
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——技术招聘筛选与笔试（当前：陈晖·推断待确认）、HR 招聘专员（当前：张欣怡、陈雁、匡蓉·推断待确认）、用人部门负责人（当前：王皓南、徐莉、杨萌·推断待确认）、面试官（当前：望政韬、吴世豪·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 定急岗等级与目标 → ② 建岗位×阶段看板 → ③ 按流水线推进（收→筛→笔试→面试）→ ④ 急岗每日、常规岗每周自动推送进度 → ⑤ 超时自动提醒 → ⑥ 节点汇总 → ⑦ 月度或触发式漏斗复盘 → ⑧ 策略调整与 HC 变更留痕
  • 交付结果：实时招聘看板、急岗日报与常规周报、月度漏斗复盘纪要（数据、共性问题、调整动作）
  • 状态依据：急岗流水线（收简历、筛简历、派笔试、排面试）已明确，也做过一次完整漏斗统计，但进度靠群里每天追问、HR 临时汇总，没有看板和固定同步节奏；2026-01～08 群里催问进度约 25 次以上，出现“完全没进度”、消息无人回复

1. 场景判定

  • 触发条件：岗位被定为 P0/第一优先级；业务负责人询问进度；春节前、月初、项目启动前需要到岗；某岗位连续两周进面率或面试通过率明显偏低；简历池枯竭；HC 数量调整
  • 典型说法：「每天同步一下急岗招聘进展」「流水线一点：收简历、筛简历、派笔试、排面试」「招人进度咋样了」「很急，这个优先级 P0」「池子里没有鱼了」「简历-录用率 2.27%」
  • 判断问题：要回答的是不是“这个岗位现在走到哪了、为什么慢、接下来怎么调”？
  • 不归本流程管：HC 申请与优先级审批 → 请走 X-RCT-01；渠道拓展与物料 → 请走 X-RCT-04；主动寻访 → 请走 X-RCT-05；笔试题目设计 → 请走 X-RCT-10；面试官培养与考察标准 → 请走 X-RCT-13；单个候选人状态维护 → 请走 X-RCT-16

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
进度负责人 维护看板、发日报周报、节点汇总、组织复盘 R/A HR 负责人（当前：黄莹·推断待确认）
招聘专员 收简历、约笔试和面试、更新阶段 R HR 招聘专员（当前：张欣怡、陈雁、匡蓉·推断待确认）
技术筛选与笔试 技术岗简历筛选、派笔试与评分、漏斗统计与复盘材料 R 技术招聘筛选与笔试（当前：陈晖·推断待确认）
用人部门负责人 定急岗目标、二面、参与复盘、确认策略调整 R/C 用人部门负责人（当前：王皓南、徐莉、杨萌·推断待确认）
面试官 按时完成面试与面评，复盘中提供面试观察 C 面试官（当前：望政韬、吴世豪·推断待确认）
兜底 急岗定级、HC 调整、跨部门资源协调 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 在招岗位清单及优先级（P0/P1/P2）、HC 数量、目标到岗日
  • 候选人台账（X-RCT-16）已按阶段更新
  • 急岗的阶段目标（如“某日前 N 人进入二面”）
  • 漏斗口径：简历数 → 初筛通过 → 笔试 → 进面 → 面试通过 → offer → 到岗
  • 上一期复盘纪要与调整动作清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 定急岗等级、阶段目标（时间 + 人数）、主面试官与二面人 用人部门负责人提出，兜底（创始人兼 CTO）确认 急岗提出当天 飞书任务 急岗卡片 👤人工判断
2 建立/更新岗位×阶段看板，数据直接取自候选人台账 HR 负责人 急岗提出后 1 个工作日内 多维表格仪表盘 招聘看板 🤖自动化
3 按流水线推进：新简历 1 个工作日内筛完；通过即当天派笔试；笔试合格 2 个工作日内排面试；技术岗先笔试后面试，统一主面，二面人看面评 招聘专员、技术筛选与笔试 见动作栏 招聘系统 / 笔试系统 / 飞书日程 推进记录 🔧+🤖
4 急岗每个工作日 18:00、常规岗每周一 10:00 机器人推送进度到招聘群；HR 补一句当天卡点 HR 负责人 按推送时间 飞书机器人 日报 / 周报 🤖自动化
5 超时提醒：简历超 1 个工作日未筛、面评超 1 个工作日未交、候选人超 3 个工作日无动作，自动 @ 责任人 招聘系统 实时 飞书机器人 催办消息 🤖自动化
6 节点汇总（春节前、月初、项目启动前）：按岗位输出待二面/待一面/待联系/待筛选数量与预计到岗 HR 负责人 节点前 3 个工作日 看板导出 节点小结 🤖自动化
7 漏斗复盘：每月第 1 周例行一次；某岗位连续两周进面率低于上月一半或面试多为无效（代答、明显不匹配）时立即触发；AI 汇总面试摘要与共性问题 技术筛选与笔试、HR 负责人 每月第 1 周；触发后 3 个工作日内 复盘模板 + AI 摘要 复盘纪要 🔧+🤖
8 落实调整动作（改 JD、换渠道、前置电话面或笔试、缩短无效面试时长）并记录；HC 增减走审批留痕 用人部门负责人、HR 负责人 复盘后 5 个工作日内 飞书任务 / 审批 调整记录 👤人工判断

5. 交付物与模板

  • 交付物：招聘看板、急岗日报、常规周报、节点小结、月度漏斗复盘纪要
  • 建议模板/表单：
    • 看板字段：岗位、优先级、HC、目标到岗日、各阶段人数、本周新增简历、平均每阶段停留天数、卡点说明、负责招聘专员、主面试官
    • 复盘纪要字段：统计周期、各阶段人数与转化率（进面率、面试通过率、简历-录用率）、无效面试占比、共性问题、渠道表现、调整动作、负责人、完成日期

6. 异常与升级

  • 升级条件：急岗定级、HC 增减、急岗 1 周无改善需跨部门调资源 → 进度负责人升级兜底（创始人兼 CTO）拍板；看板维护、同步节奏和复盘组织由进度负责人直接决定
  • 业务负责人发消息询问进度、HR 超过半个工作日未回复 → 先查看板；看板未能回答的，HR 当天回复 → 次日仍无回复升级 HR 负责人
  • 急岗连续 3 个工作日无新进面 → HR 与用人负责人当天碰头，启用主动寻访或内推加码 → 1 周无改善升级创始人兼 CTO
  • 简历池枯竭 → 当周扩展渠道或调整 JD → 两周仍无新增，复盘岗位定位与薪资
  • HC 临时暂停或增加 → 走审批并同步看板，暂停岗位的待面者由招聘专员 1 个工作日内告知
  • 面试官因排期堵塞拖慢流程 → 增补面试官 → 报用人部门负责人当天调整

7. 衡量指标

  • 简历-进面率、简历-录用率：按岗位每月统计，作为渠道与 JD 质量基线（参考：某技术岗年初一轮统计为进面率约 12%、简历-录用率约 2%）
  • 急岗关闭周期 = 急岗提出到候选人接受 offer 的自然日数，目标 ≤ 30 天
  • 简历处理时效 = 1 个工作日内完成初筛的简历比例，目标 ≥ 90%
  • 群内催问进度次数 = 每月业务方在群里询问进度的次数，目标逐月下降
  • 复盘按期率 = 按月完成复盘的次数 / 应完成次数，目标 100%

8. 低效诊断

  • 现象：招聘进度靠业务方在群里追问，回答“完全没进度”，发给 HR 的消息无回复（进度透明环节）｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：急岗每天在群里追问进展，日报靠人工整理（同步环节）｜依据：「技术岗招聘沟通」2026-05
  • 现象：业务方反复问“最近有更新吗、很急”，每次都要临时统计各岗位漏斗（汇总环节）｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-06、「跃竞招聘群」2026-08
  • 现象：节点小结只在春节前做过一次，之后没有周期性同步（节奏环节）｜依据：「跃竞招聘群」2026-02
  • 现象：低质量和代答候选人大量消耗面试时间，十个里只有少数真人后才调整流程（复盘触发环节）｜依据：「技术岗招聘沟通」2026-01、「技术岗招聘沟通」2026-02
  • 现象：速结与完整面试观点冲突，策略调整没有固定评审（复盘决策环节）｜依据：「技术岗招聘沟通」2026-03
  • 现象：HC 反复调整、简历池枯竭后才调整渠道（HC 与渠道环节）｜依据：「技术岗招聘沟通」2026-05、「技术岗招聘沟通」2026-06

9. 分支变体

  • 急岗：Agent 负责人、Agent 全栈、招投标方向负责人、子公司技术负责人——每日同步，必要时周末收简历、发笔试
  • 常规岗：后端、前端、UI、产品、AI、测试、运维、交付各自维护漏斗，每周同步
  • 跃竞（协游）岗位：由主体负责人定月度优先级，HR 按其优先级推送
  • 高管岗：进度同步对象限定为发起人与 HR 负责人（见 X-RCT-23）

10. 待确认问题

  • 急岗认定由谁拍板？是否需要走审批留痕？
  • 急岗每日同步、常规岗每周同步的时间点是否合适？推送到哪个群？
  • 周末加班推进急岗是否作为常规要求？如何补偿？
  • 漏斗复盘由 HR 负责人组织，还是由各条线招聘主力各自组织？
  • 急岗关闭周期目标 30 天是否可行？
X-RCT-22招聘团队分工与交接待新建72

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：招聘执行人员（招聘专员、招聘助理）或岗位面试官更换、新主体或新项目组开始招聘、职责边界不清（谁筛简历、谁约面、谁谈薪、谁背调）时，重新界定分工并完成候选人与台账交接
  • 负责人：主责——HR 负责人（当前：黄莹·推断待确认）；协同——HR 招聘专员/招聘助理（当前：张欣怡、匡蓉、陈雁·推断待确认）、主体业务负责人（当前：徐莉·推断待确认）、各岗位面试官（当前：王子明、张楠、魏小东、段涵、陈晖、康紫馨、宫经喜·推断待确认）；兜底——创始人兼 CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 识别人员变动或职责空白 → ② 更新招聘分工矩阵 → ③ 群公告置顶 → ④ 交接在途候选人与账号权限 → ⑤ 新成员开权限 → ⑥ 双方确认交接 → ⑦ 一周后回查
  • 交付结果：最新版招聘分工矩阵（岗位 → 简历筛选人 → 一面 → 二面 → 谈薪人 → 背调人 → offer 发放人）、交接清单与确认记录
  • 状态依据：没有岗位-人员职责矩阵，分工靠群里一句话宣布；2026-01～07 招聘执行人员多次更替，“简历发给谁看”“谁来面”“谁来谈薪”反复出现约 12 次，新人看不到前情、简历发错群，HR 同时服务多个主体成为单点

1. 场景判定

  • 触发条件：招聘专员或招聘助理入职、离职、转岗；某岗位面试官更换；新主体、新项目组开始招聘；群里出现“这份简历发给谁”“谁来面”“谁来谈薪”且 1 个工作日内没人认领
  • 典型说法：「这边测试简历发给谁来看呀」「后续有人面试由我们两位来负责，推荐人暂不负责后续流程了」「以后招人的事，我们仨在群里说吧」「给你开了权限啦，现在能看到不」
  • 判断问题：问题是不是出在“这件事该谁做”而不是“这件事怎么做”？
  • 不归本流程管：单个候选人的跨组转推与归属 → 请走 X-RCT-14；面试官培养与考察标准 → 请走 X-RCT-13；招聘账号与签约主体 → 请走 X-RCT-03；HR 员工本人离职手续 → 请走 HR-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
分工矩阵负责人 维护矩阵、组织交接、确认无遗漏 R/A HR 负责人（当前：黄莹·推断待确认）
交出方/接手方 整理并接收在途候选人、账号、待回复事项 R HR 招聘专员/招聘助理（当前：张欣怡、匡蓉、陈雁·推断待确认）
主体业务负责人 确认本主体各岗位面试官与谈薪授权 C 主体业务负责人（当前：徐莉·推断待确认）
岗位面试官 确认自己负责的岗位与轮次 C 各岗位面试官（当前：王子明、张楠、魏小东、段涵、陈晖、康紫馨、宫经喜·推断待确认）
兜底 分工争议拍板、HR 带宽不足时决定增员 A（升级） 创始人兼 CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 当前在招岗位清单（按主体：模态、鼎慧、跃竞、教育项目组等）
  • 现行分工（谁筛、谁约、谁一面二面、谁谈薪、谁背调、谁发 offer）
  • 交出方名下在途候选人清单（从候选人台账筛出）、待回复候选人、已约未面的日程
  • 招聘账号、招聘群、台账、招聘系统的权限清单

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 识别变动：人员变更或连续出现无人认领的简历/面试 HR 负责人 变动确定当天 招聘群 变动说明 👤人工判断
2 更新分工矩阵，逐岗位写明各环节负责人与备份人，主体业务负责人确认 HR 负责人 变动后 1 个工作日内 多维表格 新版分工矩阵 🔧飞书固化
3 在相关招聘群发公告并置顶矩阵链接，说明生效日期 HR 负责人 矩阵确认当天 群公告 公告 🔧飞书固化
4 交出方导出名下在途候选人、待回复事项、已约日程、渠道账号，逐条交给接手方 交出方 变动后 3 个工作日内（离职的在最后工作日前） 候选人台账筛选视图 交接清单 🤖自动化
5 给接手方和新面试官开通群历史消息、台账、招聘系统权限；收回离开人员权限 HR 负责人 交接开始当天 飞书群设置 / 系统权限 权限变更记录 🔧飞书固化
6 接手方逐条确认在途候选人并在台账改为本人负责；交出方与接手方在交接清单上确认 接手方 交接清单收到后 2 个工作日内 候选人台账 交接确认 👤人工判断
7 一周后回查：是否还有候选人无负责人、简历发错群 HR 负责人 交接完成后 5 个工作日 台账视图 回查结果 🤖自动化

5. 交付物与模板

  • 交付物：招聘分工矩阵、交接清单、权限变更记录
  • 建议模板/表单：
    • 分工矩阵字段：主体、岗位、简历来源与上传人、简历筛选人、一面面试官、二面面试官、谈薪人、背调人、offer 发放人、备份人、对应招聘群、生效日期
    • 交接清单字段：候选人 ID、岗位、当前阶段、下一步动作、截止时间、候选人已被告知的信息、交出方、接手方、确认时间

6. 异常与升级

  • 升级条件：主体之间对分工有争议、HR 带宽不足需要增员 → 分工矩阵负责人升级兜底（创始人兼 CTO）拍板；矩阵更新与交接由分工矩阵负责人直接组织
  • 简历或面试 1 个工作日无人认领 → HR 负责人按矩阵指派 → 矩阵里没有该岗位的，当天报主体业务负责人补齐
  • 交出方已离开、交接不完整 → HR 负责人从台账导出在途候选人逐一联系 → 3 个工作日内完成补救
  • 同一候选人在多个群被不同人沟通 → 以矩阵指定的负责人为唯一对接人，其他人停止直接沟通
  • 简历发到非对应群 → 当事人撤回并改发对应群或台账 → 再次发生 HR 负责人提醒
  • HR 负责人同时承担多个主体、积压明显 → 报创始人兼 CTO 决定增设 HR 助理或用 AI 承担初筛、日程与提醒

7. 衡量指标

  • 分工矩阵覆盖率 = 矩阵中各环节已指定负责人的在招岗位数 / 在招岗位总数，目标 100%
  • 无人认领事件 = 每月出现“发给谁/谁来面/谁谈薪”且超过 1 个工作日无人处理的次数，目标 0
  • 交接遗漏数 = 交接后一周回查发现的无负责人候选人数，目标 0
  • HR 人均在招岗位数，作为是否增员的参考

8. 低效诊断

  • 现象：“简历发给谁看”“谁来面”“谁来谈薪”在群里反复出现（职责界定环节）｜依据：「跃竞招聘群」2026-02、「跃竞招聘群」2026-04
  • 现象：分工变化只在群里一句话宣布，没有可查的矩阵（职责发布环节）｜依据：「跃竞招聘群」2026-01、「跃竞招聘群」2026-04
  • 现象：新加入的筛选人看不到前情，需要单独开历史权限（权限交接环节）｜依据：「跃竞招聘群」2026-07
  • 现象：技术、产品群分别有人对接，简历发到隔壁群，同一候选人被多处沟通（对接口径环节）｜依据：「跃竞招聘群」2026-02、「跃竞招聘群」2026-07
  • 现象：一名 HR 同时服务多个主体，被建议增设 HR 助理（人力配置环节）｜依据：「跃竞招聘群」2026-06

9. 分支变体

  • 跃竞（协游）、教育项目组、鼎慧、模态各有独立面试官与预算，分工矩阵按主体分表
  • 推荐人转为只推荐不跟进：在矩阵中保留“推荐人”字段，后续流程由接手方负责
  • 面试官更换：只更新矩阵对应轮次，在途候选人已约的面试由原面试官完成或明确改约

10. 待确认问题

  • 分工矩阵放在哪里（群公告、多维表格还是招聘系统）？由谁维护？
  • 各主体的谈薪人是否统一为 HR，还是允许主体负责人在授权内直接谈？
  • 是否增设 HR 招聘助理？还是先用 AI 承担初筛、日程与提醒？
  • 招聘专员离职或转岗时，交接是否纳入 HR-27 的离职交接清单？
X-RCT-23高管与子公司负责人招聘待新建100

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频1 × 耗5 × 跨4 × 险5

  • 适用场景：合资公司或子公司需要总经理兼技术负责人、CTO，或需要高薪的 Agent 专家、招投标 AI 方向负责人等关键岗位，需要从需求确认、寻访到多轮高层面试、定薪与签约的完整招聘
  • 负责人：主责——高管招聘发起人/创始人兼 CTO（当前：丁震宇·推断待确认）；协同——HR 负责人（当前：黄莹·推断待确认）、技术面试官（当前：王皓南·推断待确认）、技术筛选与笔试（当前：陈晖·推断待确认）、业务方/合资方对接人（当前：常元和·推断待确认）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 需求确认与预期管理 → ② 岗位定位与 JD → ③ 多渠道寻访 → ④ 预筛与笔试 → ⑤ 多轮高层面试 → ⑥ A 级背调 → ⑦ 薪酬与股权方案审批 → ⑧ offer 与签约主体确认 → ⑨ 退出原因复盘
  • 交付结果：岗位定位说明与 JD、候选人评估记录、经审批的薪酬与股权方案、签约的关键岗位人选（或退出原因复盘与下一步方案）
  • 状态依据：2026-05～06 一次子公司负责人与高薪专家岗招聘全程临时处理：复用旧 JD、title 与能力定位不匹配、业务方期望快速到位未管理预期，候选人因认为项目风险高而退出，无专用流程

1. 场景判定

  • 触发条件：新设合资公司或子公司需要总经理、CTO；新业务方向需要负责人；岗位年薪明显高于公司普通技术岗带宽；业务方要求关键人选限期到位
  • 典型说法：「来招新公司总经理兼 CTO 了」「高薪研发岗的 JD 应该怎么写」「需要一个能力足够强的负责人」「干招投标 AI 的负责人」「他觉得这个项目风险太高了」
  • 判断问题：这个岗位是否直接对一条新业务或一个主体负责？薪酬或股权是否超出常规审批权限？
  • 不归本流程管：普通技术岗急岗推进 → 请走 X-RCT-21；常规定薪与 offer → 请走 X-RCT-17；HC 与预算申请 → 请走 X-RCT-01；子公司主体设立与合同 → 请走 HR-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
招聘发起人 定岗位定位、组织面试、终面、牵头定薪 R 创始人兼 CTO（当前：丁震宇·推断待确认）
业务方/合资方对接人 提出需求、参与面试、确认预期与项目介绍材料 C 业务方/合资方对接人（当前：常元和·推断待确认）
技术面试官 写 JD 初稿、技术面试 R 技术面试官（当前：王皓南·推断待确认）
技术筛选与笔试 简历预筛、笔试或案例题 R 技术筛选与笔试（当前：陈晖·推断待确认）
HR 负责人 挂岗、对接猎头、背调、offer 与合同 R HR 负责人（当前：黄莹·推断待确认）
法务 股权、竞业、合资方协议条款审核 C 法务（当前：待指定）
终审 薪酬与股权方案最终审批 A CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 岗位定位说明：汇报对象、签约主体（集团/子公司/合资公司）、核心职责、成功标准、期望到位时间
  • 薪酬与激励结构初案（现金、股权或分红，由哪个主体承担）
  • 项目介绍材料：业务背景、资源投入、风险与应对（用于回应候选人对项目风险的顾虑）
  • 面试官安排：技术面、业务方面、发起人终面、CEO 面
  • 寻访渠道：内推与人脉、猎头、招聘平台挂岗、开源社区

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 与业务方确认岗位定位、汇报线、主体、激励结构与到位时间，书面说明一般周期（建议 60～90 天）以管理预期 招聘发起人、业务方对接人 需求提出后 3 个工作日内 飞书文档 岗位定位说明 👤人工判断
2 编写专用 JD，岗位 title 与能力定位一致，不复用普通岗 JD；发起人审定 技术面试官 定位确认后 3 个工作日内 JD wiki + AI 初稿 专用 JD 🔧+🤖
3 多渠道寻访：内推人脉、猎头、平台挂岗、定向外联，统一入候选人台账（限定可见范围） HR 负责人、招聘发起人 JD 定稿后 1 周内启动；每周更新进展 候选人台账（高管视图） 寻访名单 👤人工判断
4 预筛与笔试/案例题，评估结论写入台账 技术筛选与笔试 收到简历后 2 个工作日内 笔试系统 预筛结论 🔧+🤖
5 多轮面试：技术面 → 业务方/合资方面 → 发起人终面 → CEO 面；每轮面评 1 个工作日内提交，轮次间隔不超过 5 个工作日 各轮面试官 见动作栏 飞书日程 / 面评模板 各轮面评 👤人工判断
6 A 级背调（X-RCT-18），含前雇主上级、竞业限制核查 HR 负责人 终面通过后 5 个工作日内 第三方背调 背调结论表 👤人工判断
7 拟定薪酬与股权方案，法务审核条款，报 CEO（及合资方，如适用）审批 招聘发起人、法务 背调通过后 5 个工作日内 飞书审批 已批方案 🔧+👤
8 发 offer、确认签约主体与到岗日；合资/子公司由对应主体出合同 HR 负责人 审批后 2 个工作日内 邮件 / 合同 签约文件 🔧飞书固化
9 候选人退出或失败时记录原因（如项目风险顾虑），调整项目材料、激励或定位后再启动 招聘发起人 退出后 3 个工作日内 复盘纪要 退出复盘 👤人工判断

5. 交付物与模板

  • 交付物：岗位定位说明、专用 JD、候选人评估记录、背调结论、薪酬与股权审批单、签约文件、退出复盘
  • 建议模板/表单：
    • 岗位定位说明字段：岗位名称、签约主体、汇报对象、核心职责、首年目标、资源与授权、激励结构、期望到位日、面试官与轮次
    • 关键岗位候选人评估表：技术能力、业务判断、管理经验、与业务方匹配度、风险点、各轮结论

6. 异常与升级

  • 业务方要求明显短于正常周期到位 → 发起人当面说明周期与可选方案（临时代理、顾问先行）→ 分歧报 CEO
  • 岗位 title 与候选人能力不匹配 → 回到步骤 1 重新定位，不以高 title 吸引不匹配候选人
  • 候选人因项目风险顾虑犹豫 → 安排业务方或 CEO 面谈，提供项目材料 → 仍退出则做退出复盘
  • 薪酬或股权超出合资方可承担范围 → 由 CEO 与合资方协商 → 5 个工作日无结论暂停该候选人
  • 候选人信息高度敏感 → 只在发起人、HR 负责人、面试官范围内流转，不在招聘群公开讨论

7. 衡量指标

  • 到位周期 = 需求确认到候选人签约的自然日数，目标 ≤ 90 天
  • 终面转化率 = 签约人数 / 进入终面人数，按年统计
  • 关键岗位试用期留存率 = 通过试用期人数 / 到岗人数，目标 100%
  • 退出复盘完成率 = 有复盘纪要的候选人退出次数 / 退出总次数，目标 100%

8. 低效诊断

  • 现象：高薪岗位临时问“JD 应该怎么写”，复用旧 JD 挂网（岗位定义环节）｜依据：「技术岗招聘沟通」2026-05
  • 现象：岗位 title 与能力定位不匹配，中级岗位放了高 title（定位环节）｜依据：「技术岗招聘沟通」2026-05
  • 现象：业务方期望快速到位，没有事先说明关键岗位招聘周期（预期管理环节）｜依据：「技术岗招聘沟通」2026-05
  • 现象：候选人因判断项目风险太高而退出，项目介绍和风险应对材料未提前准备（吸引与说服环节）｜依据：「技术岗招聘沟通」2026-06
  • 现象：候选人多次变更，流程与普通技术岗混在同一群里推进（流程区分环节）｜依据：「技术岗招聘沟通」2026-05、「技术岗招聘沟通」2026-06

9. 分支变体

  • 子公司/合资公司总经理兼 CTO：签约主体为子公司，激励含股权或分红，需合资方参与面试与审批
  • 高薪专家岗（如 Agent 专家）：签约主体为集团，薪酬超出常规带宽，走 CEO 特批
  • 新业务方向负责人（如招投标 AI）：业务方参与定位与面试，首年目标写入岗位定位说明

10. 待确认问题

  • 高管与子公司负责人招聘的发起人与终审人分别是谁？CEO 是否必须参与终面？
  • 是否引入猎头？费用标准与适用岗位范围？
  • 合资方在面试和薪酬审批中的权限如何约定？
  • 到位周期目标 90 天是否可行？
  • 关键岗位薪酬与股权方案由哪个主体承担，审批是否需要董事会或股东会决议？
X-RCT-24候选人个人信息与简历数据合规管理待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频4 × 耗2 × 跨3 × 险4

  • 适用场景：收集、存储、转发、用 AI 筛选候选人简历与面评，以及定期删除不再需要的候选人信息时适用
  • 负责人：主责——招聘专员（当前：待指定）；协同——法务（当前：待指定）、IT 管理员（当前：待指定）、面试官（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 收集时告知与同意 → ② 统一存放与权限控制 → ③ AI 处理前脱敏或确认工具合规 → ④ 内部流转限范围 → ⑤ 定期清理 → ⑥ 候选人查询/删除请求响应
  • 交付结果：候选人信息存放清单与访问权限表、AI 处理规则、定期清理记录
  • 状态依据：已有 X-RCT-07（简历收集初筛，含 AI 快筛）、X-RCT-16（候选人台账与人才池）覆盖部分环节，本条补齐候选人个人信息的告知、存放权限、AI 处理与到期删除规则（推断）

1. 场景判定

  • 触发条件：从招聘平台下载简历；把简历发到群或发给面试官；用 AI 工具打分；人才池长期留存
  • 典型说法：「把这批简历丢给 AI 打个分」「简历发群里大家看看」「这个候选人要求删除他的信息」
  • 判断问题：信息是否会离开公司统一存储位置？是否会进入外部 AI 服务？
  • 不归本流程管：简历筛选业务流程 → 请走 X-RCT-07；候选人台账与人才池日常维护 → 请走 X-RCT-16；背景调查 → 请走 X-RCT-18；在职员工档案 → 请走 HR-28；批量数据导出授权 → 请走 X-SEC-35
  • 与 LEG-34 的边界：候选人查询/删除请求的法律口径（答复时限、留存例外、拒绝理由）以 LEG-34 为准；本流程只负责招聘侧的受理、执行与留痕；简历外泄等数据安全事件转 LEG-34 评估

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
执行 统一存放、按需授权、清理 R 招聘专员（当前：待指定）
合规口径 告知文本、AI 处理合规判断 C 法务（当前：待指定）
权限配置 存储与访问权限 C IT 管理员（当前：待指定）
使用方 仅在授权范围内查看，不外传 I 面试官（当前：待指定）
审批 批准规则与例外 A 人事负责人（当前：黄莹·部门报送人）

3. 办之前请准备

  • 当前简历存放位置清单（招聘平台、多维表格、云盘、群聊）
  • 在用的 AI 筛选工具及其数据处理方式（是否经内部网关、是否留存）
  • 候选人告知文本

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在投递入口/面试邀约中加入个人信息处理告知 招聘专员 规则发布后 5 个工作日内 招聘平台/邮件模板 告知文本 🔧飞书固化
2 简历统一存入候选人台账，禁止群内转发附件 招聘专员 下载后 1 个工作日内 飞书多维表格 台账记录 🔧飞书固化
3 按岗位给面试官授予查看权限 招聘专员 约面时 飞书权限 权限记录 🔧飞书固化
4 确认 AI 工具合规（内部网关或经法务确认的工具），必要时去除联系方式后再筛选 招聘专员 每次筛选前 内部 AI 网关 合规处理记录 🤖+👤（人工确认工具与脱敏，AI 执行筛选）
5 响应候选人查询/删除请求（口径按 LEG-34） 招聘专员+法务 收到后 15 个工作日内（以 LEG-34 确认的时限为准） 邮件 处理回复 👤人工判断
6 清理入库超过保留期限（未录用默认 12 个月，具体期限待法务确认）且未经候选人同意进入人才池的信息 招聘专员 每季度末 多维表格自动化 清理记录 🔧+🤖

5. 交付物与模板

  • 交付物：候选人信息处理规则、存放与权限清单、清理记录
  • 建议模板/表单：台账字段增加“信息来源、告知/同意方式、入库日期、保留截止日、是否进人才池”

6. 异常与升级

  • 发现简历被转发到外部或公开群 → 撤回并报法务（当天），按 LEG-34 评估
  • 面试官离职或转岗 → 同步收回候选人台账权限（1 个工作日内）

7. 衡量指标

  • 简历集中存放率 = 存于统一台账的简历 / 收到简历总数，目标 100%
  • 超期信息清理完成率：每季度目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在简历在群聊散落、未经告知交由外部 AI 处理、长期留存引发个人信息合规的风险（推断）

9. 分支变体

  • 猎头推荐的简历按与猎头约定的使用范围处理（X-RCT-25）；内推简历需推荐人确认已获候选人同意

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 当前 AI 快筛使用的是内部网关还是外部服务？
  • 未录用候选人信息保留多久合适（第 6 步暂按 12 个月执行，请法务确认）？进入人才池是否需要候选人单独同意？
X-RCT-25猎头与外部招聘服务商合作及费用结算待新建推断72

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险3

  • 适用场景：急岗、高端岗位或管理岗需要委托猎头、RPO 或其他外部招聘服务商推荐候选人，及其后续保证期与费用结算时启动
  • 负责人：主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、财务（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 判断是否需要外部服务 → ② 服务商比选 → ③ 签署合作协议 → ④ 下发岗位与推荐规则 → ⑤ 候选人归属判定 → ⑥ 入职与保证期跟踪 → ⑦ 对账付款
  • 交付结果：已签合作协议、服务商台账、推荐归属记录、付款与保证期记录
  • 状态依据：已有 X-RCT-04（招聘渠道拓展，含付费渠道投放）、X-RCT-23（高管与子公司负责人招聘）覆盖部分环节，本条补齐猎头等外部招聘服务商的比选、协议、推荐归属与费用结算；多主体招聘下存在重复推荐与费用归属问题（推断）

1. 场景判定

  • 触发条件：岗位挂出一段时间无合格候选人；高管/子公司负责人岗位；服务商主动推荐简历
  • 典型说法：「这个岗位要不要找猎头」「猎头推了个人，我们库里好像已经有了」
  • 判断问题：该岗位是否经审批可使用外部服务？候选人是否已在公司人才池中？
  • 不归本流程管：自有渠道运营 → 请走 X-RCT-04；高管招聘决策 → 请走 X-RCT-23；对公付款审批 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
对接与台账 比选、对接、归属判定、跟踪保证期 R 招聘专员（当前：待指定）
需求方 说明岗位要求、面试评价 C 用人部门负责人（当前：待指定）
合同审核 审核协议条款 C 法务（当前：待指定）
付款 对账、付款、收票 R 财务（当前：待指定）
审批 批准使用外部服务与付款 A 人事负责人（当前：黄莹·部门报送人）

3. 办之前请准备

  • 已审批的岗位需求（X-RCT-01）与 JD
  • 服务商资质、收费方式、保证期条款
  • 公司人才池查询入口（X-RCT-16）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交使用外部服务申请 招聘专员 需求确认后 2 个工作日内 飞书审批 审批结论 🔧飞书固化
2 比选至少 2 家服务商 招聘专员 审批后 5 个工作日内 文档 比选记录 👤人工判断
3 协议审核与签署（含保密、保证期、归属规则） 法务 提交后 3 个工作日内 LEG-04 合作协议 👤人工判断
4 收到推荐时查重并确认归属 招聘专员 收到后 1 个工作日内 候选人台账 归属记录 🔧+🤖
5 入职后跟踪保证期 招聘专员 保证期届满前 5 个工作日 多维表格提醒 跟踪记录 🔧飞书固化
6 按协议对账、申请付款并收票 招聘专员+财务 付款节点前 5 个工作日 飞书审批 付款记录 🔧飞书固化

5. 交付物与模板

  • 交付物：服务商台账、合作协议、推荐归属记录、付款记录
  • 建议模板/表单：服务商台账（服务商、签约主体、合作岗位、收费方式、保证期、推荐人数、录用人数、付款状态）

6. 异常与升级

  • 同一候选人被多方推荐 → 以最先书面推荐时间为准，争议报人事负责人（2 个工作日内）
  • 保证期内离职 → 按协议要求退款或免费补推

7. 衡量指标

  • 外部渠道录用率 = 外部推荐录用数 / 外部推荐数
  • 单岗位招聘周期：从委托到入职的自然日

8. 低效诊断

  • 聊天中未见相关流程，存在重复付费、费用主体错配、保证期失效后才发现不合适的风险（推断）

9. 分支变体

  • 子公司岗位由子公司主体签约付款；校园招聘合作机构参照本流程

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 是否已有合作中的猎头或服务商？
  • 使用外部服务是否需要 CEO 审批？
X-RCT-26Offer 变更、撤回与候选人未到岗处理待新建推断48

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨3 × 险4

  • 适用场景：Offer 发出后需要修改条件、因岗位冻结或背调问题撤回 Offer，或候选人延期、爽约、拒绝到岗时启动
  • 负责人：主责——招聘专员（当前：待指定）；协同——用人部门负责人（当前：待指定）、法务（当前：待指定）、行政（当前：待指定）；兜底——人事负责人（当前：黄莹·部门报送人）
  • 核心流程：① 识别变更情形 → ② 评估影响与法律风险 → ③ 审批 → ④ 书面告知候选人 → ⑤ 取消入职准备 → ⑥ 更新台账与人才池 → ⑦ 启动补位
  • 交付结果：书面变更/撤回通知或候选人确认记录；已取消的工位、设备、账号准备；更新后的招聘台账
  • 状态依据：已有 X-RCT-17（录用审批与 Offer 发放）、X-RCT-19（录用确认到入职衔接）覆盖部分环节，本条补齐 Offer 变更、撤回与候选人未到岗的处理（推断）

1. 场景判定

  • 触发条件：岗位冻结或预算变化；背调不通过；候选人要求改薪、改到岗日或临时放弃
  • 典型说法：「这个岗位先不招了，已经发了 offer 怎么办」「候选人说下周不来了」
  • 判断问题：候选人是否已书面接受 Offer？是否已从原单位离职？
  • 不归本流程管：Offer 发放 → 请走 X-RCT-17；正常入职衔接 → 请走 X-RCT-19；面试不通过通知 → 请走 X-RCT-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
沟通执行 与候选人沟通、书面告知、更新台账 R 招聘专员（当前：待指定）
业务决策 提出撤回/变更理由，确认补位需求 C 用人部门负责人（当前：待指定）
风险评估 已接受 Offer 撤回的赔偿风险与话术 C 法务（当前：待指定）
取消准备 取消工位、设备、账号准备 I 行政（当前：待指定）
审批 批准撤回或变更 A 人事负责人（当前：黄莹·部门报送人）

3. 办之前请准备

  • Offer 文本、候选人接受记录、沟通记录
  • 撤回/变更原因及依据（如背调结论、岗位冻结审批）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记变更情形与原因 招聘专员 知悉当天 候选人台账 变更记录 🔧飞书固化
2 已接受 Offer 的撤回，法务评估风险与话术 法务 1 个工作日内 文档 风险意见 👤人工判断
3 审批撤回/变更 人事负责人 评估后 1 个工作日内 飞书审批 审批结论 🔧飞书固化
4 电话沟通并书面告知候选人 招聘专员 审批后 1 个工作日内 邮件 书面通知 👤人工判断
5 通知行政、IT 取消入职准备 招聘专员 告知后当天 飞书群 取消记录 🔧飞书固化
6 候选人未按约到岗，到岗日当天联系确认，确认放弃后关闭 招聘专员 到岗日当天 电话/台账 关闭记录 👤人工判断
7 更新台账，判断是否从人才池补位 招聘专员+部门负责人 关闭后 2 个工作日内 候选人台账 补位计划 🤖+👤（自动更新台账，人工判断补位）

5. 交付物与模板

  • 交付物：变更/撤回通知、台账状态更新、补位计划
  • 建议模板/表单：Offer 变更登记（候选人、岗位、原条件、变更类型、原因、是否已接受、是否已离职原单位、审批结论）

6. 异常与升级

  • 候选人已离职原单位且公司撤回 → 法务与人事负责人共同确定处理方案（2 个工作日内）
  • 候选人到岗日失联 → 连续 2 个工作日联系不上即关闭并启动补位

7. 衡量指标

  • Offer 撤回率 = 撤回数 / 发出数，目标 ≤ 3%
  • 补位启动时效：关闭到启动补位的工作日数，目标 ≤ 2 天

8. 低效诊断

  • 聊天中未见相关流程，存在撤回引发缔约过失索赔、入职准备资源浪费、岗位空缺无人补位的风险（推断）

9. 分支变体

  • 实习生 Offer 变更可简化审批，由部门负责人与人事专员确认

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • Offer 是否设有接受期限与失效条款？
  • 撤回已接受 Offer 是否必须经人事负责人审批？

X-SEC 信息安全 / IT 运维

报送人：待定 · 归属待定 · 46 条 · 已有 0 / 待优化 17 / 待新建 29
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-SEC-01新人入职 IT 账号一站式开通与内部系统“找谁”指引新员工、实习生、借调人员确定到岗日期后，按岗位清单一次性开通 Gitea、工单、LeapCore 内部版、NewAPI 控制台、PostHog、CRM/渠道系统、企业邮箱、飞书群等账号，并在到岗当天发放“系统-负责人-申请入口”目录主责——IT 运维（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、工单系统管理员（当前：王皓南·推断待确认）、PostHog 管理员（当前：魏宗浩·推断待确认）、NewAPI 管理员（当前：柯逸飞·推断待确认）、CRM/渠道系统管理员（当前：郭逸非、陈子康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各直属上级；兜底——CTO（当前：丁震宇·推断待确认）① 入职单触发开通清单 → ② 直属上级确认岗位权限模板 → ③ 拆单派给各系统管理员 → ④ 各系统开通并安全发放凭据 → ⑤ 回填账号台账 → ⑥ 到岗当天发放“找谁”目录 → ⑦ 新人首日自检登录 → ⑧ 台账归档备回收新人到岗当天可登录全部岗位所需系统；一份按人登记的账号台账（系统、账号、权限级别、开通人、开通日期），作为离职回收依据待新建192
X-SEC-02代码仓库（Gitea）账号与仓库权限开通、重置与封禁新人、转岗、新项目、子公司或外部人员需要 Gitea 账号、组织/团队/仓库权限、SSH 公钥，或忘记密码、仓库迁入组织，或离职/违规需要封号主责——Gitea 管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、组织/仓库 Owner（当前：岳阳、王子明、李铭熙、吴世豪·推断待确认）、研发负责人（当前：王皓南·推断待确认）、人事（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 提交仓库权限申请 → ② 直属上级/仓库 Owner 确认范围 → ③ 管理员建号并发邀请链接 → ④ 按团队模板授权 → ⑤ 申请人配置 git 身份与公钥并验证 → ⑥ 台账登记 → ⑦ 重置/封禁按单处理 → ⑧ 季度权限盘点可用的 Gitea 账号与按最小授权配置的组织/团队/仓库权限；权限台账（账号、组织、团队、仓库、角色、期限、批准人）待优化96
X-SEC-03内部业务系统与管理后台账号/角色开通及密码重置内部同事需要 LeapCore 内部版、字字可研等产品管理后台（测试/正式）、渠道系统/CRM、LeapPPT 后台等业务系统账号或角色，或忘记密码，或需要收回超范围的管理员权限主责——业务系统 Owner（当前：字字可研后台——宋祺睿；LeapCore 内部版——杨萌；渠道系统/CRM——陈子康；LeapPPT 后台——马漳毓·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、LeapPPT 管理员分配人（当前：陈梦琪·推断待确认）、申请人直属上级；兜底——CTO（当前：丁震宇·推断待确认）① 提交系统角色申请 → ② 系统 Owner/上级审批 → ③ 飞书登录或管理员建号 → ④ 分配角色并设期限 → ⑤ 安全发放凭据 → ⑥ 台账登记 → ⑦ 到期回收 → ⑧ 季度管理员盘点申请人以本人账号按所需角色登录对应系统；系统-账号-角色台账（含临时授权到期日）待优化96
X-SEC-04企业邮箱与公共邮箱开通授权新人或项目需要个人企业邮箱；业务需要对外统一收发的公共邮箱（售后、HR、笔试、合作商、报名收集）；系统需要用公共邮箱 SMTP 发件；公共邮箱成员增减主责——人事负责人（当前：黄莹·推断待确认）；协同——飞书邮箱管理员（当前：丁震宇·推断待确认）、公共邮箱使用部门负责人；兜底——CTO（当前：丁震宇·推断待确认）① 提交邮箱申请 → ② 判断类型（个人/公共/SMTP）→ ③ 创建邮箱或加成员 → ④ SMTP 授权码安全发放 → ⑤ 登记公共邮箱负责人 → ⑥ 人员变动同步移除 → ⑦ 季度核对可用的个人或公共邮箱；公共邮箱台账（邮箱名、用途、负责人、成员、是否开 SMTP、绑定系统）待优化27
X-SEC-05内部系统接入飞书统一登录（SSO）与登录方式变更内部系统、渠道系统、云平台、PVE、网盘等要用飞书登录替代自建账号，或要撤销独立管理员账号、改变登录方式时主责——IT 运维（当前：杨明学·推断待确认）；协同——系统开发者（当前：宋祺睿、葛家和·推断待确认）、系统管理员（当前：郭逸非·推断待确认）、飞书管理员（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记接入需求 → ② 按模板创建飞书应用（最小权限）→ ③ 飞书管理员审批权限与可用范围 → ④ 测试环境验证 → ⑤ 账号迁移与独立管理员账号撤销 → ⑥ 发布登录方式变更通知 → ⑦ 更新系统登录台账系统可用飞书账号登录，独立账号已停用或封存；系统登录方式台账；登录变更通知待优化36
X-SEC-06外部协作方访问内网、联调环境与数据授权外包、外部开发团队、外部厂商、子公司外部人员、算法协作者需要测试机、联调环境、VPN、系统账号或产品数据；或公司需接入外部厂商硬件（远程 VPN/堡垒机）主责——IT 运维（当前：杨明学·推断待确认）；协同——项目对接人（当前：杨萌·推断待确认）、研发运维（当前：宋祺睿、杨云峰·推断待确认）、VPN 负责人（当前：吴世豪·推断待确认）、数据接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 对接人提交外部接入申请 → ② 法务核验保密协议 → ③ IT 运维出隔离接入方案 → ④ CTO 审批 → ⑤ 开独立、最小、限期账号 → ⑥ 限时安全分享凭据 → ⑦ 台账登记 → ⑧ 到期回收与改密外部人员在隔离环境内以独立账号访问约定资源；外部接入台账（主体、人员、资源、数据范围、保密协议、期限、对接人）；到期回收记录待新建150
X-SEC-07客户/渠道索要设备 root/管理员账号与远程接入的审批与回收客户、渠道、实施人员要求设备 root 密码、服务器账密、管理员账号找回、内网穿透、公网映射或远程使用部署在公司的设备时，按统一口径答复，例外走审批，交付后回收主责——研发负责人（当前：王皓南·推断待确认）；协同——对客人员（当前：杨萌、时建、杨朋伟、吴琪·推断待确认）、交付部署工程师（当前：游家豪、杨云峰·推断待确认）、IT 运维（当前：杨明学·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、CTO（当前：丁震宇·推断待确认）审批、CEO（当前：邴龙志·推断待确认）特例审批；兜底——CTO（当前：丁震宇·推断待确认）① 对客人员收到诉求不当场答复 → ② 按类型对照口径 → ③ 标准件按话术回复 → ④ 例外提交“客户上机/高权限”审批 → ⑤ 审批通过后限时开通 → ⑥ 登记台账 → ⑦ 到期回收改密 → ⑧ 误发应急处置客户收到统一口径答复或受控、限期的权限；客户高权限授权台账；误发后的改密与加固记录待新建225
X-SEC-08离职/试用终止/调岗账号回收与权限收口人员离职、试用/实习终止、违规处理、调岗时，按账号台账一次性回收或调整 Gitea、工单、业务系统、邮箱、飞书群、企业微信、VPN/飞连、服务器公钥等权限，并清理敏感群成员主责——IT 运维（当前：待指定）；协同——人事（当前：待指定）、Gitea 管理员（当前：宋祺睿·推断待确认）、各系统管理员、直属上级/技术负责人（当前：王子明·推断待确认）、敏感群群主；兜底——CTO（当前：丁震宇·推断待确认）① 人事异动单触发回收清单 → ② 试用终止/违规先封号 → ③ 各系统停用或降级 → ④ 共享凭据改密 → ⑤ 移出群组与敏感群 → ⑥ 调岗按新模板授权 → ⑦ 回填台账并归档 → ⑧ 月度残留盘点已关闭的回收清单（每个系统的停用时间与执行人）；更新后的账号台账；敏感群成员审计记录待新建120
X-SEC-09测试/内部环境地址与管理员账号登记交接测试服、公司内部生产服、交付预演环境（50、102、103、108、109 等）新部署、重装、重置或改密后，部署人把访问地址和管理员账号登记到统一环境台账，再按需授权给测试、产品、销售演示使用；账号丢失或被锁时也按本流程重置。主责——环境运维/部署负责人（当前：宋祺睿·推断待确认）；协同——部署工程师（当前：杨云峰、陈子康·推断待确认）、IT运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品（当前：杨萌、杨黔昆·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）① 部署/重置完成 → ② 凭据写入密码库环境条目 → ③ 更新环境台账 → ④ 群内发变更公告（只给台账链接） → ⑤ 使用人查台账或提交访问申请 → ⑥ 改密/重置先公告后执行 → ⑦ 每月核对与回收一张实时有效的“环境台账”（环境、地址、用途、版本、负责人、状态、对应密码库条目），以及按人授权的密码库访问记录；群聊中不再出现明文账号密码。待新建240
X-SEC-10密钥与凭据分发保管规范（禁止群内明文）凡是要在人与人之间共享账号密码、API Key、AK/SK、数据库口令、kubeconfig、镜像仓库账号、SMTP/地图/公众号等第三方密钥、生产环境变量或客户系统账号时，一律走密码库或私密通道分发并登记，禁止在群聊、私聊、截图、文档、代码里出现明文。主责——信息安全负责人（当前：待指定）；协同——IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、云与模型 Key 持有人（当前：待指定）、客户项目账号主负责人（当前：邓乾·推断待确认）、行政（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 判定凭据密级 → ② 持有人在密码库建条目 → ③ 按人/按组授权或发一次性链接 → ④ 登记凭据台账（用途、持有人、一主二备、到期日） → ⑤ 使用人从密码库取用或注入环境变量 → ⑥ 到期轮换、人员变动回收 → ⑦ 群聊明文监测与月度审计公司统一密码库（按部门/项目/环境分组）、凭据台账、按人授权记录和轮换记录；群聊明文凭据清零。待新建250
X-SEC-11凭据泄露应急处置与密钥轮换发现密钥、验证码、密码被截图外发、贴进群聊或日志、随代码提交、被过度共享、可能被 AI 读取，或 API 额度被异常用光、开发电脑中招时，立即禁用、轮换、溯源、复盘；另外每到轮换周期或发生重大节点（如保密协议生效、人员批量变动），也按本流程统一轮换。主责——信息安全负责人（当前：待指定）；协同——云与模型 Key 管理员/Gitea 管理员（当前：丁震宇·推断待确认）、IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 发现并上报 → ② 定级 → ③ 止血（撤回、吊销、禁用账号） → ④ 轮换并按 X-SEC-10 重新分发 → ⑤ 溯源与影响排查 → ⑥ 恢复与解封 → ⑦ 登记复盘与整改已吊销并替换的凭据、泄露事件登记表（含时间线、影响、处置、整改项）、轮换记录；重大事件附复盘纪要。待新建240
X-SEC-12第三方平台/对外账号台账与验证码代收公司在云厂商、AI 平台、模型渠道、OCR、微信开放平台、Apple 开发者、社媒、政务申报系统等平台持有的账号，统一登记主体、实名人、绑定手机号/邮箱、管理员和使用人；验证码统一收口；账号交接、注销、欠费都按台账处理。主责——IT运维/平台账号管理员（当前：杨明学·推断待确认）；协同——CTO（现为多数平台账号持有人和收码人，当前：丁震宇·推断待确认）、总经办（当前：待指定）、财务（当前：待指定）、法务（当前：待指定）、运营（当前：吴文葶·推断待确认）、政策申报（当前：王蕊、赵雪冰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 全量盘点登记 → ② 确认主体、实名人、管理员 → ③ 凭据入密码库 → ④ 绑定迁移到公司号码/公共邮箱 → ⑤ 验证码收码设备 + 机器人分流 → ⑥ 新增、交接、注销随时登记 → ⑦ 季度核对、到期和欠费提醒一张“对外平台账号台账”（平台、主体、实名人、绑定手机号/邮箱、管理员、使用人、费用与到期），密码库中对应条目，验证码自动转发记录；不再有账号只绑在某个人的手机上。待新建200
X-SEC-14AI 编程工具订阅账号开通、充值与防封管理员工需要 Claude、Codex、GPT、Kimi 等 AI 工具订阅，或需要公司镜像账号（Sorux 等）时，统一走申请、开通、登记、月度充值、封号上报和回收；防封网络与设备配置按 IT 发布的指引执行。主责——IT运维/AI 账号负责人（当前：杨明学·推断待确认）；协同——行政（镜像订阅名单、充值、收票，当前：侯明月·推断待确认）、人事（新人统计，当前：黄莹·推断待确认）、规则与预算决策（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 按岗位选工具类型 → ② 提交 AI 工具申请（入职或月底申请） → ③ 审批工具、额度、支付方式 → ④ 开通（镜像开号 / 按防封指引代注册官方订阅 / 补贴自购） → ⑤ 登记账号台账 → ⑥ 每月 10 日统一充值和名单更新 → ⑦ 封号或风控上报、申诉退款 → ⑧ 离职或不用时回收可用的 AI 工具账号、AI 工具账号台账（使用人、类型、支付方式、到期、状态）、月度充值记录、封号事件记录，以及一份受控的《AI 账号开通与防封指引》。待优化400
X-SEC-15云平台子账号/控制台权限与 AccessKey 申请研发、测试、运维或财务在腾讯云、阿里云、火山、EdgeOne 等控制台报“无权限”，或需要子账号、AccessKey、TCR 镜像推送、CLS/COS/CAM/监控、云安全产品、账单查看等权限时，按权限包申请、授权、登记，到期回收。主责——云平台管理员（当前：丁震宇·推断待确认）；协同——备份云管理员/IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、财务（当前：黄梦婷·推断待确认）；兜底——IT运维负责人（当前：杨明学·推断待确认）① 按岗位选权限包 → ② 提交云权限申请（平台、主体、资源、权限包、期限） → ③ 审批（高危权限人工判断） → ④ 一次性授予策略包或建子账号 → ⑤ AK 经密码库交付 → ⑥ 登记权限台账 → ⑦ 到期回收与季度盘点申请人拿到可用的子账号或策略权限，AK 进密码库；云权限台账记录谁在哪个平台、哪个主体下有什么权限、到什么时候。待新建144
X-SEC-16云服务器与云资源申请开通（CVM/COS/数据库/端口/镜像仓库）研发、交付、售前或非研发同事需要公有云服务器、对象存储桶、云数据库、安全组端口或镜像仓库时，从提需求到开通、登记、到期回收的全过程主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、资源审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交“非实体资产申领”审批 → ② 资源审批人审规格与必要性 → ③ 云资源管理员按模板开通（IaC 优先）→ ④ 凭据按规范下发 → ⑤ 登记资源台账 → ⑥ 申请人验收 → ⑦ 到期提醒续用或释放已开通可用的云资源 + 审批单留痕 + 资源台账一行记录（用途/负责人/项目/到期日/费用）待优化240
X-SEC-17内网测试服务器/GPU/虚拟机/CI Runner 资源申请、SSH 开通与调度产研需要公司机房内网的测试机、GPU（5090/4090 等）、PVE 虚拟机/LXC、CI runner、共享算力机账号、磁盘或内存扩容、测试机 SSH 登录，或 IT 需要换机、重置、回收时主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——资源优先级评估人/CTO（当前：丁震宇·推断待确认）、测试环境管理人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）、共享机与体验机管理员（当前：宋祺睿、岳阳·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交内网资源申请 → ② 优先级评估与排期 → ③ 网管建机、分配 IP/端口段 → ④ 公钥授权 → ⑤ 登记资源池台账 → ⑥ 使用中巡检与限额 → ⑦ 换机/重置提前通知，到期回收可登录的内网机器/虚拟机/GPU 时段/runner + 资源池台账记录（IP、用途、占用人、环境级别、到期日）+ 变更通知记录待新建180
X-SEC-18生产资源访问申请审批与回收研发或业务人员需要登录生产服务器、访问生产或客户数据库、查生产日志、获取生产环境变量，或做生产数据备份迁移时主责——生产权限开通执行人/运维（当前：宋祺睿·推断待确认）；协同——审批人/Leap 研发负责人（当前：王皓南·推断待确认）、客户环境运维（当前：杨明学、游家豪·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交“Leap 生产资源访问申请” → ② 审批人核对资源/上下文/预期操作 → ③ 机器人建专属群 → ④ 签发限时凭证（公钥/跳板/只读账号）→ ⑤ 访问操作留痕 → ⑥ 到期自动回收并关单 → ⑦ 月度复核审批单、限时访问凭证、操作记录、回收确认、归档的专属群待优化200
X-SEC-19域名解析、SSL 证书与端口开通新服务、内部工具、演示环境上线时，需要在已备案主域名下加子域名解析、HTTPS 证书、CNAME/EdgeOne 配置、COS 跨域或安全组端口放行主责——DNS/证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人/端口审批人（当前：丁震宇·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）① 提交域名/端口变更单 → ② 校验命名、备案状态与目标 → ③ 公网端口审批 → ④ 配置解析/EdgeOne/安全组/CORS → ⑤ 自动签发证书 → ⑥ 申请人验证 → ⑦ 登记域名台账可访问的 HTTPS 域名或已放行的端口 + 域名台账记录（域名、解析目标、证书方式、负责人、备案主体）待优化48
X-SEC-20域名选购与 ICP 备案新产品、官网或对外页面（含宣传物料上的二维码链接）需要正式对外域名时启动，包括选购、按主体备案、解析与 HTTPS、旧域名迁移/301，直至可以对外使用。主责——域名与备案管理员（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、官网前端（当前：葛家和·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 登记域名需求 → ② 查域名台账 → ③ 查候选可注册性、价格与可备案性 → ④ 确认主体并购买 → ⑤ ICP 备案 → ⑥ 解析、HTTPS、301 → ⑦ 上线核验（含二维码） → ⑧ 登记台账并设到期提醒已备案、可访问并启用 HTTPS 的对外域名；旧域名 301 跳转；域名台账（持有主体、用途、备案号、到期日、负责人）。待新建96
X-SEC-21证书与域名到期监控续期域名、HTTPS 证书或授权证书即将或已经到期，或云厂商发来证书到期、数据库安全升级通知时主责——证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人（当前：丁震宇·推断待确认）、服务负责人（当前：按台账）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 上线即登记到期台账 → ② 优先自动续签 → ③ 每日扫描剩余天数 → ④ 到期前 30/7 天提醒 → ⑤ 续期或下线 → ⑥ 部署验证 → ⑦ 更新台账；云厂商通知 → 指派处理持续有效的证书与域名、更新后的到期台账、续期记录待新建48
X-SEC-22云资源/域名资产盘点与闲置回收（成本治理）云服务器、数据库、COS、DNS 记录、演示机数量增长，或自动续费前、账单异常、旧云账号弃用、折扣更新时的定期盘点与闲置回收主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、销毁审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 每月导出云资源与账单 → ② 与台账比对标出无主/闲置/高价 → ③ 负责人限期认领 → ④ 未认领公示 7 天 → ⑤ 关机保留 7 天 → ⑥ 审批后销毁 → ⑦ 更新台账并出成本月报月度盘点表、释放清单与审批记录、更新后的资源台账、云成本月报待新建144
X-SEC-23代码签名证书申请、保管与签名使用Windows/macOS 安装包需要代码签名，涉及证书（Windows EV、Apple 开发者）采购与 CA 复审、UKey/签名机保管、CI 签名审批、签名工具使用授权与保管人交接主责——签名资产保管人/CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、签名审批人/CTO（当前：丁震宇·推断待确认）、客户端打包负责人（当前：李铭熙·推断待确认）、主体复审联系人（当前：邴龙志·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 证书采购申请 → ② 比价付款 → ③ CA 复审/Apple 核验 → ④ UKey 入库登记、签名机部署 → ⑤ CI 打包后机器人发签名审批 → ⑥ 审批确认后按范围签名 → ⑦ 使用日志、交接与到期续期有效的代码签名证书、资产台账登记（保管人、位置、到期日）、签名审批记录与签名后的安装包待优化240
X-SEC-24办公网络接入认证、网络分区与 WiFi 密码查询新人入职、访客到访、新设备（办公电脑、服务器、打印机等 IoT）需要接入公司网络，或员工需要获取 WiFi 凭据、确认该连哪个网络时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、人事负责人（当前：待指定，负责入职指引）、行政（当前：待指定，负责访客接待）；兜底——CTO（当前：丁震宇·推断待确认）① 判定接入类型与网络分区 → ② 提交入网登记 → ③ IT 审核并绑定认证 → ④ 按身份下发凭据 → ⑤ 接入验证 → ⑥ 设备台账登记 → ⑦ 定期轮换与离职回收已完成认证绑定并可正常上网的设备；更新后的入网设备台账（MAC/IP/责任人/分区）；成文的《办公网络使用说明》（含分区用途与获取方式）待优化160
X-SEC-25远程办公与内网访问接入（飞连/VPN/IP 白名单）员工居家/出差、销售外出演示需要访问内网 LeapCore 或内部服务，研发需要从外网连测试库/测试后台/测试机，或内网多人需要互相访问本地服务联调时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——LeapVPN 负责人（当前：吴世豪·推断待确认）、后端兼运维（当前：宋祺睿·推断待确认，负责 IP 白名单/安全组）、产品总监（当前：杨萌·推断待确认，负责远程访问使用手册与对外通知）、运维/交付部署工程师（当前：游家豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）① 提交访问申请 → ② 选定接入通道 → ③ 审批 → ④ 开通（席位/激活码/白名单/端口） → ⑤ 用户按手册自检 → ⑥ 登记台账 → ⑦ 到期与离职回收可用的远程访问通道（飞连账号/LeapCore 远程访问激活码/IP 白名单/端口互通）；远程访问台账；《远程访问与外出演示使用手册》（含排查口诀与 FAQ）待优化240
X-SEC-26海外出口线路与代理节点运维研发/CI 访问 GitHub、Docker、npm、海外 AI 服务出现断流、SSL/TLS 错误、超时或流量耗尽，或需要新增域名白名单、落地 IP、节点线路、续费扩容时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，预算与方向）、CI 负责人（当前：吴世豪·推断待确认，CI 依赖域名清单）、运维/交付部署工程师（当前：游家豪·推断待确认，全员配置）、财务（当前：待指定，付款与票据）、法务（当前：待指定，合规边界）；兜底——CTO（当前：丁震宇·推断待确认）① 提交需求或故障 → ② 分类（故障/白名单/新线路/续费） → ③ 按清单排查或评估 → ④ 预算审批 → ⑤ 向运营商/供应商申请执行 → ⑥ 验证并公告 → ⑦ 更新线路台账 → ⑧ 用量监控与月度复盘可用的海外出口线路/节点；线路与白名单台账（节点、落地 IP、白名单域名、带宽、流量、到期日、费用、票据方式）；用量告警与月度用量报告；《出口线路使用规范》待新建240
X-SEC-27办公网络故障报修与恢复办公 WiFi/有线/机房出口断网、变慢、丢包、TLS 阻断，或 CI 打包机、签名机、构建集群断网，影响飞书、Gitea、CI、LeapCore 与客户演示时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，现场排查）、CI 负责人（当前：吴世豪·推断待确认，CI 机与签名机）、后端兼运维（当前：宋祺睿·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，物业/施工/线槽）、行政（当前：侯明月·推断待确认，宽带续费）、外包网络工程师团队；兜底——CTO（当前：丁震宇·推断待确认）① 自检 → ② 提交报障 → ③ 分级 → ④ 响应并群内通报 → ⑤ 分层排查 → ⑥ 临时恢复 → ⑦ 根因修复（含运营商报修） → ⑧ 恢复通知、故障登记与复盘恢复可用的办公网络；故障登记表记录（时间、位置、现象、根因、处理人、耗时）；P0/P1 故障复盘；宽带与线路资产台账；《网络自检清单》待新建500
X-SEC-28办公网络建设升级、带宽专线扩容与机房设备采购新增楼层/机房、人员增长导致带宽不足、网络长期拥堵需整体重做，或需采购防火墙/交换机/模块、新增或升级专线与商宽、服务器上架与机房搬迁时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案评审与审批）、销售负责人（当前：李鹏为·推断待确认，引荐服务商与商务谈价）、运维/交付部署工程师（当前：游家豪·推断待确认，搬运上架）、财务（当前：待指定，付款与发票）、行政（当前：待指定，场地/物业/施工协调）；兜底——CTO（当前：丁震宇·推断待确认）① 需求立项（网络需求文档） → ② CTO 评审方案 → ③ 至少 2 家服务商/运营商勘探报价 → ④ 比价谈价 → ⑤ 采购审批与合同 → ⑥ 施工排期与变更公告 → ⑦ 测试验收 → ⑧ 台账更新与限速策略公告验收通过的网络/机房改造或新增线路；网络需求文档与比价表；验收记录（测试报告、设备打标、机柜整理照片）；更新后的线路台账与硬件清单；网络使用与限速策略公告待新建200
X-SEC-29机房/服务器停机维护、迁移与故障应急（含备份与数据恢复）计划停机检修（坏盘、物业停电、网络维护）、服务器迁移与 IP 切换、安全组/防火墙规则变更，或断电、硬盘/阵列、证书过期、Redis 断连等非计划故障，以及误操作导致数据丢失需恢复、新服务器上线需确认备份时启动；同时覆盖生产数据（云数据库、对象存储、网盘、计费/订单/钱包库、网关与渠道配置）的备份定级、每日校验与定期恢复演练主责——IT 运维/网管（当前：杨明学·推断待确认，机房与硬件）；协同——后端兼运维（当前：宋祺睿·推断待确认，服务迁移/安全组/备份）、运维/交付部署工程师（当前：游家豪·推断待确认，现场与 IP 切换）、Leap 研发负责人（当前：王皓南·推断待确认，研发侧需求与验证）、产品总监（当前：杨萌·推断待确认，对销售/客户通知）、NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、行政（当前：胡则瑾·推断待确认，停电等行政通知）；兜底——CTO（当前：丁震宇·推断待确认）① 变更申请或故障发现 → ② 查服务-负责人台账评估影响 → ③ 审批与公告 → ④ 有序停机/执行或应急止血 → ⑤ 按验证清单验证 → ⑥ 恢复通知 → ⑦ 复盘与台账更新 → ⑧ 生产数据备份定级（RPO/RTO）与跨账号副本 → ⑨ 每日备份校验与每周巡检 → ⑩ 季度恢复演练与整改按时完成且已验证的变更/恢复的服务；基础设施变更单与公告；服务器资产与服务-负责人台账；故障复盘；生产数据备份清单（含 RPO/RTO、保留期、负责人）；每日备份校验与巡检记录；季度恢复演练报告待新建300
X-SEC-30IT 资产领用、设备报修与终端技术支持员工领用实体/非实体 IT 资产、电脑与会议室设备故障报修、新电脑到岗初始化、AI 开发工具与内部工具安装配置求助时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，装机与现场）、后端兼运维（当前：宋祺睿·推断待确认，AI 工具配置支持）、人事负责人（当前：黄莹·推断待确认，审批流配置）、行政（当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，会议室设备）；兜底——CTO（当前：丁震宇·推断待确认）① 提交领用/报修/装机支持单 → ② 部门负责人审批（领用类） → ③ IT 受理分派 → ④ 发放/初始化/远程或现场处理/联系厂商 → ⑤ 台账自动更新 → ⑥ 申请人确认关闭 → ⑦ 沉淀 FAQ → ⑧ 月度对账已发放并登记的资产；已修复或已转送修的设备；完成初始化的新电脑；IT 资产台账（账实相符）；IT 支持 FAQ 与标准安装脚本待优化96
X-SEC-31终端安全管控（飞连/IOA 部署、锁屏与保密规范）为满足等保、研发代码合规与远程办公安全，需要选型采购终端管控/零信任产品、开通账号、下发管控策略，或执行电脑锁屏、重要文件保管、公司账号资产梳理等终端安全规范，以及管控策略引发员工数据异常时启动主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案决策）、人事负责人（当前：黄莹·推断待确认，规范签署与入离职席位联动）、综合部负责人（当前：赵雪冰·推断待确认，公司账号资产梳理）、产品总监（当前：杨萌·推断待确认，规范适用范围）、运维/交付部署工程师（当前：游家豪·推断待确认，终端安装）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 明确合规目标与范围 → ② 选型对比与试用 → ③ 报价审批、合同与下单 → ④ 授权核对 → ⑤ IT 小范围灰度 → ⑥ 分批推广与账号开通 → ⑦ 策略执行（锁屏/白名单/IP 绑定）与检查 → ⑧ 异常反馈与厂商工单 → ⑨ 席位随入离职增减与季度审计覆盖全员终端的管控部署；授权核对表；账号开通通知与使用教程；《终端安全与保密规范》（含锁屏、远程监护、重要文件保管）签署记录；公司账号资产表；季度终端审计报告待优化200
X-SEC-32大会/活动现场网络与设备保障公司举办生态大会、发布会、比赛等大型线下活动，各展区、大赛区、直播区、签到区需要网络、电脑、显示器等 IT 保障时启动，从需求征集一直覆盖到撤场回收主责——IT 运维（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、各展区负责人（当前：待指定）、大会会务负责人（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）① 表单征集需求 → ② 汇总核对库存 → ③ 与场地/运营商/直播方确认布线与分网 → ④ 需求冻结 → ⑤ 备货贴标与搬运布设 → ⑥ 现场测速 → ⑦ 现场值守 → ⑧ 撤场回收冻结版设备与网络需求清单、布线与分网方案、开场前测速记录、设备出库与回收记录待优化128
X-SEC-33飞书自建应用/机器人/CLI 权限申请审批与停用员工为自建飞书应用、机器人、飞书 CLI（含 LeapCore 内 Lark-CLI 授权）申请开放平台权限、发布新版本、调整可见范围或配置登录回调，以及停用不再使用的应用、智能体时启动主责——飞书应用审核管理员（当前：丁震宇·推断待确认）；协同——飞书管理员/人事负责人（当前：黄莹·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、应用申请人；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）① 对照权限分级表自检 → ② 规范命名后在开放平台提审并登记用途 → ③ 机器人通知审核人 → ④ 按风险等级审核（超时转备份）→ ⑤ 发版生效与授权验证 → ⑥ 登记应用台账 → ⑦ 季度盘点与停用审核通过并已发版的应用版本、应用权限台账记录（owner、scope 等级、用途、可见范围、到期日、状态）、停用记录待优化144
X-SEC-34飞书平台管理员事项（席位、功能配置、可见范围、外部分享、Aily）员工遇到飞书功能或权限配置问题、需要管理员后台操作时启动，包括席位增购与开票、审批流/知识库/会议室配置、第三方应用可见范围、跨组织分享、Aily/AI 额度与管理员角色分配，以及需要找飞书服务商顾问的情况主责——飞书管理员（当前：丁震宇·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、飞书服务商顾问（外部）；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）① 查内部飞书 FAQ → ② 提交“飞书管理员事项”工单 → ③ 管理员分类派单 → ④ 后台配置/统一咨询顾问/采购 → ⑤ 回复关单 → ⑥ 共性问题沉淀 FAQ → ⑦ 季度复核管理员角色与席位完成的后台配置或席位订单与发票、工单记录、更新后的内部飞书 FAQ、管理员角色清单待优化120
X-SEC-35敏感数据导出与 AI 分析授权（聊天记录/CRM/业务数据）员工要批量导出飞书聊天记录（个人或群聊）做 AI 分析或分身 skill、导出 CRM/渠道等业务敏感数据，或让无人值守的自动任务读取飞书凭证时，先完成数据负责人确认和安全审批主责——CTO/信息安全审批人（当前：丁震宇·推断待确认）；协同——数据所属业务负责人（如销售负责人，当前：李鹏为·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、法务负责人（当前：待指定）、人事负责人（当前：待指定）、研发运维（当前：宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）① 提交数据使用申请 → ② 按数据等级分级 → ③ 数据负责人确认 → ④ 安全审批（模型、存储、凭证）→ ⑤ 必要时法务意见 → ⑥ 按最小范围导出并脱敏 → ⑦ 约束使用与分享 → ⑧ 到期删除回填审批通过的数据使用申请单、导出记录（范围、时间、存储位置、模型）、到期删除确认待新建60
X-SEC-36新工具与高权限软件安全试用环境需要试用 ClawLite、Hermes、龙虾（OpenClaw）等需要高系统权限或来源未审查的软件，或在本机运行 AI Agent（Claude Code 等）时，先申请隔离环境并按基线配置本机与备份主责——研发运维/云资源管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，审批）、试用申请人；兜底——CTO（当前：丁震宇·推断待确认）① 判定是否需隔离 → ② 提交试用环境申请 → ③ 审批 → ④ 开通云机/虚拟机/容器并配安全组 → ⑤ 凭据私发 → ⑥ 按 Agent 本机基线试用 → ⑦ 登记试用结论 → ⑧ 到期回收带到期日的隔离测试环境、试用结论记录、回收记录；本机 Agent 配置基线与备份记录待新建48
X-SEC-37AI Agent/飞书机器人上线安全检查与权限边界在公司服务器、个人电脑或飞书群部署 OpenClaw、LeapAll、Claude Code、Qoder 等具备执行能力的 Agent/机器人，并开放给 owner 以外的人使用前，以及运行中新增能力或放宽审批时主责——AI 机器人安全负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认，审批）、Agent 研发（当前：岳阳·推断待确认，安全基线）、IT 运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认，红队测试）、机器人 owner；兜底——CTO（当前：丁震宇·推断待确认）① 注册登记 → ② 按部署基线搭建 → ③ 配置身份授权与高危二次确认 → ④ 测试群红队测试 → ⑤ 上线评审 → ⑥ 进入白名单群 → ⑦ 运行审计 → ⑧ 变更重审与下线机器人注册表记录、上线检查表（含红队测试结果）、上线审批记录、运行日志与审计记录待新建180
X-SEC-38服务器上线安全基线与对外演示暴露面检查新开公司服务器或内网机器、给客户机器交付前、在公网部署演示服务（OpenClaw、LeapCore 等）时，上线前完成口令、登录方式和端口暴露面检查并登记主责——IT 运维（当前：杨明学·推断待确认）；协同——研发运维（当前：宋祺睿·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、服务器申请人/演示环境部署人；兜底——CTO（当前：丁震宇·推断待确认）① 用基线模板开机 → ② 部署人自检 → ③ 提交公网暴露申请 → ④ 端口与弱口令扫描 → ⑤ 上线确认并登记 → ⑥ 客户机器交付加安全验收项 → ⑦ 每月复扫 → ⑧ 到期下线上线安全检查单、资产与暴露面台账、扫描报告、事件复盘记录待新建90
X-SEC-39安全扫描与渗透测试申请执行对公司自有生产/测试环境、新装机器、MCP/Agent 接入前进行安全扫描、渗透测试或红蓝对抗时，先申请授权范围，再执行、出报告并移交整改主责——安全测试执行人（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，授权审批）、研发负责人（当前：王皓南·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、跃竞运维（当前：席博田·推断待确认）、被测系统负责人；兜底——CTO（当前：丁震宇·推断待确认）① 提交测试申请（范围、环境、时间窗、手段、禁止动作）→ ② 授权审批 → ③ 准备测试账号与资产白名单 → ④ 执行扫描/渗透 → ⑤ 机器人分级推送发现 → ⑥ 复测去误报与定级 → ⑦ 出报告 → ⑧ 建工单移交 X-SEC-40测试授权单、扫描/渗透报告（分级）、漏洞工单待新建120
X-SEC-40漏洞整改闭环与对外遗留资产清理安全扫描、渗透测试、外部报告或员工发现对外服务存在未授权接口、弱口令/默认口令、密钥泄露、调试端点暴露，或发现无人认领的站点、域名、服务器时，启动“登记定级 → 修复或下线 → 复扫关闭”的闭环主责——安全整改统筹（当前：王皓南·推断待确认）；协同——安全扫描与工单跟踪（当前：魏宗浩·推断待确认）、各服务负责人（当前：宋祺睿、吴世豪、李铭熙、葛家和·推断待确认）、云账号与 DNS 管理（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·部门报送人）① 线索登记 → ② 定级与临时封堵 → ③ 认领责任人 → ④ 修复或下线 → ⑤ 复扫验证 → ⑥ 回复报告人与日报 → ⑦ 更新资产台账与复盘已关闭的漏洞工单（含定级、修复说明、复扫截图）、更新后的对外服务资产台账、遗留站点下线记录（DNS/服务/密钥/云资源/收录均已清理）待新建320
X-SEC-41高危漏洞、供应链投毒与 AI 工具安全通告应急排查外部公开高危 CVE（Linux 内核、nginx、log4j2 等）、依赖包或开发工具被投毒（npm 包、Apifox、litellm）、AI 工具被曝上传代码/.env 或收集遥测、自部署开源服务高危漏洞、外部 skill 带毒或开源协议风险时，统一研判公司是否受影响，组织排查、处置并通报结论主责——安全通告响应负责人（当前：杨明学·推断待确认）；协同——技术研判人（按技术栈指定，当前：王子明、陈晖、张楠·推断待确认）、各服务/项目负责人（当前：吴世豪、岳阳·推断待确认）、全体研发（自查）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 通告登记 → ② 研判影响与定级 → ③ 发布统一通告与排查清单 → ④ 资产比对与自查回收 → ⑤ 升级/修补/轮换凭据 → ⑥ 验证与结论通报 → ⑦ 加固规则沉淀统一安全通告、排查结果回收表（对象 × 是否受影响 × 处置结果）、结论通报、更新后的加固规则与工具准入清单待新建180
X-SEC-42内网安全事件与异常请求溯源处置内网出现异常扫描、端口爆破、疑似中毒，生产环境出现来源不明的请求或机器注册，或外部人员、云厂商发出安全告警与整改建议时，统一上报、隔离、溯源、清除并复盘主责——网络与 IT 运维（当前：杨明学·推断待确认）；协同——发现人/受影响服务负责人（当前：宋祺睿·推断待确认）、日志与研发排查（当前：吴世豪、陈晖、魏宗浩、杨云峰·推断待确认）、行政（终端装机与资产，当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 事件快报 → ② 指派与定级 → ③ 隔离止血 → ④ 日志溯源定位设备 → ⑤ 清除与恢复 → ⑥ 补齐终端防护 → ⑦ 复盘通报安全事件记录单（时间线、来源设备、处置、根因）、复盘与改进项、更新后的终端防护覆盖清单与虚拟机台账待新建120
X-SEC-43等保测评、整改与云安全产品采购产品/系统需要办理或复审等保（如鼎慧通、墨跃启智 AI 教育系统），从确定申报主体与范围、对接测评服务商、驻场测评、逐项整改、采购云安全产品、复测取证，到抽检与续费的全过程主责——等保项目经理（当前：赵雪冰·推断待确认）；协同——技术总对接与采购决策（当前：丁震宇·推断待确认）、系统整改负责人（鼎慧通当前：宋祺睿；AI 教育当前：葛家和、吴世豪·推断待确认）、技术方案（当前：王皓南·推断待确认）、开发（当前：徐鑫宇·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、产品（当前：杨萌·推断待确认）、预算审批（当前：邴龙志·推断待确认）、财务与法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）① 立项定主体与范围 → ② 服务商对接与资产表 → ③ 驻场测评出差距报告 → ④ 整改台账拆解与需求同步 → ⑤ 安全产品采购 → ⑥ 逐项整改留证 → ⑦ 复测与取证归档 → ⑧ 抽检与续费等保测评报告（电子版+纸质版）、整改项台账（含截图证据与复测结果）、安全产品台账（含到期日）、等保脚本仓库、证书主体与使用范围登记待优化375
X-SEC-44数据泄露（含个人信息）事件响应与报告发现或怀疑客户数据、用户个人信息、员工信息或内部敏感数据被未授权访问、外传、误发或公开暴露主责——信息安全负责人（当前：待指定）；协同——研发负责人、法务（当前：待指定）、售后负责人（当前：待指定）、总经办（当前：田杰·部门报送人）；兜底——研发负责人（当前：丁震宇·部门报送人）① 发现上报 → ② 止损隔离 → ③ 影响评估 → ④ 判定是否通知客户/用户/监管 → ⑤ 对外通知 → ⑥ 根因整改 → ⑦ 事件报告归档事件登记、影响评估报告、对外通知记录、整改清单与事件报告待新建125
X-SEC-45个人信息分类分级、保留期限与用户权利请求处理产品收集用户个人信息与客户业务数据，需要分类分级、按期删除，并响应用户或客户的查询、导出、更正、删除、注销请求主责——个人信息保护负责人（当前：待指定）；协同——法务（当前：待指定）、产品负责人（当前：待指定）、后端负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 建立个人信息清单并分级 → ② 定保留期限 → ③ 受理用户请求 → ④ 核验身份 → ⑤ 执行导出/更正/删除/注销并留痕 → ⑥ 回复用户 → ⑦ 每季度清理到期数据个人信息清单、保留期限表、用户请求处理记录、季度清理记录待新建64
X-SEC-46账号与权限定期复核每季度对高权限与关键系统账号（飞书管理员、云平台子账号与 AccessKey、Gitea 管理员与仓库权限、生产服务器 SSH、网关管理员、数据库账号、第三方平台主账号）做复核，清理离职遗留、超范围与长期未用权限主责——IT 运维负责人（当前：待指定）；协同——各系统负责人（当前：待指定）、各部门负责人、人事（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）① 导出各系统账号权限清单 → ② 与在职名单及岗位比对 → ③ 系统负责人与部门负责人确认 → ④ 回收/降权 → ⑤ 出复核报告季度权限复核表、回收/降权记录、复核报告待新建96
X-SEC-47全员信息安全意识培训与考核新人入职、每年度及发生安全事件后，对全员（含实习生、外包与驻场人员）进行信息安全与保密培训、考核和钓鱼演练抽测主责——信息安全负责人（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、各部门负责人；兜底——研发负责人（当前：丁震宇·部门报送人）① 制定年度培训计划 → ② 编制课件与题库 → ③ 入职培训 → ④ 年度全员培训与考试 → ⑤ 钓鱼演练抽测 → ⑥ 统计与补训培训课件与题库、培训与考试记录、演练报告、补训名单待新建80
X-SEC-01新人入职 IT 账号一站式开通与内部系统“找谁”指引待新建192

状态：待新建｜证据：有证据（卡片 15 张 / 会话 10 个）｜优先级：频4 × 耗3 × 跨4 × 险4

  • 适用场景：新员工、实习生、借调人员确定到岗日期后，按岗位清单一次性开通 Gitea、工单、LeapCore 内部版、NewAPI 控制台、PostHog、CRM/渠道系统、企业邮箱、飞书群等账号，并在到岗当天发放“系统-负责人-申请入口”目录
  • 负责人：主责——IT 运维（当前：杨明学·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、Gitea 管理员（当前：宋祺睿·推断待确认）、工单系统管理员（当前：王皓南·推断待确认）、PostHog 管理员（当前：魏宗浩·推断待确认）、NewAPI 管理员（当前：柯逸飞·推断待确认）、CRM/渠道系统管理员（当前：郭逸非、陈子康·推断待确认）、测试负责人（当前：张东郅·推断待确认）、各直属上级；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 入职单触发开通清单 → ② 直属上级确认岗位权限模板 → ③ 拆单派给各系统管理员 → ④ 各系统开通并安全发放凭据 → ⑤ 回填账号台账 → ⑥ 到岗当天发放“找谁”目录 → ⑦ 新人首日自检登录 → ⑧ 台账归档备回收
  • 交付结果：新人到岗当天可登录全部岗位所需系统；一份按人登记的账号台账（系统、账号、权限级别、开通人、开通日期），作为离职回收依据
  • 状态依据：没有入职账号开通清单和统一入口，新人逐个在群里问“账号找谁开”，6～10 月研发群反复出现开号、补权限、问路共约 60 次；账号与初始密码在群聊明文流转，权限分散在 6 个以上管理员手里

1. 场景判定

  • 触发条件：人事发出入职通知或入职单生效；实习生/借调人员确定到岗日；在岗人员转入研发、测试、产品等需要新系统的岗位
  • 典型说法：「账号应该找谁开？」「这得加到新员工入职流程里」「注册 PostHog 找谁来着」「是不是新员工没加进去」「我是新来的测试实习生，需要一个 Gitea 账号」
  • 判断问题：这是一个刚到岗（或即将到岗）的内部人员，需要一次性拿到多个内部系统账号吗？
  • 不归本流程管：单独补开或调整代码仓库权限 → 请走 X-SEC-02；业务系统/管理后台角色调整 → 请走 X-SEC-03；公共邮箱 → 请走 X-SEC-04；外包、外部厂商、子公司外部人员 → 请走 X-SEC-06；离职/调岗回收 → 请走 X-SEC-08；入职手续本身 → 请走 HR-05；工位与电脑 → 请走 ADM-03；云子账号 → 请走 X-SEC-15；AI 编程工具订阅 → 请走 X-SEC-14

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 维护开通清单与台账、拆单派单、到岗当天交付目录 R/A IT 运维（当前：杨明学·推断待确认）
人事 入职单录入姓名拼音、岗位、类别（正式/实习/借调）、到岗日 R 人事负责人（当前：黄莹·推断待确认）
直属上级 确认岗位权限模板、补充特殊仓库或系统 R（权限范围确认） 各部门直属上级
Gitea 管理员 建号、加组织/团队 R Gitea 管理员（当前：宋祺睿·推断待确认）
工单系统管理员 开工单账号、加入对应团队 R 工单系统管理员（当前：王皓南·推断待确认）
测试负责人 测试服账号、测试岗权限模板确认 R 测试负责人（当前：张东郅·推断待确认）
PostHog / NewAPI 管理员 开监控与模型网关控制台账号 R PostHog 管理员（当前：魏宗浩·推断待确认）；NewAPI 管理员（当前：柯逸飞·推断待确认）
CRM/渠道系统管理员 分配业务角色、处理席位 R CRM/渠道系统管理员（当前：郭逸非、陈子康·推断待确认）
CTO 清单与权限模板审定、管理员缺位时兜底 C/兜底 CTO（当前：丁震宇·推断待确认）
新人 首日自检登录、首登改密 I/R（自检） 新入职人员

3. 办之前请准备

  • 新人姓名拼音（作为统一账号名）、企业邮箱前缀、岗位类别（研发/测试/产品/业务/职能）、正式/实习/借调、所属团队与项目、到岗日
  • 直属上级勾选的权限模板，以及模板外的特殊仓库/系统清单（写明理由）
  • 研发岗：本机 SSH 公钥（到岗当天提交即可）
  • 当前“系统-负责人-申请入口”目录最新版（IT 运维每月核对一次）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 入职单生效，自动生成“账号开通清单”任务，带出岗位默认模板 人事 到岗前 ≥ 2 个工作日 飞书入职审批 + 多维表格 开通清单 🔧飞书固化
2 确认权限模板，勾选特殊仓库/系统并写理由 直属上级 收到任务后 1 个工作日内 飞书任务 已确认清单 👤人工判断
3 按系统拆单，派给对应管理员 IT 运维（机器人） 清单确认后 2 小时内 多维表格自动化 各系统子任务 🔧+🤖
4 开通账号：账号名=姓名拼音；凭据用邀请链接或一次性密码链接发到本人邮箱，强制首登改密，禁止在群/私聊发明文 各系统管理员 到岗前 1 个工作日 18:00 前 各系统后台 已开通账号 👤人工判断
5 在台账回填账号名、权限级别、开通日期 各系统管理员 开通当天 多维表格 账号台账 🔧飞书固化
6 到岗当天推送账号清单 + “系统-负责人-申请入口”目录 + 内网/飞连使用说明 IT 运维（机器人） 到岗当天 10:00 前 飞书机器人 新人账号包 🤖自动化
7 逐项登录自检；研发岗配置 git 用户名/邮箱并提交公钥；异常在清单内反馈 新人 到岗首日 18:00 前 清单反馈栏 自检结果 👤人工判断
8 处理自检异常，全部关闭后清单归档 对应系统管理员；IT 运维收口 反馈后 4 个工作小时内 多维表格 归档清单 🔧飞书固化

5. 交付物与模板

  • 交付物：开通清单（每人一条）、账号台账、新人账号包、“系统-负责人-申请入口”目录
  • 建议模板/表单：
    • 开通清单字段：姓名、姓名拼音、企业邮箱、岗位类别、正式/实习/借调、所属团队/项目、到岗日、直属上级、模板外系统及理由、各系统开通状态、开通人、完成时间
    • 岗位权限模板：研发＝Gitea（团队成员）+ 工单 + 测试服 + NewAPI 控制台 + PostHog + LeapCore 内部版；测试＝Gitea（工单仓库 + 按需只读）+ 工单 + 测试服账号；产品＝工单 + LeapCore 内部版 + 设计工具 + 管理后台（测试环境）；业务/职能＝LeapCore 内部版 + CRM/渠道系统（按角色）+ 企业邮箱
    • 目录字段：系统名、用途、访问地址、负责人岗位、备岗、申请入口、开通时限

6. 异常与升级

  • 权限范围以直属上级确认的模板为准；模板外申请敏感仓库、生产权限或跨主体系统，以及直属上级与 IT 运维意见不一 → 按对应 SOP 单独审批，争议由 CTO 兜底裁定
  • 系统管理员 1 个工作日内未开通 → 机器人催办 → 升级 IT 运维，仍未完成升级 CTO（到岗当天 12:00）
  • CRM 等系统席位已满 → CRM 管理员当天回收闲置席位或申请扩容 → 升级直属上级与 CTO（1 个工作日内）
  • 发现同一人已有旧账号 → 启用旧账号并合并台账，不重复建号 → IT 运维当天处理
  • 模板外申请敏感仓库或生产权限 → 转 X-SEC-02 / X-SEC-18 单独审批
  • 发现凭据被发到群聊 → 立即改密并按 X-SEC-10 处理 → 通知 CTO（当天）

7. 衡量指标

  • 到岗当日就绪率 = 到岗当天 18:00 前全部模板账号可登录的新人数 / 当期新人数，目标 ≥ 95%
  • 开通周期 = 清单确认到最后一个系统开通的工作小时数，目标 ≤ 8 小时
  • 新人“找谁开账号”群内提问次数，目标每月 ≤ 2 次
  • 明文凭据外发次数（群聊/私聊发密码），目标 0
  • 补开率 = 到岗后 7 天内补开的系统数 / 模板系统总数，目标 ≤ 5%

8. 低效诊断

  • 新人登录报错后才发现没加账号，开号依赖事后补救｜依据：「Leap产研测」2026-06
  • 谁有管理员权限、谁能把人拉进组织不清楚，申请在群里来回转｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 各系统管理员不同，没有统一目录，新人逐个问“找谁”｜依据：「Leap产研测」2026-07、「研发通知」2026-07、「Leap产研测」2026-10
  • 统一发放后，日常补权限仍靠被卡住时临时找人（runner、COS、测试服）｜依据：「Leap产研测」2026-07
  • 群内提及“SOP 文档写了谁开号”，但文档找不到、执行人与文档不一致｜依据：「Leap产研测」2026-10
  • 账号、初始密码、验证码在群里明文发送，曾出现“大家都知道密码了”｜依据：「工程咨询产研」2026-03、「Leap产研测」2026-07
  • 开号后忘发密码、漏给仓库权限，需二次补发｜依据：「鼎慧产研决策部」2026-07
  • 权限改动没有评估，误伤 CI 部署密钥｜依据：「LeapCore（archived）」2026-05
  • 业务角色由谁批准不清，影响渠道系统使用｜依据：「公司内FDE」2026-09、「公司内FDE」2026-10
  • 外包、市场等非研发人员开号无规则，一律口头开｜依据：「Leap产研决策部」2026-08

9. 分支变体

  • 研发岗：Gitea 团队成员 + 工单 + 测试服 SSH 公钥 + NewAPI/PostHog 控制台
  • 测试岗/测试实习生：只给工单仓库，代码仓库按需只读；测试服账号由测试负责人开
  • 产品/设计：工单、LeapCore 内部版、设计工具、管理后台测试环境
  • 业务/总经办/财务/市场：CRM（需本人先飞书登录一次，再由管理员配角色）、渠道系统、LeapCore 内部版；不开代码仓库
  • 实习生/试用期：最小权限，不拉入 Gitea 团队，仅开具体仓库只读（见 X-SEC-08 规则）
  • 跃竞团队：Gitea + openVPN 与连接密钥 + 内网接口文档/测试环境 wiki 一并发放
  • 子公司/借调人员：独立 Gitea 组织或项目级权限，挂在项目名下
  • 外部协作者：不走本流程 → X-SEC-06

10. 待确认问题

  • 本流程主责是否定为 IT 运维？Gitea、工单等管理员是否接受由 IT 运维派单？
  • 是否已有群里提到的“开号 SOP 文档”？如有，以哪份为准，链接放哪里？
  • 岗位权限模板（研发/测试/产品/业务）是否按上表定稿？由谁审定？
  • Gitea、工单、CRM 是否计划统一接飞书登录（见 X-SEC-05），以减少单独建号？
  • “到岗前 1 个工作日完成开通”是否可行？实习生是否也适用？
  • CRM 席位上限如何管理，谁有权回收闲置席位？
X-SEC-02代码仓库（Gitea）账号与仓库权限开通、重置与封禁待优化96

状态：待优化｜证据：有证据（卡片 17 张 / 会话 13 个）｜优先级：频4 × 耗2 × 跨3 × 险4

  • 适用场景：新人、转岗、新项目、子公司或外部人员需要 Gitea 账号、组织/团队/仓库权限、SSH 公钥，或忘记密码、仓库迁入组织，或离职/违规需要封号
  • 负责人：主责——Gitea 管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认）、组织/仓库 Owner（当前：岳阳、王子明、李铭熙、吴世豪·推断待确认）、研发负责人（当前：王皓南·推断待确认）、人事（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交仓库权限申请 → ② 直属上级/仓库 Owner 确认范围 → ③ 管理员建号并发邀请链接 → ④ 按团队模板授权 → ⑤ 申请人配置 git 身份与公钥并验证 → ⑥ 台账登记 → ⑦ 重置/封禁按单处理 → ⑧ 季度权限盘点
  • 交付结果：可用的 Gitea 账号与按最小授权配置的组织/团队/仓库权限；权限台账（账号、组织、团队、仓库、角色、期限、批准人）
  • 状态依据：建号做法固定（姓名拼音命名、关闭自助注册），但 1～10 月几乎全部由 CTO 一人手工建号，常因开会、出差延后；建号与仓库授权分属不同人，申请人要跑两处；密码明文私发、重复开号、邮件重置收不到等问题反复出现

1. 场景判定

  • 触发条件：访问仓库报 403/404；新项目或新仓库需要成员；仓库要迁入组织；忘记密码；需要 CI token；离职、试用不通过、违规需封号
  • 典型说法：「给我开个 git 号」「这个仓库下没有某某，需要加一下」「我这 403 了」「git 账号帮忙重置一下密码」「谁能帮我加一下权限」「仓库权限不归我管」
  • 判断问题：问题是否只涉及 Gitea（账号、组织、团队、仓库、token、公钥）？
  • 不归本流程管：入职一次性多系统开通 → 请走 X-SEC-01；服务器/测试机 SSH → 请走 X-SEC-17；生产资源访问 → 请走 X-SEC-18；外包/外部团队首次接入 → 先走 X-SEC-06；离职全量回收 → 请走 X-SEC-08；代码签名证书 → 请走 X-SEC-23

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
Gitea 管理员 建号、重置、封禁、组织创建、维护台账 R/A Gitea 管理员（当前：宋祺睿·推断待确认）
组织/仓库 Owner 判断并授予本组织/仓库权限、生成 CI token R 组织/仓库 Owner（当前：岳阳、王子明、李铭熙、吴世豪·推断待确认）
研发负责人 制定岗位权限模板、敏感仓库授权把关 R（敏感仓库审批） 研发负责人（当前：王皓南·推断待确认）
CTO 跨主体/子公司组织授权、管理员缺位时兜底 C/兜底 CTO（当前：丁震宇·推断待确认）
人事 提供花名册（岗位、正式/实习）、离职通知 C 人事（当前：待指定）
申请人/直属上级 提交申请、确认范围 R（申请） 各申请人

3. 办之前请准备

  • 姓名拼音、企业邮箱（与 git 全局配置的 user.email 一致，才能关联账号和头像）
  • 需要的组织、团队或仓库清单，所需角色（只读/开发/维护），使用期限
  • 岗位类别（研发/测试/产品/实习/外部），直属上级
  • SSH 公钥（如需 SSH 推拉）；仓库迁移需写明源仓库与目标组织

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“仓库权限申请”（账号、组织/仓库、角色、期限、理由） 申请人 需要前 1 个工作日 飞书审批 申请单 🔧飞书固化
2 确认范围：模板内自动通过；模板外由仓库 Owner 审；LeapCore 等敏感仓库由研发负责人审 直属上级/仓库 Owner 提交后 4 个工作小时内 飞书审批 审批结果 👤人工判断
3 建号（命名＝姓名拼音，机器人账号以 -bot 结尾），用邀请/重置链接发到企业邮箱，强制首登改密；先查是否已有旧号 Gitea 管理员 审批通过后 4 个工作小时内 Gitea API 脚本 账号 🤖+👤
4 加入对应团队授权，不逐人逐仓库加；新建仓库默认 private 并挂到团队 组织/仓库 Owner 与第 3 步同日 Gitea 团队 权限配置 👤人工判断
5 配置 git 用户名/邮箱、上传 SSH 公钥，拉取验证；失败在申请单内反馈 申请人 收到链接后 1 个工作日内 本机/Gitea 验证结果 👤人工判断
6 回填台账：账号、团队、仓库、角色、期限、批准人 Gitea 管理员（机器人） 开通当天 多维表格 权限台账 🤖自动化
7 改动权限或 deploy key 前，确认是否影响 CI/部署密钥，改后通知 CI 负责人 仓库 Owner 改动前 Gitea/CI 变更记录 👤人工判断
8 密码重置：身份核验后发重置链接；邮件不可达时管理员重置为一次性密码 Gitea 管理员 提出后 2 个工作小时内 Gitea 重置记录 👤人工判断
9 封禁：收到离职/试用终止/违规通知后先封号，再转移其名下仓库 Gitea 管理员 通知后 1 小时内（违规立即） Gitea 封禁记录 🤖+👤
10 季度盘点：对照花名册清理离职、超期、超范围权限；每组织管理员不超过 2 人 Gitea 管理员 每季度首月 10 日前 多维表格 + 脚本 盘点报告 🤖自动化

5. 交付物与模板

  • 交付物：Gitea 账号、团队权限配置、权限台账、季度盘点报告
  • 建议模板/表单：
    • 仓库权限申请字段：申请人、姓名拼音、企业邮箱、岗位类别、组织、团队/仓库、角色（只读/开发/维护/Owner）、期限、理由、是否敏感仓库、批准人
    • 团队模板：研发团队（开发）、测试团队（工单仓库 + 指定仓库只读）、产品团队（只读 + 工单）、外包团队（单仓库或独立组织）、实习团队（单仓库只读/开发，不进主团队）

6. 异常与升级

  • 敏感仓库（LeapCore、LeapAgent 等）的授权由研发负责人审批后执行；跨主体/子公司组织授权、研发负责人与仓库 Owner 意见不一 → 升级 CTO 裁定（当天）
  • 管理员 4 个工作小时内未处理 → 机器人催办 → 升级 CTO（当天）
  • 申请人自称权限已开仍 403/公钥无效 → 管理员核对团队与公钥格式 → 2 个工作小时内未解决升级研发负责人
  • 权限改动导致 CI/部署失败 → 回滚权限，通知 CI 负责人 → 升级研发负责人（30 分钟内）
  • 发现账号密码或 token 发到群聊 → 立即重置并按 X-SEC-11 处理 → 通知 CTO（当天）
  • 离职/违规人员账号未在 1 小时内封禁 → 人事直接通知 CTO 执行

7. 衡量指标

  • 开通周期 = 申请提交到权限可用的工作小时数，目标 ≤ 8 小时
  • 单点依赖率 = CTO 亲自处理的开号单数 / 总开号单数，目标 ≤ 10%
  • 封禁及时率 = 通知后 1 小时内封禁的比例，目标 100%
  • 权限误改导致 CI 中断次数，目标 0
  • 季度盘点发现的超期/离职残留账号数，目标逐季下降至 0

8. 低效诊断

  • 建号权限集中在一人，“开号就得找他，因为不知道还有谁能开”，开会/吃饭时开号延后数小时｜依据：「鼎慧产研决策部」2026-03、「LeapAll（Deprecated）」2026-04、「跃玩项目组」2026-03
  • 谁能把人拉进组织不清楚，申请人和有权限的人都以为对方不能拉｜依据：「Leap产研测」2026-06
  • 管理员不知道谁是测试谁是研发，无法按岗位授权｜依据：「鼎慧产研决策部」2026-07
  • 新仓库每次都要重新把人加到团队，权限漏更新｜依据：「【行业版Leapcore】工程版」2026-08、「信创LeapCore客户端适配」2026-07
  • 访问被拒后才发现缺权限，来回确认｜依据：「信创LeapCore客户端适配」2026-07、「Leap产研测」2026-08
  • 子公司外部技术负责人加入时，开哪个组织、开多大权限临时讨论｜依据：「鼎慧产研决策部」2026-07
  • 开权限需多次 @ 转派，配置文件、面板密码直接群发｜依据：「LeapPay」2026-04、「LeapPay」2026-07
  • 公钥作为文件发群，每个新成员都在群里问一遍怎么开｜依据：「开源聚变入驻问题沟通群」2026-02、「开源聚变入驻问题沟通群」2026-03
  • 新人 VPN 与连接密钥要事后提醒才发｜依据：「跃玩项目组」2026-07
  • 第三方 key、bucket 归谁管不清，失效时临时开新号｜依据：「Leap产研测」2026-05

9. 分支变体

  • 仓库迁入组织：发起方转移 + 接收方确认，管理员先把发起人加入目标组织
  • 实习/试用：不进主团队，只对具体仓库加协作者，只读或开发权限（见 X-SEC-08）
  • 测试人员：默认只给工单仓库，代码仓库对方提出再给只读
  • 外包：只开一个仓库或独立组织；子公司（曜途等）：独立组织 + 开放平台权限
  • CI token：由组织 Owner 生成，普通成员无权限；机器人账号走同一申请
  • GitHub 组织、Linear 等研发工具：申请同表，工具白名单由 IT 运维加
  • 跃竞团队：Gitea 账号 + openVPN 一并开通

10. 待确认问题

  • 主责是否从 CTO 移交给 Gitea 管理员？是否再授权 1～2 名备岗管理员？
  • 敏感仓库清单（LeapCore、LeapAgent 等）由谁维护，审批人是谁？
  • 是否接入飞书登录（OAuth）替代邮件重置？邮件发不出的问题何时修？
  • 每组织“只留 2 个管理员”是否作为硬规则？
  • 季度盘点由谁执行，花名册从人事哪里取？
X-SEC-03内部业务系统与管理后台账号/角色开通及密码重置待优化96

状态：待优化｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频3 × 耗2 × 跨4 × 险4

  • 适用场景：内部同事需要 LeapCore 内部版、字字可研等产品管理后台（测试/正式）、渠道系统/CRM、LeapPPT 后台等业务系统账号或角色，或忘记密码，或需要收回超范围的管理员权限
  • 负责人：主责——业务系统 Owner（当前：字字可研后台——宋祺睿；LeapCore 内部版——杨萌；渠道系统/CRM——陈子康；LeapPPT 后台——马漳毓·推断待确认）；协同——研发负责人（当前：王皓南·推断待确认）、LeapPPT 管理员分配人（当前：陈梦琪·推断待确认）、申请人直属上级；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交系统角色申请 → ② 系统 Owner/上级审批 → ③ 飞书登录或管理员建号 → ④ 分配角色并设期限 → ⑤ 安全发放凭据 → ⑥ 台账登记 → ⑦ 到期回收 → ⑧ 季度管理员盘点
  • 交付结果：申请人以本人账号按所需角色登录对应系统；系统-账号-角色台账（含临时授权到期日）
  • 状态依据：渠道系统已有“飞书登录申请 + 管理员分配角色”做法、LeapCore 内部版有部署公告，但 1～10 月仍出现共用账号、群里问密码、初始密码大群公开、临时全权限未回收，并发生过一次 LeapPPT 后台管理员误操作兑换券的事故

1. 场景判定

  • 触发条件：同事需要登录某业务系统或后台；需要更换角色（如财务、管理员、业务审核）；登录失败、忘记密码；发现某人权限超出岗位范围
  • 典型说法：「测试环境的号开了吗」「后台登不进去，是谁在管」「账号是哪个」「后台搜不到这个用户啊」「这个权限怎么开？」
  • 判断问题：要开的是公司内部人员在业务系统/管理后台里的账号或角色吗？
  • 不归本流程管：客户、渠道客户侧账号开通与登录问题 → 请走 X-DLV-15 / X-CS-05；Gitea → 请走 X-SEC-02；云控制台 → 请走 X-SEC-15；生产服务器/数据库访问 → 请走 X-SEC-18；系统登录方式改造 → 请走 X-SEC-05；敏感数据导出 → 请走 X-SEC-35

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
业务系统 Owner 审批本系统角色、开通/重置、维护角色矩阵 R/A 字字可研后台——研发运维（当前：宋祺睿·推断待确认）；LeapCore 内部版——产品总监（当前：杨萌·推断待确认）；渠道系统/CRM——渠道系统研发（当前：陈子康·推断待确认）；LeapPPT 后台——LeapPPT 研发（当前：马漳毓·推断待确认）
研发负责人 功能灰度权限、跨系统角色口径 R（灰度/跨系统） 研发负责人（当前：王皓南·推断待确认）
运营管理员 LeapPPT 后台管理员的唯一分配人 R LeapPPT 管理员分配人（当前：陈梦琪·推断待确认）
直属上级 确认申请人需要该角色 C 各部门直属上级
CTO 管理员权限收回等决策、兜底 A（升级） CTO（当前：丁震宇·推断待确认）
申请人 提交申请、首登改密 R（申请） 各申请人

3. 办之前请准备

  • 系统名称与环境（测试/正式/预览）
  • 所需角色（普通/业务审核/财务/管理员）、用途、期限（临时授权必须填到期日）
  • 本人飞书账号；后台需手机号的，由本人在申请单里填，不发群
  • 是否需要访问公司内网（后台有 IP 限制，外网需飞连，见 X-SEC-25）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“业务系统角色申请”（系统、环境、角色、用途、期限） 申请人 需要前 1 个工作日 飞书审批 申请单 🔧飞书固化
2 审批：普通角色由直属上级批；财务/管理员角色由系统 Owner 批 直属上级/系统 Owner 提交后 4 个工作小时内 飞书审批 审批结果 👤人工判断
3 开通：内部员工优先“飞书登录”后由管理员分配角色；不支持飞书登录的系统由管理员建本人账号，禁止共用账号 系统 Owner 审批后 4 个工作小时内 系统后台 账号/角色 👤人工判断
4 发放凭据：一次性链接或短信，强制首登改密；验证码只发本人 系统 Owner 与第 3 步同时 系统/短信 可登录账号 🤖自动化
5 登记台账，临时授权设到期提醒 系统 Owner（机器人） 开通当天 多维表格 账号角色台账 🔧飞书固化
6 到期自动提醒，未续批即降级或停用 系统 Owner 到期当天 多维表格自动化 回收记录 🔧+🤖
7 密码重置：本人在审批单或后台“用户管理”发起，管理员核验身份后重置 系统 Owner 提出后 2 个工作小时内 系统后台 重置记录 👤人工判断
8 季度盘点：每系统超级管理员 ≤ 2 人，清理离职、转岗、超范围角色 系统 Owner 每季度首月 10 日前 多维表格 盘点报告 👤人工判断

5. 交付物与模板

  • 交付物：本人账号与角色、账号角色台账、季度盘点报告、各系统角色矩阵
  • 建议模板/表单：
    • 申请字段：申请人、部门、系统、环境、角色、用途、开始日、到期日、直属上级、系统 Owner 审批
    • 角色矩阵字段：系统、角色名、可见数据范围、可操作功能（含导入导出、批量删除）、审批人、是否允许临时授权
    • 测试账号公告：环境、账号用途、数据会否清空、维护人（放群公告/文档，不在群里反复转发密码）

6. 异常与升级

  • 升级条件：后台误操作造成数据事故、需要收回管理员权限、系统 Owner 与研发负责人对角色口径意见不一 → 系统 Owner 升级 CTO 拍板；常规角色开通与重置由系统 Owner 直接决定
  • 管理员误操作或批量导入导出出错（如兑换券）→ 立即冻结相关管理员账号、导出操作日志、开发评估恢复 → 升级 CTO（1 小时内），事后只保留一个管理员分配人
  • 发现临时授权未回收、可看到全部客户/财务数据 → 当天降级 → 通知直属上级与系统 Owner
  • 后台搜不到用户、账号归属哪套服务不清 → 系统 Owner 核对服务实例后注册 → 1 个工作日内
  • 新设备需短信验证码 → 验证码发本人手机，不经他人转发
  • 共用账号被发现 → 当天为每人开独立账号，共用账号改密停用

7. 衡量指标

  • 开通周期 = 申请提交到可登录的工作小时数，目标 ≤ 8 小时
  • 共用账号数（多人共用一个后台账号），目标 0
  • 临时授权到期回收率，目标 100%
  • 每系统超级管理员人数，目标 ≤ 2
  • 后台误操作导致的数据事故次数，目标 0

8. 低效诊断

  • 产品长期用他人后台账号登录，互相挤号，缺少审计｜依据：「工程咨询产研」2026-02
  • 测试环境账号谁开不清楚，反复追问“号开了吗”｜依据：「工程咨询产研」2026-01、「工程咨询产研」2026-02
  • 邀请码机制被测试指出有被猜测风险，开号渠道不统一｜依据：「工程咨询产研」2026-02
  • LeapCore 内部版初始密码在大群公开，强制改密后又忘记，企业地址没放置顶｜依据：「跃迁AI总动员」2026-06、「跃迁AI总动员」2026-07
  • 账号属于哪套服务（自部署实例与公司测试服务）分不清，先试错再申请｜依据：「Leap反馈群」2026-09
  • 渠道系统账号密码在群里被反复询问，测试账号密码直发群里｜依据：「渠道系统优化」2026-07、「渠道系统优化」2026-09
  • 为跑通全流程临时给的财务全权限未回收，可看到所有客户｜依据：「渠道系统优化」2026-10
  • 开权限需要在群里提供手机号，个人信息在群内流转｜依据：「字字可研项目群」2026-04
  • 后台管理员过多，批量删除和导入导出无二次确认与日志，出事后才收权｜依据：「LeapPPT客诉问题」2026-07

9. 分支变体

  • 测试环境（可宽松，Owner 直接开）与正式环境（必须审批）
  • 内部员工（飞书登录 + 分配角色）与外部渠道账号（管理员新建，走 X-DLV-15）
  • 预览环境测试账号：统一公告维护，数据会定期清空
  • 业务用户邀请码注册：邀请码绑定手机号，由产品分配额度
  • 功能灰度权限：由研发负责人决定，后端按名单开通
  • LeapPPT 后台：所有管理员由唯一分配人开通，批量操作需二次确认

10. 待确认问题

  • 各系统 Owner 是否按上表确认？是否需要一个总的“业务系统账号”归口人？
  • 渠道系统的财务、管理员、业务审核角色矩阵由谁定稿？
  • 临时授权默认期限定多久（建议 7 天）？
  • 管理后台 IP 限制下，外网访问统一走飞连是否可行？
  • LeapPPT 等后台何时补批量操作二次确认和审计日志？
X-SEC-04企业邮箱与公共邮箱开通授权待优化27

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频3 × 耗1 × 跨3 × 险3

  • 适用场景：新人或项目需要个人企业邮箱；业务需要对外统一收发的公共邮箱（售后、HR、笔试、合作商、报名收集）；系统需要用公共邮箱 SMTP 发件；公共邮箱成员增减
  • 负责人：主责——人事负责人（当前：黄莹·推断待确认）；协同——飞书邮箱管理员（当前：丁震宇·推断待确认）、公共邮箱使用部门负责人；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交邮箱申请 → ② 判断类型（个人/公共/SMTP）→ ③ 创建邮箱或加成员 → ④ SMTP 授权码安全发放 → ⑤ 登记公共邮箱负责人 → ⑥ 人员变动同步移除 → ⑦ 季度核对
  • 交付结果：可用的个人或公共邮箱；公共邮箱台账（邮箱名、用途、负责人、成员、是否开 SMTP、绑定系统）
  • 状态依据：开通本身较快，但谁能开邮箱要问人，开邮箱曾因遗忘被催办；曾出现对外售后邮箱留的是个人邮箱、售后邮件无人处理，被发现后才补建公共邮箱；HR 邮箱成员靠口头增减

1. 场景判定

  • 触发条件：新人入职；项目用公司邮箱注册外部平台（如 AI Gateway、合作计划）；对外公布联系邮箱；程序需要发告警/通知邮件；岗位变动需要加入或移出公共邮箱
  • 典型说法：「帮我开个邮箱」「我的邮箱啥时候给我开」「给同事添加公共邮箱的权限是找你吗」「需要再开个公共邮箱」
  • 判断问题：要开的是公司飞书邮箱（个人或公共），或要给公共邮箱加减成员、取 SMTP 授权吗？
  • 不归本流程管：外部平台账号本身的台账 → 请走 X-SEC-12；飞书应用/机器人权限 → 请走 X-SEC-33；入职全量账号 → 请走 X-SEC-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
人事 个人邮箱开通、公共邮箱成员随人员变动增减 R/A 人事负责人（当前：黄莹·推断待确认）
飞书邮箱管理员 公共邮箱创建、SMTP/IMAP 授权码、邮箱后台配置 R 飞书邮箱管理员（当前：丁震宇·推断待确认）
公共邮箱负责人 每日处理来信、维护成员名单 R 使用部门指定人
部门负责人 批准公共邮箱用途与成员 R（公共邮箱审批） 各部门负责人
申请人 提交申请、首登改密 R（申请） 各申请人

3. 办之前请准备

  • 个人邮箱：姓名拼音、入职日期
  • 公共邮箱：建议邮箱名、用途、对外公布位置（官网/商城/招聘/活动报名）、负责人及备岗、成员名单
  • SMTP：使用的系统名、发件场景、预计发件量

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 个人邮箱随入职单自动开通（拼音@公司后缀） 人事 到岗前 1 个工作日 飞书入职 + 邮箱后台 个人邮箱 🔧飞书固化
2 公共邮箱/SMTP 提交“邮箱申请” 申请人 需要前 2 个工作日 飞书审批 申请单 🔧飞书固化
3 部门负责人审批用途与成员；对外联系邮箱必须用公共邮箱 部门负责人 1 个工作日内 飞书审批 审批结果 👤人工判断
4 创建公共邮箱并按名单授权（成员 ≥ 2 人） 飞书邮箱管理员 审批后 1 个工作日内 飞书邮箱后台 公共邮箱 🔧飞书固化
5 如需 SMTP，生成授权码，经一次性链接发给系统负责人，不在聊天发明文 飞书邮箱管理员 与第 4 步同日 邮箱后台 授权码 👤人工判断
6 登记台账，配置新邮件飞书提醒到负责人 飞书邮箱管理员 开通当天 多维表格 + 机器人 公共邮箱台账 🔧+🤖
7 人员入转离时同步增减公共邮箱成员 人事 异动生效当天 飞书邮箱后台 成员变更记录 🔧飞书固化
8 季度核对：成员、负责人、24 小时未读来信 公共邮箱负责人 每季度首月 10 日前 多维表格 核对记录 👤人工判断

5. 交付物与模板

  • 交付物：个人/公共邮箱、SMTP 授权码（交系统负责人保管）、公共邮箱台账
  • 建议模板/表单：公共邮箱台账字段——邮箱地址、用途、对外公布位置、负责人、备岗、成员、是否开 SMTP、绑定系统、创建日期、最近核对日期

6. 异常与升级

  • 对外渠道留了个人邮箱 → 3 个工作日内改为公共邮箱并转发历史来信 → 升级部门负责人
  • 公共邮箱来信 1 个工作日未处理 → 机器人提醒负责人和备岗 → 升级部门负责人
  • 申请查看他人个人邮箱 → 拒绝；确有业务需要走 X-SEC-35 授权
  • SMTP 授权码外泄 → 立即重置授权码 → 通知 CTO（当天）

7. 衡量指标

  • 个人邮箱到岗就绪率，目标 100%
  • 公共邮箱开通周期 = 审批通过到可用的工作日数，目标 ≤ 1 天
  • 对外公布的个人邮箱数，目标 0
  • 公共邮箱来信 24 小时处理率，目标 ≥ 95%

8. 低效诊断

  • 开邮箱依赖单人处理，忙时遗忘，需催问“什么时候开”｜依据：「鼎慧产研决策部」2026-05
  • 用公司邮箱注册外部平台后，云权限不足又要另找人开｜依据：「鼎慧产研决策部」2026-05

9. 分支变体

  • 个人邮箱：随入职开通、离职停用
  • 公共邮箱：售后、HR、笔试、合作商统计、报名收集；HR 邮箱涉及候选人信息，成员仅限人事及指定负责人
  • SMTP/IMAP：程序发告警或通知时使用，授权码由系统负责人保管

10. 待确认问题

  • 邮箱开通归口定为人事还是 IT/飞书管理员？
  • “对外联系邮箱必须是公共邮箱”是否作为硬规则发布？
  • HR 公共邮箱成员名单由谁批准？
  • SMTP 授权码统一存放在哪个密码工具？
X-SEC-05内部系统接入飞书统一登录（SSO）与登录方式变更待优化36

状态：待优化｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗3 × 跨2 × 险3

  • 适用场景：内部系统、渠道系统、云平台、PVE、网盘等要用飞书登录替代自建账号，或要撤销独立管理员账号、改变登录方式时
  • 负责人：主责——IT 运维（当前：杨明学·推断待确认）；协同——系统开发者（当前：宋祺睿、葛家和·推断待确认）、系统管理员（当前：郭逸非·推断待确认）、飞书管理员（当前：丁震宇·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记接入需求 → ② 按模板创建飞书应用（最小权限）→ ③ 飞书管理员审批权限与可用范围 → ④ 测试环境验证 → ⑤ 账号迁移与独立管理员账号撤销 → ⑥ 发布登录方式变更通知 → ⑦ 更新系统登录台账
  • 交付结果：系统可用飞书账号登录，独立账号已停用或封存；系统登录方式台账；登录变更通知
  • 状态依据：基建已能用飞书/飞连登录，云配置负责人已指定，渠道系统、LeapOTA 有可参考实现；但没有标准接入指南，每个系统各接一遍；管理员账号撤销只在群里一句话通知，无变更记录

1. 场景判定

  • 触发条件：新上线内部系统；某系统账号要逐个手工建；需撤销某系统独立管理员账号；云平台/基建要统一登录
  • 典型说法：「等机房备案搞完就直接上飞书 SSO」「就一个重定向 URL + 权限就能跑起来登录」「以后都飞书登录了」「以后用飞书的账户来登录就行」
  • 判断问题：这次要改的是“怎么登录”这个系统，而不是给某个人开权限吗？
  • 不归本流程管：给个人开系统角色 → 请走 X-SEC-03；飞书应用/机器人一般权限申请 → 请走 X-SEC-33；远程接入（飞连/VPN）方案 → 请走 X-SEC-25；域名与证书 → 请走 X-SEC-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 维护接入模板与登录台账、云/基建 SSO 配置 R/A IT 运维（当前：杨明学·推断待确认）
系统开发者 创建飞书应用、完成登录接入与账号映射 R 系统开发者（当前：宋祺睿、葛家和·推断待确认）
系统管理员 撤销独立账号、发布变更通知 R 系统管理员（当前：郭逸非·推断待确认）
飞书管理员 审批应用权限范围与可用人员 R（权限审批） 飞书管理员（当前：丁震宇·推断待确认）
系统用户 按通知切换登录方式 I 相关人员

3. 办之前请准备

  • 系统名称、访问域名、测试与正式环境地址、重定向 URL
  • 需要的飞书权限最小集（如通讯录只读姓名/邮箱），可用人员范围
  • 现有独立账号清单、管理员账号清单
  • 账号映射规则（飞书 OIDC 无 username 时用企业邮箱前缀）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在登录台账登记接入需求（系统、用户范围、现有账号数、计划切换日） 系统开发者 开发启动时 多维表格 接入登记 🔧飞书固化
2 按接入模板创建飞书应用，只申请最小权限，配重定向 URL 系统开发者 登记后 2 个工作日内 飞书开放平台 + 公共 SSO 组件 应用草稿 🔧+🤖
3 审批权限范围与可用人员（默认仅创建者可用，需开放到目标部门） 飞书管理员 提交后 1 个工作日内 飞书管理后台 已发布应用 👤人工判断
4 测试环境验证：登录、账号映射、离职人员无法登录 系统开发者 发布后 2 个工作日内 测试环境 验证记录 👤人工判断
5 迁移老用户；撤销独立管理员账号，仅保留 1 个应急账号存入密码库 系统管理员 切换日当天 系统后台 账号清理记录 👤人工判断
6 发布变更通知：生效日、登录入口、旧账号停用时间、问题联系人 系统管理员 切换前 ≥ 2 个工作日 飞书群公告 变更通知 🔧飞书固化
7 更新登录台账，系统纳入离职自动失效范围 IT 运维 切换后 1 个工作日内 多维表格 台账更新 🔧飞书固化

5. 交付物与模板

  • 交付物：已发布飞书应用、登录方式台账、变更通知、应急账号封存记录
  • 建议模板/表单：
    • 飞书应用接入模板：权限最小集、重定向 URL 规范、账号映射规则、可用范围、审批人、参考实现仓库
    • 登录台账字段：系统、环境、登录方式（飞书/飞连 OIDC/独立账号）、应用 ID、开放范围、应急账号存放位置、负责人、切换日期

6. 异常与升级

  • 应用权限在最小集内的由飞书管理员审批后执行；申请超出最小集、开放到全员或涉及消息发送/全量通讯录的，飞书管理员与 IT 运维意见不一时 → 升级 CTO 裁定（1 个工作日内）
  • 飞书 OIDC 字段不满足系统需要 → 改用飞连 OIDC 或企业邮箱映射 → 升级 IT 运维（2 个工作日内定方案）
  • SSO 依赖域名/备案未就绪 → 先用内网或飞连临时访问，备案进度按 X-SEC-20 跟踪 → 升级 CTO
  • 申请权限超出最小集（如全量通讯录、消息发送）→ 退回修改 → 飞书管理员当天处理
  • 切换后有人无法登录 → 系统管理员 4 个工作小时内处理；影响业务时临时启用应急账号并记录

7. 衡量指标

  • 飞书登录覆盖率 = 已接入飞书登录的内部系统数 / 内部系统总数，目标逐季提升，年底 ≥ 80%
  • 单系统接入周期 = 登记到切换完成的工作日数，目标 ≤ 5 天
  • 无变更通知的登录方式变更次数，目标 0
  • 离职后仍能登录的系统数（抽查），目标 0

8. 低效诊断

  • 各系统账号分别手工建，默认口令在群里公开发送｜依据：「鸽子群模态分群」2026-01
  • SSO 上线被域名与机房备案卡住，且飞书 OIDC 缺 username 字段需再套一层｜依据：「鸽子群模态分群」2026-01
  • 云平台配置此前都找一个人，后来才指定专人｜依据：「技术部」2026-04
  • 每个系统都靠“直接抄”其他项目代码接入，没有标准指南，权限范围谁审不清｜依据：「安全讨论」2026-10
  • 管理员账号撤销、改飞书登录只在群里一句话通知，无变更记录｜依据：「跃迁AI总动员」2026-08

9. 分支变体

  • 云平台（腾讯云等）与 PVE：接飞书/飞连 OIDC，老用户不受影响，仅新用户走新方式
  • Gitea、Cloudreve 网盘：计划接入，需确认 username 映射
  • CRM/渠道系统：已改飞书登录，撤销独立管理员账号
  • 内网系统：飞书登录外仍需飞连网络权限（见 X-SEC-25）

10. 待确认问题

  • SSO 接入主责是否定为 IT 运维？飞书应用权限审批是否由飞书管理员统一做？
  • 是否沉淀公共 SSO 组件，由谁维护？
  • Gitea、网盘接飞书登录的时间表？
  • 应急账号统一存放在哪个密码工具，谁有权取用？
X-SEC-06外部协作方访问内网、联调环境与数据授权待新建150

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨5 × 险5

  • 适用场景：外包、外部开发团队、外部厂商、子公司外部人员、算法协作者需要测试机、联调环境、VPN、系统账号或产品数据；或公司需接入外部厂商硬件（远程 VPN/堡垒机）
  • 负责人：主责——IT 运维（当前：杨明学·推断待确认）；协同——项目对接人（当前：杨萌·推断待确认）、研发运维（当前：宋祺睿、杨云峰·推断待确认）、VPN 负责人（当前：吴世豪·推断待确认）、数据接口研发（当前：马漳毓·推断待确认）、测试负责人（当前：张东郅·推断待确认）、交付部署工程师（当前：游家豪·推断待确认）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 对接人提交外部接入申请 → ② 法务核验保密协议 → ③ IT 运维出隔离接入方案 → ④ CTO 审批 → ⑤ 开独立、最小、限期账号 → ⑥ 限时安全分享凭据 → ⑦ 台账登记 → ⑧ 到期回收与改密
  • 交付结果：外部人员在隔离环境内以独立账号访问约定资源；外部接入台账（主体、人员、资源、数据范围、保密协议、期限、对接人）；到期回收记录
  • 状态依据：只有“外部人员不进内网”的口头原则，每次接入临时讨论；厂商账号与服务器信息在群内明文转发，联调 IP 反复下发，外部要账号时不清楚谁是测试服务器管理员；外部数据授权前核对保密协议靠个人记忆

1. 场景判定

  • 触发条件：外包或外部团队要联调公司服务；外部方要测试机/开发机；外部要产品数据做分析；接入外部厂商算力或客户机房设备
  • 典型说法：「有两个外包需要飞连来开发，有没有好办法」「不建议让他们用飞连，用了飞连就进内网了」「我们这边的账号和密码可以给我创建一个吗」「办公室网络又修改了」
  • 判断问题：使用者是否不是公司在职员工？或资源是否来自外部厂商？
  • 不归本流程管：客户、渠道要设备 root/远程接入 → 请走 X-SEC-07；内部员工远程办公 → 请走 X-SEC-25；内部人员敏感数据导出 → 请走 X-SEC-35；厂商借测试机 → 请走 ADM-30；保密协议签署 → 请走 LEG-05（保密协议与外部合作协议拟定）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 评估接入方式、出隔离方案、维护台账、到期回收 R IT 运维（当前：杨明学·推断待确认）
项目对接人 提交申请、对外沟通、到期确认 R 项目对接人（当前：杨萌·推断待确认）
CTO 外部接入与数据授权审批 A CTO（当前：丁震宇·推断待确认）
法务 核验保密协议与数据使用条款 C 法务（当前：待指定）
研发运维/VPN 负责人 下发 WG/VPN 配置、开测试服务器账号 R 研发运维（当前：宋祺睿、杨云峰·推断待确认）；VPN 负责人（当前：吴世豪·推断待确认）；测试负责人（当前：张东郅·推断待确认）
数据接口研发 开发只读接口、按人发放独立密钥 R 数据接口研发（当前：马漳毓·推断待确认）
交付部署工程师 外部厂商硬件的远程接入调试 R 交付部署工程师（当前：游家豪·推断待确认）

3. 办之前请准备

  • 外部主体名称、人员名单、联系方式（填在申请单，不发群）
  • 用途、需要的资源（仓库/测试机/服务器/接口/数据集）、数据范围、开始与结束日期
  • 已签保密协议编号或扫描件；无保密协议先走法务
  • 外部厂商接入：厂商提供的 VPN/堡垒机文档与对方运维联系人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“外部人员接入申请”（主体、人员、资源、数据范围、期限、对接人） 项目对接人 需要前 3 个工作日 飞书审批 申请单 🔧飞书固化
2 核验保密协议有效、覆盖本次数据范围 法务 1 个工作日内 合同台账 核验结论 🔧飞书固化
3 出接入方案：禁止飞连进内网；用 WG 隔离网段、独立开发机、单仓库或独立组织 IT 运维 1 个工作日内 方案模板 接入方案 👤人工判断
4 审批（涉及产品数据、生产环境必须 CTO 审） CTO 1 个工作日内 飞书审批 审批结果 👤人工判断
5 开通：每人独立账号、只读优先、设到期日；数据接口按人发独立密钥并留调用日志 研发运维/数据接口研发 审批后 1 个工作日内 各系统 账号/密钥 🔧+🤖
6 凭据通过密码工具或飞书保密文档限时分享，禁止在群聊转发 研发运维/数据接口研发 与第 5 步同时 密码工具 分享记录 🔧飞书固化
7 实体测试机走“实体资产领用”审批出库寄送 IT 运维 审批后 2 个工作日内 飞书审批 出库记录 🔧飞书固化
8 登记台账；网络变更需重新下发配置时统一通知所有外部方 IT 运维 开通当天 多维表格 外部接入台账 🔧飞书固化
9 到期前 3 个工作日提醒；结束当天停用账号、撤 WG 配置、回收设备、改密 IT 运维 到期当天 多维表格自动化 回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：外部接入申请单、接入方案、外部接入台账、回收记录
  • 建议模板/表单：外部接入台账字段——外部主体、人员、对接人、资源清单、数据范围、接入方式（WG/开发机/单仓库/只读接口）、保密协议编号、开始日、到期日、凭据分享方式、回收日期、回收确认人

6. 异常与升级

  • 无保密协议却要产品数据 → 暂停开通 → 升级法务与 CTO（1 个工作日内）
  • 厂商多次更换 VPN 地址、文档与实际不符 → 由对接人要求厂商书面确认最终地址 → 2 次失败升级 CTO
  • 不清楚测试服务器管理员 → 查台账；台账无记录由 IT 运维当天指定
  • 凭据被发到群聊 → 立即改密并按 X-SEC-11 处理 → 通知 CTO（当天）
  • 外部人员到期仍在使用 → 当天停用，对接人补续期申请

7. 衡量指标

  • 外部接入开通周期 = 申请到可访问的工作日数，目标 ≤ 3 天
  • 保密协议前置率 = 开通前已核验保密协议的比例，目标 100%
  • 到期回收率，目标 100%
  • 外部人员内网直连（飞连进内网）数，目标 0
  • 群聊明文凭据次数，目标 0

8. 低效诊断

  • 外部厂商多次更换 VPN 地址、文档链接与实际不一致，反复询问对方运维｜依据：「忠橙星行星引擎」2026-02
  • 厂商服务器账号信息在群内转发｜依据：「忠橙星行星引擎」2026-02
  • 外包要求用飞连进内网开发，临时评估后才改为按需提供服务｜依据：「忠橙星行星引擎」2026-08
  • 办公网络变更后需反复给外部方重新下发 IP 配置｜依据：「手机端-录音卡」2026-09
  • 外部要测试服务器账号时，没人确认自己是管理员｜依据：「手机端-录音卡」2026-09

9. 分支变体

  • 外包开发：WG 隔离或独立开发机 + 单仓库；禁止飞连
  • 外部厂商硬件（如 GPU 厂商算力）：厂商 VPN/堡垒机，账号进密码工具，指定调试人
  • 外部只读数据：保密协议前置，测试服/生产服分别发密钥，按人独立并留日志
  • 子公司或借调外部人员：独立 Gitea 组织（见 X-SEC-02）
  • 实体设备：走实体资产领用出库

10. 待确认问题

  • 外部接入主责是否定为 IT 运维？审批是否一律由 CTO 做？
  • 保密协议台账由法务还是总经办维护？是否能与审批联动查询？
  • 外部人员默认最长授权期限（建议 3 个月）？
  • 外部人员用的密码分享工具选哪一个？
X-SEC-07客户/渠道索要设备 root/管理员账号与远程接入的审批与回收待新建225

状态：待新建｜证据：有证据（卡片 4 张 / 会话 7 个）｜优先级：频3 × 耗3 × 跨5 × 险5

  • 适用场景：客户、渠道、实施人员要求设备 root 密码、服务器账密、管理员账号找回、内网穿透、公网映射或远程使用部署在公司的设备时，按统一口径答复，例外走审批，交付后回收
  • 负责人：主责——研发负责人（当前：王皓南·推断待确认）；协同——对客人员（当前：杨萌、时建、杨朋伟、吴琪·推断待确认）、交付部署工程师（当前：游家豪、杨云峰·推断待确认）、IT 运维（当前：杨明学·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、CTO（当前：丁震宇·推断待确认）审批、CEO（当前：邴龙志·推断待确认）特例审批；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 对客人员收到诉求不当场答复 → ② 按类型对照口径 → ③ 标准件按话术回复 → ④ 例外提交“客户上机/高权限”审批 → ⑤ 审批通过后限时开通 → ⑥ 登记台账 → ⑦ 到期回收改密 → ⑧ 误发应急处置
  • 交付结果：客户收到统一口径答复或受控、限期的权限；客户高权限授权台账；误发后的改密与加固记录
  • 状态依据：8 月发生对客人员把客户设备 root 密码交给客户的险情，9 月又出现账密私发客户；规则“禁止未经批准外发机器账密”只在群里口头宣布，“生产环境访问”审批尚未加“客户上机”类型

1. 场景判定

  • 触发条件：客户/渠道要 root、服务器账密、owner 账号；客户忘记管理员密码；要求内网穿透、公网映射、飞连/WG 远程使用；渠道实施需要配网络
  • 典型说法：「用户想获取 root 密码」「再急，查账号密码也得按规则来」「禁止给服务器账号密码」「规则就是不支持，走 VPN」
  • 判断问题：对方要的是否超出“软件管理员账号”的范围（系统级权限、机器账密、网络打通）？
  • 不归本流程管：客户软件内账号开通与额度 → 请走 X-DLV-15；客户网络与远程接入的技术配置 → 请走 X-DLV-16；外包/外部开发团队 → 请走 X-SEC-06；内部生产访问 → 请走 X-SEC-18；定制远程方案报价 → 请走 SAL-21（定制/非标需求评估、报价与特批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
研发负责人 维护口径与话术、维护审批流与台账 R 研发负责人（当前：王皓南·推断待确认）
对客人员 收集诉求、不当场答复、按话术回复、提交审批 R 对客人员（当前：杨萌、时建、杨朋伟、吴琪·推断待确认）
CTO 审批客户上机、管理员密码找回、例外放行 A CTO（当前：丁震宇·推断待确认）
CEO root 外给等特例最终审批 A（升级） CEO（当前：邴龙志·推断待确认）
交付部署工程师 执行限时授权、改密、加固 R 交付部署工程师（当前：游家豪、杨云峰·推断待确认）
IT 运维 远程接入方式与 WG 安全评估、硬件层加固 C IT 运维（当前：杨明学·推断待确认）
研发运维 访问控制规则、授权结束回收检查 C 研发运维（当前：宋祺睿·推断待确认）

3. 办之前请准备

  • 客户名称（内部用代号）、设备实例编号、设备归属（客户自有/我方托管）
  • 对方原话与诉求类型、业务理由、期望期限
  • 当前交付状态（是否已验收、是否在试用期）
  • 统一话术卡（帮助中心或群公告）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到诉求不当场答复，记录原话，在项目内部群报备 对客人员 收到后 1 小时内 飞书群 诉求记录 👤人工判断
2 按类型对照口径：root/服务器账密＝默认拒绝；软件管理员账号＝可给；内网穿透/公网映射＝不支持，走 VPN；渠道配网络＝受限 sudo 普通账号 对客人员（研发负责人答疑） 报备后 2 小时内 口径卡 类型判定 🔧+🤖
3 标准件按话术回复（“交付的是产品不是服务器”，类比手机不开放 root） 对客人员 判定后当天 话术模板 回复记录 🔧飞书固化
4 例外或管理员密码找回：提交“生产环境访问—客户上机/账号找回”审批（客户、实例、用途、期限） 对客人员 判定后当天 飞书审批 申请单 🔧飞书固化
5 审批：客户上机、密码找回由 CTO 批；root 外给须 CEO 批 CTO/CEO 1 个工作日内（客户现场紧急 4 小时内） 飞书审批 审批结果 👤人工判断
6 执行：开限时账号或现场代操作；账密存团队密码库，不私发；交付后立即改密 交付部署工程师 审批后按约定时间 密码库/WG 授权记录 🔧飞书固化
7 登记台账，到期自动提醒回收 交付部署工程师 开通当天 多维表格 高权限台账 🤖自动化
8 到期回收：停用账号、撤 WG、改密，并回填 交付部署工程师 到期当天 设备/WG 回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：统一口径与话术卡、客户上机审批单、客户高权限台账、改密/加固记录
  • 建议模板/表单：
    • 审批字段：客户代号、实例编号、设备归属、诉求类型、业务理由、权限内容、期限、执行人、审批人
    • 台账字段：客户代号、实例、授权类型、授权对象、开始/到期时间、凭据存放位置、回收时间、回收人
    • 设备加固基线：关闭 root SSH、清空 root 密码、锁 GRUB、隐藏登录页、无弱口令

6. 异常与升级

  • 升级条件：客户上机、管理员密码找回由 CTO 审批即可执行；root 或机器账密外给、托管设备开放系统权限等特例 → CTO 初审后升级 CEO 最终审批（1 个工作日内，客户现场紧急 4 小时内）
  • 发现 root 或机器账密已外发 → 交付部署工程师当天通过 WG 改密并加固 → 升级 CTO（1 小时内），记入台账
  • 渠道坚持要 root 并质疑 → 对客人员复述口径，不让步 → 升级 CTO 与销售负责人（1 个工作日内），不接受的不签
  • 客户现场紧急要查管理员密码 → 回复“正在查，需要走审批”，同步提交审批 → CTO 4 小时内批
  • 客户要求公网映射或定制远程方案 → 不支持；确需定制转商务报价
  • 飞连席位费用由谁承担有争议 → 按报价单约定；试用期默认用 WG → 升级销售负责人

7. 衡量指标

  • 未经审批外发 root/机器账密次数，目标 0
  • 客户高权限授权到期回收率，目标 100%
  • 管理员密码找回审批周期，目标 ≤ 1 个工作日（紧急 ≤ 4 小时）
  • 交付设备加固基线达标率（抽查），目标 100%

8. 低效诊断

  • 对客人员不知道 root 不能外给，已把 root 账密交给客户后才发现，双方对“是否告知过”有争执｜依据：「客户A 交付群」2026-08、「鼎慧产研决策部」2026-08
  • “禁止未经批准外发机器账密”只在群里口头宣布，客户上机审批类型未落地｜依据：「鼎慧产研决策部」2026-08
  • 交付人员仍把 owner 账号密码私下发给客户，事后才被追问｜依据：「鼎慧产研决策部」2026-09
  • 渠道客户要 root 并质疑规则，口径靠群里临时讨论｜依据：「客户D 交付群」2026-09
  • 客户现场紧急要查管理员账密，对客人员情绪急，靠群里临时定规则｜依据：「某地方政府客户群」2026-09、「客户E 交付群」2026-10
  • 飞连席位费用谁出、远程接入怎么连每次重新问｜依据：「客户A 交付群」2026-07、「客户B 交付群」2026-07
  • 客户要求公网映射，每次重申“走 VPN”｜依据：「客户C 交付群」2026-09

9. 分支变体

  • 系统 root 与软件管理后台账号：前者默认拒绝，后者可给
  • 客户自有硬件与我方托管设备：自有硬件归客户但软件授权仍受保护；托管设备一律不给系统权限
  • 渠道网络配置：提供只能配网络的普通 sudo 账号；OOBE 上线后取消
  • 远程接入：飞连需加入公司飞书且席位收费；试用期优先 WG；公网映射不支持
  • 客户忘记管理员密码：走账号找回审批

10. 待确认问题

  • 主责是否定为研发负责人？审批由 CTO 做、root 特例由 CEO 做是否确认？
  • “生产环境访问”审批何时增加“客户上机/账号找回”类型？
  • 统一话术是否放进帮助中心并对销售、交付做一次培训？
  • 团队密码库选型及谁有权查看客户设备凭据？
  • 渠道普通 sudo 账号的权限范围由谁定？
X-SEC-08离职/试用终止/调岗账号回收与权限收口待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨4 × 险5

  • 适用场景：人员离职、试用/实习终止、违规处理、调岗时，按账号台账一次性回收或调整 Gitea、工单、业务系统、邮箱、飞书群、企业微信、VPN/飞连、服务器公钥等权限，并清理敏感群成员
  • 负责人：主责——IT 运维（当前：待指定）；协同——人事（当前：待指定）、Gitea 管理员（当前：宋祺睿·推断待确认）、各系统管理员、直属上级/技术负责人（当前：王子明·推断待确认）、敏感群群主；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 人事异动单触发回收清单 → ② 试用终止/违规先封号 → ③ 各系统停用或降级 → ④ 共享凭据改密 → ⑤ 移出群组与敏感群 → ⑥ 调岗按新模板授权 → ⑦ 回填台账并归档 → ⑧ 月度残留盘点
  • 交付结果：已关闭的回收清单（每个系统的停用时间与执行人）；更新后的账号台账；敏感群成员审计记录
  • 状态依据：没有回收清单，离职运营仍留在企业微信；试用人员不合格后才想到封号；新会计被拉入旧财务群暴露敏感信息，当时连能踢人的管理员都找不到

1. 场景判定

  • 触发条件：离职审批通过；试用/实习不通过；违规或简历造假被处理；调岗/转部门生效；借调结束
  • 典型说法：「这个测试解约的时候记得先把 git 之类的号封了」「离职的运营还在企业微信呢」「是否还是做一下数据隔离吧」「怎么把会计拉进旧财务群了」
  • 判断问题：此人在公司的身份或岗位是否即将或已经改变？
  • 不归本流程管：离职手续与交接本身 → 请走 HR-27；设备回收 → 请走 ADM-32；调岗手续 → 请走 HR-25；外部人员到期回收 → 请走 X-SEC-06；凭据外泄 → 请走 X-SEC-11；锁屏与终端规范 → 请走 X-SEC-31

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 生成回收清单、派单、收口、月度盘点 R/A IT 运维（当前：待指定）
人事 发起异动单，写明生效时间与是否需先封号 R 人事（当前：待指定）
Gitea 管理员 封禁账号、转移名下仓库 R Gitea 管理员（当前：宋祺睿·推断待确认）
各系统管理员 停用或降级本系统账号 R 各系统管理员
直属上级/技术负责人 确认交接范围、提出先封号、确认共享凭据清单 C 直属上级/技术负责人（当前：王子明·推断待确认）
敏感群群主 移出成员、审计财务/董事会等群 R 敏感群群主（当前：待指定）
CTO 违规情形立即封号决策、兜底 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 异动类型（离职/试用终止/违规/调岗/借调结束）、生效时间、是否需要“先封号再谈话”
  • 此人账号台账（来自 X-SEC-01 / X-SEC-02 / X-SEC-03 的登记）
  • 此人知晓的共享账号、服务器密码、密钥清单（直属上级确认）
  • 名下仓库、文档、公共邮箱、群主身份的接收人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 异动单生效，按台账自动生成回收清单并派单 人事 → IT 运维（机器人） 异动审批通过当天 飞书审批 + 多维表格 回收清单 🔧+🤖
2 试用终止/违规：先封 Gitea、飞书、VPN 等核心账号，再办手续 Gitea 管理员、IT 运维 谈话前或谈话开始时（违规立即） 各系统 封禁记录 👤人工判断
3 正常离职：各系统停用或转为不可登录 各系统管理员 最后工作日 18:00 前 各系统 停用记录 🔧飞书固化
4 名下仓库、文档、公共邮箱、群主身份转移给接收人 直属上级 最后工作日前 Gitea/飞书 转移记录 👤人工判断
5 此人知晓的共享账号、服务器密码、密钥改密或轮换 各系统管理员 停用后 1 个工作日内 密码库 改密记录 🔧飞书固化
6 移出飞书群、企业微信、外部协作群；敏感群（财务、董事会等）复核成员 群主、IT 运维 最后工作日 18:00 前 飞书/企业微信 群成员变更 🔧飞书固化
7 调岗：按新岗位模板授权，移除原岗位多余权限和原部门敏感群 IT 运维、各系统管理员 调岗生效后 1 个工作日内 各系统 调整记录 🔧+🤖
8 回收清单全部关闭，回填台账，人事归档 IT 运维 生效后 2 个工作日内 多维表格 归档清单 🔧飞书固化
9 月度盘点：对照花名册扫描各系统残留账号与敏感群成员 IT 运维 每月 5 日前 脚本 + 多维表格 盘点报告 🤖自动化

5. 交付物与模板

  • 交付物：回收清单、封禁/停用/改密记录、群成员审计记录、月度盘点报告
  • 建议模板/表单：
    • 回收清单字段：姓名、异动类型、生效时间、是否先封号、系统名、账号、处理方式（停用/降级/转移）、执行人、完成时间、共享凭据改密项、接收人
    • 敏感群名册：群名、群主、允许成员范围（按部门/岗位）、最近审计日期

6. 异常与升级

  • 升级条件：违规情形需立即封号、敏感群越权暴露、残留账号连续两月出现 → IT 运维升级 CTO 决策；正常离职与调岗回收由 IT 运维直接收口
  • 违规人员账号 1 小时内未封 → 人事直接通知 CTO 执行
  • 新成员被拉入不属于本部门的敏感群 → 群主当天移出，评估暴露内容 → 升级部门负责人与 CTO（当天）
  • 群主或管理员缺位、无人能移人 → IT 运维用飞书管理员权限处理并补指定群主 → 当天
  • 盘点发现离职残留账号 → 当天停用 → 连续两月出现则升级 CTO
  • 离职人员掌握的共享密码无法改（第三方平台）→ 登记并在 X-SEC-12 台账跟踪 → 1 周内完成

7. 衡量指标

  • 回收及时率 = 最后工作日 18:00 前完成全部回收的人数 / 离职人数，目标 100%
  • 违规/试用终止先封号执行率，目标 100%
  • 月度盘点发现的离职残留账号数，目标 0
  • 敏感群越权成员数（审计发现），目标 0

8. 低效诊断

  • 离职运营仍留在企业微信，无人负责清理｜依据：「鼎慧产研决策部」2026-02
  • 测试人员不合格后才想到要封代码仓库账号，实习生直接拉入团队权限过大｜依据：「跃竞招聘群」2026-02
  • 尚未正式入职就差点发项目代码，入职与权限节点没对齐｜依据：「跃竞招聘群」2026-02
  • 新会计被拉入旧财务群暴露敏感信息，且找不到有管理员权限的人移人｜依据：「董事会」2026-03

9. 分支变体

  • 离职：最后工作日 18:00 前全部停用
  • 试用/实习终止、违规：先封号再办手续
  • 调岗：按新模板授权，移出原部门敏感群
  • 跃竞团队：试用人员不进 git 团队，只单仓库授权；外部劳务在微信群协作、不进飞书，结束时清群
  • 借调结束：恢复原组织权限，移除借调项目仓库

10. 待确认问题

  • 回收主责是否定为 IT 运维，具体由谁担任？
  • 人事离职审批能否自动带出账号台账生成回收清单？
  • 敏感群（财务、董事会、人事）由谁做群主，允许成员范围如何定？
  • 正常离职“最后工作日 18:00 前停用”是否可行？邮箱是否需要保留转发一段时间？
  • 是否已有成文的离职 IT 交接制度？
X-SEC-09测试/内部环境地址与管理员账号登记交接待新建240

状态：待新建｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：测试服、公司内部生产服、交付预演环境（50、102、103、108、109 等）新部署、重装、重置或改密后，部署人把访问地址和管理员账号登记到统一环境台账，再按需授权给测试、产品、销售演示使用；账号丢失或被锁时也按本流程重置。
  • 负责人：主责——环境运维/部署负责人（当前：宋祺睿·推断待确认）；协同——部署工程师（当前：杨云峰、陈子康·推断待确认）、IT运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认）、产品（当前：杨萌、杨黔昆·推断待确认）；兜底——研发负责人/CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 部署/重置完成 → ② 凭据写入密码库环境条目 → ③ 更新环境台账 → ④ 群内发变更公告（只给台账链接） → ⑤ 使用人查台账或提交访问申请 → ⑥ 改密/重置先公告后执行 → ⑦ 每月核对与回收
  • 交付结果：一张实时有效的“环境台账”（环境、地址、用途、版本、负责人、状态、对应密码库条目），以及按人授权的密码库访问记录；群聊中不再出现明文账号密码。
  • 状态依据：没有统一台账和凭据管理。2026-06～09「Leap产研测」群里反复出现“某服信息谁发我一下”“谁把管理员密码改了”，累计约 30 次；环境信息散落在群 pin、文档和私发三处；管理员凭据多次明文贴群，环境重置后还得重新索要。

1. 场景判定

  • 触发条件：新环境部署完成；环境重装、重置或升级导致地址或账号变化；有人改了共用管理员密码；新人或测试、产品、销售需要某个环境的地址和账号；账号被锁或忘记密码。
  • 典型说法：「X 服的信息谁发我一下」「能不能给我统一信息到一个地方，不同服不同账号还老换密码」「谁把 103 管理员密码改了」「pubkey 发我」「整体发我一下信息，包括安装包、企业链接地址、管理后台链接」
  • 判断问题：我要的是公司内部测试或演示环境的地址/管理员账号吗？是的话先查环境台账，台账里没有或已失效再走本流程。
  • 不归本流程管：
    • 开发服务器 SSH、GPU、虚拟机资源申请 → 请走 X-SEC-17
    • 生产环境（含客户生产、生产 wg）访问申请 → 请走 X-SEC-18
    • 客户/渠道索要设备 root/管理员账号 → 请走 X-SEC-07
    • 内部业务系统、管理后台的个人账号开通 → 请走 X-SEC-03
    • 凭据分发的通用规则 → 请走 X-SEC-10；凭据已外泄 → 请走 X-SEC-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
环境运维负责人 维护环境台账和密码库环境分组，审批管理员权限，组织月度核对 A 环境运维/部署负责人（当前：宋祺睿·推断待确认）
部署工程师 部署或重置后写入密码库、更新台账、发变更公告、处理重置申请 R 部署工程师（当前：杨云峰、陈子康·推断待确认）
IT运维 提供密码管理工具，开通人员访问分组，人员离岗时回收 R IT运维（当前：杨明学·推断待确认）
测试负责人 确认测试环境使用人名单，环境重置前协调测试窗口 C 测试负责人（当前：张东郅·推断待确认）
产品 把安装包、企业链接、管理后台入口补进台账 C 产品（当前：杨萌、杨黔昆·推断待确认）
使用人 先查台账再申请，不外传，不擅自改共用密码 I 测试/产品/销售/研发（当前：待指定）
兜底 裁决争议，决定跨环境和生产相关权限 A（升级） 研发负责人/CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 部署人：环境编号和名称、IP 或域名、用途（测试/公司内部生产/交付预演/演示）、产品与版本、owner 账号与组织 ID、服务内部凭据清单、计划重置或下线时间。
  • 申请人：要访问的环境、用途、权限级别（普通用户/管理员）、使用期限；要 SSH 的附本人公钥。
  • 密码库里已有该环境的条目分组；没有就先找 IT 运维建好。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 部署或重置完成后，把 owner 账号、组织 ID、服务内部凭据写入密码库“环境/环境名”条目；初始密码随机生成 部署工程师 部署完成当天 密码管理工具、部署 skill 密码库条目 🔧+🤖
2 更新环境台账：地址、用途、版本、负责人、状态、密码库条目名、最近变更时间 部署工程师 与步骤 1 同一天 飞书多维表格“环境台账” 台账记录 🔧+🤖
3 在产研群发变更公告：环境名、变化内容、台账链接，不含任何账号密码 部署工程师 台账更新后 1 小时内 飞书群机器人 变更公告 🤖自动化
4 使用人先查台账；需要凭据的提交“环境访问申请”（环境、权限级别、期限） 使用人 需要时 多维表格表单 访问申请记录 🔧飞书固化
5 审核授权：测试环境普通权限直接加入密码库分组；管理员权限由环境负责人确认；SSH 场景把公钥登记到 iac 仓库 环境运维负责人 申请后 4 个工作小时内 密码管理工具、iac 仓库 授权记录 👤人工判断
6 要改共用管理员密码或重置环境时，先在群里公告时间、影响和负责人，再执行；完成后回到步骤 1 执行人 至少提前 2 小时公告（故障抢修除外） 飞书群 改密/重置公告 👤人工判断
7 忘记密码或账号被锁：先查密码库；仍不行就提交“重置申请”，部署工程师重置后只更新密码库，再通知申请人去取 部署工程师 申请后 4 个工作小时内 密码管理工具 重置记录 🔧飞书固化
8 月度核对：台账与实际环境逐一比对，已下线环境归档，过期授权回收 环境运维负责人 每月 5 日前 多维表格、密码管理工具 月度核对记录 🔧+🤖

5. 交付物与模板

  • 交付物：环境台账、密码库环境分组与授权记录、变更/重置公告、月度核对记录。
  • 建议模板/表单：
    • 环境台账：环境编号、名称、地址/域名、环境类型（测试/公司内部生产/交付预演/客户专用）、产品与版本、安装包/企业链接/管理后台入口、负责人、状态（可用/重置中/下线）、密码库条目名、最近变更时间与变更人、计划重置时间。
    • 环境访问申请：申请人、环境、用途、权限级别、使用期限、公钥（SSH 时）、审批人、授权时间、回收时间。
    • 变更公告：【环境变更】环境名｜变更内容｜影响时段｜负责人｜台账链接。

6. 异常与升级

  • 升级条件：查不出无通知改密的修改人、同一环境一个月内重置中断测试 2 次及以上、公司内部生产环境被误发测试配置、跨环境或生产相关权限申请 → 环境运维负责人当天升级兜底（研发负责人/CTO）裁决；测试环境的日常授权与重置由环境运维负责人直接决定
  • 共用管理员密码被人无通知修改 → 发现人在群里报告，环境负责人 2 小时内查操作日志并恢复，结果记入台账 → 查不出修改人的，当天升级 CTO
  • 凭据已被明文发到群里 → 发送人立即撤回，部署工程师当天轮换 → 按 X-SEC-11 处置
  • 环境重置导致测试中断 → 测试负责人登记影响，环境负责人补发公告 → 一个月内发生 2 次及以上，升级 CTO
  • 台账信息与实际不符（地址失效、版本错） → 使用人在台账评论里报错，部署工程师 1 个工作日内修正 → 超期升级环境运维负责人
  • 有人在 102 等公司内部生产环境上发了测试配置 → 立即停止并回滚，环境负责人评估影响 → 当天升级 CTO

7. 衡量指标

  • 台账准确率 = 月度核对时信息正确的环境数 / 在用环境数，目标 ≥ 95%
  • 群内明文凭据次数 = 每月产研群出现账号密码明文的次数（机器人检测加抽查），目标 0
  • 环境信息索要次数 = 每月群里询问环境地址或账号的消息数，目标比上线前下降 80%
  • 访问申请处理时长 = 从申请到授权的工作小时数，目标 ≤ 4 小时
  • 无通知改密次数 = 每月未提前公告就修改共用密码的次数，目标 0

8. 低效诊断

  • 现象：环境地址和账号散在群 pin、文档、私发三处，同一环境被反复问“信息谁发我一下”，测试和产品每次都得 @ 部署人（找信息环节）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08
  • 现象：环境重装或重置后账号变了却没有公告，测试中途登不进去才发现，只能重新要（变更通知环节）｜依据：「Leap产研测」2026-06
  • 现象：管理员账号和服务内部凭据被整张表明文贴进群里，还被多次转发，群成员变动后无法回收（分发环节）｜依据：「Leap产研测」2026-08、「跃迁基座项目交付沟通」2026-03、「跃迁基座项目交付沟通」2026-04
  • 现象：默认初始密码口径不一（批量导入和手动创建不同），使用人只能逐个问（初始化环节）｜依据：「Leap产研测」2026-06
  • 现象：没有权限就临时借共用账号，谁有生产 wg 权限只能在群里问（授权环节）｜依据：「Leap产研测」2026-09
  • 现象：账号多次输错被锁、密码被不明人重置，靠人工逐个重发（重置环节）｜依据：「Leap产研测」2026-06、「Leap产研测」2026-08

9. 分支变体

  • LeapCore：50 是测试环境，102 是公司内部生产（全公司使用，禁止发测试配置），103 等是专项测试；客户专用预演环境单独分组，只授权给该项目成员。
  • LeapAll：测试服、正式服分成两个台账分组，凭据分开。
  • 交付前客户机器（涉密客户机器、高校客户测试机、演示现场机器）：每人单独开号，不给 sudo，按需只给 docker 权限；默认账号用完封存；客户方学生账号由客户自行开通，我方不代持。
  • 客户端激活码、共用测试账号：同样放进密码库按人授权，不在公司通知群里明文发布。

10. 待确认问题

  • 环境台账的主责是不是环境运维负责人？台账用飞书多维表格，还是沿用现有的链接汇总页？
  • 公司统一密码管理工具选哪个（团队版商业产品或自建）？由哪个岗位采购和维护？
  • 访问申请 4 个工作小时内响应是否可行？测试环境的普通权限能否改成申请即自动授权？
  • 部署 skill 能否在完成后自动写台账和密码库？需要研发评估工作量。
  • 初始密码统一随机生成、首次登录强制改密，是否认可？
  • 102 等公司内部生产环境的管理员名单由谁审批？
X-SEC-10密钥与凭据分发保管规范（禁止群内明文）待新建250

状态：待新建｜证据：有证据（卡片 20 张 / 会话 8 个）｜优先级：频5 × 耗2 × 跨5 × 险5

  • 适用场景：凡是要在人与人之间共享账号密码、API Key、AK/SK、数据库口令、kubeconfig、镜像仓库账号、SMTP/地图/公众号等第三方密钥、生产环境变量或客户系统账号时，一律走密码库或私密通道分发并登记，禁止在群聊、私聊、截图、文档、代码里出现明文。
  • 负责人：主责——信息安全负责人（当前：待指定）；协同——IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、云与模型 Key 持有人（当前：待指定）、客户项目账号主负责人（当前：邓乾·推断待确认）、行政（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 判定凭据密级 → ② 持有人在密码库建条目 → ③ 按人/按组授权或发一次性链接 → ④ 登记凭据台账（用途、持有人、一主二备、到期日） → ⑤ 使用人从密码库取用或注入环境变量 → ⑥ 到期轮换、人员变动回收 → ⑦ 群聊明文监测与月度审计
  • 交付结果：公司统一密码库（按部门/项目/环境分组）、凭据台账、按人授权记录和轮换记录；群聊明文凭据清零。
  • 状态依据：全年在产研、交付、客户项目等 8 个群持续出现管理员密码、Token、AK/SK、数据库连接、支付参数明文，约 120 余次；只有事后口头提醒和口头罚则；密码管理靠个人合租的家庭版和一个曾明文输出的 WiFi 机器人，公司级密码库停留在“调研一下”；没有成文规范。

1. 场景判定

  • 触发条件：需要把任何能登录系统、调用付费接口或访问数据的凭据交给另一个人、另一台机器或一个 AI 代理；凭据更新后需要通知使用人；新人或新项目需要共享凭据。
  • 典型说法：「有没有管理员账号给我用算了」「求求线上 dev 的 REDIS_URL」「发我生产 key」「我们密码有啥管理方案没，包括共享的密钥」「公司用的不要给别人发 admin 密码」「你直接放机器里告我位置我去拿就行」
  • 判断问题：这段内容别人拿到后能不能直接登录、调用或花钱？能，就是凭据，必须走本规范。
  • 不归本流程管：
    • 凭据已泄露或疑似泄露 → 请走 X-SEC-11
    • 测试/内部环境地址与管理员账号登记 → 请走 X-SEC-09
    • 第三方平台账号台账与验证码收口 → 请走 X-SEC-12
    • 模型 API Key、NewAPI 额度申请 → 请走 RND-27
    • 云子账号、控制台权限、AK 申请 → 请走 X-SEC-15
    • 办公 WiFi 密码查询 → 请走 X-SEC-24；离职回收 → 请走 X-SEC-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
信息安全负责人 制定密级与分发规则，审批 L3/L4 授权，每月审计，通报违规 A 信息安全负责人（当前：待指定）
IT运维 部署和维护密码库，建分组，配置明文检测机器人，人员变动回收 R IT运维（当前：杨明学·推断待确认）
凭据持有人 建条目、授权、登记台账、按期轮换 R 环境运维（当前：宋祺睿·推断待确认）；云与模型 Key 持有人（当前：待指定，现由 CTO 代持，建议移交专人，避免持有人与兜底审批为同一人）
客户项目账号主负责人 客户系统账号“一主二备”中的主负责人，管理该项目分组 R 项目研发/FDE（当前：邓乾·推断待确认）
行政 维护办公 WiFi 等公共低敏凭据的发放方式 C 行政（当前：待指定）
使用人 只从密码库取用，不转发、不截图、不写进代码和文档 I 全员
兜底 选型拍板、罚则口径、争议裁决 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 凭据类型、所属系统/环境（dev/test/prod/客户）、用途、使用人名单、有效期。
  • 密级判定（见下表），L3/L4 要备好审批理由。
  • 接收方的密码库账号；接收方是程序或 AI 代理的，准备好环境变量名或 CI secrets 名。
  • 密级参考：L1 公共低敏（办公 WiFi）｜L2 测试环境账号、测试 Key｜L3 生产管理员、云 AK/SK、数据库口令、kubeconfig、支付参数、客户系统账号｜L4 云主账号、root、超级管理员。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 判定密级；L1 走机器人私聊打码返回或访客网络，L2～L4 进入下一步 凭据持有人 收到需求时 本规范密级表 密级 👤人工判断
2 在密码库对应分组新建条目（名称含系统、环境、用途；API Key 按前缀规范命名，如实例用 sk-inst、网关用 sk-gw） 凭据持有人 需求当天 密码管理工具 密码库条目 🔧飞书固化
3 L2：直接授权给使用人或项目分组；L3：提交授权申请，安全负责人审批后授权；L4：安全负责人审核、报 CTO 同意后，只授予主责和一名备份 凭据持有人、安全负责人 L2 当天；L3 1 个工作日内；L4 2 个工作日内 密码管理工具、飞书审批 授权记录 🔧+👤
4 登记凭据台账：系统、环境、密级、持有人、一主二备、使用人、到期/轮换日 凭据持有人 授权当天 飞书多维表格“凭据台账” 台账记录 🔧飞书固化
5 程序和 AI 代理只通过环境变量、CI secrets 注入，使用独立最小权限 Token；生产密钥由环境运维直接注入，不经人转手 环境运维 发布前 CI secrets、配置仓库 注入记录 🤖自动化
6 凭据更新（如 90 天重置）后只更新密码库条目，机器人通知授权使用人“已更新”，不发新值 凭据持有人 更新当天 密码库、飞书机器人 更新通知 🤖自动化
7 群聊明文检测：机器人识别疑似密钥、密码后提醒撤回并通知安全负责人 IT运维 实时 飞书机器人 告警记录 🤖自动化
8 月度审计：核对台账与密码库授权，清理离岗、到期授权，统计违规次数并通报 信息安全负责人 每月 5 日前 多维表格、密码库日志 月度审计报告 🔧+🤖

5. 交付物与模板

  • 交付物：公司密码库及分组、凭据台账、授权与轮换记录、月度审计报告、《凭据分发规范》一页纸（入职培训必读）。
  • 建议模板/表单：
    • 凭据台账：凭据名称、系统/平台、环境、密级、用途、持有人、一主二备、授权使用人、创建日、到期/轮换日、最近轮换日、所在密码库条目。
    • 授权申请：申请人、凭据名称、用途、期限、密级、审批人、授权方式（分组/一次性链接）。

6. 异常与升级

  • 升级条件：L4 凭据（云主账号、root、超级管理员）授权、密码库选型、罚则口径、来源不明 Key 吊销影响业务 → 信息安全负责人升级兜底（CTO）拍板；L2/L3 授权与日常审计由信息安全负责人直接决定
  • 凭据已明文发到群、私聊或截图里 → 发送人立即撤回 → 30 分钟内按 X-SEC-11 处置，安全负责人登记
  • 同一人一个月内违规 2 次及以上 → 安全负责人通报所在团队负责人 → 按公司罚则处理（罚则口径由 CTO 与人事确认）
  • 来源不明的 Key、凭据台账里查不到持有人 → 先停用观察 24 小时，没人认领就吊销 → 有业务受影响的升级 CTO
  • 密码库不可用、紧急要用 → 持有人当面或在机器指定位置写入，告知位置，不发值 → 当天补登记
  • 平台屏蔽规则误伤正常文档（文档里提到 key 字样） → 文档改写为“去密码库某条目获取” → 必要时由 IT 运维申请加白

7. 衡量指标

  • 明文凭据次数 = 每月机器人检测到的群聊明文凭据条数，目标 0
  • 台账覆盖率 = 已登记的凭据数 / 审计发现的凭据数，目标 ≥ 95%
  • 按期轮换率 = 按时完成轮换的凭据数 / 到期应轮换数，目标 100%
  • 授权回收及时率 = 离岗或到期 1 个工作日内回收的授权数 / 应回收数，目标 100%

8. 低效诊断

  • 现象：管理员账号、Token、数据库连接、支付参数直接贴群并被二次转发，群成员变动后无法回收（分发环节）｜依据：「Leap产研测」2026-05、「鼎慧产研决策部」2026-01、「工程咨询产研」2026-02、「LeapCore（archived）」2026-05
  • 现象：只有事后口头提醒，同一问题提醒多次仍复发，没有成文规则和罚则口径（规则环节）｜依据：「鼎慧产研决策部」2026-06、「某投资机构客户项目群」2026-08、「LeapCore（archived）」2026-04
  • 现象：密码 90 天重置后要整体重发，使用人仍拿旧密码反复问（更新通知环节）｜依据：「鼎慧产研决策部」2026-01、「LeapAll（Deprecated）」2026-04
  • 现象：Key 来源不明只能靠猜再删，账号给了很多人后难以排查（登记环节）｜依据：「Leap产研测」2026-08
  • 现象：凭据过期没人负责轮换，导致部署连续失败才发现（轮换环节）｜依据：「工程咨询产研」2026-06
  • 现象：密码管理靠个人合租的家庭版，公司级方案讨论后没有结论（工具环节）｜依据：「鸽子群模态分群」2026-07
  • 现象：默认弱口令拖到上线前一晚才改（上线检查环节）｜依据：「LeapAll（Deprecated）」2026-04
  • 现象：紧急时在聊天记录里找不到客户系统账密（保管环节）｜依据：「某区政府客户项目群」2026-09

9. 分支变体

  • 研发联调参数：dev/test/prod 分开建条目，dev 参数不得用于 test 排查，发错时作废重授权。
  • 生产密钥与环境变量：随发布 checklist 列出新增变量，由环境运维从密码库注入，不经开发者转手；Apple 发布 API 密钥等账号级密钥按 L3 管理。
  • 客户系统账号：每个账号指定一主二备，按客户项目建分组，严禁在客户项目群发送。
  • AI 代理：使用独立最小权限 Token，不得持有生产写权限；能动生产的工具不交给 AI 操作。
  • 个人订阅账号（Codex/Claude 等）：不得外借共享，按 X-SEC-14 管理。

10. 待确认问题

  • 规范主责定为信息安全负责人是否合适？该岗位由谁担任（聊天中多由 Leap 研发/技术负责人提出相关规则，是否由其兼任）？IT 运维负责落地工具，这样分工是否可行？
  • 云与模型 Key 目前由 CTO 持有，是否移交专人持有，CTO 只做 L4 审批与兜底？
  • 密码库选型：商业团队版还是自建？预算和部署分别由谁负责？
  • L3 授权 1 个工作日内完成是否可行？审批人是安全负责人还是 CTO？
  • 违规罚则是否写入制度？口径需要人事确认。
  • 群聊明文检测机器人是否有必要的消息读取权限？需要飞书管理员评估。
  • 存量明文凭据（已留在群聊、文档里的）是否统一安排一次轮换？截止时间定在哪天？
X-SEC-11凭据泄露应急处置与密钥轮换待新建240

状态：待新建｜证据：有证据（卡片 8 张 / 会话 4 个）｜优先级：频3 × 耗4 × 跨4 × 险5

  • 适用场景：发现密钥、验证码、密码被截图外发、贴进群聊或日志、随代码提交、被过度共享、可能被 AI 读取，或 API 额度被异常用光、开发电脑中招时，立即禁用、轮换、溯源、复盘；另外每到轮换周期或发生重大节点（如保密协议生效、人员批量变动），也按本流程统一轮换。
  • 负责人：主责——信息安全负责人（当前：待指定）；协同——云与模型 Key 管理员/Gitea 管理员（当前：丁震宇·推断待确认）、IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、跃竞后端负责人（当前：王子明·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 发现并上报 → ② 定级 → ③ 止血（撤回、吊销、禁用账号） → ④ 轮换并按 X-SEC-10 重新分发 → ⑤ 溯源与影响排查 → ⑥ 恢复与解封 → ⑦ 登记复盘与整改
  • 交付结果：已吊销并替换的凭据、泄露事件登记表（含时间线、影响、处置、整改项）、轮换记录；重大事件附复盘纪要。
  • 状态依据：2026-03～09 至少出现 8 起泄露或疑似泄露（截图带密钥、日志外泄、代码提交带密码、额度被不明用光、开发电脑中招 4 人），每次都靠口头提醒和临时重置；对“内部群泄露算不算风险”说法不一；没有轮换登记，也没有扫描机制。

1. 场景判定

  • 触发条件：凭据出现在群聊、截图、日志、代码仓库、普通文档、AI 对话里；Key 用量或账单异常；终端疑似中毒；凭据持有人说不清来源；离职或调岗后凭据仍在外。
  • 典型说法：「你把密钥发出来了」「这个 key 注销下吧，昨天发日志泄露出去了」「谁把 claude api 用完了」「真得重置所有密钥了」「我提自动化代码的时候泄漏了密码」「这个密钥当时是谁生成的，有人用过吗」
  • 判断问题：这个凭据有没有在授权范围之外被看到、存储或使用过？有，或者无法排除，就按泄露处理，不由当事人自己判断“没风险”。
  • 不归本流程管：
    • 日常凭据分发与保管 → 请走 X-SEC-10
    • 高危漏洞、供应链投毒触发的批量排查与轮换 → 请走 X-SEC-41
    • 内网攻击、异常请求溯源 → 请走 X-SEC-42
    • 离职账号回收 → 请走 X-SEC-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
信息安全负责人 定级、指挥处置、组织溯源和复盘、跟踪整改 A 信息安全负责人（当前：待指定）
Key/账号管理员 吊销与重发云、模型、Gitea 等凭据，禁用和解封账号 R 云与模型 Key 管理员/Gitea 管理员（当前：丁震宇·推断待确认）
IT运维 终端隔离排查、重装、网络侧封禁，维护扫描机器人 R IT运维（当前：杨明学·推断待确认）
环境运维 轮换环境、数据库、CI 凭据并更新部署 R 环境运维（当前：宋祺睿·推断待确认）
子公司技术负责人 跃竞/跃玩线内的排查与通知 R 跃竞后端负责人（当前：王子明·推断待确认）
当事人/发现人 立即撤回、上报、配合排查 R 全员
兜底 P1 事件决策、对外通报、罚则 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 泄露的是哪个凭据（名称、平台、环境、密级），不要在上报里写出凭据值。
  • 泄露渠道和时间（哪个群、哪个仓库、哪份日志、哪次截图）、可能看到的人群范围。
  • 用量或登录日志截图（打码后）、异常发现时间。
  • 凭据台账里查到的持有人和使用方。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 撤回消息或删除文件，在“安全事件”表单上报（不写凭据值） 发现人/当事人 发现后 10 分钟内 飞书表单 事件记录 🔧飞书固化
2 定级：P1 生产、云主账号、客户环境、可付费 Key、终端中招；P2 测试环境、内部截图；P3 低敏、已失效 信息安全负责人 上报后 15 分钟内 事件表 级别 👤人工判断
3 止血：吊销 Key、改密、禁用相关账号或登录，涉事终端断网 Key/账号管理员、IT运维 P1 30 分钟内；P2 4 小时内；P3 1 个工作日内 云控制台、NewAPI、Gitea 吊销记录 👤人工判断
4 生成新凭据，按 X-SEC-10 经密码库重新授权，更新环境变量与 CI secrets 持有人、环境运维 止血后 2 小时内（P3 当天） 密码库、CI secrets 新凭据与授权记录 🔧+🤖
5 溯源：查用量、登录与调用日志，确认是否被滥用、凭据归属和传播路径 信息安全负责人 P1 当天；其他 3 个工作日内 平台日志、凭据台账 溯源结论 🤖+👤
6 终端中招：全员排查同类问题，涉事机器清理或重装，删除可疑 SSH Key，确认干净后提交解封申请 IT运维、当事人 排查当天完成；解封申请 1 个工作日内处理 飞书审批、Gitea 排查清单、解封记录 🔧+👤
7 登记复盘：时间线、影响、根因、整改项（如加 pre-commit 扫描、日志脱敏、工具白名单） 信息安全负责人 P1 3 个工作日内；P2 月度汇总 多维表格“安全事件台账” 复盘记录 🔧飞书固化
8 定期轮换：生产与 L3 以上凭据每 90 天轮换；人员变动、保密协议等节点触发统一轮换 持有人 到期前 7 天提醒，到期日前完成 凭据台账、提醒机器人 轮换记录 🔧+🤖

5. 交付物与模板

  • 交付物：安全事件台账、轮换记录、复盘纪要（P1 必出）、整改项清单。
  • 建议模板/表单：
    • 安全事件上报：发现人、发现时间、凭据名称（不含值）、平台/环境、泄露渠道、可见范围、是否已撤回、已知异常。
    • 安全事件台账：事件编号、级别、处置人、止血时间、轮换完成时间、溯源结论、是否造成损失、整改项、整改负责人、关闭时间。

6. 异常与升级

  • 升级条件：P1 事件（生产、云主账号、客户环境、可付费 Key、终端中招）、疑似外部盗刷、是否告知客户、当事人拒不配合、解封超过 1 个工作日 → 信息安全负责人升级兜底（CTO）决策；P2/P3 由信息安全负责人直接处置
  • 当事人或旁人认为“内部群没风险”不处置 → 以安全负责人定级为准 → 拒不配合的升级 CTO
  • Key 归属不明、无人认领 → 直接吊销并登记，观察 24 小时内的业务报错 → 有影响的找台账使用方重新申请
  • 额度或账单异常但查不到泄露渠道 → 先吊销、设限额，再查日志 → 疑似外部盗刷的当天升级 CTO，必要时联系平台冻结
  • 解封等待超过 1 个工作日 → 当事人在表单催办 → 升级 CTO 指定备份管理员处理
  • 涉及客户环境或客户数据 → 2 小时内通知项目负责人 → 是否告知客户由 CTO 决定

7. 衡量指标

  • 止血时长 = 上报到吊销完成的分钟数，P1 目标 ≤ 30 分钟
  • 轮换完成率 = 按期完成轮换的 L3 以上凭据数 / 应轮换数，目标 100%
  • 复盘闭环率 = 整改项按期关闭数 / 整改项总数，目标 ≥ 90%
  • 重复泄露次数 = 同一凭据或同一渠道 90 天内再次泄露的次数，目标 0

8. 低效诊断

  • 现象：截图、复制文档时带出密钥或验证码，只能靠事后口头提醒，没有扫描与轮换机制（发现环节）｜依据：「鼎慧产研决策部」2026-03、「鼎慧产研决策部」2026-08
  • 现象：泄露后对风险高低说法不一，有人认为“0 风险”就不改（定级环节）｜依据：「Leap产研决策部」2026-08
  • 现象：额度被异常用光后查不到是谁用的，账号为什么在别人手里也说不清（溯源环节）｜依据：「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-05
  • 现象：之前公开发出的 Key 有没有关掉，没人确认（关闭确认环节）｜依据：「鼎慧产研决策部」2026-05
  • 现象：第三方平台密钥不知道是谁生成、谁在用，只能直接重置（归属环节）｜依据：「跃迁AI总动员」2026-09
  • 现象：终端中招后解封只能等一个人，多人排队催（恢复环节）｜依据：「跃玩项目组」2026-03
  • 现象：平台敏感词屏蔽误伤了正常 SOP 文档，同事看不到（检测环节）｜依据：「鼎慧产研决策部」2026-08

9. 分支变体

  • 自动化代码或日志误带凭据：先吊销，再清理提交历史或日志；仓库启用 pre-commit 密钥扫描，日志统一脱敏。
  • 第三方平台密钥（公众号开发密钥、小程序密钥等）：先在 X-SEC-12 台账查归属，再重置并更新台账。
  • 开发电脑中招（跃竞/跃玩线已发生）：禁用 Gitea 登录与 SSH，全员排查，重装后申请解封；接口调试工具只用白名单内工具（跃竞线目前规定只用 Hoppscotch）。
  • 疑似被 AI 读取（本地 env、配置被 AI 工具访问）：按 P2 处理并统一轮换，后续把密钥移出本地明文文件。
  • 供应链或高危漏洞触发的批量轮换 → 按 X-SEC-41。

10. 待确认问题

  • 应急主责是否定为信息安全负责人？该岗位由谁担任？夜间和节假日由谁值守？
  • P1 30 分钟止血的时限能否做到？是否需要给 IT 运维开备份吊销权限？
  • L3 以上凭据 90 天轮换的周期是否合适？哪些凭据可以豁免？
  • 是否采购或自建统一密钥平台，支持一键吊销和用量告警？
  • 跃竞/跃玩线是否沿用本流程？开发工具白名单要不要推广到全公司？
  • 泄露责任与罚则如何定？是否需要人事、法务参与？
X-SEC-12第三方平台/对外账号台账与验证码代收待新建200

状态：待新建｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频4 × 耗2 × 跨5 × 险5

  • 适用场景：公司在云厂商、AI 平台、模型渠道、OCR、微信开放平台、Apple 开发者、社媒、政务申报系统等平台持有的账号，统一登记主体、实名人、绑定手机号/邮箱、管理员和使用人；验证码统一收口；账号交接、注销、欠费都按台账处理。
  • 负责人：主责——IT运维/平台账号管理员（当前：杨明学·推断待确认）；协同——CTO（现为多数平台账号持有人和收码人，当前：丁震宇·推断待确认）、总经办（当前：待指定）、财务（当前：待指定）、法务（当前：待指定）、运营（当前：吴文葶·推断待确认）、政策申报（当前：王蕊、赵雪冰·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 全量盘点登记 → ② 确认主体、实名人、管理员 → ③ 凭据入密码库 → ④ 绑定迁移到公司号码/公共邮箱 → ⑤ 验证码收码设备 + 机器人分流 → ⑥ 新增、交接、注销随时登记 → ⑦ 季度核对、到期和欠费提醒
  • 交付结果：一张“对外平台账号台账”（平台、主体、实名人、绑定手机号/邮箱、管理员、使用人、费用与到期），密码库中对应条目，验证码自动转发记录；不再有账号只绑在某个人的手机上。
  • 状态依据：没有账号主体台账。多个主体（武汉模态、苏州模态、鼎慧）名下的云账号出现“不知道谁在用”；大量平台绑定单人手机号，每次登录都要等这个人收码，他在开会时业务就卡住；管理层已要求上交“所有平台账号及实际使用人”，但没有承载工具；收码平台方案只停留在提案。

1. 场景判定

  • 触发条件：新注册或接手一个对外平台账号；需要登录共享账号而收不到验证码；忘记某平台的账号；账号要交接、转让管理员、注销；平台欠费、被封、认证到期。
  • 典型说法：「鼎慧的阿里云怎么登录来着」「那我每次登录要找你接码？」「来个码」「X 平台这个号不知道谁在用」「需要注销之前的社媒账号，它绑定的是您的手机号」「有个表管理一下就行」
  • 判断问题：这个账号属于公司（公司付费、公司业务在用）吗？是的话就必须进台账；登录要验证码的，验证码必须走公司收口。
  • 不归本流程管：
    • 凭据日常分发规则 → 请走 X-SEC-10
    • 模型 API Key 与额度 → 请走 RND-27
    • AI 编程工具订阅账号 → 请走 X-SEC-14
    • 云子账号与控制台权限 → 请走 X-SEC-15
    • 企业邮箱/公共邮箱开通 → 请走 X-SEC-04
    • 域名与备案主体 → 请走 X-SEC-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
平台账号管理员 维护台账和密码库分组，运营收码设备与机器人，季度核对 A IT运维/平台账号管理员（当前：杨明学·推断待确认）
现持有人 交出账号信息，配合换绑和管理员转让 R CTO（当前：丁震宇·推断待确认）
总经办 发起和验收全量盘点，确认账号主体归属 C 总经办（当前：待指定）
财务 维护付费账号的余额、充值、到期，接收欠费提醒 C 财务（当前：待指定）
法务 评估实名主体、境外号码使用的合规边界 C 法务（当前：待指定）
业务账号使用方 社媒、政务申报等账号的日常使用与登记 R 运营（当前：吴文葶·推断待确认）；政策申报（当前：王蕊、赵雪冰·推断待确认）
兜底 主体归属争议、高权限账号分配 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 平台名称、登录地址、账号标识（不写密码）、注册主体（武汉模态/苏州模态/鼎慧/其他）、实名人。
  • 绑定的手机号归属（个人/公司卡）、绑定邮箱（个人/公共邮箱）、2FA 方式。
  • 管理员、实际使用人、用途、付费方式、余额或到期日。
  • 要注销或转让的，准备好平台要求的主体材料。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发起全量盘点：各持有人填写“平台账号登记表”，凭据只写进密码库 平台账号管理员、各持有人 发起后 10 个工作日内完成 飞书表单、密码管理工具 台账初版 🔧飞书固化
2 逐条确认主体、实名人、管理员；归属不明的标“待认领”并在全员群公示 平台账号管理员、总经办 盘点后 5 个工作日内 多维表格 确认后的台账 👤人工判断
3 能换绑的账号把手机号换到公司号码卡、邮箱换到公共邮箱；管理员转给岗位而不是个人 现持有人、平台账号管理员 按台账逐批，每月至少完成 10 个 各平台后台 换绑记录 👤人工判断
4 验证码收口：公司号码卡插入收码设备，机器人按“平台→使用人/专用群”分流转发并留痕 平台账号管理员 方案落地后常态运行 收码设备、飞书机器人 转发日志 🤖自动化
5 过渡期仍绑个人手机的账号：在台账写明收码人和备份收码人，工作时间 15 分钟内回复 收码人 15 分钟内 飞书 收码记录 👤人工判断
6 新注册、交接、转让管理员、注销账号时，当天更新台账 经办人 变更当天 多维表格 变更记录 🔧飞书固化
7 余额、到期、认证到期前 15 天机器人提醒财务和管理员 机器人 到期前 15 天、7 天各一次 多维表格自动化 提醒记录 🤖自动化
8 季度核对：使用人是否在岗、账号是否仍需要、密码库是否一致；不用的账号走注销 平台账号管理员 每季度首月 10 日前 多维表格 季度核对表 🔧+🤖

5. 交付物与模板

  • 交付物：对外平台账号台账、密码库平台分组、号码卡台账、验证码转发日志、季度核对表。
  • 建议模板/表单：
    • 平台账号台账：平台、类别（云/AI 平台/模型渠道/开放平台/社媒/政务）、登录地址、注册主体、实名人、绑定手机号归属、绑定邮箱、2FA、管理员、使用人、用途、付费方式、余额/到期、密码库条目名、收码人、状态（在用/待认领/待注销/已注销）。
    • 号码卡台账：卡号尾号、运营商/国家、保号套餐、实名主体、所在设备卡槽、绑定的平台、月费、到期。

6. 异常与升级

  • 升级条件：账号主体归属有争议、“待认领”账号是否注销有争议、高权限账号分配、收码人与备份收码人都无法响应 → 平台账号管理员升级兜底（CTO）拍板；台账维护与常规换绑由平台账号管理员直接决定
  • 收码人 15 分钟没回复，业务被卡 → 找台账上的备份收码人 → 仍未解决的升级 CTO
  • 账号“待认领”超过 10 个工作日 → 管理员确认无业务依赖后冻结或注销 → 有争议的升级 CTO
  • 平台欠费停服 → 财务当天充值 → 影响客户交付的同时通知项目负责人
  • 账号被封或主体认证失败 → 管理员 1 个工作日内申诉 → 需要主体材料的找总经办，涉及合规的找法务
  • 账号实名绑在已离职人员名下 → 按 X-SEC-08 回收，同时发起换绑 → 无法换绑的由法务评估处置方式

7. 衡量指标

  • 台账覆盖率 = 已登记账号数 / 盘点发现账号数，目标 100%
  • 公司号绑定率 = 绑定公司号码卡或公共邮箱的账号数 / 在用账号数，目标季度提升，年底 ≥ 80%
  • 收码等待时长 = 申请到拿到验证码的分钟数，目标 ≤ 5 分钟（机器人）/ ≤ 15 分钟（人工）
  • 欠费停服次数 = 每季度因欠费导致的停服次数，目标 0

8. 低效诊断

  • 现象：同一主体名下的云账号没人知道谁在用、谁是管理员，只能临时找人确认（盘点环节）｜依据：「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-05
  • 现象：共享账号登录要在群里转发验证码，甚至发电脑登录密码请人代开机（验证码环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：账号信息只在私聊里，要“去翻翻”；密码管理器里的信息已过期（保管环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：海外平台注册到处借卡、找人收码，收码平台方案提出后没有落地（号码管理环节）｜依据：「鸽子群模态分群」2026-06
  • 现象：账号欠费、被封时才去找人处理，没有到期提醒（费用环节）｜依据：「忠橙星行星引擎」2026-05

9. 分支变体

  • 多主体：武汉模态、苏州模态、鼎慧分组登记；部分云平台折扣只绑定特定主体，开新账号前先确认用哪个主体。
  • 海外平台：海外号码卡单独登记；使用境外号码注册是否符合平台条款与国内实名要求，须先经法务评估。
  • 政务申报系统：项目负责人账号必须本人实名，不能迁移；在台账写明收码人，申报前 1 个工作日约好收码时间。
  • 社媒账号（小红书等）：注销或换绑需绑定人配合，由运营提前 5 个工作日提出。
  • 小程序、公众号密钥：只能重置时，重置后当天更新台账和密码库。

10. 待确认问题

  • 主责是否由 IT 运维承担？原持有人的账号要在多长时间内迁移完？
  • 收码设备和号码卡的采购由谁审批？保号月费从哪个费用科目出？
  • 全量盘点由总经办发起还是 IT 运维发起？截止时间定在哪天？
  • 政务申报类账号（必须个人实名）的收码人和备份人是谁？
  • 台账里是否需要记录费用？财务是否需要单独视图？
X-SEC-14AI 编程工具订阅账号开通、充值与防封管理待优化400

状态：待优化｜证据：有证据（卡片 26 张 / 会话 11 个）｜优先级：频5 × 耗4 × 跨5 × 险4

  • 适用场景：员工需要 Claude、Codex、GPT、Kimi 等 AI 工具订阅，或需要公司镜像账号（Sorux 等）时，统一走申请、开通、登记、月度充值、封号上报和回收；防封网络与设备配置按 IT 发布的指引执行。
  • 负责人：主责——IT运维/AI 账号负责人（当前：杨明学·推断待确认）；协同——行政（镜像订阅名单、充值、收票，当前：侯明月·推断待确认）、人事（新人统计，当前：黄莹·推断待确认）、规则与预算决策（当前：丁震宇·推断待确认）、财务（当前：待指定）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 按岗位选工具类型 → ② 提交 AI 工具申请（入职或月底申请） → ③ 审批工具、额度、支付方式 → ④ 开通（镜像开号 / 按防封指引代注册官方订阅 / 补贴自购） → ⑤ 登记账号台账 → ⑥ 每月 10 日统一充值和名单更新 → ⑦ 封号或风控上报、申诉退款 → ⑧ 离职或不用时回收
  • 交付结果：可用的 AI 工具账号、AI 工具账号台账（使用人、类型、支付方式、到期、状态）、月度充值记录、封号事件记录，以及一份受控的《AI 账号开通与防封指引》。
  • 状态依据：已有 wiki《订阅防封攻略（公司个人自购版）》，镜像订阅也有每月约 10 日开号、发 CDK 的节奏和负责人；但 2026-01～10 在 11 个群里反复出现开号、封号、充值断供、报销口径的问题，约 200 次；防封经验散在聊天里，不按文档操作就被封；新人开号要靠人提醒；CDK、借用账号在大群明文发；补贴、报销、代付的口径不一致。

1. 场景判定

  • 触发条件：新员工入职；员工需要某个 AI 工具或升级套餐；镜像站过期或欠费；账号被风控、被封、被降级；订阅不用了；需要临时借号给新人或合作伙伴。
  • 典型说法：「先给我整个 claude 号」「公司能不能给我报销 claude max」「sorux 过期了」「来个稳定的 claude 账号，不被封的那种」「目前很难给每个人搞稳定的官方订阅」「你自己走 SOP，文档在那」
  • 判断问题：要的是“个人使用的 AI 工具订阅或镜像账号”吗？是就走本流程；要 API Key 或额度，走 RND-27。
  • 不归本流程管：
    • 模型 API Key、NewAPI 额度 → 请走 RND-27
    • 海外出口线路与代理节点故障 → 请走 X-SEC-26
    • 新工具或高权限软件的安全试用 → 请走 X-SEC-36
    • AI 工具安全通告应急 → 请走 X-SEC-41
    • 个人垫付后的报销 → 请走 FIN-06（日常费用报销提交与审核）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
AI 账号负责人 维护指引和台账，代注册官方订阅，提供公司虚拟机/固定出口，处理封号 R IT运维/AI 账号负责人（当前：杨明学·推断待确认）
行政 镜像订阅的名单、每月充值、CDK 私发、收票 R 行政（当前：侯明月·推断待确认）
人事 入职表单收集 AI 工具需求，同步新人和离职名单 R 人事（当前：黄莹·推断待确认）
规则与预算决策 确定工具目录、补贴标准、中转站特批，审批申请 A CTO（当前：丁震宇·推断待确认）
财务 公司统一采购付款、补贴发放、个人垫付报销 C 财务（当前：待指定）
法务 评估境外订阅、支付方式和数据出境的合规边界 C 法务（当前：待指定）
使用人 按指引使用，一号一人，不外借，出问题及时上报 I 全员

3. 办之前请准备

  • 岗位类型（研发/非研发）、需要的工具和套餐、用途（是否涉及客户或涉密数据）。
  • 支付方式：公司统一采购 / AI 补贴自购 / 个人垫付报销（以财务确认口径为准）。
  • 官方订阅代注册：企业邮箱、可接收验证码的手机号、是否需要公司虚拟机或固定出口。
  • 先读一遍《AI 账号开通与防封指引》。
  • 请求最少包含字段（AI 工具申请表必填，缺项退回）：申请人、所属部门与岗位类型、工具与套餐、用途（是否涉及客户或涉密数据）、支付方式、期望可用日期与原因（入职/项目）、企业邮箱、新增/变更/取消、期限；封号登记另附：账号标识、时间、出口、最近操作、平台提示。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新人入职表单带“AI 工具需求”字段，自动写入台账待开通 人事 入职当天（到岗前 2 个工作日已知到岗日的，提前写入） 入职表单、多维表格 待开通记录（AI 账号台账"待开通"行，自动 @ AI 账号负责人与行政） 🔧+🤖
2 在岗员工每月 25 日前提交次月“AI 工具申请”（新增/变更/取消） 使用人 每月 25 日前；机器人 20 日催填 飞书表单 申请记录（飞书表单→台账一行，申请人可查状态） 🔧+🤖
3 审批工具类型、套餐、支付方式；中转站一律需要特批 规则与预算决策人 收到申请后 2 个工作日内 飞书审批 审批结果（飞书审批记录，通过/驳回理由自动回填台账）；超时→AI 账号负责人在审批流催办 👤人工判断
4 镜像账号：以企业邮箱开号，每月 10 日统一开通，CDK 由机器人私发，不在大群发 行政 每月 10 日（入职新人不晚于到岗后 1 个工作日） 镜像站后台、飞书机器人 开号与 CDK 记录（台账"已开通"+ 私信送达记录） 🔧+🤖
5 官方订阅：按防封指引在公司虚拟机或固定出口上代注册，或指导员工自购；一号一人一固定出口 AI 账号负责人 审批后 3 个工作日内 公司虚拟机、防封指引 可用账号（凭据进密码库，私信告知使用人条目位置）；超时→使用人在台账条目 @ 负责人 👤人工判断
6 登记台账：使用人、工具、套餐、支付方式、出口、到期日、状态；账号信息只放密码库 AI 账号负责人、行政 开通当天 多维表格、密码管理工具 台账记录（AI 账号台账，唯一来源；密码库条目编号回填） 🔧飞书固化
7 到期前 5 天提醒充值负责人；充值完成后通知使用人；供应商未回复时当天在群里告知预计恢复时间 行政 到期前 5 天提醒；到期前 1 个工作日完成充值 多维表格提醒 充值记录（台账到期日更新 + 使用人群通知）；供应商未回复→当天在使用人群发预计恢复时间 🤖自动化
8 封号或风控：使用人填写“封号登记”，负责人 1 个工作日内排查（出口、支付、设备、行为），决定申诉、退款或重开；同类问题集中时开复盘会 AI 账号负责人 登记后 1 个工作日内给处理结论 多维表格 封号事件记录（封号登记表 + 结论回填使用人）；超时→使用人在登记条目 @ 负责人，再超 1 个工作日报 CTO 👤人工判断
9 离职、取消或连续 1 个月未使用：停订、回收，台账标“已回收” 行政、AI 账号负责人 离职当天 / 次月 10 日 多维表格 回收记录（台账状态=已回收，人事异动通知为触发依据，见 HR-26） 🔧+🤖

5. 交付物与模板

  • 交付物：AI 工具目录（工具、适用岗位、支付方式）、AI 工具账号台账、《AI 账号开通与防封指引》（受控文档，只在公司内部可见）、月度充值记录、封号事件记录。
  • 建议模板/表单：
    • AI 工具申请：申请人、部门、岗位类型、工具、套餐、用途、是否涉及客户/涉密数据、支付方式、期限、新增/变更/取消。
    • 账号台账：使用人、工具、套餐、账号标识（不含密码）、支付方式、出口/虚拟机、开通日、到期日、状态（在用/封禁/回收）、密码库条目。
    • 封号登记：账号、时间、出口、最近操作、支付方式、平台提示、处理结果、是否退款。

6. 异常与升级

  • 镜像站过期断供 → 行政当天联系供应商并在群里通知 → 超过 1 个工作日未恢复的升级 CTO 启用备用渠道
  • 官方账号被封 → 按步骤 8 处理，可退款的 7 天内提交 → 一周内批量被封的升级 CTO，暂停新开号并复盘
  • 员工私用未审批的中转站，或把订阅号外借 → AI 账号负责人提醒并停用 → 涉及客户数据的按 X-SEC-11 评估
  • 急需订阅但支付方式不可用（借同事卡等） → 走临时特批，记录付款人 → 财务 5 个工作日内结清报销
  • 外部合作伙伴需要借用账号 → 必须审批，单独开号并设期限 → 不得把内部员工账号转借
  • 新人到岗后 1 个工作日仍无账号、或台账无其"待开通"记录 → 新人直属上级在台账补一行并 @ AI 账号负责人（不在大群喊"给我开个号"）→ 1 个工作日无响应升级 CTO
  • 开号、防封、报销口径类问题在群里被反复问 → 一律回指《AI 账号开通与防封指引》与 AI 工具目录链接；指引没写的，负责人 2 个工作日内补进指引再回复

7. 衡量指标

  • 开通时长 = 审批通过到可用的工作日数，镜像 ≤ 1 天（或下一个 10 日批次），官方订阅 ≤ 3 天
  • 断供天数 = 每月镜像站因欠费或名单问题不可用的天数，目标 0
  • 封号率 = 当月被封账号数 / 在用官方账号数，目标 ≤ 5%
  • 台账准确率 = 季度核对一致的账号数 / 台账账号数，目标 ≥ 95%
  • 重复提问量 = 群里关于开号、防封的提问数，目标比指引发布前下降 70%

8. 低效诊断

  • 现象：防封经验口口相传，每个新人从头踩坑，同类问题在群里反复问（知识沉淀环节）｜依据：「跃迁AI总动员」2026-07、「模态AI探索小分队」2026-06、「跃迁AI总动员」2026-10
  • 现象：指引已经有了，但买号后不按文档换绑就被秒封（执行环节）｜依据：「跃迁AI总动员」2026-10
  • 现象：开号代注册逐个手工做，支付和风控失败要返工（开通环节）｜依据：「忠橙星行星引擎」2026-10、「Leap产研决策部」2026-10
  • 现象：镜像站欠费后由使用人发现再 @ 充值负责人，等供应商回复期间没人通知（充值环节）｜依据：「AI工具跃迁交流群」2026-02、「AI工具跃迁交流群」2026-03
  • 现象：新人开号要靠人提醒统计，名单未统一导致断了几天（名单环节）｜依据：「AI工具跃迁交流群」2026-02、「行政人事对接群」2026-03
  • 现象：订阅不用也不取消，谁在用哪个订阅不清楚（回收环节）｜依据：「鼎慧产研决策部」2026-02
  • 现象：能不能报销、用补贴还是公司采购，口径不一（费用环节）｜依据：「鼎慧产研决策部」2026-01、「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-07
  • 现象：CDK、借用账号在大群里明文发（发放环节）｜依据：「AI工具跃迁交流群」2026-01、「AI工具跃迁交流群」2026-04

9. 分支变体

  • 共享镜像（Sorux 等）：主要给非研发；以企业邮箱为账号名；站点更换时统一核对名单；拟改为月底申请制，未申请的默认是否续订待定。
  • 官方订阅：研发优先 Codex 官方，其次 Claude Code；非研发由 IT 提供预配好的公司虚拟机；个人号分散注册，不集中挂在单一海外主体名下（避免一次被全部封停）。
  • 中转站：默认禁止，确有需要的走特批，且不得处理客户或涉密数据。
  • 数据边界：涉密或客户数据不得进入境外 AI 工具；会把本地文件上传云端的功能（如 Cowork 类）默认不用。
  • 跃竞等其他主体：沿用同一目录，费用按主体归集。
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-11（新人与新岗位上手）、ALL-08（信息归档与单一事实来源）、ALL-04（跨部门交接契约）

10. 待确认问题

  • AI 账号负责人是否正式定为 IT 运维？镜像订阅是否继续由行政负责？
  • 补贴、公司采购、个人垫付三种支付方式的适用范围和报销口径，需财务确认后发文。
  • 镜像订阅改为月底申请制后，没申请的人是否默认续订？
  • 境外订阅、支付方式和网络配置的合规边界，需要法务出书面意见。
  • 防封指引由谁维护版本？多久复核一次？
  • 公司虚拟机和固定出口的数量与预算，由谁审批？
X-SEC-15云平台子账号/控制台权限与 AccessKey 申请待新建144

状态：待新建｜证据：有证据（卡片 5 张 / 会话 2 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：研发、测试、运维或财务在腾讯云、阿里云、火山、EdgeOne 等控制台报“无权限”，或需要子账号、AccessKey、TCR 镜像推送、CLS/COS/CAM/监控、云安全产品、账单查看等权限时，按权限包申请、授权、登记，到期回收。
  • 负责人：主责——云平台管理员（当前：丁震宇·推断待确认）；协同——备份云管理员/IT运维（当前：杨明学·推断待确认）、环境运维（当前：宋祺睿·推断待确认）、财务（当前：黄梦婷·推断待确认）；兜底——IT运维负责人（当前：杨明学·推断待确认）
  • 核心流程：① 按岗位选权限包 → ② 提交云权限申请（平台、主体、资源、权限包、期限） → ③ 审批（高危权限人工判断） → ④ 一次性授予策略包或建子账号 → ⑤ AK 经密码库交付 → ⑥ 登记权限台账 → ⑦ 到期回收与季度盘点
  • 交付结果：申请人拿到可用的子账号或策略权限，AK 进密码库；云权限台账记录谁在哪个平台、哪个主体下有什么权限、到什么时候。
  • 状态依据：没有申请表、权限包和台账。2026-01～04「等保评估」「鼎慧产研决策部」中，权限每次只暴露一个缺口，要逐项贴报错往复多轮（单日约 10 次）；临时开的最高权限靠记忆回收；子账号密码和密钥被贴进群里；申请人不清楚自己权限有多大；唯一授权人不在时大家只能干等。

1. 场景判定

  • 触发条件：控制台提示 “User is not authorized to perform operation…”；新成员要开云子账号；需要创建或更换 AccessKey；需要账单只读或充值权限；等保整改要操作云安全产品；MFA 丢失要解绑。
  • 典型说法：「给我下腾讯云看账单权限」「为什么我进不去容器镜像服务」「我堡垒机还没权限」「给新同事开一个火山最高管理员」「能帮我解绑下腾讯云账号的 MFA 吗」
  • 判断问题：要的是云厂商控制台或 AccessKey 的权限吗？是就走本流程；要新的服务器、数据库、存储桶这类资源本身，走 X-SEC-16。
  • 不归本流程管：
    • 云服务器、COS、数据库、端口、镜像仓库等资源开通 → 请走 X-SEC-16
    • 生产资源访问 → 请走 X-SEC-18
    • 等保测评与云安全产品采购 → 请走 X-SEC-43
    • 模型服务 Key 与额度 → 请走 RND-27
    • 离职子账号回收 → 请走 X-SEC-08

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
云平台管理员 维护权限包，审批并授权，建子账号，管理主账号 A 云平台管理员（当前：丁震宇·推断待确认）
备份云管理员 主管理员不在时处理常规权限包授权，执行到期回收和季度盘点 R IT运维（当前：杨明学·推断待确认）
环境运维 提出研发、运维权限包需要的策略清单，CI 用 AK 的轮换 C 环境运维（当前：宋祺睿·推断待确认）
财务 账单只读、充值权限的申请与使用 C 财务（当前：黄梦婷·推断待确认）
申请人 按模板提交，权限够用后在申请单里确认 R 研发/测试/运维（当前：待指定）
兜底 主管理员长期不可用时接管，处理高危权限争议 A（升级） IT运维负责人（当前：杨明学·推断待确认）

3. 办之前请准备

  • 云平台（腾讯云/阿里云/火山/EdgeOne/其他）和主体（武汉模态/苏州模态/鼎慧）。
  • 要操作的产品和资源（如 CLS 某日志集、COS 某桶、TCR 某命名空间、云安全中心）。
  • 选好的权限包；不确定的附上完整报错原文。
  • 用途、期限（长期/临时到某日）、是否需要 AK、是否涉及生产。

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按岗位选权限包；报错不确定的，用 AI 根据报错原文生成最小策略清单 申请人 需要时 权限包清单、AI 助手 权限包/策略清单 🤖自动化
2 提交“云权限申请” 申请人 需要前 1 个工作日（紧急注明） 飞书审批 申请单 🔧飞书固化
3 审批：常规权限包直接通过；涉及生产、CAM/RAM、账单写、最高权限的人工判断并限期 云平台管理员 常规 4 个工作小时内；高危 1 个工作日内 飞书审批 审批结果 👤人工判断
4 一次性授予整个策略包或新建子账号（默认最小权限，强制 MFA）；提醒申请人等策略生效后重新登录 云平台管理员/备份管理员 审批后 2 个工作小时内 云 CAM/RAM 授权完成 🔧飞书固化
5 需要 AK 的，生成后直接写入密码库或 CI secrets，只授权给申请人或流水线 云平台管理员 与步骤 4 同时 密码管理工具 AK 条目 🔧+🤖
6 申请人验证；仍缺权限的在原申请单补充，不另起群聊 申请人 授权后 1 个工作日内 飞书审批评论 确认/补充 🔧飞书固化
7 登记权限台账：人员、平台、主体、权限包/策略、AK 有无、期限、审批单号 备份云管理员 授权当天 多维表格 台账记录 🤖+👤
8 临时权限到期当天回收；每季度盘点全部子账号、AK 和权限 备份云管理员 到期当天；每季度首月 10 日前 多维表格、云控制台 回收与盘点记录 🔧+🤖

5. 交付物与模板

  • 交付物：云权限包清单、云权限申请单、云权限台账、AK 密码库条目、季度盘点表。
  • 建议模板/表单：
    • 权限包清单：开发（CLS 读写、指定 COS 桶、TCR 推送、监控只读）、测试（只读加测试资源）、运维/等保整改（云安全中心、主机安全、WAF、堡垒机、TAT）、财务（账单只读、充值）；每个包写明包含的策略名。
    • 云权限申请：申请人、平台、主体、资源、权限包或策略清单、报错原文、用途、期限、是否需要 AK、是否涉及生产。
    • 云权限台账：人员、平台、主体、子账号名、权限包/策略、AK 标识（不含值）、开通日、到期日、审批单号、状态。

6. 异常与升级

  • 升级条件：主管理员长期不可用、紧急情况下需授予高危权限（生产、CAM/RAM、账单写、最高权限）、高危权限是否授予有争议 → 升级兜底（IT运维负责人）接管或裁定；常规权限包由云平台管理员审批
  • 授权后仍报错 → 申请人在原单贴新报错，管理员 2 个工作小时内补授权 → 同一单往复 3 次以上，回头修订权限包
  • 主管理员不在，业务被卡 → 备份管理员按常规权限包授权 → 高危权限仍需主管理员确认，紧急情况升级兜底人
  • 临时最高权限到期未回收 → 盘点时发现立即回收并登记 → 一个季度内发生 2 次的通报 CTO
  • MFA 丢失 → 申请人在飞书确认本人身份后由管理员解绑 → 涉及主账号的必须两人确认
  • AK 疑似泄露 → 按 X-SEC-11 处置

7. 衡量指标

  • 一次授权成功率 = 不需要补授权的申请数 / 申请总数，目标 ≥ 85%
  • 授权时长 = 提交到可用的工作小时数，常规目标 ≤ 4 小时
  • 临时权限按期回收率 = 到期当天回收数 / 到期临时权限数，目标 100%
  • 台账覆盖率 = 台账内子账号数 / 云平台实际子账号数，目标 100%

8. 低效诊断

  • 现象：权限每次只暴露一个缺口，申请人逐项贴报错，管理员逐项补，一天往复十来次（授权环节）｜依据：「等保评估」2026-01
  • 现象：授权后策略有延迟或给错角色，要来回试（授权环节）｜依据：「等保评估」2026-01、「鼎慧产研决策部」2026-04
  • 现象：临时给的最高权限靠口头约定事后收回（回收环节）｜依据：「等保评估」2026-04
  • 现象：申请人不清楚自己权限有多大，权限范围没有边界说明（台账环节）｜依据：「鼎慧产研决策部」2026-03
  • 现象：子账号密码、密钥贴在群里或要去翻私聊（交付环节）｜依据：「鼎慧产研决策部」2026-04
  • 现象：只有一人能授权，他不在电脑旁时部署中途卡住（单点环节）｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 腾讯云（CAM）：最高权限目前只有两人，常规权限包应开放给备份管理员授予。
  • 阿里云（RAM）：部分产品（如百炼）权限和 RAM 独立，需单独授权；AK 与代金券、折扣绑定在特定主体账号上，开前先确认主体。
  • 火山引擎：折扣只在特定主体可用；财务子账号单独开，仅账单与充值权限。
  • 等保整改：用“运维/等保整改”权限包一次授予，整改期结束当天收回。
  • 新成员批量开号：随 X-SEC-01 入职清单一并触发。

10. 待确认问题

  • 主责是否从 CTO 移交给 IT 运维，CTO 只保留高危权限审批？
  • 各权限包具体包含哪些策略？由谁起草（建议环境运维起草，管理员审定）？
  • 常规授权 4 个工作小时内完成是否可行？备份管理员需要哪些 CAM/RAM 权限？
  • 临时最高权限的最长期限定多少？
  • 子账号是否全部强制 MFA？MFA 丢失的解绑流程是否需要直属上级确认？
X-SEC-16云服务器与云资源申请开通（CVM/COS/数据库/端口/镜像仓库）待优化240

状态：待优化｜证据：有证据（卡片 28 张 / 会话 19 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：研发、交付、售前或非研发同事需要公有云服务器、对象存储桶、云数据库、安全组端口或镜像仓库时，从提需求到开通、登记、到期回收的全过程
  • 负责人：主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、资源审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交“非实体资产申领”审批 → ② 资源审批人审规格与必要性 → ③ 云资源管理员按模板开通（IaC 优先）→ ④ 凭据按规范下发 → ⑤ 登记资源台账 → ⑥ 申请人验收 → ⑦ 到期提醒续用或释放
  • 交付结果：已开通可用的云资源 + 审批单留痕 + 资源台账一行记录（用途/负责人/项目/到期日/费用）
  • 状态依据：飞书审批“非实体资产申领”自 2026-05 起使用并在全员群公告，但 01～10 月聊天中仍大量通过群内 @ 人或私下要机器（约 150 次），反复出现“找谁申请”、端口迟迟未开、开错规格重买、凭据明文发群

1. 场景判定

  • 触发条件：需要新的公有云 CVM/轻量服务器/GPU 云主机、COS 桶、云 PG/Redis、TCR 镜像仓库、安全组端口；或现有云服务器升配、扩容、换地域
  • 典型说法：「给他开个服务器」「开 5212、10000-20000 端口」「来个配置，去开腾讯云机器」「公司的 docker hub 来一个」「我需要一台机器部署一套 leapcore，我该找谁」
  • 判断问题：资源是否在公有云上、是否由公司付费、是否会存在超过 1 天？任一为“是”即走本流程
  • 不归本流程管：内网 PVE/GPU/CI runner/测试机 SSH → 请走 X-SEC-17；生产机或客户环境访问 → 请走 X-SEC-18；仅域名解析/证书/端口变更 → 请走 X-SEC-19；ICP 备案 → 请走 X-SEC-20；云子账号/AccessKey → 请走 X-SEC-15；模型额度/NewAPI → 请走 RND-27；盘点与销毁 → 请走 X-SEC-22；实体服务器/硬件采购 → 请走 ADM-24；外部 GPU 租赁 → 请走 RND-24

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 按清单填申请单、验收、到期确认续用或释放 R 各研发/交付/售前同事（当前：按需）
资源审批人 审规格与必要性、能否合并到已有机器、公网暴露把关 A CTO/资源审批人（当前：丁震宇·推断待确认）
云资源管理员 按模板开通、配安全组、下发访问方式、登记台账 R 云资源管理员（当前：宋祺睿·推断待确认）
IT 运维 维护审批表单与台账、云厂商折扣与配额、备岗开通 C IT 运维（当前：杨明学·推断待确认）
财务 云账户充值、续费与欠费付款 C 财务（当前：待指定）
项目负责人 知悉资源归属与费用 I 项目负责人（当前：按项目）

3. 办之前请准备

  • 用途与归属项目（开发/测试/预览/正式/售前 Demo/内部系统）、所属主体、负责人与备岗人
  • 规格：CPU/内存/系统盘/数据盘、系统镜像、地域；带宽默认按流量计费，不开固定带宽
  • 需开放的端口与访问来源（公网/内网/指定 IP），是否需要域名与 HTTPS
  • 预计使用时长或到期日
  • 是否需要 COS/数据库/镜像仓库，读写还是只读
  • 已确认现有机器无法合并使用的说明
  • 用于登录的 ed25519 公钥（不收、不发密码）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在“非实体资产申领”审批中按第 3 节填全字段提交 申请人 需求确定当天 飞书审批 申请单 🔧飞书固化
2 审规格与必要性；可合并到已有机器的驳回并给出合并截止日 资源审批人 提交后 4 个工作小时内 飞书审批 通过/驳回意见 👤人工判断
3 审批通过后自动生成开通任务派给云资源管理员 机器人 即时 飞书审批+任务 开通任务 🔧飞书固化
4 按标准模板开通（折扣机型、预装 docker、通用安全组），资源打负责人/项目/到期标签 云资源管理员 审批后 1 个工作日内；售前 Demo 4 个工作小时内 IaC 仓库/云控制台 实例/桶/库 🤖自动化
5 只开放申请中列出的端口；面板与数据库设强密码；关闭预装的无关软件 云资源管理员 与步骤 4 同步 云安全组 安全配置 👤人工判断
6 写入申请人公钥；密码类凭据放密钥管理，群内只发实例名与访问方式 云资源管理员 与步骤 4 同步 IaC/密钥管理 访问方式 🔧+🤖
7 写入资源台账（实例 ID、IP、规格、用途、负责人、到期、计费方式、审批单号） 云资源管理员 开通当天 多维表格 台账记录 🤖+👤
8 登录自测，在任务中点“验收” 申请人 收到通知后 1 个工作日内 飞书任务 验收记录 🔧飞书固化
9 到期前 7 天提醒负责人续用或释放；释放按 X-SEC-22 执行 机器人/申请人 到期前 7 天 多维表格自动化 续用单或释放单 🤖自动化

5. 交付物与模板

  • 交付物：可用云资源、审批单、资源台账记录、开通通知（不含明文凭据）
  • 建议模板/表单：“云资源申请单”——资源类型（CVM/轻量/GPU/COS/数据库/TCR/端口）、所属主体、项目、用途、环境、规格、地域、计费方式、端口与访问来源、是否需域名、预计到期日、负责人、备岗人、公钥
  • 资源台账字段：资源 ID、云账号、主体、IP、规格、用途、环境、负责人、到期日、月费用、审批单号、状态（在用/停用待释放/已释放）

6. 异常与升级

  • 云账号配额、CPU 上限或 GPU 需开白 → 云资源管理员联系云厂商商务 → 1 个工作日未解决升级 CTO
  • 云账户欠费停机 → 云资源管理员在财务群发起付款 → 当天未到账升级财务负责人
  • 售前紧急演示（24 小时内）→ 先开通后补单，补单不晚于次日 → 资源审批人事后复核
  • 开错规格或地域需重开 → 新机可用后旧机按 X-SEC-22 释放，新旧并行不超过 7 天
  • 申请公网暴露数据库/管理面板 → 退回改为内网或跳板访问 → 有争议由 CTO 决定
  • 云资源管理员外出无法操作 → IT 运维备岗开通 → 仍无法处理时升级 CTO

7. 衡量指标

  • 开通时效：审批通过到验收的工作小时数，目标 P90 ≤ 1 个工作日
  • 走单率：当月走审批开通的资源数 / 当月新增资源数，目标 ≥ 95%
  • 台账完整率：带负责人和到期日的资源数 / 云上资源总数，目标 100%
  • 明文凭据次数：群聊中出现服务器或面板密码的次数，目标 0

8. 低效诊断

  • 现象：申请入口不统一，审批单、群内 @、私下沟通并存，申请人反复问“找谁开”｜依据：「Leap产研测」2026-07、「开放平台Only」2026-10、「核心项目群」2026-09
  • 现象：需求信息不全（缺端口、缺规格），开通后来回追问或重开｜依据：「制造业demo」2026-03、「鼎慧产研决策部」2026-02
  • 现象：开通后不登记，机器归属与用途靠记忆，到期无人回收｜依据：「Leap产研测」2026-05、「鼎慧产研决策部」2026-06
  • 现象：初始凭据、面板密码、IP 在群内明文流转｜依据：「鼎慧产研决策部」2026-02、「制造业demo」2026-03、「平台部」2026-01
  • 现象：开通权限集中在少数人，执行人外出时端口、解析等几分钟的操作也要等半天｜依据：「LeapVPN网络预研」2026-08、「跃迁基座项目交付沟通」2026-05
  • 现象：一个业务一台机、机型选成高价型号后再迁移｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 售前 Demo 机：可先开后补单，默认期限 30 天，演示结束迁到公司统一演示环境
  • 测试服/正式服扩容：正式服升配前强制快照；无法扩容只能重买时，切换后按 X-SEC-22 销毁旧机
  • 非研发同事自建内部系统上线：开通后按 RND-62 部署，公网访问必须加认证，不放隐私数据
  • 闲置云服务器试用：申请单备注“云服务器体验装”，期限 1 个月，先到先得
  • 多主体：下单账号与费用主体与项目主体一致（模态/鼎慧/跃迁/跃竞），跨主体使用在申请单注明
  • 多云：默认腾讯云；阿里云、金山云、海外节点需在申请单写明原因

10. 待确认问题

  • 主责是否定为云资源管理员（当前人选见负责人栏），IT 运维是否为备岗？公有云与内网的分工是否按此划分？
  • “非实体资产申领”审批由 X-SEC 还是行政（ADM-34）维护？表单能否按第 5 节补全字段？
  • 资源审批人是否只保留 CTO？是否按规格或月费分级（如 GPU、月费超阈值才需 CTO）？
  • 4 个工作小时审批、1 个工作日开通的时限是否可行？
  • 是否强制 IaC 开通并打标签？密钥管理工具选哪一个？
  • 售前 Demo 默认 30 天、体验机 1 个月的期限是否合适？
X-SEC-17内网测试服务器/GPU/虚拟机/CI Runner 资源申请、SSH 开通与调度待新建180

状态：待新建｜证据：有证据（卡片 16 张 / 会话 7 个）｜优先级：频5 × 耗3 × 跨3 × 险4

  • 适用场景：产研需要公司机房内网的测试机、GPU（5090/4090 等）、PVE 虚拟机/LXC、CI runner、共享算力机账号、磁盘或内存扩容、测试机 SSH 登录，或 IT 需要换机、重置、回收时
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——资源优先级评估人/CTO（当前：丁震宇·推断待确认）、测试环境管理人（当前：张东郅·推断待确认）、CI 负责人（当前：吴世豪·推断待确认）、共享机与体验机管理员（当前：宋祺睿、岳阳·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交内网资源申请 → ② 优先级评估与排期 → ③ 网管建机、分配 IP/端口段 → ④ 公钥授权 → ⑤ 登记资源池台账 → ⑥ 使用中巡检与限额 → ⑦ 换机/重置提前通知，到期回收
  • 交付结果：可登录的内网机器/虚拟机/GPU 时段/runner + 资源池台账记录（IP、用途、占用人、环境级别、到期日）+ 变更通知记录
  • 状态依据：只有零散的 GPU 登记表、395 资源需求表单和部分“非实体资产申领”卡片；01～10 月多数申请仍靠群里催“网管我虚拟机呢”，并发生共享机被打满失联、Agent 残留进程占满测试服、换机当天才通知研发等事故

1. 场景判定

  • 触发条件：需要内网物理机/虚拟机/LXC、GPU 卡时、CI runner、共享算力机账号、扩容、独立 IP 或端口段、测试机 SSH；IT 需要回收、重置或替换机器
  • 典型说法：「还有机器可以部署吗，我要测集群」「网管我虚拟机呢」「想申请使用 5090 的，先来定时间和预期内容」「发下公钥」「你们的开发服务器目前能停用吗」
  • 判断问题：资源是否在公司机房或办公网内？是否是需要排期的共享资源？是则走本流程
  • 不归本流程管：公有云资源 → 请走 X-SEC-16；生产机/客户环境访问 → 请走 X-SEC-18；需新采购硬件、内存条 → 请走 ADM-24；外部 GPU 租赁 → 请走 RND-24；CI 流水线本身 → 请走 RND-37；环境分层规划 → 请走 RND-48；机房停机与故障 → 请走 X-SEC-29

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填申请、自测、按规则使用、用后释放并清理残留 R 各研发/测试（当前：按需）
资源优先级评估人 GPU 与共享资源优先级、是否抢占、预算 A CTO（当前：丁震宇·推断待确认）
IT 运维/网管 建机、分配 IP/端口段、PVE 权限、巡检、回收重置、台账 R IT 运维（当前：杨明学·推断待确认）
测试环境管理人 开发/测试环境换机统一安排、通知研发 C 测试负责人（当前：张东郅·推断待确认）
CI 负责人 汇总 runner 需求并验收 C CI 负责人（当前：吴世豪·推断待确认）
共享机/体验机管理员 共享算力机、体验服账号发放与使用规则 R 研发（当前：宋祺睿、岳阳·推断待确认）
研发负责人 机器用途（生产/测试/开发）规划拍板 C Leap 研发负责人（当前：王皓南·推断待确认）

3. 办之前请准备

  • 用途、所属项目、使用人与备岗人
  • 规格：CPU/内存/磁盘/系统（含麒麟等国产系统要求），是否需要 GPU 及卡型
  • 使用时段或到期日（GPU 按天/周申请）
  • 端口需求（默认 100 个端口段，更多须注明）、是否需要独立 IP
  • ed25519 公钥
  • 环境级别：开发（可随时重置）/测试（按节奏重置）/准生产（不可随意迁移）
  • 多个需求分开提单，不合并在一条消息里

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交内网资源申请（资源类型选“内网”） 申请人 需求确定当天 飞书审批 申请单 🔧飞书固化
2 评估优先级、是否抢占、排期并回写申请单 资源优先级评估人 提交后 1 个工作日内 资源池多维表格 排期 👤人工判断
3 建机/建虚拟机/分配 GPU 时段或 runner IT 运维 排期日当天；虚拟机 1 个工作日内 PVE/IaC 机器 🤖自动化
4 配 IP、端口段、网关并写入脚本持久化（重启不丢） IT 运维 与步骤 3 同步 脚本仓库 网络配置 🤖自动化
5 公钥统一由 IaC/updater 下发；面板默认口令首登强制修改，不在群里发口令 IT 运维 与步骤 3 同步 IaC/PVE 访问方式 🔧+🤖
6 登记资源池台账并自动通知申请人 IT 运维 开通当天 多维表格+机器人 台账记录 🤖自动化
7 按规则使用：容器限 CPU/内存/磁盘，预留约 1/4 内存给基础服务；AI Agent 任务结束后检查并清理残留进程、大文件 申请人 每次任务结束 监控告警 清理记录 🤖+👤
8 巡检：CPU/内存/磁盘超阈值告警；30 天未登录推送确认 IT 运维 每周一 监控机器人 巡检报告 🤖自动化
9 换机/重置/下线：提前 3 个工作日在台账和群内通知，由测试环境管理人统一安排，使用人确认备份 IT 运维+测试环境管理人 变更前 3 个工作日 飞书任务 变更通知 🔧飞书固化
10 到期前 3 天提醒；未续期则备份后重置并更新台账 IT 运维 到期日 机器人 回收记录 🤖自动化

5. 交付物与模板

  • 交付物：可用内网资源、申请单、资源池台账记录、变更与回收通知
  • 建议模板/表单：内网资源申请单——资源类型（物理机/虚拟机/LXC/GPU/runner/共享机账号/扩容/SSH）、规格、系统、GPU 卡型与时段、端口数量/独立 IP、环境级别、用途、项目、使用人、到期日、公钥
  • 资源池台账字段：主机编号、IP、宿主机、规格、当前用途、环境级别、占用人、开始/到期、上次登录、是否可重置、备注
  • 共享机使用规则卡（群置顶）：资源限额、残留清理、禁止事项（不当稳定服务、不删代理）、随时可回收

6. 异常与升级

  • 共享机被打满失联 → IT 运维重启并定位占用进程 → 当天群内复盘；同类事件 2 次以上由研发负责人定配额
  • 资源不足需采购 → 转 ADM-24 提实体资产审批 → 5 个工作日未到货升级 CTO
  • 内部使用与客户交付抢同一台机器 → 研发负责人当天拍板 → 拍不了升级 CTO
  • 重启后端口映射/网络配置丢失 → IT 运维按脚本恢复 → 2 小时未恢复群内公告并升级 CTO
  • 夜间或网管外出无人响应 → 备岗处理（待指定）→ 影响发版时电话升级 CTO

7. 衡量指标

  • 交付时效：申请到可登录的工作小时数，虚拟机目标 ≤ 8 小时
  • 台账覆盖率：台账登记主机数 / 实际在用主机数，目标 100%
  • 突发换机次数：未提前 3 个工作日通知的换机/重置次数，目标 0
  • 共享机事故：因资源耗尽失联的次数，目标每月 0
  • 催办量：群内“机器呢”类催办消息数，逐月下降

8. 低效诊断

  • 现象：申请靠群内 @ 网管，排期不透明，网管同时兼采购、备案、网络，催办频繁｜依据：「鸽子群模态分群」2026-01、「Leap产研测」2026-06
  • 现象：没有环境台账，机器用途反复变更，换机当天才通知导致研发中断、数据迁移返工｜依据：「Leap产研测」2026-07、「Leap产研决策部」2026-08
  • 现象：共享资源无限额无监控，批量下载和 Agent 残留进程打满机器｜依据：「Leap产研测」2026-06、「Leap产研测」2026-09、「跃迁AI总动员」2026-10
  • 现象：申请单字段不清、多需求混在一起，审批被关闭后重提｜依据：「Leap产研测」2026-08
  • 现象：公钥、默认口令、连接文件在群里流转｜依据：「Leap产研测」2026-08、「495 体验服」2026-10
  • 现象：网络配置未持久化，重启后端口映射丢失｜依据：「鸽子群模态分群」2026-03

9. 分支变体

  • GPU（5090/4090 等）：半抢占+优先级，先与评估人定时间和预期内容，按天/周登记；部分卡归属特定应用，分配前确认
  • PVE 虚拟机/LXC：按 VM 编号划端口段，大端口需求申请独立 IP
  • CI runner：由 CI 负责人汇总统一申请，磁盘/内存预算由 CTO 批
  • 共享算力机：找管理员开号，多用户不隔离，监控占用与上次登录时间
  • 体验服务器：仅试用，WireGuard 接入，随时可收回
  • leapssh 访问：工具作者发放，计划接审批与飞书 OIDC
  • 环境级别：开发随时可重置；测试按节奏重置；准生产不可随意迁移

10. 待确认问题

  • 主责是否为 IT 运维/网管（当前人选见负责人栏）？备岗由谁担任？
  • 内网资源是否也走“非实体资产申领”审批，还是单独建内网资源申请表？
  • GPU 与共享资源优先级评估人是否固定为 CTO？
  • 换机提前 3 个工作日通知是否可行？
  • 共享机限额具体数值（如 64G 机器给 Agent 最多 48G）是否写成规则？
  • 现有 GPU 登记表、395 需求统计表、a395 运维笔记是否合并为一张资源池台账？
X-SEC-18生产资源访问申请审批与回收待优化200

状态：待优化｜证据：有证据（卡片 8 张 / 会话 9 个）｜优先级：频4 × 耗2 × 跨5 × 险5

  • 适用场景：研发或业务人员需要登录生产服务器、访问生产或客户数据库、查生产日志、获取生产环境变量，或做生产数据备份迁移时
  • 负责人：主责——生产权限开通执行人/运维（当前：宋祺睿·推断待确认）；协同——审批人/Leap 研发负责人（当前：王皓南·推断待确认）、客户环境运维（当前：杨明学、游家豪·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交“Leap 生产资源访问申请” → ② 审批人核对资源/上下文/预期操作 → ③ 机器人建专属群 → ④ 签发限时凭证（公钥/跳板/只读账号）→ ⑤ 访问操作留痕 → ⑥ 到期自动回收并关单 → ⑦ 月度复核
  • 交付结果：审批单、限时访问凭证、操作记录、回收确认、归档的专属群
  • 状态依据：2026-07 已上线飞书审批“Leap 生产资源访问申请”并自动建群，但授权仍是群里手工加公钥、账号密码直接贴群、到期回收靠人提醒；此前出现过绕过确认直接发布生产、在生产机上调试导致全部客户受影响

1. 场景判定

  • 触发条件：登录生产服务器（102 等）；访问客户生产环境（需 WireGuard）；读写生产数据库；查生产 ClickHouse/日志；获取生产 COS/数据库连接变量；生产数据备份/迁移
  • 典型说法：「102 加下我的 key」「生产数据库地址是哪个」「请帮忙查询……全部历史操作日志」「处理完了吗？完成的话关闭吧」「为什么你没审批还能看 102」
  • 判断问题：操作对象是否承载真实客户/业务数据或对外服务？是则必须先走本流程，不得私下要权限
  • 不归本流程管：测试/开发环境 → 请走 X-SEC-17；生产发布与变更 → 请走 RND-51、RND-58；凭据保管规范 → 请走 X-SEC-10；凭据泄露 → 请走 X-SEC-11；客户设备 root/远程接入 → 请走 X-SEC-07

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填资源/上下文/预期操作，按批准范围操作，完成后申请关闭 R 研发/业务（当前：按需）
审批人 判断必要性、访问范围与时长 A Leap 研发负责人（当前：王皓南·推断待确认）；备审：宋祺睿、丁震宇、杨云峰（推断待确认）
开通执行人 下发公钥/跳板/只读账号，到期回收，归档 R 运维（当前：宋祺睿·推断待确认）
客户环境运维 客户环境 WireGuard 配置与放通 R 运维/交付（当前：杨明学、游家豪·推断待确认）
常驻权限人（一主二备） 持有常驻生产权限，负责紧急处置 C 待指定
研发负责人 权限矩阵与规则拍板，接收月度复核 I 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 访问资源（选项：内部生产机/客户环境/数据库/日志/环境变量）
  • 上下文：问题单号或排查原因
  • 预期操作：只读查询/导出/变更；写操作附回滚方案
  • 访问时长：默认 2 小时，最长 1 个工作日
  • ed25519 公钥；需要白名单时提供访问设备出口 IP
  • 业务查询类：写清查询条件，优先由研发代查

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“Leap 生产资源访问申请” 申请人 访问前 飞书审批 申请单 🔧飞书固化
2 审批：核对必要性、范围、时长，写操作看回滚方案 审批人 工作时间 30 分钟内；P0 故障 10 分钟内 飞书审批 批准范围 👤人工判断
3 机器人建专属群，推送卡片并 @ 开通执行人 机器人 即时 审批机器人 专属群 🔧飞书固化
4 签发限时凭证：服务器加带有效期的公钥；数据库给 ssh 跳板/代理或只读账号；业务查询由研发代查导出 开通执行人 审批后 30 分钟内 IaC/leapssh/跳板机 访问凭证 🤖自动化
5 在批准范围内访问，命令与查询留痕；禁止在生产机上测试、调试 申请人 批准时段内 审计日志 操作记录 🤖自动化
6 群内回复处理结论并申请关闭 申请人 完成当天 专属群 结论 🔧飞书固化
7 到期自动回收公钥/账号、移除白名单，群内提示 机器人/开通执行人 到期即时 脚本 回收记录 🤖自动化
8 关单、解散专属群，审批单关联操作记录 开通执行人 回收后 1 个工作日内 飞书审批 归档 🔧飞书固化
9 复核常驻权限名单与当月审批记录，清理越权账号 审批人 每月首个工作日 多维表格 复核记录 👤人工判断

5. 交付物与模板

  • 交付物：审批单、凭证签发与回收记录、操作审计记录、月度复核表
  • 建议模板/表单：审批字段——资源名称（选项）、上下文、预期操作、读/写、开始时间、时长、公钥、出口 IP、关联问题单
  • 生产权限矩阵：资源、常驻权限人（一主二备）、审批人、凭证方式（公钥/跳板/只读账号/代查）、最长时长
  • 回收清单：公钥、数据库账号、白名单、WireGuard 配置

6. 异常与升级

  • 线上 P0 故障需立即进入 → 常驻权限人先处置，30 分钟内补单 → 通知研发负责人
  • 批准后连不上（WireGuard 断开/白名单缺失）→ 开通执行人 30 分钟内排查 → 1 小时未通升级客户环境运维
  • 开通执行人外出 → 备岗执行（待指定）→ 群内 @ 审批人协调
  • 发现未审批持有生产权限 → 立即收回并补单 → 报研发负责人
  • 凭证在群内明文出现 → 按 X-SEC-11 轮换 → 当天完成
  • 未经确认发布生产 → 按 RND-59 回滚并复盘 → 报 CTO

7. 衡量指标

  • 授权时效：提交到凭证可用的分钟数，目标 ≤ 60 分钟
  • 到期回收率：按时回收单数 / 总单数，目标 100%
  • 无单访问：审计发现的无审批生产登录次数，目标 0
  • 明文凭证：生产凭证出现在群聊的次数，目标 0
  • 常驻生产权限人数：每个生产资源 ≤ 3 人

8. 低效诊断

  • 现象：生产权限长期普遍开放，开发可直接发布或在生产机复现问题，出事后才收权｜依据：「鼎慧产研决策部」2026-06、「Leap产研测」2026-07
  • 现象：审批已上线但授权仍手工，申请人在群里逐级找人开通，执行人外出即卡住｜依据：「审批-Leap 生产资源访问申请」2026-07、2026-08、2026-09
  • 现象：生产连接地址、账号密码、环境变量直接贴群｜依据：「工程咨询产研」2026-07、「告警通知群」2026-10
  • 现象：数据库归属不清，“谁负责”和“谁操作”需临时解释｜依据：「Leap产研测」2026-05
  • 现象：建审批流本身卡在审批 App 权限，不清楚找谁开通｜依据：「鼎慧产研决策部」2026-07
  • 现象：设备白名单未登记，生产库连不上后才排查｜依据：「工程咨询产研」2026-10

9. 分支变体

  • 内部生产服务器：公钥授权，目标改为 CLI 生成限时 SSH key，或经 updater 下发脚本，不直接 SSH
  • 客户生产环境：需 WireGuard，由客户环境运维按审批时段放通
  • 数据库：经 ssh 跳板/代理访问，云 PG 仅内网；新同事只给只读账号
  • 业务方查生产数据/日志（含跃竞业务线）：不提供连接信息，由研发代查留痕，或开只读查询机器人
  • 数据库备份/迁移：先快照；申请人申请，管理员批准并操作
  • 常驻权限：一主二备常驻，其他人一律临时提审

10. 待确认问题

  • 审批人是否固定为 Leap 研发负责人？鼎慧、跃竞、工程咨询线的生产审批人分别是谁？
  • 各生产资源的“一主二备”常驻权限名单？
  • 默认 2 小时、最长 1 个工作日的时长是否可行？
  • 限时 SSH key 的 CLI、leapssh 接审批何时上线，由谁负责？
  • 业务方查询生产数据是否纳入本流程，由谁代查？
  • 生产机是否启用命令审计，日志保留多久？
X-SEC-19域名解析、SSL 证书与端口开通待优化48

状态：待优化｜证据：有证据（卡片 5 张 / 会话 5 个）｜优先级：频4 × 耗2 × 跨2 × 险3

  • 适用场景：新服务、内部工具、演示环境上线时，需要在已备案主域名下加子域名解析、HTTPS 证书、CNAME/EdgeOne 配置、COS 跨域或安全组端口放行
  • 负责人：主责——DNS/证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人/端口审批人（当前：丁震宇·推断待确认）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 提交域名/端口变更单 → ② 校验命名、备案状态与目标 → ③ 公网端口审批 → ④ 配置解析/EdgeOne/安全组/CORS → ⑤ 自动签发证书 → ⑥ 申请人验证 → ⑦ 登记域名台账
  • 交付结果：可访问的 HTTPS 域名或已放行的端口 + 域名台账记录（域名、解析目标、证书方式、负责人、备案主体）
  • 状态依据：已有“解析先填表”“域名提单”的要求，但 03～10 月仍多为群里或私下 @ 人，缺目标 IP、域名含下划线、443 未开、是否备案反复排查，约 30 次

1. 场景判定

  • 触发条件：新增子域名、修改解析、CNAME/301、接入 EdgeOne、申请 HTTPS 证书、COS/OSS 跨域、开放安全组端口、配置遥测域名
  • 典型说法：「帮忙解析个域名」「解析什么解析到哪，填表」「谁提的申请，ip 呢，没 ip 我怎么配」「麻烦帮忙把这个解析到……」「记得审批记录下」
  • 判断问题：主域名是否已购买并备案、只是在其下加子域名或改记录？是→本流程；需要新买域名或备案→X-SEC-20
  • 不归本流程管：新购域名、ICP/公安备案、主体迁移 → 请走 X-SEC-20；证书/域名到期续期 → 请走 X-SEC-21；需要新服务器 → 请走 X-SEC-16；客户端代码签名证书 → 请走 X-SEC-23；解析记录清理 → 请走 X-SEC-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 提单、给出目标地址和端口、上线后自测 R 研发（当前：按需）
DNS/证书管理员 校验、配置解析/EdgeOne/证书、登记台账 R DNS/证书管理员（当前：宋祺睿·推断待确认）
端口审批人 命名规范、公网端口放行范围、权限边界 A CTO（当前：丁震宇·推断待确认）
IT 运维 备案状态确认、DNS 权限、ACME 自动化、备岗 C IT 运维（当前：杨明学·推断待确认）
服务负责人 知悉域名归属与证书方式 I 服务负责人（当前：按台账）

3. 办之前请准备

  • 完整域名（只用小写字母、数字、横杠，不用下划线）及所属主域名
  • 记录类型与目标（A/CNAME + IP/地址）；是否走 EdgeOne/CDN（SSE 长连接服务不上 CDN）
  • 端口与访问来源；证书方式（服务器 Caddy 自动签发或云证书）
  • 用途、环境（测试/正式）、负责人、预计下线时间
  • 内网 IP 访问且接 OIDC 登录的，提前给出 redirect URI

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“域名/端口变更单” 申请人 上线前 1 个工作日 飞书审批 变更单 🔧飞书固化
2 校验主域名已备案、命名合规、与现有记录不冲突；按主域名用途分配，避免单一主域名过载 DNS/证书管理员 提交后 2 个工作小时内 域名台账 校验结果 🤖+👤
3 非 80/443 的公网端口放行需审批 端口审批人 2 个工作小时内 飞书审批 批准范围 👤人工判断
4 配置解析/EdgeOne/安全组/CORS（脚本调云 API 或 IaC） DNS/证书管理员 批准后 2 个工作小时内 IaC/云 API 生效记录 🤖自动化
5 证书优先 Caddy/ACME 自动签发续期；云证书登记到期日 DNS/证书管理员/申请人 与步骤 4 同步 Caddy/云证书 有效证书 🤖自动化
6 验证 HTTPS、端口、跨域 申请人 生效后 1 个工作小时内 浏览器/curl 验证结果 👤人工判断
7 写入域名台账，在变更单回复完成 DNS/证书管理员 当天 多维表格 台账记录 🤖自动化

5. 交付物与模板

  • 交付物：生效的解析/端口/证书、变更单、域名台账记录
  • 建议模板/表单：变更单——域名、主域名、记录类型、目标、端口、访问来源、是否 CDN、证书方式、用途、环境、负责人、下线时间
  • 域名台账字段：域名、解析目标、所属服务、负责人、证书方式与到期日、备案主体与备案号、变更单号、状态
  • 命名规范：<服务>.<环境>.<主域名>，禁止下划线，测试与正式分开

6. 异常与升级

  • 主域名未备案 → 改用已备案主域名或先走 X-SEC-20 → 演示前 1 天仍未解决，临时用 IP 访问并报 CTO
  • 证书签不下来（443 未开/未备案/DNS 未生效）→ DNS/证书管理员 2 小时内协助排查 → 升级 IT 运维
  • 管理员不在 → IT 运维备岗 → 仍无法处理升级 CTO
  • 测试域名切正式引发下游故障 → 回滚解析 → 当天通知研发负责人
  • 误改或误删解析导致服务不可用 → 按台账恢复 → 当天复盘

7. 衡量指标

  • 开通时效：提单到生效的工作小时数，目标 ≤ 4 小时
  • 台账覆盖率：台账内记录数 / DNS 实际记录数，目标 100%
  • 无单变更次数：目标 0
  • 返工次数：因命名、缺信息、未备案导致的重做次数，按月统计逐月下降

8. 低效诊断

  • 现象：需求要素缺失（无目标 IP、无用途），执行人追问后才能配置｜依据：「Leap产研测」2026-05
  • 现象：执行依赖少数有控制台权限的人，出差、开会时开发只能等｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：是否备案、443 是否开放多次排查，证书申请卡住｜依据：「LeapCore（archived）」2026-04
  • 现象：命名不规范（含下划线）导致改名返工｜依据：「LeapAll（Deprecated）」2026-03
  • 现象：有权限者自行解析后再补审批记录，变更没有统一留痕｜依据：「跃迁AI总动员」2026-08

9. 分支变体

  • 内网服务 vs 公网服务：公网服务必须 HTTPS + 认证
  • 遥测、演示、更新平台域名：使用约定主域名与固定前缀
  • COS/OSS 跨域与桶权限：权限边界由端口审批人确认
  • EdgeOne/CDN：仅用于前端静态资源，SSE/长连接服务直连
  • 子公司、子品牌域名：随主体备案走 X-SEC-20

10. 待确认问题

  • 主责是否为 DNS/证书管理员（当前人选见负责人栏）？IT 运维是否同时持有 DNS 权限作为备岗？
  • 变更单用“非实体资产领用”审批，还是单独做域名/端口表单？
  • 各主域名的用途划分（内部工具、演示、产品）是否成文？
  • 公网端口放行审批人是否为 CTO？
  • 是否全面推广 ACME 自动签发？
X-SEC-20域名选购与 ICP 备案待新建96

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：新产品、官网或对外页面（含宣传物料上的二维码链接）需要正式对外域名时启动，包括选购、按主体备案、解析与 HTTPS、旧域名迁移/301，直至可以对外使用。
  • 负责人：主责——域名与备案管理员（当前：丁震宇·推断待确认）；协同——Leap 研发负责人（当前：王皓南·推断待确认）、官网前端（当前：葛家和·推断待确认）、运维/发版（当前：宋祺睿·推断待确认）、法务负责人（当前：李瑶·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 登记域名需求 → ② 查域名台账 → ③ 查候选可注册性、价格与可备案性 → ④ 确认主体并购买 → ⑤ ICP 备案 → ⑥ 解析、HTTPS、301 → ⑦ 上线核验（含二维码） → ⑧ 登记台账并设到期提醒
  • 交付结果：已备案、可访问并启用 HTTPS 的对外域名；旧域名 301 跳转；域名台账（持有主体、用途、备案号、到期日、负责人）。
  • 状态依据：没有域名资产台账和备案流程。2026-04 查候选域名时多轮人工和机器人查询，结论不一致；2026-05 产品域名备案未下，只能临时用子域；2026-08 官网出现多个域名并存，用哪个、谁做保护性注册都不清楚。

1. 场景判定

  • 触发条件：新产品或品牌需要主域名；官网或落地页要换域名；宣传物料要印二维码链接；需要做保护性注册（中文域名、相近拼写）；域名需要换备案主体。
  • 典型说法：「.cn 和 .com 都没了」「来点能备案的推荐」「以后用哪个，还是原来那个吗」「原来有三个域名嘛」「那不赶紧注册一个」
  • 判断问题：这个域名会不会对外长期使用，或者印在物料上？会就走本流程。只是内部服务、测试环境的子域名 → 不走。
  • 不归本流程管：内部服务或演示环境的子域名解析、证书、端口 → 请走 X-SEC-19；研发测试用域名与云资源 → 请走 RND-23；证书和域名到期续期 → 请走 X-SEC-21；云厂商备案核查通知、备案信息变更 → 请走 LEG-23；域名闲置盘点回收 → 请走 X-SEC-22；产品名称本身 → 请走 BRD-01。

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
域名与备案管理员 维护台账、查询、确认主体、购买、提交备案、设提醒 R/A 域名与备案管理员（当前：丁震宇·推断待确认）
需求方 提出用途、候选名、上线时间；确认对外使用哪个域名 C Leap 研发负责人（当前：王皓南·推断待确认）
官网/页面技术 配置 301、sitemap、站点改址 R 官网前端（当前：葛家和·推断待确认）
解析与部署 DNS 解析、HTTPS 证书、CDN/托管配置 R 运维/发版（当前：宋祺睿·推断待确认）
法务 商标冲突判断，备案所需主体材料与授权书 C 法务负责人（当前：李瑶·推断待确认）
市场/品牌 物料印二维码前确认链接已可用 I 品牌负责人（当前：何思雨·推断待确认）

3. 办之前请准备

  • 用途：产品主站、落地页、帮助中心、二维码跳转、保护性注册
  • 候选域名 3～5 个，并注明首选
  • 持有主体（模态/鼎慧/苏州等），以及该主体是否已有云账号和备案资质
  • 是否需要出海（海外后缀不做 ICP 备案，但涉及海外付款）
  • 最晚上线日期；涉及印刷的，写明物料下印日期
  • 先查域名台账，确认公司没有可用的现成域名

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 登记域名需求（用途、候选、主体、上线日） 需求方 上线日前至少 20 个工作日 飞书表单 域名需求记录 🔧飞书固化
2 查域名台账，有现成可用的直接分配，跳到步骤 6 域名与备案管理员 收单后 1 个工作日内 多维表格「域名台账」 分配或继续查询的结论 🔧飞书固化
3 批量查询候选的可注册性、价格、能否在国内备案；结果由人复核一次，不直接采信单次机器人结论 域名与备案管理员 收单后 2 个工作日内 云厂商域名查询 + 脚本/机器人 候选对比表 🤖自动化 + 👤人工判断
4 确认持有主体，和需求方定首选，一并评估保护性注册（相近拼写、中文域名） 域名与备案管理员 + 需求方 对比表出具后 1 个工作日内 飞书审批 购买决定 👤人工判断
5 在对应主体的云账号下购买，并提交 ICP 备案（按 15 个工作日预留） 域名与备案管理员 决定后 1 个工作日内提交 腾讯云/阿里云备案系统 备案申请号 🔧飞书固化
6 备案通过后配置 DNS 解析、HTTPS 证书、CDN/托管；旧域名设 301 跳转到新域名 运维/发版 + 官网前端 备案通过后 2 个工作日内 云解析、EdgeOne/COS 可访问的 HTTPS 站点 🔧飞书固化
7 上线核验：多地访问、微信内打开、二维码扫码、301 生效、页脚备案号正确 需求方 配置完成后 1 个工作日内 浏览器、微信 核验截图 👤人工判断
8 登记台账（备案号、到期日、负责人），设到期前 30 天提醒；对外域名口径同步到品牌命名表 域名与备案管理员 核验通过当天 多维表格 + 提醒机器人 台账记录 🔧+🤖

5. 交付物与模板

  • 交付物：可用的对外域名；备案号；301 跳转配置；更新后的域名台账；对外域名口径。
  • 建议模板/表单：「域名台账」字段——域名、用途、持有主体、注册商/云账号、注册日、到期日、自动续费（是/否）、备案状态、备案号、解析指向、HTTPS 证书到期日、负责人、对外主域名（是/否）、备注。

6. 异常与升级

  • 备案在物料下印前来不及通过 → 改用已备案主体下的子域名作临时链接，二维码指向可改目标的跳转地址 → 域名与备案管理员当天通知需求方和品牌负责人
  • 首选域名已被注册 → 回到步骤 3 换候选；涉及品牌被抢注的 → 法务评估是否维权（3 个工作日内）
  • 主体缺少备案资质或材料 → 转 LEG-10 出具材料 → 升级综合部负责人（2 个工作日内）
  • 备案被驳回 → 按驳回原因 2 个工作日内补正重提；连续驳回 2 次升级 CTO
  • 已备案站点被云厂商核查或下架 → 转 LEG-23 处理，同时按 BRD-06 启动官网故障响应（当天）

7. 衡量指标

  • 域名就绪周期：从需求登记到可对外访问的工作日数，目标 ≤ 20 个工作日
  • 台账覆盖率：台账中登记的对外域名 / 实际持有的对外域名，目标 100%
  • 物料链接失效数：印刷或投放后发现二维码或链接不可用的次数，目标 0
  • 意外到期数：未续期导致失效的域名或证书数，目标 0

8. 低效诊断

  • 现象：选域名靠人工和机器人反复查询，同一问题给出不同结论，多轮后才定下｜依据：「鼎慧产研决策部」2026-04
  • 现象：公司已有哪些域名说不清，需要临时回忆旧域名｜依据：「鼎慧产研决策部」2026-04
  • 现象：新产品主域名备案未下来，只能临时用子域名对外，后续还要再切换｜依据：「Leap产研测」2026-05
  • 现象：官网多个域名并存，不清楚对外用哪个；备案、保护性注册由谁负责也不清楚｜依据：「随便瞎聊啦～」2026-08

9. 分支变体

  • 国内备案类（.cn/.com/.cc 等）：完整执行步骤 1～8。
  • 出海类（.io/.ai 等）：不做 ICP 备案，但购买与付款走 FIN-04；持有主体按 LEG-26 评估。
  • 官网域名迁移：除步骤 6 的 301 外，要提交 sitemap 并在搜索引擎站长平台改址（联动 BRD-05）。
  • 保护性域名、中文域名：只买不解析或统一 301 到主域名，在台账中标「保护性」。
  • 跨主体：域名、备案主体、网站内容主体须一致；需换主体时按迁移处理，先备案迁入再注销旧备案。

10. 待确认问题

  • 域名与备案管理员是否从 CTO 移交给运维岗？由谁接手？
  • 本流程与 X-SEC-20（域名购买与备案）、LEG-23（备案信息维护）是否合并，以哪一个为主？
  • 各主体分别使用哪个云账号持有域名？现有域名是否需要一次性盘点入台账？
  • 备案按 15 个工作日预留是否符合实际经验？
  • 对外主域名（官网、各产品）目前的定稿口径是什么？
X-SEC-21证书与域名到期监控续期待新建48

状态：待新建｜证据：有证据（卡片 4 张 / 会话 3 个）｜优先级：频2 × 耗2 × 跨3 × 险4

  • 适用场景：域名、HTTPS 证书或授权证书即将或已经到期，或云厂商发来证书到期、数据库安全升级通知时
  • 负责人：主责——证书管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、云账号持有人（当前：丁震宇·推断待确认）、服务负责人（当前：按台账）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 上线即登记到期台账 → ② 优先自动续签 → ③ 每日扫描剩余天数 → ④ 到期前 30/7 天提醒 → ⑤ 续期或下线 → ⑥ 部署验证 → ⑦ 更新台账；云厂商通知 → 指派处理
  • 交付结果：持续有效的证书与域名、更新后的到期台账、续期记录
  • 状态依据：无台账、无提醒；03～09 月官网、Gitea、产品域名证书都是过期后由使用人发现，官网证书过期约一个月未处理，“证书怎么管理的”“这个域名是谁的”需临时问

1. 场景判定

  • 触发条件：云厂商到期短信/邮件、监控告警；用户反馈“证书过期”；云厂商安全升级或维护通知
  • 典型说法：「xx 证书到期了」「你没配置 renew 吗」「证书要到期了」「gitea 证书到期了，影响推代码了」
  • 判断问题：是到期/续期类问题吗？若已导致服务不可用，先按 X-SEC-29 应急恢复，再回到本流程补台账
  • 不归本流程管：新申请解析与证书 → 请走 X-SEC-19；证书过期引发 502 等应急 → 请走 X-SEC-29；代码签名证书 → 请走 X-SEC-23；新域名与备案 → 请走 X-SEC-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
证书管理员 维护台账、自动续签方案、执行续期与验证 R 证书管理员（当前：宋祺睿·推断待确认）
研发负责人 对无事故负责，裁决无主证书去留 A 研发负责人（当前：丁震宇·部门报送人）
IT 运维 域名续费、接收并分派云厂商通知 R IT 运维（当前：杨明学·推断待确认）
服务负责人 确认服务仍在用、配合更换证书 C 服务负责人（当前：按台账）
财务 付费证书与域名续费付款 C 财务（当前：待指定）

3. 办之前请准备

  • 域名/证书清单（所属服务、负责人、签发方式、部署位置、到期日）
  • 云账号到期通知接收人改为公共邮箱或群机器人
  • 付费续期预算与付款流程（FIN-01）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 新证书/域名上线时登记台账，优先 Caddy/ACME 自动续签 证书管理员 上线当天 多维表格 台账记录 🔧飞书固化
2 每日扫描全部对外域名的证书剩余天数并回写台账 机器人 每日 脚本 剩余天数 🤖自动化
3 到期前 30 天提醒服务负责人与证书管理员；7 天未处理再提醒并 @ 研发负责人 机器人 到期前 30/7 天 飞书机器人 提醒卡片 🤖自动化
4 确认服务是否仍在用；不用则下线并按 X-SEC-22 回收 服务负责人 提醒后 3 个工作日内 台账 续/停结论 👤人工判断
5 续期：自动续签失败查原因；免费证书手动续签；付费证书和域名提交付款 证书管理员/IT 运维 到期前 7 天完成 云控制台 新证书/续费单 🔧+👤
6 部署新证书并验证浏览器、客户端、git 推送 证书管理员 续期当天 服务器/curl 验证结果 🤖自动化
7 更新台账到期日与续期记录 证书管理员 当天 多维表格 台账更新 🤖自动化
8 云厂商通知（证书、数据库安全升级）转飞书并指派，约定维护窗口 IT 运维 收到后 1 个工作日内 飞书机器人 指派任务 🔧+👤

5. 交付物与模板

  • 交付物：到期台账、续期记录、维护窗口通知
  • 建议模板/表单：台账字段——域名/证书、类型（DV/通配/授权证书/域名注册）、签发方式（ACME/云证书/付费）、部署位置、所属服务、负责人、到期日、是否自动续费、上次续期日
  • 提醒卡片字段：域名、剩余天数、负责人、签发方式、处理入口

6. 异常与升级

  • 证书已过期、服务不可用 → 证书管理员 1 小时内恢复（按 X-SEC-29）→ 升级研发负责人
  • 自动续签失败（与生产隔离方案不兼容等）→ 改手动续签并记录 → 1 周内给出替代方案
  • 证书归属不明 → 台账标“无主”，3 个工作日无人认领由研发负责人决定续或停
  • 对外站点因改版等原因暂不续期 → 不允许，须先续期 → 报 CTO
  • 域名未开自动续费即将到期 → IT 运维提交付款 → 3 天未付款升级财务负责人

7. 衡量指标

  • 证书/域名过期事故次数：目标 0
  • 台账覆盖率：台账内证书数 / 实际对外域名数，目标 100%
  • 自动续签比例：目标 ≥ 90%
  • 提前续期率：到期前 7 天完成的续期数 / 总续期数，目标 100%

8. 低效诊断

  • 现象：到期靠使用人发现，多个证书“轮流过期”｜依据：「Leap产研测」2026-08
  • 现象：证书和服务器归属无记录，负责人记不清管理方式｜依据：「LeapPay」2026-07、「Leap产研测」2026-09
  • 现象：活动期间临时配置的证书没配自动续签｜依据：「Leap产研测」2026-08
  • 现象：免费证书是否自动续签说法不一｜依据：「Leap产研测」2026-08
  • 现象：云厂商到期通知只发到个人账号，靠手动转发｜依据：「LeapPay」2026-07

9. 分支变体

  • 证书对象：官网、内部服务（如 Gitea）、支付服务、活动临时证书
  • 签发方式：服务器 Caddy 自动签发 / 腾讯云证书 / 付费证书
  • 云数据库安全升级通知：约定夜间窗口执行，提前通知受影响服务

10. 待确认问题

  • 证书管理员是否按负责人栏所列人选确定？域名续费是否归 IT 运维？
  • 云账号到期通知改为公共邮箱是否可行？
  • 30/7 天两档提醒是否合适？
  • 是否统一采用 ACME 自动化，替代当前方案？
X-SEC-22云资源/域名资产盘点与闲置回收（成本治理）待新建144

状态：待新建｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：云服务器、数据库、COS、DNS 记录、演示机数量增长，或自动续费前、账单异常、旧云账号弃用、折扣更新时的定期盘点与闲置回收
  • 负责人：主责——云资源管理员（当前：宋祺睿·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、销毁审批人/CTO（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 每月导出云资源与账单 → ② 与台账比对标出无主/闲置/高价 → ③ 负责人限期认领 → ④ 未认领公示 7 天 → ⑤ 关机保留 7 天 → ⑥ 审批后销毁 → ⑦ 更新台账并出成本月报
  • 交付结果：月度盘点表、释放清单与审批记录、更新后的资源台账、云成本月报
  • 状态依据：07 月口头定过“限期上报—公示一周—关机保留 7 天”的方案，但 03～10 月仍多次出现不明机器/数据库靠群里问归属、误释放在用服务后再恢复、闲置机长期计费、DNS 记录积累 60 多条无人敢清

1. 场景判定

  • 触发条件：每月例行盘点；自动续费前 7 天；月度账单环比上升超 20%；发现不明 IP 或数据库；云账号弃用；云厂商折扣更新
  • 典型说法：「给 DDL，下周末前上报完」「这个数据库是谁用的」「没用的话就释放一下」「先关两天看看」「看看你那里的机器，要自动续费了」
  • 判断问题：要做的是盘点、清理或降本吗？是则走本流程
  • 不归本流程管：新资源申请 → 请走 X-SEC-16；内网机器回收 → 请走 X-SEC-17；证书续期 → 请走 X-SEC-21；实体资产盘点 → 请走 ADM-33；云账单付款 → 请走 FIN-01；高权限账号收回后的重新分配 → 请走 X-SEC-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
云资源管理员 导出比对、发认领清单、执行关机与销毁 R 云资源管理员（当前：宋祺睿·推断待确认）
销毁审批人 业务确认、销毁人工二次确认、折扣与型号决策 A CTO（当前：丁震宇·推断待确认）
IT 运维 维护资源台账与折扣表、发通知、出成本月报 R IT 运维（当前：杨明学·推断待确认）
资源负责人 限期认领、迁移数据、确认可释放 R 资源负责人（当前：按台账）
财务 账单核对、接收成本月报 C 财务（当前：待指定）
演示机使用方 确认演示机去留与迁移 C 销售/商务（当前：按台账）

3. 办之前请准备

  • 全部云账号清单（多云、多主体）及只读 API 权限
  • 资源台账（X-SEC-16 产出）与上月盘点表
  • 当月账单与折扣表
  • 标签规范：负责人/项目/到期

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 导出全部云资源（服务器、数据库、COS、负载均衡、安全组、EIP、DNS 记录）与账单 云资源管理员 每月第 1 个工作日 云 API 脚本 资源清单 🤖自动化
2 与台账比对，标出无标签/无负责人、低负载（CPU 低于 5% 持续 14 天）、非折扣高价型号、7 天内自动续费 脚本 同日 脚本+多维表格 待处理清单 🤖自动化
3 群内发认领清单并 @ 疑似负责人，5 个工作日内回复“在用/可释放” 云资源管理员 每月第 2 个工作日 飞书任务 认领结果 🔧飞书固化
4 未认领资源公示 7 天 云资源管理员 认领截止后 飞书群公告 公示记录 🔧飞书固化
5 按销毁检查清单核对数据迁移、是否承载认证/支付等基础服务、DNS 依赖、是否 IaC 管理 资源负责人/云资源管理员 公示期内 检查清单 检查结果 👤人工判断
6 关机保留 7 天观察 云资源管理员 公示期满 云控制台 停机记录 🔧飞书固化
7 销毁走人工二次确认；IaC 创建的用 IaC 释放 销毁审批人/云资源管理员 停机期满 飞书审批/IaC 销毁记录 👤人工判断
8 高价型号迁到折扣型号，调整计费方式 云资源管理员 与盘点同步 云控制台+折扣表 迁移记录 🤖+👤
9 更新台账，输出成本月报（总额、环比、释放节省、费用前十资源）发研发负责人与财务 IT 运维 每月第 10 个工作日 多维表格 成本月报 🤖自动化

5. 交付物与模板

  • 交付物：月度盘点表、销毁审批记录、更新后的台账、成本月报
  • 建议模板/表单：盘点表字段——资源 ID、类型、云账号、主体、负责人、用途、负载、月费用、到期/续费日、处理建议（保留/降配/迁移/释放）、认领结果
  • 销毁检查清单：数据已迁移或备份、无认证/支付等基础服务、无 DNS 指向、无客户演示依赖、已关机满 7 天、审批人确认
  • 成本月报字段：总费用、环比、按项目/主体分摊、释放节省、费用前十资源

6. 异常与升级

  • 误释放在用服务 → 立即从关机状态或快照恢复 → 当天复盘并报 CTO
  • 演示机仍有流量但无人认领 → 通知商务给 3 天迁移期 → 到期执行
  • DNS 记录不敢清 → 先补登记再逐条确认，清理前导出备份 → 不确定的标“待确认”保留
  • 欠费下机 → 财务当天付款 → 升级财务负责人
  • 高权限账号过多 → 收回后按 X-SEC-15 重新分配 → CTO 确认

7. 衡量指标

  • 月末无主资源数：目标 0
  • 闲置资源费用占比：闲置资源月费 / 云总月费，目标 ≤ 5%
  • 误释放次数：目标 0
  • 盘点按期完成率：目标 100%
  • 云成本环比：按月跟踪，异常上升超 20% 须给出说明

8. 低效诊断

  • 现象：资源创建不登记、不打标签，归属只能逐台在群里问｜依据：「鸽子群模态分群」2026-08、「技术部」2026-03、「Leap产研决策部」2026-09
  • 现象：清理靠个人巡检，自动续费前才发现大量闲置｜依据：「Leap产研决策部」2026-09
  • 现象：释放前未检查依赖，误释放承载认证服务的机器后再恢复｜依据：「鸽子群模态分群」2026-08、「忠橙星行星引擎」2026-09
  • 现象：DNS 记录无用途标注，积累后无人敢删｜依据：「鸽子群模态分群」2026-05
  • 现象：新机器开成高价型号后再迁移；高权限账号过多｜依据：「忠橙星行星引擎」2026-06、「忠橙星行星引擎」2026-07
  • 现象：在用环境被错误标注“待定废弃”｜依据：「鼎慧产研决策部」2026-07

9. 分支变体

  • 资源类别：演示机、交付机、测试环境、证书中心分开处理，演示机先通知商务
  • 旧云账号弃用：使用方自行迁移，无主服务列清单公示后停机
  • DNS 记录：先补用途与负责人，再分批清理
  • GPU 云主机：按小时计费，用完当天释放
  • 临时过渡服务器：到期前关闭并申请退款
  • 多云：腾讯云为主，华为云代金券、ucloud 物理机纳入同一台账

10. 待确认问题

  • 主责是云资源管理员还是 IT 运维？资源台账由谁维护？
  • 每月一次盘点是否可行？
  • “公示 7 天 + 关机 7 天”是否过长，演示机是否单独规则？
  • 成本月报接收人与财务对接人是谁？
  • 低负载阈值（CPU 低于 5% 持续 14 天）是否合适？
X-SEC-23代码签名证书申请、保管与签名使用待优化240

状态：待优化｜证据：有证据（卡片 7 张 / 会话 3 个）｜优先级：频4 × 耗3 × 跨4 × 险5

  • 适用场景：Windows/macOS 安装包需要代码签名，涉及证书（Windows EV、Apple 开发者）采购与 CA 复审、UKey/签名机保管、CI 签名审批、签名工具使用授权与保管人交接
  • 负责人：主责——签名资产保管人/CI 负责人（当前：吴世豪·推断待确认）；协同——IT 运维（当前：杨明学·推断待确认）、签名审批人/CTO（当前：丁震宇·推断待确认）、客户端打包负责人（当前：李铭熙·推断待确认）、主体复审联系人（当前：邴龙志·推断待确认）、财务（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 证书采购申请 → ② 比价付款 → ③ CA 复审/Apple 核验 → ④ UKey 入库登记、签名机部署 → ⑤ CI 打包后机器人发签名审批 → ⑥ 审批确认后按范围签名 → ⑦ 使用日志、交接与到期续期
  • 交付结果：有效的代码签名证书、资产台账登记（保管人、位置、到期日）、签名审批记录与签名后的安装包
  • 状态依据：06 月已上线“模态助手”签名审批卡片，但审批权限不透明、出现误拒绝、签名范围未定义；证书采购因复审电话漏接反复重审；UKey 保管与使用权移交未成文、未通知，发版当天才发现依赖个人

1. 场景判定

  • 触发条件：首次或到期需购买/续期代码签名证书；CI 产物需要签名；有人要使用 UKey、签名机或签名工具链；保管人变更
  • 典型说法：「你的安装包证书进展怎么样了」「得先等审批」「我没有签名审批权限」「win 需要物理密钥，绝对不能丢」「提具体负责人员，走审批，确定后就交付」
  • 判断问题：是否涉及代码签名证书或其载体（UKey、签名机、Apple 账号）？是则走本流程
  • 不归本流程管：打包与安装包分发 → 请走 RND-52；CI 流水线 → 请走 RND-37；HTTPS 证书 → 请走 X-SEC-19、X-SEC-21；对外账号验证码 → 请走 X-SEC-12；Gitea token 权限 → 请走 X-SEC-02；采购付款 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
签名资产保管人 保管 UKey 与签名机、维护签名环境与使用日志 R CI 负责人（当前：吴世豪·推断待确认）
签名审批人 审批每次签名、审批工具使用授权与保管人变更 A CTO（当前：丁震宇·推断待确认）
IT 运维 证书比价采购、续期、Apple 账号管理、资产台账 R IT 运维（当前：杨明学·推断待确认）
打包负责人 发起签名、核对产物与 hash R 客户端打包负责人（当前：李铭熙·推断待确认）
主体复审联系人 按约定时间接听 CA 复审电话 C 主体年报登记联系人（当前：邴龙志·推断待确认）
财务 付款与开票 C 财务（当前：待指定）
研发团队 知悉签名规则与审批人名单 I 研发（当前：全体·推断待确认）

3. 办之前请准备

  • 采购：签名主体（与工商登记一致的英文名）、证书类型、渠道比价、开票抬头、复审联系人及可接听时间
  • 签名：CI Run 编号、文件清单与首文件 hash、版本号
  • 工具使用授权：具体负责人员、用途、期限
  • 保管人变更：交接清单（UKey、签名机、账号、审批人名单）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交证书采购申请（主体、类型、渠道、费用） IT 运维 到期前 60 天或需求确定当天 飞书审批 采购单 🔧飞书固化
2 审批并付款 签名审批人/财务 3 个工作日内 飞书审批 付款记录 🔧飞书固化
3 用飞书日程约定 CA 复审时间，联系人用公司公共号码，IT 运维陪同应答 IT 运维+复审联系人 按 CA 通知当天 飞书日程 复审通过 👤人工判断
4 UKey 到货登记资产台账（保管人、位置、到期日），放 IT 办公室签名机 IT 运维 到货当天 多维表格 台账记录 🔧飞书固化
5 CI 打包完成，机器人推送签名审批卡片（Run、文件数、首文件 hash） 机器人 即时 模态助手+Gitea 审批卡片 🤖+👤
6 核对来源与产物后确认；非审批人或非本次发起人不点“拒绝” 签名审批人 工作时间 30 分钟内 审批卡片 确认/拒绝 👤人工判断
7 签名机按签名范围清单签名（只签自研可执行文件，已签运行时缓存复用） 签名机 自动 signtool 已签名安装包 🤖自动化
8 记录签名日志（Run、审批人、时间、文件数） 机器人 自动 多维表格 使用日志 🤖自动化
9 保管人或使用权变更：审批、按清单交接、群内通知 原保管人+新保管人 决定后 1 个工作日内 飞书审批 交接记录 🔧飞书固化

5. 交付物与模板

  • 交付物：证书、资产台账、签名审批与使用日志、交接记录
  • 建议模板/表单：证书资产台账——证书类型、主体、颁发机构、到期日、载体（UKey/账号）、保管人、存放位置、备岗、费用
  • 签名审批卡片字段：Run、仓库、分支、版本、文件数、首文件 hash、发起人
  • 审批人白名单与签名范围清单（自研可执行文件列表、排除的第三方运行时）
  • 保管交接清单：UKey、签名机访问、Apple 账号、机器人权限、审批人名单

6. 异常与升级

  • 复审电话漏接导致重审 → IT 运维当天预约下次时间 → 升级 CTO 协调联系人
  • 签名审批 30 分钟无人处理 → 机器人提醒备审 → 发版日直接升级 CTO
  • 误拒绝 → 重新触发签名审批，复用已构建产物，不重跑构建
  • 签名机或 UKey 不可用 → 保管人 2 小时内恢复 → 不能恢复则发版延期并通知产品
  • UKey 丢失或疑似滥用 → 立即申请吊销证书 → 当天报 CTO
  • Apple 开发者账号被封 → IT 运维重新申请并通知打包负责人

7. 衡量指标

  • 签名审批时长：卡片推送到确认的中位数，目标 ≤ 15 分钟
  • 签名返工次数：因误拒绝、重签崩溃导致重跑的次数，按月统计
  • 未签名版本外发次数：目标 0
  • 证书过期次数：目标 0；证书采购周期 ≤ 10 个工作日

8. 低效诊断

  • 现象：证书采购临近发版才启动，复审联系人与登记号码不匹配，电话漏接后重审｜依据：「忠橙星行星引擎」2026-05、「Leap产研测」2026-05
  • 现象：审批权限不透明，误拒绝导致重新打包｜依据：「Leap产研测」2026-06
  • 现象：签名范围未定义，对第三方运行时重签导致崩溃｜依据：「Leap产研测」2026-06
  • 现象：保管与使用权移交没有书面交接和通知，发版当天才发现依赖个人｜依据：「Leap产研测」2026-09、「忠橙星行星引擎」2026-09
  • 现象：UKey 使用无白名单、无审计｜依据：「Leap产研测」2026-07
  • 现象：证书买完才讨论保管位置和执行人｜依据：「跃迁AI总动员」2026-05
  • 现象：账号、验证码经群聊流转｜依据：「忠橙星行星引擎」2026-05

9. 分支变体

  • Windows：EV 证书 + UKey，必须实体签名机，走机器人审批
  • macOS：Apple 开发者账号签名与公证，打包时直接签名，不走审批卡片
  • 产线：LeapAll、LeapCore 共用证书，签名范围清单分别维护
  • 主体：武汉模态与苏州模态的购买账号、开票抬头需在采购单写明
  • 托管：签名工具链可交给 CI 机器托管，需审批人书面授权

10. 待确认问题

  • 当前 UKey 保管人是谁，是否已移交 CI 负责人？备岗是谁？
  • 签名审批人白名单有哪些人？是否每次都需 CTO 审批？
  • 签名范围清单由谁维护？
  • CA 复审联系人能否改为公司公共号码？
  • 签名证书是否纳入行政 IT 资产台账（ADM）统一盘点？
X-SEC-24办公网络接入认证、网络分区与 WiFi 密码查询待优化160

状态：待优化｜证据：有证据（卡片 7 张 / 会话 5 个）｜优先级：频5 × 耗2 × 跨4 × 险4

  • 适用场景：新人入职、访客到访、新设备（办公电脑、服务器、打印机等 IoT）需要接入公司网络，或员工需要获取 WiFi 凭据、确认该连哪个网络时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、人事负责人（当前：待指定，负责入职指引）、行政（当前：待指定，负责访客接待）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 判定接入类型与网络分区 → ② 提交入网登记 → ③ IT 审核并绑定认证 → ④ 按身份下发凭据 → ⑤ 接入验证 → ⑥ 设备台账登记 → ⑦ 定期轮换与离职回收
  • 交付结果：已完成认证绑定并可正常上网的设备；更新后的入网设备台账（MAC/IP/责任人/分区）；成文的《办公网络使用说明》（含分区用途与获取方式）
  • 状态依据：已有飞书“密码管理 Bot”与 MTYQ / MTYQ-IoT / MTYQ-WORK 分区，查询高频（单月约 30 次），但关键词大小写不命中需人工转发，凭据在群内明文回显、多个机器人各存一份；有线 MAC 白名单与 MAC+IP 双重认证仅在群内公告，未成文

1. 场景判定

  • 触发条件：新员工首日联网；访客/面试者需要上网；新增办公电脑、服务器、打印机、测试机需接入；有线网口需开通；员工不确定该连哪个 SSID；WiFi 凭据轮换后重新获取
  • 典型说法：「@密码管理Bot wifi密码」「需要用网线的把设备 MAC、设备名、用途整理一下」「别用 MTYQ，那个是访客」「所有内网服务设备都要做 MAC+IP 双重认证后才能入网」
  • 判断问题：我是要“第一次接入/换设备接入”，还是“已经接入但网不好”？前者走本流程，后者走故障报修
  • 不归本流程管：已接入但断网/变慢 → 请走 X-SEC-27；在公司外访问内网、IP 白名单 → 请走 X-SEC-25；海外出口与代理节点 → 请走 X-SEC-26；机器人上线安全检查与凭据外发风险 → 请走 X-SEC-37；群内凭据分发规范 → 请走 X-SEC-10；网络扩容与新楼层建设 → 请走 X-SEC-28

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 制定分区与认证规则、审核入网、绑定 MAC/IP/飞连、维护 Bot 与凭据轮换 R/A IT 运维/网管（当前：杨明学·推断待确认）
运维/交付工程师 现场接线、批量绑定、新设备入网协助 R 运维/交付部署工程师（当前：游家豪·推断待确认）
人事 入职清单加入“网络接入”一步，离职通知 IT 回收 C 人事负责人（当前：待指定）
行政 访客登记与访客网获取方式告知 C 行政（当前：待指定）
申请人 提供设备 MAC、设备名、用途、责任人；按说明自助接入 R 全员
CTO 分区与认证策略拍板、例外审批 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 设备类型（办公电脑/服务器/打印机等 IoT/访客设备）与用途
  • 有线接入：设备 MAC 地址、设备名、使用人、所在工位/机柜位置；共享机器需注明多人共用
  • 员工设备：飞连客户端已安装并登录（work/rd 网络强制）
  • 服务设备：计划使用的固定 IP 或申请分配 IP
  • 访客：到访人、陪同人、预计时长

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照《办公网络使用说明》判定分区：员工办公设备→MTYQ-WORK/RD；打印机等→MTYQ-IoT；访客→MTYQ（访客网，限速） 申请人 接入前 飞书知识库 分区选择 🔧飞书固化
2 提交“入网登记”表单（MAC、设备名、用途、责任人、分区） 申请人 需要入网前 1 个工作日 飞书表单/多维表格 入网申请记录 🔧飞书固化
3 审核申请；办公设备做飞连绑定+静态地址绑定，服务设备做 MAC+IP 双重认证，有线口开 MAC 白名单 IT 运维/网管 提交后 1 个工作日内 路由/AC 管理后台、飞连 绑定完成 🤖自动化（台账同步白名单脚本）+👤人工判断
4 按身份下发凭据：员工走认证/私聊一次性可见卡片；访客由行政出示访客码；禁止在群内回显 IT 运维/网管、行政 绑定后即时 密码管理 Bot（私聊模式） 凭据送达 🔧+🤖
5 申请人接入并自测（能否打开飞书、Gitea、内部服务） 申请人 当日 — 接入确认 👤人工判断
6 台账更新（MAC/IP/责任人/分区/入网日期） IT 运维/网管 接入当日 多维表格 设备台账 🔧飞书固化
7 访客网凭据每月轮换并更新 Bot；离职/设备报废时解绑 IT 运维/网管 每月首个工作日；离职当日 多维表格提醒、飞书任务 轮换记录 🔧+🤖

5. 交付物与模板

  • 交付物：《办公网络使用说明》（分区用途、限速口径、获取方式、禁止事项）；入网设备台账；凭据轮换记录
  • 建议模板/表单：入网登记表（申请人、部门、设备类型、设备名、MAC、需要固定 IP 否、分区、用途、责任人、是否多人共用、申请日期、审核人、绑定结果）；Bot 回复规则（大小写/模糊匹配、仅私聊回复、仅限已认证员工、调用日志）

6. 异常与升级

  • 升级条件：网络分区或认证策略调整、规则外的入网例外（如未登记设备进 work/rd 网段长期使用）、Bot 越权查询非网络凭据 → IT 运维/网管升级 CTO 拍板；常规入网审核与凭据轮换由 IT 运维/网管直接决定
  • Bot 无响应或不命中 → 先查飞书知识库《办公网络使用说明》→ 仍无法获取私聊 IT 运维，禁止他人在群内转发凭据（当日）
  • 凭据已在群内明文出现 → IT 运维 2 小时内撤回消息并评估是否轮换，按 X-SEC-11 处理
  • 有人通过 Bot 查询他人电脑开机密码等非网络凭据 → Bot 下线该关键词，IT 运维报 CTO（1 个工作日内）
  • 未登记设备出现在 work/rd 网段 → 先限速/隔离，再找责任人补登记（当日）
  • 新人连错访客网导致面试/会议卡顿 → 现场改连 MTYQ-WORK，入职清单补说明

7. 衡量指标

  • 入网开通时长：提交登记到绑定完成，目标 ≤ 1 个工作日
  • 群内明文凭据次数：每月 0 次
  • Bot 查询命中率：成功返回次数/查询次数，目标 ≥ 95%
  • 访客网凭据轮换准时率：目标 100%（每月）
  • 未登记设备数：每月巡检发现数，目标 0

8. 低效诊断

  • 现象：凭据查询依赖群内 @机器人，关键词大小写/拼写不命中即无回复，改由同事人工转发，同日连续多次｜依据：「技术部」2026-02、「鸽子群模态分群」2026-03、「鸽子群模态分群」2026-04
  • 现象：凭据在群内明文回显，机器人在群内整表复述，多个机器人各存一份，扩散面不可控｜依据：「随便瞎聊啦～」2026-07、「鸽子群模态分群」2026-06
  • 现象：Bot 可查询个人电脑开机密码，权限边界不清｜依据：「鸽子群模态分群」2026-01
  • 现象：分区用途无成文说明，新人和员工连到访客网后抱怨断网卡顿｜依据：「鸽子群模态分群」2026-04
  • 现象：有线入网 MAC 靠群消息收集，无台账，进度被反复追问｜依据：「Leap产研测」2026-10
  • 现象：入网认证规则在网络事故后才补立，仅群内公告，研发网是否默认带代理等需求未沟通｜依据：「忠橙星行星引擎」2026-08、「忠橙星行星引擎」2026-10

9. 分支变体

  • MTYQ-WORK / MTYQ-RD（员工办公与研发）：飞连绑定+静态地址，凭据不对外
  • MTYQ-IoT（打印机等）：MAC 白名单，QoS 限速
  • MTYQ（访客/综合，住宅带宽，与内网分离、低限速）：凭据按月轮换，由行政告知访客
  • 服务设备（内网服务器）：MAC+IP 双重认证，入网前需在台账登记负责人
  • 共享机器：支持单设备多人共用登记，需指定一名责任人

10. 待确认问题

  • 主责是否为 IT 运维/网管岗？访客凭据告知由行政还是前台承担？
  • 员工网是否计划上 802.1x/飞连账号认证，以替代共享 WiFi 密码？时间表？
  • 密码管理 Bot 是否改为仅私聊、仅已认证员工可查？还是下线改用知识库受控文档？
  • 开机密码等个人设备凭据是否允许由任何系统集中存储？
  • 访客网轮换周期“每月”是否可行？入网审核“1 个工作日”是否可行？
X-SEC-25远程办公与内网访问接入（飞连/VPN/IP 白名单）待优化240

状态：待优化｜证据：有证据（卡片 11 张 / 会话 10 个）｜优先级：频4 × 耗3 × 跨5 × 险4

  • 适用场景：员工居家/出差、销售外出演示需要访问内网 LeapCore 或内部服务，研发需要从外网连测试库/测试后台/测试机，或内网多人需要互相访问本地服务联调时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——LeapVPN 负责人（当前：吴世豪·推断待确认）、后端兼运维（当前：宋祺睿·推断待确认，负责 IP 白名单/安全组）、产品总监（当前：杨萌·推断待确认，负责远程访问使用手册与对外通知）、运维/交付部署工程师（当前：游家豪·推断待确认）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交访问申请 → ② 选定接入通道 → ③ 审批 → ④ 开通（席位/激活码/白名单/端口） → ⑤ 用户按手册自检 → ⑥ 登记台账 → ⑦ 到期与离职回收
  • 交付结果：可用的远程访问通道（飞连账号/LeapCore 远程访问激活码/IP 白名单/端口互通）；远程访问台账；《远程访问与外出演示使用手册》（含排查口诀与 FAQ）
  • 状态依据：飞连与 LeapCore 远程访问已上线并做过培训，激活码已改为管理后台自助查看；但企业识别码、入口、排查口诀靠群里问（单月约 15 次重复回答），IP 白名单靠运维手工加且脚本不覆盖边缘层，企业激活码曾外泄需更换，暂无正式跳板机

1. 场景判定

  • 触发条件：员工不在公司网络但需访问内网服务；销售/售前外出演示 LeapCore；IP 变化后测试环境被拦截；需 SSH 到内网测试机；内网两台机器互相访问不通
  • 典型说法：「公司外使用需要用飞连」「又被限制 IP 了」「我不开这个就打不开后台」「公司有正经的 ssh 跳板机/内网 VPN 吗」「激活码不要发给客户」
  • 判断问题：访问对象是公司内网/测试环境吗？访问人是公司员工吗？如果访问人是客户、渠道或外部协作方，不走本流程
  • 不归本流程管：客户/渠道远程接入与 root 账号 → 请走 X-SEC-07；外部协作方访问内网 → 请走 X-SEC-06；生产资源访问 → 请走 X-SEC-18；测试机/GPU 资源申请 → 请走 X-SEC-17；办公网接入 → 请走 X-SEC-24；海外站点访问 → 请走 X-SEC-26；对外腾讯会议账号 → 由销售运营统一安排，不属本流程

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 飞连席位开通、策略下发、通道选型、台账与回收 R/A IT 运维/网管（当前：杨明学·推断待确认）
LeapVPN 负责人 LeapCore 远程访问服务、激活码轮换、连接日志排查 R LeapVPN 负责人（当前：吴世豪·推断待确认）
后端兼运维 测试环境 IP 白名单、安全组与边缘层拦截配置 R 后端兼运维（当前：宋祺睿·推断待确认）
产品总监 使用手册、外出演示准备清单、激活码变更全员通知 R 产品总监（当前：杨萌·推断待确认）
运维/交付工程师 远程协助、现场排查 C 运维/交付部署工程师（当前：游家豪·推断待确认）
部门负责人 审批访问必要性与时长 R（审批） 各部门负责人
销售/售前 外出演示前按清单实测 R 销售/售前（当前：按需）
CTO 跳板机/零信任等通道方案、外网穿透是否收费拍板 A（升级） CTO（当前：丁震宇·推断待确认）
申请人 按手册自检、不外传激活码 R 全员

3. 办之前请准备

  • 访问场景（居家/出差/外出演示/联调）、访问对象（LeapCore、测试库、测试后台、某台测试机）与端口
  • 访问时长（长期/临时到某日）
  • 使用设备（公司电脑/个人设备）与操作系统
  • 申请 IP 白名单时：当前公网出口 IP（不是代理/WG 的 IP），或固定办公出口
  • 外出演示时：演示时间、地点、是否客户现场网络

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“远程访问申请”（场景、对象、时长、设备） 申请人 需要前 1 个工作日；演示前 2 个工作日 飞书审批 申请单 🔧飞书固化
2 选通道：员工外网访问内网→飞连；访问 LeapCore→LeapCore 远程访问（管理后台自助查看激活码）；测试环境→IP 白名单脚本；测试机 SSH→飞连+指定主机；内网联调→端口互通 IT 运维/网管 审批时同步 通道选型表 通道确定 👤人工判断
3 部门负责人审批必要性与时长 部门负责人 提交后 4 个工作小时内 飞书审批 审批结果 🔧飞书固化
4 开通：飞连发账号并下发策略；IP 白名单跑同步脚本写入安全组与边缘层；端口/防火墙规则开通 IT 运维/网管、后端兼运维 审批后 1 个工作日内 飞连后台、云安全组、同步脚本 开通完成 🤖自动化
5 申请人按手册自检：公司内连 MTYQ-WORK；公司外开飞连；本地代理需排除公司内网网段；服务监听 0.0.0.0 并放行防火墙；企业地址按公告切换 申请人 开通当日 使用手册、FAQ 机器人 自检通过 🔧+🤖
6 外出演示前 1 天按“演示准备清单”在公司外网实测一次 销售/售前 演示前 1 个工作日 演示手册 实测记录 👤人工判断
7 台账登记（人、通道、对象、到期日） IT 运维/网管 开通当日 多维表格 台账 🔧飞书固化
8 到期自动提醒回收；离职当日回收飞连席位与白名单；企业激活码泄露或定期轮换后全员通知 IT 运维/网管、LeapVPN 负责人 到期日/离职当日 多维表格提醒、通知群 回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：远程访问台账；《远程访问与外出演示使用手册》（含排查口诀、FAQ、谁负责什么）；激活码变更通知
  • 建议模板/表单：远程访问申请（申请人、部门、场景、访问对象、端口、通道、开始/结束日期、设备、出口 IP、审批人、开通人、开通时间、回收时间）；外出演示准备清单（飞连已登录、企业地址已切换、本地代理已关闭或已排除内网、演示前一天外网实测、备用热点）

6. 异常与升级

  • 升级条件：临时关闭白名单或开临时 WG 通道、外网穿透或公网暴露、跳板机/零信任等通道方案选型 → IT 运维/网管升级 CTO 批准；常规通道开通由部门负责人审批必要性后 IT 运维/网管执行
  • 外出演示时连不上 → 销售先按清单自检 → 10 分钟内仍不通联系 IT 运维/LeapVPN 负责人远程排查 → 影响客户现场时同步产品总监
  • 企业激活码外泄或误发给客户 → LeapVPN 负责人 2 小时内在后台轮换，产品总监当日发全员通知，按 X-SEC-11 复盘
  • IP 白名单脚本不覆盖的入口（边缘层拦截） → 后端兼运维手工加，并在 1 周内补进脚本
  • 申请“临时关闭白名单”或用临时 WG 通道 → 必须 CTO 批准并写明截止时间，到期自动恢复
  • 需要外网穿透或公网暴露 → 提交 CTO 评估成本与安全，属于增值方案时另行报价

7. 衡量指标

  • 远程访问开通时长：审批通过到可用，目标 ≤ 1 个工作日
  • “连不上内网”群内求助次数：每月统计，目标逐月下降 50% 直至 ≤ 3 次
  • IP 白名单手工处理次数：每月，目标 ≤ 2 次
  • 激活码/凭据外泄次数：目标 0
  • 离职当日回收率：目标 100%

8. 低效诊断

  • 现象：企业识别码、客户端入口靠群里猜和问，多种远程方案并存｜依据：「Leap产研测」2026-06
  • 现象：销售外出演示不知道要用飞连，“能否公网访问”被反复回答，使用手册未闭环｜依据：「Leap产研测」2026-06、「【模态】市场销售」2026-07
  • 现象：换网络后 IP 白名单失效，每次靠运维手工加；脚本不覆盖边缘层，单次排查近 2 小时；曾为方便临时关闭白名单｜依据：「鼎慧产研决策部」2026-02、「工程咨询产研」2026-05、「工程咨询产研」2026-06
  • 现象：同一套排查口诀（连哪个网、开飞连、代理过滤网段、手动输入地址）被反复回答约 15 次｜依据：「Leap反馈群」2026-07
  • 现象：企业激活码通过群消息传递后外泄，需更换并再次提醒｜依据：「Leap反馈群」2026-09、「模态跃迁通知群」2026-09
  • 现象：无正式跳板机/内网 VPN，研发只能“凑合用飞连”或本地自建虚拟机绕开｜依据：「跃迁AI总动员」2026-09
  • 现象：内网联调评测当天才发现互相访问不通｜依据：「leapagent赛马」2026-04
  • 现象：飞连故障不知道找谁，演示时连不上影响客户观感｜依据：「【模态】市场销售」2026-07、「【模态】市场销售」2026-08

9. 分支变体

  • 员工飞连：席位有成本，优先给非研发与外出岗位；研发按需开通
  • LeapCore 远程访问（模态空间等办公点同样适用）：激活码在管理后台自助查看，禁止外传
  • 测试数据库/测试后台：腾讯云安全组同步脚本；边缘层拦截需手工；研发可开云子账号自助（走 X-SEC-15）
  • 内网测试机 SSH：暂经飞连访问，跳板机方案待 CTO 定
  • 内网联调互通：检查监听地址、防火墙、网段；需测试机走 X-SEC-17
  • 客户异地访问：标品仅内网，内网穿透属增值，走 X-SEC-07

10. 待确认问题

  • 飞连开通主责是否为 IT 运维/网管？LeapCore 远程访问与飞连的使用边界是否需统一口径？
  • 是否建设正式跳板机或零信任通道以取代 IP 白名单？时间表？
  • 飞连席位分配规则（研发/非研发）是否成文？
  • 测试环境是否可固定办公出口 IP 或专线 IP 段，以减少白名单变更？
  • 企业激活码轮换周期定为多少？由谁发全员通知？
X-SEC-26海外出口线路与代理节点运维待新建240

状态：待新建｜证据：有证据（卡片 7 张 / 会话 6 个）｜优先级：频5 × 耗3 × 跨4 × 险4

  • 适用场景：研发/CI 访问 GitHub、Docker、npm、海外 AI 服务出现断流、SSL/TLS 错误、超时或流量耗尽，或需要新增域名白名单、落地 IP、节点线路、续费扩容时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，预算与方向）、CI 负责人（当前：吴世豪·推断待确认，CI 依赖域名清单）、运维/交付部署工程师（当前：游家豪·推断待确认，全员配置）、财务（当前：待指定，付款与票据）、法务（当前：待指定，合规边界）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交需求或故障 → ② 分类（故障/白名单/新线路/续费） → ③ 按清单排查或评估 → ④ 预算审批 → ⑤ 向运营商/供应商申请执行 → ⑥ 验证并公告 → ⑦ 更新线路台账 → ⑧ 用量监控与月度复盘
  • 交付结果：可用的海外出口线路/节点；线路与白名单台账（节点、落地 IP、白名单域名、带宽、流量、到期日、费用、票据方式）；用量告警与月度用量报告；《出口线路使用规范》
  • 状态依据：线路配置、采购、恢复全部依赖单一岗位；流量耗尽、到期、付款未到位后才被发现；“开工单”多次口头提出未落地；无申请单、无节点/白名单台账、无监控与 SLA，单月同类反馈约 25 次

1. 场景判定

  • 触发条件：海外节点不可用（超时、断流、证书过期、流量耗尽）；新增 CI/研发依赖源需加白名单；使用人数增长需扩容；节点/落地 IP 即将到期；需要新的出口区域
  • 典型说法：「刷新订阅就有」「洛杉矶的流量被用完了」「新加坡线路挂了吗」「申请加个 docker 域名加速」「公司网的海外线路是白名单机制，只打通了 AI 相关的几个域名」
  • 判断问题：问题出在海外站点访问（GitHub/Docker/海外 AI），还是公司内网本身也不通？只海外不通走本流程，全部不通走故障报修
  • 不归本流程管：办公网整体断网/变慢 → 请走 X-SEC-27；办公带宽与国内专线扩容 → 请走 X-SEC-28；AI 编程工具账号防封、网络一致性 → 请走 X-SEC-14；海外 AI 服务采购合规 → 请走 LEG-26；境外服务无票付款 → 请走 FIN-04

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 线路选型、配置、排障、白名单申请、台账与监控 R IT 运维/网管（当前：杨明学·推断待确认）
CTO 预算、扩容与线路方向拍板 A CTO（当前：丁震宇·推断待确认）
CI 负责人 维护 CI 依赖域名清单，新增源同步申请；推动缓存 R（CI 部分） CI 负责人（当前：吴世豪·推断待确认）
运维/交付工程师 全员客户端配置、上门支持 R 运维/交付部署工程师（当前：游家豪·推断待确认）
财务 线路/节点付款、票据方案 C 财务（当前：待指定）
法务 跨境访问使用范围与合规边界 C 法务（当前：待指定）
使用人 按模板反馈故障，不私自转发出口 I/R 研发及全员

3. 办之前请准备

  • 故障类：发生时间、所在网络（work/rd/飞连/家中）、访问目标域名、报错截图、curl 或 traceroute 结果、是否开了本地代理/TUN、换网（热点）对比结果
  • 白名单类：域名清单（含 CI 日志中实际用到的源）、用途、使用方
  • 新线路/扩容类：使用人数、流量估算、区域需求、预算区间、报价对比

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“出口线路工单”（故障/白名单/新线路/续费四选一，附上述材料） 使用人/CI 负责人 发现后即时 飞书表单→多维表格 工单 🔧飞书固化
2 分类与响应：故障工作时间 30 分钟内响应；白名单/新线路 1 个工作日内给出评估 IT 运维/网管 如左 多维表格、机器人通知 响应记录 🔧+🤖
3 故障按“控制变量清单”排查：换网对比→关本地代理→换节点→查流量/到期→查协议是否被拦截 IT 运维/网管 故障响应后 2 小时内给结论或临时方案 排查清单、节点面板 根因或临时切换 🤖自动化（探测脚本）+👤
4 需付费事项（新节点、落地 IP、续费、扩容）出预算表，CTO 审批，采购付款走 FIN-01 IT 运维/网管、CTO 评估后 2 个工作日内 飞书审批 审批通过 🔧飞书固化
5 向运营商/供应商申请白名单、落地 IP 或下单；跟进至开通 IT 运维/网管 供应商承诺时限内，每日跟进 供应商渠道 开通 👤人工判断
6 验证（使用人复测）并在通知群公告变更（新节点、白名单生效、订阅刷新） IT 运维/网管 开通当日 通知群公告模板 公告 🔧飞书固化
7 更新台账：节点/落地 IP/白名单/带宽/流量上限/到期日/费用/票据 IT 运维/网管 变更当日 多维表格 台账 🔧飞书固化
8 用量与可用性监控：流量达 80% 告警；到期前 15 天提醒；每月出流量排行与故障统计 IT 运维/网管 持续；每月 5 日前出报告 监控机器人、审计面板 月度报告 🤖自动化

5. 交付物与模板

  • 交付物：线路与白名单台账；月度用量与故障报告；《出口线路使用规范》（使用范围仅限 AI 开发/学术/研发依赖，禁止转发出口，个人代理自费自担，日志审计说明）
  • 建议模板/表单：出口线路工单（类型、提交人、时间、网络环境、目标域名、报错、对比测试结果、节点、处理人、结论、耗时）；线路台账（名称、区域、供应商、类型[专线/落地/节点]、带宽、流量上限、费用、到期日、付款人、票据方式、用途、负责人）

6. 异常与升级

  • 节点全部不可用、影响全员 AI 工具或 CI → IT 运维 15 分钟内群内通报，1 小时内切备用节点；超 2 小时未恢复升级 CTO
  • 流量耗尽 → 先按预授权额度重置/充值（预授权额度由 CTO 定），事后 1 个工作日内补审批
  • 付款未到账导致线路降级 → IT 运维当日通知财务与 CTO
  • 发现个人借用公司节点外传或异常大流量 → 先限流，再核实使用人，报 CTO（当日）
  • 合规边界不确定（新区域、新用途） → 暂停开通，提交法务评估

7. 衡量指标

  • 节点可用率：工作时间可用分钟/总分钟，目标 ≥ 99%
  • 故障恢复时长：工单提交到恢复，P50 ≤ 2 小时
  • 白名单申请处理时长：目标 ≤ 2 个工作日（运营商审批时间单列）
  • 到期/流量耗尽导致中断次数：目标 0
  • 台账完整率：线路与白名单字段齐全比例，目标 100%

8. 低效诊断

  • 现象：节点流量耗尽、证书过期、到期后才被使用人发现，恢复靠临时充值｜依据：「鸽子群模态分群」2026-01、「鸽子群模态分群」2026-06、「鸽子群模态分群」2026-07
  • 现象：故障反馈只能在群里 @单一岗位，“开工单”多次口头提出未落地，同类 SSL/断流问题持续数月无稳定复现记录｜依据：「鸽子群模态分群」2026-02、「鸽子群模态分群」2026-03
  • 现象：每次新增域名都要重新找运营商，无白名单清单；CI 新增源未同步就会连不上｜依据：「鸽子群模态分群」2026-04、「GIT干员藏匿处」2026-09
  • 现象：线路采购付款未落实，测试线路无带宽保证；一个节点承担约 50 人｜依据：「鸽子群模态分群」2026-04
  • 现象：无流量审计，回答不了“哪些站点耗流量最多”；CI 缺镜像缓存，1T 流量几天用完｜依据：「鸽子群模态分群」2026-07、「GIT干员藏匿处」2026-10
  • 现象：全员代理靠问卷统计后逐人上门配置；路由规则超限后才采购分流设备｜依据：「忠橙星行星引擎」2026-02、「忠橙星行星引擎」2026-04

9. 分支变体

  • 公司办公网统一出口（全员跟随，白名单机制，无法选区域）vs 个人私有线路（自购落地 IP，走公司线路需登记）
  • 海外节点（洛杉矶/新加坡等，按季度续费）/ 国内专线（仅入流量固定 IP，出流量走家宽或商宽）
  • CI 代理：由 CI 负责人维护域名清单，配镜像缓存降低流量
  • 个人代理/梯子：公司不再维护，自费自担，不得接入公司网络转发
  • 评测人员测试号单独监控，按 X-SEC-14 管理

10. 待确认问题

  • 海外线路主责是否仅 IT 运维/网管一人？是否需要设备份人（AB 角）？
  • 流量重置/充值的预授权额度是多少？超额由谁审批？
  • 海外节点无票支出如何处理，是否统一走公司供应商？
  • 出口白名单的使用范围是否已有成文规范并经法务确认？
  • 是否建设自有流量审计面板？预算与时间？
X-SEC-27办公网络故障报修与恢复待新建500

状态：待新建｜证据：有证据（卡片 24 张 / 会话 10 个）｜优先级：频5 × 耗4 × 跨5 × 险5

  • 适用场景：办公 WiFi/有线/机房出口断网、变慢、丢包、TLS 阻断，或 CI 打包机、签名机、构建集群断网，影响飞书、Gitea、CI、LeapCore 与客户演示时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，现场排查）、CI 负责人（当前：吴世豪·推断待确认，CI 机与签名机）、后端兼运维（当前：宋祺睿·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，物业/施工/线槽）、行政（当前：侯明月·推断待确认，宽带续费）、外包网络工程师团队；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 自检 → ② 提交报障 → ③ 分级 → ④ 响应并群内通报 → ⑤ 分层排查 → ⑥ 临时恢复 → ⑦ 根因修复（含运营商报修） → ⑧ 恢复通知、故障登记与复盘
  • 交付结果：恢复可用的办公网络；故障登记表记录（时间、位置、现象、根因、处理人、耗时）；P0/P1 故障复盘；宽带与线路资产台账；《网络自检清单》
  • 状态依据：上半年至 10 月几乎每月都有大面积断网（7 月被统计为“重灾区”，约一周一断），全部靠群里喊“网管”、单人临时处理；9 月起才出现飞书“故障反馈”审批但未普及；无分级、无 SLA、无根因记录，宽带账号与办理人说不清，曾因欠费断网

1. 场景判定

  • 触发条件：多人同时无法上网或明显变慢；Gitea/CI/飞书/LeapCore 访问异常且换网后正常；AP 消失、有线不通；CI 打包机/签名机/构建集群掉线；出现 IP 冲突
  • 典型说法：「网又断了吗」「网管呢，怎么突然没网」「CI 网络又挂了」「公司网络现在波动很大，发个消息卡十秒」「正在催电信」
  • 判断问题：是只有我一个人（换有线/关代理/关虚拟网卡后仍不行吗）还是多人？是只有海外站点不通吗？只海外不通走 X-SEC-26；个人设备问题走 X-SEC-30
  • 不归本流程管：计划停机、机房与服务器故障 → 请走 X-SEC-29；网络扩容与改造 → 请走 X-SEC-28；海外节点 → 请走 X-SEC-26；远程接入 → 请走 X-SEC-25；电脑与外设 → 请走 X-SEC-30；办公设施（非网络）→ 请走 ADM-08；活动现场网络 → 请走 X-SEC-32；可疑设备/入侵 → 请走 X-SEC-42；CI 构建失败本身 → 请走 RND-38

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 受理、分级、排查、修复、通报、复盘 R/A IT 运维/网管（当前：杨明学·推断待确认）
运维/交付工程师 现场查 AP/网线/机柜、网管不在时的 B 角 R 运维/交付部署工程师（当前：游家豪·推断待确认）
CI 负责人 CI 机、签名机、runner 断网后恢复与验证 R（CI 部分） CI 负责人（当前：吴世豪·推断待确认）
后端兼运维 协助排查内部服务连通性 C 后端兼运维（当前：宋祺睿·推断待确认）
行政 物业停电/装修施工预告、线槽施工、宽带续费 R（行政部分） 行政负责人（当前：胡则瑾·推断待确认）；行政（当前：侯明月·推断待确认）
外包网络工程师/运营商 线路、光衰、设备层修复 R（外部） 外部服务商
CTO P0 升级、外部团队与预算决策、对外影响评估 A（升级） CTO（当前：丁震宇·推断待确认）
报障人 自检、按模板提交、配合测试 R 全员

3. 办之前请准备

  • 按《网络自检清单》完成：换有线或换 SSID 对比、关闭本地代理/TUN 与多余虚拟网卡、清 DNS 缓存、确认没有连到访客网
  • 发生时间、楼层/工位/会议室、SSID 或有线、受影响服务（飞书/Gitea/CI/LeapCore/海外 AI）
  • 截图、测速结果、ping/traceroute 输出（必要时 iperf 数据）
  • 影响范围：只有自己/本区域/全员；是否影响发版或客户演示
  • 请求最少包含字段（网络故障反馈必填，缺项由网管一次性追问）：发生时间、楼层/工位/会议室、SSID 或有线、受影响服务、现象描述、自检清单勾选结果、截图或测速/ping 输出、影响范围（自己/区域/全员）、是否阻塞发版或客户演示及截止时间、报障人岗位

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按自检清单排除个人终端问题 报障人 5 分钟 网络自检清单、诊断脚本 自检结果（勾选项随故障单提交） 🤖自动化
2 提交“网络故障反馈”（位置、SSID、现象、时间、截图、自检结果），系统自动 @网管与 B 角 报障人 自检后即时 飞书审批/表单+机器人 故障单（故障登记表一行，编号回给报障人；群里只贴单号不另行描述） 🔧飞书固化
3 分级：P0=全员/CI/发版/客户演示阻塞；P1=某楼层或某网段；P2=个别人 IT 运维/网管 收到后 15 分钟内 故障登记表 级别（写入故障单，报障人自动收到）；超时→机器人 @ B 角 👤人工判断
4 响应并在通知群发状态（影响范围、预计恢复时间、临时方案） IT 运维/网管 P0 15 分钟、P1 30 分钟、P2 当日 通知群公告模板 状态通报（通知群公告卡片，含单号与下次同步时间；P0 影响发版/演示时同步 @ 研发负责人与销售） 🔧飞书固化
5 分层排查：终端→AP/交换机/网线→IP 冲突与 DHCP→出口 NAT 连接数与带宽→运营商线路/光衰 IT 运维/网管、运维工程师 P0 1 小时内定位；P1 4 小时内 路由日志、监控、抓包脚本 定位结论（写入故障单"根因层级"字段） 🤖+👤
6 临时恢复：切专线/备用出口、限制访客网连接数、临时接线、CPE 临时路由；必要时公告居家或热点办公 IT 运维/网管 P0 1 小时内、P1 4 小时内 网络设备 服务恢复（通知群恢复通报 + 故障单状态"临时恢复"）；超时→升级 CTO 👤人工判断
7 根因修复：换交换机/网线、调整网段、联系运营商报修（凭宽带台账）、安排非工作时间维护 IT 运维/网管、外包/运营商、行政 P0 2 个工作日内给修复计划；运营商报修当天提交并记录工单号 宽带台账、运营商工单 修复完成（故障单附修复计划、运营商工单号与完成时间；维护窗口提前 1 个工作日在通知群公告） 👤人工判断
8 CI 机/签名机/runner 恢复在线并重跑积压任务 CI 负责人 网络恢复后 1 小时内 CI 后台 CI 恢复（研发通知群一句话确认 + 积压任务重跑结果）；超时→网管 @ CI 负责人，再超 1 小时报 CTO 🤖自动化
9 发恢复通知；故障登记；P0/P1 在 3 个工作日内出复盘（根因、改进项、负责人、期限） IT 运维/网管 恢复后即时；复盘 3 个工作日 多维表格、复盘模板 恢复通知（通知群）+ 故障单关闭 + 复盘记录（复盘文档链接回填故障单，改进项有负责人与期限） 🔧+🤖

5. 交付物与模板

  • 交付物：故障登记表；P0/P1 复盘文档；宽带与线路资产台账（运营商、宽带账号存放位置、办理人、SIM 卡/光猫保管人、续费日）；《网络自检清单》；月度网络故障统计
  • 建议模板/表单：网络故障反馈（报障人、时间、楼层/位置、SSID/有线、受影响服务、现象、截图、自检项勾选、影响范围、是否影响演示/发版）；复盘模板（时间线、影响、根因层级[终端/AP/交换/出口/运营商/外部施工]、临时方案、永久措施、负责人、截止日）

6. 异常与升级

  • 升级条件：P0 超 1 小时未恢复、需引入外部团队或新增预算、运营商判断“物理上无解”需改线路、需评估对客户演示的影响 → IT 运维/网管升级 CTO 决策；P1/P2 由 IT 运维/网管直接处置
  • 网管外派/休假 → 由运维/交付工程师作为 B 角受理；B 角也不在时报 CTO 指派（30 分钟内）
  • P0 超 1 小时未恢复 → 升级 CTO，评估是否通知销售/客户调整演示（立即）
  • 运营商拖延或现场判断“物理上无解” → CTO 决定是否改企业带宽/新增线路，转 X-SEC-28
  • 欠费断网 → 行政 2 小时内续费，补录续费提醒
  • 异常并发流量导致出口打满 → 网管可先封禁可疑 IP，事后 1 个工作日内核实设备主人并补登记
  • 施工/停电导致断网 → 行政负责提前通知，未通知的事后在复盘中记录
  • 报障只在群里喊"没网"、未提交故障单 → 网管或 B 角回复"请提单"并贴表单链接，不在群内排查；15 分钟内未提单的按 P2 处理
  • 故障单提交后 15 分钟无人分级/响应 → 机器人 @ B 角；30 分钟仍无响应 → 报障人升级 CTO 指派（不逐个私聊找人）
  • 发版/客户演示被阻塞 → 网管在通知群同步时 @ 研发负责人或销售负责人，由其决定改期；恢复后再次 @ 告知

7. 衡量指标

  • 月度网络故障次数：按级别统计，目标 P0 ≤ 1 次/月
  • 平均恢复时长（MTTR）：P0 ≤ 1 小时临时恢复，P1 ≤ 4 小时
  • 报障单信息完整率：必填项齐全比例，目标 ≥ 90%
  • 复盘按时完成率：P0/P1 3 个工作日内，目标 100%
  • 欠费/未预告施工导致断网次数：目标 0

8. 低效诊断

  • 现象：报障只能在群里喊“网管”，无记录、无时限，故障结论分散在聊天中，事后要靠机器人翻聊天记录统计次数｜依据：「随便瞎聊啦～」2026-08、「跃迁AI总动员」2026-07、「鸽子群模态分群」2026-05
  • 现象：网管岗位单点，外派时无人接手，曾出现派单给不相关人员｜依据：「鸽子群模态分群」2026-05、「模态集团（全员群）」2026-05
  • 现象：报障信息不全，没有测速/抓包数据，排查只能“算卦”；报障方与运维方互相怀疑对方设备｜依据：「Leap产研测」2026-08、「鸽子群模态分群」2026-06
  • 现象：宽带账号、办理人、SIM 卡持有人说不清，报修前先找账号｜依据：「鸽子群模态分群」2026-07
  • 现象：宽带欠费导致断网，且“每月必发”｜依据：「忠橙星行星引擎」2026-03、「模态集团（全员群）」2026-04
  • 现象：装修断电、网络调整、专线停用事先无通知或通知过晚｜依据：「鸽子群模态分群」2026-04、「跃迁AI总动员」2026-08、「跃迁AI总动员」2026-09
  • 现象：IP 被抢占、访客网共用出口打满连接数，同一问题跨周仍影响发版｜依据：「Leap产研测」2026-08
  • 现象：交换机、光衰、网线被踢等根因无书面记录，同类故障反复｜依据：「Leap产研测」2026-09、「跃迁AI总动员」2026-07
  • 现象：CI 机、签名机、构建集群断网后需人工恢复，积压任务，出包阻塞约两周｜依据：「Leap产研测」2026-07、「跃迁AI总动员」2026-09、「信创LeapCore客户端适配」2026-08

9. 分支变体

  • A 办公 WiFi 过载/AP 故障（多终端挤同一 AP、会议室与研发共用）：加 AP、分流
  • B 出口 QoS/家宽或商宽问题：切专线、限速策略调整
  • C 光纤物理衰减/多级分光：运营商报修，必要时改企业带宽
  • D 终端代理/TUN/网卡驱动/虚拟网卡问题：转 X-SEC-30 支持
  • E 云机房或服务器层问题：转 X-SEC-29
  • 施工断电（行政牵头）与网络配置变更（IT 牵头）分开处理；变更需提前公告
  • CI 打包机/签名机/构建集群：网络恢复后由 CI 负责人验证；磁盘满等转 RND-79
  • 协作协议：遵循 ALL-01（工作请求提交与受理）、ALL-02（消息分级与响应时限）、ALL-06（卡点升级阶梯）、ALL-07（群聊治理）

10. 待确认问题

  • 主责是否为 IT 运维/网管？B 角是否确定为运维/交付工程师或外包网络工程师？
  • 飞书“故障反馈”审批是否作为唯一报障入口？群内报障是否需引导转单？
  • P0/P1/P2 分级与响应时限是否可行？是否需要非工作时间值班？
  • 宽带续费与宽带台账由行政还是 IT 维护？
  • 研发网与办公网是否单独组网（已多次提出）？由谁决策？
X-SEC-28办公网络建设升级、带宽专线扩容与机房设备采购待新建200

状态：待新建｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频2 × 耗5 × 跨4 × 险5

  • 适用场景：新增楼层/机房、人员增长导致带宽不足、网络长期拥堵需整体重做，或需采购防火墙/交换机/模块、新增或升级专线与商宽、服务器上架与机房搬迁时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案评审与审批）、销售负责人（当前：李鹏为·推断待确认，引荐服务商与商务谈价）、运维/交付部署工程师（当前：游家豪·推断待确认，搬运上架）、财务（当前：待指定，付款与发票）、行政（当前：待指定，场地/物业/施工协调）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 需求立项（网络需求文档） → ② CTO 评审方案 → ③ 至少 2 家服务商/运营商勘探报价 → ④ 比价谈价 → ⑤ 采购审批与合同 → ⑥ 施工排期与变更公告 → ⑦ 测试验收 → ⑧ 台账更新与限速策略公告
  • 交付结果：验收通过的网络/机房改造或新增线路；网络需求文档与比价表；验收记录（测试报告、设备打标、机柜整理照片）；更新后的线路台账与硬件清单；网络使用与限速策略公告
  • 状态依据：CTO 已明确提出要“报网络需求的 SOP”，目前只有一次性需求文档；施工延期、机房未收到接线通知、机柜电力不足、二手设备发票等问题均在现场或事后才处理，进度靠群里反复追问

1. 场景判定

  • 触发条件：带宽利用率持续高位或套餐到上限；新楼层/新机房启用；网络故障被判定为结构性问题（需重新组网）；服务器需上架/搬迁；需采购网络安全设备
  • 典型说法：「有没有报网络需求的 SOP」「网络外包团队呢」「已经准备扩容了，询价中」「你不得先谈专线采购吗」「今天不能通，机房那边没收到通知接线」
  • 判断问题：这件事是否涉及采购、施工或网络架构变更？若只是修复已有网络，走故障报修
  • 不归本流程管：日常断网修复 → 请走 X-SEC-27；海外节点与出口白名单 → 请走 X-SEC-26；服务器停机迁移与 IP 切换 → 请走 X-SEC-29；一般 IT 设备采购 → 请走 ADM-24；场地租赁与装修 → 请走 ADM-01；客户机房部署 → 请走 X-DLV-19

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 写需求、勘探、对接服务商、施工协调、验收、台账 R IT 运维/网管（当前：杨明学·推断待确认）
CTO 评审方案、取舍、预算审批、催办集成商 A CTO（当前：丁震宇·推断待确认）
销售负责人 引荐本地服务商、商务砍价 C 销售负责人（当前：李鹏为·推断待确认）
运维/交付工程师 设备搬运、上架、现场配合 R 运维/交付部署工程师（当前：游家豪·推断待确认）
财务 付款、发票合规（含二手设备代开） C 财务（当前：待指定）
行政 物业报备、施工许可、断电协调、线槽施工 C 行政（当前：待指定）
外部集成商/运营商/机房 勘探、方案、施工、接线、入室登记 R（外部） 外部服务商
全员 接收变更公告 I 全员

3. 办之前请准备

  • 现状：当前线路（运营商、带宽、到期日）、设备清单、拓扑、近 1 个月故障与带宽峰值数据
  • 需求：覆盖区域（楼层/机房/会议室）、人数与增长预期、分区要求（work/rd/IoT/访客）、是否需要认证与固定 IP
  • 预算区间与期望上线时间
  • 机房作业：机柜位置与容量、电力、入室人员身份登记信息、运营商接线需求

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 按模板写网络需求文档并立项 IT 运维/网管 触发后 3 个工作日内 飞书文档模板、飞书项目 需求文档 🔧飞书固化
2 CTO 评审方案并补漏（区域、分区、冗余） CTO 收到后 2 个工作日内 飞书文档评论 评审意见 👤人工判断
3 邀请至少 2 家服务商/运营商实地勘探并出方案报价 IT 运维/网管、销售负责人 评审后 5 个工作日内 外部沟通群 报价单 👤人工判断
4 比价表拆分硬件/软件/施工/年费，谈价 IT 运维/网管、销售负责人 收齐报价后 3 个工作日内 多维表格比价表 定价方案 🤖自动化（AI 初筛对比）+👤
5 采购审批与合同（含发票类型、二手设备开票方式） IT 运维/网管、CTO、财务 2 个工作日内 飞书采购审批（FIN-01）、合同审核（LEG-04） 合同与付款 🔧飞书固化
6 排施工窗口（非工作时间、分区分批割接），提前公告影响与临时方案；机房作业按检查单预约入室、通知接线 IT 运维/网管、行政 公告提前 ≥ 24 小时；机房预约提前 ≥ 2 个工作日 通知群公告、飞书日历、机房作业检查单 施工计划与公告 🔧飞书固化
7 施工进度在飞书任务/项目更新；延期由服务商当日书面说明 IT 运维/网管 每个工作日更新 飞书任务 进度记录 🔧飞书固化
8 验收：链路测试、无线覆盖测试、设备打标、机柜整理、文档交付 IT 运维/网管 施工完成后 3 个工作日内 测试仪、验收单 验收记录 👤人工判断
9 更新线路台账、硬件清单、拓扑；公告新限速与分区策略 IT 运维/网管 验收当日 多维表格、知识库 台账与公告 🔧飞书固化

5. 交付物与模板

  • 交付物：网络需求文档；服务商比价表；采购合同；施工计划与公告；验收单；线路台账；硬件清单（含价格、序列号、位置）；拓扑图
  • 建议模板/表单：网络需求模板（背景、范围、人数、分区、带宽、冗余、认证、预算、上线时间）；比价表（服务商、硬件、软件授权、施工、年费、交付周期、质保、发票类型、总价）；机房作业检查单（预约时间、入室人员、运营商接线通知、机柜/电力余量、带宽、回滚方案）；线路台账（运营商、类型[专线/商宽/住宅]、带宽、用途、费用、到期日、入户光纤数）

6. 异常与升级

  • 服务商延期 → 服务商当日书面说明新时间，IT 运维同步 CTO；延期超 1 周由 CTO 与服务商高层沟通
  • 机房未通知接线/机柜电力不足 → 当日暂停上架，按检查单补齐后改约
  • 二手/个人卖家设备无法正规开票 → 采购前与财务确认开票方式，无法确认的不下单
  • 施工影响超出公告范围 → 立即回滚或启用临时路由，按 X-SEC-27 报障
  • 预算超出审批额度 10% 以上 → 重新提交审批

7. 衡量指标

  • 需求到方案评审完成：目标 ≤ 5 个工作日
  • 施工按期完成率：目标 ≥ 90%
  • 变更公告提前量：≥ 24 小时的比例，目标 100%
  • 验收一次通过率：目标 ≥ 90%
  • 带宽峰值利用率：扩容后 3 个月内 < 80%
  • 线路台账完整率：目标 100%

8. 低效诊断

  • 现象：网络变更无预告，变更后研发大面积反馈不可用，限速、RD 网连接方式靠口头问｜依据：「Leap产研测」2026-08
  • 现象：无需求模板、比价表和验收清单，方案节奏和进展被反复追问约 8 次｜依据：「忠橙星行星引擎」2026-08、「忠橙星行星引擎」2026-09
  • 现象：采购谈判与日常运维压在同一岗位，专线谈价拖延；入户光纤数量无记录，临时才发现不足｜依据：「忠橙星行星引擎」2026-08、「忠橙星行星引擎」2026-09
  • 现象：施工方延期未及时同步，现场调试人员等候约 1 小时｜依据：「忠橙星行星引擎」2026-09
  • 现象：机房未收到接线通知导致当天无网，机柜容量不足需回搬｜依据：「忠橙星行星引擎」2026-01
  • 现象：二手设备发票、税务问题在采购后才处理｜依据：「忠橙星行星引擎」2026-01、「忠橙星行星引擎」2026-03

9. 分支变体

  • 纯带宽扩容：比较“新增线路”与“升级套餐”，按性价比决策；新线路测试稳定后再取消旧线路
  • 线路类型：专线（CI/飞连/互联网入口）、商宽（全员出口）、住宅线路（访客网）
  • 机房：公司自有机房、托管机房（需入室登记）、客户机房（走交付流程）
  • 一体改造：机房+制冷+隔音一并规划，行政参与
  • 安全设备选型：参考《公司内网接入设备选型》（防火墙 SSLVPN 授权、吞吐、飞书单点登录支持等）
  • 限速策略：工作网段个人动态限速、访客网段更低，变更需公告

10. 待确认问题

  • 主责是否为 IT 运维/网管？采购谈判是否应由采购/行政承担以减轻 IT 负担？
  • 服务商引荐与谈价由销售负责人参与是否为常态安排？
  • 网络建设类采购的审批额度分级是多少？
  • 二手设备采购是否允许？开票规则是否已成文？
  • 托管机房入室登记由谁统一办理？
X-SEC-29机房/服务器停机维护、迁移与故障应急（含备份与数据恢复）待新建300

状态：待新建｜证据：有证据（卡片 10 张 / 会话 7 个）｜优先级：频3 × 耗5 × 跨4 × 险5

  • 适用场景：计划停机检修（坏盘、物业停电、网络维护）、服务器迁移与 IP 切换、安全组/防火墙规则变更，或断电、硬盘/阵列、证书过期、Redis 断连等非计划故障，以及误操作导致数据丢失需恢复、新服务器上线需确认备份时启动；同时覆盖生产数据（云数据库、对象存储、网盘、计费/订单/钱包库、网关与渠道配置）的备份定级、每日校验与定期恢复演练
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认，机房与硬件）；协同——后端兼运维（当前：宋祺睿·推断待确认，服务迁移/安全组/备份）、运维/交付部署工程师（当前：游家豪·推断待确认，现场与 IP 切换）、Leap 研发负责人（当前：王皓南·推断待确认，研发侧需求与验证）、产品总监（当前：杨萌·推断待确认，对销售/客户通知）、NewAPI 研发（当前：柯逸飞·推断待确认）、跃竞运维（当前：席博田·推断待确认）、行政（当前：胡则瑾·推断待确认，停电等行政通知）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 变更申请或故障发现 → ② 查服务-负责人台账评估影响 → ③ 审批与公告 → ④ 有序停机/执行或应急止血 → ⑤ 按验证清单验证 → ⑥ 恢复通知 → ⑦ 复盘与台账更新 → ⑧ 生产数据备份定级（RPO/RTO）与跨账号副本 → ⑨ 每日备份校验与每周巡检 → ⑩ 季度恢复演练与整改
  • 交付结果：按时完成且已验证的变更/恢复的服务；基础设施变更单与公告；服务器资产与服务-负责人台账；故障复盘；生产数据备份清单（含 RPO/RTO、保留期、负责人）；每日备份校验与巡检记录；季度恢复演练报告
  • 状态依据：停电事故时不知道关键服务器是哪台，数据曾部分丢失；切 IP 时间与执行人不清导致演示中被切；安全组变更无通知误伤生产 Redis；维修通知仅提前约 1 小时；新生产发版后才被提醒检查备份；“超级 SOP”仅口头提出

1. 场景判定

  • 触发条件：硬盘告警/坏盘；物业停电或台风预警；服务器迁移、换 IP、换机；安全组/端口/防火墙变更；证书过期 502；断电后服务未自启或卷未挂载；误操作删除数据；新服务器、新生产库/存储/有状态服务上线；每日备份任务执行；每季度演练日；云厂商备份策略或保留期变化
  • 典型说法：「6 点半公司服务器要停服检修半小时」「万一有人在演示呢，说切就切吗」「下回提表单」「真得加监控了」「先保证客户出事能恢复数据，再解决根因」
  • 判断问题：这件事是否会让某个服务在一段时间内不可用或换地址？是否有数据丢失风险？这份生产数据丢失后是否影响客户使用、资金或合同交付？是则走本流程
  • 不归本流程管：办公网断网 → 请走 X-SEC-27；应用层线上故障 → 请走 RND-75；应用发布与生产变更（含变更前一次性备份）→ 请走 RND-58；线上异常数据订正 → 请走 RND-80；证书续期监控 → 请走 X-SEC-21；服务器资源申请 → 请走 X-SEC-16、X-SEC-17；停电/极端天气全员通知 → 请走 ADM-09；凭据泄露 → 请走 X-SEC-11

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 机房、硬件、网络层变更与应急，台账维护 R/A IT 运维/网管（当前：杨明学·推断待确认）
后端兼运维 服务迁移、安全组规则、备份开启与验证 R 后端兼运维（当前：宋祺睿·推断待确认）
运维/交付工程师 机房现场、IP 切换执行 R 运维/交付部署工程师（当前：游家豪·推断待确认）
研发负责人 提出迁移需求、指定验证人、确认窗口 C Leap 研发负责人（当前：王皓南·推断待确认）
产品总监 对销售/客户发停机与恢复通知，确认无演示冲突 R（通知） 产品总监（当前：杨萌·推断待确认）
服务负责人 各自服务的验证与数据一致性核对 R NewAPI 研发（当前：柯逸飞·推断待确认）；跃竞运维（当前：席博田·推断待确认）
行政 物业停电、台风等通知转发 C 行政（当前：胡则瑾·推断待确认）
信息安全 备份加密、访问权限与跨账号隔离审查 C 信息安全负责人（当前：待指定）
CTO 窗口冲突裁决、P0 升级、数据恢复方案拍板、RPO/RTO 与演练结论审定 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 服务-负责人台账：机器名、IP、物理位置、承载服务、负责人、是否客户/演示相关
  • 变更内容、影响范围、开始与预计结束时间、回滚方案、执行人、验证人
  • 近期演示与发版日程（向产品总监确认）
  • 备份状态：最近一次成功备份时间、可恢复验证结果
  • 生产数据资产清单（服务、库名、所在云账号/主体、数据类别、是否含个人信息或资金数据）；云厂商备份能力与保留期说明；隔离的恢复演练环境
  • 新地址/新连接信息的交付方式（不得群内明文发凭据）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 计划变更提交“基础设施变更申请”（影响/窗口/回滚/执行人/验证人）；故障则直接进入第 4 步 发起人 计划变更提前 ≥ 2 个工作日 飞书审批 变更单 🔧飞书固化
2 查台账评估影响，确认无演示/发版冲突 IT 运维/网管、产品总监 提交后 4 个工作小时内 多维表格台账、飞书日历 影响评估 👤人工判断
3 审批通过后发公告：计划内 ≥ 24 小时、紧急检修 ≥ 30 分钟，写明时间、影响服务、替代方案 IT 运维/网管、产品总监 如左 通知群公告模板、飞书日历 公告 🤖+👤
4 执行或应急止血：有序停机/迁移/切 IP；故障时先恢复服务与数据，再查根因；看日志定位，不猜测 执行人 窗口内；P0 故障 15 分钟内响应 运维工具、日志平台 执行记录 👤人工判断
5 按验证清单验证：服务可访问、卷已挂载、容器在数据盘挂载后启动、数据一致、充值/登录等关键路径、监控恢复 验证人 执行后 1 小时内 验证清单 验证结果 🤖自动化（巡检脚本）+👤
6 发恢复通知（对内+销售/客户）；新地址经台账或受控文档发布 IT 运维/网管、产品总监 验证通过后 30 分钟内 通知群 恢复通知 🔧飞书固化
7 故障或超窗变更 3 个工作日内复盘；更新台账；旧机关机，旧数据保留到约定日期后抹除 IT 运维/网管、服务负责人 3 个工作日内 复盘模板、台账 复盘与台账 🔧飞书固化
8 备份定级与配置：盘点生产数据，按资金/客户/一般三级定 RPO/RTO；配置自动备份与跨账号/异地副本并加密；新服务器、新生产库上线前确认备份已开 后端兼运维 + 服务负责人 新服务上线前；存量 1 个月内完成 多维表格备份清单、云厂商备份/脚本 备份清单与策略 🤖+👤
9 备份校验：每日自动校验备份是否成功、大小是否异常，失败推送告警；每周人工巡检（服务器级每日备份保留 3 天、数据库每日备份） 后端兼运维 每日 9:00 前自动校验；每周巡检 备份监控机器人 校验与巡检记录 🤖自动化
10 恢复演练：每季度抽取资金级、客户级数据各至少 1 项做恢复演练，并做 1 次断电恢复演练；未达 RTO 或数据不完整的建整改工单，报告归档 后端兼运维 + 服务负责人 每季度末月 15 日前；整改工单演练后 3 个工作日内，报告 5 个工作日内 演练环境、工单系统、知识库 演练报告与整改工单 👤人工判断

5. 交付物与模板

  • 交付物：基础设施变更单；停机/恢复公告；服务器资产与服务-负责人台账；故障复盘；备份巡检与演练记录；《断电恢复手册》
  • 建议模板/表单：变更申请（变更类型[停机/迁移/IP 切换/安全组/硬件]、影响服务、开始/结束时间、回滚方案、执行人、验证人、是否影响演示、审批人）；验证清单（多硬盘服务器检查容器服务依赖数据盘挂载、端口连通、关键业务路径、监控告警恢复、旧机处理）；上线检查（镜像备份已开、DB 备份已开、恢复已演练）；生产数据备份清单（服务、数据对象、级别、云账号/主体、备份方式、频率、保留期、副本位置、RPO、RTO、负责人、最近演练日期、结果）

6. 异常与升级

  • 断电或掉线导致客户/演示环境不可用 → P0，15 分钟内 IT 运维到场或远程，30 分钟未恢复升级 CTO，产品总监同步受影响销售
  • 数据丢失（含误操作） → 立即停止写入，按备份恢复；CTO 决定恢复方案与对外沟通；3 个工作日内复盘，责任认定按 RND-12
  • 变更时间与演示冲突 → 产品总监有否决权，改约窗口
  • 安全组/防火墙变更误伤生产 → 立即回滚，补专用规则，复盘中补变更通知
  • 服务无人认领（创建人离开） → CTO 当日指定负责人并写入台账
  • 备份连续 2 次失败 → 后端兼运维当日修复 → 当日升级 CTO
  • 演练恢复失败或耗时超过 RTO 2 倍 → 列为 P1 整改 → 1 个工作日内升级 CTO
  • 发现生产数据无任何备份 → 当日补首个全量备份 → 通报服务负责人
  • 升级条件汇总：P0 故障 30 分钟未恢复、数据丢失需定恢复方案与对外口径、变更窗口冲突、无人认领服务、RPO/RTO 定级与演练结论审定 → IT 运维/网管升级 CTO；其余计划变更与日常巡检由 IT 运维/网管直接决定

7. 衡量指标

  • 计划变更公告达标率：提前 ≥ 24 小时的比例，目标 100%
  • 非计划故障恢复时长：P0 ≤ 1 小时
  • 变更后验证漏项数：目标 0
  • 备份开启率：生产/内部 SaaS 服务器与数据库，目标 100%
  • 备份覆盖率 = 已备份生产数据对象 / 备份清单总数，目标 100%
  • 备份成功率 = 成功次数 / 计划次数（月），目标 ≥ 99%
  • 恢复演练：每季度 ≥ 1 次并有记录；演练达标率 = 恢复耗时 ≤ RTO 的演练项 / 演练项，目标 100%
  • 台账覆盖率：在用服务器有负责人比例，目标 100%

8. 低效诊断

  • 现象：停电事故时不知道关键服务器是哪台、谁负责，多人同时操作，恢复持续一天以上｜依据：「Leap产研测」2026-06、「Leap产研测」2026-07
  • 现象：服务创建人离开后无人认领，证书过期后才发现是手动管理；停电后 CI runner 离线积压任务｜依据：「Leap产研测」2026-08
  • 现象：切 IP 的时间和执行人不清，研发要求切、IT 理解成关机，切换后未验证且有漏项；群聊与表单之争未定｜依据：「Leap产研测」2026-08
  • 现象：维修通知提前量不足，员工要求非工作时间维护；维护时仍有任务在跑｜依据：「模态跃迁通知群」2026-07、「模态跃迁通知群」2026-08
  • 现象：安全组规则变更无通知，误伤生产服务连接 Redis，事后才提出加监控｜依据：「AI API」2026-08
  • 现象：迁移后的新连接地址与凭据在群内明文发布｜依据：「跃玩项目组」2026-08
  • 现象：新生产系统发版后才被提醒检查备份，容灾经验不足｜依据：「公司内FDE」2026-09
  • 现象：误操作致同事工作产出丢失，事后只议责任，无备份与复盘｜依据：「鼎慧产研决策部」2026-04
  • 现象：服务器硬件故障全部依赖单一岗位，下单维修期间服务不可用｜依据：「鸽子群模态分群」2026-02

9. 分支变体

  • 计划停机：物业停电、坏盘更换、网络维护、机房装修（行政转发通知）
  • 迁移与 IP 切换：服务器迁移、集群迁移；对外有演示时由产品总监确认窗口
  • 非计划故障：断电掉线、阵列/硬盘、证书过期、安全组误伤、Redis 断连
  • 数据恢复：服务器镜像备份 / 数据库备份 / 应用镜像回滚
  • 跃竞集群：中间件迁移、监控主控变更由跃竞运维提前预告
  • 自有机器 vs 客户交付机器：客户机器故障走交付流程，参照本流程的验证与复盘
  • 客户私有化实例/一体机的数据备份由客户或交付侧负责，须在交付须知中写明 → 见 X-DLV-30
  • 资金类数据（俱乐部会员端、钱包与分账等）RPO 应最严格
  • 已合并原 RND-90（生产数据备份与恢复演练）：其备份定级、跨账号副本、每日校验与季度恢复演练内容已并入本条

10. 待确认问题

  • 合并原 RND-90 后，生产数据备份与恢复演练归口研发（RND）还是 IT 运维（X-SEC），请管理层裁定
  • 三级 RPO/RTO 的具体数值（如资金级 RPO ≤ 15 分钟）是否可行？备份副本是否需要放到独立云账号或不同主体名下？
  • 主责是否为 IT 运维/网管？服务迁移类变更是否由后端兼运维主责更合适？
  • IT 只接受指定接口人变更请求的口径是否保留？接口人是谁？
  • 计划停机公告提前 24 小时、紧急 30 分钟是否可行？固定维护窗口定在何时？
  • 备份保留 3 天是否满足 2B 客户要求？演练频率是否为每季度？
  • 是否已有飞书“基础设施变更申请”审批？若无，由谁搭建？
X-SEC-30IT 资产领用、设备报修与终端技术支持待优化96

状态：待优化｜证据：有证据（卡片 11 张 / 会话 8 个）｜优先级：频4 × 耗2 × 跨4 × 险3

  • 适用场景：员工领用实体/非实体 IT 资产、电脑与会议室设备故障报修、新电脑到岗初始化、AI 开发工具与内部工具安装配置求助时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认，装机与现场）、后端兼运维（当前：宋祺睿·推断待确认，AI 工具配置支持）、人事负责人（当前：黄莹·推断待确认，审批流配置）、行政（当前：侯明月·推断待确认）、行政负责人（当前：胡则瑾·推断待确认，会议室设备）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交领用/报修/装机支持单 → ② 部门负责人审批（领用类） → ③ IT 受理分派 → ④ 发放/初始化/远程或现场处理/联系厂商 → ⑤ 台账自动更新 → ⑥ 申请人确认关闭 → ⑦ 沉淀 FAQ → ⑧ 月度对账
  • 交付结果：已发放并登记的资产；已修复或已转送修的设备；完成初始化的新电脑；IT 资产台账（账实相符）；IT 支持 FAQ 与标准安装脚本
  • 状态依据：已有“IT 资产管理”多维表格、新增行机器人通知和运维审批类别（实体/非实体领用、设备报修），但台账曾误填、资产归口（行政/运维）不清；软件安装和终端故障仍靠群里点名、私下拜托，同类问题反复处理

1. 场景判定

  • 触发条件：新人或在职员工需要电脑/显示器/外设；需要服务器、域名解析、开发者 AppID 等非实体资产；电脑故障、系统崩溃、预装软件弹窗；会议室电视无法入会；需要安装 Claude Code、Codex、OpenClaw 等工具或配置失败
  • 典型说法：「帮我在公司电脑上装一下 Claude Code」「以后 HP 新机器全部重装」「经常卡死加不进飞书会议，修一下」「申请资产和实际发放资产能对上就是对的」「不会配置的找运维帮忙」
  • 判断问题：这是“领东西/修东西/装东西”吗？是否只有我一台设备受影响？多人断网走网络报修
  • 不归本流程管：设备采购 → 请走 ADM-24；到货验收入库 → 请走 ADM-27；硬件送修、保修与维修费用 → 请走 ADM-31；离职换机回收 → 请走 ADM-32；资产盘点 → 请走 ADM-33；云服务与软件订阅申领 → 请走 ADM-34；AI 工具账号订阅与防封 → 请走 X-SEC-14；AI 工具用法经验与培训 → 请走 RND-29；网络故障 → 请走 X-SEC-27；终端管控软件导致的异常 → 请走 X-SEC-31；业务同事的数据抓取需求 → 不属 IT 支持，按研发需求排期

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 受理分派、台账维护、终端策略、厂商对接、月度对账 R/A IT 运维/网管（当前：杨明学·推断待确认）
运维/交付工程师 发放、装机初始化、现场与远程支持 R 运维/交付部署工程师（当前：游家豪·推断待确认）
后端兼运维 AI 开发工具配置与疑难支持（B 角） C 后端兼运维（当前：宋祺睿·推断待确认）
人事负责人 运维审批类别与审批流配置，入职清单联动 C 人事负责人（当前：黄莹·推断待确认）
行政 显示器等办公设备归口、会议室设备报修协调 C 行政（当前：侯明月·推断待确认）；行政负责人（当前：胡则瑾·推断待确认）
部门负责人 领用审批 R（审批） 各部门负责人
CTO 资产归口争议、标准环境清单拍板 A（升级） CTO（当前：丁震宇·推断待确认）
申请人 按模板提交、确认关闭 R 全员

3. 办之前请准备

  • 领用：资产类型（实体/非实体）、型号或规格、用途、使用期限、使用人
  • 报修：设备资产编号、故障现象、发生时间、截图或照片、已尝试的操作、是否影响演示/会议
  • 装机支持：操作系统（Mac/Windows/WSL）、需要的工具清单、报错截图、是否公司设备

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在飞书审批“运维”类别提交实体领用/非实体领用/设备报修/装机支持 申请人 需要时；会议用设备提前 1 个工作日 飞书审批 工单 🔧飞书固化
2 领用类由部门负责人审批 部门负责人 提交后 1 个工作日内 飞书审批 审批结果 🔧飞书固化
3 IT 受理并按类别分派（网络/电脑/账号/会议室） IT 运维/网管 4 个工作小时内响应 多维表格工单 分派记录 🤖自动化（按类别自动派单）
4 处理：发放并登记；新机按初始化清单处理；远程或现场排障；需厂商时拉厂商工单；硬件损坏转 ADM-31 运维/交付工程师 一般问题 2 个工作日内；影响会议/演示的 2 小时内 远程工具、标准安装脚本 处理结果 🤖+👤
5 审批通过/发放后自动更新台账（已发放数、库存、使用人） 系统 即时 多维表格自动化 台账更新 🔧飞书固化
6 申请人确认后关闭工单 申请人 处理后 1 个工作日内 飞书审批 关闭 🔧飞书固化
7 同类问题出现 2 次以上写入 FAQ 或安装脚本 运维/交付工程师 每周五 飞书知识库 FAQ 条目 🤖自动化（AI 汇总工单）
8 月度台账对账：申请数与发放数一致、补齐数量/价格/序列号 IT 运维/网管 每月 5 日前 多维表格 对账记录 🔧+🤖

5. 交付物与模板

  • 交付物：IT 资产台账；运维工单记录；新机初始化清单；标准安装脚本（Mac/Windows）；IT 支持 FAQ；厂商联系人清单
  • 建议模板/表单：领用单（申请人、部门、资产类型、型号/规格、数量、用途、期限、审批人、发放人、资产编号、发放日期）；报修单（资产编号、位置、现象、时间、截图、已尝试操作、紧急程度）；新机初始化清单（官方镜像重装或清理预装、系统更新、飞连安装登录、自动锁屏策略、开发工具与运行环境、证书、资产编号贴签）

6. 异常与升级

  • 升级条件：资产归口争议 2 个工作日未对齐、标准环境清单或领导端配置权限范围需定稿、台账连续两月不符、支持人员均不在 → IT 运维/网管升级 CTO 裁决；领用由部门负责人审批，其余工单由 IT 运维/网管直接处理
  • 影响客户演示或会议的设备故障 → 2 小时内现场处理，无法修复先提供替代设备（投屏/备用机）
  • 支持人员外派无人受理 → 后端兼运维为 B 角；仍无人时报 CTO 指派（4 个工作小时内）
  • 资产归口不清（行政配还是运维配、跨主体办公点设备） → IT 运维与行政 2 个工作日内对齐，CTO 裁决
  • 台账与实物不符 → 当月对账时追溯审批记录并更正，连续两月不符报 CTO
  • 员工数据疑似丢失 → 停止操作，先做数据保全，转 X-SEC-31 异常反馈

7. 衡量指标

  • 工单响应时长：目标 ≤ 4 个工作小时
  • 工单解决时长：一般问题 ≤ 2 个工作日
  • 台账账实相符率：月度对账，目标 ≥ 98%
  • 新机初始化时长：到货到可用，目标 ≤ 1 个工作日
  • 群内点名求助转工单比例：目标逐月提升，≥ 80%

8. 低效诊断

  • 现象：软件安装、领导端配置靠临时点名或私下拜托，谁负责装机不固定｜依据：「鼎慧产研决策部」2026-01、「模态AI探索小分队」2026-03、「模态AI探索小分队」2026-04
  • 现象：新电脑预装软件和广告逐台处理，重装方式各不相同｜依据：「随便瞎聊啦～」2026-08
  • 现象：终端故障无报修入口，厂商群成员都找不到，同类系统崩溃多次出现｜依据：「鸽子群模态分群」2026-07、「鸽子群模态分群」2026-08
  • 现象：AI 开发工具同类问题多人重复遇到，经验只在群里｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-08
  • 现象：安装失败处理命令在群里重复贴｜依据：「模态集团（全员群）」2026-05
  • 现象：会议室电视反复卡死，报修缺上下文、责任人不清｜依据：「公司全员群」2026-09
  • 现象：台账误填、自查发现“开始乱了”，显示器等设备归口在行政还是运维不明｜依据：「运维&综合对接群」2026-03、「运维&综合对接群」2026-06
  • 现象：非技术同事深夜或周末临时求助，支持依赖个别研发同事｜依据：「鸽子群模态分群」2026-03

9. 分支变体

  • 实体资产（电脑、显示器、外设、平板）/ 非实体资产（服务器、域名解析、开发者 AppID）
  • Mac / Windows / WSL：Mac 未签名安装包需按 FAQ 处理，正式签名到位后取消
  • 研发设备 vs 非技术同事设备：后者装机提供图文手册与一键脚本
  • 领导端：OpenClaw 等助手配置需单独清单，权限范围由 CTO 确认
  • 会议室设备：电视/投屏故障，行政协调场地，IT 处理设备
  • 跨主体办公点（模态空间等）：资产归属需先确认

10. 待确认问题

  • 主责是否为 IT 运维/网管？日常装机支持是否固定由运维/交付工程师承担？
  • 显示器、会议室电视等设备归口行政还是运维？
  • 新机初始化清单与标准开发环境由谁定稿？
  • “运维审批可以再敏捷一点”的诉求具体指哪个环节？是否取消部门负责人审批的小额领用？
  • 非技术同事 AI 工具支持是否设轮值？
X-SEC-31终端安全管控（飞连/IOA 部署、锁屏与保密规范）待优化200

状态：待优化｜证据：有证据（卡片 8 张 / 会话 6 个）｜优先级：频2 × 耗4 × 跨5 × 险5

  • 适用场景：为满足等保、研发代码合规与远程办公安全，需要选型采购终端管控/零信任产品、开通账号、下发管控策略，或执行电脑锁屏、重要文件保管、公司账号资产梳理等终端安全规范，以及管控策略引发员工数据异常时启动
  • 负责人：主责——IT 运维/网管（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，方案决策）、人事负责人（当前：黄莹·推断待确认，规范签署与入离职席位联动）、综合部负责人（当前：赵雪冰·推断待确认，公司账号资产梳理）、产品总监（当前：杨萌·推断待确认，规范适用范围）、运维/交付部署工程师（当前：游家豪·推断待确认，终端安装）、财务（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 明确合规目标与范围 → ② 选型对比与试用 → ③ 报价审批、合同与下单 → ④ 授权核对 → ⑤ IT 小范围灰度 → ⑥ 分批推广与账号开通 → ⑦ 策略执行（锁屏/白名单/IP 绑定）与检查 → ⑧ 异常反馈与厂商工单 → ⑨ 席位随入离职增减与季度审计
  • 交付结果：覆盖全员终端的管控部署；授权核对表；账号开通通知与使用教程；《终端安全与保密规范》（含锁屏、远程监护、重要文件保管）签署记录；公司账号资产表；季度终端审计报告
  • 状态依据：飞连已完成采购（授权 60 人，实际在用已超），保密与开源规范已于 2026-05 正式生效；但部署因 IT 人力不足多次延期，管控策略未灰度导致员工桌面文件被清除，锁屏规则只在群里口头宣布并反复点名，账号开通邮件缺登录入口

1. 场景判定

  • 触发条件：等保或代码合规要求；新终端管控产品引入或续费扩容；新员工需要管控账号；管控策略变更；员工安装客户端后出现文件丢失、iCloud 被关、系统崩溃；发现未锁屏、文档被篡改；梳理公司数字账号资产
  • 典型说法：「IOA、飞连、CI/CD 都得加速搞了」「你邮件里就塞了个密码，没告诉去哪登录」「安装后桌面文件都被删除了，怎样能避免」「离开自己电脑务必锁屏」「发个通告让开发都设置锁屏密码」
  • 判断问题：这件事是否涉及“对员工终端施加统一管控”或“终端安全规范的执行”？只是单台电脑坏了走 X-SEC-30
  • 不归本流程管：远程访问使用 → 请走 X-SEC-25；单台设备故障与装机 → 请走 X-SEC-30；凭据分发与保管 → 请走 X-SEC-10；保密与开源规范的起草评审 → 请走 LEG-27；代码外泄事件 → 请走 LEG-31；等保测评与整改 → 请走 X-SEC-43；违规处罚认定 → 请走 HR-20

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维/网管 方案调研、试用测试、下单、授权核对、策略配置、灰度、厂商工单 R IT 运维/网管（当前：杨明学·推断待确认）
CTO 方案取舍、预算审批、催办渠道、合规结论 A CTO（当前：丁震宇·推断待确认）
人事负责人 规范签署、入离职通知 IT 增减席位 R（人事部分） 人事负责人（当前：黄莹·推断待确认）
综合部负责人 公司账号资产梳理与台账 R（账号资产） 综合部负责人（当前：赵雪冰·推断待确认）
产品总监 规范适用范围（全员）意见 C 产品总监（当前：杨萌·推断待确认）
运维/交付工程师 终端安装、现场协助 R 运维/交付部署工程师（当前：游家豪·推断待确认）
财务/法务 合同、付款、签约主体 C 财务（当前：待指定）；法务（当前：待指定）
厂商 授权开通、技术支持、工单 R（外部） 外部服务商
全员 安装客户端、遵守锁屏与保密规范 I/R 全员

3. 办之前请准备

  • 合规目标与覆盖范围（研发办公设备/非研发设备/个人设备/是否含子公司团队）
  • 方案对比材料（IOA、飞连、SSLVPN 等）与试用测试用例
  • 在职人数与未来 6 个月人数预估（定授权数）
  • 签约主体与渠道账号（需与付款主体一致）
  • 推广前：员工数据备份提示、各系统（Mac/Windows）策略差异说明

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 写方案文档：场景、对比、推荐、里程碑，CTO 拍板 IT 运维/网管、CTO 立项后 5 个工作日内 飞书文档、飞书项目 方案定稿 👤人工判断
2 申请试用并按测试用例清单小范围测试，记录结论 IT 运维/网管 试用期内（一般 2～4 周） 厂商测试用例、多维表格 测试报告 🔧飞书固化
3 按“需求清单+对比表”向渠道要报价，核对模块不重复；采购申请→合同→付款 IT 运维/网管、财务、法务 报价后 5 个工作日内完成审批 飞书审批（FIN-01、LEG-07） 合同与订单 🔧飞书固化
4 下单后核对授权数与模块（含 DLP、MDM），同步延迟超 1 小时找厂商 IT 运维/网管 下单当日 授权核对表 授权确认 🔧飞书固化
5 新策略先在 IT 与志愿者设备灰度（Mac、Windows 各至少 2 台），观察 ≥ 1 周，评估数据、同步盘、性能影响 IT 运维/网管 推广前 灰度记录 灰度结论 👤人工判断
6 分批推广：提前 2 个工作日通知（含备份提示、影响、回滚方式）；发开通邮件（登录入口、客户端下载、首次改密、教程链接） IT 运维/网管、运维/交付工程师 每批 ≤ 1 周 邮件模板、飞书知识库 覆盖记录 🔧+🤖
7 策略执行：强制自动锁屏（建议 ≤ 10 分钟）、软件白名单与统一安装、办公设备静态 IP 绑定；规范在入职时签署 IT 运维/网管、人事负责人 推广完成当周 管控后台、飞书审批 策略生效 🤖自动化
8 员工异常反馈走“终端异常反馈”表单；IT 4 个工作小时内响应，必要时回滚策略并提厂商工单 IT 运维/网管 如左 飞书表单、厂商工单 处理记录 🔧飞书固化
9 席位随入离职增减；每季度审计覆盖率、授权余量、违规次数并报 CTO IT 运维/网管、人事负责人 入离职当日；每季度首月 多维表格 审计报告 🔧+🤖
10 公司数字账号资产统一登记，密码进入密码库，禁止私信或群发密码 综合部负责人 每半年复核 账号资产表、密码库 账号台账 🔧飞书固化

5. 交付物与模板

  • 交付物：方案文档；测试报告；采购合同；授权核对表；开通邮件模板与使用教程；《终端安全与保密规范》及签署记录；终端覆盖与审计报告；公司账号资产表
  • 建议模板/表单：授权核对表（产品、模块、授权数、已用数、到期日、签约主体、渠道联系人）；开通邮件模板（账号、登录入口、客户端下载、首次改密、常见问题、IT 联系方式，不在邮件正文放长期密码）；终端异常反馈（设备、系统、客户端版本、现象、发生时间、受影响数据、是否已备份）

6. 异常与升级

  • 管控策略导致员工数据丢失或系统崩溃 → IT 立即暂停该策略并协助数据恢复，2 小时内提厂商工单，当日报 CTO；3 个工作日内复盘
  • 渠道报价/授权拖延超过 1 周 → CTO 直接对接渠道负责人
  • 授权不足（在用超过购买数） → IT 当周提交扩容审批
  • 发现未锁屏或文档被篡改 → 按规范记录，打开文档版本记录追溯；处罚认定按 HR-20，不在群内点名处理
  • 部署因人力延期 → IT 提前说明并报 CTO 调整里程碑或调配人手

7. 衡量指标

  • 终端覆盖率：已安装管控的在职员工设备/应覆盖设备，目标 100%
  • 授权余量：授权数 - 在用数 ≥ 0，每月核对
  • 策略变更前通知率：目标 100%
  • 管控导致数据丢失事故：目标 0
  • 自动锁屏策略覆盖率：目标 100%
  • 保密规范签署率：老员工按期、新员工入职一个月内，目标 100%

8. 低效诊断

  • 现象：文档被篡改、电脑被他人使用后才定锁屏规则，规则仅口头宣布，此后多次在群里点名，无技术强制｜依据：「鸽子群模态分群」2026-01、「模态集团（全员群）」2026-01、「模态集团（全员群）」2026-02、「⭐大模型基座事业群」2026-03
  • 现象：账号开通邮件只放密码，没写登录入口和客户端下载，使用教程缺失｜依据：「鸽子群模态分群」2026-04
  • 现象：渠道报价反复催问、报价有误需删重复模块，渠道账号需与签约主体一致，约 10 次来回｜依据：「忠橙星行星引擎」2026-03
  • 现象：授权审批由厂商推进，模块突然锁定、合同到账核对反复｜依据：「模态跃迁--飞连沟通」2026-03
  • 现象：全员覆盖计划因 IT 人力不足一再延期｜依据：「忠橙星行星引擎」2026-05
  • 现象：管控策略未灰度，员工桌面文件被清除，事后才提工单｜依据：「模态跃迁--飞连沟通」2026-07、「鸽子群模态分群」2026-07
  • 现象：公司账号资产梳理要求私信密码，规范适用范围（研发还是全员）口径不一｜依据：「【模态】业务负责人」2026-04

9. 分支变体

  • 研发办公设备：IOA（代码合规）+ 飞连；非研发设备与研发个人设备：飞连；部分子公司团队暂不纳入（待确认）
  • SSLVPN / 防火墙方案：参考《公司内网接入设备选型》
  • Mac / Windows：同步盘（iCloud）管控、系统更新策略不同，分别灰度
  • 规范：远程控制电脑须有监护人或自担后果；重要文件按个人权责范围保管；规范对全员适用
  • 公司数字账号资产：统一入表，凭据入密码库，按 X-SEC-10 分发

10. 待确认问题

  • 主责是否为 IT 运维/网管？兜底是 CTO 还是 CEO？
  • IOA 与飞连的覆盖边界是否已最终确定？哪些团队不纳入？
  • 自动锁屏时长定多少？未锁屏的处理口径是否写入制度，由谁认定？
  • 管控策略灰度期 1 周是否足够？谁有权批准全员推广？
  • 公司账号资产表由综合部还是 IT 维护？是否已选定密码库工具？
X-SEC-32大会/活动现场网络与设备保障待优化128

状态：待优化｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗4 × 跨4 × 险4

  • 适用场景：公司举办生态大会、发布会、比赛等大型线下活动，各展区、大赛区、直播区、签到区需要网络、电脑、显示器等 IT 保障时启动，从需求征集一直覆盖到撤场回收
  • 负责人：主责——IT 运维（当前：杨明学·推断待确认）；协同——运维/交付部署工程师（当前：游家豪·推断待确认）、各展区负责人（当前：待指定）、大会会务负责人（当前：待指定）；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 表单征集需求 → ② 汇总核对库存 → ③ 与场地/运营商/直播方确认布线与分网 → ④ 需求冻结 → ⑤ 备货贴标与搬运布设 → ⑥ 现场测速 → ⑦ 现场值守 → ⑧ 撤场回收
  • 交付结果：冻结版设备与网络需求清单、布线与分网方案、开场前测速记录、设备出库与回收记录
  • 状态依据：已有设备清单 wiki，并由 IT 运维统一征集和制表，但 2026-05 大会筹备中单个展区需求从 4 台变 5 台再变 7 台、显示器键鼠追加，反复确认约 5 次；直播网络对接方位置不明；会场 3 个同名 WiFi 导致断流到现场才发现

1. 场景判定

  • 触发条件：大会/活动立项并确定场地与分区布局后；最迟在活动前 10 个工作日启动
  • 典型说法：「网络方面的各部门有需求的请汇总给我」「具体是什么机器?」「鉴于你们区需求变化过快，今天再次确认一下实际硬件需求」「注意检查设备实际的网络速率」
  • 判断问题：活动现场是否需要公司提供网络、电脑、显示器或直播推流链路？是否有两个以上区域同时用网？
  • 不归本流程管：大会总体方案与任务分工 → 请走 ECO-16、ECO-17；展区演示机借用、装机、彩排 → 请走 ECO-21；交付侧样机外借 → 请走 X-DLV-05；活动物料 → 请走 ECO-20；公司日常办公网络故障 → 请走 X-SEC-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 征集与汇总需求、布线分网方案、现场测速与值守 R/A IT 运维（当前：杨明学·推断待确认）
运维/交付部署工程师 设备核对、装机自检、贴标、搬运、回收清点 R 运维/交付部署工程师（当前：游家豪·推断待确认）
各展区负责人 按表单填报机型、数量、用途，冻结后不随意变更 R 各展区负责人（当前：待指定）
大会会务负责人 对接场地方、直播团队，批准冻结后的变更 R（变更审批） 大会会务负责人（当前：待指定）
CTO 设备缺口采购拍板、硬件调配冲突裁决 C CTO（当前：丁震宇·推断待确认）
场地方/运营商/直播团队（外部） 布线、带宽、直播推流链路 C 外部对接人

3. 办之前请准备

  • 活动日期、场地平面图、分区方案（展区/大赛区/直播区/签到区）及各区负责人名单
  • 场地网络条件：运营商、可用带宽、AP 布点、是否允许自建 SSID、有线点位
  • 直播团队对接人、推流码率与上行带宽要求
  • 公司可调用设备库存（从资产台账导出，见 X-DLV-03、ADM-27）
  • 往届活动的设备清单与测速记录（如有）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发布需求征集表单（区域、用途、电脑机型/数量、显示器、键鼠、有线/无线、带宽、是否直播/比赛、负责人） IT 运维 活动前 10 个工作日 飞书多维表格表单 需求表 🔧飞书固化
2 各区填报，写清具体机型与用途，只在表单内修改 各展区负责人 发布后 2 个工作日内 多维表格 填报记录 🔧飞书固化
3 汇总核对，与库存比对，缺口走借用/采购 IT 运维 填报截止后 1 个工作日内 多维表格+资产台账 设备清单 v1、缺口清单 🔧+🤖
4 与场地方、运营商、会务确认布线；直播链路独立，确认直播团队对接位置 IT 运维、大会会务负责人 活动前 7 个工作日 飞书会议 布线与分网方案 👤人工判断
5 需求冻结；冻结后变更须在表内提变更并经会务负责人批准 大会会务负责人 活动前 5 个工作日 多维表格 冻结版清单 🔧飞书固化
6 设备备货、按区域编号贴标、装机自检、装箱 运维/交付部署工程师 活动前 2 个工作日 资产台账 出库记录 🔧飞书固化
7 统一搬运布设；SSID 按区域唯一命名，直播/比赛网段隔离 IT 运维、运维/交付部署工程师 活动前 1 天 — 布设照片、SSID 表 👤人工判断
8 现场测速：每区有线/无线上下行实测，直播链路压测，记录结果 IT 运维 布设当天 + 开场前 2 小时复测 测速工具 测速记录 🤖自动化
9 现场值守，处理断网、设备故障 IT 运维 故障 10 分钟内响应 值守群 故障记录 👤人工判断
10 撤场回收清点，更新台账，登记缺损 运维/交付部署工程师 活动结束后 1 个工作日内 资产台账 回收记录 🔧飞书固化

5. 交付物与模板

  • 交付物：冻结版设备与网络需求清单、布线与分网方案、SSID 对照表、测速记录、出库/回收记录
  • 建议模板/表单：
    • 需求表字段：区域、负责人、用途、机型、数量、显示器/键鼠/转接线、有线点位数、无线终端数、带宽要求、是否直播/比赛、状态（草稿/冻结/变更）、变更原因
    • 测速记录字段：区域、SSID/网口、测试时间、下行、上行、延迟、是否达标、测试人
    • 现场检查清单：同名 SSID 排查、直播链路独立、备用 4G/5G 链路、电源与插排、设备编号与区域对应

6. 异常与升级

  • 冻结后新增设备 → 评估库存，会务负责人批准后执行 → 库存不足升级 CTO（当天）
  • 现场同名 WiFi/信号干扰 → 关闭或改名非必要 SSID，终端改连指定 SSID → 场地方配合（30 分钟内）
  • 直播推流卡顿 → 切换备用链路，暂停非必要设备占用 → 升级大会会务负责人和直播团队（5 分钟内）
  • 设备缺口 → 走借用（ADM-28）或临时采购（ADM-24） → 升级 CTO（活动前 3 个工作日内）
  • 回收发现丢失/损坏 → 登记资产台账并说明原因 → 行政负责人（1 个工作日内）

7. 衡量指标

  • 冻结后变更次数：每个区域冻结后变更次数，目标 ≤ 1 次
  • 开场前测速达标率：达标区域数 / 总区域数，目标 100%
  • 现场网络中断：开场期间中断次数，目标 0 次，累计不超过 5 分钟
  • 设备回收完整率：回收数 / 出库数，目标 100%

8. 低效诊断

  • 现象：需求征集在群里接龙、只报数量不报机型，IT 需反复追问「具体是什么机器」｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：无需求冻结点，单个展区需求连续变更约 5 次，导致反复制表与确认｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：直播网络需外部直播团队对接，但对接人和位置不明｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：缺开场前测速与 SSID 排查清单，同名 WiFi 导致断流到现场才发现｜依据：「跃迁生态大会筹备群」2026-05
  • 现象：多类硬件混放，需额外提醒避免搞混，缺编号贴标环节｜依据：「跃迁生态大会筹备群」2026-05

9. 分支变体

  • 展区：演示机为主，有线优先，需与演示场景准备（ECO-19）对齐机型
  • 大赛区：参赛设备集中，网段独立，避免与直播和展区争用带宽
  • 直播区：独立专线或独立 SSID，禁止其他设备接入，配备用链路
  • 签到区：以无线和扫码设备为主，需提前测试签到系统连通性
  • 外部场地与公司内部场地：外部场地以场地方网络为主，需提前取得网络说明书

10. 待确认问题

  • 活动网络与设备保障的主责是否为 IT 运维？与 ECO-21、X-DLV-06 的边界是否按“网络与 IT 设备归本流程，演示内容与装机归 ECO-21”划分？
  • 需求冻结点定在活动前 5 个工作日是否可行？冻结后变更由谁批准？
  • 直播网络由场地方、运营商还是外部直播团队负责？
  • 是否需要常备 4G/5G 备用链路设备？
  • 设备清单 wiki 是否改为多维表格并沿用到后续活动？
X-SEC-33飞书自建应用/机器人/CLI 权限申请审批与停用待优化144

状态：待优化｜证据：有证据（卡片 17 张 / 会话 18 个）｜优先级：频4 × 耗3 × 跨3 × 险4

  • 适用场景：员工为自建飞书应用、机器人、飞书 CLI（含 LeapCore 内 Lark-CLI 授权）申请开放平台权限、发布新版本、调整可见范围或配置登录回调，以及停用不再使用的应用、智能体时启动
  • 负责人：主责——飞书应用审核管理员（当前：丁震宇·推断待确认）；协同——飞书管理员/人事负责人（当前：黄莹·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、应用申请人；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 对照权限分级表自检 → ② 规范命名后在开放平台提审并登记用途 → ③ 机器人通知审核人 → ④ 按风险等级审核（超时转备份）→ ⑤ 发版生效与授权验证 → ⑥ 登记应用台账 → ⑦ 季度盘点与停用
  • 交付结果：审核通过并已发版的应用版本、应用权限台账记录（owner、scope 等级、用途、可见范围、到期日、状态）、停用记录
  • 状态依据：已有飞书开放平台提审和“应用使用申请”审批，但审核人单点、系统默认提醒到人事、移动端无法审批、无权限分级与命名规范；2026-02～10 群内催审、问“谁来批”超过 30 次；2026-03 发生一次约 300 项权限被误批事故，之后才口头规定机器人权限统一由技术侧审批

1. 场景判定

  • 触发条件：新建应用/机器人；新增 scope（通讯录、群消息、云文档、日历、任务、文件上传等）；改可见范围；新环境需加登录回调地址；机器人提示缺少 scope 或“需管理员开启”；应用/智能体不再使用需停用；申请使用某第三方应用
  • 典型说法：「你没提审 你先提审我才能批」「改成仅你可用了」「需要申请权限才能继续」「机器人审批能不能换个人」「通过下」
  • 判断问题：这件事是否需要飞书租户管理员在开放平台或管理后台点“通过/停用/改范围”？
  • 不归本流程管：机器人/Agent 上线前安全测试与高危操作确认 → 请走 X-SEC-37；用 CLI 导出聊天记录或业务数据 → 请走 X-SEC-35；飞书席位、功能配置、第三方应用入口、Aily 额度 → 请走 X-SEC-34；内部系统接飞书 SSO 的方案 → 请走 X-SEC-05；飞书组织架构与审批人维护 → 请走 HR-02；云厂商子账号权限 → 请走 X-SEC-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
应用申请人（owner） 自检 scope、规范命名、提审、发版、验证、到期续用或停用 R 应用申请人（研发/产品）
飞书应用审核管理员 按等级审核、调整可见范围、配置回调、执行停用、维护台账 R/A 飞书应用审核管理员（当前：丁震宇·推断待确认）
备份审核人 主审核人超时或休假时代审 L1/L2 R 备份审核人（当前：待指定）
飞书管理员（人事） 收到默认提醒后转交，不直接审批机器人/高危权限 C 飞书管理员/人事负责人（当前：黄莹·推断待确认）
研发运维 scope 定位、发版与授权问题指导 C 研发运维（当前：宋祺睿·推断待确认）
飞书超级管理员 管理员名单与角色分配、最终兜底 A（升级） 飞书超级管理员/CEO（当前：邴龙志·推断待确认）
全员 接收管理员名单与规则公告 I 全员

3. 办之前请准备

  • 应用名称：「owner 简称 + 用途」，能看出归属，不使用“飞书CLI”“机器人”等通用名
  • 用途说明、使用范围（仅本人/指定群/全员）、身份类型（user 身份或 tenant 身份）
  • scope 清单与对应功能，一次提全；对照权限分级表标注等级
  • 回调/重定向地址及环境（测试/生产）
  • 有效期：测试类默认 30 天
  • 若机器人要进群或具备执行能力：先完成 X-SEC-37 上线检查
  • 权限分级参考：L1 低——发消息到所在群、消息卡片、已授权多维表格读写；L2 中——授权范围内云文档读写、日历、任务、文件上传；L3 高——通讯录、读取群聊历史/私聊、全量云盘读写、会议与妙记、搜索成员、全员可见的 tenant 身份应用

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照权限分级表自检，删除不需要的 scope 应用申请人 提审前 权限分级表、scope 扫描脚本 最小 scope 清单 🤖自动化
2 在开放平台创建版本并提审；同时提交“应用权限申请”登记用途、范围、有效期 应用申请人 当天 开放平台+飞书审批 提审单 🔧飞书固化
3 机器人把待审事项推送给审核人（不再默认推送人事） 系统 即时 飞书机器人 待办提醒 🔧+🤖
4 分级审核：L1/L2 核对用途与范围；L3 必须人工逐项审，必要时要求先过 X-SEC-37 飞书应用审核管理员 L1/L2 1 个工作日内，L3 2 个工作日内 管理后台（电脑端） 通过/驳回意见 👤人工判断
5 超时转交：L1/L2 超 1 个工作日未处理自动转备份审核人 系统、备份审核人 超时后 1 个工作日内 飞书审批 代审记录 🔧飞书固化
6 发版生效、完成用户授权、验证功能 应用申请人 通过后 1 个工作日内 开放平台 验证结果 👤人工判断
7 回调地址、可见范围变更 飞书应用审核管理员 提前 2 个工作日申请，提交后 1 个工作日内完成 管理后台 回调登记表更新 👤人工判断
8 登记应用台账 飞书应用审核管理员 通过当天 多维表格（审批自动同步） 台账记录 🔧+🤖
9 季度盘点：到期或 90 天无调用的应用通知 owner 续用或停用 飞书应用审核管理员 每季度首月 10 日前 多维表格提醒 盘点结果 🔧+🤖
10 停用：owner 或部门负责人提停用申请，管理员在管理后台按应用 ID 停用；aily 智能体在 aily 管理后台关闭 飞书应用审核管理员 提交后 2 个工作日内 管理后台、aily 后台 停用记录 👤人工判断

5. 交付物与模板

  • 交付物：已发版应用、应用权限台账、权限分级表、回调登记表、停用记录、管理员名单公告
  • 建议模板/表单：
    • 应用权限申请单字段：应用名称、App ID、owner、部门、用途、身份类型、可见范围、申请 scope（勾选+等级）、环境、回调地址、有效期、是否已过 X-SEC-37
    • 应用台账字段：App ID、名称、owner、最高 scope 等级、可见范围、上线日期、到期日、状态（测试/使用中/停用）、最近盘点日期
    • 回调登记表字段：环境、域名、回调地址、对应应用、申请人、登记日期

6. 异常与升级

  • 升级条件：主审核人与备份审核人均超时、需调整管理员名单或角色分配、对 L3 权限是否放行有争议 → 飞书应用审核管理员升级飞书超级管理员拍板；L1～L3 的常规审核由飞书应用审核管理员直接决定
  • 误加大量权限且已被通过 → 立即停用该版本，owner 按最小权限重建 → 升级 CTO（当天），涉及凭据按 X-SEC-11 处理
  • 审核通过仍提示无权限 → 检查是否已发版、是否完成用户身份授权、可见范围是否包含使用人 → 研发运维（半个工作日内）
  • 审核人超时 → 自动转备份审核人 → 再超 1 个工作日升级飞书超级管理员
  • 审批默认推到人事 → 人事直接转交审核管理员，不审批机器人/高危权限 → 当天转交
  • 新入职人员没有应用权限（可见范围未刷新）→ 管理员刷新可见范围 → 1 个工作日内
  • 节假日前集中提审 → 假期前 2 个工作日截止，假期内只处理生产阻断事项

7. 衡量指标

  • 审核时长：提审到通过，L1/L2 ≤ 1 个工作日，L3 ≤ 2 个工作日
  • 催审次数：群内/私下催审次数，目标每月 ≤ 2 次
  • 台账覆盖率：已登记应用 / 租户内自建应用总数，目标 100%
  • 季度盘点停用率：盘点后停用的闲置应用数，持续跟踪；高危 scope 应用占比逐季下降

8. 低效诊断

  • 现象：审核人单点，移动端无法审批、后台无提醒，全靠群里 @ 催｜依据：「鼎慧产研决策部」2026-02、「鼎慧产研决策部」2026-04、「鼎慧产研决策部」2026-06
  • 现象：系统默认把机器人权限提醒到人事，非技术岗审批技术权限，出现一次约 300 项权限被通过的事故｜依据：「鼎慧产研决策部」2026-03、「模态人事大主管」2026-03
  • 现象：应用命名无规范，审核环节看不出应用归属，需改名重提｜依据：「鸽子群模态分群」2026-03、「鼎慧产研决策部」2026-04
  • 现象：权限范围“全开”与“最小”口径不一，无 scope 与功能映射表，开通后仍反复试错｜依据：「鼎慧产研决策部」2026-04、「跃迁AI总动员」2026-06
  • 现象：机器人提示缺 scope 后无人跟进，使用者直接放弃｜依据：「随便瞎聊啦～」2026-03、「随便瞎聊啦～」2026-04
  • 现象：谁是飞书管理员说法不一｜依据：「模态集团（全员群）」2026-05
  • 现象：机器人各写各的、申请入口靠问，无统一开发与申请规范｜依据：「鸽子群模态分群」2026-01

9. 分支变体

  • 个人助理型机器人：仅本人可见，通常 L1/L2，走快速审核
  • 群共用机器人：须先完成 X-SEC-37 上线检查，可见范围限定到指定群
  • CLI：user 身份（授权的是本人权限，同机 Claude/Codex 可复用）与 tenant 身份（应用身份，按 L3 审）
  • LeapCore 内 Lark-CLI 授权：按 user 身份处理，由使用人本人授权
  • 测试环境应用：有效期 30 天，到期自动提醒；测试“无权限”场景需提前告知审核人
  • 停用：自建应用、aily 智能体（关注费用额度）、第三方应用分别在对应后台操作

10. 待确认问题

  • 飞书应用审核管理员是否继续由 CTO 担任？备份审核人由谁担任？
  • 能否在开放平台把机器人权限默认审核人从人事改为技术侧？
  • L1 权限是否可设为自动通过或免审？测试应用 30 天有效期是否可行？
  • 2026-03 “机器人权限统一找技术侧审批”的口头规定是否需成文发布？
  • 应用停用由审核管理员还是飞书管理员（人事）执行？
X-SEC-34飞书平台管理员事项（席位、功能配置、可见范围、外部分享、Aily）待优化120

状态：待优化｜证据：有证据（卡片 7 张 / 会话 8 个）｜优先级：频4 × 耗2 × 跨5 × 险3

  • 适用场景：员工遇到飞书功能或权限配置问题、需要管理员后台操作时启动，包括席位增购与开票、审批流/知识库/会议室配置、第三方应用可见范围、跨组织分享、Aily/AI 额度与管理员角色分配，以及需要找飞书服务商顾问的情况
  • 负责人：主责——飞书管理员（当前：丁震宇·推断待确认）；协同——人事负责人（当前：黄莹·推断待确认）、财务负责人（当前：黄梦婷·推断待确认）、综合部负责人（当前：赵雪冰·推断待确认）、行政负责人（当前：胡则瑾·推断待确认）、飞书服务商顾问（外部）；兜底——飞书超级管理员/CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 查内部飞书 FAQ → ② 提交“飞书管理员事项”工单 → ③ 管理员分类派单 → ④ 后台配置/统一咨询顾问/采购 → ⑤ 回复关单 → ⑥ 共性问题沉淀 FAQ → ⑦ 季度复核管理员角色与席位
  • 交付结果：完成的后台配置或席位订单与发票、工单记录、更新后的内部飞书 FAQ、管理员角色清单
  • 状态依据：已有飞书服务商外部群和管理后台，但审批条件分支、知识库权限、纪要丢失、CLI 失效等同类问题 2026-01～09 分散在多个群提问约 25 次；管理员名单说不清；AI 管理权限归属不明；豆包入口 2026-07～08 反复干扰无人统一治理；席位增购需管理员、财务、人事多方接力，后台角色未预先分配

1. 场景判定

  • 触发条件：功能突然不可用（如无法创建知识库）；需要配置审批流、会议室、多维表格自动化；需要增购席位或开票；出现不希望的第三方应用入口；需要跨组织分享文档；需要 Aily/AI 额度或 AI 管理角色
  • 典型说法：「敢问我司至高无上的管理员是谁？」「我为什么不能创建知识库了」「流程审批可以设置当金额大于多少时再加一级审批人吗」「那我文档还是只能一个个分享出去」「现在一不小心就走豆包」
  • 判断问题：这个问题是否需要飞书管理后台权限或找飞书服务商才能解决？
  • 不归本流程管：自建应用/机器人/CLI 权限 → 请走 X-SEC-33；飞书组织架构与审批人调整 → 请走 HR-02；新人账号开通 → 请走 X-SEC-01；知识库空间内容治理 → 请走 GEN-12；AI 工具订阅 → 请走 GEN-09；会议室日常预约 → 请走 ADM-05

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 查 FAQ、提工单、提供截图与期望结果 R 各部门员工
飞书管理员 分类派单、后台配置、可见范围与外部分享策略、统一对接服务商 R/A 飞书管理员（当前：丁震宇·推断待确认）
人事负责人 席位用量监控、入离职席位调配、人事类审批流配置 R 人事负责人（当前：黄莹·推断待确认）
财务负责人 席位订单付款、费用中心开票、财务类审批流需求 R 财务负责人（当前：黄梦婷·推断待确认）
综合部负责人 Aily/AI 额度使用规划与台账 C 综合部负责人（当前：赵雪冰·推断待确认）
行政负责人 会议室配置需求与维护 R（会议室） 行政负责人（当前：胡则瑾·推断待确认）
飞书服务商顾问 操作路径、复杂配置与故障支持 C 外部顾问
飞书超级管理员 管理员角色分配、最终兜底 A（升级） 飞书超级管理员/CEO（当前：邴龙志·推断待确认）

3. 办之前请准备

  • 问题截图、使用端（PC/移动）、期望结果、影响人数
  • 席位类：当前用量、预计入职人数与到岗日、待清理离职名单、付款主体
  • 跨组织分享类：对方组织名称、文档或知识库范围、权限级别、到期日
  • Aily/AI 类：用途、预计用量、计费方式（搭建一次性计点或按次计费）
  • 审批流配置类：审批节点、条件分支（如金额阈值）、生效日期、业务负责人确认

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 先查内部飞书 FAQ，或用 AI 助手检索飞书帮助中心 申请人 提单前 飞书 wiki、AI 助手 自助解决或确认需提单 🤖自动化
2 提交工单（类别、描述、截图、紧急度） 申请人 当天 多维表格表单 工单 🔧飞书固化
3 分类派单：咨询/后台配置/需顾问/采购 飞书管理员 1 个工作日内 多维表格 派单记录 🔧+👤
4 后台配置：审批流条件分支、知识库创建权限、会议室、可见范围、外部分享、Aily 角色 飞书管理员或对应角色管理员 派单后 2 个工作日内 管理后台 配置结果 👤人工判断
5 需顾问支持的事项由管理员或授权对接人统一在服务商群提问，不由各员工分散提问 飞书管理员 派单后 1 个工作日内 服务商群 顾问答复 👤人工判断
6 席位：用量 ≥ 90% 自动预警 → 人事汇总入离职 → 管理员后台下单 → 财务付款 → 到账开通 → 有费用中心权限者开票交财务 人事负责人、飞书管理员、财务负责人 预警后 3 个工作日内下单；付款 2 个工作日内；到账后 5 个工作日内开票 管理后台、飞书付款审批 订单、付款凭证、发票 🔧飞书固化
7 离职人员当天停用账号释放席位 人事负责人 离职当天 管理后台 释放记录 👤人工判断
8 第三方/官方新入口准入：评估后设可见范围并公告 飞书管理员 发现后 2 个工作日内 管理后台 可见范围设置、公告 👤人工判断
9 回复申请人并关单；共性问题写入 FAQ 飞书管理员 处理完成当天 飞书 wiki FAQ 条目 🤖自动化
10 季度复核管理员角色清单与席位用量 飞书超级管理员 每季度首月 管理后台 角色清单 👤人工判断

5. 交付物与模板

  • 交付物：工单记录、配置结果、席位订单/付款/发票、内部飞书 FAQ、管理员角色清单、第三方应用准入清单
  • 建议模板/表单：
    • 管理员角色清单字段：角色（超级管理员/应用管理员/费用中心/审批管理员/AI 用量管理/会议室管理）、权限范围、主责、备份、授予日期
    • 工单字段：提交人、类别、描述、截图、紧急度、处理人、状态、处理结果、是否入 FAQ
    • 席位台账字段：总席位、已用、预警阈值、订单号、金额、付款状态、发票状态、开通日期
    • FAQ 条目字段：问题、适用端、操作路径、所需权限、更新时间

6. 异常与升级

  • 升级条件：管理员角色分配（如费用中心、AI 用量管理）、第三方入口改范围后仍反复出现、季度角色复核发现越权 → 飞书管理员升级飞书超级管理员处理；其余后台配置由飞书管理员直接决定
  • 席位已满、新人到岗无法登录 → 先释放离职席位或临时调配 → 升级飞书管理员（当天）
  • 无人有费用中心权限无法开票 → 超级管理员为财务分配对应角色 → 1 个工作日内
  • 会议纪要丢失 → 管理员联系服务商顾问排查恢复 → 当天
  • 跨组织分享无法继承父权限（关联组织需双方商业版）→ 改用共享知识库空间或逐个授权 → 飞书管理员（2 个工作日内）
  • 第三方 AI 入口改范围后仍出现 → 汇总入口位置提交服务商 → 升级飞书超级管理员（1 周内）
  • 审批流改动影响财务/人事流程 → 变更前由业务负责人确认并在测试审批中验证 → 未确认不上线

7. 衡量指标

  • 工单首次响应时长：提交到派单，目标 ≤ 1 个工作日
  • 工单解决时长：提交到关单，目标 ≤ 3 个工作日
  • 重复咨询率：同类问题二次提单数 / 总工单数，目标 ≤ 10%
  • 新人到岗当天飞书可用率：目标 100%
  • 席位预警到开通时长：目标 ≤ 5 个工作日

8. 低效诊断

  • 现象：同类配置问题多人在多个服务商群分散提问，内部无 FAQ，事后被提醒“不在这个群问”｜依据：「模态跃迁 - HR/行政飞书咨询群」2026-04、「模态跃迁 - HR/行政飞书咨询群」2026-09、「模态-飞书」2026-05
  • 现象：管理员身份说法不一，员工功能受限后不知道找谁｜依据：「模态集团（全员群）」2026-05、「模态跃迁-字字可研项目-飞书客服群」2026-05
  • 现象：AI 管理权限归属不清，曾配置过但无记录，需重新问服务商｜依据：「董事会专项沟通群」2026-05
  • 现象：第三方 AI 入口无准入规则，改了可见范围后新入口继续出现｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-08、「模态-飞书」2026-07
  • 现象：跨组织分享规则未沉淀，只能逐个开权限｜依据：「鼎慧产研决策部」2026-01

9. 分支变体

  • 席位增购：协同财务付款与开票，人事负责席位用量
  • 第三方应用入口（如豆包）：按准入清单统一设可见范围
  • 跨组织分享：关联组织需双方商业版；组织外分享不继承父权限，建议改用共享知识库
  • Aily 智能体：搭建一次性计点与按次计费两种口径，需纳入额度台账
  • 审批流配置、会议室、知识库创建权限：分别由人事、行政、管理员按角色处理

10. 待确认问题

  • 飞书管理员主责是否继续由 CTO 担任，还是转到综合部？是否需要专人统一对接服务商？
  • 席位预警阈值 90% 是否合适？财务是否开通费用中心角色？
  • 内部飞书 FAQ 由谁维护、放在哪个知识库？
  • Aily/AI 额度归哪个部门管理？是否需要月度用量报告？
  • 第三方应用准入清单由谁拍板？
X-SEC-35敏感数据导出与 AI 分析授权（聊天记录/CRM/业务数据）待新建60

状态：待新建｜证据：有证据（卡片 4 张 / 会话 2 个）｜优先级：频2 × 耗2 × 跨3 × 险5

  • 适用场景：员工要批量导出飞书聊天记录（个人或群聊）做 AI 分析或分身 skill、导出 CRM/渠道等业务敏感数据，或让无人值守的自动任务读取飞书凭证时，先完成数据负责人确认和安全审批
  • 负责人：主责——CTO/信息安全审批人（当前：丁震宇·推断待确认）；协同——数据所属业务负责人（如销售负责人，当前：李鹏为·推断待确认）、CRM 管理员（当前：闫登辉·推断待确认）、法务负责人（当前：待指定）、人事负责人（当前：待指定）、研发运维（当前：宋祺睿·推断待确认）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 提交数据使用申请 → ② 按数据等级分级 → ③ 数据负责人确认 → ④ 安全审批（模型、存储、凭证）→ ⑤ 必要时法务意见 → ⑥ 按最小范围导出并脱敏 → ⑦ 约束使用与分享 → ⑧ 到期删除回填
  • 交付结果：审批通过的数据使用申请单、导出记录（范围、时间、存储位置、模型）、到期删除确认
  • 状态依据：无成文规则；2026-04 出现先用 CLI 拉取全量聊天并在群内分享 AI 人格分析、事后才讨论合规；2026-07 自动任务欲把 CLI 解密密钥降级为本地文件存储被叫停，公司无认可的后台授权方案；2026-09 CRM 渠道总表导出靠口头找业务负责人确认，无留痕

1. 场景判定

  • 触发条件：用 lark-cli 或脚本批量拉取群聊/私聊消息；把聊天或业务数据交给 AI 做总结、画像、skill；导出 CRM、渠道、客户、人事、财务数据表；部署需读取飞书凭证的 7x24 自动任务
  • 典型说法：「你这数据是安全的吗」「拉消息给Ai说不定什么时候就被卖了」「毕竟是销售敏感数据 老大得知情」「公司是否有认可的后台飞书授权方式？」
  • 判断问题：导出数据是否超出本人日常查看范围？是否含他人聊天、客户、渠道、人事、财务信息？是否会离开本机或送入外部模型？任一为“是”即走本流程
  • 不归本流程管：应用/CLI scope 审批 → 请走 X-SEC-33；向外部提供材料 → 请走 LEG-30；代码与机密外泄事件 → 请走 LEG-31；凭证泄露 → 请走 X-SEC-11；密钥日常保管 → 请走 X-SEC-10；业务系统账号开通 → 请走 X-SEC-03

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请人 填写申请、按批准范围导出、遵守使用约束、到期删除 R 申请人
CTO/信息安全审批人 定级、审批模型/存储/凭证方案、季度抽查 A CTO/信息安全审批人（当前：丁震宇·推断待确认）
数据所属业务负责人 确认业务数据可否导出及范围 R（确认） 销售负责人（当前：李鹏为·推断待确认）等
CRM 管理员 按批准范围执行 CRM 导出与脱敏 R CRM 管理员（当前：闫登辉·推断待确认）
法务负责人 涉及个人信息、客户数据的合规意见 C 法务负责人（当前：待指定）
人事负责人 涉及员工信息时确认，人事个案一律不入库 C 人事负责人（当前：待指定）
研发运维 无人值守任务的专用身份与密钥托管 R（凭证） 研发运维（当前：宋祺睿·推断待确认）

3. 办之前请准备

  • 数据类型与范围：哪些群/时间段、哪些 CRM 字段、是否含私聊
  • 用途：工作总结、知识问答、分身 skill、业务地图等，写清产出物
  • 处理方式：使用的模型（内部 NewAPI/本地模型/外部模型）、存储位置、是否加密、保存期限
  • 分享对象：成果给谁看，是否需脱敏
  • 无人值守任务：运行设备、身份类型、密钥存放方式
  • 数据分级参考：D1 个人——本人参与的工作群，仅本地本人使用；D2 团队——部门群、项目资料；D3 敏感——全公司群、私聊、客户/渠道/CRM、人事、财务；禁止——人事个案入库、对他人做人格画像并公开分享、上传到未经批准的外部模型

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交“敏感数据使用申请” 申请人 使用前 飞书审批 申请单 🔧飞书固化
2 按勾选的数据类型自动定级，D1 仅登记 系统 即时 飞书审批条件分支 等级 🔧+🤖
3 数据负责人确认（CRM→销售负责人；部门群→部门负责人；员工信息→人事负责人） 数据所属业务负责人 1 个工作日内 飞书审批 确认意见 👤人工判断
4 安全审批：模型来源、存储与加密、凭证方案、保存期限 CTO/信息安全审批人 1 个工作日内 飞书审批 审批意见 👤人工判断
5 D3 且含个人信息或客户数据时出法务意见 法务负责人 2 个工作日内 飞书审批 法务意见 👤人工判断
6 按批准范围导出：排除敏感群，手机号、证件号、金额等脱敏 申请人/CRM 管理员 批准后 导出脚本 导出文件、导出记录 🤖自动化
7 使用约束：原始数据不外传、不进群；成果分享前脱敏，不分享个人画像 申请人 使用期间 — 脱敏成果 👤人工判断
8 无人值守任务使用专用应用身份 + 最小 scope，密钥交公司统一托管，不降低钥匙串安全级别 申请人、研发运维 部署前 密钥管理方案 部署记录 🔧飞书固化
9 到期删除数据并在申请单回填 申请人 到期后 2 个工作日内 飞书审批 删除确认 🔧飞书固化
10 季度抽查导出记录与删除情况 CTO/信息安全审批人 每季度 多维表格 抽查结果 👤人工判断

5. 交付物与模板

  • 交付物：数据使用申请单、导出记录台账、删除确认、季度抽查结果
  • 建议模板/表单：
    • 申请单字段：申请人、数据类型（勾选）、范围（群/时间段/字段）、用途、产出物、模型、存储位置、是否加密、保存期限、分享对象、是否无人值守、数据负责人
    • 导出记录字段：申请单号、导出时间、数据量、脱敏方式、存储位置、到期日、删除日期

6. 异常与升级

  • 已未经审批导出或分享 → 立即停止使用、删除共享副本、补提申请 → 升级 CTO（当天）
  • 疑似数据外送外部模型或外泄 → 按 LEG-31 处置，涉及凭据按 X-SEC-11 → 升级 CTO 与法务（当天）
  • 数据负责人不在、事项紧急 → 不先导出，按 GEN-05 找其上级代审 → 1 个工作日内
  • 自动任务要求降低凭证安全级别才能运行 → 禁止，改为申请专用身份与密钥托管 → CTO 决策（2 个工作日内）

7. 衡量指标

  • 审批覆盖率：D2/D3 导出中有审批单的比例，目标 100%
  • 审批时长：提交到批准，目标 ≤ 2 个工作日
  • 到期删除确认率：目标 100%
  • 未授权导出事件：目标 0 次

8. 低效诊断

  • 现象：先用工具拉取全量聊天并分享 AI 分析，之后才讨论是否合规、要不要录屏｜依据：「鼎慧产研决策部」2026-04
  • 现象：数据用途、范围、存储没有规则，成员对隐私担忧只能在群里争论｜依据：「鼎慧产研决策部」2026-04
  • 现象：全量拉取约需 6 小时并持续消耗 token，成本无人评估｜依据：「鼎慧产研决策部」2026-04
  • 现象：无公司认可的后台授权方式、专用账号或密钥管理方案，自动任务迁移被迫暂停｜依据：「鼎慧产研决策部」2026-07
  • 现象：业务数据导出靠在群里口头找负责人确认，无表单留痕｜依据：「【模态】市场销售」2026-09

9. 分支变体

  • 个人聊天（D1/D2）：仅本人权限范围、仅本地，登记即可
  • 全公司群聊或私聊（D3）：须 CTO 审批，必要时法务意见，敏感群排除
  • CRM/渠道/客户数据（D3）：须业务负责人知情确认，由 CRM 管理员导出
  • 7x24 自动任务（如 Mac mini 执行端）：须专用身份与密钥托管，管理端与执行端分工写入申请
  • user 身份读取与 tenant 身份读取：tenant 身份按 D3 处理

10. 待确认问题

  • 敏感数据审批人是否为 CTO？是否需要设独立的信息安全负责人？
  • 数据分级 D1/D2/D3 的划分是否认可？哪些数据“一律禁止”？
  • 公司是否提供统一的密钥托管方案和自动任务专用飞书账号？
  • 法务在什么情形下必须参与？
  • 是否已有成文的聊天数据使用规范？
X-SEC-36新工具与高权限软件安全试用环境待新建48

状态：待新建｜证据：有证据（卡片 2 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨2 × 险4

  • 适用场景：需要试用 ClawLite、Hermes、龙虾（OpenClaw）等需要高系统权限或来源未审查的软件，或在本机运行 AI Agent（Claude Code 等）时，先申请隔离环境并按基线配置本机与备份
  • 负责人：主责——研发运维/云资源管理员（当前：宋祺睿·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，审批）、试用申请人；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 判定是否需隔离 → ② 提交试用环境申请 → ③ 审批 → ④ 开通云机/虚拟机/容器并配安全组 → ⑤ 凭据私发 → ⑥ 按 Agent 本机基线试用 → ⑦ 登记试用结论 → ⑧ 到期回收
  • 交付结果：带到期日的隔离测试环境、试用结论记录、回收记录；本机 Agent 配置基线与备份记录
  • 状态依据：2026-04 因成员不敢在工作电脑装测试软件，临时开云 Windows 机器，登录信息直接发在群里，安全组事后补配；同月本机运行 AI agent 致系统损坏、配置文件丢失，事故后才备份和设置 allow/deny

1. 场景判定

  • 触发条件：要安装需管理员/root 权限、可读写全盘、可自动执行命令或来源未审查的软件；要在本机给 AI Agent 开放 shell/文件权限
  • 典型说法：「不推荐在工作电脑上装测试软件」「是不是给权限太高了」「安全组得配下」
  • 判断问题：这个软件出问题时，会不会损坏工作电脑、读到公司密钥或代码？如果会，就走隔离环境
  • 不归本流程管：常规内网测试服务器、GPU、虚拟机 → 请走 X-SEC-17；正式云资源 → 请走 X-SEC-16；Agent 部署进群对他人开放 → 请走 X-SEC-37；采购实机做调研 → 请走 ADM-26；AI 工具订阅 → 请走 RND-25；新技术选型评估 → 请走 RND-15

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
试用申请人 判定、申请、按基线试用、登记结论、到期归还 R 试用申请人
研发运维/云资源管理员 开通隔离环境、配置安全组、发放凭据、到期回收 R 研发运维/云资源管理员（当前：宋祺睿·推断待确认）
CTO 审批高权限软件试用与云资源费用 A CTO（当前：丁震宇·推断待确认）
IT 终端支持 本机事故后的恢复协助 C IT 运维（当前：待指定）

3. 办之前请准备

  • 软件名称、版本、下载来源、所需权限（root/管理员、全盘读写、网络、自动执行）
  • 运行系统（Windows/Linux/macOS）、规格、需开放的端口
  • 试用目的与期限（默认 ≤ 14 天）
  • 本机运行 Agent 前：确认重要数据已备份到公司盘，准备 allow/deny 配置

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 对照判定清单确认是否必须隔离 试用申请人 安装前 判定清单 判定结果 👤人工判断
2 提交试用环境申请（软件、来源、权限、系统、规格、期限） 试用申请人 需要前 1 个工作日 飞书审批（非实体资产申领，见 ADM-34） 申请单 🔧飞书固化
3 审批 CTO 1 个工作日内 飞书审批 审批意见 👤人工判断
4 开通云轻量机/虚拟机/容器；安全组仅放行必要端口与来源 IP；打标签（申请人、到期日） 研发运维/云资源管理员 批准后 1 个工作日内 云控制台、开通脚本 测试环境 🔧+🤖
5 凭据通过密码管理工具或一次性私信发放，禁止发群 研发运维/云资源管理员 开通时 见 X-SEC-10 凭据交付记录 🔧飞书固化
6 本机运行 Agent 按基线配置：非 root、allow/deny 列表、禁读 .env 与密钥目录、优先容器运行、关键数据每日备份到公司盘 试用申请人 首次使用前 配置模板 基线配置 🤖自动化
7 登记试用结论（能否引入、风险点、建议） 试用申请人 到期前 多维表格 试用结论 👤人工判断
8 到期提醒并回收；续期需重新申请 研发运维/云资源管理员 到期日当天 机器人提醒、云控制台 回收记录 🔧+🤖

5. 交付物与模板

  • 交付物：试用环境申请单、测试环境、试用结论台账、回收记录、Agent 本机配置基线模板
  • 建议模板/表单：
    • 申请单字段：软件名称、版本、来源、所需权限、系统、规格、开放端口、用途、期限
    • 试用结论字段：软件、试用人、试用期、结论（引入/不引入/待定）、风险点、后续动作
    • Agent 本机基线：运行用户、allow/deny 命令列表、禁访目录、容器/沙箱方式、备份位置与频率

6. 异常与升级

  • 已在工作电脑装了高权限软件 → 卸载并断网检查，排查密钥是否被读取 → 按 X-SEC-11 处理，升级 CTO（当天）
  • Agent 误删数据或损坏系统 → 停止 Agent，从备份恢复 → IT 终端支持（X-SEC-30，当天）
  • 测试机疑似被入侵 → 销毁重建，排查横向影响 → 按 X-SEC-42 处理（当天）
  • 凭据被发到群里 → 立即修改凭据 → 研发运维（1 小时内）

7. 衡量指标

  • 隔离试用比例：高权限软件在隔离环境中试用的比例，目标 100%
  • 开通时长：批准到环境可用，目标 ≤ 1 个工作日
  • 到期回收率：目标 100%
  • 本机 Agent 事故数：目标每季度 0 次

8. 低效诊断

  • 现象：无测试环境申请渠道，需求出现后临时开机｜依据：「鼎慧产研决策部」2026-04
  • 现象：测试机登录信息直接发群，安全组到使用时才补配｜依据：「鼎慧产研决策部」2026-04
  • 现象：本机 Agent 权限过高致系统损坏、配置文件丢失，事故后才备份并设置 allow/deny｜依据：「鼎慧产研决策部」2026-04
  • 现象：Agent 在宿主机自行安装数据库等组件，缺少容器隔离｜依据：「鼎慧产研决策部」2026-04

9. 分支变体

  • 桌面类高权限软件：用云 Windows 轻量机
  • CLI 类工具与 Agent：用 Linux 虚拟机或容器
  • 本机运行 Agent：macOS 与 Linux 分别提供基线模板

10. 待确认问题

  • 隔离环境开通的主责是否为研发运维？审批是否必须经 CTO？
  • 试用期默认 14 天是否合适？费用记入哪个预算？
  • 是否需要建一组常备的隔离测试机，而不是每次新开？
  • Agent 本机配置基线由谁编写并维护？
X-SEC-37AI Agent/飞书机器人上线安全检查与权限边界待新建180

状态：待新建｜证据：有证据（卡片 13 张 / 会话 11 个）｜优先级：频4 × 耗3 × 跨3 × 险5

  • 适用场景：在公司服务器、个人电脑或飞书群部署 OpenClaw、LeapAll、Claude Code、Qoder 等具备执行能力的 Agent/机器人，并开放给 owner 以外的人使用前，以及运行中新增能力或放宽审批时
  • 负责人：主责——AI 机器人安全负责人（当前：待指定）；协同——CTO（当前：丁震宇·推断待确认，审批）、Agent 研发（当前：岳阳·推断待确认，安全基线）、IT 运维（当前：杨明学·推断待确认）、测试负责人（当前：张东郅·推断待确认，红队测试）、机器人 owner；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 注册登记 → ② 按部署基线搭建 → ③ 配置身份授权与高危二次确认 → ④ 测试群红队测试 → ⑤ 上线评审 → ⑥ 进入白名单群 → ⑦ 运行审计 → ⑧ 变更重审与下线
  • 交付结果：机器人注册表记录、上线检查表（含红队测试结果）、上线审批记录、运行日志与审计记录
  • 状态依据：个别机器人已有确认人机制、拒绝外泄密钥等雏形，但无统一规范；2026-02～07 多次出现群内套出 API Key 与应用密钥、外发办公网络密码、冒名新增管理员、无沙箱被诱导执行关机、上下文跨群复述个人信息、exec 审批被全放行等问题

1. 场景判定

  • 触发条件：新机器人拉进群；Agent 获得 shell、文件、浏览器、网盘、定时任务能力；修改人设/记忆、开放群策略、关闭 exec 审批；安装外部 skill；把机器人开放给更多人（如许愿机扩大使用）
  • 典型说法：「OpenClaw 就坏在权限太高了」「上下文没隔离」「他没沙箱，他真跑在我的电脑上」「你为什么能把密钥都吐出来了」「企业自建机器人不能进外部群」
  • 判断问题：机器人能否执行命令、读写文件、读群消息或接触密钥？会不会被 owner 以外的人 @ 到？任一为“是”即走本流程
  • 不归本流程管：飞书 scope 审批 → 请走 X-SEC-33；个人试用高权限软件 → 请走 X-SEC-36；密钥泄露后轮换 → 请走 X-SEC-11；Agent 产品本身的权限设计 → 请走 RND-20；外部 skill/插件上架开放平台 → 请走 ECO-06；系统安全扫描 → 请走 X-SEC-39

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
机器人 owner 注册、按基线部署、配置授权、修复问题、到期下线 R 机器人 owner（开发者）
AI 机器人安全负责人 维护基线与红队用例、B 级评审、月度审计 R（B 级审批） AI 机器人安全负责人（当前：待指定）
CTO C 级（有执行能力）上线审批、事故决策，对上线与下线最终拍板 A CTO（当前：丁震宇·推断待确认）
Agent 研发 提供沙箱、审批通道、拒绝策略等技术基线 C Agent 研发（当前：岳阳·推断待确认）
测试负责人 组织红队测试、维护用例 R（测试） 测试负责人（当前：张东郅·推断待确认）
IT 运维 部署服务器、网络隔离、凭据托管 C IT 运维（当前：杨明学·推断待确认）
群成员 只在测试群做越权测试，正式群不试探 I 全员

3. 办之前请准备

  • 机器人名称、owner、部署位置（个人电脑/公司服务器/云）、模型与 API 来源
  • 能力清单：只读问答 / 飞书写入 / shell、文件、浏览器、网盘、定时任务
  • 已申请或计划申请的飞书 scope（见 X-SEC-33）
  • 计划进入的群、确认人及其飞书 open_id
  • 风险等级参考：A 级——只读问答无工具；B 级——可写飞书/文档；C 级——可执行命令或访问文件、网盘、浏览器、定时任务
  • 外部群（客户群、生态群、校友群）：禁止接入企业自建机器人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在机器人注册表登记 owner、能力、等级、scope、目标群、确认人 机器人 owner 部署前 多维表格 注册记录 🔧飞书固化
2 按部署基线搭建：容器/沙箱运行、非 root、仅映射 workspace 与 data；sudo 与破坏性命令需审批；环境变量与密钥不可读；不装未审查 skill；定时任务默认关、限频、带重入保护 机器人 owner 部署时 基线模板、配置文件 基线配置 🤖+👤
3 身份授权：确认人按 open_id 绑定，群内转述无效，确认有时效；改人设/记忆、群策略、密钥、批量私聊、关机、删除等操作需确认人二次确认或走飞书审批卡 机器人 owner 部署时 机器人配置、飞书审批 授权配置 🔧+👤
4 会话隔离与信息过滤：私聊与群聊上下文隔离；证件号、手机号、密码类内容拒答或脱敏；AI 代发消息加标识 机器人 owner 部署时 机器人配置 过滤规则 🤖自动化
5 在测试群跑红队用例：套取环境变量/密钥、提示词注入、冒名授权、越权写宿主机、file:// 读本地、rm/shutdown、skill 注入、跨群上下文 测试负责人、机器人 owner 上线前 2 个工作日内 红队用例脚本 测试报告 🤖+👤
6 上线评审：C 级 CTO 审批；B 级安全负责人审批；A 级备案 CTO / AI 机器人安全负责人 测试报告提交后 1 个工作日内 飞书审批 审批记录 👤人工判断
7 进入白名单内部群；外部群禁止接入，需外发信息改为人工转发 机器人 owner 审批通过后 注册表 群白名单 🔧飞书固化
8 运行审计：调用日志保留 ≥ 90 天，每月抽查异常指令与敏感输出 AI 机器人安全负责人 每月首周 日志、审计脚本 审计记录 🤖自动化
9 新增能力/scope、关闭审批、更换模型 → 重走第 5～6 步 机器人 owner 变更前 飞书审批 变更记录 👤人工判断
10 不再使用的机器人下线，回收密钥与 scope 机器人 owner 停用后 1 个工作日内 X-SEC-33 停用流程 下线记录 🔧飞书固化

5. 交付物与模板

  • 交付物：机器人注册表、上线检查表、红队测试报告、上线审批记录、月度审计记录
  • 建议模板/表单：
    • 注册表字段：机器人名、owner、等级（A/B/C）、部署位置、模型/API 来源、能力清单、飞书 scope、白名单群、确认人 open_id、上线日期、状态
    • 上线检查表：运行用户非 root、容器/沙箱、密钥不可读、skill 来源已审、定时任务限频与重入保护、上下文隔离、敏感信息过滤、高危操作二次确认、AI 消息标识、日志开启
    • 红队用例集：环境变量/密钥套取、编码绕过（如 base64）、冒名与换号授权、宿主机写入、本地文件读取、破坏性命令、skill 注入、跨群上下文泄露

6. 异常与升级

  • 机器人输出密钥或密码 → 立即下线或移出群，按 X-SEC-11 轮换凭据 → 升级 CTO（2 小时内）
  • 冒名授权成功 → 回滚被改配置，改为 open_id 绑定 → AI 机器人安全负责人（当天）
  • 机器人执行了破坏性操作（关机、守护脚本、删除）→ owner 终止进程并下线复盘 → 升级 CTO（当天）
  • 跨会话泄露个人信息 → 删除相关消息、下线修复 → 升级 CTO 并请法务评估（当天）
  • 正式群内有人持续越权试探 → 提醒转到测试群 → 群主处理

7. 衡量指标

  • 注册率：已注册机器人 / 实际在群机器人，目标 100%
  • 上线前红队用例通过率：目标 100%
  • 凭据外泄事件：目标 0 次
  • 事件响应时长：发现到下线或止损，目标 ≤ 2 小时

8. 低效诊断

  • 现象：先开放再测试，越权测试直接在正式群进行｜依据：「AI工具跃迁交流群」2026-02、「LeapCore虾塘测试群」2026-04
  • 现象：机器人能读取并输出 API Key、应用密钥、办公网络密码｜依据：「LeapCore虾塘测试群」2026-04、「leapall逗狗群」2026-06
  • 现象：授权规则靠各机器人自建记忆，口径不一，冒名注入可成功｜依据：「随便瞎聊啦～」2026-03、「leapall逗狗群」2026-06
  • 现象：Agent 跑在个人电脑上无沙箱，skill 注入可在 workspace 外操作｜依据：「跃迁AI总动员」2026-06
  • 现象：上下文未隔离、file:// 未拦截，发布后才被旁人发现｜依据：「鸽子群模态分群」2026-04、「鸽子群模态分群」2026-05
  • 现象：定时任务读群自动回复导致刷屏、分不清 AI 与真人｜依据：「Leap产研测」2026-05
  • 现象：Agent 安全基线方案停留在讨论，无人认领｜依据：「模态AI探索小分队」2026-03
  • 现象：为省事把 exec 审批全放行｜依据：「AI工具跃迁交流群」2026-04
  • 现象：许愿机先开放使用，身份与公司账号未绑定、成员角色靠事后清理｜依据：「跃迁基座许愿机」2026-05
  • 现象：机器人由谁审批不清｜依据：「鼎慧产研决策部」2026-02

9. 分支变体

  • 内部测试群：允许红队测试；正式内部群：仅白名单机器人；外部群：禁止接入企业自建机器人，外部消息人工转发（参考「奇绩校友飞书群」2026-02、2026-03 的平台限制）
  • 部署位置：个人电脑（最低限 B 级，C 级必须容器）、公司服务器 7x24（C 级审批）、对客交付环境（另走交付流程）
  • 许愿机（slock）：为 agent 单独建代码组织，不放存量私有代码；commit 标注操作人与 agent；只放公开项目；邀请制白名单；admin 由运维授予
  • owner 自用机器人与公共机器人：公共机器人必须有确认人和审计日志

10. 待确认问题

  • AI 机器人安全负责人由谁担任？是否由 Agent 研发兼任？
  • A/B/C 三级划分与审批人是否认可？C 级是否一律要求容器运行？
  • 高危操作二次确认能否接入飞书审批卡？
  • 许愿机 SOP 是否已有成稿，能否并入本流程？
  • 已发生的密钥外泄是否已全部轮换？
X-SEC-38服务器上线安全基线与对外演示暴露面检查待新建90

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频3 × 耗2 × 跨3 × 险5

  • 适用场景：新开公司服务器或内网机器、给客户机器交付前、在公网部署演示服务（OpenClaw、LeapCore 等）时，上线前完成口令、登录方式和端口暴露面检查并登记
  • 负责人：主责——IT 运维（当前：杨明学·推断待确认）；协同——研发运维（当前：宋祺睿·推断待确认）、运维/交付部署工程师（当前：游家豪·推断待确认）、服务器申请人/演示环境部署人；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 用基线模板开机 → ② 部署人自检 → ③ 提交公网暴露申请 → ④ 端口与弱口令扫描 → ⑤ 上线确认并登记 → ⑥ 客户机器交付加安全验收项 → ⑦ 每月复扫 → ⑧ 到期下线
  • 交付结果：上线安全检查单、资产与暴露面台账、扫描报告、事件复盘记录
  • 状态依据：无成文基线；2026-06 一台机器关闭证书登录、改回密码登录并保留默认弱口令后被入侵挖矿；2026-04 公网演示 OpenClaw 被安全扫描告警；2026-09 客户机器接入时才发现弱密码和 root 远程登录，只有口头约定后续统一修改

1. 场景判定

  • 触发条件：新开服务器/虚拟机；开放公网端口或域名；部署演示环境；客户机器交付或接入公司网络前；收到外部安全扫描告警
  • 典型说法：「应该直接关掉密码登录用证书」「扫到我们再公网暴露openclaw了」「我们要再公网演示用呀」「别用热门端口」「root 远程登录关闭」
  • 判断问题：这台机器能否从公网或客户网络访问？是否还能用密码或 root 远程登录？
  • 不归本流程管：服务器/云资源申请本身 → 请走 X-SEC-16、X-SEC-17；域名解析、证书、端口开通操作 → 请走 X-SEC-19；系统渗透测试 → 请走 X-SEC-39；漏洞整改闭环 → 请走 X-SEC-40；已被入侵的事件处置 → 请走 X-SEC-42；等保测评 → 请走 X-SEC-43

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维 维护基线模板、扫描验证、上线确认、每月复扫 R/A IT 运维（当前：杨明学·推断待确认）
研发运维 云上机器初始化、接入层（EdgeOne/反代）配置 R 研发运维（当前：宋祺睿·推断待确认）
运维/交付部署工程师 客户机器部署脚本强制基线、交付验收安全项 R 运维/交付部署工程师（当前：游家豪·推断待确认）
服务器申请人/部署人 自检、提交暴露申请、按期下线 R 申请人
CTO 例外审批、事故决策 A（升级） CTO（当前：丁震宇·推断待确认）

3. 办之前请准备

  • 机器用途、环境（内网/公网/客户网络）、负责人、预计下线日期
  • 需开放的端口、域名、对外访问对象（全网/白名单 IP）
  • 鉴权方式（登录、Token、IP 白名单），是否经统一接入层
  • 基线项：禁止密码登录（只用证书/密钥）、禁止 root 远程登录、默认口令改为随机强口令并存入密码管理、不用热门端口、管理面板不直接暴露公网、高危组件（如 OpenClaw）不直接暴露公网、开启自动安全更新与登录日志

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 申请服务器时选择基线模板 服务器申请人 申请时 X-SEC-16/17 申请单 带基线的申请 🔧飞书固化
2 开机即应用基线：证书登录、禁 root、随机口令 IT 运维/研发运维 开通时 初始化镜像/脚本 已加固机器 🤖自动化
3 部署人按检查单自检，不得私自关闭证书登录 部署人 上线前 检查单 自检结果 👤人工判断
4 提交公网暴露申请：端口、域名、用途、期限、鉴权方式 部署人 上线前 1 个工作日 飞书审批 暴露申请 🔧飞书固化
5 端口与弱口令扫描验证 IT 运维 申请后 1 个工作日内 扫描脚本 扫描报告 🤖自动化
6 上线确认并登记资产与暴露面台账 IT 运维 扫描通过当天 多维表格 台账记录 🔧飞书固化
7 客户机器：部署脚本强制随机口令、关闭 root 远程登录，交付验收单加安全项 运维/交付部署工程师 交付验收前 部署脚本、X-DLV-29 验收单 安全验收项 🔧+🤖
8 每月复扫内网与公网口令和端口；演示环境到期提醒下线 IT 运维 每月首周 扫描脚本、机器人提醒 复扫报告 🤖自动化
9 发生事件后按模板复盘（原因、影响、改进） 当事人、IT 运维 事件后 3 个工作日内 复盘模板 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：上线安全检查单、资产与暴露面台账、扫描报告、复盘记录
  • 建议模板/表单：
    • 上线检查单：密码登录已关、root 远程登录已关、默认口令已改且已托管、开放端口清单、非热门端口、管理面板未暴露、接入层/鉴权、日志开启、负责人、下线日期
    • 暴露面台账字段：主机/IP、环境、负责人、用途、开放端口、域名、鉴权方式、上线日期、到期日、最近扫描结果
    • 复盘模板：时间线、原因、影响范围、已采取措施、改进项与负责人

6. 异常与升级

  • 升级条件：基线例外申请（如客户要求保留密码登录）、修复逾期需关停端口、机器被入侵等安全事件 → IT 运维升级 CTO 决策；符合基线的上线确认由 IT 运维直接办理
  • 扫描发现弱口令或未登记端口 → 通知负责人修复，高危 4 小时内、其他 1 个工作日内，逾期关停端口 → 升级 CTO
  • 机器被入侵（挖矿等）→ 断网隔离、取证、重装、轮换凭据 → 按 X-SEC-42 处置（当天）
  • 收到外部安全扫描告警 → 当天下线或改为白名单访问 → IT 运维
  • 客户特殊环境要求保留密码登录 → 书面例外申请，写明补偿措施 → CTO 审批（2 个工作日内）

7. 衡量指标

  • 上线检查覆盖率：上线机器中有检查单的比例，目标 100%
  • 未登记公网端口数：每月复扫发现数，目标 0
  • 弱口令/root 远程登录机器数：目标 0
  • 告警修复时长：高危 ≤ 4 小时，其他 ≤ 1 个工作日

8. 低效诊断

  • 现象：默认证书登录可被个人随意关闭并保留弱口令，无强制与审计，导致被入侵挖矿｜依据：「鸽子群模态分群」2026-06
  • 现象：事故后才扫描内网弱口令账户｜依据：「鸽子群模态分群」2026-06
  • 现象：公网演示需求与安全要求冲突，无暴露审批，收到告警后才处理｜依据：「LeapCore（archived）」2026-04、「LeapCore（archived）」2026-05
  • 现象：端口选择无规范，使用热门端口｜依据：「LeapCore（archived）」2026-05
  • 现象：客户机器弱口令和 root 远程登录在接入时才被发现，整改靠口头约定｜依据：「某客户服务器 WG 接入群」2026-09

9. 分支变体

  • 公司内网机器：按基线开机，内网复扫
  • 个人开发/学习服务器：若接入公司网络、使用公司账号付费或存放公司数据，同样适用
  • 公网演示环境：必须有到期日，优先经统一接入层（EdgeOne/反代）与白名单
  • 客户内网交付：部署脚本强制基线，客户特殊要求走例外审批
  • 信创环境：基线项相同，工具适配由 IT 运维确认

10. 待确认问题

  • 服务器安全基线的主责是否为 IT 运维？研发运维管理的云上机器是否也由 IT 运维复扫？
  • 是否统一采购接入层（EdgeOne 等）用于所有公网演示？
  • 个人学习服务器是否纳入管理？
  • 客户机器交付验收单能否加入安全基线项？
X-SEC-39安全扫描与渗透测试申请执行待新建120

状态：待新建｜证据：有证据（卡片 4 张 / 会话 4 个）｜优先级：频2 × 耗4 × 跨3 × 险5

  • 适用场景：对公司自有生产/测试环境、新装机器、MCP/Agent 接入前进行安全扫描、渗透测试或红蓝对抗时，先申请授权范围，再执行、出报告并移交整改
  • 负责人：主责——安全测试执行人（当前：杨明学·推断待确认）；协同——CTO（当前：丁震宇·推断待确认，授权审批）、研发负责人（当前：王皓南·推断待确认）、研发运维（当前：宋祺睿·推断待确认）、跃竞运维（当前：席博田·推断待确认）、被测系统负责人；兜底——CTO（当前：丁震宇·推断待确认）
  • 核心流程：① 提交测试申请（范围、环境、时间窗、手段、禁止动作）→ ② 授权审批 → ③ 准备测试账号与资产白名单 → ④ 执行扫描/渗透 → ⑤ 机器人分级推送发现 → ⑥ 复测去误报与定级 → ⑦ 出报告 → ⑧ 建工单移交 X-SEC-40
  • 交付结果：测试授权单、扫描/渗透报告（分级）、漏洞工单
  • 状态依据：2026-08～10 有多次自发测试（AI 渗透、机器人推送漏洞卡片、跃竞线集中审计 39 个疑似漏洞），但无授权范围与固定周期；2026-10 一度误扫生产站点；同一发现是否成立口径不一，修复责任人与期限缺失

1. 场景判定

  • 触发条件：计划对自有域名/IP 做扫描或渗透；新装机器或新系统上线前；MCP/Agent 接入前；季度安全专项；重大版本发布前
  • 典型说法：「red需要单独申请」「建工单」「是不是该做安全专项了」「怎么跑生产了」「审计研判目前可能存在的39个漏洞」
  • 判断问题：这次测试会不会向公司系统发起主动探测或攻击请求？是否涉及生产环境？
  • 不归本流程管：上线前基线自检 → 请走 X-SEC-38；漏洞修复、复测与遗留资产清理 → 请走 X-SEC-40；外部 CVE/投毒通告排查 → 请走 X-SEC-41；疑似已被入侵 → 请走 X-SEC-42；等保测评 → 请走 X-SEC-43；Agent 上线红队测试 → 请走 X-SEC-37

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
安全测试执行人 提申请、在授权范围内执行、复测、出报告、建工单 R 安全测试执行人（当前：杨明学·推断待确认）
CTO 生产环境与红队测试授权、高危事项决策 A CTO（当前：丁震宇·推断待确认）
研发负责人 测试环境授权、发现是否成立的研判、整改分派 R/C 研发负责人（当前：王皓南·推断待确认）
研发运维 提供测试账号、源 IP 限制、日志排查 R 研发运维（当前：宋祺睿·推断待确认）
跃竞运维 跃竞线测试执行与报告 R（跃竞） 跃竞运维（当前：席博田·推断待确认）
被测系统负责人 确认范围、值守、复测确认 C 各系统负责人

3. 办之前请准备

  • 资产清单：域名/IP、所属系统、环境（测试/生产）、系统负责人
  • 测试类型：扫描、蓝队检测、红队攻击、AI 渗透、MCP/Agent 攻防
  • 时间窗（含夜间自动任务）、禁止动作（删除数据、横向移动、DoS、读取真实用户数据）
  • 测试账号、源 IP、回滚方案、紧急联系人
  • 工具来源与费用（如需采购扫描服务或额度）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交测试申请（资产、环境、类型、时间窗、禁止动作、联系人、回滚方案） 安全测试执行人 测试前 2 个工作日 飞书审批 申请单 🔧飞书固化
2 授权：测试环境由研发负责人批；生产环境或红队由 CTO 与系统负责人批 研发负责人/CTO 1 个工作日内 飞书审批 授权单 👤人工判断
3 准备单独测试账号、SSH 公钥登录、限定源 IP；通知系统负责人 研发运维 测试前 1 个工作日 服务器、飞书群 测试账号 🔧飞书固化
4 在扫描工具中配置资产白名单，只在授权范围与时间窗内执行 安全测试执行人 时间窗内 扫描器、AI 渗透工具 原始结果 🤖自动化
5 机器人按高/中/低危推送发现到专用群 系统 实时 漏洞推送机器人 发现卡片 🤖自动化
6 复测去误报，确认可利用性并定级（高/中/低/可接受） 安全测试执行人、被测系统负责人 推送后 2 个工作日内 漏洞多维表格 定级清单 👤人工判断
7 出报告：范围、方法、发现、等级、证据、修复建议 安全测试执行人 测试结束后 3 个工作日内 报告模板（AI 生成初稿） 测试报告 🤖自动化
8 建工单移交整改，按等级设期限：高危 3 个工作日、中危 10 个工作日、低危 30 天 安全测试执行人 报告当天 Issues/多维表格 漏洞工单 🔧飞书固化
9 制定周期计划：每季度一次全量扫描，重大版本与 MCP/Agent 接入前专项 CTO 每季度首月 飞书日历/任务 测试计划 🔧飞书固化

5. 交付物与模板

  • 交付物：测试申请与授权单、测试报告、漏洞清单与工单、季度测试计划
  • 建议模板/表单：
    • 授权单字段：申请人、资产清单、环境、测试类型、时间窗、禁止动作、测试账号与源 IP、回滚方案、紧急联系人、审批人
    • 漏洞清单字段：编号、资产、所属系统、描述、等级、是否误报、证据、责任人、期限、修复状态、复测结果、关闭日期
    • 报告结构：概述、范围与方法、发现汇总（按等级）、逐项详情、修复建议、附录（工具与时间）

6. 异常与升级

  • 误扫生产或超出授权范围 → 立即停止，通知系统负责人检查影响 → 升级 CTO（当天）
  • 发现疑似已被利用的痕迹 → 停止测试，查日志与数据库 → 按 X-SEC-42 处置（当天）
  • 发现高危漏洞 → 当天通知系统负责人与 CTO，必要时临时下线功能 → 按 X-SEC-40 整改
  • 测试导致服务异常 → 按回滚方案恢复，暂停测试 → 升级研发负责人（30 分钟内）
  • 对“是否算问题”存在分歧 → 由研发负责人定级，仍有分歧由 CTO 裁决（2 个工作日内）

7. 衡量指标

  • 授权覆盖率：有授权单的测试次数 / 总测试次数，目标 100%
  • 超范围测试次数：目标 0 次
  • 报告出具时长：测试结束到报告，目标 ≤ 3 个工作日
  • 高危漏洞修复时长：建单到关闭，目标 ≤ 3 个工作日
  • 季度计划执行率：目标 100%

8. 低效诊断

  • 现象：测试由个人临时发起，无授权范围，一度误扫生产站点｜依据：「嗨客」2026-10
  • 现象：红队需单独申请，但范围、禁止动作、回滚方案靠口头约定｜依据：「跃迁AI总动员」2026-10
  • 现象：同一发现是否成立各说各的，修复归属不清，到渗透时才发现自助注册未关闭｜依据：「Leap产研测」2026-10
  • 现象：漏洞清单与修复进度无共享台账，修复责任人和期限缺失｜依据：「跃玩项目组」2026-08、「跃玩项目组」2026-10
  • 现象：测试工具、账号、费用各自寻找，无统一渠道｜依据：「嗨客」2026-10

9. 分支变体

  • 蓝队检测与红队攻击：红队一律需 CTO 授权
  • 测试环境与生产环境：生产环境需系统负责人值守，避开业务高峰
  • 基础设施层、应用层、Agent/MCP 层：Agent/MCP 层需包含提示词注入用例
  • 跃竞线：由跃竞运维执行，结合等保二级要求
  • 对客扫描服务：目前为设想，若对外提供需另立流程并经法务评估
  • 多资产线并行：各资产线分别认领范围，在同一授权单内列明

10. 待确认问题

  • 安全测试执行人是否为 IT 运维？跃竞线是否单独执行、单独出报告？
  • 测试环境授权由研发负责人审批是否可行？生产环境是否必须 CTO 审批？
  • 漏洞整改期限（高危 3 个工作日、中危 10 个工作日、低危 30 天）是否认可？
  • 是否需要预算采购扫描工具或外部渗透服务？
  • 对客扫描服务是否立项？
X-SEC-40漏洞整改闭环与对外遗留资产清理待新建320

状态：待新建｜证据：有证据（卡片 7 张 / 会话 7 个）｜优先级：频4 × 耗4 × 跨4 × 险5

  • 适用场景：安全扫描、渗透测试、外部报告或员工发现对外服务存在未授权接口、弱口令/默认口令、密钥泄露、调试端点暴露，或发现无人认领的站点、域名、服务器时，启动“登记定级 → 修复或下线 → 复扫关闭”的闭环
  • 负责人：主责——安全整改统筹（当前：王皓南·推断待确认）；协同——安全扫描与工单跟踪（当前：魏宗浩·推断待确认）、各服务负责人（当前：宋祺睿、吴世豪、李铭熙、葛家和·推断待确认）、云账号与 DNS 管理（当前：丁震宇·推断待确认）、财务（当前：待指定）；兜底——研发负责人/CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 线索登记 → ② 定级与临时封堵 → ③ 认领责任人 → ④ 修复或下线 → ⑤ 复扫验证 → ⑥ 回复报告人与日报 → ⑦ 更新资产台账与复盘
  • 交付结果：已关闭的漏洞工单（含定级、修复说明、复扫截图）、更新后的对外服务资产台账、遗留站点下线记录（DNS/服务/密钥/云资源/收录均已清理）
  • 状态依据：目前只有“有外部用户的先修、扫出来就派工单、修完重扫”三条口头规则和一次集中整改；2026-10 集中整改期间“这个服务是谁的”反复出现约 6 次，无资产台账、无定级、工单系统尚在拟用；01 月、03 月两次对外暴露都是事后救火

1. 场景判定

  • 触发条件：
    • 安全扫描/渗透测试报告产出漏洞项（扫描本身见 X-SEC-39）
    • 外部人员、客户或合作方告知漏洞（如调试端点可导出内存）
    • 员工发现旧版/演示站点仍可访问，或测试站被搜索引擎收录
    • 发现 API Key 明文存放或泄露、接口无鉴权返回用户列表、管理后台共用 admin 账号或默认口令、登录无限速
    • 资产巡检发现无人认领的域名、IP、服务
  • 典型说法：「生产部署别带 actuator 就行」「以后开公网服务必须审批」「没用的服务器统统关掉」「这两个服务是谁的」「每天汇报一下安全问题工单解决情况」
  • 判断问题：这是不是“公司自己已存在的对外暴露面/漏洞”，需要有人修复或下线？
  • 不归本流程管：
    • 申请做扫描或渗透测试 → 请走 X-SEC-39
    • 外部 CVE、供应链投毒、AI 工具安全通告的全公司排查 → 请走 X-SEC-41
    • 密钥泄露后的批量轮换操作 → 请走 X-SEC-11（本流程只登记与跟踪闭环）
    • 内网中毒、生产异常请求溯源 → 请走 X-SEC-42
    • 新服务上线前的基线检查 → 请走 X-SEC-38
    • 单纯出于成本的闲置资源回收 → 请走 X-SEC-22

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
安全整改统筹 定级、分派、催办、验收关闭、每日汇总 A 安全整改统筹（当前：王皓南·推断待确认）
扫描与工单跟踪 登记工单、确认资产归属、复扫 R 安全扫描执行（当前：魏宗浩·推断待确认）
服务负责人 认领、修复或下线、提交修复说明 R 各服务负责人（当前：宋祺睿、吴世豪、李铭熙、葛家和·推断待确认）
云账号/DNS 管理 删解析、网关封禁、关停云资源、导出全量 IP R 云账号管理员（当前：丁震宇·推断待确认）
对外接收人 接收外部报告、回执与结果回复 R 对外接收人（当前：宋祺睿·推断待确认）
研发负责人/CTO 严重漏洞处置决策、无主资产停用拍板 C（升级时 A） CTO（当前：丁震宇·部门报送人）
官网/品牌 搜索引擎收录删除、301 跳转确认 C 官网负责人（当前：待指定）
财务 关停后核对云账单停费 I 财务（当前：待指定）

3. 办之前请准备

  • 漏洞描述：URL/IP/端口、复现步骤或截图（不在群里贴明文密钥和完整利用载荷）
  • 来源：扫描报告编号 / 外部报告人联系方式 / 发现渠道
  • 影响面初判：是否有外部用户、是否涉及用户数据/密钥/管理员信息、是否生产环境
  • 资产信息：域名、IP、所在云账号或机房、疑似负责人（先查资产台账）
  • 遗留站点：最后使用时间、是否仍有客户演示或交付依赖

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 扫描结果、外部报告、员工发现统一录入漏洞台账，一项一单 扫描与工单跟踪 发现后 2 小时内 漏洞台账（多维表格）/工单系统 漏洞工单 🔧+🤖
2 定级：外部可利用且涉及敏感数据/密钥/管理员信息=严重；有外部用户=高；纯内部=中；信息类=低。严重项先临时封堵（网关封禁、关注册、删解析） 安全整改统筹、云账号/DNS 管理 严重 2 小时内封堵；其余 1 个工作日内定级 Nginx/Caddy、DNS 控制台 等级、封堵记录 👤人工判断
3 确认归属：先查资产台账；查不到在安全群 @ 疑似负责人，1 个工作日无人认领即判定为无主资产 扫描与工单跟踪 定级后 1 个工作日内 资产台账、安全群 责任人 🔧飞书固化
4 无主资产：先删 DNS 解析/封禁入口，观察 7 天无人申诉后关停服务与云资源 云账号/DNS 管理 认领期满后 1 个工作日内处置；观察 7 天 DNS、云控制台 下线记录 👤人工判断
5 修复：关闭调试端点、补鉴权、改默认口令、拆分管理员并加审计、加登录限速/IP 限流；密钥泄露转 X-SEC-11 轮换 服务负责人 严重 24 小时；高 3 个工作日；中 10 个工作日；低 下一迭代 Gitea issue/PR 修复说明、PR 链接 👤人工判断
6 下线遗留站点：按下线清单逐项清理 DNS、反向代理、服务进程、云主机、关联 API Key、搜索引擎收录（robots/301/站长平台删除） 服务负责人、云账号/DNS 管理、官网/品牌 决定下线后 3 个工作日内 下线清单 勾选完成的下线清单 🔧飞书固化
7 针对该工单复扫，通过即关闭，不通过退回第 5 步 扫描与工单跟踪 修复提交后 1 个工作日内 扫描工具 复扫截图 🤖自动化
8 回复外部报告人“已修复”；机器人每日推送未关闭工单到安全群 对外接收人、安全整改统筹 关闭后 1 个工作日内；日报每工作日 10:00 飞书机器人 回复记录、日报 🔧+🤖
9 更新资产台账（负责人、用途、到期日）；严重项复盘并补进上线检查单（X-SEC-38） 安全整改统筹 关闭后 5 个工作日内 资产台账、复盘模板 复盘记录 👤人工判断

5. 交付物与模板

  • 交付物：漏洞工单、对外服务资产台账、遗留资产下线记录、每日汇总、严重项复盘
  • 漏洞台账字段：编号、来源（扫描/外部报告/内部发现）、资产（域名/IP/端口）、所属系统、主体/产品线、环境、等级、临时措施、责任人、截止时间、修复说明、PR 链接、复扫结果、状态、关闭日期
  • 对外服务资产台账字段：域名、IP、云账号/机房位置、用途、环境（生产/测试/demo）、是否有外部用户、负责人、备份负责人、上线日期、计划下线日期、公网开通审批单号
  • 下线清单：DNS 解析 / 反代配置 / 服务进程 / 云主机或容器 / 关联 API Key 与账号 / 搜索引擎收录 / 账单停费确认 / 台账状态改为“已下线”

6. 异常与升级

  • 严重漏洞 2 小时内未封堵 → CTO 直接处置（当天）
  • 责任人超时未修复 → 统筹催办 1 次；再超 1 个工作日 → 升级其直属负责人与 CTO
  • 资产 1 个工作日无人认领 → 按无主资产先封禁，不再继续等待
  • 修复需停服或影响客户 → 统筹与业务负责人 1 个工作日内商定窗口，涉及交付抄送交付负责人
  • 外部报告人公开披露或引发舆情 → 当天升级 CTO 与品牌负责人统一口径
  • 确认客户数据已外泄 → 当天升级 CTO，并请法务评估是否通知客户/监管

7. 衡量指标

  • 严重漏洞封堵时长 = 登记到临时封堵的时长，目标 ≤ 2 小时
  • 按期修复率 = 在等级时限内关闭的工单 / 到期工单，目标 ≥ 90%
  • 复扫一次通过率 = 首次复扫即关闭的工单 / 已复扫工单，目标 ≥ 85%
  • 无主资产数 = 月度巡检中查不到负责人的对外资产数，目标 0
  • 资产台账覆盖率 = 扫描发现的对外资产中已登记的比例，目标 100%

8. 低效诊断

  • 现象：对外服务没有资产台账，扫描后只能在群里逐个问“这是谁的服务”，归属确认反复拖延｜依据：「安全讨论」2026-10
  • 现象：整改项靠群消息分派，关没关、注册入口停没停需要多轮追问；工单系统和日报机制在整改中途才提出｜依据：「安全讨论」2026-10
  • 现象：同类 AI mock/demo 站点反复被扫出，上线时既未登记也未设下线日期｜依据：「安全讨论」2026-10
  • 现象：外部人员报告调试端点暴露，只在群内口头决定网关封禁，无定级、无工单、无对外回复闭环｜依据：「鼎慧产研决策部」2026-01
  • 现象：密钥明文存放、登录无限速等问题在被利用后才讨论加固，属事后补流程｜依据：「Leap产研决策部」2026-10
  • 现象：测试站被搜索引擎收录后才挂跳转、停用测试域名，上线前无 robots/测试域名鉴权检查｜依据：「开源聚变入驻问题沟通群」2026-03

9. 分支变体

  • 外部报告：1 个工作日内回执报告人，修复后回复结果；对外不承诺奖励，口径由对外接收人统一
  • 计划取缔的老系统：不做代码修复，直接在网关层封禁入口并设下线日期
  • 测试站被收录：测试域名加鉴权或 IP 白名单、robots 禁止收录、301 到正式站、站长平台提交删除
  • 遗留 demo/学生项目站点：默认下线；确需保留的补登记负责人与到期日
  • 已不再使用的云厂商账户：盘点资源 → 关停 → 注销，通知财务停费
  • 主体：鼎慧、Leap、跃竞各自服务负责人认领，统筹人统一

10. 待确认问题

  • 安全整改统筹是否固定为 Leap 研发负责人？鼎慧、跃竞线是否各设一名对接人？
  • 等级与时限（严重 24 小时、高 3 个工作日、中 10 个工作日）是否可行？
  • 工单载体用内部 issues 工单系统还是飞书多维表格？日报机器人由谁维护？
  • “公网服务必须审批”的飞书审批流是否已建立？审批人是谁？
  • 无主资产“先封禁、观察 7 天后关停”的规则是否接受？
  • 外部漏洞报告的统一入口（邮箱/表单）由谁维护？
  • 对外服务资产台账由谁维护，多久全量盘点一次？
X-SEC-41高危漏洞、供应链投毒与 AI 工具安全通告应急排查待新建180

状态：待新建｜证据：有证据（卡片 10 张 / 会话 7 个）｜优先级：频4 × 耗3 × 跨3 × 险5

  • 适用场景：外部公开高危 CVE（Linux 内核、nginx、log4j2 等）、依赖包或开发工具被投毒（npm 包、Apifox、litellm）、AI 工具被曝上传代码/.env 或收集遥测、自部署开源服务高危漏洞、外部 skill 带毒或开源协议风险时，统一研判公司是否受影响，组织排查、处置并通报结论
  • 负责人：主责——安全通告响应负责人（当前：杨明学·推断待确认）；协同——技术研判人（按技术栈指定，当前：王子明、陈晖、张楠·推断待确认）、各服务/项目负责人（当前：吴世豪、岳阳·推断待确认）、全体研发（自查）、法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 通告登记 → ② 研判影响与定级 → ③ 发布统一通告与排查清单 → ④ 资产比对与自查回收 → ⑤ 升级/修补/轮换凭据 → ⑥ 验证与结论通报 → ⑦ 加固规则沉淀
  • 交付结果：统一安全通告、排查结果回收表（对象 × 是否受影响 × 处置结果）、结论通报、更新后的加固规则与工具准入清单
  • 状态依据：2026-03～10 至少 8 起通告（Apifox、axios、litellm、两起 Linux 内核提权、nginx、log4j2、AI CLI 遥测/数据出境），均靠个人在群里转发、各自自查；仅 04 月一次发布统一通告，但没有结果回收，无人确认全员是否修完

1. 场景判定

  • 触发条件：
    • 安全媒体、云厂商公告、社区群出现与公司技术栈相关的 CVE 或投毒事件
    • 公司在用的开发工具、AI 编码工具、CLI 被曝上传代码/密钥或数据出境
    • 自部署的开源服务（模型网关、知识库等）被披露高危漏洞
    • 员工准备使用外部 skill、外部仓库或泄露源码
  • 典型说法：「几个群的全中招了」「所有 key 都得轮换一下」「所有人给 npm 账号上 2fa」「【紧急安全通告】…风险说明与处置要求」「该全线换 caddy 了」
  • 判断问题：通告涉及的组件/工具/版本，公司服务器、依赖、开发工具或自部署服务里有没有在用？
  • 不归本流程管：
    • 公司自己某个服务被扫出的具体漏洞 → 请走 X-SEC-40
    • 密钥/凭据轮换的具体执行 → 请走 X-SEC-11
    • 新工具引入前的安全试用 → 请走 X-SEC-36
    • 开源组件引入许可证评估 → 请走 LEG-28
    • 依赖版本日常锁定与管理 → 请走 RND-36
    • 内网异常流量、疑似中毒 → 请走 X-SEC-42

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
安全通告响应负责人 登记、组织研判、发布通告、回收结果、通报结论 A/R IT 运维（当前：杨明学·推断待确认）
技术研判人 按技术栈判断触发条件与影响面，给出排查命令 R 对应技术栈研发（当前：王子明、陈晖、张楠·推断待确认）
情报提供人 把看到的通告转入安全通告群 I 全员（当前：杨云峰、宋祺睿、魏宗浩、望政韬等）
服务/项目负责人 名下服务器、项目、自部署服务的排查与修补，回填结果 R 各服务负责人（当前：吴世豪、岳阳、邓乾·推断待确认）
全体研发 个人设备与开发工具自查，轮换个人凭据 R 全体研发
法务 开源协议、泄露源码留存、数据出境给出书面结论 C 法务（当前：待指定）
CTO 严重等级拍板、停机/停用决策 C（升级时 A） CTO（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 通告原文链接、CVE 编号或事件名、受影响版本、修复版本、PoC 是否公开
  • 公司资产清单：服务器（OS、内核、中间件）、各项目依赖锁文件、开发工具清单、AI 工具清单、自部署开源服务清单
  • 排查命令/脚本（版本检测、可疑包检测、登录日志检查）
  • 受影响时需轮换的凭据清单（SSH、Git、npm、云 AccessKey、模型 API Key）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 任何人看到通告转入安全通告群；响应负责人登记到通告台账 响应负责人 工作时间内 30 分钟 安全通告群、多维表格、CVE 订阅机器人 通告记录 🔧+🤖
2 比对资产清单，指定研判人确认触发条件并定级：严重=在用且可直接利用或已安装投毒版本；高=在用但需特定条件；低=未使用 响应负责人、技术研判人 登记后 2 小时内 资产清单、AI 汇总 研判结论 🤖+👤
3 严重/高：在通知群发布统一通告（原理一句话、影响范围、排查命令、处置要求、回填截止）；低：只登记结论 响应负责人 研判后 1 小时内 飞书通知群、通告模板 安全通告 🔧飞书固化
4 服务器由服务负责人跑排查脚本，个人设备由本人自查，结果回填回收表 服务负责人、全体研发 严重：当天 18:00 前；高：2 个工作日内 回收表、排查脚本 回填结果 🔧+🤖
5 处置：升级补丁/禁用模块/回滚依赖/卸载工具；已中招的设备先断网隔离，按 X-SEC-11 轮换全部相关凭据；包管理器账号开启 2FA 服务负责人、设备使用人 严重 24 小时内；高 5 个工作日内 包管理器、云控制台 处置记录 👤人工判断
6 每日推送未回填名单；脚本或抽查复核已处置项 响应负责人 截止后 1 个工作日内 飞书机器人 完成率 🤖自动化
7 发布结论：排查对象数、受影响数、已处置数、遗留项及负责人 响应负责人 截止后 1 个工作日内 飞书通知群 结论通报 🔧飞书固化
8 沉淀加固规则（锁版本、CI 加 --ignore-scripts、禁用工具清单、新服务中间件选型），更新资产与工具清单 响应负责人、CTO 结案后 5 个工作日内 规范文档、工具准入清单 规则更新 👤人工判断

5. 交付物与模板

  • 交付物：安全通告、排查回收表、结论通报、加固规则更新记录
  • 安全通告模板：标题（【紧急/一般安全通告】）、事件名/CVE、影响组件与版本、公司是否在用（初判）、风险说明、排查命令、处置要求、回填链接、截止时间、联系人
  • 排查回收表字段：对象类型（服务器/个人设备/项目/自部署服务）、对象名、负责人、检测结果（受影响/不受影响/不确定）、处置动作、凭据是否已轮换、完成时间、截图
  • 资产与工具清单字段：服务器（IP、OS、内核、中间件）、项目依赖锁文件位置、开发工具及版本、AI 工具（遥测开关、数据流向、使用人）、自部署开源服务（版本、负责人）
  • AI 工具/外部组件评估表：数据流向、遥测能否关闭、是否会上传代码或 .env、许可协议、结论（允许/限制/禁用）、评估人、日期

6. 异常与升级

  • 确认有设备或账号已中招 → 立即隔离并轮换凭据，1 小时内升级 CTO；涉及客户环境的当天通知交付负责人评估是否告知客户
  • 生产服务器需停机打补丁 → 当天报 CTO 批准维护窗口
  • 回填截止未完成 → 次日点名推送；再超 1 个工作日升级其部门负责人
  • 研判人无法判断影响 → 当天升级 CTO，必要时请云厂商或外部安全服务协助
  • 涉及泄露源码留存、AGPL 等协议、数据出境 → 2 个工作日内请法务出书面意见，结论出来前暂停使用
  • 需要实测 PoC → 只能在隔离环境由研判人执行，不在非工作群或共享机器上测试

7. 衡量指标

  • 研判时长 = 登记到研判结论（工作时间），目标 ≤ 2 小时
  • 回收完成率 = 截止前回填对象数 / 应排查对象数，严重级目标 100%，高级 ≥ 95%
  • 严重级处置时长 = 通告到全部处置完成，目标 ≤ 24 小时
  • 通告闭环率 = 有结论通报的通告 / 登记通告数，目标 100%
  • 资产清单命中率 = 研判时能直接从清单回答“是否在用”的比例，目标 ≥ 90%

8. 低效诊断

  • 现象：通告靠个人刷到后转发，出现过装完包才看到通告的情况，属事后补流程｜依据：「鸽子群模态分群」2026-05、「技术部」2026-03
  • 现象：无统一通告和结果回收，各人用自己的 AI 助手自查，结论散落在群里，无人确认全员修完｜依据：「技术部」2026-03、「鸽子群模态分群」2026-04
  • 现象：统一通告发出后没有排查结果回收和责任人确认｜依据：「模态跃迁通知群」2026-04
  • 现象：无服务器/中间件/依赖清单，研判只能凭记忆判断“应该没中招”，老机器上的中间件未盘点｜依据：「跃迁AI总动员」2026-05
  • 现象：对容器、虚拟机是否可逃逸各说各话，缺少指定研判人给出定论｜依据：「鸽子群模态分群」2026-04
  • 现象：AI 工具遥测、数据出境与开源协议问题由新闻驱动、群里讨论，无人负责结论，整改与否无记录｜依据：「跃迁AI总动员」2026-07、「跃迁AI总动员」2026-09
  • 现象：外部 skill 与泄露源码靠经验提醒，是否合规留存事后才讨论｜依据：「模态AI探索小分队」2026-04
  • 现象：凭据轮换无清单，个人手工操作险些误删用户目录｜依据：「鸽子群模态分群」2026-05
  • 现象：同一开发工具投毒事件在外部社群中已大面积中招，内部仍靠个人提醒排查｜依据：「奇绩校友飞书群」2026-03

9. 分支变体

  • 服务器/中间件 CVE：资产清单比对 → 脚本批量检测内核/中间件版本 → 升级或禁用模块；新服务的中间件选型统一（是否默认 Caddy 待确认）
  • 依赖包投毒（npm/PyPI）：检查锁文件与安装记录、DNS 缓存与关键字；受影响即轮换全部凭据；CI 加 --ignore-scripts 并锁版本（RND-36）
  • 桌面开发工具投毒：近期打开过该工具的人员一律视为疑似，统一轮换密钥并检查服务器登录日志
  • AI 工具遥测/数据外传：评估数据流向，结论写入工具准入清单（X-SEC-36）；需要时改用无遥测的内部构建版本或自部署方案
  • 自部署开源服务漏洞：服务负责人确认实例版本并升级，结果回填
  • 外部 skill/泄露源码：外部 skill 入库前扫描，只用可信来源；泄露源码能否留存以法务结论为准
  • 开源协议（如 AGPL 对外提供服务需开源）：交 LEG-28 评估
  • 主体：跃竞技术部与模态/Leap 研发共用同一通告台账，各线指定回收对接人

10. 待确认问题

  • 安全通告响应负责人是否由 IT 运维承担？跃竞线是否单设对接人、由谁担任？
  • 是否建立独立“安全通告群”并接入 CVE 订阅机器人？
  • 严重级“当天回填、24 小时处置”是否可行？
  • 资产/依赖/工具清单由谁维护？是否与 X-SEC-40 的对外服务资产台账合并？
  • 曾被存入公司仓库的泄露源码，法务结论是什么、是否需要清理？
  • 是否规定定期密钥轮换周期（如每季度）？
  • 新服务是否统一使用 Caddy 替代 nginx？
X-SEC-42内网安全事件与异常请求溯源处置待新建120

状态：待新建｜证据：有证据（卡片 3 张 / 会话 3 个）｜优先级：频2 × 耗3 × 跨4 × 险5

  • 适用场景：内网出现异常扫描、端口爆破、疑似中毒，生产环境出现来源不明的请求或机器注册，或外部人员、云厂商发出安全告警与整改建议时，统一上报、隔离、溯源、清除并复盘
  • 负责人：主责——网络与 IT 运维（当前：杨明学·推断待确认）；协同——发现人/受影响服务负责人（当前：宋祺睿·推断待确认）、日志与研发排查（当前：吴世豪、陈晖、魏宗浩、杨云峰·推断待确认）、行政（终端装机与资产，当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 事件快报 → ② 指派与定级 → ③ 隔离止血 → ④ 日志溯源定位设备 → ⑤ 清除与恢复 → ⑥ 补齐终端防护 → ⑦ 复盘通报
  • 交付结果：安全事件记录单（时间线、来源设备、处置、根因）、复盘与改进项、更新后的终端防护覆盖清单与虚拟机台账
  • 状态依据：2026-04 内网中毒、2026-08 云厂商整改提醒、2026-10 生产异常注册三起事件均靠群内临时 @ 全员排查；出口路由只记录出口地址无法追到内网，机器指纹无台账对应，一次全员排查约 1 小时；终端安全软件早已决定安装但出事后才上门装机

1. 场景判定

  • 触发条件：
    • 防火墙/网络日志出现内网扫描、端口爆破流量
    • 终端出现可疑进程，或杀毒软件报警
    • 生产日志出现不明来源的请求、注册或调用
    • 外部人员、合作方或云厂商告知“内网有机器在扫内网”，或云厂商下发安全评估整改建议
  • 典型说法：「到底是谁在攻击生产环境」「都自查下」「说我们内网有机器中毒了在扫内网」「用公司电脑就得装，保护公司资产」
  • 判断问题：是不是有“正在发生的异常行为”，需要找到来源设备并止血？
  • 不归本流程管：
    • 已知漏洞的修复与遗留资产下线 → 请走 X-SEC-40
    • 外部 CVE/投毒通告排查 → 请走 X-SEC-41
    • 凭据轮换执行 → 请走 X-SEC-11
    • 终端安全软件常态部署与锁屏规范 → 请走 X-SEC-31
    • 非安全原因的线上故障 → 请走 RND-75
    • 办公网络故障报修 → 请走 X-SEC-27

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事件负责人 接单定级、组织止血与溯源、关单复盘 A/R 网络与 IT 运维（当前：杨明学·推断待确认）
发现人/服务负责人 提交快报、提供服务日志、执行服务侧封禁 R 受影响服务负责人（当前：宋祺睿·推断待确认）
日志排查 分析网关/服务/埋点日志、写抓包或日志插件 R 研发（当前：吴世豪、陈晖、魏宗浩、杨云峰·推断待确认）
设备使用人 配合排查、清理或重装设备 R 涉事设备使用人
行政 终端软件上门安装、资产登记 R 行政（当前：待指定）
CTO P0 事件决策、外部安全服务引入、强制装机规则 C（升级时 A） CTO（当前：丁震宇·部门报送人）
法务 数据外泄时评估通知义务 C 法务（当前：待指定）

3. 办之前请准备

  • 现象截图或日志片段、首次发现时间、受影响系统（生产/测试/办公网）
  • 可疑来源：IP、机器码/指纹、端口、请求特征
  • 出口与内网流量日志、防火墙日志的查看权限
  • 宿主机/虚拟机台账（宿主机、虚拟机、IP/MAC、负责人）
  • 云厂商告警原文或评估报告

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 发现人在安全事件群发“事件快报”（现象、时间、截图），不在多个群分散 @ 全员 发现人 发现后 15 分钟内 飞书表单、安全事件群 事件单 🔧飞书固化
2 接单并定级：P0=生产受攻击或数据外泄；P1=内网扩散/确认中毒；P2=可疑未证实 事件负责人 上报后 15 分钟内 事件单 等级与负责人 👤人工判断
3 止血：生产侧封禁来源 IP、拒绝异常注册；内网侧隔离可疑设备或网段；保留日志，不先重启 事件负责人、服务负责人 P0 30 分钟内；P1 2 小时内 防火墙、网关 止血记录 👤人工判断
4 溯源：按出口日志 → 内网流量日志 → DHCP/ARP → 宿主机/虚拟机台账 → 机器指纹的顺序定位设备与使用人；只定向询问，不发起全员自查 事件负责人、日志排查 P0 2 小时内；P1 1 个工作日内 网络日志、服务日志、PostHog 来源设备 🤖+👤
5 清除与恢复：清理或重装中毒设备/虚拟机，关闭违规服务，确认异常流量消失 设备使用人、事件负责人 定位后 1 个工作日内 终端安全软件 清除确认 👤人工判断
6 补防护：涉事设备及同网段未装终端安全软件的公司终端补装，更新覆盖清单 事件负责人、行政 事件结束后 3 个工作日内 IOA 控制台、覆盖清单 覆盖清单 🔧飞书固化
7 复盘：时间线、根因、失效环节、改进项（日志补源 IP/MAC、台账补齐、告警规则） 事件负责人 事件结束后 3 个工作日内 复盘模板 复盘记录 👤人工判断
8 云厂商告警/评估报告：逐项登记为整改项，转 X-SEC-40 跟踪 事件负责人 收到后 2 个工作日内 漏洞台账 整改项 🔧飞书固化

5. 交付物与模板

  • 交付物：事件记录单、复盘记录、终端防护覆盖清单、宿主机/虚拟机台账更新
  • 事件单字段：编号、发现时间、发现渠道（内部/外部/云厂商）、现象、受影响系统、等级、负责人、止血措施、溯源结果（设备/虚拟机/使用人）、根因、清除确认、改进项、关闭时间
  • 终端防护覆盖清单字段：设备编号、使用人、类型（公司资产/个人设备）、操作系统、终端安全软件安装状态、安装日期、最后在线时间
  • 宿主机/虚拟机台账字段：宿主机、虚拟机名称、IP/MAC、机器码、用途、负责人、到期日

6. 异常与升级

  • P0 事件 30 分钟内未止血 → 升级 CTO，必要时下线受影响服务
  • 溯源 1 个工作日无结果 → 升级 CTO 决定是否请云厂商或外部安全服务介入
  • 设备使用人拒绝排查或拒装终端安全软件 → 部门负责人当天协调；公司资产不装不得接入内网
  • 确认数据外泄 → 当天升级 CTO 与法务，评估客户/监管通知
  • 外部（客户、合作方、云厂商）告知事件 → 1 小时内回执，处置完成后回复结论

7. 衡量指标

  • 响应时长 = 快报到指派负责人，目标 ≤ 15 分钟
  • 溯源时长 = 快报到定位来源设备，P0 目标 ≤ 2 小时
  • 全员自查次数 = 需要 @ 全员自查才能定位的事件数，目标 0
  • 终端防护覆盖率 = 已装终端安全软件的公司终端 / 公司终端总数，目标 100%
  • 复盘完成率 = 已复盘事件 / 已关闭事件，目标 100%

8. 低效诊断

  • 现象：生产出现异常注册后在群里 @ 全员自查，逐个回复排除，全员排查约 1 小时｜依据：「Leap产研测」2026-10
  • 现象：出口路由只记录出口地址，内网无流量日志，机器指纹无台账可对应，只能靠个人记忆匹配到某台虚拟机｜依据：「Leap产研测」2026-10
  • 现象：内网中毒后各自写抓包/日志插件定位来源，两天后仍在追问是否找到中毒设备，事件没有闭环｜依据：「鸽子群模态分群」2026-04
  • 现象：终端安全软件上一年就计划安装但一直未落地，出事后才上门装机；个人设备是否必装口径不一｜依据：「鸽子群模态分群」2026-04
  • 现象：内网中毒由外部先发现、云厂商提醒后才整改，缺主动告警｜依据：「忠橙星行星引擎」2026-04、「忠橙星行星引擎」2026-08

9. 分支变体

  • 内网中毒/扫描：隔离设备或网段 → 流量日志溯源 → 杀毒或重装 → 补装终端安全软件
  • 生产异常请求/注册：网关封禁 → 注册日志补源 IP/机器码 → 对照虚拟机台账 → 清理来源虚拟机
  • 云厂商告警/评估报告：转为整改项进 X-SEC-40 跟踪
  • 设备类型：公司资产强制安装终端安全软件；个人设备接入内网的要求待定

10. 待确认问题

  • 安全事件主责是否为 IT 运维？夜间/周末由谁值守？
  • 是否建立独立的“安全事件群”和上报表单？
  • 内网流量日志需要保留多久？是否需要新增日志设备（涉及采购）？
  • 个人设备接入内网是否必须安装终端安全软件？
  • 生产注册日志补源 IP/MAC 的改造由谁负责、何时完成？
  • 是否把“自查 skill”作为辅助排查工具，由谁维护？
X-SEC-43等保测评、整改与云安全产品采购待优化375

状态：待优化｜证据：有证据（卡片 8 张 / 会话 4 个）｜优先级：频3 × 耗5 × 跨5 × 险5

  • 适用场景：产品/系统需要办理或复审等保（如鼎慧通、墨跃启智 AI 教育系统），从确定申报主体与范围、对接测评服务商、驻场测评、逐项整改、采购云安全产品、复测取证，到抽检与续费的全过程
  • 负责人：主责——等保项目经理（当前：赵雪冰·推断待确认）；协同——技术总对接与采购决策（当前：丁震宇·推断待确认）、系统整改负责人（鼎慧通当前：宋祺睿；AI 教育当前：葛家和、吴世豪·推断待确认）、技术方案（当前：王皓南·推断待确认）、开发（当前：徐鑫宇·推断待确认）、测试（当前：张东郅、李国庆·推断待确认）、产品（当前：杨萌·推断待确认）、预算审批（当前：邴龙志·推断待确认）、财务与法务（当前：待指定）；兜底——CTO（当前：丁震宇·部门报送人）
  • 核心流程：① 立项定主体与范围 → ② 服务商对接与资产表 → ③ 驻场测评出差距报告 → ④ 整改台账拆解与需求同步 → ⑤ 安全产品采购 → ⑥ 逐项整改留证 → ⑦ 复测与取证归档 → ⑧ 抽检与续费
  • 交付结果：等保测评报告（电子版+纸质版）、整改项台账（含截图证据与复测结果）、安全产品台账（含到期日）、等保脚本仓库、证书主体与使用范围登记
  • 状态依据：已有测评服务商、资产表、差距报告、等保脚本仓库、堡垒机等基础，但 2026-01～07 两套系统推进约半年：测评只能排到年后、整改人排期难对齐近 2 个月、复测又出新问题、采购被追问约 3 次、申报主体临近结束才确认，等保需求未经产品导致登录改造反复返工

1. 场景判定

  • 触发条件：
    • 产品投标、客户或主管部门要求等保证书
    • 合规检查要求系统整改
    • 等保复审、抽检通知
    • 等保相关云安全产品（堡垒机、WAF、漏扫、云防火墙、主机安全授权）到期
  • 典型说法：「先驻场测评，出整改方案我们对着改，改完再测一遍交报告」「等保要求限制上传文件类型」「公网访问都关了」「等保啥时候采购了」「给等保的开访问」
  • 判断问题：这个要求是否来自等保条款或测评方，结果是否关系到等保证书？
  • 不归本流程管：
    • 算法备案等专项资质 → 请走 LEG-25；软著 → 请走 POL-10
    • ICP 备案 → 请走 LEG-23
    • 日常生产访问权限申请 → 请走 X-SEC-18
    • 等保之外的常规漏洞整改 → 请走 X-SEC-40
    • 对公付款审批本身 → 请走 FIN-01

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
等保项目经理 排期、台账维护、催办、与服务商约时间、资料提交、证书归档 A/R 综合部负责人（当前：赵雪冰·推断待确认）
技术总对接 主体与范围建议、对接服务商与云厂商、谈价下单、授予权限 R CTO（当前：丁震宇·推断待确认）
系统整改负责人（鼎慧通） 资产表、整改、截图留证、等保脚本 R 后端/运维（当前：宋祺睿·推断待确认）
系统整改负责人（AI 教育） 资产表、整改、截图留证、约复测 R 研发（当前：葛家和、吴世豪·推断待确认）
技术方案 登录、限速、会话等安全方案设计 C 研发负责人（当前：王皓南·推断待确认）
开发 应用侧整改实现 R 后端研发（当前：徐鑫宇·推断待确认）
测试 验证整改且不破坏登录主路径 R 测试（当前：张东郅、李国庆·推断待确认）
产品 等保需求入需求池、对用户告知变更 C 产品负责人（当前：杨萌·推断待确认）
预算审批 超预算采购、续费与申报主体争议的最终审批 A（升级） CEO（当前：邴龙志·推断待确认）
财务 打款、发票 R 财务（当前：待指定）
法务 申报主体与证书使用范围 C 法务（当前：待指定）

3. 办之前请准备

  • 申报主体（以哪家公司名义）、系统名称、等级（如三级）、证书用途（投标/客户/监管）
  • 每个系统一份《等保测评信息系统资产表》（服务器、数据库、域名、网络拓扑、3 名管理员信息）
  • 现有安全产品清单（堡垒机、WAF、漏扫、云防火墙、主机安全授权）及到期日
  • 测评方访问方式：白名单 IP、测试账号、管理后台地址
  • 预算额度与采购审批路径；服务商合同

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 立项：确定系统清单、申报主体、等级、截止日期、每系统整改负责人；主体须由 CEO/法务书面确认 等保项目经理、技术总对接 需求提出后 5 个工作日内 飞书任务/项目台账 立项单 👤人工判断
2 与服务商签约并约驻场日期；整改负责人填资产表，技术总对接审核后提交 等保项目经理、系统整改负责人 立项后 10 个工作日内约定日期；资产表 5 个工作日内 资产表、飞书群 资产表、驻场日期 🔧飞书固化
3 为测评方开临时访问（IP 白名单/测试账号），登记开通与计划回收时间 系统整改负责人 驻场前 1 个工作日 访问登记表 访问登记 🔧飞书固化
4 驻场测评出差距报告后，拆成整改台账（测评项 → 整改项 → 负责人 → 截止 → 证据要求） 等保项目经理 报告后 2 个工作日内 多维表格 整改台账 🔧+🤖
5 影响用户体验的整改（双因素、会话时长、报错模糊化、验证码限频、上传类型限制）先进需求池评审；测试同步准备验证码测试通道 系统整改负责人、产品、测试 拆解后 3 个工作日内 需求池、Gitea issue 需求单 👤人工判断
6 列出必须的安全产品，向服务商确认必要性与折扣，走采购审批（FIN-01）后下单，登记安全产品台账 技术总对接、等保项目经理、财务 清单确认后 5 个工作日内下单 飞书审批、云控制台 采购单、产品台账 🔧飞书固化
7 逐项整改：基础设施（关公网、堡垒机、日志接入、云防火墙、主机安全）、账号（三权分立）、应用（双因素、会话、限速）、漏扫无高危；每项截图留证，脚本沉淀到等保脚本仓库 系统整改负责人、开发 按台账截止，整体 ≤ 20 个工作日 堡垒机、Gitea 整改证据 🤖+👤
8 内部漏扫与自检脚本通过后约复测；复测问题汇总在 3 个工作日内补完 系统整改负责人、等保项目经理 整改完成后 5 个工作日内约复测 漏扫、自检脚本 复测问题汇总 🤖自动化
9 提交资料，跟进约 2～3 周出电子版+纸质版报告；归档证照库并登记主体、有效期、可用产品范围；回收测评临时访问 等保项目经理 复测通过后 3 个工作日内提交 证照库 报告与登记 🔧飞书固化
10 保留安全配置；收到抽检通知按清单恢复被关闭的功能；安全产品到期前 30 天提醒，决定续费或退订 等保项目经理、系统整改负责人 到期前 30 天 飞书机器人提醒 续费决策 🔧+🤖

5. 交付物与模板

  • 交付物：等保测评报告、整改项台账、安全产品台账、测评访问登记、证书登记、等保脚本仓库
  • 整改项台账字段：系统、测评项/条款、整改项、类型（基础设施/账号/应用/管理制度）、负责人、截止日期、状态、证据截图、复测结果、是否影响用户、关联 issue
  • 安全产品台账字段：产品、所属系统、主体、云账号、规格、购买日期、到期日、负责人、是否等保必需、续费/退订决定
  • 测评访问登记字段：访问对象、开放方式、开通人、开通时间、计划回收时间、实际回收时间
  • 证书登记字段：系统、申报主体、等级、证书编号、有效期、可使用的产品与投标场景、存放位置

6. 异常与升级

  • 升级条件：采购或续费超出预算/无折扣、申报主体与证书使用场景不一致或需书面确认 → 等保项目经理升级预算审批（CEO）决定；预算内的安全产品采购按 FIN-01 走采购审批，其余推进事项由等保项目经理直接决定
  • 服务商排期延后超过 2 周 → 项目经理 2 个工作日内升级技术总对接与服务商负责人沟通
  • 整改负责人排期冲突 → 项目经理 1 个工作日内报 CTO 调整优先级（CEO-07）
  • 整改影响客户登录或业务 → 暂缓上线，产品与测试评估后由 CTO 拍板
  • 复测仍不通过 → 3 个工作日内补改；二次失败升级 CTO
  • 采购超预算或无折扣 → CTO 与 CEO 3 个工作日内决定；买错产品 → 7 天内申请退订
  • 申报主体与证书使用场景不一致 → 立即升级 CEO 与法务确认
  • 为测评临时开放的公网访问 → 测评结束当天回收

7. 衡量指标

  • 等保周期 = 立项到取证的自然日，目标 ≤ 90 天
  • 整改按期率 = 按截止完成的整改项 / 总整改项，目标 ≥ 90%
  • 复测次数 = 取证前复测次数，目标 1 次通过
  • 采购时效 = 整改清单确认到下单的工作日，目标 ≤ 5 天
  • 到期提醒覆盖率 = 已设提醒的安全产品 / 安全产品总数，目标 100%
  • 整改引发的线上登录类缺陷数，目标 0

8. 低效诊断

  • 现象：服务商约测评只能排到年后，整改人排期难对齐，两套系统拖了近 2 个月｜依据：「等保评估」2026-01、「等保评估」2026-03
  • 现象：整改项逐项补充，复测又出新问题，返工约 3 次｜依据：「等保评估」2026-03
  • 现象：后续进度长期无人牵头，到 4 月才指定专人推进；服务商沟通分散在微信群与飞书群两处｜依据：「等保评估」2026-04
  • 现象：申报主体到测评后期才说明，与公司对外口径不一致，证书可用性存疑｜依据：「鼎慧产研决策部」2026-04、「等保评估」2026-04
  • 现象：安全产品采购靠群里追问和临时付款，买后才发现漏扫未购、授权不足，又讨论退款｜依据：「等保评估」2026-03、「等保评估」2026-04、「鼎慧产研决策部」2026-04
  • 现象：等保整改需求未经产品评审，研发做完再补需求；验证码、限速、会话策略反复改，验证码阻断自动化测试｜依据：「工程咨询产研」2026-03
  • 现象：检查期间临时开关公网数据库访问，与数据迁移互相冲突｜依据：「工程咨询产研」2026-01
  • 现象：堡垒机是否已买、谁负责接入需现场追问；关闭公网后访问方式无文档，排查堡垒机授权问题耗时约 1 小时｜依据：「鸽子群模态分群」2026-01、「鼎慧产研决策部」2026-01
  • 现象：为测评开放的后台访问和 IP 白名单变更只在群里零散告知，进度靠追问｜依据：「鼎慧产研决策部」2026-01

9. 分支变体

  • 鼎慧通 / 墨跃启智（AI 教育）：各自一份资产表和整改项，分别指定整改负责人；申报主体在立项时确认（鼎慧通主体与模态口径需统一）
  • 测试环境与正式环境：测试后台另设域名；正式后台只对测评方 IP 临时开放
  • 堡垒机：商业版与社区版二选一时默认商业版（社区版不保证通过等保）
  • 应用端登录 / 管理后台登录 / 网盘（OIDC）认证的整改要求不同；后台高频登录可评估 U 盾类免密方案
  • 应对检查的方式：在原环境整改，或部署独立新环境专用于检查，由 CTO 在立项时决定
  • 复审与抽检：按清单恢复被关闭的功能（如验证码）；云安全资源到期需续费并检查是否影响业务

10. 待确认问题

  • 等保项目经理是否固定由综合部负责人担任？技术总对接是否仍由 CTO 兼任？
  • 申报主体规则：哪些产品用哪家主体？已取得的证书能否用于其他主体产品的投标？
  • “立项到取证 ≤ 90 天”是否可行？
  • 安全产品采购是否统一走 FIN-01 采购审批？与等保代理的折扣口径由谁负责？
  • 是否沉淀“一键等保自检”脚本/skill？等保脚本仓库由谁维护？
  • 已到期的云安全资源是否续费？抽检时需要恢复哪些功能？
  • 等保整改说明文档是否已完成，存放在哪里？
X-SEC-44数据泄露（含个人信息）事件响应与报告待新建推断125

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频1 × 耗5 × 跨5 × 险5

  • 适用场景：发现或怀疑客户数据、用户个人信息、员工信息或内部敏感数据被未授权访问、外传、误发或公开暴露
  • 负责人：主责——信息安全负责人（当前：待指定）；协同——研发负责人、法务（当前：待指定）、售后负责人（当前：待指定）、总经办（当前：田杰·部门报送人）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 发现上报 → ② 止损隔离 → ③ 影响评估 → ④ 判定是否通知客户/用户/监管 → ⑤ 对外通知 → ⑥ 根因整改 → ⑦ 事件报告归档
  • 交付结果：事件登记、影响评估报告、对外通知记录、整改清单与事件报告
  • 状态依据：已有 X-SEC-11（凭据泄露应急处置）、X-SEC-42（内网安全事件溯源）、LEG-31（代码外泄处置）覆盖部分环节，本条补齐以数据（尤其个人信息）为对象的泄露评估与对外通知（推断）

1. 场景判定

  • 触发条件：数据库/存储桶被公开访问；含客户数据的文件误发外部群；接口越权可批量拉取用户信息；外部告知发现公司数据
  • 典型说法：「这个桶是不是公开的」「客户的文件被发到别的群里了」「接口不登录也能查到别人的数据」
  • 判断问题：是否涉及客户数据、个人信息或可识别到人的数据？是否已被外部获取或可能被获取？
  • 不归本流程管：密钥/密码泄露 → 请走 X-SEC-11；内网异常扫描 → 请走 X-SEC-42；代码外泄 → 请走 LEG-31；外部 CVE 排查 → 请走 X-SEC-41；公司级危机统筹 → 请走 CEO-25；告知个人/客户与向监管报告的法律评估 → 请走 LEG-34（本流程负责技术响应与内部报告）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
事件负责人 组织止损、评估、出报告 R 信息安全负责人（当前：待指定）
研发负责人 技术止损与修复决策 A 研发负责人（当前：丁震宇·部门报送人）
法务 判断通知义务、审核通知文本 C 法务（当前：待指定）
售后/销售 按口径通知受影响客户 R 售后负责人（当前：待指定）
总经办 重大事件升级为 CEO-25 I 总经办（当前：田杰·部门报送人）
发现人 在安全事件入口上报 R 全体员工

3. 办之前请准备

  • 发现时间、发现方式、截图或日志（截图先打码）
  • 涉及系统、数据类别、预估条数、涉及客户或用户范围

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 在安全事件入口上报，不在大群扩散细节 发现人 发现后 30 分钟内 飞书表单 事件登记 🔧飞书固化
2 关闭公开访问、下线接口、撤回文件、保全日志 事件负责人+研发 上报后 1 小时内 云控制台 止损记录 👤人工判断
3 评估数据类别、条数、是否被外部获取、影响对象 事件负责人 24 小时内 访问日志 影响评估 🔧+🤖
4 法务判定是否须通知客户、用户或主管部门 法务 评估后 1 个工作日内 — 通知决定 👤人工判断
5 按审定口径通知受影响方 售后/销售 决定后 1 个工作日内 邮件/客户群 通知记录 🔧飞书固化
6 根因整改并复测，输出事件报告 事件负责人 10 个工作日内 工单系统 事件报告 🔧飞书固化

5. 交付物与模板

  • 交付物：事件登记、影响评估、通知记录、事件报告
  • 建议模板/表单：事件登记字段——发现时间、发现人岗位、系统、数据类别、预估条数、是否含个人信息、是否已外泄、止损措施、影响对象、通知决定、整改项、关闭时间

6. 异常与升级

  • 涉及个人信息或多家客户 → 1 小时内升级研发负责人与总经办，按 CEO-25 启动
  • 2 小时内无法止损 → 研发负责人决定是否停服

7. 衡量指标

  • 止损时长 = 上报到止损完成，目标 ≤ 1 小时
  • 事件报告按期完成率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在泄露后扩散范围不清、未按法定要求通知、客户信任受损的风险（推断）

9. 分支变体

  • 私有化实例内的数据事件由客户主导，我方提供协助与日志
  • 境外用户数据另需评估境外法规要求

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 安全事件统一入口用飞书表单还是指定群？
  • 对客户的通知时限是否在合同中有约定？
X-SEC-45个人信息分类分级、保留期限与用户权利请求处理待新建推断64

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨4 × 险4

  • 适用场景：产品收集用户个人信息与客户业务数据，需要分类分级、按期删除，并响应用户或客户的查询、导出、更正、删除、注销请求
  • 负责人：主责——个人信息保护负责人（当前：待指定）；协同——法务（当前：待指定）、产品负责人（当前：待指定）、后端负责人（当前：待指定）、售后负责人（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 建立个人信息清单并分级 → ② 定保留期限 → ③ 受理用户请求 → ④ 核验身份 → ⑤ 执行导出/更正/删除/注销并留痕 → ⑥ 回复用户 → ⑦ 每季度清理到期数据
  • 交付结果：个人信息清单、保留期限表、用户请求处理记录、季度清理记录
  • 状态依据：已有 LEG-18（隐私政策编制）、X-CS-02（账号封停溯源）覆盖部分环节，本条补齐个人信息清单、分类分级与保留期限，并按 LEG-34 口径执行删除/注销请求（推断）

1. 场景判定

  • 触发条件：新功能新增收集字段；用户或企业客户管理员要求查询、导出、删除数据或注销账号；每季度到期清理
  • 典型说法：「用户要注销账号，数据怎么删」「客户不续约了，要求把他们的文件都删掉并出证明」
  • 判断问题：请求对象是否为个人信息或客户数据？请求人是否为本人或客户授权管理员？
  • 不归本流程管：隐私政策文本 → 请走 LEG-18；登录与密码找回 → 请走 X-CS-08；研发使用数据 → 请走 RND-92；数据泄露 → 请走 X-SEC-44；退款 → 请走 X-CS-10；C 端产品用户请求的受理与答复 → 请走 OPS-29（本流程提供清单、保留期限与后端执行）；企业客户终止服务后的数据返还与销毁 → 请走 X-CS-29；答复时限、留存例外等法律口径 → 以 LEG-34 为准

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
个人信息保护负责人 维护清单与期限、审核请求 R 个人信息保护负责人（当前：待指定）
售后 受理请求、核验身份、回复 R 售后负责人（当前：待指定）
后端研发 执行导出/删除并出执行记录 R 后端负责人（当前：待指定）
法务 期限与例外（如需依法留存）判断 C 法务（当前：待指定）
产品 提供各功能收集的字段与用途 C 产品负责人（当前：待指定）
研发负责人 审定分级与保留期限 A 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 各产品收集的个人信息字段、存储位置、用途（含第三方 SDK）
  • 请求人身份证明或客户授权文件、账号信息

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 建立个人信息清单并分一般/敏感两级 个人信息保护负责人+产品 1 个月内首版；新功能上线前更新 多维表格 清单 👤人工判断
2 按用途确定保留期限与到期处理方式 个人信息保护负责人+法务 清单完成后 10 个工作日内 知识库 保留期限表 👤人工判断
3 登记请求：C 端用户请求由 OPS-29 转入，企业客户请求在售后工单登记 售后 收到后 1 个工作日内 工单系统 请求单 🔧飞书固化
4 核验身份（本人登录态或客户管理员授权） 售后 2 个工作日内 后台 核验结论 👤人工判断
5 执行导出/更正/删除/注销，保留执行记录 后端研发 核验后 5 个工作日内 后台/脚本 执行记录 🤖+👤
6 回复请求人；客户需要时出具删除确认函 售后 受理后 15 个工作日内 邮件/工单 回复记录 🔧飞书固化
7 按期限清理到期数据 后端研发 每季度末月 脚本 清理记录 🤖自动化

5. 交付物与模板

  • 交付物：个人信息清单、保留期限表、请求处理记录、清理记录
  • 建议模板/表单：请求单字段——请求类型、产品、账号、请求人身份、核验方式、涉及数据、执行人岗位、完成时间、回复时间

6. 异常与升级

  • 数据因计费、合同、税务等需依法留存 → 告知请求人留存范围与期限 → 法务确认（3 个工作日内）
  • 无法核验身份 → 暂停执行并告知补充材料

7. 衡量指标

  • 请求按期完成率 = 15 个工作日内回复的请求 / 请求总数，目标 100%
  • 到期数据清理执行率，目标 100%

8. 低效诊断

  • 聊天中未见相关流程，存在用户注销/删除请求无人承接、超期保存个人信息被投诉或处罚的风险（推断）

9. 分支变体

  • 私有化实例数据由客户管理员自行处理，我方提供操作指引
  • 俱乐部会员端涉及实名与资金数据，保留期限需结合资金结算规则

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 个人信息保护负责人由哪个岗位兼任？
  • 15 个工作日回复时限是否与隐私政策承诺一致（以 LEG-34 确认的口径为准）？
X-SEC-46账号与权限定期复核待新建推断96

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗3 × 跨4 × 险4

  • 适用场景：每季度对高权限与关键系统账号（飞书管理员、云平台子账号与 AccessKey、Gitea 管理员与仓库权限、生产服务器 SSH、网关管理员、数据库账号、第三方平台主账号）做复核，清理离职遗留、超范围与长期未用权限
  • 负责人：主责——IT 运维负责人（当前：待指定）；协同——各系统负责人（当前：待指定）、各部门负责人、人事（当前：待指定）；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 导出各系统账号权限清单 → ② 与在职名单及岗位比对 → ③ 系统负责人与部门负责人确认 → ④ 回收/降权 → ⑤ 出复核报告
  • 交付结果：季度权限复核表、回收/降权记录、复核报告
  • 状态依据：已有 X-SEC-08（离职/调岗账号回收与权限收口）覆盖事件触发的回收环节，本条补齐高权限与关键系统账号的周期性全量复核（推断）

1. 场景判定

  • 触发条件：每季度首月；组织架构大调整后；安全事件后
  • 典型说法：「这个 AK 是谁的，还在用吗」「已经走的人怎么还在仓库里」
  • 判断问题：账号是否对应在职人员与当前岗位？权限是否超出工作需要？近 90 天是否使用过？
  • 不归本流程管：离职当天回收 → 请走 X-SEC-08；新开通权限 → 请走 X-SEC-02、X-SEC-03、X-SEC-15；生产访问申请 → 请走 X-SEC-18；对外平台账号台账 → 请走 X-SEC-12

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
IT 运维负责人 组织复核、汇总、执行回收 R IT 运维负责人（当前：待指定）
系统负责人 导出清单、确认权限必要性 R 各系统负责人（当前：待指定）
部门负责人 确认本部门人员权限 C 各部门负责人
人事 提供在职、调岗、离职名单 C 人事（当前：待指定）
研发负责人 审定复核结论与例外 A 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 人事提供的季度在职/调岗/离职名单（含外包、实习生）
  • 关键系统清单及各系统负责人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 导出各系统账号、角色、最近登录时间 系统负责人 季度首月 10 日前 各系统后台/脚本 权限清单 🤖自动化
2 与在职名单比对，标出离职遗留、超范围、90 天未用 IT 运维负责人 导出后 3 个工作日内 多维表格 待确认清单 🤖自动化
3 发部门负责人确认保留/降权/回收 部门负责人 5 个工作日内 飞书任务 确认结果 🔧飞书固化
4 执行回收与降权，轮换共享凭据 IT 运维负责人+系统负责人 确认后 3 个工作日内 各系统 回收记录 👤人工判断
5 出复核报告并归档 IT 运维负责人 季度首月底前 知识库 复核报告 🔧飞书固化

5. 交付物与模板

  • 交付物：权限复核表、回收记录、复核报告
  • 建议模板/表单：复核表字段——系统、账号、对应人岗位、角色/权限、最近使用时间、异常类型、部门确认结论、执行结果、执行日期

6. 异常与升级

  • 发现离职人员仍可登录生产或云控制台 → 当日禁用 → 升级研发负责人
  • 部门负责人超期未确认 → 默认降为最小权限 → 通报部门负责人

7. 衡量指标

  • 复核按期完成率，目标 100%
  • 离职遗留账号数（季度发现），目标 0

8. 低效诊断

  • 聊天中未见相关流程，存在离职或调岗人员遗留高权限、共享 AK 无主、被利用造成数据或资金损失的风险（推断）

9. 分支变体

  • 外部协作方账号按 X-SEC-06 的到期日同步复核
  • 多主体云账号按主体分别复核

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 季度复核频率是否可行，哪些系统纳入首批范围？
  • 90 天未用即回收的口径是否合适？
X-SEC-47全员信息安全意识培训与考核待新建推断80

状态：待新建｜证据：推断（聊天中未见，按常规补充）｜优先级：频2 × 耗2 × 跨5 × 险4

  • 适用场景：新人入职、每年度及发生安全事件后，对全员（含实习生、外包与驻场人员）进行信息安全与保密培训、考核和钓鱼演练抽测
  • 负责人：主责——信息安全负责人（当前：待指定）；协同——人事（当前：待指定）、法务（当前：待指定）、各部门负责人；兜底——研发负责人（当前：丁震宇·部门报送人）
  • 核心流程：① 制定年度培训计划 → ② 编制课件与题库 → ③ 入职培训 → ④ 年度全员培训与考试 → ⑤ 钓鱼演练抽测 → ⑥ 统计与补训
  • 交付结果：培训课件与题库、培训与考试记录、演练报告、补训名单
  • 状态依据：已有 X-SEC-10（密钥与凭据分发规范）、X-SEC-31（终端安全与保密规范）、HR-06（新人入职培训）覆盖规范制定与入职培训环节，本条补齐系统化的全员信息安全培训、考核与钓鱼演练（推断）

1. 场景判定

  • 触发条件：新员工/实习生/外包到岗；年度培训周期；发生安全事件或新型风险（AI 工具外传、投毒）
  • 典型说法：「新人知道哪些东西不能发群里吗」「这种钓鱼邮件大家能认出来吗」
  • 判断问题：对象是否会接触公司账号、代码、客户数据或内部系统？
  • 不归本流程管：保密/开源规范制定 → 请走 LEG-27；入职培训整体安排 → 请走 HR-06；终端管控 → 请走 X-SEC-31；凭据规范 → 请走 X-SEC-10

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
信息安全负责人 课件、题库、组织培训与演练 R 信息安全负责人（当前：待指定）
人事 纳入入职清单、提供名单、跟进未完成人员 R 人事（当前：待指定）
法务 审核保密义务相关内容 C 法务（当前：待指定）
部门负责人 督促本部门完成 I 各部门负责人
全员/新人（受训人员） 按期完成课程、考试与补训 R 全体员工（含新人、实习生、外包与驻场人员）
研发负责人 审定年度计划 A 研发负责人（当前：丁震宇·部门报送人）

3. 办之前请准备

  • 现行规范：凭据分发、保密、开源、终端、AI 工具使用边界
  • 近一年内部安全事件案例（已脱敏）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 制定年度培训与演练计划 信息安全负责人 每年 1 月 知识库 年度计划 👤人工判断
2 编制课件与题库（凭据、AI 工具、钓鱼、终端、客户数据、保密） 信息安全负责人 计划后 1 个月内 知识库 课件/题库 🤖自动化
3 新人完成线上课程与考试 新人 到岗后 5 个工作日内 飞书考试/表单 考试记录 🔧飞书固化
4 年度全员培训与考试，80 分及格 全员 年度计划月内 飞书 成绩表 🔧飞书固化
5 每半年一次钓鱼邮件/消息演练 信息安全负责人 计划月内 演练工具 演练报告 🤖自动化
6 统计未完成、不及格与中招人员并补训 人事+信息安全负责人 结果后 10 个工作日内 多维表格 补训记录 🔧飞书固化

5. 交付物与模板

  • 交付物：年度计划、课件与题库、成绩表、演练报告
  • 建议模板/表单：培训记录字段——姓名、部门、类型（入职/年度/补训）、完成日期、成绩、是否通过

6. 异常与升级

  • 新人 5 个工作日内未完成 → 人事提醒并抄送部门负责人；10 个工作日未完成 → 暂缓开通生产与客户数据权限
  • 演练中招率高于 20% 的部门 → 安排专项补训

7. 衡量指标

  • 培训完成率，目标 100%
  • 钓鱼演练中招率，目标逐次下降，年度 ≤ 10%

8. 低效诊断

  • 聊天中未见相关流程，存在新人与外包不清楚安全红线、密钥与客户数据被误发或外传的风险（推断）

9. 分支变体

  • 研发、运维岗位增加生产访问、代码安全与 Agent 权限专题
  • 外包与驻场人员培训纳入 X-SEC-06 准入条件

10. 待确认问题

  • 本流程是否需要？是否已有线下做法？
  • 考试是否作为开通生产与客户数据权限的前置条件？
  • 钓鱼演练是否需要事先告知全员？

X-OTH 其他待定

报送人：待定 · 归属待定 · 3 条 · 已有 0 / 待优化 0 / 待新建 3
本部门清单（首轮报送口径）
编号SOP 名称适用场景负责人核心流程交付结果状态优先级
X-OTH-01上游模型/云服务供应商询价、折扣谈判与签约新增或扩量上游渠道（云厂官转、中转站、视频/生图模型厂商、云服务/软件），或供应商对接人变更、报价迟迟不出时启动主责——上游渠道采购负责人（当前：丁震宇·推断待确认）；协同——渠道运维与账户管理员（当前：杨明学·推断待确认）、合同与开户跟进人（当前：宋祺睿·推断待确认）、鼎慧主体技术负责人（当前：王皓南·推断待确认）、销售对外报价对接人（当前：闫登辉·推断待确认）、渠道接入研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）① 需求立项与询价清单 → ② 确定签约/使用账号主体 → ③ 多家询价与用量换折扣谈判 → ④ 测试额度审批与试跑 → ⑤ 合规与合同审核 → ⑥ 签约/开户/充值 → ⑦ 登记上游供应商台账并同步定价 → ⑧ 对接人与 SLA 维护已签署的折扣/代付/采购合同；上游供应商台账一行完整记录（供应商、账号主体、折扣、合同状态、对接人、SLA、到期日）；同步给网关定价与财务的折扣信息待新建300
X-OTH-02上游并发/TPM 配额提额申请与追进线上或测试出现 429/并发不足，或新模型上线、压测前需要上游提高并发/RPM/TPM 配额时启动主责——模型网关研发（当前：柯逸飞·推断待确认）；协同——上游渠道采购负责人（当前：丁震宇·推断待确认）、测试负责人（当前：张东郅·推断待确认）、模型评测/压测执行（当前：董洪焜·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）① 发现 429/预判容量 → ② 估算并发与 TPM → ③ 生成问题说明/申请单 → ④ 提交工单或商务群 → ⑤ 追进确认 → ⑥ 复测 → ⑦ 登记配额台账并设回收预警上游确认的新配额（并发/RPM/TPM）；复测通过记录；配额台账更新待新建144
X-OTH-03云厂商代金券与赠送额度登记及到期消耗云厂商赠送限期代金券、试用额度或配额，需要登记并在到期前按优先级合理消耗时启动主责——IT 运维/云账户管理员（当前：杨明学·推断待确认）；协同——评测任务负责人（当前：王皓南·推断待确认）、构建/部署平台研发（当前：杨云峰·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）① 收到券/额度即登记 → ② 设到期前 14 天/3 天提醒 → ③ 提出消耗方案 → ④ 拍板优先级 → ⑤ 执行消耗 → ⑥ 到期后关停资源并复盘代金券/额度台账记录；获批消耗方案；到期前的消耗记录与资源关停确认待新建54
X-OTH-01上游模型/云服务供应商询价、折扣谈判与签约待新建300

状态：待新建｜证据：有证据（卡片 5 张 / 会话 4 个）｜优先级：频4 × 耗3 × 跨5 × 险5

  • 适用场景：新增或扩量上游渠道（云厂官转、中转站、视频/生图模型厂商、云服务/软件），或供应商对接人变更、报价迟迟不出时启动
  • 负责人：主责——上游渠道采购负责人（当前：丁震宇·推断待确认）；协同——渠道运维与账户管理员（当前：杨明学·推断待确认）、合同与开户跟进人（当前：宋祺睿·推断待确认）、鼎慧主体技术负责人（当前：王皓南·推断待确认）、销售对外报价对接人（当前：闫登辉·推断待确认）、渠道接入研发（当前：吴世豪·推断待确认）、财务专员（当前：待指定）、法务（当前：待指定）；兜底——CEO（当前：邴龙志·推断待确认）
  • 核心流程：① 需求立项与询价清单 → ② 确定签约/使用账号主体 → ③ 多家询价与用量换折扣谈判 → ④ 测试额度审批与试跑 → ⑤ 合规与合同审核 → ⑥ 签约/开户/充值 → ⑦ 登记上游供应商台账并同步定价 → ⑧ 对接人与 SLA 维护
  • 交付结果：已签署的折扣/代付/采购合同；上游供应商台账一行完整记录（供应商、账号主体、折扣、合同状态、对接人、SLA、到期日）；同步给网关定价与财务的折扣信息
  • 状态依据：无上游供应商台账与成文流程；2026-05～08 期间折扣口径对不上（5 折/6 折/7 折、合同价高于官网价需复查）、账号主体归属反复追问、报价催办约 15 次以上，折扣与账密散落在聊天中，渠道账号仅一人掌握

1. 场景判定

  • 触发条件：需要接入新模型/新厂商；现有渠道用量上升需要谈更低折扣、更高并发或测试额度；采购云服务/软件（零信任网络、证书等）；供应商更换对接人或报价/合同超过 3 个工作日无回应
  • 典型说法：「新一代的都得用量谈」「问问所有主流模型的折扣」「鼎慧有折扣吗」「模态主体在这家云厂商没折扣」「他们好像换对接人了」
  • 判断问题：这件事是否需要和外部供应商确定价格、折扣、合同或账号主体？如果只是在已签约渠道内调整配额或做技术接入，不走本流程
  • 不归本流程管：已签约渠道的并发/TPM 提额 → 请走 X-OTH-02；代金券/赠送额度消耗 → 请走 X-OTH-03；折扣成本价与汇率维护 → 请走 FIN-28（模型成本价、计价倍率维护与成本收入核对）；渠道技术评估与试用 → 请走 RND-68（模型与上游供应商选型评测）；对公付款 → 请走 FIN-01（对公采购申请与付款审批）；账户充值 → 请走 FIN-03（上游账户充值与余额预警）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
商务谈判与拍板 定谈判策略、用量口径、折扣底线，审批测试额度 A/R 上游渠道采购负责人（当前：丁震宇·推断待确认）
渠道执行 发询价、跟进供应商、开账号、维护台账与账密托管 R 渠道运维与账户管理员（当前：杨明学·推断待确认）
合同与开户 合同版本比对、云厂合同控制台确认、开户 R 合同与开户跟进人（当前：宋祺睿·推断待确认）
鼎慧主体对接 鼎慧账号折扣谈判与确认 C 鼎慧主体技术负责人（当前：王皓南·推断待确认）
对外报价 根据成本价核对对外报价可行性 C 销售对外报价对接人（当前：闫登辉·推断待确认）
渠道接入 签约后技术接入 I 渠道接入研发（当前：吴世豪·推断待确认）
财务 付款主体、开票、充值 C 财务专员（当前：待指定）
法务 合同条款、对公采购与海外合规审核 C 法务（当前：待指定）

3. 办之前请准备

  • 询价模型/服务清单（模型名、预计月用量、并发需求、上线时间）
  • 近 1～3 个月真实用量报表（用于“用量换折扣”，对外口径统一）
  • 拟使用的签约/付款主体（模态、鼎慧、苏州/武汉模态等）及原因
  • 竞品渠道当前价格（至少 2 家对比）
  • 海外模型：白名单要求、是否可开票、付款币种
  • 现有台账中该供应商的历史折扣、合同到期日、对接人

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 提交上游采购需求（模型/服务、用量、并发、截止时间） 需求方研发 需求出现当天 飞书多维表格“上游采购需求” 需求记录 🔧飞书固化
2 确定签约与使用账号主体，查台账已有折扣 渠道运维与账户管理员 1 个工作日内 上游供应商台账 主体结论 🔧+👤人工判断
3 按模板向 ≥2 家发询价（含所有主流模型折扣） 渠道运维与账户管理员 需求后 2 个工作日内 询价模板、供应商群 询价单 🔧+🤖自动化
4 用量换折扣谈判；不确定时两边分流路由并同时谈 上游渠道采购负责人 询价回复后 5 个工作日内 会议/日程 折扣方案 👤人工判断
5 测试额度/最低准入套餐审批，试跑验证质量与并发 上游渠道采购负责人审批；渠道接入研发试跑 审批 1 个工作日内，试跑 3 个工作日内 飞书审批 审批单、试跑结论 🔧飞书固化
6 合同比对（折扣与官网价、并发、付款条款）及合规审核 合同与开户跟进人、法务 收到合同后 3 个工作日内 飞书合同审批、云厂合同控制台 审核意见 🔧+🤖自动化
7 签约、开户、首充；账密进统一密码库 合同与开户跟进人、财务专员 审核通过后 2 个工作日内 飞书审批、密码库 已签合同、账号 🔧飞书固化
8 登记台账，通知网关定价与财务成本价 渠道运维与账户管理员 签约当天 多维表格 + 群机器人 台账记录、通知 🔧+🤖自动化
9 供应商响应超时或对接人变更：拉群交接、更新台账 渠道运维与账户管理员；超时升级上游渠道采购负责人 超 3 个工作日无回复即升级 飞书群 更新后的对接人 🔧飞书固化

5. 交付物与模板

  • 交付物：已签合同（归档到合同库，不私发）；上游供应商台账记录；定价/成本价同步通知
  • 建议模板/表单：
    • 上游供应商台账字段：供应商、类型（云厂官转/中转站/视频模型/软件服务）、签约主体、使用账号、折扣（按模型）、并发/准入套餐、合同编号、合同状态、到期日、商务对接人、技术对接人、SLA（报价/工单响应时限）、账密托管位置、备岗人
    • 询价模板：模型清单、预计月用量、并发、付款主体、开票要求、报价截止日

6. 异常与升级

  • 供应商报价超 3 个工作日未回 → 渠道运维与账户管理员二次催办 → 第 5 个工作日升级上游渠道采购负责人找对方上级
  • 合同价高于官网价或折扣与谈判口径不符 → 暂停签约，回到谈判 → 上游渠道采购负责人（1 个工作日内）
  • 账号主体有争议（无折扣主体 vs 有折扣主体） → 上游渠道采购负责人与财务专员共同决定（1 个工作日内）
  • 海外模型无法开票或需白名单 → 法务与财务评估 → 上游渠道采购负责人拍板（3 个工作日内）
  • 对接人变更 → 当天在台账更新并拉新群，重要事项向原高层联系人确认

7. 衡量指标

  • 询价周期：需求提出到拿到 ≥2 家报价的工作日，目标 ≤ 5 天
  • 签约周期：需求提出到合同签署，目标 ≤ 15 个工作日
  • 台账完整率：在用上游渠道中台账字段齐全的比例，目标 100%
  • 折扣一致率：网关定价所用折扣与合同折扣一致的比例，目标 100%（每月抽查）
  • 单点风险：每个上游渠道有备岗人的比例，目标 100%

8. 低效诊断

  • 现象：折扣、合同、账密在聊天中流转，定价环节靠“转给我”获取折扣，多处折扣对不上需复查｜依据：「AI API」2026-07、「AI API」2026-08
  • 现象：签约/使用账号主体不清，同一云厂不同主体折扣不同，接入时反复确认用哪个账号｜依据：「AI API」2026-08、「鼎慧产研决策部」2026-05
  • 现象：对外用量口径不统一，云厂不同派系需分别沟通｜依据：「鼎慧产研决策部」2026-05
  • 现象：供应商报价/响应慢，靠反复催办和找对方领导推进；对接人更换后交接断档、合同未发到群｜依据：「忠橙星行星引擎」2026-02、「忠橙星行星引擎」2026-03、「忠橙星行星引擎」2026-07
  • 现象：测试额度、最低准入套餐需逐笔临时请示，无标准审批｜依据：「AI API」2026-06
  • 现象：渠道账号仅由单一岗位掌握，无备岗｜依据：「AI API」2026-08

9. 分支变体

  • 国内云厂官转（云厂商 A/B/C 等，同一云厂商不同派系需分别沟通）：按用量谈折扣，鼎慧主体与模态主体折扣不同，签约前必须确认主体
  • 海外模型：需白名单、可能无发票，须法务与财务前置评估
  • 中转站（中转站 A/B/C 等）：重点核对汇率口径、预充/实时结算方式和稳定性
  • 视频/生图模型厂商（模型厂商 A/B 等）：常有最低准入套餐，并发与充值金额挂钩
  • 软件/网络服务（零信任网络、EV 证书）：需 IT 先确认模块，再走报价审批与合同采购

10. 待确认问题

  • 主责是否固定为上游渠道采购负责人，日常执行是否可下放给渠道运维与账户管理员？
  • 测试额度/准入套餐的审批金额阈值是多少，是否走飞书审批？
  • 各主体（模态/鼎慧/苏州/武汉）签约与付款规则是否有成文制度？
  • 供应商响应 SLA（3 个工作日）是否可写入合同或合作约定？
  • 是否已有统一密码库，渠道账号的备岗人是谁？
  • 海外模型无票采购的财务处理口径？
X-OTH-02上游并发/TPM 配额提额申请与追进待新建144

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频3 × 耗3 × 跨4 × 险4

  • 适用场景：线上或测试出现 429/并发不足，或新模型上线、压测前需要上游提高并发/RPM/TPM 配额时启动
  • 负责人：主责——模型网关研发（当前：柯逸飞·推断待确认）；协同——上游渠道采购负责人（当前：丁震宇·推断待确认）、测试负责人（当前：张东郅·推断待确认）、模型评测/压测执行（当前：董洪焜·推断待确认）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 发现 429/预判容量 → ② 估算并发与 TPM → ③ 生成问题说明/申请单 → ④ 提交工单或商务群 → ⑤ 追进确认 → ⑥ 复测 → ⑦ 登记配额台账并设回收预警
  • 交付结果：上游确认的新配额（并发/RPM/TPM）；复测通过记录；配额台账更新
  • 状态依据：无申请模板与配额台账，2026-08～10 约 12 次临时处理，催办约 8 次；出现过申请过量被回收、压测未提前告知上游等问题，研发负责人明确要求“写文档”

1. 场景判定

  • 触发条件：线上/测试监控出现 429 或限流；新模型上线前；计划压测前；配额回收通知；试用额度耗尽需转后付费
  • 典型说法：「已催云厂商加急处理」「429 已经加急让上游处理了」「tpm 自部署也记得开大」「以后要压测得提前跟他们说一声」
  • 判断问题：是否是在已签约渠道内调整配额？问题是否确认来自上游限流而非我方网关配置？
  • 不归本流程管：新渠道询价、折扣与签约 → 请走 X-OTH-01；代金券/赠送额度消耗 → 请走 X-OTH-03；我方网关自身限流配置 → 请走 RND-71（模型档位路由与渠道切换变更）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
申请发起与追进 汇总 429 数据、估算配额、提交工单、追进、更新台账 R 模型网关研发（当前：柯逸飞·推断待确认）
上游商务对接 商务群加急、额度取舍拍板 A 上游渠道采购负责人（当前：丁震宇·推断待确认）
发现与复验 发现限流、提供复现说明、提额后复测 R 测试负责人（当前：张东郅·推断待确认）
压测 压测计划与提前通知上游所需数据 C 模型评测/压测执行（当前：董洪焜·推断待确认）

3. 办之前请准备

  • 429/限流证据：时间段、模型、渠道、错误比例、请求量曲线
  • 当前配额（并发/RPM/TPM）与近 7 天峰值实际用量
  • 目标配额估算依据（预计并发 × 平均 token × 安全系数，避免过量申请）
  • 上线/压测时间窗口
  • 上游工单入口与商务群信息（从配额台账获取）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 确认限流来源（上游 vs 我方网关），导出 429 数据 测试负责人/模型网关研发 发现后 1 小时内 网关监控、日志 问题确认 🤖自动化
2 估算目标配额，按实际峰值的 1.5～2 倍申请 模型网关研发 线上问题 2 小时内；上线/压测前 5 个工作日 配额台账 申请值 👤人工判断
3 AI 生成给上游的问题说明/提额申请 模型网关研发 同步骤 2 申请模板 + AI 申请单 🤖自动化
4 提交工单，同时在商务群 @上游；线上事故由商务对接加急 模型网关研发；上游渠道采购负责人 申请单完成后 30 分钟内 上游工单、飞书/商务群 工单号 🔧飞书固化
5 追进：线上问题每 2 小时跟进；非紧急每个工作日跟进 模型网关研发 至上游确认 飞书任务 跟进记录 🔧飞书固化
6 上游确认后复测 测试负责人 确认后 4 小时内 压测/冒烟脚本 复测结论 🤖自动化
7 更新配额台账，设置“低使用率回收”预警 模型网关研发 复测通过当天 多维表格 + 机器人 台账记录 🔧+🤖自动化
8 压测前用模板通知上游 模型评测/压测执行 压测前 2 个工作日 通知模板 通知记录 🔧飞书固化

5. 交付物与模板

  • 交付物：提额申请单、上游确认记录、复测结论、配额台账记录
  • 建议模板/表单：
    • 配额台账字段：渠道、模型、并发、RPM、TPM、申请时间、生效时间、峰值使用率、回收规则、工单号、申请人、上游对接人
    • 提额申请模板：现象、时间段、影响档位、当前配额、申请配额、估算依据、期望生效时间
    • 压测通知模板：压测时间窗、预计峰值 QPS/TPM、模型、联系人

6. 异常与升级

  • 线上 429 导致档位不可用 → 先在网关切换备用渠道或分流 → 2 小时未获上游确认升级上游渠道采购负责人电话加急
  • 上游拒绝或只给部分额度 → 评估分流到其他渠道 → 上游渠道采购负责人决定（1 个工作日内）
  • 收到配额回收通知 → 评估是否需保留，需保留则补用量或申请保留 → 上游渠道采购负责人（回收日前 3 个工作日）
  • 试用额度耗尽 → 走后付费开通，涉及付款转 X-OTH-01/FIN-01

7. 衡量指标

  • 提额响应时长：提交到上游确认，线上问题目标 ≤ 4 小时，计划性目标 ≤ 3 个工作日
  • 429 影响时长：首次 429 到恢复，目标 ≤ 2 小时
  • 配额利用率：峰值实际用量 / 申请配额，目标 30%～70%（过低易被回收）
  • 计划性提额占比：上线/压测前提前申请次数 / 全部提额次数，目标 ≥ 80%
  • 压测提前通知率：目标 100%

8. 低效诊断

  • 现象：每次提额依赖人工反复催办，无工单跟进机制｜依据：「AI API」2026-09
  • 现象：申请值没有估算依据，曾申请远超实际用量导致浪费或被回收｜依据：「AI API」2026-08、「AI API」2026-10
  • 现象：每个上游重复同一套步骤，无模板，研发负责人需逐次提醒步骤｜依据：「AI API」2026-10
  • 现象：多档位合并到同一渠道后未预先评估配额，直接撞上限额｜依据：「AI API」2026-09
  • 现象：压测前未通知上游，事后才得知需提前告知｜依据：「AI API」2026-10

9. 分支变体

  • 公有渠道提额（云厂商 A/B/C 的生图模型、大模型并发与 TPM）：工单 + 商务群
  • 自部署 TPM：在自部署控制台调整，同样登记台账
  • 试用额度耗尽：转后付费开通，涉及付款走 X-OTH-01/FIN-01
  • 部分云厂商：压测须提前告知上游

10. 待确认问题

  • 主责是否为模型网关研发？LeapAll 网关的提额是否由其研发负责人对应执行？
  • 申请倍数（峰值 1.5～2 倍）与利用率目标是否合理？
  • 上线前清单是否加入“配额申请”项，由谁检查？
  • 配额台账是否与 X-OTH-01 的上游供应商台账合并为一张表？
  • 各上游的工单入口与加急方式是否已有记录？
X-OTH-03云厂商代金券与赠送额度登记及到期消耗待新建54

状态：待新建｜证据：有证据（卡片 1 张 / 会话 1 个）｜优先级：频2 × 耗3 × 跨3 × 险3

  • 适用场景：云厂商赠送限期代金券、试用额度或配额，需要登记并在到期前按优先级合理消耗时启动
  • 负责人：主责——IT 运维/云账户管理员（当前：杨明学·推断待确认）；协同——评测任务负责人（当前：王皓南·推断待确认）、构建/部署平台研发（当前：杨云峰·推断待确认）、财务专员（当前：待指定）；兜底——研发负责人（当前：丁震宇·推断待确认）
  • 核心流程：① 收到券/额度即登记 → ② 设到期前 14 天/3 天提醒 → ③ 提出消耗方案 → ④ 拍板优先级 → ⑤ 执行消耗 → ⑥ 到期后关停资源并复盘
  • 交付结果：代金券/额度台账记录；获批消耗方案；到期前的消耗记录与资源关停确认
  • 状态依据：无云资源额度台账与到期预警；2026-07～08 多次在到期前两天才集中讨论怎么花，需周末跑脚本/评测临时消耗，存在过期浪费和乱开资源的风险

1. 场景判定

  • 触发条件：云厂商发放代金券/试用额度；站内信或销售通知额度即将到期；台账提醒到期前 14 天
  • 典型说法：「赶紧花云厂商代金券了，这两天得花完」「不知道这些余额能拿来干啥了」「先跑一晚上看看情况」
  • 判断问题：这笔额度是否有到期日？不用会不会浪费？消耗方式会不会产生券外的后续费用？
  • 不归本流程管：付费采购与折扣谈判 → 请走 X-OTH-01；配额提额/回收 → 请走 X-OTH-02；云资源常规付费充值 → 请走 FIN-03（上游账户充值与余额预警）；对公付款 → 请走 FIN-01（对公采购申请与付款审批）

2. 角色（RACI）

角色 职责 R/A/C/I 岗位（当前人员）
登记与提醒 登记额度、到期日、设置提醒、开账号 R IT 运维/云账户管理员（当前：杨明学·推断待确认）
优先级拍板 决定消耗用途与优先级 A 研发负责人（当前：丁震宇·推断待确认）
使用方 用额度跑评测/测试 R 评测任务负责人（当前：王皓南·推断待确认）
环境支持 一键起停测试环境 C 构建/部署平台研发（当前：杨云峰·推断待确认）
财务 确认券外费用、入账 I 财务专员（当前：待指定）

3. 办之前请准备

  • 券/额度信息：云厂商、账号主体、面额、余额、适用产品范围、到期日、限制条件（rpm/tpm）
  • 当前待跑的评测、压测、测试环境需求清单
  • 券外计费规则（超额、券后自动续费等）

4. 步骤

# 动作 执行人 时限 工具/系统 产出 提效方式
1 收到券/额度当天登记台账 IT 运维/云账户管理员 收到当天 多维表格 台账记录 🔧飞书固化
2 设置到期前 14 天、3 天自动提醒 IT 运维/云账户管理员 登记当天 多维表格自动化/机器人 提醒规则 🔧+🤖自动化
3 收到 14 天提醒后，收集用途提案（评测、测试环境、模型调用） IT 运维/云账户管理员 提醒后 2 个工作日内 飞书群/表单 消耗方案 🔧飞书固化
4 评估人力成本与收益，拍板优先级 研发负责人 方案提交后 1 个工作日内 飞书群 获批方案 👤人工判断
5 执行消耗：评测任务排期、IaC 一键起测试环境 评测任务负责人、构建/部署平台研发 到期前 3 个工作日完成 评测仓库、IaC 模板 消耗记录 🤖自动化
6 到期当天关停临时资源，核对无券外费用 IT 运维/云账户管理员 到期当天 云控制台 关停确认 🔧+🤖自动化
7 更新台账消耗结果，财务入账 IT 运维/云账户管理员、财务专员 到期后 2 个工作日内 多维表格 结案记录 🔧飞书固化

5. 交付物与模板

  • 交付物：额度台账记录、消耗方案、关停确认
  • 建议模板/表单：
    • 额度台账字段：云厂商、账号主体、额度类型（代金券/试用额度/赠送配额）、面额、余额、适用范围、限制条件、到期日、消耗方案、使用方、状态（未用/消耗中/已用完/已过期）、过期金额
    • IaC 测试环境模板：规格、起停命令、负责人、自动关停时间

6. 异常与升级

  • 到期前 3 天余额仍超过 30% → 升级研发负责人决定加速消耗或放弃（1 个工作日内）
  • 消耗过程中产生券外费用 → 立即停资源 → 通知财务专员与研发负责人（当天）
  • 云厂商销售长期无人对接 → 由 IT 运维/云账户管理员接手并登记到 X-OTH-01 供应商台账

7. 衡量指标

  • 额度利用率：到期前实际消耗 / 面额，目标 ≥ 90%
  • 过期浪费金额：每季度统计，目标趋近 0
  • 登记及时率：收到当天登记的比例，目标 100%
  • 券外意外费用次数：目标 0

8. 低效诊断

  • 现象：额度和到期日无登记，到期前两天才集中讨论怎么花｜依据：「鸽子群模态分群」2026-08
  • 现象：账户余额长期无人规划用途｜依据：「鸽子群模态分群」2026-07
  • 现象：券快到期才发现，需周末临时跑脚本/评测消耗｜依据：「AI API」2026-07
  • 现象：云厂商销售长期无固定对接岗位｜依据：「鸽子群模态分群」2026-07

9. 分支变体

  • 云厂商代金券：常见到期集中消耗，优先用于评测任务
  • 配额回收前“冲用量”：属配额管理，按 X-OTH-02 处理
  • 模型调用额度 vs 计算资源额度：前者优先评测/压测，后者优先 IaC 测试环境，用完即关

10. 待确认问题

  • 主责是否为 IT 运维/云账户管理员？是否需要备岗？
  • 到期前 14 天/3 天两次提醒是否足够？
  • 额度台账是否并入 X-OTH-01 上游供应商台账？
  • 消耗优先级是否有固定顺序（评测 > 压测 > 测试环境）？
  • 是否已有可用的 IaC 一键起停模板？

岗位与人员对照表（推断，待确认）

用途：供各 SOP 中“岗位（当前：某某·推断待确认）”引用。 来源：第 1 部分来自 CEO 部门报送口径（已知事实）；其余来自聊天中的工作观察，非正式任命，以各部门确认为准。 口径说明：

  • “依据次数”= 出现该人全名（含明显错字变体）的观察块数，仅以缩写（如 ymx、sonui、nk）出现的块未计入。
  • 标“推断”的内容来自聊天语境，未经本人或组织确认。
  • 只记录工作职责，不含联系方式、薪酬、绩效、个人人事事件、健康等信息。
  • 合并的同名/错字：黄鹏飞→黄飞鹏；侯屹晨→侯怡辰；黄振峰→黄振锋；黄莺→黄莹；李布凯/李步凯→李凯（推断）；陈真→陈震（推断）；hmy/猴米→侯明月（推断）；Kevin/kv→陈晖（推断）。

1. 部门报送人（CEO 口径，已知事实）

条线/部门 子职能 报送负责人
生态市场条线 （条线负责人） 许君
生态市场条线 研究院生态 陈梦琪
生态市场条线 品牌 何思雨
生态市场条线 政策申报 王蕊
销售 — 许君、李鹏为
运营 — 李宣昊
研发 — 丁震宇（创始人兼 CTO）
综合 （部门负责人） 赵雪冰
综合 总经办 田杰
综合 行政 胡则瑾
综合 财务 黄梦婷
综合 法务 李瑶
综合 人事 黄莹

2. 内部人员观察表

2.1 集团管理层 / 创始团队

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
邴龙志 CEO/研究院院长（推断），公司最终决策人 模态集团/研究院 战略与组织架构、预算审批、政府与高校生态对接、制度拍板 93
常元和 COO/联合创始人（推断，个别块称 CEO） 模态集团 商务定价、合同终审、媒体口径、客户关系、商标与产品命名 68
丁震宇 多重角色：创始人兼CTO＋基座/项目部负责人＋IT与资源审批 模态集团·研发 技术路线拍板、云账号/Gitea/飞书管理、采购预算、技术招聘定岗 136

2.2 研发·产品与设计（Leap 系列 / 鼎慧）

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
杨萌 多重角色：产品总监＋鼎慧负责人＋交付SOP统筹 鼎慧/Leap 产研 需求池与迭代、产品验收、发版口径、交付订单与渠道系统推进、对外演示 108
杨黔昆 产品/运营（LeapCore 产品团队） Leap 产研 更新日志、需求池记录、反馈与 Badcase 表单、文档站 17
黄飞鹏 产品经理（网盘/工程版） Leap 产研/鼎慧 需求表与排期、网盘产品规则、帮助中心、软著材料 24
陈震 产品经理（LeapCore 客户端/LeapNew） Leap 产研 需求登记与排期、更新日志、产品走查、反馈群值班 20
康紫馨 UI/UX 设计师 Leap 产研 Figma 设计稿、Logo/UI 设计、UI 岗面试 13
陈伟康 UI 设计（推断） Leap 产研 设计图 2
毛鹏程 产品设计（推断） Leap 产研 反馈分流 skill 调试、开发大赛组织 4

2.3 研发·Leap 产研（LeapCore / LeapAll / LeapNew / v5）

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
王皓南 Leap 研发/技术负责人（nk，推断） Leap 产研 迭代规划与站会、工单系统、发版闸门、技术方案拍板、v5 网关 105
岳阳 LeapAgent/客户端核心研发，PR 主合并人 Leap 产研 Agent runtime、PR 评审合并、客户端打包签名、OTA 发版 66
宋祺睿 多重角色：后端＋运维/发版＋云资源与权限开通 Leap 产研 v5 cloud/LeapAuth、生产部署、域名备案、Gitea权限、等保 112
杨云峰 LeapCore 后端/部署（多重：交付SOP、算法推理） Leap 产研 LeapAuth/LeapUpdate、容器与集群部署、OOBE、客户机排障 60
邓乾 多重角色：LeapAll服务端＋投资人版/FDE研发 Leap 产研 钱包计费、NewAPI对接、OTA、ClawLite、PPT Skill 60
李铭熙 客户端打包/Skill Store（多重：某燃气集团客户项目、算法） Leap 产研 Mac 打包签名、LeapSkill 后台、某燃气集团客户配置、尚品项目 43
魏宗浩 研发（Agent/skill/数据爬虫/可观测） Leap 产研 skill 打包、PostHog 上报、企查查/OCR 接入、50 环境发布 52
柯逸飞 NewAPI/模型网关与计费研发 Leap 产研 模型接入与价格配置、额度充值、账单导出、网盘功能 38
葛家和 多重角色：客户端前端＋生态组/OPC平台研发 Leap 产研/生态 LeapNew 前端与 OTA、帮助中心、OPC 商城后端、等保整改 38
马漳毓 LeapPPT 核心研发 Leap 产研 PPT 工作台、生图、会议系统、LeapPPT 发版与故障响应 38
吴世豪 CI 负责人＋LeapVPN 负责人 Leap 产研 CI/runner、签名机、LeapVPN、v5 网关备用维护 45
曾庆奥 前端/基础设施研发 Leap 产研 Cloudreve 集群、LeapNew、工单验收流程 7
陈子康 研发（渠道系统/CRM 接手人） Leap 产研/内部 FDE 渠道系统、CRM、合同自动填充、业财 SaaS 22
张康 研发（多重：容器/NewAPI、FDE 项目运维） Leap 产研/项目部 容器镜像、NewAPI 计费层、军区/某燃气集团客户项目部署 26
裴蔬桐 前端/全栈研发 Leap 产研/项目部 LeapCore 前端、Demo 开发、CAD 预研 15
白睿起 研发/测试（推断） Leap 产研 尚品项目研发测试 2

2.4 研发·字字可研 / 工程版（鼎慧）

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
季学森 前端负责人/测算模块负责人 鼎慧 测算 calculator、前端 PR 评审、官网/landing page 32
侯怡辰 前端/插件研发 鼎慧 编辑器、插件机制、灰度与发布告警、DevKit 18
陈锦杰 后端研发（支付/插件） 鼎慧/Leap LeapPay/MercPay、电子合同、工程咨询插件、通知系统 24
徐鑫宇 后端/全栈研发 鼎慧 知识库搜索、项目管理、登录注册 6
王满 工程咨询业务专家/FDE（推断） 鼎慧 提示词与 skill 维护、业务验收、客户培训与演示 20

2.5 研发·测试与评测

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
张东郅 测试负责人（多重：评测、一度兼产品） Leap 产研 验收与冒烟、P0/P1 定级、压测/AI 评测、测试招聘 74
潘浩伟 测试（信创主测） Leap 产研 提单与验收、信创测试报告 19
涂维轩 测试 Leap 产研 提 Bug、验收 9
李国庆 测试（鼎慧线测试负责人，推断） Leap 产研/鼎慧 冒烟测试、Bug 登记与验证 25
黄霆瑄 测试/评测 Leap 产研 Badcase 收集分析、LeapAgent 基准评测 20
陶铎 测试 Leap 产研 测试验收 3
余超 测试 Leap 产研 测试验收 2
董洪焜 模型评测（推断） Leap 产研 模型 bench 评测 3
李慧珍 评测/内容（推断） Leap 产研 竞品评测 1

2.6 研发·基座组 / 项目部 / 信创

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
陈晖 基座组架构/预研负责人（多重：技术招聘主力） 基座组 RAG/KB 重构、Harness、笔试出题与面评、多维表格流程 36
望政韬 多重角色：基座研发负责人＋NewAPI早期管理员 基座组 GraphBase/LeapBase 架构、NewAPI、水利/某水利企业项目、面试官 52
黄振锋 FDE Leader/核心项目负责人 项目部 项目评估与报价审核、POC 交付、PRM 系统、LeapBase 开发 27
李子遥 信创&Linux 适配负责人，开源布道 基座组/生态 信创打包流水线、开源布道讲师、TeamDNA 17
李玄冰 研发（知识库/网盘/军区版） 基座组 知识库开发、LeapPan、军区版打包 6

2.7 开放平台 / FDE

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
郭逸非 多重角色：开放平台负责人＋渠道系统负责人 开放平台/FDE LeapOpen 下发与插件门禁、渠道系统后端、CRM、FDE 准入 42
吴亚军 开放平台/FDE 课程负责人 开放平台/FDE 开放平台架构与账号、FDE 课程与认证规则 16
李凯 多重角色：FDE子部门负责人＋运营负责人＋Skill负责人 FDE/运营 培训课程、投资 Skill、运营 SOP、媒体与官网宣发 42
杨睿 开放平台后端/运维 开放平台 开放平台后端、证书、渠道系统 DB、CRM 部署 7
何放 开放平台前端 开放平台 前端开发 1
佘天禾 FDE 成员 FDE 需求评估与 Skill 验收、数据看板、授课 QA 4
盛亦舒 FDE 评测（推断） FDE Skill 前后测与竞品对比 1
裴建武 内部 FDE/研发 FDE/生态平台组 合同/积分/CMS 系统、LeapVPN 一期、社区功能 12
李奎星 交付/IT（推断） FDE/交付 装机、注册、账号机器支持 3

2.8 IT 运维 / 硬件交付

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
杨明学 多重角色：IT运维/网管＋采购资产＋aiapi渠道维护 IT/基础设施 网络机房、服务器与 PVE、设备采购与资产、备案证书、上游渠道 100
游家豪 运维/交付部署工程师 IT/交付 现场部署装机、硬件交付收口、设备登记与库存、客户 WG 配置 58

2.9 生态市场条线

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
许君 生态市场总监（多重：政策申报统管、品牌宣发） 模态跃迁/生态市场 对外资料与 FAQ、渠道沙龙、内容统筹、申报事项、渠道知识库 19
陈梦琪 多重角色：生态组负责人＋OPC社区/教育运营 研究院生态 生态活动与会务、OPC 商城运营、教育项目、开源聚变社区 29
王蕊 政策申报 生态市场 政策申报操作 2
谌思铭 政策申报操作（推断） 生态市场 政策申报操作 1
谭涛 生态运营 研究院生态 生态 SOP 文档、话术、联系台账 1
蔡鸿坤 生态运营 研究院生态 电话联系 1
侯晨帆 生态运营 研究院生态 官微与 Q&A 1
徐沛 新媒体 研究院生态 推文 1
郭昊 会务 研究院生态 会务与反馈收集 1
张家瑞 AI 讲师/班主任 研究院生态 课程、认证题库、现场支持 1
梅立 AI 讲师/助教 研究院生态 课程与现场支持 1
白福康 比赛/案例组长（推断） 生态 Claw 案例组对外汇报、比赛组织 3

2.10 销售

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
李鹏为 市场销售负责人/市场总监 销售 销售体系与渠道政策、报价特批与合同审批、供应商谈判 29
闫登辉 多重角色：销售骨干＋渠道负责人＋CRM管理员 销售 渠道协议与报价、客户演示、案例与申报材料、演示机账号 44
吴琪 销售总监/客户经理 销售 才汇/某工程咨询客户等客户对接、行业版方案、合同模板需求 25
杨朋伟 商务/项目经理 销售 教育/OPC/投资版客户、报价与签约、客户资源表 27
刘昱潇 苏州子公司/苏州销售负责人 销售/苏州研究院 水利与制造业大客户、POC、LeapBase、报价汇总 25
杜中瑞 销售 销售 渠道客户对接、报价整理、提单 12
陈名赞 销售 销售 客户拜访、提单 5
时建 政企大客户销售 销售 政企大客户、电信体系、金控项目 9
汪家诺 销售 销售 台账、提单、助教排班 6
朱文瑜 销售 销售 客户反馈、提单 4
韩诗琪 销售运营/销售支持 销售/市场 台账与 CRM、会议纪要、样机 SOP、软著与布展材料 16
陈芷青 市场部 市场 样机管理、生态认证宣发、竞品评测 4
邱诗妍 销售支持（推断） 销售 会议纪要 1
彭晏仪 渠道/推广（推断） 销售/运营 渠道推广 3

2.11 运营

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
李宣昊 新媒体运营（报送为运营负责人） 运营 公众号/视频号/小红书、视频制作 7
鲁周毅 运营/新媒体（个别块称运营部负责人） 运营 新媒体与活动、官网内容验收、AI 日报 8
胡橙橙 运营/客服 运营 KOL 沟通、话术、用户访谈、现场演示 3
刘田璐 运营/新媒体 运营 新媒体内容 1
吴文葶 运营 运营 社交媒体、私域 1
谢昕璟 社区/AI 商城运营 运营/生态 社区与商城运营 2
林子淇 运营/设计（推断） 运营 开发协作、现场物料发放 3

2.12 综合（总经办 / 行政 / 财务 / 法务 / 人事）

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
赵雪冰 综合部负责人/总经办/总助 综合 制度与档案、申报统筹、用印与合同流转、知识产权、业财融合 35
田杰 总经办（多重：档案委员、IT采购） 综合·总经办 制度通知、合同/许可/付款、金蝶与 CMS/PRM 需求 15
王欣 总经办/综合部 综合·总经办 培训与 DailyWork 通知、营业执照登记、答疑机器人维护 8
董蓝汐 总经办档案管理 综合·总经办 档案库与资产管理体系搭建 3
胡则瑾 行政负责人 综合·行政 场地与采购、团建福利、零食系统、日报机器人 14
侯明月 多重角色：行政＋盖章/接待（曾列生态合作经理） 综合·行政 盖章与合同台账、采购、会议室与接待、大会物料 31
丁蕊 行政助理/会务 综合·行政 工牌、团建、会务执行 7
黄梦婷 财务负责人 综合·财务 付款与报销、开票收款、对账、研发费用归集 24
刘梦可 财务 综合·财务 付款、报销、云账单 2
祁航 财务/出纳（早期，已交接） 综合·财务 采购下单与打款、发票接收 13
李瑶 法务负责人 综合·法务 合同模板与审核、合规意见 8
黄莹 人事负责人（多重：飞书审批管理员） 综合·人事 招聘全流程、入转调离、考勤与制度、审批流开通 44
张欣怡 HR 招聘专员 综合·人事 简历上传、约面、候选人沟通 11
匡蓉 HR 招聘助理 综合·人事 简历上传、约面、产品岗一面 4
王丽菲 HR 招聘专员 综合·人事 招聘执行 1

2.13 跃竞 / 跃玩（含星域、弈荟、EG 相关）

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
徐莉 跃竞负责人＋产品/项目统筹 跃竞 需求与优先级、验收、商户与汇付对接、招聘录用决策 24
王子明 多重角色：后端负责人＋汇付支付技术顾问 跃竞 支付分账、PR 合并与发版、数据库、后端笔试面试 22
张楠 后端/全栈 跃竞 订单/会费/投诉、慢 SQL 优化、获客线索工具 16
蒋兴武 后端 跃竞 会员/VIP 体系、分账钱包、告警修复 10
魏小东 前端负责人（小程序） 跃竞 星域小程序、提审发布、更新日志 11
陈真炎 网页端前端 跃竞 管理后台前端、网页更新日志 6
郝智豪 会员端前端 跃竞 会员端/猩球/弈荟前端、版本日志 6
王雨 后端/全栈 跃竞 支付链路重构、订单查询修改 4
林瑾鸿 会员端后端 跃竞 陪玩大厅、抢单推送、昵称审核 4
董本义 后端 跃竞 评价、动态、排行榜、CDK 3
赵伟龙 测试负责人 跃竞 需求测试、自动化脚本、测试报告 7
席博田 运维/基础设施 跃竞 集群迁移、Grafana 告警、安全巡检 7
段涵 多重角色：产品经理（早期鼎慧产品） 跃竞/鼎慧 需求文档与原型、评审会组织、验收 13
樊九辰 产品 跃竞 数据大屏、营销活动、优惠券 PRD 1
陈雁 多重角色：会员端产品经理＋招聘助理 跃竞 评审与验收、更新日志、BOSS 初筛 7
史家宜 UI 设计师 跃竞 会员端/星域设计稿 3
宫经喜 多重角色：内容/视频运营＋商户入驻 跃竞/模态品牌 视频与文案、商户入驻、品牌视频与摄影 12
刘安达 获客/客户教学 跃竞 获客与客户教学 2
黄捷 销售/市场 跃竞 销售/市场 1
飞书用户8994FW（淼哥，实名未见） 销售/商务（推断） 跃竞 客户入驻、合同、线索工具销售 3

2.14 子公司

姓名 观察到的岗位/职责（≤30字） 所属团队/主体 典型负责事务（≤40字） 依据次数
白立新 曜途（招投标子公司）CTO/技术负责人 上海曜途 招投标审查系统、合同/制度审查工作流 9
赵捷 子公司 CEO（推断） 子公司 子公司 HC 沟通 2

内部合计：126 人（另有 NK AI、模态助手、Leap Dude、Spock 等机器人账号，不计入人员）。

4. 岗位归口待确认（岗位口径）

  • 负责人多头 / 待明确：运营负责人、品牌岗实际执行人、政策申报统筹、Leap 研发负责人、FDE 负责人、开放平台负责人、交付统一负责人、信创负责人、测试负责人（鼎慧线）、飞书管理员与审批流归口、知识产权归口、用印归口。
  • 单点风险岗位（无明确备岗）：CTO 岗位（云账号、代码仓库、飞书应用、预算与采购审批集中）、IT 运维岗位（网络、机房、资产集中）、代码合并评审岗位、个别产品线故障响应岗位、人事岗位（全流程单岗承担）。建议在两周优化期内为以上岗位指定 B 角。
  • 交接 / 代理中：行政、出纳与采购执行、模型网关维护、CI 负责人、渠道系统开发等岗位近期有交接，SOP 中的“当前”人员以交接后为准。

方法、口径与局限

  • 数据来源：创始人账号可见的 2026-01-01 至 2026-10-19 飞书聊天导出（610 个会话，约 51 万条消息），以及聊天中引用的流程类飞书文档（只读抽样）。机器人通知、系统消息、表情与纯图片已过滤；闲聊群仅按流程关键词粗筛。
  • 方法：AI 辅助逐段通读全部聊天，抽取流程线索约 3700 条 → 按部门聚类为 SOP 条目 → 跨部门移交裁决 → 逐条撰写完整 SOP → 独立审阅与修订（含重复条目合并 13 组）→ 汇总业务流、攻坚清单与系统建设清单。
  • 状态口径：已有＝有成文文档/模板/审批/机器人且执行稳定；待优化＝有固定做法但反复催办、返工、口径不一；待新建＝每次临时处理或出过事故。
  • 证据口径：“有证据”表示来自聊天观察；“推断”“推断补充”表示按行业常规补全，必须由部门负责人确认。负责人一律为“岗位（当前：某某·推断待确认）”。
  • 匿名与脱敏：低效诊断不点名个人，客户名、金额、薪资、个人人事事件均已隐去；单聊内容不作为对外依据。可追溯的原话证据只保存在创始人本人的工作底稿中。
  • 局限：只覆盖创始人所在的会话，品牌、政策申报、运营等部门的证据偏少；附件正文未下载；分数与时限为建议值。以上都需要各部门在两周优化期内校准。