原来卡在哪
消费品企业一年要做 100 多个 SKU:产品从需求、口味/配方研发,到包装、合规、中试、渠道上线,链路很长且环环相扣;产品经理的判断、研发的经验存在个人脑子里,数据和信息高度分散——SaaS 系统只记录结果,「为什么这么做」的上下文大量丢失;随着 SKU 增加,待审核包装不断堆积、排队等人工。
具体怎么做的
先观察,再解决:不能带着做好的方案进现场——把一个 Agent 放进客户业务群待了两三周,持续收集业务上下文,最后 Agent 自己从真实业务沟通中定位到「包装审核」这个真问题(Agent 既执行任务也观察业务)。
先定义问题,再定义 AI:借 HRBP 思路给 AI 写一份「岗位说明书」——让真正做审核的业务人员自己拆解:输入是什么、输出是什么、什么情况下需要判断、什么规则可以直接执行。
把业务工作拆成两类:可以自动化的(错别字、法规标准、NRV 能量计算)→ AI 自动检查;需要决策的(产品经理对表达的判断)→ 留给人;历史渠道反馈持续沉淀为标准。
工程化,让 AI 进入整条业务链:包装拆成不同视觉模块分别配 OCR/VLM 方案,热量表与 NRV 计算逻辑固化成确定性代码,审核结果带来源置信度、可追溯;设计稿一提交即自动预审,把合规问题在交给下游之前拦下来。
效果 · Before → After
踩过的坑
- 从承接问题到定义问题——值得做的问题须同时满足:真实存在、有业务价值、有可衡量指标
- 从构建软件系统到定义组织系统——业务方不可能把需求定义完整,FDE 要和老板、中层、业务一起搭建 AI 与人协作的组织系统
- 先解决人的问题再解决技术问题——用「点—线—面」梳理组织:面=战略价值,线=价值链,点=岗位 Know-how
义道点评 · 放到制造企业里怎么做
义道财务 · 2026-09 | 以下是义道的观点,不属于原案例内容;原案例不是义道的项目。
看点
给 AI 写一份「岗位说明书」:输入是什么、输出是什么、什么情况要判断、什么规则能直接执行——这个方法可以直接拿来用。
放到制造企业里
制造企业的研发里也有大量确定性的检查:图纸标注、材料牌号、认证要求、BOM 和图纸是否一致。义道在研发侧的工作会顺带解决一件财税上的事:研发项目从立项到结项的上下文要留存下来,这正是研发费用加计扣除和高新技术企业认定要的备查资料(M07)。研发协同做好了,备查资料就是副产品。
动手前先核对
- 研发项目有没有立项文件和结项报告
- 研发过程的记录放在哪里
- 哪些检查是确定性的,可以交给程序
文中 M01–M16 是义道的成品模块,说明见 义道官网 · 十六个成品模块 ↗;想聊自己工厂的情况,联系义道 ↗。