企业官网建设流程全解析

1. 66.4% 这个数字到底在说什么

先把结论摆在前面：66.4% 不是某个模型的"智商分数"，也不是"AGI 达成度"，它来自 Terminal-Bench 这类终端任务基准上的通过率。Terminal-Bench 的设计思路很直接——给一个真实的命令行环境，让 Agent 在有限步数内完成一个可验证的目标，比如修复构建脚本、定位日志里的异常、按规范生成一批文件、跑通一条数据处理链路。评分方式是任务级的通过/失败，最后算总通过率。66.4% 意味着大约三分之二的任务被完整解决，剩下三分之一要么超步数、要么改错文件、要么在验证环节翻车。

这个数字之所以被反复讨论，是因为它踩在了一个心理阈值上。低于 50% 时，大家默认"这玩意儿还得人盯着"；超过 60% 之后，很多人开始重新评估"我到底还需不需要自己敲这些命令"。但这里有个容易被忽略的细节：基准任务的分布是人为挑选的，偏向"可自动验证、边界清晰、单文件或小范围改动"的场景。真实工作里大量的时间花在需求澄清、跨模块影响评估、和同事对齐接口这些无法被基准覆盖的环节上。所以 66.4% 更像是一把尺子量出来的一个切面，而不是一张全景图。

我在实际使用 Coding Agent 的过程中有一个很深的体会：它在"目标明确、反馈即时"的任务上表现远超预期，但在"目标模糊、需要反复确认"的任务上会迅速退化。这不是模型能力的问题，而是任务结构的问题。终端任务恰好是前者——命令跑完有明确的退出码和输出，对错一目了然。理解了这一点，你就能判断哪些活可以放心交出去，哪些活必须自己扛。

2. Terminal-Bench 的任务结构决定了分数上限

2.1 任务是怎么被构造出来的

Terminal-Bench 的题目通常包含三部分：一个初始环境（可能是一个有 bug 的仓库、一份不完整的配置、一堆待处理的文件）、一段自然语言描述的目标、以及一个隐藏的验证脚本。Agent 拿到前两部分，通过执行命令来探索环境、修改文件、运行测试，最后验证脚本判断是否达标。这个结构决定了它天然偏向"可脚本化验证"的任务。

我拆过几道典型题目，发现它们有几个共同特征：目标状态可以被一条命令检验（比如pytest全绿、某个文件存在且内容匹配正则）、初始环境是自包含的（不依赖外部网络和私有服务）、任务描述里隐含了足够的线索（不需要额外追问）。这三点凑齐，任务才可复现、可评分。反过来说，任何不满足这三点的真实工作，都不在这个基准的覆盖范围内。

2.2 为什么 66.4% 不等于"能替代三分之二的工作"

这里要区分两个概念：任务通过率和工时替代率。一个任务通过，不代表它省下了人类完成该任务的全部时间。Agent 在探索阶段可能跑了大量无效命令，在失败重试上消耗了很多步数，最后虽然通过了，但总耗时未必比人短。更关键的是，通过率是按任务数算的，而真实工作里任务的价值分布极不均匀——一个关键模块的重构可能顶得上一百个琐碎的小修小补。

我自己的经验是：把 Agent 用在"高频、低风险、验证成本低"的任务上，收益最明显。比如批量重命名、按模板生成配置文件、跑一遍 lint 并修复明显问题、把一段日志里的错误模式提取出来。这些任务单个人做也就几分钟，但一天累积下来很可观，而且失败了立刻能发现。反过来，涉及数据库迁移、权限变更、生产配置修改的任务，即使 Agent 声称通过率很高，我也不会让它直接执行。

2.3 基准分数和真实体感之间的落差来源

落差主要来自三个地方。第一是环境差异：基准环境干净、依赖固定，真实环境里可能有历史遗留的脏数据、版本冲突、权限问题。第二是反馈延迟：基准里跑个测试几秒钟出结果，真实项目里一次完整构建可能十几分钟，Agent 的试错成本被放大。第三是隐性约束：基准任务不会告诉你"这个函数被三个下游服务依赖，改签名要同步更新"，但真实工作里这种约束无处不在。

提示：看到任何基准分数，先问三个问题——任务怎么选的、验证怎么做的、失败怎么算的。这三个问题的答案决定了这个分数能外推到多远。

3. Coding Agent 在终端里的真实工作链路

