Claude Code 第一周命令地图：初学者按顺序运行的 12 个命令

为什么要做成独立产物

本文为刚安装 Claude Code、想稳稳度过第一周的初学者设计第一周命令地图。常见失败很直接：新用户从安装直接跳到大请求，却不知道用哪个命令证明进展。Claude Code 的工作不能停在一个自信回答，而要留下别人可以检查的产物。这里的产物是从读取仓库到验证一个小改动的按天命令地图。

把这个产物当成 prompt、命令行和公开页面之间的契约。它要说明 Claude Code 读了什么、改了什么、用哪个命令证明结果，以及读者下一步该进入哪个收入路径。这个主题和 harness engineering、getting started、permissions 直接相关。

运营循环

循环分五步：定义 action，选择 proof，让 Claude Code 做最小有用工作，验证输出，再记录下一个收入动作。这里的 proof 不只是代码运行。要看build 成功、小 diff、审批意外减少，以及初学者文章的 PDF 开始。这些字段可见后，你就不用靠猜测改文章。

1. 第一天只读：先梳理文件、命令和高风险目录，再要求修改。

2. 第三天只允许一个可回滚编辑，并且先选好验证命令。

3. 第五天写交接笔记，让下一次会话从证据开始而不是靠记忆。

可复制的 starter

$checks = @(
  "git status --short",
  "rg --files | Select-Object -First 40",
  "npm.cmd run build"
)

foreach ($cmd in $checks) {
  Write-Host "NEXT:" $cmd
}

三个现场例子

例子 1. 第一天只读：先梳理文件、命令和高风险目录，再要求修改。

例子 2. 第三天只允许一个可回滚编辑，并且先选好验证命令。

例子 3. 第五天写交接笔记，让下一次会话从证据开始而不是靠记忆。

自我复查清单

在把这个流程变成习惯之前，像检查 release note 一样检查文章。第一项是 scope：读者要知道什么时候使用第一周命令地图，什么时候一个更小的 checklist 就够了。第二项是 proof：每个建议都要能指向 command、URL、diff 或 metric。第三项是 routing：免费 PDF、Gumroad guide 和咨询路径不要互相抢位置，而要回答不同紧急程度的问题。

再写一个小 owner rule。一个人负责产物，一个人负责验证，一个人负责下一次 CTA 实验。个人项目里可以是同一个人，但 note 里仍然要写清角色。这样 Claude Code 不会把发布、计量和销售文案混成一个模糊任务。下一次运行也能知道从哪里继续。

最后问一个实际问题：明天早上，什么会让这篇文章更容易验证？如果答案是 screenshot，就保存它。如果答案是更强的 prompt，就放进 prompt pack。如果答案是更清楚的边界，就写进 setup note。从读取仓库到验证一个小改动的按天命令地图只有能被下一次 session 继续使用时才有价值。

实际运营中，发布当天的检查和第二天的复盘都很重要。发布当天确认 build、deploy、HTTP 200、h1 和 canonical。第二天再看搜索流量停在哪个段落，读者有没有到达 PDF form，Gumroad link 有没有点击，是否进入咨询页面。把build 成功、小 diff、审批意外减少，以及初学者文章的 PDF 开始放在同一行，可以避免只看 PV 就宣布成功。

给 Claude Code 的权限也要分阶段。先 read-only 分析，再允许一个文件的小修改，最后才做 build 和公开 URL 验证。如果一开始就把 deploy 和商品导线都交给 agent，失败点会变得很模糊。第一周命令地图不是为了制造流程负担，而是为了决定下一步可以放心交给 agent 的范围。

收入路径不是越用力销售越好，而是分流要准确。初学者给免费 PDF，重复工作给 Gumroad，团队导入和权限设计给咨询。当正文里的例子和 CTA 指向同一个问题时，读者更容易做出下一步行动。

最后把时间轴也写清楚。发布当天看技术正确性，第二天看读者行为，一周后看收入路径。这样不会把所有判断都压在同一个 PV 数字上。从读取仓库到验证一个小改动的按天命令地图也可以帮助团队把短期验证和长期收入判断分开。

失败情况

第一个失败是只看 PV。第二个失败是没有 proof command 就批准修改。第三个失败是所有读者都送到同一个付费产品，即使有的人更适合免费 PDF 或咨询。解决方法是在改 CTA 前先写 routing rule。

收入路径

按瓶颈分流读者。需要命令熟练度，就去 免费 PDF 或 free Gumroad cheatsheet。如果每周重复同类工作，就去 50 Prompt Templates 或 Setup Guide。如果问题是 rollout、risk 或 revenue design，就去 咨询。对本文来说，free cheatsheet 负责日常记忆，Setup Guide 适合把命令地图变成团队规则。

验证指标

发布后不要只看 HTTP 200。要确认 h1、canonical、hero image、正文开头、CTA link、mobile layout 和语言。然后观察build 成功、小 diff、审批意外减少，以及初学者文章的 PDF 开始。如果指标不动，先改第一个具体例子附近的 CTA，而不是重写整篇。