Prompt 工程与调试纠错——AI 写错了怎么办

提示词工程的兴衰

2023 年的狂热

2023 年是提示词工程（Prompt Engineering）最疯狂的一年。ChatGPT 刚出圈，GPT-4 发布，所有人都发现同一个大模型——输入不同的提示词，输出质量天差地别。

那时候模型能力有限、指令遵循能力弱、上下文窗口短（GPT-4 刚出时只有 8K），能不能用好 AI 几乎完全取决于会不会写提示词。于是催生了一大批"提示词工程师"、提示词市场、提示词付费课程。网上流传着各种"咒语"级别的神秘提示词模板，有人甚至把提示词当商业机密一样保护。

几种经典模式

2023 年系统学习提示词工程是必要的，如今工具已能自动完成相关工作。以下是当时沉淀下来的几种经典范式：

• Chain-of-Thought（思维链）：让模型一步步推理，而不是直接给答案
• Few-shot（少样本）：在提示词中给出 2-3 个示例，让模型模仿格式和风格
• Role-playing（角色扮演）：设定身份角色，约束输出风格和知识范围
• Structured Output（结构化输出）：明确指定输出格式
• Persona + Constraint（人格+约束）：组合角色设定和硬性约束条件

这些模式在今天仍然有效，但已经不需要像 2023 年那样专门学习了——因为工具替你做了。

至于写提示词的经验，核心就一句话：说清楚你要什么，别让它猜。

问题是什么 → 期望的输出是什么 → 必要的约束条件

不需要花哨的框架，也不需要"咒语"。把你心中最直白的需求写出来，就够了。

为什么现在不刻意提提示词工程了

到 2024-2025 年，提示词工程作为一个"独立技能"的地位大幅下降，原因有三：

1. 模型能力大幅提升：GPT-4o、Claude 3.5/4、Qwen 等模型的指令遵循能力远超 2023 年的水平。同样一句模糊的话，2023 年的模型可能跑偏，现在的模型能准确理解。

2. 工具抽象掉了提示词：像 Qoder 这样的编码 Agent 工具，背后的系统提示词（System Prompt）由工具自动拼接——Rule、Memory、上下文、任务描述被组合成最优提示词，用户只需要说清楚"要做什么"即可。提示词工程从用户侧转移到了工具侧。

3. 上下文窗口爆炸式增长：从 2023 年的 4K/8K 到现在的 128K/200K，模型能一次性吸收大量上下文。不需要精心压缩提示词，直接把相关代码丢进去即可。

结论：提示词工程没有消失，它只是变成了工具开发者的责任，而不是用户的责任。

Qoder 中的提示词优化

Qoder 提供了一些底层提示词优化配置，但是我很少用——因为早年学过提示词工程，已经养成了直接用自然语言描述需求的习惯，反而觉得那些配置项不需要额外折腾。

对于没学过提示词工程的用户，Qoder 提供了几个实用功能：

• Rule（规则）：写在 .qoder/rules/ 下的规则文件，自动追加到每次对话的 System Prompt 中
• Memory（记忆）：跨会话的上下文知识库，自动填充到提示词中
• 自定义 Agent 指令：在 AGENTS.md 中定义每个 Agent 的行为风格

这些本质上都是在帮你做提示词工程，只是不需要你自己写 Prompt 了。

在 Growth AIOS 产品中，提示词中心（Prompt Center）提供了可视化的提示词模板管理，支持标签分类、变量定义和 YAML Frontmatter 元数据：

新建提示词时，支持通过 AI 辅助生成内容，也可以在文件头部添加 YAML Frontmatter 定义标签和变量：

不要怪 AI，要分析提示词

在实际使用中，AI 写错代码是常态而不是异常。关键不是"AI 为什么错了"，而是怎么快速定位问题和纠正方向。

大部分"AI 写错了"的问题，根因不在 AI，而在提示词。AI 不是有意犯错，而是你给它的信息不足以让它做出正确的决策。

案例分析

案例一：输出格式冲突

Agent 在生成代码时，偶尔会输出格式混乱的代码——缩进不一致、括号不匹配、甚至混入了 Markdown 标记。

根因：Prompt 中多种格式要求互相冲突

