我主要工作是 iOS app 開發，現在工作有很大一部分是在終端機裡與 AI agent 協作：研究方案、規劃功能、修改程式碼、分析 crash，最後再由人進行審查與驗收。

現在的 model 都很強大，真正影響成果的已經不是 prompt 寫得多漂亮，而是能否提供完整 context、把重要知識外部化，並將重複流程工具化。這篇文章會整理我日常工作流程，以及幾個已經實際使用的案例，希望能跟各位交流分享，聽到更多人的使用案例。

工程師都會有自己習慣的電腦設定，我自然也不例外。本文記錄了我自己的環境建置，方便以後換電腦或換工作時可以快速 setup。

Visual Studio Code 是我預設的文字編輯器，它跨平台、執行速度快、開啟大檔案沒問題、擴充套件眾多，是我選擇用它的主要原因。底下列出一些對我幫助很大的擴充套件：

好幾年前我曾經寫過一篇讓 Xcode 專案易於版本控制的方法，它非常的好用，我也在多個專案裡頭使用這樣的配置用了好多年，都沒有出過什麼問題。

直到最近遇到了 SwiftUI 的 Preview 功能。

猜測可能是因為原先的設定是在 Build phase 去執行排序的 script，導致它破壞了 SwiftUI Preview 的一些機制，我想到了幾個解法，像是

• 不要放在 Build phase，放到 Run phase 去執行。
• 改用 XcodeGen 之類的工具產生 project file。
• 使用 git hook 的 pre-commit 來執行排序。
• 不要用，等真的遇到 merge conflict 了再說 lol

最後我選擇了 pre-commit 的做法。

Git-Flow 是 Vincent Driessen 在 2010 年提出的一套 Git 分支模型，簡單的說，它有 master 跟 develop 這兩個主要的分支，以及 feature / release / hotfix 這三個支援型分支，至於各個分支的用途看圖片應該就懂了，或是看原文有更詳細的說明。

由於當時大家對如何使用 Git 還處於摸索的階段，所以當這套規範被提出並且大家發現真的滿好用的之後，它很快就被廣泛的接受。

這個方法的步驟如下：

1. 建立一個 .gitattributes 檔
2. 輸入 *.pbxproj merge=union
3. commit 這個 .gitattributes 檔

這些動作告訴 Git 「針對 .pbxproj 檔要使用 union 的 merge 策略」，翻成白話就是「要包含對方的修改跟自己的修改」。

在之前的文章裡頭，我們已經將檔案照檔名排序了，所以當遇到合併衝突的時候，可以安心的包含對方的修改跟自己的修改。

參考來源