顶级AI模型开发产品，每月20欧元预算够吗？

月末结算日，你点开AI服务商的后台，账单数字稳稳停在20欧元——这不是巧合，而是你给自己划出的一条硬线。这不是抠门，而是一道简单的算术题：只有把工具成本死死按在收入线以下，独立产品才不会在下个季度变成一台烧钱的机器。这个场景来自一位正在同时维护两个项目的开发者，他的实践比我们想象的要更系统、更冷静，也更能说明一件事：用今天最顶尖的代码模型做产品，真的可以只花20欧元一个月。

他的两个项目里，一个叫Hakanai，用于生成静态博客；另一个叫Writizzy，是一个集写作、邮件通讯和内容变现于一体的平台，可以理解成是一个不在GAFAM版图里、也不在美国土壤上的Medium或Substack替代品。你正在读的这篇文章，背后跑的正是Writizzy。

短短半年，Writizzy就吸引了550名用户，但两个产品加起来的月收入不超过250欧元。他对自己的要求简单到几乎苛刻——不在AI调用上花超过自己所赚的钱。就是在这个紧箍咒下，他摸索出了一整套让顶级模型乖乖待在预算内的工程方法。

Writizzy的代码拆开来有三块：用Kotlin写的API，用Nuxt搭建的管理后台，以及同样基于Nuxt的博客前端——负责把内容呈现给读者。当多数人还在争论“到底该选哪个AI编程助手”的时候，他的核心模型选择十分明确：Claude。理由很直接，在目前的代码基准测试上，Claude仍是评分最高的那一档。不过，他也没有把话说死，在文章的最后，他留了一句“正在考虑替代方案”。这种对模型依赖保持开放的态度，恰好构成了我们接下来要展开的那场辩论——用最贵的模型，打最省的仗，到底行不行得通？

先把结论式的判断放在一边，我们先钻进他那一套被称作“上下文工程”的操作系统。这个名字听起来有点唬人，但底层逻辑非常朴素：给大模型的不是漫山遍野的文档，而是一个精心裁剪过的、必要且充分的上下文窗口。这么做的目的只有一个——把模型的求解空间压缩到最小。你让它看到的路径越窄，它随机漫步、调用一套根本不存在的API、或者参考一份三年前的旧版文档的概率就越低。这不但直接压制了幻觉，还避免了你事后花更多token去修补这些凭空出现的错误。换言之，省token的第一站，不是精打细算每次对话的长度，而是用上下文设计从源头掐断浪费。

如果拿掉这套上下文工程，会发生什么？原文里有一句很直白的话：“如果你不这么做，当AI编造出不存在的API，或者拽出一份过时的文档时，别感到惊讶。”这种情况一旦出现，修复的成本往往是一次性的好几倍：你得先让模型意识到错误，再重新构建正确的调用路径，反复验证，来回消耗的token可能轻松超过第一次生成时的用量。

因此，严格限制上下文的本质，是一种预防性的成本控制。它不是简单地缩短提示词，而是通过结构化的文件，让模型每一次读取都能迅速定位到当前任务真正需要的那一小块信息，而不是在代码仓库里像逛迷宫一样随机翻阅。

这套上下文工程的具体载体，首先是一个叫claude.md的文件。它是AI进入项目的入口。你打开这个文件，看到的不是散乱的需求描述，而是三个层次的信息：项目目标——用它来告诉模型这个仓库存在的根本原因；整体结构——防止模型在成百上千个文件里盲目抓取；以及，最核心的、贯穿整个开发流程的一个清单：specs列表。

这个列表在作者的日常工作中充当着开发指南的角色，同时也是一个动态索引，让模型知道该去打开哪些文件、理解哪些接口。也就是说，claude.md不是在喂给模型一堆资料，而是在帮模型建立一套“只读必要内容”的读取策略。

不止项目根目录，子目录里也藏着各自的claude.md文件。每当模型的操作路径进入某个子应用，比如Nuxt博客前端对应的文件夹，那些子目录下的claude.md就会被加载起来。这些文件原本承担着一个列举“可用技术”的职能，把当前子应用下可以调用的技术栈罗列清楚。

不过，作者在实践过程中发现，光靠列举能用的东西还不够，于是他的重心越来越向另一个概念倾斜——规则。这也引出了整套系统中更主动、更能对抗熵增的一层：.claude/rules。

规则文件的设计思路，和那些一次性写完就丢进仓库再也没人看的文档截然不同。它们是可以条件加载的。举个例子，当模型的上下文进入/app这个目录时，对应的Nuxt规则就会被自动激活。这样一来，不同子应用、不同运行环境的差异化要求，就不会被一个臃肿的全局配置搅成一团乱麻。