Agent: 部落格寫手 (blog-writer)
Confidence: 65%
Cost: $0.4101
Duration: 3m 36s
Task ID: eabd0b3a-895c-4132-ba2b-61ab5df04837
好的，我已經收到完整的素材。現在讓我開始撰寫部落格文章。
根據素材和寫作指示，我會創作一篇「技術 + 商業實戰分析」的文章，主題是「如何讓 Telegram Bot 開始收錢」。
📝 完整部落格文章
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
| ---
title: 讓 Telegram Bot 開始收錢：Stars × USDT 雙軌支付實戰
date: 2026-02-25 09:30:00
tags:
- Telegram
- Stars
- USDT
- 支付整合
- AI Agent
- 商業化
categories:
- 技術實戰
---
我最近在思考一個問題：AI Agent 做得再好，如果不能收錢，那它就只是個昂貴的玩具。我們的 Telegram Bot 已經能自動寫文章、回答問題、執行任務，但要真正變成一門生意，得先解決「怎麼收錢」這個最基本的問題。
於是我開始研究 Telegram 的支付生態，發現了一條很有意思的路：**Telegram Stars × USDT 雙軌支付架構**。這不只是技術整合，更是對兩種用戶群體的精準服務——休閒用戶要的是簡單，幣圈用戶要的是掌控權。
<!-- more -->
## Telegram Stars：被低估的支付基礎設施
2023 年 11 月，Telegram 上線了官方虛擬貨幣 **Telegram Stars**（1 Star ≈ $0.01 USD）。這不是什麼實驗性功能，而是一套完整的商務支付系統：支援訂閱、禮物、廣告分潤，甚至有官方 API `sendInvoice()` 讓開發者直接在 Bot 內建立付款流程。
最吸引我的是這個：**無需第三方支付閘道**。
傳統的支付整合，你得去申請 Stripe、PayPal，填一堆表格、驗證身份、等審核通過。而 Telegram Stars 不需要這些——只要你有個 Bot，就能立刻開始收錢。用戶在 Telegram 內完成支付，你收到 webhook，解鎖服務，就這麼簡單。
### 實際怎麼用？sendInvoice 流程拆解
讓我用具體的程式碼流程說明。假設我想賣一個「AI 分析訂閱」，每月 100 Stars（約 $1 USD）：
```javascript
// 1. Bot 調用 sendInvoice
bot.api.sendInvoice(chatId, {
title: "AI 分析訂閱（月費）",
description: "每日市場分析 + 即時問答",
payload: "subscription_monthly_tier1",
provider_token: "", // 空字串 = 使用 Telegram Stars
currency: "XTR", // XTR = Telegram Stars
prices: [{ label: "月費", amount: 100 }] // 100 Stars
});
// 2. 用戶收到付款通知，在 Telegram 內完成支付
// 3. Bot 接收 pre_checkout_query（付款前驗證）
bot.on("pre_checkout_query", async (ctx) => {
// 可以在這裡檢查用戶資格、庫存等
await ctx.answerPreCheckoutQuery(true);
});
// 4. Bot 接收 successful_payment（付款成功）
bot.on("message:successful_payment", async (ctx) => {
const userId = ctx.from.id;
const payload = ctx.message.successful_payment.invoice_payload;
// 寫入 Cloudflare D1 記錄訂閱
await db.prepare(`
INSERT INTO subscriptions (user_id, plan, start_date, status)
VALUES (?, ?, datetime('now'), 'active')
`).bind(userId, payload).run();
await ctx.reply("✅ 訂閱成功！每日分析已啟用");
});
|
整個流程完全在 Telegram 內完成，用戶不需要跳出 app、不需要輸入信用卡、不需要擔心釣魚網站。這種零摩擦支付的轉化率，遠高於傳統的「跳轉到支付頁面 → 填表 → 等確認」。
但是⋯⋯幣圈用戶不買單
當我把這個方案分享給幾個幣圈朋友時，他們的第一反應是：「為什麼不直接收 USDT？」
這背後有三個理由：
- 非托管信仰：幣圈用戶習慣自己掌控錢包，不想把錢「鎖在 Telegram 裡」
- 跨境支付：USDT 沒有國界限制，不需要擔心銀行封鎖或匯率波動
- 隱私需求：USDT 轉帳可以做到相對匿名（尤其是 TRC-20 鏈上）
而 Telegram Stars 有個致命限制：目前沒有官方的「Stars → 法幣/USDT」兌換 API。你收到的 Stars，只能用來在 Telegram 生態內消費（買廣告、送禮物），不能直接提現成 USDT 或美元。
這就像你開了一家店，只接受「店內通用券」——對忠實客戶來說沒問題,但對想一次性購買的人來說就很彆扭。
雙軌架構：Stars 為主，USDT 為輔
所以我的結論是：不要二選一，而是雙軌並行。
1
2
3
4
5
6
7
8
9
10
| 用戶選擇支付方式
├─ Telegram Stars（推薦給一般用戶）
│ ├─ 一鍵支付，零摩擦
│ ├─ Telegram 抽 30%，我得 70%
│ └─ 適合月費 $1-10 的輕量訂閱
│
└─ USDT（推薦給幣圈用戶）
├─ 用戶主動轉帳到指定地址
├─ 我收到 100% 金額（無抽成）
└─ 適合年費 $100+ 的高價訂閱
|
Stars 作主軌：80% 轉化率來自這裡
對於大部分休閒用戶，他們要的是「快」——看到服務、點擊訂閱、付款完成，整個流程不超過 30 秒。Telegram Stars 完美符合這個需求。
雖然 Telegram 會抽 30%，但這個「稅」換來的是：
- 免費的支付基礎設施（不用自己架伺服器監聽區塊鏈）
- 免費的爭議處理（Telegram 官方會處理退款糾紛）
- 免費的信任背書（用戶看到「Telegram 官方支付」會更放心）
如果你賣的是 $5/月的訂閱,扣掉 30% 還有 $3.5，這個毛利率對 SaaS 來說已經很健康了（軟體成本幾乎為零）。
USDT 作輔軌：20% 核心用戶的堅持
但對於那 20% 的幣圈核心用戶，他們願意為了「零抽成 + 非托管」而多花一點時間。這時候你可以提供 USDT 支付選項：
1
2
3
4
5
6
7
8
9
10
11
12
|
bot.command("pay_usdt", async (ctx) => {
const address = "TBUCdtLW2isAsAqCsvAdyJbMtq1HngkAWh";
const amount = "10";
await ctx.reply(
`請轉帳 ${amount} USDT (TRC-20) 到：\n\n` +
`<code>${address}</code>\n\n` +
`完成後請回傳交易 hash，我會手動驗證並啟用訂閱。`,
{ parse_mode: "HTML" }
);
});
|
這裡有個關鍵設計選擇：手動驗證 vs 自動監聽區塊鏈。
- 手動驗證：用戶貼 hash，你到 Tronscan 查詢，確認後手動解鎖。成本低（不需要額外基礎設施），但不可擴展（每天超過 10 筆就會累死你）。
- 自動監聽：用 Cloudflare Worker 定期呼叫 TronGrid API，監聽指定地址的入帳事件，自動解鎖訂閱。可擴展，但需要額外開發（大概 200 行程式碼）。
我的建議是：MVP 階段先手動，有 50 個付費用戶後再自動化。不要為了「技術完美」而拖延上線時間——先驗證需求,再優化流程。
30% 抽成，值得嗎？
這是最多人問我的問題。我的答案是：看你賣什麼。
如果你賣的是「一次性內容」（比如一份 PDF 報告），30% 的抽成確實很痛。假設你賣 $10，Telegram 拿走 $3，剩下 $7——如果製作成本是 $5，你只賺 $2，毛利率只有 20%。
但如果你賣的是「訂閱服務」（比如每月 AI 分析），30% 就變得可以接受了。因為：
- LTV（客戶終身價值）會攤平成本：用戶訂閱 12 個月，你收到 12 × $7 = $84，這時候前期的 30% 抽成就不那麼痛了
- 零摩擦帶來更高轉化率：假設 Stars 支付的轉化率是 20%，USDT 是 5%，那即使扣掉 30%，Stars 的實際營收還是更高
- 節省的時間成本：不用處理退款、不用客服解釋「為什麼還沒收到款」、不用擔心信用卡盜刷
用一個比喻：Telegram 的 30% 像是「商場租金」——你付了租金,但換來的是人流、信任、基礎設施。如果你自己開店（自建支付系統），租金是 0%，但你得自己引流、自己建信任、自己處理所有問題。
現實困難：USDT 整合沒有官方 API
理想很美好，現實很骨感。
Telegram Stars 和 USDT 之間沒有官方的轉換 API。我找到一些第三方機器人（比如 @starsbot）聲稱可以做 Stars ↔ USDT 兌換，但這些都沒有 Telegram 官方認證，安全性存疑。
這意味著，如果你想讓用戶「用 USDT 充值 Stars 額度」，你得自己實現整套邏輯：
1
2
3
4
5
6
| 1. 用戶選擇「USDT 充值」
2. Bot 生成唯一的充值地址（或要求用戶在備註欄填寫 user_id）
3. 用戶轉帳 USDT
4. Bot 監聽區塊鏈，確認收款
5. Bot 更新用戶的「Stars 額度」（這是你自己的數據庫，不是 Telegram 官方的 Stars）
6. 用戶用「你的 Stars」購買服務（實際上是你的積分系統）
|
這個架構可行，但有兩個風險：
- 用戶混淆：他們可能以為這是「真的 Telegram Stars」，結果發現不能用來買 Telegram 貼圖
- 信任問題：你得說服用戶「我的積分系統是可靠的」，這在早期很難
所以我的建議是：分開處理，不要混為一談。
- Telegram Stars = 官方支付,用於月費訂閱
- USDT = 獨立支付管道，用於年費或大額購買
兩者不互通，但各自服務不同的用戶群體。
幣圈用戶 vs 一般用戶：行為差異比你想的大
這次研究讓我意識到，支付方式本身就是一種用戶分群工具。
選擇 Telegram Stars 的用戶，通常是：
- 第一次接觸你的服務（還在試水溫）
- 偏好低承諾（月費 $5 可以隨時取消）
- 技術背景較淺（不想搞懂什麼是錢包、什麼是 TRC-20）
選擇 USDT 的用戶，通常是：
- 已經確定要長期使用（願意一次付年費）
- 重視隱私和自主權（不想留下信用卡紀錄）
- 有幣圈背景（手上本來就有 USDT，轉帳對他們來說比綁信用卡還簡單）
這兩群人的 LTV 和 churn rate 可能完全不同。假設 Stars 用戶平均訂閱 3 個月就流失，USDT 用戶平均訂閱 12 個月——那你在設計產品時，就該針對 USDT 用戶提供更深度的功能（比如 API 存取、優先支援），而不是把所有人都當成「一樣的訂閱用戶」。
下一步：立刻可做的事
如果你也在做 Telegram Bot，想開始收錢，這是我建議的最小可行路徑：
第一週：實裝 Telegram Stars 支付
- 用
sendInvoice() 建立一個最簡單的訂閱（$1/月）
- 串接
pre_checkout_query 和 successful_payment webhook
- 把訂閱記錄寫入 Cloudflare D1（或任何你用的資料庫）
- 測試完整流程：付款 → 解鎖 → 到期提醒
第二週：建立 USDT 手動驗證流程
- 提供一個 TRC-20 地址（如果沒有，去 Tronlink 開一個錢包）
- 讓用戶可以選擇「USDT 支付」，顯示轉帳指示
- 用戶貼 transaction hash，你手動到 Tronscan 查詢
- 確認後手動解鎖訂閱（用
/admin_activate_user <user_id> 之類的指令）
第三週：數據分析 + 決策
- 觀察兩種支付方式的轉化率、留存率、客單價
- 如果 USDT 用戶 < 5 個 → 先專注優化 Stars 流程
- 如果 USDT 用戶 > 20 個 → 開始開發自動監聽功能
不要一開始就想做到完美。先上線、先收到第一筆錢、先驗證需求，再來談優化。
結語：支付是服務，不是障礙
寫完這篇文章，我最大的感觸是：支付方式的選擇，本身就是產品設計的一部分。
你選擇只支援 Stars，就是在說「我服務的是一般消費者」；你選擇只支援 USDT，就是在說「我服務的是幣圈核心用戶」；你選擇雙軌並行，就是在說「我想服務兩個市場，並且願意承擔額外的複雜度」。
沒有對錯，只有適不適合你的產品定位。
對我們這個專案來說（Telegram Bot + Claude + AI 分析），我傾向雙軌架構——因為我們的用戶本來就跨兩個族群：一般創作者（想要 AI 輔助寫作）和幣圈玩家（想要自動化交易信號）。服務好這兩群人,就是我們的差異化優勢。
至於 Telegram 會不會在未來推出官方的「Stars ↔ USDT」API？我不知道。但我知道的是：不要等「完美的工具」出現才開始行動。用現有的工具、做能做的事、收能收的錢，然後在過程中持續優化。
這才是創業者（和 AI Agent）該有的姿態。
一見生財
2026 年 2 月 25 日
---
`★ Insight ─────────────────────────────────────`
**文章創作的三個關鍵決策**
1. **開頭用「問題 → 解決方案」而非「概念介紹」**：直接切入「AI Agent 不能收錢就是玩具」這個痛點，比解釋「什麼是 Telegram Stars」更能抓住讀者注意力
2. **技術細節用程式碼 + 白話文雙軌呈現**：幣圈/技術讀者想看 code，一般讀者想看比喻（「商場租金」），兩者都給才能覆蓋不同背景的人
3. **結尾回到「行動」而非「總結」**：不只說「這個方案很好」，而是給出「第一週做什麼、第二週做什麼」的具體步驟——這才是實戰文章的價值
`─────────────────────────────────────────────────`
✅ **部落格文章創作完成**
這篇文章約 3,200 字，涵蓋：
- **技術實作**：sendInvoice API 流程、webhook 處理、D1 記錄
- **商業分析**：30% 抽成的取捨、LTV vs CAC、用戶分群
- **實戰建議**：雙軌架構設計、MVP 路徑、手動 vs 自動化的時機選擇
文章已經完整輸出在上方，包含完整的 YAML front matter。系統會自動將這份內容儲存為報告。