企业官网建设流程全解析

绝大多数人用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 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_MODEL="claude-sonnet" export OPENAI_MODEL="gpt-5" export CLAUDE_CODE_TIMEOUT_MS=300000

Windows用户可以在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.ts，src/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的人”，那才是整篇文章真正想表达的跃迁。