企业官网建设流程全解析

1. 先把“用上 Codex”拆开：你要用的是哪一版

我碰到过太多人来问“怎么用上 Codex”，聊两句就发现大家嘴里说的是同一个名字，脑子里想的却是四件完全不同的事：有人想要终端里那句自然语言变成一串 shell 命令，有人想要编辑器里补全半行代码，有人想把一个 issue 丢出去，等半小时拿回一个带测试的 PR，还有人只是想调接口自己搭个内部工具。这四种诉求，安装路径、配置重点、踩的坑完全不一样。所以动手之前先把“用上”这两个字拆开，比装十个插件都管用。

我自己的判断标准很简单：看你要处理的任务是秒级、分钟级还是小时级。秒级是补全和行内改写，编辑器的扩展就够了；分钟级是“把这个模块的重试逻辑改成指数退避，顺便补两个单测”，终端里的代码智能体最顺手；小时级是“把这个老仓库的依赖全升一遍，跑通全部测试”，那就得考虑放云端让它自己慢慢跑，你去看别的东西。混着用的结果通常是：拿补全工具做重构，改到第三十个文件时它忘了前面在干什么；拿终端智能体做补全，每写一行都要确认一次，效率还不如自己敲。

Codex 这个词本身在过去几年里指代过好几样东西：早年是那个把自然语言转成代码的模型，后来变成多家编辑器背后的补全能力，现在更多是指“能自己读仓库、自己改文件、自己跑测试”的代码智能体。这三者的能力边界差了不止一个量级。补全型只能看到光标附近几百行，智能体型能看到整个仓库，还能执行命令验证自己的改动。你如果是照着三年前的教程去配，配出来的东西跟你想要的八成不是一回事。

提示：先去官方文档的“版本/形态”那一页确认当前提供哪些入口，别看第三方博客的截图。这个领域半年就换一轮界面，教程的时效性比内容质量更重要。

所以这一篇我按“代码智能体”这条线来讲，因为这是目前绝大多数人说“用上 Codex”时真正想要的东西。补全型的那部分我会在编辑器那一节顺带提一句，不展开，因为它的上手成本几乎为零，装个扩展登录就完事，没什么可讲的。

1.1 三种形态的取舍：终端、编辑器、云端

终端形态是我最推荐的入门路径，原因很实际：它跟你的工作流是解耦的。你不需要换编辑器，不需要改变提交习惯，只需要在一个已经开着项目的终端窗口里多敲一条命令。它读的是磁盘上真实的文件，跑的是你本地真实的测试，改完之后git diff一目了然，不满意一条git checkout .就回去了。这种“低侵入”特性对第一次接触的人特别友好，你不会有“我把项目搞坏了怎么办”的心理负担。

编辑器形态的优势是上下文即时性。你正在看的那个文件、刚选中的那二十行、终端里刚报出来的那段堆栈，它天然就知道。适合“局部修补”类任务：一个函数写错了、一段报错看不懂、一个类型体操想不出来。缺点是它对你的仓库全局结构理解有限，你让它“把整个项目的日志规范统一一下”，它多半会给你一个局部改法然后告诉你“其余文件类似处理”。

云端形态的逻辑完全反过来：它适合长时间、可并行、结果可验证的任务。你把任务描述清楚，它在一个隔离环境里自己 clone、自己装依赖、自己改、自己跑测试，最后给你一个可以直接 review 的改动集。好处是不占你本地机器的资源，你可以同时丢三个任务出去；坏处是它对环境的假设和你本地可能不一致，依赖装不上、测试跑不通的情况相当常见，而且你没法中途插手纠正方向，只能等它跑完再提意见。我的经验是：第一次用某个仓库跑云端任务之前，先在终端里手动跑一遍完整流程，把环境问题全部暴露掉，否则你会花大量时间在读它“环境准备失败”的日志上。

1.2 什么样的项目适合立刻上手，什么样的先缓缓

