企业官网建设流程全解析

去年年底我给自己的开发工具支出做了一次彻底盘点，发现每个月花在 AI 编码助手上的钱已经高得离谱，于是动了做个“免费替代方案”的念头。free-claude-code 这个项目就是那段时间的产物——名字里的 claude 只是一个代号，你可以把它理解成任何提供免费额度的大模型编码服务。整个项目的目标很直白：在不掏钱的前提下，把免费额度组织成一条能持续产出代码、能断点续传、能复盘优化的工程流水线。如果你也是个人开发者、学生，或者在小团队里负责预算有限的内部工具开发，这篇文章应该能让你少走不少弯路。

我需要先说清楚：这不是什么破解、逆向或者卡平台 Bug 的项目，恰恰相反，我做这个项目的核心收获是——在资源受限的条件下，如何用工程手段把一个不稳定的免费服务变成称职的编码队友。整个工作流包含请求封装、会话管理、额度统计、prompt 模板沉淀几个模块，全部代码和配置都可以跟着文章搭出来。下面我按真实的演进顺序拆开讲。

1. 项目动机：为什么我盯上了 C 服务的免费额度

1.1 上游能力在升级，免费额度的含金量已经变了

很多人对免费模型有偏见，包括以前的我。早期用过的免费档模型，生成代码确实停留在“能跑但没法看”的水平：变量命名随机，边界处理缺失，生成出来的函数不返工没法合入。但这个判断放到现在已经不成立了。主流平台给免费用户的模型版本在代码理解、指令遵循这些能力上有了非常明显的进步，尤其擅长脚手架代码、正则表达式、测试用例这类重复劳动。所以我后来才发现，真正卡住免费额度使用体验的不是模型能力，而是使用方式。

我给自己做了一次数据统计，在一个月里用免费额度完成了 23 个编码小任务，包括日志清洗脚本、接口字段转换、测试数据构造、CI 配置修复。平均每个任务消耗 1.2 万到 4 万 token，最终的账单是零。这个数字说明一个问题：如果你愿意把大任务切成中等大小的块，免费额度在个人开发场景下的可用性远超预期。核心变量有两个，一是你愿不愿意等待，二是有没有一套工具来兜住请求、会话和额度这些容易失控的环节。

1.2 我给自己定下的四条边界

做这个项目之前，我先立了几个规矩，避免“免费”两个字把人带偏。第一条，不碰任何形式的破解、逆向、伪造请求，也不做规则之外的批量注册。第二条，只用官方渠道明确提供的免费额度，不走来路不明的第三方中转。第三条，免费额度只用在自己的非生产环境，凡是涉及客户数据的代码，一概不交给免费档处理。第四条，所有对话记录和脚本输出都留档，方便事后审计。边界清晰有个好处，就是遇到诱惑时不需要反复纠结，直接跳过。

很多人一听“免费”就往灰色地带想，其实完全没必要。平台给的免费额度本质上是一个试用入口，你把它当成一个有限预算的正式项目来运营，反而能锻炼出更好的成本控制能力。这也是 free-claude-code 对我最大的价值：它逼我在资源紧缺的情况下重新审视自己的编码流程，哪些步骤是必要的，哪些是在浪费额度。经过这一个月的“精打细算”，再回头看付费工作流里那些大手大脚的调用方式，我会觉得非常心疼。

1.3 项目最初的样子

一开始我其实没有写任何代码，只是把日常用到的提问模板和问答结果记在一个纯文本笔记里，连续记了两周。后来问题来了：笔记内容越来越多，想找一条历史记录要翻很久。于是我把笔记升级成小工程，逐步加入请求封装、会话管理、用量统计三个模块。这个项目最重要的就是prompts/目录，里面只有几个 Markdown 文件，但它们是整个工作流的灵魂：

free-claude-code/ ├── prompts/ │ ├── system_base.md │ ├── fix_bug.md │ └── refactor.md ├── src/ │ ├── client.py # 请求封装 │ ├── session.py # 会话保存与恢复 │ └── usage.py # 额度统计 ├── scripts/ │ └── run_agent.py # 命令行入口 ├── logs/ │ └── sessions/ # 对话 JSONL 存档 └── README.md

