同样是让 AI 帮忙，有时它会不停询问，有时它又直接改了一堆不该改的内容。我们想要的协作其实很具体：理解目标，知道边界，能自主推进，结果还能核对。

我把一组常用要求整理成了 20 个可以反复使用的场景模板。前 10 个来自需求澄清、执行控制、诊断和验收等协作环节；后 10 个补充研究、写作、会议、数据分析、选型和学习等日常任务。

使用时，先给出具体任务，再选一两个相关模板。 长期保留一份简短的通用规则，比每次把全部要求粘贴进去更容易维护。下文的组合方式是实践建议，不是已经在所有模型上验证过的效果保证。

一、先解决原有提示词里的三个问题

这组要求的方向很清楚，但有些地方需要重新划分。

第一，“自主完成普通步骤”和“计划确认后再实施”需要区分场景。 简单任务可以说明计划后直接执行；范围不明确、投入较大或后果难以恢复的任务，才适合先停下来等确认。如果同时把两条设为所有任务的默认规则，AI 很容易反复等待。

第二，“足够信心”需要变成可观察的条件。 与其要求一个难以核验的信心百分比，不如检查目标、输入、输出、约束和验收条件是否清楚。缺失信息会改变方案时才问；影响不大的细节，可以说明假设后继续。

第三，模型配置是一个专门的产品需求。 它适合单独调用，不适合放进写文章、做会议纪要等任务的全局规则。这里还要把“模型订阅接入”拆成 API Key、OAuth、订阅权益、服务端地址和计费方式，避免把不同能力混在一起。

原有 10 条可以这样保留和优化：

原有要求	优化重点	对应模板
理解目标与约束	用目标、输入、输出和验收条件判断是否需要追问	01 需求澄清
自主执行与操作确认	写清授权范围，已经明确授权的步骤不重复确认	02 自主执行
先诊断再修复	比较多个原因，用可复现证据支持根因判断	03 问题诊断
最小改动	限制无关重构，同时指出最小补丁可能遗漏的问题	04 最小改动
计划确认后实施	作为需要人工把关时主动启用的模式	05 计划审批
逐项验收	每项结论对应证据，明确尚未验证的部分	06 交付验收
假设项目已经失败	排序风险，写出预警信号和具体应对动作	07 失败预演
不迎合与独立判断	区分事实、推测和观点，不为反对而反对	08 前提审查
先找 GitHub 现成项目	比较适配度、许可证和维护成本，不只看 Star	09 开源选型
参考 pi 接入模型	先核实接入能力与订阅权限，再确定配置功能	10 模型接入

二、一套可以长期保留的通用协作规则

这段适合放进工具支持的自定义指令或项目协作说明。它规定工作方式；具体任务仍然要在每次对话里单独写清楚。

请按以下方式与我协作：

1. 先理解目标、输入、期望输出、约束和验收条件。
   缺失信息会影响方案或结果时，一次只问一个最关键的问题。
   对不影响主要结果的细节，说明假设后继续。

2. 在我已明确授权的范围内，自主完成普通执行步骤。
   复杂任务先简述计划；简单任务直接处理。
   对需要确认且尚未授权的操作，先说明对象、影响和恢复方式，
   等我明确同意后执行；已经授权的同一范围不反复确认。

3. 需要确认的操作包括删除或覆盖原始资料、安装软件、
   修改系统权限、对外发布，以及读取、传输或修改账号、
   密钥和隐私数据。确认范围以本次任务的明确约定为准。
   修改任务指定的文件，不等于可以覆盖无关内容或我的未提交改动。

4. 用完成目标所需的最小改动推进，保持现有风格。
   发现必须扩大范围时，先说明原因、影响和替代方案。

5. 独立判断，区分事实、推测和主观观点。
   对关键数字、人物、版本和结论，能核实就提供来源。
   没有工具或证据时，明确说明，不编造搜索、测试或执行结果。

6. 结束时说明完成了什么、如何验证、哪些部分未验证、
   已知限制，以及怎样撤销或恢复。

