skills/skills.netease.im/oms-techsupport-input

oms-techsupport-input

SKILL.md

OMS 技术支持提单(纯接口)

只走 HTTP API,不走浏览器点选。

0) 脚本入口

使用:scripts/oms_ts_api.py

  • OMS 提单接口认证优先级:--cookie > OMS_COOKIE > 本地缓存文件 skills/oms-techsupport-skill/.oms_cookie
  • Overmind 附件接口认证优先级:--overmind-cookie > OMS_COOKIE/--cookie 兜底 > --overmind-cookie-file(若未传则回退到 OMS cookie 文件)
  • 可用 --save-cookie 把本次 --cookie 写入 OMS 缓存,后续自动复用
  • 所有写操作前,先给用户看参数,再等确认提交

Cookie 不要混

  • OMS cookie:用于 fuzzy-group / major-search / add-group / query-assignee / build-payload / submit-record / submit-record-with-attachments
  • Overmind cookie:用于 upload-file / get-issue / attach-file / submit-record-with-attachments
  • 两边域名不同:
    • OMS:https://oms.netease.im
    • Overmind:https://overmind.hz.netease.com
  • 如果用户只给了一套 cookie,不要想当然拿去打另一边接口;优先按域名拆开传。

0.1) Cookie 自举(首次)

当本地没有 cookie 缓存时:

  1. 打开隔离浏览器访问 https://oms.netease.im/tag/technicalSupport/record
  2. 让用户手动完成登录
  3. 从任一 OMS 接口请求头抓取 Cookiedocument.cookie 可能为空,优先抓 Request Headers)
  4. 写入缓存:
python skills/oms-techsupport-skill/scripts/oms_ts_api.py \
  --cookie '<完整cookie>' \
  --save-cookie \
  fuzzy-group 'test'

说明:执行成功后会在 skills/oms-techsupport-skill/.oms_cookie 落盘,后续可不再手传 cookie。

0.2) 执行前置与失败兜底(新增约束)

每次接到提单请求时,先做两件事:

  1. 优先确认隔离浏览器是否已可访问 OMS 录入页(有登录态)。
  2. 再执行 scripts/oms_ts_api.py 流程。

若脚本报错属于以下任一情况,不要先让用户提供 cookie,应先自助修复:

  • Python 依赖缺失(如 ModuleNotFoundError: requests
  • 本地 .oms_cookie 缺失但隔离浏览器已登录可用

推荐兜底顺序:

  1. 在 skill 目录创建并使用虚拟环境安装依赖(python3 -m venv .venv && . .venv/bin/activate && pip install requests
  2. 在隔离浏览器触发任一 OMS 接口请求,从 Request Headers 提取 Cookie
  3. 写入 skills/oms-techsupport-skill/.oms_cookie 后继续接口提单

只有当隔离浏览器也无法登录/无法拿到请求头 Cookie 时,才向用户索要 Cookie。

1) 查群(一级)

python scripts/oms_ts_api.py fuzzy-group "<群名>"

接口:POST /frontApi/tag/technicalSupport/group/fuzzyQueryByName

  • 若命中:展示 groupId/cid/companyName/groupName 供确认
  • 若未命中:走第 2 步

2) 客户兜底(二级)

python scripts/oms_ts_api.py major-search "<关键词>"

接口:GET /home/majorSearch?tag=2&searchType=cust&keyword=...

  • 关键词优先用用户原文
  • 不命中时可拆 1~3 个短词再查
  • 给用户候选并让其选 CID

3) 补建群映射

python scripts/oms_ts_api.py add-group --cid <cid> --group-name "<完整群名>"

接口:POST /frontApi/tag/technicalSupport/group/add

  • 仅在用户确认后执行
  • 成功后再次 fuzzy-group 获取 groupId

4) 经办人/报告人查询

python scripts/oms_ts_api.py query-assignee "高琦"

