研发大模型全面落地实践：从选型部署到代码生成与私有化

1. 研发大模型从“尝鲜”变成“全员标配”，我是怎么感受到的

1.1 从辅助补全到全流程参与，研发节奏确实变了

先说一个我最近的个人观察。以前聊AI写代码，大家第一反应都是“补全注释、续写函数”，我觉得那只是效率工具，谈不上改变研发模式。但今年不一样了，横跨好几个项目组看下来，研发大模型已经不是部分人拿来玩的玩具，而是全体开发人员日常工作的默认底座。代码编辑器里有自动补全，命令行里有智能体，代码评审时有AI预审，连需求拆解也有人把用户故事直接丢给模型去生成初步方案。

最直观的变化是在需求到代码这条链路里。过去一个迭代从需求澄清到代码入库，全小组坐下来开评审会，至少得消耗大半天。如今很多开发者习惯先把需求描述、接口文档和已有代码结构喂给大模型，让模型产出一版结构相对完整的代码草案，大家再在上面做修正和评审。覆盖面稍微广一点的团队，还会把测试用例生成、数据库索引建议、日志埋点规范检查这些原来靠人工经验判断的环节，一并交给模型预处理。所谓“全面覆盖”，在我看不是某一家公司的口号，而是开发日常中可量化的变化：代码仓里由模型生成或辅助生成的片段占比越来越高，很多同学每天打开IDE后的第一动作已经从“查文档”变成“问模型”。

当然，覆盖加深不代表模型真的能独立交付整个业务。真正有价值的用法是把大模型当作一个理解能力很强的初级工程师，它可以快速给出候选方案、补齐重复细节，但最终方案的选择、代码质量和业务正确性责任还在人类身上。理解了这一点，下面所有关于选型、部署和使用技巧的讨论才有了基础。

1.2 大模型为什么能理解代码，而不是在“背代码”

不少非算法背景的前端后端朋友问过我同一个问题：这玩意儿凭什么能根据一句注释写出完整函数，而且偶尔还能考虑边界条件？我一般会用一个类比去解释：大模型训练时“读过”的代码量相当于一个程序员每天看一万行代码、连续看几百年才能看完的语料，它未必记得每一行字，但通过不断预测下一个token，它在参数里形成了代码的统计规律。

用一个生活中的经验帮助理解：你听一个老外用中文说了大量错句，久了以后你即便不懂语法，也能大概感觉出哪句话“念着不对劲”。大模型对代码的理解就类似这种“语感”，它从几十亿行代码里学到了缩进、命名、函数调用、异常处理的常见模式，于是当用户给出任务说明时，模型其实是在参数空间里检索最靠近这个任务意图的代码模式，再组合出一段看起来合理的结果。之所以它能跨语言完成重构，是因为代码本质上是一种有规律的结构化文本，很多设计思想在不同语言里是相通的。

更重要的锦上添花是在通用预训练之后，研发大模型都做了指令微调和代码专项训练。也就是说，它们不只是会续写，还能根据明确指令去区分“生成代码”和“解释代码”，能够遵循诸如“不要修改兼容层”“只输出JSON格式”之类的约束。训练语料里如果混入了大量高质量的Pull Request、开源文档和代码问题解答，模型对“什么样的代码才算专业”也会有更好的判断。

基于这套原理可以推导出一个重要的操作结论：想让大模型写得好，必须把上下文给足。模型不是一个凭空变知识的魔法箱，它输出质量严重依赖用户提供的类名、函数签名、项目结构和错误信息。很多说“大模型不好用”的人，多半是打开一个空白文件，直接扔一句“写一个订单系统”，这种过于开放的任务换谁来都写不好。

1.3 “全面覆盖”只能说明工具红利来了，不能说明风险消失了

这是我最想强调的一点。大模型在全体开发者中铺开以后，代码的产出速度确实变快了，但代码的“可信度”不会自动变高。以我实际遇到过的情况为例：让模型生成一段日期处理函数，它能在一分钟内写完，看似格式规范，但用到不同时区的测试用例时，边界条件处理可能是错的。为什么？因为模型更擅长生成“看起来常见”的代码，而不擅长逻辑实证。

