专栏：AI 编程提效实战 30 讲
标签：AI提示词 / AI编程 / 效率提升 / 工作流

先说结论

很多程序员并不是不会用 AI，而是每次都在“临场发挥”写提示词。

同样是让 AI 帮你读项目、拆需求、补测试、做 Review，有的人一次就能拿到可用结果，有的人要来回改 5 轮。差距往往不在工具，而在提示词有没有固定结构。

我的建议很直接：不要追求“灵感型提问”，先把高频场景固化成 5 个可复用结构。这样做的好处有两个：

• 输出更稳定，返工更少

• 可以团队复用，而不是只靠个人感觉

上图可以先收藏。真正能提效的，不是某一句神奇提示词，而是一套能反复套用的结构。

为什么程序员需要固定提示词结构

你可能也遇到过这几种情况：

• 同样一个问题，这次 AI 回答得不错，下次却跑偏

• 让 AI 写代码时，它总会自己补一堆你没要求的假设

• 让 AI 做 Review 时，它只会泛泛地说“建议优化”

• 你明明知道问题是什么，但很难把任务描述得足够清楚

这些问题背后，其实都是同一个原因：输入不稳定，输出就不可能稳定。

提示词结构的作用，不是把语言写得更花，而是确保你每次都把最关键的 4 类信息交代清楚：

1. 它现在扮演什么角色

2. 当前任务到底是什么

3. 有哪些上下文和约束

4. 你希望它按什么格式输出

只要这四类信息说清楚，结果通常就会比“帮我看一下”“帮我写一下”强很多。

结构 1：角色 + 目标 + 约束

这是最通用、最值得先固化的结构，适合几乎所有工程任务。

适用场景

• 新需求拆解

• 写局部代码

• 生成脚本

• 设计改动方案

结构模板

你现在是我的 {角色}。
当前任务：{目标}
已知背景：{项目背景/技术栈/已有能力}
必须满足：
1. {约束 1}
2. {约束 2}
3. {约束 3}
输出要求：{你要它怎么返回}

示例

你现在是我的后端开发协作助手。
当前任务：为订单系统补充“取消原因记录”能力。
已知背景：项目基于 Spring Boot + MySQL，订单状态流转逻辑已在线上稳定运行。
必须满足：
1. 不改现有接口入参
2. 尽量复用现有状态流转逻辑
3. 数据库允许新增字段，但不要新建独立大表
输出要求：先给出实现思路、影响模块和风险点，不要直接生成完整代码。

为什么有效

因为它先把“任务边界”框住了。AI 最怕的是目标大、约束少；这个结构最适合拿来做“先定边界，再出方案”。

如果你总觉得 AI 输出飘，这张对比图可以直接拿来做自查：是不是只给了任务，没有给边界和输出格式。

结构 2：上下文 + 输入材料 + 分析任务

这个结构专门用来“先看懂，再动手”。如果你经常要读陌生项目、读日志、读一段复杂代码，这个结构非常稳。

适用场景

• 读项目目录

• 分析代码逻辑

• 看报错日志

• 理解接口调用链

结构模板

我会给你 {材料类型}。
请先基于这些内容完成 {分析任务}。
分析时重点关注：
1. {关注点 1}
2. {关注点 2}
3. {关注点 3}
输出格式：
1. 先总结
2. 再列关键发现
3. 最后给风险或疑问

示例

我会给你一个陌生项目的 controller、service 和 repository 目录结构。
请先基于这些内容分析这个项目的主要业务分层和订单链路。
分析时重点关注：
1. 核心入口在哪里
2. 状态流转逻辑在哪一层处理
3. 哪些模块可能和订单取消相关
输出格式：
1. 先用 3 句话总结
2. 再列关键模块
3. 最后列我后续需要补充确认的问题

为什么有效

很多人一上来就让 AI 生成代码，实际上顺序错了。先理解上下文，后处理任务，才更像真实开发流程。

你可以把这张图理解成“用法路由表”：遇到读项目、拆需求、做对比、写局部代码、自查质量时，直接对应到合适结构。

结构 3：方案对比 + 决策依据

这个结构适合需求不清、方案不止一种的时候。它能逼 AI 给出更有判断价值的内容，而不是只丢一个“推荐方案”。

适用场景

• 技术选型

• 重构方案比较

• 接口设计取舍

• 数据模型改动评估

结构模板

请基于以下背景，对 {方案 A} 和 {方案 B} 做对比。
对比维度至少包括：
1. 实现复杂度
2. 改动范围
3. 风险点
4. 可维护性
5. 适用前提
最后给出推荐方案，并说明推荐依据。

