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注释 - 统一使用ResultT包装返回值 - 异常统一抛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 - 统一使用ResultT包装返回值 - 异常统一抛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助教的信息越结构化、越精准、越及时它就越“耳聪目明”。模型的能力是固定的但配置的质量是可以不断提升的。把配置做好比换更贵的模型划算得多。