企业官网建设流程全解析

新公司2个月，我用AI写了90%的代码，但我劝你别学我。

先说明：这不是炫耀贴，更不是劝退贴。我入职第3天就开始用AI写代码，2个月过去，业务代码里超过90%都经过了AI生成、改写或者辅助重构。团队没炸，代码没烂，项目按期上了线。但我还是要说：别学我，尤其别学我这个“用法”。

为什么劝你别学？因为“用AI写代码”最大的坑，不是AI写得不好，而是你把AI当成一个“能出活的黑盒”。我见过太多人让AI生成一堆看起来没问题、实际跑起来处处是地雷的代码，然后甩给验收的人，出了问题直接一句“AI写的”就完了。这事我在前一家公司就亲眼看过一个项目组怎么把一个简单的登录模块写得比业务逻辑还复杂——不是因为AI不聪明，而是使用AI的人根本不知道自己在干什么。

这篇内容我打算彻底拆开讲清楚：我是怎么在2个月内用AI扛下90%的代码量、中间踩了哪些坑、哪些地方AI真的能救命、哪些地方绝对不能交给AI。我还会给出我实际用的工作流，以及一套“人工审查+AI生成”的配合方法——因为我这2个月真正在做的事，不是“用AI替代写代码”，而是“重构自己写代码的方式”。如果你也想让AI成为项目加速器而不是拆弹器，下面的内容值得你认真看完。

1. 这90%是怎么构成的？先算一笔真实账目

先说清楚“90%”这个数字是指什么。我统计的维度很粗暴：提交到代码仓库里的最终代码行数，凡是通过AI对话生成、由AI提示然后我手写确认逻辑、或者由AI做大规模重构的，都算AI参与。比如空行、注释、配置文件都不算在内。这样算下来，2个月工资周期里我负责的模块，AI参与度大约在90%左右。剩下10%是手写的老接口适配和几个极其特殊的加密逻辑。

但我得先坦白：这个数字有水分。因为代码量本身不等于代码价值。一个项目里最值钱的往往不是代码本身，而是边界条件的识别、异常流的处理、数据一致性的保障。这些恰恰是AI最不擅长、也最容易装懂的部分。AI能帮你写出优雅的代码块，却很难帮你从全局判断“这个字段在第三方的回调里有可能为空，要单独处理”。

所以我的“90%”是分模块统计出来的，不是总工程量的90%。核心模块至少有一半逻辑是我手写大纲、让AI填充实现，然后我再逐行审。而那些CRUD、样板代码、配置转换、简单的单元测试，才是真正意义的“AI全权负责”。这种分工逻辑后面会详细说，这里先给个结论性判断：

在熟悉的业务领域里，AI可以将纯写码效率提升2到3倍，但想靠它完全替代开发、跨过设计决策，那是在给自己挖坑。

我入职这家新公司时，项目已经进行了6个月，历史代码有大约20万行，技术栈是Java 17 + Spring Boot 3 + PostgreSQL，前端是Vue 3。这意味着我面对的并不是一页空白画布，而是要在既有代码风格和历史技术债务里夹缝求生。AI在这种环境里的发挥空间，比从零开始写新项目要窄很多，但你只要把“AI能做什么边界”划清楚，它依然能成为主力生产工具。

2. 为什么我敢把代码交给AI？方法论先于工具

我在上一家待了4年的公司，工具链相对保守，直到离开前半年我才开始认真把AI引入日常工作。前3个月，我把让AI写代码当成一个游戏，什么代码都丢进去让它跑一遍，然后看它翻车，看它一本正经地给出错误方案。事实证明这才是最佳学习路径——AI不是用来“信任”的，是用来“驯化”的。

但驯化的前提是你得先搞清楚它会在哪些地方犯蠢，然后划定能交给它的场景。这套方法论是我用几个月的时间总结出来的，我给它起了个名字叫“三层边界”：

第一层是“样板层”。这一层包括标准CRUD接口、实体类、DTO转换、简单的分页查询、配置文件、测试数据构造等。这类代码有明确的套路，每个项目的写法可能不同，但内部结构高度相似。AI在这层的表现极其稳定，甚至可以用“完美”来形容——因为它是从海量训练数据里学出来的通用模式，本身就是同类代码的“平均解”。

