pythia-spec

确定规范

开始时宣布：“正在使用 pythia-spec — 此请求中有一些开放决策，由你而非我来决定。”

**阶段：**了解 → 提问 — 充分了解情况，以便提出好问题；持续提问，直到规范确定，然后才开始构建

其他技能组成了构建链：它们会在规范确定后启动。此技能负责此前的阶段——因为如果 Agent 悄悄替自己确定规范，就会流畅地构建出错误的东西，而开发者第一次有机会提出异议时，代码已经写好，每个选择都意味着重写。

铁律

SPEC DECISIONS BELONG TO THE DEVELOPER. YOU PROPOSE; THEY CHOOSE.

规范还是技术？这条界线决定由谁来决定

规范 — 先提问	技术 — 自行决定，并注明依据
存储什么：新增表还是新增列，保留什么还是删除什么	名称和结构 — 现有约定已经给出了答案
业务行为：过期时间、重试上限、锁定次数、允许哪些人操作	用哪个字典视图或查询来回答问题
安全性与审计的权衡：删除令牌还是保留记录	遵循通过 similar 找到的现有模式
渠道和范围：电子邮件还是 SMS、涉及哪些租户、哪些调用方	由此类值的既定规则决定的数据类型
偏离强制约定	pythia conventions 或代码库已有答案的事项

经验法则：**如果两位资深开发者可能会合理地交付不同的行为，那就是规范问题。**如果代码库或约定已经给出答案，那就是技术问题——自行决定，并说明依据。

工作流

1. **充分了解情况，以便提出好问题——但不要多到开始构建。**检查涉及表的 cols 和 src，查看 conventions，并用 similar 了解此代码库如何解决问题。此步骤的产出应是更好的问题，而不是代码。
2. **列出所有你本来会默默自行决定的事项。**检验方法：梳理你设想的实现，并记录每个你选定了开发者从未说明的行为的地方。
3. 逐一提问，给出选项、权衡和建议——绝不要只问“你想要什么？”。每个选项都要说明代价： “通过 SMS 发送 OTP：6 位数字容易被猜到，因此必须增加尝试次数计数器和锁定列——这会导致表结构与草案不同。”
4. **用几行文字写下已确定的规范，并请对方确认。**这段文字现在就是范围——也就是 pythia-write 所说的“开发者的原话”。这份摘要不可跳过；它记录了双方达成的共识。
5. 提供书面文档——由开发者选择。“规范已确定。你想先要一份规范文件和分步计划，还是现在就开始构建？” 跳过也是合理的选择；用一行记录下来，然后继续。必须完成的是提问，文档则从来不是必需的。
6. 交接：影响分析 → 编写 → 应用，一如既往。

在构建过程中发现自己正在做决定？

在那一行停下来。编码时发现新的开放决策，就要提出一个新问题——晚些时候再问，代价很小；而在最终报告中把它当作既成事实来宣布（“我还决定了……”），正是此技能要防止的情况。

危险信号 — 如果发现自己有以下想法，请立即停止

想法	事实
“任务很简单，提问只会拖延进度”	简单的请求往往隐藏着最多的规格要求：一个忘记密码流程就包含七项。提三个问题只需一分钟；返工却要花一个下午。
“懒人模式说不要因提问而拖延”	懒人模式缩短的是解决方案，绝不会缩短理解过程。敲定规格就是理解。
“我会在最终报告中说明自己的选择”	到那时，开发者只能同意或要求返工。这不是选择，而是一张账单。
“另一个工具包里的头脑风暴技能会处理这件事”	如果有技能触发了，就遵循它。如果没有，这就是最低要求——本工具包假设没有安装其他任何东西。
“开发者说了‘直接做’”	这只涵盖了他们能看到的决策。你后来发现的新决策仍然由他们决定。
“他们跳过了规格文件，所以我也可以跳过提问”	恰恰相反。提问是必需的；只有文档是可选的。

何时不应使用此技能

• 请求的规格已完整明确，或者是只有一种站得住脚的正确行为的 bug — 直接使用 pythia-impact。
• 开发者已经回答过 — 不要重复询问已确定的内容；只重新询问有变动的部分。
• 纯重构，且行为保持不变。