Day 07 - Structured Prompt Design

今日目标

能把模糊指令改写成角色、目标、输入、步骤、约束、输出格式齐全的结构化 Prompt。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读当天章节重点，只抓问题、思路、结论。
25-45 分钟	实践任务	动手完成输出模板，必须产出一份可复用产物。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
structured prompt	结构化 Prompt：用固定章节组织角色、目标、输入、步骤、约束与输出格式的 Prompt，减少歧义与遗漏。	把「帮我分析性能测试结果」改写成六要素齐全的指令。
role	角色：定义模型以什么身份、站在什么视角处理任务。	让模型以性能测试分析专家身份出报告，而不是普通问答。
objective	目标：一句话说明任务要达成的结果，是判断输出是否合格的基准。	「判断本次压测是否达标并给出依据」。
input schema	输入格式：描述输入数据的字段、类型、取值范围与必填项。	约定 TPS、P95、错误率等字段，模型才知道有什么可用。
steps	步骤：规定任务的处理顺序，先做什么、后做什么。	先判总体、再逐项分析、最后给假设。
constraints	约束：不可违反的边界，如时间范围、数据来源、禁止事项。	只分析输入时间窗内的数据，不引用其他项目结果。
output format	输出格式：约定输出的结构与样式，如 Markdown 章节、表格列、JSON 字段。	报告固定为结论摘要、指标对比表、待验证清单。
uncertainty handling	不确定性处理：信息不足或结论不确定时如何标注、如何给出置信度。	数据缺失标注「无数据」，无法确认的结论标注「待验证」。
anti-hallucination	防幻觉：通过「只基于输入输出、缺数据要说明」等规则减少编造。	禁止补全缺失的压测数据，禁止编造对比基线。
prompt-program boundary	Prompt 与程序的边界：哪些逻辑放 Prompt、哪些放代码与工具。	循环、重试、校验交给代码，Prompt 只负责分析与表达。

阅读重点

对应章节：第 2 章中提示工程与上下文组织相关内容。
关注点：
结构化 Prompt 的六个组成部分各自解决什么问题。
为什么输出格式要提前约定：可解析、可评估、可复用。
步骤设计如何减少模型的自由发挥空间。
不确定性处理与防幻觉规则怎么写才不会互相冲突。
补充材料：
Anthropic 的 context engineering 文档中关于 prompt 结构组织的部分。
OpenAI 的 prompt engineering 指南中的编写策略章节。

理解检查

一个好的 Prompt 通常包含哪些部分？每个部分负责解决什么问题？
为什么输出格式要提前约定？不约定会发生什么？
「一步一步分析」是否总是有效？在什么场景下会失效？
有哪些具体做法能让模型少编造？

实践任务

背景：团队每周做一次性能测试，但每个人给模型下的指令都不一样，报告格式五花八门。今天把最常被说的一句话「帮我分析性能测试结果」改写成结构化指令。

步骤：

按六要素拆解任务：角色、目标、输入、步骤、约束、输出格式。
明确输入字段：测试类型、压测时间窗、并发数、TPS、P95/P99、错误率、环境信息。
写清分析步骤：先判断总体是否达标，再逐项对比指标，最后给出待验证假设。
写不确定性处理：数据缺失怎么标注，结论如何区分「已验证」与「待验证」。
写禁止事项：不编造数据、不评价被测系统代码、不下超出数据的结论。
用输出模板替换成你的场景，保存为 structured-prompt-performance-analysis.md。

产出：一份六要素齐全的结构化 Prompt，可直接发给模型使用。

输出模板

角色：[身份与视角]。
目标：[一句话任务结果]。

输入字段：
- [字段名]：[含义]，[必填/可选]。

分析步骤：
- [第一步做什么]。
- [第二步做什么]。
- [第三步做什么]。

约束：
- 时间范围：[范围]。
- 只使用输入数据，[其他边界]。

输出格式：[Markdown/JSON/表格]，结构为：[章节或字段列表]。

不确定性处理：
- 数据缺失时：[处理方式]。
- 无法确认的结论标注：[标注方式]。

禁止事项：
- 不编造数据。
- [其他禁止项]。

示范输出

角色：性能测试分析专家，负责把压测原始数据转成可决策的分析结论。
目标：判断本次压测是否达标，定位不达标指标，并给出待验证假设。

输入字段：
- 测试类型：容量/稳定性测试，必填。
- 压测时间窗：如 2026-08-10 10:00-11:00，必填。
- 并发数：必填。
- TPS：必填。
- P95/P99：必填。
- 错误率：必填。
- 环境信息：必填。

分析步骤：
- 先判断总体结论：核心指标是否达到目标值。
- 再逐项对比：与目标值差多少，趋势如何。
- 最后给假设：指出最可能的原因，并标注待验证。

约束：
- 时间范围：只分析输入时间窗内的数据。
- 只使用输入数据，不引用记忆里其他项目的结果。

输出格式：Markdown，结构为结论摘要、指标对比表、异常指标分析、待验证假设。

不确定性处理：
- 数据缺失时：标注「无数据」，不推测。
- 无法确认的结论标注：标注「待验证」，并写出验证方法。

禁止事项：
- 不编造缺失数据。
- 不评价被测系统代码实现。
- 不下超出输入数据范围的结论。

追问练习

「一步一步分析」在什么场景下反而有害？什么时候应该让模型直接给结论？
Prompt 和程序逻辑的边界在哪里？哪些逻辑放进 Prompt 会让系统更难维护？
如果同一份结构化 Prompt 要支持「快速版」和「详细版」输出，你会怎么设计？
如何验证结构化版本比原版模糊指令更好？需要收集什么证据？

常见误区

只堆规则不写步骤：模型知道「不能做什么」，却不知道「先做什么」。
输出格式约定得太松：只说「用 Markdown」，没说章节和表格列，结果还是五花八门。
把业务数据写进 Prompt 当规则：数据会过期，规则和数据混在一起难维护。
滥用「一步一步分析」：对简单任务反而拖慢输出、增加出错机会。

进阶扩展

结构化输出与 schema 校验：让模型输出 JSON，用代码校验字段，失败自动重试。
Prompt 版本管理：Prompt 和代码一样需要版本、评审与回滚。
动态生成 Prompt：由代码按任务类型组装不同章节，而不是一个 Prompt 打天下。

今日作业

完成性能测试分析的结构化 Prompt，保存为可复用文件。
用原版模糊指令和结构化版本各跑一次模型，对比输出的差异。
列出你工作中 3 个可以用结构化 Prompt 改造的模糊指令。

自检清单

我能写出结构化 Prompt 的六个组成部分。
我能把一条模糊指令改写成六要素齐全的版本。
我能解释为什么输出格式要提前约定。
我能写清不确定性处理和防幻觉规则。
我能指出 Prompt 与程序逻辑的边界在哪里。