Back to Details

problem-space

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/problem-space

/problem-space

Map the terrain where solutions live. What are we optimizing? What constraints do we treat as real? Which constraints can be questioned?
Problem space exploration precedes solution space. Understanding the terrain is the work. Jump to code too early and you'll build the wrong thing fast.
梳理解决方案所处的“地形”。我们要优化的是什么？哪些约束是我们视为既定条件的？哪些约束是可以被质疑的？
问题空间探索要先于解决方案空间探索。理解所处的“地形”是关键工作。过早投入编码会让你快速构建出错误的产物。

When to Use

适用场景

Invoke 
/problem-space
when:
  • Starting new work - Before jumping to implementation, understand what you're actually solving
  • Hitting repeated blockers - The same problems keep appearing in different forms
  • Patches accumulating - Third config flag for the same bug signals you're treating symptoms
  • Estimates feel off - When time estimates are wrong by an order of magnitude, the problem isn't understood
  • Agent is talking itself out of constraints - "For this prototype we don't have time" when the constraint matters
Do not use when: The problem is well-understood and you're already in execution. Problem space is for grounding, not for stalling.
在以下场景中调用
/problem-space
：
  • 启动新工作时 - 在着手实现之前，先明确你实际要解决的问题
  • 遇到重复阻碍时 - 相同的问题以不同形式反复出现
  • 补丁不断堆积时 - 针对同一个bug添加第三个配置标志，说明你只是在处理症状而非根源
  • 预估偏差较大时 - 当时间预估与实际相差一个数量级，说明问题还未被理解
  • Agent试图规避约束时 - 当约束至关重要时，却出现“这个原型我们没时间做”的说法
不适用场景： 问题已被充分理解，且已进入执行阶段。问题空间梳理是为了明确方向，而非拖延。

The Problem Space Process

问题空间梳理流程

Step 1: State the Objective Function

步骤1：明确目标函数

What are we actually optimizing? Not the feature, the outcome.
"We are optimizing for [outcome]."
Be precise. "Build a login page" is a feature. "Reduce time-to-first-value for new users" is an objective. The aim IS the abstraction.
Ask:
  • What change in behavior would indicate success?
  • What metric would move if this worked?
  • What problem disappears if we get this right?
我们实际要优化的是什么？不是功能，而是结果。
“我们正在为[结果]进行优化。”
要精准表述。“构建登录页面”是一个功能，“缩短新用户的首次价值获取时间”是一个目标。目标是一种抽象概括。
可以问自己：
  • 什么样的行为变化能表明成功？
  • 如果这个目标达成，哪个指标会发生变化？
  • 如果我们做对了，哪个问题会消失？

Step 2: Map the Constraints

步骤2：梳理约束条件

List what we're treating as fixed. Be explicit about each constraint's nature:
Constraint: [the boundary]
Type: [hard | soft | assumed]
Reason: [why it exists]
Questioning: [could this be false?]
Hard constraints - Physics, regulations, signed contracts. These don't bend.
Soft constraints - Organizational decisions, technical debt, time pressure. These can be negotiated.
Assumed constraints - "We've always done it this way." These should be questioned.
The trap: Agents will talk themselves out of constraints. "For this prototype we don't have time" is often false when code generation takes 15 minutes, not a week. Ground yourself in what's actually fixed.
列出我们视为固定不变的条件，并明确每个约束的性质：
Constraint: [边界内容]
Type: [hard | soft | assumed]
Reason: [存在的原因]
Questioning: [这个约束是否可能不成立？]
Hard constraints（刚性约束） - 物理规律、法规要求、已签署的合同。这些无法变通。
Soft constraints（柔性约束） - 组织决策、技术债务、时间压力。这些可以协商调整。
Assumed constraints（假设性约束） - “我们一直都是这么做的”。这类约束应该被质疑。
陷阱：Agent会试图规避约束。比如“这个原型我们没时间做”，但实际上代码生成只需要15分钟而非一周，这种说法往往不成立。要立足于实际固定的条件。

Step 3: Identify the Terrain

步骤3：明确“地形”范围

Where do solutions live? Map the space:
  • What systems are involved? - Existing code, external APIs, data stores
  • Who is affected? - Users, operators, downstream systems
  • What's the blast radius? - If this goes wrong, what breaks?
  • What precedents exist? - Has this been solved before? Where?
