Amazon Quick 中的 Research、Flows、Sight、聊天代理和动作集成解决的是不同问题，因此不应该共用一套万能提示词。研究任务需要证据和边界，流程需要稳定的结构化输出，分析需要明确指标，聊天代理需要对话策略，而执行动作还必须加入确认与安全约束。
真正有效的提示词工程，不是不断补充形容词，而是根据组件的职责，把输入、约束、输出契约和失败处理写清楚。
Quick Research：把开放问题变成可验证的研究任务
研究类提示词最容易出现两个极端：问题过宽，结果泛泛而谈；问题过窄，又可能遗漏关键背景。一个更稳妥的结构包含五部分：
- 研究问题：最终需要支持什么决策。
- 范围：行业、地区、时间窗口和排除项。
- 证据标准：优先使用哪些类型的信息，并区分事实、推断与未知项。
- 分析框架：要求比较哪些维度，而不是只做摘要。
- 交付格式：表格、结论、风险和后续问题分别如何呈现。
可以这样编写研究提示词：
任务：评估未来 12 个月在德国推出 B2B 费用管理产品的机会。
范围：
- 关注员工规模为 50～500 人的企业
- 分析监管、主要竞争者、采购障碍和差异化空间
- 排除面向个人消费者的产品
证据要求：
- 对关键判断说明依据
- 将内容标记为“已验证事实”“合理推断”或“信息不足”
- 如果数据存在冲突，列出冲突而不是自行消除
输出：
1. 不超过 150 字的决策摘要
2. 竞争者对比表
3. 三个市场机会与三个主要风险
4. 仍需人工验证的问题清单
常见陷阱是直接要求“全面研究某市场”。“全面”没有可执行标准，也没有停止条件。为时间窗口、分析对象和交付物设限，通常比要求模型“更深入”更有效。
Quick Flows：提示词必须像接口，而不是聊天消息
Flows 强调多个步骤之间的数据传递。这里最重要的不是文风，而是输出稳定性。上游步骤若今天返回段落、明天返回列表，下游分支就会变得脆弱。
建议为每一步定义：
- 输入变量及其含义；
- 允许的分类值；
- 固定输出结构；
- 缗失信息时的处理方式；
- 哪些情况必须转人工，而不是继续猜测。
下面是一个可直接运行、再改造成 Flow 步骤生成器的 Python 示例。它只使用标准库，不调用未公开假设的 Amazon Quick API；实际接入时，可将生成的提示词填入相应步骤，并把模型返回值交给校验函数。
import json
ALLOWED_PRIORITIES = {"low", "medium", "high", "manual_review"}
def build_ticket_prompt(ticket: dict) -> str:
return f"""你是工单分流步骤，只做分类，不执行退款或修改账户。
输入：
{json.dumps(ticket, ensure_ascii=False, indent=2)}
规则：
- 信息不足时，priority 必须是 manual_review
- category 只能是 billing、account、technical 或 other
- 不得虚构订单号、客户身份或处理结果
仅返回 JSON：
{{
"category": "billing|account|technical|other",
"priority": "low|medium|high|manual_review",
"reason": "一句话理由",
"missing_fields": []
}}
"""
def validate_result(raw: str) -> dict:
data = json.loads(raw)
required = {"category", "priority", "reason", "missing_fields"}
if set(data) != required:
raise ValueError(f"字段必须严格为：{sorted(required)}")
if data["priority"] not in ALLOWED_PRIORITIES:
raise ValueError("未知 priority")
if not isinstance(data["missing_fields"], list):
raise ValueError("missing_fields 必须是数组")
return data
if __name__ == "__main__":
ticket = {
"subject": "发票金额似乎不正确",
"message": "本月费用比合同金额高，但我没有订单号。"
}
print(build_ticket_prompt(ticket))
sample_output = '''{
"category": "billing",
"priority": "manual_review",
"reason": "涉及账单差异，但缺少核验所需的订单号",
"missing_fields": ["order_id"]
}'''
print(validate_result(sample_output))
在 Flow 中只写“判断优先级并继续处理”是典型反模式：分类标准不明确，“继续处理”也掩盖了副作用。更可靠的做法是把分类和执行拆成两个步骤，中间增加结构校验和人工审批条件。
Quick Sight：先定义指标，再要求洞察
分析组件需要的不是“看看仪表盘有什么问题”，而是明确的业务问题。提示词应写出：
- 指标：收入、转化率、退款率还是活跃用户；
- 维度：区域、渠道、产品或客户类型；
- 时间：本周、同比还是滚动 30 天；
- 比较基线：预算、历史均值或目标值；
- 异常阈值：多大变化才值得报告。
例如：
分析最近 8 周的退款率，按地区和获客渠道拆分。
与此前 8 周以及同期目标值比较。
只报告绝对变化超过 1 个百分点的分组。
输出：异常分组、变化幅度、数据支持的可能解释，以及无法从现有数据确认的因素。
不要把相关性描述为因果关系。
这里的主要风险是让模型替业务人员偷偷定义指标，或者把同步变化包装成因果结论。指标口径应来自数据治理和业务定义，而不是由提示词临时创造。
聊天代理与动作集成：回答问题和改变系统是两种权限
聊天代理要维持上下文、判断用户意图，并在缺少信息时追问。动作集成则可能发送邮件、创建记录、修改状态或触发其他系统，风险明显更高。
可以采用两阶段模式：
- 计划阶段：代理解释准备执行什么、使用哪些参数以及预期影响。
- 执行阶段：用户确认后才调用动作；高风险操作还需人工审批。
适合动作集成的提示词约束包括：
你可以准备退款请求，但不能自行批准退款。
执行规则：
- 必须先核验 customer_id、order_id 和退款金额
- 缺少任一字段时，只能追问
- 调用动作前展示最终参数并获得明确确认
- 不得把“好的”“继续看看”解释为执行授权
- 动作失败时报告错误，不得声称已经成功
- 同一 order_id 的重复请求必须标记为可能重复
仅靠提示词不能提供真正的权限隔离。金额上限、身份校验、幂等键、审计日志和审批流应由动作接口与后端系统强制执行。提示词负责引导行为，系统控制负责守住边界。
上线前检查清单
将提示词投入生产前，可以逐项检查：
- Research 是否写明范围、证据标准和停止条件？
- Flows 是否使用固定字段，并对模型输出做解析与校验？
- Sight 是否明确指标口径、时间范围和比较基线？
- 聊天代理是否知道何时追问、拒绝或转人工？
- 动作是否在执行前确认，并由后端实施权限与幂等控制？
- 是否用正常输入、缺失字段、矛盾信息和恶意指令分别测试过？
最值得复用的不是一段“神奇提示词”，而是一套组件化契约：研究组件交付有边界的证据，流程组件交付可解析的数据，分析组件交付有口径的洞察，代理组件管理对话，而动作组件只在授权和校验完成后改变系统状态。