“看起来常见”意味着模型倾向于输出语料中出现频次最高的写法，而不一定是最符合当前项目约定的写法。如果你的代码库使用的是自定义错误码体系，模型默认返回的可能就是另一个项目里常见的错误码类型。同样，它可能参考了旧版本依赖库的API，导致你在升级过程中踩到已被移除的方法。这类问题的本质是“统计性生成”和“确定性正确”之间的矛盾，它不会因为模型参数变大而彻底消失，只是概率性降低而已。

所以在推广研发大模型时，一定要配套两条基本制度：第一，所有AI生成代码要纳入普通代码评审流程，不能产生“因为是AI写的所以没问题”的错觉；第二，凡涉及支付、权限、数据删除等敏感逻辑，模型只能提供草案，不允许自动化合入生产分支。这听起来保守，却是让“全面覆盖”持续下去而不是变成“全面返工”的关键。

2. 研发大模型的选型与部署：从几个人的玩具到几十人共用的服务

2.1 闭源API、开源权重和本地部署，究竟怎么选

现在市面上的研发大模型选择非常多，先不谈具体的模型名，我给团队做调研时通常先把选择分成三大阵营：闭源API、开源权重部署、私有化微调服务。它们各有非常明确的适用场景，不存在谁一定更好的说法。

闭源API的最大优势是省事和模型能力上线快。你不用买显卡、不用处理推理框架、不用操心模型版本升级，只要把代码交给外部服务，通过API拿回结果。对于大多数中小企业、创业团队以及个人开发者，这是一个成本极低的起步方式，开箱即用，而且很多顶级模型的代码能力确实比同参数规模的开源模型更强。闭源API的主要顾虑是数据和隐私成本：如果公司代码本身保密级别较高，或者有合规要求不能把代码片段发送到外部接口，那闭源API这条路就得慎走。

开源权重模型看重的是可控性。你可以把模型部署在自己的内网服务器上，代码数据不离开公司边界，还能按需修改推理策略和量化等级。近年来的开源模型进步非常快，一些专门面向代码场景的中小尺寸模型，在常见编程任务上已经能逼近甚至达到商业模型的水平。开源的另一层价值是可审计，你清楚地知道模型是什么架构、训练数据大概从哪来，这在做内部风险评估时特别重要。

本地部署则再往下一层：不仅模型权重可控，连资源环境也完全自持。对于只有一两台带GPU服务器的小团队，本地部署研发大模型可以把成本变成固定支出，长期高频调用时能明显降低API费用。它的问题是运维门槛上来了，你需要处理显存、推理加速、多用户并发甚至自动扩容。我见过不少团队兴致勃勃买了服务器，结果模型加载完以后QPS跑不上去，最后又退回API方案，这属于没有提前评估资源。

选型的实际判断标准，我建议按优先级看三点：

• 代码数据是否允许出域；
• 团队是否有GPU资源和推理运维能力；
• 调用频率和峰值QPS是否高到需要自建服务。

把这三点列成表格先打分明，基本就能排除掉大部分错误选项。很多团队是从API开始验证效果，等确认高频场景后再把本地部署补上，这个演进路径本身也很合理。

2.2 我用Ollama在本地快速跑起代码模型的完整记录

先说明：我是Ollama的重度使用者，因为它真的做到了“本地大模型部署低门槛”。你要做的事非常简单：安装Ollama，然后用一条命令拉取模型，再调用API就行。

以常见的代码模型为例，我经常给团队演示的是sper这类模型，这里用目前很主流的Qwen2.5-Coder系列来演示。假设你电脑上已经装好Ollama，只需要在终端执行：

bash复制ollama pull qwen2.5-coder:7b

下载完成之后，直接执行：

bash复制ollama run qwen2.5-coder:7b

