[AI 分享] 打造好用的 Skill 方法

 [AI 分享] 打造好用的 Skill 方法

摘要 : 重點不在規則多，而是寫清觸發場景、任務邊界、輸出格式與示例，才能做出真正好用的 Skill。

內容:

cloud 官方文件指出很多人寫 Skill 效果不好，不是因為不夠努力，而是沒有抓到設計重點。真正好用的 Skill，不是靠堆疊大量規則，而是要讓系統清楚知道「什麼時候該被呼叫」、「被呼叫後要完成什麼」、「最後要如何輸出」。

先介紹 Skill 的基本結構。標準的 skill.md 分成兩部分：上方是 YAML 配置區，包含名稱、觸發時機與是否需要額外權限；下方是 Markdown 內容區，負責描述 Skill 被調用後的具體執行方式。示範案例是一個名為「meeting to action」的 Skill，功能是把會議記錄轉換成結構化的行動項清單。

其中，配置區最重要的欄位是 description。這一段文字會被系統拿來做語意匹配，判斷目前對話是否需要自動載入這個 Skill。若 description 只寫「會議記錄整理工具」這種模糊描述，系統無法理解具體用途與觸發時機；但若寫成「把會議記錄或會議內容整理成結構化的行動項清單，當使用者提供會議逐字稿、錄音轉文字，或要求整理會議與提取行動項時觸發」，就能明確提供場景、關鍵詞與觸發條件。作者也提醒，description 有字數顯示限制，因此最重要的觸發詞要盡量放在前面。

接著內容區的寫法。第一步不是急著列規則，而是先定義任務本身，也就是一句話講清楚這個 Skill 的核心工作。這樣系統才知道執行的終點與邊界，例如這個案例的重點不是做全面摘要，而是只聚焦在行動項、決策與待澄清問題。

第二步是定義輸出格式，而且越具體越好。作者示範的輸出包含三部分：第一是行動項清單，每一條都要有負責人、任務、截止時間與優先順序；第二是本次會議的核心決策，列出兩到四條；第三是待澄清問題，用來標記責任不清或尚未解決的事項，若沒有則可省略。明確的格式設計，能讓每次輸出維持穩定一致，不會忽長忽短、忽散忽亂。

在規則設計上，作者特別強調「少而有力」。很多人習慣寫出一長串像是「保持客觀」、「語言簡潔」、「注意格式」這類看似專業、實際卻缺乏約束力的規則。真正有效的規則，應該要能落地執行，例如：只提取明確任務、負責人不清楚就標示待定、截止時間未說明就寫未定、不要自行猜測內容、行動項要用動詞開頭等。這些規則能直接限制模型最容易出錯的地方。

示例是最常被忽略、卻極其重要的一部分。相較單純描述，完整的輸入輸出示例更能讓系統理解你想要的格式、資訊密度與判斷方式。像是如何區分行動項與決策、如何標記待定、如何處理未解決問題，透過一個涵蓋多種情況的示例，往往比十條抽象規則更有效。

最後，整理出三條 Skill 寫作原則。第一，先寫 description，再寫內容，因為先釐清觸發場景，後續設計才有方向。第二，一個 Skill 只解決一件事，不要同時想讓它整理會議、寫週報又寄信，否則容易失焦。第三，Skill 與 cloud.md 不能混用，cloud.md 適合放每次對話都要載入的固定規則與背景，而 Skill 則適合做按需載入的場景化指引。

整體來說，核心觀點很明確：Skill 不是越長越好，也不是提示詞的堆砌，而是一份精準的操作手冊。只要把觸發條件、任務邊界與示範方式設計清楚，就能寫出真正實用、穩定又高效的 Skill。

[AI 觀點] AI工具下的程式設計師內耗危機

 [AI 觀點] AI工具下的程式設計師內耗危機

摘要 : AI雖提升寫碼速度，卻可能壓縮思考、削弱除錯與架構能力，讓工程師陷入表面高效、實則退化的困境。

內容:

最近不少程式設計師都強烈感受到，真正變捲的不是找工作，而是日常開發工作本身。自從團隊導入 AI 工具後，管理者對開發效率的期待明顯提高，原本需要三天完成的任務，現在可能被認為一天就該做完。因為在許多人眼中，既然程式碼可以由 AI 產出，那工程師只要「按幾個鍵」就能交付成果。

這樣的變化不只來自上層壓力，團隊內部也開始出現一種比拼速度的氛圍。大家互相比誰更會用 AI、誰產出更快，再加上網路上大量渲染「幾秒生成系統」、「一天完成複雜專案」的內容，讓整個開發現場變得越來越焦躁，也越來越失真。

表面上看，AI 的確讓寫程式變快了，但真正令人擔心的是，工程師主動思考的空間正在被嚴重壓縮。過去接到需求後，會先理解問題、設計系統、規劃資料表，再一步一步親手完成程式碼，過程中不斷除錯與重構。雖然慢，但每一段程式碼都經過自己的思考，系統脈絡也更清楚。

現在在時程壓力下，許多人逐漸變成把需求丟給 AI、等 AI 生出程式碼、再把錯誤訊息丟回去修正的工作模式。人腦不再主導開發，而是淪為 AI 與需求之間的傳話工具。這種流程看似高效，實際上卻讓思考能力慢慢退化，長期下來會讓工程師失去最核心的價值。

其中最明顯被削弱的能力之一，就是除錯能力。以前自己寫的程式出錯時，必須看日誌、打斷點、追原始碼、理解底層機制，雖然痛苦，卻能一步步累積真正的技術內功。現在很多人一遇到錯誤，第一反應就是交給 AI 處理。AI 若修好了，自己未必真的知道原因；AI 若修不好，就只能反覆貼錯誤訊息碰運氣。一旦遇到複雜問題，例如分散式鎖、高併發異常或記憶體溢位，若基礎功不夠，往往連問題方向都抓不到。

