實測GLM-4.5：開發出網頁版Excel，成本不到一杯奶茶錢

上周，智譜 AI 正式發布開源旗艦 MoE 架構大模型 GLM?4.5，包含主模型（ 355B 總參數，激活參數 32B ）和輕量版本 GLM?4.5?Air（ 106B 總參數，激活12B ）。

和 Kimi K2、Qwen3 Coder 類似，GLM?4.5 也是專為智能體任務打造，擅長推理、編程及工具自動調用能力。并且，參數量更少，只有 DeepSeek-R1 的 1/2、Kimi-K2 的 1/3。

API 價格上也相當實惠，即便不算當前的限時優惠，輸入成本最高（ 輸入長度 32K-128K 范圍內 ）4 元/百萬 token，輸出成本最高 16 元/百萬 token，這和 Kimi-K2 是一致的。之前知危曾提到，寫 4 個小游戲和一個游戲網站，Kimi-K2只花了不到 17 塊錢。當然，每個模型的 token 輸出量和調用工具次數有自己的特點，最終的成本消耗不能只看價格。

話不多說，這就隨手先在網頁端（ chat.z.ai ）上測一測。

簡單的 Flappy Bird、2048、Dino Run 等小游戲都沒問題，z.ai 還提供了 artifact 功能即時演示效果。并且知危注意到，游戲界面的審美都是很舒服的。

一鍵生成網站也挺有驚喜，讓 GLM-4.5 生成淘寶網站，商品卡片、篩選、搜索、加購物車、付款、登錄功能，都全了，操作邏輯也沒問題。就是有一個 Bug，搜索撤銷之后，商品頁狀態無法還原。

然后也是老規矩，寫植物大戰僵尸。結果第一版就有比較完整的視覺，代碼審美至少第一版來說是目前看過同類模型寫的最好的，Bug 不少，但能正常游玩。

迭代了第二版，修改了很多問題，包括：

• 草坪和有效區域位置沒有對齊，
• 僵尸移動速度太快，
• 缺乏開始游戲、暫停游戲、重置游戲的功能，
• 缺少僵尸剩余數量計數功能，
• 缺少櫻桃炸彈植物，

第二版邏輯上已經比較完整，雖然解決完舊問題可能會出現新問題，但迭代能力還是值得認可的。

在前幾期，知危已經測試了 Kimi-K2（ 在 Claude Code 調用 ）、CodeBuddy（ 基于 Claude 4 Sonnet ）寫網頁游戲的極限表現，并在開發《 植物大戰僵尸 》的 “ 無限生存模式 ” 上推到了新的高度，代碼行數約為 2500 行，屬于初級或中級開發者的難度。

但辦公場景應用就不同了，據了解，早期的 WPS 已經是百萬行級別的代碼量，場景復雜度更是不在一個量級，需要中高級開發者或團隊才能完成。

知危想測試代碼智能體在這個更具挑戰的場景下能推進到什么程度。這就拿 GLM-4.5 試試，寫一個網頁版的 Excel 。

首先，知危分別嘗試了 z.ai 上的 artifact 和全棧開發，來寫網頁版 Excel。

提示詞：

幫我寫一個網頁版excel，實現以下功能：

• 網格渲染：1000x1000 單元格虛擬渲染，滾動性能良好；
• 單元格編輯：雙擊進入編輯狀態，支持 Enter/Tab 移動，空值/默認值處理；
• 格式設置：字體大小、加粗、對齊、背景色（toolbar + 屬性欄）；

artifact 選用常規的 HTML/CSS/JavaScript 技術棧，寫出了基本的形態，但 Bug 不少。比如列號和行號重合了，傾斜功能用不了，清除格式也用不了等等。

全棧開發模式選用了比 HTML/CSS/JavaScript 更復雜的技術棧：

文件組成也完全不同：

該模式下開發的初版就有很驚艷的效果，審美極佳，基礎輸入邏輯和滾動邏輯也都沒問題，UI 左邊還有詳細的單元格狀態欄展示。只是有更嚴重的 Bug，設置樣式、對齊、顏色就會報錯，也沒修復成功。

而且，當前 z.ai 只能維護一個項目的工作空間，替換項目后代碼容易丟失，不利于長期維護。

