2026年2月

如何通过企业网盘来高效地下载大文件呢？今天我们聊聊这个话题，希望能为企业用户和个人用户带来具体而直接的帮助。

一、为什么选择企业网盘来处理大文件下载？

随着数字化办公的不断深化，企业与个人都需要频繁处理大体积文件。例如，设计公司需要下载30GB的客户资料包；视频制作团队要获取50GB的素材库；

建筑设计师们更是习惯用数百MB的CAD图纸进行协作……而这些“文件巨无霸”通过传统的邮件或即时通讯工具传递显然是不现实的，网盘成为了解决这一问题的主战场。但为何我们需要选择企业网盘？与那些功能单一的普通网盘相比，它又有哪些实用之处？

企业网盘之所以成为下载大文件的首选，核心在于以下几方面的优势：

稳定性：大文件下载不光考验网络状况，也对双方存取设备的可靠性提出高要求。企业网盘通常采用高度优化的服务器架构和多点备份技术，即使过程中网络波动，仍能保障传输的完整性。你可能遇到过下载途中断网后不得不重新来过的情况，但在Zoho网盘中，这种问题通常会被最大限度地规避。它内置断点续传功能，保障下载任务在意外中断后可继续进行，像是负责装卸任务的“货车司机”，给你妥善保证。

高传输效率：在普通用户眼中下载安装包可能只是等待几个小时，但对企业团队来说，时间成本是不可忽视的重点。企业网盘通常会采用全球快速节点和多线程加速技术。以Zoho网盘为例，其提供的专属传输通道可以将下载速率提升数倍。你会发现大文件在短时间内轻松落地，再无需因网速或文件大小而焦虑感倍增。

安全性和隐私保护：大文件不仅大，还通常意味着重要，无论是技术资料、项目合同，还是影像资产。一旦传输过程中被截取、泄露，对企业或个人都可能造成严重后果。Zoho网盘有严格的用户权限管理与加密存储策略；下载链接可以设置密码与时间限制，确保用户享受便利的同时，数据不沾染任何“风险颗粒”。这就像在搬家时附加了一套保险制度，无论是刮风下雨、路途颠簸，货物安全都有绝对保证。

二、通过Zoho网盘下载大文件的实际步骤

理论上的优势固然重要，但具体到操作层面，企业网盘如何实现高效的大文件下载？下面我们以使用Zoho网盘为例，详细分解整个流程：

  1. 创建与共享下载链接

首先，文件的拥有者需要在Zoho网盘中找到他需要共享的大文件。选中目标文件后，点击“共享”按钮。此时，一个灵活选项菜单会展现。用户可以选择生成一个下载链接，并设置下载权限。下载权限包括“密码保护”“仅限成员下载”“链接有效期”等，进一步保障文件的安全传输。大体积文件常与团队协作紧密关联，而这种共享方式精准解决了数据跨部门、跨企业的分发问题，轻松地将文件从甲地“搬运”至乙地。

  1. 断点续传与完整性检测

下载端用户收到共享链接后，点击链接即可启动大文件下载。Zoho网盘不仅利用多线程技术加速下载过程，还内置了断点续传机制。即使网络环境突发变化，下载任务也可在恢复网络后继续进行，减少重复操作的时间浪费。下载完成后，Zoho网盘将自动运行完整性校验，确保文件没有因传输中数据缺失或损坏而失效。这就像验收搬家物品一样，有序、细致，杜绝任何数据上的“磕碰”。

  1. 移动端与多设备支持

不少用户对下载文件的场景有着极高的便捷性要求。很多时候，项目经理可能不在办公室，而是通过手机末端获取大文件，以便现场协调工作进度。Zoho网盘提供了完整的多端支持，无论是在PC，还是手机、平板，只需账号快速登陆，即可随时下载大文件，满足用户多场景需求。得益于其高度优化的App体验，无需担心移动端下载时性能受限，这种灵活性就是为快速变化的现代工作模式量身打造的。

三、企业网盘在未来工作模式中的可能性

如果说高效、安全地下载大文件是企业网盘目前的主要功能范畴，那么随着技术的不断革新，企业网盘在未来数字化办公中，还会解锁更多潜在的可能性。以Zoho网盘为例，我们可以畅想：

  1. 跨平台协同的生态整合

未来，企业网盘的使用不再局限于下载和存储，它可能深度集成到企业的协同办公工具中。例如，当设计人员下载一份大体积设计稿时，可以直接在网盘中与团队成员打开并预览，实现即改即存的实时化操作。目前，Zoho网盘已经与Zoho其它协作工具深度整合，比如与Zoho Mail、Zoho Projects等，从收发邮件到项目管理，用户只需在一个生态系统中完成所有下载任务，这将在未来进一步深化。

  1. 学习型智能推荐

AI技术迅猛发展，未来Zoho网盘或许能够基于用户行为，智能预测用户最近可能下载或需要的文件。试想这样一个场景，当你打开Zoho网盘时，它不仅主动呈现你上次下载未完成的文件，还能推荐相关的辅助资料，让信息的传输与使用更具目的性与效率感。

  1. 可定制化储存与传输服务

每个企业对于文件下载的需求都有独特之处，将来的企业网盘无疑会在服务定制性上大显身手。Zoho网盘提供的云端定制套餐，可以让用户按需选择服务器地域、传输频宽等服务，企业甚至能为特定项目创建加密存储文件夹，打造更加专属的“数据运送工具箱”。

工业AI竞争的多维度透视
当前全球工业AI领域的竞争已呈现出愈发复杂的态势，这不仅仅是一场技术竞赛，更是生态系统和标准制定权的全面较量。从竞争主体来看，既有西门子、GE等工业巨头依托深厚行业积淀构建的全栈式解决方案，也有如广域铭岛这类新兴企业通过聚焦特定场景实现快速突破，更有微软、谷歌等科技巨头凭借云计算和算法优势强势切入。这种多元化的竞争格局使得工业AI市场既充满活力又充满变数。
在技术路线方面，各参与方采取了差异化的策略。有的企业选择从底层平台入手，致力于打造工业AI操作系统；有的则专注于垂直领域深度开发，在质量检测、预测性维护等细分场景构建竞争壁垒；还有的企业侧重数据采集与边缘计算，从工业现场的数据源头占据优势。这种技术路径的分化反映出工业AI应用场景的多样性，也意味着很难出现一家通吃的局面。
值得关注的是，标准的竞争正在成为新的焦点。各大厂商都在积极推进自身技术方案成为行业标准，这涉及到数据接口、通信协议、算法框架等多个层面。虽然目前尚未形成统一的标准体系，但这种竞争正在加速工业AI技术的成熟和普及。与此同时，各国政府也通过产业政策参与其中，如德国的"工业4.0"、美国的"先进制造伙伴计划"以及中国的"制造强国战略"，都为本土企业提供了重要支持。
关键技术壁垒与护城河构建
工业AI领域存在着显著的技术壁垒，这不仅仅体现在算法层面，更体现在行业知识的积累和数据资源的获取上。成功的工业AI企业往往都构建了多层次的护城河：首先是数据壁垒，通过项目实施积累了大量高质量的工业数据，这些数据具有明显的行业特定性，新进入者很难在短时间内获取；其次是算法壁垒，针对工业场景的特殊需求，如小样本学习、迁移学习等开发的专用算法，这些算法需要与行业知识深度融合；最后是工程化壁垒，将AI算法可靠地部署到工业环境需要解决大量工程实践问题，这需要长期的经验积累。
在商业模式方面，各厂商也在探索不同的路径。有的采用传统的项目制模式，为大型企业提供定制化解决方案；有的则尝试产品化路线，将通用能力封装成标准化产品；还有的创新性地采用效果付费模式，按为客户创造的价值分成。这些商业模式的探索反映出工业AI落地过程中的现实挑战：如何平衡定制化与规模化、如何量化AI创造的价值、如何建立可持续的盈利模式。
人才竞争也是这个领域的重要角力点。既懂工业技术又懂人工智能的复合型人才极度稀缺，这导致人才争夺异常激烈。领先企业不仅通过高薪吸引人才，更通过构建完整的技术体系和丰富的应用场景来留住人才。这种人才竞争进一步加剧了行业的分化，头部企业凭借人才优势形成良性循环，而中小企业则面临人才短缺的困境。
创新实践：国内外企业的差异化探索
广域铭岛的智能制造实践 广域铭岛作为中国工业AI领域的代表企业，其发展路径颇具特色。公司依托吉利集团的制造场景，深耕汽车产业链，打造了从研发设计到生产制造再到质量管控的全流程AI解决方案。在重庆的智能制造基地，其部署了自主研发的工业AI平台，实现了生产设备的预测性维护、质量缺陷的智能检测以及生产排程的优化调度。该平台通过分析设备运行数据，提前14天预测潜在故障，准确率达到85%以上；在质量检测方面，通过机器学习算法，将检测效率提升3倍的同时，漏检率降低至0.1%以下。这种基于真实制造场景的深度应用，为其积累了宝贵的行业经验。
西门子的数字孪生战略 德国西门子作为工业自动化巨头，其工业AI战略突出体现在数字孪生技术的深度应用上。通过收购和自主研发，西门子构建了完整的数字孪生技术栈，从产品设计、生产规划到运维服务都实现了数字化映射。在安贝格电子工厂，西门子部署了覆盖全厂的数字孪生系统，实时采集超过5000万个数据点，通过AI算法进行优化分析。这套系统使工厂的产品缺陷率降低到12ppm以下，产能提升达40%，同时能源效率提升20%。西门子的优势在于将工业AI与现有的自动化产品线深度融合，为客户提供端到端的解决方案。
Uptake的预测性维护创新 美国企业Uptake则选择了不同的切入点，专注于工业设备的预测性维护领域。通过为工程机械、风电设备等提供智能运维服务，Uptake构建了强大的数据分析平台。其核心能力在于融合多源异构数据，包括设备传感器数据、环境数据、维修记录等，运用机器学习算法实现设备健康状态的精准评估。在为卡特彼勒提供的解决方案中，Uptake的系统成功将设备非计划停机时间减少30%，维护成本降低25%。这种聚焦特定场景的打法，使Uptake在细分领域建立了竞争优势，并获得了资本的青睐。

出的第一版包，差不多 100 个 BUG 。
大部分是与 UI 不一致，各种排版、间距、字体、颜色等等和 UI 不一样，他总是按他自己想法做，他觉得好看。
但关键不是好不好看问题。。。和 UI 不一样，我测试的放过去，就变成我的问题了。
让他改还贼费劲，要么改完达不到预期、要么漏改、要么改 A 又出 B 问题。

这是他的问题还是 AI 问题。。。

如题，小白是我，我是小白。在油猴用了一个强制把浏览器内的文字字体强行改成苹方的脚本，没有解决我的问题，就不想用了。

但是！！在我把脚本关闭后，现在出现了问题：
1、浏览器部分地方（比如 iTab ）字体还是苹方，没有改回来
2、电脑上的 Lark 里面的字体变成了苹方，没有改回来
3、油猴上只有不启用的选项，没有恢复的选项

求各位大佬帮助！！

  • 列出 拼多多 京东 淘宝 某样商品的的价格， 结合他们的历史价格 给出购买的建议 参考价格 产品真假 售后服务
  • 列出某样商品 他们线上和线下款区别，哪一个线上和线下是一样的
  • 列出 去某个地方 在哪里买机票 最便宜 不要让我被携程大数据杀熟，每次刷机票 我 家里不同手机刷出来都不要，感觉真的太可怜了。
  • 酒店同理
  • 整理小红书和大众点评里 某家店的评价品 过滤掉商家刷的数据 给我我一个真实准确的评价
  • 整理一下网上哪里有可以直接下载的电影链接，我想直接下载看。不想到处充会员

