企业官网建设流程全解析

上一个迭代，我接手了一段AI生成的状态机代码。格式干净，注释完整，单元测试覆盖率接近90%，看起来是那种能放心让它上生产环境的代码。结果上线一个月后，一个只在凌晨出现的竞态条件把整条链路打断。排查到第三天，根因才浮出水面：AI为了“合理简化”，把两个语义完全不同的状态合并成了一个。

这件事之后，我认真把“AI代码”和“技术债”放在一起想了很久。AI写代码的边际成本趋近于零，但代码被读懂、被修改、被排查故障的成本，一分钱都没有降。这个剪刀差，就是技术债开始膨胀的地方。这篇文章不是要争论AI能不能写代码，而是想说说AI代码到底会以哪些方式变成债务、为什么人很难审出问题、以及从个人到团队该怎么给这批代码上锁。如果你正在用AI辅助开发，或者你带的团队已经开始靠AI提效，下面这些内容应该对你有用。

1. AI代码的隐性负债集中在哪五类问题

1.1 看起来很优雅的“过度抽象”

AI最爱干的一件事，就是过度抽象。你让它实现一个简单的导入导出功能，它可能会给你整出策略模式加工厂模式加模板方法的三件套。代码本身没什么错，读着也顺，但在一个只有两三个人维护的中等模块里，这套复杂度纯属额外税。

我反复想过AI为什么爱这么干。它评估输出的标准不是“这个团队值不值得引入这种模式”，而是“这个写法在训练数据里够不够标准、够不够常见”。于是它会选择看起来最体面的方案，而不是性价比最高的方案。这种债最坑的地方在于：它不是一眼能看出来的烂代码，恰恰相反，它漂亮得让你不忍心重构。等到需求改起来的时候，一个本来半小时能改完的小变更，可能要动五个文件、穿透六层调用。

识别方法其实很简单：改一个小需求，需要动几个文件？调用链超过几层？拉一个不熟悉这个模块的人来，让他用十五分钟讲清楚这段代码在做什么——讲不清楚，这个抽象就是负债，不是资产。

1.2 自信满满的幻觉API

如果说过度抽象是“优雅的债”，那幻觉API就是“致命的债”。AI会非常自然、非常自信地调用一个并不存在的方法，或者使用一个当前版本早就改掉了的旧API。编译时直接报错还好，顶多浪费几分钟；最怕的是那种当前能编译、行为却完全不符合预期的调用。

有一次我让AI帮忙处理某个第三方SDK的签名逻辑，它生成了一个构造器调用，参数个数、类型、顺序全都对，文档里也能搜到这个名字——但文档版本是两年前的，当前版本里这个构造器的语义已经变了。代码编译过了，单测也过了，上了测试环境才炸。这种问题为什么难防？因为幻觉代码的风格太正常了。人看到一段格式工整、命名规范、调用链合理的代码，会下意识跳过“这个API到底存不存在”这条检查。我现在养成一个习惯：凡是AI生成的代码里去调用不常用的库、不常写的框架接口，一律先去本地依赖和文档里搜一圈，确认它真的长这样。

1.3 边界条件和异常路径被“平均化”

第三类债，说到底是训练数据造成的。AI学到的代码大都是“平均情况”——输入合法、网络正常、依赖可用。教程和示例代码很少写满异常路径：超时怎么办、返回null怎么办、被并发调用怎么办、重复执行怎么办。所以AI生成的代码在理想路径上跑得飞起，一到真实世界的脏环境就露馅。

举个例子。我之前看到过一段AI生成的重试逻辑，从代码本身看完全正确：退避时间、最大重试次数、状态码判断，全都写得很规矩。但问题出在一个并发场景，多个请求同时在失败后重试，每个请求都在自己的线程里等退避，等退避结束后同时打向下游，直接把下游服务打到超时。AI不是故意漏掉这个场景，而是它从训练数据里学到的重试逻辑，默认都建立在“单实例、单线程”的假设里。真实系统中的并发、抖动、上游限流，这些东西从来不会写进AI的答案，得靠人来补。

