AI辅助开发实战：全程没写几行代码，一个人端到端交付项目

先交代一下背景：大概一个月前，我接了一个内部小系统的需求，做的是一个团队项目进度看板加周报自动生成工具。核心痛点很简单——每周五项目经理要手动汇总十几个人的进度，整理成固定格式的周报发给上级，费时且容易漏。我用AI把这个项目从需求梳理、方案设计、前后端开发到部署上线端到端跑通了，全程自己手动敲的代码不超过二十行，大部分时间是跟AI对话、审代码、改配置。这篇就把整个过程和踩过的坑完整写下来，包括我是怎么拆需求的、怎么调教大模型、哪些环节AI靠得住、哪些环节必须人工兜底。

先说结论：AI辅助交付一个中小型项目，现在已经不是行不行的问题，而是怎么组织流程的问题。它不会完全替你写代码，但它能把你从"从零搭框架、写样板代码、调CSS"这些体力活里解放出来，让你把精力放在需求判断和质量把关上面。只要流程设计得当，一个人加一套AI工具链，完全能撑起过去两三个人干的活。

1. 动手之前，先想清楚这活儿能不能交给AI

1.1 这个项目到底是个什么

我这边接到的需求是这样的：团队大概十几号人，分三条业务线，每季度同时跑着四到六个项目。原来进度信息散落在各个IM群的表格和文档里，每周五靠专人手动汇总。新系统要解决的问题就是两个：

一是有个统一的数据入口，每个人每周填一次自己的任务状态；二是系统能根据这些状态自动生成规范化的周报，按项目和负责人维度做汇总，减少人工贴数据的操作。

这个系统涉及的东西不算少：用户登录和权限管理、任务数据录入、项目维度看板、周报自动生成、导出发送。但复杂度也在可控范围，属于典型的"表结构清晰、业务逻辑不绕"的信息管理系统，没有那种需要强实时性、高并发或者复杂算法的地方。这类项目的代码量看起来不小，其实绝大多数是增删改查的样板代码，AI最擅长的恰恰就是这种活。

我判断这个项目适合用AI主导开发，主要有三个理由：

• 逻辑确定性高。业务流程是明确的，不存在"需求都没搞清就开始写代码"的情况。
• 技术栈通用。Web应用、关系型数据库、单服务器部署，AI训练语料里这种组合多得是。
• 可验收性强。每个功能点能不能跑通是客观的，不会出现"AI说做好了但我看不出好坏"的情况。

反过来，如果需求本身模糊、业务规则复杂到需要大量人工判断，或者涉及老系统对接和底层性能优化，那我就会谨慎很多，至少不会让AI直接上手写。

1.2 AI能覆盖的边界在哪里

这里我先厘清一个概念：全程没写几行代码，不等于全程没动脑。实际上我做的事情一点都不比传统开发少，只是性质变了——我需要做的是需求定义、方案决策、代码审查、问题定位，而不是逐行敲代码。

我用一张表来复盘一下这个项目里AI实际扮演的角色：

这个比例关系很直观：AI承担了大约百分之八九十的"生产"工作，但决策和验收环节都在我手里。换句话说，AI负责写出来，我负责确定要什么和确认它写对了。

1.3 工具链怎么选

工欲善其事，必先利其器。这个项目里我用的组合是：一个支持上下文对话的AI编程助手作为主力，配合一个通用大语言模型处理方案设计和技术咨询，再加一个代码托管平台的AI代码审查功能做辅助。

选型逻辑不复杂：主力工具要能直接读写项目文件，这样AI生成的代码能自动落到工程里，不用来回复制粘贴；通用大模型用来做开放性的讨论，比如"这个系统的权限模型怎么设计更合理""周报模板的参数应该怎么定义"这类问题，它的知识面更广。

这里我想强调一个很多人的误区：同时打开五六个AI工具，同一个问题每边问一次，以为能提高质量。实际体验是，工具切换成本很高，上下文反复丢失，最后得到的答案还经常互相矛盾。我自己就是主力工具一用到底，只在部署环节用通用模型查了一个编译参数的解释。工具不在多，关键在于你能不能把一个AI的上下文喂得足够完整。

2. 需求梳理和方案设计，这一步最关键

2.1 用AI把模糊想法变成功能清单

这个项目的启动方式很简单——我把原始需求直接甩给了AI，原话大概是："我们团队需要一个项目进度管理系统，主要是有任务填报、进度看板、周报生成三个核心模块，十几个人使用，要能有基本的权限管理，比如普通成员只能看自己相关的项目，负责人可以看整个项目组，管理员能管理成员。"

