企业官网建设流程全解析

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 的价值越小。如果你的项目全是 CRUD，AI 能帮你省下大量时间；如果你的项目涉及独特的业务逻辑或创新算法，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 帮你省下的是重复劳动的时间，不是思考的时间。思考这件事，永远得你自己来。