首发于公众号「逻辑与温度」，同步发到掘金，希望帮到在两个工具之间纠结的人。
先说结论：模型没换，换的是壳。
过去几个月我日常写代码主力是 Claude Code，走 API 接 DeepSeek；最近把日常主力换成了 DSH（DeepSeek Harness，DeepSeek 官方开源的 Agent 工具，桌面端带图形界面，模型可以自己配）。原因不是「DSH 更聪明」——两边底层跑的是同一个 DeepSeek 模型，智商是同一颗。
那换的是什么？我设计了一个成本不到四毛钱的实测来回答这个问题：同一个需求，一字不差的提示词，发给两个壳，全程记录数据。
这篇你能拿到：
① 一套直接可抄的同题实测提示词（三轮）
② CLI 和 GUI 干活的完整对比数据：用时、轮次、花费，精确到分
③ 我关于「同一颗脑子，壳决定了什么」的判断
一、测试设计：同一颗脑子，两个壳
先交代公平性，懂行的读者帮我盯着：
- 同一个模型：两边都是 deepseek-flash（截图可证）
- 同一份提示词：一字不差，直接粘贴
- 同一天跑完，各自新开会话，中途不给任何额外提示
任务选的是「写页面」而不是写算法——原因很实际：页面好不好看，读者扫一眼截图就能自己判断；代码写得好不好，却要读者替我验证逻辑，门槛太高。
第一轮提示词原文（可抄）：
做一个个人介绍的单页网页，要求：
1. 单个 HTML 文件，浏览器直接打开就能用，不依赖任何外部资源
2. 包含：顶部头像占位区和姓名、一句个人简介、技术栈标签（8~10 个）、
三个项目卡片（标题+两行描述）、底部联系方式（邮箱/GitHub 占位）
3. 风格简洁现代，配色自己定
4. 做完告诉我文件叫什么、放在哪
二、第一轮：一个「陈默」，一个「林一舟」
两边都是一轮对话、零报错、一次通过。有意思的是过程数据：
| Claude Code（CLI） | DSH（GUI） | |
|---|---|---|
| 用时 | 28 秒 | 58 秒 |
| 轮次 | 1 次，通过 | 1 次，通过 |
| 报错/返工 | 无 | 无 |
| 消耗 | 约 7.6 万 token | 约 5.6 万 token |
| 花费 | 约 ¥0.085 | ¥0.095 |
| 缓存命中率 | 68.2% | 95.8% |
| 输出 token | 约 4,400（323 行代码） | 11,134（430 行代码） |
CLI 终端执行过程截图：Write index.html、Wrote 323 lines、Worked for 28s
CLI 侧用量统计：总成本 $0.01 / 请求 3 次 / 76K tokens / 缓存 68.2%
DSH 对话完成页：用时 58 秒 + 本轮用量 55,642 tok / ¥0.0946
DeepSeek 官方平台账单：¥0.18 / 9 次调用 / 159,895 tokens
数字口径说明：CLI 侧的 7.6 万 token 是 Claude Code 自己显示的上下文计数，平台按计费口径统计（含缓存读写），两个数加不平，费用一律以平台账单为准；CLI 的 ¥0.085 是拿总账单减掉 DSH 那笔倒算出来的，所以标「约」，DSH 的数是界面直接显示的。
两点反直觉，先说在你前面：
① 快和便宜的是 CLI，不是 GUI。 28 秒对 58 秒，花费也略低。我原以为「界面工具更快」，数据打脸——CLI 没有界面渲染和多余交互，干起活来更像裸奔的跑车。
② DSH 慢，是因为它写得多。 输出 token 是 CLI 的 2.5 倍，代码多了 100 多行——多出来的不是废话，是入场动画、favicon、键盘焦点样式这些提示词里根本没要求的东西。
成品长什么样
陈默（Claude Code 版）效果图：浅色名片风
Claude 版（页面里的虚拟人设叫「陈默」）是一张干净的工程师名片：浅色卡片、靛蓝点缀、信息齐全，属于「放出去不会丢人」的水平。
林一舟（DSH 版）效果图：眉题 + 编号卡片 + 按钮式联系方式
DSH 版（「林一舟」）则明显多做了一层设计：小字眉题「HELLO, I'M」、编号 01/02/03 的项目卡片、分类标签、底部联系方式做成了按钮——每一处都是提示词里没写的。
代码层面我本来看走眼了
一开始我只看渲染截图，以为 Claude 版的项目卡片「文字溢出是 bug」。打开源码才发现：两边都用了 -webkit-line-clamp: 2 做两行截断——那是设计，不是缺陷。是我武断了。
代码质量本身两边打平：CSS 变量、语义化标签、响应式、prefers-reduced-motion 都有。差别在 DSH 多了 favicon、meta 描述、入场动画、focus-visible 焦点样式——一句话总结：
同一个模型，CLI 壳下它默认是「交付功能的工程师」，GUI 壳下它默认是「发布作品的开发者」。
第一轮，DSH 胜在成品，CLI 胜在速度和钱。真正的分水岭在第二轮——改需求，才是日常使用的常态。
三、第二轮：改需求才是照妖镜
第一轮比的是「从零造」，日常使用更多是「在别人（或它自己）的代码上改」。第二轮提示词同样一字不差：
改两个地方：
1. 配色改成暗色模式
2. 三个项目卡片加上鼠标悬停动效（比如轻微上浮+阴影）
结果：两边又是一轮通过、零报错、没改崩。 但过程数据继续拉差距：
| Claude Code（CLI） | DSH（GUI） | |
|---|---|---|
| 用时 | 24 秒 | 30 秒 |
| 轮次 | 1 次，通过 | 1 次，通过 |
| 改动方式 | 精准 diff：最小范围增删（仅配色块就只动了 9 增 8 删） | 大块调整：+27 行 / −24 行 |
| 花费 | 约 ¥0.044 | ¥0.056 |
| token 消耗 | 20.6 万（7 次小请求） | 5.8 万 |
| 缓存命中率 | 99.0% | 99.2% |
CLI 的 Update diff 截图：红绿对比、Added 9 lines removed 8 lines
CLI 完成说明：Crunched for 24s，逐条列出暗色与动效改动
CLI 第二轮用量统计：$0.01 / 7 次 / 206K / 缓存 99.0%
DSH 完成页：用时 30 秒 + ¥0.0557 + 58,344 tok
两个值得单独说的细节：
① CLI 的「外科手术式」改法。 它不是重写文件，是像医生一样只动要动的地方——配色变量块 9 行增 8 行删，别的一概不碰。这很像老后端的 code review 直觉：改得越少，引入新问题的概率越低。
② CLI 吃 token 像流水，花钱却更少。 第二轮它消耗 20.6 万 token，是 DSH 的 3.5 倍——但 99% 走了缓存，账单反而比 DSH 低。agent 式工作流是「多次小请求」不断回读上下文，缓存一热，费用就压下去了。吃得多不等于花得多，看账单别只看 token。
暗色成品对比
陈默（CLI 版）暗色成品
林一舟（DSH 版）暗色成品
两边暗色都成立：CLI 把点缀色从靛紫调亮保证对比度、顺手给技术栈标签的悬停也适配了暗色；DSH 则保住了第一轮全部设计细节——眉题、编号徽章、渐变头像，悬停时顶部渐变条从左划开（0.25s）。悬停动效两边都真实生效，谁也没糊弄。
第二轮剧情没有反转：CLI 追回速度、费用、改动精度三城，DSH 继续守住成品质感。
到这里，两轮合计花费 ¥0.28——两毛八，换来四个完整页面和一整套真实数据。这个测试的成本，可能还不够买一瓶可乐。
四、第三轮：加一个带动画的技能区块
前两轮是「造」和「改」，第三轮补上日常第三种场景：在页面里新增一个复杂区块（布局+动画逻辑一起上），这是最容易翻车的类型：
再加一个技能进度条区块，每项技能配百分比条，动画从 0 涨到目标值
结果又一次双双一次通过。但这次我盯的是动画是怎么实现的：
| Claude Code（CLI） | DSH（GUI） | |
|---|---|---|
| 用时 | 22 秒 | 29 秒 |
| 轮次 | 1 次，通过 | 1 次，通过 |
| 改动方式 | 精准插入 +50 行 | 整块新增 +95 行 |
| 动画实现 | transform scaleX（走合成层，不触发重排），用 CSS 变量 --level 控制宽度 | CSS 动画，延迟错开依次启动 |
| 花费 | 约 ¥0.035 | ¥0.045 |
CLI 的 Update diff：Added 50 lines，技能区块 CSS
CLI 的动画实现说明：scaleX 合成层、--level 变量、Baked for 22s
CLI 第三轮用量统计：$0.01 / 4 次 / 134K / 缓存 99.5%
DSH 完成页：用时 29 秒 + ¥0.0451 + 134,648 tok / +95 −0
两处值得停下来看：
① CLI 的动画是「懂浏览器」的写法。 进度条动画最直白的写法是动 width——每一帧都触发重排；CLI 选了 transform: scaleX，动画跑在合成层上，由 GPU 干活，主线程一次都不用重排，还配了缓动曲线和降级方案。说实话，就这一条进度条，两种写法肉眼无差；差距要等页面复杂、动画多了才显出来——这是给将来铺路的写法。一个「写页面的」默认用这个判断起步，多少有点职业素养的意味。
左 CLI index.html 177-185 行（.skill-fill：width 定终值 + transform: scaleX(0) + animation: skill-grow）；右 DSH personal-intro.html 211-223 行（.skill-fill + @keyframes grow：from width:0 → to width:var(--value)）
同样的进度条动画，两种实现——左边动画跑在合成层不触发重排，右边是更直白的 width 写法，小页面完全够用。
② 两边连无障碍都想到一块去了。 系统开启「减少动态效果」时，两边都会让进度条直接显示终值、不做动画——没人要求过，它们自己加的。同一颗脑子，底线是一致的。
陈默（CLI 版）最终版效果图（含技能熟练度区块）
林一舟（DSH 版）最终版效果图（含技能区块）
三轮总账
| Claude Code（CLI） | DSH（GUI） | |
|---|---|---|
| 累计用时 | 74 秒 | 117 秒 |
| 累计花费 | 约 ¥0.16 | 约 ¥0.20 |
| 一次通过率 | 3/3，零报错 | 3/3，零报错 |
| 成品质感 | 够用、干净 | 明显更精致 |
| 改动精度 | 外科手术式 | 大块调整 |
三轮下来总花费 ¥0.36，六个页面状态，零报错零返工。比分牌很清楚：速度、费用、改动精度、工程细节，CLI 三局全胜；成品质感，DSH 一骑绝尘；稳定性和无障碍底线，打平。
五、写在最后：数据归数据，手感归手感
先承认一个事实：论代码水平，这次测试里 Claude Code 明显考虑得更全——动画走合成层、改动精准克制、逻辑处理更直接高效。如果你主战场在服务端和工程逻辑，CLI 依然是我推荐的选择。
但我还是把日常主力换成了 DSH。真实原因有三，都是数据测不出来、用一周才有的体感：
① 操作真的简单。 图形界面上点按钮、填配置，和命令行里敲指令，是两种心智负担。写了一天代码之后，晚上折腾工具，我选轻的那个。
② 缓存命中更高。 三轮测下来 DSH 缓存命中稳定在 95%~99%，CLI 第一轮只有 68%。单次测试 CLI 更便宜，但长期高频用，缓存命中率的差距会在账单上慢慢回来。
③ 桌面端有操作历史。 做过什么、改过哪版，往回翻一目了然；命令行里翻历史，翻着翻着就烦躁了。就为这一条，日常工具的天平就歪向了 GUI。
所以我的结论不是「谁强谁弱」，是分工：
代码级任务、批量修改、工程逻辑——CLI 上场；页面、演示、看得见结果的活——DSH 上场。
换工具换的从来不是模型的智力，是它「默认替你多走哪几步」，以及你愿不愿意天天打开它。
测试的三轮提示词都在上面，照着抄一遍，三毛六就能跑出自己的版本。跑完欢迎回来聊聊你的结果。
免责声明：文中测试为个人实测，模型版本与价格以各官方页面为准；费用数据来自测试当日账单，不同用量结构下结果可能不同。
互动一下： 你是 CLI 派还是 GUI 派？评论区聊聊你换工具的真实理由——是省心、省钱，还是单纯看着爽。
关于我：10 年 Java 后端，日常泡在 DSH / Claude Code / DeepSeek 里写代码排问题，公众号「逻辑与温度」持续记录 AI 工具在真实开发里的实战与踩坑——Codex 接 DeepSeek、DSH 插件开发、微信小程序 AI 实录、智能体搭建，全都写过。写代码的第 10 年，正在把 AI 变成杠杆。
如果这篇对你选工具有帮助，欢迎来公众号找我，那边更新更勤一些。
