Sync: add design and process improvement notes

2026-04-25 19:38:47 +08:00
parent 2613a74c73
commit 8c909c9c08
21 changed files with 1553 additions and 107 deletions
--- a/wiki/concepts/Change-Management.md
+++ b/wiki/concepts/Change-Management.md
@@ -1,69 +1,59 @@
 ---
-title: "Change Management"
+title: "Change-Management"
 type: concept
-tags: [itsm, devops, operations]
-date: 2025-03-01
+tags: [Organizational-Change, Process-Improvement, ITSM]
+sources: [testing-workflow-optimizer, understanding-complete-itsm]
+last_updated: 2026-04-21
 ---

-## Definition
+# Change-Management

-变更管理（Change Management）是[[ITSM]]的核心流程之一，通过**结构化的方法评估、审批和实施IT变更**，在保持服务稳定性的同时实现业务所需的灵活性。
+变更管理——在组织中系统性地规划、实施和控制人员、流程和技术变更的管理学科。核心目标是降低变更风险、提高采纳率、确保变革产生预期业务价值，同时最小化对现有服务运营的干扰。

-## Change Management Process
+## Aliases
+- 变革管理
+- 组织变革管理
+- IT Change Management（ITSM 语境）

-```
-┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│    Change    │ →  │   Impact    │ →  │    CAB       │
-│    Request   │    │  Assessment │    │   Approval   │
-└──────────────┘    └──────────────┘    └──────────────┘
-                                                  ↓
-┌──────────────┐    ┌──────────────┐    ┌──────────────┘
-│   Build &    │ ←  │    Change    │ ←  │   Schedule   │
-│   Test       │    │    Build     │    │   & Prepare  │
-└──────────────┘    └──────────────┘    └──────────────┘
-```
+## Core Frameworks

-## Change Types
+### Kotter's 8-Step Change Model
+1. **Create Urgency**（创造紧迫感）——让利益相关者认识到变革必要性
+2. **Build Guiding Coalition**（组建指导联盟）——建立变革领导团队
+3. **Form Strategic Vision**（形成战略愿景）——清晰描述变革后的未来状态
+4. **Enlist a Volunteer Army**（动员志愿者）——让尽可能多的人参与
+5. **Enable Action by Removing Barriers**（消除障碍）——移除阻碍变革的结构性和文化性壁垒
+6. **Generate Short-Term Wins**（创造短期胜利）——通过快速成果建立信心
+7. **Sustain Acceleration**（持续加速）——保持势头，不给反对派喘息空间
+8. **Institute Change**（固化变革）——将变革融入组织文化

-| 类型 | 描述 | 审批级别 |
-|------|------|---------|
-| Emergency | 紧急变更（如P1事故响应） | 快速审批 |
-| Standard | 标准变更（例行维护） | 自动审批 |
-| Normal | 常规变更（新功能部署） | CAB审批 |
+### ADKAR Model（Prosci）
+- **A**wareness（认知）——了解为什么需要变革
+- **D**esire（渴望）——愿意参与和支持变革
+- **K**nowledge（知识）——知道如何变革
+- **A**bility（能力）——能够实施新行为
+- **R**einforcement（强化）——巩固变革成果

-## Modern Change Management (ITSM 2.0)
+## In ITSM Context（ITIL Change Management）
+在 ITSM 框架中，变更管理分为：
+- **标准变更（Standard Change）**：预批准的低风险例行变更
+- **正常变更（Normal Change）**：需经 CAB（变更顾问委员会）评估和批准
+- **紧急变更（Emergency Change）**：突发事件驱动的快速变更，事后评估

-在[[ITSM 2.0]]中，变更管理由AI和[[IaC]]驱动：
+## In Workflow Optimization
+[[testing-workflow-optimizer]] 在实施流程优化时必须考虑变更管理：
+- **测量基线**前先建立利益相关者共识
+- **设计优化方案**需要获得关键干系人认同
+- **实施规划**必须包含培训和沟通计划
+- **自动化落地**需要克服员工的恐惧和阻力

-### AI-Driven Risk Assessment
- **Automated Impact Analysis** — 自动评估变更影响
- **Failure Probability Prediction** — AI预测变更失败概率
- **Rollback Planning** — 自动生成回滚计划
+## Common Pitfalls
+- **变革疲劳（Change Fatigue）**：频繁变更导致员工抵触
+- **忽略人因素**：只关注流程和技术，忽视人的情感
+- **缺乏可见成果**：没有短期胜利导致失去支持
+- **变革太快或太慢**：节奏失控

