本节以笔者发给扣子编程的原始提示词为例，抽取其中可复用的设计原则。这段提示词虽然只有寥寥数行，其背后却隐含五个关键的设计决策。提示词页面如图7-1所示。
图7-1 提示词页面
7.3.1 从一段提示词说起
原始提示词如下：
帮我做一个数据分析专家 Agent，能够看数、做表、产出数据分析
报告。核心能力：
- 能够动态写 SQL 查询数据库中的数据。数据库中的原始数据，
使用我上传的 csv 文件。
- 使用 python 帮助用户作图，图片需要确保中文能够正确渲染，
生成图片后，需要上传对象存储，最终在 markdown 中以
图片链接 形式返回给用户。
- 使用 markdown 形式产出数据分析报告。
7.3.2 决策点一：角色定位先于能力描述
提示词开头写的是"数据分析专家 Agent"，而非"一个能执行 SQL 的程序"。这句看似平常的定位，向大模型传达了两层信息：其一是身份（你在扮演一名专业分析师），其二是场景（你服务的是数据分析工作，不是通用对话）。有了这个角色锚点，后续的系统提示词生成、模型推理时的措辞选择、输出内容的组织方式，都会自动向"专业、严谨、结构化"靠拢。反之，如果一开始只写"帮我查数据"，大模型就容易把任务当作随意的问答，输出质量显著下降。
7.3.3 决策点二：用动词拆解能力
提示词中使用了三个行为动词：看数、做表、产出报告。这三个动词分别对应三种完全不同的工具调用模式，如表 7-1 所示。
表 7-1 能力动词与工具映射关系
| 动词 | 背后能力 | 对应工具 |
|---|---|---|
| 看数 | SQL 查询与聚合 | 数据库连接＋exec_sql 工具 |
| 做表 | Python 数据可视化 | matplotlib＋对象存储上传 |
| 产出报告 | 自然语言组织与结构化输出 | 大模型自身（无需外部工具） |
将能力拆解为动词的价值有二：其一，大模型更容易从每个动词联想到具体工具，减少漏挂工具的风险；其二，后续测试环节可以按动词逐项验证，例如单独测试"看数"的 SQL 生成质量、"做表"的中文渲染效果、"产出报告"的结构完整性。动词化的拆解，直接提升了后续调试与验收的可观测性。
7.3.4 决策点三：明确数据来源
提示词中强调"数据库中的原始数据，使用我上传的 CSV 文件"。这句话决定了整条数据链路。如果改为"连接你们公司数据库"，大模型就会去追问数据库连接串、权限信息、网络可达性等一系列基础设施细节；而明确为 CSV 后，Agent 就知道数据需要先被导入一张临时表，再由 SQL 工具针对该表进行查询。数据来源的前置声明，避免了大量不必要的澄清问答。
7.3.5 决策点四：关键约束前置声明
"图片需要确保中文能够正确渲染"一句，表面上是在描述一个功能需求，实质上是在处理一个容易被大模型忽略的工程细节。在实践中发现，如果不在提示词里提前提出这一约束，大模型默认生成的 matplotlib 代码中，中文图表标题与坐标轴标签常常会变成方框。主动声明这一约束，相当于告诉模型"请为中文字体配置留出专门的代码段"，从而避免了事后返工。可以推广的规律是：所有已知容易出错的工程细节，都应当在提示词里前置声明，而不是期待模型默认"考虑周全"。
7.3.6 决策点五：指定输出格式
最后一句"以 markdown 形式产出数据分析报告"与"上传对象存储、以 图片链接 形式返回"共同构成了对 Agent 输出接口的契约式定义。输出格式的明确，直接决定了：Agent 输出能否被前端渲染、能否被用户复制到其他平台、能否与上下游系统对接。格式是能力落地的最后一公里，必须在提示词中清晰约定。
【提示】 以上五个决策点------角色、能力、数据源、关键约束、输出格式------可以抽象为面向 Agent 的提示词设计五要素模型。读者在为任何业务场景设计 Agent 时，都可以用这五要素作为检查清单，确保提示词的设计决策是完整的。
