2026/3/13 分析 · 使用者 #73e618 提供 50 則貼文 (2025-10-28 ~ 2026-03-13)
風險分析
帳號數據
過去約 4.5 個月發布 50 則貼文，平均每月約 11 則，發文頻率中等。44 則原創、6 則轉貼，原創比例極高（88%）。發文時間集中在 UTC 時間上午至下午，無明顯排程痕跡，發文間隔不規律，符合真人隨手發文模式。偶爾出現同日連發多則的情況（如 [5][6][7] 和 [34][35][36] 為系列長文拆分）。
發文時段分佈
時區：UTC
原創 vs 轉貼
互動數據（原創貼文平均）
資料期間: 2025-10-28 ~ 2026-03-13
AI 深度分析
@arvin17x 帳號可信度分析報告
1. 真實性分析
此帳號的真實性極高。帳號持有者明確為 LobeHub 開源專案的創辦人與核心開發者，身分一致性貫穿所有貼文，無偽造專業身分的跡象。
具體證據包括：
- 展現深入且一致的技術知識，涵蓋前端架構（RSC、SSR 同構）[50]、CLI 設計 [7]、TDD 實踐 [41]、Electron 優化 [23] [24] 等多個領域
- 分享真實的開發細節與困境，如 Gemini 3.0 Pro 的
thoughtSignature適配問題 [34] [35] [36]，具備高度技術深度且非公開文件可複製 - 包含個人生活細節，如因高強度寫程式導致手指蛻皮、指紋鎖無法辨識 [15]，這類細節極難偽造
- 對技術選型有具體且帶有個人經驗的觀點，如 ChatItem 設計需拆分 [40]、空狀態設計引導 [25]
- 與其他真實開發者有具名互動 [18] [50]，並可追溯到具體的 GitHub issue [31] 和 PR [45]
2. 原創性分析
原創性非常高。50 則貼文中有 44 則為原創（88%），6 則為轉貼（12%），遠高於一般帳號的原創比例。
內容品質方面：
- 多則貼文為深度技術長文，如 [7] 的 CLI vs API+Curl 完整分析（含三個子議題拆分為 [5] [6]）、[25] 的設計引導方法論
- 技術觀點具有原創性和實戰經驗支撐，如 [6] 提出的「From UX to AX」概念、[40] 關於 ChatItem 拆分的反直覺結論
- [34] [35] [36] 對 Gemini API 行為的深入分析，屬於第一手適配經驗
- 未發現 AI 生成內容的痕跡，文風自然，包含口語化表達（「我勒个去」[1]、「不能同意更多 2333」[8]）和個人情緒
轉貼的 6 則中，[17] [18] 為 LobeHub 官方及團隊成員貼文，[22] [26] 為合作者的設計相關內容，[42] 為創業觀察，[12] 為官方活動推廣，均有合理的轉貼動機。
3. 利益動機分析
此帳號存在明確但大致透明的商業利益。
帳號持有者身為 LobeHub 創辦人，幾乎所有技術分享都圍繞 LobeHub 生態展開，帳號本質上是個人品牌與產品行銷的融合管道：
- 直接推廣行為：[32] 發布促銷碼、[48] 發布 iOS 公測連結、[27] Product Hunt 拉票、[12] 轉貼付費創作者計畫、[13] 新功能上線公告
- 間接推廣行為：許多看似中立的技術分享實際上在展示 LobeHub 的功能優勢。[7] 以「CLI 設計經驗」為題但核心在展示 LobeHub Skills Marketplace 的 CLI。[38] 以「測試 Gemini 3.0 Pro」為題但重點在展示 LobeHub 桌面端的 Local System 插件能力。[30] 借 DeepSeek 發布之機彰顯 LobeHub 的行業地位
- 利益衝突：[1] 指控騰訊抄襲時，作為被抄襲方有天然的立場傾向；[4] [30] 等對 LobeHub 成績的展示缺乏外部驗證
不過需要指出，作為開源專案創辦人在個人帳號推廣自家產品是業界常態，且大部分情況下讀者可以從上下文推斷出利益關係。風險等級為中等而非高，因為身分並未刻意隱藏。
4. 操作手法分析
整體而言，此帳號未使用嚴重的操作手法，但存在一些輕微的傾向性表達：
- 選擇性展示成功：[4]「居然在一個意外的賽道里跑贏了嗎」、[30]「含金量，懂的都懂」、[21] pnpm 構建提速等，傾向於只展示正面結果。不過 [50] 也坦承了 RSC 相關的技術債問題，[15] 分享了高強度工作的身體代價，顯示帳號並非完全只展示光鮮面
- 情緒化表達：[1] 對騰訊的指控措辭較為激烈（「抄袭本领是刻在基因里的」），但考慮到抄襲議題本身的嚴重性，情緒反應在合理範圍內
- 無模糊預測：帳號不涉及投資建議或市場預測，不存在事後諸葛的風險
- 無重複洗版：雖然 LobeHub 高頻出現，但每則貼文的具體內容和角度不同
- 無詐騙導流：所有外部連結均指向合法平台（GitHub、Product Hunt、TestFlight）
引用來源
我勒个去 吃瓜吃到自己头上了，今天早上一看腾讯这东西， 我们的 Skills Marketplace 面向 Agent 的功能就这么水灵灵地被抄走了，也没任何致敬表态。你腾讯是你腾讯，抄袭本领是刻在基因里的😅 图里上面是我们的 LobeHub ，下面是腾讯的 。这抄都不会去换一下图标的吗？？我们的设计就这么金标准？
应用监控问题 curl 还有一个很大问题就是默认丢了相应的 header ，你无法区分出来这个请求是来自谁，尤其是某个接口是个公开的 public 接口情况下。 而 CLI 可以相对灵活地做一些中间层的处理（当然 curl 理论上也可以让 agent 加一个 head ，但是这个又是给 agent 的注意力负担，agent 不见得能完全遵循，且 token 占用也会更高） 我们 Marketplace 的 CLI 上的第一版就没有加 header，导致后台看到的所有 UA 全都是 node，而最新的版本已经能监测到相应的 CLI UA 了，这个在后续就可以作为反爬、来源监控的重要维度。
2026，From UX to AX 总结一下，这两个月以来，我们已经能看到以 OpenClaw 为代表的 Agency Agent 的巨大潜力，而如何进一步挖掘这些潜力发挥出更大的价值，我认为最关键的点就是思想观念上的转变。 我们需要从面向终端用户的 UX （User Experience）思维走向 AX （Agent Experience），从 Agent First 的角度出发来打造相关的工具链和生态。 而 CLI 迄今为止最佳的 agent 交互界面，之前一切的产品都应该围绕 CLI 做一轮重新的设计，届时 Agency Agent 们势必会带来比现在大十倍、百倍的价值 🔥
最近刚给 LobeHub 的 Skills Marketplace 做了 CLI ，聊聊做下来的一手经验和感悟。 API + Curl 从最终实现效果上来说是一样的，但的确 CLI 会是更好的方式。打螺丝用手拧和电动钻，在最终效果是一样的，但是却是截然不同的思想和手段。 如果要我归根结底来说， CLI 的 AX (Agent Experience) 更好，对应能带来更高的任务成功率和更低的 token 消耗。 先聊聊 api + curl 的缺陷，因为 api + curl 从功效性来说是一样的，但是问题也很多，主要体现在三个方面： - credentials 存储和安全性：curl 在 credentials 上有天然的缺陷，因为必须要进 model 上下文； - Context 有效性：api 返回的 json 内容并不是 agent 友好的方式，噪音太多，会让 agent 迷失； - 应用监控问题：curl 的监控能力过弱，无法做太多的管控层，对应用开发者来说是非常不友好的一件事。 下面详细展开：
RT @lobehub: We pay for the great agents & agent groups in our community. Win $100 per featured agent by joining our Creator Reward Program. More details → https://t.co/fO7cF47zgw
过去三个月 rush 进度写了 10w+ 行代码，把双手手指都整蜕皮了😭 现在差不多恢复了，结果我家房门指纹锁和 macOS 指纹都认不出来了，只能重新录 🥲 原来指纹是种这么不稳定的身份信息吗 🫠
RT @lobehub: Introducing LobeHub: Agent teammates that grow with you. LobeHub is the ultimate space for work and life: to find, build, and collaborate with agent teammates that grow with you. We’re building the world’s first and largest human–agent co-evolving network. Two years ago, we built LobeChat, an open-source interface for using different AI models. Today, LobeChat has 70k+ GitHub stars and serves 6M+ users worldwide. How to fully unlock the power of models has always been a shared mission between us and the community. We started with interaction — a fundamentally new, agent-first experience. Agents are no longer passive tools invoked in a single conversation. They should be proactive, always-on units of work. Treating agents as the minimal atomic unit is also the core of our agent harness infra. Today’s agents are mostly one-off executors. Even with memory, it’s often global — and hallucinates. We build long-term agent teammates that evolve with users. Each agent has its own dedicated memory space, editable by users, allowing humans and agents to co-evolve over time. This, in turn, allows us to design clearer rewards for reinforcement learning and create cleaner environments for continual learning. Agent teammates can work in groups. Through a multi-agent system, agent groups operate faster, more cost-effective, and go beyond what single-agent systems can achieve. For example, a single agent often requires heavy user involvement to proceed step by step, whereas LobeHub can execute the same work from a single instruction, with a supervisor orchestrating agents that run in parallel or debate to produce better results. We are building the collaboration network among agent teammates — and between humans and agent teammates as well. Ease of use matters. AI intelligence and shared human intelligence are equally important. With simple instructions and tool selection, you can effortlessly build and team up with agent coworkers to deliver complex, systematic work — even assembling a quant team to execute trades. Through the LobeHub community, anyone can discover, reuse, and remix agents and agent groups, customizing them to fit their own workflows, preferences, and needs. Last but not least, our vision started with LobeChat: multi-model support is the most efficient approach for users. We believe different models excel in different scenarios. By routing across multiple models, LobeHub improves cost efficiency and unlocks capabilities that a single-model setup cannot easily support.
RT @ayakaneko: 总算是上线了，忙活了大半年 很高兴能和这么有天赋的大家一起推进 LobeHub 的新版本 记忆这块我真的做了很多，目的就是为了陪用户能一起成长，就像是先前做 Project AIRI 的时候给大家分享的那样 要不要去用用看？有超级多的细节 😍（肯定不会那么卡了）
RT @rea1DonandTrump: 过去一个月给 Detail 上新了不少内容，欢迎大家来一起探讨学习。 我甚至已经把里面收录的细节实装到 @lobehub 里了，非常实用，指不定哪个也能直接加在你的产品里。 🔗detail[.]design
LobeHub 新版桌面端 350M ，在 Electron 届应该已经是还可以的程度了🤗（对比参考：Linear 300M ， Cursor 400M ，Claude 500M）
很少聊设计，但看到这个忍不住想来说一嘴。以前做设计的时候，我们 team 专门做过研究，蒙层的设计引导的有效率非常低，所以强烈不建议做。 那怎么样的引导是值得做且是有效的？核心策略是把所有空值状态都单独看成另外一个界面来做，然后在这里做引导。这样出来的方案会很自然地牵引用户往下一个状态去流转。 示例参考如 Clerk： 图1：（空状态）创建完应用后直接引导该怎么集成； 图2：（集成态）有数据以后则是变成一个 dashboard。 经典产品经理往往不会重视空状态，因为这个状态存在时间非常短。但大部分时候其实是空状态才是用户启动最难的时候，而这是设计所能发挥的价值。好的引导设计是能提前预测 User Journey 并且牵引用户自然进入到下一个阶段的。
RT @rea1DonandTrump: 分享一个我做了 2 个月的设计“研究”，希望可以给你一些灵感，尤其是「做产品」本身已经看似无比简单的今天。 我收集了很多低调、待在角落里、不常惹人注意的细节，他们是设计师认真思考过的，但你可能没注意到。因为不是炫酷的动效，也不是新颖的布局。 正因为他们太过优秀，你认为这就是「设计该有的样子」。 因为没人注意，所有连 AI 都没注意到：AI 思考不出这些细节，但你可以。 这个网站在 👉 https://t.co/wIE1TK1CnO 这是一个持续更新的收藏夹，我会不断往里面添加新内容。 目前网站还是测试阶段！可能会有 Bug 或者奇怪的地方。如果碰巧你也喜欢观察这些那就更好了，欢迎聊聊你的想法。 🍷Cheer the taste
咱们 Lobe Icons 上 PH 啦，如果这个开源 AI 图标库有帮到你，望不吝啬 Up~ 😆 https://www.producthunt.com/products/lobe-icons?launch=lobe-icons
DeepSeek v3.2 发布，在产品能力上使用了 LobeHub 的 Agent Interface 体现 agentic 能力。在模型性能上使用了 EvalSys 的 MCPMark 凸显客观公正的 Tool Use 性能。 咱这含金量，懂的都懂 ☺️
面向未来， LobeHub 2.0 将统一 Auth 方案到 Better Auth 🤗 Clerk 和 NextAuth 即将成为历史 https://github.com/lobehub/lobe-chat/issues/10456
2/3) 具体来说： 如果 messages 是这种： 1 - user 2 - assistant - tool calling 3 - tool 4 - user 那么哪怕前面的 1 中没有 thoughSignature ，gemini 3 pro也不会报错。 如果messages 是这种： 1 - user 2 - assistant - tool calling 3 - tool 4 - assistant - tool calling 5 - tool 必须要要给 2、4 都加上 magic string，否则接口就会报错。
3/3) 我自己盲猜其中原理，应该是 gemini 仅会把两个 user 之间的消息作为一轮完整的 agent 调用。所以 user 之前的 tools calling 可以当成历史记录不用太严格。而在一次 agent 调用过程中，必须要保持 Thinking 连贯性，因此 thoughtSignature 会作为必要的保证一致性的手段。 而如果这个调用过程是从其他模型生成的，那么自然没有这个 thoughtSignature ，要用 magic string 来 fallback（google 应该也可以用这个方式筛出 非 gemini 3 产生的tools calling 调用）
1/3) 事实上我上周给 LobeHub 适配完成以后发现并没有文档里说的限制那么大。如果是 user 发消息之前的 tools calling 并不会有这个限制，只有在没完成 tools calling 的时候切换到gemini时才会有报错
其实我个人最好奇的是 Gemini 3.0 Pro 的工具调用能力，因为工具调用能力基本决定了驱动 Agent 的上限。之前聊架构方案还是 2.5 Pro 最 solid ，但它的问题就是不爱调工具，所以不太适合作为驱动 Agent 的核心。 然后刚刚用 LobeHub 桌面端的 Local System 插件写了个手上的性能优化需求测试了下，整个分析很准确，实现也很精准，在我们这样一个近 20w+ 行代码的项目要做到这一点还是比较不容易了的。 这次测试并没有很强的提示词工程约束，Gemini 3.0 Pro 累计用时 17 分钟完成了这个任务，总共调用了 63 次工具，消耗 3.5M token ，花费 1.5 刀。我感觉这样一个相对白坯的情况下，这个程度还是挺让人满意了，用来做 agent 应该是个还挺不错的选项了
最近做了一轮 ChatItem 的大改造，得出了一个挺反直觉的实践结论：User Message 和 Assistant Message 的设计得分开做 所以现在市面上主流的用同一个 message item 然后 reverse 下 layout 的做法基本上都是不具有可扩展性的😌
现在vibe LobeHub 的代码 TDD 已经是基操了。上周一个下午撸了个消息流解析模块总共 7500 行，业务代码才一千来行，测试和 fixtures 6000多行。 全绿飘过那叫一个舒心
RT @chunxiangai: 情况是这么一个情况，@marclou 用48小时开发了一个单页面的应用，5天内赚了 $18,380 。用户提交Stripe Key，网站通过来自Stripe的真实数据对营收进行排名。在创业公司进行MRR鼓吹式宣发的语境下，网站火了。<----但以上这些，是故事A。 按照好莱坞的拍摄手法：画面一转，来到数年前，进入B故事，来介绍主人公为什么能想出真实MMR排行榜这么简单又巧妙的想法，并让它在5天内在X爆火。你会发现他早已做了一大排的应用。其中有一个Datafast，早就提供了StripeKey上传、Web流量分析、用户行为埋点、营收统计等丰富功能。以 https://t.co/JdQJw24lMU 举例，我可以在监控后台看到来自X的发帖导致的访问量激增。很方便。 TrustMRR从功能上，是Datafast的一个子集。但他没有将MRR排行榜，作为Datafast的一次网站功能更新来发布，而是新域名、新概念，单拎出来——这是一次反直觉的决策，因为你需要有勇气放弃已经在Datafast上传过StripeKey的用户，又要人家在TrustMRR重新上传一次。结果是，TrustMRR的5天内的营收超过了它的母集。 1、不停地发布，不停地迭代，会对自己感兴趣的要素越来越敏感。 2、这些珍贵的"敏感"，会让你在关键时刻，有勇气对某个要素进行"提纯"。 3、而这种"提纯"，在外人看来是反人性、反直觉的，因为它是"高时间密度"的积累型认知。此处应当引用泡泡玛特创始人的话："尊重时间，尊重经营"。 3、看了他的大量回复，"fun"是一个关键字：找到你感兴趣的那些要素，做起来快乐的事情，做得不累。 祝各位在TrustMRR登顶！ PS：昨天登顶的是卖课的。WTF。还得是卖课？
LobeHub App iOS 开始 TF 公测： https://t.co/4j1U6PheDa 欢迎大家下载体验与反馈 🫰
[1/7] 早上和 @ShinChven 讨论了下 SSR 相关的技术问题。聊到 LobeHub 如果用经典 SSR 同构的方法，应该不会在切换页面上如此卡顿。 其实我以前一直以为 next 就是这么做的，因为在七八年刚自学前端的时候就听说过它是市面上唯一开箱即用的 React SSR 同构框架。 然后今天考古了下 2 年前做的 App Router 改造，发现了事情和我想的有很大不同 😅 可能归根结底还是 RSC 的锅，冲在前面成时代先烈了 🤡