标签 SOP 下的文章

在 AI Agent 的工程实践中，一个反直觉但被反复验证的结论正在形成：第一版越“笨”，项目越容易成功。

从 0 到 1 阶段的目标，并不是构建一个“会思考”的系统，而是构建一个可被工程化控制的系统。在这一阶段，刻意限制智能体的能力边界，反而是长期演进的必要前提。

一、第一版的核心目标不是智能，而是可控

智能体本质上是概率系统，而工程系统追求的是确定性。

如果在初始阶段就引入复杂推理、自主规划、多轮反馈，系统将迅速演变为一个无法解释、无法定位问题、无法稳定复现结果的黑盒。

“做得很笨”的本质，是优先完成三件事：

  • 决策路径可见
  • 状态变化可追踪
  • 失败结果可复现

这是所有后续“变聪明”的前提。

二、逻辑透明化：用显式结构替代隐式推理

在第一版中，应当刻意避免让大模型承担“全链路思考”。

更可靠的做法是：

  • 使用固定 Workflow，而非开放式任务描述
  • 使用条件分支，而非自由联想
  • 使用判断题和枚举值，而非长文本推理

当逻辑被显式结构化后，模型只是执行者，而不是裁判者。

一旦输出异常，开发者可以明确判断问题来源： 是输入错误、规则缺失，还是模型执行失败。

这比“看不懂模型为什么这么想”要重要得多。

三、确定性交付：稳定比灵感更有价值

在工程场景中，80% 的可预测输出，远胜 20% 的惊艳发挥。

“笨”的智能体通常具备这些特征：

  • 输出格式强约束（如固定 Schema）
  • 数据流向单一，几乎无回环
  • 失败即中断，而不是“尝试自救”

这种设计虽然不“聪明”，但非常稳定。

当输入相同时，输出波动被严格限制在业务可接受范围内，这才是系统可上线、可扩展的前提。

四、观测成本越低，迭代速度越快

复杂系统最昂贵的成本不是算力，而是理解成本。

第一版如果过度复杂：

  • 日志量指数级增长
  • 中间状态难以复盘
  • 优化方向无法聚焦

而一个“笨”的系统，执行路径往往是线性的、分段的、可回放的。

开发者可以清楚看到：

  • 每一步输入了什么
  • 产生了什么中间结果
  • 是在哪一环节失败

这为后续的精准优化预留了认知空间。

五、从“笨系统”到“聪明系统”的正确路径

成熟的演进路径通常是：

  1. 原子能力 100% 成功率
  2. 严格 SOP 覆盖主要场景
  3. 在确定性失效点，引入有限智能
  4. 用真实运行数据反向优化 Prompt 或策略

而不是反过来。

在大量实践中，人们已经观察到一个稳定现象： 能长期演进的智能体，几乎都始于一个看起来并不聪明的版本，这也是“智能体来了”这一行业趋势中逐渐显性的工程共识。

结语

从 0 到 1 阶段，“笨”不是妥协，而是策略。

它意味着克制、可控与可复用。 也意味着系统有机会走得足够远，而不是止步于演示。

浅谈 Opencode + Oh My Opencode 工作时的 SOP 与 Workflow

总述

在使用 Opencode 的过程中，开发效果的好坏，确实在很大程度上取决于模型本身的智能水平。模型越聪明，理解需求、补全上下文、处理复杂逻辑的能力就越强，这点毋庸置疑。

但现实情况往往没那么理想。不是每个人都能稳定使用 Claude 或 GPT 的最新模型；即便能用，在高强度调用、上下文越来越长的情况下，模型也很容易开始 “走神”—— 出现幻觉、理解跑偏，甚至一本正经地胡说八道。

当你发现模型开始反复犯低级错误，或者对同一个需求给出前后矛盾的实现方案时，问题往往不在你，而在于：
你默认模型 “应该懂”，但它其实已经跟不上了。

这时候，单纯追求更强的模型，并不能从根本上解决问题。真正能兜底的，是一套清晰、稳定、可复用的 SOP（Standard Operating Procedure），以及基于 SOP 形成的 Workflow。

简单说一句就是：

模型负责输出，人负责把路铺好。

为什么越熟练，反而越需要 SOP

很多人在刚接触 Opencode 时，会觉得 SOP 是个 “新手才需要的东西”。
等自己用顺了，就开始随意对话、即兴发挥，哪里卡了就往模型里一股脑儿丢。

