|
|
你有没有遇到过这种情况:把问题丢给 AI,得到一堆废话,或者答案完全跑偏?
不是 AI 不够聪明,是你没说清楚。
提示词工程(Prompt Engineering)听起来玄,但对程序员来说其实很好上手——你每天都在写函数签名、API 文档、需求说明,本质上做的是同一件事:把意图表达清楚。
这篇文章只讲编程场景,帮你少走弯路。
━━━━━━━━━━━━━━━━━━━━
为什么程序员写的 Prompt 经常踩坑
先说三个最常见的问题。
问题一:需求太模糊。"帮我写一个排序算法"——什么语言?什么数据结构?对时间复杂度有要求吗?数据量级?AI 只能猜,猜错了你还得重问一遍。
问题二:上下文缺失。"这段代码有 bug,帮我看看"——没有代码,没有报错信息,没有环境版本。AI 在帮你算命。
问题三:没有约束条件。"帮我优化这个函数"——优化什么?速度?可读性?内存占用?不说清楚,AI 会给你一个"全面优化"的版本,然后把你精心设计的接口改得面目全非。
对症下药,才能开始聊技巧。
━━━━━━━━━━━━━━━━━━━━
三板斧:写出高质量 Prompt
第一板斧:角色设定
给 AI 一个具体的身份,输出质量会明显提升。
不是因为 AI 真的有角色意识,而是角色设定帮助模型收窄了回答范围——"资深 Go 工程师"和"Python 初学者辅导老师"看同一个问题,给出的答案天壤之别。
模糊版本:
加上角色:你是一名有 10 年经验的 Go 工程师,熟悉高并发场景下的性能优化。请 review 以下代码,重点关注 goroutine 泄漏和锁竞争问题。
后者会让 AI 直接聚焦在你真正关心的点上,而不是泛泛地说"变量命名可以更清晰"。
角色设定的几个实用场景:
安全审计:"你是一名专注 Web 安全的渗透测试工程师"
架构设计:"你是一名设计过亿级流量系统的架构师"
代码审查:"你是一名严格遵循 Clean Code 原则的技术 lead"
学习辅导:"你是一名善于用类比解释复杂概念的技术导师"
注意:角色要具体,"你是一名程序员"基本没用。越具体,越有效。
━━━━━━━━━━━━━━━━━━━━
第二板斧:示例驱动
这是最被低估的技巧。
当你描述一个需求时,语言是有歧义的。但输入输出的例子没有歧义。
光靠描述:
"驼峰转下划线",AI 大概知道你要什么,但具体处理边界情况时,它只能靠猜:
转成还是?
转成还是?
加上示例:>
现在 AI 知道你对连续大写字母的处理方式,边界情况有了明确答案。
示例驱动在以下场景特别有效:
数据格式转换:告诉它输入长什么样,输出要长什么样
代码风格规范:给一段"好代码"和"坏代码"的对比
错误处理模式:示范你期望的错误处理方式
注释风格:给一段你满意的注释作为参考
提供 2-3 个示例通常就够了。太多示例会让 Prompt 变臃肿,反而降低效果。
━━━━━━━━━━━━━━━━━━━━
第三板斧:约束条件
这是写给程序员最重要的一条。
你平时写代码,会有语言版本、依赖限制、性能要求、兼容性约束……这些同样要告诉 AI。不说,它默认选"看起来最好"的方案,不一定是适合你的方案。
约束条件的四个维度:
1. 技术栈和版本- 语言:Python 3.9(不能用 3.10+ 的新特性)
- 框架:FastAPI 0.95,不引入新依赖
复制代码
2. 性能和规模- 数据量级:日处理 100 万条记录
- 响应时间要求:P99 < 100ms
- 内存限制:单实例 512MB
复制代码
3. 输出格式- 只输出代码,不需要解释
- 代码需要包含类型注解
- 函数要有 docstring
复制代码
4. 禁止事项- 不要修改函数签名
- 不要引入新的第三方库
- 不要改变错误处理逻辑
复制代码
"禁止事项"这一条很多人忽略,但非常关键。AI 天生喜欢"全面优化",如果你不说不能动什么,它会顺手帮你把接口改了,然后下游代码全挂。
━━━━━━━━━━━━━━━━━━━━
编程场景实战
理论讲完,看几个实际例子。
场景一:代码生成
- 你是一名熟悉 Go 并发编程的工程师。
- 请实现一个并发安全的本地缓存,要求:
- - 支持 Set(key, value, ttl) 和 Get(key) 操作
- - 过期 key 惰性删除(Get 时检查)+ 定期清理(每分钟一次)
- - 线程安全,使用读写锁优化读多写少场景
- - 不引入第三方依赖,只用标准库
- 示例用法:
- cache := NewCache()
- cache.Set("user:123", userData, 5*time.Minute)
- val, ok := cache.Get("user:123")
- 只输出代码,包含必要注释,不需要解释。
复制代码
场景二:代码审查
- 你是一名专注于 Python 代码质量的技术 lead,熟悉 PEP 8 和 Clean Code 原则。
- 请 review 以下代码,按优先级(高/中/低)列出问题:
- - 高:会导致 bug 或安全漏洞的问题
- - 中:影响可维护性的问题
- - 低:风格和规范问题
- 对每个问题,说明:问题描述 + 为什么有问题 + 修改建议
- [粘贴你的代码]
复制代码
场景三:调试排错
- Python 3.11,FastAPI 项目。
- 报错信息:
- [粘贴完整错误堆栈]
- 相关代码:
- [粘贴报错位置附近的代码]
- 我已经尝试过:
- 1. 检查了数据库连接,正常
- 2. 重启了服务,问题依旧
- 请分析可能的原因,按可能性从高到低排序,并给出每种情况的验证方法。
复制代码
━━━━━━━━━━━━━━━━━━━━
常用提示词模板速查
| 任务类型 | 核心要素 |
|---------|---------|
| 代码生成 | 语言+版本 / 功能描述 / 输入输出示例 / 约束条件 / 输出格式 |
| 代码审查 | 审查角度 / 问题分级标准 / 期望输出格式 |
| 调试排错 | 完整报错 / 相关代码 / 已排查项 / 环境信息 |
| 架构设计 | 业务规模 / 技术限制 / 核心诉求(性能/成本/可维护性) |
| 文档撰写 | 目标读者 / 文档类型 / 风格示例 |
| 重构优化 | 优化目标 / 不能改动的部分 / 验收标准 |
━━━━━━━━━━━━━━━━━━━━
一个反直觉的建议
很多人觉得 Prompt 越长越好,信息越多越好。
其实不是。
Prompt 的核心是信噪比,不是长度。堆砌无关信息会稀释重要指令,反而降低效果。
经验法则是:把每一句话都问一下自己——"去掉这句话,AI 的输出会变差吗?"不会变差,就删掉。
写好 Prompt 和写好代码一样,追求的不是"没有废话可加",而是"没有废话可删"。
━━━━━━━━━━━━━━━━━━━━
小结
三板斧记住就够了:
角色设定:给 AI 一个具体身份,收窄回答范围
示例驱动:用输入输出消除语言歧义
约束条件:说清楚技术栈、性能要求、禁止事项
这三点都是程序员的基本功——你每天都在做,只是换了个对象。
把对待函数签名的严谨,用在写 Prompt 上,AI 会给你体面的答案。 |
|