企业官网建设流程全解析

1. 为什么“耳聪目明”的AI助教不是靠模型本身

很多人第一次接触AI助教，脑子里想的都是“换个更强的模型是不是就行了”。我一开始也这么想，后来发现完全不是这么回事。模型再强，如果你给它的项目上下文是残缺的、指令是模糊的、资产是散乱的，它就像一个听力正常但被蒙住眼睛的人——你说什么它都听不真切，看什么都是模糊的。

所谓“耳聪目明”，拆开来看是两件事。“耳聪”指的是AI能准确理解你的意图，你一句话它就知道你要什么，不需要反复解释；“目明”指的是AI能看到你项目的全貌，知道你的目录结构、代码规范、业务逻辑、历史决策，而不是每次对话都从零开始。这两件事，模型本身只能解决一小部分，剩下的大部分要靠项目配置来解决。

我见过太多团队，花大价钱买了最好的模型API，结果AI助教用起来还是像个刚入职的实习生——问什么都要从头解释，写出来的代码风格跟项目格格不入，改个bug能把三个不相关的文件一起改坏。问题不在模型，在于项目配置没有做到位。

这一篇要聊的，就是怎么通过项目配置，把AI助教从“实习生”变成“老搭档”。核心围绕四个东西展开：项目指令、资产库、提示词工程、上下文管理。这四个东西配好了，AI助教才能真正做到耳聪目明。

注意：本文讨论的“AI助教”泛指在IDE或项目环境中辅助开发的AI工具，包括但不限于代码补全、对话式编程、自动化重构等场景。不同工具的具体配置方式有差异，但底层逻辑是相通的。

2. 项目指令：给AI助教立规矩的第一份文件

2.1 项目指令到底在解决什么问题

项目指令（Project Instructions）是AI助教每次启动时最先读取的配置文件。你可以把它理解成“给新员工的第一份入职手册”——里面写清楚了项目是做什么的、代码怎么组织、命名用什么风格、哪些事能做哪些事不能做。

没有这份文件的时候，AI助教的行为完全靠你每次对话时临时描述。你说“帮我加个接口”，它不知道你的接口要放在哪个目录、用什么框架、返回什么格式、要不要写单元测试。你每次都得补充一大堆上下文，效率极低，而且容易遗漏。

有了项目指令之后，这些信息变成常驻上下文。AI助教在每次响应之前都会先读一遍，相当于它已经“知道”了这些规矩。你再说“帮我加个接口”，它就会自动按照项目规范来写，不需要你反复提醒。

我实测下来的经验是：一份好的项目指令，能把AI助教的首次响应准确率从40%左右提升到80%以上。剩下的20%靠的是资产库和提示词的配合。

2.2 项目指令应该包含哪些内容

项目指令不是越长越好，关键是信息密度要高。我一般会把它分成五个模块来写：

第一个模块是项目概述。用三到五句话说明这个项目是做什么的、面向什么用户、核心功能有哪些。这部分不需要太详细，目的是让AI助教建立一个大致的认知框架。比如“这是一个面向中小企业的后台管理系统，包含用户管理、订单管理、数据报表三大模块，前端用React，后端用Spring Boot”。

第二个模块是目录结构说明。列出项目的主要目录和它们的职责。比如src/main/java/com/xxx/controller放控制器、src/main/java/com/xxx/service放业务逻辑、src/main/resources/mapper放MyBatis映射文件。这部分越具体越好，AI助教需要知道“什么东西应该放在哪里”。

第三个模块是代码规范。包括命名规范（驼峰还是下划线）、注释规范（类注释、方法注释的格式）、异常处理规范（统一异常类、错误码规则）、日志规范（用什么级别、什么格式）。这部分直接决定了AI助教写出来的代码能不能直接用。

第四个模块是技术栈和依赖。列出项目用到的核心框架和版本号，比如Spring Boot 3.2、MyBatis Plus 3.5、Redis 7.0。这样AI助教在生成代码时就不会用错API或者引入不兼容的写法。

