文章指出，构建 LLM 应用需要从确定性系统思维转向概率性系统思维：输入与输出不再一一对应，用户可能以难以预料的方式使用系统。作者用“Vibes-Only Trough”描述 demo 阶段看似可用、但缺乏真实数据支撑的状态，并主张通过“数据驱动斜坡”逐步建立评测体系。核心方法是先定义可量化的成功标准，例如情感分类系统要求 92% 的人工标注一致率、95% 的请求在 500ms 内完成、高置信度预测与人类判断匹配率达到 90%。随后要从每个用户交互中收集数据，从简单的点赞/点踩按钮开始，逐步构建更复杂的数据管道。作者坦言第一版产品通常不会好，因为数据不足，波动是概率系统的固有属性，关键是系统化追踪每次迭代。适合正在把 LLM demo 推向生产的工程师，以及需要建立评测文化的团队。
在 LLM 应用中，输入与输出不再有确定性映射，任何小改动都可能改变全局行为。本文提出 Evals 是 AI 工程师的单元测试，也是从概率系统中压出可预测性的核心工具。文章拆解了三种评测方式：可写成断言的确定性 Eval、成本高但必要的人工评估，以及用另一个 LLM 打分的 LLM-as-a-Judge，并建议分层运行以控制成本。随后介绍数据飞轮：把用户的负反馈转成新的 eval 用例，形成持续改进循环。工具层面对比了云端平台 Braintrust 与作者维护的本地运行库 Evalite（基于 Vitest）。适合正在把 LLM 原型推向生产的工程师，用于建立可量化的质量反馈体系。
本文给出提升 LLM 应用性能的 17 种手段，并特意按实施成本从低到高排列成“复杂度地狱阶梯”：先改提示词、加角色设定、用 XML 标签和结构化输出，再尝试思维链、多示例、温度调节与工具调用；只有这些简单手段用尽后，才考虑 RAG、切块、智能体循环、并行调用、评估-优化器、路由器和微调。作者强调改善系统的本质是“先改进评估，再改进系统”，并给出可验证的 trade-off：CoT 以延迟换质量，智能体循环更灵活但每步决策更慢，路由器能绕过单模型约 30 个工具的限制但增加一次串行调用。适合正在做 LLM 应用迭代、需要一份按成本排序的优化清单的一线工程师。