教师节｜你还记得，那个带你入门、陪你登阶的人吗？成为AI高手，成为FDE？

教师节｜你还记得，那个带你入门、陪你登阶的人吗？

从被人带着走，到开始为别人带路。 文中两组人物与对话为情景化案例，用于讨论成长与带教，不对应具体公司的真实项目或效果承诺。

今天是9月10日，教师节。

先不聊技术选型，也不聊哪个工具又更新了。我想问两个问题：

你还记得，那个带你入门、陪你跨过某个台阶的前辈吗？

你还记得，自己第一次带新人、第一次开始管理别人时的样子吗？ 评论区一起分享你的回忆！

也许是一段始终调不通的代码，对方没有接过键盘，而是陪你从第一条日志开始看。也许是第一次面对客户，你紧张得只会重复需求，对方替你接住了场面，会后又告诉你，那几个问题为什么要那样问。

也可能不是一句温柔的鼓励，而是一次你当时不太服气的追问：

“能运行，就算做好了吗？”

“这个方案技术上没问题，可是谁真的需要它？”

当时觉得对方要求太多。后来轮到自己负责交付，才慢慢理解那些问题的分量。

我愿意把这样的帮助分成两种：有人带我们入门，让我们从不会到会；有人陪我们登阶，让我们重新理解什么才叫做好。

今年，AI（Artificial Intelligence，人工智能）又给“师徒关系”增加了一点新的意味：有时，前辈教新人判断；有时，新人也会带前辈认识一种新的工作方式。

第一个故事：从抵触 WorkBuddy，到师徒一起学会使用它

这个故事统一使用腾讯 WorkBuddy 作为AI工具。它是腾讯推出的AI工作产品；下面讨论的是围绕它如何设计带教，而不是一份产品效果评测。

陈工是团队里的资深开发，小林刚入职不久。

团队准备尝试用 WorkBuddy 辅助处理日常工作。陈工的第一反应是反对：

“新人先把基础打好。自己还没弄明白，就让工具替你做，最后出了问题谁负责？”

小林听到的，却是另一层意思：

“是不是只要用了AI，我的努力就不算数了？”

负责人想的则是：“既然已经有了工具，为什么大家还没明显快起来？”

三个人坐在同一个会议室里，担心的其实不是同一件事。陈工担心交付失控，小林担心能力得不到认可，负责人关心投入能不能带来结果。

如果这时只留下一句“大家要拥抱变化”，谁的问题都没有解决。

不争论谁更先进，先一起做完一件小事

他们选了一项边界明确的试验：根据一批获准处理的脱敏历史工单和接口说明，整理问题分类、排查清单与测试建议。

不接入生产系统，不自动修改业务数据，也不把未经复核的结果直接交给客户。

小林先用 WorkBuddy 整理出一版材料，拿给陈工看。

结构清楚，条目完整，比一堆零散文件容易阅读得多。陈工却在其中一条建议上停了下来：

“这里为什么说，订单号相同的记录可以去重？”

小林翻回原始资料，才发现这组记录对应的是同一订单的不同发货批次。看起来整齐的建议，建立在一个没有确认的业务假设上。

他有些泄气：“那是不是还是不能用？”

陈工本来想说“我早就提醒过你”，最后却换了一个问题：

“我们先弄清楚，它哪一步帮了忙，哪一步不能替我们决定。”

于是，小林负责演示怎样交代材料、拆分任务、要求标注来源；陈工负责补充业务规则、检查边界情况，并指出哪些结论还没有证据。

他们把任务说明改成：

只根据提供的资料整理。区分已经确认的事实、你的推测和待确认的问题。关键结论标注对应来源，不要自行补全业务规则，也不要把缺少依据的判断写成确定结论。

这段要求不是保证正确的咒语。来源是否对应、规则是否遗漏，仍要由人检查。但双方终于有了一个共同的工作对象：不是“AI到底行不行”，而是“这份结果哪里可用、哪里需要补证据”。

从质疑到认可，不等于从此不再质疑

后面的试用中，负责人也调整了观察方式：不只看生成初稿用了多久，还要把材料准备、人工复核、返工和最终验收一起算进去。

陈工逐渐愿意把部分整理工作交给 WorkBuddy，但坚持保留业务判断和交付检查。小林也不再把“很快生成了一份东西”直接当成“自己已经掌握了这件事”。

