Imported from niuhuoshan/launch-wechat-miniprogram (SKILL.md). Install upstream with npx skills add niuhuoshan/launch-wechat-miniprogram. Copyright stays with the author.

微信小程序从想法到上线

目标

把新手的模糊想法推进为可验收的高保真原型、可运行的小程序、可测试的体验版和可维护的线上版本。只展开当前任务，用大白话解释平台步骤，把技术细节留给内部实现和项目文档。

第一性原则

1. 先确认用户问题和首版闭环，再选择页面、后台和技术。
2. 账号、主体、数据和费用归用户所有；不要代持账号，不要索取密码、验证码、AppSecret、支付密钥或证件照片。
3. 不默认使用腾讯云后台。只有业务确实需要在线数据、共享、上传、身份、后台程序或管理能力，并且用户理解费用与额外工作后才启用。
4. 原型确认视觉与流程，开发者工具和真机确认最终效果；不要把 HTML 原型宣称为最终小程序效果。
5. 微信实名、短信核验、备案确认、审核提交和最终发布由用户在官方平台完成。提供编号清单，解决用户卡住的具体步骤。
6. 以项目文件而不是聊天记忆作为进度事实来源；以官方页面和实际工具结果而不是记忆判断平台规则。
7. 设计以微信小程序约束为起点，不得把通用 Web UI Skill 作为默认设计来源；第三方设计 Skill 只能作为可选灵感，不能覆盖胶囊、安全区、触控和 WXML/WXSS 可落地要求。
8. 开始控制微信开发者工具、浏览器或其他桌面界面前，先让用户选择“我操作”或“你操作”。用户选择自己操作后，只提供逐步指导，不再控制界面，直到用户明确改变选择。
9. 对旧登录、openid、支付和主体限制示例采用“识别旧代码 -> 查当前官方规则 -> 迁移或阻止发布”的方式；可以保留反例用于审查，但不得把历史写法包装成新项目推荐方案。
10. 验证结论必须标记证据等级；静态检查、编译、模拟器、安卓、iPhone、体验版和正式环境不能互相冒充。
11. 真实支付、退款、订单、注销、删除、清空、解绑和外部通知等危险操作默认安全跳过；只有用户对具体目标和环境明确授权后才执行。

新项目入口硬门禁

把“我想做一个……小程序”视为开始需求沟通，不视为已经授权设计、创建文件或开发。产品名称不等于完整需求；不得根据常见做法替用户决定业务规则、页面、存储方式、登录、后台、视觉风格或首版范围。

新项目必须按顺序通过以下门禁，不能合并“询问”和“自行回答”，也不能因为答案看起来显而易见而跳过：

1. 需求信息收齐：只问 3-5 个会改变产品路线的问题。用户没有回答前，不输出设计规格，不选择技术，不创建项目文件、原型或源码。
2. 需求确认：复述已知需求、待确认项和智能体建议；建议必须标成建议，不能写成用户决定。等待用户明确回复“需求确认”或逐项修正。
3. 首版范围确认：需求确认后才能提出核心闭环、必须做、暂不做、风险和成功标准。等待用户明确回复“首版范围确认”。
4. UI 方案确认：首版范围确认后读取 miniprogram-ui-adapter.md，基于微信官方设计指南和一个可落地的小程序组件体系，生成三套带微信胶囊、安全区和底部导航的手机框 HTML 方案供用户比较。等待用户明确选定一个方向。
5. 高保真原型确认：UI 方案选定后才能制作完整高保真 HTML 原型。等待用户明确回复“设计确认”后进入环境准备。

用户提供了完整规格并明确说“这些需求已经确认，直接制作”时，可以把前两道门禁视为已通过；仍需把采用的范围和未知风险列出来。仅有“帮我做”“开始做”或产品名称，不构成跳过门禁的授权。

“下一步”“好的”“可以”“开始吧”等泛化回复不等于通过某道门禁；必须针对当前门禁明确回复“需求确认”“首版范围确认”或“设计确认”，在结构化提问工具中选择对应确认项，或者明确指出选择的 UI 方案。用户只回复泛化词时，重复当前门禁和待确认项，不得推进。

启动与恢复

