Amazon Quick 的 AI 功能并不是“问得越长，回答越好”。真正决定输出质量的，是提示词是否明确表达了任务、上下文、边界和验收标准。把提示词当作一种轻量级接口来设计，往往比反复追加一句“再详细一点”更稳定。
这套方法可以归纳为四个基础动作：提高具体性、补足上下文、提供少量示例，以及使用 CRISPE 框架组织复杂请求。
提示词不是关键词，而是一份任务说明书
模糊请求通常会把大量决定留给模型。例如：
分析本月销售数据。
这里没有说明分析对象、时间范围、比较基准、输出格式，也没有定义什么结果最有价值。模型只能自行猜测。
更可执行的写法是：
分析 2025 年 5 月各区域销售数据，与 2025 年 4 月比较。找出收入变化最大的三个区域，区分销量和平均客单价的影响。以 Markdown 表格输出，并在表格后给出不超过 150 字的管理层摘要。不要推断数据中不存在的原因；信息不足时明确标记“需要补充数据”。
这个版本补齐了五类信息：
- 任务：比较区域销售表现；
- 范围：2025 年 5 月与 4 月；
- 分析维度：收入、销量、平均客单价；
- 输出格式：表格加短摘要；
- 边界条件：不虚构原因，缺失信息必须显式标记。
具体性并不意味着堆砌文字。有效提示词中的每一句话，都应该减少一种歧义。
用上下文和 few-shot 示例锁定输出形态
上下文用于解释“为什么做”和“给谁看”。同一份数据，销售经理、财务团队和客户成功团队关注的内容并不相同。
可以在请求中加入这些背景：
受众：区域销售负责人
使用场景：周一经营例会
目标：快速识别需要跟进的区域，而不是生成完整财务报告
数据限制：当前数据不包含促销活动和退货原因
当格式要求较严格时，few-shot（少样本）示例通常比抽象描述更有效。示例不必很多，一两个高质量样本即可说明字段、语气和粒度：
请把客户反馈分类为：产品问题、交付问题、价格问题、其他。
示例 1：
输入：包装完好，但设备启动后一直显示错误代码 E17。
输出：{"category":"产品问题","summary":"设备启动时显示 E17 错误"}
示例 2：
输入：产品没问题，不过比承诺日期晚到了四天。
输出：{"category":"交付问题","summary":"订单延迟四天送达"}
现在处理：
输入：{{customer_feedback}}
输出：
示例应覆盖真正容易混淆的边界。如果“产品损坏”与“运输损坏”在业务上属于不同类别，就应该各给一个样本，而不是只展示最简单的情况。
用 CRISPE 拆解复杂请求
对于一次性简单问题，自然语言已经足够；如果任务会被多人复用，CRISPE 能帮助团队检查是否遗漏关键要素。常见拆法是：
- Capacity and Role（能力与角色）：让 AI 以什么角色工作；
- Insight（背景信息）：提供业务背景、数据含义和已知限制；
- Statement（任务陈述）：明确要完成的工作；
- Personality（表达风格）：指定语气、受众和表达方式；
- Experiment（试验与迭代）：要求多个方案、自检，或根据反馈修订。
例如，可以把经营摘要任务写成：
[Capacity and Role]
你是一名面向零售业务负责人的数据分析师。
[Insight]
输入包含本月和上月的区域收入、订单量、平均客单价。数据不包含促销、退货原因或宏观经济信息。
[Statement]
识别收入环比变化最大的三个区域，并判断变化主要来自订单量还是平均客单价。
[Personality]
使用简洁、客观的管理层语言。先给结论，再给证据，避免技术术语。
[Experiment]
先输出一个 Markdown 表格，再输出三条行动建议。检查每条结论是否能由输入数据直接支持；不能支持的内容标记为“待验证”。
CRISPE 的价值不在于背诵缩写，而在于把角色、背景、任务、表达和验证拆开。团队也可以根据自己的业务重新命名字段，只要结构保持清晰即可。
可复制的提示词构建器
下面是一个不依赖第三方库的 Python 小工具。它不会调用 Amazon Quick API，而是根据 CRISPE 结构生成可粘贴到 Amazon Quick 中的提示词。运行前只需把默认业务背景和任务改成自己的内容。
将以下代码保存为 prompt_builder.py：
#!/usr/bin/env python3
import argparse
from textwrap import dedent
def build_prompt(role, context, task, style, experiment, input_data):
return dedent(f"""
[Capacity and Role]
{role}
[Insight]
{context}
[Statement]
{task}
[Personality]
{style}
[Experiment]
{experiment}
[Input]
{input_data}
""").strip()
def main():
parser = argparse.ArgumentParser(description="Build a reusable CRISPE prompt")
parser.add_argument("--input", required=True, help="Input data or text to analyze")
args = parser.parse_args()
prompt = build_prompt(
role="你是一名面向区域销售负责人的数据分析师。",
context=(
"数据包含本月和上月的区域收入、订单量与平均客单价；"
"不包含促销活动、退货原因或外部市场信息。"
),
task=(
"找出收入环比变化最大的三个区域，并判断变化主要来自订单量"
"还是平均客单价。"
),
style="使用简洁、客观的中文。先给结论，再给证据。",
experiment=(
"输出 Markdown 表格和三条行动建议。仅使用输入中的事实；"
"无法验证的判断标记为‘待验证’。"
),
input_data=args.input,
)
print(prompt)
if __name__ == "__main__":
main()
直接运行：
python3 prompt_builder.py --input '华东：本月收入120万，上月100万；订单量增长5%，平均客单价增长14%。华南：本月90万，上月110万；订单量下降16%，平均客单价下降2%。华北：本月80万，上月82万；订单量持平，平均客单价下降2%。'
如果团队经常处理不同任务，可以进一步把角色、背景和输出约束存入版本控制，并将业务数据作为运行时输入。这样修改模板时可以审查差异，也能避免每个人维护一份略有不同的提示词。
上线前的检查清单
一个可复用提示词至少应该通过以下检查：
- 任务中是否有明确的对象、动作和完成标准；
- 是否说明了受众、业务场景与数据限制；
- 输出格式是否可以直接进入下游流程；
- 示例是否覆盖最容易误判的边界情况；
- 是否要求区分事实、推断和未知信息；
- 是否避免输入密码、密钥、个人敏感信息或未经授权的数据；
- 关键业务结论是否仍由人审核，而不是直接自动执行。
提示词工程的目标不是找到一句永远正确的“魔法指令”，而是建立可测试、可复用、可审查的任务描述。先用具体性减少歧义，再用上下文和示例校准输出；当任务变复杂时，再用 CRISPE 保持结构完整。这样的提示词更容易在 Amazon Quick 中获得一致结果，也更适合团队长期维护。