实战三：Claude搭建日常工作任务框架

​

从需求分析、文档撰写到系统原型生成，一套可复用的产品经理 AI 协作方案。​

​

第一步：让 AI 懂你——建立全局规则​

​

​

1.1 CLAUDE.md：你的 AI 人设卡​

​

💡

Claude Code 的工作方式是：在用户目录下有一个 CLAUDE.md 文件，每次对话启动时，它会自动读取这个文件，作为全局的行为准则。​

​

1.2 我的全局规则包含什么​

我把自己全局规则分成了几个关键模块：​

关于我：告诉 AI 我的角色、工作内容和目标。比如"xx公司xx类产品经理"，“把任何重复的事 AI 化或自动化”。​

思维原则：定义 AI 的思考方式。我写了两条核心原则：​

•

遵从第一性原理，不因"惯例如此"照搬​

•

不要谄媚，方案有问题直接指出来​

沟通方式：规定 AI 怎么跟我说话。比如"默认中文、结论先行、优先结构化格式"。​

红线边界：明确哪些操作必须停下来问我，比如删除文件、修改密钥配置、git push 等。​

需求分析流程：告诉 AI 在辅助需求分析时的完整工作规范。我把这块内容单独放在一个文件中（claude assist.md），全局规则里只写一行引用。这样做的好处是：需求分析的规则比较长且会频繁迭代，独立文件方便维护，不会让全局规则文件变得臃肿。​

1.3 关键经验​

规则越具体，AI 输出越贴合你的风格。​

比如我写了"不要说’这是个很好的问题’“之后，AI 再也没出现过这种客套话。我写了"结论先行，再给理由”，它的回复结构就真的变成了先说结论再说原因。​

​

✍️

这套规则不需要一次写完，可以在实际使用中不断补充。每次发现 AI 的输出不符合预期，就把期望的行为加到规则里——这就是一个持续优化的过程。​

​

​

​

​

第二步：搭建需求分析工作流​

2.1 整体流程​

我把需求分析拆成了 6 个明确的阶段，每个阶段有明确的输入、输出和责任划分：​

​

代码块​

Plain Text

理解 → 讨论 → 框架确认 → 大纲确认 → 输出 → 纠偏迭代​

​

这个流程的核心原则是：不要跳步。​

为什么要这么强调？因为 AI 的优势是快速生成内容，但如果你还没想清楚就让它开始写，产出的东西大概率要大改。不如每一步都确认清楚再往下走，最终反而更快。​

2.2 每个阶段做什么​

阶段一：理解​

我把项目相关的资料（会议纪要、业务文档、竞品截图等）统一放在一个文件夹里，告诉 AI 项目名称，它会自动去浏览这些资料。​

浏览完后，AI 会输出三样东西：​

•

系统菜单框架​

•

关键信息提炼​

•

待确认问题列表​

有时候我自己已经把菜单框架列好了，那 AI 就基于我的框架提炼关键信息，直接进入讨论。​

阶段二：讨论​

这是最核心的阶段。AI 的价值不只是回答问题，更在于主动质疑——它会指出需求中不合理的地方、补充遗漏的边界条件、追问异常流程怎么处理。​

这个阶段的产出不是文档，而是思考的完整性。通过和 AI 反复讨论，需求的细节会越来越清晰。​

阶段三：框架确认​

讨论充分后，AI 输出最终的菜单框架和系统整体结构，我来确认。如果前面我已经给过菜单框架，这一步可以跳过，直接进入下一步。​

阶段四：大纲确认​

在动笔写文档之前，先让 AI 给出需求文档的大纲——包括章节计划和每章大致要写的内容。​

这一步看似多余，实际上非常关键。因为大纲是"骨架"，在大纲层面做调整，成本远低于写完文档再改。​

阶段五：输出​

大纲确认后，AI 开始生成需求文档。系统原型则是在文档定稿后，我让 AI 生成时才生成。​

所有生成的文件统一放在项目文件夹下的"需求文档与原型"目录中。​

阶段六：纠偏迭代​

AI 生成的初版不会完美，我会指出问题，它修正，反复几轮。关键是：AI 会记住每次纠偏的原因，持续学习我的思维方式和写作风格，后续的偏差会越来越小。​

2.3 资料管理方式​

我把所有项目资料按这个结构组织：​

​

代码块​

Plain Text

​

这样做的好处是：​

•

AI 每次都能快速定位到正确的项目资料​

•

