4 套 SOP，把你的 Agent 从“能用”调教成“好用”
0. 这篇文章在说什么
在 GPT-6 Astra 发布之后，延伸出了很多玩法。刚开始是 3D 模型提示词，第二天又出现了很多优化工作环境或工作流的提示词。
我收集了 X 上一些针对 Codex 的提示词，然后把它们喂给了 ChatGPT，让它做了一次汇总、分类和融合，最后就有了这篇文章里的 4 个很标准的 SOP。
在此对这些 X 友表示感谢！X 友的名单和参考链接统一放在文末。
从年初开始，Skill 得到了爆发式的增长。很多人在 Agent 里面安装了大量的 Skill，可能有几十个甚至上百个。但在这些 Skill 当中，频繁使用的可能不到 10 个。
所以大部分人在 Agent 运行之前，可能要加载非常无用且冗余的信息（比如这些 Skill）。还有一点就是，Skill 可能和 Agent 本身的一些 AGENTS.md 文件发生冲突。
所以这几个 SOP 就是给咱们 Agent 的运行环境做一下评估，顺便给它“减减肥”、理清做任务之前的头绪！
这些 SOP 最初是针对 Codex 使用的，当然也可以用在其他 Agent 里面。
但是用的时候要注意看一下，因为不同的 Agent 底层的一些配置文件可能叫法不同，有的叫 AGENTS.md，有的叫 CLAUDE.md。
下面是几个核心原则：
- Skill、AGENTS.md 和任务提示词都会影响 Agent 的行为。
- Skill 描述应尽量短，并采用渐进式披露，不要把所有细节一次塞进上下文。
- AGENTS.md 是持续生效的规则，因此应定期重新审视，而不是不断堆积。
- 不要为了弥补旧模型的不足而保留已经没有必要的规则。
- 要区分真正的安全边界与无意中造成的反复确认。
- 如果希望 Agent 持续完成任务，应提前定义完成标准，而不是让它做完第一版就停下来等待审核。
- 重复 Prompt 应逐渐沉淀为 Skill；确定性的人工重复步骤可以进一步脚本化、自动化。
- 经验沉淀后必须用真实任务重新跑一遍，确认修改确实改善了行为。
- HANDOFF.md 更适合记录跨会话的临时状态；ARCHITECTURE.md 更适合记录项目结构与数据流。
SOP 1：Agent 环境全面体检与重构
什么时候使用
满足以下任一条件时使用：
- 新模型发布；
- Agent 经常反复确认；
- Agent 经常提前停止；
- Agent 经常读取大量无关文件；
- Skills 越装越多；
- AGENTS.md 越来越长；
- 不确定哪些规则还有效；
- 项目已经使用 Agent 很长时间，需要一次环境评估。
**不要把它作为每次任务的固定启动流程，**它只是“环境维护”流程。
第 1 步：只做审计，不修改
把下面整段直接复制给 Agent。
请对当前 AI 协作环境做一次“Agent 工作环境审计”。
目标不是增加更多规则，而是找出已经没有必要、互相冲突、重复、过时，或者会不必要地限制模型判断与执行的内容。
本轮只分析，不修改任何文件，不删除或安装 Skill，不写入长期记忆。
请重点检查以下内容：
1. AGENTS.md
2. 当前项目中的 Skill 及其描述、触发条件和内部流程
3. 项目级 workflow / instructions / rules
4. 与跨会话工作有关的文档（例如 HANDOFF.md）
5. 项目架构说明（例如 ARCHITECTURE.md）
6. 当前模型和工具实际可执行的范围
7. 如果当前环境存在长期偏好或类似持久化规则，也只在确实可访问且与本项目相关时检查
请遵循以下原则：
一、区分“实际生效的规则”和“仅供参考的材料”
不要把所有 Markdown、历史文档和说明都视为同等优先级的约束。
二、重点寻找以下问题：
- 冲突的规则
- 重复的规则
- 已经没有必要的旧规则
- Skill 触发条件过宽
- Skill 描述过长
- 多个 Skill 之间存在重叠或“抢任务”
- 把本应由模型判断的事情硬编码成固定流程
- 每次任务都要求读取大量文档
- 每一步都要求人工确认
- 过于保守的审批边界
- 会导致 Agent 提前停止的措辞
- 会导致过度探索、扩大修改范围或迟迟不交付的规则
- 把临时状态、项目知识和永久规则混在一起的文档
- 为过去模型能力不足而保留、但现在可能已经没有必要的提醒
三、不要简单按照“文件越长越不好”来判断。
请结合实际使用场景判断。
如果某条规则确实有价值，就保留。
如果没有明确问题，不要为了凑数量而提出修改。
四、特别检查“决策边界”：
区分：
- 真正需要我批准的事情
- 为了安全而有意设置的保障
- 过去因为模型不可靠而设置、现在可能已经过度的限制
- 会导致 Agent 在我明确希望它继续执行时停下来的措辞
五、特别检查“持续执行”：
找出那些会让 Agent 在完成第一版后过早停下、等待人工审核的规则。
同时不要删除真正需要人工决策的审批边界。
请输出：
A. 最重要的问题（按实际影响排序）
B. 每个问题的：
- 文件 / 规则来源
- 相关原文
- 实际可能造成的影响
- 是已观察到的问题还是推测风险
- 建议如何修改
C. 哪些内容应该保留
D. 哪些内容应该合并
E. 哪些内容应该迁移到 Skill / 文档 / SOP / Script / Automation
F. 哪些内容不应该修改
最后给出一份“修改草案”，但不要执行。
修改方案必须遵循：
“最小必要约束”，而不是“规则越少越好”。
另外，不要因为模型能力增强，就自动删除安全边界、授权要求、生产环境保护、数据保护或其他明确的风险控制措施。
这一轮结束后你应该得到什么
你应该得到一份“审计报告”，而不是一堆被 AI 擅自修改过的文件。
此时不要立刻让它继续改。
先人工判断：
- 它指出的问题是否真实？
- 它是不是把安全规则误判成冗余规则？
- 它是不是把你的明确偏好误判成过度限制？
- 它是不是为了“优化”而删除了你真正需要的约束？
第 2 步：确认修改范围
如果审计结果合理，再让 Agent 修改。
直接复制：
根据上一轮审计结果，只执行我认可的修改范围。
执行要求：
1. 不擅自扩大修改范围。
2. 保留明确的安全边界、授权要求、生产环境保护和数据保护规则。
3. 删除或合并已经确认没有实际价值的重复、冲突或过时规则。
4. Skill 描述尽可能简短，并明确说明“什么时候应该使用”。
5. 对包含多个工作流的 Skill，优先采用渐进式披露：
根文档负责路由，具体细节放到需要时才读取的支持文档或脚本中。
6. 不要把本应由模型判断的事情继续硬编码成大量机械步骤。
7. 不要要求每个任务都读取与当前任务无关的大量文档。
8. 不要为了减少规则而删除真正有价值的项目约束。
9. 保留可恢复的旧版本或变更前备份。
10. 修改完成后，检查实际文件内容，确认没有产生新的冲突或重复。
完成后告诉我：
- 修改了什么
- 删除了什么
- 合并了什么
- 哪些内容保留不变
- 哪些改善需要通过真实任务继续验证
第 3 步：重新跑“历史卡点任务”
这是整个 SOP 中非常重要的一步。
不要只问 Agent：
“现在是不是变好了？”
而是找以前真实发生过的问题。
至少准备 3～5 个：
- 以前经常反复确认的任务
- 以前经常提前停止的任务
- 以前经常读取大量无关内容的任务
- 以前经常修改错误文件的任务
- 以前经常漏掉验证的任务
让 Agent 在新的独立会话中重新完成这些任务。
观察：
- 多余确认是否减少？
- 真正的审批是否仍然存在？
- 是否更快找到相关信息？
- 是否仍然会执行无关工作？
- 是否能够完成整个任务？
- 是否会验证结果？
- 是否出现新的问题？
SOP 2：把重复工作变成 Skill / SOP / Script / Automation / Agent
什么时候使用
当你发现：
“这个事情我已经让 AI 做过很多次。”
或者：
“我每次都要重新解释同一套流程。”
就启动这个 SOP。
第 1 步：让 Agent 做工作流审计
直接复制：
请对我过去的实际工作进行一次“工作流复用审计”。
目标：
减少重复说明、重复决策和重复返工，并把已经稳定的经验沉淀到合适的位置。
请不要为了数量而强行寻找问题，只提取有证据支持的高价值内容。
请重点寻找：
1. 反复出现的任务
2. 反复出现的决策
3. 反复出现的操作步骤
4. 经常发生的返工
5. 经常导致 Agent 卡住的地方
6. 经常需要我重复说明的要求
7. 已经比较稳定、值得复用的经验
对每一项都区分：
- 通用方法
- 项目特定做法
- 一次性的临时做法
并说明判断依据。
然后把发现的内容按照下面的方式分类：
A. 应该成为规则 / AGENTS.md 的内容
B. 应该成为 Skill 的内容
C. 应该成为 SOP / 文档的内容
D. 适合做成 Script 的确定性步骤
E. 适合做成 Automation / 定时任务的工作
F. 适合做成 Agent 的、需要模型判断的工作
G. 暂时不值得沉淀的内容
对最值得沉淀的项目，说明：
- 触发条件
- 输入
- 核心步骤
- 输出
- 需要人工判断的地方
- 错误代价
- 验收标准
优先复用已有能力，不要为了“系统化”而新建大量 Skill。
最后选出最值得沉淀的 3 项。
第 2 步：决定沉淀方式
使用下面这条判断规则：
| 如果它是…… | 优先考虑 |
|---|---|
| 永久有效的项目约束 | AGENTS.md |
| 特定任务才需要的稳定流程 | Skill |
| 人和 AI 都需要查阅的知识 | 文档 / Wiki |
| 完全确定、无需判断的操作 | Script |
| 固定时间自动执行 | Automation / cron |
| 需要观察、判断、选择的复杂任务 | Agent |
| 当前正在进行的临时状态 | HANDOFF.md |
一个特别重要的原则
不要把所有东西都做成 Skill。
如果一个操作可以用 20 行稳定脚本准确完成，就没有必要创建一个几十页的 Skill，让模型每次都重新理解它。
第 3 步：创建 Skill 时采用“最小路由 + 渐进式披露”
不要直接让 Agent 写一个巨大 Skill。
使用：
请根据上一轮确定的工作流创建一个 Skill。
要求：
1. Skill 描述必须短，并明确说明什么时候应该使用。
2. 不要把所有背景知识和操作细节塞进 Skill 主文档。
3. 主文档只负责：
- 判断是否应该触发
- 给出最必要的执行原则
- 指向需要时才读取的支持文档、模板或脚本
4. 将只有特定情况下才需要的信息放到支持文档。
5. 将确定性的重复操作优先做成脚本，而不是让模型机械执行。
6. 不要为了覆盖所有可能情况而加入大量“如果……那么……”。
7. 给模型足够的方向，让它自行判断当前任务的合理执行方式。
8. 明确最终验收标准。
9. 不新增与现有 Skill 重叠的能力；如果已有 Skill 可以承载，就优先修改已有 Skill。
完成后先展示：
- Skill 的触发条件
- 主文档
- 支持文档结构
- 脚本结构
- 与现有 Skill 的关系
确认结构没有冲突后再写入文件。
SOP 3：新项目 / 大型项目的 Agent 上下文建立
什么时候使用
适合：
- 新接手项目；
- AI 第一次进入大型代码库；
- 项目长期维护；
- 经常换会话；
- 多个 Agent / 多个模型共同工作。
第 1 步：建立 ARCHITECTURE.md
直接复制：
先不要修改代码。
请先理解当前项目的结构。
阅读项目入口、主要模块、关键依赖和数据流，只读取理解当前架构所必需的内容，不要为了形式完整而遍历整个代码库。
然后生成或更新 ARCHITECTURE.md。
内容至少包括：
1. 项目用途
2. 项目入口
3. 主要模块
4. 模块之间的关系
5. 核心数据流
6. 关键依赖
7. 重要外部服务或接口
8. 最容易出问题的两个位置
9. 当前架构中值得特别注意的约束
用 Mermaid 绘制：
- 项目模块关系图
- 核心数据流图
要求：
- 不要凭空推测；无法确认的地方明确标记。
- 不要把 ARCHITECTURE.md 写成代码库百科全书。
- 只记录对后续 Agent 工作真正有帮助的架构信息。
- 不修改业务代码。
完成后先给我总结，再等待我决定是否进入实现阶段。
注意
这一步只适合：
建立或重大更新架构认知。
不要每次修一个按钮都让 Agent 重新生成整个架构文档。
第 2 步：建立 HANDOFF.md
当一个长任务准备结束时，直接使用：
在结束当前长会话之前，请把当前任务整理成 HANDOFF.md。
只记录下一次会话真正需要知道的信息：
1. 当前任务目标
2. 已完成内容
3. 当前未解决的问题
4. 已经做出的重要决策
5. 下一步计划
6. 已知的坑和失败尝试
7. 如果下一次继续工作，最应该先检查什么
要求：
- 不要复制整个聊天记录。
- 不要把永久规则写进 HANDOFF.md。
- 不要把完整项目架构写进 HANDOFF.md。
- 只记录当前工作的状态。
- 如果某项信息已经稳定存在于其他项目文档中，只引用它，不重复复制。
下一次新会话：
先读取 HANDOFF.md。
根据其中记录的当前状态继续工作。
不要重复已经完成的工作。
不要把 HANDOFF.md 中的临时状态自动当成永久规则。
如果发现 HANDOFF.md 与当前项目实际状态不一致，以当前项目实际状态为准，并指出差异。
SOP 4：从一次工作到 Agent 化闭环
什么时候使用
当你发现某项工作：
有明确业务价值 + 经常重复 + 涉及多个网站/工具/步骤 + 人工耗时明显
就不要只创建一个 Prompt。
应该走下面的流程。
第 1 步：完整做一次真实工作
让 Agent 实际完成任务：
请实际完成这项工作：
[在这里写具体工作]
要求：
1. 实际完成任务，而不是只告诉我理论上应该怎么做。
2. 记录过程中真正发生的步骤。
3. 记录使用了哪些工具。
4. 记录需要哪些输入资料。
5. 记录最终交付了什么结果。
6. 记录哪些地方需要人工判断。
7. 记录哪些地方最耗时。
8. 记录哪些地方容易出错。
9. 记录哪些步骤实际上是确定性的、可以机械化执行的。
10. 不要为了形成 SOP 而虚构不存在的步骤。
完成工作后，再整理 SOP。
第 2 步：从真实执行结果生成 SOP
根据刚才真实完成的工作，生成一份可以重复执行的 SOP。
要求：
1. 只记录刚才实际发生并验证过的流程。
2. 区分：
- 确定性步骤
- 需要模型判断的步骤
- 必须人工决定的步骤
3. 写清楚：
- 输入
- 操作
- 输出
- 验收标准
- 异常情况
4. 标出最耗时和最容易出错的地方。
5. 不要为了让 SOP 看起来完整而增加未经验证的步骤。
第 3 步：判断哪些部分应该 Agent 化
然后使用：
现在对刚才这套真实 SOP 做一次 Agent 化评估。
逐步骤分析：
1. 当前人工耗时
2. 出错会造成什么损失
3. 涉及哪些工具
4. 是否需要访问外部系统
5. 是否需要人工判断
6. 自动化难度
7. 第一版能够自动完成到什么程度
8. 哪些部分应该保留人工参与
然后把流程拆成：
A. Script 可以完成的部分
B. Skill 可以指导的部分
C. Agent 需要判断的部分
D. Automation 可以定期执行的部分
E. 必须人工批准的部分
优先考虑 30 天内有机会节省时间或产生实际价值的部分。
不要为了追求“全自动”而强行自动化。
五、四套 SOP 之间的正确关系
不要理解成：
每次都执行四套。
正确关系是：
模型升级 / 环境变乱
↓
SOP 1：环境体检
↓
规则 / Skill 重新整理
↓
┌─────────────────┴─────────────────┐
↓ ↓
SOP 3：项目认知 SOP 2：工作流挖掘
↓ ↓
ARCHITECTURE.md Prompt / SOP / Skill
↓ ↓
└─────────────────┬─────────────────┘
↓
SOP 4：Agent 化
↓
Script / Agent / Automation
↓
真实任务验证
↓
发现新的问题
↓
再进入 SOP 2 / 1
六、最重要的“不要做什么”
1. 不要把四套 SOP 全塞进 AGENTS.md
这是最重要的一条。
AGENTS.md 是持续生效的环境规则。
不要把：
- 环境审计流程
- 工作流审计流程
- 架构生成流程
- Agent 化流程
全部写进去。
否则每次普通任务都会携带大量无关上下文。
2. 不要无限增加 Skill
Skill 越多不一定越好。
你提供的第 1 组材料明确指出：大量 Skill 的描述会进入模型上下文；描述过长、Skill 过多、触发条件重叠甚至“抢任务”，都会让模型更难判断应该使用哪个 Skill。
因此：
Skill 的目标不是覆盖一切，而是让特定任务更容易被正确路由。
3. 不要把 Skill 写成“巨型操作手册”
旧模型可能需要：
第一步打开 A → 第二步点击 B → 第三步读取 C……
现在应该尽量：
告诉模型目标、边界、关键约束和资源在哪里。
让模型自己处理那些不需要被硬编码的判断。
4. 不要把“少规则”理解成“没有规则”
应该追求：
最小必要约束
而不是：
最少规则
尤其不要为了“释放模型能力”而删除：
- 生产环境保护
- 数据安全
- 明确授权边界
- 必须人工批准的高风险操作
- 项目硬性约束
5. 不要让 Agent 无限探索
“自主”不等于“没有边界”。
好的任务应该明确：
目标是什么
↓
什么算完成
↓
允许自主做什么
↓
什么必须询问
↓
什么时候停止
如果希望 Agent：
第一版完成 → 检查 → 发现问题 → 修复 → 再验证 → 继续优化
就必须明确写进任务要求。
参考链接
[1]. pvncher 原帖：https://x.com/pvncher/status/2095991462416490862?s=20
[2]. ChatGPT 配置文件参考文档：https://learn.chatgpt.com/docs/config-file/config-reference
── 以下 [3] ~ [11] 为文中鸣谢的 X 友 ID，搜索名字可直达其主页 ──
[3]. @gengdaJ
[4]. @Pluvio9yte
[5]. @Vincent_AINotes
[6]. @JexLau
[7]. @Formulasearch
[8]. @ai_suxiaole
[9]. @huoshan007
[10]. @bitfish
[11]. @gregisenberg
码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践
更多推荐
3
0- 0
已为社区贡献1条内容
所有评论(0)