aim-ask-strategy

name	aim-ask-strategy
description	Strongly recommended when you need to clarify questions, converge directions and uncertainties, do design or orienting work, or answer open-ended questions before deciding how to proceed and producing a task spec, especially when key clarifications could change the route.

aim-ask-strategy

概述

这个 skill 用于 AIM 语境下执行前的问策 / 定策 / 收敛，而不是泛化访谈。

核心原则有三条：先读 README，再定策略；先给上中下三策，再决定追问；提问只服务于改变策略排序，而不是为了收集信息而收集信息。

默认推荐通常是中策，因为它最容易同时平衡 README 目标、当前约束和仓库里已经存在的历史决策；只有在证据明确支持更激进或更保守时，才改推上策或下策。

何时使用

• 用户还没有明确下一步该做什么，需要先比较几条可行方向时。
• 用户面对开放式问题、方向选择题，或在几条路线之间还没收敛时。
• 用户在做创意、交互、产品、文档结构等设计工作，但当前更需要先收敛方向而不是直接产出完整设计稿时。
• 用户说的是“你觉得该怎么推进”“给我几个策略选项”“先别直接建 Task / 写计划 / 开始实现”时。
• 需要把一个方向拆成上中下三策，并允许用户选中其中一策后继续细化下一层策略时。
• 需要先把 README 当作方向锚点，再结合当前约束与已有决策做策略排序时。

何时不使用

• 用户已经明确要创建 AIM Task，此时应优先检查 aim-create-tasks。
• 用户已经要判断 README 与最新 origin/main 的事实差距，此时应优先检查 aim-evaluate-readme。
• 用户是在核对 spec 是否完整、准确、可执行，或要验证 Task spec 是否成立，此时应优先检查 aim-verify-task-spec。
• 用户已经给出足够清楚的下一步动作，只需要执行、验证或跟进，而不是继续问策时。
• 不要把它当成随意聊天式访谈；它的目标是改变策略排序，不是延长对话。

必需输入

• 当前问题要服务的 README 内容。默认应由执行者自己从 README 中推断并读取相关章节，而不是先反问用户“该看哪一段”。
• 用户当前想推进的目标、卡点或决策点。
• 已知约束：时间、风险、依赖、仓库规则、是否允许改 README / 建 Task / 写实现。
• 若仓库里已有明确历史决策、相关 spec、已合并路径或边界，也应纳入排序依据。

前置要求

开始问策前必须先读 README。没有先读 README，就不要直接给策略排序。

如果 README 与用户口头目标看起来不一致，先把这种张力显式说出来，再给策略，不要假装它们天然一致。

默认做法是自己先从 README 中圈定相关范围，然后直接给出初始上中下三策和推荐。

只有当 README 的范围歧义足够大，且不同读取范围会实质改变上中下三策的排序或推荐时，才允许先问一个澄清问题；否则不得把“你指 README 哪一段”作为第一次响应。

同样地，其他澄清问题也只有在答案会改变路线、推荐或排序时才值得问；如果只是补背景、补偏好描述，或不会改变当前收敛路径，就不要先问。

工作流

1. 先用 README 定锚

先读 README 中与当前问题相关的部分，提炼 3 件事：

• README 想把系统推进到什么方向。
• README 明确限制了什么。
• 当前问题与 README 的贴合点或张力点是什么。

这一步不是做完整 README gap evaluation，也不是做 spec 验证；只需要把当前收敛所需的方向锚点抓出来。

如果 README 很长，默认也应先由执行者自行定位最相关章节；只有在两个或更多候选范围会把策略排序明显导向不同结论时，才值得先做范围澄清。

2. 先给初始上中下三策

第一次输出必须直接给出上中下三策，并明确初始推荐，不要先抛一串开放问题。

建议结构：

• 上策：更激进、更理想、更贴近 README 终局，但通常成本、风险或前提更高。
• 中策：在 README、当前约束、已有历史决策之间最平衡，通常作为默认推荐。
• 下策：更保守、更快、更低风险，但通常会牺牲部分 README 方向或后续演进空间。

