首页 on nekocode 的博客

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

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

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

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

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

👁 353❤️ 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,609❤️ 18🔁 1💬 20

2026-06-10

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

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

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

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

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

👁 24,567❤️ 54🔁 0💬 32

2026-06-06

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

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

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

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

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

👁 5,061❤️ 22🔁 0💬 22

2026-05-30

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

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

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

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

👁 51,189❤️ 91🔁 3💬 28

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

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

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

https://t.co/6MADl8tp2u

👁 23,331❤️ 190🔁 25💬 4

😆 笑死，确实是相互糊弄

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

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

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

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

👁 1,707❤️ 2🔁 0💬 0

2026-05-24

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

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

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

👁 1,438❤️ 8🔁 1💬 2

2026-05-22

https://t.co/lsxd9k1TtV

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

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

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

👁 659❤️ 0🔁 0💬 1

2026-04-21

这里我提供个核心思路：

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

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

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

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

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

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

👁 764❤️ 4🔁 0💬 0

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

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

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

https://t.co/bkLlDtCYwh

👁 24,675❤️ 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

👁 697❤️ 2🔁 0💬 0

2026-04-17

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

👁 550❤️ 3🔁 0💬 0

2026-04-16

今天听到个搞笑的梗：

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

👁 564❤️ 8🔁 0💬 0

2026-04-13

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

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

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

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

👁 1,324❤️ 5🔁 0💬 0

2026-04-09

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

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

👁 528❤️ 2🔁 0💬 0

2026-04-06

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

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

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

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

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

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

👁 507❤️ 3🔁 0💬 0

2026-04-04

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

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

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

👁 489❤️ 4🔁 0💬 0

2026-04-02

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

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

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

👁 1,670❤️ 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 交互

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

👁 694❤️ 3🔁 0💬 1

2026-03-27

我的 vibe 日常：

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

token roi 直接拉满🤣

https://t.co/bkLlDtCYwh

👁 2,029❤️ 20🔁 0💬 2

2026-03-25

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

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

对我来说简直太完美了！

👁 601❤️ 0🔁 0💬 0

2026-03-24

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

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

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

👁 1,544❤️ 16🔁 0💬 1

2026-03-22

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

👁 550❤️ 1🔁 1💬 0

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

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

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

👁 329❤️ 1🔁 0💬 1

Opus 4.6 + High Effort

👁 193❤️ 0🔁 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 简直行云流水，身心愉悦。

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

👁 626❤️ 0🔁 0💬 2

2026-03-09

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

👁 179❤️ 0🔁 0💬 0

2026-03-07

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

👁 542❤️ 4🔁 0💬 2

GUI IS BULLSHIT!

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

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

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

👁 1,143❤️ 2🔁 0💬 1

Tip: 多用「ROI」这个词

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

👁 373❤️ 3🔁 0💬 1

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

👁 927❤️ 0🔁 0💬 1

2026-03-03

Vibe Debug 的核心：TDD

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

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

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

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

👁 68,763❤️ 596🔁 72💬 31

2026-03-02

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

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

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

👁 489❤️ 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 格式。不需要开场白、不需要总结、不需要问我是否满意。如果推文数据不足以支撑某个章节，留空并注明"[数据不足，建议手动补充]"而非编造。

👁 365❤️ 0🔁 0💬 0

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

👁 522❤️ 3🔁 0💬 1

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

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

👁 436❤️ 2🔁 0💬 1

2026-02-27

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

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

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

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

👁 461❤️ 9🔁 0💬 0

2026-02-26

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

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

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

👁 601❤️ 4🔁 0💬 0

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

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

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

👁 326❤️ 3🔁 0💬 0

https://t.co/qv9xO7S07N

👁 2,973❤️ 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

👁 700❤️ 0🔁 0💬 1

2026-02-19

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

👁 149❤️ 0🔁 0💬 0

2026-02-14

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

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

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

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

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

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

git commit

Review & 修改 MD 文件

/clear

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

👁 908❤️ 6🔁 0💬 1

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,835❤️ 62🔁 5💬 1

2026-02-11

Coding Agent CLI ─► ACP ─► Agent Team CLI

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

👁 302❤️ 1🔁 0💬 0

2026-02-11

谁说 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

👁 1,998❤️ 12🔁 2💬 6

Hey，来看个好玩的东西 🤣

👁 274❤️ 2🔁 0💬 0

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

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

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

👁 1,070❤️ 0🔁 0💬 2

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

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

git commit

Review & 修改 MD 文件

/clear

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

👁 24,752❤️ 25🔁 1💬 2

2026-02-09

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

👁 261❤️ 1🔁 0💬 0

2026-02-08

来自 PayloadCMS CTO 的认可🌟

https://t.co/bkLlDtCYwh

👁 495❤️ 6🔁 0💬 0

2026-02-07

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

👁 211❤️ 0🔁 0💬 0

2026-02-07

使用 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,092❤️ 6🔁 2💬 1

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,424❤️ 168🔁 22💬 3

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

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

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

👁 23,167❤️ 21🔁 0💬 1

X Screenshot 已上架！

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

https://t.co/VTpiQ8SrTm

👁 134❤️ 0🔁 0💬 0

非常强大！

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

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

👁 2,030❤️ 23🔁 0💬 4

2026-02-04

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

👁 473❤️ 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

👁 390❤️ 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,219❤️ 1🔁 0💬 1

2026-02-01

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

👁 294❤️ 0🔁 0💬 1

2026-02-01

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

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

https://t.co/SJ8fPHej4M

👁 364❤️ 5🔁 0💬 2

2026-01-30

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

👁 442❤️ 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

👁 331❤️ 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的互动简化了，不过我觉得它增加的不确定性、控制力弱、延迟等问题，超越了它带来的好处。

👁 361❤️ 4🔁 0💬 0

2026-01-25

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

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

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

https://t.co/6gq0QdGniN

👁 410❤️ 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 的含金量在持续上升。

👁 845❤️ 6🔁 0💬 0

2026-01-17

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

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

👁 565❤️ 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 的含金量又变高了。😋

👁 441❤️ 5🔁 0💬 0

2026-01-13

补充下 Nano Banana 给的配图。

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

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

👁 351❤️ 0🔁 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,486❤️ 7🔁 0💬 1

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 具备可验证、可复现、可审计能力的关键一环。

👁 518❤️ 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

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

👁 698❤️ 6🔁 0💬 0

2026-01-07

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

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

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

👁 439❤️ 3🔁 0💬 0

2026-01-06

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

👁 635❤️ 5🔁 0💬 0

2026-01-05

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

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

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

👁 373❤️ 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,316❤️ 38🔁 5💬 5

2026-01-03

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

👁 987❤️ 2🔁 0💬 1

2026-01-02

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

👁 220❤️ 1🔁 0💬 0

2026-01-02

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

👁 324❤️ 1🔁 0💬 1

2026-01-01

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

Benson Sun @BensonTWN
FTX 倒了三年了。

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

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

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

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

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

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

👁 360❤️ 0🔁 0💬 0

推文 · 2025 下半年

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

2025-12-31

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

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

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

👁 390❤️ 2🔁 0💬 0

2025-12-31

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

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

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

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

👁 349❤️ 1🔁 0💬 0

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

👁 309❤️ 3🔁 0💬 0

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

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

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

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

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

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

👁 275❤️ 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

👁 551❤️ 1🔁 0💬 0

2025-12-29

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

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

👁 2,739❤️ 3🔁 2💬 0

2025-12-28

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

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

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

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

👁 45,207❤️ 162🔁 14💬 12

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

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

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

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

👁 15,024❤️ 111🔁 14💬 10

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

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

👁 740❤️ 10🔁 0💬 1

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

👁 766❤️ 4🔁 0💬 1

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

👁 194❤️ 0🔁 0💬 0

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

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

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

👁 315❤️ 2🔁 0💬 1

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,055❤️ 2🔁 0💬 1

2025-12-13

达成新成就: deprecate 前的 merge

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

👁 239❤️ 0🔁 0💬 0

2025-12-04

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

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

👁 200❤️ 0🔁 0💬 0

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

👁 322❤️ 0🔁 0💬 1

放弃使用 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

2025-09-12

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

👁 515❤️ 0🔁 0💬 0

2025-09-12

最近在公司里开始搞 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,213❤️ 2🔁 0💬 3

2025-09-09

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

👁 454❤️ 0🔁 0💬 0

2025-09-08

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

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

👁 1,065❤️ 3🔁 0💬 3

2025-09-06

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

👁 205,036❤️ 880🔁 136💬 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,618❤️ 13🔁 0💬 6

2025-08-27

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

👁 800❤️ 3🔁 0💬 1

2025-08-27

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

👁 2,032❤️ 8🔁 0💬 1

2025-08-26

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

👁 1,900❤️ 7🔁 0💬 4

2025-08-14

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

👁 527❤️ 2🔁 0💬 0

2025-07-28

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

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

👁 2,432❤️ 6🔁 0💬 6

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-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 时也能正常访问

待续

👁 809❤️ 7🔁 0💬 0

2025-07-17

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

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

👁 1,653❤️ 8🔁 0💬 2

2025-07-15

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

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

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

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

👁 646❤️ 3🔁 0💬 0

2025-07-10

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

👁 1,677❤️ 2🔁 0💬 3

2025-07-09

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

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

👁 9,574❤️ 35🔁 0💬 7

2025-07-07

述职完了，松了口气。

饭碗应该是稳住了哈哈😆

👁 1,436❤️ 1🔁 0💬 2

2025-07-05

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

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

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

👁 3,788❤️ 15🔁 0💬 3

推文 · 2025 上半年

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

2025-05-05

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

👁 92,152❤️ 200🔁 5💬 18

2025-04-09

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

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

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

👁 4,029❤️ 2🔁 1💬 4

2025-04-09

明天入职！

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

👁 4,431❤️ 7🔁 0💬 2

2025-04-08

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

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

👁 8,066❤️ 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,682❤️ 17🔁 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-28

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

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

👁 4,367❤️ 14🔁 0💬 3

2025-03-18

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

👁 1,894❤️ 1🔁 0💬 1

2025-03-17

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

👁 8,603❤️ 33🔁 2💬 10

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

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

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

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

👁 0❤️ 0🔁 27💬 0

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

👁 1,407❤️ 5🔁 0💬 0

2025-02-12

这个市场里太多赌徒了。

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

👁 1,759❤️ 8🔁 0💬 5

2025-02-11

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

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

👁 3,327❤️ 11🔁 0💬 6

2025-02-07

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

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

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

👁 1,084❤️ 1🔁 0💬 0

2025-02-07

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

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

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

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

👁 1,616❤️ 7🔁 0💬 1

2025-02-06

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

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

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

👁 9,946❤️ 18🔁 0💬 19

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

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

👁 37,870❤️ 98🔁 3💬 7

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

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

👁 495,678❤️ 986🔁 88💬 81

2025-02-03

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

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

👁 2,819❤️ 10🔁 0💬 1

2025-02-03

噩耗，老板这波归零了😂

👁 7,629❤️ 22🔁 0💬 10

已修复所有数据😮‍💨

👁 1,593❤️ 2🔁 0💬 0

fixing 😭

👁 1,775❤️ 2🔁 0💬 1

总算吃了没做 backup 的亏了🫠

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

👁 2,895❤️ 10🔁 0💬 2

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

让我想起我的一个前同事，在他的个人项目里用到我们内部的某个 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

也不知道我是什么体质，日常工作中不管用什么库/工具，总会遇到各种 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,953❤️ 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,186❤️ 16🔁 0💬 1

2024-11-20

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

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

举个简单的例子:

👁 2,587❤️ 7🔁 2💬 0

2024-11-20

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

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

方法👇：

👁 1,473❤️ 11🔁 0💬 2

2024-11-19

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

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

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

👁 3,661❤️ 17🔁 3💬 7

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

github： https://t.co/AZDNmKOb6I

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

👁 0❤️ 0🔁 61💬 0

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

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

👁 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 然后部署到服务器

👁 853❤️ 5🔁 1💬 0

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

