1. 项目缘起为什么我会把整个交付链路压到 AI 上AI Coding 喊了一整年我看过太多人拿它写工具函数、做代码补全、生成单元测试但很少有人真正敢把一个“从需求到上线”的完整项目全部交给 AI 来推进。原因是这个链路里的变量太多了需求拆解、数据结构设计、接口约定、前端状态管理、部署脚本、环境变量、数据库迁移任何一个环节断掉整个项目就卡死。我给自己定了一个三个月的实验目标只靠 AI 对话把一个带登录、项目看板、任务流转、定时邮件和支付回调的小型 SaaS从零推到生产环境。不是写 demo不是做一个只有两个页面的壳子而是要让它经受住真实用户的使用。说实话刚开始我自己也没底。因为我见过 AI 写出的漂亮代码背后藏着多少坑也见过 agent 类工具信心满满地改坏一个配置文件。但这个实验值得做因为团队里的初级开发正在越来越频繁地用 AI 完成本应由他们独立负责的工程任务我想用最直接的方式搞清楚AI Coding 的能力边界到底在哪里人在这个链条里还剩什么不可替代的工作。1.1 这三个月我到底想验证什么在此之前我用 AI Coding 做过不少零散的事情写爬虫脚本、生成正则、补测试用例、把一段老 PHP 代码翻译成 Go。这些任务全部是“点状”的输入和输出都足够清晰AI 的上下文不需要跨过太多层。但一个完整产品是“网状”的用户表要关联项目表项目表要关联任务表任务表又要关联操作日志表前端一个按钮改动后端可能涉及三个接口的变更。我想验证的正是 AI 在这种长链路、多依赖、强约束场景下能保持多大的稳定性。另一个想验证的点是成本。这里说的不是 API 调用费用而是“人的纠错成本”。很多团队引入 AI Coding 之后发现代码生成速度是快了但 review 的时间翻倍了因为 AI 会在你没注意到的地方自作主张。我要在项目中真实记录这样的时间消耗什么环节 AI 能直接交付什么环节必须人工重写。1.2 定义一个“可验收”的 AI Coding 项目为了让实验有意义我没有选那些网上教程里的经典案例比如待办清单、博客系统、聊天室。这些例子被训练数据覆盖得太充分AI 可以凭“记忆”输出相似结构根本测不出真实能力。我选的是一个体格适中、边界清晰的场景团队任务管理工具。核心功能只保留六项邮箱密码注册登录、创建团队和邀请成员、创建项目并设置状态流转规则、任务评论和附件上传、每天上午九点发送任务摘要邮件、接入支付网关完成 30 天试用转付费。这个规模刚好卡在一个临界点上功能量不算大但已经涉及认证、RBAC 权限、文件存储、异步队列、定时任务、第三方支付回调这些非常“工程化”的模块任何一个模块都需要几十次上下文交互才能做完足以暴露 AI 在长任务里的弱点。1.3 项目全景一个真实的小型 SaaS 长什么样技术栈我让 AI 自己选但给了它硬性约束前端用 Next.js后端用 FastAPI数据库用 PostgreSQL缓存和队列用 Redis部署用 Docker Compose 跑在一台 4 核 8G 的云主机上。选择这个组合的原因很简单它是一个没有明显偏科的组合前后端语言分离数据库和缓存区分明确AI 在这个组合下的训练样本足够多不至于因为冷门框架而失灵。整个系统包含三个子服务Web 前端、API 后端、Worker 进程。Web 前端负责页面交互API 后端负责业务逻辑Worker 负责处理邮件和支付回调。三个服务通过 Redis 队列和 PostgreSQL 通信。这个架构刻意选择了微服务的“低配版”因为如果 AI 连这种清晰的服务边界都搞不定那我也不会把它往更复杂的架构上推。整个实验走下来我最大的感受是AI Coding 真正的瓶颈不在生成代码而在需求拆解和工程判断。后面我会把每一阶段的实操方法、提示词模板和踩坑过程完整写出来这些都是可以直接抄走的。2. 写代码之前提示词框架决定了 AI 的发挥上限很多人在 AI Coding 项目里翻车第一刀就砍在需求描述上。上来就是一句“帮我做一个任务管理系统”AI 回了一段漂亮但完全不可用的代码双方开始拉锯你说它做错了它道歉然后给你另一段同样不可用的代码。这不是 AI 蠢而是它真的不知道你想要什么。我给这个阶段的定位是提示词不是“提需求”而是“下达工程指令”。2.1 AI Coding 最常见的翻车起点需求一两句话一句话需求最大的问题不是信息少而是“歧义多”和“假设多”。当你告诉 AI 做一个任务管理系统它会默认按 Trello 或 Asana 的样子来但你可能只是想要一个内部排期表当你告诉它用户有管理员和普通成员两种角色它会默认管理员能删一切但你的业务规则是管理员也不能删已归档项目。这些默认假设在人工智能生成的代码里表现为一堆你根本不想接受的“隐性需求”。AI 不会承认自己不理解。它会照着概率分布往下编直到你在 review 的时候发现权限逻辑错了、页面多了莫名其妙的筛选条件、数据库里多了一张它自己发明的表。所以在我这个项目里第一轮对话不写任何代码只做需求收敛。2.2 我沉淀的一套四层提示词框架如果你想复现我的过程可以直接使用这套框架分成四层往下压每次只给 AI 增加一类信息不要堆在一段话里一次发出去。第一层是“角色和项目背景”告诉 AI 它是什么角色、在做什么项目第二层是“功能范围和边界”明确列出要做什么和不做什么第三层是“技术约束”指定框架、数据库、部署方式第四层是“输出要求”规定当前这一轮只产出什么内容不产出什么内容。拿我的项目举例第一轮提示词是这么写的你是一名有十年经验的全栈工程师正在为一个团队任务管理 SaaS 项目做架构设计。 项目核心功能 - 用户通过邮箱和密码注册登录 - 用户可以创建团队通过邮件邀请成员 - 团队内可以创建多个项目 - 项目内任务具有状态流转支持自定义流转规则 - 任务支持评论和附加上传 - 每天早上九点发送任务摘要邮件 - 用户可开通 30 天免费试用之后通过支付网关付费订阅 明确不做的事情 - 不做实时在线协作编辑 - 不做移动端原生应用 - 不做复杂的自定义报表 技术约束 - 前端Next.js TypeScript Tailwind CSS - 后端FastAPI SQLAlchemy - 数据库PostgreSQL 15 - 缓存和队列Redis - 部署Docker Compose 本轮输出要求 - 只输出需求关键词列表 - 只输出数据模型设计用 SQL 建表语句表示 - 只输出 API 接口清单不要写实现代码 - 列出你认为需要我确认的业务规则问题这个提示词拉得很长但它值得。你把边界划清楚了AI 在后续代码里自由发挥造成的灾难就少了一大半。关键是“明确不做的事情”这一项大多数人都忽略了它而这恰恰是防止 AI 给你塞私货的最有效手段。2.3 技术选型让 AI 做决定我做复述确认在我这个项目里技术栈其实是我预设好的但我仍然让 AI 做了一轮技术选型分析。这不是为了形式主义而是为了让 AI 理解这套技术栈里的依赖关系。当它理解为什么选择 FastAPI 而不是 Django 时它在写代码时会更注意 SQLAlchemy 的异步会话管理会更注意 Pydantic 的校验机制而不是把 Django 的思维模式带进来。你可以在工程里做相同的事让 AI 列出每一种技术选择的“代价”然后你来确认。例如我刚才提到的技术栈AI 会指出 Next.js 的服务端组件和 FastAPI 的 REST API 之间存在重复的接口模型定义建议用 OpenAPI 自动生成前端类型。这个建议很实用所以我在项目里引用了它。它还会指出Docker Compose 写三个服务比 Kubernetes 更合适因为项目早期不需要动态扩缩容。这个判断也节省了我不少精力。这轮确认结束之后项目才算真正奠基。后面所有代码都基于这个框架生长而不是从一句“帮我做个任务管理”开始漫无边际地生成。3. 需求到 Demo把“生成计划”和“生成代码”分成两件事AI 代码生成最大的错位在于用最终代码的形态去回答一个尚未收敛的问题。如果我让 AI 直接写注册登录接口它大概率会定义好一张用户表同时给你带上传头像功能。所以在生成任何业务代码之前我先让 AI 产出“计划性文件”把需求转成可审查的产物。3.1 第一轮只输出用户故事、数据模型、API 清单我用第一轮提示词拿到了三个文件需求关键词列表、SQL 建表语句、API 接口清单。这个环节的核心价值是让我能够以最低的成本检查 AI 对业务的理解是否正确。改一段 SQL 建表语句的成本远远低于改 500 行路由代码的成本。我拿到的建表语句关键部分长这样CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), email VARCHAR(255) NOT NULL UNIQUE, password_hash TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE teams ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name VARCHAR(255) NOT NULL, owner_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE team_members ( team_id UUID NOT NULL REFERENCES teams(id) ON DELETE CASCADE, user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE, role VARCHAR(20) NOT NULL DEFAULT member, PRIMARY KEY (team_id, user_id) );除了数据表AI 还列了 28 个接口我逐一对照功能需求圈掉了其中 6 个“看起来有用但实际没人会用”的接口例如“更新团队头像”和“批量导出任务 CSV”。这两件事在我的 MVP 阶段确实不属于核心路径砍掉它们可以让第一版至少节省两天开发量。这个阶段恰恰是人不应该交给 AI 的地方产品判断。3.2 第二轮让 AI 围绕数据模型生成可运行骨架当数据模型和接口清单确认后我让 AI 进入第二轮按模块输出代码。这里有个操作细节不要让 AI 一口气生成整个项目。那种做法的问题在于任何微小的设计缺陷会贯穿全项目导致后面修一处崩三处。我按模块顺序逐个生成顺序是数据库会话管理 → 用户认证 → 团队和成员 → 项目 → 任务 → 评论和附件 → 邮件队列 → 支付回调。每个模块的提示词都遵循同一个模式把上下文贴进去把对应表的 DDL 贴进去把接口清单贴进去要求它只生成这个模块代码。比如任务模块的提示词开头这样写数据模型已确定以下是任务表 DDL请为任务模块生成 FastAPI 路由、Pydantic Schema、业务逻辑层和对应的 SQLAlchemy Model。 要求 - 不要修改表结构 - 不要创建任务表之外的任何新表 - 状态流转规则使用一个 status_config 表来驱动 - 所有接口返回统一格式{code: 0, data: ..., message: ok} - 不要写完整项目代码只需要本模块这个“不要修改表结构”的约束是我被坑过之后加的约束。AI 第一次生成任务模块时发现任务表缺少一个 position 字段没跟我商量就加上了导致开发环境数据库和已确认的建表脚本不一致。这种“自作主张”在小模块里只是一个小麻烦在大型项目里会演化成什么没人能预料。3.3 人工守门检查这五个节点再进入下一轮在每个模块的交付中我不会直接看代码细节而是检查五个节点第一新建的表是否超出数据模型范围第二接口是否按照约定的路径和请求方法生成第三鉴权逻辑是否正确地加在需要保护的路由上第四字段校验是否参考了前端的输入约束第五是否引入了数据模型之外的新依赖库。只有这五关全过我才会让 AI 进入下一模块开发。这五个检查点实际上是项目里最容易让 AI 犯错、也最容易让团队产生债务的地方。把守门动作放在模块生成阶段而不是放在集成阶段能减少大量返工。我实测下来单模块检查平均只需十分钟但如果等到所有模块生成完再检查定位问题的时间会翻三倍以上。4. 工程化关卡AI 生成的代码要过哪些质检能让项目跑通是一回事能让项目经得住代码 review 是另一回事。AI Coding 生成代码的速度确实快但它默认的代码风格、错误处理、日志输出和边界条件处理都存在明显的“写作业”痕迹。写作业追求的是答案正确而工程代码追求的是行为可预期、故障可恢复。这两者之间的距离需要靠人工质检来填补。4.1 我让 AI 给自己做 code review 的三种方式第一种方式是“白盒审查”。我会把一个模块的代码整段贴给另一个对话窗口不加任何背景只加一行指令“请以一名严格的技术负责人身份审查以下代码输出问题清单按严重程度排序并且不要修复只列出问题。”这种方式能得到一个很客观的视角AI 会指出 SQLAlchemy 查询没有使用索引列、某个事务在异常时没有回滚、密码哈希算法使用了过时的黑名单模式。第二种方式是“角色对调”。我会让同一个对话用两种身份轮流审视代码先用安全工程师视角找漏洞再用运维工程师视角发现部署隐患。这个方法的妙处在于生成代码的那个 AI 已经对这段代码有了“作者滤镜”但切换成另一种角色后它会主动识别出刚才自己留下的问题哪怕这些问题在作者视角下被认为是合理的。第三种方式是“按需解释”。我会挑几个关键算法路径例如支付回调的幂等处理、邮件队列的重试逻辑让 AI 把执行流程用文字描述出来。很多时候 AI 代码能跑但它自己解释不清为什么要这样写。一旦出现这种情况那这段代码的稳定性就值得怀疑因为 AI 可能是从训练样本里“抄”了一个模式拼上去的并没有理解它旁边的边界条件。4.2 补测试的正确姿势别让 AI 画蛇添足让 AI 生成测试用例是当前被严重低估但又被同时严重误用的功能。低估在于 AI 确实擅长写测试误用在于很多人把它用在纯单元测试层面结果产出一堆断言实现细节、但不保护行为逻辑的脆弱用例。我让 AI 写测试的一个关键技巧是给它行为场景而不是函数名。比如我要求 AI 为“任务状态流转”写测试会这样描述场景为一个看板项目的任务状态流转逻辑添加测试用例覆盖以下场景 - 创建任务时默认状态为 todo - todo 状态可以转到 doing - doing 状态可以转到 done - done 状态不能直接跳回 todo - 只有项目经理可以执行状态回退操作 - 未知状态名报错且不改变当前状态这种方法生成出来的测试用例关注的是业务规则而不是某个函数的内部实现。而测试的使命恰恰是捕捉业务规则的意外变化。如果未来有人改了状态机把这些规则破坏了AI 生成的测试会直接把它拦住。相反针对函数实现细节生成的测试代码一重构就反而误报最后维护成本高到团队干脆放弃测试那一切都前功尽弃了。4.3 重构指令怎么让 AI 识别并消除重复代码项目推进到中期重复代码一定会出现。三个模块里各有一份邮件发送逻辑两个接口都有分页参数处理。这些是我用肉眼发现的我想看看 AI 是否能主动识别。结果是如果你不给它明确信号它默认不碰这些问题。于是我在所有功能开发完成后专门开了一把重构对话给它一份服务端代码树和重复代码的具体位置要求“只做结构性重构不改变任何接口行为和数据库结构”。AI 在重构方面的表现比我想象中要好。它能快速提取公共基类、抽取工具函数、统一响应封装。但它有个致命毛病重构成瘾。有一次它把我三处本来逻辑相同但参数默认值不同的分页逻辑强行合并成了一个函数然后不同模块传入不同的默认参数导致前端从某一页获取数据时页数偏移一位。这个 bug 直到联调阶段才被发现。教训是AI 重构后的代码必须立刻跑一遍相关模块的测试套件这个动作不能省。5. 上线前最容易出事故的环节AI 测试和真实数据的差距如果说写代码阶段是 AI 的高光时刻那测试阶段就是它的照妖镜。AI 生成的测试用例经常出现一个共同特点覆盖率一张漂亮的成绩单但实际业务风险一个都没拦住。原因很简单AI 本质上是一个统计模型它写测试时倾向于模仿“测试长什么样”而不是思考“哪些场景可能真的出错”。5.1 AI 测试的盲区我让 AI 给文件上传模块写测试时它的自动化测试覆盖了文件大小限制、文件类型校验、上传成功后的 URL 返回。看起来无懈可击但漏掉了三个真实场景同一个用户并发上传多个文件时文件名冲突的处理上传过程中数据库连接中断后的残留文件清理附件表记录和对象存储中实际文件不一致时的对账逻辑。这三个场景不是 AI 不聪明而是它缺乏对真实运行环境的感知。所有测试跑完后我至少加了三类它没有考虑的用例断网、权限过期、并发冲突。这些被称为“混沌场景”的测试与其说是 AI 的能力边界不如说是一个工程项目的底线。遇到这种情况我会把这类缺失场景以提示词的方式给到 AI让它为这些“故障场景”重新设计测试计划。它生成的计划同样会漏掉一些细节点但用它跑完我也能省去不少底层的低级错误。5.2 用真实流量场景倒推测试用例一个对我帮助很大的方法是用“如果用户在这里卡住会发生什么”这个问句把整个产品过一遍。比如用户注册后邮箱收不到验证邮件怎么办不是让 AI 检查代码而是让 AI 描述用户看到的界面、邮件服务返回的错误、日志里应该出现的关键词、以及客服应该给出的标准答复。以这种方式写出来的“测试”已经不是单纯的测试代码了它是一份完整的产品排障手册。AI 做这种排障手册非常擅长因为它只需要组合知识不需要真正执行代码。这些“如果”场景中的一部分会被我转成自动化的集成测试用例另一部分被写进项目文档里的 FAQ还有一部分会被设计成监控告警规则。比如“邮件发送失败率超过 5%”会触发 P1 告警这类告警规则的阈值设定是在测试阶段通过推演场景得到的而不是等线上事故真正发生了才手动加。5.3 一次由“想当然的参数”引发的线上拦截在支付回调模块的测试中AI 曾经自信地把回调签名校验参数直接写死成一个固定值。当时它的理由是“测试环境里支付网关不会真正回调所以用一个模拟值就够了”。我没有直接拒绝而是让它设计一套模拟网关回调脚本用一个在测试环境真实运行的本地 HTTP 服务模拟支付网关的行为。结果这套脚本在集成测试阶段就发现了问题真实支付回调的签名串中有一个动态时间戳字段AI 之前写死的固定值导致每次回调都以签名过期被拒绝。如果这个问题没有被拦截用户第一次真实付费就会失败那是任何初创团队都承受不起的事故。从这次经历里我总结出了一条铁律AI 说“测试环境无所谓”的时候我都默认它有所谓AI 说“这个参数本地自己看”的时候我要追问生产环境怎么办。6. 部署与运维AI 能把 CI/CD 这条流水线管到什么程度部署是检验一切工程的最终战场。代码写得再好环境配置一旦冲突一切都凉。AI 在这个环节的表现取决于它对你的基础设施了解多少。很多人的 AI Coding 项目没有走到这步不是因为代码写不出来而是因为部署环节的交互相较于编码阶段会多出无数个环境细节AI 不知道你的主机上还跑着哪些进程不知道你的域名解析方向不知道你的证书续期逻辑。6.1 我构建的一条完全可复用的部署流水线为了让 AI 能真正管理部署我没有让它凭想象写 Dockerfile 和 Compose 文件而是先把主机环境的体检报告喂给它。我执行了 uname -a、docker version、free -h、df -h、ss -lntp把输出去掉敏感信息后交给 AI。让它基于这些信息写一套生产环境的 Docker Compose 编排。它产出了三个核心文件Nginx 配置、后端 Dockerfile、前端多阶段构建 Dockerfile。最关键的是它写对了多阶段构建前端构建阶段用 Node 镜像运行阶段用 Nginx 镜像把构建产物拷贝进 Nginx 的 html 目录这样最终镜像体积能控制在 80MB 左右而不是带着一整套 Node 运行时上生产。这些内容虽然网上教程里到处都是但由 AI 生成确实快得多。不过部署文件里的安全项例如数据库密码、JWT 密钥、支付网关密钥它一律生成了示例占位符这点让我很满意。我自己的补充是加上了健康检查。AI 默认只在 docker-compose.yml 里写了 depends_on没有写 healthcheck。这个问题的严重性在于如果后端还没完成数据库连接初始化Nginx 已经收到流量转发了前端页面会立刻报 502。把这些 healthcheck 补上之后云端主机的重启流程才真正稳定下来。6.2 监控告警的自然语言化尝试项目上线后少不了一堆监控面板包括 CPU 使用率、内存占用、磁盘空间、API 响应时间、数据库连接数、Redis 内存碎片率。这些指标本身不难做市面上现成的监控方案很多难的是告警规则配置。AI 在这块的优势在于它能用自然语言描述一个故障场景然后映射成一组查询语句。我问它的最有效的句子是“如果今天 80% 的 API 请求响应时间超过 2 秒并且持续 10 分钟以上请帮我生成一条 PromQL 和对应的告警文案。”它返回了一条可用的 alert 规则然后我把它写到 prometheus 的 rules 文件里。对比我自己手写 PromQL这个过程至少节约了半小时而且告警文案写得更像正常人类会读的东西而不是一串冰冷的标签。告警不仅限于性能指标。我让它设计了两条业务告警每日邮件发送失败率超过 5% 时通知管理员支付回调成功但订单状态没有更新时立刻告警。第二条是我最关心的它代表资金和业务系统之间的断点。AI 能根据业务描述反向定位到日志关键词和查询逻辑这是传统监控配置方式完全没法比的效率。6.3 回滚不是失败而是发布计划的组成部分上线不会总是一帆风顺。第一次正式发布后前端出现了一个偶发的白屏问题原因是 Next.js 构建产物里有一份编译缓存的错误 chunks 映射刷新页面能从缓存恢复但首次加载时偶发失效。我虽然没有直接让 AI 修复这个问题但让它设计了一套可回滚的部署方案每次发布前将当前镜像打上带时间戳的 tag例如 backend:20260612-1530并保留最近五个版本发布后运行一组 smoke test如果失败超过两个关键用例便执行一键回滚。这套方案的执行一点也不复杂却让“会不会出事故”和“出了事故要花多久恢复”这两件事被彻底分离。好的工程不是不出问题而是出了问题之后有一个已经演练过的恢复路径等待执行。AI 在这个环节给我的最大帮助不是写回滚脚本本身而是帮我审视了回滚脚本里一个容易忽略的问题回滚数据库迁移。如果新版本的某个迁移已经执行过了数据库就无法简单回退到上一个状态需要先生成补偿迁移。这个坑非常深如果不是 AI 提醒我大概率会在回滚时把数据库搞挂。7. 踩坑实录AI Coding 最容易翻车的五个场景整个项目走下来问题一个都没少遇到。这里记录的不是 AI 代码能力的问题而是在真实工作流中AI Coding 最典型的五个翻车点以及我最后是怎么绕过去的。7.1 场景一无限“下一步”循环AI 在某些不确定需求下会选择不直接回答而是抛问题而它每一次提问都很有道理。问完认证方案问数据冗余策略问完冗余策略又问缓存一致性来来回回十几轮没有任何代码产出。这种场景里越聊越焦虑因为你感觉自己像是在和一位不愿开工的咨询顾问开会。我的解法是给 AI 设置“默认决策”机制。在第一轮提示词里就添加一条“如果我的需求描述存在歧义你按行业惯例做最稳妥的假设然后在输出末尾列出假设清单让我一次性确认”。这样可以避免把 AI 的周到礼貌变成打磨时间的陷阱。确认假设清单的时间远少于被它连环提问的时间。7.2 场景二API 文档过期导致幻觉参数AI 训练数据中的 API 参数信息有时间截点。举例来说如果新版框架修改了某个函数的默认行为AI 依然会按旧版参数生成。我遇到的典型案例是文件上传库AI 生成的上传代码使用了一个在新版中已经被移除的参数代码在本地就能跑但在生产环境抛 TypeError。修复方法只有一个硬办法让 AI 在生成代码前联网搜索当前版本的官方文档整理出关键 API 的签名和弃用项然后附在提示词里。不要让 AI 凭借记忆写库调用尤其是那些更新频繁的基础库包括 ORM、队列、支付 SDK 和认证中间件。在 AI Coding 里上下文信息是否新鲜和提示词是否精确重要性不相上下。7.3 场景三数据库迁移被 AI 做得太“聪明”AI 看到我们用户表的 email 字段没有加索引自动在迁移脚本里加了一个索引同时还给任务表补了一个外键约束。这些“拾遗补缺”看起来是善意的但它会直接导致线上数据库迁移失败因为生产环境里那个外键字段的历史数据并不满足约束条件迁移一旦执行就会在中途 abort。我把迁移脚本的自主权完全收回到人工手上。数据库表结构变更必须走一个单独的流程让 AI 生成迁移 SQL我再逐条人工审核审核通过后在临时数据库里跑一遍然后才能应用到生产环境。数据库结构是整个系统的地基地基的变更不能被“顺手优化”蒙混过去。7.4 场景四测试覆盖率的假象AI 生成的测试能让覆盖率统计数字变得很漂亮但那些测试很多是空转的。例如它写了一个“创建任务成功”的测试只验证接口返回 200 和任务 ID 不为空完全不验证状态流转规则、权限控制和脏数据清理。真正的业务核心逻辑覆盖率可能只有 20%。我的应对做法是反向考核把线上已经发生的 bug 逐个交给 AI让它为每一个 bug 写一条回归测试。这样积累下来的测试集不是为了覆盖而覆盖而是为了守住已知战场。这比让 AI 去猜还有什么函数没测到更高效因为线上 bug 名单就是最真实的风险清单。7.5 场景五AI 主动引入安全隐患最需要警惕的是 AI 在代码中写死密钥。它会在本地开发配置里生成一个 JWT_SECRET 常量然后顺手写在 settings.py 里再在后面引用。如果这些代码被提交到公开仓库密钥直接就暴露了。AI 还会忽略密码错误次数的锁定逻辑或者把管理员接口放在没有鉴权的路由组里因为它没有把安全策略当作默认约束。安全处理不能靠 AI 自觉。我在每次生成模块代码后都会在人工检查清单里固定加两项搜索项目中是否有类似 secret、api_key、password 的硬编码值检查所有写操作接口是否都带了登录状态依赖。这两项检查操作简单但每一条都需要由真正的负责人亲手执行。8. “AI 全搞定”这句话的正确理解方式项目最终从需求走到线上中途经历了很多意外但结果是好的。它稳定运行了一个多月真实用户也开始使用了。回到标题里的那句话AI 真的全搞定了吗我的答案是需要拆分成两个层面去理解。第一层代码实现层面AI 的能力已经达到了“可交付”的合格线。第二层工程交付层面AI 仍然需要人来做产品判断、架构决策、安全审计、数据兜底和告别假象。AI 的“全搞定”是建立在人的判断能力足够用来校准它的前提之上的。8.1 人和 AI 的边界到底划在哪里这次经历之后我给自己划了一条比较清晰的边界凡是能用明确规则描述的任务AI 可以直接交付例如按数据库表生成 CRUD 接口、写测试用例、做代码格式化、写 Dockerfile。凡是需要用经验和判断力做权衡的任务AI 只能给建议不能直接拍板例如数据模型设计、第三方服务的选型、权限模型的设计、事务边界的划分。凡是需要跟外部系统联调的任务AI 的产出必须经过真实环境验证不能只看单测通过就终止例如支付回调、邮件服务、对象存储。这三条边界目前我用得很顺手它不会让我担心代码里有暗雷也不会让我在 AI 能胜任的事情上浪费时间。8.2 什么项目不适合全 AI Coding我也要泼一盆冷水。如果项目高度依赖既有的复杂业务规则或者涉及非常特殊的数据合规要求又或者系统需要与大量老旧内部系统交互这些场景不建议把核心链路完全交给 AI。AI 的强项是基于公开知识生成通用模式而那些沉淀在组织内部系统里的隐含规则AI 可能根本不知道也不应该知道。拿我们的支付模块举个例子虽然 AI 写出了完整的回调处理逻辑但支付网关的密钥管理策略、订单对账逻辑和对失败交易的人工介入规则全部是我自己补充的。这些内容来自真实业务经验和风险偏好AI 无从学习也无法替我判断。8.3 我现在的一套“半自动”交付节奏经过三个月实验我现在已经形成了一套实际的交付节奏。需求文档出来后AI 负责把需求拆成用户故事、DDL 和接口清单我负责业务规则确认。在代码阶段AI 按模块生成代码我执行五节点检查然后再让 AI 做 code review针对问题给出修复方案。测试阶段AI 写基础单测和接口测试我在关键业务场景上补充混沌测试和故障场景。到部署阶段AI 生成部署文件和告警规则我审核安全和回滚逻辑。整套流程下来交付速度大概是传统方式的 2.5 倍到 3 倍。最后说一个细节上的心得。让 AI 全搞定并不意味着你可以在项目里当甩手掌柜恰恰相反它对你的判断力要求更高了。你要在 AI 产出正确代码之前知道什么是正确要在 AI 过度设计之前知道你不需要什么。这比亲自写代码需要更宏观的工程思维能力。如果你也想做一次类似的实验我的建议是选一个小而完整、边界清晰的项目准备好足够的耐心和判断力然后把注意力从“怎么写代码”转移到“怎么定义任务”上。你会在项目结束时发现自己收获的不仅是一个系统还有一套重新理解了 AI 和人的关系的工作方式。