从行业简报到绩效核算：一家动物营养公司的三条工作流改造

本文是一家动物营养公司的匿名实践记录。记录的是工作流本身的变化，不把这些变化外推为营收、品牌表现或组织整体效率的结果。

三条工作流分属传播、研发管理与销售运营，改造时间不同，参与团队也不同。放在一起记录，是因为它们暴露出同一类问题：人工承担了大量本不该由人承担的重复环节，而真正需要人判断的地方，反而没有被保护出来。

一、行业简报：从人工采编到定时工作流

这家公司长期用一份行业简报与目标受众和客户保持交互。原来的做法是传统自媒体采编方式——人工检索信息、编辑、发布。

暴露出来的三个问题

版权风险。 检索范围主要是线上网络与微信公众号，使用的文字和图片存在抄袭、无授权转载的问题，过去也确实收到过维权函。

人工负荷与差错。 高度依赖人工，重复度很高，人容易疲劳，也就容易出纰漏。

覆盖面受限。 受限于个人的视野和能力边界，能关注到的行业信息与检索范围有限，这一点直接决定了简报的信息覆盖面和质量上限。

改造后的工作流

用 Agent 创建并调试了一个定时运行的 workflow：

1. 检索范围拓展到全球多语种信源，覆盖动物营养技术发展前沿、不同国际区域市场的政策变化，以及上下游产业链动态；
2. 根据检索到的信息形成摘要与行业简报；
3. 自动生成封面图和内配图，并通过 API 直接推送到自媒体账号。

人工环节被削减到只剩一步：审阅 Ready to Publish 的草稿。

稳定版本是第七版

这一点值得单独记下来。工作流不是接上模型就能跑，调试过程解决的都是具体的边界问题：

• 避免信息重复；
• 平衡不同板块之间的内容；
• 对来源不明的信源做交叉验证；
• 满足生成图片的质量要求。

七版迭代的成本，几乎全部花在这些地方。如果只看第一版能不能跑通，会严重低估把一条工作流做到可以每天运行所需要的投入。

二、产品研发项目管理：先让数据进系统

原来的做法是人员用 Office 套件制定项目计划表，再人工跟踪并统计各个项目负责人的进度。

一个决定了改造顺序的前置背景

这家公司近年上线了 OA，但普及度很低：内部员工使用意愿不强，负责推动的信息部门力度也有限。产品研发的项目管理因此一直游离在 OA 系统之外，属于人工账统计。

这个背景决定了第一步不是自动化，而是让数据先进系统。在数据还散落在个人文件里的时候谈自动统计，没有落点。

改造过程

1. 把项目统计搬进 OA，开始做信息沉淀与数据结构化，并为其重构数据库；
2. 接入 API，使项目能够自动统计、自动预警；
3. 负责人通过移动端回复项目进度后，自动汇总到项目统计表；
4. 原先依靠人工汇总统计的方式转为自动化，并可实时生成 Dashboard。

下一阶段

把预算费用的使用进度与研发项目进度关联起来，财务中心的研发管理人员也接入该项目参与协同管理。这一步的目标是降低协同沟通成本，目前仍在推进中。

三、销售绩效核算：把协同搬到同一个操作台

原来高度依赖人工，主要靠 Office 套件完成，以 Excel 的数据库函数为主。

暴露出来的两类问题

数据孤岛。 需要先从 ERP 系统导出数据，做检查和清洗，引入绩效考核规则，再对实际订单、销售合同执行、退款等做二次校对后才能计算。

协同与效率。 HRBP 算完之后，还要与财务部门和 HR 进行多轮协同。过程中暴露出效率低、容易出错，以及数据孤岛难以打通的问题。

改造后的工作流

1. 把 ERP 中的销售管理数据（包括发货、收款）汇集到销售管理操作台，并写入销售绩效考核规则；
2. 设置定期任务，在服务器闲时自动完成数据汇集、数据清理与计算；
3. 在 workflow 中引入自动检查与回归测试，避免出现错误；
4. 绩效管理以及需要协同的财务、人力团队，统一通过销售绩效管理操作台协同。

第 3 点是这条工作流里最容易被跳过、也最不该跳过的一步。绩效核算的错误不是效率问题，是信任问题——一旦算错，后面所有的自动化都会被要求退回人工复核。

三条工作流的共同点

先解决数据在哪，再谈自动化。 三条里有两条的第一步都不是接 AI，而是把散落在个人文件和个人经验里的数据，先归拢到一个系统里。

人的位置被重新安排，而不是被取消。 简报保留了发布前的人工审阅，绩效保留了自动检查与回归测试作为兜底，研发管理保留了负责人对进度的确认。被削减的是检索、汇总、转录这些重复动作。

稳定性来自迭代，不是来自选型。 简报工作流迭代到第七版才稳定，解决的都是重复、平衡、验证、质量这类具体问题。这部分工作无法通过换一个更强的模型跳过。

边界说明

本文记录的是工作流本身的变化，这些改造发生在不同团队、不同时间，不构成对营收、品牌表现或组织整体效率的归因。第二条和第三条工作流的部分环节仍在推进中，本文不把阶段性进展写成已完成的结果。