被追上也沒關係,我們為什麼還是繼續做 Termdock
Termdock 推出八個月後,很多原本很前面的功能已經被大廠 CLI 跟上了。但我們真正想做的,從來不是只靠幾個功能差異活著,而是讓大量使用 CLI、多專案切換的人,真的能更順、更穩、更少打斷地工作。
Tag
創業歷程、產品成長與實戰取捨
Termdock 推出八個月後,很多原本很前面的功能已經被大廠 CLI 跟上了。但我們真正想做的,從來不是只靠幾個功能差異活著,而是讓大量使用 CLI、多專案切換的人,真的能更順、更穩、更少打斷地工作。
第 292 天的年度檢討:從 Ingrelens 與 cosGlint 的基礎建設到架構解耦,LLM 與後端分離、Orchestrator 上線;經歷 11 月大流量的佇列塞車與 48 小時救火,補齊觀測與調度,cosGlint 用戶破兩千、內建 13k+ 商品,1.3.0 推出全方位部位檢測,持續迭代。
從華盛頓的法案到印尼機房的機架,再到中國數據中心的電費補貼,整個局面其實由三條主線拉動:政策、企業、技術現實。理解這三條主線,能幫我們預判接下來兩年算力市場的供需、價格、可用性,以及你我這種做產品的人會遇到的具體限制。
Termdock 在11/4 登上了 Product Hunt ,其實之前一直想去投,但有時候一忙就忘了,這次所幸直接上,但也發現我很多沒有做到的事前準備是可以讓成績更好的,這篇文章主要就是想先記錄下來,下次也好有個調整依據。
通過對多位成功創辦人的深度剖析,我們可以看到儘管他們的產品和市場千差萬別,但其成功的底層邏輯卻驚人地一致。這些共通的特質與做事方法並非天賦,而是可以被有志創業者學習和複製的思維模式與行為準則。
我們剖析了四種挖掘使用者痛點的核心途徑,但它們並非各自獨立的選項,而是一個整合的、可循環操作的策略系統。關鍵在於根據您的具體情境,採用最具策略性的順序與組合。成功的創新始於深刻的同理心,而系統化的痛點挖掘,正是將同理心轉化為商業價值的最佳路徑。
前言:將顧客回饋轉化為成長引擎 對於每一位自力更生的創業者和早期新創公司而言,最寶貴的資產並非程式碼或商業計畫書,而是與市場的真實連結。在這場充滿不確定性的旅程中,顧客回饋不是冰冷的數據,而是指引方向的羅盤、驅動產品迭代的燃料,更是點燃可持續成長的核心動力。許多創業者埋首於打造
聚焦創業「風險管理」:先驗證高價值痛點,再用分發驅動增長。內容涵蓋三大點子來源(自用痛點、複製優化、利基與平台)、低成本驗證方法(MVP、預售訂金、社群回饋),以及有機增長引擎(內容行銷、社群運營、SEO、短影音)與啟動擴張(生命週期優惠、影響者與付費投放)。強調創業者心態:專注一個問題、以速度迭代、韌性面對失敗。結論提出增長飛輪:洞察痛點→分發獲客→現金流迭代→深化價值。
Android 封閉測試通過心得:規則、填答、與實務提醒
這週幾乎都在跟 LLM 微服務搏鬥:為了彈性、金鑰池、供應商切換、逃生門到 fallback 機制的完善,再到 Sentry 與 Redis 限流的整合。這些改動使用者不一定看得到,但對穩定性與後續擴充很關鍵。 本週進展 * LLM 微服務成功從 Ingrelens 主專
昨天猶豫了半天要不要接 Microsoft Clarity,今天早上看了幾段 session 錄影,心裡總算鬆一口氣——問題一目了然:搜尋輸入體驗太糟。輸入法組字的時機一錯,搜尋建議就瘋狂跳,整段流程像在考驗用戶耐心。 第一件事,我把搜尋輸入的 debounce 重寫:組字期間
AI 分類越做越複雜,是在挖坑還是填坑? 這幾天把重心放在兩件事:產品分類的 AI 自動化,以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下,結果一路從資料結構、路由、日誌,到架構設計全被牽出來重整。 先談分類。 起手式很直接:把產品名稱與描述丟給模型,取
今天的開發原本很單純:做一個訪客帳號。實作後卻發現,真正的難題不在「能不能用」,而在「用起來是否一致、可信」。這一整天的折返,讓我更確定:產品的差異,往往來自那些用戶不會主動說出口、卻一直被感受到的細節。 一、身分與名稱的一致性不是錦上添花 一開始我以為 localStorag
今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能,結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求,整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結,直到要支援 guest 升級與 em
游標分頁、環境變數與 API 統一大作戰:把炸彈拆完,才有力氣往前走 有些技術債務不會自己消失,換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來,用環境變數統一管理,再加上 trim,免得前後多了空白符號害人抓狂。順手把散落各處的 console.log
這兩天主要在補技術債、梳理架構,過程當然少不了自我懷疑,但也總算把幾個老問題收斂了。 先是 Dockerfile。昨晚就覺得哪裡怪,早上看 deployment log 才確認——前端 CORS 一直叫,後端 API 的 domain whitelist 根本沒吃到。追了半天發
昨天把產品管理的 CRUD 骨架穩住後,今天直接把精力放在條碼掃描的擴展。理由很簡單:如果輸入數據不可靠,後面的分析再巧都只是表面工夫。 先整理了幾個後端細節,把多餘的 SQL 彈性收斂,移除那些看似靈活、實則增加風險的參數,順手解了一些依賴問題。結論很直白:簡化後更安全,查詢
提升掃描可靠性、夯實產品管理
打造「保養品成分分析」後端原型:選用 FastAPI,以異步處理應對 AI 延遲,並設計可在多模型間安全切換的「逃生門」(含 Grok)。重點放在錯誤處理與降級邏輯,確保故障時介面穩定。下一步:基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性(metrics、tracing、告警)。
Renew: Day 0