1. 项目概述：一份面向实干派的AI工程速查手册

如果你正在构建一个AI应用，无论是想用大语言模型做个智能客服，还是想设计一个能自动处理数据的智能体，大概率都经历过这样的时刻：面对海量的技术选项、层出不穷的框架和模棱两可的“最佳实践”，感到无从下手。到底该用哪种提示工程技巧？RAG系统该怎么设计才不“掉链子”？单智能体还是多智能体架构更适合我的业务场景？这些问题往往没有标准答案，但每一个选择都直接关系到项目的成败和后期维护的复杂度。

这就是我最初创建这个AI工程速查手册合集（louisfb01/ai-engineering-cheatsheets）的初衷。它不是一个面面俱到的教科书，而是一个工具箱，更准确地说，是一套“决策辅助工具”。它的目标非常明确：在你遇到最常见的AI工程难题时，能快速打开对应的表格，根据你当前的具体情况（比如数据量、实时性要求、预算、团队技能），找到那个最可能行得通的推荐方案，然后立刻动手去试。我自己在带团队和做咨询时，发现很多工程师和产品经理卡就卡在“选择”这一步，反复论证，浪费时间。所以，我把这些年在实际项目中验证过的路径、踩过的坑，都浓缩成了几张表。

这个合集目前核心包含三份指南：《AI工程实战手册》、《智能体架构指南》和《反套路AI写作指南》。每一份都试图解决一个特定层面的决策问题。比如，《AI工程实战手册》帮你从宏观上选择技术栈；《智能体架构指南》帮你厘清智能体设计的底层逻辑；而《反套路AI写作指南》则聚焦于一个非常具体但恼人的问题——如何让AI生成的文本听起来不像AI写的。它们都来自真实的项目需求，不是为了炫技，而是为了能用、好用。

2. 核心内容深度解析：三份指南如何解决实际问题

2.1 AI工程实战手册：从技术选型到生产部署的路线图

这份手册是整个合集的基石，它覆盖了一个AI项目从构思到上线的全链路决策点。很多教程只讲“怎么做”，但这本手册先帮你决定“做什么”和“用什么做”。它的核心是一系列决策表，你可以把它想象成一套诊断流程。

第一张表：技术路径选择。 你首先需要判断手头的问题，更适合用传统的机器学习模型、微调后的大模型，还是直接用提示工程（Prompting）搞定？这里没有银弹。手册里会列出一系列关键问题：你的数据是结构化的还是非结构化的？标注成本有多高？对预测结果的解释性要求强不强？变更频率如何？举个例子，如果你要做的是一个根据用户历史行为预测其偏好的推荐系统，数据规整且量大，那么传统的梯度提升树模型（如XGBoost）可能比动用一个大语言模型更高效、更经济。但如果你要处理的是来自客服对话的复杂语义分析，那么LLM的上下文理解能力就无可替代。这张表的价值在于，它迫使你在写第一行代码前，先进行一次冷静的技术经济性评估。

第二张表：提示工程策略矩阵。 当你确定要使用提示工程后，面对Few-Shot、Chain-of-Thought、ReAct等众多技巧，该怎么选？手册不会空谈理论，而是提供了一个场景化的对照表。例如，如果你的任务是“从一篇长文中提取特定格式的信息”（信息抽取），那么“给出输出格式示例”（Few-Shot）结合“分步思考”（Chain-of-Thought）通常效果最好。如果你的任务是“基于已知规则进行逻辑推理或决策”，那么让模型模拟“思考-行动-观察”循环的ReAct模式可能更合适。表格里会明确指出每种策略的适用场景、所需的最小示例数量、以及对提示词长度的敏感度，这些都是实践中真金白银换来的经验。

第三张表：RAG架构配置指南。 检索增强生成（RAG）现在是构建知识库应用的标配，但为什么别人的RAG回答精准，你的却总是“胡言乱语”？问题往往出在细节配置上。这份指南会拆解RAG的每一个环节：文档分块策略、向量化模型选择、检索器类型、重排序（Re-ranking）是否必要、以及如何设计上下文注入的提示词。一个关键的决策点是分块大小和重叠度。对于技术文档，可能适合按章节或子标题分块；对于连续的叙事文本，则可能需要滑动窗口式分块并设置一定的重叠，以避免在块边界丢失关键信息。手册会给出基于文本类型和查询复杂度的推荐参数范围。

