实习生“听多了反而更乱”——服务端开发的自救方法论

做服务端的人，最怕的其实不是写代码。

而是你已经解释到口干舌燥，对方转头对外同步时依然能做到：

指鹿为马，南辕北辙。

最近我就遇到了一次特别典型的场景：

我以为自己讲得很清楚，
结果第二天对齐时，认知完全跑偏，甚至还变成了：

“这是 XX 让我这么做的。”

那一刻，说不尴尬是假的。

所以这篇文章我想从自己的视角出发，记录一次真实的带教事故，也顺便总结一套服务端人常用的“自救方法论”。

背景：MCP 工具能力的落地

公司最近需要在现有业务模块中，补齐 MCP 工具调用能力。

简单来说，就是要让业务服务具备：

• 工具注册
• 权限校验
• Agent 调用
• 统一执行链路

上周六我基于八一菜刀大佬的开源项目 Knife4j 做了一个 POC，实现了基础的调用骨架。

后续需要补齐 Agent 调用侧的完整闭环，这部分交给实习生小W同学继续推进。

服务交互流程（POC版本）

整体调用链路大致如下：

这个流程本身并不复杂，但对于实习生来说，真正难的往往不是“怎么写代码”，而是：

为什么系统要这么设计？
哪些边界不能碰？
哪些东西看起来能做，其实不能做？

核心疑惑点：权限与工具边界

在 MCP 工具接入过程中，第一个绕不开的问题就是：

Token 到底在这里扮演什么角色？

权限校验是工具调用链路的第一道门槛。

这里其实牵扯到一整套“信任迁移”的演进：

• 最早的 Cookie
• 后来的 Session
• 再到 JWT Token
• 以及 Sa-Token 这种工程化封装

这些东西我当时一口气全讲了。

讲得很爽，也很细。

但现在回头看：

信息密度太高，对实习生来说反而是一种负担。

事故：讲太多导致信息过载，对外沟通失真

问题发生在一次很典型的场景。

实习生提出了一个“看起来很聪明”的实现想法。

我担心他走偏，于是花了一个多小时逐条解释：

• 为什么不行
• 风险在哪
• 系统边界是什么
• 推荐的替代方案是什么

当时我以为自己讲得足够清楚。

结果第二天，他去和另一个同事对齐时，认知完全跑偏。

甚至对方转述成：

“这是 XX 让我这么做的。”

那一刻我非常尴尬。

后来我意识到：

这不是他“笨”，而是我把“知识密度”拉满了，却没有做“理解闭环”。

写在最后：讲解不是交付，闭环才是交付

带实习生最大的挑战，从来不是技术难度。

而是：

你以为你讲清楚了，
但他其实只是“听过了”。

从那天之后我才真正意识到：

讲解不是交付，闭环才是交付。

下一次我会更克制：

• 少讲一点原理
• 多做一点确认
• 让对方先复述，再去执行
• 对外同步前先过一遍 summary

因为带人这件事，本质上不是“输出知识”，而是“交付理解”。