本文目录
上世纪 80 年代，福特汽车曾经面对一个看起来很典型的“效率问题”。
当时，福特北美的应付账款部门有超过 500 名员工。一笔采购完成后，财务人员需要核对三份信息：采购部门发出的采购订单、仓库收到货物后的收货记录，以及供应商寄来的发票。三份信息一致，才能付款；任何一个数字对不上，就需要人工调查。按照传统思路，解决方案很自然：上一套更好的计算机系统，把核对工作做得更快，然后争取减少一部分人力。
真正让福特改变思路的，是它发现持股的马自达做类似工作只需要很少的人。于是福特重新审视的已经不只是“财务人员怎样核对得更快”，而是整条采购到付款的流程为什么需要这样设计。
新的流程里，采购订单直接进入数据库。货物到达以后，仓库人员在系统里确认收货，系统直接将收货信息与采购订单进行匹配，符合条件就进入付款流程。原来大量围绕“采购订单、收货记录、供应商发票三方核对”产生的工作被压缩掉了。这个后来成为业务流程再造领域经典案例的项目，让福特应付账款部门的人力规模大幅下降，相关研究通常将降幅总结为约 75%。
这个发生在四十多年前的故事，放到今天的 AI 浪潮里看，依然很有意思。
因为今天很多企业引入 AI 时，又站在了非常相似的位置上。
产品经理以前需要一天写完一份 PRD，现在用 AI 两个小时就可以生成；编辑以前花半天整理资料和写稿，现在 AI 十几分钟就能给出初稿；程序员原来一天完成的代码，现在借助 AI Coding 可能几个小时就能完成。每一个岗位看起来都提高了效率，但真正运行一段时间之后，企业很容易发现：单个任务变快了，整个业务流程并没有按照同样的比例变快。
原因很简单。企业里的大量时间，本来就没有消耗在“写一份文档”“写一段代码”“生成一张图片”这些具体动作上。更多时间消耗在等待、交接、确认、反复沟通和返工里。
所以，企业 AI 落地如果只停留在“给每个岗位配一个 AI 工具”，最终得到的往往只是局部提效。真正值得重新思考的问题是：当 AI 已经改变了很多工作的成本和能力边界以后，我们今天还需要沿用过去那套流程吗？
从“AI 帮产品经理写 PRD”，到重新设计整个研发流程
我之前做产品负责人的时候，对这个问题有很深的体感。
特别是复杂的 B 端产品，一条需求从提出到上线，通常会经过一条很长的链路。业务先找到产品经理提出需求，产品经理经过几轮沟通以后输出 PRD；UI/UX 根据 PRD 做设计，再进行设计评审；之后组织需求评审，前端、后端、测试等角色一起确认实现方案；QA 再输出测试用例，研发开始开发，最后进入联调和验收。
把这套流程画在流程图上，看起来非常标准。但真实的项目很少能够这样顺利地从左向右走完。
产品经理写 PRD 的时候，可能没有想到某个边界场景；到了 UI/UX 出设计稿时，才发现某个业务逻辑不成立，于是回去调整需求。等到需求评审，研发又发现数据结构或者系统能力无法支持原来的设计，再调整一次。真正进入开发以后，某些异常流程、权限问题、批量操作问题又逐渐暴露，需求继续修改。到了验收阶段，还可能出现业务、产品、研发对于同一句需求的理解并不一致。
在我过去做复杂 B 端产品时，一个很强烈的体感是，相当大一部分项目周期都耗在这种需求澄清和反复调整上。某些复杂项目里，这部分时间甚至可能接近整个项目周期的三成。
AI 出现以后，一个很值得重新设计的节点，是把 Demo 提前到需求定义阶段。
现在业务提出需求以后，产品经理可以先和业务把核心目标、用户角色和基本逻辑梳理清楚，然后直接借助 AI Coding 和原型生成能力，在非常短的时间里做出一个可以操作的 Demo。
下一次需求评审的时候，不再需要大家对着几十页 PRD 想象产品最终长什么样。业务、产品、UI/UX、前端、后端、QA 可以全部坐在一起，直接从头到尾走一遍真实的用户路径。
用户从哪里进入？第一步做什么？如果没有数据怎么办？一次操作十个对象和一次操作一千个对象是否一样？失败以后怎么提示？不同权限的人看到什么？用户完成操作以后到哪里看结果？后续的数据有没有反馈回来？
很多在文字里讨论半小时仍然模糊的问题，一旦真正点一遍产品，很快就会暴露出来。
这时候，AI 带来的价值已经远远超过了“帮产品经理更快地写一份 PRD”。它让整个需求确认的时间点发生了变化。大量过去需要等到设计、研发甚至验收阶段才能发现的问题，被提前到了正式开发之前。
以前的研发流程，很大程度上建立在一个客观约束上：做一个真正能操作的产品成本很高，所以我们必须先用文档和设计稿把事情尽可能描述清楚，然后才能开始开发。当 AI 把生成 Demo 的成本大幅降低以后，这个约束正在消失。
于是流程完全可以换一种设计方式：先快速形成可交互的 Demo，通过真实用户路径把需求收敛，再更新正式 PRD；QA 基于已经收敛的需求、Demo 和边界条件提前生成验收场景和测试用例；这些测试用例同时提供给产品和研发，成为开发阶段非常明确的输入。研发再结合 PRD、测试用例以及已有项目的代码和上下文，借助 AI 完成开发。
从软件工程方法来看，这种方式和 ATDD，也就是验收测试驱动开发，有很多相似之处：在正式实现之前，先把验收条件定义清楚，再围绕这些条件进行开发。
这样重新设计以后，AI 提效的单位已经从“一个岗位”变成了“一整条研发链路”。
内容生产也是一样：真正要改变的是编辑工作的方式
类似的事情也发生在内容行业。
我们之前在做一个汽车资讯相关的项目时，也遇到过类似的问题。传统资讯生产非常依赖编辑个人能力：编辑每天浏览大量媒体、网站和信息源，从海量信息里寻找可能有价值的事件，再凭自己的经验判断哪些事情值得写、应该从什么角度切入。确定选题以后，再去寻找资料、组织文章、写稿、审核、发布，最后通过阅读量等数据判断效果。
在这条链路里，写文章当然是一项成本，但真正昂贵的地方还包括更上游的环节：每天看什么信息、哪些事件值得关注、什么内容可能有流量、什么角度值得跟进。
这些判断过去大量沉淀在编辑个人脑子里。
如果 AI 的使用方式只是编辑找到选题以后，打开一个大模型说“帮我写一篇文章”，那么它解决的主要还是写作这个局部环节。
但如果重新设计整个流程，情况就完全不同。
我们可以持续采集行业内不同的信息源，把每天新增的大量内容放到一个统一的数据层里，再通过 AI 做事件识别、聚类和去重。一个热点事件可能被几十家媒体反复报道，系统首先可以识别它们属于同一件事情；随后再结合历史内容数据、用户行为、搜索趋势、站内点击等信息，对候选事件进行评分，AI 基于这些信息生成可能的选题和报道角度。
编辑面对的就不再是每天需要人工浏览的几百条甚至几千条信息，而是一组已经经过整理和排序的候选选题。
确定选题之后，AI 可以继续整理事件背景、企业信息、历史资料和数据，并形成初稿。人的工作更多集中在事实核验、重要性判断、观点把控以及少数复杂内容的深度加工上。文章发布以后，真实的点击、阅读、搜索、转化等数据再回流，继续影响下一轮的选题判断。
这样一来，改变的已经是整套内容生产机制。
过去编辑每天首先做的是“找信息”；新的流程里，信息可以主动进入系统。过去选题大量依赖个人经验；新的流程开始把经验拆解为数据指标、规则和模型。过去内容效果分析停留在文章发布以后；新的流程则可以让结果不断反馈到下一轮生产。
人的价值也随之发生变化：从大量的信息搬运、资料整理和重复写作，逐渐转向规则设计、价值判断、事实核验和异常处理。
这可能才是 AI 真正进入一个业务流程之后应该产生的变化。
从 ERP 到 AI，企业已经经历过类似的问题
回头看企业数字化的发展历史，会发现今天的情况其实并不陌生。
1990 年，Michael Hammer 在《哈佛商业评论》发表了后来非常著名的文章《Reengineering Work: Don't Automate, Obliterate》。他提出的一个核心问题，就是企业面对信息技术时，很容易直接把原有流程自动化，却忽略了重新设计流程本身的可能性。福特的应付账款案例，也正是在这套业务流程再造思想中被广泛讨论。
后来进入 ERP 时代，同样的问题继续出现。
企业购买 ERP，真正产生的变化远远超过“把 Excel 和纸质单据搬进系统”。财务、采购、库存、销售、供应链的数据需要统一，不同部门之间的流程需要衔接，主数据需要按照统一规则维护，很多过去依赖线下沟通和个人习惯的工作方式也需要调整。ERP 的核心能力之一，本身就是把多个业务模块连接在统一的数据和流程体系里。SAP 对 ERP 的定义同样强调，对财务、供应链、采购、销售等核心业务流程进行整合，并形成统一的数据来源。
今天 SAP 推进云 ERP 实施时，仍然强调 Fit-to-Standard：先让企业理解标准业务流程，再识别真正必要的差异和调整，而不是无限按照原有工作方式定制系统。SAP 也明确提醒，偏离标准流程会带来后续维护成本。
这背后其实是一条非常稳定的规律：每当企业获得一种新的技术能力，最初往往用它优化已有动作；当技术真正深入业务以后，最终一定会开始改变动作之间的关系。
ERP 很大程度上改变了结构化数据如何在企业内部流动。AI 的影响可能会更进一步，因为它开始进入过去高度依赖人的知识工作。
阅读、理解、总结、分类、写作、设计、编程、判断、检查，这些过去很难交给传统软件处理的工作，现在越来越多可以由 AI 参与完成。
而很多我们今天习以为常的企业流程，本来就是围绕“这些事情必须由人完成”这个前提设计出来的。
当这个前提发生变化，流程自然值得重新设计。
企业真正应该问的，是“如果今天从零开始，我们还会这样工作吗？”
所以，我们在给企业做 AI 落地时，会越来越关注一个问题：企业究竟希望优化一个任务，还是希望改善整个业务结果？
如果只是问“产品经理怎么用 AI”“销售怎么用 AI”“编辑怎么用 AI”，很容易得到一堆工具：产品经理用 AI 写 PRD，销售用 AI 写邮件，编辑用 AI 写文章，研发用 AI Coding。每个人可能都节省了一些时间，但原来的组织关系、审批节点和交接方式几乎没有变化。
换一种方式，把一条业务流程完整画出来，问题会清晰很多。
我们通常会重点寻找几类节点：等待、交接、重复劳动、人工判断和返工。
然后再逐个看，AI 今天已经让哪些能力的成本发生了巨大变化。以前做一个高保真 Demo 需要设计和研发投入几天甚至几周，现在产品经理自己可能几个小时就能完成；以前阅读上万篇资料需要大量人工，现在模型可以批量处理；以前生成几百套测试场景成本很高，现在可以自动生成；以前大量个性化内容无法规模生产，现在边际成本正在快速下降。
接下来再重新设计目标流程：哪些环节可以合并，哪些判断可以提前，哪些工作可以并行，哪些步骤可以自动完成，哪些过去存在的审批和交接已经失去了原来的意义。
到了这一步，再决定需要用大模型、Agent、Workflow、RPA、企业知识库、数据平台还是自研系统，技术选型会变得简单很多。因为工具开始服务于一条已经重新设计过的业务流程。
几十年前，福特重新设计应付账款流程时，最有价值的问题其实非常简单：既然系统已经能够连接采购订单和收货信息，为什么还要让几百个人不断核对三份单据？
今天面对 AI，企业同样可以重新问一遍自己的业务。
为什么产品需求一定要在几个部门之间串行传递很多轮？为什么编辑一定要每天人工浏览数百条新闻才能找到一个选题？为什么某个业务判断只能存在一个资深员工的脑子里？为什么已经重复发生了几千次的工作，每一次还需要从头处理？
AI 让过去设计业务流程时的一部分基础约束开始消失。
所以，对于今天真正希望把 AI 落到业务里的企业，我认为有一个问题值得反复问：
如果今天重新成立这家公司，并且从第一天开始就拥有现在的 AI 能力，我们还会把这条业务流程设计成现在这样吗？
很多企业下一阶段真正的 AI 红利，可能就藏在这个问题的答案里。