拿到一个项目就焦虑进度代码写了一半不知道该问什么改完一个功能又崩了另一边——这是我最初一个人尝试做全栈项目时的真实状态。后来我慢慢摸索出一套“原子化 AI 编程”的打法简单说就是把全栈项目拆成一个个巴掌大的任务再交给 AI 辅助编程工具去生成、解释、改错而我只需保证每一小块做完之后能被验证、被记录。这篇个人学习记录就是把这套打法从思路到落地完整复盘一遍希望能给同样想“一人成军”的小白一点可以直接抄作业的参考。1. 先把“一人成军”这件事拆成可执行的最小单位1.1 为什么一个人做全栈项目要先拆而不是先学一说到全栈很多人第一反应是“要学的东西太多了”。前端要学框架、后端要学接口、数据库要学 SQL、部署要学服务器还有版本管理、鉴权、缓存、日志……如果按照“学完再做的顺序”推进大概率在第三周就放弃了因为反馈周期太长你根本不知道学那些东西到底用在哪里。我自己踩过的坑是一开始啃了半个月的教程觉得什么都会了一点结果打开编辑器写项目时依然是一片空白。真正改变进度的不是“学得更多”而是“把一个项目第一次跑通”。只要有一个极小的页面能从浏览器发请求到后端再拿到数据渲染出来那一刻你对全栈的理解会超过之前所有教程的总和。所以我的建议是从第一天就开始做项目而且是做一个小到不能再小的项目。学习只是这个项目过程中的附属品需要什么查什么。这个听起来像鸡汤但配合 AI 编程工具之后它真的能从口号变成可执行的流程。1.2 原子化让 AI 能真正帮上忙的任务切分方式“原子化”是我从接手一个巨型项目拆模块的经历里学到的思路。我当时的困惑是让 AI 写一个“完整的登录功能”它可能直接扔给你几十个文件的代码你说不清楚哪里对哪里错出了问题也不知道怎么改。后来我把登录拆成下面这些巴掌大的任务写一个后端接口接收用户名和密码返回一个固定的 JSON。写一个函数检查密码长度是否大于 6。在前端页面做一个表单点击按钮后把数据发送到这个接口。在浏览器控制台验证返回结果。每一个任务都符合三个条件一句话能说清楚、能独立运行、能立刻判断对错。这就是我理解的原子化不是把事情切得很碎而是切到“人能验收、AI能生成”的最小粒度。这个切法之所以对小白友好是因为它绕开了最大的认知负担。当你不用同时考虑“前端组件怎么写、路由怎么配、后端怎么起、数据库怎么连”的时候每个原子任务的上下文就变得很短AI 生成的代码不容易跑偏你检查起来也不用看懂所有代码只要看结果对不对就行。2. 技术栈与架构设计怎么选才不会被细节拖死2.1 耗时最短、反馈最快的技术组合一个人做项目最怕的不是技术太差而是被环境配置消磨掉耐心。我建议第一次做全栈项目时只管用“身边人用得多、文档资料全、出问题一搜就有答案”的组合不要追新。我的选择思路如下层次可选方案我的选择理由前端以组件为核心的现代前端框架生态成熟、能快速搭页面后端轻量级脚本语言后端框架写起来简单、启动快数据库文件型数据库起步再迁到服务型数据库零配置、适合初学者理解部署国内云托管平台或服务器面板能看到真实访问效果这套组合的特点是几乎不需要手动编译前端改完保存刷新就能看到效果后端一个命令就能启动。整个项目从初始化到上线环境配置的环节最少而环境配置恰恰是小白最容易卡住的地方。2.2 架构上只保留三个不变量我以前总想一步到位把网上那些高并发架构图塞进自己的小项目里结果代码量翻倍项目却更跑不通了。后来我给自己定了一个规矩项目第一版只保留三个不变量其他的都不做。第一个不变量是“前后端分离”。不管项目多小都把页面和接口分成两块。前端负责发请求、渲染数据后端负责接收请求、返回数据。这个约定让 AI 生成代码时职责非常清晰不至于一会儿把数据库代码写进前端一会儿又在前端文件里处理业务逻辑。第二个不变量是“接口只做一件事”。比如新增记账、列出记账、删除记账每个接口单独一个路径不要设计那种传一个 type 参数就切换功能的万能接口。接口职能单一AI 生成时不容易乱后面改需求时也不会误伤其他功能。第三个不变量是“数据库有独立访问层”。也就是说所有读写数据库的代码集中到一个文件里不要在好几个文件里各写各的 SQL。这一点在项目小的时候看不出差别等某天你要改表结构或者把文件型数据库换成服务型数据库时就能体会到这个约束有多救命。2.3 AI 编程工具在项目里的角色分工AI 编程工具很强但如果你把它当成“你负责想它负责全写”项目很快就会失控。我自己摸索出来的分工是人负责定义和验收AI 负责生成和解释。先说负责定义。每个原子任务要做什么、输入是什么、输出是什么、怎么算成功这些必须由人来定。比如“写一个接口接收 JSON把 title 字段存进数据库返回带 id 的记录”这样的描述 AI 几乎能一次生成。反过来如果你说“帮我写个后端”它给你的东西大概率没法直接用。再说负责解释。AI 最有价值的地方不是替你写整段代码而是帮你理解代码。遇到报错时我会把完整的报错信息丢给它然后问一句“这个错误是什么意思怎么修”。它列出的排查步骤通常比我自己瞎猜快很多。人还要负责验收。AI 生成的代码不是标准答案必须跑起来看结果。我给自己定了一条铁律任何一个原子任务没验证过就不算完成。哪怕只是写了一个加法函数也要在命令行里跑一遍确认输出正确。这条铁律帮我挡住了不少看似能跑、实际有隐藏问题的代码。3. 实操一个最小全栈项目从 0 到 1 的完整过程3.1 项目定位做什么、不做什么理论说了那么多落到实操才有感觉。我复盘时选了一个例子做一个个人记账本。当时我给自己定的范围是能手动添加一笔账、能看所有账单列表、能删除一条账单。就这三个功能不要再多。为什么要刻意做这么小因为“记账本”虽然小但它覆盖了全栈最核心的链路前端页面、后端接口、数据库存储、部署上线。跑通一遍之后你就有了一个可以不断往上加功能的骨架。之后加“编辑功能”“分类统计”“搜索过滤”都只是在已有链路上加节点而不是重新搭一张网。我在记录里写下了这个项目的“不做清单”不做用户注册登录不做图表统计不做多端适配不做高并发优化。不是这些功能难而是它们属于另一个复杂度层级。第一次做全栈目标不是炫技而是让整条链路闭环。3.2 把第一版功能写成原子任务清单项目定了接下来就是拆任务。我花了一个晚上把“记账本第一版”拆成了下面这张清单每一个任务都对应一个可以验证的结果。序号原子任务验证方式1初始化前端项目浏览器打开能看到空白页面2初始化后端项目命令行启动后访问根路径返回字符串3新增一个 POST 接口用命令行工具请求后返回固定 JSON4创建数据库表结构表能创建成功插入一条测试数据能查出来5把 POST 接口接上数据库请求后数据出现在数据库中6新增一个 GET 列表接口能返回数据库里的所有账单7前端做一个添加表单提交后能调用后端接口8前端做一个列表展示接口返回的数据能渲染在页面上9新增一个 DELETE 接口删除后再次查询列表数据消失10本地全链路联调添加、列表、删除全部通过11部署上线外网访问能正常使用这张清单的价值在于你永远知道下一步该做什么不会出现“面对空白项目发呆”的情况。每完成一项就在清单后面打个勾进度感会非常强烈。这也是我坚持“原子化”的主要原因——它把抽象的“做项目”变成了具体的“完成列表”。3.3 四步走后端、数据、前端、部署有了清单执行顺序也很有讲究。我的习惯是先做后端和数据库再做前端最后部署。因为前端依赖接口接口依赖数据库反过来做的话前端页面会发生不知道请求什么地址的僵局。第一步初始化后端项目。我在终端里执行了包管理器初始化命令然后安装了轻量级 Web 框架和跨域支持库。接着新建入口文件启动一个最简单的服务监听某个端口。这时候不要急着写业务代码先确认服务能起来、浏览器能访问再往下走。第二步设计数据库。我用的是文件型数据库不需要单独的数据库服务表结构简单到像一张 Excel 表格四个字段分别是自增编号、账单类型、金额、备注。建好表以后我随手在命令行里插入了一条测试数据然后查询出来确认存储这块没问题。第三步写接口。新增账单的接口负责接收前端传过来的金额和备注写入数据库返回记录编号列表接口把数据库里的所有记录查出来按时间倒序返回删除接口根据编号删掉指定记录。每个接口写完我立刻用命令行工具模拟请求确认返回结果符合预期。第四步写前端。前端页面只有两个区域上面是添加表单下面是账单列表。页面加载时请求列表接口拿到数据渲染提交表单时把输入内容发送到新增接口成功后再刷新列表。整个过程不需要复杂的状态管理库用最简单的页面脚本就能实现。最后一步部署。我把前后端分别处理前端打包后交给云托管平台后端连同数据库部署到服务器。部署完在浏览器里打开域名把“添加一笔账→出现在列表→删掉这笔账”重新跑一遍。这一步跑通整个项目才算真正闭环。3.4 “人机分工”的提示词示例很多人用不好 AI 编程工具是因为提问太模糊。我平时会按照“角色任务输入输出约束”的模板来写提示词。这里分享两个我在记账本项目里用过的提示词你是一个熟悉后端编程的助手。请用轻量级 Web 框架写一个处理 POST 请求的接口路径为 /api/items。 接口接收 JSON 格式的请求体包含 amount 和 note 两个字段要求把这两个字段写入数据库的 items 表中。 写入成功时返回一个 JSON 对象包含新记录的自增 id。请给出完整代码和必要的导入语句。你是一个前端页面开发助手。请写一段页面脚本实现以下功能页面加载时自动请求 GET /api/items 把返回的数组渲染成一个列表列表项显示金额和备注。请给出可以直接粘贴到 HTML 文件中使用的完整代码。这个模板看起来很简单但有三个细节很关键一是明确给出了接口路径和字段名AI 生成的前端代码能直接对上后端接口二是要求返回固定结构方便后端对接三是要求“可以直接使用”AI 会补全导入和初始化代码减少我们自己试错的时间。4. 常见问题与排查技巧实录4.1 环境不一致的翻车现场我做这个项目时遇到过最无语的情况是AI 给的代码在自己的电脑上能跑在部署服务器上却一直报错。排查到最后发现AI 写代码时默认使用了较新的语言版本而服务器上装的是旧版本语法不兼容。后来我给自己加了两道保险。第一在项目的依赖配置文件里固定版本号明确写入项目需要的运行环境版本。第二每次部署前先把本地环境清一遍重新安装依赖模拟服务器的干净状态。这样部署时遇到的环境问题能提前在本地暴露一大部分。AI 生成代码时我还会在提示词里主动补充一句“请使用当前项目指定的运行环境版本不要使用最新语法特性”。看似不起眼但对部署失败率的降低非常明显。4.2 小改动引起大崩溃的连锁反应有次我改前端里一个按钮的文案结果页面上整个列表都不显示了。原因很可笑按钮所在的组件和列表共用了一段状态管理代码我顺手把里面一个变量名改掉了列表读取数据时拿到的是 undefined。这个坑让我意识到越小的项目越容易产生“代码耦合”。解决思路不是不再改代码而是借机养成两个习惯一是动手前先看清楚改动会影响到哪些变量和函数二是每改一次就立刻在浏览器里把核心流程跑一遍。我管这个叫“三分钟回归测试”虽然听起来粗糙但对个人项目来说性价比极高。4.3 卡壳的时候怎么问自己没有人写代码不卡壳关键是有没有一套从卡壳里走出来的固定流程。我的流程是先把报错信息原封不动复制下来再打开 AI 工具问“为什么会有这个错误”。很多时候只要把问题精确描述出来答案就出来了一半。如果 AI 给了修复建议还是不行我会把自己想要的效果和当前代码之间的差距拆成更小的中间步骤再去问。比如列表渲染不出来我会依次检查接口返回的数据结构是否和我预想一样前端取字段的名字是否拼错渲染函数是否被正确调用这样一层层拆下去问题总能定位到某一个具体的原子任务上。4.4 原子化开发里的避坑清单下面这张表是我复盘整个项目后整理的避坑清单每一条都来自实际翻车记录现象常见根因排查方向接口请求跨域报错后端没有允许跨域请求检查后端跨域配置页面能打开但数据为空接口返回结构和前端预期不一致分别验证接口数据和前端渲染数据库报错表不存在建表代码没执行或表名不一致查看建表日志和连接配置中的表名部署后功能失效环境配置与本地不同逐个对比部署环境依赖版本修改无效页面缓存了旧代码强制刷新或检查前端是否重新打包这里我最有体会的一条是“接口返回结构和前端预期不一致”。第一次做接口对接时我以为返回的是数组结果后端包了一层对象前端拿到后调用了数组的遍历方法直接报错。从此我给自己定了一条规矩前后端每次联调先在命令行里看一次真实返回结果再写前端代码。5. 从记录到迭代怎么把这次经验变成长久能力5.1 学习记录模板不是日记是证据“个人学习记录”这个后缀为什么重要因为做完一个项目后你学到的不是那几行代码而是你在这个过程中做过的判断。我每次复盘都会按固定模板写记录模板只有四栏原子任务、AI 交互、验证结果、踩坑教训。比如我记录中的一行是这样的原子任务实现新增账单接口。AI 交互让 AI 生成写入数据库的代码并特别要求返回记录编号。验证结果用命令行工具请求后数据库中新增了一条记录接口返回了编号。踩坑教训第一次生成的代码没有返回编号因为我没有在提示词里提出这个要求。结论是提示词里要把“输出长什么样”写清楚。这个模板的意义在于它强迫我区分“AI 做了什么”和“我做了什么”。过三个月回看哪一栏的内容越少说明我越依赖 AI 直接给结果而没有真正消化。5.2 一人成军的三个阶段我第一次做成记账本项目的时候以为“一人成军”就是什么都能自己写。后来我发现它其实是一条从依赖到独立的长路我把它分成三个阶段。第一阶段叫“抄写与理解”。这个阶段的我基本复制 AI 给的代码唯一的任务是逐行读懂它在干嘛。读不懂没关系用笔记下来下一次遇到同样的模式时再对照。第二阶段叫“改写与组合”。这时候我已经能看明白 AI 生成的代码也能在它基础上改字段名、调逻辑、组合两个函数。这个阶段的目标是“我有需求AI 出草稿我来改”。第三阶段叫“独立设计与复盘”。目前我正处在往这个阶段走的路上。这个阶段更多是动笔设计——自己画数据库表、自己定接口、自己排任务。AI 退回到一个纯粹的编码助手而不是产品经理。阶段不同AI 的角色也不同。第一阶段 AI 是老师第二阶段 AI 是同事第三阶段 AI 是打字员。判断自己在哪个阶段的标志很简单看你还愿不愿意在没有 AI 的情况下自己写下一个原子任务的核心代码。愿意写、写得慢没关系这才是能力真正长在自己身上的信号。最后再分享一个小技巧。原子化任务拆分的时候我给每一条任务都标了一个预估时间大部分都在半小时以内。超过半小时还没完成的任务立刻停止硬啃拆成更小的步骤再继续。宁可任务列表长一点也不要让任何一个步骤大到让自己产生畏难情绪。这个习惯帮我撑过了最开始那段最容易放弃的日子应该也能帮到你。