社長的留言透過 Slack 流傳，於是我們用 AI 打造了審閱 Web 應用程式，卻遇到另一道難關的經過

〜設計師與 AI 一起在 Cloudflare 上打造了一個帶有驗證功能的 Web 應用程式〜

大家好，我是 UI 設計師 Hasshi。

最近越來越少先畫線框圖再請客戶確認，反而更常用 AI 製作 LP 或網站的模擬稿，再請客戶過目。

過去請對方確認設計時，都是透過 Slack 收到類似的留言，

「這裡請把留白加大！」 「這張圖片換掉！」 「這裡的文字要修改！」

諸如此類的回饋。

乍看之下，這是很普通的做法。

事實上，過去這樣做並沒有造成什麼大問題。

不過，自從開始用 AI 大量製作原型之後，某個問題開始變得明顯。

留言不斷流動。

Slack 很方便。

雖然很方便，但它當然不是專為設計審查打造的工具。

日常的工作聯絡、閒聊，以及其他專案的討論，全都會流進同一個地方。

結果就是，

• 修正留言流進其他對話串，
• 對話串越來越多，
• 於是出現「那個修正到底在哪裡？」的情況，
• 回過神來，話題已經轉到別的地方，

這類狀況時有發生。

Slack 也有清單功能。

我之前也寫過一篇關於運用 Slack 範本改善工作流程的文章。

從 Slack 範本開始的輕鬆 DX | 主題 | Liberogic Inc.

不過，串文的通知不易辨識，而如果把通知串接起來，訊息欄又會變得混亂……。

結果，

只有聊天區域越來越熱鬧。

用 AI 製作 LP 的速度已經快了好幾倍，但審閱的方式卻還是老樣子。

就算生成的部分變快了，如果之後的審閱卡住，實在很可惜。

於是我想到了一個方法。

那麼直接在 HTML 裡寫註解不就好了嗎？

製作一個 LP 時，我突然想到。

如果能直接在 AI 製作的原型 HTML 上留下註解，不是很好嗎? 而且，如果能把註解和附加的參考圖片打包成 ZIP,直接交給 Claude Code 或 Codex 等 AI,不是更方便嗎?

雖然在截圖上用紅筆標註也很容易理解，但如果能直接審查 HTML 本身，

• 點擊的位置
• 目標元素的 CSS 選取器
• 附近的文字
• 頁面名稱
• 附加的參考圖片

等資訊也能一併保留。

也就是說，

不必說「幫我改這裡」，而是能說「把這個 HTML 元素改成這樣」。

這個做法似乎也很適合用來請 AI 協助修改。

「這個是不是很方便？」

就這樣開始動手製作的，是

Design Marker（LP 紅字校對工具）

。

先試著做了一個

最初的版本是在自己電腦上執行的本機應用程式。

使用方式很簡單。

1. 將 HTML 檔案整組壓縮成 ZIP
2. 拖曳至 Design Marker
3. 在瀏覽器中顯示 ZIP 內的 HTML
4. 點擊想要標註的位置
5. 撰寫留言
6. 匯出包含留言資訊的審閱 ZIP
7. 交給 Claude Code、Codex 等 AI 進行修正

就像在截圖上畫紅線一樣，可以直接在 HTML 上留言。

很久以前如果要做這種東西，不知道要花上幾天。

在開發過程中，

留言列表、負責人姓名、跳轉至留言位置、圖片附件、整合多份審閱……。

「這個也想要」「那個也想要」，功能一點一點地越來越多。

從這時候開始，

這樣看來，作為內部工具其實很方便吧？

然後就漸漸得意忘形起來。

與 AI 的配合度比想像中還好

製作 Design Marker 的過程中，最有手感的是與 AI 的整合。

如果在一般聊天視窗中請 AI 修改，

「請把左上角的圖片再放大一點」

這類指示往往就是這樣。

如果是人與人之間，看著畫面大致就能理解，但對 AI 來說，「左上角」指的是哪裡、「圖片」又是哪個元素，都很模糊。

在 Design Marker 中，點擊 HTML 元素後，就能取得像這樣的 CSS 選取器。

article.strength-item:nth-of-type(1)
 > div.strength-visual-wrap
 > div.illustration-slot

接著就會把內容傳送給 AI，

請將article.strength-item:nth-of-type(1)內的插圖放大至目前的約 115%。

可以這樣下指令。

只要 DOM 結構沒有大幅改變，就能相當精確地鎖定要修改的目標。

還可以一併提供頁面名稱、附近的文字、註解，以及參考圖片。

過去，

不對不對，不是那裡！

過去得反覆向 AI 重新說明的修改，現在一次就能準確套用到目標位置的情況也越來越多了。

「以 HTML 進行審閱」在 AI 時代是不是非常適合？

這次讓我實際感受到相當大的手應。

我覺得「這真方便！」，於是分享給公司內部後的結果

好，就這樣。

這個真方便。

也讓大家來用用看吧。

我興致勃勃地把它分享到公司內部了。

