---
title: "Claude Code 持续优化：让 AI 越来越好用"
description: "把每次「不太对」记下来，按提示词、模型、流程、场景四个方向逐项改，用一份轻量日志把改进沉淀成可复用的经验。"
updated: 2026-11-13
canonical: https://docai.cc/learn/continuous-workflow-improvement/
markdown_mirror: https://docai.cc/learn/continuous-workflow-improvement.md
---
## 改进的原料是「哪里不对」

遇到不满意的输出，多数人重发一遍了事。重发是碰运气，改法才是积累。

把不满意记成三行：我问了什么、它给了什么、我期望的是什么。三行里最关键是第三行——说不出期望，等于还没想清问题在哪，换什么提示词都没用。

记够十几条再翻回去看，规律会自己冒出来：总是字太长、总是爱加小标题、总在结尾自作主张加一句总结。这些反复出现的毛病，才是值得动手改的地方。

## 四个方向，按成本从低到高

**改提示词。** 最便宜，也最常被跳过。把「写篇文章讲讲时间管理」换成带角色、读者、结构、字数的版本，差别往往是决定性的。具体怎么写，看[提示词](/concepts/prompt/)与[少样本示例](/concepts/few-shot/)。

**换模型。** 不同任务对速度、价格、写作风格的要求不一样。简单的格式化用便宜快的，需要长文推理的用强一些的，写代码另有一档。别指望一张表管所有场景，按你自己跑出来的结果记。

**改流程。** 回头看步骤：哪一步纯手工、哪一步在来回倒腾文件、哪一步其实可以让脚本先做。把「人工整理 → 发给模型 → 复制回来」压成「脚本整理 → 模型写 → 人工核」，省下的时间比调提示词多得多。每季度挑最常跑的一条流程数一遍步骤，步骤只增不减是常态；砍掉一步，往往比优化十句提示词见效。

**扩场景。** 每月问一次：哪些花时间的事我还没试过交给它。会议前的资料梳理、决策前的信息归纳、写方案前的大纲，都常被忽略。

## 做一张自己的模型选择表

「换模型」不是追新，是配对。按任务类型列一张表，只填你亲手跑出来的结论：

| 任务类型 | 优先看什么 | 我实际用哪个 | 结论日期 |
|---|---|---|---|
| 格式转换、批量改写 | 速度、稳定性 | [填写] | |
| 长文档阅读与归纳 | 上下文长度 | [填写] | |
| 代码修改 | 工具调用、准确率 | [填写] | |
| 对外文案 | 中文语感 | [填写] | |

几条规则：同一任务至少比过两个模型再填；结论标日期，隔三个月复核一次；别人的榜单只能当线索，同名模型在不同服务商处的参数和可用性可能不同，以你实际调用的结果为准。挑模型的思路可以看[如何选模型](/learn/choose-a-model/)。

## 把优化压到一分钟

持续优化听起来像要专门腾时间，其实每次一分钟就够。用完 AI 后问三句：

1. 这次改了几处才能用？改动超过两成，说明提示词还有空间；
2. 哪句话是我反复补的？把它补进模板，下次不用再说；
3. 下一次同类任务，我准备换掉哪一处？

答完就结束，不写长文。月底翻一遍，只挑出现两次以上的问题动手；一次只改一处，用下一单真实任务验证。这样优化始终挂在真实任务上，不会变成另一项待办。

## 做一次像样的对照

想验证某个改法有没有用，别凭感觉。同一个任务，两版提示词各跑一次，比较输出。

```
A：给我一篇讲时间管理的稿子。
B：读者是刚工作两年、天天加班的人。写三个能当天用上的做法，
   每个配一个具体场景，不要泛泛而谈，控制在八百字内。
```

对比时定两三条判据：有没有直接可用的内容、有没有编造、篇幅合不合适。判据事先定好，别看完结果再找标准——那样什么都能说成更好。

一次只改一处。角色、读者、字数一起换，结果变好也不知道是哪句起了作用。这套思路本质上就是小规模的[评测](/concepts/evals/)：固定任务，比较版本，留下更好的那个。

## 记一份只写有用东西的日志

不用天天写。碰到「原来如此」的时刻再记，一个月能攒五六条就很好。

```
## 11-05
试了：把「你是资深编辑」换成具体的读者画像。
结果：编造的例子少了，开头的套话也没了。
下次：写内部通知时也试试加读者画像。

## 11-12
问题：批量改写时后几批风格飘了。
改法：每批开头重申一遍规则，并让它先复述。
```

每条日志只回答一件事：我改了什么，效果往哪边动了。三个月后翻，这就是你自己的经验库，比任何通用教程都贴身。

也可以顺手记下花的时间：这条路原先要两小时，现在四十分钟。数字不用精确，量级对得上就够。它能让你在下次想改的时候，先判断值不值得改。

优化不只靠自己试。每月留十分钟看一次产品更新公告或同行案例，只挑一条当天能做的改动，试完再决定要不要留下。囤着不试，等于没看。

## 有些事接受就好

反复优化还是不理想，先分清是提示词的问题，还是这件事本身不适合交给它。需要实时信息的、需要替人做价值判断的、需要长期背锅的，交给模型只会增加你的核对成本。

这时候的正确姿势是缩小它的职责：让它做初稿、做整理、做候选，最后一步自己做。这不是退让，是把力气花在能放大的地方。

这条线的课到这里告一段落。想往下走，从沉淀知识库开始：[为什么要建知识库](/learn/knowledge-base-benefits/)。