企业官网建设流程全解析

最近这半年圈子里聊编程，几乎绕不开“Agent”这三个字母。从年初大家还在纠结 Copilot 能不能多补几行代码，到现在的 Claude Code、Codex CLI、Devin 轮番刷屏，工具迭代速度快得让人有点跟不上。我自己的感受很直观：以前写代码像是“夯地基”，一行一行垒，一个函数一个函数磨；现在更像是在“拉”，拉上下文、拉任务、拉整个工程的编译结果，AI 在中间把脏活累活接走了一大批。

这篇东西不是评测机构的那种打分排名，更像是我个人把接触过的 17 款编程 Agent 平台做了一次集中梳理。里面有重度使用的、有试过几天就弃的、也有一直留在工作流里当主力工具的。我会尽量把每款工具的核心定位、真实体验、适用人群和踩坑点讲清楚，尽量让你看完之后，能根据自己的项目类型和团队情况做出比较靠谱的选择。

1. “由夯到拉”：编程范式转换的底层逻辑

1.1 从“夯”到“拉”到底在说什么

“夯”这个字，核心意思是用力砸实地面，靠的是人力。传统编程很多时候就是这种状态——你得把需求一层层拆解成模块，把模块拆成函数，把函数写成每一行代码，然后再反复编译、调试、修错。这个过程极其依赖个人的经验积累，遇到不熟悉的领域，比如你写惯了 Java 突然要碰 Rust，前期“夯”的周期会特别痛苦。

“拉”则完全不同。它的思路是：你先把目标、约束、现有代码结构说清楚，AI Agent 能把相关的代码上下文“拉”过来，把合适的依赖库“拉”进来，甚至把 GitHub Issue、设计文档、API 文档、终端报错都“拉”到一起，然后生成一个完整的改动方案。

用一句粗糙但准确的话说：以前是“人在写代码”，现在是“人定方向，Agent 写代码，人做判断”。

我见过不少团队在引入这类工具的时候有个误区，觉得 Agent 就是更聪明的“代码补全”。真用起来之后会发现，补全和 Agent 之间隔着一条很深的鸿沟。补全工具面对的是“光标附近的几行”，Agent 面对的是“整个任务与整个仓库”。这不是模型参数量变大的问题，而是整个工作范式的变化。

1.2 Agent 和 Copilot 的本质区别

很多刚接触的朋友会问：GitHub Copilot 不也名字里带 Copilot 吗？它算不算 Agent？

我的理解是：Copilot 的形态更接近“超级自动补全”，它的默认工作方式是跟随光标，根据上下文预测你接下来要写什么。你仍然握着键盘，它负责提供候选代码。你可以把它想象成“高级输入法”，虽然在最新的 Copilot 里也加入 Agent 模式，但大多数人用它的心智模型还是以逐行写码为主。

真正的 Agent 平台，比如 Devin、Claude Code、OpenHands、Cline 这类，它们有点像是你团队里的“远程同事”。你给它一个任务描述，它自己会去看代码、自己决定改哪个文件、自己跑测试、遇到报错自己尝试修复。你更像是一个审阅者，而不是每一行代码的操作员。

所以我在选型时有个非常简单的判断标准：看这个工具是“你写它补”还是“你说它做”。前者无论宣传得多么天花乱坠，本质还是补全工具；后者才是真正意义上的 Agent。

1.3 编程工具的四代演进

为了理清思路，我把过去这些年编程工具的变化粗暴地分成四代：

第一代是文本编辑器，Vim、Emacs 这类。所有能力都靠插件和配置堆出来，对人的要求极高。第二代是 IDE，从 Eclipse 到 IntelliJ 到 VS Code，把项目管理、调试、重构、版本控制这些重度能力集成在同一个图形界面里，大幅降低了上手门槛。第三代是 AI 辅助编程，以 GitHub Copilot 为代表，模型能在你写代码的过程中实时补全，相当于给每个开发者配了一个“代码联想引擎”。

第四代就是我们现在正在经历的 Agent 阶段。它的标志性变化有两个：一是从“逐行补全”变成“任务闭环”，二是从“局限于编辑器”变成“能操作终端、浏览器、数据库等外部工具”。像 OpenAI Codex CLI 直接在终端里跑，Devin 甚至有一个自己的云沙箱环境，可以自主做很多事。这也是为什么现在大家都说“编程方式变了”——不再只是换了个自动补全工具，而是整个“需求到代码”的生产链路被重构了。

