1. 为什么你的AI助教总是“答非所问”

很多人第一次把AI助教接进项目里，满心欢喜地以为终于可以解放双手了，结果用了不到三天就发现——这玩意儿怎么跟个刚入职的实习生一样，问东它答西，让它改个bug它给你重写整个模块，让它解释代码它给你背八股文。问题出在哪？十有八九不是模型不行，而是你压根没给它配好“工作环境”。

我见过太多团队的做法：把AI助教往项目根目录一扔，最多写一句“你是一个编程助手”，然后就指望它无所不能。这就好比你招了个新人，不给他看项目文档、不告诉他代码规范、不跟他说清楚业务背景，直接让他上手改核心逻辑，不出事才怪。AI助教也是一样的道理，它的“耳聪目明”不取决于模型本身有多强，而取决于你给它配置了多少有效上下文。

所谓“耳聪”，是指它能准确理解你的意图，听得懂你在说什么；所谓“目明”，是指它能看清项目的全貌，知道代码结构、依赖关系、业务逻辑。这两件事都不是靠一句简单的系统提示词能解决的，需要一套完整的项目配置方案。这套方案的核心包括四个部分：项目指令（Project Instructions）、资产库（Asset Library）、提示词工程（Prompt Engineering）和上下文管理（Context Management）。

这篇文章就是把我自己在多个项目中反复踩坑、反复调优之后总结出来的一套配置方法论完整拆开来讲。不管你是用Cursor、Windsurf、GitHub Copilot Workspace还是自己搭的AI助教系统，这套思路都能直接套用。适合已经上手过AI编程工具、但总觉得“差那么点意思”的开发者，也适合刚开始接触AI辅助开发、想少走弯路的新手。

2. 项目配置的底层逻辑：给AI造一个“工作台”

2.1 AI助教的认知模型：它到底能看到什么

要搞清楚怎么配置项目，首先得明白AI助教在每一次对话中到底能“看到”什么。很多人以为AI能自动读取整个项目的所有文件，其实不是的。绝大多数AI编程工具的工作机制是这样的：每次你发起一个请求，系统会把系统提示词 + 项目指令 + 当前打开的文件内容 + 你选中的代码片段 + 你的问题打包成一个上下文窗口，发给大模型。模型只能基于这个窗口里的信息来回答。

这意味着什么？意味着如果你不主动配置项目指令，AI每次看到的就只有你当前打开的那一个文件。它不知道你的项目用了什么框架、遵循什么代码规范、有哪些全局配置、模块之间怎么调用的。它就像一个只看了半页图纸就开始施工的工人，能不出问题吗？

我拿一个实际场景举例。假设你的项目是一个Spring Boot后端，前端用Vue 3，数据库用PostgreSQL，代码规范要求所有接口返回值必须用统一的Result<T>包装。如果你不告诉AI这些信息，它给你生成的Controller代码很可能是直接返回实体对象，或者用Map<String, Object>拼返回值。你每次都得手动改，改完还得跟AI解释“我们项目不是这么写的”。但如果你在项目指令里把这些规则写清楚，AI第一次就能生成符合规范的代码。

2.2 项目指令、资产库、提示词三者的关系

很多人把这三个概念搞混，觉得写一个详细的系统提示词就够了。其实它们各司其职，缺一不可。

项目指令是“宪法”，是长期有效的全局规则。它定义了AI在这个项目中必须遵守的基本法：技术栈是什么、代码风格是什么、目录结构怎么组织、哪些操作是禁止的。项目指令通常写一次就不怎么改了，除非项目发生重大架构调整。

资产库是“参考资料”，是项目相关的知识沉淀。它包括API文档、数据库表结构说明、业务术语表、常见问题FAQ、历史决策记录等。资产库的内容会随着项目迭代不断更新，AI在需要的时候可以检索这些资料来辅助回答。

提示词是“战术指令”，是每次对话时你给AI的具体任务描述。提示词的质量直接决定了AI这一次回答的质量。好的提示词应该包含：任务目标、输入信息、输出格式要求、约束条件、示例参考。

三者之间的关系可以这样理解：项目指令告诉AI“你是谁、在什么环境里工作”，资产库告诉AI“遇到不懂的可以查这些资料”，提示词告诉AI“现在具体要做什么”。只有三者配合好了，AI助教才能真正做到耳聪目明。