第五个模块是禁止事项。明确告诉AI助教哪些事不能做。比如“不要修改pom.xml中的依赖版本”、“不要在controller中直接写业务逻辑”、“不要使用已废弃的API”。这部分是防止AI助教“好心办坏事”的关键。

2.3 项目指令的写法示例与避坑

我见过很多人写项目指令，要么写得太笼统（“请按照规范编写代码”），要么写得太琐碎（把每个类的每个方法都列一遍）。这两种都不对。太笼统等于没说，太琐碎会占用大量上下文窗口，反而影响AI助教的响应质量。

一个比较合理的写法是这样的：

# 项目指令 ## 项目概述 企业级后台管理系统，包含用户、订单、报表三大模块。 前端：React 18 + Ant Design 5 后端：Spring Boot 3.2 + MyBatis Plus 3.5 + Redis 7.0 ## 目录结构 - controller/：接收请求，参数校验，调用service - service/：业务逻辑，事务控制 - mapper/：数据库操作，XML在resources/mapper下 - entity/：数据库实体，与表一一对应 - dto/：数据传输对象，用于controller和service之间 - config/：配置类 ## 代码规范 - 类名大驼峰，方法名小驼峰，常量全大写下划线 - 每个public方法必须有Javadoc注释 - 统一使用Result<T>包装返回值 - 异常统一抛BusinessException，由全局异常处理器捕获 - 日志使用@Slf4j，禁止System.out.println ## 禁止事项 - 不要修改pom.xml中的依赖版本 - 不要在controller中写业务逻辑 - 不要使用已废弃的API - 不要生成没有注释的public方法

这份指令大概300字左右，信息密度足够高，AI助教读完就能对项目有一个清晰的认知。我实测下来，有了这份指令之后，AI助教生成的代码有80%以上可以直接用，不需要大改。

提示：项目指令写完之后，建议先让AI助教复述一遍它理解的内容，看看有没有偏差。如果它复述的内容跟你的预期不一致，说明指令写得还不够清楚，需要调整。

3. 资产库：让AI助教看到项目的全貌

3.1 资产库和项目指令的区别

项目指令告诉AI助教“规矩是什么”，资产库告诉AI助教“东西在哪里”。两者配合使用，才能让AI助教真正做到“目明”。

资产库的核心思路是：把项目中那些AI助教需要反复查阅的内容，提前整理好放在一个固定的位置，让它可以随时读取。这些内容包括但不限于：数据库表结构、API接口文档、核心业务流程图、常用工具类清单、历史决策记录。

没有资产库的时候，AI助教每次需要查表结构都得你手动贴给它，或者它自己去翻代码文件。前者效率低，后者容易翻错。有了资产库之后，这些信息变成“常驻可查”的状态，AI助教需要的时候自己就能找到。

3.2 资产库应该放什么、怎么组织

资产库的组织方式直接决定了AI助教的检索效率。我一般会按照“高频优先、结构清晰、更新及时”三个原则来组织。

高频优先的意思是，把AI助教最常需要查阅的内容放在最前面。根据我的经验，排在前三位的高频资产是：数据库表结构、API接口定义、核心业务规则。这三样东西几乎每次对话都会用到，必须放在最显眼的位置。

结构清晰的意思是，每个资产文件都要有明确的标题和索引。比如数据库表结构可以按模块分文件，用户模块一个文件、订单模块一个文件，每个文件里用表格列出字段名、类型、说明、约束。这样AI助教检索的时候能快速定位。

更新及时的意思是，资产库必须跟代码保持同步。代码改了表结构，资产库也要跟着改。我见过太多团队，资产库建好之后就没人维护了，过了两个月AI助教查到的还是旧信息，反而帮倒忙。

一个典型的资产库目录结构是这样的：

.ai-assets/ ├── database/ │ ├── user_tables.md │ ├── order_tables.md │ └── report_tables.md ├── api/ │ ├── user_api.md │ ├── order_api.md │ └── report_api.md ├── business/ │ ├── user_flow.md │ ├── order_flow.md │ └── report_rules.md └── utils/ ├── common_utils.md └── date_utils.md

