前言

在我的日常工作中，会用到各种 AI 工具。在使用这些工具的过程中我有一个痛点，以日常工作为例，每次切换不同的 AI 工具，或者在同一个工具新开对话的时候，如果提问的是与我们的产品相关的问题，比如帮我思考一下某个功能如何实现，交互怎么设计，为了得到更好的回答，我每次需要在提示词中反复的去携带上我们产品的一些基本背景信息，例如产品是做什么的，目前有哪些功能，这些功能是如何使用的。

于是我就在想，有没有什么方式把我们产品的所有功能用一种比较优雅的方式长期维护起来，这样每次跟 AI 对话我直接把整个上下文贴进去就好了。

这里大家可能会说，作为产品经理，肯定会有很多存量的 PRD 文档吧，是不是把 PRD 整理一下作为知识库给 AI 进行参考就好了？但是这里有个问题，每一个 PRD 文档中涉及的是很多产品设计的细节，并不是所有内容都适合直接喂给 AI。上下文太多太杂反而效果不好。

我认为最好的方式就是单独维护一个产品功能树，把各个大小功能以嵌套的方式维护在一起，每次新增功能的时候就在树的某个节点修改一下就好了。于是我就开始构思维护的方式。

最开始我想的一个方式是维护一个 Markdown，里面按照嵌套 - 无序列表标签的形式去整理，类似于：

- 不同的 Agent 模式

  - 通用模式

    > 最常用的模式，通过用户需求自行调用对应的工具

  - PPT 模式

    > 基于用户的描述，生成对应的 PPT。

    > 基于用户的主题去进行联网搜索相关的文章，确认大纲后会联网搜索相关的配图，最终通过 HTML 的格式将配图和文本进行排版组合，最终形成一个完整 PPT

  - 数据分析模式

    > 用户支持上传 Excel 数据报表，直接粘贴数据，或者通过 MCP 连接外部数据源，会基于数据及用户需求帮用户将数据整理为一份可视化的报表

  - 录音总结模式

    > 有一个开始录音按钮，点击后电脑会开始录音，用于记录会议内容。在完成记录后会将用户记录的会议信息进行总结，除了直接录音也支持上传会议记录，音频文件等进行总结

- ：表示标题

> ：表示这个产品功能的具体描述

这种维护方式是蛮简单的，只需要一个 markdown 文档就好了，但是当产品功能比较多，嵌套比较深的时候，维护起来就很麻烦了，就像一个很复杂的 yaml 文件一样，于是我想着能不能做一个可视化的工具来把这个产品树维护起来呢？

实现

说干就干，正好最近在体验 CodeX ，正好试试看这个编程工具实力如何，用了几个小时 Vibe Coding 时间我开发了一个小工具。

下图就是我实现的一个产品树维护的工具，我为他命名为 panova 

从图片中我们可以看到，其实就是将 Markdown 维护产品树的方式改为一个可视化的嵌套面板，同时集成了基础的增删查改和拖拽排序：

每一个功能项包含三个基础字段，功能标题、描述和开发状态，开发状态用于表示我们哪些功能还没有开发，哪些功能正在开发中，可以起到一点点的项目管理的作用，作为我们产品经理自己维护的一个数据。点击状态标签就会有一个下拉列表用于切换：

为了防止当个功能模块嵌套太深，我还为每一个子项提供了一个所处路径的展示，放在功能标题的顶部：

细心的你可能有发现功能树右上角还有几个小按钮，那么他们有什么用呢？第一个加号按钮就是在最外层增加一个分类，第二个按钮就是展开/折叠所有的嵌套子项，后面三个按钮就比较有创意了，我详细给大家说说。

像文档一样的图标，是这次实现这个功能的核心，因为在前文我们也已经说过了，我们这工具最主要的目的还是维护一个产品特性数，用来给 AI 大语言模型提供上下文的。所以我们这个特性树不能只是一个可视化的面板，必须有一个可以复制的文档，点击之后，会在右侧弹出一个抽屉，里面展示的就是我们这个特性树转换为 Markdown 格式的文档。 
 

样式是这样的，点击右上角的按钮可以直接复制，非常方便。

那个像一个列表树的按钮是一个模式切换按钮，这是在我实际使用过程中发现的一个痛点，就是当我们的产品功能嵌套的太深的时候，即使提供了一个功能所处路径，看起来还是不太直观，毕竟套了那么多层容器。

所以我增加了一个扁平查看模式，点击后样式会变成这样：

这样看效果是不是特别直观？把描述隐藏起来，展示为一个带有虚线的目录树形式，便于我们快速通览所有功能。

最后一个小按钮也有一些小巧思，作为一个 AI 产品经理，咱们做的小工具多少得让 AI 派上用场，最后一个按钮在点击后，会弹出一个右侧抽屉，里面是一个 AI 对话框。 在我们跟 AI 对话的时候，默认就会把我们的功能树作为上下文插入在里面。 

由于我在 Openrouter 接入了 Deepseek V3.2 EXP 版本，我可以以低到忽略不计的成本进行一些针对我们的特性树的功能查询，还通过格式化 JSON 响应的方式实现了一些可以调用的工具。可以直接让 AI 对我们的产品树进行编辑。比方说，我们的产品新增了一个功能，我可以用自然语言的方式，例如直接复制 PRD 文档里的一段话，让它自己判断应该插入在哪个位置。

之所以没有采用 MCP 或者 tool calling ，是因为场景比较简单，我就直接一个 Prompt 解决这个事情了。

特性树的价值

再说说维护一个自己的产品特性树对于产品经理来说有什么价值呢：

对内沟通： 这个功能树除了可以喂给 AI，还是一个很好的“产品速览手册”。当有新的技术、运营或测试同事加入项目时，可以直接把这个功能树发给他，让他快速了解产品的全貌，比直接丢给他一堆几十页的 PRD 文档要高效得多。

需求评审： 在进行需求评审时，可以将对应的功能节点展开，辅助讲解新功能在整个产品体系中所处的位置和关系。

竞品分析： 可以用这个工具来拆解竞品的功能结构，形成一个清晰的竞品功能树，一目了然。

不知道你在工作中是否也遇到过类似的‘上下文’难题？你又是如何解决的呢？” 或者 “你觉得 Panova 还可以在哪些方面做得更好？后续我还有很多想法会加到这个小工具身上，慢慢地，我会把它构建成一个产品经理专属的全链路产品工具。
 

有很多真正优秀的产品往往都是在解决自己的痛点时候诞生的，有的时候脑子空空，绞尽脑汁想找点事情做，但是就是没有好的想法，这时候大家不用焦虑，只要找到一个自己相对感兴趣的事情去做，你有可能会在这个过程中慢慢地发现另外一个你觉得很痛的点，或者说挖掘自己在日常生活或者日常工作中觉得繁琐的地方，自己去做一个产品，就算是没有人用，就算是自己用，这个产品也是有价值的。

最后照例在本文贴一下本文在 Text-Well 中的评审结果：