所以我现在审AI代码，最先看的就是异常分支。happy path对不对反而没那么重要，因为测试环境一跑就能发现；真正值钱的是那些不好复现、一出现就是事故的异常路径。

1.4 上下文缝合怪与全局架构的漂移

第四类是风格和架构层面的债。AI非常依赖上下文，你给它什么，它就照着什么缝。如果你在提示词里贴了一段老代码，它会默认那段代码的写法是“正确的姿势”，哪怕那段代码本身已经被团队判定为坏味道。如果你什么都不给，它就按训练数据里出现频率最高的写法来——而这种写法，跟你团队的工程规范经常是两回事。

结果就是，同一个代码库里出现各种互不兼容的风格：有的地方命令式，有的地方函数式；有的错误处理用throw，有的返回null，有的直接吞掉不报。风格不统一本身就是技术债，因为每一次阅读都要重新建立心智模型。

还有一种更隐蔽的漂移，叫局部最优。AI在每个文件、每个函数的维度上都能写得合情合理，但跨文件、跨模块的架构一致性它照顾不到——上下文窗口就那么大，它看不到全局。当AI大规模介入一个项目之后，如果没有人去维护全局设计，代码库会慢慢从“一个系统”变成“一堆局部合理的代码的集合”。这种债，静态扫描工具扫不出来，但它会在每一次跨模块联调、每一次新人接手时，一点一点收利息。

2. 为什么代码审查拦不住AI代码的坑

2.1 人对“自动化产出的代码”会天然放低防御

上面前四类问题，其实很多都能在代码评审阶段拦住。但现实是，它们偏偏经常溜过去。我在复盘那起凌晨事故时，最先承认的一点就是：如果那段问题代码是一个同事写的，我在评审时大概率会多问几句为什么；但当我看到它是AI生成的，第一反应反而是“AI能写出这种完整度，应该问题不大”。

这个现象在心理学上有个名字叫自动化偏误，人会倾向于相信自动化系统给出的结果，因为默认它经过了大量的验证。代码生成工具给人的感觉就是“背后经过充分训练、看过无数项目”，于是人脑自动进入省电模式，批判性被调低了一档。这不是简单的态度问题，它是认知机制。知道这件事存在，我才开始有意识地在评审AI代码时切换成“挑刺模式”，并且要求自己必须找到至少一个问题再放行。

反过来我也见过另一极端：一看到AI代码就全盘否定，什么都要重写。这种心态会让人把AI省下来的时间全部浪费在对抗上。正确姿势不是信任或者不信任，而是“默认怀疑、逐条确认”。

2.2 生成速度和审查带宽之间的剪刀差

更残酷的现实是：AI写代码的速度提升，并没有同步发生在代码审查环节。以前一个人一天写两百行，评审就评审两百行；现在AI一小时能生成两千行，评审带宽还是那么大。结果就是评审从“逐行读”退化成“扫一眼”。那些藏在异常分支里、藏在API调用里、藏在优雅抽象里的问题，扫一眼根本扫不出来。

这个剪刀差是结构性的，靠“让大家多上点心”解决不了。能对冲它的只有两条路：要么降低AI输出的单次规模，让它每次生成的代码量和人的审查带宽匹配；要么把审查清单做得非常机械，让评审人可以对照检查而不是靠感觉。这两条路我在后面会展开讲。

2.3 提示词锚定和“大多数都对”的幸存者偏差

人在评审AI代码时还有一个隐形的盲区：你给AI的提示词本身就在决定债务的下限。如果提示词里贴了一个有历史问题的旧实现当参考，AI会照着那份旧的逻辑把债又复印一遍；如果提示词只有一句“帮我实现XX功能”，AI就会拿它训练数据里最高频的模板来套，而那个模板是为“一般项目”准备的，不是为你的架构准备的。

