企业官网建设流程全解析

pm-ai-shipping 实战：用/ship-check六步把 AI 生成的代码变成可评审的 Shipping Packet

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

AI Agent 写的代码速度很快，但往往不留任何"意图"记录——系统本该做什么、谁有权做什么、密钥藏在哪、哪条规则真正被测试覆盖过。没有这份记录，任何人类评审者和审计 Agent 都无法判断代码到底能不能发布。pm-skills 仓库中的pm-ai-shipping插件（AI Shipping Kit）正是为这种"vibe-coded 仓库"设计的：先用/document-app把系统文档化，再以intended-vs-implemented方法审计"文档意图"与"代码实现"之间的落差，最后编译成一份人类可以直接签字放行的shipping packet。读完本文，你将掌握/ship-check的完整调用方式、六步执行序列的内部逻辑，以及 shipping packet 每个区块的编写口径，能够把一个"AI 写的、没人敢上线"的仓库变成"证据齐备、可评审、可签收"的状态。

/ship-check是什么：协调者，而非替代者

/ship-check的定义很克制：它不替代任何专项命令，而是协调它们，并产出任何一个专项命令单独都无法产出的最终交付物——shipping packet。它的答案对应的是一个实际问题：你的 AI 写了代码，但你真正想问的是——它到底能不能安全发布？

这个命令运行完整的发布检查序列，并把结果编译成一个人类可以签署的评审包。它本身不重新推导每一项审计结论，而是把"排序 + 综合"作为核心价值——这一点在原文档的 Notes 中被明确称为handoff compiler（交接编译器）。

在 pm-skills 仓库中，该命令的声明位于 pm-ai-shipping/commands/ship-check.md 的 YAML frontmatter 中：description描述其职责（文档化应用、接入 Agent 上下文、运行安全与性能审计、映射测试覆盖、编译结果），argument-hint声明其参数形态为<repo path or area; defaults to the whole repository>。这与 validate_plugins.py 中对命令文件的校验规则一致——每个命令必须提供description，推荐提供argument-hint，确保命令在输入/时具备可发现性。

调用方式

/ship-check接受一个可选参数$ARGUMENTS，用于限定检查范围；参数为空时默认检查整个仓库：

/ship-check /ship-check the payments service /ship-check supabase/functions

从插件目录结构看，该命令属于pm-ai-shipping插件，因此也可以显式使用带前缀形式/pm-ai-shipping:ship-check触发（安装说明见 pm-ai-shipping/README.md）。参数会贯穿六步序列：每一步都作用在$ARGUMENTS（或空参数时的整个仓库）上，因此限定范围会同步收窄文档化、审计与测试映射的覆盖面。

The shipping sequence：六步序列，顺序即要点

整个序列运行在$ARGUMENTS（为空则整个仓库）上，每一步都建立在前一步之上——顺序本身就是关键，因为"每一项审计的有效性，都取决于它能对照的、已被文档化的意图"。

Step 1: Document the system —— 先有"应当如何"的基线

第一步确保系统文档存在且最新（缺失或过期时运行/document-app反向工程生成）。这一步应用shipping-artifacts技能：核心文档集（architecture、flows、permissions、variables）加上按需生成的条件文档（emails、cron、seo、automation）。

这些文档就是后续一切审计的 intended-state 基线。正如 shipping-artifacts/SKILL.md 所定义的：

• architecture.md— 系统概览、技术栈、认证流程、信任边界、Known risks/assumptions，以及指向其余所有文档的 "Related Documents" 索引；
• flows.md— 权限相关旅程：每个受保护步骤的 authz 检查、信任边界跨越、各步骤引发的副作用；
• permissions.md— 角色、scope 推导、resource × operation × role 矩阵、RLS 与代码级检查的划分；
• variables.md— 配置与密钥的风险映射与轮换计划；
• 条件文档（emails/cron/seo/automation）——仅在能力真实存在时生成，否则在architecture.md中用一行注明缺失。

配套的/document-app命令明确要求"以代码为真相来源"逆向推导，对不适用条件文档要"跳过并说明"，并对代码过于含糊、无法自信文档化的缺口如实报告——那些缺口正是要最先修复的东西。值得强调的是：这些文档描述的是本系统，要剔除通用理论和成品模板；且不写"更新日期"行，文件历史才是真相来源。

Step 2: Wire the agent operating context —— 给下一个 Agent 的操作说明书

第二步创建或刷新CLAUDE.md（以及一个指向它的薄AGENTS.md），从系统文档派生——这是下一个 AI 编码 Agent 继承的操作指令：系统是什么、信任边界在哪、什么可以碰什么不能碰、护栏在哪里。

