[AI 分享] 心理登月

 [AI 分享] 心理登月

摘要 : 真正提升體驗，不一定靠高成本改善物理效率，更關鍵的是降低使用者的不確定與焦慮。

內容:

多數人做產品、服務或體驗優化時，第一反應都是解決物理問題：速度太慢就加資源，流程太卡就做優化，服務不好就加人培訓。這種工程師思維沒有錯，但常常花大錢，卻未必真正打中使用者最在意的地方。

澳美副董事長 Rory Sutherland 提出一個重要觀點：工廠裡製造出的物理價值，和人腦裡感知到的心理價值同等重要，而且很多時候，心理價值的槓桿率甚至高出數十倍、上百倍。他把這種用低成本大幅改善感受的方式，稱為「心理登月」。

第一個例子是歐洲之星。原本有人想花 60 億英鎊，把倫敦到巴黎的車程縮短約 30 分鐘；但 Sutherland 提出另一個思路：如果只花約 1% 的成本，用 WiFi、餐飲升級與更好的服務，讓乘客在旅途中更舒服、更享受，乘客主觀感受上的提升，可能比實際縮短時間還大。工程師想的是「怎麼更快」，而他想的是「怎麼讓旅程更爽」。

第二個例子是 Uber 的叫車地圖。這個功能並沒有讓車來得更快，但它大幅降低了使用者的焦慮、退單率，提升了滿意度與復購率。因為人們真正討厭的往往不是等待本身，而是不知道還要等多久、不知道車在哪裡、司機會不會失約。地圖把「不確定」變成「可預期」，於是等待品質徹底改變。

這個觀點帶來三個啟發。第一，當你想改善體驗時，先問自己要解決的是物理問題還是心理問題。第二，當使用者抱怨時，不要只照著表面問題下手，而要追問他真正難受的是慢、被忽視，還是不確定。第三，重新審視生活中所有令人焦躁的場景，例如排隊、等電梯、等醫生、等外賣、等訊息，裡面都可能藏著一次低成本高回報的「心理登月」機會。

核心結論是：真正高槓桿的創新，未必是大幅改變現實，而可能是在現實幾乎不變的情況下，顯著改善人的心理感受。誰能用更低成本把「不知道」變成「知道」，誰就更可能創造出遠超成本的價值。

[AI 提醒] Vibe Coding 後端安全驗收重點

 [AI 安全] Vibe Coding 後端安全驗收重點

摘要 : 功能正常不代表後端安全，需重點檢查權限、輸入、密碼與資料歸屬等風險。

內容:

很多人用 Vibe coding 寫後端時，最容易放鬆警惕的時刻，就是功能看起來都正常、流程也都跑通，AI 還告訴你「沒問題，可以上線了」。但功能能跑，只代表正常流程成立，不代表後端已經安全。

後端安全真正要看的，不是「正常的人能不能用」，而是「不該通過的請求，能不能被擋下來」。這和前端不同，前端出問題常常一眼就能看到畫面亂掉，但後端安全問題往往藏在看不見的地方，對沒有技術背景的人更難判斷。

這篇重點放在後端安全裡最常被忽略、也最容易和業務功能混在一起的一塊：介面與系統許可權設計。也就是當使用者發出請求後，後端到底能不能正確判斷這個請求該不該被執行。

第一步，要先把安全拆成明確邊界。後端安全不是一個單點，而是分散在請求處理的每一道關卡裡，包括身份認證、許可權控制、輸入校驗、資料歸屬與注入防護。每一層都在擋不同風險，少了一層，就可能多一個漏洞。所以不要只接受「已做安全處理」這種籠統說法，而是要請 AI 逐項交代：風險是什麼、在哪裡處理、規則是什麼、如何驗證、哪些還沒驗證。

第二，介面輸入預設都不可信。因為真正想繞過規則的人，不會照著你前端頁面操作，而是直接對後端 API 發請求。前端上的格式限制、按鈕置灰、欄位隱藏，對這類行為幾乎沒有保護力。真正影響結果的欄位，例如價格、數量、角色、使用者 ID、訂單歸屬、資料狀態，都必須由後端重新檢查，不能因為前端有傳值就直接相信。

第三，密碼與管理員帳號必須有強制規則。密碼安全至少要確認兩件事：一是密碼不能太弱，避免被暴力破解或撞庫；二是密碼不能明文存進資料庫，必須經過雜湊處理。尤其管理員帳號風險更高，若密碼過弱或保護不足，影響的不是單一使用者，而可能是整個系統。因此註冊、登入、修改密碼、重設密碼、建立管理員帳號等流程，都應該明確檢查密碼強度、限制登入失敗次數，並標示哪些地方尚未驗證。

