AI的概念已经存在很久，在LLM之前我也做过一段时间基于YOLO-v7的行为分析产品，PM更多是解决标准化产品的需求，如数据标注平台的开发、服务器配置、模型参数的设置等功能层面。但和如今负责的agent产品完全不同工作职责。
所以LLM时代的PM应该怎么做？LLM出来后，其实做PM的逻辑发生了根本性的变化，因为这是一种全新对信息的处理方式，不是简单从PC到mobile，或APP中增加了一种新的交互方式，而是完全可以绕过软硬件先天缺陷导致增加的大量冗余交互、流程和学习成本，可以简单粗暴只关注input和output，其他交给LLM的底层微调和工程方面的优化。
那对PM来说，最核心的能力是什么呢？我觉得主要是这三方面
- 在APP中找到合适的scenario，增加页面的逻辑复杂度来并行交互，避免用户wait或failure case；
- 数据库、知识库、上下文、长期记忆配合，让agent进行调用，将迭代的方法论融入到agent中，避免从0开始regenerate；
- Event-Driven架构+后端驱动UI+前端渲染的方式，提供更灵活的架构，避免在复杂架构下的逻辑冗余。
除此之外，团队协作的模式也发生了根本性的变化。原本是PM负责和stakeholder确认需求，或根据用户场景和产品定位挖掘市场；在此基础上形成prototype和feature desc；如果有涉及到其他内容，则由PM统一进行对接和沟通。现在增加了一条并行的线，由AI工程师同步进行agent开发，或者由PM兼任该角色，通过vibe coding或n8n这类agent搭建平台开展。PM也承担了一部分的生产角色。
当LLM的发展速度变缓，openAI都只能在应用层面搞突破，那我们就很难再迷信LLM有突破性发展。今天在X中看到dify CEO的观点：后AI时代，公司发展的瓶颈在于组织内部信息流动，比如复杂需求的精准设计、混乱协作、隐性知识或PMO建设，这些需要构建一条内部低噪的information bus，team内部使用同一个上下文。对于这个观点我是深表认同的，在负责的产品开始，我们进行技术选型，咨询Tech team的几位资深架构师，都说架构都差不多，关键是做好工程师的规范，这样做一些开发和调整的时候，避免纯AI堆屎山问题。
AI时代的产品最大挑战其实是复杂度发生了指数型的陡然增加，最耗费精力的不是想功能，而是「控制复杂性」与「维持信息一致性」。
在业务层面，还是关注产品的定位和用户价值，绘制用户旅程图和需求分析。
在具体的功能设计中，可以通过各类AI工具快速制作prototype，不用再耗费太多时间在样式上。当然，选择合适的工具，提供准确的prompt，以及持续输出要求迭代，还是存在很多问题。
在模型层面，如何定义prompt、各类数据源结构、规范API，是一个新的领域，我目前是通过n8n建立workflow，利用langfuse进行版本管理，配合slackbot可以进行一些demo验证。在spread中记录bad case，持续迭代，2周进行一次prompt review。
在开发新的app时，最难的就是做好AI Feature Specification。之前做fine-turning就比如为是一种炼丹，现在更是这种感觉，模糊的需求或难度稍微有点高的，就下意识想交给agent去做，但是字段、交互，如果PM没有站在更高视角进行全面梳理，那会造成大家盲人摸象，效率更低。所以需要PM发挥刨根问题的精神，不断明确每一个agent的input、output、module config、prompt、constraint、benchmark、status和version。对底层技术层面，也需要和技术负责人深入沟通，起码以architect map的形式能够直观展示出来，能做客观的WBS。