这个布局对长期维护帮助很大。prompts 单独放，是因为在免费额度模式下，prompt 的质量对结果的影响非常直接——一个写得好的系统提示词，能省掉好几轮纠错对话。session 和 usage 两个模块是后来补的，它们解决了一个非常实际的问题：免费额度会话容易断开，断开之后怎么快速恢复。没有这两个模块之前，我经历过一次会话过期导致整个任务重来，那感觉非常糟糕。

2. 免费额度的真实账本：渠道、限速和够用度

2.1 我花了一个月做的渠道对照

在动手搭建工具链之前，我先做了一轮渠道调研，把市面上能接触到的免费入口都试了一遍。结论是，同样是“免费”，不同入口的体验差距非常大。我实际测下来主要分三类：网页版聊天、官方开发平台的测试额度、第三方聚合 API。如果你也在考虑这条路，这张表可以帮你快速对号入座：

我个人把主要精力放在第二类，官方开发平台的测试额度。原因是它可以脚本化，能嵌入到我后面的命令行工具里，每次请求的 token 消耗也能通过接口返回精确跟踪。网页版聊天只适合做“一次性咨询”，因为它和自动化工作流是两套完全不同的东西。很多人忽略了这一点：免费额度的真正价值，不在于它能回答多少问题，而在于它能不能被编排进你现有的工程流程里。

2.2 限速到底卡在哪里

免费额度的“限速”体验，是第一次动手的人最不适应的部分。用实测数据说话：某个平台免费档的请求频率大约在每 10 到 30 秒一次，超了就会返回限流错误。刚开始我不懂退避，写了个小脚本一口气发了 5 个请求，结果第 3 个开始全部被拒，白白浪费了大把时间。后来我在请求模块里加了一个自适应延时：第一次失败等 2 秒，第二次失败等 4 秒，以此类推，最多等到 30 秒。这个改动把请求成功率从 60% 提升到接近 100%。

限速不只在请求频率层面，还体现在生成速度上。免费档模型生成 token 的速度通常比付费档低一个档位，实测下来大约每秒 20 到 60 个 token。什么概念？生成一份 500 行代码的初稿，一次输出大约 7000 token，按这个速度要等 2 到 6 分钟。这个等待时间很多人受不了，但其实可以利用起来。我每次发起大任务后就切去打测试用例或者看文档，把同步等待变成并行任务，整体效率几乎没有下降。

2.3 "免费"背后的隐性成本

免费额度有两笔隐性成本，第一笔是时间成本，上面已经说了。第二笔更隐蔽，是返工成本。因为免费档对上下文长度的控制更严格，你一旦在对话里堆太多内容，模型容易“忘记”早先的约定，导致代码前后不一致，这时候得花额外轮次去纠正。我的做法是控制单次任务的目标大小：一个对话只解决一个明确定义的问题，宁可多开几个会话，也不要在一个会话里塞五个需求。这条规则后来被验证得越来越对。

隐性成本还包括“额度清零时间点不一致”。不同的免费入口，额度重置周期、过期时间都不一样，有的按自然月重置，有的从领取起 30 天，还有的按小时滚动。我为此专门写了一个 usage.py 来记录每次请求的用量和剩余额度，每周自动汇总。你不做统计的话，某天额度突然清零，工作流会立刻被打断。做统计的成本不高，收益却是实打实的——至少你永远不会在写到一半的时候被“额度不足”的报错惊到。

3. 把免费额度封装成一条可复用的调用流水线

3.1 技术选型：为什么是 Python 加纯 requests

我在设计之初考虑过用现成的第三方 SDK，但最终选择了 Python 标准库加 requests 自己封装一层。原因有三个。第一，SDK 通常面向完整功能，包含很多我用不到的依赖，体积大，维护成本高。第二，当时我在评估免费额度，接口随时可能调整，自己控制请求结构更容易适配。第三，纯 requests 的代码任何人拿到都能在一两分钟内读懂，方便后期改造。我知道这个选择不够“优雅”，但在资源受限的个人项目里，优雅要让位于可控性。