另一個正在被侵蝕的，是架構與系統拆解能力。AI 擅長提供片段式答案，但企業級專案需要的是全局思維，包括模組拆分、邊界定義、解耦設計與整體架構判斷。當工程師長期習慣讓 AI 幫忙「切碎」問題、提供局部解法，就可能逐漸失去獨立拆解大型系統的能力。一旦系統規模變大、服務開始拆分、邏輯變複雜，AI 很容易因上下文不足而產出錯誤建議，這時若工程師自己也缺乏判斷能力，就很難有效修正。

這種現象帶來的，不只是效率提升，而是技術圈潛在的全面平庸化。問題不在於 AI 會不會寫程式，而在於工程師是否把最有價值的思考與決策也一併外包了。軟體開發中最不值錢的從來不是敲鍵盤，而是鍵盤背後的理解、判斷與取捨。

因此，真正值得警惕的不是 AI 讓人寫更少程式，而是它讓人少想程式。如果工作環境只追求速度，把 AI 當成思考替代品，那麼工程師的核心競爭力就會被一點一滴掏空。面對這個趨勢，最重要的不是拒絕 AI，而是重新思考：在 AI 時代，真正稀缺的能力，依然是獨立思考、深度理解與做出正確技術決策的能力。

[AI 分享] Codex AGENTS.md 實戰寫法

 [AI 分享] Codex AGENTS.md 實戰寫法

摘要 : 善用精簡的 AGENTS.md，可大幅提升 Codex 輸出品質與專案協作效率。

內容:

AGENTS.md 是一份提供給 Codex 的專案使用說明。每次 Codex 啟動時，都會自動讀取這個檔案，因此不需要手動貼上內容，也不需要每次重新說明專案規則。只要在終端輸入指定初始化指令，就能依照當前專案自動生成模板，再依需求進行修改即可。

可以把 AGENTS.md 理解成 Codex 的專案入門指南。若沒有這份檔案，Codex 每次都像剛加入專案的新手，無法快速掌握規則；有了它，Codex 一開始就知道專案怎麼執行、有哪些限制，以及提交前應遵守哪些流程，整體使用體驗會明顯提升。

撰寫 AGENTS.md 時，不建議把整份專案文件全部貼進去。因為它有 32KB 的長度限制，內容太多不但可能被截斷，還可能讓重要規則被忽略。最理想的做法，是把內容控制在十幾行內，只保留最關鍵、最具操作性的資訊。

建議優先寫五類內容。第一是專案執行方式，例如怎麼安裝依賴、怎麼跑測試、使用什麼包管理器與工具。第二是提交前必須完成的動作，例如 lint 與 test 必須全部通過。第三是禁止變更的內容，例如不要修改 ENV 檔案或既有 migration。第四是專案特殊約定，例如 commit message 格式、變數命名規則。第五是新增依賴的規矩，例如加入新的正式環境依賴前需要先確認。

撰寫時也要避開幾個常見問題。第一，不要只寫空泛態度，例如「請重視程式碼品質」，這類描述對 Codex 幾乎沒有實際幫助，應改成具體可執行的命令與步驟。第二，不要把它本來就能從專案中直接判斷的資訊重複寫進去，否則只會製造噪音。第三，不要寫完後就放著不管，因為專案規則會隨時間變動，應定期回頭檢查並刪除已經不必要的內容。

進階用法是分層管理。若專案屬於單一倉庫但包含多個服務，例如前端與後端採用不同技術棧，建議在根目錄放通用規則，再於各服務子目錄內建立各自的 AGENTS.md，分別定義專屬的測試命令與開發規範。Codex 會依所在目錄自動套用對應規則，而且越接近當前目錄的設定優先度越高。

另外，如果只是想暫時調整規則，又不想修改原本的 AGENTS.md，可以在同目錄新增 Agents Override MD。這樣就能臨時覆蓋原設定，刪除後即可恢復，使用上相當彈性方便。

總結來說，AGENTS.md 的重點不是寫得多，而是寫得準。只要內容精簡、明確、可執行，就能讓 Codex 更理解你的專案脈絡，進一步提升輸出品質與工作效率。

[AI 分享] Skill讓AI更專業

 [AI 分享] Skill讓AI更專業

摘要 : Skill將複雜流程從Agent憲法中拆出，讓AI按需載入，減少漂移並複製高手工程經驗。

內容:

前文提到，Agent憲法主要是規範AI在專案中應遵守的原則與邊界，例如哪些事能做、哪些不能做、衝突時該聽誰，以及什麼條件下才算完成任務。但如果把需求整理、開發計畫、除錯流程、驗收方式、程式碼審查與交接規則全部寫進去，內容就會變得過於龐大，不僅佔用上下文，也會增加Token消耗，反而讓AI更難抓住重點。

因此，Skill的角色就非常重要。Skill不是再補一份更長的規範，而是把特定工作流程整理成AI可以在需要時調用的能力模組。它通常在命中相關語意後才載入，所以適合承載那些具體、複雜、但不必每次都常駐的流程。這樣可以讓Agent憲法保持精簡，也讓AI在執行任務時更穩定。

對許多剛開始使用AI開發的人來說，最常見的做法就是直接丟一句話給AI，例如幫我加登入、幫我修錯、幫我優化UI。這樣雖然快速，但AI往往只是根據當下指令自由發揮，沒有穩定流程可依循。它可能這次先拆需求，下次卻直接改程式；這次先驗證Bug，下次卻直接猜測原因，久而久之程式碼就容易變亂，結果也難以保證。

