前阵子帮一个朋友快速验证产品想法,从需求梳理到上线一个可用的小工具,整个过程比预想中顺很多。功劳一半得给 Claude Code,另一半得给“先想清楚再动手”这件事——也就是我这次想重点聊的 PSB 框架。
Claude Code 是 Anthropic 官方出品的终端编程 Agent,简单说就是装好之后,你可以在命令行里用自然语言和它对话,让它读项目代码、写代码、改 bug、跑测试甚至做重构。它和网页版聊天最大的区别是:它长在项目目录里,能看到文件结构,能直接执行命令,干活是“沉浸式”的。这篇文章我会用一次真实可复现的 MVP 构建过程,讲清楚怎么从创意出发,用 PSB 把需求钉死,再用 Claude Code 把发布这件事跑通。适合正在犹豫要不要把想法落地的人,也适合想系统了解 Claude Code 使用流程的开发者。
1. 先用 PSB 把“做什么”钉死
很多 AI 编程翻车现场,问题根本不在代码写不出来,而是启动之前根本不知道自己要什么。Claude Code 执行速度越快,方向错得就越远。所以我通常建议:在打开终端之前,先用 PSB 框架把产品一页纸写出来。
1.1 PSB 说白了就是三个连续的问题
PSB 最常见的展开是 Problem-Solution-Benefit,对应三个问题:你要解决什么问题,你给出的方案是什么,用户得到什么收益。
- Problem:你发现了一个什么真实、具体、高频的问题?
- Solution:你打算给谁提供一个什么东西去解决它?
- Benefit:用户用了之后,能省下什么、赚到什么、爽到什么?
这三句话必须写下来,而且要写得很具体。不能是“用户时间管理做不好”这种正确的废话,而是“做独立开发的小团队,每周要花 2 小时手动汇总各个平台的日报,经常漏数据,没人愿意干”。
我第一个演示项目原本想做“团队周报自动汇总工具”,结果 PSB 一写出来就发现问题:5 个人的小团队,周报汇总本身不痛,痛的是老板要看跨项目进度。于是我第一版马上改成了“跨项目进度合并报表生成器”。范围小了一大截,但价值清楚了很多。PSB 的作用就是逼你在还没浪费一行代码之前,先把方向校准。
1.2 为什么 MVP 阶段特别需要 PSB
MVP 的核心理念,是用最小成本验证最大风险。Claude Code 写代码很快,但快是用来缩短验证周期的,不是用来掩盖方向错误的。
很多项目做着做着就失控,典型症状是需求清单越写越长:要登录、要权限、要可视化、要移动端适配、要消息通知。两个星期过去,最该验证的那个核心假设根本没碰到。PSB 能治这个问题,因为它逼着你把所有需求重新排一遍:哪些功能直接服务于核心问题?哪些功能只是为了“看上去完整”?凡是不直接服务于 Problem、不直接产生 Benefit 的,MVP 阶段一律砍掉。
做完这步之后,你再用 Claude Code 就有底气了。因为需求被压缩成一个很小但完整的主线:一个页面、一个表单、一个列表、一次结果输出。Claude Code 对这种“小而完整”的任务处理质量最高,生成代码更聚焦,迭代也更快。
1.3 用一页纸模板把 PSB 落到文字
建议在动手前建一个 MVP_PSB.md 文件,写清楚下面几个字段:
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 目标用户 | 谁在为这个问题花时间或金钱 | 3~10 人的项目型小团队 |
| 核心问题 | 用户当前最痛的 1 个点 | 跨项目进度靠人工汇总,周例会前手忙脚乱 |
| 解决方案 | 最小功能主线 | 粘贴各项目日报,自动生成合并后的进度报表 |
| 核心收益 | 用户可感知的价值 | 汇总时间从 2 小时降到 10 分钟 |
| 成功指标 | 用什么判断验证通过 | 连续 2 周有 3 个团队主动使用 |
这个文件不只是给自己看的,它还是后面给 Claude Code 的“需求说明书”。我在实际使用中会把 MVP_PSB.md 放进项目根目录,然后在 Claude Code 里直接说“先读一下 MVP_PSB.md,再按里面的定义搭建项目”。它会真的先读文件、再开始动手,产出的东西明显更贴合需求,少几次答非所问的来回。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Claude Code 是什么,以及它能帮到什么程度
开始装工具之前,得先认识这个工具。Claude Code 不是普通代码补全插件,它是一整套可以独立干活的终端编程 Agent。
2.1 官方出品的终端编程 Agent
Claude Code 由 Anthropic 官方开发,继承 Claude 系列模型的推理能力,以命令行为主要交互界面。它有几个关键设计:
- 居住在项目目录里,可以递归读取文件、分析项目结构。
- 能执行终端命令,比如启动测试、运行构建、安装依赖。
- 支持多轮对话式编程,可以通过自然语言持续调整。
- 闭源,官方版本强绑定 Claude 系列模型。
它和 Cursor、Copilot 这类编辑器插件的核心差别,在于“执行链”的完整程度。Claude Code 不只是给你补全代码,而是会自己规划:先改哪个文件、再跑哪条命令、测试是否通过,然后继续下一步。这种模式非常适合 MVP 阶段的大量琐碎改造。
2.2 适合与不适合的场景清单
用了一段时间之后,我整理了一个场景清单,方便你判断自己的项目适不适合用它。
适合的任务:
- 从零搭建工具类 MVP、后台管理面板、数据看板。
- 写一次性脚本处理表格、文本、文件转换。
- 在已有项目里修 bug、补单测、做小范围重构。
- 生成 API 接口文档、项目 README。
- 学习陌生代码库,让它替你解释某个模块的调用关系。
不适合的任务:
- 需要严格架构设计的大型分布式系统。
- 对数据安全、权限审计有专门要求的内部系统。
- 业务逻辑极复杂、需要多人评审的核心模块。
- 对模型选择有强依赖的场景。
2.3 两个必须说清楚的边界
关于模型绑定:Claude Code 官方版本没有“切换模型供应商”这样的配置项,网上有很多第三方转发工具或者魔改方案,本质属于非官方行为。安全性和可用性都没有保障,我不建议在正式项目里折腾,出现问题你也很难排查。
关于可用区域:Claude Code 有官方支持地区清单。如果你的账号所在地不在支持范围内,启动时客户端会给出明确提示,此时无法正常使用。遇到这个提示请以官方渠道公布的信息为准,个人配置层面没有可靠的处理办法,也不要轻信来路不明的针对方案。
3. 环境准备:安装和配置没有想象中难
从热搜词看,很多人卡在安装这一步。确实,Claude Code 的安装有一些前置要求,但搞清楚之后其实很顺。
3.1 先装 Node.js 再装 Claude Code
Claude Code 以 npm 包形式分发,所以第一步是安装 Node.js。建议安装 18 或更高版本,太老的版本运行时会报错。装完 Node.js 后,在终端里执行:
bash复制npm install -g @anthropic-ai/claude-code
安装完成后验证一下:
bash复制claude --version
如果能正常输出版本号,说明安装成功。接下来在项目目录里启动:
bash复制cd your-project
claude
第一次启动通常会引导你登录 Anthropic 账号。终端里会展示一个授权链接,浏览器打开、确认授权,再回到终端就可以开始对话了。
如果 npm 下载速度比较慢,可以先把 npm 源切到国内镜像,这个操作是常规本地配置,不影响工具本身:
bash复制npm config set registry https://registry.npmmirror.com
然后重新执行安装命令,速度会明显改善。
3.2 在 VSCode 里配置与使用
VSCode 用户有几种使用方式。最简单的一种是直接用 VSCode 内置终端,在项目目录下启动 claude,既不离开编辑器,又能看到完整的代码上下文。
还有一种方式是安装 Anthropic 官方的 Claude Code 插件。装好后,VSCode 侧边栏会出现独立的 AI 操作面板,也可以让插件读取当前打开的项目上下文。
这里提醒一点:插件版本和 VSCode 版本之间存在兼容关系。如果你遇到的提示是“版本不兼容”,优先把 VSCode 升级到最新稳定版,然后再更新插件,基本都能解决。如果还是不行,就退回只用终端方案,功能完全不受影响。
3.3 安装阶段的高频报错与处理
结合社区里反馈较多的报错,我整理了几个典型:
claude: command not found:说明 npm 全局安装目录不在系统 PATH 里。检查 npm 全局路径,或者重装 Node.js 时勾选自动配置 PATH 的选项。EACCES: permission denied:npm 全局目录没有写权限。不要直接莽sudo,更推荐把 npm 全局目录改到用户目录下,一劳永逸。not logged in:安装成功但提示未登录。直接在终端里运行/login重新走授权流程。- 启动后卡在登录界面:一般是本地浏览器授权回调异常。退出终端,重新运行
claude,换一个浏览器授权大概率能通。
安装阶段的坑基本都是环境问题,和 Claude Code 本身无关。把 Node.js 环境弄干净,90% 的安装问题自愈。
4. 从创意到发布:用 Claude Code 构建 MVP 的完整流程
下面进入主线:从创意到发布,完整跑一遍 MVP 构建。我这里以“跨项目进度合并报表生成器”为例,技术栈选 Node.js + 原生 HTML/CSS,这样不依赖复杂的脚手架,部署也轻量。
4.1 把需求说明书喂给 Claude:生成项目骨架
先在本地建目录并进入:
bash复制mkdir dev-report-mvp && cd dev-report-mvp
把 MVP_PSB.md 放进这个目录,然后启动:
bash复制claude
第一句需求可以这样写:
“先读一下项目根目录里的 MVP_PSB.md,然后基于它搭建一个 MVP。技术栈:Node.js 做后端 API,前端用原生 HTML/CSS/JS,数据存在本地 JSON 文件里,先不做用户系统。”
Claude Code 会先确认自己理解了需求,然后给出实施计划:创建哪几个文件、每个文件负责什么、API 路由怎么设计。确认没问题后,它会开始创建文件。
这个过程我遇到一个关键操作习惯:必须明确告诉它“先做最简版本”。否则它容易顺手加很多装饰性功能,把 MVP 做重。你的原话里每次带上“MVP 阶段不需要 XX”,它就会收敛很多。
4.2 对话式迭代:改功能、补样式、修 bug 的现场记录
项目骨架生成之后,迭代是高频动作。我记录几个真实对话片段供参考。
第一轮:后端接口跑通之后,我想快速看效果,就输入:
“帮我在本地启动一个开发服务器,端口用 3000,启动后告诉我访问地址。”
它启动服务器,给出 http://localhost:3000,我打开页面发现界面很简陋,于是继续:
“前端页面做成卡片式布局,每个项目一张卡片,顶部放汇总栏。不需要复杂的样式框架,手写 CSS 就行,移动端先不管。”
第二轮:我把一份模拟日报数据粘贴进去,要求“支持从文本里自动识别项目名、完成进度、风险项”,结果它识别逻辑写得太简陋,同一个项目的记录被分到了两张卡。我直接把现象和样例数据丢给它:
“样例数据里 PROJ-A 出现了两次,但应该合并到同一张卡。帮我调整解析逻辑,按项目名去重合并。”
它改了逻辑,重新跑通。
这些迭代过程里,最需要注意的操作是:把方案讲清楚再让它动手,不要只抛一句“帮我优化一下”。模糊的指令换来的是模糊的改动,来回消耗的上下文比多写两句描述贵得多。
4.3 别让对话“失忆”:会话记录与里程碑保存
很多人在搜索“Claude Code 怎么保存对话历史”。这个需求很实际,因为一次对话记录的是从生成骨架到迭代的全部上下文。如果中途崩了或者想回滚,没记录就很被动。
Claude Code 默认会把会话记录写在本地 ~/.claude/projects/ 目录下,里面有按项目分目录的 JSONL 日志。你需要导出成可读文档时,可以在会话里用 /export 把当前对话导成 Markdown。
我的习惯是每个里程碑结束后做一次导出:骨架生成完导出一次,核心功能跑通导出一次,上线前导出一次。导出的 Markdown 和 MVP_PSB.md 放一起,作为项目过程文档存档。后续新开会话时,可以把导出的摘要粘给 Claude Code,让新会话快速恢复上下文。
4.4 上线发布:MVP 部署的最短路径
MVP 验证的是价值,不是部署架构。所以我的建议是别在部署上浪费超过 30 分钟。
如果项目是纯静态页面,直接推到 GitHub 仓库,开 GitHub Pages,或者拖到 Vercel、Netlify 自动部署。这类平台对静态站点基本是零配置。
如果项目带 Node.js 后端,最简单的方式是买一台轻量云服务器,安装 Node.js 环境,把代码传上去,用 pm2 常驻运行。整个流程可以写成几条命令,Claude Code 能直接帮你生成部署脚本:
bash复制npm install --production
pm2 start src/index.js --name dev-report
部署完访问 IP 加端口,看到页面能正常展示数据,这个 MVP 就算跑通了。记得用手机试一次核心路径,因为真实用户第一次打开产品,用的往往是手机而不是你的开发电脑。
5. 让 Claude Code 更好用的几个进阶习惯
工具用久了会发现,真正提升效率的不是某个神奇命令,而是几个不起眼的日常习惯。
5.1 控制上下文:一次只干一件事
Claude Code 的上下文窗口是稀缺资源。很多人用着用着发现它“变笨了”,是因为一个会话里积累了大量无关历史:改过登录页、调过报表、聊过部署,然后你再让它处理数据解析逻辑,它要从前面的历史里捞信息,效果自然差。
我的经验是:一个会话只做一件主线任务。做界面就只做界面,调接口就只调接口。做完一个里程碑,导出记录,开新会话。另外,如果项目里有大量 node_modules 之类的目录,可以在 .claudeignore 里排除掉,避免它每次扫描无关文件。
5.2 用 CLAUDE.md 给 AI 一份“入职说明书”
Claude Code 会优先读取项目根目录下的 CLAUDE.md,把它当作项目的背景知识。这就相当于给 AI 一份“入职说明书”,里面写清技术栈、目录结构、常用命令和开发约定。比如:
markdown复制# 项目约定
- 技术栈:Node.js 18 + 原生 HTML/CSS/JS
- 后端入口:src/index.js
- 数据存储:data/reports.json,修改时用 fs.promises API
- 本地启动:npm run dev,端口 3000
- 组件风格:手写 CSS,不引入 UI 框架
写好 CLAUDE.md 之后,每次新会话启动,Claude Code 都会自动理解项目背景,不需要你重复解释“这个项目是什么、用什么写的”。这个文件值得认真维护,它省下的上下文空间非常可观。
5.3 知道什么时候该喊停
Claude Code 有时候会一本正经地写出有逻辑漏洞的代码。尤其是涉及数据合并、状态更新这类业务逻辑时,它可能把表面问题修好,却引入新的边界问题。
所以我对 AI 生成代码有个强制验收习惯:每次它完成改动,我都亲自跑一遍核心路径,至少覆盖“新建一条数据、查看列表、处理异常输入”这 3 个场景。涉及删除数据、权限校验、支付操作的代码,我还会人肉仔细读一遍,不放心就写单测锁定行为。这个习惯帮我挡住过好几次上线事故。
6. 高频问题排查与避坑实录
最后这部分,我把实际操作中容易遇到的问题整理成速查表,方便你直接对照。
6.1 高频问题速查表
| 问题现象 | 可能原因 | 处理方式 |
|---|---|---|
claude: command not found |
npm 全局目录未加入 PATH | 检查 npm config get prefix,配置 PATH 后重开终端 |
| 提示 not logged in | 登录态失效 | 运行 /login 重新授权 |
| 登录返回 403 | 账号权限或地区限制 | 以官方支持范围为准,可尝试注销重登 |
| VSCode 插件版本不兼容 | VSCode 版本过旧 | 升级 VSCode 和插件到最新稳定版 |
| 沙箱起不来 | 系统权限或依赖缺失 | 检查 Node 版本、重装依赖、重启终端 |
| 显示 PDF 有密码 | 尝试读取加密 PDF | 移除文件密码限制,或让 Claude Code 跳过该文件 |
| 会话上下文错乱 | 一个会话塞了太多任务 | 导出记录后新开会话 |
| 对话历史找不到 | 不清楚存储位置 | 查看 ~/.claude/projects/,或用 /export 导出 |
6.2 几个容易判断错的“坑”
第一个坑是“AI 说完成了,就是完成了”。Claude Code 跑完命令如果没报错,它会倾向于告诉你“搞定”。但“没报错”不等于“功能正确”。尤其是它对现有代码的改动,可能出现没有生效、改错文件的情况。务必自己跑一遍验证。
第二个坑是“项目越大,Claude Code 越弱”。这句话不完全准确,更准确的说法是:项目结构越混乱、无关文件越多,它的表现越差。我见过有人在几万行的老项目里让它改一个深层逻辑,结果它不断猜测,来回试错。解决办法不是不用它,而是把任务拆小、把上下文聚焦,必要时让它先画出调用链再动手。
第三个坑是“新鲜感驱动开发”。拿到这类工具,人很容易陷入“拼命加功能”的状态。Claude Code 生成代码太容易了,你会忍不住想做更多。但 MVP 阶段,每一项新增功能都意味着验证周期拉长。我的做法是:每周看一次 MVP_PSB.md,凡是发现代码库里出现了计划外的功能,就主动删掉或者标记为 V2。守住最初的 PSB 定义,比什么都重要。
用 Claude Code 做 MVP,最大的效率提升不是“代码写得快”,而是“验证周期被大幅压缩”。动手之前把 PSB 想清楚,动手的时候让它专注主线,每个里程碑导出记录,每次改动亲自验收。这套流程跑通之后,你会发现“从创意到发布”真正需要的时间,比你想象中少很多。
