AI专题分享(二):我复盘了自己的AI对话,哪些提示词值得留下?

上一篇文章《AI专题分享（一）：我踩过的几个坑和一些使用建议》，我总结了这段时间使用AI遇到的问题，以及如何通过明确目标、管理任务、建立Skill和增加验收来减少返工。

文章发出后，有读者想了解怎样把重复工作整理成Skill，有人希望让AI参与完整的研究报告，也有人已经实现周报自动生成，却发现AI仍然不太擅长解释业务问题。

这些话题都值得展开。我想先从一个具体的问题说起：实际工作中，哪些提示词值得留下，它们究竟解决了什么问题？

于是，我让Codex整理了过去几个月的本地历史对话，并回看部分案例的执行记录和交付文件。里面既有很长的工作说明，也有“继续”“你来操作”这样简短的指令。

重新看这些记录，我越来越关注三件事：哪些关键判断需要提前说清楚，AI完成工作后应该留下什么证据，以及出现问题时，是否真的应该继续修改提示词。

下文引用的历史提示词已经节选和脱敏，补充的示范写法会单独标明。案例没有经过同条件对照，不能据此计算某一句提示词带来了多少效率提升，但可以看看这些要求怎样进入实际工作，又在哪些地方仍然不够。

一、任务开始前，先说清楚会改变答案的条件

做游戏用户画像时，我经常需要结合游戏内行为、付费、内容观看和产品偏好等数据。

如果直接让AI“做一份用户画像报告”，它通常能给出一套完整框架。但框架完整，不代表研究对象和业务问题已经确定。

例如，实际进入游戏的玩家，与看过游戏相关内容的人，都可能出现在研究资料里。前者可以帮助分析体验后的行为，后者可以帮助理解内容触达和潜在人群。两类用户可以放在同一项研究中讨论，但不能混用统计对象和分母。

我曾经这样交代任务。

真实提示词节选：

你先梳理一下，你会怎么做，你会从哪些表读取数据，会分析哪些字段，需要我提供哪些信息给你。

这句话前面，还要求AI参考我已经做过的画像研究和历史对话。

当时它先回顾能够读取的资料，提出实际玩家与内容观看用户需要区分，再整理分析模块、观察周期和信息缺口。这一轮得到的是分析计划，还没有进入完整取数。

这里值得保留的做法，是先找出那些一旦理解不同，就会改变分析结果的条件。

比如，DAU按账号还是角色去重？一个账号可以创建多个角色，统计对象不同，结果就可能不同。“最近一周活跃用户”指每天的活跃趋势，还是七天内累计去重的人数？这两个问题也需要不同的计算方式。

报告是为了调整产品，还是寻找新的获客人群，同样需要先确定。这些问题不能留到图表做完之后再讨论。

在此基础上，还可以多问一步：这项分析准备帮助业务判断什么？

例如，AI建议研究某类内容观看用户，可以要求它说明已有证据、需要验证的假设，以及什么结果会影响下一步行动。对于直接支持决策的分析，如果结果高低都不会改变方案，就值得重新考虑它的优先级；对于探索性研究，则可以先说明准备减少哪一类不确定性。

这样，分析计划才会把业务问题、证据和后续判断联系起来。

不过，核对也不等于每次都向用户提问。数据字典已经写清楚的，应该先读取；历史规则仍然适用的，应该优先复用。只有现有材料无法确定、而不同解释会影响结果的地方，才需要进一步澄清。

我还发现，使用者自己的判断也需要接受核对。

例如，看到D2留存率高于D1，直觉上可能怀疑计算有误。但在以同一批用户为分母、分别统计指定日期是否回访的定义下，D2可能有D1没有回来的用户，因此D2高于D1是可能发生的。

如果直接说“这个结果错了，给我改掉”，就把尚未核实的怀疑变成了任务前提。

异常核对示范（本次整理）：

我发现【异常现象】，怀疑可能存在计算问题。请先核对指标定义、统计对象、观察周期和计算方法。

如果有误，定位原因并提出修复方案；如果没有发现计算错误，请说明已经排除了哪些问题。

对业务原因的解释，区分有证据支持的结论和仍需验证的假设，不要为了符合我的预期修改结果。

让AI有依据地提出不同意见，也应该成为任务要求的一部分。

二、执行与自检，要知道每一步留下的证据能证明什么

我做过一项游戏用户研究，希望分析用户观看某类内容作品的经历，是否与游戏内活跃、付费表现存在关联。

前面已经完成部分用户分组和标签分析。继续做交叉分析前，AI也发现了旧说明中的两个问题：一个字段不能准确代表实际观看天数，另一处活跃分层引用了不正确的字段。

讨论完方向后，我只发了一句。

真实提示词：

你先写sql，然后自检，然后输出excel结果。

AI随后表示，只执行新增模块，并在结果页写清分母、时间窗和数据来源。