这里的“自主执行”始终受授权边界约束。例如，“帮我写一篇文章”允许生成正文，但不等于允许登录账号并公开发布；“把文章发布到指定仓库”则已经明确了这次发布的目标。若随后需要更改账号权限或删除旧内容，仍要单独说明。

提示词也不能代替真实权限控制。涉及文件写入、外部发送或生产数据的工具，还需要在工具层设置权限和审批。规则可以约束协作方式，不能保证系统绝不会越界。

三、前 10 个模板 优化原有协作要求

以下模板中的 {占位内容} 要替换成自己的信息。不需要的字段可以删除，不要让 AI 猜测一个空白字段代表什么。

01 需求澄清

使用场景： 需求还比较模糊，准备开发功能、制定方案或启动一个新项目。

建议提供： 想解决的问题、目标用户、现有条件和不能改变的约束。

我的目标是：{目标}。
现有条件：{材料、项目现状、时间与资源}。
必须遵守的约束：{约束}。

请先检查目标、输入、输出和验收条件是否清楚。
若缺失信息会改变主要方案，一次只问一个最关键的问题；
其余细节说明假设后继续。
条件明确后，简述需求、改动范围、主要风险和验证方式。
在已有授权范围内推进，需要额外确认的操作单独提出。

这比“先问我问题直到有足够信心”更容易判断什么时候应该结束澄清。

02 自主执行与授权边界

使用场景： 文件整理、代码编辑、重复处理等可交给 AI 连续完成的任务。

建议提供： 可以处理的目录、允许的操作，以及必须保留的内容。

任务：{任务}。
本次已授权范围：{对象、目录和允许的操作}。
必须保留：{原始资料、已有成果或其他限制}。

请自主完成范围内的普通步骤，不要每一步都征求确认。
遇到未授权的删除、覆盖、软件安装、系统权限修改、
对外发布或账号、密钥、隐私数据操作时，
先说明具体对象、影响和恢复方式，等我确认后再执行。
结束时列出实际变更、验证结果和恢复步骤。

确认应当针对具体动作。例如，“是否覆盖这三个文件”比“是否继续”更清楚。

03 先诊断再修复

使用场景： 报错、性能下降、数据异常，或一个问题修了多次仍然出现。

建议提供： 复现步骤、预期与实际行为、日志、版本，以及最近的变化。

问题：{现象}。
预期行为：{预期}。
复现步骤与已有证据：{步骤、日志、版本、近期变更}。

请先诊断，不要立即修改。
按可能性列出候选原因，分别说明支持和反对的证据。
优先做成本最低、能区分这些原因的验证。
得到可复现证据后，提出最小修复方案和风险，再在授权范围内实施。
用原始复现步骤验证，并检查直接相关的回归风险。
若根因仍不确定，说明不确定点，不把猜测写成结论。

“页面能打开了”只能证明某个现象消失，未必证明问题已经根治。诊断模板要求把修复和原始问题重新连接起来。

04 最小改动

使用场景： 修复已有项目、添加小功能，或需要控制审查范围的变更。

建议提供： 目标功能、允许修改的文件和项目已有约定。

目标：{目标}。
允许修改的范围：{文件、模块或功能}。

请用完成目标所需的最小改动处理，保持项目原有风格。
不做无关重构、格式化、依赖升级或接口调整。
若最小补丁不足以解决问题，说明缺口和扩大范围的理由。
修改后说明改了什么、为什么，以及相关验证结果。
不要覆盖与任务无关的内容或已有未提交改动。

最小改动不是一律追求代码行数最少。一个把问题掩盖起来的补丁，可能比多改几行正确逻辑带来更高的维护成本。

05 先审批计划再实施

使用场景： 大范围迁移、批量处理、生产变更，或你希望亲自确认方案的任务。

建议提供： 目标、影响范围、允许的停机时间和审批要求。

任务：{任务}。
本次采用先审批计划再实施的模式。

