明确AI可介入的任务边界

这件事不能停留在口头，必须形成可执行的机制。我建议采用三步法： 第一步，召开一次部门共识会议，在白板上现场列出三列清单——“鼓励AI辅助”、“必须人工复核”和“禁止AI接触”。“禁止AI接触”这一栏，务必写清楚：数据库连接串、JWT密钥、未经脱敏的客户手机号、合同扫描件的OCR文本、甚至灰度环境的配置路径，都要全部划入。 第二步，将这份清单固化为部门级别的`.ai-scope.yaml`配置文件，放置到所有项目的根目录下。文件中需要声明`allowed_patterns`和`blocked_paths`两个关键字段。更关键的是，必须改造CI流水线，强制校验该文件是否存在、格式是否合法，任何想跳过校验的行为都无法通过。 第三步，对于那些“鼓励AI辅助”的任务，例如生成单元测试、补全日志埋点代码、撰写内部技术文档初稿等，必须统一要求在AI输出中添加一段可追溯的注释标记，例如：``。这样一来，每段由AI生成的代码都有据可查，便于后续审计与问题定位。

执行高风险操作前的双签机制

对于某些风险等级极高的操作，必须实施双签机制，这是不能妥协的安全底线。重点关注以下两类操作： **方法一：数据库变更类操作** 所有包含`DROP`、`ALTER TABLE`、`TRUNCATE`等关键字的SQL脚本，必须走一套完整流程：AI生成SQL → 人工在本地执行`sqlfluff lint`检查 → 上传至GitLab发起Merge Request → 触发`ddl-review-bot`自动审查 → 最终由指定的DBA手动点击“批准”。在这个过程中，缺少任何一个环节，该MR都会死死锁定在`pending`状态，任何人都无法合并。 **方法二：生产配置修改类操作** 任何修改`/etc/prod/`目录下文件的Pull Request，必须附带完整的`diff`对比块。然后，必须由SRE工程师在评论区手工输入指令`/confirm-prod-change`，部署流水线才被允许启动。自动化是好的，但最终的决策权必须交给最了解生产环境的那个人。

统一Prompt资产与输出验证标准

Prompt是AI的指挥棒，绝不能随意使用。所有团队成员不得私自建立个人Prompt库。部门级的`prompt-registry/`目录下，只保留以下三类标准模板： - `test-gen-v2.jinja`：用于生成单元测试，目标覆盖率达到85%以上，生成后必须调用`pytest --cov-report=term-missing`进行验证。 - `doc-summarize-cn.md`：用于摘要技术文档，输出内容首行必须包含`## 摘要来源：{{url}}`，方便追溯原文出处。 - `security-checklist.md`：用于代码安全扫描的提示词，每次使用后必须运行`semgrep --config p/ci -q`命令并将结果截图存档。 这个操作本身很简单，把文件拖入目录就行。但如果有人跳过`semgrep`验证就直接合入PR，历史数据表明，这会使静态扫描的漏报率上升37%。去年第二季度发生的两起线上XSS漏洞，根因就在于此。

建立AI行为审计与回溯通道

最后，所有对阶跃AI的调用请求，必须通过部门统一网关`ai-gateway.internal`转发。该网关会强制记录以下信息： - 请求者的工号与所属二级部门 - 输入文本的SHA-256哈希值（只存储哈希，不保留明文） - 模型版本号与推理耗时 - 输出token数量以及是否触发敏感词拦截 这些审计日志需保留180天。SRE每天随机抽取10条记录进行审查，一旦发现越权调用行为，立即冻结对应的API Key。 还有一点必须注意：员工离职当天，其名下所有绑定的AI工具访问令牌必须同步失效。这是`hr-sync-job`任务的硬性退出条件，绝不可以跳过。无论自动化程度多高，安全这根弦必须时刻绷紧。