Codex 本地部署实战：安装、本地模型接入与 config.toml 配置

1. 先搞清楚Codex 在本地跑起来到底意味着什么很多人第一次听到 Codex 本地部署脑子里浮现的是把一个大模型下载到自己电脑上。这个理解偏了。Codex 官方放出来的这套工具本质上是一个跑在终端里的编程助手外壳它自己不携带权重也不做推理真正干活的模型在别处——可能在云端也可能在你自己的显卡上。所谓下载与本地部署其实是两件事捆在一起一是把 Codex 这个客户端装到本机二是把它的请求出口指向一个你自己能控制的模型服务。这两步都走通你也就算是把 Codex 跑通了。我之所以愿意花时间折腾这个流程理由很实在。日常写代码时补全和问答类工具已经很多了但真正能读懂整个仓库、能自己执行命令、能改文件的助手用起来完全是另一种体验。而把这些能力放到本地最大的好处是可控项目代码不出本机模型想换就换额度用完也不用干等。对于有内网开发需求、或者单纯不想把公司代码往外发的团队来说这条路值得走一遍。这篇文章面向的读者分两类。一类是刚接触命令行工具、但对 AI 编程助手有兴趣的新手我会把环境准备、安装、配置每一步都摊开讲包括目录位置和验证方法。另一类是用过类似工具、卡在某个报错上的人比如切换模型后请求一直失败、响应格式对不上、安装到一半中断这些情况后面有几个章节专门处理。你不需要提前懂 Node.js 或者 TOML 配置跟着走就行。需要提前打个预防针整个流程里最容易出问题的不是安装而是配置。安装失败通常一眼能看出原因配置错误则往往表现成卡住了没反应返回一堆看不懂的东西。所以第二部分我会在环境准备上多花点篇幅把地基打牢后面会省很多事。2. 环境准备地基没打牢后面全是坑2.1 Node.js 与 npm版本选择的门道Codex 的命令行版本是通过 npm 分发的所以 Node.js 是第一个必须装的东西。这里有个常见误区很多人随手从某个教程里抄了个老版本 Node 装上结果 npm 安装包时报引擎不兼容。我的建议是直接用 Node.js 20 LTS 或 22 LTS这两个长期支持版本覆盖了绝大多数现代工具链的要求稳定性和兼容性都经过充分验证。安装方式上Windows 用户直接去 Node.js 官网下那个带 LTS 标记的安装包一路下一步就行安装程序会自动把 node 和 npm 加进系统环境变量。macOS 用户如果用 Homebrew一条命令搞定不用 Homebrew 的话官网的 pkg 包同样方便。Linux 用户我更推荐用发行版自带的包管理器装或者用 nvm 这种版本管理工具方便以后切换。装完之后必须验证这一步千万别跳。打开终端敲下面两条命令node -v npm -v正常的话会分别输出类似v20.11.1和10.2.4这样的版本号。如果提示不是内部或外部命令或者command not found说明环境变量没生效。这时候先试试关掉终端重新开一个Windows 下如果还不行就重启一次让系统重新读取环境变量。我在几台机器上遇到过装完不重启死活认不出来的情况别在这上面浪费时间怀疑人生。还有一个坑是权限。macOS 和 Linux 下用npm install -g全局安装时如果 Node 是通过官网安装包装的可能会因为目录权限不足报 EACCES 错误。遇到这种情况不要脑子一热就上sudo那样装出来的包后续升级会很麻烦。正确的做法是重新配置 npm 的全局目录到用户主目录下或者干脆用 nvm 管理 Node从根上避开权限问题。2.2 Git 与终端环境被低估的前置条件Git 在这个流程里扮演的角色比想象中重要。Codex 在执行任务时会读取项目状态、看差异、理解改动范围这些都依赖 Git 仓库信息。如果你的项目压根不是 Git 仓库Codex 的很多能力会直接打折改文件时也缺少回滚的安全网。安装 Git 本身没什么难度Windows 下官网下载安装包安装过程中有个选项是调整 PATH 环境变量建议选中间那个Git from the command line and also from 3rd-party software这样终端里能直接调用。macOS 通常自带敲git --version看一下如果提示要装命令行开发工具点确认等它装完就行。Linux 用包管理器一条命令的事。装完 git 之后有两件小事顺手做了一是配置用户名和邮箱git config --global user.name和user.email各设一下否则首次提交会报错二是把默认分支名设成 maingit config --global init.defaultBranch main省得以后每次都看到 master 心里别扭。终端选择上我个人在 Windows 下更推荐用 Windows Terminal 配合 PowerShell或者直接用 Git Bash。原因很简单Codex 输出的很多内容带颜色和特殊字符老式 cmd 窗口显示会乱。macOS 和 Linux 自带的终端就够用如果想要分屏和搜索方便可以试试 iTerm2 或者 Kitty。2.3 网络与镜像加速让安装别卡在半路npm 的默认源在境外国内直接拉包经常龟速甚至超时。这不是 Codex 独有的问题但它的依赖树不算小卡住一次可能就得重来。我的做法是换一个国内的 npm 镜像源一条命令的事npm config set registry https://registry.npmmirror.com设完之后可以用npm config get registry确认一下是否生效。如果之后需要发布包或者访问私有源记得再切回来或者用 nrm 这类工具管理多个源。这里提醒一句镜像源只是加速下载不改变包的内容装完之后可以放心用。另外如果你所在的环境里存在系统级的网络设置可能会影响 npm 和模型服务的连接。典型表现是 npm 能装但模型请求一直超时或者反过来。排查思路上先确认npm config get proxy和npm config get https-proxy返回的是不是 null如果不是 null 而你又不清楚来源可以考虑清掉npm config delete proxy npm config delete https-proxy这一步看起来很基础但我见过太多明明本地模型服务已经起来了Codex 就是连不上的案例最后都是环境里残留的转发设置或端口映射在捣乱。把环境变量里的相关配置也检查一遍尤其是HTTP_PROXY这类大写变量有时候是某个安装脚本悄悄写进去的。提示做网络相关排查前先用curl http://localhost:端口号/v1/models之类的命令确认本地模型服务本身能通能排除掉一半的干扰因素。2.4 硬件与磁盘先算清楚账再动手如果你打算把模型也放在本地跑硬件这关必须提前评估别等装到一半才发现显存不够。模型推理的主要瓶颈是显存粗略的算法是参数量乘以量化位数再除以 8加上 KV 缓存和框架开销。下面这张表是我实测下来的经验值给不同量化精度下的常见规格做个参考模型参数量量化精度权重大小约建议显存实际感受7B4bit4.5 GB8 GB日常问答流畅长上下文略吃力7B8bit7.5 GB10 GB质量更好速度稍慢14B4bit9 GB12 GB代码理解明显上台阶14B8bit15 GB18 GB需要中端以上显卡32B4bit19 GB24 GB消费级显卡的天花板附近磁盘空间也别忽略。除了模型文件本身框架缓存、模型转换中间产物、依赖包加起来预留个 50 GB 比较稳妥。CPU 推理虽然理论上能跑但速度会让你失去使用的耐心除非只是做验证否则不建议。如果你的机器配置有限也不用死磕本地模型这条路。Codex 支持配置多种模型供应商你完全可以把客户端装在本机把请求指向一台内网的推理服务器或者用云端兼容接口。客户端本身体积很小对硬件几乎没有要求真正吃资源的是模型那一侧。想清楚哪部分是本地哪部分可以远端能省掉不少硬件焦虑。3. Codex 的下载与安装一步步来别贪快3.1 全局安装命令与版本确认前面 Node 和 npm 都验证通过之后安装本身就一条命令npm install -g openai/codex这里解释一下参数。-g表示全局安装装完之后在任何目录下都能直接调用codex命令不用切到特定目录。如果不加-g包会装到当前目录的 node_modules 里用起来很别扭。安装过程会拉取依赖网络好的话一分钟内完成。装完之后立刻验证codex --version能打印出版本号说明安装成功。如果这一步报命令未找到八成还是全局路径没进 PATH。用npm root -g看一下全局包的实际位置再检查这个位置下的 bin 目录有没有在 PATH 里。Windows 下通常是在用户目录的 AppData 里macOS 和 Linux 是在 /usr/local 或 nvm 对应的目录下。想要升级的话重新执行一次安装命令即可npm 会自动覆盖旧版本。我个人的习惯是隔一段时间看一下有没有新版本因为这类工具迭代很快新版本经常修掉一些诡异的连接问题。查看当前最新版本可以用npm view openai/codex version。另外macOS 用户如果装了 Homebrew也可以走brew install codex这条路。两种方式装出来的功能一样区别在于升级和卸载的路径不同。我建议选一种就一直用下去别混着装不然哪天出现两个版本的 codex 在 PATH 里打架排查起来很烦。3.2 首次启动登录还是走密钥安装完成后第一次敲codex它会引导你做认证。这一步有两条路选哪条取决于你的使用场景。第一条路是用官方账号登录。执行codex login之后终端会给出一个链接你在浏览器里完成验证凭证会写到本地配置目录。这种方式的优点是省心额度、模型都在官方体系内管着适合个人日常使用也适合想快速试一下效果的人。第二条路是用 API 密钥。设置环境变量OPENAI_API_KEY或者在配置文件里指定环境变量名。这种方式更适合接入第三方兼容接口或者自建的模型服务。之所以用环境变量而不是把密钥硬写进配置文件是为了避免误提交。配置文件如果哪天被同步到 Git 仓库里明文密钥就泄露了这个风险一定要提前规避。配置目录的位置按系统区分Windows 下一般在用户目录的.codex文件夹macOS 和 Linux 下是~/.codex。这个目录里主要看两个文件一个是auth.json存认证信息权限要收紧另一个是config.toml存的是模型和供应商配置这个是我们后面要重点打磨的。注意不管走哪条路都别把 auth.json 或者含密钥的配置文件提交到任何代码仓库。如果不小心提交过第一件事是去后台把这个密钥作废重新生成光删文件是不够的。3.3 首次运行的交互体验认证通过后codex会进入一个交互式界面。这个界面有点像聊天窗口但功能比聊天窗口强得多——它可以读文件、跑命令、改代码。刚上手时建议找一个无关紧要的测试项目别直接在公司主力仓库上开跑。进去之后先敲/help看看有哪些命令。常用的几个/init会在项目根目录生成一份 AGENTS.md用来描述项目约定/model用来切换模型/approvals或者相关命令用来调整审批策略。这几个命令后面还会展开讲。这里有个新手特别容易踩的坑默认的审批策略比较谨慎Codex 每次要执行命令或者写文件都会问你一句。很多人以为工具卡住了其实是在等你确认。如果你清楚当前目录是安全的可以适当放宽策略但千万别一上来就设成完全放开那不是效率那是风险。4. 接入本地模型把请求出口换成自己的服务4.1 本地模型服务怎么起要让 Codex 用上本地模型第一步是先有一个能对外提供接口的模型服务。目前比较主流的选择是 Ollama 和 LM Studio 这两个前者偏向命令行和自动化后者带图形界面对新手更友好。Ollama 的安装很简单官网下载对应系统的安装包装完之后在终端里执行ollama pull qwen2.5-coder:7b这条命令会把模型文件拉到本地。拉完之后执行ollama serve启动服务默认监听 11434 端口。验证是否正常curl http://localhost:11434/v1/models能返回一段 JSON里面列着你拉下来的模型说明服务起来了。注意这里的路径里带/v1这是 Ollama 提供的兼容接口跟原生接口不是一回事配置 Codex 时必须用带/v1的这个地址。LM Studio 的思路类似图形界面里搜索模型、点击下载然后在开发者选项里把本地服务打开同样会给出一个本地地址。它的好处是能直观看到显存占用和推理速度调参的时候心里有数。这里补充一个实操心得模型第一次加载会比较慢因为要把权重读进显存。如果你配好 Codex 之后第一次请求等了几十秒都没反应先别急着怀疑配置去看看模型服务的日志很可能还在加载。可以先把模型服务单独跑通用 curl 发一个最简单的请求确认返回正常再去配 Codex这样能有效区分模型侧问题和客户端侧问题。4.2 config.toml 完整拆解这是整个流程里最关键的一步。配置文件在~/.codex/config.toml如果不存在就新建一个。下面是我实际在用的结构model qwen2.5-coder:7b model_provider local_ollama [model_providers.local_ollama] name Local Ollama base_url http://localhost:11434/v1 env_key LOCAL_API_KEY wire_api chat逐行解释一下。model是你要用的模型名必须和模型服务里实际存在的名字完全一致差一个字符都会报找不到模型。model_provider指向下面定义的段落名两处名称要对上。base_url是接口地址。这里有个非常容易搞错的地方很多兼容接口同时提供多种路径而 Codex 需要的是以/v1结尾的那个。地址末尾要不要斜杠、路径里带不带 v1这些细节建议直接照抄服务文档里的示例别凭感觉写。env_key指定从哪个环境变量读取密钥。本地服务通常不校验密钥但不填这个字段有些版本会报错所以随便给个变量名然后设一个占位值就行export LOCAL_API_KEYdummywire_api这个字段是重头戏它决定 Codex 用哪种协议格式跟服务端对话。可选值主要有chat和responses两类。responses是较新的接口形态功能更全但很多本地服务还没实现它只支持传统的chat格式。如果你配了responses而服务端不认就会出现请求发出去、服务端返回格式不对、客户端解析失败的连锁反应表现就是一直报错但看不出原因。所以接本地模型时老老实实设成chat是更稳妥的选择。4.3 模型选择与上下文长度的权衡选哪个模型取决于你的硬件和使用场景。我的经验是分三档来看。7B 级别的模型4bit 量化后在 8GB 显存的机器上能跑得很舒服。它的强项是快速问答、写小段函数、解释代码含义日常用足够了。但你要是让它理解一个几千行的模块并做跨文件重构它会明显力不从心经常漏掉上下文。14B 是一个甜蜜点。代码理解能力比 7B 有明显提升能处理更长的文件多文件改动的准确率也高不少。代价是显存需求翻倍响应速度会慢一截。如果你的机器有 12GB 以上显存我更推荐从这个档位起步。再往上32B 级别的模型在代码任务上的表现已经相当能打但它对硬件的要求也上了一个台阶。而且模型大了之后推理速度下降带来的体验损耗有时候会抵消掉质量提升带来的收益。我的建议是先在你现有硬件能承受的范围内选最大的那个跑一段时间觉得不够再往上加。还有一个容易被忽略的参数是上下文窗口长度。模型支持的上下文越大能一次性塞进去的代码就越多但显存占用也会随之上升而且长上下文下模型的注意力会被稀释反而不如把任务拆小。实操中我更倾向于把上下文控制在合理范围然后把大任务拆成几个小任务分步执行效果通常比一次性喂一大堆文件要好。5. 跑通验证用最小任务确认整条链路5.1 第一个任务怎么选配置改完之后别急着上大项目。先建一个空目录随便放一两个文件然后在这个目录下启动 Codex让它做一件特别简单的事比如读一下当前目录有哪些文件告诉我每个文件是干什么的。这么做的目的是把变量降到最少。如果这个任务能正常返回说明从客户端到模型服务的整条链路是通的认证没问题、地址填对了、协议格式匹配、模型能正常推理。任何一个环节出问题都会在这步暴露出来而且报错信息会相对干净容易定位。确认基础链路通了之后再逐步加码。第二个任务可以让它创建一个新文件并写入一点内容这一步会触发写文件权限用来验证沙箱策略是不是配置正确。第三个任务让它执行一条简单的命令比如查看当前目录这一步验证命令执行能力。我在实践中总结的顺序是这样的先读、再写、后执行。这三个动作对应三套不同的权限控制分开验证能快速定位是哪一层出了问题。很多人上来就让它重构整个项目一旦失败根本不知道卡在哪一步反而更费时间。5.2 沙箱模式与审批策略Codex 在执行操作时会受两套机制约束沙箱模式决定它能碰哪些范围审批策略决定它动手前要不要问你。这两套机制搭配使用能在效率和安全性之间找到平衡。沙箱模式大致分几档。最严格的一档只允许读取任何写入都会被拦截适合你想让它先分析、暂时不要动代码的场景。中间一档允许在工作目录内写入但工作目录之外还是只读这是日常开发用得最多的设置。最宽松的一档放开所有限制功能最全但风险也最高。审批策略同样分几档。最保守的是每一步都问你包括读文件稍微放开一点是只在写文件和执行命令时问再放开就是只在你指定为危险的操作上问。我的个人习惯是调研类任务用严格沙箱配合全审批专注分析不改代码明确的修改任务用工作目录可写配合写操作审批兼顾效率和安全。命令行参数上可以这样指定codex --sandbox workspace-write --ask-for-approval on-request在交互界面里也可以用/approvals之类的命令动态调整不用每次重启。改了策略之后当前会话立即生效这点很方便。注意无论什么时候都不要在包含敏感数据或者生产配置的目录下放开全部权限。AI 助手再聪明也只是按指令行事它不会替你判断某个文件该不该动。这个判断责任始终在你身上。5.3 AGENTS.md让助手读懂你的项目规矩在项目根目录执行/init之后Codex 会生成一份 AGENTS.md 文件。这份文件的作用是告诉助手这个项目的约定比如用什么语言、目录结构怎么组织、提交信息怎么写、哪些目录不要动。它的价值在于避免每次都要重复交代背景。写这份文件有几个技巧。第一写清楚不要做什么比写要做什么更重要。比如不要修改 migrations 目录下的文件不要执行任何涉及数据库的命令这类禁令能挡掉很多麻烦。第二把项目特有的命令写进去比如构建命令、测试命令、格式化命令这样助手就不需要自己去猜。第三内容要短别写成一份完整的开发文档太长反而会被忽略重点。我的习惯是每次发现助手做了不该做的事就往 AGENTS.md 里补一条规则。用一段时间之后这份文件就成了这个项目最实用的助手说明书换任何模型都通用因为它是给客户端读的跟后端模型是谁没关系。5.4 验证清单跑通之后可以对着下面这张表逐项确认任何一项打不上勾都说明还有隐患验证项检查方法通过标准客户端版本codex --version正常输出版本号认证状态启动后不发请求不提示需要登录模型服务curl 地址/v1/models返回包含目标模型的 JSON协议匹配发一次简单对话正常返回无格式错误写文件权限让它创建文件文件真实出现在磁盘上命令执行让它列出目录正确输出目录内容项目规则查看 AGENTS.md内容与你项目实际相符6. 常见报错与排查技巧实录6.1 安装阶段的问题安装类报错的花样不多主要是几种。第一种是权限错误表现为 EACCES前面提过别用 sudo 硬上改成用户级全局目录。第二种是引擎不兼容报错信息里会明确说需要哪个版本的 Node这时候升级 Node 就行。第三种是网络超时换镜像源或者多试几次通常能解决。还有一种比较隐蔽的情况是装了一半。表现是codex --version能输出但启动时报某个模块找不到。这通常是安装过程被中断node_modules 里留下了不完整的文件。解决办法是先卸载再重装npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex清缓存这一步别省npm 的缓存机制有时候会把损坏的包缓存下来不清掉重装也没用。我遇到过两次这种情况都是靠清缓存解决的。Windows 上还可能出现长路径问题。npm 的依赖树嵌套很深如果系统没开启长路径支持安装会失败。解决办法是在组策略或者注册表里开启长路径或者把全局安装目录设到路径更短的位置。这个问题在新版 Windows 上概率降低了但老系统上还是会碰到。6.2 连接与转发类故障这一类是最让人头疼的因为症状模糊。典型表现是模型服务用 curl 明明能通配置也检查了好几遍但 Codex 一发请求就超时或者报连接失败。排查这类问题我有一套固定顺序。第一步确认模型服务监听的是0.0.0.0还是127.0.0.1。如果 Codex 跑在容器里或者另一台机器上而服务只监听本地回环那肯定连不上。第二步检查配置文件里的地址有没有写错端口或者多加了个斜杠导致路径拼接错误。第三步检查环境变量尤其是那些会影响网络请求的变量它们可能让本该发往本地的请求绕了一圈。还有一类报错来自多配置切换工具。如果你用某个工具在不同供应商配置之间切换它有时会启动一个本地的转发中间层来处理请求。这个中间层如果和你配置文件里的地址对不上就会报出类似处理某个接口路径时转发失败的错误。这类问题的根因是转发链路上出现了重复或者冲突解决办法是理清楚你到底想让请求走哪条路要么让 Codex 直连模型服务要么让它走中间层别两套配置混在一起。实操中我建议的做法是切换配置之后先做一次最小验证别直接上复杂任务。因为配置切换出错时的报错信息往往是指向转发层的跟真正的业务请求没关系看到这类报错先怀疑转发链路而不是模型本身。6.3 响应格式与超时问题请求发出去了但返回的内容解析不了这种情况通常是协议格式不匹配。前面讲过wire_api字段如果设成了新式接口而服务端只实现了传统格式服务端返回的 JSON 结构就跟客户端期望的对不上报错信息往往很含糊看起来像是解析失败。判断方法很简单把wire_api改成chat试一次。如果改完就好了那就是这个问题。反之如果你用的是官方接口那就应该设成对应的新式格式设成 chat 反而可能丢掉一些功能。超时问题要分两种看。一种是首次请求超时多半是模型正在加载等一会儿或者提前预热一下就好。另一种是每次请求都超时那就是链路问题回到上一节按顺序排查。还有一种情况是请求成功了但结果不完整输出到一半断掉。这通常和上下文长度超出模型限制有关。模型服务会在超限时截断或者报错表现取决于具体实现。解决办法是减少一次提交的文件数量或者调大模型的上下文配置。排查时可以看模型服务的日志那里通常有明确的提示。6.4 报错速查表把上面这些整理成一张表方便对着症状找原因症状可能原因优先尝试的处理命令未找到PATH 未包含全局 bin 目录检查npm root -g并加入 PATH安装报 EACCES全局目录权限不足改用户级全局目录避免 sudo启动报模块缺失安装中断留下残包卸载后清缓存重装curl 通但客户端超时地址、端口或环境变量干扰逐项检查配置与环境变量转发层报错配置切换工具链路冲突理清直连还是走中间层响应解析失败协议格式不匹配调整wire_api取值长任务输出截断上下文超出模型限制拆分任务或调大上下文首次请求极慢模型正在加载进显存等待或提前预热服务提示排查时养成看日志的习惯。客户端和模型服务两边都有日志对照时间点看能快速判断请求到底走到了哪一步、在哪一步断掉。7. 把它用顺手几个提升效率的细节7.1 配置的分层与复用用一段时间之后你会发现不同项目需要不同的配置。写前端项目可能希望用响应快的轻量模型处理复杂后端逻辑又想换成大一点的。每次都改全局配置很烦所以建议做分层。一层是全局默认配置放在~/.codex/config.toml定义好所有可用的供应商。另一层是项目级配置放在项目根目录只覆盖当前项目需要的字段比如模型名。Codex 加载时会合并这两层项目级优先。这样一来切换项目就自动切换了配置不用手动改。配合前面提到的 AGENTS.md效果会更好。一个管技术配置一个管项目约定换工作目录就等于换了一整套工作环境。7.2 成本与资源控制如果你用的是本地模型成本主要体现在电费和硬件折旧上这个基本可以忽略。但要留意显存占用同时跑多个任务可能导致显存爆掉服务直接崩。我的做法是同一时间只跑一个重要任务需要并行就用队列。如果你用的是云端接口那就要盯住用量。给不同的配置起清楚的名字在配置里区分开这样哪天用量异常能快速定位到是哪个环境在消耗。另外把密钥分散到不同的环境变量里别所有配置共用一个出问题的时候影响面会小很多。还有个小技巧是记录日志。Codex 每次请求的耗时和结果如果能简单记录一下用一段时间之后你就能看出哪个模型在什么类型的任务上性价比最高。这种数据比任何评测榜单都真实因为它反映的是你自己的使用模式。7.3 什么任务适合交给它用了几个月我大致摸清了它的能力边界。适合的任务有读代码回答问题、写单元测试、做小范围重构、生成样板代码、解释报错的含义。这些任务的特点是边界清晰改动范围可预期。不太适合的有涉及大量隐式上下文的架构决策、需要访问外部系统状态的操作、对正确性要求极高且无法验证的改动。后者不是说做不了而是你需要投入额外的验证成本有时候还不如自己写快。一个实用的判断标准是如果这个任务你自己做需要五分钟以内那交给它反而更慢因为描述需求加检查结果的时间就超过五分钟了。如果这个任务你自己做要半小时以上而且边界清楚那它就很有价值。这个阈值会随着你越来越熟悉工具而降低但开头阶段用它处理小任务是更明智的选择。最后分享一个我踩过的坑。刚开始我把沙箱开得太松让它在项目根目录自由操作结果它顺手改了配置文件虽然不是什么大事但排查了半天才发现。从那之后我就坚持一条原则权限永远从紧到松需要什么开什么而不是先全开再回收。这条原则在任何 AI 辅助开发的场景里都适用。