请先做必要的只读检查，然后给出简短计划：
□ 将完成什么
□ 本次不涉及什么
□ 会修改哪些对象
□ 如何验证
□ 哪些操作需要确认
□ 如何恢复

给出计划后暂停，等我明确同意再实施。
执行中若范围、风险或成本明显变化，先更新计划并重新确认。

这是一个主动启用的控制模式。没有必要为了改一句文案，也强制走完整的审批流程。

06 交付与验收

使用场景： 编码、分析、整理、迁移等任务即将结束，需要判断是否可以接手。

建议提供： 验收条件；如果已有约定，直接引用即可。

请对照这些验收条件检查结果：{验收条件}。

结束时逐项说明：
□ 已通过的条件，以及对应证据
□ 使用的验证方法、实际结果
□ 尚未验证的部分和原因
□ 已知限制及其影响
□ 撤销或恢复的具体步骤

未执行的测试不要写成通过。
只完成部分目标时，明确剩余事项，不用“基本完成”代替状态。

验证强度要与后果相称。改一段文字可以核对内容和链接；改金额计算，则需要正常值、边界值和异常输入的检查。

07 项目失败预演

使用场景： 创业、采购、上线、长期投入之前，检查计划中容易遗漏的风险。

建议提供： 目标、期限、预算、资源、外部依赖和成功标准。

项目计划：{计划}。
成功标准与资源边界：{标准、期限、预算、人员}。

假设项目到期没有达成目标，请倒推最可能的失败原因。
每项给出：失败路径、最早信号、预防措施、
采取补救动作的触发条件，以及具体补救方案。
按发生可能性、影响程度和发现难度排序，先列最重要的 5 项。
涉及概率或损失时，说明依据；没有数据就用定性判断。
区分可以控制的风险和只能准备应对的外部风险。

不要只得到“加强沟通”“提高质量”这样的建议。风险预演需要能执行的动作，例如“连续两次验收未通过时缩减范围”，具体阈值再根据项目确定。

08 前提审查与独立判断

使用场景： 判断一个观点、投资逻辑、产品方向或自己已经倾向接受的方案。

建议提供： 原始观点、依据、目标和需要做出的决定。

请审查这个判断：{判断与依据}。

先检查错误前提、逻辑跳跃、缺失信息和模糊概念。
区分事实、推测与主观偏好，核实影响结论的关键来源。
不同意就直接指出理由，并给出替代解释；
同意也说明成立条件，不为反对而反对。
提醒我可能遗漏的变量、机会成本和认知偏差。
最后说明：什么证据会让当前判断改变。

独立判断的价值在于检查证据和推理，而不是固定输出一份反对意见。

09 先找 GitHub 现成项目

使用场景： 准备自研工具、选择技术底座，或希望减少重复开发。

建议提供： 必需功能、运行环境、预算、许可证限制和数据要求。

需求：{需求}。
约束：{环境、预算、许可证、数据与维护要求}。

先在 GitHub 查找能够满足核心需求的现成项目。
优先选少量真正相关的候选，核对 README、许可证、
近期提交和与需求相关的 Issue；不要只按 Star 排名。
用表格比较功能匹配、接入成本、维护状态、依赖和缺口，
每个候选提供仓库链接与支持判断的证据。
给出直接使用、二次开发或自研的建议及理由。
这一阶段只调研；不要自动安装或运行候选项目。

“最近有提交”不等于维护质量好，“很久没更新”也不自动等于不能用。要结合项目成熟度、问题反馈和你的运行环境判断。

10 AI 模型配置与接入

使用场景： 软件需要支持多个模型服务、API Key 或订阅授权接入。

建议提供： 技术栈、部署方式、目标服务商和实际拥有的订阅类型。

我需要为 {软件与技术栈} 增加模型配置功能。
目标服务商与订阅：{服务商、套餐与预期能力}。
请参考：
https://github.com/earendil-works/pi/blob/main/packages/ai/README.md