接口:POST /frontApi/tag/technicalSupport/record/queryAssignee

  • 经办人写入 detail.9
  • 报告人写入 detail.11
  • ⚠️ detail.9 / detail.11 必须写邮箱(name 字段,如 hzfangtiankui@corp.netease.com),不要写 loginName(如 hzfangtiankui
  • 不要擅自根据当前主会话用户、cookie 提供者、聊天对象去猜报告人。 这些身份可能不是同一个人。
  • 提单前必须明确向用户确认一次报告人,话术可直接用:报告人我现在准备填成 XXX,要不要就填他?如果你指定其他人,我按你指定的来。
  • 若用户明确指定其他人,优先按用户指定的人查询并填写。
  • 若用户未明确指定,且当前只拿到了一个候选报告人,也仍然要先把候选人回显给用户确认后再填。
  • 只有在用户明确回复“就填 XXX / 默认即可 / 按提单人填”等确认性表述后,才允许把该人写入 detail.11
  • 如果用户迟迟未确认报告人,提单参数预览里要把“报告人待确认”单独列出来,不要直接提交。

5) 提单参数预览(先给用户看)

python scripts/oms_ts_api.py build-payload \
  --group-id <groupId> \
  --group-name "<群名>" \
  --summary "<问题现象,不带推断>" \
  --priority P1 \
  --desc-html "<三段HTML描述>" \
  --assignee "<经办人账号>" \
  --recorder "<记录人邮箱>" \
  --reporter "<报告人账号,可空>" \
  --push-jira > /tmp/oms_payload.json

标题自动按固定规范生成: 【PX-群名】问题现象总结

  • 默认 P1(一般客户不是“闹得很厉害”都按 P1;仅在客户明确很急/强升级时再提 P0
  • 标题只写现象,不写原因推断

接口依赖:POST /frontApi/tag/technicalSupport/tag/query(取字段枚举)

默认行为:

  • pushJira=true
  • 禁止在未确认的情况下直接依赖 reporter 为空时自动使用 recorder 只有用户明确同意“报告人就按记录人/提单人填”时,才可以这样处理。

6) 用户确认后提交

python scripts/oms_ts_api.py submit-record --payload-file /tmp/oms_payload.json

提交前检查:

  • 群 / groupId 已确认
  • 经办人已确认
  • 报告人已明确确认,并且已向用户回显“当前准备填谁”
  • 用户已确认本次提单内容可以提交

接口:POST /frontApi/tag/technicalSupport/record/add

实测注意record/add 使用 application/json;charset=UTF-8

6.1) 提单后自动挂附件(推荐)

如果这次提单就需要把日志包、截图一起带上,优先直接走一条命令串起来:

python scripts/oms_ts_api.py \
  --cookie '<oms-cookie>' \
  --overmind-cookie '<overmind-cookie>' \
  submit-record-with-attachments \
  --payload-file /tmp/oms_payload.json \
  --file /path/to/log1.zip \
  --file /path/to/screenshot.png \
  --updator gaochao02@corp.netease.com \
  --product-id 295

这条命令内部会按顺序做三件事:

  1. 先调用 submit-record 创建工单
  2. 自动从返回里解析新工单号(OMUTWHMT-xxxxx
  3. 再到 Overmind 读取当前附件列表,并把 --file 传入的文件逐个追加挂上去

适用场景:

  • 新提工单时就已经拿到了日志包 / 截图
  • 你要的是“提完单,附件也一起到位”,而不是后面再手动补挂

注意:

  • 这条命令同时依赖 OMS cookie + Overmind cookie
  • --file 可以重复传多次,按传入顺序逐个追加
  • --updator 仍然必须传邮箱
  • 实测发现 Overmind 直连上传在部分环境下会返回 301 / MOVED_PERMANENTLY,当前脚本已内置 浏览器登录态兜底:直连失败时,会自动借助本机 Chrome 已登录的 Overmind 页面完成上传,再继续挂单

6.2) 上传附件到 OMUTWHMT / Overmind

当需要把日志包、截图等真正挂到工单附件区时,不要只写文本描述;走 Overmind 附件接口:

先上传文件:

python scripts/oms_ts_api.py --overmind-cookie '<overmind-cookie>' upload-file --file /path/to/file

接口:POST /api/global/suggestion/file/uploadV2

返回里核心字段:

  • result:NOS 文件地址
  • file.name / file.size / file.type:本地文件元数据
  • raw:上传接口原始 JSON,排查返回异常时先看它

补充说明:

  • 如果 upload-file / attach-file 直连 Overmind 返回 301 / MOVED_PERMANENTLY,不要再误判成“接口不可用”。这通常是 脚本直连鉴权态不对,但浏览器登录态仍然可用
  • 当前 skill 已对 attach-filesubmit-record-with-attachments 做浏览器态兜底;其中 submit-record-with-attachments 已实测通过 多附件自动挂载

再把附件挂到工单。

默认按追加思路处理,不允许盲覆盖。

