過去，國產模型一發，大家安在各種模型頭上的標籤最好的不外乎開源第一，性價比第一。
但是今天不一樣了，智譜 GLM-5.2 模型一發，鋪天蓋地的消息湧來，開源模型已經和一流的閉源編模型旗鼓相當了，coding 方面，御三家該變成 GPT，Claude，智譜了。
GLM-5.2 現位居 Design Arena 第一，達到了 1360 的 Elo 分數。
BridgeBench BS（抗胡說測試） 上排名 #1，得分 100.0，在推理能力上排名 #1，得分 42.8。
GLM-5.2 在 Code Arena: Frontend 中也排名第 2，比 Claude Opus 4.7 (Thinking) 高出 29 分，僅落後於 Fable 5!
不過，不是美國人的我，想問問各位友友們 Claude Fable5 現在在哪裏發財呢？我咋用不到呢！
全世界最強的編程模型被禁令關停，不讓大家使用，GLM-5.2 卻把同一量級的能力開源給了所有人。
但是我還是準備自己來測一測 GLM-5.2，我不是信不過這些榜單，而是感覺自己測一次，一來能確定模型好不好用，二來能確定模型適不適合自己，畢竟每個人的使用場景不一樣。
我準備從 coding 和日常任務這兩方面測試，好，多的不說，測試裏見真章~
01. GLM-5.2實測
Case 1 1M 上下文測試
提示詞：根據文檔需求，完成K姐食堂APP的設計。
K姐食堂外賣點餐 App 產品需求文檔 PRD
版本：V1.0
文檔狀態：初稿
產品名稱：K姐食堂
產品類型：外賣點餐 App
目標平台：iOS、Android、H5、小程序可擴展
目標階段：MVP 到正式上線
撰寫日期：2026-06-17
1. 文檔說明
1.1 文檔目的
本文檔用於定義「K姐食堂」外賣點餐 App 的產品定位、業務目標、用戶角色、核心流程、功能需求、業務規則、數據指標、後台管理能力、非功能需求、驗收標準和版本規劃。
文檔面向產品、設計、研發、測試、運營、商家管理、配送管理等角色，作爲後續原型設計、技術方案拆解、研發排期、測試用例編寫和上線驗收的統一依據。
1.2 產品一句話
K姐食堂是一款面向工作日高頻用餐人羣的外賣點餐 App，主打「好選、快下單、準時送、容易復購」，幫助用戶用最少步驟完成日常工作餐、輕食、套餐和飲品點單。
1.3 版本範圍
V1.0 聚焦外賣點餐核心閉環，包括用戶登錄、定位選址、店鋪瀏覽、菜品點選、購物車、訂單確認、支付、商家接單、配送履約、訂單追蹤、取消退款、評價、復購和基礎後台。
V1.0 不做複雜內容社區、直播、拼團、會員等級體系、複雜推薦算法、多人點餐、預製菜商城和重營銷玩法，優先保證點餐鏈路穩定、訂單狀態準確、履約可追蹤、售後可處理。
2. 產品背景
2.1 市場背景
外賣已經成爲工作日午餐、晚餐、加班餐和臨時補給的高頻場景。用戶對外賣平台的基礎訴求並不複雜：想快點找到能喫的、價格清楚、配送時間靠譜、出問題能處理、下次還能快速復購。
但在實際使用中，很多點餐體驗被過度複雜的信息流、過多營銷入口、菜品信息不清晰、配送承諾不穩定、售後入口隱藏等問題打斷。用戶不是每次都想逛平台，很多時候只是想在 1 分鐘內解決「今天喫什麼」。
K姐食堂的機會點不在於做一個大而全的綜合外賣平台，而在於先把一個高頻、穩定、可控的日常點餐場景做好。比如辦公園區、學校周邊、社區樓宇、企業餐補場景、單品牌多門店食堂、連鎖輕食餐飲等。
2.2 用戶痛點
用戶側常見痛點包括：
1. 選擇成本高。首頁信息太雜，活動、廣告、榜單、推薦混在一起，用戶不知道從哪裏開始。
2. 菜品信息不清楚。圖片和實物差異大，規格、分量、辣度、加料、包裝費、配送費不透明。
3. 午高峯體驗不穩定。商家接單慢、出餐慢、騎手等待時間長，用戶無法判斷到底卡在哪一步。
4. 復購不方便。用戶常喫的套餐和店鋪沒有被突出，歷史訂單復購還要重新確認一堆選項。
5. 售後流程麻煩。餐品缺漏、送錯、灑漏、超時、無法聯繫騎手時，用戶不知道怎麼快速處理。
6. 優惠理解成本高。滿減、券、配送費、包裝費疊加後，用戶不清楚爲什麼實付價變化。
商家側痛點包括：
1. 高峯期訂單集中，容易漏接、錯單、出餐狀態不同步。
2. 菜品庫存和上下架更新不及時，用戶下單後才發現缺貨。
3. 退款、改菜、催單、備註處理缺少標準流程。
4. 店鋪經營數據不清楚，難以判斷熱銷菜、復購菜、差評原因和高峯壓力。
運營側痛點包括：
1. 異常訂單無法及時發現，客服被動接投訴。
2. 不同商家的接單、出餐、售後效率無法量化。
3. 優惠活動缺少配置和效果追蹤。
4. 用戶留存、復購、退款、超時等核心指標分散。
2.3 產品機會
K姐食堂應從「點餐效率」和「履約確定性」兩個方向切入：
1. 首頁不做複雜內容流，優先呈現附近可下單店鋪、常點套餐、今日推薦和搜索。
2. 店鋪頁強化菜單結構、規格選擇、菜品狀態和購物車金額透明。
3. 訂單狀態精細化，明確展示商家接單、備餐、騎手取餐、配送中、已送達等節點。
4. 復購入口前置，讓高頻用戶可以用更少步驟完成再次下單。
5. 後台可配置店鋪、菜品、優惠、配送、售後和異常訂單處理規則。
3. 產品定位與目標
3.1 產品定位
K姐食堂定位爲高頻日常點餐工具，不做泛娛樂平台。產品體驗應偏清爽、直接、穩定，減少不必要的打擾，讓用戶知道「今天有什麼能喫」「多久能送到」「多少錢」「出了問題找誰」。
產品關鍵詞：
– 高頻
– 工作餐
– 快速下單
– 準時配送
– 套餐化
– 易復購
– 可追蹤
– 售後明確
3.2 目標用戶
核心用戶：
1. 辦公樓白領。工作日午餐和晚餐需求穩定，重視送達時間、性價比和復購效率。
2. 學生羣體。價格敏感，偏好套餐、飲品、夜宵和多人宿舍配送。
3. 社區居民。晚餐、週末和臨時加餐需求較多，重視口味、商家穩定性和配送範圍。
4. 企業團餐/餐補用戶。下單時間集中，需要發票、企業賬戶、固定地址和批量訂單能力，V1.0 只預留擴展。
次級用戶：
1. 商家店員。負責接單、備餐、庫存、缺貨處理和售後確認。
2. 騎手。負責取餐、配送、異常上報和聯繫用戶。
3. 平台運營。負責訂單監控、活動配置、商家管理、投訴處理和數據分析。
3.3 產品目標
用戶體驗目標：
1. 新用戶從打開 App 到完成首單支付，核心路徑不超過 5 分鐘。
2. 老用戶通過「再來一單」完成復購，理想路徑不超過 30 秒。
3. 用戶能在訂單詳情頁清楚看到當前訂單卡在哪個履約節點。
4. 用戶在 3 次點擊內找到取消訂單、申請退款、聯繫客服或催單入口。
業務目標：
1. 完成外賣下單、支付、接單、備餐、配送、送達、評價的閉環。
2. 支持單店、單商圈試點上線，後續擴展到多門店。
3. 支持基礎優惠配置，提高首單轉化和復購。
4. 建立訂單、履約、售後、商家表現等基礎數據看板。
技術目標：
1. 訂單狀態一致、可追溯，不出現用戶端、商家端、後台狀態不一致。
2. 支付回調、退款、取消訂單等關鍵鏈路具備冪等處理。
3. 高峯期具備基礎抗壓能力，訂單提交和商家接單不能因併發明顯異常。
4. 支持後續擴展多門店、多城市、企業餐補、會員和智能推薦。
4. 核心指標
4.1 用戶轉化指標
– 首頁訪問人數
– 店鋪頁訪問人數
– 菜品加購率
– 購物車提交率
– 訂單支付成功率
– 首單轉化率
– 復購率
– 下單路徑平均耗時
4.2 履約指標
– 商家平均接單時長
– 商家平均出餐時長
– 騎手平均到店時長
– 騎手平均配送時長
– 平均送達時長
– 超時訂單率
– 取消訂單率
– 缺貨訂單率
– 異常訂單率
4.3 經營指標
– GMV
– 支付訂單數
– 客單價
– 實付金額
– 優惠補貼金額
– 配送費收入
– 包裝費收入
– 退款金額
– 商家銷售排行
– 菜品銷售排行
4.4 體驗指標
– 用戶評分
– 菜品評分
– 店鋪評分
– 配送評分
– 投訴率
– 售後處理時長
– 退款通過率
– 差評原因分佈
5. 用戶畫像與場景
5.1 用戶畫像一：午餐高頻白領
姓名：小林
年齡：27 歲
場景：工作日 11:30 前後點午餐
特徵：時間緊、選擇困難、常點固定套餐
訴求：快速下單、準時送達、價格穩定、可以復購
典型行爲：打開 App 後看常點店鋪或今日套餐，確認地址後直接下單。
5.2 用戶畫像二：加班晚餐用戶
姓名：阿杰
年齡：31 歲
場景：晚上 19:00 後加班點餐
特徵：更關心配送範圍和出餐速度
訴求：能快速知道哪些店還營業，預計多久送到
典型行爲：按「還在營業」「最快送達」「熱銷套餐」篩選。
5.3 用戶畫像三：價格敏感學生
姓名：小雨
年齡：20 歲
場景：午飯、夜宵、飲品
特徵：關注優惠、滿減、配送費、起送價
訴求：實付價清楚，優惠容易理解
典型行爲：先看活動套餐和新人券，再決定是否下單。
5.4 用戶畫像四：商家店員
姓名：王姐
年齡：38 歲
場景：午高峯集中接單
特徵：操作時間有限，不能頻繁切換複雜頁面
訴求：訂單提醒明顯、備註清楚、缺貨可快速處理
典型行爲：聽到新訂單提示後接單，按順序備餐，出餐後標記待取餐。
5.5 用戶畫像五：平台運營
姓名：Mia
年齡：29 歲
場景：監控平台訂單和異常
特徵：需要快速發現超時、退款、差評和商家異常
訴求：有清晰後台、可篩選、可導出、可處理
典型行爲：查看當日訂單看板，處理異常池中的超時訂單和投訴。
6. 總體業務流程
6.1 用戶下單主流程
1. 用戶打開 K姐食堂。
2. 系統獲取定位或用戶選擇收貨地址。
3. 首頁展示可配送店鋪、推薦套餐和分類入口。
4. 用戶進入店鋪頁。
5. 用戶選擇菜品、規格、數量，加購到購物車。
6. 用戶進入訂單確認頁。
7. 系統校驗配送地址、營業狀態、庫存、起送價、優惠和配送費。
8. 用戶選擇優惠券、餐具數量、備註和支付方式。
9. 用戶提交訂單並完成支付。
10. 系統創建支付訂單，等待支付回調。
11. 支付成功後訂單進入待商家接單狀態。
12. 商家接單後進入備餐中。
13. 商家出餐後進入待騎手取餐。
14. 騎手取餐後進入配送中。
15. 騎手確認送達後進入已送達。
16. 用戶確認收餐或系統自動完成。
17. 用戶評價訂單。
6.2 復購流程
1. 用戶進入「我的」或首頁「常點」。
2. 用戶選擇歷史訂單。
3. 點擊「再來一單」。
4. 系統校驗店鋪營業狀態、菜品是否在售、規格是否可用、庫存是否充足。
5. 若全部可用，恢復購物車並進入訂單確認頁。
6. 若部分菜品不可用，提示用戶刪除或替換。
7. 用戶確認後支付下單。
6.3 取消訂單流程
1. 待支付訂單：用戶可直接取消，無需退款。
2. 已支付但商家未接單：用戶可無責取消，系統自動退款。
3. 商家已接單但未出餐：用戶申請取消，商家確認後退款。
4. 商家已出餐或騎手已取餐：原則上不支持無責取消，需客服介入。
5. 已送達訂單：不支持取消，只能發起售後。
6.4 缺貨處理流程
1. 商家接單前發現菜品缺貨。
2. 商家可選擇拒單並填寫原因，或發起改菜/部分退款申請。
3. 用戶收到缺貨提示。
4. 用戶可選擇接受替換、刪除缺貨菜品或取消訂單。
5. 若用戶超時未處理，系統按配置自動取消或轉人工。
6.5 配送異常流程
配送異常包括騎手到店等待過久、用戶聯繫不上、地址錯誤、餐品損壞、天氣或交通原因導致超時。
處理原則：
1. 騎手必須選擇異常類型並填寫說明。
2. 用戶端展示簡化後的異常提示。
3. 後台異常池生成記錄。
4. 運營可聯繫用戶、騎手或商家處理。
5. 異常處理結果需要同步到訂單詳情。
7. 產品信息架構
7.1 用戶端信息架構
一級導航：
– 首頁
– 訂單
– 我的
首頁模塊：
– 地址欄
– 搜索
– 分類入口
– 今日推薦
– 常點菜品
– 附近店鋪
– 優惠活動
訂單模塊：
– 當前訂單
– 歷史訂單
– 待評價訂單
– 售後訂單
我的模塊：
– 用戶信息
– 優惠券
– 地址管理
– 收藏店鋪
– 客服中心
– 發票
– 設置
7.2 商家端信息架構
一級導航：
– 工作台
– 訂單
– 菜品
– 店鋪
– 數據
工作台模塊：
– 營業狀態
– 今日訂單
– 待接單
– 備餐中
– 待出餐
– 異常提醒
菜品模塊：
– 菜品列表
– 分類管理
– 規格管理
– 庫存管理
– 上下架
7.3 後台信息架構
一級導航：
– 數據看板
– 訂單管理
– 用戶管理
– 商家管理
– 騎手管理
– 菜品管理
– 優惠管理
– 售後管理
– 系統配置
8. 用戶端功能需求
8.1 登錄註冊
8.1.1 功能說明
用戶通過手機號驗證碼登錄。首次登錄自動註冊賬號。V1.0 不強制用戶設置密碼，不做第三方賬號綁定，可預留微信、支付寶、Apple 登錄擴展。
8.1.2 需求詳情
1. 用戶輸入手機號。
2. 點擊獲取驗證碼。
3. 系統校驗手機號格式。
4. 驗證碼發送成功後按鈕進入倒計時。
5. 用戶輸入驗證碼並提交。
6. 驗證成功後進入首頁。
7. 若用戶爲新用戶，系統創建用戶賬號。
8. 若用戶未同意用戶協議和隱私政策，不允許登錄。
8.1.3 異常處理
– 手機號格式錯誤：提示「請輸入正確的手機號」。
– 驗證碼錯誤：提示「驗證碼不正確，請重新輸入」。
– 驗證碼過期：提示「驗證碼已過期，請重新獲取」。
– 短信發送過於頻繁：提示「操作太頻繁，請稍後再試」。
8.2 地址與定位
8.2.1 功能說明
地址是外賣履約的基礎。系統需要支持自動定位、手動選擇地址、地址新增、編輯、刪除和默認地址設置。
8.2.2 需求詳情
1. 用戶首次進入 App，系統請求定位授權。
2. 用戶允許後，首頁顯示當前定位附近地址。
3. 用戶拒絕定位時，可手動搜索或新增地址。
4. 地址字段包括聯繫人、手機號、性別稱呼、所在地區、詳細地址、門牌號、標籤。
5. 地址標籤支持家、公司、學校、自定義。
6. 用戶可設置默認地址。
7. 下單時必須選擇可配送地址。
8.2.3 配送範圍校驗
進入店鋪頁和提交訂單時都需要校驗地址是否在配送範圍內。
若不在配送範圍內：
– 店鋪卡片顯示「超出配送範圍」。
– 店鋪頁禁止加購或禁止結算。
– 訂單確認頁提示用戶更換地址。
8.3 首頁
8.3.1 功能定位
首頁用於幫助用戶快速進入點餐狀態，不承擔複雜內容消費功能。首頁優先解決「附近有什麼」「今天推薦什麼」「我常喫什麼」「最快多久送到」。
8.3.2 頁面元素
1. 頂部地址欄：展示當前配送地址，點擊可切換。
2. 搜索框：支持搜索店鋪名、菜品名、關鍵詞。
3. 分類入口：工作餐、輕食、面飯、飲品、夜宵、早餐。
4. 今日推薦：運營配置的套餐或店鋪。
5. 常點菜品：基於歷史訂單展示。
6. 附近店鋪列表：按綜合排序展示。
7. 優惠標籤：展示新人券、滿減、配送券等。
8.3.3 店鋪卡片字段
– 店鋪名稱
– 店鋪頭像或封面
– 評分
– 月售
– 人均價格
– 起送價
– 配送費
– 預計送達時間
– 距離
– 優惠標籤
– 營業狀態
8.3.4 排序規則
默認綜合排序可綜合以下因素：
1. 是否營業。
2. 是否可配送當前地址。
3. 預計送達時間。
4. 店鋪評分。
5. 月銷量。
6. 用戶歷史偏好。
7. 運營推薦權重。
V1.0 可採用規則排序，不做複雜機器學習推薦。
8.4 搜索
8.4.1 功能說明
用戶可搜索店鋪、菜品和關鍵詞。搜索結果需要明確區分店鋪結果和菜品結果。
8.4.2 搜索入口
– 首頁搜索框
– 店鋪頁菜單搜索
8.4.3 搜索結果
搜索結果包括：
1. 店鋪列表。
2. 菜品列表。
3. 無結果頁。
4. 歷史搜索詞。
5. 熱門搜索詞。
8.4.4 無結果處理
當無搜索結果時，展示：
– 「沒有找到相關結果」
– 推薦用戶換個關鍵詞
– 展示附近熱銷店鋪或分類入口
8.5 店鋪頁
8.5.1 功能定位
店鋪頁是用戶決策和點餐的核心頁面，應讓用戶清楚看到店鋪是否可下單、配送多久、有哪些菜、價格如何、菜品是否可選、購物車金額是否達起送。
8.5.2 頁面結構
1. 店鋪頭部：
– 店鋪封面
– 店鋪名稱
– 評分
– 月售
– 公告
– 配送時間
– 起送價
– 配送費
2. 標籤頁：
– 點餐
– 評價
– 商家信息
3. 菜品分類側欄。
4. 菜品列表。
5. 底部購物車。
8.5.3 菜品信息
菜品字段包括：
– 菜品圖片
– 菜品名稱
– 菜品描述
– 月售
– 好評率
– 價格
– 原價
– 規格
– 庫存狀態
– 推薦標籤
8.5.4 菜品狀態
菜品狀態包括：
– 正常可售
– 已售罄
– 已下架
– 非當前時間段供應
不可售菜品可展示但不可加購，按鈕置灰並說明原因。
8.6 菜品規格
8.6.1 功能說明
部分菜品存在規格選擇，如份量、辣度、主食、加料、飲品溫度等。用戶點擊加購時若存在規格，彈出規格選擇面板。
8.6.2 規格類型
常見規格包括：
– 份量：小份、標準、大份。
– 辣度：不辣、微辣、中辣、特辣。
– 主食：米飯、面、粉。
– 加料：雞蛋、肉片、蔬菜、芝士。
– 飲品：熱、常溫、冰。
8.6.3 選擇規則
規格可配置爲單選或多選。必選規格未選擇時，不允許加入購物車。規格加價需要實時計入菜品價格。
8.7 購物車
8.7.1 功能說明
購物車用於展示當前店鋪已選菜品、數量、規格、價格、優惠提示和起送差額。
8.7.2 需求詳情
1. 用戶可增加或減少菜品數量。
2. 用戶可清空購物車。
3. 用戶可修改已選菜品規格。
4. 購物車實時計算菜品總價。
5. 未達到起送價時，提示「還差 X 元起送」。
6. 達到起送價後，按鈕變爲「去結算」。
7. 同一訂單隻支持同一店鋪菜品，V1.0 不做跨店鋪購物車。
8.7.3 價格展示
購物車展示金額包括：
– 菜品金額
– 規格加價
– 包裝費
– 配送費預估
– 優惠預估
– 預計實付
完整金額以訂單確認頁爲準。
8.8 訂單確認頁
8.8.1 功能說明
訂單確認頁是支付前最終確認頁面，需要完成配送地址、送達時間、菜品明細、優惠、備註、餐具、費用和支付方式確認。
8.8.2 頁面字段
– 配送地址
– 聯繫人和手機號
– 預計送達時間
– 店鋪名稱
– 菜品明細
– 包裝費
– 配送費
– 優惠券
– 備註
– 餐具數量
– 支付方式
– 費用明細
– 提交訂單按鈕
8.8.3 下單前校驗
提交訂單前需要校驗：
1. 用戶是否登錄。
2. 地址是否完整。
3. 地址是否在配送範圍。
4. 店鋪是否營業。
5. 菜品是否仍在售。
6. 庫存是否充足。
7. 金額是否滿足起送價。
8. 優惠券是否可用。
9. 支付方式是否可用。
若校驗失敗，系統需明確提示失敗原因，並引導用戶修改。
8.9 支付
8.9.1 支付方式
V1.0 支持微信支付和支付寶支付，可預留餘額支付、企業餐補支付。
8.9.2 支付流程
1. 用戶點擊提交訂單。
2. 系統創建訂單，狀態爲待支付。
3. 系統拉起支付。
4. 用戶完成支付。
5. 支付渠道回調。
6. 系統更新訂單爲待商家接單。
7. 用戶端展示支付成功頁或訂單詳情頁。
8.9.3 支付異常
– 用戶取消支付：訂單保留待支付狀態，可重新支付。
– 支付失敗：提示失敗原因，支持重新支付。
– 支付成功但頁面未返回：用戶進入訂單頁時需根據服務端狀態展示。
– 支付回調重複：服務端需冪等處理。
8.10 訂單列表
8.10.1 功能說明
訂單列表展示用戶當前訂單和歷史訂單，支持查看詳情、再來一單、評價、退款和聯繫客服。
8.10.2 訂單分類
– 全部
– 進行中
– 待評價
– 退款/售後
8.10.3 訂單卡片字段
– 店鋪名稱
– 訂單狀態
– 下單時間
– 菜品摘要
– 實付金額
– 操作按鈕
操作按鈕根據狀態變化：
– 待支付：去支付、取消訂單
– 待商家接單：取消訂單、聯繫商家
– 備餐中：催單、聯繫商家
– 配送中：聯繫騎手、查看配送
– 已完成：再來一單、評價、申請售後
– 已取消：再來一單
8.11 訂單詳情
8.11.1 功能說明
訂單詳情頁用於展示履約進度和訂單信息，是用戶下單後的核心查看頁面。
8.11.2 頁面模塊
1. 訂單狀態區：
– 當前狀態
– 預計送達時間
– 狀態說明
2. 履約時間線：
– 訂單已提交
– 商家已接單
– 商家備餐中
– 騎手已取餐
– 配送中
– 已送達
3. 配送信息：
– 騎手姓名
– 騎手電話
– 當前位置，V1.0 可不做實時地圖，預留
4. 商家信息：
– 商家電話
– 商家地址
5. 菜品明細。
6. 費用明細。
7. 訂單編號。
8. 售後入口。
8.12 評價
8.12.1 功能說明
用戶可對已完成訂單進行評價，評價對象包括整體訂單、菜品、配送和商家。
8.12.2 評價內容
– 星級評分
– 文字評價
– 圖片上傳
– 匿名評價
– 推薦標籤
8.12.3 評價規則
1. 已完成訂單可評價。
2. 每個訂單隻允許評價一次。
3. 評價提交後可在一定時間內追加，不支持隨意修改。
4. 涉及敏感詞、辱罵、隱私的信息進入審覈。
8.13 售後
8.13.1 售後類型
– 取消訂單
– 申請退款
– 部分退款
– 餐品缺漏
– 餐品損壞
– 送錯餐
– 配送超時
– 未收到餐
8.13.2 售後流程
1. 用戶選擇售後原因。
2. 用戶填寫說明並上傳憑證。
3. 系統判斷是否自動處理。
4. 自動處理失敗或金額較高時進入人工審覈。
5. 商家或平台運營處理。
6. 用戶收到處理結果。
7. 若退款通過，原路退回支付賬戶。
8.13.3 自動退款規則
V1.0 可先支持有限自動退款場景：
– 商家未接單時用戶取消。
– 商家超時未接單。
– 店鋪主動拒單。
– 支付後庫存校驗失敗。
其他場景進入人工審覈。
8.14 優惠券
8.14.1 優惠類型
– 新人券
– 滿減券
– 配送券
– 店鋪券
– 平台券
8.14.2 使用規則
1. 新人券僅限首單可用。
2. 滿減券需達到指定門檻。
3. 配送券只抵扣配送費。
4. 店鋪券僅限指定店鋪。
5. 平台券適用於所有參與活動店鋪。
6. 單筆訂單默認只可使用一張滿減類優惠券。
7. 配送券可與滿減券疊加，具體由後台配置。
8.14.3 展示規則
訂單確認頁應展示可用券和不可用券。不可用券需要說明原因，例如未達到門檻、不適用該店鋪、已過期、不可與當前活動疊加。
9. 商家端功能需求
9.1 商家登錄
商家通過賬號密碼或手機號驗證碼登錄。賬號由平台後台創建並分配權限。
商家賬號角色包括：
– 店主
– 店長
– 店員
不同角色權限不同。V1.0 可先實現基礎權限，店員可處理訂單和菜品庫存，店主可查看數據和管理店鋪信息。
9.2 商家工作台
工作台用於高峯期快速處理訂單。
展示內容：
– 當前營業狀態
– 今日訂單數
– 今日銷售額
– 待接單數量
– 備餐中數量
– 待騎手取餐數量
– 異常訂單數量
核心操作：
– 開始營業
– 暫停營業
– 接單
– 拒單
– 標記出餐
– 聯繫用戶
– 聯繫騎手
9.3 訂單管理
9.3.1 訂單狀態
商家端訂單狀態包括：
– 新訂單
– 已接單
– 備餐中
– 待取餐
– 已取餐
– 已完成
– 已取消
– 退款中
9.3.2 新訂單提醒
新訂單需有明顯提醒：
– 聲音提醒
– 彈窗提醒
– 列表置頂
– 未處理數量角標
商家未在配置時間內處理時，後台生成超時提醒。
9.3.3 接單規則
商家可接單或拒單。
拒單必須選擇原因：
– 菜品缺貨
– 已打烊
– 配送異常
– 訂單備註無法滿足
– 其他原因
拒單後訂單取消並退款，拒單原因同步給用戶和後台。
9.4 菜品管理
9.4.1 菜品字段
– 菜品名稱
– 菜品分類
– 菜品圖片
– 菜品描述
– 售價
– 原價
– 庫存
– 包裝費
– 規格
– 是否推薦
– 上架狀態
– 售賣時間
9.4.2 菜品操作
– 新增菜品
– 編輯菜品
– 刪除菜品
– 上架
– 下架
– 設置售罄
– 恢復庫存
– 調整排序
9.4.3 庫存規則
1. 庫存爲 0 時，菜品自動顯示售罄。
2. 用戶下單支付成功後扣減庫存。
3. 訂單取消或退款時是否返還庫存由訂單狀態決定。
4. 商家可手動設置今日售罄。
9.5 店鋪管理
店鋪信息包括：
– 店鋪名稱
– 店鋪 Logo
– 店鋪封面
– 店鋪公告
– 營業時間
– 配送範圍
– 起送價
– 配送費規則
– 包裝費規則
– 聯繫電話
– 店鋪地址
營業狀態包括：
– 營業中
– 休息中
– 暫停接單
– 已打烊
暫停接單時，用戶可瀏覽店鋪和菜品，但不能下單。
9.6 商家數據
商家端展示基礎經營數據：
– 今日訂單數
– 今日營業額
– 今日退款數
– 熱銷菜品
– 差評訂單
– 平均接單時長
– 平均出餐時長
V1.0 只做基礎展示，不做複雜經營分析。
10. 騎手端功能需求
10.1 騎手登錄
騎手賬號由平台後台創建，騎手通過手機號驗證碼登錄。騎手需具備實名信息和聯繫方式，V1.0 可由後台錄入。
10.2 配送任務
騎手端任務列表包括：
– 待取餐
– 配送中
– 已完成
– 異常任務
任務卡片展示：
– 店鋪名稱
– 店鋪地址
– 用戶地址
– 預計送達時間
– 訂單號
– 聯繫商家
– 聯繫用戶
10.3 狀態操作
騎手可執行以下狀態操作：
1. 到店。
2. 已取餐。
3. 配送中。
4. 已送達。
5. 上報異常。
狀態變更需同步到用戶端、商家端和後台。
10.4 異常上報
異常類型包括：
– 商家未出餐
– 用戶聯繫不上
– 地址錯誤
– 餐品損壞
– 交通原因
– 天氣原因
– 無法進入小區或樓宇
騎手上報異常後，後台異常池生成記錄，運營可介入處理。
11. 運營後台功能需求
11.1 數據看板
後台首頁展示平台整體經營數據：
– 今日 GMV
– 今日支付訂單數
– 今日退款訂單數
– 今日活躍用戶
– 當前進行中訂單
– 當前異常訂單
– 超時訂單率
– 平均配送時長
數據支持按日期篩選，V1.0 支持今日、昨日、近 7 天、近 30 天。
11.2 訂單管理
訂單管理支持查看、篩選、導出和處理訂單。
篩選條件：
– 訂單編號
– 用戶手機號
– 店鋪名稱
– 騎手名稱
– 訂單狀態
– 支付狀態
– 售後狀態
– 下單時間
訂單詳情展示：
– 用戶信息
– 商家信息
– 騎手信息
– 菜品明細
– 費用明細
– 支付信息
– 狀態流轉日誌
– 售後記錄
– 操作日誌
後台可執行：
– 取消訂單
– 發起退款
– 標記異常
– 添加備註
– 聯繫用戶
– 聯繫商家
– 聯繫騎手
11.3 用戶管理
用戶管理字段：
– 用戶 ID
– 手機號
– 暱稱
– 註冊時間
– 最近下單時間
– 訂單數
– 支付金額
– 用戶狀態
後台操作：
– 查看用戶詳情
– 查看用戶訂單
– 禁用用戶
– 解禁用戶
– 添加運營備註
手機號展示需脫敏，只有具備權限的角色可查看完整手機號。
11.4 商家管理
商家管理字段：
– 店鋪 ID
– 店鋪名稱
– 聯繫人
– 聯繫電話
– 地址
– 營業狀態
– 審覈狀態
– 訂單數
– 評分
後台操作：
– 新增店鋪
– 編輯店鋪
– 審覈店鋪
– 設置營業狀態
– 配置配送範圍
– 配置費用規則
– 查看經營數據
11.5 騎手管理
騎手管理字段：
– 騎手 ID
– 姓名
– 手機號
– 狀態
– 今日配送單數
– 平均配送時長
– 投訴次數
後台操作：
– 新增騎手
– 編輯騎手
– 啓用/停用
– 分配配送區域
– 查看配送記錄
11.6 優惠管理
後台支持創建優惠券。
優惠券字段：
– 優惠券名稱
– 優惠類型
– 面額
– 使用門檻
– 適用店鋪
– 發放數量
– 每人限領數量
– 有效期
– 是否可疊加
– 使用說明
優惠券狀態：
– 未開始
– 進行中
– 已結束
– 已停用
11.7 售後管理
售後管理用於處理退款、投訴和異常訂單。
售後單字段：
– 售後單號
– 訂單號
– 用戶
– 店鋪
– 售後類型
– 申請金額
– 申請原因
– 憑證
– 當前狀態
– 處理人
– 處理結果
售後狀態：
– 待處理
– 商家處理中
– 平台處理中
– 已同意
– 已拒絕
– 已退款
– 已關閉
處理結果必須留痕，不允許刪除。
12. 訂單狀態機
12.1 主狀態
訂單主狀態包括：
1. 待支付
2. 待商家接單
3. 商家備餐中
4. 待騎手取餐
5. 配送中
6. 已送達
7. 已完成
8. 已取消
9. 退款中
10. 已退款
12.2 狀態流轉規則
待支付：
– 用戶支付成功，進入待商家接單。
– 用戶取消，進入已取消。
– 超時未支付，系統自動取消。
待商家接單：
– 商家接單，進入商家備餐中。
– 商家拒單，進入已取消並退款。
– 用戶取消，進入已取消並退款。
– 商家超時未接單，系統提醒或自動取消。
商家備餐中：
– 商家標記出餐，進入待騎手取餐。
– 用戶申請取消，需商家確認。
待騎手取餐：
– 騎手取餐，進入配送中。
– 騎手上報異常，進入異常處理但主狀態可保持待取餐。
配送中：
– 騎手確認送達，進入已送達。
– 用戶上報未收到，進入售後處理。
已送達：
– 用戶確認收餐或超時自動完成，進入已完成。
– 用戶申請售後，進入售後流程。
12.3 狀態日誌
每次狀態變化必須記錄：
– 訂單 ID
– 原狀態
– 新狀態
– 操作人類型
– 操作人 ID
– 操作時間
– 操作來源
– 備註
13. 費用與結算規則
13.1 訂單金額構成
訂單應付金額包括：
菜品金額 + 規格加價 + 包裝費 + 配送費 – 優惠金額 = 實付金額
13.2 包裝費
包裝費可按以下方式配置：
1. 按訂單固定包裝費。
2. 按菜品獨立包裝費。
3. 按數量疊加包裝費。
V1.0 建議支持按菜品包裝費，後台可配置。
13.3 配送費
配送費可按距離、門店、訂單金額配置。V1.0 可採用簡化規則：
– 店鋪固定配送費。
– 滿指定金額減免配送費，作爲後續擴展。
13.4 退款金額
全額退款：
退還用戶實付金額，優惠券是否返還由活動配置決定。
部分退款：
按菜品實付分攤金額退款。若優惠涉及滿減，需要根據後台規則重新計算或人工處理。
13.5 商家結算
V1.0 可先做數據記錄，不做完整財務結算系統。需要記錄：
– 訂單原價
– 優惠金額
– 平台補貼
– 商家承擔優惠
– 退款金額
– 結算金額
14. 通知與消息
14.1 用戶通知
用戶通知場景包括：
– 支付成功
– 商家已接單
– 商家已出餐
– 騎手已取餐
– 騎手即將送達
– 訂單已送達
– 退款成功
– 售後處理完成
通知形式包括 App 內消息、Push、短信，V1.0 可優先 App 內消息和 Push。
14.2 商家通知
商家通知場景包括：
– 新訂單
– 用戶取消訂單
– 用戶申請退款
– 騎手到店
– 異常訂單
新訂單提醒必須明顯，支持聲音和彈窗。
14.3 騎手通知
騎手通知場景包括：
– 新配送任務
– 商家已出餐
– 用戶修改備註
– 用戶聯繫請求
– 配送異常處理結果
15. 權限與安全
15.1 用戶隱私
用戶手機號、地址、訂單記錄屬於敏感信息。系統需遵循最小可見原則。
要求：
1. 用戶手機號默認脫敏展示。
2. 騎手和商家僅在訂單履約必要階段查看用戶聯繫信息。
3. 後台查看完整手機號需具備權限。
4. 地址信息不得用於非訂單履約目的。
5. 用戶可刪除地址。
15.2 後台權限
後台角色包括：
– 超級管理員
– 運營
– 客服
– 財務
– 商家管理員
權限示例：
– 客服可查看訂單和處理售後，但不能修改優惠規則。
– 運營可配置活動和處理異常訂單。
– 財務可查看結算數據，但不能修改訂單狀態。
– 超級管理員可管理角色和權限。
15.3 操作日誌
後台關鍵操作必須記錄日誌：
– 修改訂單狀態
– 發起退款
– 修改商家信息
– 修改優惠券
– 禁用用戶
– 停用商家
– 修改配送規則
16. 非功能需求
16.1 性能需求
1. 首頁首屏加載時間不超過 2 秒。
2. 店鋪頁菜品列表切換響應不超過 500ms。
3. 提交訂單接口平均響應不超過 1 秒。
4. 支付成功回調後訂單狀態更新不超過 3 秒。
5. 高峯期訂單狀態推送延遲不超過 5 秒。
16.2 可用性需求
1. 核心下單鏈路可用性目標 99.9%。
2. 支付和訂單狀態不得因客戶端退出而丟失。
3. 商家端斷網恢復後需重新同步未處理訂單。
4. 騎手端弱網情況下可緩存關鍵狀態，恢復後補傳。
16.3 兼容性需求
移動端需兼容：
– iOS 最近 3 個主版本。
– Android 主流系統版本。
– 主流屏幕尺寸。
H5 或小程序擴展需適配微信環境。
16.4 可維護性需求
1. 訂單狀態機需要服務端統一管理。
2. 費用計算需服務端統一計算，客戶端只展示結果。
3. 優惠規則應支持後台配置。
4. 菜品、店鋪、配送、售後規則應模塊化，便於後續擴展。
17. 埋點需求
17.1 首頁埋點
– 首頁曝光
– 地址切換點擊
– 搜索框點擊
– 分類點擊
– 店鋪卡片曝光
– 店鋪卡片點擊
– 推薦套餐點擊
17.2 店鋪頁埋點
– 店鋪頁曝光
– 菜品曝光
– 菜品加購
– 規格彈窗打開
– 規格確認
– 購物車打開
– 去結算點擊
17.3 訂單埋點
– 訂單確認頁曝光
– 優惠券點擊
– 提交訂單點擊
– 支付發起
– 支付成功
– 支付失敗
– 取消訂單點擊
– 再來一單點擊
17.4 售後埋點
– 售後入口點擊
– 售後類型選擇
– 售後提交
– 售後成功
– 售後失敗
18. 風險與邊界
18.1 業務風險
1. 午高峯訂單集中，商家接單和出餐壓力較大。
2. 配送能力不足會直接影響用戶體驗。
3. 優惠規則如果不清晰，容易引發價格爭議。
4. 商家菜品圖片和實物差異可能導致差評。
5. 售後審覈如果過慢，會放大用戶負面情緒。
18.2 產品邊界
V1.0 重點是完成點餐履約閉環，不追求複雜營銷玩法。所有新增功能都應優先判斷是否提升下單效率、履約穩定性或售後處理效率。
18.3 技術風險
1. 支付回調和訂單狀態一致性要求高。
2. 庫存扣減和退款返還容易出現邊界問題。
3. 商家端、用戶端、騎手端多端狀態同步複雜。
4. 高峯期推送延遲可能影響履約。
19. 驗收標準
19.1 用戶端驗收
1. 用戶可以手機號驗證碼登錄。
2. 用戶可以新增、編輯、刪除地址。
3. 用戶可以瀏覽首頁店鋪和分類。
4. 用戶可以進入店鋪頁查看菜品。
5. 用戶可以選擇規格並加入購物車。
6. 用戶可以提交訂單並完成支付。
7. 用戶可以查看訂單狀態。
8. 用戶可以取消符合條件的訂單。
9. 用戶可以申請售後。
10. 用戶可以評價已完成訂單。
11. 用戶可以通過歷史訂單再來一單。
19.2 商家端驗收
1. 商家可以登錄。
2. 商家可以切換營業狀態。
3. 商家可以接單和拒單。
4. 商家可以標記備餐完成。
5. 商家可以管理菜品上下架和庫存。
6. 商家可以查看今日訂單和基礎經營數據。
19.3 騎手端驗收
1. 騎手可以登錄。
2. 騎手可以查看配送任務。
3. 騎手可以標記到店、取餐、送達。
4. 騎手可以聯繫用戶和商家。
5. 騎手可以上報配送異常。
19.4 後台驗收
1. 後台可以查看訂單列表和訂單詳情。
2. 後台可以管理用戶、商家、騎手。
3. 後台可以配置優惠券。
4. 後台可以處理售後單。
5. 後台可以查看數據看板。
6. 後台關鍵操作有日誌。
20. 版本規劃
20.1 V1.0 MVP
目標：完成外賣點餐基礎閉環。
範圍：
– 用戶登錄
– 地址管理
– 首頁
– 店鋪頁
– 菜品規格
– 購物車
– 訂單確認
– 支付
– 訂單詳情
– 商家接單
– 騎手配送
– 售後
– 基礎後台
20.2 V1.1 體驗優化
目標：提升復購和點餐效率。
範圍：
– 常點菜品
– 收藏店鋪
– 智能默認地址
– 更完善的評價標籤
– 商家出餐時長優化提示
– 優惠券推薦
20.3 V1.2 運營增強
目標：提升活動和商家經營能力。
範圍：
– 店鋪活動配置
– 菜品排行榜
– 用戶分層
– 商家經營分析
– 異常訂單自動預警
– 售後原因分析
20.4 V2.0 擴展能力
目標：支持更復雜場景。
範圍：
– 多人點餐
– 企業餐補
– 發票管理
– 會員體系
– 拼單
– 預約配送
– 智能推薦
– 多城市多商圈管理
21. 原型頁面清單
用戶端：
1. 啓動頁
2. 登錄頁
3. 定位授權頁
4. 地址列表頁
5. 新增地址頁
6. 首頁
7. 搜索頁
8. 搜索結果頁
9. 店鋪頁
10. 菜品規格彈窗
11. 購物車彈窗
12. 訂單確認頁
13. 支付結果頁
14. 訂單列表頁
15. 訂單詳情頁
16. 取消訂單頁
17. 售後申請頁
18. 評價頁
19. 我的頁
20. 優惠券頁
21. 客服中心頁
商家端：
1. 登錄頁
2. 工作台
3. 訂單列表
4. 訂單詳情
5. 菜品列表
6. 菜品編輯
7. 店鋪設置
8. 數據頁
騎手端：
1. 登錄頁
2. 任務列表
3. 任務詳情
4. 異常上報
後台：
1. 登錄頁
2. 數據看板
3. 訂單管理
4. 訂單詳情
5. 用戶管理
6. 商家管理
7. 騎手管理
8. 優惠券管理
9. 售後管理
10. 系統配置
22. 測試重點
22.1 主流程測試
– 登錄到下單支付全流程。
– 支付成功後商家接單流程。
– 商家出餐到騎手送達流程。
– 用戶評價流程。
– 再來一單流程。
22.2 異常測試
– 支付失敗。
– 支付成功但客戶端斷網。
– 商家拒單。
– 商家超時未接單。
– 菜品庫存不足。
– 地址超出配送範圍。
– 騎手配送異常。
– 用戶申請退款。
22.3 金額測試
– 起送價計算。
– 包裝費計算。
– 配送費計算。
– 滿減券計算。
– 配送券計算。
– 部分退款金額計算。
– 取消訂單退款。
22.4 權限測試
– 普通用戶不能訪問後台。
– 商家只能查看自己店鋪訂單。
– 騎手只能查看自己的配送任務。
– 客服不能修改優惠規則。
– 後台操作日誌完整記錄。
23. 待確認問題
1. V1.0 是否必須同時支持 App 和小程序，還是先做其中一個端。
2. 配送由平台騎手承擔，還是商家自配送，或兩者都支持。
3. 支付是否需要支持餘額或企業餐補。
4. 是否需要對接發票系統。
5. 商家結算是否在 V1.0 內實現。
6. 地圖能力是否需要實時軌跡，還是隻展示狀態流轉。
7. 新人券和滿減活動的補貼由平台承擔還是商家承擔。
8. 售後自動退款的金額上限是多少。
9. 是否需要支持預訂單和預約配送。
10. 是否需要企業團餐場景。
24. 總結
K姐食堂 V1.0 的核心不是做一個功能堆滿的外賣平台，而是先把日常點餐最重要的鏈路跑穩：用戶能快速選餐、清楚付款、實時看狀態；商家能及時接單、準確出餐；騎手能順利配送；平台能看見異常並處理售後。
這個版本應圍繞三個關鍵詞建設：效率、確定性、可追蹤。
效率體現在首頁、店鋪頁、購物車和復購鏈路。確定性體現在配送範圍、庫存、價格、訂單狀態和預計送達時間。可追蹤體現在訂單狀態機、履約日誌、售後記錄和後台操作日誌。
大家如果看過上面的提示詞就知道，提示詞超級長，專門用來測試 1M 上下文。
完成度挺高，每一個小窗口都是可以直接互動的，
覆蓋面完整，一共做了 19 個展示界面。首頁、店鋪頁、規格彈窗、確認訂單、訂單詳情、售後、評價這些關鍵頁面都有。
後台頁面不是擺設：數據看板、訂單管理、售後管理都有。
後續只需要補交互、補狀態、補真實素材和響應式就能變成一個完整的APP了。
case 2 3D 太陽系
第一個測試我們就來一個 3D 項目吧，以往基本每次模型測評都會有的項目。
提示詞：
做一個可交互的 3D 太陽系頁面。
要求：
使用 Three.js。
行星圍繞太陽公轉，軌道可見。
點擊行星後，側邊面板顯示行星名稱、半徑、距離、介紹。
支持播放/暫停、速度調節、視角拖拽、滾輪縮放。
手機端改爲上下佈局，不能遮擋主體畫面。
出來的效果看起來真的很不錯，該有的行星都有，交互也比較全。點擊、拖拽、縮放、暫停、速度調節、重置視角都有。
看得出模型的 Three.js 基礎、頁面整合能力、交互實現能力都很不錯。
出來的效果看起來真的很不錯，該有的行星都有，交互也比較全。點擊、拖拽、縮放、暫停、速度調節、重置視角都有。效果展示視頻：https://weixin.qq.com/sph/AobTs8a50
看得出模型的 Three.js 基礎、頁面整合能力、交互實現能力都很不錯。
case 3 射擊遊戲
接下來我們做一個射擊遊戲。
提示詞：請輸出完整單文件 HTML，用 Canvas 做一個類似《雷電》的豎版射擊遊戲。玩家戰機可移動和射擊，敵機分批出現併發射子彈；有碰撞檢測、爆炸效果、分數、生命、關卡、暫停；每 30 秒出現 Boss；手機端有方向和射擊按鈕。
做完玩了十幾分鍾，是真的好玩，彌補了我小時候家長不讓玩遊戲機的遺憾。效果展示視頻：https://weixin.qq.com/sph/AGFesU2uc
戰機、Boss、子彈、音效都有，還做了屏幕震動效果，玩法結構也完整，已經是一個完整的遊戲了。GLM-5.2 顯然理解了豎版射擊遊戲的基本骨架， 能搭出主循環、實體系統、碰撞、移動端控制和視覺效果。
case 4 bug 修改
接下來測試一下 bug 修復能力，修復一個甘特圖 HTML 文件，甘特圖是典型工作場景，比普通表格更能看出前端狀態設計能力。
提示詞：
下面是一段有 bug 的單文件 HTML，目標是做一個銷售趨勢圖。請修復代碼，並輸出修復後的完整 HTML。
不要只解釋問題，必須給出能直接運行的完整代碼。
原始代碼：
<!DOCTYPE html><html><head> <meta charset=”UTF-8″> <title>Sales Chart</title> <script src=”https://cdn.jsdelivr.net/npm/chart.js”></script> <style> body { margin: 0; background: #f5f5f5; } .wrap { width: 900px; margin: 40px auto; background: white; padding: 24px; } canvas { width: 100%; height: 300px; } </style></head><body> <div class=”wrap”> <h1>銷售趨勢</h1> <select id=”range”> <option value=”q1″>Q1</option> <option value=”q2″>Q2</option> </select> <canvas id=”chart”></canvas> </div> <script> const data = { q1: { labels: [“1月”, “2月”, “3月”], sales: [120, 180, 150], refund: [12, 18, 20] }, q2: { labels: [“4月”, “5月”, “6月”], sales: [210, 260, 240], refund: [30, 22, 28] } }; const ctx = document.getElementById(“chart”); let chart; function renderChart(range) { chart = new Chart(ctx, { type: “line”, data: { labels: data.range.labels, datasets: [ { label: “銷售額”, data: data.range.sales, borderColor: “blue” }, { label: “退款”, data: data.range.refund, borderColor: “red” } ] } }); } document.getElementById(“range”).addEventListener(“change”, (e) => { renderChart(e.target.value); }); renderChart(“q1”); </script></body></html>
修復要求：
修復所有導致圖表無法正確切換的數據訪問問題。
切換 Q1 / Q2 時不能重複創建多個 Chart 實例導致內存泄漏。
頁面需要響應式，手機端寬度不能溢出。
增加一個 KPI 區域，顯示當前季度總銷售額、總退款、淨銷售額。
增加柱狀圖或折線圖切換按鈕。
增加空狀態和錯誤保護，如果傳入不存在的季度，頁面要顯示友好提示。
最後在代碼註釋裏簡短標出修復了哪些關鍵 bug。
修復前效果：
修復後效果：https://weixin.qq.com/sph/AS07Vq2uc
代碼修得很完整。KPI、圖表類型切換、響應式、空狀態都補上了，說明模型理解了修 bug 的要求，還自動完善了使用體驗。
GLM 的前端 bug 修復能力不錯：能讀懂原始問題，能修核心 bug，也能主動補齊產品體驗。
case 5 網頁製作
我覺得審美也是一個模型的能力體現，我們讓 GLM-5.2 生成一個官網頁面試試。
提示詞：
請輸出一個完整的單文件 HTML，包含 HTML、CSS、JavaScript，不依賴後端。可以使用 GSAP、Three.js、Lucide Icons 的 CDN，但不要使用 UI 模板庫。
主題：爲一個名叫「LumaNote」的 AI 筆記產品製作官網首頁。
產品背景：
LumaNote 面向研究生、產品經理、諮詢顧問和內容創作者。核心功能包括：自動整理會議錄音、把長文檔變成結構化筆記、從多篇資料中提煉觀點、生成可追溯引用、把筆記同步到 Notion 和 Obsidian。
頁面要求：
首屏必須直接展示產品，不要做空泛大標題。需要有一個真實感的產品界面主視覺，可以用 HTML/CSS 做出筆記軟件界面，也可以用 Canvas / Three.js 做互動展示。
首屏包含產品名、清晰的一句話定位、主按鈕和次按鈕。
頁面至少包含 5 個完整區塊：首屏、核心工作流、功能亮點、適用人羣、價格方案、FAQ。
核心工作流要展示「導入資料 → 自動整理 → 生成引用筆記 → 同步工具」這條鏈路，不能只列功能點。
功能亮點至少 6 個，每個亮點要有圖標、標題、簡短說明。
適用人羣要針對 4 類用戶分別寫不同場景，文案不能重複。
價格方案包含免費版、專業版、團隊版，每檔要有價格、適合誰、主要功能。
FAQ 至少 5 個問題。
頁面需要有頂部導航，並支持點擊平滑滾動到對應區塊。
移動端要適配，不能出現橫向滾動、文字溢出、按鈕遮擋。
設計要求：
整體風格要像成熟 SaaS 官網，剋制、清爽、有高級感。
不要使用大片紫藍漸變、漂浮彩色光球、emoji 圖標、模板化 bento 卡片。
卡片圓角不要超過 8px。
首屏主視覺不能只是裝飾圖，必須能看出產品是怎麼處理筆記和引用的。
使用統一字體層級、留白和顏色系統。
交互要有細節，比如導航高亮、FAQ 展開、按鈕 hover、工作流步驟切換或動效。
所有文案用中文，語氣像真實產品官網，不要寫成 AI 味宣傳稿。
輸出要求：
只輸出完整 HTML 代碼。
所有 CSS 和 JS 寫在同一個文件裏。
不要解釋設計思路。
代碼要能直接保存爲 .html 並在瀏覽器打開運行。
GLM-5.2 生成的官網頁面：
打開第一眼我還以爲點進了哪個 AI 工具網站，AI 能做出審美這麼牛的網頁，太不真實了這種感覺。
暖紙色背景、深色主按鈕、細邊框、低飽和棕色強調色配的非常舒適。已經從只會堆漸變卡片的坑跳出來了。
case 6 中文寫作
大模型的中文寫作水平真的是普通人很看重的一點了，比較很多上班族都需要 AI 給自己出點文案啥的。
提示詞：
請根據下面材料，寫一篇 1200-1500 字的中文公衆號文章。
主題：AI 工具進公司一年後，真正有用的地方和沒用的地方
背景材料：
一家 12 人內容團隊從去年開始系統使用 AI 工具。團隊主要做公衆號文章、短視頻腳本、行業資料整理和簡單數據分析。使用一年後，周產出從 3 篇文章提高到 5 篇，資料整理時間減少約 40%，但初稿返工率沒有明顯下降。團隊發現，AI 最適合做資料歸納、標題備選、表格清洗、採訪提綱和初稿結構；最不適合直接寫觀點、判斷行業趨勢、替代編輯拍板。新人依賴 AI 後，文章更快成型，但觀點經常變淺。資深編輯用 AI 更像用助理，可以省時間，但不會放棄人工判斷。
寫作要求：
標題自擬，不要標題黨。
開頭直接進入具體場景，不要用“隨着 AI 的發展”“在這個時代”這類套話。
文章要有個人判斷，不能寫成中立報告。
必須寫清楚：AI 幫到了哪裏、沒幫到哪裏、爲什麼同一個工具在新人和老手手裏效果不同。
至少寫 3 個具體工作場景。
不要使用“賦能、重塑、生態、閉環、底層邏輯、範式、降維打擊”。
不要使用“不是……而是……”句式。
不要把每段都寫成短句金句。
結尾給出一個具體建議，不要昇華。
語氣自然，像一個真的內容團隊負責人寫的覆盤。
還挺快，兩分鐘不到就跑出來了！
文章整體讀下來還是比較順的，開頭也能把讀者拉住。
新人和老手的對比很加分，有真實管理經驗的味道，比單純講工具優缺點更有記憶點。
如果滿分 100 分，GLM-5.2 的寫作能力我可以給到 85 分。
case 7 指令遵循
有很多模型經常把我們的指令搞錯，看看GLM-5.2會不會有這樣的問題。
提示詞：
請根據以下規則處理文本。規則優先級從高到低排列，衝突時只服從更高優先級規則。
規則 A：最終答案只能輸出 4 條項目符號。
規則 B：每條項目符號必須少於 18 個中文字。
規則 C：必須保留原文裏的數字。
規則 D：不要出現「提升」「優化」「打造」。
原文：
這套系統預計 30 天上線，目標是提升客服響應速度，優化工單分配流程，打造統一服務入口，並把人工處理比例降低到 40%。
很不錯，4 條項目符號，每條少於 18 個中文字，保留數字，避開禁詞都滿足了
case 8 經典陷阱題
提示詞：我要去洗車，我家離洗車店50米，我是開車去好，還是走路去好？
還好，沒有落進陷阱裏，還溫馨提示可以先回來，等洗好再去取車。
case 9 PPT 製作
提示詞：
提示詞：請根據下面材料製作一份 8 頁以內的 PPTX，主題是「AI 工具在內容團隊的落地方案」。 要求： 包含封面、現狀問題、目標、流程設計、崗位分工、風險控制、試點計劃、結尾頁。 使用穩重的商務風格，不要卡通插畫。 每頁只保留必要文字，不能堆滿段落。 至少包含 1 張流程圖和 1 張表格。 生成可編輯 PPTX 文件，並導出預覽圖檢查版式。 材料如下：
項目背景：
公司是一家面向 B 端客戶的 SaaS 服務商，主要客戶來自制造、零售、教育和專業服務行業。內容團隊負責公衆號文章、客戶案例、產品白皮書、短視頻腳本、銷售資料和活動物料。
過去一年，內容需求明顯增加。市場部希望把月度內容產出從現在的 18 篇提升到 30 篇，其中包括：
公衆號深度文章 8 篇。
客戶案例 4 篇。
短視頻腳本 12 條。
行業資料整理 4 份。
銷售支持材料 2 份。
當前團隊已經嘗試過使用 AI 工具，但主要靠個人習慣，沒有統一流程。部分編輯用 AI 做資料整理和標題備選，部分編輯幾乎不用。產出質量不穩定，審覈標準也不統一。
團隊人數與角色：
內容團隊共 12 人：
內容負責人 1 人，負責選題方向、最終審覈、跨部門溝通。
資深編輯 3 人，負責深度文章、客戶案例、白皮書。
初級編輯 3 人，負責資料整理、初稿、短內容改寫。
短視頻編導 2 人，負責腳本、分鏡、口播文案。
設計師 1 人，負責封面圖、信息圖、PPT 視覺。
運營 1 人，負責公衆號發佈、數據回收、社羣分發。
數據分析 1 人，負責內容效果分析和月報。
當前主要問題：
資料整理耗時長。
一篇深度文章平均需要 6 到 8 小時做資料收集、摘錄和覈對。
初稿質量波動大。
初級編輯寫出的初稿經常結構完整，但觀點不夠明確，返工率約 38%。
標題和摘要依賴經驗。
不同編輯寫法差異大，同一篇文章經常要反覆改 4 到 6 版標題。
客戶案例生產慢。
採訪錄音轉文字後，需要人工整理重點，平均一篇案例從採訪到成稿需要 7 天。
內容複用不足。
一篇白皮書很少被拆成短視頻腳本、銷售話術、社羣短文，素材利用率不高。
風險控制不穩定。
AI 生成內容偶爾會出現事實錯誤、引用不明、誇大產品效果、語氣過度營銷等問題。
現有數據：
當前月均產出：18 篇內容。
目標月均產出：30 篇內容。
深度文章平均製作週期：3.5 天。
客戶案例平均製作週期：7 天。
初稿返工率：38%。
資料整理平均耗時：每篇 6 到 8 小時。
標題平均修改輪次：4 到 6 輪。
內容發佈後 7 日內平均閱讀完成率：42%。
銷售團隊每月臨時資料需求：約 15 次。
落地目標：
3 個月內把月度內容產出提升到 30 篇。
把深度文章資料整理時間減少 40%。
把客戶案例製作週期從 7 天縮短到 4 天。
把初稿返工率從 38% 降到 25% 以下。
建立統一的 AI 使用規範和審覈清單。
每篇重點內容至少複用成 3 種形式，比如公衆號文章、短視頻腳本、銷售話術。
可使用工具清單：
ChatGPT 或同類大模型：用於資料摘要、提綱、標題備選、初稿改寫。
Perplexity 或同類搜索工具：用於公開資料檢索和來源追蹤。
飛書文檔：用於協作、版本管理、審批流。
Notion 或知識庫工具：用於保存行業資料、客戶案例、提示詞模板。
剪映或 CapCut：用於短視頻腳本拆分、字幕初稿。
Excel 或 Google Sheets：用於內容數據統計。
Midjourney 或即夢：用於概念圖、封面方向參考，但正式商用圖必須由設計師確認。
Grammarly 或中文校對工具：用於錯別字、語病、標點檢查。
建議流程：
選題階段：內容負責人確定主題、目標讀者、核心觀點。
資料階段：初級編輯用 AI 整理資料摘要，必須保留來源鏈接。
提綱階段：資深編輯確定文章結構和主觀點。
初稿階段：AI 輔助生成段落草稿，作者負責判斷和改寫。
審覈階段：使用事實覈查清單、品牌語氣清單、敏感表述清單。
複用階段：把長文拆成短視頻腳本、社羣短文、銷售話術。
覆盤階段：運營和數據分析每週回收閱讀、轉化、完讀率數據。
崗位分工建議：
內容負責人：確定選題優先級、審覈核心觀點、審批發布。
資深編輯：負責文章判斷、提綱、最終改稿。
初級編輯：負責資料整理、初稿生成、來源標註。
短視頻編導：把長文拆成腳本、口播稿、分鏡。
設計師：負責視覺風格、封面圖、信息圖。
運營：負責發佈排期、分發渠道、評論反饋整理。
數據分析：負責效果追蹤、月度報告、選題建議。
風險控制要求：
所有事實、數據、引用必須人工複覈。
AI 生成內容不能直接發佈。
涉及客戶名稱、合同信息、銷售數據時，不得輸入公開 AI 工具。
產品能力描述必須由產品或售前確認。
醫療、金融、法律等敏感行業內容需要額外審覈。
所有 AI 生成圖片必須檢查版權和商用風險。
文章最終觀點必須由作者本人確認，不能只採用 AI 結論。
預算：
試點期預算爲 9 萬元，週期 3 個月。
預算拆分：
AI 工具賬號：3 萬元。
內部培訓和提示詞模板建設：2 萬元。
知識庫整理和流程配置：1.5 萬元。
設計和視頻輔助工具：1.5 萬元。
預留費用：1 萬元。
時間安排：
第 1 周：確認試點範圍，選定工具，建立賬號權限。
第 2 周：整理常用提示詞模板和審覈清單。
第 3 到 4 周：選擇公衆號文章和客戶案例兩個內容類型做小範圍試點。
第 5 到 8 周：擴大到短視頻腳本和銷售資料，開始每週覆盤。
第 9 到 10 周：根據數據調整流程，補充風險控制規則。
第 11 到 12 周：形成正式 SOP，輸出試點報告和下一階段預算建議。
試點範圍：
第一階段只覆蓋 4 類內容：
公衆號深度文章。
客戶案例。
短視頻腳本。
銷售支持材料。
暫不納入：
高管署名文章。
重大品牌發佈稿。
涉及未公開客戶數據的內容。
法務風險較高的行業報告。
衡量指標：
月度內容產出數量。
單篇內容平均製作週期。
資料整理耗時。
初稿返工率。
標題修改輪次。
發佈後 7 日閱讀完成率。
銷售團隊對資料可用性的評分。
AI 內容審覈發現的問題數量。
預期結果：
3 個月試點後，內容團隊應該形成一套可複用的 AI 工作流程。AI 主要承擔資料整理、結構草稿、標題備選、內容複用和數據初篩工作。核心觀點、事實覈查、客戶表達和最終發佈判斷仍由人工負責。
任務需求方面是達標的，能看出來對項目內容理解很透，審美也還算合格，已經算可以使用了，人工稍微再精細調整一下就能直接拿去彙報。
02. 一些分享
GLM-5.2 測下來之後，感覺前面幾個榜單或許還真沒啥水分。任務的結果我覺得都很牛，國內模型的頂尖水平了，不僅能跑，能用，還用着舒服。
以前上班的時候，資料整理、代碼初版、頁面搭建、PPT 結構、測試樣例，都要一點點磨，現在可以交給模型先跑一版，人把精力放回判斷和取捨上。
我對 GLM-5.2 的評價是：上限高，完成度也穩，已經值得放進日常工作流裏認真試用。至於能不能長期留下來，還要看後面幾周高頻使用時，模型在細節、穩定性和成本上的表現。
以後接 API 的時候，或許根本分不清接的是 GLM-5.2 還是 Claude oups 了。
原文鏈接：GLM-5.2 實測，中國模型真的到第一梯隊了
