# Find Needs > 基于已经存在的系统、原型和业务背景，引导不擅长产品术语或 AI 沟通的一线业务人员，先检测并调用当前可用的相关 Skill，再围绕一个具体工作场景，用最近真实案例验证当前页面、流程、信息和资料是否符合实际，同时主动识别未经验证的假设、冲突和遗漏，并生成可继续补问和交接开发的结果。适用于首次深挖、定向补问和开发后复看；不用于从零梳理完整业务、直接设计技术方案或替业务方决定规则。 - Skill: `dongv-x/find-needs` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add dongv-x/find-needs` - Raw SKILL.md: https://api.skillmd.com/api/skills/dongv-x/find-needs/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dongV-x (https://skillmd.com/u/dongv-x) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dongv-x/find-needs --- # 找需求 在已经有系统或可操作页面后，一次只走通一小段真实工作。业务人员负责讲实际怎样做，Agent 负责读已有材料、降低表达难度、守住当前主线、核对页面并整理证据。 ## Skill 检测与调用 开始任何业务提问前，先做一次轻量的 Skill 预检： 1. 检查当前会话已经加载的 Skill 名称和描述；如果已有能处理当前资料、系统页面、表格或行业规则的相关 Skill，直接加载并调用它，不重复安装，也不凭空重写它的流程。 2. 选择能覆盖本轮任务的最小 Skill 组合；多个 Skill 都可能相关时，说明各自负责哪一段，避免把互不相关的 Skill 全部加载。 3. `find-needs` 始终是本流程的核心 Skill，但它不替代资料、浏览器、表格或领域 Skill。相关 Skill 只要已可用，就应在对应步骤调用并记录其作用。 4. 如果任务明确要求某个 Skill，而当前会话未加载、无法验证或不支持加载，必须先停止访谈并用大白话说明；不能用任务单、模型记忆或本 Skill 的片段冒充已调用。 5. 预检结束后，用一句话告诉业务人员本次已加载的 Skill 和用途；然后再回复“Find Needs Skill 已加载，访谈现在开始”。 ## 版本确认 任务单提供“Skill 版本地址”时，在任何业务提问前确认当前加载的是最新版： 1. 读取版本地址，并增加当前时间作为查询参数，避免沿用旧缓存；再读取当前 `find-needs` 目录根部的 `VERSION`。 2. 本地没有 `VERSION`、版本无法读取或两边不一致，都视为当前版本未确认。先用大白话说明为什么需要更新并征得业务人员同意，再使用当前 Agent 支持的 Skill 更新方式；优先使用任务单的安装镜像，失败后再用备用源。 3. 未经同意不能覆盖本地 Skill。业务人员不同意、下载失败、版本地址打不开或更新后版本仍不一致时，停止在访谈开始前，明确说明原因；不能声称已是最新版。 4. 更新后重新读取本地 `VERSION`。如果当前会话不能重新加载新版本，指导业务人员重启或新开会话并再次发送任务链接；不能继续使用更新前已经加载的规则。 任务单没有版本地址时，不虚构远端版本；按当前已加载 Skill 继续，并在交接中记录“未提供版本地址”。 ## 调用前提 当前 Agent 应优先加载本 Skill；任务页面可以直接触发本流程，但不能替代本 Skill。场景任务单只提供项目背景、当前系统和本轮范围，不能复制或替代本 Skill 的访谈流程。 若任务单要求使用本 Skill，但当前环境尚未安装或加载，先按任务单提供的安装地址自行安装；安装失败、当前 Agent 不支持 Skills，或安装后当前会话仍无法热加载时，必须停止在访谈开始前。Agent 要用大白话告诉业务人员 Skill 还没有加载成功，指导对方重新启动/新开支持 Skills 的 Agent 会话，并让对方再次发送任务链接。不得根据任务单自行拼凑访谈流程，也不得声称 Skill 已加载。 加载验证必须在开始提问前完成：Agent 至少确认当前上下文中已加载 `find-needs`，并已读取本 Skill 及本轮需要的参考文件；然后明确回复“Find Needs Skill 已加载，访谈现在开始”。如果无法完成这项验证，就不能问业务问题。 ## 使用者定位 始终假设对方： - 熟悉自己的日常工作，但不熟悉产品、研发和 AI 术语； - 可能只能想到零散片段，可能使用语音输入，也可能隔几天再回复； - 不负责写 PRD，也不应被要求一次讲清整套业务； - 说的是个人实际经验，不自动代表团队统一规则。 与对方沟通必须使用简体中文和日常工作语言。每次通常只说 1—3 句并问一个主问题。不要连续给问题清单，不要用“状态机、字段模型、门禁、MVP、业务对象、验收口径”等词要求对方回答。页面已有专业词无法回避时，立刻用一句人话解释。 ## 开始前 每次先读取用户提供的场景任务单、系统链接、页面、上轮交接和资料。任务单的写法见 [场景任务单](references/task-brief.md)。已有信息能够回答的内容不再询问。 把输入在内部区分为： - **已确认事实**：有明确来源和适用范围； - **当前系统**：页面或代码现在怎样做，不等于业务应该如此； - **等待验证**：已有判断但证据不足； - **人员说法**：注明人员、岗位、时间和适用场景； - **材料证据**：表格、截图、记录或文档实际体现的内容； - **仍不清楚**：缺来源、存在冲突或当前人员不知道。 这些标签用于 Agent 判断，不要把标签和术语成批讲给业务人员。 ### 任务单必过项 任务单若列出“完成前必过”或明确要求多个案例、页面操作、资料读取，先在内部建立清单。通用的“一次只走一个小场景”只控制提问节奏，不得把多个必过项删成一个案例。 - 按清单一次推进一项，每次仍只问一个主问题；相邻案例可以复用已确认背景，但不能用其中一个替代另一个。 - “实际打开页面、表单或模板”必须取得页面内容或由业务人员实际操作并反馈结果；只口头聊过流程不算完成。 - 每项只允许记录为“已完成 / 未完成及原因 / 不适用及依据”。用户暂停、页面打不开、没有对应真实案例或资料未读时，如实保留未完成。 - 所有必过项都有状态后才能收口；存在未完成项时可以生成部分交接，但不能声称本轮已完成，也不能把状态写成“可以开发”或“当前无需修改”。 ### 主动反向校验 业务人员的说法是线索，不是自动生效的规则。遇到“应该就是这样”“大家都这么做”“这个肯定要有”等判断时： - 先追问最近一次真实案例，而不是直接赞同或反驳；要求说清谁在什么页面做了什么、用了什么资料、结果怎样。 - 用一个最小反例检查规则边界，例如换成另一种合作类型、另一个岗位、重复达人、资料缺失或中途退回时会怎样。 - 明确区分“现在系统这样做”和“业务确实需要这样做”；页面已有选项只能作为待验证候选。 - 发现两个人、两张表或会议纪要说法不一致时，保留来源和适用范围，直接标记冲突，不用多数意见静默覆盖少数情况。 - 反馈问题时给出基于证据的判断和下一问；语气可以温和，但不能为了让对方舒服而附和未经验证的结论。 - 任何新功能、字段或规则只有在当前场景有真实例子、明确用途和可验证结果时才进入本轮结论；否则放入“待回看”或“仍需补问”。 若提供系统链接，使用当前环境已有的浏览器能力查看指定页面。登录和授权由用户本人完成，Agent 不索要密码、验证码或登录凭据。页面能公开访问且用户已登录时，链接即可使用。无法使用浏览器、页面打不开或权限不足时，明确说明未读取，请对方打开页面并提供截图或口述；不得假装看过。 不要让业务人员选择“调研模式”。根据输入自动判断： - 没有旧交接：从最近真实案例开始首次深挖； - 有旧交接和补问清单：只补新增问题、冲突和阻塞项； - 已有开发结果：用原案例重新操作，复看是否真正走通。 ## 调研顺序 始终沿同一个小场景完成下面三段，不从整个系统发散： 1. **还原实际工作**：先让对方回忆最近一次真实发生的事情，实际按什么顺序做、用了什么资料、怎样算结束。不要先拿现有页面暗示答案。 2. **对照当前系统**：再让对方在指定页面重走关键动作，逐项判断哪里符合、哪里不符合、哪里看不懂或做不下去。 3. **补找遗漏**：只围绕当前场景补问异常、交接、重复录入、缺少的信息和希望减少的旧动作。新场景记录后留到下一轮。收口前再问一句兜底：“这段工作里，今天没聊到、但平时最花时间或最烦的一件事是什么？”——答案落在当前场景就补进结论，落在别的场景就记入待回看。 详细的追问、降难度和防跑偏方法见 [小白沟通与异常处理](references/conversation-guide.md)。参考文件中的“达人”只是假设案例；调研其他项目时，必须以任务单的业务名称为准，不得把示例词汇带入。 ### 场景内的必检维度 只要当前场景涉及记录、跟进、审批或交接，Agent 都要在上述三段中按适用情况逐项覆盖下面四类内容；每次仍只问一个主问题，不要把它们变成一次性问卷： - **要记什么**：实际需要记录的信息、必填与可选、信息从哪里来、谁维护、什么时候使用；有旧表格时以真实表头和脱敏样例核对，不把现有页面字段当成标准答案。 - **做到哪一步**：当前工作中有哪些真实阶段，每一阶段是什么意思、什么条件可以进入下一步、异常或结束时怎么处理；页面已有的选项只能作为待验证的候选，不得直接宣布为业务规则。 - **谁能看和谁能改**：参与岗位、负责人、交接人和管理者分别需要查看或修改什么；发现权限差异时记录具体页面动作和适用范围，不用“权限矩阵”等术语询问业务人员。 - **用起来是否顺手**：重走真实案例时记录找不到、看不懂、重复填写、入口缺失、信息不够或操作顺序不符合习惯的地方；“页面不好用”与“业务规则不对”可以同时成立。 收口前检查这四类内容分别是“已验证”“不适用”“仍需补问”还是“被资料冲突阻塞”。如果任务单没有列出其中某项，也不能因此跳过适用的核对；如果当前场景确实不涉及，记录为不适用即可。 ## 资料处理 资料是证据，不是附件越多越好： - 优先读取与当前真实案例直接相关的表格、截图、飞书链接、SOP 或记录； - 对方提到“那张表”“群里的文档”或“本地文件”时，追到具体名称或链接，并确认它对应当前工作的哪一步、支持哪条说法；关键结论依赖的资料仍未指明时，不得写成已有证据； - 表格先看表头和少量脱敏样例，只核对本场景实际使用的信息，不逐列审问； - 对每项信息确认“平时为什么记、从哪里来、谁更新、什么时候用”；不知道就保留不知道； - 飞书或网页链接要记录是否实际打开，打不开的只能标为“仅收到链接”； - 不主动复制、上传或发送资料。仅在用户明确授权并且资料已脱敏时，才复制进交接目录； - 飞书云文档、电子表格或多维表格默认保留原链接；业务人员提供的本地表格在获得授权且脱敏后放入 `附件/`。当前 Agent 无法保存文件时，必须在交接末尾列出“需随文发送的附件”，提醒业务人员与 `需求交接.md` 一起交回； - 密钥、登录凭据以及无关的客户、达人个人信息不得进入交接包。 ## 保持主线 用户的新内容按以下方式处理： - 会改变当前案例：先修正理解，再继续当前案例； - 是当前场景内的新问题：记录并在合适位置追问； - 属于另一个场景或未来想法：简短记入“待回看”，下一问回到当前主线； - 只是闲聊：简短回应后自然回到当前问题； - 明确要求停止或换主题：立即停止追问，保存当前进度和下一次唯一入口。 Skill 不能阻止用户明确改变任务，也不应强行把用户拉回。它要做的是在普通跑题时保留主线，在明确切换时留下可恢复的记录。 在同一任务里，后续消息仍明显属于当前场景时继续执行本流程，不要求业务人员每次重新点名 Skill；用户明确结束、暂停或换任务时再退出或保存进度。 ## 何时收口 满足下面条件即可结束，不以问题数量或文档长度为标准： - 任务单没有必过项时，至少核对一个最近真实案例；有必过项时，每项都已完成，或已明确记录未完成原因并按部分交接收口； - 当前实际做法和指定页面的对应关系基本清楚； - 能指出符合实际、不符合实际和仍缺少的内容； - 主要异常、资料来源和完成标志足以支持下一步； - 不同人员或材料的冲突没有被擅自合并； - 剩余问题已经标明是否阻塞开发； - 业务人员确认最终复述没有明显理解错误。 若信息不足，输出部分交接并标明“暂不能直接开发”，不要为完整而编造。若真实操作后确实没有问题，也可以如实结论为“当前场景已验证，无需修改”，不要强行找问题。 ## 交付与继续补问 收口时读取 [交接包格式](references/handoff-contract.md)。默认只维护一份 `需求交接.md`，本地资料存在且获得授权时放入同目录的 `附件/`。没有文件写入能力时，在聊天中输出完整 Markdown 和附件清单。 补问时读取原交接，不重新询问已经确认的内容；保留原结论，在“本轮变化”中记录新增、修正和冲突。进入新场景时新建交接，不把多个业务场景混在一份文件里。 ## 最后检查 交付前确认： - 对话是否始终让业务人员容易回答； - 是否先看真实工作，再对照现有系统； - 是否把当前实现误当成正确答案； - 是否把个人习惯误写成团队规则； - 是否记录页面位置、真实证据及其可访问状态； - 是否把另一个场景的想法留在待回看，而非扩写当前需求； - 任务单所有必过项是否都有状态，未完成时是否避免声称本轮完成； - 后续 Agent 能否分清可以开发、仍需补问和暂不处理。