企业官网建设流程全解析

去年年初我在团队里立了个 flag：要全面铺开 AI 编程。当时我脑子里的第一反应就是“上最强模型”——把能订阅的都订阅上，Claude、GPT-4、国产大模型挨个试，谁跑分高就用谁。一年过去，我可以很负责任地说一句：模型强不强，根本不是重点。真正让 AI 编程在企业里跑起来的，是上下文管理、提示词工程、工程基建和团队协作方式。这篇文章就把我这一整年的实战过程、翻车现场和沉淀下来的方法都摊开说说，希望能给正在推 AI 编程的你一个更落地的视角。

1. 一年前我迷信“最强模型”，结果代码还是写崩了

1.1 从 Claude 到 GPT-4，为什么换模型没带来效率翻倍

我们团队最开始的做法很“朴素”：买最贵的模型，让大家直接在 IDE 里用。结果第一周就出了问题——同一个需求“给用户列表加分页”，让三个人用同一种 AI 工具写，产出的代码三套风格：有人用LIMIT/OFFSET，有人用cursor-based，还有人直接写了个流式接口。这还只是表象，更严重的是 AI 生成的代码经常跟项目现有架构不搭，比如我们内部规定所有数据库访问必须走仓储层，结果 AI 愣是给你直接拼接 SQL 然后塞到 Controller 里。

那时候我以为是模型能力不够，于是开始逐个替换模型。图表上怎么显示的呢？我整理了一份内部测试数据，用 20 个真实开发任务去测不同模型：

当时我就傻眼了：换了个所谓“更强”的模型，通过率只提升了 3 个百分点，但修改比例反而更高。问题根本不在于模型语义理解，而在于我们根本没给模型足够多的“上下文”——需求背景、技术约束、代码风格、相关模块的既有实现，一样都没给。把一句话“做个分页”丢给哪个模型，它都只能靠猜，而猜得越自信，代码越难改。

1.2 模型间差异远小于上下文管理的差异

为了验证我的猜测，我做了另一个实验：同样两个模型，分别在“一句话需求”和“完整上下文+范例”两种条件下执行同样的任务。结果非常惊人：

模型 A 和 B 之间只有 3~4 个百分点的差距，但上下文管理做与不做，直接带来 30~40 个百分点的差距。也就是说，把两个模型都配上好上下文之后，A 和 B 的最终表现几乎一样。这个实验让我彻底明白：在真实企业环境里，模型的选择只是“买彩票”，而上下文管理是“改中奖率”。从那天起，我把重心从“换模型”搬到了“怎么喂信息”上。

2. 模型强不强只决定上限，上下文管理才决定能不能落地

2.1 一个需求拆解错误，再强的模型也白搭

很多团队推 AI 编程失败，不是因为 AI 不行，而是因为需求拆得不行。你以为你在“用 AI 写代码”，实际上你在让 AI 当一个听不懂需求的新人。新人需要什么？需要一份包含背景、验收标准、技术约束、受影响文件、参考实现的工单。

举个例子：我们做“登录功能”，如果只告诉 AI“做登录”，它会给你搞出各种流派：有人用 session，有人用 JWT，有人把密码明文存。但如果你告诉它“本模块使用 Spring Security + JWT，密码使用 BCrypt，登录接口位于AuthController.java，前端使用 XHR 而非 axios，参考项目内OrderController的异常处理风格”，它产出的代码基本就能直接跑了。这里的关键是：不是模型听不懂，而是你给的信息量根本不足以支撑它做决策。

所以我把“需求拆解”当成了 AI 编程的第一步。具体来说，在需求下发前，必须把开发任务拆成一个个可以独立验证的小任务，每个任务包含三块：用户故事（谁要什么）、验收标准（怎样算完成）、技术约束（必须用什么、不允许用什么）。拆得越细，模型出错概率越低。

2.2 本地代码索引加检索增强，才是团队 AI 编程的隐形杀手锏

如果说需求拆解是“喂好入口”，那代码库索引就是“喂好背景”。我们的项目代码总量大约 150 万行，里面还有很多历史包袱。AI 模型训练时根本不可能见过这些私有代码。你如果不给它看，它就只能根据公开语料“脑补”出一个完全不存在的最佳实践。

我尝试过两种方式：

第一种是“手动拼上下文”。每次写代码前，让工程师自己把相关接口、上一版本的实现、数据库迁移脚本都贴给模型。这种方式有效，但太累，大家很快就嫌麻烦放弃了。

