入门AI PM——实践篇：PM的技术「手感」，从一行代码不写开始

在分享了《我在学什么》和《如何评测》之后，我意识到，纸上得来终觉浅。真正的理解，源于创造。尤其是在 AI 这个日新月异的领域，如果我们只停留在阅读和思考，那我们和 AI 的距离，其实从未真正拉近。

其实，这也源于一种普遍的焦虑——AI 产品经理要不要懂技术？当然要懂。而且这种技术理解力不只是针对于深度学习、LLM 技术等等相关理论知识，还包括将产品思维快速落地的技术实践能力，成为能真正理解 AI 能力边界、并与技术共舞的产品掌舵者。

现在 Vibe Coding，让这一切成为了可能。为了验证这个想法，我用几周的时间，几乎没有手动写下一行传统代码，独立搭建了一个 LLM 对话应用——「PRD For AI」。

这篇文章，就是我从 0 到 1 的全过程复盘。虽然没有高深的理论，但都是我自己踩过的坑和总结的经验。希望你读完之后，能少走一些弯路，也能鼓起勇气，开始打造属于你的第一个 AI 应用。

我的第一个 AI 应用——PRD For AI

一、我的初心：为什么要做它？

每个人都有灵光一闪的想法，但从想法到产品之间，隔着一条名为「技术实现」的鸿沟。过去，这道鸿沟让无数非技术背景的 PM 望而却步。

但现在，情况变了。

「PRD For AI」的诞生，就是为了证明：借助 AI，我们可以将脑海中的想法快速转化为一个可用的产品雏形。它的核心使命很简单：帮助你，将模糊的需求结构化、清晰化，生成一份高质量的产品需求文档（PRD），让你的想法能被 AI 更精准地理解和实现。

文字描述可能有些抽象。它现在已经有了 Chrome 插件和网页两个版本，你可以通过下面的图片先睹为快。

插件版（右侧侧边栏是 PRD For AI 的插件，左面是 Lovable 页面，点击一键复制即可将内容给 Lovable 输入框，生成复杂页面）：

网页版（登录注册页面、存储历史对话、编辑等更复杂功能）：

二、Vibe Coding：我的无代码炼金术

整个搭建过程，我将其总结为三步，就像创造一个机器人：先搭建「大脑」，再创造「身体」，最后连接「神经」。

Step 1：搭建「大脑」——用 Dify 构建 Agent 核心逻辑

我总结了几个关键点。

1. 模型选择：永远先用「最强王者」

在开发和测试阶段，不要考虑成本。直接选用市面上最先进、能力最强的模型（比如 GPT-5、Claude 4.1 Opus 等）。这能让你快速摸到产品效果的天花板，知道在理想情况下它能做到多好。性能的上限，决定了你产品的想象空间。

2. 逆向拆解：站在「竞品」的肩膀上

如果你做的领域比较新，找不到完全一样的竞品，就找相关的。然后，和你的 AI 助手一起「逆向拆解」它。问它：「这个应用可能的工作流是怎样的？如果让你来实现，你会分成几步？」AI 会给你一个非常好的起点，让你摆脱无从下手的迷茫，快速建立你对自己产品的体感。

可千万不能小瞧了逆向拆解竞品，非常重要。

3. 工作流拆解：让每个节点更「专注」

要避免将一大堆复杂的 Prompt 塞给同一个模型节点。这会让模型「精神分裂」，效果大打折扣。正确的做法是，将一个复杂的任务拆解成多个更细、更专注的子任务，分配给不同的模型节点，形成一个工作流。每个节点只负责一件事，这样最终输出的质量才会更高。（当然这样会很消耗 token，在后续产品迭代过程中需要进一步优化。）

4. Prompt 炼金：Few-shot 是金

• 案例最有效：在 Prompt 中提供几个高质量的示例（Few-shot），比写几百字的描述性指令效果好得多。
• 自然语言即可：不用追求过于结构化的 Prompt，就像和人说话一样，把业务逻辑、目标和要求讲清楚。
• 让 AI 帮你写：你甚至可以把你的需求告诉 Gemini，让它帮你生成初步的 Prompt。

我相信上面这几点建议，一定会为你节省很多时间，少走许多弯路。因为 AI 应用的「智能」并非凭空而来，是源于我们对其思考路径的精心设计，不是随意想想，搭个流程就能实现的。

一个前沿思路：最近在训练营中学到了一个全新的 RAG 方式——Agentic RAG。简单来说，就是将知识库检索工具（如 RAGFlow）封装成 MCP，让 Dify 中的 Agent 节点根据需要自主决定是否调用以及如何调用。这可能会成为未来更主流、更高效的知识检索方式。

Step 2：创造「身体」——与 AI「结对编程」

有了「大脑」，还需要一个能与用户交互的「身体」：也就是我们常说的前端和后端。这曾是让无数 PM 望而却步的天堑，但现在，AI Native 的代码编辑器彻底改变了游戏规则。我的流程是这样的。

1. 云端 AI 生成雏形

