企业官网建设流程全解析

1. 从“caveman”说起：一个AI编码代理的极简主义实践

第一次看到“caveman”这个词被拿来命名一个AI coding agent，我脑子里蹦出来的画面是：一个裹着兽皮、拎着石斧的原始人，蹲在终端前面敲代码。这个反差感本身就挺有意思——我们现在的开发工具越做越花哨，IDE插件满天飞，各种智能补全、代码生成、对话式编程助手层出不穷，结果有人反其道而行之，搞了个“原始人”出来。

但仔细一想，这个名字其实精准得很。caveman这个项目，核心思路就是用最原始、最直接的方式，让AI帮你写代码。它不搞复杂的图形界面，不搞花哨的插件生态，就是一个命令行工具，通过npx就能跑起来，背后对接的是AI coding agent的能力。你给它一个任务描述，它帮你生成代码、修改文件、执行命令，整个过程干净利落，没有多余的中间层。

这个项目解决的是什么问题？说白了，就是降低AI辅助编码的使用门槛。现在市面上很多AI编码工具，要么需要你装一堆依赖，要么需要你配置复杂的API密钥和代理设置，要么绑定某个特定的编辑器。caveman的思路是：你只要有Node.js环境，一条npx命令就能启动，剩下的交给它。对于那些不想折腾环境、只想快速让AI帮自己干点活的开发者来说，这个思路很对胃口。

适合谁来参考？我觉得三类人最值得看：一是刚接触AI编码代理的新手，想找个简单工具练手；二是经常在终端里工作的开发者，习惯命令行操作，不想切换到图形界面；三是对AI代理底层机制感兴趣的人，想看看一个轻量级agent是怎么把token、proxy、npx这些概念串起来的。当然，如果你已经在用Claude、Codex这类工具，caveman也可以作为补充，在某些场景下更轻便。

接下来我会从设计思路、核心细节、实操过程、常见问题几个维度，把这个项目拆开来讲。中间会涉及token管理、proxy配置、npx使用这些热词相关的技术点，也会分享一些我在实际使用中踩过的坑和总结的技巧。

2. 内容整体设计与思路拆解

2.1 为什么选择“极简命令行”这条路

AI编码代理这个赛道，现在大致分两个方向。一个方向是深度集成型，比如把AI能力嵌入到VS Code、JetBrains这些IDE里，做成插件或者原生功能，用户可以在编辑器里直接对话、补全、重构。另一个方向是独立代理型，比如各种CLI工具，你给它任务，它在终端里自己规划、执行、验证。

caveman明显属于后者，而且把“独立”和“轻量”做到了极致。它的设计哲学可以用一句话概括：能一条命令解决的事，绝不让你点三次鼠标。这背后其实是对开发者工作流的深刻理解——很多人在写代码的时候，手是不愿意离开键盘的，切换到浏览器或者图形界面去跟AI对话，本身就是一种打断。命令行工具的优势在于，它可以无缝嵌入到现有的终端工作流里，你甚至可以在tmux或者screen会话里跑着它，同时干别的事。

从技术选型上看，caveman选择用npx作为分发方式，这个决策很关键。npx是Node.js生态里的包执行器，它允许你在不全局安装的情况下直接运行某个npm包。这意味着用户不需要先npm install -g caveman，直接npx caveman就能用。对于工具类项目来说，这大大降低了尝试成本——你不需要做任何“安装”这个心理决策，试一下的成本几乎为零。而且npx会自动处理依赖下载和版本管理，用户永远拿到的是最新版本，不用操心升级问题。

另一个值得说的设计点是对token和proxy的处理。AI编码代理绕不开两个问题：一是怎么认证，二是怎么访问外部服务。caveman在这方面的设计思路是“尽量透明”，它会把token管理和proxy配置的细节封装起来，用户只需要提供必要的凭证，剩下的它来处理。当然，实际使用中这块也是最容易出问题的地方，后面我会详细讲。

2.2 核心架构的取舍：轻量 vs 功能

一个AI coding agent的核心能力，无非是这几块：理解任务、规划步骤、生成代码、执行操作、验证结果。caveman在这几个环节上都有自己的取舍。

理解任务这块，它依赖的是底层大模型的能力。caveman本身不做复杂的prompt工程，而是把用户的输入直接传给模型，让模型自己判断该干什么。这种做法的好处是灵活，用户可以用自然语言描述任何任务；坏处是对于复杂任务，模型可能会跑偏。我的经验是，用这类工具的时候，任务描述要尽量具体，比如“在src/utils目录下创建一个date.js文件，导出一个formatDate函数，接受Date对象返回YYYY-MM-DD格式的字符串”，就比“帮我写个日期格式化工具”要好得多。

