企业官网建设流程全解析

1. 为什么要在 AI 编辑器里加“质量闸门”

AI 代码编辑器这两年进化得非常快，从最早的“补全一行”到现在的“整段生成、整文件重构”，能力边界一直在扩。但真正在项目里用过的人都有一个共同感受：AI 写得越快，你审得越累。它能在三秒内给你吐出八十行代码，语法看着像模像样，命名也挑不出毛病，可一旦跑起来，要么变量没定义，要么边界条件漏了，要么单元测试直接红一片。你花在“擦屁股”上的时间，往往比手写还多。

我自己的体感是，AI 生成代码的“一次通过率”大概在六成上下，剩下的四成里，有一半是低级错误（拼写、漏分号、类型不匹配），另一半是逻辑错误（空指针、越界、异步顺序错乱）。如果每次都要人肉去跑、去看、去改，那 AI 带来的效率红利基本被抵消掉了。所以问题的关键不在于“AI 能不能写”，而在于“AI 写完的东西，能不能自己先过一遍筛子”。

这就是“四层质量闸门”要解决的事。它的核心思路很朴素：让 AI 写完代码之后，不要直接丢给人，而是先经过四道自动化的检查关卡，能自己修的自己修，修不了的才升级给人。四层闸门分别是语法检查、静态分析、单元测试、集成验证，一层比一层严格，一层比一层接近“真实运行环境”。跑通全部四层，才算“可交付”。

这套东西适合谁？如果你是一个人维护项目、又重度依赖 AI 编辑器写代码的独立开发者，它几乎是刚需；如果你是小团队里负责搭工程规范的人，它可以作为 CI 前置的本地防线；哪怕你只是偶尔用 AI 写点脚本，理解这四层的思路，也能让你少踩很多坑。下面我就把这套闸门从设计到落地，一层一层拆开讲。

2. 四层闸门的整体设计与选型逻辑

2.1 为什么是“四层”而不是“一层”

很多人第一反应是：跑个单元测试不就行了？测试过了不就说明代码没问题？这个想法在真实项目里会翻车。原因很简单，单元测试本身也是代码，它也可能写错，而且它只能覆盖你想到的场景。如果 AI 生成的业务代码有语法错误，测试根本跑不起来；如果代码有类型隐患但恰好没触发，测试也是绿的。所以单一闸门一定会有漏网之鱼。

四层闸门的设计逻辑是“由浅入深、由快到慢、由廉价到昂贵”：

这个顺序不能乱。你不可能在语法都没过的情况下去跑测试，那是浪费时间；也不应该先跑集成测试再回头查拼写，那是杀鸡用牛刀。闸门的价值在于“用最低的成本拦住最多的问题”，越靠前的闸门越便宜，所以要把简单检查放前面。

2.2 每一层的“自动修复”边界在哪

标题里说“AI 写完自己查、自己修”，这里有个关键问题：哪些错误可以让 AI 自己修，哪些必须交给人。我的经验是划一条线——确定性的、有唯一正确答案的错误，交给 AI 自动修；涉及业务语义和设计取舍的，必须人工介入。

语法错误、格式问题、明显的类型不匹配，这些都有客观标准，AI 修完可以立刻用同一层闸门复验，修不对就再修，设个重试上限（比如三次）就行。但如果是“这个函数该不该拆”“这个异常该不该吞掉”“这个接口设计合不合理”，AI 没有你的业务上下文，它改出来的东西可能语法全对、测试全绿，但逻辑是错的。这种就必须停下来问人。

所以四层闸门里，第一、二层可以做到高度自动修复，第三层半自动（AI 改完人扫一眼），第四层基本只报警不自动改。这个边界划清楚，才不会出现“AI 越修越乱”的情况。

2.3 工具选型的取舍

工具这块我不建议一上来就上重型方案。一个人维护的项目，最重要的是“轻、快、能跑起来”。语法检查用编辑器自带的 Linter 就够，静态分析用语言生态里的标准工具（比如 JS/TS 用 ESLint + tsc，Python 用 ruff + mypy，Java 用 checkstyle + spotbugs），单元测试用最主流的框架（Jest、pytest、JUnit），集成验证用一条启动脚本加几个冒烟接口。

这里有个坑要提前说：不要为了“全”而堆工具。我见过有人给一个小项目配了七八个检查工具，结果每次提交要跑三分钟，最后大家都不跑了，闸门形同虚设。工具数量要跟项目规模匹配，宁可少而精，也不要多而废。下面每一层我都会给出具体的配置思路和参数选择依据。

3. 第一层闸门：语法与格式检查的落地细节

3.1 语法检查到底在查什么

