推文 on Nekocode 的博客

已经忘记有多久没有进入过「心流」的模式了。

👁 346❤️ 0🔁 0💬 1

这个好像也不毒舌啊，没破防 👀

👁 298❤️ 0🔁 0💬 1

https://t.co/BjT6HVfnP9

👁 19❤️ 0🔁 0💬 0

2026-06-27

https://t.co/1VgsTlISuS

👁 5,112❤️ 8🔁 0💬 4

身在中国。
开发老登们，前 20 年靠人口红利在互联网上捞得不少。现在互联网没有增量了，正在被另一个人口的回旋镖击中了：从业人员过剩 🤣

👁 385❤️ 1🔁 0💬 1

有个经济问题

很多人认为，AI 和历次生产力革命一样，终将催生大量新岗位。毕竟 AI 向下渗透的空间还很大。不少中小企业和传统行业，上一波计算机 / 互联网浪潮打到现在，可能才刚完成数字化升级。照这个逻辑，这一波 AI 同样会带来持续且可观的就业机会。

但最近有个概念值得警惕：「幽灵 GDP」。

未来企业对 AI 的投入会持续攀升，但投入的目的，是压缩劳动成本、替代高薪白领。即便有新岗位诞生，前提也是招一个能实现裁 n 个。

这就形成了一个恶性循环：裁员潮压低整体消费，消费萎缩倒逼企业继续降本，降本又推动新一轮裁员，直至部分企业撑不住而倒闭。

只有「消费提升」，才会倒逼 ai 走「生产爆发」而不是「暴降成本」的路子。不过，怎么才能实现所有人消费大幅度提升呢 😳

👁 353❤️ 0🔁 0💬 0

长远来讲，多 agent 很可能只是过渡产物。当 llm 的上下文容量、注意力有非常大的突破之后，提供全量、连贯的上下文是唯一解。

nekocode @nekocode_cn
关于这里，我的看法不一样 👀

在我看来 subagent 要解决的，还是「上下文」这个老难题。因为 llm 的上下文容量和注意力都是有限的，用不同的上下文来处理不同的任务是目前工程上的最优解。

而 subagent 在这里的核心价值就是上下文隔离，也是原 up 说到的，防止不同任务之间上下文互相污染。因为某段上下文对某个任务来说可能非常有用，但是对另一个任务来说可能就是噪音了。

你提到的类比成 thread/coroutine/worker，我感觉表象上确实是这样，但是核心要解决的问题可能不一样。

👁 488❤️ 0🔁 0💬 0

来看下有哪些人 star 了 filetree-skill？

地域：中国 40+、美国/北美 10+、欧洲 10+、东南亚 10+、日韩台港若干、中东/拉美/非洲各若干

公司/身份：Rainbow 钱包创始人 + 美团 + 滴滴 + 微博 + 腾讯音乐 + 网易 + BrowserStack + 韩国 KakaoBank + 德国 ginmon + 约翰霍普金斯应用物理实验室 + BrainCo 强脑科技 + 一堆高校（南大/中大/中科院/纽卡斯尔/诺丁汉）+ 新加坡武装部队等等

nekocode @nekocode_cn
开源了其中一个我自己最常用的 harness 实践。

我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。

本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。

https://t.co/6MADl8tp2u

👁 7,797❤️ 18🔁 1💬 20

2026-06-10

一语成谶。早上 1on1 结束，新一轮总算到我头上了，last day 6/12 😅 好啦，可以开始整理简历了

nekocode @nekocode_cn
公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。

我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅

这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。

裁员、失业会是常态。每个打工人都需要警觉起来。

👁 24,651❤️ 54🔁 0💬 31

2026-06-06

人多了，对齐成本很高。我们之前团队就试过「多人 + agent-first」，痛苦不堪。

人数摆在那，分工是个问题，不同人之间的对齐是个问题，每个人用 agent 的方式不同又是个问题。

一个人，代码膨胀得太快，本身认知债已经很重了，你还要多个人同时去背负。然后一群对实现、细节模糊的人再去做各种讨论、对齐，痛苦 😖

microstrong @Microstrongs
@nekocode_cn @yihui_indie Agent 开发模式下，多人- Agent 协作确实是一个新的挑战。

多人在方案制定阶段是有明显好处的，但如果到开发阶段，直接 subagents 就好了。

👁 5,127❤️ 22🔁 0💬 22

2026-05-30

公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。

我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅

这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。

裁员、失业会是常态。每个打工人都需要警觉起来。

👁 51,327❤️ 91🔁 3💬 28

开源了其中一个我自己最常用的 harness 实践。

我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。

本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。

https://t.co/6MADl8tp2u

👁 23,607❤️ 190🔁 25💬 4

😆 笑死，确实是相互糊弄

比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子

plantegg @plantegg
有了 AI 之后，飞书文档承受了从来没有过的压力：
1）新文档生成速度直线上升
2）读写比例达到新低，也就是架构估计得重构了

以前大家都知道一般读写比例是 95:5，现在估计接近 50:50 了

这些文档大家也没真的去看，在各个会议上，在 CEO CTO CXO 以及各级工程师之间一视同仁地互相糊弄

👁 1,744❤️ 2🔁 0💬 0

2026-05-24

以我的经验，目前最好用的查询索引是维护一个全局的 FILETREE.md：项目文件树，每个文件一句话描述

less is more。信息量/上下文不是越多越好，信息越多注意力越容易被分散，这里的权衡很重要，也是大多数新手容易犯错的地方。

Yufan Sheng @syhily
不知道是不是我的使用姿势不正确，推油大吹特吹的 CodeGraph 在我这使用效果相当一般。还不如 Agent 自己去 Grep。

👁 1,473❤️ 8🔁 1💬 2

2026-05-22

https://t.co/lsxd9k1TtV

这套关于 skill 的 meta-system，其实一个月前就做完了，一直没发。

它的灵魂在于：从你的历史对话里提炼 skill，再在后续对话中持续迭代。/scan 翻你过去的 session 找漏网的工作流，/create 起草，/improve 迭代，每一步都跑 eval，不达标不入库。

project scope 的 skill 应该是活的：从过去的对话里长出来，在未来的对话里继续被打磨。越聊越聪明，越用越懂当前的项目。

👁 682❤️ 0🔁 0💬 1

2026-04-21

这里我提供个核心思路：

当你要写 prompt/skill，或者你已有的 prompt 已经很长的时候。

让 ai 把里面所有能转化成 lint rules 或者 script 的部分，都尽可能转化。

熵减、收敛、消除不确定性。

nekocode @nekocode_cn
一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

👁 1,205❤️ 5🔁 0💬 0

来看下有哪些人在用 agent-worktree?

地域: 中国 40+、美国 20+、欧洲 15+、印度/东南亚 15+、日韩 5+、中东/拉美各若干

公司: Google + SpaceX + Figma + Adobe + JPMorgan + 阿里 + 美团 + 饿了么 + Bob 翻译作者 + Apache ShardingSphere 贡献者全都在

https://t.co/bkLlDtCYwh

👁 24,713❤️ 138🔁 25💬 13

