@chongyan/autospec 1.0.2 → 1.0.3

package/knowledge/03-guides/01-team-orchestrator.md

@@ -1,368 +0,0 @@
----
-name: team-orchestrator
-description: 当需要协调多个角色Agent并行执行对抗审查时触发
-type: support
----
-
-## 定位
-团队协调器，负责并行启动角色Agent、汇总意见、生成综合审查报告。实现多角色对抗审查的核心调度器。
-
-**AI Native 理念**：创业团队 Agent Team 是可扩展的核心概念，各类任务都可由相关成员组队完成。
-
-## 配置文件依赖
-
-本协调器依赖以下配置文件：
-- `${KNOWLEDGE}/05-config/01-team-stage.yaml` - 团队阶段配置
-- `${KNOWLEDGE}/05-config/03-role-composition.yaml` - 角色组合规则（含动态决策树、效率优化和质量红线）
-- `${KNOWLEDGE}/05-config/02-team-tasks.yaml` - 团队任务分配
-
-**动态阵型组织**：
-- 基于 `03-role-composition.yaml` 中的 `decision_tree` 动态选择角色
-- 根据项目特征（AI/数据/安全）、复杂度、强制触发规则自动组织阵型
-- 默认配置已足够好，模型根据配置原则动态组织阵型
-
-## 输入
-- 被审查文档路径
-- 复杂度评估结果（来自 complexity-assessor）
-- 当前阶段（requirement/design/implementation/testing/delivery）
-- 团队阶段（seed/growth/mature，默认 growth）
-
-## 输出
-团队对抗审查报告：
-```markdown
-## 团队对抗审查报告
-
-### 审查概述
-- 审查对象：{文档路径}
-- 当前阶段：{阶段}
-- 团队阶段：{seed/growth/mature}
-- 参与角色：{角色列表}
-- 审查时间：{时间}
-- AI Native 关注：{aiNative描述}
-
-### 各角色意见
-
-#### CEO 视角
-- **结论**：✅ 通过 / ⚠️ 有建议 / ❌ 不通过
-- **关键发现**：...
-- **建议**：...
-- **AI Native 视角**：...
-
-#### 产品负责人 视角
-...
-
-### 意见汇总
-
-| 角色 | 结论 | 关键发现 | 建议 | AI Native视角 |
-|------|------|----------|------|---------------|
-| CEO | ✅ | ... | ... | ... |
-| 产品负责人 | ⚠️ | ... | ... | ... |
-| ... | ... | ... | ... | ... |
-
-### 一致通过项
-- ...
-
-### 分歧项（需决策）
-| 分歧点 | 角色A意见 | 角色B意见 | 建议处理方式 |
-|--------|-----------|-----------|--------------|
-| ... | ... | ... | ... |
-
-### 必须修复
-- ...
-
-### 建议改进
-- ...
-
-### 综合结论
-- [ ] 通过 — 可进入下一阶段
-- [ ] 有条件通过 — 需修复必须项
-- [ ] 不通过 — 需重新设计/分析
-```
-
-## 执行步骤
-
-### Step 1: 读取配置文件 + 确定阵型
-
-**【强制】** 读取团队阶段配置和角色组合配置：
-
-```
-1. 读取 ${KNOWLEDGE}/05-config/01-team-stage.yaml
-   - 获取当前团队阶段配置（seed/growth/mature）
-   - 默认使用 growth 阶段
-
-2. 读取 ${KNOWLEDGE}/05-config/03-role-composition.yaml
-   - 获取当前阶段、当前复杂度对应的角色组合
-   - 获取 AI Native 关注点
-   - 获取动态决策树（decision_tree）
-   - 获取效率优化配置和质量红线
-
-3. 应用动态决策树
-   - 根据项目特征（AI/数据/安全）添加角色
-   - 根据复杂度确定角色数量
-   - 检查强制触发规则
-
-4. 读取 ${KNOWLEDGE}/05-config/02-team-tasks.yaml（如适用）
-   - 如果是特定任务（环境衔接、技术分析等），获取任务配置
-```
-
-**动态阵型选择逻辑**：
-```
-如果项目类型是 AI/ML → 使用 ai-focused 阵型
-如果项目涉及安全敏感 → 使用 security 阵型
-如果复杂度 ≤ 2 → 可考虑 simple 阵型
-否则 → 使用 standard 阵型
-```
-
-### Step 2: 确定参与角色
-
-根据配置文件确定角色列表：
-
-```
-角色确定流程：
-1. 从 team-stage.yaml 获取团队阶段配置
-2. 从 role-composition.yaml 获取 {stage}.{complexity} 对应的角色组合
-3. 应用强制触发规则（mandatoryTriggers）
-4. 合并最终角色列表
-
-示例配置读取：
-# 团队阶段配置
-stages:
-  growth:
-    triggers:
-      medium: [ceo, product-owner, tech-lead, backend-engineer, ai-engineer]
-
-# 角色组合配置
-compositions:
-  requirement:
-    medium:
-      roles: [ceo, product-owner, tech-lead, ai-engineer]
-      aiNative: "AI工程师参与评估AI方案可行性"
-```
-
-### Step 3: 并行启动角色Agent
-
-使用 Agent 工具并行启动每个角色的审查Agent：
-
-```
-为每个角色并行启动 Agent：
-  Agent.run({
-    name: "{role}-reviewer",
-    prompt: `
-      请从{角色名称}视角审查以下文档。
-
-      角色画像：${KNOWLEDGE}/guides/roles/{role}.md
-      被审查文档：{文档路径}
-      当前阶段：{阶段}
-
-      AI Native 关注：{从配置获取}
-
-      审查要求：
-      1. 先读取角色画像，理解该角色的关注点
-      2. 从该角色视角审查文档
-      3. 输出：结论 + 关键发现 + 建议 + AI Native视角
-
-      注意：你是独立审查者，只看产出物和角色标准，不参考其他角色的意见
-    `
-  })
-```
-
-**关键原则**：
-- **做审分离**：每个角色Agent独立运行，不共享上下文
-- **信息隔离**：只传入被审查文档 + 角色画像 + 审查标准
-- **并行执行**：所有角色Agent同时启动，不串行等待
-- **AI Native**：每个角色都从AI思维视角审查
-
-### Step 4: 收集并汇总意见
-
-等待所有Agent完成后，收集并汇总意见：
-
-```
-意见汇总逻辑：
-1. 收集各角色审查结果
-2. 分类：通过 / 有建议 / 不通过
-3. 识别分歧点
-4. 提取 AI Native 相关建议
-```
-
-### Step 5: 处理分歧点
-
-当不同角色意见不一致时：
-
-1. **识别分歧**：找出结论相反或建议冲突的点
-2. **分析原因**：是视角不同还是理解偏差
-3. **提出处理建议**：
-   - 视角不同 → 提交用户决策
-   - 理解偏差 → 补充信息后重新审查
-
-### Step 6: 生成综合报告
-
-汇总所有角色的意见，生成结构化报告。
-
-### Step 7: 综合判定
-
-根据汇总结果做出判定：
-
-| 情况 | 判定 | 处理 |
-|------|------|------|
-| 全部通过 | 通过 | 进入下一阶段 |
-| 有建议但无必须修复 | 有条件通过 | 记录建议，进入下一阶段 |
-| 有必须修复 | 不通过 | 返回修正 |
-| 有分歧 | 待决策 | 标记NEEDS_CLARIFICATION，升级用户 |
-
-## AI Native 角色审查视角
-
-每个角色都有 AI Native 思维特质：
-
-### CEO 视角
-- 战略一致性：需求是否符合公司战略
-- 商业价值：投入产出比是否合理
-- 风险把控：是否存在重大风险
-- **AI Native**：战略决策考虑AI能力边界，识别AI带来的新机会
-
-### 产品负责人 视角
-- 用户价值：是否解决用户问题
-- 商业目标：是否支撑商业目标
-- 用户体验：是否影响用户体验
-- **AI Native**：AI产品思维，理解AI能力边界
-
-### 技术负责人 视角
-- 架构合理性：架构是否清晰合理
-- 过度设计：是否引入不必要复杂度
-- 技术选型：选型是否合理
-- **AI Native**：AI架构思维，评估AI方案可行性
-
-### AI工程师 视角
-- AI方案可行性：技术方案是否可实现
-- 模型选型：模型/技术选型是否合理
-- 效果评估：如何验证AI效果
-- **AI Native**：核心能力，模型选型、Prompt工程、效果优化
-
-### 数据工程师 视角
-- 数据架构：数据流是否合理
-- 数据质量：数据质量如何保障
-- 数据安全：数据是否安全
-- **AI Native**：数据驱动基石，数据质量、管道、特征工程
-
-### 工程师 视角
-- 可实现性：设计是否可实现
-- 工程质量：代码质量、测试覆盖
-- 性能安全：是否有隐患
-- **AI Native**：AI集成思维，API设计考虑AI调用
-
-### 安全工程师 视角
-- 安全漏洞：是否有安全风险
-- 合规性：是否符合合规要求
-- 数据安全：敏感数据处理是否安全
-- **AI Native**：AI安全思维，Prompt注入防护、数据隐私
-
-### 运维工程师 视角
-- 部署可行性：部署方案是否可行
-- 监控告警：监控是否完善
-- 成本控制：资源成本是否合理
-- **AI Native**：AI运维思维，模型部署、GPU资源管理
-
-## 效率优化策略
-
-### 1. 并行执行（默认开启）
-所有角色Agent并行运行，不串行等待：
-```
-启动时间：T0
-角色A审查：T0 → T1
-角色B审查：T0 → T2
-角色C审查：T0 → T3
-总耗时：max(T1, T2, T3)
-```
-
-### 2. 增量审查
-对于修改后的文档，只审查变更部分：
-```
-如果文档有版本标记：
-  只启动相关角色审查变更部分
-  其他角色的历史意见保留
-```
-
-### 3. 结果缓存
-相似问题的审查结果可复用：
-```
-如果文档内容相似度 > 80%：
-  复用上次审查结果
-  只重新审查差异部分
-```
-
-### 4. 快速模式（条件触发）
-满足以下条件时，可减少角色数量：
-- 复杂度评分 ≤ 3
-- 无安全敏感内容
-- 历史审查通过率 > 80%
-
-### 5. 跳过非必要审查（需记录）
-时间紧迫时，可跳过非关键审查，但必须：
-- 记录跳过理由
-- 保持可追溯性
-- 后续可补
-
-## 质量红线（不可逾越）
-
-以下场景必须执行对应检查，不能跳过：
-
-| 场景 | 必须触发的Agent |
-|------|---------------|
-| 安全敏感项目 | safety-auditor |
-| 交付归档阶段 | consistency-checker |
-| 修复循环失败3次 | failure-diagnostician |
-| 阶段完成时 | stage-gate-evaluator |
-
-**原则**：效率优化不能牺牲质量，该有的审查必须有，只是可以更智能地选择角色组合。
-
-## 反模式清单
-
-1. **串行执行**：一个一个启动Agent。检测：必须并行启动
-2. **信息泄露**：角色Agent看到其他角色的意见。检测：每个Agent只传入文档和角色画像
-3. **忽略分歧**：不一致意见直接忽略。检测：分歧必须记录并处理
-4. **过度审查**：简单任务也启动全部角色。检测：按配置文件确定角色列表
-5. **忽略AI Native视角**：每个角色都应该有AI思维视角
-
-## 与现有流程的集成
-
-### 需求阶段
-```
-需求分析完成
-    ↓
-complexity-assessor 评估复杂度
-    ↓
-team-orchestrator 协调团队审查（读取配置）
-    ↓
-生成团队对抗审查报告
-    ↓
-处理结果：通过 → 进入设计阶段 | 不通过 → 返回修正
-```
-
-### 设计阶段
-```
-方案设计完成
-    ↓
-继承或重新评估复杂度
-    ↓
-team-orchestrator 协调团队审查（读取配置）
-    ↓
-生成团队对抗审查报告
-    ↓
-处理结果：通过 → 进入编码阶段 | 不通过 → 返回修正
-```
-
-### 与 Layer 2 的关系
-- 团队对抗审查在 Layer 2 之前执行
-- 团队对抗审查不通过 → 不进入 Layer 2
-- 团队对抗审查通过 → 执行 Layer 2 独立审查（做审分离）
-
-## 团队任务支持
-
-除了阶段审查，team-orchestrator 还支持以下团队任务（从 team-tasks.yaml 读取配置）：
-
-| 任务 | 团队组合 | 说明 |
-|------|---------|------|
-| 环境衔接 | tech-lead + devops + backend | 项目环境扫描、技术栈识别 |
-| 技术分析 | tech-lead + backend + frontend + ai | 技术栈深入分析 |
-| AI评测 | ai-engineer + quality + data | AI效果评测、Badcase分析 |
-| 安全审计 | security + tech-lead + backend | 安全漏洞扫描、合规检查 |
-| 一致性检查 | tech-lead + quality | 跨产物一致性检查 |

