jolestar

用 Gemini Vibe Coding 了一个 AI 作曲的应用，思路是用 AI 来生成曲谱，然后转换成音乐。当前只能转换成 midi，后面如果接个更好的混音服务，效果会更好一些。
这个主要是用来测试 AI 对曲谱 -> 音乐的映射的理解，我测试下来发现还不错，只是我的音乐水平有限，是否有玩音乐的推友，可以试试给个反馈。
这是视频演示：
这是试用地址，需要 Google 账户登陆

x402 v2 发布，这不是一次简单升级，而是把 x402 从「一套实现」，推进为「一套可演进的标准 + 可插拔的参考实现」。让 x402 不再只是一个 SDK，而真正像一门互联网原生的付费接口语言。
在 v1 时代，x402 的模型非常简单：
服务端要钱 → 客户端签名并支付 → 服务端验证 → 结算完成。
这个模型很好理解，但也非常“直线”。
一旦你需要更多网络、更多支付方式，或者更复杂的结算形态，你很快就会走到 fork SDK、打补丁、私下维护协议边角的路径上。能跑，但生态很难协同演进。
x402 v2 的核心变化可以压缩成一句话： 它把“变化”从核心协议里移了出去。
变化不再通过“改 spec / 改 core”引入，而是被明确安放在 Extensions、插件式机制（mechanisms）和生命周期 hooks 中。
这一步非常关键，因为它决定了生态中的新能力，能否在不修改核心协议的前提下并行演进。
在这个前提下，v2 的几项变化可以被更好地理解。
首先是协议层：x402 变得更加 HTTP-native。
402 的语义回到 402，本该标准化的支付元数据进入 header；
应用层可以自由返回 HTML paywall、JSON 或任意 body，而中间件和 facilitator 依然可以稳定处理支付语义。这让支付协议第一次真正适配了现有的互联网基础设施。
其次是

让 AI 实现一个挺复杂的特性，我没顾上持续 review，就通过 Vibe Coding 的模式，让它自己加 e2e 测试，然后让另外一个 AI 来 review 迭代反馈。最后报告非常完美，功能都实现了并且测试没有错误。
美滋滋提交 PR，让 Github Copilot review 了一下。结果发现最底层的核心逻辑它给弄了两个版本，一个版本实现了代码但没有 import，实际生效的是另外一个 mock 的版本😅。
Vibe Coding 后面的挑战是如何验收成果，防止被 AI 糊弄。

AI 的两条路径：云端入口竞争，还是用户侧的原生应用？
最近看到阿里发布了通义千问 App，正式卷入 C 端 App 大战。Sam Altman 以前也多次表达过对“超级应用”的执念，不断往 ChatGPT 里塞入各种类社交功能。
在大厂的叙事里，未来的 AI App 似乎注定是当前互联网超级应用的翻版——成为唯一的入口，集众功能于一身。
但 AI 应用的未来，真的会收敛到这一条路径上吗？是否有别的途径的可能？
如果我们把目光从通用的 AI Chat 应用移开，去看看 Cursor、Windsurf 这些编程类工具，集成一下各种 MCP 工具，或许能管中窥豹，感受到 AI 原生应用（AI Native App）截然不同的脉搏。
消失的护城河与全员不安全感
当前的 AI 应用生态，如果用一个生物体来做隐喻，可以拆解为三个角色：
* 大脑（LLM 模型提供方）： 提供推理、决策和基础知识。
* 身体（客户端提供方）： 提供用户交互界面（UI/GUI）和上下文环境（Context）以及记忆。
* 手脚（工具服务提供方）： 提供具体能力，比如搜索、日历、订票、支付等 MCP 工具。
在理想状态下，客户端（身体）把大脑和手脚链接起来，帮用户解决问题。
在互联网时代，应用的壁垒来自两个东西：界面（UI）和接口（API）。用户只能通过特定界面完成特定服务。但当需求可以通过自然语言表达，Promp

Cloudflare 挂了？ 好多网站都挂了， ChatGPT 也因为打不开那个 challenges 挂了。还是我的网络出问题了？

让 AI 重构一个大模块，它欢快的拆出了好几个模块，搞了个新版本。然后让它集成测试，它反复测试好多次，中间模型配额限制到了，给它提升到 200刀的档位。结果最后它删了所有的新模块，然后告诉我还是用旧版本比较划得来🤣。气得我直接开骂，就在聊天框里骂。它又重新开始干了，还说感到用户很生气..

Cetus 被黑客攻击后 Sui 冻结黑客资金，引起了“去中心化”争论。但去中心化是一个连续的光谱，从 Bitcoin 到 CEX，中间还有大量的空间，不同链的解决方案有不同的生态位置，现在是中间地带的解决方案太少而不是太多。Web3 发展到现在，仅靠去中心化的理念已经很难突破了，可以少谈点主义多解决问题。

👍，感觉很适合 AI Agent 发布内容

框架上套框架，framework 的套娃比赛开始了😅

大家在批评向大学生推广合约的做法，但感觉批评估计没啥效果，不如反其道行之，搞个合约模拟盘大赛，玩法如下：
1. 给一笔模拟的初始资金，比如 10000 U。
2. 要求杠杆倍数大于 N，比如 10 ～ 100，算一个权重。
3. 根据仓位比例算一个权重。
5. 存活时间算一个权重。
最后来个排行。看你能在高杠杆，高仓位的情况下，活多少天。我觉得玩过一把之后就理解其中的风险了吧？
保护年轻人最好的办法不是挡着藏着不让他们参与（主要也是挡不住），而是让他们理解和认识到其中的风险。如果一定要经历了风险才能长记性，早经历比晚经历好。

浏览器直接创建一个私钥，不需要任何插件就可以参与测试 nuwa 了

AI Agent 记忆的机会与挑战
OpenAI 宣布全面启用 ChatGPT 的记忆能力( ChatGPT 可以跨会话来根据记忆提供上下文。
记忆带来的机会
记忆功能无疑是增加 AI 应用粘性的一个重要方式。用户切换 AI 平台本来没有太大切换成本，但有了记忆后就不一样了。比如 Nuwa 的设计我就是和 ChatGPT 聊出来的，如果要聊 AI Agent 相关的东西，我都会倾向于和 ChatGPT 聊，不用我增加太多上下文，它就能理解 Nuwa 上的 AI Agent 能做什么，是如何工作的。
所以记忆功能会是后面所有 AI 应用发力的重要方向，包括 AI Agent。既然大家背后都调用的是大模型接口，差距主要出现在两个方面：
1. 工具集 tools：AI Agent 是否可以依赖 tools 做更多的事情。
2. 记忆能力：AI Agent 是否更懂你。
如何管理记忆？
AI Agent 的记忆应该如何管理？把和它所有的回话内容都作为记忆，是一种简单粗暴的方案。更好的方式是让 AI 来管理自己的记忆。Langchain 前一段时间推出的 langmem SDK 就是这个思路，给 AI 一组 tools 来管理记忆，由 AI 来决定什么应该记录下来。
Nuwa 设计的时候也是这个思路，提供了一组记忆的 Action：add/update/remove/compact。每次交互

在Rooch，我们并没有让AI代理访问合同——我们正在将它们转变为合同执行者。
女娲是我们的第一步：具有记忆、资产和身份的链上代理。这不是助手——而是参与者。
提示不仅仅是输入。它是协议。
链上不是开销，而是信任。