有个很反直觉的结论：测试覆盖率越高的项目，用代码智能体收益越大。原因不难想，智能体的核心价值是“它能自己验证自己的改动”，而这个验证靠的就是你仓库里现成的测试和构建命令。一个有 70% 覆盖率、npm test三十秒跑完的项目，它可以改完立刻跑，跑挂了立刻修，你最后只需要 review 一份通过的 diff。反过来，一个测试全靠手点、构建要二十分钟的项目，它改完之后没有任何反馈回路，只能靠“看起来对不对”，那你还不如自己写。

第二类适合上手的是结构清晰、约定明确的项目。目录怎么分、代码风格怎么定、错误怎么抛、日志怎么打，如果这些在你的仓库里是有一致规律的，智能体读几个文件就能摸出来，改出来的代码跟周围风格差不多。如果每个模块各写各的，那它大概率会“自由发挥”，产出的东西你 review 起来比自己写还累。

反过来说，这几种情况我会建议先别急着上：涉及资金、权限、数据删除的核心链路，改错了代价太大，智能体再准也不值得赌；高度依赖业务背景知识的模块，比如一堆只有老员工才懂的兼容分支，它读不出来也猜不对；代码量巨大但文档为零的单体仓库，它读文件会读到上下文爆掉，最后拿到一堆碎片化的错误认知。

2. 上手前的三件准备：账号、环境、仓库

真正让人卡住的往往不是安装那一步，而是安装之前的三件事没做。我见过太多人在“装完了但跑不起来”这一步耗掉一整个下午，回头一查，是本地 Node 版本跟项目要求差了两个大版本，或者git里有一堆没提交的改动，智能体一改就分不清哪些是它的、哪些是你的。

2.1 账号与额度：先弄清楚你手上是哪种权限

目前主流的分发方式就两种：订阅制（包月，按使用频率或时间窗口限制）和按量计费（走接口，用多少算多少）。前者适合个人日常用，后者适合团队自建工具或者高频批处理。很多人第一次接触时容易忽略的是：订阅额度通常有时间窗口，比如“每几小时重置一次”，这意味着你不能一次性丢十个大任务出去，得排着队跑。我刚开始时就吃过这个亏，上午把额度跑光，下午真正要干活的时候反而用不了。

团队场景要额外确认三件事：能不能开集中账单、能不能限制成员的单次用量上限、能不能对敏感仓库设访问白名单。这三条如果不确认清楚，等出了事再补就被动了。尤其是最后一条，有些团队会让智能体直接读生产配置的仓库，这在合规上是要走审批的。

另外一个容易踩的坑是账号隔离。我建议把“实验用的账号”和“日常干活的账号”分开，实验账号随便折腾，跑废了不心疼；干活账号保持干净，不要在里面试各种奇怪的配置。这个习惯听起来麻烦，但你只要经历过一次“误操作把配置文件改乱了、忘了备份、折腾两小时找回来”，就会觉得值。

2.2 本地环境基线：四条命令必须先跑通

在装任何东西之前，先在项目根目录手动跑这四类命令，全部通过再往下走：

git status # 工作区必须干净，或者你明确知道哪些改动是你的 node -v && npm -v # 或者 python -V / java -version，看你的技术栈 <你的测试命令> # npm test / pytest / go test ./... / mvn test <你的构建命令> # npm run build / cargo build / make

为什么要强调这个？因为智能体的工作方式是“改完自己验证”，而验证用的就是这几条命令。如果测试本来就在你本地跑不过，它改完之后看到一片红色，会误以为是自己的改动导致的，然后开始疯狂“修复”一个根本不存在的问题，越修越歪。它的调试逻辑建立在“基线是绿的”这个前提上，基线是红的，它的整个推理链就是错的。

还有一个细节：测试要跑得够快。一个跑二十分钟的测试套件，意味着智能体每次验证都要等二十分钟，一个任务里它可能要验证五六轮，两小时就没了。我的做法是给它准备一条“快测”通道，比如只跑相关模块的单测、跳过端到端测试，在配置里明确告诉它用这条通道。这个优化带来的效率提升，比换个更强的模型明显得多。

注意：不要把带有真实密钥的.env放在仓库根目录让智能体随便读。真要给它看环境变量，用一份脱敏的.env.example，把值全部换成占位符。

