小程序运营支撑与后台人工兜底审查

日期：2026-09-29。性质：用户委托的当前设计审查，非 S5 独立评审、S7 全量验证或发布验收。Runtime inactive，无 bound REQ。

结论：当前后台尚不能完整支撑小程序运营。 它已经有较完整的领域入口及局部操作，但“发现异常 → 找到同一客户和业务对象 → 合法代办 → 分项执行 → 回源核验 → 用户可见结果”的服务闭环仍有实质缺口。不能用82个工作区、206个按钮或上一版984条局部检查，证明这些闭环已完成。

当前视觉按用户意见暂定；本轮不改视觉、业务模型、政策或原型行为。主会话维护缺口及设计修订，业务政策由用户决定；表中的Owner是职责建议，真实运营、资金、履约、质量及技术负责人尚待指定，不能把领域名称当已到岗人员。

1. 审查依据与有限覆盖

1.1 本轮实际检查

• 全量提取当前 catalog.json 的82个工作区、206个动作、30个创建入口，核对字段、前后状态、角色复核、对象关联及无后续动作的候选状态。
• 阅读共用 app.js、完整 model.js，重点检查跨模块执行、原请求核验、新建对象、授权与可见结果。
• 回看小程序活动构建入口、周计划/逐日确认模型、“我的”及基础订单/结算/地址/售后源码；浏览器打开4304当前小程序首页。
• 对照一周无忧、付款后陪伴、配送费、品牌经营立场、事实Owner，以及9月29日新增交易不变量/六机职责。旧报告只作问题索引，没有直接沿用旧“缺少架构设计”的结论。
• 执行10组内存级合成反例，并用4项对照确认只读、超额退款、不齐回执和非法选项的已有拦截；独立浏览器实际走“订单列表 → 陈先生订单 → 取消 → 核对 → 无后续动作”，查看客户详情。没有改用户已有浏览器记录，没有发起真实资金/外部动作。
• 形成下方36条服务结果盘点及82页附录。不是逐页执行82页所有分支，也未跑全量回归、真实支付、真实设备、微信真机或多端后端联调。

证据：定向探针与全目录提取、可复现探针、浏览器观察、输入指纹。探针只证明当前原型行为，不能上升为生产事故结论。

1.2 权威及成熟度

新架构已经补上许多旧报告指出的对象和协议，当前问题主要是它们尚未落入后台办理设计和两端共同场景。后续若否决某候选政策，应调整对应提案；已明确的主动授权、资金真实性和终态约束不能因此退回人工改状态。

2. 完整支撑的判定标准

一条运营服务必须同时回答七个问题，才能记为“可完整办理”：

1. 发现：用户求助或系统异常怎样进入队列？是否有等待时间与未接手提示？
2. 定位：是哪位客户、哪次购买、哪些餐次/订单行、哪个配送尝试、哪笔原款？
3. 授权：谁提出、谁代办、授权何时取得、允许改哪部分、金额及有效期是什么？
4. 判断：当前真实进展及可办范围是什么？拒绝时能说明原因与替代方案吗？
5. 执行：调用明确业务动作，显示责任方、步骤、部分成功及失败后的去向。
6. 核验：回源取得支付、停止、交付等证据；查不到保持未知，不能人工宣称成功。
7. 交代：工作人员与用户看到同一结果，未完成事项仍有责任人、期限和继续入口。

仅有查询、文字备注、通用证据框、跳到另一个模块列表，最多记“部分”。缺政策记“待决”，不能记“完整”或悄悄默认允许。正常自动流程不应依赖员工每天逐条点击。

3. 主要发现（按业务风险排序）

P1：在相应运营闭环成为可交付设计前必须补齐。P2：配套经营能力或范围待决；若首发仍展示相应承诺，也必须先补齐或明确收窄。以下均为设计/原型问题，无生产P0判断。

G01 · P1 · 缺少按客户、购买批次和餐次贯通的服务视图

