成品展示

案例小程序「科学月子餐」：孕产饮食参考与记录向工具；内容仅供参考，遵医嘱。

太阳码（微信扫一扫）：

微信内打开可复制：#小程序://科学月子餐/今日推荐/Y5LbwGtSevXelTu　｜　搜索：小程序栏搜「科学月子餐」。

---

一、先把话说清：什么叫「正经 Vibe coding 教程」

下面按「能力分层」把这件事说清楚：

层次	读者带走的能力	典型载体
协作协议	知道怎么跟 AI 说话才不会跑偏	提示词模板、负面约束清单
项目记忆	同一仓库里反复出现的坑只教一次	Cursor Rules、团队 AGENTS.md
重复工序	裁剪图、提审自检、写更新说明	Cursor Skills、脚本说明文档
权威细节	API 参数、字段上限、审核口径	官方文档链接，而不是抄半页 JSON

代码块不是原罪，但「整页贴业务代码」往往既不能跑（缺上下文）又不能学（字段与你无关）。本文把代码级细节全部外包给微信开放文档（链接见文末「参考链接汇总」），正文只写：你该在文档的哪一节停住、用什么提示词让 AI 按那一节生成、你用 Rule 禁止它做什么。

---

二、工具链：不绑定 Cursor，把「能力拆清楚」

形态	你实际买到的是什么	Vibe coding 里负责哪一段
Cursor	编辑器 + 索引 + Agent + Rules/Skills/MCP	最适合「整仓改、多文件、要守规矩」
Claude Code / Code X 等	终端/IDE 里的长上下文 Agent	适合「命令式拆步、配合 git」
Trae 等免费方案	低成本补全 + 对话	适合「预算为零、任务拆更碎」
网页 DeepSeek / Kimi	纯对话，无仓库索引	适合「写提示词草稿、拆接口、写文案」；落盘与编译仍要回开发者工具

接地气的一句话： 工具换来换去，不变的是三件事——约束写清、每步可编译、真机扫一眼。下文默认以 Cursor 为例讲 Rules、Skills、按需 MCP 与 Agent 对话（均指 Cursor 产品内能力）；你用别的工具，就把 Rule 等价成「系统提示词 + 项目 README 里给 AI 的固定段落」，把 Skill 等价成「你自己收藏的 Checklist 文档」，MCP 往往没有同名入口，用脚本或书签替代即可。

---

三、Cursor Rules：给 Cursor Agent 的「宪法」，专治「模型自作主张」

官方对 Rules 的定位见 Cursor Docs · Rules。结合小程序个人项目，我建议你把 Rule 想成三类条款（写进 .cursor/rules/ 下不同 md，按需 Always / Intelligently Apply）：

3.1 技术栈条款（硬约束）

用自然语言写即可，例如：「本项目为微信原生小程序，禁止引入 uni-app、Taro、npm 构建链；禁止随意添加未在 app.json 注册的页面路径。」
目的：防止模型为了「显得专业」上框架，把你首版体积与审核风险一起抬上去。

3.2 目录与修改边界条款

写明：「主包 Tab 页在 pages/；低频页只许出现在分包 packageExtra/（或你的分包根）；改路由必须先改 app.json 再生成页面四件套。」
对应官方地图：全局配置 + 分包。

3.3 合规与文案条款（越早写越省返工）

尤其健康、饮食、育儿类：在 Rule 里直接列「禁用词」「必须出现的免责声明位置」（例如关于页、知识详情顶部）。审核大面见 运营规范。

3.4 Rule 写作习惯（比「写长」更重要）

• 短而硬：一条规则一个意图，宁可拆文件，不要一篇两千字谁也不看。官方也建议控制体量（见 Rules 文档中的实践说明）。
• 可验证：每条规则对应「怎么验收」——能编译、能搜到关键字、能上传。
• 出现真坑再追加：模型重复犯同一错，再把那条写进 Rule；不要第一天堆满预言式规则。

---

四、Cursor Skills：把「你每次都要唠叨一遍」的事做成标准作业

Skills 的定位见 Cursor · Skills 文档（备用入口 Help · Skills）。和 Rules 的差别可以记一句：Rule 像交规，Skill 像「科目二步骤清单」。

适合做成 Skill 的小程序工序举例（仍不写业务代码，只写流程名，读者按自己项目填空）：

Skill 名称（示例）	里面该有什么	对应官方文档锚点
「新建页面并注册路由」	检查 app.json → 建四件套 → 编译 → 真机点路径	app.json pages
「加 Tab 并验证 switchTab」	tabBar 与 pages 一致性、switchTab 与 navigator 的 open-type 心智表	tabBar + wx.switchTab
「拆分包与路径冒烟」	主包体积预警、分包 root、从主包按钮 navigateTo 冒烟路径	分包加载
「提审材料自检」	截图路径、类目、隐私声明、测试账号说明	运营规范 + 隐私指引
「发版说明与回滚记录」	版本号 semver、体验版备注模板、回滚到上一版操作位置	公众平台 版本管理

