智慧食堂 Harness：从产品设计到完整交付的五档方案

01 五档方案：覆盖范围与投入从高到低

窗口指“在资料、测试环境及关键人员可用时，完成一条有边界的试点”，不是整个智慧食堂完成时间，也不是本次代码审计后的正式排期。角色可以兼任，投入不等于新增人数；采购、渠道开通、真机等候另计。

L5：全链路交付 Harness

配置统一编排器，把 L3 的设计契约、L4 的验证证据与代码、数据库迁移、环境部署、功能开关、Word、视频、一页图连接起来。一次输入生成唯一工作项；每个阶段有可检查的入口、结果和失败恢复。

自动化重点：非生产环境自动部署，质量门禁自动运行，发布候选包自动生成；生产执行按事先授权的范围与风险策略推进。资金、权限、硬件动作及数据库变更等高风险变更保留具体版本的人审门禁。授权绑定版本、环境、租户和有效期；内容变化则重新评估。

每个阶段保存状态、输入摘要、产物校验和和重试次数，崩溃后从检查点恢复；不能整条重跑导致重复建任务、重复退款、重复发通知。治理/评分规则锁定，执行 Agent 无权修改后给自己放行。

适合目标：多项目、高频版本、跨端交付已形成稳定需求；有专人维护平台。持续成本包括 CI 计算、模型调用、设备台架、渠道联调、测试数据、证书与版本更新。

L4：业务流程验证 Harness

建立业务流程图谱、状态机、决策表和不可破坏的规则，自动生成可执行的场景与反例。每次变化定位受影响 UC、页面、API、账务与设备型号；同时保留固定交易基线，防止影响分析漏掉公共链路。

把验证分两段：开发前验证规则完整性与逻辑一致性；开发后验证实现是否符合规则。 一个新的 Agent 说“没有问题”不足以通过，需要独立来源、确定断言和真实系统证据。

适合目标：规则与异常造成返工，支付/补贴/硬件联动复杂。直接收益来自提早发现错账、状态悬挂、重复执行和人工恢复缺口；需要持续把线上缺陷变成固定回归场景。

L3：产品设计流水线

固定输入：一句话需求 + 当前项目/租户/版本 + 现有功能与流程库。自动核对现有系统，区分配置即可、已有能力缺证据、需开发三种情况。生成完整 UC、权限与页面状态、规则决策表、Before/After 可点击原型、接口差异、验收规格及云效任务草案。

原型基于已有设计组件和页面框架，可切换加载、空、失败、无权限、重复提交及恢复状态。规则变化时只更新受影响页面、测试规格和说明，不重新生成整个系统。

正式入云效时，父项正文保留完整 UC，子任务正文保留开发执行切片，CLI/API 回读核对；未决 P0 不能变成开发任务。原型中的支付、设备动作明确是模拟，不能当作联调通过。

L2：多角色需求协作包

在同一工作项内让产品分析、架构、测试、交付视角分别找问题；支付/硬件需求按需增加专业视角。角色共享冻结后的契约，由一人合并决策；没有必要让多个 Agent 同时写同一个 PRD。

交付一份“规则与流程 + 反例 + 待决策问题 + 验收规格”协作包。人选择业务规则；AI 补充证据、定位冲突、生成候选方案。按需启用角色，控制轮数、预算和重复讨论。

它能快速改善分析，但质量仍依赖审查人员和输入证据；尚未做到状态机自动验证、真机测试或受控发布。

L1：标准模板与检查清单

每条需求统一回答：谁在什么条件下触发、成功是什么、还有哪些分支、哪里可能失败、失败后如何恢复、数据如何证明正确、谁负责拍板。

模板默认展开重复请求、超时、部分成功、权限不足、断网、断电、状态过期、跨日、人工干预。对每条记录“适用/不适用及原因/待确认”，不能把空白当作不存在。

它适合立即推广作为所有档位的输入规范；检查清单填满只证明检查被记录，流程正确性仍需要 L4 的实际验证。

02 三类瓶颈如何组合解决

这五档是累计能力，建设顺序可以不同。可先用 L2 改善当前需求、用 L3 提升产出，同时把最容易返工的交易流程做成 L4；已有的 Word/视频工具可提前接入，不必等全平台完成。

03 共用底座：一份业务契约贯穿所有产物

