点评登记核查 PerryLink/dsh-ota-review-check

dsh-ota-review-check — 在线点评与回复登记核查

dsh-ota-review-check 读取一份在线点评与回复登记表——房源表头，加上每条点评一行——核查这份登记表自身的完整性与闭环：每条点评是否记录了内容或评分，已回复的点评是否带有回复日期和回复人，回复是否早于点评，未回复的点评是否落在登记表自己写明的期限内，问题类型是否出自你所在机构自己的词表，以及点评编号是否唯一。

它能回答什么

| 你问 | 它答 |
| 某行既没填 点评内容 也没填 评分。会报什么？ | OT-001 会报出这一行：一条点评至少要记录 content 或 score 两个字段之一。它只检查其中一个是否填写，不判断点评内容是否属实，也不判断这条点评是否为恶意点评。 |
| 某行标了 已回复，但 回复日期 和 回复人 单元格是空的。会报什么？ | 只要某行的 replyStatus 命中配置的条件之一（是、Y、yes、true、已回复、√），OT-002 就报出该行缺少 repliedAt；而 OT-005 要求每一行只要带 回复人 列就必须填写 replier，所以即使某行标了 未回复，空单元格同样会被报出。两者都只检查单元格是否填写：都不说回复是否及时，也不说回复是否恰当。 |
| 我们的登记表 回复期限 列整列都是空的。核查会假定 24 或 48 小时的时限吗？ | 不会。插件不内置任何平台的回复时限：没有 replyDeadline 值就没有可比较的对象，OT-003 会出现在 skipped 里，而不是去假定多少天。它只对照登记表自己在 回复期限 列写下的期限运行，命中意味着那个期限与点评日期不一致——并不代表违反了平台规则。 |
| 回复日期 写成 2026年3月15日，而且早于 入住日期。会抓到什么？ | OT-004 比较 checkIn 与 repliedAt，报出早于点评日期的回复日期，同一天算作不晚于；无法解析的日期——比如 2026年3月15日，因为只有 2026-03-15、2026/3/15 和 2026.3.15 可带可选时间解析——会在该行报出，而不是默默放过。它只比较这两个日期，不判断回复是否及时。 |
| 我们用自己习惯的说法填了 问题类型。为什么报告说核查没有运行？ | OT-006 出厂时 values 列表为空，也就是未配置，所以它会在 skipped 里写明这一原因，而不是自己发明一套分类体系：词表（卫生、服务态度、设施设备、价格、噪音、预订与入住，或者你自己的说法）由你所在机构决定。你一旦列出词表，规则就会报出任何不在列表中的值，此外不再检查别的——某条点评属于哪一类，始终由操作人员判断。 |
| 同一 点评编号 在台账中出现两次，会报告什么？ | OT-007 会把第二行报为第一行的重复，比较 reviewNo 时忽略空白。唯一性是每条点评只登记一次的前提，所以这条规则放在 warn；它只检查唯一性，不说明两行中哪一行是副本。没有 reviewNo 列时，规则在 skipped 中说明自己，而不是默默通过。 |

遵循的标准

| 文档 | 编号 | 引用它的规则 |
| 《中华人民共和国电子商务法》与平台服务规则 | 现行版本与条号本次未核实 | OT-001 |
| 《中华人民共和国电子商务法》 | 现行版本与条号本次未核实 | OT-002, OT-004, OT-005, OT-007 |
| 各在线旅游平台服务规则（本机构配置） | 无统一标准（本条依据为本机构配置的回复时限） | OT-003 |
| 本机构点评管理办法（本机构配置） | 无统一标准（本条依据为本机构分类口径） | OT-006 |

边界： 这个插件检查 在线点评回复台账，看一份台账能被要求做到哪些闭环——每条点评记录了自己的内容或评分，回复带有日期和回复人，回复不早于点评，未回复的点评落在台账写明的期限内，问题分类来自你的词表，点评编号唯一。它不判断回复是否得体、点评是否该申诉或删除、差评是否恶意、服务质量是否合格。

⚠️ 法律在这里要求什么——又不要求什么

《中华人民共和国电子商务法》已取得并逐字阅读（见 rules/evidence/clause-verification.md），这次核查推翻了本规则包早先的表述。第三十九条把义务放在平台经营者身上，而不是商家：

电子商务平台经营者应当建立健全信用评价制度，公示信用评价规则，为消费者提供对平台内销售的商品或者提供的服务进行评价的途径。
电子商务平台经营者不得删除消费者对其平台内销售的商品或者提供的服务的评价。

没有任何条款要求商家回复点评。 所以这个插件检查的义务来自各平台自己的服务规则和贵机构的管理办法——从不来自法条——规则包和这份 README 现在都不再把回复说成法律义务。第十七条（不得虚构评价）和第二十条（按承诺交付）讲的是别的事，这里刻意不引用。

每条 excerpt 仍然写着「本次未取得」，每条规则仍然是 warn 或 info——平台服务规则本身没有取得，法条管的是平台而不是商家，把某条规则提到 direct 等于把台账缺口包装成违法。