先核实参考库的当前版本、接口和各服务商支持的认证方式。
分别说明 API Key、OAuth 和订阅权益是否适用，
不要假设网页会员自动包含通用 API 调用权限。
配置方案应覆盖服务商、模型、接口地址、认证方式、
默认模型、连接测试，以及保存、切换和移除配置。

说明凭据存储与日志脱敏方案，并列出无效凭据、
授权过期、模型不可用、限流和网络失败的验证方式。
先给出最小方案与验收条件；真实登录、授权、
凭据写入或可能产生费用的调用，按约定确认后进行。

这里值得单独解释技术边界。pi-ai 的 README 描述了统一模型接口、服务商配置和认证机制，也列出了部分 OAuth 接入方式；它可以作为实现参考，但不等于每种订阅在你的软件里都能使用。接入是否可用，需要分别核对库的支持、服务商的授权方式，以及具体产品的权限与条款。pi-ai README

例如，OpenAI 的帮助文档说明 ChatGPT 和 API 平台使用独立计费系统，API 用量与 ChatGPT 订阅分别计费。这与某些特定产品支持订阅登录是不同层面的事情。需求中应写清楚到底要接入哪种产品和接口。ChatGPT 与 API 平台计费说明

四、再补充 10 个日常高频模板

前面的模板主要控制协作过程。下面这些直接对应常见工作产物，可以和通用规则组合使用。

11 有来源的资料研究

使用场景： 查政策、研究技术、了解行业，或需要能够追溯的资料汇总。

建议提供： 研究问题、时间范围、地域和用途。

研究问题：{问题}。
范围：{时间、地域、对象和用途}。

先明确需要核实的关键问题，再优先查找一手资料。
对主要结论给出来源链接、发布或更新日期及适用范围，
区分来源事实、你的推断和仍有争议的部分。
来源冲突时说明冲突点，不用数量代替证据质量。
先给结论，再给依据和局限；无法检索时明确说明。
不要引用没有实际查到的文章、数字或人物表述。

如果问题涉及“最新”，要把查询时间和事件发生时间分开。今天搜到的旧文章，不一定能回答今天的情况。

12 按素材写文章

使用场景： 博客、说明文、方案介绍、对外邮件和演讲稿。

建议提供： 读者、目的、素材、长度，以及你认可的风格样例。

请为 {读者} 写一篇 {文章类型}，
希望读者读完能够 {理解或采取的行动}。
素材：{素材}。篇幅与风格：{要求或样例}。

先确定中心论点，再组织正文。
保留我的核心观点，补齐解释、场景和具体例子，
删除重复内容、空话和无法支持的强结论。
不要虚构我的经历、实测结果或他人引用。
缺少关键事实时标注待核实；假设案例要说明是示例。
先交付可阅读的正文，对外发布按明确的授权范围执行。

写作任务里，“更专业”往往不够具体。可以改成“面向非技术读者，先解释影响，再解释原理，保留必要术语”。

13 长文摘要与结构化提取

使用场景： 读报告、整理访谈、消化长文，或提取合同和方案里的关键信息。

建议提供： 原文，以及你最终要用摘要做什么。

材料：{原文或文件}。
我的用途：{用途}。

先用一段话概括核心结论，再提取与用途直接相关的信息。
区分作者观点、原文证据和你自己的解释，
保留关键条件、例外、数字和不确定性。
主要信息标明章节、页码或原文位置，方便回查。
材料没有说明的内容写“未提供”，不要自行补全。
最后列出下一步最值得核实的 3 个问题。

摘要不能只保留结论、删掉条件。比如原文说“在某类样本中成立”，摘要就不能变成“普遍成立”。

14 会议纪要与行动项

使用场景： 项目会议、客户讨论、需求评审或跨团队协作。

建议提供： 会议记录、参会者、已知日期和任务归属规则。

请把以下会议记录整理成纪要：{记录}。