语法检查是最基础的一层，但很多人对它理解得太窄，以为就是“有没有写错关键字”。实际上它至少覆盖四类问题：词法错误（拼写、非法字符）、语法结构错误（括号不匹配、缺少分隔符）、格式规范问题（缩进、换行、引号风格）、编码规范问题（命名大小写、文件头注释）。

AI 生成代码时，词法和语法错误其实不多，因为它本质是在“预测下一个 token”，结构通常是通的。真正高频的是格式和命名问题——比如它一会儿用双引号一会儿用单引号，一会儿驼峰一会儿下划线，函数名和变量名风格不统一。这些单看无所谓，但积累起来会让代码库变得很难维护。

所以第一层闸门的配置重点，不是“能不能编译”，而是“风格是否统一”。我的做法是：把格式规则固化到配置文件里，让 AI 生成时就有约束，生成后再用工具自动格式化一遍。这样第一层基本能做到“零人工”。

3.2 配置示例与参数说明

以 JS/TS 项目为例，ESLint 加 Prettier 是标配。关键配置项我列一下，并说明为什么这么设：

{ "semi": true, "singleQuote": true, "printWidth": 100, "tabWidth": 2, "trailingComma": "es5", "arrowParens": "always" }

• semi: true：强制分号。虽然 JS 有自动分号插入，但 AI 生成时容易在 return 后换行导致语义变化，强制分号能规避这类坑。
• singleQuote: true：统一单引号，减少 diff 噪音。
• printWidth: 100：默认 80 太窄，AI 生成的代码经常超长，100 更贴合现代屏幕。
• trailingComma: es5：尾逗号让后续增删字段的 diff 更干净。
• arrowParens: always：箭头函数参数永远带括号，避免 AI 有时带有时不带。

这些参数不是拍脑袋定的，每一条都对应一个实际踩过的坑。比如printWidth设 80 的时候，AI 生成的链式调用会被强行折行，折得乱七八糟，后来调到 100 就清爽多了。

3.3 自动修复的触发时机

第一层闸门的自动修复，我建议放在两个时机：一是 AI 生成代码的瞬间（编辑器保存时触发 format on save），二是提交前的 pre-commit 钩子。前者让问题在源头就被抹平，后者作为兜底防止有人绕过。

这里有个实操心得：format on save 一定要开，但不要开“自动修复所有 lint 问题”。因为有些 lint 规则涉及语义（比如 no-unused-vars），自动删掉一个“看起来没用”的变量，可能那个变量是被动态引用的，删了就出 bug。所以第一层只做“纯格式”的自动修复，语义相关的留给第二层。

注意：pre-commit 钩子里跑格式化，一定要用lint-staged只处理暂存文件，否则每次提交都全量格式化，大项目会卡到你想砸键盘。

4. 第二层闸门：静态分析与类型检查

4.1 静态分析能拦住哪些“隐形炸弹”

第一层过了，代码能跑，但能跑不代表对。第二层要抓的是那些“运行时才炸、但静态就能看出来”的问题。典型的有：类型不匹配（把字符串传给要数字的函数）、空值隐患（可能为 null 的对象直接取属性）、未使用变量（AI 经常生成一堆没用的 import）、不可达代码（if 分支永远进不去）、异步误用（该 await 的没 await）。

这些问题如果漏到运行时，轻则报错，重则数据错乱。而静态分析的价值在于，它不需要真正执行代码，就能在几秒内扫出这些隐患。对 AI 生成的代码来说，这一层尤其重要，因为 AI 很容易“想当然”地假设某个变量一定有值。

4.2 TypeScript 的严格模式怎么开

如果是 TS 项目，tsconfig.json的严格程度直接决定第二层闸门的强度。我建议至少开这几项：

{ "strict": true, "noImplicitAny": true, "strictNullChecks": true, "noUnusedLocals": true, "noUnusedParameters": true, "noImplicitReturns": true, "noFallthroughCasesInSwitch": true }

• strictNullChecks是最关键的一项。开了之后，null和undefined不再能随便赋给其他类型，AI 生成的“可能为空”的代码会立刻报错，逼着你去处理边界。
• noUnusedLocals和noUnusedParameters能清掉 AI 生成的多余变量和参数，让代码更干净。
• noImplicitReturns防止函数在某些分支忘记 return，这是 AI 写条件逻辑时的高频错误。

刚开严格模式的时候，老代码会报一大堆错，这是正常的。我的做法是新文件全开严格，老文件逐步迁移，不要一次性全量开，否则你会被几百个错误淹没，最后干脆关掉。

4.3 静态分析的自动修复策略

第二层的自动修复比第一层要谨慎。类型错误可以尝试自动修，但必须复验。比如 AI 把string传给了要number的参数，自动修复可能是加个parseInt，也可能是改调用方，这两种改法语义完全不同。所以我的策略是：让 AI 给出修复建议，但修复后必须重新跑一遍类型检查，通过了才接受，不通过就回滚并标记人工。

