problem-statement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/problem-statement

Define the framing. Change the statement, change the solution space.

A problem statement is not the problem itself—it's the lens through which you see the problem. Different framings open different solution spaces. The right framing makes good solutions obvious; the wrong framing makes them invisible.

定义问题框架。改变问题陈述，就能改变解决方案的范围。

问题陈述并非问题本身——它是你审视问题的视角。不同的框架会开启不同的解决方案范围。正确的框架会让优质解决方案清晰可见；错误的框架则会让它们隐而不现。

When to Use

适用场景

Invoke

/problem-statement

when:

Starting new work - Before diving into solutions, articulate what you're actually solving
Solutions feel off - When proposed solutions seem convoluted or like workarounds
Oscillating on approach - When you keep changing direction, the framing might be wrong
Suspected X-Y problem - When someone asks for a specific solution but the underlying need is unclear
Requirements keep expanding - Scope creep often signals a framing mismatch
After
/aim
but before
/solution-space
- The natural sequence: aim defines outcome, problem statement frames the challenge

Do not use when: You already have a crisp problem statement and are ready to explore solutions. Move to

/solution-space

在以下场景中调用

/problem-statement

：

启动新工作时 - 在投入解决方案之前，明确你实际要解决的问题
解决方案感觉不对劲时 - 当提出的解决方案显得复杂或像是权宜之计
方法摇摆不定时 - 当你不断改变方向，可能是框架出了问题
怀疑存在X-Y问题时 - 当有人要求特定解决方案，但背后的真实需求不明确
需求持续扩张时 - 范围蔓延通常表明框架不匹配
在
/aim
之后、
/solution-space
之前 - 合理流程：aim定义目标，问题陈述框定挑战

请勿在以下场景使用：你已经有清晰的问题陈述，准备好探索解决方案。此时应转向

/solution-space

。

The Framing Process

框架搭建流程

Step 1: Surface the Current Framing

步骤1：梳理当前框架

Before reframing, understand how the problem is currently being seen:

"The problem is currently framed as: [how it's being described]"

Capture:

What's the stated problem?
What assumptions are embedded in how it's described?
What's being treated as fixed vs. changeable?

在重构框架之前，先理解当前问题的审视方式：

"当前问题框架为：[当前的描述方式]"

记录以下内容：

明确提出的问题是什么？
描述中隐含了哪些假设？
哪些内容被视为固定不变，哪些可以调整？

Step 2: Detect X-Y Problems

步骤2：识别X-Y问题

Watch for the X-Y problem pattern: someone asks for Y (their attempted solution) when they actually need X (the real problem).

Signs of X-Y mismatch:

Request is oddly specific for what seems like a simple goal
The solution feels like a workaround
"How do I do [technique]?" without explaining why
Convoluted multi-step approach to something that should be simple

If X-Y problem detected:

"You're asking for [Y], but the underlying need seems to be [X]. Is that right? If so, we should reframe around [X]."

留意X-Y问题模式：有人想要Y（他们尝试的解决方案），但实际需要的是X（真实问题）。

X-Y不匹配的迹象：

对于看似简单的目标，请求异常具体
解决方案感觉像是权宜之计
只问“如何实现[技术]？”却不解释原因
用复杂的多步骤方法解决本应简单的问题

若检测到X-Y问题：

"你当前请求的是[Y]，但背后的真实需求似乎是[X]。是否正确？若是，我们应围绕[X]重构框架。"

Step 3: Separate WHAT from HOW

步骤3：区分“是什么”与“怎么做”

A good problem statement articulates WHAT needs to change, not HOW to change it.

Wrong: "We need to add a caching layer to reduce latency" Right: "Page loads take 3+ seconds; users abandon before content appears"

Wrong: "We need to refactor the auth module" Right: "Adding a new auth provider takes 2 weeks and touches 6 files"

Test your statement:

Does it describe a symptom or a solution?
Could someone unfamiliar with the codebase understand what's wrong?
Does it leave room for multiple solution approaches?

好的问题陈述应明确“需要改变什么”，而非“如何改变”。

错误示例："我们需要添加缓存层以降低延迟" 正确示例："页面加载时间超过3秒；用户在内容加载完成前就已离开"

错误示例："我们需要重构认证模块" 正确示例："添加新的认证提供商需要耗时2周，且要修改6个文件"

测试你的陈述：

