Peter Steinberger 在个人博客中写道：

“These days I don’t read much code anymore. I watch the stream and sometimes look at key parts, but I gotta be honest - most code I don’t read.”

他的 GitHub 贡献图显示：2025年11月25日，一天提交了 688 次 commit，其中 296 次是 Clawdbot 项目。

这不是人类能完成的工作量，这是 AI 编程（Vibe Coding）的极致形态。

Vibe Coding 的工作模式

传统开发流程

1. 需求分析
2. 设计方案
3. 编写代码
4. Code Review
5. 测试
6. 部署

时间：数天到数周

Vibe Coding 流程

1. 用自然语言描述需求
2. AI 生成代码
3. 运行测试（可选）
4. 如果有问题，告诉 AI 修复
5. 直接提交

时间：数分钟到数小时

示例对话：

开发者: "Add Microsoft Teams integration with message sending support"

AI: [生成 3 个文件，800 行代码]
    - src/channels/teams.ts
    - src/channels/teams-auth.ts
    - test/channels/teams.test.ts

开发者: "Run the tests"

AI: [执行测试，3 个失败]

开发者: "Fix the failing tests"

AI: [修改代码，所有测试通过]

开发者: "Commit with message 'feat: add Teams integration'"

AI: [执行 git commit]

全程不需要阅读代码。

一天 688 个 commit 的实现

Peter 的工作流程（推测）：

// 伪代码
for (const issue of github.getIssues()) {
  const prompt = `
    Issue: ${issue.title}
    Description: ${issue.body}
    
    Fix this issue and commit the changes.
  `;
  
  await claude.executeTask(prompt);
  // AI 自动：分析问题 → 修改代码 → 运行测试 → 提交
}

两台电脑并行工作：

• 电脑A（长任务）：处理复杂的重构、新功能
• 电脑B（短任务）：修复 bug、更新文档、依赖升级

每个任务完成后自动 commit，所以一天能产生几百个提交。

安全性的致命缺陷

研究数据：只有 10.5% 的代码是安全的

2025年底发表的论文《Is Vibe Coding Safe?》测试了多个 AI 编程工具：

测试方法：

• 200 个真实的软件工程任务
• 使用 Claude Sonnet-4、GPT-4、SWE-Agent 等工具
• 评估功能正确性和安全性

结果：

工具	功能正确率	安全代码率
SWE-Agent + Claude-4 Sonnet	61%	10.5%
Claude-4 Sonnet (直接使用)	47.5%	8.25%

解读：

• 超过一半的代码功能正确（能运行、通过测试）
• 但只有不到 1/10 的代码是安全的
• 功能正确 ≠ 安全

常见的安全漏洞

论文发现 AI 生成的代码中，高频出现的问题：

1. 硬编码敏感信息

// AI 生成的代码
export class NotionClient {
  private apiKey = 'sk-notion-abc123xyz789';  // 硬编码！
  
  async fetchDatabase(dbId: string) {
    return fetch(`https://api.notion.com/v1/databases/${dbId}`, {
      headers: {'Authorization': `Bearer ${this.apiKey}`}
    });
  }
}

正确做法：

export class NotionClient {
  private apiKey: string;
  
  constructor() {
    this.apiKey = process.env.NOTION_API_KEY || '';
    if (!this.apiKey) {
      throw new Error('NOTION_API_KEY not set');
    }
  }
}

2. SQL 注入

// AI 生成的代码
async function getUser(userId: string) {
  const query = `SELECT * FROM users WHERE id = '${userId}'`;
  return db.execute(query);
}

// 攻击者输入: userId = "1' OR '1'='1"
// 执行: SELECT * FROM users WHERE id = '1' OR '1'='1'
// 结果: 返回所有用户

正确做法：

async function getUser(userId: string) {
  return db.execute('SELECT * FROM users WHERE id = ?', [userId]);
}

3. 路径遍历

// AI 生成的代码
app.get('/download', (req, res) => {
  const filename = req.query.file;
  res.sendFile(`./uploads/${filename}`);
});

// 攻击者请求: /download?file=../../../../etc/passwd
// 读取任意文件

正确做法：

app.get('/download', (req, res) => {
  const filename = path.basename(req.query.file);  // 移除路径
  const filepath = path.join(__dirname, 'uploads', filename);
  
  // 验证文件在允许的目录内
  if (!filepath.startsWith(path.join(__dirname, 'uploads'))) {
    return res.status(403).send('Forbidden');
  }
  
  res.sendFile(filepath);
});

