★ FEATURED ARTICLE 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 installmacOS 上有 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 验收只信测试不信它的话这是我最想强调的一条。智能体说“已完成修改所有测试通过”的时候你要自己再跑一遍。这不是不信任是因为它的“通过”可能基于错误的前提跑错目录了、跑的是缓存结果、或者它把失败的测试注释掉了。验收的标准动作是三步看git diff确认改动的文件范围符合预期没有顺手改无关文件。自己跑一遍测试命令看输出。抽查一到两个关键改动看逻辑是否正确特别是有没有偷偷加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 装不上、跑不起来症状大概率原因处理方式命令找不到包管理器的全局 bin 目录不在 PATH查npm bin -g之类的路径手动加进 shell 配置提示未登录凭据写到了别的用户目录检查是否用 sudo 装过重装或修正配置目录权限启动就报版本错误Node/Python 版本太低用版本管理工具切到要求的版本别硬改装了新版但行为像旧版有多个副本在 PATH 里which -a 命令名看全部路径删掉旧的公司网络下装不上私有源/网络限制换用独立二进制安装绕开包管理器版本冲突这一条最隐蔽。我之前同时用两种方式装过同一个工具--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大改造会拆成五六个小任务排队跑中间穿插人工确认。这个比例大概是七三开七成交给它三成自己写。再多我不敢再少又浪费。这个比例每个人不一样得自己跑一段时间才摸得准。
阅读完成 · 觉得有帮助？