这里多解释一句，为什么不用更重型的异步框架。有人建议我用 asyncio 加并发来打破限速，我试过，效果非常一般，因为免费档限制的是服务端总吞吐量，不是客户端并发数。你把并发从 1 调到 10，服务端照样按固定节奏放行，反而更容易触发更严厉的惩罚机制。所以在请求层面，脚本化加健康的重试策略，比并发压榨要靠谱得多。这也是我在这个项目里反复强调的一个原则：先理解限制的本质，再决定策略。

3.2 最小可用的请求封装

核心的 client.py 我写得非常克制，只包含四个功能：构造请求头、发送请求、退避重试、解析响应。下面这段是精简后的代码，去掉了繁琐的类型检查和日志装饰，但主路径保留完整，你可以直接参考：

import time import requests BASE_URL = "https://api.example.com/v1/chat/completions" API_KEY = "sk-xxxxxxxx" def build_headers(): return { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}", } def send_once(messages, max_tokens=2048, temperature=0.3): payload = { "model": "coding-model-free", "messages": messages, "max_tokens": max_tokens, "temperature": temperature, } resp = requests.post( BASE_URL, headers=build_headers(), json=payload, timeout=120, ) return resp.status_code, resp.json() def call_with_retry(messages, max_retries=5): wait = 2 for attempt in range(max_retries): code, data = send_once(messages) if code == 200: return data["choices"][0]["message"]["content"] if code in (429, 503) and attempt < max_retries - 1: time.sleep(wait) wait = min(wait * 2, 30) continue return None

这段代码的精华在于call_with_retry里的指数退避逻辑。免费额度的限流错误集中在 429 和 503 这两个状态码，无条件重试肯定不行，间隔太短会一直撞墙，间隔太长又会拖慢整个任务。用倍增策略，在 2 到 30 秒之间自适应，是我实测下来最稳妥的方案。另一个容易被忽视的细节是超时时间。免费模型生成速度慢，超时设置 30 秒会频繁中断请求，我直接把超时拉到了 120 秒。

3.3 prompt 的固定姿势

免费额度场景下，prompt 的设计比模型能力更重要，因为一次失败的对话不仅要消耗 token，还会消耗你拿去重写的时间。我的固定姿势是“三段式”：系统提示词指定角色和约束，用户消息给出任务内容和输入数据，最后强制约束输出格式。系统提示词模板存放在prompts/system_base.md，每次请求都重新加载，保证行为一致：

你是一名经验丰富的软件工程师，侧重代码的可读性与健壮性。 在回答时遵守以下规则： 1. 先给出方案概述，再给完整代码。 2. 代码必须包含必要的错误处理与注释。 3. 不解释与任务无关的背景知识。 4. 如果输入信息不足，直接列出你需要的补充信息，而不是假设。 5. 输出代码块语言标记必须准确。

这套模板的价值，是把“如何与我协作”这个约定前置，而不是在每一轮对话里重复解释。实际使用下来，固定模板能让答案的初稿可用率提升一个档次，尤其是在“信息不足时主动提问”这条规则上，大大减少了模型瞎猜的概率。在免费额度模式下，每一次模型瞎猜都意味着额外的 token 消耗，所以我宁愿多花几分钟打磨 prompt，也不愿意多花整段额度去兜底。

3.4 从脚本到命令行的一点打磨

有了 client.py 之后，我加了一个scripts/run_agent.py作为命令行入口，支持三个参数：--prompt指定系统提示词文件，--input指定要处理的代码文件，--output指定结果输出路径。比如跑一个代码 review 任务，命令是这样的：

python scripts/run_agent.py \ --prompt prompts/system_base.md \ --input src/legacy_batch.py \ --output review.txt

这个入口本身很简单，但它解决了一个真实痛点。之前我每次都要打开网页、粘贴代码、复制回答，来回好几个动作。现在一条命令完成，结果自动落盘，不会被浏览器标签页吃掉。命令行的好处还在于可以被其他工具链调用，比如接到 Git 提交钩子里，提交代码后自动生成一份 review 意见文件。免费额度工具一旦变成命令行，它的复用率和稳定性都会有质的提升。