• 证据：customers详情只有联系方式等4项摘要，样例 links={}；浏览器显示“暂无已核验的对象关联”，下方跳的是全量模块列表。顶部搜索只查功能标题/描述。订单部分样例虽有精确链接，仍无同客户聚合。
• 小程序 study-mine.tsx:39明确新周计划与旧订单/售后两套记录未合并；study-week-model.mjs与后台使用不同本地数据。单凭“未接后端”不判原型失败，但共同业务对象及用户回看路径必须先设计。
• 后果：用户说“这周少送一餐，钱在哪里”，客服必须人工拼姓名/日期，不能可靠定位金额及后续；跨端办理后的可见结果无证据。
• 补齐：客户服务台按受权标识检索，串联购买批次→餐次→旧/新单→授权→执行→原款/退款→服务事项；保留每域来源时点及局部不可用。两端共用一组可追踪场景数据，不要求原型接真实后台。
• 完成反证：同名客户、一天多餐、多地址、部分投影延迟仍能定位准确；查不到不能显示未支付并催付。Owner：Customer组合视图，Commerce/Demand/Fulfillment提供事实。

G02 · P1 · “协助客户”尚未形成明确的受托办理机制

• 证据：plans只有服务备注，personal-cards只有问题记录与关闭；addresses只有更正文本及证据。orders.change、confirmations.accepted把客户依据作为文本，没有代理主体、授权范围、有效期、内容版本及客户核对回路。
• 缺失故事：用户不熟悉操作、账号暂不可用、设备损坏、临时由客服帮改地址/改时间/提交补救。登记备注不能完成这些请求。
• 补齐：明确“代填草稿→客户核对并授权→受控提交→双方回执”；不能操作小程序的特殊用户另设计身份核验与获准的替代授权方式。是否接受电话/其他渠道授权须业务定案，本轮不认定录音或工作人员说明自动有效。
• 边界：允许协助不等于默认确认、代扣款或改过去的授权时间；不能假扮客户登录。原确认的核验与新取得的受托授权要分开。Owner：Customer服务、Demand授权接受、Commerce变更，Identity保护动作权限。

G03 · P1 · 取消/改址/改期可能走入“待人工处置”，但没有办理出口

• 证据：orders.cancel/change → …处理中 → check → 待人工处置无出边。P01及浏览器B01复现；没有新增协调事项，changes条数保持3，原配送状态也未改变。其不直接改配送是正确的Owner边界，但必须创建/关联实际协调请求。
• changes.recover → 恢复处理中同样没有继续动作；已有原始样例并不能承接新请求。
• 补齐：从订单发起结构化变更，选择受影响行/日期及目标地址/时刻，预览可停止性和影响；建立唯一协调编号，逐步显示停止、承诺、授权、资金回执。拒绝/失败保留真实现状和下一步，不能把“已登记”当办理完成。
• 完成反证：取消一餐不改其他日；开工先成功走受控处置；关闭旧单后不能复活。Owner：Commerce协调，Demand/Fulfillment回执。

G04 · P1 · 换菜/改量缺少前驱—后继订单和差价流程

• 证据：substitutions已有提案、客户决定、价差和结果动作，是可复用基础；但“替代商品与规格”是自由文本，未选订单行/数量，无冻结/永久停止、后继订单、原款分配、补款、便宜差额、失败补偿及新授权。orders无创建入口，通用执行也不生成后继对象。
• 补齐：沿同一餐次展示完整替换案件；旧单永久终止后建立关联新单，明确原款何部分可用，差价和费用分列；新授权对应新内容。价格/份量和允许阶段待政策定案。
• 完成反证：原款已被退款预留时不能承诺仅补差；补款成功新单失败不能复活旧单；开工事实未知不能重新切一份。Owner：Commerce，协作Demand/Fulfillment/Supply。

G05 · P1 · “本次不送后恢复”沿用原ID，与新终态设计冲突

