1. 从写代码到描述需求这次交付到底发生了什么去年年底接了一个内部工具类的小项目需求不复杂但琐碎一个能读取本地表格、做数据清洗、生成可视化报表、最后打包成可执行文件的小系统。按以往的习惯我会先搭框架、写接口、调库、处理边界情况前后怎么也得一周。但这次我换了个思路——把绝大部分实现工作交给 AI 来完成自己只负责拆解需求、验证结果、修正方向。最终交付时间压缩到了两天半而且我亲手敲的代码加起来不到两百行大部分还是配置文件。这个经历让我意识到一件事AI 端到端交付项目这件事已经不是能不能的问题而是怎么用才对的问题。很多人以为把需求丢给 AI 就能坐等成品实际用下来会发现真正决定成败的不是模型有多强而是你有没有把工程判断力用在正确的地方。这篇内容就是把我这次交付的完整过程拆开讲清楚——哪些环节可以放心交给 AI哪些环节必须自己把关以及中间踩过的那些坑。适合读这篇的人有三类一是想尝试用 AI 提效但不知道从哪下手的开发者二是被重复性编码工作困住、想腾出精力做架构设计的技术负责人三是对 AI 辅助开发持怀疑态度、想看看真实边界在哪的同行。我不会吹嘘零代码搞定一切也不会唱衰说AI 写的都不能用只讲我实际跑通的流程和判断依据。2. 需求拆解阶段为什么这一步 AI 替代不了你2.1 把模糊需求翻译成可执行任务清单拿到需求的第一件事不是打开 AI 对话框而是自己先想清楚要做什么。原始需求只有一句话做个工具把表格数据整理好并出图。这种描述直接丢给 AI得到的必然是泛泛而谈的模板代码因为 AI 不知道你的数据长什么样、报表要什么格式、运行环境是什么。我的做法是先把需求拆成任务清单拆的时候遵循一个原则每个任务都要能用一句话描述清楚输入和输出。比如读取表格这个任务我会写成读取指定路径下的 xlsx 文件返回一个包含所有 sheet 名称的列表。这样拆完之后每个任务都变成了 AI 能准确理解的最小单元。拆解过程中有几个判断标准值得分享。第一如果一个任务你自己都说不清楚输入输出说明还没想明白这时候丢给 AI 只会得到更模糊的结果。第二任务粒度控制在一个函数能完成的级别太粗了 AI 会自由发挥太细了你会陷入无穷无尽的对话。第三把有依赖关系的任务标出来比如数据清洗必须在读取表格之后这样后续让 AI 生成代码时能保证调用顺序正确。2.2 识别哪些任务适合交给 AI不是所有任务都适合 AI 来做。我这次的经验是有明确输入输出、逻辑相对独立、不需要复杂上下文判断的任务最适合。比如数据格式转换、正则表达式编写、图表配置生成、异常处理模板这些 AI 做得又快又好。而涉及业务规则判断、性能调优、安全边界处理的部分必须自己来。举个具体例子。数据清洗里有个需求是把日期列统一成 YYYY-MM-DD 格式这种任务我直接交给 AI它生成的代码考虑了多种输入格式和异常情况比我手写的还周全。但另一个需求是根据业务规则判断哪些订单需要标记为异常这个规则涉及多个字段的组合判断和阈值设定AI 不知道你的业务背景生成的逻辑大概率是错的这种就必须自己写规则、自己验证。提示判断一个任务能不能交给 AI最简单的测试方法是问自己——如果换一个不了解业务的人来做他能做对吗能就交给 AI不能就自己来。2.3 建立验收标准比写代码更重要这一步是我觉得整个流程里最关键的。在让 AI 生成任何代码之前我先为每个任务定义了验收标准。比如读取表格的验收标准是能正确读取三种不同格式的测试文件返回的 sheet 列表和实际一致文件不存在时给出明确报错。生成报表的验收标准是输出的图表包含标题、坐标轴标签、数据标签颜色符合预设主题导出图片分辨率不低于 150dpi。有了验收标准后面 AI 生成的每一版代码我都能快速判断能不能用而不是凭感觉说好像不太对。这个习惯是从以前做代码审查时养成的——没有明确的通过条件评审就会变成扯皮。用 AI 写代码同样如此验收标准就是你跟 AI 之间的合同。3. 工具链选择为什么我没用最火的那套方案3.1 对话式生成与项目级生成的区别市面上 AI 辅助开发的工具大致分两类一类是对话式生成你在对话框里描述需求它给你代码片段另一类是项目级生成你给它一个项目描述它直接生成完整的项目结构。我这次两种都试了最后选择了对话式为主、项目级为辅的混合模式。原因很简单。项目级生成工具确实能一键产出完整目录结构看起来很爽但实际用下来问题不少。它生成的代码风格统一但缺乏针对性很多地方用了过度设计的模式比如一个简单的数据读取非要套三层抽象。而且一旦某个模块需要调整你得重新生成整个项目之前的修改就白费了。对话式生成虽然需要你一步步引导但每一步都可控改起来也方便。我的具体做法是先用项目级工具生成一个基础骨架包括目录结构、依赖配置、入口文件然后把这个骨架作为上下文用对话式工具逐个模块填充实现。这样既省去了搭架子的事又保证了每个模块的质量可控。3.2 本地运行环境与依赖管理的坑这次项目有个硬性要求最终要打包成可执行文件在没有 Python 环境的机器上运行。这个要求直接影响了我的技术选型。如果用了一些依赖复杂的库打包出来的文件会非常大启动也慢。所以我在让 AI 推荐库的时候特意加了一个约束条件优先选择纯 Python 实现、依赖少的库。AI 一开始推荐了几个功能强大但依赖一堆 C 扩展的库我直接否掉了。后来换成了两个轻量级方案打包体积从 200 多 MB 降到了 40 MB 左右。这个判断 AI 做不了因为它不知道你的部署环境限制只有你自己清楚。依赖管理还有个细节AI 生成的代码经常会引入一些顺手的库比如为了一个简单的日期处理引入整个日期库。我的做法是每次 AI 生成代码后检查一遍 import 列表把不必要的依赖删掉换成标准库实现。这个动作看起来琐碎但积累下来能显著减少打包体积和潜在冲突。3.3 版本锁定与可复现性保障AI 生成的代码有个特点它用的库版本往往是你环境里装的版本但不会主动告诉你。这就导致一个问题——你这边跑通了换台机器可能就报错。我这次的做法是在项目初期就生成一个requirements.txt把所有依赖的版本号写死并且每加一个新库就更新这个文件。具体操作上我让 AI 帮我写了一个小脚本功能是扫描项目里所有 import 语句对比当前环境的包版本自动生成锁定版本的依赖文件。这个脚本本身也是 AI 写的我改了改逻辑就用了。有了这个文件后面换机器部署时直接安装没有再出现过版本冲突的问题。注意AI 生成的代码里经常出现这个库最新版是 X.X.X这样的注释但实际安装的可能是旧版本。不要信注释以pip freeze的结果为准。4. 核心模块的 AI 生成与人工修正实录4.1 数据读取模块一次生成三次修正数据读取看起来简单实际是这次项目里修改次数最多的模块。第一次让 AI 生成代码时我只说了读取 xlsx 文件它给了一个用主流表格库读取单个 sheet 的实现。但我的实际需求是读取所有 sheet、自动识别表头行、处理合并单元格、跳过空行。这些细节我没说AI 自然也不会做。第二次我把需求补充完整AI 生成的代码基本能用了但有个隐藏问题它用了一个默认参数导致读取大文件时内存占用很高。这个问题在测试小文件时发现不了我是用了一个一万行的测试文件才暴露出来的。第三次修正时我明确要求使用分块读取模式每块一千行AI 很快给出了正确实现。这个过程让我总结出一个经验跟 AI 描述需求时要像写测试用例一样具体。不要只说读取表格要说读取表格处理合并单元格跳过全空行大文件分块读取每块一千行。你描述得越具体AI 一次生成可用的概率越高。4.2 数据清洗模块规则引擎的取舍数据清洗模块是我人工介入最多的部分。核心需求是根据一组规则对数据进行标准化处理比如日期格式统一、金额单位统一、文本去空格等。AI 一开始建议用一个规则引擎库来实现说这样扩展性好。我考虑了一下否掉了原因是这个项目只有十几条固定规则引入规则引擎属于杀鸡用牛刀而且会增加打包体积。最后我选择了一个更朴素的方案把每条规则写成一个独立函数用一个列表维护规则顺序依次执行。这个方案 AI 也能生成而且代码量少、易读、好调试。这个取舍的判断依据是规则数量少且不常变时硬编码比抽象更划算。如果规则有上百条且经常调整那规则引擎才值得引入。清洗过程中还有个坑AI 生成的去空格逻辑只处理了首尾空格但实际数据里有很多全角空格和不可见字符。这个问题是我在验收时用真实数据跑出来的AI 在生成时不会主动考虑这些边界情况。后来我补充了需求让它用正则统一处理所有空白字符问题才解决。4.3 报表生成模块配置驱动的设计思路报表生成是这次项目里 AI 表现最好的模块。我只描述了一句生成柱状图和折线图包含标题、坐标轴标签、数据标签导出为图片AI 就给出了一个相当完整的实现连颜色主题和字体设置都考虑到了。这个模块我几乎没有修改只做了一件事把图表配置抽出来做成一个独立的配置文件。这样以后要调整图表样式不用改代码改配置就行。这个思路其实也是 AI 建议的它在生成代码时主动把配置和逻辑分离了我一看觉得合理就保留了。从这件事我得到一个启发AI 在有成熟模式的任务上表现最好。图表生成有固定的套路AI 见过大量类似代码所以生成质量高。而数据清洗这种高度依赖具体业务规则的任务AI 就力不从心了。了解这个边界你就能合理分配哪些任务交给 AI、哪些自己来。4.4 打包发布模块那些文档里不会写的细节打包成可执行文件这一步AI 给的方案基本正确但有几个细节是文档里不会写、只有实际踩过才知道的。第一个是图标文件的问题AI 生成的打包命令引用了图标路径但没说要使用绝对路径导致打包时找不到文件。第二个是隐藏导入的问题项目里用到的某个库需要手动声明隐藏导入否则打包后的程序运行时会报模块缺失。第三个细节最隐蔽打包后的程序在开发机上运行正常换到另一台机器就闪退。排查了半天发现是缺少一个系统级的运行库。这个问题 AI 也帮不上忙因为它不知道目标机器的环境。最后我的解决方案是在打包时把必要的运行库一起打进去虽然体积大了几 MB但保证了兼容性。提示打包发布这一步建议在目标机器上做最终测试不要只在开发机上验证。开发机上的很多依赖是全局安装的打包时可能被遗漏。5. 调试与验证AI 写的代码怎么保证质量5.1 用测试用例反向验证 AI 输出AI 生成的代码有个特点看起来逻辑通顺但边界情况经常处理不到位。我的应对方法是每拿到一段 AI 生成的代码先不急着集成而是单独写几个测试用例跑一遍。测试用例的设计原则是正常输入、边界输入、异常输入各来一个。比如数据读取模块我设计了三个测试一个正常的两列小表格、一个包含合并单元格和空行的复杂表格、一个不存在的文件路径。第一个测试验证基本功能第二个测试验证边界处理第三个测试验证错误提示。三个都通过才认为这段代码可用。这个方法帮我提前发现了不少问题。有一次 AI 生成的日期解析代码正常日期没问题但遇到2024-13-45这种非法日期时直接抛异常而不是返回错误提示。这个问题如果不测上线后用户输入错误数据就会导致程序崩溃。5.2 日志埋点让 AI 的代码可观测AI 生成的代码通常缺少日志输出出了问题只能靠猜。我的做法是在关键节点手动加日志比如数据读取开始和结束、清洗规则执行前后、报表生成完成时。日志内容包含时间戳、模块名、关键参数和耗时。这些日志在调试时帮了大忙。有一次报表生成的结果不对我通过日志发现是清洗后的数据里有一列全是空值导致图表画不出来。如果没有日志我得一步步加打印语句排查有了日志直接定位到问题环节。日志的另一个作用是性能监控。我在日志里记录了每个模块的耗时发现数据清洗模块在处理大文件时特别慢后来针对性地做了优化。这个优化方向不是拍脑袋想的是日志数据告诉我的。5.3 人工审查的重点逻辑正确性优先于代码风格AI 生成的代码风格通常很规范变量命名清晰、缩进统一、注释完整。但这些表面功夫不是审查重点。我审查时关注三件事逻辑是否正确、边界是否处理、异常是否捕获。逻辑正确性方面我会挑几个典型场景手动推演一遍代码执行路径看结果是否符合预期。边界处理方面重点看空值、极值、特殊字符这些情况有没有考虑。异常捕获方面看有没有裸的 try-except 把错误吞掉或者异常处理里只打印不处理。代码风格我基本不管因为 AI 生成的风格已经够好了而且风格问题不影响功能。把审查精力放在逻辑和边界上效率更高。6. 这次交付暴露的 AI 能力边界6.1 AI 擅长什么模式化、有大量先例的任务回顾整个项目AI 表现最好的任务有几个共同特征有成熟的实现模式、网上有大量类似代码、逻辑相对独立。比如图表生成、文件读写、格式转换、正则匹配这些任务 AI 几乎一次就能给出可用代码。这背后的原因不难理解。AI 的训练数据里包含了海量的开源代码对于常见任务它见过足够多的实现能总结出最佳实践。所以当你描述一个常见需求时它给出的方案往往比新手手写的更周全。但这也意味着越是常见的任务AI 的价值越大越是独特的任务AI 的价值越小。如果你的项目全是 CRUDAI 能帮你省下大量时间如果你的项目涉及独特的业务逻辑或创新算法AI 能帮的就有限了。6.2 AI 不擅长什么需要业务上下文和全局判断的任务这次项目里 AI 翻车的几个地方都是因为它缺乏业务上下文。比如它不知道我们的数据里有一种特殊的编码格式不知道某个字段的空值代表未填写而不是零不知道报表的受众是谁所以不知道用什么图表类型合适。这些信息不在代码里也不在公开文档里只存在于项目相关人员的脑子里。AI 再强也拿不到这些信息除非你主动告诉它。但问题是很多时候你自己都意识不到这些隐含知识的存在直到 AI 做错了才发现哦原来这个规则我没说。所以我的结论是AI 能帮你写代码但不能帮你做需求分析。需求分析阶段该花的功夫一点都省不了甚至因为要跟 AI 沟通你得把需求想得更清楚。6.3 人机协作的最佳分工模式经过这次项目我总结出一个分工模式人负责定义问题和验收结果AI 负责实现过程。具体来说人做这几件事拆解需求、定义验收标准、选择技术方案、审查关键逻辑、处理异常情况。AI 做这几件事生成代码框架、填充具体实现、编写测试用例、生成文档注释、提供优化建议。这个分工的核心逻辑是人做判断AI 做执行。判断需要业务理解和全局视角这是人的优势执行需要速度和覆盖面这是 AI 的优势。两者结合效率最高。我试过完全放手让 AI 做结果是一堆看起来能用但实际跑不通的代码也试过完全自己写结果是一周的工作量。最后这个分工模式把时间压缩到了两天半而且质量有保障。7. 给想尝试 AI 交付的人几条实在建议如果你也想用 AI 端到端交付一个项目我有几条从这次经历里总结的建议。第一条是从小项目开始试。不要一上来就拿核心项目练手先找个边缘的、不那么重要的小工具试试水摸清 AI 的能力边界和你的协作节奏。我这次选的就是一个内部工具即使出问题影响也不大。第二条是把验收标准写在前面。不要等 AI 生成完了再想怎么验收那样你很容易被 AI 的输出带偏。先想清楚什么样算通过再让 AI 开始做。这个习惯能帮你省下大量返工时间。第三条是保留人工审查环节。AI 生成的代码不要直接上线哪怕它看起来再完美。至少做一遍逻辑审查和边界测试确认没问题再集成。这次项目里我发现的几个问题都是人工审查时找出来的AI 自己不会主动告诉你哪里可能有问题。第四条是记录踩坑过程。每次 AI 生成的结果不符合预期把原因记下来——是需求描述不清、还是 AI 能力不足、还是验收标准有遗漏。积累下来你会形成一套自己的AI 协作手册下次遇到类似情况就能快速判断该怎么处理。最后一条是不要追求零代码。这次项目我虽然只写了两百行代码但这两百行都是关键判断和修正价值远高于 AI 生成的那几千行。追求零代码是个误区追求把精力花在刀刃上才是正确目标。AI 帮你省下的是重复劳动的时间不是思考的时间。思考这件事永远得你自己来。
1. 从写代码到描述需求这次交付到底发生了什么去年年底接了一个内部工具类的小项目需求不复杂但琐碎一个能读取本地表格、做数据清洗、生成可视化报表、最后打包成可执行文件的小系统。按以往的习惯我会先搭框架、写接口、调库、处理边界情况前后怎么也得一周。但这次我换了个思路——把绝大部分实现工作交给 AI 来完成自己只负责拆解需求、验证结果、修正方向。最终交付时间压缩到了两天半而且我亲手敲的代码加起来不到两百行大部分还是配置文件。这个经历让我意识到一件事AI 端到端交付项目这件事已经不是能不能的问题而是怎么用才对的问题。很多人以为把需求丢给 AI 就能坐等成品实际用下来会发现真正决定成败的不是模型有多强而是你有没有把工程判断力用在正确的地方。这篇内容就是把我这次交付的完整过程拆开讲清楚——哪些环节可以放心交给 AI哪些环节必须自己把关以及中间踩过的那些坑。适合读这篇的人有三类一是想尝试用 AI 提效但不知道从哪下手的开发者二是被重复性编码工作困住、想腾出精力做架构设计的技术负责人三是对 AI 辅助开发持怀疑态度、想看看真实边界在哪的同行。我不会吹嘘零代码搞定一切也不会唱衰说AI 写的都不能用只讲我实际跑通的流程和判断依据。2. 需求拆解阶段为什么这一步 AI 替代不了你2.1 把模糊需求翻译成可执行任务清单拿到需求的第一件事不是打开 AI 对话框而是自己先想清楚要做什么。原始需求只有一句话做个工具把表格数据整理好并出图。这种描述直接丢给 AI得到的必然是泛泛而谈的模板代码因为 AI 不知道你的数据长什么样、报表要什么格式、运行环境是什么。我的做法是先把需求拆成任务清单拆的时候遵循一个原则每个任务都要能用一句话描述清楚输入和输出。比如读取表格这个任务我会写成读取指定路径下的 xlsx 文件返回一个包含所有 sheet 名称的列表。这样拆完之后每个任务都变成了 AI 能准确理解的最小单元。拆解过程中有几个判断标准值得分享。第一如果一个任务你自己都说不清楚输入输出说明还没想明白这时候丢给 AI 只会得到更模糊的结果。第二任务粒度控制在一个函数能完成的级别太粗了 AI 会自由发挥太细了你会陷入无穷无尽的对话。第三把有依赖关系的任务标出来比如数据清洗必须在读取表格之后这样后续让 AI 生成代码时能保证调用顺序正确。2.2 识别哪些任务适合交给 AI不是所有任务都适合 AI 来做。我这次的经验是有明确输入输出、逻辑相对独立、不需要复杂上下文判断的任务最适合。比如数据格式转换、正则表达式编写、图表配置生成、异常处理模板这些 AI 做得又快又好。而涉及业务规则判断、性能调优、安全边界处理的部分必须自己来。举个具体例子。数据清洗里有个需求是把日期列统一成 YYYY-MM-DD 格式这种任务我直接交给 AI它生成的代码考虑了多种输入格式和异常情况比我手写的还周全。但另一个需求是根据业务规则判断哪些订单需要标记为异常这个规则涉及多个字段的组合判断和阈值设定AI 不知道你的业务背景生成的逻辑大概率是错的这种就必须自己写规则、自己验证。提示判断一个任务能不能交给 AI最简单的测试方法是问自己——如果换一个不了解业务的人来做他能做对吗能就交给 AI不能就自己来。2.3 建立验收标准比写代码更重要这一步是我觉得整个流程里最关键的。在让 AI 生成任何代码之前我先为每个任务定义了验收标准。比如读取表格的验收标准是能正确读取三种不同格式的测试文件返回的 sheet 列表和实际一致文件不存在时给出明确报错。生成报表的验收标准是输出的图表包含标题、坐标轴标签、数据标签颜色符合预设主题导出图片分辨率不低于 150dpi。有了验收标准后面 AI 生成的每一版代码我都能快速判断能不能用而不是凭感觉说好像不太对。这个习惯是从以前做代码审查时养成的——没有明确的通过条件评审就会变成扯皮。用 AI 写代码同样如此验收标准就是你跟 AI 之间的合同。3. 工具链选择为什么我没用最火的那套方案3.1 对话式生成与项目级生成的区别市面上 AI 辅助开发的工具大致分两类一类是对话式生成你在对话框里描述需求它给你代码片段另一类是项目级生成你给它一个项目描述它直接生成完整的项目结构。我这次两种都试了最后选择了对话式为主、项目级为辅的混合模式。原因很简单。项目级生成工具确实能一键产出完整目录结构看起来很爽但实际用下来问题不少。它生成的代码风格统一但缺乏针对性很多地方用了过度设计的模式比如一个简单的数据读取非要套三层抽象。而且一旦某个模块需要调整你得重新生成整个项目之前的修改就白费了。对话式生成虽然需要你一步步引导但每一步都可控改起来也方便。我的具体做法是先用项目级工具生成一个基础骨架包括目录结构、依赖配置、入口文件然后把这个骨架作为上下文用对话式工具逐个模块填充实现。这样既省去了搭架子的事又保证了每个模块的质量可控。3.2 本地运行环境与依赖管理的坑这次项目有个硬性要求最终要打包成可执行文件在没有 Python 环境的机器上运行。这个要求直接影响了我的技术选型。如果用了一些依赖复杂的库打包出来的文件会非常大启动也慢。所以我在让 AI 推荐库的时候特意加了一个约束条件优先选择纯 Python 实现、依赖少的库。AI 一开始推荐了几个功能强大但依赖一堆 C 扩展的库我直接否掉了。后来换成了两个轻量级方案打包体积从 200 多 MB 降到了 40 MB 左右。这个判断 AI 做不了因为它不知道你的部署环境限制只有你自己清楚。依赖管理还有个细节AI 生成的代码经常会引入一些顺手的库比如为了一个简单的日期处理引入整个日期库。我的做法是每次 AI 生成代码后检查一遍 import 列表把不必要的依赖删掉换成标准库实现。这个动作看起来琐碎但积累下来能显著减少打包体积和潜在冲突。3.3 版本锁定与可复现性保障AI 生成的代码有个特点它用的库版本往往是你环境里装的版本但不会主动告诉你。这就导致一个问题——你这边跑通了换台机器可能就报错。我这次的做法是在项目初期就生成一个requirements.txt把所有依赖的版本号写死并且每加一个新库就更新这个文件。具体操作上我让 AI 帮我写了一个小脚本功能是扫描项目里所有 import 语句对比当前环境的包版本自动生成锁定版本的依赖文件。这个脚本本身也是 AI 写的我改了改逻辑就用了。有了这个文件后面换机器部署时直接安装没有再出现过版本冲突的问题。注意AI 生成的代码里经常出现这个库最新版是 X.X.X这样的注释但实际安装的可能是旧版本。不要信注释以pip freeze的结果为准。4. 核心模块的 AI 生成与人工修正实录4.1 数据读取模块一次生成三次修正数据读取看起来简单实际是这次项目里修改次数最多的模块。第一次让 AI 生成代码时我只说了读取 xlsx 文件它给了一个用主流表格库读取单个 sheet 的实现。但我的实际需求是读取所有 sheet、自动识别表头行、处理合并单元格、跳过空行。这些细节我没说AI 自然也不会做。第二次我把需求补充完整AI 生成的代码基本能用了但有个隐藏问题它用了一个默认参数导致读取大文件时内存占用很高。这个问题在测试小文件时发现不了我是用了一个一万行的测试文件才暴露出来的。第三次修正时我明确要求使用分块读取模式每块一千行AI 很快给出了正确实现。这个过程让我总结出一个经验跟 AI 描述需求时要像写测试用例一样具体。不要只说读取表格要说读取表格处理合并单元格跳过全空行大文件分块读取每块一千行。你描述得越具体AI 一次生成可用的概率越高。4.2 数据清洗模块规则引擎的取舍数据清洗模块是我人工介入最多的部分。核心需求是根据一组规则对数据进行标准化处理比如日期格式统一、金额单位统一、文本去空格等。AI 一开始建议用一个规则引擎库来实现说这样扩展性好。我考虑了一下否掉了原因是这个项目只有十几条固定规则引入规则引擎属于杀鸡用牛刀而且会增加打包体积。最后我选择了一个更朴素的方案把每条规则写成一个独立函数用一个列表维护规则顺序依次执行。这个方案 AI 也能生成而且代码量少、易读、好调试。这个取舍的判断依据是规则数量少且不常变时硬编码比抽象更划算。如果规则有上百条且经常调整那规则引擎才值得引入。清洗过程中还有个坑AI 生成的去空格逻辑只处理了首尾空格但实际数据里有很多全角空格和不可见字符。这个问题是我在验收时用真实数据跑出来的AI 在生成时不会主动考虑这些边界情况。后来我补充了需求让它用正则统一处理所有空白字符问题才解决。4.3 报表生成模块配置驱动的设计思路报表生成是这次项目里 AI 表现最好的模块。我只描述了一句生成柱状图和折线图包含标题、坐标轴标签、数据标签导出为图片AI 就给出了一个相当完整的实现连颜色主题和字体设置都考虑到了。这个模块我几乎没有修改只做了一件事把图表配置抽出来做成一个独立的配置文件。这样以后要调整图表样式不用改代码改配置就行。这个思路其实也是 AI 建议的它在生成代码时主动把配置和逻辑分离了我一看觉得合理就保留了。从这件事我得到一个启发AI 在有成熟模式的任务上表现最好。图表生成有固定的套路AI 见过大量类似代码所以生成质量高。而数据清洗这种高度依赖具体业务规则的任务AI 就力不从心了。了解这个边界你就能合理分配哪些任务交给 AI、哪些自己来。4.4 打包发布模块那些文档里不会写的细节打包成可执行文件这一步AI 给的方案基本正确但有几个细节是文档里不会写、只有实际踩过才知道的。第一个是图标文件的问题AI 生成的打包命令引用了图标路径但没说要使用绝对路径导致打包时找不到文件。第二个是隐藏导入的问题项目里用到的某个库需要手动声明隐藏导入否则打包后的程序运行时会报模块缺失。第三个细节最隐蔽打包后的程序在开发机上运行正常换到另一台机器就闪退。排查了半天发现是缺少一个系统级的运行库。这个问题 AI 也帮不上忙因为它不知道目标机器的环境。最后我的解决方案是在打包时把必要的运行库一起打进去虽然体积大了几 MB但保证了兼容性。提示打包发布这一步建议在目标机器上做最终测试不要只在开发机上验证。开发机上的很多依赖是全局安装的打包时可能被遗漏。5. 调试与验证AI 写的代码怎么保证质量5.1 用测试用例反向验证 AI 输出AI 生成的代码有个特点看起来逻辑通顺但边界情况经常处理不到位。我的应对方法是每拿到一段 AI 生成的代码先不急着集成而是单独写几个测试用例跑一遍。测试用例的设计原则是正常输入、边界输入、异常输入各来一个。比如数据读取模块我设计了三个测试一个正常的两列小表格、一个包含合并单元格和空行的复杂表格、一个不存在的文件路径。第一个测试验证基本功能第二个测试验证边界处理第三个测试验证错误提示。三个都通过才认为这段代码可用。这个方法帮我提前发现了不少问题。有一次 AI 生成的日期解析代码正常日期没问题但遇到2024-13-45这种非法日期时直接抛异常而不是返回错误提示。这个问题如果不测上线后用户输入错误数据就会导致程序崩溃。5.2 日志埋点让 AI 的代码可观测AI 生成的代码通常缺少日志输出出了问题只能靠猜。我的做法是在关键节点手动加日志比如数据读取开始和结束、清洗规则执行前后、报表生成完成时。日志内容包含时间戳、模块名、关键参数和耗时。这些日志在调试时帮了大忙。有一次报表生成的结果不对我通过日志发现是清洗后的数据里有一列全是空值导致图表画不出来。如果没有日志我得一步步加打印语句排查有了日志直接定位到问题环节。日志的另一个作用是性能监控。我在日志里记录了每个模块的耗时发现数据清洗模块在处理大文件时特别慢后来针对性地做了优化。这个优化方向不是拍脑袋想的是日志数据告诉我的。5.3 人工审查的重点逻辑正确性优先于代码风格AI 生成的代码风格通常很规范变量命名清晰、缩进统一、注释完整。但这些表面功夫不是审查重点。我审查时关注三件事逻辑是否正确、边界是否处理、异常是否捕获。逻辑正确性方面我会挑几个典型场景手动推演一遍代码执行路径看结果是否符合预期。边界处理方面重点看空值、极值、特殊字符这些情况有没有考虑。异常捕获方面看有没有裸的 try-except 把错误吞掉或者异常处理里只打印不处理。代码风格我基本不管因为 AI 生成的风格已经够好了而且风格问题不影响功能。把审查精力放在逻辑和边界上效率更高。6. 这次交付暴露的 AI 能力边界6.1 AI 擅长什么模式化、有大量先例的任务回顾整个项目AI 表现最好的任务有几个共同特征有成熟的实现模式、网上有大量类似代码、逻辑相对独立。比如图表生成、文件读写、格式转换、正则匹配这些任务 AI 几乎一次就能给出可用代码。这背后的原因不难理解。AI 的训练数据里包含了海量的开源代码对于常见任务它见过足够多的实现能总结出最佳实践。所以当你描述一个常见需求时它给出的方案往往比新手手写的更周全。但这也意味着越是常见的任务AI 的价值越大越是独特的任务AI 的价值越小。如果你的项目全是 CRUDAI 能帮你省下大量时间如果你的项目涉及独特的业务逻辑或创新算法AI 能帮的就有限了。6.2 AI 不擅长什么需要业务上下文和全局判断的任务这次项目里 AI 翻车的几个地方都是因为它缺乏业务上下文。比如它不知道我们的数据里有一种特殊的编码格式不知道某个字段的空值代表未填写而不是零不知道报表的受众是谁所以不知道用什么图表类型合适。这些信息不在代码里也不在公开文档里只存在于项目相关人员的脑子里。AI 再强也拿不到这些信息除非你主动告诉它。但问题是很多时候你自己都意识不到这些隐含知识的存在直到 AI 做错了才发现哦原来这个规则我没说。所以我的结论是AI 能帮你写代码但不能帮你做需求分析。需求分析阶段该花的功夫一点都省不了甚至因为要跟 AI 沟通你得把需求想得更清楚。6.3 人机协作的最佳分工模式经过这次项目我总结出一个分工模式人负责定义问题和验收结果AI 负责实现过程。具体来说人做这几件事拆解需求、定义验收标准、选择技术方案、审查关键逻辑、处理异常情况。AI 做这几件事生成代码框架、填充具体实现、编写测试用例、生成文档注释、提供优化建议。这个分工的核心逻辑是人做判断AI 做执行。判断需要业务理解和全局视角这是人的优势执行需要速度和覆盖面这是 AI 的优势。两者结合效率最高。我试过完全放手让 AI 做结果是一堆看起来能用但实际跑不通的代码也试过完全自己写结果是一周的工作量。最后这个分工模式把时间压缩到了两天半而且质量有保障。7. 给想尝试 AI 交付的人几条实在建议如果你也想用 AI 端到端交付一个项目我有几条从这次经历里总结的建议。第一条是从小项目开始试。不要一上来就拿核心项目练手先找个边缘的、不那么重要的小工具试试水摸清 AI 的能力边界和你的协作节奏。我这次选的就是一个内部工具即使出问题影响也不大。第二条是把验收标准写在前面。不要等 AI 生成完了再想怎么验收那样你很容易被 AI 的输出带偏。先想清楚什么样算通过再让 AI 开始做。这个习惯能帮你省下大量返工时间。第三条是保留人工审查环节。AI 生成的代码不要直接上线哪怕它看起来再完美。至少做一遍逻辑审查和边界测试确认没问题再集成。这次项目里我发现的几个问题都是人工审查时找出来的AI 自己不会主动告诉你哪里可能有问题。第四条是记录踩坑过程。每次 AI 生成的结果不符合预期把原因记下来——是需求描述不清、还是 AI 能力不足、还是验收标准有遗漏。积累下来你会形成一套自己的AI 协作手册下次遇到类似情况就能快速判断该怎么处理。最后一条是不要追求零代码。这次项目我虽然只写了两百行代码但这两百行都是关键判断和修正价值远高于 AI 生成的那几千行。追求零代码是个误区追求把精力花在刀刃上才是正确目标。AI 帮你省下的是重复劳动的时间不是思考的时间。思考这件事永远得你自己来。