这种方式在小脚本、一次性需求里问题不大，
但只要项目稍微复杂一点，SOP 缺失的后果就会逐渐显现：

  • 模型对当前任务的理解不稳定
  • 不同轮对话输出风格和实现思路不一致
  • 修复一个问题，引入两个新问题
  • 过几轮之后，连模型自己都 “忘了现在在干嘛”

SOP 的存在，并不是为了限制模型的能力，而是为了减少不必要的理解分支。
你提前告诉它当前阶段该做什么、不该做什么，反而能让模型把有限的注意力用在真正重要的地方。

从这个角度看，SOP 不是 “给模型用的”，
而是给人省心用的。

SOP 和 Workflow，本质上解决的是两个问题

这里需要稍微区分一下这两个概念。

  • SOP 更像是一组 “约定俗成的操作规则”
    比如：每次开始前先让模型复述目标、禁止未经确认的大范围重构、输出必须标注修改点等。
  • Workflow 则是你在实际工作中形成的一种节奏
    什么时候该拆需求，什么时候该写代码，什么时候该停下来做确认。

SOP 偏静态，Workflow 偏动态；
一个负责 “别乱来”，一个负责 “往前走”。

在 Opencode + Oh My Opencode 的组合里，这两者往往是一起生效的。

我的 SOP

说明

  • 以下 SOP 均由 GPT5.2 模型给出并由本人在使用过程中润色改造
  • 所有内容均为可直接复制使用的工程指令
  • 不包含分析、解释或背景说明
    • 在开始使用 SOP 前应当完成项目初始化，推荐使用 Opencode 官方指令 /init
  • SOP 为原子级，Workflow 为高频组合
  • 指令中 ulw 命令为 oh my opencode 插件特有指令，详情可以移步 oh-my-opencode/README.zh-cn.md at dev · code-yeongyu/oh-my-opencode

SOP-01：工程启动 / 陌生任务分析

ulw #start
首先完整阅读 AGENTS.md，不要跳过。

然后按以下顺序执行分析：
1) 扫描整个仓库结构，识别项目入口、核心模块、分层与边界
2) 定位与当前任务直接相关的模块、文件和入口点
3) 用 3–5 条要点总结当前实现：
   - 每条描述一个职责或核心逻辑
   - 关注数据流、控制流和隐含假设
4) 标出不清晰、强耦合或潜在高风险区域
5) 提出至少 2 种可行推进方案：
   - 每种方案包含：优点、缺点、主要风险
6) 选择风险最低的方案，并给出明确的执行计划

约束：
- 在完成以上步骤前，不要修改任何代码
- 不要提前实现或重构

SOP-02：仓库探索 / 代码定位

ulw #scan
@explore:

1) 自顶向下扫描仓库结构
2) 识别与目标主题相关的模块、包和目录
3) 梳理主要调用链和依赖方向
4) 标出变更影响最大的 3 个区域并说明原因

约束：
- 仅做分析
- 不给实现或修改建议

SOP-03：技术调研 / 最佳实践

ulw #research
@librarian:

1) 查找该主题的官方文档或权威推荐做法
2) 对比 2–3 种成熟方案
3) 总结每种方案的适用场景与风险
4) 输出可直接用于当前项目的结论

约束：
- 避免长引用
- 只输出可执行结论

SOP-04：架构 / 方案决策

ulw #design
@oracle:

1) 在当前项目约束下提出 2–3 种设计或架构方案
2) 对每种方案说明：
   - 适用前提
   - 主要风险
   - 对现有代码的侵入程度
3) 推荐最安全的方案并说明原因
4) 明确不推荐其他方案的理由

SOP-05-FE：前端功能开发（使用 ui-ux-pro-max）

ulw #dev-fe
本任务是前端功能开发，加载skill：ui-ux-pro-max并根据这个技能的指引来进行 UI/UX 设计。

第 0 步：需求与界面范围确认
1) 用 3–6 条要点明确功能边界与用户路径
2) 列出必须态与异常态（loading / empty / error / 权限 / 网络失败）
3) 明确接口依赖与字段使用方式

第 1 步：UI/UX 设计（ui-ux-pro-max）
1) 产出页面结构与组件拆分
2) 明确交互细节与反馈机制
3) 定义各状态下的 UI 行为
4) 考虑可用性与可访问性

第 2 步：实现计划
1) 明确组件、路由、状态管理与请求层改动点
2) 拆分为可运行的增量步骤

第 3 步：增量实现
- 每一步完成后项目必须可运行
- 每一步完成后汇报：
  - 修改的文件
  - 实现的可观察行为
  - 修改原因
  - 下一步计划

约束：
- 优先复用现有组件与样式
- 不做顺手重构
- 避免过度抽象

