企业官网建设流程全解析

出书这件事，我本来是当成个人阶段性总结来做的，没想到正式上市之后，身边问得最多的反而变成了一个问题：你写了B端产品，那AI的ToB市场你怎么看？

这本书叫《B端产品经理修炼手册》，聊的是B端产品经理从需求分析到产品落地、从项目交付到商业闭环的完整方法论。但写书这一年，我最大的感受其实是：B端产品经理这个岗位，正在被AI重构。企业服务市场不再只是买一套软件、装一套系统的问题，而是进入了一个“数据和模型驱动流程再造”的深水区。这本书刚好卡在这个时间点上市，也算是一种巧合。

这篇文章不聊书里的目录结构，我想借这个机会，把B端产品经理、AI的ToB市场、以及我写书过程中反复思考的一些东西，揉在一起聊透。适合刚入行的B端产品新人、正在往AI方向转的产品经理，以及所有在ToB赛道里做售前、实施、客户成功的同学参考。

1. AI正在重写ToB市场：三个看得见的变化

很多做ToB的老兵这两年都有一个共同感受：客户聊的方案变了。前几年见CIO，大家聊的是“上ERP还是不上ERP”“私有化部署还是SaaS”，PPT里画的是功能清单和模块架构图。现在是聊“哪些环节可以用大模型提效”“知识库怎么跟业务系统打通”“智能体怎么跟工单流程对接”。不是软件不重要了，而是软件的交付逻辑变了。

第一个变化是交付物从“系统”变成了“结果”。传统ToB卖的是功能，客户买了财务模块就要做账，买了CRM就要管客户。AI时代的ToB方案，客户要的是效果，是响应速度、是转化率、是成本下降。比如同样是一家客服系统厂商，以前卖的是工单流转、IVR导航，现在卖的是“大模型自动回答80%的常见问题”。系统变成了载体，模型的推理能力才是真正值钱的部分。

第二个变化是决策链路变短了。以前一套企业软件卖进去，要过IT部门、业务部门、采购部门，流程走半年很正常。AI应用不一样，很多是从一个具体的痛点切入，比如某部门想把历史合同做个智能问答，或者想让人工客服每天少回两百条重复消息。这种项目预算小、周期短、见效快，业务部门自己就能拍板。决策链路一短，对产品经理的要求反而高了，因为你没有大项目那么长的缓冲期去慢慢试错。

第三个变化是数据变成了核心竞争力。工业软件时代的壁垒是流程know-how，信息化时代的壁垒是模块覆盖度，AI时代的壁垒体现在数据质量和反馈闭环上。谁手里有干净、结构化、持续更新的业务数据，谁就能训练出更贴合场景的模型。这也是为什么很多做AI中台的公司，最后都变成了数据治理公司。

提示：理解这三个变化，是理解后面所有内容的前提。书里虽然写了很多传统的B端方法论，但底层逻辑是一样的，只不过技术工具从代码换成了模型。

2. AI时代，B端产品经理凭什么值钱

传统B端产品经理的日常工作，拆开看就三件事：画原型、写PRD、跟研发对需求。再往深一点，做做竞品分析、画业务流程图、梳理角色权限。这些工作AI都能帮你干，甚至干得比人快。但有一件事AI替代不了：判断力。放在哪个环节用AI，怎么定义AI的边界，效果不好是调模型还是换流程，这些判断需要人对业务有深度理解。

我觉得AI时代的B端产品经理，核心竞争力可以概括成三个。

第一是意图拆解能力。以前用户需求是“我要一个报表”，你设计一个筛选条件、图表类型就完事了。现在用户需求是“我要知道为什么这个月的退货率变高了”。这背后可能涉及数据口径、异常检测、因果分析、归因报告，整个链条要拆成多个子任务。大模型可以帮你生成报告，但它不知道怎么拆，拆错了生成的东西就没法用。这个拆解的能力，本质上是把模糊问题变成结构化任务的能力。

第二是评估体系设计能力。C端产品看DAU、留存、转化率，B端AI产品看的指标要复杂得多。比如一个智能文档解析工具，准确率怎么算，是看字段抽取的完整度还是关键信息的正确率；一个客服大模型，回答得好不好，是人工抽检还是客户满意度打分。这些评估体系和标注标准，都是产品经理要定义出来的，定义得好，后面优化才有方向。

