企业官网建设流程全解析

⚡ 快速参考

• 一句话：这篇文章复盘一次“把原型图 + 接口文档 + 资源文件”交给 AI 做 uni-app(Vue3) 小程序开发的实践，并把“可复用的协作流程”沉淀成一个 Skill。
• 最短路径：.cursor/skills/uniapp-vue3-mini-program/SKILL.md+docs/design|spec|assets|db+ 固定开场口令（Mode A）。
• 核心成果：不再依赖 AI“猜交互”；用docs/spec承载跳转与参数，用docs/assets承载资源台账，用“先提案后重命名”降低改名事故。
• 仓库地址：truck-hailing/uniapp-vue3-skills

一、概述

1. 这个skills到底在做什么

现在AI开发很常见情景：原型图已经画好、后端接口也给了，页面看起来“就差把代码敲出来”。AI实践里真正消耗时间的，往往不是把 UI 堆出来，而是这些细碎但致命的缝隙，当前的AIcode能几乎满足所有的需求，但是那些致命的缝隙很容易拖慢整个项目的进度：

• 同一张原型图到底对应哪个路由？
• 某个按钮点了跳哪一页？带不带参数？返回要不要刷新？
• static/里一堆图片和 svg，名字不统一，后面维护像在扫雷。

该Skill 的目标，是把这些缝隙“写成流程”，让 AI 每次都走同一套轨道，而不是靠当下的灵感和运气。

2. Skill 与 docs：一个负责流程，一个负责事实

这套方法里最重要的分工是：Skill 写流程，docs 写事实。

docs/的存在感一开始不强，但一旦项目进入第二周，价值会突然变得很具体：很多确认过的细节不需要再确认第二次。

二、原理/实战详解

1）先说使用：一次“交付”怎么跑起来

这部分不做教程式的平铺，按一次真实交付的节奏拆解。

1.1 开场：让 AI 进入同一条轨道

实践里最容易忽略的一点是：不明确“使用哪个 Skill”，AI 可能不会自动进入固定流程；直到出现某个关键词（例如“低工作量模式”）才开始按规则做事。

因此，开场口令固定化是必要的（Mode A 最常用）：

• 声明使用uniapp-vue3-mini-program
• 声明发布端（mp-alipay/mp-weixin/h5/app-plus）
• 声明本次先做哪些页面（1~3 个）
• 声明要先盘点、再提问、再规范化、最后严格按原型实现

一旦开场定住，后续过程会明显稳定：它会先把“可猜的部分”变成“必须确认的问题”。

1.2 输入：可以不完整，但要可追溯

允许的输入形态很“现实主义”：

• 只有原型图图片也能开工（但交互必须补问）
• 接口文档只有一份API_DOC.md也能开工（spec 允许最小起步）
• 资源文件先放进static/，名字可以先乱着（后续走重命名提案）

1.3 阶段化推进：把不确定变成可回写

Skill 里最终定下的是四阶段：

这张图对应的心理变化是：一开始以为“只差写代码”，后来发现“缺的是一套可复用的确认与回写机制”。

2）再说经历：哪些问题把 Skill 从“短”打磨到“能用”

2.1 第一次失败：AI 会画 UI，但会“脑补交互”

只给静态原型图时，UI 往往能做得八九不离十，但点击跳转会出现高频偏差：按钮跳错页、参数没带、返回刷新策略不一致。

这次复盘里，一个很明确的结论是：

• UI 可以先做，但跳转逻辑不能猜。

于是 Hard Rule #1 被写死：没有交互定义，不允许假设跳转逻辑。实践效果是，跳转类问题会被强行转化为“逐条确认清单”。

2.2 第二次失败：资源命名像雪球，越滚越重

资源命名问题的“真实成本”很隐蔽：第一天觉得不重要，第二周开始痛苦。

于是另一个 Hard Rule 被写死：重命名必须先提案后执行。更进一步，阶段 2 强制产出三样东西：

• static/资源盘点表（文件 → 类型 → 疑似语义 → 命名问题）
• 重命名计划表（旧名 → 新名 → 影响文件/引用处）
• 确认后自动批量改名 + 全局替换引用，并回写docs/assets/manifest.md

到这一步，资源整理才从“口头希望”变成“流程产出”。

2.3 一个关键转折：spec 允许最小起步

很多项目最初只有接口文档，页面映射与交互都是边做边确定的。若把docs/spec设计成“一开始就得写完整”，启动成本会变高，流程会被反噬。

因此最终落地成：docs/spec允许最小起步——先挂接口来源，后续逐步补screens.md的 slug/路由/原型映射与跳转逻辑。

3）目录契约：把“信息应该写在哪”写成不容争辩的规则

目录契约本质是降低沟通成本：阶段 2 做完后，AI 必须知道“该往哪回写”。

同时，资源命名默认模板也写死在 Skill 里：

• 图标：static/icons/ic-{semantic}[-{state}].svg
• 图片：static/images/{module}-{purpose}[-{state}].png

三、避坑/经验总结

1）触发不稳定：靠“自然描述”不如靠“开场口令”

触发不稳定不是玄学，而是匹配机制的现实：description关键词 + 当次对话命中度不足，就可能不启用。

这次把触发词补强到“真实会说的话”（screens.md、static 资源整理、批量重命名、manifest 台账）后，命中率显著提升；但最稳的仍然是固定开场口令。

2）原型图“能猜”不等于“该猜”

AI 能从 UI 形态推测出一些常见交互，但在工程里，猜错一次的成本远大于多问两句。

因此 Hard Rule #1 的意义是：不阻止推测，但阻止把推测当事实写进代码。

3）重命名不是小事：先提案再执行才能可控

真正的问题不在“怎么改名”，而在“怎么确保引用没漏”。把影响范围写成表，再执行批量操作，风险会成数量级下降。