惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
博客园 - 司徒正美
C
Check Point Blog
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
IT之家
IT之家
B
Blog
博客园_首页
量子位
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
J
Java Code Geeks
H
Help Net Security
A
About on SuperTechFans
Apple Machine Learning Research
Apple Machine Learning Research
Jina AI
Jina AI
D
DataBreaches.Net
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
云风的 BLOG
云风的 BLOG
Google DeepMind News
Google DeepMind News

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
我为什么放弃了利用大模型进行多项目的矩阵式开发 – 人人都是...
markzou · 2026-05-27 · via 人人都是产品经理

当AI将产研成本压缩至十分之一,创业者的试错门槛看似降低,实则暗藏陷阱。本文作者通过多个MVP项目的实战复盘,揭露二手信息与行业认知鸿沟如何让看似完美的AI方案沦为空中楼阁,并分享从技术狂欢转向市场深耕的血泪教训。

今年2月份的时候写过一篇文章用AI重构工作的实践

这篇文章写了啥呢,但是我在尝试将一个项目的整个环节全部用AI,大模型来串联。

比如寻找ideal,用了一个扣子智能体,整体逻辑是:

1、如果你没有创意想法,那么你可以指定国家,和行业,让智能体帮你搜索,整理这个行业网络上的用户有什么抱怨的问题。

2、然后你可以选择其中的一些问题作为你的创意来源,如果你已经有创意,那么就不用做第1步。

3、你选定创意之后,让智能体按照pest,行业,产品,竞对公司,优劣势分析并给出分析结论

4、如果以上内容没有问题,就让智能体进一步输出商业方案,并转化为产品方案和技术方案。

5、产品和技术方案进行vibe coding(coding的部分,转其它AI编程工具)

6、然后再让智能体输出营销方案。

这个逻辑从理论上看,感觉是没有什么问题的,也确实能够运转。

而且从我的实践中,利用AI编程工具,我不懂编程的人,也能在几个小时内手搓出一个可用的MVP版本。

这给了我极大的信心。

我在比较早之前就会偶尔记录一下我感兴趣的一些项目,差不多有30来个,

这个时候我就想,产研已经很便宜了,效率百倍的提升,那么就可以快速的去尝试这些项目。

因此,我和技术合伙人沟通,我们一致认为,可以采取矩阵的做法,把之前的很多想法快速的落地来做,然后看有哪个项目能够跑出来。

我们确实进行了尝试,比如我自己在百度秒哒上就搭建了10来个MVP项目进行尝试。

更重的自主开发项目,有三个,一个是针对B端各种俱乐部做活动的管理软件,一个是针对C端的AI旅游规划产品,一个是针对B端的电商、生产厂家的合规产品。

但最终结果不是很理想。

原因之前在其它的文章最近几个月的AI大模型独立应用实践-1有详细的讲解。

简单总结就是,做对的事情,比把事情做对更重要。

如果一个事情不对,那么把这个事情做的再好,价值也不大。

有了AI和大模型之后,在软件项目上的产研成本确实是变得很低了,是之前的十分之一,甚至百分之一。

这会给大家一个错觉,就是太便宜了,太便宜之后,就不会很珍惜,对于项目的可行性,筛选标准等就会不自觉的下降。

心理的想法可能就是“反正研发这么便宜,做出来试试也没多大的损失”,那就可能变成,不断去上新项目,不断地去上新功能,将时间和资源在不经意间消耗了。

不是说这个方式完全不对。

但就我个人而言,我确实在这几个项目的是否做的把关上,由于自己的心理和技术合伙人想要不断干活的激情中,对于项目的把关没有这么严了。

这其实是很要命的一个事情。

因为项目本身的市场拓展等各方面的难度其实没有降低。

个人的精力很有限,特别是在没有大量团队配合的情况下(我们的团队总共就2-3人,产品就我一个人,市场等方面也是我来处理),基本不可能同时运行多个项目。

因为每个项目都深度参与,并行工作,那么很可能就会陷入精力争夺竞赛中,最终让自己精疲力尽。

我们再说回前面我提到的我做了一个发现ideal然后完善ideal的智能体,它所收集的信息很多都是二手或者多手的信息。这些信息如果你不进行深度的确认,其实你是无法保证这些信息的真实性的。

另外每个行业有很多本身不太为外人所知的隐形知识,如果你没有在相关行业有深度认知,这些信息是无法知道的,如果你没有直接接触用户,你也不清楚的。

你做出来的方案,在逻辑上完全没有问题,但因为缺少对和行业的真知灼见,缺少与直接客户的长期接触,那么这个方案就很可能是一个外行对行业的想象,是一个似是而非的东西。

因为方案要从逻辑上显得没问题,是非常容易的,但是要贴合实际,反应实际却不是那么容易的一件事情,这是需要下苦功夫的,是需要直面一线用户的,也是要耗费很多精力的。

真实有时候会以一个你完全想象不到的情况呈现在你眼前。

所以,我现在的精力放在技术上的更好,放在业务上,放在用户,放在市场上的更多一些。

把精力放在直接产生高价值信息的地方,减少二手多手信息对现实的判断的影响,将更少的精力放在方案的完善上,更落地,更土气。

真实比看起来逻辑闭环更好!!!

本文由人人都是产品经理作者【markzou】,微信公众号:【markzou的笔记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。