代码提示词工程
平庸和杰出AI辅助之间的区别
好的提示词是从AI编程工具获得出色结果的关键。本部分提供经过战斗检验的模板和最佳实践。
快速开始模板
🐛 调试
我遇到了这个错误：[错误信息]
在这个文件中：[文件路径]
相关代码：
[代码块]
上下文：[你试图做什么]
帮我理解什么出错了，以及如何修复。
🔄 重构
重构此代码使其更[可维护/高性能/可读]：
[代码块]
要求：
- 保持相同的功能
- 遵循[语言/框架]最佳实践
- 添加解释变化的注释
📝 文档
为此代码编写综合文档：
[代码块]
包括：
- 函数/类的目的
- 参数描述
- 返回值说明
- 使用示例
- 边界情况
🧪 测试
使用[测试框架]为这个函数编写单元测试：
[代码块]
覆盖：
- 快乐路径
- 边界情况
- 错误处理
- 边界条件
提示词工程原则
1. 具体明确
不好: "修复这个代码" 好: "重构这个React组件使用hooks而不是类组件，保持相同的功能"
2. 提供上下文
不好: "添加错误处理" 好: "在这个Next.js页面的API调用中添加try-catch错误处理和用户友好的消息"
3. 展示示例
不好: "编写一个函数" 好: "编写一个像这个示例一样的函数：[示例]，但适用于我的用例：[你的情况]"
4. 迭代
从广泛开始，然后精细化：
- "创建一个登录表单"
- "为电子邮件和密码添加验证"
- "添加加载状态和错误消息"
- "使其响应式和可访问"
模板类别
按任务类型
🎓 最佳实践
✅ 建议做的
- 提供完整的上下文和相关代码
- 指定技术栈
- 请求解释，而不仅仅是代码
- 不确定时请求多种方法
- 保存和重用成功的提示词
❌ 不要做的
- 不理解就复制粘贴
- 跳过错误信息或日志
- 使用含糊的语言（"更好"、"更快"）
- 忘记指定约束条件
- 忽视关于最佳实践的警告
高级技巧
思维链提示
让我们一步步解决这个问题：
1. 首先，分析需求
2. 然后，设计架构
3. 接下来，实现核心逻辑
4. 最后，添加错误处理和测试
[你的问题]
基于角色的提示
作为[角色]领域的高级专家，具有[技术]方面的专业知识。
审查此代码并提供：
- 安全问题
- 性能问题
- 最佳实践违规
[代码]
约束驱动的提示
编写一个[组件]具有这些约束：
- 必须支持[浏览器/版本]
- 无外部依赖
- 最多100行
- 遵循[风格指南]
[需求]
真实示例
示例1：React组件重构
之前（含糊）：
使这个更好
之后（具体）：
重构这个React类组件以：
1. 使用带hooks的函数组件
2. 提取自定义hooks进行数据获取
3. 添加TypeScript类型
4. 遵循React 19最佳实践
5. 改进可访问性
结果：更好的AI输出和明确的要求
示例2：bug调查
之前（不完整）：
这不起作用
之后（完整）：
我在这个React组件中遇到"无法读取未定义的属性'map'"：
[组件代码]
复现步骤：
1. 导航到/dashboard
2. 点击"加载数据"
3. 出现错误
预期：数据应该在列表中显示
实际：出现错误并且应用崩溃
环境：React 19、Next.js 15、Node 20
结果：精确诊断和解决方案
🛠️ 工具集成
对于Cursor
将经常使用的提示词保存为项目根目录中的.cursorrules文件。
对于Claude Code
创建一个prompts/目录，每个模板一个markdown文件。
对于ChatGPT/Claude
使用"自定义指令"功能设置默认行为。
📖 了解更多
- 最佳实践指南 - 高级技巧
🤝 贡献你的提示词
找到一个很好的提示词？ 与社区分享 →
FAQ
什么是编程提示词工程？
它是用清晰、结构化的提示词，让 AI 输出可验证的代码与解释的实践方法。
应该从哪个模板开始？
先从调试或重构模板开始，练习提供上下文、约束和期望输出。
如何避免提示词过于模糊？
说明目标、限制、输入/输出示例，并明确验证方式。