企业官网建设流程全解析

基于结果导向执行原则：以可验证终点驱动重写与迁移

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

pstack 的Outcome-Oriented Execution（结果导向执行）原则用于规划和执行带显式阶段边界的大型重写与迁移：优先保证目标架构的完整性，而不是保留过渡阶段的平滑状态。本指南将拆解该原则的适用条件、核心规则、护栏及底层支撑，并结合 pstack 仓库中的原则索引、配套 playbook 与源码级引用，说明如何在真实工程中落地这一原则。

原则概览

原则文件位于 pstack/skills/principle-outcome-oriented-execution/SKILL.md，其核心主张是：

Optimize for the intended, verifiable end state rather than preserving smooth intermediate states.

即在规划的重写与迁移中，把优化目标放在最终可验证的端状态上，而不是保留平滑的中间状态。

为什么：避免临时兼容代码变成长命债务

• 追求每个中间步骤都完全稳定，往往会引入临时兼容代码，而这些代码最终会沉淀为长期债务。
• 因此应收敛到目标架构，并在显式的验证边界上证明正确性。

核心规则

• 优先保证端状态完整性，而非过渡稳定性
• 中间状态的破坏是可接受的，前提是有计划、有范围、可逆
• 在声明完成前，始终运行最终验证

护栏

• 仅用于带显式阶段边界的重写与迁移
• 明确声明临时破坏可接受的区域
• 迁移过程中，对正在被改动的地方保持高信号检查
• 计划完成时，要求完整的静态与运行时验证

适用场景：何时启用该原则

该原则专门用于有显式阶段边界的重写与迁移，典型的应用场景包括：

• 大规模重构（refactoring）：行为不变、仅调整结构与形状的改动，参见 refactoring playbook；
• 架构迁移（migration）：从旧架构过渡到新架构；
• 遗留 API 替换：移除旧 API、让调用方迁移到新 API；
• 多阶段（multi-phase）计划：跨阶段或跨 PR 的工作，参见 multi-phase plan playbook；
• 长期自动化运行（autonomous run）：长时间无人值守的任务，参见 autonomous run playbook。

在该原则下，改动具有以下特征：

• 有计划：阶段边界是预先声明的，而不是事后补救；
• 有范围：临时破坏限定在声明的区域内，不扩散到无关模块；
• 可逆：任何中间破坏都可以回退，不会造成不可恢复的损失。

原则落地：从声明到执行的完整工作流

将该原则接入实际工作，分为三个层面：

1. 触发：让模式读取原则索引

pstack 的入口技能 poteto-mode/SKILL.md 在任务开始时读取原则索引，将 Outcome-Oriented Execution 归类为Core（核心）原则，并说明其适用范围：

Outcome-Oriented Execution（principle-outcome-oriented-execution）。Planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture, don't preserve throwaway compatibility states.

即：当任务属于重写或迁移、且具有显式阶段边界时，该原则自动触发。

2. 执行：以阶段边界组织改动

• 每个阶段结束于可验证的状态：这是 principle-sequence-verifiable-units 的配套实践——把工作拆成每个都以可检查状态结束的小单元，前一个单元变绿后再推进；
• 在阶段边界重写检查点：对于代码耦合的工作（一个功能、一个迁移），单一 owner 内联设置检查点，并在阶段边界重写，参见 feature playbook；
• 始终运行最终验证：在计划完成时执行完整的静态与运行时验证，见下文“验证”一节。

3. 验证：证明它真的工作

结果导向执行要求“证明最终状态正确”，而非“看起来不错”。pstack 的验证原则体系为此提供了完整支撑：

• principle-prove-it-works：针对真实产物验证（运行功能、读取真实值、检查 diff），而不是依赖代理、自我报告或“它能编译”；
• principle-test-behavior-not-implementation：用调用方的方式调用代码，并断言字面预期值；
• principle-sequence-verifiable-units：每个小单元结束于可检查的状态，红转绿逐单元推进，而不是最后统一批量验证。

验证的原则是“针对真实产物，而非代理”。其可操作化方法包括：

• 构建（必要但不充分）
• 运行并实际走通功能路径
• 检查完整链路：数据是否从输入流到输出
• 端到端测试：集成场景走通完整通信路径
• 脚本化验证：把检查写成可重复运行的脚本，保留输出作为审查者可重跑的产物，参见 show-me-your-work。