规划步骤这块，caveman采用的是单步执行+反馈循环的模式。它不会一次性生成一个巨大的执行计划然后闷头跑到底，而是每一步执行完都看一下结果，再决定下一步。这种模式更接近人类开发者的工作方式，也更容易在出错时及时纠正。但代价是速度会慢一些，因为每一步都要跟模型交互一次，token消耗也会相应增加。

生成代码和执行操作是耦合在一起的。caveman可以直接修改文件系统、执行shell命令，这是它作为“代理”的核心能力。但这也带来了安全风险——如果模型判断失误，可能会删掉不该删的文件，或者执行危险的命令。所以我在使用这类工具时，一定会先在一个干净的git分支上操作，这样即使出了问题，也能一键回滚。

验证结果这块，caveman的做法比较基础，主要是看命令的退出码和输出。它不会自动跑测试用例，也不会做复杂的静态分析。这意味着用户需要自己承担验证的责任。我的习惯是，让caveman改完代码后，自己再跑一遍测试，确认没问题再提交。

2.3 与同类工具的差异化定位

市面上类似的AI编码代理工具不少，caveman的差异化主要体现在三个地方。

第一是零配置启动。很多工具需要你写配置文件、设置环境变量、指定模型端点，caveman把这些都简化了。当然，简化不等于没有，只是它把默认值设得比较合理，让用户可以先跑起来再慢慢调。

第二是终端原生体验。它的输出格式、交互方式都是为终端设计的，不会出现那种在命令行里渲染富文本的尴尬。颜色、进度提示、错误信息都处理得比较克制，不会刷屏。

第三是对npx生态的充分利用。这意味着它可以很方便地跟其他npm工具组合使用，比如你可以用npx concurrently同时跑caveman和你的开发服务器，或者用npx tsx直接执行它生成的TypeScript代码。

不过也要客观说，caveman在功能丰富度上肯定比不上那些商业化的AI编码助手。它没有代码库索引、没有多文件重构的高级功能、没有团队协作支持。但对于个人开发者和小型项目来说，这些缺失未必是问题，反而让工具更轻、更快、更可控。

3. 核心细节解析与实操要点

3.1 token管理：从获取到续签的完整链路

AI编码代理离不开token，这是绕不过去的。caveman涉及的token主要有两类：一类是访问AI服务的认证token，另一类是会话过程中产生的上下文token。这两类token的管理策略完全不同。

认证token这块，caveman通常需要你提供一个API key或者access token。获取方式取决于你用的AI服务提供商。一般来说，你需要在服务商的控制台里创建一个API key，然后把它配置到环境变量里。caveman会读取这个环境变量，在每次请求时带上。这里有个细节：不要把token硬编码在代码里或者提交到git仓库，这是基本的安全常识。我习惯用.env文件管理，并且把.env加到.gitignore里。

token的续签是个容易出问题的地方。很多AI服务的access token是有有效期的，过期后需要用refresh token换新的。caveman如果处理不好这个逻辑，就会出现“token exchange failed”这类错误。我在实际使用中遇到过几种典型情况：一种是refresh token本身过期了，这时候只能重新登录获取；另一种是网络问题导致续签请求失败，这种通常重试几次就好；还有一种是服务端返回403，提示地区限制或者权限不足，这种就比较麻烦，需要检查账号状态和网络环境。

注意：如果你看到“token endpoint returned status 403 forbidden”这类错误，先别急着改代码，大概率是认证环节的问题。检查一下token是否过期、账号是否有权限、网络是否能正常访问认证服务。

上下文token的管理是另一个维度。AI模型有上下文窗口限制，对话太长或者代码文件太大，都会导致token超限。caveman在这方面的处理比较基础，它不会自动做上下文压缩或者摘要。我的做法是，把大任务拆成小任务，每次只让caveman处理一个文件或者一个函数，避免一次性喂太多内容。另外，定期清理对话历史也有帮助，不过caveman目前好像没有内置这个功能，可能需要手动重启会话。

还有一个实用技巧：监控token用量。很多AI服务提供商会给你一个用量面板，你可以看到每天消耗了多少token。如果你用的是按量计费的服务，这个监控很重要，不然月底账单可能会吓你一跳。我一般会设置一个预算提醒，超过阈值就暂停使用，等第二天额度重置再继续。

