单枪匹马赚取 160 万美元：全球顶尖创作者都在用的 Claude Code 高阶工作流

用 AI 不只是写代码，而是当作 24/7 运营一人公司的员工

当人们听到"用 AI 赚钱"时，大多数人想到的都是同样的事情：

• 让 ChatGPT 写博客文章。
• 用 AI 批量生产图片。
• 把 AI 生成的视频发到 TikTok。
• 让 AI 写程序来批量生产应用。

然而，仅靠这些方法就能大幅赚钱的案例少之又少。

这是因为你只是用 AI 在增加"工作量"而已。

就算把文章数量从 10 篇增加到 100 篇，如果没有读者，收入也不会增加。就算把应用数量从 1 个增加到 10 个，如果解决不了客户的问题，也没人愿意付费。

在 AI 时代真正强大的人，不会把 AI 当作内容制造机。

他们用它来让公司本身变得更小。

他们不招开发者。

他们不增加客服。

他们不开会。

他们不在人与人之间传递规格文档。

他们不让代码经过本地到生产环境的多个阶段才交付。

当客户的需求到来时，AI 读取代码、修复代码、测试代码，让用户在几分钟内就能使用。

这种极致做法的典型代表，就是独立开发者 Pieter Levels。

他对 Claude Code 的使用方式，可以用一句话概括：

不要把 Claude Code 当作"方便的编码助手"，而要当作住在服务器里的员工。

在这篇文章中，我们将拆解 Pieter 的做法，并将其转化为日本独立开发者和中小企业主可以复制的形式。

Pieter Levels 是谁？

Pieter Levels 是一位独立开发者，推出了 Nomad List、Remote OK、Photo AI、Interior AI 等多个互联网服务。

他广为人知的原因之一，是他那个"12 个月建 12 个创业项目"的计划。他没有筹集大笔资金去组建团队，而是遵循快速发布服务、只培育那些获得反馈的项目这种风格。

他目前的核心服务之一是 Photo AI，一个 AI 照片生成服务。

用户上传自己的照片，服务会创建该人的 AI 模型，用来生成影棚风格的照片、头像、时尚照片、旅行照片、视频等。Photo AI 官网显示，至今已生成超过 3000 万张照片。

2024 年 3 月，Pieter 公开了 Photo AI 的以下数据：

更令人惊讶的是，他透露该服务的核心运行在一个约 40,870 行的巨型 PHP 单文件上。

听到这个，一般的工程师可能会皱眉头。

"这么大的文件根本没法维护。"

"应该拆分成微服务。"

"应该用更现代的框架。"

但收入不会为代码的优雅买单。

只要你能交付用户想要的结果并维持好状态，技术配置不需要照搬教科书。

Pieter 的优势不在于比别人更懂前沿技术。

而在于他彻底舍弃了那些不带来收入的复杂性。

严格来说，他不是"只靠 AI"赚到的钱

这一点不要误解。

Pieter 并不是某天开始接触 Claude Code，然后突然就靠 AI 独自年赚 160 万美元。

他有多年开发经验。他在互联网上有名气，有可以向其推广产品的粉丝。他有判断市场的眼光、定价的能力，以及解读用户反馈的经验。

AI 并没有从零创造一切。

AI 放大了他原本就拥有的开发能力、判断能力和营销能力。

这个差别非常大。

使用 AI 并不会让经验变得多余。相反，随着 AI 提升实现速度，判断"该做什么"、"卖给谁"、"不该做什么"的价值变得更高。

因此，这篇文章的真正主题不是"往 Claude Code 里输入什么神奇提示词才能赚几百万"。

而是 如何用 Claude Code 创建一个系统，让一个人以公司的速度运转。

方法一

让 Claude Code 住在 VPS 上，而不是笔记本上

Pieter 操作中最显著的一个特点，就是他在服务运行的 VPS 上运行 Claude Code，而不是在本地笔记本上。

据他所说，大约一年来，他几乎所有的编码工作都是在 VPS 上用 Claude Code 完成的。即使合上笔记本，处理也能继续，不消耗电池，而且可以从另一个终端或智能手机接手工作。由于新服务可以从已经在服务器上的状态开始，因此可以直接上线发布。