第四部分：生产环境配置清单。 这是很多原型项目忽视的一环。手册会列出从开发到生产必须考虑的事项，例如：如何设置有效的监控（不仅仅是延迟和费用，更重要的是回答质量漂移）、回退策略（当LLM API调用失败或返回质量过低时怎么办）、缓存策略（对常见查询结果进行缓存以降低成本和提高速度）以及版本管理（如何管理提示词、模型版本和知识库的变更）。这部分内容能帮你避免项目“见光死”，确保它能在真实用户流量下稳定运行。

2.2 智能体架构指南：在工作流与自主智能体之间做选择

智能体（Agent）是当前AI应用开发的热点，但“智能体”这个词被用得太泛了。这份指南首先帮你正本清源：你需要的到底是一个自动化工作流，还是一个具有自主决策能力的智能体？

核心决策框架：工作流 vs. 单智能体 vs. 多智能体。 指南通过一系列问题来引导你做出选择：

1. 任务是否线性、可预定义？ 如果任务的每一步都是确定的，像“获取数据A -> 清洗数据A -> 分析数据A -> 生成报告”这样，那么一个编排好的工作流（可以使用LangChain、LlamaIndex的链或工作流引擎）就足够了。它稳定、高效、易于调试。
2. 是否需要根据中间结果动态决定下一步？ 如果任务路径不确定，比如“分析这篇市场报告，找出潜在风险并提出应对策略”，AI可能需要先总结、再识别风险点、然后针对不同风险点搜索不同的资料，这个过程是动态的。这时，一个具有规划能力的单智能体（采用ReAct、Plan-and-Execute等模式）更为合适。
3. 问题是否非常复杂，需要多个“专家”分工协作？ 如果是设计一个复杂的软件系统，可能需要“产品经理”智能体定义需求、“架构师”智能体设计模块、“程序员”智能体编写代码，并且它们之间需要对话和协调。这就是多智能体系统的用武之地。指南会明确指出，多智能体系统复杂度呈指数级增长，会带来通信开销、一致性保证和“群聊失控”等新挑战，除非必要，不应轻易选择。

工程规则与信号。 这是指南中最具实操价值的部分。它告诉你，在开发过程中，应该关注哪些“信号”来判断你的架构选择是否正确。例如，对于工作流，如果频繁需要人工干预来处理异常分支，那就是一个信号，表明你可能需要引入一些智能体的决策能力。对于单智能体，如果它的“思考”（即调用LLM进行规划）步骤消耗了超过70%的token和延迟，这就是一个信号，提示你可能需要将部分固定逻辑下沉到确定性的函数中。对于多智能体，如果智能体间的对话轮数无限增长却无法达成共识，这就是一个需要引入仲裁机制或更严格议事规则的信号。

2.3 反套路AI写作指南：让机器输出拥有“人味儿”

几乎所有用过LLM写作的人都有一个痛点：生成的文字有一股明显的“AI味”，生硬、空洞、喜欢用“总之”、“综上所述”、“值得注意的是”等套话。这份指南提供了一套完整的解决方案，目标是把AI从一个小学生作文生成器，变成一个靠谱的写作助手。

七段式提示词模板。 这不是一个简单的指令，而是一个结构化的创作蓝图。它通常包含以下部分：

1. 角色与目标 ：明确赋予AI一个具体的身份（如“一位有10年经验的科技专栏作家”）和本文要达成的具体目标（如“写一篇向初学者解释RAG的博客，要求生动有趣，避免技术黑话”）。
2. 核心指令与禁忌 ：明确提出“避免使用任何陈词滥调和明显的AI生成句式”，并附上一份“禁用词列表”，比如“赋能”、“抓手”、“打通”、“闭环”、“值得注意的是”、“总的来说”等。这一步至关重要，是从源头遏制“AI腔”。
3. 风格与语气参考 ：提供一段你希望模仿的人类作者的文字片段作为风格锚点。例如，“请模仿下文简洁、略带幽默和举例丰富的风格：……”。
4. 内容大纲与关键点 ：不是让AI自由发挥，而是给出清晰的段落结构和每个段落必须涵盖的2-3个核心论点。这能确保内容不跑偏，逻辑严密。
5. 事实与数据源 ：如果文章涉及具体数据或案例，在此处提供，并要求AI只使用这些信息，杜绝编造。
6. 修改与润色指令 ：要求AI完成初稿后，以“编辑”的身份重新审阅全文，重点检查流畅度、去除冗余、强化关键论点之间的过渡。
7. 输出格式 ：明确最终的格式要求，如Markdown、带特定层级的标题等。

