企业官网建设流程全解析

1. 为什么默认配置下的AI编辑器总让人想砸键盘

刚用AI代码编辑器那会儿，我跟大多数人一样，装完就开干，结果不到三天就想卸载。最典型的一幕：我让它帮我改一个工具函数，它反手把整个文件重写了一遍，连我半年前写的兼容逻辑都删了；我让它补一个类型定义，它给我生成了一堆用不上的接口，还顺手把import顺序全打乱了。每次改完代码，git diff里红红绿绿一大片，review的时候比我自己手写还累。

问题出在哪？不是模型不够聪明，而是默认配置下，AI根本不知道你的项目长什么样、你的编码习惯是什么、哪些文件不能碰。它就像一个刚入职的新人，能力是有的，但没人告诉它团队规范，于是只能按自己的理解乱来。而大多数人抱怨"AI写代码不好用"，本质上是在抱怨"我没花时间教它怎么配合我"。

这套规则的核心思路就一句话：把AI当成一个需要明确边界和上下文的协作者，而不是一个许愿池。你需要通过配置文件告诉它三件事——你是谁、你的项目是什么、哪些事绝对不能做。配置到位之后，我实测下来，日常CRUD和工具函数的编写效率至少提升了一半，更重要的是，改出来的代码基本不用大改，review成本直线下降。

这篇文章适合两类人：一是刚接触AI代码编辑器、被默认行为搞得头大的新手；二是用了一段时间但总觉得"差口气"、想系统化调优的老用户。我会从规则文件的结构讲起，到具体每条规则怎么写、为什么这么写，再到实测中踩过的坑和验证方法，全部拆开讲清楚。你不需要什么特殊环境，只要编辑器支持自定义规则文件，跟着配就行。

2. 规则文件到底该放哪、分几层来写

2.1 全局规则与项目规则的分工逻辑

很多人配置AI编辑器时，把所有规则一股脑塞进一个文件，结果换个项目就全乱套。正确的做法是分层管理，我一般分两层：

• 全局规则：放在用户目录下，管的是"我这个人"的通用偏好。比如我习惯用4空格缩进、函数注释用中文、变量命名用驼峰、不喜欢AI主动加emoji到代码注释里。这些规则跨项目不变，写一次就行。
• 项目规则：放在项目根目录，管的是"这个项目"的特殊约定。比如这个项目用的是某个特定框架的旧版本、某个目录下的文件是自动生成的不能改、API请求必须走统一的封装层。

为什么要分开？因为全局规则是"人设"，项目规则是"项目宪法"。混在一起的话，你换项目时要么带着一堆没用的规则，要么漏掉关键约束。我见过有人把项目专用的数据库连接规则写进全局，结果新项目里AI一直试图连一个不存在的库，排查了半天才发现是全局规则在作祟。

提示：如果你的编辑器支持多级规则继承，优先级一般是"项目规则覆盖全局规则"。写规则时先想清楚这条是"我永远这样"还是"这个项目这样"，放错层级比不写还麻烦。

2.2 规则文件的推荐目录结构

我现在的习惯是在项目根目录建一个专门的规则目录，里面按用途拆成几个文件，而不是写一个巨长的单文件。原因很简单：单文件写到几百行之后，你自己都懒得维护，AI读取时也容易抓不住重点。拆开之后，每个文件职责单一，改起来也方便。

具体结构大概是这样：

项目根目录/ ├── .ai-rules/ │ ├── 00-项目概览.md # 项目是干什么的、技术栈、目录结构说明 │ ├── 01-编码规范.md # 命名、缩进、注释、import顺序 │ ├── 02-架构约束.md # 分层规则、哪些层不能互相调用 │ ├── 03-禁止事项.md # 绝对不能碰的文件和操作 │ └── 04-常用模式.md # 本项目里反复出现的代码写法示例

编号是为了让AI按顺序读取，先了解全貌，再掌握细节，最后知道红线在哪。这个顺序很重要——如果先读禁止事项，AI可能因为不知道项目背景而过度保守，什么都不敢改。

2.3 项目概览文件里必须写清楚的几件事

00-项目概览.md是AI理解项目的入口，写得好不好直接决定后续所有交互的质量。我一般会写这几块内容：

第一，一句话说清项目定位。比如"这是一个面向内部运营的后台管理系统，前端用某框架，后端用某语言，数据库是某类型"。别小看这一句，它能让AI在生成代码时自动匹配对应的生态习惯，而不是给你写一个风格完全不搭的实现。

第二，目录结构说明。把主要目录列出来，标注每个目录放什么。比如src/utils放纯函数工具、src/services放接口请求封装、src/components放通用组件。这样AI在你说"帮我加个工具函数"时，就知道该往哪放，而不是随手丢在根目录。