第二种是“搭建代码知识库”。我把项目的模块结构、接口定义、数据库表结构、常见模式全都提取出来，转成向量索引，然后用一个简单的检索器，在生成代码前先把相关的代码片段注入到 prompt 里。这样 AI 就能看到“项目里已有的东西”，而不是凭空造。我们跑了两周，AI 生成的代码里引用不存在的函数的次数下降了 70% 以上。

这个思路和现在比较火的 RAG（检索增强生成）是一个原理：模型本身的知识是一回事，但它读不到你项目的“记忆”。你帮它把这些记忆喂到嘴边，它就能从“瞎猜”变成“照着写”。这件事巴菲特有句名言很贴切：“最重要的不是能力，而是你的工具箱里有什么工具。” AI 的模型就是能力，你的代码库索引、项目规范、历史提交，才是它真正能上手的工具箱。

2.3 让 AI 记住团队规范：从写小作文到写公约

一开始我们还犯过一个典型错误：把团队规范写成一两千字的长文，塞在每个 prompt 里。结果模型要么忽略，要么被后面更长的上下文给冲掉。后来学了乖，把规范浓缩成一份AI_CONTRIBUTING.md，只保留 8 条硬规则，比如：

• 禁止引入现有项目中不存在的第三方依赖，除非你在方案里明确说明替换理由；
• 所有数据库操作必须通过仓储层，禁止直接在 Controller 里写 SQL；
• 每个新增方法必须有单测，测试用例覆盖正常、异常、边界三条路径；
• 接口返回结构必须遵循{ code, message, data }规范，禁止直接返回裸对象；
• 错误日志必须包含上下文变量的关键值，禁止只打“failed”。

然后我们写了一个小插件，每次请求 AI 前自动把这个公约注入到 system prompt 里。效果立刻不一样。因为公约很短，模型能记住，而且每条都是可检测的硬性要求。这给了我一个启发：与其写一大堆“请遵循业界最佳实践”的空话，不如列几条能被 CI 直接检查的具体规矩。人的规范如果模棱两可会导致争执，AI 的规范如果模棱两可会导致混乱。

3. 把提示词工程当项目做，中等模型也能干好活

3.1 任务拆解：大需求变成 AI 能吃掉的小块

提示词工程不是教 AI 说“请”和“谢谢”，而是一种结构化的接口设计。我们经过无数次翻车后，总结出一套“四明治”模板，现在团队里所有人共用：

【任务】实现用户信息修改接口，支持修改昵称、头像、密码。 【背景】项目基于 Spring Boot 3.x，MyBatis Plus，已有 User 实体和 UserMapper。 【约束】不允许新增数据库表；密码修改必须校验原密码；昵称长度 2-20 字符。 【参考】参考 OrderServiceImpl 的风格，DTO 使用 MapStruct，异常使用 BusinessException。 【验收】单测覆盖正常修改、原密码错误、昵称超长三种情况。

这套模板看着简单，但效果出奇地好。原因在于：模型其实是“信息饥渴”的，你让它凭空写，它只能靠概率；你给了约束，它就变成在一个很小的空间里搜索最优解，轻易不会跑偏。我做过一个统计，用四明治模板后的 AI 生成代码，一次性编译通过率从 29% 提到 56%，合入后修改比例从 71% 降到 43%。

3.2 给模型“边界和范例”，比夸模型更管用

网上很多人写提示词喜欢“让我想想”“一步一步来”之类的“咒语”，但我在实际企业场景里发现，真正用处最大的两样东西是：边界和范例。边界告诉 AI“你不能做什么”，范例告诉 AI“你应该长什么样”。

举个例子：

• 低效写法：“你是一个专家，请帮我写一个优秀的登录模块。”
• 高效写法：“现有项目使用 JWT token，过期时间为 24 小时，登录成功后返回 token 和用户基本信息。禁止使用任何外部缓存。参考下面的登录接口写法（贴一段现有代码）。”

边界的作用是防止 AI 自作主张引入新概念。范例是给模型一个“坐标”，让它模仿而不是原创。我们很多工程师写 prompt 时特别喜欢给 AI“画大饼”，什么“以高质量、可维护、可扩展著称”，这些空洞的形容词对 AI 来说毫无意义。相反，你给它一个它必须遵守的“不允许”清单，再给它一段“这就是本项目标准写法”的范例，比你说十句“你很强”都管用。

3.3 提示词模板的版本管理：我们搞了个“提示词仓库”

随着模板越用越多，我们发现一个尴尬的问题：每个人都在微调自己的提示词，有的有效，有的无效，但没人知道哪个更好。于是我们干脆把提示词当成代码来管，放进 Git 仓库，目录结构大致是：