这个描述其实很模糊，"看板"长什么样不知道，"周报"按什么格式也不知道。但AI的好处是，你不需要一开始就把需求想得完美，它会反过来用提问引导你补充信息。

第一轮对话，AI直接给了一份十二项的功能清单，每一项都有优先级建议：

• 用户管理：注册、登录、角色分配（P0）
• 项目管理：创建项目、归档项目（P0）
• 任务管理：填写任务标题、描述、负责人、预计完成日、状态（P0）
• 进度看板：按项目维度查看任务列表和状态分布（P0）
• 周报生成：按周汇总成员任务并生成文本（P0）
• 通知提醒：任务临期提醒（P1）
• 数据导出：导出周报为文件（P1）
• 数据统计：成员工作量分布（P2）

这份清单最大的价值不是它列得有多全，而是给我了一个讨论的锚点。我不用对着空白文档发愁"需求到底要写什么"，只需要在已有清单上做增删改。实际调整的时候，我把"通知提醒"从P1降到了P2，因为第一版用不上消息推送；把"数据导出"从P1提上了P0，因为客户明确要求能在周报基础上二次编辑。

这轮下来我最大的体会是：让AI做需求分析时，你给的信息越"像甲方"，它给你的结果就越"像需求文档"。你可以把原话拼上去，包括"领导想看每人这周干了啥""表格多了大家嫌烦"这种很人话的表达，AI反而能正确理解业务场景。

2.2 技术方案选型，让AI先出选择题而不是问答题

需求定了以后就是技术选型。老实说，这种体量的系统，技术方案说不上多难选，但前后端框架、数据库、部署方式的排列组合还是能让人纠结一阵子。

我没有直接问"这个项目用什么技术栈"，而是给AI设了前提条件：

• 部署在一台2核4G的普通云服务器上
• 团队人数不超过50人，并发量极低
• 开发周期两周以内
• 维护成本要低，后续可能由不熟悉技术的人接手

AI给了两个方案。方案一是前后端分离，前端用Vue，后端用FastAPI，数据库用MySQL；方案二是后端用Python的Flask或FastAPI直接渲染模板加少量原生JavaScript，数据库用SQLite，整个应用打包成单进程部署。

它还给出了一组对比数据，侧重参考工程实现成本和维护成本，得出了方案二更适合这个场景的结论。我当时犹豫的点在于，前后端分离毕竟是主流的工程实践，后续扩展性好。AI进一步解释：这个项目的主要瓶颈在业务功能的迭代速度，而不在并发和扩展性；前后端分离会引入Node构建链、跨域配置、多进程部署等复杂度，反而拖慢交付节奏。

这个推理逻辑是对的。我最后采纳了方案二——服务端渲染加轻量交互，SQLite做存储。整个后端代码加上模板文件，规模控制得很小，部署就是跑一个服务的事。如果当时为了追赶主流趋势选了前后端分离，整个项目周期估计得翻倍。

2.3 数据库设计：AI出表，人做主

技术方案定了以后，数据库设计这步就得细说。我的输入就一句话："这个系统需要的数据表有用户、项目、任务、项目成员关系，另外要能记录每周的填报状态。" AI输出的建表脚本包含了六张表，每张表的关键字段都有：

用户表、项目表、项目成员关联表、任务表这四张是基本盘。让我眼前一亮的是它自动加了两张常规需求里不易想到的表：一张是周报生成记录表，用来记录每次生成周报的时间、汇总周期和生成人；另一张是操作日志表，记录关键操作。这两张表是后面做功能回溯和排障时的重要基础，我后来确实用到了。

我做的调整主要有三处：

• 在任务表里加了"上周状态"和"本周状态"两个字段，用于周报里展示任务进展变化。
• 把项目表的负责人字段改成与用户表关联的外键，保证数据一致。
• 把"预计完成日"改成可空，因为有些任务本身是长期迭代型，没有硬性截止时间。

这里有个AI容易犯的问题：它对业务细节的预判是统计性的，不是真懂你的场景。比如它生成的关联表大概率是正确的，但字段的默认值、是否可空这类约束条件需要人工审视。我的原则是：表结构的人均互联网阅读时间花得值，这一个小时审表的时间至少省了后面十个小时的返工。

数据库实操提示：让AI生成建表脚本的时候，建议明确要求它"所有表使用InnoDB引擎，字符集utf8mb4，时间字段统一为DATETIME类型"，这能减少很大一部分后续兼容性折腾。

3. 核心功能开发的AI实操记录

3.1 权限和登录：一次生成，别让它自由发挥