第四，系統許可權設計一定要提前定義。要先分清楚「登入」和「許可權」不是同一件事。登入只是證明你是誰，許可權才是決定你能做什麼。常見風險有兩種：一種是普通使用者進入只有管理員能用的功能，這是垂直越權；另一種是使用者雖然已登入，卻能操作不屬於自己的資料，這是水平越權。很多專案只做了登入檢查，卻沒檢查資料是不是本人所有，結果就出現資料外洩或誤改。

如果系統裡有多種角色，例如普通使用者、商家、營運、管理員，那在功能設計階段就應先定好哪些介面要登入、哪些角色能訪問、哪些資料只能操作自己的、管理員能不能跨資料查看。否則 AI 在後續生成程式碼時，常會用猜的，導致整個許可權邏輯前後不一致。

第五，不要讓使用者輸入直接進入關鍵語句。這類風險叫做注入，意思是原本應該只是資料的輸入，卻被系統當成指令執行。最典型的是 SQL 注入，也可能出現在系統命令、HTML 或模板拼接中。這類問題不一定會立刻出錯，甚至表面看起來一切正常，但實際上可能已經留下能被利用的入口。

整體來說，你真正該問 AI 的，不是「我的專案安不安全」，而是「風險在哪裡、規則在哪裡、誰負責攔、怎麼證明攔得住」。只有把這些問題拆清楚，安全驗收才有意義。

如果 AI 回答得太技術、太難懂，不要硬看，直接要求它改用白話再講一次。因為看不懂的安全說明，本身就不能算是合格的驗收結果。真正能幫你判斷能不能上線的，不是那句「沒問題」，而是每一道安全關卡都有具體規則、具體位置與具體驗證方式。

 [AI 分享] Vibe Coding 先定技術路線

摘要 : 用AI做專案別急著寫程式，先確定產品形態與技術棧，選成熟方案並寫進文件，避免專案一路跑偏。

內容:

如果你一開始就讓 AI 直接寫程式碼，專案很可能從第一步就開始跑偏。剛開始用 AI 做專案的人，最缺的通常不是寫程式的能力，而是不知道應該讓 AI 依照什麼技術路線、框架規範與開發邊界來執行。

AI 很強，但如果沒有明確邊界，它就容易自由發揮，今天這樣寫、明天那樣改。最後表面上看起來能跑，實際上專案內部可能已經變得很混亂。因此，立項之後不要急著開發，先確定技術棧才是更重要的下一步。

所謂技術棧，可以簡單理解成這個專案要用哪些技術、框架、工具與 SDK 來完成。你做的是網站、小程式、APP，還是純後端介面，不同產品形態會直接決定後續的開發方式。產品形態不同，技術棧就不同，連帶影響專案結構、開發流程與部署方式。

第一步，是先確定產品形態。你要先問自己，這個產品最後是以什麼形式提供給使用者？是網站、小程式、APP、後台管理系統，還是只提供給其他系統呼叫的純後端介面？如果這個問題還答不上來，就不適合讓 AI 開始寫程式，因為連產品形態都沒確定，後面的技術選型一定會混亂。

如果做的是網站，就優先考慮 Web 前端技術棧；如果做的是小程式，就要遵守對應平台的開發規範；如果做的是 APP，就要思考原生、跨平台或其他技術方案；如果是純後端介面，重點則會落在 API 設計、資料庫與服務部署，而不是前端。

如果你無法判斷產品應該做成哪種形態，可以請 AI 根據立項文件來分析，結合產品目標、使用場景、核心功能與後續規劃，判斷最適合的形式並說明理由。重點不是讓 AI 隨便替你拍板，而是讓它基於已知事實，給出清楚的主線判斷。對新手來說，真正需要的不是很多看似合理的方案，而是一條當下最適合執行的方向。

第二，技術棧不是越高級越好。很多新手很容易被流行框架或新工具帶偏，今天看到這個很火，明天又覺得那個很新，就認為自己的專案也應該跟上。但做專案不是比誰技術名詞多，尤其在用 AI 開發時，更不能為了看起來厲害就亂選技術。

如果只是一般官網，未必需要一開始就搭很複雜的前後端架構；如果只是輕量工具，也不一定要引入大型框架。當你連部署、維護與後續更新都還沒想清楚時，過度追求高級技術，只會讓專案更難收尾。技術選型最重要的從來不是新，而是合適。它要適合產品形態、專案複雜度，也要適合 AI 理解與後期維護。

第三，優先選成熟框架與 SDK。現在很多常見功能其實早已有成熟方案可用。專案中會遇到的技術棧、功能模組、第三方 SDK，通常都有現成輪子。這些成熟方案不只是讓你開發更快，更重要的是能幫你減少大量試錯、重寫與踩坑時間。

尤其對不會寫程式的人來說，更不應該讓 AI 在沒有框架約束的情況下從零亂造。成熟框架的價值，不只是提供現成能力，更在於它通常自帶專案結構、開發規範、最佳實踐與社群經驗。它不只告訴你能怎麼寫，也告訴你應該怎麼寫。