而Skill的價值，就是把有經驗工程師面對不同任務時的標準流程交給AI。若說Agent憲法像專案的員工手冊，那麼Skill就更像各職位的SOP。前者規定原則，後者指導實作。這種分工不但更有效率，也避免所有內容都長期塞在上下文裡，造成額外負擔。

Skill之所以重要，第一個原因是它能減少AI漂移。所謂漂移，就是AI一開始明明在做A，後面卻慢慢偏成做B；原本要求先驗收再交付，最後卻變成寫完就說完成。Skill能將某一類任務的標準方法固定下來，讓AI不是每次都臨時組織做法，而是回到穩定流程中執行。

第二個重要性，在於它能複製高手經驗。很多新手缺少的並不是打程式碼的能力，而是完整的工程思維，例如需求怎麼拆、Bug怎麼查、審查風險怎麼看、上線前該驗證什麼。許多Skill本身就是資深工程師或團隊將自己長期累積的方法論沉澱下來的成果。使用Skill，等於是讓AI把這些成熟經驗帶進當前任務裡。

在實際使用上，Skill不一定需要使用者手動逐一指定。很多AI IDE會根據你的語句，自動判斷要觸發哪一類Skill。例如你提到排查問題，可能會載入除錯Skill；提到開發計畫，可能會載入規劃Skill；提到頁面檢查，可能會觸發前端驗收或瀏覽器相關Skill。當然，使用者也能主動點名，要求AI依指定Skill執行。

此外，Skill也不只是普通提示詞。它通常還會附帶說明文件，包含用途、適用時機、處理流程、輸出要求，甚至可能搭配模板、參考資料、腳本或命令。這代表在某些任務中，Skill不只是提供思路，還可能直接支援安裝、驗證、檢查與執行操作。因此，使用者若不清楚某個Skill怎麼用，最好的方式就是直接詢問IDE，了解它的用途、觸發方式與注意事項。

對一般使用者來說，安裝與理解Skill其實不一定困難。很多時候，只要把Skill連結交給AI IDE，請它協助安裝並確認是否能被工具辨識即可。如果不確定這個Skill適不適合目前專案，也可以直接詢問AI，請它依據專案技術棧、目錄結構、部署方式與既有Agent憲法，幫忙判斷是否適配，甚至進一步調整用法。

總結來說，普通人不必一開始就研究透整套Skill機制。只需要知道三件事：第一，遇到合適的Skill可以交給IDE協助安裝；第二，不懂怎麼用時可以讓IDE解釋；第三，不確定是否適合專案時，可以請IDE結合實際情況幫忙判斷與適配。這正是AI IDE的重要價值，也是Skill能真正幫助新手提升開發品質的原因。

 [AI 分享] 成交關鍵不在產品，在資訊

摘要 : 產品決定復購，資訊決定首次成交；客戶買前無法驗證品質，只能透過你釋放出的資訊做判斷。

內容:

做了15年品牌營銷後，可以總結出一個核心真相：賣東西，並不只是賣產品、賣服務、賣價格，真正影響成交的，是客戶在下單前接收到的資訊。

很多人以為，產品夠好、服務夠強、品質夠穩，客戶自然會買單。但現實是，客戶一開口就問價格、問能不能便宜、問和別家差在哪裡，其實你就已經被拉進價格比較裡了。這時候你再去解釋材料、工藝、服務和品質，客戶往往仍然只盯著價格，因為他還沒有真正感受到你的價值。

原因很簡單：在第一次購買之前，客戶根本無法驗證你的產品到底好不好。他沒用過你的服務，也沒體驗過你的交付與售後，因此他只能透過你對外傳遞的資訊來做判斷。這些資訊包括文案、封面、圖片、詳情頁、短影片、直播間、評論區、客戶案例、銷售話術，甚至是你朋友圈裡說的每一句話。

所以可以記住一句話：產品負責交付，資訊負責成交。產品的好壞，決定客戶會不會再次購買；資訊的好壞，決定客戶願不願意給你第一次機會。

許多老闆賣得很累，不是因為產品不好，而是太相信產品本身。他們以為只要東西夠好，客戶遲早會懂。但客戶不是質檢員，也不是產品經理，他不會花時間研究你的材料、工藝、技術流程。他只會在極短的時間裡問自己四個問題：這和我有什麼關係？我為什麼要停下來？我憑什麼相信你？我為什麼現在要買？

如果你的資訊無法回答這四個問題，那產品再好，客戶也感受不到。當你不主動翻譯價值，客戶就只能用價格來比較你。這也是很多生意陷入價格戰的真正原因，不是市場太卷，而是你傳遞出去的資訊，剛好只適合被拿去比價。

舉例來說，同樣是一支手機，如果你只講晶片升級、螢幕更亮、相機畫素更高、電池更大，客戶聽完通常只會問多少錢、值不值得換、別家是不是更便宜。因為這些都是引數，而引數天生就容易被比較。真正會賣的品牌，會把晶片翻譯成打遊戲不卡，把相機翻譯成晚上拍孩子也清楚，把續航翻譯成出門一天不用帶充電寶，把螢幕翻譯成太陽底下也看得清楚。產品沒有變，但資訊變了。普通資訊講的是「我有什麼」，高級資訊講的是「你會得到什麼」。

再比如外送平台上的一碗牛肉飯，一家店只寫「招牌牛肉飯28元」，另一家店寫「現炒牛肉、熱飯熱菜、30分鐘送到，適合加班晚餐，吃完不將就」。後者不一定更好吃，但更容易讓人下單。因為它賣的不只是一碗飯，而是加班後的一口熱飯，是不用糾結晚餐吃什麼，是不用下樓排隊，是不用將就冷掉的食物。客戶雖然無法先驗證味道，但會先被資訊打動。

真正有效的成交資訊，可以分成四個層次：看見、認可、信任、依賴。

