我最近做了一件事让 AI 用一个 Skill从一句含糊的想法开始最终交付一个可以点开、能跳转、能展示 mock 数据的微信小程序。这里的 Skill 不是游戏里的技能而是现在越来越多 AI 编程工具支持的一种工作单元把角色、步骤、规则、示例和检查项打包在一起让模型不再只是回答一个具体问题而是按一套固定流程执行。做完这个 Skill 之后我的强烈感受是AI 写代码的能力早就不再是主要瓶颈。真正让人卡住的是从需求到首次运行之间隔着一条很长的隐性流程。很多人试过让 AI 写小程序得到的反馈往往是这样代码看起来完整目录结构也像模像样但放进微信开发者工具里一编译立刻报错。要么是 app.json 里页面路径没写好要么是页面文件缺了 json 配置要么是接口域名不合法甚至只是项目目录不对导致整个项目无法识别。这不是 AI 不够聪明而是我们默认“能写代码”就等同于“能交付一个能运行的项目”。在真实开发里从代码到运行中间还夹着环境准备、配置校验、页面路径注册、接口 mock、编译调试、真机预览等一堆琐碎工作。这些工作占用的时间往往比写代码还多。我做的这个 Skill核心思路不是让 AI 写出更多代码而是把“从需求到首次运行”的完整流程固化下来让 AI 在每个环节只做当前该做的事并且每一次输出都有明确的验收标准。这篇文章不准备贴一个可直接下载的 Skill 文件因为它是为特定工作流服务的。我更想拆解其中的设计思路、拆分原则、边界判断和落地路径这样即使你用的是不同工具也可以自己做一套适用于微信小程序的开发流程。1. 先搞清楚一个“Skill”到底解决了什么1.1 单点 AI 写代码解决不了“首次运行”问题过去一年里AI 编程能力的进步速度是有目共睹的。无论是大模型直接生成代码还是 Claude Code、Codex、Cursor 这类工具里的 Agent 模式都能在很短时间里给出一个功能模块。但“写出一段代码”和“交付一个能运行的小程序”是两件事。一段单点提示词通常只负责一件事比如“生成一个微信小程序登录页面”。模型会基于训练时的经验拼出一个结构看起来正确的页面。它不会主动告诉你这个页面是否已经注册到 app.json 里不会检查project.config.json里的 appid 是否合法也不会帮你确认基础库版本是否支持你用的 API。等你把代码搬到微信开发者工具里错误开始出现时你才意识到真正的麻烦才刚刚开始。首次运行失败的原因大概率不是某个页面的业务逻辑写错了而是更底层的东西。可能是某个目录缺了文件可能是页面 json 里写了一个不存在的组件可能是 tabBar 页面配置错误也可能是权限、接口、域名、基础库版本等环境因素。这些因素单点提示词根本不会去关心。1.2 从需求到首次运行卡住的不是代码而是流程我梳理了一下一个微信小程序从“我有一个想法”到“在开发者工具里跑起来”至少要经历这些环节需求澄清这个小程序解决什么问题核心页面有几张用户主要操作是什么。功能拆分先做哪些功能后做哪些功能哪些可以用 mock 数据代替。项目初始化本地目录结构、app.json、project.config.json、sitemap 等基础文件。页面开发首页、列表页、详情页、个人中心等每个页面包含 wxml、wxss、js、json。交互逻辑页面跳转、事件绑定、数据渲染、状态管理。接口联调使用本地 mock、真实接口还是云开发数据字段怎么约定。编译调试处理各种编译报错、运行时错误、样式异常。真机预览确认在手机上能正常打开权限、网络、底部导航都正常。这是一个完整的闭环。任何一个环节出了问题都会让前面的工作看起来像白做了。普通开发者在 AI 辅助下通常把注意力放在第 4 步“页面开发”上但真正决定一个项目能不能跑起来的其实是后面几步。尤其是“编译调试”和“接口联调”几乎占了首次运行一半的时间。1.3 Skill 和普通提示词本质上是工作方式不同普通提示词像是临时找一位顾问“我有个问题你回答一下”。而 Skill 更像是给一个实习生发了一本操作手册里面不仅规定了“做什么”还规定了“按什么顺序做”“每一步做到什么程度算完成”“出现错误该怎么办”。具体到一个微信小程序开发场景普通提示词可能是请帮我开发一个微信小程序包含首页、列表页和详情页。这样的提示词得到的回答通常是一大段代码没有安装步骤没有验收标准也没有错误处理方案。你只能继续追问“报错了怎么办”“这个文件放哪里”。而一个 Skill 会这样组织工作步骤 1明确需求输出功能清单和页面清单等待用户确认。 步骤 2初始化项目骨架只生成必要文件。 步骤 3生成首页确保 app.json 注册并在开发者工具中可见。 步骤 4加入 mock 数据联调页面渲染。 步骤 5编译检查输出已知问题清单和处理建议。这种设计的价值在于AI 的每一步输出都对应一个可验证的结果用户可以及时纠偏而不是等所有代码一次性生成后再去大海捞针地排查问题。所以我认为Skill 的核心价值不是让 AI 更聪明而是让协作流程更可控。2. 从需求到首次运行我把流程拆成了五个阶段2.1 阶段一需求冻结不急着写代码第一次设计 Skill 时我犯过一个错误一开始就要求 AI 生成页面。结果页面不少但很多功能与最初想法不符改起来非常痛苦。后来我改成“先需求后代码”让 Skill 第一步必须输出一份需求清单。这个阶段AI 要完成的任务包括把用户的原始想法拆成功能点。合并重复功能删除无法实现或明显不合理的功能。输出页面清单每个页面说明用途和核心交互。明确数据字段比如列表页需要哪些字段详情页需要展示哪些信息。判断哪些功能是首次版本必须有的哪些可以后续再加。如果需求描述不清楚AI 应该继续提问而不是直接开始写代码。比如“这个登录是微信一键登录还是手机号登录”“列表数据来源是后端接口还是本地 mock”这些信息会直接影响项目结构。我第一次实际测试这个流程时输入的是“想做一个宠物领养小程序”。AI 输出的需求清单包含首页、列表页、详情页、申请表单页、个人中心还自动假设了“用户需要登录才能申请领养”。这个假设其实很重要。如果用户想的是不用登录也能浏览那登录逻辑就可以延后。所以 Skill 里必须有一条规则关键假设必须让用户确认不能默默替用户做决定。2.2 阶段二最小项目骨架而不是完整项目很多 AI 生成代码的问题在于一上来就生成一个“看起来很完整”的大项目。目录里塞了几十个文件实际能运行的没几个。我自己更推荐先生成最小骨架只包含微信小程序原生必备的文件。一个标准的最小骨架通常是这样my-miniapp/ ├─ app.json ├─ app.js ├─ app.wxss ├─ project.config.json ├─ sitemap.json ├─ pages/ │ ├─ index/ │ │ ├─ index.wxml │ │ ├─ index.wxss │ │ ├─ index.js │ │ └─ index.json └─ utils/ └─ mock.js在这个阶段只需要让首页显示一行文字能够被编译出来就说明项目基础是通的。这个阶段不需要复杂页面也不需要接口。先验证“项目路径是否正确”“app.json 是否被正确读取”“页面注册是否成功”这些问题是后续所有开发的地基。很多新手看到 AI 生成的代码里有几十个文件觉得很放心实际上反而是负担。因为一旦编译出错很难判断是哪个文件的问题。最小骨架的好处是问题能快速定位如果首页能显示但第二个页面报错那问题肯定出在第二个页面的注册或文件结构上。2.3 阶段三单页面跑通再扩展页面项目骨架稳定后我习惯让 Skill 先集中精力把一个页面做到“可运行”。怎么做呢先确定页面功能比如宠物列表页。定义 mock 数据模拟后端返回的字段。生成 wxml 结构展示列表项。生成 wxss 样式简单布局。在 page.json 里配置标题栏。在 app.json 里注册页面路径。这个页面完成之后先在微信开发者工具里编译确认没有红色报错再进入下一个页面。如果一次性生成 5 个页面一旦某个页面的 json 配置写错开发者工具会在启动阶段直接报错导致所有页面都无法预览。这种问题非常隐蔽因为代码逻辑可能完全没问题只是某个配置项多了一个逗号。所以我给 Skill 设了一条硬性规则每次最多生成一个页面生成后必须停在“等待用户确认编译结果”这一步。没有用户确认禁止继续生成下一个页面。2.4 阶段四接口 mock 优先联调后置小程序开发过程中最容易让人崩溃的就是接口问题。真实后端还没准备好或者接口域名没有加到白名单再或者开发环境不是 https这些都可能让请求失败。这时候 AI 生成的代码本身没有问题但页面拿不到数据看起来就像“程序跑不起来”。我用的方法是在 Skill 里默认使用 mock 数据。所有请求先不通过wx.request去拿而是从一个utils/mock.js里取。等页面渲染和交互都正常再逐步替换成真实接口。这样做有几个明显好处控制了变量页面展示和接口调用是两套独立的问题不会互相干扰。减少环境依赖开发阶段不依赖后端是否启动不依赖域名备案。方便演示即使是纯前端静态页面也能展示完整交互流程。2.5 阶段五编译错误自动回传迭代修正即便做完了以上所有步骤首次运行仍然可能失败。这是正常现象尤其在一个 AI 辅助流程里。关键不是避免报错而是快速修正报错。我设计的 Skill 里包含一个“错误处理循环”用户把开发者工具里的报错信息复制给 AIAI 根据报错内容结合当前项目上下文给出修改方案。修改完成后用户重新编译如果还有报错继续回传直到编译通过。这里最重要的不是让 AI 直接猜错在哪里而是先统一上下文。Skill 会要求用户提供三样东西报错截图或原文、当前正在操作的文件路径、项目目录结构。很多模型无法定位问题不是因为模型能力不足而是因为用户给的信息太少甚至只发了一句“报错了帮我看看”。在一个 Skill 里这个问题可以通过固定的“报错反馈格式”来解决。例如我建议用户按这个格式反馈报错信息... 开发者工具版本... 当前操作文件pages/index/index.js 最近改动新增了 onLoad 请求 mock 数据这样一来AI 能迅速判断是代码逻辑问题、文件路径问题还是环境配置问题。3. 设计 Skill 时最难的不是功能而是边界3.1 输入边界让 AI 知道自己不知道什么一个 Skill 再完善也不可能预先知道用户的所有项目背景。所以必须明确规则当信息缺失时AI 可以提问但不能擅自假设。在微信小程序开发场景里有几个信息是特别容易缺失的AppID使用测试号还是正式 AppID如果没提供应该用测试号并提示用户去微信公众平台申请。是否需要云开发如果不需要就不要在代码里引入云开发 API。后端接口地址如果没提供默认使用 mock 数据。页面数量如果信息不明确先做 2 到 3 个核心页面不要铺开做 10 个页面。这些输入边界决定了 AI 是在一个真实约束下工作还是在无根据地对未来做猜测。对用户来说AI 明确说“我不知道这个信息需要你提供”比“我帮你默认一个方案”更值得信任。3.2 工具边界哪些事 AI 能做哪些不该做虽然 AI 可以生成完整代码但有些工作不应该让它做至少不应该让它自动做。比如不适合自动做直接使用用户的正式 AppID 进行上传发布。不适合自动做替用户决定产品逻辑比如“是否需要登录”“是否要付费”。不适合自动做在用户没有确认前生成大量页面或批量修改文件。适合自动做分析报错、解释代码、生成页面、修复常见配置问题。这个边界不是能力限制而是责任划分。AI 可以是一个高效的执行者但产品方向和发布行为必须由人来确认。我在 Skill 的规则里明确写了一条在任何情况下AI 不得假设自己有权限调用真实生产环境接口也不得在未经确认的情况下执行上传操作。3.3 环境边界版本、路径和外部依赖微信小程序的运行环境比普通网页开发更受限。基础库版本、开发者工具版本、本地 Node 环境、npm 构建流程都会影响结果。在 Skill 里我建议把环境假设写清楚例如开发者工具版本建议使用稳定版不追求最新。基础库版本不宜设置过低或过高推荐使用默认兼容版本。是否使用 npm 包如果项目只用内置 API不需要 npm 构建。是否用了插件原生开发优先避免引入第三方组件带来的不确定性。如果用户的环境和 Skill 假设不一致应该先解决环境差异再继续生成代码。否则AI 生成的代码可能在作者环境能运行在用户环境里却是一堆语法错误。这个问题在真实协作中非常常见。3.4 容错边界第一次就成功的概率很低关键是恢复速度我把“完美一次通过”这件事从预期里删掉了。微信小程序首次运行即使是很小的原型也会遇到各种问题。所以 Skill 设计里最重要的容错机制不是避免所有问题而是让问题出现后能快速定位。可以按这个顺序排查先看现象编译报错、白屏、请求失败、跳转无效还是样式错乱。再看页面路径是否在 app.json 里注册文件名是否一致。再看配置文件project.config.json、app.json、page.json 的语法和字段。再看接口和环境网络请求是否用了合法域名开发阶段是否开启了“不校验合法域名”。最后看代码逻辑js 里有没有运行时错误数据格式是否匹配模板渲染。这个顺序不是拍脑袋定的而是按“影响范围从大到小”排列的。页面路径或配置文件出错会导致整个小程序启动失败影响范围最大所以优先排查。代码逻辑出错通常只影响单个页面可以放到后面。4. 如果你想做一个类似的 Skill可以参考这个落地路径4.1 先手工跑通一次再写 Skill最稳妥的方法是先不用任何 Skill自己手工完成一个微信小程序从需求到首次运行的完整流程。把每一步写下来包括你遇到的问题、解决方式、常用命令、文件路径、配置项。这个过程会让你真正理解哪些环节是需要固定下来的。我做完第一次手工流程后记录下来的卡点包括不知道要注册页面路径、忘记配置 project.config.json、没有 mock 数据导致页面空白、AppID 填错导致真机预览失败。后来这些卡点都成了 Skill 里检查项的一部分。如果你在做第一次手工流程时没有遇到任何问题要么是你已经有丰富经验要么是你还没有深入到真实运行的复杂性里。4.2 Skill 内容怎么组织描述、步骤、输出格式、检查点一个可维护的 Skill不是把一堆提示词塞进一个文件而是按照固定结构组织。我建议至少包含这些内容my-wechat-miniapp-skill/ ├─ SKILL.md ├─ steps/ │ ├─ 01-需求确认.md │ ├─ 02-初始化项目.md │ ├─ 03-生成页面.md │ ├─ 04-编译调试.md │ └─ 05-验收.md ├─ templates/ │ └─ 页面模板/ └─ checkpoints.md在SKILL.md里写清楚角色和总流程在steps目录里拆解每一步的输入、输出、执行规则和终止条件在checkpoints.md里放一份验收清单。一个重要的设计原则是每一步都要有“成功的标准”。比如“初始化项目”步骤的成功标准是“首页能在开发者工具中编译显示没有红色报错”而不是“代码生成完毕”。有了明确标准AI 就不会把一个半成品交给你。4.3 一个可复用的验收清单每次一个页面或一个功能完成后可以让 AI 对照这个表格逐项自检也可以人工确认验收项检查内容状态页面注册所有页面路径都已在 app.json 中注册必检文件完整性每个页面都包含 wxml、wxss、js、json 四个文件必检编译无报错微信开发者工具控制台没有红色错误必检数据渲染正常页面能显示 mock 数据不出现空白区域建议跳转正常列表项能跳转到详情页返回正常建议网络请求如已接入接口确认域名合法或已开启调试模式按需真机预览使用预览功能能在手机上打开并操作按需样式适配页面在常见手机尺寸下没有明显错位建议代码可读性目录结构清晰常用配置写在统一位置建议未使用敏感配置没有埋入任何真实的密钥或生产环境地址必检这个清单越具体AI 就越不容易“看起来做了实际没做完”。4.4 适合什么不适合什么一个 Skill 做得再好也不是万能的。它的使用边界和适用场景值得单独说清楚。适合使用这种“AI Skill 微信小程序”工作流的情况包括学习小程序开发想快速看到一个可运行的项目结构。验证产品想法做原型或 Demo先给同事或朋友体验。生成内部工具比如团队管理、数据展示、简单流程审批。快速从一张设计稿或一段描述生成前端页面。不适合的情况包括生产级小程序涉及支付、用户钱包、大额交易或敏感个人信息。复杂权限系统需要深度的角色控制、审计日志、数据安全策略。高并发或强一致性业务比如秒杀、实时库存、多人协作。与大量已有后端服务深度集成需要精细的接口契约和异常处理。为什么不适合因为 AI 生成代码的底层逻辑仍然是基于训练语料和通用模式它很难理解你所在公司内部系统的特殊约束。它可以把流程跑通但无法替代产品经理、后端工程师、测试工程师在边界场景下的判断。所以我更愿意把这个 Skill 定位成“从 0 到 1 的加速器”而不是“从 0 到生产环境的替代品”。回到一开始的判断这个 Skill 真正解决的不是“让 AI 写代码”而是“让从需求到首次运行的整个流程变得可维护、可重复、可交接”。它把一个容易失控的过程变成了一系列有明确输入、输出和检查点的步骤。如果你也想做类似的尝试我建议从最小的场景开始先手工跑通一遍把卡点记下来再把这些卡点写成规则最后形成一个属于你自己的 Skill。你的第一个目标不需要是“一次跑通一个完整小程序”。可以先定一个小目标让 AI 生成一个只有首页的最小项目并且你能在微信开发者工具里看到它编译成功。这件事一旦完成整个后续流程的技术底座就稳了。剩下的只是在这个底座上一页一页地加上去。
用AI Skill解决微信小程序从需求到首次运行的完整流程
我最近做了一件事让 AI 用一个 Skill从一句含糊的想法开始最终交付一个可以点开、能跳转、能展示 mock 数据的微信小程序。这里的 Skill 不是游戏里的技能而是现在越来越多 AI 编程工具支持的一种工作单元把角色、步骤、规则、示例和检查项打包在一起让模型不再只是回答一个具体问题而是按一套固定流程执行。做完这个 Skill 之后我的强烈感受是AI 写代码的能力早就不再是主要瓶颈。真正让人卡住的是从需求到首次运行之间隔着一条很长的隐性流程。很多人试过让 AI 写小程序得到的反馈往往是这样代码看起来完整目录结构也像模像样但放进微信开发者工具里一编译立刻报错。要么是 app.json 里页面路径没写好要么是页面文件缺了 json 配置要么是接口域名不合法甚至只是项目目录不对导致整个项目无法识别。这不是 AI 不够聪明而是我们默认“能写代码”就等同于“能交付一个能运行的项目”。在真实开发里从代码到运行中间还夹着环境准备、配置校验、页面路径注册、接口 mock、编译调试、真机预览等一堆琐碎工作。这些工作占用的时间往往比写代码还多。我做的这个 Skill核心思路不是让 AI 写出更多代码而是把“从需求到首次运行”的完整流程固化下来让 AI 在每个环节只做当前该做的事并且每一次输出都有明确的验收标准。这篇文章不准备贴一个可直接下载的 Skill 文件因为它是为特定工作流服务的。我更想拆解其中的设计思路、拆分原则、边界判断和落地路径这样即使你用的是不同工具也可以自己做一套适用于微信小程序的开发流程。1. 先搞清楚一个“Skill”到底解决了什么1.1 单点 AI 写代码解决不了“首次运行”问题过去一年里AI 编程能力的进步速度是有目共睹的。无论是大模型直接生成代码还是 Claude Code、Codex、Cursor 这类工具里的 Agent 模式都能在很短时间里给出一个功能模块。但“写出一段代码”和“交付一个能运行的小程序”是两件事。一段单点提示词通常只负责一件事比如“生成一个微信小程序登录页面”。模型会基于训练时的经验拼出一个结构看起来正确的页面。它不会主动告诉你这个页面是否已经注册到 app.json 里不会检查project.config.json里的 appid 是否合法也不会帮你确认基础库版本是否支持你用的 API。等你把代码搬到微信开发者工具里错误开始出现时你才意识到真正的麻烦才刚刚开始。首次运行失败的原因大概率不是某个页面的业务逻辑写错了而是更底层的东西。可能是某个目录缺了文件可能是页面 json 里写了一个不存在的组件可能是 tabBar 页面配置错误也可能是权限、接口、域名、基础库版本等环境因素。这些因素单点提示词根本不会去关心。1.2 从需求到首次运行卡住的不是代码而是流程我梳理了一下一个微信小程序从“我有一个想法”到“在开发者工具里跑起来”至少要经历这些环节需求澄清这个小程序解决什么问题核心页面有几张用户主要操作是什么。功能拆分先做哪些功能后做哪些功能哪些可以用 mock 数据代替。项目初始化本地目录结构、app.json、project.config.json、sitemap 等基础文件。页面开发首页、列表页、详情页、个人中心等每个页面包含 wxml、wxss、js、json。交互逻辑页面跳转、事件绑定、数据渲染、状态管理。接口联调使用本地 mock、真实接口还是云开发数据字段怎么约定。编译调试处理各种编译报错、运行时错误、样式异常。真机预览确认在手机上能正常打开权限、网络、底部导航都正常。这是一个完整的闭环。任何一个环节出了问题都会让前面的工作看起来像白做了。普通开发者在 AI 辅助下通常把注意力放在第 4 步“页面开发”上但真正决定一个项目能不能跑起来的其实是后面几步。尤其是“编译调试”和“接口联调”几乎占了首次运行一半的时间。1.3 Skill 和普通提示词本质上是工作方式不同普通提示词像是临时找一位顾问“我有个问题你回答一下”。而 Skill 更像是给一个实习生发了一本操作手册里面不仅规定了“做什么”还规定了“按什么顺序做”“每一步做到什么程度算完成”“出现错误该怎么办”。具体到一个微信小程序开发场景普通提示词可能是请帮我开发一个微信小程序包含首页、列表页和详情页。这样的提示词得到的回答通常是一大段代码没有安装步骤没有验收标准也没有错误处理方案。你只能继续追问“报错了怎么办”“这个文件放哪里”。而一个 Skill 会这样组织工作步骤 1明确需求输出功能清单和页面清单等待用户确认。 步骤 2初始化项目骨架只生成必要文件。 步骤 3生成首页确保 app.json 注册并在开发者工具中可见。 步骤 4加入 mock 数据联调页面渲染。 步骤 5编译检查输出已知问题清单和处理建议。这种设计的价值在于AI 的每一步输出都对应一个可验证的结果用户可以及时纠偏而不是等所有代码一次性生成后再去大海捞针地排查问题。所以我认为Skill 的核心价值不是让 AI 更聪明而是让协作流程更可控。2. 从需求到首次运行我把流程拆成了五个阶段2.1 阶段一需求冻结不急着写代码第一次设计 Skill 时我犯过一个错误一开始就要求 AI 生成页面。结果页面不少但很多功能与最初想法不符改起来非常痛苦。后来我改成“先需求后代码”让 Skill 第一步必须输出一份需求清单。这个阶段AI 要完成的任务包括把用户的原始想法拆成功能点。合并重复功能删除无法实现或明显不合理的功能。输出页面清单每个页面说明用途和核心交互。明确数据字段比如列表页需要哪些字段详情页需要展示哪些信息。判断哪些功能是首次版本必须有的哪些可以后续再加。如果需求描述不清楚AI 应该继续提问而不是直接开始写代码。比如“这个登录是微信一键登录还是手机号登录”“列表数据来源是后端接口还是本地 mock”这些信息会直接影响项目结构。我第一次实际测试这个流程时输入的是“想做一个宠物领养小程序”。AI 输出的需求清单包含首页、列表页、详情页、申请表单页、个人中心还自动假设了“用户需要登录才能申请领养”。这个假设其实很重要。如果用户想的是不用登录也能浏览那登录逻辑就可以延后。所以 Skill 里必须有一条规则关键假设必须让用户确认不能默默替用户做决定。2.2 阶段二最小项目骨架而不是完整项目很多 AI 生成代码的问题在于一上来就生成一个“看起来很完整”的大项目。目录里塞了几十个文件实际能运行的没几个。我自己更推荐先生成最小骨架只包含微信小程序原生必备的文件。一个标准的最小骨架通常是这样my-miniapp/ ├─ app.json ├─ app.js ├─ app.wxss ├─ project.config.json ├─ sitemap.json ├─ pages/ │ ├─ index/ │ │ ├─ index.wxml │ │ ├─ index.wxss │ │ ├─ index.js │ │ └─ index.json └─ utils/ └─ mock.js在这个阶段只需要让首页显示一行文字能够被编译出来就说明项目基础是通的。这个阶段不需要复杂页面也不需要接口。先验证“项目路径是否正确”“app.json 是否被正确读取”“页面注册是否成功”这些问题是后续所有开发的地基。很多新手看到 AI 生成的代码里有几十个文件觉得很放心实际上反而是负担。因为一旦编译出错很难判断是哪个文件的问题。最小骨架的好处是问题能快速定位如果首页能显示但第二个页面报错那问题肯定出在第二个页面的注册或文件结构上。2.3 阶段三单页面跑通再扩展页面项目骨架稳定后我习惯让 Skill 先集中精力把一个页面做到“可运行”。怎么做呢先确定页面功能比如宠物列表页。定义 mock 数据模拟后端返回的字段。生成 wxml 结构展示列表项。生成 wxss 样式简单布局。在 page.json 里配置标题栏。在 app.json 里注册页面路径。这个页面完成之后先在微信开发者工具里编译确认没有红色报错再进入下一个页面。如果一次性生成 5 个页面一旦某个页面的 json 配置写错开发者工具会在启动阶段直接报错导致所有页面都无法预览。这种问题非常隐蔽因为代码逻辑可能完全没问题只是某个配置项多了一个逗号。所以我给 Skill 设了一条硬性规则每次最多生成一个页面生成后必须停在“等待用户确认编译结果”这一步。没有用户确认禁止继续生成下一个页面。2.4 阶段四接口 mock 优先联调后置小程序开发过程中最容易让人崩溃的就是接口问题。真实后端还没准备好或者接口域名没有加到白名单再或者开发环境不是 https这些都可能让请求失败。这时候 AI 生成的代码本身没有问题但页面拿不到数据看起来就像“程序跑不起来”。我用的方法是在 Skill 里默认使用 mock 数据。所有请求先不通过wx.request去拿而是从一个utils/mock.js里取。等页面渲染和交互都正常再逐步替换成真实接口。这样做有几个明显好处控制了变量页面展示和接口调用是两套独立的问题不会互相干扰。减少环境依赖开发阶段不依赖后端是否启动不依赖域名备案。方便演示即使是纯前端静态页面也能展示完整交互流程。2.5 阶段五编译错误自动回传迭代修正即便做完了以上所有步骤首次运行仍然可能失败。这是正常现象尤其在一个 AI 辅助流程里。关键不是避免报错而是快速修正报错。我设计的 Skill 里包含一个“错误处理循环”用户把开发者工具里的报错信息复制给 AIAI 根据报错内容结合当前项目上下文给出修改方案。修改完成后用户重新编译如果还有报错继续回传直到编译通过。这里最重要的不是让 AI 直接猜错在哪里而是先统一上下文。Skill 会要求用户提供三样东西报错截图或原文、当前正在操作的文件路径、项目目录结构。很多模型无法定位问题不是因为模型能力不足而是因为用户给的信息太少甚至只发了一句“报错了帮我看看”。在一个 Skill 里这个问题可以通过固定的“报错反馈格式”来解决。例如我建议用户按这个格式反馈报错信息... 开发者工具版本... 当前操作文件pages/index/index.js 最近改动新增了 onLoad 请求 mock 数据这样一来AI 能迅速判断是代码逻辑问题、文件路径问题还是环境配置问题。3. 设计 Skill 时最难的不是功能而是边界3.1 输入边界让 AI 知道自己不知道什么一个 Skill 再完善也不可能预先知道用户的所有项目背景。所以必须明确规则当信息缺失时AI 可以提问但不能擅自假设。在微信小程序开发场景里有几个信息是特别容易缺失的AppID使用测试号还是正式 AppID如果没提供应该用测试号并提示用户去微信公众平台申请。是否需要云开发如果不需要就不要在代码里引入云开发 API。后端接口地址如果没提供默认使用 mock 数据。页面数量如果信息不明确先做 2 到 3 个核心页面不要铺开做 10 个页面。这些输入边界决定了 AI 是在一个真实约束下工作还是在无根据地对未来做猜测。对用户来说AI 明确说“我不知道这个信息需要你提供”比“我帮你默认一个方案”更值得信任。3.2 工具边界哪些事 AI 能做哪些不该做虽然 AI 可以生成完整代码但有些工作不应该让它做至少不应该让它自动做。比如不适合自动做直接使用用户的正式 AppID 进行上传发布。不适合自动做替用户决定产品逻辑比如“是否需要登录”“是否要付费”。不适合自动做在用户没有确认前生成大量页面或批量修改文件。适合自动做分析报错、解释代码、生成页面、修复常见配置问题。这个边界不是能力限制而是责任划分。AI 可以是一个高效的执行者但产品方向和发布行为必须由人来确认。我在 Skill 的规则里明确写了一条在任何情况下AI 不得假设自己有权限调用真实生产环境接口也不得在未经确认的情况下执行上传操作。3.3 环境边界版本、路径和外部依赖微信小程序的运行环境比普通网页开发更受限。基础库版本、开发者工具版本、本地 Node 环境、npm 构建流程都会影响结果。在 Skill 里我建议把环境假设写清楚例如开发者工具版本建议使用稳定版不追求最新。基础库版本不宜设置过低或过高推荐使用默认兼容版本。是否使用 npm 包如果项目只用内置 API不需要 npm 构建。是否用了插件原生开发优先避免引入第三方组件带来的不确定性。如果用户的环境和 Skill 假设不一致应该先解决环境差异再继续生成代码。否则AI 生成的代码可能在作者环境能运行在用户环境里却是一堆语法错误。这个问题在真实协作中非常常见。3.4 容错边界第一次就成功的概率很低关键是恢复速度我把“完美一次通过”这件事从预期里删掉了。微信小程序首次运行即使是很小的原型也会遇到各种问题。所以 Skill 设计里最重要的容错机制不是避免所有问题而是让问题出现后能快速定位。可以按这个顺序排查先看现象编译报错、白屏、请求失败、跳转无效还是样式错乱。再看页面路径是否在 app.json 里注册文件名是否一致。再看配置文件project.config.json、app.json、page.json 的语法和字段。再看接口和环境网络请求是否用了合法域名开发阶段是否开启了“不校验合法域名”。最后看代码逻辑js 里有没有运行时错误数据格式是否匹配模板渲染。这个顺序不是拍脑袋定的而是按“影响范围从大到小”排列的。页面路径或配置文件出错会导致整个小程序启动失败影响范围最大所以优先排查。代码逻辑出错通常只影响单个页面可以放到后面。4. 如果你想做一个类似的 Skill可以参考这个落地路径4.1 先手工跑通一次再写 Skill最稳妥的方法是先不用任何 Skill自己手工完成一个微信小程序从需求到首次运行的完整流程。把每一步写下来包括你遇到的问题、解决方式、常用命令、文件路径、配置项。这个过程会让你真正理解哪些环节是需要固定下来的。我做完第一次手工流程后记录下来的卡点包括不知道要注册页面路径、忘记配置 project.config.json、没有 mock 数据导致页面空白、AppID 填错导致真机预览失败。后来这些卡点都成了 Skill 里检查项的一部分。如果你在做第一次手工流程时没有遇到任何问题要么是你已经有丰富经验要么是你还没有深入到真实运行的复杂性里。4.2 Skill 内容怎么组织描述、步骤、输出格式、检查点一个可维护的 Skill不是把一堆提示词塞进一个文件而是按照固定结构组织。我建议至少包含这些内容my-wechat-miniapp-skill/ ├─ SKILL.md ├─ steps/ │ ├─ 01-需求确认.md │ ├─ 02-初始化项目.md │ ├─ 03-生成页面.md │ ├─ 04-编译调试.md │ └─ 05-验收.md ├─ templates/ │ └─ 页面模板/ └─ checkpoints.md在SKILL.md里写清楚角色和总流程在steps目录里拆解每一步的输入、输出、执行规则和终止条件在checkpoints.md里放一份验收清单。一个重要的设计原则是每一步都要有“成功的标准”。比如“初始化项目”步骤的成功标准是“首页能在开发者工具中编译显示没有红色报错”而不是“代码生成完毕”。有了明确标准AI 就不会把一个半成品交给你。4.3 一个可复用的验收清单每次一个页面或一个功能完成后可以让 AI 对照这个表格逐项自检也可以人工确认验收项检查内容状态页面注册所有页面路径都已在 app.json 中注册必检文件完整性每个页面都包含 wxml、wxss、js、json 四个文件必检编译无报错微信开发者工具控制台没有红色错误必检数据渲染正常页面能显示 mock 数据不出现空白区域建议跳转正常列表项能跳转到详情页返回正常建议网络请求如已接入接口确认域名合法或已开启调试模式按需真机预览使用预览功能能在手机上打开并操作按需样式适配页面在常见手机尺寸下没有明显错位建议代码可读性目录结构清晰常用配置写在统一位置建议未使用敏感配置没有埋入任何真实的密钥或生产环境地址必检这个清单越具体AI 就越不容易“看起来做了实际没做完”。4.4 适合什么不适合什么一个 Skill 做得再好也不是万能的。它的使用边界和适用场景值得单独说清楚。适合使用这种“AI Skill 微信小程序”工作流的情况包括学习小程序开发想快速看到一个可运行的项目结构。验证产品想法做原型或 Demo先给同事或朋友体验。生成内部工具比如团队管理、数据展示、简单流程审批。快速从一张设计稿或一段描述生成前端页面。不适合的情况包括生产级小程序涉及支付、用户钱包、大额交易或敏感个人信息。复杂权限系统需要深度的角色控制、审计日志、数据安全策略。高并发或强一致性业务比如秒杀、实时库存、多人协作。与大量已有后端服务深度集成需要精细的接口契约和异常处理。为什么不适合因为 AI 生成代码的底层逻辑仍然是基于训练语料和通用模式它很难理解你所在公司内部系统的特殊约束。它可以把流程跑通但无法替代产品经理、后端工程师、测试工程师在边界场景下的判断。所以我更愿意把这个 Skill 定位成“从 0 到 1 的加速器”而不是“从 0 到生产环境的替代品”。回到一开始的判断这个 Skill 真正解决的不是“让 AI 写代码”而是“让从需求到首次运行的整个流程变得可维护、可重复、可交接”。它把一个容易失控的过程变成了一系列有明确输入、输出和检查点的步骤。如果你也想做类似的尝试我建议从最小的场景开始先手工跑通一遍把卡点记下来再把这些卡点写成规则最后形成一个属于你自己的 Skill。你的第一个目标不需要是“一次跑通一个完整小程序”。可以先定一个小目标让 AI 生成一个只有首页的最小项目并且你能在微信开发者工具里看到它编译成功。这件事一旦完成整个后续流程的技术底座就稳了。剩下的只是在这个底座上一页一页地加上去。