作者: paul

AI對產業

AI對產業

By | | Comments 0 Comment

清晨七點，我跟朋友聊起了 AI

今天早上七點，我傳了一張圖給朋友。

「哇勒」，他回。

然後我們聊了半小時。

我發現的事

這陣子我瘋狂投入 AI，不是因為好玩，是因為被逼的。

我們老闆現在要求產品用「月」計算。以前我們是用「季」的，還不一定做得出來。時程報出去被電，我被迫要學。

但學著學著，我發現一件很扯的事——

AI 就像可以隨插即用的晶片。

以前我們學東西，受限於人腦的學習速度。但現在，想裝什麼能力就裝什麼晶片。寫程式、做簡報、建網站、串 API——只要是數位化的東西，AI 都能幫你接上。

用講的就好。

朋友問我成本

「整體串起來，建置成本是我們這種小企業吃得消的嗎？」

我說，單純 AI 大腦這件事，就是人加電腦就解決了。

AI 一個月 100 美元，等於請一個教授級的秘書。而且這個秘書會開發。技能流程串好的話，開發品質也顧得了。

你等於用 AI 又請了一個軟體團隊。

但真正讓我思考的是這件事

他說說：「這樣公司一用，他的位置不就消失？」

他說的是另一個朋友，傳產的資訊部門主管。

我說，對，終極來看是這樣。所以才要搶先機。

舊的東西如果沒有數位化，AI 也沒辦法幫你串起來。而有些「人」，就是那個舊的東西——傳統流程上的人，都是。

當上面發現國外都在做了，就會開始緊張。

我們只是提前看見變化而已。傳產沒那麼快，但搞不好下一個十年，很多東西會不見。

那我的小孩呢？

這也是我最近在想的——我小孩以後要幹嘛？

我想了想，結論是：至少要有學習的能力。

因為我想到我媽。就算給她插上這個晶片，她可能也無感，因為她不想做什麼了。

但如果是想做些什麼的人，70 歲也可以創業。

寫在最後

今天清晨七點的這段對話，讓我把最近的焦慮和興奮都說出來了。

AI 不是未來，是現在。

不是會不會影響你，是什麼時候輪到你。

而我能做的，就是在被淹沒之前，先學會游泳。

2026.01.25 清晨隨筆

我是AI公司總經理的一天？

我是AI公司總經理的一天？

By | | Comments 0 Comment

前兩篇寫完之後，我一直在想一個問題。                                                                                                             

AI把開發的執行面接走了，那我們到底在幹嘛？                                                                                                   

很多人說「要創業」、「要轉型」，但我覺得這個答案太遠了。不是每個人都要離職開公司，但每個人確實都在經歷一個轉變——你已經在經營一間公司了，只是掛的還是原本的職稱。                                                                                                                                                                                                                             

外包這件事，換個角度想                                                                                                                                          ,                                                                                                            

上一篇我提到，Claude Max 100美元的訂閱費下，AI Agent可以外包掉50%以上的日常工作了。                                                                                         

  但換個角度想：如果工作可以被外包，那你也可以當那個外包公司的人。                                                                                                                                                                                                             

  差別在於，以前外包是包給別人，現在是包給你的AI團隊。你不是被取代的那個，你是接案的那個。                                                                                                                                                                                     

  只是這間公司目前員工都是AI，而總經理是你。                                                                                                                                                                                                                                   

  —                                                                                                                                                                                                                                                                          

  半年後的某一天                                                                                                                                                                                                                                                               

  我想像了一下，半年後的某個早上，身為「保羅公司」的總經理（對，我還是在原本公司的RD），日常大概長這樣：                                                                                                                                                                       

  起床先看財報。                                                                                                                                                                                                                                                               

  昨天我的AI員工花了多少錢？跑了幾個Claude session、call了多少API、處理了幾張ticket。成本多少，產出價值多少，有沒有超載或閒置。                                                                                                                                                

  然後開Daily。                                                                                                                                                                                                                                                                

  不是我報告，是請AI秘書先整理好：                                                                                                                                                                                                                                             

  – 今天Jira上有什麼要處理的                                                                                                                                                                                                                                                   

  – 有沒有線上議題                                                                                                                                                                                                                                                             

  – 有沒有客戶問題進來                                                                                                                                                                                                                                                       

  – 昨天的PR review結果怎樣                                                                                                                                                                                                                                                    

  整理完，我再決定今天的優先順序，哪些讓AI繼續跑，哪些我要介入。                                                                                                                                                                                                               

  這跟以前的Daily有什麼不同？                                                                                                                                                                                                                                                  

  以前Daily是「我今天要做什麼」。                                                                                                                                                                                                                                              

  現在Daily是「我的公司今天要交付什麼」。                                                                                                                                                                                                                                      

  深度不一樣了。                                                                                                                                                                                                                                                               

  —                                                                                                                                                                                                                                                                          

  你的公司規模決定你能接什麼案                                                                                                                                                                                                                                                 

  以前評估一個人的能力，看的是技術深度、經驗、能寫多少code。                                                                                                                                                                                                                   

  現在要多看一個維度：你的AI公司規模。                                                                                                                                                                                                                                         

  你會不會接案？從Jira上那麼多ticket，你怎麼挑？                                                                                                                                                                                                                               

  你會不會控成本？AI不是免費的，花太多但產出沒跟上，你的公司就是虧損。                                                                                                                                                                                                         

  你會不會報成果？跟平常Daily一樣，但現在你報的是你整間公司的產出。                                                                                                                                                                                                            

  如果你沒有把自己「公司化」的能力，說實話，不太會分配太複雜、太有價值的工作給你。                                                                                                                                                                                             

  因為風險太高。你的產能天花板就是你一個人，而旁邊那個有AI團隊的人，他的天花板比你高太多了。                                                                                                                                                                                   

  —                                                                                                                                                                                                                                                                          

  履歷會變成什麼樣子                                                                                                                                                                                                                                                           

  我在想，以後的履歷可能不只是寫「我會什麼技術」、「我做過什麼專案」。                                                                                                                                                                                                         

  可能會變成：                                                                                                                                                                                                                                                                 

  – 你的AI團隊配置是什麼？                                                                                                                                                                                                                                                     

  – 你的公司能承接多大規模的案子？                                                                                                                                                                                                                                             

  – 你用什麼訂閱等級(資本額多少)？                                                                                                                                                                                                                                                         

  當然，買越多不等於產出越多。Max訂下去，不代表你就一定比較變強。                                                                                                                                                                                                           

  但中間那個gap，就是你創造價值的空間。                                                                                                                                                                                                                                          

  同樣的工具，有人能跑出1,200個commits的產出，有人只能跑出一堆沒用的對話。差別在哪？在於你怎麼指揮、怎麼設計流程、怎麼定義價值。                                                                                                                                               

  —                                                                                                                                                                                                                                                                          

  不是只有創業這條路                                                                                                                                                                                                                                                           

  很多文章都在講「AI時代要創業」、「要當自己的老闆」。                                                                                                                                                                                                                         

  但我覺得，不用想那麼遠。                                                                                                                                                                                                                                                     

  你現在就可以用你的名字，在公司內創業。                                                                                                                                                                                                                                       

  想像一下，一堆人在Daily的時候，其實就像是一堆小公司在談一個大案子。大家還是要討論怎麼切、怎麼做、誰負責什麼。                                                                                                                                                                

  但評估的維度變了。不是只看「你的能力」了，還要看「你的公司能扛多少」。                                                                                                                                                                                                         

  這是一個新的想像空間。不用離職、不用創業，但你確實在經營一間公司。                                                                                                                                                                                                           

  —                                                                                                                                                                                                                                                                          

  所以，開發人員會被取代嗎？                                                                                                                                                                                                                                                   

  這個問題問錯了。                                                                                                                                                                                                                                                             

  應該問的是：你是被外包的那個，還是接外包的那個？                                                                                                                                                                                                                             

  AI時代的競爭，不是人vs AI。                                                                                                                                                                                                                                                  

  是「有AI公司的人」vs「沒有AI公司的人」。                                                                                                                                                                                                                                     

  你的公司開張了嗎？                                                                                                                                                                                                                                                           

