企业官网建设流程全解析

开头我先说个结论：把 AI 当“搜索引擎”用太亏了。我最近一直在折腾 Qoder，目标不是让它帮我补全几行代码，而是把它训练成一个真正能接手工程任务的“数字同事”。从零搭脚手架这件事，恰好是带它“入职”的第一步——脚手架几乎覆盖了一个项目从目录结构、依赖选型、分层规范到启动方式的全部约定。把这些开发习惯同步给 AI，比让它多写几千行代码值钱得多。这篇内容适合那些已经用过 AI 写代码，但总感觉产出不稳定、风格不可控、一改需求就翻车的朋友。我会用一套能直接复用的方法，讲讲怎么把自己的开发习惯完整地、可持续地“教”给 AI。

1. 把开发习惯交给 AI：先搞清楚“数字同事”到底意味着什么

1.1 为什么选“脚手架”作为入职第一课

很多人第一次用 AI 编程，都是让它写个函数、排个 bug，有效果但很碎片。这就像招了个实习生，今天教他改一行配置，明天让他调一个接口，干了一个月还是对项目没有整体认知。

脚手架不一样。它是工程的骨架，一个 Spring Boot 项目从pom.xml到application.yml，从 controller 到 repository，从日志规范到异常处理，所有团队约定都沉淀在这些初始文件里。让 AI 完整搭一遍脚手架，本质上就是给它做了一次高密度的“入职培训”。

我实测下来，AI 搭完一遍脚手架之后，后续让它加接口、加模块、写测试，准确率和风格一致性都会上一个台阶。因为脚手架里隐含了你对分层、命名、依赖管理、配置方式的所有偏好，这些偏好一旦被 AI 吸收，它后续产出的代码就会自动对齐你的习惯，而不是它自己在网上学来的通用写法。

另一个原因很现实：问题规模决定成功率。让 AI 在一个 5 万行的老项目里改一个跨模块功能，它经常会上下文不足、改一半忘了另一半。但脚手架是可控的、全新的、边界清晰的，作为 AI 的“训练场”再合适不过。先在小而全的脚手架上验证流程，跑通了再把它放到真实项目里。

1.2 用 Qoder 这类 AI 编程底座，先看清 Agent 模式的边界

聊 Qoder 之前，先把工具分类理清楚。传统 AI 插件是“补全模式”，你写半个函数它就补另外半个，本质是高级输入法。而 Qoder 这类新一代 AI 编程工具走的是 Agent 模式——它能读取整个仓库、跨文件修改、按你的指令执行多步任务、甚至自己跑测试和命令。

选型时我不看宣传词，只看四个硬指标：

• 上下文感知能力：是只看当前打开的文件，还是能主动读整个项目结构；
• 规则文件支持：能不能通过AGENTS.md或类似机制，把项目规范持久化地绑定给 AI；
• 多文件编辑能力：修改一个需求时，能否同时改动 controller、service、repository 和测试文件；
• 自主执行能力：能不能让它自己编译、跑测试、根据报错自我修正，而不是每次把错误复制给你。

我用 Qoder 的主要原因，是它对这几项的支持比较均衡。它不强制你改变已有的 Git 工作流和 IDE 习惯，更像是在你熟悉的工程环境里多了一个会读代码、会动手改代码的同事。工具只是载体，核心还是你怎么设计规则、怎么下指令、怎么验收结果。

还得想清楚边界：Agent 模式不是万能的。它能处理执行层面的工作——代码怎么写、测试怎么跑、报错怎么查。但需求取舍、方案权衡、架构决策这些“判断型工作”要留给自己。把这个想明白，你才不会对 AI 产生不切实际的期待，也不会把好好的工具用成事故现场。

1.3 给 AI 定人设：数字同事的角色卡

带数字同事和带真人实习生，底层逻辑是一样的：先讲清楚你是谁、你要做什么、你绝对不能做什么。区别在于，AI 没有“悟性”，同样的意思你得用它能精确解析的格式来表达。

我习惯在项目根目录放一个角色卡文件，每次让 AI 干活之前先让它读一遍。这个文件就是 AI 的“员工手册”，不是什么花样文案，而是规则本身：

