上个月某系统莫名其妙又在夜里崩了一次日志里的异常堆栈看得人一头雾水。我顺手把关键代码和堆栈塞给 Claude它五分钟内列了六个可能原因验证到第三个就找到了根因。从那天起我开始把日常编码里能交给 AI 的活儿系统过了一遍攒了一个笔记集名字就叫 free-claude-code——核心问题很简单怎么尽量不掏钱或者掏很少的钱把 Claude 这类大模型在写代码、查 bug、补测试上的价值榨干。这篇文章会把免费额度的真实边界、API 用量的省钱策略、提示词的写法、三个实战案例、开源替代路线以及生产环境的红线全部摊开讲。适合正在用 AI 辅助编程、想少花冤枉钱的开发者也适合对“AI 写代码到底靠不靠谱”半信半疑的人。有一点我先说在前面AI 写代码真正的价值不是“替你写完全部”而是把重复劳动迅速清掉把时间还给你。1. 免费写代码这件事真实边界在哪里1.1 Claude 到底能在哪些环节帮上忙先给一个简单的定位Claude 不是把整个项目替你写完的“自动程序员”它更像一个随叫随到的结对编程搭档你负责判断它负责快速输出初稿。在实际工作里我用下来最顺手的场景有这么几类从零生成功能代码例如把一段需求描述转成 Python 函数、SQL 查询或正则表达式。解释陌生代码接手老项目贴一段看不懂的代码让它逐行讲比翻文档快得多。写测试用例给一个函数它能输出正常、边界、异常三类的测试骨架。排查报错把异常堆栈、日志和周边代码贴进去让它给候选原因和验证步骤。做小重构把一个长函数拆成几个小函数或把重复逻辑抽成工具方法。这里有个容易误判的点它“快”不等于“能直接用”初稿正确率往往在七成上下剩下三成需要人力修正。但关键是原来这些活儿从零写可能要半小时甚至半天现在它十秒给初稿你把时间花在验证和修改上效率提升非常明显。1.2 免费和准免费的真实边界很多人一听免费就以为能无限白嫖。实际情况大概分三层。第一层是聊天产品自带的人工额度。注册后一般有免费对话次数用完了得等下一时段或者充值。这种额度适合日常问问题、写小脚本但没办法做大批量任务。第二层是开发者 API 的试用点数。注册开发者账户后通常会有一次性赠送按 token 消耗有有效期。拿它来跑真实项目一两百个小任务没问题但想把它当长期生产力是不现实的。第三层其实是很多人的隐藏选项本地跑开源模型。不花 API 的钱只花电费和硬件折旧。效果和云端旗舰模型有差距但应付简单代码生成、测试骨架完全够用这部分我在第五章展开。我做了一个简单的任务对照表帮你看清楚哪些任务适合放在免费额度里任务类型是否建议用免费额度原因生成一次性脚本、SQL、正则强烈建议任务小、验收标准明确失败重来成本低写测试骨架和边界用例强烈建议输出结构性强适合大模型发挥解释陌生代码建议消耗 token 少收益高重构大模块不建议改动面大容易“改崩”人工兜底成本高排查复杂生产 bug谨慎只适合喂“切片后的最小线索”别整库上传说到底免费额度更像是一笔体验金帮你判断它值不值得花钱。真正理想的工作流是免费额度做小验证本地开源模型兜底实在涉及复杂分析再考虑付费或按量计费。2. API 免费额度的用量策略与成本感知2.1 搞懂 token 是怎么烧掉的先说基础概念。大模型计费不是按字数而是按 token——可以粗略理解成模型切分文本的最小单位。一个 token 在英文里大概对应三四个字符中文因为一个汉字经常就占一个到两个 token所以同一段话用中文写消耗往往比英文更高一点。所有对话的输入和输出都会被折算成 token你贴的代码、模型生成的内容每一轮对话双方的历史记录都在持续烧 token。我见过不少朋友说“额度没用几次就没了”基本都是同一个原因上下文太长。一个常见的坏习惯是把整个文件甚至整个目录往对话框里拖。一个八百行的 Python 文件按常规 token 密度算光贴进去就可能消耗大几千 token。来回几轮免费额度就见了底。2.2 我把免费额度花在了这三类事上我自己的使用经验免费额度最值得花在三类有明确验收结果的事上。第一工具函数补全。比如我手头有个内部系统的导出模块函数名和字段映射都有了缺的是具体实现。把这个函数签名、字段说明、异常要求写成一段简洁的提示词让它补全。输出几乎一次成功只改了一个日期格式的细节。第二异常排查的“第二意见”。遇到无从下手的诡异 bug把关键堆栈和五到十行相关代码切片传进去让它列出候选原因和验证方法。它不是权威但它能提供你平时想不到的角度。第三测试用例大纲。把核心函数贴进去要求它按正常、边界、异常三类给出测试用例名称和输入样例。这不等于测试写完了但能帮你把脑力劳动从“想”变成“确认”。我大致估算过这三类任务单个一般在 3000 到 8000 token 之间。如果按赠送额度算做完二三十个这样的小任务问题不大。反过来如果你拿它做开放式头脑风暴、让它一次写一个完整模块、或者反复贴同一个大文件几千 token 的额度可能聊几轮就没了。典型任务输入 token 量级输出 token 量级适合免费额度补全一个函数含说明1k-3k0.5k-2k非常合适解释一段陌生代码0.5k-2k1k-2k非常合适让 AI 写完整小模块3k-5k2k-4k看情况反复调试大文件5k3k不建议2.3 控制上下文长度额度立刻耐用一倍控制上下文的思路很简单尽量减少对话中的“历史包袱”。我有三个亲测很管用的做法。第一喂代码前先裁剪。只贴相关函数不贴整个文件如果是报错场景只贴关键栈帧前面那些通用堆栈可以删掉。第二把需求写成清单而不是叙述。例如把“我希望你写一个把列表去重并且保留顺序的方法”这种口语化需求改成“输入 list输出去重后的 list要求保持原顺序不允许用第三方库”。清单能让模型更快抓住要点也少说废话。第三一轮对话解决一个问题。不要在一段对话里又让它分析代码又让它改写又让它写测试因为后续每一轮都会把前面的来回重新计费。我通常是单独开多个会话各干各的这样每一段的 token 消耗都干净可控。提示如果你发现某个任务的输出质量明显下降先不用怀疑模型排查一下是不是上下文太长、早期信息被“挤到边缘”了。这时候重新开一个会话把关键信息压缩后重新输入经常能恢复质量。3. 提示词怎么写从“能用”到“可运行”3.1 为什么 AI 总给你“伪代码”很多人吐槽 AI 写的代码是“伪代码”——看着逻辑很清楚一跑就报错导入缺包、API 版本不对、边界没处理。事实上这不全是模型的问题更多是提示词里没有给出可运行所需的约束。看两个对照。一个模糊提示是“帮我写个读取 Excel 的函数。”另一个精确提示是“用 Python 和 openpyxl 写一个函数入参是文件路径和 sheet 名返回按行组织的 list第一行是表头文件不存在时抛出带路径的 FileNotFoundError单元格值为空时返回空字符串。”后面这种把语言、库、入参出参、错误处理和空值策略都说清楚了。前者你拿到手大概率要改半天甚至它选的库跟你项目里已有的都不一样装依赖都要折腾。后者拿到手几乎可以直接用。差别不在于“AI 变强了”而在于你把验收标准提前写清楚了。3.2 一套可以直接抄的提示词模板我自己的常用模板长这样你可以直接复制改改角色你是一个有多年经验的后端开发习惯写简洁、可维护、带类型标注的代码不写多余注释。 任务目标完成下面这个函数使其通过所有描述中的验收条件。 输入材料 [在这里粘贴函数签名、现有代码、依赖声明或错误堆栈] 验收条件 1. 语言/框架是[写清楚] 2. 入参是[写清楚] 3. 出参是[写清楚] 4. 必须处理这些边界情况[写清楚] 5. 不允许引入新的第三方依赖除非我明确要求。 6. 除必要改动外不要重构与需求无关的代码。 输出格式 只输出完整代码块不要解释如果有需要我注意的风险放在代码块后面的“注意事项”小节。这个模板的核心就是把“验收条件”显式化。模型非常擅长在明确约束下工作真正怕的是你要它猜。3.3 迭代式对话先方案再代码后测试还有一个很多人忽视的用法不要一上来就让它输出完整代码尤其当任务本身很复杂时。先让它给一个实现思路或方案你花两分钟看一下靠不靠谱确认了再让它落代码。打个比方你让它“把单体服务的用户模块拆成微服务”它要是直接给三百行代码基本全是白写。但如果你先问“给出用户模块拆分的推荐边界、数据同步方案、迁移步骤”它给出的方案你还能判断一下好坏然后再决定要不要往深走。对代码类任务我一般这样分步第一轮提供需求摘要让它列实现方案和关键文件改动点第二轮确认方案后让它按方案写具体代码第三轮代码能跑之后再单独提“为这段代码补测试用例”。这样一轮聚焦一件事不仅消耗的 token 更少更重要的是每一步你都看得到、控得住。AI 帮你干活但你始终是那个拍板的人。4. 三个实战片段补函数、追 bug、写测试4.1 片段一给内部系统补一个导出功能背景是某内部管理系统的报表模块老项目用 Python 写的代码风格偏过程式里面有个导出函数留了 TODO一直没人补全。需求是把一批业务数据导出成 Excel字段映射确定但日期要统一成“YYYY-MM-DD HH:mm:ss”格式。我把函数签名、字段映射字典、公司内部已有的 Excel 工具类都贴进去提示词里明确写了用项目里已有的导出工具类不要新引第三方依赖日期字段做格式统一空字段写空字符串。第一版输出基本可用但有一个细节没处理日期字段里混着“2024-01-01T00:00:00”这种带 T 的 ISO 格式。我在验收条件里没写这条它自然就漏了。我追问了一句“把带 T 的 ISO 格式也统一处理掉”它追加了一行解析逻辑问题和需求都解决了。这个案例典型的收益不是“AI 写代码快”而是“你不必从零描述整个业务”。所有上下文已经在代码里了它只需要做填充。你要付出的主要是定义边界条件的时间但这部分本来就该花。4.2 片段二用异常堆栈定位一个偶发崩溃另一件事是某跨平台系统在夜间跑批时偶尔报错一天可能挂一两次第二天又自己好了。初步排查怀疑是某个数据源偶发返回空值但代码里已经做了非空判断理论上不会踩空指针。我把异常堆栈前几层、相关函数的十几行代码、日志里失败时间点附近的环境信息一起放进提示词让它别急着给结论先列出可能的根因并按照概率排序每个原因后附一条验证方法。它给出的候选包括空值校验被中间层悄悄吞掉、时区导致日期边界落在“昨天/今天”之间、线程并发下共享变量被覆盖、第三方 SDK 的失败重试返回值形态不一致。我们按列表验证第三个就查出了真凶一个公共实例在并发下被覆盖导致夜间批处理共用同一个状态对象偶发错乱。这个案例里 AI 的贡献不是直接告诉你答案而是帮你把“可能的原因空间”压缩了。原来解决问题靠脑内枚举现在它帮你枚举你只需要做验证。这种配合方式比让它直接给修复代码靠谱得多。4.3 片段三为公共函数补齐单元测试第三个片段更常规。某团队有个公共函数负责把配置字符串解析成结构体逻辑不复杂但分支特别多各种分隔符组合让人头疼。团队一直没补全测试后来在某次重构里差点把兼容逻辑改坏才意识到要补。我让模型根据函数源码生成测试用例要求按“正常输入、边界输入、非法输入”三类列出用例并在提示词里强调“不要 mock 这个函数自身专注纯输入输出”。它生成了一个 pytest 文件包含二十多个用例覆盖了空字符串、缺失字段、多余字段、异常分隔符等场景。我没直接全盘照收把其中两个用例的参数改成了更贴近真实业务的值加了一个“超大输入”的压测用例跑完直接提交。这次补全让团队的回归安全感提升了一个台阶至少没人再敢随手改解析逻辑了。模型在这类任务里的优势很明显它不是“会写测试”而是“见过足够多测试”。它生成的用例名、断言写法都是社区通行风格比新手自己憋半天写出来的要完整。但最终业务语义对不对仍然需要人判定。5. 备用路线没有账号或额度见底时怎么办5.1 本地开源模型能顶大半场如果你的账号还没申请下来或者免费额度已经烧完了先别急。很多代码任务根本不需要云端旗舰模型本地跑一个开源模型就够了。这里我不具体点名某个模型或工具只说大致方案一个七八 B 到十几 B 参数量的开源模型配上推理框架跑在本机就已经能完成上面说的“补函数、生成测试骨架、解释代码”这些任务。有人会担心本地模型效果差。实事求是地讲和云端旗舰模型差距是有的主要体现在长上下文理解、复杂多文件改动、高难度排错这几个方向。但如果是单文件内的代码生成、正则、SQL 拼接、测试用例八成以上场景都能打得动。5.2 一套最基本的本地运行流程本地跑 AI 代码辅助其实思路很简单# 1. 下载一个开源模型文件建议选 7B-13B 级别、带量化版本的 # 2. 运行本地推理服务把模型加载起来监听本机端口 # 3. 用 curl 或 Python 脚本发送补全请求返回结果直接贴进编辑器具体到硬件我建议至少准备 8G 以上显存16G 内存会更从容。显存不够就用量化版本效果略降但能用。实在没有独立显卡CPU 也能跑只是速度慢适合任务量不大的场景。这套玩法的最大优势是隐私代码不出本机公司内部敏感数据可以放心喂。缺点也很明显本地模型会偶尔答非所问对超长输入支持有限所以当你发现它开始“胡言乱语”时最简单的方法是换个问法或者把输入切成更小的块。5.3 什么时候切回云端更划算我的经验是如果输入输出都集中在几个小文件里本地模型已经足够但任务需要“站在整个项目的视角”——比如理解模块之间的调用关系、分析跨服务的数据流——这时候云端大模型的长上下文优势就体现出来了。还有一类场景适合云端需要快速迭代的人设和风格。本地模型往往需要反复调提示词才稳定而云端旗舰模型对复杂指令的理解更准。省下的调试时间有时候比省下的 API 费用更值钱。所以我把这两者定位成“互补关系”而不是“替代关系”。6. 生产环境的底线审查、隐私与输出污染6.1 AI 代码的“一本正经胡说八道”AI 生成的代码有一个很隐蔽的坑表面上看完全合理但函数名、类名、第三方库的用法可能是它编出来的或者记忆里某个旧版本的写法。尤其当你让它生成一些冷门库的用法时它可能给你造一个不存在的方法名而且描述得头头是道。所以凡是要合入生产分支的 AI 代码我的底线是先编译再跑测试然后过一遍依赖声明。特别是它如果“引用”了某个第三方包我一定去官方文档确认版本和 API看看这个包是不是真的存在、这个版本是不是真的支持。6.2 私有代码脱敏后再喂如果你用的是云端服务一定要有隐私意识。不要把带着真实库名、表名、业务敏感字段的代码直接贴进去。我自己的做法是凡是涉及内部业务逻辑的代码先做一层脱敏——把类名替换成 A、B、C表名换成 table_1注释里的监控地址、账号信息全部删掉再传给模型。这不是说云端服务一定不安全而是从工程伦理上你不该把公司机密交给外部服务去处理。尤其当你只是用它做“通用的代码模式分析”时脱敏对准确性影响很小但对风险控制帮助极大。6.3 合入分支前必须做的事最后给一份我沉淀下来的检查清单供团队参考编译并跑通相关测试不满足的立刻改。检查新增依赖的许可证避免 AI 从网上“借鉴”来一段 GPL 代码。Code Review 时标注“AI 生成”请同事重点检查边界和异常路径。尽量小步合入不要让一次 PR 混入上百行来历不明的 AI 代码。对关键路径代码要求 AI 先解释设计再贴代码。我见过最离谱的一次是有人让 AI 写了个网络请求封装结果它把一个测试辅助库当成生产依赖引进来了编译能过但运维环境里根本没有那个库。这类问题不是 AI 独有的但 AI 会放大“代码看起来没问题”的错觉所以审查流程必须前置不能省。回到 free-claude-code 这个笔记集的核心免费的不是额度是一整套不交智商税的使用方法。我自己用下来最大的体会是AI 写代码最爽的不是“它帮我把全部代码写完了”而是把那些重复、机械、没有创造性的活儿迅速清掉把时间还给我去思考架构和业务边界。另外还有一个小技巧想分享给你每次让 AI 生成完代码顺手再追一句“这段代码有什么潜在问题请列出三点”。这个习惯帮我提前挡掉了不少小坑。希望这套经验也能让你在 AI 辅助编程的路上少交点学费多拿回一点时间。