一个 AI 项目最容易让人兴奋的时刻，是第一次跑通。
点一下，文档出来了；再点一下，流程完成了。对习惯靠交付证明自己的程序员，这一刻很有成就感。
但如果你准备转向 FDE，还要往后看一步：客户每天用它，等不等得起，养不养得起？
Notion 的公开案例，提供了一个很有意思的切口。据 Anthropic 发布的案例，Notion 用 Claude 支持写作、搜索等功能，并通过提示词缓存降低处理成本和等待时间。联合创始人 Simon Last 在案例里特别提到了缓存带来的速度与成本改善。[1]
我注意到的不是一个新的模型名字，而是一个熟悉的工程问题：那些反复处理、其实没变的东西，能不能不再每次重做？
01｜客户要买的，不是一次漂亮的演示
在这个案例里，Notion 既要让用户从工作资料里找到信息，也要让功能在实际使用中保持响应。模型能回答，只是其中一部分；重复输入怎样处理，同样影响体验。[1]
把它换到你自己的项目里，问题会更直白。
假设你为一家企业做资料处理助手。一次演示只有几份材料，什么都交给模型，看起来很顺。真正使用后，同一份业务规则可能被反复发送，一个任务可能因为格式问题重试，最后还要由员工重新检查。
这是假设场景，不是 Notion 的实际实施记录。但它能暴露一个常被忽略的区别：接口调用便宜，不等于一件事情做完便宜。
如果结果需要反复修，人就没有真正从流程里解放出来。你少算了重试、等待和复核，客户看到的账就会跟演示完全不同。
这也是工程经验可以重新被看见的地方。你过去做过的缓存、性能分析、调用链排查，并没有因为出现大模型而失去意义。它们需要换一个目标：不是让某个接口看起来更快，而是让一项完整业务更值得运行。
02｜先找重复工作，再谈换便宜模型
提示词缓存不是把旧答案直接复制给新问题。按 Anthropic 的技术说明，它复用的是满足条件的相同提示前缀；稳定的规则、示例等内容适合放在前面，变化的请求另行处理。是否命中，需要查看实际使用记录。[2]
这意味着，优化不只是打开一个开关，还涉及你怎样组织上下文。
哪些规则相对稳定？哪些资料属于当前客户？什么变动后需要重新处理？这些问题如果没想清楚，单看“缓存已经开启”没有多大意义。
但缓存也不是每个项目都该优先采用。低频任务、经常变化的内容，未必有足够复用机会。为了追求命中率而把无关信息塞进去，更可能把方案做复杂。
我建议先把一个任务的经过记录下来：资料在哪一步被重复读取，哪类错误触发重试，员工又在哪一步重新做了一遍。
先删掉没有必要的工作，再比较完成必要工作的不同方式。
如果固定规则就能判断，就不必让模型猜；如果必须理解上下文，就不要为了便宜把关键材料删掉。这里没有一套对所有客户都成立的省钱口诀，只有结合任务做出的取舍。
03｜别只看单次调用，要看“一个合格结果”
一个值得交付的成本账，我建议至少同时记录三件事：任务总共花了多少计算费用、经过了多久、需要多少人工复核。
再附上结果是否合格。没有这一步，所有比较都可能失真。
比如，同一组授权使用的样例，分别走原方案和优化方案。输入范围、合格条件保持一致；记录失败任务，而不是只挑成功样例。计算费用可以用金额表示，人工用分钟记录，不必强行把两者凑成一个看似精确的数字。
如果新方案便宜了，却漏掉了关键内容，这不是节约，是把成本推给后面的人。如果响应变快了，却让使用者无法理解结果，也不是一次完整改善。
这些是给读者的测试建议，不是上述公司公布的完整测试方法。
你真正要交出的，是一段别人可以检查的判断：在什么任务、什么质量要求和什么使用量下，这个方案值得用；超过什么范围，需要重新评估。
04｜你的价值，不必只写在代码量里
准备转型 FDE 的程序员，可以从现有作品里挑一个任务，补上这张运行账，而不必先开发一套更大的系统。
交代原来怎么做、为什么改、同样条件下结果如何、还有哪些问题没解决。别只写“进行了性能优化”，把优化与使用者的工作联系起来。
这样的作品不保证高薪或订单，但能让客户或面试官看到：你不仅能让 AI 工作，还能判断它在什么条件下值得持续使用。
FDE 大师所强调的“从使用 AI，到创造生产力”，也可以从这里理解：模型负责一部分能力，创造者负责把能力放进一个值得运行的方案。带着你的第一个任务和运行记录，了解 FDE 大师：fdemaster.cn。
会把 AI 做出来，是起点。能让客户愿意一直用下去，才是你需要继续证明的工程价值。
资料来源
[1] Anthropic，Notion builds agent orchestration where teams and Claude collaborate on real work：公开客户案例，查阅于 2026-10-18。
[2] Anthropic，Prompt caching：技术说明，查阅于 2026-10-18。