未使用变量这类问题可以放心自动删，但删之前要确认它没有被字符串形式的动态引用（比如obj['someVar']）。这个确认动作，可以让 AI 去代码库里搜一遍变量名，搜不到才删。

实操心得：静态分析工具的输出往往很长，直接丢给 AI 修，它可能只看到第一条就动手了。正确做法是把错误按文件分组，一次只让 AI 处理一个文件的错误，修完复验再处理下一个。这样虽然慢一点，但准确率高得多。

5. 第三层闸门：单元测试的自动生成与执行

5.1 单元测试为什么是“质量闸门”的核心

前两层解决的是“代码写得对不对”，第三层解决的是“代码干得对不对”。单元测试是唯一能验证业务逻辑正确性的自动化手段。AI 生成的代码，语法再漂亮、类型再严谨，如果算出来的结果是错的，那一切都是白搭。

但这里有个现实问题：AI 生成业务代码的同时，往往不会主动生成对应的测试。就算生成了，测试本身也可能是错的——它可能只测了 happy path，没测边界；可能断言写反了；可能 mock 掉了真正要验证的逻辑。所以第三层闸门的关键，不是“有没有测试”，而是“测试有没有真正验证到点子上”。

我的做法是：让 AI 先根据业务代码生成测试，然后人工（或让另一个 AI 实例）审查测试的覆盖点和断言是否合理，最后才执行。执行通过不代表万事大吉，还要看覆盖率报告，确认关键分支都被覆盖了。

5.2 测试用例的生成模板

以 Jest 为例，我让 AI 生成测试时，会给它一个固定的模板结构，保证测试质量：

