名称: kaizen 描述: 面向制造的持续改进技能，用于fabrikIQ。实现精益制造原则（5 Whys、Ishikawa图、PDCA循环），用于系统问题解决和质量改进。在Bug分析、重构、代码审查、生产事件中激活。 触发器:
- /why
- /cause-and-effect
- /plan-do-check-act
- /kaizen
Kaizen - 持续改进技能
这个技能将经过验证的精益制造方法引入软件开发。专为fabrikIQ设计，适用于任何TypeScript/React项目。
Kaizen的4大支柱
1. 持续改进 (Kaizen)
小而渐进的改变，而非大规模重构。
原则: 每次提交都应使代码比之前稍好一些。
// 之前: 计划大规模重构
// "我快速重构整个认证逻辑"
// KAIZEN: 小步骤
// 提交 1: 从auth.ts提取validateToken()
// 提交 2: 为TokenPayload添加类型
// 提交 3: 用unknown + 类型守卫替换any
// 提交 4: 为validateToken()编写单元测试
2. Poka-Yoke（防错法）
通过设计防止错误，而非依赖纪律。
TypeScript约束:
// 错误: 运行时检查（可能出错）
function processOrder(status: string) {
if (status !== 'pending' && status !== 'approved') {
throw new Error('Invalid status');
}
}
// POKA-YOKE: 编译时约束（不可能出错）
type OrderStatus = 'pending' | 'approved' | 'shipped' | 'cancelled';
function processOrder(status: OrderStatus) {
// TypeScript防止无效值
}
快速失败模式:
// 错误: 延迟错误检测
async function analyzeData(file: File) {
const data = await parseFile(file); // 10秒
const result = await geminiAnalyze(data); // 30秒
if (!data.hasRequiredColumns()) { // 40秒后才发现错误！
throw new Error('Missing columns');
}
}
// POKA-YOKE: 快速失败（早期验证）
async function analyzeData(file: File) {
// 先验证（< 1毫秒）
const preview = await parseFilePreview(file, 10);
if (!preview.hasRequiredColumns()) {
throw new Error('Missing columns'); // 立即！
}
// 仅在有效时执行昂贵操作
const data = await parseFile(file);
const result = await geminiAnalyze(data);
}
3. 标准化工作
一致的模板减少认知负担和错误。
API响应模式（fabrikIQ标准）:
// 标准响应格式
interface ApiResponse<T> {
success: boolean;
data?: T;
error?: {
code: string;
message: string;
details?: unknown;
};
meta?: {
timestamp: string;
duration_ms: number;
region: 'fra1'; // DSGVO
};
}
// 所有端点使用此格式
export async function handler(req: Request): Promise<Response> {
const start = Date.now();
try {
const result = await processRequest(req);
return Response.json({
success: true,
data: result,
meta: {
timestamp: new Date().toISOString(),
duration_ms: Date.now() - start,
region: 'fra1'
}
});
} catch (error) {
return Response.json({
success: false,
error: {
code: error.code ?? 'UNKNOWN_ERROR',
message: error.message
}
}, { status: error.status ?? 500 });
}
}
4. 准时制 (YAGNI)
只实现当前需要的东西。
// 错误: "也许我们以后需要"
interface User {
id: string;
email: string;
name: string;
// "为以后准备"
avatar?: string;
preferences?: UserPreferences;
notifications?: NotificationSettings;
integrations?: ExternalIntegrations;
analytics?: UserAnalytics;
}
// YAGNI: 仅当前需求
interface User {
id: string;
email: string;
name: string;
}
// 当实际需要时扩展（使用单独的提交）
命令
/why - 5-Whys根因分析
触发器: /why, 5 whys, root cause, warum passiert
应用: 用于Bug、生产事件、重复问题
工作流程:
-
定义问题（具体、可测量）
问题: SECOM数据集API超时（60秒后504） -
问5次“为什么？”
为什么1: 为什么超时？ → Gemini API响应时间超过60秒 为什么2: 为什么超过60秒？ → 提示包含590列 x 1567行 为什么3: 为什么这么多数据？ → 未实现列采样 为什么4: 为什么没有采样？ → 最初只预期小CSV文件 为什么5: 为什么没调整？ → 缺少大文件的自动性能测试 -
识别根因
根因: 缺少大型数据集的性能测试覆盖 -
定义对策
措施1: 实现列采样（MAX_COLUMNS = 50） 措施2: 在CI/CD中添加SECOM性能测试 措施3: 设置超时监控和告警
输出格式:
## 5-Whys分析
**问题**: [具体描述]
**日期**: [ISO-8601]
**受影响组件**: [文件/服务]
### 分析
| 级别 | 问题 | 答案 |
|-------|-------|---------|
| 为什么1 | 为什么[症状]？ | [答案] |
| 为什么2 | 为什么[答案1]？ | [答案] |
| 为什么3 | 为什么[答案2]？ | [答案] |
| 为什么4 | 为什么[答案3]？ | [答案] |
| 为什么5 | 为什么[答案4]？ | [答案] |
### 根因
[一句话描述核心原因]
### 对策
1. **立即**（< 1天）: [快速修复]
2. **短期**（< 1周）: [结构性解决方案]
3. **长期**（< 1月）: [预防措施]
/cause-and-effect - Ishikawa图
触发器: /cause-and-effect, /ishikawa, /fishbone, ursache-wirkung
应用: 用于具有多个可能原因的复杂问题
6M类别（制造）:
- 人 (People): 技能、培训、沟通
- 机 (Machine): 硬件、工具、基础设施
- 料 (Material): 输入数据、依赖项
- 法 (Method): 流程、工作流、模式
- 测 (Measurement): 监控、测试、指标
- 环 (Environment): 生产、暂存、本地
工作流程:
-
定义效果（右侧）
效果: 登录间歇性失败 -
按类别收集原因
人: ├── 用户手动删除Cookies └── 管理员更改Session-TTL未沟通 机: ├── Vercel冷启动时间 > Session检查 └── KV存储延迟峰值 料: ├── JWT密钥轮换不同步 └── OAuth令牌过期 法: ├── Session验证无重试 └── 无优雅降级 测: ├── 无登录成功率指标 └── 无认证错误告警 环: ├── 生产与预览环境使用不同KV └── 本地开发无真实认证 -
优先排序最可能原因
-
计划验证（测试假设）
输出格式:
┌─────────────────────────────────────────────────────┐
│ │
┌───────────┐ │ ┌───────────┐ ┌───────────┐ │
│ 人 │───┼───│ 机 │ │ 料 │────────────────┤
└───────────┘ │ └───────────┘ └───────────┘ │
│ │ │ │ │
┌────┴────┐ │ ┌────┴────┐ ┌────┴────┐ ▼
│ Cookies │ │ │ 冷启动 │ │ JWT │ ┌──────────────┐
│ 被删除 │ │ │ │ │ 轮换 │ │ 登录 │
└─────────┘ │ └─────────┘ └─────────┘ │ 失败 │
│ └──────────────┘
┌───────────┐ │ ┌───────────┐ ┌───────────┐ │
│ 法 │───┼───│ 测 │ │ 环 │────────────────┤
└───────────┘ │ └───────────┘ └───────────┘ │
│ │ │ │ │
┌────┴────┐ │ ┌────┴────┐ ┌────┴────┐ │
│ 无重试 │ │ │ 无告警 │ │ 生产vs │ │
│ │ │ │ │ │ 预览 │ │
└─────────┘ │ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────┘
## 优先假设
| # | 类别 | 原因 | 概率 | 验证方法 |
|---|-----------|---------|-------------------|-------------|
| 1 | 机 | 冷启动 | 高 | 检查“首次请求”日志 |
| 2 | 料 | JWT轮换 | 中 | 检查密钥更改历史 |
| 3 | 法 | 无重试 | 中 | 实现重试逻辑并测量 |
/plan-do-check-act - PDCA循环
触发器: /pdca, /plan-do-check-act, deming cycle, verbesserungszyklus
应用: 用于功能实现、重构、流程改进
工作流程:
┌─────────────────────┐
│ │
│ ┌─────┐ ───────► ┌─────┐
│ │计划 │ │ 执行 │
│ └─────┘ ◄─────── └─────┘
│ ▲ │
│ │ ▼
│ ┌─────┐ ┌─────┐
│ │ 行动 │ ◄─────── │检查 │
│ └─────┘ └─────┘
│ │
└─────────────────────┘
(迭代)
阶段1: 计划
- 定义目标（SMART：具体、可测量、可达成、相关、时限）
- 制定假设
- 设定成功标准
- 识别风险
## 计划
**目标**: API响应时间 < 10秒，95%请求（当前：30秒）
**截止日期**: 2025-01-15
**假设**: 列采样至50列减少Token数80%
**成功标准**:
- [ ] P95延迟 < 10秒
- [ ] 分析输出无质量损失
- [ ] SECOM数据集无超时
**风险**:
- 采样可能遗漏重要列
- 用户期望分析中所有列
阶段2: 执行
- 小步骤实现
- 实施期间文档化
- 隔离更改（功能分支）
## 执行
**分支**: feature/column-sampling
**提交**:
1. `feat: 添加MAX_COLUMNS常量（50）`
2. `feat: 在fileParser中实现列采样`
3. `test: 添加SECOM采样测试`
4. `docs: 更新AGENTS.md包含采样详情`
**笔记**:
- 取前50列（按字母顺序）
- 待办：更智能算法（基于方差）
阶段3: 检查
- 测量结果与成功标准对比
- 记录意外副作用
- 收集经验教训
## 检查
**测量**:
| 指标 | 目标 | 实际 | 状态 |
|--------|------|-----|--------|
| P95延迟 | < 10秒 | 8.2秒 | 通过 |
| SECOM超时 | 0 | 0 | 通过 |
| 分析质量 | 无回归 | 轻微下降 | 警告 |
**观察**:
- 质量略有下降（缺失相关性）
- 前50列非最优（多NaN列）
**经验教训**:
- 按字母顺序选择次优
- 基于方差的選擇会找到更好列
阶段4: 行动
- 决定：标准化或迭代？
- 基于学习调整流程
- 计划下一个PDCA循环
## 行动
**决定**: 迭代（非标准化）
**下一循环改进**:
1. 实现基于方差的列选择
2. 收集用户对分析质量的反馈
3. A/B测试：50列 vs 75列
**下一个PDCA循环**:
- 开始: 2025-01-16
- 焦点: 智能列选择算法
与fabrikIQ集成
何时使用哪个命令？
| 情况 | 命令 | 理由 |
|---|---|---|
| 生产Bug | /why |
快速根因分析 |
| 复杂Bug，多因素 | /cause-and-effect |
结构化原因收集 |
| 新功能规划 | /plan-do-check-act |
迭代实现 |
| 重构 | /plan-do-check-act |
可测量的改进 |
| 重复错误 | /why 然后 /cause-and-effect |
组合分析 |
自动触发器
此技能在以下情况自动激活：
git log带模式 “fix:” 或 “hotfix:”- Vercel部署失败
- CI/CD中测试失败
- 关键词：“bug”、“fehler”、“timeout”、“crash”、“regression”
质量门集成
每个PDCA循环后：
npx tsc --noEmit # TypeScript检查
npm run build # 构建
npm run test # 单元测试
npm run test:e2e # E2E（可选）
代码更改前检查清单
- [ ] 持续改进: 更改是否渐进？（每次提交最多1个功能）
- [ ] Poka-Yoke: 错误是否通过类型预防？（在可能时使用编译时而非运行时验证）
- [ ] 标准化工作: 代码是否遵循既定模式？（API响应格式、错误处理）
- [ ] 准时制: 是否只实现当前所需？（无“为以后准备”）
文档
每次分析后：
- 结果保存到
docs/kaizen/ - 提交消息带Kaizen引用：
fix: 解决超时（5-Whys #12） - 经验教训记录在CHANGELOG.md
资源
为fabrikIQ开发 - 制造智能平台 DSGVO合规 | 区域 fra1 | Dresden AI Insights