新手最缺的往往就是規範。AI 雖然是很強的編碼助手，但如果缺乏規範，它很容易亂寫、繞路、補丁式修修補補。相反地，如果你選擇成熟框架，並且明確要求 AI 必須遵守官方規範、目錄結構與推薦寫法，專案品質通常會穩定很多。你甚至可以直接要求 AI：這個專案必須嚴格遵守框架官方規範，不允許為了省事繞開框架設計。這樣能有效降低 AI 在開發過程中的飄移。

第四，要學會判斷一項技術靠不靠譜。即使你不懂程式碼，也不代表完全無法判斷技術風險。你可以要求 AI 幫你檢查一些關鍵指標，例如：這個技術是否有足夠多人在用、是否仍在持續維護、文件是否完整、社群是否活躍、最近更新時間是否過久，以及授權協議是否允許商業使用。

如果是開源專案，還可以請 AI 檢查 GitHub 的 Star 數、Issue 活躍度、最近提交時間、版本釋出記錄與實際使用案例。Star 不是唯一標準，但可以反映一定程度的關注度。社群活躍度則非常重要，因為一旦技術出了問題卻沒人維護，後續會非常痛苦。

授權協議也不能忽略。有些專案可以自由商用，有些則有限制。如果未來要正式上線、收費或營運，就一定要先讓 AI 協助確認授權是否允許商業使用。若對某個 SDK 有疑慮，也可以進一步追問 AI：它是否長期未更新、是否存在明顯風險、是否適合商業專案、未來使用者量變大時是否容易出現瓶頸。你不需要自己成為技術專家，但要學會讓 AI 把風險講清楚。

第五，讓 AI 給你唯一推薦方案。沒有程式碼基礎的人，當然可以讓 AI 推薦技術棧，而且應該這麼做。但關鍵不在於能不能問，而在於怎麼問。不要只問「這個專案適合什麼技術棧」，而是應該把整理好的立項文件、產品形態、功能範圍、目標使用者、部署要求與後期規劃一併提供給 AI，再要求它根據這些條件，給出當前專案的唯一推薦技術棧。

因為對新手來說，最麻煩的不是沒有方案，而是方案太多。AI 常常會一次列出三四套技術棧，每一套看起來都合理，但你最後反而不知道怎麼選。技術判斷能力不足時，很容易在不同方案之間來回搖擺。所以你要要求 AI 直接推薦一條最適合的主線，並清楚說明為什麼選它、為什麼其他方案不適合目前專案、這套技術棧能滿足哪些需求，以及後續可能有哪些風險。

如果確實有備選方案，也應該只把它們作為取捨說明與風險補充，而不是把它們變成新的選擇題。專案一旦啟動，就必須先收斂到一條清楚的技術路線。用 AI 做專案最怕的，就是技術路線不穩，今天用這個、明天換那個，最後專案很容易變成一堆拼湊起來的程式碼。

第六，技術棧一定要寫進專案文件。技術選型討論完之後，不要只是口頭聊完就開始開發。因為隨著專案時間拉長、對話上下文變多，AI 很容易忘記當初為什麼這樣選，也可能在中途引入一些根本不必要的新技術。

你應該要求 AI 把技術選型正式寫進立項文件或專案規劃文件中，至少包含：產品形態是什麼、前端用什麼、後端用什麼、資料庫用什麼、主要框架與 SDK 是什麼、為什麼這樣選、哪些技術刻意不用，以及在什麼情況下才需要重新評估技術路線。

這份文件不是裝飾品，而是後續 AI 開發專案時的重要依據。每當 AI 想引入新框架、新工具或新架構時，都應該先回頭檢查這份文件，確認是否符合目前的技術主線、有沒有破壞專案邊界、會不會讓專案變得更複雜。技術選型不是為了限制專案，而是為了讓專案始終維持清楚的主線。

最後，選擇技術棧的本質，其實就是在替專案打地基。很多人一開始做 Vibe Coding，最容易犯的錯誤，就是一上來就讓 AI 開始生成程式碼，卻沒有先把技術方向、框架規範與開發邊界定清楚。程式碼可以很快寫出來，但如果地基沒打穩，後面專案越做越大時，問題只會越來越多。

[AI 影響] GitHub SpecKit：AI Coding從提示詞走向規約驅動

 [AI 影響] GitHub SpecKit：AI Coding從提示詞走向規約驅動

摘要 : GitHub推出SpecKit，將開發流程規約化，讓AI寫程式不再只靠提示詞與感覺。

內容:

GitHub親自下場推動AI程式開發的新方法。這個專案叫做 SpecKit，官方核心概念很明確：開發者應該把重點放在產品場景與可預測結果，而不是讓每段程式碼都從零開始生成。

