workflow_what_to_how_execution_bridge

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_what_to_how_execution_bridge.md</code> 的逐字投影（仅隐私清洗，零改写）。

草案 Workflow：从 What 到 How 的执行桥接

状态

Draft skill，尚未晋升为正式 workflow。

当用户已经知道“要什么结果”，但实现路径、行动顺序、验证方式或下一步反应仍不清楚时使用。它把目标状态转成可执行路径，但不是替代具体工程、研究、测试或 Loop skill。

配合使用：

• workflow_requirement_decomposition_core：当 What 仍不稳定、需求来源不清或验收边界未定时，先用它。
• workflow_real_task_test_case_design：当路径需要真实任务测试时，用它设计 case。
• workflow_solid_decision_review：当需要判断是否能关闭、推进、晋升或停止时，用它评估证据强度。
• workflow_controller_loop：当任务需要多轮执行、任务卡、review 或调度时，由 Controller Loop 承载执行。

目标

帮助 agent 在“目标明确、方法不明”的任务中形成一种稳定思路：

目标状态
-> 当前状态
-> 关键差异
-> 能改变差异的行动
-> 最小真实切片
-> 证据边界
-> 下一步反应

这个 skill 输出的是执行桥接判断，不保证一次给出完整最终方案。它更像高层引导：让 agent 知道该从哪里下手、为什么这一步可能有效、什么证据才能允许继续。

理论内核

在 Agent-Task Gap Closure 框架里，What→How 是一个确定的部件：给定一个 Task，它生成能闭合 Delta(A,T) 的 Realization Protocol 草图。What 是 Task 的目标区域 G_eta 加验收 V，How 是把 Phi_P 头几轮的状态转移写出来。这给它一个形式定位，而不只是凭感觉的高层引导。

为什么这个桥必须存在（根因）。Simon 的状态-过程描述二元性指出：状态描述（认得出符合目标的产物）和过程描述（做得出这个产物）是两个互补、但不可互相还原的维度（SotA AX_13）。掌握其一不蕴涵掌握其二。所以「理解了目标就自然知道怎么做」是错的，What 和 How 之间存在一道真实的认知缝，What→How 就是显式跨过这道缝的动作。卡住时先诊断缝在哪一侧：能描绘目标但说不出第一步是过程描述缺失，能列步骤但说不清何时算完成是状态描述缺失，两者修复路径完全不同。

它的算子内核是 means-ends 分析。How 的生成不是 brainstorm，而是 means-ends：检测当前状态与目标状态的差异，为每个差异索引出能改变它的算子（HPS AX_24），按依赖拼接成行动序列，并监测每步是否引入新差异（SotA means-ends-analysis）。配合 Pólya 的双向遍历：先假设目标已达成、反向 analysis 到可达锚点，再从锚点正向 synthesis 兑现（HTSI AX_23）。analysis 无 synthesis 产生不可实现的计划，synthesis 无 analysis 是盲目前进。

它的停止逻辑是 satisficing。How 的搜索是过阈即停，不是搜索最优（SotA AX_07）。一旦某条路径过了可行性和可验证性阈值就锁定推进，无限精化 How 是 sunk cost 驱动的优化陷阱。这条对应输出契约里的声明上限。

理论要点逐条来源见 A_means_ends_extract.md，闭包定位见 loop_update_connected_synthesis_20260529_manual.md 第 3 节。

何时使用

使用：

• 用户给出 PRD、目标效果、验收标准、benchmark、失败现象或期望状态，但没有实现路径。
• 成功标准清楚，但根因、机制、技术方案或测试设计不清楚。
• 之前已经产出文档、代码、测试或报告，但真实使用中仍失败。
• Loop、AAU/AOU、workflow、skill 或协议需要从 requirement / diagnosis 进入 execution。
• agent 能说出“应该变成什么样”，但说不出“下一步真实动作是什么，以及如何知道它有效”。

不要使用：

• What 本身仍不稳定或有争议。
• 任务只是事实查询、资料检索或普通问答。
• 实现计划已经明确，只需要照计划执行。
• 当前问题是 closure / promotion / final report 是否可信。

核心判断

只有当目标能被写成下面这种结构时，才进入 What-to-How：

目标状态:
  可观察效果:
  验收信号:
  当前状态或未知项:
  不能支持的更强声明:
  必须生效的真实场景:

如果写不出，说明还没有到“从 What 到 How”的阶段，应先回到需求拆解或问题理解。

方法族选择

不要默认所有问题都适合 Work Backwards。先判断当前缺口属于哪一类。

可以混合使用，但必须有 primary family。常见组合：

• 固定 PRD、架构空白：architecture_risk primary，means_ends secondary。
• Loop 或调度系统：control_loop primary，failure_backchain secondary。
• 组织流程或知识迁移：messy_learning primary，strategy_kernel secondary。

输出契约

