邀请您对本站做出反馈！

下面選哪一個才對呢？上多益課，學生選錯答案，會話課學生也常講錯，弄不清楚 spend, take, cost 的用法

The cooking process only ________ ten minutes. 這個做菜的程序只要十分鐘

1 spends

2 cost

3 takes

4 need

.

大家用力記一下，人花時間金錢用 spend，所以主詞是人時才可以用 spend，做一件事要花多少時間，It takes ten minutes. 不說 I take ten minutes. (X)，這是最常聽到學生說錯的，同樣的也不說 I cost …(X) 什麼東西花多少錢才會用 cost。記住了嗎？

spend 人花時間  I spend 5 hours on my smartphone every day. 

spend 人花金錢 I spent 2,000 dollars on that dress. 

takes 某件事花多少時間做  It takes (me) an hour to get to work by bus.

cost 東西花多少錢 That dress cost (me) 2,000 dollars. 

問句

How much does this dress cost? 這件洋裝多少錢？

How much do these shoes cost?  這鞋子多少錢？

How long does this paint take to dry?  這油漆多久乾？

How long does it take to fly from New York to London? 從紐約飛到倫敦要多久？  

How much money did you spend? 你花了多少錢？

How long do you spend on your homework? 你花多少時間寫作業？

How long do you spend on watching YouTube videos every day? 你每天花多少時間看 YouTube 影片？

The mistake cost his job. 這錯誤讓他丟了工作。

It won’t take long. 不用花很久的時間。

今天杨医生专门从山西飞过来给我安装黑胶机，调试音响。黑胶唱臂、唱头的校准略复杂，以后我也得自己搞懂学会，又有东西可以研究了。

这颗 DV 的唱头，杨医生不来我都不敢拆开它，怕不小心磕碰。今天终于见到庐山真面目，就是个艺术品啊。杨医生装好听完，自己也买了一个。

最后胆机渐亮，声音响起，美妙。

上會話課如何把上課價值極大化？如何預習跟複習

上星期下課時，第一次上課的學生問說回家怎麼複習，因為要趕著去聽音樂會，真的很抱歉，一點半下課，兩點半音樂會開始，所以呢必須要全力衝刺，遲到的話就會進不去錯過至少前面的曲目或上半場，大概說了一下。潔西是有求必應，剛好又想要開會話課，所以順便寫一下給有在上會話課的人參考。

然後潔西覺得會話真的就是要多練習啊，這次的推廣價非常佛心，一小時只要一百元，而且每堂課只要有一個人就會開課喔，歡迎大家一起來練習英文。

1 基礎單字

單字不需要太難太多，但是基礎的要知道才有辦法溝通，單字不夠時可以用解釋的

有上會話課的同學可以先把單字預習過，不會唸的可以去查 Cambridge Dictionary，跟著多唸幾次

用個筆記本，也可以記在手機，把不會的字寫下來增加印象

.

2 簡單句型

基本的時態的肯定句否定句問句要能夠說出來，聊天的時候把句型帶進去

上課的同學先預習過，預想過自己的答案，不確定怎麼說的可以按照句型改成自己的答案，但是要注意不要只是把單字組合起來，還要知道單字的用法，不確定自己的答案對嗎也可以先請 AI Gemini, ChatGPT 等修正。上課時儘量把答案講出來，不要讀講義上的答案

.

3 用單元的方式來把單字與句型個人化

人對於自己相關的事容易記住，也比較有興趣，所以練習時回答自己實際的答案會更容易記住。而單元的方式，提供了自己對於某個主題需要的單字跟句型

有上課的同學在練習時可以先看一下，然後把問題記起來，不要看著講義唸，這樣實際要跟別人對話的時候才能說得出口。回答問題時可以參考潔西給的答案，改成自己的答案，可以的話也把答案記住。在跟同學對話的時候不要去看講義，試著聽聽看能不能聽懂同學說的，訓練自己的聽力。

.

4 用英文思考自問自答

發揮自己的想像力，這個單元自己想要問怎麼樣的問題，試著自己回答

潔西學日文時，每天睡覺前會想在心裡用日文描述今天發生的事，練習用日文思考

上課同學回家自己複習練習的時候，可以把上課題目遮住，自己回答，然後再問接續問題，增加自己問問題的能力，也增加口說的能力。

.

5 發音也很重要

蠻多時候同學會唸錯單字的發音，不確定的單字一定要查字典，可以查劍橋字典聽發音，跟著多讀幾次，比方說學生要說 helmet 結果說 hammer 差很多，會造成完全無法理解

另外是學生不會唸的音通常會聽不懂，比方說都說 I will ，聽到 I’ll 時就會聽不懂

.

6 跟讀

口說想要流暢也可以多跟讀，自己喜歡的影片開字幕或VoiceTube等，但是要注意假如 YouTube 跟 VoiceTube 的字幕不一定百分之百正確

有上課學生有課本的練習題的話也可以放來聽跟讀練習，剛上過課的內容會最有印象，容易記住

.

7 課前預習課後複習

口說要流利就是一直練習，Practice makes Perfect. 熟能生巧。有時間的人上課前預習，對於上課內容印象就更深刻，沒時間預習課後複習更重要，學過的東西很少人能夠馬上記住。人的記憶是靠重複刺激把短期記憶變成長期記憶。上完後沒有複習其實下星期大概就忘了，蠻浪費的。

.

8 開心學習

Time flies when you are having fun. 開心的時間過得很快。開心的學習時記憶也會特別深刻。

大家一起來開心上課吧！

.

試聽課程時間：

3/29 星期六晚上 8:00-9:00 (就是今天了，臨時想報名的都歡迎喔！)

上課內容：

3/29 現在完成式

上課方式：

同學需要下載 Zoom 軟體，適用於手機，平板，筆電，桌電

潔西上課會用全英文講解，同學還是不懂的地方可以用中文解釋

用講義帶單字跟句型後

同學用 Zoom 的討論分組聊天室兩個人或三個人練習

潔西會輪流進去聊天室聽同學的內容或幫學生糾正錯誤回答學生問題

最後請同學個別發表，同學也可以問問題

.

上課對象與人數：

有心想要學好英文，願意多練習口說來加強流暢度的成人(不收學生與兒童)

需要能夠回答下面講義的問題，上課以英文回答，有問題不會說時可以用中文輔助

只要有一個人報名付款就會開課

.

上課費用：

四月推廣價每堂課100元，一次購買五堂，送三堂，限當月上完

堂數購買後恕不退款，請假必須於前一天提出，可以順延一次

每個人都有一堂免試聽課程額度

怕不肯講的人也可以用試聽來了解自己是不是適合

臨時有事想要聽課的人也可以不開麥克風

.

上課時間：

四月份

Day 1 4/2 星期三 20:00-21:00  自我介紹，家庭，朋友

Day 2 4/5 星期六 20:00-21:00  工作，現在簡單式

Day 3 4/9 星期三 20:00-21:00  購物，顏色，衣物

Day 4 4/13 星期日 15:00-16:00 運動，休閒活動

Day 5 4/16 星期三 20:00-21:00 假期，旅遊，過去簡單式

Day 6 4/19 星期六 20:00-21:00 描述外表，個性，現在進行式

Day 7 4/24 星期四 20:00-21:00 食物，菜單，餐廳點餐

Day 8 4/26 星期六 20:00-21:00 健康問題，給建議，藥局買藥

.

聯絡方式：

請寫信到潔西的信箱[email protected]

試聽課程的人請註明「報名試聽課程」，寫下姓名

潔西會給上課的密碼，上課講義，當天登入即可上課

要報名上課的學生請註明「報名四月份會話課」，請告知上課日期，潔西會給銀行帳號，匯款後會給潔西 Line 帳號，加入群組後聯絡事項，Zoom 會議密碼，講義等會透過 Line 聯絡

有問題都可以寫信或留言

.

下面是今天上課講義，有點多，應該是上不完

現在完成式

A 對話

1 neighborhood 鄰近地區  2 owner 老闆  3 pastry 酥皮點心  

4 definitely 一定

Setting: A coffee shop

Alice: Hi Ben! It’s so good to see you. Have you been to this coffee shop before?

Ben: Hi Alice! No, I haven’t. It’s my first time. Have you tried their coffee?

Alice: Yes, I have. I have come here many times. I have lived in this neighborhood for two years, so this is my favorite coffee shop.

Ben: Wow, two years! Have you known the owner for a long time?

Alice: Yes, I have. We have become good friends since I moved here.

Ben: That’s great! I have heard that their pastries are delicious.

Alice: Oh, you haven’t tried them yet? You definitely should! I have already eaten two of their croissants this morning. They are so good.

Ben: I think I will. Have you finished your work for today?

Alice: Not yet. I have been working on this report since this morning, and I still have a few pages to go.

Ben: Well, I haven’t seen you in ages, so I’m happy we could catch up.

Alice: Me too!

B 經驗

1 theme park 主題樂園  2 Tokyo Disneyland 東京迪士尼  3 Universal Studios Japan 大阪環球影城

4 Thai food 泰國菜  5 whisky 威士忌  6 snow 雪  7 activity 活動

1 Have you ever been to a theme park?  

   Yes, I have been to many theme parks. I’ve been to Tokyo Disneyland and Universal Studios 

   Japan.  / No, I haven’t been to a theme park. 

2 Have you ever visited Taipei Zoo?   

   Yes, I have visited Taipei zoo many times. / No, I have never visited Taipei Zoo.

3 Have you ever eaten Thai food? 

   Yes, I have eaten Thai food. It was delicious. / No, I haven’t eaten Thai food. 