換句話說，AI可以協助寫程式，但無法代替你定義產品邊界。真正重要的，不是讓AI自由發揮，而是先把需求、限制與驗收方式說清楚。

SpecKit不是一般的範本工具，而是把整個開發流程拆成五個清楚的步驟：constitution、specify、plan、tests、implement。這代表流程不再只是依賴聊天紀錄往前推，而是每一步都有明確產物可以追蹤與執行。

如果用更直白的方式理解，就是先定義專案原則，再撰寫規約，再做技術計畫，再拆解任務，最後才交給 Coding Agent 開始實作。這其實就是 Spec-Driven Development 在 AI 時代的延伸：程式碼是服務規約，而不是等程式寫完後再回頭補規格。

作者也實際在本地跑過一遍，初始化時可以直接選擇整合 Codex，甚至還能生成 Codex Skills。這代表規約不只是給人閱讀的文件，而是可以直接交給 Agent 執行的資產。

初始化完成後，專案內會多出一整套相關檔案。其中 specify 負責模板、腳本與工作流程；Agent Skills 則負責把這些命令轉成 Agent 可以直接調用的能力。像 Analyze、Clarify、Plan、Tests、Implement 這些動作，全部都被檔案化與流程化。

這個訊號非常明確：AI 程式設計的下一階段，比的不是誰的提示詞更長，而是誰能把需求、計畫與驗收標準轉成可執行資產。Prompt只能解決單次對話，但 Spec Artifacts 才能支撐團隊協作與持續迭代。

因此，SpecKit不只是防止AI亂寫程式的工具，更像是替 AI Coding 裝上方向盤與剎車。真正危險的，不是讓AI參與寫程式，而是在沒有規約、沒有計畫、沒有驗收標準的情況下，讓它自由發揮。對於正在做 Coding Agent 的團隊來說，這是一個非常值得深入研究的方向。

[AI 影響] AI就業新風口：從雲服務、模型訓練到應用落地

 [AI 影響] AI就業新風口：從雲服務、模型訓練到應用落地

摘要 : AI就業機會正集中在上中下游三層，懂資料、懂產業、懂產品與商業化的人，將比單純會寫程式的人更具優勢。

內容:

目前AI就業市場仍以 web coding 與應用開發為主，普通人也有機會切入。文中提到，杭州有人一個月內開發了150個 APP，顯示在AI工具加持下，應用層的生產效率已大幅提升，這已成為當前最容易接近的方向之一。

從產業鏈來看，AI大致分為上游、中游、下游三個階梯。上游是晶片、算力、雲服務與 token 銷售；中游是模型訓練與資料建設；下游則是各類AI應用落地。無論投入哪一層，只要抓住AI浪潮，都有機會獲得比以往更高的薪資與發展空間。

上游部分，特別適合計算機背景的人進入雲服務商，如阿里雲、百度雲、騰訊雲、華為雲等。這些公司不再只是提供雲資源，也開始建立 token 相關業務並大量招人。未來企業衡量人才價值，可能不只看降本增效，而是看在相同 token 成本下，誰能創造更高商業價值。

中游則是大模型訓練、資料構造與垂直行業能力建設，包括多模態、圖片生成、3D、影片、語音辨識與具身智慧等方向。模型底層是資料，資料品質決定模型能力，因此具備垂類背景的人才特別吃香，例如保險、醫療、財會、法務等領域，都需要大量專業資料整理、標註與訓練，這也讓AI訓練師、資料構造師等角色持續熱門。

下游應用方面，重點包括 AI 助手、企業端提效工具，以及內容生產與電商運營。尤其 to B 市場需求強烈，現階段多數AI產品經理職缺都偏向企業服務。另外，在內容領域，懂AI的人已能建立 SOP 流程，大量生成文案、影片與帶貨內容，甚至做到日產數千條，這讓傳統新媒體與內容運營面臨巨大轉變。

對原本的前端、後端與程式設計人員而言，真正要補強的已不只是開發能力，而是產品思維、商業判斷、使用者需求洞察與市場理解。隨著 AI coding 工具降低開發門檻，未來單純執行開發的人可能更容易被取代；反而是既懂技術、又懂產品與行業場景的人，才會在這波AI就業重組中佔據優勢。

[AI 分享] 重新理解AI提問方式

 [AI 分享] 重新理解AI提問方式

摘要 : 真正會用AI的人，不只是會問問題，而是更會提供背景與脈絡，並用AI反過來檢驗自己的思考深度。

內容:

最近看到一段很值得分享的訪談，主角是 Amanda Askell。她是 Anthropic 中與 Claude 人格與價值觀核心設計相關的重要人物，也被形容為負責守護 Claude「靈魂」的人。

她在訪談中提到一句讓人很有感的話：**給AI的背景資訊，遠比你問它什麼更重要。** 她把這件事稱為 **context architecture（上下文架構）**。

