Agent时代产品经理的新工作方式

在 Agent 时代，我们工作协作、交接的对象不一定是人，还可能是 AI。

在同 AI 协作设计一款产品时，出于偷懒，我们可能会在提示词中遗漏一些信息或者不清楚应该补充什么信息，比如角色权限、敏感数据、失败后的重试与降级、人工兜底以及知识更新后的旧答案失效；一个听起来已经明确的需求，也可能仍然缺少目标用户、验收标准、异常处理和责任边界。进入开发后，还可能出现多个 Agent 任务同时修改同一文件、前置依赖尚未完成、主要路径测试通过但真实账号、异常恢复和部署配置仍未验证等情况。

这些问题不代表团队不专业或者 AI 不够强大，而是在方案设计、原型构建、开发与评审之间容易遗漏掉潜在风险、隐含假设和验证边界。

所以这篇文章想介绍我本机已经安装并且使用了一段时间的四个工作流 skill。它们不是四条更长的提示词，而是把一个模糊任务从“还需要了解什么”，一路带到“怎样执行、怎样验证”的四种工作方式：

• deepresearch 负责扩大证据面，从多个角度认识现状、发现盲区，并把一致、冲突和仍未验证的结论分开；
• brainstorm 负责把模糊想法问具体，先发散比较不同方案，再收敛成可以交接的 PRD；
• plan 负责把已经确认的需求拆成有依赖关系、执行顺序和验证方式的任务计划；
• execute 负责依据计划委派开发与测试任务，收集验证结果，并保留失败、遗留问题和最终状态。

Skill 下载链接（已开源）放在文末

我是在 AWS 工作人员来我们公司分享这套工作方式后，开始接触并理解的。后来我把它们应用到个人的产品开发流程中时，最明显的感受不是“AI 自动把产品做完了”，而是原本容易散落在搜索、讨论、文档和评审里的问题，能够更清晰地被呈现出来，并用于后续改进。下面我想结合设计思维，说明四个 skill 各自解决什么问题、什么时候值得用，以及它们不能替我们做什么。

专业工作也会有注意边界

产品经理、设计师和测试工程师有各自成熟的方法论。但是随着项目的扩大、AI输出越来越多的内容，真正限制工作效率的往往是固有经验、有限的时间和注意力。

一个产品经理可以把眼前问题想得很清楚，但未必同时想清楚各个环节的风险管控、异常处理、恢复机制、长期运维和迁移等；一次沟通可以解决当前分歧，却可能没有留下后来的人能复查的判断理由。对我来说，AI 工作流最值得观察的，不是生成了多少内容，而是它消除了多少信息差，能否帮助我们看见遗漏、逼近模糊处，并保存交接所需的上下文。

我把我们的认知范围按“知不知道”（是否进入注意范围）和“是否清楚”画成了一个很朴素的四象限：

这是我为了理解自己与 AI 如何分工而画的一张实用地图，不是认知科学模型。四种状态会随任务和团队变化，AI 也不能保证找到全部“未知的未知”。它比较实际的作用，是扩大我们当前能看见的范围，并让“我还不知道”成为可以被记录的结论。

四个 skill 与创新设计思维：从理解问题到测试迭代

创新设计思维通常把设计过程概括为共情（Empathize）、定义（Define）、构思（Ideate）、原型（Prototype）、测试和迭代（Test）。Stanford d.school 的设计思维资料^[1]把它们称为五种模式；迭代不是排在测试之后、只发生一次的“第六步”，而是让我们根据新证据在这些模式之间反复往返。IDEO 对设计过程^[2]的介绍也强调，真实工作并不是机械地逐步通关，而是在发散选择、收敛判断、制作和测试之间循环。

如果把这五种模式与四个 skill 放在一起，我会这样理解：

deepresearch：先扩大证据面，再承认还不知道什么

普通检索常从我们已经想到的关键词出发。deepresearch 的差别，不仅是把主题拆成多个角度，还会再并行寻找不同类型的资料，核对原始来源，标记一致、争议和未验证的结论，最后对关键发现继续追问假设、证据、缺失视角和影响。它的输入是一个研究主题及范围约束，输出是一份带来源、置信度、冲突、开放问题和限制的 Markdown 报告。

