本系列將記錄我如何運用 AI 協助開發,從一個尚未完全成形的想法出發,逐步探索並製作 Web App 原型。30 天內,我會嘗試進行需求整理、使用情境分析、介面設計、功能規劃與原型測試,並依實際進度、遇到的問題及學習成果,持續調整作品方向與範圍。過程中也會記錄我如何與 AI 溝通、修改提示、判斷生成結果,以及面對錯誤與限制時所做的調整。最終成果不預設為完整產品,而是呈現從模糊想法、反覆嘗試到階段性原型的真實 AI 協作開發歷程。
昨天,CareCall AI 的五個核心區域開始共用同一份資料。今天我終於加入第一組真正會「判讀回答」的文字規則,但範圍刻意很小:只處理正常回答與否定句。 一開...
昨天,我為 CareCall AI 加入第一組正常回答與否定句規則。「沒有不舒服」不會再因為含有「不舒服」而被誤判。今天要處理另一種同樣重要的問題:如果沒有取得...
昨天,我讓 CareCall AI 能夠分辨全部空白、部分缺漏、不確定與無法回答。當四題都沒有取得答案時,系統不會再假裝關懷已完成,而是標示為「待提醒」。但只有...
前幾天,我讓 CareCall AI 能夠處理正常回答、否定句、缺漏、不確定與持續未回應。今天要解決的問題更容易被誤解:當回答中出現不舒服或協助需求時,系統到底...
前幾天的 CareCall AI 已經可以整理固定關懷問題,區分正常回答、缺漏、未回應、不確定與明確求助,也能產生已完成、待提醒、待人工確認和優先處理四種工作狀...
使用 AI 協作寫程式時,功能通常增加得很快。前一天完成否定句,隔天加入空白處理,再往後加入未回應、狀態分流與人工接手。每一次修改看起來都合理,但真正令人擔心的...
前幾天的 CareCall AI 已經能把四題回答整理成工作流程狀態,也能讓照護人員查看原因、補上人工紀錄並完成待辦。不過,畫面在正常情況下可以操作,不等於原型...
做原型時,很容易把「又多了一個功能」當成進度,但功能越多,不一定代表作品越可靠。對我來說,真正不會歸零的 MVP,不是畫面最多、技術最新的版本,而是能明確說出它...
昨天,我替 CareCall AI 封存了第一個不會歸零的文字/規則版 MVP。今天準備往語音功能前進,但我沒有立刻開始寫麥克風程式,而是先回答一個更根本的問題...
昨天我先把語音流程畫清楚,今天才真正開始寫瀏覽器語音轉文字。這個順序很重要,因為 CareCall AI 的目標不是展示一個會動的麥克風按鈕,而是讓一句口語回答...