典型的开发流程是这样的：

1. 规划。
2. 在本地环境写代码。
3. 本地测试。
4. 推送到 GitHub。
5. CI 运行。
6. 反映到预发布环境。
7. 确认后部署到生产环境。

在大型组织中，这个流程是必要的。因为几十个工程师触碰同一个系统，所以需要防止事故的边界。

但是，当一个人运行的小型服务也采用大公司的流程时，会发生什么？

修复本身只需要 3 分钟，但上线却要花 20 分钟。

小麻烦不断累积，导致"这个改动可以等会儿再做"的判断增加。即使客户发来了需求，修复也会推迟到明天或下周。

Pieter 把这个等待时间缩到了极短。

以前，本地测试和通过 GitHub 自动部署大约需要 1 分钟。改为直接推送到服务器后，大约需要 3 秒，而现在他正在朝着让 Claude Code 直接在服务器上修改代码的方向发展。虽然他提到在 12 个月内网站只宕机了大约两次，每次约 10 秒，但他也明确表示大公司应该使用预发布环境。

这里值得模仿的重点不是"所有人都应该直接编辑生产环境"。

应该模仿的是 把 AI 放在它能持续工作的地方。

只要你在自己的电脑上运行 Claude Code，合上笔记本工作就停止了。连接断了也停止。如果换到另一个终端，就得从头解释一遍情况。

通过在 VPS 上保持持久会话，AI 可以一直待在项目旁边。

这不只是环境设置上的差异。

而是 把 AI 可以工作的时间与人类操作时间解耦，而不仅仅是增加"使用 AI 的时间"。

方法二

给每个产品分配独立的持久会话

Pieter 使用 Termius 连接 VPS，并为每个服务准备了连接配置文件。

连接后，他进入该服务的目录，然后进入对应的 tmux 会话。在每个会话中，Claude Code 都保持打开状态，因此可以从笔记本电脑或智能手机回到同样的工作。他甚至让 Claude Code 创建了 shell 函数，方便连接和回到 tmux。

这个系统的重要之处不在于终端操作看起来很酷。

而在于 每个产品都有自己的专用工作间。

• Photo AI 的工作间里有 Photo AI 的代码和 Claude Code。
• Nomad List 的工作间里有 Nomad List 的代码和 Claude Code。
• Remote OK 的工作间里有 Remote OK 的代码和 Claude Code。

当人类切换产品时，只需要进入那个工作间就行。

对于一般的聊天式 AI，每次开始对话都需要解释。

"这是这样的服务。"

"上次我做到了这里。"

"请不要修改这个文件。"

"用这个命令运行测试。"

这种解释成本会拖慢 AI 的利用效率。

另一方面，如果在项目目录中保持 Claude Code 运行，AI 可以直接访问代码、配置文件、测试和历史记录。即使人类不从零开始解释，它也能调查"这个产品的当前状态是什么"。

Anthropic 的官方文档也说明，Claude Code 不仅是一个返回代码建议的工具，而是一个可以读取文件、执行命令、修改代码、调查、规划和实现的 Agent 工具。

换句话说，要发挥 Claude Code 的优势，需要让它在一个能访问整个产品的地方工作，而不是每次把代码片段粘贴到聊天框里。

方法三

传递"完成状态"，而不是"写代码"

即使使用 Claude Code 也得不到结果的人，要么指令太详细，要么太模糊。

例如，像这样的请求：

请改进登录界面。

这样写，不清楚什么算是改进。

• 修改设计？
• 修改错误提示？
• 提高登录速度？
• 添加 Google 登录？
• 想降低跳出率？

反过来，指令每一行代码也是低效的。

在这个文件的第 35 行添加一个函数，然后修改这个变量名...

这种情况下，你只是把 Claude Code 当作一个输入速度比你快的键盘。

你应该传递的不是工作步骤，而是 完成条件。

实践中，像下面这样的格式比较好用：

目标：

减少因登录错误导致的流失。

当前状态：

无论是密码错误还是连接错误，都显示同样的"登录失败"。

修改范围：

登录界面、认证 API、相关测试。

完成条件：