执行中也遇到了问题。历史记录中，一处SQL因嵌套聚合问题被规则检查拦下，后续还遇到过字段检查失败。处理这些问题后，才继续完成查询和结果核对。

最终，历史交付记录列出了15条执行成功的新增SQL、一份包含11张工作表的Excel，以及56项通过的本地结果核验。检查涉及人数加总、分层覆盖、金额回账和关联完整性等内容，SQL、结果文件和核验记录也都保留了下来。

这条短提示词能够起作用，是因为前面的讨论已经交代了研究目标、材料和工作范围。它只需要安排下一步的执行顺序。

但这个案例更值得追问的是：这些检查通过以后，我们究竟可以相信哪些结果？

我会把检查分成四层，分别确认检查对象、依据和适用边界。

这里的分层，是我从案例中进一步整理的方法，不代表当时的56项检查已经覆盖了所有层面。

如果只是用同一套逻辑重新跑一遍，再换成“数据审计专家”说一句“结果一致”，共同的错误仍然可能留在里面。独立复核需要增加核对依据，不能只换一个角色名称。

重要指标可以采用另一种计算路径复算，或抽取原始记录人工核对。具体用哪一种，要看错误可能发生在哪里。

在解释数据时，还要分清“没有取得结果”和“结果确实为零”。请求失败、没有符合条件的记录、观察期未成熟，需要分别说明；空结果本身也不能在任何指标下都直接当成零。

如果一个问题只能回答一部分，也应该把边界说清楚。例如，用户询问“昨天各地区的汇总收入”，如果只能可靠计算总收入，可以将它作为补充结果交付，并明确地区差异尚未回答。前提是这个总值能够独立成立，不能用整体数字冒充地区结果。

自检示范（本次整理）：

请检查本轮结果，分别核对执行状态、数据一致性、业务口径和结论依据。对每项重要检查，说明检查对象、使用的依据和结果。列出已通过、未通过和尚未验证的项目。

缺失、失败和未成熟的数据不要补成零。只能完成部分要求时，交付能够独立成立的结果，并明确剩余缺口。

交付时知道哪些地方还没有验证，比得到一句范围不明的“全部检查通过”更有用。

三、让AI自主推进，也要明确它可以决定到哪一步

我不希望AI每完成一个小步骤，都来询问是否继续。任务讨论清楚以后，读取文件、按照已确认口径计算、检查结果、整理交付物，通常可以连续完成。

但自主执行到什么程度，需要看操作的影响。

在现有范围内修复一个字段引用，与改变研究对象，是不同的决定；生成一份新的对比稿，与覆盖正式报告，也需要不同的授权。

我现在更倾向于把确认环节放在这几类变化上：研究目标或业务口径改变，修改范围扩大，已有正式成果将被替换，以及需要新增原先没有授权的访问或外部操作。

范围已经明确的工作，则应尽量让AI完整做完。发现范围外的问题，可以先记录影响和处理建议，不必把所有后续工作一起停住。

这在多个AI同时参与一个项目时尤其重要。

我曾用两个Codex窗口并行开发一个产品，一边负责采集、同步和定时任务，另一边接入外部数据平台并完善页面。两边涉及部分共享文件，代码版本也已经有差异。

当时我明确提出：

真实提示词节选：

请立即执行版本隔离，但不要丢失当前工作。

我还要求检查当前状态、保存已有修改、限定各自的模块范围，并明确：

真实提示词节选：

完成后不要自行merge main。等待集成阶段。

实际检查发现，原目录并没有可以直接共用的Git历史。后来采用的是两个独立工作目录，分别保存代码快照和提交记录，再保留修改清单及共享文件的迁移说明。

这段历史能够支持的是：版本隔离和交接工作确实执行了。由于仍有一项服务级集成测试受本地端口权限限制，没有完成，不能据此宣布整个产品已经通过集成验收。

对读者来说，这个案例可以迁移到报告、数据文件和项目文档中：在修改之前，先明确保留什么、允许改什么、怎样比较，以及谁决定正式替换。

如果只是要求“不要互相覆盖”，AI还要自己决定怎样保存当前成果、怎样识别冲突。把这些要求落实成副本、修改范围和交接记录，才有后续检查的依据。

修改范围示范（本次整理）：

请在【允许范围】内完成【任务】，先保存可回溯的原始版本，保留【已经确认的内容或功能】。范围内的操作按已确认规则自主完成。

如果发现需要改变业务口径、扩大修改范围或替换正式成果，先提供具体影响和建议。交付时列出修改内容、检查结果及未解决的问题。

对于简单、可恢复的小修改，不需要照搬所有步骤。约束的多少，应当与出错后的影响和恢复成本相匹配。

四、长任务出问题时，先判断缺的是指令还是执行机制

