“别指望一次就对”：Granola 团队踩过的 LLM 产品化真坑

很多人还在幻想：给大模型一个完美 Prompt，就能一次生成“神级结果”。但 Granola 的工程团队在台上直接泼了盆冷水：你不能 one shot 它。这段分享把 AI 产品工程里最不体面的真相摊开讲清楚——而且全是实战换来的。

最反直觉的一点：LLM 不是“调用成功就完事”

分享一开始，Granola 团队就抛出一个让人不太舒服的结论：你不能指望大模型一次就把事做对。在他们的产品里，LLM 的输出不是“结果”，而是“过程的一部分”。

比如会议记录和自动笔记这种看似简单的场景，模型第一次生成的内容往往只是个“草稿级别”的东西。真正有价值的体验，来自后面一整套补救机制：结构化、纠错、补充上下文，而不是一句 Prompt 定生死。

这直接挑战了很多 AI 工程师的直觉——我们太容易把精力都花在“写一个更聪明的 Prompt”上，却忽略了系统层面的兜底设计。

他们的产品哲学：不是调教模型，而是“塑形”模型

在第二和第三个片段里，Granola 反复强调一个词：molding（塑形）。他们并不把 LLM 当成一个黑盒 API，而是当成可以被约束、被引导、被反复修正的组件。

具体做法并不花哨，但很工程化：
- 把任务拆成多个阶段，而不是一次性生成
- 明确哪些步骤可以让模型“自由发挥”，哪些必须强约束
- 在管道里引入外部工具，比如搜索或规则校验，来弥补模型的不确定性

这背后的产品哲学是：AI 功能不是功能点，而是一条流水线。模型只是其中一个环节，而且并不是最可靠的那个。

真正拉开差距的，是调试和可观测性

一个很容易被忽略、但被他们反复强调的点是：你得看得清模型到底在干嘛。相比传统 Web 应用，LLM 产品几乎没有现成的“调试奢侈品”。

Granola 分享了他们后来补上的一整套方法：记录中间输出、回放模型决策路径、对失败案例进行系统化分析，而不是“感觉这次不太行”。

这一步不性感，但极其关键。因为一旦你能定位问题是在数据、Prompt、上下文，还是模型能力本身，改进就变成工程问题，而不是玄学。

AI 产品不是设计稿，而是不断被修正的现实

在后半段，他们提到一个很现实的对比：AI 产品和传统 Web 或移动应用完全不同。以前你可以在 Figma 里看到几乎完整的用户体验，但在 LLM 产品里，真实体验只有上线后才会暴露。

这也是为什么他们强调快速迭代、频繁 shipping。不是因为他们喜欢冒险，而是因为不这样做，你根本看不到模型在真实世界里的行为模式。

这也解释了标题那句话的真正含义：不是“我们还不够聪明”，而是这个问题本身就不可能一枪命中。

总结

如果你正在做 LLM 相关的产品，这场分享给了一个非常清醒的提醒：不要把全部希望押在一次生成、一个 Prompt、一个模型版本上。真正成熟的 AI 产品，靠的是流程设计、约束机制、调试能力和持续迭代。

行动建议很简单但不容易：把模型当成不稳定因素来设计系统；为失败准备好观测和补救；尽早在真实用户环境中暴露问题。最后留给你一个问题：如果你的模型今天开始“胡说八道”，你的系统能兜住多少？

关键词： 大语言模型， LLM产品工程， AI产品设计， Prompt之外， 模型可观测性

事实核查备注： 需要核查：Granola/Cronulla 名称拼写；发言人是否为 Maddie；“you can't just one shot it”是否为 Mehedi Hassan 的原话；视频发布时间 2026-05-10