115 OJT 創新專案

115 OJT 創新專案

閱讀時間約 31 分鐘

115 OJT 創新專案

數位營運處 115 部門的 OJT 專案，目標是「提出可驗證的收入假設，設計最小實驗證明有人願意付費」。聚焦 AI + 高中學習市場，以龍騰 RAG 學科知識庫為核心。

我的位置

  • A 組：耀弘、亜旻、于庭、圓一、志瑋、振維
  • 預算：NT$6,000
  • 時間：2026/2 ~ 6 月，每人每月 1-2 天
  • 績效連結：Q1/Q2 自評表需簡述貢獻

組員能力地圖

成員角色/能力OJT 可發揮的方向
耀弘YouTube 影片產製（拍攝+剪輯+編導全包）內容通路、產品影片、Landing Page 影片
亜旻數據分析師，寫 Python數據驗證、用戶行為分析、付費訊號追蹤
于庭行銷客群觸達、Landing Page、通路策略
圓一待確認—
振維AI 首席科學家，DevOps + AI + Scrum Manager，實際帶領開發小組技術架構、AI 整合、專案管理
志瑋（我）全端 + AI Agent + Claude Code 自動化快速 MVP、Agentic Flow、Demo 實作

這組幾乎涵蓋「概念→產品→推廣」完整鏈條。耀弘做內容、于庭做行銷、亜旻做數據、振維帶架構、我做 MVP。

⚠️ AI 品質的結構性劣勢（2/23 教訓）

核心警告：付費 AI 產品的回答品質結構性地輸給免費工具

WriteAhead 品質測試的實證發現：付費產品串 API 為了成本只能用弱模型，結果核心功能（批閱品質）輸給 Google 首頁免費的 AI Mode。這個結構性問題同樣適用於 OJT。

OJT 產品如果主打「我們的 AI 回答/診斷/出題比較好」，用戶打開 Google AI 就能免費拿到品質更高的結果。因此：

  1. AI 回答品質是基本門檻，不是賣點 — 確保不比免費工具差即可，不要把差異化押在這裡
  2. 差異化必須在「單次 AI 回答」之外 — 學習歷程追蹤、弱點地圖、過程分析報告、教師端報表、課綱精確對齊
  3. 驗證付費訊號時，問「用戶拿 Google AI 做不到什麼」 — 而非「我們的 AI 答得好不好」
  4. Phase 0 加入 AI 品質基準測試 — 用四類測試案例（正常/離題/矛盾/缺失）測試知識庫 AI，跟 ChatGPT 對比，確保品質至少及格

策略思考（2/21）

核心轉向：不只是贏 OJT 競賽，而是利用這次機會做出實際能改變整個部門未來的東西。

  • 正一說最好用 RAG 知識庫，但態度似乎有彈性。為部門爭取最大利益應該是最高優先
  • RAG 知識庫「僅掛名」是評比一票否決條件（佔 25%），但如果正一本人態度彈性，規則就是活的
  • 開工策略：不開空手會。先做出具體提案或 prototype，開會時直接展示讓大家反應。先跟振維 1 on 1 對齊方向，再帶到全組
  • 開工策略（修正）：不獨斷決定方向。準備一份 prototype 選單（每個方向列：痛點、技術可行性、預估時間、風險），搭配現有 Physics KB demo 展示技術基底，讓組員在有具象感的前提下共同選擇方向。沒有「老闆」的團隊中，掌控選項範圍但把選擇權交給團隊，是更好的領導方式

Prototype 方向分析（2/22）

成本關鍵決策

蘇格拉底式引導需要 Opus 等級的深度推理才能做好（/udemy-tutor 的經驗），但 Opus API 成本太高無法商用。因此 prototype 方向應選 Haiku/Sonnet 就能做好的結構化任務：分類、檢索、模板生成。

Prototype 階段可用 Opus demo 最佳效果，但商用產品必須能用便宜模型跑。OJT 評的是「有沒有人願意付費」不是「毛利率多少」。

推薦方向