经验： Skill 越长，越要用标题层级和「勾选框」排版；Agent 执行时不容易漏步。你自己人工走流程时也同理。

---

五、提示词工程：真正值得固化的是这些，不是大段业务代码

5.1 会话开场白模板（每次新开对话用）

把下面整段当作「固定头」，后面再接你的具体需求（自然语言即可，中文往往更稳）：

你是微信小程序原生开发助手。必须遵守：不引入 uni-app/Taro/npm 构建；所有新页面必须在 app.json 注册；优先使用官方 API。若需要示例，只引用微信开放文档链接并用文字说明步骤，不要编造未经验证的私有 API。每轮输出后列出「将修改的文件路径清单」，等我确认再应用。

作用： 把「模型爱炫技」压到最低，把「可审计的变更面」抬到最高。更多固定头与填空模板见附录 D。

5.2 需求描述模板（写功能时用）

用五段式，顺序不要乱：

1. 用户故事：谁在什么场景点哪里，看到什么结果。
2. 页面范围：只动哪些路径（例如仅 pages/index 与 utils/foo）。
3. 数据策略：本地 storage 还是云；字段命名前缀；是否需要迁移版本号。官方见 数据缓存。
4. 路由策略：普通栈还是 Tab；若涉及 Tab，显式写「必须用 wx.switchTab」。见 路由 API。
5. 验收：开发者工具无报错、真机预览路径、边界 case（空数据、杀进程重开）。

5.3 「拆步」比「一次生成整个项目」更贴 Vibe coding

个人项目最亏的提示词是：「帮我做一个完整小程序」。正确拆法：

轮次	你要模型交付什么	你怎么验收
R1	只动 app.json + 说明新增了哪些 pages	编译通过、首页能开
R2	只动首页展示 + 读静态数据模块	无网络也能显示
R3	只动设置页 + 写入 storage	杀进程重开仍在
R4	才动 Tab / 分包	每加一层，真机扫一遍

网页 DeepSeek / Kimi 的用法： 没有仓库索引时，更要坚持「一轮一个交付物」，否则漏文件概率指数上升；每一轮结束你自己在开发者工具点一次「编译」。

5.4 排错提示词：贴日志，别贴情绪

把开发者工具完整红字、相关文件路径、你期望的行为三段贴给模型；最后加一句「不要改无关文件」。这比写「坏了帮帮我」省一半 token 一半时间。

---

六、微信小程序侧：只讲「地图怎么用」，不讲「替你走路」

6.1 你至少要在官方文档里读完的五个「锚点」

1. 框架：理解逻辑层/视图层、为什么有 setData。
2. app.json：理解首页、tabBar、subpackages 三者的耦合。
3. Page：理解生命周期与数据驱动。
4. 路由：理解 switchTab 不能带 query 的限制。
5. 运营规范：理解「能写」与「不能写」。

读完的标志： 你能用自己的话给 AI 下指令，而不是让 AI 替你读文档。

6.2 自定义 TabBar：为什么 Vibe coding 里常踩坑

官方文档：自定义 tabBar。常见坑不是「不会写组件」，而是：tabBar.list 与自定义组件里维护的路径顺序不一致、该 switchTab 的地方用了 navigateTo。
这类坑最适合写进 Rule（硬约束）+ Skill（逐步冒烟），而不是写进正文代码块。

6.3 分包与体积：什么时候该拆，交给「指标」而不是「感觉」

官方：分包加载。
实务建议：当你开始频繁改 project.config.json 的 packOptions.ignore、或上传提示主包吃紧，就把「拆分包」写成 Skill 的第一步，并在 Rule 里写「新增低频页默认进分包根，不许默认塞主包」。

6.4 隐私与用户数据：Vibe coding 里最容易被忽略的一节

官方：用户隐私保护指引。
你只要真的读了「收集哪些信息、展示在哪些界面」，你的提示词里就会自然出现「在关于页放入口、在设置页解释用途」——这类句子比任何代码都影响审核通过率。

---

架构速写：只须先定的五件事

个人小程序不必先画 C4 全图。

但在 Vibe coding 里，若下面五件事没有在 Rule / Skill 里各有一句硬结论，Agent 最容易在分包、存哪、上云、过审这些交叉面上替你「先做了再推翻」。每一条都只要求你能用一句话答清——答完写进仓库，比多堆业务代码更省返工。

