干了 15 年产品，我把自己“外包”给了 WorkBuddy
黄浩贤约 7 分钟开发者公众号专属群聊
扫码加入获取更多一手教程、科技前沿报告
有一次做产品方案，我没让WorkBuddy帮我写，而是让它来拆我的台。
我给它下了个指令：“你现在是一个特别挑剔的用户，也是一个强势的业务方，我这套方案，你往死里挑毛病。”它还真不客气，几轮下来揪出三四个我自己没想到的漏洞——某个异常流程没考虑、某个权限边界会打架、某类用户根本不会按我设计的路径走。
那天我盯着屏幕愣了一会儿。倒不是因为它挑得多狠，而是我突然意识到一件事：连"挑刺"这种最像人、最需要经验的活，都能外包出去了。
我做了 15 年产品，一直觉得这行有些东西是 AI 碰不到的——定义逻辑、权衡取舍、跟人博弈。但这两三个月用下来，我越来越清楚地感觉到：不是 AI 取代了产品经理，而是我这份工作本身，正在被一块一块地重新定义。
01
我叫黄浩贤，做了 15 年的互联网，现在是 AI 产品架构师，也是腾讯云架构师技术同盟的一员。
我的日常有点分裂：左手输出原型、定义产品逻辑；右手写代码、调 Prompt 和 Agent 工作流。说白了，天天在"模型能到什么程度"和"用户到底要什么"这两条线之间反复横跳，找那个最优解。
正因为我自己就在做 AI 落地，反而对"AI 怎么改造我自己的工作"这件事格外敏感。产品经理的活，粗看像是一堆杂事，细看其实就三块：产出方案、评审方案、拍板决策。 而这三块，我发现每一块都在被 AI 悄悄改写。下面就一块一块说。
02
先说产出方案。产品经理最核心的产出物是 PRD，尤其是那种涉及多端交互、逻辑一环扣一环的 B 端功能文档。
以前我怎么写？对着空白文档发呆，先花一个小时列大纲，再花三个小时填细节，填完还得反复检查逻辑有没有漏。一份文档写下来，人都麻了。
现在我把需求草稿、竞品分析链接、核心流程图一股脑丢给 WorkBuddy，给一句结构化指令：“作为资深 PM，基于这些信息，按标准 PRD 结构输出功能描述、异常流程和数据埋点需求。”五分钟，一份完成度 80% 的初稿就出来了，剩下 20% 我干——审逻辑、补那些只有懂业务的人才知道的细节。这个模式下，效率翻了三倍不止。
但真正让我在意的不只是"快"，是这件事背后的一个变化：我的产出物，正在从"写给人看的文档"，变成"写给 AI 看的规格"。
初稿能用的那80% 不是随便出来的。直接问它要 PRD，出来的一定是通用模板味。
所以我做了两件事：
一是喂了一批过往写得好的产品文档当范例，让它照着我们团队的笔法学；
二是把输出结构写死成硬约束——必须先列背景、再给方案，不许自由发挥。
这一套下来，它就从一个"通用聊天机器人"，被我调成了懂业务语境的"初级产品助理"。
现在圈里有个说法，叫"提示词工程正在让位给上下文工程"——意思就是比起雕琢一句话怎么问，更关键的是你怎么把背景、范例、约束、结构一整套喂进去。我这套写 PRD 的方式，本质上就是在做这件事。过去产品经理的功力体现在"文档写得多周全"，现在体现在"我能不能把一件事，讲成 AI 能精准执行的规格"。 对做产品的人来说，这是个不小的转向。
03
再说评审方案，也就是开头那个"杠精"用法。
做产品设计时，我不光让WorkBuddy 写文档，还会专门让它扮演两种人：一个"特别挑剔的用户"，一个"强势的业务方"，然后把我的方案摆上去，让它从这两个视角轮流攻击、质疑。
为什么这招管用？因为人对自己的方案是有滤镜的。你熬夜想出来的东西，会本能觉得它周全；评审会上同事碍于情面点到为止，你自己更下不去手。而一个没有情绪、被我明确要求"往死里挑"的 AI，反倒成了最称职的反对者——它不累、不给面子、也不怕得罪我，能把那些要等上线才爆的漏洞提前逼出来。
这其实就是 AI 圈里做产品都绕不开的红队测试：与其等真实用户和业务方来打脸，不如先在内部造一个假想敌，把方案往死里锤一遍。大家通常拿它测已经做出来的 AI 产品，而我把这个环节前移到了产品设计阶段，用来测我脑子里那张还没落地的图。
以前一个方案靠不靠谱，得攒一屋子人开评审会，还不一定说得透。现在方案落地之前，我先让 AI 当一轮红队，把明显的坑填掉再拿去过会。评审这件事的第一道关，正在从"人"挪到"AI"。
04
第三块是拍板决策。这块最有意思——它是"变化最小"却"分量最重"的一块。
先讲个反面场景：数据。
我经常收到一份格式乱七八糟、几千行的 Excel，让我快速提炼指标、给结论。以前得手动清洗、写公式或 Python 脚本跑数，一个小时起步；现在直接把文件丢给WorkBuddy，一句"分析某字段分布、找异常值、用 Markdown 表格总结 Top 5 趋势"，几分钟出结果，还附带初步洞察。
但数据是最不能纵容 AI 的地方：别的场景可能编一句还能兜回来，业务数据它要瞎编，我拿去汇报就是事故。作为做 AI 落地的人我很清楚，模型幻觉是概率问题，堵不死，只能拿规则去框。
所以我给它立了三条硬约束，本质是给它围一圈护栏：
涉及具体数据，不知道就说不知道，严禁没有依据就编；
汇报类任务，强制结论先行；做分析总结，
关键结论必须标来源出处，方便我一眼回溯这个数是从哪一行算出来的。
越是放手让 AI 干活，越得把这种护栏立起来——而"该立哪些护栏、哪里必须卡人工"，这本身是判断，是外包不出去的那部分。
这就带出了我这两三个月最深的一个体感：AI 把执行的门槛拉平之后，产品经理真正的价值，正在从"能做多少"沉到"能判断多少"。 文档它可以搭初稿，数据它可以跑结论，方案它可以当假想敌挑刺——这些我都放手了。省下来的脑子，用在只有我能做的那部分：这个逻辑到底成不成立、这个业务值不值得做、最后这一版能不能签字。
当写文档、跑数据、挑漏洞都变成人人可得的能力，能把这些东西拼成正确判断的品味和取舍，反而成了越来越稀缺的东西。
05
顺带回答一个常被问到的问题：WorkBuddy 和那些 IDE 里的编程工具是什么关系？
在我这儿分得很清。IDE 里的编程助手是"代码编辑器"，管的是代码补全、重构、单文件级修改，响应快，适合沉浸式敲代码。WorkBuddy 是"全能项目助理"，跳出了编辑器——跨文件的复杂逻辑梳理、写 PRD、啃 Excel、做长上下文问答，这些归它。一个管"把这段代码写好"，一个管"把这件事想清楚"，专业分工才能把活干得更好。
有个细节让我印象很深。有次我啃一段很偏门的遗留系统逻辑，随手把一段报错代码扔给WorkBuddy 问什么意思，我根本没给背景文档，结果它自己从我之前的对话历史里，翻出了我两周前上传的一份旧版接口文档，联系上下文给我解释了。那一下我有点意外——它记得我在干什么，没有孤立地回答一个问题。这点很重要，这是它能接住我判断的前提。
所以，AI 的下一步可能不是“一个工具包打天下”，而是走向专业分工：编程工具聚焦代码生产，WorkBuddy 承载长程任务、信息整合与项目协作。而人，越来越聚焦于那些不能被轻易外包的判断。
06
说"把自己外包出去"，其实不太准确。
这两三个月我确实把一大堆活交了出去——写初稿、跑数据、挑毛病。但能交出去的那些，恰恰是我这 15 年里最不值钱的部分。
15 年前我入行时，产品经理的看家本领是把一份文档写得又全又漂亮。今天回头看，那套本领正在快速贬值。AI 拿走的，多是那些需要时间、耐心和重复投入的工作；留给产品经理的，反而是更难被替代的部分——问题到底怎么定义，资源应该押在哪里，不同方案怎么取舍，以及什么时候拍板说一句："就这么做。"
如果用一句话总结这两三个月，我会说：它是思维的杠杆，不是答案的自动贩卖机。它让我把力气，从那些开始不值钱的地方，挪到那些越来越值钱的地方去。
作者简介
黄浩贤
腾讯云架构师技术深圳同盟成员，现任中顺洁柔 AI 产品架构相关负责人，拥有 15 年互联网行业经验，长期深耕产品架构领域，近年来重点关注 AI 技术及其在产品与业务中的应用。