AI助教配置实战：项目指令、资产库与提示词三层模型

1. 为什么“配置项目”才是AI助教好不好用的分水岭

很多人第一次接触AI助教，注意力全在模型本身——参数多大、上下文多长、跑分多高。但真正把AI助教接进实际项目里跑上一周，你就会发现一个扎心的事实：模型能力是天花板，项目配置才是地板。地板没铺好，天花板再高也够不着。

我拿自己踩过的坑说事。早前给一个后台管理系统配AI助教，代码库有十几万行，涉及Java后端、Vue前端、SQL脚本、配置文件一大堆。我一开始图省事，直接把整个仓库路径丢给AI，结果它回答问题时经常“串味”——问后端接口，它给你扯前端组件；问数据库字段，它引用了一个三年前就废弃的实体类。后来我才明白，问题不在模型，在于我根本没告诉它“这个项目长什么样、哪些文件重要、按什么规矩来”。

所谓“让AI助教耳聪目明”，拆开看就是两件事。“耳聪”指的是它能准确接收你项目里的有效信息，不被噪音干扰；“目明”指的是它能看清项目的结构、约定和上下文，回答时有的放矢。而这两件事，靠的都是项目配置——具体来说，就是项目指令、资产库、提示词这三样东西的合理编排。

这篇文章适合谁看？如果你正在用Cursor、通义灵码、GitHub Copilot Workspace、或者自己基于大模型搭了一套AI助教，并且希望它从“能聊天”进化到“真能干活”，那接下来的内容就是给你准备的。我会从整体设计思路讲到具体配置步骤，再到排查技巧，尽量把每个“为什么这么配”说清楚。你不需要是提示词工程专家，但最好对项目结构有基本概念。

2. 整体设计思路：把AI助教当成新入职的同事来带

2.1 核心隐喻：你不会让新同事自己翻整个代码库

想象一下，公司招了一个技术很强但完全不了解你们业务的新同事。你希望他帮你改一个订单导出功能。如果你只说“你去把订单导出改一下”，他大概率会懵——订单表在哪？导出逻辑在哪个模块？有没有代码规范？历史上有哪些坑不能踩？

正确的做法是什么？你会给他一份入职文档，告诉他项目结构、技术栈、代码规范；你会给他权限和工具，让他能访问代码仓库、数据库文档、接口文档；你还会在具体任务时给出明确的指令，比如“在OrderExportService里把导出字段加上优惠券金额，注意金额单位是分”。

AI助教的配置逻辑一模一样。项目指令就是入职文档，资产库就是权限和工具，提示词就是具体任务指令。三者缺一不可，而且有先后顺序——先有指令定规矩，再有资产库供信息，最后用提示词驱动具体任务。

2.2 三层配置模型：指令层、资产层、任务层

我把整个配置体系拆成三层，这样你在实际操作时不容易乱。

指令层（Project Instructions）是最高优先级、最稳定的部分。它定义的是“这个项目是什么、按什么规矩来”。比如技术栈说明、目录结构约定、命名规范、禁止事项。这一层的内容应该尽量少变，因为它会被注入到每一次对话的上下文中。写得太啰嗦会挤占上下文窗口，写得太简略又起不到约束作用。

资产层（Asset Library / Knowledge Base）是项目的“外部记忆”。它包括接口文档、数据库Schema、关键业务逻辑说明、常见问题记录等。这一层的特点是内容多、更新频率中等，不适合全部塞进指令里，而是通过检索或按需加载的方式供AI调用。

任务层（Task Prompts）是每次具体交互时你给AI的指令。它应该聚焦当前任务，引用指令层和资产层的信息，而不是重复它们。比如“参考资产库里的订单表结构，在OrderExportService中新增优惠券金额字段导出”。

这三层的比例大概是：指令层占上下文10%到15%，资产层按需检索占30%到50%，任务层占20%到30%。剩下的留给对话历史和模型思考空间。这个比例不是死的，但如果你发现指令层占了上下文一半以上，那说明你把太多东西塞错地方了。

2.3 为什么不能只靠“把代码全丢进去”

有人会想，现在模型上下文都上百万token了，我直接把整个项目源码全塞进去不就行了？理论上可以，实际上有三个问题。

