一个Python开发者花了3个月，写了400多个提示词草稿，最后只保留272个。不是因为他挑剔，是因为另外128个在真实代码里根本不好使。
这是前Google工程师、现独立开发者Matt在博客上的自述。他的日常工作是代码审查、后端调试、API架构设计——每次开工前，他得先花10到15分钟写提示词。不是写代码，是写怎么让AI帮他看代码。
更糟的是输出不稳定。同一套提示词，这次给出有效建议，下次变成泛泛而谈。他被迫反复调整、重新运行，时间全耗在"提示词工程"上，而不是解决实际问题。
400个草稿的筛选逻辑
Matt的筛选标准很直接：能在真实工作场景里反复产生可用输出。
被删除的提示词有两个共性特征。一是任务描述模糊，比如"Review my code and tell me what's wrong"（帮我看看代码哪有问题）。这种提示词返回的结果像开盲盒——有时抓得到重点，有时连边都沾不上。
二是过度绑定具体上下文。提示词里塞满项目细节，换个文件就得重写。Matt发现，真正好用的提示词走另一条路：任务类型和输出格式必须具体，但上下文保持通用。
他举了个对比案例。
低效的代码审查提示词："Review my code and tell me what's wrong"
高效的版本："Review the following code for: (1) logical bugs, (2) edge cases not handled, (3) readability issues, (4) performance concerns. For each issue found, provide: the specific line or section, the problem, and a concrete fix. If no issues exist in a category, say so explicitly."
后者的输出结构固定、可执行。更重要的是，它从Python到TypeScript都能用，不需要为每种语言重写。
为什么通用提示词包不好使
市面上"50个开发者必备ChatGPT提示词"的帖子满天飞。Matt的观察是：这些包大多是AI自己生成的，从没在真实输出上测试过。
它们的设计逻辑是"万能适配"——对什么都凑合能用，对什么都用不好。真正的Python后端开发和"帮我写个Python脚本"是完全不同的两类问题，需要不同的框架、不同的追问模式。
Matt的272个提示词全部围绕重复出现的具体场景：代码正确性与安全性审查、异步行为调试、REST API契约设计、SQL查询性能分析、pytest fixtures的隔离性验证。
以Python异步调试为例，模糊提示词得到的是："我看到你在用asyncio，这段代码可能在事件循环上有问题，以下是一些通用的异步调试建议……"
结构化提示词的输出则是逐条列出：await使用错误、缺失的await调用、可能阻塞事件循环的操作（CPU密集型任务、同步I/O）。每一项都指向具体代码位置，附带修复方案。
提示词设计的隐藏规律
从400到272的筛选过程，Matt总结出几条可迁移的经验。
第一，输出格式必须在提示词里明确定义。不要期待AI"理解你的意思"，要告诉它"按这个结构给我"。
第二，分类检查清单（checklist）比开放式提问可靠得多。让AI逐项确认，比让它自由发挥更能暴露盲区。
第三，"如果没有问题，明确说没有"——这条指令能大幅减少AI的幻觉输出。很多模型倾向于"给点建议显得有用"，即使代码根本没毛病。
第四，提示词长度和效果不是正相关。Matt淘汰的草稿里，有不少是他精心写的大段上下文说明。后来发现，把上下文放在提示词外部（比如单独粘贴代码），让提示词本身保持任务聚焦，效果更好。
从个人笔记到工具化
这272个提示词现在以两个形态存在：一个可搜索的文档库，以及5个CLI自动化脚本。后者是Matt正在写的系列第二部分——把提示词封装成命令行工具，直接对接代码文件。
他的使用场景是这样的：审查代码时，运行脚本传入文件路径，脚本自动加载对应的审查提示词模板，把代码内容填充进去，调用API，返回结构化报告。整个过程从15分钟压缩到30秒。
Matt没有开源全部272个提示词的具体文本，但提供了分类框架和筛选方法论。他的判断是：提示词的价值不在"收藏"，而在"经过自己工作流的验证"。
一个值得注意的细节是，这272个提示词全部针对GPT-4级别模型测试。Matt提到，在更小的模型上，同样的提示词结构需要额外调整——输出稳定性会下降，部分复杂任务需要拆分成多轮对话。
热门跟贴