每个文件里面用Markdown表格和列表来组织信息，方便AI助教解析。比如数据库表结构的文件可以这样写：

# 用户模块表结构 ## t_user 用户表 | 字段名 | 类型 | 说明 | 约束 | |--------|------|------|------| | id | bigint | 主键 | 自增 | | username | varchar(50) | 用户名 | 唯一，非空 | | password | varchar(100) | 密码 | 非空，BCrypt加密 | | email | varchar(100) | 邮箱 | 唯一 | | status | tinyint | 状态 | 0禁用 1启用 | | create_time | datetime | 创建时间 | 自动填充 | | update_time | datetime | 更新时间 | 自动填充 |

这种结构化的写法，AI助教读起来非常高效，比让它自己去翻SQL文件快得多。

3.3 资产库的维护策略

资产库最大的坑不是建不起来，而是维护不下去。我踩过好几次这个坑，后来总结了一套“半自动维护”的策略，效果还不错。

核心思路是：能自动生成的绝不手动写，必须手动写的定好更新时机。

数据库表结构可以用脚本从数据库中直接导出成Markdown表格，每次数据库变更后跑一次脚本就行。API接口定义可以从Swagger或OpenAPI文档自动转换。这两类资产基本不需要手动维护。

业务规则和历史决策记录这类内容没法自动生成，必须手动写。我的做法是定一个规矩：每次需求评审之后，把新增或变更的业务规则同步到资产库。这个动作纳入开发流程，不做完不算完成任务。刚开始大家会觉得麻烦，但坚持两周之后就习惯了，因为AI助教查得到这些规则，省下来的解释时间远远超过维护成本。

注意：资产库不是越大越好。我见过有人把整个项目的所有代码文件都塞进资产库，结果AI助教检索的时候被大量无关信息干扰，反而找不到重点。资产库应该只放“AI助教需要反复查阅的、结构化的、高信息密度的内容”，代码本身不需要放进去，AI助教可以直接读代码文件。

4. 提示词工程：把“说清楚”变成一门手艺

4.1 为什么提示词在项目配置中如此关键

项目指令和资产库解决的是“AI助教知道什么”的问题，提示词解决的是“AI助教怎么理解你的意图”的问题。三者缺一不可。

很多人觉得提示词就是“把话说清楚”，这没错，但“说清楚”的标准是什么？在项目配置的语境下，提示词的目标是让AI助教在最少交互轮次内产出可直接使用的结果。这跟日常聊天式的提示词完全不是一个概念。

我做过一个对比测试：同一个需求“给用户模块加一个批量导入功能”，用日常提示词写，AI助教平均需要5到7轮对话才能产出可用的代码；用工程化提示词写，平均2到3轮就能搞定。差距主要来自三个方面：需求描述的完整性、约束条件的明确性、输出格式的规范性。

4.2 工程化提示词的四个核心要素

我总结了一套工程化提示词的写法，核心是四个要素：角色设定、任务描述、约束条件、输出格式。

角色设定是告诉AI助教“你现在是谁”。比如“你是一个有五年经验的Java后端工程师，熟悉Spring Boot和MyBatis Plus”。这个设定会影响AI助教的回答风格和技术选型偏好。

任务描述是告诉AI助教“你要做什么”。这部分要具体到输入、处理、输出三个环节。比如“接收一个Excel文件，解析其中的用户数据，校验数据合法性，批量插入数据库，返回导入结果”。

约束条件是告诉AI助教“你不能做什么”和“你必须怎么做”。比如“不要使用EasyExcel以外的第三方库”、“必须使用事务保证批量插入的原子性”、“必须对每行数据做唯一性校验”。

输出格式是告诉AI助教“结果长什么样”。比如“先给出实现思路，再给出完整代码，最后给出单元测试用例”。

把这四个要素组合起来，一个完整的工程化提示词是这样的：