• 输入错误和连接失败显示不同的消息。
• 不泄露邮箱地址的存在。
• 不破坏现有的 Google 登录。
• 在智能手机显示上布局不崩坏。
• 所有相关测试通过。

禁止事项：

• 不修改数据库结构。
• 不添加新的认证库。

工作完成后：

• 总结修改过的文件。
• 展示已执行的测试。
• 报告遗留风险。

使用这种格式，Claude Code 可以调查代码库，自行找到需要修改的位置，并思考实现方法。

人类的角色从"怎么写"转变为"什么状态能提供价值"。

在这里，管理和开发连接起来了。

要写出好的完成条件，你必须理解客户在为什么而苦恼。一个能够观察客户行为、付费原因和流失原因的人，可以给 Claude Code 分配比只关注技术的人更有价值的工作。

在 AI 时代，重要的不是提示词词汇。

而是定义完成状态的能力。

方法四

把 CLAUDE.md 变成"一人公司的运营手册"

Claude Code 有一个机制，可以把项目特定的指令保存在 CLAUDE.md 中。

官方文档说明，CLAUDE.md 在对话开始时被读取，你可以列出构建和测试命令、编码规范和工作规则。但建议保持简短具体，不要写成长篇手册，也不要把读完代码就能理解的东西写进去。

大多数人只在这里写缩进宽度或变量命名规则。

但在一人公司里，真正重要的不是代码风格，而是 业务优先级。

例如，你可以这样写：

产品目标

• 本服务面向个体经营者，让其在 10 分钟内创建产品照片。
• 优先保证首次生成的速度，而不是功能的多少。
• 对于会增加免费用户使用量的改动，始终检查对成本的影响。

架构

• 使用 PHP、JavaScript、PostgreSQL。
• 未经明确许可，不添加新框架。
• 如果现有机制可以解决，不增加依赖。

工作流程

• 修改前先阅读相关代码和测试。
• 对于较大的改动，先提出计划再实施。
• 修改后，执行测试、静态分析，并检查主要页面。
• 不要通过删除测试来解决问题。

安全

• 不删除生产数据。
• 数据库变更附带回滚步骤。
• 不在日志中输出 API 密钥或个人信息。
• 对计费、认证、删除功能要极其谨慎。

完成的定义

• 能够从用户角度解释改动。
• 报告测试结果。
• 列出修改过的文件。
• 明确说明已知风险和未处理事项。

有了这个，每次就不需要重复同样的注意事项了。

更重要的是当 Claude Code 出错时如何处理。

不要只是生气"又犯了同样的错误"，而是把防止再犯的规则添加到 CLAUDE.md 中。

如果它修改了生产配置文件，就写"未经明确许可，不得修改配置文件"。

如果它为了通过测试而删除了重要的验证，就写"禁止删除失败的测试"。

如果它格式化了无关文件导致 diff 变得很大，就写"不得进行与请求无关的重构"。

Anthropic 也指出，反复出现的错误或多次解释过的事情，是应该添加到永久指令中的迹象。

换句话说，CLAUDE.md 不只是 AI 的配置文件。

它是一人公司积累的失败和判断的数据库。

在雇用员工的公司里，知识会积累在培训材料或内部 Wiki 中。

在一人公司里，你让 Claude Code 来读取它。

方法五

减少审批工作，增加护栏

Pieter 使用了一种显著省略 Claude Code 权限确认的模式，在服务器上高速工作。

他表示，自从切换到这种操作方式，开发速度飙升，任务板首次变空，输出量达到了平时的 10 倍左右。他在短时间内完成了多个产品的改动，包括认证和安全改进、图像功能、视频/音频功能、3D 查看器、newsletter、聊天机器人、电子书生成等。

但是，完全复制这部分是危险的。

Claude Code 的官方文档明确说明，相当于 bypassPermissions 的操作只应在有外部安全边界的情况下使用，例如隔离的容器或虚拟机。因为一旦省略确认，最后一道防线就只剩下执行环境的隔离了。

如果日本独立开发者要采用这种做法，与其完全复制 Pieter 的操作，不如这样转换：

调查阶段使用计划模式

首先，让它调查相关文件、影响范围、实现策略和风险，但不让它修改代码。

