1. 从“能跑”到“跑得稳”Codex CLI 智能体编程的进阶思路很多人第一次接触 Codex CLI注意力都放在“怎么装、怎么登录、怎么让它生成一段代码”上。这很正常毕竟从零到一的那一步最有成就感。但真正把 Codex CLI 当成日常生产力工具用上一段时间之后你会发现一个很现实的问题让它生成代码不难难的是让它在一个真实项目里持续、稳定、可控地干活。这一篇作为系列第十一篇我想聊的就是这个阶段的事——从“能跑”到“跑得稳”。Codex CLI 本质上是一个跑在终端里的智能体编程工具它把大模型的代码理解与生成能力和本地文件系统、命令行环境、Git 工作流结合在了一起。你可以把它理解成一个坐在你旁边、能直接读写你项目文件的结对程序员。它和那种网页里复制粘贴代码的用法最大的区别在于它能感知上下文、能执行命令、能改多个文件、能根据报错自己迭代。这种能力一旦用顺了效率提升是肉眼可见的但一旦失控它也可能把你的项目改得面目全非。所以这篇文章适合两类人一类是已经装好 Codex CLI、能跑通基本对话但总觉得“用起来不太顺手”的开发者另一类是准备把它引入团队工作流需要一套可复现、可管控的实操方案的技术负责人。我会围绕智能体编程的核心思路、关键配置、实操流程和踩坑经验展开尽量把每一步背后的“为什么”讲清楚而不是只丢一堆命令让你照抄。在开始之前先明确一个前提Codex CLI 这类工具的能力边界很大程度上取决于你给它的上下文质量和约束条件。你把它当搜索引擎用它就是个高级点的补全你把它当有纪律的工程助手用它才可能真的帮你扛活。这个认知差异决定了后面所有配置和用法的走向。2. 智能体编程的核心设计为什么不能把它当“代码生成器”2.1 智能体与普通代码补全的本质区别普通代码补全的工作模式是“你写一半它猜一半”它的输入是你当前光标附近的代码输出是一段建议。整个过程是无状态的、局部的、被动的。而 Codex CLI 这类智能体的工作模式是“你给目标它规划步骤它执行它验证”。它是有状态的、全局的、主动的。这个区别带来一个很重要的后果智能体会“自作主张”。比如你让它“修复登录接口的 bug”它可能会先去读相关文件然后发现是参数校验的问题接着顺手把参数校验的写法统一了一遍最后还改了测试用例。这些动作里有些是你想要的有些可能超出了你的预期。如果你没有给它足够的约束它就会按照自己的理解去“帮忙”而帮忙的范围是不可控的。所以设计智能体编程工作流的第一原则是明确边界缩小爆炸半径。具体来说就是让它在可控的范围内做决策而不是放任它在整个仓库里自由发挥。2.2 上下文管理智能体编程的命门智能体能不能干好活七成看上下文。这里的上下文包括几层项目结构上下文、任务描述上下文、历史对话上下文、以及工具执行结果上下文。项目结构上下文指的是它能不能快速理解你的代码库长什么样。一个几万行、几十个模块的项目如果它每次都要从头扫描那既慢又容易抓不住重点。常见的做法是在项目根目录放一个约定文件把项目结构、技术栈、编码规范、常用命令写进去让它每次启动时先读这个文件。这相当于给新来的同事一份“项目入门手册”。任务描述上下文指的是你怎么跟它说话。很多人习惯说“帮我优化一下这段代码”这种描述对智能体来说信息量几乎为零。优化什么性能、可读性、还是内存占用约束是什么不能改接口签名还是可以随便改好的任务描述应该包含目标、约束、验收标准三要素。历史对话上下文指的是多轮交互中它记住的东西。这里有个坑上下文不是越长越好。太长的历史会稀释当前任务的权重还可能让它把之前任务的假设带到新任务里。所以该开新会话的时候就开新会话别在一个会话里塞十几个不相关的任务。工具执行结果上下文指的是它跑命令、读文件、看报错之后拿到的信息。这部分是智能体区别于纯对话工具的关键也是它容易“跑偏”的地方。比如它跑了一个测试看到一堆报错可能会误判根因然后朝着错误的方向改。这时候你需要及时介入给它正确的方向。2.3 权限与安全别让智能体“裸奔”Codex CLI 能执行命令、能改文件这意味着它有能力造成真实破坏。我见过有人图省事直接给它全权限结果它在一个没提交的分支上大改一通最后想回滚都找不到干净版本。这种教训一次就够了。合理的权限设计应该分层。读操作可以放开让它自由读文件、读目录、跑只读命令。写操作要收紧尤其是删除文件、执行危险命令、推送到远程仓库这类动作必须有人工确认环节。很多 CLI 工具都支持“确认模式”也就是它提出要执行某个动作时先展示给你看你点确认它才执行。这个模式在初期磨合阶段非常有必要。另外一定要养成“先提交再让智能体动手”的习惯。让它在干净的工作区里干活改完你 review 一遍满意就提交不满意就丢弃。这样无论它怎么折腾你都有一个安全的回退点。这个习惯看起来简单但能省掉无数麻烦。3. 关键配置与实操要点把智能体调教成靠谱队友3.1 项目约定文件的写法与作用前面提到项目约定文件这里展开讲讲怎么写。这个文件通常放在项目根目录名字各工具略有不同但作用一致给智能体提供项目级的背景知识。内容上我建议包含这几块。第一块是项目概述用三五句话说明这个项目是干什么的、技术栈是什么、主要模块有哪些。别写太长智能体不需要读你的产品文档它需要的是快速定位能力。第二块是目录结构说明把关键目录和它们的职责列出来。比如src/api放接口层、src/service放业务逻辑、src/utils放工具函数。这样它找文件的时候就不会乱翻。第三块是编码规范包括命名习惯、缩进风格、注释要求、错误处理约定。这部分越具体越好比如“所有异步函数必须用 try/catch 包裹并记录日志”比“注意错误处理”有用得多。第四块是常用命令比如怎么跑测试、怎么启动本地服务、怎么跑 lint。智能体需要知道这些命令才能自己验证改动是否正确。第五块是禁区明确告诉它哪些文件不要动、哪些操作不要做。比如“不要修改config/prod下的任何文件”、“不要执行数据库迁移命令”。这一块是安全底线必须写清楚。3.2 任务描述的模板化技巧跟智能体沟通最忌讳模糊。我总结了一个简单的任务描述模板实测下来能大幅提升一次成功率。模板包含四部分背景、目标、约束、验收。背景说明这个任务在什么场景下产生目标说明要达成什么结果约束说明不能碰什么、必须遵守什么验收说明怎么判断做完了。举个例子。模糊版“优化一下用户查询接口。”模板版“背景用户列表接口在数据量超过十万时响应超过三秒。目标把响应时间降到一秒以内。约束不能改接口的入参和出参结构不能引入新的外部依赖。验收本地用压测脚本跑一遍P95 响应时间低于一秒且现有测试全部通过。”后一种描述智能体拿到之后基本能自己规划出“先看现有实现、再分析瓶颈、再改、再验证”的路径。前一种描述它只能猜猜错概率很高。3.3 会话隔离与上下文清理一个常见误区是把所有任务都塞进同一个会话。智能体在长会话里会积累大量历史这些历史有好有坏。好处是它能记住之前的决策坏处是旧任务的假设会污染新任务。我的做法是按任务类型分会话。同一个模块的连续改动可以放一个会话跨模块的任务就开新会话。会话开多了不丢人反而说明你在有意识地管理上下文。另外当智能体开始“胡言乱语”或者反复在同一个错误上打转时最有效的办法往往不是继续跟它掰扯而是清空上下文重新描述任务。很多时候它卡住是因为早期某句话给了它错误的前提而这个前提在长上下文里很难被纠正。3.4 工具调用结果的解读与干预智能体跑命令之后会拿到输出然后基于输出决定下一步。这个环节是它最容易跑偏的地方因为命令输出往往信息量很大它可能抓错重点。比如它跑测试输出里有一堆 warning 和一个 error。它可能盯着 warning 去改而忽略了真正的 error。这时候你需要主动告诉它“先看 errorwarning 后面再说。”这种干预看起来是在打断它实际上是在帮它聚焦。还有一种情况是它跑了一个命令命令本身失败了但它没意识到失败继续往下走。这时候你要及时指出“刚才那个命令返回非零退出码说明失败了先解决这个。”智能体不像人那样对“失败”有天然的敏感它需要你提醒。4. 完整实操流程从接到需求到合并代码4.1 需求拆解与任务规划拿到一个需求别急着让智能体写代码。先让它帮你拆解。你可以把需求描述给它然后问“这个需求涉及哪些模块建议按什么顺序改每步的风险是什么”它给出的拆解不一定完美但能帮你快速理清思路也能让它自己对任务有个全局认识。拆解完之后把任务切成小块。每块最好控制在“一次会话能完成、一次 review 能看完”的粒度。太大的任务它容易中途迷失太小的任务又浪费交互成本。我的经验是一个任务如果改动超过五个文件就该考虑再切一刀。4.2 让智能体先读后写这一步很多人会跳过但它极其重要。在让它动手改之前先让它读相关文件并用自己的话复述一遍它理解到的现状。比如“你先读一下userService和userController然后告诉我现在用户查询是怎么实现的瓶颈可能在哪。”这个复述过程有两个作用。一是验证它有没有读懂如果它复述得离谱说明上下文给得不够你得补。二是给它自己建立认知基础后面改的时候不容易跑偏。4.3 小步改动与即时验证智能体改代码最忌讳一次改一大片。正确的节奏是改一小块跑一次测试确认没问题再改下一块。这样出问题的时候你能快速定位是哪一步引入的。具体操作上你可以让它“只改这一个函数改完跑一下相关测试”。它改完你 review没问题就继续。如果它一次改了好几个文件你 review 起来会很累而且一旦测试挂了排查范围很大。验证环节要给它明确的命令。别只说“跑一下测试”要说“跑npm test -- user这个命令”。命令越具体它执行越准确。4.4 代码审查与人工把关智能体写的代码必须人工 review。这不是不信任它而是它和你的关注点不一样。它关注“功能对不对”你还要关注“风格统不统一、边界处理全不全、有没有引入隐患”。review 的时候重点看几类问题。一是边界条件智能体容易忽略空值、超长输入、并发这些情况。二是错误处理它可能只处理了 happy path。三是命名和风格它可能和你项目现有习惯不一致。四是依赖引入它可能为了图方便引入新库而你没打算加这个依赖。发现问题别自己改把问题描述给它让它改。这样它能从反馈里学习下次犯同样错误的概率会降低。4.5 提交与回滚策略改动确认无误后提交信息也让它帮你写。你可以说“根据这次改动生成一条 commit message遵循项目的提交规范。”它写的通常比你手写的更规范因为它会参考项目里的历史提交。回滚策略要提前想好。如果改完发现方向错了别在错误的基础上继续修直接丢弃改动重来。用git checkout或者git stash把工作区清干净然后重新描述任务。在错误方向上修补的时间往往比推倒重来还长。5. 常见问题与排查技巧实录5.1 智能体反复改不对同一个问题这是最常见的问题。表现是它改了一版测试还是挂再改一版还是挂来回好几轮。原因通常是它对根因的判断错了一直在治标。排查思路是让它停下来别改了先解释。你可以说“先别改代码告诉我你认为这个测试失败的根因是什么你的依据是什么。”它解释的过程中你往往能发现它的假设错在哪。纠正假设之后再让它改通常一次就过。如果它解释得也含糊那说明上下文不够。这时候把相关文件、报错信息、复现步骤重新整理一遍给它比继续让它瞎试有效。5.2 命令执行失败但智能体没察觉有些命令失败时不会抛异常只是返回非零退出码或者打印错误信息。智能体可能没注意到继续往下走导致后面全错。应对办法是在任务描述里明确要求“每执行一个命令检查退出码非零就停下来报告。”另外你自己 review 的时候也要留意它贴出来的命令输出里有没有被忽略的错误。5.3 上下文过长导致响应变慢变差会话开太久历史积累太多智能体的响应会变慢质量也会下降。表现是它开始重复之前说过的话或者把不相关的信息扯进来。解决办法就是前面说的按任务分会话。另外如果某个会话确实需要保留可以定期让它总结一下当前进展然后基于总结开新会话。总结相当于压缩上下文保留关键信息丢掉冗余。5.4 智能体擅自扩大改动范围你让它改 A它顺手把 B、C、D 也改了。这种情况通常是因为任务描述里没写清楚边界。预防办法是在任务描述里加一句“只改 X 文件里的 Y 函数其他文件不要动。”如果它还是动了别的review 的时候直接指出来让它回滚那些不必要的改动。5.5 常见问题速查表问题表现可能原因处理办法反复改不对同一问题根因判断错误让它先解释假设纠正后再改命令失败未察觉未检查退出码要求检查退出码非零即停响应变慢变差上下文过长分会话或总结后重开擅自扩大改动范围边界描述不清明确限定文件和函数范围复述需求离谱上下文不足补充项目背景和文件内容引入不必要依赖图方便review 时重点检查依赖变更5.6 几个我踩过的坑第一个坑是让智能体在没提交的工作区里干活。有一次它改着改着我发现方向不对想回滚结果工作区里还有我自己没提交的改动混在一起很难分离。从那以后我养成了先提交再让它动手的习惯。第二个坑是任务描述里用了“优化”这种词。它理解的优化和我理解的优化完全不是一回事。我说优化性能它去改了代码风格。后来我学乖了所有任务描述都带明确的验收标准。第三个坑是太信任它的测试结果。它说“测试通过了”我就没自己跑。结果它跑的是它自己写的测试而不是项目原有的测试。后来我要求它必须跑项目里已有的测试命令不能自己造测试。第四个坑是在一个会话里连续做了三个不相关的任务。到第三个任务的时候它把第一个任务的假设带进来了改出来的东西完全不对。从那以后我严格按任务分会话。6. 把智能体编程真正用顺手的几个心得用到现在我最大的体会是智能体编程的效率不取决于模型有多强而取决于你有多会“带”。它像一个能力很强但需要明确指令的新人你给的信息越准、边界越清、反馈越及时它产出越好。具体来说有三件事值得长期坚持。一是维护好项目约定文件这是所有任务的基础设施值得花时间打磨。二是养成小步验证的习惯别贪快一次改一点改完就验。三是认真做 review把每次 review 当成给它反馈的机会它会在你的反馈里慢慢对齐你的预期。还有一点是关于心态的。别指望它一次做对也别因为它做错就否定它。它的价值不在于替代你而在于帮你把那些重复的、机械的、需要来回翻文件的部分扛下来让你能把精力放在真正需要判断力的地方。这个定位想清楚了用起来就顺了。最后分享一个我最近在用的技巧让它每次完成任务后用三句话总结“改了什么、为什么这么改、还有什么没解决”。这三句话既是你 review 的索引也是它自己的任务收尾。养成这个习惯之后任务之间的衔接清晰了很多也不容易漏掉遗留问题。
Codex CLI 智能体编程进阶：从能跑到跑得稳的工程化实践
1. 从“能跑”到“跑得稳”Codex CLI 智能体编程的进阶思路很多人第一次接触 Codex CLI注意力都放在“怎么装、怎么登录、怎么让它生成一段代码”上。这很正常毕竟从零到一的那一步最有成就感。但真正把 Codex CLI 当成日常生产力工具用上一段时间之后你会发现一个很现实的问题让它生成代码不难难的是让它在一个真实项目里持续、稳定、可控地干活。这一篇作为系列第十一篇我想聊的就是这个阶段的事——从“能跑”到“跑得稳”。Codex CLI 本质上是一个跑在终端里的智能体编程工具它把大模型的代码理解与生成能力和本地文件系统、命令行环境、Git 工作流结合在了一起。你可以把它理解成一个坐在你旁边、能直接读写你项目文件的结对程序员。它和那种网页里复制粘贴代码的用法最大的区别在于它能感知上下文、能执行命令、能改多个文件、能根据报错自己迭代。这种能力一旦用顺了效率提升是肉眼可见的但一旦失控它也可能把你的项目改得面目全非。所以这篇文章适合两类人一类是已经装好 Codex CLI、能跑通基本对话但总觉得“用起来不太顺手”的开发者另一类是准备把它引入团队工作流需要一套可复现、可管控的实操方案的技术负责人。我会围绕智能体编程的核心思路、关键配置、实操流程和踩坑经验展开尽量把每一步背后的“为什么”讲清楚而不是只丢一堆命令让你照抄。在开始之前先明确一个前提Codex CLI 这类工具的能力边界很大程度上取决于你给它的上下文质量和约束条件。你把它当搜索引擎用它就是个高级点的补全你把它当有纪律的工程助手用它才可能真的帮你扛活。这个认知差异决定了后面所有配置和用法的走向。2. 智能体编程的核心设计为什么不能把它当“代码生成器”2.1 智能体与普通代码补全的本质区别普通代码补全的工作模式是“你写一半它猜一半”它的输入是你当前光标附近的代码输出是一段建议。整个过程是无状态的、局部的、被动的。而 Codex CLI 这类智能体的工作模式是“你给目标它规划步骤它执行它验证”。它是有状态的、全局的、主动的。这个区别带来一个很重要的后果智能体会“自作主张”。比如你让它“修复登录接口的 bug”它可能会先去读相关文件然后发现是参数校验的问题接着顺手把参数校验的写法统一了一遍最后还改了测试用例。这些动作里有些是你想要的有些可能超出了你的预期。如果你没有给它足够的约束它就会按照自己的理解去“帮忙”而帮忙的范围是不可控的。所以设计智能体编程工作流的第一原则是明确边界缩小爆炸半径。具体来说就是让它在可控的范围内做决策而不是放任它在整个仓库里自由发挥。2.2 上下文管理智能体编程的命门智能体能不能干好活七成看上下文。这里的上下文包括几层项目结构上下文、任务描述上下文、历史对话上下文、以及工具执行结果上下文。项目结构上下文指的是它能不能快速理解你的代码库长什么样。一个几万行、几十个模块的项目如果它每次都要从头扫描那既慢又容易抓不住重点。常见的做法是在项目根目录放一个约定文件把项目结构、技术栈、编码规范、常用命令写进去让它每次启动时先读这个文件。这相当于给新来的同事一份“项目入门手册”。任务描述上下文指的是你怎么跟它说话。很多人习惯说“帮我优化一下这段代码”这种描述对智能体来说信息量几乎为零。优化什么性能、可读性、还是内存占用约束是什么不能改接口签名还是可以随便改好的任务描述应该包含目标、约束、验收标准三要素。历史对话上下文指的是多轮交互中它记住的东西。这里有个坑上下文不是越长越好。太长的历史会稀释当前任务的权重还可能让它把之前任务的假设带到新任务里。所以该开新会话的时候就开新会话别在一个会话里塞十几个不相关的任务。工具执行结果上下文指的是它跑命令、读文件、看报错之后拿到的信息。这部分是智能体区别于纯对话工具的关键也是它容易“跑偏”的地方。比如它跑了一个测试看到一堆报错可能会误判根因然后朝着错误的方向改。这时候你需要及时介入给它正确的方向。2.3 权限与安全别让智能体“裸奔”Codex CLI 能执行命令、能改文件这意味着它有能力造成真实破坏。我见过有人图省事直接给它全权限结果它在一个没提交的分支上大改一通最后想回滚都找不到干净版本。这种教训一次就够了。合理的权限设计应该分层。读操作可以放开让它自由读文件、读目录、跑只读命令。写操作要收紧尤其是删除文件、执行危险命令、推送到远程仓库这类动作必须有人工确认环节。很多 CLI 工具都支持“确认模式”也就是它提出要执行某个动作时先展示给你看你点确认它才执行。这个模式在初期磨合阶段非常有必要。另外一定要养成“先提交再让智能体动手”的习惯。让它在干净的工作区里干活改完你 review 一遍满意就提交不满意就丢弃。这样无论它怎么折腾你都有一个安全的回退点。这个习惯看起来简单但能省掉无数麻烦。3. 关键配置与实操要点把智能体调教成靠谱队友3.1 项目约定文件的写法与作用前面提到项目约定文件这里展开讲讲怎么写。这个文件通常放在项目根目录名字各工具略有不同但作用一致给智能体提供项目级的背景知识。内容上我建议包含这几块。第一块是项目概述用三五句话说明这个项目是干什么的、技术栈是什么、主要模块有哪些。别写太长智能体不需要读你的产品文档它需要的是快速定位能力。第二块是目录结构说明把关键目录和它们的职责列出来。比如src/api放接口层、src/service放业务逻辑、src/utils放工具函数。这样它找文件的时候就不会乱翻。第三块是编码规范包括命名习惯、缩进风格、注释要求、错误处理约定。这部分越具体越好比如“所有异步函数必须用 try/catch 包裹并记录日志”比“注意错误处理”有用得多。第四块是常用命令比如怎么跑测试、怎么启动本地服务、怎么跑 lint。智能体需要知道这些命令才能自己验证改动是否正确。第五块是禁区明确告诉它哪些文件不要动、哪些操作不要做。比如“不要修改config/prod下的任何文件”、“不要执行数据库迁移命令”。这一块是安全底线必须写清楚。3.2 任务描述的模板化技巧跟智能体沟通最忌讳模糊。我总结了一个简单的任务描述模板实测下来能大幅提升一次成功率。模板包含四部分背景、目标、约束、验收。背景说明这个任务在什么场景下产生目标说明要达成什么结果约束说明不能碰什么、必须遵守什么验收说明怎么判断做完了。举个例子。模糊版“优化一下用户查询接口。”模板版“背景用户列表接口在数据量超过十万时响应超过三秒。目标把响应时间降到一秒以内。约束不能改接口的入参和出参结构不能引入新的外部依赖。验收本地用压测脚本跑一遍P95 响应时间低于一秒且现有测试全部通过。”后一种描述智能体拿到之后基本能自己规划出“先看现有实现、再分析瓶颈、再改、再验证”的路径。前一种描述它只能猜猜错概率很高。3.3 会话隔离与上下文清理一个常见误区是把所有任务都塞进同一个会话。智能体在长会话里会积累大量历史这些历史有好有坏。好处是它能记住之前的决策坏处是旧任务的假设会污染新任务。我的做法是按任务类型分会话。同一个模块的连续改动可以放一个会话跨模块的任务就开新会话。会话开多了不丢人反而说明你在有意识地管理上下文。另外当智能体开始“胡言乱语”或者反复在同一个错误上打转时最有效的办法往往不是继续跟它掰扯而是清空上下文重新描述任务。很多时候它卡住是因为早期某句话给了它错误的前提而这个前提在长上下文里很难被纠正。3.4 工具调用结果的解读与干预智能体跑命令之后会拿到输出然后基于输出决定下一步。这个环节是它最容易跑偏的地方因为命令输出往往信息量很大它可能抓错重点。比如它跑测试输出里有一堆 warning 和一个 error。它可能盯着 warning 去改而忽略了真正的 error。这时候你需要主动告诉它“先看 errorwarning 后面再说。”这种干预看起来是在打断它实际上是在帮它聚焦。还有一种情况是它跑了一个命令命令本身失败了但它没意识到失败继续往下走。这时候你要及时指出“刚才那个命令返回非零退出码说明失败了先解决这个。”智能体不像人那样对“失败”有天然的敏感它需要你提醒。4. 完整实操流程从接到需求到合并代码4.1 需求拆解与任务规划拿到一个需求别急着让智能体写代码。先让它帮你拆解。你可以把需求描述给它然后问“这个需求涉及哪些模块建议按什么顺序改每步的风险是什么”它给出的拆解不一定完美但能帮你快速理清思路也能让它自己对任务有个全局认识。拆解完之后把任务切成小块。每块最好控制在“一次会话能完成、一次 review 能看完”的粒度。太大的任务它容易中途迷失太小的任务又浪费交互成本。我的经验是一个任务如果改动超过五个文件就该考虑再切一刀。4.2 让智能体先读后写这一步很多人会跳过但它极其重要。在让它动手改之前先让它读相关文件并用自己的话复述一遍它理解到的现状。比如“你先读一下userService和userController然后告诉我现在用户查询是怎么实现的瓶颈可能在哪。”这个复述过程有两个作用。一是验证它有没有读懂如果它复述得离谱说明上下文给得不够你得补。二是给它自己建立认知基础后面改的时候不容易跑偏。4.3 小步改动与即时验证智能体改代码最忌讳一次改一大片。正确的节奏是改一小块跑一次测试确认没问题再改下一块。这样出问题的时候你能快速定位是哪一步引入的。具体操作上你可以让它“只改这一个函数改完跑一下相关测试”。它改完你 review没问题就继续。如果它一次改了好几个文件你 review 起来会很累而且一旦测试挂了排查范围很大。验证环节要给它明确的命令。别只说“跑一下测试”要说“跑npm test -- user这个命令”。命令越具体它执行越准确。4.4 代码审查与人工把关智能体写的代码必须人工 review。这不是不信任它而是它和你的关注点不一样。它关注“功能对不对”你还要关注“风格统不统一、边界处理全不全、有没有引入隐患”。review 的时候重点看几类问题。一是边界条件智能体容易忽略空值、超长输入、并发这些情况。二是错误处理它可能只处理了 happy path。三是命名和风格它可能和你项目现有习惯不一致。四是依赖引入它可能为了图方便引入新库而你没打算加这个依赖。发现问题别自己改把问题描述给它让它改。这样它能从反馈里学习下次犯同样错误的概率会降低。4.5 提交与回滚策略改动确认无误后提交信息也让它帮你写。你可以说“根据这次改动生成一条 commit message遵循项目的提交规范。”它写的通常比你手写的更规范因为它会参考项目里的历史提交。回滚策略要提前想好。如果改完发现方向错了别在错误的基础上继续修直接丢弃改动重来。用git checkout或者git stash把工作区清干净然后重新描述任务。在错误方向上修补的时间往往比推倒重来还长。5. 常见问题与排查技巧实录5.1 智能体反复改不对同一个问题这是最常见的问题。表现是它改了一版测试还是挂再改一版还是挂来回好几轮。原因通常是它对根因的判断错了一直在治标。排查思路是让它停下来别改了先解释。你可以说“先别改代码告诉我你认为这个测试失败的根因是什么你的依据是什么。”它解释的过程中你往往能发现它的假设错在哪。纠正假设之后再让它改通常一次就过。如果它解释得也含糊那说明上下文不够。这时候把相关文件、报错信息、复现步骤重新整理一遍给它比继续让它瞎试有效。5.2 命令执行失败但智能体没察觉有些命令失败时不会抛异常只是返回非零退出码或者打印错误信息。智能体可能没注意到继续往下走导致后面全错。应对办法是在任务描述里明确要求“每执行一个命令检查退出码非零就停下来报告。”另外你自己 review 的时候也要留意它贴出来的命令输出里有没有被忽略的错误。5.3 上下文过长导致响应变慢变差会话开太久历史积累太多智能体的响应会变慢质量也会下降。表现是它开始重复之前说过的话或者把不相关的信息扯进来。解决办法就是前面说的按任务分会话。另外如果某个会话确实需要保留可以定期让它总结一下当前进展然后基于总结开新会话。总结相当于压缩上下文保留关键信息丢掉冗余。5.4 智能体擅自扩大改动范围你让它改 A它顺手把 B、C、D 也改了。这种情况通常是因为任务描述里没写清楚边界。预防办法是在任务描述里加一句“只改 X 文件里的 Y 函数其他文件不要动。”如果它还是动了别的review 的时候直接指出来让它回滚那些不必要的改动。5.5 常见问题速查表问题表现可能原因处理办法反复改不对同一问题根因判断错误让它先解释假设纠正后再改命令失败未察觉未检查退出码要求检查退出码非零即停响应变慢变差上下文过长分会话或总结后重开擅自扩大改动范围边界描述不清明确限定文件和函数范围复述需求离谱上下文不足补充项目背景和文件内容引入不必要依赖图方便review 时重点检查依赖变更5.6 几个我踩过的坑第一个坑是让智能体在没提交的工作区里干活。有一次它改着改着我发现方向不对想回滚结果工作区里还有我自己没提交的改动混在一起很难分离。从那以后我养成了先提交再让它动手的习惯。第二个坑是任务描述里用了“优化”这种词。它理解的优化和我理解的优化完全不是一回事。我说优化性能它去改了代码风格。后来我学乖了所有任务描述都带明确的验收标准。第三个坑是太信任它的测试结果。它说“测试通过了”我就没自己跑。结果它跑的是它自己写的测试而不是项目原有的测试。后来我要求它必须跑项目里已有的测试命令不能自己造测试。第四个坑是在一个会话里连续做了三个不相关的任务。到第三个任务的时候它把第一个任务的假设带进来了改出来的东西完全不对。从那以后我严格按任务分会话。6. 把智能体编程真正用顺手的几个心得用到现在我最大的体会是智能体编程的效率不取决于模型有多强而取决于你有多会“带”。它像一个能力很强但需要明确指令的新人你给的信息越准、边界越清、反馈越及时它产出越好。具体来说有三件事值得长期坚持。一是维护好项目约定文件这是所有任务的基础设施值得花时间打磨。二是养成小步验证的习惯别贪快一次改一点改完就验。三是认真做 review把每次 review 当成给它反馈的机会它会在你的反馈里慢慢对齐你的预期。还有一点是关于心态的。别指望它一次做对也别因为它做错就否定它。它的价值不在于替代你而在于帮你把那些重复的、机械的、需要来回翻文件的部分扛下来让你能把精力放在真正需要判断力的地方。这个定位想清楚了用起来就顺了。最后分享一个我最近在用的技巧让它每次完成任务后用三句话总结“改了什么、为什么这么改、还有什么没解决”。这三句话既是你 review 的索引也是它自己的任务收尾。养成这个习惯之后任务之间的衔接清晰了很多也不容易漏掉遗留问题。
