秋田散人
@akitabtc
Entrepreneur in Bitcoin industry, MEV searcher，链上大宗贸易，分享一些技术视角下的商业见解。
1.3K 正在關注 11.7K 粉絲
grok bot 用来开户是真挺牛逼的。我用他测试了一下注册一个美国公司，税务、通信、银行券商户头、甚至 AWS 美国 startup 免费的 5000 刀额度都能帮忙做，方方面面都很周到。
看原理是后台有个用户专属虚拟机 + Chrome + 1Password，能存你信用卡和注册密钥，然后用类似 oai computer use or 按键精灵的技术操控远程屏幕——于是乎几乎所有 app 的账户注册以及支付都能自动化了。
顯示更多
今年做的 trading stack 基本上是一个 3-5 年内业内竞争都难以饱和的业务，因为充满了脏活累活，以及纯粹的腿脚业务，低效定价遍地。但也正是脏活累活的密度，使得有一些固定的时间壁垒没有办法被一个聪明人 + agent 组合轻易逾越（这个事在当代比较关键）。
从业务复利角度当然是我比较喜欢的，因为把握了一些确定性赢面，在旅途中是比较舒心的。但其实更大的还是在于实践复利，还是在 agent workflow 的熟练定义上面。
这是这个时代真正的金铲子，以及真正的经营平权，代表了你控制和组织顶尖算力智力（同时最大程度压缩成本）的经营和管理水平——而不需要透过一个粗糙的金融信贷体系和草台人力班子白手起家 or 乘风破浪。
老实说为了掌握这一点，经营什么也并不是最重要的，只是说你必须通过一个正向的业务不断去佐证经验。
为了认知正确，保持不脱产、不和市场脱节是很重要的。
工程出身的人喜欢 general & consistent model，喜欢可以到处铺开和无限复用的东西，如今把自己和业务 24/7 扔进新兴的算力组织架构里，就是这么个东西。
太多的 alpha 可以捡取，太多的实践范式可以复利终身。
顯示更多
其实还在持续更新智能合约就已经说明问题了，onchain 是 Polymarket 立足于这个领域的根基。没有 token 的话这些嬉皮士的梦是失败的。
这是我在 Polymarket 上交易两年以来体验最差的一周，宕机了五六次以上，每次都是数据库问题，一停就停 2 小时甚至 5 小时。讽刺的是今天开始居然正式推永续合约产品线了，很好奇基础架构和撮合引擎这种水平怎么接永续合约。
我推断有两点，一是世界杯以后基本上团队是松懈了，按理说流量再大数据库压力再大，不可能比两个月前大吧；二是团队内部现阶段属于 ”创业果实瓜分阶段”，大概率是出现了一些利益分歧（比如公募变现还是私募变现问题），导致技术或者商业模块动荡交割，原来负责某块问题的人甩手掌柜了。
否则不能是如今这样。
顯示更多
堪比收到空投了。
We’re introducing Claude Fable 5.1 and Claude Mythos 5.1.
They're the world’s most advanced models for coding and knowledge work.
其次要有一个直接面向终端产线、专门管理终端发布 yaml（比如 Kuberntes yaml/env config map 之类）的 CD server 作为 agent-based 开发流水线的终点。你可以面向 env 做很多数据抽象和归类，也就是更接近实际业务描述的 config map，降低碎片化的 env 配置和发布管理成本，以及配置出错概率。
这个 server 会不断 sync 最新 env 配置（即你的生产意图）到产线。并且每一次 agent 在发布流程中授权操作 env 变更都需要向你提供变更对象的 deeplink（这个 CD server 的基本功能），在 PR 评论区留档。你必须明确他改了什么，以及如果你以后自己操作要怎么改，在哪里改。
从 agent 管理哲学上来说，这个 server 是你传递实时意图到产线的关键。agent 不擅长处理紧急事务（比如 kill 开关），更擅长回溯与筹划，最终以及最敏捷的运维权利还是要放在自己手里。
——这个是整件事能够高度自动化的关键。自动化不代表你放弃你该持有的掌控资源的权力，更不代表放弃你该担负的盈亏结果的义务。一旦放弃权利与义务（所谓的 agent 全委托），那么即使这个系统代码写得再好，到产线上也是一团散沙（这也是为什么有些 trading agent 在经济逻辑上根本不成立的原因，本质是跟单与 trust fund）。
这样你的机器才真正有可能成为你的器官、你的双手，成为你向市场表达交易意图的直接方式，而不是仅仅是你的一个活跃在你大脑以外的消息代理。
顯示更多
补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。
另外有几点小经验就是：
1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。
2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。
3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。
顯示更多
补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。
另外有几点小经验就是：
1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。
2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。
3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。
顯示更多
btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理：
1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。
2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段）
3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。
4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。
——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。
而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”——PR 评论区就是最好的跨期开发对话记忆载体。
顯示更多
我认为如果我是早期 claude cli 和 codex cli 的作者，针对运维部分的训练我一定是会采纳大量 AWS/GCP 的官方和社区资料的。并且我的用户也不断在帮我 training 这些 AWS 产线上的运维经验。作为一个 agent provider，我对 AWS 这个语言体系下的所有变化都门儿清，坑也熟悉，因此能提供最高的问答质量和操作精度。
很多时候，用户端的交付，不是产品交付，而是经验交付。也不是技术的问题，而是市场磨合（用户持续验证）的问题。正如比特币和以太坊在各自领域不可替代一样，长时间高强度的市场验证，等同于产品质量和可信度。
顯示更多
我认为如果我是早期 claude cli 和 codex cli 的作者，针对运维部分的训练我一定是会采纳大量 AWS/GCP 的官方和社区资料的。并且我的用户也不断在帮我 training 这些 AWS 产线上的运维经验。作为一个 agent provider，我对 AWS 这个语言体系下的所有变化都门儿清，坑也熟悉，因此能提供最高的问答质量和操作精度。
很多时候，用户端的交付，不是产品交付，而是经验交付。也不是技术的问题，而是市场磨合（用户持续验证）的问题。正如比特币和以太坊在各自领域不可替代一样，长时间高强度的市场验证，等同于产品质量和可信度。
顯示更多
是的，就是需求端和观测端的优化，根据市场变化，根据需求目标和可用性目标定义出特定的监控指标。流水线运维标准和框架制定其实还都是一次性的，可以慢慢随需求规模改，就那么些东西。但真正滚动的还是还是获利和降损需求本身，要持续对市场敏感，那么系统的播报流、监控项、从日志聚合出的数据面板就要更精准有效，不能让自己失去对系统的感知。这一点上是 Kubernetes 和 Datadog 的价值，运维维度拆分得特别明确。
顯示更多
是的，就是需求端和观测端的优化，根据市场变化，根据需求目标和可用性目标定义出特定的监控指标。流水线运维标准和框架制定其实还都是一次性的，可以慢慢随需求规模改，就那么些东西。但真正滚动的还是还是获利和降损需求本身，要持续对市场敏感，那么系统的播报流、监控项、从日志聚合出的数据面板就要更精准有效，不能让自己失去对系统的感知。这一点上是 Kubernetes 和 Datadog 的价值，运维维度拆分得特别明确。
顯示更多
btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理：
1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。
2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段）
3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。
4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。
——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。
而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”——PR 评论区就是最好的跨期开发对话记忆载体。
顯示更多
是的，github issue/pr 其实就是项目的外挂记忆/图书馆，本地一定要配置 gh （github cli，为了本地 agent 高效和 github 通信），如果我来写 coding agent 产品应该会把这东西 cache 进来吃透先来理解整个项目。PR merge 一定要走 squash merge，因为自动合成的 commit message 里会自带 PR/Issue ID，变向成为了注释指针。给 agent 简单通过 git blame 就能索引这个图书馆。
顯示更多
参考 @akitabtc 的思路，最近把所有项目的memory都迁移到了各个项目的github里，作为issue记录下来。
之前都是直接新启动一个项目就开始蹬，memory越积越多，经常会在memory里记录一些遗留bug、调研过但未实施的方案等等。
迁移之后一个好处是正规化了，按开发流程来，解决完之后提pr，merge之后会自动关闭issue，相当于用开发流程保证了记忆的清理机制；
再一个是实现了云记忆，因为在多台服务器上做云开发，统一把memory搬到github不会造成记忆割裂；
有了云记忆之后，就可以专门搞一台机器配上专门的Claude/Codex订阅做开发自动化，定时扫描issue的优先级和状态，自动进入开发流程，写完代码提pr，最后人工审核review上线
顯示更多
不骂了，这几天 updown 和 sports 都要上了。
Hyperliquid 也真是奇怪，上了 HIP-4 现在连一点维护市场 topic 的动力都无了，写一些创建和结算脚本很难么——想建别墅大连排，但只有沿街门面房的执行力。
顯示更多
中国的青年才俊们组成的团队，很多时候就是一个随机的 idea 觉得自己团队要用（或者自己要用），但市场上没有什么现成的好用的就干脆自己重写一个，用得好了就干脆推广出去大家一起用。
于是一个小的 “side project idea” 就可能主导了一个新兴的赛道角落或者产品方向。纯粹的技术端算力过剩、技术人从自己需求出发，倒推到受众端和产品端。
就像梁老板说的，做了许多技术哲学层面更高维度的事情（LLM，AGI 之类），再看这些下游应用事务的处理是游刃有余的，to C 业务我们这几年赶都赶不走。
顯示更多
很欣赏字节的工程师/产品团队们，写出这么多好用的又看起来跟主营收没太大关联纯效率导向的刚需作品来（包括飞书）。
很欣赏字节的工程师/产品团队们，写出这么多好用的又看起来跟主营收没太大关联纯效率导向的刚需作品来（包括飞书）。
如果一个人的成就达成而被许为 “气运之子”，那其实是没有成就。
还是很难想象现如今只需要 7-10 个 Claude 账户（以用满每月每周的 Fable 额度为基准），仅一万人民币每月，就可以试探一个人的视角、开发和组织能力边界。
在自己的支付范围内，全力把这个劳动力杠杆开起来吧，没有比这件事更能在现如今称之为“套利”了。
你可以理解为资本市场现在在给当代人广撒空投，20x 套餐实际背后的token成本是可用工作额度（换算为同等劳动力价值）的 n 倍。
曾经创业（or 产品发布）需要花大功夫，甚至需要压上过去10年的积蓄以及未来 10 年的现金流，把一帮合作氛围恰到好处、各自领域的“能力者”拉拢起来，承接各类市场摩擦并且倚靠不稳定的人性构建一个有纪律章法的队伍——这事儿本身试错成本和赌注巨大。
现在你一个人能把绝大部分事情做到 90 分挑不出毛病，不依赖于外部，几乎不损耗现金流，从业结果其实是高度可预测的，高度和你自身挂钩的，“气运”的决定因素衰减。
大量视野广泛并且能对自己决策负责的人会从这个市场里“高度确定地”脱颖而出，没有人能拿“衰”（甚至出身）给自己做解释，必定是自己在担责和开拓能力上出了问题。
顯示更多
还是很难想象现如今只需要 7-10 个 Claude 账户（以用满每月每周的 Fable 额度为基准），仅一万人民币每月，就可以试探一个人的视角、开发和组织能力边界。
在自己的支付范围内，全力把这个劳动力杠杆开起来吧，没有比这件事更能在现如今称之为“套利”了。
你可以理解为资本市场现在在给当代人广撒空投，20x 套餐实际背后的token成本是可用工作额度（换算为同等劳动力价值）的 n 倍。
曾经创业（or 产品发布）需要花大功夫，甚至需要压上过去10年的积蓄以及未来 10 年的现金流，把一帮合作氛围恰到好处、各自领域的“能力者”拉拢起来，承接各类市场摩擦并且倚靠不稳定的人性构建一个有纪律章法的队伍——这事儿本身试错成本和赌注巨大。
现在你一个人能把绝大部分事情做到 90 分挑不出毛病，不依赖于外部，几乎不损耗现金流，从业结果其实是高度可预测的，高度和你自身挂钩的，“气运”的决定因素衰减。
大量视野广泛并且能对自己决策负责的人会从这个市场里“高度确定地”脱颖而出，没有人能拿“衰”（甚至出身）给自己做解释，必定是自己在担责和开拓能力上出了问题。
顯示更多
这几代领导人中我还是最欣赏朱的，他面临的经济执行层的条件背景是最苛刻的。
“比特币没有什么创新，只是之前技术的组合”，
“ChatGPT 没有什么创新，只是之前技术的组合”，
我寻思什么工业创新不是之前技术的组合呢...