一次复盘里，陈工问：“这条建议不用看工具，你能解释为什么吗？”

小林解释了一半，停住了。他们就从停住的地方重新学习。

编程教育的一项研究，也把“帮助学习者思考，而不是直接交出完整答案”列为AI辅助工具的重要设计考虑。这是学习场景的研究，并不意味着已经证明某款办公工具的培养效果，但这个提醒值得带教者借鉴。

认可工具，是知道它在哪些环节值得使用；学会使用，是知道什么时候还需要自己停下来想。

故事最后，没有人变成另一个人的反面。

陈工没有放弃严谨，小林没有放弃探索，负责人也没有放弃效率。他们只是学会了用一份实际完成的工作，而不是用立场，评价新的工作方式。

而这一次，小林也当了一回老师。

第一次带新人，才知道“这个很简单”有多难解释

陈工并非一开始就会带人。

他第一次给小林分配任务时，只说了目标、截止时间，再甩过去几份文档。看对方迟迟没有进展，他忍不住把鼠标拿了过来：

“你看，这里改一下就好了。”

问题解决了，小林却不知道下次该怎么找到那个“这里”。

后来陈工才意识到，自己省略了太多步骤：为什么先看这一份日志，为什么排除那个方向，哪些字段虽然同名却不能混用，以及什么时候应该停止猜测、找人确认。

他以为自己交代的是一道题，其实新人连题目所处的背景都还没有看见。

再后来，他不急着接过鼠标了。他先请小林讲当前理解，看看卡住的是知识、上下文，还是不敢确认自己的判断。

这也让他重新想起了带自己的前辈。

原来，当年那些看起来“不费什么事”的指点，背后也是对方一次次克制住“我直接做更快”的冲动。

第二个故事：从开发走向业务现场，他又当了一次学生

后来，陈工开始尝试另一种角色：FDE（Forward Deployed Engineer，前沿部署工程师）。

这里的“前沿”强调靠近客户和业务现场，不是前端开发。Palantir对相关岗位的介绍，强调与客户直接协作，把平台能力组合成实际解决方案；工作同时涉及软件开发、数据工程和客户沟通。

不过，换了一个岗位名称，并不会自动带来新的能力。

开发转型的第一课：先别急着回答“怎么做”

客户提出：“我们想做一个能处理订单异常的智能助手。”

陈工很快想到数据接入、规则配置、页面和自动通知。他以为，只要把这些部分连接起来，方案就基本成立了。

带他进入项目的前辈没有先评审架构，而是让他跟着业务人员看完一次异常处理。

他这才发现，销售说的“订单完成”是客户签收，仓库说的是货已发出，财务关心的却是款项是否到账。还有一些被系统标成异常的单据，在业务人员眼里只是正常等待。

一位长期处理订单的业务同事问他：

“你这个助手提醒完以后，谁来接？那个人不接怎么办？”

这句话比继续加一项技术能力，更接近眼前的问题。

在这个案例里，陈工需要补上的第一课，不是某个新的框架，而是：先确认业务希望改变什么，再判断系统应该做什么。

他们重新缩小范围，只选择一种明确的异常，先记录人工处理基线，再与客户商定试点要观察的结果：分派是否准确，责任人是否及时接手，以及处理过程有没有增加新的负担。

他以前擅长把已经明确的需求做出来；这一次，他开始学习和别人一起把问题弄明确。

站在技术领域里，他是前辈。坐到业务人员旁边，他又是新人。

产品转型的第一课：能讲清楚，还要能让它可靠地运行

与陈工一起参与项目的产品同事小夏，也希望向FDE方向发展。

小夏擅长访谈、流程梳理和推动共识。使用 WorkBuddy 后，整理资料、准备原型的门槛也降低了。她开始觉得，自己距离独立交付越来越近。

陈工没有否定这种可能，只带她继续往后看：

“数据缺一项时怎么办？接口失败之后，系统是什么状态？权限怎么控制？这次修改影响了哪里？上线后谁能发现问题，又怎样恢复？”

这些问题，不会因为原型能演示就自动消失。

以OpenAI公开的FDE岗位要求为例，除了客户协作、需求界定和部署，它仍明确要求编写、审查生产级代码。因此，产品背景可以成为转型的起点，却不能把工程能力视为可以完全跳过的一环；不同企业的具体职责也需要分别判断。