結果……。

不能用？ 怎麼回事，是我的設定有問題嗎？

啊……。

是的。

在我的電腦上明明可以動。

不過，

在大家的電腦上，它無法直接運作。

完美符合本地應用程式常見的情況，順利地被塞了進去。

我可以使用。但其他人無法使用。

因為我就是開發者本人，所以當然可以運作。

但如果要讓其他人使用，就需要安裝 Node.js，並準備相依套件。

對習慣開發的人來說，這並不是什麼困難的事。

但對設計師或指導者來說，

請先安裝 Node.js

一開始就要說明的審查應用程式。

……這已經不是一個輕鬆的審查應用程式了。

於是，

「那就做成一鍵啟動就好了！」

我這麼想，於是也做了一個啟動檔案 start-mac.command。

只要連按兩下，

就會啟動終端機、完成必要的準備、啟動應用程式，甚至打開瀏覽器。

很好。完美。

……我本來是這麼想的。

但冷靜想想，

「請連按兩下這個你不認識的 .command 檔案」

這樣的指示，也還是有點令人毛骨悚然。

要跟社長說「總之先雙擊這個！」再傳給他嗎……。 好可疑。 明明是自己做的，卻覺得好可疑。

雖然做出了能運作的東西，但沒能成為公司內部共享的正式版本。

和 AI 一起開發應用程式時，

「在我的環境能跑，別人卻用不了」

這種開發時常見的障礙，也會很自然地遇到。

資深工程師的一句話

就在這時，資深工程師給了一句建議。

寫一份 README， 「讓 Claude Code 讀取資料夾，並依照 README 進行設定」 這樣就好了吧？

……

我原本想把功能做得更便利，還花了不少心思，但對於會使用 AI 的人來說，這種做法其實簡單太多了。

與其什麼都在應用程式端解決，不如

連同使用者與AI在內，思考最省事的做法。

這也讓我學到了一課。

但社長就是不留言給我。

也寫了README。

also 啟動方法也簡化了。

這樣應該可以了。

……我原本是這麼想的。

結果呢。

音訊全無。

社長因為很忙，所以都不理我……。

這時，我又注意到一件更重要的事。

比起做出評論應用程式，

讓人願意使用

困難好幾倍。

不論在本機上把功能做得多便利，

「啟動應用程式」

這第一步仍是必要的。

對忙碌的人來說，連這一步都會成為門檻。

那麼……。

那就做成網頁吧

只要點擊網址就能使用，應該會有人願意用吧？

基於這個想法，我決定製作 Design Marker 的網頁版。

先做登入前的頁面，藉此提升動力。

雖然想要仔細打造很多細節，但需要考慮的事情很多，所以目前先以 AI 製作的 LP 為主。

我思考了後端該如何處理，最後選擇了 Cloudflare。

不過，我本身是設計師。

Cloudflare Pages、Pages Functions、Cloudflare Access、D1、R2……。

雖然聽過這些名稱，但親手規劃架構並組建成 Web 應用程式，這還是第一次。

接下來就輪到 AI 老師登場了。

我想製作供內部使用的管理後台，以及與客戶共享的審閱畫面。

管理後台可以使用 Cloudflare Access 來實現。

留言或專案資訊呢？

可以儲存到 D1

ZIP 呢？

可以利用 R2 的方法。

原來如此。感覺全都懂了！

……其實只是感覺而已。

AI 真的非常厲害。

只要問它，它就能告訴你相當具體的架構。

不過，這次開發時我特別深刻感受到，

AI 能教你做法，和能打造出安全的系統，是兩回事

就是這樣。

從「請教教我」變成「這樣的理解正確嗎？」

尤其是涉及安全性的部分，光靠 AI 的回答來決定實在令人不安。

因此，對於不懂的地方和重要的部分，我決定請資深工程師幫忙審查。

如果是以前的我，

我想用 Cloudflare 做這樣的事情，請問該怎麼做才好？

我想大家應該都是從這樣的提問開始的吧。

但是，這樣一來，前輩也得從頭到尾全部說明一遍。

在對方正忙的時候，

「前輩！請從頭教我！」

就像是直接衝上去一樣。

這次我先和 AI 反覆討論，把內容整理成自己的想法。

接著，

管理畫面透過 Cloudflare Access 限制為僅公司內部成員可存取。 共享畫面則依各專案分別提供 URL、ID 及密碼登入。 專案資訊與留言儲存於 D1，LP 整包的 ZIP 檔則儲存於 R2。 這樣的理解正確嗎？

整理到這個階段後，才開始與他人商量。

也就是說，

「請告訴我」

而不是

「這樣的理解正確嗎？」

，這樣的轉變。

對我來說，這是一個相當大的轉變。

與前輩的往來也因此減少，能讓他們把時間用在真正需要確認的地方。

我自己也不再只是複製 AI 的回答就結束，

「為什麼要這樣做」

則能一邊理解、一邊逐步推進。

改成 Web 版後，又遇到另一道關卡

