个人知识库

2026-05-29-shawn-abu-claude-code-6-weeks

23分钟阅读

万字干货：这可能是全网最实战的「用 Claude Code 做产品」完整方法论

零基础产品经理 Shawn 用 6 周时间、约 1 万元预算、62,376 次 Claude Code 对话，独立写出 8.5 万行代码的 AI 桌面应用「阿布」（386 个文件 / 222 次 commit / 1,362 个测试），完整拆解了 PM 在 AI Coding 时代从「不懂技术」到「全链路交付」的工作流、工程纪律与避坑经验。

基本信息

  • 来源类型：网页文章（人人都是产品经理，woshipm.com）
  • 原文位置：raw/articles/2026-05-29-231616-tg-337b7a.md
  • 原文 URL：https://www.woshipm.com/ai/6399524.html
  • 副标题：零基础PM用Claude Code 6周造出AI桌面应用：62,376次对话、8.5万行代码背后的完整方法论
  • 作者：Shawn（公众号「Shawn的产品笔记」）
  • 发布时间：2026-05-21
  • 消化日期：2026-05-29
  • 开源地址：https://github.com/PM-Shawn/Abu-Cowork

核心观点

  1. 「想」的时间必须远超「写」的时间，这是 PM 用 Claude Code 的第一性原则。5 步循环是「想清楚 → 写需求描述 → 让 Claude 写 → 我 review → 跑测试 + 真机验证」，但重点在比例：Claude 写一个功能可能 10 分钟，想清楚”这个功能解决什么问题、用户链路是什么”可能要一个晚上，比例与传统开发完全反过来。作者反复强调：每次加新功能，第一段对话完全不提技术，只聊用户什么时候用、用完到哪、怎么知道做对了、什么边界不能碰——想清楚这些后技术方案会自然浮出来。跳过这一步，Claude 会默认取”技术上最合理”的方案，而技术上最合理的往往不是产品上最合理的（案例：让 AI 操作浏览器时，若不先说清场景，Claude 会默认推 Playwright 干净浏览器方案，而正确决策是复用用户已有登录态）。

  2. 一个功能从想到做完的真实规模数据：6 周（3 月 2 日 → 4 月 12 日）、62,376 条消息、45,004 次工具调用、约 1 万元（订阅 5,740 + API 5,000+）、386 个源文件约 8.5 万行（7 万行 TypeScript + 4,000 行 Rust + 1.5 万行测试）、1,362 个测试（76 个测试文件、8 秒跑完全量）、峰值日 3 月 1 日单日 9,259 条消息。阿布的技术能力清单包括：双协议 LLM 适配（同时支持 Anthropic 与 OpenAI 协议，retry / 成本统计 / 错误分类统一）、OS 级沙箱（macOS 用 Seatbelt、Windows 用 ConstrainedLanguage，操作系统层面真拦危险操作而非应用层”假装”安全）、Computer Use + 5 层安全防御、MCP 协议（stdio + HTTP 双传输）、多 Agent 编排、Skills 技能系统、4 种触发器引擎（HTTP webhook / Cron / 文件变更 / IM 消息）、IM 多平台集成（飞书 WebSocket 长连接、钉钉 event callback、Slack socket mode）、文件化记忆系统、自建 Eval 框架（23 个 case）、1,362 个自动化测试（8 秒跑完）。

  3. 多窗口并行是一个人同时推多个模块的最大提效点。开多个终端窗口，每个跑独立 Claude Code session 并行开发不同模块（典型状态：左窗口写 IM 适配层、右窗口写工具安全规则、中间跑测试）。三个前提：模块之间要解耦（两个窗口改同一文件会冲突）、CLAUDE.md 是共享的（规范纪律被统一遵守）、最后关掉多余窗口在主窗口跑全量测试。作者形容体验”接近我是一个技术负责人，手下有三个工程师同时在干活，只不过三个工程师都是 Claude，不需要开会对齐”。

  4. CLAUDE.md 是 PM 与 AI 之间的合同，也是可复利的数据飞轮。作者的 CLAUDE.md 有 273 行，记录：技术约束（不许用 enum 要用联合类型）、命名规范（变量英文 / UI 中文 / commit 中英双语）、踩过的坑（如「必须用 npm run tauri:dev（冒号），空格版会污染正式数据」）、分支纪律（禁止在 main 上直接开发）。核心心法是”每次踩坑就更新一条”——文件越长越厚，Claude 表现越好，因为它每次都在读你所有的教训。作者的判断：CLAUDE.md 不只是约束自己，也是约束 AI 的。

  5. 测试与 eval 的本质是”替我记住我可能忘记的事”，而这恰是 PM 不可替代的能力。版本注册表（把所有存本地的数据模块登记成清单，自动检查版本号是否递增、有无漏登记的新数据类型）被作者称为最有价值的测试实践——“最好的测试不是测功能对不对，而是测我有没有忘了某件事”（“设置”这类数据 6 周内改了 16 次格式，任何一次漏写 migrate 都会炸掉一批用户的本地数据）。Eval 框架则是 23 个评测 case 分 8 类（文件操作 4 / 搜索 8 / 命令执行 4 / 多步任务 2 / 记忆 2 / 网页 1 / 知识 1 / 代理委派 1），跨 provider（Claude / OpenAI / MiniMax）对比 26 个内置工具的工具选择准确率，不同模型跑完可 diff 报告。作者的结论：出题需要的能力（描述用户场景、定义”做对了”、定义常见错误模式）恰恰是 PM 最擅长的，代码部分全是 Claude 写的——“PM 在 AI 时代真正不可替代的能力，是替模型定义什么叫做对了”。