2.3 配置方案选型：为什么我推荐“分层配置”策略

市面上配置AI助教的方式五花八门，有把所有规则塞进一个巨大系统提示词的，有靠.cursorrules文件搞定的，也有用RAG（检索增强生成）方案动态注入上下文的。我试过很多种，最后总结出一套“分层配置”策略，是目前我觉得最稳定、最好维护的方案。

分层配置的核心思想是：把不同稳定性的信息放在不同的层里，用不同的更新频率来管理。具体来说分四层：

这样分层的好处是：改代码规范不用动资产库，加新API文档不用改项目指令，每次对话只需要关注第四层的即时信息。维护成本低，而且不容易出现“改了A影响了B”的情况。

3. 项目指令配置实战：把规矩立在前面

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

项目指令是AI助教的行为准则，写得好不好直接决定了AI的“基本素质”。我一般会把项目指令分成六个模块来写：

第一块：角色定义。告诉AI它在这个项目中扮演什么角色。不要只写“你是一个编程助手”，太笼统了。要具体到技术栈和职责范围。比如：“你是一个资深Java后端开发工程师，专注于Spring Boot微服务开发，熟悉MyBatis-Plus、Redis、RabbitMQ等常用组件。”

第二块：技术栈声明。把项目用到的所有关键技术栈列清楚，包括版本号。这一步非常关键，因为不同版本的API差异很大。比如Spring Boot 2.x和3.x的很多写法就不一样，如果你不告诉AI版本，它可能给你生成过时的代码。

第三块：代码规范。包括命名规范、注释规范、异常处理规范、日志规范等。这部分要写得具体，不要写“遵循阿里巴巴Java开发手册”就完了，AI不一定记得住手册里的每一条。要把最常用的规则直接写出来。

第四块：目录结构说明。告诉AI项目的目录是怎么组织的，哪个包放Controller，哪个包放Service，哪个包放工具类。这样AI在生成代码时就知道该把文件放在哪里。

第五块：禁止事项。明确列出AI不能做的事情。比如“禁止使用System.out.println输出日志”、“禁止在Controller层写业务逻辑”、“禁止直接操作数据库连接”等。

第六块：输出格式要求。告诉AI回答时应该遵循什么格式。比如“代码块必须标注语言类型”、“修改代码时先说明修改原因再给出代码”、“涉及多个文件修改时按文件路径分组展示”。

3.2 一份可直接抄作业的项目指令模板

下面这份模板是我在一个Spring Boot + Vue项目中实际使用的，你可以根据自己的项目情况调整。我把它放在项目根目录的.ai-instructions.md文件里，大多数AI编程工具都支持读取这个文件。

# 项目AI助手指令 ## 角色定义 你是一个资深全栈开发工程师，后端精通Java 17 + Spring Boot 3.2 + MyBatis-Plus， 前端精通Vue 3 + TypeScript + Element Plus，数据库使用PostgreSQL 15。 ## 技术栈 - 后端框架：Spring Boot 3.2.x - ORM框架：MyBatis-Plus 3.5.x - 数据库：PostgreSQL 15 - 缓存：Redis 7.x - 消息队列：RabbitMQ 3.12 - 前端框架：Vue 3.4 + TypeScript 5.3 - UI组件库：Element Plus 2.6 - 构建工具：Maven 3.9（后端）、Vite 5（前端） ## 代码规范 1. 所有Controller方法必须返回`Result<T>`类型 2. Service层接口以`I`开头，实现类以`ServiceImpl`结尾 3. 实体类使用Lombok注解，禁止手写getter/setter 4. 所有数据库操作必须通过MyBatis-Plus的Wrapper构建 5. 日志使用`@Slf4j`注解，禁止使用`System.out.println` 6. 异常统一由`GlobalExceptionHandler`处理，业务代码中禁止try-catch后吞掉异常 7. 所有接口必须添加Swagger注解（`@Operation`、`@Parameter`） ## 目录结构 - `src/main/java/com/example/project/controller/` - 控制器层 - `src/main/java/com/example/project/service/` - 服务层接口 - `src/main/java/com/example/project/service/impl/` - 服务层实现 - `src/main/java/com/example/project/mapper/` - 数据访问层 - `src/main/java/com/example/project/entity/` - 实体类 - `src/main/java/com/example/project/dto/` - 数据传输对象 - `src/main/java/com/example/project/config/` - 配置类 - `src/main/java/com/example/project/common/` - 公共工具类 ## 禁止事项 - 禁止在Controller中直接调用Mapper - 禁止使用`SELECT *`查询 - 禁止在循环中调用数据库查询 - 禁止硬编码敏感信息（密码、密钥等） - 禁止使用已废弃的API ## 输出格式 - 代码块必须标注语言类型 - 修改代码时先说明修改原因，再给出完整代码 - 涉及多个文件时按文件路径分组展示 - 回答使用中文，技术术语保留英文原文

