夜雨聆风01
从个人AI到企业AI，中间差了什么
我从去年下半年开始用AI搭建自己的数字分身。从最开始用它帮我做日常工作的规划、文档整理、知识产出（产品方案），到现在聚焦我的成长闭环——一方面时时刻刻关注我的输入，总结我的习惯、提炼我的亮点观点，给出合理建议；另一方面降低我的学习门槛，就像我的专用教练一样，知道我要如何提升，并给出不同视角。到现在快一年了，已经形成了一套比较完整的个人AI工作流。
顺着这套个人闭环的玩法，也指引了我在工作中、真实业务场景中、和工程师们一起做AI产品的协作和流程优化。从个人到组织层面的AI协作框架，产品经理可以怎么更好地做，便是这篇文章要写的内容。
到目前为止，我观察到企业里的人对AI的认知还会存在在两类极端思路：
第一种：AI无所不能。 把需求直接丢给大模型，静等结果。最后自然是发现结果不稳定、幻觉严重；换个描述，依然效果不明显，又怀疑AI到底行不行。
第二种：AI不太行，再看看。 试了几次效果不好就下结论——"大模型不靠谱"、"现阶段还用不了"。然后又退回到纯代码方案。
其实，问题不在AI行不行，而在你让它做了什么。
企业用AI，核心问题是"AI做哪部分、代码做哪部分、人做哪部分"。
这三者的边界画不清楚，系统就算跑起来，结果是很难拿到的——要么AI做了不该做的事（比如让大模型算数），要么代码做了不该做的事（比如用规则引擎理解自然语言），要么人做了本可以自动化的事。
最近看到一些技术侧的实践分享，有人在推动一件事：用AI从存量代码中还原系统的Spec——数据结构、状态机、API。简单说，Spec就是把"这个系统到底干了什么"用结构化的方式写清楚。一个产品的内核就是这三样东西，它们加上业务价值判断，占到一个软件长期价值的绝大部分。
技术侧还原Spec，解决的是代码和代码之间的分工问题——前端该调哪个接口，后端该实现什么能力，数据该怎么流转。这是技术侧的答案，而且已经有团队在规模化落地了。
那对于AI时代的产品经理来说，能做的事情在哪里呢？
其实在AI产品里，还有一层Spec需要被定义——AI和代码之间的能力边界。这个环节该调大模型还是该写代码？置信度阈值设多少？低于阈值走人工还是走规则？prompt/skill里该嵌入什么领域知识作为护栏？
这些问题，技术侧的Spec不一定能还原——因为答案不在代码里，在产品经理的业务判断里。技术侧知道AI"能不能做"，但产品侧知道AI"该不该做"。
技术侧有Spec还原，产品侧对应的，应该是画一张AI能力边界图。
拿自己做过的一个B端AI项目实践一遍。
02
根据业务场景进行拆解
我做的是一个数据比对场景的AI系统——用户上传一份Excel，系统自动识别结构、比对差异、分析原因、生成摘要。
我设计了4个功能模块：数据解析、差异检测、差异归因、记忆学习。
第一，差异检测从AI改成了代码。
落地的时候，这个环节完全交给了工程侧。原因很简单：逐行对比两列数字、算差异件数、统计SKU数——这些是确定性计算，代码做又快又准，大模型做既慢又容易出错。
第二，归因模块从"让模型自由总结"变成了"给框架做归类"。
最开始我的做法很直接：把差异数据丢给模型，让它自己分析总结原因。结果出来之后，并不契合真实业务方场景——模型给的原因要么太泛、要么不在业务认知框架里，或者就是那种每个字都认识，合在一起不知道讲的是什么意思的表达。
我选择自己深入学了一轮业务知识，在业务专家的指导下，把常见的差异原因归纳成了标准分类。AI需要做的不再是"猜原因"，而是理解用户备注里的自然语言文本，归到我预定义的分类里。同时我还预留了一个"其他"分类——归不进去的，先收集起来，后续用来迭代分类体系。
从"让AI做侦探"变成了"让AI做翻译"。
第三，从4个功能模块变成了4个Agent + N个代码服务。
PRD里的4个功能模块，落地时演化成了4个独立的Agent：表头识别、原因归类、报告生成、刷新重写。不只是换了个名字——每个Agent是一个完整的处理单元，有自己的输入校验、提示词逻辑、输出解析和异常兜底。Agent之间也不是简单的顺序执行，每个Agent的输出需要经过代码校验、数据清洗、格式转换，才能作为下一个Agent的输入。最终形成了4个Agent串联、中间穿插N个代码服务的架构。
这个结果一方面是基于稳定性保障，同时也是为了节省token，但更重要的是做好能力边界取舍的最终结果——让AI只做它擅长的语义理解和文本生成，让代码去做它擅长的数字计算和格式校验。
这三个变化，都是我自己在和模型的反复沟通中想清楚的，然后在和工程师的协作中，把每个Agent的输入输出接口定义固化下来、跑通的。
03
对比市面上的AI产品，发现几个模式是一致的
这套系统就是我和工程师搞出来的。
当我把最终架构和市面上成熟的AI产品做对比的时候，发现几个模式高度一致：
AI-代码-AI的三明治架构。 成熟的AI产品很少让大模型从头做到尾。Notion AI、代码助手、智能客服，底层逻辑都一样：AI理解语义→代码做确定性计算→AI再生成输出。我的系统里也是这样——AI识别完表头之后，中间插了一层代码做差异计算和统计聚合，然后再交给AI生成文案。
置信度驱动的人机协作。 模型输出不是全信或全不信，而是设一个阈值。我的设计是60%——高于60%系统自动完成，低于60%交给用户选。这个模式在医疗AI、金融风控里到处都是。价值不在技术实现，在于产品经理能不能找到那个平衡点。
领域知识作为护栏。 我在其中一个Agent里嵌入了十几类标准原因库和一套优先级决策树。本质是对AI的约束——不让它自由发挥，在预定义的框架里做选择。先用业务规则画好边界，再让大模型在边界内做语义理解。
04
技术侧做了骨架，产品侧做了什么
回头看，这套系统用的是通用大模型，没有微调，没有训练数据集。但它确实在生产环境跑了起来，服务了真实客户。
工程师做了什么？做了系统的骨架——数据结构设计、接口实现、差异计算、统计聚合、稳定性保障。
我做了什么？定义了每一次AI和代码之间的分工边界。
有一个说法我觉得很准确：在AI时代，技能会越来越容易被替代，但对业务价值的判断力会越来越稀缺。
放到AI产品的语境里：写Prompt是技能，门槛在快速下降。但判断AI该做什么、不该做什么——这是判断力，很难被替代。
差异检测为什么从AI改成代码？归因为什么不能让模型自由发挥？为什么拆4个Agent而不是1个？为什么置信度阈值设在60%？
每一个决策都不复杂，但做对需要真正理解：AI擅长什么，代码擅长什么。
能力边界图画出来之后，你会发现：这张图本身，就是产品经理在AI项目里的"作品"。
05
如果你也想试试
把你做过的AI项目拿出来，找到实际跑通的prompt（不是PRD里的理想版本），然后画一张能力边界图。三步就够：
第一步，画数据流：从用户输入到最终输出，中间经过了几个AI调用、几段代码处理？
第二步，标边界：每个节点到底是AI在做语义理解，还是代码在做确定性计算？有没有该交给代码的事让AI在干？
第三步，和PRD对比：哪些设计被保留了，哪些被推翻了？每一个被推翻的设计，就是你做出的一次能力边界判断。
技术侧有他们的系统知识还原工具。产品侧有能力边界图。两者对在一起，才是一个AI系统完整的骨架。
技能会通胀，但边界判断不会。
END
我是老贺，医疗+供应链双行业产品人。
正在用AI搭建数字分身，把干过的活沉淀成方法论。