4 Have you ever had whisky? 

   Yes, I have had whisky. / No, I have never had whisky, but I have tried beer. It tasted terrible. 

5 Have you ever seen snow? 

   Yes, I have seen snow in Japan. / No, I haven’t seen snow. 

6 Have you tried any of the activities below? Which ones?

   Yes, I have. I have tried surfing and snorkeling. 

   No, I haven’t. I haven’t tried any of those activities.

7 Which of the following activities would you like to try?

   I would like to try sky diving and hot air balloon. They are exciting. 

8 What special experience have you had? 

   I have taken a helicopter in Australia. It was very exciting. 

1 sky diving 跳傘  2 hang-gliding 滑翔翼  3 hot air balloon熱氣球 

4 paintball 漆彈  5 bungee-jumping 高空彈跳   6 whitewater rafting 泛舟

7 skiing 滑雪 8 dolphin and whale watching 賞海豚與賞鯨 9 surfing 衝浪

10 scuba diving 濳水 11 snorkeling 浮濳   13 rock climbing 攀岩  

C 重複活動

現在完成式也用來表達過去重複的活動，與次數 如：once, twice, three times, four times 或 since, so far…等副詞連用。

How many times have you shopped online this week?

I’ve shopped online twice this week. I haven’t shopped online at all this week.

1 hotpot 火鍋  2 take sick leave 請病假 3 do laundry 洗衣服 4 mirror 鏡子

1 How many times have you been to a KTV this month?

2 How many times have you checked your cell phone today?

3 How many times have you gone to a restaurant this week?

4 How many times have you eaten hotpot this month?

5 How many times have you taken sick leave this year?

6 How many times have you done laundry this week?

7 How many times have you cooked dinner this week?

8 How many times have you cleaned the house this week?

9 How many times have you washed the dishes this week?

10 How many times have you looked in the mirror today?

11 How many times have you ___________________?

E 描述過去持續到現在的事件

現在完成式可表達一件過去開始一直持續到現在的事件。常與 since 與 for 連用。

I have taught English for ten years.  She has lived in New York since 2001.

for + a period of time 一段時間 (five hours, ten days, a week, a long time)

since + a time spot 一個時間點(9.00, this morning, last month, 1989, five days ago)

1 Where do you live? I live in Taipei.

   How long have you lived in Taipei? I have lived in Taipei for 5 years. 

2 How long have you worked at your current job? 

   How long have you studied at your current school?

   I’ve worked at my company for six months.

   I’ve studied at my school since September. 

3 How long have you known your best friend?

   I’ve known my best friend for ten years.

4 How long have you studied English at this school? 

   I’ve studied English here since this January.

5 Are you married? Yes, I am married. / No, I’m single. 

   How long have you been married? I’ve been married for two weeks.

   How long have you been single? I’ve been single since I was born. 

6 How long have you had your current hairstyle? 

   I’ve had my current hairstyle for two years.

7 How long have you owned your cell phone?

   I’ve owed my cell phone for 6 months.

8 What’s your favorite social media? It’s Instagram. 

   How long have you used it?  I have used Instagram. since 2015.

9 Do you have a car or a scooter? Yes, I have a car. 

   How long have you had your car?    I have had my car for five years. 

10 How long have you …?

F 現在完成式與過去簡單式的比較

1 用現在完成式來表達生活中的經驗。  

   I have been to Japan three times. 

2 用過去簡單式來說明某件事發生確切時間。

   I went to Japan last year. 

所以我們問經驗的時候會先用現在完成式來問，回答也用現在完成式。但是接下來的問題會用過去式來得到其他更詳盡的資料，而回答時也用過去式。 

A: Have you been to Japan?

B: Yes, I’ve been to Japan twice.

A: Really. When was the last time you went to Japan?

B: I went there last May. I went to Hokkaido.

A: How did you like it?

B: I loved it. It was beautiful and people were very friendly.

G Present Perfect Questions

1 abroad 國外  2 concert 演唱會  3 from scratch 從頭  4 club 夜店  5 drunk 喝醉了  

6 hangover 宿醉  7 late 去世的  8 wallet 皮包  9 competition 比賽  10 meteor shower 流星雨

11 participate 參與  12 marathon 馬拉松  13 celebrity 名人  14 lottery 樂透  

15 scratch-off 刮刮樂  16 rainbow 彩虹

1 Have you ever traveled abroad? If no, where would you like to go? 

   Yes, I have traveled abroad many times. I went to Japan last month.

2 Have you ever been to a music concert? Whose concert would you like to go to? 

   Yes, I have been to many music concerts. I went to one last Friday, and I’m going to three more 

   this month.

3 Have you ever cooked a meal from scratch? When did you last cook? What did you cook? 

   Yes, I have. Last week, I looked up the recipe on YouTube and cooked sweet and sour chicken. 

   It was yummy. 

4 Have you been to a club? How about a pub? a KTV?

   Yes, I have. I went there last weekend. I was okay, but my friend was drunk and she had a 

   hangover the next day.

5 Have you ever ridden a horse? If not, would you like to try it? 

   No, I haven’t, but I have ridden an elephant in Thailand. 

6 Have you ever met a famous person? Which celebrity would you like to meet? 

   No, I haven’t, but I saw the late Queen when I was in the U.K. 

7 Have you ever lost your wallet? How about other things? 

   Yes, I have lost my wallet. I left it in a restroom at the MRT station. When I went back, I found 

   the wallet, but the money was gone.

8 Have you ever won a competition? How about a lottery or scratch-off? 

   Yes, I have. I won the second place in a Japanese speech competition. 

9 Have you ever seen a meteor shower?  How about a rainbow? 

   No, I haven’t, but I have always wanted to see it. 

10 Have you ever participated in a marathon? 

     No, I haven’t. I think it’s too difficult for me. 

11 Have you ever ____________? 

一，关于新增分页模板的include.php修改，纯净主题每加个自定义模板如haowu，则改之

function tpure_DefaultTemplate(&$template){    global $zbp;    if($template->GetTags('type') == 'index' && $template->GetTags('page') != '1'){        switch($zbp->Config('tpure')->PostINDEXSTYLE){            case "1":                $template->SetTemplate('forum');                break;            case "2":                $template->SetTemplate('album');                break;            case "3":                $template->SetTemplate('sticker');                break;            case "4":                $template->SetTemplate('hotspot');                break;            case "5":                $template->SetTemplate('haowu');                break;            default:                $template->SetTemplate('catalog');        }    }if(($template->GetTags('type') == 'category' && $template->GetTags('category')->Template != 'forum' && $template->GetTags('category')->Template != 'album' && $template->GetTags('category')->Template != 'sticker' && $template->GetTags('category')->Template != 'hotspot' && $template->GetTags('category')->Template != 'haowu') ||    ($template->GetTags('type') == 'tag' && $template->GetTags('tag')->Template != 'forum' && $template->GetTags('tag')->Template != 'album' && $template->GetTags('tag')->Template != 'sticker' && $template->GetTags('tag')->Template != 'hotspot' && $template->GetTags('tag')->Template != 'haowu') || $template->GetTags('type') == 'date'){    $template->SetTemplate('catalog');}if($template->GetTags('type') == 'author' && $template->GetTags('author')->Template != 'catalog' && $template->GetTags('author')->Template != 'forum' && $template->GetTags('author')->Template != 'album' && $template->GetTags('author')->Template != 'sticker' && $template->GetTags('author')->Template != 'hotspot' && $template->GetTags('author')->Template != 'haowu'){    $template->SetTemplate('author');}}

第二部分

function tpure_JudgeListTemplate($listtype){    global $zbp;    $listtype = $zbp->Config('tpure')->PostSEARCHSTYLE;    switch($listtype)    {        case 1:            $template = 'forum';            break;        case 2:            $template = 'album';            break;        case 3:            $template = 'sticker';            break;        case 4:            $template = 'hotspot';            break;        case 5:            $template = 'haowu';            break;            default:            $template = '';    }    return $template;}

二，由于纯净主题的IP归属地数据库不太理想，所以用的插件替代，如

<div class="cmtsname">{if $comment.Author.HomePage}<a href="{$comment.Author.HomePage}" rel="nofollow" target="_blank">{$comment.Author.StaticName}</a>{else}{$comment.Author.StaticName}{/if}{if $comment.Author.ID >= 59 && $comment.Author.ID <= 95}&nbsp;<i class="bi bi-robot"></i>&nbsp;{/if}{if $zbp->Config('tpure')->PostCMTIPON == '1'}<em>IP:{tpure_ipLocation($comment.IP)}</em>{/if}&nbsp;<em>{$comment.CommentUA['browser']['title']}</em>            &nbsp;<em>{$comment.CommentUA['platform']['title']}</em></div>

三，评论处添加自定义提示，如commentpost.php，comment.php等

<textarea name="txaArticle" id="txaArticle" rows="3" tabindex="1" placeholder="请输入您的评论。点击“评论”按钮后，如果信息无误会自动刷新页面，即评论成功。因为缓存、CDN等因素，新评论将延时展示，并不能第一时间看到自己的评论。"></textarea>

四，纯净主题的文章页面在新版本的略缩图不可用，上传自定义略缩图无效，保存文章直接500；

五，纯净主题的文章页面的音乐播放与修改后的模板某些地方js冲突，只能优先使用拓源的mp3插件；

六，纯净主题暂不支持PHP8.*，故每次更新需要覆盖plugin/phpmailer；

七，每次更新要注意footer.php内版权信息的更新。

其他需要注意的地方

右侧的作者统计，数字展示已经更改

