在为工程领域专家构建大语言模型（LLM）应用的过程中，我总结出十条关键经验。这些经验来自与过程工程师、可靠性工程师、网络安全分析师等实际使用者的长期合作，核心在于：技术能力必须与真实工作流程、用户信任和实际价值紧密结合。 第一阶段：项目启动前 并非所有问题都适合用LLM解决 在考虑使用LLM前，先问自己：能否用规则引擎、分析模型或传统机器学习解决80%的问题？如果可以，应优先选择更稳定、可解释、低成本的方案。LLM适合处理非结构化文本理解、信息整合与生成，但不适用于需要精确数值结果或高确定性的任务。若处理量大、对延迟和成本敏感，LLM可能成为瓶颈。 从一开始就建立“增强而非替代”的思维 明确告诉工程师：LLM是“协作者”而非“替代者”。这能消除对岗位被取代的焦虑，提升参与度。当LLM出错时，讨论焦点从“AI失败”转向“这个建议有启发性，但需人工判断”，更易建立信任。 与专家共同定义“更好”的标准 早期邀请领域专家参与设计，深入了解他们的工作流程、痛点与容忍度。共同定义可衡量的改进指标，如缩短排障时间、减少误报数量或减少手动步骤。这不仅提供基准，也体现了对专家经验的尊重，是赢得信任的第一步。 第二阶段：开发过程中 打造“副驾驶”而非“自动驾驶” 避免一次性输出最终结论。应设计多阶段交互，让专家在关键节点介入，如确认事件分组逻辑、审核推理依据后再生成建议。虽然界面稍复杂，但增强了控制感与可信度。 先聚焦流程与数据流，再选框架 初期无需纠结LangGraph、AutoGen等框架。用基础API调用即可快速验证想法。将每个LLM调用视为一个函数（输入→推理→输出），通过常规编程逻辑串联，更灵活高效。框架可在后期迁移时引入，以提升可观测性与可维护性。 优先构建确定性工作流，而非盲目追求“智能代理” 工程领域已有成熟的工作流程。与其让LLM“重新发现”这些逻辑，不如将其编码为清晰、可解释的步骤流程。这能减少不确定性，提高可靠性，也更容易获得专家认可。 尽可能结构化输入与输出 不要直接喂给模型原始日志或报告。先提取关键信息为结构化格式（如JSON），再输入LLM。输出也应强制要求结构化（如Pydantic模型），便于后续集成与调试。结构化还能支持证据引用，提升可追溯性。 融合分析型AI与生成式AI 传统机器学习擅长模式识别、异常检测与聚类，应承担“重体力活”。LLM则用于解释结果、生成建议与撰写摘要。例如：先用聚类算法识别相似故障模式，再让LLM命名、解释并推荐排查路径。二者结合，效果远胜单一模型。 第三阶段：上线与落地 嵌入工程师的真实工作环境 不要只做一个独立的聊天界面。应将功能嵌入工程师日常使用的工具中，如在日志查看器中添加“总结事件”或“建议下一步”的按钮。界面设计应使用具体动词（总结、分组、对比），而非开放式对话。动态传递上下文（如当前查看的事件ID），减少重复操作。 持续评估，让系统“展示推理过程” 上线后真正的挑战才开始。系统必须清晰展示：它依据了哪些证据、经历了哪些步骤、信心水平如何。要求LLM在输出中注明证据来源与置信度（低/中/高），并附上理由。定期组织专家进行真实案例评估，观察工具在实际场景中的表现，持续迭代优化。 总结：成功的LLM工程应用，不在于技术炫酷，而在于尊重领域知识、构建可信赖的流程、嵌入真实工作流，并持续通过真实反馈进化。LLM不是万能钥匙，而是系统中一个关键但需精心设计的组件。