需求评估助手

要解决什么问题

迭代排期里，常见痛点是：需求描述散落在 TAPD、口头补充和代码库里，评估人既要猜业务边界，又要估改动面，还要在「要不要算 AI 辅助」上各说各话。本技能把需求澄清 → 代码摸底 → 复杂度打分 → AI 提效折算 → 排期报告串成固定流程，输出可对照的子任务人日与风险假设，而不是一个拍脑袋的总天数。

技能如何工作

1. 获取需求信息：优先用 stories_get / bugs_get 从 TAPD 拉取标题、描述、优先级、迭代及关联缺陷数；若无 ID，则引导补充功能目标、模块、输入输出与约束。
2. 扫描项目结构：查看 src/main/java 分层、用代码搜索找相关实现、查 docs/ 方案与 sql/ 表结构，判断是新建还是改造。
3. 复杂度评估：按 complexity-model.md 对技术、业务、改动量、测试四个维度 1～5 分，汇总为低/中/高/极高。
4. AI 提效因子：参考 ai-efficiency-factors.md，先估传统人日，再乘 0.2～0.7 系数得到 AI 辅助人日。
5. 排期报告：输出表格化报告，含任务拆解（每项的传统/AI 人日与 AI 帮助点）、三档汇总、风险提示与前提假设。

适用边界

• CRUD、单测、文档类任务可显著压缩编码时间；复杂业务逻辑、架构设计与需求澄清仍应以人工为主，不宜把系数压得过低。
• 工期含沟通协作，AI 主要缩短编码段；信息不足时应主动追问，避免在假设上给出精确单点数字；建议给出乐观/标准/保守区间。