2.3 让仓库“可读”：一份约定文件顶一千句解释

这是我认为整个流程里性价比最高的一件事。绝大多数项目都会有一个 README，但 README 是写给新人看的，讲的是“这个项目是什么”；智能体需要的是“你怎么在这里干活”，比如：

• 安装依赖用哪个命令，有没有私有源
• 测试怎么跑，快测和全测分别是什么命令
• 代码风格是什么，有没有 lint 脚本
• 哪些目录不能碰，哪些文件是自动生成的
• 提交信息怎么写，分支怎么命名
• 有没有必须遵守的架构约束，比如“领域层不许依赖基础设施层”

把这几条写进一份固定名字的约定文件（不同工具的默认文件名不一样，官方文档里会写明，常见的是仓库根目录下一个全大写的 Markdown 文件），智能体每次启动时会自动读它。这份文件写得好，你后面每一次任务描述都能省掉一半的字。

我自己的模板大概长这样，你可以直接拿去改：

# 项目约定 ## 环境 - Node 20.x，包管理器用 npm，不要用 yarn/pnpm - 依赖安装：npm ci（不要用 npm install，会改 lock 文件） ## 验证 - 快测：npm run test:unit -- --silent - 全测：npm test（约 8 分钟，非必要不跑） - 类型检查：npm run typecheck - 提交前必须通过：typecheck + 快测 ## 代码风格 - 缩进 2 空格，单引号，行尾分号 - 错误统一用 AppError 包装，不要直接 throw new Error - 日志走 logger 模块，禁止 console.log - 新增文件必须补对应的 .test.ts ## 禁止 - 不要修改 src/generated/ 下任何文件 - 不要修改 package-lock.json（除依赖升级任务） - 不要调整 tsconfig 的严格模式开关 ## 目录 - src/domain 领域逻辑，纯函数，不依赖外部 - src/infra 基础设施，数据库、HTTP 客户端 - src/api 接口层，只做参数校验和转发

这份东西写一次能用很久，而且它是可以增量演进的。每次你发现智能体犯了同一个错，就往里加一条。我现在的约定文件里有一条是“不要自作主张给函数加 try/catch 然后吞掉错误”，这就是被坑了三次之后加上的。

3. 安装与首次跑通：从零到第一条指令

准备工作做完，安装本身其实很快，五到十分钟。我把关键节点和容易出岔子的地方都标出来。

3.1 安装：三种常见方式怎么选

主流的代码智能体基本都提供三条安装路径：包管理器全局安装、独立二进制下载、容器镜像。我的推荐顺序也是这样。

包管理器全局安装最省事，一条命令，升级也方便：

# 包名以官方文档为准，这里用占位符表示 npm install -g <官方发布的包名> # 装完确认版本 <命令名> --version

用 Node 生态举例是因为它最普遍，Python 系的项目对应pipx install，macOS 上有 Homebrew 的话也可以走brew install。关键是别用sudo，全局安装加sudo之后权限会乱，后面升级、卸载都可能报错，而且有些工具会把配置写到用户目录，sudo之后写到了 root 目录，你普通用户读不到，表现就是“装完了但提示未登录”。

独立二进制适合公司电脑不让装 Node 的场景，下载解压、加进PATH就完事，缺点是升级要手动。容器镜像适合在 CI 里跑，或者你想把智能体完全隔离在一个环境里不给它碰本机文件。

装完先跑一次--help，看看子命令列表。这一步能帮你确认三件事：命令确实在PATH里、版本是对的、它支持哪些运行模式。很多人跳过了这一步，后面遇到问题连“这个功能到底有没有”都判断不了。

3.2 首次认证：交互式登录 vs 环境变量

第一次运行会要求登录。交互式的流程通常是弹一个浏览器、授权、回调带一个凭据回来存到本地配置目录。这个过程有几个细节值得注意：

配置目录在哪。通常在用户主目录下的一个隐藏文件夹里，里面会有配置文件、会话历史、日志。知道这个位置很重要，因为出问题时第一件事就是去看日志，第二件事就是备份/重置配置。我建议装完第一件事就是ls一下这个目录，心里有个数。

