文章目录开篇本文不会讨论什么一、为什么一句话 Prompt 容易产生返工二、一条高质量编程 Prompt 的基本原则1. 先给事实再给要求2. 先要方案再要完整代码3. 明确什么需要 AI 回答什么需要人工决定三、一条高质量编程 Prompt包含这 5 个要素1. 任务目标这次到底要解决什么2. 项目上下文这段代码要放在哪里3. 业务规则和约束哪些事情不能自行猜测4. 输入、输出和验收标准什么才算完成5. 交付格式希望 AI 用什么方式回答四、一个完整示例把“取消订单接口”问清楚五、把 Prompt 变成你的工程资产六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇不少开发者把 AI 编程效果不好归结为“自己不会写 Prompt”。于是开始寻找万能编程 Prompt。高级角色设定。超长提示词模板。让 AI 一次生成完整项目的咒语。但在真实开发中AI 输出不可靠通常不是因为少了一句“你是一名资深工程师”。更常见的原因是任务目标没有说清楚。项目上下文没有提供。业务规则仍然存在歧义。验收标准没有定义。输出格式不方便审查和验证。如果 Prompt 只是一句帮我写一个取消订单接口。AI 当然可以写出代码。但它不知道你的订单状态有哪些、谁可以取消、取消后如何处理库存、异常应该怎样返回、代码应该放在哪个模块。所以高质量编程 Prompt 的重点不是“写得多”而是用最少但足够的信息让 AI 知道要解决什么、在什么环境中解决、哪些事情不能擅自假设以及结果如何验收。本文不推荐万能 Prompt也不比较不同模型。我们只解决一个问题一条能够进入真实研发流程的编程 Prompt到底应该包含什么本文不会讨论什么为了避免把 Prompt 变成新的焦虑来源先明确几件事不会要求你为每次提问都写几百行背景。不会认为角色设定比项目事实更重要。不会把 AI 的第一版输出当作最终答案。不会鼓励把敏感代码、密钥、生产数据直接粘贴到对话中。不会让 Prompt 代替需求澄清、代码审查和测试验证。Prompt 的作用是降低沟通成本不是跳过工程流程。一、为什么一句话 Prompt 容易产生返工先看一个常见请求帮我用 Java 写一个取消订单接口。这句话的问题不在于太短而在于关键决策全部缺失。AI 需要自行猜测使用什么 Web 框架订单有哪些状态哪些角色可以取消订单已支付订单是否可以取消是否需要恢复库存是否需要记录取消原因是否使用事务异常如何处理它最终给出的只能是一种“通用假设下的答案”。而真实项目需要的是“符合当前系统约束的答案”。可以把 Prompt 质量理解为下面这个公式Prompt 质量 明确任务 足够上下文 已确认规则 可验证标准 可审查交付方式其中任何一项缺失AI 都会用自己的默认假设补齐。默认假设越多返工概率通常越高。二、一条高质量编程 Prompt 的基本原则在介绍具体模板前先记住三个原则。1. 先给事实再给要求先说明已知的项目事实再说明想让 AI 完成什么。不要只说“实现取消订单”而要说明项目技术栈、现有状态、相关模块和已经确认的业务规则。2. 先要方案再要完整代码对涉及状态流转、数据库、权限、金额、并发和跨模块修改的任务第一轮不要直接要代码。先让 AI 复述问题、列假设、给方案、标风险。等关键决策确认后再让 AI 生成最小实现。3. 明确什么需要 AI 回答什么需要人工决定对于不完整的信息不要让 AI 悄悄补全。应该明确要求它区分已确认事实 ↓ 可以给出实现建议的部分 ↓ 必须由产品、业务或开发者确认的假设这样AI 的回答会更接近一份可讨论的方案而不是一个看似完整、实际建立在猜测上的答案。三、一条高质量编程 Prompt包含这 5 个要素1. 任务目标这次到底要解决什么任务目标要足够具体最好包含修改或实现的功能。影响的模块或范围。本次明确不处理的内容。例如任务目标 在订单模块中新增用户取消待支付订单的能力。 范围 只处理 PENDING_PAYMENT 状态的订单。 本次不处理 已支付订单退款、库存恢复和优惠券返还。相比“写一个取消订单接口”这段描述已经明确了功能边界。常见误区把目标写成“优化一下”“重构一下”“帮我完善一下”。这类表述没有说明成功是什么样AI 只能按自己的理解扩大或缩小修改范围。2. 项目上下文这段代码要放在哪里项目上下文不是把整个仓库复制给 AI。它是提供完成本次任务所必需的最小事实。一般至少包含上下文类型示例技术栈Java Spring Boot JPA模块位置order模块业务逻辑放在 Service相关代码OrderService、订单状态枚举、现有异常类现有规范统一使用领域异常Controller 不写业务逻辑验证方式单测命令、接口测试方式、静态检查要求例如项目上下文 - 后端使用 Java Spring Boot。 - Controller 负责参数接收业务逻辑位于 Service。 - 数据访问通过 OrderRepository。 - 业务错误统一抛出 DomainException。 - 当前订单状态定义在 OrderStatus 枚举中。 - 修改后需要补充 Service 层单元测试。上下文越贴近当前任务AI 的方案越容易适配项目。3. 业务规则和约束哪些事情不能自行猜测这部分决定了 AI 生成内容是否会偏离业务。需要把已经确认的规则写成可检查的条目已确认规则 1. 只有订单所属用户可以取消订单。 2. 只有 PENDING_PAYMENT 状态允许用户取消。 3. 取消后订单状态改为 CANCELLED。 4. 请求必须携带取消原因原因长度为 1 到 200 个字符。 5. 同一订单的并发取消请求只能有一个成功。同时也要写出限制条件实现约束 - 不新增第三方依赖。 - 不修改数据库表结构。 - 不修改其他订单状态的处理逻辑。 - 不输出或记录用户隐私字段。对于仍未确认的地方可以直接要求 AI 标注如果遇到未提供的业务规则请不要自行假设。 请列为“需要人工确认”的问题。这句话往往比增加一大段角色设定更有价值。4. 输入、输出和验收标准什么才算完成没有验收标准AI 无法判断自己的输出是否真的解决了问题。可以明确四类内容输入参数和类型。成功时的结果。失败时的错误类型。必须覆盖的测试场景。例如接口约定 - 输入orderId、currentUserId、cancelReason。 - 成功返回更新后的订单状态。 - 失败订单不存在、无权限、状态不允许取消时抛出领域异常。 验收标准 1. 待支付订单可以被订单所属用户取消。 2. 非订单所属用户取消时失败。 3. 已支付订单取消时失败。 4. 取消原因为空时失败。 5. 并发重复取消不会产生错误状态。验收标准最好是开发者能够实际验证的而不是“代码优雅”“性能更好”这样的抽象描述。5. 交付格式希望 AI 用什么方式回答同一个问题如果交付格式不同答案的可用性会差很多。对于复杂任务可以先要求 AI 输出方案本轮暂时不要写完整代码。 请按以下格式输出 1. 复述你理解的任务。 2. 列出需要人工确认的假设。 3. 给出涉及的类和方法。 4. 说明状态校验、事务和并发处理方案。 5. 列出测试矩阵。 6. 标出可能影响现有功能的风险。规则确认后再进入实现轮现在请只实现 Service 层的取消订单方法。 要求 1. 不修改 Controller 和 Repository 接口。 2. 使用现有 DomainException。 3. 先说明改动点再给出代码。 4. 最后补充对应单元测试。 5. 明确标出无法从上下文确定的部分。交付格式的本质是把 AI 的输出变成你容易审查、容易验证的结构。四、一个完整示例把“取消订单接口”问清楚下面把前面的 5 个要素合并成一条可直接使用的 Prompt。任务目标 在订单模块中新增“用户取消待支付订单”的能力。 本次只处理待支付订单不处理退款、库存恢复和优惠券返还。 项目上下文 - 后端使用 Java Spring Boot。 - Controller 只负责参数接收和响应业务逻辑位于 OrderService。 - 数据访问通过 OrderRepository。 - 订单状态位于 OrderStatus 枚举。 - 业务错误统一使用 DomainException。 - 已有 OrderServiceTest可以在其中补充单元测试。 已确认规则 1. 只有订单所属用户可以取消订单。 2. 只有 PENDING_PAYMENT 状态允许取消。 3. 取消后状态必须更新为 CANCELLED。 4. cancelReason 必填长度为 1 到 200 个字符。 5. 同一订单的并发取消只允许一个请求成功。 输入、输出和验收 - 输入orderId、currentUserId、cancelReason。 - 成功返回取消后的订单信息。 - 失败订单不存在、无权限、状态不允许取消或参数非法时抛出领域异常。 - 必须覆盖正常取消、无权限、订单不存在、已支付订单、空取消原因、重复取消。 本轮交付要求 1. 先不要写完整代码。 2. 复述任务理解并列出还需要人工确认的假设。 3. 说明 Service 层的处理步骤、事务和并发风险。 4. 列出建议修改的类和方法。 5. 输出测试矩阵。注意这不是“万能 Prompt”。它只是把一个真实开发任务中最重要的信息显式写出来。针对不同场景你需要替换其中的业务规则、项目上下文和验收标准。如果 AI 在第一轮回答中提出合理的待确认问题再补充信息进入第二轮通常比一次要求它输出完整代码更稳妥。五、把 Prompt 变成你的工程资产高质量 Prompt 不应该只存在于某一次聊天记录里。建议按任务类型保存模板而不是按工具保存模板模板类型适用场景需求澄清模板需求模糊、规则不完整、需要拆任务代码阅读模板接手陌生模块、追调用链、确认影响范围方案设计模板多种实现方案、状态流转、跨模块修改代码审查模板检查异常、边界、安全、性能和可维护性测试矩阵模板正常、边界、异常和回归场景排障模板整理现象、日志、假设和验证步骤你可以从下面这份最小模板开始任务目标 [要实现、修改、审查或排查什么] 当前阶段 [需求澄清 / 代码阅读 / 方案设计 / 实现 / 测试 / 排障] 项目上下文 [技术栈、相关模块、现有代码和规范] 已确认规则 [业务规则、状态、权限、数据约束] 输入与验收 [输入、预期输出、异常、测试场景] 实现约束 [修改范围、依赖限制、安全要求、兼容性要求] 本轮交付要求 [先给方案 / 只改某个方法 / 输出测试矩阵 / 标出假设]每次任务结束后再补充两类信息本次有效 [哪些背景信息、要求和输出格式最有帮助] 本次不足 [AI 漏掉了什么哪些规则仍然需要更早说明]经过几次迭代后你会得到一套符合自己项目和团队规范的 Prompt 库。这比收藏几十条“万能提示词”更有长期价值。六、总结一条高质量编程 Prompt不需要写得华丽也不需要堆很多角色设定。它至少要回答 5 个问题要做什么明确任务目标和范围。在哪里做提供必要的项目上下文。哪些不能猜写清业务规则和实现约束。怎样算完成定义输入、输出和验收标准。怎样交付规定方案、代码、测试和风险的输出格式。当这 5 个要素足够清楚时AI 的输出会更容易进入审查和验证流程。请记住好 Prompt 不是一次问出最终答案而是让每一轮协作都减少不必要的猜测。下一篇文章我们用一个真实场景实践这套方法用 AI 拆一个真实需求从模糊描述到开发任务清单。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言你现在最常让 AI 帮你完成哪一类任务✍坚持原创求关注点赞收藏 一条高质量编程 Prompt，应该包含什么？
文章目录开篇本文不会讨论什么一、为什么一句话 Prompt 容易产生返工二、一条高质量编程 Prompt 的基本原则1. 先给事实再给要求2. 先要方案再要完整代码3. 明确什么需要 AI 回答什么需要人工决定三、一条高质量编程 Prompt包含这 5 个要素1. 任务目标这次到底要解决什么2. 项目上下文这段代码要放在哪里3. 业务规则和约束哪些事情不能自行猜测4. 输入、输出和验收标准什么才算完成5. 交付格式希望 AI 用什么方式回答四、一个完整示例把“取消订单接口”问清楚五、把 Prompt 变成你的工程资产六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇不少开发者把 AI 编程效果不好归结为“自己不会写 Prompt”。于是开始寻找万能编程 Prompt。高级角色设定。超长提示词模板。让 AI 一次生成完整项目的咒语。但在真实开发中AI 输出不可靠通常不是因为少了一句“你是一名资深工程师”。更常见的原因是任务目标没有说清楚。项目上下文没有提供。业务规则仍然存在歧义。验收标准没有定义。输出格式不方便审查和验证。如果 Prompt 只是一句帮我写一个取消订单接口。AI 当然可以写出代码。但它不知道你的订单状态有哪些、谁可以取消、取消后如何处理库存、异常应该怎样返回、代码应该放在哪个模块。所以高质量编程 Prompt 的重点不是“写得多”而是用最少但足够的信息让 AI 知道要解决什么、在什么环境中解决、哪些事情不能擅自假设以及结果如何验收。本文不推荐万能 Prompt也不比较不同模型。我们只解决一个问题一条能够进入真实研发流程的编程 Prompt到底应该包含什么本文不会讨论什么为了避免把 Prompt 变成新的焦虑来源先明确几件事不会要求你为每次提问都写几百行背景。不会认为角色设定比项目事实更重要。不会把 AI 的第一版输出当作最终答案。不会鼓励把敏感代码、密钥、生产数据直接粘贴到对话中。不会让 Prompt 代替需求澄清、代码审查和测试验证。Prompt 的作用是降低沟通成本不是跳过工程流程。一、为什么一句话 Prompt 容易产生返工先看一个常见请求帮我用 Java 写一个取消订单接口。这句话的问题不在于太短而在于关键决策全部缺失。AI 需要自行猜测使用什么 Web 框架订单有哪些状态哪些角色可以取消订单已支付订单是否可以取消是否需要恢复库存是否需要记录取消原因是否使用事务异常如何处理它最终给出的只能是一种“通用假设下的答案”。而真实项目需要的是“符合当前系统约束的答案”。可以把 Prompt 质量理解为下面这个公式Prompt 质量 明确任务 足够上下文 已确认规则 可验证标准 可审查交付方式其中任何一项缺失AI 都会用自己的默认假设补齐。默认假设越多返工概率通常越高。二、一条高质量编程 Prompt 的基本原则在介绍具体模板前先记住三个原则。1. 先给事实再给要求先说明已知的项目事实再说明想让 AI 完成什么。不要只说“实现取消订单”而要说明项目技术栈、现有状态、相关模块和已经确认的业务规则。2. 先要方案再要完整代码对涉及状态流转、数据库、权限、金额、并发和跨模块修改的任务第一轮不要直接要代码。先让 AI 复述问题、列假设、给方案、标风险。等关键决策确认后再让 AI 生成最小实现。3. 明确什么需要 AI 回答什么需要人工决定对于不完整的信息不要让 AI 悄悄补全。应该明确要求它区分已确认事实 ↓ 可以给出实现建议的部分 ↓ 必须由产品、业务或开发者确认的假设这样AI 的回答会更接近一份可讨论的方案而不是一个看似完整、实际建立在猜测上的答案。三、一条高质量编程 Prompt包含这 5 个要素1. 任务目标这次到底要解决什么任务目标要足够具体最好包含修改或实现的功能。影响的模块或范围。本次明确不处理的内容。例如任务目标 在订单模块中新增用户取消待支付订单的能力。 范围 只处理 PENDING_PAYMENT 状态的订单。 本次不处理 已支付订单退款、库存恢复和优惠券返还。相比“写一个取消订单接口”这段描述已经明确了功能边界。常见误区把目标写成“优化一下”“重构一下”“帮我完善一下”。这类表述没有说明成功是什么样AI 只能按自己的理解扩大或缩小修改范围。2. 项目上下文这段代码要放在哪里项目上下文不是把整个仓库复制给 AI。它是提供完成本次任务所必需的最小事实。一般至少包含上下文类型示例技术栈Java Spring Boot JPA模块位置order模块业务逻辑放在 Service相关代码OrderService、订单状态枚举、现有异常类现有规范统一使用领域异常Controller 不写业务逻辑验证方式单测命令、接口测试方式、静态检查要求例如项目上下文 - 后端使用 Java Spring Boot。 - Controller 负责参数接收业务逻辑位于 Service。 - 数据访问通过 OrderRepository。 - 业务错误统一抛出 DomainException。 - 当前订单状态定义在 OrderStatus 枚举中。 - 修改后需要补充 Service 层单元测试。上下文越贴近当前任务AI 的方案越容易适配项目。3. 业务规则和约束哪些事情不能自行猜测这部分决定了 AI 生成内容是否会偏离业务。需要把已经确认的规则写成可检查的条目已确认规则 1. 只有订单所属用户可以取消订单。 2. 只有 PENDING_PAYMENT 状态允许用户取消。 3. 取消后订单状态改为 CANCELLED。 4. 请求必须携带取消原因原因长度为 1 到 200 个字符。 5. 同一订单的并发取消请求只能有一个成功。同时也要写出限制条件实现约束 - 不新增第三方依赖。 - 不修改数据库表结构。 - 不修改其他订单状态的处理逻辑。 - 不输出或记录用户隐私字段。对于仍未确认的地方可以直接要求 AI 标注如果遇到未提供的业务规则请不要自行假设。 请列为“需要人工确认”的问题。这句话往往比增加一大段角色设定更有价值。4. 输入、输出和验收标准什么才算完成没有验收标准AI 无法判断自己的输出是否真的解决了问题。可以明确四类内容输入参数和类型。成功时的结果。失败时的错误类型。必须覆盖的测试场景。例如接口约定 - 输入orderId、currentUserId、cancelReason。 - 成功返回更新后的订单状态。 - 失败订单不存在、无权限、状态不允许取消时抛出领域异常。 验收标准 1. 待支付订单可以被订单所属用户取消。 2. 非订单所属用户取消时失败。 3. 已支付订单取消时失败。 4. 取消原因为空时失败。 5. 并发重复取消不会产生错误状态。验收标准最好是开发者能够实际验证的而不是“代码优雅”“性能更好”这样的抽象描述。5. 交付格式希望 AI 用什么方式回答同一个问题如果交付格式不同答案的可用性会差很多。对于复杂任务可以先要求 AI 输出方案本轮暂时不要写完整代码。 请按以下格式输出 1. 复述你理解的任务。 2. 列出需要人工确认的假设。 3. 给出涉及的类和方法。 4. 说明状态校验、事务和并发处理方案。 5. 列出测试矩阵。 6. 标出可能影响现有功能的风险。规则确认后再进入实现轮现在请只实现 Service 层的取消订单方法。 要求 1. 不修改 Controller 和 Repository 接口。 2. 使用现有 DomainException。 3. 先说明改动点再给出代码。 4. 最后补充对应单元测试。 5. 明确标出无法从上下文确定的部分。交付格式的本质是把 AI 的输出变成你容易审查、容易验证的结构。四、一个完整示例把“取消订单接口”问清楚下面把前面的 5 个要素合并成一条可直接使用的 Prompt。任务目标 在订单模块中新增“用户取消待支付订单”的能力。 本次只处理待支付订单不处理退款、库存恢复和优惠券返还。 项目上下文 - 后端使用 Java Spring Boot。 - Controller 只负责参数接收和响应业务逻辑位于 OrderService。 - 数据访问通过 OrderRepository。 - 订单状态位于 OrderStatus 枚举。 - 业务错误统一使用 DomainException。 - 已有 OrderServiceTest可以在其中补充单元测试。 已确认规则 1. 只有订单所属用户可以取消订单。 2. 只有 PENDING_PAYMENT 状态允许取消。 3. 取消后状态必须更新为 CANCELLED。 4. cancelReason 必填长度为 1 到 200 个字符。 5. 同一订单的并发取消只允许一个请求成功。 输入、输出和验收 - 输入orderId、currentUserId、cancelReason。 - 成功返回取消后的订单信息。 - 失败订单不存在、无权限、状态不允许取消或参数非法时抛出领域异常。 - 必须覆盖正常取消、无权限、订单不存在、已支付订单、空取消原因、重复取消。 本轮交付要求 1. 先不要写完整代码。 2. 复述任务理解并列出还需要人工确认的假设。 3. 说明 Service 层的处理步骤、事务和并发风险。 4. 列出建议修改的类和方法。 5. 输出测试矩阵。注意这不是“万能 Prompt”。它只是把一个真实开发任务中最重要的信息显式写出来。针对不同场景你需要替换其中的业务规则、项目上下文和验收标准。如果 AI 在第一轮回答中提出合理的待确认问题再补充信息进入第二轮通常比一次要求它输出完整代码更稳妥。五、把 Prompt 变成你的工程资产高质量 Prompt 不应该只存在于某一次聊天记录里。建议按任务类型保存模板而不是按工具保存模板模板类型适用场景需求澄清模板需求模糊、规则不完整、需要拆任务代码阅读模板接手陌生模块、追调用链、确认影响范围方案设计模板多种实现方案、状态流转、跨模块修改代码审查模板检查异常、边界、安全、性能和可维护性测试矩阵模板正常、边界、异常和回归场景排障模板整理现象、日志、假设和验证步骤你可以从下面这份最小模板开始任务目标 [要实现、修改、审查或排查什么] 当前阶段 [需求澄清 / 代码阅读 / 方案设计 / 实现 / 测试 / 排障] 项目上下文 [技术栈、相关模块、现有代码和规范] 已确认规则 [业务规则、状态、权限、数据约束] 输入与验收 [输入、预期输出、异常、测试场景] 实现约束 [修改范围、依赖限制、安全要求、兼容性要求] 本轮交付要求 [先给方案 / 只改某个方法 / 输出测试矩阵 / 标出假设]每次任务结束后再补充两类信息本次有效 [哪些背景信息、要求和输出格式最有帮助] 本次不足 [AI 漏掉了什么哪些规则仍然需要更早说明]经过几次迭代后你会得到一套符合自己项目和团队规范的 Prompt 库。这比收藏几十条“万能提示词”更有长期价值。六、总结一条高质量编程 Prompt不需要写得华丽也不需要堆很多角色设定。它至少要回答 5 个问题要做什么明确任务目标和范围。在哪里做提供必要的项目上下文。哪些不能猜写清业务规则和实现约束。怎样算完成定义输入、输出和验收标准。怎样交付规定方案、代码、测试和风险的输出格式。当这 5 个要素足够清楚时AI 的输出会更容易进入审查和验证流程。请记住好 Prompt 不是一次问出最终答案而是让每一轮协作都减少不必要的猜测。下一篇文章我们用一个真实场景实践这套方法用 AI 拆一个真实需求从模糊描述到开发任务清单。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言你现在最常让 AI 帮你完成哪一类任务✍坚持原创求关注点赞收藏