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

背景

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

第一次尝试：问题出在哪

林林一开始只写了一句话：

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

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

  • 不说明同行人员和节奏偏好。
  • 忽略天气和安全。

改进后的提示词

林林按照 AI 行程规划的思路重写了提示词，核心是让 AI 先问你几个关键问题：

我计划带家人去[城市]旅行 3 天，同行有一位老人和一个小学生。
- 偏好：自然风光和当地美食，不喜欢太赶；
- 预算：中等；
- 交通：主要使用公共交通和打车。
请：
1. 先问我 3 个你需要知道的问题；
2. 然后按天安排行程，每天不超过 3 个主要地点，标注交通方式和大约时间；
3. 每天安排午休或休息时间；
4. 列出需要提前预约或核实的事项（开放时间、门票等），提醒我以官方信息为准。

结果（示意）

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

示例（虚构）：一家人计划周末出游，AI 安排了“上午公园、午饭后回酒店休息、傍晚老街小吃”的节奏，并提醒“公园周一闭馆，请出发前在官网确认”。他们根据提醒调整了日期，避免了白跑一趟。

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

复盘：这次用到的方法

  • 让 AI 生成按天安排的行程，标注交通方式和大致时间。
  • 对景点开放时间、门票和交通信息，通过官方渠道或联网搜索核实。
  • 根据实际情况调整行程，比如天气、体力。
  • 说明是否带老人孩子、喜欢紧凑还是悠闲，行程才合理。

之后林林发现，同样的方法也适用于另一类场景：出差顺便安排半天游览。

复盘时林林还想到一个问题：行程能导出到日历吗？答案是：可以让 AI 输出标准格式的时间安排，再手动或借助工具导入日历。

给程序员的提醒

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

一个额外的小技巧：旅行中遇到变化，随时让 AI 调整剩余行程。

可以复用的经验

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

相关阅读