带初级开发者：先分清卡在哪，再决定帮多少

键盘就在你手边。一个初级开发者花了半天没定位的问题，你看两眼就大概知道问题在哪一行。这时有两种做法：把手伸过去，十分钟收工；或者坐下来，让他继续操作，你只负责问「你觉得是哪一步出的问题」。

选第一个很合理，任务确实推进了。但如果每次求助最后都变成你动手，对方学到的是「下次还找他」，而不是「下次我自己能看什么」。反过来也不对：把「你试过什么」当成准入考试，非要人先挣扎二十分钟才肯看一眼，同样是在消耗人。

Dev Leader 上 Nick Cosentino 的这篇文章讲的正是这段即时对话：有人拿着眼前的任务来求助，你可以给多少帮助。原文明确说，这不是培训计划，也不是「初级工程师必须先自己查完才能来问」的规定。

核心判断可以压成一句话：求助不是「给不给答案」的二选一，而是先分清卡点类型，再选择帮助方式，最后确认对方能自己接上下一步。

第一步：先分清「我卡住了」是哪一种

「我卡住了」主要有三种不同的意思，处理方式完全不同：

这三种不能互换。给建议之前先听清对方卡在哪一层。你不需要一份完整汇报，一段粗糙的口头解释就够——前提是你真的在听，而不是等他讲完好宣布你的方案。

四个能把求助问得更具体的问题：

• 你想让它发生什么？
• 现在实际发生的是什么？
• 此刻到底是哪一部分不清楚？
• 你需要的是背景信息、另一个视角，还是有人陪你一起推？

这四句不是面试脚本。对方已经把情况说清楚，就别让他为了配合你的流程再复述一遍。挑那句会真的改变你理解的问题问。

原文举了一个明确标注为假设的例子：一位开发者在做「控制用户是否收到通知」的设置，说这个行为他怎么也调不对。你以为他正在调试查询设置的代码，其实他不确定这个设置该影响已经发出的通知，还是只影响之后的。这时再聪明的调试建议都没用在点上。

真正有用的帮助是先确认预期行为。你可能知道答案，也可能需要把他介绍给负责拍板的人。无论哪种，这次求助都不是「他不够坚持」的证据。

目标不清楚时，先澄清，别让他试错

「先问对方试过什么」在目标明确、值得排查的时候很有用；在对方根本不知道什么叫成功的时候，几乎没用。

不要让初级开发者靠试错去猜一个他并不拥有的产品决策。预期模糊时马上澄清。需求问题不该靠先浪费一轮努力来换取你的回答。

这些是对话里的临时判断，不是给人的永久标签。同一个人可能这一刻需要立刻澄清，拿到答案之后完全可以自己往下查。

澄清要说具体。「做得一致一点」在你听来很明确，在对方听来是猜谜：跟哪个已有行为一致？给一条具体需求或一个例子，比一句形容词有用。

不确定就说不确定。两种理解都讲得通时，承认这个模糊，别把自己的偏好说成事实。带人不等于你对所有产品和技术决策都有解释权。

澄清完别急着往下走。花半分钟让对方用自己的话复述目标——不是要求他背你的原话，而是确认你们现在说的是同一件事，再让他继续投入时间。

第二步：目标清楚之后，问尝试，再选帮助方式

目标大致清楚以后，再问对方试过什么。目的是看他的思路，不是统计他痛苦了多久。

「你试过什么，它告诉你什么？」比「你卡了多久」信息量大得多。前者能暴露一个有价值的观察、一个该验证的假设，或者一个他不知道存在的步骤；后者基本只说明时间过去了。

原文另一个假设例子：开发者说他改了一个条件，测试还是失败。你可以直接告诉他去改另一个条件，也可以先问「你原本以为这次改动会影响什么？失败的表现有没有变化？」这段对话可能揭出真正的解释——他改的那段代码根本没被跑到。

值得追问的四个细节：

• 这次尝试他预期看到什么
• 实际看到了什么
• 中间那个假设是什么
• 他接下来想到、但不知道该怎么验证的是什么

不必要求每次求助都补齐这四项。初级开发者常常还不知道哪些证据算证据，帮他把一次尝试说清楚，你们两个人对证据的理解也会一起变清楚。

如果他什么都没试，先弄清为什么。缺权限、工具不熟、预期不明，需要的回应各不相同；而一个其实理解了任务、只想在安全改动前先确认一下的人，需要的是另一种回应。你可以鼓励他去试，但不必靠扣着信息来鼓励。

语气在这里很关键。「你把现在的结果给我看看，我们一起判断下一步」是合作；「你真正试过了再来找我」把对话变成了资格审查。原文顺带提过一句：工程里的软技能，在这类看似纯技术的问题上同样生效。

也可以在不假装结果正确的前提下肯定推理过程。「你查这里很合理，因为失败正好是那次改动之后开始的」是具体反馈，它把「这次排查有没有价值」和「猜没猜对」分开了。

选哪种帮助方式，看缺的是哪一块