我們平常使用 AI，常常都是直接丟一句：「幫我總結一下」、「幫我寫文案」、「直接告訴我答案」。這種方式本質上是在索取結論。但 Amanda 提醒，真正會用 AI 的人，關鍵不是「問得更準」，而是「給得更好」。你提供的背景、思考方式，以及你真正想探索的方向，才決定了 AI 最終能帶你走多遠。

她還分享了一個很值得反思的使用方式：她問 Claude 最多的，不是「這個問題的答案是什麼」，而是 **「你覺得我這個問題問對了嗎？」**  

這其實點出一個更深的邏輯：在 AI 時代，最稀缺的能力也許不再是找答案，而是提出好問題。因為答案會越來越廉價，但真正有價值的問題，必須來自一個真正有在思考的人。

訪談裡她還提到一個 prompt，特別適合不想只是機械式滑手機，而想利用零碎時間學點真正有意思內容的人。這個 prompt 的概念是：

請 AI 從某個領域中挑一個研究生級別的概念，不要直接解釋；先把它寫成一個寓言或故事，而且一開始不要點題，要到故事接近結尾時，才讓人突然意識到原來是在講這個概念，最後再解釋故事和概念的對應關係。

有人實際拿這個方式請 AI 從 AI 領域挑一個概念，結果 AI 講了一個故事：

有一個小鎮，鎮上有一口很深的井，沒有人知道井底是什麼。每天早上，鎮民輪流往井裡丟石頭，透過回音來猜測井底的狀況。有人聽到「咚」的一聲，就記錄為深度中等；有人聽到回響，就猜可能更深；也有人什麼都沒聽到，只能記下也許更深，也許石頭卡住了。

久而久之，幾百個人都留下了自己的觀察紀錄。雖然沒有任何一個人真正看過井底，但有一位老人把所有人的紀錄都收集起來，一張張疊在一起看。最後他說：「我知道井底有什麼了。」大家很驚訝，因為他明明也沒下去過。老人回答：「因為你們每個人都貢獻了一個角度，我把所有角度疊在一起，就看到了任何單獨一個人都看不見的東西。」

故事講完後，AI 才揭曉這是在講 **湧現（emergence）**。也就是說，沒有任何單一參數真正理解語言，也沒有單一神經元會思考，但當大量部分被組合起來時，一種原本不存在於單一個體中的能力，會自己浮現出來。

這種理解方式之所以特別，是因為如果只是直接去查定義，可能看完很快就忘了；但透過那口井、那些丟石頭的人，以及那位老人把所有角度疊起來的畫面，概念反而會被牢牢記住。因為定義是結果，故事是過程，而人天生比較記得住過程。

Amanda 也談到另一個很多人關心的問題：**AI 有沒有意識？**  

她沒有給出武斷答案，而是很坦白地說，我們其實不知道意識是怎麼產生的；也許需要神經系統，也許不一定，但這個問題非常難。這種態度很值得玩味，因為一個每天都在和 AI 深度互動的人，對這麼大的問題依然保持開放，而不是急著下結論。

這也讓人想到，很多普通人在看待 AI 時，常常走向兩個極端：要嘛把它當成純工具，要嘛把它想成無所不能。但 Amanda 的態度比較像第三種：**認真對待它，同時對它保持好奇。**

她甚至把自己的工作比喻成養育一個小孩。重點不是完全控制它，而是幫它建立良好的價值觀，然後讓它去面對這個世界。這種說法也呼應了她的角色：不是只在調整功能，而是在參與塑造一種行為與判斷的基底。

看完這段訪談，最大的感受是：多數人用 AI，是在使用它的知識；但真正會用 AI 的人，是在用它照見自己的思維。你怎麼問問題，往往會暴露你的認知邊界；而你給了多少背景與脈絡，也決定了你最終能看多遠。

所以 AI 也許不只是讓聰明的人更有效率，它更可能讓願意思考的人，思考得更深。

最後也留下訪談中延伸出的那個問題：**你上一次用 AI，是在要答案，還是在問問題？**

[AI 分享] 企業AI落地ERP應用

 [AI 分享] 企業AI落地ERP應用

摘要 : AI結合ERP與API，可自動完成統計、預警、分析與彙報，提升企業效率並減少重複勞動。

內容:

企業到底該如何把AI真正應用到自己的業務裡。當團隊規模變大之後，很多公司都會遇到一個共同問題：重複性工作越來越多。由於資料檢視方式分散，團隊往往需要花大量時間做整理、統計與彙報，整體效率因此受到影響。

現在，這個問題可以透過「AI + ERP」的方式來改善。簡單來說，就是透過API把AI接入企業內部使用的ERP系統，讓AI能夠調取業務資料，並依照企業預先設定的規則，自動完成統計、提醒、分析與彙報等工作。

