React 19 on Shiratsuki

深入 Cloudstay AIPMS：多渠道 OTA 会话持久化、DDL 双写汇聚流水线与安全受控 AI 桌面中枢架构

Wed, 16 Sep 2026 07:15:00 +0800

一、业务痛点与系统定位

在现代特色民宿与精品酒店的日常经营中，多渠道直销与分销是提升入住率的核心手段。经营者通常需要同时维护：

主流 OTA 平台：美团民宿/酒店商家后台（eBooking）、携程商家后台（Ctrip eBooking）、飞猪度假商家中心（Fliggy）；
第三方集中管理系统：如国内领先的民宿行业 SaaS“订单来了（DDL）”；
本地私有化系统：基于 Cloudstay 自主研发的内部 PMS 系统。

然而，这种多系统并行的常态在实际生产环境中引发了极其严峻的工程难题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


┌───────────────────────────────────────────────────────────────────────────────────┐
│ 多平台割裂下的民宿运营“超卖噩梦” │
├───────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 凌晨 02:15: 美团渠道售出一间「观海大床房」 │
│ │ │
│ ├─► [传统手工方式]: 经营者熟睡中，未能及时上线人工改房态... │
│ │ ▼ │
│ │ 凌晨 02:18: 携程渠道相同房型再次被旅客预订！ │
│ │ ▼ │
│ │ 【致命超卖】: 触发 OTA 平台高额罚款，导致客诉与店铺降权。 │
│ │ │
│ └─► [简易 RPA / 脚本方案]: │
│ ▼ │
│ 会话突然掉线 / 内存 Cookie 丢失 / 平台反爬弹窗 / 误操作关闭整店房量... │
│ │
└───────────────────────────────────────────────────────────────────────────────────┘

为了彻底终结“多渠道对单繁琐、Cookie 频死掉线、库存超卖风险与暴力脚本失控”的困局，我主导设计并研发了 Cloudstay AIPMS。系统定位于面向多渠道 OTA 与 PMS 的原生桌面控制中枢与智能自动化工作台，底层基于 Electron 43 + React 19 + TypeScript + Vite 6 + Node.js 24+ 架构构建。

二、桌面端工作台系统界面视界

系统主界面采用响应式分区与沉浸式工作坞设计：

左侧快速导航坞（Dock）：无缝切换 AI 工作台、本地 Cloudstay PMS、三渠道 AI 浏览器、订单来了独立工作区、运行日志 与 全局安全设置；
中央交互区与热门操作卡片：提供高频业务意图建议（如“查询今天待处理订单”、“查看最近经营数据”、“检查未回复评价”）；
安全受控输入栏：醒目标注当前操作渠道（如美团/携程）以及“只读计划”安全防护盾牌，重要写操作必须通过明确的人工确认卡，右侧状态指示灯实时上报底层模型引擎连通状态。

三、核心架构：会话保险库（Session Vault）与多渠道保活探针

在 Electron 桌面环境中集成多个复杂的外部商业 Web 系统，最大的挑战是：“如何让各平台的登录态长期持久化，而不让经营者每次打开软件都重新扫码或输入短信验证码？”

Chromium 默认将站点派发的会话 Cookie（Session Cookie）保留在内存中，在调用 app.exit(0) 时直接销毁。常规浏览器插件和简单脚本根本无法解决重启丢失登录态的问题。

1. 基于 Windows DPAPI 的加密会话保险库（Session Vault）

Cloudstay AIPMS 构建了专有的会话保险库子系统：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


┌────────────────────────────────────────────────────────────────────────────────────┐
│ Cloudstay AIPMS 会话生命周期与保险库机制 │
├────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ [应用关闭前 / 心跳确认时 / PMS 登录后] │
│ │ │
│ ▼ 提取内存中的 Session Cookies │
│ [Electron safeStorage (Windows DPAPI 当前用户硬件级加密)] │
│ │ │
│ ▼ 写入持久化快照 │
│ [用户数据目录: session-vault/<workspace>.vault] │
│ │ (严格施加 7 天不可延展 TTL，过期快照主动作废，拒绝明文落盘) │
│ │ │
│ ========================= [用户次日重新启动应用] ======================== │
│ │ │
│ ▼ 在任何 WebContents / 视图创建之前 │
│ [解密快照并回填至 persist:cloudstay-aipms-<工作区> 分区] │
│ │ │
│ ▼ 显式触发 │
│ [cookies.flushStore()] ──► 登录态无缝复活，用户免扫码直接进入工作台 │
│ │
└────────────────────────────────────────────────────────────────────────────────────┘

