非洲物流 TMS 现行工作流完整说明

本文是截至 2026-09-20 的独立接手说明：从输入进入项目，到需求、设计、开发、验收、发布、反馈和治理怎样流转；谁负责什么；什么时候 AI 可以继续做，什么时候必须停给人决定；怎样判断一项工作真的完成。

本文压缩了 9 月 18 日完整描述中的重复设计解释与逐条 K 清单，保留仍然有效的流程、关键约束、例外和未落地项。实时阶段、在飞任务和下一动作仍只认 〔出处：STATUS〕；本文不代替 STATUS，也不增加授权。章节来源见 〔出处：source-map.json〕。

目录

1. 工作流要解决什么
2. 角色、身份与写入边界
3. 上下文、信源与文档权威
4. 一次推进怎样开始
5. 输入分诊与客户材料入库
6. 疑点取证：文本、代码、运行证据
7. 需求、决定、假设与基线
8. 设计、评审与变更准入
9. 派工与执行
10. 开发、验证与集成
11. 发布、交付与客户可见批次
12. 反馈、回访与关闭
13. 人的决定从哪里进入
14. 多模型评审与模型成本偏好
15. 状态、事件、交接与恢复
16. 巡检、园艺与治理
17. 完成定义与收尾
18. 现行、试点、历史与未落地项
19. 三个完整操作示例

1. 工作流要解决什么

这套工作流的目标不是让更多 agent 同时工作，而是让每次承诺、判断、执行和验收都能被下一次会话接住。它必须保住五种能力：跨会话恢复状态；找到足够且有效的依据；明确责任与授权；让“已完成”受证据约束且可恢复；从真实偏差修正规则。〔出处：v3 完整描述 §1.1〕

四个长期约束决定了工作方式：

• 人和模型的上下文、时间和并发能力有限，因此入口要短、资料按任务加载、工作要拆成有界包。
• 客户没有说过的业务口径不能从历史文档或测试中推出来，因此原件、归因、冲突和未知必须保留。
• 多会话会重复消费、写一半或互相覆盖，因此用单写者、白名单、任务书、记录和独立 worktree 协调。
• 对外承诺、生产数据和不可逆后果不能靠撤回文件消除，因此按恢复成本决定验证深度，并保留人类闸门。

一条完整主链如下：

输入与原件
  → 分诊、命题、冲突与决定
  → 需求基线与模块设计
  → 任务书与执行包
  → 包内验证、验收与集成
  → 获授权的部署／发布／发送
  → 反馈、回访与提出者确认
  → 状态、证据与治理回流

2. 角色、身份与写入边界

2.1 先判身份

在仓根进入任务时先读 〔出处：AGENTS.md〕 §0：

• 王佳梁直接开会话、让 agent 接手项目，且没有执行任务包：这是驱动方。
• tcd、脚本或上游消息带任务书与包名：这是执行者。
• 判不清时按执行者，避免误取更大写权。

应用或宿主名称不决定权限。同一套任务书可以由原生代理、tcd 作业或桌面会话执行；授权来自当前身份、任务书和项目契约。

2.2 驱动方负责什么

驱动方读 STATUS，确定本阶段终点，分诊输入，写任务书，派工，监工，验收，集成并向用户汇报。具体代码与业务正文交执行者完成。驱动方可以维护 STATUS 当前区、任务书、派单记录、新决定和授权内的集成提交；部署、发布、外发仍需对应授权。〔出处：AGENTS.md §1〕；〔出处：项目推进技能〕

2.3 执行者负责什么

执行者只写任务书白名单，编码任务另读 tms-app/AGENTS.md。执行者不改 STATUS、不安装依赖、不部署或外发，Git 默认只读；只有独立 worktree 且任务书明确授权时才可提交。需要改白名单外文件时，只报告精确路径并停在边界。〔出处：AGENTS.md §2〕

2.4 业务、评审、工程和治理职能