登录权限模块是所有模块里耦合度最高、出错时最不好排查的部分。我这次的做法是：先让AI一次性把完整的认证流程生成出来，而不是让它分模块零散地给。

我跟AI的说法是："我需要一个登录注册模块，密码需要哈希存储，登录成功以后用cookie保存会话状态，权限分三种角色：成员、项目负责人、管理员。中间件或者依赖注入的方式做路由守卫，未登录的用户只能访问登录页。"

AI给出的代码包含完整的注册登录路由、密码哈希工具函数、会话管理逻辑、权限校验依赖函数。我审查以后发现，它在权限校验上有一个合理的细节处理：普通成员访问项目管理接口时返回403而不是404，这样不会暴露资源是否存在。

这里有一个值得记录的实操经验：让AI生成这类安全相关的代码时，你需要明确要求"密码不能明文存储，统一使用哈希算法加盐"和"所有接口必须做越权校验"这两条硬性规则。如果你不强调安全约束，AI虽然大概率会给出合理的实现，但细节上可能漏。比如它第一次生成的任务更新接口就只校验了"是否登录"，没校验"是否项目成员"，这意味着任何登录用户都能改别人项目的任务。这正是"AI能写但不保证默写对"的典型例子。

3.2 报表模块：AI写逻辑，我调参数

任务填报和周报生成是业务核心。任务填报的逻辑很直白：成员创建任务时关联项目，每次更新时需要填当前进度百分比、状态（待开始/进行中/已完成/阻塞）、备注。周报生成逻辑则需要一些思考：系统要把选定周期内某个项目的所有任务变更汇总起来，按负责人分组，输出一段可读的文本。

AI生成这部分的时候，我输入的提示词是：

"周报按项目生成，包含本周新增任务、完成的任务、进行中任务、阻塞任务，每个成员单独一个段落，格式是：成员名-任务名-状态。考虑到本周可能没有变更，需要一个空数据时的兜底文案。"

AI生成的视图函数做了一件意料之外的事：它自动把周报内容缓存到了数据库的周报记录表里，而不是每次请求都重新计算一遍。这样做的理由是，如果同一周的周报被反复查看或导出，重复查询数据库虽然也能跑，但缓存起来更符合使用习惯。而且基于缓存记录，后续加"历史周报查询"功能就不需要改表了。

我第一次跑通整个周报生成流程时，发现两个数据口径问题。一个是"本周"的界定，AI默认用的是自然周，以周一为起点；但团队习惯是周五为周期终点，所以我把按周分组的边界条件做了调整。另一个是进度百分比这块，如果任务本来就是"已完成"状态，AI生成周报的时候仍然会写"进度更新为80%"，这类已完成任务在周报里需要过滤掉，不然上级看到已完成任务还显示进度更新会被追问。

这轮下来的心得是：业务报表之类的功能，AI能把百分之八十的骨架逻辑搞定，越到口径细节越需要人工介入。原因在于数据口径本质上属于业务约定，而业务约定通常散落在人的脑子里，不会写在任何文档里。

3.3 前端页面：从丑到能用，只需要几轮对话

这个项目的前端没有用复杂框架，就是服务端模板加原生JavaScript。AI负责生成页面结构和基础交互，我负责提意见让它调整。

第一版页面出来以后，视觉上是能用的，但谈不上好看：表单元素排列密集、看板的卡片没有层次、按钮的对齐不统一。我没有自己上手改CSS，而是把问题描述给AI，让它按"简洁后台管理风格"的基调重新调整样式。第二轮它统一了间距和字体大小，把状态标签的颜色区分开来——进行中蓝色、已完成绿色、阻塞红色。第三轮微调后整体观感已经能见人了。

说点实在的：让AI调整UI的时候，别用"好看一点"这种空泛的词，要给它具体的参照和具体的操作指令。比如"卡片区域加白色背景和轻微阴影，圆角8px，间距统一为16px""表格行高44px，支持鼠标悬停变色"。AI十分擅长执行这些明确的设计规则，但不擅长在"好看"这种审美标准下自己悟。

页面交互方面有一个案例值得一提：进度看板需要支持按项目筛选、按状态筛选、按负责人筛选三个条件组合查询。我让AI直接实现时，页面每次筛选都会整页刷新。虽然能用，但体验不太好。我试着让AI改成"用AJAX局部刷新"，它给出的方案是封装一个fetch请求函数，把筛选条件拼成查询参数，替换表格区域的innerHTML。这个实现方式复杂度适中，效果立竿见影。

