六位一线AI工程师和创业者，把在大模型应用开发上摸爬滚打一整年的心得，全！分！享！了！
（奇怪的六一儿童节大礼包出现了）
这篇干货长文，一时间成为开发者社区热议的话题。
有网友评价为，大模型领域少有的“有操作性”的实用见解，非常值得一读。
这6位作者来自不同背景，比如有大厂工程师，也有独立开发者，还有咨询顾问。
但他们的共同之处，是过去一年里一直在大模型之上构建真实应用程序，而不只是炫酷的Demo演示，他们认为：
现在正是非机器学习工程师或科学家，也能把AI构建到产品中的时候。
在他们的一系列分享中，网友热议的亮点包括但不限于：
-何时用长上下文、何时RAG、何时微调模型
- 多样化输出不止提高温度，改变提示词中示例的顺序也影响结果
- 长上下文不会让RAG过时
- “实习生测试”：如果大学生能根据提示词完成任务，说明比较完善了
- 每个大模型都有自己的偏好，Claude更喜欢XML格式，GPT系列更喜欢Markdown和JSON
- 如果靠提示词已完成了90%的任务，微调可能就不值得投资
- 大模型当裁判评估结果可能起作用，但不是万能的
……
总之，无论是大厂工程师、创业者还是参加个人开发者，都值得一看。
全程高能干货分享
提示词、RAG和微调都是改善大模型输出结果的有效方法。
但是何时该用何种方法，还没有定论。
作者们认为，需要根据具体的应用场景、任务需求、成本效益和性能目标来做出决策：
- 建议在开发新应用程序时从提示词开始
- 需要大模型掌握新知识时优先使用RAG
- 当需要针对特定任务优化时再考虑微调
最后，他们还重点讨论了对大模型应用的评估和监测，认为是应该贯穿开发全流程的重要环节。
提示词篇
很多开发者都陷入了一个误区：以为设计一个涵盖一切的“终极提示词”就能完美解决问题。
就像过去软件开发中也有希望一个类或函数可以完成所有事情的误区。
实际情况恰恰相反，随着需求的复杂化，这样的Prompt会越来越臃肿，性能反而每况愈下。
那么正确的做法是什么呢？提示词也应该像代码一样保持简洁，以会议记录总结场景来说，可以分解为以下步骤：
- 将关键决策、待办事项和执行者提取为结构化格式
- 检查提取的详细信息与原始会议记录的一致性
- 从结构化详情生成简明摘要
通过拆分，每个提示词都简单、突出重点且易于理解，更重要的是接下来可以单独迭代和评估每个提示词。
比如思维链鼓励AI在最终回答之前写下思维过程，除了“一步一步思考”之外，还可以用一些技巧显著降低幻觉。
还以会议记录总结场景为例，迭代后的提示词示例为：
- 首先，在草稿中列出关键决策、待办事项和相关执行者。
- 然后，检查草稿中的细节是否与文字记录相符。
- 最后，根据要点合成简洁的总结。