飞书 AI 运营与管理自动化

周报写了，进展为什么还要挨个问

消息发了，周报写了，会议也开了，想知道项目到了哪一步，却还得挨个问。信息一直在增加，接下来由谁做什么，反而没那么清楚。

飞书 AI 运营与管理自动化项目处理的就是这类问题。我们是一个两人团队，2026 年 6—8 月为某企业实施，8 月交付。我负责客户需求沟通、产品设计，以及部分周报与运营 Agent 的搭建。这里不披露客户身份和内部材料。

我想让会议、周报和项目进展连起来，留下能追踪的记录。接手的人看完，应该知道现在是什么情况、自己还要做什么。只把表格填满，后面仍可能需要再问一轮。

要把“汇报更方便”做成一个功能，还得问得具体一点：谁需要知道什么，什么时候要，材料从哪里来，发现异常以后找谁？这些没定下来，系统即便搬运得再快，也不知道该把信息交到谁手里。

我把会议整理、每周汇报、周期性的项目进展收集与核验拆成任务，再逐一安排输入、输出和写回。在需求与产品设计中，也统筹了 OA 流程、Agent 权限，以及合同、资信投标材料的编写与检查。每个场景都要说清信息放在哪里，谁来确认，后面怎样追踪。

其中一部分 Agent 由我搭建，其余实现和交付与另一位团队成员协作完成。下面主要记录我负责的产品判断。

一个项目状态变了，谁有权把它写进正式记录？这个问题决定了 Agent 哪些时候能直接写回，哪些时候需要停下来等人。

同样是修改一个字段，“补上缺的材料”和“调整项目计划”涉及的判断就不同。“已完成”背后还可能需要负责人核实。技术上都能叫一次更新，放到业务里，却不能按同一种方式处理。

我的设计重点，是分清信息整理、异常核对和需要负责人作出的确认。能按既定规则写回的内容，就按规则处理；需要判断的地方，要对应到实际职责和权限。流程图可以把这件事标出来，但负责人仍要在业务中确定。

项目记录显示，客户周会从 60 分钟缩短到 15 分钟，核心团队人均每周节省汇报时间 30 分钟。前一个数字说的是开会时长，不是整理纪要的时间。

这说明项目减少了一部分协作负担。我还想继续看：有没有因此漏掉信息，异常是否更容易发现，负责人看完是否知道下一步。对我来说，会议少花时间重复已经写下来的进展，才能多留些时间讨论分歧、风险和需要作出的决定。会开得短了，这些事有没有做好，也得接着看。

算薪最初在技术上可行。实际使用后，员工频繁临时调往其他城市，规则跟着变化，硬编码脚本也要不断修改。最终，项目没有采用 Agent 算薪。

这次让我更在意一个方案交付以后怎样用下去。规则要有人解释，变更要有人维护，结果也要有人复核。如果这些工作都没少，只是换了个地方做，自动化就未必划算。演示时可以挑一次规则稳定的情况，业务却不会从此不再变化。

下次遇到类似需求，我会先拿近期真实发生的例外走一遍：谁需要判断，谁来修改，哪些结果要重算。把这些事说清楚，再决定让系统接手到哪一步。