👁 948❤️ 5🔁 0💬 0

现在想想，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

说件两件可怕的事情：

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

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

👁 3,411❤️ 11🔁 4💬 1

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

👁 630❤️ 5🔁 0💬 0

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

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

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

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

👁 676❤️ 3🔁 0💬 0

在国内四个不同团队用过 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,392❤️ 106🔁 10💬 13

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

比真的赚到钱还要高兴。

👁 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,191❤️ 9🔁 0💬 3

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

👁 488❤️ 1🔁 0💬 1

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

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

👁 997❤️ 3🔁 0💬 1

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

👁 2,309❤️ 5🔁 0💬 0

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

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

👁 47,495❤️ 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

2024-09-09

https://t.co/n6eZPauIVS

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

👁 722❤️ 3🔁 0💬 0

2024-09-09

一个有趣的建议：

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

举个例子：

👁 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

10000 用户！

Sun, 08 Sep 2024 00:00:00 +0000

👁 407❤️ 4👀 25🔁 5💬 0

10000 用户！

给阿里 AntV 组贡献了点代码

Wed, 07 Aug 2024 00:00:00 +0000

👁 131❤️ 2👀 8🔁 2💬 0

给阿里 AntV 组贡献了点代码

现在习惯了在工作中遇到第三方库的问题的话，先本地 Patch，然后再给上游提 PR ，等 PR Merge & 发新版后再从上游同步下来，然后把本地的 Patch 删掉。千万不要嫌弃麻烦，一来是能回馈给开源社区，二来是这也能成为简历里重要的素材

这次提交 PR 的目标是 AntV 系列图表依赖的 antvis/util 底层工具库。修复了图表在某些情况下（我遇到的场景主要是在 Next.js 下）会抛出异常的问题。Review 了一周现在终于成功 Merge 进去了

推文 · 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

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

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

👁 5,804❤️ 6🔁 0💬 3

背景：
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

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

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

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

👁 158❤️ 0🔁 0💬 0

https://github.com/nekocode/use-shared-state

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

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

👁 159❤️ 0🔁 0💬 0

完成一半进度了

Thu, 20 Jun 2024 00:00:00 +0000

👁 387❤️ 3👀 13🔁 2💬 1

完成一半进度了

第一次独立做的一个产品，目前在 0 成本几乎没有做推广的情况下，居然达到 5K 用户了，离自己定的 10K 注册用户的目标只差一半啦 🤩

一些随想: 1️⃣ WASM 赋予了很多古老的 C(++) 代码登录 Web 的能力 🤔 2️⃣ 为什么选择 Web？因为 Browser 无处不在，大部分智能设备、甚至连各种 App 里都内嵌了 Web Browser 🌐 3️⃣ 没想到居然还挺多人对老游戏有情怀的 🎰 4️⃣ daisyUI 4 是一次失败的版本，oklch 有兼容性问题，fallback 也做得一般 😣 5️⃣ 后续想抽时间尝试在 DOSBox 上安装 Windows 来实现运行一些 Windows 游戏（想玩暴力摩托 🌚

知乎 · 2024 上半年

Sat, 25 May 2024 00:00:00 +0000

想法2024-05-25

编程内功：
最近把 VS Code 的 JetBrains IDE Keymap 插件卸载了，用回自带的快捷键了，目前已基本习惯 🌝 #独立开发的日常#

❤️ 2🔁 0💬 0

日注册突破 200！- 独立日志📔

Mon, 20 May 2024 00:00:00 +0000

👁 240❤️ 4👀 11🔁 4💬 2

日注册突破 200！- 独立日志📔

很神奇，EMU666 今天新增注册爆发了一波，是昨天的 6 倍多。昨天我也没做啥，就发了篇文章，阅读量 200 都不到

百度统计 83% 的来源是「直接点击」，说明主要流量还不是来自外链或搜索引擎，很有可能大部分来自用户自然传播 🤔

感觉 10K 用户的目标没那么遥不可及了 🌝

自然流量增多 - 独立日志📔

Sun, 19 May 2024 00:00:00 +0000

👁 209❤️ 2👀 8🔁 5💬 1

自然流量增多 - 独立日志📔

🤔 这两天自然流量突然多了不少，平均每天有 30 多个新增注册，暂时没有花任何成本。

一些小经验： 1️⃣ SEO 很重要，搜索引擎依然是一个很重要的入口 2️⃣ 懂得用 similarweb.com 分析竞品/榜样流量来源，然后 copy 3️⃣ 很多可以免费建立的外链 4️⃣ 尽可能提高前置流程的转化率（快捷的注册、试/使用

想要吐槽的是，国内的商业环境特别恶劣、封闭、垄断，普通人想要免费获得流量很难。所以一定要提前考虑出海的可能（例如提前做好 i18n

在线模拟器 EMU666 更新啦！

Sun, 05 May 2024 00:00:00 +0000

👁 336❤️ 3👀 19🔁 10💬 5

在线模拟器 EMU666 更新啦！

趁着五一放假，把业余维护的 EMU666.com 更新了一版。这个项目可以算得上是我近年来探索 Next.js 最佳实践的试验田，目前有着： 🔍 100% SEO 友好的页面渲染，超高性能的动、静态渲染分配 🇺🇸 甚至包括了 RTL 布局的 I18N 支持 🌗 夜间主题支持

本次更新变化日志： 1️⃣ 新增了 SFC 和 FC 模拟内核 2️⃣ 新收录了将近 100 个游戏 3️⃣ 首页大改版，新增了搜索、过滤、分页 4️⃣ 其他不可见的内核级别重大重构（包括文件系统

再合并了两个 PR 🎉

Tue, 02 Apr 2024 00:00:00 +0000

👁 306❤️ 2👀 7🔁 2💬 1

再合并了两个 PR 🎉

再合并了两个 PR

其实这两个 PR 在上上周已经给他们提了，但是其中一个因为分配到的 Reviewer 对改动没法完全确定，所以一直拖着。今天仓库负责人之一总算抽空回复并 Merge 了。

目前贡献的 Commit 数量，已经让我的头像出现在仓库的 Contributors 排行榜里了 🤣

廉价持续集成

Sat, 16 Mar 2024 00:00:00 +0000

👁 236❤️ 2👀 8🔁 2💬 1

廉价持续集成

我们用的是自部署的 GitLab，然后我们的 Runner 是和 GitLab 一起跑在一台配置一般的 EC2 上。

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

最近发现 GitLab 支持「按需」分配 EC2 来跑 CI Job： 🔗 https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/ 这表示我们可以按需使用更高配置的服务器来跑持续集成！长时间没有新 Job 的话 GitLab 会自动帮我们回收服务器 🤗

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

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

修 Bug 永无止境

Thu, 07 Mar 2024 00:00:00 +0000

👁 195❤️ 2👀 9🔁 1💬 0

修 Bug 永无止境

是的，抖音前端技术团队开源的 Semi Design UI 又双叒叕让我遇到了新坑 🌚 气得我都把「从 Semi Design 逐步迁移到 Radix/Shadcn」的卡片从又拖到「下期」里了 🤣

Semi Design 对 SSR 的支持太弱了，应该是从最初设计的时候就没考虑到。

不过最终还是给他们提交 PR 了。

分享下我们的 Frontend Tech Stack

Mon, 04 Mar 2024 00:00:00 +0000

👁 200❤️ 2👀 10🔁 3💬 0

分享下我们的 Frontend Tech Stack

1️⃣ Next.js *️⃣ SSR: 最初是 SSG，有了部分动态需求后改成 SSR *️⃣ App Router 👍 *️⃣ Image Optimization 配合 CDN 层图像处理 *️⃣ Standalone mode 2️⃣ Apollo GraphQL 👍 *️⃣ Code generator: 接口强类型 *️⃣ Query batching *️⃣ Persisted queries *️⃣ Http caching: 部分请求改成 GET 方法 3️⃣ Semi Design *️⃣ DSM: 很方便的在设计师、工程师间同步设计资源（色盘、样式等 4️⃣ Tailwind CSS 👍 *️⃣ tailwind-merge *️⃣ prettier-plugin-tailwindcss 5️⃣ @nekocode/use-shared-state: 羽量级状态分享 6️⃣ i18n *️⃣ 文案维护: Lark（飞书国际版）多维表格，配合本地脚本进行双向同步 *️⃣ 机器翻译: GPT4 + Json mode *️⃣ ESLint custom rule: 未翻译文案的检测 7️⃣ Docker 部署

又双叕给抖音 FE 修 Bug 了

Fri, 01 Mar 2024 00:00:00 +0000

👁 250❤️ 2👀 11🔁 2💬 0

又双叕给抖音 FE 修 Bug 了

年前年后各又给抖音 FE 团队出的 Semi Design UI 库修了两个 Bug，目前在项目贡献榜中已经排到了第 19 了（笑哭 😆

客观评价，Semi Design 的工程实用性很强，但是细节还是做得一般，包括测试代码也不够全面。很多我提的 Bug 都是小版本发布时新出现的，因为公司的项目在用，实在影响到生产所以顺手修复了。

瞎谈下近况

Sun, 09 Jul 2023 00:00:00 +0000

👁 443❤️ 3👀 32🔁 1💬 0

好久没在网络上输出内容了，出来冒个泡。

最近两年绝大多数时间都投入到工作里了，是我职业生涯以来最忙的时候。为了量化我的工作，我魔改 gitinspector[1] 增加了 TypeScript 和 Dart 语言的支持，然后统计了下我目前公司所有仓库的有效代码（排除掉工具自动生成的代码、只统计代码文件）：

gitinspector 报告

从报告上看，意味着从我入职时间算起，全年无休的话每天会改动 700 行代码，其中有 200 行代码一直存活到现在。这存活的 16W 行代码里面，大概有 11W 行前端代码和 5W 行后端代码，总体还是做前端比较多。

分享些写这些代码期间有趣的事:

前端我们最开始单纯用的 React 做 CSR，没有用任何支持 SSR 的框架。后来考虑到 SEO 和首屏渲染的优化，迁移到 Next.js 上了
我们用的是 SSG 模式，这样可以直接把产物部署到 OSS 上
对于需要获取后端数据进行渲染的页面，我们只要定期重新生成就好了
在开发页面的时候，除了考虑响应式布局设计以外，还得多考虑一个服务端首屏如何渲染的维度
移动端 App 如果选择 Hybrid 架构的话，千万别选择 Flutter，性价比最高的还是 React Native
我们最开始选择的是 Flutter + Hybrid，结果网页渲染性能很差，因为渲染路径过长了，系统 WebView 要先渲染到 Flutter 层，进行合成后再渲染到屏幕上
后来我们新的 App 就选择 React Native 了
我们最开始后端是用 Java 写的，后来把新业务都迁移到了 Node.js 上
这里的原因我在知乎上回答过，就不细说了。最主要是 Node.js 在处理 I/O 密集问题上更有优势

总结了点 Infra 相关的事

Wed, 05 Oct 2022 00:00:00 +0000

👁 707❤️ 7👀 12🔁 2💬 1

总结下最近做的 Infra 相关的工作。

基础设施

从阿里云迁移到 AWS 并深度使用后，我的感受是 AWS 确实当之无愧是全球最领先的云计算服务商（狗头

我们用到的服务如下:

基础设施

DNS: Route 53
路由策略、流量管理
可用性监控、健康检查
SSL 证书: Certificate Manager
AWS 内免费使用、支持通配符、多域名
能直接部署在 CloudFront 甚至 ELB 层

部署到 NLB

注意: ELB 层不支持重定向，所以想要把 HTTP 请求重定向到 HTTPS 的话，需要在服务器上用 Nginx 来处理

CDN: CloudFront
Function: 支持在 CDN 层对流量进行处理。例如我们目前重定向 www 到裸域名就是在 CDN 层做的
EC2
需要注意，暂停 EC2 实例也会让 AWS 释放 IP 占用（可以看出 AWS 在资源利用率上做到了极致
S3

软件/工具

版本控制系统: Git / GitLab

知乎 · 2022 下半年

