夜雨聆风全文约 2112 字，阅读约需 10 分钟。
写于 2026.05.29 。
引子
最近几个月，我将 AI 融入日常产品工作。
随着使用频率越来越高，我对产品经理的工作模式和工作边界有了新的体会。
在此与大家分享。
先看 AI 出现前，产品经理熟悉的一种工作方式：有了一个业务想法，做需求分析，写 PRD，画原型图，交给设计师，交给开发，等排期，开发完验收，发现问题再调整，调整完再等……
一个想法从脑海到可演示，周期很长。
将 AI 纳入工作流后，我尝试了一种新的方式。
新的方式：有了想法，直接用自然语言描述给 AI，AI 自行分析，我来评审和修改。
通过 AI 配合产出初版需求稿后，就可以直接让 AI 拆任务、写代码，短时间内就能看到一个应用的效果。
有问题直接提，AI 及时修改。
从想法到可演示，时间大大缩短。
接下来分享两部分内容：第一，我的工作流具体是怎么运转的；第二，与 AI 协作后的一些感受。
一、工作流：四步完成产品分析设计到软件交付
我把现在的工作方式总结成一个四步闭环的工作流。
第一步：描述想法。
需求分析仍然是 AI 辅助开发中最重要的环节之一。
与之前不同的是，有了需求或想法后，先不写产品结构图、PRD，不画线框图。
我直接用自然语言将「当前的想法」描述给 AI，要求它进行分析。
然后根据分析结果与自己的判断，展开多轮对话。
最后将对话内容结构化，保存为本地文档（一般使用 .md 格式，便于 AI 阅读），形成规约文件。
一方面便于后续开发指导，另一方面也能帮助自己更好地理解需求。
比如：「我想开发一个麻将教学 APP。
核心功能包括：一、教程学习——通过可视化交互引导玩家掌握麻将规则，支持多个地区的玩法；二、技巧教学——帮助用户从初阶到高阶，掌握胡牌技巧；三、实战练习——支持玩家与电脑对战，巩固学习成果。」
将这个粗略想法告诉 AI 后，要求它进行深度需求分析，必要时向我提问以获取更多信息。
几轮对话后，就能产出质量不错的上下文。
此时可以让 AI 对内容进行逻辑梳理和总结，保存到本地文档。
Tips：
我目前主要使用的 Coding Agent 是 Claude Code。
它内置了规划分析功能（通过 subagent 形式实现），可以输入命令 /plan + 你的产品想法，快速启动分析。
第二步：AI 分析加拆任务。
这一步，AI 会自行读取之前保存的规约文件，理解需求，然后将需求拆解为可执行的多个任务——比如数据库建表、API 路由、前端组件——分别进行开发。
如果涉及方案选择或有问题需要确认，它会直接询问你。
比如技术栈选型，或者功能有哪些使用场景，告诉 AI 即可。
Tips：
特别提一下，有一些技术问题对非研发背景的产品经理有一些难度，不清楚也没有关系。
但是如果了解一些，会对后续产品开发有很大帮助，我了解的两点内容如下：
• 技术框架选择：经过调研，我选择 Next.js 作为开发框架。一方面，对于大部分 Web 项目，它是 AI 模型开发的默认选择；另一方面，作为全栈框架，它不仅支持前端开发，还能完成中轻度的后端业务开发，一体化的开发体验很适合一个人完成。 • 真实数据与轻量数据库：相比 Mock 数据，使用真实数据交互会让开发的产品效果更好。我默认使用轻量级的 SQLite 作为数据库，本地仅通过单个 .db 文件进行数据存储，无需额外部署数据库服务。数据库 Schema 设计及基础数据操作，全部借助 AI 辅助完成。
第三步：AI 编码。
这是实际编码的一步，通常耗时较长。
AI 的工作包括：编写数据库迁移文件、API 接口、前端组件，完成后自动运行 lint 检查并修复语法错误。
我会要求 AI 基于之前拆分的任务建立任务列表、跟踪进度。
同样以 .md 文档存储，分为「总任务进度.md」和「各子任务进度.md」，每完成一部分都会更新文档，便于我查看进度。
Tips：
• 版本管理与方案迭代：产品设计阶段通常伴随着频繁的需求调整与设计迭代，很多想法只有在真实交互中才有感觉。因此我会通过 Git 进行版本管理，保留不同阶段的方案与实现路径，方便随时回退、对比与重新验证，以降低产品试错成本。 • 用好 CLAUDE.md/AGENTS.md 文件：这是 Claude Code/Codex 等 Agent 的记忆文件，每次执行任务前会将文档内容注入上下文。但内容不是越多越好，而是越精炼越好——不要想到什么就写什么，否则会浪费和污染上下文。应当写入对话中频繁用到的要求。举例：我原来需要手动让 AI 提交 Git，写入 .md 后，AI 就能自动提交；再比如要求 AI 每次完成功能开发后自动运行 lint 检查。
第四步：验收反馈。
代码跑起来后，我就可以在浏览器里看效果。
这时候我的角色就是「挑剔的用户」——「这个按钮位置不对」「麻将的花色看不清，对比度不够」「出牌的交互不流畅」。
发现问题就直接提给 AI。每次反馈后，AI 修改效率都很高。
被别人提问题不太开心，但给 AI 挑毛病后能得到即时反馈，非常爽。
这个环节感受很深：以前这种微调需要产品、设计、开发多方协调，现在通过即时对话就能完成。
Tips：
• Worktree 多方案并行：在产品探索阶段，经常会同时存在多个实现思路，但在实际运行效果出来之前，很难判断最终方案优劣。因此会使用 Git Worktree 同时创建多个独立工作区，并行验证不同方案，最终基于真实体验进行对比选择，而不是仅停留在讨论层面。 • 将工作中重复性的内容、可能多次复用的场景固化为 Skill。例如，将统一的设计风格固化为 Skill，未来新增功能或页面时，可以遵循该 Skill 进行开发。
二、感受：变与不变
新的工作模式实践下来，有三个感受比较深。
变了的三件事：
第一，原型就是真实软件。以前原型图里的数据是假的，交互是模拟的。现在原型就是跑在浏览器里的真实代码——真实数据库、真实 API、真实交互。从原型到最终产品的差距大大缩小了。
第二，迭代速度加快。反馈后不需要「等设计和研发排期」，自己改、自己看。这带来的改变不只是速度快，而是很多想法可以低成本地尝试。
第三，我能参与研发工作的边界变了。以前我控制到原型图为止，后面的实现细节我控制不了。现在我一直控制到可演示的完整产品。
没变的三件事：
第一，产品判断力。AI 不会替你做决策——什么功能该做、什么不该做、优先级怎么排，这些还得人定。
第二，用户理解。AI 不知道你的用户真正需要什么。需求洞察、场景分析、痛点判断——这些是产品经理掌握的信息，AI 并不了解，它只是一个基于人类知识进行概率计算的机器。
第三，审美与品味。AI 可以基于已有知识进行开发，但「好」的设计——颜色对不对、交互舒不舒服、信息层级合不合理——需要人来判断。
以上内容不仅写给产品经理，也适用于研发、设计师、测试，乃至每一个想要创造自己软件应用的人。
愿大家在 AI 时代，享受构建的乐趣。
