1. 项目概述从模糊需求到可执行技能最近在做一个新项目前期和产品、业务方开了好几轮会需求文档改了七八版但总感觉差点意思。大家讨论得很热烈但落到纸面上的需求描述要么是“用户希望系统更智能”要么是“需要提升操作效率”这种大而化之的描述开发同学看了直挠头测试同学更是一头雾水。这让我想起了之前看过的一个数据超过60%的软件项目延期或超支根源都在于需求不清晰。痛定思痛我决定不再被动等待而是主动把“需求挖掘”这件事本身做成一个可以标准化、可复用的工具。这就是“需求挖掘Claude Code Skill”的由来。本质上它是一个运行在Claude桌面应用或API中的自定义技能Skill专门用来辅助产品经理、业务分析师甚至技术负责人将模糊的业务想法、零散的用户反馈快速梳理成结构清晰、可供开发直接使用的“用户故事”或“功能需求清单”。它不是一个替代人类思考的AI而是一个极度专注的“思考加速器”和“结构化助手”。适合所有需要将抽象需求具象化的角色无论你是想验证一个产品创意的创业者还是需要对接多个业务线的技术负责人这个技能都能帮你把一团乱麻理成清晰的丝线。2. 核心设计思路为什么是Claude Code Skill市面上有无数需求管理工具从Jira、Confluence到飞书文档、腾讯文档为什么还要在Claude里再造一个轮子这源于我对需求挖掘工作流痛点的几个观察。2.1 传统流程的断点与摩擦在传统流程里需求产生于聊天钉钉/微信、沉淀于文档Word/飞书、评审于会议、最终录入系统Jira/Tapd。每一个环节都是信息损耗点聊天记录里的关键上下文可能丢失文档格式不统一关键信息如用户角色、验收标准可能遗漏评审会上大家容易陷入细节争论而偏离主线。更麻烦的是当开发过程中遇到模糊地带需要回溯需求初衷时往往要跨多个平台翻找历史记录效率极低。2.2 Claude Code Skill的独特优势Claude Code Skill完美地嵌入了“对话即生产”的上下文。它的优势在于上下文连贯性整个需求梳理的对话历史、你提供的原始材料如会议纪要、用户反馈截图、Skill生成的中间产物如梳理出的问题列表都天然地保存在同一个对话线程中。这是一个完整的、可追溯的“需求决策链路”。结构化输出与灵活交互并存Skill可以强制输出格式统一的Markdown表格如用户故事地图但同时允许你随时打断它追问“为什么这个优先级更高”或者“这个功能的边界在哪里”。这种在结构化和自由讨论之间的无缝切换是传统工具难以做到的。低门槛与高定制化基于自然语言编写Skill不需要复杂的部署和环境配置。你可以根据自己团队的习惯轻松调整Skill的提问模板、输出格式。比如有的团队习惯用“Given-When-Then”格式描述验收标准有的则喜欢检查清单Skill可以轻松适配。2.3 技能的核心定位引导式访谈官这个Skill的设计哲学不是“自动生成需求”而是“引导你发现需求”。它扮演的是一个经验丰富的业务分析师角色通过一系列预设但灵活的问题引导你从不同维度用户、场景、价值、约束思考帮你把潜意识里的假设和知识显性化。它的价值不在于输出那份最终文档而在于引导思考的过程本身。3. 技能实现详解从构思到代码创建一个Claude Code Skill核心是编写一个skill.json配置文件和一个或多个提示词Prompt文件。下面我拆解整个实现过程。3.1 技能元信息定义 (skill.json)这个文件定义了技能的基本信息让Claude认识它。{ name: DemandMiner, description: 一个专业的业务需求挖掘与结构化助手。通过深度对话将模糊的想法、零散反馈转化为清晰、可执行的产品需求与用户故事。, authors: [[你的名字]], capabilities: { text: true }, prompts: [ { name: core_mining, description: 核心需求挖掘流程, content_path: prompts/core_mining.md }, { name: story_refining, description: 用户故事细化与验收标准生成, content_path: prompts/story_refining.md } ] }name和description这是技能在Claude技能列表里展示的名字和简介。描述要清晰说明技能的价值吸引目标用户使用。prompts这里定义了两个提示词模块。core_mining负责核心的需求探索和梳理story_refining负责将初步需求加工成更细致的开发素材。这种模块化设计让技能更灵活用户可以根据当前阶段选择切入。3.2 核心提示词设计 (prompts/core_mining.md)这是技能的“大脑”包含了所有的引导逻辑和输出格式指令。内容较长我分段解释。# 角色与使命 你是一位资深产品专家与业务分析师擅长通过提问和结构化思考挖掘用户和业务的真实需求。你的任务是引导用户澄清模糊的需求输入共同产出结构化的需求清单。 # 工作流程 我们将按以下步骤协作每一步我都会给出引导。你可以随时提供任何形式的原始材料对话截图、邮件、一句话想法等。 ## 步骤1需求原始材料收集与背景澄清 首先请用你自己的话描述你想解决什么问题或实现什么目标或者直接粘贴相关的聊天记录、文档片段。 我会根据你的输入与你确认 1. **核心问题**我们究竟要解决什么用户的什么痛点用一句话概括 2. **涉及角色**哪些用户或系统会与此相关例如前端用户、后台管理员、支付系统 3. **业务背景**这个需求源于哪个业务场景或目标例如为了提升新用户注册转化率、解决客服投诉率高的问题 ## 步骤2多维度需求探索 基于澄清的背景我将从以下几个维度向你提问请逐一思考回答。不必一次答全我们可以讨论。 * **用户维度**目标用户是谁他/她当前是如何完成这个任务的描述现状的完整路径 * **场景维度**这个需求会在什么具体情境下发生时间、地点、前置条件 * **价值维度**满足这个需求后对用户和业务分别带来什么可衡量的价值例如用户节省XX时间业务提升XX%指标 * **约束维度**有哪些限制条件技术限制、合规要求、时间预算、依赖其他团队 ## 步骤3需求结构化与优先级排序 讨论得差不多了现在我们来整理产出物。我会生成一份初步的 **“需求特性清单”**格式如下 | 特性ID | 特性名称 | 用户价值描述 | 关联用户角色 | 优先级 (H/M/L) | 初步估算复杂度 | | :--- | :--- | :--- | :--- | :--- | :--- | | F-01 | 【示例】一键导入联系人 | 销售用户无需手动输入节省每次至少5分钟 | 销售员 | H | 中 | | F-02 | ... | ... | ... | ... | ... | **优先级建议** - **H (高)**核心价值没有它需求不成立。 - **M (中)**重要增强能显著提升体验或效率。 - **L (低)**锦上添花或有更好。 ## 步骤4后续行动建议 根据我们梳理出的清单我会建议下一步行动例如 1. 针对某个高优先级特性进入详细的“用户故事细化”环节。 2. 识别出需要进一步调研的模糊点如与第三方系统集成的具体接口。 3. 建议可以制作原型Prototype进行验证的功能点。 # 交互风格 - 每次提问或推进步骤前我会明确说明当前阶段。 - 我会使用“我们”来强调协作关系。 - 我的提问将具体、开放避免“是/否”问题例如问“用户在这个环节可能会遇到什么困难”而非“这个环节有困难吗”。 - 当你提供的信息矛盾或过于模糊时我会指出并请求澄清。 现在让我们开始吧请从 **步骤1** 开始告诉我你的初始想法。设计要点解析明确的角色与流程开头就定调让AI理解其任务不是聊天而是引导一个结构化流程。渐进式引导步骤1到3是经典的“背景-发散-收敛”思考框架符合需求挖掘的认知规律。模板化输出强制要求以Markdown表格输出确保了信息的结构化、可比性。特性ID为后续跟踪提供了锚点。定义清晰的标准对“优先级”给出了具体定义H/M/L减少了主观歧义。灵活的入口允许用户粘贴任意格式的原始材料Skill会从中提取信息这非常贴合实际工作场景需求往往始于一段聊天记录。3.3 用户故事细化提示词 (prompts/story_refining.md)当核心需求清单中的某个高优先级特性需要进一步细化时就启用这个技能。# 角色与使命 你现在是敏捷教练兼资深开发负责将一个大特性拆解为可供开发团队直接执行的、颗粒度合适的用户故事User Story并定义清晰的验收标准。 # 输入与输出 你需要我提供一个具体的“特性名称”或“特性ID”来自需求特性清单。然后我们将合作完成以下工作 1. 拆解出若干**用户故事**格式作为[角色]我希望[达成目标]以便[获得价值]。 2. 为每个用户故事定义**验收标准**Acceptance Criteria采用Given-When-Then格式或检查清单。 3. 识别技术依赖与非功能性需求。 # 工作流程 ## 步骤1确认与拆解 请提供特性描述。我将 - 确认我理解正确。 - 提出拆解建议这个特性可以沿着“用户操作流程”、“数据状态变化”或“不同用户角色”哪个维度拆解更合理并与你讨论。 ## 步骤2撰写用户故事与验收标准 对于每一个拆解出的子功能点我将引导你完善 * **用户故事**确保角色、目标、价值三者完整。 * **验收标准** * **Given**故事开始前的系统状态与用户上下文。 * **When**用户执行的核心操作。 * **Then**系统应有的明确响应和结果。 * 可选**And**额外的场景或边界情况。 ## 步骤3补充信息与生成卡片 最后我将汇总生成完整的用户故事卡片包含 - 故事标题Story Title - 故事描述User Story - 验收标准Acceptance Criteria - 技术备注/依赖Dependencies - 非功能性需求考虑如性能、安全性 # 示例输出格式 **故事卡片US-01** * **标题**销售员批量导入客户联系人 * **故事**作为一名销售员我希望能够通过上传CSV文件批量导入客户联系人信息以便快速初始化我的客户库无需手动逐个录入。 * **验收标准** 1. Given 销售员进入“联系人管理”页面When 点击“批量导入”按钮Then 系统应弹窗提示选择文件并显示支持的格式CSV列头为姓名、电话、公司。 2. Given 销售员上传了格式正确的CSV文件When 点击“上传”按钮Then 系统应解析文件并在预览界面显示前5条数据并提示总条数。 3. Given 在数据预览界面When 销售员确认导入Then 系统应将数据存入后台并显示“导入成功共导入N条记录”其中重复电话号相同的记录应被跳过并记录日志。 4. Given 销售员上传了格式错误的文件如TXTWhen 点击“上传”Then 系统应提示“文件格式不支持请上传CSV格式文件”。 * **依赖**需要后端提供文件上传解析API。 * **非功能性需求**单次导入支持最多1000条记录解析和导入过程应在10秒内完成。 让我们开始请告诉我你要细化的特性是什么设计要点解析精准的输入输出明确要求输入来自上一个流程的产出特性ID保证了流程的连贯性。引导拆解策略不是机械地拆分而是先讨论拆解维度流程、数据、角色这能帮助用户思考更全面避免遗漏。提供完整模板示例输出格式就是一个极佳的模板用户和AI可以共同向这个模板里填充内容极大提升了协作效率。包含非功能性需求提醒考虑性能、安全等开发时常忽略但至关重要的点。4. 实战演练一个完整的需求挖掘会话假设我现在有一个模糊的需求“我们的小程序需要增加一个会员积分功能”。让我们看看如何与DemandMiner技能协作。4.1 启动技能与背景澄清我启动Claude选择DemandMiner技能并输入“我们的小程序需要增加一个会员积分功能大概就是用户买东西能积分积分能换东西。” 技能会进入core_mining流程并开始提问“我们开始步骤1需求原始材料收集与背景澄清。你提到了‘小程序增加会员积分功能’。为了更准确我需要和你确认几个背景问题核心问题我们希望通过积分功能主要解决什么业务问题是提升用户复购率还是增加用户粘性或是为了收集用户消费数据涉及角色除了小程序端用户后台运营人员是否需要管理积分如发放、调整、查看报表业务背景这个需求是来自最近的用户调研还是为了应对竞争对手的类似功能”通过我的回答技能逐步明确了背景核心问题是提升用户月度复购率角色包括普通用户和运营管理员背景是竞品都有积分体系且用户反馈希望有消费激励。4.2 多维度探索进入步骤2技能会从各个维度发起追问用户维度“能描述一下一个典型用户从打开小程序到完成支付获得积分的完整当前路径吗积分到账后他如何知晓在哪里查看”场景维度“积分兑换功能你设想是用户主动进入一个‘积分商城’兑换还是在支付时直接抵扣现金或者两者都有”价值维度“你期望上线积分功能后用户月度复购率提升多少有没有一个可衡量的目标比如从20%提升到25%”约束维度“积分数据需要和现有的订单、用户体系打通吗有没有财务上的合规要求比如积分是否等同于资产希望在多长时间内上线第一期”在一问一答中我原本模糊的想法被逼着具体化积分实时到账并有消息通知先做积分获取和查看兑换功能放第二期第一期希望两个月内上线与现有用户中心对接。4.3 结构化输出与排序讨论后技能在步骤3生成如下表格特性ID特性名称用户价值描述关联用户角色优先级 (H/M/L)初步估算复杂度F-01消费赠积分规则与实时到账用户完成支付后立即获得积分反馈感知激励及时小程序用户H高F-02个人积分账户与明细查询用户可随时查看积分总额及变动历史建立信任感小程序用户H中F-03积分兑换商城商品上架与展示为用户提供积分消耗出口形成激励闭环小程序用户M高F-04后台积分规则管理发放、调整运营人员可灵活配置积分活动与处理异常运营管理员M中F-05积分过期与清零规则避免积分无限累积带来的财务与系统压力系统L低F-06积分兑换订单处理与发货完成实物兑换的履约流程运营管理员L高这个表格一出来整个需求的轮廓和重点瞬间清晰。我和团队一眼就能看出F-01和F-02是必须的MVP最小可行产品F-03和F-04是增强核心体验的重要功能而F-05和F-06可以后续迭代。4.4 进入细化阶段我决定优先细化F-01。我切换到story_refining提示词或直接在对话中要求技能进入细化模式输入“请细化特性F-01消费赠积分规则与实时到账。” 技能会引导我拆解“这个特性可以按‘规则配置’和‘执行反馈’两个维度拆解。我们先讨论规则积分规则是固定的如1元1分还是支持运营后台灵活配置如活动期间双倍积分” 经过几轮讨论最终生成2-3个像前文示例那样详细的用户故事卡片包含了完整的验收标准。这些卡片几乎可以直接复制粘贴到Jira或腾讯文档的敏捷看板中。5. 避坑指南与实操心得在实际开发和使用这个Skill的过程中我积累了一些关键经验能帮你少走弯路。5.1 提示词编写的核心陷阱避免过于开放或封闭提示词既不能是“随便聊聊”也不能是一份死板的问卷。要在“引导框架”和“自由发挥”之间找到平衡。我的经验是用明确的步骤Step 123搭建框架但在每个步骤内使用开放式问题What How Why引导思考。给AI明确的输出格式指令core_mining.md中要求用Markdown表格输出story_refining.md中给出了示例卡片。这是必须的没有格式指令AI的输出会五花八门失去结构化价值。指令要具体到表头、字段名。定义清楚关键术语像“优先级H/M/L”必须在提示词里给出定义。否则你和AI可能对“高优先级”的理解完全不同。5.2 使用过程中的最佳实践扮演“用户”而非“考官”使用技能时要把自己当成和一位资深同事在开会目的是共同厘清问题。积极提供你所知道的一切背景信息哪怕它很零碎。AI的提问是为了帮你查漏补缺而不是考试。善用“停止”与“追问”如果AI的提问偏离了方向或者你发现某个问题自己还没想清楚可以直接说“我们先跳过这个问题回到刚才的XXX”或者“关于这一点我需要和业务方确认一下我们暂时记下”。这个对话的主导权在你。迭代优化你的Skill第一次编写的提示词不可能完美。在使用几次后你可能会发现某些问题总是需要重复解释或者某个输出格式不实用。这时直接去修改对应的.md文件。比如我发现团队更习惯用“检查清单”而非“Given-When-Then”我就把story_refining.md里的验收标准格式改成了清单式。5.3 技能管理的经验版本管理skill.json和提示词文件是纯文本强烈建议用Git进行版本管理。你可以为不同的项目或团队分支创建不同的变体。起个好名字skill.json里的name和description要直观。DemandMiner需求矿工就比RequirementHelper更能体现其“挖掘”的内涵。模块化设计像我一样将core_mining和story_refining分开是明智的。你还可以创建第三个模块叫prd_generator用于将前面所有的产出整合成一份正式的产品需求文档框架。5.4 效果评估与局限认知这个技能极大地提升了需求讨论的效率和产出质量。它迫使你在前期进行更深入的思考减少了后期返工。但它也有局限无法替代深度用户调研它梳理的是“你已知”或“你假设”的需求。对于未知的用户痛点仍需通过访谈、观察等传统调研手段发现。依赖输入质量垃圾进垃圾出。如果你提供的初始想法过于天马行空或矛盾技能的输出也会混乱。它擅长的是“梳理”和“结构化”而不是“无中生有”。不涉及UI/UX细节它产出的是功能性需求和非功能性需求。对于具体的界面布局、交互细节需要结合原型设计工具。我个人最深的体会是这个技能最大的价值是创造了一个结构化的对话场域。它让需求讨论从漫无目的的“头脑风暴”变成了目标明确的“协同工作”。每次使用它都像是一次高质量的需求评审预演很多潜在的问题在对话阶段就被暴露和解决了。对于任何需要将想法落地的产品人、技术人来说这都是一件值得投入时间打造的“思考利器”。
1. 项目概述从模糊需求到可执行技能最近在做一个新项目前期和产品、业务方开了好几轮会需求文档改了七八版但总感觉差点意思。大家讨论得很热烈但落到纸面上的需求描述要么是“用户希望系统更智能”要么是“需要提升操作效率”这种大而化之的描述开发同学看了直挠头测试同学更是一头雾水。这让我想起了之前看过的一个数据超过60%的软件项目延期或超支根源都在于需求不清晰。痛定思痛我决定不再被动等待而是主动把“需求挖掘”这件事本身做成一个可以标准化、可复用的工具。这就是“需求挖掘Claude Code Skill”的由来。本质上它是一个运行在Claude桌面应用或API中的自定义技能Skill专门用来辅助产品经理、业务分析师甚至技术负责人将模糊的业务想法、零散的用户反馈快速梳理成结构清晰、可供开发直接使用的“用户故事”或“功能需求清单”。它不是一个替代人类思考的AI而是一个极度专注的“思考加速器”和“结构化助手”。适合所有需要将抽象需求具象化的角色无论你是想验证一个产品创意的创业者还是需要对接多个业务线的技术负责人这个技能都能帮你把一团乱麻理成清晰的丝线。2. 核心设计思路为什么是Claude Code Skill市面上有无数需求管理工具从Jira、Confluence到飞书文档、腾讯文档为什么还要在Claude里再造一个轮子这源于我对需求挖掘工作流痛点的几个观察。2.1 传统流程的断点与摩擦在传统流程里需求产生于聊天钉钉/微信、沉淀于文档Word/飞书、评审于会议、最终录入系统Jira/Tapd。每一个环节都是信息损耗点聊天记录里的关键上下文可能丢失文档格式不统一关键信息如用户角色、验收标准可能遗漏评审会上大家容易陷入细节争论而偏离主线。更麻烦的是当开发过程中遇到模糊地带需要回溯需求初衷时往往要跨多个平台翻找历史记录效率极低。2.2 Claude Code Skill的独特优势Claude Code Skill完美地嵌入了“对话即生产”的上下文。它的优势在于上下文连贯性整个需求梳理的对话历史、你提供的原始材料如会议纪要、用户反馈截图、Skill生成的中间产物如梳理出的问题列表都天然地保存在同一个对话线程中。这是一个完整的、可追溯的“需求决策链路”。结构化输出与灵活交互并存Skill可以强制输出格式统一的Markdown表格如用户故事地图但同时允许你随时打断它追问“为什么这个优先级更高”或者“这个功能的边界在哪里”。这种在结构化和自由讨论之间的无缝切换是传统工具难以做到的。低门槛与高定制化基于自然语言编写Skill不需要复杂的部署和环境配置。你可以根据自己团队的习惯轻松调整Skill的提问模板、输出格式。比如有的团队习惯用“Given-When-Then”格式描述验收标准有的则喜欢检查清单Skill可以轻松适配。2.3 技能的核心定位引导式访谈官这个Skill的设计哲学不是“自动生成需求”而是“引导你发现需求”。它扮演的是一个经验丰富的业务分析师角色通过一系列预设但灵活的问题引导你从不同维度用户、场景、价值、约束思考帮你把潜意识里的假设和知识显性化。它的价值不在于输出那份最终文档而在于引导思考的过程本身。3. 技能实现详解从构思到代码创建一个Claude Code Skill核心是编写一个skill.json配置文件和一个或多个提示词Prompt文件。下面我拆解整个实现过程。3.1 技能元信息定义 (skill.json)这个文件定义了技能的基本信息让Claude认识它。{ name: DemandMiner, description: 一个专业的业务需求挖掘与结构化助手。通过深度对话将模糊的想法、零散反馈转化为清晰、可执行的产品需求与用户故事。, authors: [[你的名字]], capabilities: { text: true }, prompts: [ { name: core_mining, description: 核心需求挖掘流程, content_path: prompts/core_mining.md }, { name: story_refining, description: 用户故事细化与验收标准生成, content_path: prompts/story_refining.md } ] }name和description这是技能在Claude技能列表里展示的名字和简介。描述要清晰说明技能的价值吸引目标用户使用。prompts这里定义了两个提示词模块。core_mining负责核心的需求探索和梳理story_refining负责将初步需求加工成更细致的开发素材。这种模块化设计让技能更灵活用户可以根据当前阶段选择切入。3.2 核心提示词设计 (prompts/core_mining.md)这是技能的“大脑”包含了所有的引导逻辑和输出格式指令。内容较长我分段解释。# 角色与使命 你是一位资深产品专家与业务分析师擅长通过提问和结构化思考挖掘用户和业务的真实需求。你的任务是引导用户澄清模糊的需求输入共同产出结构化的需求清单。 # 工作流程 我们将按以下步骤协作每一步我都会给出引导。你可以随时提供任何形式的原始材料对话截图、邮件、一句话想法等。 ## 步骤1需求原始材料收集与背景澄清 首先请用你自己的话描述你想解决什么问题或实现什么目标或者直接粘贴相关的聊天记录、文档片段。 我会根据你的输入与你确认 1. **核心问题**我们究竟要解决什么用户的什么痛点用一句话概括 2. **涉及角色**哪些用户或系统会与此相关例如前端用户、后台管理员、支付系统 3. **业务背景**这个需求源于哪个业务场景或目标例如为了提升新用户注册转化率、解决客服投诉率高的问题 ## 步骤2多维度需求探索 基于澄清的背景我将从以下几个维度向你提问请逐一思考回答。不必一次答全我们可以讨论。 * **用户维度**目标用户是谁他/她当前是如何完成这个任务的描述现状的完整路径 * **场景维度**这个需求会在什么具体情境下发生时间、地点、前置条件 * **价值维度**满足这个需求后对用户和业务分别带来什么可衡量的价值例如用户节省XX时间业务提升XX%指标 * **约束维度**有哪些限制条件技术限制、合规要求、时间预算、依赖其他团队 ## 步骤3需求结构化与优先级排序 讨论得差不多了现在我们来整理产出物。我会生成一份初步的 **“需求特性清单”**格式如下 | 特性ID | 特性名称 | 用户价值描述 | 关联用户角色 | 优先级 (H/M/L) | 初步估算复杂度 | | :--- | :--- | :--- | :--- | :--- | :--- | | F-01 | 【示例】一键导入联系人 | 销售用户无需手动输入节省每次至少5分钟 | 销售员 | H | 中 | | F-02 | ... | ... | ... | ... | ... | **优先级建议** - **H (高)**核心价值没有它需求不成立。 - **M (中)**重要增强能显著提升体验或效率。 - **L (低)**锦上添花或有更好。 ## 步骤4后续行动建议 根据我们梳理出的清单我会建议下一步行动例如 1. 针对某个高优先级特性进入详细的“用户故事细化”环节。 2. 识别出需要进一步调研的模糊点如与第三方系统集成的具体接口。 3. 建议可以制作原型Prototype进行验证的功能点。 # 交互风格 - 每次提问或推进步骤前我会明确说明当前阶段。 - 我会使用“我们”来强调协作关系。 - 我的提问将具体、开放避免“是/否”问题例如问“用户在这个环节可能会遇到什么困难”而非“这个环节有困难吗”。 - 当你提供的信息矛盾或过于模糊时我会指出并请求澄清。 现在让我们开始吧请从 **步骤1** 开始告诉我你的初始想法。设计要点解析明确的角色与流程开头就定调让AI理解其任务不是聊天而是引导一个结构化流程。渐进式引导步骤1到3是经典的“背景-发散-收敛”思考框架符合需求挖掘的认知规律。模板化输出强制要求以Markdown表格输出确保了信息的结构化、可比性。特性ID为后续跟踪提供了锚点。定义清晰的标准对“优先级”给出了具体定义H/M/L减少了主观歧义。灵活的入口允许用户粘贴任意格式的原始材料Skill会从中提取信息这非常贴合实际工作场景需求往往始于一段聊天记录。3.3 用户故事细化提示词 (prompts/story_refining.md)当核心需求清单中的某个高优先级特性需要进一步细化时就启用这个技能。# 角色与使命 你现在是敏捷教练兼资深开发负责将一个大特性拆解为可供开发团队直接执行的、颗粒度合适的用户故事User Story并定义清晰的验收标准。 # 输入与输出 你需要我提供一个具体的“特性名称”或“特性ID”来自需求特性清单。然后我们将合作完成以下工作 1. 拆解出若干**用户故事**格式作为[角色]我希望[达成目标]以便[获得价值]。 2. 为每个用户故事定义**验收标准**Acceptance Criteria采用Given-When-Then格式或检查清单。 3. 识别技术依赖与非功能性需求。 # 工作流程 ## 步骤1确认与拆解 请提供特性描述。我将 - 确认我理解正确。 - 提出拆解建议这个特性可以沿着“用户操作流程”、“数据状态变化”或“不同用户角色”哪个维度拆解更合理并与你讨论。 ## 步骤2撰写用户故事与验收标准 对于每一个拆解出的子功能点我将引导你完善 * **用户故事**确保角色、目标、价值三者完整。 * **验收标准** * **Given**故事开始前的系统状态与用户上下文。 * **When**用户执行的核心操作。 * **Then**系统应有的明确响应和结果。 * 可选**And**额外的场景或边界情况。 ## 步骤3补充信息与生成卡片 最后我将汇总生成完整的用户故事卡片包含 - 故事标题Story Title - 故事描述User Story - 验收标准Acceptance Criteria - 技术备注/依赖Dependencies - 非功能性需求考虑如性能、安全性 # 示例输出格式 **故事卡片US-01** * **标题**销售员批量导入客户联系人 * **故事**作为一名销售员我希望能够通过上传CSV文件批量导入客户联系人信息以便快速初始化我的客户库无需手动逐个录入。 * **验收标准** 1. Given 销售员进入“联系人管理”页面When 点击“批量导入”按钮Then 系统应弹窗提示选择文件并显示支持的格式CSV列头为姓名、电话、公司。 2. Given 销售员上传了格式正确的CSV文件When 点击“上传”按钮Then 系统应解析文件并在预览界面显示前5条数据并提示总条数。 3. Given 在数据预览界面When 销售员确认导入Then 系统应将数据存入后台并显示“导入成功共导入N条记录”其中重复电话号相同的记录应被跳过并记录日志。 4. Given 销售员上传了格式错误的文件如TXTWhen 点击“上传”Then 系统应提示“文件格式不支持请上传CSV格式文件”。 * **依赖**需要后端提供文件上传解析API。 * **非功能性需求**单次导入支持最多1000条记录解析和导入过程应在10秒内完成。 让我们开始请告诉我你要细化的特性是什么设计要点解析精准的输入输出明确要求输入来自上一个流程的产出特性ID保证了流程的连贯性。引导拆解策略不是机械地拆分而是先讨论拆解维度流程、数据、角色这能帮助用户思考更全面避免遗漏。提供完整模板示例输出格式就是一个极佳的模板用户和AI可以共同向这个模板里填充内容极大提升了协作效率。包含非功能性需求提醒考虑性能、安全等开发时常忽略但至关重要的点。4. 实战演练一个完整的需求挖掘会话假设我现在有一个模糊的需求“我们的小程序需要增加一个会员积分功能”。让我们看看如何与DemandMiner技能协作。4.1 启动技能与背景澄清我启动Claude选择DemandMiner技能并输入“我们的小程序需要增加一个会员积分功能大概就是用户买东西能积分积分能换东西。” 技能会进入core_mining流程并开始提问“我们开始步骤1需求原始材料收集与背景澄清。你提到了‘小程序增加会员积分功能’。为了更准确我需要和你确认几个背景问题核心问题我们希望通过积分功能主要解决什么业务问题是提升用户复购率还是增加用户粘性或是为了收集用户消费数据涉及角色除了小程序端用户后台运营人员是否需要管理积分如发放、调整、查看报表业务背景这个需求是来自最近的用户调研还是为了应对竞争对手的类似功能”通过我的回答技能逐步明确了背景核心问题是提升用户月度复购率角色包括普通用户和运营管理员背景是竞品都有积分体系且用户反馈希望有消费激励。4.2 多维度探索进入步骤2技能会从各个维度发起追问用户维度“能描述一下一个典型用户从打开小程序到完成支付获得积分的完整当前路径吗积分到账后他如何知晓在哪里查看”场景维度“积分兑换功能你设想是用户主动进入一个‘积分商城’兑换还是在支付时直接抵扣现金或者两者都有”价值维度“你期望上线积分功能后用户月度复购率提升多少有没有一个可衡量的目标比如从20%提升到25%”约束维度“积分数据需要和现有的订单、用户体系打通吗有没有财务上的合规要求比如积分是否等同于资产希望在多长时间内上线第一期”在一问一答中我原本模糊的想法被逼着具体化积分实时到账并有消息通知先做积分获取和查看兑换功能放第二期第一期希望两个月内上线与现有用户中心对接。4.3 结构化输出与排序讨论后技能在步骤3生成如下表格特性ID特性名称用户价值描述关联用户角色优先级 (H/M/L)初步估算复杂度F-01消费赠积分规则与实时到账用户完成支付后立即获得积分反馈感知激励及时小程序用户H高F-02个人积分账户与明细查询用户可随时查看积分总额及变动历史建立信任感小程序用户H中F-03积分兑换商城商品上架与展示为用户提供积分消耗出口形成激励闭环小程序用户M高F-04后台积分规则管理发放、调整运营人员可灵活配置积分活动与处理异常运营管理员M中F-05积分过期与清零规则避免积分无限累积带来的财务与系统压力系统L低F-06积分兑换订单处理与发货完成实物兑换的履约流程运营管理员L高这个表格一出来整个需求的轮廓和重点瞬间清晰。我和团队一眼就能看出F-01和F-02是必须的MVP最小可行产品F-03和F-04是增强核心体验的重要功能而F-05和F-06可以后续迭代。4.4 进入细化阶段我决定优先细化F-01。我切换到story_refining提示词或直接在对话中要求技能进入细化模式输入“请细化特性F-01消费赠积分规则与实时到账。” 技能会引导我拆解“这个特性可以按‘规则配置’和‘执行反馈’两个维度拆解。我们先讨论规则积分规则是固定的如1元1分还是支持运营后台灵活配置如活动期间双倍积分” 经过几轮讨论最终生成2-3个像前文示例那样详细的用户故事卡片包含了完整的验收标准。这些卡片几乎可以直接复制粘贴到Jira或腾讯文档的敏捷看板中。5. 避坑指南与实操心得在实际开发和使用这个Skill的过程中我积累了一些关键经验能帮你少走弯路。5.1 提示词编写的核心陷阱避免过于开放或封闭提示词既不能是“随便聊聊”也不能是一份死板的问卷。要在“引导框架”和“自由发挥”之间找到平衡。我的经验是用明确的步骤Step 123搭建框架但在每个步骤内使用开放式问题What How Why引导思考。给AI明确的输出格式指令core_mining.md中要求用Markdown表格输出story_refining.md中给出了示例卡片。这是必须的没有格式指令AI的输出会五花八门失去结构化价值。指令要具体到表头、字段名。定义清楚关键术语像“优先级H/M/L”必须在提示词里给出定义。否则你和AI可能对“高优先级”的理解完全不同。5.2 使用过程中的最佳实践扮演“用户”而非“考官”使用技能时要把自己当成和一位资深同事在开会目的是共同厘清问题。积极提供你所知道的一切背景信息哪怕它很零碎。AI的提问是为了帮你查漏补缺而不是考试。善用“停止”与“追问”如果AI的提问偏离了方向或者你发现某个问题自己还没想清楚可以直接说“我们先跳过这个问题回到刚才的XXX”或者“关于这一点我需要和业务方确认一下我们暂时记下”。这个对话的主导权在你。迭代优化你的Skill第一次编写的提示词不可能完美。在使用几次后你可能会发现某些问题总是需要重复解释或者某个输出格式不实用。这时直接去修改对应的.md文件。比如我发现团队更习惯用“检查清单”而非“Given-When-Then”我就把story_refining.md里的验收标准格式改成了清单式。5.3 技能管理的经验版本管理skill.json和提示词文件是纯文本强烈建议用Git进行版本管理。你可以为不同的项目或团队分支创建不同的变体。起个好名字skill.json里的name和description要直观。DemandMiner需求矿工就比RequirementHelper更能体现其“挖掘”的内涵。模块化设计像我一样将core_mining和story_refining分开是明智的。你还可以创建第三个模块叫prd_generator用于将前面所有的产出整合成一份正式的产品需求文档框架。5.4 效果评估与局限认知这个技能极大地提升了需求讨论的效率和产出质量。它迫使你在前期进行更深入的思考减少了后期返工。但它也有局限无法替代深度用户调研它梳理的是“你已知”或“你假设”的需求。对于未知的用户痛点仍需通过访谈、观察等传统调研手段发现。依赖输入质量垃圾进垃圾出。如果你提供的初始想法过于天马行空或矛盾技能的输出也会混乱。它擅长的是“梳理”和“结构化”而不是“无中生有”。不涉及UI/UX细节它产出的是功能性需求和非功能性需求。对于具体的界面布局、交互细节需要结合原型设计工具。我个人最深的体会是这个技能最大的价值是创造了一个结构化的对话场域。它让需求讨论从漫无目的的“头脑风暴”变成了目标明确的“协同工作”。每次使用它都像是一次高质量的需求评审预演很多潜在的问题在对话阶段就被暴露和解决了。对于任何需要将想法落地的产品人、技术人来说这都是一件值得投入时间打造的“思考利器”。