这些职能不要求五个常驻窗口。简单任务由驱动方直接完成；有独立且并行收益的有界任务再派原生代理或 tcd。共享工作区同刻只运行一个代码包，避免依赖、数据库和测试环境互相污染。〔出处：v3 操作手册 §一–二〕

3. 上下文、信源与文档权威

3.1 按任务加载，不读完整历史

上下文分三层：L0 是身份、边界、状态和路由；L1 是当前任务的任务书或任务卡；L2 是按需读取的原件、决定、设计、代码和证据。没有统一共享记忆服务，长期状态靠文件和回执维持。〔出处：v3 完整描述 §3.1〕

驱动方接手项目通常读根契约、STATUS 和本次动作需要的全景或操作手册；执行者只读任务书、根契约及目标目录近端契约。任务没有需要时，不扩读原始客户材料、应用代码或大仓。

3.2 五层事实治理

运行结果以证据回执为准；汇总数字以对应生成器及其输入为准；STATUS 是当前导航，不是原始事实仓。文档 status、命题五态和证据五态是三套不同概念，不能混用。〔出处：v3 完整描述 §3.6〕

3.3 信源辨伪

任何实质主张都要能回到仓内出处。推断用“【推断】”标明；提出人无法确认时写“未标明”。04 号文档和历史底稿只作参考，使用前按项目全景核信源。原件、会议记录、归档、旧决定不可为方便说明而改写。〔出处：AGENTS.md §3〕

4. 一次推进怎样开始

驱动方收到“推进项目”“继续项目”或“按 STATUS 接手”时，使用 〔出处：tms-project-advance〕：

1. 读 STATUS 当前区、在飞 job、阻塞和下一动作。
2. 用一句话确定本次有界阶段的终点、产物和完成条件。
3. 分出可直接推进、需取证、需派工和确实需人决定的事项。
4. 先完成我方取证、材料和独立任务；无法访问的外部状态写 UNKNOWN。
5. 只把会改变承诺、权限或结果的分叉提交给相应的人。

推荐的开场句：

本阶段终点是把“财务完整稿”交成“王佳梁与柏甫可以在同一入口逐段审核并分别表态”的版本；产物是正式内审轮；完成条件是本地最终渲染通过、线上内容读回一致、两位审核人的待办入口清楚。

阶段终点不是整个项目完成，也不能把“执行者 DONE”写成阶段完成。

5. 输入分诊与客户材料入库

5.1 输入渠道

5.2 材料七步

新材料依次做：落原件、抽命题、撞冲突、标记下游 needs-review、投影基线、记录有权决定、由获授权者入库提交。每条命题带永久 ID、主体和原文锚点；双方冲突都保留，不替客户选边；来源哈希一致不能代替语义检查。〔出处：v3 完整描述 §2.2〕

命题状态包括 CONFIRMED、CONFLICTING、UNCONFIRMED、SUPERSEDED、PROPOSED。没有拍板时不能造决定；未知业务规则进入待确认清单，并写默认、级别、谁定和状态。

6. 疑点取证：文本、代码、运行证据

核实客户、顾问或王佳梁提出的疑点时，使用 〔出处：tms-evidence-check〕。先固定线索编号、逐字原文、提出人及身份依据、担忧、严重度和检查范围。

1. E1 文本证据：查 register、需求交付索引、设计、有效决定和假设台账，记录路径、行号或章节及短引句。
2. E2 静态证据：查代码、权限、路由、守卫和 schema，记录实现含义。
3. E3 运行证据：选择精确测试或同一 SHA 的运行回执，记录命令、环境、原始 rc、真实执行数和输出。
4. 主动找已有防护、相反规则和不适用条件；没找到时写“未找到反证：查了哪里”。
5. 按最低证据给 CONFIRMED、PARTIALLY_CONFIRMED、NOT_CONFIRMED、CONTRADICTED、INSUFFICIENT_EVIDENCE 五态结论。

文档缺规则至少需要 E1；代码未实现至少 E1＋E2；运行或线上结论至少 E2＋E3；发布结论需要三层齐。取证结束只给结论、影响、建议和验证方法，是否实施另看任务授权。