就能进入一个交互式命令行，问它怎么把Python的列表按字典某个字段排序，或者让它解释一段你粘贴进来的老代码。

如果要在IDE或脚本里调用Ollama，它默认会监听127.0.0.1:11434这个本地端口。比如用curl测试：

bash复制curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5-coder:7b",
  "prompt": "用python写一个判断闰年的函数",
  "stream": false
}'

很多代码编辑器插件都支持配置自定义的OpenAI兼容API，把BaseUrl指向http://127.0.0.1:11434/v1，这样就可以在IDE里使用本地模型做补全和聊天。

实操过程里，内存和显存是最大瓶颈。以7B模型为例，量化后大约需要5GB到6GB的磁盘空间，推理时还需要至少8GB的内存。如果只有CPU跑，速度会偏慢，但做日常补全和短问答勉强能接受；如果本机有一块8GB显存的显卡，生成速度会明显改善，体验会流畅很多。

这里有一个非常容易踩的坑：Ollama默认只对本机访问开放，如果你想让局域网里其他同事的机器连接到这台服务器，需要在环境变量里设置：

bash复制OLLAMA_HOST=0.0.0.0:11434

另外，现在前端插件在浏览器或Electron环境里调用本地模型时经常会遇到跨域问题，此时需要设置：

bash复制OLLAMA_ORIGINS=*

这两个环境变量一定要在启动Ollama之前配置好。我第一次给同事分享本地模型时，就是因为没有配置跨域，导致IDE插件一直连不上，排查了快半小时才发现是浏览器层面的限制，这个经验特别值得提前记住。

2.3 从原型走向生产：要不要上vLLM

如果你的团队不是个人实验，而是打算把模型服务提供给部门几十个开发人员一起使用，那么Ollama这种轻量方案大概率扛不住高并发。原因是Ollama针对“单机小规模交互”做了优化，但在动态批处理、显存管理、吞吐量优化上不如专业推理框架。我在生产环境里用到更多的是vLLM，它在大并发和长上下文场景下的吞吐量提升非常明显，有时是数量级的差距。

vLLM的技术优势主要有几个：它会像公共汽车一样把多个并发请求攒在一起批量处理，充分利用GPU算力；它通过一种类似虚拟内存的显存管理方式，大大减少显存碎片浪费；它支持常见的量化模型和分布式推理，方便扩展到多卡。用命令行方式部署一个OpenAI兼容服务非常直接：

bash复制vllm serve Qwen/Qwen2.5-Coder-14B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9

这样启动后，同一个局域网里的开发工具，只要把BaseUrl配置成http://服务器IP:8000/v1，填入一个任意值的API Key（因为本地服务通常不校验），就能像调用OpenAI接口一样使用本地模型。对于团队内部的一些工具脚本，可以直接复用大量已有的OpenAI SDK，迁移成本很低。

用vLLM部署时要注意显存预算。所谓“模型最大长度32768”，并不是每个请求都占满这些上下文，但系统会预留一整块显存给KVCache，如果设置过大会导致模型本身加载失败，设置过小又会频繁截断。我通常的做法是先按模型参数大小估算一下，再结合显卡实际容量调整。例如一张24GB的显卡部署14B模型，如果量化成INT8或者AWQ 4-bit，显存占用会低不少，但会牺牲一定的精度，需要先用几个关键用例对比再决定。

把vLLM接入Kubernetes集群自动伸缩是更大的话题，但基础逻辑不复杂：模型服务本身是无状态的，通过扩缩容副本数来应对请求量变化。为了让多个副本共享排队状态，一般会在前面加一个负载均衡层。如果团队人手不够，第一版不必做得很复杂，先在一台GPU服务器上把vLLM服务跑稳，后续再接自动伸缩即可。

3. 把大模型揉进研发日常：我最喜欢的高效用法和模板

3.1 注释驱动开发：让模型先照着你的思路写

