Claude Code Projects 上手实测——让它从头做出一整个网站，看清并行线程的优势与陷阱

Claude Code 的 “Projects”（项目）功能，会在一整条对话里由 Claude 把工作拆成一个个线程，在云端并行推进。它的原理和使用条件，我在Claude Code Projects 是什么一文中已经梳理过。本文是续篇，记录的是真正让它从头做出一整个网站的过程。

试用时间是2026年9月26日至28日，当时 Projects 还处于公开测试版（public beta）阶段（正在向 Pro 和 Max 用户逐步开放，见官方文档）。界面和行为今后都可能变化。这里写的是当时实际发生的事，以及从界面、用量报告和仓库记录中核实过的数字。

一句话总结：开发放着不管也能推进得出奇地远。但交出来的不是成品而是初稿，而且一遇到只能通过 SSH 登录的服务器，部署就走不下去了。下面按发生的顺序，把好的和不好的都写出来。

1. 让它做了什么——条件，以及一开始就要坦白的事

题材是一个可以查询本地 LLM“需要多少内存”的数据库网站。为了回答“这个模型能不能在我的电脑上跑”，它要从 Hugging Face 收集量化文件的大小，按上下文长度计算所需内存，还要能从 GPU 或 Mac 的内存容量反查可用的模型。规模不大不小，又有能拆开并行的部件（数据收集、计算、页面、反查、SEO），很适合拿来测试 Projects。

2. 上手步骤，以及踩到的5个坑

上手步骤本身很短：在桌面应用的 Code 标签页里选“Projects”→“新建”，填好名称、目标和仓库，点创建即可。不过在这前后，我在下面5个地方被绊了一下。

关于②再补充一句：创建后的对话里出现了这样一条提示：“Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits”。意思是最初使用中的前 $100 不计入常规用量额度，用量界面上也显示为“项目设置额度（Project setup credit，约24小时后到期）”。截至9月28日，官方文档的 Projects 页面并没有写这项优惠。第6章会列出它实际的消耗过程。

环境设置界面里让我犯迷糊的，是修改已有环境的时候。从 “Add cloud environment”（添加环境）进去会打开一个新环境的界面，一开始我把允许的域名填进了设置脚本那一栏。已有的环境，要在列表里把鼠标移到该环境上，点出现的齿轮图标来编辑（和官方文档的步骤一致，但光看界面不容易发现）。

3. 约20小时实录——我睡觉时发生了什么

下面是从创建（9月26日22点左右）到最后一个 PR 被合并（次日27日17点半左右）的经过。时间均为日本时间（JST）。

还有一点做得不好，也要写下来。在搭数据收集的基础时，线程为了弄清外部服务的限流机制，连续访问了 Hugging Face 的 API 520次。评审线程判定这“不妥当”，并把外部 API 的使用规则写成了文档；之后的数据收集线程在整个工作过程中只访问了8次。放着不管的话，它不会主动顾及给外部带来的负载，所以值得在指令里写明。

4. 事事审批与放手交给它，差别在哪

如第1章所说，前半段我用处处插入人工审批的指令来运行，27日17点改成了“交给你”的指令。行为明显变了。

放手时有两点值得注意。其一，改写后的指令传不到当时正在运行的线程。协调者自己就解释过：“这个线程是在改写指令之前开始的，所以看不到新的指令。”其二，项目记忆里残留的旧规则，线程删不掉。它试图改写“只有人能合并”这条旧备忘，却被安全检查拦了下来。旧的备忘需要人到设置的 “Memory”（记忆）里手动删除。

最后稳定下来的指令骨架如下。

这个项目要做出并运营〇〇。
推进方式交给你：开哪些线程、开几个、用什么模型、按什么顺序，都可以由协调者决定。
CI 通过的 PR 可以直接合并。冲突由你自己解决。

只有以下情况需要问人：
- 需要花钱时（付费 API、付费服务）
- 需要机密信息（API 密钥、密码）时
- 部署到生产环境、修改生产数据时
- 方针出现分歧、两种做法都说得通时
- 访问不到所需资源时（不要用猜测或虚拟数据填充）

调用外部 API 要遵守限流，不要为了调查而大量访问。

不过，结合后来发现的情况，我建议再加上一条：“CI 配置和部署脚本的修改需要人来批准”。放手之后的线程也能改 CI 配置，再和部署机制组合起来，就形成了一条不经确认就能改动生产环境的路径（见第7章）。