為了具備可靠的迭性，知危選擇和測試 Kimi-K2 類似的方式，將 GLM-4.5 接入 Claude Code，并在 Cursor 的終端里使用。

智譜官方文檔（ bigmodel.cn ）也提供了接入方式說明。

這一次，知危全程沒看過代碼一眼，畢竟不像游戲，連數值都不需要調，所以就不展示 Claude Code 生成過程和代碼細節了。

接入 Claude Code 完成后，正式開始網頁版 Excel 的開發！

第一版使用了和前面一樣的提示詞。

在 Claude Code 框架下，GLM-4.5 還是選擇了更簡單的 HTML/CSS/JavaScript 技術棧。

初版已經有較完善的單元格編輯功能，包括：

• 雙擊進入編輯，Enter保存輸入并自動跳到右一格；
• 還能給字體加粗、傾斜，調整字體大小，調整居中、居左、居右對齊，添加背景顏色；
• 一鍵清除格式；

就是滾動功能有一個很明顯的 Bug，行號和列號都使用和單元格獨立的滾動條，以至于不能對齊。

另一個對實用性影響較小的 Bug 是，雙擊進入編輯后，編輯框是偏離了單元格固定方向的紅色框，但畢竟不太好看。

Excel 官方設置里，格式欄和單元格之間，有名稱框和編輯欄，名稱框顯示單元格坐標，是沒問題的，編輯欄對應當前選中的單元格的值，官方設置是可編輯的，而目前 GLM-4.5 實現的版本是無法編輯的。

后續，我還想對齊 Excel，給字體增加更多格式，Enter/Tab 鍵移動方向和官方設置一致，修復滾動和編輯方面的 Bug，于是直接給 GLM-4.5 提了以下需求：

• 格式設置再加上下劃線、刪除線功能；
• Enter 鍵讓單元格向下移動，Tab 鍵讓單元格向右移動；
• 編輯欄應該是可編輯的，而不是只能靜態顯示單元格的值；
• 橫坐標（ A，B，C 等 ）、縱坐標（ 1，2，3 等 ）需要和單元格直接對齊，不需要單獨的滾動條，請修復；
• 雙擊單元格后會出現偏離單元格的編輯框，請將其與非編輯狀態的單元格重合；

這一版的結果，第一個需求有名無實，有功能鍵但沒實際效果，第二、三個需求實現了，第四個需求實現了一半，列號對齊了，行號出現了新的問題，每個坐標下多了一個間隔，第五個需求完全沒實現。

Enter/Tab 鍵目前只能移動一次，而 Excel 官方設置下每按一次都會移動單元格。

為修復這些殘留問題，繼續給模型提了以下需求：

• 下劃線、刪除線功能點擊后沒有對單元格格式產生實際效果，請修復；
• 加粗、傾斜、下劃線、刪除線按鈕的點擊效果（ 變成綠色 ）沒有互相獨立，請修復；
• Enter鍵讓單元格向下移動，Tab鍵讓單元格向右移動，這應該是持續有效的，請修復；
• 縱坐標（ 1，2，3 等 ）沒有和單元格正確對齊，請修復；
• 雙擊單元格后會出現偏離單元格的編輯框，請將其與非編輯狀態的單元格重合；

跑完這個需求，Claude Code 就提示我，已經花費了 5 美元。

我去 GLM-4.5 后臺（ bigmodel.cn ）看了一下，贈送的 200 萬通用 token 資源包花費了 33 萬 token 。

按目前 GLM-4.5 的資源包價格計算（ 目前有 1 折優惠，6.9 人民幣/1000 萬 token ），相當于花費了兩毛錢，就算以后沒有優惠了，也就需要兩塊錢成本。

這一版也不令人滿意，GLM-4.5 只修復了下劃線、刪除線生效，以及 Enter/Tab 鍵持續移動的功能，其它需求都沒有滿足。

查看這時的代碼總行數，大概 800 行，對于 GLM-4.5 的上下文長度 128K 而言不算多（ 這個長度預計能支持 2000 行左右的代碼生成和編輯 ）。

但為可靠性起見，只能先認定接下來一次只能可靠修復 1-2 個錯誤，于是我把需求拆分，一次只提一個，每次修改都在本地備份源代碼。

接下來的需求是繼續解決試用后發現的新問題：