很多人只知道“让AI补全当前行”，其实更有效的入门用法是我叫它“注释驱动开发”的方式。不要直接让AI从零生成一个完整的函数，而是你先在代码里用注释把逻辑拆成明确的步骤，再让模型逐步补全。我可以举一个很常见的例子：

java复制/**
 * 校验用户输入的邮箱格式
 * 1. 如果为空则返回 false
 * 2. 用正则校验基本格式
 * 3. 校验后反转义处理 + 检查域名后缀是否在允许列表内
 * 4. 不允许出现连续两个点
 */
public boolean isValidEmail(String email) {
    // 请实现上述逻辑
}

当开发者在IDE里把光标放在方法体里并触发AI生成时，模型可以按照注释里写好的步骤输出实现。这种做法的好处是代码逻辑的裁决权仍然在你手里：万一模型实现到第三步偏了，你直接调整注释顺序就能得到不同结果，不会陷入无休止的对话重写。

这个方法能生效的前提是：必须把“边界条件”写清楚。如果你只写一句“校验邮箱”，模型大概率会给出一个简单正则，覆盖不到实际业务里的反垃圾规则和域名白名单。开发者要做的是把约束条件“说出来”，而不是期望AI读心。

3.2 CLI Agent才是真正吃掉重复劳动的利器

如果说注释驱动开发只是把模型当高级补全，那么基于命令行的编程Agent则直接改变了个人研发闭环。例如当前很受关注的Claude Code、Codex CLI，还有国内一些团队封装的智能体工具，它们能做的不只是回答问题，而是真正在项目目录里读文件、改文件、执行测试并观察结果，形成“提出任务—执行—反馈—修正”的循环。

我自己的典型使用场景是这样的：在确保git工作区是干净且位于独立分支的前提下，在项目根目录启动CLI工具，然后输入类似这样的一段话：

“请完成用户登录接口的重构：现有LoginController里的密码校验逻辑有问题，需要改为先查询用户状态，再校验密码哈希，成功后写入登录日志。请不要修改数据库表和redis key相关逻辑，补全单元测试，然后运行mvn verify直到通过。”

CLI Agent收到指令后，会先扫描工程结构，找到LoginController和相关依赖，然后按步骤修改若干文件，还会自动运行测试。只要前期把“不许动的范围”写在指令里，整个过程基本不需要人工干预。执行完之后，我再通过git diff逐行检查改动，确认没有越界后才提交。

在这个过程中，我发现一个特别重要的心得：不要让Agent直接在主干分支上飞。有些工具默认会帮你建临时提交，但为了保险起见，我会先切到一个feature分支再调用Agent。万一模型发生“灾难性误操作”，你只需要撤掉一个分支，而不用处理一堆已经被覆盖的文件。

另外，CLI Agent是把“可执行命令”交给模型使用的，这天然引入了安全边界问题。至少要有两个动作：第一，限制Agent能执行的命令白名单，比如只能运行构建、测试、git diff等命令，不要允许随意的shell操作；第二，在交给Agent执行敏感操作前，把本地代码备份或者打一个临时commit，做到可回滚比功能本身更重要。

3.3 代码评审和单测生成：先把重复劳动外包出去

研发日常里有两件耗时但模式化严重的事情：Code Review初筛和单元测试编写。这两个场景非常适合用研发大模型来“包前置”，但多数人没找到正确姿势。

先聊单测生成。直接选中一个方法让AI生成单测，通常能得到一张勉强能跑通的用例，但质量参差不齐。我的做法是先把方法的关键业务规则写到Prompt里，并强制提测用例覆盖正常路径、边界输入、非法输入和异常抛出四个维度。比如：

“请为PaymentService.pay()函数生成JUnit测试用例。要求覆盖：余额足够时正常扣款、余额不足时报错、重复支付请求幂等返回、userId为空时抛出异常。请使用Mockito隔离外部依赖，不要生成网络请求。”

这样告诉模型“有哪些分支要测、用什么测试框架、不要做什么”，产出的单测依然需要人工确认，但覆盖度比我简单说一句“写个测试”要高出一大截。

