简诗 AI 小程序任务梳理

要解决的问题

小程序功能迭代常陷入“功能即需求”的误区：团队把老板拍板的诉求、埋点中偶尔冒头的点击，直接当成用户真实目标，上线后却无法回答“用户到底有没有完成想做的事”。比如某餐饮小程序堆叠拼单按钮，却没人梳理用户在聚餐场景下“快速凑单并分账”的核心任务，最终功能上线后完成率低迷，迭代方向只能靠猜。

技能如何工作

核心能力

只聚焦小程序功能迭代中的用户任务梳理，产出可执行的任务场景卡——明确“谁、在什么情境下、想完成什么、现在怎么做、卡在哪里”。它不做全盘战略规划，不替代真实平台操作，也不把假设冒充结果。

关键步骤

1. 证据核对：先整理用户反馈、埋点数据和开发约束，标记每项数据的来源、日期、口径缺口；资料不足时优先输出补证据清单。
2. 情境化任务描述：从触发情境（如“周末聚餐前发起拼单”）、期望结果（“10分钟内凑够人数并分账”）、现有替代方法（如“微信群接龙手动算账”）三方面拆解任务，保留用户原话。
3. 约束固化：将“需求证据与老板判断分开”作为硬约束，防止方案用无法兑现的承诺绕过真实用户诉求。
4. 真实目标区分：剥离表面的“加按钮”请求，找到背后的真实目标（如“降低凑单的沟通成本”）。
5. 优先级筛选：找出高频、高痛且未被满足的任务，避免资源浪费在伪需求上。
6. 核验与复查：用反馈编号、数据截图和技术评估对应场景卡的关键判断，上线后以任务完成率为复查指标——没有实际数据时只给计算口径，不虚构结果。

交付物包括任务场景卡、核验清单（反馈编号、数据截图、技术评估）和上线后任务完成率复查记录，每一步都可追溯。

适用边界与注意点

• 不承诺流量、转化率、收入等商业结果，也不替代合同、合规审批或真实平台操作。
• 涉及预算、价格、库存、会员数据时，必须标注来源和日期，区分已确认事实、分析判断和待确认事项，不编造经营数据。
• 处理真实变更（如发布、付费、权限修改）前，必须取得用户明确授权；涉及个人信息时仅使用最小必要信息，提醒去标识化。
• 若关键条件（如任务无情境、机会点无频次证据）不满足，直接输出“暂不可交付”，列出缺失信息和补证据动作，而非空泛建议。