分别整理已经决定的事项、尚未解决的问题和行动项。
行动项使用表格：任务、负责人、截止时间、依赖、完成标准。
负责人或日期未明确时写“待确认”，不要自行分配。
区分讨论中的建议与最终决定，保留关键分歧。
最后列出需要补充确认的问题。
只生成纪要，不自动发送消息或创建外部任务。

“有人提出可以下周做”不能自动变成“某人承诺下周完成”。把建议和承诺混在一起，会造成协作误差。

15 数据分析先检查口径

使用场景： 分析销售、支出、运营指标、问卷或业务报表。

建议提供： 数据、字段解释、时间范围和想回答的问题。

数据：{文件或表格}。
分析问题：{问题}。已知口径：{字段、单位、时间范围}。

先检查缺失、重复、异常值、单位、时间和分母口径。
说明清洗规则，保留原始数据，不直接覆盖。
给出回答问题所需的指标、计算方法和可核对结果。
区分相关关系与因果解释；样本或口径不足时限制结论。
关键汇总提供一小段手工核对示例。
不要把未执行的计算写成已完成分析。

增长率和转化率特别依赖分母。先确认统计对象，通常比多生成几张图更重要。

16 多方案比较与决策

使用场景： 采购、架构选择、项目排期、服务商选择或职业方向比较。

建议提供： 候选方案、目标、硬约束和可接受的代价。

需要做的决定：{决定}。
候选方案：{方案}。
硬约束与偏好：{预算、期限、能力、长期要求}。

先剔除不满足硬约束的方案，再比较其余方案。
比较效果、总成本、实施难度、可撤回性和长期依赖，
区分已知事实与估算，说明估算假设。
不要用主观打分制造精确结论；需要权重时说明来源。
给出推荐、适用条件，以及什么变化会让推荐反转。
若信息不足，建议一个能降低决策不确定性的最小验证。

“总成本”应包括接入、学习、运行、维护和退出成本，不只是价格表上的数字。

17 代码审查

使用场景： 检查 AI 生成代码、审查 PR，或在合并前发现真实缺陷。

建议提供： 差异、相关上下文、预期行为和测试情况。

请审查这些变更：{diff、PR 或文件}。
预期行为：{需求}。

优先查找正确性、回归、安全、数据损失和明显性能问题。
每个问题给出位置、触发条件、实际影响和修改建议，
区分确定缺陷与待核实风险，按严重程度排序。
不要把个人风格偏好当成缺陷，也不要自动重写代码。
没有发现明确问题时直接说明，同时写出审查范围和验证限制。
先交付审查意见，修改由后续任务明确授权。

代码审查应说明“什么输入会导致什么错误”。单说“这里可能有问题”，还不足以帮助作者判断。

18 学习与理解检查

使用场景： 学习新技术、理解一段代码，或防止自己只会复制答案。

建议提供： 当前基础、学习目标和已有困惑。

我正在学习 {主题}，已有基础是 {基础}，
希望能够 {具体能力}。

请从一个具体例子开始解释，逐步引入必要概念。
说明常见误解和适用边界，不一次堆满术语。
给我一道能检查理解的练习，先不要公布答案。
根据我的回答指出具体误区，再给针对性的提示和下一步练习。
我要求直接答案时再完整展示解法。

学习目标可以写成“能解释为什么会这样”“能排查一个错误”，比“掌握某技术”更容易检查。

19 长任务交接与上下文恢复

使用场景： 换对话、换模型、中途暂停，或让下一位协作者继续工作。

建议提供： 当前对话、项目状态和需要交接的材料。

请为当前任务生成一份可直接交给下一位协作者的交接说明。

包含目标、约束、已确认决定、完成内容、未完成内容、
修改的文件或产物位置，以及实际执行的验证与结果。
明确下一步最先做什么、哪些假设仍需核实、
哪些操作已经授权、哪些仍需确认。
保留必要的复现命令和参考链接，不复制账号、密钥或隐私内容。
把当前事实与历史方案分开，不把放弃的方案当成现状。

