30天,168个文件,我的AI智能旅行攻略小程序从0到1

我只用了这3步。

事情是这样的。

去年年底，我开始在公众号和小红书做旅行内容。做了一段时间发现一个痛点：读者总问我"去XX城市怎么玩"。

每次都要手动排版、查攻略、写路线，效率极低。

于是我想：能不能做一个小程序，用户输入目的地，AI直接在5秒内生成完整的旅行攻略？

想法很好，但我不会写代码。

不是"不太会"，是"完全不会"。我连小程序怎么注册都不知道。

后来我花了两周研究微信小程序开发流程，又花了两周用AI辅助编程，终于把整个项目跑了起来。

核心逻辑很简单：AI生成攻略不是魔法，本质是模块拆分 + 流式输出 + 用户交互设计这三步。

第一步：把"AI生成攻略"拆成10个独立板块

很多人一开始就想让AI一次性输出整个攻略。

试过就知道，结果惨不忍睹。要么内容太水，要么结构混乱，用户根本不想看。

我的做法是把攻略拆成10个独立板块：

【原理】：
AI一次性生成完整攻略，token消耗大、响应慢、内容质量不可控。但拆成独立板块后，每个板块只负责一个任务——天气生成天气、美食生成美食、路线生成路线——AI的准确率大幅提升。

【操作】：

1. 1. 定义10个板块：目的地概况 → 天气建议 → 交通指南 → 住宿推荐 → 景点安排 → 美食推荐 → 行程路线 → 费用预算 → 行前清单 → 注意事项
2. 2. 每个板块配独立的Prompt模板，提示词越具体，AI输出越稳定
3. 3. 用微信小程序的wx.request串行调用10次AI接口，每个板块独立请求

（实测：拆分前单次生成平均耗时12秒，拆分后每个板块0.8-1.5秒，首条内容0.8秒就能展示给用户）

第二步：用流式输出消除等待焦虑

拆完板块后，新问题来了：10个板块串行请求，全部完成也要10秒。

用户坐在那等10秒，早就划走了。

【原理】：
流式输出的核心逻辑不是"让AI生成更快"，而是"让用户感觉更快"。心理学有个概念叫"感知等待时间"——只要用户看到内容在流动，即使总时间相同，体验也完全不一样。

【操作】：

• • 用微信的wx.request配合AI接口的stream: true参数，实现逐字输出效果
• • 10个板块并行请求，谁的响应先到就先展示
• • 每个板块用不同的loading骨架屏，让用户知道"正在进行中"
• • 注意：微信小程序数据传输有2KB限制，流式数据需要自行拆包处理

（验证：流式输出上线后，页面停留时长从23秒提升到67秒，跳出率下降了42%）

第三步：用户中心做成"8页闭环"

攻略生成只是第一步。用户看完攻略就走了，和没做这个小程序没什么区别。

真正让产品有价值的，是用户看完攻略之后的下一步。

【原理】：
小程序的生命力不在首页，而在用户中心。8个页面构成一个闭环：我的行程 → 历史攻略 → 收藏夹 → 下载攻略 → 分享给朋友 → 意见反馈 → 个人设置 → 关于我们。用户生成一次攻略后，至少有5个理由回来。

【操作】：
首先，把每个生成的攻略自动存入"我的行程"。
然后，支持一键分享——用户分享出去的卡片自带小程序码，他人扫码后直接进入生成页。
最后，做了攻略导出为图片功能，用户可以保存到相册。

（效果：上线第一周，分享率14.2%，新增用户中37%来自分享回流）

其实，AI辅助编程的本质，不是"AI帮你写代码"。

而是"AI把你的产品思路翻译成代码"。

很多人用AI编程失败，根本原因只有两个：

第一，不会拆。 上来就让AI写一个"完整的小程序"，AI给出的代码要么跑不起来，要么改不动。正确做法是把需求拆到AI一次能处理的最小颗粒度——一个页面、一个组件、甚至一个函数。

第二，不会问。 大量人问AI"帮我写一个旅行攻略小程序"，得到的全是通用模板。但当你问"帮我写一个微信小程序的流式数据处理模块，需要处理分帧和数据粘包"，AI才能给出可用的代码。

168个文件听起来很多，但拆成独立组件之后——9个通用组件、11个行程组件、8个用户中心页面——每个文件平均不到150行代码，AI写完一个，你测试一个，再写下一个。

这就是"从0到1"的真正开始，也许，开发一个小程序从来不是"你会不会写代码"的问题。

而是"你敢不敢从0开始"的问题。

30天，168个文件，38个目录，一个完全不懂代码的人，借着AI，把想法变成了产品。

如果你也有一个"想做但觉得不会"的念头——

现在就拆，拆到最小颗粒度，然后让AI帮你跑起来。

「不会写代码,不是终点,而是起点。