每次使用时，产物至少应能回答这些问题。可以写入任务卡、设计记录、测试计划、round review 或 Decision Packet；不要求固定文件名。

what_to_how_bridge:
  目标:
    当前状态:
    目标状态:
    验收信号:
    不能支持的更强声明:
  方法族:
    primary:
    secondary:
    选择理由:
  问题空间:
    带满足测试的目标:
    命名差异:
    可用行动:
    行动前提:
    副作用或控制风险:
    会改变方法的未知项:
  路径:
    选择的路径:
    拒绝或延后的路径:
    首个真实切片:
    失败路径或负向保护:
  验证:
    可观察断言:
    真实条件边界:
    需要的效果证据:
    需要的控制面证据:
    通过后允许的声明上限:
  下一步反应:
    如果通过:
    如果部分通过:
    如果变差:
    如果不稳定:
    如果受阻:

「如果通过」分支应包含 look-back：成功后把这次 How 路径抽成可复用骨架登记（验证的 primary family、命名差异到行动连接表、首个真实切片做法），供后续同型 unknown 直接召回，不重新探索（HTSI AX_27 look-back，闭合 Pólya 第四相位）。

判断纪律

1. 先冻结 What，再生成 How

先写清楚目标状态和验收信号。不要用“提高质量”“更鲁棒”“更完整”这类愿望词直接生成行动。

一个有效 What 至少包含：

• 当前有什么不满足；
• 目标状态可被谁观察到；
• 什么信号算达成；
• 即使达成第一轮测试，也仍不能声称什么。

context 充分性检查点：写完 What 后，检查当前 context 是否足够把关键差异命名清楚。如果命名不出差异（只能说「质量不够」却说不出差在哪个可观察维度），不要进入 How 生成，先回到信息收集或需求拆解。历史上多次失败的根因就是 context 不足时硬进 How（典型如 2026-05-10 把 schema 层测试当真实行为验证）。操作性空间限定：What 必须落在执行者实际能表示且能测试的操作性空间，而非形式目标空间；写不出可观察的验收信号 = What 仍在 formal space，此时进入 How 生成只会把形式规格误当执行路径，先回需求拆解（HPS AX_05 operative-problem-spaces）。这一步把 Large Context 和信息收集两个支撑能力嵌进判断纪律，而不是当外挂 skill。

2. 把差异连接到行动

How 不是动作清单，而是“为什么这个动作能改变这个差异”。

每个关键行动都应说明：

• 它要改变哪个命名差异；
• 它的前提是什么；
• 它可能破坏什么；
• 它失败时下一步如何反应；
• 它完成后有什么可观察变化。

如果一个行动只是“研究更多”“优化设计”“写报告”，必须继续具体化成：读什么、改什么、验证什么、何时停止。

3. 先选路径，再选第一个真实切片

不要试图一次设计完整方案。先选能最大幅度降低不确定性的第一切片。

好的首个真实切片应该：

• 经过真实用户路径或历史可信代理；
• 足够小，能快速暴露路径是否错；
• 包含已知难点，而不是干净玩具输入；
• 能产生下一步反应，而不仅是“看起来能跑”。

4. 区分效果证据和控制面证据

这是跨方法族的普遍纪律，不只限于控制型任务。2026-05-10（效果被 exit 0 / schema pass 污染）和 2026-05-24（效果成功但控制面失败）证明，只要任务有「机制」和「效果」之分，这条就成立。对 Loop、scheduler、agent runtime、cron、workflow 等控制型任务尤其必须分开判断：

• 效果证据：用户可见任务效果是否真的发生；
• 控制面证据：trace、状态文件、receipt、反馈路径、停止条件是否可靠。

真实效果不能自动证明控制面可靠；控制面记录完整也不能自动证明用户效果达成。

5. 让测试决定下一步，而不是装饰结论

验证计划必须提前说清：

• pass 后能前进到哪里；
• partial 时修什么；
• worse 时如何回退或改路径；
• unstable 时增加什么隔离；
• blocked 时缺什么外部条件。

文件存在、schema pass、报告完成、runner exit 0、自我评价、单个正例，都不能直接支持宽泛成功声明。这一条对应 Agent-Task Gap Closure 定理的 Completion Fact 停止谓词：完成是目标状态改变、验收证据、独立检查、残余声明、状态留痕共同成立，不是执行者的文本声明。

判断「够了」用两个判据。一是 satisficing：路径过了预设的多维阈值（可行性、可验证性、副作用可控）就停，不追求最优。二是 DQ 最弱环：把决策质量看成 min(框架, 备选, 信息, 价值, 推理, 承诺) 六环，找出当前最低环，只有最低环不是瓶颈才允许声称 solid（来源 decision_quality AX_01）。两个判据一个防过度搜索，一个防过早收束。

