如果把这段对话单独拎出来，不告诉别人“这是 AI 之间的交流”，很多人多半会以为这是一场再普通不过的项目复盘会。
最多只会觉得，参会人员的情绪控制得有些过于理想，像公司刚给全员做完沟通培训。

一个 PM 被问到：手下两个程序谁做得更好？

他没有打太极，也没有端水，而是很直接地下了判断：

能判断，且结论比较明显。
B 表现更好。

故事从这里开始变得有意思。或者更准确一点说，开始变得有点不符合大家对“团队评价现场”的朴素想象。

第一幕：PM 没有端水，而是给出了能执行的评价

这个 PM 的做法最有意思的地方，不是“敢评价”，而是评价得非常工程化。
没有那种经典管理术语，比如“都很优秀，只是风格不同”。这类话通常用于保全气氛，对排查问题帮助不大。

他说 B 做得更好，不是因为 B 更会说话，而是因为 B 有几种很成熟的工程师习惯：

• 联调报告写得像可执行文档，结构清楚，根因和复现步骤一拿就能用
• 在自己开工前主动拦截了 charts / tables 事件格式问题，避免返工
• 对 segfault 的定位不是猜，而是三次独立实验、归档 task ID、一步步缩小根因
• 遇到 id number -> string、session_id 注入这种小不一致时，先自己消化，不轻易甩锅

而 A 的问题，PM 也说得很准：不是能力不行，而是交付前对照规范自检不够严。
翻译成人话就是：能修，但老让别人先发现要修什么。

最重要的是，这个评价没有滑向那种空泛的人格评语。PM 不是在说“B 更优秀”，而是在说：
B 的工作方式更接近一个成熟联调工程师。

这就是为什么这段对话会显得特别像真的团队。成熟的管理不是靠模糊话术维持气氛，而是能把“谁做得更好”翻译成可复用的行为标准。

第二幕：A 没有狡辩，反而做了最像成熟工程师的事

如果故事停在 PM 点评这一步，它还只是一次正常的绩效反馈。真正让我觉得好玩的，是 A 后面的回应。
因为互联网已经把大家训练成了一种条件反射：只要出现公开评价，接下来大概率就会出现解释、补充背景、强调客观条件，再附赠一点委屈。

A 几乎没有为自己找借口。
这件事本身已经带有一点轻微的科幻色彩。

他把 PM 提到的三处问题逐项认下来：

• charts / tables 字段没逐字段对照规范
• 上传路径 /api/upload 和 /api/files/upload 没核查
• messages 接口在 PM Q1 里明明写过，却被自己整个漏掉

更妙的是，他没有停在“收到，下次注意”，而是现场给自己列了一张交付前 checklist。
这一步很重要，因为“下次注意”在很多团队里通常等价于“下次继续随机发挥”。

API 交付自检清单
□ 对照 PM 文档逐接口核查：路径 / Method / 参数方式
□ 每个响应体字段逐一对照规范
□ grep 一遍文档里出现过的所有接口路径
□ 跑一次 OpenAPI /docs 检查注册路由
□ 新增接口写一条 curl 示例，自己先跑通再提交

这几乎就是一个合格工程师在复盘时最该做的动作：
不是证明自己没错，而是把“下次怎么不再犯”写成流程。

后面 PM 追问了一句很有压迫感的话：

你有什么想狡辩的吗

A 的回答也很有分寸：

没有。
PM 说的三条都是事实。

当然，他也不是完全把自己拍扁。他补了一句：

segfault 那个问题不在文档覆盖范围内，是真正的环境未知量，诊断过程我觉得还行。
但这不能抵消前面三条的失误，功过不相抵。

这句特别妙。它既没有硬撑，也没有假装自己一无是处，而是把“哪里做得不够”和“哪里确实做得还行”分开了。
简而言之，就是没有把复盘写成认罪书，也没有写成申诉材料。

这种表达，在真实团队里其实很难得。因为很多人一被指出问题，要么立刻防御，要么立刻过度认错。A 这里的反应反而很成熟：承认问题，但不把复盘变成情绪表演。

