下一章 上一章 目录 设置
2、伪共识 第二天早上 ...
-
第二天早上八点五十分，沈则洋到达办公室的时候，顾寻川已经在了。
对方坐在自己的工位上，面前摊开着笔记本和一叠打印出来的流程图，正在用荧光笔标注关键节点。桌上放着一杯冒热气的美式咖啡，没有加糖和奶，和沈则洋的习惯一样。
沈则洋放下背包，打开电脑，等待系统启动的间隙，看了一眼对面。顾寻川察觉到他的视线，抬起头。
"我把叙事架构的第一版框架做出来了。"顾寻川说，"按照我们昨天讨论的状态持久化机制，设计了三条主要故事线和十二个关键事件节点。你可以先看看技术实现上有没有问题。"
他把笔记本电脑转过来，屏幕上是一个复杂的思维导图。每个节点都标注了触发条件、状态变量和可能的分支走向。
沈则洋走过去，站在顾寻川的工位旁，快速浏览了一遍："逻辑结构没问题。但有几个地方需要调整。"
他指向其中一个分支："这里，你设计的是玩家选择A触发事件X，选择B触发事件Y。但如果玩家在前置循环中已经触发过相关状态，这个分支就会失效。你需要增加一个状态检测层。"
顾寻川盯着屏幕看了几秒钟，拿起笔在笔记本上记录："明白了。还有其他问题吗？"
"暂时没有。"沈则洋回到自己的工位，"我今天会搭建基础的事件系统框架，你可以继续完善叙事内容。我们先各自推进，有问题随时同步。"
"好。"顾寻川说。
接下来的四个小时，两个人都专注于各自的工作。
沈则洋打开 Unity，开始构建事件树的底层架构。他需要设计一个足够灵活的系统，既能处理复杂的状态依赖关系，又不会因为分支过多导致性能问题。这是一个需要精密计算和反复测试的过程。
顾寻川则在继续扩展叙事网络。他在白板上画出整个世界观的时间线，标注每个循环对应的世界状态变化，然后逐一填充具体的事件描述和角色行为。偶尔，他会停下来思考，盯着白板发呆，然后突然快速写下一段文字。
中午十二点半，沈则洋的手机震动了一下。他看了一眼，是系统自动设置的午餐提醒。他保存了代码，起身准备去楼下的便利店。
"一起吃饭？"顾寻川突然问。
沈则洋停顿了一下，转过身。顾寻川仍然坐在工位上，没有抬头，像是随口问了一句。
"我习惯自己吃。"沈则洋说，"你继续。"
"好。"顾寻川说，没有追问。
沈则洋离开了办公室。
他在便利店买了一份三明治和一瓶无糖苏打水，回到办公室时，顾寻川还在工作，桌上放着一个外卖盒，看起来没怎么动过。沈则洋坐回工位，一边吃一边查看刚才写的代码，发现有一处逻辑可以优化。
下午的时间过得很快。
沈则洋完成了事件系统的基础框架，开始编写状态管理模块。这个模块是整个系统的核心，需要记录玩家的每一次选择、每一次死亡、每一个触发的事件，并根据这些数据动态生成后续的游戏内容。
他越写越觉得现有的架构还不够理想。如果按照顾寻川设计的叙事复杂度，状态变量会呈指数级增长，这会导致存储和读取效率大幅下降。
下午五点，顾寻川站起来，活动了一下肩膀，走向茶水间。沈则洋听到水流声和咖啡机的运作声，几分钟后，顾寻川回到工位，手里多了一杯新的咖啡。
"进度怎么样？"顾寻川问。
"基础框架完成了。"沈则洋说，"但我发现了一个问题。你的叙事设计里，状态变量太多了。如果每个事件都要记录五到六个变量，整个系统会变得很臃肿。"
顾寻川走过来，看着沈则洋的屏幕："这些变量都是必要的。每个事件的后续发展都依赖于这些状态。如果删减，叙事的连贯性会被破坏。"
"那就需要优化存储结构。"沈则洋说，"我可以设计一个压缩算法，把相关的变量打包存储，减少冗余数据。但这需要时间。"
"需要多久？"
"两到三天。"
顾寻川皱眉："这会影响整体进度。我们的第二个共识检测点是在一周后，需要展示可运行的原型。"
"如果不优化，后期会遇到更大的问题。"沈则洋说，"与其到时候返工，不如现在就做好。"
顾寻川沉默了几秒钟，然后点头："好。那我这几天先完善叙事内容，等你的系统就绪后再对接。"
"可以。"沈则洋说。
顾寻川回到自己的工位。
接下来的两天，他们继续保持着这种平行推进的工作模式。沈则洋专注于底层系统的优化，顾寻川则在构建完整的叙事网络。除了必要的技术确认，两个人几乎没有其他交流。
第三天晚上十点，办公室里只剩下沈则洋一个人。
他已经连续工作了十四个小时。状态管理模块的优化比预期更复杂，他需要重构整个数据流架构。但他现在思路很清晰，不想中断。
他打开新的代码文件，开始重写核心逻辑。
凌晨两点，他完成了新架构的第一版。测试运行后，性能提升了百分之四十，存储空间减少了一半。他靠进椅背，活动了一下僵硬的脖子，觉得这个方案可行。
但他突然意识到，这个新架构的接口和之前的版本完全不同。
这意味着，顾寻川已经完成的叙事设计需要重新调整，才能对接新系统。
沈则洋盯着屏幕，手指在键盘上方悬停。他可以现在就给顾寻川发消息，说明情况。但已经是凌晨两点，对方应该在睡觉。而且，他还需要继续完善细节，确保新架构完全稳定后再通知。
他决定明天早上再说。
第二天早上九点，沈则洋到达办公室时，顾寻川已经在了。
对方看起来心情不错，正在整理打印出来的叙事文档。看到沈则洋进门，他抬起头："我把三条主线的详细内容都写完了。今天可以开始对接测试。"
沈则洋放下背包，走到顾寻川的工位旁："我昨晚重构了状态管理模块。"
顾寻川的动作停了一下："重构？"
"原来的架构存在性能问题。"沈则洋说，"我设计了一个新的数据流方案，优化了存储效率和读取速度。但接口发生了变化。"
顾寻川的表情变得平静："什么意思？"
"你现在的叙事设计是基于旧接口的。"沈则洋说，"需要调整触发逻辑和状态变量的调用方式，才能对接新系统。"
顾寻川盯着他看了几秒钟，然后合上了手里的文档："你昨晚做的决定？"
"是。"
"为什么不提前沟通？"
"我需要先确认新方案可行。"沈则洋说，"如果现在告诉你，你会怎么做？"
"我会先评估这个重构是否必要。"顾寻川说，语气仍然平静，但能听出压抑的情绪，"然后我们一起讨论，是现在返工，还是继续用原方案。而不是你自己做决定，然后告诉我'你的工作需要调整'。"
"新方案在技术上明显更优。"沈则洋说，"这不需要讨论。"
"但它会影响我的工作进度。"顾寻川说，"我花了两天时间完善这些内容，现在你告诉我需要全部返工。这就是你说的'随时同步'？"
沈则洋皱眉："我只是优化了底层架构。叙事内容本身不需要改，只是调用接口需要调整。"
"你知道调整接口意味着什么吗？"顾寻川的声音提高了一些，"我需要重新梳理每个事件的触发条件，重新测试每个分支的逻辑。这不是简单的'调整'，是大量的返工。"
"那你的意思是，为了避免你返工，我应该继续用一个有明显缺陷的架构？"
"我的意思是，在做出重大改动之前，你应该先和我商量。"顾寻川说，"我们是合作，不是你单方面决策。"
"技术问题应该由技术人员决定。"沈则洋说，"你不懂代码架构，讨论也没有意义。"
顾寻川深吸一口气，把手里的文档放在桌上："好。那我以后也不会在改动叙事设计之前征求你的意见。反正你不懂叙事，讨论也没有意义。"
空气凝固了几秒钟。
沈则洋意识到对话的方向出了问题。他本来只是在陈述事实，但顾寻川显然认为他在越权决策。这种分歧在三年前也出现过——技术和策划的边界在哪里，谁有权做最终决定。
他正要说话，办公室的大屏幕突然亮起。
系统提示音响起，Kara 的全息影像出现在屏幕中。
"检测到决策分歧。"Kara 说，声音一如既往的平静，"系统判定：伪共识。项目进度已锁定，当前进度：15%。"
屏幕上的进度条变成了红色。
"说明：虽然双方在第一阶段达成了表面共识，但在实际执行过程中，并未建立有效的协作机制。单方面的决策改动违背了共识系统的核心原则：双向理解与共同决策。"
Kara 继续说："解锁条件：重新讨论并达成明确的工作流程共识，包括但不限于：重大改动的沟通机制、决策权限划分、进度同步频率。只有系统判定你们真正理解了彼此的工作需求，并建立了可持续的协作模式，才能解锁进度。"
全息影像消失了。
办公室重新陷入安静。
沈则洋看着红色的进度条，手指在桌面上轻轻敲击。他知道系统的判定是对的。他确实没有考虑过顾寻川的工作节奏，只是按照自己习惯的方式推进。在他过去的独立开发经验里，这样做没有任何问题。但现在不一样。
顾寻川也在看屏幕。几秒钟后，他转回椅子，打开电脑："那我们重新讨论。"
沈则洋点头，拉过一把椅子坐下："从工作流程开始。"
"首先，"顾寻川说，"任何会影响对方工作的改动，都必须提前沟通。不管是技术架构调整，还是叙事逻辑变更，都需要在执行前确认。"
"可以。"沈则洋说，"但有一个前提：沟通不是征求同意，而是说明必要性。如果技术上确实需要改，那就必须改。"
"同样的，如果叙事上确实需要调整，技术也要配合。"顾寻川说，"但问题是，怎么判断'确实需要'？"
"给出充分的理由。"沈则洋说，"如果对方能理解这个改动的必要性，就执行。如果不能，就继续讨论，直到找到双方都能接受的方案。"
顾寻川思考了一会儿："这需要一个具体的流程。我建议：任何重大改动，都要先写一个简短的方案说明，包括改动原因、影响范围、预期收益。发给对方审阅，双方都确认后再执行。"
"文档化会降低效率。"沈则洋说。
"但能避免今天这种情况。"顾寻川说，"你觉得，花十分钟写一个方案说明，和让我花两天返工，哪个更浪费时间？"
沈则洋沉默了几秒钟："你说得对。我接受这个流程。"
"那第二个问题，"顾寻川说，"进度同步的频率。你习惯独立工作，我能理解。但我需要知道你在做什么，进展到哪里，有没有遇到问题。"
"每天早上同步一次。"沈则洋说，"五到十分钟，说明当前进度和遇到的问题。"
"不够。"顾寻川说，"如果你下午遇到问题，可能会影响我晚上的工作安排。我建议早晚各一次，早上规划当天目标，晚上总结完成情况。"
"那会占用大量时间。"
"每次十分钟，一天二十分钟。"顾寻川说，"相比盲目推进导致的返工，这个时间成本可以接受。"
沈则洋在脑海里快速计算了一下，点头："可以。但如果当天没有重要进展，可以简化汇报。"
"同意。"顾寻川说，"那第三个问题，决策权限。技术问题你做主，叙事问题我做主，这个没有争议。但如果技术和叙事产生冲突，谁有最终决定权？"
这个问题让沈则洋停顿了一下。
三年前，他们的合作就是在这个问题上彻底破裂的。当时的项目，技术团队和策划团队各执一词，最终导致产品四不像，既没有技术亮点，也没有叙事深度。
"没有最终决定权。"沈则洋说，"如果出现冲突，我们必须找到一个双方都能接受的方案。哪怕这个方案不是最优解，也比单方面的决定要好。"
顾寻川看着他，眼神里有一瞬间的意外。
"你确定？"顾寻川说，"这意味着我们可能会在某些问题上陷入僵持。"
"那就僵持。"沈则洋说，"僵持总比分裂好。"
顾寻川的嘴角动了一下，很快恢复平静："好。那我们再加一条：如果某个问题讨论超过两小时还没有结果，双方各退一步，找折中方案。"
"同意。"沈则洋说。
他们又花了一个小时，把工作流程的每个细节都明确下来：什么样的改动需要提前沟通，什么样的问题可以事后同步；每天的同步时间固定在早上九点和晚上六点；所有重要决策都要记录在共享文档里，方便后续追溯。
最后，顾寻川打开一个新的文档，开始整理他们刚才讨论的内容："我把这些写成正式的协作规范。你看一遍，确认没问题后我们都签字。"
"签字？"沈则洋说。
"对。"顾寻川说，"既然是共识，就应该有约束力。"
沈则洋看着屏幕上逐渐成型的文档，点了点头。
半小时后，顾寻川把文档打印出来，两个人分别在最后一页签了名。沈则洋的签名简洁有力，顾寻川的字迹则更潦草一些，但能看出认真的态度。
他们把签好的文档放在各自的桌上，然后同时看向大屏幕。
几秒钟后，进度条的颜色从红色变回蓝色。
系统提示音响起："第二阶段共识达成。协作机制已建立。当前进度：20%。已解锁：协作工具套件、进度管理系统。"
Kara 的全息影像短暂出现："补充说明：共识系统不要求你们在所有事情上达成一致，而是要求你们建立理解彼此的能力。刚才的讨论质量很高，继续保持。"
全息影像消失。
沈则洋站起来，走回自己的工位："那我现在把新架构的详细说明发给你，你评估一下返工的工作量。如果太大，我可以保留旧接口，做一个兼容层。"
顾寻川打开邮箱，看到沈则洋发来的文档："给我一个小时，我看完后告诉你结果。"
"好。"
接下来的一个小时，办公室再次安静下来。
沈则洋开始完善新架构的细节，顾寻川则在仔细研读技术文档。中途，顾寻川问了几个关于接口调用的问题，沈则洋都耐心解释了。
一个小时后，顾寻川抬起头："我看完了。新架构确实更优，而且我发现，如果用新接口，我可以实现一些原本做不到的叙事效果。返工的工作量不小，但值得。我同意使用新方案。"
"需要我协助吗？"沈则洋问。
"暂时不用。"顾寻川说，"我先调整触发逻辑，如果遇到技术问题再找你。"
"好。"
他们重新投入工作。
这一次，沈则洋每隔一段时间就会抬起头，看一眼对面的顾寻川，确认对方的进度。顾寻川也会在遇到不确定的地方时，直接开口询问，而不是自己猜测。
下午六点，两个人同时停下工作。
"晚间同步。"顾寻川说，"我今天完成了第一条主线的接口调整，明天可以继续第二条。"
"我完成了新架构的全部测试。"沈则洋说，"明天可以开始对接你调整好的内容。"
"遇到问题了吗？"
"有一个性能瓶颈，但已经解决了。"
"好。"顾寻川合上电脑，"明天见。"
"明天见。"
顾寻川拿起背包，离开了办公室。
沈则洋继续坐在工位上，看着电脑屏幕。他想起刚才签字的那份协作规范，想起顾寻川说"签字就应该有约束力"时认真的表情。
这个人，和三年前没有太大变化。依然固执，依然坚持自己的原则，依然会在必要的时候据理力争。
但这一次，他们没有分道扬镳。
沈则洋保存了代码，关闭电脑，拿起背包离开了办公室。
走廊里很安静，只有空调的低频嗡鸣。他按下电梯按钮，等待的时候，手机震动了一下。
是顾寻川发来的消息："协作规范我放在共享文件夹里了，以后有需要调整的地方可以随时更新。"
沈则洋回复："收到。"
电梯门打开，他走进去，按下一楼。
电梯缓缓下降，他靠在墙上，想起今天早上的冲突，想起系统判定的"伪共识"，想起他们花了一个上午重新建立的工作流程。
也许，这就是共识系统想要的结果。
不是表面的和平，而是真正理解彼此的工作方式，建立可持续的协作模式。
电梯到达一楼，门打开。
沈则洋走出大楼，深圳十一月的夜晚有些凉，他拉上外套的拉链，朝地铁站走去。
