即刻App年轻人的同好社区
下载
让普通用户为 Agent 准备一台独立且网络长期稳定的设备是奢侈的，只有跑在云上的 Agent 才能保障持续运行永久在线
但另一方面，一个 Agent 如果只有云环境而没有本地行动能力，不能在离用户最近的地方拿到个性化上下文，不能利用/接管本地的一些现成工具，那么普通用户使用它的输入成本就很难降到合理水平
一个合理的结构是，harness 在云上作为智力与记忆的中枢，用户的各类端设备/应用（本地应用+云应用）作为眼睛与手脚通过网络协议接入
但另一方面，一个 Agent 如果只有云环境而没有本地行动能力，不能在离用户最近的地方拿到个性化上下文，不能利用/接管本地的一些现成工具，那么普通用户使用它的输入成本就很难降到合理水平
一个合理的结构是，harness 在云上作为智力与记忆的中枢，用户的各类端设备/应用（本地应用+云应用）作为眼睛与手脚通过网络协议接入
10 31
去年下半年，我正在筹备这次创业，想做自己最有热情的方向，除了已有的合伙人，还缺少一位某领域的技术专家加入。人很难找，所以在找人的同时也在看是否能从不同的角度去做
关于我最有热情的方向，如果抽象一些来描述，它更偏消费端，要寻找不同角度，自然的，便导向了供给，通过 AI Coding 来创造更多供给
当时最热的、给非程序员用的 AI Coding 产品是 Lovable，数据猪突猛进，它的故事是：每个人都能搭建自己的网站来服务自己的用户
这建立在高价值流量来自人类客户的基础假设之上，我们认为这不能很好的描述未来
所以我们要做一个 Lovable Copy ，别的都大差不差，核心区别是 Lovable 给用户交付的是一个人类友好网站，而我们给用户交付的是一个人类友好的网站+一个基于MCP、A2A 或者其他随便什么对 Agent 友好协议的接口服务 —— 让你的业务为 Agent 流量做好准备，所有服务都值得为 Agent 重做一遍
并且对于我们自己，在积累足够多服务之后，还能从工具转平台，做服务分发和服务抽成
在龙虾大火的当下，这几乎就是最风口的故事，在那个时点，我们却收到了不少来自投资人的挑战，相对给 Agent 搭友好的服务，大家甚至更相信 Coding 是新内容形态，可以长出新的内容社区
我们不得不往这个故事里塞东西：谁要建网站？当时的 Lovable 有什么问题？
谁要建网站？
北美欧洲没有大众点评，只有 Google map。大众点评既有列表页又有详情页， Google map 只有列表页，详情需要这些小商家自己搭官网，产生大量建站需求，所以我们要为北美欧洲小商家建站而服务
当时的 Lovable 有什么问题？
当时的 Lovable，几乎就是个原型工具，无法稳定维护生产级的带后端业务的站点。小商家所需要的官网会涉及会员、预定、电商这类带后端且零 Bug 容忍度的业务组件，没必要每次都让 AI 从 0 写，费 token 不说，主要是质量不够生产级，容易有bug，所有这些都应该预制好，让 AI 直接复用
这俩问题我们的回答，也是当时不少团队的共同思路。经过几个月，大家开发的差不多了，便扎堆上线了一批“生产级”Coding Agent（包括Lovable自己）。还有那个 AI Coding 社区，也开始讲起了小商家建站的故事
然而无人关心了，因为龙虾的大火，投资人和自媒体说他们要第一版，要那个为 Agent 做基建、为 Agent 做服务、为 Agent 搭平台的版本
（以上无论是第一版还是挑战应答版，我们都没去做，最终还是选择了那个自己更有热情东西去投入
关于我最有热情的方向，如果抽象一些来描述，它更偏消费端，要寻找不同角度，自然的，便导向了供给，通过 AI Coding 来创造更多供给
当时最热的、给非程序员用的 AI Coding 产品是 Lovable，数据猪突猛进，它的故事是：每个人都能搭建自己的网站来服务自己的用户
这建立在高价值流量来自人类客户的基础假设之上，我们认为这不能很好的描述未来
所以我们要做一个 Lovable Copy ，别的都大差不差，核心区别是 Lovable 给用户交付的是一个人类友好网站，而我们给用户交付的是一个人类友好的网站+一个基于MCP、A2A 或者其他随便什么对 Agent 友好协议的接口服务 —— 让你的业务为 Agent 流量做好准备，所有服务都值得为 Agent 重做一遍
并且对于我们自己，在积累足够多服务之后，还能从工具转平台，做服务分发和服务抽成
在龙虾大火的当下，这几乎就是最风口的故事，在那个时点，我们却收到了不少来自投资人的挑战，相对给 Agent 搭友好的服务，大家甚至更相信 Coding 是新内容形态，可以长出新的内容社区
我们不得不往这个故事里塞东西：谁要建网站？当时的 Lovable 有什么问题？
谁要建网站？
北美欧洲没有大众点评，只有 Google map。大众点评既有列表页又有详情页， Google map 只有列表页，详情需要这些小商家自己搭官网，产生大量建站需求，所以我们要为北美欧洲小商家建站而服务
当时的 Lovable 有什么问题？
当时的 Lovable，几乎就是个原型工具，无法稳定维护生产级的带后端业务的站点。小商家所需要的官网会涉及会员、预定、电商这类带后端且零 Bug 容忍度的业务组件，没必要每次都让 AI 从 0 写，费 token 不说，主要是质量不够生产级，容易有bug，所有这些都应该预制好，让 AI 直接复用
这俩问题我们的回答，也是当时不少团队的共同思路。经过几个月，大家开发的差不多了，便扎堆上线了一批“生产级”Coding Agent（包括Lovable自己）。还有那个 AI Coding 社区，也开始讲起了小商家建站的故事
然而无人关心了，因为龙虾的大火，投资人和自媒体说他们要第一版，要那个为 Agent 做基建、为 Agent 做服务、为 Agent 搭平台的版本
（以上无论是第一版还是挑战应答版，我们都没去做，最终还是选择了那个自己更有热情东西去投入
14 42
Anthropic 封锁国内访问
-> 逼出大量程序员“中转”刚需
-> 养活一堆 API 二道贩子，各种 CC 中转站
-> 截胡海量真实 CC 、Codex、 Gemini 编程数据
-> 倒卖给国内基模厂，比起自己苦苦构造 Query 蒸馏数据，数据丰富度真实性都爆增、还不用操心封号合规、还巨特么便宜
-> 国产模型 Coding 能力大跃进
-> 逼出大量程序员“中转”刚需
-> 养活一堆 API 二道贩子，各种 CC 中转站
-> 截胡海量真实 CC 、Codex、 Gemini 编程数据
-> 倒卖给国内基模厂，比起自己苦苦构造 Query 蒸馏数据，数据丰富度真实性都爆增、还不用操心封号合规、还巨特么便宜
-> 国产模型 Coding 能力大跃进
146 2431
很早期的视频生成模型就能直出分镜，虽然那时分镜烂、画面也烂
我一直非常疑惑，为什么在所有人都预期模型画面水准会快速提升的同时，大量的创业者和投资人会认为模型分镜水准会长时间原地踏步，并以此判断为基础在过去一年内堆出了 N 个视频 Agent / 剪辑 Agent 产品
我一直非常疑惑，为什么在所有人都预期模型画面水准会快速提升的同时，大量的创业者和投资人会认为模型分镜水准会长时间原地踏步，并以此判断为基础在过去一年内堆出了 N 个视频 Agent / 剪辑 Agent 产品
20 33
朋友：市场热到，但凡有个还不错的候选人，拿的都不是 Offer 而是 TS
王慧文: 这市场热到我有点中暑的感觉😰
8 00
老罗这是做了个要你命3000么。。。
龙哥终于又出新东西了❗️内测版详细体验～ - 小红书
2 01
21 年油管博主 sentdex 上传了一个视频，使用 AI 而非 3D 渲染，实现连续帧输出，玩了一段模拟GTA
当时，和朋友们比较务虚的进行了以下讨论：
「如果将人类的视觉需求分为两类：一类是信息需求，例如查看报表、地图和书籍；另一类是感官需求，如游戏和电影（并非指它们没有信息，而是指它们选择以视觉图像代替文字的部分，主要为了提供感官刺激）
对于信息类图像，必需要确保信息的准确呈现。在这种情况下，利用 AI 生成图像所消耗的算力永远大于使用基于规则的、非AI的程序进行渲染。
然而，感官类需求与此不同，其核心在于欺骗感官而非信息的绝对还原。尽管传统的 3D 渲染技术也在利用这一点（如烘焙贴图等），但整体上还是在通过引入更多的物理计算（如光追）来提高真实感，也就是说目标是再造一个真实世界。这种方案下（不考虑优化）每提高一点真实感，算力消耗都会成倍增加。导致许多算力并未直接呈现在视觉效果上，被“浪费”了
相较之下，AI 视觉生成在实现感官欺骗这个目标上更为直接。虽然在 sentdex 的示例中，AI 消耗的算力足以让传统 3D 引擎渲染出更好的画面，但未来某一天可能会反过来」
时间回到现在，相同硬件下 Stable Diffusion 之类的模型已经能比传统光追 3D 渲染器更快地生成具有相同真实感的单帧图片。尽管在可控性和视频抖动等方面仍存在问题亟待解决，但我们那时讨论的「未来某天」似乎已经经悄无声息的过去了
当时，和朋友们比较务虚的进行了以下讨论：
「如果将人类的视觉需求分为两类：一类是信息需求，例如查看报表、地图和书籍；另一类是感官需求，如游戏和电影（并非指它们没有信息，而是指它们选择以视觉图像代替文字的部分，主要为了提供感官刺激）
对于信息类图像，必需要确保信息的准确呈现。在这种情况下，利用 AI 生成图像所消耗的算力永远大于使用基于规则的、非AI的程序进行渲染。
然而，感官类需求与此不同，其核心在于欺骗感官而非信息的绝对还原。尽管传统的 3D 渲染技术也在利用这一点（如烘焙贴图等），但整体上还是在通过引入更多的物理计算（如光追）来提高真实感，也就是说目标是再造一个真实世界。这种方案下（不考虑优化）每提高一点真实感，算力消耗都会成倍增加。导致许多算力并未直接呈现在视觉效果上，被“浪费”了
相较之下，AI 视觉生成在实现感官欺骗这个目标上更为直接。虽然在 sentdex 的示例中，AI 消耗的算力足以让传统 3D 引擎渲染出更好的画面，但未来某一天可能会反过来」
时间回到现在，相同硬件下 Stable Diffusion 之类的模型已经能比传统光追 3D 渲染器更快地生成具有相同真实感的单帧图片。尽管在可控性和视频抖动等方面仍存在问题亟待解决，但我们那时讨论的「未来某天」似乎已经经悄无声息的过去了
00:45
10 12
🌞 早上讨论到不同应用分别集成 Copilot 冗余显而易见，更合理的做法是不同应用接入同一个 Copilot，让自然语言指令可以跨应用执行；🌛 到了晚上 ChatGPT plugin 方案就公布了。这些天真是日新月异，内容只要稍微在草稿箱里躺躺就显得过时
敖特_Aute: 可以看到近期LLM对传统App的改造，几乎都是给App加Copilot的模式：「弹一个窗，展示一个聊天机器人，用户可以通过与之对话来完成软件操作」 包括但不限于Office、Github、Bing、ChatPDF 等等 关于这种改造为什么不是粗暴的短期胶水方案，我另行展开，本条先假设其就是某种最佳实践 这里要讨论的是，为什么要每个App都去各自加上一个界面大差不差的Copilot？ 好处是对自身软件有着完全的数据访问权限，可以达成一些针对性更高的操作 但其中的冗余也显而易见 并且，更大的问题是当前的LLM已经完全有能力理解跨App交互的指令，却无法进行执行 例如「请帮我把Allen在微信群提到的头显加入淘宝购物车」这样一条自然语言指令，微信的Copilot不能完成我的请求，淘宝的Copilot也同样不行（虽然这两个Copilot目前还不存在😛 如何解决这一问题，或许有两种方案： 一是通过云，但这要求我们使用的所有App都来自一家巨头，或它们都接入同一个云 二是通过端，操作系统层的Copilot能力开放，App可选择主动适配，也可以通过系统级的GUI识别、用户事件模拟，来被动接入 既然云与端的方案都要App厂商进行接入或适配，而端的方案还能通过GUI识别（读屏）、用户事件模拟等技术对没有接入的App做降级兼容。再考虑到现在各家App大厂的林立现状，端的方案极有可能最终胜出 从端的视角，苹果的多端互通、快捷指令、视障辅助功能、SwiftUI等都可以算是已经做好准备的基建 无论是视障辅助功能的界面的识别；还是通过LLM自然语言转结构化数据的能力，解决操作复杂学习成本高问题后的快捷指令，在端方案下都将发挥出巨大价值 这也是为什么我认为在本轮LLM热潮中苹果看上去有些掉队，但其实还握着一张绝佳船票的理由 注：上文的云与端并不是指AI运行在哪里，而是指这个跨应用串联的流程执行的地方 讨论可微：aute_wechat
6 11