我还做过一个游戏研究队列，希望AI从候选游戏中按优先级逐个开展研究，完成报告、归档和检查后，再处理下一项。

队列里有已经研究过的游戏、不规范的名称，也有不应该作为独立游戏项目的玩家内容。

当时的真实提示词节选：

每次只评估第一个符合条件、且还没有对应研究报告的有效游戏；如果名称不规范、不是明确游戏项目，就跳过并记录原因。

我还要求：上一款没有完成报告、归档和校验，即使到了下一次唤醒时间，也不能并发或直接跳到下一款。

后来回看其中一段历史，能够找到连续产出的三份游戏研究报告及归档文件，也有一份说明玩家内容为何被跳过的记录。执行记录里还可以看到，上一项完成检查后，才读取下一项。

但中间出现了一个很具体的问题：游戏名称里有冒号，历史报告文件名却使用下划线。最初按文件名判断时，AI差点把已经有报告的游戏重新加入队列，后来补充名称规范化检查，才避免这一轮继续重复研究。

这个问题让我觉得，写长任务提示词时，还需要考虑规则怎样落实。

“不要重复”已经写清楚了，接下来需要解决的是：两个不同写法，怎样判断为同一个对象？什么记录才算有效的完成凭证？

如果要把这个流程继续做稳定，就需要使用稳定的对象标识或经过核对的名称映射，把任务状态保存下来，并在启动前检查已有成果。在可能有多个执行者的环境里，串行要求还需要调度或程序约束，不能只依赖每次都重新理解自然语言。

这些是由案例引出的完善方向，并不代表当时已经全部实现。

那段历史也没有完成全队列无人干预运行：中途仍需要我补充一次继续执行的指令，部分规则是在运行中完善的，最后还遇到外部工具额度限制。

因此，遇到长任务中断，我会先区分几个问题：

• 工作规则不清楚
  ：不知道下一项选谁、什么情况可以跳过，需要补充指令。
• 对象或状态无法确定
  ：不知道是不是做过、上次完成到哪一步，需要核对标识和保存的进度。
• 工具或资源条件不满足
  ：权限、额度或服务出了问题，需要记录恢复条件；重复说“继续”未必能解决。

长任务示范（本次整理）：

请按【优先级】处理【任务队列】。开始前，根据【对象标识和完成标准】检查已有结果；当前任务完成检查与归档后，再领取下一项。

为每项任务保留状态、产物位置和失败原因。不符合条件的对象记录原因后跳过；缺少必要证据的任务标明受阻条件。

遇到工具或资源限制时保存进度，说明恢复需要什么。恢复后先核对已有结果，再继续处理未完成部分。

这里每个占位内容都要落实到实际业务。写出“保存进度”，还需要知道保存在哪里、下次能否读取；写出“已经完成”，还需要定义怎样检查完成。

五、值得留下的提示词，应该能帮助我们处理下一次问题

回看这些案例，很多值得保留的要求，都对应着一次具体的返工：研究对象没有区分，检查范围没有说清，已有成果受到修改影响，或者任务状态无法准确判断。

如果希望把这些经验留下来，每次复盘时都可以记录：这次缺少什么条件，补充的要求能减少哪类错误，换项目后还需要重新确认什么。这样才容易把一次临时补救变成后续可以使用的方法。

反过来，如果每次遇到问题，都往提示词后面追加一句“务必认真”“绝对不能出错”，指令虽然变长了，真正缺少的条件可能仍然没有补上。

对于已经稳定的工作，我会尝试把输入要求、分析步骤、业务规则、异常处理和验收方式整理成Skill。具体的项目数据、时间范围和特殊要求，再由当次任务补充。

固定计算、文件校验和任务状态检查，有时更适合交给程序；需要结合新材料判断下一步的地方，再让AI参与。Skill也需要更新，不能把旧项目的结论当成所有项目都适用的规则。

日常使用时，不必每次写一大段。可以先用六个问题检查，只补充当前任务还不明确的部分。

一份任务交代模板（本次整理）：

目标： 这次要解决【什么问题】，结果用于支持【什么判断或行动】？

依据： 从【哪些资料和已有成果】开始，沿用【哪些已经确认的规则】？

范围： 本轮完成【哪些工作】，保留【哪些内容】？

执行： 按【什么步骤和优先级】推进，哪些变化需要确认？

例外： 遇到缺数据、重复任务或工具失败时，怎样记录和处理？

验收： 交付【什么文件和证据】，怎样区分完成、失败和尚未验证？

已经明确的信息直接复用，真正会影响结果的缺口再补充。上下文足够清楚时，在已确认的范围内，一句“继续”就能推进下一步。

我希望通过这些案例分享的，是怎样逐步建立一套自己能理解、也能检查的AI工作方法。后面再结合实际项目，继续讨论哪些规则适合整理成Skill，以及怎样把一次性的任务做成能够持续运行的工作流。