Shipping Engineering Work Skill 是什么

shipping-engineering-work 是一套面向 AI Coding Agent 的通用工程交付 skill。

它不是让 Agent 多会一个 API，也不是再写一份“万能提示词”。它解决的是更基础的问题：

当 Agent 进入真实代码库时，如何像一个靠谱工程协作者一样工作？

很多 AI 编程助手在 demo 里表现很好，但在真实项目里常常会出这些问题：

• 需求还没弄清楚就开始写代码；
• 一处小 bug 被改成大范围重构；
• 看见报错就猜根因，没有复现和证据；
• 没跑测试就说“已经修好”；
• 多个 Agent 并行时互相覆盖文件；
• 给开源社区提 PR 时范围太大，维护者很难 review。

shipping-engineering-work 的核心价值，就是把这些风险压进一套更稳定的工程交付节奏。

它不是流程口号，而是小交付合同

这个 skill 会要求 Agent 在非平凡任务开始前，形成一个小交付合同。

这个合同包含 6 件事：

Goal：这次到底解决什么问题
Scope：改什么，不改什么
Evidence：用什么证据证明判断
Plan：下一步怎么做
Verification：怎么验证完成
Handoff：怎么交接给人类、reviewer 或下一个 Agent

听起来简单，但它能挡住很多真实问题。

比如用户说“这个 Windows CLI 报错，赶紧修一下”，普通 Agent 可能直接开始改 loader。
而启用这个 skill 后，Agent 应该先判断：

• 这是 Windows 路径问题，还是 ESM import 边界问题？
• 相关代码在哪里？
• 有没有测试或最小复现？
• 最小改动应该发生在哪个边界？
• 修改后用什么命令证明没有破坏其他路径？

这就是“工程交付”和“直接生成代码”的差别。

适合哪些任务

我更推荐在下面这些任务里使用它：

• 修 bug；
• 调试 failing test；
• 实现一个有风险的小功能；
• 做代码审查；
• 准备上游开源 PR；
• 回应维护者 review；
• 多 Agent 并行实现；
• Codex 和 Claude Code 之间交接上下文；
• OpenClaw / Hermes 这类本地 agent runtime 里的工程任务。

如果任务只是“帮我生成一段示例代码”，它可能有点重。
但只要任务涉及真实仓库、真实测试、真实 PR 或真实部署，它就很有价值。

三种典型模式

1. Debug 模式

当遇到报错或测试失败时，Agent 不应该直接猜。

它应该先做：

• 复述症状；
• 找到相关代码路径；
• 建立假设；
• 用测试、日志或最小复现验证假设；
• 做最小修复；
• 再跑验证。

项目里的 examples/bug-fix.md 就是一个 Windows ESM loader 路径问题的压力测试。

2. Upstream 模式

给开源社区提 PR 时，Agent 更不能大改。

它应该：

• 读维护者已有风格；
• 保持 patch 最小；
• 保留维护者关心的行为；
• 补测试或 changelog；
• 准备清晰 PR body；
• 不替 CI 结果提前宣布成功。

项目里的 examples/upstream-pr.md 用 Windows restart helper 弹窗问题做了演示。

3. Handoff 模式

跨 Agent 协作时，最怕丢上下文。

Claude Code、Codex、OpenClaw、Hermes 的工具形态不同，但交接信息应该稳定：

• 当前目标；
• 已完成；
• 未完成；
• 关键证据；
• 验证命令；
• 风险；
• 下一步。

项目里的 examples/cross-agent-handoff.md 就是为这个场景准备的。

它和普通提示词有什么区别

普通提示词通常告诉 Agent “你要认真、严谨、先分析”。
但真实工程任务里，这还不够。

shipping-engineering-work 更像一个工作流 skill，它会让 Agent 在不同任务里切换模式：

• Frame：需求不清时先框定问题；
• Inspect：不熟悉代码时先读证据；
• Design：新行为需要设计时先给小规格；
• Implement：清晰任务再改代码；
• Debug：失败时先复现和定位；
• Review：审查时先找风险；
• Upstream：开源贡献时尊重维护者成本。

它约束的是交付动作，不只是语气。

怎么安装

Skill 页面：

• Shipping Engineering Work Skill

GitHub 仓库：

• https://github.com/kunpeng-ai-lab/shipping-engineering-work

Codex 示例：

Copy-Item -Recurse .\shipping-engineering-work "$env:USERPROFILE\.codex\skills\shipping-engineering-work"

Claude Code、OpenClaw、Hermes 可以把同一个文件夹放到各自支持的 skill 目录或提示词配置里。

推荐怎么调用

你可以这样让 Agent 使用它：

Use shipping-engineering-work to debug this failing test and prepare a minimal verified fix.

或者：

Use shipping-engineering-work to prepare this bug fix as an upstream PR.

或者：

Use shipping-engineering-work to hand this task from Codex to Claude Code without losing context.

什么时候不要用

有些小事不需要它。

比如：

• 解释一段代码；
• 生成一个一次性脚本；
• 写一个草稿；
• 做没有真实工程风险的小改动。

但只要涉及真实仓库、测试、PR、部署、多人协作或上游社区，我会建议默认启用。

我们为什么把它开源

因为 AI Coding Agent 会越来越多，但“会写代码”和“能交付工程任务”之间还有距离。

一个通用 skill 不应该只服务某一个 runtime。
Claude Code、Codex、OpenClaw、Hermes 都会遇到类似问题：

• 如何少猜；
• 如何少大改；
• 如何保护用户已有变更；
• 如何证明完成；
• 如何给下一个人或下一个 Agent 留下可读交接。

这就是 shipping-engineering-work 想沉淀的东西。

下一步

如果你想试用，建议按这个顺序：

1. 打开 Shipping Engineering Work Skill。
2. 下载 skill 包或 clone GitHub 仓库。
3. 用 examples/bug-fix.md 压测一次自己的 Agent。
4. 再用 examples/upstream-pr.md 试一次开源 PR 场景。
5. 最后用 examples/cross-agent-handoff.md 看它能不能稳定交接上下文。

如果一个 Agent 能在这三个场景里都保持小步、证据和验证，它就更接近一个可靠的工程协作者。