这份指令看起来有点长，但实际效果非常好。配置之后，AI生成的代码基本不需要怎么改就能直接用，省去了大量来回沟通的时间。

3.3 项目指令的维护心得

项目指令不是写一次就完事了，需要持续维护。我的经验是：每次发现AI犯了一个重复性的错误，就把对应的规则补进项目指令里。比如你发现AI总是忘记给接口加Swagger注解，那就在代码规范里加一条“所有接口必须添加Swagger注解”。下次它就不会忘了。

但要注意，项目指令不能无限膨胀。如果发现指令文件超过500行，就要考虑把一些不那么关键的内容移到资产库里，保持项目指令的精简和核心。我一般控制在300行以内，确保每一条规则都是高频使用的。

还有一个技巧：给规则加优先级标记。比如用[必须]、[建议]、[可选]来区分规则的强制程度。这样AI在遇到规则冲突时，知道该优先遵守哪一条。

4. 资产库搭建：让AI有据可查

4.1 资产库应该放什么

资产库是AI助教的“知识库”，它解决的是“AI不知道项目背景”的问题。我一般会把以下几类内容放进资产库：

API文档。包括接口路径、请求参数、响应格式、错误码说明。这部分可以直接从Swagger导出，或者手写Markdown文档。AI在生成前端调用代码或者写接口测试时，会参考这些文档。

数据库表结构说明。包括表名、字段名、字段类型、索引信息、表之间的关系。AI在写SQL或者设计实体类时，需要这些信息来保证字段名和类型正确。

业务术语表。每个项目都有自己的“黑话”，比如“工单”、“结算单”、“对账单”这些词在不同项目里含义可能不同。把业务术语的定义写清楚，AI才能理解你的需求。

常见问题FAQ。把团队经常遇到的问题和解决方案整理成FAQ，AI在遇到类似问题时可以直接参考，不用每次都重新推理。

历史决策记录。记录项目中的重大技术决策及其原因。比如“为什么选择RabbitMQ而不是Kafka”、“为什么用户表要分库分表”。这些背景信息能帮助AI在给出建议时考虑历史约束。

4.2 资产库的组织方式

资产库的组织方式直接影响AI的检索效率。我推荐用目录 + 索引文件的方式：

docs/ ├── INDEX.md # 资产库索引，列出所有文档及其用途 ├── api/ │ ├── user-api.md # 用户模块接口文档 │ ├── order-api.md # 订单模块接口文档 │ └── ... ├── database/ │ ├── schema.md # 数据库表结构总览 │ └── er-diagram.md # ER图说明 ├── glossary.md # 业务术语表 ├── faq.md # 常见问题 └── decisions/ ├── 001-mq-selection.md └── 002-sharding-strategy.md

INDEX.md是关键，它相当于资产库的“目录页”。AI在需要查找资料时，先读INDEX.md了解有哪些文档可用，然后再去读具体文档。这样比让AI遍历整个docs/目录效率高得多。

4.3 资产库的更新与维护

资产库最大的问题是容易“过期”。代码改了但文档没更新，AI参考了过期的文档，反而会给出错误的建议。我的做法是：

第一，把资产库更新纳入开发流程。每次修改接口或数据库表结构时，必须同步更新对应的文档。可以在CI流程里加一个检查，如果代码变更涉及API但文档没更新，就发出警告。

第二，定期做资产库审查。每个迭代结束时花半小时过一遍资产库，把过期的内容删掉或更新。我一般会在每个Sprint的最后一天做这件事。

第三，给文档加版本标记。在每份文档的开头标注最后更新时间和对应的代码版本。AI在参考文档时，如果发现版本不匹配，会提醒你确认。