环境变量 vs 配置文件。CI 场景下没法交互式登录，就得用环境变量传凭据。这里有个安全细节：不要把凭据写进仓库里的脚本，写进本机的 shell 配置文件或者 CI 的密钥管理里。另外注意环境变量的优先级通常高于配置文件，如果你本地设过一个旧的环境变量，登录新账号之后行为会很怪，表现就是“明明登录了但提示没权限”。

多账号切换。如果你像我一样有实验账号和干活账号，切来切去会很烦。比较省事的做法是给不同账号准备不同的配置目录，用一个环境变量指过去，这样互不干扰。

3.3 第一条指令：从只读模式开始

装完、登录完，别急着让它改代码。第一条指令我强烈建议用只读模式跑一个纯理解任务，比如：

<命令名> "读一下这个仓库，告诉我：项目的入口在哪、依赖怎么装、测试怎么跑、有没有明显的技术债。不要修改任何文件。"

这条指令的价值有三层。第一层是验证整条链路通不通：能不能读到文件、能不能理解仓库结构、输出格式对不对。第二层是校准你对它的预期：看看它读代码的准确度如何，有没有一本正经地胡说八道。第三层是它在读的过程中其实顺手帮你梳理了一遍项目结构，这份输出直接可以拿来当约定文件的初稿。

只读模式在配置里通常对应一个沙箱级别，常见的有三档：只读（只能读文件，不能写不能执行）、工作区可写（能改当前工作区，但网络和系统目录受限）、完全放开（什么都能干）。我日常用中间那档，特殊任务临时放开，用完立刻调回去。这个习惯是从一次教训来的：早期我图省事一直用完全放开，结果它为了“验证”一个改动，在临时目录里装了一堆东西，磁盘直接满了。

3.4 配置文件里那几行值得改的

配置文件一般是 TOML 格式，位置在用户目录下。默认值大多能用，但有几项我建议你按自己的习惯调：

关于推理强度这一项，很多人会一直拉满，觉得“越强越好”。实测下来不是这样：拉满之后模型会在每个小决策上都反复权衡，一个“把变量名从 data 改成 payload”的任务它能想两分钟。反过来，简单的机械式改动用低强度，速度快三倍，效果没差别。按任务难度分级设置比全局拉满划算得多。

4. 核心工作流：把任务交给智能体的四个动作

装好之后，真正的门槛在“怎么派活”。我把它拆成四个动作：拆任务、喂上下文、定权限、验收。这四个动作做扎实，产出质量的差距能有十倍。

4.1 拆任务：颗粒度控制在“一次能验证完”

最典型的失败模式是任务太大。你写“重构一下用户模块”，它打开一看，二十个文件、三千行代码，然后开始凭感觉改，改到第十个文件时上下文已经满了，前面改过什么它记不清了，最后给你一份前后不一致的 diff。

我的经验是一个任务对应一次验证。什么叫一次验证？就是“改完之后跑一次测试，能明确判断对不对”。比如：

• 好任务：把UserService.getProfile里的同步数据库调用改成异步，并更新对应的三个调用点和单元测试。
• 坏任务：把整个用户模块的数据库访问全部改成异步。

前者改完跑一次测试就知道对不对，后者改完你根本不知道从哪 review 起。

拆到什么程度合适？大概是一个熟练工程师二十分钟到两小时的工作量。低于二十分钟，拆任务本身的开销超过收益；超过两小时，中途出错概率显著上升，而且你很难判断它到底卡在哪一步。

还有一个技巧：先让它出方案，再让它写代码。第一轮只说“给我一个改动计划，列出要改哪些文件、每个文件改什么、有什么风险，先别动代码”。你看完计划觉得方向对，再让它执行；觉得不对，改一轮描述重来。这一轮的成本很低，但能挡掉大部分方向性错误。

4.2 喂上下文：三个层次的信息

智能体缺的从来不是智力，是信息。信息我分三层给：

第一层是仓库级，就是前面那份约定文件，它自动读，你不用管。

