现状 交易

更新一下自已的介紹. TradingView 5 年策略作者｜專注「公平回測、真實有效」 社區 5,000+ followers, tradingview以華人來說不錯. 大量被tradingview社區認可的公開有效strategy. 零未來函數、零回測作弊. 最多認可的strategy 有2.6K boost. 會一直分享 代碼、工具和交易觀察

Block 裁掉 40% 員工，說是因為 AI，股價漲 17%。 但沒人看 Block 在疫情期間從 3800 人膨脹到10000人，股價五年跌了 75%。公司自己也承認組織架構搭錯了。 AI 已經成為最好用的裁員敘事。 問題是，當每個人都這樣說，真正在做 AI 轉型的公司反而沒人相信了。

@Ken_SOUso 太多人沒思考

@PresentTrading 太合理

大多數人看到「multi-agent」就覺得需要搭架構。 實際上你只是需要讓模型同時站在三個不同的位置思考。 角色扮演 prompt 做到的事情，跟 agent swarm 的核心機制高度重疊：強迫模型從不同前提出發、製造內部張力、讓結論不是沿著同一條思路滑下去。架構派的做法是把這個過程外顯化，拆成獨立 agent、獨立 context、獨立 call。開銷大，可控性高，適合需要審計的生產環境。 但 90% 的使用情境不需要審計，需要的是一個不只有一種聲音的回答。 這裡有個被低估的工程事實：語言模型本來就是在海量角色的文字上訓練出來的。角色切換對它來說不是模擬，是激活不同的權重分佈。你給它三個角色，它真的會用三種不同的認知結構去處理同一份材料。 複雜度不在工具，在 prompt 有沒有把角色的前提說清楚。 說清楚了，一個 prompt 頂一個 swarm。說不清楚，架構再漂亮也是三個 agent 給你同一個答案。 ---Prompt Example--- 你現在扮演三個角色，針對以下內容分別獨立思考，然後互相討論。 開始前，先用一句話定義：這份材料要解決什麼問題、要達成什麼具體結果。三個角色都必須基於這個定義出發，不能各自解讀目標。

OpenAI 把資本支出目標砍了 60%。媒體說這是「趨於理性」。 我覺得更準確的說法是：他們終於要對投資人說一個能自圓其說的數字了。 幾個月前，Sam Altman 對外喊出 1.4 兆美元的算力承諾。 那個數字一出來，整個產業開始動：GPU 排單、資料中心選址、電力合約。沒人仔細算，因為是 OpenAI 說的。 現在變成 6000 億。 表面上，這是「財務紀律」。把支出跟預期營收綁在一起，顯示公司成熟了。很多分析師在用這個框架解讀。 但有個數字值得停下來看一下。 OpenAI 2025 年營收 131 億美元。他們的 2030 年目標是 2800 億。 這不是激進，這是五年複合成長率超過 80%。而且要維持這個速度，整整五年不能掉速。 6000 億的支出「有紀律」，是相對於 1.4 兆而言的。如果你把它換算成年均支出，大約每年 1000 億——這比 Microsoft 或 Amazon 整個雲端業務的年度資本支出還要高。 所以那個「趨於理性」的敘事，其實只是換了一個更大的數字當基準。 這有點像一個人說「我把消費從月花 14 萬改成 6 萬了，我理性多了」——但他現在的月薪只有 1.3 萬。 工程現實是這樣的：當算力需求的敘事是「越多越好，因為模型還沒到瓶頸」，資本支出就沒有天花板。但 DeepSeek 之後，「用更少算力做出差不多效果」的論文開始真的進入生產環境。投資人開始問一個之前不太敢問的問題：你的算力投入跟輸出的關係，真的是線性的嗎？ 1.4 兆那個數字，現在看起來更像是一個融資策略，不是工程預算。 讓競爭對手跟著喊、讓市場覺得不跟進就會落後、讓下一輪估值有故事可說。這種數字在矽谷有個名字，不叫 forecast，叫 narrative。 6000 億是不是就可信？也不一定。 但它至少代表：那個「算力無上限」的敘事已經不好賣了。下一個問題是，誰先找到一個既能說服投資人、又跟工程現實接得上的數字。 那個臨界點有個名字：從算力競賽轉向效率競賽。 不是誰燒得多，是誰能用同樣的錢，讓模型的邊際效益不要掉太快。 ------------------ 引用: OpenAI 大幅下调资本支出预期：1.4 万亿 → 6000 亿美元 2030 年前支出预期砍掉 60%，反映 AI 基建投资从狂热转向理性，行业可能进入整合期 cnbc.com/2026/02/20/ope…

