与其纠结「AI 写的代码能不能用」，不如建立一套让 AI 为你所用、且可控的方法论。

---

一、为什么很多人觉得：AI 写的代码“看起来对，用起来坑”？

这是我在和不少开发者交流时，反复听到的一句话：

“Claude Code 写的代码挺像那么回事，但我不太敢直接用。”

这个感觉其实非常正常，原因并不在 AI，而在于：

• AI 默认产出的是「示例级代码」
• 而我们真正需要的是「工程级代码」

示例代码的特点是：

• 能跑
• 逻辑顺
• 覆盖主流程

工程代码关注的却是：

• 边界条件
• 异常处理
• 可维护性、可测试性

👉 问题不是 Claude Code 不行，而是我们不能把“默认输出”直接当终稿。

---

二、我的核心原则：把 Claude Code 当“初级工程师”

在真实项目中，我给 Claude Code 的定位非常明确：

一个执行力很强、但需要严格 Code Review 的初级工程师。

基于这个定位，我给自己定了三条铁律：

1. ❌ Claude Code 的代码 不允许无审查直接上生产
2. ✅ Claude Code 非常适合完成 70% 的基础工作
3. ✅ 最终责任人，永远是我，而不是 AI

有了这个前提，后面的协作才是健康的。

---

三、我给 Claude Code 设定的 4 条工程级约束

下面这 4 条，是我在 Prompt 中几乎每次都会明确写出的约束条件。

1. 明确运行环境与技术栈

- Python 3.10
- 使用 pandas，不使用过时 API
- 不依赖系统级第三方工具

原因很简单：

不写清楚，AI 一定会“自由发挥”。

---

2. 要求函数级拆分，而不是一坨脚本

请将代码按功能拆分为多个函数，
每个函数只做一件事，便于单元测试。

这一步的收益极高：

• 可读性明显提升
• 后续修改成本更低
• 非常利于 Code Review

---

3. 强制异常处理与边界说明

我通常会这样写：

请考虑以下异常情况：
- 文件不存在
- 数据为空
- 字段缺失
并给出合理的异常处理方式

这一步，往往能直接过滤掉 “只能在理想环境运行的代码”。

---

4. 要求自我审查（这一条最关键）

请你以代码审查（Code Review）的角度，
检查以上代码可能存在的问题，并给出改进建议。

很多时候，Claude Code 给出的 “改进版”：

• 比第一版稳健
• 注释更清晰
• 风格更接近工程规范

---

四、真实案例：一次 Bug 是如何被 AI“自己修掉”的

在一次 Excel 自动化脚本中，Claude Code 初版逻辑如下：

• 直接假设某字段一定存在
• 对空 DataFrame 没有防护

我没有自己改，而是直接追问：

如果某些 Excel 文件中缺少该字段，这段代码会发生什么？
请修复这个问题。

Claude Code 的反馈非常关键：

• 明确指出会抛出 KeyError
• 给出字段校验逻辑
• 在数据为空时提前返回并记录日志

👉 这个过程，本质上就是一次完整的 Code Review 对话。

---

五、哪些代码我绝不会让 Claude Code直接上生产？

说清楚边界，反而更安全。

以下几类代码，我一定人工重写或逐行审：

• ❌ 核心交易 / 金额计算逻辑
• ❌ 安全相关代码（鉴权、加密、权限）
• ❌ 高并发、强性能敏感模块

原因只有一句话：

这些地方，出错成本太高，不适合“猜”。

---

六、Claude Code 真正擅长的，是“降低下限”

我越来越清楚地意识到一件事：

Claude Code 并不会直接拉高你的技术上限，
但它能极大地抬高项目的“最低完成质量”。

它非常适合：

• 模板代码
• 工具脚本
• 基础 CRUD
• DevOps 自动化

而开发者真正的价值，体现在：

• 架构决策
• 技术取舍
• 风险判断

---

七、写在最后：别期待“完美代码”，要建立“协作流程”

如果你还在问：

“Claude Code 写的代码到底靠不靠谱？”

我的答案是：

靠谱不靠谱，取决于你有没有一套可控的使用方式。

把它当成工具，它只是工具；

把它纳入流程，它才是生产力。