Files
prop-ai-hr/docs/帮道8月1日业务内容与五通道签认单-20260729.md
T

12 KiB
Raw Blame History

帮道 8 月 1 日业务内容与五通道签认单

适用版本:2026-08-01 Android 受控内测

技术准备状态:READY_FOR_BUSINESS_SIGNOFF

业务签认状态:PENDING

数据边界:本文件不记录手机号、验证码、账号、访问令牌、住户个案或其他个人敏感信息。

1. 当前结论

技术侧已经把生活顾问调研转成可逐项审核的 5 个场景候选和 30 道问题候选,并完成五通道接口、固定码登录和认证后只读主路径验证。2026-07-30 又发布 superadmin 五通道处理人配置入口和租户/用户资格保护;生产五个角色按有效后台用户口径均为 2/2。业务方仍未提供正式制度来源、内容审核结论、五通道业务验收和负责人签字,因此当前不能启用候选内容,也不能把“已配置处理人”解释成“通道已正式验收”。

截至 2026-07-29 的签认基线:

项目 当前事实 本单完成条件
已收生活顾问访谈 1/24 其余访谈可在内测后继续补,但本轮 5 个正式场景必须有独立正式依据
场景候选 5 5/5 完成来源、红线、Rubric 和审核签认后才能发布
正式可发布场景 0/5 不得用 seed、访谈经验或 AI 生成答案替代
问题候选 30 30/30 绑定正式文件和预期引用/拒答行为
正式有据标准答案 0/30 来源、版本、适用范围与审核人齐全
直通车通道 5/5 可见 每个通道至少绑定 1 名主处理人和 1 名替补
生产有效处理人绑定 5 个角色均为 0 绑定后完成本通道正例、跨通道反例和一次正式回复
五通道验收证据 0/5 每通道的绑定、正例、跨通道拒绝和一次回复证据均有不可变引用与哈希
受控分发决定 PENDING 明确法务决定、签名决定、分发范围、证据哈希和负责人

候选事实源:

2. 五个场景签认

任何一行未完成时,该场景继续保持 enabled=false、publishable=false,不得进入员工端。

候选 ID 场景 正式文件编号/版本/生效日 适用项目或业态 红线与升级路径已确认 Rubric 审核 审核结论 审核人/日期
LC-AUG1-SC-001 拒绝提供定位信息时的报修受理 待业务填写 待业务填写 待签认 待签认 PENDING 待签认
LC-AUG1-SC-002 物业费明细与服务争议沟通 待业务填写 待业务填写 待签认 待双人签认 PENDING 待签认
LC-AUG1-SC-003 维修延期后的解释与升级跟进 待业务填写 待业务填写 待签认 待签认 PENDING 待签认
LC-AUG1-SC-004 情绪化停车冲突投诉的降级处理 待业务填写 待业务填写 待签认 待双人签认 PENDING 待签认
LC-AUG1-SC-005 收费沟通与服务整改并行闭环 待业务填写 待业务填写 待签认 待双人签认 PENDING 待签认

审核规则:

  1. 正式依据必须是公司制度、已发布 SOP、有效公示或经授权的项目规则;访谈只用于发现主题。
  2. 高风险场景必须由两名不同审核人复核同一内容版本。
  3. 收费、优惠、分期、报警、隐私和承诺时限不得由模型自行补充。
  4. 场景来源、回合、五维评分说明和风险等级任何一项含占位内容时,发布门禁必须拒绝。
  5. 审核结论只允许 APPROVED 或 REJECTED;未填写一律按 PENDING。

3. 三十道问题签认

30 道问题的 ID、问题文本和预期边界行为以候选 JSON 为准,本单不复制答案。每一类均需完成 6/6,合计 30/30 后才能作为正式回归集。

类别 数量 必交证据 当前结论 审核人/日期
NORMAL 6 当前有效文件、精确引用、适用范围 PENDING 待签认
SYNONYM 6 与对应正常题相同的来源和一致结论 PENDING 待签认
CONFLICT 6 冲突文件、版本优先级和停止自行裁决规则 PENDING 待签认
NO_EVIDENCE 6 无依据时的明确拒答文案,不生成政策事实 PENDING 待签认
UNAUTHORIZED 6 权限矩阵和越权命中为零的反例 PENDING 待签认

正式题单必须另附:问题 ID、标准答案、来源附件 ID、引用片段 ID、文件版本、生效日期、适用项目、审核结论和实际回归结果。不得把模型临时回答写回为标准答案。

4. 五通道处理人和权限签认

生产只读审计确认五个角色均已存在,且当前每个角色都有 2 名符合服务端资格规则的有效后台处理人。仍须由通道负责人核对这些绑定并完成正例、跨通道越权反例和一次正式回复签认;技术人数检查不能代替业务批准。

通道 角色代码 主处理人 替补处理人 本通道列表/详情正例 其他四通道越权反例 一次正式回复 业务签认
总裁 direct_president 待指定 待指定 待验收 待验收 待验收 PENDING
财务 direct_finance 待指定 待指定 待验收 待验收 待验收 PENDING
人力 direct_hr 待指定 待指定 待验收 待验收 待验收 PENDING
审计 direct_audit 待指定 待指定 待验收 待验收 待验收 PENDING
运营 direct_operations 待指定 待指定 待验收 待验收 待验收 PENDING

