企业 SOP 可不能直接整段往 Claude Code 的提示词里塞。提示词越长，越容易变成一次性的临时说明；真想长期稳定调用，得把 SOP 拆成标准化的 Skill：固定输入格式、固定执行步骤、固定调用工具、固定失败处理逻辑。Refly 干的就是这个中间活——先把业务流程做成可执行的工作流，再导出成 Claude Code、API、Webhook 或者 MCP 相关环境能直接调用的能力。

先把 SOP 从文档变成动作

就拿「发布前安全检查」来举例子吧。文档里往往列着十几条要求：查依赖、扫密钥、跑测试、确认变更范围、写发布记录。Claude Code 临时读一遍文档也能照着做一次，但下次换个项目、换个人用、甚至换个模型，执行顺序乱不乱、会不会漏项，就全没准了。用 Refly 拆成 Skill 就稳多了：固定先读仓库状态，再执行检查命令，接着解析结果，生成阻断项，最后把能不能发布的结论返回给 Claude Code。

每个能力点后面都得补上明确的失败处理逻辑：要是测试命令不存在，Skill 就得直接返回「缺少验证入口」，不能稀里糊涂假装通过；要是扫到高危密钥，Skill 必须直接阻断发布，不能只在报告里轻描淡写提一句就完事。

Claude Code 调用的不是「建议」，而是工具化结果

Refly Skills 的官方思路，是把工作流发布成可直接调用的能力。官方 README 里给的 CLI 操作路径，主要分三步：装 Refly CLI、装 Skill、发布 Skill：

npm install -g @powerformer/refly-cli
refly skill install <skill-id>
npx skills add refly-ai/<skill-name>
refly skill publish <skill-id>

当然，这些命令本身并不是企业 SOP 的全部。真要对接 Claude Code，还得把 Skill 的输入输出设计得明明白白：输入可以是仓库路径、PR 编号、发布环境；输出必须包含检查状态、失败节点、修复建议，还有能不能继续执行的明确结论。这样 Claude Code 拿到的是结构化的明确结果，不是一段模棱两可的模糊建议。

Refly 在中间负责三件脏活

第一件是编排。SOP 里经常有「先做 A，再根据结果选 B 还是 C」的分支逻辑，Refly 的工作流节点比纯提示词靠谱多了，能稳稳hold住这种顺序和分支。第二件是连接。企业 SOP 往往要对接 GitHub、Slack、飞书、数据库、内部脚本还有各种模型服务，Refly 的工具库和 MCP 支持能把这些能力都收拢到同一个执行层里。第三件是治理。Skill 进到注册表之后，可以统一做版本管理、共享和审计，再也不会出现每个团队都抄一份、改得五花八门的情况。

一条可落地的调用链

给大家说一套比较稳的落地流程：先在 Refly 里创建「发布检查 Skill」，把 SOP 拆解成明确的输入、执行步骤、阻断条件和输出；再通过 API 或者 Skill 发布的方式，把这个能力开放给 Claude Code 调用；等 Claude Code 处理发布任务的时候，就直接调用这个 Skill；Refly 跑完之后返回结构化的检查结果；Claude Code 再根据结果去修代码、补测试，或者直接停止发布。

要是走 API 调用的话，Refly 文档里的开放能力覆盖了运行工作流、查执行状态、取输出结果还有上传文件。这种设计很适合企业把 SOP 做成后台能力，让 Claude Code 只专心管当前仓库里的代码修改和验证就行。失败场景也得提前写得明明白白：API Key 无效、workflow ID 错了、执行超时、输出文件没生成，这些情况都得返回明确的可处理错误，不能让 Agent 自己瞎猜。

边界要提前说死

千万别让 Claude Code 直接绕过 SOP，也别让 Skill 自动批准高风险操作。在企业场景里，Refly Skills 更适合当「标准动作层」：它只负责告诉 Agent 当前流程能不能往下走、缺什么材料、哪一步出了问题。但凡涉及生产发布、权限变更、资金或者客户数据的操作，还是得留着人工确认的节点。

把 SOP 做成 Refly Skill 的核心好处，不是让 Claude Code 更会聊天，而是让它少靠「记性」、多靠明确的可执行规则。能被调用、能被复核、能做版本管理的 SOP，才是企业里能长期稳定跑起来的 Agent 工作流。