编程开发场景的提示词库
2026-10-19写代码时提示词的作用是缩小搜索空间
"帮我写个函数"之所以效果差，是因为模型的搜索空间太大——它不知道你的技术栈、不能改哪些文件、异常怎么处理、性能要求多少。这些不交代，它只能给你一个"教科书上常见"的实现。
好的编码提示词不追求"一次生成正确代码"，而是把问题约束到只有一两种合理写法。
1. 读代码（先理解，别改）
下面这段代码我要接手维护。先不要提改进建议，帮我读懂它。
【代码】（粘贴）
【技术栈】（语言/框架/版本）
【我知道的背景】（这段是做什么的，我了解到什么程度）
【输出】
1. 一句话说明这段代码的职责
2. 执行流程：按调用顺序列出主要步骤，标注每一步的输入输出
3. 关键数据结构：每个字段是什么、谁写谁读
4. 副作用清单：改了外部状态的地方（数据库、文件、全局变量、网络请求）
5. 可疑点：看起来可能有问题但你不确定的地方，说明"需要确认什么"而不是直接下结论
【禁止】
- 不要给重构建议
- 不要因为它"可以更简洁"就批评，先说明它的意图
- 不确定的地方标明"推测"，不要编造调用方2. 定位 bug（给现象，不给猜测）
帮我定位一个 bug。
【现象】（什么时候出现、报什么错、完整堆栈）
【复现步骤】（尽量具体）
【相关代码】（出错的函数 + 它的调用方）
【已经排除的可能】（我试过什么）
【请按这个顺序做】
1. 复述你对问题的理解，让我确认有没有跑偏
2. 列出最可能的 3 个原因，每个说明：为什么符合现象、怎么用最小改动验证
3. 指出需要我补充的日志或变量值
4. 只在你确定时才给修复代码；不确定就只给验证方法
【禁止】
- 不要在没确认原因前重写整段代码
- 不要同时改多个地方（无法判断哪个改动生效）
- 不要假设环境与我描述的不同3. 写测试（先列用例，再写代码）
为下面这个函数写单元测试。
【函数代码】（粘贴）
【测试框架】（如 pytest / jest，版本）
【我最担心出错的地方】（业务上最关键的分支）
【第一步：先只列测试用例，不要写代码】
用表格列出：用例名 / 输入 / 期望输出 / 覆盖什么情况
必须包含：正常路径、边界值、空值与 null、异常输入、以及功能本身的业务规则
【第二步：写完用例后等我确认，再生成测试代码】
【要求】
- 每个测试只断言一件事
- 测试名用"应该…当…"的自然语言，不要 test1/test2
- 不 mock 纯函数，只 mock 外部依赖（网络、数据库、时间）
- 不要为了覆盖率写没有断言的空测试4. 代码审查（按风险排序）
以严格的 code reviewer 身份审查这段改动。
【改动】（粘贴 diff 或改动后的完整文件）
【上下文】（这个模块干什么、改动目的）
【按风险从高到低输出】
1. 正确性：逻辑错误、边界、并发、错误处理
2. 安全：注入、越权、敏感信息泄露、依赖风险
3. 可维护性：命名、重复、耦合、隐式约定
4. 可测试性：难以测试的地方及原因
每条格式：文件:行号 → 问题 → 后果 → 建议改法（一句话）
只提你能指出具体位置的问题。
【禁止】
- 不提纯风格偏好（缩进、空行）除非项目有明确规范
- 不说"建议加注释"这种泛泛之谈
- 如果改动整体没问题，直接说"未发现高优先级问题"
【最后】
如果只能改一处，改哪里。怎么用
- 读代码时明确禁止它提建议。否则它会边读边批评，冲淡你对现有逻辑的理解。
- 定位 bug 时"已经排除的可能"这一栏很关键——不写，它会把你已经试过的路子再走一遍。
- 写测试要求"先列用例、等确认再写代码"。用例错了，代码写得再漂亮也是白写。
- 审查结果按风险排序，先看正确性和安全，风格问题可以放着。
- 所有"只改一处"的收尾问题都值得保留——它逼模型给出优先级，而不是一堆平权建议。
常见误区
- 一次让它改多个地方。出问题无法判断是哪个改动导致的。
- 不给技术栈和版本。它会给已废弃的 API 写法。
- 让它"顺便优化一下"。这会引入你没要求的改动，扩大 review 成本。
- 把它写的测试当成正确性证明。测试只能证明它测到的情况。
延伸阅读
让模型先思考再输出是否值得，见思维链的适用边界；让回答只依据给定资料，见检索增强生成的提示词设计。