Claude Code Projects 示例：15 个值得建的项目

15 个可直接照抄的 Claude Code Projects 示例，覆盖工程、内容、非技术文档与业务运营四类；每个都配一段能粘进项目指令的起始模板，并说清哪些活不该建项目。

2026年9月22日

搜「claude code projects 示例」，结果分两类：一类是压根不提 Projects 的副业点子清单，靠关键词蹭流量；另一类是 Anthropic 官方文档，写得准、写得严谨，但只讲机制，不讲你该拿它干什么。两边都没回答你真正的问题——侧边栏里那个 Projects 我能看见了，手上也有活，但这份活配不配叫一个项目？进去之后项目指令该写什么？

还有一层让多数搜索结果读起来别扭：Anthropic 现在同时有两个都叫 Projects 的东西，适合其中一个的例子，套到另一个上就是错的。本文先用九十秒把两者分清，再给 15 个值得真去建的项目，覆盖工程、内容、非技术文档与业务运营四类，每个都配一段可直接粘贴、再删掉不合用部分的起始指令。

先给结论

问题	短回答
Claude Code 项目一句话是什么？	一个持续对话，由 Claude 在里面开线程、协调并行云端会话
什么活配做项目？	目标比一次会话长、而且不断冒出新任务的活
一定要有代码仓库吗？	不用——官方文档原话「A project doesn't need a repository at all」
在哪建？	claude.ai/code、桌面端的 Code 标签页、Claude 手机 App
第一个该建什么？	你每周都要回去的那块：一个服务的缺陷队列、一次迁移、一文件夹文档
项目指令能写多少？	最多 16,000 字符，会发给每一个新线程

第一步：你说的是哪个 Projects？

这一步别省，因为两个东西确实不是一回事。

重新设计的 Claude Code Projects（beta）。 2026 年 9 月 17 日 Anthropic 在《Projects redesigned: from folder to conversation》里发布。项目就是一个对话，你把活丢进去，Claude「拆解请求、分派工作、协调并行线程、复查产出、把结果拼起来」。每个线程都是一个跑在自己分支上的 Claude Code 云端会话。
claude.ai 聊天与 Cowork 里那套老 Projects。 还在跑，也是大多数第三方教程实际在讲的那个：「自带聊天历史和知识库的独立工作区」，你往知识库里丢参考文件、写项目指令。所有档位都有，免费账号最多建 5 个。

官方文档把两者划得很清：新版是Pro 与 Max 档位的 public beta，面向用过 Claude Code 云端会话的账号，「rolling out gradually」，Team 与 Enterprise 暂未开放，没灰度到可以进 waiting list。老的聊天与 Cowork 项目照常用，等灰度到了再升级。下面所有例子默认指新版 Claude Code Projects，因为这才是搜索意图指向的那个。

什么样的活真配建一个项目

官方给的判据只有一句：当「工作的目标比一次会话更长、而且不断产生任务」时，这个值。四种形态天然符合：一个目标横跨多个仓库；一块你会不停投喂的区域，比如某个服务的缺陷和 review 请求；一次比单次会话更大的构建或迁移；以及完全不是代码的活——官方自己的例子是「一个合同文件夹，或者一份工单导出，你会带着新问题反复回来」。

四种情况反而别建：一次会话就能干完的单件活（直接开云端会话）；需要只有你本机才够得着的东西（本地数据库、内网 VPN 后面的 API）；按周期重复、不需要任何对话的单一任务（单独建一条 routine）；多个人在 Slack 里一起给 Claude 派活（那是 Claude Tag）。

15 个 Claude Code 项目示例

每段起始指令粘到 Project settings → Memory → Project instructions，不合用的行直接删。官方把项目指令定义为「每个新线程开工时的任务简报」，它不是配置文件，是简报。

工程类

1. 单个服务的值守台。 一个服务的缺陷、堆栈、review 请求，来什么丢什么。把该服务的仓库加进项目；你纠正过一次的那个坑会进项目记忆，后面每个线程开局就带着。

服务：payments-api。目标：p95 延迟压在 200 ms 以内，缺陷队列持续消化。
从 main 分支拉分支；每个线程一个 draft PR，命名 thread/<slug>。
宣布收工前先跑 `make test` 和 `make lint`，把两段汇总贴出来。
如果缺日志、缺面板、缺我没给你的服务，说明缺什么然后停下。