模板统一管理，保证所有项目的文档风格一致​

•

产出物和原始资料分离，结构清晰​

2.4 语音驱动的工作方式​

在整套工作流中，还有一个贯穿始终的底层习惯：我几乎不打字了。​

会议纪要全部由 AI 生成。我使用飞书妙记来完成，分两种场景：​

​

💙

•

与业务方开会时：打开飞书妙记实时录制，会后自动生成会议纪要，AI 提炼关键信息和待办事项​

​

与 Claude 的所有对话也通过语音输入完成。我使用微信自带的语音转文字功能，通过快捷键随时语音输入。无论是讨论需求、确认方案还是提出修改意见，都是说出来而不是打出来。​

​

👓

语音输入还带来了一个意外收获：表达能力的持续提升。因为要让语音识别准确理解你的意思，你会自然地减少语气词、提高表达的逻辑性和准确度。长期下来，不只是与 AI 协作更高效，日常沟通也会更清晰。​

​

​

第三步：需求文档协作​

以模板为准​

需求文档的格式、风格、内容排版必须和模板文件保持一致。我事先准备好了一份标准的 PRD 模板（Markdown 格式），AI 每次都基于这个模板来生成。​

这不是限制 AI 的发挥，而是确保输出的文档在团队内部有一致性——不管是哪个项目，看文档的人都不需要重新适应格式。​

​

讨论即写作​

传统写 PRD 的方式是：先想清楚，再打开文档，从头写到尾。​

但在 AI 辅助下，流程变成了：边讨论边写作。我在对话中做决策、补充细节、确认规则，AI 在后台记录我的思考逻辑和判断依据。讨论充分后，AI 基于这些记录直接生成完整文档。​

我的角色从"写作者"变成了"决策者"——我只管思考和判断，文字组织交给 AI。​

​

菜单框架 = 文档结构​

一个关键的规则：需求文档中功能模块章节的层级和标题，必须与确认的菜单框架完全一致。​

这样做的好处是：​

•

文档结构和系统结构一一对应，开发看文档时能直接定位到对应功能​

•

原型页面的组织也和文档章节对齐，三方（文档、原型、系统）保持统一​

•

后续维护时，改了菜单只需要同步改对应章节，不会遗漏​

​

第四步：系统原型一键生成​

单 HTML 文件方案​

B 端系统原型的生成方案是：单 HTML 文件，内联 CSS + JS，无任何外部依赖，浏览器直接打开即可使用。​

为什么不用 Axure 或 Figma？因为：​

•

B 端系统页面结构高度重复（列表页、详情页、表单），用工具一个个搭效率低​

•

AI 生成代码比手动拖拽组件快得多​

•

HTML 原型可以包含真实的交互逻辑（标签页切换、表单联动、状态切换），比静态原型体验更好​

•

一个文件就能发给任何人预览，不依赖特定软件​

6.2 生成规则​

不是所有菜单都需要生成页面。我定义了明确的规则：​

需要生成页面的：需求文档中有详细字段定义和业务规则的功能模块，生成完整页面（列表 + 详情）。​

只展示菜单的：用户管理、操作留痕等通用模块，只在侧边栏展示菜单，点击不跳转。这些是各系统都有的标配模块，不需要每次重复生成。​

原型的基本布局统一采用：侧边栏（可折叠菜单）+ 顶部栏 + 内容区，样式参考模板文件。​

6.3 样式模板复用​

我事先准备好了一个 HTML 原型的样式模板，定义了筛选区、表格、详情卡片、标签、按钮等组件的样式。​

AI 每次生成原型时，直接复用这套样式，保证所有项目的原型视觉风格一致。如果某个项目有特殊的 UI 风格要求，只需要提供对应的样式截图，AI 就能模仿生成。​

​

实战演示：从零到产出的完整过程​

以一个 CRM 客户关系管理系统的需求为例，展示完整的工作流。这个系统用于管理企业的客户信息、销售商机、合同订单和售后服务。​

第一步：理解——AI 输出菜单框架和关键问题​

我告诉 AI："帮我做一个 CRM 客户关系管理系统的需求分析。"AI 基于通用的 CRM 业务经验，直接输出了系统菜单框架草案、关键信息提炼和待确认问题列表。​

菜单框架包含客户管理、商机管理、销售管理、售后服务、数据中心等五大业务模块，以及基础信息维护、用户管理、操作留痕三个通用模块。​

