2025-11-23 22:03:58
经过多年的工作，我终于明白一件事情：
技术能力的好坏，与工作是否稳定、工资的高低、生活品质的好坏，都没有关系。
我希望可以基于已有的技术能力，给更多人提供一些 “相对随意” 的帮助。（AI 懂的比我多，但是我们可以讨论哪个 AI 更好用）
不要误会，并不是说这个交流群是为了我自己的利益而创建。我的意思是，我可以提供的帮助，是这个群聊的一个兜底的价值。如果可以在群里得到其他人的帮助，或者在群聊中收获到什么，自然是再好不过的事情。
这是一个新创建的区块链交流群，欢迎加入：
我对这个交流群的设想是：
群聊二维码：
2025-11-17 22:36:29
2025-11-03 15:37:35
有这样两个事实：
这样的事实背后是有原因的：
这会带来不同的现象：
所以区块链的技术世界中，有没有什么理论性质的 “真理”，是长久不变、可以复用、无论上层框架如何变化都不需要担心的？
区块链技术世界的三大真理：
掌握了这三个部分的技术，无论区块链形式上怎么推陈出新，无论行业热点如何变化，都不用担心，因为区块链本质上就是在解决这些问题。
怎么样才算是掌握了 “真理”？我看懂了、我理解了，算是我会了吗？算是我掌握了吗？
掌握真理的标准是，可以根据真理，从头构建出知识。
在计算机科学的世界里，假如世界毁灭了，给你一张纸和笔，你可以从头实现 lambda 演算、实现数据结构、实现一个解释器、实现一种编程语言，甚至构造出更多东西，不依赖于教材、框架、API，这叫掌握真理。
真理的意义在于，让你明白知识为何必须如此存在。——这也是王垠的课程在试图教会你的东西，王垠不教知识，只教 “王垠式真理”。所以我一直认为王垠的课程好、价值高。
类似的，在区块链的世界里，如果你可以从脚本写起，实现共识、加密、激励，不一定重建全部细节，但一定要理解现有系统为何那样设计，就差不多了。
要注意，智能合约的编程语言不在真理的范畴之内，无论是比特币脚本、Solidity、Move、Cairo，都只是表达交易逻辑的 DSL，都是在用不同形式，定义区块链执行交易的规则，很重要但是还没到 “真理层”。
非要说智能合约的真理层，可能可以表达为一个确定性的状态转移函数，无论语言如何变化，这个 “真理” 都始终存在：
State_t+1 = f(State_t, Transaction)下一个状态来自于上一个状态加上一些交易引起的状态变化，简单吧。但我们这篇文章重点关注区块链世界中的 “王垠式真理”，所以依然是三大真理：共识、加密、激励。
2025-10-24 00:55:34
到目前为止，最新的 AA（Account Abstraction）钱包规范仍然是基于 EIP-4337 实现的。
对于 AA 钱包存在的问题，像操作繁琐、Bundler 中心化、可用性低、生态支持不完善、合约安全风险高等表面上的问题就不多说了。
一句话描述 AA 钱包在干什么事情：AA 钱包能实现 “对账户资金的授权” 与 “把交易广播到链上” 这两个行为的分离。
AA 钱包的功能，体现到具体的交易行为上，就是如果没有 AA 钱包，你得自己发交易。有了 AA 钱包，你可以只签名，不发交易，让其他人代替你把交易发到链上就行。
为什么 AA 钱包能做到这一点？因为 AA 钱包本质上就是一个合约，所以你会发现，AA 钱包的大多数 “优点”，其实是智能合约本身就具备的功能，像什么社交恢复、批量操作等。唯一能带来特殊体验的，只有 “代付手续费” 这个特性。
那为什么 AA 钱包能实现代付手续费这个功能？因为 AA 钱包的所有操作实际上不是交易，而是 UserOperation，有一个链下的 Bunlder 程序会把这些用户操作，通过发交易批量提交到链上。
为什么以太坊需要 AA 钱包？因为以太坊的共识层协议要求，交易必须由一个 EOA 地址来发起。这个 EOA 地址，就是交易结构中的 from 字段，以太坊节点会从这个 from 地址计算手续费、扣手续费、验证交易有效性等。
合约没有私钥，交易不可能由合约发起。在这样的规则约束下，就导致以太坊所有的链上行为，都必须由某一个 EOA 地址来发起交易。
你可能觉得不对，部署一个合约，然后让合约来验证 data 里得签名数据就好了。data 里的签名数据，未必需要和发起交易的地址一致。
没错，事实上，AA 钱包的发展链路是：meta-transcations -> EIP-2771 -> EIP-4337。
这些方案在解决的问题本质上都是：如何让使用资金的权限，与发起链上交易的行为分离。
而引起这一系列复杂协议的根源，来自于以太坊 “交易必须由一个 EOA 地址来发起” 的规则。
为什么以太坊要有 “交易必须由一个 EOA 地址来发起” 这个规则？
因为以太坊的账户模型，是账户-余额模型。协议必须要知道，一笔交易的手续费从哪里扣。
比特币的 PSBT 交易格式，可以实现原生的多签。功能是多个钱包只负责签名，最终由另外一个钱包把交易广播出去就可以。
多签交易，就是典型的把对资金的授权，与广播交易行为分离开的场景。
为什么比特币不存在以太坊的这个问题？因为比特币使用的是 UTXO 模型，交易根本没有 from 地址，有的是多个输入脚本，节点只需要校验交易是否符合脚本的解锁规则，而不需要考虑手续费从哪里扣的问题。
我们梳理一下这个链条：以太坊使用账户-余额模型 -> 交易必须由 EOA 地址发起 -> 需要 AA 钱包。
AA 钱包在干的事情，实际上是在给以太坊的账户模型打补丁，为了修补账户-余额模型相比 UTXO 模型的不足，才有了 AA 钱包这个东西。AA 钱包是在不涉及以太坊协议变更的前提下，诞生出的一种 workaround 方案。
从地位上来说，AA 钱包对于以太坊的地位，类似于铭文/符文/RGB 对于比特币的地位。在比特币生态里，因为没有图灵完备的脚本，所以在不触及比特币协议变更的前提下，搞出了铭文/符文/RGB 这些 workaround方案。
AA 钱包需要链下的 bundler 来提交交易，与符文需要链下的索引器来维护符文的数据状态，是不是一个意思，都严重依赖于链下的程序？
而事实上我们都知道，比特币生态的玩法，至今都还没有被主流社会认可。
假如 AA 钱包未来有一天能被社会大众认可，那也就意味着 workaround 方案在区块链世界中是可行的。对于整个生态的叙事都将引起巨大的改变。
综上所述，我们能得出的结论是，以太坊永远不可能支持 “原生” 的 AA 的钱包（在协议层面支持）。
这些结论，对于技术人员的指导意义在于：
2025-10-13 17:22:58
MCP（Modal Content Protocol）是 AI Agent 在使用的一种协议规范，用于 AI 和外部的工具进行交互，MCP Server 则是具体执行外部交互的组件。
MCP 区块链的含义是，首先它是一条区块链，然后每个节点都原生支持 MCP 协议的 RPC 接口，可以直接接受来自 AI Agent 的请求。每一个 MCP 请求，都是一笔交易（智能合约调用），这也就意味着，区块链会记录下所有的 MCP 交互历史。
节点内部的 MCP 执行引擎，功能分两部分，对于内部交互（EVM 在干的事情），只需要维护好内部的状态转移，把结果写入本地的 KV 数据库就可以了。对于外部交互，则只记录下要执行的请求本身，先不做外部调用。那么实际上对于每一个请求，都会改变本地的状态，所以这些交易是可以重放的，也就可以根据哈希值来确认节点数据的完整性。
至于对外部的执行请求，可以由外部的执行节点（一种角色）来完成。每一个外部请求都包含一些详细的参数，比如需要几个执行者、结果如何验证。交易会把一部分手续费作为执行费用，奖励给执行节点。如果执行节点作恶，自然也会有相应的惩罚机制。
对于外部的调用，关键在于如何验证外部执行的结果，这个问题可以交给调用者来定义，比如要创建一个 GitHub 仓库，验证方式就是，可以通过 API 查询到这个仓库的信息。
这就是 MCP 区块链的大体思路。
解释一下这个想法的来源。MCP 区块链并不是想要 “把 MCP Server 去中心化”，而是想要 “给区块链带来与 AI 交互的能力”。这两种动机是截然不同的。
这个想法背后的逻辑很简单，比特币其实有脚本，只不过是生硬的操作码形式。以太坊干了一件很厉害的事情，给操作码加上了编译器，让开发者可以用编程语言来表达操作码。那么如今的 AI，很厉害的一点在于，打通了从自然语言到编程语言的路径。也就是说，未来的区块链，也许可以做到自然语言直接与状态机交互，而不需要经过 自然语言 -> 编程语言 -> 状态机 这样的路径。明显编程语言是一个中间层，MCP 区块链的设想在于消除这个中间层。
另一个边界在于，让区块链完全按照自然语言的意图执行是不切实际的，因为哪怕是人类，也需要书面形式的合同这种东西，所以代码本身不会消失，状态转移也不会消失。目前能够实现自然语言和状态机直接交互的技术方式，就是 MCP。
最近在思考一个问题，区块链的下一个技术趋势是什么？能明确的几个事实是：
行业内已经提过的方向也都不大有机会，DeAI、ZK、Layer2、DeFi、跨链、RWA、GameFi、BaaS、NFT、元宇宙、DAO、DID 等等，都是陈词滥调了。
所以区块链在技术趋势上，需要的一个原语级别的新叙事。
2025-09-20 18:47:37
最近一段时间的工作，我几乎所有的代码，都是 AI 写的，我不再需要自己动手写代码，哪怕只是一两行代码的变动。
我只需要告诉 AI，我需要改哪里，期望的效果是什么，AI 完成的效果就很好，而且 AI 的效率很高，也不怕累，AI 技术的发展，真正实现了解放我们双手的愿景。
这不由得引起一个思考，AI 会取代程序员吗？王垠的课程，能够帮助程序员抵抗这种来自 AI 的冲击吗？
如果你用过 AI 写代码，就会明白目前的 AI，还不可能真的取代程序员，因为很多事情做不了，很多事情会做错，需要人为判断。
但即使是在短短半年前，把项目完全托管给 AI 来开发，都是不敢想的事情。半年前，我在工作中还是手动复制 AI 写的代码的模式，因为不敢让 AI 直接动项目。但是现在，AI 的 Agent 模式已经真的可以投入使用。我印象里 AI 的 Agent 模式也就今年才出现。
而且比起两年前，现在 AI 的发展速度更是非常可怕。两年前还是 GPT-3.5 的时代，不能识别图片，文本处理也存在很多幻觉。经过两年时间的发展，现在 GPT-5 的能力已经非常厉害。
所以 AI 的水平很高，虽然现在还没有特别高，但是真正让人害怕的，是 AI 的进化速度。
我自己的主观感受上，还是 GPT-5 模型最靠谱。
因为我有正事要干，没有那么多时间去试错，Claude Sonnet 4 给人的感觉就是手过于勤快，方案还没定，代码写出一堆，删都删不过来。他自己给出 A、B、C 三种方案，结果在描述方案的过程中，就把三种方案的代码全写了。相比之下，GTP-5 就好一点，会先问你用哪种方案，然后再动手。Gemini 2.5 Pro 没太用过。
我用的编辑器是 VS Code，装了 GitHub Copolit 和 ChatGPT Codex 两个插件，这两个插件都选择 GPT-5 模型。Codex 用来执行复杂任务，Copolit 做轻量级的改动。
所以我对于 AI 编程的感受主要来源于这样的使用环境。如果你用了其他的模型，或者其他的编辑器、工具，可能会跟我的感受有出入。
回到正题，我们的话题是，王垠的课，能不能抵抗这种来自 AI 的冲击？
首先是 AI 到底冲击了哪些程序员。最大的冲击是对于 3 年以下工作经验、对业务场景和技术选型都没有判断力、工作内容以领导安排为主、自己动手实现代码为结果的程序员群体。
AI 最擅长的，就是在业务场景清晰、工作目标清晰的情况下，完成代码。所以以前在公司里的小组长，有花费口舌跟新人讲清楚需求的功夫，完全可以跟 AI 描述清楚需求、AI 就把活干了。而且 AI 态度比人好、动手能力比人强、写起代码来比专家都专业。
目前的 AI 还不能取代的是在复杂业务场景下、需要对技术选型、技术方案做决策的程序员。不过这些程序员本身已经不太是基础的技术岗位，通常已经不怎么写代码。
所以进一步明确，我们在讨论的话题是，对于需要动手写代码的程序员来说，王垠的课，能不能提高这一类程序员的竞争力，抵抗至少是延缓 AI 的冲击，比其他程序员晚一步被淘汰？
我按照之前一天一道题目的计划，第三轮做练习题，最近刚做完链表相关的部分。
（题外话，想想在面试过程中，凡是让你现场写代码、做题的公司、面试官，是不是都挺扯的。不信你随便拿一道王垠出的练习题，给那些人做，你看他们能不能做出来。所以建议大家，凡是面试流程中需要做题的公司，无论面试是否通过，一律马上拒绝。）
我在 4 年前就自己写过 链表反转 之类，但是用了非常笨拙的写法，一个节点的上一个节点指向哪里、下一个节点指向哪里什么的，来对链表进行各种操作。
王垠课程里的链表，利用纯函数式的写法，以及递归的思想，代码非常简洁优雅，完全不需要考虑上一个节点、下一个节点这种东西。即使已经是第三次面对这个题目，因为已经忘了之前是怎么做的，我也很犹豫，链表反转是能用一两行代码实现的吗？终于在第三次做出题目后，才明白真的可以简单到这种程度。
所以我想说的是，王垠的课程，思想大于形式，真正能教会你的，不只有表面的知识那么简单。
同样的链表反转，初级程序员写出来是一个样，高级程序员写出来是另一个样，真的会不一样。也许表面上代码都能运行，都能达到目的。但是当面对更复杂的系统设计问题，是不是也应该尽可能做到简洁、优雅、清晰、可靠？
当你见识过最清晰的反转链表应该怎么实现，你就知道，噢，链表反转有着各种各样的写法，复杂的写法往往存在这样那样的问题，事实上问题的解法可以更优雅。
当你面对一些复杂的功能需要实现，你可能会用同样的思路去思考，是不是有更加简洁优雅的方式，来干这个事？
你只有见识过更好的东西，才能明白，什么东西更好。
AI 可以帮你干活，但是不可能代替你水平高。
当你没有见过更好的东西，你可能不知道什么是好的，想象不出什么是好的。然后你去告诉 AI，你帮我写一段很好的代码出来，AI 写了三个版本，你都不满意，最后 AI 问你，什么是 “很好的代码”？你自己也不知道。
就像我在《一个集成 Geth 和 CometBFT 的兼容层》中提到的观点，AI 可以替你干活，但是 AI 不可能代替你懂。
你可能想问，AI 帮我把活干了就行，我为什么非要懂？我不在乎代码的好坏，事实上也没人在乎，老板不在乎，客户也不在乎。只有一些自以为是高人一等但是没有实权的老员工、小组长在乎。
这其实正是我想说的，王垠的课，不局限于代码，而在于思想。
说实话，王垠课程中对于代码形式上的规则，几句话就可以说清楚。而且大部分王垠在之前的文章《编程的智慧》中都写过。（我发现现在文章被删掉了，看起来王垠删掉了很多有价值的文章）。
真正重要的不是明面上的规则，而在于课程是如何对知识化繁为简的，为什么这样是好的，那样是坏的。
同样的思想，可以迁移到其他问题上，什么是好的，什么是坏的。
你可以不在乎代码，但是始终要面对数据结构、算法、系统架构、复杂度、性能等问题。除非你真的什么都不需要面对。
AI 能解决这些问题吗？能，但是你得给 AI 说明白需求，然后看明白 AI 给你的方案，最后你来决定选择哪一种。如果你看不懂 AI 在跟你说什么，那你就不能控制 AI 了。
还是那句话，AI 不可以代替你懂。
我一直在说 “AI 不可能代替你懂”，这是我自己使用 AI 编程的体会。
王垠在以前的文章《人工智能的局限性》，包括最近在微博上，都描述了他对于 AI 的核心观点，那就是 “AI 没有读心术”。这个和我们日常使用 AI 编程的体会是一致的，你必须非常清晰告诉 AI 你想要什么，AI 才会给你什么。如果你的描述是模棱两可的，你忽悠 AI，AI 也会敷衍你。你说不清楚，AI 就做不明白。
王垠的课能帮助程序员抵抗 AI 的冲击吗？也许可以吧……假如不可以，那该怎么办？