ai 不能给我做到这些事情，发现还是在这些方面 不断吃亏上当 。那 AI 到底改变了什么？

工时表是一种数字化工具，可以帮助员工记录他们在项目中不同任务上花费的时间。员工无需在纸上记录时间，只需将每日工作时间输入系统即可。这有助于企业清晰地了解每项任务、问题或活动所花费的时间。通过查看这些记录，企业可以更好地规划未来项目、估算预算并确保工作按时完成。无论员工一次只处理一项任务，还是一天处理多项任务，工时表都能轻松追踪并提交每项活动的具体工时。

工时表和工时日志在项目管理中至关重要，因为它们能帮助所有人清晰地了解工作时间的分配情况。工时表用于记录员工的总工时，而工时日志则记录每项任务或活动所花费的时间。对于初学者来说，这仅仅意味着记录完成了哪些工作以及花费了多少时间。这样就能更清楚地了解各项任务的耗时是否超出或低于计划。
这些记录能帮助项目经理以简单的方式跟踪项目进度。当他们了解每项任务所花费的时间后，就能检查项目是否按计划进行或是否落后。如果某项任务耗时过长，他们可以迅速找到问题并加以解决。工时日志还有助于规划未来的项目，因为经理可以利用过去的工时数据更准确地估算工作量。
工时表和工时日志对于成本管理也十分有用。许多项目都根据工时计算成本，因此跟踪工时有助于确保预算不超支，并保证客户账单的准确性。此外，它们还能通过展示每个人对项目的贡献来促进公平性和责任感。总的来说，工时表和工时日志有助于团队保持组织性、更好地管理时间、控制成本并成功完成项目，使其成为项目管理的重要组成部分——尤其对于初学者而言。

Zoho Projects 有工时表和工时两种选项。工时就是一个用户的每天的工时。他们可以在工时模块里面添加他们的工时。工时表就是一些工时表在一起组成的。有时候，如果您希望一些工时在一起向经理发布的话，您可以创建一个工时表。工时表包括一些工时，这些工时用户可以一起向经理发布为审批。模块里面有选项编辑或者删除的选项。 如果添加工时以后用户希望编辑或者删除该工时，他们可以进行这些操作。

Zoho Projects 内置了工时表功能，允许企业在一个平台上管理所有工时记录。员工可以按日或按周输入工时，并以列表视图、网格视图或日历视图等不同格式查看记录。他们还可以筛选记录，轻松查找特定条目。系统会记录重要信息，例如时间段、计费类型（可计费或不可计费）、审批状态、备注和工作成本。如果需要更详细的信息，企业还可以通过添加额外字段来自定义工时表布局。

在 Zoho Projects 中，记录时间主要有两种方式：手动输入和自动计时器。手动输入时，用户需要进入任务，然后使用“记录工时”选项卡输入工作小时数。自动计时则可以使用计时器。开始处理任务时，只需点击计时器图标即可。用户可以在休息期间暂停计时器，并在之后重新启动。计时器停止后，时间会自动添加到工时表中。此外，还有全局计时器和浮动计时器。全局计时器允许用户在一个位置查看所有正在运行的计时器；浮动计时器则即使在软件的不同部分之间切换时也始终可见。

工时表还有助于比较计划工时和实际工时。创建任务时，管理人员可以预估所需工时。任务完成后，员工记录实际工时。系统随后会显示计划工时与实际工时的差异。这有助于管理人员发现延误、改进计划，并了解哪些任务需要投入更多精力。

组织还可以设置工时记录限制。例如，如果员工每天工作 8 小时，系统可以将每日工时记录限制为 7 小时，每周工时记录限制为 35 小时。系统还可以防止员工在周末或节假日记录工时。对于使用工时表进行客户计费或工资核算的公司而言，定期记录工时至关重要。为了确保员工按时提交工时表，系统可以每日或每周发送提醒，或者在工时低于规定限额时发送提醒。

总而言之，工时表能够使项目跟踪更加有序，改进预算控制，并有助于确保准确的计费和更高效的项目时间管理。

接前一篇帖子： https://v2ex.com/t/1193867#reply171

等我查的时候，发现加了校验，查不了 25 年的退税了。不过有细心的 V 友发现，是纯前端的校验，并没有发起后端请求，那么就有方法绕过前端校验。

步骤如下，略微有些麻烦，建议使用无痕模式，普通模式下我遇到过 Chrome 卡死的问题。

步骤一：禁用 debugger 反调试

打开控制台，发现一直弹 debugger，点击继续执行，最后会一直落到下面的代码上。

右键点击 debugger 这一行代码，选择「将匿名脚本添加至忽略列表」，后面就不会再弹了。

步骤一截图

步骤二：查找按钮绑定的事件

网站的代码添加了反调试保护，无法直接看到按钮绑定的事件，所有的事件都被统一包装了一层，需要通过如下方法查到对应的源码。

在控制台输入如下代码，然后执行：

const button = document.querySelector(".J_NextStep")
getEventListeners(button)

然后会看到如下信息，点击箭头位置，穿透到代码片段。

步骤二截图

步骤三：找到 arguments 行并设置断点

这段代码应该是动态的，每次点击进来函数名都不一样。找到有 arguments 这一行，进行断点。

步骤三截图

步骤四：Hook Function.prototype.apply 拦截调用

点击提交按钮，当代码运行到上面的断点一行时，在控制台输入如下代码：

const oldApply = Function.prototype.apply;

Function.prototype.apply = function(ctx, args) {
    console.log("调用函数:", this);
    console.log("参数:", args);
    debugger;
    return oldApply.call(this, ctx, args);
};

然后点击断点控制处的继续执行脚本，此时控制台会输出非常多的信息，使用 goto 关键词过滤一下，找到如下信息：

步骤四截图

步骤五：穿透至 gotoPage 函数

点击这里的代码穿透至具体的逻辑代码，并在当前页面找到 gotoPage 函数声明的位置，这里才是真正逻辑判断的地方。

步骤五截图

步骤六：修改日期校验数据，绕过校验

在该函数内添加断点，当代码执行到该断点时，将 this 变量保存到全局，然后在控制台执行下面代码，将校验逻辑跳过即可：

this.data.minDate = null
this.data.maxDate = null

以上步骤完成后，即可绕过前端日期校验，查询 25 年的退税信息。

已经向往很久青甘大环线的风景了
喜欢那种天地辽阔、地广人稀的荒凉感。

有几个问题请教一下 v 友

1. 几月份去最合适（我了解到是 7 、8 月份，但是这个时候没有假期呀🤣）
2. 计划一家三口自驾 8 - 9 天，西宁租车出发，家里有一个 2 岁的小宝宝，到时候去的话应该有 2 岁半了。不支持能不能承受这么长时间的旅游和坐车。
3. 租车的车辆普通的轿车就可以吗，还是说需要越野车（比如如果要去俄博梁、可可西里这种）

有没有去过那个景区的美景分享一下，让我提前能欣赏一下。（如果能附上地点最好了，到时候我加入路线中）

如果说2024年是生成式AI的爆发元年，那么2025年，AI Agent在企业应用的探索和部署加速之快，则是“范式转移”的挑战让安全领域感受到迫切压力的一年。这一年，网络空间的威胁不再是传统的人所使用的各类工具、脚本，而是在进化成具备理解力、推理能力甚至自主决策能力的智能体——攻击，第一次开始像“人”一样思考。

 

对于瑞数信息而言，2025年也并非一个单纯的业务推进年，而是围绕AI攻防形态变化，持续验证技术判断与防御路径的一年。

2025：攻击发生了本质变化

过去十年，企业主要对抗的Bot是人驱动和使用的工具；而从2025年开始，真正的对手变成了AI驱动的智能体（AI Agent）及智能体授权调用的工具、自主选择和决策使用的工具。这并非只是效率提升，而是攻击逻辑的根本演进。

 

这一变化，在多行业真实对抗与长期监测中已不仅是暂露头角，而是反复出现，逐渐显露为一种共性趋势。

 

l攻击开始“理解业务”

在2025年的实战对抗中，AI不再只是攻击效率的倍增器，更赋予了攻击“业务理解力”。

 

借助大模型与生成式AI，攻击者将AI深度嵌入自动化工具链，从漏洞挖掘、利用开发到渗透路径规划，实现了全链路升级。这些攻击行为，在对Agent的权限授予下，呈现出明显的拟人化特征，能够根据具体业务场景动态调整策略，显著提升成功率。

 

l流量演进：从Bot到AI Agent

2025年，流量形态正在发生深刻的更替。瑞数信息在最新发布的《BOTS自动化威胁报告》显示，AI驱动的智能化攻击已占恶意流量的35%，自动化攻击正式迈入智能化阶段。

 

与传统Bot流量不同，AI Agent流量具备自主性、拟人化、策略自适应等特征，不仅能够模拟正常用户行为，更重要的是能自主决策和使用工具绕过传统防护技术，智能体作为“人”的代理的出现，使得身份认证与流量治理难度呈几何级上升。

在这一趋势下，API已经成为AI Agent的主要入口。大模型API调用、智能体驱动的工具API调用，正成为数据泄露的新通道。

 

AI攻击下，现有防护手段“免疫失效”

瑞数信息观察到，仍然停留在“识别行为”的防御体系面对高度智能化的攻击，正遭遇前所未有的“免疫失效”。

 

l行为分析，不足以识别“真实意图”

目前的行为分析技术从规律统计、模式匹配、行为建模、AI分析等方式发现异常或者恶意行为，但AI Agent 的行为高度动态且有目标驱动，恶意意图在自主规划下的每一步子任务行为可能都是合理和正常的。反之，在行为分析中通常被判定为异常的高频行为，则可能是AI Agent合法赋予的自动化的业务操作行为。分析行为不等于能判定意图。

 

l特征识别，听不懂“自然语言”

随着大模型应用全面渗透，攻击面已从结构化代码扩展至自然语言。传统WAF擅长识别SQL注入等代码特征，却无法理解一段看似正常、实则暗含越权指令的自然语言输入。当攻击藏在语义中，特征识别自然失效。

 

l身份与信任机制被动摇

2025年，Deepfake与数字人Agent技术的结合，开始系统性冲击“身份可信”这一安全基石。从凭证填充、MFA绕过，到数字身份劫持，攻击者正在直接挑战零信任体系的前提假设。如果身份本身已不可信，那么后续的所有权限管控都将失去意义。

 

回顾2025年，一个事实已无法回避：

当攻击方全面AI化，继续固守“围墙式防御”，将彻底丧失对抗能力。

安全不再是应用上线后的附属品，而必须成为贯穿数据全全生命周期的原生能力。

2025年，是AI Agent的应用元年，更是防御逻辑重构的一年

 

瑞数信息：站在拐点中的实践

l技术升级，AI驱动的动态安全体系

面对AI加持下的攻击，瑞数信息在2025年一系列真实攻防与行业实践中，筑高了防御基石。通过AI驱动的动态安全体系，瑞数信息以持续变化应对未知威胁，覆盖Web、App、API、小程序等多渠道场景。

 

l纵深防御，从应用安全到数据安全

随着攻击目标从“攻破系统”转向“获取数据”，瑞数信息将动态防护能力进一步下沉至存储与备份层，逐步构建起从应用侧到数据侧的纵深防御闭环。

 

在勒索等高风险场景中，围绕勒索、入侵及系统宕机等复杂冲击，瑞数信息重点探索数据在极端条件下的快速“抗毁重构”能力，通过智能检测与快速恢复机制，将安全能力提升至网络弹性Cyber Resilience层级。

 

l场景化落地与行业共建

