做一个报价系统，到底有多折腾？

最初我以为只是一个小工具。

最开始，我只是想做一个报价系统，用来算标识牌的价格。我想得挺简单：就是一个工具，用户输入尺寸、材质、数量，系统自动算出价格。就像我之前做的亚克力报价小工具一样，一个页面就够了。

结果做着做着，发现事情没那么简单。

❶ 不能只做一个工具，得分成两端

在实际操作中，我很快意识到一个问题：报价系统需要两个端，而不是一个。

• 前端：拆解端 —— 负责把图纸里的信息拆出来，比如尺寸、材质、数量、工艺
• 后端：报价端 —— 负责根据拆解出来的数据计算价格

为什么要分开？因为拆解和报价其实是两件不同的事。拆解是”读懂图纸”，报价是”计算费用”。如果混在一起，一个地方改了，另一个地方就跟着乱。

所以我把整个系统分成了两部分：前端负责拆解，后端负责报价。中间用CSV文件来传递数据。

❷ 工具拆解不靠谱，得让机器人来

最开始我想做一个纯工具，让用户上传Excel或PDF，系统自动拆解。但试了之后发现，工具拆解的结果总是有偏差。特别是遇到不同格式的图纸，工具就不知道怎么处理了。

后来我想到了一个办法：让图纸机器人来拆解。

图纸机器人是我在QClaw里训练的一个智能体，它可以读懂图纸，然后把信息拆解成标准格式。我只需要教会它怎么拆，它就能按照规则输出CSV文件。

为什么用CSV？因为它稳定。CSV是纯文本格式，没有Excel那种复杂的格式问题，不容易出现乱码或解析错误。

就这样，流程变成了：

图纸 → 图纸机器人拆解 → 生成CSV → 前端确认 → 后端报价

❸ 改代码改到崩溃，必须拆成模块

整个开发过程中最让我头疼的，就是改代码。

因为前端和后端都在不断调整，每次改完一个地方，另一个地方就出问题。版本越改越多，从V1到V3，从V3到V6，改来改去，有时候改了半天，发现又回到了原点。

后来我们约定了一个原则：代码要分板块，每次只改指定的板块，其他不动。

比如这次只改”解析CSV”的模块，那就只动那一块，其他地方不动。这样即使改错了，影响范围也有限，不会把整个系统搞崩。

❹ 本地能跑，不等于宝塔能跑

在桌面上测试的时候，一切都好好的。前端能拆解，后端能报价，数据能传递。

但一上传到宝塔面板（我的网站服务器），就不行了。前端点”发送”，数据发不出去，后端也收不到。

后来才明白，问题出在地址上。

在桌面端，前端和后端都在本地，地址是相对的。但在宝塔面板里，前端和后端需要在同一个目录下，并且前端必须知道后端的准确地址，才能把数据发过去。

就像寄快递，你填错了地址，快递员就送不到。

最后我学了一招：把后端地址放在代码的最后面，用一行变量来管理。 到了宝塔面板，只需要改这一行地址，其他地方都不用动。

❺ V1跑通了，接下来做什么？

目前这个报价系统已经跑通了，算是一个V1版本。

但跑通不等于能用。真正要用起来，还需要大量的测试和训练：

• 训练图纸机器人拆解更多类型的牌子 —— 目前只教会了它拆解不锈钢立体字，接下来还要教它拆解门牌、楼层牌、灯箱、立牌……每一个类别都需要单独训练。
• 用真实数据验算 —— 把实际项目中的数据导进来，看系统算出来的价格是否合理，有没有漏项。
• 迭代优化 —— 如果发现某个类别的报价不准，只需要修改对应的拆解规则文件，而不需要动整个系统。

❻ 做工具不难，难的是让工具真正能用

这段时间做下来，最大的体会是：做工具不难，难的是让工具真正能用。

Vibe Coding可以让你快速搭出一个原型，但真正让它变成可以反复使用、不出错的工具，还需要大量的测试、调整和耐心。

一开始我以为就是一个报价小工具，结果做成了一个”前端拆解 + 后端报价 + 图纸机器人训练”的系统。虽然过程折腾，但每一步都在解决实际问题，每一步都让我对这套东西理解得更深。

接下来就是慢慢积累，让图纸机器人学会更多类别的拆解，让报价系统覆盖更多实际业务。

路还长，慢慢走。🌱

后记：这篇文章记录了从2026年6月中旬到7月初，我和AI一起开发报价系统的全过程。期间经历了从V1到V6的版本迭代，从前端到后端的联动调试，从本地测试到宝塔面板的部署，以及无数次的代码修改和问题排查。如果你想了解这个系统的技术细节，或者想自己搭建一个类似的报价系统，可以参考我网站上”Vibe Coding集”栏目里的相关文章和工具链接。