describe('函数名', () => { // 正常路径 it('should return expected result when input is valid', () => { // arrange // act // assert }); // 边界条件 it('should handle empty input', () => {}); it('should handle null/undefined', () => {}); it('should handle max/min values', () => {}); // 异常路径 it('should throw when input is invalid', () => {}); });

这个模板强制 AI 覆盖三类场景：正常、边界、异常。很多 AI 生成的测试只写第一类，加上后两类之后，拦截能力明显提升。特别是边界条件，AI 写的业务代码十有八九在边界上出问题，比如数组为空、数字为 0、字符串为空串。

5.3 测试执行与失败处理流程

测试跑起来之后，失败是常态。关键是失败之后怎么办。我的流程是：

1. 先看失败原因分类：是测试写错了，还是业务代码错了？
2. 如果是测试写错（断言不合理、mock 配置错），让 AI 修测试，修完重跑。
3. 如果是业务代码错，让 AI 根据失败信息修业务代码，修完重跑。
4. 如果反复修不好（超过三次），停下来人工介入，因为这说明问题可能出在设计层面，不是改几行能解决的。

这里有个坑：AI 修 bug 时容易“为了让测试变绿而改测试”。比如断言期望是 5，实际返回 4，它可能直接把断言改成 4，而不是去查为什么返回 4。这种行为必须禁止。我的做法是在提示词里明确写“不允许修改断言的期望值，除非能证明原断言本身写错了”。

5.4 覆盖率怎么看才有意义

覆盖率不是越高越好，关键看分支覆盖率，而不是行覆盖率。行覆盖率 90% 但分支覆盖率 50%，说明很多 if/else 只测了一半。我一般要求核心模块的分支覆盖率不低于 80%，工具函数不低于 90%。

但也要警惕“为了覆盖率而写测试”。有些 AI 会生成一堆只调用不 assert 的测试，覆盖率上去了，实际什么都没验证。所以看覆盖率的同时，要抽查测试内容，确认每个测试都有明确的断言。

6. 第四层闸门：集成验证与冒烟测试

6.1 为什么单元测试过了还要集成验证

单元测试是隔离的，它把依赖都 mock 掉了。但真实运行时，依赖是活的。单元测试全绿、一集成就崩，这是非常常见的情况。典型问题包括：模块间接口对不上、依赖注入顺序错、环境变量缺失、数据库连接失败、异步时序错乱。

第四层闸门就是要在“接近真实”的环境里，验证整个系统能不能跑起来。它不追求覆盖所有逻辑，只追求核心链路能通。所以这一层用的是冒烟测试的思路：启动服务、调用几个关键接口、检查返回是否符合预期。

6.2 冒烟测试脚本怎么写

以 Node 服务为例，一个最小可用的冒烟脚本大概长这样：

#!/bin/bash set -e echo "启动服务..." npm run start & SERVER_PID=$! sleep 5 echo "检查健康接口..." curl -f http://localhost:3000/health || exit 1 echo "检查核心业务接口..." curl -f http://localhost:3000/api/core || exit 1 echo "关闭服务..." kill $SERVER_PID echo "冒烟测试通过"

这个脚本虽然简单，但能拦住很多问题：服务起不来、端口被占、健康检查失败、核心接口 500。set -e保证任何一步失败就整体失败，不会“带病通过”。

6.3 集成失败的排查顺序

集成失败时，排查顺序很重要，乱查会浪费大量时间。我的顺序是：

1. 先看服务有没有起来：进程在不在、端口通不通、日志有没有报错。
2. 再看依赖有没有就绪：数据库、缓存、消息队列是否可连。
3. 然后看配置对不对：环境变量、配置文件、密钥是否齐全。
4. 最后才看业务逻辑：前面都正常，才怀疑代码本身。

这个顺序的逻辑是“从外到内、从基础设施到业务”。很多集成失败根本不是代码问题，而是环境问题，先查代码会南辕北辙。

注意：第四层闸门不要做自动修复。集成问题往往涉及环境和配置，AI 看不到你的服务器状态，它改出来的东西大概率是错的。这一层只报警，人工处理。

7. 常见问题与排查技巧实录

7.1 闸门跑得太慢怎么办

这是最常见的抱怨。四层全跑一遍，小项目可能几十秒，大项目几分钟。优化思路有几个：

• 并行化：第一层和第二层可以并行跑，它们互不依赖。
• 增量检查：只检查改动的文件，而不是全量。用lint-staged、jest --onlyChanged这类工具。
• 缓存：类型检查、测试结果都可以缓存，没改的模块直接复用上次结果。
• 分级触发：本地提交只跑前两层，推送到远端才跑全部四层。

我的实际配置是：本地 pre-commit 跑第一、二层（秒级），pre-push 跑第三层（分钟级），第四层放在 CI 里跑。这样日常开发几乎无感，又保证了质量。

7.2 AI 反复修不好同一个错误

这种情况通常说明问题不在“这一行代码”，而在“设计”。比如一个类型错误反复出现，可能是接口定义本身就不合理；一个测试反复失败，可能是业务逻辑的假设就是错的。这时候要停下来，回到设计层面重新想，而不是让 AI 继续在代码层面打转。

我的经验是设一个重试上限，三次修不好就人工介入。人工介入时，先看 AI 的修复历史，往往能发现它一直在“打补丁”，而不是“治本”。

7.3 测试通过但线上还是出问题

这说明闸门有盲区。常见盲区有：并发问题（单元测试是单线程的）、数据依赖（测试用的是 mock 数据，真实数据有脏值）、环境差异（本地和线上配置不同）、时序问题（异步在测试里是顺序的，线上是并发的）。

这些盲区没法靠单元测试覆盖，只能靠集成测试、灰度发布、监控告警来补。所以四层闸门不是终点，它是“交付前的最低防线”，不是“质量的全部保证”。这一点心态要摆正。

7.4 常见问题速查表

8. 我踩过的坑和几条实在建议

先说一个最深的坑：我一开始把四层闸门做成了“全自动”，结果 AI 把测试改绿了，但业务逻辑是错的。那次上线后才发现，一个金额计算的边界条件被 AI“修”成了永远返回 0，测试全绿，因为断言也被它改了。从那以后我就定了一条铁律：测试的断言不允许 AI 自动改，只能人工确认。这条规则救了我好几次。

第二个坑是闸门太多导致大家绕过它。有段时间我配了很严格的 pre-commit，结果每次提交要等两分钟，同事直接--no-verify跳过。后来我把本地检查精简到只跑格式和类型，测试放到 CI，大家才愿意用。闸门的第一原则是“有人愿意用”，第二才是“查得全”。

第三个坑是过度依赖 AI 自动修复。AI 修简单错误很靠谱，但遇到需要跨文件理解的问题，它经常“只见树木不见森林”。比如改一个函数签名，它只改了定义处，没改所有调用处，结果类型检查报一堆错。后来我让它在修复前先“搜索所有引用”，情况才好一些。

几条实在建议：第一，闸门要分层触发，本地轻、远端重；第二，自动修复要有重试上限和回滚机制；第三，测试断言和业务语义相关的修复必须人工确认；第四，定期回顾闸门拦住了哪些问题，据此调整规则，因为项目在变，闸门也要跟着变。

这套四层闸门我用了大半年，最大的感受是：它没有让 AI 变得完美，但它让 AI 的错误变得“可控”。以前是 AI 写完我提心吊胆地跑，现在是 AI 写完闸门先跑，跑到我手上的已经是过了四道筛子的版本。省下来的时间，我可以花在真正需要人判断的设计和架构上。这大概就是“让机器做机器擅长的事，让人做人擅长的事”最实在的落地方式。