3.4 一个让AI协作效率翻倍的习惯：维护项目上下文文档

开发过程中我发现一个问题：跟AI对话超过二三十轮以后，它经常忘记项目早期定下的规则。比如反复强调过数据库字段统一命名风格、错误提示统一用中文，但过了一段时间它又按自己的习惯生成代码。

我的对策是在项目根目录维护一个CONTEXT.md文件，把项目的基本信息、技术栈、目录结构、命名约定、常用术语、已知坑都写进去。每次跟AI展开新话题时，第一句话就让它"先读一下项目根目录的CONTEXT.md再回答"。这就像给团队新同事一份交接文档，能极大减少重复说明的次数。

这个文件里我写的内容包括：

• 系统名称和核心业务逻辑的简要描述
• 技术栈和后端框架版本
• 目录结构说明
• 数据库表和各表用途的清单
• 接口返回格式的统一约定
• 前后端样式规范的几条核心规则

这个做法强烈建议每个人都在项目里落地。它不是AI开发时代的专属产物，传统开发里也有，但AI开发场景下它的价值被放大了——因为你面对的是一个记性不稳定、但执行力很强的协作者，一份好文档就是它的"长期记忆"。

4. 测试、修Bug和部署交付

4.1 让AI当测试员，自动补测试用例

开发完成以后，正经测试环节不能省。但传统思维里"让测试工程师写测试用例跑回归"的做法，在这个项目里被我换了个形式：让AI基于现有代码生成测试用例，然后我在一个测试环境里跑真实数据验证。

我给AI的指令是："请基于项目代码，帮我列出核心功能的手工测试用例清单，覆盖正常流程、异常输入、权限边界三种情况，并标注每个用例的预期结果。"

它输出的测试用例有三十多条，分成三类：

• 正常流程：用户注册、登录、创建项目、创建任务、更新任务状态、生成周报、查看看板
• 异常输入：空内容提交、非法日期格式、超长文本输入、不存在的ID访问
• 权限边界：非项目成员访问项目详情、普通成员尝试编辑项目配置、未登录访问管理页面

这份用例清单的价值在于，它把"防呆测试"这类常见但容易漏的点都覆盖了，很多我一开始没想的边界场景它也想到了。实际执行时我跑了大概八成用例，发现了三个问题：

一是注册接口对重复邮箱的校验返回了完整的数据库错误信息，这是安全漏洞，需要改成统一的"邮箱已注册"提示。二是任务状态更新的接口在极少数情况下校验逻辑判断异常。三是周报生成时，如果某成员没有任何任务记录，模板仍然会尝试渲染一个空段落，需要在生成逻辑里加一个条件过滤。

这三个问题在传统开发流程里至少要走一轮"测试发现→提单→开发修复→回归验证"的循环，而在AI辅助流程里，我把报错信息直接复制给AI，它给出修复建议，我在编辑器里接受修改，再重新跑一遍用例确认，整个过程压缩到一个小时内。

4.2 三个必须由人来判断的场景

AI能自动驾驶，但路上有几个路口必须人工接管，这是我跑了整个项目以后特别想强调的：

第一个是数据安全的边界。AI生成的代码不会天然考虑"这条日志会不会记录敏感信息""这个导出功能有没有越权"。我必须在验收时带着安全视角去过一遍，尤其是那些涉及数据导出的接口，要确认普通用户不能通过拼接URL来获取不属于自己范围的数据。

第二个是业务规则中的潜规则。AI理解不了团队内部"只有项目负责人才能归档项目"这种隐含的管理逻辑，除非你显式告诉它。所有这类规则必须在需求阶段就明确写出来，漏掉一条，后面就要返工一次。

第三个是"看起来对但实际不对"。AI写代码时偶尔会一本正经地实现一个与你本意偏离的功能，比如把"按项目生成周报"实现成了"按成员生成周报"，但因为逻辑是自洽的，页面也能跑，如果你只看页面不看细节，很可能发现不了。我在验收时坚持用真实数据走一遍完整流程，就是为了抓住这类偏差。

4.3 部署上线的最后一公里

部署环节，AI能做的和不能做的一目了然。

我在2核4G的云服务器上操作，系统环境是Linux。我把项目文件上传上去以后，AI给出的部署步骤基本是标准流程：创建虚拟环境、安装依赖、配置环境变量、启动服务、配置反向代理。

前面的步骤直接照着做就行，真正需要结合实际情况判断的是两个地方：

一是环境变量配置。AI会在部署文档里给你一个样例配置，但数据库链接字符串、会话密钥这些值需要你自己生成和填写。这个没有商量余地，属于必须人工处理的敏感操作。

