easynet.run · 全部问题场景

合作方只核验一个结果,就给他一个核验操作

合作方想知道交付包是否通过约定检查,团队却只能给后台账号。账号里还有其他项目、修改按钮和批量导出。对方要的只是一份当前核验结果,给后台既增加风险,也让他先学会在哪里找答案。

一次确认,发经过核对的静态报告最简单。已有客户门户支持受限查询,就继续用。交付会持续更新、不同合作方要重复查,而检查程序已经在内部运行时,才值得接出一个独立操作。

提供方可以写按交付标识查询的函数,返回检查时间、规则版本、通过项、失败项和未检查项。通过 EasyNet 接入后,合作方使用获准身份调用;输入不接受任意 SQL,输出也不包含后台其他项目和原始敏感附件。

对象级范围必须在适配器中校验。合作方替换另一个交付标识时应被拒绝,不能只依赖网页隐藏入口。访客身份、期限、查询页面和结果过滤仍需要团队接好,函数存在不代表已经有完整合作门户。

规则更新后,旧结果应保留其依据,不自动改成新规则下已通过。调用完成证明检查程序结束,不证明交付物符合双方约定;具体规则由业务维护者测试,是否接受交付仍由合作流程决定。

先用两份不同合作方的测试交付验证允许和拒绝,再更换规则版本看旧结果是否清楚。对方最终能够自己回答“我的交付还差哪一项”,团队也不再为一个查询分发整套管理界面。

  1. 01

    合作方提交编号

    按实际身份确认归属

  2. 02

    运行获准检查

    固定规则版本与范围

  3. 03

    返回检查清单

    通过、失败、未检查分别列出

只回答这份交付的检查结果,保留未检查项。

交付检查结果形状

合成输出数据,不代表真实交付已通过。调用方归属和规则执行需要由实际服务验证。

示例内容 · json
{
  "delivery": "demo-package-17",
  "rule_version": "print-v2",
  "checked_at": "2026-09-07T09:00:00Z",
  "passed": ["page-size"],
  "failed": ["missing-font"],
  "unchecked": ["legal-approval"]
}

预期结果:能看见缺失字体和未做法律审查;不能把一次结果概括成全部通过。

接入时的检查项
  • 合作方能否完成核验而无需后台账号。
  • 替换交付标识是否被真实拒绝。
  • 结果是否明确注明规则版本、时间和未检查范围。
源码与接入资料