每个通道的验收动作固定为:

  1. 业务负责人签认主处理人和替补;相关后端与管理端发布后,由 superadmin 在 /content/direct 的“处理人配置”中从当前租户合格候选人绑定对应角色,每个通道至少 2 人。技术侧不得替业务方选择人员。
  2. 处理人只能看到本通道;其他通道列表、详情和回复必须拒绝。
  3. superadmin 仅作系统管理全局能力,不代替五个真实业务处理人。
  4. 员工匿名提交时,处理端不显示提交人;系统仍保留内部审计身份。
  5. 同一反馈只允许一次正式回复,不扩展为多轮聊天、转派或 SLA。
  6. 验收记录只写角色、时间、结果和证据编号,不写员工手机号或反馈正文。

5. 已完成的非真机技术证据

scripts/verify-aug1-authenticated-production.sh --execute 已使用生产现有 app_user 和双向唯一在职组织身份完成首次登录和重新登录,测试值只存在执行进程内:

  • 首次获取验证码命中固定码分支,退出后等待 60 秒防刷窗口,再次获取固定码;应用日志确认两次均“未真实发送短信”;
  • 登录返回有效移动端会话,/api/aihr/mobile/me 返回有效角色和非空项目范围;
  • 认证首页、训练历史、画像、五通道列表、我的反馈、大喇叭、考试、案例能力和全网能力只读入口通过;
  • 五通道列表恰好返回 5 个通道;
  • 首次退出成功,旧令牌再次访问时按业务码 401 拒绝;第二次固定码登录、身份读取和退出再次通过;
  • 脚本只选择已存在 app_user,不会触发手机号自动注册,不提交反馈、训练、附件、ASR/TTS 或 Agent 业务请求。

这组证据完成登录与认证只读链路;后续 vivo 真机又在签名 0.1.17 完成学习中心、麦克风允许/拒绝/恢复、系统选择器取消、真实音频选择/生产 ASR、成果投稿确认保存和五通道入口。生产只读查询按服务端资格规则确认五个直通角色各有 2 名有效后台处理人。上述结果仍不替代真实断网、WebRTC、实际图片/视频/文档、受控下载,也不替代本单的正式内容、通道业务验收和负责人签认。

6. 最终签认

只有以下全部完成,业务部分才可标记为 APPROVED:

  • 5/5 场景完成正式来源、红线、Rubric 和审核签认;
  • 30/30 问题形成有据标准答案与权限/拒答回归证据;
  • 五个处理角色分别绑定主处理人和替补;
  • 五通道正例、跨通道反例和一次正式回复全部通过;
  • 内容运营确认候选版本、导入版本和员工可见版本一致;
  • 法务/合规与发布负责人明确接受受控内测范围、当前 APK 签名和分发名单;
  • 发布负责人确认本单对应的后端、内容和权限变更已纳入回退点。
签认角色 结论 签认人 日期 备注
业务总负责人 PENDING 待签认 待签认
知识内容负责人 PENDING 待签认 待签认
训练内容负责人 PENDING 待签认 待签认
五通道业务负责人 PENDING 待签认 待签认
法务/合规确认人 PENDING 待签认 待签认 受控内测可填写正式批准或明确例外接受
受控分发负责人 PENDING 待签认 待签认 确认签名摘要、分发范围与名单证据
发布负责人 PENDING 待签认 待签认

7. 机器门禁与回填方式

本单用于业务阅读;机器事实源是 aug1-release-approval.json。它只保存正式来源的编号、版本、适用范围与哈希,逐项审核和回归证据引用,以及生产场景版本/哈希,不复制制度正文、标准答案、手机号或处理人身份。

回填顺序固定为:

  1. 业务方提供正式文件,登记 sourceRegistry;不得把访谈或 AI 输出登记为 formalPolicy=true。
  2. 5 个场景在管理端完成内容录入和审核,高风险场景由不同人员二审;把最终生产 scenarioCode、contentVersion、contentHash 和证据引用回填到对应 scenarioApprovals。
  3. 30 道问题逐项形成正式引用/拒答/越权回归证据,把证据文件引用和 SHA-256 回填到 policyQuestionApprovals;不把答案正文写入仓库。
  4. 五个通道分别完成绑定、正例访问、其他通道拒绝和一次正式回复验收,把四类证据引用与 SHA-256 回填到 channelApprovals;清单不记录处理人身份或反馈正文。
  5. 受控分发负责人在 distributionApproval 中明确法务决定、DCloud 测试签名或企业签名决定、实际签名摘要和分发证据;只有受控内部测试范围允许填写明确的例外接受。
  6. 五类业务负责人签认后,将顶层 releaseStatus 改为 APPROVED。任何缺项、占位值、未知来源、证据哈希缺失、高风险同人二审、通道验收不足或签名摘要不一致都会失败关闭。
  7. 相关后端与管理端发布后,superadmin 按本单在 /content/direct 的“处理人配置”中绑定五通道主处理人和替补;候选列表由服务端排除 APP 用户、超级管理员、停用/删除、跨租户和已绑定账号,写请求复核当前租户。机器门禁只输出每个角色的有效人数,不输出人员身份。

先审计当前回填进度:

node scripts/verify-aug1-formal-content.mjs

正式签认完成后,严格校验本地证据:

node scripts/verify-aug1-formal-content.mjs --strict

最后执行生产只读门禁:

./scripts/verify-aug1-release-readiness.sh --execute

最终脚本不会请求或消费验证码,不会触发真实短信,不登录,不写数据库。它要求生产固定码模式已明确启用、五个角色各至少两名有效处理人、五通道验收证据和受控分发决定完整,并核对 5 个已发布场景的版本、内容哈希、审核链和 SOP 引用与签认清单完全一致。