Hariprasad Sudharshan · 36 分 11 秒

這支影片在講：能做出來，還不等於有理由被選中

模型、coding agent 與熟悉的問題，會把許多人推向相似產品。Hariprasad Sudharshan 把這個容易重合的起點叫做「中位數」：能快速做出 demo 是能力，找到別人無法輕易複製的問題、分發與經濟性，才是產品工作。

AI Engineer · 2026-10-15 · Video ID: 0JZy5AuuQzc

01 / 問題

同一套工具，會產生相似答案

相同模型、框架與顯而易見的需求，足以讓獨立開發者自然收斂到類似 calculator 或內部工具；相似不必代表抄襲。

02 / 反轉

Demo 不是護城河

更快的交付可以帶來有用軟體與學習，但「已經能跑」不足以證明產品有持久優勢，更不是商業成果的因果證據。

03 / 解法

預先編列新穎性預算

在開工前點名一個只有你打算做到的差異；把它放進 roadmap，像其他成本一樣持續檢查是否真的能被交付與驗證。

Signals

這支 36 分鐘分享，把差異化拆成四個可討論的訊號

Build time2 年講者從一次長期獨力開發，發現市場上已有功能相近的工具，反思「做出來」的意義。

Layers3 層模型能力、harness，以及顧客實際收到的產品；它們不能被當作同一件事。

Before build1 個差異開工前明確寫下最獨特的價值，避免只把現成技術疊成另一次中位數。

Leader check3 問誰已解過？我們有何不同？如何接觸使用者？用來判斷 demo 是否值得繼續投資。

Core story

把「先做再說」改成三個產品判斷

先搜尋，再開 coding agent

講者反思 build-first reflex：一看到問題就直接叫 agent 寫，可能跳過既有解法、替代品與真正使用情境。先確認市場已經怎麼解，才能知道自己的差異不是功能清單中的小變形。

把模型、harness 與產品分開估

租用或開放的模型能力讓起步很快，但顧客買到的還包括工作流、資料、可靠性、整合與支援。若只把模型能力當成產品優勢，能力排行榜一變，主張也會跟著失效。

讓差異能走到使用者面前

差異化不只在技術。領導者應同時問：競品已解決什麼、團隊掌握哪些難以取得的條件、產品要經由哪條分發路徑接觸使用者。沒有分發，功能再不同也未必形成優勢。

Trade-offs

在「可快速製作」與「值得投資」之間，補上這些成本

現成模型 vs. 自有條件模型讓團隊快速跨過起跑線；真正需要投資的是專有資料、工作流理解、信任關係或其他競爭者不易取得的條件。

自行部署權重 vs. 購買推論影片後段以 calculator 為例，提醒比較企業內部跑 open weights 與採購 inference 時，不能只看單次價格；還要算利用率與從權重到 token 的整段基礎設施。

功能速度 vs. 新穎性驗證更快寫出功能適合探索，但每一輪都要回到 novelty budget：這個差異有沒有被實作、測到、被使用者感受到，而非只增加輸出量。

個人反思 vs. 普遍定律這是講者的建造歷程與產品判斷框架，不是受控研究或公開商業成果；適合當提問工具，不該外推為所有產品的預測。

Checklist

立項前，用五個問題把「中位數」留在原地

已經有哪些人解過這個問題？先找同類產品、替代流程與使用者目前的 workaround；把未知的市場狀況寫下來。

我們唯一要做到的差異是什麼？用一句可反駁的話命名它，而不是列一串 feature；接著把它放進 roadmap 與驗證節點。

優勢位在模型、harness 還是產品？分層盤點，避免把可租用的模型能力誤當成顧客願意付費的產品防線。

使用者會從哪裡遇到它？寫出實際分發路徑與接觸成本；如果答案只有「做完後再想」，就不是完整的產品計畫。

這個差異的全成本與經濟性如何？比較自營 open weights 與外購 inference 時，連同利用率、運維與中間基礎設施一起估，別只比較 token 單價。

Source video

原影片與章節

0:00 決定性軟體與日常 · 3:54 租用模型改變開發 · 10:28 模型、harness、產品 · 12:09 中位數與收斂解法 · 18:03 build-first reflex · 23:51 novelty budget · 28:30 領導者的三個問題 · 30:45 open weights 與 inference 成本 · YouTube 原始來源