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容易理解的格式。比如表名字段类型说明orderidbigint订单ID主键orderorder_novarchar(32)订单编号唯一orderuser_idbigint用户ID关联user表ordertotal_amountdecimal(10,2)订单总金额单位元ordercoupon_amountdecimal(10,2)优惠券抵扣金额单位元orderstatustinyint状态0待支付 1已支付 2已发货 3已完成 4已取消这种结构化格式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 提示词工程的核心原则具体、可验证、有边界具体不要说“优化一下这段代码”而要说“把这段代码里的N1查询改成批量查询”。具体到操作层面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 常见问题速查表问题现象可能原因排查方法解决措施AI引用不相关模块模块边界不清检查指令是否明确模块范围在指令中列出涉及文件清单代码不符合规范指令约束力弱检查规范措辞和位置用“必须/禁止”给正反例资产库信息过期缓存或路径问题检查文件路径和版本刷新缓存加版本号上下文不够用配置过度统计指令和资产占比分层加载精简指令AI回答泛泛而谈资产库信息不足检查资产库覆盖度补充业务规则和示例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助教也需要你持续反馈和调整。用带人的心态来配置很多问题自然就有答案了。
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容易理解的格式。比如表名字段类型说明orderidbigint订单ID主键orderorder_novarchar(32)订单编号唯一orderuser_idbigint用户ID关联user表ordertotal_amountdecimal(10,2)订单总金额单位元ordercoupon_amountdecimal(10,2)优惠券抵扣金额单位元orderstatustinyint状态0待支付 1已支付 2已发货 3已完成 4已取消这种结构化格式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 提示词工程的核心原则具体、可验证、有边界具体不要说“优化一下这段代码”而要说“把这段代码里的N1查询改成批量查询”。具体到操作层面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 常见问题速查表问题现象可能原因排查方法解决措施AI引用不相关模块模块边界不清检查指令是否明确模块范围在指令中列出涉及文件清单代码不符合规范指令约束力弱检查规范措辞和位置用“必须/禁止”给正反例资产库信息过期缓存或路径问题检查文件路径和版本刷新缓存加版本号上下文不够用配置过度统计指令和资产占比分层加载精简指令AI回答泛泛而谈资产库信息不足检查资产库覆盖度补充业务规则和示例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助教也需要你持续反馈和调整。用带人的心态来配置很多问题自然就有答案了。