先决项	你要能一句话说清楚	建议落点
上下文边界	用户与数据在哪些界面、哪些账号/主体下活动；哪些能力明确不做（例如不做站外交易闭环、不接某类 SDK）	Rule：产品边界 + 技术栈禁止项；提示词里写清「本轮不碰的目录」
数据主权	关键状态放本机 storage 还是上云；谁有权清空；key 前缀与 version 迁移谁负责	Rule：storage 约定与禁止 clearStorage；Skill：杀进程重开验收
路由与分包策略	主包只扛哪些路径；低频页默认进哪个分包根；Tab 与栈混用时传参约定（尤其 switchTab 无 query）	Rules + 下文第七节表；Skill：主包 → 分包路径冒烟
合规与扩展开关	类目与文案红线；免责声明与隐私入口固定出现在哪几页；云开发 / 第三方接口是否默认关、由谁显式打开	Rule：合规条款 +「云开关只在 app.js 某 flag 为 true 时初始化」类条款
观测与回滚	线上问题靠体验版 + 真机还是接埋点；发版版本备注写什么；出事时回滚上一版谁操作、可接受停机多久	Skill：发版前自检；流程锚点见 公众平台 版本管理

与第七节的关系： 第七节用「科学月子餐」把上表里的路由与分包、数据主权、扩展开关等，落成可抄的决策句；你换选题后，仍以本节五向量为骨架，只替换领域词与目录名即可。

---

七、案例复盘：以「科学月子餐」为例——决策怎么迁移到「你的产品」

先对齐目标： 这一节不是「产品说明书」，而是借一条真实业务线，说明当你在任意选题下做小程序时，哪些决策该写进 Rule、哪些该拆进 Skill、提示词里该锁哪些边界。你把表格里的「月子餐 / 分包名」换成自己的领域与目录即可。

产品一句话（示例）： 面向孕晚期 / 产后的「饮食参考 + 记录 + 知识」工具向小程序；不做订餐、不做付费会员；内容口径按工具/信息查询类自我约束，医疗承诺词不进文案。

工程决策（与提示词/Rule 的对应关系）：

决策	为什么	提示词 / Rule 里怎么写才落地
主包只放高频 Tab	控制首包、减少首屏解压时间	Rule 写明 pages/ 与分包职责；Skill「新建页」里强制问一句「是否 Tab」
低频页进分包	日历、导出、长表单等打开少	Rule 写默认分包根路径；提示词里写「新页面路径以 /packageExtra/ 开头」
数据先本地	首版不接后端，缩短闭环	提示词写「只用 storage，不接云」；接云时另开分支再改 Rule
云能力开关预留	避免第二次推翻	Rule 写「云初始化只能出现在 app.js 某开关为 true 时」；官方云开发入口见 云开发文档（按需阅读）
Tab 与详情带参	switchTab 无 query	Rule 写「Tab 进详情必须用全局队列 + 目标页 onShow 消费」；这是模式，不是具体字段名

这一节刻意不写「日记字段长啥样」——字段名、页面数都该由你的产品决定；你要抄的是决策模板：主包放什么、分包放什么、数据先本地还是先云、Tab 与详情怎么传参——换选题，模板不变。

---

八、经验教训：仍然偏「流程与话术」，不偏「源码」

8.1 审核与产品口径

经验	怎么做	官方依据
类目与功能一致	用体验版让「完全不懂的人」口述产品，再对照类目	运营规范
文案避免医疗承诺	Rule 里列禁用词；发布前全文搜索「治愈」「根治」等	同上
截图诚实	审核截图必须覆盖真实主路径	同上

8.2 工程协作

经验	怎么做	官方依据
路由心智稳定	把 switchTab 限制写进 Rule，减少「能跑但路径偶发错」	wx.switchTab
存储可迁移	提示词要求加 version 字段；迁移写独立函数	数据缓存
体积可控	Skill「发版前」包含压图、ignore 文档目录	分包 + 工具上传提示

8.3 Vibe coding 的反噬

坑	对策
模型乱加框架	Rule 技术栈条款 + 每轮验收编译
提示词太大	固定头 + 五段式需求 + 拆轮次
没有 Skill	你会在第三个页面开始重复唠叨同一套步骤

---

附录 A：从注册到提审的「流程清单」（仍无代码，只指路）

阶段	你在做什么	建议打开的文档/后台
注册	拿 AppID、定主体	公众平台
开发	新建项目、首屏、主路径	开发者工具 + 框架
配置	app.json、页面、分包、Tab	全局配置
联调	真机预览、体验版	工具内按钮 + 公众平台版本管理
提审	类目、截图、隐私、测试号	运营规范 + 隐私指引

---

附录 B：和 AI 协作时的场景问答（B-1～B-10）

B-1 模型总想上框架怎么办？

回到 Rule 技术栈条款；并在提示词里写「若你认为需要框架，必须先输出理由 + 对包体积与审核的影响，再等待我确认」。绝大多数个人工具小程序不需要。