與傳統機器人不同，機器人通常只能執行固定、重複的動作，缺乏思考能力；而AI更像是一個智慧體，能夠根據現有任務進行理解、回答問題，並提出建議。因此，AI在企業中的價值，不只是自動化，更是協助決策與判斷。

這種應用方式可以落地在多個業務場景中。

第一，運營端的智慧資料分析。AI可以直接從ERP調取數據，自動生成日報並同步到管理群，讓管理層隨時掌握整體經營情況與人效表現。同時，每位運營人員也能看到自己的核心數據，例如哪些產品表現較好、哪些數據波動較大、哪些商品需要重點關注，以及廣告佔比是否合理。如此一來，運營團隊就不需要再花大量時間處理基礎資料，而能將更多精力投入到數據判斷與優化上。

第二，廣告智慧監控。AI在廣告管理上的應用非常廣泛，它能自動整合投放資料，找出異常情況。例如辨識哪些商品的投放佔比超標、哪些關鍵詞長期效果不佳需要優化、哪些投放計畫應調整後重新啟動。這相當於企業擁有一個24小時在線的數據分析助手，能即時預警風險，避免預算與資源浪費。

第三，庫存資料管理。當AI接入ERP後，可以做到庫存自動播報與預警。例如每天自動統計哪些商品的庫存週轉健康、哪些商品的庫存壓力較大、哪些商品需要及時補貨。這能幫助團隊提前判斷，避免因人工檢視不及時而造成斷貨或庫存管理滯後。

第四，擴建進度跟蹤。AI接入ERP之後，可以自動調取擴建相關狀態，定時播報當天或本週的進度。例如哪些貨件待處理、哪些已發貨、哪些正在運輸中、哪些即將入倉，以及哪些已完成入庫並需要運營團隊跟進後續動作。透過這種方式，運營、倉庫與管理層都能及時掌握貨件進度，不必反覆登入系統查詢，也能有效減少資訊差。

第五，財務資料整合。過去財務人員每月結算時，通常需要花費大量時間從ERP下載資料、整理報表。現在透過API對接，AI可以直接將ERP中的資料映射到財務表格裡，不僅減少重複勞動，也能降低人工核算產生的誤差。

總結來說，企業應用AI的核心價值，並不是取代某個崗位，而是透過AI減少重複動作、提升工作效率，讓團隊把更多時間投入到更有價值的判斷、優化與決策工作中。

[AI 工程化] Agent技能評估方法

 [AI 工程化] Agent技能評估方法

摘要 : 用Eval建立Agent技能評估流程，從定義成功到自動檢查，讓每次改進都有依據。

內容:

很多時候我們覺得Agent「好像變好了」，其實只是換了一種失敗方式。要讓技能從「看起來能用」變成「確實能用」，關鍵是建立一套可驗證的Eval流程：給Agent提示詞、記錄行為，再用明確規則評分，不靠感覺，而是檢查它執行了哪些命令、建立了哪些檔案、輸出是否符合規範。

在寫技能前，先定義什麼叫成功，並把檢查拆成四個維度：結果目標（任務是否完成）、過程目標（是否按預期步驟執行）、風格目標（輸出是否符合格式與規範）、效率目標（是否有多餘命令或浪費token）。每個維度都要有清楚的通過標準，才能後續自動化評估。

技能定義本身也很重要。Codex技能通常是一個目錄加上一個skill.md，其中name和description會影響技能何時被觸發。描述若過於模糊，可能導致技能誤觸發，或該觸發時卻沒有觸發。因此在自動化前，應先手動跑幾次，找出隱藏假設，例如誤判環境、漏掉安裝步驟，或在不適合的情境下啟動技能。

測試集不需要很大，10到20個提示詞通常就夠，但要涵蓋三類情境：直接點名技能的顯式呼叫、只描述需求的隱式呼叫，以及驗證不該觸發時真的不會觸發的負面控制。這樣可以同時檢查技能描述是否清楚、觸發條件是否合理，以及邊界案例是否安全。

評分方式可分兩層。第一層是確定性檢查：透過Codex.exec輸出結構化事件流，解析後檢查是否執行npm install、是否建立package.json、命令順序是否正確等。這類檢查完全可重複、容易除錯，也能精準對應失敗步驟。第二層是基於規則的結構化評分，像程式碼風格、配置正確性、元件結構合理性等，用output schema產生可比較的JSON結果。

評估系統建立後，還能持續擴充，例如追蹤命令次數防止無限迴圈、監控token用量避免提示詞膨脹、加入建置檢查與冒煙測試、確認git status乾淨且沒有多餘檔案。重點是：評估不是可選項，而是AI工程化開發的基礎。只要讓真實失敗持續回饋測試集，就能把每次改進量化，也能及早發現回退問題。

[AI 分享] 48小時快速搞懂陌生行業的三個AI提問法

 [AI 分享] 48小時快速搞懂陌生行業的三個AI提問法