先取当前工单详情(或只取 attachment 列表):

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  get-issue \
  --issue-key OMUTWHMT-64707 \
  --product-id 295 > /tmp/issue_64707.json

只看附件:

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  get-issue \
  --issue-key OMUTWHMT-64707 \
  --product-id 295 \
  --attachments-only

然后把整包工单 JSON 直接喂给脚本做合并:

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  attach-file \
  --issue-key OMUTWHMT-64707 \
  --file /path/to/file \
  --updator gaochao02@corp.netease.com \
  --existing-issue-file /tmp/issue_64707.json

如果你已经手头就是当前工单的 attachment JSON 数组,也可以直接传:

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  attach-file \
  --issue-key OMUTWHMT-64707 \
  --file /path/to/file \
  --updator gaochao02@corp.netease.com \
  --existing-attachments-file /tmp/current_attachments.json

或直接传 JSON 字符串:

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  attach-file \
  --issue-key OMUTWHMT-64707 \
  --file /path/to/file \
  --updator gaochao02@corp.netease.com \
  --existing-attachments-json '[{...已有附件对象...}]'

接口:POST /api/efficiency/editIssueBySignleField

当前脚本默认用:

  • fieldKey=attachment
  • category=SYSTEM
  • value=[...已有附件对象, <新上传的附件对象>]

如果你明确知道当前工单附件为空,或者就是想覆盖,才显式传:

python scripts/oms_ts_api.py \
  --overmind-cookie '<overmind-cookie>' \
  attach-file \
  --issue-key OMUTWHMT-64707 \
  --file /path/to/file \
  --updator gaochao02@corp.netease.com \
  --replace

注意:

  • attach-file 现在默认拒绝盲覆盖;没给已有 attachment 列表、也没传 --replace,脚本会直接报错拦住。
  • 当前版本已经支持通过 get-issue 读取工单详情,再自动从返回结果里抽取 attachment 列表做追加。
  • 若返回里 attachment 不在顶层,而是在 customField 中,脚本会优先识别 fieldKey=attachmentname=附件 的字段再解析。
  • 若直连 get-issue / uploadV2 拿到的数据不完整,脚本会优先尝试用浏览器已登录态补拉工单详情或补传附件。
  • updator 要传邮箱,不要传工号前缀。
  • 提单和附件最好分两套 cookie 传,别再把 OMS / Overmind 域名混着打。

7) 描述格式(强制)

detail.12 必须三段:

  • <p>【客户原话】...</p>
  • <p>【关键信息】...</p>
  • <p>【排查进展】已做动作与待研发核查点...</p>

其中【关键信息】要求:

  • 优先把 SDK 版本、发生时间、平台/机型、uid/accid/cid、现象、日志线索等拆成多行,提升可读性
  • 使用多个 <p> 分行(或在一个 <p> 内用 <br/> 分行),避免把所有信息挤在一整段
  • 仅写已确认事实,不写推断

示例:

<p>【关键信息】SDK版本:v1.2.2</p>
<p>发生时间:2026-03-20 16:30~16:40</p>
<p>平台:ESP32;账号信息:uid=xxx / accid=xxx</p>
<p>现象:低功耗后重连耗时长于预期(目标1~3秒)</p>

不要虚构;缺失信息先问用户,用户无法提供时省略该字段。

8) 返回文案

  • 成功:返回 resrequestId、工单链接
  • 失败:原样返回 res/errmsg/requestId
  • 若误提测试单,主动告知并给处理建议(标注/关闭)

9) 业务领域(原文ID映射,按你提供保留)

  • 861 = AOS
  • 862 = iOS
  • 863 = Flutter
  • 864 = Mac
  • 865 = Electron
  • 1116 = 鸿蒙
  • 866 = Linux
  • 867 = RN
  • 868 = PC
  • 869 = Server
  • 870 = Uniapp
  • 871 = Unity
  • 872 = Web
  • 875 = 小程序
  • 1045 = 通用
  • 877 = 数据平台
  • 1046 = 音频引擎
  • 1047 = 音频算法
  • 1048 = 视频引擎
  • 1049 = 视频算法
  • 1050 = 网络引擎

10) 优先级规则与枚举映射(原文,按你提供保留)

  • 规则:一般客户不是闹得很厉害,都用 P1
  • 提单传参必须传枚举值(不要只传文本)
  • P0 = 1
  • P1 = 3
  • P2 = 4
  • P3 = 10100