4. 命令注入

// AI 生成的代码
async function convertImage(filename: string) {
  const cmd = `convert ${filename} output.jpg`;
  execSync(cmd);
}

// 攻击者输入: filename = "image.png; rm -rf /"
// 执行: convert image.png; rm -rf / output.jpg

5. 未验证的重定向

// AI 生成的代码
app.get('/redirect', (req, res) => {
  const url = req.query.url;
  res.redirect(url);
});

// 钓鱼攻击: /redirect?url=http://evil.com/fake-login

为什么 AI 会生成不安全的代码？

1. 训练数据中有大量不安全代码

AI 在 GitHub 上学习，而 GitHub 上：

• 教程代码通常不考虑安全（为了简洁）
• 旧项目的代码有已知漏洞
• 个人项目没有经过安全审查

AI 模仿了这些"不良示范"。

2. 安全规则太复杂

SQL 注入、XSS、CSRF、路径遍历…每种攻击都有独特的防御方式。

AI 无法记住所有边界情况，尤其在复杂的业务逻辑中。

3. 功能优先的指令

开发者的 prompt 通常是：

“实现一个文件下载功能”

而不是：

“实现一个安全的文件下载功能，防止路径遍历、验证文件类型、检查权限”

AI 按照指令优先实现功能，安全是"隐含"的要求，容易被忽略。

代码质量的不可见性

技术债务的累积

Vibe Coding 产生的代码往往存在：

1. 重复代码

// File A
function validateEmail(email: string) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

// File B (AI 重新生成了一遍)
function isValidEmail(email: string) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

// File C (又一个版本)
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
function checkEmail(email: string) {
  return emailRegex.test(email);
}

2. 不一致的命名风格

// AI 在不同文件中使用了不同的风格
const user_id = req.params.id;    // snake_case
const userId = req.body.userId;   // camelCase
const UserID = req.headers.id;    // PascalCase

3. 过度复杂的实现

// AI 生成的代码（30 行）
function calculateTotal(items: Item[]): number {
  let total = 0;
  for (let i = 0; i < items.length; i++) {
    const item = items[i];
    if (item.price) {
      if (item.quantity) {
        total += item.price * item.quantity;
      } else {
        total += item.price;
      }
    }
  }
  return total;
}

// 人类可能写的代码（1 行）
const calculateTotal = (items: Item[]) => 
  items.reduce((sum, item) => sum + (item.price || 0) * (item.quantity || 1), 0);

4. 未处理的边界情况

// AI 生成的代码
function divide(a: number, b: number): number {
  return a / b;
}

// 问题：
// - b = 0 时返回 Infinity
// - a = Infinity 时未处理
// - 参数是 NaN 时返回 NaN

维护成本的隐患

现在，Clawdbot 有 337 个 open issues。

其中很多是：

• “某个功能有时候不工作”
• “在特定情况下会崩溃”
• “与其他功能冲突”

这些问题往往需要：

1. 阅读大量 AI 生成的代码
2. 理解其设计意图（可能没有文档）
3. 修复而不破坏其他部分

如果原开发者"不读代码"，那谁来修复这些问题？

与传统软件工程的对比

代码审查的缺失

传统流程：

Developer writes code
  ↓
Peer review (check logic, security, style)
  ↓
Senior review (check architecture, edge cases)
  ↓
Merge

Vibe Coding 流程：

AI writes code
  ↓
Developer: "Looks good to me" (未读代码)
  ↓
Merge

Code Review 的价值：

• 发现逻辑错误
• 指出安全漏洞
• 统一代码风格
• 传递知识

Vibe Coding 跳过了这一步，风险全部推到生产环境。

测试驱动开发（TDD）的失效

TDD 流程：

1. 写测试（定义预期行为）
2. 运行测试（应该失败）
3. 写代码（让测试通过）
4. 重构（优化代码）

Vibe Coding：

1. 让 AI 生成代码和测试
2. 运行测试（通过）
3. 提交

问题：AI 生成的测试可能也有问题。

示例：

// AI 生成的代码
function processPayment(amount: number) {
  if (amount > 0) {
    // 处理支付
  }
}

// AI 生成的测试
test('processPayment works', () => {
  expect(processPayment(100)).toBeDefined();
});

测试通过了，但测试本身没有验证任何实际行为。

