企业官网建设流程全解析

1. 为什么“耳聪目明”的AI助教不是靠模型参数堆出来的

很多人第一次接触AI助教，脑子里想的都是“换个更强的模型是不是就聪明了”。我一开始也这么想，后来发现完全不是这回事。模型再强，如果你给它的项目上下文是残缺的、指令是模糊的、资产是散乱的，它就像一个听力正常但被蒙住眼睛的人——你说什么它都只能靠猜。所谓“耳聪目明”，核心不在模型本身，而在于你为它配置的项目指令、资产库和提示词体系这三件套是否到位。

这个判断不是拍脑袋来的。我前后在三个不同类型的项目里搭过AI助教：一个是代码辅助类的，一个是内容生成类的，还有一个是数据分析类的。每次一开始都觉得“模型不行”，折腾到最后发现，问题几乎都出在配置层。模型的能力上限是固定的，但你能不能让它在你的项目里发挥出接近上限的水平，取决于你喂给它的信息质量和结构。

打个比方，AI助教就像一个刚入职的实习生。他学历很好、基础扎实，但他不知道你们公司的代码规范、不知道你们项目的目录结构、不知道你们团队习惯用什么命名方式、不知道哪些文件是核心哪些是废弃的。你不告诉他这些，他干活就是瞎干。你告诉他了，他立刻就能上手。项目配置的本质，就是把一个通用型AI变成一个懂你项目的专属助手。

这里要区分一个常见误区：很多人把“配置项目”理解成写一个很长的系统提示词就完事了。实际上，项目配置至少包含四个层面——项目指令（告诉AI它是谁、要做什么）、资产库（给AI提供可查阅的项目资料）、提示词模板（规范AI的输出格式和思路）、运行环境配置（确保AI能调用项目里的工具和文件）。这四个层面缺一个，AI助教就会在某个环节“失聪”或“失明”。

我见过太多人只做了第一层，写了一段角色设定就以为配置完了，结果AI回答问题时完全不参考项目实际代码，给出的建议全是通用模板。这不是AI的问题，是你没给它“眼睛”去看项目里的东西。

所以这篇内容，我打算把这四个层面拆开讲清楚，每个层面都给出具体的配置方法、实操步骤和我踩过的坑。不管你是用哪种AI编程工具，底层逻辑是相通的。你把这套配置思路吃透，换任何工具都能快速搭出一个真正“耳聪目明”的AI助教。

2. 项目指令的写法：从“你是谁”到“你在这个项目里该怎么干活”

2.1 角色设定只是起点，行为约束才是核心

大部分人写项目指令，第一句话就是“你是一个资深Python开发工程师”。这句话有用，但作用非常有限。它只告诉了AI一个身份标签，没有告诉它在这个具体项目里应该怎么做事。

我现在的做法是把项目指令分成三个模块来写：身份模块、行为模块、边界模块。身份模块就是角色设定，一两句话搞定。行为模块是重点，要写清楚AI在回答问题时应该遵循什么流程、参考什么资料、输出什么格式。边界模块则是告诉AI哪些事情不能做、哪些假设不能下、哪些文件不要碰。

举个例子，在一个Java Web项目里，我的行为模块是这样写的：

当你收到一个代码问题时，按以下流程处理： 1. 先确认问题涉及哪个模块，在项目目录中找到对应的包路径 2. 查阅项目根目录下的 ARCHITECTURE.md 了解模块间依赖关系 3. 检查项目使用的框架版本（见 pom.xml），不要给出与当前版本不兼容的API 4. 输出代码时，遵循项目已有的命名规范和分层结构 5. 如果问题涉及数据库操作，先查看 mapper 目录下的XML文件确认表结构

这段指令看起来简单，但它把AI从一个“通用答题器”变成了一个“会查资料再回答的助手”。差别有多大？我实测过，加了这段流程指令之后，AI给出的代码建议与项目实际结构的匹配度从大概四成提升到了八成以上。

边界模块同样重要。比如我会写：“不要假设项目使用了某个未在pom.xml中声明的依赖”、“不要建议重构与当前问题无关的模块”、“如果项目中没有找到相关配置，明确告知而不是编造”。这些约束能大幅减少AI“幻觉”带来的干扰。

2.2 把项目规范翻译成AI能执行的指令

