oms-techsupport-input
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
- OMS:
- 如果用户只给了一套 cookie,不要想当然拿去打另一边接口;优先按域名拆开传。
0.1) Cookie 自举(首次)
当本地没有 cookie 缓存时:
- 打开隔离浏览器访问
https://oms.netease.im/tag/technicalSupport/record - 让用户手动完成登录
- 从任一 OMS 接口请求头抓取
Cookie(document.cookie可能为空,优先抓 Request Headers) - 写入缓存:
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) 执行前置与失败兜底(新增约束)
每次接到提单请求时,先做两件事:
- 优先确认隔离浏览器是否已可访问 OMS 录入页(有登录态)。
- 再执行
scripts/oms_ts_api.py流程。
若脚本报错属于以下任一情况,不要先让用户提供 cookie,应先自助修复:
- Python 依赖缺失(如
ModuleNotFoundError: requests) - 本地
.oms_cookie缺失但隔离浏览器已登录可用
推荐兜底顺序:
- 在 skill 目录创建并使用虚拟环境安装依赖(
python3 -m venv .venv && . .venv/bin/activate && pip install requests) - 在隔离浏览器触发任一 OMS 接口请求,从 Request Headers 提取 Cookie
- 写入
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
这条命令内部会按顺序做三件事:
- 先调用
submit-record创建工单 - 自动从返回里解析新工单号(
OMUTWHMT-xxxxx) - 再到 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-file和submit-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=attachmentcategory=SYSTEMvalue=[...已有附件对象, <新上传的附件对象>]
如果你明确知道当前工单附件为空,或者就是想覆盖,才显式传:
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=attachment或name=附件的字段再解析。 - 若直连
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) 返回文案
- 成功:返回
res、requestId、工单链接 - 失败:原样返回
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