项目标题叫“AI写代码尝试1”，听起来像随手建的文件夹名，但这是我给自己安排的一次正经开发实验。这段时间“AI写代码”这个话题被聊得火热，热搜词翻来覆去就是那几个：免费的AI编程写代码、哪个AI写代码厉害、哪个AI写代码最好。与其刷别人发的测评和演示，不如自己花一个下午，拿一个真实的小需求，从头到尾让AI把代码写出来，跑起来，再回头复盘整个流程。这篇博文就是那次尝试的记录，从选免费工具、写提示词、跑代码、修bug到给AI“写代码能力”打分，全部拆开讲清楚。适合对AI编程感兴趣但还没真正上手过的开发者，也适合想找一个免费工具来提效的普通程序员。

1. 为什么突然想做这个尝试

1.1 一台电脑、一个下午、一个明确的小目标

先说背景。我日常写业务代码，大量时间花在重复劳动上：新增接口、调整页面样式、拼装查询条件。这类活儿技术含量不高，但特别占时间，写完了也没什么成就感。所以当AI写代码在讨论区刷屏时，我第一反应不是兴奋，而是怀疑：它到底能帮我干多少活？还是说只能生成一段看起来像样、实际跑不起来的废代码？

光看别人演示没用，演示视频里都是挑成功案例给你看。我决定自己跑一遍，而且跑一个真实需求。实验目标非常具体：用AI辅助写一个“带自动归档的待办事项命令行工具”。为什么选这个项目？第一，需求足够小，一个下午能完成；第二，它包含添加待办、列表展示、标记完成、删除、文件持久化、命令行参数解析这些常见开发动作，能比较完整地反映AI写代码的真实水平；第三，它是本地命令行工具，跑得起来就是跑得起来，做不了假，也没法像网页项目那样用样式糊弄过去。

我不推荐一上来就拿复杂业务系统当试验田。原因很简单：一旦报错，你根本分不清是需求没说清楚、AI理解偏了、还是技术方案本身有问题。小项目的优势在于变量可控，能集中在“理解需求、生成代码、修复错误”这三个环节上观察AI的表现。这一条实验边界比选哪个工具更重要，先想明白，后面才不会乱。

1.2 怎么定义“AI写代码成功”

很多人对AI写代码的期待是：我丢一句话过去，它直接扔回一个能上线的产品。这种期待太高了，真这么干一定会失望。我在实验前就把“成功”拆成了三个可验收的指标，避免到最后“感觉还行”又说不出哪里好。

第一个指标是能运行。生成出来的代码必须在我本机跑起来，不是“逻辑看起来正确”。第二个指标是可靠。加一条待办、标记完成、自动归档，这些核心流程不能出现严重bug。第三个指标是可理解。AI生成的代码我必须每一段都能看懂、能解释，因为最后维护这个工具的人是我，如果代码像天书一样，哪怕它跑得通，我也会选择重写。

这三个指标看着朴素，执行起来会发现它们对应着一个关键方法论：AI写代码不是全自动流水线，而是“人提需求、AI实现、人验收”的协作。你把验收标准定为“代码能跑”，那你得到的就是一段能跑的代码；你把验收标准定为“我看得懂、改得动、跑得稳”，你才会认真Review AI给的每一行。我把AI当成一个写代码速度很快、但偶尔会犯错的初级同事，我的工作不是夸它，而是验收它。

1.3 这次尝试不打算做什么

动手之前，我还给自己划了三条“不做”的边界。第一，不做工具排位赛。我不会只用十分钟就给所有AI工具打分排名，那太浅了，我只想搞清楚一两个工具在我的使用场景下到底合不合手。第二，不做完整工程重构。我这个小工具不会用到复杂的架构设计，也不会过度设计，实验目的是验证AI能不能把一个明确的小需求落地，而不是考验它能承受多复杂的系统。第三，不追求一次成功。AI写代码大概率会出错，我的目标不是让它第一轮就完美，而是看它能不能在对话中通过修复、迭代把事情做完。这个预期管理救了我，后面几次报错时我都没有想砸键盘。

2. 免费AI编程工具怎么选不踩坑

2.1 先把市面上的免费选项盘一遍

既然热搜词里全是“免费的AI编程写代码”，我第一反应也是先找免费工具。现在可免费试用的选项其实不少，有些是长期免费额度，有些是注册就送一定的请求次数。我这次实验主要盘了这么几款：GitHub Copilot的免费试用、Cursor免费版、Windsurf免费版、Codeium，以及通义灵码、文心快码这类以IDE插件形态提供的免费助手。

