jolestar (@jolestar)

Most slides AI create locked artifacts. So I built Starry Slides — an open-source tool for creating fully editable HTML slides. Built for the agent era: - HTML as source files - Fully editable with a WYSIWYG editor - No built-in templates — the input context defines the design - Works with your own agents and workflows The goal: Content creation should feel more like human–AI collaboration than one-shot generation. Quick demo ↓

求职（求转发 我最近两年在云南本地&加密业内从事公益； 2021~2024 间陆续在两家 Tokenfund 工作，主要负责研究、案源、投后和投资者关系； 更早在 memecoin 做 marketing ; 加密行业前我在外贸工厂做直播策划。 我能对多种人、事、物保持长时间的、低度的兴趣，并以此幸运的交到很多朋友，特别帮助到案源、投后、投资者关系方面的工作。 我长期关注 DAO 治理、关注加密行业与各国当局的政策博弈，部分预言了 @arbitrumdao_gov 最近行为的后续影响。今年部分研究内容请移步我的账号文章列表。 我寻求任何 to G/policy 相关的 internship 或 VC/生态/公益相关的 senior 职位。

上一次做 benchmark 遇到 Agent 读取文件的问题， 然后做了分析和优化。按照当前 Codex/Claude 的实现，单文件最好保持在 500 行以内，这样可以保证 Claude/Codex 有需要的时候可以一次性加载进来。 Agent 读取文件的时候，读取的太长了就会触发压缩，它会做截取。如果正好是被截取部分有用，就会触发 LLM 再次读取。 Codex 没有专门的读取工具，用的是 shell 命令来读取。 Claude code 给了读取工具，读取文件的工具比 Shell 给的额度更宽松一些，但也有上限，但 Agent 经常会自己决定用 shell。 如果单行按照 50 chars 计算，Codex 大约 700 行左右，Claude shell 大约 600 行，Claude FileRead 大约 2000 行。 所以当前保守一些让文件保持 500 行内是最佳的。

和 gpt 交流多了后，自己也习惯用“收口”这个词了。一些任务完成后，但还有一些零碎的事情没搞，告诉它把剩下的事情收口，感觉很自然。我都忘了不用收口这个词之前是咋表达的😅。

AI Coding 时代，好的编程习惯仍然重要 最近做一个 Agent benchmark，发现不能简单地用开发者视角来评估一个编程任务对 AI 的复杂度。 比如一个重构任务：把一个几千行的大文件，按功能拆成十多个小模块。 这个任务对开发者来说其实不算难，主要工作就是移动代码、整理 imports、编译验证，新手也能搞定。 所以想着用一个简单的任务来做一下 benchmark，结果却出乎意料。 Claude Code 判断这个任务比较大，尝试拆了一部分，提了个 PR 写了 Future work 打算分步来。 我自己的 Agent 是“硬上”，往完整拆分的方向推进了更多，但代价也很明显：Token 消耗是 Claude 的几十倍，后面大量时间都花在反复读文件、修编译错误、再读文件、再修错误上。 这让我意识到，人觉得简单的任务，对 Agent 不一定简单。 对人来说，这类重构很多时候就是“把这一段挪过去”。但对 Agent 来说，它要先分批读大文件，记住哪些函数和哪些测试有关，再生成一堆跨文件修改，最后通过编译错误一点点补洞。看起来像机械活，实际变成了一个高 Token、高状态管理成本的任务。 前一段时间看到有人说，AI Coding 时代，拆分模块这些编程原则没那么重要了，反正人也不看代码。现在看，我不太同意。模块边界清楚、文件粒度合适、依赖关系简单，不只是方便人读，也是在帮 Agent 降低任务复杂度。 从另一个角度看，现在 Agent 的读文件和改文件工具，对这种重构也不太顺手。 Coding Agent 改文件，主要还是文本替换。比如 Claude Code 常见的是 old_string / new_string 模式：先给出一段旧文本，再替换成新文本。Codex 常用的是 apply_patch：生成一个类似 git diff 的 patch，表达把旧的内容替换成新的。它们都适合小范围修改，但如果要删除一大段旧代码，或者把一批函数挪到别的文件，模型往往还是要先把原始内容读进上下文，再生成一大段替换或 diff。 所以我后来给 Agent 一个提示，让它先用脚本、sed、perl 这类工具把大文件粗拆开，直接把旧内容删掉，写到新文件中，然后再逐个慢慢修，它的完成度确实高了许多。Agent 默认不会这样做，主要是因为系统提示词里会强烈要求 Agent 用内置工具修改文件，而不是命令行工具。 再往前想一步，Coding Agent 可能还需要更高级的编辑工具。不是只给它一个“替换文本”的接口，而是先通过 parser、LSP 或 compiler 建立代码结构，让 Agent 可以像 IDE 一样做重构：移动函数，删除 impl block，整理 imports。不知道是否有朋友做这方面的尝试。 总的来说，即便是 AI Coding 时代，好的编程习惯还是有价值的。尽量在早期通过 harness engineering，把好的编程习惯变成 Agent 的默认工作方式，比后来再重构的成本要小很多。

