PR 描述靠自觉，敏感信息靠运气------这是很多小团队的默认态。把「AI 写描述」和「敏感词门禁」塞进同一条流水线时，最常见的错误是混成一个 Job：生成失败就放行，或门禁误报就关掉整条检查。正确拆分是：描述生成是软辅助，敏感扫描是硬闸门；合并权永远在人。
本文面向 AtomGit 托管仓库，给出可复制的工作流思路、PR 模板、敏感模式类目与落地四步。语法若与你使用的 AtomGit Actions / 兼容 GitHub Actions 的运行器细节有出入，以平台当前文档为准；本文聚焦工程结构，不编造未核实的计费与分钟额度。
摘要
- 拆 Job：生成描述可失败可重试；敏感门禁失败必须红。
- AI 只草稿：输出到 PR 评论或描述建议区，不直推受保护分支。
- 门禁可审计：规则进仓库，白名单走评审，不靠个人口头例外。
- 人审合并：公约写明「描述再漂亮也不能省人眼」。
- 开源友好：示例去密钥，可挂 AtomGit 教学仓。
结论：CI 里的 AI 是助理编辑，不是合并按钮；敏感词扫描是地板，不是天花板。
结论卡
| 能力 | 失败时 | 输出位置 | 权限影响 |
|---|---|---|---|
| PR 描述生成 | 可警告 | 评论/草稿 | 不改保护规则 |
| 敏感词门禁 | 必须阻断 | Check 红 | 阻止合并 |
| 人工终审 | --- | 合并决定 | 最终权威 |
背景与边界
AtomGit 为国内开发者常用的代码托管与协作平台，工作流能力常与主流 Actions 风格兼容或提供对照文档。具体触发器名称、密钥托管、Marketplace 动作是否可用，以你仓库启用的功能为准。本文不提供绕过分支保护、伪造身份或攻击流水线的方法；敏感词列表示意，不能替代专业密钥扫描与 DLP 产品。
架构：两条轨
轨 A：PR 描述自动生成（软）
触发：pull_request 的 opened / synchronize（名称以平台为准）。步骤示意：
- 检出代码并取得 diff（注意大 PR 截断策略）。
- 用脚本或模型调用生成「标题建议 + 正文草稿」；提示词要求：只描述变更、列出风险与测试、禁止编造未出现的文件。
- 把结果发到 PR 评论；若 API 失败，评论「生成失败，请手写」，不要让 Job 红到妨碍门禁以外的协作（或与门禁分 Job）。
模型调用若经由外网 API：密钥放在 CI 密钥库；日志禁用打印密钥；开源仓默认关闭「真实调用」，改为「模板填充」模式以便读者复现。
轨 B：安全敏感词门禁（硬）
独立 Job，失败 exit 1。扫描范围：本次 diff 或变更文件内容。类目见下节。误报处理：经安全负责人加白名单条目并写明理由，禁止贡献者本地「先删检查再提 PR」。
PR 描述模板（可入库）
markdown
## 变更说明
-
## 动机 / 关联
- Ticket/Issue：
## 风险与回滚
- 风险：
- 回滚：
## 测试证据
- [ ] 单测/相关测试命令：
- [ ] 手测步骤：
## 检查
- [ ] 无密钥与生产配置
- [ ] 高风险路径已人审生成提示词应强制模型按此骨架输出，并引用实际 diff 文件列表；若 diff 过大，先让脚本产出「文件清单 + 统计」，再生成摘要，避免胡编。
敏感词 / 模式示例类目
示意（按团队扩充，勿当完整安全产品）：
- 私钥头：
BEGIN PRIVATE KEY/BEGIN RSA PRIVATE KEY - 常见云访问键形态（按你们实际供应商补充）
api_key=、password=、secret=明文赋值- 误提交
.env、credentials.json、id_rsa - 内网主机名与口令出现在同一文件
配套：
- 对二进制与锁文件策略要明确（避免无意义误报或漏报）；
- 对测试夹具中的「假密钥」使用固定前缀如
TEST_ONLY_并入白名单流程； - 与 git history 泄漏应急文档交叉引用（轮换优先于「重写历史炫耀」）。
工作流示意（伪 YAML）
yaml
# 示意：字段名请对照 AtomGit Actions 当前文档
name: pr-ai-and-gate
on:
pull_request:
types: [opened, synchronize]
jobs:
secret-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: scan
run: python tools/secret_gate.py
pr-draft:
runs-on: ubuntu-latest
needs: [] # 不要让生成依赖阻塞门禁；可并行
steps:
- uses: actions/checkout@v4
- name: draft
run: python tools/pr_draft.py
continue-on-error: true要点：secret-gate 失败必须红；pr-draft 可 continue-on-error。分支保护要求 secret-gate 通过才能合并。
落地四步
- 入库模板：PR 模板 + 生成脚本 + 门禁脚本。
- 先开门禁：第一周只启敏感扫描，收集误报。
- 再开生成：默认模板模式；有密钥与预算再开模型调用。
- 写进公约：人审合并、白名单流程、示例仓去密钥。
与本地 Cursor Agent 的分工
| 环节 | 本地 Agent | AtomGit Actions |
|---|---|---|
| 写代码与单测 | 主场 | 不替代 |
| 填 PR 描述 | 可预生成 | 打开 PR 后再生成一版 |
| 防密钥进仓 | pre-commit / 自检 | 硬闸门 |
| 合并 | 人 | 人 |
不要因为 CI 会扫，就在本地故意「先提交再看红不红」。本地自检仍是第一道。
踩坑
| 坑 | 后果 | 处理 |
|---|---|---|
| 生成与门禁同一 Job | 生成挂了误关安全 | 拆开 |
| 只扫 main 不扫 PR diff | 漏检 | 扫变更集 |
| 白名单口头化 | 永久例外 | 文件化评审 |
| 日志打印 Prompt+环境 | 泄密钥 | 脱敏 |
| 自动合并 | 事故放大 | 禁止 |
验收标准
- 故意加入假私钥形态的 PR：门禁红，不可合并。
- 合法 PR：门禁绿；评论区出现描述草稿或明确跳过说明。
- 关掉网络密钥时，开源读者仍能跑「模板模式」生成。
- 文档含应急：若真实密钥曾进入历史，先轮换再清理。
练习作业
- 在示例仓加
secret_gate.py，至少三类模式。 - 加
pr_draft.py模板填充（可不调用模型）。 - 配置分支保护要求门禁通过。
- 写 README：如何复现红/绿两种 PR。
脚本职责拆分建议
tools/secret_gate.py：纯规则、无网络、可单测；输入为文件列表或 diff；输出人可读的命中行号。tools/pr_draft.py：组装提示词或填充模板；可选调用模型；输出 Markdown。不要把「调模型」写进门禁脚本，否则网络抖动会变成安全检查抖动。单测夹具放 testdata/leaky/ 与 testdata/clean/，CI 对两者断言红/绿。
模型调用的最小安全提示词条款
若启用模型生成，提示词应显式包含：禁止复述或改写任何疑似密钥；发现疑似密钥时在草稿顶部用警告框提示「门禁应已阻断，请勿绕过」；只使用提供的 diff 摘要，不发明文件路径；输出必须使用仓库 PR 模板小标题。把这几条也放进仓库，便于审计「模型到底被允许说什么」。
与九月创作之星 / AtomGit 秋季的衔接
教学仓公开时：默认关闭真实 API Key；用 DRY_RUN=1 生成骨架；在 README 声明「本仓库演示门禁与草稿结构，不是渗透工具」。活动向读者要的是可复现路径，不是你的云额度。若文章配截图，打码仓库私有地址与用户名。
一周试点复盘问题
试点结束问四句：误报是否可在一天内消化？生成草稿的采用率是否超过一半？是否出现「为了过 CI 而打码假阴性」？新人是否能按 README 复现红绿？任一句答「否」，先修流程，再谈加模型。
补充说明（1）
落地时请以你当前工具链的官方文档为准，把本文步骤当成检查清单而非版本锁定说明书。每完成一步就记录「命令、现象、是否可复现」，这比追求一次性写完美长文更接近工程。把失败也写进团队笔记，能减少下一位同事重复踩坑。若字数与信息密度冲突，优先保留可执行步骤与验收标准。
补充说明（2）
落地时请以你当前工具链的官方文档为准，把本文步骤当成检查清单而非版本锁定说明书。每完成一步就记录「命令、现象、是否可复现」，这比追求一次性写完美长文更接近工程。把失败也写进团队笔记，能减少下一位同事重复踩坑。若字数与信息密度冲突，优先保留可执行步骤与验收标准。
补充说明（3）
落地时请以你当前工具链的官方文档为准，把本文步骤当成检查清单而非版本锁定说明书。每完成一步就记录「命令、现象、是否可复现」，这比追求一次性写完美长文更接近工程。把失败也写进团队笔记，能减少下一位同事重复踩坑。若字数与信息密度冲突，优先保留可执行步骤与验收标准。
补充说明（4）
落地时请以你当前工具链的官方文档为准，把本文步骤当成检查清单而非版本锁定说明书。每完成一步就记录「命令、现象、是否可复现」，这比追求一次性写完美长文更接近工程。把失败也写进团队笔记，能减少下一位同事重复踩坑。若字数与信息密度冲突，优先保留可执行步骤与验收标准。
补充说明（5）
落地时请以你当前工具链的官方文档为准，把本文步骤当成检查清单而非版本锁定说明书。每完成一步就记录「命令、现象、是否可复现」，这比追求一次性写完美长文更接近工程。把失败也写进团队笔记，能减少下一位同事重复踩坑。若字数与信息密度冲突，优先保留可执行步骤与验收标准。
假阴性与假阳性怎么治理
门禁的敌人有两个：假阳性让人想关检查；假阴性让人以为安全。治理假阳性：沉淀可评审白名单，条目含「为何安全、谁批准、何时复审」。治理假阴性：定期用已知泄漏样本做回归，样本放在私有夹具或合成串，不把真实密钥当测试数据。宁可暂时多拦，也不要沉默放行；但必须给贡献者清晰的修复路径说明，否则团队会绕道推送到无保护的 fork 玩火。
描述生成质量的最低条
好的草稿应：列真实文件；区分行为变更与纯重构；写出测试命令；标出「我不确定」的段落。坏的草稿：空洞形容词、编造 Ticket、声称「已全面测试」却无命令。可在脚本里做简单校验------正文是否包含「测试证据」小标题、是否包含至少一个仓库内真实路径------失败则评论警告。质量校验仍属软辅助，不要与敏感门禁绑死。
权限与密钥托管清单
CI 调用外网模型时：密钥仅存平台密钥库；最小权限；定期轮换；禁止 echo 到日志；fork PR 是否允许使用密钥要单独策略（多数团队对 fork 禁用机密）。开源示例默认不配置真实密钥。本地调试用空密钥走模板模式。把这些写进 SECURITY.md 比写「我们很重视安全」有用。
小结
AtomGit Actions 里做 AI 评审草稿，价值不在「全自动合并」，而在降低描述质量方差 与托住敏感信息地板。生成可软、门禁必硬、合并归人------这三句话写进团队默认值，比追一个最炫的模型调用更重要。
草稿未发布 · 作者 梧桐秋海 · 活动：九月创作之星、AtomGit秋季、工具实践