第三是落地陪跑能力。AI不是装上就能用，要投入运营。模型会退化，数据会漂移，业务流程会调整。好的B端产品经理，交付完项目只是开始，后面要持续跟客户一起看数据、调参数、优化提示词、改进训练集。这个“陪跑”的过程，才是客户真正愿意续费的原因。

说实话，这三个能力不是看书就能会的，得在真实项目里磨。但看书的好处是可以帮你建立框架，知道往哪个方向磨。我的书里有一章专门讲B端产品的需求分析，用的就是“业务目标-用户任务-功能拆解-数据反馈”四层法，这个框架在AI项目里同样适用。

2.1 传统B端PM最需要补的三门课

如果已经在B端做了两三年，想往AI方向转，我觉得优先补这三样。

第一是补技术视野。不需要会训练模型，但要看得懂API文档，知道Token成本怎么算，了解RAG（检索增强生成）的基本流程，清楚向量数据库和关系型数据库各自解决什么问题。我把这些看作B端PM的“新八股”，不懂就聊不到一块去。

第二是补数据思维。很多传统B端项目，数据都是客户提供，格式乱、质量差、口径不统一。AI项目里，数据就是产品的一部分。要开始学着用SQL捞数据、会看数据分布、能设计简单的标注规范。

第三是补价值度量。传统ToB卖功能，功能上线就是价值。AI项目里功能上线只是开始，价值的度量变成了上线前后对比、投入产出比计算、长期效果追踪。这一课对售前和交付团队同样重要，否则方案写得很热闹，验收的时候拿不出数据。

3. 《B端产品经理修炼手册》写了什么：从框架到落地

这本书的起点，是我刚做B端产品那几年的迷茫。市面上讲C端产品的书很多，讲增长、讲体验、讲策略，一套一套的。轮到B端，要么是讲大而全的信息化理论，要么是零散的项目复盘，很少有一本能从“产品经理如何思考”这个角度，把B端这一套讲完整的。所以这本书首先解决的是“没有地图”的问题。

全书的结构分成五大部分。第一部分是B端产品经理的角色认知，回答“这个岗位到底在解决什么问题”；第二部分是需求分析，讲怎么从客户的抱怨中抽取出真实需求；第三部分是产品设计，讲信息架构、权限模型、业务流与状态机；第四部分是项目管理与交付，讲怎么跟客户、售前、研发、测试打交道；第五部分是商业化与增长，讲定价、包装、续费与扩展。

每一章都会给你一套可以复用的模板或清单，比如需求访谈的问题清单、竞品分析的拆解框架、系统崩溃后的复盘模板。

3.1 这本书的核心观点：B端产品经理的能力地图

如果只记一个核心观点，我希望你记住这句话：B端产品经理的核心工作，是把组织里的复杂业务，翻译成系统里可运行的逻辑。

这句翻译工作包含三层意思。第一层是理解组织，知道一个公司是怎么通过“部门+流程+角色+规则”运转起来的；第二层是抽象建模，把这些运转逻辑变成数据对象、状态流转和权限边界；第三层是持续演进，业务变了系统要跟着变，而这需要产品经理始终站在业务和技术的交汇点上。

这套能力地图，在书里用了一张大图来展示，包含六个维度：业务理解、用户共情、抽象建模、技术素养、项目管理、商业思维。AI时代的到来并没有改变这张地图，只是某些维度变重了。比如技术素养的要求变高了，商业思维的权重也变大了。但底层逻辑没变，依然是理解和翻译。

3.2 写书和出版这件事，本身就是一次ToB交付

聊点书之外的事。写书这一年，我的感受是：写书和做ToB项目，本质上是一回事。你要面对一个模糊的需求（编辑说“写一本B端产品经理的书”），你要做用户调研（看看这个市场缺什么），你要设计结构（目录改了十几版），你要交付（按时交稿）再做售后（读者反馈、加印修订、线上线下分享）。

最耗时间的不是写作，而是改稿。初稿写完之后，编辑从读者视角提了一批意见，比如 chapter 8 的案例分析太简单、chapter 3 的权限模型讲得太抽象。这个过程很像B端项目里的测试阶段，你自己写得嗨没用，要把报告交给读者看，读者看不看得懂、用不用得上，才是真验收标准。

