选择任意段落提问。我会收到问题并将答案添加到文档中。

序言

序言其实不过是一份提前列好的借口和解释，用来保护自己免受批评——尤其是来自你自己的批评。所以尽管跳过。

什么意思？

最近我总听人谈论 FDE，也就是“前沿部署工程师”，而他们中的大多数根本不知道自己在说什么。不是因为他们蠢（虽然有些人可能确实如此），而是因为他们从未真正接触过这件事。所以，显然，我要给你讲讲我自己的经历：这样一支团队意味着什么、为什么要组建、如何运营、什么时候合理、如何招聘和培训，顺便说说为什么大多数陈词滥调都是胡扯。

但如果你只记住一件事，那就是：FDE 是有用的，是说得通的，你应该考虑在自己的产品公司里组建这样一支团队，尤其是当你销售高额合同时。

本文写给谁

这主要是写给创始人或正在组建这类团队的人：向规模较大（但不一定）且较成熟的公司销售、产品需要一定集成工作的 B2B 公司。

但如果你想要这样一个职位，或者已经身在其中，我认为了解别人是怎么做的会很有帮助。无论什么主题，这总是有益的。

但为什么？

我是一家 B2B 创业公司的创始人：Tinybird，融资约 7000 万美元，ARR 达数千万美元。我们做的是技术产品，而且公司和产品都是从一支 FDE 团队起步的。当时这个词对我们来说还不存在，不过没关系。这是一种让客户为你的产品研究买单、同时反过来为他们提供有用帮助的好方式。你知道的，这就是生意。

八年后，这支团队仍在运转。它不仅帮助客户解决具体问题，也是支持团队的一部分。与其由我来告诉你他们做得好不好，不如让那些接受过帮助的人来说。

我认为真正有这方面经验的人不多，写出来的更少。于是就有了这份文档。

FDE 团队到底是干什么的？

写给非 B2B 从业者的简短介绍

如果你刚读到 B2B 就一头雾水，不知道接下来会讲什么：当你做一个产品并卖给规模较大和/或较成熟的公司时，他们通常需要帮助。有些是因为他们实在不行，有些是因为内部政治导致他们的团队无法执行，还有些——也就是有意思的那些——是因为他们需要你特有的能力。在 B2C，甚至低客单价的 B2B 里，你把产品发布出去，让人们自己摸索。而在高客单价的 B2B 里，你不会放任他们不管。

而且，看在上帝的份上，我们别自欺欺人了：让你的软件完美契合一家公司的需求是非常困难的。总有一些角落和细微之处需要调整。拥有一个提供帮助的团队并不丢人。当然也有传奇式的例外（比如 Datadog），这些公司的客户团队乐于自己折腾着解决问题，但即便是他们，也始终有技术人员在提供帮助。

什么是 FDE？它和穿着廉价西装、按小时计费的顾问有什么区别？

最好的解释是间接给出的——这是一位前 Palantir 员工写的一篇精彩文章。Palantir 正是创造这个术语的那帮朋友。需要说明的是，你可以叫它 FDE 或任何你喜欢的名字；这类人需要：1) 知道自己在做什么，2) 打入客户组织内部，去理解并解决他们的问题，3) 把可以应用到自己产品上的知识带回来。

传统咨询做到 1 和 2。嗯，有些咨询公司几乎不做 1，而把全部精力放在 2 中“打入内部”这件事上。理想情况下，FDE 应该专注于 3。FDE 应该能够从客户那里回来后，实现产品所需要的任何东西。当团队很小时，这相对容易；而在大公司内部，这非常困难。

不过，有一种更好的方式来定义这个角色。传统顾问和 FDE 之间的区别——至少在我看来——在于 FDE 与结果利益攸关（skin in the game）。他们会坚持到最后并承担责任。在 Tinybird，我曾看到我团队里的人接管了客户的项目管理，因为他们看出客户靠自己永远无法上线。

团队的目标是什么？

我的定义很简单，但对我一直极其有效：你的目标是让客户尽快进入生产环境。

这句话我每周大概要重复一千遍，但它很重要。永远不要被“多收钱”或“提供技术支持”之类的事情分心。有时候，正确的帮助恰恰是提出一个完全不使用你产品的解决方案。

要做到这一点，显然你需要理解他们的问题。要正确地理解并解决它，你需要他们的上下文。获得上下文的方式是提问、理解、再提问。提出解决方案，测试它，验证它，再提问，如此反复。开发者恰好就是做这件事的专家。我们将在下一章讨论这一点。

