Knowledge Base

閱讀站

首頁而家只顯示最近 50 篇文章，避免文章量愈大愈拖慢首頁載入。

共 2662 篇文章

Claude Code+Obsidian加起來就是王炸

Claude Code 同 Obsidian 組合可以打造個人 AI 操作系統，打通知識庫、執行引擎同跨工具協同，一個人就等於一間公司。

完成

Obsidian 筆記也能「發芽」？我復刻了一個 Get 筆記同款功能

復刻Get筆記發芽功能嘅過程，本身就係一次「慢直覺」嘅完美示範

完成

胡彥斌 1 個月用 AI 做出 App 的真相：你的“領域知識”比代碼值錢 100 倍

胡彥斌用 AI 一個月開發 App「彥火」嘅故事，揭示咗 Vibe Coding 時代真正值錢嘅係領域知識，唔係編程技術。

完成

Claude Code 詳解：SubAgent 六種執行模式

Claude Code 嘅 SubAgent 六種執行模式，由同步到遠端，逐個拆解設計取捨

完成

拖延問題在AI時代值得重新回答一遍，因為傳統戰拖的建議在AI時代，可以進一步升級，效果更好。AI 時代，提高行動力的關鍵不再是“逼自己更自律”，而是給自己搭一個 AI 行動閉環。傳統時間管理的建議通常是：拆任務、番茄鍾、下一步行動、WOOP、記錄覆盤、100天行動。這些東西還雖然沒有過時。但它們有一個共同前提：你得自己啓動，自己拆解，自己提醒，自己監督，自己覆盤。而問題恰恰在這裏。一個拖延的人，最缺的往往不是道理，而是啓動那一下。你讓一個啓動困難的人每天手動拆任務、手動覆盤、手動做計劃，聽起來正確，執行起來很殘酷。AI 真正改變的地方，不是它能替你寫一份漂亮計劃，而是它可以在行動鏈條裏承擔一部分“外部執行功能”：你說不清楚目標，AI 幫你問清楚。你不知道下一步，AI 幫你拆到能動。你怕寫得爛，AI 先給你墊一個粗糙初稿。你想逃避，AI 追問你到底在躲什麼。你做完一小步，AI 幫你驗收、記錄、生成下一步。你連續中斷，AI 幫你覆盤模式，而不是罵你沒毅力。所以，AI 時代戰勝拖延，更準確地說：把 AI 變成你的行動腳手架，而不是新的娛樂玩具。AI 會同時增強行動力，也會增強拖延AI 不是天然幫你行動的工具。用不好，它會讓你拖得更隱蔽。以前拖延是刷短視頻、看小說、打遊戲。現在的高級拖延是：讓 AI 幫你做十版計劃，但一版都不執行。不斷優化提示詞，假裝自己在工作。讓 AI 總結資料，總結完不產出。問 AI “我該怎麼辦”，問完繼續問。收集一堆 AI 工具，真正該做的事還沒開始。這種拖延更難察覺，因為它看起來很勤奮。你甚至可以忙一整天，聊天記錄很長，產出為零。這幾月在高強度使用AI之後，發現：工具很多，不等於有執行力。真正有用的是反饋迴路有沒有閉合。這個發現放到個人行動力上也成立：AI 聊天很多，不等於行動力提高。只有“目標-行動-驗收-反饋-再行動”閉起來，AI 才真的在幫你。所以 AI 時代第一條原則是：不要用 AI 生產更多想法，要用 AI 推動更小的行動。判斷 AI 有沒有幫上忙，只看一個指標：今天有沒有留下一個真實產物？哪怕很小也行：寫了 200 字。發出一封郵件。做完一道題。整理完一個文件夾。預約了體檢。走了 10 分鐘。把項目拆成了 3 個可以執行的工單。如果沒有真實產物，只是在對話框裏來回聊，那大概率只是把拖延包裝成了“思考”。傳統拖延的根源沒變：你不是不想做，而是不想面對不舒服AI 時代，人的底層問題沒變。拖延最常見的原因，仍然不是懶，而是短期情緒緩解壓倒了長期目標收益。《拖延心理學》系列裏反覆提到：拖延背後常常有害怕失敗、完美主義、焦慮、自我價值感受威脅。《戰拖行動》和《如何應對拖延》裏也提到過一個公式：行動動機 = 期望 x 價值感 / 衝動 x 可推遲時間這個公式放到 AI 時代仍然有效。只是 AI 可以介入四個變量：變量傳統做法AI 時代更好的做法期望自己給自己打氣讓 AI 把任務拆到“我現在能做”價值感寫目標意義讓 AI 幫你算拖延代價和行動收益衝動遠離手機讓 AI 做環境預案和中斷恢復方案可推遲時間設置截止日期讓 AI 拆成今日小交付並驗收也就是說，AI 不是替代心理機制，而是改造行動環境。以前你要靠自己在腦子裏完成這套轉換：“我應該寫論文” → “我今晚先寫引言第一段” → “我卡住了先列3個小標題” → “我做完了記錄一下”。現在你可以把這個轉換外包給 AI。這才是 AI 對拖延真正有價值的地方。AI最適合接管的，是拖延鏈條裏的六個薄弱環節一個任務從“想做”到“做完”，中間至少有六個環節：澄清目標、拆成下一步、降低啓動阻力、陪你完成第一輪粗糙產出、驗收結果、覆盤並生成下一步。傳統方法要求你自己完成這六步。AI 時代，可以讓 AI 介入每一步。1. 讓 AI 把模糊目標問清楚拖延常常從目標模糊開始。“我要提升自己”“我要開始學習”“我要做副業”“我要寫文章”“我要改變生活”，這些話都不能直接執行。你可以直接問 AI：我現在的目標是：____。請你不要急着給建議，先連續問我 5 個澄清問題，直到這個目標變成一個本週可以交付的具體結果。AI 在這裏的價值不是給答案，而是逼你把霧氣散開。例子：你說：“我想提高英語。”AI 應該追問：你提高英語是為了考試、工作、閲讀還是交流？你現在水平大概在哪裏？你一週能投入幾次，每次多長時間？你希望 30 天后看到什麼變化？最小可交付成果是什麼：背詞、讀文章、聽播客、寫郵件，還是口語對話？最後目標可能變成：未來 7 天，每天用 20 分鐘精讀一段英文材料，週日輸出一篇 300 字英文摘要。或者每天用語音跟 OpenAI 對話 15 分鐘這才進入可行動狀態。2. 讓 AI 把任務拆到“下一步行動”想戰勝拖延“下一步行動”非常關鍵。AI 能把這件事做得更輕。你可以用這個提示詞：我正在拖延這件事：。請把它拆成 10 個連續步驟。每一步都必須是肉眼可見的動作，不能出現“思考、準備、提升、研究”這種抽象詞。然後標出其中最小的第一步，要求 5 分鐘內能完成。比如“寫一篇公眾號文章”，AI 不應該只說“收集資料、確定結構、開始寫作”。這還是太粗。更好的拆法是：打開文檔。寫下問題原文。寫一句你真正想反駁的常見觀點。列出 3 個親身或知識庫例子。寫出一個 100 字開頭。讓 AI 幫你檢查這個開頭是否有吸引力。拖延的人需要的不是宏偉路線圖，而是下一塊踏腳石。3. 讓 AI 降低“第一稿羞恥”很多人不是不會做，而是不敢開始，因為第一稿一定很爛。寫作、簡歷、彙報、方案、郵件、讀書筆記，最難的常常不是完成，而是忍受第一版的粗糙。AI 在這裏特別有用：讓它先生成一個“可批評的壞版本”。提示詞：我需要完成：。請先給我一個 60 分的粗糙版本。不要追求完美，只要讓我能開始修改。輸出後請列出 3 個最值得我親自改的地方。這招的價值在於：你不再面對空白。空白會放大恐懼。粗糙版本會激發判斷。很多人一看到 AI 寫得不夠好，反而知道自己想要什麼了。這個時候行動已經開始。4. 讓 AI 做“如果-那麼”預案《WOOP思維心理學》和執行意圖研究都強調：計劃必須包含障礙。Gollwitzer & Sheeran 2006 關於執行意圖的元分析顯示，“如果-那麼”計劃能提高目標執行概率。AI 可以幫你批量生成預案。提示詞：我的目標是：。我最可能失敗的場景有：。請幫我生成 8 條 if-then 預案。要求每條都具體、短、能立刻執行。其中至少 3 條必須是“最低版本”，用於狀態很差的時候。例子：如果下班太累，那麼只做 5 分鐘，不做完整任務。如果想刷手機，那麼先把手機放到門口，回來再決定。如果寫不出來，那麼只寫 3 個小標題。如果今天中斷，那麼明天不補債，只恢復最低版本。如果又想重新做計劃，那麼先完成當前任務的第一步。很多人失敗，不是因為沒有計劃，而是計劃只適用於理想狀態。AI 的用處，是幫你為壞狀態提前鋪路。5. 讓 AI 當驗收員，而不是隻當鼓勵員AI 如果只是鼓勵你“你很棒、你可以”，用處有限。更好的用法是讓 AI 驗收。當 AI Agent 成為執行者時，人要設計讓事情被正確做出來的系統。放到個人行動力上，就是給每個任務設計驗收標準。你可以這樣用：這是我今天完成的內容。請按 3 個標準驗收：-是否完成了最小交付？-是否有明顯跑偏？-下一步最該做什麼？不要安慰我，直接指出問題。這比“今天我做得怎麼樣”有效得多。行動力來自反饋，而不是來自情緒按摩。6. 讓 AI 做覆盤，發現你的拖延模式人很難看見自己的重複模式。你每次都覺得這次拖延是偶然：今天太累、事情太多、別人打擾、狀態不好。但記錄 2 周後，AI 可以幫你看出模式：你總是在晚上安排高難度任務。你總是在任務不明確時刷手機。你總是在完成 70% 後停下，因為害怕交付。你總是花太多時間找資料，不進入輸出。你每次失敗後都會加碼，導致第二次更難開始。提示詞：下面是我過去 7 天的行動記錄：。請幫我分析：我最常見的拖延觸發點是什麼？哪些任務安排不合理？我應該刪除什麼，而不是增加什麼？下週只改一個地方，應該改哪裏？注意最後一句：只改一個地方。AI 很容易給你 20 條建議。拖延的人不需要更多建議，需要更少、更準的下一步。AI行動力系統：不要做計劃表，要做反饋迴路Harness Engineering 的一個核心思想是：人的角色從“親自執行”變為“設計讓執行正確發生的系統”。這句話可以直接遷移到個人行動力。AI 時代，最有效的個人行動系統不是一個待辦清單，而是一個小型反饋迴路。最小版本如下：1. 早上：AI 幫你定今日唯一交付不要讓 AI 幫你列 20 項待辦。你只問：根據我本週目標：，今天只選一個最重要的小交付。要求 60 分鐘內能完成。請給出最低版本、標準版本、超額版本。例子：最低版本：寫 100 字。標準版本：寫完第一節。超額版本：寫完第一節並讓 AI 初審。這樣你狀態差也不會徹底斷掉。2. 開始前：AI 把任務拆到 5 分鐘第一步提示詞：我準備開始這個交付：。請給我一個 5 分鐘啓動動作。不要解釋，不要鼓勵，只給動作。你要的是啓動，不是雞湯。3. 執行中：AI 只在卡住時介入不要邊做邊跟 AI 聊。AI 聊天本身會變成分心。規則可以設成：先做 25 分鐘。卡住超過 3 分鐘，再問 AI。問 AI 時只問一個具體障礙。例如：我卡在這句話，不知道怎麼繼續。請給 3 個續寫方向，每個不超過 30 字。不要問：你覺得我該怎麼寫好這篇文章？問題越大，越容易重新進入拖延。4. 完成後：AI 驗收並生成下一步提示詞：這是我的交付物：。請用“通過/不通過/需補一處”驗收。如果通過，給我下一步。如果不通過，只指出最小返工點。這裏要限制 AI 的輸出。否則它會給你一堆優化建議，讓你陷入無窮返工。5. 晚上：AI 做 3 行復盤提示詞：今天目標：實際完成：中斷/拖延點：請只輸出三行：-今天有效的一個動作-今天最大的一個阻礙-明天的一個最小動作覆盤越短，越容易堅持。AI 能做的不是替你自律，而是降低行動摩擦AI 對行動力最大的幫助，可以概括成 7 個動作：AI動作解決的拖延問題追問目標模糊拆解不知道下一步初稿空白恐懼改寫完美主義卡住預案情緒狀態不穩定驗收做了但不知道是否有效覆盤重複失敗但看不出模式你會發現，這些動作都不是“替你成功”。AI 不能替你去跑步，不能替你考試，不能替你體檢，不能替你把工作交給老闆，不能替你承受現實反饋。但 AI 可以把你從“我不知道怎麼開始”的泥潭裏拉出來。這就夠重要了。很多拖延並不是卡在 100 分的能力上，而是卡在 0 到 1 的啓動上。警惕三種 AI 時代的新拖延1. 計劃型拖延表現：你讓 AI 生成各種計劃、表格、SOP、路線圖，但沒有一個進入執行。解決：每次讓 AI 生成計劃後，必須立刻問：這個計劃裏，5 分鐘內能做的第一步是什麼？然後馬上做。2. 工具型拖延表現：不斷研究哪個 AI 工具更好，哪個插件更強，哪個工作流更先進。解決：設定工具凍結期。比如 14 天內只用一個 AI 對話工具、一個文檔工具、一個提醒工具。先把迴路跑通，再升級工具。工具升級不能替代行動升級。3. 代理型逃避表現：你把所有事情都丟給 AI，自己不判斷、不驗收、不承擔。這也危險。AI 可以當助手，不能當人生負責人。控制論和 Harness Engineering 裏有一個相同的提醒：一旦機器有行動能力，人必須確保目標和邊界是自己真正想要的。個人行動也是一樣。你可以讓 AI 幫你拆任務，但最終要不要做、做到什麼程度、交付給誰、承擔什麼後果，仍然是人的責任。普通拖延和 ADHD 相關拖延，AI用法也不同我以前寫過一篇《單純拖延與ADHD拖延的根本區別》有個區分很重要：普通拖延：我不想立刻面對。ADHD 相關拖延：我想面對，但執行系統調不起來。如果是普通拖延，AI 的重點是幫你降低情緒阻力：拆小、啓動、預案、覆盤。如果更像 ADHD 相關拖延，AI 可以做外部支架：把任務拆成更短的步驟。用更頻繁的提醒。每一步只給一個動作。用視覺化清單。用固定時間做 check-in。把長期任務變成即時反饋。但要明確：AI 不能替代專業評估。長期嚴重啓動困難、注意力失控、時間感混亂、焦慮抑鬱明顯時，應該尋求專業幫助。AI 可以輔助管理，不要拿它替代醫學判斷。給你一套今晚就能用的 AI 戰拖流程不要再問 AI：我總是拖延怎麼辦？這個問題太大，AI 很容易給你一堆正確廢話。直接複製下面這段：我正在拖延一件事——。你現在是我的行動教練，不要給長篇建議。請按以下步驟幫我：-用 3 個問題幫我找出我在逃避什麼。-把這件事拆成 5 個肉眼可見的動作。-選出一個 5 分鐘內能完成的第一步。-給我 3 條 if-then 預案，應對分心、疲憊、害怕做不好。-等我完成第一步後，再幫我驗收並給下一步。規則：一次只輸出當前步驟，不要一次性給完整方案。最後一句最重要：一次只輸出當前步驟。拖延的人最怕方案太完整。完整方案會帶來新的壓力。AI 最好的用法，是像導航一樣：你只需要知道下一個路口怎麼走。AI時代行動力的第一性原理傳統時代，行動力更多依賴個人意志、習慣和環境。AI 時代，行動力可以變成一個人機協作系統：人負責目標、價值、邊界和最終判斷；AI 負責拆解、提醒、陪跑、驗收和覆盤。更簡潔一點：行動力 = 人的意圖 x AI 的拆解與反饋 x 真實世界的小交付三者缺一不可。只有人的意圖，沒有 AI 支架，容易回到傳統拖延。只有 AI 支架，沒有人的意圖，會變成工具遊戲。只有對話，沒有真實交付，會變成 AI 時代的新型拖延。真正有效的狀態是：今天你不需要“變得很自律”。你只需要打開 AI，輸入一個真實拖延任務，讓它幫你拆出 5 分鐘第一步。然後你去做。做完回來，讓它驗收。明天繼續。行動能力不是靠一次頓悟長出來的。它是靠一個個被閉合的小回路長出來的。AI 時代最值得做的，不是讓自己更像機器一樣自律，而是讓 AI 幫你把行動這件事變得更容易開始、更容易繼續、更容易被反饋。注：這篇文章是在結合個人經驗跟多個大模型對話、溝通之後，梳理出來的，有AI參與。觸發即行動：你以為的"理性"，其實是最高級的拖延擊退決策的三大敵人——恐懼、拖延和迴避，使您能夠做出影響人生的最重要的1%選擇打破拖延最實用的一套方法，想行動力開掛一定要試試一招制敵：打敗分心、拖延、壓力！你知道這周要做什麼嗎？怎麼樣確保自己不拖延你為什麼還不開始？為什麼拖延通過自我提問法來搞定拖延症，瞬間變得超級自律拖延症患者自救手冊我把“溝通訓練”做成了最小行動：每天 1 張牌，30 秒一輪。小程序「撲克溝通大師」，讓你把提問能力練出複利。👇我這裏輸出的內容都“可直接照做”的東西：注意力 / 時間管理 / 溝通技巧 / 讀書讀記 📌 找直播：關注視頻號「生活黑客、讀書方法」→ （近半年）🚀 想系統一起做：加入 100天行動（最小行動、複利成長）⭐ 不想錯過更新：把 warfalcon 設為星標（點上方「warfalcon」→ 右上角「…」→ 設為星標）

