《职场吐槽日常》陈丶

76、领导总喜欢拔员工栽的树怎么办 项目启动那

　　项目启动那天，一切看起来都井然有序。

　　他说他负责前端，后端我们俩一起写。我后端经验多一些，自然多担待后端的主干工作。主动划分了项目的功能模块之后，我说了我正在做的模块，让他自己选择可以开发的独立模块，我们共用同一个后端代码仓库，各自推进，偶尔同步，像两条并行的铁轨，朝着同一个方向延伸。

　　第一个月还算平静。代码在长，功能在添，周报写起来也充实。然后他忽然发来消息，说换了后端项目的代码仓库地址，让我重新推送。我没多想——重构、迁移，都是项目里常有的事——便照做了。推送完之后，我等着他在新仓库里继续提交代码，但一连几天，静悄悄的。他的那个文件夹里，什么也没有。

　　我没吭声，继续在老仓库里写我的逻辑。

　　第二个月，同样的事情又来了一遍。他又换了一个地址，我又推了一次。这一次他总算有所动作——在项目里加了一个AI框架的readme.md文件。几百字，像个占位的旗帜插在一片空地上。

　　我盯着那个readme看了一会儿，心里隐约浮起一点说不清的异样。但很快就被手头的任务压下去了。

　　第三个月，他第三次更新了git仓库地址。

　　这一次我没有再跟着推。我选择留在老仓库里，继续写代码、改bug、搭环境。那条轨道虽然旧了些，但我知道它通向哪里。三个月来我所有的提交记录、所有的逻辑设计、所有的调试痕迹，都安安静静地躺在那里。我没有理由抛弃它们。

　　直到后端部署测试成功的那一天，他终于坦白了。

　　他说他搞了一个新的后端，自己从头搭了一套。他说两个功能版本会对比着看，但他的那套还不完善，功能也不全。

　　我坐在屏幕前，把这几句话读了两遍。

　　三个月。他换了三次仓库地址，每一次都让我把代码推过去，每一次他自己都没有实质性的贡献。他让我做这些动作的时候，自己的新后端已经在暗中搭建了。而我像一个人来回搬运砖石的人，每一次都被指引到一片新地基前，放下砖，抬头一看——工地上仍然只有我一个人。

　　然后他丢下一句“两个版本对比着看”，像是一个技术决策，轻描淡写。

　　老仓库里那三个月的心血，在他口中变成了“付出了心血的老代码确实有些可惜”。但可惜完了，也就完了。

　　周一的时候，他又发来了几条消息。

　　“我想了一下，觉得在我新的代码上继续应该是工作量最小的，你依然作为控制层的负责人，就是实际当中，对于bug和新功能让AI从头到尾直接改，这样效率最高。付出了心血的老代码确实有些可惜，不过我现在的代码除了文档之外也都是新的，之前的也都放弃了。目前还缺不少功能，还有很多bug，一起完善吧。你觉得如何？”

　　“代码可以各自拉一套，各自修改，及时push，及时同步，有冲突及早merge，应该会一切顺利的。”

　　“周报继续按照你的节奏写，不用提具体变化。”

　　我读完这几条，慢慢理清了他话里的结构。

　　“工作量最小”——是对我说的，意思是让我接受这个方案，不要抗拒。“控制层的负责人”——头衔还在，听起来我仍然是核心角色。“AI从头到尾直接改”——把技术手段摆出来，显得理性、高效。“之前的也都放弃了”——轻描淡写地把三个月归零。“周报不用提具体变化”——这一条最耐人寻味。

　　我试着理解他的逻辑：我的老代码要被放弃了，我要转到他的新代码上继续工作，但这件事不能写进周报。那么周报里写什么？写“修复了一个bug”？写“新增了一个功能”？这些功能和bug是在谁的代码上？是在他的新项目上。他的项目，他的代码，他的仓库。我像一个进入别人工地帮忙的工人，每天干完活，却不能提自己换了工地。

　　我回复他：“我明白你的意思，但我更新你的代码却不体现在周报里，那我周报写什么呢？毕竟老代码是要逐步废弃的，更新会越来越好，周报主要会以你的项目需求为主。”

　　这段话我写得很慢。每一个字都在克制。我不是在质问他，我是在陈述一个基本事实——如果你的代码替代了我的代码，而我不能写我在做你的代码，那我周报里到底有什么？

　　他又回复了：“写哪个功能OK了，写在改哪个方面的bug就可以了。”

　　这句话让我彻底看清了他的逻辑框架。在他的认知里，周报只是一份“做了什么动作”的清单，不涉及“在谁的代码上做”“基于什么基础做”“替代了什么做”。只要动作描述存在，周报就是合格的。至于这些动作的上下文、归属、历史——不重要。

　　这不是疏忽，这是刻意的模糊化。