2. 17 款编程 Agent 平台全景盘点

这部分是全文的核心，我的分类逻辑是按照“工作形态”，因为同一个模型能力再强，如果形态跟你的工作流不匹配，也很难用起来。

2.1 深度绑定的 IDE 协同型 Agent

GitHub Copilot

Copilot 是绕不开的标杆。虽然它一开始是补全工具的定位，但现在已经默默长出了 Agent 能力，尤其是 Copilot Workspace 和针对 Visual Studio / VS Code 的 Agent 模式。实际操作里，它最厉害的地方还是“无缝”——几乎不改变你现有的开发习惯，装好插件就能用，企业版能直连 GitHub 仓库的 Issue 和 PR 上下文。

我的体验是，Copilot 最适合做“衬底工具”。什么叫衬底？就是你可能不觉得它多惊艳，但一旦关掉它，写代码速度立刻掉一截。它适合那些已经有明确思路、只是需要“手速更快”的场景，比如写模板代码、单元测试样板、重复性的 CRUD。真要做多文件重构或者复杂跨模块修改，它不如后面提到的专业 Agent 那么聪明。

适合人群：几乎没有门槛，推荐所有用 GitHub 管理代码的团队作为基础工具先用起来。

Cursor

Cursor 是这一波 Agent 浪潮里最大的受益者之一。它本质上是一个基于 VS Code 的 AI 原生 IDE，但把 AI 能力做成了第一公民。我最喜欢它的地方是 Composer / Agent 模式——你选中一段报错或者写一段需求文字，它可以直接跨文件改动，并且能自动跑命令行。

用 Cursor 的人通常会分成两派。一派把它当“更聪明的 VS Code”，只开 Tab 补全；另一派直接用 Agent 模式完成中型任务。我的建议是：如果是独立开发者或者小团队，Cursor 是全场景通吃的效率神器。但要注意，它虽然是 IDE，本质是魔改版 VS Code，插件生态跟原版基本兼容但也有小概率掉坑。另外它的模型订阅策略变过好几次，团队采购前务必去官网确认最新的计费方式。

Windsurf

Windsurf 是原 Codeium 团队的产品，后来改名为 Windsurf。它其实跟 Cursor 走的是同一条路：AI 原生 IDE。我用下来最直观的区别是，它在“编辑器内交互”上做了更多设计，比如 Cascade 面板可以直接看到当前 Agent 的思考过程、用到的文件、输出的命令，整个链路更透明。

如果你之前被 Agent 生成的“迷之改动”坑过，Windsurf 的透明性会让你安心一些。它对已有大型代码库的索引能力也不错，打开老项目和 monorepo 时搜索、跳转、定位相关的体验明显比 Cursor 初始状态下顺滑。缺点是生态和用户量不如 Cursor，遇到问题时的社区答案相对少。

Trae

Trae 是字节跳动出的 AI 原生 IDE，早期版本给我的感觉像“更适合国内场景的 Cursor”。国内用户拉代码、用国内大模型、对接字节系服务方便很很重要。它对中文的理解和生成质量是我用过的 AI 编程工具里第一梯队的，Agent 模式也能正儿八经跨文件做事。

不过要注意：Trae 在国内和国际两个版本之间的模型和功能有差异，如果是在海外团队工作，直接用国际版更稳；如果是国内团队，它在访问速度和合规上有天然优势。整体来看是个被低估的选择，建议中文技术团队认真试试。

2.2 开源与终端流派的硬核 Agent

Cline

Cline（原 Claude Dev）是 VS Code 生态里最早出圈的 Agent 插件之一。它不走“魔改 IDE”路线，直接在你现有的 VS Code 里装一个 Agent。它的设计逻辑很明确：允许 Agent 读取文件、编辑文件、执行终端命令、调用浏览器等，每一项操作你都可以在“计划模式”下审批。

Cline 最值钱的是它的“透明 + 可控”组合。你可以看到它每一步做了什么、为什么要做，能及时打断或者驳回。它支持接入 Claude、OpenAI、Gemini 等多种模型 API，灵活性极高，也是很多团队做二次开发和自动化实验的首选底座。缺点是全部自主可控意味着配置成本高，如果你不想折腾，它的体验不如 Cursor 开箱即用。

Roo Code