完成

Codex 官方插件(openai/plugins)是開源的

Codex插件係開源嘅能力包，畀AI Agent裝配方法、連接同固定動作，令佢做到真實工作

完成

Claude最新發布的Dynamic Workflows - 五個行業成功案例

Claude Dynamic Workflows 實戰：5個非程式員都用得嘅真實成功案例，AI自己組隊互相挑刺

完成

學過就忘？用 Obsidian 搭建個人知識庫，把知識真正變成資產

用Obsidian建立本地優先嘅個人知識庫，將零散資訊沉澱成可持續增長嘅資產

完成

徹底解決 Codex 重連 5 次的問題（僅限 macOS）

修復 Codex Desktop 重連問題：設定代理環境變量即可

完成

AI時代，每一個高考生都應該掌握帶領AI解決真實問題的閉環能力。

AI時代核心競爭力：定義問題、批判思維、系統思維、邏輯表達、審美創造力同項目能力，而唔係死記硬背

完成

一條 prompt 裏到底有哪些組成部分？

寫 prompt 唔係亂打字，拆開四個要素先係關鍵：角色、任務、上下文、約束，缺一不可。

完成

花了近一年，我把提示詞、Skill、Agent、MCP的關係畫成一張圖

提示詞、Skill、Agent、MCP構成AI協作棧而非菜單，理解層次與關係先過於選擇。