## 角色 你是一个有五年经验的Java后端工程师，熟悉Spring Boot 3.2和MyBatis Plus 3.5。 ## 任务 给用户模块添加批量导入功能。输入是一个Excel文件，包含username、email、status三列。 处理流程：解析Excel -> 校验数据（username和email唯一性、status合法性）-> 批量插入数据库。 输出：导入成功条数、失败条数、失败原因列表。 ## 约束 - 使用EasyExcel解析文件，不要用POI原生API - 使用@Transactional保证原子性 - 每行数据都要校验，校验失败的行跳过并记录原因 - 不要修改现有的UserService接口，新增方法 ## 输出格式 1. 实现思路（200字以内） 2. 完整代码（包含Controller、Service、DTO） 3. 单元测试用例（覆盖正常导入、数据校验失败、文件格式错误三种场景）

这个提示词大概200字，但信息密度极高。AI助教读完就知道要做什么、怎么做、做到什么程度。我实测下来，这种写法的首次响应可用率能达到70%以上。

4.3 提示词模板的沉淀与复用

工程化提示词写多了之后，你会发现很多场景的提示词结构是相似的。比如“新增接口”、“修改逻辑”、“排查bug”、“重构代码”这四类场景，每类都可以沉淀出一个模板。

我的做法是在项目里建一个.ai-prompts/目录，把常用的提示词模板存进去。每次遇到对应场景，直接调模板改几个参数就行，不需要从头写。

比如“新增接口”的模板可以这样写：

## 角色 你是一个有五年经验的Java后端工程师，熟悉Spring Boot 3.2和MyBatis Plus 3.5。 ## 任务 在[模块名]模块中新增[接口名]接口。 - 请求方式：[GET/POST/PUT/DELETE] - 请求路径：/api/[模块名]/[接口名] - 请求参数：[参数列表] - 业务逻辑：[简要描述] - 返回值：[返回值描述] ## 约束 - 遵循项目指令中的代码规范 - 参考资产库中的[相关表结构]和[相关接口定义] - 不要修改现有接口的签名 ## 输出格式 1. Controller方法 2. Service方法 3. 必要的DTO和VO 4. 单元测试

这个模板用起来非常顺手，改几个参数就能适配不同的接口需求。我团队里现在每个人都有自己的模板库，互相之间还会交换好用的模板。

提示：提示词模板不是一成不变的。每次用完觉得效果不好，就顺手改一改，下次再用。积累一两个月之后，你的模板库会变成非常宝贵的资产。

5. 上下文管理：让AI助教记住该记住的

5.1 上下文窗口的分配策略

AI助教的上下文窗口是有限的，怎么分配这些窗口，直接决定了它的“耳聪目明”程度。我一般把上下文分成四个优先级：

第一优先级是项目指令。这是每次对话都必须加载的，占用窗口的10%到15%。

第二优先级是当前任务相关的资产。比如你在改用户模块的代码，就加载用户模块的表结构和接口定义。这部分占用窗口的20%到30%。

第三优先级是当前对话的历史。包括你之前说了什么、AI助教回了什么、你做了哪些修改。这部分占用窗口的30%到40%。

第四优先级是参考代码。如果任务需要参考项目中的其他代码，就把相关文件加载进来。这部分占用窗口的15%到20%。

这个分配不是固定的，要根据任务复杂度动态调整。任务越复杂，第三和第四优先级的占比越高；任务越简单，第一和第二优先级的占比越高。

5.2 什么时候该开新对话

这是很多人忽略的一个点。AI助教的对话历史越长，上下文窗口被占满的风险越大，响应质量也会下降。我一般遵循三个原则来判断什么时候该开新对话：

原则一：任务切换时开新对话。你刚改完用户模块，现在要改订单模块，这两个任务之间没有直接关联，开新对话可以让AI助教重新加载订单模块的资产，避免被用户模块的信息干扰。

原则二：对话超过20轮时开新对话。20轮之后，历史信息占用的窗口已经很大了，继续下去会影响响应质量。如果任务还没完成，可以把关键结论整理一下，带到新对话里继续。

