后编码时代【03】：OPC 是镜花水月

这是「后编码时代」系列的第 3 篇。
上一篇我们说到 AI 应该是"在"的——不需要被召唤，始终在场。这篇来介绍一个让"在"落地的协作模型。

---

从一个画面说起

你见过爵士乐队排练吗？节奏组铺好底子，萨克斯手开始 solo。他不需要回头问鼓手"接下来我要即兴什么调"，因为鼓手已经在听他的旋律，自动跟上。solo 结束，钢琴手接过去，不是从零开始，而是在萨克斯的旋律上继续发展。

每个人都轮到自己的部分。轮到你的时候，你接过了整首曲子的上下文——前面发生了什么、现在的情绪是什么、接下来可能去哪里。

你接过的是决策权和上下文，不是指令。

传统协作：传话模型

传统团队协作是一个"传话"模型：

产品经理 → 设计师 → 开发者 → 测试 → 上线
   "做这个"   "设计这样"  "代码写好了"  "测完了"

每一次交接，传递的是一句话。而一句话在传递中必然衰减——你玩过传话游戏吗？10 个人排成一排耳语传递，最后一个人说出来的和第一句完全不同。

这不是游戏，这是你每天的团队协作。产品经理说的"灵活配置"，到了开发者那里变成了"写死配置项"。开发者做的"临时方案"，到了下一个接手的人那里变成了"正式架构"。

OPC 是镜花水月——至少现在是

“一个人加 AI 就是一家公司”——OPC（One Person Company）是当下最火的概念之一。AI 编码 Agent 能写代码，AI 设计工具能出图，AI 分析能做商业决策。一个人指挥一群 AI，理论上什么都能干。

听起来很美。但如果你真的试过一个人做一个完整产品，你会发现：AI 让你一个人能干的事情变多了，但没让你一个人能做的判断变多。

前端开发者用 Claude Code 写了完美的组件——这是工程层面的专业判断。但他做不了架构层面的判断：用消息队列还是直接写库、服务怎么拆、缓存策略怎么定——那是架构师的专业。架构师也做不了产品层面的判断：这个功能该不该做、优先级是 P0 还是 P2、对核心指标有什么影响——那是产品经理的专业。产品经理同样做不了商业层面的判断：做这个产品方向对不对、商业模式成不成立、什么时候该 pivot——那是创始人和业务负责人的专业。

AI 让每一层内部的执行变快了。但没有消除层与层之间的边界——因为每一层需要的判断力，来自不同的经验和不同的信息维度。分工是事实，交接是必然。问题不是"怎么消除交接"，而是"怎么让交接不丢东西"。

传键盘：接过决策权

"传键盘"这个名字来自一个最朴素的画面：几个人围着一台电脑做东西，轮到谁了就把键盘推过去。接键盘的人不是从零开始——屏幕上开着前一个人的工作成果、搜索记录、未关的标签页。他能看到前一个人纠结的痕迹，看到哪些方案被排除了，看到当前走到哪一步。

物理世界里的传键盘，上下文是自然传递的。 屏幕没换，代码没关，浏览器标签还在。但在团队协作中，我们做的恰好相反——每次交接都是一个人关上电脑，另一个人从空白开始。

传键盘模型要做的，就是把物理世界里自然发生的上下文传递，在团队协作中重新实现：

结构化。 每个步骤不是模糊的"做这个功能"，而是明确的目标、完整的上下文、清晰的交付标准。做了什么决策、为什么、考虑过什么备选——全部结构化记录。这不是为了写文档，是为了让信息在传递中不衰减。

自动传递。 交接不依赖人写 handoff 文档。你完成一个步骤后，AI 自动总结你做了什么、记录关键决策、识别影响后续步骤的信息、整理成下一个执行者可以直接使用的格式。这是"传键盘"的关键动作——不是人传人（会衰减），而是 AI 传递（保真）。

AI 参与执行。 AI 拆解目标为步骤，为每个步骤匹配最合适的人，在执行过程中关联历史决策、检测冲突，在交接时生成上下文摘要。没有 AI，这个模型退化回传话模型——上下文传递和决策记录都需要人手动做，而上一篇文章已经说过了：人不会持续做额外的事。

一个具体场景

5 人的技术团队要加一个"用户通知"功能。

产品经理创建一个 Session：“用户需要在移动端收到实时通知”。AI 拆解成 5 个步骤，每个步骤有明确的目标和交付标准。

第一步，产品经理。 AI 主动提供上下文：当前系统已有邮件服务，三个月前团队选了极光推送做 Push（历史决策关联），建议沿用。产品经理定义通知类型和业务规则，完成后 AI 自动生成摘要：做了什么决策、为什么选极光推送、下一步需要注意什么。

键盘传到后端。 后端负责人拿到的不是一句"设计通知系统"，而是完整的上下文——产品经理做了什么决策、之前的技术选型是什么、当前架构有哪些现成组件。AI 帮他分析数据库结构，输出方案对比。他选了方案 B 并记录理由。AI 再次生成交接摘要。

键盘传到前端。 前端开发者拿到的不只是后端的 API 文档，还有"为什么选了方案 B"、“这个方案对前端有什么影响”。不需要去 Slack 翻记录，不需要拉后端开会问——上下文就在那里。

键盘传到测试。 测试工程师拿到的不只是"测一下"，而是每一步做了什么、有什么已知限制、重点测什么。他不需要开会对齐，因为对齐已经自动完成了。

最后一步，上线。 所有人做过的决策、考虑过的方案、排除过的选项——全部被记录。下个月有人问"通知系统为什么用方案 B"，搜一下就有完整上下文。半年后有人做类似功能，AI 主动关联这条历史。

轮到你的那一刻，你拥有了做决策所需的全部信息。 不是"去 Slack 翻记录"，不是"问老员工"，是系统主动把完整的上下文递到你手里。

传话模型像接力赛，传键盘模型像爵士乐队

传话模型像接力赛——每个人只看自己这一棒，交接时递过去一根棒子（一句话），信息在传递中必然衰减。

传键盘模型像爵士乐队——每个人轮到自己的部分时，接过的不是指令，是整首曲子的上下文。前面发生了什么、现在是什么情绪、接下来可能往哪走。

这不是和 Claude Code 竞争。Claude Code 是一对一的——帮你在自己的工位上干活更快，但不知道隔壁在做什么。传键盘模型做的是另一个层——让整个团队的决策过程被捕获、传递和复用。理想情况下它们是互补的：开发者用 Claude Code 写代码，传键盘模型捕获他写代码过程中的决策，把上下文传给下一个人。

这不是替代人，是增强人。但这个"增强"不是"帮你干活更快"——那是工具做的事。这是让你的团队多了一个"人"：它一直在场，带着全队的记忆，在你需要之前就准备好了。