新手用AI做个人项目：从零到一完整指南

1. 新手用AI做个人项目的整体思路拆解

1.1 为什么现在是新手做个人项目最好的时间窗口

我做了十多年开发，带过不少刚入行的朋友，最大的感受就是：过去一个新手想独立做出一个能跑起来、能给别人用的小项目，门槛高得离谱。你得先学一门语言，再学框架，再学数据库，再学部署，中间任何一环卡住，项目就死在半路。很多人不是没想法，是想法还没落地就被环境配置劝退了。

现在情况完全变了。AI编程工具把“写代码”这件事的门槛拉低了一大截，但注意，它拉低的是编码门槛，不是项目门槛。这两者差别很大。编码门槛指的是“你能不能把一段逻辑翻译成语法正确的代码”，项目门槛指的是“你能不能把一个模糊的想法拆成能跑起来的模块，并且知道每一块该用什么、为什么这么用”。AI能帮你干掉前者，但后者还得你自己扛。

所以新手用AI做个人项目，正确的姿势不是“我有个想法，让AI全给我写了”，而是“我有个想法，我先想清楚它由哪几块组成，然后让AI帮我加速每一块的实现”。这个思路的转变，决定了你是真的在做项目，还是在玩一个会写代码的玩具。

我见过太多新手一上来就跟AI说“帮我做一个记账App”，然后AI吐出来几百行代码，他复制粘贴跑不起来，就懵了。问题不在AI，在于他自己都不知道这个记账App要几个页面、数据存哪里、怎么增删改查。AI给的是代码，不是架构。架构这件事，现阶段还得人来定。

1.2 个人小项目的选型原则：小、闭环、能演示

新手选项目，我建议死守三个原则：足够小、能闭环、能演示。

足够小，指的是功能范围要窄到你自己能在脑子里完整过一遍。比如“一个能记录每天喝水杯数并显示本周统计的网页”，这就够小。别一上来就搞“带社交功能的健身打卡平台”，那是给自己挖坑。

能闭环，指的是这个项目从输入到输出要能自己跑通，不依赖一堆外部服务。比如你做一个待办清单，数据存本地浏览器就行，不需要后端、不需要数据库、不需要登录。闭环意味着你能独立调试，出了问题不会甩锅给“可能是服务器的问题”。

能演示，指的是你做完了能截图、能录屏、能发给朋友看。这一点特别重要，因为新手最需要的是正反馈。一个能演示的项目，哪怕只有三个按钮，也比一个“架构很牛但跑不起来”的项目有价值一百倍。

基于这三个原则，我推荐新手从这几类项目入手：单页工具类（比如单位换算、颜色选择器、倒计时）、本地数据管理类（比如书签整理、观影记录、读书笔记）、调用公开接口的小应用（比如天气查询、汇率转换、每日一句）。这些项目的共同点是：不需要后端、不需要登录、不需要复杂状态管理，一个HTML文件加一点JavaScript就能跑。

1.3 AI在项目里到底扮演什么角色

很多人对AI的期待是“帮我写完整项目”，这个期待本身就是错的。AI在个人项目里最合适的角色是结对搭档，而不是外包团队。

具体来说，AI能帮你做这几件事：第一，解释概念。你不懂什么是API、什么是JSON、什么是异步，直接问它，它能用大白话给你讲明白。第二，生成样板代码。比如你要写一个表单提交，它能给你一个标准的结构，你改改字段就能用。第三，排查报错。你把错误信息贴给它，它大概率能告诉你哪里出了问题。第四，提供多种方案。你想实现一个功能，它可以给你三种写法，你挑一个顺眼的。

但AI做不了这几件事：它不知道你的真实需求（因为你可能自己都没想清楚），它不知道你的运行环境（浏览器版本、操作系统、依赖版本），它不能替你调试（它只能猜，你得自己验证），它不能替你决定项目该做成什么样。

所以正确的协作方式是：你负责想清楚要什么、拆解成步骤、验证结果；AI负责加速每一步的实现、解释不懂的地方、提供备选方案。这个分工一旦搞反，你就会陷入“AI写了一堆我看不懂的代码，跑不起来我也不知道为什么”的死循环。

2. 核心工具链与关键细节解析

2.1 编辑器与AI插件的搭配逻辑

新手最容易纠结的就是“我该用哪个AI编程工具”。市面上的选择确实多，Cursor、Trae、各种IDE插件，每个都说自己最强。我的建议是：别纠结，先选一个用起来，用顺手了再考虑换。

