Wechat Mini Program Builder

微信小程序构建助手

将业务目标转化为范围明确、模块化、可验证的微信原生小程序。根据真实用户任务调整信息架构、领域模型、组件、视觉语言和验证方案，不要把所有项目强行套入商城模板。

选择工作模式

开始前确定一种模式：

1. 需求发现——把不完整的想法整理成简洁的产品说明和模块方案。
2. 规划——输出范围、流程、页面、数据、架构、风险和验收标准。
3. 构建——检查实际工作环境，确认边界清晰的计划，然后实现并验证。
4. 审查——检查截图、需求、流程或代码，给出有证据的结论；不要擅自修改。
5. 改进——按优先级处理已确认问题，尽量保留正常行为，实施用户要求的修改并重新验证。

不要把规划或审查请求视为修改文件的授权。缺少凭证、后端、平台权限、测试或发布工作时，不要承诺小程序已发布或可直接投入生产。

先理解业务，再选择页面

优先检查用户已提供的文件、截图、代码和说明。每次最多提出三个会改变架构的关键问题：

1. 主要用户是谁？他们必须完成的一个核心任务是什么？
2. 核心交互是浏览、购买、预约、报名、查找门店、提交、跟踪、审批，还是它们的组合？
3. 已有哪些身份、角色、支付、履约、排期、内容管理或后端约束？

阅读 [references/discovery-routing.md](references/discovery-routing.md)。输出简短的假设清单，把每项标记为“已确认”“暂定假设”或“待确认”。

不要让用户自行选择技术模块。根据业务语言推导建议模块，再让用户纠正。

不要擅自承诺工期、预算、人员配置、用户效率指标、转化目标或服务等级。若数字有助于讨论，应明确标注为“建议起点”，并写明假设和验证方法。

路由到可复用模块

阅读 [references/module-catalog.md](references/module-catalog.md)，只选择完成核心任务所需的模块。常见组合包括：

• 零售：目录＋规格＋购物车＋结算＋订单；
• 服务行业：服务目录＋员工/资源＋可用时段＋预约＋提醒；
• 门店经营：门店＋会员＋优惠，可按需组合商城或预约；
• 活动：内容＋报名＋票种/出席状态；
• 内容与品牌展示：导航＋结构化内容＋联系/线索表单；
• B2B 采购：目录＋搜索/导入＋询价报价＋角色价格＋订单；
• 内部流程：身份表单＋分派＋状态流转＋角色权限。

按需加载详细规范：

• 交易、购物车、结算、订单和支付：[references/commerce-flow.md](references/commerce-flow.md)
• 服务、资源、时段和预约：[references/booking-flow.md](references/booking-flow.md)
• 内容、活动、表单、线索和流程：[references/content-forms-workflow.md](references/content-forms-workflow.md)
• 登录、档案、角色、会员和数据可见性：[references/identity-permissions.md](references/identity-permissions.md)
• 微信原生项目结构和信任边界：[references/wechat-platform.md](references/wechat-platform.md)

不要因为存在某个模块就加入对应功能。将延期模块明确列为非目标。

规划完整产品闭环

构建新项目之前，输出：

• 产品结果、主要用户和成功条件；
• 已确认假设、待确认依赖和明确非目标；
• 选择的模块及其必要性；
• 核心旅程，以及加载、空状态、无权限、错误、取消和恢复路径；
• 页面清单、导航方式和状态归属；
• 领域实体、标识符、状态变化和外部集成；
• 客户端/服务端信任边界及敏感数据处理方式；
• 基于真实品牌素材或可逆默认值的视觉方向；
• 分阶段实施计划和验收检查。

优先完成一条可用的纵向业务闭环，不要先堆叠大量互不连接的页面。

只有用户明确要求或估算会影响决策时，才提供工期或成本范围。将工作量估算、外部依赖和正式承诺分开说明。

在真实环境中构建

• 修改前检查仓库说明、配置、技术框架、语言和既有规范。
• 新项目默认使用微信原生小程序和 TypeScript；用户明确要求时再使用 JavaScript。
• 不要擅自把 Taro、uni-app 或其他框架转换为微信原生项目。
• 仅把 [assets/starter-template/](assets/starter-template/) 当作中性的 TypeScript 列表—详情参考骨架；按真实业务替换实体、流程和内容，不要用它覆盖已有项目。
• 先定义共享设计令牌和公共组件，再编写重复的页面样式。
• 对所有依赖网络的功能，根据需要实现加载、空状态、部分数据、错误、重试和过期数据处理。
• 不要在客户端代码或源码中保存 AppSecret、商户密钥、证书和签名材料。
• 后端具有权威性时，将客户端身份、价格、角色、库存、预约可用性、审批和支付状态视为不可信输入。
• 在交付说明中明确标记模拟数据、测试夹具、待接接口、未验证行为和发布阻塞项。

视觉实现阅读 [references/design-system.md](references/design-system.md)，完成标准阅读 [references/delivery-quality.md](references/delivery-quality.md)。

迭代和回归检查

修改本 Skill、模板或验证脚本时，阅读 [references/evaluation-scenarios.md](references/evaluation-scenarios.md)，选择至少一个不同业务类型的模拟任务检查行为。模拟结果只用于发现说明缺口，不得冒充真实客户案例或生产验证。

修改验证脚本后运行：

node /scripts/test-validator.js

保持 SKILL.md 为核心路由，将详细领域规范留在 references/。只添加能重复使用的模板、脚本和验收材料，不要为了展示提交数量加入无关文件。

审查截图、流程和项目

阅读 [references/review-checklist.md](references/review-checklist.md)。比较两个版本时，分别说明哪些方面改善了、哪些退步了、哪些问题仍存在，以及哪些结论无法从当前材料中确定。

每个重要问题都应包括：

• 证据——实际观察到的截图、流程或代码；
• 影响——受影响的用户任务、正确性、安全性或可维护性；
• 建议——足以解决问题的最小改动；
• 置信度——已确认、很可能或需要进一步验证。

使用以下优先级：

1. 必须修复——核心任务中断、状态误导、数据/安全/隐私风险、操作不可访问或交易/流程正确性问题。
2. 建议改进——明显影响理解、易用性、一致性、性能或可维护性的问题。
3. 视觉润色——不阻碍任务完成的视觉优化。

不要根据截图推断后端正确性。没有相应证据时，不要声称能够提升转化率、留存率、无障碍水平或性能。

交付前验证

运行内置结构检查：

node /scripts/validate-project.js 

然后选择必要的验证方式：

• 运行 lint、类型检查、单元测试、组件测试或仓库已有测试；
• 使用当前版本微信开发者工具编译并手动走查核心流程；
• 检查代表性屏幕宽度、安全区域、长文本、图片缺失以及弱网/离线状态；
• 检查权限、角色、重复提交、取消、重试和状态过期场景；
• 对支付、预约、内部流程或其他权威系统运行服务端集成测试。

分开报告四种状态：

• 已实现并验证；
• 已实现但未完成运行验证；
• 使用模拟数据或等待集成；
• 超出范围或存在阻塞。

不要仅凭项目能够编译就将原型描述为生产级成品。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: akuguaaaa-png
• Source: akuguaaaa-png/wechat-mini-program-builder
• License: MIT

Install and usage instructions live in the source repository linked above.