你是这个项目的后端工程师，技术栈是 Java 17 + Spring Boot 3.5 + MyBatis-Plus + MySQL。 你的行为准则： - 所有新增代码必须遵循项目目录分层：controller -> service -> mapper，禁止跨层调用； - 接口返回统一使用 Result<T> 包装，禁止直接返回裸数据； - 异常必须分类处理，业务异常抛 BizException，未知异常由全局拦截器兜底； - 写代码的同时必须补单元测试，覆盖正常路径和异常路径； - 日志用 slf4j，关键操作记 info，异常记 error，禁止 System.out.println； - 不得修改 pom.xml 中的依赖版本，除非任务明确要求； - 数据库操作一律走 mapper 层，禁止在 service 里直接写 SQL。 每次修改前，先列出你的计划，确认后再动代码。

这个角色卡有几个关键点需要注意。第一，它不提空话，“遵守代码规范”这种表述 AI 无法执行，但“禁止跨层调用”这种规则它执行得了。第二，它明确了产出物不只是代码，还有测试和日志。第三，它给了 AI 一个工作流程：先列计划再动手，这个习惯能避免它闷头改出一大堆不符合预期的东西。

角色卡不是写一次就完事了。我在后面几周的实操中发现，规则是随着踩坑不断叠加的。比如 AI 有几次在 service 里直接拼 SQL，我就在角色卡里加了“数据库操作一律走 mapper 层”；有几次它生成的测试类没有任何断言，我就在角色卡里加了“测试必须包含断言”。每个坑都是一条新规则，角色卡会越长越像你真正的团队成员。

2. 从零搭脚手架：让 AI 照着你的规范生成工程骨架

2.1 先定规范，再写代码：项目的“宪法”文件

很多人让 AI 搭脚手架，上来就说“帮我生成一个 Spring Boot 项目”，得到的自然是网上最常见的标准结构。能跑，但和你团队的代码风格大概率是两回事。问题出在顺序上：你得先定规范，再让 AI 动手。

我把规范文件拆成两个：AGENTS.md用来放“AI 怎么工作”的通用约定，比如新增代码前必须先列计划、必须补测试、不允许修改没有涉及的配置；CONVENTIONS.md用来放“代码怎么写”的具体规范，包括包结构、命名规则、返回格式、异常处理、日志规范。两个文件都在项目根目录，Qoder 这类工具在读取项目文件时会把它们自动纳入上下文。

这里有个实操细节：规范文件别贪多。我见过有人写了几百行规范，结果 AI 执行时反而抓不住重点。好的规范文件应该像空乘安全须知——短、明确、每条都能被执行和验收。一条规范如果没有对应的验收方式，不如不写。比如“日志要规范”这种话就没用，但“异常必须记 error 级别日志并包含堆栈”就有用，因为它可以被检查。

还有一点，规范文件是给人来看的吗？不是。它主要是给 AI 看的。所以语法上有一点很重要：用祈使句，少用描述性语言。“代码应保持简洁”是描述，“单行超过 120 字符必须换行”才是规则。把规范当成一系列 if-then 判断条件来写，AI 的服从度会明显提高。

2.2 实操生成 Spring Boot 3.5 脚手架

具体到脚手架生成的实操，我会给出一个我带 AI 搭 Spring Boot 3.5 项目时实际用过的提示词结构。注意，不是让你复制粘贴，而是理解这个结构为什么这么写。

请为以下项目搭建完整的 Spring Boot 3.5 脚手架，不要解释设计思路，直接输出可运行的代码和文件。 项目背景： - 项目名：user-center，包名：com.example.usercenter - Java 17，Spring Boot 3.5，Maven 管理依赖 - 数据库 MySQL 8，连接池用 HikariCP，ORM 用 MyBatis-Plus 必须包含的模块： - 统一返回体 Result<T>，包含 code、message、data 三个字段 - 全局异常处理，能捕获 BizException、参数校验异常、兜底异常 - 一个示例用户实体 User（id、username、email、created_at） - 对应的 UserMapper、UserService、UserController，实现简单的分页查询 - MyBatis-Plus 分页插件配置 目录规范： - controller 只做参数接收和结果返回，不写业务逻辑 - service 只做业务逻辑，不直接操作数据库 - mapper 只写数据库操作，不允许出现业务判断 补充要求： - 每个类必须有类注释，方法必须有方法注释 - 需要给出 SQL 建表语句，放在 resources/sql 目录下 - 生成后自行检查，确保 mvn compile 能通过