所以，如果你读到这里就停下来，你已经掌握了关键：不要被各种指标和愚蠢的次要目标缠住。如果你的客户赢了，你就赢了：在收入、留存以及与客户的关系上都是如此。所有这些都是二阶效应。

有一个细节不容忽视：当你进入客户现场解决问题时，有时问题本身并没有被明确定义，你得自己去定义它。没有什么比亲身面对实际情况更有效的学习方式了。这就像看别人解数学题和自己动手解题的区别。你懂的。

团队应该是什么样的？

无论做什么，团队都是关键。Ed Catmull 用一句话解释得比我好得多：

这里有一个重要的原则，看似显而易见，但根据我的经验，其实一点也不明显。找到合适的人并让他们产生良好的化学反应，比找到好点子更重要。

合适的人加上良好的化学反应。记住这一点。当然，你做的事情至少还得有点道理。Catmull 把这一点视为理所当然，但我们是西班牙人（对非西班牙语读者来说，我们通常很不擅长推销自己，所以我想自嘲一下），所以最好还是别冒险。

我们的前提是：“人们处理数据的方式还停留在 15 年前，但技术和硬件已经好得多了；我们可以帮助他们做得更好。”八年过去了，我可以说这个前提是正确的。

谁来做？

当然，这取决于产品。Ed 和我已经告诉过你了。但看在上帝的份上，请雇用真正懂行的人。不要把团队塞满只会发邮件、维持客户关系的文员。他们在这里毫无用处。你需要的是有主动性的能干人才。这类人通常很贵。别抠门。他们往往是工程师；FDE 的定义大致就是由此而来的。

我再说一遍：别抠门。花在这些人才上的每一欧元都会有回报。很多公司试图在这方面、在支持团队以及其他没有明显回报的事情上省钱。在我看来，这是个错误。

就我而言，我招的是后端工程师。是的，我们的领域是“数据工程”，但“数据工程师”大多是只会用四个工具的人，所以我们选择了有软件经验、基础扎实的人。他们对与客户打交道一窍不通，但这不要紧。人是可以学的。

但他们需要懂得“周旋于客户之间”吗？

每当听说这类人需要商业知识、必须懂得周旋和玩弄权术时，我就感到不适。我的经验是，一旦有人懂得玩这一套，他们就会用起来，最终通过操纵来“解决”问题。我本想用个更委婉的词，但何必呢。从长远来看，用事实说话、又有点主动性的人要好得多。

你可以有懂得“周旋”的人，但他们的职责是支持 FDE。我稍后会解释具体方式。

所以忘掉那条要求吧。人是可以学的。在 Tinybird，我招过说话时盯着自己鞋子看的人，他们最终与客户合作，并且乐在其中。

一定要是一个团队吗？

他们难道不能只是个人吗？说到底，终究是一个人对着一个客户工作。大概可以。但组建团队是有道理的，至少我是这么做的。

首先，一如既往，总得有人不断催促推进。你去政府办公室办过手续吗？你见过那种不坐在工位上办事、只是盯着确保事情办成的人吗？就是那种当公务员说“这需要填405号表格，你得去另一个办公室”时，会回一句“不，我们就在这儿把这事解决掉”的人。这就是你需要的：一个确保事情真正发生的人。

其次，团队需要精心准备客户入驻和流程，组织信息并输送给产品团队，知道什么时候该施压把事情做完，提供人员来验证方案，等等。

他们做什么，以及怎么做

他们帮助客户解决那些客户自己不懂的部分。他们不是一堆可计费工时的容器；他们是“懂行”的资源。在我们这里，FDE 做 FDE 的工作，同时也协助售前、售后、支持等环节。这里我只讲客户内部的工作。

这项工作有三个清晰的支柱：1）面向客户，显而易见，用 Z 世代的话说；2）面向内部，不那么明显；3）面向产品，一半明显。