原则三：AI助教开始“胡言乱语”时开新对话。如果你发现AI助教开始重复之前说过的话、或者给出明显不相关的回答，说明上下文已经混乱了，赶紧开新对话。

5.3 跨对话的信息传递技巧

开新对话之后，怎么把之前的关键信息带过去？我的做法是维护一个“任务状态文件”，每次开新对话之前，把当前任务的进展、已完成的步骤、待解决的问题写进去，然后在新对话开始时把这个文件贴给AI助教。

这个文件不需要很正式，用简单的列表就行：

# 任务状态 ## 当前任务 给用户模块添加批量导入功能 ## 已完成 - 数据库表结构已确认（见资产库user_tables.md） - Controller方法已写完 - Service方法写了一半 ## 待完成 - Service方法的数据校验逻辑 - 单元测试 ## 关键决策 - 使用EasyExcel而不是POI - 校验失败的行跳过并记录原因，不中断整个导入

这个文件大概100字，但能让AI助教在3秒内恢复到之前的工作状态。我实测下来，有了这个文件之后，跨对话的上下文丢失问题基本解决了。

6. 配置落地：从零搭建一套AI助教工作环境

6.1 目录结构的完整规划

把前面说的东西串起来，一个完整的AI助教工作环境目录结构是这样的：

project-root/ ├── .ai-instructions.md # 项目指令 ├── .ai-assets/ # 资产库 │ ├── database/ │ ├── api/ │ ├── business/ │ └── utils/ ├── .ai-prompts/ # 提示词模板 │ ├── new-api.md │ ├── fix-bug.md │ ├── refactor.md │ └── review.md ├── .ai-state/ # 任务状态 │ └── current-task.md └── src/ # 项目源码

这个结构的好处是：所有AI助教相关的内容都集中在以.ai-开头的目录和文件中，跟项目源码完全分离。既不会干扰正常的开发流程，又方便AI助教快速定位。

6.2 配置生效的验证方法

配置建好之后，怎么验证它是否生效？我一般用三个测试来验证：

测试一：项目指令测试。问AI助教“这个项目的代码规范是什么”，看它能不能准确复述项目指令中的内容。如果它答不上来或者答错了，说明项目指令没有被正确加载。

测试二：资产库测试。问AI助教“用户表的email字段有什么约束”，看它能不能从资产库中找到答案。如果它说“我不知道”或者给出错误答案，说明资产库没有被正确索引。

测试三：提示词测试。用提示词模板发起一个任务，看AI助教的响应是否符合模板中定义的输出格式。如果它没有按照格式输出，说明提示词模板没有被正确识别。

这三个测试都通过之后，基本可以确认配置生效了。我建议每次修改配置之后都跑一遍这三个测试，确保没有引入新的问题。

6.3 团队协作中的配置同步

如果是团队使用，配置同步是一个必须解决的问题。我的做法是把.ai-开头的目录和文件全部纳入Git管理，跟代码一起提交、一起合并。

这样做的好处是：每个人用的都是同一套配置，AI助教的行为在团队内部保持一致。新人入职的时候，拉下代码就自动获得了完整的AI助教配置，不需要额外设置。

需要注意的是，.ai-state/current-task.md这个文件是个人状态，不应该提交到Git。我一般把它加到.gitignore里，每个人维护自己的任务状态。

提示：如果团队里有人用不同的AI助教工具，配置文件的格式可能需要调整。我的经验是尽量用Markdown格式写配置，因为几乎所有AI助教工具都能解析Markdown，通用性最好。

7. 实测中遇到的几个典型问题

7.1 项目指令太长导致响应变慢

我一开始写项目指令的时候，恨不得把所有细节都写进去，结果写了2000多字。实测发现，AI助教的响应速度明显变慢，而且有时候会“抓错重点”——你问它A问题，它扯到B问题上去了。

后来我把项目指令精简到500字以内，只保留最核心的信息，响应速度恢复正常，准确率也上去了。这个经验告诉我：项目指令的信息密度比信息总量更重要。与其写2000字的详细说明，不如写500字的高密度指令，把细节放到资产库里按需加载。