　　他接着说：“我理解，我也想了很久分工问题，就是现在的vibe coding，其实AI擅长从头到尾一起解决，强制划分层次，反而增加很多工作量。最好就是按最终功能划分，但是这方面我还说不清楚还有多少功能要做。”

　　“我觉得merge难题对于AI来说反倒是小问题。”

　　这两句话让我看到了一种非常典型的当代技术人格：把一切问题都交给工具去弥合。分工不清？AI会处理冲突。历史代码被废弃？AI会生成新的。责任边界模糊？AI会“从头到尾一起解决”。工具成了万能的缝合剂，用来缝合他自己不愿面对的架构决策和协作伦理。

　　我最后回了一句：“那就一起梳理下，正好沟通一下进度。”

　　他说：“好的👌”

　　一个表情符号，结束了这场对话。

　　事情说完了。但真正让我坐在这里、一字一句写下这些的，不是那三个月的代码迁移，不是仓库地址的反复更换，甚至不是他另起炉灶的决定。

　　是那句话——“周报不用提具体变化”。

　　这句话像一把极薄的刀片，精准地切开了一个口子，让我看到了整件事的结构。他不是在搞技术架构，他是在搞信息架构。他控制代码仓库的地址，就控制了代码的归属；他控制周报的叙事，就控制了工作的呈现。当一个人的代码贡献可以被“不提具体变化”地抹去，当三个月的持续交付可以被“之前的也都放弃了”一句话归零，那么最终呈现在上级面前的，是谁的成果？谁的投入？

　　这是一个非常老练的操作。甚至不需要恶意，只需要一种习以为常的、对他人劳动的钝感。

　　我把这件事翻来覆去地想了好久。

　　他为什么要换三次仓库地址？第一次，可能确实是技术调整。第二次，他的新后端大概已经开始搭建了，他需要我的代码推过去，不是为了合并，而是为了“存在”——让那个新仓库看起来有内容，有历史，有人维护。第三次，他已经不需要我的代码了，但他仍然让我推，因为这样他的新仓库会持续有提交记录，而我老仓库里的三个月，会自然地被时间掩埋。

　　每一次让我“重新推送”，都是一次对劳动归属的重新锚定。

　　而他最后给出的“控制层的负责人”这个头衔，不过是一张漂亮的包装纸。里面包着的，是一个已经被掏空了的实际权限和责任边界。

　　他今年四五十几岁了。在这个IT日新月异行业里，我见过太多人，经历过太多项目。年轻的时候，遇到这种事会愤怒，会觉得不公平，会想找人说清楚。现在不会了。现在我更多的是困惑，是一种沉甸甸的、说不出口的疲惫。

　　我理解不了的是——你把前人的树拔了也就拔了，你还要把年轻人自己种的树也拔了，然后张冠李戴，说这棵树是你从头养到大的。

　　到底职场上这种人的存在意义是什么？恶心别人，成全自己？

　　遇见恶人多了，有时候会恍惚，好像所有人都是脏的。这不是一种理性的判断，这是一种被反复摩擦之后产生的条件反射。更可悲的是，这种人还不是一般的多，多到大家都习以为常了。好像职场本来就是这样的——上面的没参与要冠名，下面参与的连个署名都没有。

　　我有时候会想，这种行为如果放在别的领域，算不算某种形式的侵占？但似乎没有人会这样类比。因为代码是“虚的”，劳动是“看不见的”，git提交记录里的名字，好像也不具备真正的证明力。

　　可悲。可叹。非我所及。

　　我甚至向上苍许了一个不切实际的愿望——职场上拒绝这种蛀虫。不是因为他们能力不行，而是因为他们影响风气，也影响人心。一个团队里如果有一个人靠这种方式获得认可，那么其他人只有两种选择：要么也变成那样，要么沉默地承担双倍的劳动。

　　善良在这种环境里，真的会变成一种奢侈品。

　　但光愤怒没有用。光写记叙文也没有用。我得把这件事拆开，看清楚每一个关节，然后找到应对的策略。不是为了报复，是为了以后不再被同样的手法困住。

　　下面是我复盘之后，对这类操作的拆解和对策。

　　一、识别“仓库迁移”类操作的实质

　　这类操作有一个非常明显的特征：频繁变更底层基础设施的归属，并要求你配合迁移，但对方自身没有实质贡献。

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

　　识别要点：- 对方频繁更换仓库地址，且每次都需要你重新推送
　　- 对方在新仓库中几乎没有实质性的代码提交
　　- 对方对你原有代码的评价出现“可惜”“但放弃了”等词汇
　　- 对方在迁移完成后，开始强调“新代码”“新架构”“效率更高”

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

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

　　应对策略：
　　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不是问题，觉得周报怎么写都无所谓。

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

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

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

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

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

　　【后记】

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

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

　　其他的，交给时间。