Cloudflare Workers 可觀測性團隊負責人 Boris Tane 發了一個Claude Code 使用心得. 他的整個工作流有一條守則：在你審過並同意書面計畫之前，Claude 不准動一行 code。 大多數人的用法是：給 prompt、看輸出、修錯誤、重來。這個循環在簡單任務上跑得通，在複雜功能上會讓你花三倍時間收拾爛攤子。真正的問題不是 Claude 寫錯語法，是它在你還沒確認前提的情況下，已經在錯誤的方向蓋了十五分鐘的東西。 他的方法是：先讓 Claude 深讀 codebase 並寫成 research.md，然後出 plan.md，然後他在文件裡直接加 inline 注記——不是在 chat 裡解釋，是在錯的地方直接寫「不對，改成這樣」。 這個循環跑一到六次，直到他滿意，才說「implement it all」。 文章以下: boristane.com/blog/how-i-use…

「慢知識的護城河」 大家都知道科學是集體成就。 引力波是幾千人花幾十年搞出來的。AlphaFold 背後是整個 DeepMind 團隊。沒有人會說這些是某個天才單打獨鬥的結果。 但科技公司在招 AI 研究員的時候，賭注押的恰恰相反。 《Nature》剛發的評論揭了一個數字：入職約五年、論文引用量排在前列的年輕研究員，隔年跳去業界的機率，是同期普通學者的 100 倍。 100 倍。不是兩三倍。 這不是個人選擇的問題，這是結構性的抽血。 一個頂尖 AI 教授，全薪大概 20 到 40 萬美金。聽起來不少。但 Google、OpenAI 給的 total comp，可以到 100 到 300 萬。同一個人，做的是類似的工作，薪資差了一個數量級。 業界的邏輯很直接：只要有一個「10x 工程師」，就不用養十個普通的。而且現在連這個邏輯都在進化——如果 AI 能替代中低階的工程師，那就更應該集中資源搶頂尖的人。 問題是，這個邏輯把一件事搞反了。 你可以把學術界想成土壤，業界是在上面蓋房子。 土壤的工作是慢的，是不預設應用場景的，是允許失敗的。它產出的是可以被反覆引用、被開放批評的知識，而不是一個被商業目標驅動的產品。 把土壤裡最肥沃的那部分挖走蓋房子，短期房子蓋得更好，但長期你的地基在慢慢空洞化。 我自己在 PhD 最後這一年同時在處理這個問題：論文要發，但也面對業界 offer。 那個選擇不只是薪資計算，是在選擇你的研究問題將以什麼速度、服務於誰的邏輯。 業界的問題是真實的，但都有一個隱含的時間壓力和應用方向。學術的問題是自由的，但你必須接受那個自由是有代價的。 這個流失不會靠「學術界要更有競爭力」解決。錢的問題不能用更少的錢打贏。 它真正需要的是學術系統重新想清楚自己在提供什麼「業界沒有的東西」，然後讓那個東西對真正在乎它的人變得更可見、更有吸引力。 有個概念我一直在想：我把它叫做慢知識的護城河。 不是所有有價值的知識都能在 18 個月的產品週期裡被兌現。那些兌現不了的，必須有人守著。 -------------------------- 引用: 1. Sanders, N. E., & Schneier, B. (2026). Why sky-high pay for AI researchers is bad for the future of science. Nature. nature.com/articles/d4158… 2. Jurowetzki, R., Hain, D. S., Wirtz, K., & Bianchini, S. (2025). The private sector is hoarding AI researchers: what implications for science? AI & Society, 40(5), 4145–4152. doi.org/10.1007/s00146…

🔹 「AI 成本已跌破臨界點，不用就是浪費」 NVIDIA Blackwell + 開源模型讓推理成本直降90%（Baseten醫療案例），Together AI語音查詢成本降6倍。當AI執行成本遠低於人力，自動化從「可選項」變成「必選」。 → 必然性：經濟引力 — 成本優勢已大到無法忽視 💼 工程師/產品經理：立刻審計現有工作流程中所有高頻率、低複雜度任務，用低成本AI代理替換 🔗 blogs.nvidia.com/blog/inference…

