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