裝置端內容生成：離線也能運作的 AI 草稿功能

電子郵件回覆建議。訊息自動完成。筆記擴展。社群貼文草稿。這些功能有一個共同模式：使用者提供簡短輸入，AI 生成更長、更精煉的輸出。

內容生成是裝置端 AI 第二自然的應用場景（僅次於分類）。它充分利用了語言模型的優勢，同時保持在行動裝置硬體的效能預算之內。

裝置端生成擅長處理的內容

短篇內容（200 字以下）

短篇生成是最佳甜蜜點。模型產生 50-200 個 token（1-3 句到一個短段落），在 3B 模型上需 2-5 秒，在 1B 模型上需 1-3 秒。

中篇內容（200-500 字）

中篇內容在 3B 模型上需 5-15 秒。當使用者明確要求草稿（點擊「草擬郵件」按鈕）時這是可接受的，但對於行內建議來說太慢了。

架構模式

一鍵草稿

最高互動率的模式。向使用者展示一個按鈕，根據上下文生成完整草稿：

[收到關於安排會議的郵件]

    [接受]  [拒絕]  [建議替代方案]

    > 點擊「接受」

    草稿：「感謝您的來信。週二下午 2 點對我來說沒問題。
    我會發送日曆邀請。期待見面。」

    [發送] [編輯]

AI 根據使用者選擇的動作生成草稿。無需打字。使用者審閱後發送（或先編輯）。

行內自動完成

使用者輸入時提供完成建議：

使用者輸入：「感謝您的更新。我會審閱...」
建議（灰色文字）：「...文件，並在週五前回覆您。」
[按 Tab 接受]

自動完成需要最低延遲。建議必須在使用者暫停後 200-300 毫秒內出現。這在旗艦裝置上使用 1B 模型可以實現（35-50 tok/s = 200 毫秒內生成 7-10 個字）。

範本擴展

使用者選擇範本，AI 填入上下文細節：

範本：「會議後跟進」
上下文：與 Sarah 討論第三季預算審查

生成結果：
「嗨 Sarah，感謝今天就第三季預算審查進行的富有成效的討論。
如我們所討論的，我將在下週三之前準備好修訂後的預測。
如果您需要其他任何資料，請隨時告知。」

實作

生成介面

// iOS：草稿生成
class DraftGenerator {
    private let model: LlamaContext

    func generateReply(
        incomingMessage: String,
        action: ReplyAction,
        onToken: @escaping (String) -> Void
    ) async -> String {
        let prompt = buildPrompt(message: incomingMessage, action: action)
        var fullResponse = ""

        await model.generate(prompt: prompt, maxTokens: 256) { token in
            fullResponse += token
            onToken(token) // 串流到 UI
        }

        return fullResponse
    }

    private func buildPrompt(message: String, action: ReplyAction) -> String {
        return """
        Write a brief reply to this message. Action: \(action.rawValue)

        Message: \(message)

        Reply:
        """
    }
}

多個建議

生成 2-3 個替代草稿讓使用者選擇：

// Android：生成多個建議
suspend fun generateSuggestions(
    context: String,
    count: Int = 3
): List<String> {
    return (1..count).map {
        model.generate(
            prompt = buildSuggestionPrompt(context),
            maxTokens = 64,
            temperature = 0.8f // 較高溫度以增加多樣性
        )
    }
}

使用溫度 0.7-0.9 來增加建議之間的多樣性。較低溫度（0.1-0.3）適用於需要一致、高品質草稿的情況。

上下文管理

好的草稿需要好的上下文。提供模型以下資訊：

• 正在回覆的內容（郵件、訊息、貼文）
• 使用者的動作或意圖（接受、拒絕、提問）
• 相關的後設資料（寄件者名稱、主旨、日期）
• 使用者的寫作風格（來自訓練資料）

保持總上下文在 500 個 token 以下，以確保快速生成。

內容生成的微調

基礎模型生成通用內容。微調模型以您應用程式的風格和特定使用場景生成內容。

訓練資料來源

1. 現有使用者內容（需取得同意）：您的使用者目前如何撰寫郵件、訊息和筆記？他們的風格就是訓練目標。
2. **合成範例：**使用更大的模型生成訓練配對，然後驗證品質。
3. **基於範本的生成：**為常見場景建立範本並生成變體。

訓練重點領域

總計：700-1,700 個訓練範例，即可獲得一個調校良好的內容生成模型。

像 Ertas 這樣的平台處理完整流程。上傳您的訓練對話，使用 LoRA 微調，匯出 GGUF。模型學習您應用程式的內容風格，生成感覺原生的草稿。

效能預期

生成速度（3B 模型，Q4_K_M）

生成速度（1B 模型，Q4_K_M）

行內自動完成使用 1B 模型。完整草稿生成使用 3B。

品質考量

幻覺管理

內容生成模型可能會捏造細節。對於草稿而言，這意味著生成不在上下文中的名字、日期或事實。

緩解措施：

• 在提示中提供完整上下文（不要期望模型知道未提供的事實）
• 利用微調模型遵循訓練模式的傾向（微調模型在領域內任務上的幻覺較少）
• 在 UI 中增加「發送前審閱」步驟

長度控制

使用目標長度的範例進行微調。如果您想要 2-3 句的回覆，就用 2-3 句的範例訓練。模型從訓練資料中學習預期的輸出長度，而不是從指令中學習。

重新生成

始終提供「重新生成」按鈕。如果第一次草稿不符合期望，使用者可以獲取新的。溫度高於 0 時，每次生成都會產生不同的輸出。

即時生成、離線支援和零單次使用成本的組合，使裝置端內容生成成為任何使用者需要撰寫內容的應用程式的高價值功能。