AWS发布Amazon Quick提示词工程分组件指南：Research、Flows、Sight、chat agents与action integrations各有写法
AWS机器学习博客刊出系列第二篇，按Amazon Quick的五个能力组件逐一说明提示词写法和常见错误，作者为Daiquan Nkere；文章基于AWS官方文档和示例，未给出效果实测数据。
AWS机器学习博客发布Amazon Quick提示词工程系列第二篇，作者Daiquan Nkere，标题为《Prompt engineering by Quick component: Patterns and pitfalls》。第一篇讲的是通用原则：具体化、设定上下文、少样本示例，以及用于复杂请求的CRISPE框架；这一篇按组件拆解，说明每个Quick能力如何以不同方式解读提示词，以及哪种写法能得到最好结果。
文章覆盖五个组件：用于市场分析的Quick Research、用于自动化的Quick Flows、用于数据可视化的Quick Sight、用于团队知识访问的chat agents，以及用于跨系统工作流的action integrations。原文没有提供各写法的效果对比数据或基准测试，示例均为提示词模板。
文章称目标是让输出从泛泛而谈转向精确可执行，并特别指出：没有效果数据，各组件提示词的收益取决于具体场景。
Quick Research：写研究目标而不是搜索词，并先圈定来源
Quick Research的工作方式是：接收目标，拆成子话题，在企业数据和外部来源中检索，最后交付带引用的结构化报告。文章称，含糊的目标产出浅报告，具体的目标产出可执行的内容。
AWS文档的原话被直接引用：“Be specific by stating what you want to achieve, for whom, and why.” 一个强的目标要命名主题、限定时间范围、指明读者，并告诉agent哪些输出最重要。
文章给出的示例目标：分析过去 12 个月美国医院系统对生成式AI的采用情况，聚焦临床决策支持工具和行政自动化（排班、计费、记录管理）两个领域，读者是正在决定下一步投资方向的医疗IT高管。
文章建议在写目标前自问：这项研究会支撑什么决策？谁来读？什么内容会让他觉得“这正是我需要的”？
对于多面向研究，文章建议自己先列出想被回答的具体问题，这样能减少agent跑偏的概率。
来源范围上，Quick Research可调用Quick Index的企业数据、200 多家可信新闻机构，以及来自S&P Global、FactSet、IDC、美国专利数据和PubMed的付费数据集。输入目标后需要选择纳入哪些来源，并审阅草拟的研究计划。文章举例：竞争分析不需要PubMed，临床文献综述不需要新闻文章。
该组件的常见错误包括：把研究目标写成搜索查询、省略读者上下文、跳过研究计划审阅。
Quick Flows：把调度、数据源和条件写进提示词
Quick Flows把自然语言描述转成自动化工作流。文章称，一个只省团队五分钟的工作流和一个省五小时的工作流，差别往往就在提示词怎么写。
最常见错误是只描述想要什么，不说明怎么做、什么时候做、给谁。原文给出一组前后对照：改前是“从我们的销售数据创建一份报告”；改后是“每周一上午 8 点，从CRM拉取上一周的销售数据，计算总收入和按销量排名前 10 的产品，生成一页PDF摘要，发到sales-managers邮件组”。
文章指出第二个提示词提供了具体锚点：日程、数据源、具体计算、输出格式、投递目标，每个细节都对应到流程中的一步。
定义触发器时要同时说清时间和条件。“每周一上午 8 点”是清楚的，“当有新数据到达时”是含糊的。文章建议明确是哪个系统产生触发器、什么算“新数据”、以及触发器触发但没有新数据时该怎么办。
超过两三个操作的工作流，文章建议把提示词写成编号步骤。Quick Flows支持条件分支、重复循环和用户输入，编号步骤与其内部步骤结构自然对应。给出的示例流程为：1. 接收上传的费用报告（PDF或图片）作为输入；2. 从文档中提取总金额、供应商名称、日期和费用类别；3. 如果总额超过 500 美元，路由到财务团队的Slack频道审批；4. 获批后，连同审批时间戳，把所有提取字段记录到Google Sheets跟踪表。
文章称这种结构让调试变得直接：如果第 3 步不工作，就知道该看哪里。
Quick Flows的agentic运行时支持通过对话迭代，而不是重写整个提示词。示例追加指令是：在第 2 步和第 3 步之间加一步，检查数据源是否返回了结果；如果查询返回为空，给我发通知，而不是继续执行剩下的流程。
该组件的常见错误包括：单个提示词塞太多操作、跳过用户输入定义、忽略错误条件和失败处理。
Quick Sight：查询要包含业务问题、指标、维度和时间范围
Quick Sight支持用对话式查询探索数据。文章称，每次有效的Quick Sight查询应包含六个核心要素：业务问题（想得到什么决策或洞察）、指标（要分析的量化度量）、维度（如何分组、筛选或切分数据）、时间周期、可视化类型，以及附加分析（趋势线、阈值、统计标记或对比周期）。
文章称，省略任何一项都会迫使Quick Sight去猜，结果往往在技术上正确但没什么用。
文章给出五类分析模式的提示词示例。时间序列：“把过去 12 个月的客户支持工单量按优先级画成堆叠折线图，加一条总量趋势线，让我看出总体负载在升还是在降。”对比分析：“对比 2025 年第四季度按行业垂直和销售代表的平均单笔成交额，做成按成交额降序排列的分组柱状图，并高亮平均低于 5 万美元的垂直行业。”关系分析：“画出客户生命周期价值与产品使用频率的散点图，按订阅层级给点着色，加一条回归线，让我看出使用频率对LTV的预测强度。”分布分析：“生成过去六个月项目完成时间的直方图，用两周分箱，把目标完成时间作为垂直参考线叠加，并标出项目占比超过 20% 的分箱。”地理分析：“显示北美客户分布的热力图，用颜色深浅表示收入集中度，为贡献超过总收入 10% 的地区加数据标签。”
在使用Topics（为对话式查询优化的精选数据集合）时，文章建议把问题围绕业务结果来组织，而不是数据机制。不要问“给我看一张用户数表”，而是问“哪些客户群体对我们移动应用的参与度最高，用日活用户和会话时长衡量”。
生成第一张可视化后，可以通过对话继续调整：换图表类型、加筛选、改聚合，或请求计算字段。公式可用自然语言写。示例：“添加一个叫‘Customer Health Score’的计算字段，混合续约概率（权重 40%）、产品使用趋势（权重 35%）和支持工单频率（权重 25%，反向——工单越少越健康），以 0–100 指数展示。”
该组件的常见错误包括：使用含糊指标而不指定聚合方式、缺少时间上下文、分组维度不清、对比没有基线。
Quick chat agents：身份要划边界，知识源要挑，兜底指令要写明
Quick chat agents把对话式AI带进组织内部。文章称，用户可以控制agent的身份、把它连到公司知识库、设置行为护栏并发布给团队，体验质量取决于配置有多用心。
Builder Mode中的身份字段为每一次回答打底。文章给出的示例身份是：“你是我们FinOps团队的云成本优化顾问。你的专长覆盖AWS成本管理、预留实例规划、Savings Plans分析和资源合理配置。只回答云成本优化相关问题。如果问题超出这个范围，说明情况并建议联系合适的团队。”文章称，没有这类边界，agent容易用自信但不可靠的回答去应对其专长之外的问题，并建议定期复查身份，因为六个月前写的身份可能已不反映当前优先级、工具或组织结构。
连接哪些Quick Spaces决定了agent能取用哪些信息。文章称，连接到组织内每一个Quick Space的agent会翻出不相关内容，应让知识源与agent的既定角色匹配。
同样重要的是告诉agent在不知道答案时该怎么做。没有明确指令，agent会用看似合理但编造的回答填补空白。文章给出的兜底话术是：“我的当前知识库中没有这个信息。请联系 [相关团队] 或查看 [具体资源] 获取最新指引。绝不要猜测或编造答案。”文章还建议定期复查已连接的Quick Spaces，理由是过时文档比没有文档更糟，因为agent会带着确信去引用它。
建议提示词是用户首先看到的内容，会设定预期，并示范agent表现最好的具体程度。文章称，“问我关于成本的问题”这类含糊建议会教用户写含糊提示词，具体建议则能教出更好的习惯。示例：“我们生产账户中哪些EC2实例族过去 30 天利用率最低，把它们合理配置后能省多少？”以及“对比把我们的按需RDS用量换成 1 年预留计划和 3 年Savings Plan的成本影响，哪个在节省和灵活性之间平衡最好？”
该组件的常见错误包括：身份含糊、没有定义专长领域；连接了信息过时的空间；没有提供兜底指令；没在Preview模式测试就上线。
Action integrations：参数一次给全，破坏性操作先加复核步骤
通过action connectors，Quick可以与Jira、Slack、Confluence、Salesforce等外部系统交互。文章称，有效的action提示词要包含清晰意图、所有必要参数和正确的先后顺序。
参数必须一次给全，不完整会让系统追问或自行假设。示例提示词：“创建一个Jira issue，详情如下：项目CUSTOMER-SUPPORT；问题类型Bug；摘要‘[客户名称] —— [简要描述]’；优先级High；经办人为当班支持工程师；标签customer-reported、needs-triage；描述中附复现步骤、预期与实际行为，以及客户账户层级。”
多步工作流要按依赖关系编号，说明条件，并明确指出哪一步的输出进入下一步。示例：“按顺序执行以下步骤：1. 在‘Product Documentation’ Confluence空间搜索关于 [主题] 的现有页面。2. 如果页面存在，用新内容更新并加修订说明。3. 如果不存在，用我们的标准模板新建。4. 把变更（或新建）摘要连同链接发到 #product-docs Slack频道。”
对于破坏性或批量操作，文章建议把复核步骤直接写进提示词，而不是只依赖系统层面的保护措施：先让系统生成摘要报告，得到明确批准后再执行。文章称，这对于修改工单、删除记录或向外部相关方发送沟通尤其重要。
该组件的常见错误包括：action请求含糊、缺少必要参数；action之间依赖不清；没有为失败或认证问题做规划；破坏性操作跳过复核步骤。
文章列出的通用错误与三周实践安排
文章认为横跨所有Quick组件的通用错误有六类：语言含糊允许多种解读；单个提示词塞进太多要求；假设AI拥有它并不具备的上下文；没有指定输出格式；没有用真实的边界情况测试；没有把成功的写法记录下来复用。
文章最后给出一份三周安排。第一周做基础：找出三种最常用的Quick用例，用第一篇的CRISPE框架重写现有提示词，记录改写前后的结果。第二周聚焦组件：选一个Quick组件，把本文的组件专属写法应用到真实工作流，并创建可复用的提示词模板。第三周做进阶：在知识库中实现元数据驱动的检索，用ARCHITECT框架构建自定义agent，创建一个带条件逻辑的复杂Quick Flow，把最有效的提示词记录进共享库，培训团队成员，并建立反馈机制。
文章结尾称，文中和第一篇里的提示词写法是起点而不是固定模板；组织之间的差距不在技术是否最复杂，而在是否学会了有效地与它沟通。原文还给出后续入口：阅读讲核心原则和CRISPE框架的第一篇、访问Amazon Quick服务页、查阅Amazon Quick开发者文档，以及克隆GitHub上aws-samples/sample-quicksuite-kiro-quickstarts仓库中的Quick API脚本和模板。