为了彻底防止被 OTA 平台识别为异常爬虫客户端，系统还在网络层做了关键防指纹处理：

动态精简 User-Agent：只剔除 Electron/x.y.z 敏感特征字段，保留完整原生 Chrome 版本号，既避免被平台风控拦截，又防止因锁定旧版本 UA 撞上平台的“浏览器版本过低”拦截页；
存储硬契约：将 persist:cloudstay-aipms-pms、persist:cloudstay-aipms-meituan 等分区视为不可变数据结构，通过单元测试硬编码锁定，防止升级时会话被意外清空。

2. 四态会话探针与低频无感心跳（Keepalive）

针对 OTA 平台服务端的空闲超时机制，系统设计了精细的四态探测引擎与页面内轻量心跳：

会话状态	状态定义	系统应对策略
`fresh`	探针确认会话处于安全有效状态	界面显示绿色常亮指示灯，允许执行库存读取与预备流水线。
`stale`	网络临时微抖或页面暂时未响应	绝不粗暴判定为失效！采用指数退避算法逐步拉大探测间隔（最高 60 分钟），杜绝无意义的弹窗误报。
`expired`	明确检测到被重定向至登录页	红色预警，自动阻断后续库存写入，并在界面直接提供「一键打开登录页」引导人工复登。
`unknown`	启动初始态或尚未探测	启动后后台排队依次触发首轮检测。

无感心跳机制：每隔 10~15 分钟（加入随机抖动），在页面内向当前平台自身发起一次同源只读 GET 请求。真实带 Cookie 的请求能够无声刷新服务端的 Session 活跃计时器，不改动 DOM、不刷新页面、不干扰用户当前正在进行的任何手动操作。

四、双写入目标流水线：Dual Order Sink

当系统从各 OTA 渠道的采集侧（自动轮询器，默认 60 秒间隔）捕获到新订单或订单变更事件后，事件会被推送至核心的 双写入目标流水线（Dual Order Sink）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 [ 真实 OTA 订单变更事件流 ]
 │
 ▼
 [ createDualOrderSink ]
 │
 ┌───────────────────────┴───────────────────────┐
 │ │
 ▼ ▼
 【目标一：PmsOrderSink】 【目标二：DdlOrderSink】
 │ │
 调用 Cloudstay PMS 核心服务 复用订单来了 (DDL) 活跃 Web 会话
 │ │
 - 内部房态日历实时扣减 - 通过注入的 window.http 执行真实业务调用
 - 本地流水账本持久化记账 - 支持全生命周期分支：
 - 触发多端本地即时广播 * 创建订单 (Create)
 * 取消订单 (Cancel)
 * 变更房型 / 改单 (Modify)
 * 人工单反向对冲 (Counter-Hedging)
 │ │
 └───────────────────────┬───────────────────────┘
 ▼
 [ 独立读回校验 (Read-Back Verification) ]
 - 重新拉取 DDL 与 PMS 实际落库状态
 - 34/34 项自动化集成用例全面保证强一致性

全分支覆盖：流水线完整适配了新增订单、用户主动取消、平台改单换房、以及通过人工录入单冲抵超卖等高难度边缘场景；
防伪回执与写后读回：拒绝将“接口返回 200”或“页面弹窗关闭”视作成功。每次写入操作执行后，流水线必须发起独立的读回请求，确认订单编号与房型在目标系统界面中真实可见，才向系统账本上报 applied 状态。

五、 AI 工作台与 Codex 集成：绝对的“安全红线”机制

