Back to Details

problem-statement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/problem-statement

/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:
BadGood
"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:
  1. State it to someone else - If they immediately suggest a solution, the framing is too narrow
  2. Invert it - What would the world look like if this problem didn't exist?
  3. Zoom out - Is this a symptom of a larger problem?
  4. Zoom in - Is this actually multiple problems masquerading as one?
在确定问题陈述之前，进行测试：
  1. 向他人陈述 - 如果对方立刻提出解决方案，说明框架过于狭窄
  2. 反向思考 - 如果这个问题不存在，世界会是什么样子？
  3. 放大视角 - 这是否是更大问题的症状？
  4. 缩小视角 - 这是否是多个问题伪装成一个问题？

Output Format

输出格式

Produce a problem statement in this structure:
undefined
请按照以下结构生成问题陈述：
undefined

Problem Statement

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

Constraints

  • Hard: [Actually immovable constraints]
  • Soft: [Constraints that feel fixed but might be flexible]
  • Hard: [确实无法改变的约束]
  • Soft: [看似固定但可能可调整的约束]

What this framing enables

What this framing enables

[What solution approaches become visible with this framing]
[采用该框架后，哪些解决方案会变得可行]

What this framing excludes

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

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

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

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

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

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

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:
  1. Build theming infrastructure (larger)
  2. 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. 构建主题基础设施（规模较大）
  2. 添加深色模式作为首个备选主题（规模较小，依赖于问题1）
最初的需求暴露了一个缺失的能力，而非需要添加的功能。

Constraints

Constraints

  • Hard: None identified
  • Soft: "Ship dark mode this sprint" (may not be realistic given scope)
  • Hard: 未识别到
  • Soft: "本迭代上线深色模式"（考虑到范围，可能不现实）

What this framing enables

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

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

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
    - 若目标本身不明确（返回重新澄清）
请记住： 问题陈述不仅仅是文档——它是撬动解决方案的支点。不同的框架不仅会改变问题的描述方式，还会切实改变可行的解决方案范围。