Vibe Doctor：跟聊天機器人一起，把論文初評變成一個會跑的網頁
它出嘴、你出手——這趟用聊天機器人把論文初評做成網頁的全程實錄，包含真實的 bug 與除錯，最後帶出「該換 Agent 的時機」。
上一篇，我們讓 AI 訪談你、把一位醫師心裡的評讀標準長成一段「論文初評提示詞」，再停進一個常駐工具裡。那是「引擎」。但你大概也發現一件事：每次要用，還是得手動打開對話、手動貼上論文、看完關掉——做過的初評，沒有留下來。
這篇要替那個引擎裝上車身：做一個會跑、能存、還能回看的網頁。醫師貼上一篇論文、按一個按鈕，就用那段固定提示詞跑一次初評、把結果存進 Google 試算表，之後隨時回頭查。
先說在前頭：我自己是醫師、不是工程師，這趟從頭到尾，沒寫過一行我真正看得懂的後端程式。能把這個網頁做出來，靠的就是一件事——把需求講清楚，剩下交給 AI。所以如果你也是臨床出身、平常一看到程式碼就想關掉視窗，這篇正是寫給你的。
而且這篇要老實示範的，是一種工作流：完全用聊天機器人（這次是 Gemini）幫你把程式寫出來、一步步部署——包含中途真的撞到的 bug、怎麼靠聊天機器人除錯、以及一個會讓很多人卡住的快取陷阱。下一篇我們會換成「Agent 工作流」做同一件事，兩種各有適合的場合。
⚠️ 本篇一律用合成（虛構）論文示範。 文中那個網頁工具是教學原型，不可輸入病人可識別資料、也不可作為臨床決策依據。AI 整理、醫師定案。
一、先看成品：一個「論文初評紀錄」網頁
我們要做的東西長這樣——一個單頁網頁：最上面是醒目的安全警示與「我沒有輸入病人資料」的勾選框，中間貼論文、按一個「產生論文初評」，下面跑出結構化初評；還有一個「歷史紀錄」頁籤，把你做過的每一篇收起來、可以展開回看。
四個功能，到此為止（再多會稀釋重點）：①貼論文 ②一鍵跑初評 ③存進 Google 試算表 ④歷史紀錄頁。接下來，我們從零把它生出來。
二、把「需求」寫清楚，丟給聊天機器人
這一步是整個工作流的關鍵：你不必自己會寫 Google Apps Script，但你要把「要做什麼」講清楚。
而且——等一下你會看到這份規格書裡有 doGet、UrlFetchApp、Script Properties 這些技術字眼。身為醫師、又是程式新手的你，可能會想：「我又不是工程師，連 Google Apps Script 是什麼都不知道，這份規格書我哪寫得出來？」
別擔心——這整份規格書，本身就是 AI 幫你寫的。 延續上一篇學到的同一招：讓 AI 教你用 AI。 你不必懂後端怎麼接 API、不必會寫「系統規格書」；你只要把「想做一個怎樣的工具」用白話講清楚，請 AI 幫你整理成一份有條理的系統規格書就好。你出「要什麼」，AI 出「把技術細節寫清楚」。
下面這份規格書，就是這樣聊出來的（你可以直接拿去改成你自己的）：
裡面那段「固定初評提示詞」，就是上一篇讓 AI 訪談醫師生出來的那份評讀標準——原封不動放進來，當這個工具的大腦。而其餘的技術細節（怎麼接 Gemini、怎麼把結果存進試算表、怎麼防止金鑰外洩、怎麼做出歷史頁）也全是 AI 補上的，你只要點頭確認方向就好。
這就是 Vibe Coder 的精神：你負責把想法說清楚，技術細節交給 AI。 對我們醫師來說更是如此——你最懂的是臨床、是這篇論文該怎麼讀；把那份判斷講清楚，寫程式的事就交給它。
接著產程式碼，記得把模型切到進階的那一檔（這裡用 Gemini 3.1 Pro，它的定位就是「進階數學與程式設計」）。
把整份需求規格貼上、送出：
Gemini 開始產出。它先說明會做成單頁應用程式、嚴格做到「不在試算表存原始論文與病人資料」，然後給你兩個檔的完整程式碼：
Code.gs（後端）：最上面把模型名稱、提示詞版本抽成常數，並把上一篇那段初評提示詞原封不動放進來當固定指令。
Index.html（前端）：版面用 Google 藍（#1a73e8），有安全警示、表單、結果區、歷史頁籤。
最後它附上部署三步：設定金鑰 → 部署成網頁 → 首次授權。
到這裡，聊天機器人已經把「藍圖」給你了。但藍圖跟「真的蓋起來」之間，藏著幾個只有動手做過才知道的坑。
三、把程式碼變成一個真的會跑的網頁
聊天機器人給的程式碼，要真的變成一個會跑的網頁，中間有 6 步。先看這張全局地圖，再回頭逐一對照下面的細節截圖——你會比較不容易迷路：
先別急著貼程式——你得先有一個 Apps Script 專案
Gemini 直接叫你「把程式貼進 Code.gs」，但如果你沒做過，第一個問題會是：Code.gs 在哪？怎麼生出來？這一步它沒講，我們補上。
Google Apps Script 不用另外安裝，它就藏在你的 Google 雲端硬碟裡。打開雲端硬碟、進到（或新開）一個放這專案的資料夾，左上角點 「新增」→「更多」→「Google Apps Script」。
它會開出一個全新的 Apps Script 編輯器，裡面預設已經有一個空的 Code.gs。把 Gemini 給的後端程式整段貼進去（覆蓋空殼）：
新增前端檔（Index.html）——這步最容易錯
HTML 檔不是在雲端硬碟另開，而是在這個編輯器裡面新增。左側「檔案」那排、Code.gs 上方有個 「+」→ 選「HTML」：
命名時，只打 Index（不用打 .html，系統會自動加）。然後把前端程式整段貼上。
但這裡有一個會讓你卡到懷疑人生的雷——大小寫。我一開始把它命名成小寫的 index：
程式裡寫的是 createHtmlOutputFromFile('Index')（大寫 I）。檔名對不上，網頁就會打不開、報錯。改成大寫 Index 才行：
Vibe Coder 小常識：聊天機器人叫你「把 HTML 貼進 Index.html」，聽起來簡單，但它假設你已經知道「這個檔要在編輯器裡用 +→HTML 新增」「名字要和程式裡呼叫的字串大小寫完全一致」。這種「只有真的做過才知道」的細節，正是它最容易略過的地方。
設定 API 金鑰（放對地方，別被人偷看）
程式要靠 Gemini API 跑初評，得先給它一把金鑰。金鑰絕對不能寫在前端程式裡——要放在 Apps Script 的「指令碼屬性（Script Properties）」，這是伺服器端、安全的地方。到 ⚙ 專案設定找到它：
新增一個屬性 GEMINI_API_KEY，值貼上你在 Google AI Studio 申請的金鑰。（下圖把值換成了提醒語——順便說一句：貼金鑰時，小心後面沒有人在偷看。）
部署成網頁、首次授權
接著照部署流程走：選「網頁應用程式」、填描述、執行身分選「我」。存取權這裡我示範時選了「所有人」方便直接展示——但你自己測試時，建議先選「只有我自己」比較安全，確定沒問題再考慮開放。然後部署、授權。
部署成功，拿到一個 .../exec 結尾的網頁網址——到這裡，所有設定都完成、工具正式上線了：
四、跑第一次：它真的把論文初評做出來了
打開網頁，貼上那篇合成腎臟科論文、勾選「我確認未輸入病人可識別資料」、按下「產生論文初評」。畫面會一步步告訴你它在做什麼（組裝提示詞 → 呼叫模型 → 整理輸出 → 寫入試算表），而不是只給你一顆轉圈圈。
幾十秒後，初評出來了——開頭先聲明這是合成稿、不可當臨床證據，接著判定研究類型、拆 PICO、分層終點：
往下，是整體評等：它正確指出主要終點「血壓達標」是過程性替代指標、非硬終點，標出開放標籤/未盲會讓效果偏向高估，把腎臟結果壓在探索性，最後給可信度等級與一句話結論。
同一時間，它把這次執行的紀錄寫進了 Google 試算表（標題、時間、狀態、初評全文都在，但刻意不存原始論文全文）：
停一下，看看剛剛發生的事：你——一個整天在看病人、不是在寫程式的醫師——剛剛親手部署出一個真的會跑、會評讀、會把結果存下來、之後還能回看的網頁。 沒有工程師、沒有 IT 部門，就靠一段需求和一台瀏覽器。一個按鈕，把上一篇那段提示詞變成了可重複、會留痕的工作流——到這裡，工具的主體，真的跑起來了。
五、撞到一個真實的 bug：歷史紀錄卡住了
但「歷史紀錄」頁籤一點下去，畫面就永遠卡在「載入中…」，既不出現紀錄、也不報錯。
這是寫程式的日常：一口氣產出的程式，總會有個地方不對。重點是怎麼修——而這正是「聊天機器人工作流」要面對的事。
其實這個「卡住」藏了兩層坑。先看這張地圖，下面那一連串除錯截圖，就是逐層把它拆開、修好的過程：
第一個常識：聊天機器人看不到你的瀏覽器，你得自己開檢查面板
畫面卡住、又沒有錯誤訊息，怎麼查？答案是打開瀏覽器的開發者工具（按 F12）、切到 Console（主控台），看底層到底在抱怨什麼。截寬一點，讓你看清楚這個面板是從哪裡冒出來的：
放大看訊息本身——有兩個紅色的 Uncaught rt 錯誤，夾在一堆網路狀態訊息之間：
這就是重點之一：聊天機器人沒辦法看到你這個畫面。它不知道你的網頁卡在哪、console 噴了什麼。所以下一步，得由你把這個錯誤帶回去給它。你是它的眼睛。
把錯誤貼回去問——它就抓到了
我把症狀（歷史紀錄卡載入中、沒有錯誤）回報給 Gemini。它從症狀就猜中了根因，講得很清楚：
原因是：Google 試算表會把寫入的時間字串自動轉成 Date 物件；當後端把含有 Date 的資料回傳給前端時，google.script.run 會在背後靜默失敗、連錯誤處理都不觸發，前端就一直痴痴地等。
它的修法也直接給了——把 getHistory() 回傳的所有資料強制轉成字串；而且它還主動提醒：改完程式記得「重新部署新版本」，否則網頁會繼續跑舊版。
老實說，Gemini 這題表現很好：症狀一給就中、修法正確、連最容易漏的「要重部署」都幫你補上。聊天機器人真的能幫你寫程式、也能幫你除錯。
一個會騙過很多人的陷阱：瀏覽器快取
但故事還沒完。我照它的修法改好程式、重新部署一個新版本（注意：要「管理部署作業 → 編輯現有的 → 版本選『新版本』」，不是新增另一個部署）：
回到網頁一看——竟然還是卡在「載入中…」。修法明明是對的，怎麼會這樣？
於是我把「重部署後還是卡」也丟回去問 Gemini——它給了開發者最常用的「三招」：
第一招：用「測試部署作業」的 /dev 網址來測，而且它特別提到「有時候瀏覽器會快取（Cache）舊版本」：
第二招：換一個更防呆的 getHistory()（跳過空白列、加上預設值）：
第三招：自己按 F12、點歷史紀錄，看有沒有紅色錯誤——然後把結果告訴它：
我照第一招做：用那個 /dev 測試網址打開、點歷史紀錄——這次立刻就出來了。
原來真因就藏在第一招裡：是瀏覽器快取。 我的修法其實一開始就成功了，只是正常瀏覽器一直在跑快取住的舊版本；而 /dev 測試網址跑的是編輯器裡最新的程式、繞過了快取，所以一試就通。
而第三招那句「你有看到任何紅色的錯誤訊息嗎？」，本身就是另一個重點：聊天機器人看不到你的畫面，它只能請你去當它的眼睛和手、再把看到的回報給它。
Vibe Coder 經典坑：改完程式、重新部署後，網頁卻沒變——很可能是瀏覽器在跑快取的舊版。解法是強制重新整理（Ctrl+Shift+R）、開無痕視窗、或用
/dev測試網址。這個坑很常見，而且聊天機器人看不到你的瀏覽器，沒辦法替你發現。
📄 這一切都是真的。 從產出程式碼、到兩輪除錯，整段跟 Gemini 的原始對話都在這裡，你可以自己點開看：完整 Gemini 對話紀錄。
六、回頭看：這趟我們學到什麼
把整趟走完，有幾件事很清楚：
- 聊天機器人真的能幫你寫程式。 你把需求講清楚，它就能產出一個會跑的網頁工具——你不必先變成工程師。
- 逐步來、邊做邊驗證是對的。 一步部署、一步測試，問題才好定位。
- 它一口氣產的程式會藏小 bug（像這次的歷史紀錄）。這種坑不是因為「對話太長」，而是程式本來就會有；只是程式越大、要顧的越多，這種坑越容易冒出來、來回除錯也越累。
- 出錯別怕，把錯誤畫面貼回去就好。
- 簡單的程式：常常貼一個錯誤訊息，它就找到問題。
- 複雜的程式：可能要來回貼個幾次，但通常最後也能解決。
但在這個過程裡，你一定會慢慢感覺到一件事——每一次，都是你在跑腿：你開 F12、你複製錯誤、你貼回去、你換函式（還得小心別把大括號弄壞）、你重新部署、你試了 /dev 網址才發現原來是快取。聊天機器人很能幹，但它看不到、也碰不到你的東西。而我們醫師的時間，本來就被門診、查房、值班切得很碎——這種一來一回的「跑腿稅」，你我大概都特別有感。
於是心裡會浮出一個問題：
到底是人類在當聊天機器人的助理，還是聊天機器人在當人類的助理？
七、兩種工作流，各有各的場合
先講清楚：這不是「聊天機器人比較弱、Agent 比較強」的對決。它們是兩種不同的工作流：
- 工作流一（聊天機器人）：像這篇做的——它出嘴、你出手。對小型專案很合適：一兩個檔、改個幾次，你照著貼、照著部署，很快就成。
- 工作流二（Agent，下一篇）：把「看狀態、動手改、重新部署、再驗證」整圈交給 Agent。對大型專案更有利——效率更高、你不必一直跑腿；代價是一開始的設置（環境、文件）比較費工。
換句話說：專案越小，聊天機器人越划算；專案越大、改越多次，那個「跑腿稅」就越重，這時把整件事交給 Agent 才會回本。
下一篇，我們就把同一份需求交給一個 Agent，看它怎麼直接動手把網頁建好、自己把這次的 bug 修掉、自己確認結果——整個過程會很不一樣。
責任邊界
- 本文的網頁是教學原型，首頁就清楚標示：請勿輸入病人可識別資料、結果不可作為臨床決策依據。
- 示範一律用合成（虛構）論文；真實論文也一樣，AI 的初評必經醫師人工核對。
- API 金鑰只放在伺服器端的指令碼屬性，絕不寫進前端、不外洩。
- AI 整理、醫師定案——工具只是把流程接起來，醫學判斷的最後一筆，仍由醫師落。
