用华为云码道 CodeArts 20 分钟做出咖啡萃取计算器

一、起因：一个每天都会撞上的小麻烦

我平时每天两杯手冲，同时又是写嵌入式 Android 的。手冲这件事真正烦的不是手法，是换豆子就得重算一遍参数：

• 粉水比要不要从 1:15 调到 1:16？
• 磨豆机刻度给多少格？
• 目标萃取率定 20% 的时候，预计液重和 TDS 大概是多少？

这些参数我记在手机备忘录里，一换豆子就得翻记录、心算、再验证一次。于是想做个一页纸的小工具：输入粉量和目标萃取率，其它全自动算出来。

需求很明确，代码量也不大，但为了这么个小工具去开 IDE、建工程、配打包链路，性价比太低。这次我换成用华为云码道 CodeArts（GLM-5.2）直接生成。

二、提示词：把"我要什么"写成"验收标准"

码道这类工具的产出质量，八成取决于提示词里有没有写清楚约束。我这次只写了一段，但把四点全部钉死：

做一个「咖啡萃取配方计算器」单文件网页应用：
1) 输入粉量(g)、水量(g)、目标萃取率(%)，自动算出粉水比、液重、建议研磨度与水温；
2) 提供 V60 / 意式 / 冷萃 三种预设，切换时联动参数；
3) 深色卡片式 UI，移动端自适应，纯 HTML+CSS+JS 无依赖；
4) 结果区实时更新，并给出一个「复制配方文本」按钮。
请直接生成可运行的 index.html。

四个约束分别对应四个坑：

三、生成结果：一次跑通

任务提交后，码道直接返回了完整的 index.html：

• 12.2 KB，纯前端，无任何外部请求
• 耗时约 4 分 30 秒，消耗 19.83 积分
• 三种器具参数做了联动：粉量一改，水量、液重、研磨度、水温全部实时刷新

实测一组数据（粉量 15 g、目标萃取率 20%）：

这几个数跟我平时记的手冲小抄完全对得上，说明生成的不只是个能跑的壳子，换算逻辑是对的（液重 ≈ 水量 − 粉量 × 吸水率，TDS 由萃取率与液重反推）。

代码我开源在这里，可以直接看：

https://gitcode.com/fllytodie/g-coffee

四、几点实际使用感受

1. 单文件零依赖是最舒服的一点 丢到任何静态托管、甚至直接双击本地文件就能用。手机浏览器打开也顺手，不需要装 App。

2. 逻辑全在前端，断网也能算 咖啡机边上经常没 Wi-Fi，纯前端的方案反而比"调个 API 算"更可靠。

3. 深色 UI 在厨房场景是真的加分 吧台灯光偏暗，浅色背景看久了费眼。

4. 真正花时间的不是生成，是"想清楚参数关系" 从提需求到拿到能跑的作品大约 20 分钟，其中大部分时间我在纠结：萃取率给 20% 还是 22%？研磨度到底该按 V60 还是按豆子烘焙度给？——这些是业务知识，模型替不了。提示词写的是我的判断，不是它的。

五、踩到的一个坑：别用太小的 max_tokens 去试探推理模型

后来我把这个模型接到自己的网关上调了一次接口，用 max_tokens: 40 发了个很短的请求，结果返回 HTTP 500：

{"error":"empty response content","success":false}

一开始以为是路由坏了，其实不是：这个模型是推理模型，40 个 token 全部烧在 reasoning 上，最终 content 是空的。把 max_tokens 提到 300 之后一切正常（那次实际用了 107 个 token，其中 92 个是 reasoning）。

结论：验证一个推理模型的路由是否可用时，max_tokens 至少给 300，否则你会把一个正常的模型误判成挂掉。

六、什么时候适合这么干

这段经历让我对"AI 生成小工具"的适用边界更清楚了：

• 适合：需求边界清晰、输入输出明确、几十到几百行就能搞定的小工具（计算器、转换器、批量重命名、参数面板）
• 不适合：需要对接内部系统、有复杂状态机、要长期维护迭代的项目——这种还是老老实实建工程

另外这类单文件工具的复用成本极低：今天做咖啡计算器，明天把提示词换成"饲料配方计算器""线材长度计算器"，半小时就能再出一个。对经常被同事问"能不能帮我算一下这个"的人来说，这个产能是实打实的。

七、小结

一段约束清楚的提示词，换来一个零依赖、能离线跑、手机上也能开的小工具。对这类"小而确定"的需求，码道 CodeArts 是我现在会优先想到的路径。

项目代码：https://gitcode.com/fllytodie/g-coffee