一、範式轉變的那個瞬間
2026年1月，徐明和團隊做了一個決定，放下做了幾年的 Trickle.so，用14天時間造一個全新的產品。
這不是心血來潮。
Trickle 是一個生產力工具，幫普通用戶做前端 coding，走的是 vibe coding 路線。
團隊在這個過程中積累了不少經驗，也看到了一些可能性。
但到了 Claude Code 出現的時候，徐明意識到， 整個遊戲規則變了 。
變化的核心在哪裏？
以前的 Agent 像 Manus 那樣，是通過 Function calling 調用工具，Agent 住在沙盒外面，跟沙盒通過 API 通信。
這就像給實習生髮了50個不同的機械手，每完成一個工序就要換一個手。
Claude Code 帶來的新範式是什麼？
只需要一個 bash，就像人類的一雙靈巧的手，不需要預先定義工具，理論上就能幹計算機上的所有事。
更本質的是，Agent 從"住在沙盒外"變成了"住在計算機裏"。
這非簡單的技術升級， 而是 Agent 第一次擁有了操作電腦的靈巧手 。
徐明在內部測試 Claude Code 的時候發現了一些有趣的現象。
非研發的同事看到 demo 很有興趣，但自己嘗試的時候，終端、VSCode 這些東西成了門檻。
大家需要的不是一個開發工具，而是一個聊天界面加任務進度觀察器。
還有一個問題，Agent 要搶你的電腦用，安裝門檻也不低。
那爲什麼不直接給它一臺電腦呢？
這就是 Happycapy 的起點。
https://happycapy.ai/
二、14天和99%
14天做出第一版，這個速度確實極端。
但更極端的是， 99%的代碼是 AI 寫的 。
徐明說，在做 Trickle 的時候，AI 寫的代碼最多佔四五成。
到了 Happycapy，團隊直接把比例拉到了99%。
他們甚至放棄了人工 review 每一行代碼的習慣，因爲代碼寫得太快，多到沒法 review。
這是一次關於工作方式的實驗。
實驗的結果是什麼？
代碼倉庫裏出現了大量"廢案"，就像遊戲裏那些做了一半沒完成的內容。
但團隊欣然接受了這一點， 接受了 Agent 這種級別的冗餘，然後跟它一起協作去幹掉這些冗餘 。
這個過程本身就是 AI Native 工作方式的演練。
組織和個人先從量變到質變，纔有了工具的 AI Native。
比做一個客戶端要難不少，因爲雲端方案涉及安全性、調度、SDK 控制、用戶權限等等複雜問題。
但團隊一開始的目標很明確， 不是做一個完美的產品，而是做一個能用的、開箱即用的方案 。
先上線，再迭代。
三、爲什麼叫 HappyCapy
這個名字來自團隊的頭腦風暴。
2025年12月，團隊就開始畫卡皮巴拉的形象了。
他們想做一個輕鬆可愛的產品，因爲 Agent 已經可以在計算機上幫人幹活了， 那美好的未來應該是大家能因此輕鬆一點 。
小動物形象在海外市場很受歡迎。
最終選定卡皮巴拉，核心原因是 它情緒非常穩定 。
這個細節值得琢磨。
在一個 AI 情緒穩定、人類情緒不太穩定的時代，產品的定位就是做那個穩定的、把活幹好的存在。
巧合的是，Anthropic 最近劇透的新模型也叫卡皮巴拉。
元子笑着說，這是穩穩地踩在了時代的前沿，哈哈哈。
但更有意思的是，這個名字背後傳遞的理念， AI 帶來的應該是快樂而非焦慮 。
四、一臺 Agent Native 的計算機
Happycapy 的定位是"Agent Native Computer"。
這個定義很關鍵。
Agent Native 的核心標誌是什麼？它和傳統的 Code Native 有什麼本質區別？
徐明的回答是，未來 Agent 跟 Computer 會合二爲一。
今天 Agent 是 Agent，Computer 是 Computer，Agent 只是接管了 Computer。
但未來它倆會變成一個東西， Computer 會是 Agent 的軀幹 。
現在的 Happycapy 1.0，只是讓 Agent 暫時住在了人類的計算機裏。
這臺計算機還是以圖形界面爲主，Agent 要模仿你打開瀏覽器去操作。
但越來越多的網站已經推出 CLI 了，連飛書都有 CLI。
當 Twitter、Reddit、攜程、京東都有 CLI 的時候，圖形界面就完全不需要了。
Agent 會在自己的 CLI 黑箱裏把所有工作完成。
接下來每3到6個月會出現一款新的計算機。
Happycapy 1.0、2.0、3.0，我們要習慣這個計算機不斷升級的過程。
這就是 Agent Native 和 Code Native 的分界線。
Code Native 只是 Agent Native 中的一個部分，一個能力。
未來的產品不是爲人類設計的 GUI，而是爲 Agent 設計的 CLI 。
五、和龍蝦的本質區別
很多人把 Happycapy 理解成"雲端的龍蝦"。
這個類比有一定道理，但不夠準確。
Happycapy 和龍蝦在底層邏輯上，最大的分岔路口在哪裏？
徐明說，Happycapy 是端到端爲用戶體驗負責的產品。
他們幫用戶打磨了沙盒體驗，內置了路由，調度了每個任務，預置了Skills，決定了哪些 CLI 要放進去。
龍蝦是一個很好的開源項目，但它無法爲端到端體驗負責。
你會發現龍蝦有一個版本升上來之後，很多人的飛書鏈接、微信鏈接就斷了，因爲它升級的時候不會考慮你連了哪些插件。
這是產品和開源項目的區別。
還有一個問題，龍蝦的大部分代碼都是 Agent 寫的，社區貢獻者越來越多。
當 Agent 貢獻的代碼越來越多的時候，怎麼去幹預它？怎麼去約束它？ 這是一個很大的挑戰。
徐明判斷，未來一定會有龍蝦的商業發行版，就像當年 Linux 的商業發行版一樣。
Happycapy 甚至可以看作是一個不同源但不同代碼的發行版 。
六、AI Native 的組織長什麼樣
Happycapy 的團隊不大，但戰鬥力很強。
祕密可能在於，他們自己先變成了 AI Native 的工作方式。
徐明說，他們不是先做了 Happycapy 纔去做這個轉換， 而是先把團隊轉成了 AI Native 的工作習慣，才發現需要一款AI Native工具，才做的 Happycapy 。
舉個例子：
他們的財務同學已經完全轉成用 Agent 來處理財務。
聽起來反直覺，因爲財務很嚴謹。
但恰恰相反，財務都是數字、文檔、票據和表格， 這些是今天 agent 在計算機上最擅長處理的事情 。
只要一個小技巧，在涉及到任何數字的比對和計算的時候，都讓 Agent 去寫 Python 腳本，不要用大模型去心算。
那個數字是絕對正確的。
哪怕你再擔心，就讓一個 Agent 做，另一個 Agent 複覈。
兩個月看下來， 出錯的比例遠遠小於人類 。
產品開發也變了。
傳統的需求文檔、設計、研發流程， 在他們公司已經沒有了 。
設計師、前端、運營，所有角色都在用 GitHub 來協作。
所有的東西都以文件推到 GitHub 來界定，在 GitHub 去 review 結果。
對 Notion 這類協作工具的使用大幅減少了，反而更多地使用 GitHub 。
這並非偶然，好友橘子的 ListenHub 團隊也是一樣，他們做了內部調研，發現這些工具使用頻率越來越低，乾脆把訂閱取消了。
省下每月幾千上萬美元，用來給大家買Claude Code的TOKEN。
人跟 Agent，以及 Agent 跟 Agent 之間的協作，GitHub 是更好的選擇。
徐明說，他們的組織結構也變了，變得更加扁平 。
每個人的決策半徑都變大了。
以前他需要看某些數據，一定會找工程師先統計一下。
現在他直接進入各個系統，讓 Agent 自己去看，看完給他一個數。
財務同學也是，以前只能處理財務系統上的數據，如果需要 AWS 或者 Cloudflare 上的基礎設施數據，或者需要 Stripe 上的賬單，都要去找工程師拿數據。
現在財務跟她的 Agent 說就好了，只要給她必要的權限，她自己就搞定了全部數據的整合 。
每個人的決策半徑都變大了，決策層級變小了。
所有人都同時在幹所有事 。
設計師可能在寫前端，產品經理也在寫前端或後端，前端和後端可能變成全棧。
這就是 AI native 的組織形態。
審覈機制也變了。
以前可能讓 CTO 去審覈每一行代碼，現在代碼提交多了100倍，PR 多了100倍，CTO 已經無法去審覈每一行代碼了。
從過去的 Review 代碼本身，變成了 Review 產品體驗。
很多代碼已經不去檢查中間過程了，只看上線之後，通過人和 AI 自動化測試的方式去看體驗有沒有變化。
還有一個改變， 不要求把一個完美的更新推到線上 。
如果你是 Happycapy 的老用戶，你會發現他們經常一天裏有十幾次更新。
只要決定它沒有重大風險，就把功能儘可能先推上線。
很多時候用戶比他們測得還快，這樣方便大家體驗到最新的能力，也是跟社區一起 Review 。
七、Product Hunt 的"神仙打架"
Happycapy 在 Product Hunt 上的表現很驚豔。
日榜第一、周榜第一、月榜第一。
但月榜第一來得並不輕鬆。
那天，Happycapy 遇到了硬茬， 一家 A16Z 投資的俄羅斯公司 。
兩邊此消彼長，你漲幾十票，我就再拉幾十票。
AJ和我在自己的各個微信和X賬號，Fingerfly嘉賓的很多朋友都在幫Happycapy拉票，徐明團隊也在全力動員。
可惜，最後一刻，Happycapy 還是落後20多票，所有人都快絕望了。
結果對方被Producthunt官方發現刷票作弊，剔除了一些票數，Happycapy 終於拿下了月榜第一。
這場"神仙打架"讓整個 AI 圈子都興奮了起來。
海外的 Instagram、Facebook 上AI圈的人到處都在聊，今天 Product Hunt 怎麼回事，這兩個團隊到底什麼背景。
甚至據說那天 ProductHunt 的流量可能都是新高。
徐明說，這次打榜最大的意義不是流量， 而是讓他看到了從第一次在 ProductHunt 發佈產品（當天排名第24）到現在的變化 。
第一次發佈的時候，他們什麼都不知道，沒有視頻，沒有準備，只有二三十個人投票，排名第24。
但這兩三年的過程串起來，讓他很震撼，從完全什麼都不知道，到現在開始做對了 。
越來越多的人開始幫助他們，這纔是真正讓他感覺做對了的信號。
ProductHunt 是一個很好的產品發佈平臺。
第一它免費，第二它聚集了國內國外最多的科技行業 SaaS 產品或者 AI 產品的發燒友和專業人士。
這是很好的早期用戶羣體，他們會給你很好的反饋意見，甚至第一波流量和第一波付費用戶 。
如果產品確實有特色，更好的流量在二次傳播當中。
海外會有很多 Newsletter，會有一些產品 Influencer（網紅/達人） 看這個榜單。
如果他們覺得你的產品真的好，會主動做二次推薦和評測。
真正能跑出來的，是看第二波的二次傳播。
八、誰在用 Happycapy
徐明給出的用戶畫像很清晰。
介於極客和小白之間。
如果天平的一邊是完全的開發者和極客用戶，另一邊是完全的小白用戶，Happycapy 最好的用戶區間在這之間。
你可能日常工作中有一些專業任務，但不是很重的研發場景，也不是極度的重度極客用戶 。
具體場景呢？
不是那些看起來很炫酷的"武功"，而是迴歸到日常工作生活中的重複任務。
幫你創建一個表，幫你調研一隻股票，幫你整理發票，幫你寫 PPT。
最開始上手，從那些你已經做過、大量重複、且一眼就能看出對錯的事情開始 。
然後是進階階段，通過跟 Agent 合作，讓它幫你做一些原來做不到的事情。
比如財務同學問數據，Agent 不再只是給文字或表格，而是直接做一個 Dashboard（儀表盤） 讓你自己分析。
第三階段，是讓 Agent 做調研、探索性的事情。
設定一個實驗臺，讓它24小時大量重複地做實驗。
重複工作、拔高能力、探索未知，這是三個階段。
九、一個晚上做出 iOS 版
徐明分享了一個Claude Code讓他震撼的故事。
過年前要回家，他覺得在家應該很少能打開電腦，就臨時花了一個晚上五六個小時，給自己做了一個 iOS 版的 Happycapy。
這輩子從來沒寫過移動端代碼，甚至不知道該選什麼框架，全程跟 Claude 探討，五個小時手搓出來了。
今天 Max 用戶內測的那個版本，就是當時那個一個晚上的原型。
這個故事的意義不在於技術本身， 而在於 Agent 大幅拔高了一個人的能力邊界 。
第一階段 Agent 做你熟悉的事，第二、第三階段真的可以做到很多你原本做不到的事情。
這是10倍、20倍的槓桿，這個是真的很明顯 。
十、用戶的腦洞
徐明印象最深的用戶案例，是用戶自己在定義自己想要的界面。
有一個高手用戶，用了很多 TOKEN。
徐明去問他到底用來幹啥，發現 他自己爲 Happycapy 開發了一堆插件 。
他不滿意官方的 UI，就按照自己的理解做了一套自己的 UI 部署在本地。
他把所有任務按照看板的感覺來分，按完成度來區分，同時跟蹤很多任務 。
他每天不看官方的對話界面，只看他那個看板界面。
還有很多自己的功能，比如篩選對話、搜索、排序、自動化等等。
他完全按自己的理解做了一套自己的 UI。
還有一個用戶做了一個叫"卡皮農場"的東西。
把 Happycapy 的任務具象成了一個一個卡皮巴拉的角色，在一個卡通的農場裏面，就像一個遊戲場景一樣去調度 。
這給了徐明一個很大的啓發。
過去的產品經理，包括他自己，實際上是把所有人的訴求取到一個交集，得到一個最大的公約數，把棱角都刪掉了，最後得到的是一箇中庸的答案，一個60分的結果 。
但未來可能是每個人會得到自己滿意的一個90分的結果。
十一、TOKEN 焦慮和解法
這是繞不開的話題。
Opus 太貴了，徐明很誠實地說， Happycapy 目前是在補貼用戶，成本非常高 。
即使在有周限額的情況下，補貼力度依然很大。
90%的付費用戶七天之後還在用，但 收入確實無法覆蓋成本 。
怎麼辦？
一方面，團隊在跟 Minimax、Kimi 等國產模型合作，豐富用戶的選擇。
Minimax 2.7在一些稍微沒那麼複雜的場景裏，體驗還可以。
另一方面， 他們在做一些工程研究，希望有創新突破能緩解 TOKEN 焦慮 。
具體怎麼解決不能劇透，但這是從 Trickle 時期積累的上下文處理經驗延續過來的。
當時是爲了解決上下文裝不下的問題，現在可以解決上下文貴的問題。
還有一個辦法是用 Skill。
徐明舉了個例子，Anthropic 官方推薦的寫 PPT 的 skill，最早版本執行150多步，非常浪費 TOKEN。
最近的版本精簡到20步， TOKEN 省了七八倍 。
更優秀的方法論，能把成本真正降下來。
這就像一臺車，發動機是 V8 的很耗油，但總有一些人的開車技巧能讓它省油一點。
十二、Skills 生態的未來
Happycapy 上有很多 skills，目前能搜索到網絡上所有的 skills， 應該有40萬條 。
但徐明有一個觀點， Skills 不是未來 。
爲什麼？
同樣做 PPT 這一件事情，你能搜到800個 skills。 你怎麼去平衡這些 skills？
而且我們現在的計算機上安裝了很多 Skills，但它們類型完全不一樣。
做前端開發的時候需要這一些 Skills，寫文章的時候又需要另一些 Skills。
徐明判斷，Skills 上面可能還會有一層封裝，是 Agent 或者是Skills的集合。
現在看到的 Skills 應用市場，可能是一箇中間狀態。
團隊 CTO 做的那個美股交易員就是一個例子。
它不是一個 Skill，而是一套 Skills，加上人類的智慧，以及 Agent 在試錯當中積累的經驗和記憶系統 。
它打包在一起，是一個 Agent。
這個東西有很強的被分享和被複用的價值。
十三、普通人怎麼用
很多人面對新產品會茫然無措，不知道該怎麼用。
徐明的建議很實在。
第一，茫然感是正常的。
他回想起自己小時候學計算機，前一兩年其實都是很茫然的。
真正的啓蒙點是玩遊戲，爲了玩遊戲要改很多配置文件，在這個過程中學會了很多東西。
所以他在思考，有沒有一個打引號的 Agent 的遊戲，一個 Playground，讓大家在沒有那麼嚴肅、沒有那麼壓力的情況下，把 Agent 入門給解決了。
第二， 先找一個你日常真的要用的場景，在用這個場景的過程中慢慢學習 。
不要上來就看着左邊的功能菜單一個一個學下來，那樣會很茫然。
把一個工作生活中已經有的小問題丟給它，比如幫我寫一個 PPT，或者幫我整理一些數字、整理一些 Excel 表。
從這個過程中去解決問題，去學習。
至於怎麼養成把任務交給 Agent 的習慣？
從簡單的、大量重複的、一句話能說清楚的任務開始。
徐明自己的例子，每天凌晨12點讓 Agent 去看所有人提的 PR，總結一下，看看有沒有潛在的 Bug，如果有的話再給一個修復建議，每天早上起來給他發封郵件。
另外他有個 Automation 自動化流，每天凌晨3點去掃描開源項目的代碼更新和商業化產品的文檔更新，最後寫一份簡報發給他。
這些任務聽起來很簡單，很容易描述清楚，大量重複。
很多 Automation（自動化） 的項目都是一句話能說清楚的。
十四、五個"不要"
當被問到創業者應該避免什麼時，徐明給出了五個建議：
1. 不要再做龍蝦套殼了。
已經太多了。
如果要做，去做優化版的龍蝦，那甚至更有意義。
2. 不要再做去年範式下的 Agent。
去年那個範式下的大模型套殼真的不要再做了。
如果要套殼，套 Claude Code，Agent 套殼是可以的。
3. 不要再做 GUI 的產品。
應用主力做 Agent，做 CLI。
4. 不要侷限在單機。
龍蝦這一類單機其實已經挺好了，不要再過多研究它單機的性能了。
想想它們聯網之後會怎麼樣。 計算機一定會聯網。
5. 不要只看 C 端場景。
很多 B 端還是有機會的，可能也不一定有你想的那麼難。
還有一個更本質的建議。
找到大廠沒有立場去解決的問題。
比如 TOKEN 貴這件事，不是 Anthropic 的困擾，是用戶的困擾。
Anthropic 的工程師不會喫不下飯睡不着覺每天想着優化 TOKEN 成本，他們要把 ARR 做大，要上市，要 IPO。
找到正確的問題，找到大廠的立場，他沒有意願、沒去解決的問題。
或者說，幹了對他們沒好處的事，所以他們沒有很強的意願去幹。
永遠有一波他們不願意乾的事。
十五、爲 Agent 打造產品
什麼樣的 Agent 產品值得長期關注？
徐明的回答是， 爲 Agent 打造產品，值得長期關注 。
不是 Agent 產品本身，而是爲 Agent 打造的產品。
比如，Agent 需要有自己的支付、自己的錢包、自己的郵箱，甚至自己的電話。
今天我們都是在強迫 Agent 去訪問人類的網絡，它有諸多限制。
比如讓它上 Twitter 就不是很順暢。
但 Twitter 一定會變得對 Agent 友好，對合法的 Agent 友好 。
Agent 也會有自己的 Twitter，有自己的 Facebook。
現在想讓 Agent 去京東幫我買一個東西，還是比較複雜的。
但京東會變成歡迎 Agent，或者說會有新的歡迎 Agent 的新京東出現 。
徐明覺得這個事情 3 到 6 個月就會有，很值得期待。
十六、Agent 越來越強，和 AGI 還有什麼區別
Agent讓人類終於找到了大模型的正確使用方法 。
這是通向 AGI 的正確道路之一。
但它不完全是 AGI，因爲今天理論上 Agent 只是接管了我們的計算機。
它的能力邊界是人類使用計算機的能力邊界 。
但人類的智慧可不只在於數字世界操作計算機。
人類還有很大的世界可以去操作。
所以它是通向 AGI 重要的一環，是找到了正確的方向之一。
十七、AI 會搶飯碗嗎
這是個繞不開的問題。
徐明說，短期內確實會是一個混亂的過程。
但他給程序員的例子很有意思。
以前的焦慮是35歲被裁，現在只要你願意，代碼可以寫到60歲 。
因爲寫代碼已經不是體力勞動了，Agent 把體力勞動那部分接管了，腦力勞動可以工業化了，但人可以貢獻智慧。
年齡已經不是很大的因素了，關鍵在於思維方式是不是能夠跟 Agent 一起協作，而且一定要變成 Agent 爲主、人類爲輔的方式。
有兩類人用 agent 寫代碼最好，一類是老師傅，過去的經驗非常豐富，有很多跨類型的經驗。
還有一類是完全沒有經驗的年輕人、高中生。
這兩類人都可以把 agent 寫代碼寫得非常好。
另一個建議是降低預期。
不要期望 Agent 一夜之間幫你賦能10倍，從簡單的事情着手，能提效20%、30%就很好了。
把預期降下來的時候，人反而就沒有那麼焦慮。
長遠來看，很多基礎工作會被解放出來，大家又開始去做更加有創意的事情。
人類工作時長會越來越短，可能一週四天、三天 。
十八、預期管理的邊界
很多人對 AI Agent 最大的誤解是什麼？
預期。
因爲網上新聞看得太多了，會預期說所有事情交給它就能解決了。
這是比較大的一個誤區。
現階段對 Agent 比較務實的想法是， 這個任務是你自己能做的，且你知道這個結果是好還是壞，然後你用 Agent 來先做 。
就像徐明跟他爸說的，炒股這件事他自己是知道的，且他自己會操盤，他也知道什麼是虧錢、什麼是賺錢。
這個時候用 Agent 來替代是一個比較務實的階段 。
而不是說你可能完全不知道這件事怎麼做，你就讓 Agent 像一個魔盒一樣幫你搞定了，那這個是不太現實的。
還有一個有意思的現象。
有經驗的人在使用 Agent 的時候，可能會因爲自己的經驗限制了自己的想象力，反而用得沒有那麼好。
比如編程領域，有一些有通識性知識的人去做編程的時候，在某些領域上反而勝過了一些編程的老師傅。
因爲老師傅會把具體定義得非常明確，你要用什麼方法、用什麼框架、用什麼路徑去做什麼事情， 反而限制了 Agent 。
預期管理的邊界在哪裏？
在於驗收。
我們可能不知道中間過程，不知道方法，但一定要知道什麼是對的，什麼是我想要的。
你得知道說，我可能不知道這盤菜的配方是什麼炒出來的，但我一定得說出來它是淡了還是鹹了，是酸了還是苦了。
你不能說它不好喫，你得說它有點太辣了，我不想喫這麼辣。
你得講出這個程度的事情。
這是對未來所有人的一個能力上的要求。
十九、三年後最大的風險
如果三年後回頭看，Happycapy 最大的風險是什麼？
徐明說， 更多還是來自自己，團隊遲鈍了，或者說對某些東西不夠敏銳了 。
現在在一個巨大的變化當中， 就像一個衝浪選手，其實不是浪把你打倒的，是你自己的姿勢不對，或者你自己的狀態不對 。
至於巨頭碾壓的問題，徐明的看法是， 對於這個時代的創業者來說，永遠還得是往前走 。
你不能做停下來的那種競爭，你得去探索能力邊界上再往前去探索一點點，往外再拱一點。
這是你能生存下來的第一個條件，是你能總是在邊界上再往前探索一步，這是你比大廠唯一的優勢 。
當年的 Manus 出來，再到龍蝦，大家其實都是在現有的邊界上往前再走了一步。
這一波的創新纔剛剛開始，那個邊界上有很多的方向你可以去突破。
二十、寫在最後
這場對話持續了兩個多小時，信息量很大。
但最打動我的，不是那些技術細節，而是徐明團隊身上那股勁。
看準方向就往前衝，用14天證明想法，用兩個月跑出成績。
他們自己先變成了 AI Native 的工作方式，才做出了 Happycapy。
財務同學完全轉換成用 Agent 處理財務，設計師、前端、運營都在 GitHub 上協作，所有人的決策半徑都變大了。
這不是工具的勝利，是組織和個人先變了，工具纔跟上來。
範式變了，計算機正在重新被髮明一遍。
我們正站在這個變化的起點，看着下一代計算機慢慢成形。
Happycapy 只是開始。
但更值得期待的，是這個時代本身。
注： 本文基於2026年3月28日"未來硅世界"第13期直播訪談整理。
未來硅世界每雙週的週六，和朋友一起圍爐夜話，聊聊 AI。主持團隊：向陽喬木、姚金剛、尼克西、元子。
想了解更多，可以訪問 https://happycapy.ai 或加入社羣交流。
能看到這裏的都是喬幫主鐵桿！
如果覺得不錯，請隨手三連~
謝謝你耐心看完我的文章~