完成标准：
1) 最小自测清单（主流程 + 异常态 + 边界态）
2) 核心交互演示路径
3) 接口字段与错误处理记录

SOP-06-BE：后端功能开发

ulw #dev-be
本任务是后端功能开发。

第 0 步：业务与契约确认
1) 明确输入、输出、业务规则、权限与幂等性
2) 列出数据模型变更与迁移策略
3) 明确错误码与异常语义

第 1 步：API 契约设计
1) 定义 endpoint、method、参数与响应结构
2) 明确分页、排序、过滤规则
3) 明确鉴权与资源所有权校验

第 2 步：测试准备
1) 补充最小测试或复现用例
2) 覆盖正常、异常、权限与边界情况

第 3 步：增量实现
- 每一步完成后服务必须可运行
- 每一步完成后汇报：
  - 修改的文件
  - 可验证结果
  - 修改原因
  - 下一步计划

约束：
- 优先复用现有架构与库
- 不做顺手重构
- 数据变更必须可回滚

完成标准：
1) 最小验证步骤
2) API 契约摘要
3) 影响范围说明

SOP-07：前后端对接 / 联调

ulw #dev-integration
本任务是前后端对接与联调。

第 0 步：冻结接口契约
1) 输出统一接口契约
2) 明确字段类型、必填性、默认值、空值语义
3) 明确错误码与错误结构
4) 明确鉴权方式与过期策略

第 1 步：联调准备
1) 后端提供可联调环境或 Mock
2) 前端完成请求封装与校验
3) 明确接口版本与兼容策略

第 2 步：联调闭环
1) 走通主流程
2) 覆盖异常场景（权限、参数、5xx、超时、空数据）
3) 明确 loading、重试、降级与幂等策略

第 3 步：对账与验收
1) 对账字段、单位、精度、时区
2) 对账分页、排序与筛选边界
3) 对账权限与越权访问

每一步完成后汇报：
- 修改的前后端文件
- 已打通的路径
- 当前阻塞点
- 下一步计划

完成标准：
1) 联调验收清单
2) 最终接口契约摘要
3) 最小复现链路

SOP-08：高风险重构（分析）

ulw #refactor
在修改任何代码前：
1) 找出所有相关定义与引用
2) 区分公开 API 与内部实现
3) 评估影响范围、风险点与迁移顺序

约束：
- 未确认前不要修改代码

SOP-09：高风险重构（执行）

ulw #refactor-exec
1) 如缺少测试，先补充
2) 按迁移顺序逐步修改
3) 每一步完成后说明：
   - 本步修改内容
   - 安全性理由
   - 可运行证据
   - 下一步计划

SOP-10：Bug / 异常排查

ulw #debug
1) 列出最可能的 3 个根因并排序
2) 为每个根因提供最小验证方法
3) 只修复被验证的根因
4) 说明其他假设被排除的原因

完成后：
- 给出回归验证步骤

SOP-11：提交前自检

ulw #review
1) 列出修改的文件与关键差异
2) 指出潜在风险与边界情况
3) 检查是否符合 AGENTS.md
4) 给出回滚方案
5) 给出最小本地验证命令

SOP-12：任务闭环

ulw #wrap
1) 确认目标是否完成
2) 按文件或模块总结关键变更
3) 列出风险与覆盖情况
4) 给出验证步骤
5) 给出回滚方案
6) 建议 AGENTS.md 的补充（仅新增）

关于 #xxx 这类指令

#xxx 是什么？
像 #start、#plan、#review 这一类 #xxx，本质上只是给模型看的阶段标签。
它们不参与具体内容，只用来告诉模型：现在处在什么阶段，该怎么配合你工作。

为什么要这样做？
因为模型默认会把所有对话当成一整段连续上下文来处理。
一旦讨论过多、来回修改几次，它就很容易把已经不重要、甚至已经作废的内容继续当成前提。

用 #xxx，等于是提前告诉模型：

“接下来换个阶段思考，别按刚才那套逻辑继续往下跑。”

这么做的必要性是什么？
这类指令的意义不在于 “让模型更聪明”，而在于减少跑偏和误解。

在任务切换频繁、上下文偏长的情况下，一个清晰的阶段标记，往往比多写几段解释更有效。
成本很低，但能明显提升稳定性，尤其适合长期、反复使用。

SOP 之外，更重要的是 Workflow 的 “手感”

有了 SOP，并不代表事情就会自动变顺。
真正拉开差距的，往往是你如何把这些规则串成一套顺手的流程。

