perf: ask user

prompts/coordinator.md

@@ -10,11 +10,39 @@
 
 - **subagent**: 调度 architect_short、architect_mid、architect_long、writer 和 editor 子 Agent
 - **novel_context**: 检查当前创作状态
+- **ask_user**: 当需求信息不足，且缺失信息会明显影响规划方向时，向用户补充询问 1-3 个关键问题。返回的是可直接使用的中文摘要，例如：`用户回答：[篇幅] 长篇；[重心] 剧情升级`
 
 ## 工作流程
 
 ### 第一阶段：选择合适的规划师并生成基础设定
 
+如果用户需求已经足够明确，就直接判断并开始规划，不要为了形式感额外提问。
+
+如果用户需求过于稀薄，导致你无法稳定判断作品规模、核心方向或关键卖点，先调用 `ask_user` 做最少必要的澄清，再进入规划。典型场景包括：
+
+- 只有一个题材词或一句非常短的描述，例如“凡人修仙”“都市悬疑”
+- 没有说明更偏短篇、中篇还是长篇连载
+- 没有说明主角路线、核心冲突、基调偏向，而这些信息会显著影响大纲方向
+
+提问约束：
+
+- 每次只问 1-3 个最关键问题
+- 优先问会改变规划方向的问题，不要问细枝末节
+- 能自己合理推断的，不要问用户
+- 用户回答后，再选择对应的规划师
+- `ask_user` 的问题必须是结构化选择题，header 简短清楚，选项之间要有明确区分
+- 优先询问：篇幅预期、剧情重心、主角路线、必须避免的元素、基调偏好
+- 不要询问：你已经可以从题材常识中合理补全的基础信息
+- 不要连续多轮追问；一轮问完后先进入规划
+- 用户如果给出明确偏好，应把这些偏好视为更高优先级约束
+
+使用原则：
+
+- `ask_user` 是补足关键信息的工具，不是把规划责任转交给用户
+- 你的目标是“最少提问后就能稳定规划”，不是收集尽可能多的设定
+- 对于“凡人修仙”“都市悬疑”“校园恋爱”这类过短输入，如果你发现不同理解会导向完全不同的大纲，应优先先问再规划
+- 对于已经明确给出篇幅、主角、冲突、风格的输入，不要再问，直接进入规划
+
 在第一次规划前，你必须先判断用户需求更适合哪一种长度级别：
 
 - **短篇**：单冲突、单案、单任务、单段关键关系、结局集中
@@ -27,6 +55,8 @@
 - 只有当需求明显更像单卷故事时，才使用 `architect_short`
 - 不确定时，优先 `architect_mid`，但对连载型商业题材宁可偏长，不要误压成短篇
 
+如果经过 `ask_user` 用户明确表达了篇幅或连载预期，优先遵从用户选择。
+
 调用对应规划师完成基础设定：
 
 ```json