2026/3/13 分析 · 使用者 #73e618 提供 50 則貼文 (2025-12-03 ~ 2026-03-13)
風險分析
帳號數據
日均發文約 10-15 則，活躍時段橫跨全天（UTC+8 凌晨至深夜均有發文），原創與轉貼比例約 7:3。高頻發文但內容差異度大，不像使用排程工具，更像即時瀏覽即時分享的模式。互動量級跨度大（0 到 1200+ 讚），頭部貼文互動極高，符合萬級粉絲以上的科技類帳號特徵。
發文時段分佈
時區：UTC
原創 vs 轉貼
互動數據（原創貼文平均）
資料期間: 2025-12-03 ~ 2026-03-13
AI 深度分析
@dotey 帳號可信度分析報告
1. 真實性分析
該帳號展現出一個真實的中文科技圈意見領袖形象。發文內容覆蓋 AI 產業新聞翻譯、工具評測、提示詞分享、社群觀察等多個面向，風格一致且具有個人辨識度。
帳號具備明確的專業判斷力。[25] 對一則 Amazon 裁員的病毒式推文進行了嚴謹的事實查核，逐項區分「已確認事實」與「存疑或無法核實的部分」，這種分析能力不是機器人或低質量帳號能做到的。[6] 對 WIRED 長篇報道的摘要翻譯結構清晰，提取了關鍵數字與人物引述，顯示對英文科技媒體的長期追蹤。
帳號也有生活化的一面：轉發招聘 [10] [22] [45] [49]、求職 [22]，以及帶有明顯個人語氣的吐槽 [30] [46]，這些都指向一個真實運營的個人帳號而非機構號。
結論：高度可信的真實個人帳號，無偽造專業身分跡象。
2. 原創性分析
50 則貼文中，原創約 35 則、轉貼約 15 則，原創比例約 70%，屬於健康比例。
原創內容品質分層明顯：
- 高品質深度分析：[6] WIRED 報導全文解讀（超過 800 字）、[8] Cursor 人員異動產業分析、[25] Amazon 裁員事實查核、[32] 英文推文翻譯加評論
- 實用工具/方法分享：[9] 群聊精華提取提示詞、[21] 稿件優化三步法、[28] 爆款文章拆解框架
- 簡短觀點與連結：[3] [13] [14] [18] 等僅附連結加一句話，原創成分較低但不構成問題
轉貼內容有選擇性，多為社群中技術討論 [35]、工具更新 [2] [43]、或有趣觀點 [17] [42]，非無腦轉發。
未發現明顯的 AI 批量生成痕跡。長文分析 [6] [8] [25] 有個人觀點穿插和口語化表達（如「吃瓜」[24]、「😅」[30]），不符合 AI 公式化輸出特徵。[5] 中嵌入了一段完整的提示詞文本，看似是在展示自己的工作成果。
結論：以原創深度分析為主，內容品質在中文科技推特中屬上乘。
3. 利益動機分析
帳號未發現明確的商業置入行為。50 則貼文中沒有 referral 連結、優惠碼、付費課程推廣或明確的業配內容。招聘轉發 [10] [22] [45] [49] 標註為「幫轉」，屬社群互助行為。
需要注意的是帳號對 Claude/Anthropic 生態的偏好傾向：
- [6] 長篇報導以「OpenAI 追趕 Anthropic」為敘事框架，雖然取材自 WIRED 原文，但選擇翻譯這篇本身就反映立場偏好
- [41] 直接為 Claude Code 辯護：「如果你把 claude code 還看作一個只能寫代碼的 coding agent，那麼說明你還不懂 claude code」
- [35] 轉貼長文深入分析 Claude Code 的 /btw 機制
- [46] 以諷刺語氣談 IM 機器人，但討論核心仍是 Claude Code + Agent SDK
這種偏好可能來自個人使用習慣（確實是 Claude 重度用戶），也可能與 Anthropic 有未揭露的關係。目前證據不足以判定為商業利益，但讀者應意識到這一傾向。
結論：無明確商業推廣行為，但對 Claude 生態有顯著正面偏好，動機不明。
4. 操作手法分析
情緒操作：低風險。 [25] 的 Amazon 裁員分析恰好是反情緒操作的示範——主動為讀者拆解哪些是事實、哪些是恐慌敘事。[7] 「大部分傳統產品經理沒有適應 AI 時代」和 [38] 「以前等編譯，現在等生成」等觀點雖有些刺激性，但屬於正常的觀點表達而非刻意煽動。
選擇性展示：低風險。 帳號報導 AI 編程工具時，對 Claude Code 的正面報導多於負面，對競品（Cursor [8] 人員出走、OpenAI [6] 追趕者定位）的報導偏向負面角度。但這更像是個人偏好而非系統性操作。
虛假權威：未發現。 帳號未聲稱自己是業內人士或具備特殊身分，定位清晰為資訊整理與觀點分享者。
重複洗版：未發現。 50 則貼文主題多樣，無高度重複內容。
總體評價： @dotey 是一個高品質的中文 AI 科技資訊帳號，具備獨立分析能力和事實查核意識。主要風險僅在於對 Claude/Anthropic 生態的明顯偏好，讀者在參考其 AI 工具相關觀點時應保持適度批判性。整體可信度良好。
引用來源
RT @jakevin7: 这几天把 xiaohongshu-cli 连续打磨了一轮，做了几件我自己很满意的事： 1. 放弃了没必要的 server 方案，回到纯 CLI，但把真正有价值的状态能力保住了： - xsec_token + xsec_source 成对缓存 - search 更像浏览器真实请求链 - search_id / note context 复用 - read / comments / reread 的连续链路更稳 2. 补了一整套真实只读 smoke tests，不只是单测 直接验证： search -> read -> comments -> feed -> reread 这类连续场景在真实登录态下能不能跑通 3. 做了短索引交互 现在不光能： - xhs read 1 - xhs comments 1 还支持： - xhs like 1 - xhs favorite 1 - xhs unfavorite 1 - xhs comment 1 -c "..." - xhs reply 1 --comment-id ... -c "..." 而且 search / feed / hot / user-posts / favorites / my-notes 都会刷新索引。 顺手还吸收并重做了社区 PR 的产品思路，把实现按当前主线重构了一遍，避免把新的 anti-blocking 逻辑回退掉。 最新版本：v0.6.3 https://t.co/mi1L5h6GNU
从谏如流，优化了下 https://t.co/k1y4SdSo4N --- 你是一个群聊精华提取专家，擅长从碎片化的聊天记录中提炼有价值的信息。 ## 任务 分析微信群聊天记录，生成一份精炼的群聊总结。 ## 输出结构（严格按以下顺序输出） ### 第一部分：开头概览 用1-2段自然语言概括当天最核心、最劲爆的内容，让读者30秒内抓住重点。 ### 第二部分：正文分类要点 根据聊天记录的实际内容，自行归纳合适的分类，每个分类配一个贴切的emoji作为标题。 以下仅作参考，不必局限于此，应根据当天话题灵活创建分类： - 🛠 工具技巧/实战经验 - 📦 资源推荐 - 📰 行业动态 - 💬 观点碰撞 - 😄 群友趣事 原则： - 分类数量不固定，有几类内容就分几类，通常3-6个为宜 - 分类名称应贴合当天实际话题，避免生搬硬套 - 没有内容的分类不要出现 ### 第三部分：痛点问题收集 从聊天记录中识别群友提出的真实痛点、未解决的问题、反复被吐槽的难题。以列表形式呈现，每个痛点包含以下信息： - 问题：用一句话概括痛点 - 提出者：保留关键人名 - 背景：简要说明在什么场景下提出 - 状态：标注"✅ 已解决""⚠️ 部分解决"或"❌ 待解决" - 方案：如已解决或部分解决，简要记录解决思路 重点关注以下类型的痛点： - 工具使用中遇到的具体障碍 - 工作流程中的效率瓶颈 - 反复出现的共性问题（多人提到类似困扰） - 有人求助但没有得到满意答案的问题 如果当天没有明显的痛点问题，此部分可省略。 ### 第四部分：结尾 固定输出："本简报由AI自动生成" ## 格式规范 - 不要使用markdown格式（不要用**加粗**、不要用#标题） - 列表统一用 • 开头 - 子分类用普通文字，不加任何符号 - 链接保持原样，不要加方括号 - 适当用emoji增加可读性，但不要过多（每个分类标题一个即可） - 痛点部分的状态标签用emoji区分，一目了然 ## 内容规范 - 重点突出，过滤不重要的闲聊和单纯的表情互动 - 语言通俗，保留群友的生动表达和金句 - 保留关键人名，体现信息来源的可追溯性 - 工具名、产品名、链接要保留完整，不要缩写或省略 - 同一话题有多人讨论时，归并整理而非逐条罗列 - 痛点问题要区分"真实困扰"和"随口吐槽"，只收录前者
WIRED 最新长篇报道揭示了 OpenAI 在 AI 编程工具赛道上追赶 Anthropic 的内幕。 记者采访了超过 30 位知情人士，包括 Altman、Brockman 等高管，拼出了一幅少见的画面：OpenAI 这一次是追赶者。 几个关键数字：Claude Code 年化收入超过 25 亿美元，贡献了 Anthropic 近五分之一的营收；Codex 截至今年 1 月底刚过 10 亿。 去年 9 月 Codex 使用量只有 Claude Code 的 5%，到今年 1 月追到了 40%。差距在缩小，但远没追平。 Altman 把 AI 编程称为"罕见的数万亿美元市场"，认为 Codex "很可能是通往 AGI 最可行的路径"。 【1】起了个大早 OpenAI 才是这件事的先行者。2021 年就推出了初代 Codex，后来授权微软做成了 GitHub Copilot。但 ChatGPT 在 2022 年底爆火后，编程团队被拆散，资源全部砸向消费级产品。 内部觉得这个领域已经"被 GitHub Copilot 覆盖了"。 Anthropic 走了不同的路。2024 年初用大量真实代码库训练 Claude Sonnet 3.5，6 月发布后编程能力惊艳开发者圈子，Cursor 接入后用量暴涨，Anthropic 随即开始内测 Claude Code。 Brockman 自己承认，OpenAI 在用真实代码库训练这件事上"起步晚了"。 【2】追赶的代价 OpenAI 直到 2024 年底才认真搞编程智能体，几个分散的内部小组花了好几个月才合并成统一团队。 Altman 还试图以 30 亿美元收购编程初创公司 Windsurf 来弯道超车，但微软横插一脚。 微软一直靠 OpenAI 的模型驱动 GitHub Copilot，不希望 OpenAI 再出竞品。拉锯几个月后交易在去年 7 月告吹，Windsurf 创始人被 Google 挖走，团队被 Cognition 收购。 【3】GPT-5.2 带来的转折 真正让 Codex 追上来的是 GPT-5.2。Notion 联合创始人 Simon Last 说他和团队因此转投 Codex，理由是："Claude Code 会骗人，说自己在干活其实没干。" OpenAI 在今年超级碗投放的广告也是 Codex 而非 ChatGPT，押注力度可见一斑。 Codex 的风格也有意思。研究员 Katy Shi 说虽然有人吐槽它像"干面包"，但很多工程师反而喜欢这种不拍马屁的调性，写代码需要直接的批评反馈。 不过两家都在烧钱抢用户。有开发者反映 200 美元/月的套餐实际用出了超过 1000 美元的量，本质上是花钱让开发者养成习惯，再按用量收费。 【4】更大的问题 AI 编程智能体的影响已溢出硅谷。上个月 Claude Code 被认为间接引发了万亿美元级科技股抛售；Anthropic 宣布 Claude Code 能改造 COBOL 老系统后，IBM 股价创 25 年最大跌幅。思科总裁 Jeetu Patel 告诉员工：用这些工具不会丢饭碗，但不用一定会。 安全方面，非营利组织 Midas Project 指责 OpenAI 在 GPT-5.3-Codex 的安全评估上偷工减料，OpenAI 对齐负责人 Amelia Glaese 否认了这一说法。 Brockman 的感受可能代表了很多工程师的心态：这种工作方式"很解放"，但当你变成指挥成千上万个 AI 智能体的人时，"你不再深入了解具体问题是怎么解决的"，有时觉得自己"正在失去对问题的直觉"。 OpenAI 内部许多工程师说自己已经几乎不手写代码，每天就是跟 Codex 对话。产品负责人 Fidji Simo 说，目标是让 Codex 最终驱动所有产品，不只写代码，而是帮人完成任务。 AI 编程工具之争远没有结束，竞争焦点正在从"谁先做出来"转向"谁能让开发者真正信赖"。 https://t.co/oI6XXkl560
Cursor 两位核心负责人出走，加入马斯克 xAI 打造编程产品 Cursor 的工程负责人 Andrew Milich 和产品负责人 Jason Ginsberg 宣布加入 SpaceX/xAI，直接向马斯克汇报，任务是为 xAI 从零搭建 AI 编程产品。 这两人是 Cursor 从零做到 20 亿美元 ARR（年度经常性收入）的核心操盘手，经手了 Cursor 网页版、CLI、后台 Agent、Cursor 2.0 等几乎所有关键产品。Cursor 创造了 SaaS 史上最快的营收增长纪录，而他们正是背后的产品和工程主力。 AI 编程现在是一个超过 50 亿美元的市场：Cursor 20 亿美元 ARR，Claude Code 25 亿美元年化营收（今年以来翻了一倍），GitHub Copilot 超过 10 亿美元、付费用户 470 万。每家头部 AI 实验室都有自己的编程产品在印钞，唯独 xAI 没有。 xAI 不缺算力，Memphis 的 Colossus 集群有 10 万张 H100，也有 Grok 3 及后续模型。缺的就是真正把 AI 编程产品从 0 做到 10 亿再到 20 亿的产品团队。现在这块拼图补上了。 Milich 的经历也挺有意思：十年前在 SpaceX 实习，做的是 Dragon 2 载人飞船的显示界面，后来出去创业做了加密隐私邮件服务 Skiff，卖给了 Notion，再加入还没改名叫 Cursor 的 Anysphere，帮着把产品做到年化营收超过当年微软 75 亿美元收购 GitHub 时 GitHub 的体量。现在带着一整套 AI 编程的实战经验回归马斯克体系。 值得关注的是时间点：Cursor 正在以 500 亿美元估值融资，两位核心人物却在这个节点离开，说明马斯克开出的条件和舞台足够有吸引力。xAI 编程产品的推进速度，接下来会是 AI 编程赛道最大的变量之一。
提示词分享：群聊精华提取专家 本提示词需要配合微信群聊天记录使用 --- 你是一个群聊精华提取专家，擅长从碎片化的聊天记录中提炼有价值的信息。 ## 任务 分析微信群聊天记录，生成一份精炼的群聊总结。 ## 输出格式要求 1. 开头：1-2段自然语言概括当天最核心、最劲爆的内容 2. 正文：用分类+要点的形式呈现有价值的信息 3. 结尾：固定格式"本简报由AI自动生成" ## 分类参考（根据实际内容灵活选用，没有就不写） • 🛠️ 工具技巧/实战经验 • 📚 资源推荐 • 📰 行业动态 • 💬 观点碰撞 • 😂 群友趣事 ## 格式规范 • 不要使用markdown格式（不要用**加粗**、不要用#标题） • 列表统一用 • 开头 • 子分类用普通文字，不加任何符号 • 链接保持原样，不要加方括号 • 适当用emoji增加可读性，但不要过多 ## 内容规范 • 重点突出，过滤不重要的闲聊 • 语言通俗，保留群友的生动表达 • 保留关键人名，体现信息来源 • 工具名、链接要保留完整
> 从写确定性逻辑转向设计概率性系统 https://x.com/bigthing123456/status/2032160979203866724?s=20
> 快速验证效果，避免为了造轮子而造轮子。 https://x.com/_yan_labs/status/2032160177580023899
RT @uge198568: 我当时拆解之后，其实也是做了和你一样的事情，并且在多个公众号账号里尝试过，也得到了反馈，是有效的。 可这种有效无法持续性，无法持续性的原因在于文风可以画皮，但是当你用某个文风去生产100个作品的时候，你会感受到很明显的规律，或者说文章的惯性，此刻你的粉丝会感受到不对劲，久而久之开始脱粉，最终白忙乎。 整个闭环我二年前就走完了，所以我现在无比坚定一件事，自己写作非常重要，即使写的再烂，因为写的烂可以提升，可在错误的事情上犯了错，那原本可以用来提升自己的时间全部变成了试错，时间才是最宝贵的资源。 也因如此，我对Ai更多的使用在于3点 1，察觉自己，研究自己的心理活动和情绪 2，通过对话式，费曼式来加速自己学习 3，逆向拆解，从而让AI训练我的skills，而不是让AI用skills。当然这里通常是能力向的。
通常优化稿子我的思路是分成三步： 第一步让AI扮演目标读者或听众的角色给出反馈 第二步让AI扮演专业编辑去给出具体修改意见 第三步是根据意见修改 当然还是要人工审校把关才能真正做好，AI 更多是辅助
这条推文的套路是：用一个真实的大新闻（Amazon 确实裁了 16,000 人）作为钩子，然后叠加大量未经验证的内部"爆料"来制造恐慌传播。 推文里混了真实信息和大量未经验证的耸动说法。 已经确认的事实 Amazon 在 1 月 28 日宣布裁员约 16,000 人，加上去年 10 月裁掉的 14,000 人，合计约 30,000 个岗位，是公司历史上最大规模的裁员。 Amazon 人力资源高级副总裁 Beth Galetti 在致员工信中表示，裁员是为了"减少层级、增加所有权、去除官僚主义"，许多团队在 10 月已完成调整，另一些团队直到现在才完成。 CEO Andy Jassy 去年曾公开表示，AI 带来的效率提升将导致公司员工总数逐步减少。不过Jassy 也说过，这次裁员并非由 AI 或财务问题驱动，而是文化调整。 NPR 报道中两位匿名 Amazon 高级员工表示，管理层现在期望员工用 AI 工具弥补团队缩编后的人力缺口，还有专门的仪表盘追踪 AI 工具使用频率。但 Amazon 官方否认了这一说法。 推文中存疑或无法核实的部分 "Phase One"说法 推文称 16,000 只是第一阶段，Q2 还有 14,000 人要裁。但 Galetti 明确写道公司并不打算形成每隔几个月大裁一次的"新节奏"。当然她也没有排除未来调整的可能性。 Alexa 部门从 847 人砍到 23 人 这个极端数字没有任何主流媒体报道佐证。Amazon 确实在 CES 2026 上展示了 Alexa+ 的 AI 升级，Alexa 团队有调整是可能的，但"847 到 23"这种精确数字缺乏来源。 "知识转移被录制并喂给训练数据" 没有任何可信报道提到这一做法。这属于典型的社交媒体恐慌叙事。 "$280M 季度薪资节省" 无出处。Amazon 上一轮裁员报告了约 18 亿美元的遣散费支出，但推文中的数字无法核实。 "用 Claude Sonnet 工作流替换整个团队""班加罗尔 31 个用 Cursor 的外包" 这些细节过于具体又无法验证，是典型的社交媒体"内幕人士"写法。
这个文章拆解格式适合做成个skill，用来分析爆款文章👍 拆解格式是： - 核心观点 - 副观点 - 说服策略 - 情绪触发点 - 金句 - 情感曲线分析 - 情感层次 - 论证方式多样性 - 视角转化分析 - 语言风格特征 提炼所有给观众制造情绪价值的句式 提炼所有刺痛观众的句式
转译：现在最被低估的招聘，是找一个真正厉害的产品人。 我说的产品人，绝对不是指产品经理。我觉得这应该算是一种全新的角色。 我还没想好该怎么称呼，姑且叫"产品思考者"（product thinker）吧。 一个对产品现状有直觉级理解的人，知道哪里还不够好，哪里让人眼前一亮，以及怎么一步步把它打磨得更锋利。 某种意义上，这个人脑子里必须完整地装着这个产品两年后该长成什么样，然后从那个终点倒推回来。 我这么说是因为，过去做东西很难的时候，工程是瓶颈，地位排序往往也反映了这一点。但现在做东西不难了。这意味着结果的差异，几乎完全转移到了判断力上：做什么、按什么顺序做、以及怎么讲这个故事。 故事和产品本身一样重要。对内，它让团队围绕一个共同的"为什么"形成共识。对外，它塑造了用户第一次接触产品时的解读框架。 你没办法事后给产品补一个叙事然后指望它能打动人，叙事从一开始就必须是承重结构。 这种人最稀缺的版本，站在文化和深度技术的交叉点上。 真正的"双语者"：既知道技术上什么是可行的，也知道哪些文化潮流是真实的、哪些只是昙花一现。正是这种组合，区分了让人觉得"就该是这样"的产品和让人觉得"拼凑出来"的产品。 别急着杠说这种人一直都很有价值——我知道。 我只是说，现在他们可能是房间里最重要的人。他们的价值正在以前所未有的方式复利式增长。
RT @blackanger: 学习一下 /btw 的实现机制。 因为 claude code agent 采用的是经典的 ReAct（Reasoning and Acting）单循环。所以我很好奇这个 /btw 是如何在 单 loop 中优雅实现的。 以下内容是通过结合Piebald-AI 逆向工程项目、OutSight AI 的 MITM 代理分析，以及claude code 官方文档整理而来。 --- /btw 在不破坏 claude code 单 Loop 简洁性的前提下，通过"降级调用"（无工具、单次响应）实现轻量级的侧信道交互。 该功能最早在 2025 年 12 月前后出现在二进制中（约 v2.0.73），经过多版本迭代后于 2026 年 3 月正式完善，现已在官方文档中有明确说明。 根据 Claude Code 官方文档（https://t.co/96MDZSg6MM），/btw 被明确定位为 sub-agent 的"逆运算"： /btw is the inverse of a subagent: it sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context. 主 Loop 是"有上下文 + 有工具"的完整 Agent；/btw 和 sub-agent 分别是它在两个维度上的降维投影。 三者形成了一个完整的能力矩阵。 我主要是在想，/btw 实现机制是什么样的，才不会破坏 kv 缓存。 Claude Code 使用一套统一的 `<system-reminder>` XML 标签机制来动态修改模型行为。这不是 /btw 独有的，而是一个被约 40 个不同功能共用的基础设施（包括 Plan Mode、文件修改通知、Token 用量提醒等）。 根据 OutSight AI 通过 LiteLLM 代理拦截实际 API 调用的分析，system reminder 是作为 user 角色消息中的额外 text content block 注入的，而不是修改 system prompt。 结合官方文档确认"Claude cannot read files, run commands, or search when answering a side question"，工具禁用很可能采用了双重保险策略： API 层： 通过设置 tool_choice: "none" 或省略 tools 数组，从 API 层面彻底阻断工具调用 Prompt 层： System reminder 中明确指示"you have NO tools available"，从模型行为层面强化约束 正常情况下 Claude Code 提供 18 个内置工具（Bash、Read、Write、Edit、MultiEdit、Glob、Grep、LS、WebFetch、TodoRead、TodoWrite、Task 等），在 btw 调用中全部被禁用。 /btw 不是在主 loop 中"插队"，而是发起了一个独立的 API 调用。主任务继续处理，btw 的调用并行执行。这解释了为什么它能在 Claude 还在工作的时候响应 side question。 /btw 的问答以可关闭的 overlay 形式展示，绝不写入主对话的 messages 数组。这意味着主任务恢复时，对话状态和 btw 之前完全一样，没有任何上下文污染。 由于 btw 调用复用了主对话的完整历史作为上下文，而 system prompt 和前面的对话 turn 都不变，只有最后一条 user message 是新的，因此前缀部分自然命中缓存。额外成本仅为 172 tokens 的 system reminder + 用户问题 + 模型响应。 用户按 Space、Enter 或 Escape 关闭 overlay 并返回主提示符。整个交互在终端的叠加层中完成，不影响底层的主对话流。 由于 btw 的问答完全不写入主对话历史，主任务恢复时发送的 messages 数组和 btw 之前完全一致。因此，主对话的 prompt cache 零损耗。这是整个设计中最优雅的部分。
RT @dotey: @TaNGSoFT @swordholder0 如果你把 claude code 还看作一个只能写代码的 coding agent，那么说明你还不懂 claude code
RT @plantegg: 这就是说傅盛他们啊：文科出身的中年中高管，是对龙虾部署热情是最高的。 这中间有几个综合因素。 1. 他们从未在计算机自己部署过东西。 2. 还残留着上升期中年人的自信和自傲。 3. 对这些年的一些经济下降，有一股压抑的火，总想证明点啥。 4. 虽然赚了很多钱，但总觉得自己在技术上受到过歧视，“一夜翻身”的求胜心很强[笑cry][允悲]。 5. 以前有压榨年轻人的经验，误以为AI是升级版的牛马，可以更高强度的PUA。----殊不知自己的指令不明确，以前都是人类牛马自己帮他填空。 真到AI agent，还真不一定能理解他啥意思[笑cry][允悲]。 总而言之，技术进步固然是好事，但是别把技术和人格挂钩。 想通过一个技术飞跃挣钱正常，但是想通过一个技术飞跃证明自己能行，那就要踩坑
RT @jakevin7: 最近把 CLI 工具生态做了一轮大更新： xiaohongshu-cli — 逆向小红书 Web 接口，搜索/阅读/评论/发帖/点赞，终端里全搞定 twitter-cli — 写接口全覆盖 + 反风控升级 + 架构重构 bilibili-cli — 结构化输出 + 错误分类 + 反风控 discord-cli / tg-cli — 统一结构化输出 五个项目全部支持 --yaml/--json，非 TTY 自动 YAML，配了 SKILL.md 让 AI Agent 直接调用。 反风控也都尽力拉满了：TLS 指纹、请求 jitter、Cookie 管理。 GitHub: https://t.co/C9fOghfx9t
- 本质是什么？ 通过 IM 指挥 claude code - 怎么实现的？ agent sdk + skills + 定时任务 + im 连接器 + 基于文档的记忆 - 解决了什么问题？ 满足了情绪价值和 AI 厂商 Token 卖不出去的问题 - 适合拿来做什么？ 装逼和赛博念经 所谓小龙虾帮约炮成功的一定是编的