先说清楚，我不接推广，以下全是个人实测感受。而且这行迭代太快，我这个月的测试结论下个月就可能过时，大家重点看思路，别把工具排行榜当成永久答案。我简单梳理一下各家特点：GitHub Copilot的免费试用适合在VS Code里做行级补全，写样板代码很顺；Cursor免费版自带聊天面板，可以直接对着整个项目文件夹提问，也能直接改文件；Windsurf和Codeium这两年的免费力度都不错，适合习惯在编辑器里用插件的人；通义灵码和文心快码对中文描述的理解相对友好，安装之后能在IDE里边写边问。

我当时把关心的几个维度拉了一张表，方便对比：

2.2 我筛选工具的四个硬指标

面对这么多选择，我不可能每个都深度测一遍，所以给自己定了四个硬指标，先过滤掉一批。第一，免费额度必须够我完成“生成一个完整小工具”的任务，不是只够试几分钟就提示升级。有些工具嘴上说免费，实际用两下就锁住，这种直接就走了。第二，必须能处理项目级上下文，不能只会单文件对话。我要的是让AI理解项目的整体结构，能够修改项目里已有的多个文件，而不是每次都扔给我一段和上下文脱节的代码。第三，对中文描述的理解要过关，最好能生成中文注释。我平时写代码注释用中文，这个习惯得让工具兼容。第四，操作门槛不能太高，最好能落在VS Code或独立App里，不用折腾复杂的环境配置。

这四个硬指标一过，我留下了两个主测对象：Cursor免费版和通义灵码。Cursor在项目级上下文和全流程对话上明显更强，适合今天的完整实验；通义灵码作为IDE插件，日常写代码时挂在旁边，用来补函数、写注释、解释报错非常顺手。剩下的工具不是不好，而是它们更适合“日常加速”，不太适合我今天这种“从零到一跑通一个项目”的实验场景。

2.3 最终选了谁、备胎又是谁

正式实验时我用的主力是Cursor免费版，备胎是通义灵码。这个组合有一层实际考虑：主线任务用主力工具做全流程验证，万一主力出现额度限制或服务不稳定，备胎还能保证我不付费的情况下把实验做完。

C之所以选它当主力，展开再多说一句：它的项目文件读取能力比较强，我可以在对话框里直接说“帮我看看当前项目有哪些文件”“这个报错来自哪里”，它就真的会去翻文件、定位问题。这个体验非常接近和一个坐在旁边的程序员交流。而通义灵码更像是我的“兜底裁判”：当Cursor给的结果出现分歧，或者它修的bug我不放心，我就会把报错信息再贴给通义灵码，看看另一个AI会给出什么解释。两个工具交叉验证，比自己死磕高效很多。

2.4 免费额度到底够不够用

这是很多人在选免费工具时最关心的问题。我的体感是：完成这类小项目，免费档基本够用。整个实验过程中，我大概进行了四轮完整对话，中间穿插了若干次子问题，没有遇到额度被锁的情况。但要注意，免费版的体验确实会受高峰期影响，比如某个时段对话响应明显变慢，偶尔会提示稍后重试。如果你只是日常写代码时补个函数、问个报错，免费档完全没问题；如果你要在一天之内让AI生成大量文件、不停重构，那就得考虑付费档或者错峰使用。

我也观察到一个现象：免费版和付费版的差异主要集中在上下文长度、并发请求数和部分高级功能上，单次生成代码的基础能力并没有天壤之别。对新手来说，先用免费版跑通一个项目，比直接上付费更合理。省下来的钱，与其说是买功能，不如说是买稳定和更少等待。

3. 实操全记录：从需求描述到能跑的代码

3.1 第一步：把人话翻译成AI能懂的提示词

实验目标明确后，我在Cursor里新建了一个空文件夹，写下第一版提示词：

请用Python写一个命令行待办事项工具，功能包括：添加待办、列出所有待办、标记某个待办为已完成、删除待办。待办数据要存到本地JSON文件里。还要有一个自动归档功能：超过7天且已完成的事项自动进入archived列表。

这段提示词看起来简单，但有几个细节值得展开。一是“存到本地JSON文件”必须写清楚，否则AI可能自作主张用数据库或内存列表，后者一关进程数据就没了。二是“超过7天且已完成”这种条件要一次性说透，虽然AI经常会在第一轮漏掉，但你在初始提示词里写出来，后续修正的轮次就会少一些。三是注明使用语言，别让它猜，猜中的概率虽然大，但完全没必要赌。