选工具的核心逻辑不是“哪个功能多”，而是“哪个能让你少切换窗口”。新手最怕的就是在浏览器、编辑器、终端之间来回跳，跳着跳着注意力就散了。所以优先选那种把AI对话和代码编辑放在同一个界面的工具。

Cursor是目前比较主流的选择，它的优势是把AI对话、代码补全、错误修复都集成在编辑器里，你选中一段代码直接问它，它就在旁边回答，不用切窗口。Trae是另一个选择，界面更简洁一些，对新手更友好，但生态和插件丰富度还在追赶。如果你已经习惯了某个编辑器，也可以装AI插件，比如PyCharm里可以装一些AI辅助插件，但体验上不如原生集成的工具流畅。

这里有个细节很多人忽略：AI工具的中文设置。有些工具默认是英文界面，新手看着一堆英文菜单容易发怵。大部分工具都支持切换语言，在设置里找“Language”或“语言”选项，切成中文就行。如果找不到，直接问AI“这个工具怎么设置中文”，它一般能告诉你路径。别小看这一步，界面语言顺眼了，你的学习意愿会高很多。

2.2 代码托管与版本管理：为什么新手也该用GitHub

很多新手觉得“我就做个小项目，放本地就行了，搞什么GitHub”。这个想法我理解，但我要说，哪怕是一个人做的小项目，用GitHub也是值得的。

原因有三个。第一，备份。你本地硬盘挂了、电脑丢了、手滑删了文件夹，代码就没了。传到GitHub上，至少有个远程副本。第二，历史记录。你今天改了一版，明天改了一版，改到后天发现还是第一版好，用Git就能回退。没有版本管理，你只能靠“复制一份改个名”这种原始方法，文件夹里全是项目_最终版_真的最终版_2。第三，展示。你做完了项目，把链接往简历或社交平台一放，别人能直接看到你的代码和提交记录，这比说“我会编程”有说服力得多。

新手用GitHub，不需要学太复杂的东西。掌握三个操作就够了：克隆（clone）、提交（commit）、推送（push）。再配合一个图形化工具，比如GitHub Desktop，连命令行都不用敲。如果访问GitHub有困难，可以找一些国内的代码托管平台作为替代，操作逻辑是类似的。

这里有个实操心得：提交信息要写人话。很多人提交的时候写“update”“fix”，过两个月自己都不知道改了什么。写“增加了删除按钮”“修复了日期显示错误”这种，以后回看一目了然。AI可以帮你生成提交信息，你把改动的文件列表贴给它，让它总结一下，比你自己憋半天强。

2.3 项目结构的最小化设计

新手做项目，最容易犯的错是过度设计。还没写几行代码，先建了十几个文件夹，什么components、utils、services、hooks，结果每个文件夹里就一个文件，自己都记不住哪个是哪个。

我的建议是：项目初期，所有代码放在一个目录下，文件数量控制在五个以内。比如一个网页小工具，就三个文件：index.html、style.css、script.js。等代码超过五百行，或者你明显感觉到“这块逻辑和那块逻辑混在一起了”，再考虑拆分。

拆分的逻辑也很简单：按功能拆，不按类型拆。比如你做一个记账工具，可以拆成记账逻辑.js、统计逻辑.js、界面渲染.js，而不是所有工具函数.js、所有常量.js。按功能拆的好处是，你改一个功能的时候，只需要打开一个文件，不用在五个文件之间跳来跳去。

AI在这个环节能帮上忙。你可以把代码贴给它，说“帮我看看这个文件是不是太长了，该怎么拆”，它会给你一个拆分建议。但记住，拆分是为了让你更好维护，不是为了看起来更专业。如果一个文件才一百行，拆成三个文件反而增加了跳转成本，那就别拆。

3. 从零到一：一个完整小项目的实操过程

3.1 需求定义：把“我想做个东西”变成可执行的清单

假设我们要做一个每日喝水记录工具。这个需求听起来很简单，但如果你直接跟AI说“帮我做个喝水记录”，它给你的东西大概率不是你想要的。所以第一步是把模糊想法翻译成具体清单。

我会这样拆：这个工具要能记录今天喝了几杯水，每杯按250毫升算；要能显示今天总共喝了多少毫升；要能显示距离目标（比如2000毫升）还差多少；要能重置今天的记录；数据要存在本地，关掉浏览器再打开还在。