3.1 从自然语言到命令序列的翻译过程

一个 Coding Agent 处理终端任务时，内部大致走这么几步：解析任务描述，提取关键目标和约束；扫描当前目录结构，建立环境认知；规划一个初步的命令序列；执行第一条命令，读取输出；根据输出调整下一步；循环直到达成目标或耗尽预算。这个循环里最关键的是"根据输出调整"这一步，它决定了 Agent 是在盲目试错还是在有方向地收敛。

我观察过不少 Agent 的执行轨迹，发现表现好的那些有一个共同点：它们会先做低成本的信息收集（ls、cat、git status、grep），再动手改东西。表现差的则倾向于直接猜一个命令然后跑，错了再猜。这个差异在简单任务上不明显，但在复杂任务上会迅速拉开差距。所以如果你在配置 Agent 的工作流，不妨在系统提示里明确要求它"先侦察、后行动"。

3.2 工具调用中的步数预算与收敛策略

步数预算是 Agent 的一个硬约束。给太少，它还没摸清环境就被迫交卷；给太多，它可能在错误方向上反复折腾。我的经验是，对于"定位并修复一个已知类型的 bug"这类任务，20 到 40 步通常够用；对于"从零搭建一个可运行的小项目"，可能需要 60 步以上。关键是设置一个合理的提前终止条件——比如连续几步没有任何文件变更，或者验证命令连续失败且错误信息没有变化，就应该停下来重新规划，而不是继续硬试。

这里有个反直觉的点：有时候给 Agent 更多步数反而降低成功率。因为它会在一个错误假设上越陷越深，每多跑一步就多一层"沉没成本"，越不愿意推翻重来。所以我在自己的流程里会加一个"重启阈值"——如果同一个错误出现三次，就强制清空上下文重新开始，而不是让它继续在旧轨迹上修补。

3.3 验证环节为什么是成败分水岭

验证环节是很多 Agent 翻车的地方。它们可能改对了文件，但没跑验证命令；或者跑了验证命令，但没正确解读输出；又或者验证通过了，但改动了不该改的东西。我见过最典型的失败模式是"局部正确、全局破坏"——Agent 为了让某个测试通过，把另一个测试搞挂了，而它只盯着眼前那个测试。

所以一个可靠的 Coding Agent 工作流必须包含"回归检查"这一步。具体做法是：在修改前后各跑一次完整的测试套件（或者至少是受影响的模块），对比结果。如果修改前就有失败的测试，要记录下来作为基线，避免把历史问题算到 Agent 头上。这个习惯看起来笨，但能挡掉大量"看起来通过了其实埋了雷"的情况。

4. 把 Agent 用出价值的三类场景

4.1 场景一：环境侦察与信息聚合

这是我认为最被低估的用法。让 Agent 去回答"这个仓库的构建流程是什么""哪些文件引用了这个即将废弃的接口""最近的提交里有没有引入新的依赖"这类问题，它做得又快又全。人类做这些事要来回切窗口、翻文档、记笔记，Agent 可以一次性把相关文件、命令输出、依赖关系整理成一份结构化报告。

我常用的一个模式是：给它一个模糊的问题，要求它输出"结论 + 证据 + 不确定的地方"。比如问"这个项目的测试覆盖率大概什么水平"，它会去跑覆盖率工具、读配置、统计结果，最后告诉你数字和统计口径。这种任务风险极低，因为不改任何东西，纯读操作，即使它理解偏了，你一眼就能看出来。

4.2 场景二：重复性代码与配置的批量生成

第二类高价值场景是批量操作。比如给一批结构相似的模块补上统一的日志埋点、把散落在各处的硬编码配置抽到统一文件、按新规范重命名一批函数。这类任务的特点是模式固定、单次改动小、但数量多，人工做既枯燥又容易漏。Agent 的优势在于它不会因为重复而走神，只要模式描述清楚，它能一致地执行到底。

但这里有个前提：模式必须能被明确表达。如果你说"把代码改得优雅一点"，它会给你一堆主观判断；如果你说"把所有console.log替换成统一的 logger 调用，logger 从@/utils/logger导入"，它就能准确执行。所以用 Agent 做批量任务，功夫花在"把规则写清楚"上，而不是花在"盯着它改"上。

4.3 场景三：失败日志的定位与初步修复