给想出书的朋友一句实在话：不要等完全准备好了再动笔，先写一个粗糙的初稿，再慢慢打磨。这跟做产品如出一辙，先做出一个可用的最小版本，再持续迭代。

4. B端产品经理的核心动作拆解：需求、竞争、架构、交付

书里有两章是我觉得含金量比较高的，一个是需求分析，一个是项目交付。这两块刚好也是AI项目里最容易出问题的环节，我展开讲讲。

4.1 需求访谈：别被客户的解决方案带偏

B端最典型的坑是：客户提的需求永远是“解决方案”，他自己想好了一个功能，让你照做。比如客户说“我要一个自动生成周报的功能”，如果直接做，你就成了外包。正确做法是往下问一层：为什么要自动生成周报？省下的时间拿去看什么？周报的受众是谁？现有的周报是给管理层看还是给客户看？

我习惯用“五个为什么”的方式往深挖，至少要挖到业务目标这一层。在上面的例子里，问到底会发现真正的问题是“项目信息散落在各个系统，管理者缺乏统一视图”。那解决方案就不只是自动生成周报，而是一个项目数据聚合面板。这就是从功能思维升级到目标思维，AI产品尤其需要这种思维，因为大模型什么都能生成，但你得知道真正该生成什么。

访谈的时候还有一个技巧：不要只听一个人讲。同一个流程，一线操作的人、中层管理者、高层决策者，三方的理解往往完全不同。操作的人告诉你现状是“Excel表格里记录”，管理者告诉你“我们已经有了一套OA审批”，决策者告诉你“我们想实现流程数字化”。三份信息拼起来，才是真正的业务全貌。

4.2 竞品分析：从功能列表到商业逻辑

很多新人做竞品分析就是拉一个功能对比表，看看对方有没有这个按钮、有没有那个模块。这个维度在B端远远不够，因为B端的竞品分析本质上是商业分析。

我做竞品分析一般看四个层面。第一是定位，这家厂商是做大客户还是中小企业，是卖标准品还是做定制，这决定了它的产品形态。第二是定价，它按人头收费还是按调用量收费，这个收费模式暗示了它对客户价值的判断。第三是交付方式，是SaaS还是私有化，是项目制还是产品制，这决定了它的毛利和规模天花板。第四是生态，它有没有合作伙伴，有没有开放接口，有没有应用市场。

把这四个层面搞清楚，你就能预判对手下一步会干什么。比如一家厂商开始推出面向中小客户的轻量版，往往意味着它的增长主力从大客户转向了中腰部市场。这时候如果你还只做大客户，就要提前想好护城河。

4.3 产品架构：模块化、可配置化、数据闭环

B端的产品架构设计，我个人最看重三个原则。

第一个是模块化。按业务域拆分成多个模块，每个模块高内聚、低耦合，让不同客户可以用不同模块组合。AI项目里的模块化还要再往前走一步，把模型服务也当成模块，比如有一个通用的文档解析服务、一个智能检索服务，任何一个业务模块都可以调用。

第二个是可配置化。B端客户最大的特点是需求各不相同，如果每个需求都改代码，研发团队会累死，你也会被版本管理搞疯。可配置化就是让业务人员在不改代码的情况下调整流程、字段、权限。做AI产品的时候，这个原则体现为提示词可配置、知识库来源可切换、阈值参数可调整。

第三个是数据闭环。每个功能在跑的时候都要想清楚：数据从哪来、存到哪、怎么用、怎么回流到模型训练。没有数据闭环，AI产品永远只能停留在Demo阶段。

4.4 项目交付：售前、实施、回款的配合

书里有一章专门讲B端项目的交付流程，因为B端产品的价值最终要通过交付实现。这里我分享一个踩过的坑：售前过度承诺。

有一年做一个数据可视化项目，售前在投标时答应客户“所有报表都可以自定义拖拽生成”。客户签完合同，实施团队进场后发现，所谓自定义拖拽在数据粒度很粗的情况下根本实现不了，因为底层数据模型压根不支持任意维度组合。最后项目延期三个月，双方都很难看。从此以后，我每次参与售前方案评审，都会认真核对承诺的功能是不是当前产品真正具备的，如果是需要定制的，一定要标注出来并给出工作量评估。

交付阶段的另一个关键点，是让客户的关键用户尽早参与测试。很多项目做完了才拉客户验收，结果发现一堆操作习惯、权限关系跟想的不一样，改动成本巨大。正确做法是在开发中期就找关键用户试用，随时收集反馈，把验收风险前置到开发过程里。