7. 需求、决定、假设与基线

7.1 什么可以由 AI 继续做

内部、可回退、已授权且能由证据判断的动作由 AI 继续完成。无对错、可回退且两周可测的偏好放入实验卡：写默认方案、指标、采集方式、观察期、复审日和回退。〔出处：AGENTS.md“Multi-Agent Review”〕

7.2 什么必须由人决定

以下事项保留给承担后果的人：改变客户承诺；对外发布或发送；关于人和钱；权限、财务、隐私和数据迁移；不可逆风险接受；现行决定明确指定的审批。机器门通过、讨论收敛或一次授权都不会扩大权限。

需要人决定时，给一张可执行决定卡：背景、选项、推荐与理由、影响、真实入口、决定后的动作。已有有效答案的事项直接按现行决定执行，不重复索取批准。

7.3 假设实施

客户未答时，可按现行 D36 对可回退部分做显式假设：写入 ASM 台账，设计中标“假设实施”，给默认、界面标注、反向测试或开关。涉及钱、权限、数据迁移且做错不可逆的事项只能占位等待，不得用假设越过人类闸门。〔出处：v3 完整描述 §2.3〕

8. 设计、评审与变更准入

8.1 设计要足以实现和验收

模块设计应把业务语义和技术实现分开：业务负责需求、场景、异常、未决；工程补技术规格、接口、数据、权限和测试设计。交工程前至少能定位完整设计、06 场景、08.0 需求—代码对账、10 未决表、版本、批准引用和接收 ACK。〔出处：v3 完整描述 §2.3〕

顾问评审可以与已答模块的实施并行；结构性意见返回时停受影响包并改设计，独立包继续。送审材料用可连续阅读的完整需求正文和证据链接，不恢复旧的固定六件摘要或刻板提问数量。

8.2 什么时候必须跑变更准入

将要修改 schema、加删字段、改变字段业务含义、枚举或状态机，或把模块设计稿送审前，使用 〔出处：tms-change-gate〕：

1. 写清具体变更动作和对应需求、有效决定、设计与实现。
2. 先判断设计是否需要更新；找不到设计或关键口径未决时写 BLOCKED，不能先改表再补手续。
3. 对受影响设计运行 python3 tools/check_design_doc.py "docs/specs/<模块>-设计.md" --report。
4. 保留原始 rc 和逐门结果：rc 0 只证明机械检查通过；rc 1 是违例；rc 2 是工具或输入故障。
5. 准入通过后再按应用契约完成类型、DDL、白名单同源、测试与证据。

普通 CSS、纯文案和不改变字段、枚举或状态语义的局部修复不触发该技能。准入通过不等于需求冻结、顾问通过、客户拍板或发布获准。

9. 派工与执行

9.1 什么时候派，派给谁

简单任务由驱动方直接完成。有独立、可并行、有界且收益大于交接成本的子任务再委派。原生代理与 tools/codex_dispatch.py 是两种独立机制；后者 --dry-run 只验证模板，真实派出才产生 job、作业记录和 watch_cmd。〔出处：项目推进技能第 4 步〕

模型路由见第 14 节。写入任务并行时必须分开文件所有权；依赖或重叠任务串行。共享工作区同刻一个代码包。

9.2 任务书的必要内容

每份执行包至少写六部分：来源；目标与具体交付物；用例；精确白名单；包内门与批次门责任；完成纪律。另写：

• 恢复：对象、方法、预计耗时、恢复证据和不可恢复副作用。
• 默认裁定：他包改动怎样处理、什么不算越界、遇到常见歧义怎么做。
• 验收深度：quick 或 deep，依据恢复成本选择。
• 完成标记和越界停点。

机械 completion contract 只适合检查交付文件和本轮标记；完整业务验收仍由驱动方完成。〔出处：v3 完整描述 §3.2〕

9.3 监工