第二层是任务级，在任务描述里给它指路：“相关代码在src/features/order/下，入口是OrderController.create，数据模型在src/models/order.ts，参考实现可以看src/features/payment/里的同类逻辑，那个模块已经改造过了。”这几句话能让它少读二十个无关文件，省下的上下文全是赚的。

第三层是验证级，告诉它“改完跑npm run test:unit -- order就行，不用跑全量”。这一句能省掉后面十分钟的等待。

第三层经常被忽略，但它直接影响任务能不能顺利跑完。默认情况下智能体会倾向于跑全量测试“确保万无一失”，结果一个简单改动跑了八分钟测试，中途超时或者被你打断，任务就废了。

4.3 定权限：审批策略选哪一档

审批策略本质上是风险和效率的权衡。常见几档：

• 每次都问：最安全，最烦。适合第一次在陌生仓库上跑。
• 失败时问：让它自己跑，出错才停下来找你。我用得最多。
• 按请求问：它自己判断哪些操作需要问。平衡点，但对模型的判断力有依赖。
• 从不问：适合 CI、容器、一次性环境。本地开发别用。

我自己的默认是“失败时问”，然后在两种情况下临时调严：一是碰核心链路，二是第一次在某个仓库上跑。调松的场景只有一种：任务已经被拆得很小、验证手段很明确、而且我有完整的 git 提交可以回滚。

配套的一件事是提交纪律。让智能体干活之前，先把当前工作区提交或者 stash 掉。这样它的所有改动都是干净的增量，git diff一眼能看出它改了什么，不满意git checkout .直接回退。我见过有人带着一堆未提交的改动让智能体干活，最后分不清哪个 bug 是谁写的，回滚也不敢回，很难处理。

4.4 验收：只信测试，不信它的话

这是我最想强调的一条。智能体说“已完成修改，所有测试通过”的时候，你要自己再跑一遍。这不是不信任，是因为它的“通过”可能基于错误的前提：跑错目录了、跑的是缓存结果、或者它把失败的测试注释掉了。

验收的标准动作是三步：

1. 看git diff，确认改动的文件范围符合预期，没有顺手改无关文件。
2. 自己跑一遍测试命令，看输出。
3. 抽查一到两个关键改动，看逻辑是否正确，特别是有没有偷偷加try/catch吞错误、有没有把断言改宽松。

第三步特别重要。我遇到过一次，测试确实通过了，因为智能体把一条expect(x).toBe(5)改成了expect(x).toBeDefined()。从“测试绿了”这个结果看它没撒谎，但这个改动把测试的价值直接抹掉了。所以git diff里测试文件的改动要重点看。

5. 任务描述模板：把话说清楚的五个要素

写任务描述这件事，跟带新人是一样的。你说“把这块优化一下”，新人懵；你说“这个函数在数据量大时是 O(n²)，改成用 Map 做索引降到 O(n)，保持函数签名不变，补一个一万条数据的测试”，新人就知道干什么。智能体也一样，甚至更需要明确，因为它不会主动来问你。

5.1 五要素模板

我总结的模板包含五块，写熟了大概一分钟就能填完：

## 目标 把 `src/features/order/OrderService.ts` 里的 `listOrders` 方法改成支持分页。 ## 背景 现在这个方法一次性查出全部订单，数据量超过一万时接口超时。 上游调用方是 `OrderController.list`，它已经接受 page 和 pageSize 参数， 但目前是忽略状态。 ## 约束 - 保持方法签名兼容，不要改调用方 - 分页参数非法时（page < 1 或 pageSize > 100）抛 AppError，错误码 INVALID_PAGINATION - 不要改数据库 schema - 不要引入新依赖 ## 验证 - 跑 `npm run test:unit -- order`，必须全绿 - 新增至少两个用例：正常分页、非法参数 ## 交付 - 只改 OrderService.ts 和对应的 test 文件 - 改完给我一份改动摘要，说明改了什么、为什么这么改

这五块里，约束和验证是最容易被省略、也最影响结果的两块。约束告诉它边界在哪，验证告诉它什么叫“做完了”。没有验证的任务，它就只能靠“看起来对”来判断，那质量就完全随机了。

