从零到一：我用 AI 写了一个贷款计算器，顺便把等额本息公式彻底搞懂了

起因：一个被"房贷月供"逼疯的独立开发者

最近在做一个面向个人用户的工具站，需要一批实用的小工具来引流。翻了一圈需求列表，发现"贷款计算器"是个高频搜索词------毕竟谁没在买房买车时被月供计算折磨过。

作为一个独立开发者，我的原则是：能不写后端就不写后端。贷款计算这种纯数学的活儿，完全可以在浏览器里搞定，数据不上传服务器，用户也放心。所以目标很明确：一个单文件 HTML，纯前端，打开即用。

但问题来了：等额本息和等额本金的公式，我早就还给高中数学老师了。这时候不找 AI 帮忙，更待何时？

传统方案？不存在的

说实话，这种工具市面上多如牛毛。但作为开发者，我深知那些网页版计算器有多坑：

有的要注册才能用
有的算完结果还要"下载 App 查看详情"
有的界面塞满广告，点一下计算按钮弹出三个弹窗

这不比自己做一坑？ 自己做还能顺便练手，而且完全掌控代码质量。

和 AI 的"结对编程"之旅

第一轮：需求描述

我打开 Claude，开始描述需求：

帮我写一个贷款计算器，单文件 HTML，支持等额本息和等额本金两种还款方式，输入贷款金额、年利率、期限，输出月供、总利息、总还款额，还要有逐月还款明细表。

AI 很快给出了一版代码。结构清晰，功能完整，但我扫了一眼就发现了几个问题：

问题一：数字格式化太粗糙。 AI 直接用 toFixed(2) 处理金额，没有千分位分隔符。用户看到 1234567.89 和 1,234,567.89 的体验是完全不同的。

问题二：没有输入校验。 用户输入负数或者 0，直接算出一堆 NaN 或者 Infinity。虽然不是不能用，但用户体验太差。

问题三：明细表直接渲染全部 360 行（30年贷款）。 这会让页面卡顿，而且用户根本不会去看全部。

第二轮：调优对话

我继续追问：

金额要加千分位分隔符

输入值要做合理性校验

明细表太长，默认只显示前 12 期和后 3 期，中间用省略号

AI 很快更新了代码，加了 toLocaleString 做格式化，加了校验逻辑，明细表也做了折叠处理。这一轮效率很高，基本改到位了。

第三轮：国际化需求

我的工具站要面向中英文用户，所以提了最后一个需求：

加上中英文切换，用 URL 参数 ?lang=en 控制，还要自动检测浏览器语言。

AI 设计了一个轻量 i18n 方案------一个 t('key') 函数搞定所有文案切换，没有引入任何 i18n 库。这个设计很聪明，代码量小，维护也方便。

核心算法：等额本息 vs 等额本金

这次开发让我彻底搞懂了两种还款方式的区别，这里直接说人话：

等额本息（每月还款固定）：

scss 复制代码

月供 = 贷款额 × 月利率 × (1+月利率)^期数 / ((1+月利率)^期数 - 1)

每月还款额相同，但前期还的利息多、本金少，后期反过来。适合收入稳定的上班族。

等额本金（每月还固定本金）：

复制代码

首月月供 = 贷款额/期数 + 贷款额 × 月利率

每月还的本金固定，利息逐月递减，所以月供是递减的。总利息比等额本息少，但前期还款压力大。

核心代码实现：

javascript 复制代码

function calcEqualPayment(p, r, n) {
  // p: 贷款本金, r: 月利率, n: 期数
  const factor = Math.pow(1 + r, n);
  const payment = p * r * factor / (factor - 1);
  const details = [];
  let remaining = p;
  for (let i = 0; i < n; i++) {
    const interest = remaining * r;
    const principal = payment - interest;
    remaining -= principal;
    details.push({
      month: i + 1,
      payment,
      principal,
      interest,
      remaining: Math.max(0, remaining)
    });
  }
  return details;
}

这里有个小坑：浮点运算的精度问题。比如 remaining 最后一期可能剩个 0.0000001 之类的残值，所以我用 Math.max(0, remaining) 兜底，防止显示负数。

从"能用"到"好用"的细节打磨

AI 生成第一版代码后，我做了几处关键优化：

1. 实时计算

用户输入即触发计算，不用点"计算"按钮。这在移动端体验尤其重要------少一次点击，少一分流失。

javascript 复制代码

document.querySelectorAll('#amount,#rate,#years')
  .forEach(el => el.addEventListener('input', calculate));

2. 深色模式适配

现在用户对深色模式的要求越来越普遍，不加真的会被吐槽。用 CSS 变量 + prefers-color-scheme 实现，成本很低：

css 复制代码

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #1a1a2e;
    --text: #e2e8f0;
    --primary: #60a5fa;
  }
}

3. 结构化数据

为了让搜索引擎更好地理解页面内容，我加了 schema.org 的 WebApplication 结构化数据。这个对独立开发者来说很重要------不用花钱做 SEO，但基本的语义化标签该加还是要加。

踩坑记录

坑一：toLocaleString 的兼容性。 在部分旧版浏览器上，toLocaleString('zh-CN', { style: 'currency' }) 可能返回异常格式。我最后用了最保险的方式：只做千分位分隔，货币符号用文本拼接。

坑二：明细表的渲染性能。 360 行的 DOM 渲染在低端手机上确实会卡。我做了个简单优化：超过 24 期只渲染前 12 期和后 3 期，中间用省略行代替。用户想看完整数据？展开全部就行。

坑三：等额本息公式的边界情况。 当年利率为 0 时，公式里的 (1+r)^n - 1 会变成 0，直接除零报错。我加了个特殊处理：

javascript 复制代码

if (r === 0) {
  // 零利率时，月供就是本金除以期数
  const payment = p / n;
  return Array.from({length: n}, (_, i) => ({
    month: i + 1,
    payment,
    principal: payment,
    interest: 0,
    remaining: p - payment * (i + 1)
  }));
}

这个 edge case 是 AI 没考虑到的，CV 工程师狂喜之后还得自己动手。

对 AI 辅助开发的感受

这次开发让我对 AI 辅助编程有了更深的体会：

AI 擅长的是"从 0 到 80 分"。给它一个清晰的需求描述，它能快速搭出骨架，省去大量重复劳动。但**"从 80 到 100 分"需要人来把关**------边界情况、性能优化、用户体验细节，这些都需要开发者自己思考。

我的工作流程变成了：

向 AI 描述需求（越具体越好）
审查 AI 生成的代码（别盲信，逐行看）
补边界情况、调样式、优化交互
测试所有可能的分支

AI 不是银弹，但确实让独立开发者能更快地把想法变成产品。以前写这种工具可能要一晚上，现在一个小时内搞定，剩下的时间可以打磨细节。

适用场景

这个计算器适合以下场景：

买房前估算月供，看自己能不能扛得住
买车时对比等额本息和等额本金的还款差异
投资前计算贷款成本，判断值不值得

纯前端实现，数据不上传服务器，打开即用，支持中英文切换和深色模式。

如果你也有类似需求，可以直接在线体验：

贷款计算器：craftvo.app/zh/tool/loa...

最后说一句：AI 辅助开发不是魔法，但它确实让"一个人干一个团队的活"变成了可能。关键是------你得知道自己要什么，AI 才能帮你把路走通。