再看代码评审。我目前推荐的做法是不要直接把整个代码库或超大PR扔给模型，它处理起来又慢又容易淹没重点。更好的方式是做“分层预审”：先让模型只关注某几类高频缺陷，例如空指针风险、资源未关闭、并发场景下的原子性问题、错误信息是否包含敏感信息，然后让模型以评论列表的格式输出。人工Reviewer拿到这个列表后，再针对风险项逐条确认。

有些工程会直接把AI评审机器人和CI集成，让它对每个新提交自动生成审查意见。这里要警惕的是，AI给出的“问题”有时是伪问题，可能是它误读了上下文。所以机器人生成的评论不会自动“Request Changes”，而只是以普通评论的方式提醒，保证最终的话语权仍然属于人类。

3.4 一套通用研发提示词模板，覆用率很高

总是有人问提示词该怎么写，其实研发场景的提示词没有那么神秘，我总结了一个最简公式：角色 + 任务 + 上下文 + 约束 + 输出格式。

角色用于限定视角：例如“你是一名有十年经验的后端工程师”。任务要写清楚产出：是编写代码还是解释代码，还是检查代码。上下文要尽量粘贴真实代码片段、报错日志、项目结构，上下文越具体，模型回答越不飘。约束用来划红线：例如“不要改变现有数据库结构”“只能使用JDK8的语法”“不要引入新依赖”。输出格式则是给结果规定结构：例如“先给出方案，再给出代码，最后列测试用例”。

我来给一个通用示例，这个模板在小规模代码生成场景里几乎可以复用：

code复制作为团队里的资深Java工程师，请帮我实现一个spring boot接口方法。
任务：根据userId查询用户最近10条登录记录，返回脱敏后的展示数据。
上下文：现有UserLoginRecordMapper提供findByUserId(Long userId)方法，
返回List<UserLoginRecord>，字段包含userId、loginTime、ip。
约束：
1. 不得修改Mapper和数据库表结构。
2. 使用的脱敏规则只需要对IP后两段打码。
3. 返回结构用Map即可，不需要单独建DTO。
输出格式：
先分析存在的安全风险，再给出完整方法代码，最后列出需要人工补充的测试用例。

这样写，模型的输出基本上不会偏离太远。核心原则是：你以为AI知道你的项目上下文，它其实不知道；除了你主动贴进去的内容，其他全是它的猜测。所以项目里的依赖版本、变量名、特殊规范，只要影响输出结果，就都应当写进Prompt里。

4. 私有化落地的最后一公里：微调、RAG与API封装

4.1 先别急着微调：什么时候才值得动权重

团队一旦开始认真使用大模型，就会有人提出：“我们的代码规范太特殊，通用模型写不准，能不能微调一个专属模型？”我的答案是：再等一等，先看能不能用RAG或工程手段解决。因为微调研发大模型不是点一下按钮，它涉及数据准备、算力消耗、评测回归，以及后续模型版本迭代的成本，很多团队在这个环节投入产出比很低。

那什么情况下才真的需要微调？我认为主要有三类。第一类是模型需要学习一种强规则格式，例如公司内部自定义的接口协议、字段命名规范或代码生成模板，规则太新或太少见，模型靠提示词很难一次学会。第二类是模型需要掌握某些私有框架的API知识，而框架文档又不适合塞进每次请求的上下文里；这种情形先用RAG可能还勉强能应付，但如果调用非常频繁、每次都要检索出大量API文档，微调确实可以降低推理开销。第三类是业务需要对同一类任务做大批量自动化生成，例如把自然语言的需求转成特定领域的知识图谱实体抽取，这种任务结果可以批量标注，也方便建立评测集，适合微调。

做微调之前，我强烈建议先做一套不少于200条的良好标注数据，包含输入指令和期望输出。这些数据不用追求数量惊人，但质量必须非常高。你喂给模型的数据决定了它之后会养成什么输出习惯，如果标注数据里本身就存在错误，微调后的模型也会把错误当成“规律”。