第三类是排错。给 Agent 一段报错日志和一个可复现的命令，让它定位根因并给出修复方案。它在"从错误信息反查代码位置"这件事上效率很高，尤其是当错误信息里包含文件路径和行号时。我经常用它来快速判断"这个报错是环境问题还是代码问题"，因为它会去检查依赖版本、环境变量、文件权限这些容易被忽略的地方。

不过要注意，Agent 给出的"修复方案"需要你复核。它可能治标不治本，比如把报错的那行注释掉让程序跑起来，而不是解决根本原因。我的做法是让它同时给出"临时绕过方案"和"根本修复方案"，然后我自己判断该用哪个。这个习惯能避免很多"跑是跑起来了但埋了更大的雷"的情况。

5. 那些基准分数不会告诉你的坑

5.1 上下文污染导致的连锁错误

Agent 在一个会话里待久了，前面犯的错会污染后面的判断。比如它一开始误以为某个配置文件在 A 目录，后面所有操作都基于这个错误假设，即使中途有证据表明文件其实在 B 目录，它也可能因为"已经做了这么多步"而继续错下去。这个现象在长任务里特别明显。

我的应对办法是分段执行。把一个长任务拆成几个独立的子任务，每个子任务开一个新的会话，只带上必要的上下文。这样虽然损失了一些连续性，但避免了错误累积。另一个办法是在提示里明确要求它"每完成一个阶段就重新确认当前状态"，强制它定期回到事实层面。

5.2 权限边界与破坏性操作的拦截

Agent 默认不会区分"读操作"和"写操作"的风险等级。它可能为了排查问题而执行rm、git reset --hard、修改系统配置这类破坏性命令。基准环境里这些操作无所谓，因为环境是一次性的；真实环境里可能就是灾难。

所以我在任何真实项目里用 Agent，第一件事是设置权限边界：只读操作放开，写操作限制在特定目录，破坏性命令一律需要人工确认。具体实现方式取决于你用的工具，但原则是一样的——把"能做什么"和"允许做什么"分开。这个设置花不了几分钟，但能挡掉绝大多数"手滑"级别的损失。

5.3 过度自信的输出与人工复核点

Agent 在报告结果时往往语气笃定，即使它其实不确定。它会说"已修复"而不是"我改了 X，你验证一下"。这种表达方式容易让人放松警惕。我的习惯是：不管它说得多肯定，关键改动都要自己跑一遍验证。尤其是涉及数据、金额、对外接口的改动，复核这一步不能省。

复核也有技巧。不要只看它改了什么，还要看它没改什么。比如它说"修复了登录逻辑"，你要确认它没有顺手改动权限校验。一个实用的方法是让它输出改动清单，逐条对照你的预期，多出来的改动要么有合理解释，要么回滚。

6. 人类程序员的坐标系该怎么重新校准

6.1 哪些能力在贬值，哪些在升值

贬值的是"记忆型"和"检索型"能力——记住某个 API 的签名、知道某个报错对应哪个 Stack Overflow 答案、熟练敲出一段样板代码。这些 Agent 做得又快又准，而且不会忘。升值的是"判断型"和"定义型"能力——判断一个方案在长期是否可维护、定义清楚一个问题到底要解决什么、在多个可行方案之间做取舍。

这个转变对程序员来说其实是好事。以前大量时间花在"把想法翻译成代码"上，现在这部分被压缩了，更多时间可以花在"想清楚要做什么"上。但前提是你得主动往这个方向走，而不是停留在"和 Agent 比谁敲代码快"的层面——那个比较没有意义，你赢不了，也不该赢。

6.2 从"写代码的人"到"定义问题的人"

我自己的转变过程是这样的：以前拿到需求直接想"这个功能怎么写"，现在先想"这个需求背后的真实目标是什么、有没有更简单的实现方式、验收标准是什么"。把这些问题想清楚之后，再决定哪些部分交给 Agent、哪些部分自己写。这个顺序的调整，让我的产出质量明显提升，因为很多需求在"想清楚"阶段就被简化甚至否决了。

定义问题的能力还包括"把模糊需求拆成可验证的子任务"。Agent 擅长执行明确的任务，不擅长处理模糊的目标。所以你的价值很大程度上体现在"把模糊变明确"这一步。这一步做得好，Agent 的产出就稳定；做得差，Agent 就会给你一堆看起来对但用不上的东西。

6.3 协作模式：把 Agent 当同事而不是工具