Sat, 10 Sep 2022 00:00:00 +0000

回答2022-09-10

2022年了nest.js在国内怎么样？

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

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

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

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

❤️ 54💬 16

DCA / 马丁格尔策略

Wed, 10 Aug 2022 00:00:00 +0000

👁 560❤️ 2👀 12🔁 16💬 2

DCA 策略

首先给大家看一下我的一个机器人🤖️，仅仅运行了 20 天，ROI 就达到了 20% 以上（相对于历史最大投入金额）。

DCA 机器人

可以说，DCA 策略还是挺适合在熊市、震荡行情下运行的。

什么是 DCA？

DCA 是「Dollar-cost averaging」的缩写，中文可称作「平均成本法」，指的是将资金在特定间隔期间分批买入，达到在波动的价格下平摊持仓成本的策略。

举个简单的例子，假设我们在某个股票 100 时建仓，然后在价格跌到 90、80 时分别补仓，最终我们的仓位平均成本就从初始的 100 下降到了 90。

DCA

DCA 的核心在于「仓位管理」，比起将所有资金单次建仓，分批建仓可以显著降低风险。

马丁格尔策略

马丁格尔实际是一种赌场策略：当每次「输钱」时就以 2 的倍数再增加赌金，直到赢为止。

在资金无限的情况下，这是一种必胜策略，因为不管你输多少次，只要最终赢一把就可以连本带利赢回来。

它的关键在于「加注」，当我们把它和 DCA 结合起来，延续上面的例子，假设我们在价格 90、80 时翻倍加仓，最终我们的持仓成本会降到 86。

Martingale

我们把「价格下跌 10」认为是输，而「价格上涨 10」认为是赢。那么即使你连输了两次，但是你只要最后赢了一次你就能连本带利赢回来。

被誉为交易的「圣杯」？

马丁格尔看起来是个必胜的策略，但实际上每次加仓我们都需要投入更多的资金。假设我们初始开仓金额为 $100，如果每次我们以 2 倍进行加注，那么加仓 10 次后：

100 + 100 x 2¹ + 100 x 2² + ... + 100 x 2¹⁰ = 204700

推文 · 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

Quant 之路 - 资金费率套利

Tue, 12 Oct 2021 00:00:00 +0000

👁 505❤️ 2👀 7🔁 5💬 3

永续合约和资金费率:

最早币圈合约只有 交割合约，后来 BitMEX 创新的推出了 永续合约，大受欢迎。目前主流交易所基本都支持永续合约。

交割合约

交割日期越远、价格波动越大、合约价格会和现货价格偏离越大，但到了交割日强行按现货价格结算，因此价格总会回归。

永续合约

和交割合约定时交割不同，永续合约可以一直持有，所以需要一个机制来保证合约价格和现货价格尽量接近，这就是资金费率机制。

如果一段时间价格看涨、做多的人很多，会导致永续价格高于现货，此时资金费率一般为正，做多的一方要向做空方按持仓缴纳费用，行情偏离越大费率越高，最终使得差价倾向于下跌。反之亦然。

做多交易永续合约相当于借钱加杠杆，而资金是有使用成本的，所以大多数时候都是 0.01% 的正向率。资金费率每 8 小时收取一次，频率较高，因此永续价格往往十分贴近现货。

总结: 资金费率是针对「永续合约」、用来拉近合约价与现货价的机制。

资金费率差、价差

单个交易对，在不同的交易所内的合约价、资金费率都不一样。我们可以从不同交易所、同一交易对中寻找收益最高的「套利机会」。

资金费率差盈利

以上图为例（2021-10-12 号数据），BTC/USD 交易对在不同交易所间最大费率差为：

0.0152% - -0.0331% = 0.0483%

此时，假设我们以相同仓位价值，同时在 FTX 对 BTC/USD 进行做空、在 Bitget 进行做多，则能吃到两个资金费率的总和，共 0.0483%

如果这个费率差可以持续一天的话，我们吃满三次，一天则能吃到：

0.0483% * 3 = 0.1449% 的利润

这样年化大概就有 0.1449% * 360 = 52%

这还只是在行情一般、非最优机会（通常小币种的利润空间更大）、没加杠杆下的表现。

举个利润空间比较大的例子：

这里针对 IOTA 交易对，只吃一次资金费率就能有 0.14% 的收益了。

不过，这种机会通常不会一直持续，但是捕捉到的话就能吃到不少收益。

价差盈/亏

进行对冲时，双边仓位的开仓和平仓价格可能会发生不同幅度的波动，因此最终可能会产生额外的价差盈亏。

接着上面的例子，我们假设此时 FTX 上 BTC/USD 的市价为 $57,409.50:

知乎 · 2021 下半年

Tue, 31 Aug 2021 00:00:00 +0000

回答2021-08-31

useEffect监听了很多变量怎么办？

如果是简单的数据处理的话，我会用 @justjavac 答案里的做法：直接在 rendering 里处理数据。但是如果是计算密集的处理的话，我建议用 useMemo:

const { data: data1 } = //...

const parsedData1 = useMemo(
  () => data1?.data ? JSON.parse(data1.data) : undefined,
[data1]);

另外，如果答主一定要维护额外的 state 的话（例如在其他地方需要改变 state），那就把你那个大的 useEffect 拆分成四个小的 useEffect 吧。

再假设你想要等四个请求都完成再 setState 的话，可以:

const dataRef = useRef([data1, data2, data3, data3]);
dataRef.current = [data1, data2, data3, data3];

const isDone = data1?.data && data2?.data && data3?.data && data4?.data;
useEffect(() => {
  if (isDone) {
    setState1(dataRef.current[0]);
    setState2(dataRef.current[1]);
    setState3(dataRef.current[2]);
    setState4(dataRef.current[4]);
  }
}, [isDone])

这里只是提供思路，换我的话我是不会用四个 state 来维护状态。

知乎 · 2021 上半年

Mon, 24 May 2021 00:00:00 +0000

想法2021-05-24

service worker 领域上目前看到过两个神应用，一个是 jsproxy（曾经魔改过它的代码），另一个就是最近刷屏了的在 browser 上跑 node。绝了🤔

❤️ 0🔁 0💬 1

想法2021-05-16

有意思，参考下猪八戒网？（狗头

🔗 该怎么给程序猿定 KPI ？

❤️ 2🔁 0💬 0

想法2021-05-10

遇到第一个热心分析我小破库的网友🌝

❤️ 5🔁 0💬 3

回答2021-05-08

为什么Next.js和Nuxt.js发布时间只隔了几小时？

专门去翻了下两个开源项目的 git commit history。

next.js 在 10 月 25 号的「发布」实际上是将 1.0 版本开源出来，而实际该项目最早的 commit 是在 10 月 6 号：

vercel/next.js

而题主说的 nuxt.js 在 10 月 26 号的「发布」实际上只是作者创建了 GitHub 仓库而已，nuxt.js 的第一个可用的原型完成的时间是在半个月后的 11 月 7 号，而且可以看出很多代码中有参考了 next.js 的痕迹：

我的 H2 OKR

Sun, 16 May 2021 00:00:00 +0000

👁 489❤️ 2👀 25🔁 0💬 5

好久没更新了，先讲点最近看到的一些事：

长江后浪推前浪。最近在社交平台上发现国内有越来越多在读但是技术却很强的年轻人。有意思的是他们很大一部分和我一样都有「洁癖」，例如会用 Latex 来写排版很工整的简历，文本排版时总会遵守「中文文案排版指北」。

「另有研究顯示，打字的時候不喜歡在中文和英文之間加空格的人，感情路都走得很辛苦，有七成的比例會在 34 歲的時候跟自己不愛的人結婚，而其餘三成的人最後只能把遺產留給自己的貓。畢竟愛情跟書寫都需要適時地留白。

與大家共勉之。」

—— vinta/paranoid-auto-spacing

「中文文案排版指北」最早源自于呆湾。不得不承认呆湾人的素质确实高，在很多事情的细节上都追求完美。不过值得庆幸的是，国内的年轻人已经逐渐追赶上来了。

以我近几年的经验来看，国内整个招聘市场可能看似越来越「内卷」，但是现实是大部分中小企业依然很难招到 Junior 级别中能力强的员工。另外，不管是中小企业还是巨头，每年也都在花更多的成本招聘甚至挖角 Senior 级别的工程师。
千万不要看不起或者抵触一些你看不懂的事物或逻辑。曾经因为这个而错过了很多次起飞的机会，现在会谦逊很多，后面有时间再展开分享。

下面是正题😄

2021 即将进入下半年了，作为 93 年正值焦虑的中老年人，决定用 OKR 来规划下我下半年想要达成的业余目标。

在我看来事情的成功至少需要明确的计划、持续的坚持以及执行力。

Objective 1: 提高社区/技术影响力
KR 1: 在 GitHub 将收获 Star 的数量提高到 9600 个 (9496/9600)
KR 2: 在 GitHub 新开源一个仓库 (0/1)
KR 3: 在知乎将粉丝提高到一万个 (9762/10000)
KR 4: 在知乎新增 30 个答题 (0/30)
Objective 2: 发布业余产品，尝试增加收入渠道
KR 1: 在 Google Play 和 AppStore 上发布一个 App (0/1)

知乎 · 2020 下半年

Sun, 06 Dec 2020 00:00:00 +0000

回答2020-12-06

如何评价TypeScript新特性 template string type?

第一次见有语言能支持编译期对字符串内容进行静态检查的（可能我孤陋寡闻了），厉害啊。All in TS 就对了

❤️ 4💬 0

知乎 · 2020 上半年

Mon, 15 Jun 2020 00:00:00 +0000

回答2020-06-15

非科班33岁男转行前端前景如何，求业内大佬指点一二?

去掉 33 岁，或者改成国外的话我觉得是有机会的。

但如果不是的话，不建议。国内内卷程度会让你绝望，就怕你被割几轮韭菜（报培训啥的）后结果还是只能屁颠屁颠的逃离这个行业（狗头

❤️ 1💬 0

回答2020-06-15

typescript写后端的优势是什么？

既能用上 JS 庞大的生态
又能享受 TypeScript 不输于（甚至碾压）其他静态语言的类型系统
有着世界上最庞大的工程师群体，可以跟你交流（/解决问题）

性能？讲真，你接触到的 99% 的项目可能都到不了需要通过切换语言来提高那丁点性能的地步。

而且你再往前看看？Serverless 上不也一样推荐跑 JS，语言（/解释器）上的那点性能损耗真不是事

❤️ 10💬 7

回答2020-06-15

除 Redux 外，目前还有哪些状态管理解决方案？

Redux 确实是目前流行的状态「管理」方案，但实际上题主问出这种问题的时候，我在猜测很可能你的场景并不需要对状态进行「管理」，你可能仅仅想要在组件间「共享」状态而已。

如果你确定你是后者的话，那么我可以给你推荐下这个（被 Typora 的作者 Star 过哦哈哈）：

这是一个结合 React Context API 的一个状态共享库，用法和 useState 类似（仅需把 initialState 改成 SharedState 的 Context）:

const [state, setState] = useSharedState(UserNameContext);

为什么推荐它？因为它几乎是用法最贴近官方接口、没有额外概念的、高性能的、带单元测试的（狗头）、最轻量级的 State-Sharing 实现（对比其他一众花里胡哨的状态管理/分享方案来说）。

回到原题，之所以很多人会觉得 Redux 很繁琐很可能是因为你并不需要用到它，Redux 应该更适合用在需要状态机、状态可回溯、或大型复杂项目等场景（例如编辑器）。对于轻量级的项目、甚至是库项目，Redux 的各种范式、boilerplate code，以及可能对 Redux 无法熟练掌握的你，只会让你的工程最终变成一坨 Shit

看看我们都在用着哪些技术？

Sun, 24 Nov 2019 00:00:00 +0000

👁 546❤️ 12👀 1🔁 0💬 0

作为技术导向的团队，通过正确的技术来推动商业发展是我们的重要任务之一。接下来，将简单介绍下我们团队中用到的一些新技术或工具。

