求职（求转发 我最近两年在云南本地&加密业内从事公益； 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 的默认工作方式，比后来再重构的成本要小很多。

最近关于 x402x 的命名有一些争议，我想用一条推把事实、时间线和技术边界说明清楚，也顺便澄清一些常见的技术误解。 x402 解决的是一个非常基础、但潜力巨大的问题：让 HTTP 原生具备链上支付能力。它本身并不是一个“完成态”的协议，而是为互联网引入了一种新的支付抽象方式，因此天然具有很大的扩展空间。进一步看，支付也不应只是一次转账，而可以与链上行为形成原子化组合，例如支付即 mint、支付即分账、支付即触发合约逻辑。x402x 这个名字，本质上就是社区对这类扩展方向的自然命名，而并非某一个人的专属定义。 下面是整理后的时间线（感谢 Grok 辅助）： 2025 年 11 月 4 日：@NuwaDev 发布 x402x 测试网并宣布项目开源，核心为基于 Settlement Router 的可编程结算扩展 2025 年 11 月 11 日：@yq_acc 发布文章《x402x: Extension of x402》，系统性阐述了 x402 的潜在扩展方向 2025 年 11 月 26 日：@yq_acc 发布其 x402x gateway（alpha），主打多 token、gasless 的支付网关方案，强调快速部署与商户易用性 2025 年 12 月 12–13 日：@0xAA_Science 在 BNB Chain 黑客松发布另一条独立的 x402x 路线，基于 EIP-7702，通过账户委托将支付逻辑下沉到商家 EOA 这里需要专门澄清一个常见误解：路由合约并不必然意味着引入新的信任假设。在 Nuwa 的 x402x 设计中，Settlement Router 的关键参数（包括接收方、hooks、分账规则等）是通过 commit 的方式嵌入到 ERC-3009 的 nonce 中，并由用户在签名阶段一并确认。 这意味着路由逻辑本身已经成为支付授权的一部分，任何偏离该 commit 的执行都会在链上验证阶段直接失败。换句话说，Router 只是一个确定性执行器，而不是一个被信任的决策者，facilitator 或路由合约都无法在用户签名之外篡改结算路径。 在这个前提下，Nuwa 的 x402x 路由模式在信任假设上并没有劣于其他方案，而只是选择了一个更有利于组合性和生态扩展的执行模型。不同 x402x 路线之间的差异，核心并不在于“是否信任”，而在于执行位置与可扩展边界的不同取舍：有的选择通过 Router + Hooks 提供生态级可编排能力，有的通过 Gateway 降低接入与运营成本，也有的通过 EIP-7702 将逻辑下沉到账户层。 因此，这三者只是名字相同，但在技术路径和设计目标上是清晰分离的，也不存在直接竞争或覆盖关系。它们更像是在同一个新协议之上，从不同约束条件出发所展开的并行实验，各自验证着不同的可能性边界。 在这样一个仍处于早期阶段的协议生态中，这种并行探索本身就是正常且必要的。x402 v2 能够快速演进到 Extension + Hooks 的结构，很大程度上正是因为这些实践不断暴露真实需求与设计张力。 随着 v2 扩展机制释放出更大的创新空间，这些看似独立的 x402x 路线并不需要彼此替代，反而具备被组合、被编排的可能性，共同构成 x402 生态向前演化的一部分。 希望这条说明能把事实、机制和边界讲清楚，让讨论回到技术本身。x402 仍在非常早期的阶段，但也正是这些并行、甚至偶尔“撞名”的探索，才让它开始真正具备成为 payment as protocol 的可能性。