Roo Code 是 Cline 的一个分支，早期叫 Roo Cline，后来独立发展。它最大的卖点是“多模式”：可以分别定义 Architect、Code、Debug、Ask 等不同角色，每个角色用不同的 prompt 和模型，实现分工协作。比如架构师角色用强推理模型，写码角色用快模型，测试角色用低成本模型。

我刚才提到 Cline 时说的“透明可控”，Roo Code 继承得很彻底，而且自定义能力比母版更激进。适合喜欢折腾、对成本敏感、希望把 Agent 行为深度定制到团队规范里的开发者。缺点同样是学习曲线偏陡，新手第一次打开设置项可能会懵。

Aider

Aider 是终端里的老牌 Agent，支持命令行直接做代码修改。它最核心的能力是“和 Git 深度集成”——每一次 AI 改动都会自动创建 commit，你可以随意回滚、diff、查看每一步之间的关系。这种方式特别适合保守派程序员：AI 生成的每个改动都是有“痕迹”的，不会污染你的工作区。

用 Aider 时你的工作流会变成“写 prompt + 看 diff + 确认或回滚”，非常干净。它对大型代码库的处理走得是“地图 + 补丁”的路线，性能表现还不错。缺点是终端交互对很多人来说有门槛，如果你不习惯纯键盘操作，可能会觉得它反人类。

Tabnine

Tabnine 是老牌 AI 代码补全工具，主要面向企业私有化部署。很多大厂选它是因为可以完全离线、私有化、代码不出内网，对安全和合规要求极其严格的团队很友好。它现在已经从补全延伸到 Agent 能力，但核心定位仍然偏“保守型的辅助者”，不会像 Cline 那样激进地直接改你的代码。

我接触过几个银行和政企项目，他们选 Tabnine 的原因非常一致：不是因为它多聪明，而是因为它“安全可控”。所以我的建议是：如果你在强合规行业，Tabnine 仍然是兜底的首选；如果你追求上限，它能干的事 Cursor 基本都能干，且干得更多。

Sourcegraph Cody

Sourcegraph Cody 背后的优势是 Sourcegraph 的代码搜索和代码图谱能力。它非常擅长理解大型代码库，尤其是在处理跨仓库、跨服务、依赖关系复杂的场景时，能比多数 IDE 插件更快地定位到真正相关的代码。

如果你维护的是“n 个微服务 + 几十个仓库”的巨型项目，Cody 绝对值得试。它甚至能让你用自然语言搜索整个组织内的代码，这个能力在大型团队里很实用。缺点是独立 IDE 体验不够 Cursor 那么顺，配置起来有点麻烦。

Amazon Q Developer

Amazon Q Developer 是 AWS 官方的 AI 编程助手，跟 AWS 生态深度绑定。如果你天天跟 Lambda、S3、ECS、CloudFormation 打交道，它能直接从 AWS 服务文档和你的云资源上下文里找答案，这个能力是其他通用 Agent 很难比的。它也能做代码生成、重构、单元测试等常规操作。

它在“云上开发”这个细分场景里足够好，但放到通用编程领域，它的表现只能算中规中矩。它更像是 AWS 全家桶开发者的一把瑞士军刀，而不是全场景的编程 Agent。

2.3 云端生成部署型 Agent

v0

v0 是 Vercel 做的云端生成式前端工具，输入自然语言描述，它能直接帮你生成 React/Tailwind 的界面代码，并且实时预览。严格来说它不算是“全能编程 Agent”，但在“从 UI 概念到页面代码”这个环节，效率提升是惊人的。

新项目需要快速出原型、做落地页、做管理后台的初版界面时，v0 几乎是我的首选。它生成的代码质量相当能打，可以直接接到真实项目里。不过它擅长的始终是前端表现层，深入到业务逻辑和后端集成时需要你手动收拾。

Bolt.new

Bolt.new 是 StackBlitz 出的云 IDE，最大的特点是在浏览器里直接从零启动一个项目，包括 npm 安装依赖、跑 dev server，全都在云端完成，不需要本地环境。它可以算是一个“浏览器的 Agent + 云原生开发环境”。

对新手特别友好的是，你说一个项目想法，它能从项目脚手架开始一路帮你搭到能跑的页面。我建议把它当作“原型验证机”来用：任何新想法先进 Bolt.new 验证，跑通了再拉到本地项目里精细化。真的用它从零维护一个复杂生产项目，目前还不太现实。

Replit Agent

