想象这样一个工作日。
AI替你整理了会议纪要，生成了经营报表，还写好了下一次活动的方案。原本需要慢慢做的事情，现在很快就有了结果。
但你依然没有空下来。
纪要需要核实，报表需要对数，方案需要挑选。几个工具不断通知你“任务已完成”，你又开始逐个检查，把结果放到对应的系统里，再向同事解释哪些可以用、哪些还要改。
到了下班时，后台显示AI完成了不少任务，你却觉得自己只是换了一种忙法。
这是一个假设场景，但它值得每个正在用AI的团队问一句：我们想省下的，究竟是某个动作的时间，还是办成一件事所需要的总劳动？
10月29日，微软发布了一份内部AI部署手册。其中一个明确的主张是：在自动化之前，先检查业务流程，找出工作在哪里卡住、哪里存在浪费，以及什么真正创造价值。它还提出，评估时应追问节省出来的时间被用于何处、带来了什么结果。
沿着这个思路看，企业引入AI，有一个容易忽略的起点：先确认原来的工作是否值得原样保留。
模型越来越会做事，并不代表我们交给它的每件事都值得做。
设想一家连锁企业，每次促销结束后，运营人员都要把销售数据从业务后台导出来，填入一份周报表格，再整理成汇报材料。
后来接入AI，这几步都可以自动完成了。员工不再反复复制粘贴，这当然是进步。
但继续往下问：这几份材料分别给谁看？看完之后，要作出什么决定？如果一个数字变了，哪一份才算数？有没有一份表格，只是因为几年前某位负责人要求过，后来就一直保留到了今天？
答案不同，适合的改造方式就不同。
管理者如果需要比较不同门店的活动效果，汇总分析仍然有价值。财务如果需要核对退款与实际收入，独立检查也有价值。
但如果三份材料只是换了格式，使用同一批数据，最后还要员工来回解释为什么不同步，那么更快地生成三份材料，未必是最值得投入的方向。
企业也许应该先确立一份可信的数据来源，再按实际需要呈现给不同的人。哪些材料可以不再生成，哪些信息只在异常时提醒，需要负责业务的人重新判断。
这里并没有“表格越少越好”的统一答案。真正值得检查的是：每一个步骤，都在帮助谁作出什么决定，或者守住什么必要条件？
有些工作服务于业务结果，有些工作承担核实和约束，还有一些工作只是人为了弥补系统之间的断点而额外付出的劳动。
如果不作区分，就可能出现两个相反的问题：把可以省掉的重复劳动全部自动化保留下来，又把真正必要的检查当成提效障碍。
比如，一笔退款需要确认退款对象和金额。过去员工为了做这项检查，要在几个页面之间来回切换、寻找订单、整理凭证。
AI可以帮助收集这些材料，把需要判断的差异清楚地展示出来。可以省掉的是找资料、抄信息和整理格式的时间，核实对象与金额的责任仍然需要有人或可靠机制承担。
“这一步耗时很长”，并不能直接推出“这一步应该取消”。
更值得问的是：时间花在了作决定上，还是花在了为这个决定准备材料上？
当审批人面对的是一份很长、却看不出关键差异的AI总结，审批可能仍然很累。把它缩成一个“同意”按钮，也不等于真正改善了判断条件。
因此，让AI参与流程优化，也要讲清楚谁有权改变流程。AI可以发现重复、建议合并步骤，但“帮公司提高效率”的目标，并没有自动包含取消审批、改变权限或降低验收要求的授权。
业务负责人应当明确调整哪些规则，适用什么范围，如何验证效果。执行助手再按照确认后的规则办事。
还有一种忙碌，甚至可能发生在AI工作得很准确的时候。
当产出变得便宜，组织对产出的需求也可能跟着增加。
以前做一次活动方案需要投入不少时间，团队会先想清楚需求，再决定是否启动。现在一句话就能生成，讨论中很容易变成：“再来几版”“顺便把各个门店都做一份”“明天再更新一下”。
生成的成本降低了，选择、审阅、协调和承担决定后果的成本，却不会同比例消失。
假如每个部门都更容易产生材料，而接收材料的人仍然只有那么多，那么一部分效率提升，就可能变成别人收件箱里的新增工作。
这时，员工未必是在替AI纠错。他可能只是在处理更多准确、完整，却不一定需要的内容。
所以，“AI输出质量已经很好”与“员工仍然忙不过来”，完全可能同时成立。
管理者需要决定的不只是哪些工作交给AI，还包括哪些新增工作值得发起。不要因为生成容易，就默认每一份内容都应该被制作、阅读和回复。
否则，企业可能得到更多文档、更密集的汇报和更多待确认事项，却很难说清客户究竟获得了什么。
效率统计还可能漏掉另一类成本：人被打断的次数。
一个助手帮你节省了一段操作时间，却在过程中反复询问、发送提醒，事后还需要你补充上下文。单看每次打扰都不长，分散在一天里，却可能让人很难连续完成自己的工作。
原来是自己集中处理一件事，现在成了随时准备接管几件事。操作负担下降了，注意力负担却未必下降。
这也解释了为什么“工具估计节省了多少分钟”，不能直接等同于“员工多出了多少可以使用的时间”。
节省的时间可能很零碎，也可能被审阅、返工和新增任务重新占用。企业如果想知道AI是否让工作变好，就需要把这些部分一起看见。
一个值得尝试的做法，是先选一项高频工作，从需求出现一直看到结果被实际使用。
原来总共等了多久，有多少人在参与，哪些时候只是等待，哪些时候必须判断；接入AI之后，检查和纠错花了多少时间，打扰了谁，异常最后由谁收拾。
比较时还要考虑任务难度、业务量和结果质量。简单任务变多、复杂任务变少，也会让平均用时看起来下降，不能直接把变化都算在AI头上。
对于员工，可以看能否更少被打断、更少重复录入，是否有机会把时间用于需要经验的工作。对于客户，可以看等待是否缩短、问题是否真正解决。对于企业，可以看相同投入是否支撑了更好的服务或更多有效业务。
员工不一定因此每天提前下班。释放出来的能力也可以用来改善服务、处理积压或开拓业务。关键是明确这些能力被用到了哪里，而不是一边宣布大量时间被节省，一边对员工的忙碌感到困惑。
值得追问的，是那些省下来的动作，最终有没有变成可以使用的工作能力。
从这个角度看，AI进入业务系统的价值，也需要重新理解。
一个软件后台的页面和按钮，是过去组织工作的一种方式。智能体接入之后，如果只照着原来的页面把所有动作重新做一遍，就很容易连历史遗留下来的重复劳动一起继承下来。
软件厂商更有价值的工作，是把业务真正需要的能力、条件和结果梳理出来。哪些事情可以直接办理，哪些要等待决定，哪些结果能够被其他环节继续使用，需要明确表达。
我们把智能体接受人或组织的委托，进入已有业务系统替人办事的这类场景，称为A2B（Agent-to-Business）。
它让我们把注意力放在一种业务关系上：人把什么事情交出去，系统提供哪些能力，智能体可以推进到哪里，谁来确认业务结果。
这也是我们整理ACC（Agent Capability Contract，智能体能力契约）的出发点之一。我们希望面向智能体开放的能力及其治理要求，能有共同理解、检查和复用的表达，减少每接一个助手就重新解释一遍的成本。
ACC提供的是公共契约参考。哪些流程值得保留、谁有权调整公司的制度，仍然需要组织自己决定；业务系统也仍要执行自身的规则和最终授权。把规则写清楚，是帮助参与者协作的基础，具体落实还需要相应的执行机制。
我们将相关思考做成了开源实现BailingHub，并在自己的业务接入中持续改进。希望贡献的，也包括实际对接中发现的重复工作、难以交代清楚的边界，以及为解决这些问题积累的经验。
对软件行业而言，机会就在这些具体的地方：让用户少做一轮无意义的搬运，让一次必要的判断更容易完成，让已经确认的事实能够被后续工作可靠使用。
一个值得长期使用的AI系统，应当让人在明确边界内越来越容易把事情交出去，减少不必要的反复确认和持续盯守。
因此，下次看到一份AI提效报告，我们可以多问几句：哪些工作不再需要做了？哪些等待缩短了？哪些检查变得更清楚了？谁真正少了一些负担？
模型的速度当然重要。但企业最终需要的，是这些速度能够兑现的结果。
当AI完成的任务越来越多时，人应当更有余力去处理真正值得投入的事情。否则，我们可能只是把原来的忙碌，升级成了响应更快的忙碌。