第一，噪音干扰。项目里大量代码是自动生成的、废弃的、或者与当前任务无关的。这些内容会稀释有效信息，让模型抓不住重点。我实测过，同样一个问题，只给相关文件时回答准确率明显高于给全量代码。

第二，成本与延迟。每次对话都传全量代码，token消耗巨大，响应速度也会明显下降。对于日常高频使用来说，这个成本不可接受。

第三，更新滞后。代码库每天都在变，你不可能每次改动都重新同步全量代码给AI。而结构化的指令和资产库更新成本低得多。

所以正确的思路不是“喂更多”，而是“喂更准”。这就是配置的价值。

3. 项目指令怎么写：让AI助教先懂规矩再干活

3.1 指令的四个必备模块

一份合格的项目指令，我建议包含四个模块，按优先级排列。

模块一：项目身份。用两三句话说明这个项目是做什么的、技术栈是什么、面向什么用户。比如“这是一个基于Spring Boot + Vue3的后台管理系统，服务于内部运营人员，核心功能包括订单管理、库存管理和报表导出。”这段话的作用是给AI一个全局定位，避免它把后台管理系统当成电商前台来理解。

模块二：目录结构与关键路径。列出项目的主要目录和它们对应的功能。不需要列到每个文件，但关键模块要标出来。比如：

src/main/java/com/example/ controller/ 接口层，处理HTTP请求 service/ 业务逻辑层 mapper/ 数据库访问层 entity/ 实体类 config/ 配置类 src/main/resources/ application.yml 主配置文件 mapper/ MyBatis XML映射文件

这样AI在回答“订单逻辑在哪”时，能直接定位到service层，而不是去controller里瞎找。

模块三：代码规范与约定。这部分是很多项目配置里缺失的，但极其重要。比如命名规范（类名大驼峰、方法名小驼峰、常量全大写下划线）、注释要求（公共方法必须有Javadoc）、异常处理约定（统一用BusinessException包装）、日志规范（用SLF4J，禁止System.out）。把这些写清楚，AI生成的代码才符合项目风格，而不是各写各的。

模块四：禁止事项。明确告诉AI哪些事不能做。比如“禁止在controller层直接调用mapper”、“禁止使用SELECT *”、“禁止在循环中调用数据库”、“禁止修改自动生成的代码文件”。这些禁止事项往往来自项目历史上的踩坑经验，写进去能避免AI重复犯错。

3.2 指令的写法技巧：用“必须”“禁止”代替“建议”“最好”

这是一个很微妙的点。大模型对指令的遵循程度，和指令的措辞强度有关。我实测下来，“必须”“禁止”“始终”“绝不”这类词的约束效果，明显好于“建议”“最好”“尽量”。

比如你写“建议使用构造器注入”，AI可能有一半概率用@Autowired字段注入。但你写“必须使用构造器注入，禁止使用@Autowired字段注入”，遵循率会高很多。

另一个技巧是给出正反例。对于容易出错的规范，直接给一个正确示例和一个错误示例，比单纯描述规则有效得多。比如：

// 正确：使用构造器注入 private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } // 错误：使用字段注入 @Autowired private OrderService orderService;

这种正反对比，AI一看就懂，比长篇大论管用。

3.3 指令长度控制：宁短勿长，分层加载

项目指令不是越长越好。我见过有人写了三千字的指令，结果每次对话光指令就占了几千token，模型真正用来思考的空间被压缩了。

我的经验是，核心指令控制在500到800字，只放最关键的约束。更详细的内容放到资产库里，按需检索。比如完整的数据库Schema、接口文档、业务规则说明，这些都不应该塞进指令，而是作为资产库内容，在需要时由AI主动查询或由你手动引用。

如果你用的工具支持分层加载（比如Cursor的.cursorrules文件、通义灵码的项目级配置），那就把指令分成“全局指令”和“模块指令”。全局指令放通用规范，模块指令放特定模块的约定。这样AI在处理不同模块时，加载不同的指令，效率更高。

4. 资产库怎么建：给AI助教配一个随用随取的资料柜

4.1 资产库该放什么：四类核心资产

资产库不是代码仓库的复制品，而是经过提炼的、AI真正需要的信息。我建议放四类内容。

第一类：数据模型说明。包括数据库表结构、字段含义、表之间的关系。不需要把建表SQL原封不动放进去，而是整理成AI容易理解的格式。比如：

