2026 年已经出现过好几起"AI 帮倒忙"的标志性事故：把密钥 push 到 GitHub、给生产库连上错误的 migration、把内部 API token 写进开源 Skill 包……大多数事故根因不是模型"变坏了"，而是遵守的边界没说清。本章把 AI 编程里你必须画的几条红线讲清——你不对自己的代码负责，没人会替你负责。

7.1 AI 编程的四类风险

┌──────────────────────────────────────────────────────────────────┐
│ 风险           | 描述                                  | 触发场景      │
├──────────────────────────────────────────────────────────────────┤
│ 泄密           | 把 secret / 内部数据 / PI 写入产出     | 复制粘贴上下文  │
│ 漏洞           | 生成的代码 0day / 加固被错解            | 不做 review     │
│ 幻觉           | 引用不存在的 API / 包装不存在的方法       | 不验证          │
│ 责任           | "AI 说这样写没问题"，结果违反合规         | 出事甩锅        │
└──────────────────────────────────────────────────────────────────┘

7.2 泄密：最容易踩、最不该踩

7.2.1 三种典型现场

# ❌ 你贴给 AI 的代码里有真实 token
API_KEY = "sk-prod-..."  # 嘱! 我贴进 ChatGPT 了

# ❌ 你让 AI "生成 .env.example"
# 它有时候会顺手把真值塞进示例

# ❌ 你写 Skill，里面把 "测试时用这个邮箱" 写死
# Skill 上传到 GitHub 时一起泄密

7.2.2 三条强约束

  1. 任何贴给 AI 的代码先用 secret-scanner 扫一遍 
    pipx install detect-secrets
detect-secrets scan path/to/code/
  2. .env 永远不入 git，靠 .gitignore 兜底而非个人自觉
  3. Skill / Agent prompt 里不嵌真值——用 os.getenv("SLACK_TOKEN") 风格

沉淀经验：在 OpenCode / Claude Code 的 .opencode/ 或 .claude/ 里放一份 SECURITY.md，每次大会话开头让模型加载，AI 会"在场"地拒绝贴真 secret。

7.3 漏洞：模型产出的代码要审查什么

研究表明：模型对"常见 CWE 模式"是敏感的——它在生成时不会刻意制造 SQL injection，但它会因为省略输入校验而留下 injection 的可能。

7.3.1 五种要主动审查的目标

审查项 典型危险 工具辅助
SQL 拼接 f"SELECT ... WHERE id = {user_id}" sqlfluff, bandit
路径穿越 Path(user_input) 静态扫描 + review
命令 os.system("git clone " + url) bandit, semgrep
反序列化 pickle.loads(...) 禁用 + 接受评审
跳过权限 “为了 demo 提前 return” 源代码审计

实操：在 CI 中加三件套——

# 1. Bandit（Python）/ Semgrep（多语言）做静态扫
bandit -r src/
semgrep scan --config=p/python

# 2. 自带 secret 抓取
detect-secretsscan src/ --baseline .secrets.baseline

# 3. 依赖漏洞
pip-audit

让 AI 做上述三步的产物（tool_use transcript）扣在 PR 里，就有"双重审查"的效果。

7.4 幻觉：API / 库 / 文档不存在的引用

幻觉带来的安全风险经常被低估——它不一定立刻崩溃，却改变了你代码库语义。

# 模型虚构 pandas 的 df.fast_merge()
# ⚠️ 它不存在
result = df1.fast_merge(df2, how="left")

如果你把这段提交、半年后接手代码的同事按 grep 找 → 找不到 → 静态分析也不报错（可能是元类合成）。防御手段：

  1. 任何 AI 写出的"陌生 API" → 当场让 AI 自己写最小调用 demo 跑通
  2. 多次调用的陌生 API → 配 MCP docs server 让模型在生成时检索而非猜
  3. Skill / production prompt 里禁用“我猜这个 API…“循环

7.5 责任：什么不能甩锅给 AI

不能甩锅的事

  • 任何对真实环境做改动的操作（迁移、删数据、上线）
  • 任何对用户数据的操作（PII 处理、对外发送）
  • 任何对生产的关键设计决策（架构、license、third-party）

可甩锅的事

  • 把 5 千行 README 翻译成中英双语
  • 把样式表从头重写
  • 给你的代码加 unit test 样板

判断标准一条：对方付了钱 / 对方被波及真实损失吗？是 → 你要负责；否 → 你可以让 AI 蛮干。

7.6 一份"AI 安全 checklist”

每次让 AI 改动到非 demo 代码，自检：

□ 我读了 diff，没有"as any" / "@ts-ignore" / "# type: ignore"
□ 我搜过这个 PR 里没引入 secret / token / 真 email
□ 我加了新依赖 → 在 README 里记了 license + 用途
□ 我跑了 `bandit`/`semgrep`/`pip-audit` → 没新增 critical
□ 我跑了 unit test → 通过
□ 我把跨边界风险（执行命令、网络调用）做了白名单验证
□ 我至少 5 分钟慢读 review 过这 diff

把这 checklist 写成一个 Skill，自动注入到每次 commit hook 的 prompt 里——这就是"沉淀”。

7.7 合规与版权

容易被忽视的两个细节：

  1. 训练数据版权：用模型生成内容输出会不会包含他人作品片段？目前业界对此无定论，建议：
    • 对外发布的产出（如开源库代码、文章），自检抄袭 / 与某现有库高度相似时改写
    • 商业项目对 AI 出品代码加一行"AI-assisted"声明
  2. AI 输出标识：欧盟已要求 LLM 在境内所发布的"非真人作品"加 mark 标识，2026 年中美也在跟进。Skill / 文档 / 博客发布时建议标 ai-assisted。

7.8 小结

  • 四类风险：泄密 / 漏洞 / 幻觉 / 责任
  • 三条强约束：scan secrets / .env 不入 git / Skill 不嵌真值
  • 边界感：对方付了钱或被波及真损失 → 你必须做最后责任人

下一篇：《08 开发环境搭建：从 IDE 到 Agent CLI》——把前面的认知落地到可执行的环境。

Summary: 四类风险 + 三条强约束 + 一份 pre-commit checklist，把 AI 编程的责任边明确。