用得多了，慢慢能分出「哪些事交给 AI 是纯赚，哪些是给自己挖坑」。下面是我的个人清单，带具体例子。
最值的 5 件事
1. 一次性的脚本和正则。 「把这个目录下所有 md 文件的标题行提取出来，生成一个 sql 的 insert 语句」——这种活以前要翻半小时文档，现在三十秒。判断标准：写完就不再看、跑错也没大后果。
2. 读陌生代码。 接手项目时让它回答三个问题：请求从哪进、数据落在哪张表、这行奇怪的判断是为了兼容什么。它偶尔答错，但错误的答案通常也很容易被我看出来。
3. 把长东西压成要点。 一份 30 页的规范、一场两小时的会议录音转录、一个几百行的报错堆栈——先让它压缩成十条要点，我再决定哪几条值得精读。这一步省的不是阅读时间，是「决定读不读」的时间。
4. 翻译与润色。 中英互译时先让它直译，再让它按「技术文档的语气」重写一遍，两版对照着看，往往比我一次翻完更准。写英文 issue 和 commit message 也基本交给它。
5. 命名和起标题。 变量名、接口名、文章标题、分类名——它一次给十个候选，我挑一个改两个字。不用纠结，也不会有心理负担。
最不值的 3 件事
1. 架构决策。 它会认真给你三个都挺合理的方案，然后你发现没有一个能回答真正的问题：「团队三个人，历史包袱是这套老框架，未来半年要支持多租户，选哪个？」——这些约束它不知道，也不该替我知道。
2. 没验证过的配置。 nginx、supervisor、systemd、K8s 的 yaml——写错就起不来。它给的永远是「看起来对」的草稿：字段名可能是旧版本的，缩进可能少一层，某个参数在 1.25 之后被废弃了。我现在把这类产物当「填空提示」，逐行对着官方文档填。
3. 需要精确事实的文案。 价格、日期、法律条款、产品参数、引用别人的话——它会编，而且编得很像真的。有次它给我一段「某标准规定……」，我去查原文，那句话不存在。凡是「说错了要负责」的内容，事实部分自己写，让它只做表达优化。
一条经验
区分标准其实就两条：错了的代价大不大、我有没有能力一眼看出它错了。
- 代价小 + 我能验 → 放心交给它（脚本、命名、翻译）；
- 代价大 + 我能验 → 让它先做初稿，我做逐行核对（配置、SQL、文档）；
- 代价大 + 我验不了 → 不要用它的产出，至少不要直接用（法律、医疗、财务，以及你不熟的领域）。
把这三格想清楚，比记任何提示词技巧都有用。