你看，拆完之后，每个功能都是可验证的。“记录一杯水”就是一个按钮点击事件，“显示总量”就是一个数字更新，“存本地”就是用浏览器的localStorage。这些AI都能帮你实现，但前提是你得先告诉它要做这些事。

这一步我强烈建议手写，不要用AI。你自己拿张纸或者开个记事本，把功能一条条列出来。这个过程能帮你发现很多“我以为我想清楚了但其实没有”的地方。比如你列到“重置记录”的时候，可能会想：是重置今天的，还是清空所有历史？这就是一个需要你决定的细节，AI不会替你想。

3.2 技术选型：为什么这个项目不需要框架

需求列清楚之后，下一步是选技术。很多新手在这里会犯“杀鸡用牛刀”的错，一个喝水记录工具，非要用React或者Vue，结果光环境配置就搞了半天，项目还没开始写就累了。

我的判断标准很简单：如果这个项目不需要频繁更新界面、不需要组件复用、不需要路由跳转，那就用原生HTML+CSS+JavaScript。喝水记录工具完全符合这个标准，它就是一个页面、几个按钮、一个数字显示，原生三件套足够了。

原生写法的好处是：没有构建步骤、没有依赖安装、没有版本冲突。你新建一个index.html，双击就能在浏览器里打开，改完代码刷新就能看到效果。这种即时反馈对新手特别重要，它能让你保持“我在做东西”的感觉，而不是“我在配环境”的挫败感。

如果你确实想学框架，我建议先用原生做一个完整项目，再用框架重做一遍。这样你能真切感受到框架解决了什么问题，而不是为了学框架而学框架。AI可以帮你把原生代码翻译成框架代码，你对比着看，理解会深很多。

3.3 核心功能实现：让AI帮你写第一版代码

到了写代码这一步，AI就能发挥最大价值了。但提问方式很关键。不要问“帮我写一个喝水记录工具”，要问“帮我写一个HTML页面，上面有一个按钮，点击后数字加250，下面显示这个数字，并且把数字存在localStorage里”。

后一种问法，AI给你的代码基本能直接用。前一种问法，AI会给你一堆你可能不需要的东西，比如样式框架、图标库、响应式布局，你还得删。

我实际操作的流程是这样的：先让AI生成一个最简版本，只有核心功能，没有样式。跑起来确认逻辑没问题，再让AI加样式。加样式的时候也具体一点，比如“按钮圆角、背景蓝色、文字白色、鼠标悬停变深”，别只说“好看一点”。

这里有个技巧：让AI解释它写的代码。你可以说“逐行解释这段代码在做什么”。新手看代码容易只看个大概，但逐行解释能帮你发现很多细节，比如localStorage.setItem的第二个参数必须是字符串，如果你传数字它会自动转换，但读出来的时候是字符串，需要parseInt转回数字。这些细节你不问，AI不会主动说，但它们是新手最容易踩的坑。

3.4 调试与迭代：报错不可怕，不会看报错才可怕

代码跑不起来是常态，跑起来才不正常。新手遇到报错容易慌，其实报错信息是最有价值的线索。浏览器按F12打开开发者工具，Console面板里红色的就是报错，它会告诉你哪个文件、哪一行、什么错误。

常见的报错就那么几类：undefined is not a function通常是函数名拼错了或者对象没有这个属性；Cannot read property of null通常是你想操作的元素还没加载出来；SyntaxError通常是括号、引号、逗号写错了。你把报错信息完整复制给AI，它基本都能告诉你原因和改法。

但注意，AI给的修改方案要验证。它可能会说“把这一行改成那样”，你改完发现还是报错，那就把新的报错再贴给它。这个过程可能要来回几次，很正常。我自己的经验是，同一个问题问三次还解决不了，就换个问法。比如从“为什么报错”换成“这段代码我想实现某某效果，现在报错，帮我看看逻辑哪里有问题”。换个角度，AI可能就找到症结了。

还有一个新手常犯的错：改了代码不刷新页面。浏览器有缓存，有时候你改了代码但页面还是旧的。养成习惯，改完代码按Ctrl+F5强制刷新，或者打开开发者工具的Network面板勾选“Disable cache”。

4. 常见问题与排查技巧实录

4.1 AI生成的代码跑不起来怎么办

这是新手遇到最多的问题。AI给了一段代码，你复制粘贴，运行，报错。这时候不要急着说“AI不行”，按这个顺序排查：