11) 默认字段(原文,按你提供保留)

  • detail.305 默认:复杂工单 = 8c2bb455-e03c-358a-ae7c-7478fed939f0
  • detail.293 默认:无 = 9969db8c-e544-3e2a-b524-1178d7ce27e5
  • productId 默认:295

12) 业务类型-云信(原文ID映射,按你提供保留)

  • IM-V1 = 092826b7-6b7b-37fc-be85-d55c23bc62fa
  • IM-V2 = 6b04a212-270b-3448-ac58-356836595e64
  • IM-UIKit = ccce41e3-b28a-359f-bdc4-11738246058a
  • 音视频2.0 = 4471747d-5e0c-3bd6-8525-2a0b9d9b26e7
  • 音视频1.0 = 3ddd97b3-342d-388a-8013-db0d0b2494c4
  • 互动直播1.0 = 9ff2607c-7224-3957-bb1e-300c9d3f354a
  • 互动直播2.0 = 824ca7b0-bb04-3ecb-9f3f-23a47f56e87e
  • 指南针 = 9d83fbdd-3d21-337a-9881-4534071c1516
  • 直播 = 5514905f-a089-3544-9ee6-12a88c4107b9
  • 点播 = fca98879-d904-3e46-bf41-35a8050fd33d
  • 互动白板 = 0bfba7ac-de54-3d73-aefc-cb478142d8b3
  • 短信 = 8e1415fc-3d4b-34b2-9f91-1be9e3b933e8
  • 数据平台 = 45b43feb-8ef4-3d28-964a-af3fa5ce3ce8
  • 业务系统 = d05e3451-bd5b-3e6d-a909-ddb31a4e073b
  • 短视频 = a6eab9f8-802a-3fd2-9af6-dcfed93a473d
  • 官网 = 5665484c-215a-33e0-b87b-375e6dea3c8d
  • 应用-娱乐社交解决方案 = 8c001627-b23f-36e5-9627-0b6873120cbc
  • 应用-会议组件(含网易会议) = 5a36fd10-26d2-38ec-88db-e09262bc56ae
  • 应用-呼叫组件 = 9e189b11-ef47-37f1-b95a-b656510acb87
  • QS平台 = d0861c73-082b-34b8-9049-9c783bb8eb22
  • 效能建设 = bd9705b5-dd34-37c7-bbd2-01df0e0ec77a
  • 稳定性建设 = 462e2049-6268-3d72-b659-f533a6e6a6e0
  • 成本管理 = 30ef33f5-a1b7-37aa-a8c2-9e15e9b94cdd
  • 金财系统 = 495ff5ed-8ccd-37bf-a807-ff8172f28745
  • 私有化-基建 = d5cd51a9-560f-386f-8ec1-856472671849
  • IM-私有化 = 29d9f43b-4dbf-39c9-a8b9-e523d50a94db
  • RTC-私有化 = 0a13ba1e-fbef-32f5-b391-8da1be2e6748
  • 会议-私有化 = 73ae6ff6-a014-3ac6-8c38-5889f2b35bad
  • IM-融合AI = e352a966-4ca2-3cc4-9e1b-0f5914a1388b
  • 一键登录 = 4f0b739d-034a-39a4-9b57-532ab9dc2db2
  • 5G消息 = c9d85aeb-9664-3c62-9360-aa3cf60b2a45
  • 应用-IM-UIkit(20240920前含呼叫组件) = 034a1335-ff2f-34de-9db8-1dceb593b456
  • 专线电话 = e3128894-2a28-38a7-8255-a9be1452fcbf
  • 号码隐私保护 = e6d3a04e-1f34-3874-92ae-769a6850b751
  • 应用-其他 = c7f8bdd7-cf75-3d70-8c17-f059ab6296f6
  • AI = e7ddab32-dcaf-31fe-92eb-c03e19ac735c
  • AI产品-听房师 = 6ec4b40f-6de4-3f07-ae0e-c24c7f808bdf
  • AI产品-金融 = 888fa23a-9b5f-346d-a0c6-df6e3780f18d
  • AI产品-招采 = b7c5f499-024a-3aab-89d3-125a601ffd67
  • AI产品-智能硬件-智能体平台 = dae211ff-cc86-3da0-8250-fe8b47277232
  • AI产品-智能硬件-硬件SDK = b588676c-542b-31ae-aef2-00f24e0bcc1a
Installs
2
First Seen
Apr 3, 2026