AI 備課引擎（首選）

  • 付費者：老師 / 補習班
  • 痛點：備課耗時（教案、練習題、考卷）
  • 功能：輸入科目+章節 → 自動產出教案大綱、暖身問題、課堂練習、回家作業、段考題
  • 技術：RAG 檢索 + 模板生成，Haiku 即可
  • 龍騰角度：從「賣教師手冊」升級為「賣 AI 備課服務」— 商業模式層級跳躍
  • 分工：振維架 AI pipeline、志瑋做 MVP、亜旻追蹤使用數據、于庭找補習班試用、耀弘拍 demo 影片

AI 錯題分析器（備選）

  • 付費者：家長
  • 痛點：「我小孩哪裡不會」的焦慮
  • 功能：上傳錯題 → OCR + 知識點辨識 → RAG 拉相關內容 → 生成同類型練習題 + 弱點地圖
  • 技術：分類 + 檢索 + 生成，Sonnet 即可

知識庫擴展策略

目前只有高中物理第一章。 Ch1 v2 已完成（342 篇：concepts 52, scientists 60, formulas 10, apps 5, questions 210, MOC 4），verify 0 errors / 0 warnings。Pipeline 優化完成（物理知識庫 Pipeline 優化專案 Phase 0-5），可快速擴展到新章節。

Prototype 不需要覆蓋整個年級，但一章太窄。目標：3-4 個跨類型章節（如力學+熱學+波動），足以證明系統能處理不同類型的知識。Phase 6（Ch2 擴展）待做。

知識庫架構優化

現有 md 原子筆記 + MOC 結構不需要砍掉重練，但需要針對 AI 檢索優化：

  1. Frontmatter 標準化 ✅ Pipeline 優化 Phase 1 完成：加 chapter、topic_path、context_header（Contextual Retrieval），66 個三層路徑
  2. 筆記自足性 ✅ 模板 + 生成 prompt 已加入自足性原則，每篇筆記不依賴 wikilink 就能被 AI 理解
  3. MOC 當路由層 ✅ Agent 第一輪搜 MOC → 提取 topic_path → 後續搜尋限定範圍
  4. ✅ Hybrid Search：BM25 + vsearch 並行 → RRF fusion → LLM re-rank（Pipeline Phase 3）
  5. ✅ Metadata Pre-filter：chapter/topic_path filter → 7,500 篇先篩到 ~500 再語意搜尋
  6. ✅ 自動化校驗：verify.sh 五項檢查（LaTeX / frontmatter / wikilink / tag / 重複）

時程與檢核

階段時間重點狀態
報告日3/4（三）部門 AI 工具展示 + OJT 技術路線 demo準備中
檢核 13 月底收入假設成形、商業模式卡 v1進行中
檢核 24-5 月驗證付費訊號待開始
檢核 36 月下旬決選 Demo Day、MVP 決策包待開始

3/4 報告日：Matt 主講（1 小時），聽眾正一 + Enoch。展示已在跑的系統：Team Bot（@lungtengaibot）+ 物理知識庫 Demo（physics-kb.fly.dev）+ Landing Page（knowbase-landing.pages.dev）。報告準備見 Claude Code 部門導入提案會議。

Phase 0 待辦：開局（2 月）

目標：讓 A 組在第一次正式會議前，每個人都有底，會議時能直接做決策而不是從零開始。

知識庫

  • Survey 目前 RAG 技術現況（Graph RAG、傳統 RAG、各方案在符號密集科目的適配性）→ qmd 方案已完整驗證，Pipeline 優化 Phase 0-5 完成
  • 取得 RAG 知識庫的存取方式（API / 直接連資料庫？）與操作權限 — ⚠️ 龍騰 RAG 未接觸，正一/Enoch 尚未提供
  • 實際測試：餵入不同科目、不同題型，記錄回應品質 → Physics KB 6 題型全通過（概念/人物/公式/跨概念/歷史/開放）
  • 釐清限制：哪些科目強、哪些弱？延遲多少？成本怎麼算？ → 每次問答 3×Haiku + 1×Sonnet ≈ $0.01，grep 即時 / hybrid ~5s
  • 整理成一頁「知識庫能力卡」，讓全組有共同認知 — 3/4 報告日可用 Physics KB Demo 替代