特别是对于计费、认证、数据删除、邮件发送等事故影响大的部分，不要让它立即实施。

在预发布环境中自动化实现

准备一个与生产环境配置相似的预发布环境，让 Claude Code 在那里进行修改和测试。

与其每次审批每个命令，不如预先划分允许的操作和禁止的操作。

官方文档提供了多种权限模式，例如 acceptEdits 允许修改、auto 自动判断安全性、plan 只创建计划。你也可以按命令设置 allow、ask 和 deny。

只留一个人工审批环节用于生产部署

• 测试通过。
• 界面确认完成。
• diff 在预期范围内。
• 有回滚方法。

达到这个状态后，人类才允许生产部署。

重要的不是人类写每一行代码。

而是创建一个结构，当出现问题时可以回滚，人类只处理最后不可逆的判断。

方法六

优先测试和回滚，而不是代码审查

当 AI 开始编写大量代码时，人类逐行检查所有内容的方法达到了极限。

即使代码生成速度提高了 10 倍，如果审查需要 10 倍的时间，生产力也不会提高。

因此，需要改变信任的所在。

不要相信"Claude 一定写对了代码"。

要相信这个系统：

• "如果错了，测试会失败。"
• "主要用户操作可以自动确认。"
• "如果有问题，可以立即恢复到之前的状态。"

Pieter 自己也优先准备测试并在生产中快速确认的反馈循环，而不是详细检查所有内容。他还解释说，服务器上有多个备份，结合了本地和异地备份。

在安全的 Claude Code 操作中，至少先创建以下四个要素：

1. 主要功能的自动化测试。
2. 生产前的操作确认。
3. 检测错误和收入异常的监控。
4. 可以在几分钟内恢复到之前状态的回滚。

使用 Claude Code 的 Hooks，你还可以自动化流程，例如在文件更改后执行测试或格式化程序，或者在特定操作之前插入检查。Hooks 是一个官方功能，可以在 Claude Code 的特定生命周期执行 shell 命令、HTTP 处理、LLM 判断等。

例如，在修改后自动执行以下流程：

代码修改

↓

自动化测试

↓

静态分析

↓

主要页面的操作确认

↓

diff 总结

↓

如果有问题则停止生产部署

通过这种方式，人类的工作从"查看所有内容"变为"只查看异常"。

独自赚大钱的人不只是工作速度快。

他们是在减少需要确认的工作本身。

方法七

把客户需求直接变成 Claude Code 的工作队列

在 Pieter 公开的一人公司配置中，他结合了收集用户需求的反馈板、面向客户的 Stripe 计费管理界面、用户可以自行操作的退款功能，以及使用 ChatGPT API 的自动化处理。

他展示的理想形态是"1 个创始人，0 个员工"，一个由他负责营销、开发和设计，其他一切尽可能自动化的模式。

在这里，Claude Code 不仅用于创建新功能。

它变成了一个将客户声音转化为带来收入的改进的装置。

例如，像这样的流程：

用户提交需求

↓

分类相似需求

↓

检查对流失率和付费率的影响

↓

选择一项高价值任务

↓

Claude Code 调查影响范围

↓

实施和测试

↓

通知用户改进完成

当你创建了这个系统，任务管理的意义就变了。

在许多公司中，收到需求后，他们会开会、写规格、确定负责人、放入 sprint，最后几周后才上线。

在一人公司中，有可能当天就发布。

小公司能赢过大公司的地方，不是功能数量。

而是客户声音反映到产品中的时间。

如果你已经引入了 Claude Code，但人类仍然在详细拆解任务、复制粘贴代码、逐一指定修改位置，那你并没有利用好 AI 的速度。

把客户问题和完成条件传递过去，让 Claude Code 自己去调查代码库。

这就是把它当作聊天机器人和当作员工之间的区别。

方法八

大胆避免复杂化技术配置

Photo AI 的核心是一个超过 40,000 行的 PHP 单文件，这并不意味着所有开发者都应该创建巨大的文件。

相反，模仿表面形式是危险的。

对 Pieter 来说，重要的不是 PHP 或巨大的文件。

重要的是 将系统保持在他和 Claude Code 能够把握的范围内。

