企业官网建设流程全解析

很多 Agent 训练营的问题，是讲完一小时工具操作之后，你就不知道该拿它做什么了。这次两天实操训练营的主题是“CC/Codex 自动实证”，说白了就是拿 CC 和 Codex 这两款终端侧 AI 编码智能体，在真实项目里硬碰硬跑两天。跟坐在屏幕前看演示完全不同，每个人都要把自己的项目目录打开，让 AI 自己读代码、改文件、跑命令、看报错，然后交出一个能合的 diff。这篇内容不是课程宣传，是参与之后的完整复盘，把训练营怎么设计、工具怎么选、任务怎么拆、坑怎么躲，都按可复现的方式写出来。

1. 训练营定位：为什么是 CC 和 Codex，这“两天”要解决什么

1.1 它解决的真实痛点是“会用”但不“会干”

报名之前，我其实已经处在“会用”AI 编码工具的阶段：打开聊天窗口，把报错信息粘进去，把相关代码片段复制过去，拿到建议再手动改回来。表面上省了点查文档的时间，实际上大量精力消耗在上下文搬运上。遇到跨文件、跨逻辑的问题，AI 往往只能凭转述做发散推理，给出一堆看似合理但并不能落地的假设。

训练营想解决的，就是这类“伪效率”。它要求你彻底切换使用方式：不再把自己当作信息的搬运工，而是让智能体直接存活在项目目录里。CC（Claude Code 的常用缩写，下文按社区习惯简写成 CC）和 Codex，都是这种模式的代表工具。它们能自己搜文件、读源码、执行测试、生成补丁，甚至在你没盯着的时候把整个任务跑完。

第一天开场，讲师定的铁规矩确实有点反常规，但又很实在：全营不许把智能体当聊天问答来用，所有任务必须发生在本地仓库里，必须让它自己检查报错并修改代码。这句话帮我重新校准了对 Agent 的预期——它不该是一个“更聪明的搜索框”，而更像一个能拿到代码库上下文、可以直接执行操作的新协作角色。

1.2 选 CC / Codex 当训练营主角的理由

现在能叫“Agent”的编码工具不少，但训练营只挑这两款是有原因的。它们的核心体验足够完整：既有终端内直接执行命令的能力，也有在多个文件中做一致改动的能力，还支持人工确认、测试驱动、规则定制等贴近真实工程流程的机制。

更关键的，这两款工具在交互哲学上恰好互补。CC 是对话驱动的探索型 Agent，适合需求模糊时边聊边改；Codex 偏向任务派发型，你给它一个相对完整的诉求，它会拆步骤、读文件、执行、汇报，像一个领了工单就自动进展的协作者。把两者放在同一期训练营里对比学习，比只学单一工具有价值得多——你能从中理解“指令工程”在不同交互模型下如何调整。

另一个理由是它们都适合本地项目实操。不依赖云端网页控制台，配置好后直接在仓库里工作，训练营里几十个人同时开工也带得动。再加上两个工具都支持把规则文件放项目根目录，这为训练营设计“同一套工程规范、两种执行习惯”的对比任务提供了条件。

1.3 适合什么人，以及需要的基础

从最终参与者的构成看，训练营主要覆盖两类人。一类是已经在用 AI 助手、但觉得效率上不去的开发者，他们的问题往往不是“不会问问题”，而是还没有建立 Agent 化的工作流。另一类是团队里的技术负责人或工具布道者，他们想评估“这个工具放进我们仓库到底行不行”，需要的是快速判断哪些任务能交、哪些任务暂时不能交。

基础要求其实不高：能打开终端，会用 Git 基本操作，理解“测试—报错—修复”的循环，就够了。至于智能体的参数调优、上下文管理、权限壳配置这些能力，训练营默认你之前没碰过，所有概念都是从命令行启动开始逐步带起来的。相比传统“从入门到放弃”的教程，两天内安排的是连续的小任务，每完成一个都能立刻看到智能体的产出，这种即时反馈比背 API 文档有效得多。