这种结构化格式，AI理解起来比看DDL快得多。

第二类：接口文档。整理核心接口的路径、方法、参数、返回值。同样用结构化格式，不要直接贴Swagger JSON。

第三类：业务规则说明。这是最有价值但最容易被忽略的部分。比如“订单金额计算规则：总金额 = 商品金额之和 - 优惠券金额 - 积分抵扣金额，其中积分抵扣最多占总金额的30%”。这种业务逻辑，代码里可能分散在多个地方，但AI需要知道完整规则才能正确修改。

第四类：常见问题与历史决策记录。比如“为什么订单表不用外键：因为分库分表后外键无法维护”、“为什么导出功能用EasyExcel而不是POI：因为POI在大数据量下内存溢出”。这些背景信息能帮助AI理解代码为什么这么写，避免它提出“优化建议”时把有意为之的设计当成错误。

4.2 资产库的组织方式：按模块还是按类型

资产库的组织方式有两种主流做法：按模块分和按类型分。

按模块分适合业务边界清晰的项目。比如订单模块一个文件夹，里面放订单的表结构、接口文档、业务规则。用户模块一个文件夹，放用户相关的资产。这种方式的优点是检索范围小，AI处理订单问题时只需要加载订单模块的资产。

按类型分适合技术栈统一、业务交叉多的项目。比如所有表结构放一个文件，所有接口文档放一个文件。这种方式的优点是维护方便，更新时只需要改一个地方。

我个人的选择是混合模式：核心的、跨模块的资产按类型分（比如全局数据字典、通用规范），业务模块相关的资产按模块分。这样兼顾了检索效率和维护成本。

4.3 资产库的更新机制：别让它变成“死库”

资产库最大的风险是过期。代码改了，资产库没改，AI就会基于错误信息回答问题，比不知道还糟糕。

我的做法是把资产库更新纳入开发流程。具体来说，在代码合并请求的检查清单里加一条：“如果本次改动涉及表结构、接口定义或业务规则，是否同步更新了资产库？”这样每次代码变更都会触发资产库的检查。

另外，对于高频变动的部分，我倾向于不放进资产库，而是让AI直接读代码。比如具体的实现逻辑，代码本身就是最新最准的，没必要在资产库里维护一份副本。资产库只放那些代码里看不出来的、或者分散在各处需要汇总的信息。

5. 提示词怎么设计：让AI助教每次都能听懂你的具体需求

5.1 任务提示词的结构：背景 + 目标 + 约束 + 示例

一个好的任务提示词，我总结为四段式结构。

背景：说明当前任务涉及哪个模块、什么场景。比如“当前在处理订单导出功能，涉及OrderExportService和OrderMapper”。

目标：明确要做什么。比如“在导出字段中新增优惠券抵扣金额”。

约束：说明有什么限制。比如“优惠券金额单位为元，保留两位小数；如果优惠券金额为0，导出时显示空字符串而不是0.00”。

示例：给一个输入输出的例子。比如“参考现有字段totalAmount的导出逻辑，它的格式化方式是...”。

这四段写清楚，AI基本不会跑偏。很多人写提示词只写目标，结果AI要么漏掉约束，要么理解错背景，来回改好几轮，反而更费时间。

5.2 提示词工程的核心原则：具体、可验证、有边界

具体：不要说“优化一下这段代码”，而要说“把这段代码里的N+1查询改成批量查询”。具体到操作层面，AI才能执行。

可验证：好的提示词应该让你能判断AI的输出对不对。比如“生成的SQL必须能通过EXPLAIN验证，不能出现全表扫描”。这样你拿到结果后能快速验证。

有边界：明确告诉AI不要做什么。比如“只修改OrderExportService，不要动OrderMapper”、“不要引入新的依赖”。边界越清晰，AI越不容易越界。

5.3 提示词的迭代与沉淀：把好用的提示词存下来

提示词不是一次性的。同一个任务，你可能需要反复执行，比如每周都要导出一次报表。这时候把调试好的提示词存下来，下次直接用，效率提升明显。

我建议在资产库里专门开一个“提示词模板”区域，按任务类型分类存放。比如“代码生成类”、“代码审查类”、“问题排查类”、“文档生成类”。每个模板记录：适用场景、提示词全文、使用注意事项、历史效果评价。

