實(shí)測GLM-4.5：開發(fā)出網(wǎng)頁版Excel，成本不到一杯奶茶錢

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

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

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

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

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

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

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

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

• 草坪和有效區(qū)域位置沒有對(duì)齊，
• 僵尸移動(dòng)速度太快，
• 缺乏開始游戲、暫停游戲、重置游戲的功能，
• 缺少僵尸剩余數(shù)量計(jì)數(shù)功能，
• 缺少櫻桃炸彈植物，

第二版邏輯上已經(jīng)比較完整，雖然解決完舊問題可能會(huì)出現(xiàn)新問題，但迭代能力還是值得認(rèn)可的。

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

但辦公場景應(yīng)用就不同了，據(jù)了解，早期的 WPS 已經(jīng)是百萬行級(jí)別的代碼量，場景復(fù)雜度更是不在一個(gè)量級(jí)，需要中高級(jí)開發(fā)者或團(tuán)隊(duì)才能完成。

知危想測試代碼智能體在這個(gè)更具挑戰(zhàn)的場景下能推進(jìn)到什么程度。這就拿 GLM-4.5 試試，寫一個(gè)網(wǎng)頁版的 Excel 。

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

提示詞：

幫我寫一個(gè)網(wǎng)頁版excel，實(shí)現(xiàn)以下功能：

• 網(wǎng)格渲染：1000x1000 單元格虛擬渲染，滾動(dòng)性能良好；
• 單元格編輯：雙擊進(jìn)入編輯狀態(tài)，支持 Enter/Tab 移動(dòng)，空值/默認(rèn)值處理；
• 格式設(shè)置：字體大小、加粗、對(duì)齊、背景色（toolbar + 屬性欄）；

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

全棧開發(fā)模式選用了比 HTML/CSS/JavaScript 更復(fù)雜的技術(shù)棧：

文件組成也完全不同：

該模式下開發(fā)的初版就有很驚艷的效果，審美極佳，基礎(chǔ)輸入邏輯和滾動(dòng)邏輯也都沒問題，UI 左邊還有詳細(xì)的單元格狀態(tài)欄展示。只是有更嚴(yán)重的 Bug，設(shè)置樣式、對(duì)齊、顏色就會(huì)報(bào)錯(cuò)，也沒修復(fù)成功。

而且，當(dāng)前 z.ai 只能維護(hù)一個(gè)項(xiàng)目的工作空間，替換項(xiàng)目后代碼容易丟失，不利于長期維護(hù)。

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

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

這一次，知危全程沒看過代碼一眼，畢竟不像游戲，連數(shù)值都不需要調(diào)，所以就不展示 Claude Code 生成過程和代碼細(xì)節(jié)了。

接入 Claude Code 完成后，正式開始網(wǎng)頁版 Excel 的開發(fā)！

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

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

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

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

就是滾動(dòng)功能有一個(gè)很明顯的 Bug，行號(hào)和列號(hào)都使用和單元格獨(dú)立的滾動(dòng)條，以至于不能對(duì)齊。

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

Excel 官方設(shè)置里，格式欄和單元格之間，有名稱框和編輯欄，名稱框顯示單元格坐標(biāo)，是沒問題的，編輯欄對(duì)應(yīng)當(dāng)前選中的單元格的值，官方設(shè)置是可編輯的，而目前 GLM-4.5 實(shí)現(xiàn)的版本是無法編輯的。

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

• 格式設(shè)置再加上下劃線、刪除線功能；
• Enter 鍵讓單元格向下移動(dòng)，Tab 鍵讓單元格向右移動(dòng)；
• 編輯欄應(yīng)該是可編輯的，而不是只能靜態(tài)顯示單元格的值；
• 橫坐標(biāo)（ A，B，C 等 ）、縱坐標(biāo)（ 1，2，3 等 ）需要和單元格直接對(duì)齊，不需要單獨(dú)的滾動(dòng)條，請(qǐng)修復(fù)；
• 雙擊單元格后會(huì)出現(xiàn)偏離單元格的編輯框，請(qǐng)將其與非編輯狀態(tài)的單元格重合；

這一版的結(jié)果，第一個(gè)需求有名無實(shí)，有功能鍵但沒實(shí)際效果，第二、三個(gè)需求實(shí)現(xiàn)了，第四個(gè)需求實(shí)現(xiàn)了一半，列號(hào)對(duì)齊了，行號(hào)出現(xiàn)了新的問題，每個(gè)坐標(biāo)下多了一個(gè)間隔，第五個(gè)需求完全沒實(shí)現(xiàn)。