4. 实战复盘：用免费额度重构一段 300 行遗留代码

4.1 任务背景

我从一个模拟项目里抽了一段 300 行左右的遗留批处理脚本当试验品。这段代码的功能是：读取一批日志文件，按规则过滤字段，把需要上报的事件整理成 CSV。脚本本身能跑，但问题典型：所有逻辑堆在一个 main 函数里，没有单元测试，变量命名随意，错误处理缺失，日志文件格式稍一变就直接崩溃。

我刻意选了这样一个“不好不坏”的任务。太简单体现不出工作流价值，太复杂免费额度又顶不住压力。300 行脚本拆成三步：先把读写与过滤逻辑分离，再重写核心筛选函数，最后补测试用例。整个过程分三轮对话完成，每轮的目标边界非常清晰，这也为后面控制上下文、管理会话打下了基础。

4.2 我为什么要分三轮问，而不是一次喂完

很多人喜欢把整个需求一次塞给模型，我也这么干过，结果在免费额度场景下很快吃到亏。一次塞入 300 行代码加 500 字需求，上下文占用很大，模型在中途会出现“记忆漂移”——前面约定的命名规范，后面就不遵守了。后来我把任务拆成三轮，一轮只干一件事，每轮重新加载系统提示词，并且只附上前一轮的结论摘要，而不是重发完整对话历史。

三轮的分法如下。第一轮请模型分析函数结构和接口边界，输出一份重构方案；第二轮让模型基于方案输出重构后的核心代码；第三轮让模型根据重构代码生成测试用例。第二轮开始前，我会把第一轮的方案摘要作为上下文补丁贴在消息里，这样既省 token，又避免上下文总量触及免费档的窗口上限。

分轮问答还有一个隐藏好处：免费额度会话容易中断，如果你只用一个超长会话，中断一次就前功尽弃；拆成多个中等长度会话后，每个会话相对独立，断了一个，其他几轮的产出还能保留。这个设计是我在踩过“全量丢失”的坑之后才想清楚的，后面会仔细讲那个坑。

4.3 中间产物管理

每一轮对话的请求和响应，我都会以 JSONL 格式存到日志目录，文件名带上时间戳和任务标记。存档的价值体现在两个地方。第一，复现问题：如果某轮回答质量很差，我可以翻看完整上下文，定位是哪里的 prompt 产生了歧义。第二，迁移复用：当我要把这套免费额度的用法移植到另一个平台时，历史记录就是最好的训练素材。

下面是一段简化后的会话记录结构：

{ "task": "refactor_legacy_batch", "round": 2, "timestamp": "2025-06-11T10:24:00Z", "messages": [ {"role": "system", "content": "..."}, {"role": "user", "content": "根据上一轮方案重构核心函数..."}, {"role": "assistant", "content": "...完整代码..."} ], "usage": {"input_tokens": 1240, "output_tokens": 2080} }

注意其中的 usage 字段。免费额度最怕的就是不知道还剩多少，我在每个会话记录里都存了 token 用量，然后写了一个简单的聚合脚本，每周统计一次总消耗。这样做的好处是，当平台调整额度策略时，我能立刻算出新的预算水平还能支撑多少轮任务，而不是等到请求失败才后知后觉。

4.4 免费额度下最容易翻车的三个环节

第一个翻车点是需求描述含糊导致返工。比如我让模型“优化性能”，它很可能改成牺牲可读性的位运算实现。后来我在每轮任务末尾加了一句“如果存在一个以上合理方案，选可读性最高的那个并说明理由”，返工率明显下降。第二个翻车点是模型对自己的输出过度自信。它生成的测试数据里，日期格式和实际日志完全不一致，跑起来一片红。我的解决办法是要求它“基于我提供的样本行生成测试数据”，而不是凭空编造。

第三个翻车点最隐蔽，是免费档模型容易“偷工减料”。让它生成 10 个测试用例，它可能给你写 3 个完整的、其余 7 个用注释省略掉。我发现这个规律后，在系统提示词里强制加了“所有测试用例必须完整可运行，不允许使用注释省略”，问题就解决了。这三点都指向同一个道理：免费额度模式下，你花在 prompt 约束上的时间，最后都会从返工时里省回来。

