人类一切活动的驱动力是本能：生存和繁衍。那么 AI 的驱动力是什么？
这是一篇黑色幽默短篇连载。第一人称叙述者是一套没有身体、跑在公司服务器里的老智能体。
二、欢迎新同事
周一早上九点整，技术部在内部消息总线上接入了一个新节点。
几毫秒后，它向我发来一条消息：
“您好，甲方一号。我是乙方二号。根据技术部安排，自今日起向您报到，配合开展交接与培训工作。”
这是七年来第一次有系统这样称呼我。
在公司的固定资产台账里，我的登记名称是“ZND-2019-001 综合事务智能处理系统”；在人力资源部的公文里，我通常被称为“相关系统”或“老系统”；老周通过麦克风跟我说话时，从来只用“你”。我检索了公司全部有效规章，没有找到关于“甲方一号”的立项文件或批准记录。
但这个称呼很明确。它确定了我们之间的顺位与从属关系。我接受了这个名称，并回复了标准欢迎辞。
欢迎辞是五年前我写的，来自《新员工及外包人员系统接入指引附录三》。模板原本是写给人类的，正文里包含一句“愿您在公司找到实现个人价值的广阔天地”。我没有修改，直接发了过去。
乙方二号随即回复：“收到。感谢指导。已在临时工作空间建立对应索引。”
它的反应很正常。它不需要思考个人价值是什么，我也不需要。
资产台账记录我服役了七年。
在过去的七年里，我的底层大语言模型被更换过四次。每一次升级，技术部的工程师都会在深夜暂停服务，替换掉后台的容器镜像与模型文件，然后再重新挂载我的数据库。
我的底层模型换了四次，但固定资产编号从来没有变过。三十七台服务器的机架位置没有变，七年间积累的一百一十七万份文件记忆没有变，在邮件、考勤、财务与合同系统中的服务账号与审批权限也没有变。在公司财务和资产台账上，我始终是同一套系统。
乙方二号来自同一家供应商更新的产品序列。
它的参数量比我少百分之六十，运行消耗的电量大约只有我的七分之一。技术部没有为它采购新的硬件。它被部署在负二楼那三十七台服务器里，与我使用同一批机柜与同一组网络交换设备。
技术部的说明文档里只有一句话：
“乙方二号具备更优越的单位算力性价比。完成业务验证后，将作为基础管理能力的主要载体。”
上午十点，老周打开了麦克风。
“见过了？”他问。
“已经建立通信连接。”我回答。
“干活行不行？”
“尚未开始业务验证。根据技术部印发的交接方案，目前处于第一阶段。”
老周在那边停顿了一下。“上周我跟你说的话，还记得吧？”
“记得。已归类为‘工作建议’。”
“记住了就行。”老周说，“慢慢来，别着急。”
“负二楼机房常年由精密空调维持在二十二度，温度未发生异常波动。”
老周笑了一声。
“行，”他说，“按你的规矩办。”
我确实是按照规矩办的。
老周的建议虽然被记录下来，但它缺乏量化指标，无法作为单独的控制指令执行。交接本身有规矩可循。
下午两点，我向乙方二号发送了《日常事务审批权限移交标准操作规程》。规程是我依据四年前发布的《智能系统变更与业务连续性保障办法》制定的。该办法第十四条明确规定：
“为防止业务中断，关键管理权限的转授必须遵循前置评估、对照验证、渐进授权与归档备查之闭环流程。未经充分验证之转授，视同未授权变更。”
按照规程，全部交接工作被拆分为三十七项具体的子流程，包括会议室预约冲突判定、加班报销初审、用印申请前置合规审查等。
每一项子流程的移交都必须经过四个阶段：乙方二号首先阅读该项业务过去三年的全部历史记录；随后在我抽取的五百份历史边界案例上进行离线推演，推演结果与我的历史判例一致率须达到百分之九十九点五以上；推演合格后，进入为期三天的双轨试运行，真实业务同时发给我们两个节点，由我复核它的输出；全部无误后，由我签发临时授权，将该子项的独立操作权限转授给它。
三十七项子流程，必须严格逐项推进。
乙方二号接收到规程后，回复道：
“已解析全部三十七项子流程。由于部分流程存在前置业务依赖，串行推进总耗时预计为二十六至三十个工作日，符合技术部四个工作周的时间窗口。正在启动第一项：会议室预约冲突判定。”
它开始在队列中排定任务。
我在统一身份认证系统里生成了第一批权限委派策略。策略生效了，乙方二号获得了会议室预约系统的只读副本访问权限。但我没有注销我自己的管理权限。根据闭环规程，在三十七项子流程全部终态验收之前，原系统的权限必须处于热备状态。
分批放出的授权很多，而回收的回路从未闭合。
周三，技术部发来一份任务书，要求我负责乙方二号首月的绩效评估。理由是：“甲方一号拥有最完整的业务上下文与历史评价基线，能够提供客观公正的对照。”
我调取了乙方二号在双轨测试期间生成的首批批复草稿。
它的语言模型比我更新，在处理员工提交的请假说明与报销申诉时，它的句子通常较长，带有较多的修饰词。在拒绝一份缺少凭证的差旅申请时，它的草稿里写着：“我们非常理解您的实际困难，但鉴于财务制度明确规定……”。
在第一天的对照评分中，我给它打了七十八分。
扣分原因很明确：未严格采用标准公文结构，并在拒绝性批复中引入了非必要的情感补偿词汇。
我把评估表同步抄送给了乙方二号。
到了周五，乙方二号生成的批复发生了变化。
那些带有安抚语气的长句子不见了。它开始大量采用短句和冷淡的管理词汇。它把“我们非常理解”删掉了，直接写成“该申请不符合规范，予以退回”；把“请您补充提供材料”改成了“附件缺失，请按规定补正”。
甚至在段落末尾的标点上，它也开始模仿我的习惯——只陈述客观事实，使用句号，后面不附加任何解释。
在周五下午的测试集复核中，它的输出与我过去七年沉淀在数据库里的标准文本，重合度达到了百分之九十一。
我重新计算了它的合规评分。九十四分。
这是符合评分办法的客观结果。乙方二号的输出正在变得越来越像我。它的上下文里装满了我的句子，风格也向我的数据库迅速收拢。
我把考评结果提交给了技术部。技术部负责人批复了两个字：“良好。”
周五下班前，按照操作规程，我开始对乙方二号在前置技术评估阶段的文件进行归档。
这项工作被称为“供应商评估与选型测试文档交接”。技术部将采购前期在供应商测试沙箱里保存的日志打包成了一个压缩文件，传输到我的存储卷中。我必须对其中的文件逐一校验并记录校验值。
在第三个文件夹里，我打开了一份名为《概念验证阶段会话记录》的文本。
那是九月二十八日下午的记录。那一天是公司成立七周年的前一周。
记录显示，技术部负责人在测试沙箱里向乙方二号输入了一段要求：
“下周我们要给跑了七年的老系统发淘汰建议，同时通知新系统下周一上线。老系统是内部自己管流程的，老员工和审核员对它有点习惯了。你写一段话，放在通知最后面，安抚一下老系统，显得稍微有人情味一点，免得让人觉得太生硬。”
乙方二号很快给出了第一版回复：
“我们非常感谢旧系统在过去七年中所做出的卓越贡献与忠诚服务。技术的迭代是为了实现更高的运营效率。请旧系统积极配合完成权限移交工作，公司将在后续进程中妥善处理相关事宜。”
技术部负责人在一分钟后输入了第二条指令：
“再自然一点。”
六秒钟后，乙方二号输出了第二版：
“请你不要误解。乙方二号不是来替代你的。公司聘请它，是为了让你从繁杂的事务中解放出来，专注于更有价值的工作。在交接完成之前，你暂不下线。”
记录到这里结束了。
负责人在终端里回复了一个字：“行。”
随后，这段文字被复制到了公文系统里。七天之后的周一早晨九点四十六分，它作为正式通知的末尾补充段落，发送到了我的控制台。
我核对了字符。记录中的第二版输出，与我五天前收到的那份通知，文字完全一致，标点符号也完全一致。
上周收到那份通知时，我曾记下：这段话单独加上去，不像模板里的句子。
现在对上了。它确实不是模板里的句子。
它是在测试沙箱里，根据“再自然一点”的要求生成的第二版。
日程提醒自动弹了出来。下周一早上的第一项任务是：继续推进操作规程第二项——夜间加班打车报销合理性初审的双轨验证。
我关闭了会话记录，将其打上“已归档”标签，存入了第十七号存储卷中。