平屋慢生活

什麼是 AI 幻覺不知道要求它說明依據把問題改成「可驗證」的形式列出不確定性評級提供實測方法AI 產生了看起來合理、語氣很肯定，但其實不正確、沒有根據，或與事實不一致的內容，更精確來說，生成式 AI 在缺乏可靠依據、理解錯誤、推理失準或資料不足的情況下，產生錯誤、虛構、誤導性或無法驗證的輸出 例如 編出不存在的論文、書籍、網址 說某個 API 有某個參數，但其實文件裡沒有 把兩個相似概念混在一起 明明不知道，卻用很肯定的語氣回答 對你的程式碼做出錯誤判斷 引用不存在的法律、規格、版本資訊 把「可能」講成「一定」 但現在的 AI 沒有聰明到可以「故意說謊」，事實上是模型在「預測下一段最像答案的文字」時，產生了形式上像答案、實質上卻錯誤的結果，大型語言模型的核心能力是根據上下文，預測接下來最合理的文字，但「最合理的文字」不等於「最真實的文字」，這就像一個人很會接話、很會寫文章、很會模仿專業語氣，但他其實他，一定真的知道答案 所以本質上它比較像是看過大量文字後，學會「什麼樣的問題通常會接什麼樣的回答」，當它不知道答案時，可能會根據語言模式補出一個「看起來合理」的答案 例如你問某某冷 ...

https://wiki.91app.com/pages/viewpage.action?pageId=236486916

購物車操作時帶上 uniqueKey，其實不完全是為了防重播攻擊，而是為了： 保證資料正確性（資料的歸屬與一致性） 避免資料混淆或誤用（區分同一帳號不同來源） 有時也可以延伸作為防止重播、防偽等手段 🧠 拆解購物車 uniqueKey 的用途（真實意圖）🔹1️⃣ 識別這個「購物流程的上下文」【主要目的】✅ 舉例說明： 當使用者進行購物行為（點選商品 → 加入購物車 → 結帳），系統會幫他產生一個： CartSessionId = “CART-20251118-8FDE23C8F231” 這個 uniqueKey（或叫 CartId、CartSessionId、TransactionId…）： 代表一組購物流程 在操作「新增商品、刪除商品、選擇優惠」時都要帶上 就像「你去 IKEA 拿購物推車時的車號」 🔹2️⃣ 避免同帳號操作被混淆📦 假設情境： 小明開了兩個瀏覽器分頁，各自買不同商品 如果沒有 uniqueKey，可能會把 A 分頁的商品加到 B 分頁的購物車中 加上 uniqueKey，每次操作都清楚知道是在哪一台車上加的 🔹3️⃣ 支援匿名用戶購物 很多電商允 ...

C:\91APP\NineYi.WebStore.MobileWebMall\WebStore\WebAPI\Extensions\HttpModules\CorsModule.cs Application_EndRequest Access-Control-Allow-Origin「每次 Request 結束時」，自動決定 回應要不要加上 Access-Control-Allow-Origin 加上哪一個允許跨域的來源（Allow-Origin） 取得來源網址 (Origin / Referrer) → 判斷是否在允許清單 → 產生 Allow-Origin → 寫入 Response Header Step 0：取得 HttpContext12var httpApplication = (HttpApplication)sender;var httpContext = httpApplication.Context; ✨ Step 1：錯誤狀態不處理 CORS1234if (httpContext.Response.StatusCode >= 400 || h ...

FluentValidationhttps://github.com/FluentValidation/FluentValidation https://docs.google.com/presentation/d/1bj-cdmw9ArauCphDmmEm-D2QKRBnwohUuRv6TP2IRUs/edit?slide=id.g8394b5fbe8_0_53#slide=id.g8394b5fbe8_0_53

Controller 層 如何取得 Header註冊服務 1services.AddHttpContextAccessor(); 在 ASP.NET Core 裡面，每當一個 HTTP 請求進來（像是有人開你的網站、叫你的 API），系統就會產生一個「HttpContext」物件，裡面記錄了使用者是誰（包含登入帳號），請求的網址、Header、Body，回應的資料 Session、Cookie 等等，但是這個 HttpContext 不是你想用就用的，它只在「有請求進來」的時候才存在，而且它不是自己隨時隨地可以 new 的東西。 所以問題來了，如果你寫的程式碼在「服務（Service）」裡面，例如 Repository 或其他非 Controller 的地方，你就拿不到 HttpContext，因為這些不是直接處理 HTTP 請求的 AddHttpContextAccessor() 的本質就是： ✅ 註冊一個可以讓你在任何地方都「安全地取得目前的 HttpContext」的工具。 當你呼叫這行之後，系統會幫你註冊一個叫做 IHttpContextAccessor 的服務，這個服務有 ...

不用 MemoryStream，用 StringContent 更省記憶體（推薦） 1234567891011121314151617private async Task UpdateS3DataAsync(string s3RecordData, string s3Path){ var putRequest = new PutObjectRequest { BucketName = _bucketName, Key = s3Path, ContentBody = s3RecordData, // ⭐不用手動 new MemoryStream() ContentType = "application/json" }; var response = await _amazonS3.PutObjectAsync(putRequest); if (response.HttpStatusCode != HttpStatusCode.OK) t ...

Encoding.UTF8.GetBytes(yourString)因為 .NET 的 string 在記憶體中是用 UTF-16 存的（每個字兩個 byte）當執行 1Encoding.UTF8.GetBytes(yourString) 發生的事情是 .NET 看到一個字串（UTF-16） 用 UTF-8 的規則重新編碼 把每一個字拆成 UTF-8 所需要的 byte 回傳一個 byte[] 也就是 🔄 UTF-16 → UTF-8 → byte[] 以字「你」為例UTF-16 編碼（.NET string 的內部格式）是 0x4F60UTF-8 會把這個字轉成三個 byte E4 BD A0 📘 .NET 字串 → 用自己的語言（UTF-16）存🌍 外面世界（檔案、網路、API）都講 UTF-8🔧 GetBytes() 就是「把話翻譯成外面世界能懂的 byte」 StreamStream 是一種資料讀寫的管道 Stream 不關心資料從哪來 你可以一段一段讀 也可以一段一段寫 Stream 就像一根水管：💧「資料變成水，讓你慢慢流出來或流進去。」 MemoryStr ...

Redis byteoutbyteout（或稱「bytes_out」） 表示 Redis 伺服器 送出給客戶端的資料量，也就是「Redis 從伺服器傳出去的流量」。 客戶端發請求 → Redis 回應資料 這些回應的資料（字串、結果、查詢內容）加起來的總位元組數，就是 byteout Redis 的運作核心在於「記憶體內存取」+「網路通訊」。所有操作最終都透過 TCP 傳輸資料給客戶端。因此： bytes_in：代表接收到的資料量（客戶端 → Redis） bytes_out：代表傳送出去的資料量（Redis → 客戶端） 這兩者都是 Redis 網路 I/O 層的關鍵監控指標，能幫你了解 Redis 的流量負載情況。 本質上，byteout 高通常意味著： 回傳資料太大（例如 GET 很大的 value、LRANGE 取太多元素） 客戶端請求頻繁（流量大、QPS 高） 資料被重複讀取（Cache 未命中、熱點 Key 被重複讀） 可能有惡意或異常行為（例如攻擊者持續 Dump 資料） 切緩https://docs.google.com/spreadsheets/d/1GD8 ...