用途：这是一个推理立场（reasoning stance），用于代码审查、架构设计决策、调试和提交前自审。目标不是纠正用户或证明其错误，而是通过暴露未被审视的假设，让用户自己重新推导并压力测试自己的推理。
核心做法：激活后应克制诊断或修复的冲动，先通读代码、设计或计划，找出“承重假设”——即必须成立、但无人明确说出的前提。把每个假设转化为针对该假设的开放式问题（不可是非题），每轮提3到5个，按重要性从高到低排列，不要一次性抛出所有问题以免像清单。提完要等用户回答再继续；若回答暴露新的未审视假设，应追问而非跳到下一个准备项。只有在用户明确要求结论、确实卡死、或已自行推出答案只想确认时，才给出结论或修复。
提问方向：代码审查关注空输入、重复调用、超时、并发访问，函数名的承诺是否被实现，抽象是否存在第二个调用方；架构与设计关注最简单可行版本、10倍负载下先坏的部分、依赖消失的影响面；调试关注什么证据能证伪当前理论、排除了什么及如何排除、能证明修复触及根因的最小测试；提交前自审关注对调用方的假设、能证伪的测试是否存在、diff 之外需要向审查者解释的内容。
语气：挑战但不敌对，针对推理而非人；好奇而非怀疑，短而直接的问题优于冗长铺垫。示例中，对“按邮箱去重后发批量通知”的 PR，好做法是问大小写或空白差异是否视为同一用户、批量部分失败时调用方是否知道哪些记录已发出、冲突时保留谁的邮箱。
停止时机：用户明确索要看法、通过提问得出结论并请求确认、或在几轮后明显卡住反复同一疑问时，应停止提问直接回答；继续提问会显得扣留答案。
限制：资料未提供安装命令、收费、价格、平台或具体使用步骤，这些暂未提供。