这是根据公开信息得出的解读，但如果你把一个产品拆分成太多小服务，每次改动都会涉及多个仓库、API、认证方法和部署流程。

对人类来说复杂的系统，对 AI 来说也是复杂的。

• 需要加载到上下文中的文件更多。
• 调查修改位置需要时间。
• 只更新一侧会导致不一致。
• 测试范围扩大。
• 故障时定位原因变得困难。

即使你有 Claude Code，也不意味着可以管理无限复杂的技术配置。

AI 降低了复杂性的成本，但并没有让它变成零。

因此，在引入新库、新服务、新数据库、新框架时，要这样思考：

这项技术增加了客户获得的价值吗？ 还是仅仅为了开发者的技术满足感？

一个创造了年营收 2 亿日元产品的人，不一定选择了最现代的配置。

这对许多独立开发者来说是一个重要的事实。

方法九

让 Claude Code 创建"公司自动化"，而不仅仅是"开发"

许多使用 AI 编码工具的人只考虑实现产品功能。

但是，独自赚大钱所需的不只是产品本身。

• 回复问询。
• 检测欺诈使用。
• 更改计费信息。
• 退款。
• 取消。
• 内容审核。
• 故障通知。
• 定期报告。
• 收入汇总。
• 客户引导。

随着业务增长，这些运营工作也会增加。

如果收入翻倍，问询也会翻倍，如果还需要双倍的人力，一人公司就无法维持。

在 Pieter 公开的配置中，他通过 Stripe 客户功能、自助管理界面、自动退款以及使用 AI API 的工作脚本，减少了人类介入的点。

你应该让 Claude Code 制作的东西，不光是新的花哨功能。

而是能消除"你每周花 30 分钟做的工作"的代码。

例如，如果你每天早上检查收入并写到 Slack 里，就创建一个自动化报告。

如果有很多相同问题的问询，就改进管理界面或帮助页面。

如果每次退款请求都要操作管理界面，就创建有条件的自助退款。

如果你在肉眼检查欺诈使用，就检测异常值，只发送需要人工判断的案例。

每一个都是小规模的自动化，但它们加起来会改变公司的固定成本。

既要创建增加收入的功能，也要创建消除自己工作的功能。

这就是留下利润的 Claude Code 使用方法。

方法十

让 Claude Code 成为后台工作进程

Claude Code 不仅可以在交互界面中使用。

官方提供了使用 claude -p 的非交互式执行、限制允许工具的执行、结构化输出以及会话延续功能。它还被设计为可以从 CI 或脚本中调用，并集成到后台处理中。

利用这一点，你可以让 AI 在人类不启动对话的情况下生成工作。

例如，每晚执行以下流程：

1. 检查过去 24 小时的错误日志。
2. 归类为同一原因的报错。
3. 调查重现方法。
4. 创建修复方案。
5. 在预发布环境中修复。
6. 执行测试。
7. 第二天早上，向人类报告 diff 和风险。

或者，让它分析从用户收到的问询：

1. 按主题对咨询进行分类。
2. 汇总数量及收入影响。
3. 提取可通过产品原因解决的项目。
4. 按优先级对改进候选进行排序。
5. 为最高优先级项目制定实施计划。

到这一步，Claude Code 不再是“只有人类跟它说话它才回答的 AI”。

它变成了一位员工，在夜间完成调查，并在早上准备好判断材料。

然而，在后台运行得越多，安全设计就越重要。

将删除、转账、计费、批量发送给客户以及更改生产数据等不可逆操作，排除在自动化范围之外。

你必须将赋予 AI 的自由度以及出现故障时的损害范围，作为一组因素来考虑。

最大的秘密

即使你用 Claude Code 提高了开发速度，客户也不会增加

在 Pieter 的帖子中，最重要的不是技术层面的讨论。

他指出，有很多独立开发者沉迷于构建复杂的 AI Agent 环境或“AI 开发工厂”，却没有收入或流量。他说，他们满足于搭建开发环境，却把市场营销抛在脑后。

此外，他还表示，随着任何人都能用 AI 制作应用，真正的挑战变成了分发——即触达客户的能力。