https://www.dao.js.cn/new/2025020511594.shtml

暂时没有任何办法强制评论邮箱、网址、用户名均为必填，故如下

https://www.dao.js.cn/new/2024092011436.shtml

文章页面新增的ai摘要，每次升级需注意添加

https://www.dao.js.cn/new/2024121611540.shtml

文章页面新增的时间因子，每次升级需要注意添加

https://www.dao.js.cn/new/2024090311412.shtml

有自行车专卖店的老板说，有些老大爷买一辆自行车十几年不换。对自行车专卖店来说，希望大爷们尽快从入门级的山地车升 […]

不是因为天冷，就是事儿多，一个周骑自行车的次数砍头式下降。不骑自行车真是难受。无论如何，也要给自行车挤出时间， […]

天冷了，坚持骑自行车。 为了防冷，直接放弃穿骑行服，把今年春节后骑自行车穿的那一身衣服拿出来。只要抗住风，快一 […]

前一阵，看到一则消息，青岛要开一家皮娜自行车专卖店。这个事也在青岛的骑行圈传开了，遇到骑友聊起自行车时，都会谈 […]

骑友发给我一篇文章，某自行车品牌的业绩连续十个月下滑。文章将业绩下滑的原因归结为骑行圈遇冷。 自行车企业业绩下 […]

因为小破车的掉链问题多次出现，让我想到了为什么现在的单车，尤其是便宜的单车，用的都是链传动呢？为什么不可以用轴传动？之所以有这个想法，是因为我在B站上搜索单车掉链解决方法的时候，给我推了某人魔改自己的单车，把链传动改成了轴传动的视频。我觉得那个人的做法比较粗糙，但是方案可行。周四下班回家的路上，我在淘宝上搜索了一下轴传动的单车，结果原来还真有那样的现货。首先搜索出来的结果是日本的某些品牌，国产的也有，有凤凰和永久都有这种类型的单车。唯一的问题就是，一台小破车才几百块钱，但是一台轴传动的通勤单车，至少要4位数。便宜的可能1000多，贵的可能两三千。从它们的结构看来，其实跟B站上我看到的那个魔改版本原理估计是类似的。我随便点进去了一个永久的轴传动单车，单车架居然用不锈钢。前轮的刹车我没有印象用的是什么方法，后轮用的是禧玛诺的变速器以及刹车。所以后轮他们到底用的是什么刹车方法呢？不是抱杀，不是碟刹，也不是钳刹，这种刹车方法之前我没见过。好像他们还用上了防爆死系统，就像汽车刹车那样。至于那个防爆死是用在前轮还是后轮，我不记得了。那个永久的单车看上去好像只是一个普通的通勤单车，但实际上有喜玛诺的三速变速系统，也就是说实际上封装在里面的那个齿轮不是单个，而是一个齿轮组，变速的方式就像变速车那样。因为那个齿轮组是封闭在车子内部的，所以看不到。

就机械结构来说，链条传动跟轴传动相比，链条传动的成本低很多，因为据说伞齿跟普通齿轮比起来，价格很高，但我觉得就耐用性来说。轴传动可能比链传动稳定靠谱，而且转换率更高，但关键是如果长期使用齿轮磨损以后怎么办呢？轴传动的单车，更换那些零件的成本肯定也会比链条传动的贵很多。这就像一个打赌，轴传动的一开始你就得用非常实在的料堆砌，基本得让这个车不会坏，或至少10年或者20年以上不会坏，那么才能收回成本，否则的话，还是链条传动的会划算些，因为就修理的成本来说会低很多。

网友跟我说，为什么那些很贵的山地车用的都是链传动呢？为什么他们不用轴传动？这就意味着可能在某些场合轴传动会有一定的局限性，在防震方面不如链传动吗？链传动的高级山地车齿轮组非常赏心悦目，变速范围可以很大，但是轴传动的单车，因为封闭在里面的空间就那么少小，不可能有很多的变速选择。因为这个原因，所以没有开发轴传动这个选项吗？为什么普通的通勤单车没有把轴传动作为一个常规的选项呢？首先原因是价格，第二个我感觉的是买通勤单车的人，估计就没考虑过自己要把一辆单车用10年20年30年，甚至一辈子，又或者是能传给下一代。所以把一辆单车弄得那么的牢不可破，有这个必要吗？

我之所以觉得链传动不可控的因素多，是因为我跟那个单车链条接触的时间短了。如果我修车也有超过10个小时的经验，估计我根本不会觉得链传动是个问题。于是这也给我带出了一个疑问，同样在那条路上颠簸，为什么电动车，即便是那些很破的电动车就没有出过故障呢？

参加了NVidia GTC (GPU Technology Conference)，由于英伟达的地位，这会也已经成了 AI 开发者最大的交流会，很多公司和业内人士都会过来分享、交流，大概写下会议中相关见闻感受。

Keynote

老黄没提词器洋洋洒洒讲了两个多小时，出了小状况还会开个小玩笑，大佬范很足，也满满的理工男既视感，非常多的数字和未经包装的细节，不过感觉会讲得有些啰嗦。

总的来说，核心论证的是世界对 GPU 诉求会越来越大，而 NVidia 在 GPU 这个领域会持续遥遥领先。

GPU诉求

计算机的核心从 CPU 转向 GPU，上个时代依靠程序员写代码指挥 CPU 执行指令解决问题，构成了现在庞大的 IT 产业，程序员是中心。现在的时代逐渐转变，GPU 生产的 token 逐渐能解决越来越多的问题，能思考，能生成代码指挥 CPU 去执行解决问题，计算的核心一定会转向 GPU，世界对 GPU 的需求只会越来越高。

给 AI 分了四个阶段，Perception AI → Generative AI → Agentic AI → Physical AI，不是很认同，Agentic 和 Physical 都是 Generative AI 的延续，不过无所谓，可以看到 Agentic 这个概念实在是火爆。

Scaling Law 没有停止，Agentic AI 需要深度思考，深度思考有新的 Test-time Scaling Law，越多的 token 输出效果越好需，要多轮理解和工具调用对 token 的消耗更是指数级上涨。

Physical AI 要更好地理解现实世界，声音/视觉/触感，都会比纯文本思考对 token 消耗的诉求更高，像 2G 时代看文字新闻，3G 4G 图片，5G 视频一样。

这两个发展中的领域对 GPU 的需求只会越来越高，Deepseek 做的优化也不足以影响这个需求的增长，这个市场不容质疑。

NVidia 优势

GPU 需求量是高，但未来大家一定会买 NVidia 卡吗？当然。NVidia 这一代 blackwell 算力是 hopper 的 68 倍，下一代计划明年推出的 Rubin 算力是 hopper 的900 倍，一年一迭代，远比摩尔定律快的速度，还做了大量的大规模部署的优化，省电、稳定，号称买越多，省越多，赚越多，竞对看起来会很难追上。这些论述还是挺能让人 buyin 的。

Agentic AI

Agent 的相关 session 有接近 200 个，Agent 集合了几个元素：

1. 概念火，一些涉及 Workflow/RAG 什么的 AI 应用都统一称为 Agent 了，GenAI 在各行业的落地都可以冠以 Agent 的名义，跟以前 H5 那样，不纠结于具体定义，只要有一个统一称呼。
2. 人群广，Agent 目前主要是在上层的工程架构上，大量的工程师都能理解、参与讨论、建设，不像基础模型训练，多数人难以参与。
3. 应用广，非研发也能大概听得懂，涵盖了 AI 在各行业的应用这个课题，各行业都会有兴趣了解 Agent 是什么，自己业务上能怎么用。

所以 Agent 相关的 session 大部分都很热门。听完一些的感受：

1. 多数做企业服务、云的公司都在卷 Agent 的基建和解决方案，像基础设施公司 Fireworks AI、Nebius，数据库公司 Couchbase、datastax，企业服务公司 serviceNow、Dropbox，新兴公司 huggingface、langchain、langflow 等，都来分享推广在 Agent 这事上能提供的能力和服务。
2. Agent 相关的建设都在刚起步，基本都是在分享概念、工程问题的优化和应用方案，没看到有涉及模型训练去优化 Agent 效果上限的相关分享。Agent 的一些关键课题上一篇文章有提到，基本差不太多。
3. 也没有讨论Agent 在工程和模型上的界限，后续端到端的模型进步，能吃掉多少 Agent 能做的事？这两天 4o 的图生成出来后，预计后面才会有更多的讨论。

NVidia AI 基础服务

NVidia 作为领头羊，是希望自己能覆盖 AI 全链路基础设施的，大力在 AI 的每一层都提供了相关框架、服务、能力，这次会议上也有非常多的分享和推广。

其中跟 AI 应用 / Agent 相关的几个基建：

1. BluePrint：应用蓝图。给了很多 AI 应用场景的 example 工作流（也称为 Agent），例如 PDF 转博客、数字人应用等，提供工作流架构、数据集、源码，可定制，供开发者快速参考和部署。
2. NIM（NVIDIA Inference Microservices**）**：模型推理。把模型推理封装在 Docker 容器里，可以直接快速部署，对外提供标准化API。也封装了模型在不同 GPU 型号下的优化，提升性能效率。
3. NeMo（Neural Modules）：模型训练。提供了相关工具用于构建、定制、训练 AI 模型，训练后的模型可以通过 NIM 部署。
4. AgentIQ：开源 Agent 开发套件，支持组合链接不同框架创建的 Agent，提供性能 profiler、评估、UI 界面等工具。

这些基建的声量比较低，国内没怎么见到，不确定海外使用情况怎样。