第一，检查代码是否完整。AI有时候会省略一些它认为“你应该知道”的部分，比如HTML的<head>标签、CSS的引入、函数的调用。你看一下代码是不是从中间开始的，有没有缺少闭合标签。

第二，检查运行环境。AI可能用了某个新语法，你的浏览器不支持；或者用了某个库，你没有引入。比如它用了fetch，这是现代浏览器都支持的，但如果你在很老的浏览器里跑就会报错。

第三，检查变量名和文件名。AI生成的代码里，变量名可能和你已有的代码冲突，或者它引用的文件名和你实际的文件名不一致。这种错误很隐蔽，但很常见。

第四，让AI自己检查。你把完整代码和报错信息一起贴给它，说“这段代码报这个错，帮我检查哪里有问题”。它有时候能发现自己之前生成的代码有bug。

我踩过的一个坑：AI生成了一段用localStorage的代码，但它写的是localStorage.setItem('count', count)，count是数字。存进去没问题，但读出来的时候是字符串"250"，直接拿去做加法会变成字符串拼接，"250" + 250等于"250250"。这个bug我找了半天，后来让AI逐行解释才发现的。所以类型转换这件事，新手一定要留心。

4.2 如何让AI理解你的项目上下文

AI没有记忆，你关掉对话窗口再打开，它就不记得你之前说过什么了。所以每次提问，要把必要的上下文带上。

比如你之前让它写了一个喝水记录的工具，现在想加一个“历史记录”功能。你不能直接说“加个历史记录”，它不知道你在说什么项目。你应该说“我之前有一个喝水记录的HTML页面，用localStorage存了每天的杯数，现在想加一个功能，能显示最近七天的记录，数据还是存在localStorage里”。

更高效的做法是：把当前代码贴给它。代码本身就是最好的上下文。你贴完代码，再说“在这个基础上加一个历史记录功能”，它就能给出针对性的修改。

还有一个技巧：给AI设定角色。你可以说“你是一个前端开发助手，我正在做一个纯前端的喝水记录工具，不用框架，只用原生HTML/CSS/JS”。这样它就不会给你推荐React或Vue的方案，省去很多沟通成本。

4.3 项目做完了下一步做什么

项目能跑起来之后，我建议做三件事。

第一，写一个README。不用很长，几句话就行：这个项目是干什么的、怎么运行、用了什么技术。AI可以帮你写，你把项目描述给它，让它生成一个README模板，你改改就能用。这个习惯养成了，以后你回头看自己的项目，能快速回忆起当时做了什么。

第二，部署上线。纯前端项目部署很简单，GitHub Pages、Vercel、Netlify都支持直接拖文件夹上传，几分钟就能得到一个公开链接。有了链接，你就能发给朋友看，这种“我做的东西别人能访问”的感觉，是继续做下一个项目的最大动力。

第三，记录踩坑。把你做这个项目过程中遇到的问题和解决方法记下来，哪怕就写在README里。下次做类似项目的时候，这些记录能帮你省很多时间。而且这些记录本身就是很好的分享素材，你发到技术社区，能帮到其他新手，也能收获反馈。

4.4 新手常踩的五个坑速查表

4.5 关于AI工具的几个实操心得

用了这么久AI编程工具，有几个心得是文档里不会写的。

第一，AI对“新语法”和“旧语法”的态度不一样。你问它一个老问题，它可能给你一个很新的写法，因为它的训练数据里新资料更多。但新写法在你的环境里不一定支持。所以如果你用的是比较老的运行环境，要主动告诉它“请用ES5语法”或者“不要用箭头函数”。

第二，AI生成的代码风格不统一。同一个项目里，它可能一会儿用function，一会儿用箭头函数，一会儿用var，一会儿用let。这不影响运行，但看着难受。你可以在提问的时候加一句“统一用const和箭头函数”，它就会保持一致。

第三，AI有时候会“编”API。它可能会调用一个根本不存在的函数，或者用一个库的用法是错的。这种情况在比较冷门的库上更容易出现。所以AI给的代码，尤其是涉及第三方库的，一定要自己跑一遍验证。

第四，多AI协作是个进阶玩法。你可以用一个AI写代码，用另一个AI做代码审查。比如让AI A写一个功能，然后把代码贴给AI B，说“帮我看看这段代码有没有bug或者可以优化的地方”。两个AI的角度不同，经常能发现对方忽略的问题。这个玩法适合已经有一定基础的新手，刚开始不用追求这个。