实操内容保留

代码/配置

CLAUDE.md 分支纪律条目（main 分支事故后写入）：

禁止直接在 main 上开发或 push commit。所有工作在 dev 分支进行。

每次开始工作前必做：
1. git branch --show-current —— 确认当前分支
2. 如果在 main，先 git checkout dev
3. git pull origin dev —— 拉取最新代码

版本号同步规则（发版翻车后写入，阿布三处存版本号）：

三处版本号必须同步更新：
- package.json（前端）
- src-tauri/tauri.conf.json（Tauri 配置）
- src-tauri/Cargo.toml（Rust 构建）

Eval 跨模型对比命令：

tsx src/eval/run.ts tool-selection --provider anthropic --model claude-sonnet-4-20250514
tsx src/eval/run.ts tool-selection --provider openai --model gpt-4o

真实双语 commit 示例：

feat(computer-use): sensitive app blocking + dangerous key interception

每个操作前检查前台 app 和按键组合安全性。敏感 app 用 bundle_id 匹配（跨语言）。

Design Token（阿布约定，写进 CLAUDE.md）：主色用克莱因蓝系、背景用柔白、文字用温暖灰、圆角 8/12/16 三档。

Prompt 模板

需求描述公式（User Story 标准格式）：

作为 [角色]，我想要 [功能]，以便 [价值]。

示例：「作为一个要整理发票的运营，我想要一个能批量读取发票图片并按日期重命名的功能，以便我每月不用手动处理 30 张发票。」

迭代分析三步法（大改之前先让 Claude 写”迭代分析”，不要直接说”帮我重构 XX”）：

第一步：「先读一下这个文件，告诉我它现在的设计是什么、为什么这么做」 第二步：「如果我要加 XX 功能 / 改 XX 行为，有哪些方案？每个方案的利弊和风险是什么？」 第三步：我看完它的分析，觉得它理解对了，才让它开始写

Bug 修复后补测试：

「这个 bug 你刚才修了，请写一个最小的测试用例覆盖它」

Review 时反复丢回去的三个问题：

「这段逻辑在 XX 情况下会怎样？」 「这个改动会影响 XX 模块吗？影响的话怎么处理？」 「这个方案的风险是什么？有没有更稳的做法？」

浏览器功能三轮对话模板：

第一轮：「我要做一个 Chrome 浏览器插件，用户装上之后，阿布能通过它看到用户打开的网页、帮用户点按钮和填表单。先帮我把这个插件写出来。」 第二轮：「现在帮我写桥接程序。它要能跟刚才那个插件对接，把阿布的指令翻译成插件能执行的操作。对接的格式就按刚才那份来。」 第三轮：「现在帮我写一份 Skill 说明书，教阿布什么时候用浏览器工具、什么时候不该用、每个操作是干什么的。」

Claude Code 内置功能（作者每天在用）：

/plan：只规划不动手，列方案分析利弊但不写一行代码（复杂功能先 /plan 出方案 → 我审 → 同意再写） /insight：分析过去 30 天使用数据，生成”你的工作模式是什么、摩擦点在哪、CLAUDE.md 该加什么规则”的报告（作者每月跑一次，把建议直接应用到 CLAUDE.md） /simplify：写完大功能后扫描改过的代码，找复用机会、质量问题、效率优化点并自动修（“让 Claude 做自己的代码审查”） /btw：开一个旁白通道，随手提问不打断当前开发上下文 /resume：恢复上一次会话上下文，跨设备跨时间段开发

