iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Vibe Coding

從模糊想法到可操作原型:我的 30 天 AI 協作開發實驗 系列

本系列將記錄我如何運用 AI 協助開發,從一個尚未完全成形的想法出發,逐步探索並製作 Web App 原型。30 天內,我會嘗試進行需求整理、使用情境分析、介面設計、功能規劃與原型測試,並依實際進度、遇到的問題及學習成果,持續調整作品方向與範圍。過程中也會記錄我如何與 AI 溝通、修改提示、判斷生成結果,以及面對錯誤與限制時所做的調整。最終成果不預設為完整產品,而是呈現從模糊想法、反覆嘗試到階段性原型的真實 AI 協作開發歷程。

參賽天數 20 天 | 共 20 篇文章 | 2 人訂閱 訂閱系列文 RSS系列文 團隊五人成行,Bug 不行
DAY 11

Day 11|關鍵字看見「不舒服」,不代表使用者真的表示不舒服

昨天,CareCall AI 的五個核心區域開始共用同一份資料。今天我終於加入第一組真正會「判讀回答」的文字規則,但範圍刻意很小:只處理正常回答與否定句。 一開...

2026-08-12 ‧ 由 rachelcltang 分享
DAY 12

Day 12|沒有取得答案時,系統最不該做的就是假裝已經完成

昨天,我為 CareCall AI 加入第一組正常回答與否定句規則。「沒有不舒服」不會再因為含有「不舒服」而被誤判。今天要處理另一種同樣重要的問題:如果沒有取得...

2026-08-13 ‧ 由 rachelcltang 分享
DAY 13

Day 13|未回應不代表危險,也不能直接當成安全

昨天,我讓 CareCall AI 能夠分辨全部空白、部分缺漏、不確定與無法回答。當四題都沒有取得答案時,系統不會再假裝關懷已完成,而是標示為「待提醒」。但只有...

2026-08-14 ‧ 由 rachelcltang 分享
DAY 14

Day 14|工作流程優先度,為什麼不能等同醫療嚴重程度?

前幾天,我讓 CareCall AI 能夠處理正常回答、否定句、缺漏、不確定與持續未回應。今天要解決的問題更容易被誤解:當回答中出現不舒服或協助需求時,系統到底...

2026-08-15 ‧ 由 rachelcltang 分享
DAY 15

Day 15|AI 整理資訊之後,如何真正交到照護人員手上?

前幾天的 CareCall AI 已經可以整理固定關懷問題,區分正常回答、缺漏、未回應、不確定與明確求助,也能產生已完成、待提醒、待人工確認和優先處理四種工作狀...

2026-08-16 ‧ 由 rachelcltang 分享
DAY 16

Day 16|讓 AI 協作寫程式時,有一套不會越改越壞的安全網

使用 AI 協作寫程式時,功能通常增加得很快。前一天完成否定句,隔天加入空白處理,再往後加入未回應、狀態分流與人工接手。每一次修改看起來都合理,但真正令人擔心的...

2026-08-17 ‧ 由 rachelcltang 分享
DAY 17

Day 17|真正可靠的原型,不只是在一切順利時能操作

前幾天的 CareCall AI 已經能把四題回答整理成工作流程狀態,也能讓照護人員查看原因、補上人工紀錄並完成待辦。不過,畫面在正常情況下可以操作,不等於原型...

2026-08-18 ‧ 由 rachelcltang 分享
DAY 18

Day 18|做到哪裡才算真正擁有一個不會歸零的 MVP?

做原型時,很容易把「又多了一個功能」當成進度,但功能越多,不一定代表作品越可靠。對我來說,真正不會歸零的 MVP,不是畫面最多、技術最新的版本,而是能明確說出它...

2026-08-19 ‧ 由 rachelcltang 分享
DAY 19

Day 19|語音功能最重要的不是辨識成功,而是失敗時仍能繼續

昨天,我替 CareCall AI 封存了第一個不會歸零的文字/規則版 MVP。今天準備往語音功能前進,但我沒有立刻開始寫麥克風程式,而是先回答一個更根本的問題...

2026-08-20 ‧ 由 rachelcltang 分享
DAY 20

Day 20|第一次把聲音變成「可以確認」的關懷內容

昨天我先把語音流程畫清楚,今天才真正開始寫瀏覽器語音轉文字。這個順序很重要,因為 CareCall AI 的目標不是展示一個會動的麥克風按鈕,而是讓一句口語回答...

2026-08-21 ‧ 由 rachelcltang 分享