没有任何规则说导师不能给答案。不同处境需要不同量的帮助，而且可以在一次对话里换好几次。

提问适合已经有足够上下文、只是缺一个视角的人；指方向适合手里有零件但不知道怎么拼的人；直接解释适合缺一条具体信息的人；演示适合缺一个没见过的手法的人。

不必声明自己正在用哪一类。只需要留意：这一种帮助此刻是否有用。

拿一个他不熟的调试工具举例：你可以演示怎么查看一个值，解释为什么选这个位置，然后让他去查看下一个相关的值。演示给的是必要知识，交还给他的是应用机会。

如果你亲手改了东西，说清为什么：基于什么假设、打算怎么验证。别让速度盖掉推理，尤其是对方来求助的目的本来就是想弄懂，而不只是被解锁。

也有必须直接介入的时候：风险高、时间紧。这时要说明你是在处理眼前这件事，不是在给以后所有求助立默认模式。需要补充解释就承认这一点，别声称看一次快速修复就学到了所有该学的东西。

键盘留在他手上

一起排查时，只要说得通，就让对方控制操作：导航、改代码、跑检查、解释看到的现象。你的角色是补推理，不是坐在旁边解说、手却一直在动。

这不等于你在旁边沉默。「可以看看那里」「这个概念是这样的」，或者指出一个他漏掉的观察，都是帮助。关键问题是：他是否理解下一个动作、以及为什么要做这个动作。

原文给的一段假设对话：

开发者：我觉得这个值在某处被覆盖了。 导师：如果真是这样，我们应该看到什么？ 开发者：原来那个值是对的，但它在返回响应之前被改掉了。 导师：好。这两点你打算在哪里验证？

这不是说每个开发者都会给出这么整齐的回答。它演示的是把「选哪个检查点」的决定留在对方手里。如果他不知道怎么查看这个值，那就补这个技术动作，而不是把同一个问题再问一遍。

跑完之后还要问一句：「你觉得这个结果说明什么？」一次成功的检查同样可能没让人理解原因；一次失败的假设也不等于这次带人失败——只要他能说清这次排除了什么、为什么另一个可能性现在更可信。

遥控式指导是这里最容易犯的错：每句话都是「点这里、打开那个、把这行改了」。手是他放在键盘上的，决策却是你做的。该停的时候停下来，让他把动作和问题连起来。

第三步：收尾，让他说出下一步

不必一起把整个任务做完，这次帮助也可能有用。一个合理的终点可以是：需求澄清了、他拿到一个能自己验证的假设、或者学会了一个能自己用的手法。

分开前确认接下来发生什么。问「你接下来打算试什么，这能告诉你什么」通常能暴露剩下的不确定。如果他只能复述你的指令，就换一种说法把目的再讲一遍。

常见的四种收尾结果：

1. 他能自己继续排查下一个可能。
2. 他需要另一个人给一个明确答复。
3. 他能把演示过的手法用到剩下的情况上。
4. 你们发现有一个决策必须先澄清，实现才能继续。

这四种都不要求他假装已经毫无障碍。把未解决的依赖说清楚，比一句双方都不信的「懂了」更有价值。

当这套判断开始不奏效

越问越糊涂。 提问能让有上下文的人理清思路，也能让缺上下文的人更混乱。如果对方越问越乱，先换做法：给背景、把问题问窄，或者干脆演示一遍。也可以直接问「我这段解释哪里没接上」。更多提问不等于更好的帮助，对方一脸困惑也不说明他不努力。

一直来问。 求助次数本身说明不了原因。可能是几个不同领域都不熟，也可能是之前的解释没接上，还可能确实是依赖问题。先看请求内容，再下判断。

一群人同一类概念都缺课。 如果对话暴露出的是一群开发者在同一个概念上都缺课，那属于另一个问题：要给多人补课，而不是把眼前这次求助改造成课程。

下次他拿着问题过来

三步不必每次走满。卡点一眼就能看清的时候，直接进第三步确认交接就行。

1. 先听清卡点类型。目标不清就先澄清，或找人拍板，别让他盲试。
2. 目标清楚再问尝试，用「你试过什么，它告诉你什么」，然后挑一种帮助方式。
3. 收尾问「你接下来试什么、能验证什么」。

如果只能多问一句，就问收尾那一句。他答得出来，这次帮忙才算交接完成；答不出来，就换一种讲法再补一次。

如果你也在带初级开发者，Aide Hub 会继续写软件工程实践、开发工具和 AI 助手的落地经验。

参考

• How to Help Junior Developers Without Doing Their Work — 原文，Nick Cosentino，Dev Leader。
• Listen First, The Human Sounding Board — 原文在「先听懂对方的困难」一句处引用。
• Software Engineering Soft Skills: 6 Focus Areas That You Need — 原文在「工程中的沟通能力」一句处引用。
• Informal Leadership In Software Engineering: What You Need To Progress — 原文在「非正式领导力」一句处引用。
• These Junior Developers Suck, They Just Don’t Understand My Code — 原文在「如何理解初级开发者看不懂代码」一句处引用。