Docker

Docker 是我们团队最喜欢且最常用的技术之一，我们通过它来部署和维护大量基础服务（GitLab、CI、Registry 等）以及线上产品。借助 Docker Compose，我们可以在任意一台服务器上准确、快速地部署复杂的服务群。而通过轻量级的 Portainer 和 Swarm（未来可能切换到 k8s），我们可以很方便地管理我们的服务器和容器集群。

这些 Docker 社区提供的各种设施和工具，让我们彻底摆脱了「部署炼狱」，从而可以轻松地手工、甚至通过持续集成来自动部署任何服务。而通过像 Docker-Gen 这类的工具，我们还可以对容器进行一些监控和自动化，例如自动编写 Nginx 配置、自动申请免费 SSL 证书等。

GraphQL

目前我们的大部分服务接口都在使用 GraphQL，它简化了我们在接口开发上的很多工作。

不同于过往的 Rest 接口开发，我们的工程师都是面向 Schema 开发，「Schema 即文档」。而社区提供的一些工具能大量提高我们的开发效率，例如通过 Playground 可以进行接口调试，通过代码生成器可以将 Schema 转换成指定语言的类型代码。

通过 GraphQL 语言来查询数据让我们的前端变得更灵活。我们可以自由组合需要的字段，可以在一次 Http 请求中查询到所有需要的数据。此外，像 Relay 和 Apollo 这类 GraphQL 前端框架还提供了字段粒度的全局缓存、乐观更新、分页等前端常用的功能，能大量地减少前端的负担。

Flutter

对于初创团队而言，能够快速地迭代产品十分重要。所以为了提高生产效率，我们在开发移动客户端时更倾向于选择跨平台的解决方案。而在经过一段时间的尝试和研究后，我们在 Flutter 和 React Native 两个热门方案中最终选择了 Flutter，并用它来开发了一个完整的社交类型 App。

即便 Flutter 以及其社区还处在初期阶段，但是其工具链已经足够成熟，对于技术能力较强的团队是可以直接用在生产上的。而对比起 React Native 来说，Flutter 真正能让你用一套代码来完全控制你的前端渲染，只有渲染无关的部分才可能需要写 Native 代码。

为跨国公司打造顶尖用户体验的加密货币交易所客户端

Wed, 23 Oct 2019 00:00:00 +0000

👁 594❤️ 24👀 1🔁 0💬 0

实现一个高实时、国际化的交易所客户端并不是一件简单的事情。我们在帮助客户实现这一目标的同时，还保证了产品的用户体验达到行业一流的水准。

UI

我们在图表的交互细节和性能上做了大量优化，确保 UI 元素能提供丰富、流畅的交互反馈。

Interactive Chart

Candlestick Chart

为了实现应用中所有可视化数据的实时更新，我们采用了响应式框架来处理所有 WebSocket 数据连接。

Real-Time Orderbook

Real-Time Depth Chart

在一些比较重的交互场景下，譬如交易 Bottom Sheet，我们投入了大量精力来编写控件进行细节还原。

Smooth Bottom Sheet

在列表滑动上，我们对控件渲染进行了优化，流畅度超越了绝大多数的竞争产品。

Smooth Scrolling

此外，我们还编写了脚本来快速实现应用的多语言支持。而且应用对多分辨率、甚至横屏都做了完美的适配。

Multiple Language Support

Landscape Mode Support

Tech

在技术选型上我们采用了 Kotlin、Jetpack 等业界最新的技术，这加快了我们的研发效率、降低了客户的成本，并且确保了工程能够与时俱进。

整个应用所有的图形都使用矢量图进行绘制，这保证了 UI 能适配不同分辨率下的屏幕，而且还大大减少了应用的体积（最终只有 8MB）。

此外，我们的脚手架[1] 以及很多代码的质量都达到了开源标准。在大量借助开源力量的同时，我们也反馈了一些贡献给上游。

一直以来，我们都在追求更先进的技术、工具以及经验，而通过这些来为客户提供高效率、高质量的技术支持则是我们的服务目标。

参考资料

[1]

脚手架: https://github.com/nekocode/create-android-kotlin-app

知乎 · 2019 下半年

Fri, 20 Sep 2019 00:00:00 +0000

想法2019-09-20

写了一个多月 Flutter 后的感受：基本支持 @千里冰封你懂吗回答里的大部分观点（除了关于 Gradle 相关的描述外，狗头）。Dart 是个不坏的选择，但绝对不是最好的选择（这里抛开商业相关的顾虑）。Dart 作为一门现代编程语言，比起老前辈 Js、Java 来说确实「智慧」了不少，但是对比起 TypeScript、Kotlin 还是差得远，以至于给我一种高不成低不就的感觉（或许是 Kotlin 确实太优秀了）。而 IDE 的支持即使迭代到目前依旧问题很多（不够智能、经常报错信息位置不对），但这个也确实怪不了 Google，论 IDE 技能 Jetbrains 是吊打 Google 级别的。

个人猜测 Flutter 很长一段时间不会选择支持其他语言，更不可能抛弃 Dart。我个人很喜欢 Flutter，它还原 UI 的速度比 Android 快很多很多，但是 Dart 让它稍微逊色了一点点，目前我只希望 Dart 以及周边能随着 Flutter 的推广进步得更快一些。

https://www.zhihu.com/question/267644807/answer/327361408

❤️ 13🔁 2💬 6

李笑来上 GitHub 割韭菜了？

Sun, 28 Apr 2019 00:00:00 +0000

👁 752❤️ 13👀 0🔁 0💬 11

今天来说说新东方英语老师李笑来，啊不，应该是著名企业家兼投资人才对 hhhh

资本圈里的或玩过数字货币的应该都认识这位老师。他和锤子手机老爹一样喜欢经常在媒体面前上蹿下跳，一会说自己是「比特币首富」，但却又从未公布过任何证据。

一会又被泄漏录音，被爆自己在区块链行业割着韭菜还骂韭菜蠢，还不忘顺带喷下其他从业者，称傻 X 的共识也是共识，只有赚到钱才是成功。。。

韭菜们哪里错了，为什么要这样对韭菜们！！！不对，边割着你们又边暗地里骂你们不正说明着他心底里其实还是爱着你们的么，嗯，一定是这样的？

当然，今天主要也不是来损李笑来老师的，失敬失敬。今天之所以会谈到他，是因为我发现他竟然有 GitHub 账号！

实际上，GitHub 并不是一个普通人会上的网站，这个网站上的绝大多数用户都是程序员。作为非程序员出身的李笑来，为什么会注册 GitHub 账户呢？好奇心驱使我仔细扒了下他这个账户。

首先，从上图中他的个人页面来看，至少能得到几点信息：

•他的 Follower（粉丝）特别多，在如此小众的平台上都到达了 5.2k 了；•看起来近一年来有持续地在贡献东西。

于是乎，我继续扒了下他的所有仓库，发现他果然是把 GitHub 当作他的电子书博客了，分享的清一色是他写的电子书。例如教别人如何学英语的：

再例如，教你如何走向「成功」的鸡汤类管理文学：

更让我意想不到的是，他居然连这个都能出书？？？（黑人问号

果然是成功学导师，不管是哪个方面都是辣么的成功！在下佩服佩服。。。

从各方面来看，笑来老师是想在 GitHub 上持续布道啊。难道正如 GitHub 上某位网友说的，是开始想在程序员圈子里圈粉割韭菜了么？

我用垃圾邮件堆起了这个 GitHub 交友群！

Wed, 24 Apr 2019 00:00:00 +0000

👁 740❤️ 17👀 0🔁 0💬 12

最近我干了件有趣的事！

众所周知，GayGitHub 网站上是允许个人在 Profile 页上展示自己的 Email 的：

假设你有私事想联系上 GitHub 上某个开发者，Email 几乎是公开的唯一联系方式。例如我公开的个人邮箱就偶尔会收到一些网友的来信：

当然，除了 GitHub 社区上的网友会联系你之外，有些聪明的招聘工作者也可能会通过这个途径联系上你：

事实上，很多信息化的猎头公司都开始爬 GitHub 上有价值的用户，然后通过群发 Email 的方式来 Push 一些招聘信息了。

这其实是一个不错的增长机会，所以我开始动歪脑筋了 (°ー°〃) 要不我也群发 Email 试试能不能在 GayHub 上交到朋ji友？（逃

于是我写了个 Node.js 程式，爬了 GitHub 上几个知名用户所有 Follower 的 Email。然后群发了一封交友 Email：

随着这个 Node.js 程式在我的笔记本电脑上持续跑了几天，截至目前已经发出去了 7 千多封邮件，并且有 30% 左右的用户打开过该邮件～

这其实上是一次小小的 Growth Hacking。而在持续发送邮件的期间，我收到了很多回覆，有很多人加我的微信或回我的 Email。还有不少外国友人联系上我（捂脸

值得一提的是，加了我的微信的网友里有很多有趣的人。有在各种巨头公司工作的，有 GitHub 上几千 Follower 的，有正在参与某知名芯片开发的。但最让我惊讶的是，这里面居然还有参与过国内顶级网游开发的大佬。。。

是的你没看错，就是那个轱天乐和渣渣辉都全力推荐的介款游戏 hhhhh

酸酸酸酸！国内员工还在抵制 996 时，日本微软宣布开始试行「一周三休」！

Tue, 23 Apr 2019 00:00:00 +0000

👁 745❤️ 16👀 0🔁 0💬 5

昨日（4 月 24 日），微软日本公司总裁兼代表董事 Takuya Hirano 在东京举行的公告中表示，将在 8 月实施「ワークライフチョイスチャレンジ 2019 夏」（2019 夏季工作 - 生活选择挑战）项目。

简而言之，就是 2019 年 8 月内的所有星期五，微软日本全职员工将享受「特殊带薪休假」。这意味着一周不仅给你休三天，有一天还是带薪的！

Takuya Hirano 表示，公司旨在推动「工作生活选择」原则，强调工作方式的多样性、主体性，每个员工可以根据工作和生活的情况选择不同的工作方式。

虽然假期的增加将减少员工 20％的工作时间，但他预计这会让员工改变自己的心态，提高创造力从而保证工作量。

事实上，这也并不是日本企业第一次尝试为员工提供「一周三休」的工作方式。早在过去几年，为了留住人才和提高员工的生产力，日本「优衣库」、「肯德基」、「雅虎」等企业都曾宣布过各自的「一周三休」工作制。

日本媒体曾经对此进行过民众意见调查，大多数人还是持赞同意见的。

联想起国内近期现象级的「996.ICU」运动：

国外都在探讨如何提高员工的工作效率的时候，国内的某些企业首先想的反而是如何剥削员工的生活时间？？？

某些企业家甚至想把 996 和崇尚奋斗画上等号。结果惨遭人民日报打脸：

这等嘴脸还真🐔你太美。996 不给加班费就已经是耍流氓了，你还偏要争辩说这不是耍流氓，难道免费加班真的是为了实现人类共产主义的伟大前行？？？

事实上，随着社会生产力的不断提高，发达国家的就业市场早已逐渐变成买方市场了。新生代的应聘者们更关注个人感受，待遇差的工作已经很难找到愿意应聘的人了。

知乎上曾经有个过千万阅读量的问题「怎样看待应届生喜欢辞职？」

这个问题稍微改一下也是成立的「怎么看待如今那么多企业留不住应届生？」。

很多时候问题不是仅由单方面造成的，新生代的应届生在面对不公的待遇时更有勇气辞职了，那企业是不是也该好好反思下剥削老实人的套路已经开始不凑效了呢？

知乎 · 2019 上半年

Tue, 16 Apr 2019 00:00:00 +0000

回答2019-04-16

gradle别人引用我的jar包时，如何自动下载依赖包?

单纯一个 jar 包是不包含依赖信息的哦。可以传到 maven 仓库，然后在 pom 文件中添加依赖的第三方 jar 包。然后其他人通过 maven 依赖你的 jar 包时就会把依赖的其他 jar 包也依赖进去了。

❤️ 1💬 1

回答2019-04-01