其中，会把不同代理对同一主张的支持、反对或未发现证据情况整理成交叉验证矩阵，并按下面的标准标记状态和最低置信度：

我会在两类任务里优先想到使用这个 skill。第一类是陌生领域，连“应该问什么”都不清楚；第二类是资料互相冲突，需要把不同说法和证据强度摆在一起，而不是过早选一个顺眼答案。

它最有帮助的地方，也是最容易被误解的地方。多个 Agent 可以从不同角度交叉检查，但不自动等于多个独立专家。如果几个代理最终都引用同一个页面，来源仍然只有一个；相同模型和提示框架也可能产生相关错误。“共识”适合帮助我们暴露一致与分歧，不能当成事实投票器。更准确的说法是：deepresearch skill 为用多角度和来源核对提高可检查性，而不是保证每次研究都完整、正确。

同样，AI 二手研究不能替代真实用户研究。IDEO 对二手研究的定位很清楚：它适合建立背景和启发问题，但真实需求仍要回到访谈、行为观察、共创和可用性测试。我们可以让 deepresearch 帮忙补齐竞品、技术规范和访谈假设，却不能写“AI 已经替我们理解了用户”。

brainstorm：把“我大概知道”追问成可以交接的决定

如果说 deepresearch 主要回答“还有什么需要看见”，brainstorm 更像是在问“基于这些材料，我们究竟要做什么决定”。

它可以接收一份研究报告，也可以从一个原始想法开始。工作过程中，它先抽取显性要求、隐含假设和 PRD 缺口，再一次只追问一个高杠杆问题；随后比较最小、理想和非显然方案，记录推荐理由以及什么条件会推翻推荐，最后用对抗式审查检查矛盾和遗漏。

这里的“对抗审查”不是让另一个 Agent 泛泛评价“写得好不好”，而是把 PRD 草案交给独立审查角色，专门从五个方面找问题：内部是否自相矛盾、方案是否可行、范围是否清楚、隐含假设是否被冒充成事实，以及后续 plan 是否还需要替产品经理猜决定。审查结果按严重程度和置信度分类；机械性问题可以直接修正，涉及范围或产品判断的问题要回到用户确认。修订后还会再次审查，直到没有关键和高优先级缺口，或把无法解决的问题明确留在文档中。

它的输出不是一段听起来完整的建议，而是一份带稳定需求、角色、流程和验收编号的 PRD。稳定编号看似只是格式，实际解决的是交接问题：后面的计划、实现和审查可以指向同一个决定，不必每次重新解释“我们说的是哪一条”。

这篇文章就是用这四个 skills 产出的，这本身就是一个近场例子。我提供给 AI 的提示词已经很丰富，但仍有几件事没有闭合：读者首先是谁？读者原来的工作方式是什么？读完后希望他们做什么？这是一篇演讲稿还是可独立阅读的长文？通过逐问，AI 没有替我做价值判断，而是迫使我把“可以想清楚但还没想到”的判断说出来。

代价也很直接：用户必须参与回答和选择；逐问、方案比较和审查会增加时间与 token；如果问题本来小、清楚、低风险，完整流程反而可能过度。

brainstorm 负责澄清产品决定，不负责写实现；如果阻塞问题还没解决，把它直接交给下一阶段只会让后面的 Agent 产生更多的幻觉，结果也可能会偏离我们的期望。

plan 与 execute：把决定变成依赖和验证

当产品决定已经闭合，plan 才开始发挥作用。它把 PRD 转成带稳定 U-ID、依赖 DAG、并行 wave、涉及文件、测试场景和验证方式的计划。它回答的是“哪些工作可以同时做，哪些必须等待，怎样证明完成”，而不是替产品负责人补做需求选择。

这里的 wave 可以理解为一批依赖条件已经满足、而且不会同时修改同一文件的任务。同一个 wave 里的任务可以并行进行；下一批 wave 必须等前置任务完成后才能开始。例如 U1 和 U2 互不依赖时可以同时执行，而同时依赖 U1、U2 的 U3 要进入下一批。这样既利用并行能力，也避免看似并行、实际互相覆盖结果。

