喜欢结果，不等于喜欢这份工作

这几天，我看着一套内容流程自动往前跑。

它先读最近收藏的 30 条材料，再和过去 60 篇文章做向量去重。能交给程序的选题排序、配图、翻译，都尽量交出去。

可真走到最后，草稿要过微信接口，博客要过内容系统，文章还要进知识库。任何一步超时，都得先查远端到底写进去没有，不能凭本地一句“失败”就再发一遍。

我原来想省掉的是重复劳动。跑久了才发现，有些麻烦不是自动化没做好，而是这件事本来就需要和别的系统、别的人对齐。

工程师很容易把工作分成两半。

一半叫“真正做事”：写代码、画方案、解决问题。另一半叫“被迫协调”：确认需求、等接口、解释取舍、约上线窗口。

前一半让人有成就感，后一半常常让人烦。于是我们会产生一个错觉：只要流程更好、工具更强、AI 再聪明一点，后一半迟早能被砍掉。

但企业里的代码很少独自成立。你改了一个字段，调用方要不要跟着改；你提前上线，数据端能不能接住；方案更漂亮，交付时间会不会超出窗口。这些都不是代码外面的噪音，而是代码能不能变成结果的条件。

需要多人完成的工作，协调不是附加税，它就是工作的一部分。

微软研究院在 2009 年研究过一个约 300 人的软件团队。他们访谈了 26 名成员，又用 775 名工程师的调查做补充，最后把影响协调的因素归成三类：沟通、能力和合作意愿。

这项研究很旧，也不能代表所有公司。可这三个条件到今天依然很直白：对方有没有听明白，有没有时间和能力接住，愿不愿意按同一个目标行动。工具可以让信息传得更快，却不能自动让这三件事同时成立。

这也让我重新理解“喜欢一份工作”。

有人喜欢写代码时那种问题被拆开的感觉，却不喜欢需求反复；有人喜欢产品上线后的反馈，却不喜欢和用户解释；有人想拍一部好电影，却讨厌预算、档期和几十个工种互相等待。

这不一定说明他不热爱，也不说明组织一定有问题。更可能的情况是，他喜欢这件事最亮的那一段，却没把它的完成方式算进去。

职业不只是一项内容，还带着一种工作方式。投资研究可以长时间独自推进，软件产品却天然要接上用户、市场、测试和运维。选了后者，也就选了更多对齐、等待和妥协。

当然，烂会议、职责模糊、反复改口都可以改善。把浪费说成“工作特性”，只是替管理问题开脱。

边界在于：删掉这次沟通以后，事情还能不能完整交付？如果答案是否定的，那就该优化它，而不是幻想它从此消失。

AI 也没有改变这笔账。

它能替我翻译文章、整理材料、检查格式，甚至把一段清楚的需求直接变成代码。可到了接口权限、发布时间、内容边界和失败后的责任，仍然得有人确认。

自动化把重复动作拿走以后，反而把剩下的协作照得更清楚：哪些是以前没设计好，哪些是这件事无论如何都要付的成本。

喜欢结果，只决定你愿不愿意开始；能不能长期做下去，要看你是否接受它真实的工作方式。

回到那套每天自动跑的流程。它确实让我少点了很多次鼠标，却没有把“和外部世界打交道”这件事删掉。

文章能不能写出来，是一个问题。它能不能安全、准确地走到该去的地方，是另一半工作。