自定义 GPT 的价值，不是把一段超长提示词“永久保存”，而是把一个稳定任务拆成可维护的四层：任务边界、行为规则、知识资料和测试题。这样当结果不对时，你能知道该改规则、补资料，还是调整任务本身。
先选对容器：指令、项目还是自定义 GPT
| 工具 | 适合什么 | 不适合什么 |
|---|---|---|
| 自定义指令 | 你长期通用的表达偏好、输出格式 | 只服务于单一专业任务的大量规则 |
| 项目 | 一段时间内围绕资料持续推进的工作 | 需要对外复用、角色固定的助手 |
| 自定义 GPT | 角色、流程、资料和验收方式长期稳定 | 一次性临时任务或还没验证清楚的需求 |
如果你还没把任务跑通，先用自定义指令试出稳定的工作标准；若需要沉淀多个文件和对话，先在资料库管理流程中整理。稳定后再做成自定义 GPT，维护成本最低。
四层设计法
第一层：任务边界
用一句话说明“为谁解决什么问题，不解决什么问题”。例如：为课程运营整理学员反馈并输出可执行改进项；不替代教研结论，不编造未提供的数据。
第二层：行为规则
规则应该写成可观察的动作，而不是抽象形容词。与其写“专业、严谨”，不如写：
先复述任务目标；信息不足时提出不超过三个澄清问题；输出按“发现—证据—建议—风险”四段排列；无法从资料确认的内容必须标记为待验证。
规则负责“怎么做”，不要把长篇手册塞进这里。
第三层：知识资料
资料负责“依据什么回答”。优先上传或整理结构清楚、标题明确、版本可追溯的文本资料。每份资料都写上用途、负责人、更新时间和适用范围；过期资料应替换或移除。不要把敏感信息、无授权内容或永远不会被查询的文件堆进去。
第四层：测试题
没有测试题，就无法判断助手是不是“看上去很聪明”。至少准备四类：
- 正常任务：验证它能否完成最常见的输出；
- 资料任务：验证它能否在给定资料里找到依据；
- 边界任务：验证它遇到不该回答的内容会不会乱答；
- 冲突任务：验证资料与用户要求矛盾时，它会不会指出矛盾并请求确认。
一个可直接改写的设计骨架
角色：你是【具体岗位】。
目标：帮助【具体用户】完成【稳定任务】。
输入：用户提供的【材料类型】与【必要字段】。
流程：先确认目标，再查阅相关资料，随后按【固定结构】输出。
边界：不处理【排除范围】；资料不足时明确说明缺口。
质量要求：每项建议必须对应到输入中的证据或待验证项。
结束动作：列出下一步需要用户确认的内容。
上线前做一次“失败演练”
故意给它模糊需求、过期资料、相互矛盾的要求和不在职责范围的提问。好的助手不应该为了显得有用而编造答案，而应能说明自己缺什么、该查什么、下一步由谁确认。
如果需要把输出进一步变成研究与判断材料，可接着使用深度研究的核验流程；任何看似完整的结论，仍应保留人工审阅与最终决策。
