SophiaPro 成立于 2025 年 6 月，最早的产品为 Karis.im ，致力于为出海企业提供市场营销数字员工。而后转向 C 端产品方向，推出 浏览器插件 TryClico 和桌面端产品 Invoko.ai。

“特朗普，金色假发，嘟着嘴，在MacBook屏幕顶部的灵动岛里，左右跳动。”这是一个 Invoko 用户最新的小需求。

Invoko 是一款桌面端 AI 助手。它的 IP 是一朵蓝色的云☁️，长在 Mac 灵动岛的位置，你按下去它会回应你。不管你正在写邮件，还是需要Slack里同事刚发的数据，或者要参考飞书文档里的方案，都无需在三个窗口之间来回切，只需要和这朵云说一句话就行。

以下是 SophiaPro 创始人程梦琪在锦秋小饭桌 X Google 的活动上的分享：

我们创业大概一周年。这一年我们从垂直 Agent 转型到了 C 端产品，中间几乎把 AI 应用创业能踩的坑全踩了一遍。很多坑是当时觉得逻辑上绝对正确，后来发现全是错的。

我把这些选择一个一个摊开来讲。不是因为我找到了正确答案，而是这些选择题，可能每一个做 AI 应用的人现在都在面对。

第一个选择：General Agent 还是 Vertical Agent？

去年 5 月，我们开始创业。当时最火的是 Manus，市面上已经出现了十几个“我也是 general Agent”的产品，人均发一个 launch video。

我们做了第一个决策：不做 general Agent，做 vertical Agent。逻辑很通顺，赛道太挤了，而且所有人都说 Manus 迟早被基模吃掉。我们找更聚焦的问题、更聚焦的场景，去交付比通用 Agent 更好的局部结果。

这是我后来复盘认为最大的一个错误决策。

不是说垂直 Agent 这个方向本身一定不成立，也许某些垂类比如合规之类是可以的。但我们做了六个月之后发现，大部分垂类 Agent 公司都面临一个结构性困局：你的客户其实不用你的产品，但你又想挣钱，最后就变成你出人去服务他。垂直 Agent 公司在过渡阶段都被迫变成了 agency。

我在旧金山聊了大概一百家做类似事情的公司，大家的困境都一样。

更极端的案例是：有些公司的 Agent 产品就是给投资人看的，交作业用。真正挣钱靠服务。内部做服务的人自己都不用那个产品。

如果时光倒流，真的回到去年 5 月，也许就应该做个 general Agent。起码你能积累一大批用户的 query，知道 C 端用户的行为。也比你做了六个月 ToB 发现此路不通要好。

第二个选择：选哪个垂直场景？

既然决定做 vertical，就得选一个方向。我们画了三个圆，自己的经验、市场大小、Agent 擅长的事，选了营销。我以前在 TikTok 做过海外市场，这是背景上的原因。

但我们当时还讲了一个更"性感"的故事：coding 有明确的 reward 信号，数学也有，那下一个有点反馈信号的领域是什么？是 marketing，因为你发的内容天然有曝光和互动率，你能拿到信号来训模型。

这故事我当时讲了一百遍。现在听到别人讲类似的，我都想笑。创业公司做个毛线的训练。你确实有这样的数据，你也确实能训。但你训出来的东西，基模厂商随便改一改，比你带来的收益大多了。

我后来反复想为什么当时每一步都觉得自己对。答案就两个字：虚荣。我不是在基于市场需求做决策，是在基于"我得装一下"做决策。刚拿到融资都是创始人的愚昧之巅，觉得自己太聪明了，太能造概念了，太能融会贯通了。

所以我这里下一个暴论：大部分纯应用的创业公司不要招算法。你用不上。快放人家去训模型吧，你让人家在你这干什么？纯属给投资人看阵容。

第三个选择：在营销里选哪个切入点？

我们先选了达人营销，帮品牌找 KOC 做推广。当时想的是，你找明白了达人，就能找明白候选人、专家、客户。Sourcing 是一个能泛化的能力。

做了两三个月发现，sourcing 这件事百分之七八十取决于你 API 和数据质量。我们花了一万多美金买了很贵的达人数据库，但本质上你就是在用别人洗过的数据、做了一个跟人家差不多的界面。

更要命的是，sourcing 只占用户整个工作的大概 30%。你选了价值链上最简单的部分来做，后面来回聊、谈价格、跟进交付，这些最浪费人力的环节你都 skip 掉了。