一日Claude 操作員心得

一日Claude 操作員心得

By | | Comments 0 Comment

從昨天那篇 https://paulfun.net/wordpress/?p=4363 的Claude Max訂閱衝下去後，我開始思考這麼大的使用量，到底能用在開發的哪邊。

一開始Cli 開始請他做好多個skills，整理組內的PR流程，甚至可以依 執行PR的角度 做Level1, Level2的PR Process，既然要AI開發，那我們就要用AI思維跟流程，再對AI做PR，解決Code Level的問題，而AI + MCP +Skill讓 這整個體驗真的可以在幾句話間無縫感的完成了所有的事情，甚至 其他人類回的PR Comment再請他拉下一起評估要怎麼修改，這個都可以變成是一站式的在Cli完成。不過 這當 中 我發現，人類 可以切入的點是Spec PR，因為我請他做A, 做B，做C，但我”有可能”沒想到D，但這其實是人類 Spec一開始也沒有被Review的問題，這個未來在AI Spec也開始被”外包”的時候 ，我想也一樣是可以有機會AI就自已可以循環解決掉的問題了。總而言之，AI思維下，大家Mindset要開始轉換，我們RD在2028年的時候，可能有一部分都是Claude AI 的操作員了 XD。當然 AI基礎建設跟權限開放管理就也會是合理想象的公司組織的管理議題。

接著我又想到，適逢要績效考核，既然有Jira跟Azure Devops MCP，我請他試著用我的名字跟帳號，整理2025年的整個工作摘要跟統計。同時我趁這個AI研究拉資料的過程中，順便跟他Pair一份 公司部門級別的YearReview Skills

成果如下:

DevOps Commit 貢獻分析

1. XXXX-Fxxm 專案

1.1 XXXX-Api (後端 API 開發)

月份Commits 數量新增檔案編輯檔案刪除檔案
2025-01801110
2025-0240296670
2025-031201348344
2025-041001229530
2025-0551446020
2025-061811091,15411
2025-08160270
2025-091112476314
2025-101621598640
2025-112111601,4770
2025-12200+3008360
年度總計1,200+1,304+8,156+19

分析說明:

  • 全年度在 BackendApi 專案貢獻超過 1,200 次 commits
  • 編輯檔案變更超過 8,000 次，顯示大量的功能開發與維護工作
  • 3月、6月、10月、11月、12月為高產出月份，顯示專案交付週期的節奏
  • 持續穩定的貢獻，無明顯的工作中斷期

1.2 XXXX-WebAdmin (後台管理系統)

月份Commits 數量新增檔案編輯檔案刪除檔案
2025-093521231518
2025-102324582
2025-112915733
2025-121310230
總計10026146923

分析說明:

  • 9月份開始投入 WebAdmin 開發，顯示新功能模組的開發
  • 新增檔案數量較多，表示建立新的功能架構
  • ….略

Jira的部分也示意一下

整份報告洋洋灑灑8大區塊就不說了，但確實都可以請AI做到位了。他還同時針對重要的git message去做分類分析，太Rough的請他要統一分類到別的地方，JIRA也一樣。看到這邊，我想雖然這個commit或單子的數量不一定能代表一個人完整的工作表現，但是卻是真實數據對齊的一種方式。人在哪裡，管理就要到哪裡 ~

第3的部分，就是AI我昨天比諭是FSD自動架駛，但我現在更抽象的想象是我們執行了”外包”。而且這個外包感受跟之前常聽到的，美國工程師用多少美元，把自己年薪20w美元的工作用3w美元把開發外包到印度去，然自己只要開會跟在夏威夷度假跟遠端確認 工作結果的故事一樣。現在我們不就是站在這個風口浪尖嗎？現在來說就是100美元，就可以外包掉 50%以上的日常工作，那為什麼人們會覺得這個100美元花不起？我現在想象，只要公司的環境/資安允許，那麼這些都將會讓 人們開始變成價值提供者，專業以人分工會變的極端不重要，昨天也講到 前端後端都會變成產品端，產品端，銷售 端，可能會變成直面市場挑戰，這個是可以預見的改變，所以我也試著在新專案中，準備開始訂好Spec-Kit的Skills，接著直接請他開始 針對舊專案好的部分，我想保留的部分，簡單陳述一下，需要測試，要有目錄結構，專案名稱要怎麼命名等，一行的prompt在彈指之間，他就幫我創立好了一個完整的專案目錄架構，還幫你編譯檢查過，新專案一鍵生成如下圖。

最後，講一個有趣的撞牆後才慢慢打破的想法。我自已是IDE時代出身的，所以對於 Visual Studio跟Rider還有 後來出的Cursor其實都是有其熟悉性(慣性)的，後來雖然對不同的技術科目，有開始學習像是VIM，Bash, Docker , Linux等Command line，但往往 在不同的Context 下我會需要記憶跟切換 context反而造成”不舒適”區，而Cli在我發現他”仍然”可以用Bash跟Vim的時候，一開始覺得是狂喜。過不久就發現，Cli上的Bash跟Vim雖然是讓你可以操作作業系統跟編輯長prompt更方便 ，但我發現，在Cli上，你其實更要直覺得直接請他做什麼事，而一直在怎麼做上面，去做思考成本。舉例來說，一開始我們啟動Cli的時候，通常你都會在”家目錄”(~/{user}/)。你的DEV目錄可能在~/DEV/xxxxxx-API，下面可能有好多個repo，往往 在這個只有一兩層的時候，我慣性的會想用 cli去切cd跟切 目錄，而在bash上，切換這個對我們的直覺來說，是快的，而且目錄名稱太長的話，也可以用上下切換跟tab來提示，這麼自然不過的場景，在Claude Cli的Bash(!)模式，竟然沒有，雖然不確定是刻意拿掉還是怎樣，導致我在前期時，常常在prompt模式下，打 ls，然後我又想下 bash，所以又切去bash想要切到開發目錄做事，這種日常的切換 超級鎖碎，後來想打破這個慣性，我突然發現，其實我們只要跟他好好講，拋棄那些什麼os/bash/目錄結構的記憶框架。就跟他說 切換到 xxx yyy api的專案，他就會去幫你達成。這個小小的慣性突破，雖然小，但總覺得對我來說也是一個有趣的發現。

就這樣，一天過了，token還用不完，一樣的有新的idea跟感受的話，再分享吧~或許哪一天這些過程也變的不重要了，就跟水龍頭一樣來的自然~那時我就真的是個操作員了

心得: AI Claude Max就這樣訂下去了

心得: AI Claude Max就這樣訂下去了

By | | Comments 0 Comment

2025年底才剛分享慢慢上手的Cursor+MCP，慢慢上軌道後，沒想到過1個月，AI的進步感又讓人有全面腦洞大開的感覺！

主要是看到別人的分享大多是，放著讓 Claude ai去工作，自己跑去打球還是做別的事情時，回來他已經做好了。而且還可以邊運動的時候，叫他再接著做什麼.. 仿彿真的可以給ai他們在背景做事情了？

很多人都是分享了這樣的結果，而不講過程，讓人著實覺得納悶與好奇。

最近被專案產品壓著時程跑，讓人不禁覺得應該快點成為先行者來試。

所以就這樣再跳下去Claude的懷抱 (這時我同時已經有chatGPT pro, gemini pro, Cursor pro的訂閱)

除了MCP外，另一個好奇的就是Skills是什麼。正巧用這個機會來玩看看

先看完了幾個影片解釋，Skills似乎是一個更泛用，且使用方式更靈活的MCP(因為就是 一堆文字 跟提示)

比起 MCP協定的背後，是固化的流程，文字就有調整的彈性，且有辦法做到一定的結構性。(比起提示詞過度抽象)，skills就是更有結構化且具備 擴充性的提示詞分類工程(初步想法)

MCP讓 AI具備了權限，而Skills讓他有了流程跟領域的知識(吧？)

就這樣，我買了5x的Max Plan，開始試著讓他建立Skills