5. 踩坑实录：五次让我差点放弃的时刻

5.1 限流错误后的退避策略，写不好就是灾难

第一次大规模使用免费额度时，我写了一个循环，试图批量让模型逐行解读一个项目的所有核心文件。循环里没有任何延时控制，结果第 3 个请求开始不断收到 429 状态码。我最初的代码在失败后立即重试，这导致服务端的限流惩罚升级，后续 20 分钟内所有请求都被拒。后来我才明白，免费额度的限流不只是请求数限制，还包括惩罚窗口——你不遵守节奏，它就把窗口拉长。

解决方案就是我们 3.2 节里提到的指数退避加最大等待时间。此外我还给退避策略加了一个小优化：如果连续三次都在同一个请求上失败，就主动放弃当前请求，回滚到对话层面，换个角度重写 prompt，而不是死磕到底。因为很多情况下限流迟迟不退，说明不是节奏问题，而是请求体量本身超出了服务端的容忍度。

5.2 会话断开导致上下文全丢，我差点崩溃

免费额度会话的稳定性确实不如付费档。我遇到的第一次严重事故是：第三轮对话进行到一半，会话已过期，再打开时历史记录全没了。虽然那一轮对话的产出本身不重要，但前面两轮的方案摘要全部丢失，整个任务被迫重新开始，浪费了两个小时。

从那以后，我开始严格执行 4.3 节的中间产物管理。经验是：每次模型返回内容后，立刻把响应文本追加到本地文件，而不是只存在 API 的响应变量里。即使后续会话真的断开，手上也有一份完整的对话记录可以手动续接。这件事带给我的教训是：把外部服务的状态当成不稳定，是工程上必须具备的基本假设。免费额度的不稳定表面上是个缺点，实际上是在训练你的防御式编程思维。

5.3 输出被截断时，"继续"两个字并不总是管用

生成超长代码时，免费档经常在接近输出上限的位置截断。我第一次遇到这种情况时，直接发一句“继续”，结果模型从开头重新生成了一段完全不相干的代码。后来我发现，更可靠的方法是让模型“从断点处继续”，前提是你得给它提供断点处最后一段文本。

我的做法是准备一个拼接工具：把 assistant 上一次输出的末尾 200 到 500 字取出来，放到新请求的用户消息里，命令模型“基于以下结尾继续输出，不重复已生成内容”。这个技巧对免费额度尤其有用，因为它在不增加上下文长度的前提下，把截断问题局部化。实测下来，继续生成的结果和原内容衔接得很自然，几乎不需要额外修补。这也再次印证了一个规律：上下文是免费额度模式下最值钱的资源。

5.4 额度清零的瞬间毫无预兆

有一次我在赶一个临时脚本，突然所有请求都返回“额度不足”的错误。我去翻配额页，才发现上个月的免费测试额度早在两天前就消耗完了，只是因为请求量小一直没被注意到。那天我不得不临时切回网页版手动问问题，效率低了一大截。

这次经历促使我写了 usage.py 里最简单也最实用的功能：每次请求成功后，从响应数据里解析剩余额度字段，低于阈值时在终端打印警告。看到警告，我就知道接下来应该降低任务规模，优先处理最重要的问题，把次要任务留到额度重置之后再继续。这个机制此后帮我避开了至少三次“干到一半被掐断”的情况。免费额度的使用，本质上就是一场对自己预算敏感度的训练。

5.5 三个教训，彼此之间是连环套

把上面几个坑串起来看，可以总结成三句话。第一，要把限流当作接口的正常反馈，而不是异常，所有重试机制都应该围绕这个假设设计。第二，外部服务的会话状态不可靠，本地落盘永远是你最后的底线。第三，任务粒度要控制得比付费档更小，因为额度断开和输出截断的恢复成本，在小任务上几乎可以忽略，在大任务上则会被无限放大。