注意：资产库不是越大越好。我见过有人把整个项目的所有文件都塞进资产库，结果AI检索时反而找不到重点。资产库应该只放“AI需要知道但代码里看不出来”的信息，代码本身能表达的内容不需要重复放进去。

5. 提示词工程：把话说清楚的艺术

5.1 好提示词的五个要素

提示词是你和AI助教之间的“接口”，接口设计得好不好，直接决定了通信质量。我总结了一个好提示词应该包含的五个要素：

要素一：角色设定。告诉AI这次对话它应该以什么身份来回答。比如“你是一个代码审查专家”、“你是一个性能优化顾问”。角色设定会影响AI的回答风格和关注点。

要素二：任务描述。清晰说明你要AI做什么。不要只说“帮我看看这段代码”，要说“帮我审查这段代码，重点检查空指针异常、SQL注入风险和性能问题”。

要素三：上下文信息。提供AI完成任务所需的背景信息。比如相关的代码片段、报错信息、业务需求描述。上下文越充分，AI的回答越准确。

要素四：输出格式。明确告诉AI你希望它以什么格式输出。比如“用表格列出所有问题”、“按严重程度排序”、“每个问题给出修复代码”。

要素五：约束条件。告诉AI有哪些限制。比如“不要修改方法签名”、“保持现有代码风格”、“只修改我选中的代码块”。

5.2 常见任务的提示词模板

我把日常开发中高频使用的提示词整理成了模板，用的时候直接填空就行。下面挑几个最常用的分享出来。

代码审查模板：

角色：你是一个严格的代码审查员，专注于Java后端代码质量。 任务：审查以下代码，找出所有潜在问题。 上下文：这是Spring Boot项目中的一个Service方法，使用MyBatis-Plus操作数据库。 输出格式： 1. 按严重程度（高/中/低）分类列出问题 2. 每个问题说明原因和可能导致的后果 3. 给出修复后的代码 约束：不要修改方法签名，保持现有代码风格。 代码： [粘贴代码]

Bug排查模板：

角色：你是一个经验丰富的调试专家。 任务：帮我定位以下报错的根本原因并给出修复方案。 上下文： - 项目技术栈：Spring Boot 3.2 + MyBatis-Plus + PostgreSQL - 触发场景：调用用户查询接口时 - 报错信息：[粘贴完整堆栈] - 相关代码：[粘贴相关代码] 输出格式： 1. 根本原因分析 2. 修复方案（附代码） 3. 预防措施 约束：优先考虑最小改动方案。

新功能开发模板：

角色：你是一个资深全栈开发工程师。 任务：实现一个[功能描述]的功能。 上下文： - 参考现有[类似功能]的实现方式 - 数据库表结构：[粘贴相关表结构] - 接口规范：遵循项目统一的Result<T>返回格式 输出格式： 1. 实现思路简述 2. 完整代码（按文件路径分组） 3. 需要注意的边界情况 约束：遵循项目代码规范，使用现有的工具类和常量。

5.3 提示词设计的进阶技巧

掌握了基础模板之后，可以试试这几个进阶技巧，能让AI的回答质量再上一个台阶。

技巧一：分步引导。对于复杂任务，不要一次性把所有要求都抛给AI，而是分步骤引导。比如先让AI分析需求，确认理解正确后再让它设计方案，方案确认后再让它写代码。这样每一步都可控，不容易跑偏。

技巧二：提供示例。如果你希望AI按照某种特定格式输出，最好的方式是给它一个示例。比如“请按照以下格式输出：[示例]”。AI的模仿能力很强，给了示例之后输出格式基本不会跑偏。

技巧三：反向约束。除了告诉AI“要做什么”，还要告诉它“不要做什么”。比如“不要使用Lambda表达式”、“不要引入新的依赖”、“不要修改配置文件”。反向约束能有效防止AI“过度发挥”。

技巧四：角色切换。同一个问题可以让AI用不同角色回答两遍。比如先让它以“开发者”身份给出实现方案，再让它以“审查者”身份挑毛病。两轮下来，方案的质量会明显提升。

实操心得：提示词写完之后，先自己读一遍，看看有没有歧义。如果你自己都觉得“这句话好像有两种理解”，那AI大概率也会理解错。把歧义消除掉，比事后反复纠正要省事得多。

6. 上下文管理：让AI记住该记住的

