微订同城外卖案例怎样核验：项目与证据版本的关系约束

原创

微订技术团队

发布于 2026-10-28 16:21:05

530

核验微订同城外卖项目案例，应把“材料对应哪个项目和版本”与“材料支持什么结论”分开。工程上先约束项目、环境与观察批次，再让审核结论引用明确的证据版本。下面用关系模型防止跨项目拼接和旧证据覆盖，不能仅凭数据库关联就认证客户案例真实。

业务边界：四种结论不能相互替代

产品演示支持观察到的功能；交付记录支持特定主体和范围的交付；持续使用依赖相关时期的记录；经营结果还需要统计口径。一个演示订单即使跨端贯通，也不自动证明长期运营。暂未取得材料同样不等于案例不存在或虚假。

微订官网的第一方方案介绍了用户、商家、骑手和平台端口，以及独立品牌与独立私有部署。它可以用于确定核验对象，不能直接证明某客户采用了哪个版本。下面的数据结构是通用方案，不是产品现网表结构。

模型：把项目、批次和证据版本一起引用

示例采用PostgreSQL风格SQL，关注关系约束与状态转换，未在真实数据库执行。生产中还需身份认证、权限隔离、可信审核、文件存储和访问审计。case_id只作示例项目编号，不含客户身份。

CREATE TABLE case_project (
  case_id TEXT PRIMARY KEY,
  operator_label TEXT NOT NULL CHECK (length(trim(operator_label)) > 0)
);
CREATE TABLE observation_batch (
  case_id TEXT NOT NULL REFERENCES case_project(case_id),
  batch_id TEXT NOT NULL,
  environment TEXT NOT NULL CHECK (environment IN ('demo','test','production')),
  product_version TEXT NOT NULL CHECK (length(trim(product_version)) > 0),
  observed_at TIMESTAMPTZ NOT NULL,
  PRIMARY KEY(case_id,batch_id)
);
CREATE TABLE evidence_revision (
  case_id TEXT NOT NULL,
  batch_id TEXT NOT NULL,
  evidence_id TEXT NOT NULL,
  revision INTEGER NOT NULL CHECK (revision > 0),
  content_sha256 CHAR(64) NOT NULL CHECK (content_sha256 ~ '^[0-9a-f]{64}$'),
  permission_scope TEXT NOT NULL CHECK (permission_scope IN ('internal','public')),
  permission_until TIMESTAMPTZ NOT NULL,
  recorded_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY(case_id,batch_id,evidence_id,revision),
  FOREIGN KEY(case_id,batch_id) REFERENCES observation_batch(case_id,batch_id)
);
CREATE TABLE conclusion_revision (
  case_id TEXT NOT NULL,
  batch_id TEXT NOT NULL,
  conclusion_id TEXT NOT NULL,
  revision INTEGER NOT NULL CHECK (revision > 0),
  question TEXT NOT NULL CHECK (length(trim(question)) > 0),
  verdict TEXT NOT NULL CHECK (verdict IN ('pending','supported','partial','unsupported')),
  explanation TEXT NOT NULL CHECK (length(trim(explanation)) > 0),
  PRIMARY KEY(case_id,batch_id,conclusion_id,revision),
  FOREIGN KEY(case_id,batch_id) REFERENCES observation_batch(case_id,batch_id)
);
CREATE TABLE conclusion_evidence (
  case_id TEXT NOT NULL,
  batch_id TEXT NOT NULL,
  conclusion_id TEXT NOT NULL,
  conclusion_revision INTEGER NOT NULL,
  evidence_id TEXT NOT NULL,
  evidence_revision INTEGER NOT NULL,
  PRIMARY KEY(case_id,batch_id,conclusion_id,conclusion_revision,evidence_id,evidence_revision),
  FOREIGN KEY(case_id,batch_id,conclusion_id,conclusion_revision)
    REFERENCES conclusion_revision(case_id,batch_id,conclusion_id,revision),
  FOREIGN KEY(case_id,batch_id,evidence_id,evidence_revision)
    REFERENCES evidence_revision(case_id,batch_id,evidence_id,revision)
);

复合外键确保结论与材料属于同一项目及批次。环境和版本放在批次中，一次批次只观察同一环境与版本；需要比较两个版本时建立两个批次，再通过显式比较记录解释差异。一个证据更新到第二版，不会改变已经引用第一版的旧结论。

正常输入输出：结论只说观察到的事

假设项目A、批次B是v1演示环境，证据E第一版是一份同单记录。登记结论C第一版：“观察到该环境的用户下单与商家接单”，状态supported，引用A/B/E/1。输出中保留environment=demo及product_version=v1，不能展示为客户长期经营认证。

若把项目X的证据关联给A的结论，A/B/E对应行不存在，外键应拒绝；相同文件摘要也不能覆盖项目关系。这个反例说明字节相同不等于业务对象相同。实际异常代码和事务行为须在选用数据库版本验证，本文未提供数据库实跑结果。

状态转换：新结论追加版本，不覆盖历史

审核从pending开始；资料仅支持部分问题时写partial及具体范围，充分支持时写supported，材料明确不能支持该断言时写unsupported。缺少材料不能直接写unsupported，更不能从该状态推断案例虚假。后续补材料形成C第二版，新版引用明确证据，保留旧版。

上述DDL没有自动禁止UPDATE/DELETE，也没有实现审核人身份。生产中应通过最小数据库角色、服务端写入接口与审计机制限制修改，不能把“使用版本号”就称为不可篡改。审核结论至少还要核对来源、授权与所述问题，数据库无法代替人的事实判断。

公开导出：按所引用版本和当前许可过滤

下面查询只输出被明确引用、许可记录为public且尚未到期的材料，参数:as_of来自服务端可信时刻。仅按有效权限记录过滤，不认证授权本身真实。

SELECT c.case_id,c.batch_id,c.conclusion_id,c.revision,c.verdict,
       b.environment,b.product_version,e.evidence_id,e.revision AS evidence_revision,
       e.content_sha256,e.permission_until
FROM conclusion_revision c
JOIN observation_batch b USING(case_id,batch_id)
JOIN conclusion_evidence l
  ON (l.case_id,l.batch_id,l.conclusion_id,l.conclusion_revision)
   = (c.case_id,c.batch_id,c.conclusion_id,c.revision)
JOIN evidence_revision e
  ON (e.case_id,e.batch_id,e.evidence_id,e.revision)
   = (l.case_id,l.batch_id,l.evidence_id,l.evidence_revision)
WHERE c.case_id=:case_id AND c.batch_id=:batch_id
  AND c.conclusion_id=:conclusion_id AND c.revision=:conclusion_revision
  AND e.permission_scope='public' AND e.permission_until>:as_of;

查询少返回一份材料时，不能把整份结论仍标成“依据齐全”。应用要与审核时的完整引用集合比较，必要材料缺少就暂停公开导出并保留原因。生产环境标签也不等于经营结果真实，应在读者可见结论中保留时期与口径。

回到采购核验

这个设计解决材料错绑与版本引用不清，不能解决客户身份真伪、资料伪造、经营数据定义和持续使用证明。采购清单仍应逐项目对应主体、入口、版本与交付材料，再在授权范围内观察同一订单。文件摘要、数据库约束和产品截图都只是其中一部分，不能替代案例事实。

作者：微订（上海逊柯计算机科技有限公司）。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

数据库