write-instructions-zh

提示词编写

目标

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

确定提示词需要说明什么

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

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

长期维护时，骨架承载需要跨版本保持的内容。当前模型、宿主和工具所需的说明、例子和固定协议构成“血肉”。环境变化时，先核对骨架，再复审血肉。

结构

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

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

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

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

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

# A

## B

### C

# D

## E

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

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

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

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

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

编写流程

明确本次要改变的表现

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

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

用户已经发现某次或同一批修改擅自弱化、删除或增加规则，并要求继续排查时，不再要求用户逐条找出问题。本次范围包括检查这一批的全部差异，以及相同改法可能影响的其他位置。能够从当前规则、Git 和历史材料明确还原的内容直接列入恢复候选。证据冲突或者会改变用户当前目标时，再请用户决定。

用户会记得多次任务中发生过什么，当前模型通常只看到这一次。因此，用户反复指出的体验和实际代价是判断问题的重要线索。涉及文件状态、运行记录或失败原因时，再查看当前文件和记录核实。

先确认这次的问题能不能靠修改提示词解决。提示词里已经有相关规则，模型却仍然没有形成预期行为时，再判断是规则本身没有说清楚，还是问题根本不在提示词。问题不在提示词时，修改真正出问题的地方。

恢复现有提示词的来路

这一阶段是为了知道现有规则为什么存在，避免精简时删掉过去解决过的问题。

修改已经使用一段时间的提示词，先看当前文本、修改日志和保真并集。能从这些材料看清相关规则的目的和已经否决的路线，就可以开始写。只有看不清时，才继续查 Git 历史、旧版、备份或以前的会话。

对于成熟而且关联较多的提示词，维护一份不参与运行的当前规则说明，记下每项独立行为为什么存在、对应的历史案例和精确来源、删弱后会重新出现什么问题、当前由哪里承载，以及什么条件出现后才允许改变。建立这份说明时，从现有 Git 历史、修改日志、保真并集、旧版、备份、会话和其他相关文档中追溯。能够核实的内容写成事实，只能由材料共同支持的结论标明是推断。暂时无法还原理由的现有规则继续保留并标为待确认，不能自行补造原因，也不能因为来路尚未整理清楚就删除。

当前正文、当前规则说明和保真并集都是需要核对的材料，不因正在生效或被标成“当前”就自动正确。根据历史证据分别确认规则仍然有效、只在特定条件下适用、已经迁移、已经被取代、被用户否决、实验失败、暂停、尚未验证或仍然未知。当前规则与后来的用户决定、真实结果或可靠机制冲突时，把它列入修正或删除候选。不能用“现在就在正文里”证明它应该继续保留。

新建提示词没有这些历史，直接从真实用途和代表性例子开始，先写够当前使用的版本，不为假想的未来增加结构。