昨天在群里跟AI的朋友们唠嗑，我们会发现其实在公司里有很多提效场景，它可能并不是那么高频刚需，但做了又确实能够有很不错的提效。
比如说我有一个数据我要解析分析并且做成可视化的格式，这个事情每个月只需要1-2次，用研发资源做吧也不是很合适，ROI不一定划算，业务没准哪天需求就变了。
不做吧，它又确实是一个很典型的效率场景，真的是做了立马能够看到提效的；包括很多C端和B端的demo，其实现做出来一个验证再去让研发投精力研发才是最划算的。
这块在AI编程工具成熟之前其实没有什么特别好的解法，但当AI工具出来之后我觉得它会逐渐成为产品经理的必须技能，通过Cursor你可以快速的把业务的需求搭建出来，低频需求直接封装好给业务用，验证的demo直接上线内部测试效果。
之前的产品经理流程是这样的，产品汇总需求——prd——研发开发——上线测试，我觉得未来像我提到的简单业务提效需求有可能变成：产品汇总需求——AI prd——AI编程——交付业务使用；
demo验证的则变成：产品汇总需求——AI prd ——AI编程——demo验证——AIprd ——研发开发——上线测试。
这样做的好处是整个公司整体的效率都会往上跑一大截，研发资源的损耗会降低很多。
那不用AI编程cursor，用dify和coze能不能达到同样的效果？
如果你的业务是内容生产类型、总结类型、知识库检索相关的业务且不需要任何批量化的事情，用dify和coze是可以尝试实现的。
但这个边界其实特别的窄，且一旦匹配上批量化的事情就玩不转了，用dify做一条内容产出效率还行，但同时做100条就非常麻烦了。
dify和coze的优点是上手简单，同时coze还可以接入飞书知识库，但对于定制化的需求场景其实还是偏弱的，更多其实是通用的内容生产总结场景。
cursor的优点是啥都能做，缺点就是上手成本比较高，但产出的天花板更高一点。
大家可以根据自己的具体业务需求来选择，哪个好用用哪个~
比如说我有一个数据我要解析分析并且做成可视化的格式，这个事情每个月只需要1-2次，用研发资源做吧也不是很合适，ROI不一定划算，业务没准哪天需求就变了。
不做吧，它又确实是一个很典型的效率场景，真的是做了立马能够看到提效的；包括很多C端和B端的demo，其实现做出来一个验证再去让研发投精力研发才是最划算的。
这块在AI编程工具成熟之前其实没有什么特别好的解法，但当AI工具出来之后我觉得它会逐渐成为产品经理的必须技能，通过Cursor你可以快速的把业务的需求搭建出来，低频需求直接封装好给业务用，验证的demo直接上线内部测试效果。
之前的产品经理流程是这样的，产品汇总需求——prd——研发开发——上线测试，我觉得未来像我提到的简单业务提效需求有可能变成：产品汇总需求——AI prd——AI编程——交付业务使用；
demo验证的则变成：产品汇总需求——AI prd ——AI编程——demo验证——AIprd ——研发开发——上线测试。
这样做的好处是整个公司整体的效率都会往上跑一大截，研发资源的损耗会降低很多。
那不用AI编程cursor，用dify和coze能不能达到同样的效果？
如果你的业务是内容生产类型、总结类型、知识库检索相关的业务且不需要任何批量化的事情，用dify和coze是可以尝试实现的。
但这个边界其实特别的窄，且一旦匹配上批量化的事情就玩不转了，用dify做一条内容产出效率还行，但同时做100条就非常麻烦了。
dify和coze的优点是上手简单，同时coze还可以接入飞书知识库，但对于定制化的需求场景其实还是偏弱的，更多其实是通用的内容生产总结场景。
cursor的优点是啥都能做，缺点就是上手成本比较高，但产出的天花板更高一点。
大家可以根据自己的具体业务需求来选择，哪个好用用哪个~