Qwen3.5-plus 真香 1. 你要的是「接近前沿能力，但 output 不想付到 GPT-5.2 那麼貴」：qwen3.5-plus 的 $2.4/1M output 對比 GPT-5.2 的 $14/1M output，非常香。 2. 需要更強的 agent/中文穩定性/多模態/長上下文（尤其要 1M） 3. 它本身就是託管版、預設 1M、帶工具。

2026 年 2 月 16 日，你站在懸崖邊。 一邊是舊世界的餘暉（依靠信息差賺錢、依靠重複勞動生存），一邊是新世界的晨曦（依靠創造力、依靠人機協作、依靠能量掌控）。

cursor 發佈了最新的功能 Grind

@fundstrat Shouldn’t you have brought BTC?

這些編排好的操作技能其實看看就好 重要是技能也沒有泛化能力

@jenzhuscott @deepseek_ai What you said is very similar to someon else

So much to unpack @deepseek_ai ‘s expanded R1 paper. So valuable. Regardless DeepSeek releases R2 or V4 in Feb or not, 2026 R1 paper v2 update is probably the most cutting-edge, transparent benchmark in the current publicly available research materials on reasoning models by humanity. A true gift to the world. 1. It publicly shares the expensive lessons from their failures, so the others can save significant amount of trial/error costs. It points out some highly anticipated methods by the industry will actually only teach the model to "cut corners." This restores what were originally closed commercial secrets into engineering science that can be publicly verified & improved upon. 2. It confirms acquisition of reasoning capabilities does not rely on large-scale human annotation; simply by designing reasonable incentive mechanisms through "reinforcement learning," it is sufficient to induce the model to naturally emerge w complex thinking patterns that surpass human presets, shattering the superstition that "the upper limit of intelligence depends on human data." 3. It closed the generational gap in reasoning capabilities between the open-source community and the closed-source giants. This paper will go down the AI history that a small team of smart human beings offered the most advanced alternative that is accessible by the entire world rather than guarded in handful expensive walled gardens. Thank you. 🫶 arxiv.org/pdf/2501.12948…

大多數開發者還停留在「調戲 AI」的階段，而工程師已經在構建自己的「AI 命令行體系」。 這就是為什麼我選擇用Kiro。 如果說 Claude Code 提供了 Slash Commands 作為「快捷鍵」，Kiro 則提供了完整的「自動化流水線」

我为什么更爱用 Kiro👻？因为它把我从“会写”拉回“会交付”. 给Spec coding 爱好者 简单讲解要点和心得👇 1️⃣ TL;DR - 我用 Kiro 的最大收益：返工少了，因为我先写验收，再让 agent 按 tasks 交付（Kiro 主打 spec-driven） - 我不再靠“更长 prompt”求稳，而是靠“验收+验证步骤+证据链”。 - hooks/steering/CLI 让它更像一个交付系统，而不是聊天玩具。 2️⃣ 差別 AI IDE 现在都能写代码，但真正稀缺的是：长期交付的稳定性。我发现只追“聪明”，很容易短期爽、长期债。Kiro 走的是“结构化”的路线：先 specs，再 code 3️⃣ Kiro机制拆解 1. Prompt → Requirements（EARS）：把含糊意图翻译成可验收的约束 2. Requirements → Architecture：先做系统设计与最佳实践对齐 3. Architecture → Tasks → Agent：离散任务、按依赖排序、可选测试，让实现更像“工程流水线” 4. Hooks：把重复劳动变成后台触发的 agent 流程 4️⃣ 我的使用法 1. 写 spec：目标/非目标/验收（必须可验证） 2. 让 Kiro 补齐 requirements/AC（你做审稿人） 3. 让 Kiro 产出 tasks（每个 task 独立验收） 4. 逐 task 实施 + 每次附验证命令 5. 给重复动作加 hooks（补单测/补文档/格式化） 6. 用 steering 固化规范与偏好（减少来回扯皮）

VisionOS 的工作已整理好, 都開源到github.🙌 歡迎交流 #vibecoding #Robotics

沒人告訴你 其實現在最香的版本是用KIRO 到閑魚買個號, 70人民幣狂刷opus 4.5.