每一策至少说明：

• 这条路为什么成立。
• 它主要牺牲什么。
• 它对下一步动作意味着什么。

3. 明确为什么当前推荐是这一策

初始推荐必须写出来，不能让用户自己猜。

推荐语气要具体指向排序依据，例如：

• 为什么当前更推中策。
• 哪个约束如果变了，推荐可能会从中策切到上策或下策。
• 哪个已知事实是当前排序里最关键的分水岭。

4. 只问会改变排序的问题

问问题前先自问：这个问题的答案，会不会改变上中下三策的排序、推荐或拆分方式？

只有答案是“会”，这个问题才值得问。

这同样适用于 README 范围澄清：只有不同 README 读取范围会实质改变排序时，范围问题才值得问；否则应先按自己读到的最相关 README 范围给出初始三策。

可问的问题通常长这样：

• 如果用户回答 A，我会把上策升为推荐。
• 如果用户回答 B，我会把下策升为推荐。
• 如果用户回答 C，我会保留中策，但把它再拆成新的上中下三策。

不会改变排序的问题，不要问。

5. 用户选中一策后，递归细化这一策

如果用户说“就按中策继续”，不要直接把中策变成机械实施清单。

应先把这个被选中的中策再拆成新的上中下三策，例如：

• 该中策下的上策：更完整、更系统的推进法。
• 该中策下的中策：当前层级最平衡的推进法。
• 该中策下的下策：更保守、更快的推进法。

然后再次给出推荐，并说明这层的排序依据。

只要下一步动作还不够清楚，就继续按这个模式递归细化，而不是固定停在“第二层”或“第三层”。

6. 在下一步动作已经清楚时停止

停止条件不是“已经拆了几层”，而是“下一步动作是否已经清楚到可以执行”。

满足以下任一情况即可停止继续问策：

• 用户已经能明确说出要采取哪一个下一步动作。
• 当前推荐已经收敛到单一、清晰、可执行的下一步。
• 再继续拆分只会把同一动作换不同表述，已不再改变决策。

到这里就应结束问策，并把清晰的下一步动作总结出来。

提问纪律

• 先出策略，再追问；不要反过来。
• 问题必须服务于改变排序、推荐或下一层拆分。
• README 范围默认自己判断；只有范围歧义会实质改变排序时，才允许先问一个范围澄清问题。
• 如果一个问题只会补背景、不改变决策，就不要问。
• 如果 README 已经能回答，就不要重复问用户。
• 每轮追问后，要回到新的上中下三策，而不是只回一句分析意见。
• 每次只展开一层。不要给出推荐策略后再次展开推荐策略后的上中下策。

Quick Reference

场景	应该做	不该做
初始响应	先自行读 README 相关部分，再直接给上中下三策和初始推荐	先问用户 README 该看哪一段，或先丢一串开放问题
开放题 / 设计题	先把方向、设计取向或探索路径拆成上中下三策	直接把问题变成无边界头脑风暴
推荐默认值	通常先推中策	无依据地偏爱最激进或最保守
追问	只问会改变排序的问题	为了“多了解一点”继续访谈
澄清	只在答案会改变路线时追问	把任何不确定处都先变成澄清问题
用户选中一策后	把该策再拆成新的上中下三策	直接滑进机械计划或实现步骤
结束时机	下一步动作清楚就停	为了凑层数继续细化

明确禁止

• 不得跳过 README 直接给策略。
• 不得把“问策”退化成泛化 interview、需求采集或无边界访谈。
• 不得把创意 / 设计问题退化成漫无边界的 brainstorm；仍然要收敛到上中下三策与下一步动作。
• 不得因为 README 很长，就先把“该读哪一段 README”抛给用户，除非这个歧义会实质改变策略排序。
• 不得第一次响应只给问题、不给上中下三策。
• 不得省略初始推荐。
• 不得把 spec 校验、验收口径核对、Task spec 完整性判断伪装成问策；那属于 aim-verify-task-spec 的边界。
• 不得在用户选中某一策后直接跳成 implementation plan、任务分解或代码步骤，除非下一步动作已经清楚且用户明确要求进入那个阶段。
• 不得固定要求输出到某个层级，例如“必须拆三层”。
• 不得为了显得谨慎而无限追问；问题若不改变排序，就是噪音。

