Code Monkey // Senior YAML Editor // 擅长江浙菜
Matrix
Joined May 2009
- Tweets6.8K
- Following713
- Followers5.8K
- Likes4.1K
目前泄漏信息看，不是管控面（更可怕），而是 PingCAP 内部的经营管理系统。
静观后续。
pingcap数据泄露还是被暴露出来了(破折号 后是我的点评)：
在 57 个月的统计周期内，PingCAP 的 AWS 总支出高达 $107,195,238.42 美元（约 1.07 亿美元）——就是pingcap购买AWS云服务器等然后部署tidb后卖给第三方客户使用
仅 us-east-1 区域的跨可用区传输费用（cross-AZ transfer）一项就高达 $16,509,714.87 美元。——天杀的AWS 流量费用，不只是跨AZ、跨可用区也是收费的，而且很贵
EDP 折扣（企业折扣计划）：减免了 $10,362,705.51 美元——看起来pingcap 谈了一个很给力的折扣
涉及到的主要大客户，如图
总结：
这令人悲哀地成为了常态:他们会花数百万美元购买花哨的 EDR（终端检测与响应），却任由半千个 S3 存储桶大摇大摆地流失。但这家公司是一家云服务提供商。连对他们各个云服务（AWS、GCP、Atlassian / Jira、Azure）遭受的大规模、毫不掩饰的入侵和数据外泄都似乎毫无察觉，这简直是可怕且极度不负责任的
How far are we from 24/7 automated code writing going live? How far from 2,000 PRs? How do we step into stage 8? Sharing my thoughts and practices.
🧠 Attention / ✈️ preflight / 🧑✈️ logbook / 💉 Mutation testing / 🤔 Humans and AI: arti and fact
距离 7 × 24 自动写代码上线还有多远？距离 2000 个 PR 还有多远？如何迈入 stage 8？分享一下我的思考和实践。
🧠 注意力 / ✈️ preflight / 🧑✈️ logbook / 💉 Mutation testing / 🤔 人和 AI 创和作
一句话，让 Codex 和 Claude Code 都用上 Matt Pocock 的 Skills。⚡
换台电脑、开个新环境，Agent 装好了，Skills 还得重新配。好不容易攒了一套，换个工具又要确认目录、重新安装。初始化环境的时候，这些零碎事还挺打断节奏的。😅
📦 这部分可以交给 skm 管。把 Skills 收进自己的本地库，再安装到需要的 Agent，后面导入新 Skills、查看安装状态、批量更新，也都有统一的入口。新环境拿 Matt 这套起步，一条命令就能把工具和 Skills 一起装上。
👇 下面命令会安装 skm，并先初始化本地库，再把 Matt 的 Skills 链接到 Codex 和 Claude Code：
curl -fsSL raw.githubusercontent.com/al… | sh
# （重新打开一个新 shell）
skm init ./skm && skm deploy --repo github.com/mattpocock/skills… --root ./skm --target codex,claude
🔌 适配也不只这两个：skm 还支持 pi、dsh 等安装目标；Skills 可以从 GitHub、GitLab、Skills.sh 或本地目录导入。工具用的是自定义目录，也可以通过 skm target add 接进来。
Agent 可以换，自己积累的 Skills 接着用。经常折腾新环境的朋友，可以试试 👉 github.com/alswl/skm
今天看到 Zebur 关停的消息，想起来我在上面还有服务在跑，赶紧研究一下对我有什么影响。
Zeabur 宣布将于 2026 年底停止运营。短短两个月，两次严重安全事故，最终击垮了一家开发者熟悉的云部署平台。
整个过程很值得做基础设施的工程师警醒。
第一次：8 月 27 日，一款用户部署的 NextChat 应用成为突破口。黑客利用 CVE-2026-7644 漏洞进入容器，随后发现共享集群内部网络隔离不足，一路横向移动：
用户应用 → K8s 共享集群 → 内部管理服务 → AWS Root Key → 生产数据库。
最终，大量用户环境变量和 API Key 泄露，部分 OpenAI、Anthropic 用户遭遇密钥盗刷。
最离谱的是，一个普通用户部署的应用漏洞，最终竟然能拿到整个云平台的 Root 权限。
第二次：10 月 15 日，防线再次失守。
距离第一次事故不到两个月，旧共享集群再次出现未授权访问，攻击甚至波及 GCP 专用服务器和平台数据库。
虽然第二次攻击的完整技术路径尚未公布，但此前的整改显然没能彻底消除风险。
最终：10 月 17 日，Zeabur 宣布逐步关停，12 月 31 日全面停止服务。
这件事让我想到三个问题：
多租户隔离是 PaaS 的生命线。 必须假设每个租户的容器随时可能被攻破。
凭证管理不能靠信任。 Root Key、长期静态凭证、过大的内部服务权限，任何一个都可能成为灾难的放大器。
安全债不会因为系统被标记为 Legacy 就自动消失。 旧集群只要还在线，就仍然是攻击面。
做 PaaS 的人都知道，真正难的不是把应用部署起来，而是让成千上万个互不可信的应用安全地运行在同一个平台上。
PaaS 卖的是替用户管理复杂性的能力，也承担了集中化的安全责任。
一次应用漏洞不该演变成平台级灾难。而两次事故，也足以让一家创业公司多年积累的信任归零。
#Zeabur #PaaS #Kubernetes #网络安全
Jingchao retweeted
很多人想让我分享一下工作流，我一直没想好怎么分享，因为其实我没有任何的魔法，甚至还特别简陋，总觉得分享出来毫无意义。其实我就是用 Claude Code，然后用官方的 Opus 5.5 模型执行 loop 就可以了。
我会并行执行图里的 3 个 loop，然后每晚抽一点时间铲铲屎（主要是 UI/UX 的问题），然后就没活儿了。
工程师们应该感谢 @yetone 的无私。
也要感谢作者制作视频，我建议还在用 Cluade Code / Codex 手工编程的工程都要反复观看。
这是下一代开发秘籍，绝大部分人都没有摸到这个门道。现在这么一部九阳神功就被放在所有江湖人面前了。
我自己流程完成了其中 70% 的环节，有些方面没有他设计的细致，比如打破测试这个环节，我之前都没有想到。
我自己的 SKILLS 和 specs 目前都是 private 状态，除了隐私安全问题和在线服务生产安全问题，也有一些私心，所以更感慨 yetone 和 magpie 的大方。
非常棒的总结。
提升带宽的核心方法就是模拟传统成功路径，核心思想就是创建循环，最大挑战是是否能洞察工程流程里面的本质。
密度在不断提高，我刚看了一下我大约 1000+ PR 每月（这不是一个好度量指标），离上限还有距离。
停下你手头的所有工作，去提升你的带宽
记得去年年初有一个大模型未来发展速度的估算研究，是按照模型独立解决问题的粒度和时长来算的
当时最前沿模型的能力大概能到几十分钟，长程任务不借助代码框架还很难到小时级别
现在只要是第一梯队的模型，在编写良好的 skill + harness 的辅助下，已经可以很轻松到小时甚至天级别了
这个速度是我切实体会到的，而且随着 agent 和 harness 能力的助力还在不断加速
当模型能独立完成天级别时长的任务时，瓶颈渐渐转移到了人这一边
人对需求的转化能力、验证能力、以及可支配的token成本决定了不同的“带宽”
带宽越大，能够撬动的杠杆就越大
举个例子，能搭建一套自动评估+优化体系，来让 agent/skill 自我迭代优化的人，会比只用模型来 vibe coding 的人拥有更大的带宽
所以最近为什么 @poteto 非常火，是因为她几乎代表了带宽最强的那批人的上限在哪里（她最近写的一篇推文强调“量”很重要）
有趣的是，我认为大厂无限token并不是高带宽的必要条件
你可以仅仅是一个独立开发者或自媒体人，每月仅支付几十、上百美金的订阅费用，也可以通过优化自己的带宽来撬动商业杠杆
而一旦杠杆被撬动，就会有更多token供你消耗，形成一个正向循环
如果还在愁手头token登不完的同学，可能需要首先思考的是如何提升自己的带宽，而不是找更多可供消耗token的场景
做乘法，而不是做加法，才能提升你的带宽上限
Jingchao retweeted
YouMind 创业以来，最近录的这期播客，是最完整的一次表达。感谢出海相对论。
如果你是 AI 应用创业者，这期播客里，可能会有很多同感及一些启发。创业者帮助创业者。
如果你是 AI 用户，这期播客里，也有我的一些 AI 产品使用经验。比如 AI 时代，人何以自处。播客最后会有我的一个答案。
如果你是投资人，听完这期播客，有可能获得一个新的取景框。在寻找大生意的路上，能多关注身边人。身边人可能就是大机会。
立刻收听 👇
xiaoyuzhoufm.com/episode/6ac…
DHH 也难啊，哪有当父亲的会老是责备儿子呢。只能找角度呗。
I've had agents implement and optimize the Campfire web app in Elixir, Go, and Rust. Yes, Ruby is the slowest. I didn't care about that when the pay-off was huge in terms of productivity and developer joy. But if you're no longer reading the code? github.com/basecamp/once-cam…
Readers added context they thought people might want to know
The shown benchmarks use non-equivalent implementations: Elixir routes all DB queries through a single GenServer with Redis for jobs (retained from Rails), while Rust uses in-process queues, omits CSRF tags/fields, and applies other caching changes.
github.com/basecamp/once-…
raw.githubusercontent.com/basecamp/once-…
github.com/basecamp/once-…
github.com/basecamp/once-…
x.com/zachsdaniel1/s…
在大家都不看代码的时代，我倒觉得有些内容还是要 Review，不限于代码，可能是 Design Doc，也可能是全局 Milestone。我们还是需要一个有效的手段，和其他人，或者 Agents，进行交流。
PR Comments 一直是我喜欢的方式。我仍然想在这个狂躁的时代保留更多思考和交流。
和人需要，和 Agents 也需要。当同时和 20-30 个 Agents 协作时，找到一个高效的交流工具就更有必要了。
于是我最近把 fude.nvim 引入了我的 Neovim。
github.com/flexphere/fude.nv…
我可以直接在 diff 里看内容、留评论、标记已看；下一轮回来继续。不必等 PR，也不必把反馈散落在聊天窗口里。
它的本地审阅记录会写进 .fude/，我会把它加入 .gitignore。这不是 GitHub Review 的替代品，恰好相反：先在本地把明显问题清掉，PR 留给真正需要协作的讨论。
side panel 里能看审阅范围、文件和 viewed 状态。评论写到一半退出会保存草稿，重启 Neovim 后也能回来。fude 也有一个 SKILL 可以让 Agent 快速协作，查看和回复评论。有些场景我会让 Agent 来通过评论指导我阅读设计和代码。
一句话：Review 从来都是重要的，既看代码，也看决策；用最熟悉的工具管理交流记录。