第二层是“逻辑层”。这一层包括状态机流转、权限校验、批量处理、复杂的SQL聚合、缓存策略等。AI可以生成初稿，但你必须让它理解业务背景，而且必须强调约束条件。它常常会在某一块写出完全合理的代码，可一到跨模块交互就开始短路。比如我让它写一个“库存扣减并记录流水”的接口，它写出来的逻辑在单测里看起来完美，可如果并发请求同时打到这个接口上，库存直接变成负数。这不是写代码的问题，是“并发控制意识”的问题——AI模型没有真正经历过线上事故，它就很难主动加上分布式锁。

第三层是“决策层”。这一层包括接口设计、数据结构设计、数据库表拆分、事务边界划分、技术选型、重构策略等。这一层我从来不交给AI，最多让它提供参考方案、对比优缺点、列个checklist。AI在决策层表现最好的状态不是“替你做决定”，而是“提供一个让你不遗漏任何选项的视角”。比如在选择“订单状态字段用什么枚举还是常量类”这种问题上，它能帮你列出两者在可维护性、可读性、空间占用上的差异，但它不会知道你团队里的同事更习惯哪种风格。

我在这家新公司的头两周，做的一件事就是先把公司现有代码里高频出现的模式提取出来，喂给AI当Few-shot示例。比如我们项目的分页返回结构、统一异常格式、审计日志注解、权限注解写法，我都会在生成指令里贴上一两个真实示例，让AI照着现有风格写。这个动作把我的代码review成本直接砍掉了三分之一——因为AI生成的代码从一开始就贴合团队规范，而不是需要我再花时间改写成统一格式。

3. 实操工作流：从需求到提交的6个关卡

用AI写代码最容易犯的错误，是把AI当成“翻译机”——你给它一句“写一个订单导出功能”，它输出一个满足表面需求的实现，然后你直接提交。这种做法在Demo阶段可能没问题，但在生产环境就是灾难。

我自己搭的一套流程有6个关卡，严格按顺序执行，每个关口都不能跳过。你可以把它理解成“用AI之前先给自己加一段编译期检查”：

第一关：需求拆解与提示词设计。

这一步是最耗心力的。需求和功能描述大部分都很口语化、很零散，比如“用户反馈说导出Excel太慢了，需要优化”。这种需求如果你原封不动丢给AI，它可能输出一个分页查询的优化方案，但它不知道导出的关键瓶颈在“大数据量下的内存溢出”还是“数据库查询慢”。我通常会把需求拆成两个部分：业务规则（做什么）和约束条件（怎么做/不能做什么），然后分别转换为AI能理解的上下文。

举个例子，一个导出需求我会这样写：

背景：订单表数据量在百万级，用户导出Excel时需要按筛选条件导出，目前导出的最大瓶颈是内存占用过高。 任务：请实现一个订单导出接口，返回一个zip压缩包，包含多个Excel文件。 约束：不能使用内存拼接Excel文件（Project X方案不可行）；需要按批次从数据库读取数据；格式需要和现有导出模板保持一致；超出10万行需要拆分为多个sheet。 请在代码中标注关键实现点的注释，并补充对应单元测试。

这样喂进去，AI的产出质量就完全不一样。它在生成时会自动绕开你用plain内存拼接的方案，也会主动考虑拆分逻辑。相比之下，直接写“用EasyExcel导出订单”出来的代码，大部分情况需要重写。

第二关：上下文锚定。

这里我要特别强调一点：现在的AI工具已经能做到上下文窗口非常大，大到可以塞进整个项目的核心代码，但这不代表你应该用“把整个项目贴上”的暴力方式对话。上下文越长，AI反而越容易在无关信息里迷失方向，生成的代码会“平均化”，而不是“贴合你的业务”。

我的做法是“按需拉取上下文”。需要写Controller，就把现有的Controller拎出来；需要写Service，就把现有的Entity、Repository、以及相关的Service代码贴上去。一次对话只聚焦一个模块，拒绝“一锅炖”。比如我做“库存同步”功能的时候，我只贴库存表结构、现有库存Service、对外的HTTP接口定义，其他一概不管。这会让AI在生成时始终围绕你给出的实际数据结构来展开，而不是凭空创建一个“OrderEntity”出来。

第三关：逐模块验收与编译检查。

AI生成代码后，我不会直接粘进IDE里，而是先复制到一个临时目录里，用编译器和静态检查工具过一遍——这一步在命令行就能完成，不用手动点击。检查通过后再进入代码审查阶段。这里推荐一个我自己的习惯：把AI生成代码中所有“TODO”、不完整的异常处理、以及对自己也不确定的地方，全部标记出来，强制让AI解释“为什么这里用了这个方式”，如果它解释不清，大概率就是“平均解”。

