feasibility-analysislisted

# 可行性分析（Feasibility Analysis） ## 目的与边界 当技术、合规、资源或业务约束对某个具体产品级方案的可行性提出疑问时，本 skill 在四个维度上客观框定评估——**市场空间、技术可行性、投入产出、风险评估**——并给出带置信度的 做 / 不做 / 有条件做 推荐——但**绝不做出最终决策**。人类决策人拥有选择权。 当同一目标存在 ≥2 个实质不同的方案时（自研 vs 外购、不同路径、不同范围取舍），对比作为可行性报告内部的 **§多方案取舍** 章节处理，使用在打分前定义好的加权决策矩阵。它是报告的一章——不是独立的交付物。 **不要**做出最终决策、静默修改范围、设计架构，或评估只在实现细节上不同的方案（那些属于工程，不属于产品）。可行性评估要求一个具体的产品级方案已经存在——在 X 具体之前，你无法评估"我们能不能做 X"。 ## 输入与输出 输入：一个具体的产品级方案（来自 `product-ux` 或 `function-description`）或显式的可行性决策请求、上游证据（background-goal、成本/约束/合规输入）、以及一个指定的 decision-owner。如果决策会改变已确认的范围、成本、合规或风险姿态，停止在 `needs_user_input`，直到识别出决策 owner。 输出：单一的 `feasibility-report.md`，使用 `src/templates/support/feasibility-report.md` 中的模板——市场空间 / 技术可行性 / 投入产出 / 风险评估 / §多方案取舍（≥2 实质方案时）/ 结论（做/不做/有条件做）。§多方案取舍 章节（若存在）使用 `src/templates/support/solution-comparison.md` 的多方案对比模板作为其章节结构；它嵌入在报告中，绝不作为独立产物产出。 分析前加载 `references/thinking-framework.md`（其中引用 `src/framework/thinking-core.md` §1 必用透镜）。Intake 时加载 `references/source-handling.md`。Clarify 时加载 `references/question-patterns.md`。起草前加载 `references/output-contract.md`。Generate 时加载 `references/anti-patterns.md`。移交前加载 `references/audit-checklist.md` 和 `references/reviewer-checklist.md`。评审前运行 `scripts/validate_artifact.py <artifact> --json`。 ## 思考提示（按阶段） ### 1. Preflight（预检） - "是否存在需要在市场 / 技术 / 投入产出 / 风险维度回答的可行性问题？是否存在具体的产品级方案？" - "同一目标是否存在 ≥2 个真正不同的方案？如果是，适用 §多方案取舍 章节（报告内部的加权矩阵）。" - "如果方案只在实现细节上不同，路由给工程，而不是产品。" - 识别 decision_owner。**如果不存在决策 owner，返回路由收据并 STOP 在 `needs_user_input`。** - 评估成熟度：L0（无具体方案）→ L1（模糊想法