• 证据：P02：CONFIRMATIONS-003由“本次不送”变“待客户确认”，没有新的安排身份。study-care-flow.mjs:10也接受skipped原记录，当天直接变delivering。
• 判断限定：不是说任何暂停对象都不能恢复；问题是本次到期决定、原订单是否终态没有区分。新架构要求到期安排不可复活，原型这条路径无法解释新旧身份和执行资格。
• 补齐：保留旧结果；“重新安排”建立新尝试，按原订单是否终态及资金状态确定是否关联新单，再取得本次授权。界面不要求客户理解多个内部对象，后台要能查清谱系。
• 完成反证：旧确认/付款事件晚到不重新执行；原款退款未知不能再占用。Owner：Demand/Commerce/Fulfillment。

G06 · P1 · 收退款核验被简化为人工填写成功，UNKNOWN没有完整出口

• 证据：model.js:70的resolvePending只要非空证据便迁移到原目标状态；无“仍未知、核实失败、金额/对象不符、相反证据”结果。P05：尚无外部流水的待收款记录可凭文本变“已验证”；P06复现UNKNOWN单一路径。
• 可保留：原请求ID、退款整数分额度、未知保留占用、独立复核已有局部设计。
• 补齐：展示原目标、渠道/尝试、核验结果和可信回执；“查询”不等于“确认成功”。确定失败后的合法重试/释放、仍未知的下次查证及升级、终态相反证据另立差异。原型也应有这些分支，不只写“以后接API”。
• 完成反证：重复回调、断网、迟到成功、员工撤权均不能重复收退；成功与来源摘要矛盾必须可见。Owner：Commerce资金及受限恢复服务。

G07 · P1 · 留存、购买批次结算、自动退差和退出办理未闭合

• 证据：retained止于“退出待评审”（P08）；82页目录未见PurchaseBatch、资金切片/分配、结算运行、结算更正工作区或对应详情。reconciliation是账单匹配，不等于批次结算；Finance总账也不能替代运营资金账。
• 补齐：按原交易列实收、占用、实际消费、待结算、退款预留、实退及限制；自动结算任务可追踪，正常结果自动推进，异常接手。整周/部分退出受理后有裁决、执行、回执及用户结果。
• 政策待决：批次结束、称重/优惠/配送费分摊、自动退款时点、无争议部分先退、原路失败替代路线。最新架构的自动退费是拟议方向，不能写成已批准随时退款或已实现钱包。
• 完成反证：结算与换菜竞争、部分未知、结清后晚到事实，不能双退或重开已关闭批次。Owner：Commerce资金；Finance消费经济事实。

G08 · P1 · 每日确认与费用承接缺少同一次请求的完整办理链

• 证据：accepted只输入同意、期望时刻和回执选项，未绑定安排版本/地址/具体行数量/费用目标；tariffs止于“待业务确认”，无政策生效/失效与报价溯源。试算函数fee()只接受时分，跨日返回负提前量（P10）。
• 草稿¥3改¥5后正式试算不变，本身不是缺陷（草稿本就不应立即生效）；缺口是没有受审生效版本供正式报价引用，也没有独立提案试算说明。不可用“改了参数”证明两端已一致。
• 补齐：客户选择→版本化报价→授权/费用核验→服务接受→执行资格，逐项可查；收费成功而确认失败、跨档、时区/跨日、商家延迟和改时的恢复或补偿路径。
• 完成反证：两小时边界不是关单；选中时间/费用已付不等于已接受；当前不应由经办人填写“齐全”越过门禁。Owner：Demand/Commerce。

G09 · P1 · 缺少以经营结果为中心的监控和自动流程兜底

• 证据：monitor主要是服务/队列3条样例；首页是静态日期和按样例状态计数。jobs只有配置、启用、暂停；confirmations.skip是人工动作。没有未确认到期补扫、确认已接受却未派生任务、结算超时、无人接手、原款UNKNOWN年龄等业务队列。
• 补齐：正常到期/结算由系统执行；后台按“风险/超时/金额/负责人/日期”归集异常，显示最后成功水位、影响对象、自动恢复尝试和下一步。任务技术成功后回查业务结果。
• 边界：待确认但未到期是正常业务，不全部报警；客户拒绝提醒不应被持续催促。监控阈值和接手时限须指定，不在本审查随意设数字。
• 完成反证：客户没打开应用、调度宕机重启、重复补扫、只部分成功都能发现并恢复。Owner：各业务Owner，Platform提供调度/工作索引。

