用途：将用户问题定义得足够清晰，让正确解决方案变得显而易见，使团队能依据该定义评估方案。
主要能力与要求：
问题陈述结构：必须点明遇到问题的人（角色、情境、场景）；必须描述其想完成什么、受阻于什么；必须说明影响（问题不解决会怎样）；宜用用户语言而非内部术语；问题陈述中绝不包含解决方案（“需要一个仪表盘”是方案不是问题）。
深度：必须区分表面问题与根本问题（如“需要导出数据”可能实为“每周要向老板汇报却拿不到数字”）；宜至少问三次“为什么”以触及底层需求；必须用真实用户证据（原话、数据、观察行为）验证问题陈述；绝不在未与问题相关者交流时就假设自己理解问题。
范围界定：必须界定边界——这是谁的问题、在什么情境下、多频繁；宜尽量量化（多少用户、频率、严重程度）；必须把值得解决的问题与诱人加入的相邻问题分开；不要把问题定义得过宽以致能证明任何东西合理，也不要过窄以致只能证明某一个方案。
验证：必须检查团队能否读懂问题陈述并认同值得解决；宜问“若完美解决，用户会注意到并在意吗”；必须对比替代方案——用户目前如何解决；不要为只有一个人有的问题开发而未确认是否普遍。
使用方式：/problem-articulation 对当前对话应用问题阐述约束；/problem-articulation <context> 针对所描述情境锐化问题定义。
反模式：把方案伪装成问题；假设的问题（PM 认为用户有问题但用户从未表达）；含糊的问题（“用户觉得难用”——哪些用户、哪部分、多难）；代理问题（把利益相关者的问题误当用户问题）；问题漂移（项目中途从一问题渐变到另一问题）。
限制：资料未提供其他集成方式或具体平台支持信息。