双模型工作流：写手与编辑。 指南推荐了一个非常实用的技巧：不要指望一个模型一次性完成所有工作。可以先用一个成本较低的模型（如GPT-3.5-Turbo）作为“写手”，根据上述模板生成初稿。然后，用一个更强大、更擅长理解和遵循复杂指令的模型（如Claude 3 Opus或GPT-4）扮演“编辑”，对初稿进行润色、批判性审查和风格强化。这个“写而后审”的流程，在成本和质量的平衡上，往往比单纯使用一次顶级模型效果更好。

3. 如何将速查手册融入你的开发流程

这些速查手册不是用来通读的，而是用来即查即用的。关键在于将其集成到你团队的标准开发流程中，使其成为决策节点上的“检查点”。

在项目立项与设计阶段。 当产品经理提出一个AI功能需求时，技术负责人可以带着团队一起过一遍《AI工程实战手册》的第一部分“技术路径选择”。通过回答表格里的问题，快速形成技术方案雏形，并预估主要的复杂度和风险点。这能避免在错误的方向上投入大量资源。

在技术方案评审阶段。 在详细设计系统架构时，《智能体架构指南》里的决策框架和问题清单，可以作为架构评审会的讨论提纲。大家需要共同回答：“我们为什么选择工作流而不是智能体？指南中提到的哪些风险信号是我们需要提前设计监控的？” 这能让评审会更聚焦、更高效。

在开发与提示词工程阶段。 工程师在编写核心的提示词或设计Agent逻辑时，应随时翻阅对应的速查表。例如，在构建一个客服Agent时，可以参照《反套路AI写作指南》来设计其回复的语气和风格，避免生成机械化的回答；同时参考《AI工程实战手册》中的RAG部分，来优化知识检索的准确性。

在测试与上线前检查阶段。 手册中“生产环境配置”部分的内容，可以转化成一个上线前检查清单（Checklist）。运维和开发人员需要逐一确认：监控告警是否设置、回退方案是否就绪、缓存策略是否生效、成本监控是否到位。这能极大提高项目上线的成功率。

实操心得： 我建议将手册中最关键的决策表打印出来，贴在团队白板旁，或者做成团队Wiki的首页链接。让这些经过验证的决策框架成为团队共享的“思维习惯”，比任何复杂的流程都管用。我们团队在引入这个习惯后，关于技术方案的争论减少了至少一半，因为大家是在一个共同的框架下，用事实和场景（“你看，我们这种情况属于表格里的B2类，所以推荐方案是X”）来讨论，而不是各执一词。

4. 超越速查：从应用到精通的进阶路径

速查手册能帮你快速做出不差的决策，避免低级错误，但它不能替代深度的理解和系统的学习。手册中提到的很多概念，比如ReAct模式、向量检索的优化、多智能体通信协议，背后都有深厚的原理。

针对性的深入学习。 手册中每个推荐方案的旁边，其实都指向了一个更广阔的知识领域。如果你发现你的项目严重依赖于RAG，那么仅仅知道分块和检索的推荐参数是不够的。你需要深入理解嵌入模型（Embedding Model）是如何训练和评估的，为什么同样是768维的向量，有些模型在语义检索上就是比另一些好。你需要了解除了简单的余弦相似度，还有没有更先进的检索和重排序算法。这时，就应该转向更系统的课程、论文或专业书籍。

实践中的迭代与贡献。 这些速查手册本身是基于特定时间点的最佳实践和工具生态总结的。AI领域日新月异，新的模型、框架和模式不断涌现。最有效的使用方式，是把它作为一个“活”的基线。当你在自己的项目中尝试了手册的推荐方案，并发现了更好的做法，或者遇到了手册未曾覆盖的新场景时，这个经验就变得极其宝贵。你可以基于自己的实践去优化它，甚至可以向开源项目贡献你的案例。真正的AI工程能力，正是在这种“应用-学习-反思-优化”的循环中建立起来的。

建立你自己的知识库。 最终，你的目标不应该是永远依赖这份速查手册，而是以其为骨架，填充进你自己项目的血肉，形成属于你个人或团队的“AI工程决策知识库”。你可以为每个成功（或失败）的项目建立案例档案，记录当时面临的场景、做出的选择、依据的手册条目、实际的结果以及事后的复盘。这份不断增长的内部知识库，将成为你团队最核心的竞争力。它比任何公开的速查表都更贴近你的业务，更能指导你未来的决策。

5. 常见陷阱与实战排雷指南

即使有了清晰的指南，在实际操作中依然会踩坑。下面是一些我们和社区开发者经常遇到的高频问题及其解决思路，你可以把它们看作是对速查手册的补充注释。