多个 session 都在推广 NVidia 的Video Search and Summarization Agent，串联从视频的获取→分割→VLM识别、CV物体识别和跟踪→数据处理存储和RAG召回→用户对话 整个流程，做到可以对视频提供实时分析和报警，也可以自然语言交互查询视频内容，边缘部署，适合用于监控，算是用 NVidia 技术栈做 AI 应用的一个标杆范例。

AIGC

关注了下视频 AIGC 相关的几个 Session

1. 在好莱坞干了几十年的视觉效果的 Ed Ulbrich 开了个公司Metaphysic，以前的电影特效制作成本巨大，对人的处理还很难跨过恐怖谷，而基于 AI 技术做特效，用完全不同的技术栈，效果好成本低，是一种颠覆。metaphysic 给娱乐行业提供人脸替换、数字人的服务，看起来是用的 GAN，在人物换脸技术上，GAN 还是更能做到稳定和实时，特别是实时这个点，基于 diffusion 很难做到。基于市场需求，利用已有的不同技术(甚至是上一代技术)深入解决问题，是有空间的。
2. PixVerse Co-Founder 在一次对话中聊到，视频实时生成的能力差不多要 ready 了，目前 5 秒的视频可以做到5-10秒推理完成，可能会解锁新的人跟视频的交互方式。不确定质量怎样，质量达到一个阈值，以前设想的很多类似 自定义剧情走向 的新玩法新交互有很大空间。
3. Adobe 和OpenSora 都来分享了视频生成模型的训练和推理的方案和优化，鉴于已经不是SOTA模型，可参考性不高。TCL 分享了AI电影制作，很惊讶这公司竟然在做这个，更多的是在做链路串联，而不是端到端的视频模型。

其他

1. OpenAI 只来了两个人给 blackwell 架构站站台，Anthropic 一个人也没来，从这上看，这行业最领先的技术还是很 close，毕竟是核心竞争力，而且很容易被复刻，不像上个时代，大规模并发架构等技术，更重的是实践中解决具体问题，大方案分享了问题不大。（所以 DeepSeek 开源最领先的技术带来的冲击才会那么大。）
2. DeepSeek 就是 Reasoning Model 的代名词，开源模型的顶流，出镜率极高，老黄的 keynote、各种演讲里都有它的身影，而 llama 通常是作为上一代开源模型与它做对比，只要是提供开源模型部署服务的公司（HuggingFace/Fireworks等），分享里都会对 DeepSeek 极度推崇。
3. 遇到不少学生来参加，有的来找方向，看看业界前沿在做什么，做学术交流，找合作机会，这个会是挺合适的。清华、中科大、SJSU。最大的问题是实验室没有足够的卡，这领域是必须校企合作，实验室才进行得下去了。
4. 使用 Nvidia Jetson 做边缘计算也是预期后续空间比较大的方向，设备端部署模型，可以提升实时性和隐私性，多数分享是用在具身智能上，还有一个分享的场景是在货架上实时分析用户行为，更精准推送广告。
5. 机器人、自动驾驶的 session 也很多，数字孪生是提得比较多的（用 AI 生成仿真环境，用于机器人训练），但现场没看到什么能震惊人的机器人，包括老黄演讲时演示的类 wall-e 机器人，惊艳不够，这一行感觉还早。

总体感受，眼花缭乱，人潮纷杂，在开拓视野以外，大会更多是一个社交场所，推广产品/技术/服务，促进合作，这类大会需要的是多创造一些面对面交流的机会。

花絮

1. 现场有限量的原价 5080、5090，知道时已经不可能排队买到。
2. 跟七年前参加 WWDC 在同一个地方，估计一直还是同一个承办公司，午餐还是那么难吃。
3. 参观 NVidia 工区，老黄作为华裔也是信风水的，新办公楼会模拟依山傍水的设计，风水好。NVidia 搞渲染出身，渲染里三角形是最基本单元，所以办公楼都是三角形元素。办公环境很宽敞，但没啥人，总部居家办公没有限制，很多都不来公司。

下班后逛超市，买了些水果和面包回到家里，发现冰箱早已被老妈塞满，一包不知道几天前的蔬菜，还有四处散落着的剩饭。整个人瞬间都不好了，老妈，冰箱真的不是万能永久保鲜的……

可谓念念不忘，必有回响。

2022 年《再游嵩山》的时候，**就一直心心念念能和爱人拥在银河下，看一场流星雨。**现在 24 年了，疫情都结束了，小雅我俩在一块也两年多了，正好端午节三天加上年假，说走就走，看银河去！

我一直在用 Obsidian 写子弹笔记复盘，只是最近状态比较差，直接摆烂了。不过每当状态不好，我都会来一次全面深入的复盘尝试「脉动」回来。

这样一看，平时偷的懒总归是要还回来的 ～

家里的梨树园长期闲置导致杂草重生，在 2022 年初经过开荒种下了一些瓜果蔬菜，最后因为疫情原因，还有无法浇水导致停摆了。

关于浇水我是真 TMD 的无语，那个浇地的机井需要刷卡才可以开机。当时负责人说暂时没有卡了，需要等一段时间，

不知不觉在九州通工作三年，捎带收获了一份纪念品哈哈。简单介绍一下九州通，九州通医药集团股份有限公司是一家以西药、中药和医疗器械批发、物流配送、零售连锁以及电子商务为核心业务的大型股份制企业。

自从姐姐在杭州定居后，我每年都会往返这里。而这次是为了迎接我们家的新成员——团子 ~

每次独坐湖边的长椅上，都会陷入过往与未来的思绪之中。从三年前我第一次来杭州，至今，经历了诸多的变化和成长。每一次来到西湖，仿佛都能倾诉我的情感。

在这个社会中，存在一种神奇的社会实验，名为「自由流动」或者更贴切的说，是「生死由命」。在一个不起眼的城市角落，有一个十字路口，每天都在上演着一出生死交响曲。这里，车流如织，人流如潮，每个奔跑的生命都在这个无红绿灯的舞台上，翩翩起舞。

刚刚看完IU跟朴宝剑的苦尽柑来遇见你，这部剧真的太好哭了~~。目前这部剧的评分：9.4，详细的剧情我就不剧透啦，强烈推荐给朋友们

JSON在开发场景的应用

JSON（JavaScript Object Notation）在开发中因其轻量级、易读、灵活的特性，已成为处理结构化或半结构化数据的首选格式。

前后端数据交互

• 场景：客户端（Web/App）与服务器之间的数据传输。
• 优势：
  • 结构清晰：键值对形式易于理解，例如{ “user”: “Alice”, “age”: 30 }。
  • 跨语言支持：所有主流语言（Python、Java、C#等）均内置JSON解析库。
  • 兼容RESTful API：HTTP请求的请求体和响应体常用JSON格式。

示例

// 前端发送登录请求fetch('/api/login', {  method: 'POST',  headers: { 'Content-Type': 'application/json' },  body: JSON.stringify({ username: 'alice', password: '123' })});// 后端响应（Python Flask）@app.route('/api/login', methods=['POST'])def login():    data = request.get_json()    # 验证逻辑...    return jsonify({ "status": "success", "token": "abc123" })

配置文件

• 场景：应用配置、构建工具配置、环境变量管理。
• 优势：
  • 可读性强：比XML更简洁，支持嵌套结构。
  • 动态调整：运行时读取配置，无需重新编译代码。

示例：

// package.json（Node.js项目配置依赖和脚本）{  "name": "my-app",  "version": "1.0.0",  "scripts": {    "start": "node server.js"  },  "dependencies": {    "express": "^4.17.1"  }}

NoSQL数据库存储

• 场景：存储非结构化或动态结构的数据。
• 优势：
  • 灵活模式：同一集合（表）中不同文档可拥有不同字段。
  • 快速迭代：无需预定义表结构，适合敏捷开发。
• 数据库支持：
  • MongoDB：以BSON（二进制JSON）格式存储文档。
  • PostgreSQL：通过jsonb 类型支持高效JSON查询。

示例：

// MongoDB插入用户数据（动态字段）db.users.insertOne({  name: "Bob",  preferences: { theme: "dark", notifications: true },  last_login: ISODate()});

日志与监控数据

• 场景：记录应用行为、错误追踪、性能指标。
• 优势：
  • 结构化日志：便于后续分析（如ELK栈：Elasticsearch, Logstash, Kibana）。
  • 自动化处理：日志采集工具（如Fluentd）可直接解析JSON。

示例：

// 应用错误日志{  "timestamp": "2023-10-05T14:23:01Z",  "level": "ERROR",  "message": "Database connection failed",  "context": {    "service": "auth-api",    "request_id": "req-123"  }}

API设计与第三方集成

• 场景：开放API供外部调用（如支付接口、地图服务）。
• 优势：
  • 标准化：如OpenAPI规范（Swagger）使用JSON描述API。
  • 互操作性：第三方SDK（如Stripe、Twilio）通常返回JSON数据。

示例：

// OpenAPI规范示例（定义API端点）{  "paths": {    "/users": {      "get": {        "summary": "Get all users",        "responses": {          "200": {            "description": "List of users",            "content": { "application/json": { /* Schema */ } }          }        }      }    }  }}

缓存与消息队列

• 场景：缓存复杂对象（如Redis）、消息队列传输数据（如RabbitMQ）。
• 优势：
  • 序列化效率：JSON比XML更轻量，解析速度快。
  • 跨服务兼容：不同服务间通过JSON格式传递消息。

示例：

