东辑事厂两年前，我在一家传统SaaS公司做B端产品经理，每天的生活就是画原型、写PRD、被研发挑战、被销售喷、被客户折磨。那时候AI刚火起来，朋友圈一半人喊着AI要替代产品经理，另一半人转发各种AI生成PRD的截图。我属于比较慌的那一批——因为我发现自己干的事情，好像真的可以被标准化、被自动化、被"蒸馏"掉。
说实话，B端产品经理的工作和C端不太一样，它有大量隐性知识藏在项目里：客户的业务逻辑、行业的潜规则、历史决策的来龙去脉、甚至某些客户负责人的沟通风格。这些内容没法写在简历上，也没法做成标准文档，但它们恰恰是B端PM真正值钱的部分。所以我当时焦虑的核心不是"我会不会被AI替代"，而是"我脑子里这些东西，能不能在AI时代变成一种可调用、可复用、可持续成长的资产"。
后来的两年，我做了一件事：给自己打造了一个"数字分身"。听起来玄乎，但现在回头看，它其实是一套由知识库、决策框架、工作流和AI Agent组合成的系统。这个过程让我从一个对AI半信半疑的传统B端PM，进化成了能同时管三条产品线、还能抽空带团队的人。这篇文章就是完整的复盘，从迷茫到设计方案、从踩坑到跑通，每一步都会拆开讲。适合所有正在焦虑的B端产品经理，也适合那些想要把AI真正用进日常工作的朋友。
1. 先想清楚：AI时代B端产品经理为什么焦虑
不是所有焦虑都是坏事，但如果连焦虑的来源都搞不清，就容易有病乱投医。我先说说自己观察到的三类焦虑来源，你对照看一下，大概率能对上号。
1.1 工作中的可替代部分确实在扩大
B端产品经理的大量日常工作，本质上是在做"信息搬运和格式转换"：把客户的业务诉求转成需求文档，把研发的实现方案转成产品方案，把高层的战略方向转成季度版本计划。这些工作有一个共同特点——有输入、有规则、有输出模板。而只要有模板和规则，AI就比人学得快、做得快、24小时不休息。
我做过一个简单的实验：把自己写过的100份PRD扔给一个大模型做微调提示，让它模仿我的语气写一份新需求的PRD，出来的初稿居然达到了我六七成的水平。这意味着什么？意味着如果一个老板只想要一份"能用的PRD"，那确实不需要我了。但如果老板想要的是"理解客户业务本质、能看到连客户自己都没说出来的真实需求"的人，那这份PRD只是载体，真正的价值在我的脑子里。
所以焦虑的本质是：我们过去赖以生存的交付物，正在从"稀缺技能"变成"通用能力"。就像当年Excel替代了算盘，不是会计消失了，而是只会打算盘的会计消失了，会建模分析的会计反而更值钱。
1.2 三个典型的错误自救反应
知道自己被威胁之后，我见过太多同行做出了错误反应，我自己也踩过其中两个。
第一个是"工具囤积癖"。看到AI工具就收藏，ChatGPT、Claude、各种国产大模型、AI画图、AI表格、AI会议纪要……装了三十多个工具，每个都会一点，每个都用不深。结果是工具不仅没有提升效率，反而增加了切换成本，每天光想着"这个需求该用哪个工具"就能消耗半小时。
第二个是"提示词迷信"。天天研究所谓的万能Prompt模板，收藏了几百条提示词，但真到用的时候发现效果还是不稳定。后来我才明白，Prompt只是AI能力的触发器，如果你自己脑子里没有完整的业务框架，再好的提示词也白搭——AI不是搜索引擎，它是在配合你的思考，而不是替你思考。
第三个是"跟风做AI产品"。看到别人做AI客服、AI写作、AI数据分析就心痒，也想在自己公司推一个AI功能。结果需求没搞清、场景没选对、ROI算不明白，最后做出来一个自嗨型产品，上线没人用，还消耗了团队的信任。
这三个坑的共同问题是：大家都把注意力放在了"AI能做什么"，而没有问"我该让AI做什么"。而恰恰是第二个问题，才是B端产品经理最该发挥专业能力的地方。
1.3 破局点：把AI当成自己能力的放大器，而不是对手
想通了焦虑的来源，我给自己定了一个原则：凡是有明确规则、标准模板、历史案例支撑的工作，全部想办法交给AI；凡是需要理解业务上下文、判断利益关系、进行取舍决策的工作，自己亲自做，同时用AI辅助获取信息。
这个原则听起来简单，但真正执行起来需要一个载体。因为我发现，大多数AI工具是通用型的，它们不懂我的业务、不懂我的行业、不懂我踩过的坑。我把自己的PRD模板丢给它，它只能学个皮毛；我把一份竞品文档丢给它，它给出的分析框架虽然全面但没有重点。
于是，一个念头开始成形：如果我能把自己的经验、决策逻辑、行业认知、文档风格都"打包"成一个可以持续调用的系统，让AI基于这个系统来辅助我工作，那我不就相当于有了一个"AI分身"吗？这个分身不会累、不会忘事、不会情绪化，更重要的是，它可以在我不在的时候帮我做一些基础工作，在我做决策的时候帮我做信息加工。
这就是"数字分身"最初的想法。但真正落地的时候，我发现它远不是搞一个Agent那么简单，它需要一套完整的方法论。下面这部分，就是整个方案的设计思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 把"数字分身"从玄学变成可运行的系统
数字分身这个词这两年被用烂了，什么数字人直播、虚拟形象、AI克隆人，都是拿来做营销的。我做的这个东西很朴素，它不是一个好看的虚拟形象，而是一套以我的工作日志、决策记录、文档沉淀为数据源，以AI大模型为推理引擎，以自动化工作流为骨架的个人AI系统。
2.1 数字分身的本质：把隐性经验显性化
做B端产品最痛苦的事情是，很多经验藏在你脑子里面，无法直接复制给新人。比如"这个客户的IT负责人很强势，他更关心系统能不能帮他向老板邀功，所以方案里要多写汇报素材"——这种判断，查任何文档都找不到，它来自你和客户喝了十次咖啡之后形成的直觉。
数字分身要做的事情，就是把这类直觉转化成可描述的规则，然后把规则喂给AI。AI不产生经验，但它可以成为一个完美的"经验调用器"：当需要做决策时，它能把相关规则和案例在几秒钟内调出来，辅助你判断；当需要做交付时，它能把历史文档风格和结构映射到新任务上，提升产出的一致性。
这一步想清楚之后，数字分身就不再是玄学，而是一个知识工程问题。
2.2 我给数字分身划分的六大功能模块
整体设计上，我把数字分身拆成了六个模块，每个模块对应B端产品经理工作中的一个高频场景。
第一个是知识底座模块。用来沉淀行业知识、客户信息、历史文档、竞品分析，相当于分身的"长期记忆"。第二个是需求洞察模块。用来辅助做用户访谈纪要清洗、需求分类、优先级评估，属于高频使用区。第三个是竞品扫描模块。用来定期跟踪竞品动态、功能对比、差异化分析。第四个是PRD工程模块。基于历史PRD风格生成新文档初稿、验收标准建议、异常流补全。第五个是评审模拟模块。让AI扮演研发、销售、测试等角色来挑战我的产品方案，相当于"评审演习场"。第六个是复盘归档模块。项目结束后自动生成复盘报告，并把经验沉淀回知识底座。
看到这里你可能发现了，这个架构其实和B端产品经理的核心能力模型一一对应：输入（知识）、洞察（需求）、分析（竞品）、输出（PRD）、对抗（评审）、成长（复盘）。数字分身不是要替代我做产品经理，而是要把我这套能力模型变成一个可以并行运转的系统。
2.3 动手之前先确认的三件事
在开始搭建之前，我还做了一次"现状体检"，确认了三件事，这三件事决定了数字分身能不能落地。
一是确认自己的文档积累够不够。如果过去连项目复盘都不写，客户访谈记录也随手丢，那么数字分身的第一阶段就不是搭系统，而是先建立记录习惯。我自己的情况是，过去三年积累了上百份文档，虽然格式混乱，但内容是够的。
二是确认自己的核心决策场景有哪些。我梳理了自己过去一年做的所有产品决策，发现高频场景其实只有三类：需求优先级判断、竞品功能取舍、项目风险预警。这三类就有资格做成标准化的决策规则，而一年只遇到一次的"黑天鹅"事件，不需要也做不进分身里。
三是确认自己可以接受的自动化边界。数字分身毕竟涉及到大量内部敏感信息，哪些内容可以进知识库、哪些绝对不能碰，这个规则必须提前定好。我的原则是：脱敏后的业务知识和决策规则可以进入，但具体客户名单、合同条款、未公开的商业数据绝不进。这条边界，直到今天我也没有放松过。
3. 实操：从零搭建B端产品经理数字分身
下面这部分是全文最硬核的内容，我把每一步怎么做、踩了什么坑、最终的方案是什么都写出来。整个搭建过程大概用了我三周下班后的业余时间，不过如果你手上的素材整理得好，速度可以更快。
3.1 工具选型：不追新，只求稳
我最早尝试的是拿一个现成的AI Agent平台来搭，结果发现太灵活反而不好用——它更像一个给开发者用的积木，我得想着怎么写插件、怎么调API，没工夫去填充业务逻辑。后来我换了个思路，采用"本地知识库 + 通用大模型 + 自动化工作流"的组合方案，三个环节各用各的成熟工具，再把它们串联起来。
知识库我用的是支持本地部署的开源方案，目的是保证敏感数据的可控性。大模型我保留了三个备选，分别应对不同场景：日常需求分析和PRD生成用通用能力强的商用模型，涉及内部数据解析的时候用本地部署的小参数模型，需要做长文档总结的时候再用长上下文模型。自动化工作流则是用来把"知识检索—模型推理—文档生成"串成流水线，让分身能在无人干预的情况下定时跑任务。
这个方案的核心思想是：不追求一个AI做所有事，而是让最合适的AI做最擅长的事。对B端产品经理来说，稳定性和可控性远超先进性。
3.2 第一步：把历史PRD和案例复盘清洗成知识库
这一步是整个工程的基石。我把自己过去三年写的PRD、竞品分析、项目复盘、客户访谈纪要全部翻出来，先做了一次大清洗。
清洗分三层。第一层是去敏感信息，把所有客户名字替换成代号，涉及具体报价、合同条款的数据全部删除。第二层是分类打标签，比如一份PRD会被标记为"财务管理行业""续费场景""移动端""高复杂度""涉及三方对接"这样一组结构化的标签。有了标签，后面在检索的时候才能精准命中。第三层是提取"决策点"，这部分是最关键的——我去翻每一份历史文档，找到那些关键的决策记录，比如"为什么这个需求放在V2不做V1""为什么选A方案不选B方案"，把这些内容单独抽取出来，附上当时的背景和考虑因素。
为什么要把"决策点"单独拎出来？因为知识库如果只有文档，那它只是一个搜索引擎，AI只能回答"文档里写的是什么"，回答不了"这种情况下应该怎么判断"。而有了决策点，AI就可以做类比推理：新的需求和历史某个案例相似，当时的决策逻辑可以复用。
做完这三步，我得到了一个将近3000条知识条目的个人知识库。这个规模已经足够支撑后续的检索和推理了。顺便说一句，清洗这件事非常耗时，但绝对不能跳过，因为知识库的质量直接决定数字分身的能力上限。垃圾进，垃圾出，这是所有AI应用的铁律。
3.3 第二步：设计"需求判断决策链"的提示词框架
知识库只是材料，要让AI真正像个产品经理一样思考，还需要一套结构化的决策链提示词。我查阅了大量关于CoT（思维链）和结构化Prompt的资料，最后总结出一套适合B端产品的七步判断法，每次向分身提问时，它都会自动走这条链路。
七步分别是：第一步，复述问题，用一句话确认自己理解的需求背景；第二步，定位用户，明确这个需求的受益者是一线操作员、管理层还是外部客户；第三步，回溯目标，把需求和产品本季度的核心目标挂钩；第四步，对标案例，在知识库中检索最相似的历史需求和当时的决策；第五步，评估成本，结合研发资源给出粗略的性价比判断；第六步，识别风险，把可能涉及的异常流程和数据安全问题列出来；第七步，给出结论，按"做、不做、缓做、换一种方式做"输出建议。
这套提示词框架的价值在于，它把B端产品经理的隐性决策路径变成了显性的、可强制执行的流程。刚开始用的时候会觉得有点死板，但用熟了以后，我发现它其实是在帮我建立一种肌肉记忆——就算没有AI，我自己做需求判断的时候，也会下意识地走这套流程。这才是数字分身对我最大的改变：它不是替代我思考，而是在倒逼我把思考过程规范化。
我特意强调，这套提示词不是让你直接从网上下载的通用模板，而是必须根据自己的业务领域调整。比如你做的是电商后台，决策链里就该有"是否影响订单履约时效"这一项；你做的是医疗系统，就该有"是否符合数据合规要求"这一项。通用的七步法只是一个壳，里面的血肉必须来自你自己的业务积累。
3.4 第三步：搭建"评审对抗"和"竞品扫描"两个自动化工作流
知识库和提示词框架都具备之后，我开始搭建真正的自动化工作流。这其中最有价值的两个，一个是"评审对抗"，另一个是"竞品扫描"。
先说评审对抗。在B端公司，产品经理最头疼的环节就是需求评审，研发会问技术可行性，测试会问异常场景覆盖，销售会问这个功能凭什么让客户买单，老板会问这个功能对营收的拉动是什么。四个人各有各的立场，一个人往往很难同时照顾好所有角色。我的做法是，在知识库里创建五个"角色档案"，分别是研发总监、测试负责人、销售总监、客户成功经理和我自己。每个角色档案里不仅有背景设定，还放了这个角色过去在真实评审中提出过的经典问题。然后我设定了一个工作流，每周五下午定时运行，输入本周的产品方案草稿，让AI分别以这五个角色对方案提问和挑刺。
最初几次运行的效果让我挺惊讶的，AI提问的很多角度确实是我自己没考虑到的。比如研发角色会问"这个字段的历史存量数据怎么迁移"，测试角色会问"如果第三方接口返回超时，页面上的状态怎么回退"，这些问题虽然不是每个都准确，但至少提供了一个"检查清单"，让我在评审会之前先自查一遍。实际上线以后，评审会的通过率明显提升了。
再说竞品扫描。我列了一个竞品清单，包括直接竞品、间接竞品和学习对象，然后在自动化工作流里设定任务：每周日晚上八点，自动去抓取这些产品的官方更新日志、帮助文档更新、社区讨论和招聘信息，然后按时生成一份竞品动态简报，发到我的工作邮箱。简报的格式包括：本周产品更新、功能变化解读、招聘方向分析（招聘技术岗多说明在加大投入，招聘销售岗多说明在发力商业化）、对自身产品的启发。
这个工作流跑起来以后，我基本告别了手动逛竞品官网的习惯，每周一早上花十五分钟读简报，就能把竞品动向掌握个大概。这里有个小技巧，简报不是越长越好，我限制AI只输出最关键的三个变化和一条启发，避免信息过载。
3.5 第四步：让分身"替我说话"的实际落地场景
最后一步是让数字分身从"内部工具"变成"对外输出接口"。具体来说，我训练分身学会了我的写作风格，让它能替我生成周报、月报、项目同步邮件甚至部分客户沟通文档。
这个训练过程和搭知识库类似：我把自己过去一年写的所有周报、邮件、项目汇报PPT拿给它看，总结出我的风格特征——喜欢用数据说话、结构一定是"结论—背景—行动—风险"、语言偏保守不会把话说满。然后把总结好的风格描述以系统提示词的形式固化下来，告诉分身"以后生成任何对外文档，必须符合这个风格"。
效果最明显的是周报。以前我写周报要磨叽半小时，现在分身在周五下午自动收集我这周的产品文档更新、需求评审记录、项目进度变化，生成周报初稿，我再花十分钟修改润色就能发出。周报质量不仅没有下降，甚至比我以前手写的更完整，因为分身不会漏掉某个项目线的更新。
不过我在这里也要强调一点：分身替我说话的前提是，最终负责的人还是我。所有对外的文档，我发出之前一定会逐字读过，确认每一个判断都是我想表达的。AI可以帮你节省90%的起草时间，但如果那10%的确认时间你不花，迟早要吃大亏。
4. 实战验证：数字分身介入后的工作流变化
系统搭好之后，我做的第一件事就是把它投入到真实的项目里去检验。这里我挑几个典型场景，说说数字分身介入前后的差别。
4.1 需求分析阶段：从"见人说人话"到"分身先帮我过滤一遍"
B端的需求分析，通常伴随大量的客户访谈和内部沟通。以前我每次访谈完，要花一两个小时整理录音、划重点、提炼需求，然后还要对照自己记的笔记，防止漏掉细节。这个过程非常耗精力，但又不能省略。
现在我的流程是：访谈结束以后，把录音转写文字丢给分身，让它按照我预设的模板做结构化整理。模板包括：客户基本信息、核心诉求、使用的业务场景、现有解决方案、痛点强烈程度、决策链角色意见、潜在线索等。分身整理完之后，还会和知识库里同行业、同类型的历史需求做对比，标注出"这个诉求和XX客户三月份提的相似，当时我们判断是伪需求"之类的提示。
当然，分身做的分析结果我只会把它当作"第一轮过滤"，最终的判断依据还是我自己在访谈现场的感觉。不过有了一次过滤，我可以把节省下来的时间用在更有价值的深挖上——比如再约一次访谈，或者去看看客户后台的真实使用数据。B端需求分析的本质不是"听到需求"，而是"判断需求背后的动机和场景"，分身负责把听到的内容结构化，人力负责判断动机和场景。
4.2 PRD写作阶段：从"一张白纸"到"七成成品"
以前写一份复杂PRD，我大概需要花一整天，因为要从零开始组织背景、推演流程、设计异常流。现在我的习惯是：把需求背景、访谈要点、决策结论一起丢给分身，让它先按照我历史PRD的风格生成第一版初稿。这个过程通常只要十分钟。
初稿拿回来以后，我不会直接在原文上改，而是先通读一遍，把"它写错的地方"和"它没写到的地方"分别标出来。写错的地方，往往就是需求关键逻辑的转折点，需要我重点检查；没写到的地方，往往是我以为自己说清楚了、但实际上没有传达到位的部分。所以分身生成的初稿，本质上是一个**"需求表达压力测试"**——它暴露出的是我自身思考的盲区和表达的不精确。
经过这样的流程，我最终交付的PRD质量反而提升了，因为我的注意力从"码字"转移到"审视逻辑"上。一个具体的改变是：以前我的PRD里异常流程经常写得不够细，现在分身会自动补上"接口超时、数据为空、并发冲突"等常见异常场景，我再根据自己的经验判断哪些需要保留、哪些可以忽略，效率高了不少。
4.3 项目推进阶段：从"追着问"到"分身帮我盯进度"
B端产品经理的另一大痛点是项目推进过程中的信息同步。项目群里有业务、研发、测试、设计、运维，每个人只关注自己那一块，产品经理得像个信息中枢，不断把各方的进度和问题对齐。这会消耗大量的精力，而且很容易遗漏。
我的解决方式是在项目群里接入了一个基于数字分身能力搭建的定时任务：每天早上九点，自动在项目文档中汇总各成员的更新内容，生成一份"项目健康日报"，包括：昨日完成事项、今日计划、延期风险、待产品决策的问题、成员活跃度变化。这份日报看起来简单，但它让所有人共享同一个信息源，减少了大量重复询问。
日报的生成逻辑也不复杂，就是定时触发工作流，读取项目文档的修改记录、任务管理工具的状态变更，让大模型做摘要汇总。这里面比较难的是如何判定"延期风险"，我的做法是把知识库里的历史项目延期原因做了一个标签体系，比如"频繁变更需求""依赖外部团队""关键人员请假"，让分身根据当前项目的状态匹配这些标签，一旦命中就发出预警。这个功能上线以后，至少帮我提前发现过三次潜在延期风险。
5. 踩坑实录：做数字分身时容易翻车的几个地方
两年的实践过程不可能一帆风顺，我踩过的坑不少。挑几个有代表性的分享出来，希望你能绕开。
5.1 坑一：知识库"贪多嚼不烂"，塞了一堆没用的进去
刚开始搭知识库的时候，我什么文档都想往里塞：行业报告、技术资料、管理书籍摘抄、别人写的优秀PRD……结果知识库变得非常臃肿，检索的时候经常出现"答非所问"——AI给出的答案总是来自那些泛泛的行业报告，而不是我自己的实践经验。
后来我才想明白：数字分身的价值在于"私有知识"，而不在于"公有知识"。通用行业报告、技术资料这些东西，大模型自己本来就懂，你把它放进去反而会干扰分身的判断。真正应该进知识库的，只有你在实际项目中积累的、网络上查不到的、带有你个人或者团队独特视角的内容。
调整策略之后，我把知识库从6000多条压缩到3000多条，砍掉的全是网上能查到的东西，只保留自己的项目复盘、客户访谈、决策记录和内部经验。效果立竿见影，分身回答的准确性和针对性明显上升。
5.2 坑二：分身输出"伪造记忆"，把不存在的案例说得头头是道
这是所有AI应用都会遇到的问题——幻觉。但在我这个场景里，幻觉更危险，因为知识库里的内容都是真实的业务案例，分身如果混淆了不同案例的细节，把A客户的场景安到B客户头上，那我基于这个分析做决策，就会出大问题。
我遇到过最离谱的一次，是分身在做竞品分析时，凭空编造了一个"某竞品最近上线了某项功能"，还分析得有模有样。我差点把这个信息写进了自己产品的竞争策略里，最后去查证才发现根本不存在。
从那以后，我定了一条规矩：分身给出的任何涉及事实的信息，必须附上来源出处。我调整了提示词，要求它在回答问题时先列出参考的知识库条目ID，如果完全没有参考来源，必须明确回答"知识库中没有相关信息"。同时我在工作流里加了自动验证环节，对分身生成的关键事实做一轮交叉检查。这套机制虽然增加了一点延迟，但极大降低了幻觉带来的风险。
5.3 坑三：轻视维护成本，系统半年就变成了"僵尸"
数字分身不是"搭好就不用管"的一次性工程，它需要持续维护。半年后你会发现，知识库里很多条目已经过时了——客户换了负责人、产品的功能结构大改过、行业政策出现了新动态。如果这些不过时，分身给出的建议就会越来越远离现实。
我的维护方案是"每月一次小维护，每季度一次大清理"。小维护是每周在日常使用中随时补充和纠正知识库内容，比如做完一次客户访谈，立刻把新的认知更新进去；每季度做一次整体审查，删除不再适用的条目，更新行业动态。这个维护工作看起来琐碎，但它是保证数字分身长期有效的关键。
另外还要注意，大模型的版本升级也会影响分身的输出风格和行为。每当我更换底层模型，或者模型厂商发布了重要的版本更新，我都会用一套"回归测试用例"来检验分身的输出是否还符合预期。这套用例大概有二十个固定问题，覆盖需求判断、竞品分析、PRD生成三个核心场景。
6. 两年后的认知升级：B端PM真正该练的四种能力
数字分身只是一个工具，真正让我在AI时代站稳脚跟的，是打造分身过程中被迫练出来的几种能力。这些能力，我认为才是未来三到五年B端产品经理的核心竞争力。
6.1 节奏感：判断哪些环节该用AI、哪些环节必须用人
这两年的实践经验让我悟出一个判断标准：如果一个环节的价值在于"理解"，就不要交给AI；如果一个环节的价值在于"输出"，就可以交给AI。理解客户没明说的痛点、理解研发方案背后的权衡、理解老板战略背后的动机——这些"理解"类的工作，AI目前只能做个不错的辅助，真正拍板还得靠人；而把理解到的内容转化成PRD、周报、竞品报告，这些"输出"类工作，AI已经非常拿手。
把这条标准想清楚之后，我再也不纠结"什么该自动化"了。每个工作环节放到这个框架里过一遍，答案自然浮现。
6.2 提问能力：Prompt的本质是需求澄清
以前做C端产品，我觉得"用户访谈"是一门需要练习的技能；现在面对AI，我发现"Prompt设计"本质上也是一门需求澄清技能，甚至可以说它们底层是相通的。
同一个需求，给AI的信息越模糊，它给出的答案就越泛；信息越具体，答案就越精准。比如我问"分析一下我们客户流失的原因"，得到的往往是正确的废话；但如果我问"分析我们在华东区制造业中小客户中，近三个月流失率上升的原因，重点对比续费前30天的使用行为变化"，得到的答案就有价值得多。这跟访谈客户是一个道理——你问"你觉得这个产品怎么样"和问"你上次在什么场景下觉得这个功能不好用"，得到的有效信息天差地别。
所以我现在带新人，会专门花时间教他们怎么写Prompt。我不教什么高级技巧，就强调三要素：给背景、给约束、给输出格式。这三要素想清楚，Prompt基本就合格了。
6.3 数据颗粒度：用数据喂养数字分身，也喂养自己
数字分身在一次次的迭代中逐渐变强，关键在于我开始有意识地用更细颗粒度的数据喂养它。以前我记录一个需求，只记录结论，不管过程；现在我要求自己记录过程中的所有关键变量：客户当时的业务阶段、预算范围、决策链角色、竞品参与情况、客户对价格的态度变化。这些变量单独看不重要，但当它们沉淀到知识库里，就能帮助分身做更精准的匹配和预测。
同时，这种数据颗粒度的训练也在反哺我自己。因为要记录，我变得更加关注访谈中的细节、数据背后的异常、市场变化的早期信号。以前觉得自己"有行业敏感度"是一种玄学，现在我发现敏感度就是数据颗粒度的结果——你积累的数据越细，你看到趋势的时间就越早。
6.4 跨角色翻译力：让业务、研发、AI三方对齐
数字分身进入工作流之后，我的日常工作中多了一个新角色——AI。以前我只需要在业务和研发之间做翻译，现在还要处理AI的输出、判断AI的建议、向团队解释AI方案的合理性。这表面上是多了一项工作，实际上是在逼我变成一个更好的沟通者。
有一次，分身建议我们修改某个功能的交互逻辑，理由是"根据知识库中多个同类客户的行为数据，当前设计会导致30%的用户在首次使用时产生困惑"。我把这个分析发给研发，研发的第一反应是"这是AI说的，靠不靠谱"。我没有直接说"这是AI分析的"，而是把知识库里的客户反馈案例和数据分析过程整理成一份可追溯的文档，让研发看到结论的来源，最后这个建议被采纳了。
这件事给我一个启发：AI进入团队协作，最大的阻力往往不是技术，而是信任。产品经理作为整个流程的连接器，有责任把AI的输出"翻译"成团队可以理解和信任的语言。这一能力，在未来的价值会越来越高。
两年走下来，我对数字分身有了新的理解。它不是一个替你工作的机器人，而是一面镜子——你脑子里有什么样的知识、经验、判断力，它就会用AI的方式把它放大。你思维清晰，它让你更高效；你思维混乱，它只会更快地产生一堆令人头大的垃圾。
所以这趟旅程真正教会我的事情，不是怎么用AI，而是怎么做一个更清醒的B端产品经理。数字分身最大的贡献，是在这个充满噪音的AI时代，给了我一个稳定、可靠、可信赖的思维训练场。如果你也想试试，先别急着去注册一堆AI工具，打开你的历史文档，开始整理你自己的知识库吧。那是所有奇迹发生的地方。