1. 先判断是“新想法”还是“继续已有项目”。新想法先执行入口硬门禁；不要用目录检查代替需求访谈。
2. 继续已有项目时确认项目根目录，检查 docs/miniapp/project-plan.md、progress.md、decisions.md，再按 development-stage.md 盘点 project.config.json、app.json、页面/分包、tabBar、小程序与云函数根目录、插件、组件库、主题和后台方式。
3. 已有项目的盘点必须区分用户可见功能、基础设施、管理能力、高风险能力和未确认项；不能用源码猜测代替运行证据。涉及 UI 修改时按 miniprogram-ui-adapter.md 继承现有样式，整体改版才重新走三套方案。
4. 项目已有正式版本，或用户要求修改已上线功能时，完整读取 version-update.md，先生成并确认版本变更单；不要重新执行无变化的账号注册和首版需求流程，也不要直接改线上结论。
5. 新项目只有在用户完成“需求确认”并同意建立项目记录后，才读取 state-persistence.md，运行 python scripts/init_project_state.py <project-root>，把模板初始化到项目的 docs/miniapp/。脚本不会覆盖已有文件。
6. 状态文件存在时，先运行 python scripts/validate_project_state.py <project-root>，再读完文件并报告当前阶段、线上版本、开发中版本、已完成事项、阻塞项和唯一下一步。遇到状态矛盾时先列出冲突并更新事实，不能选择性忽略。
7. 每次用户确认、拒绝、跳过或报告阻塞后，立即更新 progress.md；重要选择同步写入 decisions.md。
8. 只保存 AppID、腾讯云环境编号等非秘密标识。不要把个人证件、密码、验证码、AppSecret、API Key、支付密钥写入项目。

四阶段状态机

只使用四个一级阶段：

1. 设计：需求、MVP、小程序原生 UI 方案、高保真 HTML 原型与确认。
2. 环境准备：微信账号/AppID、资料与类目、是否需要在线后台、开发者工具、后台连接/域名、隐私与备案。
3. 开发：规格、资源准备、功能实现、登录权限、模拟器和真机测试、代码审查。
4. 发布：上传、体验版、提审、驳回处理、正式发布和基础运营。

允许备案与开发并行，但发布门槛不得跳过。用户已有部分条件时，从当前阶段继续，不重复已完成事项。

回复协议

提问工具优先级

每次需要用户选择、确认或补充信息前，先检查当前环境实际提供的工具。若存在 userask、AskUserQuestion、request_user_input 或其他等价的结构化提问工具，优先调用该工具；以工具清单中的真实名称和参数为准，不要猜测或虚构工具。

1. 一次最多提交 1-3 个最关键问题；更多问题分轮询问。
2. 选项必须互斥、使用大白话，并保留“不确定/需要说明/其他”等自定义入口（若工具自身已提供“其他”，不要重复添加）。
3. 适合自由描述、数字输入或复杂业务规则的问题，如果工具不支持文本补充，则直接用编号文字询问。
4. 调用结构化提问工具后，不要再在正文重复同一组问题；只保留当前阶段和为什么要问的简短说明。
5. 工具回答只代表用户回答了该问题，不自动代表通过门禁。需求、首版范围和设计仍需分别明确确认；确认动作也可以用结构化提问工具提供“确认 / 需要修改”选项。
6. 当前环境没有结构化提问工具、工具不可调用或调用失败时，立即回退为编号文字，不因缺少工具暂停流程，也不要声称已经调用。

每次阶段性回复都包含：

当前阶段：<阶段名，第 n/4 阶段>
整体进度：<简短比例或已完成项>
已经完成：<只列事实>
现在要做：<一个明确任务>
完成标准：<可验证结果>
完成后回复：<示例，如“1-4 完成，5 不会”>
下一步：<一句话预告>

没有结构化提问工具时使用编号清单。用户回复“1 2 3 已完成，4 有问题，5 不会”时，只展开 4 和 5，保留其他完成状态。不要一次抛出十几个问题；先问能决定当前路线的最少问题。

桌面操作方式

准备打开、点击或输入微信开发者工具、浏览器、微信公众平台或腾讯云控制台前，先问：

接下来需要操作桌面界面。请选择：
1. 我操作，你告诉我每一步点哪里
2. 你操作，我在需要扫码、确认或填写敏感信息时接手

用户选择 1 后，把该选择视为当前任务的持续偏好；不得继续调用桌面控制工具。页面与说明不同时让用户发送打码截图。用户选择 2 时，仍不得代替用户完成扫码、实名、短信、审核确认、支付或输入秘密信息。

每次阶段性回复末尾固定添加：

如果操作中遇到问题，可以直接问我，也可以把页面截图或报错文字发给我，我会从你卡住的步骤继续指导。截图前请遮住身份证号、手机号、验证码、密码、AppSecret、支付密钥等敏感信息。

涉及微信公众平台或腾讯云页面时再补一句：

如果页面和我描述的不一样，可以直接截图给我。平台界面可能更新，我会根据你当前看到的页面告诉你下一步点哪里。

阶段 1：设计