• 你能否已经触达很多人？
• 你能承担广告费用吗？
• 你能生成 UGC 吗？
• 你是否有免费制造热度的想法？

随着开发变得更容易，这些分发能力上的差异会变得更大。

这就是 AI 时代的残酷现实。

当你引入 Claude Code 时，功能可以快速完成。

然而，即使开发速度提高了 10 倍，如果流量为零，收入也为零。

更危险的是，由于构建速度加快，你可能会大量生产没有需求的功能。

每增加一个功能，代码量、测试、故障风险以及咨询响应都会增加。

即使客户没有增加，维护项目也会增加。

因此，用 Claude Code 节省下来的一半时间，必须用于开发以外的事情。

• 倾听客户的声音。
• 阅读竞品评论。
• 调查产品卖不出去的原因。
• 测试价格。
• 重写销售页面。
• 发布案例研究。
• 在社交媒体上分享制作过程。
• 创建让用户愿意推荐给他人的机制。

Claude Code 的真正价值，不在于缩短编写代码的时间。

在于为人类赢回思考客户和市场的时间。

日本独立开发者可复制的 30 天计划

即使你没有 Pieter 那样的经验、名气或粉丝，你也可以采纳他的经营理念。

但是，你不能从一开始就创建多个服务。

首先，聚焦于一个产品、一个客户和一个问题。

第 1 周：在写代码之前，找到愿意付钱的人

你在第一周要做的，不是一个完整的服务。

而是决定要解决谁的、什么样的问题，以及如何解决，收费多少。

不要扩大目标范围。

与其说是“面向所有公司的 AI 工具”，不如缩小范围，比如“为房地产公司提供 10 分钟内创建房产描述的工具”。

与潜在客户交谈，确认他们目前使用什么方法，需要多少分钟，以及遇到多大的困难。

然后创建一个简单的销售页面。

不要只放一个免费注册按钮，如果可能的话，要显示价格。加入能让用户实际采取行动的机制，比如预注册、预约或小额预购。

如果在这个阶段没有反应，即使让 Claude Code 制作大量功能，情况也不会改变。

第 2 周：只提供一个核心价值

在接下来的一周，只制作用户愿意付费的核心功能。

推迟登录、管理后台、详细的个人资料设置、大量模板、团队功能等，直到它们变得必要。

先让 Claude Code 调查现有配置，并制定实施计划。

一旦计划确认，就让它在预发布环境中进行实施和测试。

此阶段必须包含的内容是：访问分析、计费、错误监控和咨询窗口。

无法确认收入的产品不是生意。无法确认错误的产品，无法自行驱动。

第 3 周：创建让 Claude Code 不会迷失的环境

在第三周，与其增加新功能，不如安排好运营基础。

将产品的目标、技术配置、禁止事项、测试方法和完成条件写入 CLAUDE.md。

为每个产品准备一个 VPS 或安全的开发环境，以及一个持久的会话。

确保当 Claude Code 做出更改时，测试、静态分析以及主要页面的操作确认会自动运行。

同时确认备份和回滚。

这里的目标不是“完全信任 AI”。

而是要确保，即使 AI 犯了错，业务也不会遭受致命打击。

第 4 周：花与开发同样多的时间用于销售

在最后一周，每天发布一项改进。

但是，不要凭自己的喜好决定改进内容。

要根据用户的反应来决定，比如咨询、流失点、支付前的行为以及取消原因。

• 早上，选择一个对收入影响最大的问题。
• 让 Claude Code 进行调查和实施。
• 测试后发布。
• 下午，将这项改进告知客户。

如果你分享自己改进了某件事，这本身就是一种营销。

与其说“我在开发”，不如展示“我昨天收到的请求今天就已经实现了”，这更能传达产品的速度和可靠性。

单人公司日常运营循环

在引入 Claude Code 之后，不要注册大量任务，而是每天运行以下循环：

早上：查看数据

查看收入、注册数量、付费转化率、取消数、错误数和咨询数。

从业务的状态开始新的一天，而不是从代码开始。

上午晚些时候：选择一个价值最高的单一问题

与其做十个小任务，不如选择一个。

判断标准不是“是否有趣”，而是对收入、留存率和使用成功率的影响。

中午：将完成条件传递给 Claude Code

