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