我怎么把需求分析流程整理成一个可复用 Skill

很多人让 AI 参与项目时，最早失控的地方往往不是写代码，反而是需求分析阶段。原因其实不复杂——需求信息天然就模糊，如果这一步没扎紧，后面的 PRD、架构、接口、页面会跟着一路发散。 以记账 App 为例，实践下来会发现一件事越来越清晰：**需求分析其实特别适合沉淀成 Skill**。原因是这里面高频出现的动作非常稳定，只不过大多数人没有把它们写成可重复的固定流程。

为什么需求分析阶段最容易跑偏

一个极其常见的场景：用户只扔过来一句话——“帮我做一个个人记账 App。” 如果没有额外约束，AI 几乎立刻就开始输出了：登录页、首页、图表页、用户表、分类表、一堆接口……看起来很快，但真正重要的问题还没回答：用户是谁？痛点是什么？第一版核心价值是什么？哪些功能先不做？这到底是 MVP，还是已经在做正式版？ 需求分析阶段最怕的不是慢，而是**还没把问题定义清楚，就已经把实现铺开了**。

后来固定要求 AI 先回答什么

现在回过头来总结，需求分析阶段几乎可以固定让 AI 先回答下面这些事： - 目标用户是谁 - 用户最核心的问题是什么 - 核心使用场景是什么 - MVP 必须做什么 - 可以后做什么 - 暂时不做什么 - 核心流程怎么走 - 异常情况有哪些 这些问题本身并不复杂，真正有价值的是：它们会逼着 AI 把需求从“想法”收成“边界”。同样是记账 App，只说“支持语音”范围很宽，但一旦继续追问——语音是直接入库，还是先转文字？预算和账单是不是同一类输入？查询能力要做到什么程度？——需求立刻就会具体很多。

为什么这些要求值得收成 Skill

因为它们会反复出现。不只是在做这个记账 App 时会用到，之后做别的项目、新模块、重构老功能，一样需要先回答这些问题。而且只要这一步做得稳，后面的工作会顺畅很多：PRD 更容易写，架构方案更容易收敛，API 范围更容易定义，测试验收也更容易明确。 从这个角度看，需求分析 Skill 的价值不是“帮你多产一份文档”，而是帮你减少后续返工。

一个需求分析 Skill 最关键的几部分

如果总结一下，一个可用的需求分析 Skill 至少需要写清楚四件事。 **第一件，是输入模板。** 要求使用者至少提供：产品目标、用户是谁、当前痛点、希望达成的体验。 **第二件，是输出结构。** 不能只让 AI 自由发挥，要规定它按固定结构输出，例如：用户画像、场景拆分、MVP 范围、后做项、暂不做项、核心流程。 **第三件，是明确禁止它一上来直接写代码。** 这一点非常关键——很多跑偏，都是从“需求还没清楚，代码先出来了”开始的。 **第四件，是要求它主动收边界。** 比如提醒它优先回答：第一版是否必须做？是否有更轻的方案？哪些需求看起来重要，其实可以后放？

这个 Skill 最适合用在什么地方

它不只适合新项目。以下几类场景都很适用： - 新项目立项 - 老项目新增一个相对独立的功能 - 把模糊想法整理成可开发任务 - 和客户或团队先对齐边界 尤其是“需求很多，但还没收敛”的时候，这类 Skill 的价值会特别明显。

Skill 化之后，最大的变化是什么

最大的变化不是“AI 变聪明了”，而是它更不容易跳步骤了。以前你可能每次都要临时补一句：“先别写代码”“先帮我收敛 MVP”“先讲必须做和后做”。写成 Skill 以后，这些就不再依赖你每次临场记得提醒——它会变成一种稳定工作方式。

最后

怎么把需求分析流程整理成一个可复用 Skill？核心不是把需求阶段写得更重，而是把那些**真正决定后面会不会返工的问题**固定下来。需求分析 Skill 最重要的作用，不是替你做产品经理，而是防止 AI 在问题还没说清楚的时候，就急着开始给答案。先把边界收住，再让后面的方案、代码和测试跟上，整个项目会稳很多。