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