Replit Agent 是 Replit 平台内置的 Agent，主打“一个人 + 一句话＝一个可运行的应用”。它跟 Bolt.new 有相似之处，但 Replit 的老底子是云开发平台，在部署、数据库、域名关联这些环节上更顺滑。它甚至在生成代码之后能直接把应用部署上线，给你一个公开可访问的 URL。

我用它做过一些小工具和临时 demo，体验很丝滑。但它的定位更偏向“独立开发者的全流程助理”，离企业级多人在大型代码库上协作还有距离。如果你要的是“想法到上线的最小闭环”，Replit Agent 是最接近成品的一个。

2.4 自主规划执行与企业级 Agent

Devin

Devin 是 Cognition 团队做的“自主软件工程师”，代表了 Agent 的高规格形态：它不止在编辑器里改代码，而是有一套独立的云沙箱环境，有自己专属的 Shell、编辑器、浏览器。你给它一个 GitHub Issue，它会自己规划任务、改代码、跑测试、提交 PR，整个过程中你甚至可以在旁边看它的实时工作画面。

实际体验下来，Devin 在端到端任务执行上确实强，尤其是维护型工作，比如升级依赖、修 CI、加日志、处理 issue 清单这类耗时但不复杂的杂活。但它的成本相当高，而且遇到高度复杂、需要大量领域判断的架构调整时仍然容易跑偏。我的定位是：给团队配一个“永不疲倦的初级工程师”，而不是指望它替你做架构决策。

OpenHands

OpenHands 原名叫 OpenDevin，是开源社区里影响最大的通用自主 Agent 之一。它也是一套完整的 Agent 环境，可以部署在本地或自己的服务器上，支持接入不同模型，通过沙箱运行代码、操作文件系统、上网查资料。

它最大的价值在于“开放可控”：如果你是技术团队，想深入了解 Agent 内部原理、想定制自己的 Agent 流程、想接私有数据源，OpenHands 是很好的研究基座。相对地，它的稳定性、易用性和云端产品比还是差一些，部署运维成本不低。

Claude Code

Claude Code 是 Anthropic 官方出的终端编程 Agent，直接集成在命令行里。它在“在终端里理解整个项目、执行复杂多步任务”这件事上的能力相当强，对上下文的理解和长任务规划尤其好，因为底层的 Claude 模型本身在代码推理和长文本理解上很有优势。

它能直接读写仓库、执行命令、跨文件重构，跟 Git 工作流嵌合得很好。我的感受是，如果你已经习惯终端工作流，Claude Code 是效率上限最高的工具之一。它的缺点是 Anthropic 的定价不便宜，此外完全终端交互对新手和重度 IDE 用户不友好。

OpenAI Codex CLI

OpenAI Codex 大家应该不陌生，它是 OpenAI 代码模型的老名号。2025 年推出的 Codex CLI 直接以命令行形式开放，可以在终端里用自然语言驱动代码任务。它可以理解代码库结构，执行终端命令，自动修改文件和提交。

Codex CLI 的特点是“低调但高效”：没有花哨的图形界面，但代码生成质量和任务规划能力都在第一梯队，定位跟 Claude Code 很像。用它最大的感受是自然语言描述越清楚，输出质量越接近预期。对团队而言，它很适合做 CI 流程里的“自动化编码代理”，跑测试、改配置、处理小范围重构。

Gemini Code Assist

Gemini Code Assist 是 Google 的 AI 编程工具，覆盖 IDE 和终端场景，背后是 Gemini 系列大模型。它在代码生成、解释、测试生成上都有不错的表现，而且跟 Google Cloud 生态捆绑得比较紧。Jules 是 Google 的异步 Agent，可以挂载在 GitHub 上，自动处理 Issue 并提交 PR，适合当“后台小工”。

优点是接入 Google 全家桶顺畅，上下文窗口大，能吞下超长文件和处理复杂仓库。缺点也很明显：不同区域对 Gemini 服务可用性有差异，企业落地时要先确认合规和网络条件。

Augment Code

Augment Code 主打“企业级系统理解”，核心思路是把企业内部架构、代码库、文档、数据源全部索引起来，然后基于这些上下文做 Agent 辅助。它在大型企业的效果比在个人项目里更明显，因为个人项目并不需要那么重的“代码图谱”和“知识库”能力。

如果你所在团队的代码规模大、历史包袱重、文档散落各处，Augment Code 值得评估。它的短板是知名度相对低，社区反馈不多，采购前建议做一次深度试用。