G10 · P1 · 作业、质量和停止依据仍可用自选字段代替权威门禁

• 证据：guard('gates')只检查表单是否选择“依赖已齐全”。P03：质量隔离任务改派后选齐全即进入执行，质量源没有变化。packages.seal同样依赖自选门禁。
• 补齐：现场工作台只读展示当前授权、质量/物料、依赖、执行范围与停止结果；经办人发起核验，不自己宣告它们成立。给质量隔离、开工未知、停止在途、部分已切配独立处置入口和证据。
• 完成反证：隔离不能靠改派解除；离线旧任务/旧标签不能开工；现场发生但回执丢失先查实物不重做。Owner：Fulfillment执行，Supply质量与物料。

G11 · P1 · 售后/补送/回收有方案，却缺实际派生与分项办理

• 证据：aftersales有方案、复核、关闭，这是基础；但批准不产生关联退款、补送新单或回收任务。refunds无创建入口；returns只对种子记录派发/接收。P09可选“全部回执齐全”关闭售后而关联源未核验。
• 补齐：按订单行/数量选择少件、品质、重量、切法、配送问题；生成独立退款/补送/回收目标并逐项跟进，必要检验/处置不丢失。客户可见方案与实际执行分别表示。
• 完成反证：一个包裹少一件不能整单重送；重复售后不双退款；退款完成通知失败仅重投通知；已完成原单不复活。Owner：Commerce售后，Fulfillment/Supply执行。

G12 · P1 · 异常与交接能“关单”，不代表源业务已恢复

• 证据：P04异常“退款查询超时”能关闭，REFUNDS-002仍未知；handoffs.close只收文本证据。service-cases.close明确是“沟通已完成”，但无同时突出“业务仍待办”的统一服务汇总。
• 补齐：工作事项与源事实分别收尾；只沟通完成不能撤掉退款恢复责任。每个案件有当前个人/岗位责任、下次动作、期限、交接接收、升级和关闭依据；源未恢复则保持待办或明确转出到接收者。
• 完成反证：员工离职/轮班、无接收人、回执不全、查证仍未知时不丢案；通用异常台只能调用受控恢复动作。Owner：Platform工作索引，源领域决定完成。

G13 · P1 · 新建记录及种子关系不足以支持真实联办

• 证据：perform新建时links={}且摘要全“待核对”。P07新增售后选择了ORDERS-002，但仅保存在fields，没有关联导航/摘要。detail()以id.split('-')[0]推导页面，带连字符的SERVICE-CASES-*、PERSONAL-CARDS-*等类型不适用，不能作为统一引用协议。
• 样例反证：REFUNDS-001标题/显示原交易是排骨取消及PAY-…03，却链接PAYMENTS-001（林女士¥186）；额度初始化又为¥92。PACKAGES-001说任务已验收，但链接TASKS-002仍执行中。周女士客户范围城北而订单/留存样例城南，缺少解释跨范围协作的依据。
• 补齐：使用显式对象类型、稳定ID、范围及关联来源；新建时建立合法引用与摘要，检查权限，客户/原款/物料/金额可追踪。合成数据也要内部自洽，跨范围共享需显式规则。
• 完成反证：从新建案件而非预制样例开始，能完整走到退款/补送与客户回看；不能靠手抄编号。Owner：主设计会话维护样例，各事实Owner定义引用。

G14 · P1 · “按需备货、不留隔夜、明日鲜讯”缺少经营支撑链