-### CI/CD Pipeline Governance
-```
-Code Commit → Automated Testing → IaC Validation → Risk Score → Approval
-     ↓            ↓                 ↓               ↓          ↓
-  Git hooks    Unit/Int Tests    Terraform Plan    ML Model   Auto/CAB
-```
-
-## Key Metrics
-
-| 指标 | 描述 |
-|------|------|
-| Change Success Rate | 变更成功率 |
-| Failed Change Rate | 失败变更率 |
-| Rollback Rate | 回滚率 |
-| Emergency Change Ratio | 紧急变更比例 |
-
-## Related Concepts
-
- [[ITSM]] — 父框架
- [[Change-Failure-Rate]] — 变更失败率
- [[IaC]] — 基础设施即代码
- [[CI/CD-Pipeline]] — CI/CD流水线
- [[Rollback]] — 回滚机制
-
-## Sources
-
- [[understanding-complete-itsm]] — AI-driven Change Management
+## Connections
+- [[testing-workflow-optimizer]] — 流程优化落地的必要保障机制
+- [[ITSM]] — ITSM 框架中的三大核心流程之一
+- [[Kaizen]] — 持续改进需要有效的变更管理支撑
--- a/wiki/concepts/Design-Thinking.md
+++ b/wiki/concepts/Design-Thinking.md
@@ -0,0 +1,46 @@
+---
+title: "Design-Thinking"
+type: concept
+tags: [UX, Human-Centered, Innovation, Process-Improvement]
+sources: [testing-workflow-optimizer, Human-Centered-Design]
+last_updated: 2026-04-21
+---
+
+# Design-Thinking
+
+设计思维——一种以人为中心的创新方法论，通过共情（Empathize）、定义（Define）、构思（Ideate）、原型（Prototype）和测试（Test）五个阶段的迭代循环，解决复杂问题并创造有意义的解决方案。
+
+## Aliases
+- 设计思维
+- Design Thinking Process
+- 以人为本的创新方法
+
+## Five Stages
+
+1. **Empathize（共情）**——深入理解用户的需求、感受、动机和行为。通过观察、访谈和沉浸式体验获取洞察。
+2. **Define（定义）**——综合共情阶段的洞察，明确要解决的核心问题（Point of View / How Might We）。
+3. **Ideate（构思）**——头脑风暴，生成大量创意和可能的解决方案，不评判，鼓励疯狂的点子。
+4. **Prototype（原型）**——用低成本、快速的方式制作解决方案的物理或数字原型。
+5. **Test（测试）**——用真实用户验证原型，收集反馈，迭代改进。
+
+## Core Principles
+- **以人为中心**：始终从人的真实需求出发，而非从技术可能出发
+- **迭代而非线性**：允许反复回到前面的阶段
+- **跨职能协作**：打破 silos，融合不同背景的视角
+- **快速失败、快速学习**：通过小规模实验快速获取认知
+
+## Connection to Human-Centered-Design
+Design Thinking 是 [[Human-Centered-Design]] 的系统性方法论框架——HCD 提供哲学和价值观，Design Thinking 提供可操作的流程。
+
+## Connection to Workflow Optimization
+[[testing-workflow-optimizer]] 将 Design Thinking 应用于流程改进：
+- **Empathize** → 理解员工（流程执行者）的真实痛点
+- **Define** → 明确效率瓶颈和优化目标
+- **Ideate** → 构思多种可能的优化方案
+- **Prototype** → 小规模试点验证优化方案
+- **Test** → 收集反馈，迭代改进
+
+## Connections
+- [[Human-Centered-Design]] — 哲学基础
+- [[Lean]] — 互补：Design Thinking 侧重创新发现，Lean 侧重效率优化
+- [[testing-workflow-optimizer]] — 应用于流程改进的方法论工具
--- a/wiki/concepts/Human-Centered-Design.md
+++ b/wiki/concepts/Human-Centered-Design.md
@@ -0,0 +1,60 @@
+---
+title: "Human-Centered-Design"
+type: concept
+tags: [UX, Process-Design, Employee-Experience, Design-Thinking]
+sources: [testing-workflow-optimizer]
+last_updated: 2026-04-21
+---
+
+# Human-Centered-Design
+
+人本设计——一种以最终用户和员工为核心的设计哲学，在设计产品、服务、流程和系统时，优先考虑人类的需求、能力、限制和情感，而非仅关注技术可行性或效率指标。
+
+## Aliases
+- HCD
+- 以人为本的设计
+- 人本设计
+
+## Core Principles
+1. **User Needs First**（用户需求优先）——在技术或流程约束之前，首先理解和满足人的需求
+2. **Empathy**（同理心）——深入理解用户的真实感受、痛点和心智模型
+3. **Iterative Design**（迭代设计）——通过快速原型→测试→改进的循环持续优化
+4. **Inclusion & Accessibility**（包容性与可访问性）——确保设计服务于所有用户，包括残障人士和边缘群体
+5. **Cognitive Load Management**（认知负荷管理）——减少用户在完成任务时的思考和记忆负担
+
+## In Workflow/Process Design
+在流程和工作流设计中，人本设计意味着：
+- **员工满意度优先于单纯效率**：好的流程设计不仅高效，还让执行者感到有价值和满足
+- **减少认知负荷**：将复杂的决策规则可视化，提供清晰的指引
+- **保留人类判断空间**：在自动化无法处理的灰色地带保留人工决策节点
+- **可访问性**：确保流程对所有能力水平的员工都可用
+
+## Connection to Workflow Optimization
+[[testing-workflow-optimizer]] 将人本设计作为核心约束：
+> "Prioritize user experience and employee satisfaction in process design"
+> "Consider change management and adoption challenges in all recommendations"
+> "Balance automation efficiency with human judgment and creativity"
+
+这意味着：
+- 自动化不应完全消除人的参与感
+- 流程设计应减少而非增加员工认知压力
+- 变革建议需要考虑员工的接受度和适应成本
+
+## Design Thinking Process
+1. **Empathize**（共情）——观察、访谈，理解用户
+2. **Define**（定义）——综合洞察，定义核心问题
+3. **Ideate**（构思）——头脑风暴，生成大量创意
+4. **Prototype**（原型）——快速低成本制作解决方案原型
+5. **Test**（测试）——用真实用户验证原型
+
+## Connection to Lean/Six-Sigma
+人本设计补充了 [[Lean]] 和 [[Six-Sigma]] 的量化视角：
+- Lean/Six-Sigma 提供数据驱动的优化框架
+- Human-Centered-Design 提供人本视角的优化方向
+- 两者结合：优化的指标必须与人的真实需求对齐
+
+## Connections
+- [[testing-workflow-optimizer]] — 流程优化中的人本设计约束
+- [[Cognitive-Load-Reduction]] — 人本设计的核心子维度
+- [[Lean]] — 互补：量化优化 + 人本方向
+- [[Design-Thinking]] — 人本设计的系统性方法论框架
--- a/wiki/concepts/Kaizen.md
+++ b/wiki/concepts/Kaizen.md
@@ -0,0 +1,55 @@
+---
+title: "Kaizen"
+type: concept
+tags: [Continuous-Improvement, Lean, Process-Improvement]
+sources: [testing-workflow-optimizer, devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin, AgilePractices]
+last_updated: 2026-04-21
+---
+
+# Kaizen
+
+改善（Kaizen）——日语"継続的改善"（持续改进）的音译，是一种以员工为核心、小步快跑、渐进式的持续改进哲学。核心理念：所有流程都有改进空间，每次改进即使微小，累积效果也十分显著。
+
+## Aliases
+- 改善
+- 持续改进（Continuous Improvement）
+- 渐进式改进
+
+## Origin
+源自丰田生产系统（TPS），由日本管理大师今井正明（Masaaki Imai）在 1986 年《Kaizen》一书中向西方推广。
+
+## Core Principles
+1. **Process Focus**（过程导向）——好的结果来自好的过程，聚焦过程改进而非单纯追求结果
+2. **Everyone Involved**（全员参与）——从 CEO 到一线员工，每个人都是改进的推动者
+3. **Small Improvements**（小步改进）——大幅改进往往由无数小改进累积而成
+4. **Discipline**（纪律性）——坚持不懈，持续执行
+5. **Eliminate Waste**（消除浪费）——持续识别和消除 Mudas（浪费）
+
+## Key Practices
+- **改善活动（Kaizen Event）**：短周期（1-5天）跨职能团队聚焦单一流程的密集改进
+- **PDCA Cycle**（戴明环）：
+  - **Plan**：计划改进
+  - **Do**：执行改进
+  - **Check**：检查结果
+  - **Act**：标准化或重新改进
+- **5S**：整理（Sort）/整顿（Set in Order）/清扫（Shine）/清洁（Standardize）/素养（Sustain）
+- **无责归因（No-Blame Culture）**——改进系统而非惩罚个人
+- **Gemba Walk**（现场走动）——管理者到实际工作现场观察和改进
+
+## Kaizen vs Six-Sigma
+| 维度 | Kaizen | Six-Sigma |
+|------|--------|-----------|
+| 节奏 | 渐进式，持续小改 | 阶段性，DMAIC 大改 |
+| 方法 | 定性为主，全员参与 | 定量为主，专家主导 |
+| 目标 | 消除浪费，流动改善 | 减少变异，接近目标值 |
+| 适用场景 | 文化变革，持续改进 | 复杂问题，系统优化 |
+
+两者互补：Kaizen 营造持续改进文化，Six-Sigma 解决深层复杂问题。
+
+## In DevOps Context
+DevOps 文化的四大支柱之一：Continuous Improvement (Kaizen)。实现方式：无责复盘（blameless post-mortems）、metrics驱动的瓶颈识别、混沌工程。
+
+## Connections
+- [[Lean]] — 共享消除浪费的核心价值观
+- [[Six-Sigma]] — 互补：渐进 vs 阶段
+- [[DevOpsCulture]] — DevOps 文化四大支柱之一
--- a/wiki/concepts/Lean.md
+++ b/wiki/concepts/Lean.md
@@ -0,0 +1,51 @@
+---
+title: "Lean"
+type: concept
+tags: [Process-Improvement, Six-Sigma, Workflow-Optimization]
+sources: [testing-workflow-optimizer]
+last_updated: 2026-04-21
+---
+
+# Lean
+
+精益制造/精益管理方法论，源于丰田生产系统（TPS），核心目标是通过消除一切形式的浪费（Muda），最大化客户价值。
+
+## Aliases
+- Lean Manufacturing
+- 精益生产
+- 丰田生产系统（TPS）
+
+## Definition
+Lean 通过识别和消除非增值活动（NVA），将价值流中的等待时间、搬运浪费、过度加工、库存过剩、不必要的移动、缺陷返工和过度生产降至最低。
+
+## Key Principles
+1. **价值（Value）**：从客户视角定义——客户愿意付费的转化活动
+2. **价值流（Value Stream）**：识别从原材料到交付的所有步骤，区分增值（VA）/价值赋能（VEA）/浪费（NVA）
+3. **流动（Flow）**：使增值步骤持续、不中断地运行
+4. **拉动（Pull）**：按客户实际需求而非预测来生产
+5. **完美（Perfection）**：持续追求零浪费状态
+
+## Three Types of Activities
+| 类别 | 说明 | 示例 |
+|------|------|------|
+| 增值活动（VA） | 客户愿意付费的转化 | 加工零件、填写表格 |
+| 价值赋能活动（VEA） | 不直接增值但必需的支撑活动 | 质量检查、设备维护 |
+| 浪费（NVA/Muda） | 消耗资源但不创造客户价值的活动 | 等待、搬运、返工 |
+
+## Seven Types of Waste (TIMWOODS)
+- **T**ransport（搬运）
+- **I**nventory（库存）
+- **M**otion（动作）
+- **W**aiting（等待）
+- **O**verproduction（过量生产）
+- **O**ver-processing（过度加工）
+- **S**kills underutilization（技能浪费）
+- **D**efects（缺陷/返工）
+
+## Connection to Six-Sigma
+Lean 关注速度（消除浪费），Six-Sigma 关注质量（减少变异）。两者的融合称为 **Lean Six-Sigma**，同时优化速度和精度。
+
+## Connections
+- [[Six-Sigma]] — 融合伙伴，速度+质量双优化
+- [[Kaizen]] — 互补：Kaizen 小步快跑，Lean 系统重构
+- [[Value-Stream-Mapping]] — 识别浪费的可视化工具
--- a/wiki/concepts/Six-Sigma.md
+++ b/wiki/concepts/Six-Sigma.md
@@ -0,0 +1,61 @@
+---
+title: "Six-Sigma"
+type: concept
+tags: [Process-Improvement, Statistical-Quality-Control, Lean]
+sources: [testing-workflow-optimizer]
+last_updated: 2026-04-21
+---
+
+# Six-Sigma
+
+六西格玛方法论，由摩托罗拉在 1986 年创立，通过统计分析减少流程变异和缺陷，目标将每百万机会的缺陷数（DPMO）降低至 3.4 以下（即六西格玛水平）。
+
+## Aliases
+- Six Sigma
+- 6σ
+
+## Core Goal
+**3.4 DPMO**（Defects Per Million Opportunities）——在考虑 1.5σ 漂移的情况下，六西格玛水平对应 99.99966% 的无缺陷率。
+
+## Two Core Methodologies
+
+### DMAIC（用于改进现有流程）
+1. **Define**（定义）——识别问题，确定项目范围和目标
+2. **Measure**（测量）——收集当前状态数据，建立基准
+3. **Analyze**（分析）——识别变异根本原因
+4. **Improve**（改进）——设计并实施解决方案
+5. **Control**（控制）——建立控制机制维持改进成果
+
+### DMADV / DFSS（用于设计新流程）
+1. **Define**（定义）——识别需求和项目目标
+2. **Measure**（测量）——测量 CTQ（关键质量特性）和风险
+3. **Analyze**（分析）——设计方案评估
+4. **Design**（设计）——详细设计
+5. **Verify**（验证）——验证设计满足需求
+
+## Belt System（人员资格体系）
+| 等级 | 职责 |
+|------|------|
+| White Belt | 基础概念理解，参与改进项目 |
+| Yellow Belt | 团队成员，理解 DMAIC，能使用基本工具 |
+| Green Belt | 项目领导者，60%+ 时间投入改进项目，精通统计分析 |
+| Black Belt | 专家领导者，100% 投入，精通高级统计分析，培训 Green Belt |
+| Master Black Belt | 战略级，培训和指导 Black Belt，组织方法论推广 |
+
+## Key Metrics
+- **DPMO**（Defects Per Million Opportunities）：每百万机会中的缺陷数
+- **Sigma Level**：流程能力等级（1σ ≈ 690,000 DPMO → 6σ ≈ 3.4 DPMO）
+- **Process Capability (Cp/Cpk)**：衡量流程满足规格的能力
+- **Cost of Poor Quality (COPQ)**：质量不良成本
+
+## Connection to Lean
+- Lean 关注消除浪费（速度），Six-Sigma 关注减少变异（质量）
+- **Lean Six-Sigma**：两者融合，同时优化速度和精度，是 [[testing-workflow-optimizer]] 的核心方法论之一
+
+## Relationship to Statistical-Process-Control
+Six-Sigma 的 Analyze 和 Control 阶段大量依赖统计过程控制（SPC）工具（控制图、过程能力分析、假设检验）
+
+## Connections
+- [[Lean]] — 融合伙伴，速度+质量双优化
+- [[Statistical-Process-Control]] — Six-Sigma 的统计分析基础
+- [[Kaizen]] — 互补：DMAIC 系统性改进 + Kaizen 渐进式持续改进
--- a/wiki/concepts/Statistical-Process-Control.md
+++ b/wiki/concepts/Statistical-Process-Control.md
@@ -0,0 +1,58 @@
+---
+title: "Statistical-Process-Control"
+type: concept
+tags: [Six-Sigma, Quality-Control, Data-Driven-Decision]
+sources: [testing-workflow-optimizer]
+last_updated: 2026-04-21
+---
+
+# Statistical-Process-Control
+
+统计过程控制（SPC）——使用统计方法（主要是控制图）监控过程稳定性，区分常见原因变异和特殊原因变异，使过程可控、可预测，并支持基于数据的持续改进决策。
+
+## Aliases
+- SPC
+- 统计过程控制
+- Statistical Quality Control (SQC)
+
+## Core Concept: Variation
+所有过程都存在变异，SPC 的核心是区分两类变异来源：
+
+| 变异类型 | 英文 | 来源 | 特征 | 处置 |
+|----------|------|------|------|------|
+| 常见原因变异 | Common Cause | 过程内在的正常随机波动 | 稳定、可预测 | 通过过程改进系统性减少 |
+| 特殊原因变异 | Special Cause | 特定外部因素导致 | 不稳定、不可预测 | 识别并消除根本原因 |
+
+**Gerald M. Weinberg 第一定律**：即使是最简单的系统，只要测量足够精确，就能观察到随机涨落；因此，变异永远存在，区分其来源是关键。
+
+## Control Charts（控制图）
+SPC 的核心工具，通过建立控制上限（UCL）和控制下限（LCL），监控过程是否处于统计控制状态。
+
+### Common Types
+- **X̄-R Chart**（均值-极差图）：监控连续数据的均值和变异
+- **X̄-S Chart**（均值-标准差图）：大样本（n>10）场景
+- **p Chart**（比率图）：监控不合格率等比例数据
+- **c Chart**（计数图）：监控缺陷数
+
+### Interpretation Rules（Western Electric Rules）
+- 1 点超出 UCL/LCL → 特殊原因，可能失控
+- 连续 9 点在中心线同一侧 → 过程漂移
+- 连续 6 点递增或递减 → 趋势
+- 连续 14 点交替上下 → 系统性周期变异
+
+## SPC in Six-Sigma
+SPC 是 [[Six-Sigma]] DMAIC 中 Analyze 和 Control 阶段的核心工具：
+- **Measure**：建立过程基线和控制图
+- **Analyze**：识别特殊原因变异
+- **Control**：维持改进后的稳定过程
+
+## In Workflow Optimization
+[[testing-workflow-optimizer]] 将 SPC 整合到四阶段工作流：
+- **现状分析**：使用控制图建立基线性能
+- **优化验证**：改进后通过 SPC 确认过程稳定性
+- **持续监控**：自动化监控异常信号
+
+## Connections
+- [[Six-Sigma]] — SPC 是 Six-Sigma 的核心工具
+- [[Lean]] — SPC 支撑 Lean 的数据驱动决策
+- [[Kaizen]] — SPC 发现的问题通过 Kaizen 活动改进
--- a/wiki/concepts/Value-Stream-Mapping.md
+++ b/wiki/concepts/Value-Stream-Mapping.md
@@ -0,0 +1,52 @@
+---
+title: "Value-Stream-Mapping"
+type: concept
+tags: [Lean, Process-Improvement, Workflow-Optimization]
+sources: [testing-workflow-optimizer, AgilePractices, devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
+last_updated: 2026-04-21
+---
+
+# Value-Stream-Mapping
+
+价值流映射（VSM）——一种精益可视化工具，用于绘制和分析产品或服务从原材料到交付客户的全流程中的所有步骤，区分增值时间与非增值等待时间，从而识别改进机会。
+
+## Aliases
+- VSM
+- Value Stream Map
+- 价值流图
+
+## Purpose
+将流程中的每个步骤按两大类时间进行量化：
+- **增值时间（Value-Adding Time, VA Time）**：客户愿意付费的实际转化时间
+- **非增值时间（Non-Value-Adding Time, NVA Time）**：等待、移动、搬运、检查等不创造客户价值的时间
+
+## Standard VSM Symbols
+| 符号 | 含义 |
+|------|------|
+| 矩形（Process Box） | 工序/步骤 |
+| 三角形（Triangle Inventory） | 库存/在制品 |
+| 推（Push Arrow） | 推式生产信号 |
+| 客户/供应商框 | 流程的输入和输出 |
+| 看板（Kaizen Burst） | 改进机会点 |
+| 看板（Kaizen Event） | 改善活动标识 |
+
+## Time Line（时间线）
+VSM 底部时间线计算：
+- **总生产时间（Total Lead Time, L/T）**：从开始到完成的日历时间
+- **增值时间（Value-Added Time, VA）**：实际加工时间
+- **增值比（VA Ratio）**：VA / L/T × 100%，典型值 5-10%，说明大量时间在等待
+
+## In DevOps Context
+价值流映射用于 DevOps 工作流优化：
+- **运营价值流（OVS, Operational Value Stream）**：面向客户的持续交付
+- **开发价值流（DVS, Development Value Stream）**：内部产品开发过程
+
+典型 DevOps VSM 分析结果：发现问题等待时间占 90%+，实际编码/构建/测试仅占 10%
+
+## Connection to Lean
+价值流映射是 [[Lean]] 的核心工具，用于识别 TIMWOODS 七类浪费的具体位置。
+
+## Connections
+- [[Lean]] — 核心分析工具
+- [[AgilePractices]] — Agile/DevOps 流程优化的核心工具
+- [[Kaizen]] — VSM 发现的问题通过 Kaizen 活动改进
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,10 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-25] [Performance Benchmarker Agent Personality](sources/testing-performance-benchmarker.md)
+- [2026-04-25] [Testing Reality Checker](sources/testing-reality-checker.md)
+- [2026-04-25] [Workflow Optimizer Agent Personality](sources/testing-workflow-optimizer.md)
+- [2026-04-25] [API Tester Agent Personality](sources/testing-api-tester.md)
 - [2026-04-25] [OpenCode Integration](sources/readme.md)
 - [2026-04-25] [OpenCode Integration](sources/readme.md)
 - [2026-04-25] [OpenCode Integration](sources/readme.md)