这个提示词里最关键的三个信息，大多数人会漏掉：一是“不要解释设计思路，直接输出可运行的代码”，这能避免 AI 生成一大堆没有信息的说明文字；二是“必须包含的模块”，界定了 AI 的职责范围，没写的不要让它自由发挥；三是“生成后自行检查，确保能通过编译”，这一步把验收动作前置了，AI 会尽量一次写对。

我实操中还有个习惯：让 AI 把生成的完整目录树和关键文件内容列出来，我再快速过一遍。这一步不能省，因为 AI 有时候会自以为聪明地加一些依赖，比如它给 MyBatis-Plus 项目又加了一个 JPA，这种冗余对后续开发是灾难。及时检查目录和依赖，比等项目写完再排查成本低得多。

2.3 入职检查清单：不只是“能跑”

脚手架生成之后，我会按一个固定的检查清单来验收，不会只满足于“项目能启动”。这套清单在后来带 AI 干真实活时也一直在用，算是从“搭架子”沉淀出来的标准动作。

这个表格我每次都会过一遍，不是为了挑刺，而是为了给 AI 形成“提交 = 要被检查”的预期。这跟带实习生一样，如果你不看他的第一版代码，他就以为标准是“能跑就行”。我印象很深的一次，AI 生成的分页查询里把页码参数直接拼进了 SQL 的 limit 语句，编译能过、功能也能跑，但存在注入风险。检查清单里如果有“SQL 是否走参数化查询”这一项，这种问题在入职阶段就能被第一时间纠正过来。

另外，检查清单本身也应该回写给 AI。我会在验收完之后，把发现的问题汇总成一段反馈发给 Qoder，让它自己读一遍并且修正。这样做的好处是，AI 在下一次任务里会主动规避同样的问题，而不是每次都要靠你亲自发现。把这一点做好，“带数字同事”才算真正开始。

3. 把开发习惯制度化：让 Qoder 学会你团队的协作方式

3.1 从一次性提问升级为可持续复用的规则

我用 AI 编程头两周最大的挫败感，是同样的问题会反复出现。今天让它写接口，它忘了用统一返回体；明天让它加功能，它又忘了写测试。每次我都要在提问里重新强调一遍，感觉像在教鱼游泳。

后来我想明白了：AI 是记不住对话的，它没有“上次你说过”的长期记忆。每一次新任务，它都是重新读仓库、重新理解背景。所以“可持续”这件事，不能靠每次提问时提醒，而要把规则固化到它每次启动任务时都会读取的文件里。

这就是为什么我在 2.1 里坚持要放AGENTS.md和CONVENTIONS.md。它们不只是一份文档，更是 AI 的“长期记忆外挂”。每次 Qoder 读取项目上下文，这些文件都会被自动纳入视野，等于你每一次都在告诉它这些规则，但只写了一遍。

这里有一个取舍要说清楚：规则文件不是越多越好。规则越复杂，AI 在具体任务中的注意力就越分散。我现在的习惯是，规则文件分“硬规则”和“软约定”。硬规则是违反就会导致代码进不了仓库的，比如禁止 System.out.println、禁止跨层调用；软约定是风格层面的，比如方法注释应该怎么写。硬规则必须精简，最好是 10 条以内；软约定可以多一点，但也不要超过 20 条。一旦超出这个量级，建议拆文件，按模块或按职责分开管理。

3.2 开发习惯的模板化：提交信息、代码风格、测试习惯

“教 AI 上班”最值钱的部分，是把那些你已经形成肌肉记忆的开发习惯，变成 AI 能直接套用的模板。我挑了三个最影响协作效率的方面来举例：提交信息、代码风格、测试结构。

先说提交信息。我原来用 AI 写代码有个痛点：它改了代码但不会帮你写 commit message，而我自己写又容易犯懒。后来我在规则文件里加了一条规定：每次任务完成后，AI 必须基于实际改动生成 commit message，并且遵循 angular commit 规范。实际效果挺好，它生成的提交信息比我手写的详细得多，而且能精确到每个文件改了什么地方：

