AI 编程代理的安全发布框架：轻量级操作系统方案

难点不在于生成补丁

Coding Agent 非常擅长产出初稿。真正成本高昂的工作从那之后才开始：确保请求不超出范围、证明具体发生了哪些变化，以及让没有参与编写补丁的人也能清楚理解发布决策。

一套用于 Agent 辅助交付的轻量级操作体系，其实可以非常精简。它只需要一份仓库契约、一套可重复执行的请求处理闭环、明确的人为边界，以及最终的验证证据。

1. 把请求变成契约

在 Agent 修改任何内容之前，先明确写下：

• 想要达成的结果，而不只是实现方式
• 哪些文件或系统属于本次工作范围
• 验收检查项
• 最终决策由谁负责

一份简短的 AGENTS.md，就能让所有贡献者清楚看到这些约定：

# Delivery contract

## Before changing files
- Restate the outcome and non-goals.
- Inspect the repository and name the evidence you will use.
- Ask for approval before implementation if scope is unclear.

## Before release
- Summarize changed files and checks run.
- Record known gaps and rollback steps.
- Leave deployment and destructive actions to a human owner.

这个文件不是什么神奇的 prompt，而是所有人共同遵守的边界。

2. 使用清晰可见的闭环

• 分诊（Triage）——明确目标、范围、风险和验收标准。
• 检查（Inspect）——阅读相关代码以及现有检查项。
• 规划（Plan）——提出规模最小且逻辑完整的变更方案。
• 实现（Implement）——在边界明确的小范围内完成变更。
• 验证（Prove）——运行检查并保存证据。
• 审查（Review）——追问哪些地方可能出问题，以及还有哪些未知项。
• 发布（Release）——由人类批准最终操作。

这套流程为速度赋予了结构。请求范围扩大时，它也能让你更容易及时停下来。

3. 让证据成为 Pull Request 的一部分

PR 回答的不应该只有“修改了哪些文件”。增加一段简洁的证据信息会很有帮助：

## Evidence
- Checks run: ...
- Result: pass / fail / not run
- Risk introduced: low / medium / high
- Rollback: ...
- Human decision needed: yes / no
- Known gap: ...

目的不是增加繁文缛节，而是让 reviewer 无需重放整个工作过程，也能做出合理的决策。

4. 让高影响操作始终由人类掌控

不要让 Agent 在无人知情的情况下，获得以下事项的处置权限：

• secrets 和私钥
• 支付和资金转账
• 向团队外部发送消息
• 生产环境部署
• 不可逆的数据删除

Agent 可以准备计划、diff、交易草稿或 release note，但不可逆的最终操作应该由人类负责。

5. 衡量工作流，而不是模型

真正有用的是这些务实的指标：

• 从收到请求到产出第一个可供 review 的计划所需的时间
• 包含证据的 PR 占比
• 因范围不明确而造成的返工
• 被回滚或推迟的发布
• 在文档约定流程之外完成的人类审批

这些指标能告诉你，这套操作体系的薄弱环节在哪里。模型变得更快，并不能解决隐藏不明的审批边界问题。

一套用于起步的小型工具包

我把这些想法整理成了一套零依赖的 Markdown 模板，其中包括仓库契约、需求与 Bug 简报、PR 与发布门禁、五个工作流 prompt、安全边界、每周检查清单，以及一个离线看板。这里提供免费预览版，以及扩展的团队版和工作室版：

https://jadiface.gumroad.com/shipkit-ai-safer-shipping-with-coding-agents

https://jadiface.gumroad.com/l/shipkit-ai

这些模板是刻意设计得平淡无奇。越是朴素的基础设施，就越容易 review、调整和信任。

如果你正在真实的代码仓库中使用 Coding Agent，最有价值的下一步通常不是再写一个 prompt，而是把那些 prompt 无法替你决定的边界明确记录下来。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。