4.1 KiB
4.1 KiB
title, type, tags, date
| title | type | tags | date |
|---|---|---|---|
| Runbook: Enterprise Feature Development | source | 2026-05-02 |
Source File
Summary（用中文描述）
- 核心主题：企业级产品大型功能开发的多 Agent 编排完整手册
- 问题域：合规、安全、质量门控不可妥协，20-30 个 Agent 并行协作，多方利益相关者需对齐
- 方法/机制：NEXUS-Sprint 模式，12 周五阶段流水线（需求架构→基础构建→开发→硬化→发布），每个阶段设置 Quality Gate，Reality Checker 默认返回 NEEDS WORK
- 结论/价值：可复用的企业级功能开发 Agent 编排模板，量化质量指标 + 结构化风险矩阵 + 分层利益相关者沟通节奏
Key Claims（用中文描述）
- 多 Agent 编排（20-30 个 Agent）可将企业级功能开发在 6-12 周内完成，同时满足合规、安全和质量门控要求
- 利益相关者沟通必须分层分级：执行层每日、产品周报、主管层双周 SCQA 简报（≤500 词）、合规/财务月度报告
- Reality Checker 质量门默认返回 NEEDS WORK（而非默认通过），强制修复循环直至完全合规
- 代码覆盖率 >80%、API P95 响应时间 <200ms、无关键安全漏洞、品牌一致性 ≥95%、10 倍流量压测通过，才能发布
Key Quotes
"Reality Checker → Integration testing (default: NEEDS WORK)" — 最终质量门必须主动修复，不接受默认通过 "Legal Compliance Checker involved from Day 1" — 合规从项目第一天介入，而非事后补查 "Sprint Prioritizer enforces MoSCoW, Project Shepherd manages changes" — 范围蔓延通过 MoSCoW 优先级强制管控
Key Concepts
- Quality-Gate：每个阶段结束的结构化验收点，未通过则进入修复循环
- RICE-Scoring：Sprint Prioritizer 用于对 Product Backlog 进行评分排序的方法论（Reach/Impact/Confidence/Effort）
- MoSCoW：需求优先级框架（Must have/Should have/Could have/Won't have），防止范围蔓延
- Canary-Deployment：灰度发布策略（5%→25%→100%），通过 DevOps Automator 逐步放量降低发布风险
- WCAG-2.1-AA：Web 内容无障碍指南 2.1 AA 级，是企业级功能发布的强制可访问性要求
Key Entities
- Agents-Orchestrator：流水线控制器，管理 Dev↔QA 循环的核心协调 Agent
- Project-Shepherd：跨职能协调员，负责利益相关者分析和变更管理
- Sprint-Prioritizer：Product Backlog 管理，使用 RICE 评分和 MoSCoW 防止范围蔓延
- Reality-Checker：最终质量门，默认返回 NEEDS WORK，强制修复循环
- Evidence-Collector：视觉 QA，通过截图记录每个任务的质量证据
- Experiment-Tracker：A/B 测试追踪，为关键功能设置实验对照
- Legal-Compliance-Checker：合规审查 Agent，从项目第一天介入直至最终审计通过
- Performance-Benchmarker：性能基准测试，包括 P95 响应时间 <200ms 和 10 倍流量压测
- Executive-Summary-Generator：执行层简报生成器，使用 SCQA 框架（Situation/Complication/Question/Answer）
- DevOps-Automator：CI/CD 和灰度发布（Canary Deployment 5%→25%→100%）执行
Connections
- scenario-marketing-campaign ← similar_pattern ← 本 Runbook：两者均为多 Agent 协作+NEXUS-Sprint 框架，营销场景侧重内容传播，本 Runbook 侧重企业合规开发
- scenario-incident-response ← related ← 本 Runbook：应急响应是第 11-12 周 Week 11 "Final Judgment" 的关键前置知识
- NEXUS ← managed_by ← Agents-Orchestrator：NEXUS 框架通过 Agents Orchestrator 实现多 Agent 流水线编排
- agent-activation-prompts ← template_source ← 本 Runbook：本 Runbook 定义的 Agent 角色使用 agent-activation-prompts 中的标准化模板激活
Contradictions
- 与 scenario-marketing-campaign 无冲突：营销场景重内容传播，本 Runbook 重合规开发，方法论互补而非矛盾
- 与 scenario-incident-response 无冲突：应急响应是发布后事件，本 Runbook 是发布前流程，时序无重叠