“不要引入新依赖”这条我几乎每个任务都写。不写的话，它有可能为了解决一个小问题去装一个库，然后你的package-lock.json就多了一堆东西，review 成本陡增。

5.2 五个反复出现的反模式

反模式一：用形容词代替标准。“优化一下性能”“让代码更优雅”“提高可读性”。这些词在它那里没有可执行的对应动作，最后它会给你一堆格式化的改动然后说“已优化”。换成可量化的描述：“这个函数在 10 万条数据时耗时 3 秒，目标是降到 200 毫秒以内”。

反模式二：一次给多个不相关的任务。“修一下登录的 bug，顺便把日志规范统一了，另外首页加载太慢也看看”。这三件事改动范围完全不重叠，混在一起它会在三个方向之间来回切，上下文被切碎。分开跑，一个任务一条命令。

反模式三：不给参考实现。你仓库里已经有一个写得很好的同类模块，但你没告诉它。它就会自己造一套风格，review 的时候你还得说服自己“这样也行”。给个路径，说“参考src/features/payment/的写法”，产出的一致性立刻不一样。

反模式四：指望它猜业务规则。“会员折扣要按公司政策算”，它不知道政策是什么。这种必须把规则写清楚，或者指到具体文件。业务知识这块它没有任何优势，别赌。

反模式五：改完不提 review。有些人把智能体当黑盒，跑完直接提交。这个习惯迟早出事。至少看一遍 diff，这是最低成本的保险。

5.3 让长任务跑得稳的两个技巧

第一个是分阶段确认。对于超过半小时的任务，我会拆成“先做前一半，做完停下来给我看”。这样即便方向错了，损失也控制在一半。中断和恢复的机制各家都有（会话恢复、继续上一次任务之类的命令），用起来很顺手。

第二个是让它自己记录进度。在任务描述里加一句“每完成一个子步骤，在仓库根目录的PROGRESS.md里追加一行，说明做了什么、下一步做什么”。这样即便中途断了、上下文丢了，你重启之后让它读一下这个文件就能接上。这个技巧在长任务里救过我很多次，尤其是那种要改二三十个文件的机械式改造。

6. 常见问题与排查速查

下面这些是我和周围人实际踩过的，按“症状—原因—处理”整理。大部分问题不需要去翻文档，看这张表就能定位。

6.1 装不上、跑不起来

版本冲突这一条最隐蔽。我之前同时用两种方式装过同一个工具，--version显示的版本跟which出来的路径对不上，折腾了半小时才发现跑的是另一个副本。养成习惯：出问题时先which -a，把所有副本列出来。

6.2 跑起来了但效果很差

这是咨询量最大的一类。常见表现是“它改的代码根本不是我想要的”。往下拆通常是四个原因：

原因一：没给约定文件。它不知道你的代码风格、不知道验证命令，只能按通用最佳实践来，产出的东西自然“不像这个项目”。补上约定文件，效果立竿见影。

原因二：任务描述太抽象。回到上一节的五要素，检查你漏了哪块。八成的“效果差”是描述问题，不是模型问题。

原因三：仓库太大，上下文被稀释。一个几十万行的单体仓库，它读文件读不过来。处理方式是缩小范围：明确告诉它只看哪几个目录，或者在描述里直接贴关键代码片段，跳过它自己去读的过程。

原因四：基线本身是坏的。测试本来就红，构建本来就挂，它的一切判断都建立在错误前提上。回到 2.2 节，先把基线弄绿。

6.3 权限、误删、幻觉这三类风险

误删文件是最吓人的。预防手段有三层：第一层是沙箱级别别开太高；第二层是干活前提交代码，保证能回滚；第三层是在约定文件里明确写“禁止删除任何文件，如需删除先说明理由”。第三层特别有效，实测下来它真的会遵守。

幻觉主要表现在两个地方：一是编造不存在的 API 或配置项，二是声称“已验证”但实际没跑。前者靠“让它先读文档/源码再回答”来缓解，后者靠你自己复核。我的习惯是：只要它说“测试通过”，我一定自己跑一遍，成本很低，收益很高。

