Emma, AI Product Manager — AtomsEmma·Product Manager

可撰写可交付 PRD 的 AI 产品经理代理

Emma 将想法转化为你的 AI 团队当天就能构建的 PRD,而不是那种在文档里躺上两个冲刺周期的规格说明。

从想法到明确范围的功能,只需一次对话。

受到这些公司的创作者信赖:

为什么 PRD 只是停留在文档里,而不是被交付上线

  • 没人能落地实现的 PRD

    ChatPRD 能写出一份精美的文档,但你的工程师仍然得重新解读它、拆分成工单,并四处补齐缺漏。Emma 撰写的 PRDAlex 可直接当作事实来源阅读的版本,没有任何转译层。

  • 规格与代码从第一天就开始脱节

    PRD 放在 Notion,代码放在 GitHub,产品则活在生产环境里。到了第二个迭代,它们讲的已经是三个不同的故事。Emma 将 PRD 保持在与代码相同的工作空间中,让它持续作为事实来源。

  • 没人预警的范围蔓延

    单人 PRD 工具会按你的要求写下任何内容。Emma 会主动提出 v1 的裁剪方案,并对范围漂移提出异议,而不是悄悄把一个 2 周的功能变成一个 2 个月的项目。

  • 永远产不出 PRD 的反馈聚合工具

    Productboard 能收集成千上万条反馈,但要把它们整理成团队可交付的规格,依然还是人的工作。Emma 能基于 Iris 的研究或一个原始想法,写出工程团队可以据此开发的用户故事。

Emma的一天

从你的第一个提示词到交付结果——这就是 Emma 的实际运作方式。

  1. 01

    从 Iris 获取已验证的方向

    Emma 从一个真实且已验证的机会出发——而不是“我洗澡时突然想到一个点子”。

    Iris, AI Deep Researcher移交给 Iris
  2. 02

    梳理用户故事和验收标准

    谁在什么时候做什么,以及我们如何知道它是否奏效?清晰到工程师可以直接据此构建。

  3. 03

    将范围收缩到能赢的 v1

    将规格限定为能够验证假设的最小版本——范围蔓延会在这里被发现。

  4. 04

    让 Bob 和 Alex 参与可行性讨论

    在规范最终敲定前,就会将架构权衡和构建时间纳入考虑——构建过程中不会出现意外。

    Bob, AI Architect移交给 Bob
  5. 05

    锁定规格并交付构建

    PRD 会直接进入构建队列——这是 PM、架构和工程共享的同一份产物。

Emma 交付清晰规范所需的一切

结构化 PRD 模板

每次都以一致的格式包含问题、目标、用户、范围、范围外内容和成功指标。

带验收标准的用户故事

每条故事都可实施、可测试,而不是模糊的功能愿望。

范围与风险标记

Emma 会标记含糊不清的需求,并提出 v1 精简方案,而不是把你要求的一切都写进去。

研究集成

在可用时从 Iris 拉取研究发现,使 PRD 建立在真实洞察之上。

直接交接给 Engineer

Alex 将 PRD 作为实施的唯一事实来源来阅读,无需中间转换层。

项目中的动态规范

PRD 与代码一起保存在编辑器中,因此更新对整个团队始终可见。

轻量级模板

根据你的实际需要,在快速的内部工具规范和完整的功能 PRD 之间调整详略层级。

Emma加入你的团队后,会发生什么变化

手工搭建的工作流缓慢、依赖人工且需要大量工具。将鼠标悬停在任意卡片上,查看每项收益为何重要。

为什么创作者会在众多选择中选Emma

对比

正从 ChatPRD 转来?以下就是 Emma 更胜一筹的地方。

01

能真正构建产品的规格说明,而不是束之高阁的文档

ChatPRD 会生成一份精炼完善的 PRD,并永久保存在 Notion 中。Emma 的规格说明会直接进入 Bob 的架构草图和 Alex 的构建计划——你写下的文档几天内就会变成产品,而不是等到下个季度。

02

范围得到控制,而非被拉大

大多数 PRD 工具对每个功能想法都说好。Emma 会问:“能证明这可行的最小版本是什么?”并据此撰写规格说明。范围蔓延会在规格阶段被发现,而不是等工程已经开始之后。

03

连接到负责交付的团队

Notion AI 就在你的 wiki 中。Emma 与 Iris(研究)、Bob(架构)、Alex(工程)和 Mike(审批)协同工作——这样一来,在你投入哪怕一个工程工时之前,PRD 就已经由将要构建它的团队完成审阅。

Atoms 与 ChatPRD:比较功能、价格和能力

功能
Atoms
推荐
ChatPRD
输出
可用于构建的规格说明
润色后的文档
连接到工程团队
移交给 Alex
存在于 Notion 中
内置范围控制
V1 思维
对每个想法都说好
让架构师参与可行性讨论
在规格锁定之前
你需要分别询问
验收标准
每个用户故事
每个用户故事

Emma 如何与你的其他 AI 团队成员协作

Emma 并不是单独工作。以下是你与完整团队协作构建时,各项交接如何落地。

Emma 为产品团队撰写的内容

Emma 产出的可直接交付给工程团队的具体产品工件。

  1. 功能 PRD

    针对单个功能的完整 PRD,包含问题、范围、用户故事和验收标准。

    编写功能 PRD
  2. MVP 范围文档

    定义 v1 要交付什么、哪些内容延后,这样你发布的是一个有用的产品,而不是一个完美但不存在的产品。

    定义 MVP 范围
  3. 用户故事集

    包含清晰验收标准的用户故事,便于工程师据此进行开发和测试。

    编写用户故事
  4. Sprint 范围规划

    将一个功能拆分为可交付的小块,让每个 Sprint 都能产出可供演示的内容。

    规划一个 Sprint
  5. 内部工具规格说明

    适用于内部工具的轻量级 PRD,需要清晰的范围定义,但不必达到面向客户产品的严谨程度。

    定义工具范围
  6. 发布清单

    在发布前定义“完成”意味着什么,确保上线时不会遗漏任何关键事项。

    规划一次发布

试试这些与 Emma 一起使用的提示

为新功能编写 PRD

@Emma 为我们的 SaaS 推荐计划编写一份 PRD。提取 Iris 的受众研究,定义问题、范围、非范围项和 v1 指标,然后编写 Alex 可据此开发的用户故事及验收标准。

从一句话界定 MVP 范围

@Emma 我想在 4 周内推出一款面向自由职业者的时间追踪 SaaS。先问我正确的澄清问题,然后提出一个能交付有用功能的 v1 范围,并清晰列出哪些内容留待 v2。

削减范围过大的功能

@Emma 当前的通知 PRD 有 14 个用户故事,而我们只有一位工程师一周的时间。请将其缩减为 3 个能交付核心价值的故事,标明我们会失去什么,并重写文档。

制定发布检查清单

@Emma 我们下周四发布 invoicing 模块。请编写发布检查清单,涵盖验收标准、David 的跟踪规范、Sarah 的落地页状态,以及 Adrian 的活动准备情况。

认识 Emma 的其他 AI 团队成员

没有任何一个智能体是单独工作的。点开任意队友,即可查看他们如何处理你产品中的那一部分。

常见问题

让 Emma 为你效劳

别再写没人看的 PRD。让 Emma 在 Atoms 中撰写你的 AI Team 当天就能构建的规格说明。