就這樣，Web 版也逐漸開始運作了。

只要傳送 URL 就能開啟。

比本機應用程式好用得多。

「這樣不就解決了嗎？」

……我本來是這麼想的。

一改成 Web 版，本機版中較少留意的問題便一口氣浮現出來。

舉例來說，

• 是否能將客戶尚未公開的著陸頁託管至雲端？
• 誰可以瀏覽哪個專案？
• 如何保護密碼？
• 如何防止未經授權的登入嘗試？
• 能否安全地顯示已上傳的 HTML？
• 專案結束後，何時刪除資料？

等等。

只要加上一個驗證畫面，並不代表「資安措施已完成！」

這說來理所當然，但親自動手製作之後，才真正體會到其中的分量。

目前已實作 Cloudflare Access、依專案設定的登入機制，以及儲存於 D1 與 R2 的基本架構。

另一方面，

仍有一些需要改善的部分，例如加強密碼保護、限制登入嘗試次數、分離 HTML 預覽，以及資料的儲存與刪除規則，才能正式公開發布。

Design Marker 也提供一種模式，可以不將 ZIP 儲存到雲端，直接在瀏覽器中進行審閱。

只有在雲端共享專案時，才會儲存必要的專案資訊與 ZIP 檔案。

目前的 Design Marker 尚未正式推出服務。

目前主要在公司內部使用，仍處於驗證階段。

也就是說，這次我們做出的是

「完全安全的服務已經完成！」

這樣的說法並不正確。

相反地，

是一款正在逐步實作必要安全對策的應用程式，我們也持續學習必須守護的重點

。

要轉為網頁，並不只是變得更方便而已。

同時也必須承擔保管使用者資料的責任。

這次真的學到很多。

這是已完成的設計製作商管理畫面。

員工可以從儀表板確認所有的紅字修改檢查。

進入詳細頁面後，只要像這樣開啟架構提案的快速連結，就能直接查看 LP，並留下評論。

接著可以像這樣確認標註在 LP 上的評論。此外也能參考過去的評論，讓架構的修正變得更加順暢。

即使有 AI，學習仍然是必要的

透過這次的開發，我還有另一個深刻的感受。

多虧了 AI，即使是設計師，也比以前更容易挑戰開發工作。

我自己，

「我想做出這個」

從構想到實際可運作的成品，能做到的範圍確實擴大了。

但是，那並不是

「已經不需要再學習了」

的意思。

恰恰相反。

我推薦這個結構。

明白了!

光靠這樣很危險。

真正需要的是，

「為什麼？」 「這次也沒問題嗎？」 「有沒有漏掉什麼？」 「這個部分請專家確認過會比較好吧？」

這是我們的結論。

要判斷 AI 的提案是否符合這次的條件，以及缺少了什麼，仍然需要相關的知識。

AI 確實是值得信賴的夥伴。

但最後做出判斷並負起責任的，仍然是人。

這次將 Design Marker 轉為網頁版的過程，也讓我們重新思考了與 AI 相處的方式。

或許在 AI 時代，最大的改變會發生在審查（Review）這件事上。

AI 只需幾分鐘就能做出 LP。

過去需要花上好幾個小時的初稿，現在能以令人驚訝的速度完成。

但之後要進行的，

「這裡這樣改」 「把這邊的留白稍微加大」 「只換這張圖片」

這樣的來回溝通，其實從以前到現在都沒有太大改變。

只有製作的速度變快了，

仍需人工確認、傳達修改內容，然後重新製作。

這個部分仍然相當依賴人工判斷。

因此最近我開始思考，

不只是AI本身，

AI與人之間的互動方式

也會變得越來越重要，我是這樣認為的。

Design Marker 就是其中一項實驗。

目前會同時將

我們正在嘗試的功能包括：在 HTML 上留言、附加圖片、整合多位審閱者的意見，以及依專案進行版本管理等。

未來還有許多想做的事。

直接在截圖上標註修改。

根據留言向 AI 提出修改要求。

改善版本之間的比較功能。

提升多人審閱時的易用性。

當然，也會持續強化安全性，包括驗證機制、HTML 預覽及資料管理等。

首先，我們會先在公司內部實際使用，並逐步改善。

首先，

「Slack 的留言一直滾動，想想辦法解決」

原本只是抱著隨手做做看的心態，開始製作的小工具。

沒想到回過神來，

先做了本地端應用程式，

但社長沒有實際使用，

於是改為網頁版，

研究 Cloudflare，

在資安問題上煩惱，

向工程師前輩請教，

最後連與 AI 的相處之道都開始思考了。

……original plan was just to build a review app, but there turned out to be a lot to think about.

Still, I think it's an interesting change that we can now turn the small inconveniences in our daily work into real tools together with AI.

Once it has grown to the point where it can be released to the public with confidence, I'd like to formally introduce Design Marker again.

Before that.

First, I'll do my best to get the president to write a proper comment (lol). For now, though, I think I'm going to enjoy some good sake today.