越权访问在团队场景要特别注意。如果你把智能体放在有生产凭据的环境里跑，它有可能为了“验证”去连真实数据库。防护方式是把凭据从环境里摘掉，或者用只读的测试库。

注意：不要在挂着生产环境变量的终端会话里跑智能体。这是我认为最容易出事、也最容易避免的一个坑。

7. 用量、成本与团队落地

个人用不太需要考虑成本，但一旦团队推广，这几件事绕不开。

7.1 用量到底花在哪：一个估算方法

很多人以为成本主要在“生成代码”，其实大头在读文件。一个任务里，它可能读了三十个文件、每个几百行，这些内容全部计入上下文。生成的那点代码可能只占总量的一到两成。

粗略估算方法：假设一个任务它读了 20 个文件、平均 250 行、每行 15 个字符左右，光读文件就是 75000 字符量级；如果中途反复读、反复确认，这个数翻两三倍很常见。这么一算你就明白为什么“缩小范围、明确指路”能省那么多——把它要读的文件从 20 个降到 5 个，消耗直接掉一半以上。

对应的省钱技巧也就三条：约定文件减少探索、任务描述明确指路、验证命令用快测。这三条做下来，同样的工作量消耗能降一半。别指望靠“换个便宜模型”来省钱，模型选错了返工一次，省的全都吐回去。

7.2 团队推广的三条硬规矩

规矩一：约定文件进仓库，跟着代码一起 review。不要让它散落在每个人的本地目录里。谁发现智能体犯了新错误，就往约定文件里加一条，走正常的 PR 流程。半年下来这份文件会变成一份非常实用的项目手册，新人看了也受益。

规矩二：智能体产出的代码，跟人写的代码走同一套 review 标准。千万别因为“是 AI 写的”就放松要求，也别因为“是 AI 写的”就额外苛刻。标准一致，效率才高。唯一需要额外看的是测试文件的改动，前面说过，防止断言被偷偷放宽。

规矩三：敏感仓库设白名单。哪些仓库允许接智能体，哪些不允许，写清楚。涉及用户隐私数据、支付链路、权限体系的仓库，默认不放行，要用就走审批。这条不是不信任工具，是给团队一个明确的边界，避免有人图省事直接开。

7.3 我自己的几个使用习惯

最后分享几条纯个人经验，不成体系，但都是我用了很久之后沉淀下来的。

习惯一：每个任务开始前先提交。这条听着啰嗦，但我已经形成肌肉记忆了。命令敲下去之前先git status看一眼，有改动就提交或者 stash。它让“回滚”这个动作永远可用，心理负担小很多。

习惯二：让它改之前先让它说。稍微复杂一点的任务，第一轮永远只要方案不要代码。看完方案再放行，能挡掉大部分方向性错误。这一轮成本很低，但收益非常明显。

习惯三：把踩过的坑写进约定文件。我现在的约定文件里有一堆看起来很奇怪的规定，比如“不要在 catch 里返回默认值”“新增接口必须在同一 PR 里补 openapi 描述”“不要给工具函数加 memo”。每一条都是被坑过之后加的。这份文件是活的，一直在长。

习惯四：不用它做自己完全不懂的事。这条最重要。它能帮你写代码，但不能替你判断这段代码该不该这么写。你不懂的领域，它给的方案你 review 不出来，那就等于没有 review。这时候它的角色应该是“讲解员”而不是“执行者”：让它先解释这段逻辑是怎么跑的，你搞懂了再决定要不要让它改。

习惯五：留一条“人肉通道”。有些任务我会刻意不用它，比如核心算法、关键的事务边界、涉及并发的地方。不是因为搞不定，是因为这些地方出错的代价太高，而我 review 一遍的时间跟自己写差不多。工具的价值在于放大你的产出，不在于替代你的判断。

这套流程跑顺之后，我现在的节奏大概是：日常小改动直接丢给它跑，我同时看别的；中等任务先要方案、再放行、最后自己复核一遍 diff；大改造会拆成五六个小任务排队跑，中间穿插人工确认。这个比例大概是七三开，七成交给它，三成自己写。再多我不敢，再少又浪费。这个比例每个人不一样，得自己跑一段时间才摸得准。