不先碰過知識庫，後面所有討論都是空想。 知識庫已碰過（自建 342 篇 + Agent CLI + Web Demo），但龍騰 RAG 仍未接觸。目前路線是「用自建知識庫驗證技術可行性 → 報告日展示 → 組會決定是否接入龍騰 RAG」。

商業方向

  • 第一次組會：用策略儀表板三問對齊方向（見 策略儀表板三問）
  • 組內選定 1 個主付費者（見 客群分析）
  • 寫出一句話描述付費者痛點（例：「高中生家長擔心孩子段考成績但不知道怎麼幫」）

技術路線

  • [~] 根據知識庫實測結果，選 1-2 個最可行的核心功能（見 功能定位）— Agent CLI 驗證「AI 問答 + 蘇格拉底引導 + 出題」可行，待組會確認方向
  • [~] 確認功能是「因為有知識庫才能做，沒有就做不到」— 知識庫提供精確學科內容 + 連結遍歷，ChatGPT 做不到課綱精準對齊
  • 比較 RAG vs QMD 三層搜尋的技術可行性 → 實驗：qmd 原子化筆記方案驗證（物理 Ch1）
    • ⚠️ 此實驗的 Graph RAG 比較欄為推論非實測，需做以下補充驗證：
  • QMD vs Graph RAG 實測比較：用同一份物理 Ch1 內容建一個 Graph RAG，跑同樣四個場景測試（學生問概念/解題、老師搜題/出題），以實際數據比較品質、建構時間、維護成本 — ⚠️ 自建 QMD 已驗證到 342 篇，Graph RAG 仍未實測
  • 知識庫規模化新增測試：Pipeline 優化 Phase 0-5 完成（物理知識庫 Pipeline 優化專案），Ch1 v2 重寫 342 篇 verify 0 errors。三層生成 SOP + verify.sh 自動化校驗 + hybrid search + metadata pre-filter → 可從 300 擴展到 7,500 篇
  • 實作 Agentic Flow CLI：自動化「搜尋→讀筆記→追蹤連結→LLM 回答」流程 → 物理知識庫專案#Agentic Flow CLI 實作

AI 品質基準測試

  • 設計四類測試案例（正常/離題/矛盾/缺失），針對物理知識庫 AI 問答
  • 同一組問題分別餵給知識庫 AI 和 ChatGPT / Google AI，逐項對比
  • 整理成品質對比報告（可參考 WriteAhead AI 批閱品質 vs Google AI 對比觀察 的測試框架）
  • 確認知識庫 AI 品質至少不劣於免費工具，識別需要補強的項目

驗證實驗：Landing Page 先行，過門檻才做 MVP

策略：用 Landing Page 驗證「有沒有人想買」，不需要先做出產品。零成本，幾小時可上線。過了門檻再投入做 MVP，沒過就換方向再測。NT$6,000 預算留給過門檻後的 MVP 開發。

詳見 付費訊號驗證法、Landing Page 的八角框架設計模式。

Step 1：定假設與門檻

  • 草擬至少 2 個收入假設（格式：「做___，接觸___人，% 願付 NT$，月收 NT$___」）
  • 每個假設標註最大風險
  • 為每個假設定門檻（例：曝光 100 人，≥15 人預約 → Go）

現有假設草案：

假設付費者定價Landing Page CTA
家長願付月費用雙模式 AI 家教家長NT$299/月預約試用
老師願付費看解題過程分析報告老師NT$99/月/班預約試用

Step 2：做 Landing Page（一個假設一頁）

  • 每個假設各做一個 Landing Page（數據才乾淨）→ 2/25 完成物理知識庫 Landing Page
  • 頁面上寫定價（訪客看到價格仍願意預約才是真正的付費訊號）— 目前 LP 未含定價
  • 用八角框架設計頁面：CD1 標題喚起使命 → CD5 社交認證 → CD6 稀缺 + CD8 損失推 CTA（白帽開場黑帽收尾）
  • CTA 表單包含身份欄位（家長/老師/學生/其他）— ⚠️ 尚缺 CTA 追蹤邏輯
  • 各管道用 UTM 追蹤（?utm_source=youtube / ltrust / teacher）
  • 工具：Pencil.dev 生成 直接用 Claude Code 寫 HTML + CSS + Cloudflare Pages 部署