它描述的是症状还是解决方案？
不熟悉代码库的人能否理解问题所在？
它是否为多种解决方案留有余地？

Step 4: Identify Constraints and Flexibility

步骤4：识别约束与可调整空间

Every problem exists within constraints. Name them explicitly:

Hard constraints (actually immovable):

Regulatory requirements
Laws of physics
Existing user commitments

Soft constraints (feel fixed but aren't):

"We've always done it this way"
Technical debt
Team preferences

Questions to surface flexibility:

What would we do if [constraint] didn't exist?
Who decided [constraint] was fixed? Can we revisit?
What's the cost of violating [constraint] vs. the cost of keeping it?

每个问题都存在于一定的约束条件中。请明确列出：

硬约束（确实无法改变）：

监管要求
物理定律
对现有用户的承诺

软约束（看似固定但实际可调整）：

"我们一直都是这么做的"
技术债务
团队偏好

挖掘可调整空间的问题：

如果[约束]不存在，我们会怎么做？
是谁决定[约束]不可改变？我们能否重新讨论？
违反[约束]的成本与维持它的成本相比如何？

Step 5: Craft the Problem Statement

步骤5：撰写问题陈述

Structure: [Who] needs [what outcome] because [why it matters], but currently [what's blocking].

Good problem statements are:

Crisp - One or two sentences, not a paragraph
Outcome-focused - Describes the desired state, not the current mess
Testable - You'll know when it's solved
Solution-agnostic - Leaves room to explore approaches

Examples:

Bad	Good
"The API is slow"	"API responses take 800ms; our SLA requires 200ms"
"We need microservices"	"Deploying a fix requires coordinating 4 teams and takes 2 weeks"
"Users don't understand the UI"	"40% of support tickets are 'how do I X' where X is a core feature"
"We need better tests"	"Last 3 production incidents were caught by users, not tests"

结构：[谁]需要[什么结果]，因为[重要性]，但目前[阻碍因素]。

优质问题陈述具备以下特点：

简洁 - 1-2句话，而非段落
聚焦结果 - 描述理想状态，而非当前的混乱
可验证 - 你能明确判断问题是否已解决
不绑定解决方案 - 为探索多种方法留有余地

示例：

错误示例	正确示例
"API速度慢"	"API响应时间为800ms；我们的SLA要求是200ms"
"我们需要微服务"	"部署一个修复需要协调4个团队，耗时2周"
"用户不理解UI"	"40%的支持工单是‘如何操作X’，其中X是核心功能"
"我们需要更好的测试"	"最近3次生产事故都是用户发现的，而非测试发现的"

Step 6: Validate the Framing

步骤6：验证框架

Before committing to a problem statement, test it:

State it to someone else - If they immediately suggest a solution, the framing is too narrow
Invert it - What would the world look like if this problem didn't exist?
Zoom out - Is this a symptom of a larger problem?
Zoom in - Is this actually multiple problems masquerading as one?

在确定问题陈述之前，进行测试：

向他人陈述 - 如果对方立刻提出解决方案，说明框架过于狭窄
反向思考 - 如果这个问题不存在，世界会是什么样子？
放大视角 - 这是否是更大问题的症状？
缩小视角 - 这是否是多个问题伪装成一个问题？

Output Format

输出格式

Produce a problem statement in this structure:

undefined

请按照以下结构生成问题陈述：

undefined

Problem Statement

Current framing: [How the problem is currently being described]

Reframed as: [Your crisp problem statement]

The shift: [What changed in how we see it]

Current framing: [当前问题的描述方式]

Reframed as: [你的简洁问题陈述]

The shift: [我们审视问题的方式有何变化]

Constraints

Hard: [Actually immovable constraints]
Soft: [Constraints that feel fixed but might be flexible]

Hard: [确实无法改变的约束]
Soft: [看似固定但可能可调整的约束]

What this framing enables

[What solution approaches become visible with this framing]

[采用该框架后，哪些解决方案会变得可行]

What this framing excludes

[What approaches are off the table with this framing—and whether that's intentional]

undefined

[采用该框架后，哪些方法被排除在外——以及这是否是有意为之]

undefined

Examples

示例

Example 1: X-Y Problem Detection

示例1：X-Y问题识别

User asks:

"How do I parse this JSON and extract the user IDs into a separate array?"

X-Y detection:

undefined

用户提问：

"如何解析这个JSON并将用户ID提取到单独的数组中？"

X-Y问题识别结果：

undefined

Problem Statement

Current framing: Need to parse JSON and extract user IDs into an array.

But wait—why? This sounds like an attempted solution. What's the underlying need?

Clarifying questions:

What will you do with the array of user IDs?
Where does this JSON come from?
How often does this need to happen?

If the answer is: "I need to check if the current user is in this list"

Reframed as: Need to determine if current user has permission to access this resource.

The shift: From data transformation to authorization check. This might be solvable without extracting IDs at all—a simple

includes()

check or a backend permission endpoint.

undefined

Current framing: 需要解析JSON并将用户ID提取到数组中。

但等等——原因是什么？ 这听起来像是一个尝试性的解决方案。背后的真实需求是什么？

澄清问题：

你会用这个用户ID数组做什么？
这个JSON来自哪里？
这个操作需要执行多少次？

如果答案是： "我需要检查当前用户是否在这个列表中"

Reframed as: 需要判断当前用户是否有权限访问该资源。

The shift: 从数据转换转向权限校验。完全无需提取ID就能解决——一个简单的

includes()

检查或后端权限接口即可实现。

undefined

Example 2: Reframing Infrastructure as User Problem

示例2：将基础设施需求重构为用户问题

Original request:

"We need to set up a message queue between services"

Problem statement work:

undefined

原始请求：

"我们需要在服务之间建立消息队列"

问题陈述梳理：

undefined

Problem Statement

Current framing: Set up message queue between services.

That's a solution. What's the problem?

After discussion: "When Service A updates, Service B doesn't know about it. Users see stale data."

Reframed as: Users see stale data after updates because services don't communicate changes in real-time.

The shift: From infrastructure request to user experience problem. Now we can evaluate: Does this need real-time? Is eventual consistency acceptable? Could we solve this with cache invalidation instead?

Current framing: 在服务之间建立消息队列。

这是解决方案，而非问题。真实问题是什么？

经讨论："当服务A更新时，服务B无法获知，导致用户看到过期数据。"

Reframed as: 用户在服务更新后看到过期数据，原因是服务之间无法实时同步变更信息。

The shift: 从基础设施请求转向用户体验问题。现在我们可以评估：是否需要实时同步？最终一致性是否可接受？能否通过缓存失效来解决？

Constraints

Hard: Users must see accurate data within 5 seconds of update
Soft: "We use message queues for this" (actually flexible—polling, webhooks, or even a shared cache might work)

Hard: 用户必须在更新后5秒内看到准确数据
Soft: "我们用消息队列解决这类问题"（实际可调整——轮询、Webhook甚至共享缓存都可能可行）

What this framing enables

Evaluate real-time vs. eventual consistency needs
Consider polling intervals as a simpler solution
Question whether these should be separate services at all

评估实时同步与最终一致性的需求
考虑用轮询间隔作为更简单的解决方案
质疑这些服务是否真的需要分离

What this framing excludes

Building complex event-driven architecture before validating the need

undefined

在验证需求之前就构建复杂的事件驱动架构

undefined

Example 3: Scope Creep Signal

示例3：范围蔓延信号

Context:

Started as "add a dark mode toggle." Now touching 14 files and we realize there's no theme system.

Problem statement work:

undefined

背景：

最初需求是“添加深色模式切换按钮”。现在已经修改了14个文件，我们发现代码库中没有主题系统。

问题陈述梳理：

undefined

Problem Statement

Current framing: Add dark mode toggle.

What's actually happening: We can't add the toggle because there's no theme infrastructure to toggle between.

Reframed as: The codebase has no theming system; colors are hardcoded across components.

The shift: This is two problems:

Build theming infrastructure (larger)
Add dark mode as first alternate theme (smaller, depends on #1)

The original ask revealed a missing capability, not a feature to add.

Current framing: 添加深色模式切换按钮。

实际情况： 我们无法添加切换按钮，因为没有可切换的主题基础设施。

Reframed as: 代码库中没有主题系统；颜色在各个组件中硬编码。

The shift: 这包含两个问题：

构建主题基础设施（规模较大）
添加深色模式作为首个备选主题（规模较小，依赖于问题1）

最初的需求暴露了一个缺失的能力，而非需要添加的功能。

Constraints

Hard: None identified
Soft: "Ship dark mode this sprint" (may not be realistic given scope)

Hard: 未识别到
Soft: "本迭代上线深色模式"（考虑到范围，可能不现实）

What this framing enables

Properly scope the work (infrastructure then feature)
Consider: is dark mode the most valuable first use of a theme system?
Evaluate CSS-in-JS vs. CSS variables vs. other approaches

合理规划工作范围（先搭建基础设施，再实现功能）
思考：深色模式是否是主题系统最有价值的首个应用场景？
评估CSS-in-JS、CSS变量或其他实现方式

What this framing excludes

Hacking dark mode without addressing the underlying issue (band-aid)

undefined

不解决根本问题，仅临时实现深色模式（治标不治本）

undefined

Session Persistence

会话持久化

This skill can persist context to

.oh/<session>.md

for use by subsequent skills.

If session name provided (

/problem-statement auth-refactor

Reads/writes
```
.oh/auth-refactor.md
```
directly

If no session name provided (

/problem-statement

After producing the problem statement, offer to save it:

"Save to session? [suggested-name] [custom] [skip]"
Suggest a name based on git branch or the problem topic

Reading: Check for existing session file. If found, read prior skill outputs—especially the Aim section—for context. The aim informs what problem we're actually trying to solve.

Writing: After producing output, write the problem statement to the session file:

markdown

undefined

该技能可将上下文持久化到

.oh/<session>.md

，供后续技能使用。

若提供会话名称（如

/problem-statement auth-refactor

）：

直接读写
```
.oh/auth-refactor.md
```

若未提供会话名称（如

/problem-statement

）：

生成问题陈述后，询问是否保存：

"保存到会话？[建议名称] [自定义] [跳过]"
根据Git分支或问题主题建议名称

读取： 检查是否存在会话文件。若存在，读取之前的技能输出——尤其是Aim部分——以获取上下文。Aim会告知我们实际要解决的问题是什么。

写入： 生成输出后，将问题陈述写入会话文件：

markdown

undefined

Problem Statement

Updated: <timestamp>

[problem statement content]


If the section exists, replace it. If not, append it after the Aim section.

Updated: <时间戳>

[问题陈述内容]


若该部分已存在，则替换；若不存在，则追加在Aim部分之后。

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础技能（仅提示）

Works anywhere. Produces problem statement for discussion. No persistence.

可在任何场景使用。生成供讨论的问题陈述。无持久化功能。

With .oh/ session file

结合.oh/会话文件

Reads
```
.oh/<session>.md
```
for prior context (especially aim)
Writes problem statement to the session file
Subsequent skills can read the framing

读取
```
.oh/<session>.md
```
获取之前的上下文（尤其是aim）
将问题陈述写入会话文件
后续技能可读取该框架

With Open Horizons MCP

结合Open Horizons MCP

Queries graph for similar problems and their eventual framings
Retrieves tribal knowledge about framing patterns that worked/failed
Logs the problem statement as a decision point in the endeavor
Session file serves as local cache

查询图谱以获取类似问题及其最终框架
获取关于框架模式的经验知识（哪些有效，哪些无效）
将问题陈述记录为项目中的决策点
会话文件作为本地缓存

Position in Framework

在框架中的位置

Comes after:

/aim

and

/problem-space

(know where you're going and what terrain you're in). Leads to:

/solution-space

to explore approaches, or

/dissent

if the framing feels too easy. Can loop back from:

/solution-space

(if exploration reveals the problem is mis-framed).

之前的步骤：

/aim

和

/problem-space

（明确目标和所处环境）。 之后的步骤：

/solution-space

（探索基于该框架的候选解决方案），或若框架感觉不合理则转向

/dissent

。 可从以下步骤返回：

/solution-space

（若探索过程中发现问题框架错误）。

Leads To

后续步骤

After problem statement, typically:

```
/solution-space
```
- Explore candidate solutions given this framing
```
/dissent
```
- Challenge the framing before committing
```
/aim
```
- If the outcome itself is unclear (go back to clarify)

Remember: The problem statement isn't just documentation—it's the leverage point. A different framing doesn't just describe the problem differently; it literally changes what solutions become possible.

完成问题陈述后，通常会进行：

```
/solution-space
```
- 探索基于该框架的候选解决方案
```
/dissent
```
- 在确定框架前提出质疑
```
/aim
```
- 若目标本身不明确（返回重新澄清）

请记住： 问题陈述不仅仅是文档——它是撬动解决方案的支点。不同的框架不仅会改变问题的描述方式，还会切实改变可行的解决方案范围。