mcpField
P
Preserving Productive Tensions

Preserving Productive Tensions

github.com/obra开发756505 次安装54 周前更新
代码仓库

关于 Preserving Productive Tensions

Preserving Productive Tensions 是一项开发技能，用于判断何时应保留有效的权衡选项，而非强行择一。它介绍通过配置、并行实现或明确文档来保留依赖情境的优先级，并提供必要时解决分歧的判断标准。

主要功能

  1. 01识别有效的相互竞争优先级
  2. 02通过配置保留选项
  3. 03维护并行实现
  4. 04记录尚未解决的权衡
  5. 05判断何时需要做出取舍

适用场景

  1. 01支持优先级不同的部署场景
  2. 02记录有意保留的架构权衡
  3. 03判断不同方案是否应并存

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/obra/superpowers-skills --skill preserving-productive-tensions

安装后在 Claude Code 中输入/preserving-productive-tensions确认已加载。

详细介绍

保留有价值的张力

概述

有些张力不是需要解决的问题，而是值得保留的宝贵信息。当多种方法在不同情境下都确实有效时，强行做出选择会破坏灵活性。

核心原则： 保留能够体现情境依赖性的张力。只有在必要时才强行解决。

识别有价值的张力

出现以下情况时，张力是有价值的：

  • 两种方法各自优化不同但合理的优先事项（成本与延迟、简单性与功能）
  • “更好”的选择取决于部署情境，而非技术优劣
  • 不同用户／部署会做出不同选择
  • 权衡确实存在，不会因巧妙的工程设计而消失
  • 利益相关者各自有合理但相互冲突的顾虑

出现以下情况时，需要解决张力：

  • 同时保留两种方法的实施成本高得难以承受
  • 两种方法存在根本冲突（无法共存）
  • 针对这个特定用例，一种方法在技术上明显更优
  • 这是一个单向门（选择会锁定架构）
  • 同时保留两种方法只会增加复杂性，却没有价值

保留模式

模式 1：配置

将选择设为可配置项，而不是固化到架构中：

class Config:
    mode: Literal["optimize_cost", "optimize_latency"]
    # Each mode gets clean, simple implementation

适用情况： 两种方法在架构上兼容，切换属于运行时决策

模式 2：并行实现

将两种方法分别维护为独立、清晰的模块，并共用同一契约：

# processor/batch.py - optimizes for cost
# processor/stream.py - optimizes for latency
# Both implement: def process(data) -> Result

适用情况： 两种方法差异显著，但共用同一接口

模式 3：记录权衡

在文档／决策记录中明确记录这种张力：

## Unresolved Tension: Authentication Strategy

**Option A: JWT** - Stateless, scales easily, but token revocation is hard
**Option B: Sessions** - Easy revocation, but requires shared state

**Why unresolved:** Different deployments need different trade-offs
**Decision deferred to:** Deployment configuration
**Review trigger:** If 80% of deployments choose one option

适用情况： 无法在代码中同时保留两种方法，但需要记录这个选择是经过深思熟虑的

危险信号——你正在强行解决张力

  • 在两种方法都合理时，还在问“哪种最好？”
  • 不解释原因就说“我们必须选一种”
  • 根据个人偏好而非用户情境做选择
  • 为了“推进进度”而消除张力，尽管保留张力本身就是进展
  • 在多样性有价值时强行达成共识

出现以上任何一种情况都意味着：停下来，考虑保留这种张力。

何时强行做出选择

以下情况，你应该强行做出选择：

  1. 实施成本高得难以承受

    • 同时构建／维护两种方法会显著拖慢开发
    • 团队没有足够资源并行采用两种方法

  2. 根本冲突

    • 两种方法基于互相矛盾的架构假设
    • 无法清晰地分离关注点

  3. 技术上明显更优

    • 针对这个特定情境，一种方法在客观上更好
    • 不是“我更喜欢 X”，而是“X 能满足我们的约束，Y 不能”

  4. 单向门

    • 选择会使我们锁定在某种架构中
    • 在不同选项间迁移的成本会很高

  5. 简单性要求做出选择

    • 同时保留两种方法确实会增加复杂性
    • YAGNI：如果我们只需要一种，就不要构建两种

明确询问：“我应该选一种，还是将两种都作为选项保留？”

文档格式

保留张力时，请清晰记录：

## Tension: [Name]

**Context:** [Why this tension exists]

**Option A:** [Approach]
- Optimizes for: [Priority]
- Trade-off: [Cost]
- Best when: [Context]

**Option B:** [Approach]
- Optimizes for: [Different priority]
- Trade-off: [Different cost]
- Best when: [Different context]

**Preservation strategy:** [Configuration/Parallel/Documented]

**Resolution trigger:** [Conditions that would force choosing one]

示例

有价值的张力（保留）

“我们应该优化成本还是延迟？”

  • 答案： 将其设为可配置项——不同部署需要不同的权衡
技术决策（解决）

“我们应该使用 SSE 还是 WebSockets？”

  • 答案： SSE——我们只需要单向通信，实现也更简单
业务决策（暂缓）

“我们应该支持离线模式吗？”

  • 答案： 不要两者都保留——请利益相关者根据用户需求做出决定

请记住

  • 合理优先事项之间的张力是特性，而非缺陷
  • 过早达成共识会破坏宝贵的灵活性
  • 在合理的情况下，配置优于强行选择
  • 明确记录权衡
  • 有充分理由时，解决张力也没问题

评论

支持 Markdown