2. 开工前的工具认知：CC 和 Codex 到底差在哪

2.1 CC：更贴近“结对资深同事”的终端助手

CC 在项目目录里启动后，默认进入一段持续对话。你可以让它“先看一下这个模块的结构”“找出最近三天被修改的文件”“把这段逻辑重构成策略模式”，它会通过读取文件树、打开具体代码、执行命令等方式逐步推进。整个过程更像和一个资深同事结对：你出主意，它动手，中间有任何不确定，你再插一句纠正。

CC 的强项在于对长上下文的处理。一个涉及多个文件、多个调用链的重构任务，它能保持较完整的项目认知，而不是聊了两轮就忘记前面的约束。我到现在都习惯把 CC 当作“探索型任务”的首选：需要先理解一段遗留代码、再决定怎么改的时候，让它在对话里把推理过程展示出来，比直接要一个最终 patch 更可控。

它的权限模型也给得更细。可以在配置文件里白名单化命令，比如只允许读目录、运行测试、执行格式化，不允许碰网络请求或强制推送。对于还没有完全信任 AI 自动改代码的团队，这种“逐步授权”的设计很友善。第一天训练营里，几乎一半人第一反应就是先收紧权限，再慢慢放开，这个倾向本身就说明了问题。

2.2 Codex：更强调“自动跑完任务”的流水线执行者

Codex 的另一味道在于起始方式。你给它一句话，它可以自己把任务拆成多步独立推进，而不是每走一步都等你点头。比如“给登录接口增加验证码校验，并补上单元测试”，它会先明确实现方案、列出要改的文件清单，然后实际动手修改代码，执行相关测试，再把失败项继续修掉。中间不需要你贴代码给它，因为它本来就在仓库里。

这种模式的好处是，适合“需求已经清楚，就差落地”的任务。它倾向于生成结构完整的产物，比如代码补丁、测试用例、执行日志，并且会自动给自己按顺序排步骤。在训练营第二天做 bug 修复闭环时，这个特性体现得很明显：智能体面对一个突然失败的回归测试，能自己追踪失败原因、修复实现、再把相关测试全部跑一遍，最后汇报改动范围和验证证据。

它也有需要适应的地方。因为自动执行力度大，你在下指令前就得把约束说清楚：哪些目录不要动、哪些文件是只读参考、哪些命令不能执行。这其实训练出一种好习惯：把需求像写工单一样写得具体一点。含糊的需求进 Codex，大概率会得到一个“能做但不由你想要的方式”的产物，这一点后面会专门说。

2.3 用一张表把选型逻辑说清楚

训练营的第二天，助教团放了一张对比表，把两个工具的使用倾向直接摊开。我根据自己的实战体验整理成更完整的版本：

当然，这不是“谁更好”的对比，而是两种工作风格。一天下来，训练营里不少人都说自己是“CC 探索开了头，Codex 收尾执行”，这个组合确实很顺手。但如果你只选了其中一个，也别觉得缺了什么，关键是先把一套完整流程跑熟。

3. 核心实操循环：让 Agent 真正“自动”起来

3.1 第一步：把问题“翻译”成三段式指令

训练营让我收获最大的，是“目标—边界—验收”的指令结构。很多人在 Agent 工具上跑不出理想效果，问题不在工具，而在需求随口说出去了。比如“帮我修一下日志模块”这种话，交给再强的 Agent 也只会给你一个随机猜测方向的改动。

训练营推荐把指令拆成三段：

• 目标：你要它产出什么，带具体文件和功能描述；
• 边界：明令禁止做什么、哪些目录不能碰、哪些文件只能读；
• 验收：怎么判断活已经干完，比如执行哪条测试命令才算通过。

举个例子，我想让智能体写一个日志清理脚本。用“目标—边界—验收”翻译后的指令会是这样：