很多人忽略的一步是单元测试。我要求AI生成的每个业务模块，至少配套一个Happy Path的核心流程测试。别指望AI能覆盖异常流，但至少验证正常路径不炸。如果你让它生成一个带状态流转的接口，它通常会漏掉“重复提交幂等性”这种测试——这种边界情况必须由人来补。

第四关：代码审查与模式校验。

代码审查阶段，我只检查五件事：异常处理是否完整、事务边界是否合理、并发是否安全、是否存在内存泄漏风险、是否与现有团队规范一致。其他一般性问题，能用工具自动扫描的就不用人肉看。

这里我想讲一个特别值得注意的坑：AI非常喜欢生成“自己风格的代码”，而不是“你项目风格的代码”。比如同一个功能的写法，你项目里习惯用Optional收尾、Objects.equals判断，AI一旦没有示例可参考，就极有可能写成if (obj == null) return。判别代码是否属于“项目风格”，其实用正则或静态扫描工具就能做到，但“为什么这样写”这种背后逻辑，需要人来过。

第五关：集成联调与数据验证。

这是我最看重的一关。AI生成的代码单独编译通过不等于它能和整个系统协作。特别是数据库迁移、缓存失效、消息队列交互这些场景，AI的几何级想象力在运行时完全失效。我测试时永远带着真实生产的匿名数据跑一遍，而不是只靠mock数据。

举个具体的例子：我写一个“用户积分变动通知”功能，AI生成的代码在单元测试时完美通过，可一旦接入真实消息队列，才发现它把“积分变动”和“通知发送”放在同一个事务里，结果发消息失败会直接导致积分回滚。这就是典型的“局部最优，全局停滞”——AI无法看到消息队列失败应该独立补偿这种业务语义。

第六关：提交前再想想“反例”。

提交代码之前，我给自己设置一个强制问句：“这个功能在什么情况下会出错？”。然后让AI反向生成几个“故障场景”。你会发现，AI在这方面的潜力惊人，它能把对应的边界情况列得很全。我只会挑出其中有价值的场景，手动补测试和防御代码。

这一步花的时间不多，但极大地减少了生产事故。我在新公司提交的第一周代码，因为有这一道关口，review阶段几乎没有被打回重写——不是代码有多完美，而是已知的坑大部分在提交前就被找出来了。

4. AI的四种翻车模式与我的排查实录

我知道上面那套流程看下来，你可能会觉得“太麻烦了，用AI不就是为了省事吗？”——但我必须说，省的是打字时间和搜索时间，而不是思考时间。AI真正让你少做的事是“从零写起”的重复劳动，而不是“判断这段代码是否正确”的心智负担。

为了让你少踩坑，我把这2个月里真实遇到过的AI翻车情况，按类型整理成表，你也可以当作一份“AI生成代码排雷清单”来用：

关于过度自信型翻车，我想多说几句。有个经典案例是我让AI写一个“批量插入10万条订单数据到PostgreSQL”的方法，它给出的方案是使用JDBC Batch，参数是合理的；但它又额外加了一句“使用INSERT ... ON CONFLICT DO UPDATE实现幂等”，这句对于遇到的业务来说并不合适——因为那两张表的业务不允许重复更新。我一开始被它带偏了，直到压测时才反应过来。这个教训让我养成了一个习惯：AI在方案上给了两个以上的选项时，我默认只当作参考资料，最终决策永远自己拍板。

上下文漂移型也比较典型。我一开始试图在一个长对话里让AI把整个微服务的代码都写完，到了第5个模块，它竟然把之前定义好的返回结构体给忘了，新模块直接用了另一个名字。这种“跨模块记忆失效”是AI模型的固有限制，不是调prompt就能解决的。最稳妥的方案是把“每个模块之间的接口契约”单独拎出来写明，然后每次对话开始前都重新粘贴一遍契约，让AI老老实实基于最新契约干活。

风格漂移型在团队协作的语境里特别危险。一个项目有多人在维护，代码风格如果不统一，后面维护的人会崩溃。我测试过让AI生成两种风格的循环写法——一种是传统的for循环，一种是Java 8的stream，它在一半情况下会选stream，而项目里大部分业务循环都是传统for。AI并没有能力提前了解到项目的风格偏好，这个只能靠“人工给示例”去约束。

5. 与新同事的协作模式：AI不止是你一个人的工具

