题目重点：把辅导从替人写代码扩展到诊断能力差距、分级授权、反馈与可持续独立交付。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 只使用本人真实经历；本文场景为虚构练习，不应替换成自己的履历事实。
- 团队规模、结果数值、决策权和时序必须可解释；没有实际测量就说明证据局限。
- 回答先给约两分钟主线，再按追问展开；职级和团队会改变所需影响范围。
解题路线
- 选一个具体人和具体能力目标，例如能够独立拆任务、排查故障或做设计，而不只说“我回答过很多问题”。说明你与对方的关系和能投入的时间。
- 先诊断原因：知识缺口、系统背景、任务不清、缺反馈或缺机会。自己觉得代码不够好不一定是对方能力不足，也可能是文档与设计标准缺失。
- 制定逐级授权：一起做一次、对方主导你review、对方独立做你只看关键决策。每阶段用可观察标准验收，不把“我不再管”当作授权成功。
- 反馈针对行为和证据，分清必须修的风险与可自行选择的实现。给出理由和一次改进机会，不在公开review里靠否定建立权威。
- 结果包括对方能独立完成何种决定、返工/求助方式如何变化、是否能指导下一位同事。晋升或项目上线由很多因素共同造成，不把它全部归功于自己。
- 说明辅导中自己需要改变的部分，例如过早接手、解释太快、把个人偏好当规范。若辅导未成功，要说怎样调整目标或承认时间不足。
- 对Staff岗位可加机制复用：模板、pairing轮值、风险review标准。但先讲人的真实变化，不能只展示一套培训材料证明完成了mentoring。
手动走一遍
练习场景：同事每次告警都找你直接修。你先让其记录假设和观测，陪做两次诊断，再让其主导一次有回滚保护的处理，复盘只纠正关键缺口。后续其能独立定位相似故障；如果没有数据，举具体事件变化，不编造效率提升百分比。
规模与取舍
准备一条能力变化主线及每阶段证据，材料与review次数是投入，独立判断/交付变化是结果，两者不能混作指标。
易错点与追问
容易失分的边界
- 替人完成任务却称为培养。
- 只提对方晋升没有自己的行动。
- 把反馈写成个人好恶。
- 把独立负责等同于撤掉所有支持。
继续深挖
- 对方最初不接受反馈怎么办？
- 怎样判断可以继续放权？
- 你为辅导投入牺牲了什么？
- 如果辅导长期没有进展呢？
