A Product Manager's Workflow
一个产品经理如何用 Claude Code 完成从调研到产品上线的全链路工作
我是一名产品经理，不写代码、不看代码。但过去一个月，我通过 Claude Code 独立完成了 7 个项目，覆盖竞品调研、数据管线、Agent 产品开发、实验设计、评测体系构建。
以下是真实案例。
Case 01
Flipbook 是一个"AI 生成无限视觉浏览器"，每一页都是实时生图，我想做一个 HTML 版本。问题是：它的技术细节没有公开文档，也没有开源代码。
这个案例的核心不是"一句话搞定"，而是一个我持续引导、追问、纠偏的过程：
我提出目标，Claude Code 先通过 WebFetch 和 WebSearch 静态分析，输出了一份初步的技术摘要。但我觉得不够深入——它没有真正"用过"这个产品。
关键是——Playwright 方案不是 Claude 自己想到的，是我提示"能否操作浏览器"后它才想出来的替代方案。
这一段 Claude Code 自主执行了很多步：
Claude 给了一份总结，但我觉得关键细节不够：
Claude 回答了 tap 模式的请求结构。我继续深挖：
Claude 发现之前抓的 prompt 被截断了，重新注入 JS 脚本抓取完整的 authored_prompt 和 final_prompt。
追问变量的具体含义和实测值。Claude 给出了三个场景下的实测数据表。
指出哪些发现需要落入文档。
看完文档后给出质量反馈：
Claude 重写了技术原理部分，增加了完整的加工链路流程图。
做完后我继续反馈：
最终部署上线，拿到链接。
| 我做的事 | 本质 |
|---|---|
| "你能操作浏览器吗" | 提供方法灵感，它自己解决技术方案 |
| "tap 传给模型的上下文是什么" | 追问关键细节，不满足于表面回答 |
| "{parent_title} 是什么" | 深入追问变量含义，确保理解准确 |
| "这个很重要，写进去" | 判断重要性，决定什么值得记录 |
| "先不着急做网页" | 控制节奏，确认质量再推进 |
| "输入输出说的还不够细" | 质量把控，要求更高精度 |
| "我有个 deploy skill 你找找" | 提供资源，告诉它可用的工具 |
从"我想了解这个产品怎么做的"到拿到部署好的研究报告网页，全程 1 个对话，但包含 6 轮有实质引导的交互。最终产出：
Case 02
我在做一个 Agent 产品，需要从小红书爬取优质创作者的内容，然后"蒸馏"成结构化的经验供 Agent 使用。
我让 Claude Code 使用 xhs-cli 搜索旅行垂类创作者，自动整理成表格：
"你先找 10 个旅行类的，给我整理成一个表格，列好基础信息和主页链接，我来 check 给你反馈"
Claude Code 搜索后生成 Markdown 表格，我在表格里加"bob 备注"列，逐个标注通过/不通过。然后：
"我写了十个，你同步看看，我继续看"
Claude Code 自动分析我的标注模式（看了多少内容、准确率如何），反推改进搜索策略。
使用 media-crawler-pro skill 批量下载创作者的全部笔记（图文 + 视频），包括：
实际案例：一篇保险科普笔记原文只有 200 字，9 张信息图经视觉模型理解后，正文扩展为完整的险种体系 + 保额表 + 各险攻略。
"看一下小菜这个作者的内容，能总结出哪些实际旅行经验"
Claude Code 阅读全量内容后，提取出结构化的"经验条目"—— 不是攻略，而是"只有真实去过才说得出的判断"。
人机协作标注：AI 批量处理 + 我做质量判断，形成迭代闭环。典型对话：
我："我觉得不能只看一篇的原因是我们需要蒸馏一个人，至少需要主页内容丰富"
Claude Code：自动更新筛选策略文档
Case 03
我的 Agent 产品需要"访谈"创作者来收集他们的经验。访谈 Agent 的设计直接决定了经验的质量。
这是一个纯对话式的产品设计过程，Claude Code 扮演我的产品搭档：
Phase 1：对齐目标
我先拒绝了 Claude 要去执行的冲动，坚持讨论清楚实验变量：
Phase 2：概念澄清
我定义了"经验"的概念：一个人真实做过某件事之后形成的判断和感受。不是攻略，不是框架，是"朋友会怎么跟你说"。
Phase 3：评估标准讨论
Claude 提出三层评估标准，我说"第二层不清楚，第三层数量不是绝对要求"。经过 3 轮拉扯后收敛到：
经验条目的质量只看两件事：专属性（只有她才说得出）和 可用性（能帮用户做判断）
Phase 4：系统设计
Claude 重新来过，设计了一个三模块的迭代系统：
Phase 5：实现架构
讨论出访谈者必须做成 Agent（而非纯 model + SP），因为需要诊断失败在哪一步。三个组件：
整个设计过程没有写一行代码。我只是在和 Claude Code 讨论，它帮我：
后续我真的跑了 3 轮实验（v1 → v2 → v3），每轮根据结果迭代 system prompt。
Case 04
我想做一个 no-code 的产品：用户不看代码，只看文档和结果。底层用 Claude Code SDK 驱动 Agent 执行任意操作。
"根目录下放了我的产品文档和技术文档，请你阅读并帮我实现，实现前请先规划，另外质疑不合理的地方以及可以简化验证版本的地方"
Claude Code 的第一反应不是开始写代码，而是质疑我的技术方案：
我坚持必须用 Claude Code SDK（因为 Agent 能力是核心），Claude Code 接受后调整方案：用 CLI 子进程 + stream-json 模式驱动。
Claude Code 完成了全栈开发：
过程中我不断报 Bug：
disabled={!activeProject}，没有项目时锁死了每次我只描述"看到的现象"，Claude Code 自己定位代码位置并修复。
我："现在好了，这个问题我们改了好久，总结一下"
Claude Code 输出了问题根因分析和修复历程。这就是 vibe coding 的真实体验——我只看页面效果，它负责所有技术细节。
Case 05
我在做一个 Skill 驱动的生活助手 Agent 产品，需要一套系统化的评测框架来衡量 Agent 的能力。这不是一个点状任务，而是一个完整的评测数据集构建工程。
我先设计了一个多维度的评测框架（agent-eval-framework.md），覆盖：
每个维度下写了具体的 Case，形成可执行的评测数据集，自动构建成 Wiki 页面并部署。
这是最耗时的部分——我和 Claude Code 逐条审查和修改 Case 的判定标准：
每一条我都在追问"这个评判标准本身是否合理"，而不是让 AI 自己决定。
"请你阅读这个论文（GAIA），看看我的评测逻辑和文章是否类似，有哪些需要优化"
"我更想了解我的 case 设计维度是否合理"
Claude Code 对比了 GAIA 论文的三级难度分类方法，指出我的框架缺少 C3（记忆管理）的具体 Case。我让它直接构建：
"c3 当时做的时候没有写 case，请你基于 agent-eval-framework.md 帮我构建 c3 吧"
Claude Code 写了 21 条 C3 Case，覆盖 5 个子维度（短期记忆利用、记忆更新、记忆冲突...），每条都有明确的信息不对称设计。
发现模型"不爱输出图片"这个系统性问题后，我让 Claude Code 新建一个评测维度。写了 21 条 Case 后我反馈：
Claude Code 承认偷懒，重新梳理了高频出图场景（商品、穿搭、家居、健身动作、发型、家装...），补充了多样化的 case。
"请你倾尽全力寻找所有的相关资料，帮我分析我的评测方式"
Claude Code 并行启动 5 个研究方向：
我和 Claude 就报告结论展开讨论：
然后讨论了"结果有效性"应该作为独立维度还是在现有 Case 上调整：
最终确认了 process 评测和 outcome 评测并存的方案。
评测数据集构建完成后我跑了一轮测试，发现通过率太高：
"我已经测完了 b1 b2 b3，但我发现满分通过的 case 很多，是不是我们的评测数据集太简单了"
Claude Code 对比了公开测试集的客观难度，帮我分析了后续如何增加难度和"陷阱 case"。
这个项目体现了一种产品经理做评测工程的方式：
Core Insight
我在一次产品设计讨论中说过：
"我乐于使用 Claude Code 因为它可以帮我做产品研究，并且方便地管理上下文。如果直接在 Claude 中使用，就没有这样的上下文管理体验，因为它是一个瀑布流。但在 Claude Code 中我可以和 agent 脑暴，让他写方案并修改，然后和 agent 一起协作。"
这不是一个程序员的选择，而是一个信息管理者的选择。对我来说，Claude Code 的核心价值不是"能写代码"，而是：
每个 .md 文件都是 agent 可以随时读取的 context。我的蒸馏项目里：
这些文件不只是文档，它们是跨会话的 context 层。新开一个对话，一句"请你阅读蒸馏项目思路"就能把之前所有的决策历史加载进来。
我在不同文件夹下工作，每个文件夹就是一个独立的 context 域：
切换目录 = 切换工作上下文，不用手动"告诉 AI 我在做什么"。
Skill 不只是工具，它是一种结构化的 context 注入。当我说"使用 media-crawler-pro"时，agent 不只是获得了爬虫能力，而是获得了一整套关于"如何签名、如何处理限流、cookie 格式是什么"的结构化知识。
我把能力沉淀为 Skill 后，以后任何项目都可以直接调用，不用重复解释。
我说过："我们最关键的是管理 context...文档交互只是一个更合适的创作环境。"
实际工作中的交互模式：让 agent 写文档 → 我在文档上反馈 → agent 读反馈修改 → 循环。
这和 Chat 对话的根本区别是：产出物本身就是持久化的 context，而不是消失在对话流里。
Methodology
"先不用这么细，我们继续讨论清楚实验逻辑，不用进入执行"
我经常阻止 Claude Code 直接动手，先把逻辑讨论清楚。讨论清楚后一句"开始吧"即可。
我的每一个指令几乎都在管理 context：
本质上，我在不断地把 ephemeral 的对话 context 转化为 persistent 的文件 context。
我不做执行层面的事，只做判断层面的事。典型例子：
把常用能力封装成 Skill（类似插件）：
media-crawler-pro：多平台爬虫xhs-bulk-download：小红书批量下载cloudflare-deploy：一键部署静态页面lark-doc：飞书文档读写ark-vision：图片理解tada-artifact-design：网页设计规范之后每个项目都可以直接调用。实际案例：flipbook 调研结束后，我说"根目录放了 tada-artifact-design 这个 skill，用它做网页"，"我有一个 deploy cloudflare 的 skill 你找找"——我的 skill 库就是我的工具箱。
| 我的指令 | 本质 |
|---|---|
| "先不着急做网页，我先看看文档给你一些反馈" | 拉回来，先确认质量 |
| "先不用这么细，我们继续讨论清楚实验逻辑" | 阻止盲目执行 |
| "我是产品经理，不是让你写技术方案" | 纠正产出格式 |
| "怎么在装 anthropic sdk 了？不用装，这里面 llm 就是你" | 阻止过度工程化 |
| "你今天特别一根筋呀" | 要求重新思考 |
| "这次完全认同了，特别好" | 确认方向正确，继续推进 |
我最常做的几件事：
这不是"人给 AI 下指令"的关系，更像两个产品经理在讨论方案，只是其中一个能力超强且能立即执行。
作为产品经理，Claude Code 对我来说不是代码工具，而是一个可以持久化管理 context、封装能力为 skill、随时回溯决策历史的 AI 协作系统。写代码只是它恰好能做的事之一。