先在 Bolt.new 或 Lovable 这样的平台上，用自然语言描述你想要的前端页面（此处可以用 PRD For AI 协助），甚至可以直接上传设计图。AI 会快速生成一个基本的前端框架。这时可能很多按钮点不通，没关系，我们只需要它的样式、布局和基础功能。

2. 本地 AI 二次开发

将生成的代码下载到本地，然后使用 Cursor 这类 AI 代码编辑器打开。Cursor 就像一个拥有顶尖智慧的「全栈工程师」（前端、数据库、后端），坐在你旁边。你只需要用聊天的方式告诉它：

「帮我创建一个后端服务，用 Python 和 Flask 框架。」

「我需要一个简单的数据库来存储用户对话，用 SQLite 就行。」

「这个『生成 PRD』的按钮点击后没有反应，请帮我修复它。」

当然，Cursor 不可能每次都能完美解决你的问题，端口冲突、依赖缺失、跨域请求等等，都是很可能会遇到的问题。这就需要我们能够耐下心来，多与 Cursor 沟通请教，逐渐就会明白前后端是如何通信的、数据库如何搭建的、一个 Web 应用是如何跑起来的。

踩坑 tips：「端口」问题

是什么：前端和后端是两个独立运行的服务，它们通过各自的「门牌号」（端口号）进行通信。比如，后端通常运行在 5000 或 8001 端口，前端开发环境可能在 3000 或 8080 端口。

为什么会出问题：有时端口会被其他程序占用，Cursor 会自动换一个端口（比如 8081 变成 8082）。但它可能只修改了前端的配置，却忘了告诉后端「我的门牌号换了」，导致前端无法访问后端的数据。

怎么办：当应用跑不起来时，检查一下终端的提示信息，看看是不是端口被占用了，并确保前端代码中请求后端的地址和端口是正确的。

另外，有一个好习惯：经常让 Cursor 帮你更新 README.md 文档，记录下项目如何启动、有哪些主要功能和依赖。一个清晰的文档，是你未来迭代和求助的好帮手。

所谓 PM 的技术手感，就是在一次次试错中慢慢熏出来的。

想要成为一个领域的专家，不需要有多聪明，但要肯花时间，要把自己沉浸在这个领域内。

Step 3：连接「神经」——API 接口的调用与联调

现在，「大脑」和「身体」都有了，最后一步就是用「神经系统」（API）将它们连接起来。

API 就像一个信使：

1. 把用户在前端界面上输入的需求，传递给在 Dify 云端运行的「大脑」。
2. 再把「大脑」的思考结果带回来，显示在前端界面上。

实现这一步，同样是通过与 Cursor 对话完成：先在 Dify 后台，找到你应用的 API 文档（API 的调用规范），还有 API 地址、密钥。然后将整个 API 文档粘贴给 Cursor，下达类似指令：「请根据这份文档，帮我实现前端与这个 Dify 应用的通信。当用户点击『生成』按钮时，调用这个 API，并把返回的结果以流式的方式显示在对话框里。」

当然，它不可能一次性完美实现：

• 多轮对话的上下文如何传递？
• 如何实现「中止回答」功能？
• 返回的 Markdown 格式如何正确渲染？

这些都需要你在页面上反复测试，然后清晰地描述问题，与 Cursor 一起迭代解决。

三、从 0 到 1 的收获：我获得了怎样的「技术手感」？

这次实践，带给我的远不止一个可供展示的小应用，而是一种内化于心的技术「手感」，是作为一名 AI PM 的自信和洞察力：

• 是在面对一个产品构想时，我能大致判断出实现它的技术路径和关键节点。
• 是在和工程师沟通时，我能更准确地描述需求，理解他们的技术挑战，而不仅仅是抛出一个模糊的功能。
• 是在遇到 Bug 时，我不再手足无措，而是能冷静地分析问题可能出在哪个环节（是前端显示问题？是 API 调用失败？还是后端逻辑错误？）。

当然，不用写代码，并不意味着这是一件简单的事。开发过程中涌现的 Bug 需要极大的耐心。我们需要代入开发者的状态，不能焦躁。虽然我们省去了思考代码逻辑的脑力，但我们必须学习优秀开发者面对 Bug 时的心态：耐心分析，清晰描述，与你的 AI 伙伴一起，一步步解决它。

结尾：邀请你，一起动手

AI 时代，PM 的技术「手感」不再是少数技术出身 PM 的专利，AI PM 的能力也正在回归 PM 的本质：深刻地定义问题，并高效地组织资源（包括 AI）去解决它。

我的「PRD For AI」还只是一个非常初级的玩具，甚至可能充满 Bug，但它承载了我对 AI 时代 PM 新工作流的思考和探索。

如果你对我的搭建过程有任何疑问，或者也想开启你的第一个 AI 小项目，欢迎交流。

让我们一起，从「一行代码不写」开始，真正走进 AI 的世界。

最后，对于完全不懂代码的产品小白想要使用 Cursor 上手开发 AI 应用，不会写代码没有关系，但一定要学会用 git 进行代码版本管理。