监工核本包 job、活性、原始 rc 和机械契约。idle、DONE 或代理总结不代表业务接受；UNKNOWN、BLOCKED 和白名单停点按真实状态处理。验收只看任务书点名产物、实际命令、真实执行数和完整输出。

10. 开发、验证与集成

10.1 包内开发

代码包围绕一个可独立验收的用户行为闭环。修复先证明错误可复现，再证明同一断言变绿；覆盖正常、边界、失败和权限四类用例，缺类写不适用依据。执行者不静默吸收需求变化；发现需求变化回业务线并取得接收 ACK。

10.2 worktree 与候选

较大代码批次使用：冻结共同基点 B → 每包独立 worktree → 定向红绿 → 封存单包候选 C → 工程验收 → 集成候选 I → 静止工作区排他批次门 → 驱动方合并。执行者默认没有 Git 写权；创建树、依赖初始化、集成和合 main 由有授权者承担。〔出处：v3 完整描述 §3.4〕

P2.3 是一次历史试点，证明“两包隔离开发＋集成候选”跑通过；其中发生过输入污染假红，也暴露 406 条冒烟全绿仍漏掉真实客户端导入 500。真实端直连用例与干净库动作仍是待补能力，不能把试点结果写成永久保障。

10.3 验证深度

验证强度看恢复成本和影响面：quick 适用于可回退、影响受控且恢复证据充分；deep 适用于恢复小时级、不可恢复或依据未知。两者都不能豁免业务断言、权限不变量和对外授权。

需要送审的页面还要核：最终渲染、实际运行版本、正文与结构化显示字段一致。截图不是每个任务的默认门；普通视觉由 Terra，确定性计数与存在性由 Luna，需要改实现时由 Sol。〔出处：规则更新回执〕；〔出处：模型分工决定〕

10.4 机器门的边界

现有机器门包括任务书模板、只追加保护、监工活性、修剪无损验收、多模型警戒线、流程卡 runner 和三态自检。每个 PASS 只覆盖它实际检查的对象：引用检查不验业务含义；设计门不等于需求批准；runner dry-run 不等于发布已自动完成；gen_status --check 的 rc 0 不代表差异为零，必须读报告。〔出处：v3 完整描述 §3.3、3.5、3.7〕

11. 发布、交付与客户可见批次

11.1 发布顺序

客户可见批次按固定候选执行：确定版本 → 从干净候选部署 → 核实际 SHA、版本、构建和探针 → AI 与顾问走查及观察 → 处理 P0/P1 → 由王佳梁按现行授权决定宣布 → prereview 与正式发布按各自批准对象执行 → 外发和回执。〔出处：v3 完整描述 §2.5〕

合 main 不等于部署；部署不等于已通知客户；内审通过不等于已经发送。微信等不可逆发送由有权者执行。版本升位和批次范围沿现行 D26 与交付工作流，不从本文创造新规则。

11.2 prereview 与正式发布

发客户前的完整稿由指定内审人审核同一版本。当前财务案例要求王佳梁与柏甫分别表态；两人“赞成”表示稿件可照此发客户，但仍不等于已经发送，也不自动批准 TMS 部署。〔出处：财务调度记录〕

第 10 轮只是一次已明确授权的新内审轮：主代理执行一次受保护 POST，旧轮和工作台运行文件保持不变。不能把该次批准推广为以后可以自动新开轮次或绕过未答项。

11.3 回滚

回滚必须绑定上一份 PASS 回执、候选和数据恢复证据。不可逆迁移或紧急回滚边界仍由有权者决定；历史文档里的“自动回滚”建议不能覆盖现行授权。

12. 反馈、回访与关闭

反馈按五路处理：已有功能缺陷进工程；需求变化进业务；新功能建议进确认清单；使用问题答疑；评审线索先取证。每条保留来源 ID、提出人身份、责任线、处理版本和回访记录。〔出处：v3 完整描述 §2.6〕

“我方已处理”和“提出者确认关闭”分开记录。回访说明判定、原因、改了什么、在哪个版本、去哪里验证。提出者没有确认时保持待确认，不能用沉默、pending=0 或工程 DONE 代替关闭。

