OPC 时代的分工方式

刚才和产品经理、设计师讨论后续的产品规划，发现大家对「后续怎么做」的理解存在比较大的偏差。这里做个记录。

问题

讨论中大家下意识还是按过去的习惯分工：把一个项目拆成不同的阶段和功能，分给不同的人负责。比如数据分析安排一个人；生成脚本的内容安排一个设计师加一个开发；输出合成再按渲染方式拆，视频生成一个人、HTML 生成一个人、信息图生成一个人，各自配开发。

这个分法听起来很自然，因为过去几年我们都是这么干的。我一开始也顺着这个思路听，听到一半才意识到问题出在哪：这种分工的前提是「一个人做不完整条链路，必须多人接力」。而这个前提在 AI 时代已经不成立了。

这个模式是上个时代的模式，不是当前 AI 时代、特别是 OPC 时代的模式。

我认为应该是怎样的

现在应该是每个人完整地负责一整条线。比如并购重组这条业务线就由一个人负责，产业链由另一个人负责。这个人把这条链路里所有的内容全部搞定：

• 需要工具，就自己去 Vibe Coding 把工具开发出来；
• 需要处理数据，就自己去把数据处理搞定；
• 他自己就是这些工具的使用者。

最后一点很关键。因为开发者自己就是用户，他才能真正知道该开发什么需求，开发出来的东西才是最符合实际需求的。把「开发工具的人」和「用工具的人」拆成两个角色，中间的信息损耗是上个时代没办法的办法，现在没必要再付这个成本。

对应地，角色的边界也要淡化。产品、设计、开发这些分工到后面会逐渐模糊，一个人既干产品、又干设计、又干开发，还干后面的运营和数据分析。这是趋势，不是可选项。

为什么要这么做

一个很现实的原因：产出压力。AI 把个人的产能放大了，相应地，对每个人的产出要求也水涨船高。一个人负责一整条链路，贡献是完整的、可衡量的；多个人共同负责一个项目，价值就容易说不清。分工方式如果还停留在上个时代，个人的价值体现不出来，处境会很被动。

再往后一步：人会往更高维度走

还有一个更远的判断：未来会逐渐剔除人在执行环节里的工作。人的知识可以通过蒸馏的方式沉淀下来，成为 skill 或知识库；之后更多靠 AI 自动化——通过一个 agent 调度其他 agent，层层往下传递，形成类似蜂群的 agent 集群，大批量、自动化地解决问题。

人的工作要跟着这个发展不断往上走：

• 现在（初级阶段）：构建 skill、编写 skill、调度 skill，或者制作某个 agent；
• 下一阶段（agent 集群成型后）：设计整个 agent 集群——agent 之间的调度、大规模 agent 的上下文管理、可观测性、agent 结果的校验等等。

适应不了这种变化的人会被淘汰，这句话不是恐吓，是正在发生的事实。

后续要做什么

后续再讨论产品规划时，先按两条原则校准：分工的基本单位从「功能」变成「业务线」；人的工作从「执行」变成「构建和调度」。落到具体动作上，我给自己列了一个清单：

• 产品规划按「一个人一条业务线」来排，不再按功能切分；
• 每个人认领的链路里，工具自己开发、自己用，把「我是用户」这个优势用足；
• 日常工作中持续把可沉淀的知识蒸馏成 skill，为后面的 agent 集群做准备。

这次讨论也算一个提醒：技术变了，但分工习惯是有惯性的。如果不在规划阶段就把旧模式拦下来，后面执行、复盘、考核的每个环节都会替它还债。