第一層是看見。看見不只是客戶刷到你，而是願意為你停下來。你的標題、封面、短影片前三秒、詳情頁首屏、直播間第一眼，能不能讓客戶繼續看，這才是關鍵。看見的核心不是讓客戶看到你，而是讓客戶在你的內容裡看到自己。比如賣減脂餐，與其一開始講低卡、高蛋白、營養均衡，不如先說「下班已經很累了，別再靠意志力決定晚飯吃什麼」，這樣客戶更容易有感。

第二層是認可。客戶停下來之後，不會立刻購買，他會先判斷你有沒有用。這時候如果你只是不斷講自己的原料好、團隊專業、設備先進、服務周到，效果通常有限。客戶真正關心的是：我能得到什麼？我能少什麼麻煩？我能降低什麼風險？我能獲得什麼結果？所以認可的關鍵，就是把你的優勢翻譯成客戶的利益。發貨快，對客戶來說叫不用等；服務好，叫出問題有人管；品質穩定，叫不用反覆試錯；流程成熟，叫交給你更省心。

第三層是信任。認可不代表成交，因為信任解決的是「我會不會踩坑」。客戶會懷疑你說的是真的嗎？有人買過嗎？交付怎麼樣？售後可靠嗎？這時候，信任不能靠口頭保證，而要靠證據建立。真實案例、客戶評價、前後對比、交付流程、產品細節、常見問題、售後承諾、復購紀錄，這些才是讓客戶放心的關鍵。

像山姆、Costco這類會員店，厲害的不只是商品多或價格便宜，而是它們替客戶做了篩選。客戶相信這裡的商品大機率不容易踩坑，所以買的不只是商品，而是一種被篩選過的安心感，也是一種信任你的判斷力。

第四層是依賴。一次成交不難，真正有價值的是讓客戶下一次還找你，甚至一想到某個需求，第一個就想到你。這種依賴不是靠一次交易建立的，而是靠持續輸出資訊、持續解決問題、持續降低選擇成本、持續提供方法與判斷。最高級的成交，不是客戶被你說服，而是客戶覺得找你最省心，懶得再去比較別人。

所以，別再只是反覆問「我的產品哪裡還不夠好」，你更該問的是：客戶第一眼看見我時，接收到的是什麼資訊？客戶看完內容後，知不知道我解決什麼問題？客戶猶豫時，我有沒有提供足夠證據讓他放心？客戶買完之後，有沒有理由再回來找我？

最後要記住，產品當然重要，因為沒有好產品，再好的資訊也只能換來一次成交，後面終究會被口碑反噬。但如果只有好產品、沒有好資訊，客戶甚至不會給你第一次體驗的機會。

總結一句話：產品好，決定客戶會不會復購；資訊好，決定客戶會不會成交。

[AI 分享] Vibe Coding立項先行

 [AI 分享] Vibe Coding立項先行

摘要：Vibe Coding做專案時，先和AI完成立項討論與文件沉澱，比急著寫程式碼更重要。

內容:

前面已經談過 AI IDE、Agent、憲法、Skill，以及前端、後端、資料庫等基本開發認知。到了真正進入專案實作階段，最重要的第一步不是馬上寫程式碼，而是先完成立項。

很多新手在使用 AI 做專案時，常常一有想法就直接要求 AI 幫忙生成整個專案。看起來速度很快，但其實風險很高。因為專案開發就像蓋房子，必須先打好地基；如果產品方向、資料結構、頁面流程或功能邊界一開始就沒有想清楚，後面發現錯誤時，往往不是改幾行程式碼就能解決，而是整體都要重來。

更麻煩的是，AI 在重構時不一定會完全乾淨地重做，常常會留下死程式碼、過度相容舊邏輯，甚至不斷打補丁，最後把整個專案結構弄亂。因此，Vibe Coding 的核心不是一句話讓 AI 變出完整專案，而是在規則、流程與基本技術認知下，讓 AI 協助你一步步把專案做出來。

正式開始前，建議先建立一個空的專案資料夾，並用 AI IDE 開啟。這個資料夾一開始可以沒有任何程式碼，它的用途是作為專案的獨立空間，方便後續存放立項文件、開發規劃、Agent 憲法與專案說明等內容。資料夾名稱最好使用英文，搭配中劃線或底線，例如 task-manager 或 resume-assistant，避免使用中文、空格、特殊符號，或像 demo1、測試專案這類隨意命名。清楚的專案命名，對後續開發、部署、版本管理以及 AI 理解專案都更有幫助。

之所以要先討論，是因為 AI 雖然能寫程式碼，但不能替你決定產品真正要做什麼。像是產品面向誰、解決什麼問題、核心功能是什麼、使用者為什麼要用、第一版應該做到什麼程度、哪些功能之後再做、哪些現在不該碰，這些都必須先釐清。

立項階段和 AI 討論，主要有三個目的。第一，是讓 AI 對專案建立基本認知，不只是知道你要做個後台或小程式，而是理解產品類型、目標使用者、核心問題與主要流程。第二，是幫助你完善想法，因為很多初步構想其實還很粗糙，透過 AI 追問與分析，能更早發現自己沒想清楚的地方。第三，是讓 AI 幫你查漏補缺，例如你可能只想到功能，卻忽略了權限、資料設計、後續擴充性等問題。

和 AI 討論時，不需要一開始就說得很複雜。你可以先簡單描述自己想做的產品類型與大概功能，請 AI 協助分析核心設計、判斷想法是否可行，甚至主動追問你。這個階段的重點不是讓 AI 開寫，而是讓它扮演產品合夥人與架構顧問，協助你拆解需求、界定 MVP、分析使用者場景、整理核心功能、梳理資料流與推演使用流程。