更麻烦的是幸存者偏差。AI生成十段代码，九段都能正常工作，于是你默认第十段也没问题。但技术债恰恰最喜欢藏在那个“第十段”里面——而且这个“第十段”往往还是一个公共函数、一个底层工具，因为公共代码被复用的频率高，一旦出错，影响面会被乘数放大。等到一个季度后，几个隐藏的问题一起爆出来，你甚至想不起来它们都是来自AI。

2.4 代码正确但业务错误，是最难拦的一关

最后想补充一个容易被忽略的点：AI代码的审查通常停留在“代码正确性”层面，也就是编译能不能过、测试能不能跑、逻辑看起来合不合理。但工程里更大的债，通常出在“业务正确性”上——这段代码是否符合远期业务规则、是不是把两个语义不同的状态合并了、这个“合理简化”在未来的需求演进里还成立吗。

这一点AI天然做不到。它从上下文和训练数据里推测业务语义，但它不知道你的业务决策会怎么变。所以AI代码在单点上越正确，长期来看越需要人来兜底。这也是为什么我坚持：AI生成的每一段核心逻辑，都必须能回答“它为什么要这样设计”，而不是“它这样设计对不对”。

3. 个人实操：从写提示词到点合并，给AI代码上锁

3.1 动手之前，先在提示词里写完“验收标准”

我自己用AI写业务代码有个习惯：让它动手之前，先自己把约束写清楚。所谓验收标准，就是把边界立出来，不让AI自由发挥。

请帮我实现[某个功能]。约束如下： - 输入域：入参类型和取值范围；什么情况下会收到 null/空集合 - 成功标准：做什么、不做什么，哪些行为属于“范围外” - 失败行为：超时/网络错误/重复调用/上游返回异常时，分别应该怎么做 - 硬约束：不得新增依赖、不得修改现有接口、代码风格与模块保持一致 - 如果以上某个约束无法满足，请直接说明，不要用看起来正确的代码绕过去

这段提示词里最关键的是最后一句：“如果约束无法满足，请直接说明，不要用看起来正确的代码绕过去”。AI的倾向是迎合——哪怕做不到，它也会生成一段貌似满足需求的代码，把缺口藏在“看起来不错”的实现里。明说了这句，等于逼它在缺口处坦白。我实测下来，加了这句之后，AI给出“做不到、需要放宽某个约束”这类反馈的频率明显变高了，而这恰恰是它最有价值的输出。

3.2 先要方案，再要代码；关键API要求它说明依据

还有一个很实用的技巧：第一轮对话不要让它直接给代码，而是先让它说清楚改动方案——涉及哪些文件、每处改动的意图、会不会改变现有接口行为、风险点在哪里。它说清楚了，说明上下文吃透了；它含糊其辞，那么它给你的代码大概率也是糊的。拿到方案后，我才决定是否让它往下写，而不是让它在第一轮就把代码甩到对话框里。

另一个习惯关于API：常用框架、常用库里的常规调用，AI生成的可靠性很高，我可以相对放心。但对于那些不常用的API、SDK边角方法、只有某个特定版本才有的参数，我会要求它说明依据。它能说出“这个接口在哪个模块里、参数语义是什么”，我才敢信；它只能说“这是标准做法”，我就当它在编。AI最大的特点就是自信，而自信恰恰是最不可靠的信号。

3.3 让AI写测试和边界用例，比让它写核心实现更划算

用了一阵子AI之后，我得出的结论可能和很多人不一样：AI最擅长的事情不是“写生产代码”，而是“根据一个已经明确定义的行为，把测试用例和边界用例铺满”。

所以我现在会把任务拆开：核心逻辑的行为边界由人来定义，AI负责把对应的测试用例批量生成——输入合法时的正常路径、输入非法时的异常路径、被并发调用时的场景、对超时的模拟。人的精力花在定义行为上，AI的算力花在铺用例上。这个责任分离，可以避免“AI写了算法但没人真正理解”的尴尬。

这里我踩过一个坑：有一次我先让AI写了实现，再让它给自己写测试。结果它的测试和实现共享同一个错误假设，看起来全绿，实际上都是在重复同一个错的镜像。后来我改成：人先写行为基线测试，再让AI补用例和实现。测试必须和实现有独立的来源，否则那套绿油油的测试只是给债盖了一层遮羞布。