3.2 proxy配置：让请求顺利到达目的地

proxy这个词在AI编码代理的语境下，通常指的是网络代理，用来解决网络访问的问题。caveman作为一个需要访问外部AI服务的工具，proxy配置是否正确直接决定了它能不能用。

proxy的配置方式一般有两种：一种是通过环境变量，比如HTTP_PROXY和HTTPS_PROXY；另一种是在工具自己的配置文件里指定。caveman应该支持环境变量这种方式，因为这是最通用的做法。你可以在启动caveman之前，先export这些变量，或者在.env文件里写好。

这里有个坑：不同工具对proxy环境变量的读取方式可能不一样。有的只读大写，有的只读小写，有的两个都读。如果你设置了proxy但caveman还是连不上，可以先检查一下环境变量名对不对。另外，有些proxy需要认证，这时候URL里要带上用户名和密码，格式是http://user:pass@host:port。

还有一种情况是proxy类型不支持。比如你用的是某种特殊类型的代理，而caveman底层用的HTTP客户端不支持这种类型，就会报“unsupport proxy type”之类的错误。这种问题通常需要换一种代理类型，或者改用支持该类型的HTTP客户端库。不过这块涉及到具体实现，普通用户能做的有限，更多是给开发者提issue。

提示：如果你在公司网络环境下使用caveman，proxy配置可能需要IT部门提供。别自己瞎猜，直接问网络管理员要正确的proxy地址和端口，能省很多时间。

除了网络代理，还有一种“代理”是API代理，也就是在caveman和AI服务之间加一层中间层，用来做请求转发、缓存、限流等。这种代理通常需要你自己搭建，或者使用第三方服务。好处是可以统一管理多个AI服务的API key，坏处是增加了一个故障点。我的建议是，个人使用的话，直接连AI服务就行，没必要加中间层；团队使用的话，可以考虑搭一个，方便管理和审计。

3.3 npx使用：零安装运行的利与弊

npx是caveman的主要分发方式，理解npx的工作机制对用好这个工具很重要。

npx的基本逻辑是：你运行npx caveman，它会先检查本地有没有安装caveman，如果没有，就去npm仓库下载最新版本，然后执行。执行完之后，下载的包可能会被缓存起来，下次再运行就不用重新下载了。这个机制的好处是用户永远拿到的是最新版本，不用手动升级；坏处是每次运行都可能有网络请求，如果网络不好或者npm仓库访问慢，启动就会很慢。

我实测下来，第一次运行npx caveman大概需要几秒到十几秒，取决于网络速度。之后因为有了缓存，启动就快很多。如果你经常用，可以考虑全局安装npm install -g caveman，这样启动最快，但需要手动升级。

npx还有一个特性是可以指定版本。比如npx caveman@1.2.3会运行1.2.3版本，而不是最新版。这个在排查问题时很有用——如果你怀疑最新版有bug，可以回退到旧版本试试。

不过npx也不是没有坑。一个常见问题是权限问题。在某些系统上，npx下载的包可能没有执行权限，导致运行失败。这种通常需要检查npm的配置，或者用sudo运行（不推荐）。另一个问题是缓存损坏，表现为运行时报一些莫名其妙的模块找不到错误。这时候可以试试npx clear-npx-cache清理缓存，然后重新运行。

注意：如果你在CI/CD环境里用npx运行caveman，记得把npm缓存目录也缓存起来，不然每次构建都要重新下载，会很慢。

还有一个细节：npx运行的时候，当前工作目录很重要。caveman会以当前目录为基准来读写文件，所以你要确保在正确的目录下启动它。我一般会先cd到项目根目录，再运行npx caveman，这样它就能看到整个项目的结构。

4. 实操过程与核心环节实现

4.1 环境准备：从零到能跑起来

在开始用caveman之前，你需要确保环境里有Node.js和npm。Node.js的版本建议用LTS版本，比如18.x或者20.x，太老的版本可能不支持一些新特性。你可以用node -v和npm -v检查版本。

如果你还没有Node.js，去官网下载安装包，或者用版本管理工具比如nvm、fnm来安装。我个人推荐用nvm，因为它可以方便地切换不同项目的Node.js版本。安装好之后，确认npx命令可用，npx -v应该能输出版本号。