第一版生成结果我比较满意，文件结构是单文件todo.py，还附带说明只用Python标准库，不需要额外安装依赖。不过我很快就发现一个问题：它没有把归档逻辑做进去，只实现了基础增删改查。这其实非常典型，AI写代码时擅长处理高频、常见的需求，一到你自己定制的业务规则，它大概率会丢三落四。所以不要指望一句提示词能得到一个完整产品，第一轮生成的作用只是搭了个架子。

3.2 第二步：用AI搭骨架，别一上来就写细节

我见过很多刚开始用AI写代码的人，第一步就要求生成完整的业务代码，结果代码冗长、耦合度高，最后也没法维护。正确的做法是先要求搭骨架，确认数据结构和模块划分没问题，再往里面填细节。我继续对话，补了一条指示：

请先重构这个文件，把功能按函数拆分，并加入我要求的自动归档逻辑。归档标准是：done为True，且完成时间距离今天超过7天，这样的待办要移入archived列表。

这次Cursor给出的结构比第一次清楚得多：load_todos、save_todos、add_todo、list_todos、done_todo、archive_old_done_todos，最后是main入口做命令行分发。看到这个函数列表，我才敢往下走，因为骨架对了，后面改bug才有的放矢。

在这个阶段我学到的方法是：在让AI写完整代码之前，先让它列出“函数清单”，你只需要检查函数清单，就能提前判断它有没有理解业务需求。如果函数划分不对，让它在骨架上改，成本非常低；如果直接生成三百行代码再改，那排查起来就很痛苦了。这一轮主体代码的核心逻辑长这样：

def add_todo(text): todos = load_todos() todos.append({ "id": len(todos) + 1, "text": text, "done": False, "done_at": None, "created_at": datetime.now().isoformat() }) save_todos(todos) return len(todos)

3.3 第三步：让AI解释每一段代码，不放过“黑箱”

骨架和主体代码都生成后，我没有急着运行。接下来的操作，可能和大多数人不一样：我让AI逐段解释代码。具体指令是：

请解释save_todos和archive_old_done_todos这两个函数的实现逻辑，并指出潜在问题。

为什么要做这一步？因为AI生成的代码再怎么顺眼，你也得知道它为什么这么写。比如归档函数涉及时间比较，如果它直接用字符串比较ISO时间，而待办里的时间字段格式不统一，就可能出现归档不准确的隐蔽bug。让它解释，其实是在逼它自检，同时也让我自己掌握这段代码的逻辑，避免以后要改动时看不懂。

Cursor的解释还算老实，一个函数一个函数讲清了输入输出。但也正是在解释过程中，它自己承认了一个问题：最开始版本的done_todo函数只把done字段设为True，没有记录done_at时间，这导致归档函数根本没有时间可比较。这就是解释代码带来的额外好处，它能自己发现逻辑漏洞。我随即让它补上done_at字段，并把archive_old_done_todos改成用done_at做时间判断，问题当场就解决了。

3.4 第四步：运行报错了，怎么让AI改

把修正后的代码保存成本地文件，我第一次运行就发现了问题。命令执行后不只把待办添加进去了，终端还弹出一大段异常信息。核心报错是list index out of range，位置在done_todo函数里。这是个很基础又很典型的错误：ID分配逻辑在删除操作后没有重新计算，删除某条待办后，残留的ID引用指向了不存在的位置。

这时候就能看出对话式工具的优势。我不需要自己逐行排查，直接把报错堆栈贴给Cursor，再加一句：“根据这段报错，帮我分析原因并修复。”它先说明问题定位，认为删除操作应该同时处理ID的连续性，然后给出修复方案。这里我要插一句，AI给的方案不一定都对。它提供了两个选项，一个是把删除改为软删除，一个是每次保存前重排ID。我选择了更稳妥的重排方案，保证列表ID始终连续。这种技术选型不属于AI，属于我作为程序员的判断，必须由人来拍板。

修复之后再运行，流程就通了。添加待办、列表展示、标记完成、归档、删除，五条命令都能正常工作。整个过程耗时大约一个半小时，比我完全手写快一点，但也没夸张到五分钟搞定。这一步让我确认了一个事实：AI写代码目前最擅长的不是“替我做决定”，而是“把我已经想清楚的需求敲成代码”。它可以极大地压缩从想法到原型的时间，但前提是你知道自己想要什么。

3.5 这一轮跑下来的真实数据

为了避免全程“感觉还行”，我记录一下数据。项目从零到可运行，共迭代了四轮对话：第一轮生成初始代码，第二轮要求按函数拆分并补归档逻辑，第三轮让AI自我解释并修时间字段，第四轮根据报错修删除Bug。最终总代码量大约180行Python，单文件，无第三方依赖，标准库搞定。

