总结一下怎么在VS Code 调试vue2 源码
我们开始吧～
去Github克隆源码，克隆后我们用VS Code打开。
登录
git clone https://github.com/vuejs/vue
pnpm i
把项目跑起来
npm/pnpm run dev
bundles /Users/gongzemin/Documents/GitHub/vue/src/platforms/web/entry-runtime-with-compiler.ts → dist/vue.js...
从 entry-runtime-with-compiler.ts 这个入口文件打包生成 dist/vue.js 这个最终可用的 Vue 文件
生成了dist文件夹 里面有vue.js
我们找examples/classic/commits/app.js 在如图位置打上断点
commits/index.html 这个文件引入了vue.min.js, 我们刚才构建出来的是vue.js文件，我们把引入的文件改成vue.js
<script src="../../../dist/vue.js"></script>
安装好插件后，打开文件的上下文菜单 可以看到Open with Live Server
这样我们就可以打开我们的examples/classic/commits/index.html 文件了 是用服务器打开的
注意这里的URL是我们的要调试URL路径
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Run parser",
"runtimeExecutable": "parser",
"cwd": "${workspaceFolder}/packages/reactivity-transform/node_modules/@vue/compiler-core",
"args": []
},
{
"type": "chrome",
"request": "launch",
"name": "调试Vue源码",
"url": "http://localhost:5501/examples/classic/commits/index.html",
"webRoot": "${workspaceFolder}",
"sourceMaps": true,
"sourceMapPathOverrides": {
"webpack:///./*": "${webRoot}/*",
"webpack:///packages/*": "${webRoot}/packages/*",
"*": "${webRoot}/*"
},
"skipFiles": ["<node_internals>/**"]
}
]
}
点击Run and Debug图标， 选择调试Vue源码(就是我们配置launch.json里面配置的name)
看到app.js 进入我们打的断点了
我们点击Step Into
就进入Vue()构造函数了
调试vue3源码方法也一样 参考这篇笔记
奥特曼家被炸了
【导读】当地时间周五清晨，奥特曼家被炸了。奥特曼发出家人和孩子的照片，并且发出长文表示，AGI如今已经如同魔戒一般，让人做出疯狂的举动。
奥特曼家被炸了！
就在当地时间周五清晨，一名20岁男子向奥特曼旧金山中投掷了燃烧弹，引起火灾。
这栋豪宅价值2700万美元。
凌晨4点12分，警方接到报警，调查后发现无人受伤，火势已被控制。但嫌疑人已经徒步逃跑，体貌特征已被通报。
凌晨5点07分左右，警方又接到报警称，OpenAI办公楼外，一名身份不明的男子扬言要烧毁大楼。
警员很快发现，该男子与向奥特曼家中投掷燃烧弹的嫌疑人特征相符，应为同一人，警方立即将其拘留。
现在，旧金山警察局已经在X上发布通报。目前调查仍在进行中，尚未正式提出指控。
旧金山警察局已经在X上发布通报
面对这起事件，奥特曼愤怒了！他罕见地公开全家福，并且深夜发表了一篇长文。
奥特曼发长文
奥特曼发长文
奥特曼表示，「我爱我的家人胜过一切」
在这篇文章中，奥特曼首次深刻地回应了公众对AI的极度焦虑。他坦诚这种恐惧是合理的，呼吁通过全社会的政策响应和AI民主化来应对，坚决反对少数实验室独占未来控制权。
同时，他也进行了深度的个人反思，为自己因「逃避冲突」导致董事会风波而致歉。
他犀利指出，当前AI行业频发的内部斗争，就是源于AGI犹如「魔戒」般的权力诱惑。而唯一的解法，就是不让任何人独占控制权。
最后，他呼吁各方保持理性，停止极端的言语与物理攻击。
近几个月来，美国民众对AI的看法急剧恶化。
就在Anthropic拒绝国防部合同要求的几小时后，OpenAI宣布与五角大楼达成协议，此举招致了大量对OpenAI的恶评。
奥特曼也明白，AI在美国大众的心目中并不受欢迎，很多人认为电价上涨、大量裁员的罪魁祸首就是AI。
山姆·奥特曼：AI在美国大众的心目中并不受欢迎
奥特曼的遭遇并不是首例，很多科技领袖都受过类似威胁，各大公司也都加大了对高管保护的投入。
仅在2019年，扎克伯格的安保费就超过了2000万美元。
而特斯拉提交给美国证券交易委员会的文件也透露了马斯克的安保成本：该公司「在2023年为此类安保服务支付了约240万美元的费用，并在2024年2月之前支付了约50万美元的费用，这仅仅占总成本的一部分。」
此前，美国各地就曾爆发反AI的大规模游行，愤怒的民众聚集在OpenAI和Anthropic总部外面，街道上写满标语。
3月份，就曾爆发过一场美国史上最大规模的AI全球抗议活动，200人横跨Anthropic、OpenAI、xAI高喊「停止AI竞赛」！
美国史上最大规模的AI全球抗议活动
总诉求只有一个：若主要AI实验室彼此达成一致，应承诺暂停更强大模型的训练与发布。
参与联盟包括MIRI、PauseAI、StopAI、QuitGPT等组织成员，以及部分学者与前实验室员工。
如今，AI安全派和技术加速派之间关系已经极度紧张。
美国史上最大规模的AI全球抗议活动
美国史上最大规模的AI全球抗议活动
我希望图片是有力量的。通常我们尽量保持低调私密，但在这种情况下，我决定分享一张照片，希望它能打消下一个人向我们家扔燃烧瓶的念头，不管他们对我有什么看法。
上一个人是在昨晚，凌晨3点45分干的。谢天谢地，燃烧瓶被房子的外墙弹开了，没有人受伤。
文字也是有力量的。几天前，有一篇关于我的文章，充满了火药味。昨天有人跟我说，在大家对AI感到极度焦虑的当下出这种文章，会让我的处境变得更加危险。我当时没当回事。
现在，我大半夜醒来，火很大，并且意识到我之前低估了文字和舆论导向的力量。现在看来，正是把一些事情说清楚的好时候。
首先，我的信念。
*为每个人争取繁荣、赋能全人类，以及推动科技进步，对我来说是义不容辞的道德责任。
*AI将成为人类见过的、扩展自身能力和潜力最强大的工具。人们对这个工具的需求基本上是没有上限的，大家会用它做出不可思议的事情。这个世界理应拥有海量的AI，我们必须想办法实现这一点。
*但一切不会总是一帆风顺。对AI的恐惧和焦虑是完全合理的；我们正在见证社会发生长久以来、甚至是史无前例的巨变。我们必须搞定安全问题，这不仅仅是对齐某个模型那么简单——我们迫切需要全社会的共同响应，以抵御新的威胁。这包括制定新政策，帮助我们度过艰难的经济转型期，从而走向一个美好的多的未来。
*AI必须民主化；权力绝对不能过度集中。未来的控制权属于全人类及其社会机构。AI需要在个体层面赋能每个人，同时我们需要共同为我们的未来和新规则做决定。我认为由少数几家AI实验室来决定我们未来社会形态这种最重大的事情，是不对的。
*适应性至关重要。我们都在极其快速地学习新事物；我们的一些信念会被证明是对的，有些则会是错的。有时随着技术发展和社会演变，我们需要迅速转变观念。现在还没有人真正了解超级智能的影响，但这种影响必将是极其巨大的。
其次，一些个人的反思。
回首我在OpenAI头十年的工作，有很多让我感到骄傲的事情，但也犯了一大堆错误。
我刚刚想起了我们即将与马斯克对簿公堂的事，想起了我当初是如何死守底线，拒绝同意他想要对OpenAI拥有单方面控制权的要求。我为此感到骄傲，也为我们当时在夹缝中求生，保住了OpenAI并取得随后的所有成就而感到自豪。
我不为自己害怕冲突的性格感到骄傲，这给我和OpenAI都带来了巨大的痛苦。我不为自己在与前任董事会的冲突中表现糟糕而感到骄傲，那给公司造成了巨大的烂摊子。在OpenAI疯狂的发展轨迹中，我还犯过许多其他错误；我是一个有缺陷的人，身处在一个极其复杂的局面中心，试图每年都取得一点点进步，始终为着公司的使命而工作。我们在入局之前就知道AI的赌注有多大，也知道我所关心的、心怀善意的人们之间的个人分歧会被无限放大。但亲身经历这些痛苦的冲突，并且还要经常出面调停，完全是另一回事，我们付出了惨痛的代价。我向我伤害过的人道歉，希望我当初能学得更多、更快一些。
我也非常清楚，OpenAI现在是一个大平台了，不再是当初那个草台班子般的初创公司，我们现在必须以一种更可预测、更稳定的方式运营。过去这几年，强度极大、极其混乱且压力山大。
但抛开这些，最让我自豪的是，我们正在兑现我们的使命，这在我们刚起步时看起来简直是天方夜谭。排除了万难，我们弄清楚了如何构建极其强大的AI，弄清楚了如何筹集足够的资金来建立基础设施以交付它，弄清楚了如何打造一家产品公司和商业模式，弄清楚了如何在大规模上提供相对安全和稳健的服务，还有很多很多。
很多公司都把「改变世界」挂在嘴边；但我们是真的做到了。
第三，关于这个行业的一些想法。
过去几年我个人的体会，以及我对为什么我们这个领域的公司之间会上演这么多莎士比亚戏剧般抓马事件的看法，归结起来就是一句话：「一旦你见识过通用人工智能（AGI），你就再也忘不掉了。」它带有一种真实的「魔戒」效应，能让人做出极其疯狂的事情。我不是说AGI本身就是那枚魔戒，而是那种「要成为控制AGI的那个人」的极权主义思想。
我能想到的唯一出路，就是坚定地与大众分享这项技术，不让任何人独占这枚「魔戒」。实现这一点的两个最明显的方法就是：赋能个人，以及确保民主制度始终掌握控制权。
关键在于，民主进程必须始终拥有比公司更大的权力。法律和规范肯定会改变，但我们必须在民主的框架内行事，哪怕这个过程会很混乱，而且比我们希望的要慢。我们希望成为一种发声渠道和一个利益相关者，但绝不希望拥有所有的权力。
对我们行业的许多批评，实际上源于对这项技术极高风险的真诚担忧。这是非常合理的，我们欢迎善意的批评和辩论。我对那些反技术的情绪感同身受，显然技术并不总是对每个人都有利。但总的来说，我相信技术进步能为你我的家人创造一个无比美好的未来。
在我们进行这些辩论的同时，我们应该降降温，少用点过激的言辞和手段，不管是在比喻意义上还是字面意义上，都少搞点爆炸，少炸点房子吧。
参考资料：
https://www.theverge.com/ai-artificial-intelligence/910393/openai-sam-altman-house-molotov-cocktail
https://blog.samaltman.com/2279512
https://www.businessinsider.com/sam-altman-home-attack-molotov-cocktail-police-arrest-2026-4
本文来自微信公众号“新智元”，作者：新智元，36氪经授权发布。
大家好，我是笨笨狗吞噬者，uni-app、varlet、nrm 等众多知名仓库的核心开发，专注于分享 前端技术 和 AI 实践知识，欢迎关注我的微信公众号 前端笨笨狗！
大家平时写代码时，经常会遇到一些很碎的小动作，比如：
这些操作不难，但做得多了就很烦，尤其是在目录结构比较复杂的工程里。我也被这类问题折腾了很久，试了插件市场里的很多插件，却总不如意，于是，我就自己写了插件 Copy Filename Pro。
Copy Filename Pro 主要提供下面几个功能：
比如我想复制某个 vue 文件的完整文件名
比如我想复制某个 vue 文件的不包含文件后缀的文件名
比如我想复制某个文件夹名称
由于 VSCode 本身有复制路径和相对路径的功能了，所以这里演示如何得到不包含文件后缀的路径
比如我想一次复制多个文件名
大家可以参考下面的图片安装此插件
另外，此插件的源码是完全免费公开的，访问 https://github.com/chouchouji/copy-filename-pro 即可获取，如果你有更好的想法和建议，也可以留言给我。
在 React Native（RN）里处理权限申请，本质上有两条路：
最主流的是 👉 react-native-permissions
yarn add react-native-permissions
iOS 还需要：
cd ios && pod install
import {request, PERMISSIONS, RESULTS} from 'react-native-permissions';
import {Platform} from 'react-native';
export async function requestCameraPermission() {
const permission =
Platform.OS === 'ios'
? PERMISSIONS.IOS.CAMERA
: PERMISSIONS.ANDROID.CAMERA;
const result = await request(permission);
switch (result) {
case RESULTS.GRANTED:
console.log('已授权');
break;
case RESULTS.DENIED:
console.log('用户拒绝');
break;
case RESULTS.BLOCKED:
console.log('被永久拒绝，需要引导去设置页');
break;
}
}
| 功能 | iOS | Android |
|---|---|---|
| 相机 | CAMERA |
CAMERA |
| 相册 | PHOTO_LIBRARY |
READ_MEDIA_IMAGES（Android 13+） |
| 定位 | LOCATION_WHEN_IN_USE |
ACCESS_FINE_LOCATION |
| 存储 | 自动 |
READ/WRITE_EXTERNAL_STORAGE（已逐步废弃） |
import {openSettings} from 'react-native-permissions';
openSettings();
RN 自带：
👉 PermissionsAndroid（仅 Android）
import {PermissionsAndroid} from 'react-native';
await PermissionsAndroid.request(
PermissionsAndroid.PERMISSIONS.CAMERA
);
只有这些情况才建议：
// permission.ts
export async function requestPermission(type: 'camera' | 'photo' | 'location') {
// 内部统一处理
}
👉 避免业务代码到处写权限逻辑
不要一进 App 就申请 ❌
👉 要“用到时再申请” ✅
例如：
if (result === RESULTS.BLOCKED) {
Alert.alert(
'需要权限',
'请前往设置开启权限',
[
{text: '取消'},
{text: '去设置', onPress: openSettings}
]
);
}
存储权限拆分为：
READ_MEDIA_IMAGESREAD_MEDIA_VIDEOREAD_MEDIA_AUDIO👉 用旧的 READ_EXTERNAL_STORAGE 会失效
👉 90% 场景建议：
react-native-permissions
文｜Lambda
编辑｜晓静
4月初，Hermes Agent 火了。这个名字直接让人联想到奢侈品牌爱马仕，所以也被戏称为“爱马仕Agent”。
它由 Nous Research 在 2 月发布，定位是「The agent that grows with you」。核心卖点是一个闭环学习系统：Agent 完成复杂任务后，自动把经验固化成 Skill，下次遇到类似任务直接复用，还能在使用过程中持续改进。Skill 自动生成、越用越强——这是 Agent 领域目前最有吸引力的叙事之一。
但这个叙事遮蔽了一个更基本的问题：Skill 真的是当前 Agent 落地的主要瓶颈吗？
图片由AI生成
一个容易被忽略的事实是：目前公认体验最好的编程 Agent 产品之一——Claude Code，它好用的基石并不是 Skill 的自动进化，而是背后大量扎实的 CLI 工具支撑。
用 GlobTool 找候选文件，用 GrepTool 定位相关代码片段，用 FileReadTool 查看实现细节，用 LSPTool 做代码符号跳转和引用分析。每一个都是确定性的、零 token 消耗的原子操作。
但人们很少为这些工具写故事。只要一提到 Agent 能自动生成 Skill、还能持续进化，整个行业立刻就兴奋起来。
这个反差说明了一件事：CLI （命令行界面）不性感，不好讲故事，但它才是 Agent 能力的真正地基。
地基不牢，Skill 再会长，也只是长在沙地上。
这件事放到 OpenClaw（俗称‘龙虾”） 身上会看得更清楚。
OpenClaw 最被人诟病的两点，一是 token 消耗大、账单吃不消，二是长时间工作稳定性差、经常失联。乍一看是两个问题；往下拆，会发现它们经常来自同一个源头：Agent 在用劣质工具——比如脆弱的浏览器自动化——去完成本该由确定性工具完成的任务。
这类成本在社区里并非抽象的抱怨，而有大量具体案例。
Reddit 上有 OpenClaw 用户提到，自己只是想自动化 X 账号发帖，三次尝试就花掉了 10 美元，任务还没真正跑通。还有人在 r/automation 里直言，现在很多所谓的 AI Agent 浏览器控制，本质上只是「披着智能外衣的脆弱自动化」——问题不在模型有多笨，而在底层工具本身就不可靠。页面一变、DOM 一改、按钮状态一抖，Agent 就只能一遍遍观察、一遍遍重试、一遍遍重新规划。
而这些「失败但不致命」的试错过程，并不会因为任务没完成就免费——每一次观察页面、分析状态、决定下一步，都在继续消耗 token。
于是，稳定性问题和成本问题，其实是同一个问题的两面：工具越脆弱，试错越多；试错越多，token 烧得越快；任务链越长，失联和中断的概率也越高。
从这个角度看，Skill 自主进化解决的是「怎么更聪明地使用一个工具」，但并没有解决「好工具本身稀缺」的问题。Skill 可以让 Agent 更熟练地驾驭一匹跛脚马，但并不能把跛脚马变成千里马。
这才是今天很多 Agent 系统真正卡住的地方：不是 Skill 不够强，而是底下能调度的高质量原子工具太少。
Hermes 做的事情，本质上是把 Skill 的生成和优化自动化——让 Agent 从经验中蒸馏知识，不再需要人手写。这确实解决了一个真实痛点。
但 Skill 本身有一个更深层的问题：它是自然语言驱动的，本质上是模型能力的延伸，或者说，是一种对模型能力的借贷。
现状是，大量 Agent 在用 Skill 加上自主解题能力，完成本该由 CLI 完成的事情——比如以效率低下的浏览器自动化方案查一个股票价格、下载一张图片、提交一个表单。代价很清楚：贵、慢、不稳定、调试难。
这里还有一个常见的认知误区，可以叫做「Skill 可迁移幻觉」：很多人以为，用强模型写出来的 Skill，可以无缝迁移给弱模型用。实际上不能。Skill 是自然语言指令，它对模型能力有隐性依赖；模型一换，行为就可能变。CLI 则不同——它是代码：同样的输入，永远给你同样的输出，不管底下跑的是什么模型。
二者的区别非常鲜明：
Skill 调试难，CLI 调试容易；
Skill 烧 token，CLI 近乎零消耗；
Skill 吃模型版本，CLI 不吃；
Skill 是语义层资产，CLI 是执行层资产。
如果把 Skill 当成核心积累方向，本质上是把赌注压在模型能力的稳定性上。至少在当前阶段，更值得积累的是高质量 CLI。
上面的分析也能从 Anthropic 自己的产品经验里得到印证。
Anthropic 的设计负责人、Cowork 产品的设计主导者 Jenny Wen 在近期访谈中提到一个细节：她个人其实不怎么用 Cowork 的 Skills 功能。原因不是她否定 Skill，而是她在 Cowork 里挂载了一个文件夹，里面有自己长期积累的个人笔记、一对一会议记录、随手想法和工作观察。对她来说，Cowork 从这些材料里已经学到了足够的信息，以至于她对 Skill 和 Memory 的需求都被显著削弱了。
这并不是说 Skill 没有价值，而是说：当上下文管理足够好、底层工具足够强时，Skill 的优先级会自然下降。
换言之，Hermes 所强调的 Skill 自主进化并不是错，而是它解决的问题很可能没有想象中那么基础。
如果说 Skill 解决的是应用层的编排问题，那么更底层的变化发生在 CLI 上。
过去，CLI 是为人设计的。给人用的 CLI 可以有交互提示，可以容忍模糊输出，也可以在文档不全的时候靠用户自己猜——因为人会停下来，会理解歧义，会重试，会去查文档。
Agent 不一样。
Agent 不睡觉，不容忍歧义，会并发，会在没有预料到的时机无限重试。一个对人类来说「勉强能用」的 CLI，对 Agent 来说可能就是高频事故源。
给 Agent 用的 CLI 必须满足一组完全不同的要求：
一条命令只产出一个明确结果；
输出是结构化的 JSON；
错误信息不仅告诉你哪里错了，还要告诉 Agent 下一步该怎么办；
长任务必须支持异步，不能让 Agent 傻等；
接口天然支持幂等、重试和并发。
背后只有一句话：以前的软件默认使用者要睡觉、会分心、有耐心；现在 Agent 不满足这些前提。
一旦使用者从人变成 Agent，CLI 的设计哲学就需要从头重写。Agent 真正在乎的是 token 消耗、缓存命中率、幻觉控制、长程稳定性，而不是「这个命令看起来是否优雅」。
有一个实验很能说明问题：把 ChatGPT 的网页版变成一个可以被 Agent 调用的 CLI。
做法并不神秘——通过 Chrome CDP 协议直接驱动浏览器，操作 DOM，填输入框，点发送，等待文字出现，再把结果抓下来。因为复用了已有登录态，行为上和人在浏览器里操作没有本质区别。
这个实验背后更大的洞察是：浏览器里能看到的，原则上都可以被 CLI 化。
不只是 ChatGPT——Gemini、音乐生成、视频生成、股票图表，只要能在浏览器里完成的流程，都可以被代码重复执行，最后收敛成一条 Agent 可调用的命令。
一旦一个 Web 流程被 CLI 化，它就会从「需要 Agent 一步步盯着网页试错」的流程，变成「可并发、可异步、可幂等的原子操作」。原来要靠浏览器自动化消耗大量 token 才能完成的事，被压缩成了一条命令、一个结构化结果。
某种意义上，这是一条很反直觉但非常现实的优化路径：节省 token 的方法，不是少让 Agent 干活，而是先烧一点 token，把高频流程预制成 CLI。磨刀不误砍柴工。
这个逻辑也不只适用于 Web。桌面应用和手机 App，本质上都可以被逐步 CLI 化，what you see is what can cli。目前已有不少开源项目在分别推进这三个方向，只是三者之间还没有形成统一的设计语言和引起大家足够的重视。
Agent 的未来，除了模型本身的提升，更取决于如何处理好两种逻辑：确定性逻辑和语义逻辑。
前者靠 CLI，后者靠 Skill 的自适应和进化。Hermes 解决的是后者，但前者才是今天很多系统真正缺的底座。
如果把 CLI 化推到极致，会出现一件很反直觉的事：一类流程完全固定的任务，Agent 只需要判断任务类型、路由到对应 CLI、拿结果回来——这个过程理论上甚至不需要 LLM，几个 if-else 就够了。你甚至可以用代码去模拟 LLM 的输入输出接口，零 token、零延迟，继续复用现有的 Agent 调度机制，只在真正需要判断的地方才调用真实模型。
这有点像 2026 年的一场「代码的文艺复兴」——人们开始重新发现，不是所有「看起来像智能」的问题都应该交给模型来解决。
终态的分工应该是三层：
CLI 层：确定性执行，零 token，可并发，易测试，不依赖任何模型；
Skill 层：上下文编排和经验蒸馏，越用越强；
LLM 层：提供智能，做真正需要语义判断的部分。
三层不是竞争关系，而是依赖关系。
今天很多系统的问题在于，它们跳过了 CLI 层，直接让 Skill 和 LLM 去兜底。结果就是：系统又贵又慢，稳定性也差。正确的路径应该是——开发者预制 CLI，上层应用自动管理 Skill，LLM 在 Skill 的辅助下使用 CLI 解决问题。
Hermes 的出现不是终点，而是一个信号：Skill 层的问题可能正在被解决，但下一个真正的战场，在 CLI 层。
Web 端、PC 端、移动端，三大平台系统性的 CLI 改造才刚刚开始。这可能才是今天 Agent 领域最值得做、也最不性感，但最关键的事情。
本文来自微信公众号“腾讯科技”，作者：Lambda，36氪经授权发布。
