1
客人四步问卷卡片与按钮作答
(案例) 宴会餐饮・Polish AI / Polish 3D
四步问卷取得分级菜单，确认后在 3D 场景摆好整桌
婚宴餐饮客户需要确认菜色，也需要看到餐桌的样子。客户以四个步骤说完需求，取得分级菜单，确认后直接进入 3D 场景，摆好整张餐桌。
同样做法适用于宴会餐饮、宴会场地、婚礼顾问、餐具与花艺租赁，以及任何需要组合起来才看得懂的服务。
7种宴会餐饮服务
6组预设方案
4步问卷
(挑战)
宴会餐饮客户需要同时确认菜色与餐桌的样子
宴会餐饮客户购买的是一场宴席的画面：菜品，加上当天那张桌子的样子。服务共有七种，从西式婚宴、圆桌宴席、周岁派对到个人餐盒，规格各不相同；日期、人数、场地与忌口，也都会改变菜品与价格。
询价单以人工逐题询问、逐份配菜时，提案速度会影响可承接的数量，也影响客户比价的时间。
(做法)
由 AI 撰写菜单，价格一律依规格
让 AI 直接面对客户，最大的风险是自行报价。因此工作切成两半：计价方式、每人价格与附加服务依后台规格，道数也依规格上限修剪；AI 只负责方案命名、菜单与描述。价格若有出入，后端以规格覆盖。
AI 参考的菜品也先经过筛选：依日期推算季节，依场地判断室内外，从描述判断素食，再由菜品库挑出一池候选菜交给 AI。
提案依规格由经典、升级到主厨款逐级递进，系统另将同类服务、价位与人数相近的过往案例交给 AI 参考。
客人
- 四步问卷
- 一句描述例如长辈多、有人吃素
需求分级方案
开发团队的服务
- 候选菜预筛依季节、室内外与素食需求
- 规格覆盖计价方式、每人价格、附加服务与道数上限
候选菜命名与描述
模型供应商
- 语言模型方案命名、菜单与描述
不交给模型价格、计价方式与道数上限。
范围：提案生成。
菜单由 AI 撰写，价格由后台规格决定。
看完整内容 RAG 企业知识问答的逐字验证流程(关键设计)
三项关键设计
四步问卷
问卷以卡片与按钮作答，可预约日期由系统实时提供，填到一半刷新页面也不会丢失。填写无需注册，提交后以邮箱验证即可保存提案。最后一步只需写一句描述，例如长辈多、有人吃素，AI 便调整菜品、预留素食菜品并避开忌口。
3D 餐桌
选了西式婚宴、圆桌宴席或 Buffet 的客户，确认方案后带着订单直接进入 3D 餐桌。每种桌型内置座位定位点，椅子、餐盘、杯具、口布到菜卡依定位点就位，方桌换圆桌，整桌自动重排。
预设方案
六组预设方案一键应用，桌椅、餐具到花艺整桌一次换好；想自行搭配，可在十个分类中逐项替换。布置完成后，选配存回同一张订单，团队在后台即可看到客户选了哪组方案与品项。
桌面端
六组预设方案，整桌一次换好
3D 餐桌下方列出六组预设方案，方桌与圆桌各三组，点选后桌型、桌椅、餐具与桌旗整桌重新排列；切到定制化，可在各分类中逐项替换。
手机
手机同样能一键换整桌
手机上的 3D 餐桌保留同一组预设方案与定制化分页，单指旋转视角，点选方案后整桌重新排列。
(成果)
交付两个串接的网站与一套可调校的 AI
现在有两个互联的网站，与一套可自行调校的 AI：主厨口吻、命名规则等提示词在后台分段管理，每次修改皆留版本，可回滚。品项与方案也在后台增减，上新餐盘不必改代码。
3D 模型经过压缩，手机自动降级，客户以手机即可布置；介绍与问答写进网页源代码，搜索与 AI 引擎皆能读取。
问卷
提案
布置
确认
客人
系统
团队
2
系统产出分级方案经典、升级到主厨款
3
客人进入 3D 餐桌套用默认方案或逐项替换
4
系统选配存回订单
5
团队后台查看方案与品项
3D 餐桌适用西式婚宴、圆桌合菜与 Buffet。
服务与常见问答由后台数据库供应，文字仍在网页源代码里。
- 内容来源静态文件，或后台数据库
- 更新频率固定，或经常更新
- 3D 加载失败时用户是否仍看得到文字
- 内容固定，路径数量有限构建期预渲染磨人官网：不换框架，构建多一步，逐路由输出静态 HTML
- 内容来自数据库，经常更新服务器渲染加增量静态再生服务卡片与 FAQ 由后台数据库供应
- 3D 是交互主体，加载可能失败服务器文字层，3D 接手后拆除某公共机构网站：3D 加载不起来或超时才显示文字
- 文字只为爬虫而放，用户看不到不采用内容必须与用户所见相同
(工程记录)
做法与实测，逐张可展开
3D 网站的搜索与 AI 爬虫可读性：预渲染、爬虫分流与结构化数据
预渲染让磨人官网首页的原始 HTML 从 730 字节增加到 39,516 字节，画面没有改变 相关做法・数字来自其余项目
首页原始 HTML 大小（字节）原始 HTML 中的 h1 数量
- 730 字节预渲染前（单页应用，空容器）前0
- 39,516 字节预渲染后（构建时逐路由输出静态 HTML）定案1
磨人前一版官网首页。h1 数量依预渲染的做法说明。
三类爬虫读同一份 HTML，用途不同，robots.txt 能管的范围也不同 相关做法
爬虫
- 搜索索引爬虫OAI-SearchBot、Claude-SearchBot、PerplexityBot：抓取文本，用于搜索与助手的结果
- 训练爬虫GPTBot、ClaudeBot；Google-Extended 是令牌，没有自己的 user agent
- 用户触发的爬虫ChatGPT-User、Claude-User、Perplexity-User：用户提问时才抓取一页
请求与 user agentHTML 文本
网站（开发团队设置）
- 预渲染的 HTMLh1、直答段与正文都在源代码里
- robots.txt 分组搜索与助手开放，训练依商业决定
- 服务器层 user agent 判断拒绝不遵守 robots.txt 的请求
robots.txt 不是访问控制RFC 9309 说明这些规则不是访问授权；用户触发的抓取，官方文档说明规则不一定适用。
依 OpenAI、Anthropic、Perplexity 与 Google 的官方文档整理，查核日 2026-11-05
AI 项目的费用怎么估：为什么估出来常差好几倍
每条发现各派一个验证代理，代理数就随发现数涨到 136 个；批量验证后降到约 7 个 相关做法・数字来自其余项目
- 每条发现各派一个验证代理136 个代理代理数随发现数放大
- 合并后减少的代理成本约为原来的 5%一个代理验 15 到 20 条
- 批量验证约 7 个代理派工前先算出发现数乘以验证者数的上限
审计流程。成本按标价换算，不是账单。
关闭思考能把写作时间缩到 6 到 17 秒，但标题成功率从 11/11 降到 2/13 相关做法・数字来自其余项目
写作时间标题成功率
- 15 到 75 秒启用思考，一次写完保留11/11
- 6 到 17 秒关闭思考，一次写完不采用2/13
测试站、真实模型，13 题。被验证程序删掉的句子，关闭思考时是启用思考的 3 倍。
最贵的模型只处理抽查后标出的疑难案例，没有逐篇读完全部语料 相关做法・数字来自其余项目
- 全部语料标注约 1,500 篇一篇一个子任务，由 Haiku 标注
- 未抽查的篇数只通过程序验证器退出码 0 才收
- 依风险抽查约 160 篇约一成，由 Sonnet 审查
- 升级给 Opus9 个子任务只处理标出的疑难案例与验证器未通过的
子任务数：Haiku 约 1,600 个、Sonnet 约 50 个、Opus 9 个。篇数与子任务数均为近似值。
(联系)
Start a project.
三个步骤，取得可判断的做法与预算区间。
- 01预约第一场会议：选择时段，不需要完整规格。
- 02在线咨询 15 至 30 分钟：取得做法方向、预算区间与时程草案。
- 03查看素材后，约 3 至 5 个工作日提供报价单暨交付规格明细表。
- 邮箱
- hello@polish-design.com.tw
- 通讯地址
- (104) 台北市中山区植福路191-1号3F
