1. 为什么“耳聪目明”的AI助教不是靠模型参数堆出来的很多人第一次接触AI助教脑子里想的都是“换个更大的模型是不是就聪明了”。我一开始也这么想后来在真实项目里折腾了几个月才发现模型能力只是下限真正决定AI助教好不好用的是项目配置这一层。所谓“耳聪”指的是它能准确读到项目里的上下文、规范、历史记录“目明”指的是它清楚当前任务边界、知道该看哪些文件、不该碰哪些文件。这两件事跟模型多大关系不大跟你怎么配置关系极大。我见过太多团队模型用的是第一梯队结果AI助教给出的建议驴唇不对马嘴。排查下来问题几乎都出在配置上项目指令写得像口号资产库散落在各个角落提示词全靠临时手打。这就像请了一位很聪明的助教但不给他教材、不告诉他课程大纲、不告诉他学生水平他再聪明也只能瞎猜。所以这一篇我想把“项目配置”这件事拆开讲透从项目指令、资产库、提示词三个维度讲清楚怎么让AI助教真正变得耳聪目明。这篇文章适合三类人看一是正在把AI助教接入自己项目的开发者二是团队里负责搭建AI工作流的技术负责人三是自己用AI写代码、写文档但总觉得“它不懂我”的独立创作者。不管你用的是哪家的AI编程工具底层逻辑是相通的——配置决定上限提示词决定下限资产库决定稳定性。2. 项目指令给AI助教装上一套“工作手册”2.1 项目指令到底在解决什么问题项目指令英文里常叫project instructions或者system prompt它是AI助教每次启动时最先读到的一段“总纲”。你可以把它理解成新员工入职时发的那本《员工手册》——里面写着公司是做什么的、代码规范是什么、遇到问题找谁、哪些事绝对不能干。没有这本手册新员工只能靠猜有了手册他至少不会犯低级错误。我在实际项目里踩过最大的坑就是一开始把项目指令写成了“你是一个资深工程师请帮我写好代码”。这种话对AI来说等于没说。后来我改成结构化的写法效果立刻不一样。项目指令要回答的核心问题有四个这个项目是干什么的、技术栈是什么、代码风格和目录约定是什么、有哪些硬性禁止事项。把这四个问题写清楚AI助教给出的建议立刻从“泛泛而谈”变成“贴着项目走”。2.2 一份可复用的项目指令模板拆解下面这份模板是我在多个项目里迭代出来的你可以直接拿去改。注意模板里的方括号内容需要你替换成自己项目的实际情况。# 项目背景 本项目是[一句话描述项目定位]主要服务于[目标用户]。 核心技术栈[语言/框架/数据库/部署方式]。 # 目录结构约定 - src/ 存放业务源码按功能模块划分 - config/ 存放配置文件禁止硬编码 - tests/ 存放测试用例命名规则为 xxx.test.js - docs/ 存放设计文档新增功能必须同步更新 # 代码规范 - 函数命名使用小驼峰常量使用全大写下划线 - 单个函数不超过50行超过必须拆分 - 所有对外接口必须有参数校验和错误处理 - 禁止在业务代码里直接写SQL字符串 # 硬性禁止 - 禁止引入未经团队评审的第三方依赖 - 禁止修改 config/ 下的生产环境配置 - 禁止删除 tests/ 下已有用例只能新增 # 交互约定 - 回答前先确认你理解了需求有歧义先提问 - 给出代码时标注修改的文件路径和修改原因 - 涉及数据库变更时必须同时给出回滚方案这份模板的关键在于“可执行”。什么叫可执行就是AI读完能直接判断“这件事我能不能做”。比如“禁止硬编码”就是可执行的AI看到配置项会主动往config里放“代码要优雅”就不可执行因为优雅没有标准。我建议你在写项目指令时每写一条就问自己这条规则能不能用“是/否”来判断不能的话就继续拆。2.3 项目指令的更新节奏与版本管理项目指令不是写完就一劳永逸的。项目在演进规范在变化AI助教读到的指令也必须跟着更新。我的做法是给项目指令单独建一个文件比如.ai/instructions.md纳入版本管理。每次项目规范调整先改这个文件再同步给团队。这样做有两个好处一是AI读到的永远是最新版二是团队成员能通过git记录看到规范是怎么演变的。还有一个细节很多人忽略项目指令的长度。我实测下来项目指令控制在800到1500字之间效果最好。太短了信息不够AI还是会瞎猜太长了AI会“注意力涣散”把前面的规则忘掉。如果你确实有很多规则要写建议分层核心规则放项目指令细节规则放资产库让AI按需读取。3. 资产库让AI助教随时翻得到“参考资料”3.1 资产库和项目指令的分工项目指令是“总纲”资产库是“资料柜”。总纲告诉AI助教“我们是怎么做事的”资料柜告诉AI助教“具体这件事以前是怎么做的”。举个例子项目指令里写“所有接口必须有错误处理”这是规则资产库里放三个历史接口的完整实现这是范例。AI助教看到规则知道要做什么看到范例知道怎么做才符合团队习惯。我见过不少团队只写项目指令不建资产库结果AI助教给出的代码“方向对但味道不对”——逻辑没问题但命名风格、异常处理方式、日志格式跟项目里其他代码格格不入。这就是缺了资产库的后果。资产库的价值在于“对齐”让AI的输出和团队既有资产保持一致的“手感”。3.2 资产库该放什么、不该放什么资产库不是垃圾桶不是什么文件都往里塞。我建议按“高频参考价值”来筛选具体可以分四类资产类型具体内容参考价值代码范例典型模块的完整实现、工具类、公共组件让AI模仿团队代码风格设计文档架构图说明、接口文档、数据模型让AI理解系统全貌规范细则命名规范、日志规范、异常码表补充项目指令的细节历史决策技术选型记录、踩坑复盘避免AI重复建议已被否决的方案不该放的东西也很明确密钥、密码、生产环境配置、个人隐私数据。这些一旦进了资产库AI在生成内容时可能无意间泄露。我一般会在资产库目录下放一个.aiignore文件把敏感路径排除掉跟.gitignore一个思路。3.3 资产库的组织方式与检索效率资产库放得乱AI助教找起来就慢甚至找错。我的经验是按“领域类型”两级目录来组织比如.ai/assets/ backend/ examples/ 后端代码范例 docs/ 后端设计文档 frontend/ examples/ 前端代码范例 docs/ 前端设计文档 shared/ conventions/ 通用规范 decisions/ 历史决策记录这样组织的好处是当AI助教处理后端任务时你可以在提示词里明确说“参考backend/examples下的实现”它就不会跑到前端目录里去找。检索效率的提升直接体现在AI回答的准确率上。我实测过同样一个需求资产库组织清晰的团队AI一次给对的概率比组织混乱的团队高出将近一倍。4. 提示词把“耳聪目明”落到每一次具体交互4.1 提示词不是越长越好而是越准越好很多人写提示词有个误区觉得写得越多AI越懂。我早期也这样一个提示词写上千字结果AI反而抓不住重点。后来我总结出一个原则提示词要像给同事发的工作消息说清楚“背景、任务、要求、参考”四件事就够了。背景是当前在做什么任务是这次要AI干什么要求是输出格式和约束参考是让它看哪些资产。举个例子同样是让AI写一个用户查询接口差的提示词是“帮我写个查询用户的接口”好的提示词是“当前项目是电商后台用户模块已有User实体和UserRepository请参考backend/examples/order-query.js的风格写一个按手机号查询用户的接口要求包含参数校验、分页、错误处理输出完整文件内容”。后者信息密度高AI一次就能给对。4.2 提示词工程里的“上下文工程”思维现在圈子里常提“提示词工程”和“上下文工程”我的理解是提示词工程解决“怎么说”上下文工程解决“给AI看什么”。两者配合AI助教才能真正耳聪目明。上下文工程的核心是“精准投喂”——在正确的时间把正确的资料以正确的形式给到AI。具体怎么做我一般分三步。第一步判断任务类型是写新代码、改老代码还是排查问题。第二步根据任务类型决定要加载哪些资产写新代码加载范例改老代码加载原文件和规范排查问题加载日志和决策记录。第三步把这些上下文用清晰的分隔符组织进提示词让AI能区分“这是规则”“这是范例”“这是当前任务”。分隔符我常用---或者XML标签效果比纯文本堆叠好很多。4.3 一套可复用的提示词骨架下面这套骨架是我日常用得最多的你可以根据任务类型增删模块## 背景 [当前项目状态、正在做的功能] ## 任务 [这次具体要AI完成什么] ## 约束 - [必须遵守的规则1] - [必须遵守的规则2] ## 参考资产 - [资产路径1][这个资产说明什么] - [资产路径2][这个资产说明什么] ## 输出要求 - 格式[文件/片段/说明] - 语言[中文/英文] - 特别说明[其他要求]这套骨架的好处是模块化AI读起来有结构你写起来也有章法。我建议你把它存成模板每次用的时候填空比每次从零写效率高得多。5. 三个配置维度的联动一次真实项目的调优记录5.1 项目背景与初始配置去年我参与了一个后台管理系统的开发技术栈是Python加前端框架团队五个人AI助教用的是当时主流的编程助手。初始配置很粗糙项目指令只有三行资产库没建提示词全靠手打。结果第一个月AI助教给出的代码能用率不到三成团队成员怨声载道说“AI还不如自己写”。我接手调优后先做了一件事把项目指令从三行扩展到一千字把目录约定、代码规范、禁止事项全部写清楚。然后建了资产库把已有的十个典型模块整理进去。最后给团队定了一套提示词模板要求每次提问必须填背景、任务、约束、参考。这三步做完第二个月AI代码能用率涨到了七成以上。5.2 调优过程中的关键发现调优过程中有几个发现值得分享。第一个发现是项目指令里“禁止事项”比“鼓励事项”更重要。AI助教很聪明你不禁止它它就会“自由发挥”引入你没用过的库、改你不让它改的文件。把禁止事项写清楚等于给它画了红线越界行为大幅减少。第二个发现是资产库的“新鲜度”比“数量”重要。我们一开始塞了很多老代码进资产库结果AI模仿出来的风格跟当前项目脱节。后来我们定了个规矩资产库只放最近半年内、经过评审的代码老代码一律清出去。风格一致性立刻提升。第三个发现是提示词模板要“强制使用”。光发模板没人用我们在代码评审里加了一条AI生成的代码必须附上使用的提示词评审时一起看。这样一来提示词质量成了团队共同关注的事整体水平提升很快。5.3 配置成熟后的效果对比配置成熟后我做了个对比。同一个需求“新增一个数据导出功能”配置前AI给出的代码需要大改配置后AI给出的代码基本可以直接用只需要微调。时间上配置前从提问到可用平均要两小时配置后缩短到二十分钟。更重要的是团队成员对AI助教的信任度上来了愿意把更多任务交给它形成了正向循环。这个案例让我确信一件事AI助教的“聪明”七分靠配置三分靠模型。你把配置做扎实中等模型也能干出好活配置稀烂顶级模型也白搭。6. 配置过程中最容易踩的五个坑6.1 坑一项目指令写成“愿望清单”最常见的坑就是把项目指令写成“我希望AI怎么样”比如“希望AI写出高质量代码”“希望AI理解业务”。这种写法AI没法执行。正确做法是写成“AI必须怎么样”用可判断的规则替代模糊的期望。我一般会做个小测试把项目指令给一个新同事看问他“你知道什么能做什么不能做吗”如果他说不清楚说明指令还得改。6.2 坑二资产库变成“代码坟场”第二个坑是资产库只进不出越堆越多最后AI在里面找不到有用的东西。我的建议是给资产库定个“保质期”比如每季度清理一次把过时的、被替代的资产移出去。同时给每个资产加个头部注释写明“这个资产适用于什么场景、最后更新是什么时候”方便AI判断相关性。6.3 坑三提示词全靠“灵感”第三个坑是提示词没有模板每次靠临时想。这样质量忽高忽低AI的表现也跟着忽好忽坏。解决办法就是前面说的模板化把常用任务类型的提示词固化成模板用的时候填空。模板不用多五六个覆盖八成场景就够了。6.4 坑四忽略“负面提示”第四个坑是只告诉AI要做什么不告诉它不要做什么。AI在缺乏约束时会“过度发挥”比如你让它写个函数它顺手把整个文件重构了。负面提示就是明确说“不要改这个文件”“不要引入新依赖”“不要动数据库结构”。这些“不要”能省掉大量返工。6.5 坑五配置一次就不管了第五个坑是把配置当成一次性工作。项目在变配置必须跟着变。我的做法是每月做一次“配置体检”检查项目指令是否还准确、资产库是否有过时内容、提示词模板是否需要更新。这个习惯坚持下来AI助教的表现一直很稳定。7. 让配置持续生效的几个日常习惯配置做完只是开始能不能持续生效靠的是日常习惯。我分享几个自己一直在用的。第一个习惯是“配置先行”。每次开新功能先更新项目指令和资产库再让AI介入。这就像开工前先发图纸比边干边改效率高得多。第二个习惯是“提示词留痕”。每次用AI完成一个任务把提示词存下来标注任务类型和效果。积累一段时间后你会发现某些提示词模板特别好用某些场景需要特殊处理这些都是团队的知识资产。第三个习惯是“定期复盘”。每月花半小时看看这个月AI助教哪些任务完成得好、哪些完成得差差的任务是配置问题还是提示词问题。复盘一次配置就精进一次。第四个习惯是“新人上手先读配置”。团队来新人第一件事不是写代码是读项目指令和资产库。读懂了再上手AI助教用起来也顺手。这个习惯让新人融入速度明显加快。说到底AI助教的“耳聪目明”不是技术问题是管理问题。你把它当成一个需要培训、需要资料、需要反馈的团队成员来对待它就能真正帮上忙。配置这件事花的是前期时间省的是后期返工这笔账怎么算都划算。