在这组案例里，两个人需要补的课并不相同：陈工要走近业务，学习判断问题与价值；小夏要走近系统，学习数据、实现、验证和运行边界。

他们不是要放弃原来的专业，而是要让原来的专业，能够和另一半真实世界接得上。

这也不是说，每一个开发或产品都必须转型FDE。有人适合继续深耕技术，有人适合专注产品。值得借鉴的，是这种走出岗位边界、对实际结果负责的学习方式。

轮到我们带新人进入FDE，第一步应该教什么？

如果接下来由陈工带小夏完成第一次小范围交付，我更赞成这样的安排，而不是先发一长串工具清单。

先一起看，再让新人讲。

一起旁听需求访谈、观察真实操作，回来后由新人复述：谁遇到了什么问题，现在怎么解决，为什么现有做法不够好，还有哪些地方没有弄清楚。导师先检查理解，不急着检查方案。

再交出一小段，但保留完整的前因后果。

例如，让新人负责一种订单异常的识别与人工确认流程。范围可以小，却要看见数据从哪里来、规则由谁确认、结果给谁用、失败由谁处理。既不是永远打杂，也不是第一次就让他独自承担整个项目。

逐步放手，同时把求助边界说清楚。

哪些事项可以自行决定，哪些必须复核，什么情况下必须停下来求助，关键技术决策由谁负责，都提前讲明。导师提供支持，不替新人做完；允许试错，也不把真实客户当作无保护的练习场。

最后，让新人把这次经历讲给下一位新人。

交付物不只是一套能运行的东西，还应包括业务词汇表、关键决策、失败样例和验收记录。让下一位接手的人不仅知道“怎么做”，也知道“为什么这样做”。

WorkBuddy可以继续参与这条学习路径：基于获准使用的材料辅助整理知识、模拟业务追问、暴露理解盲点。但工具生成的解释和评分不等于真实验收，业务规则仍要回到资料和领域专家，工程结果仍要经过测试。

Palantir的一篇官方岗位访谈中，受访工程师谈到进入陌生领域时，依靠的不只是独立学习，还有导师、团队成员，以及最了解问题的客户；他也专门强调了导师关系的重要性。

这让我觉得，所谓“能独立解决问题”，不必理解为一个人什么都懂。它也可以意味着：知道哪些地方自己还不懂，知道向谁学习，并能把学到的东西组织成可信的结果。

好的带教，不是把自己的答案复制给别人

回头看，这两个故事讲的其实是同一件事。

从抵触 WorkBuddy 到学会使用，不只是掌握一个工具，而是师徒重新讨论：什么可以交给工具，什么仍需要自己理解和负责。

从开发或产品走向FDE，也不只是补齐一张能力清单，而是有人陪你进入不熟悉的现场，允许你提问，再逐步把判断和责任交到你手上。

如果我们已经开始管理团队，还应该为这种过程留出真实的位置：安排带教时间，承认导师的投入，不要一边要求培养新人，一边又把所有解释、复盘和练习都当成“耽误交付”。

我希望好的带教，最后能留下的不是“没有我你就做不了”，而是：

“下次遇到类似的问题，你知道该从哪里开始；遇到不同的问题，你也敢承认不知道，再想办法弄明白。”

这大概就是从“我会”，走向“我们会”的过程。

今天，把评论区留给那些具体的人和事

教师节，除了向课堂上的老师说一声感谢，也想把这份感谢送给那些没有教师头衔，却曾认真带过我们的人。

可能是前辈、同事、负责人，也可能是耐心解释业务的一线员工，或者在某个新领域反过来教过我们的年轻人。

你还记得，谁带你入门，又是谁陪你跨过了后来那个台阶？对方说过哪句话、做过哪件小事，你到现在还记得？

你第一次带新人、管理新人时，又出过什么糗、踩过什么坑？有没有后来才意识到：原来自己也在重复当年前辈的某个动作？

也欢迎聊聊最近的一次变化：是谁让你从抵触AI到愿意认真试一次？又是谁在你走向FDE或其他新角色时，陪你完成了第一段不熟悉的路？

不用写成履历，也不必总结成大道理。一个场景、一句话，就足够。

曾经有人愿意等我们弄明白，也有人在我们犹豫的时候，给过一次尝试的机会。

愿我们记得他们。

也愿后来的人回忆起自己的入门与进阶时，能够想起我们。

教师节快乐。