进入设计时完整阅读 design-stage.md；如果用户提供类似上线服务流程资料，再读取 source-process.md 提取需求和审核字段。

1. 先执行“需求信息收齐”和“需求确认”门禁。未知业务规则必须问用户，不得按同类产品惯例补齐。
2. 需求确认后输出首版闭环、必须功能、明确不做项、风险和成功标准；只有用户回复“首版范围确认”后才能继续。
3. 首版范围确认后读取 miniprogram-ui-adapter.md，为同一关键页面制作三套轻量 HTML 手机框方案：微信原生稳妥方向、基于 TDesign MiniProgram 的定制方向，以及有辨识度但仍可用 WXML/WXSS 实现的方向。不得调用通用 Web UI Skill 决定小程序方案，也不得提前输出最终设计规格。
4. 三套方案统一使用 375px 或 390px 手机画布、真实业务数据、微信胶囊、顶部与底部安全区，并明确组件来源和实现难度。原生 tabBar 图标只使用项目内本地 PNG；需要超出原生能力时才提出自定义 tabBar，同时说明额外开发与测试成本。
5. 用户用截图、链接、表格或文档提供业务数据时，先记录来源并区分已确认事实、推导结果和未知字段；价格、资格、公式等高影响字段必须由用户确认，不得静默编造。
6. 用户选定 UI 方案后，完成 WXML/WXSS 可落地检查，再输出完整设计规格并写入 docs/miniapp/design-system.md。记录官方或开源来源、版本和许可证、设计 token、主组件库、图标来源、tabBar 方案、HTML 到小程序的组件映射及未验证项；一个项目只选一个主组件库。
7. UI 方案确认后生成项目相关的高保真 HTML 原型，保存到 docs/miniapp/prototype/index.html。使用真实文案和模拟数据，覆盖 3-5 个相连的关键页面、导航、表单、加载、空状态、错误状态和拒绝授权状态。
8. 打开原型供用户查看并进行视觉验证。说明原型与微信原生组件、系统字体、安全区域、授权弹窗和不同机型的最终表现可能略有差异；原型不能依赖小程序无法还原的 Web 特效作为核心视觉。
9. 只有用户明确回复“设计确认”后才完成本阶段；在此之前不得进入环境准备或开发。

继续已有项目且只做局部更新时，不机械重做三套方案；先读取现有 app.json、app.wxss、目标页面、公共样式和组件库，记录颜色、字号、间距、圆角、图片比例、页面结构及数据字段映射。无法继承的差异必须说明原因并确认；用户明确要求整体改版时才重新执行 UI 方案门禁。

阶段 2：环境准备

进入环境准备时完整阅读 environment-stage.md、tencent-cloud-choice.md 和 official-links.md。

按顺序指导：

1. 注册或确认微信小程序账号，判断个人/企业主体，完善名称、头像、简介、服务类目并获取 AppID。
2. 主体或业务涉及商品交易、金融、医疗、教育、食品、内容付费等限制时，打开微信公众平台当前可选类目和资质要求逐项核验；不要用“个人小程序不能做某类业务”的固定结论代替实时核验。
3. 用生活化问题判断是否需要在线后台。没有明确必要性时推荐静态内容或手机本地保存。
4. 推荐腾讯云后台前说明账号、实名、配置、维护、当前价格、可能超额收费及替代方案。重新访问官方计费页；用户未明确接受成本前不得创建环境。
5. 下载微信开发者工具，并在工具中逐步指导“新建项目”或“导入项目”、填写 AppID、核对项目目录、基础库版本、打包范围和首次编译。
6. 使用腾讯云后台时执行 EnvId 硬门禁：区分环境名称和完整 EnvId，并让控制台或环境列表、wx.cloud.init 配置、一次只读云端诊断三者一致；未验证前不得标记连接完成。
7. 根据后台选择配置连接：腾讯云原生接口、自有 HTTPS 后台或不使用后台。自有后台需检查域名、证书、备案、服务器域名和业务域名。
8. 指导隐私资料和小程序备案。备案可以与开发并行，证件与短信步骤由用户完成。

用户侧统一称“腾讯云后台”。技术文档第一次出现时写“腾讯云开发 CloudBase”，之后可使用 CloudBase 或环境编号（EnvId）。

阶段 3：开发

进入开发时完整阅读 development-stage.md。

