一个写代码的普通人，每年在AI工具上烧掉多少钱？Jess Lee没算过这笔账，但她发现了一个反直觉的规律：最贵的模型往往不是最优解，就像用手术刀切菜——能切，但没必要。
作为Forem的联合创始人兼COO，Lee管理着开发者社区平台DEV的技术架构。她不是专业程序员出身，却需要频繁使用自动化工具完成工作。这种"半吊子开发者"的身份，反而让她摸索出一套极端务实的AI使用哲学。
第一层筛选：把模型当员工分级
Lee的工作流核心只有四个字——按需降级。她把大语言模型（LLM，Large Language Model）分成三档：高阶、中阶、低阶。高阶模型如GPT-4或Claude 3 Opus，处理架构设计和安全审查；中阶模型写常规代码；低阶模型干杂活——比如调整代码格式、补全注释。
"用智能且昂贵的模型去修代码空格，不值得。"Lee在博客中这样写道。她的成本曲线因此变得陡峭：80%的任务交给廉价模型，15%需要中阶模型把关，只有5%触及高阶模型的计费区间。
这种分级不是拍脑袋决定的。Lee观察到LLM的一个致命弱点：提示词（Prompt，即给AI的指令）过长时，模型会"困惑"——不是比喻，是字面意义上的注意力涣散。上下文窗口被塞满后，AI开始重复生成、逻辑跳跃，token（文本处理的基本单位）像漏水的水龙头一样流失。
她的解决方案粗暴但有效：把每个任务切成独立的小块。AI一次只看见它需要看见的东西，既省token，又减少幻觉。
第二层控制：把文档埋进代码仓库
多数开发者把架构文档存在Notion或Confluence里。Lee反着来——她把所有计划和任务说明塞进代码仓库的./docs目录。
这个细节藏着产品思维。当AI代理（AI Agent，能自主执行任务的AI程序）读取代码时，指令和上下文就在隔壁文件夹，无需跨系统调用。距离产生美，但效率产生在零距离。
她的任务描述遵循死板的四段式：目标、背景、验收标准、技术约束。没有抒情，没有"请尽量做好"这类模糊表达。Lee把系统指令（System Instructions，定义AI行为边界的规则）写得像法律条文：
「禁止猜测编码标准」「禁止引入未经验证的依赖」「所有变更必须通过测试」——这些规则在每次运行时强制注入，不给模型留自由发挥的空间。
AI在她手里不是创意伙伴，是高度规范化的打字员。
第三层兜底：免费工具+纳米服务
模型分级之外，Lee还留了一手：外部工具链。她把能外包的环节全部外包——语法检查用开源linter，格式化用Prettier，简单查询用免费的代码分析工具。这些工具零token消耗，响应速度比LLM快一个数量级。
更极端的是她的"纳米服务"（Nanoservice）策略。传统微服务按业务模块拆分，她的纳米服务按单一功能拆分——一个服务只做一件事，比如"接收JSON返回校验结果"。这种设计在人工开发时代是架构灾难，但在AI生成代码的场景下反而成立：AI写单功能代码的准确率远高于复杂系统，调试成本趋近于零。
Lee的安全观同样朴素。每个功能必须经过三步：AI生成代码→自动化测试→人工抽查。她没有迷信AI的自我纠错能力，"严格测试门"（Strict Testing Gate）是她的非 negotiable 底线。
这套流程跑通后，她的交付速度没有变慢，但代码审查通过率从60%跳到了90%以上。省下的时间不是拿去写更多代码，而是花在定义更清晰的任务边界上——这是典型的产品经理思维：慢在前端，快在后端。
帕累托法则的暴力执行
Lee反复提及一个概念：20% effort，80% result。这不是装饰性的引用，是她整个工作流的数学基础。
她算过一笔账：一个需要高阶模型10分钟完成的架构设计，如果拆成"低阶模型草拟+高阶模型审核"，总耗时可能变成15分钟，但token成本下降70%。时间换金钱，在AI计费模式下是理性选择。
这种计算方式对专业开发者可能显得斤斤计较。但Lee的身份特殊——她需要证明非技术背景的人也能驾驭AI工具，成本可控是前提条件。她的方法论本质上是一份"平民AI使用指南"：不追求代码的诗意，追求功能的落地。
她在文章结尾留下了一个开放性的邀请："我分享这套方法，是为了开放讨论我们如何构建更好的自动化。"
这句话的潜台词是：AI编程的最佳实践尚未定型，她的方案只是其中一条路径。但数据不会说谎——当多数人还在用单一模型处理所有任务时，她已经把成本结构拆成了可优化的变量。
最后一个细节：Lee的这篇文章发布在DEV社区，平台本身就是她用这套方法论参与构建的产品。读者在评论区问得最多的问题是——"你的低阶模型具体用哪个？"她没有直接回答，只是贴了一张自己模型切换决策树的截图。
那棵树的第一条分支写着："这个任务需要理解业务逻辑吗？"
热门跟贴