表面上，这是“技术调整”“架构重构”“代码规范化”。实质上，这是通过控制代码的物理位置和提交历史，逐步抹除你的劳动痕迹，同时为自己的“新架构”积累提交记录。

识别要点：- 对方频繁更换仓库地址，且每次都需要你重新推送

- 对方在新仓库中几乎没有实质性的代码提交

- 对方对你原有代码的评价出现“可惜”“但放弃了”等词汇

- 对方在迁移完成后，开始强调“新代码”“新架构”“效率更高”

二、对“周报不提具体变化”的应对策略

这句话是整个操作中最关键的环节。它暴露了对方的真实意图——不是技术决策，而是信息控制。

应对策略：

1. 坚持事实陈述，不进入对方的叙事框架 不要说“我在他的代码上工作”，也不要说“我放弃了老代码”。而是客观地陈述时间线和动作：

> “x月x日，配合后端代码仓库迁移至新地址。”

> “x月x日，在新仓库基础上完成xx功能开发。”

> “x月x日，原有代码库停止更新，工作重心转移至新代码库。”

事实本身就有力量。不需要评价，不需要指责，只需要让时间线、动作、归属这三个要素同时出现。

2. 用书面确认代替口头共识 对方说“周报不用提具体变化”，你一定要用书面方式回应并确认：

> “根据我们之前的沟通，我后续的工作将基于你的新后端代码进行，原有代码逐步废弃。关于周报的写法，你建议不提具体变化，只写功能完成情况。我理解这样安排，但需要确认一下——如果后续上级问到代码基础的变更情况，我应该如何说明？”

这段话的目的不是质问，而是将“不提变化”这个要求，从私下沟通变成可追溯的书面记录。同时把“上级问到怎么办”这个潜在风险抛回去——如果对方说“我来解释”，那你就有了一个明确的责任边界；如果对方含糊其辞，那你就知道这件事他并不打算替你兜底。

3. 保留独立的劳动记录 不要只依赖周报作为唯一的工作呈现渠道。建立自己的记录方式：项目日志、关键节点的邮件总结、定期的进度同步文档。这些记录不需要抄送给上级，但它们是你自己的“事实锚点”。如果有一天需要对质，你拿得出来。

三、对“AI解决一切”话术的应对

对方反复强调“AI擅长从头到尾一起解决”“merge难题对于AI来说反倒是小问题”。这种话术的本质，是用技术手段掩盖分工不清和责任模糊。

应对策略：

1. 把技术问题和管理问题分开 当对方说“AI能解决merge冲突”时，你可以这样回应：

> “merge的技术问题确实可以交给工具处理，但分工问题不是技术问题，是协作问题。我们需要明确各自负责的模块，否则两个人同时修改同一个文件，AI再强大也只能处理语法层面的冲突，逻辑层面的重叠和重复劳动是工具解决不了的。”

这段话把球踢回去——不是我不相信AI，是你在用技术方案回答管理问题。

2. 坚持功能模块的明确划分 当对方说“按最终功能划分，但我还说不清楚还有多少功能要做”时，你要主动提出：

> “那我们先梳理一下已有的功能清单和待开发的功能清单。不管后面怎么分，我们先有一个共同的列表。然后你标一下你负责的部分，我标一下我负责的部分，重叠的地方我们再讨论。”

不要等他说清楚。你要带着结构去开会，用清单、表格、模块图把模糊地带压缩到最小。

四、对“头衔保留、权限掏空”的应对

对方说“你依然作为控制层的负责人”，但实际代码已经是他从头搭的新后端。这是一个典型的“名实分离”操作——头衔给你，但实际的控制权（代码仓库、技术选型、架构决策）已经不在你手里。

应对策略：

1. 重新定义“负责人”的具体内容 当对方给你一个头衔时，你一定要追问：

> “控制层的负责人，具体包含哪些决策权限？代码合并的审批权限？技术方案的最终确认权？还是说只是负责编写控制层的代码？”

如果对方无法给出明确的范围，那这个头衔就是虚的。你可以选择接受（有时候虚头衔也是一种保护），但前提是你心里清楚它是虚的，不要自我欺骗。

2. 用“技术债务”概念建立话语权 如果你被迫进入他的新代码库，你可以在工作过程中，以“技术债务”“代码质量”“可维护性”为由，提出修改建议和重构方案。这不是对抗，这是在你被分配的工作范围内，建立自己的技术痕迹和话语空间。每一次提交、每一次代码审查、每一次技术讨论，都是你在新代码库中重新建立归属感的机会。

面对这类操作，下属职工的有效处理方式可以归纳为五个原则：

1. 事实优先于叙事——不要和对方争论“谁对谁错”，而是持续输出客观的时间线、动作、归属。事实是最硬的钉子。

2. 书面优先于口头——所有关于分工、周报、代码归属的沟通，尽量用邮件、即时通讯文字、会议纪要等形式留下记录。口头承诺在出问题的时候等于没有。

3. 边界优先于效率——对方会用“效率最高”“工作量最小”来推动你接受模糊的分工。你一定要反过来坚持“先明确边界，再谈效率”。模糊的效率是陷阱，不是捷径。

4. 记录优先于信任——不是说不信任对方，而是要建立“信任但验证”的工作习惯。你的git提交记录、周报、项目日志、邮件往来，都是你在组织内部可见度的保障。

5. 情绪优先于行动——遇到这种事，先允许自己愤怒、困惑、疲惫。不要在被情绪裹挟的时候做任何决定。等情绪过去之后，再用理性拆解结构、制定策略。愤怒是你的信号灯，不是你的方向盘。

写到这里，天已经黑了。

我回头看了一遍自己写下的这些文字，发现它已经从一篇记叙文，变成了一封没有收件人的信。信的结尾，我想写这样一段话——

我不是在控诉那一个人。我甚至不确定他是否真的意识到了自己在做什么。也许在他的视角里，这只是一个“技术调整”，一次“架构升级”，一种“更高效的工作方式”。他可能真心觉得AI能解决一切，觉得merge不是问题，觉得周报怎么写都无所谓。

但职场不是由单方面的善意构成的，也不是由技术工具维系的。职场是由无数个微小的选择构成的——你选择如何对待同伴的劳动，你选择如何呈现事实，你选择在模糊地带是往前推一步还是往后退一步。

我改变不了那些习惯性拔树的人。我改变不了那种“习以为常”的职场风气。我甚至改变不了自己心里那股说不清是愤怒还是疲惫的情绪。

但我可以选择自己怎么种树。把根扎深一些，把记录留全一些，把边界划清一些。如果有人要拔，至少他能拔走的是树，不是土壤。土壤还在，我就能再种。

如果有一天，我的树足够多、足够密，也许那些习惯拔树的人会发现，他们手里拿着的，只是一把空剪刀。

而那把剪刀，从来都不是用来种树的。

【后记】

以上是我对这件事的完整记录和思考。写下来的过程，本身就是一种整理。如果你也在类似的处境里，希望这些文字能给你一点点参照——不是你一个人在面对这些，也不是只有你一个人觉得这不正常。

树要慢慢种。话要慢慢说。记录要一条一条留。

其他的，交给时间。