很多 LLM 项目“Demo 很惊艳，上线就崩”：要么成本不可控、要么延迟飙升、要么数据合规踩雷、要么 Agent 误操作。问题不在某个点，而在于上线前缺少一份系统性的检查清单。
很多 LLM 项目“Demo 很惊艳，上线就崩”：要么成本不可控、要么延迟飙升、要么数据合规踩雷、要么 Agent 误操作。问题不在某个点，而在于上线前缺少一份系统性的检查清单。
RAG 项目最容易陷入“瞎调参”：换 embedding、换向量库、换模型、加 prompt……但质量还是忽高忽低。真正有效的方式，是按影响链路从大到小、从最容易做的到最难的，做一条清晰的优化路线图。
RAG 项目最容易陷入“瞎调参”：换 embedding、换向量库、换模型、加 prompt……但质量还是忽高忽低。真正有效的方式，是按影响链路从大到小、从最容易做的到最难的，做一条清晰的优化路线图。
Agent 一旦能“调用工具”，就从聊天升级成了能动手的系统。风险也随之升级：发错一封邮件、删错一条数据、误触发一次付费操作，都可能是真实事故。
Agent 一旦能“调用工具”，就从聊天升级成了能动手的系统。风险也随之升级：发错一封邮件、删错一条数据、误触发一次付费操作，都可能是真实事故。
Agent 热起来之后，大家会很快踩到一个坑：模型“会说”不等于“会做”。要让它做事，就得让它调用工具：搜索、数据库、工单、内部 API、文件系统……
Agent 热起来之后，大家会很快踩到一个坑：模型“会说”不等于“会做”。要让它做事，就得让它调用工具：搜索、数据库、工单、内部 API、文件系统……
很多团队把 Prompt 当成“随手改改的字符串”，最后会遇到同一个灾难：效果变差了，但你不知道改了什么；成本升高了，但你不知道为什么；线上翻车了，也没有回滚按钮。
遇到“知识不准/幻觉/记不住”的问题，很多团队会在两条路里摇摆：
当你接入 LLM 之后，“失败”经常不是代码写错，而是系统在告诉你：你需要节流。但很多业务的第一反应是“加重试”，最后变成：失败 → 重试更多 → 更失败 → 雪崩。
当你接入 LLM 之后，“失败”经常不是代码写错，而是系统在告诉你：你需要节流。但很多业务的第一反应是“加重试”，最后变成：失败 → 重试更多 → 更失败 → 雪崩。
很多人把“流式输出”理解成“更快”。但在工程上，流式真正的价值是：把一次长调用切成可持续交付的片段，从而让你拥有 更好的体验控制（更低 TTFT）、更强的可取消性（随时 stop）、以及 更细粒度的观测（首字慢？中途卡？尾部慢？）。
很多人把“流式输出”理解成“更快”。但在工程上，流式真正的价值是：把一次长调用切成可持续交付的片段，从而让你拥有 更好的体验控制（更低 TTFT）、更强的可取消性（随时 stop）、以及 更细粒度的观测（首字慢？中途卡？尾部慢？）。
很多 LLM 应用“能用”和“好用”之间，差的不是模型，而是工程指标：你到底在保证什么？是总耗时？首字时间（TTFT）？还是在高峰期的可用性？
很多 LLM 应用“能用”和“好用”之间，差的不是模型，而是工程指标：你到底在保证什么？是总耗时？首字时间（TTFT）？还是在高峰期的可用性？
“Token × 单价”只能回答“这次调用花了多少钱”，却回答不了更重要的问题：钱花在哪、为什么花、值不值、还能不能更省。当你进入生产环境，真正需要的是 LLM FinOps：像管理云成本一样管理模型成本。
“哪个模型更好”这种问题，最怕用“我感觉”来回答。因为模型效果会随：提示词版本、温度参数、上下文长度、业务数据变化而波动；如果你没有一套可复现的评测框架，今天选的“最好”，下周可能就变成“翻车最多”。
很多团队的 LLM 接入会经历同一个演进：先接一个最顺手的模型 → 业务做起来后发现“不是所有请求都值得用同一个模型” → 开始出现“按场景选模型、按成本控调用、按稳定性做兜底”的需求。
很多团队的 LLM 接入会经历同一个演进：先接一个最顺手的模型 → 业务做起来后发现“不是所有请求都值得用同一个模型” → 开始出现“按场景选模型、按成本控调用、按稳定性做兜底”的需求。