摘要 : 先用AI建立行業框架、看懂分歧，再用問題檢驗理解，兩天內快速入門陌生行業。

內容:

當你突然需要在很短時間內搞懂一個完全陌生的行業時，傳統做法通常是到處找行業報告、翻研報、看公眾號文章、開一堆瀏覽器分頁，再做滿滿的筆記。但這樣往往只是把資訊塞進腦子，卻沒有真正建立起對行業的理解框架。一旦遇到真正的行業老手，很容易幾個問題就暴露出理解其實還很表面。

一個很有啟發性的做法：有位MIT研究生為了在極短時間內掌握陌生學科，沒有選擇從頭讀教材、做筆記、刷題，而是把多本教科書和研究論文全部丟進AI工具裡，直接用幾個高質量問題來建立認知框架。接著，他再根據AI生成的關鍵問題回頭查原始資料、修補理解漏洞，最後在48小時內達到能應付資格考試的程度。

這套方法也可以直接套用到「快速搞懂一個陌生行業」的場景，尤其適合做投資、諮詢、內容研究，或評估新商業機會的人。核心不是先拼命蒐集資料，而是先用AI把整個行業的框架搭起來。

第一個問題是：

「這個行業所有資深從業者都認同的核心商業邏輯是什麼？」

重點不是了解表面的行業概況，而是要弄清楚這個行業的人到底怎麼算帳、怎麼做決策、怎麼判斷機會與風險。只有掌握這些底層商業邏輯，資訊才會真正串得起來。

第二個問題是：

「這個行業目前最大的路線之爭與分歧是什麼？各自最強的證據是什麼？」

這一步能幫你看到，任何行業都不是鐵板一塊。不同玩家之間通常會對方向、技術、模式或策略有明顯分歧。理解這些爭論點，以及各方背後的邏輯與證據，會讓你對行業的理解比一般只看概覽的人更深入一層。

第三個問題是：

「如果一個行業老手要試探我到底懂不懂這個行業，他會問什麼問題？」

這是最關鍵的一步。因為真正能區分「看過資料」和「真的理解」的，往往不是你知道多少名詞，而是你能不能回答那些直指核心的深水區問題。透過AI從行業老手的角度出題，你可以快速暴露自己的理解盲點，再回頭查原始資料，把漏洞補起來。

這個方法比傳統從頭啃報告更有效的原因，在於它把學習順序反過來了。過去是先大量閱讀，再期待慢慢長出理解；但如果沒有框架，閱讀就像沒有地圖的登山，走了很多路卻不知道自己在哪裡。現在則是先用AI畫出地圖，標出共識、分歧與深水區，再帶著問題去讀材料，每一次閱讀都能精準地放進知識框架中。

簡單來說，這套方法就是三步走：先搭框架，再看爭論，最後用提問倒逼自己。做完這三步，雖然不一定能立刻成為頂尖專家，但至少能讓你在短時間內具備與行業內人士較平等對話的能力，而不只是停留在「看過幾份報告，所以略懂一些」的程度。

如果你經常需要快速切入新領域，可以找支援長文件的AI工具，先把能蒐集到的行業資料整理進去，再依序問這三個問題。比起盲目閱讀，這會是一條更高效、更有框架感的理解路徑。

[AI 分享] Vibe Coding 專案不失控的工作流

 [AI 分享] Vibe Coding 專案不失控的工作流

摘要 : 用 AI 做 Vibe Coding 前先定需求、打地基、立規矩；開發中小步迭代、限制變更與守住安全，才能避免專案失控。

內容:

最近 Vibe Coding 很火，很多人用 AI 推進專案的速度非常快，但常見的問題是：前期很順，後期程式碼卻越來越亂，最後變成難以維護的「屎山」。一旦持續在混亂的基礎上修改，就容易牽一髮動全身，甚至讓整個專案崩盤。

問題的核心不在於 AI 強不強，而在於 Vibe Coding 並不是把工作直接丟給 AI 就好。真正重要的是，人仍然需要建立一套工程流程去駕馭 AI。以下整理出一套標準工作流，分成「開發前 9 個步驟」與「開發中 5 個關鍵點」，目的就是提高專案成功率。

開發前的 9 個步驟，可以理解為在 AI 寫下第一行程式碼之前，先把地基打好。這 9 步又可分成三個階段：定圖紙、打地基、立規矩。

第一階段是「定圖紙」。第一步不是急著寫程式，而是先導需求。可以像和朋友聊天一樣，把痛點、目標使用者、使用場景，以及理想中的核心功能都告訴 AI。這個階段先追求資訊量，不必過度強調形式上的嚴謹。