• 加粗、傾斜、下劃線、刪除線按鈕的點擊效果（變成綠色）沒有互相獨立，也沒有和對齊按鈕互相獨立，請修復；

對這個需求，GLM-4.5 只修復了和對齊格式之間的獨立性，字體格式功能鍵的獨立性仍然沒有實現。

這時候我意識到，我使用的提示詞表述其實不太規范，而 Excel 問世了那么多年，很多術語應該都標準化了。

知危與業內在企業內部落地代碼智能體的技術專家的交流中也了解到，即便是代碼智能體如此強大的當下，提示詞的專業性、規范性對智能體的表現的影響也是非常顯著的。

于是接下來，我將提的每一個需求，都先發給 ChatGPT 優化，再發給 GLM-4.5。

對以下提示詞：

• 加粗、傾斜、下劃線、刪除線按鈕的生效狀態（ 變成綠色 ）沒有互相獨立，也沒有基于每個單元格獨立顯示格式狀態，請修復；

ChatGPT 提供了更專業和規范的版本：

問題描述： 富文本工具欄中的加粗、傾斜、下劃線、刪除線按鈕的狀態顯示存在問題：

• 當前行為： 按鈕的“激活狀態”（變為綠色）未基于當前選中單元格的格式屬性單獨反映，且不同按鈕間狀態非獨立控制。
• 期望行為： 各格式按鈕應當根據當前選中的單元格樣式獨立判斷激活狀態，即：
• 若某單元格已加粗，則“加粗”按鈕應自動呈激活狀態；
• 各按鈕的狀態應互不影響，且與其他單元格無關；

請修復上述狀態同步邏輯，使按鈕狀態與選中單元格的實際格式保持一致。

這回終于成功解決了這個問題。

然后，我按同樣的方式解決雙擊單元格出現的編輯框與原單元格不重合的問題，為簡單起見就不再展示 ChatGPT 優化后的提示詞。

原提示詞：

• 雙擊單元格后會出現偏離單元格的編輯框，請將其與非編輯狀態的單元格重合；

結果發現這個問題很磨人，雖然解決了，但出現了新的問題，Enter/Tab 鍵失效了，跳到其它單元格后原來編輯的內容不能保存。

于是我繼續提修復需求：

• 現在編輯態下的輸入框與該單元格在非編輯狀態下的邊界已經完全重合，但輸入內容后，按enter鍵無法向下一個單元格跳躍，如果切換選中的單元格，原來單元格輸入的內容也沒有保存，請修復。

然后，編輯框就暴走了，成了雙擊激活的剪貼板。

到這里，只能先判斷編輯框的問題不好修復，暫且擱置，這時候就能感受到 vibe coding 中隨時本地備份的重要性。

我跳回修復了字體格式獨立性的版本，繼續迭代。（ 注意這種情況下，除了替換文件夾中的源代碼，也要清理 Claude Code 的上下文，在終端中輸入 /clear 就可以 ）

然后，我就開始修復縱坐標（ 行號 ）與單元格對齊的問題：

• 縱坐標（ 1，2，3 等 ）在滾動后就沒有和單元格正確對齊，而是坐標的每個值之間多了一個單元格的距離，請修復；

修改失敗，但沒有出現新的問題。

接下來，我在官方文檔了解到，GLM-4.5 在調用模型時不是默認最強的版本，而是會通過多因素權衡來靈活調用 GLM-4.5 或 GLM-4.5-Air 。

https://docs.bigmodel.cn/cn/guide/develop/claude

因此，為保證能夠解決更難的Bug，我參考官網說明修改了～/.claude/settings.json 文件，強制只使用最強模型。

并嘗試加強思考強度。Claude Code 有一個重要的使用技巧是，在提示詞中增加一些關鍵詞，可以極大提高解決問題的能力，當然 token 使用量也會暴增。

具體來說，只要在提示詞最后加上“ think ”或 “ think hard ”、“ think harder ”、“ ultrathink ”，就能讓模型更積極地思考。

思考強度排序如下：

“ think ” < “ think hard ” < “ think harder ” < “ ultrathink ”

其實我并不確定這個提示詞對 Claude 以外的模型是否管用，但畢竟提示詞比程序靈活多了，試試也無妨。

這是我接下來使用的提示詞（ 經過了 ChatGPT 優化 ）：