Step 3：曝光

  • [~] 確認曝光管道：LTrust 平台、立亨教育界人脈、耀弘/圓一 YouTube 影片描述欄 — 2/25 已分享給大P、小任、立亨（小規模同事反饋），正式曝光待組會後
  • YouTube 管道注意：觀眾是財金/生活類，不是目標客群，UTM 分開追蹤避免污染訊號

Step 4：看數據決定

  • 過門檻 → 做 MVP
  • 沒過門檻 → 訪談預約者（他們是最有價值的訪談對象：「為什麼有興趣？期待什麼功能？」），用回饋調整方向，再做下一輪 Landing Page

進展日誌

2/26 — 利亨「數據才是產品」洞見

核心觀點（早餐討論 08:44-08:54）：龍騰 50 年教材龍頭但幾乎零數據蒐集。RAG 知識庫的真正價值可能不在直接銷售 AI 功能，而在透過使用行為蒐集教育數據。免費不是壞事——IG/YouTube/FB 靠數據變現，freemium 先養依附再收費。

對專案方向的影響：

待組會討論：是否調整商模假設，從「家長/老師付費」轉向「免費使用 + 行為數據蒐集 + 數據報告賣給學校/教育局」。

2/25 — Landing Page 上線 + Team Bot 就緒 + Pipeline 優化完成

Landing Page：物理知識庫產品驗證 Landing Page 完成並部署。

  • 暗色版：knowbase-landing.pages.dev
  • 亮色版：knowbase-landing-light.pages.dev
  • 內容結構：Header → Hero（AI 助教定位）→ How It Works → Core Features → Social Proof → Final CTA
  • 同事反饋：小任「很棒欸」、立亨正面。小任反饋老師偏好白底
  • ⚠️ 尚缺：CTA 追蹤邏輯（頁面曝光 + 點擊次數）、定價資訊、UTM 追蹤

Team Bot 就緒：部門 AI 工具導入專案 Phase 0 A.1-A.5 完成。

  • 獨立 bot @lungtengaibot，systemd service，角色系統（admin/dev/pm）
  • 部門知識庫 ~/team-zettelkasten/，Lung-Teng 11 repos clone
  • 先導期成員已加入（Matt + Enoch admin、卜仁 dev、正一 pm）
  • 3/4 報告日已排定，1 小時 Matt 主講

Pipeline 優化完成：物理知識庫 Pipeline 優化專案 Phase 0-5 全完成。

  • Ch1 v2 重寫：307 → 342 篇（concepts 52, scientists 60, formulas 10, apps 5, questions 210, MOC 4）
  • verify 0 errors / 0 warnings / 21 broken links（全為跨章節概念）
  • 新增能力：hybrid search（BM25 + vsearch + RRF）、metadata pre-filter、LLM re-rank、自動化校驗
  • Phase 6（Ch2 擴展）待做——OJT 3 月底檢核需要 3-4 章

對 OJT 的意義：

  1. 技術路線已從概念驗證走到 production-ready pipeline，3/4 報告可以 demo 完整系統
  2. Landing Page 讓 A 組能具象理解「產品長什麼樣」，不再只是技術投影片
  3. Team Bot 證明 AI 工具已在部門實際運作，不是紙上談兵

2/23 — 部門 AI 工具導入提案 + 報告日排定

Enoch 主動拉高提案層級，從原本「Claude Code 報告給正一」升級為「GCP 部署部門級 zettelkasten + Claude Code + Telegram」。安排 3/4（三）一小時會議報告。

組織影響：OJT 不再是 A 組的獨立行動——部門 AI 導入和 OJT 產品驗證形成兩條互相支持的線。Team Bot 是「部門先用 AI」，OJT 是「用 AI 做產品」。

