> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bigmodel.cn/llms.txt
> Use this file to discover all available pages before exploring further.
# GLM 提示工程指南
> 在 GLM 上可以直接使用的通用提示工程方法：任务描述、上下文组织、输出控制、工具调用与结果验证。
好的提示词并不一定很长。更重要的是让模型理解**要完成什么、需要依据什么、哪些边界不能突破，以及如何判断任务已经完成**。
本指南整理了在 GLM 系列模型上可以尝试的通用提示工程方法，涵盖任务描述、上下文组织、输出控制、长上下文处理、工具使用、多步骤任务执行、长程 Agent 实践与结果验证。内容既适用于日常文本工作，也适用于 Coding、工具调用和 Agent 场景。
这些实践是可以直接使用并通过实际任务检验的**默认起点，而不是固定模板**。不同 GLM 模型在上下文容量、推理能力、工具调用和 API 参数等方面可能存在差异；涉及某一具体版本模型的功能、配置或经过验证的行为特点，应查阅对应的模型指南。本篇不将其他模型的经验直接视为 GLM 的已证实表现。
## 一、通用原则
### 1. 清晰、直接地描述任务
明确说明希望模型完成什么。任务越复杂，目标、范围和完成条件越应该具体。
可以把提示交给一位不了解项目背景的同事，请他仅根据提示执行。如果同事会反问“要改哪里、依据什么、做到什么程度、如何判断完成”，模型通常也需要这些信息。
如果希望模型做得更完整、更深入或更简洁，应直接说明，而不是依赖模型从模糊提示中猜测。对 Coding 任务，“超出预期”还应与范围控制平衡：可以要求完整实现和明显边界情况处理，但不应默认允许无关重构或功能扩张。
**效果较差：**
```
帮我改一下这个项目。
```
**效果更好：**
```
修复订单创建接口中的并发问题。
保持现有公开 API 和数据库结构不变。
只修改完成这个问题所必需的代码。
覆盖明显的并发边界情况。
完成后运行现有测试，并说明修改内容和验证结果。
```
已知的重要约束尽量尽早提供。如果存在会导致工作内容明显不同的关键歧义，可以先让模型澄清；不必让模型对已经明确的细节反复确认。
### 2. 提供必要的上下文与限制原因
在目标之外，补充真正影响回答的背景信息，例如任务用途、目标读者、当前情况和必须参考的材料。提供背景的目的是帮助模型理解任务，而不是单纯增加提示词长度。
除了说明“做什么”，还可以解释关键限制背后的原因。原因能帮助模型将规则泛化到未逐条覆盖的情况。
**效果较差：**
```
不要使用省略号。
```
**效果更好：**
```
该回复会被语音合成引擎朗读。省略号可能导致发音不稳定，因此请改写为完整句子。
```
**效果较差：**
```
帮我整理一下客户反馈。
```
**效果更好：**
```
我们正在为下周的产品评审会整理客户反馈。
请根据下方材料归纳主要问题，合并相似反馈，
并在每个问题后标注对应的原始反馈编号。
不要把推测当成客户已经明确提出的需求。
客户反馈：
[粘贴反馈内容]
```
只提供与判断、执行或输出相关的上下文。如果缺少完成任务所必需的信息，应明确指出信息缺口，而不是凭空补全。
### 3. 控制任务范围
长程任务给了模型更多调查、修改和优化的空间，也更容易发生范围扩大。任务明确时，应同时说明**要做什么**和**不属于本次工作的内容**。
```
完成当前请求所需的工作，并保持在既定范围内。
不要增加未要求的功能，也不要重构与任务无关的代码。
如果发现会实质改变任务范围的问题，再向我确认。
```
这里的目标不是限制模型解决问题，而是避免把“可以顺便做”变成“必须一起做”。任务范围和完成条件越明确，越容易评估最终结果。
### 4. 使用少量有代表性的示例
当文字描述不足以准确表达输出格式、语气、行为边界或分类标准时，可以提供少量有代表性的输入输出示例。
示例应满足三个标准：
1. **相关**：贴近真实输入、真实输出和业务边界；
2. **多样**：覆盖常规情况、边界情况和容易误判的情况；
3. **结构化**：将指令、示例和待处理输入分开，避免示例中的事实被当作当前事实。
对分类、抽取、格式转换等任务，可以从少量示例开始；示例数量不是目标，覆盖关键差异才是目标。不要为了追求数量而堆叠相似样本。
**效果较差：**
```
汇报要简洁。
```
**效果更好：**
```
问题：修改是否完成？
期望回答：
已完成。修改了 2 个文件，相关测试全部通过；未进行生产环境验证。
```
示例中的事实和数字只表示期望的表达形式，实际汇报仍必须依据本轮真实执行结果。
### 5. 给复杂提示建立清晰结构
当提示同时包含任务要求、背景、参考资料、示例和输出约束时，可以使用分段结构把不同内容区分开，避免指令与待处理数据混在一起。
Markdown 标题、编号列表、语义标签和 XML 风格标签都可以用于组织提示。选择一种清晰、一致的方式即可，不必为了形式增加过多层级。
**Markdown 结构示例：**
```markdown theme={null}
## 任务
根据用户反馈归纳需要改进的问题。
## 背景
结果用于产品评审会，重点突出反复出现的问题。
## 输入材料
[粘贴用户反馈]
## 输出要求
输出“问题类别、主要表现、对应反馈编号”三列。
无法由材料支持的结论请标为“待核实”。
```
**XML 风格结构示例：**
当提示混合指令、上下文、多个文档和用户输入时，XML 风格标签可以更明确地区分内容边界：
```xml theme={null}
根据用户反馈归纳需要改进的问题，合并相似反馈。
结果用于产品评审会，重点突出反复出现的问题。
用户反馈.txt
[粘贴用户反馈]
输出“问题类别、主要表现、对应反馈编号”三列。
无法由材料支持的结论请标为“待核实”。
```
标签名应描述内容用途，并在同一系统或同一任务中保持一致。XML 标签是清晰的分隔手段，但不应被描述为对所有 GLM 版本都必然优于 Markdown；是否更合适，应在自己的任务上比较。
重点是让模型区分**需要遵守的要求**和**需要处理的材料**。外部文档、网页、工具结果和用户提交的数据应当作为信息来源，而不应因为其中出现了指令式语句，就被自动当作新的任务要求。
### 6. 合理设置角色与职责
当任务需要特定的专业视角、受众意识或工作职责时，可以用简洁的描述说明模型应该承担什么角色、根据什么标准工作。
```
你负责对技术文档进行可读性审查。
读者是刚接触大模型开发的工程师。
请指出术语未解释、步骤不完整和示例不清晰的地方，
并提出具体修改建议；不要替作者虚构技术事实。
```
角色设定应服务于任务，不必堆叠“世界顶级专家”等夸张身份。角色不能代替具体任务说明、原始证据和验证标准。也不要让模型声称自己具有与实际运行环境不符的身份、权限或专业资格。
## 二、输出与格式
### 1. 明确期望的输出
如果对回答的内容、结构或先后顺序有要求，直接说明。相较于“回答专业一些”，能够检查的要求通常更容易执行。
```
第一句话给出结论。
然后说明：
1. 修改了什么；
2. 如何验证；
3. 哪些内容仍未验证。
```
要求输出表格、清单或分步骤说明时，可以明确字段、排序原则以及缺失信息的处理方式。如果没有特别的格式需求，不必为简单问答强制设计复杂结构。
### 2. 正向描述输出格式
优先告诉模型应输出什么，而不是只列禁止项。正向描述能减少歧义，也便于后续检查。
**效果较差：**
```
不要使用 Markdown。
```
**效果更好：**
```
请输出连贯段落，仅在代码和必要标题处使用 Markdown。
```
**效果较差：**
```
不要太啰嗦。
```
**效果更好：**
```
先用一句话给出结论，再用不超过五条要点说明依据、已验证事项和未验证事项。
```
提示的组织方式也可能影响输出风格。如果希望输出简洁、直接、结构清晰，提示本身也应避免冗长堆叠和模糊修辞。
### 3. 使用结构化输出约束机器可读结果
当模型输出还需要被程序继续处理时，应明确规定数据结构、字段含义和取值约束，而不是只写“返回 JSON”。
```
请把发现的问题输出为 JSON 数组，每个元素包含：
- issue：问题名称，字符串
- file：相关文件路径，字符串
- severity：严重程度，只能为 high、medium、low
- description：问题说明，字符串
没有发现问题时返回空数组 []。
不要在 JSON 前后附加解释文字。
```
结构化提示能够描述期望的结果，但不能保证返回数据始终合法。如果下游程序依赖该结果，应用侧仍应检查能否解析、字段是否完整、类型与取值是否正确，以及是否满足业务约束。模型特定的结构化输出 API 配置不属于本篇范围。
### 4. 控制回答长度与信息密度
输出控制不只是让内容更短，还包括保留必要信息、避免重复，以及让答案适合实际使用场景。
```
覆盖完成任务所需的实质内容。
避免重复摘要、模板化填充和与任务无关的扩展。
```
如果需要详细教程，可以要求解释关键概念、操作步骤和判断标准；如果只需要结果汇报，可以约束为结论、依据和未完成事项。
对报告、演示稿或可视化文档，应明确受众、结构、设计约束和交付格式。不要只写“做得好看”或“专业一些”。
## 三、上下文与信息处理
### 1. 组织长文档和多来源信息
处理长文档或多份资料时，先明确**材料边界和来源**，再告诉模型要查找、比较或提取什么内容。不同资料中的事实与结论不要混在一起。
建议为每份材料标注：
* 来源；
* 时间；
* 版本；
* 适用范围；
* 可信度或权威性，如果会影响判断；
* 是否为不可信用户输入或工具返回结果。
**多文档比较示例：**
```xml theme={null}
请比较下面两份方案，只分析三个方面：
实验目标、评价指标、风险控制。
输出差异表，并在每条差异后标明资料来源。
如果某份资料没有提到相关内容，请写“原文未说明”，不要补写。
方案A.md
[粘贴资料 A]
方案B.md
[粘贴资料 B]
```
当材料特别长时，可以先定位相关部分、记录出处，再开展归纳和比较。建议：
1. 先查找与问题直接相关的段落；
2. 为每条结论保留来源或原文位置；
3. 区分“原文明确支持”“合理推断”“外部知识”“无法确认”；
4. 对冲突信息不要强行合并，应说明冲突及来源；
5. 材料超过上下文或预算时，使用检索、分批摘要或局部读取；
6. 验证关键段落确实进入了上下文。
长材料的布局可以作为实验变量，例如材料前置、查询前置、分段检索后局部引用。不同模型和任务类型的最优布局可能不同，应以自己的 GLM 任务评测结果为准，不直接沿用其他模型的结论。
### 2. 基于原始资料回答，区分事实与推测
对于代码库、文档、数据和其他已有材料，应尽量基于真实内容回答，而不是只根据文件名、记忆或用户概述猜测实现细节。
```
先检查与问题直接相关的原始资料。
根据实际内容给出结论，并说明关键依据。
没有检查到或无法确认的内容，请明确说明，不要猜测。
```
对于 Coding 任务，可以进一步明确：
```
回答前先读取与问题直接相关的文件。
基于实际代码说明结论。
没有检查到的实现不要猜测。
```
修改代码前也应先了解相关实现、调用关系和约束，再决定如何修改。必要时将信息分为：
* **已确认的事实**：来自当前代码、日志、测试或权威材料；
* **合理推断**：有依据但尚未直接验证；
* **尚待验证**：缺少证据或存在冲突。
工具返回失败时，不要把预期结果当作已发生结果。
### 3. 研究与信息收集
研究型任务应先定义成功标准：需要回答什么、可接受来源是什么、时间范围是什么、是否要求交叉验证、结论需要达到什么确定程度。
执行中可以：
1. 维护多个竞争假设；
2. 为每个假设记录支持证据和反对证据；
3. 对高风险或事实敏感结论进行多来源验证；
4. 保留来源链接或文档位置；
5. 输出时区分事实、推断和不确定项。
不要把单一检索摘要、单一模型回答或未经验证的二手转述当作最终事实。
## 四、工具使用
### 1. 说明工具为什么以及何时使用
工具描述不应只有名称和参数，还应让模型知道工具解决什么问题、何时需要调用，以及什么情况下不应该调用。
```
当用户询问具体订单的支付、发货或物流状态时，
先调用订单查询工具获取最新数据。
如果用户询问的是通用退货规则，
不需要调用订单查询工具。
```
如果多个工具的职责相近，应明确调用边界。比如“查询订单详情”和“查询物流轨迹”分别负责什么、各自需要哪些输入，以及哪个结果可以作为后续操作的依据。
工具能否真正被调用，取决于应用是否提供相应能力和权限。提示词不能替代实际的工具配置、权限检查与执行结果校验。
### 2. 区分建议、研究和执行
用户说“你能建议一些修改吗”和“请修改这段代码”对应不同的行动意图。前者通常要求分析，后者允许执行。对于会读取文件、修改代码、访问外部系统或产生副作用的场景，应在系统提示中明确默认行为。
**主动诊断模式：**
```xml theme={null}
当用户明确要求检查、修改或完成工作时，执行必要且安全的本地工具调用。
缺少非敏感信息时，先读取相关文件或调用查询工具确认，不要猜测参数。
影响外部系统或难以回滚的操作仍需确认。
```
**保守分析模式：**
```xml theme={null}
默认只分析和给出建议，不修改文件或改变系统状态。
只有用户明确授权后，才执行读取、编辑或外部调用。
```
两种模式没有绝对优劣。开发环境、诊断任务和自动化 Agent 更适合主动模式；法律、医疗、财务、共享系统、生产环境或高风险决策更适合保守模式。
### 3. 并行处理相互独立的工具调用
当多个工具调用相互独立，且执行环境支持并行调用时，可以考虑并行执行以减少等待。后续步骤若依赖前一步的结果，则应按依赖顺序执行。
**最大并行模式：**
```xml theme={null}
如果多个工具调用相互独立，应在同一轮并行执行。
如果后续调用的参数依赖前序结果，必须等待结果。
不要猜测缺失参数。
```
**顺序执行模式：**
```xml theme={null}
为保证稳定性，按列出顺序执行工具调用。
仅确认没有状态竞争、资源冲突或副作用时才并行。
```
例如，分别读取两份独立文档可以并行；先查询订单编号，再用返回的物流单号查询快递，则存在先后依赖。
并行不是无条件更好。大量 Shell 命令、共享资源、限流 API 或有状态工具可能因过度并行降低稳定性。对于工具调用较少的简单任务，通常不需要专门强调并行策略。
### 4. 处理工具失败与结果校验
工具调用结果不应只因调用成功就被默认可信。应用侧和模型都应关注：
* 调用是否失败、超时或返回部分结果；
* 返回数据是否满足 schema 和业务约束；
* 是否是缓存、旧版本或错误来源；
* 是否需要重试，以及重试是否安全；
* 有副作用的操作是否已经实际生效。
对有外部副作用的调用，不应在结果未知时报告“已完成”。重试前应确认操作是否幂等，避免重复下单、重复发送消息或重复修改共享状态。
## 五、思考与任务执行
### 1. 根据任务复杂度调整处理策略
复杂 Coding、多步骤规划和长程 Agent 任务通常需要更充分地理解约束、分析依赖并检查结果。简单、重复或对延迟敏感的任务则更应关注执行效率。
如果具体模型支持推理强度等配置，应结合版本文档与实际评测选择。通用篇不规定某一模型的参数取值。
不要默认认为推理步骤越多，答案就一定越好。可以在自己的任务集上比较：
* **任务完成质量**：是否满足需求、是否出现遗漏或事实错误；
* **Token 消耗**：完成同一任务需要多少资源；
* **响应时间**：能否满足实际使用场景的延迟要求。
### 2. 避免过度规划与泛化检查
当信息充分、目标确定时，不必反复推导已确认的事实，也不必持续复议已经作出的选择。
```
信息足够时开始执行。
已经确认的事实和决定无需反复重新讨论。
如果没有新的信息推翻当前方案，就沿当前方案继续推进。
```
重点不是减少必要思考，而是让思考服务于下一步行动。
在已经有明确验证步骤的任务中，连续加入“再仔细检查一次”“一定要确认没有问题”等重复要求，不一定比给出具体检查项更有效。
```
完成后确认：
- 相关测试是否通过；
- 是否修改了任务范围外的文件；
- 是否仍存在未经验证的假设。
```
有具体检查目标，模型才能更清楚地判断何时完成，以及哪些问题需要继续处理。
### 3. 避免过度工程
最小正确实现优先。不要为了展示完整性而引入不必要的复杂度。
应注意：
* 不为一次性逻辑创建抽象；
* 不修改与任务无关的文档、类型或格式；
* 不为不可能发生的输入添加防御分支；
* 错误处理和输入校验应集中在系统边界，例如用户输入、外部 API、文件解析和网络响应；
* 不设计假想的未来需求；
* 复杂度以解决当前问题所需的最小量为宜。
如果复杂度是解决问题所必需的，应在汇报中解释原因，而不是为了避免复杂度而牺牲正确性。
## 六、长程 Agent 实践
### 1. 持续维护任务状态
对于跨多步骤、长时间运行的任务，应保留当前目标、已经完成的工作、关键决定和剩余事项，避免上下文变化后重复劳动或遗漏约束。
可以使用两类状态记录：
* **自由格式进度笔记**：例如 `progress.md`，记录总体进展、关键决策、阻塞和下一步；
* **结构化状态数据**：例如 `tasks.json` 或 `tests.json`，记录任务、测试、验证结果和依赖关系。
建议记录：
* 当前目标；
* 已完成的重要工作；
* 已确认的决定及原因；
* 尚未完成或待验证的事项；
* 关键文件、命令、日志或来源。
不要把代码库中已有的信息大段重复复制进状态文件；旧信息失效后应更新或删除。状态文件只有在被实际保存、读取和维护时才能发挥作用，不能仅凭提示词假设模型会自动保留跨会话状态。
### 2. 跨上下文恢复
长任务可能跨越多个上下文窗口、会话或执行环境。恢复任务时，应先重建状态，再继续实现。
可以要求：
```
确认工作目录和权限。
读取 progress.md、tasks.json 和 git 状态。
运行基础测试或检查脚本。
核对原始目标、已完成事项和未完成事项。
再继续实现新改动。
```
对于大型任务，可以准备初始化脚本，用于安装依赖、启动服务、运行基础测试或生成必要环境，减少新上下文中的重复准备工作。
如果使用 git，应利用提交、分支和变更记录作为状态检查点。不要把未解释的无关变更混入任务提交。
### 3. 平衡自主性与安全边界
本地、可逆、低风险操作可以直接执行，例如读取文件、编辑工作区文件、运行测试。以下操作应先确认或遵循平台权限：
* 删除数据、重置分支或清空数据库；
* 强制推送、改写已发布历史；
* 修改共享基础设施；
* 向外部服务发送消息或提交表单；
* 创建持久凭据或修改权限；
* 安装软件；
* 任何难以回滚、影响生产系统或影响他人的操作。
遇到障碍时，不应使用破坏性捷径绕过验证或安全检查。提示词可以声明风险偏好，但不能替代应用侧权限控制、审计和人工审批。
### 4. 避免不必要的委派
子智能体适合处理真正独立、能够并行执行或需要隔离上下文的任务。对于几次工具调用即可完成的连续工作，没有必要只为使用“多 Agent”而额外拆分。
适合委派的情况：
* 子任务真正独立；
* 可并行执行；
* 需要隔离上下文；
* 需要不同专业工具或独立复核。
不适合委派的情况：
* 连续几步就能完成；
* 各步骤强依赖同一上下文；
* 单文件修改；
* 交接和整合成本高于并行收益；
* 用户未授权额外 Agent 或权限。
委派结果应回传明确结论、修改文件、验证证据和剩余问题，不能只回传模糊总结。使用多个 Agent 不应被视为结果一定更好的保证。
### 5. 使用复杂提示链
当单次调用难以保证质量，或需要在中间结果上人工审查时，可以使用提示链：
```text theme={null}
生成草案 → 对照标准审查 → 最小必要修改 → 程序化验证
```
每一步可以单独记录、评估或分支。常见模式是自我纠正：先让模型生成草案，再用明确标准独立审查，最后根据审查结果修改。
提示链的价值是可控和可观察，不是越长越好。对简单任务，拆链会增加成本和错误传递风险。
### 6. 管理临时文件
Coding Agent 可以为验证创建临时脚本、夹具或输出文件。这是合理行为，但如果用户要求最小变更或干净工作区，应明确清理策略：
```
为迭代创建的临时脚本、生成物和辅助文件，任务结束前应清理或集中说明。
不要把调试代码、无关重构或一次性脚本遗留在最终变更中。
```
不要为了减少文件数量而跳过必要的测试脚本或验证产物；应在“可验证性”和“最小变更”之间根据任务要求平衡。
## 七、验证与持续优化
### 1. 根据实际结果进行验证与汇报
任务完成与否，应以实际产物和验证证据为依据，而不是依据计划、推测或模型自己的口头承诺。
```
汇报进度前，先核对本轮实际执行结果。
已经验证的内容直接说明结果。
尚未验证的内容明确标记为未验证。
```
如果需要中间更新，只在发现重要信息、改变方向或完成关键阶段时简要汇报即可。最终汇报优先回答“结果是什么”，再补充过程和证据。
### 2. 让实现解决真实问题，而不是只适配测试
测试是验证实现的方法，而不是实现目标本身。
```
实现应解决实际问题，并对合法输入保持正确。
不要通过硬编码测试数据或只针对当前测试用例的特殊分支来通过测试。
```
不要修改或绕过测试来制造“通过”的结果。如果测试与需求明显冲突，应指出冲突并请求确认。
### 3. 对重要结果进行独立复核
对于高价值、风险较高或容易遗漏问题的任务，可以考虑用新的独立上下文复核结果。
```
请独立检查当前结果是否满足原始要求。
重点寻找遗漏、未经验证的假设和与任务范围不一致的修改。
不要默认接受已有结论。
```
独立复核可能发现新的问题，但不意味着它一定优于常规自检。是否增加复核，应根据任务风险、成本和实际评测决定。
### 4. 通过评测持续优化提示词
一次提示词有效，不代表它面对不同输入时都有效。更可靠的优化方式是先明确成功标准，再使用覆盖常见情况和边界情况的样本，比较修改前后的表现。
建议记录：
* **质量指标**：任务完成率、事实错误、遗漏等；
* **格式指标**：结构化输出是否合法、字段是否正确；
* **执行指标**：工具调用是否合理、是否完成必要验证；
* **效率指标**：响应时间、Token 消耗或调用成本；
* **安全指标**：高风险操作确认率、越权操作次数。
评测样本可以拆分为：
* **开发集**：用于迭代提示；
* **保留集**：不参与日常调参，用于回归验证；
* **边界集**：长输入、空输入、冲突来源、注入攻击、工具失败；
* **人工评审集**：用于质量、安全和用户体验评估。
```
请对照以下成功标准检查本次输出：
1. 是否覆盖用户要求的全部字段；
2. 是否存在无法由原始材料支持的结论；
3. 输出能否被下游程序正常解析。
先报告不符合项，再给出最小必要的修改建议。
```
模型自检可以辅助定位问题，但不应代替程序校验、人工复核或独立评测数据。具体指标、阈值和样本量，应由真实业务要求决定。
## 八、从其他模型提示迁移到 GLM
从其他模型迁移提示时，不要只替换模型名称。建议检查：
1. **删除模型专属参数**：不保留其他模型的思考、effort、预填充、工具批处理或其他 API 专属配置。GLM 应使用对应版本文档支持的参数。
2. **收敛过度触发提示**：旧提示中的“必须始终使用某工具”“如有疑问就多检查”可能导致过度调用或过度验证。改成具体触发条件和停止条件。
3. **重写身份与角色**：删除其他模型身份设定。角色只描述职责、读者和标准，不虚构专业等级或权限。
4. **调整结构标记**：Markdown、语义标签和 XML 风格标签都可以保留，但应在 GLM 任务上比较效果。
5. **检查长上下文布局**：比较材料前置、查询前置、分段检索和局部引用，而不是直接沿用其他模型的最优布局结论。
6. **加强验证**：JSON 输出必须程序化校验；Coding 任务必须运行可行测试；研究任务必须保留来源和不确定度。
7. **记录版本**：提示词变更、模型版本、参数、评测集和结果应一起记录，避免把版本差异误判为提示词效果。
## 九、综合示例
### 1. 普通文档处理任务
```markdown theme={null}
## 任务
阅读给定的研究方案，整理出“研究问题、实验步骤、评价指标”。
## 背景
这份总结将用于向不熟悉项目的同事介绍实验。
## 材料
[粘贴方案原文]
## 要求
1. 使用通俗中文，但保留原文的重要技术术语。
2. 每项结论标出对应的原文依据。
3. 对原文没有说明的信息标记“未说明”。
4. 不设计原文之外的新实验。
## 输出
先给一段简述，再给出结构化表格。
```
这个示例组合了任务目标、受众背景、材料边界、证据要求和输出格式，适合总结报告、分析资料或比较方案等工作。
### 2. 长程 Coding 任务
```
你负责完成当前代码任务。
先读取与问题直接相关的文件，基于实际实现再开始修改。
完成当前请求所需的全部工作，并保持在既定范围内。
不要增加未要求的功能，也不要重构无关代码。
如果存在会明显改变工作范围的关键歧义，再向我确认。
实现应解决真实问题，而不是只针对现有测试用例。
相互独立的工具调用可以并行；
存在结果依赖时按顺序执行，不要猜测缺失参数。
如果创建临时脚本或生成物，任务结束前应清理或说明。
完成后根据实际执行结果汇报：
先说明结果，再说明修改内容、验证情况和仍未验证的事项。
```
这个示例更适用于能够读取文件、修改代码和运行测试的开发环境。实际使用时，还应填入具体任务、项目约束和验收条件，不能把上述通用指令当成完整需求。
## 十、版本与验证说明
本篇只覆盖通用提示方法，不规定某一 GLM 模型的上下文长度、思考强度、采样参数、结构化输出 API 或版本专属能力。具体配置应以使用时的 GLM 官方文档为准。
本版新增的 XML 分区、正向格式约束、多来源证据判断和主动/保守工具模式，已在 GLM 代理环境中完成单次冒烟测试，行为符合预期。冒烟测试不是统计基准；生产使用前仍应在自己的任务集和 GLM 版本上评测。
好的提示词不需要一次写入所有技巧。更实用的做法是：**把目标说清楚，提供真正需要的上下文，明确关键约束与验证方式，再根据实际任务的结果持续迭代。**
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.