2026年9月14日，AWS机器学习博客发布了一篇题为”生成式AI定制光谱：从提示工程到AWS上的定制模型”的技术文章。

这篇文章乍看是一个技术指南，讲述企业在使用生成式AI时应该如何选择适合的定制方法。但仔细阅读会发现，它的核心价值不是告诉你”应该怎么做”，而是揭示了企业AI项目中反复出现的两种典型错误决策模式——以及为什么这两种错误如此常见。

两种错误，各有各的昂贵

AWS文章的开篇即直击要害：

“团队经常在一个提示工程就能在一个下午解决问题时，就直接跳到微调。另一些团队在他们的使用场景明显需要领域专业训练数据时，仍死守在提示工程上困了好几周。这两种错误都付出了真实的代价。”

这不是夸张。企业AI项目中的定制决策失误，确实正在造成两类截然不同但同样昂贵的损失：

过度工程化（Over-engineering）：

以一个典型场景为例：某企业想让AI助手回答关于公司政策的问题。正确的解决方案是把政策文档导入RAG，需要3天实施，成本几乎为零。

但这个企业决定”做得专业一点”，决定用公司内部问答数据对模型进行微调。这需要标注1000+个问答对（2个月），准备SageMaker微调环境（1周），进行3轮超参数调整（3周），最终生成一个”公司专属模型”，部署在专用端点上。

总耗时：3个月。总成本：工程师人力成本+SageMaker训练费用，估计超过20万美元。

结果：性能与RAG方案相比，提升可以忽略不计——因为模型微调优化的是”语言风格和输出格式”，但这个场景的核心需求是”从特定文档中检索准确信息”，这是RAG的强项而非微调能解决的问题。

投入不足（Under-investing）：

另一个典型场景：一家制造业企业需要AI系统识别生产线设备的故障模式——这些故障模式在通用预训练数据中几乎不存在（设备型号是内部专有的，故障描述使用公司内部术语）。

这个团队用了提示工程：写了一个详细的系统提示，列出了常见故障模式和对应的维修建议，期望AI能举一反三。他们在这上面花了3周，反复调整提示词，尝试了dozens种不同的格式和示例。

结果：准确率始终无法突破60%——因为这个任务的核心需求是”领域专有知识内化”，这需要模型在公司的历史故障数据上进行微调或继续预训练。用提示工程去解决一个微调才能解决的问题，就像试图用Google Maps的搜索框来导航一条地图上根本不存在的小路。

8步阶梯：不是选项，是递进门槛

AWS框架将生成式AI定制分为8步，分属3个类别：

USE类（不改变模型，改变与模型的对话方式）

步骤1：直接使用——调用基础模型，不做任何定制。这是起点，也是大多数概念验证阶段的正确选择。 步骤2：提示工程——通过系统提示、少样本示例、思维链推理提升性能。AWS特别指出，当提示工程需要跨数百个生产工作负载扩展时，Bedrock的提示评估工具可以量化提示质量。

ENHANCE类（模型权重不变，在模型外部添加能力）

步骤3：RAG（检索增强生成）——用你的文档为模型提供上下文。AWS明确指出：大多数工作负载不需要超过这一步。RAG是提示工程和模型训练之间效果/成本比最高的方案。 步骤4：提示缓存——对重复的上下文片段（如系统提示、长文档）缓存处理结果，降低延迟和成本。 步骤5：知识蒸馏——将大模型的能力蒸馏到更小、更快的模型中。适合需要极低延迟或边缘部署的场景。

TRAIN类（直接修改模型权重）

步骤6：微调（Fine-tuning）——用标注数据更新模型权重，适合特定输出格式或专业领域的一致性要求。 步骤7：继续预训练（Continued Pre-training）——用大量非标注领域数据扩展模型的基础知识，适合高度专业化的垂直领域（如法律判例、医疗文献）。 步骤8：从零训练（Amazon Nova Forge）——完全自定义模型，从数据到架构完全控制。这是大多数企业永远不需要走到的最后一步。

框架的核心原则，AWS反复强调：从步骤1开始。只有在当前步骤无法满足你的精度、延迟或领域要求时，才升级到下一步。

为什么企业总是绕过这个阶梯？

AWS框架看起来逻辑清晰，但现实中企业总是跳过阶梯，直接跳到看起来更”专业”的高层级定制。为什么？

原因1：技术人员的”知识陷阱”

对于有深度学习背景的工程师，”微调”是一个比”提示工程”更有技术含金量的词汇。在学术和研究环境中，微调是正统的模型适配方式，提示工程有时被视为”走捷径”。这种认知偏差在企业AI项目中导致了系统性的过度工程化——工程师倾向于选择技术上更复杂的方案，即使更简单的方案完全够用。

原因2：供应商利益驱动

生成式AI服务链中，帮助企业进行微调和自建模型的咨询顾问、云服务提供商，往往比帮助企业做提示工程的顾问收取更高的费用。这创造了一个市场激励错配：服务提供商有动力推荐更复杂的解决方案，因为这产生更多计费时间。

原因3：”一步到位”思维

