社長的評論在Slack上流傳，用AI製作評論Web應用後，卻面臨另一堵牆的故事

〜設計師與AI一起用Cloudflare製作具備認證的Web應用程式的嘗試〜

大家好。我是UI設計師hasshi。

最近，不再是製作線框圖後請客戶確認的流程，而是改用AI製作LP和網站的模型稿進行確認，這種情況變得相當頻繁。

過去在確認設計時是透過Slack，

「請把這裡的空白擴大！」 「請用這張圖片替換！」 「請改變這裡的文字！」

這樣的評論。

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

實際上，到目前為止這個方法都沒有造成重大問題。

不過，自從開始用AI大量製作原型後，某個問題變得格外突出。

評論持續流入。

Slack 很方便。

雖然方便，但當然不是專用的設計審查工具。

日常工作溝通、閒聊、其他專案諮詢，全都流入同一個地方。

結果是，

• 修改意見流向了其他對話
• 對話串四處蔓延
• 「那個修改在哪裡來著？」
• 不知不覺已經變成了另一個話題

這些事都會發生。

Slack 也有清單功能。

之前我也寫過關於使用 Slack 範本進行業務改善的文章。

使用 Slack 範本開始輕鬆 DX | 主題 | Liberogic

不過，執行緒的通知容易令人困惑，而且當整合通知時，訊息欄就會變得混亂……。

最後，

聊天欄變得越來越熱鬧。

雖然用 AI 製作登陸頁面的速度加快了好幾倍，但審查方法仍然停留在過去。

只有生成部分加快速度，但如果卡在之後的審查流程上，就有點浪費了。

因此我想到了。

那何不直接在 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 來說，「左上角」在哪裡、「圖片」是哪個元素，就變得模糊不清。

在 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， 「用 CloudCode 載入資料夾，按照 README 進行設定就行」 不就可以了嗎？

……

我一直在應用程式端想要實現各種便利功能，但如果是給會用 AI 的人用，那樣反而簡潔得多。

與其想著在應用程式端解決所有問題，

包括使用者和 AI，考慮最輕鬆的方法。

這也讓我學到了一些東西。

但是董事長沒有寫評論。

也建立了 README。

簡化了啟動方法。

這樣應該沒問題。

……我是這麼想的。

不過。

沒有任何音訊。

董事長很忙，顧不上我……。

在這裡，我發現了更重要的一點。

與其開發審查應用程式，

讓人們使用它

難得多倍。

即使在本機上再怎麼方便，

「啟動應用程式」

這最初的一步是必要的。

對於忙碌的人來說，連這一步都可能成為障礙。

那麼呢……。

既然這樣，就用Web吧。

只要按一下網址，應該就能讓使用者使用吧？

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

先製作登入前的頁面來提升動力。

想製作很多功能，但需要考慮的事情太多了，所以目前先用 AI 製作的登陸頁面。

我思考了後端該如何實現。最後選擇的是 Cloudflare。

話說回來，我是設計師。

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

雖然聽過名字，但自己去構思架構並組合成網頁應用程式還是第一次。

接下來就是 AI 老師的出場時刻了。

我想製作內部用的管理畫面，以及分享給客戶的審核畫面

管理畫面可以使用 Cloudflare Access 的方法。

評論和專案資訊呢？

可以儲存到 D1

ZIP 檔案呢？

有使用 R2 的方法

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

……只是感覺懂了。

AI 真的非常優秀。

只要提問，它就會告訴你相當具體的結構。

但在這次開發中，我強烈感受到的是，

AI 教會你方法和建立安全系統是兩回事

是這樣的情況。

從「請告訴我」轉變為「這樣的理解是對的嗎？」

特別是涉及安全的部分，只憑 AI 的回答來決定實在太令人不安了。

因此，我們決定針對不明白的部分和重要的部分請工程師前輩幫忙審查。

如果是以前的我的話，

我想在 Cloudflare 上實現這樣的功能，要怎麼做才好呢？

應該是會這樣詢問。

但那樣的話，前輩就必須從頭開始逐一詳細解釋。

在前輩忙碌的時候，

「前輩！請從頭開始教我！」

就像在強行衝撞一樣。

這次，我首先與 AI 多次往返互動，並按照自己的方式進行了整理。

然後，

管理畫面用 Cloudflare Access 限制為公司內部成員只讀。 共享畫面使用專案各自的 URL 以及 ID・密碼登入。 專案資訊和評論儲存在 D1，LP 一式的 ZIP 檔儲存在 R2。 我的認識沒有問題吧？

進行到那個階段之後才去進行諮詢。

也就是說，

「請教我」

而不是，

「我的認識沒有問題吧？」

變成了這樣。

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