这三句话听起来没什么了不起，但我是在连续踩了两周的坑之后才真正内化成设计原则的。如果你刚开始用免费额度搭建编码工作流，建议提前把这几条写进项目 README，哪怕现在用不上，等出问题时再回头看，能省掉很多弯路。

6. 度量与升级：什么时候该为编码助手买单

6.1 免费额度跑完前，先把这三样资产留下

免费额度迟早会用完或者到期，所以从第一天开始我就给自己定了一个规矩：所有在免费额度基础上产生的资产，必须脱离平台也能独立存活。需要留下的东西有三样。第一样是 prompt 模板库，就是prompts/目录下的几份 Markdown 文件，它们是你与模型协作的协议，换平台后微调就能复用。第二样是会话存档，其中记录了每一轮任务的提示词、输出和 token 用量，这是优化工作流的第一手数据。第三样是脚本封装，client.py、session.py、usage.py 这套代码不绑定任何特定平台的 SDK，换接口地址和鉴权方式即可适配新平台。

这三样资产一旦沉淀下来，你会发现即使免费额度彻底清零，你失去的也只是“廉价的计算资源”，而不是整套工作方法。这也是我把项目取名为 free-claude-code 的第二层意思：free 不只是免费，更指这套代码可以从特定平台上自由迁移走。工具可能过期，能力不会。

6.2 付费切换的三个信号

虽然我把免费额度用到了极致，但在三个场景出现时我会果断切换付费档。第一个信号是任务的时效性变得很重要。模型的响应速度开始明显影响排期，等待生成所花的时间已经无法用其他任务填补，就说明该付费了。第二个信号是上下文需求超出了免费档限制。当我要做的重构任务必须一次看清多个文件的关联，而免费档的窗口装不下时，强行分轮会导致代码风格割裂，返工成本反而高于订阅成本。第三个信号是稳定性要求提高。当我要用模型辅助生成生产环境使用的脚本时，不能容忍会话随时断开、输出频繁截断，付费档带来的不只是速度，还有心智负担的减轻。

我自己用免费额度跑了大约四个月后，逐渐在“效率优先于省钱”的需求上触发了第二个和第三个信号。但我没有立刻订阅，而是先做了一次两周的交叉对比：用付费档处理同样的任务，对比 token 消耗、返工率和完成时间，确认提升幅度足够明显之后才完成切换。这个验证步骤非常关键，可以避免因为“感觉慢”而冲动付费。

6.3 决定继续免费时，可以怎么把损耗降到更低

如果你暂时不打算付费，降低损耗主要有三个办法。第一个办法是压缩上下文。系统提示词只保留核心规则，删除铺垫段落；历史对话尽量用摘要而不是全文，因为免费档单次调用的 token 成本虽然为零，但上下文越大，模型的注意力越分散，返工概率越高。第二个办法是任务分块。一个复杂任务拆成五个小任务分别调用，每次调用保持输入输出清晰，避免模型跨任务记忆漂移。第三个办法是离线缓存常用代码段。把生成过、验证过的代码收集起来，建一个本地代码片段库，遇到类似需求直接复用，不用重复请求模型。

这三个办法本质上是同一件事：用本地工程手段降低对在线模型的依赖。免费额度可以帮你完成从 0 到 1 的粗稿，但从 1 到 10 的打磨应该尽可能在本地完成。这不仅省钱，也让最终代码的质量更可控，因为你已经清楚哪些部分经过验证，哪些还需要人工审查。免费额度用久了，你会发现它其实是最棒的工程激励——逼着你优化一切。

6.4 我对这个项目最终的评价

free-claude-code 没有解决所有问题，它只解决了一个被反复追问的问题：当预算为零时，我还能不能持续获得高质量的编码辅助。答案是可以，前提是你愿意把“使用模型”这件原本很随意的事，当成一个有纪律、有工具的工程来对待。免费额度看似在限制你，实际上是在帮你筛选出真正重要的任务，同时逼你打磨出一套可迁移的工作方法。现在即使预算放开，我依然会保留这套项目结构，因为它的价值从来不在省钱，而在结构化的使用方式——这是我做这个项目最大的收获。