当你刚开始利用人工智能进行开发时，最响亮的声音都指向同一个地方：模型。他们说，只要选对了模型，其他一切都会迎刃而解。在进行了几周的实验后，我可以告诉你，事实并非如此。在现有的各种大语言模型中做出选择固然重要，但这可能只占工作的百分之二十。剩下的百分之八十是系统工程。它是基础设施建设、工艺打磨和不懈的测试。这个认识在我早期就已产生，并从那时起重塑了我处理每一个项目的方式。
模型仅仅是开始
初学者之所以痴迷于模型，原因显而易见。更新日志承诺了更强的推理能力、更大的上下文窗口和更整洁的输出。这些改进是真实的，但它们也是通用型的。最先进的模型并不会自动知道你公司的退款政策。除非你告诉它如何操作，否则它无法可靠地为你的移动应用格式化响应。它也无法凭空调取实时库存数据。
我曾通过惨痛的教训学到了这一点。我的第一个原型使用了一个能力很强的模型，它能生成优美、自信的段落，但偶尔会完全出错。由于模型已经掌握了语气，文本听起来非常专业，但它无法获取最新信息。我花了几天时间去对比模型基准测试，而我本该思考的是数据管道和上下文注入。模型本身没有坏，是围绕它的系统不完整。当你从演示 Demo 转向人们真正依赖的软件时，这种区别至关重要。
提示词是代码，而非建议
高质量的提示词（Prompts）是任何可靠 AI 应用的核心。早期，我把提示词当成搜索查询——简短、随意、乐观。我会要求模型“总结一下这个”或“提供帮助”，然后听天由命。结果在“有用”和“无关”之间剧烈波动，而我完全不知道原因。
现在，我把提示词视为轻量级程序。一个好的提示词会定义角色、指定输出格式、在必要时包含示例，并设定边界。如果我需要 JSON，我会要求 JSON 并展示其 schema。如果我需要简洁的回答，我会明确限制长度并禁止开场白。迭代至关重要。我会记录提示词及其输出的日志，每次只改变一个变量。提示词中一个模糊的形容词就可能改变整个工作流的行为。这种敏感性要求严谨，而非猜测。
垃圾进，垃圾出
可靠的数据检索是许多 AI 项目悄然夭折的地方。检索增强生成（Retrieval-Augmented Generation，简称 RAG）已成为让模型访问私有或实时数据的标准模式。其思路很简单：获取相关文档，将它们塞进模型的上下文窗口，然后让模型基于事实进行推理。但实际操作起来要复杂得多。
我曾花时间调试一个简单的知识库，它总是返回无关的结果。模型没问题，是检索层失效了。我的文本块（chunks）太小，且丢失了上下文。我的嵌入（embeddings）在生成时没有清理重复的标题。相似度搜索找到了在技术上接近、但回答了错误问题的文本。修复它意味着要重新思考分块策略、添加元数据过滤器并引入重排序（re-ranking）步骤。一旦检索稳定下来，模型的回答立即得到了提升。教训很明确：你无法通过使用更好的模型来修补糟糕的数据检索。你必须正确构建管道。
无法衡量，便无法改进
持续的评估是将“实验”转化为“产品”的习惯。刚开始时，我凭感觉评估。我会读五个输出，点头表示认可，然后继续。这种方法在用户问到第六个问题并得到奇怪答案时就会失效。
现在，我会为每个功能构建小型的评估集。我收集真实的用户查询，标注预期行为，并针对它们运行自动化检查。我会关注漂移（drift）：上个月还奏效的提示词，在模型更新或底层数据变化后可能会失效。我会将风格评估与事实准确性分开。看起来专业固然好，但做到正确是必须的。如果没有这个闭环，你就是在凭希望进行交付，而希望并不是一种测试策略。
了解机器的极限
理解模型的局限性让我免于过度承诺却无法兑现。这些系统存在真实的约束。上下文窗口比以前更大了，但它们仍然有上限，而且填得太满会导致边缘性能下降。模型会产生幻觉，尤其是在训练数据稀缺的小众话题上。它们在精确算术和某些类型的多步逻辑方面表现挣扎。它们对措辞非常敏感。
成本和速度也是限制因素。一个需要十秒钟才能生成完美散文的模型，在实时聊天界面中可能无法使用。我现在会尽早将功能与延迟预算进行匹配。如果任务需要亚秒级响应，我可能会预计算答案、进行激进的缓存，或者先用较小的模型生成初稿，仅在精修阶段才使用较大的模型。在约束条件下工作是标准的工程实践。AI 也不例外。
为真实用户构建
我目前正在研究 LLM 应用和软件工程，目标很简单：构建人们每天都在使用的工具。这听起来显而易见，但一个酷炫的原型与一个日常使用的工具之间存在巨大的鸿沟。演示（Demo）可以容忍 40 秒的停顿和冗长的回答，但一个试图在会议前完成任务的人则不能。
日常使用的工具需要错误处理、回退机制，以及在模型不确定时的清晰 UI。它们需要融入现有的工作流，而不是强加新的工作流。我现在会考虑边缘情况：当模型拒绝回答、上下文溢出或 API 超时时会发生什么？交付 AI 软件意味着要用代码来回答这些问题，而不仅仅是靠乐观。
分享我们的所学所思
我想与走在相同道路上的其他开发者建立联系。这个领域发展迅速，最佳实践仍在不断形成中。没有人掌握所有的答案。无论你是在苦苦钻研 prompt 设计、应对检索流水线，还是在研究如何大规模评估输出，共同解决这些问题会更有效。
让我们分享所学到的东西。不是那些经过润色的会议演讲，而是那些“混乱的中间过程”。失败的流水线、最终奏效的 prompt 微调、在发布前发现 bug 的评估测试。这种细致、诚实的交流，才能将个人的实验转化为共享的知识体系。
真正的启示
如果你刚开始从事 AI 开发，请少花时间去寻找