绝大多数人用AI编程工具只发挥了它百分之十的能力把代码贴进网页对话框问几个问题再复制回来。Claude CLI和Codex CLI这两款命令行工具才是真正让AI从“聊天助手”变成“Agent工程师”的关键入口。今天这篇文章我直接把自己从零开始摸索出的那几招拆开讲核心就一句话让AI进入项目目录干活而不是让它在聊天框里隔岸观火。这篇文章适合正在用AI辅助开发、但总觉得效率没有翻倍的工程师也适合想从网页版迁移到CLI的新手。1. 先看清CLI凭什么成为Agent工程师的主力战场1.1 从网页聊天到命令行到底变了什么网页聊天版AI最大的问题不是回答质量而是它和你的代码库之间有一堵墙。你让它改一段代码你得先把文件内容复制过去它改完了你又得手动粘贴回来。来回几次上下文就断了你还要反复补充背景信息。CLI的核心进步在于它默认感知到你所在的目录。你启动Claude CLI或Codex CLI后它能看到当前项目的文件结构、Git状态、已有代码甚至可以主动读写文件、执行终端命令。换句话说它不再是一个回答问题的对象而是直接参与工作流的协作者。我习惯用生活里的例子解释这件事网页聊天像是你隔着窗台喊隔壁师傅帮你修水管你得把水管拆下来递出去修完再递回来而CLI是师傅直接进了你家站在水管旁边动手修你只需要在旁边说清楚哪里漏、怎么改、什么不能碰。后者当然效率高。1.2 Claude CLI和Codex CLI到底擅长什么很多人的误区是“有了一个AI CLI就不用另一个了”。我自己的体会是这两个工具定位不同搭配使用反而更顺手。对比维度Claude CLICodex CLI长文本理解很强适合分析大段日志、技术文档偏代码生成和任务执行文本分析略弱多文件修改可以一次改多个文件但更依赖你的引导在仓库级任务上更主动能自己拆解步骤自动执行命令需要你确认关键命令对命令执行更积极适合跑测试、查报错任务规划适合逐步讨论和细化方案适合给出一个目标后让它自动推进上手难度低几乎是对话式略高需要给清楚任务边界所以我的选型习惯是需要梳理思路、理解历史代码、讨论技术方案时打开Claude CLI需要完成明确编码任务比如重构、补测试、修Bug时打开Codex CLI。两款工具的底层模型不同侧重点也不同你只用其中一个不亏但两个都掌握后你会发现很多活可以完全甩给它们。2. 装好环境少走一半弯路2.1 安装与登录两条命令快速就位安装CLI本身并不复杂我这里说两条最常用的安装路径实际包名以你当前官方文档为准。# 安装 Claude CLI npm install -g anthropic-ai/claude-code # 安装 Codex CLI npm install -g openai/codex装完之后第一步是登录认证。Claude CLI和Codex CLI一般都会引导你在浏览器中完成登录或者用API Key方式。个人开发者我建议直接登录账号简单省事如果是团队内部脚本化使用再考虑API Key注入环境变量。登录完成后先在任意目录执行一下版本检查claude --version codex --version看到版本号就算成功一半。我遇到过不少初学者卡在这一步报错原因大多是Node版本太低。这两款CLI通常要求Node 18以上所以先升级Node再重装全局包基本能解决。2.2 必配环境变量模型、超时、Git集成不要小看环境变量这是CLI稳定运行的隐形配置。我最常配的有三个维度模型选择Claude CLI可以通过ANTHROPIC_MODEL指定模型Codex CLI通过OPENAI_MODEL指定。不同模型的价格和速度差别很大日常开发用性价比高的处理复杂架构时再切到强模型。超时设置默认超时有时候不够用尤其是让Agent生成大文件或跑长任务时建议调高到300秒以上避免中途断掉。Git集成CLI自动读取Git状态能帮你判断当前改动。如果你不希望在远程仓库目录下执行需要设置忽略提示或手动选择。例如在Linux或macOS上你可以这样写入shell配置export ANTHROPIC_MODELclaude-sonnet export OPENAI_MODELgpt-5 export CLAUDE_CODE_TIMEOUT_MS300000Windows用户可以在PowerShell里用$env:变量名值临时设置或者直接在系统环境变量里配。配置完成后建议先跑一个最小任务测试连通性比如让CLI读取当前目录下的README.md并总结。2.3 三种运行模式交互、单次、管道装好了不代表会用这里我先讲清楚CLI的三种运行姿势。交互模式在终端直接输入claude或codex进入对话。这种模式适合探索式开发你一边看代码一边给反馈交互感最强。单次运行通过参数直接传一段提示词。比如claude 解释这个项目的模块结构CLI执行完就退出。这种模式适合自动化脚本也适合你在编辑器里快速调用。管道模式把其他命令的输出接给CLI。比如cat package.json | claude 帮我看这个依赖有没有安全隐患或者在脚本里解析日志、让CLI给出诊断意见。我最常用的是管道模式。它的好处是AI能直接读取实时数据不需要你人工复制粘贴。比如我排查线上报错时会让CLI直接读取日志最后五百行并给出分类归纳。3. 世界级Agent工程师的四个核心招式3.1 把任务拆成可验收的小需求很多人让AI写代码上来就是“帮我优化这个项目”这种模糊指令再强的Agent也会无从下手。世界级Agent工程师的第一招是把大目标拆成多个可验收的小需求。举个例子不要只说“提升图片上传模块的性能”要拆成在这个文件里把compressImage函数的时间复杂度从O(n²)降到O(n)保持返回格式不变增加一个单元测试覆盖1MB到10MB的图片输入一次只给一个明确任务。任务越清晰AI产出越接近预期你审查diff的时间也越短。我这里有一个非常实用的判断标准如果这个任务你自己能给出明确的“完成条件”那它就是可验收的。完成条件可以是“所有测试通过”“特定函数不再报错”“界面响应时间低于500毫秒”。把完成条件写进提示词Agent就相当于拿到了质检标准。3.2 写需求说明书而不是聊天记录AI在CLI里并不是靠连续聊很多轮来理解你它更希望你在第一轮就把需求说清楚。我建议每一轮核心任务都写一份简短的“需求说明书”包含四部分目标、涉及文件、约束条件、验证方式。模板参考目标在 src/utils/date.ts 中新增 formatRelativeDate 函数 涉及文件src/utils/date.tssrc/utils/date.test.ts 约束不改变已有函数签名返回格式为“x分钟前/昨天/日期” 验证运行 npm test确保 date 相关测试全部通过把这段话发给Claude CLI或Codex CLI它的行动方向会非常明确。相比一句“帮我写一个日期格式化函数”这种结构化说明让AI不需要再反问你一堆问题一步到位。我管这种方式叫“给AI写需求文档”。它本质上和人类工程师协作一样需求越具体交付越准。你甚至可以把这个模板放在项目根目录的AGENTS.md文件里让CLI每次启动都能读到效果更稳。3.3 放权给工具但设好边界Agent工程师和普通提示词用户的区别还在于你会不会放权。CLI可以自己读文件、改代码、跑命令但默认行为可能过于保守也可能过于激进。所以你需要显式设定边界。常见的授权方式有两种一种是对话中直接说“你可以执行测试命令但不要安装依赖”另一种是使用CLI配置里的权限控制功能设置允许的命令白名单和拒绝的命令黑名单。我自己设的边界是允许读取文件、运行测试、执行lint、查看Git diff禁止自动安装全局依赖、修改CI配置、向远程分支推送这样Agent既能完成核心工作又不会在我不注意时把项目环境搞乱。特别是自动安装依赖这个操作很多初学者放任不管结果CLI悄悄给你升了包版本老项目直接跑不起来。3.4 让Agent自证清白测试与diff复盘Agent写完代码后真正的考验才开始。世界级工程师不会直接信任输出而是会要求Agent自证清白。我的固定流程是要求Agent在完成修改后主动运行相关测试并贴出结果如果失败就继续修复直到通过。同时让它提供改动文件的diff摘要。你不需要看每一行但至少要看涉及的文件范围是否符合预期。比如你可以这样说完成修改后请运行 src/__tests__ 下的测试并贴出结果 如果测试失败请分析原因并继续修复 最后用 git diff --stat 展示你改动的文件清单。这一招能省掉你很多兜底时间。AI在生成代码时会有“幻觉样本”但它跑测试时骗不了人。测试通过、diff清晰基本可以放行如果测试不通过它自己修几轮往往比你去修更快。4. 实操复盘用CLI把一个图片压缩Demo从零做出来4.1 任务定义和验收标准光讲概念不够我这里用一个模拟项目“图片压缩Demo”演示完整流程。这个Demo的要求是在指定目录下批量压缩所有JPEG和PNG图片压缩后保持子目录结构输出目录可指定允许用户调整质量参数。验收标准定为三点输入目录和输出目录用命令行参数传入压缩后的图片能正常打开大小平均减少30%以上不改变原先文件名和目录层级这三点就是整个任务的核心接下来所有交互都围绕它们展开。4.2 第一轮交互生成骨架我把需求说明书发给CLI让它先不要急着写全所有代码而是先给出项目文件结构和核心函数签名。输入提示词请创建一个图片压缩Node.js脚本支持命令行参数 --input 输入目录 --output 输出目录 --quality 压缩质量0-100 要求保留目录结构输出一个项目骨架和核心函数签名先不要实现完整逻辑。很快就能得到类似结构src/ index.js 入口文件解析命令行参数 compress.js 压缩逻辑 walk.js 目录遍历逻辑这一步的意义是让我先确认方向。如果CLI误解了需求我此时纠正的代价很低。很多新手直接让它写完整个项目结果发现结构不对返工成本反而高。4.3 第二轮交互连接真实逻辑确认骨架无误后我让CLI填充具体逻辑。提示词里带上明确的“依赖什么库”和“输出格式”。使用sharp库实现压缩保留原文件的扩展名。 目录遍历用Node.js原生fs.promises实现。 质量参数传入sharp的compressOptions并做0-100的边界校验。 完成后创建一张最小测试图运行脚本验证输出。这次我特意指定了sharp因为它是高保真压缩里比较常用且稳定的库。CLI会帮我安装依赖、生成测试图、跑通流程。如果过程中遇到权限类问题它会停下询问我再确认。这一轮结束脚本已经可以运行。我手动检查了输出目录图片压缩率大概在28%到45%之间符合验收标准。4.4 第三轮交互收边界和错误处理最后一轮我专门处理“看起来正常但实际会出问题”的细节。比如图片文件为空或损坏时需要跳过并给出警告输出目录不存在时要自动创建并发压缩时机写了控制指令大量文件时也要稳定我把这些补充要求一次性发给CLI让它修改脚本并重新运行测试。它会把每个警告输出、目录自动创建、并发队列上限这些逻辑补进去。所以说CLI的价值不在于一次写完而在于你能像带一个中级工程师那样一轮一轮地“评审、反馈、打磨”。4.5 效率复盘整个Demo从零到可用手动写我大概需要四十分钟到一小时用CLI三轮完成大约只用了十分钟其中还包括我思考和补充需求的时间。但请注意省时间的核心不是键盘敲得少而是我每一轮都让Agent做了明确的事情没有让它瞎猜。这也是这篇文章反复强调的方法把任务拆细、写清验收标准、设好边界、最后测试兜底。5. 踩坑实录这些问题我替你先试过了5.1 登录成功却报401/403这类问题非常常见尤其是刚登录完马上运行任务。原因一般是以下几个当前终端会话没有读取到新的登录态需要重开终端环境变量里设置了旧的API Key覆盖了账号登录信息多个账号配置混乱CLI识别到的是权限不足的那个身份排查时可以先用claude auth status或codex auth list查看当前身份。如果显示异常就重新登录或者在配置管理里清除存量Key。我建议尽量统一使用账号登录不要同时混用账号和API Key否则会出现“看起来登录了但请求失败”的怪现象。5.2 上下文超长Agent开始“失忆”CLI最大的优势是能感知项目但这也意味着它容易把大量文件塞进上下文。上下文一旦超长模型会开始遗漏前面的细节表现为“重复问同样的问题”“改了A文件却忘了B文件依赖”。解决办法有几个使用.gitignore和CLI的忽略规则排除不需要的目录如node_modules、dist在提示词里指定“只看以下文件”而不是让它扫描整个仓库如果项目很大先把问题拆成子模块分多次对话处理我见过有人把一个几万行代码的仓库直接丢给Agent结果回答质量直线下降。记住CLI不是越“全”越好而是越“准”越好。5.3 Agent改完代码后项目跑不起来了这是新手最容易受挫的场景。Agent高高兴兴改完了十几处文件结果构建直接失败。原因是它在某个小改动上用了不兼容的API或者没有运行完整测试。遇到这种情况我不建议立刻手动回滚所有改动而是先做两步用git status和git diff查看改动范围判断问题集中点把构建失败的信息原样发给CLI让它自行定位并修复CLI能读取报错文件和上下文修复能力往往很强。如果它实在找不到我会git checkout -- 具体文件只回滚问题文件的改动保留其他有效修改。千万不要一气之下全部回滚否则好的改动也浪费了。5.4 Windows环境下的乱码和路径分隔符问题在Windows上用CLI时常见的坑是终端编码和路径格式。比如Agent生成的脚本里写死了/路径在PowerShell某些命令下会失效。我的建议是在Windows上尽量使用Windows Terminal并切换到UTF-8编码路径参数统一用绝对路径避免斜杠混乱如果CLI需要执行Shell命令优先让它在Git Bash环境运行。你可以给CLI配置默认Shell让它不要调用PowerShell来跑复杂的bash脚本。6. 我自己的效率心法6.1 从“写代码的人”变成“评审代码的人”用了CLI之后我最明显的改变是身份转换。过去我大部分时间在“写代码”现在我大部分时间在“下需求、审代码、验结果”。这种转变带来的效率提升是结构性的。写代码时AT人很容易陷入局部细节而评审人视角会让你更关注整体方向。CLI帮我处理重复劳动我把省下来的时间用于思考边界条件、系统设计和测试策略。我甚至建议你把自己想象成项目经理Agent是执行者你是指挥者。你不需要比它多写一行代码但你必须比它更清楚“为什么这么做”。6.2 适合用CLI的场景和不适合用CLI的场景虽然CLI很强但它不是万能钥匙。我梳理一下适合和不适用的场景适合用CLI的场景生成脚手架、重构已有函数、修Bug、补单元测试、分析日志、解释技术问题、批量处理文件。不适合用CLI的场景需要大量审美判断的UI微调、复杂度极高的架构讨论、涉及多团队沟通的需求分析。这类工作更适合人类主导AI只做辅助总结。了解边界之后你就不会因为一次失败而过早结论“CLI不行”。它只是不适合在这个场景里当主力。6.3 最后一招让CLI帮你写CLI最后分享一个我一直在用的技巧让CLI给你写一套日常工作的自动化脚本把重复的提示词固化下来。比如我每周都要检查项目的依赖更新、整理提交信息、生成周报。我会让CLI生成一个Shell脚本把这些操作串联起来。以后我只需要运行一句命令CLI就会自动执行并生成报告。这相当于把“Agent工程师的工作方法”变成你自己的工具箱。你用CLI建立一套个人工作流下次不管换什么项目调用者其实是同一套逻辑。我在实际使用中的体会是效率翻倍不是幻觉但它不是白来的。你得愿意花一点时间学习怎么向Agent下需求、怎么审它的代码、怎么让它自证结果。这几招练熟之后你会发现自己已经从“写代码的人”变成了“指挥Agent的人”那才是整篇文章真正想表达的跃迁。