各位开源作者对996.icu里面提到的禁止996公司使用开源库的协议有什么看法？是否会考虑添加？

不会考虑使用。

协议的直接受害者是工程师，公司哪会管你用的什么协议。需求摆在那，996 实现不了的话只能继续加班啊。

❤️ 4💬 1

想法2019-02-25

魔改 Github 官方开源的 Jekyll 主题，更新了下我的个人主页～
不得不说 Github 团队的设计真的一直很棒！

🔗 nekocode

❤️ 5🔁 0💬 0

nekocode 是谁？

Sat, 13 Apr 2019 00:00:00 +0000

👁 1,109❤️ 37👀 3🔁 4💬 22

Hello! 我是「nekocode」，是一名 IT 工程师，目前在国内当 Freelancer[1]。欢迎阅读我的公众号。

ID

「nekocode」是我的网络 ID。neko 取自日文「ねこ」的罗马拼音，是「猫」的意思，code 则是英文意义上「代码」的意思。这是我在广州读大学、最中二[2] 的时候起的 ID，一直沿用至今。

我很喜欢猫。在读大学的时候室友养过两只猫，我在北京工作时也自己养过一只蓝猫。我觉得猫很契合「Geek[3]」的气质——能对外界充满好奇心，也能专注自己的世界。

Title 和自我介绍

GitHub[4] 用户 Star 榜世界排名 721，Java 语言世界排名 200，Kotlin 语言世界排名 19（数据采集于 2019/04/13 日）。曾在两家小型创业公司担当 Android Tech Lead，前知乎[5] 最年轻 Android 架构师。

我比较擅长 Android 领域的软件开发，但是也会一些其他领域的技术，例如 Web 前后端、DevOps，我甚至写过弹幕游戏和 2D 游戏引擎。我一直把「Full-Stack Developer[6]」作为我的目标，因为这个世界需要跨领域的工作者。

开公众号的目的

过去，我在很多信息、社交平台上都输出过一些专业性的内容，而决定成为 Freelancer 后我希望能多输出一些面向大众的、更有趣的其他东西。我很喜欢微信团队「克制」的产品思想，所以决定了开公众号。

当然，这是一个个人主义的公众号。我的角度、思想、言论都仅代表我个人，如果内容让你感到不适的话请务必开喷（我还怕没人来喷呢哈哈～）。

References

[1] Freelancer，自由工作者: https://zh.wikipedia.org/wiki/freelancer [2] 中二，中二病的简称，青春幻想症: https://zh.wikipedia.org/wiki/ 中二病 [3] Geek: https://zh.wikipedia.org/wiki/geek [4] GitHub，世界最大源代码托管服务网站: https://github.com [5] 知乎，国内最大问答网站: https://www.zhihu.com [6] Full-Stack Developer，全栈开发者: https://www.thinkful.com/blog/what-is-a-full-stack-developer-2

在知乎的 2018 年

Mon, 31 Dec 2018 00:00:00 +0000

今年是在知乎的第二年。

首先得提及下我的前 Leader 佳恒（目前已去美国），他是个十分 Nice 的人，也是知乎里对我帮助最大的人。今年夏季，他把我从业务组调到了他 Lead 的「Android 基础架构组」，这个组属于中台部门，主要负责提升工程师团队的开发效率、质量，国外有个很火的词「DevOps」指的就是这个方向～

实际上，在知乎里做 DevOps 十分具有挑战性。庞大的开发人员数量和 Codebase 规模都让开发效率和质量的保障变得很困难。而且作为一个有着上亿用户、千万级 DAU 的产品，开发时看似很小的问题一旦到了线上都可能会被放大而导致公司损失惨重 w(ﾟДﾟ)w。所以非常需要中台提供流程、工具、自动化来解决这些问题。

接下来，就记录一下我在这个组里做过的一些有意义或有趣的事～

Maven 仓库

随着组件化的推行，Android 组变得严重依赖于 Maven 仓库。虽然公司内部已经搭建了一个 JFrog 仓库，但是由于管理权限不在我们组，想自定义或遇到问题想解决时都十分困难，所以我们组计划自己搭建一个 Maven 仓库。

由于当时组里只有我有过搭建 Maven 的经验，所以这个任务自然而然就落到了我的手上ㄟ( ▔, ▔ )ㄏ。于是用 Docker，配合公司内网 Dns、Nginx-proxy 快速搭了个 Nexus 仓库服务，并且代理了所有用到的第三方的远程仓库，然后把我们 Gradle 工程的 Maven 源依赖都收缩到我们自己搭建的仓库上，这样就能很方便地集中管理我们的 Maven 源和所有 Artifact 了。

JarFilter

这其实是我的个人开源项目但目前已经用在了知乎上，想更详细了解的话可以看这篇文章。

简单来讲，这个 Gradle 插件可以在编译时把指定 Jar 里的指定 Class 文件剔除掉。这么做主要为了能快速修改某个第三方库里类的实现：

无需 Fork 或 Clone 第三方库的所有源码，只需复制目标类的源码到主工程（通常在 IDE 中可以直接从 Sources.jar 中复制），然后用该插件剔除掉原 Jar 中的 Class 然后一起编译即可。

知乎 · 2018 下半年

Wed, 26 Dec 2018 00:00:00 +0000

文章2018-12-26

Kotlin 101

Kotlin 简介

2011 年，作为全球最先进 IDE 开发商之一的 JetBrains 揭露了一项正处于开发中的编程语言 —— Kotlin。它是一门跑在 JVM 上，和 Java 间具有高互操作性的全新语言。JetBrains 通过多年来和各种编程语言打交道的经验，为 Kotlin 整合了多项现代编程语言特性。

2017 年，Google 在 I/O 大会上宣布将 Kotlin 作为 Android 开发的官方支持语言。彼时，Kotlin 的开发者社区开始了爆炸性的增长，而 Netflix、Pinterest、Trello、Kickstarter 等知名公司也早已开始使用 Kotlin。

2018 年，目前 Kotlin 1.3 正式版本已经发布，更多的语言特性得到了支持。而随着官方提供了更多的编译后端，也让 Kotlin 摆脱了 JVM 的束缚，使用 Kotlin 编写的代码可以编译成机器码甚至 JavaScript 而跑在不同的运行环境中。另外，根据 Google 官方的调查，目前已有 40% 的 Android 开发者选择使用 Kotlin 进行编程工作，国内抖音、网易有道词典、大众点评、知乎等大量应用也开始引入 Kotlin。

使用 Kotlin 有什么好处？

既然 Google 已经宣布 Kotlin 成为 Android 开发的官方支持语言，也说明了至少在 Android 开发上使用 Kotlin 目前已经毫无障碍了。那么作为 Android 开发者，对比 Java 而言，使用 Kotlin 语言能获得什么好处呢？

Kotlin 101

Sun, 16 Dec 2018 00:00:00 +0000

Kotlin 简介

使用 Kotlin 有什么好处？

被滥用的 GUI 设计模式

Sun, 02 Dec 2018 00:00:00 +0000

随便侃些个人对 GUI 设计模式的看法。

近些年来，随着 Fronted 技术的火热和推进，古老的（至少有几十年历史）用来解决 GUI 应用中代码组织问题的「GUI 设计模式」现在也成为了 Frontend 工程师的热门话题，MVC、MVP、MVVM 等设计模式在网路上被议论不绝。有很多工程师开始通过写博文来介绍它们、阐述自己对它们的理解，甚至在 Github 上开源了各种 GUI 设计模式的实现。

顺着这种趋势，很多 Frontend 工程师甚至把 GUI 设计模式当成一种「规范」乃至「教条」。然而糟糕的现实是，大多数人并没有正确地、细致地理解和运用 GUI 设计模式，反而因为 Tradeoff 导致它的缺点被放大。结果就是你用了大量精力、模板代码去设计它，反而让它更复杂、更难维护了。

例如，当你打开 Github 上大多数试图实现 GUI 模式的仓库时会发现，整个应用大概也就两三个页面、四五个网络接口，就可能已经创建了几十个类和接口来承载那单薄的逻辑了。举个更具体的例子，我个人曾经接触过几个用 MVP 模式设计的大型 Android 工程，在进行维护或者迭代的时候，各种带有问题的设计反而让 MVP 模式成为了累赘。

首先，工程中大多数 View 都是粒度大耦合度高的 Activity 类，而且很多 View 里为了方便，会提供 fun updateView(user: UserModel) 这样的方法，导致 View 和领域/业务模型直接耦合了。再者，View 和 Model 中还会包含了跳转页面、发送全局消息等各种带有「副作用」的命令，这也让面向接口编程成为了形式主义。

所以与其「舍本逐末」、「知其然而不知其所以然」，倒还不如理解问题的本质。于 GUI 设计模式而言，实际上最重要的思想是「分而治之」，通过把之前都写在一处的代码按照职能分到不同的类，来让它们实现「低耦合高内聚」。所以，我们更应该把 GUI 设计模式当成一思想而不是具体的手段，更也没必要用各种所谓的模板来解决问题，只要你能把热点、关键代码设计得足够低耦合高内聚，那么你完全可以无视所有 GUI 设计模式。

例如上面提到的 fun updateView(user: UserModel) 问题，实际有两种方式来让 View 和业务模型 UserModel 解耦：

// 方法一
interface ViewA {
    fun updateText1(text: String)
    fun updateText2(text: String)
    // ...
}
class PresenterA {
    fun onSomeEvent() {
        val userModel = Apis.requestUser()
        viewA.updateText1(userModel.name)
        viewA.updateText2(userModel.age.toString())
    }
}

// 方法二
interface ViewA {
    data class ViewAttributes(
        text1: String,
        text2: String,
        // ...
    )
    fun updateView(view: ViewAttributes)
}
class PresenterA {
    fun onSomeEvent() {
        val viewAttributes = Apis.requestUser().mapTo ViewAttributes()
        viewA.updateView(viewAttributes)
    }
}

方法一更倾向于用「指令」来描述 View，方法二则更倾向于用「数据」。而我个人更喜欢方法二，因为数据是运行时可处理、可持久化的，甚至可以跨进程、跨语言、乃至跨机器共享的。讲个题外话，Web Fronted 里 Redux 等状态管理工具捧起了一个很火的词「时间旅行」。在我看来核心思想其实也是把指令下沉，用数据（/状态）来描述上层逻辑，这样就可以在运行时实现逻辑可记录、可回放。

GraphQL 纪要（二）

Sat, 20 Oct 2018 00:00:00 +0000

Resolver 设计

我们可能会在 Resolver 里做一些耗时的操作（例如操作 Database）。为了保证我们尽可能快地响应用户的查询，我们必须保证只对那些用户需要的字段进行查询。

首先举个反例，我们定义了以下的 Schema：

type Query {
  getPost: Post
}

type Post {
  title: String
  authorName: String
}

对应的 Resolver Map：

export const resolverMap: IResolvers = {
  Query: {
    getPost: {
      resolve: () => {
        const post = queryPostDbTable();
        const author = queryUserDbTable(post.authorId);
        return {
          title: post.title,
          authorName: author.name;,
        };
      },
    },
  },
};

可以看到，在 getPost 字段的 Resolver 里会查询 Post 和 User 表。糟糕的是，即便用户并没有查询 authorName 字段，在获取 getPost 字段的时候也会查询 User 表。这造成了冗余的数据库操作。

为了解决这个问题，我们应当把 authorName 字段的获取放到另一个 Resolver 里。例如：

export const resolverMap: IResolvers = {
  Query: {
    getPost: {
      resolve: () => {
        return queryPostDbTable();
      },
    },
  },
  Post: {
    authorName: {
      resolve: (post) => {
        return queryUserDbTable(post.authorId).name;
      },
    },
  },
};

这样可以只在用户查询到 authorName 字段时才去查询 User 表。

GraphQL 纪要

Fri, 19 Oct 2018 00:00:00 +0000

Schema & GraphQL 语句

GraphQL 是一门查询语言，使用它可以描述你需要哪些数据。而 Schema 则是用于声明你能够查询什么样的数据。