B-2 模型一次改十个文件我不敢点应用？

要求它输出「文件路径清单 + 每个文件改动的目的」，你只允许本轮改其中三个；其余下一轮。配合 git 本地提交，心理负担会小很多。

B-3 真机与模拟器表现不一致？

优先信真机。把差异现象 + 机型 + 基础库版本贴进提示词，让它对照 官方更新日志 里相关条目（按需检索）。

B-4 审核说「类目不符」怎么改？

只有两条路：改功能或改类目，不要试图用长文申诉硬刚。先把功能口述成一句话，对照 运营规范 里类目描述。

B-5 我不用 Cursor，Rule/Skill 放哪？

放 AGENTS.md / CONTRIBUTING.md / docs/ai-conventions.md 任意你团队会读的地方；核心是可检索、可复用，不是文件名。

B-6 提示词要不要写英文？

模型读英文也强，但你写中文需求往往更准。建议：固定约束用中英混合短句（例如技术名词英文、业务中文），整体以你能稳定复写为准。

B-7 我想「一天上线」现实吗？

现实的是「一天把可提审骨架跑通」：账号、工具、主路径、存储、真机、上传。内容堆满与审核一次过，仍取决于类目与材料诚实度——这部分请尊重平台节奏，别被标题党绑架。

B-8 文章里要不要放「我的提示词全文」？

可以，但建议放模板而非带隐私的项目全文。模板才有复用价值；全文往往绑定你的字段名，对他人是噪音。

B-9 Skill 会不会太长导致 Agent 忽略？

会。Skill 也要分段、标题、勾选框；超过你一次读不完的篇幅，Agent 更容易漏步。官方 Skills 文档同样强调「可执行、可检索」。

B-10 最后一条：比万字更重要的是「你真机扫过一次」

任何教程替代不了你手指在真机上点的那三十秒。把真机预览写进你的 Skill 第一步，写进你的肌肉记忆。

---

九、逐场景演练：不写业务代码，也能把 AI 用到「可验收」

下面五个场景，是我在做这一类工具型小程序时反复踩过的；与是不是月子餐无关。每个场景只给你：该打开哪篇官方文档、提示词里必须出现的约束句、怎么验收。请把整段复制进你自己的项目会话，把示例里的路径、分包名、业务名词全部换成你正在做的产品。

场景 1：从「空仓库」到「能编译的首屏」

你先读： 框架 · 目录结构 与 全局配置 里关于 pages 数组的说明。你要建立的心智是：pages 第一项就是冷启动首屏，任何「先 splash 再进首页」的炫技都会增加首屏成本。

提示词必须写清的约束： 只允许微信原生；本轮只交付「能显示静态标题的首页」；禁止创建未在 app.json 注册的页面；禁止引入第三方构建。验收标准一句话：开发者工具点编译无红字、模拟器能看到标题。

