How We Claude Code三阶段拆解cwc-workshops的AI产品工作流访谈→设计→可验证应用【免费下载链接】cwc-workshops项目地址: https://gitcode.com/GitHub_Trending/cw/cwc-workshopscwc-workshops 仓库中的How We Claude Code工作坊完整演示了一套 AI 辅助产品工作流用一段提示词访谈敲定产品规格Spec生成 4 个差异化设计方案再落地为组件皆可运行时验证的 React 应用。三个阶段层层递进是理解 Claude Code 如何从一个模糊想法走到可验证应用的完整样本 一、How We Claude Code 是什么为什么值得学how-we-claude-code/README.md 给出了官方定位这是一个从开放式想法 → 书面规格 → 设计探索 → 可运行且可运行时验证的 React 应用的三阶段工作坊。它的特殊之处在于交付形态阶段目录交付物阶段一 探索phase-1-exploration/一段访谈式提示词产出产品规格阶段二 规划phase-2-planning/一段提示词产出 4 套静态 HTML 设计方案阶段三 验证phase-3-verify/完整构建好的 Vite React 可验证应用前两个阶段只给提示词、不给成品——你需要自己跑一遍来复现规格和设计稿阶段三则是可直接运行的完整工程。这种提示词 成品对照的结构让新手能直接看到输入长什么样、输出长什么样。# 克隆仓库只读学习即可 git clone https://gitcode.com/GitHub_Trending/cw/cwc-workshops二、阶段一如何用一次访谈式对话产出产品规格阶段一的全部家当只有一句话提示词PROMPT.MD我想做一个账单分摊应用先帮我头脑风暴目标用户是谁然后用 AskUserQuestion 工具深度访谈我重点是挖出所有歧义并沉淀成一份规格。这句话藏着三个 AI 产品工作流的关键技巧先定人群再定功能——brainstorm with me on who the audience is 把目标用户前置避免 AI 自由发挥。让 AI 反问你——指定AskUserQuestion工具把需求澄清的主动权交给 AI 提问而不是人挤牙膏。以消除歧义为验收标准——规格不是文档而是把每一个模糊点问清楚。按提示词执行后产物是一个免注册、基于链接的账单分摊应用no-account, link-based bill-splitting app的产品规格作为阶段二的输入。三、阶段二4 个发散设计方案横向对比后再收敛阶段二的提示词同样短小PROMPT.MD读取阶段一的规格文件帮我确定应用的整体设计。探索 4 个不同的设计方向并为每个方向创建一套包含关键页面的 HTML 文件。这一步的方法论价值在于让 AI 一次产出多个发散方案divergent explorations以静态 HTML 形式落地方便并排比较。相比让 AI 给一个设计然后反复改四套方案横向对比能更快暴露取舍点信息层级、配色、交互密度再做收敛决策。阶段二刻意不产出代码这正是产品流程中设计先行的体现在动手写组件之前先把视觉方向锁定。四、阶段三核心让每个组件都能被 AI 运行时验证阶段三是整套工作流最精华的部分——一个 Todo 应用架构围绕一个理念构建见 phase-3-verify/README.md应用的每个部分都应该能被 AI Agent 在运行时平凡地验证——不是靠人读代码也不是靠离线测试套件而是真实运行、驱动它、读取它实际渲染出的东西。4.1 DOM 即机器可读的契约每个组件渲染时都会输出data-verify-*属性把自身状态直接写在表面。例如 TodoApp.tsxsection>cd how-we-claude-code/phase-3-verify bun install bun run dev # 应用起在 5199 端口验证仪表盘在 /verify bun run verify # 无头跑完整验证矩阵vitest jsdomREADME 还给了一个亲手破坏的练习把TodoApp.tsx里的data-verify-total删掉再运行就能看到dom-contract和counts-add-up两项检查在仪表盘和 CI 里同时给出精确失败诊断——验证框架抓的是谎言而不仅是确认真相。六、新手能带走的 4 个工作流启示规格先于设计设计先于代码——三阶段各自有独立产物AI 每一步的输出都是下一步的输入。把歧义当一等公民——阶段一的核心任务不是产出功能列表而是消除歧义。发散再收敛——一次让 AI 产出 4 套方案做对比比单方案迭代更省沟通成本。可验证性是架构属性——data-verify-*契约 统一判定路径让验证从附加测试变成产品架构的一部分人、Agent、CI 三方共享同一个真相源。这套访谈 → 设计 → 可验证应用的三段式正是 Claude Code 在实际产品工作中的典型用法也是 cwc-workshops 其余工作坊多 Agent 拆分、评测驱动开发等见根目录 README.md的共同方法论基调。【免费下载链接】cwc-workshops项目地址: https://gitcode.com/GitHub_Trending/cw/cwc-workshops创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/18 2:25:13 · 阅读 1.2k How We Claude Code三阶段拆解：cwc-workshops的AI产品工作流（访谈→设计→可验证应用）
How We Claude Code三阶段拆解cwc-workshops的AI产品工作流访谈→设计→可验证应用【免费下载链接】cwc-workshops项目地址: https://gitcode.com/GitHub_Trending/cw/cwc-workshopscwc-workshops 仓库中的How We Claude Code工作坊完整演示了一套 AI 辅助产品工作流用一段提示词访谈敲定产品规格Spec生成 4 个差异化设计方案再落地为组件皆可运行时验证的 React 应用。三个阶段层层递进是理解 Claude Code 如何从一个模糊想法走到可验证应用的完整样本 一、How We Claude Code 是什么为什么值得学how-we-claude-code/README.md 给出了官方定位这是一个从开放式想法 → 书面规格 → 设计探索 → 可运行且可运行时验证的 React 应用的三阶段工作坊。它的特殊之处在于交付形态阶段目录交付物阶段一 探索phase-1-exploration/一段访谈式提示词产出产品规格阶段二 规划phase-2-planning/一段提示词产出 4 套静态 HTML 设计方案阶段三 验证phase-3-verify/完整构建好的 Vite React 可验证应用前两个阶段只给提示词、不给成品——你需要自己跑一遍来复现规格和设计稿阶段三则是可直接运行的完整工程。这种提示词 成品对照的结构让新手能直接看到输入长什么样、输出长什么样。# 克隆仓库只读学习即可 git clone https://gitcode.com/GitHub_Trending/cw/cwc-workshops二、阶段一如何用一次访谈式对话产出产品规格阶段一的全部家当只有一句话提示词PROMPT.MD我想做一个账单分摊应用先帮我头脑风暴目标用户是谁然后用 AskUserQuestion 工具深度访谈我重点是挖出所有歧义并沉淀成一份规格。这句话藏着三个 AI 产品工作流的关键技巧先定人群再定功能——brainstorm with me on who the audience is 把目标用户前置避免 AI 自由发挥。让 AI 反问你——指定AskUserQuestion工具把需求澄清的主动权交给 AI 提问而不是人挤牙膏。以消除歧义为验收标准——规格不是文档而是把每一个模糊点问清楚。按提示词执行后产物是一个免注册、基于链接的账单分摊应用no-account, link-based bill-splitting app的产品规格作为阶段二的输入。三、阶段二4 个发散设计方案横向对比后再收敛阶段二的提示词同样短小PROMPT.MD读取阶段一的规格文件帮我确定应用的整体设计。探索 4 个不同的设计方向并为每个方向创建一套包含关键页面的 HTML 文件。这一步的方法论价值在于让 AI 一次产出多个发散方案divergent explorations以静态 HTML 形式落地方便并排比较。相比让 AI 给一个设计然后反复改四套方案横向对比能更快暴露取舍点信息层级、配色、交互密度再做收敛决策。阶段二刻意不产出代码这正是产品流程中设计先行的体现在动手写组件之前先把视觉方向锁定。四、阶段三核心让每个组件都能被 AI 运行时验证阶段三是整套工作流最精华的部分——一个 Todo 应用架构围绕一个理念构建见 phase-3-verify/README.md应用的每个部分都应该能被 AI Agent 在运行时平凡地验证——不是靠人读代码也不是靠离线测试套件而是真实运行、驱动它、读取它实际渲染出的东西。4.1 DOM 即机器可读的契约每个组件渲染时都会输出data-verify-*属性把自身状态直接写在表面。例如 TodoApp.tsxsection>cd how-we-claude-code/phase-3-verify bun install bun run dev # 应用起在 5199 端口验证仪表盘在 /verify bun run verify # 无头跑完整验证矩阵vitest jsdomREADME 还给了一个亲手破坏的练习把TodoApp.tsx里的data-verify-total删掉再运行就能看到dom-contract和counts-add-up两项检查在仪表盘和 CI 里同时给出精确失败诊断——验证框架抓的是谎言而不仅是确认真相。六、新手能带走的 4 个工作流启示规格先于设计设计先于代码——三阶段各自有独立产物AI 每一步的输出都是下一步的输入。把歧义当一等公民——阶段一的核心任务不是产出功能列表而是消除歧义。发散再收敛——一次让 AI 产出 4 套方案做对比比单方案迭代更省沟通成本。可验证性是架构属性——data-verify-*契约 统一判定路径让验证从附加测试变成产品架构的一部分人、Agent、CI 三方共享同一个真相源。这套访谈 → 设计 → 可验证应用的三段式正是 Claude Code 在实际产品工作中的典型用法也是 cwc-workshops 其余工作坊多 Agent 拆分、评测驱动开发等见根目录 README.md的共同方法论基调。【免费下载链接】cwc-workshops项目地址: https://gitcode.com/GitHub_Trending/cw/cwc-workshops创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考