20 个编程提示词, 让 AI 不再瞎猜
AI 写出烂代码,多半是因为模型自己填补了你留下的空白。这里的每个提示词都堵住一处空白:先读再写,先测再修,并把自己的猜测按可能性排好序说出来。
把[方括号]里的内容换成你自己的代码、报错或目标。
01. 动手之前,先划出影响范围
修改不是你写的代码之前。
阅读下面的代码。先不要编写或修改任何代码。 请告诉我: 1. 它做什么,不超过三句话。 2. 它对输入、调用方和运行环境做了哪些假设,逐条列出。 3. 如果我[描述你想做的修改],会有什么东西出问题,出在哪里。 如果需要查看其他文件才能回答,请说出文件名,然后停下。 [粘贴代码]
02. 先给原因排序,再谈修复
遇到一个你还解释不了的 bug。
这是一个报错和它周围的代码。 请列出三个最可能的原因,最可能的排在前面。每个原因都给我一条日志或一个测试,用来证实或排除它。 不要提出修复方案。我会去跑这些检查,再告诉你到底是哪个原因。 报错和堆栈信息: [粘贴报错] 代码: [粘贴相关代码]
03. 先写会失败的测试,然后停下
在你要新代码或修复之前。
使用[测试框架]为[函数或功能]编写测试。 覆盖正常情况、这些边界情况:[列出你已经知道的边界情况],以及至少两个你认为我没有考虑到的情况。用一句话说明这两个情况为什么重要。 每个测试在现有代码或缺失的实现上都应该失败。不要编写实现。
免费解锁其余 17 条提示词
订阅 Whizi 邮件通讯,即可阅读这套合集的全部内容。
- 以半夜被叫醒的人的视角审查 diff
- 重构,但不改变任何一个行为
- 挑出最先该读的五个文件
- 对照你真实的表结构来写查询
- 拿到正则,也拿到证明它可靠的用例
- 移植代码,读起来像母语者写的
- 从真实的性能分析里找出时间花在哪
- 追踪不可信输入,从源头到落点
- 写一份陌生人也能用的 README
- 根据 diff 写提交信息
- 用你自己的代码来学一个概念
- 先设计 API,再攻击这个设计
- 规划一次不让网站停机的迁移
- 让模型来向你提问
- 列出会让它崩溃的输入
- 找出依赖升级会弄坏你代码的地方
- 请第二个模型给第一个模型打分