> 本站副本说明：本文件是 2026-09-30 快照的**脱敏阅读副本**，供站内阅读；不可访问的项目原件与原始记录统一标注“原件在本地归档”，标题、日期与证据等级保留。原始行号（`L…`）可供有权限的审计者在本机定位。

# 工作流与人机协作发现

## 总判断

【推断】现有工作流能约束高风险金额、留下失败证据并支撑局部修复；将目标从“若干包完成”收束到“读者能够开始验证”的能力不足。用户充当了持续的完成条件校正者。不能简单裁定整套工作流有效或无效，应分别评估路由、证据、可操作交付、授权恢复和上下文入口。

## 问题与反证

### W01 完成条件晚到，局部PASS掩盖读者无法开始

**已证实**：用户多次要求做到可发柏甫；9/29最终说可内测，9/30清单盲读却说明匹配运价数据和同单司机任务不足。430用例及部署门没有覆盖这些前置条件。**责任判断【推断】**：主代理应为已授权的演示数据准备和可操作性负责；客户专属金额不能自行假定，但可以准备明确标注内部样例的局部测试数据，不能只把缺口写进清单。

反证：始终明确完整主线未过；局部内测可采用已有数据或由柏甫协助准备，并非所有局部操作都不可用。问题是“可发”被解释成能访问和预读，没有证明用户期待的可开始条件。来源：L7693/7725/13362/15308/17260；资料回执、项目S8/S9。

改进：开工记录接收人、一个可开始场景、数据/角色、版本、预期结果、证据；缺任一项只能报对应状态。把数据包纳入同一交付包，准备工作与需求裁定分开。

### W02 测试路由及测试设计时序没有一次纠正到位

**已证实**：G1由开发会话写并测；用户指出后改DS独立执行。G2作者独立但完整设计晚于实现；G3/G4后来先写再开发。独立执行不等于独立设计，也不等于规格正确。来源：L1673/2012/3184/3223/5670；G1/G2/G3A/G4回执。

反证：初期读取的旧规则允许局部紧耦合例外，不能用后改规则追溯为当时全部违规；用户纠偏后例外已取消，后续实际DS provider有证据。

改进：测试设计由Sol先固定范围/场景，开发者可评审可测性但不得事后改预期以迎合实现；DS执行并给rc/执行数。为设计基线加版本引用与首个实现时间，先后关系可查。

### W03 环境错配制造0执行与重复派工

**已证实**：G1缓存/监听权限导致两轮0执行；G4及guide检查也遇环境或角色误解；guide的DS一度以为自己应再启动DS。CLI退出0、route_verified和机械检查0候选不能替代实际通过。来源：G1回执；L16160/16333；资料验收记录。

反证：这些轮次后来没有计入通过；已改可写缓存/隔离环境及“你已经是DS”提示。环境权限在历史宿主下并非单靠内层sandbox能解决。

改进：测试包先声明需要缓存、端口、浏览器与数据；执行前做一次环境预检。不要为工具错误重新写业务规则；0执行只归环境或选择问题。

### W04 部署恢复路径不完整，阻塞被反复转交用户

**已证实**：既有demo部署脚本仍匿名预热，登录墙开启后v0.2.21实际上线却脚本FAIL；凭据恢复位置未知。主代理三次问文件/钥匙串路径，用户不理解其与服务器部署的关系，最后重新给凭据。来源：L7955/10992/13353/13370/13547/13612/15308；部署工作流。

反证：业务认证核验确实需要有效登录态，不能凭SSH就证明业务可用；不把密码硬编码的安全边界正确。问题是没有先穷尽已有恢复入口和清楚说明三种权限。

改进：先检索已知恢复位置、脚本、历史回执；向用户描述“账号用于上线后验证，服务器已可连接”。最终Keychain存取协议已沉淀，不把值写入项目。

### W05 guide漏发和授权解释不稳定

