按 Quick 组件做提示工程：模式与陷阱

AWS ML Blog 2026-09-30T06:22:23.744168

在本系列第一部分，我们介绍了 Amazon Quick 中提示工程的基础原则：具体明确、设定上下文、少样本示例，以及用于复杂请求的 CRISPE 框架。这些原则普遍适用。本文将逐个组件拆解，展示每个 Quick 功能如何以不同方式理解提示，以及各类提示模式在哪些场景下效果最好。你可能用 Amazon Quick Research 做市场分析，用 Amazon Quick Flows 做自动化，用 Amazon Quick Sight 做数据可视化，用聊天代理访问团队知识，或用动作集成打通跨系统工作流。不论你的目标是什么，下面这些技巧都能帮你从泛泛的输出，走向精准、可落地的结果。

Quick Research

想从 Amazon Quick Research 得到有用的输出，关键看你如何界定研究目标。代理会接收你的目标，拆成多个子主题，在企业数据和外部来源中检索，最后给出一份带引用的结构化报告。目标含糊，报告就浅；目标具体，报告就能指导行动。

明确目标、受众和重点领域

AWS 文档说得很直白：“要具体说明你想达成什么、为谁做、为什么做。”一个有力的研究目标会点明主题、限定时间范围、确定受众，并告诉代理哪些输出最重要。

示例：

分析过去 12 个月美国医院系统对生成式 AI 的采用情况。
重点关注两个领域：临床决策支持工具
和行政自动化（排班、计费、病历管理）。

为医疗 IT 高管撰写研究结论，帮助他们决定下一步把预算投向哪里。这个目标同时告诉智能体三件事：该调查什么、该用什么视角、读者真正关心什么。Quick Research 会借助这些背景信息拆解子问题、挑选合适的数据源，并围绕你的实际需求组织报告结构。动笔写目标之前，先问自己：这项研究要支撑什么决策？谁会读它？他们看到什么内容才会觉得“这正是我需要的”？

把复杂话题拆成子问题

Quick Research 会自动把目标拆成子话题，但如果你自己也做一部分拆解工作，效果会更好。面对多维度研究，把你想得到答案的具体问题列出来。这样智能体方向更清晰，跑偏的概率也更低。

限定来源范围，并检查研究计划

Quick Research 的数据来自企业内部数据（通过 Quick Index）、200 多家可信新闻媒体，以及 S&P Global、FactSet、IDC、美国专利数据和 PubMed 提供的高级数据集。输入目标后，选择要纳入哪些来源，再检查一下初步的研究计划。做竞品分析不需要 PubMed，做临床文献综述不需要新闻文章。缩小来源范围能让智能体更聚焦，也能减少噪音。

Quick Flows

一个工作流能帮团队省 5 分钟还是省 5 小时，差别往往就在于提示词怎么写。Quick Flows 能把一段白话描述变成自动化工作流，但你提供的具体程度、结构和背景信息，直接决定了最终产出。

把“做什么、何时做、在哪里做”说清楚

提示词含糊，流程就含糊。最常见的错误是只说你想要什么，却没说清楚怎么做、什么时候用、给谁用。

改前：“根据我们的销售数据生成一份报告。”改后：“每周一早上 8 点，从 CRM 中拉取上一周的销售数据，计算总营收和按销量排名前 10 的产品，生成一页 PDF 摘要，并发送到 sales-managers 邮件分发列表。”第二个提示词给 Quick Flows 提供了明确的抓手：时间安排、数据来源、具体计算、输出格式和交付目标。每个细节都对应流程中的一个步骤。

定义触发器时，要把时间表和条件都写清楚。“每周一早上 8 点”是明确的，“当有新数据到达时”就很模糊。要说清是哪个系统产生的触发、什么算“新数据”，以及触发了但并没有新数据时该怎么办。

把复杂逻辑写成编号步骤

如果工作流涉及两三个以上的操作，就把提示词写成编号序列。Quick Flows 支持条件分支、重复循环和用户输入，编号步骤天然对应它内部的步骤结构：

示例：构建一个流程，完成以下操作：

  1. 接收上传的费用报告（PDF 或图片）作为输入。

  2. 从文档中提取总金额、供应商名称、日期和费用类别。

  3. 如果总金额超过 500 美元，将其发送到财务团队的 Slack 频道进行审批。

  4. 审批通过后，将这笔费用记录到 Google Sheets 跟踪表中，包含所有提取的字段以及审批时间戳。这种结构让调试变得简单：如果第 3 步出了问题，你清楚该从哪里排查。通过对话迭代，而不是重写。借助 Quick Flows 的智能体运行时，你可以在初次搭建完成后通过对话来优化流程。不用重写整个提示词，只需给出有针对性的后续指令：例如：在第 2 步和第 3 步之间加一个步骤，检查数据源是否返回了结果。如果查询结果为空，就给我发通知，而不是……

