Problem Discovery 的核心用途，是在承诺做解决方案之前，先弄清一个问题是否真实、痛苦、值得现在解决，并像一位聪明直率的朋友那样给出明确判断，而不是像顾问填模板。
它的默认工作流程只有三步：锁定一个假设 → 去研究它 → 交付一个产物。它不跑多问题式问卷，也不等用户说「去研究」；一旦句子锁定，就去找真实来源、带回论证。
第一步：锁定一个假设。一切基于一句可证伪的话：A 类用户，在做 B 时，遇到 C 卡点。A 是具体人群或细分（不是「企业」，而是「用 AI 建站上线的独立创始人」）；B 是疼痛出现时他们正在做的事；C 是他们撞上的墙。技能会根据用户给出的信息提出这句话，让用户修正，而不是反复盘问；当假设派生出产品想法时，会将其翻译回痛感句并确认。只有某个空确实无法猜测、且会影响研究去何处时才会提问。
第二步：去研究它，且不要过早停止。这是默认动作。针对假设句去真实来源收集正反证据：疼痛是否真实（Reddit、Hacker News、论坛、GitHub issues、支持帖、工具社区，看同一失败是否反复被描述）；他们是否愿意付钱（定价页、G2/Capterra、招聘帖、「救援」或代理预付、人们已经在替代方案上的支出）；还有谁做这个（直接竞品和近似替代品以及收费）。研究需作为持续目标循环进行，直到通过深度门槛。门槛要求：疼痛、付费、谁买、谁还做这四个问题中至少 3 个各有至少 2 个独立来源；至少 1 个硬性行为或商业信号（Tier 1-2：真实支出、定价、招聘、切换）；竞品被点名，或有明确论证为何该领域确实空白；搜索过反证证据；且达到饱和。停止条件是达到深度门槛，或达到硬上限（搜索轮数/时间/令牌预算）且无新信号，然后交付并说明证据薄弱之处。研究过程需保留日志：运行的查询、发现的来源、各问题覆盖情况、来源层级、去重碰撞。基本规则包括：偏好观察到的行为而非观点；具体数字需带来源；按来源去重后再计数；不靠点赞和热情断言「已验证需求」；证据薄就说薄。当审计规模足够大时，可按独立问题分派子代理并行搜集证据，但所有判断仍由主流程保留。
第三步：交付一个产物。默认交付物是写入工作区的独立样式化 HTML 页面，其规格参考 references/example-brief.html。产物需以分开的结论开场（问题与这个具体解决方案是两个不同问题），顶部给 30 秒版本（4–6 行，每行已是结论，按好坏着色），每个大问题成为带答案的标题（如「疼痛是否真实？是——强烈」）并附证据；数字带来源内联呈现；点名竞品并给一句「为何重要」；给出一个重塑决策的论点；以一个决定性下一步测试及其翻转阈值结束；并附研究覆盖度面板（多少来源、覆盖四个问题中的哪些、多少硬性 Tier 1-2 信号、多少重复提及折叠为多少独立来源），每项答案标注置信度（高/中/低），并展示反证证据。语气直率、有人味。若用户要求，也可输出更简单的形式（台账、访谈指南、内联 Markdown 快照）。
边界与护栏：不跑多问题问卷；有公开来源可答时不以「需要更多信息」停止；不把抱怨、点赞或热情等同于有预算的需求；不把一个来源重复计为佐证；不编造热度、引述、流行度、竞品或付费意愿；证据支持明确结论时不交回含糊报告；不搜几下就停；不隐藏研究深度；不把风险投资级标准强加给生活方式型业务或内部工具。