举个例子，下面的是 Schema：

type Query {
  hello: String
}

通过以上 Schema 的声明，你可以写下这么一条 GraphQL 查询语句：

query {
  hello
}

Schema

Schema 里主要有两个核心的概念，类型（Type）和字段（Field）。举个例子：

type User {
  name: String
}

上面定义了一个名为 User 的类型，并且这个类型里包含了一个叫做 name 的字段。注意，字段必须声明类型，可以声明为 Int、String 这类基础类型，也可以声明为自定义的类型。另外，字段是可以包含参数的，这让它看起来有点像函数：

type User {
  name: String
  posts(count: Int): [Post]
}

type Post {
  title: String
}

例如这里 User 类型里的 posts 字段，它接受一个名为 count 的参数并返回一个 Post 类型的列表。

Schema 里的 Query 和 Mutation 类型

在 Schema 里面有两个约定的类型：

Docker, Serverless, GraphQL

Mon, 10 Sep 2018 00:00:00 +0000

最近被 Backend、DevOps 的一些新概念震撼到了。

Docker

Docker 应该是目前 DevOps 界最火的工具了。

早在前几年，我就开始使用 Docker 了。通过 Docker 为公司搭建 Maven 和 Jenkins 服务，然后构建用于编译 Android 项目的 Docker Image 提供给 Jenkins 使用。

对于曾经尝试过 Deployment 地狱的人，Docker 的便捷让我对它的印象十分好。

而今年，借助 Docker Compose，我更在我的服务器上成功用几句命令就搭建了一系列工具。仅仅是写写 YAML 配置，就可以快速轻松地部署到任意服务器上，这得有多爽。甚至还包括以下一些自动化的事情：

通过 jwilder/nginx-proxy 自动为其它 Docker 容器配置 Nginx 代理；
通过 jrcs/letsencrypt-nginx-proxy-companion 自动创建 Let’s Encrypt 证书并配置，轻松支持 Https。

如果是在远古时代，对一个非专业 DevOps 工程师而言，即使不考虑系统和软件之间的兼容问题，要手动完成上述的所有部署操作也是十分麻烦的。要是遇到要把所有服务迁移或复制到其他机器上这种事情，估计得抓狂。

来看看我的 Docker Compose YAML 吧：

Nginx-Proxy:
  image: daocloud.io/daocloud/nginx-proxy:latest
  privileged: false
  restart: always
  ports:
    - 80:80
    - 443:443
  volumes:
    - /root/nginx-proxy/certs:/etc/nginx/certs:ro
    - /root/nginx-proxy/vhost:/etc/nginx/vhost.d
    - /root/nginx-proxy/html:/usr/share/nginx/html
    - /var/run/docker.sock:/tmp/docker.sock:ro
  labels:
    com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: 'true'
LetsEncrypt:
  image: jrcs/letsencrypt-nginx-proxy-companion
  restart: always
  volumes:
    - /root/nginx-proxy/certs:/etc/nginx/certs:rw
    - /root/nginx-proxy/vhost:/etc/nginx/vhost.d
    - /root/nginx-proxy/html:/usr/share/nginx/html
    - /var/run/docker.sock:/var/run/docker.sock:ro
Gitlab:
  image: gitlab/gitlab-ce:11.2.1-ce.0
  privileged: false
  restart: always
  ports:
    - 80
    - 443
    - 22
  volumes:
    - /root/gitlab/config:/etc/gitlab
    - /root/gitlab/logs:/var/log/gitlab
    - /root/gitlab/data:/var/opt/gitlab
  environment:
    VIRTUAL_HOST: git.nekocode.cn
    LETSENCRYPT_HOST: git.nekocode.cn
    LETSENCRYPT_EMAIL: nekocode.cn@gmail.com
    GITLAB_OMNIBUS_CONFIG: |
      gitlab_rails['smtp_enable'] = true
      gitlab_rails['smtp_address'] = "smtpdm.aliyun.com"
      gitlab_rails['smtp_port'] = 465
      gitlab_rails['smtp_user_name'] = "git@nekocode.cn"
      gitlab_rails['smtp_password'] = "xxxxxx"
      gitlab_rails['smtp_domain'] = "smtpdm.aliyun.com"
      gitlab_rails['smtp_authentication'] = "login"
      gitlab_rails['smtp_enable_starttls_auto'] = true
      gitlab_rails['smtp_tls'] = true
      gitlab_rails['gitlab_email_enabled'] = true
      gitlab_rails['gitlab_email_from'] = 'git@nekocode.cn'
      gitlab_rails['gitlab_email_display_name'] = 'noreply@nekocode.cn'
Gitlab-Runner:
  image: gitlab/gitlab-runner:latest
  container_name: gitlab-runner
  restart: always
  volumes:
    - /root/gitlab-runner/confg:/etc/gitlab-runner
    - /var/run/docker.sock:/var/run/docker.sock
Wiki:
  image: blacklabelops/confluence
  privileged: false
  restart: always
  ports:
    - 8090
    - 8091
  environment:
    VIRTUAL_HOST: wiki.nekocode.cn
    VIRTUAL_PORT: 8090
    CONFLUENCE_PROXY_NAME: wiki.nekocode.cn
    CONFLUENCE_PROXY_PORT: 443
    CONFLUENCE_PROXY_SCHEME: https
    LETSENCRYPT_HOST: wiki.nekocode.cn
    LETSENCRYPT_EMAIL: nekocode.cn@gmail.com
PostgresDB:
  image: blacklabelops/postgres
  restart: always
  ports:
    - 5432:5432
  environment:
    POSTGRES_DB: postgresdb
    POSTGRES_USER: admin
    POSTGRES_PASSWORD: admin123
    POSTGRES_ENCODING: UTF8

感谢 Docker 和社区的发展，让快速轻松地部署软件成为可能。所以请不要再去手工部署或写兼容性差的 Deploy 脚本了。你需要拥抱 Docker / 容器技术。

知乎 · 2018 上半年

Thu, 24 May 2018 00:00:00 +0000

想法2018-05-24

石头门 0 更了，爽爽爽

❤️ 0🔁 0💬 0

想法2018-05-07

这可以算得上是我写的第一个完整的 Web 页面（源码在页面最底端有链接）。脚本这东西写起来就是比编译型语言爽，容易上瘾。

🔗 Gallery

❤️ 7🔁 0💬 0

想法2018-04-29

今天学到了一个新词「Steampunk」，才发觉宫崎骏也是蒸汽科技的幻想家啊。

❤️ 2🔁 0💬 0

回答2018-04-12

Vue真的比React上手简单吗?

非专业前端工程师，发表些业余看法：

Vue 是传统的在 Html 里写 Js，而 React 则是在 Js 里写 Html。（题外话：作为一个 Android 工程师，感觉这有点像 Databinding 和 Anko 之间的差异）

Vue 的好处是非侵入，不需要重构，在原有的 Html 和 Js 基础上改就行了。React 的话则更可能需要大面积重构整个项目。

论上手简单的话，对于前端工程师应该 Vue 确实会更容易一些吧？毕竟思维上不需要做什么转变。但是对于零基础的人，感觉其实差不多，个人喜欢 React 多些。

❤️ 11💬 4

想法2018-04-11

上 Twitter 逛了下才发现 Github 十周年！

「二零一七年」的总结

Thu, 15 Feb 2018 00:00:00 +0000

为什么二月十五才写去年的总结？一，懒；二，正处农历大年三十，可以诡辩地说二零一七在农历上仍未完结。

二零一七，于我而言是十分重要的一年。

一五、一六年我跟着几个刚毕业的朋友一起创业，从获得千万级风投，到最终资金链断裂，总算结束了我个人的所谓「大学生创业」之路。而一七年初，我入职了知乎。这是一家已经连续创业七年多的公司，而我一直是知乎的重度用户。

把之前创业的经历，和在知乎这一年的经历联系在一起，让我感触十分大。我个人的观点是，「大学生创业」、「九零、零零后创业」等，这些只是资本包装起来的词汇。风口上的标签、媒体口味的变化、可观的投资回报率让很多投资者突然对这块市场虎视眈眈。能够在一个早期创业团队上买入股份，然后对团队进行包装和宣传，就有可能再融个几轮卖出个好价钱了。这种已成套路的投资，让大学生创业市场近几年变得熙熙攘攘。

但是，缺乏从业经验、市场眼光、风险控制能力、精英化管理能力的大学生团队，不管是在创业的哪一个环节上遭遇到了问题，都可能会是对团队的致命一击。如果我是投资家，我是万万不敢重仓大学生创业团队的，因为在我看来，目前以及未来仍旧是「精英创业」的时代。而那些投资大学生团队的人，他们肯扔钱其实主要出于三个原因：一，容易用很低的价格买入大量的股份，因为大多数大学生团队在面对资本的时候，根本没有任何谈资。二、大学生团队运营成本极低，只要不乱烧钱，想要活久一些太容易了。三，前面就说过了，媒体的口味决定了大学生团队更容易被包装起来，这个其实主要看 CEO，可以参考「余佳文」这类典例（但我个人并不喜欢被这类人 Lead）。

而一七年，我能明显感觉到媒体的口味开始再度产生变化，之前一向喜欢鼓吹大学生创业的媒体开始倒戈相向，反而频频开始对大学生创业项目发起质疑、反讽。这让我学习到了三件事：一，资本市场都是贪婪、黑暗的。二，媒体的能力变得日益可怕，创造错误的信息差也能挣钱。三，风口是会改变的（或者说具有周期性），虽然跟着泡沫涨能吃上猪肉，但你得预测到它什么时候会爆。

写到这顺带把一五、一六年的一些看法也总结了。接下来说回二零一七这一年。

我前面说到了，入职知乎的这一年于我而言十分重要。一来是遇到了很多职场精英，颠覆了我很多过往的看法。他们中有极具有 Geek 精神的工程师、年投资回报过百万的工程师、极具逻辑能力的 Leader。在这个平台上，其实能明显感觉到，相对于很多其他人，自己能力还十分不足，但值得庆幸的是自己的职业生涯还早，并且自己能明显意识到自己的一些问题所在。我本身算是个 Workaholic，希望之后方向正确的话，勤能补拙。

二来是由于「实际收入 / 工作时间」比的提高，让我有更多精力去学习、探讨一些技术以外的东西，譬如投资。相对于之前泡沫化的收入，其实到手的收入对于一个风险承担能力弱的穷人而言更踏实。创业的话，干个几年活，最终期权变废纸的概率太大了。当然我不是抵抗创业，我骨子里是喜欢创业的，而且我也崇拜硅谷创业精神。但所谓厚积薄发，我认为目前并不是 Allin 创业的时机，因为我根本没有多少资本去支撑高风险的持续创业（这里的资本包括经验、眼界、资金等）。不过我相信，未来我应该会重新投入其中。当然，目前在知乎也是一种创业，但我想做的其它事还多着。

技术相关的事在这个博客上不想费太多笔墨，简单总结下：大多数达到了我对二零一七的心里预期，稍微提高了自己在社区的影响力（我在 Github 社区的一些成就可以在这里查看）。希望二零一八可以持续提高自己的能力和影响力，并且能在一些其它的领域（新技术、Web）获得新的成就。

接下来我想讲下「投资」。

很多人喜欢把它称作「理财」，这其实是每个人都会接触到的事情，即使是你把钱全部放在银行里，你也是在做一项投资，只不过你是把钱投给了风险和投资回报率都相对较低的银行（银行也会拿你的钱去投资其它产品、或借贷出去来获得利润）。在二零一七的下半年，我开始大量接触了投资相关的知识，一来是市场突然一片大好，以及投资热潮的突然刮起（这其实是个相当危险的讯号），二来是我创业的时候做的是新三板相关的内容，耳濡目染也开始对金融行业产生兴趣。

比较狗血的是，我入场的时机几乎是最差的。二零一八初，我投资了些数字货币，没想到不到半个月比特币的价格就腰斩了。而最近美股市场也一片哀嚎，可以看出经济可能要到周期的拐点了，也就是泡沫要爆了。而我恰好在最高点入场了，。。。

