开发者的 AI Prompt 模式库：我每天都在用的 15 个模板

为什么 Prompt 比工具更重要

用了一年多 AI 工具（Claude、Kiro、Cursor、ChatGPT），我的核心发现是：

工具的选择没那么重要，Prompt 的设计决定一切。

同样的问题，好 prompt 和坏 prompt 给出的答案质量差 5-10 倍。

这篇文章把我日常高频使用的 15 个 prompt 模板整理出来，分类归档。直接抄走改参数就能用。

我在《AI 是工程师的杠杆，不是替代品》里提过一个判断：调 prompt 比学新技能回报更高。这篇就是那句话的”施工图”——把我调出来的模板全部摊开。

分类

类别	使用频率
代码生成	每天 10+ 次
Code Review	每天 3-5 次
架构讨论	每周 2-3 次
调试排障	每周 3-5 次
学习新技术	每周 1-2 次
写文档	每周 2-3 次

代码生成类

模板 1：带约束的功能实现

需求：[一句话描述]

上下文：
- 技术栈：[语言 + 框架]
- 项目风格：[如何参照现有代码]
- 关键约束：[性能、兼容性、安全性等]

要求：
- 代码要能直接运行，不要伪代码
- 错误处理要完整
- 给出一个最小测试用例
- 不要过度抽象，能简单就简单

为什么好用：强制你先想清楚需求，也让 AI 知道边界。

模板 2：改造现有代码

下面这段代码有一个问题：[具体问题]

目标：[改造目标]

约束：
- 保持对外接口不变
- 改动要最小（只改必要部分）
- 改完后说明：为什么这样改、哪些行为变了

[粘贴原代码]

关键点：强调”改动最小”，防止 AI 顺手重构无关代码。

模板 3：写单元测试

下面这段代码需要完善的单元测试。

要求：
- 覆盖：正常路径、边界条件、异常路径
- 测试用例要有描述性命名
- 不要 mock 无关的东西
- 每个测试只验证一件事
- 给出一个"为什么这样测"的说明

[粘贴代码]

Code Review 类

模板 4：安全性审查

从安全性角度 review 下面的代码：

重点检查：
- SQL 注入、XSS、CSRF
- 权限校验是否完整
- 敏感数据是否可能泄露
- 错误处理会不会暴露内部信息
- 依赖是否有已知漏洞

不要列"没问题"的点，只列有问题的地方。
如果代码很安全，直接说"未发现明显问题"。

[粘贴代码]

模板 5：性能审查

下面的代码可能有性能问题。帮我找：

- 有没有 N+1 查询
- 有没有不必要的内存分配
- 有没有没必要的同步阻塞
- 有没有可以批量化的操作
- 有没有可以缓存的结果

[粘贴代码]

请按"问题严重度"排序（高/中/低）。每个问题给出：
1. 具体在哪
2. 为什么是问题
3. 怎么改

模板 6：PR Review

请对这个 PR 做一次 review。

PR 描述：[作者写的描述]
变更的核心点：[你自己总结]

请从以下维度评价：
1. 实现是否满足需求
2. 代码质量（命名、可读性、风格）
3. 有没有明显 bug
4. 有没有性能问题
5. 测试覆盖是否充分

格式：
- 对每个维度给一个评分（1-5）
- 对低分的维度给出具体的改进建议

[粘贴 diff]

架构讨论类

模板 7：方案对比

我要做 [具体功能]，考虑两个方案：

方案 A：[简述]
方案 B：[简述]

项目背景：
- 团队规模：[X 人]
- 现有技术栈：[...]
- 性能要求：[...]
- 未来方向：[...]

请从以下维度对比：
1. 实现复杂度
2. 运维成本
3. 扩展性
4. 风险点
5. 团队上手难度

最后给出推荐（如果没有明显好坏，说"两个都可以，选择取决于 X"）。

模板 8：架构评审

我在设计一个 [系统]，目前的方案：

[描述架构，可以是文字也可以是 ASCII 图]

请扮演一个资深架构师，对这个设计提出挑战：

- 找出 3-5 个潜在问题
- 问出 3-5 个我可能没想清楚的问题
- 给出 1-2 个可能的替代方案

不要夸我，专挑毛病。

关键：强调”挑毛病”，避免 AI 的讨好倾向。

模板 9：容量估算