静态分析的警告被忽略

传统开发中，静态分析工具会发现问题：

$ eslint src/

  src/channels/teams.ts
    15:10  error    Unsafe assignment of an `any` value
    23:5   warning  Missing return type annotation
    45:10  error    Unused variable 'response'

开发者会修复这些问题。

但在 Vibe Coding 中：

$ eslint src/ --fix  # AI 自动修复

# 或者干脆
$ eslint src/ --quiet  # 忽略警告

工具发现的潜在问题被自动"修复"或忽略，没有人工判断。

责任归属的困境

谁该为 AI 生成的代码负责？

场景：Clawdbot 的一个安全漏洞被利用，导致用户数据泄露。

责任链：

用户 → Clawdbot (软件)
       ↓
     Peter Steinberger (维护者)
       ↓
     Claude AI (代码生成者)
       ↓
     Anthropic (AI 提供商)

法律上，责任在维护者（Peter）。

但他"不读代码"，怎么对代码质量负责？

如果他反过来起诉 Anthropic（“AI 生成了不安全的代码”），Anthropic 会说：

“AI 是辅助工具，最终责任在使用者。我们已在 ToS 中声明，AI 生成的代码不保证安全。”

结果：受害的是用户，但没人能真正负责。

开源协议的免责条款

Clawdbot 使用 Apache 2.0 License：

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND...

翻译：软件按"现状"提供，无任何保证。

但这是否能免除"明知代码可能不安全，却不审查"的责任？

法律尚未给出明确答案。

合理使用边界

并非所有场景都不能用 Vibe Coding。

适合的场景

1. 原型开发

目的：快速验证想法
要求：功能优先，短期使用
风险：可接受（不涉及真实数据）

2. 一次性脚本

// 批量重命名文件
const files = fs.readdirSync('./images');
files.forEach(file => {
  const newName = file.replace(/\s+/g, '-').toLowerCase();
  fs.renameSync(`./images/${file}`, `./images/${newName}`);
});

3. 简单的 CRUD 应用

场景：内部工具，用户量小
逻辑：增删改查，无复杂业务规则
风险：低（有人工监督）

不适合的场景

1. 安全关键系统

• 支付处理
• 认证授权
• 数据加密
• 医疗设备

2. 高并发系统

AI 生成的代码可能存在性能问题（N+1 查询、内存泄漏）。

3. 长期维护的项目

Vibe Coding 产生的代码可读性差，后续维护成本高。

4. 合规要求的行业

金融、医疗等行业需要代码审查、审计，AI 生成的代码难以追溯。

我的观点

Vibe Coding 是一个强大的工具，但不是万能钥匙。

当前的问题

1. 安全性严重不足：只有 10.5% 的安全率，不可接受
2. 维护成本被低估：短期快速开发，长期偿还债务
3. 责任归属不清：出问题后没人能负责

可能的演进方向

1. AI 辅助 + 人工审查

AI 生成代码 → 人工审查（聚焦安全、边界情况） → 提交

不是"不读代码"，而是"重点读关键部分"。

2. 专业化的 AI 模型

训练专门针对安全代码的模型：

• 数据集：只包含通过安全审查的代码
• 奖励函数：惩罚不安全的模式
• 测试：包括安全测试用例

3. 形式化验证

AI 生成代码后，自动运行形式化验证工具：

# 验证代码符合安全规范
verify --spec security.tla src/

只有通过验证的代码才能提交。

4. 分级开发模式

原型阶段：Vibe Coding (快速迭代)
  ↓
MVP 阶段：AI 辅助 + 人工审查 (平衡速度和质量)
  ↓
生产阶段：传统开发 (严格审查、测试)

个人建议

对于开发者：

1. 不要盲目信任 AI 生成的代码
2. 至少审查安全关键部分（认证、授权、数据处理）
3. 使用静态分析工具，不要忽略警告
4. 为 AI 生成的代码添加单元测试
5. 定期安全审计

对于用户：

1. 评估项目的安全要求
2. 检查是否有安全审查流程
3. 不要在关键场景使用"Vibe Coded"的软件

Vibe Coding 让"人人都能编程"成为可能，但也让"人人都能制造漏洞"成为现实。

技术进步不能以牺牲安全为代价。

"不读代码"可能是高效的，但也是危险的。

在 AI 代码生成技术更成熟之前，人类的审查仍然是不可替代的。