当 sourcing 这个点的价值不够 strong 的时候，我们面临了一个选择：是横着打，把 sourcing 能力泛化到找候选人、找客户？还是纵着打，在达人营销这一个场景里做深？

我们做对了这个决策，选了纵着打。逻辑很简单，我当时想了一个比喻：我现在掌握了面粉和鸡蛋，我要开个店，你说我卖大饼加鸡蛋和意大利面，都是面粉鸡蛋做的，很 make sense。但你见过谁同时来你店里说"给我一份大饼加鸡蛋，再给我一份意大利面"吗？

横着打 sourcing，找达人、找候选人、找客户，这几个场景之间几乎不可能交叉销售。什么人会同时有这些需求？只有 founder。但 founder 自己是不会用产品的。

第四个选择：Agent 还是 Workflow？

这是去年 6 月几乎所有 Agent 创业者都要做的技术决策。

我们公司当时的算法合伙人是从 OpenManus 出来的，他说做 Agent，Agent 最领先。我非常坚定地选了 Agent。

做到后面非常痛苦。Agent 不稳定，同一个问题问两次给你不同的答案。你没法跟客户保证结果的一致性。

今天让我重新选，哪怕现在所有人都知道 Agent 更先进，我选 workflow。

因为这是一个 ToB 产品。ToB 客户要的不是最领先的技术，是"你稳定给我答案，我第二次问你同样的问题，你不要给我不一样的结果"。考虑成本、速度、质量、交付稳定性、客户不要跑出来骂你，workflow 都更合适。

当时为什么没选？就是技术虚荣心。我是 AI 创业者，我怎么能选 workflow 呢？

这个世界很参差。对大部分企业来说，能把 workflow 用上就已经解决大部分问题了。

第五个选择：听专业用户还是听非专业用户？

产品上线之后，两类人给我们提需求。

创始人说：你别跟我讲中间要点什么、按什么，我什么也不想按，你给我结果就行。

公司里专门负责达人的人说：不行，中间需要可审计，这一步需要我确认了才能继续，这些指标我要自己定义。

两类人的需求完全不一样。当时市面上很火的概念是"蒸馏专家经验"，把高认知能力浓缩成产品，再卖给非专业的人。我们觉得应该先服务专业用户，把他们的经验蒸馏出来。

这又是一个错误。

你一旦选定服务专业用户，你就是在给他做工具。你问一个专业剪辑师他需要什么样的 Agent，他会一直给你提需求，直到你长得跟 Adobe 差不多他才收手。专业用户对过程的把控非常严谨，所以这条路必然走向 SaaS。

有一天我对比了一下我们的产品和这个行业里八年前创业的 SaaS 公司的界面，长得几乎一模一样。那一刻我觉得完蛋了，你创了半天业，把人家 SaaS 走过的路又走了一遍。

第六个选择：ToB 做不动了，要不要硬撑？

做到 12 月的时候，信号已经非常清晰了。

我们在帮 Manus 做增长，如果 Manus 用不明白我们的产品，中国没有任何公司能用明白，因为 Manus 是我见过的最 AI native 的组织。他们都用不懂，那一定不是他们智商不够，一定是我的产品和商业模式错配。

同时我发现，我们公司 40 个人，团队的性格更适合做 C 端。我发现这件事的契机是：我们有个同学在服务大客户的时候，在群里跟客户抬杠。客户说 CPM 太高了，他说不高啊。客户说你能不能找低一点的，他说这已经很低了。永远在抬杠。

我以前做 ToB 的时候，只会说"卑职收到了，卑职遵旨"。被包养就不要谈独立人格。但我们的同学做不到这个，他们性格上就不是干 ToB 的人。那段时间就我一个人在舔客户。

2 月份我跑去旧金山，把那边做垂直 Agent 的公司聊了一遍。大概一百家公司，困境都很相似。而且我发现大部分创业公司连基本的 ToB 组织都建不起来，我问他们你知道 CSM 是什么吗，一半人不知道。很多技术背景创业者对 ToB 的理解就是"我身边有两个朋友我劝他用一下"，互相买、互帮互助刷到 100万 美金 ARR。但到了 100 万之后，集体性的迷茫。

这是一个结构性问题：你的产品模式是 Agent，但你的商业模式是 ToB。ToB 在中国是贬义词，在美国华人做的天花板也非常明显。而且 ToB 吃不到新模型带来的能力跃迁和红利，你能吃到的最大红利是内部 coding Agent 更强了、开发更快了，但你的产品解决客户问题的效率有没有 10 倍增长？没有。