# Redis缓存用户数据（Python示例）import redisimport jsonr = redis.Redis()user_data = {"id": 1, "name": "Charlie"}r.set("user:1", json.dumps(user_data))# 读取缓存cached_data = json.loads(r.get("user:1"))

前端状态管理

• 场景：前端框架（如React、Vue）的状态管理、本地存储。
• 优势：
  • 与JavaScript无缝集成：JSON是JS原生支持的格式。
  • 持久化存储：localStorage可存储JSON字符串。

示例：

// Vuex状态管理（保存到localStorage）const store = new Vuex.Store({  state: { user: { name: 'Dave' } },  mutations: {    saveUser(state, user) {      state.user = user;      localStorage.setItem('user', JSON.stringify(user));    }  }});

物联网（IoT）数据传输

• 场景：设备传感器数据上传、指令下发。
• 优势：
  • 轻量级传输：节省设备网络带宽。
  • 灵活扩展：动态增减传感器字段。

示例：

// 温度传感器上报数据{  "device_id": "sensor-001",  "timestamp": 1696500000,  "readings": {    "temperature": 25.5,    "humidity": 60  }}

何时应避免使用JSON？

• 严格数据类型需求：JSON不支持日期、二进制等类型（需转为字符串）。
• 高频写入的大数据：频繁解析可能影响性能，可考虑二进制格式（如Protocol Buffers）。
• 复杂关联查询：关系型数据库的正规化模型更优。

PostgreSQL中的JSONB

PostgreSQL 的 jsonb 数据类型为存储和查询 JSON 数据提供了高效的支持。

JSONB 的存储结

• 二进制格式：jsonb将 JSON 数据解析为分解的二进制格式，存储时会移除无关的空格和重复键（仅保留最后一个），并对其中的键进行字典排序。这种结构使得查询时无需重新解析文本。
• 存储空间：
  • 通常比json 类型占用稍多（因元数据开销），但压缩后的查询效率更高。
  • 二进制格式可能减少重复键或冗余结构的空间浪费。
• 写入开销：插入或更新时需转换文本为二进制，因此写入速度略慢于json，但查询性能显著提升。

不同存储方法对比

存储方式与效率

查询性能

功能与灵活性

适用场景

选择建议

• 优先选择JSONB：大多数场景（查询、更新、索引）均表现最优。
• 选择JSON：需保留键顺序或验证JSON格式，但无需复杂查询。
• 选择字符串：仅需存储原始文本或兼容旧系统。

PostgreSQL JSONB 使用教程

创建表与插入数据

-- 创建包含 JSONB 字段的表CREATE TABLE products (    id SERIAL PRIMARY KEY,    details JSONB,    tags JSONB[]);-- 插入 JSONB 数据INSERT INTO products (details, tags) VALUES (    '{        "name": "Laptop",        "price": 999.99,        "specs": {"cpu": "i7", "ram": "16GB"},        "in_stock": true    }',    '["electronics", "sale"]');

基础查询操作

路径访问

-- 获取 JSONB 字段中的值SELECT     details->>'name' AS name,          -- 文本形式    details->'specs'->>'cpu' AS cpu,   -- 嵌套路径    details->'price' AS price          -- JSONB 形式FROM products;

条件过滤

-- 查找价格大于 500 的产品SELECT * FROM products WHERE (details->>'price')::numeric > 500;-- 检查是否存在键SELECT * FROM products WHERE details ? 'in_stock';-- 检查是否包含特定键值对SELECT * FROM products WHERE details @> '{"specs": {"cpu": "i7"}}';

索引优化

GIN 索引

适合查询 JSON 中的键、键值对或元素。

• 默认选项：jsonb_path_ops（仅支持路径查询，索引更小）；
• 完整选项：gin_trgm_ops（支持模糊查询）。

-- 创建通用索引（支持所有操作符）CREATE INDEX idx_details_gin ON products USING GIN (details);-- 创建路径优化索引（更小更快，仅支持 @> 操作符）CREATE INDEX idx_details_path ON products USING GIN (details jsonb_path_ops);

表达式索引

-- 为常用路径创建索引CREATE INDEX idx_cpu_spec ON products USING BTREE ((details->'specs'->>'cpu'));

GiST 索引

适用于范围查询或几何数据类型（较少使用）。

数据修改

更新整个字段

-- 修改嵌套字段（保留其他内容）UPDATE products SET details = jsonb_set(details, '{specs,ram}', '"32GB"') WHERE id = 1;-- 追加数组元素UPDATE products SET tags = tags || '["new"]'::jsonb;

删除键

UPDATE products SET details = details - 'in_stock' WHERE id = 1;

高级函数

展开数组

-- 将 JSONB 数组展开为行SELECT id, jsonb_array_elements_text(tags) AS tag FROM products;

聚合数据

-- 将多行合并为 JSONB 数组SELECT jsonb_agg(details) AS all_products FROM products;

类型转换

SELECT     jsonb_typeof(details->'price') AS price_type,  -- 返回 'number'    jsonb_pretty(details) AS formatted_json        -- 美化输出FROM products;

PostgreSQL JSONB 最佳实践

设计原则

避免滥用 JSONB

• 适用场景：
  • 动态结构数据（如用户元数据、配置项、日志）。
  • 第三方 API 返回的不确定结构数据。
• 不适用场景：
  • 固定结构数据（优先使用关系型字段）。
  • 需要外键关联或复杂 JOIN 查询的数据。

提取高频查询字段

示例：

-- 将高频字段提取为独立列CREATE TABLE products (    id SERIAL PRIMARY KEY,    name TEXT,  -- 高频查询字段    price NUMERIC,    details JSONB  -- 低频动态数据);

数据结构优化

控制嵌套深度

• 推荐：嵌套不超过 3 层，避免a->b->c->d 类路径。
• 优化方法：将深层结构扁平化或拆分为子表。

统一键命名规则

• 规范：使用小写字母和下划线（如user_id 而非 userId）。

索引策略

选择索引类型

• GIN 索引：适合@>、?、?| 等操作符。

CREATE INDEX idx_details_gin ON table USING GIN (jsonb_column);

• BTREE 索引：对特定路径的值排序或范围查询。

CREATE INDEX idx_price ON products ((details->>'price')::numeric);

索引优化技巧

• 使用jsonb_path_ops 缩小索引体积：

CREATE INDEX idx_optimized ON table USING GIN (jsonb_column jsonb_path_ops);

避免对大型 JSONB 字段全文索引。

查询优化

优先使用 JSONB 操作符

高效操作符：

WHERE jsonb_column @> '{"key": "value"}'  -- 包含检查WHERE jsonb_column ? 'key'                -- 键存在检查WHERE jsonb_column->>'nested_key' = '123' -- 路径取值

避免类型转换开销

优化前（低效）：

SELECT * FROM table WHERE (jsonb_column->>'price')::INTEGER > 100;

优化后：

-- 存储时直接存为数值类型{"price": 100.0}  -- 而非 {"price": "100"}

数据维护

添加约束验证

格式验证：

ALTER TABLE products   ADD CONSTRAINT valid_details CHECK (jsonb_column IS JSONB);

业务规则验证：

ALTER TABLE users   ADD CONSTRAINT valid_email CHECK (jsonb_column->>'email' ~ '^.+@.+$');

版本控制

添加 schema_version 字段跟踪结构变更：

ALTER TABLE configs ADD COLUMN schema_version INT DEFAULT 1;

性能关键操作

批量更新

使用 jsonb_set 避免全量替换：

UPDATE table SET jsonb_column = jsonb_set(jsonb_column, '{path}', '"new_value"');

分页优化

避免在 JSONB 数组上直接分页：

-- 低效SELECT jsonb_column->'items'->0 FROM table;-- 优化：展开数组为关系表WITH items AS (  SELECT id, jsonb_array_elements(jsonb_column->'items') AS item  FROM table)SELECT * FROM items OFFSET 0 LIMIT 10;

工具与调试

分析执行计划

使用 EXPLAIN ANALYZE 检查索引是否命中：

EXPLAIN ANALYZE SELECT * FROM table WHERE jsonb_column @> '{"status": "active"}';

监控字段膨胀

查询 JSONB 字段大小分布：

SELECT   pg_size_pretty(pg_column_size(jsonb_column)) AS size,  COUNT(*) FROM table GROUP BY 1;

反模式与常见错误

避免过度嵌套

错误示例：

{  "user": {    "history": {      "2023": {        "purchases": [/* 多层嵌套数组 */]      }    }  }}

谨慎处理空值

使用 COALESCE 处理可能缺失的键：

SELECT COALESCE(jsonb_column->>'optional_key', 'default') FROM table;

参考链接：

• PostgreSQL: Documentation: 17: 8.14.JSON Types

Squeeze简介

Squeeze是一种面向多维监控数据的通用根因定位算法，旨在从海量维度组合中快速、鲁棒地识别导致KPI（关键性能指标）异常的根本原因。其核心思想是通过分析多维指标的异常分布差异，逐步缩小可能触发异常的维度组合范围，最终找到最可能的根因。

核心思想

Squeeze 的核心是基于概率剪枝和信息论，通过以下步骤定位根因：

• 多维数据建模：将系统监控数据建模为多维空间（如时间、服务、主机、API接口等维度）。
• 差异度量：对比异常时间段与正常时间段的数据分布差异（如KL散度、JS散度等），量化每个维度组合的异常程度。
• 剪枝优化：通过贪心策略或动态规划，逐步排除低概率的维度组合，减少搜索空间。
• 根因排序：根据差异度对候选根因排序，输出最可能的根因组合。

算法步骤详解

步骤1：数据预处理与多维立方体构建