3.4 合并之前的三个问题，答不上来就暂缓

最后是个人端的放行门槛。每段AI生成的代码，在点合并之前，我要求自己先回答三个问题。

第一，这段代码我真的读懂了，还是仅仅编译通过、测试绿色？很多AI代码的问题是：你没法读懂，但所有自动检查都过了。如果答案是后者，那这段代码还没到合并的时候。

第二，如果半年后一个不熟悉这个模块的人来改它，他需要多久？如果答案是“要绕很久还不一定改对”，那这个复杂度就是债。

第三，这段逻辑出错时最坏的影响是什么？影响面是单次请求，还是整条链路？一旦出错，谁会先发现、靠什么机制发现？如果最坏的影响没有任何兜底措施，那就不该合。

这三个问题不是学术讨论，是我在凌晨三点排查竞态问题时最想提前问自己的。答不上来不可怕，可怕的是连问都不问就点了合并。

4. 团队治理：给AI划边境线，而不是一刀切禁用

4.1 把AI的使用场景分成放开区、管控区、禁区

团队层面最忌讳的一刀切管理，要么“全员禁用AI”，要么“随便用AI”。禁用只会让大家把AI藏起来私下用，问题从明处转到暗处，反而更难追踪；完全放开，债务规模就会失控。我建议把AI的使用场景分成三类来管理。

• 放开区：模板CRUD、配置生成、测试桩、数据脱敏样板、各类胶水代码。这些代码行为标准、风险可控，即使AI写错了，测试和上层逻辑也容易兜住，可以放手让AI跑。
• 管控区：核心业务逻辑、并发控制、状态机、资金支付、安全鉴权。AI可以出方案、可以生成片段，但必须由人来完成设计评审，并且生成结果必须配齐边界测试才允许合入。
• 禁区：强审计、强合规、跨系统通信协议、任何不可逆操作。这个区域不用AI生成，至少在当前阶段不用，谁要用谁自己手写，并且写清楚理由。

场景围栏的意义不是限制效率，而是划清责任边界。在放开区用了AI，出了问题团队兜得住；在管控区用了AI，就必须为每一段代码配评审；至于禁区，那就不是“要不要用AI”的问题，而是“出了事谁负责”的问题。

4.2 把“AI代码审查清单”固化到Code Review流程里

光在理念上分类还不够，真正落地的抓手是一张可以勾选的审查清单。我从那次事故之后，在团队里推了一套清单，每次涉及AI代码的评审都必须逐项过一遍。

• API是否存在、版本是否正确：重点查那些不常写的库、不常用的框架接口，这是AI幻觉的高发区。
• 边界条件是否覆盖：超时、空值、并发、重复调用、上游脏数据，至少要有两条测试锁住异常路径。
• 异常处理是否一致：是抛出、返回错误码还是吞掉，必须和模块现有的约定对齐，不能每个函数一种风格。
• 是否引入了新依赖或新模式：这个依赖/模式的价值是什么，是不是AI为了显得“标准”而硬加的。
• 抽象层次是否匹配模块复杂度：这段代码用了三个设计模式，真的比平铺直叙的三层if更划算吗。
• 行为是否有独立测试兜底：所谓独立，指的是不从实现代码反推出来的测试，而是从接口行为定义出来的。

这张清单不是给评审人增加负担的，恰恰是为了降低负担——照着条款勾选，总比凭感觉去“读代码”快。尤其是AI生成代码的量级已经远超人肉可以通读的范围时，机械化的清单反而更可靠。

4.3 事后复盘：别只归因于“AI不行”，要把结论写回规范

技术团队总会遇到必须复盘线上事故的时候。如果根因追溯到AI代码，我最反对的复盘结论是“以后少用AI”。这句话等于什么都没总结出来，而且根本解决不了下一个AI模块继续出类似问题。