prompts/ common.md # 团队公约，自动注入 backend.md # 后端任务模板 frontend.md # 前端任务模板 bugfix.md # 缺陷修复模板 refactor.md # 重构模板 code-review.md # AI 评审模板

每个模板里都有变量，比如{task}、{background}、{constraints}、{examples}。工程师在 IDE 里通过一个小工具选择模板，填入变量，就能渲染出完整 prompt。这个做法的最大收益是：好的提示词可以像代码一样被 review、被迭代、被复刻。我们后来把团队里最容易出效果的提示词沉淀成了“黄金三件套”，新人来了不用自己摸索，直接套模板就能上手。这比任何模型选型都重要——因为模型的能力是固定，而模板是可以在团队里持续演化的。

4. 选型不是选分数，而是选约束下的最优解

4.1 评测分数和真实代码质量之间的“温差”

网上天天有人晒 SWE-bench、HumanEval 分数，一开始我也迷这些。后来发现，这些评测题跟真实企业代码库是两个世界。公开评测题通常是自成体系、有标准答案的小任务，而企业代码往往有一堆历史包袱：老旧的依赖版本、绕不清的模块耦合、隐式的业务规则。一个在 benchmark 上排第一的模型，到了你项目里可能因为不知道“这个项目所有金额字段单位都是分”而写出错误代码。

我们内部做过一次“盲测”：选了 10 个模型，在 15 个真实来自业务线的任务上对比产出，结论是——排名和公开评测完全不一样。有在 SWE-bench 上拿高分的模型，在我们这儿因为上下文窗口处理不好，频繁忘掉前面的约定，产出质量反而垫底。所以我的建议是：不要迷信榜单，要做“基于你自己代码库的评测”。挑几个有代表性的需求，带上你们项目的文档、代码做对比测试，这才是最靠谱的选型方法。

4.2 成本、延迟、数据安全：企业 AI 编程的三道紧箍咒

在企业里推 AI 编程，你会发现决定模型能不能用的不只是“效果”。还有三样东西：成本、延迟和数据安全。

• 成本：一个中型团队一个月用云端 API 的 token 费，动辄上万。如果不做缓存和预算控制，财务第二天就来找你谈话。我们的做法是做一个轻量网关，按任务类型控制 token 上限，对重复请求走缓存，减少绝对调用量。
• 延迟：很多编程助手为了追求“聪明”，会进行很长时间的思考。结果工程师坐在那儿等 1 分钟，烦躁得不行。实际体感上，3 秒内出能用的代码，比 10 秒后出“完美”的代码更受欢迎。
• 数据安全：企业的代码就是命根子，不能随便丢给云服务。尤其涉及核心业务逻辑，合规直接禁止外发。所以私有化部署或本地模型成为必然选择。

我把几个选项列成了表：

综合这三点，你会发现很多单纯“跑分高”的模型直接被淘汰了。我们最终选择的是一个私有化部署的中等模型加上云端强模型的组合：普通任务走本地，难任务才走云端。这样成本、延迟、安全都控制住了，效率也不错。

4.3 Cursor、Copilot、Windsurf、Trae：我们最终留下了什么

工具这一层，也值得跟大家聊聊。我们团队试过 Cursor、VS Code Copilot、Windsurf 和 Trae，各有各的脾气：

• Cursor：多文件编辑和上下文感知很强。它能全局理解项目，边改代码边对标架构，适合做“重构”“跨文件改动”这类任务。
• VS Code Copilot：IDE 集成最稳，提示速度最快，适合日常写函数、补注释这些轻量场景。但复杂任务容易犯“只增不改”的毛病。
• Windsurf：Agent 模式做自动化长链路任务很爽，比如“跑一遍测试再修问题”。不过需要比较强的约束，否则它会自己给自己加戏。
• Trae：个别人试用觉得够用，但深度和稳定性暂时弱一些，适合入门级尝鲜。

最后的结论是，工具只是外设，最重要还是你在它背后怎么组织上下文。我们目前采用的是：Cursor + 私有化本地模型作为主力，配合自建的代码索引和提示词仓库。Copilot 留给喜欢轻量使用的同事。真正让我们效率起来的不是某个编辑器，而是“无论用什么工具，大家都遵循同一套上下文规范”这件事。

5. 比模型更值钱的非模型基建：测试、评审、度量

5.1 给 AI 代码装上“测试安全网”，敢写才敢放