接下来是获取AI服务的API key。以常见的AI服务为例，你需要登录服务商的控制台，找到API key管理页面，创建一个新的key。创建的时候注意权限范围，如果只是用来写代码，不需要给太高的权限。创建完之后，把key复制下来，存到一个安全的地方。

然后配置环境变量。我习惯在项目根目录创建一个.env文件，内容大概是：

AI_API_KEY=your_api_key_here AI_BASE_URL=https://api.example.com/v1

然后在.gitignore里加上.env，防止不小心提交。caveman启动的时候会读取这些环境变量。如果你不确定caveman支持哪些环境变量，可以先运行npx caveman --help看看帮助信息。

4.2 第一次运行：从简单任务开始

环境准备好之后，就可以跑第一个任务了。我建议从最简单的开始，比如让caveman创建一个hello world文件。

在终端里输入：

npx caveman "在当前目录创建一个hello.js文件，内容是用console.log输出Hello World"

caveman会解析这个任务，然后调用AI模型生成代码，最后把代码写入文件。整个过程你可以在终端里看到它的思考过程和执行步骤。第一次运行可能会慢一些，因为要下载依赖和建立连接。

如果一切顺利，你会看到当前目录下多了一个hello.js文件。你可以用node hello.js运行一下，确认输出正确。这个简单的任务能帮你验证整个链路是否通畅：npx能下载包、环境变量能读到、AI服务能访问、文件能写入。

如果这一步就失败了，别急着往下走，先排查问题。常见的失败原因有：API key不对、网络连不上AI服务、proxy配置有问题、Node.js版本太老。根据错误信息逐个排查，一般都能解决。

4.3 处理真实任务：一个完整的代码修改案例

简单任务跑通之后，可以试试更真实的场景。比如你有一个现有的项目，想让caveman帮你加一个功能。

假设你有一个Express项目，想加一个健康检查接口。你可以这样描述任务：

npx caveman "在src/routes目录下创建一个health.js文件，导出一个Express Router，包含一个GET /health接口，返回JSON {status: 'ok', timestamp: new Date().toISOString()}。然后在src/app.js里引入这个router并挂载到/health路径"

这个任务涉及创建新文件和修改现有文件，比之前的hello world复杂一些。caveman会先读取src/app.js的内容，理解现有的代码结构，然后生成新的代码并写入。执行过程中，它可能会问你一些问题，比如“是否覆盖现有文件”，你需要根据情况回答。

执行完之后，你需要验证结果。先看看health.js的内容对不对，再看看app.js的修改是否合理。然后启动服务，用curl测试一下：

curl http://localhost:3000/health

如果返回了预期的JSON，说明任务成功。如果没有，检查一下路由挂载的路径对不对，或者让caveman再修一下。

这个过程中有个经验：任务描述越具体，结果越可控。如果你只说“加个健康检查”，caveman可能会用不同的实现方式，比如用中间件而不是router，或者返回不同的字段。把文件路径、函数名、返回格式都写清楚，能减少来回修改的次数。

4.4 参数计算与选择：token预算怎么估

用AI编码代理，token消耗是绕不开的成本。虽然caveman本身不直接收费，但它调用的AI服务是按token计费的。所以你需要对token用量有个大概的估算。

一个粗略的估算方法是：1个token大约对应0.75个英文单词，或者0.5个中文字符。但这只是平均值，实际取决于模型的分词器。对于代码来说，token和字符的比例又不一样，因为代码里的符号、缩进、换行都会影响分词。

更实用的方法是看AI服务商提供的用量统计。大多数服务商会在控制台里显示每次请求消耗的token数，你可以根据这些数据来估算。比如你发现一个简单的文件创建任务消耗了500个token，那么一个涉及10个文件的复杂任务可能就要5000个token左右。

如果你用的是按量计费的服务，可以设置一个预算上限。比如每月预算10美元，根据服务商的定价换算成token额度，然后监控用量。快超了的时候就减少使用，或者换更便宜的模型。

提示：不同模型的token价格差异很大。一般来说，能力越强的模型越贵。对于简单的代码生成任务，用便宜的小模型就够了；只有遇到复杂逻辑或者需要深度理解代码库的任务，才需要用大模型。

还有一个省token的技巧：复用对话上下文。如果你连续让caveman做几个相关的任务，它可以把之前的对话历史作为上下文，这样就不用每次都重新描述背景。但上下文太长也会消耗token，所以要在“复用”和“精简”之间找平衡。我的做法是，把一个大任务拆成几个小任务，每个小任务单独开一个会话，避免上下文过长。

