实测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 这种复杂的、抽象的数据型应用场景，将是智能体必须攻克的高地。