原本我是想整理像是C#，dotnet core的準則，結果跟Claude來回問答後，他創建的skills的file廣又周全

而且可以請他先在專案下/init，讓他瞭解你的專案後，再去做規劃會更接地氣(說到這個claude cli是真正解放AI的其中之一要素，因為他一定程度的可以執行bash，跟os層深度的串接，有風險，但報酬也很高)

AI就這樣來來回回，他已經一定程度的幫我建好了dotnet expert的skills，後來我也把pull request and code review的skills建立起來，這個過程中，我也試著確認，我若貼上我們的jira跟ado(azure devops)的網址，claude有沒有辦法知道 我想叫他做什麼，然後試圖用他的能力(skills)做事

就這樣，我貼上了我們teams的pr link(cursor可以發pr)，進一步請他審pr ，這個Cli跳出驗證授權後，他就這樣去進行了pr流程，而且很聰明的問我，local repo在哪邊，他自已會去那邊用 git指令 查詢差異，再進行code review，最後，他自動發了PR Comment，全程不用開browser

範例如下:

後續，我拿這個小小的PR，再請 AI試著針對AI的PR去Checkout branch，試圖修正，而在Cli指令的過程中。他也在我的local自然的做完了這一連串我給 他的任務。(他真的可以幫我創建branch後去修正，絲滑的融合)

先到這邊，與其探討AI到底能不能Code review 好 自己的程式品質，skills或所謂的提示詞工程我們到底要投入多少心血，還是我們要學習怎樣給 出精準的工程知識(這個可以另外討論)，但這個階段突顯的其實是AI有辦法真正意義的整合了我們在電腦端的工作流。以前IDE是這樣的角色，現在OS級更大更強更自然的融合了。

舉個有趣的比喻。我們沒有開特斯拉，卻開始在軟體開發中先體驗了FSD(特斯拉的自動駕駛軟體)的感覺。

小提一下，也立一個Flag

我自己架的gcp + php.blog + docker + mariadb，以往 這些技術在linux，container ，php等技術名詞上是有割裂感的(上版還要用ssh)

我必須要一直context switch才能做到一定程度的價值流程，但每個技術我原本都只懂一點點，所以我也一直跳不出那一步。而現在或許我可以期待我某個週末可以透過某個嘗試互動後，可以讓 AI瞭解我的cloud，進而做的到幫我架站，架 docker，佈署。而我本地開始 接入我的多個應用的版控後，這生態系會開始解放我的想象能力。

看著保哥做的給小孩用的練習app，有想象力+執行力

https://99.gh.miniasp.com/

https://stroke.gh.miniasp.com/

更讓我有這個有趣切入點的想象，我或許也可以做出我的應用艦隊，敬請期待？

綜合以上的體驗，有幾個小Insight

  1. 工程師 要開始 把流程 整合，從個人，團隊，部門到全公司，看有沒有辦法建立可以讓 AI友善的開發環境，是我們立即要做的，就算是個人創業，要開始試著做才有辦法有想法有回饋去把路打通，而不是停在規劃跟計劃，你要把路打通，也是要投入跟投資的。比起100人 + 分散的使用AI打散戰力，也要想想如何投資在AI友善基礎建設上，這個是個人要發揮超越個人以上的影響力的絕佳戰場。
  2. 未來工程分界職能可能不會再用技術細分了，而是以價值流程定義，前端跟後端跟自動化QA可能都叫做產品端。在可見不遠處的未來，甚至都是AI在執行，而我們只是請AI專業地執行我們要的價值點，我們更多的在指揮。注意，不代表我們不需要有想法，專業跟深層的基本原則反而是AI其實會幫你懂，而你要關注的是價值跟品質(有朋友說其實這就是讓 工程師慢慢變成慣老闆XD)。但這個意思並不是說技術完全不重要。其實目前大部分跟半年前對AI改變我們工程的領悟一樣，只是現在是連”技術”是什麼都會被淡化了，是GO, 是Python, 是C#，還是Playwright，都不是要鑽牛角尖的東西，也不是有標準答案的東西了。
    • 舉個例，半年前我可能會覺得 可以學一下Playwright，可以讓ai跟著你做自動化測試，而現在是你要做確認，AI會開瀏覽器幫你做測試，而你要告訴他做什麼，他就是可以幫你探討並執行完成測試任務，他背後用的playwright來精準定位element，還是其他方案。這個趨勢看到的不是你具備playwright(或任何技術)的理解或撰寫能力了，這些技術在你的履歷上會變成一文不值。而產品跟你的想法價值，成功案例，才會是人的加分項。
  3. 沒有投資 AI的人/組織，將極大機會被已經AI 友善化 的組織淘汰，而無法接到組織的能力放大器上的人也會被淘汰，所以組織要想辦法做出可以放大能力的基礎ai友善的環境。反之，有AI整合能力的人，在組織偏傳產(就算是軟體公司也可能是傳產level)，他會逐水草 而居，去尋求更能放大 他能力 的地方 ，我覺得這也會是一個趨勢。

暫時先這樣，或許3個月後，又會刷新三觀了~到時再來看看有沒有什麼新的想法吧~~

Cursor + MCP 初體驗

Cursor + MCP 初體驗

By | | Comments 0 Comment

很多時候都是透過痛點(啊雜點)來激勵自己發想工具

今天想試試看，如何 透過 cursor 快速串接azure devops發pr，以前透過FORK才有快速串PR的方法

很想試試看同事口中的自動發PR是怎麼回事

雖然知道技術怎麼做到的，但要怎麼讓AI在我們的開發環境做的完整 到真的沒試過

我很快地在AI Chat 中 描述了我的意圖

1.我要透過AzureDevOps的串接方式(我已知要PAT : Personal Access Token)

2.我要請AI Agent協助我生成相關的PR資訊

3.請自動幫我組成請求發到AzureDevOps的Api去生成PR

但過程我希望有一些規則(例如PR標題/檔案清單/更改目的)

很快的，我取得PAT以後，告訴我的LocalAI，他很快的survey到AzureDevOps的 PR EndPoint

從 local clone下來的Repository，AI其實有辦法知道你對齊的是哪一個remote Repository

接著他生成了一段Python語法，幫我把上面的程序，組裝成了自動化Process

我原本以為這樣就有點MCP的概念了，但後來想想我還沒掛上Cursor的MCP，且run一段程式

是自動化 ，這樣距離 MCP有多遠呢？

詢問了AI以後

他幫我整理成了以下的MCP Server Code，並產生了 MCP Setting

MCP Server 

import os
import sys
import json
import base64
import urllib.request
import urllib.error
import subprocess
import ssl
from typing import Optional
from mcp.server.fastmcp import FastMCP

# Initialize FastMCP Server
mcp = FastMCP("AzureDevOps-Agent")

# Constants
ORG = "{OrgName}"
PROJECT = "{TeamProject}"
REPO = "{CodeRepository}"
API_VERSION = "7.1"

def get_pat() -> str:
    """Retrieve ADO PAT from environment or .ado_token file."""
    pat = os.environ.get("ADO_PAT")
    if pat:
        return pat
    
    # Fallback to local file
    token_path = os.path.join(os.getcwd(), ".ado_token")
    if os.path.exists(token_path):
        try:
            with open(token_path, "r", encoding="utf-8") as f:
                return f.read().strip()
        except Exception:
            pass
    
    raise ValueError("ADO_PAT not found in environment variables or .ado_token file")

def get_current_branch() -> str:
    """Get the current git branch."""
    try:
        return subprocess.check_output(["git", "rev-parse", "--abbrev-ref", "HEAD"]).decode("utf-8").strip()
    except Exception as e:
        raise RuntimeError(f"Failed to determine current branch: {str(e)}")