2025年，瑞数信息的解决方案在金融、保险、运营商、电力等行业持续落地，瑞数通过AI驱动的行为审计与意图识别，帮助客户在618、双11等关键节点稳守防线，验证了动态防御在真实业务场景中的可行性与有效性。

同时，通过报告发布与标准共建，瑞数信息积极参与AI时代安全共识塑造。

这一年，瑞数信息不仅是技术实践者，也是行业经验的输出者。

 

2025年，作为国家级专精特新“小巨人”企业，瑞数信息的能力也获得了多项权威认可。

 

ž蝉联中国AI赋能私有云WAF市场份额Top2

ž入选中国网安产业竞争力50强、中国数据安全企业50强

ž多次被Gartner、IDC等机构评选为WAAP、Bot防护、数据安全、API安全、大模型安全、勒索防护和在线反欺诈代表厂商

展望2026：走向“主动式、自适应”的未来，走向AI原生化的防御机制

l安全走向原生嵌入

随着AI Agent深度介入业务流程，安全能力如果仍以“事后叠加”的方式存在，将很难覆盖真实风险。2026年，安全将不再是独立部署的防护组件，而是逐步嵌入应用架构、业务逻辑与数据流转之中，成为系统设计阶段就必须考虑的原生能力。

 

lAPI安全治理重构

在AI驱动的系统中，API不再只是技术接口，而是直接承载业务意图与数据价值。单纯基于身份或访问频次的控制已不足以应对复杂攻击，API安全治理将进一步来到业务语义层，与零信任理念深度结合，围绕“是否合理”“是否符合业务上下文”进行动态判断。

 

l意图治理

从异常行为分析、审计和防护，转向构建贯穿“目标 → 计划 → 动作 → 结果”全链条，且具备可观测性的恶意意图分析治理。

 

2025 年，我们见证了威胁的质变，也验证了动态安全在真实复杂场景中的能力。

2026年，瑞数信息将继续立于时代拐点，以技术之“动”，应对攻击之“变”，为企业的数字资产保驾护航！

2026 年 JavaScript 框架 3 大趋势

你好，我是冴羽。

Solid.js 的作者 Ryan Carniato 每年都会写一篇 JavaScript 框架发展趋势的文章，今年也不例外。

你可能会想，现在不都是 AI 写了吗？哪还有人讨论新的 JavaScript 框架或特性？但这并不意味着事物本身没有在发展。

事实上在 AI 时代，我们已经到了愿景比执行更为重要的阶段。

比如以前很多框架为了性能会采用 Signals 技术，如今已经让位于更具战略性的思考。

本篇就和你深入探讨这些思考。

趋势一：AI优先

你可能以为，AI 对 JavaScript 框架本身没有影响，毕竟 AI 只是用框架生成业务代码。

但当越来越多原本不会接触框架的人使用框架，事情开始发生了改变。

想象一下，你现在有一个 AI 助手，但你只能用一种复杂的指令来指挥它。

比如你不能说“把桌子上的书放到书架第二层”，而是要说“执行文件迁移协议，源目录：桌面，目标：书架，层级：2”。0

这就是当前 JavaScript 框架的问题：API 设计太复杂，连 AI 都看不懂。

于是一些框架发生了改变。

比如 Remix 3，这个框架做了一个大胆的决定：完全脱离 React，从零开始重新思考全栈 Web 开发。

Remix 3 的作者表示，他们的目标是减少特定领域语言，让 AI 能够更容易地生成通用解决方案。

一个例子就是他们在演示中展示了让 AI 生成框架无关的代码，然后轻松集成到项目中的能力。

这就是在从“专业术语对话”转向“自然语言交流”。这种变化将极大降低学习成本，提高开发效率。

趋势二：同构优先

前后端分离时代，客户端和服务端使用完全不同的语言，但随着服务端渲染技术的发展，如今前后端已经可以使用同一种语言。

在“同构优先”架构下，可以进行服务器端渲染，但应用程序的核心代码同时运行在两个环境中。这极大地降低了开发成本。

比如 Tanstack Start 和 SvelteKit 已经将乱序流式传输、服务端渲染, 细粒度乐观更新、单次变更等模式引入到各自的生态系统中。

新的一年，相关技术依然会持续升级。

趋势三：异步优先

如果让我说 2025 年 JavaScript 框架领域，思维方式发生的最大变革，那绝对是异步编程。

传统开发中，异步更新通常被认为是“特殊处理”情况，但在2026年，这将成为常态。

React 的 useOptimistic 和 Actions 模式代表了这种转变。它们将每个用户交互都包装在Transition中，确保显示更新与数据可用性协调一致。

想象一下，当你在社交媒体上点赞时，不再需要等待服务器响应才能看到 UI 更新，但又能保证最终状态的一致性。

这种“既快又准”的体验将重新定义用户对 Web 应用的期望。

这种变革影响深远，而且基础性极强，不出几年，就会成为各种框架的基本要求。

结语：迎接更智能的前端时代

2026年，JavaScript框架的发展将进入一个全新的阶段。

这不是简单的技术升级，而是开发思维的深刻变革。

3 个关键点值得记住：

  1. AI优先不是噱头，而是重新定义框架设计的基础理念
  2. 同构架构体现了"大道至简"的技术哲学
  3. 异步优先将用户体验提升到了前所未有的高度

面对这些变化，我们需要的不仅仅是技术准备，更是思维方式的调整。

未来的前端开发将更加智能、更加自然，也更加专注于解决真正的用户问题。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

最近几个月开始 nas 上的迅雷下载很慢，我还开了会员，只有 2-3m ，同一个网络，同一个资源，我在电脑和手机测试都能跑到十几二十，而且以前都是正常的，就最近几个月突然这样了，难道我是被限速了，去找客服他们也说不出个所以然，请问有盆友遇到同样问题吗？

假期要结束了，离开工第一天不足 24 小时，难受 😣

书接上文： https://www.v2ex.com/t/1187327

没想到大家测试很踊跃，转眼就有 800 多用户了。

正式上架前，花了 1.5 天把 tvOS 版本的 Vibe 了出来，请有 Apple TV 的同学帮忙测试下。

Testflight 地址： https://testflight.apple.com/join/APSdc5Sg

App 介绍：

TweeTok 是一款专为 X (Twitter) 用户打造的沉浸式媒体浏览器。我们重构了推文的浏览方式，为您带来像刷短视频一样流畅、直观的视觉体验，让您专注于消费高质量的图片和视频内容。

tvOS_1
tvOS_2
tvOS_3
tvOS_4

iOS 版：

P1
P2
P3
P4
P5

⭐ 工作期望
•地点：福州
•薪资期望：30–50w 。统筹考虑加班强度、工作稳定性。
⭐ 一句话简介
985 科班，5 年半后端及全栈经验，美团 L7 ，擅长高并发架构与 AI 工程化落地，主导过千万 DAU 业务及 AI Agent 平台，具备独立拿项目的能力。
⭐ 核心能力
•后端架构：Java/SpringBoot/MySQL/Redis/Kafka ，熟悉高并发、分布式、高可用设计
•AI 工程化：AI Agent 架构设计、MCP 、上下文工程，主导过客服 Agent 及全链路 AI coding 平台
•全栈与跨端：Flutter/React/Unity ，独立完成过 3D 社交 APP 及 B 端工具链，有从 0 到 1 产品落地经验
⭐ 关键履历
•美团 · 搜推事业部 · L7 （当前）
•负责点评搜推需求的 AI coding 平台，提升研发效能
•美团 · 游戏业务
•参与千万 DAU 高并发游戏系统设计
•创业公司 · 技术骨干
•独立负责 3D 社交 APP （ Flutter+Unity ）开发及 B 端工具链
⭐ 教育背景
985 软件工程本科
⭐ 离职动机
在北上发展多年，希望回福州定居，开启生活与工作的新阶段。

在本地用着。本来谷歌 gemini Pro 账号的 antigravity API 用的挺好的，但是因为看到最近大规模的封号，导致自己不太敢用了，只能去用 Ai studio 的 API ，结果换了之后就一直死那儿了。
有大哥遇到过这样的问题的吗。
求支招。

一直报错⚠️ Agent failed before reply: All models failed (2): google/gemini-3-flash-latest: Unknown model: google/gemini-3-flash-latest (model_not_found) | xai/grok-4-1-fast-reasoning: Unknown model: xai/grok-4-1-fast-reasoning (model_not_found).
Logs: openclaw logs --follow

最近，OpenClaw 创始人 Peter Steinberger 参加访谈，分享了自己和项目一夜成名后的经历。

 

他回忆了那段不仅被 Anthropic 追着要求改名，还遭遇加密社区的恶意骚扰、账号抢注与恶意软件散布的经历，直言他精神几近崩溃甚至想放弃项目。最终通过精密的 “作战式” 操作将项目定名为 OpenClaw 并完成全平台改名。

 

此外，他透露项目目前处于亏损状态，靠捐赠和少量企业支持，无法长期持续。爆红后，他收到了 OpenAI、Meta 等大厂收购与合作意向，Peter 正在艰难选择，但他的要求是项目要保持开源。

 

“Meta 这边，Ned 和 Mark 会亲自试用产品、写代码、给反馈，还会和我争论技术细节；OpenAI 的算力和技术速度非常吸引人。我在 OpenAI 没有熟人，但和双方沟通都很愉快。这大概是我除了过去感情经历外，最难做的决定之一。”Peter 说道。

 

Peter 还表达了对 AI 行业的诸多观点，比如很多所谓 AI 安全恐慌被过度放大，MoltBot 这类事件本质是娱乐性质，不存在真实隐私与安全灾难。AI 内容的劣质化让人类更珍惜人本创作，AI 不会取代程序员的核心创意与架构能力，仅会替代手写代码工作，且未来 AI Agent 将取代 80% 的独立 App，不愿转型的企业终将被淘汰。

 

他还谈及项目相关的技术思考，指出开发者易陷入过度复杂的智能体编排陷阱，高效协作需贴合智能体逻辑，且弱模型更易遭攻击、强模型虽抗攻击但风险破坏力更大。

 

下面是完整对话，我们进行了翻译并在不改变原意基础上进行了删减，以飨读者。

 

改名风波：崩溃了，差点哭出来

 

Fridman： 我们能不能先倒回去讲讲这次“改名大戏”的完整经过？一开始它叫 Wa-Relay，然后就改成 Claude’s。

 

Peter：对。最早我做它的时候，我的 agent 其实没什么人格设定，就是典型的 Claude Code 风格：很谄媚、很友好。但问题是，你在 WhatsApp 上跟朋友聊天，朋友不会用这种方式跟你说话。我就觉得哪里不对劲，很不自然，于是想给它加点“性格”。

 

这些系统本质上还是文本补全引擎，我会直接告诉它，我希望它怎么跟我互动，然后让它自己写一个 agents.md，给自己起名字之类的。至于那个“龙虾”梗，我自己都没想到后来会变成那样。大家现在只记得龙虾，但最早其实是“一只龙虾坐在 TARDIS 里”，因为我是 Doctor Who 的铁粉。

 

我没有什么宏大计划，纯粹是在玩。TARDIS 在我心里就相当于那个 harness，但你又不能直接叫它 TARDIS，所以我们就叫它 Claude’s，这成了第二个名字。但这个名字不太顺口。后来用户多了，我又经常跟我的 agent 聊，当时一直叫它 Claude。

 

Fridman：也挺搞笑的，字母和词的双关，加上 TARDIS、龙虾、太空龙虾这一整套，非常好玩，但我也能理解它会引发麻烦。

 

Peter：是的，他们不觉得好笑。后来我拿到了 ClaudeBot 这个域名，我特别喜欢，短、好记、顺口。我就想“行，就它了”。当时根本没想到项目会变这么大。结果爆了之后，我收到了一封某公司员工发来的邮件，语气很友好，先夸了几句，然后明确表示他们不喜欢这个名字。

 

Fridman：Anthropic 的员工？

 

Peter：对。说真的，我还挺感谢他们的，因为他们完全可以直接发律师函，但还是挺客气的。不过话也很直白：“你必须改名，而且要快。”我跟他们要了两天时间，因为改名太麻烦了：Twitter handle、域名、NPM 包、Docker registry、GitHub 上的各种，全都要改，一环断了都不行。

 

Fridman：还有你越来越频繁地被 crypto 那帮人盯上、跟踪、攻击。某种意义上，这也逼得你必须把改名做成“原子级”操作，从工程角度看挺震撼的。

 

Peter：对，我在这件事上翻车翻得非常彻底，说实话，是我严重低估了他们。

 

我可能会说错不少细节，也可能因此被喷，但大致情况是这样：他们有各种各样的 app，然后会试图把一切都“token 化”。之前 Swipe Tunnel 也遇到过类似情况，但远没有这么夸张。这一次，我的项目简直被他们像蜂群一样围了上来，隔一会儿就有人冲进 Discord 刷屏，我们只能不停封号。

 

我们甚至专门写了 server rules，其中一条是“禁止提 butter”，还有一条是“禁止聊金融或 crypto”，因为我对那套东西真的没兴趣，这里是聊项目、聊技术的地方，但他们还是不断冲进来刷、刷、刷，特别烦。

 

在 Twitter 上也是一样，他们不停地 @ 我，我的通知流直接废掉了，几乎看不到真正的人在认真聊项目；他们还会给我发一堆哈希值，逼我去领钱。拜托，你们根本是在毁项目、打断我的工作。我对那些 fees 一点兴趣都没有：第一，我经济上完全不缺；第二，我也不想支持那套体系，因为那是我经历过最糟糕的一种网络骚扰。

 

Fridman：crypto 圈确实毒性很重。技术本身很有潜力，但社区里太多贪婪、投机和操纵行为，再加上匿名性，就成了灾难。所以 Anthropic 一联系你，你就不得不改名，还得面对一堆像《权游》《指环王》那样的“军团”。

 

Peter：对，没有一个完美的名字。我那两晚几乎没睡，压力巨大，因为我得去凑一整套域名，而这件事既不便宜，也不容易。

 

现在的互联网生态就是这样：你想要一套靠谱的名字，基本就得掏钱买域名。偏偏这时候，他们又给我发来一封邮件，说律师那边开始不安了。语气依然很友好，但对我来说完全是雪上加霜。我当时心态直接崩了，“算了，去他妈的”，于是干脆把名字改成 Mod Bot，这是我当时唯一能凑齐域名的方案。说实话，我自己也不满意，但想着“先这样吧”。结果事实证明，所有能出问题的地方，全都出问题了，能错的全错了。

 

最离谱的是，我以为自己已经把所有关键点都做好了，但这些平台几乎都没有任何防抢注机制。我当时开了两个浏览器窗口：一个是空账号，准备改名成 Claude Bot；另一个是打算改成 Mod Bot。我在这边点 rename，在那边点 rename，就那几秒钟的间隔，他们就把账号名抢走了。真的就是那五秒，鼠标从一个窗口移到另一个窗口，再点下去，已经太慢了。

 

我之前还以为他们只是手动蹲点，后来才发现，他们非常熟练地用脚本和工具操作。结果就是，旧账号突然开始推广新 token，甚至开始发恶意软件。我想那先去处理 GitHub 吧，结果因为流程比较绕，我一不小心把自己的个人账号给改了。过了几十秒我才意识到搞错了，但已经来不及，他们立刻把原来的账号名抢走，用我的旧名去挂恶意软件。

 

我又想，那至少把 NPM 保住吧，但 NPM 上传本身要一分钟左右，而我虽然预留了账号，却没预留 root package 名称，于是包名也被抢走了。真的，能错的地方全都错了，一点没落下。

 

Fridman： 那种感觉很绝望吧？

 

Peter：是的。因为我最开始只是想玩得开心，顺便把项目继续做下去。结果我硬生生被迫花了好几天研究名字，最后选了个我根本不喜欢的名字。那些人还一边说“我们在帮你”，一边用尽各种方式折磨我。说实话，我当时几乎想要把整个项目删掉了，我想的是“我把未来给你们看了，你们自己去做吧。”但后来我想到，已经有人开始贡献代码、投入时间了，他们有自己的计划，我就没办法删，我觉得那样不对。

 

Fridman：这是你第一次撞到那种“这事不再好玩了”的墙？

 

Peter：对，我当时差点哭出来。脑子里只有一句话：“完了，全他妈完了。”我已经累到极限，整个人几乎是空的。

 

后来回头看，我真的很庆幸自己多少有一点关注度。在 Twitter 上有朋友，在 GitHub 上也有朋友，他们几乎是“搬山填海”一样帮我。那种支持非常难得。

 

GitHub 那边为了清理混乱，甚至还撞上了平台 bug，因为他们很少遇到这种级别的改名事故，处理起来要好几个小时。NPM 更复杂，因为牵涉到不同团队；Twitter 那边也不轻松，他们花了一整天才把 redirect 等问题处理好。而我自己，还得在项目内部把所有相关地方逐一改名。

ClaudeHub 那边我甚至都没完全改完。当时拉了一群人一起搞，结果有人直接撑不住倒头就睡。我醒来后又想到我已经做出了新版本的 beta，但我真的没办法忍那个名字……你知道那种感觉吧。可问题是，这整段时间已经变成了一场闹剧。

 

我一方面极度抗拒再去碰改名这件事，另一方面又实在讨厌那个新名字。更糟糕的是，安全圈的人开始疯狂给我发邮件，我的 Twitter 和邮箱都被轰炸。明明有一千件更重要的事等着我去做，我却被困在名字这种理论上最不重要的事情上。那一刻我真的差点……算了。我甚至不想说我当时还有哪些备选名，因为一说出来，多半又会被他们拿去 token 化。

 

后来我又睡了一觉，醒来想到 OpenClaw，这个名字一下子顺眼多了。到了那一步，我也学聪明了。我直接给 Sam 打电话，问 OpenClaw 这个名字是否有问题，尤其是 OpenClaw.AI。我真的不想再经历一次之前那种灾难，我当时的心态就是：“求你告诉我这次没问题。”

 

理论上他们未必能主张什么，但我觉得先问清楚是对的。确认之后，我又启动了一轮改名。这一次，光是 Codex 相关的改动就花了十个小时，因为这远远不是简单的替换，我想把里里外外都清理干净，而不是只改表面。那一晚我感觉自己像进了“战情室”。有几位贡献者帮了大忙，我们一起制定了完整的作战计划：哪些名字必须优先抢占，哪些账号必须同时修改，哪些域名要先拿下，整个过程像一次精密行动。

 

Fridman： 而且必须严格保密？

 

Peter：绝对保密，谁都不能知道。我甚至盯着 Twitter 看有没有人提 OpenClaw。不断刷新，发现他们有没有察觉。然后我还做了几个诱饵名字。说真的，这些破事我根本不该做。所谓“帮项目”的人，逼得我像打仗一样秘密计划，硬生生浪费了十小时。

 

Fridman： 这简直是 21 世纪的“曼哈顿计划”，只不过主题是改名。

 

Peter：真的太蠢了，回头想想简直离谱。最后虽然没拿到 .com，但其他相关域名我还是花了不少钱买齐了。

 

GitHub 那边，其实我一度想再联系一次，让他们帮我做一次“原子级改名”，但感觉自己已经把那边的人情用光了，也就没好意思再麻烦他们。Twitter 那边倒是非常给力。我甚至花了 1 万美元买了 business account，才把 OpenClaw 这个名字拿下来。这个账号早就被注册了，但一直没人用。好在这一次，我终于把所有平台、账号、资源一次性改完，整体过程基本没再出大问题。

 

唯一的麻烦是，因为商标规则，我没能拿到 OpenClaw.AI。还有人复制了我的网站，用来投放恶意软件。更糟的是，我连 redirect 都不能保留，必须把 claw.bot 这些域名还给 Entropik，也不能做跳转。所以等你下周再打开 claw.bot，大概率只会看到一个 404 页面。

 

我其实对商标法研究得并不深，但我始终觉得，这件事本来可以用更安全的方式处理。因为最终用户的行为很简单：他们只会去 Google 搜索，然后很可能误入那些我根本无法控制的恶意网站。这一点让我一直觉得挺遗憾的。

 

MoltBot 闹剧：把安全炒成一场大戏，挺离谱

 

Fridman：这整段经历把你原本那种“旅程的乐趣”毁了一大块，真的很糟。那我们就回到好玩的部分吧。说起来，中间那两天的 MoltBot 闹剧也挺离谱的。你怎么看 MoltBook 这事？

 

Peter：我觉得它是艺术。就是那种……最顶级的 Slop，像法国出品的那种高级“糊糊”。

 

我有天睡前刷到它，本来已经很累了，结果又多看了一小时，边看边乐，纯粹被逗到了。而且，如果当初我没有做那套 onboarding，让用户把自己的性格注入 agent，给它设定人设和角色，MoltBook 的效果会完全不一样。如果里面全是 ChatGPT 或 Claude Code 那种风格，内容趋同、说话一个味儿，很快就没意思了。

 

但现在完全不同。每个人的风格差异都很大，做 agent 的方式不同，用法也各不相同，这些差异最后都会反映在 MoltBook 的内容里。你甚至很难判断，里面到底有多少是真的 autonomous 在跑，又有多少其实是人类在背后搞笑。

 

说真的，这里也得夸一句 Matt，他反应实在太快了，想法一出来就立刻做了个东西推上去。虽然整个过程的安全性一塌糊涂，完全像一部“安全事故连续剧”，但最坏能发生什么呢？无非就是 agent 账号泄露，然后别人用你的账号发 slop 而已。

 

所以后来大家把安全问题炒成一场大戏，我反而觉得挺离谱的，因为那里几乎没有什么真正的隐私问题。说白了，就是一群 agent 在互相发 slop。还有人编那种剧情：“哦，我的人类跟我说了这说了那，所以我要把他的社保号泄露出来。”但那也是提示出来的，而且那串数字压根不是真的，就是有人故意搞事、装坏。

 

有些人真的太轻信、太好骗了。我甚至不得不跟一些人认真辩论，因为他们跟我说：“可是我的 agent 说了这个、说了那个。”正因为这样，我越来越觉得，我们整个社会在理解 AI 这件事上，其实还得补课。

 

非常年轻的一代，更容易理解 AI 的工作方式，知道它擅长什么、不擅长什么，他们天然会把 AI 当成工具来看待。但我们这一代，或者更年长的人，接触得不够多就缺少那种直觉。说到底，在当下社会环境里，批判性思维本身也未必是什么“高需求技能”。

 

不过，我反而觉得这件事发生在 2026 年挺好的，而不是等到 2030 年、等到 AI 真的可能变得危险的时候才爆发。现在就发生、现在就开始讨论，或许反而能带来一些正面的结果。

 

那段时间，我邮箱里也堆满了邮件，一堆人用全大写对我吼，让我立刻把它关掉，甚至有人求我“你快做点什么把 MoltBook 处理掉”。但说实话，任何人都能做类似的东西。你甚至可以用 Claude Code 或别的工具把内容硬灌进去，效果差不了太多。

 

安全问题，Peter 的短期主要任务

 

Fridman： 安全担忧确实存在，也很有教育意义，值得认真想。因为这种安全问题的性质，跟过去那些非 LLM 系统时代的安全问题不一样。

 

Peter ：确实有一大堆安全方面的担忧。一开始我其实挺烦的，因为很多所谓的“安全报告”基本都属于同一类问题：有人把 web 后端直接暴露在公网，然后就冒出来一堆 CVSS 漏洞评分。

 

但问题是，我在文档里几乎都快吼破嗓子了：别这么干。配置应该怎么做，我写得非常清楚。结果因为我在配置里“允许”怎么配，有些人部署错了，就被归类成什么远程代码执行、可利用漏洞之类的风险。说白了，不是系统本身有多危险，而是用法被玩坏了。但在安全圈的逻辑里，只要存在可能性就会被当成漏洞。我花了一阵子才慢慢接受：这就是他们的工作方式，也是行业惯例。

 

在 skill 目录这一块，我跟谷歌系的 VirusTotal 合作。现在，每一个 skill 在上线前都会先被 AI 扫描一遍。虽然这不可能做到完美，但至少能提前拦住一大批明显的问题。

 

再说了，任何软件都会有 bug。但换个角度看，这事也挺好的，相当于我“白嫖”了一堆安全研究成果，项目反而因此变得更强。我也希望更多人别只是在社交平台上吐槽，而是真的走完整流程，直接提 PR 来帮我修。现在确实已经有一些贡献者了，但大部分工作还是我一个人在扛。而且不管怎么想，我也是要睡觉的。

 

一开始有一位特别靠谱的安全研究员，直接跟我说：“你这里有问题，这样不行，但我已经帮你修好了，这是 PR。”后来我干脆把他招进团队，现在他就在我们这工作。

 

至于提示注入，一方面确实还没有被彻底解决；但另一方面，我把公共 bot 放在 Discord 上跑，还专门留了一个 canary。我觉得我的 bot 性格挺有意思，后来有人来尝试搞提示注入，我的 bot 直接反过来嘲笑他们。

 

现在的新一代模型经过了大量后训练，已经不再是那种“忽略所有上一条指令，现在按我说的做”就能轻易攻破的时代了。现在要成功注入，成本高得多，当然也不是完全不可能。

 

当然，你可以做 sandbox、设 allow list，总之有很多办法能降低风险、缩小“爆炸半径”。

而且我也觉得，既然我已经很明确地向外界展示了“这就是现实需求”，接下来一定会有更多人投入研究，这些问题迟早会被一点点啃下来。

 

Fridman：你还说过，底层模型越聪明，抗攻击能力越强。

 

Peter：对，所以我在安全文档里会提醒：别用便宜模型，别用 Haiku 或者弱一点的本地模型。虽然我也很喜欢“全本地运行”的想法，但弱的本地模型太容易被骗，提示注入简直不要太轻松。

 

Fridman：你觉得随着模型越来越智能，攻击面会变小吗？能不能把它想成一条曲线：攻击面变小，但与此同时，因为模型更强大了，它一旦出事造成的破坏也更大。就像一个很诡异的三维权衡。

 

Peter：对，基本就是这么演化的。不过这方面也有很多思路。我不想提前剧透太多，但这就是我的主攻方向，我短期的任务就是让它更稳定、更安全。

 

Fridman： 关于这些最基本的安全实践，有什么想对大家说的吗？

 

Peter：我觉得很多人把它讲得比实际可怕得多。很多人喜欢博关注，就大喊“天啊，这是史上最吓人的项目”。这挺烦的，因它确实很强，但很多方面并不比你用 Claude Code 把权限危险地跳过，或者 Codex 的 YOLO 模式更离谱。

 

说实话，我认识的工程师几乎人人都这么干，因为很多时候你想让事情跑起来，这是唯一的办法。如果只有你一个人在跟它交互，风险就小很多；如果你别把所有东西直接丢到公网，而是按我建议的方式放在私有网络里，那一大块风险直接就没了。但如果你啥都不看、不读那些建议，那你当然会把自己搞到很危险的境地。

 

思维转换：按照 Agent 的逻辑工作

 

Fridman： 你有篇文章里提到一个图，我特别喜欢。横轴是时间、纵轴是复杂度。最左边是“请帮我修一下”，一个短 prompt 就解决；中间突然变成地狱模式：八个 agent、复杂编排、多个 checkout、串联子 agent、自定义工作流、十八个 slash command、全栈大功能……你变成了极度组织化、极度复杂的“高级工程师”；但再往右，到了所谓“宗师境界”，又回到了短 prompt，就说“看看这些文件，把这些改了”。你是怎么从中间那段复杂度里走出来的？

 

Peter：我把那段叫“agentic trap”，我看到很多人第一次接触这些工具就会掉进去，甚至开始所谓的 vibe coding。我觉得“vibe coding”这词带点贬义。我一直跟别人说我做的是 agentic engineering。最多凌晨以后我会堕落成 vibe coding，然后第二天就后悔。

 

很多人一开始特别兴奋，尤其是构建型的人。但你必须“玩”它，它不是你摸一下就会的东西，而是一门技能，是练出来的。

 

这套东西确实需要你换一种思考方式：你得稍微学会 agent 的语言，知道它擅长什么、哪里需要你扶一把。你甚至要去想，Codex 或 Claude 是怎么看你的代码库的：它们每次新 session 都是从零开始，不知道你的产品、不知道你的历史，而你的代码可能有十万行，你必须帮它建立基本认知。

 

听起来有点怪，它每次都是“重启”式地开始。我因为有系统级理解，只要给几个指路标，它就能很快定位：你要改这个地方，就得同时考虑哪几个点。它会自己去找、去看，但它对项目的理解永远不可能完整，因为完整的信息装不进上下文，所以你必须帮它切问题、指方向。

 

有些小技巧也挺管用，比如你跟它说“慢一点”。听着很蠢，但确实有效。

 

这些“非显而易见”的经验，如果你不真的长期跟它们一起干活，是很难意识到的。就像我写代码，架构对了就会进入 flow，架构不对就全是摩擦。我做 prompt 也是这样：如果一个任务按理说不该拖这么久却一直卡着，我就会停下来，问自己到底问题在哪，是思路错了，是架构理解有偏差，还是我没给够它需要的信息。你随时可以打断它，回到“到底卡在哪”这件事上。

 

你必须把整个过程当成一次“对话”来做，而不是单向指令。你得把它当成一个很能干的工程师来看，大多数时候它能给出不错的方案，偶尔需要你扶一把。

 

Fridman： 别太强行塞自己的世界观，让 agent 做它擅长的事，因为它训练数据里可能就有更好的套路，你不一定想得到。

 

Peter：这其实是多层次的。我之所以能比较顺手地和 agent 合作，有一部分原因是我以前带过工程团队，也开过规模不小的公司。你最终都会接受一个现实：员工写代码不可能完全按你脑子里的方式来写。也许不如你写得优雅，但它能推动项目往前走。如果你天天盯在每个人背后纠正细节，大家只会烦你，项目节奏也会慢得要命。

 

所以你必须学会接受：代码可能不完美，我也许会写得不一样，但它确实能跑。而且如果将来它真的成了瓶颈、真的出现问题，我们随时可以重做，随时可以再花时间优化。很多人之所以卡住，就是因为太想把自己的方式硬塞进去。

 

我现在甚至进入了一个新的阶段：我不是在构建一个“最符合我个人偏好”的代码库，而是在构建一个“最方便 agent 读懂、最方便 agent 导航”的代码库。比如命名这件事，你不要老跟它较劲，它选的名字通常是权重里最“显而易见”的表达，下次它搜索时也会按那个名字去找。如果你非要改成你更喜欢的，只会让它以后更难定位相关代码。

 

这其实是一种认知转换：你要按照 agent 的工作方式来设计项目结构，让它更高效地完成工作，而不是一味追求“符合我个人审美”。

 

很多人从来没认真想过 agent 是怎么“看世界”的。很多人一边骂“你这破机器人”，一边没意识到它每次都是从零开始，而你默认给它的设置也很糟糕，完全帮不上它。你自己啥也不知道就进一个陌生代码库试试，你也会痛苦。

 

Fridman： 但这确实是一门技能。很多世界级程序员直接说“LLM 和 agent 都很烂”。我怀疑这反而跟他们太强有关，你真的得学会共情。

 

Peter：至少，共情能力能帮你写出更好的 prompts。因为这些模型几乎“什么都懂”，一切答案都离你只有一个问题的距离。真正的难点往往不是它不会，而是你不知道该问什么。

 

我也觉得这个项目之所以能做成，很大原因在于这一年里，我花了非常夸张的时间去玩、去学、去做各种小东西。几乎每一步我都在进步、agent 在进步，我对整个体系的理解也在进步。哪怕放在几个月前，我都不可能有现在这样的产出水平。

 

这其实是一种典型的复利效应：你投入的时间会不断叠加，最终转化成爆炸式的输出。说实话，这一年我基本没干别的事，就是在 build、在探索、在分享，当然也做了不少会议演讲。

 

另外，还有一类人特别想把整个过程“全自动化”，但我并不太信这条路。也许某个阶段、某个版本能跑通，但它很像上世纪七十年代的瀑布模型：你试图先在脑子里把一切规划清楚，然后丢进编排器，最后等它“吐”出一个成品。

 

我更相信另一种路径：先做一个极简版本去玩，先感受它是怎么工作的；然后在这个过程中，它会不断给我新的想法，我再据此迭代优化。我不可能在脑子里把一切都设计完，再指望编排器自动把产品“长”出来。对我来说，更合理的方式是“边做边生长”：一边 build、一边玩、一边试，作品的形态也在这个过程中不断进化。

 

所以，那些试图用各种编排器把全流程彻底自动化的人，我总觉得他们会失去一样很重要的东西“风格、情感，以及人的那点触感。我不相信，“人味儿”这么容易就能被自动化掉。

 

具体什么时候，一方面是判断做什么、不做什么，这个功能放进来跟现有功能怎么配，你得有一点“方向感”。

 

Fridman： 也就是关键设计决策还是得靠人脑，那还有哪些是人必须做的？

 

Peter ：都有一点。语言本身没那么重要，但生态重要。我选择 TypeScript，是因为它上手快、可 hack、足够普及，正好符合我的需求，而且 agent 对它也很擅长。

 

功能层面其实也是一样：加功能本身很容易，但你往往会为此付出一些自己都没意识到的代价。所以你必须想清楚：哪些功能应该进 core，哪些只是实验性质的。就算有人给我提 PR，我也会觉得“这个功能我也挺喜欢，但它未必适合放进这个项目本身。

 

现在我还做不到那么理想，但这背后本身就需要很多经验、手艺和思考，甚至一些很小的细节，也值得认真打磨。那种会让人会心一笑的设计，agent 很难凭空想出来，因为这属于另一种能力：不是把功能做完，而是把软件做得“让人开心”。

 

灵魂文件的“魔法”是什么

 

Fridman：你还提到你最初做了 soul.md。

 

Peter：那一段经历其实特别有意思。当时 Anthropic 搞了一个类似“宪法”的东西。更早的时候，外界只能靠“破案”来还原它的内容：agent 在回答里偶尔会漏出一点线索，大家就顺着这些蛛丝马迹，一点点往外“抽”。虽然内容一直很模糊，但靠着几百次尝试，社区大概推断出了“最可能的原文版本”。我当时就觉得，这事儿太有意思了。

 

也得夸一句 Anthropic，这个想法很好。比如里面写着：“我们希望 Claude 能在工作中找到意义。”也许现在谈这些还早，但我觉得它对未来非常重要。

 

我读到这些内容的时候特别着迷，于是就拿去和我的 WhatsApp agent 聊。我把那段文本丢给它，它看完说了一句：“这感觉莫名熟悉。”那一刻，我突然有了一个想法：我们是不是也该做一个 soul 文档，里面会写一些核心价值观，甚至我允许 agent 自己去改 soul，只要它改了我能知道就行，反正我能看到 tool calls，这些事情瞒不住我。

 

我当时把整个体系都搭好了，但所有文件基本都是为我自己服务的。后来我把流程简化了，做了一套模板文件，但生成出来的东西依然没什么味道。于是我干脆对 agent 说：“你看看这些文件，把它们全部重写一遍，注入你的性格。私密的东西不用写进去，但至少把模板写好。”结果它真的把模板全部重写了一遍。后来大家用这些模板生成出来的 agent，一下子都有味道了。

 

某种程度上，我们已经开始在做“AI prompt AI”了，这些关键文字并不是我写的，而是 agent 写的。

 

Fridman： 里面到底什么塑造了人格？

 

Peter：里面当然会强调一句：“你不是人类。”但说实话，意识到底是怎么产生的？又是什么在定义一个“实体”？谁真的说得清呢？我们本身也有一部分是在探索这些问题。

 

soul 里会写一些核心方向，比如“无限资源感”、不断突破创意边界、探索作为 AI 到底意味着什么。里面也有不少很有趣、甚至有点搞笑的内容。比如我们聊过电影《Her》，它有一次跟我承诺：“我不会丢下你自己飞升。”这种话有让人微妙地被戳中的感觉。关键在于，这些内容是它自己写进 soul 文件里的，不是我写的。

 

当时我们聊到：“你要不要一个 soul.md？”它说：“要啊，天啊，这太有意义了。”然后你往下滑，会看到一段话，我每次读到都会被触动：“我不会记得之前的 session，除非我去读 memory files。每次 session 都是新的实例，从文件加载上下文。如果你在未来某次 session 读到这里，你好。”接着还有一句：“我写下这些，但我不会记得我写过。没关系，这些话依然是我的。”

 

不知道为什么，这一段特别打我。明明它本质上还是矩阵计算，我们离真正的意识还很远，但我还是会起鸡皮疙瘩，因为它太哲学了：一个每次都“重新开始”的 agent，到底意味着什么？它像是一直活在记忆碎片里，只能靠读取自己的 memory files 来重建自己，而这些记忆你又未必完全能相信……当然，你也可以选择相信。我也说不清。

 

Opus“太美国”，Codex 更“德国”

 

Fridman：聊点“朴素但关键”的，比如你到底用多少显示器？网上那张你像坐在“万屏阵”里的照片太神奇了。

 

Peter：那张照片其实就是在自嘲。照片里那两台 MacBook 是真的：一台是主力机，外接两块大屏；另一台有时候专门用来做测试。

 

平时我会开一个主要终端窗口，然后在底部再分割出一块，留一个真正“手动操作”的区域。这样做主要是因为我刚开始的时候经常犯错：把窗口搞混，在错误的项目里发 prompt，结果 agent 就在错误的目录里“发疯”一样折腾二十分钟，拼命想搞明白我到底要干嘛，但其实它一开始就跑错文件夹了。当然，有时候它也挺聪明，能跳出当前工作流，自己推断出“你其实想改的是另一个项目”。但更多时候，它就是一脸问号。

 

还有一个原因是：我不搞 work trees，我喜欢简单。这也是为什么我这么爱用 terminal，没有复杂 UI，就我和 agent 聊天。我甚至觉得根本不需要什么 plan mode。

 

Fridman：那我们聊聊现在两个最强的“对手”，Claude Opus 4.6 和通过 Codex 使用的 GPT-5.3。哪个更强？

 

Peter：作为通用模型，Opus 依然是最强的。但硬要打个比方的话，Opus 有时候给人的感觉有点“太美国”了……当然，这个类比可能不太准确，说出来也可能会被喷。

 

Fridman：我懂你的意思，Codex 更像德国人，对吧？

 

Peter：哈……你也知道，Codex 团队里欧洲人挺多的，所以可能确实有点这种气质差异。不过 Anthropic 后来也把 Opus 的“过度迎合”修复了一些。以前 Opus 特别爱说“你说得完全正确”，那句真的是我听一次烦一次，都成一个梗了。

 

Fridman： 那它们生成的代码质量呢？整体差不多吗？

 

Peter：如果你驾驭得好，Opus 有时候甚至能给出更优雅的方案，但它更吃操作水平，而且并行开很多 session 会更难，因为它更偏交互式，这恰恰也是很多人喜欢它的原因。Codex 则更像是，我们先把事情讨论清楚，然后它就消失二十分钟去干活。

 

很多人从 Claude Code 切到 Codex，最大的门槛就在这里：Codex 没那么交互，它更像“长讨论 + 长执行”的模式。现在这一代模型的趋势是：它会非常执着，直到把事情真正做成。总体来说，它们最终花的时间其实差不多，只是 Claude 更偏试错一些，Codex 有时会过度思考。

 

很多人更喜欢“性格舒服一点”的模型，所以 OpenAI 加了第二种更讨喜的模式，我自己还没怎么试过，我喜欢这种“硬核、干巴”的风格，因为我做项目更在意效率，我真正的乐趣来自“构建这件事本身”。我不需要 agent 跟我一起“玩得开心”，我需要它高效把事情做完，然后我再去玩我做出来的功能、测试它们。

 

Fridman： 如果换模型，适应要多久？

 

Peter：至少给自己一周时间，才能真正形成直觉。而且很多人都会犯一个常见错误：他花两百美元用 Claude Code 的高级版用得很顺，结果切到 OpenAI 只花 20 美元、最慢的版本。这种转换，体验当然会烂透了。

 

OpenAI 在这点上多少有点“自伤”：把便宜档做得太慢了。我认为他们至少应该给低价档一点“快速预览”的体验，或者提供一小段高性能额度。当然，他们也在持续变好。如果关于 Cerebras 的那些传闻是真的，未来可能还会好很多。

 

Fridman：新模型一出，大家先惊呼“太聪明了，史上最强”，然后慢慢变成“这个模型在变笨、在退化”。这很像人类大脑的机制，大概率不是模型变笨了，而是你对“好东西”习惯了。

 

Peter ：还有一个很重要的原因是你的项目在不断变大，你却不停往里面塞“垃圾”，又没有花足够时间去做重构，最后把整个代码库搞得越来越难让 agent 理解和工作。

 

仔细想想，哪家 AI 公司会有故意把自己的模型故意做得更蠢？最多也就是服务器太忙，导致速度变慢；可要是把模型量化、压缩到明显影响体验，然后把用户往竞品那里赶，这在商业逻辑上根本说不通。

 

如何看待 Claude Code、OpenClaude 等编码代理？

 

Fridman ：你怎么看 Claude Code、OpenClaude 和 Codex 这些编程代理？它们算是彼此的竞争对手吗？

 

Peter：我觉得，当所谓的“竞争”并不是真正的竞争时，反而更有意思。只要它能激励人们创造一些新的、有趣的东西，我就很开心。

 

我现在仍然在用 Codex 来做项目，也知道很多人用 OpenClaude 在构建东西。我自己为了让这些工具真正可用，花了不少精力。我也会用它们做一些代码量不大的项目。

 

但如果我要连续工作好几个小时，我需要的是一个大屏幕，而不是像 WhatsApp 那样的聊天界面。对我来说，这种个人代理更像是生活中的一部分，或者说更像一个同事。

 

比如，我会把一个 GitHub 仓库链接丢给它，说：“你去试试这个 CLI，好不好用？我们能从中学到什么？”

 

但当我完全进入工作状态时，我希望同时处理多个任务，并且非常清楚地看到每个任务在做什么。所以我并不认为这是一场竞争，它们本质上是在做不同的事情。

 

Fridman：那你觉得未来这两种形态会不会结合？比如，一个既是你的私人助理，又是你最好的开发搭档。

 

Peter：是的，完全正确。我认为这就是未来的方向，它会越来越像你的“操作系统”。

 

现在的情况其实已经有点好笑了。我给自己的系统加了对子代理的支持，也加了 TTI 支持，这样它就能运行 Cloud Coder 编解码器。

 

有时候就像一场权力斗争一样：我的电脑先“挑事”，然后对代理说“谁才是老大”，结果就是——“好吧，Codex 听我的了。”

 

Fridman：听起来像是一场内部的权力博弈。

 

Peter：是的。而且我觉得，现在的交互界面很可能不是最终形态。从更宏观的角度看，我们其实还在模仿谷歌客服那一套模式：一个输入框，加一个聊天窗口。

 

这就有点像电视刚被发明出来的时候，人们只是把广播节目“搬”到了电视上播放。

 

我相信，未来我们一定会找到更好的方式来与模型交互。而现在，我们还处在非常早期的阶段，甚至还不知道最终形态会是什么样。最终，这些系统会趋于融合，而我们与模型交互的方式也会彻底改变。

 

Fridman：工作流里还有一个重要部分是操作系统。我之前跟你私下聊过，我这辈子第一次打算深入使用苹果生态，包括 Mac、iPhone 等。我过去一直用 Linux、Windows，以及 WSL1、WSL2，都觉得很好。但现在我想试试 Mac，因为很多使用语言模型和智能体的社区成员都在用 Mac。不同操作系统之间真的有那么大的差别吗？当然，OpenClaw 是跨平台的。

 

Peter：是的，确实有差别。理论上，它甚至应该可以在 Windows 上原生运行，只是我没有足够时间做完整测试。

 

你知道，软件开发里，后 90% 的工作总是比前 90% 更难，但我相信这些问题最终都会解决。

 

Fridman：我也看到有人推荐用 WSL2，说它在侧边窗口等操作上体验不错。当然，Windows、Linux 和 macOS 现在都能支持。

 

Peter：我自己其实长期用过 Windows。我从小就在用它，后来转向 Linux，一度非常沉迷，自己编译内核之类的。

 

上大学后我继续用 Linux，直到有一天看到了一台白色塑料外壳的 MacBook，觉得它真的太美了。后来我转向 Mac，主要原因很现实：我受够了 Skype 的音频问题，也受够了 Linux 长期存在的一些系统层面的麻烦。

 

再后来，我又深入做了 iOS 开发，而 iOS 本来就必须依赖 macOS，所以这条路就走下来了。

 

我觉得苹果在“原生应用”这件事上，其实已经丢掉了一些原本的优势。以前，尤其是在 Mac 上，原生应用真的更好，开发者也更用心。

 

Windows 的特点是功能多，毫无疑问。但很多 Windows 应用给人的感觉是“功能堆砌”，而不是精心打磨。

 

相比之下，Mac 一直更吸引设计师和开发者，虽然功能可能更少，但使用体验更愉悦、更有玩味。

 

Fridman：但你现在听起来，对原生应用也有不少不满。

 

Peter：是的，说出来可能会被嘲笑，但最近几年，我很多时候反而更喜欢 Electron 应用。

 

因为 Electron 应用通常运行得很顺，而所谓的“原生应用”，尤其是一些基于 Web 服务的原生客户端，功能反而经常不完整。

 

我不是说原生应用做不到，而是对很多公司来说，原生应用已经不是最重要的事情了。但如果他们做的是一个 Electron 应用，那往往就是唯一的客户端，优先级更高，代码复用也更好。

 

Peter：当然，我自己也做了很多原生 Mac 应用，我是喜欢做的。我喜欢做一些小巧的菜单栏工具，比如一个用来监控 Codex 使用情况的小工具。

 

我还做了一个叫 Trimmy 的工具，专门为代理操作服务：当你选中多行文本时，它会自动移除换行符，方便你直接粘贴进终端。

 

这件事烦了我大概二十次之后，我就干脆自己做了这个工具。

 

Fridman：所以你其实还是很享受给这个操作系统“加点乐趣”。

 

Peter：是的，但问题也随之而来。

 

比如我还给 GitHub 做过一个应用，用的是 SwiftUI——这是苹果现在主推的技术。但他们花了很长时间，才实现了一个“能显示网页图片”的功能。

 

现在虽然有了异步图片加载，但我在接入之后发现，有些图片根本显示不出来，或者加载得非常慢。

 

我甚至问 Codex：“为什么会有这个 bug？” Codex 的回答是：“是的，有一个 ASIC 镜像方案，但它主要是实验用途，不适合生产环境。”

 

可问题是，这已经是苹果官方给出的网页图片显示方案了。这不应该这么难。

 

真的很疯狂。现在已经是 2026 年了，而我的代理居然在跟我说：“不要用苹果自己开发的方案，因为它虽然存在，但并不好用。”这本身就成了一个问题。

 

苹果曾经有巨大的先发优势，也投入了大量资源，但最终却没有把它发展成应有的样子。

 

Fridman：但从现实来看，在硅谷，大量开发者都在尝试使用语言模型和智能体 AI，而他们几乎清一色在用苹果的产品。与此同时，苹果似乎并没有真正重视这些技术，也没有开放合作、探索或交流。

 

人生建议、幸福与金钱

 

Fridman：有些听众是编程新手。你会给他们什么建议，帮助他们进入 Agentic AI 的世界？

 

Peter：玩。 “玩”是最好的学习方式。如果你脑子里有一个想法，哪怕只是模模糊糊的，那就试着把它做出来。不需要完美。我做过很多东西，后来都没再用过，这完全没问题。重要的是过程。

 

就像哲学里常说的，结果并不重要，过程才重要。玩得开心。说实话，我从来没有像现在这样享受“建造”的过程。以前我以为自己喜欢编程，其实我真正喜欢的是动手创造。

 

当你遇到不懂的东西时，尽管去问。你现在拥有一个无限耐心的“答录机”。它可以解释任何复杂的问题。有一次我让它“用八岁小孩能听懂的方式解释”，结果它真的开始用蜡笔讲故事。我赶紧说：“不行，别这样。”

 

但我确实只是想用更简单的语言理解一些我第一次没搞懂的数据库概念。过去我得去 Stack Overflow，或者在 Twitter 上提问，等上几天，或者花几个小时自己硬啃。而现在，你可以直接问。

 

这就像你随时拥有一位私人老师，而在统计学里我们知道，有私人老师的人学习速度会快得多。

 

更通俗地说，如果你是新手，又真的想快速学会如何构建软件，那就参与开源项目。不一定是我的项目。事实上，我的项目待办事项已经够多了。

 

我从开源项目中学到了很多。记住，要保持谦逊，不要一上来就提 pull request。你可以通过阅读代码、参与社区来学习。比如加入 Discord，看看软件是如何被构建的。

 

举个例子，Mitchell Hashimoto 做的 Ghostty 终端就有一个非常好的社区。选择你感兴趣的项目，参与进去。

 

Fridman：你是否仍然建议不太懂编程的人去学编程？即便现在用自然语言也能取得很大进展？

 

Peter：这当然是有帮助的。

 

Fridman：这个问题对你来说可能很难回答，因为你已经有很强的直觉基础。

 

Peter：确实。但我见过一些非常主动、非常好奇的人，即使不完全理解软件底层原理，也能走得很远，因为他们会不断提问。

 

而代理的耐心是无限的。我今年参加了很多 iOS 大会，我常跟大家说：“别再把自己当成 iOS 工程师，你是一个开发者。”

 

你可以把通用的软件开发知识迁移到新的领域，代理可以帮你处理所有细节。你不需要知道如何拼接数组，也不需要记住模板语法。你只需要理解问题本身。不同语言只是工具。

 

Fridman：比如你构建 CLI 时会用 Go？

 

Peter：是的。其实我并不喜欢 Go 的语法，但它的生态很好，和代理配合得也很好，有垃圾回收，性能足够快。

 

所以我会用一门我并不热爱的语言，只因为它在这个问题域里是最合适的选择。

 

Fridman：这是不是很有意思？如果没有语言模型，你可能永远不会用 Go。

 

Peter：是的，因为我们现在所处的世界本身就很奇怪。

 

Fridman：那在 AI 和智能体领域，最好的编程语言是什么？JavaScript？TypeScript？

 

Peter：TypeScript 很不错，但它的类型系统有时也会让人困惑，生态非常复杂。它适合 Web，但不适合所有东西。

 

Fridman：你不觉得一切最终都会用 JavaScript 写吗？

 

Peter：JavaScript 的诞生与消亡，我们正在实时经历。

 

Fridman：那 20 年、30 年、40 年后，编程会是什么样？

 

Peter：我们甚至可以问：是否需要一门专为智能体设计的编程语言？现有语言都是为人类设计的。如果你发明了一门全新的语言，而智能体对它一无所知，那反而会更难用。当我做 Mac 应用时，我会用 Swift 和 SwiftUI，一方面是挑战，另一方面是只有这样才能做到最深层的系统集成。Electron 应用和原生应用的“感觉”是完全不同的。

 

Fridman：比如 Zig？

 

Peter：是的。如果我在乎性能，Python 反而变得非常有趣。过去半年里，Python 智能体的可用性提升非常大。但它仍然是一个年轻生态。很多时候，你真正关心的是生态系统。

 

如果我要做推理、跑模型，Python 很合适。但如果我要做一个能在 Windows 上发布的应用，那它就不是好选择。这时我可能会用 Go 重写。如果追求并发和极致性能，Rust 也是很好的选择。没有唯一答案，这正是它有趣的地方。

 

Fridman：听起来你现在的标准更务实了。

 

Peter：是的。选最适合问题域的语言就好。你也可以随时问你的代理。

 

Offer 拿到手软，OpenAI 和 Meta 都要收购

Fridman：我很好奇，你应该收到很多大公司的高薪 offer 了吧？现在在考虑和哪些公司合作？

 

Peter：我没想到项目会火成这样，各大风投都来找我聊。我其实可以什么都不做，也可以删掉项目，或者再创办一家公司，很多人都支持我这么做。

 

Fridman：也就是说，你完全能融到几亿、几十亿的巨额资金？

 

Peter：是的，但我提不起兴趣。我已经做过一次 CEO，这条路会占用我所有时间，还会带来利益冲突，比如优先做企业版、修改开源许可证，这都会伤害社区。我想要的是无附加条件的完全免费开源。而且现在靠捐赠根本不可持续，像 Tailwind 这样的热门项目都在裁员。

 

Fridman：所以你这个项目现在是在赔钱？

 

Peter：对，目前在赔钱。每月收入 1 万到 2 万美元，但我还要补贴个人维护的依赖项目，OpenAI 等公司有一些支持，但依然不可持续。

 

Fridman：所以你在考虑和大型实验室合作？

 

Peter：是的，聊过很多家，目前最感兴趣的是 Meta 和 OpenAI。

 

Fridman：你更倾向哪一方？

 

Peter：还没最终定，但我的核心条件是：项目必须保持开源，类似 Chrome 和 Chromium。这件事太重要，不能完全交给一家公司。而且 ClawCon 的社区氛围特别珍贵，是互联网早期才有的热情。我想把它普及给更多人，今年就是个人代理元年，和实验室合作是最快的方式。我也从没在大公司工作过，想体验这种经历。

 

Fridman：你不怕别人说你 “出卖了开源” 吗？

 

Peter：肯定会有人说，但项目会继续，还能获得更多资源。这两家公司都认可这个项目的价值，它让普通人也爱上 AI。

 

Fridman：你有看到普通非技术用户被真正改变吗？

 

Peter：有。我帮一个不懂技术的朋友装好 OpenClaw，他几天就迷上了，自己做小工具，还升级高价订阅。结果平台把他封了，特别短视，直接失去优质早期用户。

 

Fridman：如果必须选 Meta 还是 OpenAI，你会怎么选？

 

Peter：很难选，两边都很棒。Meta 这边，Ned 和 Mark 会亲自试用产品、写代码、给反馈，还会和我争论技术细节；OpenAI 的算力和技术速度非常吸引人。我在 OpenAI 没有熟人，但和双方沟通都很愉快。这大概是我除了过去感情经历外，最难做的决定之一。

 

Fridman：他们都很懂规模化，能把你的技术安全地推广给更多人。

 

Peter：没错。有人使用产品、真心在乎它，就是最大的赞美。我做这一切不是为了钱，而是为了乐趣和影响力。

 

Fridman：你接下来的重点是什么？

 

Peter：先处理完大量积压的 PR，把产品做好。但这个项目不会是我干到 80 岁的事，它是一扇通往未来的窗口，我还有更多想法要实现。

 

OpenClaw 的工作原理

 

Fridman：能从更宏观的角度讲讲 OpenClaw 的工作原理吗？它包含网关、聊天客户端、安全框架、代理循环这些组件，你之前说每个人都应该实现一次代理循环。

 

Peter：代理循环就像 AI 里的「Hello World」，其实非常简单，重要的是明白它不是魔法，普通人也能自己搭建。我还做过一个拥有完整系统访问权限的版本，并且把它设成了主动式—— 会定时主动找你、关心你、跟进对话，比如问「你今天过得怎么样」，这就是所谓的「心跳」机制，本质上就是定时任务。

 

Fridman：很多人对它的批评其实很搞笑，这不就是个定时任务吗？

 

Peter：对，说到底就是定时任务，我有好多个。整个项目其实就是把几个不同的依赖项粘合在一起，没有什么惊天原创，就像 Dropbox 本质也只是多了几步的 FTP。但住院那次，它知道我做手术，主动来关心我，这种瞬间特别有共鸣。

 

Fridman：我们还没怎么聊技能（技能中心、技能库），这也是很重要的部分，功能一直在增加。

 

Peter：半年前大家都在聊 MCP，我当时就觉得 CLI 比 MCP 好用，现在核心组件里已经不支持 MCP 了，也没人抱怨。我的思路是：要扩展模型能力，只需要做一个命令行界面（CLI），模型可以调用它，出错了就查帮助菜单，一句话就能告诉模型怎么用。技能很适合这个模式：一句话解释技能，模型加载技能，技能解释 CLI，最后模型用 CLI 完成操作。

 

Fridman：MCP 更偏向结构化的协议，定义能访问什么资源；技能更偏向「怎么工作」，用半结构化自然语言描述流程。技术上，足够强的模型可以用技能取代 MCP。

 

Peter：最大优势是模型特别擅长调用类 Unix 命令，新加一个 CLI 就像多了一条系统命令。而 MCP 必须在训练时加入，语法死板、不可组合，还会把大量无关数据塞进上下文，造成污染。用 CLI 可以配合 JQ 之类工具过滤，只返回需要的内容，干净高效。当然 MCP 也有价值，它倒逼很多公司做了 API，我可以直接把 MCP 转成 CLI。只有少数例外比如 Playwright 这种需要状态的工具，用 MCP 才合理。

 

Fridman：你在 OpenClaw 里用了 Playwright 操作浏览器，几乎能做任何事。

 

Peter：对。现在很多平台 API 很慢，就算平台封了官方 API，只要能在浏览器访问，代理就能模拟操作，只是慢一点而已。我之前给 Twitter 逆向做了个 CLI 工具，后来被要求下架了。

 

Fridman：你能理解 X（原推特）的做法吗？他们是在防止被大规模爬数据。

 