第三，技术栈版本信息。这点极其关键。同一个框架的不同大版本，API写法可能完全不同。如果你不写清楚，AI很可能按最新版本的写法给你生成代码，结果你项目里用的是旧版本，跑都跑不起来。我踩过这个坑：项目里用的是某个库的旧版，AI按新版语法生成了一堆代码，编译报错几十处，最后只能全部回退重写。

第四，当前项目的特殊约定。比如"所有时间字段统一用某格式存储"、"接口返回统一包一层结果对象"、"日志必须走统一的logger而不是console"。这些约定不写，AI就会按通用做法来，跟你的项目格格不入。

3. 编码规范规则：让AI写出的代码像你亲手写的

3.1 命名与格式规则的写法

编码规范这块，最忌讳写得太抽象。你写"遵循良好的命名习惯"，AI根本不知道你指的是什么。必须具体到可执行的程度。我一般这么写：

• 变量和函数用驼峰命名，常量用全大写下划线分隔，类名用大驼峰。
• 布尔值变量必须以is、has、can开头，比如isLoading、hasPermission。
• 私有函数以下划线开头，比如_parseConfig。
• 缩进统一4空格，不用Tab。
• 单行代码不超过120字符，超了必须换行。
• import顺序固定为：标准库、第三方库、项目内部模块，每组之间空一行。

这些规则看起来琐碎，但效果立竿见影。配置之前，AI生成的代码命名风格飘忽不定，一会儿getUserInfo一会儿fetch_user_data，看着就难受。配置之后，生成的代码基本能直接融入现有代码库，不用再手动调整格式。

注意：规则要写成"必须/禁止"的肯定句式，不要写成"建议/尽量"。AI对模糊表述的理解很不稳定，你写"尽量用驼峰"，它可能一半驼峰一半下划线。写"必须用驼峰，禁止下划线"，执行率明显高很多。

3.2 注释与文档规则的取舍

注释这块要特别小心，因为AI有个坏毛病：要么不写注释，要么写一堆废话注释。比如// 设置变量x为1这种，纯属噪音。我的做法是在规则里明确注释的边界：

• 函数必须有注释，说明功能、参数含义、返回值，但不要逐行解释代码在做什么。
• 复杂逻辑（比如多层条件判断、位运算、正则）必须有行内注释，解释"为什么这么做"而不是"做了什么"。
• 禁止生成// TODO之类的占位注释，除非我明确要求。
• 注释语言统一用中文，专业术语可保留英文。

这里有个经验：注释规则里最好给一个正例和反例。光说"不要写废话注释"，AI可能理解不到位。我直接在规则文件里贴两段示例代码，一段是好的注释风格，一段是差的，并标注"参考正例，避免反例"。实测下来，这种方式对AI的引导效果比纯文字描述强得多。

3.3 用示例代码代替抽象描述

这是我认为整个规则配置里最有效的一招：与其用文字描述你要什么风格，不如直接给一段示例代码。AI对代码示例的模仿能力远强于对文字规则的理解能力。

比如我想让AI生成的工具函数都遵循某种结构，我就在规则文件里写一个模板：