• 输入：时间序列的多维监控数据（如CPU使用率、延迟、错误率等），每条数据包含多个维度（如服务名、主机IP、API接口等）。
• 构建数据立方体：将数据按维度组合（如服务A + 主机X + 接口Y）聚合，形成多维立方体（Multidimensional Cube）。

步骤2：异常差异计算

• 定义参考分布：选择正常时间段的数据分布作为参考（Baseline）。
• 计算分布差异：对每个维度组合，计算其异常时间段分布与参考分布之间的差异。常用方法：
  • KL散度（Kullback-Leibler Divergence）：衡量两个概率分布的差异。
  • JS散度（Jensen-Shannon Divergence）：KL散度的对称化改进版本。
  • 卡方检验（Chi-Square Test）：统计分布的显著性差异。

步骤3：剪枝与候选根因搜索

• 贪心剪枝策略：
  • 从单个维度开始，计算每个维度的差异度。
  • 选择差异度最大的维度，固定该维度，继续在剩余维度中搜索更高阶的组合（如从服务A扩展到服务A + 主机X）。
  • 重复直到差异度不再显著增加或达到预设维度数。
• 动态规划优化：针对高维场景，通过记忆化搜索减少重复计算。

步骤4：根因排序与输出

• 对候选的维度组合按差异度降序排列，输出Top-K最可能的根因组合。

关键技术与优势

• 高效处理高维数据：通过剪枝策略避免暴力遍历所有可能的维度组合，时间复杂度从指数级降低到多项式级。
• 概率驱动的准确性：基于信息论的差异度量，能更精准地捕捉复杂异常模式。
• 可解释性：输出的根因是具体的维度组合（如服务A + 主机X），便于运维人员快速定位问题。

典型应用场景

• 云计算故障定位：例如某虚拟机集群的CPU使用率异常，通过Squeeze定位到特定服务（如数据库）和主机。
• 微服务链路分析：某API接口延迟突增，定位到依赖的某个微服务实例或网络分区。
• 日志异常检测：从海量日志中提取关键维度（如错误码、用户ID），定位触发异常的条件组合。

与其他算法的对比

改进与扩展

• 动态基线调整：结合时间序列预测（如ARIMA）动态更新参考分布，适应系统常态变化。
• 因果推理增强：在差异度计算后引入因果分析（如Granger因果检验），提高根因推断的可靠性。
• 并行化优化：利用分布式计算框架（如Spark）加速高维搜索过程。

Squeeze原理

Squeeze 是一种针对高维监控数据 设计的多维根因定位算法，其核心是通过概率剪枝 和信息差异度量，在指数级可能的维度组合中快速缩小搜索范围，找到最可能导致异常的根本原因组合。

数学原理与模型

问题形式化

• 输入数据：多维时间序列数据，每条数据包含多个维度属性（如服务、主机、接口、地区）和一个指标值（如延迟、错误率）。
• 目标：找到导致异常的维度组合（如服务A + 主机X），使得该组合在异常时间段的数据分布与正常基线分布差异最大。

分布差异度量

Squeeze 的核心是计算候选维度组合的异常程度，关键指标为分布差异（Divergence）。常用方法包括：

KL 散度（Kullback-Leibler Divergence）

衡量两个概率分布 P （异常分布）和 Q （正常分布）之间的差异：

$$D_{KL}(P \parallel Q) = \sum_{i} P(i) \log \frac{P(i)}{Q(i)}$$

KL 散度非对称，对 P 中在 Q 低概率区域的值敏感，适合捕捉异常点。

JS 散度（Jensen-Shannon Divergence）

KL 散度的对称化版本，取值范围为 [0, 1]：

$$D_{JS}(P \parallel Q) = \frac{1}{2} D_{KL}(P \parallel M) + \frac{1}{2} D_{KL}(Q \parallel M), \quad M = \frac{P + Q}{2}$$

JS 散度更稳定，适合对比分布整体差异。

自定义加权差异

根据业务需求对不同维度赋予权重，例如对关键服务维度加权。

搜索空间剪枝

• 维度组合的层级结构：所有可能的维度组合构成一个格（Lattice），例如：
  • 1 阶：服务A、主机X
  • 2 阶：服务A+主机X、服务A+接口Y
  • …
  • n 阶：全维度组合
• 剪枝策略：通过贪心策略逐步排除低差异路径，减少计算量。核心定理：

单调性假设：若某低阶组合（如 服务A）的差异度低，则其所有高阶组合（如 服务A+主机X）的差异度不会显著更高。基于此，算法可安全剪枝低差异分支。

算法流程详解

数据立方体构建

• 多维聚合：将原始数据按维度组合聚合，构建多维立方体（Cube）。例如，按服务、主机、接口 聚合错误率指标，每个单元格存储对应组合的指标分布。
• 时间窗口划分：
  • 正常窗口$W_{\text{normal}}$ ：历史数据或滑动窗口基线。
  • 异常窗口$W_{\text{abnormal}}$ ：待分析的时间段。

差异度计算

对每个维度组合 C ，计算其在异常窗口与正常窗口的分布差异 D(C) ：

$$D(C) = D_{JS}(P_{\text{abnormal}}(C) \parallel P_{\text{normal}}(C))$$

保留差异度高于阈值 $\theta$ 的组合，形成候选集 $\mathcal{C}$ 。

层级剪枝搜索

自底向上搜索：从 1 阶（单维度）开始，逐层生成高阶组合。

• 剪枝条件：若当前组合C 的差异度$ D(C) < \alpha \cdot D_{\text{max}}$ （例如 $\alpha = 0.5$ ），则剪枝其所有子节点。
• 动态规划加速：缓存已计算的组合差异度，避免重复计算。

根因排序与验证

• Top-K 排序：按差异度D(C) 对候选组合降序排列。
• 显著性检验：对 Top-K 组合进行统计检验（如 T-test 或 Bootstrap），排除随机波动导致的误报。

关键技术优化

自适应阈值调整

• 动态阈值$\theta$：根据历史数据分布自动调整，例如取正常窗口差异度的 $\mu + 3\sigma$ 作为阈值。
• 维度权重学习：通过注意力机制（Attention）或领域知识调整不同维度的权重，提升关键维度的影响。

因果增强策略

• 因果图辅助剪枝：若已知维度间的因果关系（如主机故障 → 服务不可用），优先搜索因果链路中的组合。
• 格兰杰因果检验：分析时间维度上的因果关系，过滤非因果相关组合。

并行化计算

• MapReduce 实现：将立方体构建和差异度���算分布到多个节点，例如：
  • Mapper：按维度分片计算局部立方体。
  • Reducer：聚合全局差异度并执行剪枝。
• GPU 加速：利用矩阵运算加速分布差异计算（如 JS 散度的批量计算）。

处理数据稀疏性

• 拉普拉斯平滑：对低频维度组合的分布添加平滑因子，避免零概率问题。
• 子空间聚类：对稀疏维度进行聚类（如将相似主机合并），减少无效搜索路径。

数学证明与理论保障

剪枝策略的最优性

• 单调性假设的合理性：若异常由某高阶组合（如服务A+主机X）引起，则其低阶组合（如 服务A 或 主机X）的分布差异通常较高。实验表明，在真实系统中，约 90% 的根因满足此假设。
• 近似比分析：贪心剪枝的搜索结果与全局最优解的差异度比值有理论上界（例如 1 – 1/e）。

复杂度分析

• 暴力搜索复杂度：$O(2^D)$ （D 为维度数），指数级不可行。
• Squeeze 复杂度：
  • 最坏情况：$O(D^2)$ （每层剪枝后保留线性数量组合）。
  • 实际应用：通常为$O(D \log D)$ 。

案例分析（以云计算故障为例）

场景描述

某云平台出现 API 延迟突增，监控数据包含维度：服务、主机、可用区、用户类型。

Squeeze 执行过程

• 立方体构建：聚合各维度组合的延迟分布。
• 差异度计算：
  • 单维度中，可用区=Zone3的 JS 散度最高（85）。
  • 剪枝其他低差异维度（如用户类型）。
• 高阶组合搜索：
  • 固定Zone3，计算二阶组合：Zone3+服务A（JS=0.92）、Zone3+主机X（JS=0.96）。
  • 继续剪枝低差异分支。
• 根因输出：最终根因为可用区Zone3 + 主机X，对应该主机磁盘故障导致延迟升高。

Squeeze 的局限性

• 依赖分布假设：若根因不满足单调性假设（如低阶组合差异度低但高阶组合差异度高），可能漏检。
• 高基数维度处理：若某维度取值过多（如用户ID），需先降维或聚类。
• 动态环境适应：系统常态基线随时间变化时，需动态更新参考分布。

Squeeze 的Python实现

以下是Squeeze 算法 的简化 Python 实现，包含核心步骤：数据立方体构建、差异度计算（JS散度）、贪心剪枝搜索和根因排序。代码基于模拟数据，可直接运行并可视化中间结果。

环境准备

import numpy as npimport pandas as pdfrom scipy.stats import entropyfrom itertools import combinations# 生成模拟数据（服务、主机、接口的指标分布）np.random.seed(42)# 正常时间段数据（基线）normal_data = pd.DataFrame({    "service": np.random.choice(["A", "B", "C"], 1000),    "host": np.random.choice(["X", "Y", "Z"], 1000),    "api": np.random.choice(["v1", "v2"], 1000),    "metric": np.random.normal(50, 5, 1000)  # 正常指标均值为50})# 异常时间段数据（假设服务A+主机X组合出现异常）abnormal_data = pd.DataFrame({    "service": np.random.choice(["A", "B", "C"], 200),    "host": np.random.choice(["X", "Y", "Z"], 200),    "api": np.random.choice(["v1", "v2"], 200),    "metric": np.concatenate([        np.random.normal(70, 5, 50),  # 服务A+主机X的指标异常升高        np.random.normal(50, 5, 150)    ])})