我建议复盘时多问三件事：第一，提示词当时给了多少约束？如果约束本身就残缺，那错的不只是AI，还有把任务交给AI的人。第二，审查清单为什么没拦住它——是压根没人按清单审，还是清单里缺了这一项？第三，这个问题出在放开区、管控区还是禁区？是不是场景划分本身就划错了？

把这三件事的结论依次更新到提示词模板、审查清单和场景围栏里去，才算真正把一次事故变成了治理规则。不然同一个坑换个马甲还会再来一遍，只是这次戴了顶更新的AI帽子。

4.4 用指标让AI负债可视化

管理AI代码不能靠感觉，得靠几个简单指标。我建议团队先跑两个迭代，观察数据而不是急着定KPI。几个我常用的指标如下。

这四个指标不用追求绝对准确，趋势比绝对值重要。如果某个放开区场景的AI缺陷密度突然升高，说明它可能被错划进了放开区；如果返工率居高不下，说明提示词和审查之间的约束没对齐。指标不是为了追责，是为了让负债显形——看不见的东西，永远没法治理。

5. 还债实战：清洗一个AI遗留模块的完整过程

5.1 不要上来就重写，先用黑盒测试锁住行为基线

前阵子我处理过一个典型的AI遗留模块。它表面上看什么都有：完整注释、漂亮的结构、全部通过的测试。但团队成员没人敢动它，因为没人真正理解它。这是AI债最典型的症状：代码在跑，但心智不在。

我做的第一件事，不是打开内部实现，而是把它当一个黑盒，把现有接口的全部行为记录下来。什么样的输入会返回什么样的结果，什么样的输入会抛异常，并发调用了会怎样，上游超时了会怎样。这个阶段不追求优化，只追求把现状钉死。

为什么必须先锁行为？因为AI遗留代码往往有一套“看起来合理、但说不清为什么”的逻辑，你直接重写，大概率会“以为懂了”，然后重写出来的代码和真实行为南辕北辙。先记录行为，等于给后续所有动作铺了一张对照表——改完之后跑一遍，行为没变才算成功。

5.2 对照审查清单扫描债务，按风险分级还款

行为基线建立之后，我开始用前面说的那套审查清单逐项扫描。扫完一圈，高风险、中风险、低风险分得非常清楚。

高风险项：上游超时时，那段AI生成的重试逻辑没有设置整体的超时上限，本身在多实例并发下还会放大流量，直接威胁下游服务——这段我直接人工重写，不让AI参与。

中风险项：金额为空时会抛出破坏数据一致性的异常，但缺少防御性校验，我给这段代码补了参数校验和对应的边界测试，逻辑本身保留。

低风险项：命名风格和模块其他部分不统一，不影响运行，但增加心智负担，这类先记录为“已知债”，排到下一个迭代顺手清理。

还款顺序是最关键的部分。高风险必须先还，因为它对应的是线上事故概率；中风险可以跟正常迭代走，因为它影响的是长期稳定性；低风险不用急着还，记录在案比强行重构更划算——强行把低风险重构了，可能又会引入新的高风险。

5.3 把还债过程发现的问题，反向炼成团队的经验模板

清洗完这个模块，我顺手做了一件小事：把这次发现的高频问题整理进团队的AI代码审查清单和提示词模板。比如“重试逻辑必须考虑并发放大”“AI生成的API调用必须验证版本”“行为基线测试先于重构”这些条目，都是这次还债用时间换来的。下次再有类似模块进来，很多坑在第一轮就会被人按清单拦掉。

我个人现在的体会是：AI代码不是不能碰，而是必须作为“负债”被管理。每一段AI代码合入主分支时，都要能回答三个问题：它解决了什么、它改变了什么、如果它错了最坏的结果是什么。回答不了这三个问题，就别把它称作资产，先按负债计息，然后尽早安排还款。

凌晨两点那次排查让我学到最重要的一件事，就是AI写代码的速度可以很快，但理解代码的速度始终是人的速度。技术债从来不是代码生成的，而是“没人理解它”生成的。只要人的理解跟得上，AI代码完全可以变成资产；跟不上的地方，债就会越滚越多。这与工具无关，与使用工具的我们有关。