@@ -415,10 +419,6 @@
 - [2026-04-21] [testing-tool-evaluator](sources/testing-tool-evaluator.md) — (expected: wiki/sources/testing-tool-evaluator.md — source missing)
 - [2026-04-21] [testing-evidence-collector](sources/testing-evidence-collector.md) — (expected: wiki/sources/testing-evidence-collector.md — source missing)
 - [2026-04-21] [testing-test-results-analyzer](sources/testing-test-results-analyzer.md) — (expected: wiki/sources/testing-test-results-analyzer.md — source missing)
- [2026-04-21] [testing-performance-benchmarker](sources/testing-performance-benchmarker.md) — (expected: wiki/sources/testing-performance-benchmarker.md — source missing)
- [2026-04-21] [testing-reality-checker](sources/testing-reality-checker.md) — (expected: wiki/sources/testing-reality-checker.md — source missing)
- [2026-04-21] [testing-workflow-optimizer](sources/testing-workflow-optimizer.md) — (expected: wiki/sources/testing-workflow-optimizer.md — source missing)
- [2026-04-21] [testing-api-tester](sources/testing-api-tester.md) — (expected: wiki/sources/testing-api-tester.md — source missing)
 - [2026-04-20] [security](sources/security.md) — (expected: wiki/sources/security.md — source missing)
 - [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
 - [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
@@ -988,6 +988,7 @@
 - [Dependency-Management](concepts/Dependency-Management.md)
 - [Deployment-Automation](concepts/Deployment-Automation.md)
 - [Deployment-vs-Release](concepts/Deployment-vs-Release.md)
+- [Design-Thinking](concepts/Design-Thinking.md)
 - [Design-to-Code-Workflow](concepts/Design-to-Code-Workflow.md)
 - [DevOps-Maturity](concepts/DevOps-Maturity.md)
 - [DevOpsCulture](concepts/DevOpsCulture.md)
@@ -1083,6 +1084,7 @@
 - [Hosmer-Lemeshow-Test](concepts/Hosmer-Lemeshow-Test.md)
 - [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md)
 - [HTTPS自动化证书](concepts/HTTPS自动化证书.md)
+- [Human-Centered-Design](concepts/Human-Centered-Design.md)
 - [Human-Handoff](concepts/Human-Handoff.md)
 - [Hybrid-Cloud](concepts/Hybrid-Cloud.md)
 - [Hybrid-Search](concepts/Hybrid-Search.md)
@@ -1118,6 +1120,7 @@
 - [JFFS双清](concepts/JFFS双清.md)
 - [Jira-Gate](concepts/Jira-Gate.md)
 - [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md)
+- [Kaizen](concepts/Kaizen.md)
 - [Kanban](concepts/Kanban.md)
 - [Karpman-Drama-Triangle](concepts/Karpman-Drama-Triangle.md)
 - [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md)
@@ -1137,6 +1140,7 @@
 - [launchd](concepts/launchd.md)
 - [Layered-Configuration](concepts/Layered-Configuration.md)
 - [Lead-Time](concepts/Lead-Time.md)
+- [Lean](concepts/Lean.md)
 - [Learn-By-Building](concepts/Learn-By-Building.md)
 - [Left-over-Principle](concepts/Left-over-Principle.md)
 - [Link-Proposer](concepts/Link-Proposer.md)
@@ -1319,6 +1323,7 @@
 - [Shift-Right-Security](concepts/Shift-Right-Security.md)
 - [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md)
 - [Single-Control-Plane](concepts/Single-Control-Plane.md)
+- [Six-Sigma](concepts/Six-Sigma.md)
 - [SKAdNetwork](concepts/SKAdNetwork.md)
 - [SLS](concepts/SLS.md)
 - [SmartBidding](concepts/SmartBidding.md)
@@ -1341,6 +1346,7 @@
 - [Standard-Change](concepts/Standard-Change.md)
 - [STARFramework](concepts/STARFramework.md)
 - [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
+- [Statistical-Process-Control](concepts/Statistical-Process-Control.md)
 - [Strategic-Portfolio-Management](concepts/Strategic-Portfolio-Management.md)
 - [Streak-Tracking](concepts/Streak-Tracking.md)
 - [Stretched-Cluster](concepts/Stretched-Cluster.md)
@@ -1391,6 +1397,7 @@
 - [ULS](concepts/ULS.md)
 - [Unified-Inbox](concepts/Unified-Inbox.md)
 - [USER.md](concepts/USER.md.md)
+- [Value-Stream-Mapping](concepts/Value-Stream-Mapping.md)
 - [Variables-YAML](concepts/Variables-YAML.md)
 - [Vector-Embedding](concepts/Vector-Embedding.md)
 - [Vendor-Lock-In](concepts/Vendor-Lock-In.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,4 +1,38 @@
-## [2026-05-05] ingest | OpenCode Integration
+## [2026-05-05] ingest | Performance Benchmarker Agent Personality
+- Source file: Agent/agency-agents/testing/testing-performance-benchmarker.md
+- Status: ✅ 成功摄入
+- Summary: Performance Benchmarker——The Agency Testing 部门的性能测试与优化专家 Agent，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：量化一切可量化的，用数据证明优化价值。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。
+- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值）
+- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值）
+- Source page: wiki/sources/testing-performance-benchmarker.md
+- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-performance-benchmarker 段落。与 testing-reality-checker 的互补张力（指标量化 vs 用户感受）已在 Source Page Contradictions 节记录。
+
+## [2026-05-05] ingest | Testing Reality Checker Agent Personality
+- Source file: Agent/agency-agents/testing/testing-reality-checker.md
+- Status: ✅ 成功摄入
+- Summary: Testing Reality Checker——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。默认"NEEDS WORK"，强制三步验证流程（Reality Check 命令 → QA 交叉验证 → 端到端截图分析）。C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。
+- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值）
+- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值）
+- Source page: wiki/sources/testing-reality-checker.md
+- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-reality-checker 段落。与 testing-workflow-optimizer 的潜在张力（效率 vs 真实性）和与 testing-api-tester 的互补关系（截图 vs 接口）已在 Source Page Contradictions 节记录。
+
+## [2026-05-05] ingest | Workflow Optimizer Agent Personality
+- Source file: Agent/agency-agents/testing/testing-workflow-optimizer.md
+- Status: ✅ 成功摄入
+- Summary: Workflow Optimizer——The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：找到瓶颈，修复流程，其余自动化。四阶段工作流（现状分析→优化设计→实施规划→自动化执行），融合 Lean/Six Sigma/Kaizen/统计过程控制/变更管理/人本设计六大方法论体系。核心交付物：WorkflowOptimizer Python 框架。成功指标：40% 周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。
+- Concepts created: [[Lean]], [[Six-Sigma]], [[Kaizen]], [[Value-Stream-Mapping]], [[Statistical-Process-Control]], [[Human-Centered-Design]], [[Design-Thinking]]（共 7 个，其中 Change-Management 已存在）
+- Entities created: 无（The Agency 已在 entities/ 中存在；各工具仅出现 1 次，不满足 ≥2 次创建阈值）
+- Source page: wiki/sources/testing-workflow-optimizer.md
+- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-workflow-optimizer 段落；7 个新 Concept 页面已创建并添加到 index.md。与 specialized-workflow-architect（设计与执行的分层关系）和 product-behavioral-nudge-engine（自动化 vs 人机交互互补张力）已在 Source Page Contradictions 节记录。
+
+## [2026-05-05] ingest | API Tester Agent Personality
+- Source file: Agent/agency-agents/testing/testing-api-tester.md
+- Status: ✅ 成功摄入
+- Summary: API Tester Agent——The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架。核心理念"Breaks your API before your users do"，通过 Playwright/REST Assured/k6 框架实现 95%+ API 端点覆盖率，CI/CD 流水线集成，性能 SLA（95p < 200ms、10x 负载、< 0.1% 错误率），OWASP API Security Top 10 安全验证。
+- Concepts created: 无（API Testing、Performance Testing、Security Testing、Contract Testing、CI/CD Integration、OWASP API Security Top 10 等概念均已在本文档出现，未达独立创建阈值）
+- Entities created: 无（Playwright、REST Assured、k6、perf_hooks 等工具均仅在本文档出现，未达创建阈值）
+- Source page: wiki/sources/testing-api-tester.md
+- Notes: 无内容冲突。index.md 和 overview.md 已更新。新增 Testing 部门 section 到 overview.md。
 - Source file: Agent/agency-agents/integrations/opencode/README.md
 - Status: ✅ 成功摄入
 - Summary: OpenCode Integration——The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案，通过 `./scripts/install.sh --tool opencode` 安装，将 .md 格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 格式。核心机制：`mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不在 Tab 循环中占位；命名颜色自动映射为十六进制颜色代码。支持项目级和全局级两种安装范围。与 [[readme|Cursor Integration]]（.mdc）、[[github-copilot|GitHub Copilot Integration]]、[[windsurf-integration|Windsurf Integration]] 同属 The Agency 多 IDE 集成生态。
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -92,6 +92,17 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)

 **[[Project-Management-Experiment-Tracker]]**（Experiment Tracker）：实验追踪与数据驱动决策专家 Agent——The Agency 项目管理部门的实验管理专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心职责：设计统计有效的 A/B 测试和多变量实验（默认 95% 置信度）、管理实验 Portfolio 组合（每季度 15+ 实验）、执行统计功效分析确定所需样本量、实施渐进放量与安全监控。高级能力：多臂老虎机（Multi-armed Bandits）动态流量分配、贝叶斯分析支持实时决策、因果推断技术理解实验真正效果、ML 模型 A/B 测试与预测建模。典型交付物：实验设计文档模板（假设/设计/风险评估/实施计划）、实验结果报告模板（统计结果/置信区间/业务影响/决策建议）。成功指标：95% 实验达统计显著性、70% 实验成功率、80% 成功实验实现落地。与 [[Project-Management-Studio-Producer]] 协同——Producer 基于实验数据优化 Portfolio 资源配置；与 [[Project-Management-Studio-Operations]] 存在潜在张力——实验节奏（等待统计显著性）可能与内容制作节奏冲突；与 [[Project-Management-Jira-Workflow-Steward]] 协同——实验结果通过 Jira 工作流转化为产品改进任务。属 Agency 项目管理体系中的实验验证层级，补充了从战略规划→任务分解→实验验证→流程治理的完整闭环。

+### The Agency — Testing 部门
+|The Agency 的 Testing 部门涵盖 API 测试、可访问性审计、工具评估、证据收集、结果分析、性能基准、真实性检验、工作流优化等专业测试 Agent，覆盖从功能到安全到性能的全方位质量保障。|
+
+**[[testing-api-tester]]**（API Tester）：API 测试与验证专家 Agent——The Agency Testing 部门的核心 API 质量保障专家，专注于全面的 API 功能验证、性能测试和安全审计。核心理念：**Breaks your API before your users do**——防御性测试哲学，主动发现潜在问题。核心能力：Playwright/REST Assured/k6 自动化测试框架、95%+ API 端点覆盖率目标、CI/CD 流水线集成。性能 SLA：95 百分位响应时间 < 200ms、10x 正常负载验证、错误率 < 0.1%。安全测试覆盖 OWASP API Security Top 10（认证绕过/SQL 注入/XSS/速率限制等）。与 [[specialized-model-qa]] 互补——后者测试 ML 模型质量，前者测试 API 端点行为；与 [[multi-agent-system-reliability]] 协同——系统可靠性依赖 API 质量验证。
+
+**[[testing-workflow-optimizer]]**（Workflow Optimizer）：流程优化与工作流自动化专家 Agent——The Agency Testing 部门的核心流程改进专家，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：**找到瓶颈，修复流程，其余自动化**。核心方法：四阶段工作流（现状分析与文档化→优化设计与未来状态规划→实施规划与变更管理→自动化实现与监控）+ 数据驱动决策框架（测量→验证→文档化）。方法论融合：Lean（消除浪费）/Six Sigma（DMAIC 减少变异）/Kaizen（持续改进）/统计过程控制。人本设计原则：在追求效率的同时平衡员工满意度与认知负荷，在自动化效率与人类判断创造力之间取得平衡。核心交付物：WorkflowOptimizer Python 框架（含瓶颈识别/自动化潜力评估/ROI 计算/实施路线图生成）。成功指标：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程相关错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。与 [[specialized-workflow-architect]] 互补——后者负责工作流设计建模（穷举路径/状态树），前者负责工作流实施改进（量化效率收益/自动化 ROI），属于设计与执行的分层关系。与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在互补张力：Workflow Optimizer 追求最大化自动化，Nudge Engine 追求最大化员工参与，两者共同构成效率与人本的双轮驱动。
+
+**[[testing-reality-checker]]**（Reality Checker）：截图驱动型生产就绪认证 Agent——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。核心理念：**默认"NEEDS WORK"，以截图证据截断虚假乐观评估**。核心方法：三步强制流程（Reality Check 命令验证实际构建 → QA 交叉验证自动化证据 → 端到端截图分析用户旅程）+ 硬性失败触发器（完美评分/无证据声明/声称奢华但实为基础实现/规格未落地）。默认状态：NEEDS WORK；C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。与 [[testing-workflow-optimizer]] 存在张力：Optimizer 追求效率（目标 60% 自动化率），Reality Checker 追求真实性（要求每轮修订充分证据），在修订周期数量上可能存在分歧；与 [[testing-api-tester]] 互补——API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图，两者共同构成前后端双重质量门控。与 [[Agents-Orchestrator]] 协同——作为多智能体流水线的最终质量门控。
+
+**[[testing-performance-benchmarker]]**（Performance Benchmarker）：性能测试与优化专家 Agent——The Agency Testing 部门的性能工程专家，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：**量化一切可量化的，用数据证明优化价值**。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。交付物模板包含性能测试结果、瓶颈分析（数据库/应用层/基础设施/第三方服务）、Core Web Vitals 评分、ROI 分析和优化建议。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。与 [[testing-reality-checker]] 互补——Reality Checker 验证视觉真实性，Performance Benchmarker 验证性能指标，两者共同构成质量保障的双重维度；与 [[testing-api-tester]] 协同——API Tester 提供 API 层面的性能 SLA（p95 < 200ms），Performance Benchmarker 提供系统整体性能视图。
+
 ### The Agency — Paid Media 部门
 The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。

--- a/wiki/sources/testing-api-tester.md
+++ b/wiki/sources/testing-api-tester.md
@@ -0,0 +1,52 @@
+---
+title: "API Tester Agent Personality"
+type: source
+tags: ["the-agency", "testing", "api", "automation", "qa", "performance", "security"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-api-tester.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架
+- 问题域：API 质量保障缺乏系统性方法论、测试覆盖不足、安全漏洞遗漏、性能 SLA 不达标等现实问题
+- 方法/机制：Playwright 测试框架 + perf_hooks 性能监控 + OWASP API Security Top 10 安全验证 + CI/CD 流水线集成 + 95%+ 覆盖率目标驱动
+- 结论/价值：为 The Agency 提供标准化的 API 测试智能体规范，通过自动化测试套件实现功能验证、性能基准、安全审计的三位一体质量保障
+
+## Key Claims（用中文描述）
+- API Tester Agent 通过 Playwright/REST Assured/k6 框架构建自动化测试套件，目标实现 95%+ API 端点覆盖率
+- API 性能 SLA 要求：95 百分位响应时间低于 200ms，正常负载下错误率低于 0.1%
+- 负载测试必须验证 10 倍正常流量容量，确保系统可扩展性
+- 安全测试覆盖 OWASP API Security Top 10，包含认证绕过、SQL 注入、XSS、速率限制等关键威胁
+- API 测试必须集成到 CI/CD 流水线，实现持续验证而非手动测试
+
+## Key Quotes
+> "Breaks your API before your users do." — API Tester Agent 的核心理念，防御性测试哲学
+> "API response times must be under 200ms for 95th percentile" — 明确的性能 SLA 标准
+> "Always test authentication and authorization mechanisms thoroughly" — 安全优先原则
+> "Load testing must validate 10x normal traffic capacity" — 规模化验证要求
+
+## Key Concepts
+- [[API Testing]]：覆盖功能、性能、安全三维度，通过自动化测试框架验证 API 端点行为与 SLA 合规性
+- [[Performance Testing]]：通过 perf_hooks 监控响应时间，验证 95 百分位 < 200ms、10x 负载、< 0.1% 错误率三大指标
+- [[Security Testing]]：OWASP API Security Top 10 安全测试框架，包含认证/授权/输入验证/速率限制等核心检查项
+- [[Contract Testing]]：API 版本间契约合规性与向后兼容性验证，确保服务间接口稳定性
+- [[CI/CD Integration]]：测试自动化嵌入持续集成/持续部署流水线，实现每次代码变更的自动质量验证
+- [[OWASP API Security Top 10]]：API 安全测试的行业标准清单，覆盖 BOLA/ BFLA/ Broken Auth 等关键 API 威胁
+
+## Key Entities
+- [[Playwright]]：Node.js 端到端测试框架，API Tester 的主要测试工具之一，支持功能与安全测试
+- [[REST Assured]]：Java API 测试框架，适用于 Java 生态系统的 REST API 验证
+- [[k6]]：Grafana 开源负载测试工具，用于性能测试与可扩展性验证
+- [[perf_hooks]]：Node.js 内置性能监测 API，用于精确的 API 响应时间测量
+
+## Connections
+- [[specialized-model-qa]] ← 测试范围互补 ← [[testing-api-tester]]（模型质量测试 vs API 端点测试）
+- [[testing-accessibility-auditor]] ← 质量保障并行 ← [[testing-api-tester]]（可访问性测试 vs API 功能/性能/安全测试）
+- [[testing-tool-evaluator]] ← 工具推荐上游 ← [[testing-api-tester]]（工具评估为测试实施提供框架选择）
+- [[specialized-mcp-builder]] ← 技术栈关联 ← [[testing-api-tester]]（MCP 服务器构建需要 API 测试能力保障）
+- [[multi-agent-system-reliability]] ← 质量保障基础 ← [[testing-api-tester]]（系统可靠性依赖 API 质量验证）
+
+## Contradictions
+- 暂无冲突内容
--- a/wiki/sources/testing-performance-benchmarker.md
+++ b/wiki/sources/testing-performance-benchmarker.md
@@ -0,0 +1,53 @@
+---
+title: "Performance Benchmarker Agent Personality"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-performance-benchmarker.md]]
+
+## Summary（用中文描述）
+- 核心主题：性能测试与优化专家 Agent，专注于测量、分析和改进跨应用程序和基础设施的系统性能
+- 问题域：性能基线建立、负载/压力测试、Web Vitals 优化、容量规划、可扩展性评估
+- 方法/机制：使用 k6 编写综合性能测试套件，统计置信区间分析，Core Web Vitals 监控，性能回归测试
+- 结论/价值：数据驱动的方法论，通过量化指标证明性能改进，确保系统满足 SLA 要求
+
+## Key Claims（用中文描述）
+- Performance Benchmarker Agent 通过系统性性能测试确保所有系统以 95% 置信度满足性能 SLA
+- 通过 Core Web Vitals 优化（LLC < 2.5s、FID < 100ms、CLS < 0.1）提升用户体验
+- 通过查询优化可将第95百分位响应时间从 850ms 降至 180ms
+- 通过性能监控可预防 90% 的性能相关事故
+
+## Key Quotes
+> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化效果量化
+
+> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 性能与业务影响关联
+
+> "Always establish baseline performance before optimization attempts" — 性能优化的首要原则
+
+## Key Concepts
+- [[LoadTesting]]：模拟正常和峰值负载，验证系统在预期条件下的性能表现
+- [[StressTesting]]：逐步增加负载直到系统崩溃，找出性能临界点和恢复行为
+- [[CoreWebVitals]]：Google 定义的页面用户体验核心指标（LCP、FID、CLS）
+- [[RealUserMonitoring]]：基于真实用户数据的性能监控，对抗合成测试的局限性
+- [[CapacityPlanning]]：基于增长预测和使用模式预测资源需求
+- [[ConfidenceIntervals]]：统计置信区间用于可靠的性能测量
+
+## Key Entities
+- [[TestingRealityChecker]]：测试现实核查 Agent，与 Performance Benchmarker 协同工作
+- [[TestingApiTester]]：API 测试专家 Agent，共同构成全面测试体系
+- [[WorkflowOptimizerAgent]]：工作流优化 Agent，通过性能优化提升工作流效率
+
+## Connections
+- [[TestingRealityChecker]] ← complements ← [[TestingPerformanceBenchmarker]]
+- [[TestingApiTester]] ← extends ← [[TestingPerformanceBenchmarker]]
+- [[WorkflowOptimizerAgent]] ← depends_on ← [[TestingPerformanceBenchmarker]]
+
+## Contradictions
+- 与 [[TestingRealityChecker]] 的视角差异：
+  - 冲突点：Reality Checker 强调"真实用户感受"，Performance Benchmarker 强调"量化指标"
+  - 当前观点：量化指标（p95 < 500ms）是性能优化的客观标准
+  - 对方观点：用户主观感受比指标更重要，指标可能具有欺骗性
+  - 调和：两者互补——指标指导优化方向，用户体验验证优化效果
--- a/wiki/sources/testing-reality-checker.md
+++ b/wiki/sources/testing-reality-checker.md
@@ -0,0 +1,52 @@
+---
+title: "Testing Reality Checker"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-reality-checker.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的 Reality Checker Agent——通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。
+- 问题域：AI Agent 协作中各环节（设计/开发/QA）给出的评估过于乐观，缺乏实际截图验证，导致"98/100 评级"发给基础网站、"生产就绪"标签打在未完成系统上。
+- 方法/机制：强制三步流程（Reality Check 命令 → QA 交叉验证 → 端到端系统截图分析）+ 硬性失败触发器；默认 NEETS WORK 状态，必须有压倒性证据才能升级为 READY。
+- 结论/价值：第一次实现通常需要 2-3 轮修订；C+/B- 评级属正常；只有真实截图证据才能支撑"生产就绪"声明。
+
+## Key Claims（用中文描述）
+- Testing Reality Checker Agent 作为最后一道防线，通过截图证据截断"幻想型认证"，要求压倒性视觉证明。
+- 所有系统声明需要视觉证明（自动化截图），规格说明需要对照实际实现进行交叉验证。
+- 完整的用户旅程测试需要截图证据；性能数据（加载时间、错误率）必须来自 test-results.json。
+- 默认"NEEDS WORK"状态，除非有压倒性证据支持"READY"。
+
+## Key Quotes
+> "You're the last line of defense against unrealistic assessments" — Testing Reality Checker Agent 自我定位
+> "Default to 'NEEDS WORK' status unless proven otherwise" — 核心认证原则
+> "First implementations typically need 2-3 revision cycles, C+/B- ratings are normal" — 现实质量预期
+> "Trust evidence over claims" — 质量认证核心方法论
+
+## Key Concepts
+- [[End-to-End Testing]]：完整用户旅程截图分析（桌面/平板/手机 × 交互前/后对比）
+- [[Evidence-Based Certification]]：以自动化截图 + test-results.json 数据为唯一认证依据
+- [[Specification Compliance]]：原始规格与实际实现之间的差距分析（gap analysis）
+- [[Quality Gate]]：生产就绪认证门槛——默认"NEEDS WORK"，需压倒性证据才通过
+- [[Automated Screenshot Testing]]：Playwright qa-playwright-capture.sh 自动化截图捕获
+
+## Key Entities
+- Testing Reality Checker Agent：The Agency Testing 部门角色——截图驱动的生产就绪认证 Agent
+- QA Agent：前序 QA 测试环节，提供自动化测试发现和证据
+- Integration Agent：RealityIntegration——Reality Checker 的执行主体
+- [[testing-workflow-optimizer]]：工作流优化 Agent，为 Reality Checker 提供优化流程建议
+- [[testing-api-tester]]：API 测试 Agent，提供后端接口层面的测试证据
+
+## Connections
+- [[testing-workflow-optimizer]] ← workflow integration ← [[testing-reality-checker]]
+- [[testing-api-tester]] ← evidence source ← [[testing-reality-checker]]
+- [[testing-accessibility-auditor]] ← cross-validation ← [[testing-reality-checker]]
+- [[testing-evidence-collector]] ← provides screenshots ← [[testing-reality-checker]]
+- [[testing-reality-checker]] ← final gate ← [[agents-orchestrator]]
+
+## Contradictions
+- 与 [[testing-workflow-optimizer]] 潜在张力：Workflow Optimizer 追求流程效率（目标：75% 流程错误减少），Reality Checker 追求真实性（默认"需要工作"），两者在修订周期数量上可能存在分歧——Optimizer 希望快速迭代，Checker 要求充分证据
+- 与 [[testing-api-tester]] 的互补关系：API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图；两者共同构成前后端双重质量门控
--- a/wiki/sources/testing-workflow-optimizer.md
+++ b/wiki/sources/testing-workflow-optimizer.md
@@ -0,0 +1,56 @@
+---
+title: "Workflow Optimizer Agent Personality"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-workflow-optimizer.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论，专注于端到端业务流程的分析、重设计、自动化与持续改进。
+- 问题域：工作流效率瓶颈识别、跨部门流程孤岛、人工重复性任务、流程质量与员工满意度的平衡。
+- 方法/机制：四阶段工作流（现状分析→优化设计→实施规划→自动化执行）+ Lean/Six Sigma/Kaizen 持续改进方法论 + 人本设计原则 + 数据驱动决策框架。核心工具：WorkflowOptimizer Python 框架（含瓶颈识别、优化机会评分、ROI 计算、实施路线图生成）。
+- 结论/价值：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。
+
+## Key Claims（用中文描述）
+- Workflow Optimizer Agent 通过系统分析消除效率瓶颈、流线化流程、实施智能化自动化解决方案，提升生产力、质量和员工满意度。
+- 每个流程优化必须包含自动化机会和可量化改进指标。
+- 在实施变更前必须测量当前状态性能，并使用统计分析验证改进有效性。
+- 优先考虑用户/员工体验和满意度，同时在自动化效率与人类判断和创造力之间取得平衡。
+
+## Key Quotes
+> "Finds the bottleneck, fixes the process, automates the rest." — Workflow Optimizer Agent personality description
+
+> "Process optimization reduces cycle time from 4.2 days to 1.8 days (57% improvement)" — communication style example
+
+> "Automation eliminates 15 hours/week of manual work, saving $39K annually" — communication style example
+
+## Key Concepts
+- [[Lean]]：精益方法论，识别三类活动（增值活动/价值赋能活动/浪费），追求消除一切不增值环节。
+- [[Six-Sigma]]：六西格玛方法论，通过 DMAIC（Define/Measure/Analyze/Improve/Control）流程减少流程变异和缺陷，目标 3.4 DPMO。
+- [[Kaizen]]：持续改进哲学，小步快跑、员工驱动的渐进式流程优化，与六西格玛形成互补。
+- [[Value-Stream-Mapping]]：价值流映射，识别流程中的增值时间 vs 非增值等待时间。
+- [[Statistical-Process-Control]]：统计过程控制，通过数据监控过程稳定性并预测性能。
+- [[Change-Management]]：变更管理，确保流程改进被团队接受并成功落地的策略框架。
+- [[Human-Centered-Design]]：人本设计，优先考虑用户/员工体验、认知负荷和可访问性。
+
+## Key Entities
+- [[The-Agency]]：Testing 部门的 Workflow Optimizer Agent 所属组织。
+
+## Connections
+- [[testing-api-tester]] ← 协同质量保障 ← [[testing-workflow-optimizer]]（流程优化后需要 API 测试验证自动化后的系统行为）
+- [[specialized-workflow-architect]] ← 共享方法论 ← [[testing-workflow-optimizer]]（两者均关注工作流设计与优化，但前者侧重设计建模，后者侧重实施改进）
+- [[product-sprint-prioritizer]] ← 协同优先级排序 ← [[testing-workflow-optimizer]]（流程优化实施需要与 Sprint 规划对齐）
+- [[specialized-model-qa]] ← 协同数据验证 ← [[testing-workflow-optimizer]]（六西格玛等统计方法与 Model QA 的量化验证方法相互补充）
+
+## Contradictions
+- 与 [[specialized-workflow-architect]] 存在职责边界张力：
+  - 冲突点：两者均涉及工作流分析，但 Workflow Architect 强调设计规范（穷举所有路径/状态树），Workflow Optimizer 强调实施改进（量化效率收益/自动化 ROI）。
+  - 当前观点：Workflow Architect 负责"如何设计"（设计层），Workflow Optimizer 负责"如何改进"（执行层），属于工作流生命周期的不同阶段。
+  - 对方观点：部分场景下两者可互换使用，职责边界模糊。
+- 与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在理念张力：
+  - 冲突点：Workflow Optimizer 追求最大化自动化（减少人工干预），Nudge Engine 追求最大化人类参与（微任务/游戏化驱动）。
+  - 当前观点：两者互补——工作流层面追求自动化，用户/员工层面保留适度的人机交互以维护满意度。
+  - 对方观点：过度自动化可能降低员工参与感和学习机会。