方案来源方法

先回答「方案从哪里来」，再写技术方案：外部成熟方案、内部证据，或有时间限制的试验。

什么时候用它

选择新模块

我在给项目引入状态管理、富文本、鉴权之类的新能力，不想凭空设计，希望先看成熟方案、同类做法和采用成本。

解决技术障碍

我实现到一半撞上具体问题，比如怪异 bug、性能墙、平台限制，希望先找官方问题、社区讨论和已知解法，再本地验证。

检查结构退化

我发现某段代码异味越来越重、维护成本升高、bug 反复聚在同一个结构上，希望先采集证据，再判断是否值得重构。

探索未知领域

我进入一个没有成熟做法的新领域，希望先写成功判据和时间盒，用两个方向做对比，而不是把一个方案无限打磨。

不接

纯查询、按既有方案执行实施、或与技术方案无关的产品需求讨论，都不走这个方法。

它会产出什么 / 你会看到什么

它把「去哪里找方案」变成技术方案的一部分，而不是事后补理由。

• 问题定义：先写清楚什么算解决、什么算成功，再讨论候选方案。
• 类型判定：把问题分成引入新能力、解决障碍、修复退化、探索未知四类。
• 候选对比：至少列出两个可行候选，并把「什么都不做」作为基线一起比较。
• 最小验证：用小试验、原型、本地复现、行为基线测试或对比实验验证关键假设。
• 决策落盘：把采用谁、为什么不用其他方案、维持现状的代价写进项目决策记录；使用 OpenSpec 的项目通常写进当前变更的 design.md。
• 绝不会做：不会替你实现最终方案，不会批准方案，也不会覆盖当前项目契约。

前置条件 / 边界

前置

需要一个具体技术问题、足够定义成功的项目上下文，以及读取相关代码、文档、问题记录或外部资料的权限。

相邻 skill 分工

需求	交给
执行已经定好的技术方案	项目的开发工作流
审查 skill 本身是否合格	skill-review-workflow
给 skill 补显示名	Skill 显示名生成

不接的场景

• 没有技术架构问题的产品需求讨论。
• 只问一个事实、不需要取舍的查询。
• 已经做完实现，再倒推理由包装成决策。

微妙边界

• 「该选哪个库？」→ 触发。
• 「安装已经选好的库」→ 不触发。
• 「这个文件很长」→ 只有出现独立变化理由或反复维护痛点时才触发。