如果腦中只有一個模糊方向，也可以直接告訴 AI，請它陪你一起梳理專案應該怎麼做。等專案輪廓初步清楚之後，還可以進一步讓 AI 幫你搜尋與分析競品、參考開源方案、找出差異點與切入機會。有時候你以為是新想法，其實市場上已經有類似產品；也有可能只是換個使用場景，就能找到新的價值定位。

到了更後面，AI 還可以幫你規劃長期路線，例如第一版先做什麼、第二版擴充什麼、哪些功能後面再處理、哪些模組現在就要先保留邊界。這些討論越清楚，後續開發就越不容易失控。

特別要注意的是，在立項階段不要讓 AI 直接開始寫程式碼。很多 AI 一看到你說要做專案，就會立刻建立檔案、安裝依賴、生成頁面和 API。這時候你必須明確阻止它，告訴它目前只做產品討論與立項設計，暫時不要寫程式碼。因為此時產品定位、功能邊界、技術路線與驗收標準都還沒沉澱下來，太早進入開發，只會讓專案提早陷入混亂。

當討論差不多之後，下一步就是讓 AI 在專案資料夾中整理並生成立項文件。這份文件非常重要，因為它會成為後續開發的依據。之後無論是寫程式碼、拆任務、設計資料庫、規劃前後端介面，都可以回到這份文件確認方向。如果沒有文件，專案在多輪對話與反覆修改中很容易飄移，今天設定給個人用，明天 AI 可能寫成企業後台；今天說第一版只做核心流程，明天又可能被塞進一堆不必要的複雜功能。

如果專案很小，一份立項文件就足夠；如果專案稍微複雜，可以拆成幾份，例如專案立項說明、詳細規劃、商業計畫或長期路線等。格式不必過度糾結，重點是這些文件要能讓你和 AI 都看得懂，並在後續開發中持續拿來對照，避免專案偏離原本目標。

此外，立項也不是追求一次到位的完美。尤其對新手來說，最重要的不是產出一份無懈可擊的文件，而是先把目前能確定的內容寫下來。像是專案是什麼、給誰用、解決什麼問題、第一版做什麼、暫時不做什麼、未來可能如何擴充，這些只要先整理清楚，就已經比一句「幫我做個專案」成熟許多。之後隨著討論、開發與驗證的進行，文件本來就可以持續更新。

總結來說，Vibe Coding 做專案的第一步不是寫程式碼，而是立項。你需要先學會和 AI 討論產品，讓它理解你的想法，也利用它幫你完善想法。等方向清楚後，再把討論結果沉澱成專案文件。這樣 AI 後續才知道專案是什麼、第一版要做什麼、哪些功能暫時不碰，以及未來大致往哪裡發展。真正穩妥的做法，是先建立空專案資料夾，用 AI IDE 開啟，從討論開始，把專案聊清楚，再讓 AI 正式動手。

[AI 開發] AI寫程式不跑偏的分階段管理法

 [AI 開發控] AI寫程式不跑偏的分階段管理法

摘要 : 用實施文件拆解任務，搭配分階段驗收，能有效避免AI寫程式時自由發揮、功能跑偏與架構失控。

內容:

很多人讓AI寫程式時，前面其實已經想了很多功能細節，也和AI討論得很清楚，原本以為方向既然定了，AI就能照著思路一步步完成專案。但實際情況常常不是這樣，AI不是加了一堆沒意義的功能，就是該做的功能沒做好。對不懂程式碼的人來說，更難自行核對，只能一輪一輪叫AI修改，結果越改越亂，最後不是重構就是直接放棄。

這篇內容的核心，在講真正開始寫程式之後，怎麼讓AI一個階段一個階段穩定往前推，避免中途跑偏。尤其對沒有技術背景的人來說，AI雖然像一把利器，但同時也很難駕馭。如果只是隨手丟一句需求給AI，往往就像在開盲盒，結果充滿不確定性。

要讓AI穩定做專案，重點其實只有兩件事。第一，是把目前要做的大階段拆成足夠細的實施文件；第二，是讓AI嚴格按照這份文件，一個子階段一個子階段執行，而且每完成一段就先驗收，再進入下一步。這樣才能降低AI自由發揮的空間。

所謂把大階段拆細，是因為大階段的描述通常太粗。像是「先做一個買家可以下單付款的最小可用版本」，這種話對人來說好像很清楚，但對AI來說卻會變成自行腦補流程、順序和完成程度。最後做出來的內容，常常不是你真正想要的。所以在寫程式之前，應該先把當前大階段拆成幾個子階段，再把每個子階段拆成更小的步驟。

拆解的目標不是越細越好，而是要細到讓AI清楚知道三件事：這一步要做什麼、做到什麼程度才算完成、哪些事情現在先不要碰。同時，每一步也要附上驗收標準與驗證方式，確保任務不只是能執行，還能驗收，而且邊界明確。

這份文件不只是拿來參考，而是每次開工前都要要求AI對照執行。這樣AI才知道這一輪只該做哪些內容，不容易自己延伸。這份文件可以視為該階段的「單一可信來源」，也就是這一階段的開發與驗收，都要以它為準。聊天過程中臨時冒出的想法，不是不能加，但必須先更新回這份文件，才算正式變更。

另外，也不需要一開始就把所有大階段都拆成這種細部實施文件。比較好的方式是，只拆目前馬上要做的那一個大階段，後面的階段先保留方向即可。因為專案進行中需求很可能會調整，如果太早把後面所有內容都寫得很細，之後一改動，前面整理的大量細節很可能就白做了。