問題描述： 在滾動表格區域后，縱向坐標（即左側行號，如1、2、3等）未與對應行正確對齊。滾動后，每個行號之間多出一個單元格高度的間距，導致視覺錯亂。

期望行為： 左側行號（縱坐標）應始終與對應的數據行精確對齊，滾動不應引入錯位或間距異常。

請修復行號渲染或滾動同步邏輯，確保其與內容區域垂直對齊。

Think hard

這一次真的成功了！雖然還有些位置偏移，但問題不大，token 一次性消耗了 10 萬，按 GLM-4.5 的價格，也是能接受的。

為了修復位置偏移的問題，我繼續提需求，并加上 “ think harder ” 再提高一級思考強度，也是花費了 10 萬 token，把問題解決了。

到這里，Excel 開發的第一階段就基本完成了，雖然編輯框對齊問題沒有解決有些難受，但因為不影響實用性，所以還能接受。debug 了許多步，代碼還是維持在 800 行的規模。

雖然 debug 過程磕磕絆絆，但也算是摸索出了不少使用的技巧。即便 GLM-4.5 暫時還趕不上頂級編程模型的順暢體驗，疊加提示詞優化、強制模型選擇、思考加強等 “ 魔法 ”，最終還是能順利地完成任務。

在第二階段，知危打算繼續實現更多新功能，包括：

• 添加/刪除行列操作
• 復制剪切粘貼操作和快捷鍵
• 行列選中和復制剪切操作
• 撤銷、恢復功能鍵和快捷鍵
• 行列拉伸操作
• 單元格多選、行列多選操作
• 格式刷功能鍵

到這一步，其實每個需求看似簡單，經過 ChatGPT 拆解后發現存在大量細節，需要注意很多潛在的問題。

比如，增加行列的操作，原提示詞是這樣的（ 為保證運行效果，都加了第三等級的思考加強 “ think harder ” ）：

• 增加行列操作，支持單擊行號、列號后，按=鍵往下添加1行，按-鍵刪除該行，并自動調整行號或列號。

經過 ChatGPT 拆解，是這樣的，ChatGPT 特別提醒實現功能時避免空值錯誤，刪除后坐標需要重排：

功能名稱： 行列快捷操作支持（ 基于行號/列號點擊 ）

功能說明： 用戶在點擊左側行號或頂部列號后，可通過鍵盤快捷鍵快速添加或刪除整行/整列，具體行為如下：

功能行為定義：

添加行（ 或列 ）

操作方式： 單擊選中某一行號（ 或列號 ）后，按下 = 鍵；

效果： 在當前行（ 或列 ）下方插入一行（ 或右側插入一列 ）；

后續處理： 自動更新所有行號（ 或列號 ）以保持連續性。

刪除行（ 或列 ）

操作方式： 單擊選中某一行號（ 或列號 ）后，按下 - 鍵；

效果： 刪除當前選中的行（ 或列 ）；

后續處理： 自動更新所有行號（ 或列號 ）以保持正確順序。

注意事項：

快捷鍵生效前提是當前焦點在行號/列號區域；

刪除操作需避免刪除最后一行或列（ 可添加最小保護機制 ）；

添加/刪除后，需觸發表格內容重排，并同步更新 UI；

Think harder

還有就是內存管理也會越來越復雜，很多中間狀態在 UI 上是看不到的，但必須維護。比如實現撤銷恢復功能時，如果不加管控，內存可能不知不覺就爆炸。這是 ChatGPT 在優化實現撤銷恢復提示詞時增加的提醒：

限制建議：

加入最大撤銷層數限制（ 默認 100 層 ）以控制內存；

頁面刷新或數據清空應清除操作棧；

只經過一次 debug，添加/刪除行列操作就實現了。

實現復制剪切剪切操作、行列選中和復制剪切、撤銷和恢復操作、單元格拉伸操作（ 單元格不是獨立拉伸的，時間關系就沒修復，畢竟也能用 ），都很順利。需要注意的一點是由于功能拆解更復雜，所以都用了 “ Ultrathink ” 思考加強，每跑一次大概花費 30 萬 token 。

當然，這些功能也不是沒有小毛病，比如復制剪切后只能粘貼一次，選中行列后只能復制剪切不能統一修改字體格式等。

