I built two AI tools for yoga teachers. Then I discovered the real problem wasn't about tools at all. It was about the gap between finishing teacher training and actually standing in front of a class. 我為瑜伽老師做了兩個 AI 工具。然後發現真正的問題根本不是工具,而是師培結業到真正站上去教課之間的那段空白。
I built these tools to practice teaching. But using my own product, I realized they solved technique while the real blockers went untouched: identity, confidence, and the social cost of asking people to show up. 我做這些工具是為了練習教課。但用自己的產品後發現,它們解決了技術問題,真正的障礙卻沒碰到:身份認同、信心,以及開口邀人來上課的社交成本。
Post-YTT struggles aren't different problems for different people. They're the same person at three moments: 師培後的困境不是不同人的不同問題,而是同一個人在三個不同時刻:
| Moment | 階段 | Feeling | 感受 | What They Need | 需要的 |
|---|---|---|---|---|---|
| 1. "Am I a teacher?" | 1.「我算老師嗎?」 | Identity limbo after YTT | 師培後的身份空白 | Validation, a mirror | 肯定、一面鏡子 |
| 2. "How do I start?" | 2.「我怎麼開始?」 | Can teach but can't get going | 會教但跨不出去 | Lower barriers, invitations | 降低門檻、邀請機制 |
| 3. "What now?"3.「然後呢?」Cut捨棄 | Teaching but no career path在教但沒有職涯路徑 | Different persona, different product不同的人物、不同的產品 |
I focused on Moments 1 and 2. Moment 3 serves a different persona with different needs. Trying to solve all three would dilute the product. 我聚焦在第 1 和第 2 階段。第 3 階段服務的是不同人物、不同需求。三個都想解決只會稀釋產品。
After YTT, the gap between knowing poses and teaching a class has too many steps. This tool compresses them: discover your teaching style, generate a class plan in 15 minutes, and practice your verbal cues with AI feedback across five dimensions. 師培結業後,從「我會體式」到「我可以教一堂課」中間有太多步驟。這個工具壓縮它們:探索你的教學風格、15 分鐘生成課程計畫、用 AI 回饋練習五個維度的口令引導。
A 75-minute class recording sits in your phone. You never revisit it. The teacher's cues fade within a week. 75 分鐘的課堂錄音躺在手機裡,你不會回去聽。老師的引導一週內就忘了。
This tool turns that recording into structured notes (synced to Notion), a 10-minute follow-along practice guide, shareable content cards, and auto-edited reels. 這個工具把錄音變成:同步到 Notion 的結構化筆記、10 分鐘跟練音檔、可分享的內容卡片、自動剪輯的短影片。
Same domain, two tools, one lesson: the interesting product decisions aren't technical. They're about judgment. When to automate, when to leave room for the human. When to ship with a disclaimer instead of chasing perfection. 同一個領域、兩個工具、一個教訓:有趣的產品決策不是技術問題,而是判斷。什麼時候該自動化、什麼時候該留空間給人。什麼時候帶著免責聲明上線,而不是追求完美。
Being both builder and user meant I could feel when something was off before articulating why. I designed a "30-Day Teaching Challenge," then killed it because it demands identity commitment from someone who hasn't decided they're a teacher yet. That instinct, feeling what the user would feel before they tell you, is the same loop that made products better at Dcard: build, use, notice the gap, rebuild. 同時身為開發者和使用者,讓我能在說出原因前就感覺到哪裡不對。我設計了「30 天教學挑戰」,然後砍了,因為它要求一個還沒決定自己是老師的人做出身份承諾。這個直覺,在使用者告訴你之前就感受到他們的感覺,跟在 Dcard 做產品時一模一樣的迴圈:做、用、發現落差、重做。
Questions about these projects or how I think about product? 對這些專案或我的產品思維有任何問題?