AI 越来越强，公司为什么还是做不快？

这两天，我去了一趟北京，和青萍之末创始人、产业组织顾问舒书见了面。我们聊了Solo独立开发者社区，聊了WorkBuddy和AI，也聊到了播客。舒书老师在朋友圈写道：“一顿家常简餐，聊组织协作的坑，聊业务增长的取舍。” 对我而言，这趟北京之行也留下了一个值得继续想的问题。我做产品，也在运营独立开发者社区，很容易看到AI怎样扩展一个人的能力：过去需要找人配合的工作，现在有机会自己先做出初版。但当这些能力进入团队，一个人的提速，怎样才能变成一群人更快交付？ 回到具体的工作里，这个问题就有了更直接的表达：一个页面已经能打开、能操作，为什么开发还说需要时间？一份方案已经写得完整，为什么业务仍然不肯确认？AI让开发和分析更快产出结果，也让项目进度多了一种容易产生误解的信号：成果看起来已经在那里，工作却还没有结束。 以一个用于客户演示的页面为例，界面和交互可以很快搭出来，但进入实际业务，还要处理权限、数据、异常情况和验收标准。看演示的人关心它已经能做什么，负责交付的人则必须确认它在什么条件下不会出错。双方看的是同一个页面，对“完成”的理解却可能完全不同。 如果这些标准没有提前说清楚，展示出来的功能越完整，后续工作越容易被看成拖延。需求方觉得只剩一点收尾，执行方却知道还有业务规则尚未确认、数据需要接入、边界情况等待验证。讨论很容易从“还有哪些工作”滑向“为什么还没做好”，真正影响交付的问题没有解决，双方先消耗在解释进度上。 这种分歧原本就存在。AI的新影响，是把一个看起来完整的结果更早摆到所有人面前。在需求尚未澄清的项目里，视觉上的完成度，可能提前制造了进度上的乐观。工具省下的时间，能否变成团队提前交付的结果，取决于大家有没有把演示、可用与验收通过分别说清楚。 最近，一位用户对AI产品的反馈也让我注意到这段距离：“感觉他还是比较像一个大脑，执行还得自己去执行。”这句话讨论的是产品体验，但它提示了一个更实际的衡量方式：拿到结果之后，使用者还要做多少工作，事情才能继续往前走？企业同样需要问这个问题。一个环节的输出变快，并不意味着接手的人可以立即使用它。 研究已经提供了个人提效的证据。《Shifting Work Patterns with Generative AI》覆盖66家企业、7137名知识工作者，进行了为期六个月的随机实地实验。在实验后半程，获得工具且实际使用的员工每周处理邮件的时间减少约两小时，常规工作时间之外的工作也有所减少。但研究没有检测到，仅为个人提供AI工具会使任务数量或任务构成发生变化。 员工少做重复劳动、减少对私人时间的占用，是明确的收益。至于公司是否因此更快交付，需要另行观察。例如，一份报告提前写完，仍然要等到固定评审日才被处理，局部节省的时间就未必会改变整个周期；如果评审者可以因此更早介入、发现问题，后续返工才可能减少。 这使企业面临一个比“员工会不会用AI”更具体的问题：工作流程有没有接住工具带来的变化？如果执行环节提速，需求确认、审核和决策仍按原来的节奏运行，待处理的结果就可能集中到这些环节。管理者看到更多产出，执行者感到自己更忙，交付却仍然停在等待中。 等待之外，还有一些工作从来不容易被看到。一个可以演示的页面，容易让人看见布局、文案和交互；权限判断、数据一致性和故障处理，往往要到出问题时才受到重视。一份语言流畅的报告，也容易让人先接受结论，再发现其中的数据版本或引用依据需要核查。 这些工作没有消失。开发或分析环节提速之后，核验和修正仍然需要时间。如果团队把“已经做出结果”当作“任务基本完成”，就可能低估这部分工作。问题发生之后，又把此前被忽略的工作重新归为个人执行不力。 还有一部分成本发生在执行之前。企业里的任务背景，可能分散在合同、聊天记录、旧文档和个人经验中。同一个项目名称没有变，客户要求、业务口径和数据范围却可能已经调整。使用者必须找到足够信息，判断哪些仍然有效，再让AI开展工作。 2026年9月发布的WorkWorlds预印本考察了资料组织方式的影响。在以合成制药企业为主的环境中，研究进行了192次配对评测：当任务所需上下文被专门整理出来时，任务通过率为76.7%；换成完整的岗位可见环境，通过率为68.0%。主要差异出现在智能体是否找到足够证据的阶段。 这是一项有限规模的合成环境评测，不能直接当作企业部署效果。它提醒我们，展示AI能力时，任务相关文件可能已经被挑选出来；在实际工作中，寻找文件、确认版本、判断适用范围，本身就是劳动。企业如果只记录AI处理任务用了多久，就可能漏掉此前的资料准备，以及此后的检查和修正。 当这些准备由每个员工各自完成，公司还会付出重复成本。同一套背景被不同的人整理多次，同一个决定在不同文档里出现不同版本。更强的生成能力甚至可能把旧口径迅速扩散到更多材料中，接手者需要重新核对。企业要获得稳定收益，资料的维护责任和当前有效版本就必须清楚。 独立开发与团队交付之间，还有一个容易被忽略的差别：一个人做产品，通常可以边做边决定；团队则需要让不同的人接受同一套完成标准。判断权如何分配，影响着执行之后还要等待多久。 独立开发者决定先上线哪个功能，可以同时调整范围和实现方式。进入团队之后，销售可能已经向客户作出承诺，产品需要守住既定规划，研发要考虑维护，交付要满足验收。大家各自有理由，AI也可以帮助每个人更快整理出完整的依据。但形成更多理由，不等于更快形成一个可以执行的决定。 客户定制最容易显出这种差别。AI降低了首次实现的成本，一项需求看起来变得更容易接受；后续的维护、培训、特殊流程和兼容问题，却需要不同团队持续承担。是否接受这笔业务，不能只根据初版开发速度判断。承诺范围、维护责任和验收条件，需要有人统筹决定，否则签约环节增加的收入，可能把未被核算的工作留给后续团队。 这种取舍也不能全部交给工具。AI可以帮助补充知识、计算成本、整理冲突，但谁有权修改承诺、谁能够接受某项风险，来自组织的安排。一位员工理解了其他部门的顾虑，并不意味着他已经获得预算，或者能够改变对方的考核目标。 当然，AI也有机会直接改善协作。2025年发布的一项宝洁实地实验涉及776名专业人员。在特定产品创新任务中，使用AI的个人，其表现能够达到不使用AI团队的水平。 这说明，部分跨专业知识可以通过工具获得，原本需要等待他人提供的建议，有机会更快补齐。 企业应当区分这两类情况：缺少专业信息，工具可能提供帮助；已经掌握信息，却没有人能够确认结果或作出取舍，就需要调整决策方式。如果不作区分，公司容易持续为前一种问题购买能力，却让后一种问题继续阻塞交付。 判断AI投入是否有效，也需要追踪完整任务，而非只看使用次数。一项业务从提出需求到验收通过，总共用了多久？其中多少时间用于执行，多少用于等待，多少用于返工？在质量要求一致的条件下，把这些时间分开，才能知道工具真正缩短了哪里，哪些环节需要同步改变。 更早拿到可展示、可检查的结果，本来可以成为一种优势。团队有机会提前检查假设，让需求方更早反馈，避免等到投入大量开发之后才发现理解不同。要获得这份收益，就需要借助这些阶段性成果确认需求、验证假设，并且在展示时明确说明：哪些已经完成，哪些仍需验证，下一步由谁确认。 员工也需要让后续工作可以被看见。能够演示，并不代表权限已经正确；文字完整，并不代表依据已经可靠；功能跑通，并不代表异常情况已经处理。把这些状态说清楚，管理者才有可能为核验安排时间，为冲突安排决策，而不只是根据眼前的成果不断催促收尾。 AI越来越强，公司为什么还是做不快？答案需要落到具体项目里。有些团队缺少执行能力，有些团队等待资料，还有些团队迟迟没有统一完成标准。模型升级可以解决其中一部分，流程和责任的调整则决定了剩下的工作能否继续推进。 这趟北京之行让我更想追问的，也是这种从个人能力到共同结果的转变。社区、产品和内容都需要有人把事情往前推进，工具带来的可能性，最终要在具体的合作中兑现。下一次看到AI很快做出的成果，我会先问清楚：它完成了哪一步，距离可以交付，还剩哪些工作？