上周有个朋友跑来问我说不舍得买AI编程工具会员但又不想纯靠手写代码憋得慌问我有没有“既要又要”的方案。我直接把我最近一直在用的免费组合甩给了他Cursor 免费版写业务代码Qodo 免费版生成单元测试SiliconFlow 免费额度跑模型推理。这套组合我已经实打实跑了好几个小项目代码质量没比付费方案差到哪里去关键是每个月在开发工具上的支出几乎为零。这篇文章就把这套免费 AI IDE 工作流完整拆开讲适合独立开发者、学生党、小团队甚至刚入门编程的新手参考。很多人觉得 AI 编程工具不给钱就不好用其实不是工具不好用而是没有把免费额度重新组合起来。Cursor 免费版负责日常写业务逻辑和补全代码Qodo 免费版在后台盯着你的代码自动生成测试用例SiliconFlow 的免费模型额度则承担了那些需要“跑一下模型”的辅助任务比如给代码解释、做测试结果分析、生成接口示例数据。三者分工明确之后我基本戒掉了看到支付页就焦虑的习惯反而发现免费额度用得好的话效率完全够用。1. 整套组合的核心思路为什么三个工具拼在一起才顺手1.1 解决的核心问题付费订阅重复覆盖先算一笔账。如果单独买一个 AI 编程助手会员一个月一两百块不止再买一个代码测试生成工具又得加一笔最后再专门去买模型 API 的额度又是一笔钱。更麻烦的是这些工具的功能还有重叠钱花了不少实际用到的功能可能只有三分之一。我搭这套免费组合的思路很简单把“写代码”“查代码”“跑模型”三件事拆开分别用三个在各自领域做得最细的免费产品而不是用一个全家桶把三件事全包了。Cursor 免费版在代码编辑、补全、多文件理解上的体验已经接近付费工具拿它来写业务代码最合适。Qodo 免费版的核心能力是“自动为你的代码生成单元测试”它本来就擅长这件事让它专门做测试生成和代码审查比在聊天框里让 AI 随便写几个断言靠谱得多。SiliconFlow 提供免费调用额度适合跑那些模型推理类的任务比如给一大段日志做摘要、把测试失败信息翻译成通俗解释、批量生成测试数据。三者各管一段免费额度的利用率反而比订阅制还高。1.2 三人分工Cursor 写、Qodo 测、SiliconFlow 跑这套组合看着像三个工具拼在一起实际上它们在一条流水线上各有明确位置。Cursor 在最前端承担交互最多、最需要响应速度的编码工作。你在编辑器里描述需求、调整代码、重构逻辑它负责实时补全和对话。Qodo 在第二环专注于你的代码变更自动分析函数、类、模块之间的依赖关系然后生成带断言的单元测试跑一遍就能暴露大部分逻辑漏洞。SiliconFlow 则更像一个可编程的“模型引擎”凡是需要批量跑模型、调 API 的场景都可以交给它因为它按 token 计费并且有免费额度不用一次性搭一套本地推理环境。举个实际场景我写一个订单折扣计算函数Cursor 帮我补完了函数体和边界判断Qodo 自动生成了一份 pytest 测试文件里面有正常折扣、满减、非法参数、类型错误这些用例我跑完 pytest 看到两个失败用例随手把失败日志粘给 SiliconFlow 的免费模型让它帮我分析是精度问题还是逻辑短路。整个过程里我没有打开第三个编辑器也没有切换订阅平台只是几个窗口之间接力。1.3 免费额度的真实边界别把免费工具当无限资源免费额度从来不是“无限制免费用”但只要掌握好节奏完全不影响开发。Cursor 免费版有几个明显限制请求次数有限高峰期可能进入慢速模式对超长上下文的支持很有限一些高级代码审查功能被锁定。Qodo 免费版有每日或每月的请求上限团队协作功能受限。SiliconFlow 免费额度同样有调用频率和模型范围限制。我在实际使用中总结出来的应对方法很简单把额度用在刀刃上。Cursor 的对话次数留给“改复杂逻辑”和“重构代码”这种高价值场景简单补全交给它的免费补全功能不额外消耗对话额度。Qodo 的免费额度每天够生成几十次测试文件单文件生成通常用不到整额度的十分之一等攒到一天结束时再批量生成一次就行。SiliconFlow 的免费模型适合跑短文本任务长文档分析尽量拆段避免一次消耗过多 token 触发限流。只要按照“短任务、分批跑、降噪输入”的原则三个工具的免费额度实际上是可以长期稳定使用的。2. 三个工具的核心能力拆解与关键细节2.1 Cursor 免费版写业务代码时的实用设置Cursor 本质上是一个以 AI 能力为中心的代码编辑器免费版保留了很多核心体验。我最常用的是它的 Tab 补全和 CtrlK 交互式编辑。前者在你写代码时给出下一段预测后者可以对选中的代码进行重构、补注释、改逻辑。免费版在会话次数上有限制但纯补全功能是不怎么消耗会话额度的所以我平时让补全一直开着把有限的对话次数留给真正需要“理解上下文”的任务。设置上有几个值得注意的细节。我在用户设置里关闭了“自动收集代码片段用于训练”之类的选项不是因为这个功能一定不好而是从隐私习惯上不希望每个文件都被拿去分析。模型选择上免费版可选的模型有限但足够应付日常开发。如果需要在本地跑一些辅助模型配合 Cursor可以把 API 地址指向 SiliconFlow 提供的 OpenAI 兼容接口这样就能在 Cursor 里调用云端免费模型来分担部分对话压力相当于多了一条额度备用通道。还有一个实用技巧是善用 Rules 文件。你可以为项目新建一个规则文件在里面写明项目的代码风格、技术栈、禁止使用的模式Cursor 在补全和对话时会更贴合你的工程规范减少“写出来的代码风格不像你自己写的”这种感觉。这个习惯一旦建立后面 Qodo 生成测试时也会因为代码结构更规范而少很多报错。2.2 Qodo 免费版从自动补测试到代码审查Qodo 的核心不是“聊天生成代码”而是“对代码进行深度理解后生成可运行的测试”。我用的最多的是它的 IDE 插件形式。安装之后打开一个 Python 文件选中一个函数或类右键选 Qodo 生成测试它会在几秒内分析函数签名和内部逻辑生成一个带完整断言的文件。这个文件不是摆设直接放在项目里跑 pytest 就能出结果。Qodo 的免费版有几个明显特征需要注意。第一它生成的测试依赖现有的测试框架识别如果项目里没有 pytest 环境需要先把环境装好否则生成的测试文件会被 IDE 忽略。第二它生成的用例偏“正向逻辑”居多对边界条件的覆盖率不一定特别高尤其是复杂的异常分支需要自己补充一两条用例。第三免费版的生成次数确实有限但我实际用下来每天的正常开发强度足够用不需要刻意节省。除了生成测试Qodo 还提供变更审查功能。它会在你提交代码前自动审查你改动过的文件标记出潜在的 bug、安全问题、无效断言。我把这个功能当成一个“低成本 code review 机器人”代码写完之后先让它过一遍再交给人工检查明显能拦截掉不少低级错误。对于个人项目和没预算请人审查的小团队来说这个价值很高。2.3 SiliconFlow 免费额度模型不在本地也能“跑代码”SiliconFlow 是一个模型推理服务平台提供很多开源模型的 API同时提供免费调用额度。它的关键优势是对开发者友好接口兼容 OpenAI 格式提供了 Python SDK 和 API 文档几行代码就能调用。我把这一层理解为“AI 工具箱”需要模型推理能力时不用自己买显卡不用本地部署模型只用拿 API key 请求远程服务。SiliconFlow 的免费额度具体覆盖哪些模型会随平台策略变化但基本思路是部分模型提供免费调用次数或每日免费 token 配额超过之后按正常价格计费。我的习惯是新建一个专门用于免费模型的 API Key然后把默认参数调成短输出、低温度、有限长度确保每次请求尽量只消耗必要 token。它不用于跑重型生成任务更多是把模型当成一个“快速分析工具”用。在配合 Cursor 和 Qodo 时SiliconFlow 承担了三类工作。一是测试信息的解读把 pytest 的报错信息转换成通俗的自然语言二是接口数据的批量生成比如造一批假订单数据、测试密钥、边界参数三是帮我给代码生成注释或文档减少手工写说明的时间。这些任务都不要求极高的生成质量免费模型足够不会浪费更贵的额度。提示SiliconFlow 这类平台通常有控制台查看每日用量建议把免费额度的使用情况做成一个仪表盘习惯每周扫一眼避免某天突然跑光。3. 实操过程从零搭一套免费 AI IDE 开发流水线3.1 第一步环境准备与账号开通开始之前需要准备三个账号Cursor 账号、Qodo 账号、SiliconFlow 账号。Cursor 下载安装后用邮箱注册就能进入免费版。Qodo 可以安装 IDE 插件或浏览器扩展注册后绑定 GitHub 账号即可。SiliconFlow 注册后在控制台创建一个 API Key并把它保存到环境变量或配置文件中后续会用到。我用的是 Python 3.10 和 pytest 环境示例项目是一个简单的订单服务。项目结构大概这样demo_order/ ├── app/ │ ├── __init__.py │ ├── discount.py │ └── order.py └── tests/ └── test_discount.py先安装必要依赖pip install pytest requests这一步没有复杂操作但有一个小提醒Qodo 生成测试时默认检测当前项目使用的测试框架如果项目里同时存在 pytest 和 unittest 的配置它可能生成两种风格的测试文件。建议在项目根目录先建一个pytest.ini明确指定框架[pytest] testpaths tests python_files test_*.py这样 Qodo 生成时会更稳定地落到 pytest 风格。3.2 第二步在 Cursor 中写一段业务代码在 Cursor 里打开项目创建一个函数calculate_discount它接收商品单价、购买数量和优惠码三个参数返回折扣后的总价。我在文件顶部写一行注释描述需求然后让 Cursor 根据 Tab 补全继续写下去。# 根据原价、数量和优惠码计算应付金额 # 优惠码规则 # - SAVE10: 整单 9 折 # - SAVE20: 整单 8 折 # - 无优惠码原价合计 def calculate_discount(price: float, quantity: int, promo_code: str ) - float: if price 0 or quantity 0: raise ValueError(price and quantity must be positive) subtotal price * quantity if promo_code SAVE10: return round(subtotal * 0.9, 2) elif promo_code SAVE20: return round(subtotal * 0.8, 2) elif promo_code : return round(subtotal, 2) else: raise ValueError(funknown promo code: {promo_code})Cursor 在这里做了几件事补齐了类型注解、生成了异常处理逻辑、根据注释自动填充打折规则。我只需要检查和微调整体花了两分钟。这个函数如果用手敲大概五到十分钟但核心收益不是省时间而是它生成的边界判断比我通常第一版写的更完整。然后我写了一个模拟接口调用from fastapi import FastAPI, HTTPException from pydantic import BaseModel from app.discount import calculate_discount app FastAPI() class DiscountRequest(BaseModel): price: float quantity: int promo_code: str class DiscountResponse(BaseModel): total: float app.post(/discount, response_modelDiscountResponse) def get_discount(req: DiscountRequest): try: total calculate_discount(req.price, req.quantity, req.promo_code) return DiscountResponse(totaltotal) except ValueError as e: raise HTTPException(status_code400, detailstr(e))这里 Cursor 在补全时自动引入了 FastAPI 和 Pydantic且错误处理直接对接 HTTP 状态码整体代码风格符合常用做法。3.3 第三步用 Qodo 给业务代码生成单元测试业务函数写完下一步是让 Qodo 生成对应的测试。在 Cursor 的编辑器里打开discount.py选中calculate_discount函数体点击 Qodo 插件图标选择“Generate tests”。几秒后Qodo 会生成一段测试代码并写入新文件。下面是类似它生成的测试内容import pytest from app.discount import calculate_discount def test_calculate_discount_save10(): assert calculate_discount(100.0, 1, SAVE10) 90.0 def test_calculate_discount_save20(): assert calculate_discount(100.0, 2, SAVE20) 160.0 def test_calculate_discount_no_promo(): assert calculate_discount(50.0, 3, ) 150.0 def test_calculate_discount_invalid_price(): with pytest.raises(ValueError): calculate_discount(-1.0, 1, SAVE10) def test_calculate_discount_invalid_quantity(): with pytest.raises(ValueError): calculate_discount(100.0, 0, SAVE10)这些断言都是基于函数逻辑推导的包含了合法参数和非法参数两大类。我把生成的文件保存到tests/test_discount.py然后运行python -m pytest tests/test_discount.py -v输出显示五个用例全部通过。这个动作的实际意义是我只写了一遍业务逻辑Qodo 立刻把这些逻辑转成了可重复验证的断言之后任何一次改动只要跑一遍测试就能知道有没有破坏原有行为。如果生成测试后发现运行失败最常见的原因是依赖路径问题。Qodo 生成的 import 路径可能基于 IDE 的解释器路径如果项目根目录不在PYTHONPATH里运行时会报 ModuleNotFoundError这时候在pytest.ini中配置pythonpath .即可解决。3.4 第四步用 SiliconFlow 跑模型辅助任务现在业务代码和测试都齐了我再让 SiliconFlow 的免费模型介入扮演一个“测试结果分析助手”。写一个 Python 脚本把 pytest 的运行输出读取出来发送给模型让它生成简短的分析报告。先在环境变量里配置 API Keyexport SILICONFLOW_API_KEYsk-xxx写一个调用脚本ai_analyze.pyimport os import subprocess import json import requests API_KEY os.getenv(SILICONFLOW_API_KEY) API_URL https://api.siliconflow.cn/v1/chat/completions def run_pytest(): result subprocess.run( [python, -m, pytest, tests/test_discount.py, -v], capture_outputTrue, textTrue, ) return result.stdout def analyze_with_model(text: str) - str: headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: deepseek-ai/DeepSeek-V3, # 以实际可用免费模型为准 messages: [ { role: system, content: 你是一个测试分析助手请用简洁的中文总结测试运行结果指出失败用例的可能原因。, }, {role: user, content: f以下是 pytest 运行输出\n{text}}, ], max_tokens: 500, temperature: 0.3, } resp requests.post(API_URL, headersheaders, datajson.dumps(payload), timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: pytest_output run_pytest() print(analyze_with_model(pytest_output[:2000]))这里我把 pytest 输出截断为前 2000 字符避免 token 消耗过大。实测下来模型能准确总结出“5 个用例全部通过”或“有一个用例失败可能与负价格校验有关”之类的内容。用 SiliconFlow 的好处是可以批量处理这些“模型琐事”。比如我项目里有十几份 pytest 输出要分析写个循环调用免费模型跑一遍就能得到一个统一的分析摘要。这个任务如果手动读日志非常费神让模型跑一遍十分钟能省下来。3.5 第五步把三端串成一条完整流程到这里三个工具各自的能力已经展示过了。真正让它们发挥一加一大于二效果的是把它们串成一个自动化循环。我每次修改业务逻辑流程就是这样的在 Cursor 中改代码 → 运行 pytest → 如果失败复制失败信息到 ai_analyze.py 分析 → 根据模型结果回 Cursor 修改 → 再次运行 pytest → 全通过后让 Qodo 再审查一次变更。这样一个循环跑下来我基本不需要在聊天框里反复问“哪里错了”而是直接让工具链告诉我哪里错了、为什么错、怎么改。代码质量的控制不再依赖我的细心程度而是靠“补全、测试、分析”三层防线。对于小项目来说这个流程完全可以当正式开发流程用而且全部基于免费额度。我的实践体会是如果只是偶尔用其中一个工具体验很一般。但把 Cursor 的交互、Qodo 的测试、SiliconFlow 的模型分析组合起来之后每个工具的免费额度都会被高效利用反而不会再出现“额度没用完就到期”这种浪费现象。4. 实战中的常见问题与排查技巧4.1 Cursor 免费版额度不够用时怎么办我用 Cursor 免费版时最常遇到的是“对话额度用尽”和“慢速模式”。慢速模式下 Tab 补全和对话响应都会变慢但并不是完全不可用。如果遇到额度耗尽我的处理是先切换到本地模型或者换一个问题更窄的提示词减少对话轮次。如果确实需要大量 AI 辅助就把任务拆小一次只让 Cursor 改一个函数这样每个对话请求返回的信息更准确也不会很快把额度烧光。另外一个备用方案是把 Cursor 的外部模型地址配置成 SiliconFlow 的 OpenAI 兼容接口这样它能用 SiliconFlow 免费额度承担部分请求。配置方式是在 Cursor 的模型设置里添加自定义 OpenAI 兼容端点填入 API Key 和对应模型名然后选择合适的模型作为备用。需要注意的是免费模型的能力有上限遇到特别复杂的重构任务可能表现一般但作为额度兜底完全够用。提示Cursor 免费版在慢速模式下不建议做大型重构否则你会被延迟耗光耐心。把困难任务留到额度恢复后再做日常小改动随手完成。4.2 Qodo 生成的测试为什么不按预期运行根据我使用 Qodo 的经验它生成的测试有几种典型失败场景。第一种是路径导入问题。ModuleNotFoundError最常见解决方式是检查项目根目录是否在 Python 路径下推荐在pytest.ini中配置[pytest] pythonpath .第二种是类型不匹配。比如 Qodo 给Decimal类型的字段生成与float相等性断言运行时会直接失败因为Decimal(90.0) 90.0返回的是 False。修复方式是把断言改成Decimal(90.00)或者用pytest.approx。第三种是测试与业务函数强耦合。如果业务代码里依赖外部环境变量或数据库连接Qodo 生成的测试在本地跑时拿不到这些依赖就会失败。这类问题的标准做法是重构业务函数把外部依赖作为参数传进去或者在测试中添加 Mock。Qodo 自己也会在生成时尝试分析外部依赖但复杂的场景它同样会漏。我的习惯是Qodo 生成测试后先人工扫一遍测试文件重点看断言数值是否符合业务逻辑预期然后运行一次。如果失败优先检查 import 和外部依赖而不是直接否定测试生成能力。大多数失败都是环境问题不是测试逻辑问题。4.3 SiliconFlow 调用报错与限流使用 SiliconFlow 免费模型时我遇到最多的报错是 HTTP 401/403 和模型不存在。401/403 通常是 API Key 填错或没有开通对应模型的权限去控制台检查 Key 是否有效。模型不存在则是因为免费模型列表是动态变化的我之前写的deepseek-ai/DeepSeek-V3可能在某天就变成了付费专用模型需要去控制台查看当前可用的免费模型列表。另外容易踩坑的是超时与上下文长度。免费模型对max_tokens有上限比如有的模型限制单次输出最多 2000 token如果请求设置的max_tokens超过这个值会报错。还有一种情况是输入 prompt 太长超过模型的上下文窗口。我的排查习惯是先把传给模型的内容截断到 1000 字左右看是否恢复正常。免费额度被限流时请求会返回 429。这时不要立即重试等几秒或几分钟再发。如果任务需要频繁调用建议把调用代码里加上简单的退避重试逻辑或者把任务拆成多个批次避免瞬间把额度用完。4.4 三个工具衔接时的常见遗漏在组合使用过程中三个工具的衔接处经常出现小问题。比如 Cursor 生成的文件没有保存Qodo 无法读取最新代码Qodo 生成的测试文件没有放在tests目录SiliconFlow 脚本里的 API Key 还留着上一份环境变量。这些看起来都不难解决但出了问题很耗时间。我的做法是把环境变量统一放进项目根目录的.env文件用python-dotenv加载然后写一个Makefile定义几个常用目标test: python -m pytest tests -v analyze: python ai_analyze.py flow: test analyze这样每次跑流程只需要执行make flow不用手动记一串命令。Cursor、Qodo、SiliconFlow 之间的衔接通过文件名和约定目录来完成不会因为人工操作导致状态不一致。提示三个工具之间的数据流尽量用“文件”而不是“聊天记录”传递。文件可复现、可追踪、可自动化聊天记录一旦关掉窗口就全没了。把 ai_analyze.py 和 tests 目录当成核心契约谁改动了契约跑一遍测试就能暴露。5. 额外补充这套组合还能怎么扩展上述这套免费组合如果只是用于订单服务有点浪费了。实际上把它迁移到其他技术栈和场景也有很好的效果。我用同样流程试过几个前端项目Cursor 生成 React 组件Qodo 对纯函数生成 Jest 测试SiliconFlow 免费模型分析 TypeScript 编译错误信息效果同样稳定。核心逻辑不变交互界面用 Cursor逻辑校验交给 Qodo批量文本分析委派给 SiliconFlow。扩展时需要注意模型能力的选择。C、Go 等语言 Qodo 同样支持测试生成但生成的测试代码风格略有差异SiliconFlow 上的模型擅长不同语言的能力也不同如果用某个模型分析 Rust 编译错误效果不好换一个模型试试就行。免费额度本身就是用来试错的不用太纠结一次选对。另外有人可能想引入更多类似工具进入这个流水线。我的经验是不要贪多工具链里每一个新成员都要优化现有效率而不是增加花活。当前这套三个免费工具的组合在轻量级项目上已经达到了“低预算 高覆盖 可自动化”的平衡比盲目买一堆付费工具更容易坚持下来。还有一个值得推荐的扩展方向是让模型参与代码评审的“反向检查”。每个月抽一天让 SiliconFlow 免费模型把项目里的核心测试报告读一遍然后生成一份代码维护建议例如哪些函数缺少异常处理、哪些断言覆盖不足、哪些模块测试运行时间过长。这有点像一个低配但可持续的自动化质检投入的只是免费额度回报是对项目健康度的长期观察。我个人的感受是这套组合最大的价值不在于省了多少钱而在于它改变了我的编码习惯。过去写完代码总想直接提交反正还有人工测试兜底。现在写完函数Qodo 的测试就在旁边盯着我会下意识多思考一步边界条件跑完测试后随手让模型分析一遍输出又等于多了一层代码审查。最终代码不是被某一次“大力度审查”救下来的而是在每天几十次的自动检查中慢慢变得扎实。建议你也按这个节奏试试从一个小函数开始让免费工具形成你自己的流水线。