给输出一个稳定的结构

核心方法

当结果要进入表格、看板或程序，只有好读还不够，还需要字段稳定、类型明确、缺失值一致。本课从会议行动项出发，设计一个人能检查、程序也容易处理的数据结构。

不要混淆两种正确：结构正确表示字段和类型符合约定；语义正确表示内容有真实依据。JSON 可以完全合法，同时把负责人写错。因此格式校验与事实核验必须分别完成。

案例拆解

原始记录是：「小林已发出标题方案，设计反馈尚未收到；小周负责核对剩余 3 篇文档，截止日期未确认。」先确定一条行动最少要包含任务、负责人、截止日期、状态与来源。

字段定义。 task 是可执行动作，owner 是材料明确指定的人，due_date 是明确日期，status 只能使用 agreed、pending_confirmation 或 completed，source 保存依据编号。缺失负责人或日期时使用 JSON 的 null，不混用空字符串、问号和「N/A」。

{
  "actions": [
    {
      "task": "核对剩余 3 篇帮助文档",
      "owner": "小周",
      "due_date": null,
      "status": "agreed",
      "source": "R04"
    }
  ],
  "questions": ["文档核对的截止日期是什么？", "谁负责跟进设计反馈？"]
}

这个例子没有把「设计未反馈」直接变成小林承诺负责的任务，也没有把周五的上线计划借来充当文档核对日期。未知值必须能被后续使用者识别。

做三个边界测试。 第一组材料没有任何行动项，预期应是空数组而不是虚构一个行动。第二组把两个不同任务写在一句话里，检查是否拆成两条。第三组日期是「下周三」，但没有会议日期，不能强行转换成绝对日期，应保留待确认问题。

面向人工与面向程序的差异。 如果只放进周报，「待确认」这个中文值就很方便；如果交给程序，null 与固定枚举更容易可靠处理。没有必要为了显得技术化，把所有普通写作都转成 JSON。

提示词与使用说明

从下方记录提取已经明确约定的行动。
输出一个 JSON 对象，只包含 actions 与 questions 两个数组。
actions 每项包含 task、owner、due_date、status、source。
缺失 owner 或 due_date 使用 null；不要猜负责人，不推算缺少基准的相对日期。
status 只允许 agreed、pending_confirmation、completed。
没有行动时返回空数组。建议或未确认意向放进 questions，不升级成承诺。
只返回 JSON，不包裹 Markdown 代码围栏。
记录：[带编号的材料]

有些 API 提供结构化输出功能，可以约束返回结构；这不意味着模型生成的字段值自动正确。正式开发时应在服务器再次检查类型、枚举、长度和业务关系。可延伸阅读 OpenAI Structured Outputs ↗ 的结构保证与使用限制。

独立练习

先把答案写进本课笔记，再展开解析。以下人物、活动和数据均为教学用的虚构材料；练习记录请填写你实际完成的过程。

给定材料

R1：小周确认负责核对 3 篇文档，日期未定。
R2：小林建议增加视频，尚未讨论是否采用。
R3：今天没有其他已确认行动。

你的任务

输出 actions 与 questions 两个数组。行动包含 task、owner、due_date、status、source。再分别做 JSON 解析检查和事实检查，不把这两项混为一谈。

完成后，对照参考解析

actions 中只有 R1 一条：owner=小周，due_date=null，status=agreed，source=R1。R2 的视频建议放到 questions，不能写成小林已经接下的工作。缺失日期使用真正的 null，而不是字符串“null”。JSON.parse 通过只能说明语法有效；还必须检查字段白名单、枚举和来源关系。若输入没有明确行动，actions 应是 []。

验收与迁移

对照自己的成果逐项检查。未达到的项目，写明缺什么、怎样补；这些标准用于自查，不会自动标记课时完成。

可解析，字段与枚举符合约定
日期是 null，未推算或猜测
建议没有升级成已确认行动

带回自己的场景

再用“没有行动”“两项任务一句话”“相对日期无基准”三种输入测试同一提示词。

延伸资料

设计可检验的评估 ↗。资料用于核对方法和技术边界，案例与练习由 Nextory 编写。