AI生成的部分占比超过八成，但剩下两成的人工工作量，恰恰决定了工具能不能用。我自己做的那部分主要是：定义验收标准、检查函数结构、决定修复方案。换句话说，AI把我从重复编码的体力劳动中解放了，但判断、取舍、兜底这些脑力劳动仍然得由我来做。这个比例很多人之前可能没意识到，总以为AI写代码等于全自动，真用起来才会发现，它更像一个高效的辅助者，而不是替代者。

4. “哪个AI写代码厉害”：我这轮对比下的判断

4.1 同一需求，不同工具的翻车现场

每轮对话结束，我都会把同一段需求丢给备胎工具验证一下。因为热搜词里全是“哪个AI写代码厉害”“哪个AI写代码最好”，可工具的优劣从来不是一句话能说清的，非得放在具体任务里看才靠谱。

我用通义灵码问同一需求时，它生成的基础待办功能也能运行，但归档逻辑同样没有自动带上，需要二次强调。这很能说明问题：不管哪家AI，对自定义业务规则的理解都不算一次到位，靠提示词反复澄清是绕不开的。要说哪个更“厉害”，我个人的体感是：在“对话改项目文件”这个场景里，Cursor体验更胜一筹；在“IDE里随时补全、随手问注释”的场景里，通义灵码更贴近日常。厉害的定义取决于场景，脱离场景谈排名没有意义。

4.2 我踩过的三个典型坑

这轮尝试不是一帆风顺，有三个坑我认为值得单独写出来。它们不是工具的问题，而是使用方法的问题。

第一个坑是自然语言描述太模糊。我一开始写“把完成的待办归档”，AI完全不知道什么时候归档、按什么条件归档。后来我改成“已完成且完成时间距今超过7天的待办”，它立刻就写出了对应逻辑。给AI说需求，要像给同事交接工作一样，边界要清楚，判据要明确，不能光说“差不多”“你看着办”。

第二个坑是AI过度自信。有一轮我让它检查代码有没有问题，它回复“代码没有严重问题”，可实际一运行就报错。这种情况特别容易迷惑新人，以为AI说的“没问题”就真的是没问题。我现在的原则是：AI给出的“没问题”只代表它没看到问题，最终验收仍然要靠黑盒测试和跑真实场景，不能跳过验证直接上生产。

第三个坑是版本混乱。对话式工具很容易在一个会话里反复改，改到后面我已经分不清哪一段代码是最新版。后来我养成了一个习惯：每次让AI修改之前，先手动复制一份带时间戳的备份文件，比如todo_v2_1405.py。小项目看起来有点多余，但一旦需求复杂起来，版本混乱造成的时间浪费远大于备份那几秒钟。

4.3 哪些活该交给AI，哪些活必须自己扛

经过这一轮尝试，我心里对“什么活该交给AI”的边界清晰了很多。适合交给AI的包括：从零生成样板代码、写增删改查这类标准逻辑、根据报错信息做问题定位、把注释翻译成代码、统一代码风格。这些任务的共同点是高度重复、规则明确，AI做起来效率高，人也容易验收。

必须自己扛的则包括：确认业务需求的真实含义、判断技术方案和数据结构、处理异常流程和边缘情况、排除AI生成的隐藏bug、决定架构边界。这几类任务需要经验、需要对业务的理解、需要对系统的全局把控，至少目前AI还没到能独立完成的程度。你可以让AI帮你填代码，但那个“帮”字很重要，别丢掉。

4.4 接下来我还会坚持的三个习惯

以后再让AI写代码，我会强制自己做三件事。第一，每轮修改前先备份版本，哪怕只是在文件名后面加个时间戳，这个小动作能让人在反复试错时不慌。第二，先定义验收条件再写代码，最好把测试指令提前想好，让AI生成完直接跑一遍，别等到用的时候才发现问题。第三，我会让AI不只给代码，还要给修改说明，说明它改了什么、为什么这么改。多一个解释的步骤，往往能提前暴露逻辑问题。

对我个人来说，这次“AI写代码尝试1”最大的收获，是把对AI编程的想象从“黑科技”修正成了“生产力工具”。它不会替你思考，但能帮你扫清很多表达层面的阻碍。这套工作流我后来已经复制到其他项目上了，如果你也想试，建议就从今天这个最小实验开始：开一个空文件夹，写一句清楚的需求，让AI生成第一个版本，然后把报错原封不动地丢回给它。整个过程你很快会找到那种“旁边坐着个熟悉语法但偶尔犯浑的同事”的感觉，你管方向，它管输出，配合起来，效率是真的能涨一截。