我那时候做了一个判断：如果做 ToB，我不应该创业，也不应该融资。我以前做过几年 ToB，有客户资源有行业关系，不需要融资也能做。创业应该追求高赔率的事。

第七个选择：转 C 端，做什么产品？

在 ToB 还没有正式停掉之前，我已经让一部分同学开始试水 C 端。因为团队的士气和信心是不可再生之物，你没办法突然有一天说"全部推翻，从头来"。

大概 1 月份的时候，有个小组做出了一个浏览器插件叫 Clico。功能极其简单，你浏览器开了一堆 tab，它让你 chat with tabs，把各个 tab 里的信息 retrieve出来。你在写文档的时候可以直接说"把那个网页里关于 use case 的信息放到我这个文档下面"。

我当时内心觉得这不值得做。太薄了，做产品一上来三连问：核心竞争力是什么？跟竞品区别是什么？解决的核心问题是什么？这个产品只能回答第三个问题，前两个完全回答不了。我能说出 100 个一模一样的竞品，Grammarly 早就在做类似的事了，7 亿用户。

但我没说出来。怕浇灭大家的小火苗。

结果这个产品增长很不错，有很多自发传播。有些学校的学生用了就不停向同学推荐，某些学校里几百个我们的用户。

我自己也开始用它，然后我理解了为什么它有价值。以前你想让 AI 帮你写一段话，你要截图、发给ChatGPT、写 prompt、等返回、复制回来。Clico 就一个按钮，你按下去就行，不用写任何 prompt，按钮本身就代表了你的意图。

只要你能缩短用户意图和解决方案之间的距离，你就有价值。

2026 年了，翻译还是问题吗？当然不是，这事根本不难。但到今天好多用户跟我们说，没有一个好的本地翻译划词产品。彩云小译为什么还活着？就是够方便、在你手边。

这个认知对我的冲击很大。以前我做产品脑子里全是差异化、核心竞争力、技术壁垒这些概念。但 C 端用户要的东西很朴素：好用、快、在我手边。

第八个选择：要不要做客户端？

Clico 有个天然的局限，它是浏览器插件，只能在浏览器里运行。你想跨飞书、跨 Slack、跨 Gmail 做事，做不了。

所以我们顺理成章地决定做桌面客户端产品 Invoko。一个长在你电脑灵动岛位置的 notch 产品，因为是全局的，天然适合做 context switching，你不需要在不同 app 之间来回划屏幕找信息了。

这个决策我不后悔，但我要提醒所有人：小团队不要轻易做客户端。

这东西太难做了。你要适配不同的 Mac 版本、不同的芯片型号。Reddit 上天天有人跟我们说"什么时候出 Intel 版？我们用不了，天天看你在那吹"。你要不要去适配 2021 年那一年卖的 Intel 芯片 Mac？你还没做 Windows 呢，你的增长流量出去了，发现一半是 Windows 用户，白做了。

到昨天晚上我们上了第 49 个版本，大概一两天一个版本，做了快三个月。

我有一个理论：软件不是你在本机能运行就完了。本机能跑跟上 production 是两回事，上了 production 跟能挣钱又是两回事。三级阶梯，一级比一级高。而且软件更像一块草坪，修剪费用比当初买草皮还贵。

但正是因为它难，我反而不焦虑了。三月份的时候我焦虑到快裂开了，觉得谁干软件谁神经病，你任何一个 idea，Cursor 能做、Claude Code 能做，投资人第一句话就是"我一个 skill 就能干你"。我甚至后悔去年为什么不讲个具身的故事，讲一个三四年不可证伪的方向。

但做了这个客户端之后我发现，它就是由 15000 个细节组成的。你一个一个把屎吃掉，多吃一个用户体验好一点。一个人说"我一周就能做出来"的东西，你做了 49 个版本还在修。这个事没有捷径，所以我反而踏实了。

第九个选择：怎么验证需求？

做 C 端之后最大的变化是我们认真做用研了。

我们最大程度用好了 Reddit。不只是去上面挖数据，那只能给你静态结论。我们做的是：每一个产品决策都拆成一个决策漏斗，每一层对应要发的帖子。这个需求是不是真需求？用户愿不愿意付费？现在的解决方案是什么？现在的方案哪里不好？每个问题发 40 到 50 个帖子出去，回收反馈。

我们甚至在美国线下 BD 了一批真人 Reddit 用户，不是供应商养的号，是真正在 Reddit 活跃了三年的人。我们不做红蓝对抗，不跟 Reddit 安全团队 PK。就是找真人帮我们验证场景。