流程资产不是菜单清单。一个“退款按钮”涉及原单、已退金额、支付渠道、补贴规则、设备履约、权限和审计，必须把这些关系放进同一份契约。

建议采用可读 Markdown + 结构化 JSON/CSV 管理下列内容，按版本冻结：

唯一追踪链：业务目标 → UC/流程步骤 → 规则/状态 → 页面/API/设备 → 验收标准 → 自动测试 → 运行证据 → 发布版本 → Word/视频/一页图。

规则发生变化，系统沿这条链标记下游内容过期。失效的测试证据和旧视频不能继续作为新版本通过依据；材料有哈希还不够，还要检查所描述的行为与实际版本相符。

04 如何让主流程、分支、异常和恢复真正可检验

先画系统地图，再逐个流程深入。当前能力资料采用三条 SPU、PC/移动/大屏/设备四端，可以复用为检索入口；105 条功能和 32 类设备/集成条目不能直接换算成测试覆盖率。

每个 UC 使用 M 主流程、A 分支、E 异常、R 恢复编号。每个外部调用/状态变化检查：成功、明确失败、超时未知、部分成功、重复、乱序、重启；再判断业务是否适用。

开发前的检查器至少应发现：没有处理分支的决策表、相互冲突的条件、不可达状态、永久悬挂的中间状态、异常缺恢复负责人、没有验收断言的 P0 规则。自动提问只呈现影响设计的未决问题，并附来源与候选方案；证据已能回答的问题自动消化。

采用风险分层控制组合爆炸：交易、权限、不可逆设备动作的指定关键组合完整覆盖；低风险配置用等价类、边界值与成对组合。报告分母是冻结版本的“适用关键步骤/规则/组合”，不是页面数、接口数或 AI 生成用例数。无法证明覆盖的部分明示缺口。

05 支付与硬件：专门建立故障实验室

支付按渠道与产品分别签订测试契约

微信、支付宝、第三方聚合渠道、一卡通分别维护适配器；JSAPI、小程序、付款码、扫码、免密/代扣等是不同接入产品，不因为同属一个品牌就假定能力一致。冻结实际商户/服务商模式、接口版本、查单/撤销/关单/退款能力、回调方式和对账口径。

内部统一表达创建支付、查询、通知、退款、退款查询与对账；不支持的能力明确标注。业务订单、支付尝试、退款单分开建模，不能给所有重试笼统换一个新单号；未知结果先查原尝试，根据渠道协议决定重试或新建。

微信官方指引要求结合回调与主动查单处理状态不明，并处理重复通知。支付宝官方异步通知说明要求验签后继续检查订单、金额、收款方和应用身份。它们支撑这里的测试方向；具体试点仍须匹配实际签约产品，不能直接套用文档里的字段到所有支付模式。微信回调与查单指引 · 支付宝异步通知说明

关键账务规则建议：同一支付尝试最多一次有效入账；本试点单笔单渠道消费，同一业务订单只能有一个有效收款结果，原尝试未知时不得开启新的可扣款尝试。若因外部竞争实际多收款，必须识别差异并由支付/对账负责人按批准规则补偿，不能隐去多余渠道流水。组合支付需要另行定义各支付分项、应收上限与竞争规则。

退款按原子约束控制“已成功退款 + 在途/未知退款占用 ≤ 可退实收”；明确失败后才按渠道协议释放占用，结果未知先查原退款单。内部账变按批准的现金/补贴规则守恒。设备流水、业务订单、内部账、渠道交易与结算账单按统一流水关联核对，手续费、优惠、跨日与结算时差须单独解释。

硬件按“协议 + 型号 + 固件 + 配置”认证

设备注册能力、支持命令、命令/流水 ID、状态、错误码、ACK 与完成回执、重试限制、本地持久化、容量、时间校准、升级兼容与人工恢复方式。模拟器必须对照厂商协议或真实样本校准。

对已授权的测试台架注入断网、延迟、重复消息、乱序、断电重启、满盘/磁盘满、传感器故障和固件混用。使用过期卡/脸/锁卡状态，检查授权信息不同步时设备如何处置。开柜、出餐、烹饪等物理动作结果未知时，先查设备或人工确认，禁止直接盲重发。

离线交易只有在相应项目规则和设备能力都确认后才启用；必须证明重启后数据仍存在、补传不重扣、冲突有处理、设备与平台可对账。微信/支付宝联机交易不能默认具有内部钱包式的离线扣款能力。

四层证据分别通过