原文档特别强调：这是与系统文档不同的另一种产物——指令，而非描述。system docs 记录系统事实，CLAUDE.md/AGENTS.md 规定 Agent 行为边界。这个仓库本身就是最好的实证：仓库根目录的 AGENTS.md 全文仅 3 行，声明"所有 Agent 指导都位于 CLAUDE.md，该文件是唯一真相来源，本文件只为引导非 Claude Agent 找到同一份指令，不在本文件重复指导"——这正是 Step 2 要求的"薄指针文件"形态；而 CLAUDE.md 则完整承载了项目结构、设计规则、版本策略、校验流程等操作约束。

Step 3: Security audit —— 对照文档意图的安全审计

第三步运行安全审计（/security-audit-static），应用intended-vs-implemented技能，标记代码与permissions.md、flows.md、architecture.md背离之处，并汇总存活的发现（surviving findings）。

/security-audit-static的引擎很小但约束很强：先映射入口点到信任边界与 sink（含 LLM prompt 与工具调用这类 AI 应用特有 sink），再检查授权、数据访问、会话/身份、输入→输出编码四条高价值路径，随后对照/documentation/*.md交叉核对 intended vs. implemented，最后对每一条候选发现做self-refute——除非有"文件 + 行号"的证据证明该路径被消毒器/校验器/授权检查拦截、sink 本身无危险、后端独立重申了前端门禁等情形，否则默认保留。其配套技能 intended-vs-implemented/SKILL.md 定义了这类审计的核心纪律：文档意图是"待验证的主张"，不是证据；实现证据必须是引用了文件与行号的实际代码路径；凡是无法同时引用"文档说了什么"和"代码实际做了什么"的，属于待调查问题而非可上报发现。这正是普通扫描器（对意图没有建模）无法捕获的那类 bug——比如"文档声明仅 cron 可调用的端点任何人都能调用"。

Step 4: Performance audit —— 针对数据增长的三类失效模式

第四步运行性能审计（/performance-audit-static），聚焦三类问题：过度拉取（over-fetching）、缺失索引（missing indexes）、缓存缺失（caching），并汇总发现。

/performance-audit-static的立论切中 AI 生成代码的典型缺陷："Agent 优化的目标是'在我的种子数据上能跑'，而不是'在 100 倍行数下扛得住'"。它要求给出具体的索引定义而非"加个索引"，并为每个缓存建议明确失效规则——"没有失效计划的缓存就是一个等待发生的正确性 bug"。它同时提醒按 impact-per-effort 排序：热门表上缺一个索引通常胜过十个微优化。

Step 5: Derive the test-coverage map —— 把规则变成防止回退的测试地图

第五步运行/derive-tests，把已文档化的规则——以及前两步审计刚刚暴露的缺口——转化为覆盖地图tests.md：哪些规则被今天已存在的测试钉住，哪些只是提议，哪些是guarded-live 或 manual，哪些完全没有验证。

这一步刻意放在审计之后：每个被确认的发现都会变成一个具体的回归测试来钉住它，这样同一个缺口就不会在下一次 AI 编辑时悄然重新打开。这就是"documented == implemented"的操作化形态，而未经验证的边界规则会直接喂入下面的发布阻塞评估。

/derive-tests的工作流进一步明确了细节：先从系统文档（最重依赖flows.md、permissions.md、automation.md）提取值得测试的承重规则——授权允许与拒绝两种情况、各 sink 的输入校验与输出编码、作业幂等性、fail-closed 默认值、副作用触发条件、公共数据约束、Agent 输出契约与工具面限制；然后按rule → expected behavior（含负面用例）→ evidence source → test type → status构建覆盖地图。测试类型分四档：unit（纯确定、无外部服务）、integration (deterministic)（针对本地/内存依赖、每次运行结果一致）、guarded live（需要真实外部 DB/邮件服务/LLM，只在显式 flag 后运行，绝不进入默认 CI）、manual（评审清单项）。CI 门槛的推荐是：每个 PR 跑确定性本地集（unit + 确定性 integration），guarded-live 保持 opt-in，main 合入以绿色状态 + 分支保护为门禁——但以"建议供用户批准"的形式输出，而非擅自修改。

Step 6: Compile the shipping packet —— 编译最终评审包

第六步把所有结果编译成 shipping packet。原文档给出的模板如下，需完整继承：

## Shipping Packet: [repo / area] ### Documentation Inventory | Doc | Status (present / stale / missing / n/a) | Notes | ### Agent Context CLAUDE.md / AGENTS.md: [created / updated / already current] ### Test Coverage [Rules pinned by tests that exist today · proposed but not yet written · guarded-live/manual · and the documented rules nothing verifies yet] ### Security Summary [Counts by severity + the surviving findings, each: Risk · Attack · Impact · Fix] ### Performance Summary [Findings by view/route/table, each: Recommendation · Effort · Priority] ### Launch Blockers [Unresolved Critical/High items — including any boundary rule that is both unverified and unaudited — that should stop a ship] ### Recommended Next Actions [Concrete owner actions or commands to run next]

六个区块各自对应一个明确的签收问题：文档清单回答"该有的文档齐不齐"（含 present / stale / missing / n/a 四种状态）；Agent Context 回答"下一个 Agent 有没有操作上下文"；Test Coverage 回答"声称的规则到底有没有被验证"；Security Summary 回答"剩余风险有哪些，每条的风险等级、攻击路径、影响与修复建议是什么"；Performance Summary 按视图/路由/表给出建议、投入与优先级；Launch Blockers 则把未解决的 Critical/High 项——包括任何既未验证又未审计的边界规则——明确列为应阻止发布的事项。

Notes：边界与定位

原文档以四条 Notes 收束，这些边界对正确使用命令至关重要：

• 这是交接编译器：价值在于排序与综合，而非重新推导每项审计。
• 文档缺失时要大声说出来：没有文档化意图的审计是不完整的，inventory 让这种不完整可见，而不是藏起来。
• 发现是代码评审结果，不是已确认的漏洞利用：packet 是人类签字的基础，不是替代品。
• 只需单阶段时直接运行专项命令：/document-app、/derive-tests、/security-audit-static、/performance-audit-static均可单独调用。

如何安装与运行

pm-ai-shipping是 pm-skills marketplace 的 9 个插件之一（插件清单见 pm-ai-shipping/.claude-plugin/plugin.json，当前版本 2.0.0，关键词覆盖 ai-shipping、vibe-coding、security-audit、performance-audit、owasp、shipping 等）。安装方式与其余插件一致（详见根目录 README.md）：

• Claude Code（CLI）：claude plugin marketplace add phuryn/pm-skills后执行claude plugin install pm-ai-shipping@pm-skills；
• Claude Cowork：在插件浏览器的 Personal 中通过 GitHub 添加phuryn/pm-skills，9 个插件自动安装；
• Codex CLI（OpenAI）：codex plugin marketplace add phuryn/pm-skills+codex plugin add pm-ai-shipping@pm-skills（注意 Codex 插件不暴露/slash命令，需要用自然语言描述步骤触发，或让 Codex 把命令文件转换为等效 skill）；
• 其他助手（仅 skills）：将pm-ai-shipping/skills/下的SKILL.md复制到.gemini/skills/、.opencode/skills/、.cursor/skills/或.kiro/skills/即可获得两个技能（shipping-artifacts 与 intended-vs-implemented）。

安装后，/ship-check可随时对目标仓库执行完整序列；仓库是只读的，命令产出的documentation/*.md、reports/*.md等文件应写入你自己的工作副本，而不是本仓库。

从源码看实现约束

仓库内的实现细节进一步印证了/ship-check的编排设计。从目录结构看，pm-ai-shipping/commands/ 下 5 个命令文件是平行单元，ship-check.md是唯一负责串起其余四者的编排器；pm-ai-shipping/skills/ 下两个 SKILL.md 则提供了命令依赖的方法论层。此外，validate_plugins.py 中的跨引用校验（validate_cross_references）会检查命令是否引用了同插件内真实存在的技能——这保证了ship-check对shipping-artifacts和intended-vs-implemented的引用在插件独立安装时不会悬空，与 CLAUDE.md 中"无跨插件硬引用"的设计规则一致。可以推断：插件的模块化（命令引用同插件技能、插件独立安装）正是/ship-check作为协调命令得以成立的基础——它只依赖同插件内的能力，任何单阶段可独立运行，全序列可一键编译。

结语

/ship-check回答的不是"代码有没有 bug"，而是"我凭什么敢发布它"。六步序列把"文档化意图 → 代理上下文 → 安全审计 → 性能审计 → 测试覆盖 → 评审包"串成一条可追溯的流水线，让人类评审者拿到的不再是一堆零散的审计输出，而是一份包含文档清单、剩余风险、性能建议与发布阻塞项的单一交付物。对任何对 AI 编写代码负有发布责任的 PM 与创始人而言，这是把"vibe-coding 的快"与"可评审的稳"重新接回同一条轨道的最短路径。

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills