小程序功能迭代概念测试卡

先把需求和判断分开

小程序要加一个拼单、会员或优惠券入口时，最常见的风险不是没人写代码，而是需求证据和老板判断被混在一起：一句“用户会喜欢”替代了反馈、埋点和开发约束。开发一旦启动，产品方要承担的是灰度、兼容、审核和回滚成本，而不是一句被高估的直觉。

这个技能只处理小程序功能迭代中的概念测试任务，交付物是一张能在立项会上直接评审的 概念测试卡。它不替代全盘战略、真实平台操作、合同或合规审批，也不会把建议写成已经发生的结果。

用证据生成概念测试卡

开始前需要四类信息：用户反馈、埋点和开发约束；需求证据与老板判断分开；产品概念；目标人群、关键假设。涉及预算、价格、库存、时间、平台规则、会员或客户数据时，必须标明来源和日期。

执行时按六个步骤推进：

• 核对用户反馈、埋点和开发约束，标记数据日期、来源、缺失项和不可比较口径；资料不足时先输出补证据清单。
• 用人群、场景、利益、差异和价格写成简洁概念，不堆功能。
• 把“需求证据与老板判断分开”写成该场景的硬约束，任何方案都不得用无法兑现的承诺绕过它。
• 设计不诱导的理解、价值和选择问题。
• 预设继续、修改和停止的判断条件。
• 用反馈编号、数据截图和技术评估完成交付前核验；没有实际数据时只给测量口径。

质量检查要求概念不堆功能、问题不诱导、样本匹配人群、判断条件预先设定，并且反馈编号、数据截图和技术评估能够对应到交付物里的关键判断。任一关键条件不满足时，输出“暂不可交付”，并列出缺失信息、影响范围和下一步补证据动作，而不是用空泛建议填满模板。

边界要明确

复查指标是上线后任务完成率。当没有真实数据时，只能给出 计算口径 和 复查时间，不能虚构转化率或收入效果。该技能不承诺流量、排名、审核、裂变规模或活动效果，也不读取密码、Token、私钥及与任务无关的个人信息。