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