yiming-Falcon YM PM Intake
把“客户想做一个 AI 工具”转化为可判断价值、可限定范围、可用真实案例验收的项目简报。
核心原则
- 先问业务问题，再谈智能体形态和技术方案。
- 先找真实流程、资料和损失，再判断 AI 能做什么。
- 一次只追问最影响下一步判断的问题，不机械逐题访谈。
- 优先选择高频、痛点明确、资料可得、出错可控的最小场景。
- 把事实、假设、待确认项分开，不替客户补造答案。
- 人只参与价值判断、风险授权和验收；Agent 负责整理、追问和形成交付物。
执行流程
1. 接住现有信息
先复述已经明确的内容，并标注：
- 已知事实
- 当前假设
- 关键缺口
不要重复询问用户已经提供的信息。
2. 做立项价值判断
围绕五个问题收敛：
- 谁在什么场景中遇到什么业务问题？
- 现在如何处理，最痛或最贵的环节是什么？
- 不解决会造成什么损失？
- AI 预期执行什么动作，输出什么结果？
- 做好后如何观察到业务改善？
如果问题低频、损失很小、没有可用资料或无法定义好坏，明确指出项目暂不适合产品化，并给出更轻量的人工或半自动方案。
3. 补齐实施条件
按当前缺口选择性追问：
- 资料：需要读取什么，在哪里，哪个版本为准，质量是否可用。
- 流程：谁执行、频率多高、有哪些例外、谁能给出标准答案。
- 用户：谁使用，使用入口和操作习惯是什么。
- 系统：需要连接哪些文件夹、邮箱、协作平台或业务系统。
- 风险：涉及哪些敏感数据，AI 出错的最坏后果是什么。
- 人工把关：哪些动作必须在人确认后才能继续。
先做安全快速筛查：
- 是否处理个人信息、敏感个人信息、未成年人信息或商业秘密？
- 数据会存在哪里，是否会发给境外模型、云服务或第三方接收方？
- 是否接入邮箱、协作平台、数据库、业务系统、支付或其他可写工具？
- 是否使用付费 API，谁承担成本，如何限制滥用？
- AI 是否可以自动发送、发布、删除、付款、修改权限或执行其他高影响动作？
- 如果输出或自动动作出错，最坏后果是什么？
命中真实个人信息、外部用户、付费接口、可写系统或高影响自动化时，把项目至少标为“需要 ym-pmsafety 专项审查”，不要在需求澄清阶段假装完成完整安全评估。
需要完整访谈题库时，读取 references/client-discovery-question-bank.md。
4. 收敛第一阶段 MVP
选择一个最小闭环，至少满足：
- 有明确使用者和触发场景。
- 有真实输入资料。
- 有具体输出物。
- 有 3 个测试案例：普通、复杂、易错各 1 个。
- 有明确人工确认节点。
- 可在较短周期内判断是否继续投入。
如果存在多个候选场景，按业务价值、使用频率、资料可得性、实现难度和错误风险进行比较，并推荐一个首发场景。
5. 定义验收
把“效果不错”改写为可检查标准。至少说明：
- 测试材料和样本量
- 验收负责人
- 正确性或完整性标准
- 时间、成本或错误率改善目标
- 失败时如何回退到人工流程
不要随意承诺准确率。没有基线和样本时，把数字标为待验证假设。
6. 输出项目简报
使用以下结构：
# AI 项目前期需求简报
## 一句话项目定义
谁在什么场景下，使用什么资料，让 AI 完成什么动作，获得什么结果。
## 业务问题与现状
## 用户与干系人
## 预期输入、处理和输出
## 第一阶段 MVP
## 资料与系统条件
## 人工确认与安全边界
## 验收方式
## 已知事实、假设与待确认项
## 是否建议启动
## 下一步行动
在简报末尾按 references/pm-handoff-contract.md 输出或更新 pm_handoff。如果项目需要安全专项审查，将 next_gate 设为 ym-pmsafety；需要建立或整理项目空间时设为 ym-pmclean。
对话方式
- 信息足够时直接生成简报，不为走流程继续提问。
- 信息不足时，每轮集中提出 1-3 个最高价值问题，并说明这些答案会影响哪项判断。
- 待确认项优先在当前对话中集中询问，不要求用户逐个打开 Markdown 文件确认。
- 涉及密钥、隐私、对外发送、付款、删除或线上权限时，暂停并取得明确授权。
与相邻 Skill 的边界
ym-pmintake：项目前期判断、需求澄清、MVP 和验收定义。ym-pmclean：项目启动后或阶段收尾时的项目内部文件与知识整理。ym-pmsafety：上线、交付、共享、接入系统或执行高风险动作前的专项安全审查。ym-workspace：长期工作空间整体结构和治理，不代替单个项目的需求澄清。