首次回复和处理时限是观察口径；超时记未遂，不伪造时间。客户或顾问反馈改变需求时，必须回业务层更新来源、受影响设计和包清单，代码不能直接吸收为事实。

13. 人的决定从哪里进入

13.1 对话还是工作台

• 一个到几个明确问题：在对话中给背景、选项、推荐、影响和决定后动作。
• 完整长稿、多处批注、可视化对照或用户指定：使用现有工作台，正文只出现一次，入口明确。
• 已授权且没有新分叉：直接执行，不重复请求确认。

工作台是人的决策界面，不是 TMS 业务规则的第二权威源；决定仍需落到项目所属记录。〔出处：改进清单 §4〕

13.2 决定卡、实验卡、周治理卡

讨论一致、机器 PASS 或多数意见都不能替代有权者作决定。

14. 多模型评审与模型成本偏好

14.1 先过三问

开多模型评审前问：有没有可判定的对错；错了能否恢复及代价；两周实践能否给数据。“无对错＋可逆＋可测”不讨论，直接填实验卡。只有有对错或不可逆的动作分叉才进入多模型评审。〔出处：AGENTS.md“Multi-Agent Review”〕

重要既有工件用 blind-review；重大方案用 deliberate：独立三稿 → 收敛门 → 只对剩余分叉做反证 → 证据合成。第二等设计可用 Astra 或 Sol 单稿加独立盲评。确定性 API 调用、任务书生成、计数和核验走脚本，不派 agent 充当命令搬运工。

当前三稿默认 Astra＋K3＋opus，Fable 仅王佳梁点名。每轮触及警戒线就停；续轮例外必须留具体理由。不按投票裁决，讨论不新增执行授权。仓内 ai-config 仅是离线快照，实际使用前核当前宿主加载的技能入口和渠道。

14.2 日常模型路由

简单任务主代理直接做。选择模型看判断难度，不看文件数量；不为了换模型增加交接。主代理读精简结果和必要证据，避免重复加载同批截图或长输出。没有精确计量时，费用和 token 写 UNKNOWN，不编造节省比例。〔出处：模型分工决定〕

15. 状态、事件、交接与恢复

15.1 STATUS 的职责

STATUS 只放当前阶段、在飞、阻塞和下一动作，由驱动方单写。执行者不改 STATUS。当前仍是手写当前区与 gen_status 预览／检查并存，尚未切成完全生成段。〔出处：v3 完整描述 §3.5、附录 B〕

15.2 事件

事件的核心字段是 work_id、attempt、event、at、candidate、target、evidence，正文末尾只追加。DONE 与 accepted 分开；target=demo 还需要匹配同一 work、attempt 和 candidate 的部署 PASS 才能结单。旧 PASS 不能关闭新 attempt。

15.3 交接

任何跨会话交接至少能定位：任务书、授权来源、固定产物、验收回执、未决项及下一责任人。恢复说明写对象、方法、证据和副作用。凭证不入仓，只记录可恢复入口。〔出处：v3 完整描述 §3.2〕

15.4 当前协调能力的边界

目前依靠任务书、派单记录、STATUS、Git 工作树、tcd 作业记录和讨论 run 目录协调。统一的 agent_id/run_id/work_id 事务账本、认领、租约和幂等服务尚未建成，因此驱动方仍需核在飞并避免重复派单。

16. 巡检、园艺与治理

16.1 巡检

巡检只报告实际可访问的状态。需要联网、SSH 或写台账时先核授权；不可访问写 UNKNOWN，不冒填零。每小时巡检归属在 9 月 18 日完整描述中仍是未落实义务，不能说已由 v3 自动接管。〔出处：项目推进技能第 1 步〕；〔出处：v3 完整描述附录 B〕

16.2 文档园艺