• 证据：当前小程序首页实际显示“明早7:30到店”“按需备货，不留隔夜”。content只编辑标题/文案，receiving从实际接收开始；supply-capacity只发布能力。目录没有分日期/部位/切法的需求汇总与备货计划、预计到货→实际异常→鲜讯更正、日末剩余处置的明确办理链。
• 补齐：分开草稿意向、已付未确认、已确认需求，生成可解释备货建议并人工承接；关联预计/实际供给、到货短缺/隔离、替代或告知。鲜讯有业务日、依据、有效期、撤回/更正及受影响客户；剩余处置有证据。
• 边界：采购准备不授权订单级切配；不要求先建设完整采购/WMS；具体隔夜/损耗政策需运营定案，不凭文案制定食品安全标准。
• 完成反证：大量不确认、临近新增、到货延误、临时下架时，承诺与顾客页面都能更新。Owner：Supply经营准备，Demand需求，Catalog发布。

G15 · P2 · 商品规格、个人菜卡与推荐能力的支持粒度不足

• 证据：products单组克重/切法，recipes单SKU映射；当前菜卡模型支持多关联商品和文字备忘。personal-cards只登记问题，缺SKU失效/规格变化对未付餐次与已付快照的不同处理。家庭偏好/下周建议/收藏/积分部分仍是基础源演示。
• 补齐：合法规格组合、份数/人数、多SKU映射、商品停售影响名单、替代建议与客户接受；保留私有菜卡和已付快照。工作人员协助修复要限定范围，不擅改客户全部菜卡。
• 范围待决：积分兑换、推荐规则、增长与团长佣金Owner/首发承诺；已有优惠权益不等于积分账本，持续服务合同不等于免费建议开关。
• 完成反证：备忘“少盐”不变采购项，改模板不修改已付明细，下架历史仍可查。Owner：Catalog/Customer，增长决策待定。

G16 · P1 · 提醒和外呼缺少授权、直达与失败后接手闭环

• 证据：confirmations.remind只修改原记录并记事件，不产生通知目标；notifications.send可从待发送直接到“已送达”，无已受理/已送达/无法确认区别；通知创建只有主题、对象文本和原因。
• 补齐：按有效用途/渠道同意发送，绑定安排ID和版本；旧链接查最新事实；成功确认后停止旧提醒，退订不影响服务。失败可进入合法人工联系队列并记录结果/拒绝联系。
• 完成反证：推送失败或未读不能转为同意、不能影响到期停送；退款成功而消息失败不得重退。真实微信通知能力待外部专项验证，本轮未宣称可接入。Owner：业务意图Owner + Customer授权 + Platform投递。

G17 · P1 · 配送异常、部分交付、追溯与回收处置仍不完整

• 证据：deliveries只有出发/送达/异常/同记录再次安排；无逐包裹部分签收、拒收、失联、错送、终止尝试后新尝试的明确设计。packages交接后无接收动作；“绑定受阻”无本页恢复动作，异常回执也不推进原包裹。回收“已接收”后缺质量判定/报损/物料处置路径。
• 补齐：异常类型驱动可办方案和客户决定；保存每次尝试、实际交付数量、未交部分去向、费用责任与证明；扫描/补打标签不算交付。追溯缺失/撤回与召回需按影响对象逐一处置、核验下游，不只写总数。
• 完成反证：一单多包、部分送达、派送员失联、客户否认收货、批次隔离、返回物料不可再用，均不重置实际事实或重复派送。Owner：Fulfillment/Supply/Commerce售后。

G18 · P1 · 岗位、边界权限、双人复核与审计尚不能支撑真实代办

• 证据：所有动作主要检查operator/reviewer/readonly，非业务角色矩阵；复核以role字符串比较作者而非员工身份。跨域相关对象没有逐一权限/存在性核验；新增记录默认城南。events主要记录接受动作，不具备完整拒绝原因、原客户/代办人、前后快照、政策版本与核验来源。
• 补齐：客服、经营、履约、质量、资金经办/复核、系统运维、只读审计按动作/对象范围授权；金额及高风险决策职责分离，紧急授权有范围/期限/审批。离职撤权不遗弃原义务，恢复用受限主体。
• 完成反证：只读、错区域、同人不同岗位、撤权后的旧窗口、管理员调用、批量部分失败均受同一门禁；无万能改状态。Owner：Identity及各业务Owner。

4. 服务结果覆盖矩阵（36项有限库存）