2/7-2/22 — 技術基建期

進度主要在接案和技術基建，OJT 無直接推進，但多項成果可直接用於 OJT：

  • WriteAhead vs Google AI 品質報告（2/23 完成）：實測證實 付費 AI 產品的回答品質結構性地輸給免費工具，報告已給正一和小任
  • Pencil Landing Page 工具驗證（2/8-2/24）：Pencil MCP + Claude Code 可快速設計 Landing Page，Pencil Landing Page Demo 專案 Phase 0-1.5 完成
  • 接案系統成熟：goodnight 自動掃描穩定運作（FB 社團 + Tasker + Pro360 + PTT），接案基建對 OJT 無直接影響但分散了時間
  • InBody 數據（2/10、2/25）：非 OJT 相關，但減脂專案與接案同時進行的時間壓力需注意

2/6 — Physics KB Demo 上線 Fly.io

將 物理知識庫 Demo 部署到 Fly.io（東京機房），加密碼牆和限流。

線上 Demo：https://physics-kb.fly.dev/

技術細節：

  • Docker 化（oven/bun:1），搜尋策略固定 grep（不需 qmd）
  • 密碼牆：DEMO_PASSWORD 透過 Fly secrets 注入，sessionStorage 存密碼
  • 限流：per-IP 每分鐘 10 次 /api/ask
  • 自動休眠：idle 時 machine 停止，首次請求喚醒

對 OJT 的意義：Demo 可以直接分享 URL 給組員和立亨試用，不需要本地環境。3 月底檢核時可作為技術驗證的展示入口。

2/5 — Agentic Flow CLI 實作完成

完成 物理知識庫專案 的 Agentic Flow CLI 工具（~/Documents/physics-kb/agent/），將手動查詢流程自動化為獨立 CLI。

架構：Question → Haiku 拆關鍵字 → Search → 讀筆記 → Judge（context 夠嗎？）→ 追蹤 連結 → Generate → Verify → 輸出

關鍵發現：

  • 4 次 LLM 呼叫（3× Haiku + 1× Sonnet），每次問答 < $0.01
  • Verify 必須用 Sonnet（Haiku 判斷力不足，會放過混淆錯誤）
  • 跨概念題目品質取決於筆記本身的關聯描述深度，agent 無法補救筆記的缺口
  • grep 作為預設搜尋策略足夠穩定，qmd search/vsearch 作為可切換選項

對 OJT 的意義：技術上驗證了「原子化筆記 + 連結 遍歷 + LLM」的 agentic flow 可行，成本極低。若接入龍騰知識庫，同架構可直接復用。

2/5 — SEL 商模方向（立亨洞見）

立亨（教育界人脈）提供的市場資訊觸發了新的商模方向。詳見 AI 讓正確答案商品化，解題過程成為新價值。

市場缺口：SEL 是教育界趨勢，PISA 從「正確答案」轉向「解題過程」評量，但出版社不知道怎麼做成商品。龍騰本身就是出版社——A 組如果能率先把 SEL 做成產品，就是內部創新。

商模方向：

  1. 雙模式 AI 家教（freemium）

    • 免費：每月有限激戰模式（直接給答案）
    • 付費：無限蘇格拉底+激戰自由切換
    • 技術上只需切換 generate prompt，pipeline 不變

  2. 解題過程分析報告

    • Agentic flow 天然有過程數據：學生問了什麼、在哪卡住、被引導幾次
    • 包裝成家長報告或教師儀表板 → 付費功能
    • 對標 PISA 的過程評量軟體，台灣高中版無競品

收入假設草案：

假設付費者定價驗證方式
家長願付月費讓孩子用雙模式 AI 家教家長NT$299/月Landing page + 預約試用
老師願付費看班級解題過程分析報告老師/學校NT$99/月/班找立亨介紹老師面談

與八角框架的接點：蘇格拉底模式直接補強現有產品最弱的 CD3（創造力）和 CD7（好奇心）——學生不是被動接收答案，而是被引導自己發現答案。