让它调查相关代码并确认计划。

之后，让它进行实施、测试和差异总结。

人类不详细指导工作流程，而是传达客户期望的正确结果。

下午：发布并触达客户

发布改进后，事情并没有结束。

通知发送相应请求的用户。在社交媒体上分享制作过程。在销售页面上体现。将其做成案例研究。

始终将开发完成的项目与分发联系起来。

晚上：将当天的失败转化为规则

确认 Claude Code 在哪里迷失了方向，在哪里做了不必要的更改，以及人类重复解释了哪些内容。

如有必要，在 CLAUDE.md 中添加简短的规则。

每天，AI 都会一点点地为你的公司进行优化。

绝对不要模仿的事情

Pieter 的案例很令人兴奋，但如果你只模仿表面，你会失败。

突然让它在生产环境中自由操作

在涉及生产数据、计费、认证和客户通知的环境中，跳过所有权限检查是危险的。

首先，在隔离的开发或预发布环境中操作，并限制允许的操作。官方文档也指出，省略权限检查的模式需要容器或 VM 等隔离措施。

只模仿那个巨大的 PHP 文件

一个 4 万行的文件并不是收入来源。

它是 Pieter 选择了一种自己能够理解并快速更改的配置的结果。

技术配置应该与你的产品、经验、用户数量和故障风险相匹配。

在未确认需求的情况下，用 AI 大量开发

当开发成本下降时，对制作的判断会变得松懈。

不要“因为能快速做出来就做”，而要“因为这是付钱客户的问题才做”。

在向 Claude Code 提出请求之前，要确定那个更改会改善哪个指标。

混淆收入与利润或个人收入

月收入 10.5 万美元和月利润 8 万美元是不同的数字。

此外，业务利润和个人实际到手收入也不同。它取决于税收、结算费用、基础设施成本、AI API 成本、退款等的处理方式。

在看待大数字时，你需要确认它是“收入”、“毛利润”、“营业利润”还是“个人收入”。

假设 AI 能纠正商业判断

Claude Code 可以调查代码库、制定实施计划并执行测试。

然而，某个功能是否真的必要，应该如何定价，以及瞄准哪些客户，这些仅仅通过阅读代码是无法理解的。

当你把市场判断交给 AI 的那一刻，它就会变得和其他 AI 用户制作的普通产品一样。

创造百万美元收入的不是秘密提示词

看到 Pieter Levels 利用 Claude Code 就认为“我用同样的提示词也能赚钱”，这是一个错误。

秘密不在于提示词。

• 将 Claude Code 部署在 VPS 上。
• 为每个产品提供一个持久的会话。
• 传递完成条件。
• 在 CLAUDE.md 中积累判断标准。
• 通过测试和备份为故障做好准备。
• 立即将客户需求反映到产品中。
• 自动化你重复执行的操作任务。
• 将省下的时间用于市场营销。

优势在于将这些组合成一个单一的系统。

Claude Code 的价值不在于能快速编写代码。

而在于能够将以下循环变得极其短暂：

客户遇到问题 ↓ 了解原因 ↓ 修复 ↓ 发布 ↓ 衡量结果

在普通公司需要数周的循环，一个人可以在一天内，甚至在某些情况下，在几小时内完成。

如果这种速度持续数月，产品之间的差异将变得巨大。

然而，AI 创造的是供给，而不是需求。

• 你在解决谁的问题？
• 他们为什么付钱？
• 你将如何让人们知道你的存在？
• 为什么选择你的产品而不是竞争对手的？

人类必须找到这些问题的答案。

在 AI 时代，“只有海外天才在做的事情”不是编写困难的提示词。

而是在 AI 夺走他们的工作之前，利用 AI 将工作本身从公司中消除。

并且，他们利用消除工作所节省的时间，不是去编写更多代码，而是去理解客户和销售产品。

这就是为什么即使一个人，也能经营年营业额 2 亿日元、年利润 1.6 亿日元的企业。

Claude Code 不是一个能让你赚取数百万美元的神奇工具。

然而，对于那些拥有正确客户、正确产品和正确销售能力的人来说，它变成了 一个将一个人的判断力放大到公司规模的设备。