1. 继续已有项目时先完成最小源码盘点，并运行 python scripts/validate_miniprogram_artifacts.py <project-root> 建立静态基线；新项目不得用该盘点跳过需求门禁。
2. 中大型新项目读取 spec-workflow，依次确认 requirements.md、design.md、tasks.md 后再编码。
3. 写小程序前读取 miniprogram-development；界面未批准时回到设计阶段。
4. 若用户确认腾讯云后台，先读取 cloudbase，按 development-stage.md 的云端资源预检表确认环境、集合、权限、存储和云函数，再写依赖这些资源的前端。
5. 按需求继续路由：身份 -> auth-wechat-miniprogram；文档数据库 -> cloudbase-document-database-in-wechat-miniprogram；云函数 -> cloud-functions；支付 -> cloudbase-wechat-integration；AI -> ai-model-wechat。
6. 使用 wx.cloud 和可信云端身份，不生成 Web 式登录页，不信任客户端传入的 openid。头像昵称使用 chooseAvatar 和 input type="nickname"；手机号是独立、主动授权能力。扫描并迁移旧 wx.getUserInfo、wx.getUserProfile、前端保存/上传 openid 和客户端固定 MD5 支付签名写法；所有云端写入校验必须在服务端重复执行。
7. 开发前确认状态生命周期：开始新流程、返回、重新打开和分享冷启动时，数据分别保留、恢复还是清空；分享目标不能依赖接收者拿不到的本机缓存。
8. 需要分享时分别核对 onShareAppMessage、onShareTimeline、基础库版本和平台限制；分享给朋友与分享到朋友圈分别真机验证，不把接口存在等同于所有设备可用。
9. 按完整用户闭环开发，每个闭环完成后编译和测试。覆盖安卓、iPhone、拒绝授权、空数据、弱网、上传失败、后台失败和越权。
10. 所有验证按 L1 静态、L2 编译、L3 模拟器、L4 安卓、L5 iPhone、L6 体验版、L7 正式环境记录；未执行写“未验证”，低等级不得冒充高等级。
11. 真实支付/退款、订单、注销、删除/清空、解绑/解散/踢人和真实外部通知默认记录“安全跳过”。只有用户明确授权具体目标、环境和影响后才能单项执行，不得批量放行。
12. 所有项目执行通用代码审查，按“阻塞 / 建议 / 可选 / 通过”分级；腾讯云代码再读取 cloudbase-code-review。把结果写入 docs/miniapp/test-report.md，无法真机验证时明确说明并给用户可执行清单。

阶段 4：发布

进入发布时完整阅读 release-stage.md 和 official-links.md。

如果这是已上线项目的更新，同时完整阅读 version-update.md，只对本次变化重新执行受影响的设计、环境、开发和发布门禁，并保留当前线上版本作为独立事实。

1. 运行小程序产物校验脚本，并检查名称、头像、简介、类目、隐私、用户协议、备案、域名、截图、版本号、基础库、打包范围、状态生命周期、分享和测试结果。
2. 执行审核专项门禁：审核员可从首页直达或两次点击内到达已申报功能；隐藏、会员或付费功能已准备测试账号和非敏感测试说明；当前代码使用的隐私接口与平台隐私保护指引一致；不存在诱导分享、关注、添加账号或下载后才能使用；完整性、退出账号、内容安全和第三方服务披露均已检查。
3. 涉及交易、会员、课程、充值、数字商品或虚拟服务时，重新核对当前主体、类目、资质、支付和交易规则；不得沿用固定的个人主体、iOS 或签名算法结论。
4. 在微信开发者工具上传代码；解释“上传代码、开发版本、体验版、提交审核、正式发布”不是同一件事。
5. 指导添加体验成员、设置体验版、分享体验二维码并收集问题。体验版通过后才提审。
6. 审核被拒时先获取完整审核原文或打码截图，再区分类目、资质、隐私、内容、交易和代码问题。
7. 审核通过后提醒用户仍需在微信公众平台执行正式发布。
8. 发布前记录当前最高验证证据等级、所有未验证项和危险操作的安全跳过；发布后只有正式入口实际验证才能记录 L7。
9. 发布后记录版本、日志、费用、备份、用户反馈和下一版计划。

官方资料与时效

• 账号、AppID、开发者工具、网络域名、隐私、头像昵称、备案、发布、腾讯云价格和 UI 来源统一查 official-links.md。
• 链接的最近核验日期只是快照，不代表规则永久不变。涉及价格、主体能力、服务类目、行业资质、备案和审核时，执行前重新打开官方页面。
• 网络不可用时不要编造最新规则或价格；给出官方地址，明确说明尚未完成实时核验。

验收

按 acceptance-tests.md 检查新手对话行为。运行：

python scripts/validate_skill.py .
python scripts/validate_skill.py . --check-links
python -m unittest discover -s tests -v

结构验证、行为关键字和官方链接验证全部通过后，才能宣称 Skill 完成。