5. 上线后才看清的质量——测试全都通过了

我把用 Projects 做出来的东西交接给平时用的本地 Claude Code，发布到了生产环境。刚上线时的感想是“好像挺普通”。因为一个模型页面都没有。追查原因后，看到了并行开发特有的漏洞。

10个线程、一百几十个测试、Opus 的评审、CI，没有一个发现这个缺口。因为每个线程在自己负责的范围里都是对的。如果没有一个角色从头到尾贯通地检查，分工的交界处就会出现漏洞。

导入真实数据后，又冒出了两个问题。

• 量化表里混进了不属于模型本体的文件。它把用于预测解码的辅助模型（MTP、EAGLE 等）和 LoRA 文件也当成了本体的量化版本，结果某个 12B 模型的表格第一行显示为“Q8_0 0.47GB”（真正的 Q8_0 是 12.7GB）。修正后，56个仓库中的195个文件被改为辅助文件。
• 最新、需求最大的那些模型，所需内存显示“无法计算”。当时的计算公式不支持新一代架构（比如不同层以不同方式保存记忆的结构）。网站最大的卖点，偏偏在访问量最大的页面上出不来。

这两个问题都是因为测试只基于“样例数据”搭建，直到往生产环境导入数据才暴露出来。用本地 Claude Code 修复的内容和所花时间如下（9月28日17点21分〜22点54分，13次提交）。

另一方面，做得好的地方也很明确。页面显示很快（主要页面在0.1秒左右），文件大小是 Hugging Face 上的实际值，受支持模型的所需内存与计算公式吻合。标题、结构化数据、sitemap、llms.txt 这些 SEO 细节，一开始就做进去了。骨架和细节都做得不错，缺的是“接缝”和“真实数据”——这是我的总评。

6. 用量与费用——1.9亿 token 的构成

项目设置里的“用量”界面，会按线程和模型列出 token 数。点右上角的按钮，还可以直接复制成文本。9月27日11点47分的报告如下。

1.9亿这个数字看着很大，但其中97.7%是缓存读取。线程每执行一次操作，都会把之前的对话重读一遍，一个线程操作几百次，就会是这个样子。协调者额外占的只有2%，管理成本很小。

作为对比，我用“读取的 token ÷ 输出的 token”和本地 Claude Code（我电脑上最近3天的数据）比了一下：Projects 约为330，本地约为340。按工作量算，消耗和本地会话几乎一样。Projects 之所以让人觉得“重”，大概是因为它并行地一口气推进，额度在短时间内集中消耗（工作内容不同，这只是个粗略的比较）。

费用方面，我追踪到了设置额度（$100）的消耗过程。

这笔额度的变化，和按 API 单价计算的金额很接近。用 Anthropic 的官方单价（Pricing：Sonnet 5 输入 $2、输出 $10、缓存读取 $0.20，Opus 5.5 输入 $4、输出 $20、缓存读取 $0.20，均为每百万 token）计算11点47分那份报告，约为 $58〜65，和当时的显示（78%＝$78）大致相符。也就是说，“$100 额度”的意思是按 API 付费要花 $100 的量，放在 Max 包月订阅里并不算多。另外，另行发放的云端会话额度（Max 为 $250），领取页面上写着“Projects 不适用”，实际上也一分钱都没减少。

7. 部署到生产环境为何卡住

最费劲的，是把做好的东西发布到生产环境。因为部署目标是只能通过 SSH 登录的共享主机。

• 云端的线程连不到生产服务器（SSH 密钥只在我本地的电脑上）。
• 要在本地电脑上运行，得用项目的 “Work locally”（在本地工作）。它的底层是 Remote Control，需要打开桌面应用里的 “Use this computer from your phone and claude.ai”（允许从手机和 claude.ai 使用这台电脑）。
• 然而，这个设置的作用对象是之前用 Claude Code 打开过的文件夹列表，而且是自动收集的。在我的环境里有22个，其中1个是内含几十个项目的父文件夹。开着这个设置期间，它们都会成为可以被远程发起工作的对象，文件夹名、路径和仓库 URL 也会发送给 Anthropic。如果只想开放一个文件夹，就得换一种方法：在终端里进入那个文件夹，启动 claude remote-control。

于是我比较了几种部署方式。