Prompt 中的约束：
  → "请用 Markdown 格式输出"
  → "生成的文件必须符合 C# 编译规范"
  → "在代码块中标注修改位置"

冲突：
  前两条互相矛盾——Markdown 格式要求代码块标记，
  但 C# 编译器不认识 Markdown 标记。

修复：拆分约束、消除冲突

优化前：
  "请用 Markdown 格式输出并生成可编译的 C# 代码"
优化后：
  "直接输出 C# 代码（不含 Markdown 代码块标记），
   在代码上方用注释说明修改位置。"

同一个问题只给一种格式要求，不要叠加互相矛盾的约束。

案例二：约束条件——"限定目录范围"和"不允许出现xxx"

现象：

场景一：让 AI 在 src/Modules/Order 目录下加一个功能，结果它跑到 src/Shared 或 src/Infrastructure 目录去改代码，破坏了模块边界。

场景二：让 AI 写一段逻辑，结果它引入了第三方库，而项目不允许新增外部依赖。

根因：没有在提示词中明确告诉 AI "不要做什么"。AI 默认会尽可能"优化"和"发挥"，但这跟你的精确需求可能有偏差。

修复：加上否定约束条件

场景一：只修改 src/Services 目录下的文件，不允许扩大到其他目录
场景二：不允许引入新的 NuGet 包，只用现有依赖实现

"不许做什么"和"要做什么"同样重要，有时前者更关键。

案例三：用提示词生成 Mermaid 架构图

这也是一个非常高频的实用场景——用自然语言描述系统结构，让 AI 输出 Mermaid 图表，省去手动画图的时间。技术图（架构图、流程图、时序图）都用 Mermaid 来画。

graph TD
    A[前端] -->|HTTP| B[API 网关]
    B --> C[用户服务]
    B --> D[订单服务]
    C --> E[(MySQL)]
    D --> E

对应的提示词极其简单：

帮我用 Mermaid 画一个系统架构图：
前端 → API 网关 → 用户服务 / 订单服务 → MySQL

一句话描述关系，AI 就能把它变成可视化的架构文档。

常见错误模式与对照

表现	常见原因	修复方法
AI 反复生成不存在的 API	项目依赖信息未提供	在提示词中提供明确的 NuGet 包和版本
AI 重复生成已有功能	项目中已有的工具函数未告知 AI	在提示词中引导 AI 先搜索代码库
AI 忽略编码规范	Rule 未生效或不够具体	检查 Rule 的 trigger 类型和优先级
AI 在前几轮表现差、后几轮好	上下文窗口不足	启用上下文压缩或拆分成多个子任务
AI 拒绝执行某个操作	安全策略过度限制	检查 settings.json 中的权限配置
AI 输出与需求不相关	提示词过于模糊	按"问题→影响范围→期望结果"结构重写

调试提示词的基本原则

1. 排除法

当 AI 输出不理想时，逐项检查：

1. 去掉所有 Rule 约束，看输出是否变好 → 如果是，说明某个 Rule 有问题
2. 去掉 Memory 上下文，看输出是否变差 → 如果是，说明 Memory 中有正确的信息但被其他信息干扰了
3. 换成更简单的任务描述，看输出是否正确 → 如果是，说明任务分解不够细

2. 分步验证

不要一次性给 AI 太多信息。分步给、分步验证：

第 1 步："读取这个文件，告诉我它的结构"
  → 验证 AI 理解了文件内容
第 2 步："基于文件结构，给出修改方案"
  → 验证 AI 的分析方向正确
第 3 步："按方案实施修改"
  → 验证执行结果符合预期

3. 记录有效提示词

好用的提示词不要只在脑子里，记下来。Growth 产品线的 114 份修改记录中有很大一部分本身就是经过验证的有效提示词。

检查表：Prompt 优化 + 纠错

• [ ] 每次输出不合格时，记录了当时的完整提示词/上下文吗？
• [ ] 是否有某个问题反复出现？（如果反复出现，说明不是偶然，是系统的提示词问题）
• [ ] 是否对比过"加某条信息"前后的 AI 输出质量差异？
• [ ] 是否把有效的提示词提取出来做成 Command 或 Skill？
• [ ] 是否有一份维护中的"提示词踩坑清单"？