18 份可执行 Playbook

产出一份可被 Delivery Lead 与业务 Sponsor 共同签字的机会判定结论（Go / Conditional-Go / No-Go），其核心是回答四个「可做成」硬前提是否同时成立：

把立项时的价值假设，转化为利益相关者共同认可、可被后续阶段直接引用的对齐结论，具体产出：

把访谈得到的业务事实与数据线索，沉淀为四类可版本化的一等资产，作为下游场景设计（04）、验收标准（05）与数据/权限验证（06）的输入：

把开放式业务问题拆成边界清晰的用例卡，每张卡回答六个问题：用户意图是什么、实体范围到哪里、数据从哪来、期望输出长什么样、怎样算通过、哪些是负例。用查询约束契约（Query Constraint Contract）的正交轴来表达「范围」，而不是给每个场景加一个一次性布尔开关。

为每个 P0/P1 用例产出一张端到端验收表，每行是一个可执行 case，列出：输入 → 期望分类器输出 → 期望工具参数 → 期望呈现 → 显式 PASS 判据，并在真实运行日志上验证（不是单元测试的想象输入）。同时为每个 case 定义 must_not_include（禁兜底、禁泄露）与维度严重度（硬/软/忽略）。

在真实环境用 Probe 核验四件事，并把结论沉淀为可复用契约：

把上游冻结的验收标准（playbooks/05）与已验证的数据/接口/权限事实（playbooks/06），落成一套责任分层清晰、每层单一事实源（SSOT）、确定性与概率性边界明确的智能体架构，使得：

用尽量小的实现验证"这套架构真能端到端产出可用交付物"，并同时立起可复现的质量标尺：

把"实现与迭代"变成一个分数驱动、可复现、防作弊的闭环，使每次改动都满足：

把单个失败 Case 修到「根因已消除、单 Case 通过、稳定复跑通过、回归无新增失败、独立验证确认、经验已沉淀」，而不是修到「这次跑绿了」。

把一批（参考规模：数十至数百）失败 Case 系统化收敛，同时守住三条底线：

- UAT：用一份可逐字段判定的用例表，证明系统在真实数据、真实口径、真实权限、真实多轮下达到每条用例自己的验收标准（AC），并把失败用例驱动到闭环收敛——而不是「回复看起来不错」。 - 试点：在真实现场稳定运行，把 Eval/UAT 没覆盖到的边缘案例系统性采集下来，目标产出物是新的 Eval 用例（生产反馈必须变成 Eval 资产），并接入现场运营反馈通道。

- 把「可合并（merge-ready）」与「可上线（deploy-ready）」拆成两个独立门禁，避免用合并质量冒充发布质量。 - 用发布门（Release Gate）统一放行条件：静态门全绿 + golden 硬门通过 + Eval 阈值达标 + P0 缺陷为 0 + 无悬而未决的产品决策。 - 上线后独立验证真部署与真行为：grep 生产制品是否含本次修复的唯一串（证明代码真到了服务器）；跑至少一个真实端到端语义冒烟用例（证明行为没坏）。 - 用 canary（灰度）与 soak（浸泡观察）把「小流量 / 短时间的真实生产反馈」变成放大流量前的必经关卡。 - 把回滚设计成纯配置操作（改 env / 切版本 + 重启），让「出问题能在数分钟内退回」成为发布的前置条件而非事后补救。

- 一次建模遥测 schema、增量埋点：先把「运行 / 单次 LLM 调用 / 单次工具调用 / 里程碑事件」四类实体的表结构一次设计好，再逐步补埋点，避免 schema 反复变动。 - 遥测永不阻塞业务：埋点走 fire-and-forget + 有界缓冲 + 失败丢弃计数，任何遥测故障都不能拖垮或崩溃业务链路。 - 每次调用可溯源：记录 {配置版本, 配置来源枚举（db/cache/code_default/not_managed）}，让「哪个配置版本产生了这次成本/行为」「我的配置改动生效了吗」能从数据直接回答。 - 单点埋点：在工具/数据调用的唯一咽喉点记录，把零散调试变成常驻的工具健康看板（成功率 / P95 / 错误分布）。 - 定时巡检规则：对遥测表跑定时异常检测 SQL，每条规则都绑定一个真实历史故障。 - 运行时自我复审：每次回复后异步跑规则化质量自检（可选 AI 复审），写台账、发质量提示，把生产运行变成学习燃料。 - 生产质量监控：把兜底率、延迟分位、异常聚类作为常驻质量信号，喂给发布决策与学习闭环。

- 把每条原始反馈分类为固定枚举类型（bug / feature / question / data_gap / praise / complaint），避免自然语言杂陈无法路由。 - 用文件化队列 + 显式优先级（P0–P3）+ 状态机管理反馈，让 backlog 可复用、可复现、不塞进对话上下文。 - 明确区分修复（fix）与产品决策（product_decision）：不是所有反馈都该「立刻改代码」，有的需客户/PM 拍板口径或砍需求。 - 把每条被修的反馈变成一个 Eval 用例，让同类问题永不回归。 - 把可机器强制的规则变成测试 / 代码护栏，而非仅写进文档。 - 用单一归宿路由（Experience Capture）：每条反馈落到 fix / product_decision / eval_case / code_guard / doc_update / wont_do / duplicate 之一，不重不漏。

把一次交付/一轮缺陷修复/一次生产反馈中产生的可复用经验，转化为下一次会自动生效的资产，而不是停留在某个人的记忆或某条聊天记录里。具体产出三类可验证的结果：

- 可续接的移交：产出「≤80 行即可让接手方直接续」的 handoff 状态机文档，接手方不靠原作者记忆、不靠聊天记录即可恢复工作，且每条状态有证据链支撑（不是自述「已完成」）。 - 可复制的适配层：把这次交付里项目专属的适配层（口径、字段映射、场景、验收、护栏）沉淀成可复制模板，与通用方法论显式分离，供下一个客户直接改填而非从零重建。 - 可评估的成熟度：用成熟度模型对当前项目/团队做一次评估（见 docs/09-maturity-model），明确「哪些能力可规模化、哪些还需现场陪跑」，作为规模化决策依据。 - 可持续的知识刷新：建立知识刷新机制（见 operations/knowledge-refresh-management），让移交后模型/数据/口径变更不会让交付物悄悄过期。

让 N 个并行 worker 安全、可复现地推进同一个大工作量，且满足三条硬约束：