继续其余流程。Quick Flows 会保留原始提示的上下文，所以后续调整都建立在已有内容之上。

Quick Sight

在 Amazon Quick Sight 中，你可以通过对话式查询来探索数据。组织分析请求时，需要指明业务问题、相关维度、需要的计算，以及可视化偏好。

分析类查询的结构

一条有效的 Quick Sight 查询包含以下核心要素：

只要漏掉其中任何一项，Quick Sight 就只能靠猜，结果往往是一张技术上没错、但帮不上什么忙的图表。

分析模式

时间序列：“把过去 12 个月的客户支持工单量按优先级画成堆叠折线图。再叠加一条总量趋势线，让我看清整体负载是在上升还是下降。”

对比分析：“比较 2025 年第四季度各行业垂直领域和销售代表的平均成交金额。用分组柱状图展示，按成交金额降序排列，并把平均金额低于 5 万美元的垂直领域高亮出来。”

关系分析：“画一张客户终身价值与产品使用频率的散点图。按订阅等级给点着色，再加一条回归线，让我看出使用频率对 LTV 的预测强度。”

分布分析：“生成过去六个月项目完成时间的直方图。以两周为区间，叠加目标完成时间的垂直参考线，并标出超过 20% 项目落入的区间。”

地理分析：“展示一张北美客户分布热力图。

用颜色深浅表示收入集中度，再给占比超过总收入 10% 的地区加上数据标签。

优化图表与创建计算字段

使用 Topics（为对话式查询优化的精选数据集合）时，提问要围绕业务结果，而不是数据操作。别问「给我看一张用户数量表」，改问「哪些客户群体对我们移动应用的参与度最高？用日活用户数和会话时长来衡量。」

生成初始图表后，通过对话式追问来优化：换图表类型、加筛选条件、改聚合方式，或者要求添加计算字段。公式可以直接用自然语言描述。

示例：「添加一个名为『客户健康度评分』的计算字段，综合续约概率（权重 40%）、产品使用趋势（权重 35%）、支持工单频率（权重 25%，反向计算——工单越少越健康）。用 0–100 的指数展示。」

Quick 聊天代理

Amazon Quick 聊天代理把对话式 AI 引入你的组织。你可以控制代理的身份，把它接入公司的知识库，设定行为边界，再发布给团队使用。体验好坏，取决于你把代理配置得多细致。

明确代理身份

Builder Mode（构建模式）里的身份字段，决定了每一条回复的基础。好的身份设定要写明角色、专业领域，并划清边界。

示例：你是我们 FinOps 团队的云成本优化顾问。你的专长是……

涵盖 AWS 成本管理、预留实例规划、节省计划分析，以及资源合理配置。只回答云成本优化相关的问题。

如果问题超出这个范围，要明确说明，并建议对方联系合适的团队。没有这类边界，代理往往会用自信但不可靠的回答去应对自己不熟悉的问题。随着团队需求变化，要定期审查代理的身份定义。六个月前写好的身份描述，可能已经不再反映当前的优先级、工具或组织结构。把知识接对，并设置好护栏。将 Quick Spaces 连接到代理，决定了它能获取哪些信息。要谨慎选择：一个连接了组织内所有 Quick Space 的代理，会拿出不相关的内容。知识来源要和代理的职责匹配。同样重要的是，要告诉代理在找不到答案时该怎么做。没有明确指示，代理就会用看似合理但编造出来的内容填补空白。示例：当你没有足够信息来有把握地回答时，回复：

“我的当前知识库里没有这个信息。请联系[相关团队]，或查看[具体资源]获取最新指引。”绝不要猜测或编造。

还需要定期检查连接的 Quick Space。过时的文档比没有文档更糟糕，因为智能体会自信地引用它。团队知识更新后，要及时删除陈旧来源、补充新内容。

设计能培养好习惯的建议提示

建议提示是用户最先看到的内容，既设定了预期，也示范了智能体最擅长处理的提问方式。像“问我关于成本的问题”这样含糊的建议，会让用户也学会写含糊的提示。具体的建议则能培养更好的习惯：

示例：“我们生产账户中哪些 EC2 实例系列过去 30 天利用率最低？如果调整到合适规格，能省下多少钱？”

示例：“把我们的按需 RDS 用量改成 1 年期预留计划或 3 年期节省计划，成本影响分别如何？哪个方案在节省和灵活性之间平衡得最好？”

动作集成

