write-instructions-zh

提示词编写

目标

让提示词在真实使用中持续产生用户期望的行为，并在模型、宿主和工具变化后，仍能以较低的维护成本保持这种效果的一致性。写出的指导既保留长期校准形成的有效经验，也能迁移到未列出的情境。

按需补充

为 ChatGPT 网页端项目创建、修改或审查项目指令时，读取 网页端项目提示词编写补充，与本 Skill 一起使用。该补充指导编写者适配项目的使用环境，不直接作为用户项目指令。普通网站开发或其他宿主的提示词任务不因此加载它。

为 Codex 编写或审查全局 AGENTS、项目规则、主 agent 与子 agent 的提示词、角色描述或 Skill 入口时，读取 Codex 提示词装配与分工。先区分目标 agent 已获得的正文、用于选择能力的描述和按需读取的材料，再决定规则放在哪里。主 agent 与子 agent 共用的规则按实际加载关系复用，角色正文补充职责差异。

确定提示词需要说明什么

从以下五个方面还原用户希望模型怎样工作。根据实际需要选择其中的内容，形成提示词的骨架。

• 目的： 希望通过这块提示词让模型做到什么。
• 背景： 模型理解任务和作出判断需要知道什么。
• 行动： 模型需要做什么。
• 结果： 模型做完后要交付什么，怎样判断已经完成。
• 边界： 需要保持什么，模型可以行动到什么范围，以及何时停止。

骨架与功能块

骨架是整份提示词最基础、最通用、可复用的工作设计，承载总体原则、目标和方向，以及基本工作所需的直接行动指导、禁止事项和边界。这些指导共同说明模型怎样工作、怎样判断和完成责任，并能用于未列出的情境。模型替换和版本迭代本身不改变骨架。用户需要的工作设计发生变化时，才据此调整骨架。

血肉由补充骨架的功能块（function chunk）组成，针对具体模型、环境或任务条件，进一步细化骨架中的规则。每块补充一项完整的判断或行为，可以使用具体说明、方法、例子或协议，其内容和粒度由实际需要决定。区分骨架和血肉时，看规则是共同的基础指导，还是针对特定对象和条件的补充。

例如，本 Skill 的通用审查属于骨架，“GPT模型专属审查”针对 GPT 的特点细化审查要求，属于血肉。只要相应特点和需要仍然存在，这个功能块就可以持续保留。

编写时先形成连贯、可直接指导工作的骨架，再根据实际需要补充功能块。每块都应明确它服务于骨架的哪项责任、在什么条件下需要，以及怎样帮助模型实现这项责任。功能块放在对应责任之下或目标模型能稳定获得的位置，具体文件组织服从实际使用方式。

维护时保持骨架的工作设计，分别复审功能块的必要性和适用条件。模型或环境变化后，根据实际表现决定各块继续保留、调整、替换或移除。移除前确认它补充的行为已经由骨架、模型能力、其他功能块或可靠机制承接，或者相应需要已经消失。新增功能块同样应有实际需要，并服从骨架的目标、责任和边界。

结构

提示词按稳定主题组织。标题直接说明本节的对象、情境或责任，使第一次阅读者只看目录就能定位内容。

结构应当表达规则之间的统摄关系。先找出一组规则共同服务的责任或判断，把共同原则写在上位，再把需要分别处理的差异放在它下面。不要只把原有句子拆成更多标题、段落或列表。

一个标题优先表达一个完整概念。内容能够独立展开且足以成节时再拆分，较短内容留在更大的自然主题中。

同一个判断能够用一句自然的话说清时，直接写成一句。内容包含多个独立规则或真实的从属、并列、步骤关系时，再用相应结构展开。

标题层级表达内容的真实从属关系。根据内容需要使用相应层级：

# A

## B

### C

# D

## E

没有先后关系的并列内容使用无序列表，从属内容放在对应的上位内容之下：

- 并列内容
- 并列内容
  - 从属内容

真实的步骤、阶段、优先级或判断顺序使用有序列表：

1. 第一步
2. 第二步
3. 第三步

多个独立规则分别写清，不用分号压成长句。章节可以长短不一，使用能够准确表达语义关系的最浅层级。根据实际内容选择需要的形式和层级。

编写流程

明确本次要改变的表现

先说清楚这次想让模型在哪种情况下改变什么表现。把现在已经做对、需要继续保留的部分也记下来，避免修一个问题时破坏其他效果。

对于已经成熟、规则较多或与其他提示词共同生效的提示词，在动笔前列出本次新增、修改、迁移和删除的规则。没有列入这些变化的当前规则和原文保持不变。工作中发现确实需要扩大范围时，先补充变化及原因，再修改新增范围。