负责需求解析、结构化提取、歧义识别、优先级评估，输出标准化需求规格说明书
基于结构化需求生成完整 PRD 文档，包含功能列表、用户故事、验收标准
设计系统架构、数据库 schema、API 路由、技术选型、性能优化策略
设计 UI 组件架构、状态管理方案、响应式布局、交互逻辑、性能优化
生成 OpenAPI/Swagger规范、定义请求响应格式、错误码、认证授权机制
根据技术方案和 API 协议自动生成前后端代码，支持多语言多框架
自动生成单元测试用例，覆盖边界条件、异常场景，确保代码质量
执行端到端测试、API 集成测试、数据一致性验证、性能压力测试
使用 Playwright/Selenium进行UI自动化测试，视觉回归测试，用户体验验证
管理 Jenkins Pipeline、Docker镜像构建、K8S部署、灰度发布、回滚机制
从多渠道自动采集需求信息，包括文档上传、会议记录同步、IM 消息监听等
去除噪声、格式化文本、OCR 识别、语音转写校对
NLP 处理、实体识别、关系抽取、需求拆解
识别模糊点，生成澄清问题，等待人工确认后继续
生成需求评审报告，组织相关方 review，收集反馈
生成 JSON Schema 格式需求规格书，同步到需求管理系统
# 需求分析 Agent 核心类结构示例
class RequirementAnalysisAgent:
"""
需求分析 Agent - 负责将非结构化需求转换为标准化规格
"""
def __init__(self, config: AgentConfig):
self.nlp_engine = NLPEngine() # NLP 处理引擎
self.knowledge_graph = DomainKG() # 领域知识图谱
self.clarification_bot = ClarificationBot() # 澄清机器人
self.output_formatter = OutputFormatter() # 输出格式化
async def analyze(self, raw_requirement: str) -> StructuredRequirement:
"""主分析流程"""
# Step 1: 语义理解
semantic_result = await self.nlp_engine.parse(raw_requirement)
# Step 2: 实体与关系抽取
entities = self.extract_entities(semantic_result)
relations = self.extract_relations(entities)
# Step 3: 需求拆解
features = self.decompose_features(entities, relations)
# Step 4: 歧义检测
ambiguities = self.detect_ambiguities(features)
if ambiguities:
clarifications = await self.clarification_bot.ask(ambiguities)
features = self.refine_features(features, clarifications)
# Step 5: 结构化输出
structured_req = self.output_formatter.format(features)
return structured_req
def extract_entities(self, text: str) -> List[Entity]:
"""提取业务实体（用户、对象、操作等）"""
pass
def decompose_features(self, entities: List[Entity]) -> List[Feature]:
"""拆解功能点"""
pass
def detect_ambiguities(self, features: List[Feature]) -> List[Ambiguity]:
"""检测模糊点和矛盾"""
pass
| 层级 | 描述 | 粒度 | 示例 |
|---|---|---|---|
| L1 - 史诗 (Epic) | 战略性业务目标 | 最大 | "提升用户留存率" |
| L2 - 特性 (Feature) | 可交付的功能模块 | 大 | "用户积分系统" |
| L3 - 用户故事 (User Story) | 从用户角度描述的功能 | 中 | "作为用户，我想查看积分余额，以便了解我的奖励" |
| L4 - 任务 (Task) | 具体开发任务 | 小 | "创建积分查询 API" |
| L5 - 验收标准 (Acceptance Criteria) | 可验证的完成条件 | 最小 | "Given 用户已登录，When 访问积分页面，Then 显示当前积分" |
# 用户故事提取规则模板
USER_STORY_PATTERN = {
"format": "As a [角色], I want [功能], So that [价值]",
"extraction_rules": [
{
"rule_id": "US-001",
"pattern": r"(?:作为 |As a)\s*(.+?)(?:我想要 |我希望|I want)\s*(.+?)(?:以便 |为了|So that)\s*(.+)",
"action": "extract_user_story",
"fields": ["role", "feature", "value"]
},
{
"rule_id": "US-002",
"pattern": r"(?:用户 | 客户|admin) 可以 (.+?) 来 (.+)",
"action": "infer_user_story",
"fields": ["feature", "value"],
"default_role": "user"
}
],
"validation": {
"required_fields": ["role", "feature", "value"],
"min_length": {"feature": 10, "value": 5}
}
}
# 验收标准 Gherkin 语法提取
ACCEPTANCE_CRITERIA_PATTERN = {
"format": "Given [前置条件] When [操作] Then [预期结果]",
"extraction_rules": [
{
"rule_id": "AC-001",
"pattern": r"(?:在 |Given)\s*(.+?)(?:当|When)\s*(.+?)(?:则|Then|那么)\s*(.+)",
"action": "extract_gherkin",
"fields": ["given", "when", "then"]
},
{
"rule_id": "AC-002",
"pattern": r"(?:如果 |If)\s*(.+?)(?:就| 则|then)\s*(.+)",
"action": "convert_to_gherkin",
"transform": "if_then_to_given_when_then"
}
],
"scenario_types": ["positive", "negative", "boundary", "error_handling"]
}
# 功能点层级拆解规则
FEATURE_DECOMPOSITION_RULES = {
"decomposition_strategies": [
{
"strategy": "by_user_action",
"description": "按用户操作拆解",
"patterns": ["点击", "输入", "选择", "上传", "下载", "删除", "编辑"]
},
{
"strategy": "by_data_entity",
"description": "按数据实体拆解",
"patterns": ["用户", "订单", "商品", "支付", "库存"]
},
{
"strategy": "by_crud",
"description": "按 CRUD 操作拆解",
"operations": ["Create", "Read", "Update", "Delete"]
}
],
"dependency_detection": {
"keywords": ["需要先", "依赖于", "前提是", "之后才能"],
"action": "build_dependency_graph"
}
}
# MoSCoW 优先级评估规则
PRIORITY_EVALUATION_RULES = {
"moscow_categories": {
"MUST_HAVE": {
"score_range": [8, 10],
"indicators": ["必须", "一定要", "核心", "关键", "blocking"],
"business_impact": "critical"
},
"SHOULD_HAVE": {
"score_range": [6, 7],
"indicators": ["应该", "重要", "需要", "high priority"],
"business_impact": "high"
},
"COULD_HAVE": {
"score_range": [4, 5],
"indicators": ["可以", "最好", "可选", "nice to have"],
"business_impact": "medium"
},
"WONT_HAVE": {
"score_range": [1, 3],
"indicators": ["暂时不", "以后", "低优先级", "low"],
"business_impact": "low"
}
},
"scoring_factors": [
{"factor": "business_value", "weight": 0.4},
{"factor": "urgency", "weight": 0.3},
{"factor": "risk_reduction", "weight": 0.2},
{"factor": "dependency_count", "weight": 0.1}
]
}
| 歧义类型 | 检测模式 | 澄清策略 | 示例 |
|---|---|---|---|
| 模糊数量词 | "一些"、"几个"、"若干" | 询问具体数值或范围 | "显示一些推荐商品" → "显示多少个？" |
| 模糊时间词 | "尽快"、"及时"、"实时" | 明确具体时间要求 | "尽快通知" → "多少分钟内？" |
| 模糊程度词 | "高性能"、"美观"、"友好" | 量化指标定义 | "高性能" → "响应时间<200ms?" |
| 指代不明 | "它"、"这个"、"上述" | 明确指代对象 | "保存它" → "保存什么对象？" |
| 逻辑矛盾 | 前后不一致的描述 | 标记冲突并请求确认 | "公开可见"vs"仅管理员可见" |
| 协同级别 | AI 自主度 | 人类介入时机 | 适用场景 |
|---|---|---|---|
| L1 - 全自动 | 100% | 仅在失败时介入 | 代码生成、单元测试、文档格式化 |
| L2 - AI 主导 | 80% | 关键决策点确认 | 技术方案设计、API 定义 |
| L3 - 人机对等 | 50% | 共同讨论决策 | 需求澄清、架构评审 |
| L4 - 人类主导 | 20% | AI 提供建议 | 产品战略、商业模式 |
| L5 - 全人工 | 0% | 完全人工决策 | 伦理审查、法律合规 |
AI 自动从多渠道采集需求，人类无需介入
AI 识别模糊点并提问，人类产品经理回答确认
AI 生成评审报告，人类组织相关方 review 并决策
AI 生成 PRD 初稿，人类 PM 审核并微调
AI 提供多个方案选项，人类架构师选择并优化
AI 生成 OpenAPI 规范，人类 Tech Lead 审批
AI 自动生成代码，人类仅在 CI 失败时介入
AI Reviewers 先审，人类抽查关键 PR
AI 生成并执行测试用例，人类查看报告
AI 执行自动化 UI 测试，人类进行体验验收
AI 管理 Pipeline，自动部署到 K8S
AI 监控错误并尝试自动修复，严重问题时通知人类
| 阶段 | 目标耗时 | 自动化率 | 质量指标 |
|---|---|---|---|
| 需求分析 | < 30 分钟 | 85% | 需求清晰度>90% |
| PRD 设计 | < 1 小时 | 90% | PRD 完整度>95% |
| 技术方案 | < 2 小时 | 70% | 方案可行性>90% |
| 代码开发 | < 4 小时 | 80% | 代码通过率>85% |
| 测试验证 | < 1 小时 | 95% | Bug 检出率>95% |
| 部署上线 | < 30 分钟 | 100% | 部署成功率>99% |
| 全流程总计 | < 10 小时 | 85% | 交付质量>90% |
| 风险类型 | 风险描述 | 影响程度 | 应对策略 |
|---|---|---|---|
| AI 生成代码质量 | AI 可能生成有 bug 或安全漏洞的代码 | 高 | 多层 Code Review + 自动化测试覆盖 + 人工抽查关键路径 |
| 需求理解偏差 | AI 误解用户真实意图 | 高 | 歧义澄清机制 + 人机协同确认 + 快速迭代反馈 |
| 系统依赖故障 | LLM API 不可用或限流 | 中 | 多模型备份 + 本地缓存 + 降级策略 |
| 数据安全风险 | 敏感信息泄露给 AI 模型 | 高 | 数据脱敏 + 本地优先架构 + 访问权限控制 |
| 技术债务累积 | 快速迭代导致代码质量下降 | 中 | 定期重构计划 + 技术债务追踪 + 代码规范约束 |
| 团队技能断层 | 过度依赖 AI 导致人类技能退化 | 中 | 保持人工 review 能力 + 定期技能培训 + 轮岗机制 |