解决方案存在于哪些范围？梳理如下：
  • 涉及的系统有哪些？ - 现有代码、外部API、数据存储
  • 受影响的对象是谁？ - 用户、运维人员、下游系统
  • 影响范围有多大？ - 如果出问题，哪些部分会受影响？
  • 是否有先例？ - 这个问题之前是否被解决过？在哪里？

Step 4: Surface Hidden Assumptions

步骤4：挖掘隐藏假设

Every problem statement has embedded assumptions. Make them visible:
"We assume [assumption]. If this is false, [consequence]."
Common hidden assumptions:
  • The current architecture must be preserved
  • The feature set is fixed
  • The timeline can't change
  • Users want what they asked for (not what they need)
每个问题陈述都包含隐含假设。要将它们明确出来：
“我们假设[假设内容]。如果这个假设不成立，会导致[后果]。”
常见的隐藏假设：
  • 当前架构必须保留
  • 功能集是固定的
  • 时间线无法更改
  • 用户想要的就是他们所要求的（而非他们实际需要的）

Step 5: Check for X-Y Problems

步骤5：检查X-Y问题

Are we solving the real problem (X) or the user's attempted solution (Y)?
Signs of X-Y mismatch:
  • Request is oddly specific for a simple goal
  • You're building something that feels like a workaround
  • "How do I do [technique]" without explaining why
If potential X-Y problem detected:
"The user asked for [Y], but the underlying need might be [X]."
我们是在解决真实问题（X），还是用户尝试的解决方案（Y）？
X-Y不匹配的迹象：
  • 针对简单目标的请求异常具体
  • 你正在构建的东西感觉像是一种权宜之计
  • 用户只问“如何实现[技术]”却不解释原因
如果检测到潜在的X-Y问题：
“用户要求的是[Y]，但潜在需求可能是[X]。”

Output Format

输出格式

Always produce a problem space map in this structure:
undefined
请始终按照以下结构生成问题空间图谱：
undefined

Problem Space Map

Problem Space Map

Date: [timestamp] Scope: [what area this covers]
Date: [时间戳] Scope: [覆盖范围]

Objective

Objective