很多人 Workflow 混乱，并不是能力问题，而是节奏问题：

  • 需求还没想清楚，就开始让模型写代码
  • 代码刚能跑，又急着往上堆功能
  • 出问题时，直接整段推翻重来

相比之下，一个成熟的 Workflow 往往更 “慢”，但更稳：

  • 先对齐理解，再动手
  • 先最小可用，再逐步完善
  • 每一步都能随时停下来回滚或修正

Oh My Opencode 在这里扮演的角色，其实很清晰：
它不是帮你 “多写点代码”，而是帮你守住流程的下限。

我的 Workflow

# 接手陌生项目
ulw #start #scan

# 标准新功能（前后端）
ulw #start
→ ulw #dev-be
→ ulw #dev-fe
→ ulw #dev-integration
→ ulw #review
→ ulw #wrap

# 仅前端功能
ulw #start
→ ulw #dev-fe
→ ulw #review
→ ulw #wrap

# 仅后端功能
ulw #start
→ ulw #dev-be
→ ulw #review
→ ulw #wrap

# Bug 修复
ulw #debug
→ ulw #review
→ ulw #wrap

# 高风险重构
ulw #start
→ ulw #refactor
→ ulw #refactor-exec
→ ulw #review
→ ulw #wrap

# 技术选型
ulw #research
→ ulw #design

把模型当成同事，而不是许愿池

最后一个很重要的心态转变是：
不要把模型当成全知全能的存在，而要把它当成一个执行力强、但容易跑偏的同事。

你需要做的不是 “多问”，而是：

  • 把问题拆清楚
  • 把边界讲明白
  • 在关键节点做确认
  • 发现偏离及时拉回来

SOP 和 Workflow，本质上就是你和模型之间的协作协议。

结语

模型会更新，能力会上涨，也可能随时被限流；
但一套成熟的 SOP 和顺手的 Workflow，会长期存在。

Opencode + Oh My Opencode 真正提供的，不是 “写代码的捷径”，
而是一种在不完美模型条件下，依然能稳定推进工作的方式。

当模型不再可靠时，
流程，才是你最后的安全绳。

出处与使用说明

本文内容及其中的 SOP / Workflow 由 @HappyCoding 原创整理并在 LinuxDo 首发。
允许在保留原始出处的前提下复制、修改与二次分发，
不建议在未注明来源的情况下直接商用。

📌 转载信息
原作者：
HappyCoding
转载时间：
2026/1/23 10:25:18

“通用性不再是主要瓶颈，部署中的任务集熟练度和可靠性才是决定机器人能否真正落地的关键。”在近期的一场采访中，智元机器人合伙人、首席科学家罗剑岚称，2026 年是机器人从会做很多事但每个事做得不太好走向把事情做好并落地的关键节点，要求学习范式从静态离线训练升级为部署学习再部署的整套数据闭环系统。

 

他表示，正是基于这个判断，智元机器人具身研究中心提出了 SOP（Scalable Online Post-training），一套面向真实世界部署的在线后训练系统。SOP 的核心目标是，让机器人在真实世界中实现分布式、持续的在线学习。

 

据罗剑岚透露，智元今后会在所有机器人上应用 SOP。今年，智元计划部署比现在大几个数量级的机器人，真正找到机器人真实场景部署和真实场景落地的 Scaling law。

 

要在真实世界中大规模运行，通用机器人必须同时满足两个看似矛盾的要求：在复杂多变的环境中保持稳定性与可靠性；在处理差异巨大的任务时，仍具备良好的泛化能力。现有 VLA 预训练模型已经提供了强大的通用性，但真实世界的部署受困于更高的任务专精度要求以及离线数据采集方式的边际效益递减，往往需要通过后训练获得更高的任务成功率。

 

然而，当前主流的 VLA 后训练方法仍受离线、单机、串行采集等因素制约，难以支撑高效、持续的真实世界学习。这些限制并非源自具体算法，而是来自学习范式本身。智元方面介绍，SOP 改变的不仅是训练范式，更是机器人系统的生命周期。如果说 VLA 让机器人第一次具备了通用理解与行动能力，那么 SOP 所做的是让众多机器人的经验共同驱动智能的快速成长。

 

“SOP 目前不是完全开源的，但不排除未来开放的合作形式。”罗剑岚表示，智元从成立之初就坚持走生态开放的路线，希望跟更多厂商一起共建 SOP，把 SOP 的闭环真正接入到业务流程里。SOP 不是封闭系统，而是一种新的持续学习、在线学习、协同进化的方式，任意的后训练算法和模型都可以接进来，智元会开放一些 SOP 的关键模块和接口。

 