驗證管道：立亨本人有教育界人脈，可直接幫忙找老師做付費意願訪談。

2/4 — 部門會議確認 + 技術路線初探

部門會議（10:00-11:10）：OJT 正式改制為三組各自構想商模並驗證。會後完成本專案筆記初版並部署到 Cloudflare Pages 分享給組員。

技術路線討論（下班電梯，與卜＋以諾）：

議題現狀
RAG 知識庫尚未建置（「根本還沒做出來」）
技術方案以諾提議 Graph RAG（LLM 協助搭建知識圖譜）
硬體資源新創已購 server，4 張 AMD 顯卡未使用，可做 local 部署
科目適配非所有科目適合同一 RAG 技術，需分科研究
前提必須實測通過才有意義，否則後續免談

策略思考（散步途中）：

  1. MVP 聚焦：只選單一非文本科目（數學/物理）。符號密集型 RAG 較少人做（尤其台灣），若能解決就是高 CP 值突破口
  2. 替代路線：MD + QMD 三層搜尋取代 RAG。副產物為知識圖譜，需與 RAG 做性能比較（精準度/延遲/成本），直覺上可能不比 RAG 差
  3. OpenClaw 架構復用：解析 codebase 後將架構移植到 OJT，或取精華用 LangGraph 重寫

參考框架

策略儀表板三問

八角框架策略儀表板：面對任何陌生問題，永遠從三個問題開始：

  1. 商業指標是什麼？ — OJT 的指標很明確：付費訊號強度（佔評比 50%）。一切設計圍繞「怎麼讓人掏錢」
  2. 玩家（付費者）是誰？ — 必須選一個主付費者。從「誰最痛、最願意付錢」而非「誰最多」來思考
  3. 期望行為是什麼？ — 付費者要做出什麼具體動作？（購買、訂閱、預約試用）

某客戶光是對齊商業指標就花了兩週，但認為這個練習本身值 $10-20 萬，因為它揭露了高層從未就優先級達成共識。A 組 6 個人也一樣——第一次會議如果沒對齊，後面全是各說各話。

客群分析

客群付費意願觸達難度驗證速度備註
學生低（口袋淺）低（有 LTrust）快量大但客單價低
家長高（為孩子花錢）中中痛點明確：成績焦慮
老師中中慢採購決策慢
學校高高慢B2B，超出 OJT 時間範圍
補教高高慢需要行業人脈

功能定位

知識庫不能只是「掛名」（一票否決條件），必須是交付核心。可選方向：

功能說明知識庫角色
AI 診斷學生做題 → AI 判斷弱點在哪提供學科知識做精準診斷
AI 出題根據弱點自動生成練習題提供題庫素材與知識結構
AI 解說學生看不懂的地方即時解釋提供正確且結構化的學科解說
AI 回饋批改後給出改進建議確保回饋內容學科正確性
蘇格拉底引導不直接給答案，用提問引導學生自己推導提供概念脈絡，讓 LLM 設計引導式問題而非直接解答。技術上僅需切換 generate prompt（physics-kb agentic flow 的搜尋/Judge/連結追蹤 pipeline 不變）。學界趨勢，立亨建議
解題過程分析記錄學生解題路徑（卡點、引導次數、概念盲區），打包成報告知識庫提供概念結構，讓 AI 能精確標記學生卡在哪個概念節點。對標 PISA 過程評量方向。詳見 AI 讓正確答案商品化，解題過程成為新價值

八角框架優勢

已做過 WriteAhead Web 八角框架遊戲化分析 和 LTutor Web 八角框架遊戲化分析，發現現有產品的共同問題：

  1. 都只有行為迴圈，沒有遊戲迴圈 — 獎勵不具加速器性質，用戶完成動作後沒有理由「自然且更強地回到起點」
  2. 都過度依賴 CD6（稀缺性）作為營收驅動 — 高頻學習行為不應以黑帽為主驅動力
  3. 都缺乏 CD3（創造力）和 CD7（好奇心） — 最持久的動機來源反而最弱

OJT 中的應用：

連結

關係圖譜