Four AI Agents Planned My Feature While I Waited for an Uber — All I Did Was Review
No Human Code doesn't replace engineers. It lets them focus on architecture decisions and quality gates.
No Human Code doesn't replace engineers. It lets them focus on architecture decisions and quality gates.
No Human Code 不是取代工程師,是讓工程師專注在架構決策和品質把關
From rejecting OpenClaw to automating design handoff with OpenAB + Figma MCP + Jira MCP. Last week Anthropic suspended 60+ accounts overnight — validating why vendor-agnostic architecture matters. Covers technical trade-offs, cloud vs local AI, MCP × ACP as the enterprise AI battleground, and the no-human-code product architecture vision.
半年前拒絕 OpenClaw,半年後用 OpenAB + Figma MCP + Jira MCP 自動化 design handoff。上週 Anthropic 停權 60+ 帳號驗證了 vendor-agnostic 架構的必要性。涵蓋技術 trade-off、cloud vs local AI 佈局、MCP × ACP 企業戰場,以及 no human code 的產品架構遠見。
Most engineers use AI as a chatbot. This is what happens when you treat it as infrastructure — with the same rigor you'd apply to choosing a database or designing a deployment pipeline.
A practical guide to frontend testing using real production components — newsletter anti-spam validation, clap button debounce, and Markdown detection — with Vitest, React Testing Library, and Playwright.
以自己網站的真實元件為範例,分享前端測試的分層策略 — 涵蓋 NewsletterSubscribe 反垃圾驗證、ClapButton 防抖與樂觀更新、Markdown 偵測函數的測試實作,使用 Vitest、React Testing Library 與 Playwright。
一個前端工程師在轉職 Data Engineer 的路上,不靠 Dagster UI,自己寫了一個 5 頁的 Streamlit Dashboard 來理解醫療級數據 Pipeline 的每一層。從 Raw Data 到 Partitioning、CGM 補值、業務分析、到全局瓶頸 — 用視覺化的方式搞懂資料怎麼流、怎麼變、哪裡會爆。
資深 Data Engineer 前輩看完我的 GitHub 說:「用 UDF 如果沒解釋原因,直接扣分。」這才發現 Spark ETL 裡的 Python UDF 藏著 JVM ↔ Python 序列化地雷。重構為 Native Functions 後跑了 500 萬筆壓測,Local Mode 下差距僅 ~1%——但能解釋「為什麼差距小」,才是面試真正的加分項。
550 days working at the intersection of hardware and software — from building a unified control platform integrating 15+ PC hardware devices, to transitioning into full-stack development with Django + PostgreSQL, to architecting a Data Lakehouse POC with Apache Iceberg and Trino on my home lab. This is a technical retrospective on architecture evolution, backend engineering growth, and the path from frontend specialist to data engineering practitioner.
【2025 年度技術回顧摘要】 在內湖行善路科技公司參與硬體生態系統研發的五百五十天中,我主導建立了觀測性監測體系,並導入標準化日誌規範,實現從被動救火轉向主動預警的技術管理 。 在資料工程的架構探索方面,我利用自建雙顯卡伺服器研發了醫療數據湖倉專案,採用儲存層與計算層分離的架構解決醫療審計與分析效能的衝突 。同時透過分佈式運算處理大規模空間數據,成功解決傳統後端架構在高併發下的記憶體溢位瓶頸 。 此外,我也建構了跨平台財務系統,將複雜財務邏輯模組化。這段歷程展現了我從資深前端架構師轉向資料工程的明確路徑,並強調在人工智慧世代中連結複雜系統與建立數據秩序的工程價值 。
在 3.1 和 3.2 中,我們解決了批次處理(150 秒/50 萬筆)。但即時推論還是瓶頸——每次啟動 Spark Context 需要 15秒,拿來查單一司機根本是殺雞用牛刀。本文將架構重構為微服務:FastAPI 作為 Producer 接收請求並秒回 TaskID,Redis 作為 Message Broker,Celery Worker 作為 GPU Consumer 執行推論。核心優化是「模型熱啟動」——在 Worker啟動時載入模型到 GPU 記憶體,後續請求直接使用,從 Cold Start 的 15 秒降到 Hot Start 的 0.25 秒,實現 60 倍加速。
在 Part 3.1 實驗中,雙 RTX 3090(無 NVLink、PCIe 3.0)的執行時間竟比單卡慢 2.8 倍,主因是 NCCL 通訊 overhead 佔了 70%。既然短期無法升級硬體,本文聚焦架構調整:Stage 1 用 Apache Spark 處理複雜的 ETL 邏輯(145 秒),透過 Parquet 列式儲存交接數據(GPU 讀取快 32 倍),Stage 2 用 RAPIDS cuML 完成 K-Means 聚類(0.51 秒)。文末也分享從 WSL 2 遷移到原生 Ubuntu 的心得,Docker GPU 啟動時間從 15 秒降到 3 秒。
This article isn't about future chips. It is a record of how, in early 2026, I attempted to realize "full-scale data analysis" in a local environment. It’s the story of how I transformed a spare machine originally built for Windows client testing—using a power drill, an external power supply, and cables from Taobao—into a machine that crashed into a physical wall, only to be reborn.
當 CES 2026 描繪著 Strix Halo 的優雅未來,我的現實卻是暴力的。為了在 2017 年的 Z370 老主板上驅動雙卡 RTX 3090,我不惜將第二顆電源「外掛」在機殼外,並透過一條淘寶買的 SATA 線觸發它的心跳。這是一篇關於物理限制、NCCL Error 報錯、以及工程師如何用混合架構(Spark + RAPIDS)繞過硬體高牆的實戰紀錄。
This article explains how a migration from Node.js to PySpark surfaced an unexpected bottleneck: LLMs were failing with “Context Window Exceeded” not because CSV files were large in megabytes, but because high‑precision GPS floats created extremely dense tokens. By showing how a value like 121.5654321 is split into multiple tokens, while a truncated 121.56 uses fewer, it reframes precision itself as a cost driver in token‑bounded systems. The proposed fix is a precision truncation layer in the ETL pipeline that rounds floats to domain‑appropriate precision (for GPS, typically 2 decimals), which reduces input tokens per coordinate by about 25% and increases the number of rows that fit into a fixed context window by roughly one‑third.
在處理 50 萬筆地圖軌跡資料時,Node.js 單執行緒架構在 3.2 秒後因記憶體溢出(1.7GB)而崩潰,而 PySpark 分散式架構則穩定完成全量處理(19.88 秒)。本文透過對照實驗,比較兩種架構在大規模資料處理上的表現差異,並探討 Event Loop 的物理限制、Spark DAG 的執行機制,以及浮點數精度問題的防禦策略。實驗數據顯示,在處理大型資料集時,系統的穩定性往往比峰值效能更具實際價值。
When processing 500,000 map trajectory records, the Node.js single-threaded architecture crashed after 3.2 seconds due to memory overflow (1.7GB), while the PySpark distributed architecture stably completed the full dataset processing (19.88 seconds). This article presents a controlled experiment comparing the performance differences between these two architectures in large-scale data processing, exploring the physical limits of the Event Loop, Spark's DAG execution mechanism, and defensive strategies against floating-point precision issues. The experimental data suggests that system stability often has more practical value than peak performance when processing large datasets.
This article tells the story of an engineer who tried to cut 30% of mapping API costs, but due to survivorship bias and sample-based testing, nearly crashed a SaaS food-delivery order system within 15 minutes of launch. A pre-built Feature Flag became the only escape hatch, enabling an instant rollback to Google Maps and stopping mounting compensation risks in under 45 minutes. Three years later, the same engineer revisits the incident using Apache Spark, real-time data pipelines, and LLMs to build an intelligent decision matrix, evolving from a Senior who could only triage incidents into an Architect who designs systems to proactively manage business risk.
這是一個工程師為了省下 30% 地圖 API 成本,結果因為倖存者偏差與抽樣驗證失誤,差點讓整個 SaaS 外送訂單系統在上線 15 分鐘內大爆炸的故事。 當時只能靠事先埋好的 Feature Flag 緊急一鍵切回 Google Maps,在 45 分鐘內止血,避免大量月費減免與賠償。 三年後,作者用 Apache Spark、即時資料管線與 LLM,重建一套「智慧決策矩陣」,從只能抽樣賭運氣的 Senior,成長為能用架構控管商業風險的 Architect。
This article shares a lightweight observability implementation designed specifically for PC hardware control software (RGB, fan control, etc.). By using "Exceptions + Structured Logs" instead of full TEMPLE, in 6 months of production use, problem diagnosis time dropped from 10-14 days to 1-2 days, with average engineering hours reduced ~80%, and some cases achieving 83-85% efficiency improvement. Key highlights include: Four-layer log classification (DEVICE/AUTH/APP/SYSTEM), 5W1H structured fields for hardware operations, IPC logging pipeline in Electron + Native Add-on architecture, and async batching with intelligent throttling keeping additional latency to 1-2ms, balancing observability with performance.
Understanding React's rendering mechanism is critical for writing efficient applications. This article systematically analyzes the execution timing of useEffect and useLayoutEffect, their appropriate use cases, and React 18's new batching mechanism. Mastering these concepts will help you avoid common performance issues and UI flickering.
為什麼 typeof [] 是 'object'?學會 Type Guards 讓你不再踩雷
面試被問到 sort() 會改變原陣列嗎?一張表搞懂所有 Array Methods
身為個人品牌經營者或小型團隊,電子報是維繫讀者關係的重要工具。市面上有 Mailchimp、ConvertKit、Substack 等成熟服務,但當你需要更多客製化、想控制成本、或單純想深入了解系統如何運作時,自建 EDM 系統就成了有趣的選項。 這系列文章將分享我從零開始打造 EDM 系統的完整歷程,包含架構設計、API 串接、事件追蹤到營運優化的所有細節。
在構建多人分帳系統時,合理的 Django Model 設計直接影響系統的可維護性、查詢性能和業務邏輯的清晰度。本文將以實際的家族活動分帳系統為例,深入探討關鍵的 Model 設計決策與最佳實踐。
從理論到實踐——用真實的資安掃描工具解構 Tauri 架構
本文深入探討在 Django REST Framework 中設計多層權限系統的實務經驗。以家族記帳系統為例,說明如何處理五種角色(系統管理員、活動管理者、群組管理者、參與者、一般用戶)的差異化權限需求。文章涵蓋三層架構設計(Model、ViewSet、Serializer)、動態權限實作、QuerySet 效能優化,以及審計日誌整合等核心技術點,並提供完整的程式碼範例與最佳實踐建議。
本文深入探討如何使用 Tauri 2.0 + Vue 3 + Rust 建立高效能的跨平台桌面應用。有別於一般入門教學,本文基於 RedForge Scanner(一個安全掃描工具)的實際開發經驗,展示從專案建立到生產打包的完整流程。 文章從 Electron 開發者常見的痛點出發:安裝檔 120 MB、記憶體占用 250 MB、啟動慢。透過遷移到 Tauri 2.0,最終達成安裝檔縮小 15 倍(8 MB)、記憶體節省 76%(60 MB)、啟動速度提升 4-6 倍的顯著成效。 文章涵蓋十大主題:(1) 為什麼選擇 Tauri(與 Electron 的詳細架構比較、實測數據);(2) 開發環境設置(macOS/Windows/Linux 各平台需求);(3) Tauri Commands 與 IPC 通信機制(invoke、events、狀態管理);(4) 前端(Vue 3)與後端(Rust)整合(Composables、類型映射);(5) 檔案系統操作與權限管理(Tauri 2.0 Capabilities 系統);(6) 資料庫整合與持久化(SQLite 插件、Migration);(7) 視窗管理與系統托盤(多視窗、背景執行);(8) 打包與跨平台發布(GitHub Actions 自動化);(9) 常見問題與解決方案(5 個常見坑和修復方法);(10) 最佳實踐檢查清單。 本文特別著重 Tauri 2.0 的新特性與陷阱避免:Capabilities/Permissions 權限系統的設定方式;IPC 參數命名必須與 Rust 函數匹配;Rust Option 映射為 T | null(不是 undefined);關閉視窗時如何只隱藏而不退出。所有程式碼範例均來自 RedForge Scanner 的生產程式碼,包含完整的錯誤處理和中文註解。 本文適合已具備 Vue 3 / TypeScript 基礎、想開發桌面應用但不想承擔 Electron 體積負擔的前端工程師,以及想學習 Rust 並將其整合到前端專案中的開發者。 核心貢獻: - ✅ Electron vs Tauri 完整架構比較與實測數據 - ✅ Tauri 2.0 Commands、Events、State 完整實作 - ✅ Capabilities/Permissions 權限系統詳解 - ✅ SQLite 資料庫整合與 Migration - ✅ 系統托盤與多視窗管理 - ✅ GitHub Actions 跨平台自動化建置 - ✅ 5 個常見問題與解決方案 - ✅ 20+ 項最佳實踐檢查清單
「類型系統不是束縛,而是解放。當你的程式碼能在編譯時告訴你哪裡有問題,你就不再需要在凌晨三點被 production error 驚醒。」
本文深入探討 Vue 3 Composition API 在大型桌面應用 RedForge Scanner 中的完整實踐。有別於理論介紹,本文提供基於實際生產專案的量化分析、完整實作和經驗總結。 文章從實際遇到的痛點出發,展示 Composition API 如何解決 Options API 的命名衝突、程式碼分散和 TypeScript 類型推導問題。透過完整的 useScanPersistence Composable 實作(350 行),展示從需求分析、介面設計到實作與測試的系統化開發流程。 文章特別著重實測數據與常見陷阱:透過 Benchmark 測試證明 shallowRef 優化可使大資料渲染效能提升 76%(245ms → 58ms);深入探討 shallowRef + { deep: true } 的反模式及記憶體洩漏問題;提供 watch vs computed 的選擇策略;100% TypeScript 覆蓋率和 92% 測試覆蓋率的達成策略;以及 12 項可直接遵循的最佳實踐檢查清單。 本文適合已具備 Vue 3 基礎、希望深入理解 Composition API 設計模式的中高級前端工程師,以及需要在大型專案中導入 Composition API 的技術決策者。所有程式碼範例均完整呈現,無需存取原始倉庫即可理解與應用。 核心貢獻: ✅ 真實痛點到解決方案的完整演進過程 ✅ 350 行生產級 Composable 完整實作(含詳細註解) ✅ 實測效能數據(渲染 -76%、Bundle -12%、記憶體 -15%) ✅ watch 與 shallowRef 的陷阱與最佳實踐(含記憶體洩漏案例) ✅ watch vs computed 選擇策略與實戰案例 ✅ 12 項最佳實踐檢查清單 ✅ 完整測試策略(92% 覆蓋率)
你是否也被 Redux 裡滿滿的 API 處理邏輯搞得頭很大?是否懷疑過為什麼一個簡單的資料請求需要寫 50 行程式碼? 這篇文章源自我在重構專案時的頓悟:我們一直在用錯誤的方式管理伺服器狀態。透過 TanStack Query,我重新理解了前端狀態管理的本質 - 不是所有狀態都該用同一種方式處理。 文章涵蓋: 為什麼要區分伺服器狀態和本地狀態 React/Vue 專案的最佳實踐架構 TanStack Query 的核心優勢(程式碼量減少 90%!) 實際的程式碼對比和遷移經驗 效能優化技巧和踩坑分享 無論你是 React 還是 Vue 開發者,這篇文章都能幫你找到更優雅的狀態管理方案。最重要的是,你會學到如何讓每個工具在最適合的場景發揮作用,而不是試圖用一個工具解決所有問題。
週末川普一句話,導致富台指暴跌5% 💥,週一開盤預期先跌約 1000 點!回顧歷史,統計顯示:年度跌幅 5% 約每年四次...
這篇文章分享一套專為 PC 硬體控制軟體(如 RGB、風扇控制)設計的精簡可觀測性實作,透過「Exceptions + 結構化 Logs」取代完整 TEMPLE 架構,在 6 個月的實戰中,將問題診斷時間從 10–14 天縮短到 1–2 天,工程師工時平均降低約 80%,部分案例效率提升達 83–85%。方案重點包含:以 DEVICE/AUTH/APP/SYSTEM 四層分類管理日誌、為硬體操作設計 5W1H 結構化欄位、在 Electron + Native Add-on 架構下實作 IPC 日誌管線,以及利用非同步批次與智能節流,將額外延遲控制在 1–2ms 以內,確保可觀測性與效能之間取得平衡。
As Blake Lab's cultural-technology integration experiment, Day 5 dives deep into product management practice, exploring how to balance the dual roles of engineer and product manager in solo development, driving PAPA system iteration optimization through user feedback.
As Blake Lab's cultural-technology integration experiment, Day 4 dives into Tauri desktop development, showing how to create native desktop experiences for macOS and Windows using web technologies, with large-screen friendly interfaces designed specifically for elders.
As Blake Lab's cultural-technology integration experiment, Day 3 dives into Django backend's technical core, showcasing how elegant architecture design solves complex financial splitting needs for Indigenous communities.
PAPA 是專為阿美族家族設計的財務管理工具,透過7天開發實踐文化敏感設計方法論,將文化洞察轉化為具體功能:透明分帳機制尊重集體決策、大字體介面解決跨世代鴻溝、彈性規則體現互助傳統。12位測試者(28-75歲)驗證成果顯著:長輩獨立操作成功率達80%、爭議減少50%、滿意度4.6/5。文章聚焦三階段方法(傾聽→轉化→驗證),提供可複製的原住民數位工具設計框架。
PAPA開發Day6聚焦效能優化的平衡藝術。從產品思維回歸工程實戰,學習在技術可行性與使用者需求間找到最佳解決方案。重點包括:評估現有架構效能、識別使用者真正痛點、規劃階段性優化策略、建立務實監控方法。最大學習:技術團隊的價值在於穩健解決真實問題,而非炫技。展現Blake Lab跨領域專業價值。
- 獨立開發者尋求產品管理最佳實踐 - 產品經理關注文化科技應用策略 - 全端工程師學習產品思維轉換 - 對跨世代使用者體驗設計有興趣的專業人士
部落活動中心的電腦需要桌面版,但 Electron 100MB 太大了。本文分享如何用 Tauri 和 Web 技術打造 macOS 和 Windows 的原生體驗,讓長輩也能輕鬆操作。
簡單勝過複雜:扁平化權限比複雜權限樹更易維護 業務邏輯內聚:Model 層封裝提升程式碼品質 查詢優化至關重要:正確預載策略可提升 10 倍效能 文化理解不可替代:AI 能生成 60% 程式碼,但核心算法需人工設計
- 主題定位:四層權限系統的文化敏感 UX 設計 - 技術挑戰:48 種權限組合的視覺化難題 - 解決方案:四大創新設計方法 - 技術實現:完整的技術棧和工具組合 - 性能數據:具體的效能指標 - 核心洞察:文化轉譯的重要性
- 🎯 起源:阿美族家族聚會後,看到表姊花2週處理50人財務結算的痛點 - 🔍 調研:訪談5位活動組織者,發現技術層面(預算失控、收據散亂)與文化層面(集體決策、跨世代參與)需求 - 💡 產品定義:PAPA分帳系統 - 無需註冊、即開即用、資訊透明 - ⚡ 技術架構:Django 5.0 + PostgreSQL 後端,React 18 + TypeScript 前端 - 📊 實際成果:完成需求分析、技術選型、核心資料模型設計(Event, Group, Expense) 定位:Blake Lab「文化×技術」方法論的首次實踐,展現AI時代文化科技雙領先者戰略