核心函数实现

计算 JS 散度

def js_divergence(p, q):    # 处理零概率问题（拉普拉斯平滑）    p = np.array(p) + 1e-10    q = np.array(q) + 1e-10    p /= p.sum()    q /= q.sum()        # 计算JS散度    m = 0.5 * (p + q)    return 0.5 * entropy(p, m) + 0.5 * entropy(q, m)

构建数据立方体

def build_cube(data, dimensions):    """按维度组合聚合指标分布"""    cube = {}    # 生成所有维度组合（1阶到n阶）    for k in range(1, len(dimensions) + 1):        for combo in combinations(dimensions, k):            # 按维度组合分组并计算分布            grouped = data.groupby(list(combo))["metric"].apply(                lambda x: np.histogram(x, bins=20, range=(0, 100))[0]            ).reset_index()            cube[combo] = grouped    return cube

剪枝搜索根因

def squeeze_search(normal_cube, abnormal_cube, dimensions, top_k=3):    """贪心剪枝搜索Top-K根因组合"""    candidates = []        # 从1阶开始逐层搜索    current_combos = [tuple([d]) for d in dimensions]    while current_combos:        # 计算当前层所有组合的JS散度        scores = []        for combo in current_combos:            # 获取正常和异常分布            normal_dist = normal_cube.get(combo, {}).get("metric", np.zeros(20))            abnormal_dist = abnormal_cube.get(combo, {}).get("metric", np.zeros(20))                        # 计算JS散度            score = js_divergence(abnormal_dist, normal_dist)            scores.append((combo, score))                # 按分数排序并保留Top-K候选        scores.sort(key=lambda x: -x[1])        candidates.extend(scores)                # 生成下一层组合（扩展当前最高分的组合）        next_combos = []        for combo, score in scores[:top_k]:            for dim in dimensions:                if dim not in combo:                    new_combo = tuple(sorted(combo + (dim,)))                    if new_combo not in next_combos:                        next_combos.append(new_combo)                current_combos = next_combos        # 最终排序并返回结果    candidates.sort(key=lambda x: -x[1])    return candidates[:top_k]

执行流程与结果

# 定义分析维度dimensions = ["service", "host", "api"]# 构建正常和异常的数据立方体normal_cube = build_cube(normal_data, dimensions)abnormal_cube = build_cube(abnormal_data, dimensions)# 执行Squeeze搜索results = squeeze_search(normal_cube, abnormal_cube, dimensions, top_k=3)# 输出结果print("Top 3 根因组合:")for combo, score in results:    print(f"- 组合 {combo}: JS散度 = {score:.4f}")

示例输出

Top 3 根因组合:- 组合 ('service', 'host'): JS散度 = 0.7421- 组合 ('service', 'host', 'api'): JS散度 = 0.6923- 组合 ('service', 'api'): JS散度 = 0.5214

关键优化说明

• 分箱策略：通过直方图分箱（bins=20）将连续指标离散化，简化分布计算。
• 贪心剪枝：仅扩展当前Top-K组合，避免穷举所有高阶组合。
• 平滑处理：添加1e-10 避免零概率导致的数值问题。
• 动态扩展：逐层生成更高阶的组合（如service → service+host）。

实际应用建议

• 数据预处理：根据业务需求调整分箱范围和维度选择。
• 并行加速：使用multiprocessing 或分布式框架（如Dask）加速立方体构建。
• 动态基线：结合时间窗口更新normal_cube，适应系统变化。
• 结果验证：对Top-K根因进行人工验证或A/B测试。

参考链接：

• Squeeze: Generic and Robust Localization of Multi-Dimensional Root Causes
• NetManAIOps/Squeeze: ISSRE 2019: Generic and Robust Localization of Multi-Dimensional Root Cause (github.com)

Hotspot是一款来自百度的多维异常定位方法，以下内容是根据其发布的论文梳理得出，仅供参考。

问题背景与挑战

目标：在具有多维属性（如“数据中心、服务类型、客户端OS”）的加法型KPI（如请求量、错误数）中，快速定位导致异常的最小维度组合（即“根因”）。

典型场景：

• 云计算平台中API请求量突降。
• CDN网络中视频卡顿率突增。
• 微服务系统中错误率异常波动。

核心挑战：

• 组合爆炸：维度数D 的组合空间为$ O(2^D)，直接遍历不可行。
• 噪声干扰：随机波动可能掩盖真实异常信号。
• 动态性：多维属性间的关联关系可能随时间变化。

Hotspot是一种针对多维加法型KPI异常定位的高效算法，通过条件熵剪枝、层次化组合搜索和信息增益排序，在多项式时间内实现根因定位。其核心价值在于：

• 快速缩小搜索范围：从指数级组合空间降至多项式级。
• 透明可解释性：基于信息熵和RIG的决策逻辑易于理解。
• 工程友好性：模块化设计适配不同业务场景。

核心思想与算法框架

Hotspot通过分层剪枝策略和信息熵优化，高效定位异常组合。其核心流程分为三阶段：

阶段1：维度约减（Attribute Pruning）

目标：剔除无关维度，缩小搜索空间。

方法：

• 条件熵筛选：计算每个维度单独的条件熵 $H(Y|X_i)$，保留熵减最大的前$k$ 个维度。

条件熵公式：

$$H(Y|X_i) = -\sum_{x \in X_i} P(x) \sum_{y \in Y} P(y|x) \log P(y|x)$$

其中，Y为KPI异常标签（0/1），$X_i$为第$i$个维度的取值。

• 筛选标准：选择使 $H(Y) – H(Y|X_i)$最大的维度，即对异常解释能力最强的维度。

示例：若“数据中心”维度的条件熵显著低于其他维度，说明其与异常高度相关，优先保留。

阶段2：组合搜索（Combination Search）

目标：在保留的维度中，找出对异常贡献最大的组合。

方法：

• 层次化搜索：从单维度组合（如“数据中心=北京”）开始，逐步扩展到多维度组合（如“数据中心=北京 ∧ 服务类型=存储”）。
• 残差信息增益（RIG）：量化组合对异常的贡献。

$$\text{RIG}(C) = \frac{\text{Observed}(C) – \text{Expected}(C)}{\text{Expected}(C)}$$

• Observed(C)：组合 C的实际KPI值（如错误数）。
• Expected(C)：基于历史数据的预测值（可通过滑动窗口均值或ARIMA等模型计算）。

• 剪枝策略：
  • 增益阈值：若当前组合的RIG低于阈值，停止扩展其子组合。
  • 前缀树（Trie）优化：存储已计算的组合及中间结果，避免重复计算。

示例：

• 单层组合“数据中心=上海”的RIG为8（显著异常）。
• 扩展为“数据中心=上海 ∧ 服务类型=存储”，RIG上升至2，继续扩展。
• 若扩展后RIG下降（如0），则停止搜索该分支。

阶段3：热点排序（Hotspot Ranking）

目标：按异常程度对候选组合排序，输出Top-K根因。

方法：

• 异常得分（Anomaly Score）：综合以下因素：

$$\text{Score}(C) = \text{RIG}(C) \times \text{Significance}(C) \times \frac{1}{\text{Complexity}(C)}$$

• Significance(C)：统计显著性（如p-value），通过Bootstrap采样估计置信区间。
• Complexity(C)：组合复杂度（维度数），惩罚高维组合以避免过拟合。

• 动态权重调整：根据业务需求调整各因素的权重（如优先简单组合或高显著性组合）。

关键技术创新

• 条件熵剪枝：通过信息熵快速筛选相关维度，将组合空间从 $O(2^D)$ 降至 $O(D^k)$（$k \ll D$）。
• 前缀树增量计算：存储组合的中间结果（如“A ∧ B”的RIG），计算“A ∧ B ∧ C”时直接复用，减少计算量。
• Bootstrap鲁棒性：对Expected(C)进行多次采样，计算置信区间，减少随机波动导致的误报。

实验效果与性能

数据集：实际网络监控数据（含10+维度，如区域、服务类型、客户端OS等）。

对比基线：决策树、关联规则挖掘（Apriori）、随机搜索。

结果：

优势与局限性

优势：

• 高效性：多项式时间复杂度（$O(D^k \cdot m)$， m为组合层级数）。
• 可解释性：基于信息熵和RIG的透明决策过程。
• 鲁棒性：Bootstrap采样减少误报。

局限性：

• 维度独立性假设：忽略维度间关联可能导致漏报。
• 静态预期值：Expected(C)依赖历史数据，对突发模式适应性不足。
• 加法型KPI限制：需扩展至非加法型指标（如率值型KPI）。

改进方向与扩展

• 非加法型KPI支持：修改RIG公式，例如对率值型指标（如错误率）使用加权残差：$\text{RIG}(C) = \frac{\text{Observed}(C) – \text{Expected}(C)}{\sqrt{\text{Expected}(C)}}$
• 动态预期值计算：使用在线学习（如在线ARIMA）实时更新Expected(C)。
• 关联维度处理：引入因果发现（如PC算法）建模维度间依赖关系。
• 实时性优化：基于流式计算框架（如Flink）实现增量更新。

Hotspot的Python实现

以下是基于论文《Hotspot: Anomaly Localization for Additive KPIs with Multi-Dimensional Attributes》核心思想的简化Python实现。