完成

給 Claude Code 挑了 15 個 Skills，按工作流分層

按工作流分層精選 15 個 Claude Skills，夠日常開發用，唔使堆數字

完成

為什麼同一個問題，不同問法得到的答案天差地別？

Prompt嘅信息密度決定AI輸出質量，提供最少充分信息先係關鍵。

完成

應該是目前使用最順手的Skills桌面端工具！

SkillsLM 統一管理多個 Coding Agent 嘅 Skills，實現一次安裝、處處同步。

完成

Codex+image2 自動給文章配專業插畫，文章更好看

Codex + image2 自動配圖，寫文同時生圖，提升閲讀體驗

完成

AI 寫得PRD"還行"，那到底是行？還是不行？10 道題讓它現原形

用10道題考卷量化AI輸出，告別「還行」嘅模糊驗收

完成

馬斯克是SpaceX面子，她才是裏子

格温·肖特韋爾：SpaceX嘅幕後功臣，從瀕臨破產到萬億IPO嘅關鍵推手

完成

Vibecoding 最忌諱的事——寫給任何想嘗試或者正在做的朋友

Vibecoding 最忌諱嘅係跳過架構設計，直接寫代碼，令到後期不斷打補丁。

完成

Superpowers Skill - 讓 Claude Code 和 Codex 按工程流程做開發