6.1 上下文窗口的分配策略

AI的上下文窗口是有限的，怎么分配这些“注意力资源”很有讲究。我的经验是遵循**“三三制”原则**：

• 三分之一给项目指令和资产库索引：保证AI知道基本规则和有哪些资料可查
• 三分之一给当前任务相关的代码和文档：保证AI有足够的信息完成任务
• 三分之一留给对话历史：保证AI记得之前聊了什么

但实际使用中，对话历史往往是最容易被忽略的。很多人聊了十几轮之后，AI已经忘了最开始的需求是什么。解决办法是定期做上下文压缩：每聊5-6轮，就让AI总结一下当前的任务目标和已确认的结论，把总结作为新的上下文起点。

6.2 什么时候该开新对话

这是一个很实际的问题。很多人习惯在一个对话里聊到底，结果上下文越来越长，AI的回答质量越来越差。我的建议是，遇到以下情况就开新对话：

• 任务类型发生切换时（比如从“写代码”切换到“排查bug”）
• 对话轮次超过15轮时
• AI开始出现“遗忘”现象时（比如重复问已经回答过的问题）
• 切换到不同的功能模块时

开新对话之前，把上一个对话的关键结论复制出来，作为新对话的初始上下文。这样既保持了信息的连续性，又避免了上下文过载。

6.3 用文件引用代替内容粘贴

很多AI编程工具支持用@文件名的方式引用项目文件，而不是把文件内容粘贴到对话里。这种方式的好处是：AI可以直接读取文件的最新内容，不需要你手动同步；而且文件引用占用的上下文空间比粘贴全文要小。

我一般会这样组织一次对话的上下文：

参考文件： @src/main/java/com/example/controller/UserController.java @src/main/java/com/example/service/impl/UserServiceImpl.java @docs/api/user-api.md 任务：根据API文档，检查UserController和UserServiceImpl的实现是否一致，找出所有不一致的地方。

这样AI会自动读取这三个文件的内容，然后基于这些内容来回答。比手动粘贴代码要高效得多。

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

7.1 AI不遵守项目指令怎么办

这是最常见的问题。你明明在项目指令里写了“所有接口必须返回Result ”，但AI还是给你返回了实体对象。原因通常有三个：

原因一：指令文件没有被正确加载。不同的AI工具读取项目指令的方式不同。有的读.cursorrules，有的读.ai-instructions.md，有的需要在设置里手动指定。先确认你的工具到底读哪个文件。

原因二：指令被更高级别的提示词覆盖了。有些工具的系统提示词优先级高于项目指令。这种情况下，你需要在对话中再次强调项目规范，或者把关键规则写进对话的提示词里。

原因三：指令写得太模糊。“遵循项目规范”这种话AI理解不了，它需要具体的、可执行的规则。把“遵循项目规范”改成“所有Controller方法必须返回Result 类型”，效果立竿见影。

7.2 AI生成的代码总是差那么点意思

有时候AI生成的代码逻辑是对的，但就是不符合你的预期。比如变量命名风格不对、注释太多或太少、异常处理方式不一样。这通常是因为项目指令里的代码规范写得不够具体。

解决办法是给正反示例。在项目指令里加一段：

正确示例： public Result<UserVO> getUserById(@PathVariable Long id) { UserVO user = userService.getById(id); return Result.success(user); } 错误示例： public User getUserById(Long id) { return userService.getById(id); }

有了具体示例，AI的模仿准确率会大幅提升。

7.3 资产库检索不准确

资产库内容多了之后，AI可能检索到不相关的文档。解决办法是优化INDEX.md，给每份文档加上更详细的关键词描述。比如不要只写“用户API文档”，要写“用户API文档：包含用户注册、登录、信息查询、信息修改、密码重置等接口的请求参数和响应格式”。

另外，可以在对话中直接指定要参考的文档，而不是让AI自己去检索。比如“请参考docs/api/user-api.md中的接口定义来生成前端调用代码”。这样最准确。

7.4 常见问题速查表

7.5 几个我踩过的坑

坑一：项目指令写太长。一开始我觉得写得越详细越好，结果写了800多行，AI反而抓不住重点。后来精简到200行左右，效果反而更好。项目指令要的是精准，不是全面。