经历被割韭菜的洗礼后，上个月，我在知乎想法上发表了一些对数字货币的看法，现在可以在这里再补充一些。首先，大部分经济学家都认为数字货币是泡沫，而股神巴菲特也不看好，并坦言很乐意买入五年期的加密货币看空期权。为什么是五年期？因为即使是巴菲特也没法准确预言这个泡沫会什么时候爆，但他觉得五年后必然会爆。

但是「天下熙熙皆为利来，天天攘攘皆为利往」，由于人性的贪婪，没人知道这个泡沫会怎么发展，虽然近期腰斩之后目前又开始回升了，但是说实话，我不建议再投钱进去。目前的币市由于缺乏公信机关的监管基本已沦为赌场，而目前能支撑起价格的，大部分还是黑市的需求，和一些尚未对社会产生实际价值的概念。

在这次经历里，我犯的最严重的错误就是简单地认为「看好某样事物」就值得投资，然而这其实只是最基础的一个判断因素。假设市场里有十个人，你是第八个看好某件事物的，那么你可能就已经站在泡沫的顶端了。所以看涨某件事物，首先你得足够早（这其实是个信息差的问题）。其次，你得准确预判它的价值是被低估了，还是已经产生泡沫了。

但这绝非易事。只能不断学习和尝试。最近春节无聊，刚好也沉迷上了玩德州扑克，这其实可以看作是一个微型的投资训练了，取胜需要你有足够的情绪和风险控制能力。其实，很多时候投资和投机 / 赌博是有共通点的，投资也有赚有亏，能稳住牌面最终赢钱离场，那你就是赢家。

二零一七要记录的也就那么多。希望新的一年能有更多新的进步。

知乎 · 2017 下半年

Wed, 13 Dec 2017 00:00:00 +0000

文章2017-12-13

深入简出 RxJava

网络上很多关于 RxJava 的文章都是基于「方法论」的，很少从实现原理的角度去透析。本文希望通过深入简出地描述 RxJava 的一些重要原理，让读者大概知道 RxJava 是如何 Work 的。

核心对象

ReactiveX 是基于观察者模式设计的，核心对象只有 Observable 和 Observer。它们最简单的代码为：

interface Observable {
    void subscribe(Observer observer);
}

interface Observer {
    void onNext(T t);
}

Observable 的核心方法是 subscribe()，它接收一个 Observer。当调用 subscribe() 的时候，就开始通过调用 Observer 的 onNext() 方法发射数据。

上下游

以下代码中:

ob1 = Observable.create(Func1);
ob2 = ob1.map(Func2);
ob3 = ob2.subscribeOn(SchedulerA);

ob1 是 ob2 的上游，ob3 是 ob2 的下游。可以看出，对 Observable 进行一次「操作」后会得到一个新的 Observable。

官方定义：Doubt about the terms Upstream vs Downstream · Issue #5022 · ReactiveX/RxJava

知乎 · 2017 上半年

Fri, 16 Jun 2017 00:00:00 +0000

想法2017-06-16

发现现在某些所谓的「面向小白」的大 V 真是喜欢装逼。例如在某回答里说自己读大学时刷完所有 LeetCode，然后评论中被质问就改口说只刷完 Easy 和 Medium，再后来大概虚心了，直接把这段描述给全删了……

拜托，你能把 Easy 每道不落全刷完我都不太相信好么，有些标着 Easy 的题根本就可以归到 Medium 或 Hard 里去了。

❤️ 24🔁 0💬 25

想法2017-06-07

去年开源了一个项目（当初花了很大心血），结果今天在 Github 上就搜到有国人去掉了版权说明并进行二次开发，真尼玛啊……

❤️ 53🔁 0💬 10

回答2017-05-27

如何评价 Kotlin？未来是否会取代 Java？

Java 是最贴近 JVM 的语言，只要在对性能还有要求的情况下，Java 依旧是 JVM 上的首选。

事实上在对任何语言进行选择时，都是基于对运行效率和开发效率之间的权衡。所以在我看来 Kotlin 是不可能取代 Java 的（官方也从未立意过要取代），但表达能力更强的 Kotlin 在一些地方肯定会比 Java 更适合，例如一些更高层的逻辑。我觉得就会像 Unity3D 引擎用 C/C++ 来写，但是游戏逻辑会选择用 C# 一样。

❤️ 22💬 23

回答2017-05-26

如何评价王垠《聊聊 DSL》？

DSL 的存在是必要的，但是是否应该给予普通人创建 DSL 的捷径确实有待商榷，毕竟不是所有人是领域或语言大师，过多的 DSL 只会造成干扰。

知乎 · 2016 下半年

Sat, 26 Nov 2016 00:00:00 +0000

文章2016-11-26

#Android# 轮子杂评 1

工作中常常会用到一些开源的轮子，但真的是每个都如人气般质量高么？你真的敢用么？该系列文章为你揭开一些高人气轮子的内幕。

android-ripple-background （1000+ Star）

挺多 Star 的。但是首先该动画用 View 来实现就要扣分了，实际上像此类无交互（例如不需要处理 Touch 事件）的纯动画不应该使用 View 作为容器，直接用 Drawable 实现就行了（能避免基类问题）。再仔细看了下代码，妈蛋，直接是个 ViewGroup 然后内嵌几个子 View，通过属性动画来实现的（用的还是使用反射的 ObjectAnimator），差评。

AVLoadingIndicatorView （3000+ Star）

这个动画挺多的所以 Star 数也更多，但同样直接扔了个 View 出来（虽然你也可以用它内部的 Indicator，因为 Indicator 继承的 Drawable）。在 Indicator 里面借助多个 ValueAnimator 来实现数值变化，好处是用起来简单，不需要自己计算动画的中间值，而且可以使用 ArgbEvaluator 和 RectEvaluator 等这类系统提供的插值器。

然而但这并不是 Drawable 推荐实现动画的方法，更正确的做法是使用 scheduleSelf() 方法。可以参考这里 An example showing how to create and use a Drawable that animates. 虽然 ValueAnimator 和 scheduleSelf() 本质上都是通过线程内 Looper 的定时消息实现的，但是 scheduleSelf() 将动画的播放权交给所在的 View，View 可以决定是否播放 Drawable 的动画，而用 ValueAnimator 的话则需自己处理。

知乎 · 2016 上半年

Wed, 22 Jun 2016 00:00:00 +0000

回答2016-06-22

作为一名程序员，最大的成就感来自哪里？

写了个 Game Engine。顺便用自己的 Game Engine 写了一系列的游戏。

是的，为了方便编写游戏脚本，我还拓展了下 notepad++，当做个简易的 IDE 来使用。

引擎里有哪些看起来比较复杂的东西？自己定义了一套脚本（叫做 fscript），写了个简单的脚本解析器。写了个用在立绘切换的 Shader。搞了搞 FreeType。当初写引擎的时候，链表和 hash 表的实现都是自己手写的，那个酸爽~

做了个弹幕游戏。

游戏视频：

UP主自制游戏_实况解说

图形渲染、粒子系统、碰撞检测都是自己写的，还写了个光效叠加的 Shader。当然最屌的还是音频信息可视化，游戏所有对象和状态都和背景音乐有互动。

想想，这都是大二大三时候的事了。如果路子不走野的话，现在大概在做游戏开发或者搞图形、可视化相关的东西吧~ 哎，可惜了 ╮(╯▽╰)╭

❤️ 93💬 27

文章2016-06-10

#Kotlin# 一年の使用报告 - 类型设计

前言

大约有一年的 Kotlin 使用历史，总结下 Kotlin 带来的一些体验。这是该系列文章的第一篇。

正文

昨天，著名 PL 人王垠写了篇文章 Java 有 value type 吗？是的十分有意思，文中假设将 Java 中的原子类型设计为 reference type，你会发现它依然和 value type 表现一致。一个很重要的原因是 Java 中并不具备 C 语言中的 deref 操作符，无法修改 reference 指向中真实的 value，你在对它进行再赋值时，仅仅是改变了它的指向。

知乎 · 2015 下半年

Thu, 31 Dec 2015 00:00:00 +0000

回答2015-12-31

Erlang如何与C++通信？

同问通信和语言有什么关系？你究竟是想问 IPC 呢，还是想问跨语言调用呢？讲清楚了才好答你啊。

❤️ 0💬 0

回答2015-12-22

程序员口中所说的前端和后端是什么?

前端负责和用户交互，后端负责和计算机交互

❤️ 3💬 0

回答2015-12-21

依赖注入框架AndroidAnnotations和ButterKnife真的方便了开发者？

更新一下，看到 @wakao 的答案，槽点有些多，吐槽下：

.var .filed这种写法不是快捷键，这是 Intellij IDEA 的 Postfix Completion Feature，不要混淆了。
Annotation 是 Java 层面的东西啊，怎么叫不像 Android 代码了（别忘了 @Override 也是注解），不太懂。
拿 compile 那点性能损耗上台来讲，也是醉了。
吐槽不能。。

==== 以下为原回答 ====

谢邀。

之前一直是用 JakeWharton/butterknife · GitHub 加上 avast/android-butterknife-zelezny · GitHub ，你确定你手写 findViewById 会比我用 Plugin 一键生成代码更快？：）

使用 ButterKnife，是因为它足够轻。

Field and method binding for Android views which uses annotation processing to generate boilerplate code for you.

推文 · 热度

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

2026-06-06

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

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

👁 5,061❤️ 22🔁 0💬 22

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

👁 4,618❤️ 13🔁 0💬 6

2025-04-09

明天入职！

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

👁 4,431❤️ 7🔁 0💬 2

2025-03-28

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

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

👁 4,367❤️ 14🔁 0💬 3

👁 4,029❤️ 2🔁 1💬 4

👁 3,788❤️ 15🔁 0💬 3

👁 3,661❤️ 17🔁 3💬 7

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

👁 3,570❤️ 17🔁 0💬 8

👁 3,411❤️ 11🔁 4💬 1

👁 3,368❤️ 5🔁 0💬 0

👁 3,327❤️ 11🔁 0💬 6

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

👁 3,188❤️ 7🔁 0💬 6

2025-02-28

👁 3,048❤️ 13🔁 0💬 2

👁 2,987❤️ 6🔁 0💬 0

https://t.co/qv9xO7S07N

👁 2,973❤️ 20🔁 4💬 0

2024-11-26

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

👁 2,953❤️ 10🔁 0💬 17

👁 2,895❤️ 10🔁 0💬 2

👁 2,838❤️ 13🔁 0💬 3

👁 2,819❤️ 10🔁 0💬 1

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

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

👁 2,782❤️ 22🔁 1💬 2

2025-12-29

👁 2,739❤️ 3🔁 2💬 0

2024-12-12

👁 2,733❤️ 14🔁 0💬 4

2025-03-02

总算提到新玩具了🤣

👁 2,718❤️ 15🔁 0💬 2

👁 2,587❤️ 7🔁 2💬 0

👁 2,578❤️ 11🔁 0💬 2

👁 2,486❤️ 7🔁 0💬 1

👁 2,432❤️ 6🔁 0💬 6

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

👁 2,399❤️ 23🔁 0💬 5

2025-02-26

👁 2,347❤️ 6🔁 0💬 3

2025-03-29

👁 2,343❤️ 1🔁 0💬 0

推文 · 热度

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

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

👁 2,309❤️ 5🔁 0💬 0

2025-02-14

👁 2,179❤️ 11🔁 1💬 0

2025-08-27

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

👁 2,032❤️ 8🔁 0💬 1

非常强大！

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

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

👁 2,030❤️ 23🔁 0💬 4

👁 2,029❤️ 20🔁 0💬 2

👁 2,027❤️ 6🔁 0💬 5

👁 1,998❤️ 12🔁 2💬 6

一个有趣的建议：

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

举个例子：

👁 1,919❤️ 7🔁 1💬 4

2025-08-26

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

👁 1,900❤️ 7🔁 0💬 4

2025-03-18

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

👁 1,894❤️ 1🔁 0💬 1

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

