企业官网建设流程全解析

上周有个朋友跑来问我，说不舍得买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 补全和 Ctrl+K 交互式编辑。前者在你写代码时给出下一段预测，后者可以对选中的代码进行重构、补注释、改逻辑。免费版在会话次数上有限制，但纯补全功能是不怎么消耗会话额度的，所以我平时让补全一直开着，把有限的对话次数留给真正需要“理解上下文”的任务。

设置上有几个值得注意的细节。我在用户设置里关闭了“自动收集代码片段用于训练”之类的选项，不是因为这个功能一定不好，而是从隐私习惯上不希望每个文件都被拿去分析。模型选择上，免费版可选的模型有限，但足够应付日常开发。如果需要在本地跑一些辅助模型配合 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(f"unknown 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_model=DiscountResponse) def get_discount(req: DiscountRequest): try: total = calculate_discount(req.price, req.quantity, req.promo_code) return DiscountResponse(total=total) except ValueError as e: raise HTTPException(status_code=400, detail=str(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 Key：

export SILICONFLOW_API_KEY=sk-xxx

写一个调用脚本ai_analyze.py：

import 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_output=True, text=True, ) return result.stdout def analyze_with_model(text: str) -> str: headers = { "Authorization": f"Bearer {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, headers=headers, data=json.dumps(payload), timeout=60) 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 的测试就在旁边盯着，我会下意识多思考一步边界条件；跑完测试后，随手让模型分析一遍输出，又等于多了一层代码审查。最终代码不是被某一次“大力度审查”救下来的，而是在每天几十次的自动检查中慢慢变得扎实。建议你也按这个节奏试试，从一个小函数开始，让免费工具形成你自己的流水线。