AI旅行博客生成器V2.2:六步流水线与脚本封装

从"现场拼命令"到"一键脚本"：旅行博客生成器 V2.1 & V2.2 迭代记录

上一篇我们聊了如何用 AI Agent 从零搭建一个旅行博客生成器——用户扔照片进来，AI 看图、写文、排版，一条龙输出精美游记 H5 页面。

这篇记录 V2.1 和 V2.2 两个版本的迭代优化。核心主题只有一个：让 AI 的工作流从"能跑"变成"跑得好、跑得稳"。

一、V2.0 回顾：我们有什么

先快速回顾 V2.0 的家底：

• 后端：一个 ~250 行的极简 Python 服务，只做存储和渲染，零 AI 逻辑

• 5 套 HTML 模板：default（紫色渐变）、magazine（杂志风）、film（胶片）、card（卡片）、minimal（极简）

• 6 个写作 prompt：literary / humorous / minimal / xiaohongshu / writer_en / writer_ja

• Vision 看图：vision.txt prompt，四维度结构化分析每张照片

• 缩略图：ffmpeg 自动压缩，800px 宽

架构原则很清楚：Hermes（AI Agent）是大脑，后端是手脚。 所有智能逻辑在 Skill 层，后端只管 CRUD。

但实际跑一遍完整流程后，我发现了两个明显的痛点。

二、痛点分析

痛点 1：流程断裂，全靠人肉串联

V2.0 的 Skill 文档里写了"上传 → 看图 → 选风格 → 写文 → 发布"的步骤，但每个步骤之间缺少标准化的衔接。比如：

• 看完图，照片该按什么顺序排列？靠 Agent 临场发挥

• 用哪个模板配哪个文风？没有推荐逻辑，靠用户自己选

• 标题怎么起？Agent 随便取一个

结果就是：同样的照片，跑两次可能出来完全不同的效果，质量不稳定。

痛点 2：后端调用全靠现场拼 curl

Skill 文档里写着：

curl -X POST http://localhost:8765/api/upload -F "files=@photo.jpg"
curl -X POST http://localhost:8765/api/publish -H "Content-Type: application/json" -d '{...}'

Agent 每次执行时要"读文档 → 理解 → 自己组装 curl 命令"。能跑，但：

• 每次都重新拼，效率低

• JSON payload 复杂时容易出错（尤其是中文编码）

• 没有参数校验，出错了才知道哪里写错了

这不是一个可靠的工程实践，而是一个"demo 级别"的权宜之计。

三、V2.1：补齐流程断点

V2.1 的核心思路：为流程中每个"需要判断"的环节，提供结构化的 prompt 模板，让 AI 的决策有据可依。

3.1 新增 5 个辅助 Prompt 模板

3.2 标准化 6 步流程

Step 1: Upload        → 上传照片到后端，拿到 blog_id
Step 2: Vision        → 逐张看图，结构化分析（场景/情绪/细节/叙事线索）
Step 2.5: Sequencing  → 照片智能排序，输出最佳叙事排列 + 分章建议
Step 3: Style Match   → 匹配模板 × 文风，附推荐理由
Step 4: Write         → 用选定风格生成文章
Step 5: Title         → 生成候选标题 + 多平台摘要
Step 6: Publish       → 发布到后端渲染，返回在线链接

每一步都有明确的 输入、输出、可选跳过条件。比如 Step 2.5 的跳过条件是"用户已手动排好序，或只有 1-2 张照片"——不是每个步骤都必须走，但跳过是有条件的，不是随意的。

3.3 实战验证：伊豆游记

V2.1 的首次完整实测是一组 9 张伊豆半岛旅行照片：

• Vision 分析：识别出缆车、火山口、富士山远眺、城崎海岸吊桥、飞鸟、人像、烤肉等场景

• 照片排序：从缆车出发 → 火山口 → 远眺富士 → 吊桥 → 海岸 → 飞鸟 → 人像 → 烤肉，构建了完整的一日游叙事线

• 风格匹配：推荐 film（胶片模板）+ literary（文艺散文），理由是照片色调温暖、有胶片质感

• 最终产出：「伊豆：从火山口到海角，我们把一整天的蓝都收进眼睛里」

关键收获：有了结构化的 prompt 引导，AI 的决策质量和一致性显著提升。 排序不再随机，风格选择有理有据，标题生成有多个选项供挑选。

四、V2.2：封装后端交互脚本

V2.2 的改动很小但很关键：把散落在 SKILL.md 文档里的 curl 命令，固化为 Skill 内的 Python 脚本。

4.1 三个脚本

scripts/
├── upload.py     # 上传照片
├── publish.py    # 发布博客
└── manage.py     # 列表 / 查模板 / 删除

upload.py — 上传照片，返回 blog_id：

python scripts/upload.py photo1.jpg photo2.jpg photo3.jpg
# → {"blog_id": "20260507_xxx", "images": ["01.jpg", "02.jpg", "03.jpg"]}

publish.py — 发布文章（正文写入临时文件，避免 shell 转义问题）：

python scripts/publish.py <blog_id> film "标题" "摘要" /tmp/article.txt 01.jpg 02.jpg
# → {"blog_id": "xxx", "url": "/blog/xxx"}

manage.py — 日常管理：

python scripts/manage.py list          # 列出所有博客
python scripts/manage.py templates     # 查看可用模板
python scripts/manage.py delete <id>   # 删除博客

4.2 为什么这件小事值得单独做一个版本

看起来只是"把 curl 包了一层"，但本质区别是：

核心原则：Skill 里的流程描述应该是"调什么"，而不是"怎么拼"。 把"怎么拼"下沉到脚本层，让流程层保持干净。

五、当前架构全景

经过 V2.1 和 V2.2 的迭代，旅行博客生成器的 Skill 层架构已经形成了三层清晰的分离：

┌──────────────────────────────────────────┐
│            流程层（SKILL.md）              │
│     6 步标准化流程，定义"做什么、何时做"      │
├──────────────────────────────────────────┤
│           模板层（templates/）             │
│  11 个 prompt 模板：6 写作 + 5 辅助工具     │
│  → 定义"怎么想"（AI 的思考框架）             │
├──────────────────────────────────────────┤
│           脚本层（scripts/）              │
│  3 个 Python 脚本：upload / publish / manage│
│  → 定义"怎么做"（与后端的交互细节）           │
└──────────────────────────────────────────┘
         ↕ REST API（localhost:8765）
┌──────────────────────────────────────────┐
│         后端服务（app.py ~250行）           │
│    存储 + 渲染，零 AI 逻辑，5 套 HTML 模板   │
└──────────────────────────────────────────┘

每一层的职责边界清晰：

• 要加新写作风格？往 templates/ 扔一个 txt

• 要加新排版样式？往后端 templates/ 扔一个 html

• 要改 API 接口？改 scripts/ 里的脚本

• 要调整流程？改 SKILL.md

• 以上所有改动，后端代码零修改

版本迭代路线

六、下一步

还有几个方向在规划中：

• 图片 CDN/OSS：目前图片存本地磁盘，访问速度取决于服务器带宽。上 OSS + CDN 后加载体验会好很多

• HTTPS + 域名：目前是裸 IP + HTTP，不够正式

• 前端模板切换器：让用户在浏览器里直接切换模板预览效果，不需要重新发布

V2.1 和 V2.2 的改动都不大，加起来可能不到 200 行代码。但它们解决的是工程质量问题——让 AI 的工作流从"能跑通"进化到"跑得稳、跑得一致"。 这和写业务代码是一样的道理：功能做出来只是第一步，做得可靠、可维护才是真正的交付。