feat(user): add pagination query for user list - add PageResult<T> wrapper for unified page response - implement UserService.pageQuery with MyBatis-Plus pagination - add corresponding unit tests for service and controller layers Closes #12

代码风格这块，纯文字描述很难让 AI 完全对齐，最有效的方案是给示例。在CONVENTIONS.md里放一小段“好代码示例”和“错误代码示例”，AI 的模仿能力会直接把这些示例变成模板。我实测下来，给示例比写一百句“你写得整洁一点”管用得多。

测试习惯也一样。我要求 AI 生成的测试遵循 given-when-then 三段式结构，并且必须包含断言。这个要求看似基础，但在 AI 生成的测试里，我碰到过太多只有调用没有断言的“假测试”。规则文件里加一句“没有断言的测试视为未完成”，这个问题基本就绝迹了。

3.3 Skills 与多 AI 协作：把工作流变成可插拔技能

规则文件解决的是“习惯一致”，Skills 解决的是“能力可复用”。简单理解，Skill 就是给 AI 装的一个可插拔插件——把某类任务的完整操作流程打包成一个独立组件，让 AI 在特定场景下自动调用。

我写过最常用的一个 Skill 是代码审查。以前让 AI 审查代码，它的输出是泛泛而谈的，什么“可读性有待提升”“建议增加注释”，一点用都没有。后来我把它定义成一个 Skill，规定了审查必须输出的结构、必须检查的维度、按严重程度排序的输出格式。

# Code Review Skill ## 触发场景 当用户要求 review 代码或 Merge Request 时启用。 ## 审查流程 1. 读取目标代码及其相关上下文（调用方、被调用方、测试文件）。 2. 按以下维度逐项检查： - 正确性：逻辑是否有边界条件遗漏； - 安全性：是否存在注入、越权、敏感信息泄露； - 异常处理：失败路径是否有兜底； - 性能：是否存在不必要的循环或 SQL 查询； - 规范一致性：是否对齐项目 CONVENTIONS.md。 3. 输出格式： - 按严重级别分类：Block / Major / Minor / Suggestion； - 每条意见必须标注文件与行号，禁止笼统评论； - 每条必须给出修复建议或代码示例。 ## 注意事项 - 发现问题时先给证据，再给建议； - 不确定的问题标注“待确认”，不要编造； - 风格类意见统一归入 Minor，不占用主要篇幅。

多 AI 协作是另一个思路。我在一些稍大的任务里会让多个 AI 实例分工：一个负责需求拆解和方案设计，一个负责具体编码，一个专门负责挑毛病。这就像你把“结对编程”和“代码评审”一起虚拟化了。Qoder 在任务上下文里可以启动对话，我会这样分配角色：

规划 AI 只输出实现步骤和改动点清单，不写代码；执行 AI 照着规划动手改，改完自测；审查 AI 按 Skill 的规则挑刺，挑出来的问题回到执行 AI 那里修。这套流程跑顺之后，代码质量比我单人写的时候还稳，因为每个环节都有专门的眼睛在盯着。很多开发者担心“AI 写的代码没人 review”，解决方案其实不是不让人工 reviewer 参与，而是让 AI 先 review 两轮，给人留出精力只看真正有争议的问题。

4. 真实任务走一遍：从需求到自测，AI 全程参与

4.1 任务拆解与提示词设计

搭完脚手架、立好规则之后，我拿一个真实需求来测试 AI 的“上手能力”：给用户中心加一个注册接口，要求校验邮箱唯一、密码加密存储、返回标准化结果。这里我用一个相对完整的任务提示词，展示怎么在真实场景里给 AI 下指令。

任务：实现用户注册接口。 背景：项目 user-center 已经搭好，统一返回体是 Result<T>，全局异常已配置。 需求： - POST /api/users/register，入参 username、email、password； - username 长度 4-20，email 格式校验，password 至少 8 位且包含字母和数字； - 注册前校验 email 是否已存在，存在则抛 BizException，错误码 USER_EMAIL_EXISTS； - 密码用 BCrypt 加密存储，禁止明文入库； - 返回结果包含新用户 id 和 username。 约束： - 遵循 CONVENTIONS.md 的目录分层； - 必须写 service 层和 controller 层测试，测试需要覆盖正常注册、重复邮箱注册、参数不合法三种场景； - 不要修改 pom.xml； - 完成后执行 mvn test 并报告结果。 先给出修改计划，再开始动代码。