常见误用

误用	正确处理
还没读 README 就开始凭经验给建议	先读相关 README，再说明策略排序依据
先问用户 README 要看哪一段	默认自己推断并读取相关范围；只有范围歧义会改写排序时才先澄清
先问十几个问题，最后才给策略	先给初始上中下三策，再只问会改变排序的问题
用户选了中策，于是直接写实施清单	先把这个中策继续拆成新的上中下三策，直到下一步动作清楚
把上策永远当成“最佳实践”默认推荐	默认先看 README、约束和历史决策，通常中策更平衡
已经知道下一步动作，却还继续细分层级	停止递归，直接总结清晰下一步
用户问“这个交互该走探索型还是收敛型设计方向”	先按 README 与约束给出设计方向的上中下三策，而不是直接展开完整设计稿
用户问“这份 Task spec 是否已经够清楚”	切到 aim-verify-task-spec，不要继续当成问策

推荐输出骨架

README 锚点:
- 相关 README 章节 / 方向约束
- 当前问题与 README 的贴合点或张力点

初始三策:
- 上策: <更激进、更贴近终局>
- 中策: <更平衡，通常推荐>
- 下策: <更保守、更快>

当前推荐:
- 推荐 <上策|中策|下策>
- 原因: <README / 约束 / 历史决策怎样影响排序>

如果需要追问:
- 问题: <仅会改变排序的问题>
- 排序影响: <不同答案会怎样改变推荐>

如果用户选中一策:
- 该策下的新上中下三策
- 新的当前推荐

停止时:
- 已清楚的下一步动作: <一句话>

示例

示例 1：先决定要不要立刻建 Task

如果 README 强调先把方向说清楚、避免盲目执行，而当前用户只是说“这个功能要不要做”，则可以给出：

• 上策：先补一份更完整的方向澄清，再统一收敛成可创建 Task 的目标。
• 中策：先围绕当前问题做一轮问策 / 定策，收敛出最平衡的下一步，再决定是否建 Task。
• 下策：直接建一个宽泛 Task，边做边澄清。

这里通常推荐中策，因为它既尊重 README 的方向约束，也避免上策过重、下策过早承诺。

示例 2：用户选中“先问策再收敛下一步”

用户如果接受中策，不要立刻产出实现计划；应继续把“先问策再收敛下一步”拆成新的上中下三策，例如：

• 上策：把相关 README、已有 spec、历史决策都并入排序依据，做一轮更完整的定策。
• 中策：只抓 README 相关段落与当前约束，快速做一轮足够决定下一步的定策。
• 下策：只凭当前聊天上下文快速给一个低成本建议。

若时间紧但仍要尊重 README，通常仍推荐这个层级的中策。

示例 3：创意 / 设计方向收敛

如果 README 强调一致性和可交付性，而用户在问“这个新页面应该偏品牌表达、偏信息效率，还是先做低风险延续”，则仍应先给：

• 上策：做更强烈、辨识度更高的设计探索，争取拉开体验差异。
• 中策：在现有设计语言内做有限创新，先验证最关键的表达目标。
• 下策：尽量沿用现有模式，只做最低风险调整。

这类问题仍属于 ask-strategy，因为核心是执行前方向收敛；但如果用户已经明确要产出完整页面 spec 或核对 spec 是否充分，就不再属于这个 skill。

自检口径

• 是否明确要求先读 README。
• 是否第一次输出就给了上中下三策和初始推荐。
• 是否把中策说明为通常默认推荐，并给出 README、约束、历史决策之间的平衡理由。
• 是否明确要求追问只能服务于改变排序，而不是泛化收集信息。
• 是否明确支持用户选中一策后继续递归拆成新的上中下三策。
• 是否把停止条件写成“下一步动作已经清楚”，而不是固定文档层级。
• 是否拦住了 interview 化、计划化和无限递归这三类常见跑偏。