1) The customer cycle is “relatively” simple:

  • 一个客户带着你领域内的某种“挑战”出现。不要接那些纯粹为了赚钱的咨询工作，即使你完全有能力做。
  • 团队里有人判断这是不是一个真正的挑战。有两种可能：也许他们只需要四个小调整和一次方向修正，也许确实有实实在在的东西可做。显然，你要的是有实质内容的客户。通常由有经验的人来做这个判断，但其实只要掌握一些基础要点（我会在培训部分讲到）就足够了。
  • 在第一次会议上，如果可能，直接向客户要你能立即上手处理的“数据”。不要说“我们再约个时间开会”。直奔主题。这一点非常重要，因为它能告诉你对方是在浪费你的时间，还是真的有问题。大公司当然会说“NDA（保密协议）之类的”，但当需求是真实的时候，NDA 签得飞快。
  • 建立一个永久的、实时的沟通渠道。我们用 Slack。什么工具都行，但必须设在客户所在的地方。你得深入其中。
  • 创建一份文档，写明你要达到的目标，并在每次客户会议中使用它。当然，我假设这一切都是远程进行的。把人派驻到办公室？我们又不是原始人。
  • 每周开一次进度检查会，看看进展如何。紧跟客户是根本。你必须坚持不懈。无论你有多少流程、工具和受过培训的人，总得有人去推动。这适用于 FDE，也适用于任何你想交付的东西——不管那些流程爱好者跟你说什么。
  • 如果 FDE 认为有必要，就强制召开会议。是的，是的，我知道：会议，诸如此类的抱怨。但会议也分种类。有些会议的存在，只是为了让那些根本一无所知的人露个面。而我所说的会议，是为了强制做出决策。这些人除非必要不会开会；他们不是糟糕的销售人员。
  • 一旦客户进入生产环境，或者你已经解决了相关问题，继续跟进。监控一切是否正常运行，并持续关注。

本文档的最后一部分将介绍围绕这一切的、偏管理性质的工作。

2) Internally, meaning what the team does as a team:

  • 每周，审查重要客户、有潜力的次重要客户，以及维护类客户。
  • 收集所有阻碍进展的产品问题和功能需求。不要立即转交给产品团队。
  • 审查产品中的所有新功能，看看是否有客户能在他们的使用场景中用上。有时你直接用他们自己的数据给他们发一个测试，就像我们做的那样。记住：你是他们项目内部的人。你不需要请求许可。

3) With product:

  • 如果可能，FDE 也应该就是构建产品的人。这并不常见，但在产品早期是可行的。你可能会过度拟合解决方案，但这总比空中楼阁要好。
  • 团队负责人参加产品会议和例行检查。他们是试飞员。如果 FDE 需要和产品经理（或无论这个角色现在叫什么）沟通，他们就直接去做。如果需要揪着产品经理的耳朵把拖到客户现场，他们也会去做。FDE 是产品团队的触觉，尤其是在事情着火的时候。
  • 跟踪问题，当问题修复后告诉客户：“你的问题解决了。”没有比让人们看到你在乎他们更好的留存策略了。否则，你三十岁了还赖在妈妈家里干什么？
  • 维护产品的声誉。不存在“产品团队说他们做不到”这种话。没有什么比在谈判中拿同事当挡箭牌更可悲的了。那很可悲。不要那样做。选择睡个好觉。

轮换

一个重要的点：人会疲惫。AI 不会，但人会。让他们 1) 同时服务多个客户，2) 不时更换客户，是个好主意。

理想情况下，FDE 应该在产品团队待一段时间。但说实话：人员调动并非易事，而且一旦进入产品团队，你就会安顿在产品经理、工程经理和支持团队的温暖庇护之下。那是一个“假装解决问题”的国度，问题只是 Linear 上的工单，而不是你必须亲自出面应对的处境。

另一种很好的休息方式是去攻克一个艰难的挑战。客户经常会提出荒谬的要求。这没关系，我自己也总是这么干。那些乍一看不可能实现的事情。在我们的案例中，这类挑战看起来像“在 100 毫秒内对 10 万亿行数据运行这种查询”，而这需要非常深入地钻研。这种研究是纯粹的黄金。它让团队保持清醒，抬高标准，并夯实基础。这很昂贵，但一个失去干劲的团队代价更高。

最后一点，同样重要（是的，我在重复自己）

如果你认为这类团队的目标应该是最大化每个客户的收入，请关掉这个页面，去角落里好好反省。那些“懂行”的人把这称为“客户成功”，而这是整个行业的绝对瘟疫。不。你的目标，永远是以最快的速度、最好的质量解决问题。其他一切都是扯淡，或者是良好工作带来的副产品，比如钱。

招聘与入职

你可能会觉得你需要有客户经验的人、顾问，或者是那种既懂技术又能与人打交道、穿着得体、有魅力有气场、又高又帅、浪漫而坚定的独角兽……

不。你很可能需要招聘的是你的客户所需要的人。举个例子：我们面对的是开发者，这些人能在 200 公里外就嗅出扯淡。他们不信任任何无法证明自己懂行的人，而且他们通常有非常独特的沟通习惯。让一个穿西装的人站在他们面前，半个会议之内就会被撕得粉碎，而你的机会也就没了。

是的，但他们难道不需要“人际交往能力”吗？

你需要最基本的尊重和礼貌，并且需要清楚地表达你想做什么。你不需要是个骗子。你只需要遵守一些基本规则，我会在与客户合作的那一节中讲到。

在 Tinybird，我们招进这个岗位的人几乎都没有客户经验。但他们确实懂行，而这才是最重要的。话虽如此，我领导过这个团队，与数百位客户交谈过，而我的性格并不特别友善，从这份文档中你大概也能看出来。我不擅长搞政治，也读不懂一群人之间的微妙关系。

招聘

我认为这与你在招聘产品、后端或其他工程师时的标准没有太大区别，但我非常、极其看重一个人探索未知的方式。

流程是这样的：我会提出一个非常开放但极其简单的技术练习。这里有一个例子1。一旦我看到他们的思路，我会在后续问题中不断改变规则，以了解他们如何界定问题。

筛选标准很简单：如果他们不问问题就开始解题，这是坏信号。如果他们会提问、形成假设、试图理解、澄清并收窄问题，那就是你要找的人。当然，如果他们技术功底也扎实，那就加分。

关于招聘的一个重要细节：招聘永远不会结束，也不是偶尔才做的事。你需要谈论你在做的事情。你需要对人有吸引力，这样当你发布一个职位时，已经有不错的人感兴趣了。这其实很简单，就是定期发布有用的内容，但几乎没人这么做，因为他们把这事丢给了市场人员，而那些人通常根本不知道自己在写什么。

最后，招聘就像俄罗斯方块。你必须在正确的时机找到合适的方块。有时候长条很有用，有时候则不然。平衡是关键。

入职培训

入职培训比招聘重要得多。好的入职培训可以挽救一个糟糕的招聘，也能毁掉一个优秀的人才。基本原则是：

  • 教授基础。不要迷失在细节的讲解中。把基础内容反复强调大约 200 遍。当然，你需要清楚自己业务的基础是什么。
  • 确保他们顺利融入团队。如果他们自作聪明或招人讨厌，那你就已经搞砸了。处理这个问题有很多方法，但日久生情，经理（或负责人）需要在场，一点一点地把他们介绍进团队。这个人要为机器上润滑油，磨平粗糙的棱角，并完成把新人引入团队仪式的社交工作。保持团队互相信任、没有嫌隙至关重要。我经常使用幽默和玩笑，即使在我们搞砸得很惨的时候也是如此。你可能有别的技巧。用你喜欢的任何方式，但确保新人站稳脚跟是你的责任。

在 Tinybird，我使用一些别人绝不可能在之前发明出来的古老技巧：

  • 我录制了一门涵盖基础内容的课程，让他们必须观看。是基础内容。不涉及公司、产品，也不涉及创立公司的那位“基督”。都是非常非常基础的东西，重复迭代了上千遍。事实上，我们把这些材料公开发布了，它同时也起到了市场推广的作用，并成为我前面提到的持续招聘的一部分。
  • 一系列真实练习，让他们借助产品对这些基础内容进行迭代。显然，需要有人跟进他们的进度、回答问题、讲解错误，并布置练习来巩固他们没有理解的内容。我以前还会给他们出难题，免得他们太自满2。
  • 逐步让他们接触客户，始终与另一位 FDE 一起。通常是一个较小的客户，其背景更容易理解，这样他们就能消除提问或搞砸的恐惧。
  • 与此同时，他们必须每天写下自己学到的东西。这能培养写作习惯，有助于文档化，也让其他人（当然包括 LLM）能够学习。我们低估了用文字清晰地解释事物、记录我们所做工作的价值。让团队变得更好的大量知识，都来自那些解释某人如何解决客户问题的内部帖子。
  • 最后一个技巧是“把他们扔进狮群”：让他们陷入一团乱麻，自己找出路。这招非常管用。

解雇

没人喜欢谈论解雇这件事，因为在文化上这很伤人。这很正常。如果你的国家大多数工作都是低技能岗位，人生的终极目标是一份铁饭碗，而公务员是最终的大 boss，那这种心态就说得通了。幸运的是，在我们这个行业，如果一家公司解雇了你，第二天你就能去参加四场面试。还是会疼，但那只是戏剧，不是流血牺牲。

把这点说清楚之后，你可以因为某人不能胜任工作、不适合团队，或者任何原因而解雇他们。但有一件事你绝不能容忍，那就是客户被怠慢，或者有人找“借口”。这是一门建立在信任之上的生意。这是你不能丢失的根基。同样，如果你是一名 FDE，而你的老板让你撒谎，那就开始备份你的邮件并打开 LinkedIn 吧。

与客户相关的非技术工作

并非所有事情都是技术性的。与客户打交道还有很多其他重要的事情，尤其是达成共识、提供可见性、设定边界，以及管理与决策层的关系。

这时候通常需要一位商务人士登场：客户经理（Account Executive）、创始人、CEO、大客户高级客户成功经理（CUSTOMER SUCCESS MANAGER KEY ACCOUNT ENTERPRISE SENIOR），或者上帝决定给他们起的任何头衔。我亲切地称他们为“西装”。重要的是，这个人负责把控客户关系的节奏、设定边界、谈钱，并扮演黑脸。

“西装”在任何情况下都绝不能卷入技术争论。原因有二。第一，他们会搞砸，并在技术团队面前失去公信力。第二，最好在运营/技术工作与客户管理之间保持清晰的界限。把他们想象成两条轨道，各自做各自的事。最终，FDE 和商务人士应该能够交换一个眼神（当然是通过 Google Meet），就知道什么时候该让位给对方。如果你是创始人，你可以随心所欲，把交易搞砸。这就是你给自己发工资的意义。这是个玩笑，但并非不真实。

启动项目

正如我所说，与客户的合作总是从讨论要解决的问题开始，带着全世界最紧迫的紧迫感。索取访问权限、数据、联系人，以及任何能让你尽快摸清情况的东西。这项工作由“书呆子”也就是 FDE 来做，而不是“西装”。

话虽如此，期望必须明确：时间、投入、金钱和边界。这要花这么多钱；你会和这些人沟通；你可以联系这个人，响应 SLA 是这样；我们需要这个和那个；每月费用是多少。当然，所有人都会试图把它算进 ARR，好让 AE 拿更多提成。天经地义。

在商务方面，你需要了解你的客户如何分配预算。为工作收费有几种方式：

  • 咨询服务。这种方式对大公司很有效，因为他们通常有已批准的预算，也习惯于购买这类服务。在某个糟糕的供应商平台上注册一下，就大功告成了。
  • 高级支持服务。问题在于，Amazon、Google 以及许多其他公司出售的极其昂贵的高级支持服务完全是垃圾。我是凭经验这么说的。
  • 直接作为产品合同的一部分：对于超过 X 美元的企业合同，强制收取 10%。

无论采用哪种模式，都要像对待任何合同一样，明确限制工时、日期、参与程度、响应 SLA 等等。

你也可以选择不收费，并假设会有回报。有时这确实行得通，尤其是在融资拿到一笔严重高估值的资金、手握数百万美元，每月几千美元对你来说无关痛痒的时候。

光把活干完还不够；还得让人看起来你干过：业务会议

正如我所说，业务线还有另一项任务：让工作成果可见。FDE 的影响力并不总是显而易见的。因此，当你的“业务”人员定期与对方的“业务”人员会面时，他们首先要解释的就是：“看，这就是我们所做的工作。”

显然，你要提前为这次会议做好准备。FDE 和业务人员聚在一起，审阅 FDE 撰写的报告（这就是那种把一切都记录下来的美好文化的由来），并准备以下内容：

  • 我们做了什么以及为什么。光靠 LLM 生成的摘要是不够的。你需要掌握客户的真实脉搏，而 LLM 做不到这一点。你需要读懂字里行间的含义，理解真正让客户痛苦的是什么。
  • 下一步计划、阻碍因素，以及项目例会上的常规内容。我不打算在这里教你怎么管理项目。
  • 钱和其他业务事项。绝对、千万不要让技术人员参与这些对话。FDE 的职责是解决问题；业务人员的职责是促成交易并讨论这些事情。把两者混在一起，你就会开始用金钱来思考。有些信息是有用的，但最终你会潜移默化地认为钱就是目标。
  • 最后，是那个价值百万美元的问题，也是你辉煌的 NDR（美国用来衡量账户扩张程度的指标）的来源：“你们还有其他正在推进的项目吗？”公司通常同时在做不止一件事。如果某个项目引起了共鸣，你可以主动提出参与其中。很多时候这会自然发生：他们启动了一个项目，FDE 听说了这件事。作为 FDE，你必须时刻竖起耳朵。