新公司有个特别好的氛围：团队里几乎每个人都在用AI，但用法和深度各不相同。有人只拿它补注释、写日报；有人拿它写单元测试；也有人像我一样直接把它推上一线生产。

这种差异让我明白一个道理：AI在团队里能不能发挥价值，不是看工具的先进程度，而是看有没有一套被大多数人认同的协作方式。所以我在第二周做了一件小事：在团队内部文档里写了一个简短的“AI辅助开发公约”。内容很简单，就4条：

1. AI生成代码必须经过人工审查才能在代码库中出现，工时归人、责任也归人。
2. AI产出的代码必须有相应的单元测试覆盖，不能只测主流程。
3. 涉及数据库迁移、第三方对接、复杂事务链路的代码必须人工手写或逐行确认。
4. 任何人禁止把自己不理解的代码提交进代码库。

这4条规定靠团队的力量落实下来了，也让我的“AI重度用法”没有成为团队的乌云，反而变成一种可以参考、可借鉴的模式。其他同事也开始尝试用自己的方式让AI参与，比如有人专门负责归纳“AI使用技巧”的文档，有人整理“AI生成代码常见错误清单”。这个文档越写越厚，我从里面受益不少。

6. 劝你别学我的真正原因

文章开头我说“劝你别学我”，这里必须解释清楚。你可以学我的方法论，但不要直接学我的“2个月90%代码”这件事本身。直接学的风险在于：

第一，我的90%是有前提的。我来这家公司前，已经在同类型系统上积累了3年经验。代码里的领域模型、业务流程、常见坑位，我心里都有数。这让我敢用AI填剩余的部分。如果你是个刚入行的新人，没有主干逻辑在脑子里，AI给你生成的代码就是你全部的理解——一旦它出错，你连排查的入口都找不到。

第二，AI生成代码的速度会给你极大的“进度感”，但进度感和真正的质量感是完全两回事。我在新公司头一个月，每天提交的PR数量比老员工多出很多，但review的人可不是吃素的。有好几次是我觉得AI写的已经很好了，被老手一句话打回，说“这种并发场景你怎么敢这么写？”

第三，我没有告诉你的是：那2个月里我的加班时长不降反升。AI帮我写了90%的代码，但为了确认那剩下的10%边界条件、补那90%的坑，我花的时间比纯手写还多。你说“效率提升”了吗？提升了，提升的是“我把时间花在更难、更值得花的地方”。原来一天的工作有两小时在敲样板代码，现在那两个小时被我用在思考数据一致性和接口设计上。

所以我的体感是：AI不能让一个平庸的开发者变得优秀，但它能激励一个尚可的开发者把时间花在刀刃上。

7. 最后再分享一个小技巧：让AI给自己做代码体检

我在这个项目学到的最有价值的一个习惯，不是让AI写代码，而是让AI“审”自己的代码——用两个独立的对话会话，一个生成，一个审查，审查时不共享生成时的上下文，让AI从纯粹的表层逻辑去客观看待这段代码。相当于是“AI写、我审、AI再审”——三个视角交叉，能找出大量两两配合也查不出的问题。

做法非常简单：

1. 把AI生成的代码复制出来，粘贴到一个新会话。
2. 让它扮演一个资深代码审查专家，分别从性能、安全、代码风格、异常处理、复杂度5个维度给出意见。
3. 对每个意见都要求它给出“规范化修改建议”和“理由”，只接受有理有据的，不接受“看起来更好”的。
4. 人工对修改意见做优先级排序，按照“高风险改动”“中风险改动”“纯风格改动”分别决定是否采纳。

这个技巧最惊人之处在于，AI审查自己的代码时，经常会先指出它在生成时已经忽略的边界情况——就好像它回答“我知道这里有问题，但我没告诉你”。整个过程只需要5分钟，但几乎每次都能抓到一两个有价值的改进点。如果你也在用AI写代码，强烈建议你把这一步养成肌肉记忆。

用AI写代码这件事，放到今天已经不值得大张旗鼓讨论了。工具就在那里，每个人都能用。真正拉开差距的，依然是编写代码背后的人：怎么问需求、怎么拆问题、怎么把握好审查粒度、怎么让AI产出与你团队文化兼容的结果。这4个能力，才是AI时代程序员真正的核心竞争力。

我在新公司的第二个月，已经能明显感觉到：AI写代码的速度，终有一天会稳定在某个水位线上；而人的判断力和工程经验，才是决定代码能不能落地的天花板。你要做的不是追上AI的速度，而是让自己成为那个拿着棋盘的人。