第五，提示词的质量决定输出质量。“帮我写个网页”和“帮我写一个HTML页面，包含一个标题、一个按钮、一个显示数字的区域，点击按钮数字加一，用原生JavaScript实现，不要用任何框架”，后者得到的结果可用性高十倍。花三十秒把需求写清楚，能省三十分钟改代码的时间。

5. 从一个小项目到持续做项目的习惯

5.1 怎么选下一个项目

做完第一个项目之后，选第二个项目的原则是：在第一个项目的基础上加一点新东西。比如第一个是喝水记录，第二个可以做“喝水记录+图表显示”，引入一个图表库；或者做“喝水记录+多用户”，引入简单的登录逻辑。

这样选的好处是，你不需要从零开始，大部分代码可以复用，只需要学一个新知识点。每次只学一个新东西，积累起来就很快。如果每次都是全新项目、全新领域，学习曲线太陡，容易放弃。

我自己的习惯是维护一个“想做的项目”清单，平时想到什么就记下来。做项目的时候从清单里挑一个难度适中的，做完再挑下一个。这样永远不会出现“不知道做什么”的情况。

5.2 怎么让AI帮你学新东西

AI不只是写代码的工具，也是很好的学习工具。你可以用它来做这几件事：

解释代码。看到一段看不懂的代码，贴给它，让它逐行解释。比看文档快。

出练习题。你可以说“给我出五道关于JavaScript数组的练习题，从易到难”。它会给你题目和答案，你可以自己先做，再对答案。

对比方案。你想实现一个功能，可以问“实现这个功能有哪几种方式，各自的优缺点是什么”。它会给你一个对比，帮你做技术选型。

模拟面试。你可以说“你是一个前端面试官，问我关于这个项目的技术问题”。它会问一些你可能没想到的问题，帮你查漏补缺。

但注意，AI的解释不一定全对。它可能会把某个概念解释错，或者漏掉重要的细节。所以关键概念还是要交叉验证，比如查官方文档或者找几篇不同的教程对照着看。

5.3 把项目变成作品集的思路

新手做项目，最容易忽略的是记录过程。你做完一个项目，代码传到GitHub了，但别人点进去只看到一堆代码，不知道你做了什么、为什么这么做。

我的建议是：每个项目配一篇简短的说明。不用写成技术文章，就回答几个问题：这个项目解决了什么问题、我用了什么技术、遇到了什么困难、怎么解决的、如果重做我会改什么。这几百字写下来，你的项目就从“一堆代码”变成了“一个故事”。

这些说明积累起来，就是你的作品集。以后找工作或者接私活，你把GitHub链接一发，别人能看到你的代码、你的思考过程、你的成长轨迹。这比简历上写“熟悉JavaScript”有说服力得多。

而且写说明的过程本身也是复盘。你会发现很多当时没想清楚的地方，写着写着就想明白了。AI可以帮你润色文字，但内容得你自己提供，因为只有你知道当时发生了什么。

5.4 关于坚持这件事的一点个人体会

做个人项目最难的不是技术，是坚持。我见过太多人第一个项目做完就停了，第二个项目开了个头就烂尾了。原因通常不是能力不够，是期望太高。总想做一个“拿得出手”的项目，结果迟迟做不完，最后不了了之。

我的经验是：把项目做小，小到你觉得“这也能算项目？”的程度。一个只有三个按钮的网页，一个只有五十行的脚本，都算。做完一个就发布一个，不管多简陋。发布的动作本身会给你正反馈，而正反馈是坚持下去的唯一动力。

AI在这个过程中最大的价值，不是帮你写代码，是帮你消除“我不会”的恐惧。以前你遇到一个不懂的概念，可能要查半天资料才能继续，现在直接问AI，三十秒就有答案。这种即时反馈让做项目变得像聊天一样轻松，你更容易进入“做着玩”的状态。而“做着玩”的状态，恰恰是能坚持下去的状态。

我现在的习惯是，每周花两三个小时做一个小东西，不求完整，只求跑通一个点。有时候是一个新的CSS效果，有时候是一个API的调用，有时候只是把之前项目的某个功能重写一遍。这些零碎的时间积累起来，比集中一周做一个大项目更可持续。

最后分享一个我常用的方法：给每个项目设一个“最小可发布版本”。比如喝水记录工具，最小可发布版本就是“能记录、能显示、能存本地”，样式丑没关系，没有历史记录没关系。先把这个版本做出来发布，然后再迭代。这样你永远有一个能用的东西在手，而不是一个永远在“开发中”的半成品。