幫公司寫的打卡機器人功能已經正常運作了 2 週左右，差不多也是來做心得總結的時候，一個完全不懂程式的文組小祕書，如何利用 AI 協助寫程式，當中又遇到了什麼困難，最後是我的心得感想。
規格說明：我的資訊能力還有背景
身為一個文組人，我的日常工作和程式設計從來沒有交集，和程式碼稍微像一點的，就是我很會寫 Excel 的公式 
不過要說完全沒有程式基礎可能也不太對，雖然看不懂程式語言，但在資訊素養與認知，可能還是高於平均。
和 AI 一起寫程式，專案開始
從今年的 AI 年會看到薩泰爾的分享，還在 AI 社群讀書會當中，許多像我一樣沒有技術背景的文組小夥伴，利用 AI 完成了許多功能實用的小工具和專案，看著這些案例當下超級興奮的，也想著：「或許我也能試試看寫個什麼？」
一開始我以為我會寫什麼「合約產生機器人」之類的，也想過自己的日常可以作一些什麼，不過從「想法」就開始卡關，一來是我想不到我有什麼事情需要特別寫個 AI 來處理，而不用現用的工作流程或者工具就好？其次是眼界不夠開闊，我缺乏想像，沒有辦法想出「原來 AI 可以這樣應用」。
很有趣的事情就是，還是回到產品營的第一個訓練 ── 為什麼要做一個產品？其實到最後這些產品是為了要解決問題，那麼現在有什麼問題要解決？剛好公司需要解決將大家在 Slack 上的打卡紀錄抓下來匯總成冊、保留 5 年這個問題（感謝勞動部…），如果都用手動就真的太蠢了，於是小專案就出現了。
專案過程的困難
看了幾個案例之後，我想著，前輩們的東西拼拼湊湊應該不會太困難，所以我決定用 AI 幫助開發一個 Slack 的打卡機器人，功能其實也很簡單，就是抓取 Slack 特定頻道的打卡訊息、人名、上／下班卡別、訊息時間，都寫入 Google Sheet 裡，後來還自己加了 Slack 的 定時發送「缺卡通知訊息」，這兩個功能就構成了我的出缺勤紀錄機器人。
這個想法看似簡單，但過程卻真的是重重難關。一開始依照 ChatGPT、Claude、Perplexity 的教學設置 Slack 機器人的時候，就遇到權限問題，機器人無法正確啟用並且加到 Slack 頻道裡，後來是靠著三方比對，把問題問得更深入，在 Perplexity 的延伸問題中，才找到蛛絲馬跡。
好不容易完成了「抓取上／下班打卡紀錄」這個功能時，又發生了日期無法 match，所以打卡紀錄每次執行都會新增一筆當天相同的資料而非更新當天的上／下班打卡紀錄，和 AI 互動到最後差點翻桌，直接 call out 求助，還順便 code review。事後我詢問了程式好朋友，為什麼會有這個問題，他告訴我，因為寫入 Google Sheet 之後，原本的日期就不是我們眼中看到的資訊了，他的格式除了 yyyy/mm/dd 以外，還會有時區、經緯度…等等，所以 AI 在抓資料是一比對，就覺得今天還沒有資料啊，自然就繼續新增，而不是更新現有資料了。要解決不難，就是在更新資料要重新判讀原有的日期欄位，但幾經嘗試一直失敗，所以我劍走偏鋒，直接改為每次抓資料時都直接砍掉重抓，反正 30 天的資料而已，還能忍受。
最後，我完全沒有想到，最大的挑戰來自後續的提醒功能。我希望機器人能在中午 12 點還有晚上 8 點，提醒當天沒有打卡的同事記得補打卡，我原本以為，我都有打卡紀錄的資料了，不就是照著這個結果，發提醒訊息而已，是有多難？結果卡關卡最久就是這裡！
而最煩且煩讓人沮喪的問題是 AI 寫程式最底層的問題。三種功能其實都陷入相同的困境，原先這三大功能都是在同一個 Google Apps Script 的腳本中，每當我請 AI 修正或者調整錯誤的部份，它會重寫整段程式碼，錯的不一定改成對的，更煩的是它會覆蓋掉之前正確的部分，有時候還會不小心刪除部份程式碼。這種反覆修改的過程既耗時又令人煩躁。
解決問題靠得反而是專案管理經驗
AI 這種反覆修改是無常的，他的本質上是一個抽卡，什麼時候抽到 SSR 完全靠運氣，而且也因為版本太多，每一天在金魚腦上床睡覺前，都要決定要退回哪一個版本，才能繼續穩定提升品質，所以最後，我開始請 AI 依據我的檔案命名原則，加註 log，方便版本控管。
另外，反覆修改之下，每次都要重新測試所有功能是否正確，沒有被改到錯的，真的太累人了。有一天我靈光一閃想起以前專案管理的時候，我是用模版來處理各種活動，也會用專案 dashbaord 來匯總所有檔案與資源，所以又開啟了一個對話，和 AI 討論塊組化還有整合調用的作法以及可行性，每一次只專注一個功能，抓記錄就抓記錄、抓名單就抓名單、Slack 訊息就只寫 Slack 訊息，然後再用一個中樞管理檔案去調用，從一個大腳本拆成 6 個小腳本，才開始把產出的品質穩定下來。
雖然最後真的寫出來了，這段經歷讓我重新思考：使用 AI 來寫程式，真的有效率嗎？我們是否應該走這條路？一開始興致勃勃時大概花了 3 小時左右寫出了抓取上／下班功能的腳本，但實際整個專案完成，應該耗費了 5 倍以上的時間（我猜應該 20 小時），若不是當作一個新工具的嘗試，這 20 小時拿來上個班，我都可以多完成 1 週的進度了。
那文組人應該開始與 AI 協作，一起寫程式嗎？
這是一個沒有標準答案的問題。但從我的經驗來看，這值得嘗試。AI 確實降低了寫程式的門檻，它讓像我這樣的非技術背景者也能做出實際可用的工具。但同時，它也揭示了一個重要的事實：AI 並不是萬能的。在設計複雜功能時，仍然需要邏輯思考和耐心。
這樣的嘗試讓我學習到的事情是，就算邏輯給得再清楚，AI 都不見得第一次就成功。我當時的 prompt 連決策樹都給了，第一版的完成度也只有 60% 左右。如果 prompt 連這種架構都沒有，AI 在釐清需求這塊應該要更多的時間。我也是沒想過，產品營學到的釐清需求這個練習，會用回自己身上（笑）
以前，我對程式還有技術，一直抱持著「交給專業的人來完成」這個想法，完全符合經濟學的比較利益原則，這個想法現在依然沒有變，在自己動手嘗試後，我更能理解，程式的開發需要考量的不僅是功能本身，還有邏輯結構、效能優化，甚至是版本管理。就和一開始我就知道 AI 無法取代小蜜的功能一樣，AI 也無法取代工程師。我可以請 AI 寫出 6 個檔案，將近 800 行的程式碼來解決一個小問題，但厲害的工程師可能 100 行以內就可以解決了（之前那份 code review 過的腳本，真的是讓產出穩定非常非常多）。
如果還是想要試著寫寫看
以工具來說，Google Apps Script 還有 Chrome 外掛依然是最好入手的地方，但我覺得最重要的是學習了如何站在工程師的角度去看待問題，還有怎麼去用工程師的邏輯結構（至少是「有邏輯」）去描述需求給 AI 聽
其次，接受技術限制，找出解決辦法。AI 工具的侷限讓我認識到，AI 寫程式不可能一步到位。與其執著於完美，不如先完成最小可行版本（MVP）。然後，直接找大神幫忙 code review 或者調整。我覺得站在文組人還有工程師的兩種角色來說，這是 AI 能夠幫上最多忙的地方。我們可以先簡單呈現我們想要的是什麼，在 AI 足夠清楚的註解之下，工程師夥伴也可以快速找到要處理的地方，快速拉齊彼此的認識，省下時間，一起前進。（突然想起峰值體驗，老師的節點有種成功耶 
）
）
最後，一定要做完整的記錄與版本管理。在反覆修改腳本的過程中，版本記錄的重要性變得更加重要，在找程式好朋友協助時，清楚的文件與版本控制也可以節省很多溝通成本。
我還會不會再寫？
也許會吧，案例看得愈多，也還是會覺得可能性好大，也會想試試看。AI 讓寫程式變得更容易上手，但它並不是完美的工具，很多細節仍需要手動調整。
不過下次會把範疇再縮得更小一點點，讓成就感早點來，也不會覺得有 AI 什麼事都可以辦得到，AI 是工具之一，重點是選對工具、提升效率，而不是「想辦法用 AI」。那是學習的過程，不是策略與產出。
AI 寫程式番外篇
這篇是用 ChatGPT 的對話模式寫的，雖然他寫出來的東西爛透了，我大概改了 70% 以上，但用訪談的方式可以講出很多沒有想過的心情，有人打稿也解決了我懶得從頭寫又拖延症的這個問題，而且又嘗試了一個 AI 功能，真的是一舉兩得~ 