2. 跨仓库统一规范。 「把所有服务切到新的 lint 配置」是官方原文例子。把受影响的仓库全加进来，然后在 Overview 面板看哪些线程已经到待 review。

目标：所有仓库按 @docs/lint-standard.md 切到共享 lint 配置。一个仓库一个线程。
不要给某个仓库自创变体——要么照配置改，要么开一个 draft PR 说清它为什么做不到。

3. 大迁移。 「把应用从废弃的 ORM 上搬下来」同样是官方例子。相比临时开会的优势是：你第一天拍板的决定，第八天的线程照样带着。

迁移：旧 ORM 下线，按 @docs/migration-plan.md 换仓储层。一个模块一个线程，先小后大。
收工时测试必须是绿的——跑 `make test` 并贴结果。某个模式该一次定死的，在线程里问我。

4. 消灭不稳定测试。 一个线程治一个 flaky test：先复现，再修或隔离，并写下理由，开 PR。

目标：flaky test 清零。一个测试一个线程，先复现并贴失败输出。
产品 bug：开 PR 修它。测试自身 bug：修测试。绝不把调大超时、加重试当成修复。
三次复现不出来：说明情况、隔离、停手。

5. PR 与 CI 响应台。 线程会盯自己开的 PR——空闲线程在 CI 挂掉或有人评论时被叫醒，推修复，检查通过后回报。review 比写码多的人，这条收益最高。

线程开的每个 PR 都要盯：CI 挂了推修复，review 评论在线程里回。
不许 merge、不许 force-push、不许动 CI 配置，除非我在那个线程里点头。
reviewer 的要求和这份指令冲突时，把冲突摊开，别自己选一边。

6. 依赖与安全公告巡检。 定时版：一条 routine 每周对着清单跑，每个可动的升级变成一个线程、一个 PR。routine 截至 2026 年 9 月还在 research preview。

每周：对照安全公告和 changelog 检查依赖。一个升级一个线程一个 PR，别把无关升级打包。
大版本升级只开 draft PR，描述第一行写清可能踩坏什么。

内容与产品类

7. 发布工作区。 文案、定位、FAQ、changelog、公告稿放一处，全部基于同一套事实。项目不需要仓库，所以这里可以只有一个文件夹。

产品事实在 @launch/facts.md，它是唯一可信来源。要写的文案如果需要一个文件里没有的说法，
来问我，别自己编。每个交付物都是一个 Markdown 文件，进 Library，文件名带受众
（launch-email-developers.md）。

8. 带品牌规范的编辑流水线。 这类活上老版聊天 Projects 更合适：如果你只是想 Claude 拿一份风格规范去改零散稿子，那建个 claude.ai 项目、把规范放进知识库，比开线程省事得多。

9. 一稿多改台。 一份长素材进来——转写稿、release note、博客原文——多个渠道版本出去，一个渠道一个线程，五种格式一趟跑完。

素材在 /mnt/project-files。按 @channels.md 列出的渠道各产一版，一渠道一线程。
每一版都要能独立读：不许出现「如上所述」。某个说法单独被引用会站不住的，删掉并告诉我你删了。

10. 研究笔记本。 你会反复回去的题材。收益点在 Library 会把一手来源越攒越厚，后面的线程不用重新搜。

规矩：没有你亲自打开过的来源 URL，就不许下结论，并标注「accessed 2026-09-22」。
结论写进 research/<主题>.md：一行主张、原话或数字、然后 URL。厂商口径不一致时，
两个数都记，并标明各自是谁的说法。

非技术与个人事务

11. 合同与制度文件夹。 官方举的字面例子——你会带着新问题反复回来的文档。把文件夹上传，每份梳理会以文件形式回到 Library。

这些是我的合同和公司制度。只依据本项目内的文档作答，并按标题引用具体条款。
问题需要我还没上传的文档，直接点名缺哪份。每份回答末尾写「非法律意见」，
再加三条我必须亲自读的条款。

12. 行政与证件台账。 不性感但回本快：税单、保险续保、表格、保修到期——一个你全年往里丢东西、十二月一次性查询的项目。

目标：行政截止日期一个都别漏。维护 admin/register.md，逐条记事项、截止日、
原始文件在哪、还差我什么。我上传任何文件，先把日期抽出来记上。
30 天内到期的，每次回答都顶在最前面。

