Security 与 Privacy in Vibe Coding

AI 写代码时，最危险的不是它写出一个 bug，而是它把不该暴露的东西也一起带进 prompt、log、repo 或 PR。Vibe Coding 的速度很快，但速度越快，越容易跳过 security 和 privacy 的基本动作。

所以这页的重点不是“要注意安全”这种空话，而是把常见风险点和 minimum guardrail 写清楚。

---

最常见的风险，不是黑客级攻击，而是日常失误

真实项目里更常见的是这些问题：

• 直接把 API key 贴进对话
• 把 .env 内容复制给 AI
• 把客户数据样本原样贴进 prompt
• 新增 dependency 时不看 license 和维护状态
• 让 AI 改权限逻辑却没做边界验证

这些不是“高级攻防”，但足以在团队里造成很大问题。

---

第 1 步：Secrets 永远不要进 Prompt

最基本的规则：

• 不贴真实 API key
• 不贴真实 database password
• 不贴 .pem、token、cookie
• 不贴完整 .env

如果必须描述环境，应该用 placeholder：

OPENAI_API_KEY=YOUR_API_KEY
DATABASE_URL=YOUR_DATABASE_URL

AI 需要的是结构和用法，不是你的真实 secret。

---

第 2 步：处理真实 Data 时先做 Redaction

很多人调试功能时，会顺手把用户数据、客服记录、合同片段贴给 AI。
更稳的做法是先做 redaction：

• 姓名 -> User A
• 邮箱 -> masked
• 订单号 -> mock ID
• 合同金额 -> 区间或假数据

如果你把真实业务数据原样贴进 chat，再去谈 privacy policy，顺序已经错了。

---

第 3 步：让 AI 改 Auth / Permission 逻辑时必须更谨慎

有些代码区域，本来就不适合完全 trust AI：

• login / auth
• role / permission
• payment
• admin operation
• data export

不是说 AI 不能帮忙，而是这些地方必须：

1. 先明确 acceptance criteria
2. 要求最小改动
3. 跑边界测试
4. 做人工 review

---

第 4 步：Dependency 不是能跑就能加

AI 很喜欢“顺手加个包”。
风险在于它不一定会帮你判断：

• 这个包是否还在维护
• license 是否合适
• 是否存在更轻量替代
• 是否只是为了一个小功能引入很重依赖

更稳的问法是：

如果要新增 dependency，请说明：
- 版本
- license
- 维护状态
- 为什么值得引入
- 有没有 built-in 或更轻量替代

---

第 5 步：Log 也可能成为泄漏点

很多团队做 AI workflow 时，知道不能贴 secret，却忘了 log 也会泄漏：

• 错误日志打印完整请求
• debug 日志记录原始用户输入
• AI output 被原样写进监控系统

更好的原则是：

• log 记录必要 metadata
• 敏感 input 做 masking
• 出问题时能 replay 结构，不必保留完整原文

---

一个最小 Security Checklist

1. prompt 里没有真实 secret
2. 示例数据已做 redaction
3. 高风险逻辑有人工 review
4. 新 dependency 已检查 license 和维护状态
5. log 不包含不必要的敏感原文

---

常见误区

---

Practice

回看你最近一次 AI-assisted code change：

1. 有没有贴过真实 secret 或业务数据
2. 有没有新增 dependency
3. 有没有碰 auth / permission / payment 相关逻辑
4. 有没有足够的 validation 和人工 review

只要这 4 个问题里有一个你答不上来，这次改动的 security bar 就还不够高。