我用 TraeCode 把普陀山攻略做成了可交互的私人礼佛导览站，全程零部署
部分内容由豆包生成
投稿板块：TRAE 社区「案例与作品」
我是一名自由职业者，平时喜欢周末短途游，对佛教文化也有些兴趣。最近计划去普陀山朝拜一天，提前一周开始做攻略，结果越做越乱。
一、遇到的问题
- 路线说法不一：网上搜了七八篇攻略，有的顺时针有的逆时针，根本不知道信哪个。
- 祈祷词背不下来：我通过豆包收集了大量寺庙点位，手动整理了各点位的祈祷词，存成文档，但临出发前发现根本背不下来，到了佛前脑子一片空白。
- 注意事项散落各处：进殿走哪侧、怎么上香、不同寺庙的规矩，散落在不同文档里，想找的时候翻半天。
- 模板无法个性化：祈祷词里都是「弟子某某某」这种模板，想换成自己的名字、自己关心的愿望，60 多个点位总不能手动改一遍吧。
出发前一天晚上，我手上是 3 份攻略 txt、1 份祈祷词 md、还有几张景区导览图，一团乱麻。传统做法是打印出来带上，但 60 多个点位的内容，到了现场根本翻不过来。
转念一想，我能不能用 TraeCode 把这些东西做成一个网页？一个文件、打开就能用、手机上也能看、还能自动帮我替换姓名和祈愿内容的那种。
二、我是怎么用 TraeCode 解决的
主要用的是 IDE 模式（Default Mode），因为整个项目就是一个 HTML 文件，改动频繁，我需要每一步都能看到效果、随时调整。前后花了大约3小时。
1. 把散乱资料喂进去，搭出整体骨架
一开始我也不确定能不能做成，就先把豆包整理的点位资料、手动收集的祈祷词和礼佛礼仪文档放进项目目录，然后描述需求：
“基于这些普陀山朝拜攻略和祈祷词资料，生成一个单文件 HTML 导览应用。要求：按一日游时间顺序排列 62 个参观点位；每个点位可折叠，展开后显示祈祷词和注意事项；顶部导航 + 底部 tabbar，移动端友好；全部内联，不依赖任何外部资源，离线可用。”
TraeCode 直接生成了一个完整的单页应用骨架：
- 总览页：行程概览、时间安排、准备事项
- 导览图页：景区地图和路线示意
- 执行清单页：62 个点位卡片，按路线编号，可折叠展开祈祷词详情
- 礼仪应急页：礼佛常识、应急联络、注意事项
最惊喜的是它自动识别出了不同攻略里重复的点位（比如南海观音像在两份资料里都出现了），合并后还标注了交叉验证来源，省了我好多对比的功夫。
2. 个性化祈祷词——从模板到"我自己的话"
骨架搭好后，最核心的需求来了：祈祷词要能自动替换姓名、性别，还要根据我勾选的祈愿项，动态填充家庭愿、财运愿、事业愿这些内容。62 个点位的祈祷词里都有占位符，手动改是不可能的。
我把愿望分类清单和祈祷词模板给了 TraeCode，让它实现一个「礼佛信息设置面板」，由 TraeCode 完成祈祷词的动态编辑和全站替换。它的实现方案很巧妙：
<section class="block devotee-block" id="devotee">
<h2>礼佛信息 · 个性化设置</h2>
<div class="devotee-panel">
<!-- 性别 + 姓名 -->
<div class="dp-row">
<label><input type="radio" name="gender" value="male"> 男（弟子）</label>
<label><input type="radio" name="gender" value="female"> 女（信女）</label>
<input type="text" id="devotee-name" placeholder="请输入姓名">
</div>
<!-- 树形祈愿多选 -->
<div class="wish-tree">
<details open>
<summary>世间福报祈愿</summary>
<label><input type="checkbox" data-wish="family"> 家庭安康</label>
<label><input type="checkbox" data-wish="wealth"> 财禄丰足</label>
<label><input type="checkbox" data-wish="career"> 事业顺遂</label>
<!-- 10 大类共 40 项祈愿 -->
</details>
</div>
</div>
</section>
核心逻辑就是几十行 JS：性别切换时全站「弟子/信女」统一替换、姓名实时填入、勾选祈愿后动态生成各愿内容。而且设置自动存在 localStorage，下次打开直接恢复，不用重新填。
到这一步，这个页面已经从"别人的攻略"变成了我的专属朝拜手册。
3. 交互细节打磨——好用比好看重要
框架和内容都有了，但用起来还是有些小别扭：
- 底部导航在滚动时会自动藏起来，到了寺里想点导航，得往上滑一下才出来，户外单手操作特别容易掉。
- 首页那么长，「礼佛设置」藏在中间，想改个愿望还要翻半天。
- 点击目录里的点位，页面跳过去了但位置不准，差了好大一截。
这些细节如果自己调，每个都要试半天。直接把问题描述给 TraeCode，它很快就搞定了。
导航固定 + 新增「心愿」入口：删除了 tabbar 滚动隐藏的逻辑，导航始终固定显示；顶部导航和底部 tabbar 各加了一个「心愿」按钮，一点就跳到礼佛设置区；路由还支持了页面 + 页内锚点的组合格式。
function parseRoute() {
var h = (location.hash || '#/home').replace(/^#/, '');
var frag = '';
var hi = h.indexOf('#');
if (hi >= 0) { frag = h.slice(hi + 1); h = h.slice(0, hi); }
if (h.charAt(0) === '/') h = h.slice(1);
var parts = h.split('/');
return { page: parts[0] || 'home', arg: parts[1] || null, frag: frag };
}
function scrollToFrag(frag) {
var el = document.getElementById(frag);
if (!el) { scrollTop(); return; }
try {
el.scrollIntoView({ behavior: reducedMotion ? 'auto' : 'smooth', block: 'start' });
} catch (e) { el.scrollIntoView(); }
}
锚点定位修复：一开始跳转不准的原因也找到了——JS 初始化时用新 id 覆盖了标题原有的 id，导致找不到目标。改成"保留原始 id、只对无 id 标题生成新 id"后，62 个点位的目录跳转全部精准命中。
4. 浏览器里跑一遍，确认真的能用
改完最后一个 bug，我用 TraeCode 启动了本地服务器，在浏览器里从头到尾走了一遍流程：
- 打开页面 → 填写姓名性别 → 勾选祈愿 → 祈祷词实时替换
- 点击 tabbar「心愿」→ 跳回首页 + 滚动到礼佛设置区
- 点击目录任意点位 → 精确定位到对应卡片
- 滚动页面到底部 → tabbar 始终固定，不隐藏不伸缩
- 关掉页面再打开 → 设置都还在
整个验证过程 TraeCode 也参与了——它帮我写插桩代码、检查 DOM 状态、确认功能路径，不像以前改完得自己肉眼一个个试。
三、成果展示
最后交付的东西很简单，就一个 HTML 文件，400 多 KB：
| 产出 | 说明 |
|---|---|
| 1 个单文件 HTML 应用 | 所有 CSS/JS/内容全部内联，零依赖，离线可用 |
| 62 个点位卡片 | 按路线顺序编号，可折叠查看祈祷词详情 |
| 个性化礼佛面板 | 性别/姓名替换 + 40 项祈愿树形多选 + 本地持久化 |
| 4 个功能页面 | 总览 / 导览图 / 执行清单 / 礼仪应急 |
| 移动端适配 | 顶部导航 + 底部 tabbar，固定显示不伸缩 |
出发那天实测了一下：山里信号时有时无，但页面完全离线可用，打开就看；到每个寺庙前，掏出手机点一下对应点位，祈祷词自动填好了我的名字和愿望，照着念就行；中途想加个愿望，点底部「心愿」直接跳过去改，改完全站自动更新；同行的朋友问我要，我直接发了个文件过去，不用解释怎么安装怎么部署。
回来之后这个文件我也没删——下次去别的佛教名山，把内容替换一下，就是一套新的导览站。相当于有了自己的旅行导览生成器。
四、效率对比
| 环节 | 以前怎么做 | 这次用 TraeCode |
|---|---|---|
| 整理攻略、梳理路线 | 手动对比七八篇文章，排顺序去重，约 3 小时 | 资料丢进去，AI 自动合并去重排序，约 20 分钟 |
| 搭页面骨架、写样式 | 从零写 HTML/CSS，调布局适配移动端，约 4 小时 | 描述需求后一次性生成，微调样式，约 30 分钟 |
| 个性化祈祷词功能 | 根本不会做，放弃了 | 描述需求后自动实现，约 20 分钟 |
| 调试交互细节 | 每个问题自己查、自己试，约 2 小时 | 描述问题后直接修复，约 30 分钟 |
| 总计 | 约 9 小时（还做不了个性化功能） | 约 2 小时（功能更完整） |
省时间是一方面，更重要的是——以前我根本不会想到"做一个网页导览站"这个方案，觉得那是程序员才会干的事。但有了 TraeCode 之后，想法和实现之间的距离突然变得很近。
五、经验和技巧总结
做这个项目的过程中踩了几个坑，也摸索出一些门道，分享给想做类似事情的朋友：
1. 非开发场景，先用"描述需求"代替"写代码"
如果你和我一样不是专业前端，别一上来就纠结"用什么框架"“怎么写组件”。直接用大白话描述你想要什么效果，TraeCode 能理解八九不离十。不满意再微调，比从零学快多了。
2. 旅游/户外类应用，"稳"比"炫"重要
一开始生成的页面有滚动隐藏导航、各种平滑动画，看起来很酷。但实际在户外用的时候，手机性能一般、网络不稳定，这些"炫技"效果反而会造成卡顿和误触。主动让 AI 把动画关掉、导航固定，体验反而好很多。
3. 单文件 HTML 是被低估的交付形式
很多人做项目第一反应是搭框架、装依赖，但对于"旅游导览"这种场景，一个 400KB 的单文件 HTML 才是最优解——离线可用、分享方便、零部署成本。TraeCode 生成单文件应用的能力非常强，善用这一点。
4. 先做能用的版本，再慢慢加功能
我一开始列了十几个想做的功能（打卡记录、GPS 定位、语音播报……），后来发现最核心的需求就三个：路线清楚、祈祷词能用、设置方便。先把这三件事做好，剩下的以后再说。不然容易陷入"功能越做越多，核心体验越做越差"的怪圈。
注：本文为个人真实实践分享。涉及家人健康信息均已脱敏处理。发帖时请为文中标注的截图位置补充真实截图，并在标题带上话题 #TraeCode的100种用法。
（注：内容完全由 AI 生成）
putuoshan-pilgrimage-standalone.html (432.8 KB)