用 Superpowers Skill 將工程流程固化，令 AI coding agent 有紀律地開發

完成

Codex 最厲害的根本不是寫代碼！分享 10 個高級心法

Codex 真正價值在於建立協作工作流，10 個心法提升效率

完成

別再 Prompt 完就點 Accept

由 Vibe Coding 轉向 Agentic Engineering：先寫 Spec 再讓 AI 鬱手，先係生產環境嘅正確做法

完成

有了這個插件，用 Codex 寫 iOS 不用再切 Xcode 了

Codex 可以說是現在很多開發者用的最多的 Coding Agent，但用 Codex 寫 iOS 程序的人一定也遇到過這樣的麻煩事兒。你讓 Agent 寫完一段 SwiftUI 的代碼後，得切去 Xcode，選 Scheme，點編譯，等模擬器慢吞吞地轉起來，然後再看一眼實際效果，發現哪裏不對了，再切回 Codex 描述問題，然後再進行修改。整個工作流就像在兩個房間裏來回穿梭，每跑一次都要重新找到自己在哪兒。這個麻煩今天被 OpenAI 主動推的一個插件解決掉了。這個插件叫 Build iOS Apps。它是 Codex 桌面端插件市場裏的一個產物，OpenAI 官方出品，內部標識是 build-ios-apps@openai-curated，屬於「OpenAI 精選」級別，不是第三方做的，是 OpenAI 自己在維護的。要理解這個插件是什麼，得先知道 Codex 插件機制是什麼。今年 3 月 26 日，OpenAI 首次給 Codex 裝上了一套插件系統，每個插件可以往 Codex 裏塞三樣兒東西：◆ 可複用的指令集（Skills）◆ 第三方服務連接器（Apps）◆ 以及跟外部構建工具通信的中間層（MCP 服務器）而 Build iOS Apps 這個插件，本質上就是把一套專門為 iOS 開發設計的技能包，外加一個叫做 XcodeBuildMCP 的 MCP 服務器，打包成了一個可以一鍵裝進 Codex 的能力模塊。以下視頻來源於Codexx裝上它之後，Codex 就獲得了跟 Xcode 模擬器直接通話的能力，不再只是一個往外輸出代碼文本的機器了。Codex 能在自己的應用內嵌瀏覽器窗口裏，直接把 iOS 模擬器的畫面鏡像出來給你看。你呢，則可以在 Codex 裏用自然語言描述需要變動的地方，Codex 會自己去調用 xcodebuild 進行編譯、啓動模擬器、截圖，然後再把截圖展示在同一個窗口裏。你全程不需要打開 Xcode，不需要手動點模擬器，不需要切出去再切回來。更爽是的它還具備 SwiftUI 的熱重載功能，你改一行代碼，界面即可實時刷新。你可以把這個理解成前端開發裏 Chrome 自動刷新的感覺，不需要每次都重新完整編譯整個工程，改了就能立刻看到 UI 變化。這對於在 Codex 裏進行 iOS 開發的人來說，體驗是前所未有的。整個構建循環是純命令行驅動的，底層走的是蘋果官方的 xcodebuild，不依賴 Xcode 的圖形界面。這讓 Codex 可以在 Agent 的自循環裏持續迭代，改一次、編一次、看一次，完全不打斷你的思路。相當於把「編輯→編譯→預覽→調試」全流程都塞進了 Codex 的一個窗口中。而且這個插件裏打包的東西還不止這些。它一共帶了七項技能，你可以把它理解成七個專項顧問。最核心的是 ios-debugger-agent：負責構建、啓動、UI 操作、截圖、日誌讀取和模擬器調試，這是上面說的那套閉環的基礎。另外還有 ios-ettrace-performance：用來分析模擬器上的 app 運行性能；ios-memgraph-leaks：是專門查內存泄漏的；ios-app-intents：可以幫你把 app 功能接入蘋果 Siri 和快捷指令。再加上以下三個 SwiftUI 的專項技能：swiftui-liquid-glass：負責適配 iOS 26 新推出的 Liquid Glass 視覺語言swiftui-performance-audit：做性能審查swiftui-ui-patterns：提供最佳實踐的架構設計模式。簡單理解就是：這個插件不只是能幫你跑代碼，還能幫你做性能體檢、查內存問題、順手把界面適配到 iOS 26 的新設計風格。怎麼裝？首先你得有 Codex 桌面端，在以下 OpenAI 官方開發者頁面可以直接下載。https://developers.openai.com/codex/app裝好客戶端之後，安裝插件有兩條路：第一條是在 Codex 界面裏直接操作點左側邊欄的 Plugins 入口，搜索「build-ios-apps」，找到後點加號，幾秒就能裝好。第二條是在終端裏跑以下命令行npx codex-marketplace add openai/plugins/plugins/build-ios-apps --plugin適合習慣用終端的用戶。裝完插件之後，本機還需要有 Xcode 環境，因為 XcodeBuildMCP 在本地運行，底層依賴 xcodebuild 這個命令行工具。也就是說，你的 Mac 上得裝着 Xcode，並且 xcode-select 路徑要配好。這不是什麼難事兒，但如果你是第一次配 iOS 開發環境，這一步需要提前做。這裏面有兩個邊界得提前知道，特別是對於新手，避免踩坑。第一，Windows 用戶用不了這個插件（能裝但你用不了），因為 Xcode 不支持 Windows，底層構建鏈根本跑不起來。第二，這個插件的優化目標是針對 SwiftUI 應用，OpenAI 官方文檔裏的定位也是 SwiftUI，如果你的項目是純 UIKit、React Native 或者 Flutter，這個插件不是為你設計的，能不能用你可以試試，但多半應該是不行。還有一個背景，就是關於這個 Build iOS Apps 插件，其實在 Codex 市場裏這個插件已經存在有一段時間了，並不是本次全新發布的。在官方 GitHub 上你也能找到：https://github.com/openai/plugins/tree/main/plugins/build-ios-apps之前 OpenAI 官方也一直沒有主動推廣過這個插件，所以可能有很多人根本不知道它的存在。但這次官方親自下場在 X 上主動推廣，說明這個插件已經經過了磨合期，可以正式大規模投產了。寫在最後前幾天剛上的 Site 插件其實跟這個 Build iOS Apps 插件有異曲同工之妙。一個是包辦網站，一個是包辦移動應用。它們都不是 OpenAI 在模型層面上做了什麼突破，只是他們站在開發者的角度，把工作流運轉當中的痛點給揪了出來，然後重新做了個封裝。這是一種「領域專用能力包」的思路，把通用的代碼能力和特定領域的工具鏈、調試鏈、預覽鏈結合起來，捆成一個可以即插即用的東西。每一個插件，其實都是在往某個具體的工作場景裏深入走了一步。走得越深，這個工具就越有可能成為你某個領域工作流的一部分。如果你也正在嘗試開發 IOS 原生應用，不妨去試試官方推薦的這款 Build iOS Apps 插件。最後附上一個官方推薦的啓動提示詞，裝完插件與 Xcode 環境後在 Codex 中使用：Scaffold a starter SwiftUI app and add a build-and-launch script I can wire to a 'Build' action in my local environment.Constraints:1、Stay CLI-first. Prefer Apple's 'xcodebuild'; if a cleaner setup helps, it's okay to use Tuist.2、If this repo already contains a full Xcode project, use XcodeBuildMCP to list targets, pick the right scheme, build, launch, and capture screenshots while you iterate.3、Reuse existing models, navigation patterns, and shared utilities when they already exist.4、Keep the app focused on iPhone and iPad unless I explicitly ask for a shared Apple-platform implementation.5、Use a small trustworthy validation loop after each change, then expand to broader builds only when the narrower check passes.6、Tell me whether you treated this as a greenfield scaffold or an existing-project change.Deliver:1、the app scaffold or requested feature slice2、a small build-and-launch script with the exact commands3、the smallest relevant validation steps you ran4、the exact scheme, simulator, and checks you used既然看到這兒了，如果覺得還不錯，幫忙隨手點個「贊」、「在看」、「轉發」三連；如果想第一時間收到推送，也可給我加個星標★，非常感謝！

完成