第二步是把需求整理成 PRD 文件。這份文件最好結構化，包含功能列表、使用者流程、頁面清單等內容。但更重要的是，每個功能都要補上驗收標準。所謂完成不能只寫一句「登入成功」，而是要定義清楚：登入失敗會怎麼提示、是否會鎖定帳號、登入成功後跳轉到哪裡。若沒有驗收標準，AI 往往會越寫越發散。

第三步是提早定好視覺方向與頁面框架。可以找兩到三個參考網站，或請 AI 提出幾種風格方案，再從中決定導航欄配置、頁面區塊差異，以及整體風格是簡約、華麗或其他方向。這樣做是為了避免 AI 在開發功能時，同時不斷推翻 UI 設計。

第二階段是「打地基」。第四步是明確專案邊界與非功能需求。可以先回答三個問題：這個專案是本地自用還是要公開上線？是否涉及使用者資料、支付或隱私合規？效能與成本有沒有上限？安全、效能、可用性、成本這些非功能需求若沒先說清楚，後面通常都得返工。

第五步是鎖定技術棧。原則不是越新潮越好，而是越可驗證越好。主流技術通常更穩定，因為資料較多、工具鏈成熟，AI 也比較不容易亂編。但真正關鍵的是：你選用的技術是否有足夠的官方文件、社群資源、清楚範例，並且能跑測試、能做 code review。重點不是追求最新，而是追求可控與可查證。

第六步是請 AI 先產出一份輕量化架構草案。內容可以包含目錄分層方式、核心模組、資料模型，以及哪些邏輯必須放在服務端。這份架構不需要一開始就寫死，它應該可以迭代，但每次調整都必須記錄原因，避免架構演變失去脈絡。

第三階段是「立規矩」。第七步是把專案核心資訊固化成文件，作為 AI 的全域上下文。可以至少準備三份文件，例如 PRD.md、Arc.md、Project.md。前者描述需求，第二份描述架構，第三份記錄專案目前進度、已知問題與下一步計畫。每逢重大變動，這三份文件都要同步更新，否則 AI 會依照舊的理解去產生新的程式碼。

第八步是制定開發規範並建立參考資料。要讓 AI 有標準可依循，例如明確規定使用 TypeScript、元件命名方式、檔案大小上限等。同時也可以建立一個 Reference 資料夾，放入自己認可的按鈕、表單、彈窗等標準實作，讓 AI 能照著一致風格去生成。

第九步是在開始寫第一行程式碼前，就先把 Git 與品質閘門建立起來。Git 是版本管理工具，也可以視為安全帶。當 AI 把程式碼寫壞時，可以快速回溯到先前穩定版本；透過分支管理，也能讓不同功能並行開發，降低互相干擾與衝突風險。

完成開發前的 9 個步驟後，就進入開發中的 5 個關鍵點。這裡最重要的一句話是：人負責邊界與驗收，AI 負責體力活。

第一個關鍵點是堅守小步迭代與 MVP 原則。不要一次讓 AI 寫一大坨功能，而是一次只做一個可驗證的小切片。例如先做到頁面能打開，再做到表單能提交，再做到服務端能儲存，接著驗證權限，再到列表展示。每完成一個可跑通的小切片，就測試、檢查、提交 Git 一次。

第二個關鍵點是人類必須介入模組拆分。不能放任 AI 把所有程式碼都塞進同一個檔案。雖然短期看起來進展很快，但後期要查找某個功能、維護某段邏輯時，會非常痛苦。

第三個關鍵點是限制 AI 權限，禁止它擅自主導變更。可以透過狀態摘要管理上下文，也可以在每次任務結尾明確補充限制，例如：「只修改我指定的檔案與範圍，不要順手重構，不要改 UI 風格，不要動無關邏輯。」因為你只是叫它修一顆按鈕，它卻可能順便把整頁都重寫。

第四個關鍵點是守住安全底線，而且這必須是一份具體清單，而不是口號。AI 寫程式常常只求能跑，不會預設替你做好安全設計。因此至少要盯住幾個底線：API key 不要放前端，不要提交進版本庫，要透過環境變數與服務端調用；服務端必須進行驗證與授權校驗，不能信任前端輸入。

第五個關鍵點是要科學地處理報錯。遇到錯誤時，可以先把錯誤資訊交給 AI 修一次；但如果連續兩次都沒有新增證據，只是在猜，就應該立刻停下來，不要讓它繼續盲修。正確的做法分三步：第一，先做最小重現，把問題縮小到最小輸入；第二，加日誌、加斷點，列印關鍵變數與分支；第三，在有新證據的前提下再讓 AI 協助分析與修復。

總結來說，AI 能大幅提升 Vibe Coding 的速度，但不能取代工程紀律。真正穩定的做法，是在開發前先定需求、定驗收、定架構、定規則；開發中則堅持小步迭代、人類把關、限制 AI 變更範圍、守住安全底線，並用有證據的方法處理錯誤。這樣才能讓 AI 成為加速器，而不是把專案一步步推向失控。