EyesRhythm
在本機執行的眨眼頻率偵測器,盯著螢幕久了會提醒你眨眼。

產品拆解
使用者在用它做什麼
免費版能用全部基本功能;Pro 每月 $5,多了長時間提醒和匯出。影像不會上傳。
替使用者省掉了哪一步
乾眼的人早就知道該多眨眼,難的是做到。它把這件事從「自己記著」變成「它來找你」,省掉的是注意力,不是知識。
它怎麼運轉
打開就開始看,頻率正常時什麼都不做,偏低才動一次螢幕,形成一個閉環。
用了什麼 AI 技術
三層都在本機:擷取影格、處理、輸出。沒有伺服器端,畫面不出機器。
新在哪
多數護眼工具依時間提醒(每 20 分鐘一次),它是依你實際的眨眼頻率觸發。
為什麼有人願意用
- 不用註冊、不要帳號,試用成本幾乎為零
- 有一個能截圖分享的分數,可以當社交貨幣
- 程式碼公開可查,有隱私顧慮的人能自己看
不足與缺陷
- 指標沒法自證:使用者不知道準不準,也沒有第三方驗證
- 可以被「關掉螢幕」「眨一下眼」零成本取代
- 依賴攝影機權限,這是最大的轉換障礙
評價分析
This is a great idea and can help with dry eye. Many people who work in front of a computer have dry eye which can literally be solved by blinking more.
Really cool idea, but I am very careful with installing non-OSS stuff on my computer that records my webcam 24/7.
覆蓋區域
英語區變更記錄
使用者評價
0 人評分過 · 0 則評論句式進化
固定幾句「求推薦」「有沒有」搜到底,能挖到的需求很快就見底。這一頁是把「讓搜尋詞自己進化」這件事真跑了兩輪的結果,包括它失敗的地方。
怎麼轉起來
兩輪實跑結果(2026-11-09)
| 句式 | 返回 | 求購 | 痛點 | 說明 |
|---|---|---|---|---|
| 每天重複做表格(種子) | 18 | 0 | 13 | 痛點最多,但人工看只有 3 條是真的 |
| 求一個做發票(變異) | 19 | 3 | 1 | 求購最多,人工看 0 條是在找工具 |
| 求一個整理會議紀錄(變異) | 18 | 1 | 2 | 換場景後有小幅產出 |
| 哪裡能找到整理會議紀錄(變異) | 14 | 0 | 3 | 換個說法沒帶來增量 |
| 有沒有什麼AI工具推薦(種子) | 15 | 1 | 0 | — |
| 求推薦一個AI工具(種子) | 19 | 0 | 0 | 全是合輯與教學 |
| 現在都靠手工(種子) | 20 | 0 | 0 | 說法太籠統,搜不到具體情境 |
| "is there an AI that"(種子) | 17 | 0 | 0 | 規則判 0,但人工看有 6 成是具體情境——是判定器的問題 |
| "wish there was a tool"(種子) | 18 | 1 | 0 | — |
然後把 39 條人工讀了一遍,發現判錯了
原因不複雜:業配文的結構就是「先講痛點,再推產品」,天生就長得像需求。規則看到痛點和情境詞就放行,正好被業配文騙。
所以機制要改三處
一、判定這一關必須用模型讀全文,不能用詞表。詞表永遠追不上情境的寫法,而且會被業配文騙。模型要回答的就一個問題:這個作者是在「求」,還是在「給」?給的一律不算。
二、進化的重點不是句式,是場景。實測裡「求一個 X」,X 換成做發票出 3 條、換成給商品圖換背景出 0 條;而「每天重複做表格」一條頂別人十條。場景的差別遠大於說法的差別。所以每一輪該變的是「問什麼」,不是「怎麼問」。
三、平台要分開養。X 上「is there an AI that」人工看六成是真的在問;小紅書上同一個句式,搜出來全是標題黨。不是詞的問題,是這兩個地方的人做的事不一樣——一個在公開提問,一個在看別人種草。
還有兩條上限,得提前認
說法是會窮盡的。中文裡表達「我想要一個能 X 的工具」就那麼幾十種寫法,跑一兩週就會把有用的都找出來,之後新說法帶來的增量接近零。這一天到了,就該停掉換說法,只換場景。
只能挖到說出口的需求。說不出自己想要什麼的人,這套機制永遠碰不到。別指望它能發現「未知需求」,它的上限是把「已說出口的需求」覆蓋全、說法聽全。
這些資料怎麼來的
這一頁不是產品功能,是把“哪些資訊真的能拿到”攤開給你看。6 個項目,全部來自 2026-11-08 HN 上的新品,逐一造訪官網、定價頁、討論區。
每個資訊項目的實際取得率
| 資訊項目 | 6 個裡拿到 | 狀態 | 怎麼拿的 / 為什麼拿不到 |
|---|---|---|---|
| 官網能不能打開 | 5 / 6 | 硬事實 | 直接請求。domdb.com 返回 403,是反爬擋的 |
| 它是什麼(一句話) | 5 / 6 | 硬事實 | 頁面標題 + 描述標籤,基本可靠 |
| 有沒有定價頁 | 5 / 5 | 硬事實 | 看頁面裡有沒有 pricing 連結 |
| 具體價格方案 | 3 / 5 | 要人讀 | 價格能抓成文字,但哪個數字對應哪個方案必須人看,機器容易配錯 |
| 有沒有接受付款 | 判斷不了 | 會誤判 | 首頁只偵測到 0 個收款代碼,但其中 3 個有完整定價頁——它們顯然在收錢,只是收款代碼不在首頁。所以這一項不能自動判“沒在收錢” |
| 真實使用者評論 | 2 / 5 | 硬事實 | HN 討論區。另外 3 個是 0 評論,新品根本沒人聊 |
| 討論熱度 | 5 / 5 | 硬事實 | HN 分數與評論數 |
| 月收入(MRR) | 0 / 6 | 拿不到 | 沒有支付商核驗管道。任何“估算”都是猜,不寫 |
| 有多少使用者 | 0 / 6 | 拿不到 | 這些是網頁/桌面產品,沒有商店安裝量可查 |
| 中文社群媒體在聊嗎 | 0 / 3 | 等於沒有 | 小紅書搜尋專案名稱,回傳 16–20 條,但正文真正提到的 0 條。海外新品在中文圈等於不存在 |
三條結論
1. “它解決什麼問題”可以當標籤,但不能當判斷依據。官網自己寫的一句話是可靠的;使用者評論只有被討論過的專案才有,6 個裡只有 2 個。拿 2 條評論推斷“需求成立”,就是我上一版犯的錯。
2. 價格結構是硬數據,收入不是。三個專案的方案和單價都完整抓到了,能算出“一個客戶值多少錢”。但賣了多少錢,外部永遠看不到。所以卡片上“收入”一欄空著,寫“沒查到”。
3. 中文來源接不住海外新品。這不是來源不好,是場景不對。小紅書適合看“中國人願意為什麼付錢”,不適合看“海外剛出的東西有沒有人在用”。兩者要用不同的來源,不能混成一個資料庫。
所以這個資料庫能回答什麼
不能回答:它賺了多少錢、有多少活躍使用者、這個需求是不是真的成立。
後面這三件,只能靠你自己看、自己判斷。介面上不做結論,就是這個原因。