不過，需求雖然可以微調，有一條底線不能隨便破壞，就是不要在已經開始寫程式之後，動不動就去改底層架構。像是技術棧、目錄結構、資料庫表設計、核心欄位存法、登入權限、支付流程等，這些都屬於地基。業務細節可以修，但如果一個改動會動到地基，就不能直接讓AI順手改下去，而是要先請AI做影響評估，說明影響範圍，再提出穩妥的調整方案。

如果沒有先評估，就直接丟一句「先滿足需求再說」，AI很可能為了配合需求，把原本的架構破壞掉。那樣一來，前面做的立項、技術選型與架構規劃，就可能全部白費。因此，在真正實作前，仍然要維持架構層面的紀律。

當你要AI幫忙拆解階段時，可以直接要求它根據功能清單與階段計畫，整理出一份詳細的實施文件。內容要包括：先拆成幾個子階段、每個子階段再拆成哪些步驟、每一步要做什麼、做到什麼程度、涉及哪些功能、驗收標準是什麼、用什麼方式驗證，以及暫時不做哪些事。這個階段先不要寫程式，只專心把文件定清楚。

文件拆好之後，你一定要先看過。這不只是給AI執行時看的，也是你在動手寫程式前，最後一次跟AI對齊需求的機會。如果你發現文件和原本想法有偏差，就先討論清楚並修正。如果看不懂，就直接請AI用白話一條條解釋。甚至你可以把最初的需求重新貼給AI，請它反過來檢查這份文件有沒有和需求衝突，或有沒有需要先釐清的地方。

等文件定好後，才進入真正的執行階段。這裡最大的風險叫做「飄移」，也就是AI寫著寫著偏離了原本的計畫。它可能會自己擴充你沒要求的功能，也可能漏掉該做的內容。為了防止這種情況，每次開始一個子階段前，都要先給AI一段明確指令，例如要求它嚴格遵守既定規則與實施文件，只實作當前子階段，不要超出範圍，做完後停下來回報，不要自動進入下一個子階段。

這種做法等於同時畫了兩條邊界，一條是AI做事的方法邊界，一條是這次任務的內容邊界。只要這兩條邊界清楚，AI亂跑的機率就會大幅降低。如果你使用的Agent工具有自動執行模式，更要注意不要讓它一路做到自己認為完成為止，而是每完成一段就停下來，先驗收再繼續。

在每個子階段完成後，你不一定要自己看程式碼，也可以直接要求AI回報三件事。第一，對照實施文件，哪些內容已經做完，哪些還沒完成；第二，它具體修改了哪些地方，有沒有漏做或多做；第三，它是怎麼驗證的，驗證結果是什麼，下一步應該做哪個子階段，理由是什麼。透過這三組問題，就能快速判斷AI是不是還在按照文件前進，還是已經開始憑感覺行動。

如果AI提出的下一步和文件內容對不上，就表示它的理解已經偏掉了，這時應該先把它拉回來，而不是放任它繼續做下去。如果它的說明你看不懂，也不要硬撐，直接要求它對照文件，用白話重新講一次做了什麼、還差什麼，以及驗證結果代表什麼。每個子階段都這樣確認沒問題後，再進入下一階段。

整體來看，這套方法的核心，就是不要讓AI憑感覺寫程式，而是讓它始終有文件可以對照、有邊界需要遵守、有驗收標準可以回報。即使你不懂程式碼，也能透過文件、範圍控制與驗收證據，把專案方向穩穩抓在自己手上。

[AI 分享] PDF型RAG處理思路

 [AI 分享] PDF型RAG處理思路

摘要 : PDF做RAG不能只轉文字切片，重點在辨識類型、保留結構、語意切分、可追溯引用與多工具協作。

內容:

當 agent 做 RAG 時，知識庫裡是一堆 PDF 該怎麼處理，不能只回答「先轉文字、再切片、再丟向量庫」。這種答案太表面，因為真實專案裡的 PDF 往往不是乾淨的純文字，而是充滿各種複雜結構與格式問題。

實務上，PDF 可能是合約、財報、掃描件、技術文件，裡面會包含條款、表格、圖表、圖片、雙欄排版、流程圖、程式碼區塊、註腳、頁首頁尾等內容。若直接把它當成一般文本抽取，後續很容易出現切片斷裂、表格結構混亂、頁首頁尾重複召回、圖片資訊遺失等問題。最終模型雖然能回答，但常常無法正確引用原文，來源也難以對應。

這題真正考的，不是會不會把 PDF 存進向量庫，而是有沒有理解 PDF 型 RAG 的難點在於：能不能正確讀懂、正確切分、正確引用。

第一步是先判斷 PDF 類型，而不是急著抽文字。若是原生文字型 PDF，例如說明書、產品文件、論文，可以直接做文字解析；若是掃描型 PDF，例如紙本合約、發票或拍照轉成的檔案，就必須先透過 OCR 做文字辨識；若是圖文混排、表格密集或含大量流程圖與截圖的 PDF，就不能只靠文字抽取，而要搭配版面分析、視覺理解，甚至多模態模型一起處理。因為一開始類型判斷錯了，後面的切片、檢索與回答都會跟著失真。

第二步是盡量還原文件結構。PDF 處理很常見的錯誤，就是把整份文件抽成一大段純文字，這樣雖然快，但會犧牲掉很多關鍵上下文。例如合約中的章節、條款、附件編號，或財報中的表格名稱、年份、指標欄位，這些資訊如果遺失，模型即使抽到一句內容，也不知道它屬於哪一頁、哪一章、哪一個條文，自然難以驗證與追溯。

因此在生產環境中，應盡量保留頁碼、標題層級、章節關係、段落邊界、表格位置、圖片說明、註腳與頁首頁尾等結構資訊。更重要的是，每一段內容都要知道自己在原文中的位置，這樣後續才能支援引用、校驗與來源追蹤。