最后一个校准点是心态。把 Agent 当"更快的自动补全"用，你只能拿到边际收益；把它当"一个需要清晰指令、会犯错、需要复核的同事"用，你才能拿到结构性收益。这意味着你要给它足够的上下文、明确的验收标准、以及犯错后的反馈。就像带新人一样，指令越清晰，产出越可靠。

我现在的工作流里，Agent 承担了大概三成到四成的执行工作，主要集中在信息收集、批量修改、初步排错上。剩下的六到七成还是自己做，包括架构决策、关键逻辑、以及所有需要对外负责的部分。这个比例不是固定的，会随着任务类型浮动，但核心原则不变：Agent 负责"做"，我负责"判断做什么"和"判断做得对不对"。

7. 一套可复用的 Agent 协作流程

7.1 任务分级：什么交给它，什么自己扛

我按"风险 × 可验证性"两个维度给任务分级。低风险高可验证的，直接交给 Agent，比如生成测试数据、格式化代码、提取日志信息。低风险低可验证的，让 Agent 做初稿，自己复核，比如写文档、整理会议纪要。高风险高可验证的，让 Agent 做但必须跑完整验证，比如修改有测试覆盖的业务逻辑。高风险低可验证的，自己做，Agent 只做辅助侦察，比如改数据库 schema、调整权限配置。

这个分级不是绝对的，但能帮你在"想偷懒"和"怕出事"之间找到一个理性的平衡点。关键是每次交出去之前，先问自己：如果它做错了，我多久能发现？发现成本越高，越应该自己做或者加更多验证。

7.2 提示词里的四个必备要素

我给 Agent 写任务描述时，尽量包含四样东西：目标（要达成什么）、约束（不能碰什么）、验收标准（怎么算成功）、输出格式（结果怎么给我）。这四样写清楚，成功率会明显提升。举个例子，与其说"优化一下这个脚本"，不如说"把这个脚本的执行时间降到 10 秒以内，不能改变它的输出格式，改完后跑./run.sh --test验证，把改动点和耗时对比告诉我"。

约束这一项特别容易被忽略，但它往往是防止 Agent 闯祸的关键。明确告诉它"不要修改 X 目录""不要升级依赖版本""不要动数据库"，能挡掉很多意外。我甚至会在提示里写"如果不确定某个操作是否安全，先问我"，虽然它不一定每次都问，但至少给了它一个停下来的理由。

7.3 结果验收：三个必须检查的点

Agent 交付结果后，我固定检查三件事。第一，改动范围是否符合预期——有没有多改、少改、改错地方。第二，验证是否真的通过——它说通过了，我要自己跑一遍，或者至少看它跑的输出。第三，有没有引入新的问题——跑一遍回归测试，对比修改前后的结果。

这三步看起来繁琐，但熟练之后也就几分钟的事。而且它能帮你建立对 Agent 的"信任校准"——你会逐渐知道它在哪类任务上可靠、哪类任务上容易出问题，从而更精准地分配工作。这个校准过程本身就是一种能力积累，比单纯记住某个模型的分数有用得多。

8. 关于 AGI 讨论的一点个人看法

66.4% 这个数字被拿来讨论 AGI，我觉得更多是话题性的，而不是技术性的。AGI 的定义本身就没有共识，有人按"能否完成任意人类任务"算，有人按"能否自主设定目标"算，有人按"能否持续学习"算。Terminal-Bench 测的是"在特定类型的终端任务上能否达成目标"，这个能力和 AGI 之间的距离，取决于你用哪个定义。

我自己的判断标准比较朴素：看它能不能在我没把问题说清楚的时候，通过提问把问题变清楚。目前我试过的 Agent 里，能做到这一点的还很少。它们更擅长执行明确指令，不擅长在模糊中主动澄清。这个能力一旦突破，讨论 AGI 才有实质意义；在那之前，66.4% 就是一个有用的工程指标，告诉我们"这类任务可以放心交出去了"，仅此而已。

把注意力放在"怎么用好它"上，比争论"它是不是 AGI"更有产出。我见过太多人花时间讨论模型的上限，却很少花时间研究怎么把它的下限用稳。而实际工作中，决定成败的往往是下限——它会不会在关键时刻掉链子、会不会在你没注意的时候改错东西、会不会给你一个看起来对但经不起推敲的答案。把这些下限问题解决好，66.4% 也好，80% 也好，都能变成实实在在的产出。