Agent 能動手之後:替產品建立安全與授權邊界
Agent 不只產生文字,還可能查資料或改動產品狀態。搭配產品實作情境與現行 SDK,拆開輸入、工具授權與輸出檢查的責任。
主題索引
資安、風險與安全性議題
Agent 不只產生文字,還可能查資料或改動產品狀態。搭配產品實作情境與現行 SDK,拆開輸入、工具授權與輸出檢查的責任。
保留 2025 年對美國出口管制、企業供應與中國硬體替代的分析,補上 2026 年 H200、MI325X 有條件逐案審查的政策後續,區分提案、現行規則與境外算力交易的限制。
以下整理 2025 年 10 月間 OpenAI 的核心爭議:改制與融資綁定、反壟斷與監管壓力、內容政策(成人情色)、安全與法律風險,以及「過度互聯、可能太大而不能倒」的系統性風險討論。
cosGlint 1.2.4 上線:Findskin 核心演算法重新設計、膚質細分至 10 種,搭配全新相機介面與「計算權重」報告,讓拍照更順、結果更準。Ingrelens 提供 AI 成分解讀、膚況檢測與個人化保養建議,協助判斷產品是否合適。
cosGlint 的回饋介面:點一下分數,30 秒後自動送出,想補充的人也能寫文字或撤回。這篇記錄我如何用倒數、動畫和 A/B 測試,讓兩種需求放在同一個流程裡。
面試作業也可能是攻擊入口:一次 Node/React 測試儲存庫的伺服器端惡意載入與防護重點
回看 2025 年 OpenAI 宣布放寬成年人內容的計畫,區分原始訊息、產品判斷與實際可用範圍;補上個人化指示和內容權限應分開管理的做法。
把高溫、濕度、風速、UV 指數轉成可執行的日常保養:從保養品分析到成分分析,cosGlint 以可被解釋的訊號給出白天防曬、夜間修護、隔日預防的具體指引。
回顧 cosGlint 第 209 天的成分分析與產品規劃,補上 Day 234、1.2.4 膚質演算法及相機介面的後續更新。
保留 API key 外洩事件,更新 Gemini 預付計費與 OpenAI 支出上限,說明後端代理、配額、限流和停機責任。
保留 cosGlint 2025 Android 封測心得與填答,補上個人帳號適用範圍、12 人連續 opt-in 14 天及公開資料規則。
回看 2025 年 GPT-5 上線與 GPT-4o 回歸爭議,討論選擇權、互動偏好與產品語氣設計;補上 2026 年自訂指示和事實邊界的做法。
這週從 SEO、Dockerfile/Supervisor、狀態管理、Tiptap + AI 到 環境變數,每天都有新坑。與其把它們當救火,我選擇把舊債系統性轉成投資,讓產品的基礎更穩。 * SEO不是小事。重新設計 JSON‑LD 和 metadata,短期流量未必動,但可
保留 Google 解除綁定的開發經過,補上站內 session、OAuth scope、access/refresh token 與登入同意撤銷的差異。
今天把幾件拖很久的事一次處理掉,專案也順了不少。 先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔,結果測試掛了:有個測試竟然跟 sitemap 的產生邏輯耦合在一起。把測試拆乾淨、舊案例順手整理後,CI 回到綠燈。像清掉房間的舊雜物,空出腦袋。 真正影響
本來計畫把時間放在核心功能的優化,結果一打開產品分析服務的介面,先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異,卻會讓品牌商覺得產品不夠專業,也影響他們的信任。想到我們的客群特別在乎質感,我還是把今天的重心從新功能挪開,展開一場用語清掃。 原本只想改幾
AI 分類越做越複雜,是在挖坑還是填坑? 這幾天把重心放在兩件事:產品分類的 AI 自動化,以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下,結果一路從資料結構、路由、紀錄,到架構設計全被牽出來重整。 先談分類。 起手式很直接:把產品名稱與描述丟給模型,取
今天的開發原本很單純:做一個訪客帳號。實作後卻發現,難的是讓它用起來一致、可信。這一整天的折返,讓我更確定:產品的差異,往往來自那些使用者不會主動說出口、卻一直感受到的細節。 一、身分與名稱要一致。一開始我以為 localStorage 放個暱稱就好。等到遇到「訪客是否能轉成正
API 重構後的幾點實話:技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來:API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構,還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險,過去半年累積
成分搜尋與 API 整合的兩天修補:從資料庫到前端的連鎖反應 這兩天主要在處理兩件事:把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理,全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD,前端要找成分時不是
延續昨天的 AI 整合反思,我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節,整個渲染邏輯就像多米諾骨牌一樣一路倒下:從前端元件、狀態流到資料處理方式,都得重新整理。雖然頭疼,但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊,原本擔心資訊太細,使用
昨天把產品管理的 CRUD 骨架穩住後,今天直接把精力放在條碼掃描的擴展。理由很簡單:如果輸入資料不可靠,後面的分析再巧都只是表面工夫。 先整理了幾個後端細節,把多餘的 SQL 彈性收斂,移除那些看似靈活、實則增加風險的參數,順手解了一些依賴問題。結論很直白:簡化後更安全,查詢
條碼掃描初步跑起來了,但影像前處理比預期花時間。這週的反省是先讓功能上線,再根據使用資料調整;下週優先處理弱光環境下掃描太慢的問題。
讓掃描更可靠,也把產品管理功能做紮實
這次把「AI 模型切換」端點併入產品分析 API,讓功能回到穩定、準確的分析。也處理 OpenAI 模型更新的封裝,補上 FastAPI middleware 與錯誤處理;下週要做完整的整合測試,也確認前後端能搭配運作,並用監控與快速還原先前版本的機制降低風險。
打造「保養品成分分析」後端原型:選用 FastAPI,以非同步處理應對 AI 延遲,並設計可在多模型間安全切換的「逃生門」(含 Grok)。重點放在錯誤處理與降級邏輯,確保故障時介面穩定。下一步:基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性(metrics、tracing、警示)。
Renew: Day 0
Agent 不只產生文字,還可能查資料或改動產品狀態。搭配產品實作情境與現行 SDK,拆開輸入、工具授權與輸出檢查的責任。
保留 2025 年對美國出口管制、企業供應與中國硬體替代的分析,補上 2026 年 H200、MI325X 有條件逐案審查的政策後續,區分提案、現行規則與境外算力交易的限制。
以下整理 2025 年 10 月間 OpenAI 的核心爭議:改制與融資綁定、反壟斷與監管壓力、內容政策(成人情色)、安全與法律風險,以及「過度互聯、可能太大而不能倒」的系統性風險討論。
cosGlint 1.2.4 上線:Findskin 核心演算法重新設計、膚質細分至 10 種,搭配全新相機介面與「計算權重」報告,讓拍照更順、結果更準。Ingrelens 提供 AI 成分解讀、膚況檢測與個人化保養建議,協助判斷產品是否合適。
cosGlint 的回饋介面:點一下分數,30 秒後自動送出,想補充的人也能寫文字或撤回。這篇記錄我如何用倒數、動畫和 A/B 測試,讓兩種需求放在同一個流程裡。
面試作業也可能是攻擊入口:一次 Node/React 測試儲存庫的伺服器端惡意載入與防護重點
回看 2025 年 OpenAI 宣布放寬成年人內容的計畫,區分原始訊息、產品判斷與實際可用範圍;補上個人化指示和內容權限應分開管理的做法。
把高溫、濕度、風速、UV 指數轉成可執行的日常保養:從保養品分析到成分分析,cosGlint 以可被解釋的訊號給出白天防曬、夜間修護、隔日預防的具體指引。
回顧 cosGlint 第 209 天的成分分析與產品規劃,補上 Day 234、1.2.4 膚質演算法及相機介面的後續更新。
保留 API key 外洩事件,更新 Gemini 預付計費與 OpenAI 支出上限,說明後端代理、配額、限流和停機責任。
保留 cosGlint 2025 Android 封測心得與填答,補上個人帳號適用範圍、12 人連續 opt-in 14 天及公開資料規則。
回看 2025 年 GPT-5 上線與 GPT-4o 回歸爭議,討論選擇權、互動偏好與產品語氣設計;補上 2026 年自訂指示和事實邊界的做法。
這週從 SEO、Dockerfile/Supervisor、狀態管理、Tiptap + AI 到 環境變數,每天都有新坑。與其把它們當救火,我選擇把舊債系統性轉成投資,讓產品的基礎更穩。 * SEO不是小事。重新設計 JSON‑LD 和 metadata,短期流量未必動,但可
保留 Google 解除綁定的開發經過,補上站內 session、OAuth scope、access/refresh token 與登入同意撤銷的差異。
今天把幾件拖很久的事一次處理掉,專案也順了不少。 先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔,結果測試掛了:有個測試竟然跟 sitemap 的產生邏輯耦合在一起。把測試拆乾淨、舊案例順手整理後,CI 回到綠燈。像清掉房間的舊雜物,空出腦袋。 真正影響
本來計畫把時間放在核心功能的優化,結果一打開產品分析服務的介面,先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異,卻會讓品牌商覺得產品不夠專業,也影響他們的信任。想到我們的客群特別在乎質感,我還是把今天的重心從新功能挪開,展開一場用語清掃。 原本只想改幾
AI 分類越做越複雜,是在挖坑還是填坑? 這幾天把重心放在兩件事:產品分類的 AI 自動化,以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下,結果一路從資料結構、路由、紀錄,到架構設計全被牽出來重整。 先談分類。 起手式很直接:把產品名稱與描述丟給模型,取
今天的開發原本很單純:做一個訪客帳號。實作後卻發現,難的是讓它用起來一致、可信。這一整天的折返,讓我更確定:產品的差異,往往來自那些使用者不會主動說出口、卻一直感受到的細節。 一、身分與名稱要一致。一開始我以為 localStorage 放個暱稱就好。等到遇到「訪客是否能轉成正
API 重構後的幾點實話:技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來:API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構,還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險,過去半年累積
成分搜尋與 API 整合的兩天修補:從資料庫到前端的連鎖反應 這兩天主要在處理兩件事:把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理,全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD,前端要找成分時不是
延續昨天的 AI 整合反思,我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節,整個渲染邏輯就像多米諾骨牌一樣一路倒下:從前端元件、狀態流到資料處理方式,都得重新整理。雖然頭疼,但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊,原本擔心資訊太細,使用
昨天把產品管理的 CRUD 骨架穩住後,今天直接把精力放在條碼掃描的擴展。理由很簡單:如果輸入資料不可靠,後面的分析再巧都只是表面工夫。 先整理了幾個後端細節,把多餘的 SQL 彈性收斂,移除那些看似靈活、實則增加風險的參數,順手解了一些依賴問題。結論很直白:簡化後更安全,查詢
條碼掃描初步跑起來了,但影像前處理比預期花時間。這週的反省是先讓功能上線,再根據使用資料調整;下週優先處理弱光環境下掃描太慢的問題。
讓掃描更可靠,也把產品管理功能做紮實
這次把「AI 模型切換」端點併入產品分析 API,讓功能回到穩定、準確的分析。也處理 OpenAI 模型更新的封裝,補上 FastAPI middleware 與錯誤處理;下週要做完整的整合測試,也確認前後端能搭配運作,並用監控與快速還原先前版本的機制降低風險。
打造「保養品成分分析」後端原型:選用 FastAPI,以非同步處理應對 AI 延遲,並設計可在多模型間安全切換的「逃生門」(含 Grok)。重點放在錯誤處理與降級邏輯,確保故障時介面穩定。下一步:基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性(metrics、tracing、警示)。
Renew: Day 0