7.2 资产库更新不及时导致AI助教“记错事”

有一次我们改了用户表的结构，加了一个nickname字段，但忘了更新资产库。结果AI助教在生成代码的时候，一直用旧的表结构，生成的SQL里没有nickname字段，跑起来就报错。

这个问题的根因是资产库更新没有纳入开发流程。后来我们定了一个规矩：任何数据库变更，必须同步更新资产库，否则代码不允许合并。这个规矩执行了两周之后，就再也没出现过类似问题。

7.3 提示词模板“水土不服”

我从网上抄了一个提示词模板，用在项目里发现效果很差。后来分析原因，发现那个模板是针对Python项目的，而我们用的是Java，技术栈完全不匹配。

这个经验告诉我：提示词模板必须针对自己的项目定制。网上的模板可以参考结构，但具体内容必须结合项目的技术栈、代码规范、业务特点来写。直接抄过来的模板，大概率不好用。

7.4 上下文窗口被“无关信息”占满

有一次我在一个对话里连续改了五个模块的代码，到第六个模块的时候，AI助教开始胡言乱语了。我检查了一下，发现上下文窗口已经被前五个模块的信息占满了，AI助教已经“记不清”当前在做什么了。

后来我养成了一个习惯：每完成一个模块的任务，就开一个新对话。如果任务确实需要跨模块，就把关键信息整理到任务状态文件里带过去。这个习惯让我的AI助教使用体验稳定了很多。

8. 配置之外的几个实用心得

8.1 让AI助教先“复述”再“执行”

这是一个非常实用的小技巧。每次给AI助教布置任务之前，先让它复述一遍它理解的任务内容。如果复述的内容跟你的预期一致，再让它执行；如果不一致，先纠正理解，再执行。

这个技巧看起来多了一步，但实际上省了很多时间。我实测下来，加了“复述”这一步之后，返工率降低了60%以上。因为很多问题其实不是AI助教能力不够，而是它理解错了你的意图。提前发现理解偏差，比事后返工划算得多。

8.2 用“对比示例”代替“抽象描述”

如果你想让AI助教按照某种风格写代码，不要用抽象的描述（“请写出优雅的代码”），而是给它两个对比示例：一个是你想要的风格，一个是你不要的风格。AI助教通过对比就能准确理解你的偏好。

比如你想让AI助教写注释，可以给它看两个例子：

// 不好的注释：获取用户 public User getUser(Long id) { ... } // 好的注释：根据用户ID查询用户信息，如果用户不存在则抛出BusinessException public User getUser(Long id) { ... }

这种对比示例比任何抽象描述都有效。我现在的项目指令里，每个规范都配了一个正例和一个反例，AI助教的理解准确率明显提升。

8.3 定期“体检”AI助教的配置

配置不是建好就一劳永逸的。项目在演进，代码在变化，AI助教的配置也需要定期更新。我一般每个月做一次“配置体检”，检查三件事：

第一，项目指令中的技术栈版本是否跟实际一致。第二，资产库中的表结构和接口定义是否跟代码同步。第三，提示词模板是否还适用于当前的项目场景。

这个体检大概花半个小时，但能避免很多因为配置过期导致的问题。我建议把它纳入团队的月度技术债务清理计划，定期执行。

8.4 不要追求“一次配置到位”

我见过很多人，想一次性把AI助教的配置做到完美，结果花了大量时间在配置上，实际使用的时间反而少了。我的建议是：先配一个最小可用版本，然后在使用中逐步迭代。

最小可用版本只需要三样东西：一份200字左右的项目指令、一个包含核心表结构的资产库文件、一个常用的提示词模板。这三样东西花半个小时就能搞定，然后就可以开始用了。用的过程中发现哪里不够好，就改哪里。这样迭代一两个月，配置自然就完善了。

8.5 记录“AI助教犯错”的案例

