用途：把用户随时抛出的产品想法、使用痛点整理成持续维护的结构化需求池，并在准备启动新版本时协助筛选。定位是痛点驱动，不做假设性规划和提前排期，需求池管理到“可以做了”为止，后续设计/PRD/开发由其他流程接管。
主要能力：按四档状态归档需求——可以做了、需要想想、先放着、已完成；维护总览表与详情区；识别新想法与既有条目是否同方向并建议合并；定期整理池子，对条目提出删除、升档或追问建议；筛选版本候选时按频率、可绕过性、ROI 三个标准做对比分析；版本完成后归档并补充版本号与完成时间，同时检查依赖条目能否升档。
使用方式：需求池文件位于 docs/需求池.md，已存在则更新，不存在则按给定模板创建（含总览表和各状态分区）。总览表每行需有编号、需求名称、状态、依赖、备注；不同分区使用不同字段，如“可以做了”必填痛点、方案，“需要想想”必填方向，“先放着”必填想法，“已完成”必填完成时间、简述。编号递增、不复用已删除编号。流程分六步：收集（追问痛点、频率、现在怎么绕，整理成一句话确认）、归类（读取现有池、判断合并与状态、经用户确认后写入）、写入、整理、筛选、归档。
限制与约束：必须先追问确认，不能用户说一句就直接写入；追问超过 3 轮未收敛，先按当前理解归档并标注“待进一步讨论”。状态归类、合并、批量变更都需用户确认。不得替用户决定做哪个需求、不得强行排优先级、不得编造需求内容。池子是被动的，不应当作待办清单催用户。
暂未提供：具体的安装方式、运行环境要求与收费信息。