[What we're optimizing for - the outcome, not the feature]
[我们要优化的目标——是结果而非功能]

Constraints

Constraints

ConstraintTypeReasonQuestion?
[boundary]hard/soft/assumed[why][could this be false?]
ConstraintTypeReasonQuestion?
[边界内容]hard/soft/assumed[原因][这个约束是否可能不成立？]

Terrain

Terrain

  • Systems: [what's involved]
  • Stakeholders: [who's affected]
  • Blast radius: [what breaks if wrong]
  • Precedents: [existing solutions to examine]
  • Systems: [涉及的系统]
  • Stakeholders: [受影响的对象]
  • Blast radius: [出问题时受影响的部分]
  • Precedents: [可参考的现有解决方案]

Assumptions Made Explicit

Assumptions Made Explicit

  1. [assumption] - if false: [consequence]
  2. [assumption] - if false: [consequence]
  1. [假设内容] - 如果不成立：[后果]
  2. [假设内容] - 如果不成立：[后果]

X-Y Check

X-Y Check

  • Stated need (Y): [what was asked for]
  • Underlying need (X): [what might actually be needed]
  • Confidence: [high/medium/low that Y=X]
  • Stated need (Y): [用户提出的需求]
  • Underlying need (X): [实际潜在需求]
  • Confidence: [Y与X匹配的置信度：高/中/低]

Ready for Solution Space?

Ready for Solution Space?

[yes/no] - [why or what's missing]
undefined
[是/否] - [原因或缺失的信息]
undefined

Examples

示例

Example 1: Repeated Deployment Failures

示例1：重复部署失败

/problem-space

Deployments keep failing. We've added 3 config flags in the last month
and each one "fixes" something but creates new edge cases.
Output:
undefined
/problem-space

部署持续失败。我们在过去一个月里添加了3个配置标志，
每个标志都“修复”了一些问题，但又引发了新的边缘情况。
输出：
undefined

Problem Space Map

Problem Space Map

Date: 2024-01-15 Scope: Deployment pipeline reliability
Date: 2024-01-15 Scope: 部署流水线可靠性

Objective

Objective

We are optimizing for: Reliable deployments that succeed without manual intervention.
我们正在优化的目标：无需人工干预即可成功完成的可靠部署。

Constraints

Constraints

ConstraintTypeReasonQuestion?
Must use existing CI/CDsoftTeam familiarityCould we evaluate alternatives?
Zero-downtime requiredhardSLA commitmentNo
Config managed in repoassumed"Best practice"Could config live elsewhere?
Current rollback approachsoftBuilt incrementallyIs this the right rollback model?
ConstraintTypeReasonQuestion?
必须使用现有CI/CDsoft团队熟悉度我们可以评估替代方案吗？
必须实现零停机hardSLA承诺否
配置在代码库中管理assumed“最佳实践”配置可以放在其他地方吗？
当前的回滚方式soft逐步构建而成这是正确的回滚模型吗？

Terrain

Terrain

  • Systems: GitHub Actions, Kubernetes, ArgoCD, 3 microservices
  • Stakeholders: Dev team, SRE, downstream API consumers
  • Blast radius: Customer-facing outage, 200+ API consumers
  • Precedents: Similar system at [X] uses feature flags instead of config
  • Systems: GitHub Actions, Kubernetes, ArgoCD, 3个微服务
  • Stakeholders: 开发团队、SRE、下游API消费者
  • Blast radius: 面向客户的停机、200+ API消费者受影响
  • Precedents: [X]的类似系统使用功能标志而非配置，效果良好

Assumptions Made Explicit

Assumptions Made Explicit

  1. Config flags are the right mechanism for deployment variation - if false: we need environment-aware builds
  2. Failures are config-related - if false: we have an architecture problem
  1. 配置标志是处理部署差异的正确机制 - 如果不成立：我们需要支持环境感知的构建
  2. 失败是由配置问题导致的 - 如果不成立：我们存在架构问题

X-Y Check

X-Y Check

  • Stated need (Y): Fix deployment config issues
  • Underlying need (X): Make deployments reliable
  • Confidence: Medium - config is a symptom, not the disease
  • Stated need (Y): 修复部署配置问题
  • Underlying need (X): 实现可靠部署
  • Confidence: 中 - 配置只是症状，而非根源问题

Ready for Solution Space?

Ready for Solution Space?

No - Need to understand if this is a band-aid problem (more config) or a redesign problem (change how deployments work).
undefined
否 - 需要明确这是一个用更多配置来临时解决的问题，还是需要重新设计部署方式的问题。
undefined

Example 2: Performance Degradation

示例2：性能下降

/problem-space

App is slow. PM wants us to "optimize the database queries."
Output:
undefined
/problem-space

应用运行缓慢。产品经理要求我们“优化数据库查询”。
输出：
undefined

Problem Space Map

Problem Space Map

Date: 2024-01-15 Scope: Application performance
Date: 2024-01-15 Scope: 应用性能

Objective

Objective

We are optimizing for: Page load time under 2 seconds for 95th percentile users.
我们正在优化的目标：95%分位用户的页面加载时间低于2秒。

Constraints

Constraints

ConstraintTypeReasonQuestion?
Must use current databaseassumed"Migration too expensive"Have we actually costed this?
Can't change API contractssoftDownstream consumersHow many consumers actually use slow endpoints?
Feature set is fixedassumedPM specifiedWhat if we removed/simplified features?
ConstraintTypeReasonQuestion?
必须使用当前数据库assumed“迁移成本太高”我们实际核算过成本吗？
不能更改API契约soft下游消费者依赖有多少消费者实际使用那些缓慢的端点？
功能集固定assumed产品经理指定如果我们移除/简化某些功能会怎样？

Terrain

Terrain

  • Systems: PostgreSQL, Redis cache, React frontend, Node backend
  • Stakeholders: End users, mobile clients, third-party integrations
  • Blast radius: User churn, support tickets, competitor migration
  • Precedents: Similar app moved to read replicas, saw 3x improvement
  • Systems: PostgreSQL, Redis缓存, React前端, Node后端
  • Stakeholders: 终端用户、移动客户端、第三方集成
  • Blast radius: 用户流失、支持工单增加、用户转向竞争对手
  • Precedents: 类似应用迁移到只读副本后，性能提升了3倍

Assumptions Made Explicit

Assumptions Made Explicit

  1. Database queries are the bottleneck - if false: frontend rendering or network latency is the issue
  2. Optimization is cheaper than redesign - if false: N+1 queries need architectural change
  3. Current feature set is needed - if false: could eliminate unused expensive features
  1. 数据库查询是性能瓶颈 - 如果不成立：前端渲染或网络延迟才是问题所在
  2. 优化比重新设计成本更低 - 如果不成立：N+1查询需要架构变更
  3. 当前功能集是必需的 - 如果不成立：可以移除未使用的高成本功能

X-Y Check

X-Y Check

  • Stated need (Y): Optimize database queries
  • Underlying need (X): Make app feel fast to users
  • Confidence: Low - PM prescribed solution without diagnosis
  • Stated need (Y): 优化数据库查询
  • Underlying need (X): 让用户觉得应用运行流畅
  • Confidence: 低 - 产品经理未经过诊断就指定了解决方案

Ready for Solution Space?

Ready for Solution Space?

No - Need performance profiling to identify actual bottleneck before optimizing anything.
undefined
否 - 需要先进行性能分析，确定实际瓶颈后再进行优化。
undefined

Session Persistence

会话持久化

This skill can persist context to 
.oh/<session>.md
for use by subsequent skills.
If session name provided (
/problem-space auth-refactor
):
  • Reads/writes 
    .oh/auth-refactor.md
    directly
If no session name provided (
/problem-space
):
  • After producing the problem space map, offer to save it:
    "Save to session? [suggested-name] [custom] [skip]"
  • Suggest a name based on git branch or the exploration topic
Reading: Check for existing session file. Read prior skill outputs—especially Aim and Problem Statement—to ground the exploration.
Writing: After producing output, write the problem space map to the session file:
markdown
undefined
该技能可以将上下文持久化到
.oh/<session>.md
，供后续技能使用。
如果提供了会话名称（如
/problem-space auth-refactor
）：
  • 直接读写
    .oh/auth-refactor.md
如果未提供会话名称（如
/problem-space
）：
  • 生成问题空间图谱后，会询问是否保存：
    “保存到会话？[建议名称] [自定义] [跳过]”
  • 根据git分支或探索主题建议一个名称
读取： 检查是否存在现有会话文件。读取之前的技能输出——尤其是Aim和Problem Statement——来为探索提供依据。
写入： 生成输出后，将问题空间图谱写入会话文件：
markdown
undefined

Problem Space

Problem Space

Updated: <timestamp>
[problem space map content]
undefined
Updated: <时间戳>
[问题空间图谱内容]
undefined

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础技能（仅提示）

Works anywhere. Produces problem space map through questioning. No persistence.
可在任何场景使用。通过提问生成问题空间图谱。无持久化功能。

With .oh/ session file

配合.oh/会话文件使用

  • Reads 
    .oh/<session>.md
    for prior context (aim, problem statement)
  • Writes problem space map to the session file
  • Subsequent skills can read constraints and terrain
  • 读取
    .oh/<session>.md
    获取之前的上下文（目标、问题陈述）
  • 将问题空间图谱写入会话文件
  • 后续技能可以读取约束条件和“地形”信息

With Open Horizons MCP

配合Open Horizons MCP使用

  • Queries graph for related past decisions and their outcomes
  • Pulls relevant tribal knowledge about similar problem spaces
  • Retrieves guardrails that apply to this domain
  • Session file serves as local cache
  • 查询图谱获取相关的过往决策及其结果
  • 提取与类似问题空间相关的隐性知识
  • 获取适用于该领域的指导原则
  • 会话文件作为本地缓存

Position in Framework

在框架中的位置

Comes after: 
/aim
(you need to know your destination before mapping the terrain). Leads to: 
/problem-statement
to frame the specific challenge, or 
/solution-space
if already well-framed. Can loop back from: 
/salvage
(constraints were wrong), 
/review
(keeps hitting same blockers).
前置技能： 
/aim
（在梳理“地形”之前，你需要知道目标方向）。 后续技能： 
/problem-statement
（明确具体挑战），如果问题已明确，则进入
/solution-space
。 可回溯场景： 
/salvage
（约束条件错误）、
/review
（反复遇到相同阻碍）。

Leads To

后续方向

After problem space mapping, typically:
  • /problem-statement
    - Crisp articulation of what needs solving
  • /solution-space
    - Explore candidate implementations
  • Return to stakeholders - If constraints need challenging
  • Research/investigation - If terrain is insufficiently understood
Remember: Problem space is not about delay. It's about building the right thing. The constraint is alignment, not delivery. When execution is cheap, understanding is the leverage.
完成问题空间梳理后，通常可以：
  • /problem-statement
    - 清晰表述需要解决的问题
  • /solution-space
    - 探索候选实现方案
  • 反馈给利益相关者 - 如果需要质疑约束条件
  • 研究/调查 - 如果“地形”信息不够充分
记住： 问题空间梳理不是为了拖延。而是为了构建正确的产物。约束条件是对齐方向，而非交付。当执行成本低廉时，理解问题就是最大的杠杆。