插件不内置任何平台的回复时限。 OT-003 拿点评日期和台账自己 回复期限 列里写明的期限比较，该列为空时它会在 skipped 中报告自己。一条发现说的是「期限和点评日期对不上」，从不说「你违反了平台规则」。分类词表同样默认为空。插件也不读情感：它检查低分是否记录了整改，而什么算低分由你的配置决定，不是它的判断。

兼容性

| 层面 | 状态 |
| Harness | 对等范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0 — 已验证同时接受 0.2.0-rc.2 和 0.2.1-alpha.1。故意不声明 engines.dsh：它没有读取方，也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部（纯 ESM；无原生代码、无网络、无模型调用） |
| 工具模式 | 在 native、ptc 和 both 下都能用；做整月点评审查请用 ptc |

它做什么

注册 ota_review_check 工具。它读取一份点评与回复登记表——属性表头加上每条点评一行——套用带版本号的规则包，返回报告。

| 规则 | 检查项 | 严重级别 | 依据类型 |
| OT-001 | 点评记录了内容或分数 | warn | principle |
| OT-002 | 已回复的点评带有回复日期 | info | local |
| OT-003 | 未回复的点评落在记录的期限内 | info | local |
| OT-004 | 回复不早于点评 | info | local |
| OT-005 | 已回复的点评写明了回复人 | info | local |
| OT-006 | 问题类型来自你的词表（默认关闭） | info | local |
| OT-007 | 点评编号唯一 | warn | principle |

安装

dsh plugin --profile <name> add dsh-ota-review-check
dsh --profile <name> --dump-config | grep 'dsh-ota-review-check'

配置

| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/ota-review-check.yaml | 规则包路径，相对于包根目录 |
| disabledRules | string[] | [] | 要停止运行的规则 id；每个都会出现在 skipped 里 |
| onlyRules | string[] | [] | 只运行这些规则 id；留空则运行全部规则 |
| skipNotes | string | "" | 追加到每条 skipped 原因后面的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |

几个值得了解的规则级参数：

- OT-002 conditionValues — 你的是否回复列里表示「已回复」的取值，默认是 [是, Y, yes, true, 已回复, √]。
- OT-003 读取登记表的 回复期限 / replyDeadline 列。插件从不按天数推算期限，因为各平台的窗口不一样。
- OT-006 values — 你的问题类型，例如 [卫生, 服务态度, 设施设备, 价格, 噪音, 预订与入住]。留空表示不检查。

材料格式

工具接受 JSON 或 YAML：

hotel: 某某门店 period: 2026 年 3 月 platform: 某某平台 rows:
- { 序号: '1', 渠道: 某某平台, 房型: 标准大床房, 入住日期: 2026-03-01,
总分: '4.5', 评分制: 5 分制, 点评内容: 位置方便，前台服务热情，房间隔音一般。, 是否回复: 是, 回复日期: 2026-03-02, 回复期限: 2026-03-04, 回复人: 张店长, 问题类型: 噪音, 是否整改: 是 }

列名匹配不区分大小写，并忽略空格、下划线和连字符；登记表自己的列名会保留，所以一条发现会写明它读的是哪一列。

规则来源

规则数据放在 rules/ota-review-check.yaml。规则包的头部完整说明了引用缺口，每条规则的 note 又重复了与该规则相关的那部分。加载时的守卫通常要求「摘录必须是至少八个字符的真实引文」，但它分不清引文和描述——所以这个规则包靠头部、每条规则的 note，再加一个测试来兜底，该测试断言每个 excerpt 都承认这个缺口。

故障排查

- OT-003 报告自己被跳过。 登记表里没有记录回复期限。各平台的窗口期不同，所以插件不会替你补一个——请把该平台的期限记进台账。
- OT-003 触发，但回复其实是及时的。 登记表里的 回复期限 与评审日期不一致。
- OT-006 从不运行。 它的词表是空的；请填入你自己的业务类别。
- OT-006 在我认为没问题的类别上触发。 该值不在你的列表里。要么放宽 values，要么改正单元格——插件自己不会对评审做分类。
- OT-007 在同一条评审上触发两次。 一条评审可能确实被处理两次（一次跟进回复）。请区分这两行，而不是复用同一个编号。
- 插件装上了，但工具始终不出现。 检查 main 是否指向 lib/index.mjs，以及 pnpm run build 是否生成了它；main 写错会让加载器静默跳过该入口。
- dsh plugin add 以不兼容为由拒绝该包。 peer 范围覆盖 0.1.x 和 0.2.x；如果你的运行时不在其中，请显式授予豁免： dsh plugin --profile <name> allow-version dsh-ota-review-check@0.1.0 --dsh-version <runtime> --accept-risk
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围，它早于 0.2 系列。运行时会在安装时强制校验 peer 兼容性，所以声明的范围才是正确的；这是 dsh-plugin-dev 里已知的上游问题。

开发

pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, the shared table-plugin suite plus paired fixtures
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-ota-review-check # refresh src/shared from ../_shared

这个插件是纯数据的：src/model.ts 声明表结构，共享工具包提供读取器和检查引擎，规则包声明每一项检查。

许可证

Apache License 2.0 © 2026 dsh-ota-review-check contributors.