并非每种渠道产品都有完整沙箱；缺少沙箱时记录缺口，安排获授权的小额联调。模拟器通过时显示“模拟通过”，真机未跑显示“待真机”，不合并成一个绿色总分。

06 从一句话到发布与材料：阶段门禁

一句话 + 项目上下文
  → 查现有能力、来源与历史问题
  → UC + 规则表 + 状态机 + 多端原型
  → 开发前完整性检查 + 关键业务决策
  → 冻结契约、写入云效并回读
  → 按可验收纵向流程拆任务、隔离实现
  → 单元/契约/集成/E2E/真渠道/真机验证
  → 构建不可变发布候选包 + 自动生成材料草稿
  → 发布审查、授权 → 部署 → 灰度开启功能
  → 目标版本回验、核账、材料定稿 → 功能发布
  → 观察、停用/恢复 → 缺陷回流流程库

部署成功与功能发布分开：代码可以先落到环境，开关决定谁可用。停用新入口不能停止在途交易、回调、退款与对账。回退代码不能撤销已发生的付款/出餐，也不能盲目反向执行数据库迁移；资金和物理结果走已定义的补偿/人工恢复。

阶段状态建议：DRAFT / BLOCKED / READY / RUNNING / FAILED / PASSED / APPROVAL_REQUIRED / DEPLOYED / RELEASED / OBSERVING / CLOSED。编排器检查证据后迁移，模型输出“PASS”不会直接改变发布状态。

用户材料由已验收的同一流程生成

原始自动测试录像包含重试、断言和异常噪声，通常不宜直接作为用户教学视频。先做材料草稿，版本/界面稳定后复验；代码或规则改变使对应内容过期。缺 TTS、真机录像、模板或逐页验收时，材料状态单独阻塞。

07 现有资产如何接入

这些判断来自指定控制资产的静态核查，不能推断所有业务仓库都没有测试。现有开发工具和质量门禁应作为底座扩展，避免再建一套平行 PRD、任务库和素材库。

08 试点 Use Case 与拆解建议

以下为带阻塞项的试点 UC 骨架，不能直接充当完整开发 UC。正式开发前必须补齐逐步状态转换、规则编号、AC 与测试映射，并关闭下列 P0 决策。

Use Case ID：UC-HARNESS-001｜将一句话需求转换为可验收交付

• 角色与边界：需求发起人、产品决策人、研发、独立测试、硬件/支付负责人、发布负责人。Agent 只在授权的项目、租户、版本和环境内执行。
• 触发：收到带目标的一句话需求；项目上下文缺失则先解析候选，不猜目标环境。
• 前置：来源/系统基线可读，工具权限清楚，已有能力与规则有负责人。
• 成功后置：本次选择档位对应的产物和证据齐全；L5 另要求实际发布与材料交付、观察达标。
• 失败后置：保留当前状态、失败证据、已发生副作用和下一步；不能报告全链路完成。
• M01–M06：检索现状→生成并审查 UC/原型→冻结契约/云效回读→依赖拆解/实现→分层验证→版本发布及材料/观测。
• A01：需求可配置实现，跳过代码变更但保留配置审查与回归。A02：只选 L2/L3，终点是经审查分析/设计包，绝不宣称已上线。
• E01/R01：P0 缺失或冲突→BLOCKED→责任人裁决→新版本契约与下游重验。
• E02/R02：工具/网络/运行器失败→保留检查点→限次重试；超预算交接，不重复执行资金/外部动作。
• E03/R03：测试失败或真机缺位→按失败层归因→修复或补证→重跑受影响套件与交易基线。
• E04/R04：发布或观察失败→暂停放量→按已批准预案处理新入口、在途单和迁移；人工处理不可逆结果。
• 规则：唯一工作项与契约版本；测试预期/评分规则由独立角色冻结；流程证据不得伪造、跳过或用摘要替代。
• 页面/API/数据：本次仅提出工作台、只读证据与运行控制的逻辑契约；真实路由/API/schema/权限需在实施时冻结，未指定现有接口名称。
• 验收：五档边界明确；关键步骤可追踪；已知坏契约被拦截；好契约仍须经真实执行才可晋级；过期证据不能放行；中断续跑不重复副作用。
• 自动化测试：schema 与决策表检查、好/坏契约对照、评估规则篡改负例、并发领取/重入/中断恢复、跨租户拒绝、证据失效与发布状态迁移拒绝。
• 性能/安全：队列容量、阶段超时、模型预算、数据留存与权限矩阵需量化；禁止把凭据、未脱敏人脸/手机号/生产 payload 写入共享证据。
• DoR: BLOCKED（实施）；待确认试点项目/版本、规则负责人、可用测试环境与权限、阈值及发布范围。本次方案评审不等于开发准入；尚未创建/更新云效事项。

