#Product

这些技术真正强大的地方，不是自己拥有多少功能，而是它们提供了一层稳定基础，让更多人可以继续建设。

因为一个项目改变软件世界，通常不是因为它自己完成了一切，而是因为越来越多的人开始在它之上创造新的东西。

当一个技术成为别人建设的基础，它就不再只是一个项目。它开始变成基础设施。

可行性分析通常看两个层面：

产品角度：这个功能有没有价值？和 App 的定位是不是匹配？ 技术角度：技术上能不能做到？成本是不是可控？

瓶颈转移到了代码两侧：左边是设计和确认，右边是测试、验证和部署。 这些环节仍然在以人类速度运行，它们才是现在需要优化的地方。

通用 Agent 会吃掉垂直 Agent，Codex、Claude Cowork、WorkBuddy 这些通用型选手，配合 Skill 和 MCP，就能搞定大部分专业任务。很多 AI-native 应用创业，本身就是个伪命题。

不只是通用 Agent 会吃掉垂直 Agent，通用 Agent 这个赛道本身，也会是少数赢家通吃。

我们转向了通用 Agent，这条路如何能够不被大厂吃掉？

将你的经验、你学到的知识以及你目前认为真实的东西暂时放在一边，重新审视问题。

我仍然想利用这些经验。但很容易在没有真正理解面前的问题之前，就让过去的项目或熟悉的技术限制决定答案。

当我退一步，去问我们实际上在做什么、为什么这很重要、各个部分是如何连接的，我通常会找到比预期更多的前进方式。

一个 2C 软件应该是面向普通老百姓设计的而非精英。如果你和很多人接触过你就会发现，大部分人是没有主动提出问题的能力的，即便要提出，也没有掌握正确的提问方式。

现在的 Agent 希望自己的能力是泛化的，所以一切功能都来自于用户的自然语言输入，而一个人的真实世界行为其实主动发起聊天是极少的场景，大部分我们的数字生活都是被动的。被动被推荐新闻短视频，被动刷 Ins 流，被动决定晚饭吃什么，正是这些被动才使得我们的生活变得轻松，主动的人生是值得追求的但是非常累。

Agent 应该是一种技术实现方法，而不是软件交互方式。

Agent 的技术原理其实很简单，就是「用户输入」-「模型推理」-「工具调用」-「模型推理」- … -「输出结果」。技术上并没有限定输入输出必须是以聊天的方式进行的。

我认为的务实的交互方式是，利用现存软件已经积累的数据资产和 UI ，在背后让软件的实现方式变成 Agent 化。

搜索并不是一种平衡的社交产品形态。它天然站在发起者的角度解决“我想找谁”，却没有解决更重要的问题：“对方为什么要选择我？”

AI 降低了验证成本，但没有降低商业难度。

有人使用、有人留存、有人付费，并不等于一个产品可以持续经营。生产层面的成功，也不会自动转化为商业上的成功。

在一个固定的校园流量池里，第一轮曝光就已经把大部分潜在用户找出来了。那些本来就喜欢认识新朋友、正在找对象、愿意上传照片，也没有太强社交羞耻的人，第一次看到产品时就会注册。他们不会等到第五次宣传，或者换了一套活动文案后才突然产生需求。第一两轮推广往往是效果最好的时候。它不是增长飞轮开始启动，而是高意向人群被一次性转化了。

我们并不是因为产品没人用而停止，也不是因为某次推广效果不好而放弃。恰恰是在留存、付费和短期增长都曾经给出正向反馈之后，我们才逐渐看清：这些数据证明了产品可以被使用，却没有证明它能够成为一门值得持续投入的生意。

能够用相对可控的成本换来这些认知，本身就是AI时代给创业者带来的巨大机会。

对于那些有好奇心、有想法，也愿意执行的人来说，这可能是一个前所未有的时代。创业的资金和技术门槛正在下降，个人能够做的事情越来越多，竞争也会逐渐从“谁能组建更大的开发团队”，转向“谁对问题理解得更深，验证得更快”。

过去，创业者往往需要先凑齐一支团队，才能开始验证想法。现在更合理的顺序可能是：先由一个能力相对全面的人把业务跑起来，确认方向成立之后，再组建真正需要的团队。

我从事产品开发已有10年，开发过一些失败的产品，它们要么过于复杂，要么缺乏鲜明的特色。我在犯过这些错误后，总结出三个限制条件。

1. 能不能把产品介绍写成一页纸的概要？

可以降低复杂性和歧义性

