最近我在一家传统纺织企业推动数字化改造也在思考怎样让AI真正进入企业的日常工作。越往业务里走我越关注一个问题什么样的产品经理才能把AI做成企业真正需要的产品这家企业有研发、生产和销售有自有工厂也有委外工厂既做标准品也做定制。业务并不简单。企业内部还有一套持续演进多年的自研ERP承载着大量日常工作。原本我带着AI落地的任务进入企业。但诊断下来发现产品规划、数据和流程本身都有需要补齐的基础。于是问题也变得更具体怎样借着AI落地的机会把业务产品和工作方式一起优化在我看来真正的AI产品经理要理解业务也要理解AI能够分清人、AI和业务系统各自承担什么再把这种分工设计成实际可用的产品。先把业务工作看清楚这套ERP过去主要按照业务人员的需要不断追加功能。需求来了就做一个功能新的情况出现了再加一些规则。长时间积累下来功能很多产品也越来越臃肿大家仍然觉得用得不够顺。从订单到收款的大流程看整体链路能够走通。但走进每一个环节就会发现职能部门内部的工作还比较凌乱。流程图上的一个节点落到实际岗位往往是一组信息收集、判断、沟通和跟进工作。所以我考虑从产品管理、销售、生产、采购、仓储、品质等业务领域重新梳理产品。先看每个领域要完成什么业务目标再看岗位如何协作、信息如何流动最后考虑AI应该参与哪里。以产品管理为例需要考虑研发过程、产品运营策略和产品全生命周期。如果只重新做一遍流程管理和规则配置最后可能只是换了一张皮。我们还要继续追问哪些工作可以减少哪些判断可以得到更好的支持哪些事情可以更早被发现和跟进**AI产品设计的起点应该是一项具体工作及其结果。**数据、规则或责任存在问题时也要区分哪些需要业务先澄清哪些需要系统优化哪些适合让AI参与。重复工作值得优化但具体采用什么方式还要看问题本身。我最关注的三个价值场景在这次实践中我首先关注三类工作。它们距离业务人员很近也容易把产品价值说清楚。第一减少反复录入和校正同一个信息为什么要在不同环节反复填写已经有人整理过的内容为什么下一个人还要重新录入、重新核对这些事情会消耗大量时间却未必增加业务价值。这里需要先找原因。如果已有结构化数据可以通过接口传递就应该优先复用数据如果信息散落在文档、消息或会议记录里再考虑让AI帮助提取和整理。需要人工确认的内容就把确认环节设计清楚。我要改善的是信息进入业务的过程尽量一次采集、持续复用并让需要校正的地方清楚可见。第二让过程跟进更主动一款产品从研发到上市周期可能很长。项目经理需要持续问进度、收集信息、核对计划、发现问题再推动各方协调。我的设想是让AI参与这些日常跟进把进度整理成可处理的事项。比如收集到的反馈出现延期或依赖问题时AI可以整理异常和建议交给负责人处理。需要开会就协助发起安排会议结束再接收结论、重整任务、继续跟进。**主动管理的价值体现在问题能否进入处理过程并有人持续负责。**如果只是多发几条提醒大家还是要自己重新整理信息、判断优先级产品的帮助就很有限。第三给专业岗位提供更全面的辅助以新面料选型为例研发人员可以与AI讨论材料、技术方案和需要进一步核实的问题再让承担审校角色的AI帮助检查方案、补充市场相关考虑。我希望得到的效果是专业人员能考虑更多信息、减少遗漏让讨论和审校更充分。但“给每个人配一个专家”是我对使用体验的设想。**专业方案仍需要有依据需要结合实际条件确认。**再增加一个AI审校角色也不应该被当作方案已经正确的证明。把人、AI和业务系统的职责分清楚这三类场景往下展开都会遇到同一个问题一项工作由谁来完成我认为AI产品经理需要把这个问题拆成三个部分。人做判断担责任处理现实协作面对面协调、供应商谈价、现场质量检验以及需要授权的决策和承诺。AI理解信息辅助判断推动跟进提取与整理信息、识别任务、汇总进展、提示异常、讨论方案和提供处理建议。业务系统记录事实执行规则承载任务保存业务数据登记责任与状态校验权限流转待办执行确定的业务操作。比如AI从会议记录里识别出一项任务产品设计不能到“任务已提取”就结束。它还要进入业务系统登记负责人、要求和状态再出现在执行人员的工作台。执行人员完成工作后反馈也要回到对应事项。同样AI提出了处理建议还要说明谁有权确认、确认后由谁执行、哪些操作由系统完成。供应商谈价、现场检验和面对面协调在我当前考虑的场景里仍然需要人来承接。哪些由人做哪些由AI做哪些由业务系统做这应当在定义产品和讨论方案时就成为一把标尺。把这三类职责分清楚才能继续讨论产品结构、技术实现和用户体验。否则很容易出现AI能说很多话但一件事情仍然没有进入业务执行的情况。设计AI员工要把一段工作定义完整我想在产品研发管理里引入一个AI员工参与项目的日常跟进。这里的“员工”是帮助我思考产品职责的一种说法不代表把项目经理的全部工作都交给AI。如果沿着这个思路继续设计我会先把一段工作的入口、任务和结束条件写清楚。例如接收计划与任务明确跟进哪款产品、哪些阶段和哪些人员以哪份计划为依据。收集与整理进展按照约定收集反馈对照任务整理进度把缺失或有疑问的信息列出来。识别问题并交给负责人整理延期、依赖和需要协调的事项形成待办与处理建议。接收新的决议由负责人组织必要的沟通将确认后的会议结论交回系统调整任务和后续安排。持续跟进完成情况根据执行反馈更新状态直到事项满足约定的完成条件。沿着这条工作链就能继续问AI可以向谁收集信息什么情况需要提醒什么情况需要请负责人介入计划调整由谁确认任务结束要看什么依据这些问题会直接决定产品是否可用。AI要有明确的职责和考核要求也要知道哪些事情需要交给人处理。项目经理仍然负责现实中的协调、取舍和推动。AI如果能把日常过程跟进做好项目经理就有机会把更多精力放在真正需要自己处理的事情上。这是我希望验证的价值具体效果还需要在实际使用中检验。理解AI能力要能回答产品问题我说AI产品经理需要理解运行原理和能力边界并不是要求每个人都去训练模型。但这种理解至少要能够支撑产品取舍。设计一项AI工作时产品经理应该能够说清楚它能获得哪些信息判断依据在哪里输出要交给谁使用哪些结果必须经过核实它可以调用哪些系统能力出现信息缺失或判断不确定时工作怎样继续拿面料方案讨论来说只知道AI“能够分析”还不够。产品经理需要继续明确它参考什么产品资料、技术规范和业务要求输出哪些建议哪些问题留给研发人员确认哪些结论还需要实验或市场信息支持。拿重复录入来说也不能看到重复劳动就直接放一个AI进去。已有数据传递、字段校验和固定规则能解决的部分应当先把系统能力用好。AI更适合参与哪段工作要结合信息形式和判断要求继续评估。**对AI能力的理解最终应该体现为具体的产品选择**用在哪里给什么信息允许做什么结果怎样核实以及什么时候交给人。产品价值要落到可以检验的结果职责清楚之后还需要回答这个AI产品做得好不好如果考核只看问答次数、消息数量或生成了多少内容我很难判断它对业务究竟有什么帮助。沿着前面的三个场景我会把验收问题继续细化。下面是我基于这些场景的评价思路并不是已经测得的项目效果。重复录入有没有真正减少比较同类工作需要录入几次、花多少时间以及后续核对和返工有没有增加。过程跟进有没有更及时检查信息是否完整、异常是否及时进入待办以及负责人是否能跟进处理结果。专业辅助有没有改善方案检查建议是否有依据、是否帮助发现遗漏、是否减少返工以及人工核实需要投入多少精力。这里还要把AI运行、人工确认和后续纠错的投入一起考虑。如果前面省了一些操作后面却多了大量校正实际价值就需要重新判断。我的推进思路是先选一段职责和结果都能说清楚的工作形成可以体验的产品再通过使用反馈调整。能验证价值的部分继续扩展还不稳定的部分就收窄范围或增加人工确认。**产品是否专业要看它能不能把业务变化和评价依据一起设计出来。**没有实际测量之前我不会用一个提升比例替代验证。未来的工作台会更接近人的任务沿着这样的分工继续推演我对未来企业软件的一个判断是用户会减少在多个界面之间的反复操作更多地围绕自己要处理的事情工作。他进入工作台后应该能看到自己负责什么、哪些待办最紧急、哪些事项出现异常以及有哪些处理建议。需要审核就确认需要协调就去沟通完成线下工作再把反馈交回系统。尤其是线下反馈。如果供应商沟通、现场检验或会议里的重要结论没有回来AI掌握的信息就不完整。产品必须让这些反馈有地方进入并与相应任务联系起来。我并不认为所有界面都会消失。专业操作、复杂资料查阅和管理配置仍然需要合适的界面。但在日常使用中产品可以让人少做信息搬运把注意力放到确认、判断、异常处理和现实协作上。我眼中的真正AI产品经理能够把具体业务工作拆清楚把人、AI和系统的职责安排清楚并让这种协作产生可以检验的改善。这也是我在企业数字化实践中越来越明确的方向。先走进业务理解人每天在做什么再把AI能力放到合适的位置。从一段真实工作开始把信息、任务、执行和反馈连起来产品才有机会持续产生价值。文 / 零一架构师记录架构、产品与企业AI落地中的实践和思考。