execute 再按这份计划分 wave 委派任务，收集结构化验证，有限重试，并在失败时跳过依赖它的下游单元；最后保留 DONE、DONE_WITH_CONCERNS、BLOCKED 等状态和执行日志。它也不是质量保证器，高风险或不可逆动作仍需权限和人工门禁。

四者可以串成默认主路径，却不是只能走一次的瀑布。执行中出现新证据，可以回到研究、PRD 或计划修订；小而清楚、低风险且可逆的任务，也完全可以只用其中一两个。

相比不用 skill，真正多出来的是什么

专业人工流程的优势不可替代：真实需求方提供情境，资深同事提供隐性经验，产品负责人承担价值判断和责任。普通 AI 对话也并不弱，熟练使用者通过连续追问、模板和检查表，同样可以得到结构良好的研究或方案。

skill 工作流真正多出来的，是默认存在的流程契约：研究要留下来源和争议，模糊需求要经过逐问，方案要保留取舍，需求能追到计划，计划要写依赖和验证，失败不能被一句“基本完成”抹平。它更容易复查和交接，也更容易让下一位 Agent 知道前面为什么这样决定。

DAG、wave 和文件边界还会把哪些工作可以安全并行、哪些必须串行说得更明确，让多人或多个 Agent 的协作边界更容易检查，但这并不保证并行一定更快。

它同时增加等待时间、token 消耗、人工回答、来源核对和审查负担。多个代理还可能制造噪声或虚假共识，复杂流程也可能带来审批疲劳和分析瘫痪。目前没有统一任务 A/B、盲评或组织级成效数据，可以证明它节省了多少时间、减少了多少返工。

但基于我个人体验：对不确定性高、多人协作、需要留痕的任务，它值得试；对简单任务，不必为了“流程完整”而完整。

从产品工作迁移到现实工作和生活

在现实工作里，我最想先试的不是“所有项目强制走全链路”，而是几个高不确定场景。比如承接业务部门 AI 转型需求时，用 deepresearch 补业务、数据、架构、安全和运营视角，再用 brainstorm 把触发条件、输入输出、失败语义和评价方式问清；设计和测试工作也可以分别用它扩展状态、异常、权限、恢复和验证场景。

做企业 Agent 平台时，四阶段产物还能成为治理接口：研究和脑暴以只读为主，计划形成待审批契约，执行只获得最小权限。

还可以要求 AI 创建知识库或 Wiki，用来保存文档来源、版本、所有者、决定理由和过期状态。

产品之外，供应商选型、培训或工作坊设计、写作汇报和复盘，都可以用前两个 skill 扩大比较维度、澄清目标。生活中的装修或大额购买、旅行或学习规划，也有相似的问题形状：资料很多、约束模糊、风险容易漏。

不过，多 Agent 不是多个真实人的集体智慧；涉及家庭价值判断、专业责任和实时价格时，AI 只能辅助整理，不能替相关的人作决定。

总结：从四个 skill 到一套与 AI 协作的方法论

回看全文，deepresearch、brainstorm、plan 和 execute 分别把证据、决定、依赖和验证放进了一条可以回溯的工作链。它们表面上是四个工作流，背后处理的其实是同一个问题：当信息不完整、判断会变化、工作需要交接时，怎样让人和 AI 都不那么容易丢失上下文。

• deepresearch 管理的是问题和认知上下文
• brainstorm 管理的是方案和评审上下文
• plan 管理的是依赖条件上下文
• excute 管理的是验收和结果上下文

归根结底，设计 AI 产品并不是追求一个永远正确、无所不知的系统，而是设计一套在信息不足时仍能诚实表达边界、在判断出错时能够发现和修正、在人与 Agent 之间交接时不轻易丢失上下文的认知基础设施。日常使用 AI 也是如此：面对关键结论，不妨持续追问三件事——我们现在知道什么？为什么相信它？如果它错了，怎样发现并兜底？

这也是我跳出这四个 skill 想告诉大家的：AI 不替我们承担判断和责任，而是帮助我们扩大看见问题的范围，把模糊变成决定，把决定变成可以验证的行动，并诚实地记录还有什么尚未完成。