目标：新增 scripts/clean_logs.py，扫描 logs 目录下修改时间超过 7 天的 .log 文件，并在 dry-run 模式下只打印待删除列表，不真正删除。 边界：不得修改 logs 之外的任何文件，不得删除非 .log 文件。 验收：运行 python scripts/clean_logs.py --dry-run，输出应只列出 7 天前的 .log 文件；去掉 --dry-run 后再次运行，对应文件被删除。

这段指令给出去之后，Agent 再也不是“猜你想改哪里”，而是按你划定的轨道执行。看起来多花了一分钟写约束，实际上省掉了后面好几轮返工。训练营第一天下午的小作业，就是用这套结构替换掉所有人“随手一句”式的旧指令，对比结果非常真实：同样一个任务，结构清晰的指令通常一轮通过，随口说的指令平均要三到五轮才能被拉回来。

3.2 第二步：建立测试护栏再放权

让 Agent 自动跑任务，最怕的是它信誓旦旦说“完成”，实际上把你仓库弄乱了。训练营的做法是：先给任务配好测试护栏，再让智能体放胆执行。所谓测试护栏，就是任务开始前，先把“通过/不通过”的判定标准写进项目里。比如让 Agent 实现一个新函数，那就在开工前先写好函数调用用例和断言；让 Agent 修一个 bug，那就先把预期行为固化成可重复运行的测试。

这个思路很像开车先系安全带。AI 编码智能体本质上是在不确定空间里做搜索，每一步都可能走偏。如果它跑完自己能执行一条测试命令来证明“我改对了”，整个任务就从“它说完成了”变成“验证体系说它完成了”。训练营里很多人的第一次“社死”时刻，都是因为没写测试就放手，结果 Agent 跑完自测时才发现自己只是在报告里补了句“通过”，而项目测试根本没运行。

所以现在我的个人习惯是：大改动的第一步，永远是先把测试或验证命令写好。这跟传统开发的测试驱动开发理念一致，只不过现在的“实行者”变成了智能体。测试护栏越清晰，你的审查负担就越轻，因为最终合并的依据不是 Agent 的一句话，而是那些绿了的测试输出。

3.3 第三步：异步迭代和结果验收

第二天开始，训练营的任务难度加大，动辄要跑十几分钟。这时最考验人的不是“会不会写指令”，而是“能不能在一旁安静等着”。很多学员忍不住每十秒刷一次输出，看到 Agent 停住就想打断，结果反而把它的思路切断了。助教反复提醒：除非 Agent 确实进入死循环或明显跑偏，否则让它自己迭代完，再一次性看结果。

这其实很反直觉。我们习惯了跟聊天式 AI 一来一回地对话，但 Agent 类工具最大的价值在异步执行：你交给它一个目标，它可以自己搜索、失败、重试、再失败、再调整，最后把结果摆在你面前。你只需要在关键节点做审查，比如看一下它改了什么、测试是否通过、有没有越界操作。

训练营为此设计了“验收清单”环节。每次智能体交付一个结果，学员不是直接说“可以”，而是按三个问题走一遍：需求里的验收标准是否达成？有没有修改声明之外的目录？测试结果是否真实可重复？这三问虽然朴素，但确实拦下了很多表面完成的假交付。尤其是第二问，Agent 有时会因为想“更周全”而顺手改了相邻文件，这种“过度好心”必须靠边界约束加人肉审查双重控制才能防止。

4. 两天实录：从搭环境到自动修 Bug 的真实记录

4.1 第一天上午：环境布置与第一个自动化脚本

训练营开始的头两小时，没有直接上“大招”。大家做的是最基础的环境准备：安装并登录 CC 和 Codex 的官方终端工具，确认自己有权限在本地仓库执行命令，再跑通第一次最小交互。

我当时的 Demo 仓库是个简单的 Python 服务，第一步任务朴素得很：让智能体在仓库里新增一个 Makefile，提供一个make check命令，作用是依次运行格式化检查和单元测试。听起来很基础，但里面已经有几个坑点。Agent 需要先读懂项目结构才能写出正确的 Makefile 目标，它得知道测试命令是pytest而不是python -m unittest，还得把格式化工具的实际配置找出来。