这个提示词有五个要素，缺一不可：需求背景、功能描述、约束条件、验收标准、工作流程。很多人只给中间两项，AI 就会在没有上下文的情况下自由发挥。特别是最后一句“先给出修改计划，再开始动代码”，我几乎每次都会带。AI 把计划列出来之后，你会发现很多问题在动代码之前就能暴露出来——比如它打算在 controller 里写业务逻辑、或者准备引入一个新的依赖来“解决”校验问题。

任务下发之后，Qoder 会按计划修改多个文件。你应该要求它把每次改动的核心内容同步给你，而不是埋头改完一次性丢个大结果。把过程透明化放在 AI 协作里同样重要，因为中间的每一步都可能产生偏离规范的代码，及时发现比事后返工效率高。

4.2 AI 生成代码后的 Code Review 流程

AI 跑完测试不等于任务结束，还需要过一轮 Code Review。我在 3.3 里定义了审查 Skill，这里说一个实际案例：AI 实现的注册接口，自测全部通过，但 review 时发现了三个问题——密码字段在日志里被打印了；邮箱重复校验存在竞态条件，高并发下可能漏掉；异常分支没有给用户友好的提示文案。

这三点如果你人肉去 review，得一行行看过去，很耗精力。但用审查 Skill，AI 在几秒内就把问题按 Block/Major/Minor 分类列出来了，每个问题都有文件路径和修改建议。密码打日志是 Block 级别，因为线上信息泄露风险；邮箱校验竞态得改 SQL 加唯一索引或在 service 层做分布式锁；异常提示是 Minor，数据库唯一索引冲突时转成友好错误码就行。

这个流程走下来我最大的体会：让 AI 自己 review AI 写的代码，不是“机器审机器”那么肤浅。因为审查规则是由你定义的，你输出的不是“让 AI 自发地变得严谨”，而是“把你心中成熟的 review 检查点变成自动化能力”。真正需要人来判断的是问题优先级，而不是逐行检查本身。

4.3 让 AI 自己跑测试：把报错变成养料

任务里我要求 AI 完成后执行mvn test并报告结果，这一步很关键。很多人的使用习惯是让 AI 写完代码就结束，测试自己手动跑，报错了自己去读、去改。这等于你把最值钱的“自我闭环能力”给废掉了。

当 Qoder 执行测试失败时，我会把完整报错信息原样回贴给它，让它自己分析、修改、重跑。注意，不是让它“猜”原因，而是要求它把报错定位到具体文件和具体断言，说明为什么失败，再给出修复方案。

有个印象很深的例子：AI 注册接口测试失败，报错是SQLIntegrityConstraintViolationException。它一开始以为是自己 mock 数据的问题，改了测试数据还是失败。我把完整堆栈贴回去之后，它才定位到是 MyBatis-Plus 自动生成的 SQL 里省略了 email 字段。这个问题最后改的是通用 Mapper 的插入策略配置，而不是测试代码。如果我没有走“贴报错—让 AI 定位—让 AI 修复”这个闭环，我自己查这个原因至少得花二十分钟。

测试闭环跑通之后，AI 后续写代码的长进非常明显。它学会了先检查字段映射、再写业务逻辑；学会了在测试之前先站在数据库角度想一遍约束条件。这些话我没有在规则文件里写，是它在一次次的报错修正里自己沉淀下来的——这就是“让它上班”和“让它跑腿”的区别。

5. 我踩过的坑与排查心得

5.1 上下文越用越薄：工程大了 AI 会“失忆”

头一两周，项目还小，AI 的表现很好。等到仓库里文件超过二三十个、模块之间耦合变多之后，问题开始出现了：AI 有时候改 A 模块时会忽略 B 模块里对 A 的调用，导致编译不过；或者新增的接口没有遵循几个月前在另一个文件里定义的规范。