业务运营类

13. 工单分诊。 官方给的第二条非代码例子，也是不写代码的人最好的入门项目：「从这批工单里找出十个最常见的集成错误」。

读 /mnt/project-files 里的工单导出。按根因聚类，不按客户聚类，再按频次排序。
前十大类各写一份 support/top-issues/<slug>.md：现象模式、三个真实工单号、
我们现在怎么答、以及建议的自助文档。引用工单原话，别转述。

14. 售前应答库。 每个 RFP 问题都留答案，答案被反复复用。这里项目记忆本身就是产品——第十次回答应该长得和第一次一样，而不是每次重新猜。

已批准口径在 enablement/approved.md。每个 RFP 问题先搜它。搜到：原样复用。
搜不到：起草一条，顶部标 DRAFT — NEEDS SIGN-OFF，并追加到 enablement/pending.md。
凡是该文件里没有的 SLA 或集成承诺，一句都不要写。

15. 经营数字周报。 从导出表出发的一周一份，产出形式是页面而不是段落：Claude Code 能把会话输出发布成一个私有 URL 的 artifact，页面就地更新。

每周一：读 /mnt/project-files 里最新的导出，更新同一份报告。
开头先写变动最大的三个数字，以及那个需要人拍板的。发布成 artifact，URL 保持稳定。
某个指标当前导出算不出来，说出缺哪一列，别估。

开跑之前，先把额度算明白

项目的用量和你其他 Claude Code 会话走同一个套餐额度池，官方明确项目「can't spend past those limits on its own」——但它烧得更快，因为每个线程都是一次完整会话。截至 2026 年 9 月，文档写着并发数没有固定上限（「Claude starts as many as the work calls for」），同时跨你所有项目强制每天 200 个新线程。第一天就建议改两处默认：新项目的每个线程默认跑 Opus、high effort；以及给一个空闲超过一小时（Pro/Max 的 prompt cache 窗口）的线程追加消息，它会先把整段历史重读一遍，往往比新开一个线程更贵。长任务还要提醒线程随手 commit 并 push——暂停后恢复不出来的沙箱，会从一份全新克隆继续。

常见问题

一次该开几个项目？

一个。项目的价值来自记忆复利——早期拍板的决定会传给后面的线程——三个项目各自空着，你一分都拿不到。先挑你每周都会回去的那块，跑两周，再考虑加第二个。

示例里这些项目，没有 GitHub 仓库能跑吗？

非代码那几条完全能。文档写得很直接：「A project doesn't need a repository at all.」线程可以在自己的沙箱里做研究、写文档、跑代码，产物丢进 Library。仓库前置条件——代码在 github.com 上、装了 Claude GitHub App，GitHub Enterprise Server、GitLab、Bitbucket 都不算——只在线程要推分支时才会碰到。

Team 或 Enterprise 能用 Claude Code Projects 吗？

新版不能。截至 2026 年 9 月它是 Pro 与 Max 的 public beta，文档写明暂未覆盖 Team 与 Enterprise。老的聊天版与 Cowork 版在那些档位可用，也支持组织内共享和 Can view / Can edit 两档权限。

项目指令和仓库里的 CLAUDE.md 是一回事吗？

不是，混用是最常见的配置错误。项目指令会发给该项目里每一个新线程——上限 16,000 字符——包括那些根本不碰某个仓库的线程；而每个线程另外会读项目内每个仓库的 CLAUDE.md。官方的切分很清楚：关于某个仓库的规则写进那个仓库的 CLAUDE.md，关于这个项目怎么运作的规则写进项目指令。同一套作用域逻辑也适用于 AGENTS.md 文件。

我建的会自动共享给同事吗？

不会。beta 期间「A project belongs to one user」：项目和它的线程都不能共享，也没有组织级管控。线程发布出来的单个 artifact 可以用链接分享——控件说明看 Claude Artifacts 教程。

项目和 routine 有什么区别？

routine 是一份存好的提示词加仓库加连接器，按定时、API 调用或 GitHub 事件触发，处于 research preview，Pro/Max/Team/Enterprise 都有。项目是里面坐着一个协调者的对话。两者会接上：在项目里说要定时的活，Claude 就建一条 routine，以线程形式在该项目里跑。要把这些线程的活切到更便宜的模型上，看 Claude Code Router 教程。