最终，我把项目归档了，做好的东西转入了平时本地 Claude Code 的运维流程。我判断，和其他网站共用同一套部署机制，比再新增一套机制更安全。

回头看，Projects 最好以和“合并到 GitHub 就自动发布”的托管服务搭配使用为前提来考虑。比如 Vercel，只要和 GitHub 关联就能一路发布上线，不会出现这次这样的僵局。不过，Vercel 免费的 Hobby 计划仅限非商业用途，如果要放 Google AdSense 之类的广告，就需要付费的 Pro（每月 $20 起）（Fair Use Guidelines）。而且它和这次这种 PHP 加 MySQL 的网站也不太合拍。技术栈和部署目标，最好一开始就一起定下来。

让别人远程操作自己电脑时的风险，以及它和平时的 Claude Code 有何不同，我打算另写一篇文章详细整理。用手机操作本地会话的用法，可以参考介绍 Remote Control 的文章。

8. 适合的工作与不适合的工作

根据这次的经验，把开始前应该确认的事项整理如下。

• 部署目标：合并到 GitHub 后能否自动发布。如果需要 SSH，就先定好由服务器来拉取之类的方式。
• GitHub 权限：Claude GitHub App 的安装范围。要么用专用账号，要么收窄仓库范围。
• 交给它的范围：在项目指令里只写需要问人的事。CI 和部署配置的修改设为需要审批。
• 网络：如果要用外部 API 或网站，白名单里要同时加入主域名和子域名。
• 用真实数据核查：样例数据的测试通过了也别放心。最后专门开一个线程，负责把和生产环境相同的数据从头到尾跑一遍。
• 用量额度：重新选择线程的默认模型。最初的24小时内有 $100 的设置额度。

总结

Projects 是一个真正替人接手了“分派、跟进、反复交代同样前提”这些麻烦事的功能。一夜之间3个工作并行推进，线程之间互相协调，放手之后连合并和下一步工作都能自己判断。按工作量算的 token 消耗，也和本地的 Claude Code 没有差别。

另一方面，它交出来的是初稿。一旦并行拆分，分工的交界处就会出现漏洞。样例数据的测试全部通过，导入真实数据后照样出缺陷。而且，它和只能通过 SSH 登录的服务器部署不太合得来。如果要用，记住三点：部署目标选能与 GitHub 联动的；一开始就写清交给它的范围；最后专门开一个“用真实数据从头到尾核查”的线程。这样应该能避开这次走过的弯路。

FAQ

Q. Projects 要花多少钱？

A. 没有单独收费，从 Pro 或 Max 的常规用量额度里扣除。这次在此之外，还附带了“设置额度”：最初约24小时内，$100 以内的用量不计入额度（依据界面显示；截至9月28日，官方文档没有相关说明）。10个线程、11个 PR 的工作用掉了约1.9亿 token，把这笔额度用完了。换算成 API 单价，大约相当于 $100 的量。

Q. 真的合上电脑也能继续推进吗？

A. 是的。在云端运行的线程，合上电脑或让电脑休眠都照样推进。这次也是在夜间约7小时里完成了3项工作。不过，通过 “Work locally” 在本地电脑上开的线程，只在电脑保持唤醒时才会运行。

Q. GitHub 以外的仓库也能用吗？

A. 处理代码的线程，前提是安装了 Claude GitHub App 的 github.com 仓库。这次我原本用自建的 git 服务器管理代码，所以专门为 Claude 建了一个 GitHub 账号，在那边开始，最后再迁回本地。

Q. 中途修改项目指令会怎样？

A. 协调者会立刻采用，不用跟它说话，推进方式就变了。但当时正在运行的线程收不到新指令，需要的话就让它在新线程里继续。项目记忆里残留的旧规则，需要人从设置里删除。

Q. “Work locally” 安全吗？

A. 通信只有从电脑向外发起的加密连接，不会开放接收连接的端口。但打开桌面应用里的这个设置后，根据使用记录收集到的文件夹列表（这次是22个，还包括父文件夹里的几十个项目）都会成为可以被远程发起工作的对象。需要做好只在使用时打开、确认登录账号已开启两步验证之类的运维措施。

Q. 做出来的东西能直接用吗？

A. 这次是不能直接用的。骨架和 SEO 细节做得很好，但分工交界处的处理整个缺失，在真实数据下也出现了缺陷。发布之前，需要一道导入真实数据、从头到尾整体核查的工序。