一、引子：当 AI 代码"看起来对了，跑起来就崩"
一个月前，接手了一个项目——前任用 Cloude Code 生成的代码堆了三个月，逻辑全对，但运行时像纸糊的一样。单元测试通过率 95%，上了生产就 OOM。debug 到凌晨三点，发现问题不在代码逻辑，而在代码质量——内存泄漏、异常吞噬、连最基本的防御性编程都没做。
这并不是 AI 本身的问题，而是"如何正确使用 AI"的问题。过去一个月，我开展了 200 多次 AI 代码生成实验，几乎踩遍了所有潜藏的技术坑，最终总结出这 5 个实用技巧。它们能帮助 AI 生成代码从"勉强能跑"进化为"敢于上线"的可靠状态。
二、技巧一：Prompt 里一定要写"非功能约束"
很多人在编写 prompt 时，习惯只交代功能需求："写一个用户登录接口"。AI 确实能够给出一个可用的实现——但通常缺乏输入校验、没有重试机制、日志输出也杂乱无章。问题的根源在哪？不是 AI 能力不够，而是你没有明确告诉它"做到什么标准"。
一个非常有效的做法是：在 prompt 末尾附加一份约束清单。
| 约束类型 | 示例 | 为什么重要 |
|---|---|---|
| 性能约束 | "单次请求不超过 200ms" | 防止 AI 写出三层嵌套循环 |
| 安全约束 | "所有用户输入必须 sanitize" | XSS/SQL 注入的第一道防线 |
| 可观测性 | "每个异常打印 trace_id" | 线上问题不用翻半天日志 |
| 资源管理 | "用 contextlib 管理数据库连接" | 杜绝连接泄漏 |
来看一下改造前后的效果对比：
改造前：
# 写一个获取用户信息的函数def get_user(user_id):cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")return cursor.fetchone()改造后（加了约束后的 prompt 输出）：
import loggingfrom contextlib import closingfrom typing import Optional, Dictdef get_user(user_id: int, db_conn) -> Optional[Dict]:"""获取用户信息，带输入校验和异常处理。Args:user_id: 用户 ID，必须为正整数db_conn: 数据库连接实例Returns:用户字典或 None"""if not isinstance(user_id, int) or user_id <= 0:logging.warning(f"无效的 user_id: {user_id}")return Nonetrace_id = logging.getLogger().getEffectiveLevel()try:with closing(db_conn.cursor()) as cursor:cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))row = cursor.fetchone()logging.info(f"[{trace_id}] 查询用户 {user_id}: {'找到' if row else '未找到'}")return dict(row) if row else Noneexcept Exception as e:logging.error(f"[{trace_id}] 查询失败: {e}")return None效果非常直观：加入约束后，AI 生成代码的质量评分从平均 62 分跃升至 84 分（基于一套自动化评分脚本的评估结果）。
三、技巧二：先让 AI 写测试，再让 AI 写实现
这个技巧源于一次深刻的教训。有一次让 AI 编写一个数据处理管道，它输出了 300 行代码，逻辑看起来无懈可击。结果上线后的第二天，某个边缘 case 触发了索引越界——因为那个场景在需求文档里根本没有被提及。
后来我彻底改变了工作流程：先让 AI 编写测试用例，明确所有边界条件，再用测试来驱动 AI 生成实现代码。
# step 1：让 AI 先写这个测试文件def test_process_user_data():assert process_user_data([]) == []# 空列表assert process_user_data(None) is None# None 输入assert process_user_data(["a"])[0]["status"] == "active"# 正常流程assert len(process_user_data(["a"] * 1000)) <= 100# 限流assert process_user_data(["x" * 10000]) == []# 超长输入将测试用例提供给 AI 后，生成的代码通过率从 67% 提升到了 93%。道理很简单：测试用例本身就是最精确的需求文档，它比用自然语言反复强调"要考虑边界情况"有效得多。
四、技巧三：拆碎再拼，比一次生成强三倍
让 AI 一次性生成一个完整模块，就像让实习生直接写出整个微服务——虽然能写出来，但后续几乎无法维护。
更优的做法是：将大型任务拆解为 3-5 个独立函数，逐个生成，最后再组合集成。
| 方法 | 生成耗时 | 后续修改耗时 | 缺陷率 |
|---|---|---|---|
| 一次性生成 | 2 分钟 | 25 分钟 | 35% |
| 拆碎后生成 | 5 分钟 | 8 分钟 | 12% |
拆解带来的优势十分明显：单个函数的逻辑范围更小，AI 出错的概率大幅降低；修复 bug 时只需替换一个函数，无需重构整个文件。
具体的操作步骤：
- 先写接口定义：明确每个函数的输入类型和输出类型
- 按功能拆成独立函数：把"处理订单"拆成"校验→计算→落库→通知"
- 让 AI 逐个生成：每次只处理一个函数，给上下文但不给全部代码
- 最后手动写组合逻辑：把函数拼成完整流程
五、技巧四：加一句反问——"这个方案有什么潜在问题？"
AI 默认只会给出最优路径的解法，不会主动告诉你它的方案在什么场景下会失效。但只需要加一句追问，它就能输出完全不同的代码。
这个技巧特别推荐用在代码审查场景。让 Claude Code 审完代码之后，再加一句追问："请列出这个方案在以下场景中的潜在问题：高并发、异常输入、首次运行。"
// AI 原本输出的代码（只在理想情况下跑得通）async function fetchUserData(userId) {const response = await fetch(`/api/users/${userId}`);return response.json();}// 追问"潜在问题"之后的优化版async function fetchUserData(userId, options = {}) {const { retries = 3, timeout = 5000 } = options;const controller = new AbortController();const timer = setTimeout(() => controller.abort(), timeout);for (let i = 0; i < retries; i++) {try {const response = await fetch(`/api/users/${userId}`, {signal: controller.signal,});if (!response.ok) throw new Error(`HTTP ${response.status}`);return await response.json();} catch (err) {if (i === retries - 1) throw err;await new Promise((r) => setTimeout(r, 1000 * (i + 1)));} finally {clearTimeout(timer);}}}一个小小的追问，就让代码从"只处理理想情况"升级为"全面考虑了网络故障、超时和重试机制"。效果立竿见影。
六、技巧五：搭脚手架，让 AI 填空
最后一个技巧可能是性价比最高的：不要让 AI 从零开始写代码，你搭好框架让它填充。
我观察到一个规律：AI 独立完成的代码有两个通病——命名风格前后不一致、目录结构随意。但当它沿着一套已有的代码规范工作时，输出质量会有明显提升。
推荐的工作流程：
- 手动搭好文件结构 + 类型定义
- 写一个示例函数的完整实现（给 AI 做"模板"）
- 让 AI 按照模板风格填充剩余函数
- 审查 + 批量修改
src/services/userService.ts # 手动写的骨架和示例实现orderService.ts# AI 按模板风格填充paymentService.ts# AI 按模板风格填充types/index.ts # 类型定义（手动）utils/logger.ts# 日志工具这种"脚手架模式"让 AI 输出的代码风格一致性从 70% 提升到了 95%。整个代码库看起来就像是一个人写的——哪怕实际上有两个人（你 + AI）在协作。
七、总结
5 个技巧，核心逻辑只有一句话：AI 是高效的执行者，但你需要教会它"按什么标准干"而不是"干什么"。
| 技巧 | 一句话概括 | 可量化效果 |
|---|---|---|
| 写非功能约束 | 告诉 AI 性能和安全的底线 | 质量评分 62→84 |
| 先测试后实现 | 测试即最精确的需求文档 | 通过率 67%→93% |
| 拆碎再拼 | 把模块拆成独立函数逐个生成 | 缺陷率 35%→12% |
| 追问潜在问题 | 让 AI 主动识别方案缺陷 | 防御性代码自动生成 |
| 搭脚手架 | 定好框架让 AI 填空 | 风格一致性 70%→95% |
这 5 个技巧全部来自过去一个月的真实踩坑经验。如果你也有"AI 生成的代码不敢上线"的困扰，不妨明天就试试第一个技巧——在 prompt 末尾加一行约束清单，效果立竿见影。
小实验：试试你的 Prompt 能打几分？
可以尝试编写一个简单的评分脚本，根据上面提到的 4 个约束维度（性能、安全、可观测性、资源管理）对 AI 生成的代码进行打分。下面是同一个需求使用两种 prompt 得到的结果：
Prompt A（只有功能描述）：
Prompt B（带非功能约束）：
结果：Prompt A 拿到的代码平均 61 分，其中一个版本甚至使用了字符串拼接 SQL。Prompt B 的代码平均 85 分，并且在安全维度上全部获得满分。
你现在就可以试试——把你平时使用的 prompt 加上约束清单，然后对比一下 AI 的输出质量。数据不会撒谎。