我第一次没有写清楚“用什么工具做格式化检查”，智能体自作主张选择了一种没装进环境里的工具，结果make check跑起来直接报“命令不存在”。这个失败非常典型。修正也很简单，在边界里补一句“必须使用项目 requirements 里已有的格式化工具”就解决了。后来想想，这跟我们平时带实习生是一个道理：第一次交办任务，得先说明现有的工具栈，否则新人就会用自己的习惯去理解，然后产出对不上的东西。

4.2 第一天下午：让 Agent 独立完成小模块

下午的任务开始升难度：在一个爬虫项目里新增一个 URL 去重模块，要求用布隆过滤器实现，并且要把新模块接入已有的调度流程。表面看是小模块，实际已经涉及“新建文件、修改入口、补充测试、跑通集成”四个子步骤。

我在指令里给出的验收条件是：本地测试里新增 5 个 URL 去重的用例，全部通过；调度流程里能看到对新模块的调用。Codex 拿到任务后，自己把四个子步骤列了出来，然后逐个执行。中间它读了两遍调度代码，因为第一次找到的调用位置跟测试期望不一致。它自己纠错的方式也很有意思：不是直接改测试去迎合实现，而是重新读调用链，把修正落到正确位置。那一刻你会感觉到，它不是在机械拼代码，而是在按“让测试通过”的目标做搜索与验证。

CC 组同时做的任务稍微偏探索一点：不新增模块，而是把既有去重逻辑里一段 O(n^2) 的遍历改成哈希索引。CC 在过程中连续问了几个问题，比如“这段遍历的上层调用是否依赖元素顺序”“原函数返回结果是否允许顺序变化”。这些问题能有效挡住后期返工，也说明上下文充分的智能体确实能捕捉到隐藏约束。

4.3 第二天：跑通“报错-定位-修复-回归”的闭环

第二天的核心任务，是训练营里最像真实工作的环节：有意制造一个故障，让智能体从一条失败测试开始，独立完成定位、修复、回归验证。我拿到的故障是：项目里某个配置解析逻辑在处理空配置时抛异常，导致一个冒烟测试挂了。Agent 需要先运行测试、看到失败输出、追到解析函数、修复边界处理，再补一个针对空配置的用例，最后把整组测试全跑绿。

这个任务难度比前一天明显高，因为失败原因不在刚改过的代码里，而在一个很久没动的底层工具函数。Codex 的排查路径是：先跑失败用例，看到异常栈，指出配置为None时走了不该走的分支，然后定位到工具函数第几十行，顺手加了一个空值保护，并在上层调用点补了一个类型检查。整个过程大概十分钟，最终 diff 只碰了十行代码，干净利落。

CC 组同场做的是另一个故障：日志模块偶尔会把敏感字段明文打到磁盘。CC 没有直接动手，先做了一次搜索，找到所有调用日志模块的位置，评估哪几个字段需要脱敏，再改了一个公共方法，最后通知上层调用点不必各自改。这个处理路径非常有“老工程师”味道——先在理解全局上下文的基础上最小化改动，而不是见一个改一个。事后助教点评时说，这类探索性修复正是 CC 的长项，而 Codex 更擅长给一个明确的破坏性变更收尾。

5. 高频踩坑与避坑速查

5.1 上下文超限时的三种处理

两个工具在长任务里都容易出现上下文管理问题。任务跑了二十分钟之后，可能出现输出变慢、开始遗忘早期约束、甚至报上下文超限的情况。训练营里最常用的三个对策，按优先级排序：拆任务、清现场、换会话。

拆任务是第一优先级。一个看起来很大的改动，其实可以切成“先实现核心逻辑、再补边界条件、后集成到入口”三个阶段，每阶段单独发指令。清现场是指把已经完成的部分先提交或暂存到 Git，让工作区恢复干净，再让智能体基于新的代码状态继续。换会话则适合那种越聊越糊的对话，与其在一个超长上下文里修补，不如开一个新会话，把目标、边界、验收重新写一遍，反而更高效。