坑二：资产库不更新。有次接口改了但文档没改，AI根据旧文档生成了错误的调用代码，排查了半天才发现是文档过期了。从那以后我就把文档更新纳入了代码审查清单。

坑三：所有任务用同一个提示词模板。不同任务需要不同的提示词结构。代码审查需要严格挑错，新功能开发需要创造性，Bug排查需要逻辑推理。用同一个模板效果会打折扣。

坑四：忽略对话历史的管理。有一次在一个对话里聊了30多轮，AI开始胡言乱语，把之前确认过的方案又推翻了。后来我养成了每10轮左右就总结一次的习惯，再也没有出现过这种情况。

8. 不同AI编程工具的配置差异

8.1 Cursor的配置要点

Cursor是目前最流行的AI编程工具之一，它的配置方式主要是通过.cursorrules文件。这个文件放在项目根目录，Cursor会自动读取。我一般会把项目指令的核心内容写进去，控制在300行以内。

Cursor还有一个很好用的功能是@引用，可以在对话中引用文件、文件夹、甚至整个代码库。我经常用@Codebase来让Cursor搜索整个项目，找到相关的代码片段。

另外Cursor的.cursorignore文件也很重要，用来排除不需要AI索引的文件（比如node_modules、dist、.git等）。配置好了能显著提升AI的响应速度。

8.2 GitHub Copilot的配置要点

GitHub Copilot的配置方式不太一样，它主要通过VS Code的设置和.github/copilot-instructions.md文件来配置。这个文件放在.github目录下，Copilot会自动读取。

Copilot的优势是代码补全非常流畅，但在对话式交互方面不如Cursor灵活。我的做法是用Copilot做日常的代码补全，用Cursor做复杂的重构和调试。

8.3 自建AI助教的配置要点

如果你是自己搭的AI助教系统（比如用OpenAI API + LangChain），那配置的灵活度就更高了。你可以完全控制上下文的组装方式、资产库的检索策略、提示词的模板管理。

我的建议是：把项目指令和资产库索引作为系统提示词的一部分固定注入，把资产库内容用RAG的方式动态检索，把对话历史做滑动窗口压缩。这样既能保证AI始终知道项目的基本规则，又能根据当前任务动态加载相关知识。

9. 配置效果的验证与持续优化

9.1 怎么判断配置是否有效

配置完了之后，怎么知道有没有效果？我一般用三个指标来衡量：

指标一：首次回答准确率。统计AI第一次回答就基本符合要求的比例。配置好的话，这个比例应该在70%以上。如果低于50%，说明项目指令或提示词还有优化空间。

指标二：返工次数。统计每个任务平均需要几轮对话才能完成。配置好的话，简单任务1-2轮，复杂任务3-5轮。如果超过10轮，说明上下文管理有问题。

指标三：重复错误率。统计同类错误重复出现的频率。如果同一个错误出现了三次以上，说明对应的规则没有沉淀到项目指令里。

9.2 持续优化的方法

配置不是一次性的工作，需要持续迭代。我的做法是每周花半小时做一次“配置回顾”：

• 回顾本周AI犯过的错误，把重复性的问题提炼成规则补进项目指令
• 检查资产库是否有过期内容，及时更新
• 整理本周用得顺手的提示词，补充到模板库里
• 清理不再需要的旧规则，保持项目指令的精简

这样坚持一个月，你会发现AI助教的“智商”明显提升了。不是模型变了，而是你给它的工作环境越来越好了。

9.3 团队协作中的配置管理

如果是团队使用，配置管理就更重要了。我的建议是：

第一，项目指令和资产库纳入版本控制。放在Git仓库里，跟代码一起管理。每次修改都走代码审查流程，确保规则的质量。

第二，建立提示词共享库。团队成员把自己觉得好用的提示词贡献出来，统一放在一个地方管理。新人入职时直接参考，不用从零开始摸索。

第三，定期做配置同步。每两周开一次短会，同步一下各自发现的配置问题和优化建议。把好的实践推广到全团队。

最后分享一个我个人的小技巧：我会在项目指令的最后加一段“元规则”，告诉AI如果它对某条规则不确定，应该主动询问而不是猜测。这条规则帮我避免了很多“AI自作主张”的情况。比如AI不确定某个字段该用什么类型时，它会问“这个字段应该是String还是Integer”，而不是随便选一个。多问一句，少改十行。