示例

请基于一个已有两年历史的后端项目，对“在订单表新增字段记录取消原因”和“单独新增取消记录表”做对比。
对比维度至少包括：
1. 实现复杂度
2. 改动范围
3. 历史数据兼容
4. 查询成本
5. 后续扩展性
最后给出推荐方案，并说明什么前提下应该选另一个方案。

为什么有效

程序员真正需要的，不只是答案，而是判断依据。这个结构能让 AI 的输出更接近“可用于决策的草案”。

结构 4：局部实现 + 输出边界

这个结构适合真正开始写代码时使用。重点不是“让 AI 多写”，而是“只让它写你已经确认过的一小块”。

适用场景

• 生成局部方法

• 补测试用例

• 写 SQL 草案

• 补脚本

结构模板

现在只处理 {局部模块}。
目标：{具体目标}
不要做：
1. {不要做的事 1}
2. {不要做的事 2}
请输出：
1. 需要新增或修改的点
2. 伪代码或代码草案
3. 关键注意事项

示例

现在只处理 Service 层的订单取消逻辑。
目标：在保持原有状态流转逻辑的前提下，补充取消原因记录。
不要做：
1. 不要改 Controller 入参
2. 不要生成完整项目代码
请输出：
1. 需要新增或修改的方法
2. 每个方法的职责
3. 一段最小侵入式伪代码
4. 关键边界条件

为什么有效

只写局部，意味着更容易评估、也更容易直接落地。多文件、大范围生成最容易失控，而这个结构正好反过来收缩范围。

结构 5：验收标准 + 自查清单

这是最容易被忽略、但最能减少返工的结构。很多人会让 AI 生成内容，却不要求它“按什么标准自查”，结果就只能靠自己兜底。

适用场景

• 代码生成前的约束校验

• 提交前 Review

• 测试补全

• 文档或 SQL 自查

结构模板

请基于以下验收标准完成 {任务}：
1. {标准 1}
2. {标准 2}
3. {标准 3}
输出后，再按同样标准自查一次，并列出：
- 已满足项
- 不确定项
- 需要我确认的地方

示例

请基于以下验收标准生成 Java 代码草案：
1. 保持原有方法签名不变
2. 尽量少改已有逻辑
3. 异常路径需要能补单测
4. 如果有不确定的地方，不要自行假设
输出后，再按同样标准自查一次，并列出：
- 已满足项
- 仍有风险的点
- 需要我补充的信息

为什么有效

它会把 AI 从“直接给结果”拉回到“结果 + 检查”。很多质量问题，靠这一步就能提前暴露。

正式发给 AI 之前，按这 5 项过一遍，能明显减少“回答得像样但不能落地”的情况。

这 5 个结构怎么搭成自己的工作流

如果你只收藏模板，不放进流程里，还是很难稳定提效。更实用的做法是把它们按开发顺序串起来：

1. 先用“上下文 + 输入材料 + 分析任务”读懂项目

2. 再用“角色 + 目标 + 约束”拆需求

3. 遇到分歧时，用“方案对比 + 决策依据”做判断

4. 真正写代码时，用“局部实现 + 输出边界”控制范围

5. 提交前，用“验收标准 + 自查清单”补最后一道保险

这套顺序本质上是在解决三个问题：

• 先理解，再生成

• 先定边界，再动手

• 先定义标准，再验收

我自己的使用建议

如果你最近就想把提示词质量提上来，建议先做这 4 件事：

1. 只固化高频场景

不要试图一次写 20 个模板。先抓最常用的 3 到 5 个场景，比如读项目、拆需求、写局部代码、做 Review。

2. 模板要留空位

真正好用的模板，一定是“半固定、半变量”。角色、目标、约束、输出格式固定，具体业务内容按场景替换。

3. 每次复盘哪一句最有价值

提示词优化不靠玄学，靠复盘。看哪些约束一加上去，结果立刻稳定；哪些描述太空，AI 总跑偏。

4. 让模板进入团队协作

如果一个模板只有你自己知道，它的收益是线性的；如果团队共用，它的收益会放大。

写在最后

程序员高质量提示词，不是“更会说话”，而是“更会定义任务边界”。

你不需要每次都写出一段华丽提示词，只需要把高频任务固化成几个稳定结构。这样 AI 才更像一个可控的工程协作助手，而不是一台随机回答机器。

下一讲我会继续写：用 AI 快速读懂陌生项目的标准流程。如果你经常接手老项目，这一讲会更实用。

---

如果你也在搭自己的 AI 开发工作流，欢迎关注专栏《AI 编程提效实战 30 讲》。