第三步是按語意切片，而不是機械式固定字數切分。很多人習慣每 500 字或 800 字切一段，但 PDF 的內容通常不適合這樣做。標題和正文不能隨便拆開，合約條款最好保持完整，表格也不能當一般段落切開，圖表內容更不能直接忽略。

更好的方式是根據語意與結構切分，例如同一標題下的數個段落可以組成一個 chunk，合約中的單一條款盡量完整保留，表格可以單獨轉為結構化文本，圖表則可先生成摘要，再連同頁碼與標題一起保存。每個 chunk 都應附上 metadata，例如文件 ID、頁碼、章節標題、條款編號、表格編號、圖片描述與版本時間等，讓檢索結果不只是孤立句子，而是帶著上下文與來源資訊的內容單元。

若要做得更精細，還可以為每個 chunk 補充一段上下文說明，例如註記這段內容來自某份合約的付款條款，主要說明尾款支付條件。這樣模型在檢索回來後，不只看到片段，還能更快理解它在整份文件中的語意角色。

第四步才是 agent 層的工具設計。到了 agent 使用階段，不建議把整份 PDF 一次塞進上下文，這樣既浪費 token，也容易讓模型抓不到重點。更合理的方法，是把 PDF 處理能力拆成多個工具，讓 agent 根據問題類型按需呼叫。

例如可以設計 Search PDF 來做片段檢索，Read Page 用來讀取指定頁內容，Extract Table 專門抽取表格，Chart Analysis 或視覺分析工具用來理解圖表，Citation Source 則負責返回頁碼與原文引用。這樣當使用者問簡單問題時，agent 可以先檢索相關段落；當使用者問跨年度比較、數據變化趨勢等複雜問題時，agent 就能進一步定位章節、抽取表格、做整理與歸納；如果問的是流程圖或圖片內容，就要交給視覺分析工具，而不是只靠文字搜尋。

回答這題，最後最好補充生產級細節：PDF 型 RAG 一定要做到可追溯引用，也一定要建立評測機制。回答內容最好附上頁碼、章節、原文片段，甚至表格編號，否則模型說得再自然，也很難確認它是不是憑空編造。

而評測也不能只看最後答案對不對，還要往下拆成更細的品質指標，例如檢索片段是否正確、頁碼是否準確、表格有沒有被解析錯亂、OCR 是否漏字、圖表資訊是否被正確理解、原文引用是否真的能支撐最終回答。這些細節，才是真實業務裡最容易出問題的地方。

總結來說，這題的成熟回答不是「PDF 轉文字後向量化」而已，而是先辨識 PDF 類型，再選擇合適的解析方式；接著保留文件結構，依語意進行切片；對表格、圖片與圖表做專門處理；最後讓 agent 透過工具鏈按需檢索、讀頁、抽表、看圖，並全程保留引用與評測閉環。這樣的回答，才能讓面試官知道你不是只做過簡單 demo，而是真的理解 PDF RAG 在生產環境中的核心難點。

[AI 分享] 吳恩達AI Agent課程重點整理

 [AI 分享] 吳恩達AI Agent課程重點整理

摘要 : 濃縮吳恩達8小時AI Agent課程，快速理解什麼是Agent、如何搭建，以及最常被忽略的評估關鍵。

內容:

這次內容主要是把吳恩達釋出的 AI Agent 完整課程重點濃縮整理，幫大家省下八小時的學習時間。即使你不會寫程式、沒有技術背景，只要平常有在使用 ChatGPT、Gemini 這類 AI 工具，也能透過這份整理快速掌握核心觀念。

首先，AI Agent 其實沒有很多人想像中那麼複雜。最簡單的理解方式，就是替 AI 加上「自己做決定」和「使用工具」的能力。過去的大語言模型通常是你問一句、它答一句，任務到此結束；但 Agent 不一樣，它可以自己拆解任務、決定步驟、選擇工具，逐步完成整件事。

整個概念可以分成三個層次來理解。第一層是大語言模型，也就是我們熟悉的 ChatGPT、Claude、Gemini。這類模型的特點是輸入問題、輸出答案，但它有兩個限制：第一，它不知道你的個人資料或外部即時資訊；第二，它是被動的，你不下指令，它就不會主動行動。

第二層是 AI Workflow，也就是 AI 工作流。這一層是在大語言模型上增加固定步驟，讓 AI 在回答問題前，先去查日曆、待辦事項或其他資料來源。這樣它能回答得更準確，但本質上仍然只是照著你事先設定好的流程走。只要真正做決策的人還是你，那它就還不算 Agent。像常聽到的 RAG，本質上也是一種先查資料再生成答案的工作流。

第三層才是真正的 AI Agent。從 Workflow 升級到 Agent 的核心差異，在於「做決定的人從你變成 AI」。你不需要替它規劃每一個步驟，只要告訴它最終目標，例如幫你完成一份週報，它就會自己決定去哪裡蒐集資料、怎麼整理內容、是否需要檢查品質，甚至反覆修改直到結果夠好為止。

這裡有一個重要概念叫做 ReAct，也就是 Reasoning 加上 Action，代表推理與行動。真正的 AI Agent 必須同時具備這兩種能力：先想清楚怎麼做，再實際去做。它不只是會回答問題，更能採取行動、使用工具、持續迭代。

如果要搭建一個 AI Agent，核心可以拆成三塊積木。第一塊是模型 Model，也就是 AI 的大腦，負責理解、推理、產生內容。第二塊是工具 Tool，也就是讓 AI 能與外部世界互動的能力，例如查詢資料庫、讀取日曆、存取訂單系統、發送訊息等。第三塊則是評估 Evaluation，負責檢查結果品質、替輸出打分，判斷任務是否真的完成得夠好。