帮我做一次容量估算：

系统：[描述]
当前规模：[用户数、QPS、数据量]
预期增长：[N 倍，X 时间内]

请估算：
1. 每个关键组件的 QPS 和存储需求
2. 瓶颈在哪个环节
3. 到达瓶颈时应该如何扩容
4. 成本预估（按云服务价格）

数据不够的地方给合理的假设，并标注假设。

调试排障类

模板 10：基于日志的排障

我遇到一个问题：[描述症状]

相关日志：
[粘贴日志，时间顺序]

已知信息：
- 什么时候开始出现：[时间]
- 什么操作触发：[操作]
- 影响范围：[多少用户 / 多少次]

请：
1. 根据日志推测最可能的原因（给出 2-3 种假设）
2. 对每种假设，说明如何验证
3. 不要直接给解决方案，先定位原因

如果信息不够，告诉我还需要什么。

模板 11：性能分析

下面这段代码跑得慢（[具体数据]），帮我分析：

[粘贴代码]

使用场景：
- 输入规模：[数据量]
- 调用频率：[多久一次]
- 当前耗时：[X ms]
- 期望耗时：[Y ms]

请：
1. 列出所有可能的性能瓶颈
2. 给出每个瓶颈的优化方案
3. 按"投入产出比"排序（优先做哪个）

模板 12：Bug 复现

我有一个 bug 不容易复现：[描述症状]

已知：
- 正常场景 99% 时间都工作
- 偶尔会出现 [具体现象]
- 我怀疑和 [某个因素] 有关

请帮我：
1. 列出 5 种可能的原因
2. 每种原因的"复现条件"
3. 如果要写一个必现的测试，应该怎么写

代码：[粘贴]

学习新技术类

模板 13：带上下文的学习

我是一个 [X 年] 后端工程师，熟悉 [Y 技术栈]。

现在要学 [新技术]，但我不想从 tutorial 开始。

请帮我：
1. 用我熟悉的 [Y 技术栈] 类比，解释核心概念
2. 列出 5 个"只在 [新技术] 才有，[Y] 没有"的关键差异
3. 推荐一个 20 分钟能跑起来的 hello world
4. 推荐 3 个值得深入看的话题（按优先级）

不要写"这是一个流行的技术"这种废话。

模板 14：源码阅读

我在读 [项目名] 的源码，想理解 [具体模块]。

入口代码：
[粘贴入口函数或文件]

请：
1. 用自然语言概述这段代码的核心逻辑
2. 标出关键的状态变量、控制流
3. 指出哪些是通用模式（其他项目也有）
4. 指出哪些是这个项目的特殊设计

不要一行行翻译代码，要抽象出"设计意图"。

写文档类

模板 15：写 API 文档

下面这段代码需要写 API 文档。

要求：
- 说明：这个 API 做什么（一句话）、使用场景
- 参数：每个字段的含义、类型、约束、示例
- 返回：正常返回结构 + 所有错误码
- 示例：一个 curl 请求 + 一个 response
- 限制：限流、超时、幂等性等

风格参照 Stripe API 文档。

[粘贴代码]

通用原则

用了一年多，我总结的几个通用原则：

1. 给足够的上下文

差 prompt：“这代码为什么不对？” 好 prompt：“我的项目是 X，用 Y 技术栈，这段代码本来想做 Z，但实际 [具体症状]。可能的原因？“

2. 明确边界

告诉 AI 你不要什么和告诉它你要什么一样重要。

比如：“不要重构这段代码，只改我提到的那一行”。

3. 要求结构化输出

给 AI 一个格式（bullet points、表格、分段），不要让它自由发挥。

4. 让它挑毛病

默认 AI 会讨好你。主动让它批评，效果好得多：

“请扮演一个挑剔的 senior，从 X 角度挑 5 个问题。“

5. 迭代比一次到位更好

第一次很难问到最好。把第一次的答案当作素材，继续追问：

“这个方案的风险点是什么？”
“如果规模大 10 倍呢？”
“有没有更简单的做法？“

结论

AI 工具的效能不取决于你用哪个产品，取决于你怎么提问。

这 15 个模板我每天都在用。我建议你收藏这篇，遇到对应场景直接复制模板，改参数，用。

用熟以后你会发展出自己的模板。Prompt 模板库是个人工程师的资产，值得长期维护。