YC (Yucheng)

统计数据

6
文章
0
粉丝
0
获赞
0
阅读
avatar
YC (Yucheng)
4小时前
学习一下 YouTube 增长
#YouTube #增长 #学习 #社交媒体 #视频
avatar
Google 推出「一键跳槽」功能，让用户把 ChatGPT/Claude 的聊天记录和个人信息直接迁移到 Gemini。 最妙的地方：记忆迁移的机制是让你把 prompt 粘到竞争对手那里，用对方的模型生成你的个人档案，再导入 Gemini。 Google 在用对手帮自己做用户迁移。
avatar
a16z 合伙人给出了一条五个字的公式，却让整个软件行业不得不重新选择站位。 "Grow 10 or earn 40. No middle lane." 营收增速提高 10 个百分点，或者运营利润率做到 40%。两个选项，选一个。 没有第三条路。 --- 这不是在预测未来，是在描述已经发生的事。 公开市场已经重新定价了。那些夹在中间的软件公司——增长还凑合、利润率也凑合、护城河也算有——正在集体被市场惩罚。你不用等分析师来告诉你，看一眼过去两年的软件股走势就清楚了。 "舒适中间地带"消失了。 问题是：大多数软件公司还不知道自己在中间地带。他们还在开 QBR，还在讨论 FY2027 路线图，还在给团队画下一轮增长的饼。但市场已经投票了，结果正在等他们去读。 --- 第一条路：AI 原生新产品 David 说的第一条路，不是"在现有产品上加 AI 功能"。 大多数软件公司现在做的恰好是这个——加个 Copilot 按钮，写几个 AI 摘要，推一个"AI 助手"。产品发布会上有 AI 字样，投资人 Deck 里有 AI 字样，但增长曲线没动。 David 的判断更激进：你需要一个真正移动增长曲线的 AI 原生新产品，而且要在 12-18 个月内看到效果。那个新产品不能是现有产品的 AI 包装，它必须是用 AI 能力重新想象用户价值之后的新物种。打个比方：Figma 加了 AI 还是 Figma，Cursor 是用 AI 重新想象了"写代码"这件事本身。前者是升级，后者是新品类。 操作层面，David 给了个具体建议：找内部 5 个能交付 100x 价值的人，不管级别高低，把他们单独拉出来，给独立资源，让他们从零开始重建。50% 的 R&D 预算投到这个新产品上，四人 pod，产品/设计/工程合并，没有中间层，没有委员会。 大公司的 AI 转型失败，不是因为没钱，是因为官僚结构会杀死任何真正意义上的重建。 --- 还有一个判断，我认为是整篇文章最锋利的地方：定价必须切换。从座位数（per seat），切换到 token/消费/自动化（usage-based）。 这不只是商业模式的调整，是一个关于"谁是客户"的哲学问题。David 给了个判断标准：代理（Agent）能不能自主消费你的产品？ 如果答案是"不行，还是需要人工操作"，那你的产品在 AI 时代可能不是基础设施，是阻碍。 当 AI Agent 代替人类完成工作时，它不会去点开你精心设计的 UI，也不会购买一个"用户席位"。它需要 API、需要自动化流、需要按实际消耗计费的机制。如果你的产品现在不支持被 Agent 消费，你的客户群正在被悄悄替换。 --- 第二条路：重建机器本身 如果第一条路走不通，那就走第二条路。 但 David 说的第二条路，不是裁员 10-20%。 裁员 10-20% 是很多 CFO 的第一反应，但它解决的是成本问题，不是结构问题。裁完之后，剩下的机器还是原来那台效率低下的机器，只是变小了一点。利润率可能短暂回升，但士气和能力一起损伤了。 真正的第二条路是重新设计机器本身。 砍管理层级。软件公司增长时积累了大量中间管理层，每一层都在消耗信息带宽、拖慢决策。AI 时代，一个有能力的工程师 + 充足的 token 预算，可以做过去三个人的工作。中间管理层的价值正在被压缩，不砍只是在烧钱。 标准化实施。大量软件公司的成本黑洞藏在客户实施端——每个客户都定制，每次都重新造轮子，CS 团队规模随客户数线性增长。这种模式不可持续。标准化实施配合 AI 辅助，是堵上这个洞的唯一方法。 清理委员会文化。每个决策都需要跨部门对齐，每个功能都需要"stakeholder buy-in"——这是管理体系失控的症状，不是健康的协作文化。委员会文化在增长期可以被掩盖，在压力期会成为致命的包袱。 David 援引了 Broadcom/Hock Tan 的案例，收购 VMware 之后砍产品线、砍人、砍一切不能支撑 40% 利润率的东西。残酷，但有效。大多数公司不需要走到这个程度，但方向是一样的：目标是 40%+ 真实运营利润率（含股权激励），不是收割 EBITDA 数字游戏。 --- 还有个细节：David 说，大幅提高每个工程师的 token 预算，参考数字是 $1000/月。 这很实际。给工程师好电脑、快网络，但极低的 token 预算，等于在 AI 时代给跑车加了手刹。工程师的生产力现在部分取决于能用多少 AI 算力，token 预算是 leverage，不是成本。 --- 护城河正在被侵蚀 David 在第二条路里有一个很多人不想听的诊断：你的护城河，可能没有你想的那么深。 数据护城河？用户界面护城河？集成护城河？这三个传统软件护城河都在被 AI 快速侵蚀。 以前建一套深度集成需要数年，现在 AI 写代码快了 10 倍，竞争者可以在几个月内复制。以前靠 UI 体验把客户锁定，现在 AI 原生界面重新定义了"好用"，原来的 UI 优势变成了"老旧遗产"。以前靠独有数据建壁垒，现在大模型训练数据越来越泛化，边际数据优势在缩小。 这不是末日论。是要求你诚实地问自己：我的护城河是什么，它还扛得住多久？如果答案模糊，那护城河大概率是在收缩的。 --- 投资人应该怎么追问 David 在文章末尾说了一段话，不只是给投资人看的。 "模糊的答案，市场会继续施压。" 投资人在 Board Meeting 上应该直接问：你走的是哪条路？ 如果 CEO 的回答是"我们在做 AI 转型，进展顺利，同时也在关注盈利能力……"——这就是模糊答案。这就是没有选择。这就是还在中间地带。 中间地带不是安全区，是最危险的地方。 --- 两件事 从做产品的视角来看，David 的框架让我想到两件事。 "加 AI 功能"和"做 AI 产品"是两回事。前者是把 AI 当工具，后者是用 AI 重新定义价值。这个区别在早期看起来不明显，但 12-18 个月后，市场会让你看清楚。 精简和高效不是对立的。Hock Tan 的案例告诉我们，一家 40% 利润率的公司，可以比一家 -5% 利润率的公司更有战斗力，更能扛住周期。精简不是退缩，是给自己更长的跑道。 "Grow 10 or earn 40."——五个字，但不好回答。大多数 CEO 在 board room 里的答案，其实是第三个选项：继续模糊下去，看市场什么时候逼他们选。
avatar
Wikipedia 限制 AI 写作，不是因为 AI 写得不准。 是因为 AI 写的东西没有「作者」。 每条 Wikipedia 编辑都有人名、时间戳、来源——这条链断了，内容就失去了可信度。 AI 产品的信任问题，本质上是 provenance 问题。用户不信任你，往往不是因为 AI 出错，而是因为出错了没有人负责。
#wikipedia #AI写作限制 #作者可信度 #provenance问题 #AI信任问题
avatar
最近练习 Jujitsu 的时候教练老是提醒我要 呼吸 Breath！！！ 然后我才意识到我不光是 Jujitsu 的时候会忘记，只要一开始特别专注，都会忘了呼吸。。。 感慨一下呼吸法的重要性啊
avatar
大多数人看 autoresearch，看到的是"100 个实验/晚"。我看到的是：100 种出错的方式，你只防住了速度慢这一种。 --- 想法从来不是瓶颈 我做过很多优化工作。ML 训练、产品增长、内容分发。每次问团队「有没有想法」，大家都有一堆。 top-k sampling、学习率 warmup、改文案、调推送时间……想法永远不缺。 真正的瓶颈是：这个实验跑完，我怎么知道它赢了？ 这个问题比看起来难。 一个优化「赢了」可能有三种情况： 1. 真的赢了（real win） 2. 质量退步了，但你没测到（quality regression） 3. 你把问题变简单了，所以分数高了（benchmark illusion） 大多数团队的实验流程，区分不了这三种。他们跑完实验，看指标涨了，就 ship。然后半年后搞不清楚为什么线上效果变差了。 --- 一个「GPU 穷人」的案例 最近看到一个工程师想搞清楚一件事：LLM 在 Apple Silicon 上跑，速度瓶颈到底在哪？不是靠猜，是靠实验逼出来。他自称「GPU 穷人」，没有高端服务器，就在自己的 Mac 上跑。 他做的事不复杂：把代码拆成两个文件。 只读，锁死——这是考卷，agent 不能动题目本身。 可改——这是答题区，agent 在这里自由发挥。 然后他设了一个关键机制：双重质量门控。速度涨了不够，质量也不能掉；更重要的是，规则里专门写死了一条——任务变简单了，不算赢。比如 agent 发现把回答长度砍一半速度就快了。指标确实涨了。但那是缩水，不是优化，直接拦截。 跑完一批实验，结论很清楚： ✅ 真正有效： 把 top-p 随机采样换成 argmax（直接取概率最高的词，省掉每个 token 的概率运算），Qwen 速度提升 10.8%；删掉 42 行冗余配置，速度不变但代码干净了 ❌ 没用的： KV cache 量化（压缩显存的技巧，听起来厉害，实测要么让系统直接崩，要么提升完全淹没在测量误差里）；调各种参数——结果跟没做一样 --- 框架设计的三个教训 第一，把搜索空间和评估标准完全隔离。 只读，agent 动不了 benchmark。听起来显然，但很多团队没做到——他们让 agent 既改优化逻辑，又改评估方式，最后说不清楚到底哪个提升了什么。 第二，多维度质量门控，不让单指标作弊。 只看 tokens/sec，agent 会缩减任务规模刷分。只看 perplexity，可能牺牲速度换质量。两个绑在一起，再加 sanity check，才能逼 agent 找真正的 Pareto 改进。产品增长里一样：只看 DAU 你会做推送轰炸，只看留存你可能在牺牲新用户体验。 第三，区分「测量噪声」和「真实效果」。 有些实验不是「没效果」，是「信噪比不够，区分不了」。诚实标注这两种情况的区别，才不会把可能有害的改动堆进系统里。 --- autoresearch 的真正贡献 Karpathy 这个框架，本质上在回答：怎么让「跑一次实验」的成本低到可以系统性迭代？ 一晚上 100 个实验，不是炫耀速度。是说当单次实验的成本足够低，你就可以用量来补质——用大量小实验代替少数大赌注，用频繁验证代替偶尔的大 release。 但这个「量」要有意义。如果 100 个实验里有 30 个是 benchmark illusion，量没有任何意义，只是在积累噪声。 所以框架设计在前，实验数量在后。 这和做产品的逻辑一样。72 小时 MVP 不是说你要在 72 小时内做出什么厉害的东西。是说你要在 72 小时内验证一个假设。但「验证」有效的前提是你知道什么算成功，什么算失败，什么算「数据太少看不出来」。没有这个框架，MVP 只是快速做了一个东西，不是快速学到了什么。 --- 优化比你想象的更难被感知 减少 MAX_TOKENS 那个实验——速度真的提升了。如果没有 sanity check，这会被记录为「成功的优化」。 但它是假赢。 这种假赢在任何领域都存在。内容营销里，改短文案的打开率可能更高——但因为降低了期望，不是因为质量提升了。增长实验里，取消某个注册步骤可能提升转化——但带来的用户质量可能更差。 大多数团队无法区分，因为评估框架就没设计用来区分。 真正重要的能力，是在实验开始之前，就把「什么算赢」定义清楚。 这很无聊。比想新点子无聊多了。但这才是让实验积累成知识而不是积累成噪声的关键。 --- 那位 GPU 穷人工程师说了一句话，是整件事最准确的总结： > "The hardest part of optimization is not generating ideas. It's building a harness that can tell the difference between a real win, a quality regression, and a benchmark illusion." 这句话不只是关于 LLM 推理优化。 任何需要持续迭代的工作，都应该贴在墙上。 --- 你的实验在测真实效果，还是在测你设计考题的能力？