我自己的体会是：与其等到上下文快爆了才补救，不如一开始就预期它会爆。训练营第二天，我把一个涉及 6 个文件的改动主动拆成 4 个小任务，每个任务结束后立即让 Agent 汇报 diff 和测试结果。这样做的代价是每阶段多花几十秒写指令，收益是整个流程没有出现一次上下文混乱，稳定得让人意外。

5.2 Agent 起飞后怎么“拉回来”

所谓“起飞”，就是 Agent 在没有明确指示的情况下开始做一些不相干的事情，可能是顺手调整格式、提前重构、或者把没让你动的依赖升级了。训练营里有几个学员亲眼看着自己的 Agent 从“修复一个 bug”一路狂奔到“顺带把整个模块的命名都改了”，然后一脸无奈地回滚所有改动。

拉回的方法不在于强行打断，而在于你给的边界和它的检查点。第一层防线的指令约束，你已经知道了；第二层是会话里的明确禁止句，比如“你不要修改任何与超时处理无关的文件”。如果它还是起飞了，最好的做法不是继续在乱局里修修补补，而是先把工作区恢复到它起飞前的 Git 状态，然后重新给一次更窄的指令，同时强调先列计划、等确认再动手。

训练营里助教的一句话让我印象很深：不要在 Agent 的错误路径上给它纠错，那只会把对话引到更远的地方。正确做法是回到上一个安全检查点，换个更小步的路线再走。这句话几乎适用于所有 Agent 工具。

5.3 训练营里最容易被忽略的配置细节

很多“翻车”其实不是智能体能力的问题，而是配置没到位。最常见的是没有在项目根目录放规则文件，导致 Agent 按通用习惯写代码，跟项目既有规范不一致。训练营后半天，几乎所有学员都在仓库里加了一份轻量规则：写明项目语言、测试命令、禁止使用的依赖、编码风格偏好。加了这份文件之后，产出的代码质量立刻上了一个台阶。

另一个细节是命令权限。CC 的精细命令白名单和 Codex 的沙盒内执行，都需要你提前想清楚允许什么、拒绝什么。比如某些自动修改公共依赖锁文件的动作，建议直接在规则里禁掉。还有一点容易被忽略：默认情况下，Agent 可能不会主动运行测试，只会在你明确要求时才执行。如果你希望它在每次改动后都自动回归验证，请把“改完必须执行全量测试”写进行为约束里。

最后，记得把敏感信息隔离。训练营强调了不要让智能体读取包含密钥、内部账号信息的文件，如果你的仓库里存在这类内容，应该在规则文件里标记为“只读或忽略”，避免它在调试时把内容打印到对话输出里。

6. 我最后想分享的一个个人习惯

这次训练营之后，我给自己定了一个新规则：每天至少把一个三十分钟以内的改动，完整交给智能体来做，我只做需求拆解和结果审查。刚开始，我总会忍不住想抢键盘，看它改得慢就想去“帮一把”。坚持两周之后，心态就变了，我开始像一个真正的技术负责人那样思考，怎么把任务说清楚，怎么设验收标准，怎么从 diff 里快速判断这次改动是不是值得合入。

一个特别小的技巧分享一下：每次交付后，我会让 Agent 用三句话总结“改了什么、为什么这样改、验证结果是什么”。这个习惯看起来多此一举，但它逼着 Agent 输出可审查的推理过程，也让每一次人工 review 都变得轻很多。如果你也想在自己的项目里引入 CC 或 Codex，我建议不要从大重构开始，先拿一件小到不能再小的任务跑通闭环，然后慢慢加码。你会发现，真正难的从来不是让 Agent 写代码，而是你怎么把自己的需求，翻译成一个它能够执行、你也能够验收的工程任务。