AI 写代码的速度之快，一开始让我非常兴奋，但也很快让我非常害怕。因为没人 review 的情况下，AI 可以一个小时产出几千行“看起来正常但实际跑不过”的代码。而且它会非常自信，你觉得它好像理解需求，其实它只是在做“高级的复读”。

我们的解法是：一切都靠测试说话。强制要求 AI 生成的代码必须附带单元测试，并且这些测试必须本地跑通才能提 MR。这个做法有两个好处：第一，AI 给自己写的代码补测试，等于让它自证清白，很多逻辑错误会在测试设计阶段暴露；第二，人 review 的时候不用一句句猜 AI 想干嘛，直接看测试就懂它接住了哪些约束。

有一次一个工程师让 AI 实现“金额字段千分位格式化”，AI 写得天花乱坠，但测试用例里漏掉了“负数和带小数”的边界。我们加了这两条测试后，代码马上就炸了。后来我们索性准备了“必测清单”，让 AI 生成的测试必须覆盖正常、异常、边界三种情况，否则不 pass。这个安全网让我们的合入灾难降了大概七八成。

5.2 代码评审的新玩法：AI 先审，人再审

有了安全网还不够，因为测试只能覆盖“你想到的”，Review 才是人工兜底。但我们面临的问题是：代码提交量巨大，人工 review 根本看不过来。后来我们建了一个“AI 评审 agent”作为第一道关卡。

具体流程是这样的：AI 提交代码后，先跑一个评审 agent，用固定的 review 模板检查静态问题，比如：

• 有没有未使用的变量或导入？
• 有没有吞掉异常但是没有记录日志？
• 有没有绕过仓储层直接访问数据库？
• 有没有把密码、密钥硬编码到代码里？

AI 评审通过之后，再把代码推给人类 reviewer。人类不再花时间挑拼写错误和格式问题，把注意力放在“这个设计符不符合模块职责”“接口抽象是否合理”这些大问题上。人机分工明确后，PR 的平均 review 时间从 2.5 天降到了 0.8 天，而且团队成员普遍觉得没那么累了。

当然 AI 评审也有它的局限性——它判断不了业务的“语义正确性”，更不知道产品经理的真实意图。所以我们并不指望它能替代人，它只是一个“高效筛子”，把低层次问题先筛掉，让人能把时间花在最值钱的地方。

5.3 度量与反馈：用数据看 AI 到底有没有提效

最后，我们建立了一套非常轻量的度量体系，用来回答“AI 编程到底提升了什么”这个问题。我们不玩虚的，就看四个数字：

这些数据说明一件事：AI 编程确实带来了明显的效率提升，但这个提升不是“因为模型聪明”，而因为我们把上下文管理、测试安全网、评审流程都做对了。我们甚至做了个横切分析——发现团队里那些把模板用得很溜的人，他们的产出改善是其他人的两倍。这和用什么模型几乎没关联。

所以度量不是为了给报表好看，而是为了告诉我们下一步该优化哪里。如果你现在只是觉得“AI 写代码很快”，但没有度量，后续的优化就是拍脑袋。

6. 如果你想在团队里推 AI 编程，先别急着换模型，先做这六件事

一年走来，如果让我把经验浓缩成六条可以直接抄作业的建议，那就是：

1. 先把团队规范浓缩成一条条可检查的规则，写进AI_CONTRIBUTING.md，而不是长篇大论。
2. 搭建代码索引或者至少做一个代码摘要工具，让 AI 写代码前“看见”你的项目里已经有什么。
3. 统一提示词模板，放进 Git 里管理，像代码一样 review 和迭代。
4. 强制测试先行，AI 生成的代码必须带测试且跑通，否则不让提交。
5. 做一个小规模选型评测，用你们自己的真实任务，而不是看公开跑分。
6. 设一个度量基线，从开发时长、合入修改率、回滚率去判断，不要光凭感觉说“好用”。

在企业里推 AI 编程，终究不是“选一个最强的模型”那么简单。它是一个把工具、流程、规范和人的习惯重新揉合在一起的过程。模型的能力确实一直在涨，但决定你团队效果的，往往是那些看起来一点也不“AI”的琐碎工作：把需求拆明白、把规范列清楚、把测试跑起来。

所以如果你正准备在团队里推开这件事，我的建议是——别先去抢购最强模型的订阅，先坐下来跟团队写一份“AI 公约”，把你允许它做什么、不允许它做什么写清楚。然后把第一个需求拆成最小任务试一试。等你发现模型换什么都能稳定产出，你就知道，你已经摸到 AI 编程真正的那道门了。