如果一个项目的介绍需要超过一页纸才能写完，那就说明它太复杂了。

2. 核心技术能不能与产品分离？

可以让你聚焦在真正具有影响力和原创性的想法上

开发一项支撑产品而非产品本身的核心技术。核心技术可以是方法、技能、工具，甚至是产品本身，它支持你当前的工作，但即使没有产品本身也能继续运行。它是一种可重用的知识产权，是你长期的投入，它独立于产品的方向。

产品会不断调整方向，而核心技术则始终如一，并持续发展。

将核心技术与产品分离，能迫使你跳出产品本身的局限去思考。

3. 产品有没有一个核心特色？

限制功能随意扩展，并强制保持产品功能的一致性

这意味着用户会时刻看到它并与之互动。这个特色清晰明了，赋予你的产品独特的个性。

你选择的这个特色可以让你缩小决策空间，专注于真正重要的问题。如果你的产品没有特色，或者选择了错误的特色，你就会打造出一个臃肿的产品，试图面面俱到。

感觉应该拿豆包办公和 workbuddy 比较，而不是飞书，不过最主要的想说的是产品在生态上受到的约束，IM 作为 Agent 入口只是临时的，这会受到很大限制

Agent 必须大于办公套件，而不是小于办公套件

飞书的问题，是套件太成功了。它希望用户直接说出真正的目标，剩下的工具由它决定——必要时用飞书，必要时用 Office，必要时打开网页，必要时进入企业自建系统。飞书的完整开始变成一层约束。

入口上，Agent 越能独立完成任务，用户越不需要逐个打开飞书里的文档、会议和工作台。指标上，用户少点了十次页面，却更快完成工作，这究竟算飞书活跃下降，还是 AI 效率提高？商业模式上，企业将来买的是飞书席位，还是 Agent 的任务额度、Token 和数字员工？生态上，一个通用 Agent 理应平等连接钉钉、企业微信、Office 和 WPS，飞书却没有理由花大力气培养一个帮助用户离开飞书的入口。

既要形成套件化（自己的多个产品间的连接，不能过于独立），也要有对外（内）可连接的方式，成为别人的基础设置

WorkBuddy 这类产品有一个很准确的定义：它帮助 C 端用户完成 B 端工作。

从简单开始

一个有效的系统总是由一个较小的、有效的系统构建而成

理解是关键

完美是不可能实现的

我们都曾被要求做一些看似简单的改动，但当我们说这需要几周时间而不是别人预期的几个小时时，却不得不承受各种反应。大多数情况下，这是因为代码里藏着一些我们无法理解的复杂陷阱，而我们又害怕去修改。唯一的选择要么是完整的重构，要么是把他当做黑盒绕过他。

Coding Agent 很容易让我们一开始就无法理解整个代码库

如果你连一个想法是否可行都不知道，就去构建一个十年愿景，这是不合理的。你必须清楚自己正在做出哪些权衡。

做一些新的事情

先前的经验实际上会限制认知，导致专家即使知道某些模式并非最优，也会默认使用熟悉的模式。

先攻克难关

开发新产品时，你根本无法预知它需要多长时间才能完成，也无法预知它的效果如何。

无论是在工程层面，还是在产品和业务层面，都秉持着“先做概念验证（POC）再做最小可行产品（MVP）”的理念。

如果我们决定采用某种方法，就必须确保它行之有效。这并非意味着它一定是最佳方案，但至少我们知道它有效。

能排除掉的不可预测因素越多，剩下的事情就越可预测

关注影响力

人们需要更加以客户为中心。优秀的创业软件工程师不会把自己的工作仅仅局限于编写代码。他们不只是解决软件问题，而是深入挖掘，理解客户和业务的痛点。他们运用对软件和技术的理解，找到其他人想不到的解决方案。作为软件工程师，我们通常是团队中最强的系统思考者和批判性思考者，也是最了解技术功能的人。优秀的人懂得如何将这些技能成功运用到编码之外的领域，这在创业公司中至关重要。因为在创业公司里，仅仅解决遇到的第一个问题是远远不够的。解决表面问题不足以克服所有阻碍变革的障碍。要想取得突破，你必须不断挖掘人们的痛点、目标、希望和梦想。

看不见的东西，往往也就不需要

人其实很容易把“看见”误认为“需要”。

而“顺便看看”其实是一个非常危险的消费入口。

看不见，就想不起来；想不起来，就不会觉得缺。

我们以为自己每天都在“自由选择”要不要买东西，但实际上，很多欲望是被环境主动提醒出来的。