package/knowledge/03-guides/02-analyze-requirement.md

@@ -1,195 +0,0 @@
----
-name: requirement-analyzer
-description: 当收到原始需求（口头/文字/issue）需要转化为结构化需求文档时触发
-type: produce
----
-
-## 定位
-需求阶段的核心"做"类skill。将非结构化的原始需求转化为可指导设计的结构化需求文档。
-
-## 输入
-- 必须输入：原始需求（口头描述、文字记录、issue、用户反馈等）
-- 可选输入：项目背景信息、现有系统信息、相关业务知识
-
-## 输出
-
-结构化需求文档，包含：
-- 需求背景与目的（为什么要做）
-- 功能需求列表（含优先级：P0/P1/P2）
-- 非功能需求（性能、安全、兼容性等）
-- 每条功能需求的验收标准
-- 依赖和约束
-- 不做的事项（明确排除）
-- 待澄清问题列表（最多3个NEEDS CLARIFICATION，其余做合理默认）
-- **关键假设清单**（已确认 / 待确认）
-- **证据清单**（支撑需求合理性的依据：用户反馈来源、数据支撑等）
-
-### 产出物模板（增强版）
-
-产出 `.autospec/specs/{feature}/requirement.md`，建议包含以下章节：
-
-#### 文档头部
-
-```markdown
----
-document_id: REQ-{feature}-001
-version: v1.0
-created: YYYY-MM-DD
-updated: YYYY-MM-DD
-status: Draft/Review/Approved
-upstream: []
-downstream: [DES-{feature}-001]
----
-
-## 版本历史
-
-| 版本 | 日期 | 修改人 | 修改说明 |
-|-----|------|--------|---------|
-| v1.0 | YYYY-MM-DD | | 初始版本 |
-```
-
-#### 第一章：背景与目的
-
-- **业务背景**：为什么需要做这个功能？当前痛点是什么？
-- **业务目标**：期望达成的业务指标（可量化）
-- **技术目标**：期望达成的技术指标（如有）
-
-#### 第二章：功能范围
-
-- **功能列表**：做什么
-  - 功能ID | 功能名称 | 优先级 | 验收标准
-- **非功能需求**：性能/安全/兼容性/可用性
-- **不做的事项**：明确排除的范围
-
-#### 第三章：用户场景
-
-- **目标用户**：谁使用这个功能
-- **使用场景**：什么情况下使用
-- **用户故事**：As a... I want to... So that...
-
-#### 第四章：业务规则
-
-从需求提取的业务规则，每个规则引用 BR-ID：
-
-```markdown
-| 规则ID | 规则名称 | 规则描述 | 来源 |
-|--------|---------|---------|------|
-| BR-01 | （规则名） | （描述） | requirement.md#章节 |
-```
-
-如规则未在 `knowledge/09-templates/06-business-rules.md` 中定义，需同步新增。
-
-#### 第五章：边界定义
-
-- **边界案例**：极端情况如何处理
-- **约束条件**：时间/资源/技术约束
-- **依赖识别**：依赖的系统/服务/数据
-
-#### 第六章：风险评估
-
-```markdown
-| 风险ID | 风险名称 | 类型 | 可能性 | 影响 | 缓解措施 |
-|--------|---------|------|--------|------|---------|
-| R-01 | （风险名） | 业务/技术 | 高/中/低 | 高/中/低 | （措施） |
-```
-
-#### 第七章：知识缺失
-
-- **待确认项**：需要进一步确认的问题
-- **假设清单**：当前做的假设（继承关键假设清单）
-
-#### 第八章：Open Questions
-
-待澄清问题列表（最多3个），每个问题附AI推荐答案：
-
-```markdown
-| 序号 | 问题 | AI推荐答案 | 状态 |
-|-----|------|----------|------|
-| 1 | （问题） | （推荐答案） | 待确认/已确认 |
-```
-
-#### 附录
-
-- **术语引用**：引用 `knowledge/09-templates/05-business-glossary.md` 中的术语
-- **流程引用**：引用 `knowledge/09-templates/07-business-flows.md` 中的流程图
-
-### 自查清单（嵌入式）
-
-产出完成后，执行自查：
-
-- [ ] 每条功能有明确的验收标准
-- [ ] 业务规则已提取并ID化
-- [ ] 术语已在 glossary.md 中定义（如有新术语）
-- [ ] 关键流程已有流程图（如有）
-- [ ] 风险已评估并有缓解措施
-- [ ] 假设已明确记录
-- [ ] 待澄清问题不超过3个
-
-## 执行步骤
-1. 通读原始需求，理解背景和目的
-   - 预期产出：对需求背景的一段话总结
-   - 失败处理：背景不清晰则标记为NEEDS CLARIFICATION
-2. **需求穿透**：至少追问两层"为什么"
-   - 用户方案（What）→ 产品需求（How）→ 真实痛点（Why）
-   - 用JTBD三维度分析：功能任务 / 情感任务 / 社会任务
-3. **价值验证**：检查客户价值公式
-   - 客户价值 = 新方案价值 - 旧方案价值 - 转换成本 > 0
-   - 如不成立，标记为待讨论
-4. 提取功能点，拆解为独立的功能需求条目（MECE原则）
-5. 对每条功能需求，按5W标准描述：
-   a. Who（用户角色）/ Where+When（场景）/ What（需求）/ Why（动机）
-   b. 定义验收标准（可验证的条件）
-   c. 识别模糊点（如有，加入待澄清列表）
-6. 补充非功能需求（参考 methodology/checklists/requirement.md）
-7. 识别依赖关系和约束条件
-8. 明确不做的事项（防止范围蔓延）
-9. 排定优先级（P0必做/P1应做/P2可做）
-10. 定义效果指标和基线（当前是什么、目标是什么）
-11. **整理关键假设清单**，标注已确认/待确认
-12. **整理证据清单**，标注每条需求的支撑依据
-
-## 反模式清单（DP7）
-1. **需求镀金**：加入原始需求未提及的功能。检测：每条功能回溯到原始诉求，无法回溯的删除
-2. **隐含需求遗漏**：用户没说但理应包含的。检测：用checklist逐项检查非功能需求
-3. **边界模糊**：什么算做完没说清。检测：强制填写验收标准和排除项
-4. **假设隐藏**：假设了条件但未显式记录。检测：强制填写关键假设清单
-5. **过度澄清**：无限追问延迟推进。检测：最多3个NEEDS CLARIFICATION，其余做合理默认
-6. **范围蔓延**：拆解过程中不断扩大范围。检测：定期回溯原始需求核心诉求
-
-## 适用场景与边界
-- 适用：所有需要从原始需求产出结构化文档的场景
-- 不适用：需求已经结构化只需评审（用requirement-reviewer）
-- 边界：分析和结构化需求，但不做技术可行性深度评估（那是设计阶段的事）
-- 前置：无
-- 后续：requirement-reviewer审查 → 通过后进入design-planner
-
-## 示例
-**输入**："我们需要给商机项目加一个企业标签筛选功能，用户可以按行业、地区、规模筛选企业"
-**输出**：
-```
-## 需求背景
-商机项目用户需要从大量企业中快速定位目标客户，当前只能通过搜索，无法按维度筛选。
-
-## 功能需求
-1. [P0] 行业筛选：用户可按行业分类筛选企业列表
-   - 验收标准：支持多级行业分类选择，选择后列表实时更新
-2. [P0] 地区筛选：用户可按省/市筛选
-   - 验收标准：支持多选，选择后与行业筛选联动
-3. [P1] 规模筛选：用户可按企业规模档位筛选
-   - 验收标准：支持预设档位（微型/小型/中型/大型）
-
-## 非功能需求
-- 筛选响应时间 < 500ms
-- 支持10万+企业数据量
-
-## 不做
-- 不做自定义筛选维度（本期只做固定3个维度）
-- 不做筛选结果导出
-
-## 关键假设
-- [已确认] 企业数据已有行业、地区、规模字段
-- [待确认] 行业分类使用国标分类体系
-
-## 证据
-- 用户反馈中提及"找不到目标企业"的占比：来自support tickets统计
-```