😳退休老人新赛道：公众号自媒体
我爸去年 10 月份退休，本来是打算出去再就业赚点零花钱的，但是因为一直配合公司在忙补交社保的事情，所以也没急着出去。
我爸去年 10 月份退休，本来是打算出去再就业赚点零花钱的，但是因为一直配合公司在忙补交社保的事情，所以也没急着出去。
👁 495,713❤️ 981🔁 86💬 81
热度 · 共 248 条 · 第 1/9 页
后来也不知道跟谁学的，跑去开了个公众号写文章去了。就这么捣鼓了几个月，一开始家里人其实都没当一回事，觉得按他说的能赚钱应该是难，就当消磨时光也好。
谁成想春节这段时间阅读量居然暴增了，最高一天还有上千。要知道在这种小城市，他退休前工资一个月也才五千😅
谁成想春节这段时间阅读量居然暴增了，最高一天还有上千。要知道在这种小城市，他退休前工资一个月也才五千😅
👁 37,870❤️ 98🔁 3💬 7
笑死，我就随手分享点好玩的日常，一堆人跑来质疑，甚至恶言诋毁。
无非就是看到别人赚钱就酸，说实话这些人在我看来真是傻逼 & loser。我其实在评论区公布过号名，也有不少人跑去看过证实过了，只是我后来考虑到怕有什么不必要的、未知的麻烦所以删掉了，毕竟不是我自己的号。
这样，如果还有觉得我铁定是骗人的，私下联系我，我私底下给你证实哈。要是证实是真的话你在推啥自骂 10 句自己是傻逼和 loser 就好🙂
无非就是看到别人赚钱就酸，说实话这些人在我看来真是傻逼 & loser。我其实在评论区公布过号名，也有不少人跑去看过证实过了，只是我后来考虑到怕有什么不必要的、未知的麻烦所以删掉了，毕竟不是我自己的号。
这样，如果还有觉得我铁定是骗人的，私下联系我，我私底下给你证实哈。要是证实是真的话你在推啥自骂 10 句自己是傻逼和 loser 就好🙂
👁 9,947❤️ 18🔁 0💬 19
今天学会了一个骚操作：
花不到 40 元在万能的某宝找人帮忙，成功把：
- 联通副号：从之前能找到的最低 29 元套餐，改成了 8 元保号套餐
- 移动主号：从 129 元 30G → 99 元 40G+30G
原理其实就是商家帮你投诉运营商，通常收到投诉后运营商才会愿意给你改套餐。
实属是用魔法来打败魔法了🤣
花不到 40 元在万能的某宝找人帮忙，成功把：
- 联通副号：从之前能找到的最低 29 元套餐，改成了 8 元保号套餐
- 移动主号：从 129 元 30G → 99 元 40G+30G
原理其实就是商家帮你投诉运营商，通常收到投诉后运营商才会愿意给你改套餐。
实属是用魔法来打败魔法了🤣
👁 205,061❤️ 879🔁 137💬 95
最近比较震惊的一件八卦：
老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...
老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...
👁 185,510❤️ 617🔁 49💬 46
尴尬，一个五一假期直接把我阿里云服务给干欠费停机了😅一个业余兴趣项目，怎么感觉要做起来了😂
👁 92,154❤️ 200🔁 5💬 18
Vibe Debug 的核心：TDD
千万别陷入反复 Prompt「还是有问题，xxxx」的循环。即便强如 Opus 4.6，我也试过七八轮仍然修不好。
正确的做法是「想办法写测试代码来复现问题，然后通过测试反馈来自主循环修改，直到完全修复」
你把问题描述得再详尽，也不如让 AI 自己插桩、增强可观测性，再通过自动化测试捕获比肉眼更全面的上下文来驱动修复。
更关键的是，这去掉了 Human in the loop。人从逐轮盯盘中解放出来，Debug 变成了全自动流水线。
千万别陷入反复 Prompt「还是有问题，xxxx」的循环。即便强如 Opus 4.6，我也试过七八轮仍然修不好。
正确的做法是「想办法写测试代码来复现问题，然后通过测试反馈来自主循环修改，直到完全修复」
你把问题描述得再详尽，也不如让 AI 自己插桩、增强可观测性，再通过自动化测试捕获比肉眼更全面的上下文来驱动修复。
更关键的是，这去掉了 Human in the loop。人从逐轮盯盘中解放出来，Debug 变成了全自动流水线。
👁 68,803❤️ 593🔁 72💬 31
公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。
我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅
这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。
裁员、失业会是常态。每个打工人都需要警觉起来。
我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅
这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。
裁员、失业会是常态。每个打工人都需要警觉起来。
👁 51,309❤️ 91🔁 3💬 28
为什么我非常建议所有开发者在每一个项目都把 mono-repo/workspace 用起来？
一个很重要的原因是因为它能实现对代码的 project scope 的「完全隔离」。这样你可以把常用的代码抽象 & 隔离到一个单独的 project，实现代码在不同项目的快速复用。
一个很重要的原因是因为它能实现对代码的 project scope 的「完全隔离」。这样你可以把常用的代码抽象 & 隔离到一个单独的 project，实现代码在不同项目的快速复用。
👁 47,496❤️ 234🔁 21💬 19
Anthropic CEO 透露他们 70% 以上的代码都是由 AI 写的。很多人不仅不相信，甚至还对此冷嘲热讽 🤣。但假设这是真的，这其实是一个非常令人震惊的信息，甚至可以理解为一个极其重要的「金丝雀信号」！它表明：
「AI 编程已经接近、甚至已经跨过临界点」。 如果 Anthropic 能做到，那其他科技公司肯定也能逐步做到。未来软件开发的成本结构，可能将发生根本性的改变。
这也是我为什么说程序员们一定要尽快把 Claude Code 这类 Agent 深度使用起来，要强迫自己逐渐把 AI 作为主力生产者，而不单纯是辅助工具。
因为当临界点真正到来时，差距不会线性拉开 —— 它会指数级扩大：
- 深度掌握 AI 协作的工程师，生产力可能是传统方式的数倍甚至数十倍
- 这些人将能承担更复杂的项目、更快的迭代速度、更低的成本
- 而那些仍将 AI 视为「可有可无」的人，将在竞争中迅速被边缘化
「AI 编程已经接近、甚至已经跨过临界点」。 如果 Anthropic 能做到，那其他科技公司肯定也能逐步做到。未来软件开发的成本结构，可能将发生根本性的改变。
这也是我为什么说程序员们一定要尽快把 Claude Code 这类 Agent 深度使用起来，要强迫自己逐渐把 AI 作为主力生产者，而不单纯是辅助工具。
因为当临界点真正到来时，差距不会线性拉开 —— 它会指数级扩大：
- 深度掌握 AI 协作的工程师，生产力可能是传统方式的数倍甚至数十倍
- 这些人将能承担更复杂的项目、更快的迭代速度、更低的成本
- 而那些仍将 AI 视为「可有可无」的人，将在竞争中迅速被边缘化
👁 45,212❤️ 162🔁 14💬 12
为什么说这是「金丝雀信号」？
Anthropic 是最了解 AI 能力边界的公司之一。他们的一举一动、每一个对外释放的信号，都在预示整个行业即将发生的变化。
什么是「临界点」？
当你和 AI 的角色发生互换 —— 不再是「AI 辅助你写代码」，而是「你辅助 AI 完成代码生产」时。
Anthropic 是最了解 AI 能力边界的公司之一。他们的一举一动、每一个对外释放的信号，都在预示整个行业即将发生的变化。
什么是「临界点」？
当你和 AI 的角色发生互换 —— 不再是「AI 辅助你写代码」，而是「你辅助 AI 完成代码生产」时。
👁 2,739❤️ 3🔁 2💬 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 也是首要支持的语言。
至于为什么选择 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,397❤️ 105🔁 10💬 13
Git Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。
这绝对是 Coding Agent 的并发放大器！
现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。
快速 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,442❤️ 168🔁 22💬 3
结合 @waylybaye 老师最近说的 BDD。我有个新玩法，先让 AI 出一份基于 BDD 的测试 Spec，然后我来人工校验、不断和 AI 对话进行完善和补充。
最后再让 AI 根据这份 https://t.co/vEA75SM4Xs 结合 TDD 来迭代就好。这里 TDD 是底线，对我来说测试不是目的，「可测试的代码」通常「更加可维护」才是重点。
最后再让 AI 根据这份 https://t.co/vEA75SM4Xs 结合 TDD 来迭代就好。这里 TDD 是底线，对我来说测试不是目的，「可测试的代码」通常「更加可维护」才是重点。
nekocode @nekocode_cn上下文工程，我常用的一个小技巧:
让 AI 把现状先写到一个 MD 文件里
git commit
Review & 修改 MD 文件
/clear
让 AI 基于 git diff（你对现状的修改意见）去解决问题
👁 25,856❤️ 62🔁 5💬 1
上下文工程，我常用的一个小技巧:
让 AI 把现状先写到一个 MD 文件里
git commit
Review & 修改 MD 文件
/clear
让 AI 基于 git diff（你对现状的修改意见）去解决问题
让 AI 把现状先写到一个 MD 文件里
git commit
Review & 修改 MD 文件
/clear
让 AI 基于 git diff（你对现状的修改意见）去解决问题
👁 24,782❤️ 25🔁 1💬 2
这里的现状可以是某个问题、某个模块的现状。
在某些改动点可能比较多的场景下，先让 AI 提供一个「底座 / 框架」给你去修改，比起你自己自述所有改动要轻松得多。
这里还用上了 git 这个超能力。
在某些改动点可能比较多的场景下，先让 AI 提供一个「底座 / 框架」给你去修改，比起你自己自述所有改动要轻松得多。
这里还用上了 git 这个超能力。
👁 1,071❤️ 0🔁 0💬 2
来看下有哪些人在用 agent-worktree?
地域: 中国 40+、美国 20+、欧洲 15+、印度/东南亚 15+、日韩 5+、中东/拉美各若干
公司: Google + SpaceX + Figma + Adobe + JPMorgan + 阿里 + 美团 + 饿了么 + Bob 翻译作者 + Apache ShardingSphere 贡献者全都在
https://t.co/bkLlDtCYwh
地域: 中国 40+、美国 20+、欧洲 15+、印度/东南亚 15+、日韩 5+、中东/拉美各若干
公司: Google + SpaceX + Figma + Adobe + JPMorgan + 阿里 + 美团 + 饿了么 + Bob 翻译作者 + Apache ShardingSphere 贡献者全都在
https://t.co/bkLlDtCYwh
👁 24,702❤️ 138🔁 25💬 13
一语成谶。早上 1on1 结束，新一轮总算到我头上了，last day 6/12 😅 好啦，可以开始整理简历了
nekocode @nekocode_cn公司这周非常突然地裁了员，我们 team 砍掉了一半左右，留下来的人被分到了其他 team。
我算是侥幸留了下来，但被分到了一个不太 match 的团队。所谓「插班生往往是下一轮的炮灰」，我也说不准自己还能撑多久 😅
这让我想起之前听过的一个说法：「一家公司有多少人，不取决于它需要多少人，而取决于它能养得起多少人。」这个观点挺有意思，也很贴合经济上行期很多公司的行事逻辑。但在如今经济下行的大环境下，我感觉越来越多的公司开始认真思考一个问题，「维持正常运转，最少需要多少人」。
裁员、失业会是常态。每个打工人都需要警觉起来。
👁 24,642❤️ 54🔁 0💬 31
开源了其中一个我自己最常用的 harness 实践。
我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。
本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。
https://t.co/6MADl8tp2u
我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。
本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。
https://t.co/6MADl8tp2u
👁 23,528❤️ 190🔁 25💬 4
非常强大！
如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。
演示视频稍后整理发出。
https://t.co/bkLlDtCYwh
如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。
演示视频稍后整理发出。
https://t.co/bkLlDtCYwh
👁 2,032❤️ 23🔁 0💬 4
介绍下 agent-worktree 的功能：SNAP 模式 ⚡
搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。
用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。
搭配 Claude Code 使用，任务完成、退出 CLI 时自动 merge 回主干。
用过 Conductor 但更喜欢 CLI 的朋友，你应该会很喜欢它。
👁 23,176❤️ 21🔁 0💬 1
https://t.co/0Nb4et8Ay5 这网站我也挺久没维护了，也没做宣传，现在每天稳定有差不多 30 左右的新增用户。这就是被动增长了么😆
👁 16,735❤️ 73🔁 9💬 6
最近听到一个很有趣的词「JIT (Just-In-Time) Context」。
熟悉编译原理的朋友对「JIT」一定不陌生。而在 LLM 领域，JIT Context 代表着一种范式转变：
- 传统方式：固定的 System Prompt + 线性追加的历史对话
- JIT 方式：每轮对话都动态编排输入内容（System Prompt 也不例外）
为什么需要 JIT Context?
因为随着 Context 不断膨胀，真正重要的信息的一定会被不断稀释注意力，每轮对话需真正需要的上下文其实也在不断变化。
而 JIT Context 强调了，不是所有历史都需要保留，而是应该在正确的时间提供正确的信息。它让 Prompt 像代码编译一样「即时生成」，根据当前任务动态筛选、重组上下文，让每一个 Token 都发挥最大价值。
熟悉编译原理的朋友对「JIT」一定不陌生。而在 LLM 领域，JIT Context 代表着一种范式转变：
- 传统方式：固定的 System Prompt + 线性追加的历史对话
- JIT 方式：每轮对话都动态编排输入内容（System Prompt 也不例外）
为什么需要 JIT Context?
因为随着 Context 不断膨胀，真正重要的信息的一定会被不断稀释注意力，每轮对话需真正需要的上下文其实也在不断变化。
而 JIT Context 强调了，不是所有历史都需要保留，而是应该在正确的时间提供正确的信息。它让 Prompt 像代码编译一样「即时生成」，根据当前任务动态筛选、重组上下文，让每一个 Token 都发挥最大价值。
👁 15,037❤️ 111🔁 14💬 10
Spec-Driven Development 就跟 Java 设计模式一样，又长又臭，有点用，但用（/写）得太多是反作用。大多数人掌握不好那个度，容易陷进过度设计的陷阱。
就如我之前提到的 JIT Context。现在优秀的 Context Engineering 都是围绕着「如何构造最有价值的上下文」来设计的，要让每一个 Token 发挥最大的价值。但现在大多数人所谓的 Spec-Driven Development 明显是反模式的，把一堆文档丢给 LLM，大量的「规则」反而会影响 LLM 的注意力和遵循能力。
真正要用好 Spec-Driven Development 的话，一定是要模块化、渐进式的。把需求拆分成多个模块、计划，每一步再单独进行 Spec-Driven。
就如我之前提到的 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,321❤️ 38🔁 5💬 5
不知道怎么回事，网站今天的新增用户又爆增了，到目前为止已经新增一万多个用户了，害我又紧急充了两次钱😅
每隔一段时间就爆发一次，看来口碑还是 ok 的，能持续自然传播🤣
每隔一段时间就爆发一次，看来口碑还是 ok 的，能持续自然传播🤣
👁 9,574❤️ 35🔁 0💬 7
增长总共爆发过三次。昨天是新高😅真成烫手山芋了
👁 1,677❤️ 2🔁 0💬 3
最近几天也不知道怎么回事，https://t.co/0Nb4et8Ay5 每天有上千的新注册用户 😂
👁 8,603❤️ 33🔁 2💬 10
昨天一天最终有 4k 多新用户，这相当于之前一个多月的新用户量了😳
👁 1,894❤️ 1🔁 0💬 1
👁 8,067❤️ 48🔁 3💬 11
来看下有哪些人 star 了 filetree-skill？
地域：中国 40+、美国/北美 10+、欧洲 10+、东南亚 10+、日韩台港若干、中东/拉美/非洲各若干
公司/身份：Rainbow 钱包创始人 + 美团 + 滴滴 + 微博 + 腾讯音乐 + 网易 + BrowserStack + 韩国 KakaoBank + 德国 ginmon + 约翰霍普金斯应用物理实验室 + BrainCo 强脑科技 + 一堆高校（南大/中大/中科院/纽卡斯尔/诺丁汉）+ 新加坡武装部队等等
地域：中国 40+、美国/北美 10+、欧洲 10+、东南亚 10+、日韩台港若干、中东/拉美/非洲各若干
公司/身份：Rainbow 钱包创始人 + 美团 + 滴滴 + 微博 + 腾讯音乐 + 网易 + BrowserStack + 韩国 KakaoBank + 德国 ginmon + 约翰霍普金斯应用物理实验室 + BrainCo 强脑科技 + 一堆高校（南大/中大/中科院/纽卡斯尔/诺丁汉）+ 新加坡武装部队等等
nekocode @nekocode_cn开源了其中一个我自己最常用的 harness 实践。
我习惯在每个项目里维护一份 FILETREE.md：完整文件树 + 每个文件由 AI 生成的一句话描述 + 用于感知变更的 hash。
本质上，这是为项目提前构建了一层文件维度的索引，对 agent 而言，是密度 / 性价比极高的上下文，特别是在中小型项目里，加了这么一段信息，对 agent 快速理解整个项目有非常大的帮助。
https://t.co/6MADl8tp2u
👁 7,749❤️ 18🔁 1💬 20