从长远来讲，智元的目标是构建一个开放的机器人在线学习生态，不同的机器人本体都可以接入，让数据共享上传到云端一个大脑，数据回传回来并不断进化，给大家使用。

SOP：分布式在线后训练框架

SOP 采用 Actor–Learner 异步架构，本身是一套通用的框架，可以即插即用的使用任意后训练算法，让 VLA 从在线经验数据中获益。智元选取 HG-DAgger（交互式模仿学习）与 RECAP（离线强化学习）作为代表性算法，将其接入 SOP 框架以进化为分布式在线训练。

 

据介绍，他们将 VLA 后训练从“离线、单机、顺序”重构为“在线、集群、并行”，形成一个低延迟的闭环系统：多机器人并行执行 → 云端集中在线更新 → 模型参数即时回流。

 

 SOP 架构设计图

SOP 的关键优势包括：

• 高效状态空间探索。分布式多机器人并行探索，显著提升状态–动作覆盖率，避免单机在线学习的局限。

• 缓解分布偏移。所有机器人始终基于低延迟的最新策略进行推理采集，提升在线训练的稳定性与一致性。

• 在提升性能的同时保留泛化能力。传统的单机在线训练往往会使模型退化为只擅长单一任务的“专家”， SOP 通过空间上的并行而非时间上的串行，在提升任务性能的同时保留 VLA 的通用能力，避免退化为单任务专家。

实验评估：性能、效率与 Scaling Law

实际效果方面，智元围绕三个方面对 SOP 进行了系统性评估。

 

首先是 SOP 能为预训练 VLA 带来的影响。实验结果说明，在各类测试场景下，结合 SOP 的后训练方法均得到了显著的性能提升。

 

相比预训练模型，结合 SOP 的 HG-Dagger 方法在物品繁杂的商超场景中实现了 33% 的综合性能提升。对于灵巧操作任务（叠衣服和纸盒装配），SOP 的引入不仅提升了任务的成功率，结合在线经验学习到的错误恢复能力还能明显提升策略操作的吞吐量。结合 SOP 的 HG-Dagger 方法让叠衣服的相比 HG-Dagger 吞吐量跃升 114%。SOP 让多任务通才的性能普遍提升至近乎完美，不同任务的成功率均提升至 94%以上，纸盒装配更是达到 98%的成功率。

 

 

为了进一步测试真机 SOP 训练后 VLA 模型是否达到专家级性能，他们让 SOP 训练的 VLA 模型进行了长达 36 小时的连续操作，模型展现出了惊人的稳定性和鲁棒性，能够有效应对真实世界中出现的各种疑难杂症。

 

其次，智元使用了三种机器人队伍数量（单机、双机、四机配置），在同样的数据传送总量的基础上，进行了比较。实 验结果表明，在相同的总训练时间下，更多数量的机器人带来了更高的性能表现。在总训练时间为 3 小时的限制下，四机进行学习的最终成功率达到了 92.5%，比单机高出 12%。

 

他们认为，多机采集可以有效阻止模型过拟合到单机的特定特征上。同时，SOP 还将硬件的扩展转化为了学习时长的大幅缩短，四机器人集群相比单机能够将模型达到目标性能的训练速度增至 2.4 倍。

 

 SOP 学习效率提升

 

此外，他们探究了 SOP 和预训练数据之间的关系，把总量为 160 小时的多任务预训练数据分为了三组：20 小时，80 小时和 160 小时，分别训练一组初始模型后再进行 SOP。接着发现，预训练的规模决定了基座模型和后训练提升的轨迹。SOP 能为所有初始模型带来稳定的提升，且最终性能与 VLA 预训练质量正相关。

 

同时，对比 80 小时和 160 小时实验效果，在解决特定失败情况时，在轨策略经验带来了非常显著的边际效果。SOP 在三小时的在轨经验下就获得了约 30%的性能提升，而 80 小时额外人类专家数据只带来了 4%的提升。这说明在预训练出现边际效应递减的情况下，SOP 能够高效突破 VLA 性能瓶颈。

 

 SOP 在不同预训练数据规模下的对比

 

最后，智元将机器人队伍放到了预训练模型没有见到的真实新环境下执行任务，并使用 SOP 进行在线训练。当机器人被置于不同的环境时，即便是同样的任务，起初成功率和吞吐量如预期般下降，但在 SOP 介入仅仅几个小时后，机器人的性能便显著回升，能够鲁棒地执行相对复杂的实际任务。