企业决策者害怕频繁切换技术方案，倾向于”一步到位”选择一个长期解决方案。提示工程被认为是临时性的（”以后还要升级微调”），而微调被认为是”最终形态”。这种思维导致很多企业跳过了完全够用的中间步骤，在还不确定需求的阶段就提前锁定了高成本方案。

第3步是分水岭，大多数企业在这里做出了错误选择

AWS在文章中特别强调了步骤3（RAG）的重要地位：这是大多数企业工作负载的”终点”——能解决80%以上的问题，以较低的成本和几乎不需要模型训练数据。

这个判断有行业数据支撑。AWS在文章中明确写道：”大多数工作负载不需要超过第3步（RAG）”——这句话直接来自AWS ML博客原文，是AWS基于Bedrock客户实际部署模式的观察结论，而非理论推断。

在实际的企业AI项目部署中，我们观察到一个反直觉的现象：能够正确实施生产级RAG的团队，比选择直接微调的团队少得多。

这听起来矛盾——RAG明明更简单，为什么选择它的团队反而更少？

原因在于：好的RAG实施并不简单。高质量的RAG需要：文档清洗和分块策略设计、合适的向量化模型选择、混合检索（语义检索+关键词检索）的优化、以及答案生成的提示工程配合。这些工作需要经验和调试时间，没有”开箱即用”的完美解决方案。

很多团队在RAG调试阶段遇到准确率瓶颈，然后得出结论：”RAG不够好，我们需要微调。”但实际上，他们的RAG质量问题通常是文档处理或检索策略问题，而非需要微调才能解决的。

AWS的框架提醒我们：在升级到下一步之前，先确保当前步骤的实施质量达标。如果步骤3的RAG表现不好，先优化RAG，而不是跳到步骤6微调。

对企业AI战略的实际影响

AWS这篇文章发布时，正值AI减速讨论最热烈的时刻——Amodei/Altman/Musk三人同周发声，芯片股集体暴跌。

但这个时间节点的吻合恰恰有其深意：当AI基础设施投资开始面临”可持续性”拷问，企业对AI定制的投入也需要重新审视资本效率。

如果过去18个月企业AI项目的核心问题是”我们能不能做”，那么接下来的18个月，问题将转变为”我们应不应该这样做，有没有更经济的方式”。

AWS的8步框架在这个时间节点发布，给出了一个明确的信号：在AI定制的成本与收益权衡中，从最简单的方案开始，只在必要时升级，不只是一个技术建议，更是一个商业理性原则。

对于正在规划AI定制投入的企业决策者，这个框架提供了一个简单的自我测试：

你的团队在准备微调之前，有没有认真地把步骤3（RAG）的所有优化选项用尽？

如果答案是否，那么在启动微调预算之前，先回到步骤3，重新把它做好。很可能你根本不需要步骤6。

AWS为什么现在发布这个框架？

这个问题值得认真思考。AWS作为全球最大的云基础设施提供商，发布一个”大多数情况下只需要第3步”的框架，表面上看似乎在自己打自己的脸——少卖微调和训练服务。

但从商业逻辑看，这恰恰是AWS最聪明的策略之一。

过去18个月，企业AI项目的失败率居高不下，据行业研究，超过70%的企业AI概念验证从未进入生产阶段。失败原因之一，是项目初期定制决策错误导致成本失控，进而导致预算被砍和项目搁置。

对AWS来说，一个使用5年RAG的企业客户，带来的AWS收入远超一个做了3个月微调然后放弃整个项目的企业客户。帮助企业做对决策，比卖给企业错误的解决方案更能持续产生收入。

这是一个”成功客户驱动增长”的逻辑：如果AWS帮助企业以正确的方式、合理的成本实现AI落地，这些企业会继续加大对AWS的投入，并向同行推荐AWS。这比通过复杂化方案争取短期高价项目可持续得多。

AWS的8步框架，是这个逻辑的具体体现：它不是在帮AWS卖更多高价服务，而是在帮助客户建立可持续的AI战略。而可持续的客户，才是AWS最有价值的长期资产。

生成式AI定制的光谱，从最简单到最复杂，跨越8步，三大类别。但框架最重要的洞察不在于那8步的描述，而在于它背后的一个朴素原则：你不需要的复杂度，是成本而非能力。

在AI基础设施投资”可持续性”成为新主题的今天，这个原则适用范围远不止于技术定制决策——它是一种关于资本效率的思考方式，提醒每一个AI项目团队：在跳到下一步之前，先把当前这步做好。

参考资料

  1. The generative AI customization spectrum: From prompt engineering to custom models on AWS, AWS ML Blog, 2026-09-14, https://aws.amazon.com/blogs/machine-learning/the-generative-ai-customization-spectrum-from-prompt-engineering-to-custom-models-on-aws/
  2. Amazon Bedrock documentation, https://aws.amazon.com/bedrock/
  3. Amazon Nova Forge custom model training, https://aws.amazon.com/bedrock/nova/
  4. Prompt optimization with Amazon Bedrock, https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-management-optimize.html