总结一下最近特别火热的Sutton谈到LLM在通向 AGI 道路上的核心局限与原因: 1. 根本性局限:数据有限且人类化 LLM 的学习完全依赖于人类生成的文本数据(有限且有偏)。 一旦人类数据被“吃完”,模型将失去可持续自我学习的来源。 学到的知识和价值体系被“人类偏见”所框定,无法跳脱出人类语料的边界。 2. 学习机制的局限:被动模仿 vs. 主动学习 LLM 是“预训练 + 微调”模式,本质是模仿人类语言模式。 它不会主动与世界互动、实验、纠错或持续学习。 Sutton 所主张的“child machine”(类动物学习机器)应当是一个通过环境反馈动态进化的系统,而非被一次性训练后静态部署的模型。 3. “Bitter Lesson” 被误解的悖论 Sutton 的“Bitter Lesson”主张:应信赖可扩展的计算与自动学习,而非人类设计。 LLM 看似符合“越多算力越强”的范式,但其实仍深陷人类干预之中: 训练数据来自人类 微调由人类评估 奖励机制由人类工程师手动设计 因此它并非真正的“bitter lesson pilled”,而是人类经验的放大器。 4. 缺乏“在线学习”与“内在动机”机制 动物和人类学习是持续的、带有内在动机的过程(好奇、快乐、探索)。 LLM 缺少此类驱动力,除非人类手动触发再训练。 Sutton 倡导的强化学习系统应当在测试时仍在学习,而非被“冻结”。 5. 自然智能与人工智能的初始化差异 动物看似“从零学习”,但其大脑由进化赋予了强大的初始结构(DNA ≈ 演化训练的参数)。 AI 无法重演进化,因此需要巨量的预训练数据“替代”这一初始条件。 换言之,预训练是我们拙劣的人造“进化”,解决了冷启动问题但带来偏见。 6. 突破方向与可能路径 引入内在动机与持续学习机制:模仿动物的“好奇心、探索、社会互动”学习方式。 减少人类监督依赖:发展能自我生成任务、奖励、自我纠错的学习系统。 多智能体共演化:通过环境中多个 AI 体相互作用,模拟文化与合作的演化。 混合范式:结合 LLM 的符号/语义优势与强化学习的行为探索,使之既“懂语言”又“能实验”。
Y11
3天前
很多人都盼着收入数字往上走,但走着走着,就容易被各种“重要”的事带偏,忘了最初的方向。 分享几个实在的建议,帮你把产品从0做起来,最终拿到结果。 第一步,先问问自己的想法到底靠不靠谱。在社交媒体上(比如Twitter、LinkedIn)、技术论坛(Hacker News、Reddit这些地方),或者直接问问身边的朋友、甚至路上遇到的陌生人,至少找10个人聊聊你的创意。 也可以用个简单的登陆页面放个等候名单,或者用Stripe做个支付链接,看看大家愿不愿意为这个想法买单。多验证,少空想,方向对了才有力气跑。 有了靠谱的想法,就赶紧做个最小可行的产品(MVP)。不用追求完美,用无代码工具快速搭个超简单的版本,推给那些之前说感兴趣的人。然后认真听他们说,根据反馈改,这叫“小步快跑”。 如果无代码工具不够用,就找个Next.js的模板,逼自己一个月内把产品做出来。为了赶时间,把所有不影响核心功能的东西都先砍掉,先让产品“能用”,而不是“完美”。 产品做出来了,就赶紧推出去,然后用最快的速度改。用户更在意产品能不能快速解决他们的问题,哪怕有点小bug也没关系,总比放着不动强。记住,速度比完美更重要。 在这个过程中,每天都要写点东西。不用写得华丽,就分享你真实的故事——遇到的困难、怎么解决的,甚至产品没做好的经历。这种真实的分享就是最好的营销,像跟朋友聊天一样自然就好。 另外,花一天时间写10篇文章,把SEO做起来。不用自己硬扛,有ChatGPT或者一些SEO工具能帮你加快进度。现在多花点功夫在内容上,以后会慢慢看到效果,不用急着求回报。 最后一点,也是最关键的:别停,一直迭代。如果事情没做好,别回到一开始那种“瞎忙”的状态,而是继续改。如果某个功能怎么都做不好,说明你还没掌握这个技能,那就继续练,继续试。创业不是靠想的,是靠在“战场”上打出来的。要么做出结果,要么发现自己不适合,至少你试过了。 创业这条路,没有什么捷径,但把这些事做扎实了,就离成功近了一步。
Y11
3天前
从生命起源的视角回望,有一类特殊的“参与者”值得关注——它们并非我们通常认知的“活物”,却被认为是生命最初的“迹象”。这就是“催化剂”。 想象一个原始的化学汤环境,这些早期催化剂还未形成明确的“目标”,只是无差别地加速着周围化学反应的速率,包括它们自身变种的产生。 在这个过程中,那些偶然“运气好”的分子,因为能更快地促进自身复制、同时更难被分解,在数量上逐渐占据了优势。 它们开始“协作”起来,共同推动自身变种的构建,这便是生命进化的起点。 随着时间推移,这些催化剂的“自我复制能力”变得越来越强,也越来越“专业”,人们开始称它们为“复制因子”。它们不断优化自身的复制效率与可靠性,不同的复制因子逐渐形成了“群体”——每个成员都承担着复杂化学反应中的特定“任务”,整体上共同产出更多的“群体副本”。这样的群体,便是最原始的生命体雏形。 此时的生命形态,有点像早期的印刷机或罗马数字系统:既不是单个复制因子的孤立运作,也没有形成一个能精准生产特定物质的“通用系统”。在众多复制因子中,RNA分子可能是当时的“佼佼者”。它们本身就具备催化功能,其复制过程高度依赖组成它的“碱基序列”——这使得复制不再仅仅是简单的催化反应,更像是一种“编程”,通过碱基排列形成的“语言”来传递信息。 随着进化深入,“基因”这个概念逐渐清晰:它是复制因子中具体的“指令”,而“基因组”则是由多个相互依存的基因组成的“协作群体”。复制整个基因组的过程,就构成了一个完整的“生命体”。可以说,遗传密码本身,就是描述生物体的“语言”。 大约在35亿年前,生命系统出现了一次关键的“升级”——DNA取代RNA成为主要的复制因子。DNA分子结构更稳定,能存储更大量的遗传信息,为后续更复杂的生命形态奠定了基础。 从DNA开始,生命进化的故事我们已相当熟悉,但这背后的“非凡”仍值得深思。最初,遗传密码与生物体其他部分共同进化,但在某个节点,当生命还停留在原始单细胞阶段时,遗传密码本身却“停止了进化”。此后,尽管地球上的生命形态不断分化、变得复杂,从单细胞到多细胞,从简单到高等,但所有生命都共享着同一个“遗传语言”:使用相同的碱基字母表,每三个碱基组成一个“词语”(即密码子),这些“词语”的含义虽有细微差异,却构建了从微生物到人类的所有生命蓝图。 这种“语言的延续性”,或许正是生命最深刻的奥秘之一——它以一种稳定的“底层代码”为基础,不断生长出千变万化的“生命形态”。
Y11
3天前
在工作中,我们常常面临目标设定的选择:是紧盯结果(KPI),还是聚焦过程(OKR)? KPI的“结果导向”有时像一把双刃剑。 当我们为自己定下KPI时,很容易因为对结果的过度期待而变得焦虑,甚至患得患失。 毕竟,努力之后如果结果不如预期,KPI就仿佛成了衡量价值的唯一标准,让人倍感压力。 而OKR的“过程导向”则给了我们另一种思路。 它更像是在指引我们,把大目标拆解成一个个可执行的“小任务”,完成一个就向下一步推进。 这种方式更注重执行力,鼓励我们先行动起来,在实践中不断调整。 其实,很多时候我们在开始做一件事时,很难完全预见过程中会遇到什么困难,也不清楚哪里需要改进。 就像我们写代码,最初可能只是为了解决一个具体的小问题,随手写出一段代码。但随着项目推进,你会发现重复的代码越来越多,于是开始思考能否抽象成一个通用组件;当系统并发量提高后,性能瓶颈出现,又会琢磨如何引入队列来优化;随着数据量增长,数据一致性和冗余问题浮现,可能需要通过定时任务来梳理……这些改变往往不是一开始就能规划好的,而是在一次次实践中发现问题、解决问题,逐步迭代优化的结果。 真正有价值的突破,很少是完美规划出来的,更多是在行动中不断调整、持续优化的“自适应微创新”。我们也常常发现,最初的规划与最终的实现会有偏差,这恰恰是因为现实中总会有新的情况出现,需要我们根据实际反馈做出调整。 所以,与其纠结于KPI的数字,不如像OKR倡导的那样,脚踏实地完成每一个小任务,在实践中积累经验、发现问题、持续改进。毕竟,任何伟大的成就,都始于每一次微小的行动和迭代。
Y11
3天前
开源组件作为互联网世界的基石,其安全问题始终是悬在开发者头顶的一把剑。 最近,我注意到一个值得关注的现象:不少国内团队在使用开源组件时,往往专注于功能实现和迭代速度,却容易忽略对安全漏洞的排查。 这就像我们在搭建房屋时,只关心装修是否漂亮,却忘了检查地基是否牢固,隐患可能随时爆发。 我有一个不成熟的小想法:如果能开发一个工具,让开发者只需输入开源项目的代码提交记录地址,就能通过大模型自动分析这次代码变更是否涉及安全升级。 比如说,当我们看到一个开源项目最近有大量代码提交,传统方式可能需要人工逐条比对差异,耗时又费力。 但借助大模型,我们可以让它像一个细心的安全侦探,自动识别出那些可能修复漏洞的代码片段——比如涉及加密算法优化、权限校验改进、输入验证增强的部分。 如果工具真的能准确捕捉到这些安全升级,那意义就更大了。我们还可以让大模型进一步发挥作用,基于分析结果生成简单的漏洞验证(POC)和利用代码(EXP)。当然,这部分内容必须严格控制使用范围,目的不是为了攻击,而是帮助开发者更直观地理解漏洞原理、验证修复效果,或者为安全研究者提供快速参考。 这个想法的核心其实很简单:用技术手段降低安全排查的门槛,让更多开发者能在日常工作中主动关注开源组件的安全状态。毕竟,安全不是某一个人的责任,而是整个生态的事。就像过马路时需要大家共同遵守交通规则,开源社区的安全也需要每个使用者的细心和警惕。 当然,技术实现中肯定会遇到不少挑战,比如如何让大模型更精准地识别安全相关的代码变更,如何平衡自动化分析的效率与准确性,以及如何确保生成的POC/EXP不会被滥用。但我始终相信,技术的价值在于解决问题,而这个小工具或许能成为连接开发者与开源安全的一座小桥,让更多人意识到“安全升级”的重要性,共同为构建更安全的数字世界添砖加瓦。毕竟,在互联网这个“看不见的城市”里,每个人都是守护者。
Y11
3天前
有些道理看似简单,却常常因为我们未曾深入体验或换位思考而难以真正理解。 最近在实践中,我有了几点真切的感悟,或许能给我们一些启发: 首先,以技术视角看问题时,要明白表象之下往往有更深层的价值。 比如我们常讨论的一些技术平台,像Solana,很多人一开始可能会把它简单看作一个高性能的数据库,觉得实现相应的接口和API并不复杂。 但实际上,当它被广泛应用于金融场景时,其核心价值远不止于此。它真正解决的是“信任”这个根本问题:通过技术手段确保每一笔交易100%可靠,并且从源头上杜绝了像程序员通过代码凭空生成大量虚拟资产这类滥用行为。 这就像在数字世界里建立了一个值得信赖的“账本”,让人们能够放心地进行价值交换。 其次,在评估新技术框架时,不能只看表面的性能参数。 最近尝试使用HonoJs这个新兴框架,它在速度和成本控制上确实表现出色。 但在实际压力测试中,当我们用100个并发用户发起10万次请求时,却出现了约60次莫名的错误。 这让我意识到,对于金融交易、线下商超系统、地图服务、自动驾驶数据传输、物流调度以及支付系统等对稳定性和可靠性有极高要求的场景,这样的框架可能还无法胜任。因为在这些场景中,哪怕是一次数据传输的失误,都可能导致巨大的经济损失,甚至影响到实体与虚拟资产的正确流转——多一个零少一个零,或者数据出现偏差,都绝非小事。当然,它或许更适合内容管理系统(CMS)、客户关系管理(CRM)、企业资源规划(ERP)、博客平台、视频直播、图文社交社区、即时通讯以及生成式AI应用等对实时性和成本更敏感,但对极端可靠性要求稍低的场景。 再者,编程的本质是为了提升效率、降低成本,但这并不意味着技术要从一开始就追求复杂。当业务规模较小时,大家没有形成统一的行动模式,一个简单的Excel表格,或许就能清晰地管理所有事务,满足需求。但随着业务的扩张,角色的增多,以及用户行为的复杂化,我们就需要通过明确角色定义、梳理用户行为分类、制定标准化操作流程(SOP)等方式,让整个系统高效运转,这才是编程真正发挥价值的“大后期”。 最后,关于“耐心”,我理解它并非消极等待,而是一种积极的“从容”。这意味着我们要踏踏实实地做好眼前的每一件事,专注于日常的积累和成长,少一些患得患失的焦虑,也不必总去过度担忧未来的结果。与其在空想中消耗精力,不如一步一个脚印,用行动去积累力量。就像种树,耐心等待的不是什么都不做,而是默默耕耘,等待它自然生长。 这些感悟或许朴素,但在实践中却能让我们更清晰地看到事物的本质,找到更适合的路径。无论是技术选择、业务规划,还是个人成长,保持这种务实而深刻的思考,总能让我们走得更稳、更远。
Y11
3天前
做一个平台,让大家可以在上面“买”GitHub的Star或者ProductHunt的点赞?这个想法听起来简单,可背后藏着不少门道。 我们先琢磨琢磨用户为什么需要这个。 现在的互联网圈子里,GitHub有个Trending榜,ProductHunt也经常有黑马产品冒出来。 对那些想让自己项目被更多人看到的开发者来说,冲榜能带来实实在在的好处,比如获得投资、吸引用户,甚至直接变现。 可自己一个人弄,力量太单薄了,找朋友互相帮忙又不长久,花钱找水军又怕风险高、效果差。 这时候,如果有个平台能把有冲榜需求的人和想赚点零花钱的人对接起来,会不会就不一样了? 发布者可以在平台上明码标价,比如“需要100个GitHub Star,每个0.5元”,或者“ProductHunt点赞,每个0.8元”。然后,有闲账号的人就可以去平台接单,按照要求操作。 这里面有几个关键问题得解决。首先,怎么保证点赞是真实有效的?如果都是机器人操作,平台很快就会被官方封号,项目也做不起来。所以,平台得想办法让这些点赞看起来“自然”。比如,用户需要用自己真实的账号去操作,平台可以要求用户提供一些基础信息,甚至进行简单的实名认证,再通过一些行为验证,比如让用户手动输入验证码,或者模拟真实用户的浏览习惯,避免被系统识别为机器操作。 其次,价格怎么定才合理?太便宜了,做任务的人没动力;太贵了,发布者又觉得不划算。平台可能需要根据不同平台(GitHub、ProductHunt)、不同排名难度、不同时间段的热度来动态调整价格。比如,在GitHub的热门领域,冲榜竞争激烈,价格可能就高一些;而在相对冷门的领域,价格可能就低一点。同时,平台还可以设置一些阶梯价格,比如买得多就给折扣,鼓励发布者批量下单。 再者,平台怎么盈利?最直接的方式就是收取佣金,比如从每个交易中抽成10%-20%。另外,还可以考虑增值服务,比如为发布者提供数据分析,告诉他们哪些账号的质量更高,或者哪些时间段进行冲榜效果更好。对于那些有长期冲榜需求的用户,平台还可以推出会员服务,提供更优惠的价格和更优先的接单权。 这个想法的价值,在于它抓住了开发者和产品方的痛点——“低成本、高效率地提升曝光度”。现在很多人都在做小红书矩阵号,虽然也能达到类似的宣传效果,但成本可能比较高,而且账号风险也大。相比之下,用这种众包点赞的方式,用户只需要为真实有效的操作付费,性价比可能更高,而且操作起来更灵活。 不过,这个平台也面临一些挑战。首先是合法性问题,GitHub和ProductHunt都有自己的社区规范,这种众包点赞的行为会不会被判定为恶意营销?平台需要在商业利益和遵守规则之间找到平衡,甚至可以和这些平台进行沟通,争取得到一定的理解和支持。其次是用户信任问题,很多人可能会担心账号安全,或者怕自己的账号被拿去做违规操作。平台需要建立严格的安全机制和用户反馈渠道,及时处理纠纷,比如如果用户的账号因为平台的问题被封禁,平台要承担相应的责任。 总的来说,这个“点赞众包平台”的想法有一定的市场潜力,但要成功,关键在于解决好真实性、价格、盈利和合规这几个核心问题。如果能把这些问题处理好,或许真的能成为一个有价值的项目。