我试过很多方法，只有 project scope 的隔离是最彻底的而且最通用的，这样能强迫你把通用的代码摘得很干净
👁 2,309❤️ 5🔁 0💬 0
热度 · 共 235 条 · 第 3/8 页
https://t.co/eaLaprcFD9 的数据也是逐渐好起来了，这几天应该马上要突破 2w 用户了😆
但是我已经好久没维护它了。一直想把 aliyun 的服务适配到 aws & cloudflare 再做一个国际版也没空去做😂
其实这个网站有机会发展得更好的。在 emulatorjs 开源之前，全网我们几乎是最早能把 retroarch 模拟器完美跑在 web 上的，那时候几乎找不到能在 web 上玩到各种模拟器游戏的网站。
但是由于精力问题，错过了那段市场空白的时间，等到 emulatorjs 正式开源之后，现在已经一大堆网站支持在 web 上玩模拟器游戏了🤣
但是我已经好久没维护它了。一直想把 aliyun 的服务适配到 aws & cloudflare 再做一个国际版也没空去做😂
其实这个网站有机会发展得更好的。在 emulatorjs 开源之前，全网我们几乎是最早能把 retroarch 模拟器完美跑在 web 上的，那时候几乎找不到能在 web 上玩到各种模拟器游戏的网站。
但是由于精力问题，错过了那段市场空白的时间，等到 emulatorjs 正式开源之后，现在已经一大堆网站支持在 web 上玩模拟器游戏了🤣
👁 2,179❤️ 11🔁 1💬 0
前前同事，从码农转行去做直播带货（幕后）后，一个月能分 10~15 个😳
👁 2,032❤️ 8🔁 0💬 1
非常强大！
如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。
演示视频稍后整理发出。
https://t.co/bkLlDtCYwh
如果你喜欢原汁原味的 Claude Code CLI，这可能是目前和原生 CLI 结合最好的 Worktree 管理工具。
演示视频稍后整理发出。
https://t.co/bkLlDtCYwh
👁 2,030❤️ 23🔁 0💬 4
我的 vibe 日常：
同时开 2 到 3 个 project，然后每个 project 使用 agent-worktree 维护至少一个固定存在的 worktree。并行 vibe，控制时机做好 sync 和 merge。
token roi 直接拉满🤣
https://t.co/bkLlDtCYwh
同时开 2 到 3 个 project，然后每个 project 使用 agent-worktree 维护至少一个固定存在的 worktree。并行 vibe，控制时机做好 sync 和 merge。
token roi 直接拉满🤣
https://t.co/bkLlDtCYwh
👁 2,029❤️ 20🔁 0💬 2
vibe coding / claude code 真有这么神么？有没有极其深度用过、或者在大型 / 复杂项目上用过的小伙伴现身说法一下😅
目前我还是用的 copilot 的形式。我目前还不太相信在有限的上下文内（即使上下文工程做得足够好）让 ai 完全主导开发，能保证在复杂项目上不错过任何一点内部细节🤔代码这东西对准确性的要求很高，稍微哪里出了点问题都会影响整个系统。
当然有很多方法来把控，code review、vibe debugging(👀)。但是这种 chat & review 的 workflow，比起自己写代码 & ai 作为 copilot 小范围补全 / 建议，总感觉很难让人对代码产生信任。所以我想问下实际体验
目前我还是用的 copilot 的形式。我目前还不太相信在有限的上下文内（即使上下文工程做得足够好）让 ai 完全主导开发，能保证在复杂项目上不错过任何一点内部细节🤔代码这东西对准确性的要求很高，稍微哪里出了点问题都会影响整个系统。
当然有很多方法来把控，code review、vibe debugging(👀)。但是这种 chat & review 的 workflow，比起自己写代码 & ai 作为 copilot 小范围补全 / 建议，总感觉很难让人对代码产生信任。所以我想问下实际体验
👁 2,027❤️ 6🔁 0💬 5
谁说 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
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
一个有趣的建议：
一个功能完备、提供开放接口的在线表格，能省掉绝大多数小型产品的后台管理开发成本。
举个例子：
一个功能完备、提供开放接口的在线表格，能省掉绝大多数小型产品的后台管理开发成本。
举个例子：
👁 1,919❤️ 7🔁 1💬 4
为啥大公司里几乎找不到 10x 工程师？🙄
👁 1,900❤️ 7🔁 0💬 4
昨天一天最终有 4k 多新用户，这相当于之前一个多月的新用户量了😳
👁 1,894❤️ 1🔁 0💬 1
一些补充：
1️⃣ 有 X 友好奇我怎么知道的老板的薪资，其实是老板自己告诉我们的
2️⃣ 老板是炒币发家的，自从创业后，据说目前已经烧掉了 8 位数的钱了
3️⃣ 当前情况确实挺艰难，没有收入 + 暂时没拉到新的融资，目前在努力做一些挽救 & 尝试
1️⃣ 有 X 友好奇我怎么知道的老板的薪资，其实是老板自己告诉我们的
2️⃣ 老板是炒币发家的，自从创业后，据说目前已经烧掉了 8 位数的钱了
3️⃣ 当前情况确实挺艰难，没有收入 + 暂时没拉到新的融资，目前在努力做一些挽救 & 尝试
nekocode @nekocode_cn最近比较震惊的一件八卦：
老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k，能 cover 住服务器的费用...
👁 1,862❤️ 10🔁 0💬 3
这个数据 📊 如果纯靠广告的话能带来多少收益 🤔
有懂行的推友么？
有懂行的推友么？
👁 1,812❤️ 3🔁 0💬 0
这两天抽空折腾了下，放弃了 🤪
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 那就美滋滋了。
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
fixing 😭
👁 1,775❤️ 2🔁 0💬 1
这个市场里太多赌徒了。
但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸
但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸
👁 1,759❤️ 8🔁 0💬 5
😆 笑死，确实是相互糊弄
比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子
比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子
plantegg @plantegg有了 AI 之后，飞书文档承受了从来没有过的压力：
1）新文档生成速度直线上升
2）读写比例达到新低，也就是架构估计得重构了
以前大家都知道一般读写比例是 95:5，现在估计接近 50:50 了
这些文档大家也没真的去看，在各个会议上，在 CEO CTO CXO 以及各级工程师之间一视同仁地互相糊弄
👁 1,707❤️ 2🔁 0💬 0
增长总共爆发过三次。昨天是新高😅真成烫手山芋了
👁 1,677❤️ 2🔁 0💬 3
一点心得，harness engineering 的本质是「熵减」。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
👁 1,670❤️ 7🔁 0💬 0
我给我们部门搭建的这套 Web Codebase，我真的太特么喜欢了😆甚至让我有种喜欢上上班的错觉哈哈。
很多最新 / 最佳实践，核心代码有单元测试，Storybook，很多自动化工具，太多太多让我开发起来觉得快乐的地方了😆
很多最新 / 最佳实践，核心代码有单元测试，Storybook，很多自动化工具，太多太多让我开发起来觉得快乐的地方了😆
👁 1,653❤️ 8🔁 0💬 2
本来想维护下 https://t.co/MYHte01pbp 这个项目，把依赖都升级下的。
结果发现 pixi.js 的 7 -> 8 这个升级有太多 breaking changes 了，之前处理 6 -> 7 升级时也是一堆 breaking changes。
说实话，按照这个库当前的接口设计，我感觉后续还会有不少 breaking changes，好多设计依然很别扭。
设计基础库时，api 的设计太考验开发者的编程内功了。一套好的 api 应该做到每次在内部实现有大的改动时，接口只有增量更新，或者只有少量的破坏改动。
结果发现 pixi.js 的 7 -> 8 这个升级有太多 breaking changes 了，之前处理 6 -> 7 升级时也是一堆 breaking changes。
说实话，按照这个库当前的接口设计，我感觉后续还会有不少 breaking changes，好多设计依然很别扭。
设计基础库时，api 的设计太考验开发者的编程内功了。一套好的 api 应该做到每次在内部实现有大的改动时，接口只有增量更新，或者只有少量的破坏改动。
👁 1,616❤️ 7🔁 0💬 1
已修复所有数据😮💨
👁 1,593❤️ 2🔁 0💬 0
让我想起我的一个前同事，在他的个人项目里用到我们内部的某个 token，然后还 push 到 github public repo 幸好最后被我发现的事 😅
我甚至最开始还不知道他的 github id，是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。
我甚至最开始还不知道他的 github id，是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。
Ruifeng @liruifengvvant、@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
「最终，一切取决于品味」
只要涉及到创造的领域其实就离不开艺术和品味，「苹果团队里有音乐家、诗人、艺术家、动物学家、历史学家，同时他们也是顶尖的计算机学家」。在代码工程领域里，不同地区 / 文化、不同性格 / 背景的工程师也许「品味」差距很大。
每一个细微的决策、设计上的差距，在累积到一个新的量级 / 诞生出一个「产品」时，也会产生出翻天覆地的变化。
只要涉及到创造的领域其实就离不开艺术和品味，「苹果团队里有音乐家、诗人、艺术家、动物学家、历史学家，同时他们也是顶尖的计算机学家」。在代码工程领域里，不同地区 / 文化、不同性格 / 背景的工程师也许「品味」差距很大。
每一个细微的决策、设计上的差距，在累积到一个新的量级 / 诞生出一个「产品」时，也会产生出翻天覆地的变化。
👁 1,569❤️ 3🔁 0💬 0
做了个东西：SeqLog — Apple 原生的 Logseq 替代品。
SwiftUI + Rust FFI，没有 Electron，没有 300MB 运行时，没有云。
- 不做数据库（.md 就是真相）
- 不做索引（ripgrep 够快，VS Code 同款引擎）
- 不做云（你自己选 iCloud/Git/Dropbox）
- 不做 Electron（SwiftUI 原生）
SwiftUI + Rust FFI，没有 Electron，没有 300MB 运行时，没有云。
- 不做数据库（.md 就是真相）
- 不做索引（ripgrep 够快，VS Code 同款引擎）
- 不做云（你自己选 iCloud/Git/Dropbox）
- 不做 Electron（SwiftUI 原生）
👁 1,544❤️ 16🔁 0💬 1
看看过去 24 小时里暴跌行情 📉 我们资金曲线的表现 👀
👁 1,513❤️ 9🔁 0💬 1
交易起来 💸💸💸
👁 1,490❤️ 4🔁 0💬 1
希望大家不会用上的技巧之：
💡如何代理某个 docker 容器内所有的网络流量。
背景：
我想让某个跑在国内服务器上的 nestjs 应用支持下 google 登录。应用是跑在容器内的，所以你懂的，得代理下容器内所有与 https://t.co/Ua4slLfG9e 之间的请求。
方法👇：
💡如何代理某个 docker 容器内所有的网络流量。
背景：
我想让某个跑在国内服务器上的 nestjs 应用支持下 google 登录。应用是跑在容器内的，所以你懂的，得代理下容器内所有与 https://t.co/Ua4slLfG9e 之间的请求。
方法👇：
👁 1,473❤️ 11🔁 0💬 2
100% 同意。但是现实是大多数的利益分配者不会愿意多付这 100% 的支出。
贪婪和压榨是资本的天性。
贪婪和压榨是资本的天性。
Yishi @ohyishi聪明的人沟通起来就是爽，你刚说完30%的需求，他就能 get 到120%，多出来的那20%是超额执行，考虑了各种边缘情况和向后兼容，考虑得比你还周全。
不聪明的人，你完整交代100%的需求，他只能做到30%，多不了一点，只管上线，脏活全丢给 qa。然后你被逼着不停拉会，非常疲惫。
不要为了省那20%预算招不聪明的人，应该花200%的钱招聪明的人。
👁 1,470❤️ 5🔁 0💬 0
以我的经验，目前最好用的查询索引是维护一个全局的 FILETREE.md：项目文件树，每个文件一句话描述
less is more。信息量/上下文不是越多越好，信息越多注意力越容易被分散，这里的权衡很重要，也是大多数新手容易犯错的地方。
less is more。信息量/上下文不是越多越好，信息越多注意力越容易被分散，这里的权衡很重要，也是大多数新手容易犯错的地方。
Yufan Sheng @syhily不知道是不是我的使用姿势不正确，推油大吹特吹的 CodeGraph 在我这使用效果相当一般。还不如 Agent 自己去 Grep。
👁 1,438❤️ 8🔁 1💬 2
述职完了，松了口气。
饭碗应该是稳住了哈哈😆
饭碗应该是稳住了哈哈😆
👁 1,436❤️ 1🔁 0💬 2