fixing 😭

👁 1,775❤️ 2🔁 0💬 1

2025-02-12

这个市场里太多赌徒了。

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

👁 1,759❤️ 8🔁 0💬 5

😆 笑死，确实是相互糊弄

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

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

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

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

👁 1,707❤️ 2🔁 0💬 0

2025-07-10

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

👁 1,677❤️ 2🔁 0💬 3

👁 1,670❤️ 7🔁 0💬 0

👁 1,653❤️ 8🔁 0💬 2

👁 1,616❤️ 7🔁 0💬 1

已修复所有数据😮‍💨

👁 1,593❤️ 2🔁 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,544❤️ 16🔁 0💬 1

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

👁 1,513❤️ 9🔁 0💬 1

2024-12-24

交易起来 💸💸💸

👁 1,490❤️ 4🔁 0💬 1

2024-11-20

👁 1,473❤️ 11🔁 0💬 2

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

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

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

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

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

👁 1,470❤️ 5🔁 0💬 0

2026-05-24

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

👁 1,438❤️ 8🔁 1💬 2

2025-07-07

述职完了，松了口气。

饭碗应该是稳住了哈哈😆

👁 1,436❤️ 1🔁 0💬 2

推文 · 热度

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

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

👁 1,407❤️ 5🔁 0💬 0

2026-04-13

👁 1,324❤️ 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,219❤️ 1🔁 0💬 1

👁 1,213❤️ 2🔁 0💬 3

👁 1,191❤️ 9🔁 0💬 3

👁 1,143❤️ 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,092❤️ 6🔁 2💬 1

👁 1,092❤️ 6🔁 0💬 0

👁 1,084❤️ 1🔁 0💬 0

👁 1,070❤️ 0🔁 0💬 2

👁 1,065❤️ 3🔁 0💬 3

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

👁 1,055❤️ 2🔁 0💬 1

👁 1,014❤️ 2🔁 0💬 0

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

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

👁 997❤️ 3🔁 0💬 1

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

👁 988❤️ 3🔁 1💬 0

2026-01-03

👁 987❤️ 2🔁 0💬 1

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

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

👁 982❤️ 4🔁 0💬 0

2025-08-30

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

👁 963❤️ 4🔁 0💬 0

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

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

👁 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 来触发。

👁 927❤️ 0🔁 0💬 1

2026-02-14

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

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

git commit

Review & 修改 MD 文件

/clear

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

👁 908❤️ 6🔁 0💬 1

2024-10-23

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

👁 883❤️ 2🔁 0💬 1

👁 853❤️ 5🔁 1💬 0

2026-01-18

👁 845❤️ 6🔁 0💬 0

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

👁 837❤️ 2🔁 0💬 1

推文 · 热度

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

👁 825❤️ 4🔁 0💬 1

👁 822❤️ 6🔁 0💬 1

👁 809❤️ 7🔁 0💬 0

👁 804❤️ 4🔁 0💬 2

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

👁 800❤️ 3🔁 0💬 1

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

比真的赚到钱还要高兴。

👁 793❤️ 6🔁 0💬 0

2024-11-10

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

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

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

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

👁 790❤️ 4🔁 1💬 0

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

👁 766❤️ 4🔁 0💬 1

2026-04-21

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

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

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

👁 764❤️ 4🔁 0💬 0

👁 741❤️ 2🔁 0💬 1

2024-07-01

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

👁 741❤️ 6🔁 0💬 1

👁 740❤️ 10🔁 0💬 1

👁 727❤️ 3🔁 0💬 0

2024-09-09

https://t.co/n6eZPauIVS

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

👁 722❤️ 3🔁 0💬 0

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

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

👁 716❤️ 4🔁 0💬 0

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

👁 700❤️ 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

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

👁 698❤️ 6🔁 0💬 0

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

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

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

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

👁 697❤️ 2🔁 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

2026-03-29

👁 694❤️ 3🔁 0💬 1

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

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

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

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

👁 687❤️ 2🔁 0💬 0

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

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

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

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

👁 676❤️ 3🔁 0💬 0

2026-05-22

👁 659❤️ 0🔁 0💬 1

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

👁 653❤️ 4🔁 0💬 0

2025-07-15

👁 646❤️ 3🔁 0💬 0

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

👁 643❤️ 3🔁 0💬 0

2024-11-09

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

👁 640❤️ 4🔁 0💬 3

2026-01-06

👁 635❤️ 5🔁 0💬 0

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

👁 630❤️ 5🔁 0💬 0

推文 · 热度

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

为什么我要说 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 简直行云流水，身心愉悦。

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

👁 626❤️ 0🔁 0💬 2

2026-03-25

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

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

对我来说简直太完美了！

👁 601❤️ 0🔁 0💬 0

2026-02-26

👁 601❤️ 4🔁 0💬 0

👁 596❤️ 5🔁 0💬 0

2026-01-17

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

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

👁 565❤️ 0🔁 0💬 0

2026-04-16

今天听到个搞笑的梗：

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

👁 564❤️ 8🔁 0💬 0

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

https://t.co/ZwEWNrn8dA

👁 551❤️ 1🔁 0💬 0

2026-04-17

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

👁 550❤️ 3🔁 0💬 0

2026-03-22

👁 550❤️ 1🔁 1💬 0

2026-03-07

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

👁 542❤️ 4🔁 0💬 2

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

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

👁 530❤️ 1🔁 0💬 0

2026-04-09

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

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

👁 528❤️ 2🔁 0💬 0

2025-08-14

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

👁 527❤️ 2🔁 0💬 0

👁 522❤️ 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 具备可验证、可复现、可审计能力的关键一环。

👁 518❤️ 5🔁 0💬 0

2025-09-12

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

👁 515❤️ 0🔁 0💬 0

👁 515❤️ 4🔁 0💬 2

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

👁 513❤️ 1🔁 0💬 0

2026-04-06

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

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

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

👁 507❤️ 3🔁 0💬 0

2026-02-08

来自 PayloadCMS CTO 的认可🌟

https://t.co/bkLlDtCYwh

👁 495❤️ 6🔁 0💬 0

2026-04-04

👁 489❤️ 4🔁 0💬 0

2026-03-02

👁 489❤️ 6🔁 0💬 1

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

👁 488❤️ 1🔁 0💬 1

状态是万恶之源！🤡

👁 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

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

👁 473❤️ 2🔁 0💬 3

2026-02-27

👁 461❤️ 9🔁 0💬 0

👁 458❤️ 2🔁 0💬 0

2025-09-09

👁 454❤️ 0🔁 0💬 0

推文 · 热度

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

2026-01-30

👁 442❤️ 7🔁 0💬 0

2026-01-16

lcomplete @xlcomplete
有趣，太有趣了。

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

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

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

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

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

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

👁 441❤️ 5🔁 0💬 0

2026-01-07

👁 439❤️ 3🔁 0💬 0

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

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

👁 436❤️ 2🔁 0💬 1

👁 410❤️ 4🔁 0💬 0

👁 390❤️ 4🔁 0💬 0

👁 390❤️ 2🔁 0💬 0

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

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

👁 376❤️ 0🔁 0💬 0

Tip: 多用「ROI」这个词

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

👁 373❤️ 3🔁 0💬 1

👁 373❤️ 5🔁 0💬 0

👁 365❤️ 0🔁 0💬 0

👁 364❤️ 5🔁 0💬 2

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

👁 361❤️ 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 的創新，真的可惜了。

👁 360❤️ 0🔁 0💬 0

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

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

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

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

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

👁 353❤️ 0🔁 0💬 0

2024-06-19

👁 352❤️ 3🔁 0💬 0

2026-01-13

👁 351❤️ 0🔁 0💬 0

2025-12-31

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

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

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

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

👁 349❤️ 1🔁 0💬 0

2024-05-14

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

👁 348❤️ 0🔁 0💬 0

👁 331❤️ 5🔁 0💬 0

👁 329❤️ 1🔁 0💬 1

👁 326❤️ 3🔁 0💬 0

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

👁 324❤️ 1🔁 0💬 1

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

👁 322❤️ 0🔁 0💬 1

👁 315❤️ 2🔁 0💬 1

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

👁 309❤️ 3🔁 0💬 0

2026-02-11

Coding Agent CLI ─► ACP ─► Agent Team CLI

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

👁 302❤️ 1🔁 0💬 0

2026-02-01

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

👁 294❤️ 0🔁 0💬 1

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

👁 288❤️ 1🔁 0💬 0

2026-01-24

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

👁 278❤️ 0🔁 0💬 1

推文 · 热度

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

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

👁 277❤️ 3🔁 0💬 0

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

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

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

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

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

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

👁 275❤️ 0🔁 0💬 0

Hey，来看个好玩的东西 🤣

👁 274❤️ 2🔁 0💬 0

2026-02-09

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

👁 261❤️ 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

2026-01-02

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

👁 220❤️ 1🔁 0💬 0

2026-02-07

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

👁 211❤️ 0🔁 0💬 0

2025-12-25

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

👁 205❤️ 0🔁 0💬 0

2025-12-04

👁 200❤️ 0🔁 0💬 0

2025-12-24

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

👁 196❤️ 2🔁 0💬 0

2024-03-12

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

👁 195❤️ 2🔁 0💬 0

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

👁 194❤️ 0🔁 0💬 0

Opus 4.6 + High Effort

👁 193❤️ 0🔁 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

2026-03-09

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

👁 179❤️ 0🔁 0💬 0

👁 159❤️ 0🔁 0💬 0

👁 158❤️ 0🔁 0💬 0

2026-02-19

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

👁 149❤️ 0🔁 0💬 0

X Screenshot 已上架！

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

https://t.co/VTpiQ8SrTm

👁 134❤️ 0🔁 0💬 0

👁 0❤️ 0🔁 27💬 0

👁 0❤️ 0🔁 61💬 0

2022-07-03

👁 0❤️ 0🔁 0💬 0

推文 · 热度

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

👁 495,678❤️ 986🔁 88💬 81

2025-09-06

👁 205,036❤️ 880🔁 136💬 95

2024-10-28

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

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

👁 185,510❤️ 617🔁 49💬 46

2025-05-05

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

👁 92,152❤️ 200🔁 5💬 18

2026-03-03

👁 68,763❤️ 596🔁 72💬 31

2026-05-30

👁 51,189❤️ 91🔁 3💬 28

👁 47,495❤️ 234🔁 21💬 19

2025-12-28

👁 45,207❤️ 162🔁 14💬 12

👁 37,870❤️ 98🔁 3💬 7

👁 31,392❤️ 106🔁 10💬 13

2026-02-06

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

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

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

👁 27,424❤️ 168🔁 22💬 3

2026-02-13

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

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

git commit

Review & 修改 MD 文件

/clear

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

👁 25,835❤️ 62🔁 5💬 1

👁 24,752❤️ 25🔁 1💬 2

👁 24,675❤️ 138🔁 25💬 13

2026-06-10

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

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

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

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

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

👁 24,567❤️ 54🔁 0💬 32

👁 23,331❤️ 190🔁 25💬 4

👁 23,167❤️ 21🔁 0💬 1

2024-12-29

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

👁 16,735❤️ 73🔁 9💬 6

👁 15,024❤️ 111🔁 14💬 10

2026-01-04

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

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

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

👁 10,316❤️ 38🔁 5💬 5

2025-02-06

👁 9,946❤️ 18🔁 0💬 19

2025-07-09

👁 9,574❤️ 35🔁 0💬 7

2025-03-17

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

👁 8,603❤️ 33🔁 2💬 10

2025-04-08

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

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

👁 8,066❤️ 48🔁 3💬 11

2025-04-01

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

👁 7,682❤️ 17🔁 0💬 3

2025-02-03

噩耗，老板这波归零了😂

👁 7,629❤️ 22🔁 0💬 10

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

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

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

https://t.co/6MADl8tp2u

👁 7,609❤️ 18🔁 1💬 20

2024-11-21

👁 7,186❤️ 16🔁 0💬 1

2024-09-08

👁 6,643❤️ 24🔁 2💬 5