其中，工具的作用特別容易從實際場景看出來。以電商客服為例，當客戶反映尺寸寄錯，AI 模型本身可以先理解訊息內容，抓出關鍵資訊；接著需要透過工具連接後台系統，查詢訂單、物流與庫存；最後再利用模型撰寫回覆，並透過另一個工具把訊息真正發送出去。這就是模型與工具互相配合的完整過程。

而整份內容最重要的一個提醒，就是大多數人最容易忽略的「評估」。很多人在談 AI Agent 時，只關注模型夠不夠強、工具接得多不多，卻忽略了最後怎麼判斷結果是好還是不好。其實評估才是讓 Agent 能真正穩定運作的關鍵，因為沒有評估，AI 就無法知道自己是否做對、是否需要修正，也無法持續提升表現。

總結來說，AI Agent 的本質不是神秘的新技術，而是讓 AI 從單純回答問題，升級成能自主思考、使用工具並完成任務的系統。理解它的最好方式，就是先分清楚大語言模型、工作流與 Agent 的差異，再掌握模型、工具、評估這三大核心結構。只要把這些概念搞懂，你就已經具備進一步實作 AI Agent 的基礎了。

[AI 分享] Codex三種電腦操控方式解析

 [AI 分享] Codex三種電腦操控方式解析

摘要 : 一文看懂Codex的Computer Use、Chrome擴充套件與內建瀏覽器差異，快速選出最適合自己的使用方式。

內容:

OpenAI開發者體驗工程師、前Meta資料科學家 Jason Liu 近期分享，Codex 目前有三種主要方式可以操控電腦執行任務，分別適合不同場景。理解它們的能力邊界，才能真正發揮 AI Agent 的效率。

第一種是 Computer Use，這是目前 Codex 在操控電腦方面能力最強、應用範圍最廣的方式。它可以模擬使用者在電腦上的大部分操作，只要是滑鼠能點、鍵盤能輸入的地方，理論上都能處理。不論是微信、飛書，還是 Excel 等桌面軟體，甚至跨多個應用切換，它都能執行。

Jason Liu 分享了一個實際案例：有次他的包裹被偷，但亞馬遜客服排隊等待時間長達 25 分鐘，於是他讓 Codex 每 5 分鐘檢查一次客服視窗，等客服即將接通後再改成每分鐘檢查，並嘗試完成退款申請。等他回來時，退款流程已經處理完成。這顯示出 Computer Use 很適合接手那些繁瑣、耗時、必須盯著流程的任務。

不過，Computer Use 也有明顯限制。由於它每一步都需要先理解畫面，再判斷位置、進行操作，因此速度相對較慢。這種方式不適合追求極致效率的情境，但很適合那些沒有 API、沒有外掛、只能依靠圖形介面完成的工作。

第二種是 Codex Chrome 擴充套件，這類方式更適合發生在瀏覽器中的任務，尤其是需要登入狀態的網站，例如飛書文件、淘寶商家後台、B站創作中心等。這些平台依賴使用者當前的帳號登入資訊，而 Chrome 擴充套件可以直接基於你已登入的瀏覽器環境進行操作。

它和 Computer Use 最大的不同在於，Computer Use 是透過「看螢幕、點按鈕」來完成任務，而 Chrome 擴充套件則是直接進入瀏覽器工作流。它能讀取網頁內容，也能在多個分頁之間切換，例如先查資料、再交叉比對、最後整理輸出結果。因此，在純瀏覽器場景下，Chrome 擴充套件通常會比 Computer Use 更快、更準確。

Jason Liu 表示，他自己經常使用 Chrome 擴充套件來檢查私訊、瀏覽新聞、蒐集回饋，並將有價值的內容整理儲存到本地檔案，方便後續反覆查看。不過，這種方式的權限也更敏感，因為它使用的是你的真實登入狀態，所以網站會將所有點擊、輸入與提交視為你本人操作。因此，資訊蒐集、內容整理可以交給它，但像傳送訊息、確認付款這類高風險動作，仍建議由使用者自行確認。

第三種是內建瀏覽器，這種方式更偏向開發者使用，特別適合做網頁開發、前端頁面預覽與本地工具除錯。例如當你正在開發一個前端頁面時，可以讓 Codex 開啟本地預覽網址，檢查版面配置是否正常、按鈕是否錯位、手機端是否有溢位問題。檢查完成後，它還可以直接修改程式碼，再重新打開頁面驗證結果。

內建瀏覽器最有價值的地方，在於它把「寫程式碼」與「看結果」串接成一個完整流程。因此，它不是拿來登入網站或處理帳號任務的工具，而更像是 Codex 在開發與介面除錯時的專屬工作台。

如果要快速選擇使用方式，可以這樣理解：需要登入狀態的網站任務，優先使用 Chrome 擴充套件；需要操作桌面軟體，或在多個應用之間切換時，選擇 Computer Use；需要開發網頁、預覽頁面、除錯介面時，則使用內建瀏覽器。

Jason Liu 也特別提醒，如果任務本身可以透過外掛、MCP 或 API 等結構化工具完成，應優先選擇這些方式。像是讀取飛書文件、整理線上表格，如果能直接呼叫介面，通常會比讓 Codex 透過畫面模擬點擊來得更準確、更高效。

這也說明了一個重要觀點：Codex 操控電腦不是越像人越厲害，而是越能根據任務選對入口越強。真正高效的 Agent，不是接到任務就盲目點滑鼠，而是知道什麼時候該用 API，什麼時候該進瀏覽器，什麼時候該接管桌面。

從這個角度來看，Codex 早已不只是寫程式碼的工具，而是逐漸成為一套圍繞電腦、瀏覽器與本地專案運轉的任務執行系統。對想提升效率的人來說，重點不只是會不會用 AI，而是能不能根據任務場景，挑對最合適的工具入口。