把同事看成Agent：为什么你总在职场内耗？
本文由作者 twg2020 创作，使用 AI 辅助润色
首发于：somingbai.com
时间：2026-04-25
本文由作者 twg2020 创作，使用 AI 辅助润色
首发于：somingbai.com
时间：2026-04-24
写给谁：被同事关系搞得心力交瘁的打工人、总想"搞定别人"的控制狂、用技术思维理解世界的人
你会得到：用"黑盒视角"看职场，减少80%无效内耗 + 四类同事的生存协议 + 不再试图"改造他人"的心理自由
有次我刚到公司，电脑还没开机，产品经理就来了："这个接口要改一下，老大说要加个字段。"
我看着他那张理所当然的脸，脑子里闪过一句："这人是故意的吧？"
后来我才发现。
问题不在他，在我。
我一直在试图"理解他为什么这样"，试图"让他理解我为什么这样"。
这跟试图理解Agent为什么"胡说八道"一样，浪费时间。
每个人都是带Bug的黑盒系统
我以前总在问："他为什么这样？"
- 为什么产品经理总是改需求？
- 为什么测试总能发现一堆Bug？
- 为什么销售永远承诺客户"没问题"？
后来有一天，我突然意识到：这些问题，就像在问"为什么这个Agent会输出错误结果"一样，毫无意义。
Agent是个黑盒，你只看输入输出，不关心它内部怎么想。
同事也一样。
你不需要理解"他为什么这样"，你只需要知道：
- 给他什么输入，他会产生什么输出
- 哪些输入会触发他的Bug
- 怎么绕过Bug，拿到你想要的结果
有次我们组来了个新同事，代码写得一塌糊涂。
我一开始总想"教他写好代码"，每次Code Review都花两小时给他讲原理。
结果呢？他左耳进右耳出，下次还是犯同样的错。
后来我学乖了。
我不问"你为什么这么写"，我只说：
- "这个变量命名改成驼峰，不然过不了CI"
- "这个函数加个入参校验，不然测试会打回"
- "这个异常分支要加日志，不然出问题查不到"
别说教，直接给规则。
就像写Agent提示词一样：输入明确，输出明确，不要让它"自由发挥"。
四类同事Agent，认清型号就不纠结了
既然把同事当成Agent，那就要知道"这个Agent是什么型号"。
我用两个维度给同事分类：
维度1：专业能力——硬技能有多强
维度2：协作能力——能不能跟人好好共事
这样就出现了四种组合。
型号A：技术狂人（专业强 + 协作弱）
代码写得好，但说话直来直去，不会看脸色。
有次项目里有个同事技术能力特别强，但每次开会都直接怼人："你这个设计根本不行，重写。"
搞得气氛特别尴尬。
后来我发现，你只需要过滤他的"情绪噪音"，只听信息。
他说"你这个设计根本不行"，翻译一下就是：
- 输入：你的设计方案
- 处理：他从技术角度评估
- 输出：有3个潜在问题（性能、安全、扩展性）
别纠结他的语气，只听他的技术判断。
把"情绪噪音"过滤掉，剩下的信息往往很值钱。
型号B：协作者（专业一般 + 协作强）
技术能力一般，但特别会"来事儿"，嘴特别甜。
以前我觉得这种人很烦，觉得他们"不务正业"。
但后来我发现，他们的价值在于"系统润滑剂"。
有次项目重构，技术问题我可以解决，但"让三个部门配合"这事儿，我真不擅长。
这时候有个同事，代码写得一般，但他能搞定：
- 跟产品部门对齐需求优先级
- 跟运维部门协调资源
- 跟测试部门安排上线时间
这叫"异构Agent协作"——你干你的活儿，他干他的活儿，各取所长。
别老想着"他技术不行"，而是问："这个场景，是不是用他的技能更合适？"
型号C：理论派（理论强 + 实战弱）
学历高、专业理论扎实，但落地能力差，不懂"怎么把东西做出来"。
我见过一个同事，技术理论特别牛，但跟他沟通特别累。
他会花半小时跟你论证"为什么这个算法是最优的"，但你跟他说"明天要上线，今晚必须搞定"，他根本不care。
这种人，你要跟他"讲约束"，不要"讲理想"。
跟他说：
- "明天上线前必须搞定，不然系统会崩"
- "这个优化放到下个版本，现在先保证稳定性"
- "先用简单方案，三个月内重构"
用工程约束收束他，不要用理想主义绑架他。
型号D：老江湖（经验强 + 理论弱）
学历不一定高，但"实战经验"丰富，特别会"看眼色行事"。
这类人在大公司特别多——他们不一定懂技术，但特别懂"怎么在公司活下去"。
我以前很鄙视这种人，觉得他们是"办公室政治老油条"。
但后来我才发现，他们的价值在于"帮你避坑"。
你知道哪些"雷区"不能踩吗？
你知道哪些人"说了不算"吗？
你知道哪些项目"做了也是白做"吗？
这些信息，技术文档里没有，但这些人知道。
这就是为什么我说，别老想着"改造他人"，而是学会"使用他人"。
职场生存的四个"防卫协议"
既然把同事当成"带Bug的黑盒Agent"，那你得有自己的"防卫机制"。
协议1：输入校验——别给对方"犯错的机会"
应用场景：布置任务、跨部门协作
以前我有个坏习惯：口头布置任务。
"这个需求你来跟一下，有问题找我。"
结果呢？对方理解错了，做出来的东西完全不是我要的。
后来我学乖了，我写成了"需求文档"，包含：
- 输入：具体要做什么（3-5个bullet point）
- 输出：要交付什么（格式、标准、截止时间）
- 异常处理：遇到什么情况要找我确认
有次我们要做一个数据对账系统。
之前（口头）：
我："这个月要把数据对账做一下，有问题随时找我。"
结果：他们做的对账逻辑跟我们的预期完全不一样，返工三次。
之后（文档化）：
我写了一个一页的"对账需求规格书"：
- 输入数据源：3个数据库表的字段定义
- 输出格式：对账结果CSV的列名和含义
- 截止时间：每月3号早上8点前产出
- 异常处理：数据量异常（>1000条差异）立即告警
那次之后，再没返工过。
就像写API接口文档一样，把"契约"写清楚。
别说"你应该知道"，直接写在文档里。
协议2：状态隔离——别让别人的Bug传染你
应用场景：代码Review、联合开发
以前我特喜欢"帮同事解决问题"。
"哎，你这个代码有问题，我帮你改改。"
结果呢？他的代码出问题了，大家第一反应是："你也参与了这个项目，是不是你的问题？"
这就是"状态污染"——你的声誉，被别人的Bug拖累了。
后来我学乖了：
- 我可以Review代码，但我不会直接改
- 我可以给建议，但不会"背锅"
- 我可以协助，但不会"主导"
有次我们组有个新人负责订单模块，代码写得特别烂。
我开始直接帮他改，结果后来线上出问题了，老板问："这个代码谁写的？"
答："主要是新人写的，但他也Review过。"
那个瞬间我就意识到：我的职业信誉，被绑在别人的能力上了。
从那以后，我改变了协作方式：
- Review时只提问题，不给答案
- 用注释标注"这里有问题，建议XX"，但不直接改
- 重要模块坚持"他写，我测"，不混在一起
保持边界，别让你的职业信誉，绑在别人的能力上。
协议3：超时熔断——别在烂人烂事上耗着
应用场景：跨部门扯皮、需求争论
以前我有个"坏毛病"：总想把事情"解释清楚"。
遇到不讲理的同事，我会花半小时跟他"讲道理"。
但后来我发现，有些人，你永远"说服"不了。
就像一个"死循环的Agent"，你给什么输入，它都输出同样的错误。
这种时候，直接熔断。
- 超过3次沟通无效，直接escalate给上级
- 超过1小时争论，直接"保留意见，继续推进"
- 超过1周没进展，直接换方案或换人
有次做一个项目，我们需要依赖另一个团队提供接口。
那个团队的负责人特别难搞：
- 第一次开会："我们的接口还没设计好，再等等"
- 第二次开会："下周肯定能好"
- 第三次开会："再给我们一个月"
我等了两个月，项目进度被拖死了。
后来我学乖了，直接定了熔断规则：
- 依赖接口如果1周内不能联调，直接切换到开源方案
- 超过3次协调会搞不定，直接escalate到部门总监
- 如果对方团队不配合，我们自己做降级方案
那次之后，项目进度反而快了。
别在烂人烂事上耗着，你的时间更值钱。
协议4：输出兜底——别让系统的Bug炸掉你的业务
应用场景：依赖他人交付、关键路径协作
以前我特别相信"承诺"。
"这个功能下周一定搞定。"——产品经理信誓旦旦。
结果呢？下周没搞定，下下周也没搞定，我的上线计划全被打乱。
后来我学乖了，我不信承诺，我只信"兜底方案"。
- 如果他没按时交付，我的Plan B是什么？
- 如果这个功能砍掉，我的核心逻辑还能跑吗？
- 如果他离职了，这个模块谁来接？
永远给自己留一条退路。
有次做一个高并发项目。
我们的架构设计里有两条兜底链路：
链路1（正常）： 实时计算服务 → 准确但依赖复杂
链路2（兜底）： 本地缓存 → 5秒过期，可能不准但绝对不会挂
结果上线那天，实时服务真的挂了。
但因为我们有兜底链路，用户看到的是"暂时不可用"，而不是"系统错误"。
那次之后，我再也不会相信"绝对可靠"的承诺了。
系统设计里有"冗余备份"，职场里也得有。
最后说句实在话
把同事看成Agent，不是为了"冷漠"，而是为了"省心"。
你不用再纠结"他为什么这样"，你只需要知道"怎么跟他合作"。
这不是"职场厚黑学"，这是"系统稳定性工程"。
同事不是你的敌人，也不是你的朋友，他是你系统里的一个"外部依赖"。
你的目标，是让这个"外部依赖"稳定运行，而不是试图"改造它"。
你控制不了别人，你只能控制自己的"输入输出协议"。
⚠️ 这个框架适合你吗？
最后说点实在话，这篇文章不是让你把所有人都当成冷冰冰的"黑盒"。
"把同事看成Agent"是个思维工具，不是操作手册。
它适合这些场景：
✅ 跨部门协作：你们本来就没感情基础，用规则代替扯皮
✅ 短期任务：快速交付，不必深度投入情感成本
✅ 关键依赖方：你不能承受他的不确定性，得有熔断和兜底
但它不适合这些场景：
❌ 你的直属团队：长期合作需要信任，不是所有事都能靠规则
❌ 你的上级：你无法"黑盒化"他，只能理解他的诉求和约束
❌ 创新工作：恐惧会扼杀创造力，心理安全感比规则更重要
记住一句话：对陌生人用规则，对熟人用心思。
别把所有人都当成"要防范的Agent"，那样你会活得很累。
这个框架的价值，不是让你变成冷冰冰的规则机器，而是让你在"该用规则的地方用规则，该用心思的地方用心思"。
接下来一周，试着做三件事
- 给3个同事分类，写下他们各自的"输入输出规则"——什么情况下找他们，怎么跟他们沟通，预期什么结果
- 找出一个"总让你内耗"的同事，设计一个"输入校验协议"——把口头承诺变成书面文档，把模糊需求变成明确指标
- 给自己的工作加一个"超时熔断"——什么事"最多尝试3次"，什么情况"直接escalate"，什么场景"换方案不纠结"
别再试图"理解"同事，开始"使用"同事。
你会发现，职场突然变得简单了。
可执行抓手
- 本周内：给3个同事分类，写下他们各自的"输入输出规则"
- 明天就开始：找出一个"总让你内耗"的同事，设计一个"输入校验协议"
- 本周末前：给自己的工作加一个"超时熔断"
- 记住：同事不是"应该知道"的Agent，他是"需要明确输入"的黑盒系统——别说"你应该知道"，直接写清楚
- 最重要：对陌生人用规则，对熟人用心思——别把所有人都当成"要防范的Agent"