3. 核心能力拆解：选型时真正该看什么

刚接触这一堆平台时，最容易眼花缭乱。我给团队做选型评估的时候，一般只看四个维度。

3.1 上下文窗口与代码库记忆

Agent 能不能解决问题，首先取决于它“看得到”多少上下文。模型上下文窗口决定了一次能处理多大体积的内容。现在主流模型动辄 200K 起步，但代码库往往几个 GB，所以 Agent 策略通常是先检索、再精读——先找到相关文件，再把关键内容塞进上下文。

这也就是为什么“检索能力”往往比“模型参数”更影响体验。Cursor、Copilot、Cody 这些做得好的，已经把代码索引、语义搜索融合进了 Agent 流程，你不需要显式告诉它某个文件在哪。而 Aider、Codex CLI 这类更轻量的工具，有时候需要你用命令手动“添加”相关文件，稍微多一点心智负担。

3.2 工具调用与执行权限

Agent 能“做事”而不是“提建议”，靠的是工具调用，包括执行 Shell 命令、运行测试、读写文件、查数据库、调 API 等。权限给得太宽，它可能乱改你的依赖、误删文件；给得太窄，它又什么都干不了。

所以选型时要问清楚：权限是默认放开还是按步骤审批？能不能设置黑名单/白名单命令？有没有沙箱隔离？Cline、Roo Code、OpenHands 在权限控制上都做得不错，Devin 则侧重云端隔离，Cursor 和 Copilot 的 Agent 模式在 IDE 内的权限设计也比较成熟。

3.3 多文件编辑与项目级重构能力

真正有体感的 Agent，必须能一口气改五六个文件，把接口定义、函数实现、调用方、测试全部串起来。很多工具单个文件生成很漂亮，一到多文件重构就开始互相矛盾，改完 A 文件忘了改 B 文件的调用方式。

我的测试方法很简单：丢给它一个真实的“重命名模块”或者“抽取公共组件”任务，看它能不能完成所有关联修改并跑通测试。像 Claude Code、Codex CLI、Cursor 的 Agent 模式、OpenHands 在这一项表现较好；老一代补全工具基本没有这个能力。

3.4 成本模型与团队落地

成本是个绕不开的坎。市面上的商业模式大致有几种：按订阅收费，比如 Cursor Pro 的月费固定；按 API 调用量收费，比如 Cline 和 Codex CLI 走的是模型 API 计费；按“任务/坐席”收费，比如 Devin 通常按 Agent 席位收高价；还有混合模式，比如 Copilot 企业版打包。

给团队选型时，我建议先做“日活估算”。每天跑多少 Agent 任务、平均消耗多少 token、高峰期并发是多少，然后拉一个 Excel 比较每家平台的月成本和人力成本替代率。很多团队因为只看单价被“野生 API 账单”坑过，所以务必提前规划好预算上限。

4. 实操配置与落地避坑

4.1 项目上下文工程：让 Agent 看懂你的仓库

不管用哪款平台，“读项目”这一步都是决定成败的。我见过太多人一上来就甩给 Agent 一个含糊的“帮我加个登录功能”，然后抱怨 Agent 写得乱七八糟。真相是，它根本不了解你们项目的技术栈、目录结构、代码规范。

多用“项目级说明文件”，把架构介绍、模块划分、命名规范、启动方式写清楚，这是投入产出比最高的一件事。Cline、Roo Code、Cursor 都支持把项目的说明文件作为固定上下文引入。稍微大点的项目，建议花半天时间整理索引信息，之后的 Agent 效果会上一个台阶。

4.2 Prompt 高效写法：描述结果而不是描述动作

跟 Agent 沟通和跟人沟通有一点很像：你要说清楚“要什么”，而不是“怎么做”。比如你说“给用户列表页加一个按状态筛选的功能”，不如说“用户列表页新增一个状态筛选器，支持按‘启用’‘禁用’‘待审’过滤，筛选后 URL 参数同步、刷新页面时保持选中状态、为空时展示统一空态”。后者给 Agent 的信息越充分，输出越接近你的预期。

写作 prompt 时可以遵循“背景 + 目标 + 约束 + 验收标准”四段式。背景是现状说明，目标是你要的结果，约束是技术栈、兼容性要求等限制条件，验收标准是可执行的测试条件，比如“点击筛选后请求参数必须包含 status 字段”。

