正文
吴恩达：
我觉得最大的挑战在于：很多业务流程里，牵涉到的是合规、法务、人力等团队的具体操作。那你要怎么构建一个“管道”把这些流程数字化？是用 LangGraph 做集成？还是看看 MCP 是否也能帮助实现？
一个很重要但常被忽略的点是：要搭建一个正确的 Eval（评估）体系，不只是评估整个系统的效果，还要能追踪每一步骤，这样你才能快速定位“是哪一步坏了”，“是哪个 Prompt 没有发挥作用”。很多团队在这个过程中可能进展比应有的慢——他们一直靠人手评估，每次改完 Prompt，就一个个看输出，人工判断，这会极大影响效率。
我认为，构建系统性评估机制是最理想的方式。但问题是，很多团队还没有这种“下一步该做什么”的直觉。技能不足的团队经常会走进“死胡同”——比如花几个月去优化一个永远也做不好的组件。而经验丰富的团队会说：“这个方案我们放弃吧，换一条路线。”
我希望我能总结出更高效的方式，教会大家这种“经验性判断”，因为很多时候你必须在几分钟甚至几小时内，看着 LangChain 的 Trace 输出、判断当前状态，然后迅速做出决策，而这仍然是非常困难的。
Harrison Chase：你认为这种“经验性判断”，更多是和 LLM（大模型）本身的限制有关，还是更偏向产品结构、任务拆解这些“构建能力”？
吴恩达：
我觉得两者都有。过去几年，AI 工具公司构建了一套非常强大的工具体系，包括 LangGraph 在内。你可以思考如何实现 RAG，如何构建聊天机器人，如何做记忆系统、构建 Eval、加上 Guardrails 等等。
我经常会用一个类比：如果你手上只有一种颜色的乐高积木，比如只有紫色的，你其实很难拼出复杂的结构。但现在我们有了更多类型的“积木”工具：红的、黑的、黄的、绿的，各种形状和功能。
你拥有的积木越丰富，组装成复杂结构的能力就越强。
我们提到的那些 AI 工具，它们其实是不同形状的“乐高积木”。在构建系统时，你可能就正好需要那个“弯曲奇怪形状的那一块”，
有经验的人知道用哪一块，能迅速完成任务。但如果你从没做过某种类型的 Eval，可能会因此多花三个月时间，走弯路
。而有经验的人会直接说：“我们用 LLM 做 Judge，评估方式换成这个，三天就能搞定。”
这也是 AI 比较“残酷”的地方之一——它不是一个工具能解决所有问题。写代码时，我自己也会用一堆不同的工具。我不能说自己精通每一个，但我熟悉足够多，可以快速组合。而且，工具之间的变化也很快。例如，随着 LLM 的上下文长度持续增加，
一年半前的很多 RAG 最佳实践，今天可能就不适用了。
我记得 Harrison 在这方面很早就开始探索了，比如早期的 LangChain RAG 框架、递归摘要等。而现在，由于上下文窗口扩大了，我们可以往里面直接塞入更多信息。RAG 并没有消失，但调参难度已经大大降低——现在有一大段“都还行”的参数区间。
所以，随着 LLM 的持续进化，我们两年前的一些直觉，有些可能就已经不再适用了。
Harrison Chase：有哪些“乐高积木”组件是现在被低估了，但你会推荐大家去关注的？
吴恩达：
虽然大家现在都在谈论评估这件事，但很多人其实并没有真正去做。我不太明白为什么不做，可能是因为大家通常认为写一个评估系统是一项巨大而严谨的任务。但我自己是把评估当成一个可以在 20 分钟内快速搭起来的小工具，可能做得不够完美，但可以作为我人工 Eyeball（眼球）评估的补充。
经常会发生这样的事：我构建了一个系统，然后某个问题不断出现。我以为修好了，它又坏了，再修好，又坏了。这时候我就会写一个非常简单的评估，可能只包含五个输入样例，用一些非常基础的 LLM 作为评审，只针对这个特定的回归问题做检测——比如“这个地方是不是又坏了”。我并不会完全用自动化评估取代人工评估，还是会亲自看输出。但这个简单的评估可以帮我减轻一点负担，自动跑一下，让我不用每次都手动去检查。
然后会发生什么呢？就像我们写论文一样，一开始只是搭一个非常简陋、明显有缺陷的评估系统。但等你有了初版，你会想“其实我可以改进它”，然后就开始迭代优化。很多时候我就是从一些糟糕透顶、几乎没什么帮助的评估开始做起的。然后随着你查看它的输出，你会发现“这个评估系统是坏的，但我可以修好它”，就慢慢让它变得更好。
另一个我想提的点是，虽然大家也讨论得挺多，但我觉得还远远被低估的，是 Voice stack（语音技术栈）。这是我非常感兴趣的领域，我身边很多朋友也很看好语音应用。我们也看到不少大型企业对语音技术极其感兴趣，而且是规模很大的企业、使用场景也很大。
虽然这个社区里也有一些开发者在做语音，但开发者的关注度相比这些企业的关注度还是小得多。而且我们说的也不仅仅是实时语音 API，也不只是 Speech-to-text 那类原生音频模型——因为那种模型往往很难控制。我更喜欢一种基于 Agentic 工作流的语音技术栈，它更容易控制。我最近在和很多团队一起做语音栈相关的项目，有些希望很快能对外公布。
还有一个可能不算“被低估”，但我认为更多企业应该去做的事情是——让开发者使用 AI 辅助编程。很多人应该都见过，使用 AI 辅助的开发者效率远远高于不使用的开发者。但我还是看到很多公司，尤其是 CIO、CTO 们，还制定了一些政策，不允许工程师用 AI 编程工具。我知道有时也许是出于合理原因，但我觉得我们需要尽快突破这个限制。坦白讲，我和我的团队，已经完全无法想象在没有 AI 帮助的情况下写代码了。但现在还有很多企业需要接受和适应这一点。
还有一个被低估的观点是，我觉得“每个人都应该学一点编程”。我们 AI Fund 的一个有趣事实是：我们公司每个人都会写代码，包括前台接待、CFO、法务总顾问……所有人都会写。不是说我希望他们成为软件工程师，但在自己的岗位上，他们通过学一点点代码，能够更清晰地告诉计算机他们想做什么。这带来了各个非工程岗位的显著生产力提升，这个现象我也觉得挺令人激动。