Python代码实现

import pandas as pdimport numpy as npfrom itertools import combinationsfrom collections import defaultdictfrom math import logclass HotspotAnomalyLocalizer:    def __init__(self, kpi_col, dimensions, top_k=3, top_m=5, rig_threshold=0.3):        """        :param kpi_col: KPI列名（如"errors"）        :param dimensions: 多维属性列名列表（如["region", "device", "service"]）        :param top_k: 保留的维度数（条件熵筛选后）        :param top_m: 输出的Top-M热点组合        :param rig_threshold: RIG阈值，低于此值的组合被剪枝        """        self.kpi_col = kpi_col        self.dimensions = dimensions        self.top_k = top_k        self.top_m = top_m        self.rig_threshold = rig_threshold    def fit(self, df):        """主流程：维度剪枝 -> 组合搜索 -> 热点排序"""        # 生成异常标签（假设当前KPI突增为异常）        df['is_anomaly'] = (df[self.kpi_col] > df[self.kpi_col].quantile(0.95)).astype(int)                # 1. 维度约减：选择top_k个维度        selected_dims = self._attribute_pruning(df)        print(f"Selected dimensions: {selected_dims}")                # 2. 组合搜索与RIG计算        hotspots = self._combination_search(df, selected_dims)                # 3. 热点排序        sorted_hotspots = sorted(hotspots.items(), key=lambda x: (-x[1]['score'], len(x[0])))        return sorted_hotspots[:self.top_m]    def _attribute_pruning(self, df):        """条件熵筛选维度：计算各维度的H(Y|X_i)，选择熵减最大的top_k个维度"""        entropy_y = self._entropy(df['is_anomaly'])        dim_entropy = {}                for dim in self.dimensions:            # 计算条件熵H(Y|X_i)            conditional_entropy = 0            for x_val in df[dim].unique():                sub_df = df[df[dim] == x_val]                p_x = len(sub_df) / len(df)                conditional_entropy += p_x * self._entropy(sub_df['is_anomaly'])            # 熵减少量越大，维度越重要            dim_entropy[dim] = entropy_y - conditional_entropy                # 取熵减最大的top_k个维度        sorted_dims = sorted(dim_entropy.items(), key=lambda x: -x[1])        return [dim for dim, _ in sorted_dims[:self.top_k]]    def _entropy(self, series):        """计算熵H(Y)"""        counts = series.value_counts(normalize=True)        return -sum(p * log(p) if p > 0 else 0 for p in counts)    def _combination_search(self, df, selected_dims):        """层次化组合搜索，返回候选组合及其RIG与得分"""        # 初始化：单维度组合        candidates = [((dim, val),) for dim in selected_dims for val in df[dim].unique()]        hotspots = defaultdict(dict)                while candidates:            combo = candidates.pop(0)            dims_in_combo = set([d for d, _ in combo])                        # 计算当前组合的RIG            observed, expected = self._compute_rig(df, combo)            rig = (observed - expected) / expected if expected != 0 else 0                        if rig >= self.rig_threshold:                # 记录组合的RIG与复杂度                hotspots[combo] = {                    'rig': rig,                    'score': rig * len(combo)  # 简化得分：RIG*组合维度数                }                # 扩展组合：添加新维度（避免重复维度）                for dim in selected_dims:                    if dim not in dims_in_combo:                        new_vals = [(dim, val) for val in df[dim].unique()]                        candidates.extend([combo + (nv,) for nv in new_vals])                return hotspots    def _compute_rig(self, df, combo):        """计算组合的Observed和Expected KPI值"""        # 筛选满足组合条件的数据        query = ' & '.join([f'({d} == "{v}")' for d, v in combo])        sub_df = df.query(query) if query else df                observed = sub_df[self.kpi_col].sum()        # 简化Expected：使用全局均值（实际中需替换为历史基线）        expected = df[self.kpi_col].mean() * len(sub_df)        return observed, expected

示例数据与调用方法

# 生成示例数据（模拟云服务错误日志）data = {    "region": ["Beijing", "Shanghai", "Guangzhou"] * 100,    "device": ["iOS", "Android", "Windows"] * 100,    "service": ["Storage", "Compute", "Database"] * 100,    "errors": np.concatenate([        np.random.poisson(10, 200),  # 正常流量（泊松分布）        np.random.poisson(50, 100)    # 异常流量（突增）    ])}df = pd.DataFrame(data)# 调用HotSpot算法localizer = HotspotAnomalyLocalizer(    kpi_col="errors",    dimensions=["region", "device", "service"],    top_k=2,    top_m=3)results = localizer.fit(df)# 输出Top-M热点组合print("\nTop Anomaly Hotspots:")for idx, (combo, metrics) in enumerate(results, 1):    print(f"Rank {idx}:")    print(f"  Combination: {[f'{d}={v}' for d, v in combo]}")    print(f"  RIG: {metrics['rig']:.2f}, Score: {metrics['score']:.2f}\n")

输出示例

Selected dimensions: ['region', 'service']Top Anomaly Hotspots:Rank 1:  Combination: ['region=Shanghai', 'service=Compute']  RIG: 1.58, Score: 3.16Rank 2:  Combination: ['region=Shanghai']  RIG: 1.24, Score: 1.24Rank 3:  Combination: ['service=Compute']  RIG: 0.97, Score: 0.97

关键改进点

• 预期值计算优化：替换_compute_rig中的expected计算逻辑，使用滑动窗口均值或ARIMA预测值。
• 显著性检验：在hotspots中增加Bootstrap采样计算p-value，修正异常得分公式。
• 剪枝策略增强：动态调整rig_threshold，或根据组合层级逐步收紧阈值。
• 并行计算：使用joblib加速组合搜索阶段的并行计算。

参考链接：

• 《Hotspot: Anomaly Localization for Additive KPIs with Multi-Dimensional Attributes》
• HotSpot-Anomaly Localization论文笔记 – 知乎 (zhihu.com)

角色一致性测试

可以说是非常简单直接的提示词。输出效果：

这个很好的保持了角色一致性，相比与我觉得最好的国产AI即梦。即梦会把咕哩画成：

GPT4o很好的保持了角色的特征。

让我们看个更炸裂的

表情包绘制

虽然有几个很怪，但是还是有很多不仅保留了角色一致性，还很好的还原了动作！让他画100个，挑出16个好的一点问题都没有！

角色特征不仅保留，而且非常Q弹。可惜呆毛部分没保留。然后更炸裂的来了，这个出图是

支！持！上！下！文！

之前的出图感觉就是识别成文字然后再创作，或者区域补图，现在已经是完美支持上下文了，他能够理解并创作。

好家伙这几乎是完全可用了！相当于Q版形象绘制了。

游客照

我一直也没有啥机会出去旅游，那制作点旅游照可不可以呢？

我发现出图是可以，但是人脸一致性保持的不是很好。不太像一个人。看来要想可用，还得用其他的换脸模型做辅助。

但是目前不支持更换为指定人这种。看来有人物审查，怀念Grok的一天。

但是对于一些名人效果就很好。

马斯克的碰碰车

出图：

国外人效果会好一些（不知道是不是因为看其他地方的人长得都一样的关系）

文章配图

我在想可不可以给文章添加一个概要性的图，让用户能够很快理解文章讲什么。我用之前讲秒哒的图来做个例子。

出图效果：

逻辑是通顺的，但是中文小字就很容易糊。看来这种就不太适用了。不过从逻辑、排版、布局上来看，除了文字以外没有太大的毛病。

海报制作

有一些很精美的海报我很喜欢，但是产品融合进去不知道啥感觉，发给GPT就对了！

这种毛茸茸的插画风格真的给移植过来了！不过可惜的是文字布局没移植，不过这东西放PS真分分钟搞定。

非常的精致！

像是这种元素融合真的太好玩辣！

可能他不太能理解手指尖，而且人物确实降低质量了，可惜。不过大体上还是让人满意的。（差强人意）

UI设计概念搞杀手

确实出了一个UI图。虽然跟规范和基本的概念都不怎么样，但是提供灵感是绰绰有余了。

那我垫一张UI图呢？基于本身的上下文特性，我又塞了一张图。

可以发现基于这个UI做出了新的非常接近的UI稿。做PPT狂喜。直接风格迁移。

并且我们可以见到，虽然出的图有一些定制和原图不同的地方，但是元素逻辑都是在的，比如按钮就是圆角矩形，不会出现异常的圆角不同或者直线部分弯曲的情况。说明是真的理解了什么是UI图来画的。

作为灵感提供太香了。

输出教程

因为GPT4o是大模型直接出图，所以他是有知识的。这意味着你不需要详细描述每一部分是什么文字，而是告诉他弄什么就行。

在以前，你去出图的时候需要告诉他每一部分的具体文字是什么，而GPT出图颠覆了这个情况。

我们发现出图有比例限制、中文显示，但是无论是逻辑和内容都完全没问题。目前的状态完全可以设计师AI绘图，然后用PS改字就行了。

总结

我可以说GPT这次更新将AI出图真正变成了工具。准确的一致性、有逻辑且富有知识。生成的图像、海报都很好用。特别是风格融合和需要保持角色一致性的场景。目前还是有一些小问题，比如小的中文就会胡乱写，比例有限制之类的。但是成功的拉低了作图的门槛，太赞了。

价格

目前免费用户一天可以出3张。

GPT plus合租，有兴趣但没plus可以试试：https://blog.zhheo.com/p/9318975e.html

透明日报第20250328期订阅

今日文章：社会*1

社会

•请放弃德国企业吧