Day 13 提示词工程：写给程序员看的 Prompt 指南

共计 2609 个字符，预计需要花费 7 分钟才能阅读完成。

你有没有遇到过这种情况：把问题丢给 AI，得到一堆废话，或者答案完全跑偏？

不是 AI 不够聪明，是你没说清楚。

提示词工程（Prompt Engineering）听起来玄，但对程序员来说其实很好上手——你每天都在写函数签名、API 文档、需求说明，本质上做的是同一件事：把意图表达清楚。

这篇文章只讲编程场景，帮你少走弯路。

为什么程序员写的 Prompt 经常踩坑

先说三个最常见的问题。

问题一：需求太模糊。" 帮我写一个排序算法 "——什么语言？什么数据结构？对时间复杂度有要求吗？数据量级？AI 只能猜，猜错了你还得重问一遍。

问题二：上下文缺失。" 这段代码有 bug，帮我看看 "——没有代码，没有报错信息，没有环境版本。AI 在帮你算命。

问题三：没有约束条件。" 帮我优化这个函数 "——优化什么？速度？可读性？内存占用？不说清楚，AI 会给你一个 " 全面优化 " 的版本，然后把你精心设计的接口改得面目全非。

对症下药，才能开始聊技巧。

三板斧：写出高质量 Prompt

第一板斧：角色设定

给 AI 一个具体的身份，输出质量会明显提升。

不是因为 AI 真的有角色意识，而是角色设定帮助模型收窄了回答范围——" 资深 Go 工程师 " 和 "Python 初学者辅导老师 " 看同一个问题，给出的答案天壤之别。

模糊版本：

帮我 review 这段代码

加上角色：

你是一名有 10 年经验的 Go 工程师，熟悉高并发场景下的性能优化。请 review 以下代码，重点关注 goroutine 泄漏和锁竞争问题。

后者会让 AI 直接聚焦在你真正关心的点上，而不是泛泛地说 " 变量命名可以更清晰 "。

角色设定的几个实用场景：

• 安全审计：" 你是一名专注 Web 安全的渗透测试工程师 "
• 架构设计：" 你是一名设计过亿级流量系统的架构师 "
• 代码审查：" 你是一名严格遵循 Clean Code 原则的技术 lead"
• 学习辅导：" 你是一名善于用类比解释复杂概念的技术导师 "

注意：角色要具体，" 你是一名程序员 " 基本没用。越具体，越有效。

第二板斧：示例驱动

这是最被低估的技巧。

当你描述一个需求时，语言是有歧义的。但输入输出的例子没有歧义。

光靠描述：

帮我写一个函数，把驼峰命名转成下划线命名

" 驼峰转下划线 "，AI 大概知道你要什么，但具体处理边界情况时，它只能靠猜：

• XMLParser 转成 xml_parser 还是 x_m_l_parser？
• userID 转成 user_i_d 还是 user_id？

加上示例：

帮我写一个函数，把驼峰命名转成下划线命名。

示例：

• userName → user_name
• userID → user_id
• XMLParser → xml_parser
• getHTTPResponse → get_http_response

现在 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 和写好代码一样，追求的不是 " 没有废话可加 "，而是 " 没有废话可删 "。

小结

三板斧记住就够了：

1. 角色设定：给 AI 一个具体身份，收窄回答范围
2. 示例驱动：用输入输出消除语言歧义
3. 约束条件：说清楚技术栈、性能要求、禁止事项

这三点都是程序员的基本功——你每天都在做，只是换了个对象。

把对待函数签名的严谨，用在写 Prompt 上，AI 会给你体面的答案。