分類: AI

心得: 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個月後，又會刷新三觀了~到時再來看看有沒有什麼新的想法吧~~

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跟 問對問題！！