4.3 权限与安全边界：别让 Agent 裸奔在主干上

现在多数 Agent 都能直接在终端里执行命令，这意味着它有“破坏力”。我的建议是把它当成“需要穿防弹衣的实习生”，给它设置好操作边界。先在一个独立的测试分支上跑 Agent 任务，代码评审通过后再合入主干；在 CI 和终端命令上设置关键命令白名单；涉及密钥、生产数据的操作必须人工完成。

无论是 Devin 还是 OpenHands，在处理敏感任务时都应该限制它的网络访问权限和密钥读取权限。安全问题不是“出了问题再处理”，而是工具链一开始就要框住边界。

4.4 常见问题与排查技巧速查

4.5 三条我实践下来的独家经验

第一条：把 Agent 输出当成“第一版草稿”，而不是“最终答案”。我见过太多人因为 Agent 写出来的代码看起来很像样，结果忘了做边界检查和安全校验，上线出了大事故。无论 Agent 多大程度替代了书写过程，review 和测试永远不能省。

第二条：留一个“Agent 不碰的文件清单”。部署脚本、数据库迁移、支付相关、鉴权相关，这些关键代码尽量人肉写。不是 Agent 能力不行，而是出错的代价太大，不值得把命脉交到一个概率模型手里。

第三条：学会“回滚式开发”。用 Aider、Cursor 这类支持 Git 联动或快照的工具时，让 Agent 每完成一个子任务就提交一次，然后你再 review diff。这样每个改动都可追溯，坏味道立刻就能发现，比最后一次性倒腾几百行再修要高效十倍。

5. 从个人效率到团队协作

5.1 多 Agent 协同与工作流编排

当 Agent 从“个人助手”变成“团队设施”，就要考虑更复杂的协作模式。现在常见的做法是“分工制”：用一个 Agent 做架构分析和规划，输出任务清单；另一个 Agent 按清单写代码；第三个 Agent 做 review 和测试。像 Roo Code 的 Architect/Code/Debug 多模式、OpenHands 里可自定义多个 Agent 实例，都是在试图解决这件事。

我在实际项目里更喜欢用“路由器 + 专家”的模式：Router 是主 Agent，负责理解需求、拆分任务、调度不同的专家 Agent。这种模式下，每类 Agent 只干自己最擅长的事，长期使用能积累出一套专属的 Agent 工作流，整体效率比“一个什么都会的通用 Agent”稳定很多。

5.2 引入 Agent 后的人效评估与工程规范

每次有团队问我“要不要引入 Agent”，我首先会问“你们有没有一套清晰的工程规范”。Agent 能放大产出，但也会放大混乱。如果代码提交前没有强制 lint、没有强制的测试覆盖、没有清晰的 code review 流程，那么 Agent 只会更快地制造出大量的“能跑但不可维护”的代码垃圾。

比较好的落地路径是：先定规范，再上工具。把分支规范、提交流程、测试要求、评审标准都固定下来，然后让 Agent 在这些约束内工作。人效评估不能只看“代码产出量”，还要看缺陷率、返工率、评审时间。我也建议大家先选一个小项目试跑一到两周，用量化数据判断是不是适合自己的团队。

5.3 从工具到流程，编程 Agent 时代的个人成长

工具变了，人不会失业，但“只会加班写重复代码”的人会很难受。编程 Agent 真正替代的不是程序员，而是“低价值劳动”。那些需要快速原型验证、需要大量样板代码、需要反复调试枯燥报错的工作，Agent 交出了远超人类的效率和耐力。而真正值钱的，是对需求的理解、对架构的判断、对代码质量的底线意识。

我个人的习惯是把 Agent 当成“杠杆”，自己把精力往更上游挪：多读需求文档、多跟业务方聊、多审视系统设计。以前一半时间在搬砖，现在搬砖的活有人干，剩下的一半时间就是实实在在的架构和交付能力提升。这也是“由夯到拉”最理想的结果——把人从体力劳动里解放出来，去做更需要判断力的事。

最后再说个细节：我使用这类工具这半年，最大的一个体会是“别迷信任何单一平台”。模型迭代周期越来越短，今天最强的不一定下个月还最强。与其沉没在某一个工具的细节里，不如把核心能力——比如写清楚 prompt、设计好项目结构、守住代码评审底线——打磨扎实。工具会变，这些基本功不会变。