最近因为帮团队招一些人，我又想起两篇很久以前看过的文章。它们其实都是很多年前读过的，只是最近确实在招聘，才重新把里面的话想了一遍：找到合适的人，补足我负责这一块的短板，团队才有机会做更专业、更有挑战的事情。
我现在做的事情更具体一些：一边在 GPU 故障、研发效能和基础设施组件这些方向上持续做事，一边帮助团队寻找合适的人，补足能力上的缺口。
在这一块，我会参与技术方向讨论、方案评审、故障分析和经验传递，在关键问题上给出建议；同时也在继续探索未来 AI Infra 可能会是什么样子，以及我们需要提前积累什么能力。
以前我会觉得，招人就是把岗位发出去、筛简历、约面试。后来自己真正参与进去，才发现招聘其实和做系统有点像：先要知道缺的是什么，再找到能够补上这块能力的人。岗位描述写得再漂亮，如果没有说清楚问题和边界，最后招来的也可能不是团队真正需要的人。
两篇文章，最近又想起来了
一篇讲怎么带团队，一篇讲怎么花两年时间观察一个候选人。放在一起看，居然都在讲同一件事：
目标得先说清楚，然后让人在真实的事情里慢慢暴露能力。
这句话放在招聘里，就是先说清楚团队现在缺什么、要解决什么问题；放到实际指导和协作里，就是把问题、边界和判断依据讲清楚，然后让真正负责的人继续往下做。
我现在做的是领域指导
我现在做的几件事看起来有点分散，但都围绕同一个问题：如何把 GPU 故障里的经验，变成可复用的工程能力，再让团队更快交付，最后为 AI Infra 的探索留下真实依据。
GPU 故障：把问题定位清楚，并且让它少发生
GPU 故障是我目前最具体、也最贴近线上问题的一块工作。
这里关注的是故障发现、现象归类、根因定位、恢复处理和后续治理。一次故障处理完以后，还要继续追问：为什么没有更早发现？能不能自动诊断？能不能减少人工操作？同类问题再次出现时，能不能让下一个人更快处理？
GPU 故障是问题本身。如果一个问题反复出现，我会继续想：能不能把排查经验做成监控、诊断工具，或者一个可以复用的基础设施组件。
基础设施组件：把通用能力做成可靠的组件
基础设施组件是解决问题的工程载体。
这里关注组件的设计、选型、接入、稳定性、可观测性、升级和故障处理。一个组件能跑起来只是开始，还要考虑谁来用、出了问题怎么定位、怎么回滚、能不能被其他系统复用。
我关心的是和 GPU 故障、基础设施运行以及 AI Infra 直接相关的通用能力，比如监控、诊断、调度、自动化和服务接入。具体业务系统、供应商侧运维和其他团队自己的组件，还是由各自的 owner 负责，我不会把所有基础设施都揽到自己身上。
研发效能：减少重复劳动，让交付过程更顺畅
研发效能关注的是：一个问题从发现、定位到修复、上线，能不能少一些等待、重复劳动和信息丢失。
它可能包括问题流转、研发流程、发布协作、信息沉淀、工具建设和反馈机制。目标是让研发、运维和相关协作方更容易看到状态、暴露风险、完成交付。
这里说的研发效能，主要是让问题和信息流动得更顺。能自动化的事情就自动化，必须保留的流程也要说清楚到底解决什么问题。它不是给人增加 KPI，也不是为了看起来规范而增加流程。
未来 AI Infra：探索还没有完全确定的方向
未来 AI Infra 更像是探索性工作。
需要关注新的计算资源形态、训练和推理基础设施、调度方式，以及这些变化会带来哪些新的可靠性问题。这里不一定一开始就有明确需求，可能要通过调研、实验、原型和小规模验证，逐渐判断哪些方向值得投入。
现在的基础设施组件，要先把已经出现的问题解决稳定；未来 AI Infra 面对的，往往是还没有完全成形的问题，需要先做实验，再决定要不要继续投入。
简单说，GPU 故障告诉我哪里出了问题，基础设施组件把解决办法留下来，研发效能让这套办法更快落地，AI Infra 探索则是从这些真实问题里找下一步方向。
在这几块里，我能做的主要是参与技术讨论、拆问题、看方案、传经验，并在关键问题上给出建议。具体项目还是由对应负责人和 owner 推进。
我不负责替别人把所有决定都做完，也不应该把一起做事的人变成只等答案的人。更好的状态是，我把问题讲清楚，把自己知道的东西补上，然后让真正负责的人自己继续往下做。
如果一个人每遇到问题都来问我“下一步该敲什么命令”，那可能说明我并没有真正帮到他。指导的目标，应该是让他下一次遇到类似问题时，知道该看什么、怎么验证、什么时候需要求助。
上面说的是我关注的领域关系。具体到一起做事，我更在意的是下面这些事情。
先别急着开干，边界和验收标准得先讲明白
我自己做项目时，最怕的就是大家一上来就开干，做到一半才发现每个人理解的“完成”都不一样。所以如果有人来和我一起做一个重要项目，我会先把目标、边界、方案、风险和验收标准聊清楚（最近刚接的一个需求，让我先短暂划掉这段，等我以后完整践行之后，再回来打开！）。
方向对齐以后，执行过程尽量让真正负责的人自己做决定。遇到技术问题，我可以一起分析；遇到信息不对称，我尽量把上下文补齐；项目结束以后，再一起复盘，看看哪些地方做得好，哪些地方下次可以更早发现。
我把它总结成一句话：
事前对齐，事中支持，事后复盘。
我越来越觉得，培训很难替代真实项目。真正能看出一个人有没有成长，往往是他负责过一次 GPU 故障、推进过一次跨团队改造，或者在没人告诉他答案的时候，能不能把问题继续往下挖。
在实际一起做事时，我更关心几件事：
- 让一起做事的人负责真实的技术改造或工程项目；
- 大项目先做设计，再做评审；
- 重要变更坚持代码评审和必要的验证；
- 鼓励大家记录问题、分享经验和复盘过程；
- 把反复出现的故障和流程问题，想办法变成工具或自动化。
项目做完以后，至少应该留下代码、文档、工具，或者一套更清楚的判断方式。这样下一次遇到类似问题时，就不用从头再来。
我更愿意和主动把问题接走的人一起做事
我比较愿意和这样的人一起做事：问题还没有完全定义清楚，他已经开始补日志、找上下游、问相关的人；事情结束以后，他还会顺手把文档和自动化补上。
当然，我不会要求每个人一开始就知道所有答案。但我希望他在不知道的时候能主动说出来，并且愿意把问题继续往下推进。
有些问题确实不在你的职责范围内。但你可以告诉我：问题在哪里、谁应该负责、现在卡在哪里、你能不能帮忙把它推给正确的人。把问题甩出去，和把问题交给正确的人处理，中间差别挺大的。
我也不希望这些问题永远只依赖某个“最懂的人”。如果所有问题最后都只能回到同一个人身上，那说明知识没有流动起来。
更好的状态是：有人在关键问题上有经验，也愿意把经验讲出来；刚开始接触的人能够逐渐接过一部分问题，最后不需要每一步都等别人带着走。
每个人的成长路径都不一样
我现在也没有一套特别成熟的成长模型。毕竟我自己也是被一个个项目推着往前走的，很多时候并不是提前规划好“这半年要成为谁”，而是先把眼前的问题做好，然后慢慢发现自己更擅长、也更愿意承担什么。
有人希望成为技术专家，有人希望承担项目，有人希望更多地和业务沟通，也有人暂时只想把手上的事情做扎实。我不会用同一套路径要求所有人。
但这不等于降低要求。我们还是需要一起把下一步说具体：
- 你接下来要独立解决哪一类问题？
- 你需要补上哪项能力？
- 什么时候可以从执行者变成负责人？
- 你能不能把经验沉淀成文档、工具或分享？
如果有机会持续一起做事，我希望沟通不只是汇报，也能聊聊这些问题。
上面这些对一起做事的期待，也会直接影响我怎么帮团队找人。
说说我现在想帮团队找什么样的人
先说现在的情况：我目前主要帮助团队找 AI Infra、GPU 集群、平台工程和故障自动化方向的人。
我想做这件事，是因为自己负责和持续投入的这些方向，确实还有一些能力短板。一个人可以把很多事情扛起来，但不可能永远同时把 GPU 故障、研发效能、基础设施组件和未来 AI Infra 都做到足够深。与其继续一个人硬扛，不如把缺的能力说清楚，找到专业的人一起做。
无论是 GPU 故障、平台组件还是故障自动化，这类工作都不太像“来了以后只写某个模块”。更多时候，你会从一个模糊的故障现场开始，把问题定位、修掉，再想办法让它以后自动发现、自动处理，或者至少让下一个人更容易接手。
我想找的不是一张写满技术关键词的简历，而是能够一起把复杂问题做成系统的人。
我也不打算找一个什么都会的人。更现实的是，先把团队最缺的那一块说清楚，找一个能在主方向上做深、又愿意理解上下游的人。
能从证据开始排查问题
遇到问题时，先看日志、指标、链路和复现条件，愿意先验证再下结论。
我很喜欢那种会问“现在有什么证据”“下一步实验能排除什么”的人。猜测当然可以有，但不能一直停留在猜测里。
能把一次问题变成长期能力
修完故障以后，会顺手想一想监控、自动化、文档和流程，而不是只把告警关掉。
如果同一个问题每周都要人工处理一次，那大概率说明我们还没有真正解决它。
能把复杂事情讲清楚并推动完成
基础设施工作很少是一个人关起门来完成的。你需要和研发、运维、产品、供应商以及其他人合作。
我希望你能把复杂技术问题说给不同的人听，也能把决策、风险和边界写下来。事情卡住时，知道什么时候同步、什么时候升级、什么时候自己继续往下挖。
我现在还没有一套神奇的面试体系
我现在还没有一套特别成熟的面试题库，也不相信一次面试就能把一个人看明白。我的想法是先把岗位需要解决的问题写清楚，再围绕候选人真正做过的项目多问几层。
首先，岗位要求要写成具体结果，而不是“精通某某技术”“有多年经验”。比如，加入团队以后，能不能独立完成某类 GPU 故障排查，能不能写清楚基础设施组件的设计方案，能不能和相关的人推进一次完整上线。
其次，我会深入追问候选人做过的项目：当时的问题是什么，具体负责哪一部分，遇到什么困难，为什么做出某个决定，最后结果如何。简历只负责提供线索，项目细节才真正提供信息。
我也会安排一个时间合理的小任务，看看问题拆解、验证方式、文档表达和接受反馈的能力。面试是为了互相了解，不是让候选人免费替公司做一周项目。
书单、博客、GitHub 或开源贡献也可以作为长期信号。我不会把它们当成唯一门槛，但会关注一个人是否持续学习、是否认真做过东西、是否能在公开协作中留下可靠记录。
真正的判断也会发生在录用和实际合作以后：刚开始能不能把环境和问题跑起来，过一段时间能不能独立接一类事情，再往后能不能主动推动一次改进。这个过程对团队和候选人双方都公平。
我能在招聘里做什么
我不负责替团队拍板，但我可以把领域问题讲清楚，把岗位需要解决的技术问题拆开，参与候选人的项目追问和技术判断。
我也不敢保证每个项目都轻松，也不能保证每次判断都正确。但我可以保证，岗位背景和技术上下文会尽量讲清楚，遇到专业问题会一起分析，做得好的地方会说，做得不好的地方也会直接说。
我能补上的，大概是这些：
- 足够的上下文，而不是只丢给候选人一个任务标题；
- 对 GPU 故障、研发效能和基础设施组件问题的真实讨论；
- 对方案、项目经历和排障过程的具体反馈；
- 帮忙找到正确的协作对象和信息来源；
- 让专业的人进来以后，能够逐渐负责更大的问题。
相应地，我也会期待候选人对结果负责，主动暴露问题，认真对待质量，并且愿意把自己的经验讲给别人听。
写在最后
至少现在，我是在一个领域里持续做事，同时帮助团队找到能够补足短板的人。
这些事情都还在往前发展，靠一个人硬扛很难真正做深。找到专业的人一起做，才有机会把短板补上，把价值做大。
先把这几条记下来，等真正帮助团队招到更多人、一起做过几个项目、踩过几个坑，再回来看看哪些还成立。
但目前我比较认同的是：
把问题和短板讲清楚，找到专业的人，一起把真实的问题做深，做出更大的价值。
这就是我现在想尝试的工作方式。
如果你正好在做 AI Infra、GPU 集群、平台工程或故障自动化，也可以来聊聊。简历不用写得特别漂亮，我更想知道你最近到底解决过什么问题。
最后放一下最近重新想起的两篇文章。它们其实都是很多年前看过的，只是最近因为帮团队招人，才又想了一遍：
- 一点团队管理心得：里面关于授权、梯队和 Tiger Team 的部分比较有启发。
- 很好的文章《怎样花两年时间去面试一个人》：它让我重新思考了简历、作品和长期观察之间的关系。
Comments