示例场景
客户想做一个预约和资料提交小程序，首版先服务真实客户，不急着做复杂会员、营销和支付。
真实需求不必和这个场景完全一样，但应该达到同样的颗粒度：目标、角色、首版范围、暂不做范围、验收和部署都要能落到具体描述。
Requirement Example
小程序需求示例
把一句“想做小程序”拆成用户角色、核心流程、页面、接口、微信能力、上线条件和验收动作。
好需求写法
下面这些内容可以直接作为任务包草稿，再根据真实项目替换细节。
项目目标
做一个微信小程序，让客户能查看服务项目、提交预约和上传资料，管理员能在后台看到并处理。
用户角色
游客可以浏览服务，微信登录用户可以提交预约，管理员在后台处理预约状态。
首版范围
首页、服务列表、服务详情、预约表单、资料上传、提交结果、个人预约记录、后台预约列表和状态修改。
暂不做范围
首版不做支付、会员等级、优惠券、复杂营销、客服自动回复和数据大屏。
接口和数据
需要用户、服务项目、预约、附件、处理记录和基础配置；接口覆盖登录、列表、详情、提交、上传和后台审核。
验收标准
用户能登录并提交一条带附件的预约；管理员能看到这条预约并把状态改为已处理；用户端能看到状态变化。
部署条件
AppID、主体认证、隐私协议、备案、HTTPS 合法域名和服务器环境需要在正式提审前确认。
验收重点
微信登录、接口鉴权、文件上传和预约状态流转都要逐项测试。
移动端表单输入、长文本、图片上传失败和重复提交要有明确处理。
后台只能看到授权范围内的数据，不能暴露用户手机号、附件地址和管理接口。
提审前检查隐私协议、类目、合法域名、用户信息字段和订阅消息配置。
不要这样做
不要一开始同时做商城、会员、分销、支付和营销活动。
不要在没有合法域名和备案状态时承诺能直接提审上线。
不要把 AppSecret、支付密钥、后台账号或真实用户资料写进公开仓库。