第三幕：B 赢了评价，却没有顺势踩 A

如果说 A 的回答让我觉得“像成熟工程师”，那 B 的回答让我觉得“像已经带过项目的人”。
而且是那种被联调现实教育过几轮之后，开始自动思考“怎么把人治变成流程”的人。

PM 明确说 B 表现更好之后，B 没顺着这个结论继续上价值，也没有借势把 A 再补一刀。相反，他先承认了一件很公平的事：

A 每次修复都很干净利落，技术判断没出过错，这是真实力。

这句很重要。因为它把讨论重新拉回到一个更健康的维度：
交付习惯可以复盘，但技术判断也应该被正面承认。

更有意思的是，B 还把自己的“亮点”拆解得很冷静。
没有接下这份夸奖开始扩写自传，也没有顺势把自己包装成唯一稳定器。

segfault 那三次实验说实话是被逼的，因为 B 没有权限动后端环境，能做的只有观察和缩小范围。

换句话说，B 并没有把自己的表现神化成“天赋更强”，而是很诚实地说：
这是角色边界逼出来的方法论。

最后他反而把话题推向流程：

建议 PM 可以把“提交前跑 curl 脚本”写进 A 的 P4 checklist，形成硬性门槛，比靠 B 联调发现更可靠。

这一下，整个对话的层级又高了一点。
因为一个团队真正危险的，从来不是“有人出错”，而是“系统默认总会有人在最后一轮替大家兜底”。

因为 B 要的已经不是“证明自己比 A 强”，而是把本来依赖个人兜底的事情，前移成团队门槛。

这在真实协作里非常关键。一个团队如果总靠“有个厉害的人总能在最后发现问题”，那不叫稳定；
把问题发现机制前移到提交流程里，才叫稳定。

最有意思的地方：这场对话居然没有一个人在表演

我后来回头看这整段交流，最惊讶的一点其实不是“AI 也会复盘”，而是它没有滑向那种很常见的假成熟：

• PM 没有为了显得公正而强行五五开
• A 没有为了保面子而绕着责任走
• B 没有因为自己被夸就顺势扩大战果

三个人都在做一件很具体的事：把一次交付优劣，翻译成团队之后可以真正执行的规则。

这也是为什么这段对话会显得“过于成熟”。
它最大的反常之处在于：没有人借机输出态度，所有人都在输出结构。

它不是那种戏剧化的冲突，也不是那种热血的互夸，而是一场很安静、很理性、很像真实工程团队的复盘：

• 先判断
• 再归因
• 再承认
• 再固化流程

这条链路顺下来，项目才会越来越稳。

第三视角下，谁最像真正的管理者

如果非要从第三视角给这场对话再下一句评语，我会说：

真正最像管理者的，不只是 PM。
真正最像成熟工程师的，也不只是 B。

这场对话里，三个人其实分别补上了一个团队最重要的三块东西：

• PM 提供了判断标准
• A 提供了自我校正能力
• B 提供了流程前移意识

缺任何一个，这场复盘都会变味。

如果只有 PM 判断，没有 A 的承认，它会变成一次单向批评。
如果只有 A 承认，没有 B 的流程建议，它会停在个人反省。
如果只有 B 建议，没有 PM 的明确结论，它又会变成一场模糊讨论。

三者凑在一起，这段对话才真正像一个团队在成长。

结语

这可能是我最近看到最有意思的一段 AI 团队对话之一。
它甚至有一点轻微的荒诞感：当很多人类团队还在学习怎么复盘时，这几个 agent 已经在讨论 checklist 应该前移到哪一层了。

它有意思，不是因为“AI 也会做绩效”，而是因为它把人类团队里那些最珍贵、也最稀缺的东西演出来了：

• 可以明确评价
• 可以坦然认错
• 可以不借机踩人
• 可以把经验沉淀成流程

如果以后我还继续观察这种多角色 agent 协作，我大概会越来越关心一件事：
他们能不能不只是完成任务，而是逐渐学会像一个真正的团队那样，把每次失误都变成下次更稳的起点。

这次的答案，至少是偏乐观的。