Enter/Tab 鍵目前只能移動(dòng)一次，而 Excel 官方設(shè)置下每按一次都會(huì)移動(dòng)單元格。

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

• 下劃線、刪除線功能點(diǎn)擊后沒有對(duì)單元格格式產(chǎn)生實(shí)際效果，請(qǐng)修復(fù)；
• 加粗、傾斜、下劃線、刪除線按鈕的點(diǎn)擊效果（ 變成綠色 ）沒有互相獨(dú)立，請(qǐng)修復(fù)；
• Enter鍵讓單元格向下移動(dòng)，Tab鍵讓單元格向右移動(dòng)，這應(yīng)該是持續(xù)有效的，請(qǐng)修復(fù)；
• 縱坐標(biāo)（ 1，2，3 等 ）沒有和單元格正確對(duì)齊，請(qǐng)修復(fù)；
• 雙擊單元格后會(huì)出現(xiàn)偏離單元格的編輯框，請(qǐng)將其與非編輯狀態(tài)的單元格重合；

跑完這個(gè)需求，Claude Code 就提示我，已經(jīng)花費(fèi)了 5 美元。

我去 GLM-4.5 后臺(tái)（ bigmodel.cn ）看了一下，贈(zèng)送的 200 萬通用 token 資源包花費(fèi)了 33 萬 token 。

按目前 GLM-4.5 的資源包價(jià)格計(jì)算（ 目前有 1 折優(yōu)惠，6.9 人民幣/1000 萬 token ），相當(dāng)于花費(fèi)了兩毛錢，就算以后沒有優(yōu)惠了，也就需要兩塊錢成本。

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

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

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

接下來的需求是繼續(xù)解決試用后發(fā)現(xiàn)的新問題：

• 加粗、傾斜、下劃線、刪除線按鈕的點(diǎn)擊效果（變成綠色）沒有互相獨(dú)立，也沒有和對(duì)齊按鈕互相獨(dú)立，請(qǐng)修復(fù)；

對(duì)這個(gè)需求，GLM-4.5 只修復(fù)了和對(duì)齊格式之間的獨(dú)立性，字體格式功能鍵的獨(dú)立性仍然沒有實(shí)現(xiàn)。

這時(shí)候我意識(shí)到，我使用的提示詞表述其實(shí)不太規(guī)范，而 Excel 問世了那么多年，很多術(shù)語應(yīng)該都標(biāo)準(zhǔn)化了。

知危與業(yè)內(nèi)在企業(yè)內(nèi)部落地代碼智能體的技術(shù)專家的交流中也了解到，即便是代碼智能體如此強(qiáng)大的當(dāng)下，提示詞的專業(yè)性、規(guī)范性對(duì)智能體的表現(xiàn)的影響也是非常顯著的。

于是接下來，我將提的每一個(gè)需求，都先發(fā)給 ChatGPT 優(yōu)化，再發(fā)給 GLM-4.5。

對(duì)以下提示詞：

• 加粗、傾斜、下劃線、刪除線按鈕的生效狀態(tài)（ 變成綠色 ）沒有互相獨(dú)立，也沒有基于每個(gè)單元格獨(dú)立顯示格式狀態(tài)，請(qǐng)修復(fù)；

ChatGPT 提供了更專業(yè)和規(guī)范的版本：

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

• 當(dāng)前行為： 按鈕的“激活狀態(tài)”（變?yōu)榫G色）未基于當(dāng)前選中單元格的格式屬性單獨(dú)反映，且不同按鈕間狀態(tài)非獨(dú)立控制。
• 期望行為： 各格式按鈕應(yīng)當(dāng)根據(jù)當(dāng)前選中的單元格樣式獨(dú)立判斷激活狀態(tài)，即：
• 若某單元格已加粗，則“加粗”按鈕應(yīng)自動(dòng)呈激活狀態(tài)；
• 各按鈕的狀態(tài)應(yīng)互不影響，且與其他單元格無關(guān)；

請(qǐng)修復(fù)上述狀態(tài)同步邏輯，使按鈕狀態(tài)與選中單元格的實(shí)際格式保持一致。

這回終于成功解決了這個(gè)問題。

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

原提示詞：

• 雙擊單元格后會(huì)出現(xiàn)偏離單元格的編輯框，請(qǐng)將其與非編輯狀態(tài)的單元格重合；

結(jié)果發(fā)現(xiàn)這個(gè)問題很磨人，雖然解決了，但出現(xiàn)了新的問題，Enter/Tab 鍵失效了，跳到其它單元格后原來編輯的內(nèi)容不能保存。

于是我繼續(xù)提修復(fù)需求：

• 現(xiàn)在編輯態(tài)下的輸入框與該單元格在非編輯狀態(tài)下的邊界已經(jīng)完全重合，但輸入內(nèi)容后，按enter鍵無法向下一個(gè)單元格跳躍，如果切換選中的單元格，原來單元格輸入的內(nèi)容也沒有保存，請(qǐng)修復(fù)。

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

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

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

然后，我就開始修復(fù)縱坐標(biāo)（ 行號(hào) ）與單元格對(duì)齊的問題：

• 縱坐標(biāo)（ 1，2，3 等 ）在滾動(dòng)后就沒有和單元格正確對(duì)齊，而是坐標(biāo)的每個(gè)值之間多了一個(gè)單元格的距離，請(qǐng)修復(fù)；

修改失敗，但沒有出現(xiàn)新的問題。

接下來，我在官方文檔了解到，GLM-4.5 在調(diào)用模型時(shí)不是默認(rèn)最強(qiáng)的版本，而是會(huì)通過多因素權(quán)衡來靈活調(diào)用 GLM-4.5 或 GLM-4.5-Air 。

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

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

并嘗試加強(qiáng)思考強(qiáng)度。Claude Code 有一個(gè)重要的使用技巧是，在提示詞中增加一些關(guān)鍵詞，可以極大提高解決問題的能力，當(dāng)然 token 使用量也會(huì)暴增。

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

思考強(qiáng)度排序如下：

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

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

這是我接下來使用的提示詞（ 經(jīng)過了 ChatGPT 優(yōu)化 ）：

問題描述： 在滾動(dòng)表格區(qū)域后，縱向坐標(biāo)（即左側(cè)行號(hào)，如1、2、3等）未與對(duì)應(yīng)行正確對(duì)齊。滾動(dòng)后，每個(gè)行號(hào)之間多出一個(gè)單元格高度的間距，導(dǎo)致視覺錯(cuò)亂。

期望行為： 左側(cè)行號(hào)（縱坐標(biāo)）應(yīng)始終與對(duì)應(yīng)的數(shù)據(jù)行精確對(duì)齊，滾動(dòng)不應(yīng)引入錯(cuò)位或間距異常。

請(qǐng)修復(fù)行號(hào)渲染或滾動(dòng)同步邏輯，確保其與內(nèi)容區(qū)域垂直對(duì)齊。

Think hard

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

為了修復(fù)位置偏移的問題，我繼續(xù)提需求，并加上 “ think harder ” 再提高一級(jí)思考強(qiáng)度，也是花費(fèi)了 10 萬 token，把問題解決了。

到這里，Excel 開發(fā)的第一階段就基本完成了，雖然編輯框?qū)R問題沒有解決有些難受，但因?yàn)椴挥绊憣?shí)用性，所以還能接受。debug 了許多步，代碼還是維持在 800 行的規(guī)模。

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

在第二階段，知危打算繼續(xù)實(shí)現(xiàn)更多新功能，包括：

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

到這一步，其實(shí)每個(gè)需求看似簡單，經(jīng)過 ChatGPT 拆解后發(fā)現(xiàn)存在大量細(xì)節(jié)，需要注意很多潛在的問題。

比如，增加行列的操作，原提示詞是這樣的（ 為保證運(yùn)行效果，都加了第三等級(jí)的思考加強(qiáng) “ think harder ” ）：

• 增加行列操作，支持單擊行號(hào)、列號(hào)后，按=鍵往下添加1行，按-鍵刪除該行，并自動(dòng)調(diào)整行號(hào)或列號(hào)。

經(jīng)過 ChatGPT 拆解，是這樣的，ChatGPT 特別提醒實(shí)現(xiàn)功能時(shí)避免空值錯(cuò)誤，刪除后坐標(biāo)需要重排：

功能名稱： 行列快捷操作支持（ 基于行號(hào)/列號(hào)點(diǎn)擊 ）

功能說明： 用戶在點(diǎn)擊左側(cè)行號(hào)或頂部列號(hào)后，可通過鍵盤快捷鍵快速添加或刪除整行/整列，具體行為如下：

功能行為定義：

添加行（ 或列 ）

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

效果： 在當(dāng)前行（ 或列 ）下方插入一行（ 或右側(cè)插入一列 ）；

后續(xù)處理： 自動(dòng)更新所有行號(hào)（ 或列號(hào) ）以保持連續(xù)性。

刪除行（ 或列 ）

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

效果： 刪除當(dāng)前選中的行（ 或列 ）；

后續(xù)處理： 自動(dòng)更新所有行號(hào)（ 或列號(hào) ）以保持正確順序。

注意事項(xiàng)：

快捷鍵生效前提是當(dāng)前焦點(diǎn)在行號(hào)/列號(hào)區(qū)域；

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

添加/刪除后，需觸發(fā)表格內(nèi)容重排，并同步更新 UI；

Think harder

還有就是內(nèi)存管理也會(huì)越來越復(fù)雜，很多中間狀態(tài)在 UI 上是看不到的，但必須維護(hù)。比如實(shí)現(xiàn)撤銷恢復(fù)功能時(shí)，如果不加管控，內(nèi)存可能不知不覺就爆炸。這是 ChatGPT 在優(yōu)化實(shí)現(xiàn)撤銷恢復(fù)提示詞時(shí)增加的提醒：

限制建議：

加入最大撤銷層數(shù)限制（ 默認(rèn) 100 層 ）以控制內(nèi)存；

頁面刷新或數(shù)據(jù)清空應(yīng)清除操作棧；

只經(jīng)過一次 debug，添加/刪除行列操作就實(shí)現(xiàn)了。

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

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

在實(shí)現(xiàn)多單元格選中、多行選中功能時(shí)，可能代碼長度已經(jīng)逼近模型上下文極限了（ 代碼總行數(shù) 1800 行左右 ），每次清空上下文跑一次都會(huì)觸發(fā) Claude Code 自動(dòng)壓縮上下文。

甚至，模型還跑偏了方向，實(shí)現(xiàn)的功能和需求完全不搭邊，并花費(fèi)了 100 萬 token 。

因此，我放棄了這個(gè)功能以及格式刷功能鍵的實(shí)現(xiàn)，也放棄了最難的數(shù)值計(jì)算、數(shù)據(jù)檢索、數(shù)據(jù)可視化功能，只在第三階段補(bǔ)充比較簡單的需求，把項(xiàng)目收尾。

在收尾階段，關(guān)注的是外部因素，實(shí)現(xiàn)其作為辦公產(chǎn)品的完整形態(tài)，包括里子和面子：

• .json和.csv文件導(dǎo)出；
• 整體UI的美化；

這兩步都挺順利地實(shí)現(xiàn)了。以下是網(wǎng)頁上的數(shù)據(jù)狀態(tài)：

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

最后一步的 UI 優(yōu)化效果，還是很驚艷的，風(fēng)格變化不大，但各種細(xì)節(jié)上的優(yōu)化包括滾動(dòng)動(dòng)畫、陰影、漸變等，使得視覺感受舒服了很多，GLM-4.5 再次展現(xiàn)了它的代碼審美水平。

至此，我們對(duì) GLM-4.5 的評(píng)測結(jié)束。

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

最終消耗的 token 總數(shù)是 600 萬，按當(dāng)前 GLM-4.5 資源包價(jià)格算，大約 4 塊錢成本，按非優(yōu)惠的輸入 token 價(jià)格 4 元/百萬 token 計(jì)算（ 相比輸出消耗占大部分 ），并不計(jì)緩存，也就是 24 塊錢，常規(guī)使用的成本消耗大概會(huì)在 4-24 元的范圍內(nèi)。

在開發(fā)過程中，知危對(duì)代碼智能體的邊界有了更深的體會(huì)。

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

但項(xiàng)目越往深走，便越顯艱難。網(wǎng)頁版 Excel 作為一款典型的高交互辦公應(yīng)用，不僅功能多，而且每個(gè)功能都牽一發(fā)而動(dòng)全身。

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

這就對(duì)模型的持續(xù)調(diào)試能力、上下文一致性認(rèn)知提出了很高的要求。

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

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

相比之下，像《 植物大戰(zhàn)僵尸 》這類小游戲，雖然邏輯上涉及實(shí)時(shí)狀態(tài)、動(dòng)畫驅(qū)動(dòng)和事件聯(lián)動(dòng)，數(shù)值調(diào)整需要手動(dòng)操作，測試的時(shí)間成本較高。但模塊結(jié)構(gòu)清晰，Bug 容忍度高，不涉及長鏈路狀態(tài)維護(hù)，因此智能體處理起來更輕松。后續(xù)即便不在優(yōu)化上花功夫，也可以直接通過代碼微調(diào)和模塊組合來豐富關(guān)卡設(shè)計(jì)。

而類似 Excel 這種復(fù)雜的、抽象的數(shù)據(jù)型應(yīng)用場景，將是智能體必須攻克的高地。