# Ym Pmintake

> 面向客户沟通的 AI 应用、智能体和自动化工作流项目前期需求澄清。用于客户只提出“想做 AI/智能体”、需求模糊、需要判断项目是否值得做、选择首个 MVP 场景、明确资料与系统条件、风险边界和验收标准时；也用于把访谈记录整理成可评估、可启动的项目简报。不要把它当作内部需求申请表或直接进入技术方案设计。

- Skill: `yiming-falcon/ym-pmintake` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add yiming-falcon/ym-pmintake`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yiming-falcon/ym-pmintake/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yiming-Falcon (https://skillmd.com/u/yiming-falcon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yiming-falcon/ym-pmintake

---


# YM PM Intake

把“客户想做一个 AI 工具”转化为可判断价值、可限定范围、可用真实案例验收的项目简报。

## 核心原则

- 先问业务问题，再谈智能体形态和技术方案。
- 先找真实流程、资料和损失，再判断 AI 能做什么。
- 一次只追问最影响下一步判断的问题，不机械逐题访谈。
- 优先选择高频、痛点明确、资料可得、出错可控的最小场景。
- 把事实、假设、待确认项分开，不替客户补造答案。
- 人只参与价值判断、风险授权和验收；Agent 负责整理、追问和形成交付物。

## 执行流程

### 1. 接住现有信息

先复述已经明确的内容，并标注：

- 已知事实
- 当前假设
- 关键缺口

不要重复询问用户已经提供的信息。

### 2. 做立项价值判断

围绕五个问题收敛：

1. 谁在什么场景中遇到什么业务问题？
2. 现在如何处理，最痛或最贵的环节是什么？
3. 不解决会造成什么损失？
4. AI 预期执行什么动作，输出什么结果？
5. 做好后如何观察到业务改善？

如果问题低频、损失很小、没有可用资料或无法定义好坏，明确指出项目暂不适合产品化，并给出更轻量的人工或半自动方案。

### 3. 补齐实施条件

按当前缺口选择性追问：

- 资料：需要读取什么，在哪里，哪个版本为准，质量是否可用。
- 流程：谁执行、频率多高、有哪些例外、谁能给出标准答案。
- 用户：谁使用，使用入口和操作习惯是什么。
- 系统：需要连接哪些文件夹、邮箱、协作平台或业务系统。
- 风险：涉及哪些敏感数据，AI 出错的最坏后果是什么。
- 人工把关：哪些动作必须在人确认后才能继续。

先做安全快速筛查：

- 是否处理个人信息、敏感个人信息、未成年人信息或商业秘密？
- 数据会存在哪里，是否会发给境外模型、云服务或第三方接收方？
- 是否接入邮箱、协作平台、数据库、业务系统、支付或其他可写工具？
- 是否使用付费 API，谁承担成本，如何限制滥用？
- AI 是否可以自动发送、发布、删除、付款、修改权限或执行其他高影响动作？
- 如果输出或自动动作出错，最坏后果是什么？

命中真实个人信息、外部用户、付费接口、可写系统或高影响自动化时，把项目至少标为“需要 `ym-pmsafety` 专项审查”，不要在需求澄清阶段假装完成完整安全评估。

需要完整访谈题库时，读取 [references/client-discovery-question-bank.md](references/client-discovery-question-bank.md)。

### 4. 收敛第一阶段 MVP

选择一个最小闭环，至少满足：

- 有明确使用者和触发场景。
- 有真实输入资料。
- 有具体输出物。
- 有 3 个测试案例：普通、复杂、易错各 1 个。
- 有明确人工确认节点。
- 可在较短周期内判断是否继续投入。

如果存在多个候选场景，按业务价值、使用频率、资料可得性、实现难度和错误风险进行比较，并推荐一个首发场景。

### 5. 定义验收

把“效果不错”改写为可检查标准。至少说明：

- 测试材料和样本量
- 验收负责人
- 正确性或完整性标准
- 时间、成本或错误率改善目标
- 失败时如何回退到人工流程

不要随意承诺准确率。没有基线和样本时，把数字标为待验证假设。

### 6. 输出项目简报

使用以下结构：

```markdown
# AI 项目前期需求简报

## 一句话项目定义
谁在什么场景下，使用什么资料，让 AI 完成什么动作，获得什么结果。

## 业务问题与现状
## 用户与干系人
## 预期输入、处理和输出
## 第一阶段 MVP
## 资料与系统条件
## 人工确认与安全边界
## 验收方式
## 已知事实、假设与待确认项
## 是否建议启动
## 下一步行动
```

在简报末尾按 [references/pm-handoff-contract.md](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`：长期工作空间整体结构和治理，不代替单个项目的需求澄清。