建议第一条业务试点：UC-PAY-001｜消费机单笔消费与异常恢复

选择一个已有消费场景、一个测试租户、一种设备型号及固件、一个已开通支付产品。先跑“发起消费→支付结果确定→履约确认→订单/账务核对”，再扩退款和离线适用分支；哪一个项目更合适由可用证据和台架决定。

不默认把支付、称重绑盘、咖啡机、炒菜机器人放进同一首轮闭环。跨渠道复用的是统一测试契约，不是未经验证的成功结论。

• 主要角色：就餐者、操作员、支付服务、消费机、对账人员；严格绑定租户和商户。
• 前置与触发：用户发起一笔单渠道消费；身份、应收、交易号与设备配置已确定。
• 成功后置：业务订单、支付结果、内部账及可验证履约一致；账单到期后完成渠道核对。
• 失败后置：能说明资金与履约是否已发生，未知状态可查询与处理，留审计记录。

页面状态：待操作、处理中、成功、明确失败、结果待核实、权限拒绝、重复操作提示、人工处理中。API/表名以实际代码定位后冻结，此处均为逻辑契约；每条测试当前状态均为“未执行”。

规则待决策：扣费/履约先后；支付未知多久升级人工；已扣未出餐处理；离线准入/额度/时长；现金/补贴退款分摊；日切/对账时限；旧版本兼容范围。负责人岗位分别为产品、支付、硬件、财务/运营、发布负责人，具体人员与日期待确定。

性能基线需冻结峰值每秒交易数、设备数、数据量、持续时间、p95 延迟、未知单收敛时限与离线恢复时限；这里不编造通用合格值。安全测试至少包含租户/商户隔离、重复调用、回调验签、操作权限和敏感信息脱敏。DoR: BLOCKED，规则与实际契约补齐后才开发。

任务按可验收纵向切片拆分

共享 API、DB、权限、状态语义先冻结再并行。控制资产留在 zhctprompt，业务实现留在各业务仓库；H5、API、PC、设备按现有仓库清单定位。Ruflo 可登记协调，真实执行与测试回执仍由 Codex/运行器提供。

09 建议推进节奏与投入判断

第 1—2 天：全团队用 L1，选一个需求跑 L2。 从最近返工和真实故障反推问题库，确定首条试点及规则负责人，测量现有用时和返工。

第 1—2 周：主攻 L3，加上 L4 的设计检查部分。 输出真实系统对照、UC、规则表、状态机、异常可点击原型、测试规格、任务切片。两周目标是证明设计门禁有效，不承诺完成全部支付/真机/自动上线。

第 3—6 周：形成首条 L4 可执行闭环。 完成模拟器、真实后端/终端测试、约定的渠道与真机证据。将实际发现的设计缺陷加入固定回归，不追求一次覆盖全部型号。

随后按场景扩展 L5。 每次增加一个渠道/机型/业务流程，复用发布清单、灰度、观察、Word/视频与一页图生成器。8—12 周以上只是一个受控范围的试点窗口，完整系统建设仍需按实际存量、接口与设备差异重新排期。

建议设一名产品规则负责人、一名 harness 工程负责人、一名独立测试负责人，支付/硬件/发布/交付按切片参与。产品经理主要决定规则与取舍，AI 负责检索、展开、检查、生成、执行和追踪；不要把新的所有确认事项再次集中给一个人。

10 验收提速效果，不用文档数量衡量

候选检查器还应做已知好/坏案例验收：遗漏“超时已扣”、删掉断电恢复、篡改测试预期、用旧固件证据覆盖新固件、用旧视频覆盖新页面时必须被拦截。合法契约可进入测试，但不能跳过真机/发布门禁。无法判定的输入应报告待复核。

推荐落点：全团队今天采用 L1 + L2，产品骨干建设 L3，测试与研发共同建设 L4，再把稳定流程逐条接入 L5。 这样每档都产生独立价值，又能逐步达到“一句话触发完整交付”的目标。