Claude Code首次仓库审计清单：第一次编辑前先画清地图

在既有仓库里第一次使用 Claude Code，不应该从编辑开始，而应该从画地图开始。它读文件很快，但只有知道入口、保护区、验证命令和业务导线时，这种速度才安全。

这个搜索意图很明确：初学者想在真实代码库里使用 Claude Code，但不想失控。目标不是马上做功能，而是在20分钟内看清 scope、risk、verification 和 revenue CTA。

相关阅读: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-harness-lite-workflow.

为什么要在第一次编辑前先建立这个框架

Claude Code 在任务边界清楚时最可靠。好的边界会写明可以读取哪些文件、可以编辑哪些文件、哪些操作绝对不能运行，以及用什么证据结束工作。没有这个边界，初学者的小请求也可能变成大范围重写，内容修改也可能悄悄破坏免费PDF、Gumroad或咨询入口。

这个模式也适合收入导线，因为它把技术证据和读者证据放在同一张检查表里。页面在本地能 build，但把读者送到错误商品，就还没有完成。记录 scope、command、public URL 和 CTA，明天就能根据记录继续优化，而不是重新回忆。

实际工作中的流程

1. 先只读 README、package.json 和路由入口
2. 把 generated、billing、auth、migrations、.env 标成保护区
3. 第一次允许编辑的范围限制在三个文件以内
4. 修改前先选一个 proof command
5. 内容站或落地页还要把免费PDF、Gumroad和咨询链接纳入审计

场景	安全做法	验证方式
Astro内容站	创建文章前先看 content collection、slug规则、heroImage 和 CTA 模式。正文和付费路径都属于审计范围。	build, diff, URL
React运营后台	小的布局问题只看目标组件、CSS规则和截图验证，auth 与 billing 保持保护。	screenshot, test
API仓库	先读路由路径和测试命令，第一次任务不要碰数据库 migration 和 secrets。	log, command, handoff

第一次检查要短。审计要产出的是判断，不是庞大的报告。如果20分钟后仍然判断不清，安全的下一步不是开始编辑，而是决定还需要再读哪一个文件。

可直接复制的提示词和代码

请在第一次编辑前审计这个仓库。暂时不要修改。返回入口文件、保护区域、可以安全编辑的文件、最小验证命令，以及公开URL和CTA检查项。

const audit = {
  repo: "customer-portal",
  intent: "first safe Claude Code session",
  scope: ["README.md", "package.json", "src/routes"],
  protected: [".env", "billing/", "migrations/"],
  proof: ["npm.cmd run build", "git diff --stat"],
};

export function readyForFirstEdit(report) {
  return report.scope.length > 0 &&
    report.protected.length > 0 &&
    report.proof.some((command) => command.includes("build"));
}

console.log(readyForFirstEdit(audit));

这段代码故意很小。它把一个操作原则变成可检查的对象：有 scope、有保护区、有至少一个验证命令。你可以把这个形状改成文章发布、应用开发、调试或团队交接版本。

三个真实例子

Astro内容站

创建文章前先看 content collection、slug规则、heroImage 和 CTA 模式。正文和付费路径都属于审计范围。

关键是证据。保留一个命令、一个可见页面，或一条能说明工作已经到达读者的记录。

React运营后台

小的布局问题只看目标组件、CSS规则和截图验证，auth 与 billing 保持保护。

关键是证据。保留一个命令、一个可见页面，或一条能说明工作已经到达读者的记录。

API仓库

先读路由路径和测试命令，第一次任务不要碰数据库 migration 和 secrets。

关键是证据。保留一个命令、一个可见页面，或一条能说明工作已经到达读者的记录。

需要避免的失败情况

• 一上来要求修复所有问题，会把审计和实现混在一起。
• 本地 build 通过不代表完成，公开URL或CTA指错页面仍然失败。
• 保护区没有写清楚时，善意修改也可能变成事故。

另一个隐蔽问题是本地化漂移。英文文章可能解释了正确商品路径，但其他语言还保留旧 CTA。因此公开检查必须看每个语言的 h1、正文开头和 CTA 文案，不能只看 frontmatter 的 lang。

如何把读者引向免费PDF、Gumroad和咨询

如果读者还需要熟悉命令，先让他下载 免费速查表。如果瓶颈是安装、权限、CLAUDE.md、hooks、MCP 或 CI/CD，就推荐 Setup Guide。如果每天都在重复写 review、debug、refactor 提示词，就推荐 50 Prompt Templates。如果问题已经变成团队流程、上线纪律或收入路径设计，就引导到 导入咨询。想比较所有资源时，可以查看 products。

不要把所有读者立刻推向付费产品。初学者通常先需要低摩擦的PDF。反复写同样提示词的中级读者更接近模板。被权限、CLAUDE.md、hooks、MCP 或 CI/CD 卡住的读者更接近 Setup Guide。团队流程和运营设计问题更接近咨询。

发布前后要验证什么

本文的验证不只看 HTTP 200。还要确认 h1、正文开头、heroImage、内部链接、Gumroad 链接和咨询入口都服务同一个读者意图。

多语言发布要分别检查日语、英语、中文、韩语、西班牙语、法语、德语、葡萄牙语、印地语和印尼语。slug 一致不代表正文是新的。移动宽度截图能同时看到开头段落和 CTA，比只查 frontmatter 更快发现问题。

接下来要看的数字

接下来要看这个 slug 的 PDF 开始数、Gumroad 点击、products 访问、training 访问、搜索来源、国家分布和文章到 CTA 点击率。PV 上升但 Gumroad 点击不变，就要强化商品匹配。如果技术文章带来咨询访问，读者需要的可能是工作流设计，而不是普通教程。