/** * 函数功能简述 * @param {类型} 参数名 - 参数说明 * @returns {类型} 返回值说明 */ function functionName(param) { // 参数校验 if (!param) { throw new Error('参数不能为空'); } // 核心逻辑 // 返回结果 return result; }

然后注明"所有新增工具函数必须遵循此结构"。之后AI生成的函数基本都长这样，参数校验、核心逻辑、返回结果三段式清清楚楚。这比写十条文字规则都管用。

同样的思路可以用在组件模板、接口请求封装、错误处理等所有反复出现的代码模式上。规则文件里多贴几个模板，AI的输出就越来越像"你写的"。

4. 架构约束与禁止事项：给AI划出不能越的线

4.1 分层调用规则怎么写才不被绕过

架构约束是规则配置里最容易被忽视、但出事最严重的部分。AI不懂你的架构分层，它看到两个模块就敢互相调用，结果把好好的分层结构搅成一锅粥。我一般会明确写出调用方向：

• 视图层只能调用服务层，禁止直接访问数据层。
• 服务层可以调用数据层和工具层，禁止反向调用视图层。
• 工具层是纯函数，禁止依赖任何其他层，禁止有副作用。
• 跨层调用必须通过明确的接口，禁止直接引用内部实现。

写这些规则时，我会顺便说明为什么这么分层。比如"工具层保持纯净是为了方便单元测试和复用"，AI理解了动机之后，在边界情况下更容易做出正确判断，而不是机械地遵守字面规则。

实测中我发现，光写规则还不够，最好在规则文件里点名几个容易违规的典型场景。比如"在视图层直接写数据库查询是禁止的，必须通过服务层封装"，这种具体场景的警示比抽象规则有效得多。

4.2 哪些文件是AI绝对不能碰的

这条规则能帮你省下大量回滚代码的时间。每个项目都有一些"动一发牵全身"的文件，AI不知道轻重，改起来毫不手软。我一般会列一个禁止修改清单：

• 自动生成的代码文件（比如协议文件、ORM生成的模型）。
• 配置文件（比如构建配置、部署配置），除非我明确要求改。
• 数据库迁移脚本，这类文件一旦生成就不能改，只能新增。
• 第三方库的补丁文件。
• 包含密钥、证书等敏感信息的文件。

写这条规则时，我会用绝对明确的路径匹配，而不是模糊描述。比如直接写"禁止修改src/generated/目录下的任何文件"，而不是"不要改自动生成的文件"。路径明确，AI才能准确判断。

提示：禁止事项最好单独放一个文件，并且在文件开头用一句话强调"以下规则优先级最高，任何情况下不得违反"。我试过把禁止事项混在编码规范里，结果AI有时候会"权衡"一下觉得某条规范更重要就忽略了禁止项。单独成文件、明确优先级之后，这种情况基本没再出现。

4.3 依赖引入的审批规则

AI还有个习惯：遇到问题就想引入新依赖。你说"帮我解析个日期"，它可能给你推荐一个日期库；你说"帮我做个深拷贝"，它又想引入一个工具库。项目依赖越加越多，打包体积越来越大，最后没人说得清每个库是干嘛的。

我的规则是：新增任何第三方依赖必须先问我，禁止直接引入。如果确实需要某个功能，优先用现有依赖或标准库实现。规则里我会写清楚"当前项目已有哪些依赖可用"，这样AI在需要时优先从现有依赖里找方案，而不是动不动就推荐新的。

这条规则配合"禁止事项"一起用效果最好。我在禁止事项里写"未经确认禁止修改依赖配置文件"，在编码规范里写"优先使用现有依赖"，双管齐下，AI基本不会再擅自加库了。

5. 常用模式规则：把重复劳动交给AI

5.1 接口请求封装的统一模板

后台项目里，接口请求是最频繁的操作。如果每次让AI写请求代码，它可能这次用这种写法、下次用那种写法，维护起来很痛苦。我的做法是在规则文件里放一个标准的请求模板，包含错误处理、loading状态、参数校验的完整流程。

模板大概长这样：

async function fetchData(params) { // 参数校验 if (!params.id) { throw new Error('缺少必要参数'); } try { const result = await request({ url: '/api/xxx', method: 'GET', params }); return result.data; } catch (error) { // 统一错误处理 logger.error('请求失败', error); throw error; } }

然后注明"所有新增接口请求必须遵循此模板，只需替换url和参数处理逻辑"。之后我让AI加接口，它就直接套模板，错误处理和日志都自动带上，不用我每次提醒。

5.2 组件与状态管理的固定写法

前端组件也是重复劳动的重灾区。我在规则里定义了几种组件模板：纯展示组件、带状态的容器组件、列表组件。每种模板都规定了props定义方式、状态声明位置、事件处理命名规范。

比如列表组件模板会规定：必须有loading态、空态、错误态三种状态处理，列表项必须有唯一key，分页参数必须走统一的分页组件。这些规定写进规则后，AI生成的列表组件直接就是完整可用的，不用我再补各种边界状态。

状态管理这块，我会明确写"全局状态必须通过某状态管理库，禁止在组件里直接改全局变量"、"局部状态优先用组件内部状态，不要什么都往全局塞"。这些规则能有效防止AI把简单问题复杂化。

5.3 错误处理与日志的统一约定

错误处理是最能体现项目成熟度的地方，也是AI最容易写乱的地方。有的地方try-catch，有的地方直接抛，有的地方吞掉异常，风格完全不统一。我在规则里统一约定：

• 所有可能失败的异步操作必须try-catch。
• catch块里必须记录日志，禁止空catch。
• 面向用户的错误提示必须友好，技术细节只进日志。
• 禁止在catch里直接console.log，必须走统一logger。

这些约定配合前面说的请求模板，基本能保证AI生成的代码在错误处理上是统一且完整的。实测下来，配置前后最大的区别就是：以前AI写的代码经常漏掉错误处理，我得手动补；现在它自动就带上了，省心很多。

6. 实测中踩过的坑和验证方法

6.1 规则写太满反而让AI变笨

这是我踩的第一个大坑：一开始兴奋过头，写了三百多条规则，恨不得把每个细节都规定死。结果AI变得畏手畏脚，让它写个简单函数，它反复确认"这样写符合规则吗"，生成速度慢了一大截，而且经常因为规则之间冲突而卡住。

后来我做了减法，把规则精简到核心的二十条左右，只保留真正影响代码质量和架构安全的内容。那些"锦上添花"的偏好，比如注释里用句号还是分号，全部删掉。精简之后，AI的响应速度和生成质量反而都提升了。

经验就是：规则要抓大放小，管住架构和规范底线，细节留给AI自己发挥。你管得越细，AI越像个提线木偶，反而失去了它该有的灵活性。

6.2 规则冲突时的排查思路

规则写多了，难免出现互相矛盾的情况。比如一条规则说"函数不超过50行"，另一条模板里的示例函数有60行。AI遇到这种冲突时，行为很不稳定，有时候按这条、有时候按那条。

我的排查方法是：先看AI的实际输出，找到它违反的那条规则，然后回溯规则文件里有没有跟它冲突的表述。找到冲突后，要么删掉一条，要么明确优先级。我一般会在规则文件开头写一句"如遇规则冲突，以禁止事项文件为准，其次以项目概览为准"，给AI一个明确的裁决顺序。

还有一种隐蔽的冲突：规则和示例代码不一致。文字规则说"用A写法"，但示例代码里是B写法。AI会优先模仿示例代码，导致文字规则形同虚设。所以每次改规则，我都会检查示例代码是否同步更新了。

6.3 怎么验证规则真的生效了

配完规则不能就完事了，得验证。我的验证方法分三步：

第一步，用几个典型场景测试。比如让AI写一个工具函数、加一个接口请求、改一个组件，看输出是否符合规则。每个场景测两三次，看稳定性。

第二步，故意诱导AI违规。比如让它"快速实现一个功能，不用管规范"，看它会不会真的跳过规则。如果它依然遵守规则，说明规则约束力够强；如果它一诱导就违规，说明规则写得不够明确或者优先级不够。

第三步，定期review AI生成的代码。规则不是配一次就永久有效的，项目在演进，规则也要跟着更新。我一般每两周花十分钟看看最近AI生成的代码，发现反复出现的问题就补一条规则，发现过时的规则就删掉。

提示：验证时最好用真实任务而不是测试用例。真实任务里AI面临的信息更复杂，更容易暴露规则配置的盲区。我试过用精心设计的测试用例验证，结果全过，但一到真实开发就出问题，就是因为真实场景的上下文复杂得多。

7. 不同项目阶段的规则调整策略

7.1 新项目起步期的规则重点

新项目刚开始时，代码库还很小，这时候规则的重点应该放在建立规范上。我会把编码规范、目录结构、技术栈约定写得详细一些，因为这时候定下的基调会影响整个项目周期。AI在这个阶段生成的代码，基本就是项目后续代码的模板，所以规则要写得"严"一点。

这个阶段我还会特别强调"禁止引入不必要的依赖"和"保持目录结构清晰"。新项目最容易失控的就是依赖膨胀和目录混乱，一开始管住，后面省心。

7.2 维护期项目的规则侧重

项目进入维护期后，代码库已经很大，这时候规则的重点要转向保护现有代码。禁止事项要写得更细，明确哪些老代码不能动、哪些兼容逻辑必须保留。我一般会加一条"修改现有函数时，必须保留原有的边界处理和兼容逻辑，除非明确要求重构"。

维护期还有个特点：新代码往往要跟老代码风格保持一致。这时候规则里最好说明"新增代码遵循本文档规范，但与相邻老代码风格冲突时，优先保持局部一致性"。这条规则能避免AI在老旧文件里强行套用新规范，搞得一个文件里两种风格。

7.3 多人协作时的规则同步

如果是多人协作，规则文件必须纳入版本管理，跟代码一起提交。我见过团队里每个人本地规则不一样，结果同一个人今天生成的代码和明天生成的风格都不同，更别说不同人之间了。

我的做法是：规则文件放在项目仓库里，任何人修改规则都要走代码review流程。这样规则本身就是团队共识的体现，AI生成的代码自然也就符合团队共识。新成员入职时，规则文件也是很好的项目规范文档，一举两得。

另外，团队协作时规则里最好注明"如有疑问，以团队最新约定为准"，并留下一个更新规则的入口说明。规则不是一成不变的，团队在演进，规则也要跟着走。

这套配置方法我用了大半年，从最初的"AI老帮倒忙"到现在"基本能放心让它写"，中间踩的坑基本都写在这了。核心就一句话：别指望AI猜你的心思，把该说的说清楚，它比你想的好用得多。规则文件不用一次写完美，边用边调，用着用着你就会发现，改代码这件事，真的可以少写一半。