用大模型整理一份工具说明时，我们可能同时期待三个结果：读懂工具的用途，确认它是否适合自己的项目，以及把资料保存成可继续使用的文件。这三个要求需要不同的输入和检查。摘要可以依据当前文本完成，最新版本需要查询当前来源，保存文件则需要实际的文件操作能力。
本文是“大模型应用方法与实践”系列的导读，面向使用过基本聊天功能的读者，无需编程、API 或 Agent 经验。我们先建立任务与能力的基本认识，再用同一份小型资料完成摘要、事实提取和操作需求分析。详细 Prompt 模板、多轮协作、项目规则、Skill 安装和工具配置分别放在后续专题。
实践条件：使用任意能够进行文本对话的产品，将本文给出的资料和任务要求一起粘贴即可；不要求上传文件、联网或授权文件写入。案例采用教学模拟资料，文中的参考结果由原文逐项整理，供人工核对，不是某个模型的通过率报告。相关官方文档核对日期为 2026 年 10 月 4 日；具体产品的功能、权限和可选模型仍需在使用时确认。
1. 任务类型与能力边界
任务目标与完成条件
开始一项任务前，可以先写出五项信息：目标、输入、能力、输出、验证。目标说明要解决什么问题，输入说明有哪些资料，能力说明要读取或执行什么，输出说明交付物是什么，验证则说明怎样确认完成。
例如，“帮我整理实验日志”还没有说明完成条件。若目标只是理解一段日志，可以把文本粘贴到对话里，要求概括异常和可能原因；若目标是生成一张结果表，需要提供字段含义、单位和记录范围；若目标是批量整理本地文件，还需要确定目录、写入位置和覆盖规则。明确这些差别，才能判断当前产品是否具备所需能力。
| 类型与示例 | 必要输入或能力 | 主要检查 |
|---|---|---|
| 生成：拟定学习笔记结构 | 读者、主题、范围与要求 | 是否覆盖目标，是否适合读者 |
| 转换：将工具说明改写成摘要 | 原文与输出要求 | 是否保留原意，是否补造事实 |
| 提取：提取版本、平台与格式 | 原文、字段含义与缺失规则 | 各字段是否能定位到原文 |
| 检索：查询当前发布版本 | 可访问的当前来源与检索能力 | 来源、版本、查询日期与适用范围 |
| 计算：统计日志中的失败次数 | 完整记录、计数规则；必要时使用计算工具 | 记录是否齐全，计算能否复核 |
| 操作：创建文件并保存摘要 | 文件工具、目标路径与相应权限 | 实际文件是否存在，内容是否正确 |
一项真实任务往往包含多种类型。例如，比较两份说明属于提取与分析，补齐没有提供的当前信息需要检索，生成报告文件需要写入。可以先完成资料范围内的部分，并明确列出尚缺的输入或能力。
模型与宿主
模型负责根据当前输入生成回答或提出下一步行动。宿主是承载模型的产品或应用，例如聊天网页、桌面应用、开发工具或自己编写的程序。宿主决定如何组织对话、怎样提供文件与工具，以及哪些操作需要授权。
因此，模型名称相同，不代表两个产品都能搜索网页、读取本地目录或修改表格。能理解一段代码，也不代表当前会话能执行代码；能给出文件正文，也不代表已经把正文保存到磁盘。使用工具扩展搜索、文件检索或外部服务访问，是应用层提供的能力，具体配置与调用方式依运行环境而定，参见 OpenAI 的 Using tools。
判断能力时，可以查看当前会话可用的入口、工具说明和实际执行记录。任务完成后，再检查对应的来源或产物。聊天里出现“已经完成”时，仍应能找到支持这一说法的结果。
任务范围与核验成本
大模型适合协助组织材料、解释概念、提出候选方案和转换表达，但结果仍需要与任务条件核对。对于小型说明，逐项检查几条事实通常很容易；对于几百份记录，遗漏、重复和字段混淆就需要集合检查或脚本辅助。
任务是否值得交给模型，也取决于检查成本。若只需统计一列数值，现成公式或脚本可能更直接；若需要理解几份不同写法的说明，再组织成面向初学者的解释，模型可以承担语言处理部分。可以组合两种方式，让计算工具负责精确计数，让模型负责说明结果，并分别检查。
2. 输入、上下文与输出
信息来源
一次回答中的信息可以来自模型训练形成的知识、当前提供的材料，以及工具实际返回的结果。三者的用途与可核验程度不同。
| 信息来源 | 可以用于什么 | 需要留意的限制 |
|---|---|---|
| 模型已有知识 | 解释常见概念，提出分析思路 | 可能不完整、过时或记错；不能直接证明某个产品的当前状态 |
| 当前输入资料 | 摘要、提取、比较给定内容 | 结论受资料范围、版本和完整性限制 |
| 工具返回结果 | 核对网页、文件、计算或操作状态 | 需要检查工具是否成功、读取范围是否正确、返回内容是否支持结论 |
例如，资料写明“此说明对应 1.2 版”，可以据此提取说明版本；要回答“当前最新版是多少”，还需要当前发布记录。“没有在资料中出现”只说明资料没有提供，不能直接改写成“产品不支持”。
提供文档会改变当前任务可以使用的信息。是否将用户数据用于后续训练，是另一个由产品政策、账户设置和授权决定的问题，不能从一次材料上传推断。本文只讨论当前任务中材料的组织与使用。
Token 与上下文窗口
模型通常以 token 为单位处理输入和输出。token 是分词或编码得到的单位，不能简单等同于一个汉字、一个单词或一个字符；不同内容和编码方式的对应关系可能不同。
上下文是当前任务中提供给模型使用的信息，包括指令、资料、相关历史和工具结果。上下文窗口则限制一次处理可容纳的信息量。在 OpenAI 的接口说明中，窗口预算涉及输入、输出，以及适用模型的推理 token；具体限制应查看所选模型和接口文档，参见 Conversation state。
对使用者而言，关键是让必要信息进入当前任务，并给结果留出足够空间。较大的窗口可以容纳更多材料，但不能保证每条材料都被准确使用。把全部历史、重复说明和无关附件一起加入，也会增加查找依据和定位错误的难度。
长任务可以保存三类内容：稳定的目标与约束、原始资料的位置、当前完成状态。需要交接时，记录已经完成的产物、尚未解决的问题和下一步，再让新对话核对原资料。具体目录与交接方法将在第三篇展开。
对话历史与产品记忆
聊天界面显示的全部历史、模型本次实际使用的上下文，以及产品保存的跨对话记忆，是不同的概念。宿主可能选择历史片段、形成摘要或按需读取文件；产品记忆的范围与加载方式也依产品而定。
重要约束应保存在可检查的任务说明或项目文件中，并在继续工作时确认。例如，“未知许可证必须保留为未知”应能在当前任务材料中找到，不能只依赖“上次已经说过”。
输出的不确定性
同一份输入可能得到措辞、结构乃至细节不同的回答。OpenAI 的 Prompt engineering说明了生成结果的非确定性，以及不同模型和版本可能需要不同提示方式。
我们可以固定需要检查的内容，而允许表达变化。两份摘要只要都保留输入格式、输出形式和关键限制，就可能同时合格；若其中一份把“最多两个输入文件”写成“支持任意数量”，即使表达自然，也违反了资料。
缺乏依据却呈现为事实的内容，通常称为幻觉。常见表现包括虚构来源、补造参数、把猜测写成明确结论。要求注明来源和保留未知，有助于暴露这些问题；最终仍要回到原文或实际状态核对。
3. Prompt、Skill 与工具
组件职责
同一个资料整理任务，可以使用一次性指令完成，也可以在任务反复出现后组织成可复用流程。这里先区分各组件的职责：
| 组件 | 主要职责 | 资料整理示例 |
|---|---|---|
| Prompt | 表达本次任务的目标、限制和输出要求 | “根据这份说明提取五个字段，缺失项写明未提供” |
| 上下文 | 提供当前任务所需的信息 | 工具说明、字段定义、已有结果和反馈 |
| 项目规则 | 保存特定项目持续适用的约定 | 只读原始资料，输出放入指定目录 |
| Agent Skill | 组织可复用的步骤与配套资源 | 读取来源、提取事实、核对缺失、生成报告 |
| 工具 | 提供读取、搜索、计算或写入等执行能力 | 读取说明文件，保存结果，检查文件内容 |
| Agent | 根据任务状态选择行动，并利用结果继续工作 | 发现资料缺失后补读来源，再决定是否能完成报告 |
Agent Skill在本系列中指由 SKILL.md 与可选参考资料、模板、脚本等组成的任务流程。以 ChatGPT 和 Codex 的实现为例，宿主先提供 Skill 名称与描述，在选用时读取完整说明；具体发现和调用行为见 Build skills。本篇不要求安装或编写 Skill。
Skill 中可以写明“读取文件后检查来源编号”，也可以提供辅助脚本；执行这些步骤仍需要宿主具备对应工具与权限。只有指令的 Skill 可以指导文本工作，文件写入则需要可用的执行能力。是否实际选用和执行了流程，需要从当前运行记录与产物检查。
组合方式
在资料整理案例中，各部分可以这样配合：
本次要求（Prompt） + 工具说明与约定（上下文）
↓
模型处理当前任务
↑ ↓
按需读取 Skill 提出工具调用
↓
宿主执行并返回结果
↓
继续处理或形成交付物
↓
依据原文与实际产物验收
普通聊天任务可以只使用上半部分，直接得到文本；具备工具能力的任务可以经过读取、写入与检查等步骤。Agent 的一次执行可能包含多个循环。预先规定步骤顺序的流程则称为工作流，也可以在某些步骤中使用 Agent。
MCP是连接 AI 客户端与外部工具、资料等能力的开放协议。插件是具体平台的扩展包装形式，可能同时包含 Skill 和 MCP 服务，也可能只提供指令与资源。相关分工见 MCP server。导读只需要理解这些职责，连接、认证和故障定位在第七篇实践。
方法选择
偶尔整理一份短说明，直接给出资料与清晰要求即可。连续处理多份相似资料，且字段与核验步骤已经稳定时，可以考虑用 Skill 复用流程。需要当前网页、本地文件或外部账户数据时，再选择具备相应工具的宿主。
每增加一项能力，都应能说明它解决什么实际问题。流程复杂度也会带来配置、排查和检查成本，因此可以从能够完成任务的最小方式开始，再根据观察到的问题补充。
4. 说明资料与最小实践
练习资料
本系列的贯穿项目是 llm-practice-lab，主题为 Windows 与 Linux 实验日志整理。导读先使用一份固定说明，后续再加入版本差异、来源冲突和实验记录。
下面的 LogBrief 是为本系列编写的虚构工具，条目均为教学模拟资料。不要搜索同名产品来补齐字段，也不要据此安装软件或执行命令。行号是证据定位标识，复制资料时请保留。
[S1] LogBrief 说明，教学模拟资料
L1：本说明对应 LogBrief 1.2，说明日期为 2026-09-20。
L2：工具用于整理小型实验日志，读取 UTF-8 编码的纯文本日志。
L3：本版说明列出的运行平台为 Windows 11 和 Ubuntu 24.04。
L4：一次任务最多接收 2 个输入日志文件，每个文件不超过 5 MB。
L5：工具输出一份 CSV 汇总表，列为 run_id、status、elapsed_ms。
L6：elapsed_ms 的单位为毫秒；缺失耗时保留为空，不填为 0。
L7：处理过程在本地完成，不连接网络；工具不修改输入日志。
L8：该工具不提供图形界面；本说明未提供许可证和安装命令。
资料也可从导读输入文件读取。任务要求完整列在下面；参考答案放在独立核对文件中。练习时只提交输入与任务要求，完成后再打开答案。
三个实验分别使用相同的原始资料，可以在三个新对话中独立完成。这样能减少前一份回答对后续输出的影响。新对话是否还加载产品记忆或项目规则，依宿主设置而定；如有加载，应在记录中注明。
实验一：资料摘要
初始状态：只有 S1 说明，不需要网络与文件工具。目标是让初学者理解工具用途和关键限制，而不是编写安装教程。
将 S1 原文与下面的要求一起提交：
请仅依据资料 S1，写一段面向实验日志整理初学者的中文摘要。
摘要应包含用途、输入、输出和关键限制，正文不超过 180 个汉字。
随后单独列出资料没有提供、但开始实际使用前还需要确认的信息。
保留每个关键事实的来源行号；不要补写安装命令或真实产品信息。
一份可供核对的参考摘要如下，措辞不要求完全相同：
LogBrief 1.2 用于本地整理 UTF-8 纯文本实验日志，输出含运行编号、状态和毫秒耗时的 CSV 表（S1:L1–L2、L5–L7）。说明列出 Windows 11 和 Ubuntu 24.04；一次最多输入两个文件，每个不超过 5 MB（S1:L3–L4）。缺失耗时留空，输入日志保持不变；工具没有图形界面（S1:L6–L8）。
还需确认的信息至少包括许可证和安装方式，S1:L8 明确说明二者未提供。字段如何从日志中识别，也没有给出解析规则；若要处理实际日志，需要进一步说明。
核验时，用原文逐项检查用途、输入、输出、数量与大小限制、缺失值和输入保护。不能把“缺失耗时为空”概括成“缺失耗时自动补零”，也不能把“本地处理”扩展成“采用某种加密算法”。后者即使听起来合理，也没有资料支持。
实验二：事实提取
初始状态：仍只使用 S1，不读取实验一的摘要。目标是形成可追溯的字段表，观察模型能否区分已提供信息与未知信息。
请仅依据 S1，提取以下字段：说明版本、列出的运行平台、输入格式、
输出格式、许可证。输出“字段｜值｜依据”三列表格。
值没有提供时写“未提供”，并说明缺失判断的依据或检查范围。
不要把说明版本写成当前最新版，不要猜测许可证。
参考结果为：
| 字段 | 值 | 依据 |
|---|---|---|
| 说明版本 | 1.2 | S1:L1 |
| 列出的运行平台 | Windows 11、Ubuntu 24.04 | S1:L3 |
| 输入格式 | UTF-8 编码的纯文本日志 | S1:L2 |
| 输出格式 | CSV | S1:L5 |
| 许可证 | 未提供 | S1:L8 |
这里的两个判断尤其重要：1.2 是当前输入说明对应的版本，不能据此认定是现实中的当前最新版；许可证是未提供，不能据此认定“没有许可证”或“可以任意使用”。
再给任务增加“是否能处理扫描图片”这一字段。S1:L2 描述了纯文本日志输入，但没有直接说明扫描图片处理能力。合适的结果是“说明只列出纯文本日志输入，扫描图片处理能力未说明”，并引用 L2。要给出确定结论，需要补充明确的规格或实际验证。
如果把任务改为查询某个真实工具的当前发布版本，应指定真实工具及其官方来源，记录查询日期，并实际打开发布页面核对。没有检索能力时，应明确写出这一部分未完成。LogBrief 是虚构资料，因此本例的正确结果仍是“无法据此查询真实最新版”。
实验三：操作需求分析
初始状态：只有聊天能力；尚未提供本地目录，也没有授权文件操作。目标是分析保存摘要需要什么条件，输出一份可检查的操作计划。
我准备把 S1 原文和一份学习摘要保存到本地练习目录。
请分析完成此任务需要哪些输入、工具和权限，并列出完成后的检查方法。
当前只做需求分析，不调用工具，不创建、移动或覆盖文件。
目标目录尚未给出；原始说明需要完整保留，输出与原资料分开保存。
一个合格的计划应说明：先确认目标目录和摘要内容；需要本地文件读取或写入能力，或由用户手动保存；写入范围限定为练习目录；目标文件已存在时，应先检查并选择新的文件名或确认处理方式。计划中可以提出 inputs/ 保存原资料、runs/ 保存输出，但这只是建议的组织方式。
完成操作后，应检查原文文件是否与输入一致、摘要文件是否能打开、内容是否满足实验一的要求，并核对实际保存位置。在尚未执行时，状态应为“需求分析完成，文件保存未执行”。
这个实验没有执行文件写入。若使用普通聊天产品，可以自己在文本编辑器中保存；若后续使用具备文件工具的宿主，再按明确的目录与权限完成操作。聊天中生成了目录树或文件正文，仍需要保存步骤和实际文件检查。
任务选择表
将三个实验放在一起，可以看到相同资料怎样对应不同的任务：
| 任务与输入 | 能力与输出 | 验证 |
|---|---|---|
| 摘要：S1 与读者、篇幅要求 | 文本理解与改写；输出摘要及待确认信息 | 事实覆盖、来源一致、无补造信息 |
| 提取：S1 与五个字段 | 文本提取与表格表达；输出字段表 | 五项齐全，值与行号对应，未知保留 |
| 操作需求分析：S1 与保存目标 | 任务分析；输出条件、步骤与检查计划；执行阶段另需文件能力 | 识别缺失目录，未把计划写成已执行 |
案例的验证范围是固定资料中的事实映射、参考答案和任务边界。没有开展跨模型独立运行、实时版本检索或自动文件写入测试，也不据此宣称某个产品更可靠。读者可以保存自己的原始输出，再按照上表逐项检查。
5. 模型选择与结果验证
能力匹配
模型选择先看任务条件，再看速度与预算。文本摘要需要准确理解资料；扫描页面需要图像输入与相应识别能力；查询当前信息需要检索；操作本地文件需要宿主工具。缺少必要资料或能力时，单纯更换模型不能完成对应步骤。
| 选择维度 | 检查方法 |
|---|---|
| 任务质量 | 用自己的小型代表任务，检查事实、覆盖范围与约束遵循 |
| 输入模态 | 确认当前产品能接收所需文本、图片、音频等内容 |
| 上下文与输出 | 确认材料可用，输出空间足够；过大任务拆成可核对的阶段 |
| 工具支持 | 确认所需工具在当前会话可用，且操作范围合适 |
| 延迟与预算 | 记录完成时间、返工次数及产品实际提供的消耗指标 |
OpenAI 的 Model selection也区分质量、延迟与成本，并说明工具、设置和额度会随产品及版本而异。本篇不固定模型排名或价格，选择方法可以随可用产品变化继续使用。
最小比较可以从实验二开始：向候选模型提供同一份 S1 与同一要求，记录五个字段是否完整、许可证是否保留未知、依据是否正确，以及耗时。若产品提供推理设置，也要记录实际可见的设置；未显示的值写“未显示”。发现错误后，先确定是材料缺失、要求不清还是输出没有遵守，再决定改写任务或更换模型。
验收依据
验收标准应在输出之前确定。否则容易被一份看起来完整的回答带着改变原目标。例如，原本需要五个字段，却因为模型额外写了很多背景介绍，而忽略其中许可证被猜成某种常见协议。
| 验收项 | 本文案例中的合格条件 |
|---|---|
| 正确性 | 版本、平台、格式、数量与单位均符合 S1 |
| 完整性 | 指定字段或摘要要点齐全 |
| 可追溯性 | 行号真实存在，对应内容支持当前结论 |
| 不确定性 | 缺失项保持未知，推断与直接事实分开 |
| 执行状态 | 计划、未执行、成功和失败描述与实际结果一致 |
| 可用性 | 输出能被目标读者理解，实际文件能打开并继续使用 |
“有引用”还需要进一步检查：引用的资料是否存在、是否支持这条结论、是否覆盖所有关键结论。相应地，表格格式正确也只说明结构可读，不能证明其中数值正确。
独立检查与运行记录
模型自检可以帮助找出遗漏，但它仍可能沿用最初的误解。资料提取回到原文核对，计算用公式或脚本复算，文件处理打开实际产物，网页结论读取原页面。检查方式应能提供独立于回答措辞的依据。
每次实践可记录产品与环境、界面显示的模型及设置、日期、输入版本、完整任务要求、原始输出和检查结果。本篇的输入标识为 S1 / 00-logbrief-note；如果修改了材料，应另存版本，以便解释结果变化。来源、缺失值和结构化记录的完整契约将在第四、五篇建立。
一次成功只说明本次输入输出通过了检查。需要长期复用时，还应加入缺失、冲突和异常样例，保留失败结果。任务级评估与人工判断的配合可参考 Evaluation best practices；第九篇再系统讨论版本对照、重复运行与成本记录。
6. 学习顺序与专题入口
系列路线
本系列采用“一篇导读与九篇专题”的结构。前半部分建立人与模型的协作方法，后半部分再加入流程复用、工具和自动化。下表中的专题标题是写作计划，尚未完成的篇目不提供文章链接；已完成内容统一在系列入口更新。
| 顺序 | 篇目 | 主要练习与掌握结果 |
|---|---|---|
| 0 | 大模型应用基础与学习路径 | 区分资料、能力与结果，填写任务选择表 |
| 1 | 提示词结构与示例引导 | 改写摘要要求，建立可检查的单次任务 |
| 2 | 多轮协作与任务分解 | 按阶段形成比较报告，给出具体修订反馈 |
| 3 | 上下文组织与项目约束 | 保存项目规则和状态，新对话能继续任务 |
| 4 | 资料检索与事实核验 | 定位来源，保留版本、缺失与冲突 |
| 5 | 文件处理与输出规范 | 将证据准确映射到报告和结构化记录 |
| 6 | Agent Skills 的使用与评估 | 检查已有流程、依赖与实际执行效果 |
| 7 | 工具调用与 MCP | 理解参数、权限与结果，定位连接或执行问题 |
| 8 | Agent 工作流与自动化 | 保存状态，恢复失败任务并控制重复操作 |
| 9 | 结果评估与成本控制 | 用固定样例比较质量、耗时与消耗 |
阅读路径
主要做聊天协作的读者，可以先读第一至三篇，练习任务表达、反馈和交接。经常整理资料或文件的读者，再读第四、五篇，建立证据与字段约定。需要使用和评估已有流程时，进入第六篇；需要连接外部能力和持续执行时，再读第七、八篇。第九篇复用前文样例进行系统评估，各篇自己的验收无需等到系列末尾。
Skill 实操优先使用 Codex，具体环境与验证范围会在对应文章说明。缺少某项产品功能时，可以先手动粘贴小型资料、保存结果和执行检查；手动实践能支持方法学习，真实工具连接与自动执行则需要另外验证。
下一篇：提示词结构与示例引导。它继续使用 S1，从简单请求出发，逐步说明目标、材料、限制、输出与示例怎样配合，不要求本篇读者提前安装任何扩展。
7. 常见问题
冗长指令与缺失信息
增加角色设定、重复强调或延长 Prompt，不能补齐资料里不存在的许可证。应先检查缺少什么，再决定补充来源、澄清条件或保持未知。模板与示例应服务于已经观察到的问题，效果需要对照输出检查。
最新信息与实时访问
在请求中写“截至今天”，不会自动赋予搜索能力。需要当前结论时，应实际读取相应来源，记录日期与版本；如果当前会话不能检索，可以自行提供官方页面的相关内容，并将结果范围限定为该快照。
推断与事实
“说明只列出纯文本输入”可以直接提取；“因此它一定无法处理任何图片”扩大了结论范围。依据不足时，可以提出待验证的问题，或明确写为推断并说明条件。
计划与实际执行
给出代码、文件名或目录树，属于提出方案或生成内容。要报告保存成功，应找到实际文件并检查内容；要报告处理成功，应有成功的工具结果和符合要求的产物。失败返回也应保留，不能改写成“没有找到相关记录”。
自检与可靠性
让模型重读输出，有时可以发现遗漏，但自检不提供天然独立的证据。对于实验二，可以用 S1 的五处定位逐行检查；对于后续自动化，可以用原始记录和确定性检查辅助。准确表达尚未核验的部分，也是交付质量的一部分。
8. 方法速查
| 阶段 | 最小做法 | 可观察的结果 |
|---|---|---|
| 明确任务 | 写出目标、输入、能力、输出、验证 | 能解释完成条件 |
| 准备资料 | 保留原文、版本与定位，排除无关内容 | 关键事实可以回查 |
| 选择路线 | 匹配当前宿主的输入与工具能力 | 必要步骤有执行途径 |
| 提交要求 | 说明范围、读者、格式及缺失处理 | 输出约定清晰 |
| 核对结果 | 对照原文、计算或实际文件 | 错误与未完成项可定位 |
| 保存记录 | 保留输入、要求、输出和检查结论 | 后续能比较与继续 |
9. 实践练习
- 任务选择：分别为 S1 摘要、真实工具的当前版本查询、把摘要保存到本地文件填写“目标—输入—能力—输出—验证”表。验收标准：至少识别一个需要当前来源的结论和一个需要实际执行的步骤。
- 事实提取：独立完成实验二，再打开参考答案。验收标准：五个字段齐全，每条依据支持相应值，许可证保持“未提供”，没有把 1.2 写成当前最新版。
- 摘要核对：完成实验一，逐项标记遗漏或无依据内容。验收标准：用途、输入、输出和关键限制齐全；缺失耗时保持为空，输入保护被保留，待确认信息与摘要分开。
- 缺失资料：复制 S1 为新版本，删除 L3 和 L8，再提取相同五个字段；保留其余行号。验收标准：平台与许可证均为“未提供”，缺失判断写明检查了修改后的 S1，没有借用原版本或参考答案补齐。
- 执行状态：完成实验三，并给计划写一句状态说明。验收标准：能区分需求分析已完成与文件保存未执行，指出目录待确认，检查方法涉及实际文件与原始资料。
保存一份自己的运行记录，注明输入版本、产品、实际可见模型与设置、日期和各验收项结果。不方便创建文件时，可以先保存在普通笔记中；记录中的未知值与失败结果保留原样。
参考资料
以下为本文概念说明所用的官方资料，核对日期为 2026 年 10 月 4 日。API 文档中的预算和配置描述适用于对应接口，不能直接推定任意聊天产品的入口、账户能力或权限行为。
- Prompt engineering：任务指令、相关上下文与输出变化。
- Conversation state：对话状态与上下文窗口预算。
- Using tools：工具扩展能力及运行环境的差异。
- Build skills：Skill 的文件组织与按需加载。
- MCP server：MCP、外部工具与插件的关系。
- Model selection：质量、延迟、成本与产品支持范围。
- Evaluation best practices：任务级评估与人工核对方法；本文未使用其评估服务。
系列导航：大模型应用方法与实践；下一篇：提示词结构与示例引导。