这样积累下来，你就有了一个提示词工具箱。新任务来了，先看看有没有现成模板可以套，没有的话再从头写，写完如果效果好也存进去。时间长了，AI助教的使用效率会越来越高。

6. 实操过程：从零配置一个AI助教

6.1 第一步：梳理项目结构，确定指令内容

假设我们有一个基于Spring Boot + Vue3的后台管理系统，代码库大概五万行。首先花半小时梳理项目结构，确定指令内容。

打开项目根目录，列出主要目录和关键文件。然后打开几个核心模块的代码，看看命名规范、注释风格、异常处理方式。把这些观察整理成指令文档。

我实际写出来的指令大概长这样：

# 项目指令 ## 项目身份 基于Spring Boot 2.7 + Vue3的后台管理系统，服务于内部运营人员。 核心模块：订单管理、库存管理、报表导出。 ## 目录结构 - src/main/java/com/example/controller/ 接口层 - src/main/java/com/example/service/ 业务逻辑层 - src/main/java/com/example/mapper/ 数据访问层 - src/main/java/com/example/entity/ 实体类 - src/main/resources/mapper/ MyBatis XML ## 代码规范 - 必须使用构造器注入，禁止@Autowired字段注入 - 公共方法必须有Javadoc，说明参数和返回值 - 异常统一用BusinessException包装，禁止直接抛RuntimeException - 日志用SLF4J，禁止System.out.println ## 禁止事项 - 禁止在controller层直接调用mapper - 禁止使用SELECT * - 禁止在循环中调用数据库 - 禁止修改target/目录下任何文件

这份指令大概400字，覆盖了最关键的约束。

6.2 第二步：整理资产库，建立结构化知识

接下来整理资产库。先从数据库开始，把核心表的结构整理成表格。然后整理接口文档，把主要接口的路径、参数、返回值列出来。最后整理业务规则，把订单金额计算、库存扣减逻辑等关键规则写清楚。

这一步比较费时间，但一次投入长期受益。我整理一个五万行项目的资产库，大概花了半天时间。之后每次AI回答问题时，我都能感觉到它“懂”这个项目，而不是泛泛而谈。

资产库文件建议用Markdown格式，方便阅读和更新。放在项目根目录的.ai-assets/文件夹下，按模块或类型分文件。

6.3 第三步：配置工具，让AI能读到指令和资产

不同工具的配置方式不一样。以Cursor为例，在项目根目录创建.cursorrules文件，把项目指令放进去。资产库文件放在.ai-assets/目录下，在对话时通过@引用。

通义灵码的话，在项目设置里找到“项目级配置”，把指令填进去。资产库可以通过“知识库”功能上传。

GitHub Copilot Workspace目前对项目级配置的支持还在完善中，但可以通过.github/copilot-instructions.md文件来提供指令。

不管用什么工具，核心思路是一样的：指令要自动加载，资产要按需引用。指令每次对话都生效，资产在需要时手动或自动检索。

6.4 第四步：跑一个真实任务，验证配置效果

配置完成后，找一个真实任务来验证。比如“在订单导出中新增优惠券金额字段”。

先看AI能不能正确定位到OrderExportService和OrderMapper。然后看它生成的代码是否符合规范（构造器注入、Javadoc、异常处理）。最后看它有没有引用资产库里的订单表结构，字段类型和单位对不对。

如果发现问题，回到指令或资产库调整。比如AI用了字段注入，就在指令里把“必须使用构造器注入”加粗强调。如果AI不知道优惠券金额的单位，就在资产库里把字段说明写得更清楚。

这个迭代过程可能来回两三次，但每次调整都会让AI助教更“懂”你的项目。

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

7.1 AI回答“串味”，引用了不相关的模块

这是最常见的问题。原因通常是资产库检索范围太宽，或者指令里没有明确模块边界。

排查思路：先看AI引用了哪些文件，判断它是从指令还是资产库里获取的信息。如果是指令里没写清楚模块划分，就在指令里补充“订单模块只涉及OrderController、OrderService、OrderMapper，不要引用User模块的代码”。如果是资产库检索太宽，就调整检索策略，缩小范围。

我的经验是，在指令里明确写出“当前任务涉及的文件列表”，能大幅减少串味问题。比如“本次任务只涉及OrderExportService.java和OrderMapper.xml，其他文件不要修改”。

7.2 AI生成的代码不符合项目规范