这是一个我觉得非常有价值的习惯。每次AI助教犯错，我都把错误案例记录下来：什么场景、什么提示词、什么错误结果、怎么修正的。积累一段时间之后，这些案例变成了优化配置的最佳素材。

比如我发现AI助教经常在生成MyBatis Plus的查询条件时用错API，我就把这个案例记下来，然后在项目指令里加了一条“使用LambdaQueryWrapper时，条件方法必须用Lambda表达式”。加了这条之后，同类错误就再也没出现过。

这个习惯的本质是：把AI助教的错误转化为配置的改进。错误不可怕，可怕的是同样的错误反复出现。有了错误案例库，配置就能持续进化，AI助教也会越来越“耳聪目明”。

9. 一个完整的配置示例

最后，我把前面说的所有东西串起来，给一个完整的配置示例。假设我们有一个Spring Boot项目，目录结构如下：

my-project/ ├── .ai-instructions.md ├── .ai-assets/ │ ├── database/ │ │ └── user_tables.md │ └── api/ │ └── user_api.md ├── .ai-prompts/ │ └── new-api.md ├── .ai-state/ │ └── current-task.md └── src/

.ai-instructions.md的内容：

# 项目指令 ## 项目概述 企业级后台管理系统，包含用户、订单、报表三大模块。 技术栈：Spring Boot 3.2 + MyBatis Plus 3.5 + Redis 7.0 + MySQL 8.0 ## 目录结构 - controller/：接收请求，参数校验 - service/：业务逻辑，事务控制 - mapper/：数据库操作 - entity/：数据库实体 - dto/：数据传输对象 - config/：配置类 ## 代码规范 - 类名大驼峰，方法名小驼峰 - public方法必须有Javadoc - 统一使用Result<T>包装返回值 - 异常统一抛BusinessException - 日志使用@Slf4j ## 禁止事项 - 不要修改pom.xml依赖版本 - 不要在controller中写业务逻辑 - 不要使用已废弃的API

.ai-assets/database/user_tables.md的内容：

# 用户模块表结构 ## t_user 用户表 | 字段名 | 类型 | 说明 | 约束 | |--------|------|------|------| | id | bigint | 主键 | 自增 | | username | varchar(50) | 用户名 | 唯一，非空 | | password | varchar(100) | 密码 | 非空，BCrypt加密 | | email | varchar(100) | 邮箱 | 唯一 | | nickname | varchar(50) | 昵称 | 可空 | | status | tinyint | 状态 | 0禁用 1启用 | | create_time | datetime | 创建时间 | 自动填充 | | update_time | datetime | 更新时间 | 自动填充 |

.ai-prompts/new-api.md的内容：

## 角色 你是一个有五年经验的Java后端工程师，熟悉Spring Boot 3.2和MyBatis Plus 3.5。 ## 任务 在[模块名]模块中新增[接口名]接口。 - 请求方式：[GET/POST/PUT/DELETE] - 请求路径：/api/[模块名]/[接口名] - 请求参数：[参数列表] - 业务逻辑：[简要描述] - 返回值：[返回值描述] ## 约束 - 遵循项目指令中的代码规范 - 参考资产库中的相关表结构和接口定义 - 不要修改现有接口的签名 ## 输出格式 1. Controller方法 2. Service方法 3. 必要的DTO和VO 4. 单元测试

.ai-state/current-task.md的内容：

# 任务状态 ## 当前任务 给用户模块添加批量导入功能 ## 已完成 - 数据库表结构已确认 - Controller方法已写完 ## 待完成 - Service方法的数据校验逻辑 - 单元测试 ## 关键决策 - 使用EasyExcel而不是POI - 校验失败的行跳过并记录原因

这套配置大概500字，搭建时间不超过半小时，但能让AI助教的首次响应可用率从40%提升到80%以上。我团队里现在每个人都在用这套配置，反馈都很好。

配置这件事，说到底就是一句话：你给AI助教的信息越结构化、越精准、越及时，它就越“耳聪目明”。模型的能力是固定的，但配置的质量是可以不断提升的。把配置做好，比换更贵的模型划算得多。