通过动作连接器，Quick 可以与 Jira、Slack、Confluence、Salesforce 等外部系统交互。有效的动作提示要包含清晰意图、所有必要参数和正确的执行顺序。

参数说明

一次性提供所有必需信息。参数不完整会迫使系统追问或自行假设：

示例：

创建一个 Jira 问题，包含以下信息：

动作顺序

用清晰的依赖关系组织多步骤工作流。给步骤编号，说明条件，并明确哪一步的输出会进入下一步：

示例：

按顺序执行以下步骤：

  1. 在‘产品文档’Confluence 空间中搜索关于[主题]的现有页面。
  2. 如果页面存在，用新内容更新它，并添加修订说明。
  3. 如果页面不存在，用我们的标准模板创建一个。
  4. 把变更（或新建内容）的摘要发布到 #product-docs Slack

操作审查的处理方式

对于破坏性或批量操作，提示词里要设计一个执行前的审查环节。让系统先生成一份摘要报告，只有你明确批准后才真正执行。修改工单、删除记录、向外部相关方发消息这类操作尤其要注意。审查步骤要直接写进提示词里，不能只靠系统层面的保护机制。

常见坑点

了解常见错误，能让你少踩坑，在各组件上都更顺畅。

通用坑点

各组件特有的坑点

Quick Research

Quick Flows

Quick Sight

聊天代理

操作集成

把经验用起来

可以分阶段开始实践这些方法：

第一周：打基础

找出你最常用的三个 Quick 使用场景。用第 1 部分介绍的 CRISPE 框架重写现有提示词。把改写前后的结果记录下来。

第二周：聚焦组件

选一个 Quick 组件（Quick Research、Quick Flows、Quick Sight 或 Quick 聊天代理）。把本文中该组件的模式用到实际工作流程里。

创建可复用的提示模板。第 3 周：进阶技巧。在知识库中实现元数据驱动的检索。用 ARCHITECT 框架搭建自定义智能体。创建带条件逻辑的复杂 Quick Flow。第 4 周：规模化与共享。把最有效的提示整理进共享库。对团队成员进行成功模式的培训。建立反馈机制，持续改进。结论：Quick 的每个组件都有自己的长处和脾气，但底层原则始终一致：你把意图表达得越精准，输出质量就越高。Quick Research 需要清晰的目标和受众背景。Quick Flows 需要编号步骤，以及明确的触发条件和判断条件。Quick Sight 需要结构化查询，并定义好指标和维度。智能体需要鲜明的身份定位和清晰的边界。Action 需要完整的参数和正确的执行顺序。本文和上篇给出的这些提示模式只是起点，不是死板模板。用得多了，你自然会摸清每个组件最适合什么样的提示。你会逐渐体会到：Quick Research 智能体在受众定义精准时表现最好；Quick Flows 必须写清楚错误处理；Quick Sight 查询用上命名聚合类型效果更佳；聊天智能体的知识范围收窄后表现更优。把有效的做法记录下来，分享给团队，不断迭代。从 AI 中获得最大收益的组织，靠的不是最先进的技术，而是学会了如何与 AI 有效沟通。

下一步

准备继续打磨你的提示工程实践？可以从这些地方入手：

克隆示例代码

GitHub 上的 aws-samples/sample-quicksuite-kiro-quickstarts 仓库提供了 Quick API 脚本和模板，可以直接拿来作为起点。

关于作者

Daiquan N'kere

Daiquan 是 AWS 的技术客户经理，同时担任 AI/ML 业务应用专家。他与企业客户一起设计云上架构，推动客户的数字化转型。工作之外，他喜欢到世界各地探索新的目的地，陪伴家人，或者泡在博物馆里感受艺术与历史。

Praney Mahajan

Praney 是 AWS 的高级技术客户经理，作为战略顾问服务重点企业客户。他热衷于把技术方案与业务成果打通。闲暇时喜欢带家人长途自驾，也爱打板球。

Vishnu Elangovan

Vishnu 是 AWS 全球智能体 AI（Agentic AI）解决方案架构师，在应用 AI/ML 与深度学习领域有十多年经验。他喜欢构建、把玩可扩展的 AI/ML 方案，自称终身学习者。他在 AI/ML 社区里是公认的意见领袖，经常在重要 AI 会议上演讲，并在顶级活动中分享智能体 AI 方面的经验。

Dalien Ahiekpor

Dalien 是 AWS 的高级客户经理，负责旅游与酒店行业的企业客户。在转任现职之前，他做了四年技术客户经理，因此每次与客户打交道，都能兼顾技术深度和商业判断。他热衷于帮助客户利用云技术重塑宾客体验。

查看原文