技能介绍

要解决什么问题

很多「做个系统 / 加个 Agent」的需求，表面是功能清单，底层却是流程断点、信息不可靠或决策无处可依。若默认用软件作答，容易把痛点写成「缺工具」，范围在 MVP 之前就失控。

本技能把 数字化需求发现 当成工程前置：在设计工具、工作流或文档之前，用第一性原理还原——真实世界哪段过程在失效、缺什么信息、应改善哪类决策，以及为何值得引入数字化或智能化手段；并显式比较流程调整、表格/数据库、低代码、自动化、看板、知识库、AI Agent、定制软件等 方案载体，而非一上来写实现。

技能如何工作

对话按 阶段门控 推进，未满足条件不进入 MVP 或实现设计：

Intake：复述诉求，厘清提出方、用户、现状、期望变化与约束。
第一性原理门：说明过程失败点与信息/决策缺口；若用户已带着方案来，先解释为何要回到基本面。
模型路由：只选用当前情境需要的最小分析模型集（见 references/model-router.md）。
聚焦提问：一次一问，优先能解锁决策、暴露假设或降风险的问法。
问题重框：整理业务语境、真痛点、目标结果、角色、现行流程、数据流与关键假设。
方案探索：至少对比两种载体，并在可信时给出更轻路径；涉及 AI/API/运维成本时写入比较。
MVP 与路线图：最小可用版本、非目标、验证计划与后续阶段。
结论文档：按模板输出需求洞察与方案设计，实现细节放附录。

交付前会区分事实、假设、用户观点与推断，并检查痛点是否表述为结果/约束而非「缺某工具」。

适用边界

需要 快速拍板 时，可先给轻量结论，但须标明未闭合的假设。
用户质疑流程时，应说明当前阶段并调整节奏，而非硬推下一步。
上下文不足时仍产出文档，但必须有 Open Questions and Assumptions 专节；非 trivial 需求应列出至少三条非目标，且 MVP 须可在短周期内被验证成败。