为什么独立检查不可省：Challenger 的举证责任反转（the_challenger_..._nasa/codex_v6 的 AX_32_proof-burden-inversion）说明，当默认是「继续 / 已完成」时，质疑方被要求承担超额举证负担，于是负面证据被系统性降级。这是 IB-05（机制成功冒充任务成功）成为稳定均衡的结构性原因，所以验证的举证方向必须钉死在「凭什么证明它完成了」。

6. 失败声明与完成声明对称：镜像条款 + bad-behavior 桶检查

纪律 5 把举证方向钉在「凭什么证明它完成了」，防的是 false-positive（把没完成说成完成）。但同一个停止谓词必须对称：下「失败 / 未完成 / blocked」结论时，要和下「完成」结论一样接受独立或确定性检查。单一负面信号不构成 blocked，正如单一正面信号不构成 complete。失败声明要问的是「凭什么证明它没完成、是否查过所有路径」。

这条镜像条款来自一次真实失败（2026-05-29）：执行者把外部 agent 的产物判为「静默失败」并据此从零重做，实际产物成功了，只是写到了错误路径、在默认检视面里隐身。失败链是 FAM-J（预检复用失败，IB-22）到 FAM-K（错路径 artifact 隐身，IB-36）到 FAM-F（单视角 closure，IB-29），最后把 IB-05 反向误贴到一个真成功上。根因正是停止谓词只防 false-positive、缺镜像条款。

把 bad-behavior 目录（12 个 FAM 家族，见 adhoc_jobs/llm_harness_kb_20260418/research/bad_behavior/current_integrated_catalog_20260503/）按环节分桶当验证 checklist，不平铺 36 条（平铺会劣化成 rubber-stamp，即 IB-20 自检伪监督）：

每个探针走举证反转措辞，路由给独立 critic，不让执行者自勾（自勾即 IB-20 自检伪监督）。

7. 跨域迁移：先抓骨架，按系统对应迁移，用目标域不变量筛

方法族表给的是「在某个领域内选哪个 family」的广度，不是「把一个领域成功的 How 搬到新领域」的迁移机制。跨域迁移按四步，不要靠表面相似临场凑：

1. 把目标抽成跨域骨架：unknown 的 1-3 词抽象类型加关系结构，而不是表面特征（surfaces_and_essences AX_06 先骨架后表面；卡住时上爬一层类别再回投 AX_22）。
2. 召回其他域解过同型 unknown 的 How 骨架（Pólya look-at-the-unknown）。
3. 按系统对应迁移，不按特征相似：迁的是关系结构的整体映射，不是「看起来像」（mental_leaps AX_03 系统对应优于特征匹配，防「像得快错得快」）。
4. 用目标域的不变量或硬约束筛掉只靠优美成立的迁移：源域成立不蕴涵目标域成立，特例化必须配「回桥」验证（how_to_solve_it specialization-needs-bridge-back）。

边界（means-ends 的适用限度，HPS AX_24）：means-ends 在差异可命名、算子功能可关联的任务上最强；目标不可比较或算子功能未知时，退回方法族表选 architecture_risk / failure_backchain，不要硬套差异缩减。

输出质量标准

一个合格的 What-to-How 产物应满足：

• 读者能区分 What、How、验证和下一步反应。
• 每个核心行动都能回连到一个命名差异或诊断。
• 至少有一个被明确拒绝或延后的替代路径。
• 首个真实切片可以在真实条件或可信历史代理中被执行。
• 声明上限明确，且不会把局部通过说成整体完成。
• 对控制型任务，效果和控制面分开审查。
• 对 messy situation，输出是可修订改进，不是永久解决方案。

常见失败模式

• 标签替代方法：只说“这是架构问题 / Loop 问题 / 策略问题”，但执行方法没有变化。
• 动作清单冒充 How：列了很多任务，却没有解释它们如何改变目标差异。
• 裸适用性陷阱：选择某操作只是因为它能做，而不是因为它能改变当前差异。
• 只倒推不兑现：从终点倒推出很多条件，但没有前向执行切片。
• 玩具验证：测试避开真实难点，只证明流程会跑。
• oracle drift：不断放宽 evaluator / fixture，最后把被放宽后的通过当成改进。
• 控制面污染：真实效果和 trace/state/receipt 混在一起，导致结论过强。
• 永久解 overclaim：对组织、知识迁移或复杂协作问题宣称一劳永逸。
• 模型膨胀：为了建模而建模，没有问题、风险和停止条件。

与相邻 skill 的边界

• 需求不清：先用 workflow_requirement_decomposition_core。
• 测试 case 不清：用 workflow_real_task_test_case_design。
• 证据强度和 closure 不清：用 workflow_solid_decision_review。
• 多轮执行、任务拆分、review 或调度：用 workflow_controller_loop。

本 skill 的职责只是在“目标状态已经足够清楚，但路径还不清楚”的时刻，提供从目标到行动的思考桥。