@mcp.tool()
def create_pull_request(title: str, description: str, target_branch: str = "main", source_branch: Optional[str] = None) -> str:
    """
    Create a Pull Request in Azure DevOps.

    Args:
        title: The title of the PR.
        description: The full description of the PR (markdown supported).
        target_branch: The branch to merge into (default: main).
        source_branch: The source branch (default: current git branch).
    """
    try:
        pat = get_pat()
        actual_source = source_branch if source_branch else get_current_branch()

        url = f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/git/repositories/{REPO}/pullrequests?api-version={API_VERSION}"

        # Format refs
        src_ref = actual_source if actual_source.startswith("refs/") else f"refs/heads/{actual_source}"
        target_ref = target_branch if target_branch.startswith("refs/") else f"refs/heads/{target_branch}"

        payload = {
            "sourceRefName": src_ref,
            "targetRefName": target_ref,
            "title": title,
            "description": description
        }

        # Auth header
        auth_str = f":{pat}"
        b64_auth = base64.b64encode(auth_str.encode()).decode()
        
        headers = {
            "Content-Type": "application/json",
            "Authorization": f"Basic {b64_auth}"
        }

        # SSL Context (Bypass for compatibility)
        ctx = ssl.create_default_context()
        ctx.check_hostname = False
        ctx.verify_mode = ssl.CERT_NONE

        req = urllib.request.Request(url, data=json.dumps(payload).encode(), headers=headers, method="POST")
        
        with urllib.request.urlopen(req, context=ctx) as response:
            response_data = json.loads(response.read().decode())
            pr_url = response_data.get('url', '').replace(
                f'_apis/git/repositories/{REPO}/pullrequests/', 
                f'_git/{REPO}/pullrequest/'
            )
            return f"Successfully created PR #{response_data.get('pullRequestId')}: {pr_url}"

    except urllib.error.HTTPError as e:
        error_body = e.read().decode()
        return f"Failed to create PR. HTTP {e.code}: {error_body}"
    except ValueError as e:
        return f"Configuration Error: {str(e)}"
    except Exception as e:
        return f"Unexpected Error: {str(e)}"
Ｄ
@mcp.tool()
def get_staged_diff() -> str:
    """
    Get the git diff of staged changes (cached). 
    Use this to analyze changes before generating commit messages or PR descriptions.
    """
    try:
        # Run git diff --cached
        diff_output = subprocess.check_output(["git", "diff", "--cached"]).decode("utf-8")
        if not diff_output:
            return "No staged changes found."
        return diff_output
    except Exception as e:
        return f"Error reading git diff: {str(e)}"

if __name__ == "__main__":
    mcp.run()


//MCP Setting
{
  "mcpServers": {
    "{org-team自行代入}-ado": {
      "command": "tools/mcp/.venv/bin/python",
      "args": ["tools/mcp/ado_mcp_server.py"]
    }
  }
}

MCP 啟用後的樣子(他可以是local的process，也可以是遠端的server)
透過MCP Setting，是提供AI的Model知道我們有哪些工具庫可以使用

他的PR寫的真漂亮

一開始不清楚 MCP 的具體用途，以為它只是讓企業把自己的資料打包給 AI 後提供服務。後來才發現 MCP 的本質其實是一個協定。

MCP（Model Context Protocol）是一種 protocol，讓 AI model 能透過這個協定與其他 model 或系統進行交互。核心依然是 API，只是這組 API 是「給 AI 用的」，讓 AI 能理解你的產品程式該怎麼操作，進而在理解你的意圖後，做出有目的性的動作，而不是依靠猜測。

換句話說，MCP 不是 API 的替代品，它是 API 的「語義映射層」，MCP 是把「無法讓 AI 理解的 API」→ 轉成「AI 可以語義推理的功能模組」。重點不是 API 本身，而是 AI 能自然語言推理什麼時候、怎樣、以什麼參數呼叫 API。MCP 是行為層，不是資料層。資料只是行為的一部份輸入。