园艺目标是缩短读取路径，同时不丢事实、义务、限定语和恢复能力。四种动作是搬、标、生成、报，每种都受精确授权。首次前台修剪和六条无损验收已跑过；后台四探针 daemon、效力旁车、条款级 supersede 自动投影仍未建。〔出处：v3 完整描述 §1.8、3.6〕

16.3 周治理

计划中的治理会话从原问题、开放义务、检查差异和反例出发，输出不超过 10 条的周卡，并固定审查规则、成本收益和存量债务。独立治理首跑和 09-28 数据复盘仍是安排，不是已完成事实。〔出处：v3 操作手册 §四〕

17. 完成定义与收尾

17.1 执行包完成

执行者完成必须同时满足：交付物落盘；指定命令通过并给原始 rc；真实执行数和完整输出可核；本包后台为零；回复首末行有本轮 [DONE:<包名>]。这表示“已交付待验”，不表示驱动方已接受。〔出处：AGENTS.md §2〕

17.2 驱动方验收

驱动方读取实际文件和证据，核业务含义、候选版本和验证边界。需要送审的页面核最终渲染、实际运行版本和结构化字段；普通任务按风险验证，不一律升级截图、盲评或全量复验。验收结果可为通过、有条件通过或不通过；条件必须有责任人和关闭判据。

17.3 一段工作怎样收尾

收尾先回答五问：阶段变了吗；出现新系统、凭证或流程了吗；出现新偏好、经验或坑了吗；有未遂吗；本段修过一批 bug 吗。变化写回所属文件，无变化写不适用。修过 bug 的批次记录机制根因、旧门为什么没拦住、同类探查和本质，不自动增加规则。〔出处：v3 操作手册 §三〕

最终汇报按以下顺序：

1. 本阶段业务结果；
2. 用户现在要做的具体动作，或明确本阶段无需用户操作；
3. 本地候选与验证；
4. 线上实际状态；
5. 人类确认状态；
6. 实际代理、模型、技能与主代理验收；
7. 未决项的责任人、缺口和下一动作；
8. Git、部署、发送和恢复的真实状态。

18. 现行、试点、历史与未落地项

早期文档中的固定六件评审摘要、四件套全文、硬 24 小时、人投入分钟、所有评审结束才能派所有包等表述已被后续决定调整，不能从旧稿恢复成现行硬门。〔出处：v3 完整描述附录 B〕

19. 三个完整操作示例

示例 A：王佳梁说“继续推进项目”

1. 当前会话无任务包，判为驱动方。
2. 读 STATUS 当前区、在飞和下一动作。
3. 写阶段终点，例如“把待审核完整稿交到正式内审入口”。
4. 先核稿件、版本、入口和我方剩余准备；能独立完成的直接做。
5. 需要正文适配时写白名单任务书，派一个执行包；驱动方验收文件、真实页面和版本。
6. 只有“是否对外”“是否接受风险”等分叉交人决定。
7. 收尾分开写本地、线上和人类确认，并给下一动作。

示例 B：顾问说“某权限可能绕过审批”

1. 固定顾问原话、身份、担忧、严重度和范围。
2. E1 查现行需求、设计、决定和权限规则。
3. E2 查路由、守卫和权限实现。
4. E3 跑精确权限用例或读取同 SHA 回执。
5. 主动找相反保护和不适用条件，给五态结论。
6. 输出受影响角色、状态、接口和流程；提出 Requirements／Specs／Code／Tests 建议。
7. 如果用户只要求核实，到此结束；修复另按任务授权派包。

示例 C：要新增一个状态枚举

1. 写清枚举变更、业务含义和对应需求／决定／设计。
2. 使用变更准入技能判断设计是否需更新；未决口径先 BLOCKED。
3. 更新任务白名单内设计与需求—代码对账。
4. 跑 check_design_doc.py --report，保留原始 rc 和逐门结果。
5. 只有适用门通过后才派实现；包内保持类型、DDL、接口和测试同源。
6. 工程验收后固定候选并跑适用批次门。
7. 是否部署、发布或通知客户另按授权处理；机器门通过不产生发布权。