真正的实操里，用LoRA这类参数高效微调方法来处理研发场景已经足够。它会冻结原模型的大部分参数，只训练一部分适配器权重，使得基础能力不被破坏，同时能学会你想强调的格式和风格。微调完成后的评估尤其关键：不能用训练集来自我陶醉，要留出10%到20%的样本做盲测，还要选一批与训练无关的通用任务看模型有没有“灾难性遗忘”。

4.2 用Spring AI搭一个能检索自己代码库的知识助手

前面讲的是模型侧，现在讲工程侧。很多Java团队开始关注Spring AI，本质原因是希望把模型能力嵌入已有的Spring Boot技术栈，而不是在业务系统旁边单独维护一套Python服务。

借助Spring AI，你可以写一个很薄的应用层。由于本地通过vLLM或Ollama启动的推理服务基本都提供OpenAI兼容接口，因此Spring AI天然可以对接它们，配置文件大致是这样：

yaml复制spring:
  ai:
    openai:
      api-key: local-not-needed
      base-url: http://127.0.0.1:8000/v1
      chat:
        options:
          model: qwen2.5-coder-14b-instruct
          temperature: 0.2

然后注入ChatClient，就能在业务代码里发起对话：

java复制@Service
public class CodeAssistantService {

    private final ChatClient chatClient;

    public CodeAssistantService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String explainMethod(String sourceCode) {
        return chatClient.prompt()
                .system("你是一名Java代码讲解专家，请用简洁中文解释代码逻辑。")
                .user(sourceCode)
                .call()
                .content();
    }
}

这只是最基础的部分。真正有研发价值的是在服务里串联一套“代码检索增强”流程：先把代码片段或项目文档切片后向量化存到向量数据库，等用户提问时先召回相关的代码片段，再把片段与问题一起组装进Prompt，让模型基于召回结果回答。这样模型不需要记住整个代码库，也能做到针对具体项目回答，而且每次代码更新后只要增量刷新向量索引就行，不需要重新训练模型。

Spring AI对这些能力做了抽象，可以集成本地向量存储，也可以对接外部向量数据库。实操要点是切片策略：按函数或类进行切片通常比按固定字符长度切片更好，因为后者会把代码拦腰截断，导致召回的内容不完整。

在把这种助手开放给团队之前，建议先做一层校验逻辑：如果召回结果和相关度分数低于某个阈值，就直接回答“当前项目里没找到相关代码”，不要硬编答案。研发助手最怕的不是说“不知道”，而是伪装成知道然后给出错误结论，这种假自信会破坏开发者的信任。

4.3 大模型研发平台必须做的可观测性和成本治理

开发人员一旦把大模型当作日常基础工具，那么“全面覆盖”背后的资源消耗就不是一个小数目了。我见过不少团队在试用期嗨得飞起，月底拿到账单时傻了眼。所以自建或者采购研发大模型服务，请务必提前做好三层可观测性。

第一层是调用日志。要记录是谁、在哪个环节、调用哪个模型、输入了多少字符、输出了多少字符、耗时多少。这样一旦出现生成质量投诉，可以重现当时的上下文，而不是拿“模型问题”一句话搪塞过去。

第二层是成本核算。大模型API通常按token计费，而研发场景的请求往往包含大量代码上下文，token消耗量远高于普通聊天。有些模型工具支持会话压缩或上下文裁剪，可以在不明显影响效果的前提下把每次请求开销降下来。我处理团队成本的方法是：把研发助手按场景拆成不同模型档位，简单补全用中小模型，复杂Agent任务才用更大更强的模型，这样既省钱又不牺牲体验。

第三层是质量评测。一个看起来“能回答”的研发大模型，和“真的好用”之间隔着成百上千个真实任务。团队应该把一些稳定的任务沉淀成回归测试集，例如“让模型从中文需求生成一段符合规范的接口代码”，每次更换模型或升级参数后都跑一遍，比较输出质量的变化。没有评测机制的AI集成就是在裸奔，因为你完全不知道模型升级后会不会在某些场景里悄悄退化。