5. B端产品经理怎么成长：复盘方法、学习路径与底线能力

很多同学问过我，非计算机背景能不能做B端产品经理。我的答案很明确：能，而且做得好的人往往不是计算机背景，而是经济、管理、外语这类专业的。B端产品最核心的是理解业务，计算机只是工具。我见过最厉害的项目经理是学法律出身，他跟客户聊合同流程、聊合规风控的时候，客户以为他是老法务。

5.1 案例复盘：怎么拆一个复杂项目

成长最快的方式是做复盘。每次项目结束，我都会做一次结构化复盘，大概分四步。

第一步是回顾目标，当初这个项目要解决什么问题，验收标准是什么。第二步是重演过程，把从调研到上线的关键节点列出来，标注每个节点做出的决策。第三步是对比结果，哪些决策是对的，哪些是错的，错的地方是信息不足还是模型错误。第四步是沉淀规则，把这次的经验抽象成可复用的清单或模板。

复盘不一定写在文档里，有时候跟同事吃顿饭聊一遍效果更好。关键是聊完要有产出，哪怕是三条笔记，也比不聊强。

5.2 学习路径：什么值得反复看

B端产品经理的学习资料，我觉得主要有三类最值得反复看。

第一类是优秀产品的帮助文档和白皮书。很多人做竞品只看官网介绍，其实产品文档里的信息密度高得多。你看一家客服系统的文档，能看出它的角色权限怎么设计、工单状态怎么流转、SLA规则怎么配置，这些才是真正的产品功力。第二类是行业报告和标杆案例里的业务数据，比如制造业的交付周期、医疗行业的合规要求，这些数据能帮你在没有行业经验的时候快速建立业务感。第三类是跟自己项目相关的复盘文章，特别是那些写了“失败的教训”的，那种文章含金量最高。

5.3 AI时代，B端产品经理的底线能力

不管AI怎么发展，有三项能力我认为是底线。

第一项是结构化表达。能不能把一个复杂的业务场景用一张流程图、一页PPT讲清楚，这决定了别人愿不愿意跟你合作。第二项是优先级判断。需求永远是做不完的，能在资源有限的情况下保护核心逻辑不被稀释，是产品经理最值钱的能力。第三项是跟人打交道的能力。B端是强人的生意，客户、销售、研发、老板，每一方诉求都不一样，能把他们拉到一个方向上，是一种稀缺能力。

注意：模型能力会越来越强，但判断一个需求值不值得做、怎么做、做到什么程度，这种“取舍”能力短期内看不到被替代的可能性。

6. 写这本书的几件小事：反思、习惯与下一步

最后说点写书过程中真实感受到的东西。

第一个感受是透明化写作的压力。写博客的时候，写错了可以悄悄改。写书不行，白纸黑字印出来，错了就是错了。所以我写每个章节都会刻意多问一句“这是我在实际项目中验证过的方法，还是我听别人说过的方法”，后者宁可删掉也不写进书里。这种压力反过来让我的复盘习惯变好了，以前做完项目懒得总结，现在会逼着自己写下来。

第二个感受是写书是一种高杠杆的成长方式。写一本书的过程，相当于把你的知识体系从头到尾体检了一遍。你会发现很多你以为自己懂的东西，落到笔头上就写不清楚。写不清楚的本质是想得不透。所以哪怕不是为了出版，我也建议每个工作五年以上的B端产品经理，认真写一份自己的方法论沉淀，哪怕只有两万字，也会很有收获。

第三个感受是关于AI的确定性。AI的ToB市场现在看起来很热闹，但真正跑通商业化闭环的领域还很有限。我自己判断未来两三年会有几个方向稳定放量：一是企业内部知识管理，二是垂直行业的辅助决策，三是客户服务和营销自动化。如果你正处在职业选择的路口，可以往这些方向多看两眼。

这本书的后续，我打算围绕几个重点章节做配套的案例拆解和模板下载，也会邀请几位做AI落地项目的朋友一起写实战案例。毕竟书的局限是更新慢，但案例库可以一直迭代。最后再分享一个小技巧：写书也好、做B端产品也好，养成自己的工作台历习惯，每天固定一个时间写两段话，不一定要长，但要坚持，很多灵感都是在这样写的过程里冒出来的。