AI 编程协作提示词

把 AI 从“直接生成代码”引导到先理解、再修改、最后验证的工程闭环。通用提示词适用于多数编码 Agent；Claude Code 专用部分依赖其计划模式、SubAgent 等能力。

通用 AI 编程：15 条反表演话术

开工前：先摸底再动手

  1. 先别写代码，先告诉我你准备怎么坑我。 — 先列风险，再进入实现。
  2. 先给我 3 个可能原因，别急着改代码。 — 避免未经诊断就修改文件。
  3. 把你不确定的地方列出来。 — 显式暴露假设和信息缺口。

排查与理解：用清楚的话解释

  1. 用新人能听懂的话解释这个报错。 — 降低术语密度，建立共同理解。
  2. 像 code review 一样看这段代码。 — 聚焦具体风险，而非泛泛“优化”。
  3. 假装你是接手这个项目的倒霉同事，你最想骂哪里？ — 寻找坏命名、隐形复杂度和维护障碍。
  4. 这段代码如果半年后出 bug，最可能死在哪里？ — 主动寻找边界条件和长期风险。

测试与挑刺：减少迎合

  1. 假设测试会很阴险，你会补哪些用例？ — 寻找容易遗漏的异常路径。
  2. 不要夸我，直接挑刺。 — 要求给出可行动的批评。

控制改动范围

  1. 只改最小范围，别顺手优化。 — 限制爆炸半径。
  2. 如果只能改 10 行，你会怎么修？ — 用硬约束迫使方案收敛；十行不是绝对目标。
  3. 如果你要重构，先证明不重构为什么不行。 — 要求重构有必要性证据。

架构与决策：防止过度设计

  1. 这个方案哪里看起来很高级，但其实没必要？ — 识别装饰性复杂度。
  2. 请用最土但最稳的方式实现。 — 优先成熟、可验证的实现。
  3. 现在忘掉你刚才的方案，重新站在反方想一遍。 — 对已有方案进行对抗性复核。

Claude Code 工作流提示词

开工规划：先出方案再动手

  1. 先进入计划模式，只出方案，一行代码都不准碰。
  2. 我想做一个新功能，先别写代码，访谈我，把实现方式、交互、边界情况全部问清楚。
  3. 你是一位资深工程师，把这份开发计划狠狠审一遍，把所有隐患都给我挑出来。

先读后写：遵循现有约定

  1. 动手写方案之前，先把代码库里能复用的函数摸一遍，别重复造轮子。
  2. 先去看老功能是怎么实现的，摸清它的套路，再照着同样的方式做这个新功能。
  3. 如果我删掉这个函数，哪些地方会炸？

修 Bug：修根因并验证

  1. 把这个报错的根本原因修掉，不要打表面补丁，修完验证一遍真的能过。
  2. 粘贴完整报错信息，然后说：“修。” — 极简指令适合上下文已经完整时；复杂或高风险修改仍应补充边界和成功标准。

代码审查与验证

  1. 审一遍我还没提交的改动，把所有看着有风险的地方标出来。
  2. 对比 main 分支和这个分支的行为差异，证明你没有改坏任何东西。

及时止损

  1. 别硬改了，停下来，回到计划模式重新规划。
  2. 以你现在知道的一切，把刚才这版推倒，重新写一个优雅的方案。

知识沉淀

  1. 你又犯这个错了，把这次的教训写进 CLAUDE.md，以后别再犯。
  2. 拷问我这些改动，我答不上来，你就别让我提 PR。
  3. 我先讲一遍我对这块代码的理解，你来追问，把我没吃透的地方都问出来。

Warning

写入 CLAUDE.md、AGENTS.md 等长期规则前，应先确认教训具有跨任务复用价值，且不会与仓库既有规则冲突。

SubAgent、可视化与进度跟踪

  1. 这个任务比较复杂，多开几个 subagent 并行去做。
  2. 开一个 subagent，帮我检查【具体问题】。
  3. 画一张架构图，帮我快速看懂这个代码库的整体结构。
  4. 给这个任务建一个笔记目录，每次提交完代码就把进展更新进去。

推荐组合

新功能

先别写代码。读取相关实现、调用方和共享工具，列出可复用部分与不确定点。
访谈我，把目标、交互、边界条件和成功标准问清楚。
然后给出最小改动计划；计划确认前不要修改文件。

Bug 修复

先给出最可能的3个原因和区分它们所需的证据，不要急着改代码。
定位根因后，用最小范围修复；补一个能复现问题并说明业务意图的测试。
最后运行相关验证，明确说明哪些通过、哪些没有运行。

提交前审查

像严格的 code review 一样检查未提交改动。不要夸赞，优先寻找行为回归、边界条件、安全问题和缺失测试。
按严重程度列出问题，并给出精确文件和行号；如果没有可行动问题，明确说明。