与其他原则的协同

结果导向执行并非孤立原则，它与其他原则形成互补：

配套原则：Migrate Callers Then Delete Legacy APIs

与结果导向执行最直接相关的配套原则是 principle-migrate-callers-then-delete-legacy-apis，它明确反对保留兼容层：

Rule:Do not keep legacy API paths only because internal callers still exist. Inventory callers, migrate them, and delete the old API immediately. Treat temporary adapters as exceptional and time-boxed, not default architecture. Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details.

适用条件包括：没有外部用户依赖向后兼容、项目能吸收协调的破坏性变更、新 API 是简化或重构计划的一部分。它警告说，同时保留新旧 API 会制造双路径复杂度，拖慢清理，让代码库看起来像“只增不减”。

审查侧的反向验证

interrogate 的评审标准（references/rubric.md）从审查者角度反向验证该原则的执行质量：

Legacy dual-paths: does the change introduce a new API while keeping the old one alive? If there are no external consumers, migrate callers and delete the old path in the same wave. Don't leave compatibility layers that will become permanent.

以及：

Obsolete compatibility paths kept alive for transitional stability that's no longer needed. If the migration is done, delete the scaffolding.

这从反面印证了结果导向执行的核心主张：为过渡稳定性保留的兼容路径，一旦不再需要，就应该删除。

架构师技能的联动

在 architect/SKILL.md 的 Phase D（Implement against the sketch）中，明确引用了结果导向执行原则：

The synthesis can ship as its own commit either way, as the "scaffold first" mode of thefoundational-thinkingprinciple skill. Planned and scoped breakage during fill-in is fine, per theoutcome-oriented-executionprinciple skill.

也就是说，在填写实现阶段，有计划、有范围的破坏是被明确允许的。这直接呼应了结果导向执行原则中“中间状态的破坏是有计划、有范围、可逆时可接受”的核心规则。

如何在实践中使用该原则

通过 /poteto-mode 使用

日常使用中，不需要手动引用该原则。启动任务时输入：

/poteto-mode 迁移所有调用方从同步存储到新的异步存储，保持行为一致。我回来时要信任它是正确的。

poteto-mode 会读取原则索引，将任务匹配到相应的 playbook，并在需要时自动应用结果导向执行原则。每个阶段边界都会有明确的检查点。

通过原则名称定向控制

如果想显式控制，可以在提示中直接说出原则名称：

在迁移中应用 outcome oriented execution。不要保留临时兼容层，直接收敛到目标架构，并在每个阶段边界做验证。

一个原则引用如果没有对应的决策变化，就是“点名”而不是“应用”。

文档中的对应描述

08-principles.md 对结果导向执行原则给出了精炼的定义：

Outcome-Oriented Execution converges rewrites on the target design instead of preserving throwaway compatibility states.

反模式与注意事项

以下做法与该原则相悖，应避免：

• 为平滑中间状态保留临时兼容代码：这些代码会变成长命债务；
• 同时保留新旧双路径：制造双路径复杂度，拖慢清理（参见 interrogate rubric）；
• 只保留旧 API 因为内部调用方还在：应盘点调用方、迁移、然后立即删除旧 API；
• 声明完成前跳过最终验证：该原则明确要求“在声明完成前始终运行最终验证”；
• 超出声明区域的临时破坏：中间破坏只有在计划、有范围、可逆的前提下才可接受。

小结

结果导向执行原则的核心信息是：在规划的重写与迁移中，优先保证目标架构的完整性与最终可验证性，而不是保留过渡阶段的平滑状态。通过显式阶段边界、有计划有范围可逆的临时破坏，以及最终完整的静态与运行时验证，你可以避免临时兼容代码沉淀为长期债务，让代码库收敛到目标架构。

该原则是 pstack 的 23 条原则之一，被归类为Core原则，在 poteto-mode 的原则索引中声明。与 sequence-verifiable-units、prove-it-works、migrate-callers-then-delete-legacy-apis 等配套原则协同，形成了“收敛到目标架构 + 逐单元验证 + 不留兼容层”的完整闭环。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins