Frank带研发团队时，曾经很认真地规划下一年的产品路线。哪些方向要做、哪些产品要出，内部有一套安排，销售却不买账。面对批评，他起初也不愿接受，直到有一天跟着销售去见客户，直接听到对方的困难与抱怨，才意识到，自己原来的理解缺了重要一块。
这一期谈学术与应用的距离，他没有只从抽象角度评价研究者，而是带出企业内部同样存在的矛盾。技术、工程、销售与用户，都可能各自有合理目标；如果交接方式不清楚，即便每一方都在认真工作，成果也可能停在中间。
从客户反馈到算法优化，从研究指标到人才选择，他不断追问，谁来把一段工作接下去，以及为什么有人愿意接。研发成果能不能落地，并不只取决于技术是否先进，还取决于组织有没有为后面的工作安排合适的资源、责任与认可。
做菜单的人，需要真的听见点菜的人
Frank用饭馆作比喻，一拨人设计菜单，另一拨人来点菜。如果前者一直想着自己想做什么，后者却在寻找别的需要，双方可能隔着很大的距离。菜单做得认真，并不能保证顾客就会喜欢，而顾客不喜欢，也不说明厨师没有能力。
销售带他去见客户，是他亲身经历的一次转折。原先由销售转述的批评，容易被看成部门之间的争执；当具体使用者站在面前，说明哪里卡住、哪里不合适，他才更容易发现，问题并不是谁故意否定研发，而是实际场景没有被充分看见。
这个经历让他重视直接反馈。技术团队不必因此接受每一个要求，却需要有机会理解要求从哪里来，再解释实现条件。只有当两边能够共同谈需要与限制，产品路线才不只是内部认真完成的一张表，而是与外部经验保持联系的安排。
长期研究，不能只用当期交付来衡量
谈企业里的研究方向，Frank强调，大方向仍要与业务相关，但其中的细分探索，需要留给具备相应能力的人。若把所有市场压力原样压给研究者，要求每一项投入立刻带来收入，可能使长期工作很难继续，也难以留住愿意深入的人。
他介绍自己当时区分研究与工程实现的评价方式。工程端面对项目、质量与业务支持，研究端可能关注论文、专利、提案和行业交流；观察时间也可能放得更长。这是他的管理实践，不是适用于所有企业的固定制度，但说明不同工作需要不同的完成标准。
同时，他也清楚长期投入依赖资源。人员、设备与时间最终都涉及成本，企业能承受多久，会影响哪些方向留下。保护研究不是只靠一句重视创新，而是需要实际预算与长期判断；资金紧张时怎样调整，也会暴露组织原先的承诺到底有多坚实。
演示让客户高兴，实际运行却需要十秒
Frank讲到一种典型的工程困境：研发做出很好的算法，演示给客户看，客户也愿意要。问题不是市场毫无兴趣，而是真正要用起来时，等待时间太长。点一下十秒才能返回，放进实际流程，用户未必能够接受，工程团队也不能直接宣布完成。
这个例子的重要之处，是客户已经认可过展示，产品仍然可能不成熟。演示通常证明某个能力可以实现，却未必同时证明速度、稳定性和使用方式都已合适。把演示成功等同于交付成功，后面就会出现一段看起来理应有人做，却没有被明确分配的工作。
要缩短时间，工程师可以从代码与设备等层面调整，但若瓶颈在算法结构，就需要理解核心方法的人参与。工程团队未必敢随意动，研究团队又可能已经转向下一项成果，双方之间便形成了真正的交接难题，而不是多催几次进度就能解决。
优化意味着取舍，也触动不同的成就标准
Frank观察到，有些研究者不喜欢为了速度调整自己精心设计的方法。原来最优秀的准确率若下降，即便换来更快的使用体验，也可能让他难受。对研究者而言，核心指标体现成果价值；对用户而言，结果需要在可接受的条件下出现，才有实际意义。
这不必简单解释成研究者不肯配合。优化需要大量时间，也未必带来同样容易发表或展示的成果。如果组织只奖励新突破，却把转化当成顺手完成，便会持续吸引人去开下一个方向，而缺少动力留在旧成果里处理复杂细节。
因此，Frank提出的问题同时指向技术与组织。哪些指标必须保留，哪些可以调整，怎样核对取舍后是否仍然满足需求，以及谁因这段投入获得认可，都需要明说。只有把这份工作正式看见，研究与工程才更可能一起完成它，而不是互相等待。
他喜欢招的人，是懂算法又愿意把产品做成的人
谈到积累下来的成果，Frank用毛坯房作比喻。核心结构已经在那里，但还不能直接住进去，需要继续处理许多细节。他带过的团队也有这样的项目，因此招人时，会特别注意那些既理解算法，又对落地有兴趣的人。
这类人能够进入核心方法，也愿意面对性能、使用与整合问题。让一项成果真正被用上，对他们本身就有吸引力。他们不是简单接收指令，也不一定最想不断开辟新领域，而是在两种工作之间承担有价值的连接。
Frank由此提醒，不同人才的贡献值得被区分。擅长原创突破的人重要，愿意完善已有成果的人同样重要；不能仅凭学校成绩或是否最会发表，决定谁在企业里更有价值。岗位到底需要什么，要回到真实任务，而不是只追逐一种看起来最耀眼的能力。
不是每一间毛坯，都应马上变成成品
当薛铁鏻感慨成果放着可惜，Frank又提出另一道问题：如果每一个都继续开发，投入会有多大？人、时间、设备与成本都需要增加，不能因为已经有了研究基础，就默认下一步应该无条件推进。
有些成果也许暂时适合保留，等市场、硬件或其他条件变化，再重新判断。这样的保留不一定等于失败，正如当时没有形成产品，也不足以断定研究完全没有价值。关键是知道为什么暂缓，以及什么信号出现时值得再看，而不是让项目在无人负责的状态里慢慢消失。
他也关心激励怎样分配。谁承担转化，谁拥有相应决定权，成果带来的收益怎样与投入对应，都会影响人是否愿意继续。让大家仅凭共同理想长期填补交接空白，很难稳定；合理安排责任与利益，才更接近可持续的合作条件。
回到测评，市场化也不能越过真实作用
Frank把讨论带回测评时，看见另一种张力。研究者希望工具被认真使用，用户却可能只想获得一组社交语言，或听到对自己的解释。这些用途与最初设计不完全一致，推广者需要理解，却不能为了迎合就把作用无限扩大。
他特别警惕通过恐惧推动消费的方式。先宣布对方会有坏事，再出售所谓解决办法，可能使人受到不必要的控制。测评若也采用类似路径，把有限信息说成确定命运，就不再只是表达方式的问题，而是在使用者没有充分依据时影响其选择。
因此，把专业内容讲得容易接近，并不需要许诺一切。可以说明它帮助观察什么，不能确定什么，结果还要怎样与当事人经验对照。市场需要听得懂的话，使用者也需要真实的范围；这两点一起做到，服务才更有机会获得长期信任。
真正的连接，需要把完成定义说清楚
Frank的这些经历，让成果转化从一个宏大愿望，变成许多可以具体讨论的工作。客户反馈怎样进入路线，算法如何继续优化，谁愿意承担连接，什么项目值得再投入，都比一句研发应该更懂市场更能帮助管理者作判断。
同样，市场端也不能只说用户要，就把复杂工作全部交给技术。需要说明场景与优先顺序，允许对成本和风险作判断。研究者、工程师与销售各自的目标不同，可以被保留，但交接处必须有共同目标，才不至于每一方都觉得自己已经完成，而客户仍用不上。
这一期里，Frank提供的不是一种消除所有鸿沟的制度，而是长期做团队工作后的实际提醒。完成研究、完成演示和完成产品之间，各有一段需要认真承担的劳动。把这段劳动看见，给它合适的人与条件，才可能让兴奋的展示，逐步变成真实生活里能够使用的东西。