二是反向代理和进程守护。为了让服务在SSH退出以后还能继续运行，并且方便以后重启，AI建议用进程守护工具托管应用。我这次直接用系统服务的方式，配置简洁，管理方便。如果对进程守护工具的配置不熟，让AI针对"用系统服务托管Python Web应用"专门生成一份配置文件，然后把路径和用户名变量换掉即可。

部署完以后我做了两轮验证：第一轮是新用户注册到填任务再到生成周报的全流程；第二轮是确认服务器重启后服务能自动恢复。这里建议大家都验一下，不然某天服务器自动重启导致服务挂了你可能连续几天接口异常却不自知。

整个部署过程的耗时大概是：服务器初始化半小时，依赖安装加配置一小时，验证调优一小时。和前面开发阶段相比，这段倒是更传统一些——毕竟服务器是你自己的，网络环境、系统版本、软件版本都需要结合实际情况处理，AI给的参考文档能覆盖大部分，但最后一公里的细节还是得自己确认。

5. "全程没写几行代码"的真相与心得

5.1 AI不是替你写代码，而是改变了你的工作姿势

回顾这个项目从启动到上线，我自己手动敲的代码可能只有十几行，主要是环境变量配置和一些个别配置项的调整。但这不代表我闲着了，在最忙的方案评审和需求确认阶段，我一天的对话轮次超过一百次，审过的代码提交有几十次。

我觉得"用AI写代码"这个表述容易给人错觉，好像人坐在那里等结果就行。实际的工作方式更接近"主编和写手"的关系：你是主编，AI是写手，产出方向、质量标准、兜底措施都得你负责。人一天的工作时间没有缩短，但工作内容从"手动实现"变成了"决策和审查"。

这个转变对效率的提升是实打实的。我统计了一下，这个项目从立项到交付大约是8天。如果按老办法一个人从头写，这个体量的系统至少得两周，而且大概率会有更多细节遗漏。AI压缩的主要是非创造性的编码时间和上下文切换成本，让你把精力集中到真正需要判断力的事情上。

5.2 什么项目不适合这么干

AI端到端交付不是万能的，我在开头说过，现在再展开说说什么情况我会打退堂鼓。

第一类是安全敏感型项目。涉及支付、金融交易、用户敏感数据的系统，AI生成的代码可以作为初稿，但必须有专业的安全审查流程。这不是说AI写的代码一定不安全，而是你无法只通过对话就让AI对完全未知的合规要求负责。

第二类是强交互体验型项目。如果一个系统的核心价值在于流畅的客户端体验、复杂的动画和交互设计，AI自动生成的页面会明显偏"后台管理风"，达不到这类项目的要求。

第三类是强领域知识型项目。如果你的业务逻辑依赖特定的行业规则，比如复杂的计费规则、专业领域的计算逻辑，AI可能会生成结构完整但规则错误的代码。因为它不知道行业规则，如果你不知道要去告诉它，这个错误就很难被发现。

第四类是遗留系统改造。对接老系统、修复历史问题，这类工作需要的不是生成能力，而是排查能力。AI对老代码的理解深度有限，如果你自己都说不清老系统的规则，AI更不可能帮你弄清楚。

5.3 给想尝试的人几条实在建议

如果我只能给三个建议，那就是：

第一，从一个全新项目开始，因为你掌控的信息量是完整的，AI知道的也只是你告诉它的，这样不会出现信息差导致的返工。

第二，把需求想清楚再动手。我见过很多翻车案例，本质上不是AI不行，而是需求本身是糊涂的。你把需求原话发给AI，它尽自己理解力帮你做，做完了发现不对，这锅有一半在你。

第三，保持代码审查的习惯。AI生成的代码，看不懂的地方当场问它"这行为什么要这样写"，让它解释清楚再接受。所有不清楚的实现都会变成未来的坑。

最后再分享一个我的个人习惯：每次项目结束，我会把这次和AI协作时用的好提示词、容易踩的坑、项目里定下的规则，都整理到一份自己的速查文档里。下次做类似项目时，拿出来直接复用，效率还能再高一截。AI开发这件事，积累的不只是代码资产，更是你跟这个工具协作的默契。

说到底，全程没写几行代码这事，真的一点都不魔幻。工具在往前跑，你只要愿意调整自己的工作方式、承担好决策和审查的角色，就能用一个更高效的方式把项目交付掉。下一次技术栈更新、工具升级，我还会继续用这套思路去跑新项目——毕竟，干活的人尝到了甜头，很难再往回走。