Regmark02
受众与场景
给谁用，在什么时候用，用完手里多了什么。
谁会用
| 受众 | 他们手上的问题 | Regmark 给的东西 |
|---|---|---|
| 独立站和 DTC 品牌的开发者 | 主题、插件、促销规则谁都能改，改完没人知道机器读到的还对不对 | 发版前的门禁，加上每天一次的巡检 |
| 出海独立站团队和服务商 | 想被 ChatGPT、Gemini 推荐，可资料几乎全是英文，用的又多是 WooCommerce 或自研系统 | 中文文档，能在本地跑的检查，可以直接交给客户的报告 |
| 建站公司、代运营、系统集成商 | 给客户接完代理协议，拿什么证明接好了 | 一份可以复现的验收报告，能批量跑多家店 |
| 协议适配器和 feed 插件的作者 | 插件输出的东西和店里的真实数据对不对得上，缺回归测试 | 一个预置了缺陷的样板店，一条现成的 CI 流水线 |
| 开源电商框架的维护者 | Medusa、Saleor、Vendure 上与代理相关的插件需要一致性测试 | 可以挂进各自 CI 的检查套件 |
| 平台方的内容治理团队 | 第三方卖家在商品内容里塞写给代理看的指令 | 内容卫生规则，可以单独调用 |
首期只认真服务前四类。后两类的需求会影响接口怎么设计，但不排进首期交付。
典型场景
下面六个场景里的数字是为了说明用法编的，不是实测结果。
发版门禁
- 起因：有人提了一个升级主题的合并请求。
- 做法：CI 在预览环境上跑
regmark audit，价格不一致的预算设为 0。 - 结果：新主题在促销期间把 JSON-LD 里的价格写成了原价，7 件商品对不上。合并请求被拦下，报告直接指到输出那个字段的模板。
大促前夜
- 起因：晚上十点改价，零点开卖。
- 做法：改完价跑一次只读巡检，重点看 feed。
- 结果：feed 插件每小时导出一次，37 件商品在 feed 里还是旧价。运营决定手动触发一次导出，不等它自己跑。
接入验收
- 起因：服务商给客户的 WooCommerce 店装好了 UCP 适配器。
- 做法：跑完整套件，包括结账探针和 20 个购物任务。
- 结果：一份报告，列出通过的规则、失败的规则和每一条的证据，附在验收单后面作为交付物。
模型更新后的回归
- 起因：某家模型发了新版本。
- 做法：先重放上次录下的购物任务，确认工具自身没变；再用新模型实跑一遍，对比任务成功率。
- 结果：成功率从 85% 掉到 60%，掉的全是带尺码筛选的任务。问题出在变体数据的表达方式上，不是模型变笨了。
内容卫生
- 起因：店里开放了用户评论，或者接进来一批供应商写的商品描述。
- 做法：对新增内容跑内容卫生规则。
- 结果：3 条评论里有写给机器看的指令，1 件商品的描述用了和背景同色的隐藏文字。
多渠道对账
- 起因：同一批商品同时挂在自营站、Shopify Catalog 和 Google Merchant Center。
- 做法：三处的数据各接一个采集器，以自营站的结账为基准。
- 结果：一条漂移时间线，看得出哪个渠道总是慢半拍。
不是给谁用的
- 不写代码、只想要一个分数的店主。 浏览器插件形态的工具更适合他们。
- 想盯竞争对手价格的人。 这不是比价爬虫，带写操作的探针也只对自己的店开放。
- 做代理的团队。 他们要测的是代理本身，ShopGym 这类基准更对路。
为什么先做开发者，而不是店主
店主关心的是结果，开发者才有办法把检查接进流程里。一个只在出问题后才被想起来的工具，用一次就没了；一个挂在 CI 上的工具，每次发版都会跑。所以首期的形态是命令行和 CI 动作，不是网页上的打分器。等规则和数据模型稳定了，再往上包一层给店主看的界面，是顺理成章的事。