在涉及酒店房态与真金白银的经营场景下，纯粹由 AI Agent 全自动点击修改房量是不可接受的巨大风险。Cloudstay AIPMS 确立了严格的 “只读计划 -> 预览卡片 -> 人工确认 -> 审计落库 -> 独立读回” 安全红线闭环：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


用户自然语言输入（例如：“把下周二美团的阳光大床房关掉，留一间预留房”）
 │
 ▼
[Codex 原生 RPC 子进程 (通过 stdio:// JSON-RPC 通信，只读沙箱环境)]
 │
 ▼
[匹配专用渠道 Skill] ──► (如 meituan-eb-cli-ops)
 │
 ▼
[只读预检阶段 (Read-Only Prep)]
- 唤起对应渠道适配器，定位至指定日期与房型
- 读取当前实际状态：[ 当前剩余房量: 3, 预留房量: 1, 房态: 开启 ]
 │
 ▼
[生成 1 × 1 × 1 不可变预览卡片]
- 明确标注影响范围：【单门店 × 单房型 × 单日期】
- 变动对比：[ 房态: 开启 ──► 关闭 ]，[ 剩余: 3 ──► 0 ]
 │
 ▼
[人工确认闸门 (Human-in-the-Loop)]
- 界面弹出阻断式预览卡片，等待经营者人工核对并点击【确认提交】
- （未点击确认前，主进程坚决锁死任何页面写操作控件）
 │
 ▼
[原子写入与写后读回 (CDP Atomic Action)]
- 写入本地审计凭据 (audit/meituan.jsonl)
- 仅触发一次真实点击提交
- 强制刷新日历，执行只读读回校验
- 校验前后差异与预期完全一致 ──► 返回成功回执！

1. Codex 本地配置的绝对隔离

AI 工作台后端的 Codex 引擎不依赖环境变量乱窜的外部配置，主进程只以项目根目录的 luna.config.toml 作为唯一权威标准；
启动时在系统临时目录建立硬链接作为原生 config.toml，通过 codex app-server --listen stdio:// 标准输入输出直接与主进程建立高性能 RPC 通道，杜绝 Token 复制泄露与配置漂移。

2. 严格的 Phase 1 写入边界

当前写入严格限制在 1 × 1 × 1 范围（单门店、单房型、单日期）；
精细区分三种原子操作：
- set_inventory：仅调整实际剩余房量，预留房量和房态开关严格保持不变；
- close_room：仅使用原生单日房态开关关房，严禁以“库存设为 0”伪装关房，并强制校验当前预留房为 0，防止误关已预留房间；
- open_room：反向开启房态开关。

六、全链路工程验证与测试指标

为了确保系统在高并发、网络抖动及复杂平台环境下的绝对稳定性，项目构建了完备的自动化测试体系：

1
2
3
4
5


# 运行离线多通道隔离性与读回测试
node tools/run-isolated-ota-verification.mjs

# 运行 DDL 订单汇聚流水线单元与端到端测试
npm run test:sink

通道隔离性：通过两个完全独立的 Node 进程与双内存 PMS 实例，验证美团与飞猪在并发事件下的数据零串扰；
订单汇聚套件：test/ddl-order-sink.test.js 与 test/order-e2e-verifier.test.js 共 34 个深度端到端测试用例全部通过；
合规与隐私审计：全系统所有操作日志均采用字段白名单制，日志中绝不包含任何用户密码、Bearer Token、Cookie 或未脱敏旅客敏感信息。

七、总结

Cloudstay AIPMS 的实践证明：在外部 SaaS 平台高度碎片化、传统 API 接口封闭且多方博弈的商业环境下，“以现代化 Electron 桌面为宿主、以硬件加密会话保险库解决持久化、以双写入目标保证业务对冲、以受控 AI Agent 严格绑定只读计划与人工确认”，是构建企业级高可靠自动化系统的最优架构范式。

解构「衡准」：高中物理手写作答 AI 自动批改系统——从多阶段视觉推理、评分标准版本化到考务网页闭环回填

Wed, 16 Sep 2026 07:10:00 +0800

一、研发背景与核心工程挑战

在高中物理教学评估中，主观解答大题（如力学综合、电磁感应动力学、带电粒子在复合场中的运动等）在高考和各类大型模拟考中占据着决定性的分值比例。然而，主观大题的评卷长期以来是整个智慧教育领域中最难攻克的“深水区”。

传统教育信息化软件或通用 OCR 改卷方案在面对高中物理大题时，普遍遭遇以下难以逾越的工程瓶颈：

手写字符与物理符号的语义崩塌：学生在有限时间内作答，字迹连笔潦草、划线涂改频繁。通用 OCR 极易将物理矢量角标（如 $v_A$、$v_B^2$、$F_{N1}$）错误切分，把上下标拍平甚至误识别为乱码，直接导致后续推导链断裂；
图文混排与草图受力分析：物理试题答卷往往伴随学生自主绘制的隔离体受力分析图、速度-时间（$v-t$）草图或几何轨迹草图。基于纯文本的解析方案完全无法“看懂”草图中的辅助线与标注；
推导步骤的逻辑等价性判断：高中物理强调“分步给分”。同一道大题，学生可能采用动能定理、功能关系、动量定理或牛顿第二定律结合微元法等截然不同的物理路径求解。简单依赖关键词匹配或正则提取公式，必定造成极其严重的误判与漏给分；
大模型直接打分的幻觉陷阱：直接将整页试卷丢给多模态大模型并提示“请给出每小问得分和总分”，已被大量实际测试证明存在致命缺陷——模型在长上下文下经常出现算术幻觉（各小题给分累加与最终总分不一致）、评语苛刻但总分虚高、或者在关键扣分点上因上下文注意力分散而产生“薛定谔的给分”。

针对上述行业痛点，我自主设计并开源了 衡准 · EquiGrade（GitHub 仓库：Shiratsuk1/EquiGrade）。系统定位于面向高中物理主观大题的本地单机（Windows 优先）自动改卷与网页考务流水线工作台，底层技术栈采用 Electron 43 + React 19 + TypeScript 5.8 (Strict) + Express 5 + Vite 7，自动化测试套件包含 241 个测试用例（保持 100% 通过）。

二、桌面工作台整体架构与交互视界

系统界面采用现代双栏与卡片化设计，左侧为主控管理与配置面板，右侧为嵌入式目标考务网页（智学网 / 睿芽云）视窗：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


┌──────────────────────────────────────────────────────────────────────────────────┐
│ 衡准 · EquiGrade 桌面工作台 │
├───────────────────────────────────────┬──────────────────────────────────────────┤
│ 控制中枢与批改面板 (React) │ 考务网页视窗 (WebContentsView) │
│ │ │
│ [状态总览卡片] │ ┌────────────────────────────────────┐ │
│ - 目标考务站点：智学网 (Zhixue) │ │ 智学网统一评卷系统在线工作台 │ │
│ - 当前评分细则：圆周运动综合题 (v2.1)│ │ │ │
│ - 批改进度：42 / 120 份 │ │ [题目原图] [考生手写答卷高清区域] │ │
│ - 待人工复核：2 份 (needs_review) │ │ │ │
│ │ │ 评分框：[ ] [提交并下一份] │ │
│ [自动批改准备自检 (4 项全部就绪)] │ └────────────────────────────────────┘ │
│ ✔ 评分标准已绑定并版本化 │ │
│ ✔ 目标网页考务控件已连接 │ - 自动拦截并提取答卷图像 (SVG/PNG) │
│ ✔ 学生答卷读取控件就绪 │ - SHA-256 图像哈希防串卷校验 │
│ ✔ 最终总分输入框可使用 │ - 本地批改完成后自动写分并触发提交 │
│ │ │
│ [最近流水线活动 (实时日志与证据链)] │ │
│ - [14:20:12] 答卷哈希: a8f9... 已提取│ │
│ - [14:20:14] 稳定链路：答案核验通过 │ │
│ - [14:20:16] 本地计分引擎回填: 16分 │ │
└───────────────────────────────────────┴──────────────────────────────────────────┘

工作台系统内部各模块解耦清晰：

UI 交互层：基于 React 19 + KaTeX 实现试卷题目、参考答案与 LaTeX 物理公式的高性能确定性渲染；
本地 Express 核心服务：启动于随机高位回环端口，杜绝端口冲突；承载完整的批改工作流编排（Workflows）、计分引擎（GradingEngine）、模型客户端（ModelClient）与产物审计持久化；
本地安全存储：API 密钥全部通过操作系统底层 AES-256-GCM 加密，批改历史、评分细则版本与中间证据全部落地在本地 .data/ 目录，无任何云端数据泄露风险。

三、双大题批改链路架构设计

在衡准系统中，我设计了双轨并行的批改流水线：默认的“稳定分阶段链路” 与 前沿的“Responses Agent 视觉链路”。用户可在教师模型页面按需自由切换。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


flowchart TD
 Start["学生手写答卷图像 (高清截取 + 计算 SHA-256)"] --> LinkChoice{"选择批改链路"}

 subgraph PipelineA ["链路一：稳定分阶段链路 (默认，/chat/completions)"]
 LinkChoice -->|"默认推荐"| Preprocess["本地图像预处理 (同尺寸对比度与边缘增强)"]
 Preprocess --> Paddle["PaddleOCR-VL 布局解析<br/>全量 bbox 坐标分块与转录索引"]
 Paddle --> FirstPass["教师模型首轮核验<br/>全量转录矫正 + 各小问最终答案快速判定"]
 FirstPass --> AnsDecision{"最终答案正误?"}
 AnsDecision -->|"全部正确"| QuickPath["【极速支路】<br/>本地计分引擎直接判满分<br/>跳过繁重过程审验 (耗时骤降 70%)"]
 AnsDecision -->|"存在错误 / 判空 / 存疑"| DeepPath["【并行复核支路】<br/>1. 整页视觉复核支路<br/>2. 逐步骤细粒度评分点审验支路"]
 end

 subgraph PipelineB ["链路二：Responses Agent 大题链路 (前沿，/responses)"]
 LinkChoice -->|"手动开启"| WebPEncode["全量输入标准化为 WebP q90<br/>学生答卷灰度增强 · 题图保留色彩"]
 WebPEncode --> MainAgent["主 Agent 通读整页答卷<br/>(完全禁用 PaddleOCR)"]
 MainAgent --> InspectCheck{"字迹模糊 / 局部细节存疑?"}
 InspectCheck -->|"需要放大 (最多3轮/6区域)"| ToolCall["调用只读局部工具<br/>inspect_page_tiles / inspect_page_region"]
 ToolCall --> MainAgent
 InspectCheck -->|"看清并审验完毕"| AgentOutput["输出严格结构化审验结论与定位证据"]
 end

 QuickPath --> DeterministicEngine["后端结构校验与权威计分引擎 (GradingEngine)"]
 DeepPath --> DeterministicEngine
 AgentOutput --> DeterministicEngine

 DeterministicEngine --> ScoreCalculation["按当前评分标准版本重算总分<br/>(严格依据步骤给分规则，绝对不信任模型总分)"]
 ScoreCalculation --> ReviewCheck{"是否超出复核阈值?"}
 ReviewCheck -->|"是 (得分波动/无法认读)"| MarkReview["标记 needs_review (记录置信度与证据快照)"]
 ReviewCheck -->|"否 (完全正常)"| NormalPass["标记批改成功 (Pass)"]

 MarkReview --> PipelineWriteback["考务流水线回填与自动提交"]
 NormalPass --> PipelineWriteback

 PipelineWriteback --> NextPaper["自动翻页进入下一份 / 历史留档"]

1. 链路一：稳定分阶段链路（Stable Phased Pipeline）

如上图真实运行记录所示，系统在大题批改中展现了清晰的分流特性：

小问 (2) 触发极速通道（满分 5/5）：教师模型首轮审验确定最终答案 $t = 9\text{s}$ 与参考答案完全一致（置信度 98%），系统按预设规则直接核定满分 5/5，未触发耗时繁琐的过程深审；
小问 (1) 触发深度复核通道（得分 3/7）：首轮发现最终答案与参考答案（$18\text{m}$）不一致，自动触发局部视觉复核与 4 项细分给分点审验（2项通过，2项未满足），最终精确给出 3 分。

针对大批量联考中网络开销与响应延迟敏感的场景，稳定分阶段链路采用了**“分阶段正误分流”**的创新架构：

第一阶段：PaddleOCR-VL 空间切分 输入预处理答卷图，由 PaddleOCR 生成整页的文本块外接矩形框（bbox）坐标与层级 Markdown 索引。
第二阶段：教师模型首轮核验（Fast Answer Check） 教师多模态模型接收试题文本、参考答案与 OCR 结构，首轮核心任务仅聚焦于全量转录校正与每个小问的最终答案（如第 (1) 问：$v_B = 8.0\text{ m/s}$，第 (2) 问：$N_C = 15\text{ N} > 0$ 能通过）。
极速支路与并行深审：
- 若某个小问最终答案完全正确且无逻辑硬伤，本地计分引擎直接判定该小问满分！由于高分卷通常占比较高，此机制能节省超过 70% 的模型推理 Token 和时间开销；
- 若最终答案出现错误、留空或模型标记 uncertain，系统则立即并行触发两条深度支路：一条走整页视觉重核，另一条针对该小问的评分步骤（公式、代入、分段推导）逐一审验，寻找可踩分点。

2. 链路二：Responses Agent 大题链路（Responses Vision Pipeline）

为了彻底摆脱传统 OCR 算法对复杂手写公式的结构性误切，系统引入了新一代基于 OpenAI 原生 /responses 协议的 Responses Agent 视觉链路：

完全禁用 PaddleOCR：主 Agent 将学生原始作答视为不可分割的视觉整体，不依赖外部文本切片；
图像规格化：学生答卷图统一转换为高质量 WebP (q90) 并进行灰度自适应对比度增强；题图与参考答案图保留色彩通道，保证图表辨析度；
主动式局部放大工具（Active Zooming Inspection）：当遇到涂改、小字角标或铅笔浅痕时，主 Agent 可主动发起结构化工具调用：
- inspect_page_tiles：按网格定位分块；
- inspect_page_region：按归一化坐标范围 $[x_1, y_1, x_2, y_2]$ 提取局部超高分辨率切片。为防止 Agent 陷入无休止的局部检查，核心层施加硬性闸门：单卷交互最多允许 3 轮、累计最多放大 6 个独立区域。
协议与防幻觉约束：
- 强制固定 store:false，实现真正的无状态纯客户端会话管理，不依赖云端易失效的 previous_response_id；
- 严格采用服务端校验的 json_schema，拒绝任何形式的降级；
- 针对 LaTeX 转义引发的 JSON 解析崩溃，独创 [[LATEX_BS]] 安全传输协议，确保复杂物理公式（如根号、矩阵、微积分积分号）100% 确定性解析。

四、核心机制：评分标准版本化与权威计分引擎

1. 评分标准（Rubric）的数据建模与版本化快照

在传统阅卷中，老师经常在“试评数十份试卷”后，发现考生的某种特殊解法应当给予同等步骤分，从而需要修改评分标准。若系统没有版本化管理，修改标准会导致历史已评试卷出现“前后打分尺度不一致”的严重教学事故。

衡准建立了严格的评分标准版本控制系统：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// shared/types/rubric.ts
export interface RubricVersionSnapshot {
 id: string; // 规则唯一标识
 paperId: string; // 所属试卷 ID
 questionIndex: number; // 大题序号
 version: number; // 严格单调递增版本号 (v1 -> v2 -> v3)
 createdAt: string; // 创建时间快照
 summary: string; // 变更摘要说明
 subQuestions: {
 index: number; // 小问号
 maxScore: number; // 本小问满分
 points: {
 id: string; // 评分点 ID (如 "q1-step1")
 type: 'formula' | 'substitution' | 'result' | 'text'; // 评分点类型
 score: number; // 赋分值 (如 2.0 分)
 description: string; // 给分条件说明 (如 "正确列出牛顿第二定律方程")
 requiredSymbols: string[]; // 关键物理量符号白名单
 alternativeForms?: string[]; // 允许的等价变形公式
 }[];
 }[];
}

不可变版本机制：每一次对给分点的调整都会递增生成全新的版本快照；
历史安全重判：当使用新细则对历史答卷进行复评时，系统会创建一条关联新版本的新批改记录，绝对不会覆盖或擦除旧版本的历史证据与得分。

2. 本地权威计分引擎（GradingEngine）与严苛过程给分红线

衡准确立了核心设计公理：模型只负责语义与视觉审验，绝对不信任模型返回的总分。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


// server/src/gradingEngine.ts
export function recalculateAuthoritativeScore(
 rubric: RubricVersionSnapshot,
 auditResult: ModelAuditResult
): ComputedGrade {
 let finalScore = 0;
 const itemizedDetails = [];

 for (const subQ of rubric.subQuestions) {
 const subAudit = auditResult.subQuestions.find(s => s.index === subQ.index);
 let subScore = 0;

 // 黄金法则 1：若该小问首轮被确认答案正确 (correct)，直接赋予小问满分
 if (subAudit?.verdict === 'correct') {
 subScore = subQ.maxScore;
 } else {
 // 黄金法则 2：逐步骤校验审验结论
 for (const point of subQ.points) {
 const pointAudit = subAudit?.points.find(p => p.id === point.id);

 // 过程评分红线：严格检查公式与代入合法性
 if (pointAudit?.status === 'satisfied') {
 // 公式点必须具有可见符号逻辑，禁止仅靠数字反推公式
 if (point.type === 'formula' && !pointAudit.hasExplicitFormulaEvidence) {
 continue; // 拒绝给分
 }
 subScore += point.score;
 }
 }
 // 单小题得分上限截断
 subScore = Math.min(subScore, subQ.maxScore);
 }

 finalScore += subScore;
 itemizedDetails.push({ subIndex: subQ.index, score: subScore });
 }

 return { finalScore, itemizedDetails, status: 'calculated' };
}

过程给分物理红线：
- 公式点（Formula）：必须有学生在卷面上白纸黑字写出的符号推导（如 $F - f = ma$）。如果学生直接代入数字算式并算出结果，哪怕数字正确，也不得反向推导“学生心中已知该公式”而补给公式分；
- 代入点（Substitution）：必须对应正确的公式与正确的题目已知量数值；
- 结果点（Result）：最终数值、正负号、单位必须同时合规，结果错误绝对不可反向证明中间过程无误。

在上图所示的真实批改详情中，系统忠实体现了物理阅卷的严苛物理红线与证据链追踪：

步骤 1-1（公式定理）：学生规范写出了两车共速最大间距条件 $v_1 - at = v_2$，审验通过（置信度 98%），按标准计入 2/2 分；
步骤 1-2（代入数据）：学生由字母公式直接跳步算出时间结果，卷面上未按给分细则写出代入速度与加速度的过程式 $12 - 1.5t_1 = 6$，系统精准命中“审验未满足（置信度 95%）”，严守红线坚决不给分（0/1 分）；
步骤 1-3（求解中间量）：解得 $t_1 = 4\text{s}$，审验通过计 1/1 分；
步骤 1-4（位移关系）：位移差写为 $\Delta x = x_1 - x_2$，漏掉了两车初始间距 $x_0$，判定审验未满足（0/2 分）；
右侧高亮与 OCR 坐标联动：右上角自动裁剪出包含该步骤的手写原卷高亮切片，右下角展示 PaddleOCR 识别区块的逐行置信度（99%、98%），实现给分证据 100% 卷面可定位可追溯。

五、考务网页自动化流水线（智学网 / 睿芽云）

衡准桌面端的右半侧是与实际生产考务系统无缝打通的嵌入式工作区。通过底层的 WebContentsView 与 DOM 隔离通道，系统攻克了各大阅卷平台的反自动化与操作时序难题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


┌────────────────────────────────────────────────────────────────────────┐
│ 考务平台自动化调度流水线 │
├────────────────────────────────────────────────────────────────────────┤
│ 1. 考务页面就绪监听 │
│ 等待 DOM 容器加载完成 (智学网 #topicImgContent / 睿芽云 #panelKey) │
│ │
│ 2. 答卷图片智能提取与三因子防串卷保护 │
│ - 提取来源：img.src / canvas / OSS 私有存储桶 │
│ - 矢量转换：SVG 答题卡无损光栅化转为高分辨率 PNG │
│ - 防串卷三因子：[ pageKey ] + [ pageToken ] + [ 答卷 SHA-256 哈希 ] │
│ │
│ 3. 本地并发批改与证据链生成 │
│ - 触发本地 Express API 批改工作流 │
│ - 产生完整审验记录与 grading-artifacts 归档 │
│ │
│ 4. 考务前端 DOM 安全回填 │
│ - 定位目标打分输入框 (#txt_marking_all) │
│ - 触发 native input 事件与键盘按键合成模拟 │
│ - 校验输入框写入值与后端重算分值 100% 相等 │
│ │
│ 5. 自动提交与翻页 │
│ - 触发提交按钮点击 (#bnt_save) │
│ - 等待服务器回执，自动触发翻页至下一份试卷 │
│ - 若连续 3 次遇到不可读或网络异常，流水线自动挂起警报 │
└────────────────────────────────────────────────────────────────────────┘

本地演练场（Mock Arenas）

为了让系统在不连接真实学校考务账号的情况下也能进行 100% 高保真回归测试，衡准内置了两个完备的测试端点：

/zhixue-mock：像素级复刻智学网的真实 DOM 结构与打分流转逻辑（严格模拟“未保存打分时禁用下一份按钮”等底层细节）；
/mock-grading：通用 data-grading-* 标注页，支持导入 JSON 试卷用例并动态生成 SVG 手写答卷，供开发者进行自动化回归演练。

六、批改产物缓存与透明审计

每次批改完成后，系统除了向界面回传分数外，还会在本地根目录的 grading-artifacts/<结果ID>/ 下完整固化本次批改的所有现场凭证：

1
2
3
4
5
6
7
8


grading-artifacts/res_20260916_001/
├── preprocessed-student-paper.png # 本地增强后的学生手写答卷
├── question-reference-image.png # 试题与标准参考答案图
├── paddleocr-blocks.jsonl # 稳定链路导出的全量 OCR 区块与坐标
├── agent-webp-tiles/ # Agent 链路请求的局部高倍放大切片 (WebP q90)
├── response-output-raw.json # 模型原生完整的输出结构与 Tool Calls
├── rubric-snapshot-v2.json # 当次批改绑定的评分标准快照
└── final-audit-result.json # 包含所有步骤置信度、重算分数的最终凭证

在历史记录界面中，用户可以随时点击打开任意一份历史试卷的产物目录，进行毫秒级的问题定位与溯源。这种“证据先行、完全透明”的审计能力，使得 AI 自动改卷不仅具有极高的判卷速度，更具备了足以面对家长和学生查卷检验的严密公信力。

七、总结与未来演进

衡准 · EquiGrade 证明了：在大模型落地于极其严谨的教育评卷场景时，“唯有将多模态大模型的视觉理解优势，与本地确定性计分引擎、版本化评分标准以及严密的考务自动化闭环深度融合，才能彻底战胜幻觉，真正构建出工业级可用的智能工作台。”

项目开源仓库：https://github.com/Shiratsuk1/EquiGrade
技术讨论与共建：欢迎提出 Issue 与 PR，共同推动手写多模态评估体系的工程进化！

React 19 on Shiratsuki

深入 Cloudstay AIPMS：多渠道 OTA 会话持久化、DDL 双写汇聚流水线与安全受控 AI 桌面中枢架构

一、 业务痛点与系统定位

二、 桌面端工作台系统界面视界

三、 核心架构：会话保险库（Session Vault）与多渠道保活探针