陷阱一：盲目追求最新最热的架构。 看到多智能体（Multi-Agent）很火，就想把所有项目都改成多智能体，这是最常见的错误。多智能体引入了智能体间通信（协调、竞争、协商）的复杂度，调试难度大，运行成本也高。 排查思路 ：回归《智能体架构指南》的第一个决策问题：“你的任务是否可以由一个智能体通过序列化步骤完成？” 如果答案是肯定的，就坚决用单智能体或工作流。只有当任务本质是分布式、需要不同专长、且存在复杂协作时，才考虑多智能体。一个简单的判断方法是：你能画出这个任务的线性流程图吗？如果能，就别用多智能体。

陷阱二：RAG效果差，只会调大检索数量（k值）。 当RAG返回的答案不相关时，很多人的第一反应是增加检索到的文档块数量（比如把top-k从3调到10）。这通常会导致答案中注入更多无关噪声，让LLM更加混乱。 正确排查路径 ：

1. 检查分块（Chunking） ：你的文档分块方式是否破坏了语义完整性？尝试不同的分块策略（按段落、按标题、滑动窗口）和块大小。一个实用的技巧是，对分块后的文档进行摘要，看摘要是否还能准确反映原意。
2. 检查嵌入（Embedding）模型 ：你用的嵌入模型是否适合你的文本领域？通用模型（如text-embedding-ada-002）对通用文本不错，但对专业领域（如法律、医学）可能不佳。尝试领域专用的或微调过的嵌入模型。
3. 引入重排序（Re-ranking） ：在初步向量检索（召回）后，加入一个轻量级的重排序模型（如Cohere的Rerank，或开源的BGE-Reranker），对召回的Top N个结果进行精排，只将最相关的2-3个块注入上下文。这比单纯增大k值有效得多。
4. 优化查询（Query） ：用户的原生查询可能很模糊。可以先用一个LLM对查询进行改写或扩展，生成一个更利于检索的“搜索查询”。例如，将“它怎么工作的？”改写为“解释[产品名]的核心工作原理和主要步骤”。

陷阱三：提示词过长且无效，导致成本飙升、性能下降。 为了追求效果，把所有的指令、示例、背景知识都堆进提示词，很容易就超出模型的上下文窗口，或者让模型忽略关键指令。 优化策略 ：

1. 遵循“最小必要信息”原则 ：只提供完成任务必不可少的信息。将长篇的背景文档移到RAG的知识库中，让模型通过检索动态获取。
2. 结构化你的提示词 ：使用清晰的标记符，如 ## 指令 ## 、 ## 示例 ## 、 ## 数据 ## ，帮助模型解析。将指令放在最前面和最后面（模型对开头和结尾的内容更敏感）。
3. 进行提示词压缩 ：对于Few-Shot示例，尝试用更精炼的语言表达。有时，一个设计精巧的示例胜过三个冗长的示例。
4. 实施持续评估 ：建立提示词的评估机制，定期用一批测试用例检查其效果。如果效果下降，分析是提示词本身问题，还是外部知识库或数据发生了变化。

陷阱四：忽视生产环境的非功能性需求。 在原型阶段只关注功能实现，上线后才发现延迟太高、成本失控、或遇到流量高峰就崩溃。 上线前必查清单 ：

• 延迟与吞吐量 ：你的AI服务P99延迟是多少？能否满足用户交互体验要求（通常要求<2秒）？进行压力测试。
• 成本监控与优化 ：是否对每次LLM API调用的token消耗进行记录和监控？是否对高频且回答固定的查询设置了缓存？是否考虑使用阶梯式模型策略（如简单查询用便宜模型，复杂任务用昂贵模型）？
• 错误处理与降级 ：当LLM API服务不可用或返回错误时，你的应用是否有友好的降级方案（如返回预置的常见回答、或转接人工）？是否设置了合理的超时和重试机制？
• 可观测性 ：除了系统指标，你是否监控了AI特有的“业务指标”？例如，用户对AI回答的满意度（通过点赞/点踩）、回答的毒性或偏见分数、答案与检索源的一致性等。

陷阱五：对“反套路写作”指南的机械套用。 直接复制粘贴指南中的模板，但生成的内容依然生硬。 问题根源 ：模板是骨架，你需要注入灵魂。关键在于“角色”和“风格参考”这两个部分。赋予AI的角色必须足够具体（“一位为《纽约客》撰稿的科技史作家”就比“一位作家”好得多）。风格参考的文本，必须是你精心挑选的、真正符合你期望的样本。此外，禁用词列表需要根据你的行业和受众进行定制。金融领域的报告和科技媒体的快讯，需要禁用的“套话”是不同的。