在實現多單元格選中、多行選中功能時，可能代碼長度已經逼近模型上下文極限了（ 代碼總行數 1800 行左右 ），每次清空上下文跑一次都會觸發 Claude Code 自動壓縮上下文。

甚至，模型還跑偏了方向，實現的功能和需求完全不搭邊，并花費了 100 萬 token 。

因此，我放棄了這個功能以及格式刷功能鍵的實現，也放棄了最難的數值計算、數據檢索、數據可視化功能，只在第三階段補充比較簡單的需求，把項目收尾。

在收尾階段，關注的是外部因素，實現其作為辦公產品的完整形態，包括里子和面子：

• .json和.csv文件導出；
• 整體UI的美化；

這兩步都挺順利地實現了。以下是網頁上的數據狀態：

以下是分別導出的 .json 文件和 .csv 文件在微軟官方 Excel 上打開的樣子（ .json 文件也要把后綴改成 .csv 才能用官方 Excel 打開 ）：

最后一步的 UI 優化效果，還是很驚艷的，風格變化不大，但各種細節上的優化包括滾動動畫、陰影、漸變等，使得視覺感受舒服了很多，GLM-4.5 再次展現了它的代碼審美水平。

至此，我們對 GLM-4.5 的評測結束。

其實，《 植物大戰僵尸 》的 2500 行代碼已經能逼近 Claude 4 Sonnet 處理的極限（ 上下文長度 200K ）。而具備 128K 上下文長度的 GLM-4.5，最終在網頁版 Excel 的開發中，寫下了接近 3000 行代碼，完成了高度可交互的原型，已是相當亮眼的成績。

最終消耗的 token 總數是 600 萬，按當前 GLM-4.5 資源包價格算，大約 4 塊錢成本，按非優惠的輸入 token 價格 4 元/百萬 token 計算（ 相比輸出消耗占大部分 ），并不計緩存，也就是 24 塊錢，常規使用的成本消耗大概會在 4-24 元的范圍內。

在開發過程中，知危對代碼智能體的邊界有了更深的體會。

GLM?4.5 的確具備了中高級開發者的 “ 戰力 ”—— 它能一次性生成基礎功能完整、界面美觀、代碼風格統一的產品雛形，幾百行代碼量的模塊也能較快成型，審美在目前所有中文編程大模型中屬于第一梯隊。

但項目越往深走，便越顯艱難。網頁版 Excel 作為一款典型的高交互辦公應用，不僅功能多，而且每個功能都牽一發而動全身。

Excel 處理的對象是更抽象的文本或數據，格式、復制、數值計算等操作什么時候需要批量執行、什么時候需要獨立執行，有更大變化空間；長鏈路操作下如何維護和優化內存，都會帶來新的復雜度；在迭代上，新功能是否需要泛化到其它操作，也是很關鍵的問題；而且，這是工具型應用，用戶精度要求高，不像《 植物大戰僵尸 》，僵尸判定攻擊的距離、植物與草坪對齊的程度等事件，可以有很大的彈性空間。因此，每多一個新功能，都可能給已有邏輯帶來干擾和未知的 Bug。

這就對模型的持續調試能力、上下文一致性認知提出了很高的要求。

GLM?4.5 雖然上下文長度達到 128 K，可以支撐較長的代碼編輯，但一旦進入 800-1800 行的范圍，模型對已有代碼的理解和操作準確性也會顯著下降。

因此，我需要將需求拆成小塊、頻繁清空上下文、保存本地代碼快照，并搭配提示詞的結構化描述、術語標準化表達和 “ 思考強度增強 ”（ 如 “ think harder ”、“ ultrathink ” ）等方法，才能維持開發穩定性。這些 “ 魔法技巧 ” 不是普通用戶（ 比如網頁端用戶 ）能隨手掌握的。

相比之下，像《 植物大戰僵尸 》這類小游戲，雖然邏輯上涉及實時狀態、動畫驅動和事件聯動，數值調整需要手動操作，測試的時間成本較高。但模塊結構清晰，Bug 容忍度高，不涉及長鏈路狀態維護，因此智能體處理起來更輕松。后續即便不在優化上花功夫，也可以直接通過代碼微調和模塊組合來豐富關卡設計。

而類似 Excel 這種復雜的、抽象的數據型應用場景，將是智能體必須攻克的高地。