5. 常见问题与排查技巧实录

5.1 认证类问题：token失效与登录失败

认证问题是AI编码代理最常见的故障类型。我整理了一个速查表，覆盖了大部分场景。

处理这类问题的通用思路是：先确认token本身有效，再确认网络能到达认证服务，最后确认proxy配置正确。这三步能解决大部分认证问题。

还有一个容易被忽略的点：系统时间不准确。有些认证机制依赖时间戳，如果本机时间偏差太大，会导致token验证失败。如果你排除了其他原因还是不行，可以检查一下系统时间是否同步。

5.2 网络类问题：proxy与连接超时

网络问题在AI编码代理的使用中也很常见，尤其是在企业网络或者网络环境比较特殊的情况下。

“unsupport proxy type”这个错误通常意味着你配置的proxy类型不被底层HTTP客户端支持。比如有些客户端只支持HTTP/HTTPS proxy，不支持SOCKS proxy。解决办法是换一种proxy类型，或者用工具把SOCKS转成HTTP。

“connection timeout”或者“ECONNREFUSED”通常表示连不上目标服务。先检查proxy地址和端口对不对，再检查proxy服务本身是否在运行。如果proxy需要认证，确认用户名密码是否正确。

“unexpected status 404 not found”有时候不是网络问题，而是API路径写错了。检查一下AI_BASE_URL是否包含了正确的路径前缀，比如有些服务需要/v1，有些不需要。

我的经验是，把proxy配置单独拿出来测试。比如用curl命令走同样的proxy去访问AI服务的健康检查接口，如果能通，说明proxy没问题，问题在caveman的配置上；如果不通，说明proxy本身有问题，需要先解决proxy。

5.3 使用类问题：npx执行失败与文件权限

npx相关的问题主要集中在下载和执行两个环节。

“npx playwright install失败”这类错误，通常是因为npx在下载包的时候网络中断，或者磁盘空间不足。解决办法是清理npx缓存（npx clear-npx-cache），然后重试。如果还是不行，检查一下npm的registry配置，确保指向可用的仓库。

“permission denied”表示没有执行权限。在Linux和macOS上，可以用chmod +x给文件加执行权限。但如果是npx下载的包没有权限，可能需要检查npm的全局配置，或者用sudo运行（不推荐，有安全风险）。

“command not found”表示npx没有找到对应的包。检查一下包名拼写对不对，或者用npm view caveman确认包是否存在。

还有一个问题是Node.js版本不兼容。有些包要求Node.js 18以上，如果你用的是16，可能会报语法错误或者API不存在的错误。用node -v确认版本，必要时升级。

5.4 独家避坑技巧：我踩过的那些坑

第一个坑：在错误的目录下运行。有一次我在home目录下运行caveman，让它创建一个项目文件，结果它把文件创建在了home目录下，而不是我预期的项目目录。后来我养成了习惯，运行前先pwd确认当前目录。

第二个坑：任务描述太模糊。我说“优化一下这个函数”，caveman把函数重写了一遍，但逻辑完全变了。后来我改成“把这个函数里的for循环改成map，保持逻辑不变”，结果就符合预期了。具体、可验证的任务描述是关键。

第三个坑：忘了设置超时。有些任务caveman会跑很久，如果终端会话超时断开，任务就中断了。后来我用nohup或者tmux来跑长任务，避免中断。

第四个坑：token用量失控。有一次我让caveman处理一个很大的代码库，它把整个代码库的内容都读进了上下文，结果一次请求就消耗了大量token。后来我学会了限定范围，比如“只处理src/utils目录下的文件”，避免它读太多无关内容。

第五个坑：没有版本控制。早期我直接让caveman在主分支上改代码，有一次它改错了，我花了好久才恢复。现在我一定会在新分支上操作，改完确认没问题再合并。

6. 进阶用法与扩展思路

6.1 把caveman嵌入到开发工作流

caveman作为一个命令行工具，最大的优势是可以跟其他工具组合使用。我分享几个我常用的组合方式。

第一种是跟git hooks结合。比如你可以写一个pre-commit hook，在提交前让caveman检查代码风格，自动修复一些简单问题。这样能减少代码审查时的低级问题。

第二种是跟测试框架结合。让caveman生成测试用例，然后跑测试看是否通过。如果不通过，把失败信息反馈给caveman，让它修复。这个循环可以自动化，形成一个“生成-测试-修复”的闭环。

