PageSourceSearch

https://cympha.com/assets/alignerbot-phase1-to-phase2.zh-xzDpvS_y.js

js cympha.com collected 2026-10-09 22:58:10 UTC 11,838 bytes, 124 lines download raw bytes

1const n=`# AlignerBot——跨 Cympha、OrthoPlus 和 Agent 的 Phase-1 到 Phase-2
2
3**适用人群:** 提交 AlignerBot 病例的临床医生、对其分诊的技工所经理,以及在技工所中使用 Cympha Agent Manager 调度 OrthoPlus 的 AlignerBot 操作员. 请端到端阅读,这样每个角色都知道其他两方在做什么.
4
5**阅读后您将知道:** 一个 AlignerBot 病例如何穿越规划(Phase-1)和矫治器设计(Phase-2)阶段、调度交接在哪里发生,以及当临床医生在循环中途请求更改时需要什么.
6
7**所需时间:** 阅读约 25 分钟. 一个真实病例的 Phase-1 通常在不到一小时的 Agent + OrthoPlus 时间内完成,加上临床医生审阅的时间.
8
9---
10
11## 开始之前
12
13您需要:
14
15- 一位拥有 Cympha 账户且可访问 \`app.cympha.com/cases/new\` 的临床医生.
16- 一家 Cympha 上的技工所,其 \`/team\` 中至少有一位用户持有 **AlignerBot** 角色. 如果没有 AlignerBot 角色用户,病例可被分配给普通设计师,但 Agent 不会自动调度 OrthoPlus——它会作为普通设计师任务搁置.
17- 一台 Windows 工作站,已安装并激活 **GuideMia OrthoPlus**,且 **Cympha Agent Manager** 已安装并配对到 AlignerBot 角色用户的 Cympha 邮箱.
18- 一组已确认的扫描数据(至少上颌+下颌 STL/PLY). Agent 没有扫描数据无法调度 OrthoPlus.
19
20技工所侧的设置,请先按 [为您的技工所设置 AlignerBot](/docs/set-up-alignerbot-for-your-lab) 操作. Agent 侧的设置,请按 [安装并配对 Cympha Agent Manager](/docs/install-pair-agent-manager) 操作. 如果临床医生对 AlignerBot 全新,[提交一个 AlignerBot 病例](/docs/submit-alignerbot-case) 是专注的受理文档.
21
22## 第 1 步——临床医生在 /cases/new 提交 AlignerBot 病例
23
24临床医生打开 \`app.cympha.com/cases/new\`. 他们搜索一家提供 AlignerBot 的技工所并选择类别 **AlignerBot**. 表单显示 AlignBot 参数部分:每颌方案范围、自动拔牙开关、拔牙牙位号、缺失牙、允许的 IPR、前牵/后退、扩弓、伸长/压低、中线对齐、Spee 曲线、矢状/冠状倾角.
25
26他们至少上传上下颌 STL/PLY. 可选:咬合、照片、CBCT.
27
28他们提交. 病例从草稿提升到 **Submitted**,由技工所经理持有,经理会收到一封来自 Cympha 的邮件. 完整的受理侧详情见 [提交一个 AlignerBot 病例](/docs/submit-alignerbot-case).
29
30## 第 2 步——技工所经理将病例路由到 AlignerBot 席位
31
32技工所经理打开这个新病例——它显示状态为 **Submitted**,类别为 **AlignerBot**. 他们确认扫描和参数看起来合理,然后将病例移动到 **Designing**. 状态控件在确认之前会预览病例将由谁接收;团队中有 AlignerBot 席位用户时,病例会路由到该用户. 完整的分配演练见 [将病例分配给设计师](/docs/assign-case-to-designer).
33
34席位为什么重要:配对到该用户的工作站上的 Cympha Agent Manager 内含一个 AlignerBot Agent. 它只在病例持有者是 AlignerBot 席位用户时激活. 由普通设计师持有时,病例会停留在 **Designing**,但不会自动调度——设计师必须手动驱动 OrthoPlus.
35
36## 第 3 步——Agent 认领病例并调度 OrthoPlus
37
38在下一次轮询时(Agent 每 20 秒检查一次新病例),AlignerBot 操作员工作站上的 Cympha Agent Manager 看到一个由其配对用户持有的新分派病例,于是认领一个调度锁. (这个锁可防止配对到同一用户的第二台工作站发生竞争——任何一次设计任务只会被一个 Agent 拾取. )
39
40然后 Agent:
41
421. 将病例文件(扫描+任何其他输入)下载到工作区文件夹中该病例自己的文件夹里.
432. 以规划模式(Phase-1)在该病例上启动 OrthoPlus.
44
45调度支持并行——Agent 可以同时运行多个 OrthoPlus 工作进程,在其 **Configure AlignerBot** 对话框中配置.
46
47## 第 4 步——OrthoPlus 运行 Phase-1(规划)
48
49OrthoPlus 加载扫描,应用 AlignBot 参数,运行规划级联. 这会生成一个治疗方案:N 个步骤上的分阶段牙齿位置、IPR 图、附件放置、中线对齐.
50
51OrthoPlus 将成果保存到病例文件夹中,其中包括 \`.gvw\`(Studio 可查看的治疗方案). Agent 自动上传 \`.gvw\`,而且——因为经由 Agent 到达的审阅文件会自行发起审批——病例变为 **Awaiting Approval**,带 **Plan Approval Pending** 标签,全程无需技工所点击. (OrthoPlus 使用的 \`.gos\` 项目文件留在工作站本地;它不会被上传. )临床医生收到一封来自 Cympha 的邮件.
52
53## 第 5 步——临床医生在 /cases/<id>/approve 审阅
54
55临床医生点击邮件链接,进入 \`/cases/<id>/approve\`. 标题显示患者姓名、**Awaiting Approval** 徽章和步骤标签 *"Approval needed — Treatment Plan"*.
56
57文件面板列出 \`.gvw\` 以及原始扫描. 临床医生点击 \`.gvw\` 链接在新标签页中打开 Studio,并旋转查看方案——分阶段牙齿位置、附件放置、治疗结束时的模拟咬合.
58
59底部有三个操作:
60
61- **Approve design**——接受方案.
62- **Request changes**——退回给 AlignerBot Agent.
63- **Escalate to lab manager**——转给技工所经理.
64
65完整的批准页演练见 [批准或拒绝设计](/docs/approve-or-reject-a-design).
66
67## 第 6a 步——临床医生批准方案 → Phase-2 自动调度
68
69如果临床医生批准方案,状态会经由 **Approved** 中转,并且——因为还剩一个审批周期——直接回落到 **Designing**,仍由同一个 AlignerBot 席位持有. Agent 下次轮询时认领一个新的调度锁.
70
71这次 Agent 以矫治器模式(Phase-2)启动 OrthoPlus,OrthoPlus 运行矫治器设计级联——生成病例的 **Design kind** 所要求的内容:**Aligner models**、**Arch model**、**Bracket bonding guide** 或 **Treatment plan only**.
72
73OrthoPlus 以一个设计结果 zip 和一个 \`.gos.gpk\` 传输包收尾. Agent 自动上传它们,而经由 Agent 到达的 \`.gos.gpk\` 会自行触发第二次审批:状态再次变为 **Awaiting Approval**,带系统标签 **Appliance Approval Pending**.
74
75临床医生再次收到来自 Cympha 的邮件,并返回 \`/cases/<id>/approve\`. 他们审阅矫治器文件并批准. 状态经由 **Approved** 中转,并且——这是数字类别的最后一个周期——直接推进到 **Delivered**,没有生产制造环节(完整生命周期见 [病例状态术语表](/docs/case-status-glossary)).
76
77往返结束. 病例已交付.
78
79## 第 6b 步——临床医生请求更改 → 需要结构化物件
80
81如果临床医生改为点击 **Request changes**,对话框要求他们确认. **对于 AlignerBot,对话框强制执行结构化的修订物件**:确认按钮在扩展名为 \`.xml\` 或 \`.gpk\` 的文件被附加到病例之前保持禁用.
82
83对话框本身显示一个琥珀色横幅,内容为 *"Upload one of the following first:"*,并列出两条路径:
84
85- **从 Cympha Studio 的 3D 审阅导出的 XML 牙位文件. ** 临床医生在 Studio 中打开病例的 \`.gvw\`,在 3D 审阅界面进行牙位编辑,导出 \`.xml\`,并在重新确认拒绝之前将其上传回病例.
86- **从 GuideMia OrthoPlus Planner 保存的 \`.gos.gpk\` 传输包. ** 如果临床医生本人有 OrthoPlus,他们可以编辑方案并保存为 \`.gos.gpk\`,然后上传.
87
88对话框中的 **Get the planner →** 链接指向 \`/downloads\`,方便临床医生在没有的情况下获取 OrthoPlus.
89
90一旦上传了其中一种物件类型,**Request changes** 确认按钮即可启用. 点击它使状态变为 **Changes Requested**,病例回到 AlignerBot 席位手中. Agent 下次轮询时认领一个新锁,并以规划模式重新调度 OrthoPlus,同时应用修订物件. Phase-1 在融入临床医生的编辑后再次运行. 循环重复.
91
92为什么没有自由文本拒绝:OrthoPlus 规划级联没有英文解析器. 一个键入的指令如"move tooth 16 buccally"在管道中没有可落地的位置. XML/GPK 物件是 OrthoPlus 实际消费的结构化输入.
93
94## 第 6c 步——临床医生升级 → 退出 Bot 循环
95
96如果临床医生点击 **Escalate to lab manager**,状态变为 **Escalated**,持有者转交给技工所经理. Bot 不会在已升级的病例上重新调度. 技工所经理进行分诊——通常他们在聊天中与临床医生审阅,然后要么让病例重新走 Bot 流程(将
96其移回 **Designing**,使其路由到 AlignerBot 席位),要么改为手动处理该病例.
97
98## 成功的样子
99
100一次干净往返的终态:
101
102- 病例活动日志中有 **两次批准**——一次对应 **Treatment Plan** 步骤,一次对应 **Appliance Design** 步骤.
103- \`/cases/<id>\` 上 **状态为 Delivered**(数字交付——AlignerBot 病例没有生产制造环节).
104- **Files 面板** 包含原始扫描、Phase-1 的 \`.gvw\`、Phase-2 的矫治器输出(设计结果 zip 和 \`.gos.gpk\`),以及循环中上传的任何修订物件.
105- **临床医生的病例列表** 在 **Delivered** 下显示该病例,可以通过 [与患者共享治疗方案](/docs/share-treatment-plan-with-patient) 分享给患者.
106
107## 故障排查
108
109**分配后病例停留在 Designing 但 OrthoPlus 从未打开. ** 病例由一位不持有 **AlignerBot** 席位的设计师持有. 将病例重新走一遍 **Designing**,使其路由到 AlignerBot 席位用户——状态控件会预览由谁接收. Bot 只对 AlignerBot 席位持有者激活.
110
111**OrthoPlus 打开但加载病例时立即报错. ** 扫描数据格式错误或缺一颌. 在 \`/cases/<id>\` 中打开病例,确认上下颌扫描都存在并已确认(不是卡在上传中). 如有需要重新上传,然后在病例页点击 **Re-run design** 触发新的调度.
112
113**Phase-1 完成但 Approve 后从未调度 Phase-2. ** 临床医生批准了,但 Agent 没有拾取病例. 检查操作员工作站上的 Agent 是否已配对. 如果已配对但未调度,病例可能已不在 AlignerBot 用户手中;请在 \`/cases/<id>\` 上检查当前由谁持有该病例,等它回到正确持有者后使用 **Re-run design**.
114
115**临床医生的 Request changes 确认按钮保持灰色. ** 他们尚未上传 \`.xml\` 或 \`.gos.gpk\`. 对话框中的琥珀色横幅解释了两条合法路径. 要么前往 Studio 的 3D 审阅获取 \`.xml\`,要么使用 OrthoPlus Planner 获取 \`.gos.gpk\`. 在病例聊天中的自由文本指令不算数.
116
117**临床医生在批准 Phase-1 后想要不同的设计类型. ** 病例页上的 **Design options** 卡片带有 **Design kind** 选择器(**Aligner models**、**Arch model**、**Bracket bonding guide**、**Treatment plan only**),以及步骤范围和附件选项. 保存选项本身不会派发任何任务——更改类型后,点击 **Re-run design** 以新值重新调度.
118
119**病例在循环中不断重新调度 Phase-1. ** 查看活动日志,弄清每一轮由什么驱动. 如果病例确实卡住了,技工所经理可以在病例页覆盖其状态,待状态正常后使用 **Re-run design**——或者取消并重新提交.
120
121---
122
123*相关教程:[提交一个 AlignerBot 病例](/docs/submit-alignerbot-case) · [为您的技工所设置 AlignerBot](/docs/set-up-alignerbot-for-your-lab) · [安装并配对 Cympha Agent Manager](/docs/install-pair-agent-manager) · [将病例分配给设计师](/docs/assign-case-to-designer) · [批准或拒绝设计](/docs/approve-or-reject-a-design) · [使用 ClearAligner.AI 直达诊所](/docs/use-clearaligner-ai-direct) · [病例状态术语表](/docs/case-status-glossary) · [文件格式参考](/docs/file-formats-reference) · [角色矩阵](/docs/role-matrix)*
124`;export{n as default};

Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.