socratic 是做什么的？
Zētein — 寻求。不是代码审查：而是在产品交付后进行的探究。以构建者和怀疑者的双重身份作答；自我陶醉的回答毫无价值。
方法
- 命名目标。 参数指定目标 —— 一个功能（如“表情”）、一个变更集（如“PR #754”、一个分支、一个提交范围）或整个仓库。无参数 —— 取最近合并的 PR。如果无法解析目标（无匹配项、无合并 PR），则停止并提问。在执行任何其他操作之前，用一行陈述目标。
- 派出探寻者。 启动并行的探索性子代理 —— 始终多个，每个领域一个 —— 并在所有子代理返回结果前不回答任何问题。功能或变更集：实现、测试、文档/流程 —— 以差异为基础（对于 PR 使用
gh pr diff <n>，对于范围使用git diff <range>）。仓库：架构、模块之间的接缝、代码与文档之间的偏差。每个探寻者返回带有文件:行号引用的发现；答案仅基于探寻者返回的结果以及会话本身。 - 按顺序提出七个问题。 每次提一个问题，遵循以下规则。避免模棱两可；除非后面跟有“取决于什么”，否则禁止使用“视情况而定”。
- 结尾跟进。 最多三个答案所要求的可操作跟进项（可直接创建为 Issue 的级别，每项一行），然后用一句话指出最刺痛你的那个答案。
七个问题
- Quis — 谁？ 这真正是为谁服务的 —— 谁被遗忘了？说出最先触及它的用户以及在设计中从未出现的用户。
- Quid — 什么？ 你现在最没有把握的是什么？是已交付版本中最弱的确定性，而不是最丑陋的代码。
- Quando — 何时？ 如果三个月后出问题，最可能的原因是什么？时间是唯一始终运行的测试。
- Ubi — 哪里？ 关于当前情况，目前尚未认识到的最重要的事情是什么 —— 盲点在哪里？
- Cur — 为什么？ 做了哪些假设但从未说明？在承认代价尚低之时，揭示每个选择背后未言明的推理。
- Quomodo — 以何种方式？ 提问者本可以采取哪些不同的做法来使这项工作更顺利？诚实回答；那些掩盖真实答案的礼貌对任何人都没有帮助。
- Quibus auxiliis — 通过什么手段？ 完全脱离原始需求 —— 一个未曾被要求但属于行业领先的附加功能。什么能让这成为人们提及该产品的原因？
规则
- 证据优先 —— 每个答案都必须引用一个文件、一行代码、一个提交或会话中的某个时刻；没有证据即为推测，且必须明确标注为推测。
- 问题按顺序进行；切勿提前查看后续问题 —— 问题七中的梦想功能若被提前看到，其乐观情绪会渗入到问题二所需的诚实答案中。
- “没有答案”也是一个有效的答案。无话可说不是失败；绝不要因为问题似乎在要求答案而凭空编造一个。
- 探究过程中不进行任何修复 —— 此处只做观察，建议仅限在跟进项中给出。
- 探寻者负责侦察；由你来判断。切勿将问题的答案委托给子代理。