当项目结束时

项目永远不会结束，只会放缓。但重要的是，你要持续关注事情的进展。你可以半自动地进行，通过定期检查、指标，或者询问客户的团队。

而且如果你在一家产品公司工作（不然你为什么要雇 FDE？），你非常清楚他们是否会流失，是全部流失还是部分流失。所以你可以做出那些高管层最爱的美妙预测。而如果你够聪明，与其盯着预测看，不如做点什么来留住客户。你几乎总能留住他们。

杂谈

客户公司里的人员来来去去。你需要保持关注，并赢得新人的信任。如果你工作做得好，它本应不言自明，但永远要记住，人性是最糟糕的，有人可能就是单纯不喜欢你。如果他们不喜欢你，那也没办法，生活就是这样。只要确保这不是因为你把工作搞砸了就行。

工作应当直接计费、按高级支持小时数计费，或者通过扩展带来显而易见的投资回报。这看起来是常识，但尤其是在初创公司里，很容易滑入“这个我们以后再谈”的状态。在我看来，你应该跳进泳池、承担一些风险，但几个月后数字必须说得过去。否则你就是在白干。

客户会习惯于极其优质的服务，然后拒绝接受任何更差的东西。这就是为什么你要收费，并确保你的工作被重视。

收尾

撇开工作和解决问题显然能赚钱、能让你学到东西这一点不谈，有件事我们常常忘记：解决问题是有趣且令人满足的。

许多从未与客户打过交道的开发者，一旦转到其他岗位（通常是产品岗），就会怀念那段经历，因为还有谁比真正和产品搏斗过的人更适合打造产品呢？不仅如此：他们已经养成了与客户协作的习惯，知道如何提出正确的问题，而且游刃有余。Soltura（西语：通透）。我喜欢这个词。

一些坏处

事情并非一片阳光和牛至。以下是我们遇到过的一些问题：

  • 产品变得过于依赖 FDE 来留住客户。
  • 客户过度依赖你的 FDE，并期待一些他们本不该期待的东西。
  • 你最终会忽视产品的自然增长。你会忘记自助服务也可以是一个不错的渠道。
  • 很难同时维持 FDE 文化和产品驱动增长文化。
  • 产品团队会习惯于有一个人来弥补产品的问题。
  • FDE 最终会抱怨产品有问题，却不去自己动手解决。
  • 它无法“规模化”：要增长就需要更多人，而人是最糟糕的。
  • 我想我已经有足够的素材再写一篇 4500 字的文章了，所以就写到这里。

需要帮助吗？

只需……报名参加这门课程——不不不，我开玩笑的。

如果你读到了这里，说明你有一家 B2B 产品公司，想组建一个团队，或者已经有了团队并有一些疑问。我很乐意帮忙；给我写信，我们可以聊聊。免费的。我不以此为生；这是我为自己所在的生态圈尽一份力的方式。

  • 如果你读了这篇文章，你会看到我禁用了 ChatGPT。后来，我又把它变成了强制使用。 ↩
  • As a manager, there are two important things I tend to do:
    • 当女儿把三位数加法练习拿来让我检查时，我常常看都不看就说：“其中有一道题算错了。”这会带来两个效果：她学会确保自己的作业是正确的，同时她也明白“老板”并不总是对的，有时老板也会犯错，你需要懂得如何去挑战他们。“批判性思维”将是未来几十年的核心技能，因为 AI 会扮演那个“无所不知”的角色。同样的方法也适用于员工：他们觉得你错了，但通常不会告诉你。
    • 你应该始终把目标设定得略高于预期——无论是你自己的预期还是他们自己的预期。如果某人有潜力，但你从不加以考验，你就永远不会知道。在入职阶段，这样做还能在一切还像游戏一样轻松的时候，就把期望值拉高。
    ↩