---
title: 'STR AI 導入備忘錄'
disqus: hackmd
---

STR AI 導入備忘錄
===

> STR Network 是一間喜劇公司，Lab 是喜劇公司裡負責導入和轉型的團隊。
> 我們認為工具的使用只是末端選擇差異，本文件記錄喜劇公司在流程設計與 AI 導入過程中的思考、試驗與掙扎。
> 此為公開共筆，歡迎登入後於段落旁留言或建議。
> contact: [e-mail]
---

[TOC]

## On-Going Projects
* ==general==: 決策和管理議題
* ==data==: 資料議題
* ==proj-tool==: 內部工具網頁及公司需求開發，主力加速報帳和專案帳務管控
* ==proj-inviti==: 開發禮賓系統服務 inviti
* ==proj-indexing==: 內容索引及自動剪輯序列

## Logs
:::info
- What in mind
- Takeaways
- Next step
:::

### 20251219

寫於 WebConf2025 結束一週之後。
2025/12/12 那天，受龍哥邀請來到 WebConf 分享，分享主題是「[AI 槓桿時間賦能之術——全端工程師獨自升級全記錄](https://www.canva.com/design/DAG7FbmoC8k/jfAbbMkU7cQ7tSZDcNtxbQ/view?utm_content=DAG7FbmoC8k&utm_campaign=designshare&utm_medium=link2&utm_source=uniquelinks&utlId=h01c3afeb3d#1)（點擊查看簡報）」，內容則是在說在 2025 的下半年，我如何在 AI（具題來說是 Claude Code）的幫忙下到處胡搞一堆專案的過程與心得。很幸運地，在活動隔天後發的一篇 threads 文獲得超出預期的回響，近 40.000 次曝光、簡報本身超過 2,000 次觀看，也經由朋友告知被分享到許多社團、群組，受寵若驚之於也收到了許多不同的提問。這些被問到的問題，就像是被 AI 反問一樣，也讓我更近一步思考整個關於學習、協作的脈絡。

==關於學習==

這個命題講的精準一點是「快速學習」，如何在時間短暫的情況下**學習一個自己原先沒有、甚至是跨領域**的知識？
總結過往數十年的~~亞洲小孩~~學習經驗，我發現我尤其擅長模仿，從而內化出了一套學習步驟是「模仿」⭢「驗證」⭢「複製」。
- 模仿：
學生時期，我最愛的兩項運動分別是籃球和桌球，當時最快讓自己變強的方式就是「直接跟我覺得強或我喜歡的人學」！籃球方面我學習 Curry 的投籃姿勢和運球動作，在練習兩年後得以跟當時學校球隊成員打成平手；桌球則是直接模仿了當時短暫加入桌球隊時的同學動作，讓我直掉現在發球基本上還是有著初見殺的水平。簡單來說就是把自己當成《黑子的籃球》裡的黃瀨吧！
而現在學習新技術也是一樣的，當我面對到一個自己完全不會的技術，我會讓 AI 幫我整理出一套最乾淨的架構，並整理到現有的專案中，優先確保測試能過、整個能動，然後開始仔細的 codo review，了解怎麼架構如何設計、了解資訊如何被傳遞。至今我很慶幸的一件事是我在自學程式時經歷過那個沒有 AI 的時代，那時所有的資訊需要靠自己濃縮、整理，所以即使有 AI 的存在有些學習歷程還是不會變的，AI 可以加速學習但絕對不是取代學習，關鍵就是從 DNA 深處開始模仿，知道為什麼桌球發旋球時要靠近桌子、知道為什麼投三分球時要蹲得更低、知道為什麼怎樣的 pattern 可以把程式拆得更乾淨。這些，是 AI 幫不上忙的。

### 20251204

明天要發薪水了，續命續命！

==HotFix 紀錄==

今天經歷了人生第一次的 HotFix，覺得是一個很有趣的體驗，也給自己留了個紀錄，下次再來就不會當下那麼慌ㄌ。

- 起因：
今天上班在處理工具網頁的進度時，突然接到 Niny（營運同事）的回報，印表機功能卡 bug 了！
迅速調查，發現是我們印表機印 QRCode 的服務那邊 CDN 路徑掛錯了（很弔詭的是之前功能上線後我再也沒動過那邊的 Code 怎麼突然噴錯了我也不大曉得），改起來很快，但問題是我手上正好有東西改到一半，總不能把這邊這些半成品一起 push 上去？！
研究所教授在開學就跟我們提過分 branch 開發的開發方式，我也一直遵循著他的教導。當年他就有提到當我們的 Production 環境真的出狀況的時候，得緊急從 Main 開一個 `HotFix` 分支來修復錯誤，但一直沒有實作過的我多少是有點慌張的。但來都來了，只能上了。

- 過程：
1. 確認當前總共有 3 個分支，分別是 `main`、`development`、以及 `feature/sidebar`。在 `feature/sidebar` 先透過 `git status` 確認一下檔案異動，接著透過 `git stash` 把所有暫存都先包起來。

        git status
        git stash push -u -m "WIP: sidebar 開發到一半"

2. 切回道 `main` 從這邊開出一個分支來修 bug（先 pull 確保是最新狀態）：

        git switch main
        git pull origin main
        git switch -c hotfix/bug-qrcode-printed

3. 改完 bug 之後，正常操作地 add 與 commit 後 merge 回 main branch，並順手將 main 推回去

        git switch main
        git merge --no-ff hotfix/bug-qrcode-printed
        git push origin main

4. 接著要沿路 `main` -> `development` -> `feature/sidebar` merge 回去。
5. 最後把 stash 裡的修改紀錄 pop 出來，有 conflict 的話就認了乖乖解。

        git stash pop

以上是人生第一次 HotFix 的紀錄，希望下次自己再遇到的時候別那麼緊張了，好險是以這樣小小的改動學到這個，要是再大一點我可能直接離職逃跑（開玩笑）

#### 後記
執行到第三步時（把修好的版本 push 回去時），就這麼剛好遇到 Zeabur 臨時地故障，
導致即使改完了也沒有辦法順利部署，終究是緊張了一下，好在是有驚無險🫡再次感謝 Zeabur 超人的努力，如果至今還沒用過 Zeabur 的人歡迎用我的折扣碼ㄛ！你可以獲得 5 美元的額度，直接享用台北 AWS 機房的低延遲享受！[](https://zeabur.com/referral?referralCode=STRfong&utm_source=STRfong)

### 20251201

今天紀錄測試了的新工具、與同事新的合作方式、以及零星的工作紀錄。

==測試了的新工具==

11/23 時，PostgreSQL 官方發布了一則[貼文](https://www.postgresql.org/about/news/pg_ai_query-ai-powered-sql-generation-query-analysis-for-postgresql-3175/)，表示他們新發布了 Plugin **pg_ai_query** 讓 AI 可以根據自然語言產生 Query 語法。看到保哥分享時心理異常興奮，因為這跟 Sunny 幾個月前在做的事不謀而合：

接著就是通報了 Zeabur 的給力夥伴們，他們也在 11/28 快速做出了對應的 [pg 模板](https://zeabur.com/zh-TW/templates/XJOIMQ)；快速部署上線之後並遷移資料後，發現一來他會產生出錯的 Query 外，二來他就是「只產生 Query」，並不像 MCP 那般，可以直接透過自然語言的方式真正地做到與 DB 對話。

所以暫時放緩對其的研究🚬

==與同事的新合作方式==

最近 Gemini 3 的大進化，讓很多人投入了 Vibe Coding 的行列，各式前端小工具、小遊戲（最近沈迷於一款叫[幻想世界](https://shota6666.github.io/fantasyadventure0/fantasyadventure.htm?media_id=3773552275173355006_73995445592&media_author_id=73995445592&source_quote_media_id=3773577663714842931&utm_source=ig_text_post_permalink)的純前端小遊戲，甚至是部署在 github page 上！）當然薩的同事也不例外！

最近有個串流的活動，同事們就靠著跟 gemeni 的對話，變出了一個好完整、RWD 做很好心理測驗，一樣透過 github page 部署後讓大家所有人試玩了，體驗那是真的一個好！並且這個專案在後續其他同事們提出的修改點後都還是 AI 可以改得動的狀態，除了側面說明 AI 真的變很強之外，也證明了 AI 現在真的可以輔助許多非工程師達成過去所無法完成的 idea。

而這個專案的下一步就是正式地部署上線，這塊似乎真的是程式小白最難跨越的一塊，說實話在學校操作 Heroku 的時候也實在是很痛扣，但現在有 Zeabur 的幫忙，一切就兩個字：絲滑！

接著就是我收到了一個打包好的 ZIP 檔，由我上傳到我的 Github 觸發 Zeabur 的部署，10 分鐘拿下這局。這樣新的合作方式讓我回憶起幾個月前《賀瓏夜夜秀》時的恐怖回憶，在 AI 相關的 CLI 工具都還沒出來的時候要快速做出像「韓國瑜午餐轉盤」、「罷免理由拉霸機」這樣的前端網頁荒謬作品還是會耗掉我兩個工作天；僅僅過了數月，大家都有能力做出來了！無需任何程式背景，現在的世界真的變得像是《葬送的芙莉蓮》口中的：

==proj-inviti==

INVITI 最近對資料庫的欄位進行了調整，原本每一筆的參與紀錄並沒有特別保留一個欄位是「邀請人」，理由是在原先的設計中，就已經以外鍵關聯了 VIP 的資料，而那邊就有一個邀請人了。為了不重工，我們選擇每次更新 VIP 那邊的邀請人資料，起初還沾沾自喜，想說太好了，這樣就可避免掉之前資料會遇到的問題：
> VIP 的內部聯絡人都不是最新的

但！直到最近外部使用者也開始操作系統，我才發現這樣想就是狹隘了。如果今天我想要調用「我個人在過往的邀請紀錄」，在這個架構下就會大失敗，因為即使我邀請過某 A 來參加活動，在未來的日子只要被其他人加入到資料庫，那麼聯絡人就會被覆蓋，我彷彿就沒邀請過某 A 😭

奇怪，回頭想想都覺得腦袋像是被抽到，邀請紀錄裡直接多一個 FK 關聯到使用者根本不會多麻煩，也可以輕鬆透過 sort 找到特定 VIP 最新一次參加紀錄中的邀請人是誰啊？

意外累積技術債的感覺不是很好，但一方面又很慶幸在還可以挽救的範圍真是太好了！

重要 Takeaway:
> 關聯式資料庫好用，但還是要看場景，不要抱著「反正一路關聯過去就查得到資料」的心亂省資料欄位，該插 FK 的時候就插吧！不然查資料的時候會很痛苦的

附上 GPT 最近警告我的，但我還是覺得很荒謬，我沒有教我的 GPT 這樣講話啊？？？

### 20251126

昨天發票沒中，今天要乖乖繼續上班：（

==general==

大概在五個月前，薩因為有一些在 kktix 售票的活動而有了從 kk 執行票務回報的需求。以今年來說算是第一次，因為不論《賀瓏夜夜秀》或是《奧德修斯》都是在 FANSI GO 上面賣票，而他們家是有開 API 給我們的，所以要取得即時的票務資訊就容易許多，可 KKTIX 就不一樣了，沒有開 API，也沒有下載單一天報表的功能，所以我第一時間認為我可以做的事不多，頂多就是做到讓整理資料的人可以更方便地更新資料到 Slack 回報僅此而已。

但本著姑且一試的心，並拿出之前偷撈 JVID 資料的經驗，這次竟然又又又再次順利地從 AJAX 的端點拿到了資料 XD 然後就是 Docker + FastAPI + Puppeteer + Cloudfare Tunnel 搭了一個定時回報票務的 server 在公司，用 Google Apps Script 將資料整理到 Google Sheet 再打到 Slack，這題就這樣解掉了（？）總歸得謝謝 K 老大用 Cookie 當登入驗證還四個月不會過期，心裡是有些疑慮但就這樣吧🤡

但餅乾總有過期的一天的。

四天前是禮拜六，系統回報公司那台 Server 噴 401 了，心裡直覺是 Cookie 終於過期了是吧，所以今天一進辦就準備來換個 Cookie，不出意外的話就出意外了。因為對 Docker 沒有像我對 Django 框架那樣的熟悉，所以一上來就吃了大虧，換了 Cookie 卻持續 response 401 讓我心都涼了一半，「東西能跑我們就不碰」是（我個人）開發過程中的鐵律，今天我沒碰他也不跑了這要我怎麼辦？！

問了 GPT，他叫我 restart；我 restart 了，系統還是回我 401，這可把我搞急了，抱著死馬當活馬醫的心理，我重 build 了 image，ㄏㄟˊ，好了（？）當初我的設計，是 docker 只會一直跑著 FastAPI 程式，接到 request 才會啟動 Puppeteer 去打 KKTIX，估計也是因為這樣我才不能夠單純的 restart 或是 compose down 再 compose up 來更新我的結果。

總之，今天的知識點：下次再要換 cookie，即便那只是程式碼裡的一行常數，也要重建整個 image：）

 docker compose build --no-cache puppeteer-login

### 20251119 - 20251120

==proj-tool==
- 把專案預付款申請的功能全部移植到工具網頁中了。
「專案預付款」的流程，源於一次的突發奇想：一筆現金出去之後，我要怎麼知道這些錢被花去哪裡？於是以專案預付款編號 + QRCode 追蹤花費狀況的 side project 就這樣誕生了（延伸閱讀：[小聚簡報](https://www.canva.com/design/DAGbgUOIG2o/FJ07A_iwDWKko6YKCKbytA/edit?utm_content=DAGbgUOIG2o&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton)）

整個流程是這樣的：
1. 製作組（或任何需要申請專案預付款的同仁）從 Slack 的ㄉ WorkFlow 送出請求，相關資料將會發送到 Google Sheet 保存。
2. 出納端核可後，會在 Slack 點擊「核可」，並透過 Google Sheet 中的 Google Apps Script 印出 QRCode。
3. 請款同仁每次送出核銷時，都會需要將核銷的資訊連同專案預付款的編號一起送出，將「核銷內容」與「那包錢」綁定在一起。
4. 在確定所有項目都結清後，透過 QRCode 核對手上的錢與已登記的費用是否吻合，並送到出納完成核銷。

而這個流程從第一次的 QRCode 印出直到上個月歷經了超過 10 個月的時間，驗證了兩件事：
1. 欄位的固定性。
過去這些日子，上至 Slack 中的 Workflow 下至製作組同仁透過 QRCode 查看專案預付款花費狀況，與其他的報帳流程不同，這裡的 flow 完全沒有被 challenge 分毫（除了速度），欄位至始至終就那幾欄沒有變過 -> 代表這些欄位是可以被固定的，我們不需要給使用者們變動的彈性了。
2. 工作流的有效性。
以往錢出去之後，出納端在核銷的過程會非常痛苦，錢東落西落，常常會有數字對不起來的問題；而這套拼裝車流程，卻讓出納們給出了「一塊錢都沒有出錯」的、我認為至高無上的評價 🤩 這也意味著這樣的開發方向沒有錯：在一線使用者沒有反彈的情況下，讓下一步接球的工作者也減輕了負擔。

移動到工具網頁，當然使用者可以用最小的改動（送出請求端從 Slack 變成了網頁上的一個彈出視窗）享受到最大程度地優化（之前掃描 QRCode 算餘額要跑超久因為 Apps Script 的效能問題），但最讓我雀躍的部分，是這個系統更近一步整合了薩泰爾內部的核銷流程：原本發散在各地的、各長各的 Best Practice，在透過像是[程式搬遷](https://hackmd.io/-g7fBM-KT5Ok-atySg9Nag#20251029)和流程搬遷的過程一步一步收攏，逐漸靠近我當初心目中認為應該要為公司做到的事情，我想這才是完成這次整合最有價值之所在。

==general==
- ChatGPT 可以直接編輯 Canva，上傳中文簡報之後重新整理脈絡改成英文簡報

### 20251118
==general==
- 今天讀到火球祭這篇報導，對於持續提升體驗有感，有點介意他們的場景的複雜性 https://blow.streetvoice.com/84531/ ，處理攤商和金流以及觀眾的排隊體驗，這些都跟音樂演出無關卻跟體驗有關，由衷的感到敬佩。

==proj-tool==
- 報帳入口短暫崩，zeabur
- 
- [結果是 cloudflare 從 19:30 開始大當機](https://www.independent.co.uk/tech/cloudflare-down-twitter-not-working-outage-b2867367.html)
- 完成了全站的服務帳戶使用，如此一來便可以不跟使用者要寫入 Google Sheet 的權限！
- 完成批量匯入傳票的功能，又一次發現我認為的好用跟實際的使用情境是如此地不同

### 20251114
==general==
- what in mind(sunny):
- 這週接受採訪還有整理一些報獎用的資料，對於「工時」這個概念感到不太舒適。我們從每個節點省下來的時間，並非僅僅是省下時間。KPI 對我而言相對沒有意義，我需要永續的環境和快樂的工作者。
- 公司 slack 方案升級，slack 加上了 ai recap 和每一句都能自動翻譯的功能。使用兩週至今感到雜訊增加，因為我們有很多自動化的機器人，recap 量化且定型的流程意義不大。

==proj-tool==
- 報帳工具很流暢，但太流暢，以至於使用者可能跳過人為檢查的步驟。具體場景：匯款截止日當天提交的核銷需求自動被認列為當天也要出帳。

### 20251113

==general==、==proj-tool==

最近在拼的就是所謂 AI 的命中率。
- What in mind（fong）：
架構還是重要的。尤其最近教書 + 瘋狂修整公司的 bug，讓我深刻感受到架構的重要性。學生很多會超前完成很多事項，因為我不會阻止他們使用 AI，也是在近期他們開始哀嚎：**「老師我發現程式開始會出現一些 AI 解決不了的 bug」**，但其實不論是功能開發或是 Debug，只要架構夠清晰，一切絕對都不難，要拼的就只是誰越快讓 AI 找到對的位置去處理問題，讓他越慢打到 context window 的上限，就可以進一步拉高那個完成度。
- Working log
1. 升級了工具網頁的諸多功能：
- 把從個人 OAuth 端取得權限輸出 Google Sheet 的功能統一調整成了以服務帳戶帶操的功能。
- 完成了批量輸入傳票編號的功能（這個感覺像是開發之前沒有調查好的緣故）
2. 修了五個 INVITI 的 Bug：
- 優化｜批量新增貴賓的介面現在點了之後要跑很久才會跑出來
- BUG｜單筆新增貴賓時，可以在沒有選擇「內部窗口」直接送出，但送出後會無法再更新
- BUG｜地區名單新增貴賓「內部窗口」的欄位不能選
- UI｜地區出席名單，批量寄信的錯誤訊息需要跟單封寄信時一樣
- 地區名單版面（分頁）

### 20251029
==general==、==proj-tool==

一鼓作氣把本來架設在 EmilyRPA 那台黑蘋果上面的程式移到了另外一台 MacBook Pro 上，並整個改寫以 Docker 完成整段程式碼，再透過 cloudfare tunnel 連上自己網域。

- What in mind（fong）：
這次的升級解決了幾個痛點：

1. 之前在黑蘋果電腦啟動速度十分緩慢，同時因為同時有 RPA 在跑 RAM 消耗巨大，動不動當機、重開機，程式就得重新啟動。
2. 承上，同時因為之前是透過 ngrok 的方式將本地程式連上公網，一但重新啟動，網址就會產生變化（免費版），對於我後續打 post 的端點要修改就十分麻煩。
3. 透過 docker 完成後，之後如果這台 Mac 掛掉的話，再拿下一台電腦補上就非常快速。

最後則是跟工具網頁的需求有關：當今天後端要打的 api 端點不會再有亂七八糟的變化，就可以把原本不在工具網頁內部的工具整合進去。因此！下一步就是準備要來把專案預付款的流程移動到工具網頁！

### 20251027
==proj-inviti==
- what in mind:週末高流演出貴賓報到基本上還是依賴紙本，在現在工作時紙本也許還是比較直接。(s)其中貴賓室邀約以出示圖片為主，目前看來合理，現場人員也不需要花太多時間檢查身分。這樣的演後活動未來可以有更敏捷可愛的機制，例如事先給貼紙等。
==general==
- takeaways:
- 工作餐敘前輩表示 inviti 很適合創投使用。

### 20251022
==general==
- what in mind:(sunny)
- 管理面評估生產力工具使用，建議公司捨棄 Asana，原因：組織調整後應調整任務派發和驗收方式，不再需要所有人都開 account。
- notion 的資料庫很 rich 但不敏捷，當閱讀介面、資料提取有更好的做法（例如 chat），notion 的美觀就不是那麼必要。現階段 chatgpt 的 MCP notion 已經可以做到。

==proj-tool==
- 彈性議題（fong)
- 以傳票的輸入方式為例，在設計時原以為針對核銷編號逐筆輸入會是常態，但在跑完兩輪的匯款週期後發現，更多需要輸入傳票號碼的場景，反倒是在大量匯款完成後要一口氣批量更新（約佔 80%），那麼【輸入傳票號碼】這個功能就應該在兩個輸入情境間保有彈性讓用戶選擇，不強迫所有的輸入端口要維持在系統中，而是讓用戶多一個更順手、更熟悉的選擇，即使用 Google Sheet 批量輸入。
- 不需要彈性的議題
- 有些流程在過去一年裡，如果沒有太多需要手動調整的欄位或是除自動填入外的輸入方式變動，在接下來的流程中，會被我歸類在「不需要彈性」的流程，即我們可以把它固定在一個方便我們使用的位置（系統？Google Sheet？）就好。

舉例來說，目前的「專案預付款申請」就是一個可以被定調為「不需要彈性」的流程。現在的流程，讓不論內部或外部的使用者可以透過 Slack 或是 Google 表單來提交申請，資料寫入 Google Sheet 後再交由營運人員審核及發放。然而，現在這個流程再多出一個系統後，讓資料會分隔兩地：實際大家核銷的數據會放在系統中，而大家申請的資料去被保留在 Google Sheet，這就導致了會計人員在對帳時的不便，以前都在 Google Sheet 時用 ImportRange 拉一拉就好了，但現在可沒這條路能走。

於是便產生了討論：「申請專案預付款還有需要放在 Google Sheet 這樣保有大量變動彈性的存放空間嗎？」
- 使用者教育自動帶入功能反而造成更多呆
- 這十分令人哭笑不得。由於為了滿足會計所需，每次報帳都會需要填入非常多的資訊，舉凡憑證的編號、類型、日期，或是花費的項目、稅金、總價、和摘要，最後是公司內部管理的項目如專案和承辦人員，上述零零總總加起來約有 10 個欄位要填寫的情況下，一直被詬病的一點便是「太多欄位太麻煩」，於是我們在新系統中設計了非常多**自動帶入**的功能，希望可以減輕使用者的負擔。

有一好沒兩好，此舉確實加快了用戶填寫核銷資料的速度，卻也因為少了讓他們「逐筆輸入」的斷點減降低了「需要檢查」的戒心，「自動代入」開始變成了「欄位填寫錯誤」的藉口，反而開始造成了營運端需要不斷修改前端用戶錯誤填寫的資料而發起抱怨。這會是個在接下來開發過程中要面對的議題：方便 vs. 嚴謹？

---
# Keywords
- DDD (Domain Driven Design)
- DST (Domain Story Telling)
- Align, Empower, Transform

---
# 附錄
## 相關文件
[薩泰爾娛樂公司文化](https://hackmd.io/@strlab/rkr_C0txZl)

## 簡報分享

## Team：對內任務優先級說明

| 等級 | 說明 | 處理原則 |
|------|------|-----------|
| **P0** | 🚨 網站或系統停機，所有工作停止直到問題解決。<br>嚴重影響整體運行。 | 立即處理，全員支援。 |
| **P1** | 🔥 阻礙他人進度或流程的問題。<br>需優先完成以解除瓶頸。 | 在其他任務之前完成。 |
| **P2** | ⚙️ 日常工作任務，標準優先級。 | 按排程執行。 |
| **P3** | 🌱 改進項或潛在優化。<br>非急迫但有價值。 | 時間允許時進行。 |
| **P4** | 📝 僅供參考的建議或想法。 | 保留紀錄，不需行動。 |
## 公開報導
| 編號 | 標題 | 媒體 | 時間 | 連結 | 備註 |
| -- | --------------------------------------------------------- | ------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -- |
| 1 | AI先鋒薩泰爾為何不停打掉重練？做AI，先理好你的「管理債」 | 商業週刊 | 2025/6/26 | [https://www.businessweekly.com.tw/Archive/Article?StrId=7012596&rf=google](https://www.businessweekly.com.tw/Archive/Article?StrId=7012596&rf=google) | |
| 2 | 從害怕被ChatGPT取代到玩轉AI，菜鳥工程師兩年練出十年功 | 商業週刊 | 2025/3/13 | [https://www.businessweekly.com.tw/Archive/Article?StrId=7011988&rf=google](https://www.businessweekly.com.tw/Archive/Article?StrId=7011988&rf=google) | |
| 3 | 《博恩夜夜秀》幕後功臣：薩泰爾團隊AI神用法，如何讓全員升級？ | 遠見雜誌 | 2025/2/27 | [https://readwise.io/reader/shared/01jn5v2q1tas5nx016xtdmcexk/](https://readwise.io/reader/shared/01jn5v2q1tas5nx016xtdmcexk/) | |
| 4 | 博恩破億票房推手　薩泰爾娛樂把工作變樂高，用AI遠離無聊 | 天下雜誌 | 2024/11/11 | [https://www.cw.com.tw/article/5132623](https://www.cw.com.tw/article/5132623) | |
| 5 | 【Generative AI 年會爐邊談】一鍵生成文件不是夢！薩泰爾四階自動化從 EPA 到 GenAI 全數公開 | INSIDE | 2024/5/22 | [https://www.inside.com.tw/feature/2024-generative-ai-week/34926-str-sunny-genai](https://www.inside.com.tw/feature/2024-generative-ai-week/34926-str-sunny-genai) | |
| 6 | 為了加速文書作業，親自開發「合約產生器」！薩泰爾娛樂鄭晴元：別讓員工被低價值工作困住 | 經理人 | 2024/5/16 | [https://www.managertoday.com.tw/articles/view/68580?utm_source=copyshare](https://www.managertoday.com.tw/articles/view/68580?utm_source=copyshare) | |