5. 在真实项目里踩过的坑：排查思路与注意事项

5.1 代码幻觉：模型一本正经地给你编出错误API

用AI写代码最让人头疼的问题不是它不会写，而是它写得太像真的了。它可能为你构造一个当前依赖库里根本不存在的类，一个参数顺序弄反的方法，或者一个已经废弃的配置项。因为它对语言规律的把握要强于对“实际依赖版本”的感知，所以在没看到真实代码库时，它不会知道自己引用了不存在的API。

应对思路是不要相信它输出的“import”或“依赖注解”一定对。使用AI生成代码后，一定要让构建工具或测试来“兜底”，如果模型写的代码根本编译不过，那就属于显而易见的幻觉，要把报错信息重新丢回去让它修正。如果编译能通过但运行结果不对，那多半是业务逻辑理解偏差，这时候建议结合单元测试去逐条验证，而不是空对空追问“你确定吗”。

给模型投喂报错日志是一个很有效的做法。你直接把完整的异常堆栈粘贴进去，附上相关代码片段，并问“这段代码为什么在某个条件下会抛出异常”，模型通常能很快指出问题。千万不要只贴一行“为什么报错”，没有上下文，它只能给你猜。

5.2 Agent自动修改代码时，怎么加一道实在的护栏

CLI Agent能读文件、写文件、执行命令，给我带来效率的同时也带来了新的风险管理需求。我自己遇到过的情况是为一个Python项目写重构脚本时，Agent自作主张帮我把requirements.txt里好几个库的版本号都升级了，理由是新版本修复了安全问题，但实际上构建环境不能随便变更这些版本，结果CI全崩。

这个经历的教训是：要让Agent明确区分“什么该动、什么不该动”。在给Agent下任务时尽量写清楚禁止变更的文件清单，比如“不要修改requirements.txt、不要动数据库迁移脚本、只允许改动src目录下与用户注册相关的代码”。能坚持做到这一步，Agent越界概率会明显降低。

其次是权限管控。在终端里给模型工具的直接命令执行权限要克制，更稳妥的方式是让它只能操作你设置的沙箱项目目录。如果是本地开发，至少在一个单独的分支上做实验，并在Agent启动前确保工作区能一键回滚。对“自动提交代码”这个动作更要谨慎，尤其是合入主干分支的操作，无论模型给出多合理的提交理由，都应该由人类触发合并。

5.3 本地部署和集成的常见故障速查表

把常见的故障和解决思路整理成表，可以复制到知识库或Wiki，对团队排查非常有帮助。

顺便强调一个经常被忽视的问题：本地部署模型时要留意模型许可证。不同开源模型的商用授权范围不一样，团队内部使用和对外提供服务，规则也可能不同。确认许可证这件事应该在模型选型时就做，不要等技术方案落地后再去补合规，那样返工成本太高。

另外一个让我印象深刻的故障是，有次我把模型最大上下文长度调得很大，结果QA同学在测试时一次性贴了好几个整文件，请求直接超时。后来才明白，长上下文不是免费的，上下文窗口越大，首token延迟和显存占用都大幅增加。实际落地时应按团队里最常用的代码长度范围来设置，而不是一昧追求“能塞多少就塞多少”。

回到开头那句话，研发大模型能够在全体开发人员中实现全面覆盖，这个趋势我的感受是特别真实的。但我仍然相信，工具本身不会自动带来工程师能力的成长。真正掌握主动权的团队，知道什么时候问模型、怎么给模型上下文、如何为模型划边界，也会在模型给出看似完美的代码时保持“这份代码怎么工作、有什么风险”的好奇心。我自己这几年最深的体会是：大模型可以帮我们把想法快速变成代码，但它没法替我们建立对代码的ownership。保持技术判断力，把它当成一个非常努力、记忆力超群但偶尔会编故事的协作者，很多麻烦都能提前避开。