浅谈 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-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