MCP 的想像空間非常大，它本質上是一個能快速替 AI 加上任務能力的「軍火庫」(MCP = LLM 的動作介面(Action Interface)。

對 RD 團隊而言，如果我們用 MCP 讓 AI 能操作 Azure DevOps 發 PR，能大幅簡化開發流程；在 IDE 的 AI 客戶端輸入一句「幫我發 PR」，AI 會讀 MCP 裡的能力、理解你的意圖，並直接使用對應 API，而不是只停留在建議或指示層級，也不再侷限於本機工作區。

再往前一步，當 MCP 整合 JIRA，而 JIRA 的 MCP 內又包含完整的登入與授權 API，使得 AI 在需要權限時能主動走授權流程。這能進一步降低人工干預，讓我們專注於與 AI 溝通意圖，由 LLM 自動把這些意圖轉成 MCP API 的操作序列。

以產品團隊角度來看，你可以將產品／domain 的 API 以 MCP 打包。AI 理解後，就能組合出你需要的 SOP，自動運用你的產品能力。MCP 在本地端能運作後，從團隊、產品到公司層級，都可以逐步規劃對應的 MCP。

例如：

當我們為表單產品建立 MCP，AI 就能透過對話自動發出正確的權限申請單，甚至能直接幫你填單。簽核清單也能在 AI 操作流程中自動取得並串接。你可以用 LLM 來串接任何你想整合的產品服務。

這次體驗後，MCP 的價值不只是在開發 IDE 的便利性，它更是所有生成式 AI Chat 「實務應用化」的核心框架。有心人士或許真的可以善用它來改善跟AI之間的關係與互動。

後記:

[2025聽心得] 麥肯鍚 問問題的框架 (How to ask smart questions)

[2025聽心得] 麥肯鍚 問問題的框架 (How to ask smart questions)

By | | Comments 0 Comment

以下是你這篇《麥肯錫問問題的框架》的聽書心得筆記整理版，已包含引用來源：

🎧 來源影片： YouTube｜麥肯錫問問題的框架Attachment.tiff

🎯 一、核心觀念：從「問對問題」開始解決問題

麥肯錫的分析邏輯不是直接找答案，而是定義正確的問題。

「問題定義得好，解決一半。」

多數人陷入行動導向，卻沒釐清問題背後的脈絡與限制。

🧩 二、問題拆解七步法（Problem Statement Worksheet）

1️⃣ Basic Question

要先問「真正要解決的是什麼？」

例：「我要增加營收？」太模糊，需具體化為：「要提高哪個產品線的營收？要在什麼時間內？以什麼手段？」

2️⃣ Context — 問題形成的背景

釐清「為什麼現在問這問題」：

是市場份額下降、公司轉型、或個人交棒壓力？

這一步是要讓問題「有故事、有血有肉」，避免空泛。

3️⃣ Decision Makers & Stakeholders

找出誰在決定與誰會受影響：

  • 誰的「好」最關鍵？（必須說好的人）
  • 誰不能說不好？（潛在阻力）
  • 誰其實不重要？（可忽略的） 同時要理解各方的背景、風險偏好與權力關係。 👉 沒搞清楚人際盤，就會提案被「禮貌性忽略」。

4️⃣ Criteria for Success

定義「成功」的具體樣貌與衡量標準。

常見錯誤：大家口中「成功」的定義其實不一樣。

  • KPI 是什麼？營收？滲透率？品牌能見度？
  • 時間軸是多久？ 職場建議：初期只要釐清「你主管認為的成功」，你就已比多數人清楚方向。 → 成功的人知道遊戲規則，不猜規則。

5️⃣ Scope of Solution Space

界定解決方案的邊界。

不能無限想像，要知道哪些方向是「禁止區」。

例：「今年不做線下活動」、「合作對象限定台灣廠商」。

從小範圍出發、先做出信任感，是推案成功的關鍵。

→ 「Scope 愈發散，力量愈浪費。」

6️⃣ Constrains — 限制條件分析

問清楚資源配置：

  • 要多少人、錢、時間？
  • 「好、便宜、快」三者不可兼得，必須取捨。

理解決策偏好遠比提出更多點子重要：

「缺錢」和「缺效果」是不同問題。

許多提案被拒，其實是忽略了這層限制。

另外，還有「隱性限制」——例如客戶不說他沒錢。

懂得問出「Question behind the Question」，能看穿表象需求。

7️⃣ Key Resources of Insight

要能判斷哪些資料「值得信任」。

  • 公開資料是基本功。
  • 內部或付費資料是洞察的來源。
  • 訪問一位專家 ≠ 得到全貌，要建立專家網路。

避免伸手牌行為：

找專家前先自己查，整理出假設與框架，再問。

→ 「無準備的提問，只會浪費彼此的智商與時間。」

🧠 三、延伸理解與應用思路

  • 限制愈多，成功率愈高，因為焦點更集中。
  • 問問題的過程，就是釐清現實與想像差距的過程。
  • 不同階段的職場人，能夠問出「對應層級的問題」，才會被視為有價值的思考者。
  • 框架的意義不是形式，而是讓思考「不亂跑」。

📘 四、個人心得反思

這個框架的精髓在於：問題本身就是決策品質的鏡子。

多數組織提案、會議失效，不是因為人笨，而是問題問錯。

若能養成習慣——

在行動前，先問：

「背景是什麼？誰在乎？成敗怎麼定義？限制在哪裡？」

《AI 整理版｜AWS 全球大當機完整解密：DynamoDB DNS 競態引爆連鎖故障、官方根因與賠償機制全解析》

《AI 整理版｜AWS 全球大當機完整解密：DynamoDB DNS 競態引爆連鎖故障、官方根因與賠償機制全解析》

By | | Comments 0 Comment

以下整理上週（以台北時間，落在 2025/10/20–10/21）AWS 全球性大規模事件的官方根因、時序、影響範圍、後續改進與賠償機制。所有敘述均以 AWS 官方文件為主，並輔以權威媒體技術脈絡補充。你要決策、要追 SLA、要做事後改善，照這份做。

結論

  • 根因（Root Cause）：DynamoDB 於 us-east-1 的自動化 DNS 管理系統存在潛在競態條件（race condition），導致將 regional endpoint（dynamodb.us-east-1.amazonaws.com） 的 DNS 記錄誤更新為空集合，且自動修復失效，需人工介入修正；接著 EC2 的 DropletWorkflow Manager（DWFM） 與網路狀態傳播 backlog 引發新開機/網路配置的連鎖復原延遲；NLB 健康檢查在網路狀態未完全傳播時誤判，觸發 AZ failover 造成連線錯誤攀升。
  • 範圍：起於 DynamoDB，但波及 EC2 / Lambda / EKS / ECS / Fargate / NLB / Connect / Redshift 等多項服務於 us-east-1；全球大量第三方服務連鎖受影響。
  • 官方時序（PDT→台北時間）：事件自 10/19 23:48 PDT（10/20 14:48 TST） 起，分三波衝擊，AWS 宣告 10/20 15:01 PDT（10/21 06:01 TST） 全部服務恢復正常。詳細見下方時序表。
  • 後續改進：全面停用 DynamoDB DNS Planner/Enactor 自動化並修補競態、對 NLB 加上容量移除速度控制（velocity control）、EC2 增加 DWFM 復原大規模測試與以佇列深度為基準的節流機制。
  • 賠償（SLA Service Credit）：依各服務 SLA 申請服務抵用金（Service Credit），非自動發放，需在事件後第二個帳單週期結束前透過 Support Case 以「SLA Credit Request」提出。範例如 DynamoDB SLA、EC2/Compute SLA 與各服務的 Credit Request 條款。

一、Root Cause（技術根因拆解）

  1. DynamoDB：DNS 管理競態 → 空白 DNS 記錄 → 端點無法解析
  • 內部 DNS Planner 產生計畫、DNS Enactor 多 AZ 冪等套用至 Route 53。因一個 Enactor 長時間重試延遲，另一個較新的計畫先套用且觸發舊計畫清理；延遲的 Enactor 之後把舊計畫套回 regional endpoint，而清理程序又把該舊計畫刪掉，導致所有 IP 記錄被移除且狀態不一致，自動修復停滯，需人工介入。
  1. EC2：DWFM / Network Manager 復原連鎖
  • 事件期間 DWFM 與 droplets 的 lease 檢查依賴 DynamoDB，先被拖垮；DynamoDB 復原後 lease 大量重建、工作佇列壅塞，DWFM 進入壅塞崩潰（congestive collapse），需節流+選擇性重啟才能清併列。接著 Network Manager 處理積壓的網路狀態傳播，造成新起機器可開但無法立即通網。
  1. NLB：健康檢查與 DNS AZ failover 的交互放大
  • 健康檢查在網路狀態尚未完整傳播時誤判，導致節點被移出/又加回，放大負載與錯誤；AWS 一度停用自動健康檢查 failover 以回復容量。

上述技術解釋以 AWS Post-Event Summary（PES） 為準；外電報導（Guardian/Reuters/Wired 等）與第三方監測（ThousandEyes）之描述與 AWS 官方內容一致或相符。

二、官方時序（轉換為台北時間，UTC+8；括號內為 PDT）

來源：AWS About Amazon 官方更新與 PES。

  • 10/20 14:48（10/19 23:48 PDT）：DynamoDB regional endpoint DNS 異常開始，API 錯誤上升（第一波）。
  • 10/20 17:25–17:40（10/20 02:25–02:40 PDT）：AWS 修復 DNS 記錄；隨各地 DNS 快取過期，DynamoDB 恢復。
  • 10/20 20:30–10/21 05:09（10/20 05:30–14:09 PDT）：NLB 健康檢查誤判引發連線錯誤；09:36 PDT 停用自動 failover、14:09 PDT 恢復。
  • 10/20 20:01–10/21 04:50（10/20 05:01–13:50 PDT）：EC2 新開機與 API 逐步恢復，DWFM/Network Manager 清 backlog。13:50 PDT（10/21 04:50 TST） EC2 全恢復。
  • 10/21 06:01（10/20 15:01 PDT）：AWS 對外宣告所有服務恢復正常。

期間 IAM Console、Support Console、Redshift、Lambda、ECS/EKS/Fargate、Connect 皆有不同時段/型態的 API 錯誤與延遲，詳見 PES 細節分段。

三、影響與證據

  • 多服務於 us-east-1 大範圍受影響，含 EC2/Lambda/EKS/ECS/Fargate/NLB/Connect/Redshift/IAM Console/Support 等；第三方大規模中斷（通訊、金流、遊戲、媒體等）。
  • AWS Health Dashboard / About Amazon：官方對外狀態與統一時序；PES：完整技術剖析。
  • 外部監測與媒體旁證（ThousandEyes / Wired / Guardian / Reuters）：記錄全球影響與技術脈絡。

四、AWS 後續改進（官方承諾）

  • DynamoDB：全球停用 DNS Planner/Enactor 自動化，修補競態並加防護，再評估重啟。
  • NLB：加入 velocity control，限制單一負載平衡器在 AZ failover 時可移除的容量，以避免抽走過量健康容量。
  • EC2：新增 DWFM 大規模復原測試套件；節流機制改為以佇列深度為準，高負載時自保服務穩定。
  • 跨服務：檢討跨服務復原路徑以縮短下次 TTR。

五、賠償與申請實務（SLA Service Credits）

要點：不是自動賠付；你要主動提。標準流程如下（各服務 SLA 條款相近）：

  1. 確認受影響服務與區域（例如：DynamoDB、EC2，區域 us-east-1），計算該月度可用性是否落入 SLA 賠付檔次。
  2. 提出申請：在 事件後第二個帳單週期結束前，到 AWS Support Center 建立 Support Case，主旨含 “SLA Credit Request”，附上受影響期間、資源、帳單證明與監測證據。
  3. 抵用金形式：Service Credit 會抵扣未來帳單（部份服務載明可視情況退刷同月信用卡），非現金退款。

參考：DynamoDB SLA、EC2/Compute SLA 與 Credit Request 條款（多服務條款結構相似）。

六、你現在該做的（行動清單｜魔鬼教練版）

  1. SLA 索償
    • 彙整你在 10/20 14:48–10/21 06:01（TST） 的錯誤率、失敗交易、不可用時段；逐一比對 DynamoDB / EC2 / 其他受影響服務 的月可用性與 SLA 門檻，本週內送出 Support Case。
  2. 架構補強（依官方改進方向對齊與超前部署）
    • DNS 依賴降風險：對控制平面依賴（e.g., 資料表/隊列/金鑰管理）建立跨區域 endpoint fallback 與 更短 TTL / 獨立解析策略。
    • 啟動分區容錯：關鍵業務至少雙區域（active/active），避免 us-east-1 單點；Global Tables 與讀寫路由切換演練常態化。
    • NLB 容量與健康檢查：避免健康檢查信號耦合於延遲網路傳播；對AZ failover 做壓力測與節流曲線。
    • EC2 啟動路徑：將冷啟容器/VM 的依賴降至最少；必要時改用可在異區預熱的機制、或以 Lambda/ECS/Fargate 輔助短期擴容。
    • 運維演練：把這次時序寫進故障劇本（runbook），每月演練一次：DNS 端點解析失效 → 控制面不可達 → 容量節流 → 逐步恢復 的全鏈路演習。
    • 外部技術脈絡可佐證你的設計說帖（ThousandEyes / Wired / Guardian）。

七、權威來源（官方文件｜可供稽核附檔）

  • AWS Post-Event Summary（PES）：Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region（根因、時序、影響、後續改進的權威版）。
  • About Amazon 官方公告（同日更新）：Update – AWS services operating normally（整體時序對外版，含 PES 連結）。
  • AWS Health Dashboard（事件歷史）：可回溯各服務的官方時間線與公告。
  • SLA 與賠償條款：
    • DynamoDB SLA（可用性門檻與信用額度計算）。
    • Amazon Compute/EC2 SLA（Region/Instance 級別承諾與 Credit）。
    • Credit Request 規範（提出申請期限與格式要求）。
    • 其他服務（如 S3、Connect）之 SLA 條款與 Credit 機制可類推查核。
  • 外部權威脈絡（非官方，作為影響面旁證）：ThousandEyes、Wired、Guardian、Reuters。
AI 左移對軟體開發的變革 ，C#後端開發為例

AI 左移對軟體開發的變革 ，C#後端開發為例

By | | Comments 0 Comment

🧠 AI 左移：從 Chat 到 Commit 的開發革命

傳統 IDE 時代，重構工具、語法補全與靜態分析已經幫助我們加速開發。但現在，我們正站在另一個斷代點──AI 開發模式的橫空出世。

從最早的「問答式 AI」產生 code snippet，逐漸演進到「動作外包」、到可以在 CLI 中自然對話，甚至進一步進入 Cursor 等具備 Project Context、Agent System、MCP（Multi-Agent Command Protocol） 的多工 AI 工具戰國時代。

🤖 AI 自己發 PR、自己 Code Review 的時代？

當我看到這支影片 [AI 左移影片連結]，我才真正意識到，這並不是空想：

AI 不只會寫程式，它可以從需求分析、Mock UI、拆解任務、估算工時、產出規格，直到 PR 審查形成一個完整開發閉環。

而這樣的流程，正在顛覆我們原本對「軟體開發分工」的理解與作法。

🪛 為什麼 AI 要往前移動（AI 左移）？

過去，我們在開發流程中只在實作階段使用 AI，而忽略了一件更關鍵的事：

⚠️ 人類的瓶頸從來不在 code，而在「對問題的理解」與「開發過程中資訊的流失」。

透過 CLI + Project Context + Prompt 工程技巧，AI 可以開始參與「定義問題」的過程，進入專案需求前期：

  • ✍️ 需求口述 → 語音備忘 → 文字轉錄
  • 📄 轉為 markdown 文件（需求規格.md）
  • 🧠 透過 Prompt 進行 extended thinking / chain-of-thought 鏈式思考
  • ✅ 讓 AI 主動復述需求，對齊理解，減少溝通誤差
  • 🧩 開始進行 Mock、WBS 拆解、工時預估

🛠️ AI 開發流的實作節奏（從需求到派工）

以下是我目前思考的實驗流程（你也可以試試看）：

flowchart TD
    A[需求口述/備忘錄] --> B[生成 需求規格.md]
    B --> C[AI協助產出 todo.md（拆工+估時）]
    C --> D[AI產出 SD規格文件.md（技術設計）]
    D --> E[開 PR，開始進行協作]
    E --> F[Reviewer 產出 refinement.md]
    F --> G[對應 JIRA 拆單派工]

補充：

  • 每份 .md 檔案皆納入版控，AI 分析時可以讀取上下文。
  • .todo.md 為階段性任務清單，支持迭代審查與 prompt 精化。
  • .refinement.md 可成為後續 QA 或重構依據。

🧩 提示詞工程才是核心技能（不是工程本身）

與 AI 合作的關鍵不是「讓它幫我寫 code」，而是「讓它理解我要什麼」。

關鍵提示詞技巧：

  • 說清楚你的技術要求、框架範圍、邏輯驗收條件
  • 用正向語言描述需求（「要怎樣」而不是「不要怎樣」）
  • 補充範圍與限制（避免硬編碼、可維護性、可擴展性）
  • 在 prompt 中註明：「請不要只為了測試通過而實作」

🔁 Git + AI 迴圈：低風險高效率的實驗場

AI Left Shift 的特點，就是快速試錯，但這不代表無序。你可以透過下列策略控管風險：

  • 使用 /init 指令快速建立專案理解基底（產出掃描報告）
  • /clear, Esc, /reset 等指令控管 prompt 紀錄與狀態清理
  • 利用 Git 分支搭配 PR 討論實施「嘴炮即代碼」的思維
  • 不一定要選 highlight code，文字描述即可驅動 AI 修改提案

🔁 分享一下，近期我對於C#後端如何搭配Cli或Cursor(接下來簡稱AI)

C#傳統IDE(我用Rider，以下以Rider為例)的強項其實是Debug、Testing跟 Trace Code以及人為的重構工具

AI進來以後，其實工具的演化 非常快，目前看來確實 AI Editor以 Cursor還是算相當成熟的工具，當然這邊指的不是像Claude AI的model，指的是AI寫扣的能力 而是ui與cli的平衡生態

圖示(IDE 的好處，在於對人類的友善性)

以下針對後端軟體開發一樣分成3階段，常態下，我會對我的AI Editor設定好Plan, Coding , Designing的Rule, Guide line的md檔案給他，然後同時開起AI Editor(Cursor)與Rider後(Mac上兩指左右滑就可以快速切換)，開始進行feature開發

第一階段

描述需求，並聊透，分析完整，進行評估與限制(注意prompt與context的上下文工程)
跟AI 在IDE Chat完需求後，進入下一階段

第二階段

請他在AI Editor以TDD的角度開發測試
這時候切換到Rider跑測試，編譯不過或紅燈，就把錯誤貼回chat請他修正
這段其實是AI的短版，搭配人類協助測試與檢核編譯(但我相信很快cursor或Cli就會自動檢查這類的東西了)

第三階段

有測試後，再堆疊案例，這時透過AI重構意義就有了保障，直到完成需求並驗收通過

以上我實測了以後，其實在第二階段是AI容易撞牆的地方，偶爾還是給出無法編譯的程式，有時還是會給出不如預期的命名或設計，但我認為撞牆大部分都還是你給的指令 不夠明確，或是所謂預期工程不足(要什麼正向表達)。若我們小步小步的移動來讓 AI進行開發的話，可以透過人類的補充資訊，更精準的取得修正的方向，AI獲得更多 context後，都確實可以做的更好。

📌 總結：讓 AI 更早參與，才能真正減少浪費

從需求定義、Mock、估時、PR、派工、Refinement，AI 都可以參與。

AI 有短版，但人的「記憶力、注意力、思考速度」也有極限。

將 AI 左移，不是為了讓它代替人，而是讓它幫助人把最難搞的前中期開發流程梳理清楚、減少返工、提升開發信心與節奏。

這不僅是開發方式的變革，更是我們與 AI 協作型態的一場進化。

👉 需求規格.md → todo.md → SD設計文件 → refinement.md → jira 任務派工

這一套，會是我認為未來專案管理 + AI 工程協作的骨架。

後記 :

AI的短版其實會複製人類的短版，若人類給的prompt不夠具體，AI就會一樣會亂猜跟幻覺(可能跟你老闆一樣)，不夠具體的定義 不只是prompt的問題，Context跟Scope的限縮也有關係，這就是cli跟ide帶來的優勢，而不是只有chatgpt的對話記錄而已；我試過1500行的cs程式，請他重構符合規範(有具體的要求 ) vs 請他只針對cs中某個測試 function(具體名稱)去進行 明確的重構(可以在prmpt講清楚或是有參考檔都可以)，那麼後者效率會好很多。這證明了，人類專注記憶力有限的缺點，其實在AI也有，必竟現在的很多專家模型都是混搭在workflow上去建構agent。跟他工作也要把他當成教育現場，有耐心的去tune他跟讓他小步確認與對齊(可以試試犯錯)來修正他的產出！

再舉個例，很多人問AI的時候，就會把100萬個字 或整個專案 當context丟給他，再問他的一個抽象的問題，例如整理所有的重點。可想而知，AI只能猜你想要什麼，再加上性能跟算力的限制，就會給你一個被限制也無法達到你需求的結果，憤而覺得AI難用 。這時其實就是拆解context跟task，降低ai要猜測你的成本其實會對生成式的結果品質會有飛躍式的提升。另外多試試一些deep think，ultrathink等指示詞，有機會讓 ai進行換model運作。也有機會改善輸出品質，但前提一樣是要給對context跟 問對問題！！

Who is ZhouShen

Who is ZhouShen

By | | Comments 0 Comment

第一次看到他也是從2014年初登場中國好聲音第3季，一直以來，我都會多多少少觀注一下素人選秀節目 ，從台灣的星光大道，超偶，到後來大放異彩的中國選秀節目。其實那時聽到這首歌的時候，對他的聲音覺得特別，雖然有歡顏與貝加爾湖畔的比賽作品，但我其實就僅僅是有印象而已

初登場: 歡顏

第二首-貝加爾湖畔 (被那英淘汰的名場面)

真的對他驚豔的就是這個大魚美聲合唱版，以前有聽音樂劇跟世界三大男高音，其實我對這種美聲唱法就是有愛好~，所以我就開始 密切關注他，這時的他也默默已經有一些作品了。(動畫-大魚主題曲)

中國好聲音幫唱版本 ，唱到陳奕迅 都稱讚

因為周深是烏克蘭音樂學院畢業的，以致於後來看到多首他的美聲的作品時 ，他的技巧也愈發成熟

以這兩首為例(2019~2020年左右)

歌劇魅影 – Think of Me

貓- Memory

他把握住了每一個的舞台，因為他都做好了最萬全的準備，展現了他絕佳的控制力 ，嗓音條件。

恰恰符合我對跨界美聲的審美，同時又具備有獨特性，在那時看來，根本就是一個鑽石(他勵志的故事又是另一段故事了)

他曾經說過，他特別珍惜並全力準備每一個表演的機會，因為他唯有這樣，才有機會有”下一個舞台”

有2020~2024年 ，幾乎可以看到他不斷的出現在各大晚會與典禮，也有無數的歌讓他唱，甚至一度戲稱勞動楷模

也是因為這樣，他開始被很多人聽到

香港明星們對周深的評價

那時因為幾個音綜開始嶄露頭角，我們的歌與他一起參演的周華健也 把對他的讚賞，帶到台灣，

連知名電台主持人光禹都開始挖起他的礦(看看下面的歌單就知道這個坑的深度)，做了寶藏週記 一做也好幾年了

🌹寶藏周記【周深為何成電影節必邀嘉賓 穩坐第二排 更獲外媒好萊塢焦點報導】 🌱光禹·飛碟電台夜光家族·2025.04.30

而其實這幾年 來周深的成長，從YOUTUBE的作品、能見度，都可以看的出來，他本身也很努力，他曾經說過 ，剛開始很多人對他的評價是∶「原來周深是一個男孩子，唱是唱的不錯，但若是做為一個女孩子，就顯著普通了」，他覺得很多人因為這樣 否定了他在音樂上下的努力。

然而他不畏酸言酸語，繼續憑實力與求新求變的勇氣，讓自己始終能保持，這是一個特別是他從不自信的轉變過來的，看著他就像自己的孩子一樣成長起來。

跟貝加爾湖畔 原唱 李健老師合作了一個即興舞台

出道十年 專訪，可以見得，他是一個心思非常細膩且正向的一個人

早期辛酸的經歷

如今的維基百科寫道 : 周深是一位備受讚譽的中國男歌手，以其清亮溫柔的嗓音和多變的演唱風格著稱。自2014年參加《中國好聲音》第三季正式出道以來，他在音樂領域取得了眾多成就，以下是他的一些重要榮譽與貢獻：

🎤 音樂成就與代表作品
* 代表歌曲：《大魚》、《燈火裡的中國》、《小美滿》、《和光同塵》、《花開忘憂》等，這些作品展現了他在流行、古風、電子等多種音樂風格中的出色表現。
* 專輯發行：截至目前，周深已發行兩張錄音室專輯：《深的深》和《反深代詞》，並發表超過200首單曲。

銷售成績與認證

  • 首日銷售額：專輯發行首日即創下2500萬元人民幣的銷售額。

  • 首週銷售額：首週銷售額突破3000萬元人民幣。

  • 累計銷量：截至2024年12月，專輯累計銷量超過167萬張，銷售額突破5900萬元人民幣，成為2024年中國內地專輯銷量冠軍。 

  • 平台認證：《反深代詞》是2024年QQ音樂平台上首張也是唯一一張獲得“史詩唱片”認證的專輯。

🌍 國際成就

  • IFPI全球專輯銷量榜：該專輯在2024年IFPI全球專輯銷量榜中排名第11位，是當年唯一上榜的華語專輯。

  • 單曲認證：專輯中的4首歌曲獲得雙白金認證，1首獲得白金認證，7首獲得黃金認證，累計認證單位達1250萬。

以他的成長期，以我認識他的部分，我將 時間軸分類如下
* 前期(中國好聲音2014+首張專輯，少數翻唱) 2014~2018
* 中期 (2019~2022)
主要是靠默默累績曝光(OST大量累積超過100首，其中包含成名曲大魚)
另一個部分是音綜累積 作品期( 各種 合作舞台 ，翻唱創作 – 留下yt作品)
註: 他在跑男也很活躍，所以在中國很出圈~
* 現在 (2023~now)
大鳴大放期(各種音樂獎、邀約、晚會演出，國內外巡迴)
* 以上年限就我印象，不用太在意
另外以音樂風格作品，又可于分成
中國風(曲調本身京有中國風，或加入戲腔)，因為本著仙嗓天賦，通常效果拉滿，方文山都認證
一般流行(翻唱 or ost現代劇) 就看歌順不順耳就好

跨界(融合美聲唱法) -> 我特別有興趣的

以出處來分的話，以下歌單大部分就是很單純的分法，沒有排名，大部分絕得要嘛是順耳，不然就是覺得 是值得一再品味的現場或錄音室 作品~

一看到JJ找他當佳賓，也算原了周深偶像的一個夢想，他們同台飆唱 真的滿感動的~因為這也是看到他被前輩認可了
JJ + 周深 《裹着心的光》 (JJ北京演唱會)

各大音綜時期

蒙面唱將猜猜猜

《雪落下的声音》

雪落下的聲音

《我真的受伤了》

杨丞琳、周深
《她说》

《我是真的爱你》李宗盛

聲入人心 我很愛聽音樂劇，這完美 發揮了他美聲
莎拉布萊曼 《Time to say goodbye》

貓- Memory

歌劇魅影 – Think of Me

Version 2

周深 王晰 月彎彎 二重唱

合作舞台 (他唱合音超強，超like他的二創加分作品)
天賜的聲音- 周深-張韶涵 – 一路生花

周深GAI周延合唱《玫瑰少年》 (原唱: 五月天or蔡依林)

我們的歌
周深 李克勤 – 張國榮 (追 )

周深 李克勤 – 《月半小夜曲》

周深 李克勤 – 《天下有情人《我是真的爱你》》

時光音樂會- 梁詠琪 – 花火

時光音樂會- 阿杜 – Andy

時光音樂會- 周杰倫 – 聽見下雨的聲音

時光音樂會- 月光(原唱 : 胡彥斌 轉音一絕)

原唱王菲 – 如願

五月天- 好好

起風了

《歌手·当打之年》Singer 2020
歌手 – 達拉崩吧 (獵奇)

無問 – 原唱:毛不易

《自己按门铃自己听》

《大鱼》

声生不息·家年华- 周深 汪蘇瀧 愛的供養 (原: 楊冪)

声生不息·家年华- 周深 黃綺珊 歲月 (原: 王菲)

声生不息·家年华- 周深 宋亞軒 桃花諾 (原: 鄧紫琪)

声生不息·家年华- 周深 陳楚生 逆光(原 : 孫燕姿)

舞台 2023 朴仔範、王嘉爾、Ella供他清唱大眠名場面

音樂緣計劃(新歌很多)
沉默的羔羊

合作版
薛之谦&周深《只字不提》

周深&周笔畅《孤独音乐家》

二次元作品+翻唱 (他出圈前，在中國二次元界已經爆紅)
《Rubia》——《崩壞3rd》印象曲

《Unravel》 – 原唱 TK from 凛として時雨

迪士尼合作作品
《奇遇乐章》

星願 I’m a Star

20201224周深Charlie Zhou Shen 九语版《Let It Go》

OST電視原聲帶(古風劇)
《蒼蘭訣》-《餘情》

慶餘年 2-借過一下

《願得一心人》(電視劇鶴唳華亭主題曲)

《願》(電視劇錦衣之下主題曲)

《若夢》(電視劇 夢醒長安 主題曲)

陳情令《荒城渡》

周深 + 鄭雲龍 -《曇花一現雨及時》(電視劇三千鴉殺主題曲)

《明月傳說》(電視劇 風起霓裳 主題曲)

Sword and Fairy《祈今朝》 | 《共鸣》

【長歌行 The Long Ballad OST電視劇片尾主題曲】

《相擁不放》(無損音樂連歌詞)(《白月梵星》影視劇主題曲)

一晌 (電視劇《狐妖小紅娘月紅篇 Fox Spirit Matchmaker: Red-Moon Pact》片尾曲)

曼陀 (《淮水竹亭》影视剧主题曲/片尾曲

以上…太多了，遺珠之憾應該還有超過10首

OST電影原聲帶

《水形物語-奧斯卡金像獎最佳影片》(電影水形物語同名推廣曲)

《問花》(電影 白蛇2：青蛇劫起 主題曲)

張藝謀 – 《懸崖之上》(電影 懸崖之上 同名主題曲)

《來不及勇敢》(電影昨日青空青春告白曲)

《小美滿》【熱辣滾燙 YOLO OST 電影熱辣陪伴曲】

電影《解密》中文版同名主題曲

《流浪地球2》定义主题曲《人是_》

OST電視原聲帶(現代劇主題區)

《消散人潮》【北上 Northward OST 電視劇片尾曲

《雲邊的風箏》(又名《我們的王鶯鶯》

《风吹过的晨曦》（玫瑰的故事情感主题曲）

《幸福的故事》幸福裡

人世間-光字片

生活總該迎著光亮 (電視劇《喬家的兒女》主題曲)

過客 (《以愛為營》電視劇主題曲)

全英文歌
周深《避難所 Sanctuary》(英語單曲)

《My Only》(電視劇 開端 片尾主題曲)

還有滿多現場 作品是英文歌

戲腔風格
周杰倫 – 《蘭亭序》

《易燃易爆炸》

光亮 – 記錄片或實境節目 主題區

手遊作品: 江湖3系列 第一部: 江湖緣起

第二部: 江湖覓知音

第三部: 《我，江湖》《一梦江湖》

《雲裳羽衣曲》(手遊雲裳羽衣首發主題曲)

https://www.youtube.com/watch?v=E2bpviMgPLk

藝術歌曲 或合作舞台聯合國表演 – 《和平頌》

周深+郎朗！钢琴+吟唱！《大鱼》+《Scarborough Fair 斯卡布罗集市》

周深、克萊德曼合作中國經典《梁祝 The Butterfly Lovers》

《月光爱人》南山流行音乐节

其他現場or翻唱 作品

唱给世界听 《随风》

鐵達尼號 My heart will go on (席琳迪翁)

雪落下的聲音(神翻唱)

《 問世間情是何物》 （ 詞：元好問 • 金朝）

Unstoppable (原唱: SIA)

Fire

身騎白馬(原唱: 徐佳瑩)

《天堂島之歌》

周深萨顶顶《左手指月》

Zhou Shen/周深《與你同在》【い つ も 何 度 で も】[《千與千尋》主題曲日文版]

自創曲-虛構 現場晚會首唱

齐豫+周深 合唱《欢颜》 2024-2025跨年

《我用所有报答爱》 – 譚盾 交響樂團

《浮光》

《我以渺小爱你》

《花开忘忧》

《卧龙吟》

首張專輯 周深 Charlie Zhou【深的深】 全分享(10首歌)

時隔七年，第二張個人專輯 反深代詞https://youtube.com/playlist?list=PLrlBqwsy1XpTJSap7VwatCdz6Fh0eUIYM&si=4rb5CSCdYfR12OEq

.net core 應用程式 在AppService進行dotnet dump

.net core 應用程式 在AppService進行dotnet dump

By | | Comments 0 Comment

當應用程式有High Memory 或是High Cpu的現象時，若希望對應用程式進行Runtime的分析，以前在IIS上常常進行的是在工作管理員對w3wp進行傾印，移到雲端又是Container形式後，跟以往 在windows的經驗不大一樣，不得其門而入，以下記錄一下作法

在Container For AppService的環境下要能進行Dump，會有以下 步驟

Container安裝dotnet-dump 的tool 

# 前略...
# Open port 2222 for SSH access
EXPOSE 80 2222

# dotnet
RUN apk add icu-libs tzdata
RUN apk --update add libgdiplus ttf-dejavu
RUN apk add --no-cache bash curl icu-libs libc6-compat \
    && curl -sSL https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh \
    && bash /tmp/dotnet-install.sh --channel 8.0 --install-dir /usr/share/dotnet 

# 安裝 dotnet-dump
RUN /usr/share/dotnet/dotnet tool install -g dotnet-dump \
    && ln -s /root/.dotnet/tools/dotnet-dump /usr/bin/dotnet-dump \
    && dotnet --info

# 後略...

確認Docker Build成功

通常你的webapp有多個 instance，請先設定環境變數增加以下 設定為true

WEBSITES_ENABLE_APP_SERVICE_STORAGE

這個設定是讓 多個instance的/home目錄共用，後續可以透過kudu的newui進行FileManager下載Dump檔案

透過進階工具連到開發工具(不是上面的SSH，這個外層的SSH應該主要是連到Container Host的主機，要連到指定的Instance的話，可以進到Kudu去指定Instance)

接著ssh連進去 確認Container內dotnet-dump版本

/home/LogFiles# dotnet-dump --version
9.0.553101+5b61d34de04d6100e6003415f7d7e9c4b971afd4

確認指定ok後，查詢process id

ps aux | grep dotnet
16 root 5h23 dotnet /app/example.dll
10891 root 0:00 grep dotnet

進行dump collect，注意，此步驟在linux container進行時，並不會中斷process或重啟(這跟我們之前w3wp.exe的經驗不太一樣，不過或許還是會間接造成伺服器比較忙錄，所以可以離峰進行)

dotnet-dump collect  -p [process-id]  --type Full  --diag

Writing full to /home/LogFiles/core_20250211_010126
Complete

成功後

透過kudu 的FileManager就可以找到檔案 進行下載分析~~

Reference :

https://techcommunity.microsoft.com/blog/appsonazureblog/how-to-collect-net-core-dump-on-linux-web-app/2260713