操作步骤

5 步开发循环：

  1. 想清楚——明确用户场景和使用链路（最花时间的一步，可能一个晚上）
  2. 写需求描述——用 User Story 公式「作为[角色]，我想要[功能]，以便[价值]」
  3. 让 Claude 写代码
  4. 人工 review——通常 2-3 轮，4 个关注点：逻辑对不对（不是语法）、边界条件有没有想到、跟其他模块的耦合影响（问”有没有 breaking change”）、安全和用户体验
  5. 跑测试 + 真机验证

出 bug 时的三条原则：

  1. 把报错原文贴回去，不要用文字描述（“不要说有个地方报错了，直接把终端 error trace 粘过去”）
  2. 让它先解释根因再修（不要一上来就说”修一下”，否则可能只是”糊”补丁，根因没解决）
  3. 修完之后让它顺便写一条最小测试覆盖这个 bug（几秒钟的事，但 6 个月后 Claude 要”优化”这段代码时，那条测试会拦下它）

可持续构建 5 条纪律：

  1. 分支隔离：dev 分支写代码，main 分支给用户，绝不在 main 上直接开发
  2. 版本号同步：发版时所有版本号一起改，不能漏
  3. 提交前检查：build 能过、lint 没报错、测试全绿，才允许 commit
  4. commit 纪律：每个有意义的变更单独 commit，conventional commits 格式，中英双语
  5. 发版清单

发版清单（被固化进流程，每次让 Claude 按清单走）：

  1. 确保 dev 分支 build + lint + test 全绿
  2. 三处版本号同步更新
  3. git checkout main && git merge dev
  4. git tag vX.Y.Z
  5. git push origin main --tags
  6. 在 GitHub 创建 Release

浏览器操控功能的三件套拆解 + 真机验证：

  1. Chrome 浏览器插件——装在用户 Chrome 里，能看到用户打开的所有网页，帮阿布点按钮、填表单、提取文字（“伸进浏览器的一只’手’”）
  2. 中间桥接程序——在阿布和插件之间传话，Claude 用 MCP 协议封装了 17 个操作（截图、点击、填写、提取表格等）
  3. Skill 说明书——给阿布自己看的”什么时候应该用浏览器工具、17 个操作各是干什么的、用错了怎么办”
  4. 真机验证：手动装插件 → 启动桥接程序 → 让阿布”打开网页、提取标题” → 看是否跑通
  5. 第一次跑踩了两个坑：插件与桥接程序身份验证没对上（连不上）、某些网页内容动态加载（插件去找时页面还没渲染完）；修复后按惯例各写一条测试

给小白（过去自己）的 6 条建议：

  1. 先选一个你自己天天会用的小工具去做，不要做”大产品”
  2. 第一周不写测试，找感觉；等第一次被 bug 坑了再补
  3. 成本会比预期的高 3 倍（第一周烧 1000 块正常，Pro 额度很快不够用）
  4. 从第一天就建 CLAUDE.md
  5. 不要追求一次性做大功能，一个一个加，每个加完跑一遍测试
  6. 让 Claude 先想产品再想技术（“先告诉我用户是谁、场景是什么、做完之后是什么状态”）

关键概念

  • Claude Code — 本文核心工具，62,376 次对话 / 45,004 次工具调用；/plan、/insight、/simplify、/btw、/resume 等内置功能的实战用法
  • Vibe Coding — 非技术背景 PM 描述需求让 AI 写代码的最大规模实战验证
  • 独立开发者 — 一个 PM 独立完成从产品设计到架构、实现、测试、发版的全链路
  • AI编程开发 — 主题页：分支纪律、CLAUDE.md 合同、测试与 eval 的工程闭环
  • AI产品经理工作流 — 主题页：5 步循环、多窗口并行、review 方法、需求描述公式
  • AI 工作流方法论 — 主题页：PM 在 AI 时代从”写需求”到”定义对错”的角色迁移
  • MCP 模型上下文协议 — 阿布浏览器操控通过 MCP 接入，封装 17 个操作，支持 stdio 与 HTTP 传输
  • Skill — 重复性 SOP 沉淀为 Markdown 技能卡片，AI 自动识别何时激活（浏览器功能的第三件套就是一份 Skill 说明书）
  • AI Agent 智能体 — 阿布的多 Agent 编排：主 Agent 拆任务给子 Agent 并行执行，每个子 Agent 独立上下文
  • AI创业 — 1 万元预算 / 6 周 / 34 天有效开发时间的单人产品化成本结构
  • CLAUDE.md 合同文件 — 273 行，项目根目录，每次 Claude 工作前先读；“每次踩坑就更新一条”
  • Design Token — 颜色/间距/圆角/字体预定义并写进 CLAUDE.md，AI 自动保持视觉一致
  • Computer Use 与 5 层安全防御 — 敏感 app 黑名单、危险按键拦截、全局停止快捷键、会话超时、双中止通道
  • Eval 框架 — 23 个 case 分 8 类，跨 provider 对比工具选择准确率，结构化报告可 diff
  • 版本注册表 — 数据模块登记 + 版本号递增检查 + 漏登记扫描的三道锁
  • 4 种触发器引擎 — HTTP webhook / Cron 定时 / 文件变更 / IM 消息