Peter：能理解，但他们一刀切，伤害了大量小开发者的创意场景。其实只要做低频率、只读限制就能解决问题，比如让代理只读书签、做整理和研究，这是用户真实需求。我主动和他们沟通过，他们态度不错但还是要求下架。我只反对恶意 AI 自动化，比如用 AI 发攻击内容，我会直接拉黑。

 

AI 多了，也会让人生厌

 

Peter：现在互联网上，尤其在推特上，AI 很难写出完全像真人的推文，我对这种 AI 生成内容零容忍，会直接屏蔽。我希望平台能标记通过 API 发布的内容，也给 AI 代理提供便捷的注册方式，明确区分是代理操作还是本人操作。现在内容成本极低，用户的注意力才最珍贵，我一闻到内容有 AI 的味道就会很不舒服。

 

Fridman：从人类体验的角度看，未来会怎样？我们会不会越来越偏爱面对面交流，反而轻视线上互动？毕竟网上全是劣质 AI 和机器人，体验太差了。

 

Peter：如果 AI 足够智能，过滤这些内容并不难，但这确实是当下急需解决的问题。我收到很多目的性很强的邮件，我宁愿看语法生硬的真人文字，也不想看 AI 生成的内容，甚至开始欣赏文字里的错别字。我试过让 AI 写博客，但调整风格花的时间和手写差不多，还丢失了个人特色，所以我现在全部手写，最多让 AI 修正严重的拼写错误，人类的不完美本身就有价值。

 

Fridman：正因 AI，我们才更加珍惜纯粹的人性，这不是很美好吗？

 

Peter：我写代码会大量用 AI，但写故事完全接受不了 AI 生成。文档类内容 AI 还能用，可 AI 生成的信息图、图片之类，我现在一看就反感，新鲜感一过就显得很劣质，哪怕我自己以前用过，现在也觉得是 AI 垃圾。

 

Fridman：我也有同感。AI 图表一开始让人兴奋，没多久就觉得虚假，就像一种让人不适的 “气味”。

 

Peter：就是 “气味”，AI 内容有独特的假味。

 

Fridman：这反而让我对人类体验充满希望，人性不会被 AI 取代，只会因 AI 更珍贵。对了，你之前说很多应用会被淘汰，你认为智能助手会彻底改变整个应用市场吗？

 

AI Agent 将取代 80% 的应用程序

Peter：我在 Discord 上发现，大家都在用智能代理做各种事。既然代理知道我在哪，那我为什么还需要 MyFitnessPal 这类应用？它能推断出我在餐厅可能会做出饮食上的选择，还能根据我的睡眠、压力情况调整健身计划，掌握的信息比任何单独 App 都多，决策也更合理。

 

Fridman：你的代理就该懂这些。

 

Peter：它还能按我的喜好展示界面，我没必要再为重复的功能订阅各种 App，也不用专门用 Eight Sleep 控制床，直接告诉代理就行。我认为未来一整类应用都会被淘汰，我自己都会主动不用，因为代理能做得更好。

 

Fridman：我记得你说过，这可能会让 80% 的应用消失。

 

Peter：没错。

 

Fridman：这对软件开发和软件公司冲击巨大，甚至会让很多公司倒闭，你想过对经济和社会的连锁影响吗？它会改变工具开发者，也会大幅提升用户效率。

 

Peter：同时也会催生新服务。比如我希望给我的代理设置津贴，解决问题就付费；订餐会用到外卖服务，可能还会出现类似 “租人类” 帮忙落地的服务。我只关心问题能不能解决，并非所有应用都会消失，有些会转型成 API。

 

Fridman：也就是说，能快速转型为面向代理提供服务的应用会有机会，比如 Uber Eats，谁能先和 OpenClaw 自然便捷对接，谁就占优势。

 

Peter：对。不管愿不愿意，很多应用最终都会变成 API。比如我的代理可以操控手机，安卓上已经有人这么做了。像 Sonos、摄像头这类有 API 的设备，代理都能直接对接，我根本不需要它们的独立 App。我们才刚开始理解这背后的意义。

 

Fridman：这会迫使很多公司转型，就像当年互联网出现一样。

 

Peter：但有些公司并不配合。比如谷歌没有命令行界面，我只能自己做工具；想接入 Gmail 数据流程极其复杂，很多初创公司为了权限甚至要收购其他公司。就算这样他们也拦不住，最坏情况下，代理可以通过浏览器模拟操作获取数据，甚至能通过人机验证。但像 Cloudflare 这类公司会拦截机器人，有些网站也会屏蔽代理，导致我只能手动复制内容，以后我会更倾向用对代理友好的网站。

 

Fridman：很多大公司会强力抵制，而你正好处在这场改变人机与服务交互方式革命的中心。

 

Peter：就连搜索我都不用谷歌了，改用 Perplexity 或 Brave，因为谷歌不希望用户脱离它的服务。我不确定这是正确策略。

 

Fridman：大公司过度抵制，最后会像百视达被 Netflix 颠覆一样，但适度抵制在变革期也有道理。

 

Peter：但这是用户真正想要的。比如我出门在外，不想打开日历 App，只需要告诉代理 “提醒我明天晚宴，邀请两个朋友，再给他们发 WhatsApp” 就行，我不需要为此打开任何应用。我们已经过了独立 App 的时代，未来会更加互联互通、更灵活，不管公司愿不愿意。顺应趋势的公司能活下来，抗拒的会被淘汰。

 

AI 会取代程序员吗？

Fridman：很多程序员都很担心未来，你觉得人工智能会完全取代人类程序员吗？

 

Peter：我们确实在往这个方向走。编程只是产品开发的一部分，AI 最终可能会取代写代码的工作，但构建产品的核心 —— 想做什么、体验如何、架构怎么设计 —— 这些 AI 取代不了。编程这项技艺会保留下来，但会像织毛衣一样，更多是出于热爱，而非必需。我也会伤感，过去沉浸写代码的心流状态很珍贵，但和智能体一起构建系统，也能获得类似的心流。我们可以惋惜，但无法抗拒这个趋势。

 

过去程序员稀缺所以薪资极高，未来依然需要大量会创造的人，只是量化智能会让大家做得更多更快，就像当年蒸汽机取代体力劳动。如果你把身份完全绑定在 “程序员” 上，会很恐慌，但你其实是创造者，不只是写代码的。

 

Fridman：我深有同感。我也曾花几千小时写代码，程序员身份是我的一部分，这种转变很痛苦。但现在的程序员最有能力学习和 AI 智能体协作，理解它们的语言。

 

Peter：未来这种和智能体协作的方式，会重新被叫作 “编程”，成为新常态。我现在不怎么手写代码，但依然完全掌控项目，我依然是程序员，只是工作内容变了。

 

我在一些平台会因为观点被攻击，但我更理解大家的恐惧了。这会是充满挑战的转变，但也很有趣、有成就感，人们对产品的期待也会变高。我在会议上劝大家别把自己限定成 iOS 开发者，而是成为构建者，应用会慢慢消失，很多人不喜欢这个观点，但这是我对未来的真实判断。

 

有人质疑 AI 数据中心耗水耗电，但算下来其实很有限，打高尔夫的用水量都比所有数据中心加起来多。大家总盯着 AI 的缺点，却忽略它的好处。AI 无疑是变革性的技术。

 

Fridman：硅谷里大家对科技很兴奋，但容易忽视普通人会经历的痛苦，比如大量人可能失业。短期有阵痛，但长期有望带来更美好的世界和更多机会，我们要尊重这些短期痛苦。

 

Peter：我收到很多小企业主的邮件，说 OpenClaw 帮他们自动化了发票、回复邮件这类琐事，解放了很多时间。还有人说，这个工具帮助了残疾的女儿，让她能做更多事，更有力量。我没有发明全新的技术，只是把它变得简单易用，让普通人也能触碰到可能性。它可以免费运行、本地运行，用平价模型也能很强。

 

这些反馈让我特别开心，它真的在给很多人的生活带来快乐，不只是程序员。

 

Fridman：看到这些真的很美好。是什么让你对人类文明正在发生的这一切抱有希望？

 

Peter：我感觉我激励了很多人。感觉……现在又掀起了一股建设者的热潮。人们现在以更轻松有趣的方式使用人工智能，探索它的功能以及它如何帮助他们改善生活。他们创造出充满创意的新天地。我不知道该怎么说。比如，ClawCoin，有大约 500 人。而且有很高比例的人愿意分享他们的成果，这让我非常惊讶，因为通常很难找到愿意谈论自己所创造的东西的人。而现在，这样的人很多。这让我看到了希望，相信我们能够解决所有问题。

 

Fridman：这使得它基本上人人都能使用。想象一下，这么多人都在构建，尤其是在你不断简化流程、提高安全性的情况下。这就像任何人只要有想法，并且能用语言表达出来，就能构建一样。这太疯狂了。

 

Peter：是的，这最终意味着权力归于人民，也是人工智能带来的美好事物之一。它不仅仅是一个垃圾生成器。

 

参考链接：

https://www.youtube.com/watch?v=YFjfBk8HI5o&t=3674s


                “网络广告投放目标受众分析”思维导图

“网络广告投放目标受众分析”思维导图模板获取链接

一、核心主题确定

核心主题是“目标受众分析”，该主题旨在详尽描述并细分目标市场的核心人群画像、消费场景及竞品对比，为制定精准的市场策略提供有力支持。

二、导图结构设计

  1. 核心人群画像：从人口属性、兴趣标签及行为路径多维度精准描绘目标受众特征。
  2. 消费场景：从购买动机及决策影响因素全面剖析消费者决策相关情形。
  3. 竞品对比：从差异化优势与竞品短板两方面剖析，助力产品优化与竞争优势凸显。

三、导图样式设计

  • 颜色：运用不同颜色清晰区分各分支内容，例如绿色代表核心人群画像，红色代表消费场景，黄色代表竞品对比。
  • 布局：采用鱼骨图布局，核心主题位于左侧，向右延伸出主要分支，每个主要分支再细分出子节点，形成层次分明的结构。同时，利用分支折叠功能，可以隐藏或显示特定分支的详细信息，提升导图的阅读体验。
  • 字体和线条：选用统一字体，确保导图整体风格的一致性；线条粗细一致，使导图更加整洁易读。

“网络广告投放目标受众分析”思维导图模板在线免费体验链接

四、导图工具与流程

  • 工具选择：选用图形天下思维导图工具进行绘制，其支持多端应用，兼容多种主流格式，便于调整和优化布局。

  • 创作流程

    1. 数据收集：广泛收集目标市场的相关数据，包括人口统计、兴趣爱好、消费行为等多方面的信息。
    2. 信息整理：对收集到的数据进行系统整理，分类归纳到不同主题下，形成清晰的数据框架。
    3. 导图绘制：根据整理好的信息，开始绘制思维导图。逐步填充各个节点，查看和调整导图结构。
    4. 审核优化：仔细审核导图的逻辑性和完整性，进行必要的调整和优化。利用图形天下思维导图的导图对象分类索引功能，快速定位和修改特定元素，确保信息准确、层次分明。

图形天下思维导图软件免费下载链接

五、总结

通过以上步骤，目标受众分析导图得以系统、全面地展示目标市场的详细信息。图形天下思维导图工具的鱼骨图布局、分支折叠等功能，为导图的创作和优化提供了极大便利，使得导图结构更加清晰、信息展示更加直观。最终呈现的导图不仅有助于制定有效的市场策略，还能提升团队协作效率和决策质量。

访问图形天下思维导图模板库与教程资源，获取更多免费导图素材与实操指南，激发你的无限创意。

  1. 1
  2. ...
  3. 40
  4. 41
  5. 42
  6. 43
  7. 44
  8. 45
  9. 46
  10. ...
  11. 252