如果AI反复违反某条规范，说明指令的约束力不够。解决办法有三个：一是把规范措辞加强，用“必须”“禁止”；二是给出正反例；三是把规范放到指令的最前面，因为模型对开头的内容注意力更高。

还有一个技巧是在任务提示词里重复关键规范。比如“生成代码时注意：必须使用构造器注入，必须写Javadoc”。虽然指令里已经写了，但在具体任务里再强调一次，遵循率会更高。

7.3 资产库更新后AI还在用旧信息

这通常是缓存问题。有些工具会缓存资产库内容，更新后需要手动刷新或重启。另外检查一下资产库文件的路径有没有变，如果路径变了，工具可能读的是旧路径下的文件。

如果工具支持版本管理，建议给资产库文件加版本号，比如order-schema-v2.md。这样能清楚知道AI用的是哪个版本。

7.4 上下文窗口不够用，指令和资产库占太多

这是配置过度的信号。解决办法是分层加载：核心指令常驻，资产库按需检索。如果工具不支持按需检索，就把资产库拆成多个小文件，每次只引用相关的那个。

另外，定期清理指令里过时的内容。项目在演进，半年前写的规范可能已经不适用的。每季度review一次指令和资产库，删掉不再需要的内容。

7.5 常见问题速查表

8. 进阶技巧：让AI助教从“能用”到“好用”

8.1 用“角色设定”提升回答质量

在指令里给AI设定一个角色，能明显提升回答的专业度。比如“你是一名有十年经验的Java后端工程师，熟悉Spring Boot和MyBatis，注重代码质量和性能”。这个角色设定会引导AI用更专业的视角回答问题。

但角色设定要适度，不要写得太夸张。我试过写“你是世界顶级架构师”，结果AI回答时喜欢扯大词，反而不实用。后来改成“你是一名注重实效的后端工程师”，回答就务实多了。

8.2 用“思维链”引导AI分步思考

对于复杂任务，可以在提示词里要求AI分步思考。比如“请按以下步骤处理：第一步，分析OrderExportService的现有逻辑；第二步，确定新增字段的位置；第三步，生成修改后的代码；第四步，检查是否符合规范”。

这种分步引导能减少AI的跳跃性思维，让输出更可控。特别是涉及多文件修改时，分步思考能避免遗漏。

8.3 建立反馈循环，持续优化配置

AI助教的配置不是一次性的，而是持续迭代的。我建议每次使用后花一分钟记录：这次回答哪里好、哪里不好、下次怎么改进。积累一周后，你会发现自己项目的AI助教配置越来越精准。

可以建一个简单的反馈日志，记录日期、任务类型、问题描述、改进措施。比如“3月15日，代码生成任务，AI漏了异常处理，改进：在指令里把异常处理规范提前”。

这个习惯看起来麻烦，但坚持下来，AI助教的可用性会有质的提升。

8.4 多工具协同：不同场景用不同工具

不要指望一个工具解决所有问题。我的做法是：日常代码补全用IDE插件，复杂重构用对话式工具，批量任务用脚本调用API。每个工具的配置侧重点不同，但共享同一套指令和资产库。

比如IDE插件更注重实时补全，指令可以精简一些；对话式工具需要更完整的上下文，指令和资产库都要加载。把同一套配置适配到不同工具，能保持AI助教行为的一致性。

9. 我个人的配置心得

配置AI助教这件事，我最大的体会是：前期投入的时间，会在后续使用中加倍返还。我第一个项目配置花了大概一天时间，之后三个月里，AI助教的回答准确率明显高于没配置的项目，来回修改的次数少了很多。

另一个心得是不要追求完美配置。一开始就想把所有规范、所有资产都整理好，很容易半途而废。我的做法是先配最小可用版本——一份核心指令加一个关键模块的资产库，跑起来再说。然后在使用中逐步补充，遇到问题就加一条规范，发现AI不知道某个信息就补进资产库。这样配置是长出来的，不是一次性设计出来的。

最后分享一个小技巧：把AI助教当成团队新成员来对待。你会怎么带新同事，就怎么配置AI助教。新同事需要知道项目背景、代码规范、业务规则，AI助教也一样。新同事需要时间熟悉项目，AI助教也需要你持续反馈和调整。用带人的心态来配置，很多问题自然就有答案了。