与其他素材的关联

  • 与 2026-05-27-pm-vibe-coding-5-products 的关系：Iris 的 Vibe Coding 方法论（先 PRD 后编码、# 指令写入 CLAUDE.md）在本文得到最大规模验证。Shawn 的 5 步循环（想清楚 → 需求描述 → Claude 写 → review → 跑测试验证）与 Iris 的四步工作流（调研三问 → 苏格拉底 PRD → 原型三阶段 → Kickoff）同源，但 Shawn 把规模推到 6 周 / 8.5 万行 / 62,376 次对话量级，并补上了 Iris 未覆盖的工程纪律层（版本注册表、发版清单、eval 框架）。
  • 与 2026-05-27-woshipm-codex-product-dev-lessons 的关系：四月用 Codex 独立开发 macOS 番茄钟 App 的心得与本文高度一致——“一句话让 AI 写代码必然翻车”、AI 卡壳时需要人工指引方向。但四月停留在单个 App，Shawn 给出的是更完整的工程化方法论（1,362 个测试、23 case eval、OS 级沙箱、跨平台 Mac + Windows）。
  • 与 2026-05-28-woshipm-ai-workshop-multi-agent-collaboration 的关系：麦克先生构建 AI Workshop 多 Agent 共享工作区，Shawn 在阿布内部实现了多 Agent 编排（主 Agent 拆任务给子 Agent 并行执行），两者共同验证”管理 AI 比使用 AI 更重要”。
  • 与 2026-05-11-ai-evaluation-scoreboard 的关系：本文的 23 case tool-selection eval 是该主题在个人产品中的落地样本——“定义什么叫做对了”的能力来自 PM 而非工程师。

原文精彩摘录

我花在”想”上的时间，比花在”写”上多得多。Claude 写一个功能可能 10 分钟，但我想清楚”这个功能到底要解决什么问题、用户使用链路是什么”可能要一个晚上。这个比例跟传统开发完全反过来了。

那一晚模型试图打开我的钥匙串。阿布有一个 Computer Use 功能，模型能看屏幕、点鼠标。某天晚上我在 dev 环境跑测试，模型截屏看了一圈，然后在 Spotlight 搜索框里输入了”Keychain Access”。那一瞬间我意识到，模型完全有能力打开我电脑上任何 app。第二天我从早上写到深夜，连发 5 个 commit，一次性加了敏感 app 黑名单、危险按键拦截、全局停止快捷键、会话超时。那是我做阿布以来最有”产品恐惧感”的一天。

我发了一次版搞炸了用户数据。改了一个字段名，我本地测了没问题就发版了。当晚用户说”打开是空白”。因为老用户存在硬盘上的是旧字段名，新代码读不到。从那以后我做了”版本号 + migrate + 注册表”三道锁，到现在设置数据结构已经改了 16 次，再没出过这种事。

这个做法的核心启发是：最好的测试不是测”功能对不对”，而是测”我有没有忘了某件事”。

你可能觉得”PM 搞这个是不是小题大做”。但做完之后我发现，eval 的本质不是技术，是”想清楚怎么判断对错”…… PM 在 AI 时代真正不可替代的能力，是替模型定义”什么叫做对了”。

AI Coding 不是让你写代码更快 —— 它逼你直面那些以前可以装看不见的问题。安全、数据迁移、分支管理 —— 这些事你以前可以说”等有工程师了再想”，现在你就是那个工程师。

你不需要学会编程，你需要学会跟一个会编程的伙伴说话。

相关页面

关系图谱

快速导航

反向链接