铭文是个 Bug 还是 Feature？ Bitcoin 开发者 @LukeDashjr 要禁止铭文（Inscription）的推文引起激烈讨论，他的主要理由是这是个 Bug，会影响 Bitcoin 网络的安全。 Bug 还是 Feature 之争影响深远，如果它是个 Bug，那修复它的版本就是延续了当前版本的正统版本，但如果它是个 Feature，修复它就是要删除这个 Feature，那修复版本就是一个分叉版本，所以值得深入讨论一下。 但一个东西是 Bug 还是 Feature 其实没有客观的标准，关键是这个东西对软件系统有害还是有利。我们从两个角度讨论这个问题： 1. 铭文有没有影响 Bitcoin 网络的安全。 2. 铭文对 Bitcoin 生态是否带来益处。 铭文真的影响 Bitcoin 网络的安全了吗？ 如何度量区块链网络的安全，一直是一个有争议的话题。一个经常被人拿来用的度量的维度是出块节点的数量（miner 或者 validator）。这点上 PoW 系统不占优势，经常被 PoS 推崇者嘲讽。还记得当初 EOS 用的 21 个节点嘲笑 BTC 不够去中心化，不够安全的文章么？ 而 Bitcoin 开发者们经常用的一个度量方法是全节点的数量。为了让个人 PC 都能运行全节点，所以要严格限制区块大小，以及 UTXO 集，以降低全节点的成本。但多少个全节点算够呢？铭文在多大程度上会影响 Bitcoin 的全节点数量呢？反倒从当前的统计图上能看出，大约因为铭文的热度，很多人需要和 Bitcoin RPC 交互，增加了 Bitcoin 全节点的数量。 （数据来源： 从全节点这个角度衡量，也不能说铭文影响了 Bitcoin 网络的安全。 我们再进一步推演一下，保证 Bitcoin 网络安全的真的是那些全节点吗？在没有激励的情况下，用户为什么要运行一个全节点呢？如果我一个人花钱跑几万个节点，是不是可以让 Bitcoin 网络更安全了？实际上我们需要的不是全节点，而是全节点背后代表的人和组织。 区块链是一个公开账本，关心账本是否正确的人越多，这个账本越安全。而用户为什么关心这个账本？因为这个账本上记载了和他利益相关的东西，无论它是 BTC 也好，还是其他什么东西也好，只要他觉得有价值，他就会关心这个账本。 而用户关心账本的方式也并不是只有自己运行全节点一个途径。用户只要直接和 Bitcoin 网络发生连接，就有这个效果。比如用户安装链上钱包，查看链上交易，带来的安全保证就高于用户把 Bitcoin 托管在交易所或者托管钱包里。 而我们能看到的现象是，这波铭文热明显的带来了用户和 Bitcoin 网络更多的直接连接（浏览器钱包），带来了 DApp 应用生态的雏形（网站上挂铭文通过 psbt 链上交易），有更多用户关心这个账本上记录了什么东西了（区块链浏览器的涌现和访问量）。 所以说，即便是从安全的角度，铭文对 Bitcoin 网络的安全是有提升的。 铭文及其衍生协议对 Bitcoin 生态的技术价值 铭文乍一看没有太多技术含量，只是简单粗暴的往 Bitcoin 网络上写数据，还依赖一个中心化的 Indexer。 但我们可以把它理解成一种把 Bitcoin 当数据可用层（DA）的 Sovereign Rollup，只是在这个模式里，由客户端直接写 DA，可以叫做 DA first 模式，而 Indexer 相当于模块化区块链里的 Bitcoin 执行层，所以也可以认为 Indexer 实际上就是 Bitcoin 的 L2。 这个模式的缺点很明显，没有排序器（Sequencer）批量打包交易，用户体验很差，交易费也很贵，没有欺诈证明，安全性也受质疑。如果有技术团队设计了这样一个方案，肯定没有投资人愿意投资，但市场的魅力就在于，用户把它给玩出来了。前一段时间 BRC20 的余额在不同交易所的数据不一致，用户通过发推来社会共识，最终也实现了一致性，正好说明它是可行的。 但这个模式的优点是它是协议先行，先设计公开的协议和数据格式，链上只保存协议必须的数据，执行和校验在链下。而任何一个团队都可以实现一个 Indexer 接入这个 L2 的执行层网络，整个 DA 的数据是共享的。而 Ethereum 的 L2 方案里，每个 L2 相当于在 L1 的 DA 上圈了一块地，各自抢占空间，数据并没有共享。 打个比方就是，如果 L1 相当于一个老国王，L2 相当于老国王的王子们： Ethereum 国王：你们在我的地盘上抢空间，抢用户，谁抢到是谁的，Mev 和 Gas 收益归谁。 Bitcoin 国王：地盘是我的，用户都是我的，交易费也是我的，但数据是共享的，看你们谁能开拓新地盘，让用户去你们的新地盘玩耍。 这会完全呈现出不同的竞争态势。因为任何 L1 的空间总是有限的，如果 L2 没能开拓出新的，让用户信任的空间，那实际上并没有实现扩容。 所以说铭文是对 Bitcoin 作为 DA 的价值发现，同时配合 Indexer 的这种玩法展示了一种新的 L2 的构建途径，对 Bitcoin 生态有重大意义，它是个 Feature 不是 Bug。 可能的解决方案 当然，Bitcoin 开发者们担心的 UTXO 集膨胀的问题也是存在的。但它并不是无解的，因为铭文协议是一种链下共识的协议，只要 Indexer 以及社区达成共识，可以有非常多的解决方案，我这里拍脑袋写几个。 1. 用 Hash 替代铭文的内容。现在铭文包含了各种媒体文件，json 等，体积比较大。但实际上，只要 indexer 层成熟了，完全可以实现只写 Hash 到 L1，原始内容保存在 Indexer 或者用户的钱包里。 2. 设计一套协议，支持铭文在链上和链下之间的迁移。铭文迁移到链下的时候，相当于在 L1 销毁，UTXO 也就消费掉了。如果要再次回到链上，用户需要提供 Off-chain 转移的签名聚合，这样 Indexer 之间就可以校验。 还有一种方式是采用类似 Taproot 那样的稀疏默克尔树的校验方式，来实现链上链下的迁移。这个我原来设计过一个 Ethereum NFT 的迁移方案，但可惜 Ethereum 上的 NFT 是通过 Interface 定义的，不是数据对象模式，很难发挥出这种优势，而铭文的这种模式非常适合。感兴趣的朋友也可以看下这个链接 更多的方案就不写了。我想说的是，技术是一个生态系统，它需要随着用户的使用和反馈来生长。很多创新都不是开发者们在电脑前规划设计出来的，而是随机的尝试，然后和用户的反馈碰撞涌现出来的。 引用我在《语言是一个去中心化系统 接受一个系统是去中心化的，那就得接受它会演化出你不喜欢的东西，也得接受它的演化过程中的各种失败的尝试。 利益相关声明 我个人除了 5 月份体验了一下 BRC20 的 mint，没有持有任何其他的 Bitcoin 上的新兴协议的资产，只是从技术角度看它的潜力和对 Bitcoin 生态的影响。 这篇文章不是投资建议，如果是长期主义者也不需要 fomo，因为这才刚刚开始。现在这些协议发的资产大都属于 meme 币范畴，meme 币能否从有限次博弈变成一个长期的博弈的系统，主要看几方博弈： 1. 早期获利的参与者 holder 是否愿意持续投资生态，给资产提供应用场景，类似 Bitcoin 早期 holder 们投资各种基础设施。如果都套现离场，那就只是一场 meme 游戏。 2. 基础设施提供者能否提供这样的空间和场景。这一方面取决于 Bitcoin L2 等基础设施提供的能力，另外一方面也受包括 Bitcoin 核心开发者在内的 Bitcoin 社区态度的影响。 未来是不确定的，但参与者可以让它变的有确定的可能，这是创业的魅力所在，@RoochNetwork 会在给 Bitcoin 上的衍生协议提供应用场景的方向进行探索。

AI 视角的 Web3 21 年底,一次技术meetup上我分享了一个《元宇宙，Web3，区块链之西北乱炖》的话题，其中做了一个思想试验： 如果 AI 有了自我意识，它是如何看待以及使用现在的互联网？最近 ChatGPT 以及 AI 很火，我把这个思想试验写出来，换一个视角看 Web3，也可以思考 Web3 和 AI 的关系。(1/n)