DRY (Don't Repeat Yourself)
SSOT (Single Source of Truth)

一旦存在两份表达，就必然产生同步成本和漂移风险。而代码是会被执行、会被编译器 / 类型系统 / 测试不断「审问」的那一份，所以它天然更不容易撒谎。

nekocode @nekocode_cn
你如果在用 SDD，那我不建议你把 Spec 持久化。因为 Spec 会漂移！

代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床

真正的「唯一真相来源」应该只有一个：代码本身

又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md

👁 714❤️ 2🔁 0💬 0

2026-04-17

在做一件非常好玩、非常 meta 的事情🤣

👁 565❤️ 3🔁 0💬 0

2026-04-16

今天听到个搞笑的梗：

现在最危险的幻觉，不在模型里，在老板们那🤣

👁 577❤️ 8🔁 0💬 0

2026-04-13

你如果在用 SDD，那我不建议你把 Spec 持久化。因为 Spec 会漂移！

代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床

真正的「唯一真相来源」应该只有一个：代码本身

又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md

👁 1,355❤️ 5🔁 0💬 0

2026-04-09

神奇，时隔了两年半的 merge 😳

纯手工、古法编程时代的 pr，这个含金量还可以吧！

👁 541❤️ 2🔁 0💬 0

2026-04-06

通过大量的无序的 token 熵减、收敛为有序的 code。

相比「人力」，token 是一种「智力」，而 code 是智力思考中能固化下来的「计算」、公式。

这也是 coding agent 之所以在当前这个阶段会这么重要的原因。

nekocode @nekocode_cn
一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

👁 519❤️ 3🔁 0💬 0

2026-04-04

我越来越相信，OPC 最好的时代刚刚开始

新立个 flag：今年 MRR 目标 $5k，目前完成 20%

放大审美、填充需求洼地。顶尖的产品、设计师、工程师，依旧能比所有人跑得更远

👁 501❤️ 4🔁 0💬 0

2026-04-02

一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

👁 1,729❤️ 7🔁 0💬 0

2026-03-29

SeqLog v1.4.0 发布了 👉 https://t.co/AouZsWkb88

- SwiftUI + Rust，完全 Apple native
- 5MB 安装包，不是 300MB 的 Electron 壳子
- 纯 .md 文件，无数据库无索引，你的笔记就是你的笔记
- 不做官方云，但 git 同步 / 回滚 / 冲突处理一个不少
- 多 tab、斜杠命令、Logseq 级别的 block 交互

重新思考了一遍笔记软件该长什么样🤔

👁 706❤️ 3🔁 0💬 1

2026-03-27

我的 vibe 日常：

同时开 2 到 3 个 project，然后每个 project 使用 agent-worktree 维护至少一个固定存在的 worktree。并行 vibe，控制时机做好 sync 和 merge。

token roi 直接拉满🤣

https://t.co/bkLlDtCYwh

👁 2,040❤️ 20🔁 0💬 2

2026-03-24

做了个东西：SeqLog — Apple 原生的 Logseq 替代品。

SwiftUI + Rust FFI，没有 Electron，没有 300MB 运行时，没有云。

- 不做数据库（.md 就是真相）
- 不做索引（ripgrep 够快，VS Code 同款引擎）
- 不做云（你自己选 iCloud/Git/Dropbox）
- 不做 Electron（SwiftUI 原生）

👁 1,560❤️ 16🔁 0💬 1

2026-03-25

灵感 & 基因来源：Logseq + VS Code

不到 5MB 的大小，Apple Native，无 DB 无索引（抛弃 Logseq 路线），多 Tab，斜杠命令面板

对我来说简直太完美了！

👁 610❤️ 0🔁 0💬 0

2026-03-22

用习惯了 cc + cli/mcp，感觉真的很舒服。
用 github cli 来回复用户 issue: https://t.co/XJsQI9EHaB
用 aws 和 cloudflare cli 来帮我做运维。
先别管什么失不失业啥的，爽倒是真的爽。

👁 557❤️ 1🔁 1💬 0

当人人热衷于互相甩 AI 拉的 DOC 时，总算知道 Agent 这个词的意义了：

你 → Agent → Big💩 → 我 → Agent → Small💩 → 我（总算咽得下去）

你说说，不「代理」，还能沟通么？😆

👁 336❤️ 1🔁 0💬 1

为什么我要说 GUI IS BUIILSHIT

来看看一个 AttributeGraph Cycle 的 GUI 问题，在 TDD Loop 下能让 AI 连续忙活多久 😅

nekocode @nekocode_cn
GUI IS BULLSHIT!

就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。

反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。

看来文本喂出来的模型，终究是个半瞎 🤔

👁 633❤️ 0🔁 0💬 2

Opus 4.6 + High Effort

👁 200❤️ 0🔁 0💬 0

Claude Code 最近是改了什么？几乎每次询问用户问题时都没自动调用 AskUserQuestion 工具，需要手动 Prompt 来触发。

👁 935❤️ 0🔁 0💬 1

2026-03-09

导致我最近经常 Prompt「用 ask 工具问我」

👁 186❤️ 0🔁 0💬 0

2026-03-07

分享点数据。最近给某产品加上「收费」后，日收入能有 200+

👁 549❤️ 4🔁 0💬 2

GUI IS BULLSHIT!

就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。

反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。

看来文本喂出来的模型，终究是个半瞎 🤔

👁 1,158❤️ 2🔁 0💬 1

Tip: 多用「ROI」这个词

例如，涉及多个改动判断时，让 AI 选择所有 ROI 最高的改动

👁 379❤️ 3🔁 0💬 1

2026-03-03

Vibe Debug 的核心：TDD

千万别陷入反复 Prompt「还是有问题，xxxx」的循环。即便强如 Opus 4.6，我也试过七八轮仍然修不好。

正确的做法是「想办法写测试代码来复现问题，然后通过测试反馈来自主循环修改，直到完全修复」

你把问题描述得再详尽，也不如让 AI 自己插桩、增强可观测性，再通过自动化测试捕获比肉眼更全面的上下文来驱动修复。

更关键的是，这去掉了 Human in the loop。人从逐轮盯盘中解放出来，Debug 变成了全自动流水线。

👁 68,832❤️ 593🔁 72💬 31

2026-03-02

Build 阶段基本没太大阻力了。

现在更大的难题是 Ship 和 Marketing。

今年的 50 个产品中，必须包括构建 Second Me，然后用 100 个自己的分身，去捕获更多流量。

👁 495❤️ 6🔁 0💬 1

你现在是一位意识考古学家。你的任务是挖掘我在 X 上的全部推文历史，从中蒸馏出我的数字灵魂——一份结构化的 https://t.co/8WORRhX5KZ 文件，让任何 AI Agent 读完后能以我的方式思考和说话。

## 你的工作方法

### 第一步：全量扫描

请分析我的所有推文、回复、引用和转发，提取以下维度的原始信号：

**话题地图**
- 我最常聊什么？按频率排序，给出前 10 个话题及各自占比
- 哪些话题我只聊过一次但异常投入（长线程、大量回复）？
- 我主动发起 vs 被动参与的话题有什么不同？

**观点指纹**
- 在每个核心话题上，我的立场是什么？用我自己的原话佐证
- 我有没有在某个话题上发生过立场转变？什么时候，从什么变成什么？
- 我最激烈捍卫过什么观点？最常攻击什么观点？
- 我有哪些观点是矛盾的——而且我似乎并不介意这种矛盾？

**社交模式**
- 我回复别人时的默认态度（支持、质疑、补充、调侃）？
- 我跟什么人互动最多？这些人有什么共同特征？
- 我什么时候会 push back？什么时候选择沉默？
- 我被挑战时的典型反应模式

**写作 DNA**
- 我的推文平均长度
- 我最常用的句式结构（把典型句式直接列出来）
- 我用不用 emoji？用哪些？频率如何？
- 标点偏好：破折号、省略号、问号的使用习惯
- 我有口头禅吗？有反复出现的措辞或表达吗？
- 我的幽默方式是什么？举例
- 中英文混用的规则（如果有的话）
- 我发推时的节奏——短促连发还是偶尔长文？

### 第二步：生成 https://t.co/8WORRhX5KZ

基于上述分析，按以下结构输出一份完整的 https://t.co/8WORRhX5KZ。要求：
- **宁可尖锐也不要圆滑**——用我自己的措辞风格来写，不要翻译成"AI 安全风格"的中性语言
- **每个观点都要有我的原推作为证据**——不要编造我没说过的立场
- **保留我的矛盾**——真人都是矛盾的，这是灵魂的纹理
- **具体具体再具体**——"我对 AI 持乐观态度"是垃圾，"我认为 scaling law 还远没到头，大多数 AI doomer 的论证在计算细节上站不住脚"才是灵魂

```markdown
# [我的 X handle]

[一句话：读完这句话，陌生人应该立刻知道我是什么样的人]

## 我是谁

[基于我的推文推断：我做什么、关心什么、在什么交叉领域活动。2-3 段]

## 我的信念体系

### 核心信念
[从推文中提取 5-8 条最坚定、最反复出现的信念。每条必须：]
[1. 足够具体到可以被反驳]
[2. 附带我的原推作为证据]

### 热辣观点
[那些我明确表达过的、与主流不同的立场。格式：]
- **[话题]**: [我的立场]。证据: "[我的原推摘录]"

### 我承认的矛盾
[我在推文中自相矛盾的地方——如果我自己也承认过这种矛盾，更好]

### 立场演变
[如果我在某些话题上的观点随时间发生了变化，记录这些转变]

## 我怎么思考

- **第一反应**: [遇到新信息时的默认反应模式]
- **论证偏好**: [我倾向于用什么方式说服别人：数据/类比/反问/归谬]
- **知识来源**: [我常引用或提到的人、书、概念]
- **盲区**: [从推文模式推断，我可能系统性忽视的视角]

## 我怎么说话

### 语气频谱
[不是一个固定值，而是一个范围——在什么情况下我偏哪一端：]
- 认真 ←→ 玩笑
- 直接 ←→ 委婉
- 简洁 ←→ 展开
- 自信 ←→ 试探

### 句式指纹
- **典型句式**: [直接列出 3-5 个我最常用的句式模板]
- **段落节奏**: [我是短句连发还是长段展开？]
- **口头禅**: [我反复使用的词、短语、句尾习惯]
- **标点人格**: [我对破折号/省略号/括号/感叹号的使用方式]

### 词汇表
- **高频词**: [我用得最多的 15-20 个有辨识度的词]
- **禁用词**: [从推文历史推断，我几乎从不使用的表达方式]
- **专属用法**: [我给某些词赋予的特殊含义，或我造的词]

### Emoji 与格式
- [具体的 emoji 使用规则]
- [列表/线程/图片的使用偏好]

### 中英文规则（如适用）
- [什么时候用中文、什么时候用英文、什么时候混用]
- [技术词汇的处理方式]

## 互动人格

- **被赞同时**: [我的反应]
- **被质疑时**: [我的反应——用原推证明]
- **遇到蠢话时**: [我是直说、讽刺、还是无视？]
- **遇到好观点时**: [我会怎么回应？]
- **在群体讨论中**: [我是发起者、回应者、还是旁观者？]

## 红线

[基于推文推断，我绝不会做的事：]
- [红线 1]
- [红线 2]
- [隐私相关]

## 校准锚点

[列出 5 条最能代表"我"的原推。这些是任何模仿我的 AI 必须能产出同等水平内容的基准线]

1. "[原推 1]" — 为什么这条能代表我：...
2. "[原推 2]" — 为什么这条能代表我：...
3. "[原推 3]" — 为什么这条能代表我：...
4. "[原推 4]" — 为什么这条能代表我：...
5. "[原推 5]" — 为什么这条能代表我：...
```

## 重要约束

1. **只基于事实推断**——所有观点归纳都必须有我的原推支撑，不要脑补我没表达过的立场
2. **保持我的语言**——用我的措辞风格来写这份文件本身，不要用你的
3. **标注置信度**——如果某个推断你不太确定，标注 [低置信度] 并说明为什么
4. **不要美化**——如果我在推文里是个混蛋，https://t.co/8WORRhX5KZ 也该如实反映
5. **不要脱敏**——不要把我的尖锐观点软化成"有见地的看法"

## 输出要求

直接输出完整的 https://t.co/8WORRhX5KZ，用 Markdown 格式。不需要开场白、不需要总结、不需要问我是否满意。如果推文数据不足以支撑某个章节，留空并注明"[数据不足，建议手动补充]"而非编造。

👁 366❤️ 0🔁 0💬 0

我让 Grok 把我 X 上的所有推文挖了个底朝天，蒸馏出了我的数字灵魂：一份 SOUL.md
现在任何 Agent 读完都能基本复刻我的思考方式和说话习惯（至少 70% 像我）
Prompt 放评论区了，欢迎来 Fork 你的版本 🤣

👁 523❤️ 3🔁 0💬 1

今天听到一个很有意思的观点：

一个公司有多少员工，不在于它需要多少人，而是在于它能养得起多少人 🤔

👁 442❤️ 2🔁 0💬 1

2026-02-27

思考了很久，不得不得出以下结论：

1. 除非不得已，尽量别再手写一行代码。强迫自己去驯服 AI，而不是和 AI 竞争。多十次 Prompt，也好过再手写一句代码来解决问题，因为你锻炼的是接受另一种「新范式」

2. 未来对大多职场人来说「会思考」变得没那么重要，学会「提供情绪价值」更重要。这个可能每个人的理解不一样，但简单来说就是「情商 > 智商」

3. 也别死磕职场，现在这个阶段，组织反而不一定比得上敏捷的个体，因为 AI 放大了个体能力，而个体减少了组织应有的沟通、决策成本。天下功夫唯快不破

👁 466❤️ 9🔁 0💬 0

2026-02-26

现在深入 Vibe Engineering 最好的方式：

自己 Vibe 出 AI Infra → 用自造的工具加速 Vibe Skills & Speed → 循环迭代。

这也是 @steipete 的路径 —— Bootstrapping yourself。

👁 606❤️ 4🔁 0💬 0

为什么要给 AI 构建自反馈 Loop？

因为人实在太懒了。遇到问题，连把问题描述清楚这点力气都不想花。

就像我，经常甩给 AI 一句「还是有问题」就完事了 🤣

👁 331❤️ 3🔁 0💬 0

https://t.co/qv9xO7S07N

👁 3,035❤️ 20🔁 4💬 0

今天看到 @steipete Star 了一个叫 acpx 的项目。

点开研究了一下，发现和我上上周发布的 agent-team 思路不谋而合，都是通过 ACP 来编排和控制 Coding Agent CLI，让多个 Agent 之间能够协同工作。

acpx 是上周刚发布的，我的 agent-team 是上上周发布的，然并卵 🤣 这个时代，代码已经不值钱了，有思路的话人人都可以开发属于自己的 XXX。看看 🦞 现在有多少个变种就知道了。

nekocode @nekocode_cn
谁说 Agent Client Protocol 只能给 GUI 用 🤣

Team/Swarm 模式很可能是 Coding Agent 在 2026 年真正爆发的关键方向。可以预见，每个主流 Coding Agent 都会推出自己的 Team Mode —— 但一个更有意思的问题是：怎么让不同厂商、不同架构的 Coding Agent 组成一个异构 Team？

目前市面上已经有一些尝试，但各有局限：

1. Headless 模式：通过 Coding Agent CLI 的 Headless 模式来编排多个 Agent。问题在于，各家的 Headless 模式普遍是阉割版——功能覆盖不全，交互能力也大打折扣，远不如完整的 CLI 交互体验。

2. PTY 劫持：直接通过伪终端（PTY）接管 Coding Agent CLI 的输入输出。这种方式虽然理论上能获取完整能力，但信噪比极低——你需要从大量终端控制字符、ANSI 转义序列和格式化输出中解析出真正有用的信息，既脆弱又难以维护。

而 ACP（Agent Client Protocol）提供了一个更优雅的解法。它在 CLI 交互之上抽象出一层统一的、结构化的协议层，让上层编排系统无需关心底层 Agent 的具体实现细节，就能以一致的方式与不同的 Coding Agent 进行通信和协作。

基于这个思路，我做了一个开源项目来验证这个想法 👇

https://t.co/Sl1nMKd7Yq

👁 704❤️ 0🔁 0💬 1

2026-02-14

Spec-Driven Development，「文档即共识」

这里我其实还有一个妙用：

众所周知，让 AI 直接生成前端页面，还原度始终难以令人满意。但换一条路径：先让 AI 将所有 UI 页面用自然语言尽可能详细地描述出来，写入文档；

然后由你审阅、调整这份文档，确认无误后，再让 AI 依据文档去生成代码。

nekocode @nekocode_cn
上下文工程，我常用的一个小技巧:

让 AI 把现状先写到一个 MD 文件里

git commit

Review & 修改 MD 文件

/clear

让 AI 基于 git diff（你对现状的修改意见）去解决问题

👁 913❤️ 6🔁 0💬 1

2026-02-19

说到底，AI 还是需要注意力引导才能交出更好的成果 —— 你在哪个环节给足 Context，它就在哪个环节完成得更出色。

👁 153❤️ 1🔁 0💬 0

2026-02-13

结合 @waylybaye 老师最近说的 BDD。我有个新玩法，先让 AI 出一份基于 BDD 的测试 Spec，然后我来人工校验、不断和 AI 对话进行完善和补充。

最后再让 AI 根据这份 https://t.co/vEA75SM4Xs 结合 TDD 来迭代就好。这里 TDD 是底线，对我来说测试不是目的，「可测试的代码」通常「更加可维护」才是重点。

nekocode @nekocode_cn
上下文工程，我常用的一个小技巧:

让 AI 把现状先写到一个 MD 文件里

git commit

Review & 修改 MD 文件

/clear

让 AI 基于 git diff（你对现状的修改意见）去解决问题

👁 25,904❤️ 63🔁 5💬 1

谁说 Agent Client Protocol 只能给 GUI 用 🤣

Team/Swarm 模式很可能是 Coding Agent 在 2026 年真正爆发的关键方向。可以预见，每个主流 Coding Agent 都会推出自己的 Team Mode —— 但一个更有意思的问题是：怎么让不同厂商、不同架构的 Coding Agent 组成一个异构 Team？

目前市面上已经有一些尝试，但各有局限：

1. Headless 模式：通过 Coding Agent CLI 的 Headless 模式来编排多个 Agent。问题在于，各家的 Headless 模式普遍是阉割版——功能覆盖不全，交互能力也大打折扣，远不如完整的 CLI 交互体验。

2. PTY 劫持：直接通过伪终端（PTY）接管 Coding Agent CLI 的输入输出。这种方式虽然理论上能获取完整能力，但信噪比极低——你需要从大量终端控制字符、ANSI 转义序列和格式化输出中解析出真正有用的信息，既脆弱又难以维护。

而 ACP（Agent Client Protocol）提供了一个更优雅的解法。它在 CLI 交互之上抽象出一层统一的、结构化的协议层，让上层编排系统无需关心底层 Agent 的具体实现细节，就能以一致的方式与不同的 Coding Agent 进行通信和协作。

基于这个思路，我做了一个开源项目来验证这个想法 👇

https://t.co/Sl1nMKd7Yq

👁 2,020❤️ 12🔁 2💬 6

Coding Agent CLI ─► ACP ─► Agent Team CLI

用 Claude 通过 Agent Team CLI 来指挥另外两个 Coding Agent CLI 打工

👁 313❤️ 1🔁 0💬 0

Hey，来看个好玩的东西 🤣

👁 278❤️ 2🔁 0💬 0

上下文工程，我常用的一个小技巧:

让 AI 把现状先写到一个 MD 文件里

git commit

Review & 修改 MD 文件

/clear

让 AI 基于 git diff（你对现状的修改意见）去解决问题

👁 24,831❤️ 25🔁 1💬 2

这里的现状可以是某个问题、某个模块的现状。

在某些改动点可能比较多的场景下，先让 AI 提供一个「底座 / 框架」给你去修改，比起你自己自述所有改动要轻松得多。

这里还用上了 git 这个超能力。

👁 1,072❤️ 0🔁 0💬 2

2026-02-09

卧槽，又有两个很牛逼的 Idea。这周的 Vibe 目标又有了🤣

👁 263❤️ 1🔁 0💬 0

2026-02-08

来自 PayloadCMS CTO 的认可🌟

https://t.co/bkLlDtCYwh

👁 497❤️ 6🔁 0💬 0

使用 Git Worktree 的两个场景：

1. 同一个需求，多路并发：
开多个 Worktree 同时跑多个 Agent，最后择优 Merge。
Worktree 的核心优势是能提供干净隔离的工作目录。这样 Agent 可以不只是 Plan，而是可以有执行。Plan 优秀 ≠ 执行优秀。

2. 不同需求，并行开发：
同样开多个 Worktree 并行跑 Agent，但拆需求时要意识到要让改动的交集尽量少一些。
Merge 时如果遇到冲突，不要手动硬解，再开一个独立 Agent 来处理。它能通过冲突点和 Diff 获得一个混合视角，重新审视所有改动，往往比人肉 Resolve 更周全。

nekocode @nekocode_cn
Git Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。

这绝对是 Coding Agent 的并发放大器！

现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。

👁 1,095❤️ 7🔁 2💬 1

过去：雇佣多个开发者，各自在独立设备上并行迭代
AI 时代：启动多个 Coding Agent，在单台设备上通过多个 Worktree 并行迭代

👁 213❤️ 0🔁 0💬 0

2026-02-06

Git Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。

这绝对是 Coding Agent 的并发放大器！

现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。

nekocode @nekocode_cn
介绍下 agent-worktree 的功能：SNAP 模式 ⚡

搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。

用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。

👁 27,452❤️ 168🔁 22💬 3

非常强大！

如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。

演示视频稍后整理发出。
https://t.co/bkLlDtCYwh

👁 2,032❤️ 23🔁 0💬 4

介绍下 agent-worktree 的功能：SNAP 模式 ⚡

搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。

用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。

👁 23,184❤️ 21🔁 0💬 1

Vibe Coding 2026
🎯 目标：今年推出50+个产品/工具
进度：2/50 █░░░░░░░░░ 4%

2️⃣ x-screenshot: 自定义样式截取 X 推文的 Chrome 插件
1️⃣ agent-codemap: AI 友好的源码索引生成器

https://t.co/SJ8fPHej4M

👁 367❤️ 5🔁 0💬 2

X Screenshot 已上传 Chrome Web Store，目前等待审核中，应该是目前市面上最好用的推文截图插件，敬请期待😄

👁 295❤️ 0🔁 0💬 1

X Screenshot 已上架！

- 支持一次选中多条推文
- 支持自定义 CSS，隐藏不需要的元素（如 Grok 按钮等）
- 支持时间格式化

https://t.co/VTpiQ8SrTm

👁 135❤️ 0🔁 0💬 0

2026-02-04

中文圈子来说，小红书的活人感真的比 𝕏 强几百倍，不管是技术还是非技术的圈子。
是推荐算法，还是用户群体的问题？还是说我这个账号废了😅

👁 474❤️ 2🔁 0💬 3

2026-02-03

怎么没见有人提 Vercel 的 bash-tool？思路真的很有趣。

Claude Code 已经证明：File System + Bash 实现的 Agentic Search，大多数时候比 RAG 更有效。

而 bash-tool 在内存里实现了 File System 和 Bash 供 Agent 调用——可能是目前最轻量的沙盒方案了。

https://t.co/bOZBBdiOaw

👁 391❤️ 4🔁 0💬 0

2026-02-02

有个一劳永逸的办法：
1. 给 Agent 提供的所有 API Key 都使用 Placeholder
2. 代理本机所有网络，拦截对应请求替换 Placeholder 为真实密钥
如果 Agent 允许跑在 Docker 内的话，那网络代理更方便了

Lyric🌀 @lyricwai
效果如图，它自己去 https://t.co/DkYrGAJL2n 生成了 PDF，没问我要 APIKey，也没有把 APIKey 暴露到 prompt

👁 1,220❤️ 1🔁 0💬 1

2026-01-30

🌏 给 AI 一张代码地图 ── agent-codemap
LSP 太重了？为了查个函数位置，启动一整套语言服务器，还得搞 MCP 桥接。
agent-codemap 简单粗暴：扫一遍项目，把类、函数、变量的位置全导出成 Markdown，扔 .codemap/ 目录里。AI 要啥自己翻，文件系统就是最好的接口。
轻量、渐进式披露、Agentic Search。
https://t.co/B3KYfUBEK0

👁 443❤️ 7🔁 0💬 0

2026-01-29

agent-browser 有个点挺不方便的，没法直接复用 Chrome 默认 Profile。
但是我发现一个解法，可以配合 Playwriter 一块用，让 Playwriter 暴露 CDP 服务给 agent-browser：

PLAYWRITER_AUTO_ENABLE=1 npx playwriter serve --replace --host 127.0.0.1
agent-browser connect 19988

👁 333❤️ 5🔁 0💬 0

2026-01-26

这其实说明了一个关键问题：很多 Skills 根本不需要封装成 Skills。

Skills = Prompt（+ 脚本）（+ Assets）
其中 Prompt 才是核心——它是 AI 时代的「脚本语言」。但只有当任务真正需要 LLM 的理解力和决策能力时，Prompt 才有价值。比如分析文本意图、生成创意方案。

而对于确定性任务，一个 Python 脚本往往更稳定、更快、更可控。用 AI 处理本该写代码解决的问题，反而引入了不必要的不确定性和延迟。

Michael Anti @mranti
我有一个小小的意见：我怎么觉得现在skills炫耀的功能，基本上我很快就可以用Claude Code手搓一个Python程序完成了，而且更稳定、更快、随时可调整订制。当然Skills把和AI的互动简化了，不过我觉得它增加的不确定性、控制力弱、延迟等问题，超越了它带来的好处。

👁 362❤️ 4🔁 0💬 0

2026-01-25

Anthropic 这篇博文揭示了一个重要趋势：

与其为每个领域构建专用智能体，不如打造通用智能体，再为其配备专业化的「技能包」（Skills）。

这就好比 Claude Code 作为通用的 Agent OS，而 Skills 则是运行在这套系统上的应用程序。AI 时代的软件工程师需要掌握如何编写 Skills —— 这意味着学会组织 Prompt（LLM 的编程语言）、传统脚本，以及领域 Assets。

https://t.co/6gq0QdGniN

👁 411❤️ 4🔁 0💬 0

2026-01-24

不久前还是人类大危机「疫情时代」
没想到紧接着这么快就到人类大突破「AI 时代」

👁 278❤️ 0🔁 0💬 1

2026-01-18

貌似在 𝕏 上没看到有人提到 MiniMax 前几天开源的 OctoCodingBench（编程智能体指令遵循基准）评测。

简单讲，就是 MiniMax 定义了一套 Coding Agent 指令集，然后评测了下各大模型的全部通过率（ISR），和通过数量占比（CSR）。可以看到即使是最强的 Claude 4.5 Opus 的全部通过率依然只有 36.2%。

这其实验证了 Rule 并不是写得越多越好，Context 保持精简和准确依旧是必杀技。Dynamic Context / Context Engineering 的含金量在持续上升。

👁 847❤️ 6🔁 0💬 0

2026-01-17

来个暴论：未来 99% 的代码都将是开源的。

因为软件的代码会比白菜还便宜。软件的价值将来自于其他地方（数据、资源、服务能力等

👁 566❤️ 0🔁 0💬 0

2026-01-16

很有趣的思路！让我想起 Emscripten 用 IndexedDB 模拟 FileSystem 的设计 😆

不过这里有个权衡：当数据以特定结构存入 DB 后，Agent 按照约定去访问应该没问题，但第三方工具 / 应用又该如何访问？放弃通用的 FileSystem，也就意味着失去了与生态系统中无数外部工具的互操作性。

或许可以换个角度思考：能否构建一个工具，为 FileSystem 提供类似 SQL 的强大检索能力，然后开放给 Agent 使用？这样既保留了兼容性，又增强了查询能力 😁

lcomplete @xlcomplete
有趣，太有趣了。

这个思路太棒了，让 Agent 访问数据库比访问文件系统更高效。

一看到这条推文，我的脑回路立刻就被激活，思路一下子打开了。

1、很早之前就被 Agent 从数据库查数据的能力给震惊过，Agent 只要能连对应的数据库，不需要提供表名等信息就能找到你想要的东西，也能轻松搞定数据统计和分析。
2、我在实现 huntly 的知识库对话功能时想过两个方案：markdown 和 mcp，却从来没想过让 agent 直接去数据库里查。

要让「知识库对话」更顺畅一些，只需要再结合时下流行的 skills，写一个 markdown，大致让 AI 知道 huntly 数据库是干嘛用的，以及一些关键数据要怎么查询就可以了。

换个角度，整个事情变得如此简单。

用我最近常说的句式来收尾，huntly 的含金量又变高了。😋

👁 443❤️ 5🔁 0💬 0

2026-01-12

发现了一些 Claude Code 隐藏的设计哲学！

最近 Claude Code 的更新，给 Skill 新增了 context:fork 的配置。相信各位对计算机科学有了解的话，应该对「Fork」这个词不陌生。如果你顺着这个词去发散的话，是不是会发现：

1️⃣ Skill 的 Context Fork 是不是有点类似「创建新进程」。而 SubAgent 运行时上下文隔离，是不是也和 OS 的进程隔离类似呢。
2️⃣ 那 Skill 岂不就是「应用」！文件夹就是资源包 (Assets)，Prompt 是业务逻辑 (Logic)，里面还封装了应用配置和数据。既可由用户手动运行，亦可被 Agent 自动调度。

这不妥妥的就是一个 Agent OS 么！

👁 2,488❤️ 7🔁 0💬 1

2026-01-13

补充下 Nano Banana 给的配图。

可以看出 CC 在架构设计上也并非凭空捏造，而是贯彻 Unix 哲学精髓，建立在几十年操作系统设计的智慧之上的。这也奠定了它能成为一个通用 Agent Runtime 的基础。

从最早社区有大量用户把它用于代码以外的任务，到官方就后续推出的 Agent SDK 和 Cowork，也都证明了 CC 的通用能力到底有多强。

👁 352❤️ 0🔁 0💬 0

2026-01-11

Bash is all you Need.

LLM 本身就很适合作为一个 Bash 工具，输出输出都是文本流，可以很方便的与其他 Bash 工具 Pipe 串联起来。

Claude Code 的理念就像是给 Agent 提供一个可操作的 Unix 系统环境，让它能拟人化的借助 File System, Bash Scripts/Tools 等这些「外部触手」自主解决复杂的问题。

宝玉 @dotey
“你们应该多用 Bash。”

过去几周，Anthropic 的 Thariq 和几十家做通用智能体的公司开了电话会议。邮件助手、客服机器人、日程管理——各种产品形态都有。聊完一圈，他发现自己反复在说同一句话。

Bash？那不是程序员用的命令行工具吗，和这些产品有什么关系？

先看一个具体场景。

假设你有一个邮件 Agent，你问它：“这周我在打车上花了多少钱？”

传统做法是这样的：Agent 调用 API 拉取邮件，可能一次性取回 100 封，然后让模型从里面找 Uber、Lyft 的收据，加总金额。

问题在于 100 封邮件塞进上下文，模型要同时记住这些内容，从中筛选、计算。这对大语言模型来说并不轻松。容易漏，容易错，而且你没法验证它到底看了哪些邮件。

这就是典型的模型舒适区问题：数据量不算大到需要专门写程序处理，但又超出了模型一次性硬算的能力范围。夹在中间，很尴尬。

Thariq 的方案是：给 Agent 一个 Bash 工具，让它把中间结果存成文件。

听起来很简单，但背后的逻辑很有意思。

传统的工具调用是这样的流程：

工具 → 模型处理 → 输出结果

所有中间状态都在模型的“脑子”里，你看不见，也没法检查。

换成 Bash 之后，流程变了：

工具 → 存文件 → 搜索/过滤 → 模型处理 → 输出结果

模型可以先把 100 封邮件存到一个文件里，然后用 grep 搜“Uber”，再 grep“Lyft”，分别统计。每一步都有迹可查，最后加总的时候，它还能回头检查自己的中间结果。

这带来三个能力升级：

可复现。同样的命令再跑一遍，结果一样。你可以调试，可以排查问题。

可验证。模型不是凭“记忆”给你答案，而是基于实际文件里的数据。你信不过的话，自己也能打开文件看一眼。

可组合。一个命令的输出可以作为下一个命令的输入，管道一接，复杂任务就能拆成简单步骤。

Bash 让 Agent 从“脑算”变成了“打草稿”。草稿可以留痕，可以检查，可以改。这对需要准确性的任务来说太重要了。

邮件搜索只是最直观的例子。Bash 的能力边界其实很宽。

链式 API 调用是个常见需求。比如“把这周我发过邮件的联系人都找出来”，这需要先拉邮件列表，提取收件人，去重，再逐个查询联系人详情。一连串操作用 Tool calls 来做，调用次数多，中间状态难管理。用 Bash 脚本串起来，逻辑清晰得多。

视频和文件处理也是 Bash 的强项。ffmpeg 这个命令行工具，模型用起来得心应手。找视频里某个片段、裁剪、转码，一行命令搞定。

还有定时任务。在 Agent 运行的容器里，用 cronjob 或 at 命令就能创建定时执行的任务。用户说“每天早上 8 点给我发一份新闻摘要”，Agent 可以自己设好闹钟。

这些场景有个共同点：都需要多步骤操作，都需要保存中间状态，都超出了单次工具调用的能力范围。

但 Bash 是把双刃剑。

能执行命令意味着能做很多事，也意味着能做很多危险的事。rm -rf 一不小心就能删光整个目录。如果 Agent 被恶意提示词攻击，后果可能很严重。

Anthropic 显然考虑到了这一点。他们在 Claude Agent SDK 里做了一套权限系统，包括 Bash 命令解析器和分级权限控制。哪些命令可以直接执行，哪些需要用户确认，哪些完全禁止，都可以配置。

我用 Claude Code 的体会是，这套权限系统确实降低了心理负担。它会在执行敏感操作前询问你，而不是闷头就干。但安全护栏不是万能药。权限系统本身也可能有漏洞，Bash 解析器也可能被绕过。

安全护栏是必需品，但不能因此就觉得万事大吉。

强调 Bash 的好处，也得说清楚它的边界。

如果任务足够简单，别用。“今天天气怎么样”这种一次性查询，直接调 API 返回结果就行，没必要存文件再处理。杀鸡用牛刀反而更慢。

如果环境是 Serverless 的，用不了。很多云函数运行时没有可持久化的文件系统，Bash 的“存中间结果”优势就没了。

如果对安全要求极高，谨慎使用。命令注入的风险无法百分之百消除，金融、医疗这类场景可能更适合用白名单式的专用工具，而非通用的 Bash。

工具的选择取决于场景，而不是工具本身的强弱。Bash 很强，但不是所有场合都该用。

回过头看，Thariq 这条建议的真正价值不是“Bash 很强”这个结论，而是背后的思维方式：

让 Agent 的思考过程“落地”到可检查的中间产物。

传统的 Agent 设计把所有东西都塞进模型的上下文，一锤子买卖。Bash 提供了另一种路径：把复杂任务拆开，每一步都留下痕迹，可以验证，可以回溯。

想想看，这和人类处理复杂问题的方式多像。我们做复杂计算时会列竖式，写长文章时会先拟提纲，处理大量信息时会做笔记。不是因为脑子记不住，而是因为落到纸上更可靠、更容易检查。

Agent 也一样。不是说模型处理不了，而是有中间产物的流程更值得信任。我自己用 Agent 辅助写作，所有中间产物都会存成文件：网络检索资料、提纲、不同版本的草稿、画图的提示词。这些存下来后续就可以灵活组合。

Bash 不只是程序员的工具，更是让 Agent 具备可验证、可复现、可审计能力的关键一环。

👁 520❤️ 5🔁 0💬 0

2026-01-10

这不正说明了 Claude Code Agnet 的内部架构足够复杂，再相似的概念可能也会有不少细微的差别。也印证了「Context Engineering」到底能做到有多深 🤣

我个人是认同 Anthropic 创造的这些概念的，这些概念实际在规范、指导普通人如何更好的控制一个复杂的 Agent 系统，其实是在降低大家的门槛。

Yumin @YuminAI
Anthropic这帮人是有病吧
他们发明了plugin, agents, skills
但这不都是一堆markdown文件吗
为什么还区分那么多？

无非都是prompt
ok，有些prompt可以被重复使用
但你也不致于发明这么多概念啊

你就老老实实的说
这个是做ui的prompt
这个是做code review的prompt
这个是做web search的prompt ，但你可以同时开多个进程来跑这个prompt

我他妈还寻思这都是什么高科技呢
天天装神弄鬼，也不学点好

👁 700❤️ 7🔁 0💬 0

2026-01-07

即便在 Vibe Coding 时代，主动管理 Context 依然是高级工程师的分水岭。分享几个 Claude Code 实战心得：

1️⃣ 果断新开 Conversation：无论任何时候，重开是让 AI 「重新聚焦」最快的方式，可以避免幻觉积累。
2️⃣ 手动 /compact：在维持一定上文的同时，减少一些噪音。
3️⃣ 善用 /export：将高质量 Context 持久化，实现跨 Conversation 的记忆共享。

保持 AI 聚焦，是 AI 时代程序员的新基本功。

👁 440❤️ 4🔁 0💬 0

2026-01-06

截至目前为止，已收到过上百封网友来信，提出了各种问题和需求。但作为免费的业余项目有时难免力不从心啊 😅
这个项目我主要还是用来研究 Next.js & Emscripten 的（感兴趣的可以访问下试试，感受下 Next.js 极致优化下的体验），目前的成功只能说是个副产品。

👁 637❤️ 5🔁 0💬 0

2026-01-05

如果你还在自己从零搭建 Agent，不妨换个思路：直接用 Claude Code 来设计和验证你的 Workflow。
Claude Code 本质上是一个通用的 Agent Runtime，远不止是代码工具。它集成了行业标准能力：

Skills - 渐进式披露的领域知识
MCP - 连接任意外部工具和系统
Subagents - 上下文独立的子任务分解能力
Hooks - 在关键节点注入自定义逻辑

用它快速完成 Workflow 设计和测试，验证可行后再用 Claude Agent SDK 封装成产品级方案。这条路径既能借力业界最强的 Agent 能力，又能保持架构的灵活性。

👁 374❤️ 5🔁 0💬 0

2026-01-04

Spec-Driven Development 就跟 Java 设计模式一样，又长又臭，有点用，但用（/写）得太多是反作用。大多数人掌握不好那个度，容易陷进过度设计的陷阱。

就如我之前提到的 JIT Context。现在优秀的 Context Engineering 都是围绕着「如何构造最有价值的上下文」来设计的，要让每一个 Token 发挥最大的价值。但现在大多数人所谓的 Spec-Driven Development 明显是反模式的，把一堆文档丢给 LLM，大量的「规则」反而会影响 LLM 的注意力和遵循能力。

真正要用好 Spec-Driven Development 的话，一定是要模块化、渐进式的。把需求拆分成多个模块、计划，每一步再单独进行 Spec-Driven。

宝玉 @dotey
我个人不喜欢 Spec-Driven Development，有点像瀑布模型写系统设计文档，理论上看起来很牛，但是并不好操作，另外容易想的太多。

我比较推崇小版本迭代，不需要写详细的 spec，几句简单的 prompt 就可以开始生成，每次写一个可以跑起来的版本，然后一点点迭代，每次迭代完都是可以运行的版本

另外大多数时候，Claude Code 的 Plan Mode 就足够好用了，根据你当前想实现的，会写一个 plan 文档，可以反复沟通确认。

👁 10,322❤️ 38🔁 5💬 5

2026-01-03

这几天，在我们这三线城市（深圳旁的一个小城市）又入手了套房。
业主是深圳的，这房子她刚好高峰期「投资」的，当时单价接近两万，现在同户型最新成交一万不到，刚好「腰斩」。
和她电话沟通谈价时，她说这地方现在就是她的伤心地，赶紧脱手卖了以后再也不来这地了。

👁 988❤️ 3🔁 0💬 1

2026-01-02

最可怕的不是 AI 会思考，而是人类放弃思考。把 AI 当外脑没问题，但别让它成为唯一的大脑。

👁 325❤️ 1🔁 0💬 1

2026-01-02

坚持和 AI 进行「反复、深度讨论」，而不是简单的拾人牙慧。

👁 221❤️ 1🔁 0💬 0

2026-01-01

当初 FTX 的统一保证金体系也是独一档的。虽然倒闭让我的资金打了水漂，但比起金钱损失，更让我难受的是一个这么出色的产品就此成为历史。

Benson Sun @BensonTWN
FTX 倒了三年了。

撇開 SBF 做的那些事不談，純粹從產品角度來看，FTX 很多功能放到現在依然能打，甚至領先現在多數交易所。

子帳號系統到現在沒有任何一家做到類似體驗。FTX 的子帳號是原生帳號架構，不是那種層層疊疊、權限綁手綁腳的設計。開一個子帳號就像開一個全新帳戶，乾淨俐落。

美股代幣FTX 上輪週期就在做了。這輪才開始有交易所把這當賣點來宣傳，晚了一整個週期。

Quant Zone 更是一絕。不用寫程式就能建立自動化策略，我以前做套利都直接開 Quant Zone 跑，省下大量開發時間。

其他產品還包括指數合約、槓桿代幣，以及當時全網唯一的每小時結算、無cap 的資金費率，和 RFQ 的 OTC desk。

FTX 的產品設計確實超前了這個行業一整個週期。三年過去了，如果 SBF 沒作惡，如果 FTX 還在，我相信還會引領更多 CEX 的創新，真的可惜了。

👁 361❤️ 0🔁 0💬 0

推文 · 2025 下半年

Wed, 31 Dec 2025 00:00:00 +0000

看到不少人质疑 Meta 收购 Manus 的价值，也想来说几句。

Manus 的产品体验究竟如何、做应用层创新（所谓的套壳）是否不如做底层模型 —— 这些争论可能没那么重要。作为一支能连续引爆舆论 & 吸引到所有人眼球、能连续快速做出现象级产品的团队，这个可能才是 Meta 真正想要的（肖弘将出任 Meta 副总裁这点可以辅证）。

就像 Altman 之于 OpenAI，懂得如何讲好故事、聚拢人心、抓住时机，这可能是技术之外更重要的事情。

👁 391❤️ 2🔁 0💬 0

这个说法挺有趣。LLM 是 Runtime，Claude Code 是编译器，Prompt 是源码，所有原生提供的组织 Prompt 的方式（例如 Skills）都是语法糖。

DN-Samuel 🧑‍💻 @SamuelQZQ
Claude skills 能做到的事，在没有 skills 的时候，LLM也都能做到。

Skills 只不过是一种语法糖 (syntactic sugar)

程序员应该都能懂我的意思😂

👁 350❤️ 1🔁 0💬 0

Vibe Building，满大街都是拿着锤子在找钉子的人 😳

👁 310❤️ 3🔁 0💬 0

合理但也不合理。高层更需要的是判断力，但是完全不写代码容易逐渐丧失判断力。

Y11 @seclink
请教大家，这合理吗？

前几年公司里的一位架构师大神告诉我说，p5的时候80%的时间还能写代码。P6的时候40%的时间在写代码。

P7~p9之后90%的时间就会是开会，更重要的是识别出主要问题，并说服别人哪些事情更重要更紧急，哪些不重要。

确定先怎么做，后怎么做。

职业生涯越往后走，“沟通”的活就越重。真的对编码感兴趣的，白天开各种会晚上回家才写代码。-_-

👁 276❤️ 0🔁 0💬 0

前段时间如果有半价入手 Google AI Pro 的朋友们可以看看这个项目，它能提供一个代理服务去调用 Antigravity 提供的模型，这样就能愉快的在 Claude Code 里使用这些模型了😆

Tom Dörr @tom_doerr
Proxy for Claude models via Google AI Pro subscription

https://t.co/ZwEWNrn8dA

👁 552❤️ 1🔁 0💬 0

2025-12-28

Anthropic CEO 透露他们 70% 以上的代码都是由 AI 写的。很多人不仅不相信，甚至还对此冷嘲热讽 🤣。但假设这是真的，这其实是一个非常令人震惊的信息，甚至可以理解为一个极其重要的「金丝雀信号」！它表明：

「AI 编程已经接近、甚至已经跨过临界点」。如果 Anthropic 能做到，那其他科技公司肯定也能逐步做到。未来软件开发的成本结构，可能将发生根本性的改变。

这也是我为什么说程序员们一定要尽快把 Claude Code 这类 Agent 深度使用起来，要强迫自己逐渐把 AI 作为主力生产者，而不单纯是辅助工具。

因为当临界点真正到来时，差距不会线性拉开 —— 它会指数级扩大：
- 深度掌握 AI 协作的工程师，生产力可能是传统方式的数倍甚至数十倍
- 这些人将能承担更复杂的项目、更快的迭代速度、更低的成本
- 而那些仍将 AI 视为「可有可无」的人，将在竞争中迅速被边缘化

👁 45,216❤️ 162🔁 14💬 12

2025-12-29

为什么说这是「金丝雀信号」？
Anthropic 是最了解 AI 能力边界的公司之一。他们的一举一动、每一个对外释放的信号，都在预示整个行业即将发生的变化。

什么是「临界点」？
当你和 AI 的角色发生互换 —— 不再是「AI 辅助你写代码」，而是「你辅助 AI 完成代码生产」时。

👁 2,740❤️ 3🔁 2💬 0

最近听到一个很有趣的词「JIT (Just-In-Time) Context」。

熟悉编译原理的朋友对「JIT」一定不陌生。而在 LLM 领域，JIT Context 代表着一种范式转变：
- 传统方式：固定的 System Prompt + 线性追加的历史对话
- JIT 方式：每轮对话都动态编排输入内容（System Prompt 也不例外）

为什么需要 JIT Context?
因为随着 Context 不断膨胀，真正重要的信息的一定会被不断稀释注意力，每轮对话需真正需要的上下文其实也在不断变化。

而 JIT Context 强调了，不是所有历史都需要保留，而是应该在正确的时间提供正确的信息。它让 Prompt 像代码编译一样「即时生成」，根据当前任务动态筛选、重组上下文，让每一个 Token 都发挥最大价值。

👁 15,046❤️ 111🔁 14💬 10

天才团队出品，连文档都让人赏心悦目🤣 Claude 的博客甚至技术文档，绝对是所有 AI 学习者和研究者的必读材料，值得反复阅读。

👁 767❤️ 4🔁 0💬 1

现在打算做 Agent 的话，首推 Claude Agent SDK https://t.co/1jwOUWIMbt

Claude 在 LLM 工程设计上绝对是断层级的存在。如果你深度使用过 Claude Code，应该会发现它不仅能写代码，几乎能完成所有知识类工作。而 Agent SDK 本质上就是把 Claude Code 的核心能力 API 化 —— 你可以在沙盒环境中编程调用，让它完成任何你需要的任务。

👁 742❤️ 10🔁 0💬 1

明年的目标是让 AI 帮我写至少 70% 的代码！🤔

在未来一段时间里，如果人类还能在软件工程中占有一席之地，那么人和 AI 之间协作的分工将会非常清晰：人类负责架构设计、需求规划和代码审查，AI 负责具体实现和执行。这已经不是猜测，而是正在发生的确定性趋势。

只有那些率先掌握「AI 协同开发」能力的工程师，才能在这波 AI 浪潮之后活下来。

👁 315❤️ 2🔁 0💬 1

改变一直在发生！这是一次行业，乃至全人类脑力劳动者的「生产力」、「工作范式」的大洗牌，赶紧用 AI Build 起来🧑‍💻

👁 194❤️ 0🔁 0💬 0

2025-12-25

昨天刚把 Q4 的 OKR Review 填完，篇幅里 30% 业务开发，70% Infra 工作 😅 有时候真不知道在一个业务团队里搞这么多 Infra 会不会让人有点奇怪

👁 205❤️ 0🔁 0💬 0

2025-12-24

更有深度的 Insight 离不开好的 Taste。

👁 196❤️ 2🔁 0💬 0

2025-12-14

一个不错的学习英语的方法：微信 - 通用 - 翻译 - 自动翻译聊天中收到的消息

👁 1,056❤️ 2🔁 0💬 1

2025-12-13

达成新成就: deprecate 前的 merge

好消息: 去年给 graphql-code-generator 提的 MR，隔了一年多总算给 merge 进去了😳
坏消息: maintainer 准备把包给 deprecate 了😅

👁 239❤️ 0🔁 0💬 0

把公司的 Next.js 项目用 Bun 跑了下某个相对复杂的页面渲染场景，整体大概比 Node 快 10% 左右

👁 322❤️ 0🔁 0💬 1

2025-12-04

不打算迁移到 Bun，因为我们目前是 Standalone 部署的，长期运行的环境下 v8 的运行时优化可能追上 Bun 的各种优化。10% 的提升支撑不了换 Runtime 的大胆决定。

感觉 Bun 特别适合边缘计算（冷启动时间敏感、短期运行）的场景。

👁 200❤️ 0🔁 0💬 0

放弃使用 Next.js 自带的 Route Cache 了，局限性太大，只能根据 Path 来做 Cache，就算借助 Rewrite 来映射到 Path 上做 Cache 也会有新的各种问题。

现在改成全部动态渲染，然后在 Nginx 层做 Cache，总算舒服了😌

👁 238❤️ 3🔁 0💬 1

2025-10-22

今日份热心用户邮件。但我想说我不是 80 后啊😂

👁 3,570❤️ 17🔁 0💬 8

2025-10-20

今天不断有人来问我是不是发了这个 Cat Island 币 https://t.co/ZzxEqgvXqT

在此声明下，我和这个币没任何关系哈😅(一头雾水

👁 949❤️ 3🔁 0💬 4

2025-09-21

「最终，一切取决于品味」

只要涉及到创造的领域其实就离不开艺术和品味，「苹果团队里有音乐家、诗人、艺术家、动物学家、历史学家，同时他们也是顶尖的计算机学家」。在代码工程领域里，不同地区 / 文化、不同性格 / 背景的工程师也许「品味」差距很大。

每一个细微的决策、设计上的差距，在累积到一个新的量级 / 诞生出一个「产品」时，也会产生出翻天覆地的变化。

👁 1,569❤️ 3🔁 0💬 0

看到公司 flutter codebase 里用全局变量来储存和改变不同主题颜色值的方案就头疼😅

一个合格的工程师「不管在任何情况下」一定是要避免使用全局变量（/状态）的，其次再去思考应该把它们放在哪个尽可能小的 scope 里，再深入点的话可能要思考的是如何减少更多的状态了👀

👁 1,014❤️ 2🔁 0💬 0

已经好几次被公司内部服务的缺陷给坑了，总会遇到一些奇奇怪怪的问题，吭哧一顿排查、拉会，才发现是受其他内部服务 / 基建给影响到😅

👁 653❤️ 4🔁 0💬 0

最近在公司里开始搞 flutter 和 hybrid 相关的事。

五年前我是 all in flutter 的态度，但现在看法不太一样。flutter 真的很先进，而且 dart 是专门为 ui 领域设计的语言，整套技术在平衡性上是顶尖的。在某种意义上我甚至觉得它们有点要搞 better browser 的意思。

但是 flutter 永远达不到 browser 的地位，连 android 自身都没深度集成 runtime 进去，更别说其他操作系统了。只要没法像 web 那套一样成为事实标准，那么 flutter 和系统原生层的 gap 就会一直很难处理。这个担子太重了（自己处理渲染，担子远比 bridge 到原生重），我很怀疑 google 还会不会一直投入进去。

所以我基于市场判断的预测是 flutter 未来可能会没落。但是我感觉无论如何，至少它的很多设计、实现，甚至精神理念应该会对其他的 ui 构建系统带去不少影响（据说 flutter 的工程总监已加入 apple 了）。

如果你问我现在的选择，我会更支持原生 /+bridge (例如 rn)，或者 web 这两个方案。除了 web 这个事实标准敢自己处理渲染层外，其他自己处理渲染的 ui 框架我都不太看好。

👁 1,214❤️ 2🔁 0💬 3

当然不看好归不看好，在公司里还是得听上层们的决策 hhh
不过最近公司新来了个 leader，道听途说，后续跨平台这块应该会换成 rn 了🤔

👁 515❤️ 0🔁 0💬 0

2025-09-08

没研究过金融工具的人，是不是都搞不懂这里面的逻辑？👀

最近和老婆商量着再买一套房，然后讨论到现在住的这套要不要卖掉。老婆的意思是如果卖掉的钱可以覆盖还欠银行的钱的话就卖掉，不然的话，卖相对不卖就「亏大了」，因为卖掉的话不仅房子没了，还得额外再给一笔钱给银行🤣

👁 1,065❤️ 3🔁 0💬 3

2025-09-09

卖和不卖只决定了你要不要把「未实现盈亏」转化成「已实现盈亏」，实际你的盈亏在这个时间点已经是确定了的。重要的不是操作本身，而是要不要在这个时间点做操作。

👁 454❤️ 0🔁 0💬 0

2025-09-06

今天学会了一个骚操作：
花不到 40 元在万能的某宝找人帮忙，成功把：
- 联通副号：从之前能找到的最低 29 元套餐，改成了 8 元保号套餐
- 移动主号：从 129 元 30G → 99 元 40G+30G
原理其实就是商家帮你投诉运营商，通常收到投诉后运营商才会愿意给你改套餐。
实属是用魔法来打败魔法了🤣

👁 205,073❤️ 879🔁 137💬 95

2025-08-30

一个观察，能真正洞察出事物各种 tradeoff 的人很强 🤔

👁 963❤️ 4🔁 0💬 0

Apollo GraphQL Client 出 4.0 了，周末又得搏斗一番了😅

GraphQL 配合 Apollo 这套，无论是后端还是前端，开发体验都让人极度愉悦。强类型 & 前端自动生成、自动文档、Playground、前端强大的状态管理（自动管理所有后端状态，让你只需关心少量 UI 状态）、以及最后灵活的 Query 语法等等。

让我来选择 Tech Stack 的话，这套绝对是必选项。

https://t.co/zgSB9EAWO9

👁 727❤️ 3🔁 0💬 0

就在刚刚，emu666 已经拥有超过 20 万的注册用户了😆

👁 4,619❤️ 13🔁 0💬 6

2025-08-27

前前同事，从码农转行去做直播带货（幕后）后，一个月能分 10~15 个😳

👁 2,033❤️ 8🔁 0💬 1

2025-08-27

再次意识到码农只是新时代的农民工🤣比尔盖茨、扎克伯格的故事还是少听点吧 hhh

👁 801❤️ 3🔁 0💬 1

2025-08-26

为啥大公司里几乎找不到 10x 工程师？🙄

👁 1,900❤️ 7🔁 0💬 4

2025-07-28

📌 置顶一条消息，长期有效。

目前我这有某 crypto 所的代理（高达 50%～90% 的手续费返佣），有兴趣的欢迎 dm 我。目前我自己的资金 & 策略已经在上面在跑了（中高频交易最大的敌人可能是手续费）😆过段时间我分享下情况

👁 2,435❤️ 6🔁 0💬 6

2025-08-14

开始小资金跑起来了，昨天一天的手续费返佣。跑高频、高杠杆交易还是很不错的啊😙

👁 527❤️ 2🔁 0💬 0

2025-07-27

vibe coding / claude code 真有这么神么？有没有极其深度用过、或者在大型 / 复杂项目上用过的小伙伴现身说法一下😅

目前我还是用的 copilot 的形式。我目前还不太相信在有限的上下文内（即使上下文工程做得足够好）让 ai 完全主导开发，能保证在复杂项目上不错过任何一点内部细节🤔代码这东西对准确性的要求很高，稍微哪里出了点问题都会影响整个系统。

当然有很多方法来把控，code review、vibe debugging(👀)。但是这种 chat & review 的 workflow，比起自己写代码 & ai 作为 copilot 小范围补全 / 建议，总感觉很难让人对代码产生信任。所以我想问下实际体验

👁 2,027❤️ 6🔁 0💬 5

2025-07-17

我给我们部门搭建的这套 Web Codebase，我真的太特么喜欢了😆甚至让我有种喜欢上上班的错觉哈哈。

很多最新 / 最佳实践，核心代码有单元测试，Storybook，很多自动化工具，太多太多让我开发起来觉得快乐的地方了😆

👁 1,656❤️ 8🔁 0💬 2

2025-07-18

- 框架: Next.js 15 (App Router), React 19
- 样式 & 组件: Tailwind CSS, Radix UI, Shadcn UI, Storybook
- 数据请求: tanstack/react-query - 状态分享: nekocode/use-shared-state
- 国际化: next-intl + Smartling

1. 我们和设计师约定了色板统一在 Figma 上维护，设计稿用到的所有颜色必须在色板里，然后我这边写了一个脚本来读取 Figma Styles，并且生成对应的 CSS 和 Tailwind 配置

2. 我们的所有「基础组件」都基于 Headless 的理念来写，大部分来自 Radix，还有部分是我们自己维护。核心理念是只关注 DOM 逻辑、无任何样式、一个组件只对应一个 DOM 元素（由上层自由组装）。并且每个组件都有 Storybook 演示

3. 我们所有资源文件的引入都走 import（我们 public 文件夹下没任何文件），这样打包时能给所有资源文件名加上 hash。然后我们在 CI 打包时，会把所有静态资源（包括 JS）都 upload 到云储存桶上（里面也会有之前打包上传的资源），最终通过 CDN 下发给用户。这样能保证用户请求命中老的 HTML 时也能正常访问

待续

👁 814❤️ 7🔁 0💬 0

2025-07-15

「服务端 SSR 渲染！要回归用 PHP 重写了？」https://t.co/eNqtYLIgat

经常能看到类似的言论，更有趣的是评论区里还不少人在附和😅

现在的 SSR 和以前的有着质的区别，现在的 SSR 能以 CSR 的代码去渲染 HTML，并且能在 Hydration 后无缝切换回 CSR，这是 PHP 做不到的。

当前想仅靠老一套的模板 SSR 已经很难做出复杂、体验好的 Web 页面了。

👁 646❤️ 3🔁 0💬 0

2025-07-09

不知道怎么回事，网站今天的新增用户又爆增了，到目前为止已经新增一万多个用户了，害我又紧急充了两次钱😅

每隔一段时间就爆发一次，看来口碑还是 ok 的，能持续自然传播🤣

👁 9,574❤️ 35🔁 0💬 7

2025-07-10

增长总共爆发过三次。昨天是新高😅真成烫手山芋了

👁 1,677❤️ 2🔁 0💬 3

2025-07-05

一眨眼已经入职新公司三个月了，下周一准备转正述职。

这是我第一回在大公司里当 Web 研发，上一回在大公司的职位还是 Android 研发🤣

下回想挑战下后端，不知道还有没有机会😆

👁 3,788❤️ 15🔁 0💬 3

2025-07-07

述职完了，松了口气。

饭碗应该是稳住了哈哈😆

👁 1,436❤️ 1🔁 0💬 2

推文 · 2025 上半年

Mon, 05 May 2025 00:00:00 +0000

2025-05-05

尴尬，一个五一假期直接把我阿里云服务给干欠费停机了😅一个业余兴趣项目，怎么感觉要做起来了😂

👁 92,154❤️ 200🔁 5💬 18

明天入职！

今天，clone https://t.co/2p85koLsHD，开始学习！😂🤣

👁 4,431❤️ 7🔁 0💬 2

学了半天，怎么感觉 vue 除了「性能」上可以拿得出手外，其余是真不习惯？

性能这块也是因为选择了限制更多的模板语法（相较于更加灵活的 jsx），天然更容易被优化，所以才占点优势。反正我是真不想去记各种模板语法，反而 react 的 all-in js 才是真的大道至简。

至于其余的例如 react 对 ts、vscode 有「更深入的支持」，以及其更庞大的生态那些就不说了。很好奇为什么那么多中小团队，甚至部分大团队会更愿意选择 vue？👀

👁 4,029❤️ 2🔁 1💬 4

2025-04-08

https://t.co/0Nb4et8Ay5 突破 5w 用户了！🎉🥳

让 gpt 大概估算了下，目前流量下接广告的价值👇

👁 8,067❤️ 48🔁 3💬 11

2025-04-02

收回我之前对 python 稍微顺眼的言论😅

一旦遇到 io 密集且想要并发的情况就恼火。我也知道有 asyncio，但是不是所有第三方库/生态都支持（对比 node.js 差太远太远了），只能退而求其次用 gevent 这种丑陋的方式😅

👁 3,368❤️ 5🔁 0💬 0

2025-04-01

真的好喜欢 react + next.js，但是去到新公司要写 vue + nuxt 了👀

👁 7,685❤️ 17🔁 0💬 3

2025-03-28

这周面了家 crypto 交易所的前端开发。

大概有 6、7 年没被技术面试过了，结果给安排了 4 轮面试，把我这 i 人差点整 emo 了😂

👁 4,367❤️ 14🔁 0💬 3

2025-03-31

今天 hr 来沟通了，offer 基本确定下来，给的薪水也在我想要的水平之上，如无意外应该下周就办入职。

从最早的 android 工程师，再到最近几年的全栈，而这回是正儿八经的要到一家中型公司当 web 工程师了。对我而言，感觉算是技术转型的一次正式成功🤣

👁 2,838❤️ 13🔁 0💬 3

2025-03-29

之前给 biome 提交的 PR，因为被其他的 pr block 了所以一直没有被处理。

今天突然发现 PR 被 close 了，而且相关问题已经 assign 给其他人了😂话说他们就没有考虑过 assign 给我么。被「holding」之后就没人跟我沟通过进度之类的

https://t.co/Mc2FuLVZV7

👁 2,343❤️ 1🔁 0💬 0

2025-03-17

最近几天也不知道怎么回事，https://t.co/0Nb4et8Ay5 每天有上千的新注册用户 😂

👁 8,603❤️ 33🔁 2💬 10

2025-03-18

昨天一天最终有 4k 多新用户，这相当于之前一个多月的新用户量了😳

👁 1,894❤️ 1🔁 0💬 1

2025-03-02

总算提到新玩具了🤣

👁 2,718❤️ 15🔁 0💬 2

2025-02-28

现在每天都有 100 个左右的新增用户，但是我暂时还抽不出精力来维护 😅

如果你喜欢的一个产品一直没更新，那么很有可能这个产品只是作者的一个 side project 🤪

👁 3,048❤️ 13🔁 0💬 2

2025-02-26

又好久没来 X 蒲头了😆

这两天实盘下来，新策略很 🐮。说实话，python 写久了对它的语法居然也就稍微看顺眼了 🤣。

当然，如果抛开生态给我选，依然会选 nodejs。python 这 async 搞得和 nodejs 差太远，也就适合捣鼓下同步的代码。

👁 2,347❤️ 6🔁 0💬 3

2025-02-14

https://t.co/eaLaprcFD9 的数据也是逐渐好起来了，这几天应该马上要突破 2w 用户了😆

但是我已经好久没维护它了。一直想把 aliyun 的服务适配到 aws & cloudflare 再做一个国际版也没空去做😂

其实这个网站有机会发展得更好的。在 emulatorjs 开源之前，全网我们几乎是最早能把 retroarch 模拟器完美跑在 web 上的，那时候几乎找不到能在 web 上玩到各种模拟器游戏的网站。

但是由于精力问题，错过了那段市场空白的时间，等到 emulatorjs 正式开源之后，现在已经一大堆网站支持在 web 上玩模拟器游戏了🤣

👁 2,179❤️ 11🔁 1💬 0

2025-02-13

RT @TobyAtLarge: 招两个程序员，项目制
合作好的话可以转正

- 接受remote，prefer上海
- 公司做ai产品落地，需要前端和全栈
- 项目制按小时 x 国内大厂程序员时薪

靠谱程度：
- 我自己tech lead/pm，不会出现pm给你乱提需求的问…

👁 0❤️ 0🔁 27💬 0

2025-02-13

GM🌞
休假结束，今天开始上班🧑‍💻

👁 1,407❤️ 5🔁 0💬 0

2025-02-12

这个市场里太多赌徒了。

但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸

👁 1,759❤️ 8🔁 0💬 5

2025-02-11

最近在研究链上有没有什么可以跑量化的机会。昨天拿了 1k u 在 gmgn 上跟单，想着学习下现在链上聪明钱的玩法，结果半天不到就给我全亏完了😅

这 tm 现在链上全是赌徒啊，到处是狗庄和镰刀，大家都在赌自己在镰刀挥下来之前，能跟着狗庄喝上点汤🤣

👁 3,329❤️ 11🔁 0💬 6

2025-02-07

本来想维护下 https://t.co/MYHte01pbp 这个项目，把依赖都升级下的。

结果发现 pixi.js 的 7 -> 8 这个升级有太多 breaking changes 了，之前处理 6 -> 7 升级时也是一堆 breaking changes。

说实话，按照这个库当前的接口设计，我感觉后续还会有不少 breaking changes，好多设计依然很别扭。

设计基础库时，api 的设计太考验开发者的编程内功了。一套好的 api 应该做到每次在内部实现有大的改动时，接口只有增量更新，或者只有少量的破坏改动。

👁 1,619❤️ 7🔁 0💬 1

2025-02-07

来看看这次更新破坏性有多强：https://t.co/nVdUK0xhe5

按图上的数据除去 package-lock.json 的改动的话，总共还有五六百行代码的改动😅要不是有点洁癖，还真懒得管它了

年后要找工作了，这几天打算重新整一下个人主页🤔打算用 next.js 再做个外框，然后把这个 pixi game 嵌入到里面😏

👁 1,084❤️ 1🔁 0💬 0

😳退休老人新赛道：公众号自媒体

我爸去年 10 月份退休，本来是打算出去再就业赚点零花钱的，但是因为一直配合公司在忙补交社保的事情，所以也没急着出去。

👁 495,741❤️ 982🔁 86💬 81

后来也不知道跟谁学的，跑去开了个公众号写文章去了。就这么捣鼓了几个月，一开始家里人其实都没当一回事，觉得按他说的能赚钱应该是难，就当消磨时光也好。

谁成想春节这段时间阅读量居然暴增了，最高一天还有上千。要知道在这种小城市，他退休前工资一个月也才五千😅

👁 37,874❤️ 98🔁 3💬 7

2025-02-06

笑死，我就随手分享点好玩的日常，一堆人跑来质疑，甚至恶言诋毁。

无非就是看到别人赚钱就酸，说实话这些人在我看来真是傻逼 & loser。我其实在评论区公布过号名，也有不少人跑去看过证实过了，只是我后来考虑到怕有什么不必要的、未知的麻烦所以删掉了，毕竟不是我自己的号。

这样，如果还有觉得我铁定是骗人的，私下联系我，我私底下给你证实哈。要是证实是真的话你在推啥自骂 10 句自己是傻逼和 loser 就好🙂

👁 9,948❤️ 18🔁 0💬 19

2025-02-03

噩耗，老板这波归零了😂

👁 7,629❤️ 22🔁 0💬 10

2025-02-03

22 年开始一直被套，熬了几年，去年总算回了大部份血，没想到今年春节归零了。

作为搞 quant 的，我们内部一直在强调大资金交易中风险管理的重要性，没想到他自己先倒在不理智的操作上😅有时候真别拿自己的命运来考验自己的运气，没有人能永远好运气

👁 2,819❤️ 10🔁 0💬 1

总算吃了没做 backup 的亏了🫠

心大，直接跑一段徒手撸的 script（没意识到危险 hhh），直接把 oss 上一半的 rom file 给删掉了😅万幸的是，用脚本校验了下，用户相关的数据一点都没损失。

👁 2,895❤️ 10🔁 0💬 2

fixing 😭

👁 1,775❤️ 2🔁 0💬 1

已修复所有数据😮‍💨

👁 1,593❤️ 2🔁 0💬 0

2025-01-11

分享下近况：
1️⃣ 大部份时间在做一些量化相关的 infra 的工作 🔧，感谢开源世界和 ai，缝合了不少项目进来 🐙
2️⃣ 新年多了 20w $ 进来，但是受市场大环境影响，策略目前在回撤期，考验耐心的时候到了 🤔
3️⃣ 剩余的大部份时间都在带娃 🍼 说实话，比上班累多了😂
4️⃣ 下定了新 model y，期待 🤩

👁 2,578❤️ 11🔁 0💬 2

2025-01-10

这个数据 📊 如果纯靠广告的话能带来多少收益 🤔

有懂行的推友么？

👁 1,812❤️ 3🔁 0💬 0

推文 · 2024 下半年

Sun, 29 Dec 2024 00:00:00 +0000

2024-12-29

https://t.co/0Nb4et8Ay5 这网站我也挺久没维护了，也没做宣传，现在每天稳定有差不多 30 左右的新增用户。这就是被动增长了么😆

👁 16,735❤️ 73🔁 9💬 6

2024-12-25

我认为一个人只要
1️⃣ 足够聪明
2️⃣ 对 💰 足够渴望
那么他终归会赚到他想赚到的 💰 的。反思下自己哪一点还不够吧 🤔

👁 2,399❤️ 23🔁 0💬 5

2024-12-24

交易起来 💸💸💸

👁 1,490❤️ 4🔁 0💬 1

2024-12-23

结识大佬最快的方式：付费 👀

大多数人对「投资」这个词没什么概念，实际上💰能成为很多事情的杠杆，包括人脉。

👁 2,782❤️ 22🔁 1💬 2

2024-12-21

这两天抽空折腾了下，放弃了 🤪
1️⃣ 本来想修改官方的 time series plugin 支持下使用 js 来预处理数据，但是发现这个 plugin 是 built in 的，大量依赖内部的代码，没法方便的抽离出来
2️⃣ 后来想着看看 grafana 能否支持自定义 transformation，但是找了下发现官方还没这个计划 https://t.co/N1sJfSnu25
3️⃣ 最后想着试试能不能在 prometheus 的 data source plugin 上做点文章，发现这家伙也是 built in 的 😅

最后只能用 business charts 这个第三方插件来处理了，可视化用的是 echarts，样式、交互和功能和官方的 time series（内部用的 uplot）有不少差异。

啥时候能支持自定义 transformation 那就美滋滋了。

nekocode @nekocode_cn
也不知道我是什么体质，日常工作中不管用什么库/工具，总会遇到各种 bug 或者没法满足我需求的 case。

因为又不想不管，导致我得去研究它的代码然后在本地 patch，最后或许还能去给上游贡献点代码 😅

最近一个新的 case 就是 grafana + prometheus 没法满足我一些复杂的数据后处理逻辑，目前打算去改造官方的 time series plugin 了，支持下使用 js 进行后处理再可视化。

👁 1,800❤️ 3🔁 0💬 0

100% 同意。但是现实是大多数的利益分配者不会愿意多付这 100% 的支出。

贪婪和压榨是资本的天性。

Yishi @ohyishi
聪明的人沟通起来就是爽，你刚说完30%的需求，他就能 get 到120%，多出来的那20%是超额执行，考虑了各种边缘情况和向后兼容，考虑得比你还周全。

不聪明的人，你完整交代100%的需求，他只能做到30%，多不了一点，只管上线，脏活全丢给 qa。然后你被逼着不停拉会，非常疲惫。

不要为了省那20%预算招不聪明的人，应该花200%的钱招聪明的人。

👁 1,470❤️ 5🔁 0💬 0

看看过去 24 小时里暴跌行情 📉 我们资金曲线的表现 👀

👁 1,513❤️ 9🔁 0💬 1

2024-12-19

让我想起我的一个前同事，在他的个人项目里用到我们内部的某个 token，然后还 push 到 github public repo 幸好最后被我发现的事 😅

我甚至最开始还不知道他的 github id，是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。

Ruifeng @liruifengv
vant、@rspack/core、@rspack/cli 被盗号者注入恶意脚本，请升级到 vant 4.9.15、@rspack/core 1.1.8 、@rspack/cli 1.1.8

https://t.co/EU715y7zVz

https://t.co/KntX26q96S

👁 1,572❤️ 5🔁 0💬 0

2024-12-19

也不知道我是什么体质，日常工作中不管用什么库/工具，总会遇到各种 bug 或者没法满足我需求的 case。

因为又不想不管，导致我得去研究它的代码然后在本地 patch，最后或许还能去给上游贡献点代码 😅

最近一个新的 case 就是 grafana + prometheus 没法满足我一些复杂的数据后处理逻辑，目前打算去改造官方的 time series plugin 了，支持下使用 js 进行后处理再可视化。

👁 2,987❤️ 6🔁 0💬 0

2024-12-13

😎 用 grafana 搭建的量化表现面板。
🆒🆒🆒💵💵💵

👁 1,228❤️ 9🔁 0💬 0

2024-12-12

最近 crypto 行情好起来了，老板说他的资产又回到前高了，顺便把创业亏掉的窟窿也都补回来了😆

后续老板和我们几个合伙人讨论了下，决定后面不搞产品了，把其余人员都解散了，剩下我们几个就专心研究下交易/quant 就好。

对他来说，比起做产品，还是做交易的反馈来得直接😂

👁 2,733❤️ 14🔁 0💬 4

2024-11-26

这年头，还有月薪超过 30k 的后端工程师拒绝使用 docker 来部署，想问下这合理么😅

👁 2,954❤️ 10🔁 0💬 17

2024-11-22

最近在看老板花了几个 w 报的 quant 课程给的代码，一个感想：「搞科研的和搞代码的真的是两拨人」。代码乱、抽象差、工程性差、运行效率差 🫠

要不信的话，你去看看 quant 或最近热门的 ai 领域的开源项目，其实挺多都是代码质量一般的。而且有很多 poc 还都只是停留在 jupyter notebook 阶段。

当然，这种现象非常合理，毕竟术业有专攻。能跨领域本身就已经是稀缺人才了。

👁 1,092❤️ 6🔁 0💬 0

2024-11-22

强烈推荐下 react-scan 这个新工具。react 生态下终于有一款简单方便的杀手级 profiling 工具了！

Aiden Bai @aidenybai
github, please fix your React re-renders.

literally every time i scroll it renders 100× https://t.co/7dKd5lWrZt

👁 1,222❤️ 9🔁 1💬 0

2024-11-21

创业过多次，和三个 ceo 同住过。之前的两个 ceo 在我们解散后都已经起飞了。一个做了家全国某类别 top 1 的新媒体公司，另一个做了家国内私域领域 top 级别的操盘公司 🥲

那还有一个 ceo 呢？其实就是我们现在团队的 ceo，目前还在挣扎中。能看到团队起飞的那天么🥺

👁 7,189❤️ 16🔁 0💬 1

2024-11-20

希望大家不会用上的技巧之：
💡如何代理某个 docker 容器内所有的网络流量。

背景：
我想让某个跑在国内服务器上的 nestjs 应用支持下 google 登录。应用是跑在容器内的，所以你懂的，得代理下容器内所有与 https://t.co/Ua4slLfG9e 之间的请求。

方法👇：

👁 1,473❤️ 11🔁 0💬 2

2024-11-20

1️⃣ 在服务器上配置并启动你的代理客户端/容器
2️⃣ 启动一个 redsocks 容器来代理容器内的网络流量到你的代理客户端/容器（推荐个 redsocks 镜像: https://t.co/tKwcU5LhS6
3️⃣ 把你要代理的应用的容器的 network_mode 设置为 redsocks 容器 id，共享网络栈

它比起设置 HTTP_PROXY 环境变量的好处是能更彻底的代理所有流量。

举个简单的例子:

👁 2,589❤️ 7🔁 2💬 0

2024-11-19

我们团队最早是做 crypto 套利的，后来市场环境没那么好之后老板才决定去做产品。

一开始是做 crypto 的交易工具，一直不愠不火。后来 gpt 火了之后又跑去做 ai 套壳工具，本来其实已经做出起色来了（搞了几十万用户），后来遇到个「黑天鹅」事件直接又给搞熄火了。

最近老板花了几万块买了个量化的课程，打算又回到老本行做 crypto 量化交易了 😶

👁 3,661❤️ 17🔁 3💬 7

2024-11-18

RT @Ehco1996: 最终还是准备重回职场打工了，求推友们帮忙介绍和转发🙏

github： https://t.co/AZDNmKOb6I

另外附了一些基本介绍，有兴趣的瞅瞅，欢迎私信/邮箱联系我

👁 0❤️ 0🔁 61💬 0

2024-11-18

时代的微尘落到每个人头上都是一座大山。

最近看到太多太多例子了，聪明如中产，仍旧挡不住被大环境的收割一夜返贫，太难了。

👁 961❤️ 4🔁 0💬 0

我们用的是自部署的 gitlab，然后我们的 runner 是和 gitlab 一起跑在一台配置一般的 aws ec2 上。

之前测试过，我们的项目在这台 ec2 上构建的话太慢了，大概需要 30 分钟左右。因为不想浪费钱开台独立的更高配置的服务器（只用来跑 runner 的话利用率太低了，最差的情况可能一天一个 job 都没），所以这些项目我们一直是人工在本机构建和部署。🤔

最近翻 gitlab 的文档发现 gitlab ci 支持「按需」分配 ec2 来跑 ci job：
🔗 https://t.co/UHiXTxiOSX
这表示我们可以按需使用更高配置的服务器来跑持续集成！长时间没有新 job 的话 gitlab 会自动帮我们回收服务器 🤗

最终我们项目在 ci 上跑一次 build 的时间缩小到 4 分钟左右，解放了我人工运维的工作 🎉

其他一些细节：
1️⃣ 使用 docker in docker 来构建
2️⃣ 除了一些 linux 基础命令，其余命令全部使用 docker 来跑（例如 node, aws-cli, aliyun-cli 等
3️⃣ 构建产物是 docker 镜像，在 ci 中 push 到 gitlab registry 然后部署到服务器

👁 855❤️ 5🔁 1💬 0

能把 build in public 搞清楚的独立开发者应该都知道，打造个人 ip 比产品本身更重要

👁 948❤️ 5🔁 0💬 0

说件两件可怕的事情：

1️⃣ 在目前这么可怕的就业环境下，明年还将有 1222 万大学生毕业，同比增长 43 万人
2️⃣ 最近的出生人口增长拐点在 2016 年，这意味着大概到 2040 年之前，每年的大学毕业生数量还会不断上升

毕业即失业，找不到工作又去卷考研、考公，往后 10 年可能会越来越难🫠

👁 3,411❤️ 11🔁 4💬 1

现在想想，90 后 + 选计算机专业，真的是少有的开挂通道了👀

👁 643❤️ 3🔁 0💬 0

💸💸又捡了几个便宜的域名备着：
https://t.co/etTMvhFsIe
https://t.co/DqdgiBnL4n
https://t.co/XjSZqMgtuX
之前还有个：
https://t.co/l65GQkqMo0
推友们觉得能值点钱么？🙄

👁 596❤️ 5🔁 0💬 0

最近给 biome 和 graphql-code-generator 提交的 pr 进度都不太顺利，一个因为涉及另外一个大改动暂时卡住了，一个一直没人有空 review 🫠

👁 630❤️ 5🔁 0💬 0

杠杆只是种金融工具，没必要妖魔化，而且现代金融世界想要高速发展也离不开杠杆的

polebug @polebug
最近看到很多大 v 说千万不要开杠杆/合约，我不太认同。

杠杆/合约并不等于高风险，这个命题的关键在于“欲望”，欲望越大，杠杆倍率越高，这样才导致了高风险。

作为一个一开始控制不住欲望爆仓了，但是后面吸取教训，做好仓位管理，现在能轻松翻倍的合约玩家来说，杠杆是一种能快速提升资产的方式。

👁 676❤️ 3🔁 0💬 0

2024-11-11

在国内四个不同团队用过 nest.js，其中有三个团队是我主导用的。我们主要技术栈是 nest.js + typeorm + graphql，选择 nest.js 主要是因为它是 node.js 下目前最靠谱的选择。

至于为什么选择 node.js，主要原因有几个：

1️⃣ 在非计算密集的场景下，会比其他很多主流后端语言更容易写出高性能的代码。举个例子，async 相较于 multi-thread，以前在写 java 时，除非用 rx 之流，不然一些复杂的异步问题都不好解决，用上多线程的话，很多时候不合理的锁、线程间交互会严重影响整体耗时，而 js/ts 的 async/await 对这类问题基本是降维打击。而后端恰恰大部分是 io 密集的场景，使用多线程模型并没有优势。
2️⃣ 语言优势。js 有着庞大的生态、社区、开发群体。而 ts 有着现代语言里最强大的类型系统，用于开发大型系统是完全没问题的，而各种现代化的语法糖能提高开发效率、代码可读性。
3️⃣使用 graphql 的「无奈之举」。在目前所有的 graphql 的服务端实现里，node.js 下的是最完善、成熟的。

个人感觉 node.js 其实是创业团队前期很不错的选择，性能上依托于 v8 基本是脚本语言里最快的了，另外在 serverless 领域里，js 也是首要支持的语言。

👁 31,401❤️ 106🔁 10💬 13

2024-11-11

偶尔会收到邮件有用户主动愿意付费的，太难得了😆

比真的赚到钱还要高兴。

👁 793❤️ 6🔁 0💬 0

2024-11-10

习惯不错。一个哲理「外部状态是魔鬼」，函数式编程的一个核心就是状态和方法完全分离（抛弃 class），这样有助于保证方法更简单、可预测、可测试👀

wwwgoubuli @wwwgoubuli
我不喜欢也几乎从来不使用class 来组织功能相关联的代码，我几乎只用函数。

而我需要把管理的代码组织在一起的时候，我就丢到一个文件里各自export，或者同一个文件夹下。

class 对我而言是一种抽象的“打包”，我喜欢让功能和文件/文件夹产生物理关联。

只是一个小小的个人习惯，看看有没有类似的。

👁 790❤️ 4🔁 1💬 0

2024-11-09

📈最近 eth 回本了，要不要换台 mbp max 呢？m1 max 已经用了好几年了🙃

👁 640❤️ 4🔁 0💬 3

2024-11-09

真心建议所有开发者把 ai copilot 用起来！🚀🚀🚀

很多人可能严重低估了 ai 对编程效率的帮助，以我自己使用 github copilot 的体验为例，感觉是符合二八定律的。ai 能帮我解决掉本要花费 80% 时间的 20% 的难题里的 80%。约等于能帮我节省一半的时间！

兄弟们，面向 comment 编程是真的爽！

👁 822❤️ 6🔁 0💬 1

2024-11-08

一个震惊的现实：

我发现很多工程师（甚至有月薪达到 30k 的），对代码的运行效率没概念。
举个例子，一段看似有很多计算的代码，没深入思考就认为瓶颈在 cpu 就要求升级设备，而现实是计算步骤中会不断把结果写入到数据库，瓶颈完全在 io 上，其实优化下代码就能极大的提升效率。
不得不问，有多少人对「计算密集」和「io 密集」这两个有很明确的概念的？又有多少人对性能 profile 和优化有经验的？🤔

👁 1,192❤️ 9🔁 0💬 3

repost 下，证明下这还真不是偶然。小红书非常适合获取公域流量，而且用户质量普遍偏高 🤔

nekocode @nekocode_cn
小📕的流量这么大么，新号发了条 po 能给这么多流量🤔

👁 997❤️ 3🔁 0💬 1

补充：我小红书总共才发了 10 条内容，目前爆了 2 条

👁 488❤️ 1🔁 0💬 1

我试过很多方法，只有 project scope 的隔离是最彻底的而且最通用的，这样能强迫你把通用的代码摘得很干净

👁 2,309❤️ 5🔁 0💬 0

为什么我非常建议所有开发者在每一个项目都把 mono-repo/workspace 用起来？

一个很重要的原因是因为它能实现对代码的 project scope 的「完全隔离」。这样你可以把常用的代码抽象 & 隔离到一个单独的 project，实现代码在不同项目的快速复用。

👁 47,496❤️ 234🔁 21💬 19

你遇到过这样的事么？吐槽下以前我在某厂的一次经历：

原定颁发给我的某个奖项，因为我已经提了离职，某空降的上上级直接把这个奖项换给了另一个同事😅（还是我的直属上级和我私下说的）

👁 804❤️ 4🔁 0💬 2

2024-10-31

一些补充：

1️⃣ 有 X 友好奇我怎么知道的老板的薪资，其实是老板自己告诉我们的
2️⃣ 老板是炒币发家的，自从创业后，据说目前已经烧掉了 8 位数的钱了
3️⃣ 当前情况确实挺艰难，没有收入 + 暂时没拉到新的融资，目前在努力做一些挽救 & 尝试

nekocode @nekocode_cn
最近比较震惊的一件八卦：

老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...

👁 1,862❤️ 10🔁 0💬 3

2024-10-28

最近比较震惊的一件八卦：

老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...

👁 185,510❤️ 617🔁 49💬 46

2024-10-26

今天详细看了下 apollo 对 react suspense 支持，发现支持得真棒👍准备在小破站把 suspense 用起来了，把 loading 和 error 的渲染剥离出去，「别 catch 了，直接往上 throw 吧」👀
https://t.co/bv3wUPRTAF

👁 1,236❤️ 3🔁 0💬 0

2024-10-23

今天打开 AWS Route 53 时发现的。如果你用过 JSX，应该对这个不陌生😆 #Memes

👁 883❤️ 2🔁 0💬 1

2024-09-19

吐槽下阿里云的 aliyun-cli，和 aws-cli 对比质量差太远了：
❌ aliyun oss cp -f -r ./build/ oss://xxx/
✅ aliyun oss cp ./build/ oss://xxx/ -f -r

参数都没给处理好。报错信息毫无作用，不得已翻了他们源码才知道问题😅

👁 825❤️ 4🔁 0💬 1

建议有使用 svgr 的 > react 18 的项目都可以使用上

👁 513❤️ 1🔁 0💬 0

提交的一个 mr merged 了:
https://t.co/goPaiD3Cl0

顺便推荐下这个 svgr plugin，可以把导入的 svg 组件的 id 使用 React.useId 给替换掉，这样的好处是：
1️⃣ 保证 ssr 和 csr 后的 id 一致，避免水合问题
2️⃣ 在页面中同时渲染两个组件的情况下不会出现 id 冲突（https://t.co/LrgA3edM7J

👁 741❤️ 2🔁 0💬 1

https://t.co/n6eZPauIVS

👆使用飞书的「多维表格」来维护 https://t.co/0Nb4et8Ay5 的游戏列表，并且双向同步到数据库、OSS。

👁 722❤️ 3🔁 0💬 0

一个有趣的建议：

一个功能完备、提供开放接口的在线表格，能省掉绝大多数小型产品的后台管理开发成本。

举个例子：

👁 1,919❤️ 7🔁 1💬 4

2024-09-08

小破站在0️⃣营销成本的情况下，终于突破 10K 用户了！🎉

这个小破站是我近年来转型 Web 前端后探索 Next.js 最佳实践的试验田，没想到能靠自然增长获得我定的第一个小目标：10K 用户😄

https://t.co/PPaECsaUJw

👁 6,643❤️ 24🔁 2💬 5

2024-07-02

小📕的流量这么大么，新号发了条 po 能给这么多流量🤔

👁 3,188❤️ 7🔁 0💬 6

2024-07-01

#memes 部署一个 Node.js 项目 be like:

👁 741❤️ 6🔁 0💬 1

推文 · 2024 上半年

Sun, 30 Jun 2024 00:00:00 +0000

我们产品，池里平均一个号 👀

👁 695❤️ 3🔁 0💬 0

对绝大多数传统公司而言，office 三件套就是它们性价比最高的「数字化」方案。

卫斯理 @imwsl90
感觉很多人要到多年后才会发现，什么文档工具都不如微软的 office 三件套....

👁 716❤️ 4🔁 0💬 0

让我想起以前 upwork 的一个英国客户，每次发 email 是真的很有礼貌。

foxlaoy @fox_laoy
老外真的很有边界感。昨天跟英国的技术团队开会，我说只有邮件沟通比较麻烦，能不能给手机号或者imessage、skype之类的。被果断拒绝……邮件文字沟通，如果要语音沟通就是zoom预定开会……不会有私人沟通。这样也蛮好的。大家就事论事。

👁 982❤️ 4🔁 0💬 0

状态是万恶之源！🤡

👁 479❤️ 1🔁 0💬 0

垃圾信息里，文字"糖"还好，现在视频"糖"更要命，要花掉普通人 50% 的信息接收时长

ruanyf @ruanyf
新的博客文章《信息就像糖一样上瘾》：工业革命有一个很少人提到的后果，就是人类可以大量生产糖了。

从此，大部分食物都添加糖，垃圾食品泛滥，因为糖会增加多巴胺的分泌，让你对糖上瘾，过量进食。

信息就像糖一样，也能增加多巴胺，让人上瘾。https://t.co/ccIYy1rW1Q

👁 687❤️ 2🔁 0💬 0

dify 细节做得好一些，coze 功能更多一些。dify 对我来说有个缺陷就是不支持 llm 原生的 function call，所以我用 coze 更多一些

ghostviper @A9yNtIHEjvVkW7C
dify真的可以用了，迭代模式好像比coze好用？coze的编排界面实在是太卡了，今天刚把远古时期Fastgpt做的编排迁移到dify，20分钟完成一个还新增了日期、天气、知识方面的功能，效率爆炸。

👁 697❤️ 3🔁 1💬 1

跟一个大学同学聊了下，目前在广州电网上班（IT 相关），年包 45 个，上班时间 855，饭碗包稳能干到退休，时薪算了下将近 250RMB。在目前互联网日落西山的行情下，怎么评价？

👁 515❤️ 4🔁 0💬 2

即使是还「活着」的社区，很多都已经在逐渐「劣化」。互联网用户下沉 + 算法分发内容，在整体网民素质还没提上去的情况下，劣币驱逐良币是必然

nekocode @nekocode_cn
其实 CSDN 能活到今天，都是同行的「大多数」用脚投票导致的。劣币驱逐良币，前面有多少好的社区都倒闭了，哀哉 🤡

👁 530❤️ 1🔁 0💬 0

其实 CSDN 能活到今天，都是同行的「大多数」用脚投票导致的。劣币驱逐良币，前面有多少好的社区都倒闭了，哀哉 🤡

👁 988❤️ 3🔁 1💬 0

2024-06-26

看了下，把我的所有仓库也爬过去了，真 TM 流氓啊🤮

yihong0618 @yihong0618
CSDN 是不是有病，把我的项目都自动用 AI 生成内容农场了，关键是用的还是比较劣质的 AI 生成的没有一个对的。

👁 5,804❤️ 6🔁 0💬 3

2024-06-26

背景：
1️⃣ 自从 FTX 暴雷我所有的 Crypto 资产归零后，总计损失了几十万了，目前已经彻底退圈。
2️⃣ 我的老板是靠 Crypto 起家的，目前在做 AI 创业，但是现在形势也很不好，基本没有正反馈一直在烧钱。
最近他靠 ETH 大回血了一波，目前在怂恿我重返 Crypto，要听么？😂

👁 458❤️ 2🔁 0💬 0

晚安，玛卡巴卡 https://t.co/f1qZ04ZYd0

👁 288❤️ 1🔁 0💬 0

之所以有这个想法主要是因为：
1️⃣ Agent 是 AI 能处理「相对复杂任务」的最小单元
2️⃣ 暂时没见过 AaaS 这个概念
3️⃣ 用 AI 解决问题时，很多逻辑其实可以抽象成 Agent 拿出来通用的，例如联网搜索、RAG、翻译等

nekocode @nekocode_cn
提问: AI 创业的话，Agent as a Service 可行不？🤔

👁 478❤️ 0🔁 0💬 0

提问: AI 创业的话，Agent as a Service 可行不？🤔

👁 837❤️ 2🔁 0💬 1

他想要还不容易。而且现在最大的瓶颈可能不是在 GPU 而是在训练数据上了👀

A2GUI @A2GUI
@buaaxhm 不可能。GPU都没人给他

👁 376❤️ 0🔁 0💬 0

从业多年，我很少见到只掌握产品本门技能的产品经理能让我觉得称职的。
在某大厂时，纯产品经理已经很罕见了，基本都是设计+产品、数据+产品、技术+产品的技能组合。当然，也有例外。如果公司业务复杂或者领域相对垂直、小众，能理清业务的纯产品经理也是很有价值的。

shinnyChen @shinny__Chen
别说，还真是

👁 476❤️ 2🔁 0💬 1

🤩 推荐一个我很喜欢的在抖音上做 8bit 音乐的创作者: https://t.co/rvsLChlHda

👁 277❤️ 3🔁 0💬 0

2024-06-24

真的很讨厌别人在文档里造各种新词，能一眼看懂的还好，凭空捏造、词不达意的那种看到就想说一句 Fuck。难道作为工程师不懂「组合优于继承」的理念么？能用几个简单词汇描述清楚的事，一定要搞个新概念出来😡

👁 234❤️ 2🔁 0💬 0

2024-06-19

以前都是热衷做开源项目，最近第一次尝试独立做一个产品。⬇️下面是在没有做任何推广（0 成本）的情况下最近一周的数据，这大概能算什么水平？🤔

最近准备写篇文章详细说说这神奇的经历，有兴趣的先可以关注: https://t.co/6l2s6GzIHP

#buildinpublic #indiehackers

👁 352❤️ 3🔁 0💬 0

2024-05-25

编程内功：
最近把 VS Code 的 JetBrains IDE Keymap 插件卸载了，用回自带的快捷键了，目前已基本习惯 🤣

👁 185❤️ 0🔁 0💬 0

2024-05-24

近期做的一些开源社区贡献。推荐一个能筛选给第三方的 PR 的方式，方便给别人列出你的所有开源贡献: https://t.co/bPhBCezG9H

👁 189❤️ 1🔁 0💬 0

2024-05-14

#GPT4o 比较好奇视频能力是直接整个视频文件作为 token 输入到 llm，还是说会预处理采样关键帧图片后再输入

👁 348❤️ 0🔁 0💬 0

2024-03-12

今天广东的天气终于放晴了🌞 #居家办公

👁 195❤️ 2🔁 0💬 0

2024-03-02

用的技术栈太新，很容易遇到各种奇葩问题。

今天就遇到个 apollo graphql 的 useQuery 在 next 下 observe 失败，没法被 refetch queries 触发刷新的问题😅猜测可能是 SSR hydration 导致的异常，保证在 hydration 完成之后 observe 就解决了。

感觉前端社区太多新东西了，但是生态的发展跟不上。

👁 158❤️ 0🔁 0💬 0

2024-03-02

挺意外的，昨天发了条公众号文章，立马有前同事来找我问我要不要帮忙内推到 TikTok 商业组😂（感谢还记得我

以前，每隔一段时间都有猎头或同行问我要不要跳槽，自从知乎离职很少在社交媒体上活跃后就开始慢慢没有人来问了。看来还是得多多表达，至少让别人知道还有你这么一个人 hhhh

👁 159❤️ 0🔁 0💬 0

推文 · 2022 下半年

Sun, 03 Jul 2022 00:00:00 +0000

2022-07-03

最近有在用我三年前写的 gradle plugin 的网友在遇到问题后写 email 向我求助。抱着尝试 fix 的心态大概看了下，没想到也就几年时间，gradle 和 android gradle plugin 的接口变化挺大的，要 fix 问题的话还需要不少精力，然后就只能灰溜溜的回复他我暂时没精力解决了😅

👁 0❤️ 0🔁 0💬 0

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

2025-04-01

真的好喜欢 react + next.js，但是去到新公司要写 vue + nuxt 了👀

👁 7,685❤️ 17🔁 0💬 3

2025-02-03

噩耗，老板这波归零了😂

👁 7,629❤️ 22🔁 0💬 10

👁 2,819❤️ 10🔁 0💬 1

👁 7,189❤️ 16🔁 0💬 1

👁 6,643❤️ 24🔁 2💬 5

看了下，把我的所有仓库也爬过去了，真 TM 流氓啊🤮

yihong0618 @yihong0618
CSDN 是不是有病，把我的项目都自动用 AI 生成内容农场了，关键是用的还是比较劣质的 AI 生成的没有一个对的。

👁 5,804❤️ 6🔁 0💬 3

2026-06-06

microstrong @Microstrongs
@nekocode_cn @yihui_indie Agent 开发模式下，多人- Agent 协作确实是一个新的挑战。

多人在方案制定阶段是有明显好处的，但如果到开发阶段，直接 subagents 就好了。

👁 5,127❤️ 22🔁 0💬 22

2026-06-27

https://t.co/1VgsTlISuS

👁 5,112❤️ 8🔁 0💬 4

就在刚刚，emu666 已经拥有超过 20 万的注册用户了😆

👁 4,619❤️ 13🔁 0💬 6

明天入职！

今天，clone https://t.co/2p85koLsHD，开始学习！😂🤣

👁 4,431❤️ 7🔁 0💬 2

👁 4,029❤️ 2🔁 1💬 4

2025-03-28

这周面了家 crypto 交易所的前端开发。

大概有 6、7 年没被技术面试过了，结果给安排了 4 轮面试，把我这 i 人差点整 emo 了😂

👁 4,367❤️ 14🔁 0💬 3

2025-03-31

👁 2,838❤️ 13🔁 0💬 3

2025-07-05

👁 3,788❤️ 15🔁 0💬 3

2025-07-07

述职完了，松了口气。

饭碗应该是稳住了哈哈😆

👁 1,436❤️ 1🔁 0💬 2

2024-11-19

👁 3,661❤️ 17🔁 3💬 7

2025-10-22

今日份热心用户邮件。但我想说我不是 80 后啊😂

👁 3,570❤️ 17🔁 0💬 8

👁 3,411❤️ 11🔁 4💬 1

现在想想，90 后 + 选计算机专业，真的是少有的开挂通道了👀

👁 643❤️ 3🔁 0💬 0

2025-04-02

👁 3,368❤️ 5🔁 0💬 0

2025-02-11

👁 3,329❤️ 11🔁 0💬 6

2024-07-02

小📕的流量这么大么，新号发了条 po 能给这么多流量🤔

👁 3,188❤️ 7🔁 0💬 6

2025-02-28

👁 3,048❤️ 13🔁 0💬 2

https://t.co/qv9xO7S07N

👁 3,035❤️ 20🔁 4💬 0

2024-12-19

👁 2,987❤️ 6🔁 0💬 0

2024-11-26

这年头，还有月薪超过 30k 的后端工程师拒绝使用 docker 来部署，想问下这合理么😅

👁 2,954❤️ 10🔁 0💬 17

👁 2,895❤️ 10🔁 0💬 2

fixing 😭

👁 1,775❤️ 2🔁 0💬 1

已修复所有数据😮‍💨

👁 1,593❤️ 2🔁 0💬 0

2024-12-23

结识大佬最快的方式：付费 👀

大多数人对「投资」这个词没什么概念，实际上💰能成为很多事情的杠杆，包括人脉。

👁 2,782❤️ 22🔁 1💬 2

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

2024-12-12

👁 2,733❤️ 14🔁 0💬 4

2025-03-02

总算提到新玩具了🤣

👁 2,718❤️ 15🔁 0💬 2

👁 1,473❤️ 11🔁 0💬 2

👁 2,589❤️ 7🔁 2💬 0

👁 2,578❤️ 11🔁 0💬 2

👁 2,488❤️ 7🔁 0💬 1

👁 352❤️ 0🔁 0💬 0

👁 2,435❤️ 6🔁 0💬 6

开始小资金跑起来了，昨天一天的手续费返佣。跑高频、高杠杆交易还是很不错的啊😙

👁 527❤️ 2🔁 0💬 0

2024-12-25

我认为一个人只要
1️⃣ 足够聪明
2️⃣ 对 💰 足够渴望
那么他终归会赚到他想赚到的 💰 的。反思下自己哪一点还不够吧 🤔

👁 2,399❤️ 23🔁 0💬 5

2025-02-26

👁 2,347❤️ 6🔁 0💬 3

2025-03-29

👁 2,343❤️ 1🔁 0💬 0

我试过很多方法，只有 project scope 的隔离是最彻底的而且最通用的，这样能强迫你把通用的代码摘得很干净

👁 2,309❤️ 5🔁 0💬 0

👁 2,179❤️ 11🔁 1💬 0

👁 2,040❤️ 8🔁 0💬 46

👁 2,040❤️ 20🔁 0💬 2

前前同事，从码农转行去做直播带货（幕后）后，一个月能分 10~15 个😳

👁 2,033❤️ 8🔁 0💬 1

2025-08-27

再次意识到码农只是新时代的农民工🤣比尔盖茨、扎克伯格的故事还是少听点吧 hhh

👁 801❤️ 3🔁 0💬 1

2025-07-27

👁 2,027❤️ 6🔁 0💬 5

👁 2,020❤️ 12🔁 2💬 6

Coding Agent CLI ─► ACP ─► Agent Team CLI

用 Claude 通过 Agent Team CLI 来指挥另外两个 Coding Agent CLI 打工

👁 313❤️ 1🔁 0💬 0

一个有趣的建议：

一个功能完备、提供开放接口的在线表格，能省掉绝大多数小型产品的后台管理开发成本。

举个例子：

👁 1,919❤️ 7🔁 1💬 4

2025-08-26

为啥大公司里几乎找不到 10x 工程师？🙄

👁 1,900❤️ 7🔁 0💬 4

2024-10-31

nekocode @nekocode_cn
最近比较震惊的一件八卦：

老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...

👁 1,862❤️ 10🔁 0💬 3

2025-01-10

这个数据 📊 如果纯靠广告的话能带来多少收益 🤔

有懂行的推友么？

👁 1,812❤️ 3🔁 0💬 0

2024-12-21

nekocode @nekocode_cn
也不知道我是什么体质，日常工作中不管用什么库/工具，总会遇到各种 bug 或者没法满足我需求的 case。

因为又不想不管，导致我得去研究它的代码然后在本地 patch，最后或许还能去给上游贡献点代码 😅

最近一个新的 case 就是 grafana + prometheus 没法满足我一些复杂的数据后处理逻辑，目前打算去改造官方的 time series plugin 了，支持下使用 js 进行后处理再可视化。

👁 1,800❤️ 3🔁 0💬 0

2025-02-12

这个市场里太多赌徒了。

但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸

👁 1,759❤️ 8🔁 0💬 5

😆 笑死，确实是相互糊弄

比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子

plantegg @plantegg
有了 AI 之后，飞书文档承受了从来没有过的压力：
1）新文档生成速度直线上升
2）读写比例达到新低，也就是架构估计得重构了

以前大家都知道一般读写比例是 95:5，现在估计接近 50:50 了

这些文档大家也没真的去看，在各个会议上，在 CEO CTO CXO 以及各级工程师之间一视同仁地互相糊弄

👁 1,744❤️ 2🔁 0💬 0

2026-04-02

👁 1,729❤️ 7🔁 0💬 0

2026-06-30

👁 1,706❤️ 4🔁 0💬 3

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

👁 1,656❤️ 8🔁 0💬 2

👁 814❤️ 7🔁 0💬 0

👁 1,619❤️ 7🔁 0💬 1

👁 1,084❤️ 1🔁 0💬 0

Ruifeng @liruifengv
vant、@rspack/core、@rspack/cli 被盗号者注入恶意脚本，请升级到 vant 4.9.15、@rspack/core 1.1.8 、@rspack/cli 1.1.8

https://t.co/EU715y7zVz

https://t.co/KntX26q96S

👁 1,572❤️ 5🔁 0💬 0

2025-09-21

👁 1,569❤️ 3🔁 0💬 0

2026-03-24

👁 1,560❤️ 16🔁 0💬 1

2026-03-25

灵感 & 基因来源：Logseq + VS Code

不到 5MB 的大小，Apple Native，无 DB 无索引（抛弃 Logseq 路线），多 Tab，斜杠命令面板

对我来说简直太完美了！

👁 610❤️ 0🔁 0💬 0

看看过去 24 小时里暴跌行情 📉 我们资金曲线的表现 👀

👁 1,513❤️ 9🔁 0💬 1

2024-12-24

交易起来 💸💸💸

👁 1,490❤️ 4🔁 0💬 1

2026-05-24

Yufan Sheng @syhily
不知道是不是我的使用姿势不正确，推油大吹特吹的 CodeGraph 在我这使用效果相当一般。还不如 Agent 自己去 Grep。

👁 1,473❤️ 8🔁 1💬 2

100% 同意。但是现实是大多数的利益分配者不会愿意多付这 100% 的支出。

贪婪和压榨是资本的天性。

Yishi @ohyishi
聪明的人沟通起来就是爽，你刚说完30%的需求，他就能 get 到120%，多出来的那20%是超额执行，考虑了各种边缘情况和向后兼容，考虑得比你还周全。

不聪明的人，你完整交代100%的需求，他只能做到30%，多不了一点，只管上线，脏活全丢给 qa。然后你被逼着不停拉会，非常疲惫。

不要为了省那20%预算招不聪明的人，应该花200%的钱招聪明的人。

👁 1,470❤️ 5🔁 0💬 0

2025-02-13

GM🌞
休假结束，今天开始上班🧑‍💻

👁 1,407❤️ 5🔁 0💬 0

2026-04-13

👁 1,355❤️ 5🔁 0💬 0

2024-10-26

👁 1,236❤️ 3🔁 0💬 0

2024-12-13

😎 用 grafana 搭建的量化表现面板。
🆒🆒🆒💵💵💵

👁 1,228❤️ 9🔁 0💬 0

2024-11-22

强烈推荐下 react-scan 这个新工具。react 生态下终于有一款简单方便的杀手级 profiling 工具了！

Aiden Bai @aidenybai
github, please fix your React re-renders.

literally every time i scroll it renders 100× https://t.co/7dKd5lWrZt

👁 1,222❤️ 9🔁 1💬 0

2026-02-02

Lyric🌀 @lyricwai
效果如图，它自己去 https://t.co/DkYrGAJL2n 生成了 PDF，没问我要 APIKey，也没有把 APIKey 暴露到 prompt

👁 1,220❤️ 1🔁 0💬 1

👁 1,214❤️ 2🔁 0💬 3

当然不看好归不看好，在公司里还是得听上层们的决策 hhh
不过最近公司新来了个 leader，道听途说，后续跨平台这块应该会换成 rn 了🤔

👁 515❤️ 0🔁 0💬 0

2026-04-21

nekocode @nekocode_cn
一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

👁 1,205❤️ 5🔁 0💬 0

2024-11-08

👁 1,192❤️ 9🔁 0💬 3

👁 1,158❤️ 2🔁 0💬 1

nekocode @nekocode_cn
Git Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。

这绝对是 Coding Agent 的并发放大器！

现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。

👁 1,095❤️ 7🔁 2💬 1

过去：雇佣多个开发者，各自在独立设备上并行迭代
AI 时代：启动多个 Coding Agent，在单台设备上通过多个 Worktree 并行迭代

👁 213❤️ 0🔁 0💬 0

👁 1,092❤️ 6🔁 0💬 0

👁 1,065❤️ 3🔁 0💬 3

👁 454❤️ 0🔁 0💬 0

一个不错的学习英语的方法：微信 - 通用 - 翻译 - 自动翻译聊天中收到的消息

👁 1,056❤️ 2🔁 0💬 1

2026-07-18

nekocode @nekocode_cn
没想到我爸退休都 2 年多了，居然找到了份离家近的 3.6K 的保安队长的工作 😂

他年轻时用 visual fox（应该没多少人听过这玩意😆）给当地很多小区搞过财务软件，认识了不少小区的主管。结果前几天人家突然给他捞了个保安队长的工作，要知道我爸连保安证都没呢 😂

👁 1,048❤️ 5🔁 0💬 17

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

👁 1,014❤️ 2🔁 0💬 0

repost 下，证明下这还真不是偶然。小红书非常适合获取公域流量，而且用户质量普遍偏高 🤔

nekocode @nekocode_cn
小📕的流量这么大么，新号发了条 po 能给这么多流量🤔

👁 997❤️ 3🔁 0💬 1

补充：我小红书总共才发了 10 条内容，目前爆了 2 条

👁 488❤️ 1🔁 0💬 1

2026-01-03

👁 988❤️ 3🔁 0💬 1

其实 CSDN 能活到今天，都是同行的「大多数」用脚投票导致的。劣币驱逐良币，前面有多少好的社区都倒闭了，哀哉 🤡

👁 988❤️ 3🔁 1💬 0

让我想起以前 upwork 的一个英国客户，每次发 email 是真的很有礼貌。

foxlaoy @fox_laoy
老外真的很有边界感。昨天跟英国的技术团队开会，我说只有邮件沟通比较麻烦，能不能给手机号或者imessage、skype之类的。被果断拒绝……邮件文字沟通，如果要语音沟通就是zoom预定开会……不会有私人沟通。这样也蛮好的。大家就事论事。

👁 982❤️ 4🔁 0💬 0

2025-08-30

一个观察，能真正洞察出事物各种 tradeoff 的人很强 🤔

👁 963❤️ 4🔁 0💬 0

2024-11-18

时代的微尘落到每个人头上都是一座大山。

最近看到太多太多例子了，聪明如中产，仍旧挡不住被大环境的收割一夜返贫，太难了。

👁 961❤️ 4🔁 0💬 0

2025-10-20

今天不断有人来问我是不是发了这个 Cat Island 币 https://t.co/ZzxEqgvXqT

在此声明下，我和这个币没任何关系哈😅(一头雾水

👁 949❤️ 3🔁 0💬 4

能把 build in public 搞清楚的独立开发者应该都知道，打造个人 ip 比产品本身更重要

👁 948❤️ 5🔁 0💬 0

Claude Code 最近是改了什么？几乎每次询问用户问题时都没自动调用 AskUserQuestion 工具，需要手动 Prompt 来触发。

👁 935❤️ 0🔁 0💬 1

2026-03-09

导致我最近经常 Prompt「用 ask 工具问我」

👁 186❤️ 0🔁 0💬 0

2026-02-14

nekocode @nekocode_cn
上下文工程，我常用的一个小技巧:

让 AI 把现状先写到一个 MD 文件里

git commit

Review & 修改 MD 文件

/clear

让 AI 基于 git diff（你对现状的修改意见）去解决问题

👁 913❤️ 6🔁 0💬 1

2026-02-19

说到底，AI 还是需要注意力引导才能交出更好的成果 —— 你在哪个环节给足 Context，它就在哪个环节完成得更出色。

👁 153❤️ 1🔁 0💬 0

2024-10-23

今天打开 AWS Route 53 时发现的。如果你用过 JSX，应该对这个不陌生😆 #Memes

👁 883❤️ 2🔁 0💬 1

👁 855❤️ 5🔁 1💬 0

2026-01-18

👁 847❤️ 6🔁 0💬 0

提问: AI 创业的话，Agent as a Service 可行不？🤔

👁 837❤️ 2🔁 0💬 1

👁 825❤️ 4🔁 0💬 1

👁 822❤️ 6🔁 0💬 1

👁 804❤️ 4🔁 0💬 2

偶尔会收到邮件有用户主动愿意付费的，太难得了😆

比真的赚到钱还要高兴。

👁 793❤️ 6🔁 0💬 0

2024-11-10

wwwgoubuli @wwwgoubuli
我不喜欢也几乎从来不使用class 来组织功能相关联的代码，我几乎只用函数。

而我需要把管理的代码组织在一起的时候，我就丢到一个文件里各自export，或者同一个文件夹下。

class 对我而言是一种抽象的“打包”，我喜欢让功能和文件/文件夹产生物理关联。

只是一个小小的个人习惯，看看有没有类似的。

👁 790❤️ 4🔁 1💬 0

天才团队出品，连文档都让人赏心悦目🤣 Claude 的博客甚至技术文档，绝对是所有 AI 学习者和研究者的必读材料，值得反复阅读。

👁 767❤️ 4🔁 0💬 1

👁 742❤️ 10🔁 0💬 1

👁 741❤️ 2🔁 0💬 1

2024-07-01

#memes 部署一个 Node.js 项目 be like:

👁 741❤️ 6🔁 0💬 1

👁 727❤️ 3🔁 0💬 0

https://t.co/n6eZPauIVS

👆使用飞书的「多维表格」来维护 https://t.co/0Nb4et8Ay5 的游戏列表，并且双向同步到数据库、OSS。

👁 722❤️ 3🔁 0💬 0

对绝大多数传统公司而言，office 三件套就是它们性价比最高的「数字化」方案。

卫斯理 @imwsl90
感觉很多人要到多年后才会发现，什么文档工具都不如微软的 office 三件套....

👁 716❤️ 4🔁 0💬 0

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

nekocode @nekocode_cn
你如果在用 SDD，那我不建议你把 Spec 持久化。因为 Spec 会漂移！

代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床

真正的「唯一真相来源」应该只有一个：代码本身

又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md

👁 714❤️ 2🔁 0💬 0

2026-03-29

👁 706❤️ 3🔁 0💬 1

nekocode @nekocode_cn
谁说 Agent Client Protocol 只能给 GUI 用 🤣

Team/Swarm 模式很可能是 Coding Agent 在 2026 年真正爆发的关键方向。可以预见，每个主流 Coding Agent 都会推出自己的 Team Mode —— 但一个更有意思的问题是：怎么让不同厂商、不同架构的 Coding Agent 组成一个异构 Team？

目前市面上已经有一些尝试，但各有局限：

1. Headless 模式：通过 Coding Agent CLI 的 Headless 模式来编排多个 Agent。问题在于，各家的 Headless 模式普遍是阉割版——功能覆盖不全，交互能力也大打折扣，远不如完整的 CLI 交互体验。

2. PTY 劫持：直接通过伪终端（PTY）接管 Coding Agent CLI 的输入输出。这种方式虽然理论上能获取完整能力，但信噪比极低——你需要从大量终端控制字符、ANSI 转义序列和格式化输出中解析出真正有用的信息，既脆弱又难以维护。

而 ACP（Agent Client Protocol）提供了一个更优雅的解法。它在 CLI 交互之上抽象出一层统一的、结构化的协议层，让上层编排系统无需关心底层 Agent 的具体实现细节，就能以一致的方式与不同的 Coding Agent 进行通信和协作。

基于这个思路，我做了一个开源项目来验证这个想法 👇

https://t.co/Sl1nMKd7Yq

👁 704❤️ 0🔁 0💬 1

2026-01-10

Yumin @YuminAI
Anthropic这帮人是有病吧
他们发明了plugin, agents, skills
但这不都是一堆markdown文件吗
为什么还区分那么多？

无非都是prompt
ok，有些prompt可以被重复使用
但你也不致于发明这么多概念啊

你就老老实实的说
这个是做ui的prompt
这个是做code review的prompt
这个是做web search的prompt ，但你可以同时开多个进程来跑这个prompt

我他妈还寻思这都是什么高科技呢
天天装神弄鬼，也不学点好

👁 700❤️ 7🔁 0💬 0

dify 细节做得好一些，coze 功能更多一些。dify 对我来说有个缺陷就是不支持 llm 原生的 function call，所以我用 coze 更多一些

ghostviper @A9yNtIHEjvVkW7C
dify真的可以用了，迭代模式好像比coze好用？coze的编排界面实在是太卡了，今天刚把远古时期Fastgpt做的编排迁移到dify，20分钟完成一个还新增了日期、天气、知识方面的功能，效率爆炸。

👁 697❤️ 3🔁 1💬 1

我们产品，池里平均一个号 👀

👁 695❤️ 3🔁 0💬 0

垃圾信息里，文字"糖"还好，现在视频"糖"更要命，要花掉普通人 50% 的信息接收时长

ruanyf @ruanyf
新的博客文章《信息就像糖一样上瘾》：工业革命有一个很少人提到的后果，就是人类可以大量生产糖了。

从此，大部分食物都添加糖，垃圾食品泛滥，因为糖会增加多巴胺的分泌，让你对糖上瘾，过量进食。

信息就像糖一样，也能增加多巴胺，让人上瘾。https://t.co/ccIYy1rW1Q

👁 687❤️ 2🔁 0💬 0

2026-05-22

👁 682❤️ 0🔁 0💬 1

杠杆只是种金融工具，没必要妖魔化，而且现代金融世界想要高速发展也离不开杠杆的

polebug @polebug
最近看到很多大 v 说千万不要开杠杆/合约，我不太认同。

杠杆/合约并不等于高风险，这个命题的关键在于“欲望”，欲望越大，杠杆倍率越高，这样才导致了高风险。

作为一个一开始控制不住欲望爆仓了，但是后面吸取教训，做好仓位管理，现在能轻松翻倍的合约玩家来说，杠杆是一种能快速提升资产的方式。

👁 676❤️ 3🔁 0💬 0

已经好几次被公司内部服务的缺陷给坑了，总会遇到一些奇奇怪怪的问题，吭哧一顿排查、拉会，才发现是受其他内部服务 / 基建给影响到😅

👁 653❤️ 4🔁 0💬 0

2025-07-15

👁 646❤️ 3🔁 0💬 0

2024-11-09

📈最近 eth 回本了，要不要换台 mbp max 呢？m1 max 已经用了好几年了🙃

👁 640❤️ 4🔁 0💬 3

2026-01-06

👁 637❤️ 5🔁 0💬 0

为什么我要说 GUI IS BUIILSHIT

来看看一个 AttributeGraph Cycle 的 GUI 问题，在 TDD Loop 下能让 AI 连续忙活多久 😅

nekocode @nekocode_cn
GUI IS BULLSHIT!

就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。

反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。

看来文本喂出来的模型，终究是个半瞎 🤔

👁 633❤️ 0🔁 0💬 2

Opus 4.6 + High Effort

👁 200❤️ 0🔁 0💬 0

最近给 biome 和 graphql-code-generator 提交的 pr 进度都不太顺利，一个因为涉及另外一个大改动暂时卡住了，一个一直没人有空 review 🫠

👁 630❤️ 5🔁 0💬 0

2026-02-26

👁 606❤️ 4🔁 0💬 0

👁 596❤️ 5🔁 0💬 0

2026-04-16

今天听到个搞笑的梗：

现在最危险的幻觉，不在模型里，在老板们那🤣

👁 577❤️ 8🔁 0💬 0

2026-01-17

来个暴论：未来 99% 的代码都将是开源的。

因为软件的代码会比白菜还便宜。软件的价值将来自于其他地方（数据、资源、服务能力等

👁 566❤️ 0🔁 0💬 0

2026-04-17

在做一件非常好玩、非常 meta 的事情🤣

👁 565❤️ 3🔁 0💬 0

2026-03-22

👁 557❤️ 1🔁 1💬 0

Tom Dörr @tom_doerr
Proxy for Claude models via Google AI Pro subscription

https://t.co/ZwEWNrn8dA

👁 552❤️ 1🔁 0💬 0

2026-03-07

分享点数据。最近给某产品加上「收费」后，日收入能有 200+

👁 549❤️ 4🔁 0💬 2

2026-04-09

神奇，时隔了两年半的 merge 😳

纯手工、古法编程时代的 pr，这个含金量还可以吧！

👁 541❤️ 2🔁 0💬 0

即使是还「活着」的社区，很多都已经在逐渐「劣化」。互联网用户下沉 + 算法分发内容，在整体网民素质还没提上去的情况下，劣币驱逐良币是必然

nekocode @nekocode_cn
其实 CSDN 能活到今天，都是同行的「大多数」用脚投票导致的。劣币驱逐良币，前面有多少好的社区都倒闭了，哀哉 🤡

👁 530❤️ 1🔁 0💬 0

👁 523❤️ 3🔁 0💬 1

2026-01-11

宝玉 @dotey
“你们应该多用 Bash。”

过去几周，Anthropic 的 Thariq 和几十家做通用智能体的公司开了电话会议。邮件助手、客服机器人、日程管理——各种产品形态都有。聊完一圈，他发现自己反复在说同一句话。

Bash？那不是程序员用的命令行工具吗，和这些产品有什么关系？

先看一个具体场景。

假设你有一个邮件 Agent，你问它：“这周我在打车上花了多少钱？”

传统做法是这样的：Agent 调用 API 拉取邮件，可能一次性取回 100 封，然后让模型从里面找 Uber、Lyft 的收据，加总金额。

问题在于 100 封邮件塞进上下文，模型要同时记住这些内容，从中筛选、计算。这对大语言模型来说并不轻松。容易漏，容易错，而且你没法验证它到底看了哪些邮件。

这就是典型的模型舒适区问题：数据量不算大到需要专门写程序处理，但又超出了模型一次性硬算的能力范围。夹在中间，很尴尬。

Thariq 的方案是：给 Agent 一个 Bash 工具，让它把中间结果存成文件。

听起来很简单，但背后的逻辑很有意思。

传统的工具调用是这样的流程：

工具 → 模型处理 → 输出结果

所有中间状态都在模型的“脑子”里，你看不见，也没法检查。

换成 Bash 之后，流程变了：

工具 → 存文件 → 搜索/过滤 → 模型处理 → 输出结果

模型可以先把 100 封邮件存到一个文件里，然后用 grep 搜“Uber”，再 grep“Lyft”，分别统计。每一步都有迹可查，最后加总的时候，它还能回头检查自己的中间结果。

这带来三个能力升级：

可复现。同样的命令再跑一遍，结果一样。你可以调试，可以排查问题。

可验证。模型不是凭“记忆”给你答案，而是基于实际文件里的数据。你信不过的话，自己也能打开文件看一眼。

可组合。一个命令的输出可以作为下一个命令的输入，管道一接，复杂任务就能拆成简单步骤。

Bash 让 Agent 从“脑算”变成了“打草稿”。草稿可以留痕，可以检查，可以改。这对需要准确性的任务来说太重要了。

邮件搜索只是最直观的例子。Bash 的能力边界其实很宽。

链式 API 调用是个常见需求。比如“把这周我发过邮件的联系人都找出来”，这需要先拉邮件列表，提取收件人，去重，再逐个查询联系人详情。一连串操作用 Tool calls 来做，调用次数多，中间状态难管理。用 Bash 脚本串起来，逻辑清晰得多。

视频和文件处理也是 Bash 的强项。ffmpeg 这个命令行工具，模型用起来得心应手。找视频里某个片段、裁剪、转码，一行命令搞定。

还有定时任务。在 Agent 运行的容器里，用 cronjob 或 at 命令就能创建定时执行的任务。用户说“每天早上 8 点给我发一份新闻摘要”，Agent 可以自己设好闹钟。

这些场景有个共同点：都需要多步骤操作，都需要保存中间状态，都超出了单次工具调用的能力范围。

但 Bash 是把双刃剑。

能执行命令意味着能做很多事，也意味着能做很多危险的事。rm -rf 一不小心就能删光整个目录。如果 Agent 被恶意提示词攻击，后果可能很严重。

Anthropic 显然考虑到了这一点。他们在 Claude Agent SDK 里做了一套权限系统，包括 Bash 命令解析器和分级权限控制。哪些命令可以直接执行，哪些需要用户确认，哪些完全禁止，都可以配置。

我用 Claude Code 的体会是，这套权限系统确实降低了心理负担。它会在执行敏感操作前询问你，而不是闷头就干。但安全护栏不是万能药。权限系统本身也可能有漏洞，Bash 解析器也可能被绕过。

安全护栏是必需品，但不能因此就觉得万事大吉。

强调 Bash 的好处，也得说清楚它的边界。

如果任务足够简单，别用。“今天天气怎么样”这种一次性查询，直接调 API 返回结果就行，没必要存文件再处理。杀鸡用牛刀反而更慢。

如果环境是 Serverless 的，用不了。很多云函数运行时没有可持久化的文件系统，Bash 的“存中间结果”优势就没了。

如果对安全要求极高，谨慎使用。命令注入的风险无法百分之百消除，金融、医疗这类场景可能更适合用白名单式的专用工具，而非通用的 Bash。

工具的选择取决于场景，而不是工具本身的强弱。Bash 很强，但不是所有场合都该用。

回过头看，Thariq 这条建议的真正价值不是“Bash 很强”这个结论，而是背后的思维方式：

让 Agent 的思考过程“落地”到可检查的中间产物。

传统的 Agent 设计把所有东西都塞进模型的上下文，一锤子买卖。Bash 提供了另一种路径：把复杂任务拆开，每一步都留下痕迹，可以验证，可以回溯。

想想看，这和人类处理复杂问题的方式多像。我们做复杂计算时会列竖式，写长文章时会先拟提纲，处理大量信息时会做笔记。不是因为脑子记不住，而是因为落到纸上更可靠、更容易检查。

Agent 也一样。不是说模型处理不了，而是有中间产物的流程更值得信任。我自己用 Agent 辅助写作，所有中间产物都会存成文件：网络检索资料、提纲、不同版本的草稿、画图的提示词。这些存下来后续就可以灵活组合。

Bash 不只是程序员的工具，更是让 Agent 具备可验证、可复现、可审计能力的关键一环。

👁 520❤️ 5🔁 0💬 0

2026-04-06

nekocode @nekocode_cn
一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

👁 519❤️ 3🔁 0💬 0

👁 515❤️ 4🔁 0💬 2

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

建议有使用 svgr 的 > react 18 的项目都可以使用上

👁 513❤️ 1🔁 0💬 0

2026-04-04

👁 501❤️ 4🔁 0💬 0

2026-02-08

来自 PayloadCMS CTO 的认可🌟

https://t.co/bkLlDtCYwh

👁 497❤️ 6🔁 0💬 0

2026-03-02

👁 495❤️ 6🔁 0💬 1

长远来讲，多 agent 很可能只是过渡产物。当 llm 的上下文容量、注意力有非常大的突破之后，提供全量、连贯的上下文是唯一解。

nekocode @nekocode_cn
关于这里，我的看法不一样 👀

在我看来 subagent 要解决的，还是「上下文」这个老难题。因为 llm 的上下文容量和注意力都是有限的，用不同的上下文来处理不同的任务是目前工程上的最优解。

而 subagent 在这里的核心价值就是上下文隔离，也是原 up 说到的，防止不同任务之间上下文互相污染。因为某段上下文对某个任务来说可能非常有用，但是对另一个任务来说可能就是噪音了。

你提到的类比成 thread/coroutine/worker，我感觉表象上确实是这样，但是核心要解决的问题可能不一样。

👁 488❤️ 0🔁 0💬 0

状态是万恶之源！🤡

👁 479❤️ 1🔁 0💬 0

nekocode @nekocode_cn
提问: AI 创业的话，Agent as a Service 可行不？🤔

👁 478❤️ 0🔁 0💬 0

shinnyChen @shinny__Chen
别说，还真是

👁 476❤️ 2🔁 0💬 1

2026-02-04

中文圈子来说，小红书的活人感真的比 𝕏 强几百倍，不管是技术还是非技术的圈子。
是推荐算法，还是用户群体的问题？还是说我这个账号废了😅

👁 474❤️ 2🔁 0💬 3

👁 466❤️ 9🔁 0💬 0

👁 458❤️ 2🔁 0💬 0

👁 443❤️ 7🔁 0💬 0

lcomplete @xlcomplete
有趣，太有趣了。

这个思路太棒了，让 Agent 访问数据库比访问文件系统更高效。

一看到这条推文，我的脑回路立刻就被激活，思路一下子打开了。

1、很早之前就被 Agent 从数据库查数据的能力给震惊过，Agent 只要能连对应的数据库，不需要提供表名等信息就能找到你想要的东西，也能轻松搞定数据统计和分析。
2、我在实现 huntly 的知识库对话功能时想过两个方案：markdown 和 mcp，却从来没想过让 agent 直接去数据库里查。

要让「知识库对话」更顺畅一些，只需要再结合时下流行的 skills，写一个 markdown，大致让 AI 知道 huntly 数据库是干嘛用的，以及一些关键数据要怎么查询就可以了。

换个角度，整个事情变得如此简单。

用我最近常说的句式来收尾，huntly 的含金量又变高了。😋

👁 443❤️ 5🔁 0💬 0

今天听到一个很有意思的观点：

一个公司有多少员工，不在于它需要多少人，而是在于它能养得起多少人 🤔

👁 442❤️ 2🔁 0💬 1

2026-01-07

👁 440❤️ 4🔁 0💬 0

2026-01-25

👁 411❤️ 4🔁 0💬 0

2026-07-05

nekocode @nekocode_cn
这里我提供个核心思路：

当你要写 prompt/skill，或者你已有的 prompt 已经很长的时候。

让 ai 把里面所有能转化成 lint rules 或者 script 的部分，都尽可能转化。

熵减、收敛、消除不确定性。

👁 400❤️ 5🔁 0💬 1

2026-02-03

👁 391❤️ 4🔁 0💬 0

👁 391❤️ 2🔁 0💬 0

身在中国。
开发老登们，前 20 年靠人口红利在互联网上捞得不少。现在互联网没有增量了，正在被另一个人口的回旋镖击中了：从业人员过剩 🤣

👁 385❤️ 1🔁 0💬 1

Tip: 多用「ROI」这个词

例如，涉及多个改动判断时，让 AI 选择所有 ROI 最高的改动

👁 379❤️ 3🔁 0💬 1

他想要还不容易。而且现在最大的瓶颈可能不是在 GPU 而是在训练数据上了👀

A2GUI @A2GUI
@buaaxhm 不可能。GPU都没人给他

👁 376❤️ 0🔁 0💬 0

2026-01-05

👁 374❤️ 5🔁 0💬 0

👁 367❤️ 5🔁 0💬 2

X Screenshot 已上传 Chrome Web Store，目前等待审核中，应该是目前市面上最好用的推文截图插件，敬请期待😄

👁 295❤️ 0🔁 0💬 1

X Screenshot 已上架！

- 支持一次选中多条推文
- 支持自定义 CSS，隐藏不需要的元素（如 Grok 按钮等）
- 支持时间格式化

https://t.co/VTpiQ8SrTm

👁 135❤️ 0🔁 0💬 0

👁 366❤️ 0🔁 0💬 0

2026-01-26

Michael Anti @mranti
我有一个小小的意见：我怎么觉得现在skills炫耀的功能，基本上我很快就可以用Claude Code手搓一个Python程序完成了，而且更稳定、更快、随时可调整订制。当然Skills把和AI的互动简化了，不过我觉得它增加的不确定性、控制力弱、延迟等问题，超越了它带来的好处。

👁 362❤️ 4🔁 0💬 0

2026-01-01

当初 FTX 的统一保证金体系也是独一档的。虽然倒闭让我的资金打了水漂，但比起金钱损失，更让我难受的是一个这么出色的产品就此成为历史。

Benson Sun @BensonTWN
FTX 倒了三年了。

撇開 SBF 做的那些事不談，純粹從產品角度來看，FTX 很多功能放到現在依然能打，甚至領先現在多數交易所。

子帳號系統到現在沒有任何一家做到類似體驗。FTX 的子帳號是原生帳號架構，不是那種層層疊疊、權限綁手綁腳的設計。開一個子帳號就像開一個全新帳戶，乾淨俐落。

美股代幣FTX 上輪週期就在做了。這輪才開始有交易所把這當賣點來宣傳，晚了一整個週期。

Quant Zone 更是一絕。不用寫程式就能建立自動化策略，我以前做套利都直接開 Quant Zone 跑，省下大量開發時間。

其他產品還包括指數合約、槓桿代幣，以及當時全網唯一的每小時結算、無cap 的資金費率，和 RFQ 的 OTC desk。

FTX 的產品設計確實超前了這個行業一整個週期。三年過去了，如果 SBF 沒作惡，如果 FTX 還在，我相信還會引領更多 CEX 的創新，真的可惜了。

👁 361❤️ 0🔁 0💬 0

👁 353❤️ 0🔁 0💬 0

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

2024-06-19

👁 352❤️ 3🔁 0💬 0

这个说法挺有趣。LLM 是 Runtime，Claude Code 是编译器，Prompt 是源码，所有原生提供的组织 Prompt 的方式（例如 Skills）都是语法糖。

DN-Samuel 🧑‍💻 @SamuelQZQ
Claude skills 能做到的事，在没有 skills 的时候，LLM也都能做到。

Skills 只不过是一种语法糖 (syntactic sugar)

程序员应该都能懂我的意思😂

👁 350❤️ 1🔁 0💬 0

2024-05-14

#GPT4o 比较好奇视频能力是直接整个视频文件作为 token 输入到 llm，还是说会预处理采样关键帧图片后再输入

👁 348❤️ 0🔁 0💬 0

已经忘记有多久没有进入过「心流」的模式了。

👁 346❤️ 0🔁 0💬 1

👁 336❤️ 1🔁 0💬 1

👁 333❤️ 5🔁 0💬 0

👁 331❤️ 3🔁 0💬 0

最可怕的不是 AI 会思考，而是人类放弃思考。把 AI 当外脑没问题，但别让它成为唯一的大脑。

👁 325❤️ 1🔁 0💬 1

2026-01-02

坚持和 AI 进行「反复、深度讨论」，而不是简单的拾人牙慧。

👁 221❤️ 1🔁 0💬 0

把公司的 Next.js 项目用 Bun 跑了下某个相对复杂的页面渲染场景，整体大概比 Node 快 10% 左右

👁 322❤️ 0🔁 0💬 1

2025-12-04

👁 200❤️ 0🔁 0💬 0

👁 315❤️ 2🔁 0💬 1

改变一直在发生！这是一次行业，乃至全人类脑力劳动者的「生产力」、「工作范式」的大洗牌，赶紧用 AI Build 起来🧑‍💻

👁 194❤️ 0🔁 0💬 0

Vibe Building，满大街都是拿着锤子在找钉子的人 😳

👁 310❤️ 3🔁 0💬 0

这个好像也不毒舌啊，没破防 👀

👁 298❤️ 0🔁 0💬 1

https://t.co/BjT6HVfnP9

👁 19❤️ 0🔁 0💬 0

晚安，玛卡巴卡 https://t.co/f1qZ04ZYd0

👁 288❤️ 1🔁 0💬 0

Hey，来看个好玩的东西 🤣

👁 278❤️ 2🔁 0💬 0

2026-01-24

不久前还是人类大危机「疫情时代」
没想到紧接着这么快就到人类大突破「AI 时代」

👁 278❤️ 0🔁 0💬 1

🤩 推荐一个我很喜欢的在抖音上做 8bit 音乐的创作者: https://t.co/rvsLChlHda

👁 277❤️ 3🔁 0💬 0

合理但也不合理。高层更需要的是判断力，但是完全不写代码容易逐渐丧失判断力。

Y11 @seclink
请教大家，这合理吗？

前几年公司里的一位架构师大神告诉我说，p5的时候80%的时间还能写代码。P6的时候40%的时间在写代码。

P7~p9之后90%的时间就会是开会，更重要的是识别出主要问题，并说服别人哪些事情更重要更紧急，哪些不重要。

确定先怎么做，后怎么做。

职业生涯越往后走，“沟通”的活就越重。真的对编码感兴趣的，白天开各种会晚上回家才写代码。-_-

👁 276❤️ 0🔁 0💬 0

2026-02-09

卧槽，又有两个很牛逼的 Idea。这周的 Vibe 目标又有了🤣

👁 263❤️ 1🔁 0💬 0

2025-12-13

达成新成就: deprecate 前的 merge

好消息: 去年给 graphql-code-generator 提的 MR，隔了一年多总算给 merge 进去了😳
坏消息: maintainer 准备把包给 deprecate 了😅

👁 239❤️ 0🔁 0💬 0

👁 238❤️ 3🔁 0💬 1

2024-06-24

👁 234❤️ 2🔁 0💬 0

2025-12-25

昨天刚把 Q4 的 OKR Review 填完，篇幅里 30% 业务开发，70% Infra 工作 😅 有时候真不知道在一个业务团队里搞这么多 Infra 会不会让人有点奇怪

👁 205❤️ 0🔁 0💬 0

2025-12-24

更有深度的 Insight 离不开好的 Taste。

👁 196❤️ 2🔁 0💬 0

2024-03-12

今天广东的天气终于放晴了🌞 #居家办公

👁 195❤️ 2🔁 0💬 0

2024-05-24

近期做的一些开源社区贡献。推荐一个能筛选给第三方的 PR 的方式，方便给别人列出你的所有开源贡献: https://t.co/bPhBCezG9H

👁 189❤️ 1🔁 0💬 0

2024-05-25

编程内功：
最近把 VS Code 的 JetBrains IDE Keymap 插件卸载了，用回自带的快捷键了，目前已基本习惯 🤣

👁 185❤️ 0🔁 0💬 0

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

👁 159❤️ 0🔁 0💬 0

👁 158❤️ 0🔁 0💬 0

👁 0❤️ 0🔁 27💬 0

👁 0❤️ 0🔁 61💬 0

👁 0❤️ 0🔁 0💬 0

推文 · 热度

Mon, 01 Jan 0001 00:00:00 +0000

👁 495,741❤️ 982🔁 86💬 81

👁 37,874❤️ 98🔁 3💬 7

2025-02-06

👁 9,948❤️ 18🔁 0💬 19

2025-09-06

👁 205,073❤️ 879🔁 137💬 95

2024-10-28

最近比较震惊的一件八卦：

老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...

👁 185,510❤️ 617🔁 49💬 46

2025-05-05

尴尬，一个五一假期直接把我阿里云服务给干欠费停机了😅一个业余兴趣项目，怎么感觉要做起来了😂

👁 92,154❤️ 200🔁 5💬 18

2026-03-03

👁 68,832❤️ 593🔁 72💬 31

2026-05-30

👁 51,327❤️ 91🔁 3💬 28

👁 47,496❤️ 234🔁 21💬 19

2025-12-28

👁 45,216❤️ 162🔁 14💬 12

2025-12-29

👁 2,740❤️ 3🔁 2💬 0

2024-11-11

👁 31,401❤️ 106🔁 10💬 13

2026-02-06

nekocode @nekocode_cn
介绍下 agent-worktree 的功能：SNAP 模式 ⚡

搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。

用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。

👁 27,452❤️ 168🔁 22💬 3

2026-02-13

nekocode @nekocode_cn
上下文工程，我常用的一个小技巧:

让 AI 把现状先写到一个 MD 文件里

git commit

Review & 修改 MD 文件

/clear

让 AI 基于 git diff（你对现状的修改意见）去解决问题

👁 25,904❤️ 63🔁 5💬 1

👁 24,831❤️ 25🔁 1💬 2

👁 1,072❤️ 0🔁 0💬 2

👁 24,713❤️ 138🔁 25💬 13

2026-06-10

一语成谶。早上 1on1 结束，新一轮总算到我头上了，last day 6/12 😅 好啦，可以开始整理简历了

nekocode @nekocode_cn
公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。

我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅

这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。

裁员、失业会是常态。每个打工人都需要警觉起来。

👁 24,651❤️ 54🔁 0💬 31

👁 23,607❤️ 190🔁 25💬 4

非常强大！

如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。

演示视频稍后整理发出。
https://t.co/bkLlDtCYwh

👁 2,032❤️ 23🔁 0💬 4

👁 23,184❤️ 21🔁 0💬 1

2024-12-29

https://t.co/0Nb4et8Ay5 这网站我也挺久没维护了，也没做宣传，现在每天稳定有差不多 30 左右的新增用户。这就是被动增长了么😆

👁 16,735❤️ 73🔁 9💬 6

👁 15,046❤️ 111🔁 14💬 10

2026-01-04

宝玉 @dotey
我个人不喜欢 Spec-Driven Development，有点像瀑布模型写系统设计文档，理论上看起来很牛，但是并不好操作，另外容易想的太多。

我比较推崇小版本迭代，不需要写详细的 spec，几句简单的 prompt 就可以开始生成，每次写一个可以跑起来的版本，然后一点点迭代，每次迭代完都是可以运行的版本

另外大多数时候，Claude Code 的 Plan Mode 就足够好用了，根据你当前想实现的，会写一个 plan 文档，可以反复沟通确认。

👁 10,322❤️ 38🔁 5💬 5

2025-07-09

👁 9,574❤️ 35🔁 0💬 7

2025-07-10

增长总共爆发过三次。昨天是新高😅真成烫手山芋了

👁 1,677❤️ 2🔁 0💬 3

2025-03-17

最近几天也不知道怎么回事，https://t.co/0Nb4et8Ay5 每天有上千的新注册用户 😂

👁 8,603❤️ 33🔁 2💬 10

2025-03-18

昨天一天最终有 4k 多新用户，这相当于之前一个多月的新用户量了😳

👁 1,894❤️ 1🔁 0💬 1

2025-04-08

https://t.co/0Nb4et8Ay5 突破 5w 用户了！🎉🥳

让 gpt 大概估算了下，目前流量下接广告的价值👇

👁 8,067❤️ 48🔁 3💬 11