前阵子我用 AI 端到端交付了一个给朋友公司做的内部报价工具从需求梳理、代码生成、测试部署到客户培训全程我亲手写的代码加起来算上配置大概不到十行。准确说是只有几行环境相关的配置代码。听起来像爽文但这是一次有完整交付物、已经完全跑在客户内网里的真实项目不是 demo不是玩具。我甚至到最后复盘时自己都觉得离谱以前一个至少排三天工期的小项目这次两天收工而且大部分时间花在需求确认和部署沟通上真正面对代码的时间其实很少。先交代一下背景。朋友开了一家做工业耗材贸易的小公司业务员每天要给不同客户发报价单。之前的方式是打开 Word 模板复制粘贴产品明细手动改单价、改折扣、改有效期再拿计算器算总金额。碰上客户多的时候一天二十多份报价单光核对金额就要花一两个小时还偶尔把 A 客户的价格错发到 B 客户那边。他问我能不能搞个工具业务员只要整理一个 Excel 表格丢进去系统自动生成带编号、带有效期、带合计金额的 PDF 报价单最好还能带上公司自己的 logo 模板。这个需求本身不复杂但真正交付到“能用”的程度链路其实一点都不短前端页面、后端接口、数据存储、Excel 解析、PDF 生成、金额计算、部署脚本、操作文档全都要有。以前这种项目我至少要排三天工期其中一大半会耗在重复的 CRUD 和调 PDF 样式上。这次我决定整条链路全部让 AI 参与看看端到端 AI 交付到底能把人力和时间压缩到什么程度。1. 先说清楚背景我交付的到底是什么项目1.1 需求源头一次看似简单实则坑很多的报价单批量生成朋友最初找我时说得很轻巧“你就帮我搞个网页传 Excel 上去点一下按钮自动生成 PDF 报价单就行。”但实际一聊发现这里面有很多隐含需求报价单要按公司模板排版左上角是 logo中间是客户信息和报价编号下面是产品明细表格最后一栏是含税总金额和报价有效期还要支持对不同客户使用不同的折扣率。更麻烦的是业务员不一定会按固定格式填 Excel他们可能在表里加一行备注或者把产品名称写得长短不一这些都需要系统能合理处理而不是直接报错。我花了一个晚上把朋友发来的两三个 Word 和 PDF 示例文档整理成结构化需求输入是一份标准 Excel 表格包含产品编号、名称、规格、单位、单价、数量、折扣率这几个固定列输出是一份 PDF 报价单文件名格式是“报价单-客户名-日期.pdf”并且要自动生成一个不重复的报价编号。数据量很小一天最多几十份报价单没有多用户登录需求没有审批流只要部署在办公室内网服务器上业务员通过网页访问就行。这个需求最适合拿来验证 AI 端到端交付原因有两个。第一逻辑边界非常清晰没有任何模糊的算法就是标准的增删改查加文件转换第二所有技术点都有极其成熟的开源方案PDF 生成、Excel 解析、Web 框架都是现成的AI 不需要发明任何东西只要把组件组合起来。换句话说这是一个“工程型需求”而非“科研型需求”AI 最擅长处理的就是这种组合式任务。1.2 为什么我敢说“全程没写几行代码”我需要先给“没写几行代码”画个边界免得被误解成“完全甩手”。事实是我全程没有写过一段业务逻辑代码没有写过 API、没有写过 PDF 生成逻辑、没有写过数据库表结构、没有写过前端页面。我做的事情是把需求变成 AI 能理解的规格描述审核 AI 生成的每一步代码决策技术选型让它对照报错改 bug最后负责部署和客户验收。我唯一手动改动的几行是部署时让人头疼的绝对路径和端口配置这类东西藏在本机环境里AI 再怎么聪明也猜不到客户服务器上会把项目放在哪个目录。这其实是一种很微妙的状态你明明是项目负责人对最终交付物负全责但你不再是“打字的那个人”更像是“带实习生干活的那个人”。你下发任务、审查产出、验收结果。刚开始我还会下意识地自己动手去改代码后来发现完全没必要——把报错信息连同一段上下文描述丢回去AI 给出的修改方案往往比我自己改得更快因为它是基于整个项目上下文来做修改而不是只盯着当前那个文件。1.3 我自己定的三条交付纪律决定尝试全 AI 端到端之前我先给自己定了三条纪律这些在后面整个过程中帮我避开了不少坑。第一条AI 生成的代码必须先跑通最小闭环再做功能增强。很多人在让 AI 写代码时会一次性要求“把所有功能都做了”结果得到的代码动辄几十个文件、几百个依赖跑都跑不起来。我先让它生成一个“能上传 Excel、能生成 PDF、能显示成功页面”的最简版本确认整条链路通了再逐步加功能。第二条所有涉及价格、金额的计算必须人工逐行 review并且做交叉验证不能把 AI 生成的算法直接当成最终答案。金融数据无小事哪怕这是个内部工具万一金额差了业务员拿去发给客户就是事故。第三条对客户完全透明我明确告诉朋友这个项目是 AI 辅助开发的我承担最终责任后续功能迭代可以继续用同样模式但不能指望 AI 自己保证正确性。把边界说清楚后面维护才不会变成烂账。2. 需求拆解把口语需求变成 AI 能理解的规格2.1 关键动作先让 AI 帮忙生成需求文档而不是直接生成代码朋友给到我的材料非常零散几个旧的报价单示例、一个大致的 Excel 表格、几条语音消息。按照我往年接活的做法我会花半天时间自己把这些整理成 PRD 再动手但这次我试着先把素材丢给 AI让它把零散的例子归纳成结构化需求。这个方法挺管用的我把朋友的原话、示例文件里的字段截图、旧的 PDF 报价单拍照全部贴给 AI要求它输出一份“系统功能清单 验收标准 字段规则表”它很快列出了十几个潜在问题比如“报价编号的日期格式是年年-月月-日日还是年年月月日日”“折扣率是填 0.85 还是 85%”“产品数量是否允许小数”。这些细节我一开始完全没想到而朋友其实也一直没意识到自己有这么多隐含规则。这里我强烈建议如果你也想这样干不要一上来就让 AI 写代码先让它写需求文档。代码是可以不断改的但需求文档决定了对话方向。AI 在没有完整上下文的时候会默认给你设计登录功能、操作日志、甚至角色权限你可能只是想要一个业务员能用的简单工具而已。让 AI 先产出文档你作为人来审核和补充远比让 AI 先埋头写代码再推倒重来效率高。2.2 我实际使用的三段式 Prompt角色、约束、交付物在正式让 AI 写项目之前我给它设置了一个覆盖全局的系统提示词后面所有对话都基于这个上下文。我把这种写法叫三段式描述角色、约束、交付物。角色你现在是一个熟悉 Python FastAPI、Vue 和 SQLite 的全栈工程师你的目标是帮我实现一个内部报价单生成工具你的代码要干净、可维护注释用中文。约束技术栈固定为 Python 3.11 FastAPI SQLite Vue 3不用 Redis不用 Docker Compose不做多用户登录不做复杂的权限系统。前端页面要风格简单业务员使用不需要花哨特效。所有金额字段必须使用 Decimal 而不是 float避免浮点精度问题。PDF 生成使用开源的 reportlab 方案。交付物需要给出可直接运行的项目目录结构、数据库表结构、API 接口定义、前端页面文件、Dockerfile 和部署说明。为什么我要花这么多篇幅做约束因为 AI 默认会“炫技”。如果你不加约束它大概率会给你生成一个带有 JWT 认证、Redis 缓存、Docker Compose 编排的项目看起来特别专业但部署复杂度直接翻倍。我们的诉求很朴素办公室那台 Windows 服务器上能跑业务员浏览器能访问重启电脑数据不丢就足够了。把技术约束写清楚AI 就不会擅自引入没必要的复杂度。2.3 最容易翻车的点AI 会过度理解你的需求让 AI 干活的过程中我发现一个规律它有天然的“需求膨胀”倾向。我把功能清单发过去之后它第一版代码里自动添加了批量上传进度条、操作日志记录、报价单预览窗口甚至还有按客户分组统计销售数据的仪表盘。这些东西不是不好但对当前场景就是过度设计每加一个功能就多一片需要维护和测试的代码面。我的解决办法是在需求文档里单独写一节“明确不需要的功能”不做登录、不做多用户、不做审批流、不做数据统计大屏、不做邮件发送。这就像你跟人沟通时不仅要告诉对方“我要什么”还要告诉“我不要什么”。AI 没有常识边界它分不清什么功能是多余的你只有直接告诉它它才会收敛。把“不做清单”发过去之后生成的代码干净了很多项目文件少了差不多三分之一。3. 代码生成阶段我从“写代码的人”变成了“审代码的人”3.1 工具选型为什么我选 Cursor Claude 的组合工具选择上我大概对比过三类方案纯网页版对话式 AI、AI 编程插件、AI 原生的编辑器。纯网页版对话式 AI 最大的问题在于“上下文断裂”你让它生成一个文件它可以做得很好但项目一旦多文件协作跨文件修改就要反复复制粘贴效率很低。传统补全型插件则更像是“高级自动补全”适合你本来就会写代码、只是希望提速的场景不适合“真没怎么写代码”的场景。我最后用的是 Cursor 搭配 Claude 的组合。原因很简单AI 原生编辑器可以直接读写项目文件我只要在对话框里说“把前端页面里的 API 地址改成相对路径”它就能自己检索文件、定位代码、完成修改整个过程不需要我手动打开文件。更重要的是它能在命令行里直接跑测试和启动命令报错信息可以直接回传形成一个闭环。Claude 的优势在于上下文理解能力比较强不需要我把前因后果讲得非常细它也能抓住逻辑。从一个“不太想写代码”的交付者角度来说这个组合是我目前能拿到的最顺手的工具。我习惯的做法是先让 Claude 在对话里给出整体设计方案等我确认了再让 Cursor 按照方案去实现。相当于一个是架构师一个是干活的。不要小看这一步直接让编辑器里的 AI 写代码它确实能写但如果方向错了后面返工成本很高。先花两轮对话锁方案比写完再推倒重来划算得多。3.2 实际生成过程先数据模型再接口再页面我这次刻意把生成过程拆成了三个阶段。第一阶段先让 AI 设计数据库模型。我在对话框里用自然语言描述了字段需求“产品表要有产品编号、名称、规格、单位、单价产品编号唯一报价单表要有报价编号、客户名称、业务员、报价日期、有效期、总金额、折扣率报价单明细表要关联产品记录每个产品的数量、折扣、行金额。”AI 生成了 SQLAlchemy 模型并自动加上了外键关系。第一阶段代码生成示意这是 AI 输出的第一版class Quotation(Base): __tablename__ quotation id Column(Integer, primary_keyTrue) quotation_no Column(String(30), uniqueTrue, indexTrue, nullableFalse) customer_name Column(String(100), nullableFalse) salesperson Column(String(50)) quotation_date Column(Date, nullableFalse) expire_date Column(Date, nullableFalse) discount_rate Column(Numeric(10, 4), defaultDecimal(1.0000)) total_amount Column(Numeric(12, 2), nullableFalse) items relationship(QuotationItem, back_populatesquotation)第二阶段让它生成 API 接口包括上传 Excel、解析并创建报价单、查询报价单列表、下载 PDF 文件。第三阶段才让它实现前端页面一个上传按钮、一个报价单列表、一个下载按钮用 Vue 3 搭起来。这个顺序很重要先有数据结构再有数据流转最后才有界面AI 在不同阶段之间不会因为逻辑矛盾而陷入混乱。如果一上来就让它“做一个完整项目”它大概率会自己设计一套结构不一定符合你的业务认知导致后续每改一处都要牵一发动全身。3.3 审查 AI 代码的三个重点金额计算、SQL 注入、文件安全不写代码不等于不审代码。我在 review AI 代码时重点关注三个地方。第一是金额计算。AI 第一版生成的总金额计算逻辑用的是 Float 类型代码注释里还写着“价格可能会出小数问题”我立刻要求全部替换成 Decimal并且让金额计算统一走一个函数不允许在各个页面里各自实现。第二是 SQL 注入。这个工具虽然内网使用但朋友公司里的业务员偶尔会填出一些奇怪字符AI 第一版的查询语句有一条是直接拼接字符串的我一路追查下去发现它是在模糊搜索功能里用 f-string 拼的这种习惯必须纠正。第三是文件安全。生成 PDF 后下载接口的路径规则要严格限制不能让用户通过修改文件名去下载其他目录下的文件。这其实就是把 AI 当成一个“会写代码但经验不足的实习生”来带你要看它有没有踩常见坑有没有用不合理的方式处理边界情况。我不会逐行看但核心逻辑必须上心。3.4 说点实话我也不是完全没写代码但都是两三行的“环境补丁”整趟下来我唯一亲手动过的代码集中在两处。第一处是 PDF 中文乱码问题AI 生成的 reportlab 配置里注册了系统中文字体但客户服务器是一台精简版 Windows Server路径下面的字体文件名和开发机不一样我手动把字体路径改成实际存在的那个字体文件。第二处是前端页面打包后请求后端接口的地址客户要求接口地址写成服务器内网 IPAI 在开发环境里用的是 localhost部署时我改了配置文件里的 API 地址。这两处都有一个共同点它们是“环境特定信息”不写进对话里 AI 永远不可能知道。所以说“没写几行代码”不代表不碰代码而是你碰的代码已经从业务逻辑变成了环境适配。4. 联调排错我用“自然语言调试”搞定 Bug4.1 报错信息不能只丢链接要补齐三件套AI 写代码最快的部分不是第一次生成而是后面反复联调时的高频修复。但这里有个很关键的使用习惯你不能只把报错截图贴给 AI 就指望它秒回答案。我总结出了一个报错三件套报错信息原文、触发的操作步骤、你期望的结果。举个例子测试阶段我让 AI 修复“上传文件后页面白屏”的问题完整描述是“我在浏览器点击上传按钮选择一个 30 行的 Excel点击确认后页面白屏浏览器控制台没有任何报错但后台日志显示 500 错误期望是上传成功并跳转到报价单列表”。AI 看到这条描述后直接定位到了异常Excel 里有一列字段名和代码里读取的不一致。如果我只丢一个 500 报错给它它能猜到的可能性就会小很多。这背后的原理是AI 的代码生成能力建立在对上下文的理解上你给的上下文颗粒度越细它定位就越快。很多人在网上吐槽“AI 写代码越改越乱”大概率是因为只给了零散信息让 AI 靠猜来修改自然容易把其他地方改坏。4.2 一个很实用的技巧先让 AI 输出排查计划再让它动手当 Bug 比较隐蔽的时候我会要求 AI “先列出所有可能导致问题的原因给出排查顺序等我确认后再修改”。这一步看起来多余但其实能省下大量来回试错的轮次。有一次报价单生成后 PDF 文件永远打不开AI 第一反应是“可能 reportlab 版本有问题”试图升级依赖库。我让它先做原因分析它列出了四个可能文件没有写入完成就关闭、PDF 结构被损坏、文件名被非法字符干扰、生成过程中内存不足。最终检查发现是 AI 在写 PDF 文件时用了 with open 但缩进写错了导致文件在内容写入完成前就被关闭和它最初猜的版本问题差了十万八千里。这种“先计划后动手”的模式本质上是把 AI 当成一个可以参考的实习生而不是一个预言家。你要求它给出推理过程它的回答准确率会明显上升。直接用“请修复”其实是在逼迫 AI 在不确定的情况下赌一个答案赌错的概率不低。4.3 项目文件变多之后按“问题-文件-函数”的粒度提问项目跑起来之后文件有十几个上下文窗口撑不住的时候怎么提问就变得很重要。我的做法是让 AI “先不要看整个项目只定位问题相关的文件”。比如前端“下载按钮点了没反应”我会先问它“前端页面里下载按钮的事件绑定在哪个文件哪个函数”等它给出文件路径和函数名之后我再把那个函数贴出来告诉它“这里的点击事件触发后没有任何网络请求发出帮我检查是不是事件绑定失败”。把问题压缩到某一个文件、某一个函数的粒度AI 的回复就会非常精准。这里有个容易踩的坑不要为了让 AI“了解全貌”就把整个项目的代码一次性塞进上下文AI 处理大量无关代码时注意力会分散反而容易顾此失彼。按需取用是最有效率的方式。如果需要全局视角我通常会让它先输出项目目录树再让它选择性地打开文件而不是一锅端。5. 测试与部署AI 补位测试工程师5.1 让 AI 生成测试用例表和自动化测试脚本没有测试资源的小项目AI 完全可以充当测试工程师。我让 AI 基于需求文档自动生成了一张测试用例表专门覆盖正常路径、异常路径和边界情况。比如正常上传一份符合格式的 Excel验证能不能生成报价单上传一个完全空的 Excel验证会不会弹出清晰错误提示折扣率填 0 或者填负数验证金额计算方式产品数量填小数验证行金额是否合理报价有效期跨月的日期计算是否正确等等。AI 一口气列了 20 多个场景比我自己凭经验想还要全。其中金额相关的用例我专门做了交叉验证。我手工用 Excel 算了几组数据然后用 AI 生成的自动化测试脚本跑一遍对比结果。下面是我抽查过的其中一组产品单价数量折扣率税率预期行金额系统输出12.5040.8513%42.5042.5099.9021.0013%199.80199.803.14100.9013%28.2628.26金额全部对上之后我心里才有底。这个抽查动作非常关键因为 AI 生成的测试脚本只能证明“代码执行没有报错”不能证明“金额计算规则符合业务人员脑子里的算法”。业务逻辑的正确性必须由人来确认。5.2 部署到内网让 AI 写部署脚本但环境细节得靠人部署阶段我要求 AI 生成一个 Dockerfile 和一份部署文档同时把“服务器内网无外网、硬件配置只有 1G 内存”两个约束写进了提示词。AI 第一版给的 Dockerfile 使用了较大的基础镜像引入了一些用不到的系统组件我让它改成更精简的镜像并且把 reportlab 需要的中文字体打包进镜像。这个过程中也确实遇到典型的部署问题客户服务器上不能访问外网没法在线拉取依赖包。AI 很好的作用是帮我生成了一份离线安装计划把 Python 依赖包在开发机上下载好再拷贝到客户服务器上安装。真正让部署跑通的依然是大量的环境确认和人工检查。AI 告诉你“端口 8080 应该开放”但如果客户的 Windows 防火墙把它拦了AI 是不知情的它也无法替你点确认弹窗。这也是我反复提到的一点AI 能帮你生成让你十分省力的东西但部署到真实环境里的“最后一公里”一定需要人来走。5.3 上线前验收清单从“能跑”变成“能交付”我整理了一份上线验收清单然后让 AI 照这个清单生成测试记录模板方便最终让客户签字确认。清单内容包括准备一份真实格式的 Excel在页面上传确认生成 PDF 后金额与预期一致连续生成三份报价单确认报价编号不会重复重启服务器后确认历史报价单和数据还在系统不需要重新录入用业务员真实的客户数据跑一遍确认文件名里的客户名不会因为特殊字符导致保存失败。这些看起来琐碎的检查项恰恰是“能跑”和“能交付”的区别。当天实测时还真发现了一个问题业务员输入的客户名称里带了一个斜杠字符AI 在生成 PDF 文件名时没有做非法字符过滤导致文件保存失败。这个问题如果不靠真实数据测试开发阶段根本发现不了。我把这个 bug 反馈给 AI它很快在文件名生成的逻辑里增加了非法字符替换函数前后不超过两分钟。6. 交付环节文档、培训和背后的“隐形工作”6.1 使用说明、部署手册、故障排查表三大件缺一不可很多独立开发者在交付小工具时最爱省略文档但这次项目我反而花了比较多时间做资料整理因为客户是典型的不懂技术的小公司。我让 AI 先生成三份文档的初稿给业务员看的使用说明因为只有两个页面的操作路径所以控制在三页以内配上按钮截图给服务器维护人员看的部署手册内容包括如何启动服务、如何备份 SQLite 数据库文件、如何查看日志还有一份故障排查表比如“页面打不开先检查服务有没有启动”“上传报错先检查 Excel 是不是另存为过 xlsx 格式”。AI 生成初稿后我逐条对照实际操作过了一遍修正了几处截图不对应的地方然后才发出去。文档不用长但必须真实照着做能解决问题否则不如不发。6.2 客户培训前我用 AI 准备了“最可能被问的 15 个问题”交付当天培训只用了不到半小时但准备工作里有一个很巧的抓手我先把自己代入到不懂技术的业务员视角用自然语言描述“我明天要给客户演示这个工具请你列出客户最可能问的 20 个问题以及对应的回答”。AI 给出的问题里有几个确实超过了我原来的预期比如“服务器宕机了以前的报价单还能找回来吗”“Excel 里如果有几百行数据会不会卡死”“这个工具的格式会不会随着浏览器不同而变化”“如果以后想增加两个审批人会不会很复杂”。这些问题如果现场被问到我可能只会拍脑袋给个模糊回答但提前准备好了之后演示过程显得很专业朋友在客户那边也好交代。给客户答疑的本质是要让他们对这套系统有信心。AI 负责把问题库准备出来但最终回答的准确性和承诺边界必须由掌握项目真实情况的人来把关。6.3 说实话AI 交付不等于甩手交付维护边界必须提前说我必须在合同里把后续维护边界写清楚AI 辅助开发的项目代码的可维护性是有限的。如果后续要添加数据库字段、调整业务流程我可以继续用同样的方式迭代但如果涉及数据迁移、支付、安全审计等重逻辑场景就不能指望靠几个 prompt 解决。未来三个月之内我提供小修支持包括数据备份恢复、Excel 字段错位修复、PDF 乱码问题但这些都不意味着这个系统可以永远零成本运行。给 AI 交付项目做事后维护我的体会是AI 让“把东西做出来”的门槛大幅降低但“保证东西长期没问题”的责任依然完全在人身上。交付前把这句话跟客户讲清楚后面双方都会舒服很多。7. 复盘端到端 AI 交付的收益、风险与适用边界7.1 时间账这次项目到底省了多少时间整个项目从接到需求到验收交付大概花了两个工作日。我大概记了一下各环节的时间和分工阶段主要工作耗时需求梳理与客户确认规则、AI 辅助生成需求文档约 3 小时代码生成与联调让 AI 生成代码、修复 bug、跑通功能约 6 小时测试与部署AI 生成测试用例、部署到内网服务器约 4 小时文档与验收文档制作、客户培训、反馈修改约 3 小时如果按传统开发模式来做这个项目我大概率要排 3 天其中还包含晚上熬夜修 PDF 样式。现在整个编码部分被压到了半天以内压缩下来的时间都花在了真正重要的沟通和验收上。这个结果对我的触动是在边界清晰的小项目上AI 已经不只是“辅助工具”了它是真正意义上的生产主力。7.2 风险与技术债AI 代码不是免检产品收益很大但坑也很真实。第一个坑是“版本幻觉”AI 在生成代码时常常会引用一些并不存在的第三方库版本号我遇到过两次安装依赖时报错最后都是靠让 AI 去查 PyPI 上真实存在的版本号再修正才解决。第二个坑是安全审查AI 写代码时不太会主动考虑安全细节比如文件下载接口的路径穿越、上传接口的文件大小限制、Excel 里公式注入风险这些都得靠人像老中医一样把脉。第三个坑是数据隐私我在整个开发过程中从没有把客户真实的数据喂给 AI用的都是自己造的数涉及真实公司名、价格、税号的场景一律脱敏处理。这一点我自己写项目时非常注意建议所有人都养成这个习惯。7.3 什么样的项目适合 AI 端到端交付什么样的不适合复盘完这个项目我对 AI 端到端交付的适用边界有了更清晰的判断。适合的项目通常具备这些特征需求边界清晰、技术栈有成熟开源方案、代码量在可阅读范围内、项目涉及的敏感风险可控、交付验收可以由一两个人完成。像内部的报表工具、后台管理界面、文件转换服务、简单的电商原型都属于这类。不适合的项目也有很明显的信号强实时低延迟系统、支付和交易核心链路、硬件设备交互、需要严格合规审计的场景这些地方 AI 可能生成看起来很完整的代码一旦出问题排查和定责的代价会非常高。如果把过去的开发流程比作“自己一砖一瓦盖房子”那 AI 端到端交付更像是“你带着一队手脚麻利的机器工人盖房子”。工人干活很快但你依然要会看图纸、要懂结构安全、要清楚水电走向否则房子盖得再快塌了还是你的责任。这次项目之后我对“写代码”这件事本身的心态变了真正值钱的早就不再是每行代码敲得多快而是对问题的定义、对方案的判断、对结果的验收。以后再有类似的小工具需求我会毫不犹豫地继续走这条链路但每走一次我都会提醒自己AI 可以代替我写字但不能代替我思考。