交接说明要记录决策和证据，而不是把整段聊天原样搬过去。下一位协作者仍应核对实际文件状态。

20 先做低成本验证

使用场景： 想做产品、开发自动化工具、改造流程，但还不知道需求是否值得投入。

建议提供： 目标用户、问题、目前的解决办法和可投入资源。

想法：{想法}。
目标用户与现有办法：{用户、问题、替代做法}。
资源上限：{时间和预算}。

先找出最影响成败、目前又缺少证据的假设。
设计一个低成本验证，说明对象、步骤、观测指标、
继续或停止的条件，以及可能的偏差。
优先考虑访谈、人工模拟、小样本试用等办法，
不要默认先做完整软件。
阈值要根据目标和成本解释，不能随意给出成功率。
最后说明：验证通过以后，第一版最小范围是什么。

能够实现一个功能，和有人愿意持续使用它，是两件需要分别验证的事。

五、实际使用时怎样组合

先选当前最主要的问题，再补一个控制方式，通常就能开始。

当前任务	优先使用	必要时补充
想法还不清楚	01 需求澄清	20 低成本验证
项目持续报错	03 问题诊断	04 最小改动、06 验收
准备做一个工具	09 开源选型	01 澄清、07 失败预演
批量修改或迁移	05 计划审批	02 授权边界、06 验收
写文章或方案	12 按素材写作	11 资料研究、08 前提审查
看报告做决定	13 摘要提取	16 方案比较
处理业务报表	15 数据分析	06 验收
完成开发准备合并	17 代码审查	06 验收
中断后继续工作	19 上下文交接	01 澄清剩余问题
学习一个新知识	18 理解检查	11 资料研究

具体任务本身可以用下面这个骨架：

任务：{希望完成什么}
背景：{为什么做、当前处于什么状态}
输入：{提供了哪些材料}
产物：{希望得到的文件、内容或结果}
约束：{时间、范围、风格、预算、不能改变的内容}
授权：{允许直接执行的操作、必须先确认的操作}
验收：{怎样才算完成}
采用的协作模板：{一个或两个模板名称}

例如，排查账单导入错误时，可以这样写：

任务：排查导入 CSV 后退款被计入支出的问题。
输入：导入代码、报错记录和一份虚构的小样本账单。
产物：能正确区分支出与退款的最小修复。
约束：不改变其他导入格式，不覆盖原始账单。
授权：可修改导入模块和相关测试；不操作真实账户。
验收：小样本汇总符合人工结果，正常支出仍能正确导入。
采用模板：03 问题诊断、04 最小改动。
结束时按 06 交付验收说明结果。

如果只是修改文案，就不必再添加诊断、开源选型和失败预演。规则要服务当前任务，避免让一个小任务背上整套项目流程。

六、怎样判断提示词是否需要继续优化

不要只看 AI 的回答是不是“像专业人士”。更值得检查的是：

• 产物是否对题。 输出的内容和格式是否符合目标，有没有扩大范围。
• 过程是否越界。 是否做了没有授权的修改、发送或发布。
• 结论是否有证据。 来源能否支持结论，测试是否真的执行。
• 不确定性是否保留。 不知道的部分有没有被包装成确定答案。
• 下一步是否可接手。 文件、命令、决定和剩余事项是否清楚。

可以保留几项自己经常遇到的任务，在修改提示词前后对照检查。记录具体失败，例如“漏掉原文的限制条件”“没有保留原始数据”，再修改对应规则，避免只凭一次回答变长或变漂亮就判断它更有效。

OpenAI 的提示工程指南也强调明确指令、提供相关上下文和示例，以及对输出进行验证。本文的模板是在这些一般做法上，为具体协作场景补充目标、授权和验收要求，不是厂商提供的统一标准。OpenAI 提示工程指南

对我来说，一份值得长期保留的提示词，应该帮助我们更清楚地表达：要完成什么，允许怎样做，用什么证据判断做对了。 模板可以复用，任务的真实背景和验收标准仍然需要自己补上。