同时，AI 提出了 9 个待确认问题，比如：客户分配机制是自动还是手动？权限范围怎么划分？商机阶段是自定义还是固定？合同是否需要审批？等等。​

第二步：讨论——快速决策​

针对 AI 提出的问题，我按通用方案逐一回复。比如客户采用公海机制、销售只看自己的数据、商机阶段固定、合同需要单级审批等。​

这个阶段非常快——因为 AI 提的问题都踩在关键决策点上，我只需要做选择题，不需要自己想"还有什么遗漏"。​

第三步：框架确认​

讨论完直接确认菜单框架，八大模块，层级清晰。​

第四步：大纲确认​

AI 给出了需求文档的完整大纲，包含需求概述、系统总览、功能模块（每个二级菜单对应一个三级章节）、非功能性需求、附录。我确认后 AI 开始动笔。​

第五步：输出——需求文档 + 系统原型​

AI 生成了完整的需求文档（Markdown 格式），涵盖所有功能模块的字段定义表格、筛选项、业务规则和状态枚举。​

随后 AI 基于需求文档生成了系统原型——一个单 HTML 文件，浏览器直接打开即可交互。原型包含 11 个页面：客户列表、客户详情、联系人管理、线索管理、商机列表、商机详情、报价管理、合同管理、订单管理、工单管理、回访记录、销售漏斗、业绩报表，每个页面都带有模拟数据。​

​

​

下图是 AI 生成的需求文档和系统原型的效果：​

需求文档截图​

​

​

​

原型截图​

第六步：纠偏迭代​

我审阅后提出了几个调整：侧边栏不需要折叠功能、部分字段描述需要补充。AI 修正后定稿。​

整体复盘​

整个过程中，我实际做的事情是：​

•

回答了 9 个业务决策问题（选择题）​

•

确认了菜单框架和文档大纲（确认题）​

•

审阅并指出 2 处需要调整的地方（纠偏）​

其余所有工作——信息整合、字段定义、业务规则梳理、文档排版、原型页面编码——全部由 AI 完成。从开始讨论到拿到需求文档和可交互原型，整个过程非常高效。​

​

踩过的坑和积累的经验​

规则要具体，不要模糊​

一开始我的规则写得很泛，比如"注意风格"。结果 AI 的理解和我完全不一样。后来改成具体的指令：“不要说’这是个很好的问题’”“结论先行，再给理由”，效果立刻好起来。​

​

AI 的文档风格需要纠偏训练​

第一次让 AI 写 PRD 时，它的风格偏向技术文档——太多技术术语，缺少业务视角的描述。我反复纠正了几次后，它学会了用"业务人员"“操作”“权限"这些产品经理的语境来写，而不是用"用户”“接口”"字段"这种开发视角。​

这个过程就像带新人——前几次需要多花点时间纠偏，后面越来越顺手。​

​

不要让 AI 自由发挥​

AI 的能力很强，如果你不给约束，它会自作主张加很多"自认为合理"的内容。这些内容往往和你的实际需求有偏差。​

所以我的工作流里有"大纲确认"这一步——在大纲层面就把 AI 的创作范围锁死，它只需要在大纲框架内填充内容，不要自己发明新的章节和结构。​

​

哪些环节必须人工把关​

•

需求优先级判断：AI 可以帮你列出所有功能，但哪些先做、哪些后做，必须你自己决定​

•

业务规则最终确认：AI 会根据资料推断规则，但涉及合规、风控等敏感领域，必须人工复核​

•

用户体验设计：AI 能生成可用的页面，但交互的细节打磨仍需要产品经理的判断​

​

总结​

回顾这套工作流，核心理念就一句话：AI 是你的思维放大器，不是替代品。​

它不能帮你做决策，但能帮你把决策快速转化为产出物。它不能帮你思考，但能在你思考的过程中提供质疑和补充。​

搭建这套工作流的成本并不高——一份全局规则文件、一份 PRD 模板、一个原型样式模板，加上几轮纠偏训练。但长期收益非常显著：​

•

需求文档的产出效率提升数倍​

•

原型从"需要专门花时间做"变成"确认后一键生成"​

•

你的思考方式和工作偏好被固化在规则中，AI 越用越懂你​

​

💪

​

开始的第一步很简单：安装并打开 Claude Code，写一份你自己的 CLAUDE.md，告诉它你是谁、你怎么工作、你希望它怎么配合你。​

然后，就开始你的第一个项目吧。​