每个项目都有自己的规范，有些写在文档里，有些只存在于老员工的脑子里。AI助教不可能自己去“悟”出这些规范，你必须把它们翻译成明确的指令。

我一般会从这几个维度去梳理项目规范：目录结构约定、命名规范、代码风格、异常处理方式、日志规范、接口返回格式。每一条都写成一句明确的指令，放在项目指令文件里。

比如目录结构这块，我会写：“本项目采用按功能模块划分的目录结构，每个模块包含 controller、service、mapper、entity 四个子目录。新增功能时，文件应放在对应模块的对应子目录下，不要创建新的顶层目录。”

命名规范我会写：“类名使用大驼峰，方法名和变量名使用小驼峰，常量全大写下划线分隔，数据库表名使用下划线分隔且统一加前缀。”

这些指令看起来琐碎，但它们是AI助教“耳聪目明”的基础。没有这些，AI给出的代码虽然能跑，但风格和项目格格不入，你还得花大量时间改。

提示：项目指令不要一次写太长。我的经验是控制在800到1500字之间效果最好。太短了信息不够，太长了AI反而会忽略中间部分的内容。如果规范特别多，可以拆成多个文件，在项目指令里引用文件路径，让AI按需查阅。

2.3 指令的更新节奏：跟着项目走，别写完就不管

项目指令不是写一次就完事的。项目在迭代，规范在变化，AI助教也需要同步更新。我现在的习惯是每次项目有重大结构调整或者引入新规范时，顺手更新一下项目指令文件。

具体做法是在项目根目录建一个.ai-assistant目录，里面放instructions.md（项目指令）、glossary.md（术语表）、patterns.md（常用代码模式）。每次项目有变化，先更新这几个文件，再让AI助教开始干活。

这个习惯带来的收益非常明显。有一次我们项目从单体架构拆成了微服务，我花了一个下午更新了项目指令和资产库，之后AI助教给出的建议立刻就适应了新架构，完全没有出现“还在按单体架构给建议”的情况。如果没更新，AI就会一直用旧信息回答，你还得反复纠正它。

3. 资产库搭建：给AI助教装上“项目记忆”

3.1 什么该放进资产库，什么不该放

资产库这个概念，说白了就是给AI助教准备一个“项目资料柜”。它需要什么资料，你提前放进去，它回答问题时就能查阅。但不是什么文件都往里塞，塞太多反而会让AI抓不住重点。

我的筛选标准是这样的：放“解释性”文件，不放“执行性”文件。什么意思？比如项目的架构说明文档、数据库设计文档、接口文档、术语表、常见问题记录，这些是解释性的，应该放。而具体的业务代码文件、配置文件、日志文件，这些是执行性的，不需要全量放进去，AI需要时可以通过文件路径去读取。

我见过有人把整个项目源码都塞进资产库，结果AI每次回答都要扫描大量无关文件，效率极低，而且容易被不相关的代码干扰。正确的做法是放“索引”和“摘要”，而不是放“全文”。

具体来说，我的资产库通常包含这几类文件：

• 架构概览：用一段话描述项目整体架构、模块划分、技术栈
• 数据字典：核心表结构、字段含义、表间关系
• 接口清单：主要接口的路径、参数、返回值格式
• 术语表：项目中的专有名词、缩写、业务概念解释
• 常见模式：项目中反复出现的代码模式、设计模式使用惯例
• 已知问题：当前已知的坑、待修复的问题、临时方案

这些文件加起来控制在5000字以内，AI查阅起来效率最高。

3.2 资产库的组织方式：让AI能“按图索骥”

资产库不是把文件堆在一起就行了，得有清晰的组织结构，让AI知道什么情况下该查什么文件。

我的做法是在资产库根目录放一个index.md，里面用表格列出每个资产文件的名称、内容摘要、适用场景。AI在回答问题时，先读index.md，根据问题类型找到对应的资产文件，再去读取具体内容。

这个索引文件大概长这样：

允许执行： - cat, head, tail, grep, find（查看和搜索） - mvn test, npm test（运行测试） - mvn compile（编译检查） - prettier, eslint（代码格式化） 禁止执行： - rm, mv, chmod（文件操作） - git push, git reset（版本操作） - 任何涉及网络请求的命令