第三种是跟CI/CD结合。在CI流水线里加一步，用caveman自动生成变更日志或者更新文档。这样每次发布都能有完整的记录，不用手动写。

不过要注意，自动化程度越高，出错的影响也越大。在把这些组合用到生产环境之前，一定要在测试环境充分验证。

6.2 多模型切换与成本优化

不同的AI模型在能力、速度、价格上差异很大。caveman如果支持多模型切换，你可以根据任务类型选择最合适的模型。

简单任务比如格式化代码、重命名变量，用便宜的小模型就够了。复杂任务比如重构架构、修复疑难bug，才需要用大模型。这样能在保证效果的前提下，尽量降低成本。

切换模型的方式通常是通过环境变量或者命令行参数。比如AI_MODEL=gpt-4或者--model claude-3-opus。具体支持哪些模型，要看caveman的文档和你的AI服务商。

还有一个优化思路是缓存重复请求。如果你经常让caveman做类似的任务，可以考虑在中间加一层缓存，把相同请求的结果存下来，下次直接返回。不过这需要自己实现，caveman本身可能没有这个功能。

6.3 安全边界：什么该让AI做，什么不该

AI编码代理虽然方便，但不是所有事情都适合交给它。我总结了几条边界。

可以放心交给AI的：生成样板代码、写单元测试、格式化代码、重命名变量、添加注释、生成文档。

需要人工审核的：修改核心业务逻辑、处理用户输入、涉及数据库操作、涉及网络请求、涉及文件系统操作。

绝对不能让AI碰的：生产环境的配置文件、包含密钥的文件、数据库迁移脚本、部署脚本。

这个边界不是绝对的，取决于你的项目性质和风险承受能力。但原则是：AI生成的代码，你要能看懂、能验证、能负责。如果你看不懂它生成的代码，那就不要用。

注意：caveman在执行shell命令的时候，一定要小心。有些命令是不可逆的，比如rm -rf。我建议在让caveman执行命令之前，先让它把命令打印出来，你确认没问题再执行。

6.4 后续扩展方向

caveman作为一个开源项目，后续可以扩展的方向很多。我个人比较期待的几个方向：

一是更好的上下文管理。现在的上下文窗口有限，处理大项目时经常不够用。如果能自动做代码库索引和相关性检索，只把相关的代码片段喂给模型，就能大大提升处理大项目的能力。

二是多轮对话的持久化。现在每次重启caveman，之前的对话历史就丢了。如果能持久化对话历史，就能跨会话继续任务，不用每次重新描述背景。

三是更丰富的工具集成。除了文件读写和shell命令，如果能集成更多工具，比如数据库客户端、API测试工具、性能分析工具，caveman能做的事情就更多了。

四是团队协作支持。现在caveman更像是个人工具，如果能支持多人共享会话、共享配置、共享任务历史，就能更好地用在团队场景里。

这些扩展方向有些可能需要改底层架构，有些可能只需要加一些插件机制。如果你对caveman感兴趣，可以关注它的更新，或者自己动手改。

6.5 一个实际项目的完整复盘

最后分享一个我用caveman完成的实际项目，是一个小型的Node.js CLI工具，用来批量处理图片。项目不大，大概十几个文件，但涉及文件读写、图片处理、命令行参数解析这些模块。

我的做法是：先自己搭好项目骨架，包括package.json、目录结构、入口文件。然后用caveman逐个实现功能模块。每个模块的任务描述都写得很具体，比如“在src/commands/resize.js里实现一个resize命令，接受--width和--height参数，用sharp库调整图片尺寸，输出到output目录”。

caveman在实现过程中出过几次错，主要是对sharp库的API不熟悉，生成的代码调用了不存在的方法。我把错误信息反馈给它，它就能修正。整个项目大概花了两个小时完成，如果纯手写，估计要四五个小时。

复盘下来，caveman最适合的是“有明确输入输出”的模块级任务。对于需要全局架构设计的任务，它还是力不从心。所以我的建议是：人负责架构和设计，AI负责实现和填充。这样既能发挥AI的效率优势，又能保证项目的整体质量。

这个项目后续我还想加一些功能，比如支持更多图片格式、加进度条、加并发处理。这些都可以继续用caveman来做，每次加一个功能，测试通过再提交。这种小步快跑的方式，比一次性让AI生成一大堆代码要靠谱得多。