**已证实**：应用已更新，guide仍旧版；deploy-demo.sh不会发布guide。用户9/30指出后才补候选和资料包；随后又停在“本次页面授权”。独立审阅指出《工作偏好与约束》第10条明确“说明页每次演示环境更新同步改；改完可直接发布，微信通知由王佳梁发”。发布卡同时列有R53内部可撤回demo直接做、R70例行demo除外。上一轮新增的“本次重新授权”关口与既有约定冲突；这是主代理执行及新增流程口径的错误，不能继续归为用户缺授权。

反证：guide带客户验收邀请、承诺或正式轮次时仍需人判；页面授权须绑定范围，不能拿一次内测授权覆盖未来所有外发。来源：L7506/13362/15319/17260；发布卡R53/R70、部署/交付工作流。

改进：记录授权对象（内部demo应用及同版资料/正式客户轮次/微信发送）、有效范围和时点；已有授权直接执行，只有扩范围才问。本次按该证据修正三份现行流程，保留修改前快照；没有实际发布guide。应用、guide、消息三者分别核状态，避免遗漏。

### W06 资料是先写后对照，出现UI与版本语义误述

**已证实**：资料漏了草稿删除/库存单价；车辆看板菜单归属错误；旧v0.2.21提示一度列成本版新增；审批历史API守卫一度被描述为正常UI变化。DS表述审查也曾PASS，Sol沿调用链发现不适用才删除。来源：资料回执、L16630/16677/16922；版本更新说明。

反证：这些误述在最终候选修正；已部署代码可以辅助核UI词，但未实见线上业务流程仍是未验证。

改进：资料作者先拿到本版变更清单、UI标签、入口、实际可观察行为及版本归属；检查用来证伪，不能以关键词符合代替业务可达性。

### W07 “完整PRD”与“主题分层”被当作文件存在问题

**已证实**：用户先问完整资料，主代理以未签认解释不完整；用户澄清是汇总已知碎片与缺口。之后又指出人看不懂，v0.2才用角色和同单讲业务。15主题入口存在，但不是自动注入，也未全部正文整合。来源：L6913/7045/7054/7351/7362/7486。

反证：原始回答确实区分评审稿和已签认；主题规则及冷启动已有首期证据。入口机制并未完全失效。

改进：完整性分“已知输入已汇总/规则无歧义/可执行/签认”四种，分别核。每包只带相关主题和决定，把缺口显式OPEN；用冷启动任务观察漏读率，不靠目录数量验收。

### W08 证据分散与过细复测增加协调负担

**已证实**：最终430证据在隔离worktree、部分资料输出在（临时位置已省略）、根仓有大量未提交修改。此次扫描一度误判430证据不存在；跨目录可发现性尚不足。资料轮15次CLI启动，部分围绕单句、命名和规则重复。**推断**：部分低风险文字宜一次综合验收后只测受影响项，过细拆分可能抵消廉价模型收益。

反证：没有成本/完整耗时基线，不可给出浪费金额；一些追加检查抓到了审批可达性、0候选假阳性和数据缺口，确有收益。独立工作树保护了他人修改，也支持冻结候选。

改进：一个版本交付包聚合任务、SHA、环境、通过/失败、数据、资料、guide、消息和外部状态；保存稳定指针，不复制所有正文。设置停止条件：必要检查过且无具体疑点即停止。

## 应保留的机制

1. 真实provider核验、原始rc和0执行单列，保护了证据可信度。
2. 价格批准证据缺失时停金额落账，没有把AI推荐当客户决定。
3. 冻结候选与隔离工作区、文件所有权，避免吸收他人未提交改动。
4. 有来源的需求汇总、先测试设计、定向红绿和兼容回归，抓到真问题。
5. 安全凭据位置协议、公开版本与客户验收范围分离，减少长期恢复成本。

保留这些机制，同时把低风险步骤合并、把业务可开始性提前；不通过增加更多常驻规则解决所有偶发错误。