與前輩的往來減少了許多，他們可以將時間用在真正需要確認的地方。

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

「為什麼要這樣做」

能夠逐漸理解這一點，邊思考邊推進工作。

改成 Web 版後，又遇到了新的問題

就這樣，Web 版逐漸能夠運作了。

只要傳送 URL 就能打開。

比本地應用程式容易使用得多。

「這樣應該能解決吧？」

……或者我是這樣認為的。

改成 Web 版的那一刻，本地版本中沒有特別注意到的問題一下子都浮現出來了。

舉例來說，

• 是否應該將客戶的上線前 LP 委托給雲端保存
• 誰可以查閱哪些專案
• 如何保護密碼
• 如何防止非法登入嘗試
• 上傳的 HTML 能否安全地顯示
• 專案結束後什麼時候刪除資料

等等。

只要加上一個驗證畫面就「安全對應完成！」並不是這樣的。

理所當然地說，只有在自己實際試著做了之後，才真正體會到這份責任的沉重。

目前我們實裝了 Cloudflare Access、按專案設置登入、儲存到 D1・R2 等基本機制。

另一方面，

密碼保護強化、登入嘗試次數限制、HTML 預覽隔離、資料保存與刪除規則等，正式公開前還有許多需要改進的部分。

Design Marker 提供一種模式，可以在瀏覽器內進行檢閱，而不需要將 ZIP 檔案保存到雲端。

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

Design Marker 目前還不是正式服務。

我們目前主要以內部使用為中心進行驗證。

換句話說，這次開發的是，

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

這樣的說法。

反而是，

認識到必須守護的項目，並逐步實裝必要對策的應用程式

。

將某個事物轉換為網路形式，不僅是為了便利性。

接手使用者的資料，也隨之產生了責任。

這次真的讓我學到了不少東西。

完成後的設計製作工具管理畫面。

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

進入詳細頁面後，可以透過構成案的快速連結打開登陸頁面進行直接查看，或者添加評論。

這樣一來，我們可以確認登陸頁面上記錄的評論。同時也能參照之前的評論，使得構成的修改變得更加順暢。

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

透過這次開發，我強烈感受到了另一件事。

得益於 AI，即使是設計師也比以前更容易挑戰開發工作。

我自己，

「想要建立這個」

到實際運行的東西之間的範圍，顯然擴大了。

但是，那並不是，

「不需要再學習了」

的意思。

反而相反。

推薦這個配置

明白了！

單獨是危險的。

真正需要的是，

「為什麼？」 「這次這樣也可以嗎？」 「有沒有遺漏的地方？」 「這部分要不要讓專家確認一下？」

這樣被認為是。

需要具備能夠判斷 AI 的提案是否符合本次條件、缺少了什麼的知識。

AI 確實是真正可靠的夥伴。

但是，最後做出判斷並承擔責任的還是人類。

這次 Design Marker 的網頁化，也成為重新思考與 AI 相處方式的契機。

AI 時代改變最多的，或許是審查流程

AI 能在數分鐘內為我們製作登陸頁面。

以前需要花上好幾小時才能做出的初稿，現在速度快得令人驚訝。

但之後要進行的是，

「把這邊改成這樣」 「把這個空白稍微擴大一點」 「只改這張圖片」

這樣的往來交流，其實從很久以前就沒有改變。

製作速度雖然加快了，

由人確認、傳達修正內容、再重新製作。

這部分仍然相當具有人為色彩。

所以最近，

不只是 AI 本身，

AI 與人如何進行互動

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

Design Marker 是其中一個實驗。

目前我將

我們正在試驗 HTML 註解、圖片附加、多人審查整合、以及按專案進行的版本管理等功能。

我們未來還有許多想要實現的功能。

直接在螢幕截圖上進行標記。

透過評論向 AI 要求修正。

改善版本之間的比較。

提升多人審查的易用性。

當然還有驗證、HTML 預覽、資料管理等安全性提升。

我們計畫先在公司內部實際使用，然後逐一改善。

起初，

「Slack 上的留言流動太快，希望能有所改善」

抱著這樣的想法開始製作的一個小工具。

沒想到後來，

製作了本機應用程式、

公司主管卻用不慣、

轉為網頁版、

深入研究 Cloudflare、

為安全性問題而煩惱、

向資深工程師尋求建議、

甚至開始思考與 AI 的相處之道。

……其實我只是想做一個審查應用程式而已。沒想到要考慮的東西還挺多的。

不過，能夠把自己業務中的小不便之處和 AI 一起形象化，我覺得這是個有趣的改變。

等到能安心公開的時候，我想再正式介紹 Design Marker。

在那之前。

首先，我得先好好讓社長寫出評論（笑）。 不過總之今天應該能喝到好酒了