20 个编程提示词, 让 AI 不再瞎猜

AI 写出烂代码,多半是因为模型自己填补了你留下的空白。这里的每个提示词都堵住一处空白:先读再写,先测再修,并把自己的猜测按可能性排好序说出来。

把[方括号]里的内容换成你自己的代码、报错或目标。

01. 动手之前,先划出影响范围

修改不是你写的代码之前。

阅读下面的代码。先不要编写或修改任何代码。

请告诉我:
1. 它做什么,不超过三句话。
2. 它对输入、调用方和运行环境做了哪些假设,逐条列出。
3. 如果我[描述你想做的修改],会有什么东西出问题,出在哪里。

如果需要查看其他文件才能回答,请说出文件名,然后停下。

[粘贴代码]

02. 先给原因排序,再谈修复

遇到一个你还解释不了的 bug。

这是一个报错和它周围的代码。

请列出三个最可能的原因,最可能的排在前面。每个原因都给我一条日志或一个测试,用来证实或排除它。

不要提出修复方案。我会去跑这些检查,再告诉你到底是哪个原因。

报错和堆栈信息:
[粘贴报错]

代码:
[粘贴相关代码]

03. 先写会失败的测试,然后停下

在你要新代码或修复之前。

使用[测试框架]为[函数或功能]编写测试。

覆盖正常情况、这些边界情况:[列出你已经知道的边界情况],以及至少两个你认为我没有考虑到的情况。用一句话说明这两个情况为什么重要。

每个测试在现有代码或缺失的实现上都应该失败。不要编写实现。

免费解锁其余 17 条提示词

订阅 Whizi 邮件通讯,即可阅读这套合集的全部内容。

  1. 以半夜被叫醒的人的视角审查 diff
  2. 重构,但不改变任何一个行为
  3. 挑出最先该读的五个文件
  4. 对照你真实的表结构来写查询
  5. 拿到正则,也拿到证明它可靠的用例
  6. 移植代码,读起来像母语者写的
  7. 从真实的性能分析里找出时间花在哪
  8. 追踪不可信输入,从源头到落点
  9. 写一份陌生人也能用的 README
  10. 根据 diff 写提交信息
  11. 用你自己的代码来学一个概念
  12. 先设计 API,再攻击这个设计
  13. 规划一次不让网站停机的迁移
  14. 让模型来向你提问
  15. 列出会让它崩溃的输入
  16. 找出依赖升级会弄坏你代码的地方
  17. 请第二个模型给第一个模型打分