原因很朴素：AI 的上下文窗口是有限的。它默认读取的文件有限，不可能把整个仓库都装进一次上下文里。我现在的解决办法是：关键信息前置 + 显式文件引用。任务描述里明确写出“本次修改涉及的文件包括哪些，你响应前先读取这些文件”；对于长期不变的规范，全部沉淀到CONVENTIONS.md，靠配置文件而不是靠 AI 记忆。显式引用比让它“自己探索”更可靠，尤其当项目结构复杂、文件命名接近的时候。

还有一点值得注意：每次任务尽量收窄范围。让 AI 一次只做一个内聚的功能，而不是“把这个模块重构一下顺便把那个 bug 修了”。任务范围越窄，上下文命中率越高，产出质量越稳定。

5.2 风格漂移：同一件事，这次和上次写的不一样

我发现 AI 有个毛病叫“风格漂移”：同一个功能，上次生成的代码用Optional.ofNullable，这次生成的就用if (xxx != null)。逻辑都没错，但项目代码风格会变得越来越不一致，最后维护成本全砸在你头上。

这个问题光靠规则文件里的文字约束解决不了，最有效的做法是“锚定示例”。在CONVENTIONS.md里放上两三个你满意的代码片段，明确说“类似场景一律按示例风格写”。AI 对示例的模仿能力远强于对抽象规则的理解，这在我多次实测中都得到了验证。我会同时把示例代码放进项目的某个固定示例包里，让 AI 在犹豫时有一个可视化的参照。

另外，每次做完任务之后，我会顺手把 AI 写得“特别对味”的那段代码摘进规范文件里，作为新的正例。时间一长，规范文件本身就在持续进化，它承载的不只是你原本的习惯，还融合了 AI 在协作中表现出的最佳实践。

5.3 脏活清单：哪些事别交给 AI

说句实在话，不是所有活都适合交给 AI。我踩过的坑里面，最贵的一次是让 AI 直接改数据库迁移脚本，它把一张表的历史数据更新逻辑给重写了，幸好有备份回滚。从那以后我给自己定了一份“不交给 AI”的脏活清单：

这里不是完全不许 AI 碰这些，而是要有“人先定方案、AI 只执行”的分工。让 AI 参与实施之前，我会先给它一个明确的操作边界：哪些能改，哪些只能看不能动，做完之后必须等人工确认。这比事后发现它越权再回滚要省心得多。

5.4 提问的“三给”原则

总结这段时间带 AI 的经验，我发现自己提问方式的改变对产出质量影响最大。现在我的每次任务指令都遵循一个“三给”原则：

• 给角色：你是谁、在这个任务里处于什么位置；
• 给约束：规则是什么、哪些不能做、边界在哪里；
• 给验收标准：怎么算完成、跑什么命令、结果怎么汇报。

这三条少了任何一条，AI 产出的质量就像开盲盒。“给角色”是定基调，让 AI 不至于用通用经验对付你的项目；“给约束”是踩刹车，防止它自由发挥引入你没有预期的依赖或设计；“给验收标准”是设终点，让它拥有自己检查自己工作的判断依据。

还有一个习惯上的变化：“下次注意”是没有用的，AI 没有记忆。你把一条规则告诉它十次，不如把它写进规则文件一次。遇到 AI 反复犯同一个错误时，最优操作不是反复纠正它，而是停下来更新规则文件，然后重新开启任务。规则文件才是你和 AI 之间真正的协作契约，每一条新规则都来自一个真实踩过的坑，它不是文档，是你们俩共同迭代出来的工作协议。

带数字同事这件事，做久了以后，我最大的感受是：它没有让我失业，也没有让我变成不用写代码的“甩手掌柜”，而是把我从重复劳动里解放了出来，把精力逼到了真正需要判断力的地方。我每天写代码的量变少了，但对项目全局、对规范设计、对任务拆解的思考变多了。最后分享一个我一直在坚持的小习惯：每周花半小时重读一遍项目里的AGENTS.md和CONVENTIONS.md，把本周踩过的坑沉淀成新规则，删掉那些已经不再适用的旧约定。这份文件越贴近现状，AI 就越像一个真正懂你项目的老同事，而不是一个每次都要重新教一遍的新人。