这是一个虚构但很典型的案例：小郑是一位每天写业务代码、修线上问题、参加评审的后端或全栈开发，最近手头在忙“完成订单服务接口重构，接口平均响应从约 300ms 降到 120ms 左右（以压测为准）”，同时还要准备“上线订单服务灰度”。这次小郑需要整理一份给技术负责人的技术方案文档，决定试试 AI 生成检查清单。

背景

对小郑来说，真正写代码的时间常被排查问题、写文档和同步进度挤占，很多重复性的文字和样板代码其实可以交给 AI 起草。偏偏这次还遇到一个变数：依赖的第三方支付 SDK 下周升级，可能需要适配。技术方案文档需要尽快交给技术负责人，时间并不宽裕。

第一次尝试：问题出在哪

小郑一开始只写了一句话：

帮我写一份关于“订单服务从单体拆分为微服务”的技术方案文档。

结果 AI 给出的内容四平八稳却用不上。复盘下来，主要有两个问题：

  • 清单条目写成名词。
  • 用完不更新。

改进后的提示词

小郑按照清单生成的思路重写了提示词，核心是要求按阶段或类别分组：

请为程序员生成一份“上线订单服务灰度”的检查清单。
背景：依赖的第三方支付 SDK 下周升级，可能需要适配。
要求：
1. 按“开始前 / 进行中 / 完成后”分组；
2. 每条以动词开头，写成可以勾选的动作；
3. 用【必须】标出不能遗漏的项目；
4. 最后列出 3 个最容易被忽略的环节，并说明原因。

结果（示意）

下面的效果为虚构演示，用来说明这类改进通常带来的变化：

示例输出（虚构，节选）： 开始前

  • 【必须】确认参会名单和人数
  • 预订会议室并测试投屏 完成后
  • 24 小时内发出会议纪要 最容易被忽略：会后跟进，往往因为大家默认“有人会发”而遗漏。

拿到结果后，小郑没有直接转发，而是先检查关键事实和数字，再补上 AI 不知道的背景。

复盘：这次用到的方法

  • 每条检查项写成动作，而不是名词，例如“确认……”“打印……”
  • 要求标注优先级或必须项。
  • 根据自己的经验增删修改，删掉不适用的条目。
  • 写成动作，比如“打印签到表”而不是“签到表”

之后小郑发现，同样的方法也适用于另一类场景：交接工作时需要一份明确的待办。

复盘时小郑还想到一个问题：可以把清单做成表格吗？答案是：可以，加上负责人、截止时间和状态列，就是一份简单的任务跟踪表。

给程序员的提醒

把报错堆栈、相关代码片段和运行环境版本一起贴给 AI，比只描述现象有效得多。AI 生成的代码必须经过本地运行、测试和代码评审，不要直接合入主干。另外，对话里不要出现密钥、内网地址、数据库连接串和用户数据。

一个额外的小技巧：和反向提问结合，先让 AI 问清你的条件，再生成清单。

可以复用的经验

这个案例里最值得复用的，不是某一句提示词，而是“先说清背景和标准，再看结果、再修正”的习惯。下次遇到“排查定时任务重复执行问题”这类任务，同样适用。

相关阅读