“部分”表示已有可复用界面/动作，但存在结果级缺口；“缺闭环”表示当前不能从入口办到目标；“冲突”表示与当前明确原则/候选新约束需对齐；“待决”表示范围/政策仍须选择。没有把技术未接入本身等同所有设计失败。

5. 人工代办边界：能帮助，不代替客户做决定

每次代办建议最小记录：客户与原发起者、实际经办人、代办原因、身份核验引用、授权方式/范围/版本/时效、原对象与目标、影响预览、必要复核、原请求与执行回执、客户可见说明。敏感证据采用受限引用，不能直接铺在通用日志里。具体字段与保存期限后续收敛，不在此冻结接口。

6. 建议的后台补齐方式

保留十个业务上下文及当前视觉；在其上增加按业务事项办理的组合入口，避免让客服理解全部菜单才能完成服务。

1. 客户服务台：按客户/订单/餐次/流水/服务编号定位 → 展示同一事实链 → 可办动作、授权及影响 → 案件进展 → 用户回看。
2. 今日运营与异常队列：正常待确认与异常分开；到期未处理、已确认未安排、变更冻结、资金未知、配送受阻、结算未完成按责任和年龄排序。
3. 变更办理详情：旧/新内容、原单/后继、停止、差价、授权、执行门禁和补偿逐项显示；每个未完成步骤有办理入口与责任。
4. 购买与资金明细：按批次、订单行、原交易查看分配/消费/退款，正常自动结算，例外人工跟进；Finance保持核算职责。
5. 履约与售后处置台：按受影响行/包裹/批次处理质量、少件、部分交付、回收、补送；显示源证据而非手选“齐全”。
6. 经营准备与内容发布：需求分层、备货安排、鲜讯依据/有效期、供应异常、剩余处置，并反馈顾客端。

这些是组合视图和受控业务命令，不新造“后台订单库”，也不增加一个拥有所有事实的万能客服领域。

推荐实施顺序与验收方式

每轮以同一组客户数据同时走小程序、后台及模拟源结果。至少包含：正常；拒绝；无权限；重复；旧版本；并发胜负；收费成功接受失败；切配发生回执丢失；部分退款/部分送达；新单失败；退款未知；退出；调度恢复；员工交接；终态后晚到证据。

验收不是按钮有回执，而是顾客能看清“当前结果、钱在哪里、会不会送、还需谁做什么”，员工能看清“源事实、可办范围、责任、时限、恢复路径”。UNKNOWN必须保留；任何一端未有对应结果，都不能关闭该故事。

7. 待业务决策与剩余风险

长期真实负责人和政策未知仍是未完成事项。本轮提供可评审的设计方向，不要求现在一次回答所有参数；后续逐条业务闭环设计时再把必要决策收敛。

回退与迁移：本轮没有产品变更或生产迁移。后续修原型须版本化合成数据，保留原记录备份及旧ID引用；不能把旧“已验证/已完成”强映为新权威成功。真实迁移与回滚要核验外部资金和现场事实，不能用重置浏览器作为恢复方案。

8. 对先前“全模块覆盖”结论的修正

82页/206动作/318故事证明的是已声明能力的目录与局部动作覆盖，不证明经营机制无遗漏、跨模块实际协作、受托授权或两端一致。先前“已明确对象都有可见路径”的表述也需受9月29日新增对象及本轮结果审查限制。

已有局部设计值得保留：事实Owner分工、独立确认意识、退款整数额度和未知占用、逐次操作历史、独立复核入口、质量/物料/财务基本检查、精确关联样例及异常场景入口。下一步应在这些基础上补齐结果，不能把“证据框+目标状态”持续扩展成所有模块的通用办理方式。

附录A：82项工作区逐项盘点

此表只声明已核对配置和相应风险，不声明每项已做浏览器全路径验收。所有创建入口均受G13的新建关联问题约束；真实权限共同受G18约束。无状态出边只是检查线索：合法终态、策略待批准和跨域下一步必须区别，不能自动判成Bug。