一泡在 Reddit 上你就不焦虑了。因为你会发现 AI 这么牛了，大量的问题还是没有被解决。Context switching 这事，每天都有人在吐槽说脑子要分裂了。

另一个很大的变化是：学会了克制。

我是 ENFP，非常发散，恨不得一天给产品提 800 个方向。之前做 ToB 那个产品就是这样，客户说做达人营销，做完说你能不能顺便做搜索类信息？然后 GEO 火了，客户说也做了吧。一路跟着需求走，做成了菜市场。

中国人特别喜欢菜市场式做产品。你看淘宝再看任何一个海外电商；看携程再看 Booking。中国人觉得我这么多菜必须全摆出来，不然你就走了。海外用户接受结构化信息，先看第一层，再决定要不要进第二层。

Invoko 如果你下载了，会发现功能非常少。不是没做，大概只上了我们做了的百分之二三十。在之前那个产品上我们得到了教训：不要菜市场。

第十个选择：怎么找到好的商业模式？

有意思的是，我们不做那个 ToB 产品之后，ToB 业务反而挣钱了。

因为我们要给 C 端产品做增长嘛，增长同学被迫继续用之前的 Agent 工具。用着用着，把一些经验提炼成了 skill。这个 skill 比之前那个正儿八经的 ToB 产品好用得多。

为什么？因为以前我们是拿着客户的离散需求在做，客户今天说两句，明天没空理你，一周后再说三句，context 是断裂的。但现在我们自己就是用户，自己的需求最完整、最直接、每天都在用。

这个 skill 每天增加七八个细节，比如给达人发的邮件前9个字是雕琢过的，因为达人打开邮件前只能看到前 9 个字。你每天加 10 个细节，加 3 个月，就没有人能 compete 你。

以前我们恨不得大跃进，这个版本月底上、那个版本什么时候出。但你从来没有真正有时间、有一个持续有需求的人给你完整的 context，让你把一个 skill 打磨好。

这个 skill 做出来之后，分享给了一些兄弟公司，大家都说好用、能不能卖给我。一个客户的需求过来，我们同学直接转发给Agent跑，跑完把结果发给客户，基本没有人力损耗。客户原来找 agency 起码两到三倍的报价，用我们便宜一半。

我终于找到了做 ToB 产品的正确路径：不是大跃进式 rush 一个版本交作业，而是你自己先有需求、自己用到好，然后外溢给别人。这是一个过程产品。

几个可能有用的判断

讲完了踩坑，说几个我现在的想法，不一定对。

关于 OPC（一人公司）。 OPC 是趋势，但不是现实。现实中 OPC 很少，挣到钱的 OPC 更少。他没挣到钱凭什么给你钱？做独立开发者的生意很艰难，因为独立开发者首先要自己吃饱，才能拿一点钱出来跟你一起搞。而且最有信息获取能力的那批人，大概率自己就能把 Claude Code 用得很好。

关于速度。 我特别讨厌 quick win。一个好的 skill 一定是调很久的，一个好的客户端产品一定是磨很久的。我特别抵触那种"我做了个很牛的东西"到处发朋友圈发小红书的心态。你真有人用、用了有效、上线了好使，比吹牛难 100 倍。所有落到生产级别的事，都比讲概念难 100 倍。

关于情绪价值。 效率工具关注的是你的问题。但我想做一款产品，不只是解决你的问题，不解决问题我就是一个只提供情绪价值但不靠谱的下属，没意义，同时我在乎你是谁、在乎你今天心情怎么样。DAU 不是一个四位数、八位数的数字，背后都是人。我们请了很多美国设计师来打磨情绪价值的部分，用户说"有些细节能感觉到你们很用心"。比如所有客户端产品都面临隐私问题，用户隐私协议全是字没人看，我们做了一个漫画来解释数据怎么存储。

关于公司组织。 我们现在没有产品经理。不是不需要这个角色，是在这个时代我还没想好产品经理应该干什么。研发流程是：用户报 bug，扔给 Agent，Agent 分配到研发同学本地的 coding Agent，自动修，人做测试验收。增长侧有各种skill在跑自动化。组织尽可能简单、沟通尽可能短，每个人都能connect 到 repo。

关于软件的出路。 AI coding 越来越强，软件供给一定变多。大家的"货"都差不多，都是同样几家的 API。API 直出两块钱，你想卖六块，怎么办？我看到三条可能的路：一是品牌化，有品牌溢价；二是精选买手，你选过的 skill 就是比别人靠谱，你做胖东来；三是陪伴和情感连接，你不只是生产力工具，用户跟你有情感上的 connection。