面试官：“你一天烧几十个token也好意思面AI应用开发？”我镇定自若：“我烧的不是token，是我的热情。”面试官：“明天二面。”这个段子最近在很多技术群里传疯了，笑归笑，但仔细想想，它戳中的其实是AI应用开发求职者最真实的窘境：简历上写着“熟悉大模型应用开发”，真到了面试现场，面试官一句“你一天烧几十个token”就能把你打回原形。因为谁都清楚，这个领域的实践痕迹几乎无法伪装——你调过多少次API、迭代过几轮Prompt、跑过多少条测试数据，从你嘴里的技术细节、你拿出来的项目深度，甚至你说“成本”这两个字时的表情，全都藏不住。我把这句话视作一面照妖镜，也当成一张入场券的隐喻。今天想认真聊聊：token消耗这个指标在AI应用开发岗位面试里到底意味着什么，一个真正有底气的AI应用开发者，平时到底在“烧”什么、该“烧”什么、怎么“烧”才不白烧，以及如果你现在正打算转型或者刚起步，一周时间能做出一个什么样的Demo去接住这类灵魂拷问。1. 这个段子背后，藏着一场关于“AI应用开发”的正名1.1 面试官为什么单挑token说事先把这个岗位本身聊透。AI应用开发，和算法工程师不同，它通常不做模型训练、不碰权重和梯度，核心工作是利用成熟的LLM能力，在具体业务场景里做出真正能用的东西。拿实际任务举例：给客服做一个智能工单分类；帮法务批量摘要合同；给运营搭一个周报自动生成器；做一个能检索内部知识库的问答机器人。这类岗位面试有一个共性难题：很难通过八股题来判断候选人水平。你问“LLM的注意力机制怎么理解”，背过几天文档的人都能扯几句；你问“Transformer结构里QKV分别是什么”，培训速成班也教过。但如果你问“你上一个项目的对话平均要花多少token、有没有试过更省的结构”，一个真正做过事的人和一个只是在文档里看过的人，回答质量的差距会立刻拉开。所以面试官问“一天烧几十个token”，本质上不是嘲讽，而是一个高效的筛选动作。他是在快速探测三件事：你有没有真正动手调过模型，还是只停留在curl通一个API返回hello world的水平；你对成本敏不敏感，有没有把token当成一个工程指标来管理；你有没有面对过真实场景中的脏问题、坏数据、超长上下文，因为这些才会真正烧token。你要是只在本地用某一款开源模型玩过几次对话，没接过线上API，没批量跑过测试集，没为降本改过Prompt结构，那你确实很难接得住这句话。1.2 一天烧几十个token，到底意味着什么很多人对token数量没有体感，先把这个概念落到地上。Token是模型处理和计费的基本单位，可以粗略理解成“字词片断”，一个中文汉字大约对应1到2个token，一个英文单词大约对应1到3个token。普通一次API调用，哪怕只是简单问答，输入加输出也至少几百token开头。然后我们来算账：你说“一天烧几十个token”，这意味着什么？一次完整对话都跑不完，因为一次几百token的调用就已经超过这个量了；更不用说做一次RAG检索问答，得把用户问题、检索回来的若干条文档片段、系统Prompt全部拼进上下文，一次调用就轻松上千token；至于写一段代码让模型帮忙改成流式输出、做一次函数调用带参数返回、跑五条Case做效果对比，每次都是一两千token的成本。所以几十个token的一天，基本等于没动手。这不是省钱，是压根没有进入实践状态。说得更直接一点，一个真正在做AI应用开发的人，光是调试一个系统Prompt，在一个模型上反复试三五版，再配几组few-shot示例，半天下来烧一两万token跟喝水一样正常。我自己的经验是，认真做一个小功能模块，一天在API上烧掉几万token是最低消费，你要是开了调试日志反复跑，十万token也可能。但是这里也要说句公道话。面试官强调“烧得多”，并不真的指望你把公司预算当柴火烧。他真正想看到的是：你不仅烧得多，而且每一分token都烧得有目的、有产出。每天只调几十次API但都在记录对比结果、迭代改进方案的人，和一天盲目重试几百次但从不总结的人，后者才是在烧钱，前者才是把token当研究经费。1.3 面试官真正想听的不是“我烧了多少”，而是“我用它解决了什么”把这个问题翻译一下，面试官的潜台词其实是：你烧了这么多token，烧出了什么名堂？最差的回应就是段子里那种抖机灵——“我烧的是热情”。段子里能换到二面是因为幽默，现实里只有这一句没有作品兜底的话，就是把自己往火坑里推。稍微好一点的回应，是直接把自己的实践过程摊开来讲：“这周我在调一个用于工单分类的Prompt。一开始让模型直接判断工单类型，准确率只有65%，后来我加了三个few-shot示例并把分类体系从12类压缩到7类，准确率到了82%。中间大概迭代了十几版Prompt，烧了大概五万token。每次改动我都保留了输入输出快照，最后还有两千多条测试集用来评估。”这段话的信息量完全不一样。面试官能在几秒钟内判断出：这个人懂Prompt对输出质量的影响；知道分类体系设计本身也会影响效果；有量化评估的习惯；有版本管理的意识；最关键的，他对token消耗有感知，知道一次排障大概要多少成本。“烧了多少”只是门槛，“烧出了什么”才是分水岭。所以这篇文章想帮大家做的事很明确：把关于token的实践细节彻底搞懂，把简历上那些虚词换成经得起盘问的真东西。2. 想不被这个问题问倒，先搞懂AI应用开发的核心能力模型2.1 AI应用开发不等于调接口每次刷到“LLM API调用教程”，底下都会有人问：“这不就是调个接口吗？有什么好学的？”说这话的人，大概没做过一个真正要上线的AI应用。接口调用只是最外层的一毫米，往深了走，AI应用开发是一套完整的能力栈。拆开来看，至少要具备五个层次的能力。第一层是Prompt工程。这是门槛最低但水最深的一块。不是会写“你是一个智能助手”就叫Prompt设计。真实场景里你得学会结构化指令、设置角色约束、给few-shot示例、控制输出格式、处理模型幻觉、设计思维链引导。举个例子，同样是让模型抽取合同中的付款条款，直接提问和给出“已知干扰项-抽取规则-输出模板-边界说明”四段式指令，效果差异会大到让你怀疑是不是换了模型。第二层是RAG（检索增强生成）的设计与落地。企业私有知识、实时资讯、长文档问答，这些场景下微调不现实，只能靠检索把相关信息塞进上下文。这里面每一步都是坑：文档怎么切块、块大小多少合适、Embedding模型怎么选、检索回来TopK取多少、相关性阈值怎么定、上下文超长了怎么压缩。第三层是Agent与工具调用。现在AI应用已经很少停留在“一问一答”了，很多需求要求模型自主决定调用哪些工具、以什么参数调用。比如一个日程助手，面对“说明天下午三点和客户开会”这句指令，需要模型从文本中抽取出时间、地点、参与人，决定调日历接口还是查通讯录，并在参数缺失时追问。这背后涉及Function Calling的Schema设计、意图判定的Prompt策略、多轮对话中的状态管理。第四层是效果评估。这是多数自学开发者最忽视的一环，也是面试官最爱追问的一环。你凭什么说你的Prompt比别人的好？你的RAG检索准确率有多少？面对回答质量方差极大的LLM，你靠什么来保障业务稳定？这就需要建立评估集、设定评测维度、跑批量对比、量化指标。Mechanical的活，但不过这一关，你永远只能说自己“感觉效果好”。第五层是成本与性能工程。这部分直接呼应开头那个段子。缓存怎么设计、模型选大还是选小、复杂任务怎么分流、超长上下文怎么截断、流式输出怎么落地、并发下的延迟怎么优化，这些能力直接决定了AI应用能不能真正放进业务里跑起来。把这五层能力装进脑子里，再回头看面试官那句“一天烧几十个token”，你就会发现他要验证的远远不止“你有没有调API”，而是你在这五个层面有没有真实项目的肌肉记忆。2.2 token是开发者与模型对话的“货币”把token这个概念再往深里讲一点。很多教程把它解释成“计费单位”就结束了，但用过一段时间就会发现，token其实是开发者与模型对话时的“资源预算”，是你每一轮实验的单位成本，也是你方案设计时的一个约束变量。举个例子就清楚了。假设你要做一个会议纪要摘要工具，系统Prompt里有角色设定、要处理的会议记录的格式说明、输出模板、还有指令细节，光这个系统Prompt可能就400token。来一段5000字的中文会议记录，大约是4000到5000token。模型输出的纪要，假设写得比较详细，又是1000多token。那么单次会议纪要处理一次，消耗大约6000token。假设每天业务侧要处理300场会议，一天光这一个场景就是180万token。同一个小功能，如果你把系统Prompt精简到250token、输出模板压缩到800token、并对输入做“只保留正文核心段落”的预处理，单次消耗可能降到3500token，一天的消耗直接砍半。这就是为什么面试官会把token挂在嘴边。一个没有真实做过项目的人，会以为AI应用开发就是选一个最聪明的模型然后往死里调；一个做过生产级项目的人，开口谈的第一件事永远是：这个场景下，模型能力、上下文长度、成本、延迟这四个变量怎么平衡。再补充一个很多人不知道的细节：不同模型架构下，同样一段中文消耗的token数量并不完全相同。原因在于各家的分词器词表设计不一样，英文好的模型处理中文时可能切得更碎，导致同样内容token数偏高。所以严格来说，做成本对比时不能光看单价，还要用同一段真实业务文本去测出各家实际的token消耗量，再乘单价算总账。这个细节能在面试时讲出来，立刻就跟只会背价格表的人拉开差距。2.3 面试官用token做筛选的潜台词把前面这些信息综合起来，面试官问token消耗的潜台词其实可以拆成三层。第一层：他害怕招进来一个只会“调参型开发”的人。这类人简历写得天花乱坠，但遇到真实生产环境里问题就直接抓瞎。调接口谁都会，能在一堆文档里把API串起来、做完容错、写好评估、控好成本，才是一个应用开发者的真正价值。第二层：他在意思维习惯。一个开口就是“我烧了几万token”的人，潜意识里已经把模型调用当成需要管理预算的工程行为；一个对token毫无概念的人，大概率对成本、性能、资源消耗这些工程要素也缺乏敏感度。第三层：他在测试你对自己的项目有多投入。AI应用开发有个很现实的特点：没有真实项目的持续试错，你不可能积累出“这个Prompt模板在这个场景会失效”“长文本分段要避开表格”“日期解析用正则比让模型抽更稳”这类碎片但极重要的实战直觉。而这些直觉的养成，恰恰就体现在token的消耗量级上。聊到这里你会发现，token这个话题根本不是一个成本会计问题，它是一把衡量开发者“真实实践深度”的尺子。尺子背后的刻度，就是你的项目经验。3. 用一周烧出底气：一个可谈可演示的AI应用Demo实操3.1 选题：一个让面试官眼前一亮的真实场景说再多理论，不如亲手跑一遍。如果你现在准备面试AI应用开发岗，又不确定自己的实践量能不能扛住拷问，我的建议很明确：花一周时间，认认真真做一个垂直场景的AI应用Demo，然后把整个过程中的关键决策记录下来。一周时间足够，前提是选题别铺太大。选题有一个核心原则：选一个边界清晰、能被你完整掌控的窄场景，不选“做一个全能AI助手”这种无底洞。我推荐的方向，是那些已经存在明确痛点、又不至于涉及过多复杂系统的场景。拿我实际带过的一个模拟项目举例。某团队的运营人员每天要处理近两百封用户反馈邮件，需要人工判断每封邮件属于“投诉”“咨询”“建议”“退订”哪一类，还要识别紧急程度并提取关键词。这是一个再典型不过的AI应用场景：任务边界清晰、有分类体系可设计、有历史数据可模拟、效果可以被量化评估。你可以用同样的思路找自己的场景：合同关键条款抽取，简历初筛打分，售后工单自动分派，市场竞品动态摘要，产品的用户评价情感分析。这些场景的共性是什么？业务边界清晰，不需要对接太复杂的外部系统，产出可以被简单验证。相比之下，如果你一上来就想做一个“企业级智能客服”，又要多轮对话、又要知识库问答、又要转人工策略、还要对接工单系统，那一周时间光是梳理需求都不够，Demo做出来也只能是表面功夫，经不起面试官追一句：“这个客服的意图识别是怎么做的？错误分类你们怎么兜底？”3.2 搭建环境与选择模型把环境搭建这部分尽量压缩到半天内完成，别在这上面耗时间。强烈推荐直接用成熟LLM服务提供商的API，不推荐自己部署开源模型。原因很现实：这一周你的目标是把“应用开发”能力跑通，而不是把时间花在运维GPU和模型量化上。本地部署一个几B的小模型，虽然token零成本，但效果可能不够有说服力，而且光调试环境就可能吃掉两天时间，得不偿失。模型选择上，优先选当前主流的能力较强的商用模型API，一个关键原因是：面试沟通时对方大概率熟悉这套生态，你的项目细节他能快速理解。至于具体选哪家，我不在这里点名，原则是看你主要处理的是中文文本还是英文文本、上下文长度需求、以及API的稳定性。如果条件允许，可以在项目里同时对比两到三个模型在你自己数据集上的表现，这一手在面试时非常加分，因为“会做技术选型”是应用开发者的核心素养之一。环境结构可以很轻：一个Python脚本、一套依赖库、一个文件夹管理数据和输出。不要为了做一个Demo就上个重框架，那只会让你陷入“配环境两小时、写业务两分钟”的泥潭。3.3 Prompt迭代与RAG接入环境就绪后，开始做核心环节。注意，做这个环节时一定要穿上“评估”这件盔甲，否则你就是在裸奔。第一步，准备数据。模仿真实场景造200封邮件样本，分布在四类里，覆盖常见说法变体：有长篇大论的投诉、有一句话的退订、有带情绪词的咨询、有提了一堆建议的反馈。把这批邮件按7:3切成开发集和测试集。开发集用来做Prompt迭代，测试集最后跑一次做效果验收。第二步，写第一版Prompt。别急着一步到位，就用最直观的写法：告诉模型做什么分类、输出什么格式、有哪些分类。跑完十封开发集邮件，你会发现大量问题：分类边界不清晰导致投诉和咨询经常混淆、模型输出格式不听话、某些邮件被强行塞进不合适的类别。把这些问题记录成一个问题清单。第三步，针对问题迭代Prompt。你会发现自己在不断烧token，而且这种烧法是有价值的。给Prompt加few-shot示例，每条邮件附上正确的分类结果和简短的分类依据；给分类体系补边界说明，比如“只有在用户明确要求退款或补偿时才视为投诉”；给输出格式加JSON约束；给模型加一条“不确定时输出unknown，不要强行归类”的安全兜底。每改一版，跑十到二十条开发集邮件，记录正确数量。这个过程你会亲眼看到正确率从70%爬到85%以上，这就是token燃烧的意义。如果你选的是知识库问答类场景，在这个阶段还要把RAG链路搭起来。文档切块时注意块大小：切太大了检索粒度粗、噪声多，切太小了上下文割裂、语义不全。我自己的经验是先按400到600字切块、带50字重叠，再用这个基线跑一轮评估，根据检索命中情况再调整。还有一个小技巧：给每个块生成一句话摘要作为检索元数据，召回相关性会明显提升，这个细节花不了多少token，但面试时讲出来很显功力。3.4 用token日志证明你“烧”得有价值这一步很多自学开发者完全不会做，但恰恰是面试叙事里最能打的部分：给整个Demo建立一个token消耗日志。具体做法很简单：每跑一次Prompt，就把输入token数、输出token数、模型型号、版本号、对应哪条数据、跑完后的效果指标，一行一行记录到一张表里。比如你可以建一个CSV，列名为：时间、场景、Prompt版本、模型、输入token、输出token、单条成本、是否正确。跑完一百条数据，这张表就是一个完整的实验记录。千万别小看这个动作。一周后你手上会多出两样别人没有的东西：第一，一张token消耗模型表。你能清楚地告诉面试官：我的系统单次调用平均消耗多少token、成本是多少、相比初版降了多少。这种颗粒度的成本认知，直接回应了“你一天烧几十个token”这类问题。第二，一组Prompt迭代曲线。你能拿出“V1准确率70%、V2准确率78%、V3准确率83%、V4加了few-shot后到86%”的演进过程。面试官立刻会意识到，你不仅做了一个Demo，还建立了一套评估和改进方法论。这才是“烧token”烧出的真金。附上一点代码示例，帮大家理解日志记录的思路。实际开发中你在调用API的封装函数里顺手加一段日志逻辑即可：import csv import time LOG_FILE = "token_log.csv" fields = ["time", "scene", "prompt_version", "model", "input_token", "output_token", "cost", "is_correct"] def log_token_usage(scene, prompt_version, model, info, is_correct): # info 里包含 API 返回的 usage 字段 input_token = info["prompt_tokens"] output_token = info["completion_tokens"] # 根据模型单价换算成本，这里只写伪代码逻辑 cost = (input_token / 1000) * INPUT_RATE + (output_token / 1000) * OUTPUT_RATE with open(LOG_FILE, "a", newline="", encoding="utf-8") as f: writer = csv.DictWriter(f, fieldnames=fields) writer.writerow({ "time": time.strftime("%Y-%m-%d %H:%M:%S"), "scene": scene, "prompt_version": prompt_version, "model": model, "input_token": input_token, "output_token": output_token, "cost": round(cost, 4), "is_correct": is_correct, })注意，实际模型接口返回的结构各家不太一样，但一般都会包含输入的token数和输出的token数，中文文档里通常写成“输入tokens”和“输出tokens”。你把它取出来落库即可。有了这张表，后面做成本分析、实验复现都有据可依。3.5 提炼成面试叙事Demo跑完，token日志有了，效果指标有了，最后一步是把它整理成一个能在面试里讲三分钟的项目故事。很多人项目做得不错，一开口就讲得像流水账，这是极大的浪费。推荐的叙事结构是：场景痛点是什么、我做了什么技术选型、迭代过程中遇到了什么具体问题、我是怎么定位和解决的、最终效果如何、我对成本是什么感知。来一段真人口吻的示例：“我做的是一个邮件自动分类工具。运营每天要处理两百封反馈邮件，人工分拣效率低且标准不一致。我选了商用大模型API来实现，没有自己做训练。第一版Prompt很朴素，让模型按四个类别分类，开发集准确率只有70%左右，投诉和咨询经常混。后来我给Prompt加了few-shot，每条示例里包含邮件原文、分类结果、还有一句人工标注的判断理由，准确率到了78%。再后来我把分类体系里每类的判定边界写清楚了，还加了一条‘不确定就标unknown’的兜底规则，准确率到了86%。整个迭代过程我记录了token消耗，单次调用平均从最初的1800token降到1200token，因为我去掉了输出里冗余的解释部分，要求它只输出JSON和置信度。”最后再补一句你对成本的感知：“目前跑完全量测试集，两百条邮件的总成本大概在几块钱，单条成本不到几分钱，这个量级在业务上是完全可接受的。”这段话全程没有空话，没有“我认为AI是未来”这种正确的废话，面试官听到的是一个个具体的决策和指标。到这一步，你面对“一天烧几十个token也好意思面AI应用开发”这句拷问时，就有底气把token日志拍在桌上：我这一周光调试这个Demo就烧了大几万token，而且每一轮烧的结果都在表里。4. 面试现场：如何接住“token拷问”并用作品说话4.1 常见追问速查表只做一个Demo还不够，你得提前预判面试官会顺着项目往哪些方向追。基于我自己参加和模拟面试的经验，AI应用开发岗位的高频追问其实高度集中，列一个速查表供参考。追问方向面试官真正想知道建议的应对素材为什么选这个模型/A PI你有没有做技术选型，还是随手拿了个最火的对比过两三个模型的提取准确率、成本、延迟你的Prompt是怎么设计的你有没有方法论，还是全靠感觉讲清楚从V1到V3的迭代逻辑、few-shot的设计依据怎么评估效果你有没有量化意识讲开发集和测试集的划分、正确率/召回率的计算方式怎么控制成本你对生产环境有没有概念讲token日志、Prompt压缩、缓存策略、模型分级遇到模型输出不听话怎么办你有没有异常处理经验讲格式强制、JSON修复、重试机制、兜底规则RAG相关的检索不准你对检索链路有没有实操理解讲切块大小、重叠、Embedding选择、TopK调参过程如果业务量扩大10倍你有没有工程化思维讲并发处理、批量调用、限流、异步队列这张表直接拿去用，每个方向都对应你项目里一个可以展开讲的具体细节。面试前自己对着表过一遍，每个问题准备一个两分钟的小故事。4.2 两类错误回应 vs 正确回应面试现场听到token质疑时，人的应激反应往往分两类，都容易踩坑。第一类：不自信型。“是是是我确实用得不多，我还在学习阶段，希望进公司多积累。”这种回应等于主动缴械。确实经验不足没关系，但你不能在没有任何实践证据的情况下直接认怂，面试官会怀疑你的自驱力和抗压能力。正确做法是把话题扭向你能控制的部分：“我这个周刚做了一个Demo，大概烧了几万token，这里面每一步我都记了实验日志，比如……”用的事实重新定义自己的“使用量级”。第二类：防御型。“烧得多不代表能力强，token多只是说明API调得频繁，真正的设计能力不能这么衡量。”这句话道理没错，但听起来像在狡辩。尤其当面试官只是想开个话题，你接一记硬怼，气氛直接凝固。正确做法是先笑着认下这个梗：“哈哈被您看穿了，不过我确实有个项目可以给您演示一下，这个项目里我对token消耗做过完整的记录……”然后直接展示。这里最关键的技巧叫“接梗但不接刀”。段子里那种幽默回应在职场上可以用，但必须用作品做支撑。你可以幽默开场，但不能只有幽默。接到问题后五秒内转到自己的项目叙事上，让面试官顺着你的节奏走。4.3 避坑清单：从简历到演示结合我之前踩过的坑，再来一份AI应用开发求职避坑清单。这些细节很少被写进面经，但每一件都在真实面试里决定过成败。简历上不要写“精通Prompt Engineering”。这句话在面试官眼里约等于什么都没写。改成“设计了一套基于few-shot的分类Prompt，将准确率从70%提升到86%”，信息量完全不同。不要只演示“能跑通”的Demo。面试官对顺利运行的demo早免疫了，他想听的是你在开发过程中遇到什么阻碍、怎么解决的。把token日志里那些“改坏了”“准确率反而下降”的记录留下，这比完美顺利更能证明你的真实参与度。不要在面试时临时打开一个没准备好的笔记本环境。环境可能出状况、网络可能波动、依赖可能要重新装，这些在高压下一旦卡壳非常减分。准备两套备案：录好的演示视频，以及一份带结果的截图文档。不要忽视对基础概念的准确表述。面试官随口问你“RAG里Retriever和Generator分别负责什么”，你不能答得含糊其辞。能独立完成Demo的人不应该栽在这些基础概念上，但紧张状态下确实容易嘴瓢，面试前花一小时把核心概念用自己话复述一遍，不亏。5. 热情之外，AI应用开发者的长期主义5.1 用最小代价保持手感段子里那句“我烧的不是token，是我的热情”能火，是因为它某种程度上是真话。这个领域太吃手感了，隔两周不碰API，很多细节就会开始模糊：某个模型的输出风格变了、新的工具链生态出来了、Prompt写法在另一个模型上不work了，这些感知只能靠持续实践维持。但我不建议为了保持手感无脑烧钱。更可持续的方式是建立一套策略组合：主力场景用一个足够强的商用API去跑真实小项目，日常试错用价格优势明显或免费的模型，需要对比验证时再交替调用。另外很多平台会提供免费试用额度，新用户额度薅起来也够玩一阵。关键是形成“带着问题烧token”的习惯：每次调用前先写下想验证什么，跑完立刻记录结论，这样的token烧得最少、长进最快。5.2 把每次实践沉淀成可复用的资产做AI应用开发有个容易被忽略的复利效应：你每一次实践留下的Prompt模板、评估数据集、token成本基线、踩坑笔记，都是可以反复使用的资产。再做一个新场景时，把上次积累的模板拿出来改一改，首版效果可能就比从零开始强不少。我现在给自己定了一条硬规矩：任何一次项目实战，结束前必须产出三份东西——一份项目总结文档、一份可复用的模板片段、一份评估数据集描述。前两份用于新项目复用人，第三份可以用于回测。养成这个习惯以后，你做过的每一个项目，都在为后面的项目铺路。面试官在问token数量时，他真正在探测的其实是这种习惯。那些有积累的人，任何一次对实践的追问都能接住，因为他不是临时抱佛脚做了个Demo，而是长久保持着稳定输出的节奏。段子能火是因为幽默，现实里能拿二面，靠的是作品。5.3 烧token的正确姿势最后分享一个我个人的观察。在AI应用开发这条路上，我见过两类成长速度截然不同的人。一类人把精力花在反复焦虑“该学A还是学B”“现在转型来不来得及”，一年过去还在起点纠结；另一类人挑一个具体的小场景，从今天开始给模型发第一条请求，然后迭代、记录、复盘、再做下一个场景。一年之后他们的差距，不夸张地说，是两条完全不同的职业曲线。“一天烧几十个token”这句话，与其说是面试官的嘲讽，不如理解成他对所有空谈态度的一次温和提醒。大多数人停留在“知道”的层面太久了，对模型的边界、Prompt的敏感度、token成本的结构，全部停留在概念表面。你真正打开API、传一段真实的业务数据、处理一堆脏乱输入、盯着日志里跳动的token数字时，那些模糊的概念才会变成属于你的肌肉记忆。回到面试场景。面试官问出那句话时，真正想确认的其实很简单：你是真的在动手，还是在表演热情？如果你是前者，哪怕起步时一天只烧几百token，只要每段时间都在往前推进，你都值得被认真对待。如果你只是用段子里的机灵话去应付一个接一个的质疑，那就算侥幸进了二面，最终也会在更大的追问面前露馅。所以，下一次面试官再提起token的时候，别慌，也别急着抖包袱。把你这个星期烧掉的几万token、迭代过的十几版Prompt、记录着每一次成本和正确率的实验日志，一件一件摊开放在桌上。真正的好消息从来不是“明天二面”，而是你清楚地知道自己每一分热情，都转化成了拿得出手的东西。
面试官：“你一天烧几十个token也好意思面AI应用开发？”我镇定自若：“我烧的不是token，是我的热情。”面试官：“明天二面。”这个段子最近在很多技术群里传疯了，笑归笑，但仔细想想，它戳中的其实是AI应用开发求职者最真实的窘境：简历上写着“熟悉大模型应用开发”，真到了面试现场，面试官一句“你一天烧几十个token”就能把你打回原形。因为谁都清楚，这个领域的实践痕迹几乎无法伪装——你调过多少次API、迭代过几轮Prompt、跑过多少条测试数据，从你嘴里的技术细节、你拿出来的项目深度，甚至你说“成本”这两个字时的表情，全都藏不住。我把这句话视作一面照妖镜，也当成一张入场券的隐喻。今天想认真聊聊：token消耗这个指标在AI应用开发岗位面试里到底意味着什么，一个真正有底气的AI应用开发者，平时到底在“烧”什么、该“烧”什么、怎么“烧”才不白烧，以及如果你现在正打算转型或者刚起步，一周时间能做出一个什么样的Demo去接住这类灵魂拷问。1. 这个段子背后，藏着一场关于“AI应用开发”的正名1.1 面试官为什么单挑token说事先把这个岗位本身聊透。AI应用开发，和算法工程师不同，它通常不做模型训练、不碰权重和梯度，核心工作是利用成熟的LLM能力，在具体业务场景里做出真正能用的东西。拿实际任务举例：给客服做一个智能工单分类；帮法务批量摘要合同；给运营搭一个周报自动生成器；做一个能检索内部知识库的问答机器人。这类岗位面试有一个共性难题：很难通过八股题来判断候选人水平。你问“LLM的注意力机制怎么理解”，背过几天文档的人都能扯几句；你问“Transformer结构里QKV分别是什么”，培训速成班也教过。但如果你问“你上一个项目的对话平均要花多少token、有没有试过更省的结构”，一个真正做过事的人和一个只是在文档里看过的人，回答质量的差距会立刻拉开。所以面试官问“一天烧几十个token”，本质上不是嘲讽，而是一个高效的筛选动作。他是在快速探测三件事：你有没有真正动手调过模型，还是只停留在curl通一个API返回hello world的水平；你对成本敏不敏感，有没有把token当成一个工程指标来管理；你有没有面对过真实场景中的脏问题、坏数据、超长上下文，因为这些才会真正烧token。你要是只在本地用某一款开源模型玩过几次对话，没接过线上API，没批量跑过测试集，没为降本改过Prompt结构，那你确实很难接得住这句话。1.2 一天烧几十个token，到底意味着什么很多人对token数量没有体感，先把这个概念落到地上。Token是模型处理和计费的基本单位，可以粗略理解成“字词片断”，一个中文汉字大约对应1到2个token，一个英文单词大约对应1到3个token。普通一次API调用，哪怕只是简单问答，输入加输出也至少几百token开头。然后我们来算账：你说“一天烧几十个token”，这意味着什么？一次完整对话都跑不完，因为一次几百token的调用就已经超过这个量了；更不用说做一次RAG检索问答，得把用户问题、检索回来的若干条文档片段、系统Prompt全部拼进上下文，一次调用就轻松上千token；至于写一段代码让模型帮忙改成流式输出、做一次函数调用带参数返回、跑五条Case做效果对比，每次都是一两千token的成本。所以几十个token的一天，基本等于没动手。这不是省钱，是压根没有进入实践状态。说得更直接一点，一个真正在做AI应用开发的人，光是调试一个系统Prompt，在一个模型上反复试三五版，再配几组few-shot示例，半天下来烧一两万token跟喝水一样正常。我自己的经验是，认真做一个小功能模块，一天在API上烧掉几万token是最低消费，你要是开了调试日志反复跑，十万token也可能。但是这里也要说句公道话。面试官强调“烧得多”，并不真的指望你把公司预算当柴火烧。他真正想看到的是：你不仅烧得多，而且每一分token都烧得有目的、有产出。每天只调几十次API但都在记录对比结果、迭代改进方案的人，和一天盲目重试几百次但从不总结的人，后者才是在烧钱，前者才是把token当研究经费。1.3 面试官真正想听的不是“我烧了多少”，而是“我用它解决了什么”把这个问题翻译一下，面试官的潜台词其实是：你烧了这么多token，烧出了什么名堂？最差的回应就是段子里那种抖机灵——“我烧的是热情”。段子里能换到二面是因为幽默，现实里只有这一句没有作品兜底的话，就是把自己往火坑里推。稍微好一点的回应，是直接把自己的实践过程摊开来讲：“这周我在调一个用于工单分类的Prompt。一开始让模型直接判断工单类型，准确率只有65%，后来我加了三个few-shot示例并把分类体系从12类压缩到7类，准确率到了82%。中间大概迭代了十几版Prompt，烧了大概五万token。每次改动我都保留了输入输出快照，最后还有两千多条测试集用来评估。”这段话的信息量完全不一样。面试官能在几秒钟内判断出：这个人懂Prompt对输出质量的影响；知道分类体系设计本身也会影响效果；有量化评估的习惯；有版本管理的意识；最关键的，他对token消耗有感知，知道一次排障大概要多少成本。“烧了多少”只是门槛，“烧出了什么”才是分水岭。所以这篇文章想帮大家做的事很明确：把关于token的实践细节彻底搞懂，把简历上那些虚词换成经得起盘问的真东西。2. 想不被这个问题问倒，先搞懂AI应用开发的核心能力模型2.1 AI应用开发不等于调接口每次刷到“LLM API调用教程”，底下都会有人问：“这不就是调个接口吗？有什么好学的？”说这话的人，大概没做过一个真正要上线的AI应用。接口调用只是最外层的一毫米，往深了走，AI应用开发是一套完整的能力栈。拆开来看，至少要具备五个层次的能力。第一层是Prompt工程。这是门槛最低但水最深的一块。不是会写“你是一个智能助手”就叫Prompt设计。真实场景里你得学会结构化指令、设置角色约束、给few-shot示例、控制输出格式、处理模型幻觉、设计思维链引导。举个例子，同样是让模型抽取合同中的付款条款，直接提问和给出“已知干扰项-抽取规则-输出模板-边界说明”四段式指令，效果差异会大到让你怀疑是不是换了模型。第二层是RAG（检索增强生成）的设计与落地。企业私有知识、实时资讯、长文档问答，这些场景下微调不现实，只能靠检索把相关信息塞进上下文。这里面每一步都是坑：文档怎么切块、块大小多少合适、Embedding模型怎么选、检索回来TopK取多少、相关性阈值怎么定、上下文超长了怎么压缩。第三层是Agent与工具调用。现在AI应用已经很少停留在“一问一答”了，很多需求要求模型自主决定调用哪些工具、以什么参数调用。比如一个日程助手，面对“说明天下午三点和客户开会”这句指令，需要模型从文本中抽取出时间、地点、参与人，决定调日历接口还是查通讯录，并在参数缺失时追问。这背后涉及Function Calling的Schema设计、意图判定的Prompt策略、多轮对话中的状态管理。第四层是效果评估。这是多数自学开发者最忽视的一环，也是面试官最爱追问的一环。你凭什么说你的Prompt比别人的好？你的RAG检索准确率有多少？面对回答质量方差极大的LLM，你靠什么来保障业务稳定？这就需要建立评估集、设定评测维度、跑批量对比、量化指标。Mechanical的活，但不过这一关，你永远只能说自己“感觉效果好”。第五层是成本与性能工程。这部分直接呼应开头那个段子。缓存怎么设计、模型选大还是选小、复杂任务怎么分流、超长上下文怎么截断、流式输出怎么落地、并发下的延迟怎么优化，这些能力直接决定了AI应用能不能真正放进业务里跑起来。把这五层能力装进脑子里，再回头看面试官那句“一天烧几十个token”，你就会发现他要验证的远远不止“你有没有调API”，而是你在这五个层面有没有真实项目的肌肉记忆。2.2 token是开发者与模型对话的“货币”把token这个概念再往深里讲一点。很多教程把它解释成“计费单位”就结束了，但用过一段时间就会发现，token其实是开发者与模型对话时的“资源预算”，是你每一轮实验的单位成本，也是你方案设计时的一个约束变量。举个例子就清楚了。假设你要做一个会议纪要摘要工具，系统Prompt里有角色设定、要处理的会议记录的格式说明、输出模板、还有指令细节，光这个系统Prompt可能就400token。来一段5000字的中文会议记录，大约是4000到5000token。模型输出的纪要，假设写得比较详细，又是1000多token。那么单次会议纪要处理一次，消耗大约6000token。假设每天业务侧要处理300场会议，一天光这一个场景就是180万token。同一个小功能，如果你把系统Prompt精简到250token、输出模板压缩到800token、并对输入做“只保留正文核心段落”的预处理，单次消耗可能降到3500token，一天的消耗直接砍半。这就是为什么面试官会把token挂在嘴边。一个没有真实做过项目的人，会以为AI应用开发就是选一个最聪明的模型然后往死里调；一个做过生产级项目的人，开口谈的第一件事永远是：这个场景下，模型能力、上下文长度、成本、延迟这四个变量怎么平衡。再补充一个很多人不知道的细节：不同模型架构下，同样一段中文消耗的token数量并不完全相同。原因在于各家的分词器词表设计不一样，英文好的模型处理中文时可能切得更碎，导致同样内容token数偏高。所以严格来说，做成本对比时不能光看单价，还要用同一段真实业务文本去测出各家实际的token消耗量，再乘单价算总账。这个细节能在面试时讲出来，立刻就跟只会背价格表的人拉开差距。2.3 面试官用token做筛选的潜台词把前面这些信息综合起来，面试官问token消耗的潜台词其实可以拆成三层。第一层：他害怕招进来一个只会“调参型开发”的人。这类人简历写得天花乱坠，但遇到真实生产环境里问题就直接抓瞎。调接口谁都会，能在一堆文档里把API串起来、做完容错、写好评估、控好成本，才是一个应用开发者的真正价值。第二层：他在意思维习惯。一个开口就是“我烧了几万token”的人，潜意识里已经把模型调用当成需要管理预算的工程行为；一个对token毫无概念的人，大概率对成本、性能、资源消耗这些工程要素也缺乏敏感度。第三层：他在测试你对自己的项目有多投入。AI应用开发有个很现实的特点：没有真实项目的持续试错，你不可能积累出“这个Prompt模板在这个场景会失效”“长文本分段要避开表格”“日期解析用正则比让模型抽更稳”这类碎片但极重要的实战直觉。而这些直觉的养成，恰恰就体现在token的消耗量级上。聊到这里你会发现，token这个话题根本不是一个成本会计问题，它是一把衡量开发者“真实实践深度”的尺子。尺子背后的刻度，就是你的项目经验。3. 用一周烧出底气：一个可谈可演示的AI应用Demo实操3.1 选题：一个让面试官眼前一亮的真实场景说再多理论，不如亲手跑一遍。如果你现在准备面试AI应用开发岗，又不确定自己的实践量能不能扛住拷问，我的建议很明确：花一周时间，认认真真做一个垂直场景的AI应用Demo，然后把整个过程中的关键决策记录下来。一周时间足够，前提是选题别铺太大。选题有一个核心原则：选一个边界清晰、能被你完整掌控的窄场景，不选“做一个全能AI助手”这种无底洞。我推荐的方向，是那些已经存在明确痛点、又不至于涉及过多复杂系统的场景。拿我实际带过的一个模拟项目举例。某团队的运营人员每天要处理近两百封用户反馈邮件，需要人工判断每封邮件属于“投诉”“咨询”“建议”“退订”哪一类，还要识别紧急程度并提取关键词。这是一个再典型不过的AI应用场景：任务边界清晰、有分类体系可设计、有历史数据可模拟、效果可以被量化评估。你可以用同样的思路找自己的场景：合同关键条款抽取，简历初筛打分，售后工单自动分派，市场竞品动态摘要，产品的用户评价情感分析。这些场景的共性是什么？业务边界清晰，不需要对接太复杂的外部系统，产出可以被简单验证。相比之下，如果你一上来就想做一个“企业级智能客服”，又要多轮对话、又要知识库问答、又要转人工策略、还要对接工单系统，那一周时间光是梳理需求都不够，Demo做出来也只能是表面功夫，经不起面试官追一句：“这个客服的意图识别是怎么做的？错误分类你们怎么兜底？”3.2 搭建环境与选择模型把环境搭建这部分尽量压缩到半天内完成，别在这上面耗时间。强烈推荐直接用成熟LLM服务提供商的API，不推荐自己部署开源模型。原因很现实：这一周你的目标是把“应用开发”能力跑通，而不是把时间花在运维GPU和模型量化上。本地部署一个几B的小模型，虽然token零成本，但效果可能不够有说服力，而且光调试环境就可能吃掉两天时间，得不偿失。模型选择上，优先选当前主流的能力较强的商用模型API，一个关键原因是：面试沟通时对方大概率熟悉这套生态，你的项目细节他能快速理解。至于具体选哪家，我不在这里点名，原则是看你主要处理的是中文文本还是英文文本、上下文长度需求、以及API的稳定性。如果条件允许，可以在项目里同时对比两到三个模型在你自己数据集上的表现，这一手在面试时非常加分，因为“会做技术选型”是应用开发者的核心素养之一。环境结构可以很轻：一个Python脚本、一套依赖库、一个文件夹管理数据和输出。不要为了做一个Demo就上个重框架，那只会让你陷入“配环境两小时、写业务两分钟”的泥潭。3.3 Prompt迭代与RAG接入环境就绪后，开始做核心环节。注意，做这个环节时一定要穿上“评估”这件盔甲，否则你就是在裸奔。第一步，准备数据。模仿真实场景造200封邮件样本，分布在四类里，覆盖常见说法变体：有长篇大论的投诉、有一句话的退订、有带情绪词的咨询、有提了一堆建议的反馈。把这批邮件按7:3切成开发集和测试集。开发集用来做Prompt迭代，测试集最后跑一次做效果验收。第二步，写第一版Prompt。别急着一步到位，就用最直观的写法：告诉模型做什么分类、输出什么格式、有哪些分类。跑完十封开发集邮件，你会发现大量问题：分类边界不清晰导致投诉和咨询经常混淆、模型输出格式不听话、某些邮件被强行塞进不合适的类别。把这些问题记录成一个问题清单。第三步，针对问题迭代Prompt。你会发现自己在不断烧token，而且这种烧法是有价值的。给Prompt加few-shot示例，每条邮件附上正确的分类结果和简短的分类依据；给分类体系补边界说明，比如“只有在用户明确要求退款或补偿时才视为投诉”；给输出格式加JSON约束；给模型加一条“不确定时输出unknown，不要强行归类”的安全兜底。每改一版，跑十到二十条开发集邮件，记录正确数量。这个过程你会亲眼看到正确率从70%爬到85%以上，这就是token燃烧的意义。如果你选的是知识库问答类场景，在这个阶段还要把RAG链路搭起来。文档切块时注意块大小：切太大了检索粒度粗、噪声多，切太小了上下文割裂、语义不全。我自己的经验是先按400到600字切块、带50字重叠，再用这个基线跑一轮评估，根据检索命中情况再调整。还有一个小技巧：给每个块生成一句话摘要作为检索元数据，召回相关性会明显提升，这个细节花不了多少token，但面试时讲出来很显功力。3.4 用token日志证明你“烧”得有价值这一步很多自学开发者完全不会做，但恰恰是面试叙事里最能打的部分：给整个Demo建立一个token消耗日志。具体做法很简单：每跑一次Prompt，就把输入token数、输出token数、模型型号、版本号、对应哪条数据、跑完后的效果指标，一行一行记录到一张表里。比如你可以建一个CSV，列名为：时间、场景、Prompt版本、模型、输入token、输出token、单条成本、是否正确。跑完一百条数据，这张表就是一个完整的实验记录。千万别小看这个动作。一周后你手上会多出两样别人没有的东西：第一，一张token消耗模型表。你能清楚地告诉面试官：我的系统单次调用平均消耗多少token、成本是多少、相比初版降了多少。这种颗粒度的成本认知，直接回应了“你一天烧几十个token”这类问题。第二，一组Prompt迭代曲线。你能拿出“V1准确率70%、V2准确率78%、V3准确率83%、V4加了few-shot后到86%”的演进过程。面试官立刻会意识到，你不仅做了一个Demo，还建立了一套评估和改进方法论。这才是“烧token”烧出的真金。附上一点代码示例，帮大家理解日志记录的思路。实际开发中你在调用API的封装函数里顺手加一段日志逻辑即可：import csv import time LOG_FILE = "token_log.csv" fields = ["time", "scene", "prompt_version", "model", "input_token", "output_token", "cost", "is_correct"] def log_token_usage(scene, prompt_version, model, info, is_correct): # info 里包含 API 返回的 usage 字段 input_token = info["prompt_tokens"] output_token = info["completion_tokens"] # 根据模型单价换算成本，这里只写伪代码逻辑 cost = (input_token / 1000) * INPUT_RATE + (output_token / 1000) * OUTPUT_RATE with open(LOG_FILE, "a", newline="", encoding="utf-8") as f: writer = csv.DictWriter(f, fieldnames=fields) writer.writerow({ "time": time.strftime("%Y-%m-%d %H:%M:%S"), "scene": scene, "prompt_version": prompt_version, "model": model, "input_token": input_token, "output_token": output_token, "cost": round(cost, 4), "is_correct": is_correct, })注意，实际模型接口返回的结构各家不太一样，但一般都会包含输入的token数和输出的token数，中文文档里通常写成“输入tokens”和“输出tokens”。你把它取出来落库即可。有了这张表，后面做成本分析、实验复现都有据可依。3.5 提炼成面试叙事Demo跑完，token日志有了，效果指标有了，最后一步是把它整理成一个能在面试里讲三分钟的项目故事。很多人项目做得不错，一开口就讲得像流水账，这是极大的浪费。推荐的叙事结构是：场景痛点是什么、我做了什么技术选型、迭代过程中遇到了什么具体问题、我是怎么定位和解决的、最终效果如何、我对成本是什么感知。来一段真人口吻的示例：“我做的是一个邮件自动分类工具。运营每天要处理两百封反馈邮件，人工分拣效率低且标准不一致。我选了商用大模型API来实现，没有自己做训练。第一版Prompt很朴素，让模型按四个类别分类，开发集准确率只有70%左右，投诉和咨询经常混。后来我给Prompt加了few-shot，每条示例里包含邮件原文、分类结果、还有一句人工标注的判断理由，准确率到了78%。再后来我把分类体系里每类的判定边界写清楚了，还加了一条‘不确定就标unknown’的兜底规则，准确率到了86%。整个迭代过程我记录了token消耗，单次调用平均从最初的1800token降到1200token，因为我去掉了输出里冗余的解释部分，要求它只输出JSON和置信度。”最后再补一句你对成本的感知：“目前跑完全量测试集，两百条邮件的总成本大概在几块钱，单条成本不到几分钱，这个量级在业务上是完全可接受的。”这段话全程没有空话，没有“我认为AI是未来”这种正确的废话，面试官听到的是一个个具体的决策和指标。到这一步，你面对“一天烧几十个token也好意思面AI应用开发”这句拷问时，就有底气把token日志拍在桌上：我这一周光调试这个Demo就烧了大几万token，而且每一轮烧的结果都在表里。4. 面试现场：如何接住“token拷问”并用作品说话4.1 常见追问速查表只做一个Demo还不够，你得提前预判面试官会顺着项目往哪些方向追。基于我自己参加和模拟面试的经验，AI应用开发岗位的高频追问其实高度集中，列一个速查表供参考。追问方向面试官真正想知道建议的应对素材为什么选这个模型/A PI你有没有做技术选型，还是随手拿了个最火的对比过两三个模型的提取准确率、成本、延迟你的Prompt是怎么设计的你有没有方法论，还是全靠感觉讲清楚从V1到V3的迭代逻辑、few-shot的设计依据怎么评估效果你有没有量化意识讲开发集和测试集的划分、正确率/召回率的计算方式怎么控制成本你对生产环境有没有概念讲token日志、Prompt压缩、缓存策略、模型分级遇到模型输出不听话怎么办你有没有异常处理经验讲格式强制、JSON修复、重试机制、兜底规则RAG相关的检索不准你对检索链路有没有实操理解讲切块大小、重叠、Embedding选择、TopK调参过程如果业务量扩大10倍你有没有工程化思维讲并发处理、批量调用、限流、异步队列这张表直接拿去用，每个方向都对应你项目里一个可以展开讲的具体细节。面试前自己对着表过一遍，每个问题准备一个两分钟的小故事。4.2 两类错误回应 vs 正确回应面试现场听到token质疑时，人的应激反应往往分两类，都容易踩坑。第一类：不自信型。“是是是我确实用得不多，我还在学习阶段，希望进公司多积累。”这种回应等于主动缴械。确实经验不足没关系，但你不能在没有任何实践证据的情况下直接认怂，面试官会怀疑你的自驱力和抗压能力。正确做法是把话题扭向你能控制的部分：“我这个周刚做了一个Demo，大概烧了几万token，这里面每一步我都记了实验日志，比如……”用的事实重新定义自己的“使用量级”。第二类：防御型。“烧得多不代表能力强，token多只是说明API调得频繁，真正的设计能力不能这么衡量。”这句话道理没错，但听起来像在狡辩。尤其当面试官只是想开个话题，你接一记硬怼，气氛直接凝固。正确做法是先笑着认下这个梗：“哈哈被您看穿了，不过我确实有个项目可以给您演示一下，这个项目里我对token消耗做过完整的记录……”然后直接展示。这里最关键的技巧叫“接梗但不接刀”。段子里那种幽默回应在职场上可以用，但必须用作品做支撑。你可以幽默开场，但不能只有幽默。接到问题后五秒内转到自己的项目叙事上，让面试官顺着你的节奏走。4.3 避坑清单：从简历到演示结合我之前踩过的坑，再来一份AI应用开发求职避坑清单。这些细节很少被写进面经，但每一件都在真实面试里决定过成败。简历上不要写“精通Prompt Engineering”。这句话在面试官眼里约等于什么都没写。改成“设计了一套基于few-shot的分类Prompt，将准确率从70%提升到86%”，信息量完全不同。不要只演示“能跑通”的Demo。面试官对顺利运行的demo早免疫了，他想听的是你在开发过程中遇到什么阻碍、怎么解决的。把token日志里那些“改坏了”“准确率反而下降”的记录留下，这比完美顺利更能证明你的真实参与度。不要在面试时临时打开一个没准备好的笔记本环境。环境可能出状况、网络可能波动、依赖可能要重新装，这些在高压下一旦卡壳非常减分。准备两套备案：录好的演示视频，以及一份带结果的截图文档。不要忽视对基础概念的准确表述。面试官随口问你“RAG里Retriever和Generator分别负责什么”，你不能答得含糊其辞。能独立完成Demo的人不应该栽在这些基础概念上，但紧张状态下确实容易嘴瓢，面试前花一小时把核心概念用自己话复述一遍，不亏。5. 热情之外，AI应用开发者的长期主义5.1 用最小代价保持手感段子里那句“我烧的不是token，是我的热情”能火，是因为它某种程度上是真话。这个领域太吃手感了，隔两周不碰API，很多细节就会开始模糊：某个模型的输出风格变了、新的工具链生态出来了、Prompt写法在另一个模型上不work了，这些感知只能靠持续实践维持。但我不建议为了保持手感无脑烧钱。更可持续的方式是建立一套策略组合：主力场景用一个足够强的商用API去跑真实小项目，日常试错用价格优势明显或免费的模型，需要对比验证时再交替调用。另外很多平台会提供免费试用额度，新用户额度薅起来也够玩一阵。关键是形成“带着问题烧token”的习惯：每次调用前先写下想验证什么，跑完立刻记录结论，这样的token烧得最少、长进最快。5.2 把每次实践沉淀成可复用的资产做AI应用开发有个容易被忽略的复利效应：你每一次实践留下的Prompt模板、评估数据集、token成本基线、踩坑笔记，都是可以反复使用的资产。再做一个新场景时，把上次积累的模板拿出来改一改，首版效果可能就比从零开始强不少。我现在给自己定了一条硬规矩：任何一次项目实战，结束前必须产出三份东西——一份项目总结文档、一份可复用的模板片段、一份评估数据集描述。前两份用于新项目复用人，第三份可以用于回测。养成这个习惯以后，你做过的每一个项目，都在为后面的项目铺路。面试官在问token数量时，他真正在探测的其实是这种习惯。那些有积累的人，任何一次对实践的追问都能接住，因为他不是临时抱佛脚做了个Demo，而是长久保持着稳定输出的节奏。段子能火是因为幽默，现实里能拿二面，靠的是作品。5.3 烧token的正确姿势最后分享一个我个人的观察。在AI应用开发这条路上，我见过两类成长速度截然不同的人。一类人把精力花在反复焦虑“该学A还是学B”“现在转型来不来得及”，一年过去还在起点纠结；另一类人挑一个具体的小场景，从今天开始给模型发第一条请求，然后迭代、记录、复盘、再做下一个场景。一年之后他们的差距，不夸张地说，是两条完全不同的职业曲线。“一天烧几十个token”这句话，与其说是面试官的嘲讽，不如理解成他对所有空谈态度的一次温和提醒。大多数人停留在“知道”的层面太久了，对模型的边界、Prompt的敏感度、token成本的结构，全部停留在概念表面。你真正打开API、传一段真实的业务数据、处理一堆脏乱输入、盯着日志里跳动的token数字时，那些模糊的概念才会变成属于你的肌肉记忆。回到面试场景。面试官问出那句话时，真正想确认的其实很简单：你是真的在动手，还是在表演热情？如果你是前者，哪怕起步时一天只烧几百token，只要每段时间都在往前推进，你都值得被认真对待。如果你只是用段子里的机灵话去应付一个接一个的质疑，那就算侥幸进了二面，最终也会在更大的追问面前露馅。所以，下一次面试官再提起token的时候，别慌，也别急着抖包袱。把你这个星期烧掉的几万token、迭代过的十几版Prompt、记录着每一次成本和正确率的实验日志，一件一件摊开放在桌上。真正的好消息从来不是“明天二面”，而是你清楚地知道自己每一分热情，都转化成了拿得出手的东西。