常见翻车点： 模型顺手加了它熟悉的脚手架目录，你的 Rule 里若没写「禁止改 project.config.json 的 compileType」之类边界，它就会动你不关心的配置。建议把「允许改动的配置文件白名单」也写进 Rule：通常首版只允许 app.json、app.js、app.wxss、pages/**。

场景 2：从「首页」到「第二页并能返回」

你先读： 路由 wx.navigateTo 与 Page 生命周期。重点理解：页面栈深度有限，别把用户推进无限深的「下一步」。

提示词约束： 明确写「第二页用 navigateTo 打开，保存后用 navigateBack 返回」；并要求模型说明「为什么不用 redirectTo」。这不是考它，是逼它把路由心智讲出来，减少你事后返工。

验收： 连续前进后退十次不报错；杀进程回到首页状态符合你预期（若不符合，就要在提示词里写清「返回后首页读哪里的数据」）。

场景 3：准备上 Tab 之前的「冷静期」

你先读： tabBar 配置 与 wx.switchTab。读完后你应该能复述：Tab 页互跳只能 switchTab，且不能带 query。

提示词约束： 让模型先输出「Tab 列表与页面路径对照表（文字表格即可）」，你人工检查路径是否与磁盘一致、是否与 pages 注册一致，再允许它改代码。Tab 是最典型的「配置与实现双写」区域，不配这一步，后面你会在真机上遇到「点了没反应」的神秘感。

若你要自定义 TabBar： 再读 自定义 tabBar。提示词里要求模型同时改三处：app.json 的 custom、组件目录、list 顺序映射——并让它自检「选中态如何跟随 route」。

场景 4：分包第一次落地时的「路径冒烟」

你先读： 分包加载。你要记住的不是语法，而是：从主包跳到分包页时，路径要以分包 root 开头，且分包页不能再假设自己还在主包相对路径里 require。

提示词约束： 让模型输出「从首页某个按钮到分包页的完整点击路径」，包括：按钮绑定函数名、跳转 API 名称、目标路径字符串。你拿着手机一步步点，点不通就让模型只改「路径与注册」直到冒烟通过。

验收： 上传前看包体积提示；体验版里让完全不懂的人按路径点三次，能点通才算过。

场景 5：提审前夜的「材料对齐」而不是「再加一个功能」

你先读： 运营规范 里与你类目相关的章节，以及 用户隐私保护指引。这一晚最忌讳的是：你觉得「不够酷」又加功能——加功能会引入新截图、新文案、新隐私点，审核风险反而上升。

提示词用法： 让模型当你的「审核员替身」：把你准备提交的功能描述、截图顺序、隐私勾选逐项朗读一遍，让它找「与文案不一致」之处。你要的不是它替你做决定，而是它帮你做交叉检查。

验收： 你自己再用普通话录屏讲一遍主路径，能讲顺再提交。

---

十、Rule 条文示例库：十二条自然语言条款（按需改成你的「宪法」）

下面十二条全部是自然语言条款示例，不是代码。建议拆进 .cursor/rules/ 多个文件：技术栈、目录、路由、数据、合规、发版各一份，避免单文件过长（官方 Rules 文档也建议克制篇幅，见 Rules）。

1. 技术栈锁定： 本项目为微信小程序原生；未经人类确认不得引入跨端框架与 npm 构建链。
2. 页面注册纪律： 任何新页面必须先更新 app.json 的 pages 或分包 pages 列表，再创建页面文件。
3. 主包瘦身： 默认禁止把低频功能页面放在主包 pages/；若确有需要，必须写明理由与体积评估。
4. 路由纪律： 凡 tabBar 内页面互跳，必须使用 wx.switchTab；禁止用 navigateTo 冒充 Tab 切换。
5. 参数传递纪律： 禁止在 switchTab 路径上拼接 query；跨 Tab 传参只能用应用内约定队列（由人类定义队列字段名）。
6. 存储纪律： 所有本地存储 key 必须带项目前缀与版本后缀；禁止在页面内硬编码魔法字符串散落读写。
7. 数据迁移纪律： 一旦调整 settings 结构，必须同时给出迁移策略说明，禁止静默丢数据。
8. 日志纪律： 发版前减少无意义 console.log；禁止日志输出用户敏感输入。
9. 图片纪律： 新增大图必须先说明体积与压缩策略；禁止把设计稿 PSD 原图打进上传包。
10. 合规纪律： 禁止生成诊断、治疗、功效承诺类文案；涉及健康必须出现「仅供参考」提示语（位置由人类指定）。
11. 隐私纪律： 任何涉及相册、定位、剪贴板等能力，必须先对齐 隐私指引 再写提示词让模型改代码。
12. 发版纪律： 上传前必须跑一遍「真机预览 + 体验版成员试玩」；禁止跳过体验版直接盲提审。

这十二条的价值在于：它们把「你每次跟 AI 唠叨的话」固化成项目记忆。模型再聪明，也不如你把纪律写成可检索文本。

---

十一、审核与话术：把「能通过」当成一种可训练的写作课

审核不是玄学，它更像阅读理解 + 一致性检查。你可以训练自己做三件事。

第一件事，把产品一句话写成小学生能懂的动词句。例如「帮妈妈记录每天吃了什么」比「打造全链路数字化营养赋能平台」更像人类语言，也更不容易触发「虚假宣传」类敏感。运营规范入口见 运营规范。

第二件事，把截图当成故事板。第一张：打开小程序第一眼；第二张：用户最常点的核心按钮之后；第三张：设置或关于（若有数据收集，这里要出现隐私入口）。顺序错误会导致审核员推断错误。此处不需要代码，需要的是信息架构诚实。

第三件事，把隐私声明当成合同条款写。你只收集了什么，就用一句话解释用途；没收集就不要勾选。官方指引见 用户隐私保护指引。很多个人项目翻车不是功能问题，而是「勾了但没做」或「做了但没勾」。

---

附录 C：更多场景问答（B-11～B-20）

B-11 我让 AI 写文案，会不会被判定营销过度？

有可能。你要在提示词里明确「禁止绝对化用语」，并在 Rule 里列禁用词表。上线前仍建议人工通读一遍，尤其是首页首屏与分享标题。

B-12 Skill 和 README 有什么区别？

README 给人看，Skill 给 Agent 当作业指导书；Skill 更应该短、可执行、可勾选。官方对 Skills 的说明见 Skills。

B-13 我需要 MCP 吗？

首版小程序多数不必上 MCP；当你要高频对接仓库外的系统（Notion/Jira/设计稿 API 等）再评估。更细的「该不该接」对照表 + 对话模板见附录 D-12、D-13。官方说明见 Cursor · MCP；总入口仍见 Cursor Docs。

B-14 模型引用了一个不存在的 API 怎么办？

让它给出官方文档链接再允许合并；链接打不开的 API 一律视为幻觉处理。养成习惯后，你会少踩很多「能编译但真机挂」的坑。

B-15 我想把「写测试」也交给 AI？

可以，但要先定义你能运行的最小测试形态。小程序侧可参考官方与社区工具链文档，不要把「测试」写成口号。首版更现实的测试往往是：真机路径冒烟 + 体验版用户访谈。

B-16 我能不能让 AI 直接帮我填审核表单？

可以辅助，但不要盲信。审核表单里的每一句话最终责任在你。用 AI 做「校对与一致性检查」比让它「替你吹牛」安全。

B-17 我被拒三次了还要坚持个人主体吗？

这取决于类目与功能。若连续因资质问题拒绝，停下来读拒因原文，对照 运营规范 做「减法」比硬刚更有效。

B-18 我想做社交裂变，提示词要注意什么？

社交能力与分享文案更容易触碰平台规则。建议先把分享路径与内容边界写进 Rule：哪些页面允许分享、分享标题必须包含哪些提示语。

B-19 我同时用 Trae 和 Cursor 会不会冲突？

不会，只要你 git 管理好。关键是「同一时刻只有一个 Agent 在改仓库」。人类当合并者，别两个工具同时自动 apply。

B-20 这篇文章读完我下一步做什么？

打开微信开发者工具，新建或打开你自己的小程序项目，复制第九章「场景一」里的提示词约束（把路径与业务词换成你的），跑通编译；然后写下你的 Rule 第一条（技术栈与边界）。只要这一步完成，你就已经从「看教程」进入「用 Vibe coding 做自己的产品」。若想少绕弯路，可先打开文末附录 D，把会话固定头和 Rule 片段存进项目再迭代。

---

附录 D：开发过程中可复制复用的「家伙式」总盘

这里的可复制，指换项目、换需求还能接着用的协作资产：提示词套路、Rule 切片、Skill 工序、按需的 MCP 决策——不是某页业务 WXML。下表按「提示词 → Rules → Skills → MCP」组织；D-1～D-8 为整段模板，D-9～D-13 为短套路与 MCP 专用段落。

再强调一遍： 下表及本附录中的 Rules / Skills / MCP，以及 D-1 里「新开 Agent」，一律是 Cursor 开发流程里的概念；与微信开发者工具无同名对应项。

D-0 一张表分清：你每个阶段该抄哪类东西

家伙式	典型用途（开发过程中）	一般落盘位置	附录索引
提示词套路	固定上下文、限制模型越界、拆步、排错、要官方链	会话里粘贴；可另存 docs/prompts.md	D-1～D-4、D-8、D-9
Rules	长期约束：技术栈、路由、分包、合规、别乱改配置	.cursor/rules/*.md（规则写法见 Rules）	D-5、D-10
Skills	重复工序：新建页冒烟、发版前自检、压图说明	Cursor Skills 或仓库 docs/skill-*.md（见 Skills）	D-6、D-11
MCP	把外部系统接进对话：文档站、缺陷单、设计稿 API 等	Cursor MCP 配置（见 MCP）	D-12、D-13
自检清单	提审前、合并前逐项核对	备忘录 / PR 模板	D-7
Agent	在 Cursor 里开一轮「能读仓库、能改文件」的自动化对话	Cursor Agent 会话（见 文档首页）	D-1（先贴固定头）

D-1 会话固定头（标准版，新开 Cursor Agent 先贴）

你是微信小程序原生开发助手。硬约束：
1）禁止引入 uni-app / Taro / npm 构建链；
2）所有新页面必须先出现在 app.json 的 pages 或分包 pages 里；
3）需要 API 说明时只引用微信开放文档链接，禁止编造未公开的 wx 接口；
4）每一轮回复末尾列出「将修改的文件路径清单」，在我回复「应用」前不要假设已写入磁盘。

当前仓库是我的个人产品（非教学模板），请尊重现有目录命名。

D-2 会话固定头（加强版：防乱改配置）

在 D-1 后面追加一段：

额外约束：未经我明确点名，不要修改 project.config.json、不要改云环境 ID、不要执行会清空用户数据的逻辑。若你认为必须改 project.config.json，请先说明理由和影响面，再等待我确认。

D-3 需求五段式（填空版）

【用户故事】作为（角色），在（场景）下，我要点（入口）看到（结果）。
【页面范围】本轮只允许改动：（路径1）（路径2）；禁止动：（其它路径）。
【数据策略】使用（本地 storage / 云开发）；storage key 统一前缀为（前缀_）；是否需要版本字段（是/否）。
【路由策略】涉及 Tab 则必须 wx.switchTab；普通页用 navigateTo / navigateBack。禁止 switchTab 带 query。
【验收】开发者工具无红字；真机预览路径为（步骤简述）；边界：（空数据 / 杀进程重开）不白屏。

D-4 一键口令：先出「变更计划」再动手（防一锅端）

请先只做两件事，不要改任何文件：（1）用无序列表给出你将修改的文件路径及每处改动目的；（2）标出可能受影响的 tabBar / 分包路径。我确认后你再按清单逐步应用。

D-5 可放进 .cursor/rules/ 的规则片段（示例文件名：wechat-miniprogram.md）

Cursor 不同版本对 Rule 文件名、是否支持 mdc 略有差异，以 Rules 文档 为准。下面是一段规则正文（保存为 .md 即可），此处用引用块排版便于阅读，复制时整段选中即可。

微信小程序 · 个人项目边界

技术栈

• 仅使用微信原生小程序（WXML / WXSS / JS / JSON）。
• 禁止引入 uni-app、Taro、Webpack/npm 等跨端或构建链，除非我逐条书面确认。

路由与 Tab

• tabBar 内页面互跳必须使用 wx.switchTab。
• 禁止在 switchTab 的 url 上拼接 query；跨 Tab 传参使用应用内约定队列（字段名由项目统一文档规定）。

页面与配置

• 新建任何页面前，必须先更新 app.json（主包 pages 或 subpackages 下 pages），再创建页面四件套。
• 低频页默认进我指定的分包根目录（把本行改成你的分包根，如 packageExtra）。

输出习惯

• 每轮列出将修改的文件路径；不要一次改动超过 5 个文件，除非我明确要求。
• 需要查 API 时给出微信开放文档链接，不要凭记忆捏造参数名。

D-6 Skill 骨架（存成 SKILL.md 或项目内 docs/skill-发版前自检.md 均可）

Skill：发版前冒烟（微信小程序）

编译

• 开发者工具「编译」无红字、无未注册页面告警

路由

• 从冷启动到主路径点穿 1 遍；Tab 每项可进入可返回
• 若有分包：主包按钮 navigateTo 到分包页路径以 /分包根/ 开头

数据

• 杀进程重开：关键设置仍在（或符合预期的空态）
• 未出现未捕获异常白屏

提审材料（若本版要提交）

• 功能描述与截图主路径一致
• 类目与功能口径一致；隐私勾选与实际采集一致

备注
版本号：（填）　本版不做的功能：（填）

D-7 提审材料自检清单

• 功能描述用「用户操作步骤」写，不出现夸大或医疗承诺词
• 截图 3～5 张覆盖：首屏 → 核心操作 → 设置/关于（若有采集信息则含隐私入口）
• 测试账号/密码：不需要则写清「无需登录」
• 隐私指引：勾选项与代码实际调用的敏感接口一致
• 体验版已给至少 1 人点过主路径

D-8 向 AI 描述异常时的模板

【现象】（例如：真机白屏 / Tab 点不进去）
【机型与基础库】（填）
【开发者工具完整报错】（粘贴红字）
【相关文件路径】（填）
【我期望的行为】（一句话）

请只分析原因并给出最小修改方案；不要改无关文件。

D-9 提示词「短口令」套路箱

【拆步】本轮只改一个目标：（写清）。其它文件一律不要动。
【要证据】请给出微信开放文档链接支撑你的 API 用法；没有链接就写「不确定」。
【防一锅端】先输出变更计划与文件清单，我回复「应用」前不要改文件。
【缩改动面】本次 diff 控制在 N 个文件以内（把 N 改成 3～5）。
【对照真机】给出我应在微信里点的路径：从冷启动到复现共几步。
【反向验收】列出你认为会失败的边界 case，并说明你怎么处理。
【别编字段】只使用我仓库里已出现的 storage key / 页面路径名，不要发明新名词。
【文案合规】涉及健康/金融/功效的句子先标「高风险」，给替代表述。

D-10 Rules 文件拆分示意

实际文件名按你团队习惯即可；核心是一条文件一个主题，方便 Cursor 按规则类型加载。

目录示例： .cursor/rules/

• 00-stack-wechat-native.md — 技术栈与禁止项（always）
• 10-routing-tab-subpackage.md — navigateTo / switchTab / 分包路径
• 20-storage-keys.md — storage key 前缀、迁移、禁止 clearStorage
• 30-ui-copy-compliance.md — 禁用词、免责声明出现位置
• 40-project-config-guard.md — 谁能改 project.config.json / 云开关

D-11 可落地的 6 条 Skills 工序名

• Skill：新建页面四件套 + app.json 注册 + 编译冒烟
• Skill：加 Tab / 自定义 TabBar 选中态同步
• Skill：拆分包 + 主包跳转路径冒烟
• Skill：发版前自检（真机 + 体验版 + 包体积）
• Skill：提审材料交叉检查（截图顺序 vs 功能描述）
• Skill：内容批量入库（data 模块约定 + 校验清单）

D-12 MCP：值不值得接（对照下表）

信号	更适合 MCP	不如不用 MCP
你要在对话里频繁查飞书/Notion/Jira 上的 PRD、缺陷、接口	是	偶尔看一眼，浏览器够了
你要自动拉设计标注、图标资源、组件库 token	是	手动导出一次即可
你首版只有本地小程序 + 文档都在仓库里	否	用 @文件 与 Rule 更轻
你团队没人维护 MCP 配置与安全审计	否	接入成本 > 收益

D-13 请 AI 评估是否接入 MCP（对话模板）

我的仓库是微信小程序原生。请根据我描述的重复劳动（例如每天要查 Notion 里的需求表），判断适不适合用 MCP。

输出格式强制如下：
1）结论：建议 / 不建议，一句话；
2）若建议：列出 1～2 个 MCP 能力类型（只写类型名，不写具体供应商）及接入后对话里会少做哪几步人工；
3）若不建议：给出更轻的替代（Rule / Skill / 脚本 / 浏览器书签）；
4）风险：数据出域、Token、权限，各一行。

不要生成具体 JSON 配置或密钥占位符。

---

结语：你可以直接带走的三句话

1. 开发过程中可复制复用的是：提示词套路、Cursor 的 Rules / Skills、以及按需上的 Cursor MCP（对话载体是 Cursor Agent）——不是某一份业务 JSON，更不是「抄一个科学月子餐」。
2. 微信小程序的正确打开方式是「读官方地图 + 让 AI 当苦力」——地图链接见篇末参考链接汇总；地图上的目的地由你自己定。
3. 健康、饮食、育儿向产品：首屏、关于页与分享文案建议人工通读一遍，并对照微信运营规范核对表述，免责声明位置别省。

---

参考链接汇总（微信与 Cursor 文档入口）

正文各节已穿插内链；下表为微信官方与 Cursor 文档入口，随用随查即可。

主题	链接	你点进去主要查什么
小程序框架总览	微信开放文档 · 框架	目录结构、渲染层/逻辑层、运行环境
全局配置 app.json	小程序全局配置	pages、window、tabBar、subpackages 等字段含义
页面配置	页面配置	单页 navigationBarTitleText、usingComponents
应用生命周期 App	App 参考	onLaunch、globalData 该放什么、不该放什么
页面生命周期 Page	Page 参考	onLoad、onShow、setData 使用注意
路由	路由跳转 API 总览	navigateTo / redirectTo / switchTab / reLaunch 选型
本地存储	数据缓存 wx.setStorage	同步/异步、单 key 大小、清理策略
分包	分包加载	root、pages、主包体积、跳转路径写法
自定义 TabBar	自定义 tabBar	与 tabBar.custom 配套、selected 同步
按需注入	按需注入和用时注入	lazyCodeLoading 与组件声明关系
运营与审核规范	运营规范 / 平台常见拒绝情形	文案、类目、隐私、医疗表述等红线
用户隐私保护	用户隐私保护指引	收集哪些信息、如何声明
开发者工具	工具下载与说明	新建项目、预览、上传、真机调试
公众平台	微信公众平台	注册、类目、版本管理、体验成员
Cursor · Rules	Cursor Docs · Rules	规则文件放哪、何时触发、与 Agent 关系
Cursor · Skills	Cursor · Skills 说明（若打不开见 Help · Skills）	Skill 与 Rule 分工、长流程如何沉淀
Cursor · MCP	Cursor · MCP	何时接 MCP、配置与安全注意
Cursor · Agent	Cursor 文档首页	Agent、索引等总入口

写在最后

这篇教程试图传递的核心，并非某个具体的代码片段或项目，而是一种可迁移的协作心智：把 AI 当作一个需要明确指令、遵守项目纪律的协作者，而不是一个能猜透你所有意图的魔法黑盒。

Rules 是你的宪法，Skills 是你的标准作业程序，提示词 是你的沟通协议。这三者共同构成了你与 AI 在项目中的“共同语言”。而微信小程序的官方文档，则是你们共同遵循的“地图”。

现在，你可以：

1. 打开微信开发者工具，创建一个新项目（或打开你的旧项目）。
2. 将 附录 D-1 的固定头复制到 Cursor Agent 的对话中。
3. 根据你的产品领域，写下你的第一条 Rule（比如：“本项目为工具类小程序，禁止引入任何电商或社交裂变功能”）。
4. 从 第九章“场景一” 开始，用拆步的提示词，跑通你的第一个可编译页面。

Vibe coding 的“ vibe ”（氛围感），始于你写下第一条约束、并看到 AI 乖乖遵守的那一刻。 祝你开发顺利。

---

（全文完）