self-evolving-loop

让AI具备自主迭代能力的"查-做-测-改-修-记-循环"七阶段技能

一、核心哲学

1.1 唯一铁律

> 每一次交互都必须留下痕迹，要么改进代码，要么修复缺陷，要么沉淀知识。循环不停，直到AI限额。

v2.0的循环是"做完就交付"。v3.0的循环是"做完就测试，测试不过就修复，修复完再测，测过就找下一个改进点，永不停歇"。

1.2 五个底层认知

1.3 核心公式（v3.0升级）

任务输入
  → 查：读取 MEMORY.md + 扫描项目上下文 + 扫描知识专栏
    → 做：基于上下文完成任务（代码轨道 + 知识轨道）
      → 测：全链路自动化测试（HTML视觉/DOM/a11y/响应式/性能 + 非HTML结构/逻辑/接口）
        → 改：主动发现并修复问题（代码缺陷 + 知识缺口 + 测试失败）
          → 修：自我修复引擎（诊断→修复→重测→沉淀，直到通过或达到重试上限）
            → 记：将新经验写入 MEMORY.md + 将新洞察写入知识专栏 + 更新测试基线
              → 循环：测试驱动持续循环（通过→扩展覆盖→下一改进点；失败→修复→重测）
                → 直到AI限额

1.4 三轨模型（v3.0升级）

┌──────────────────────────────────────────────────────────┐
│                 self-evolving-loop v3.0                   │
├──────────────────┬───────────────────┬────────────────────┤
│   代码轨道        │   知识轨道         │   测试轨道          │
│  (Code Track)    │ (Knowledge Track) │  (Test Track)      │
├──────────────────┼───────────────────┼────────────────────┤
│ 重复代码 → 提取   │ 品牌卡片 → 定位框架 │ 手动验证 → 自动测试  │
│ 配置散落 → 集中   │ 伦理人物 → 决策模型 │ 一次性测试 → 基线回归 │
│ 命名混乱 → 统一   │ 日报文件 → 知识策展 │ 结构校验 → 视觉回归  │
│ 魔法数字 → 常量   │ 信息碎片 → 知识图谱 │ 单点测试 → 全链覆盖  │
│ 硬编码 → 配置化   │ 静态数据 → 动态演进 │ 失败报错 → 自动修复  │
│ 缺错误处理 → 补充 │ 孤立知识 → 跨域关联 │ 修复即止 → 沉淀知识  │
│ 文档缺失 → 补充   │ 浅层描述 → 深度洞察 │ 测完即止 → 持续循环  │
│ 流程繁琐 → 简化   │ 被动积累 → 主动策展 │ 覆盖固定 → 持续扩展  │
└──────────────────┴───────────────────┴────────────────────┘

二、完整执行流程（七阶段）

Phase 1：查（检索）

Step 1.1：读取 MEMORY.md

操作：

1. 检查项目根目录是否存在 MEMORY.md
2. 如果存在，完整读取内容
3. 如果不存在，立即创建（见 Step 1.2）

检验标准：

• [ ] 已确认 MEMORY.md 存在或已新建
• [ ] 已理解项目类型、技术栈、规范约定
• [ ] 已识别可复用的代码模式和工具函数
• [ ] 已识别知识专栏的现状和演进方向
• [ ] 已识别测试基线和测试覆盖现状

Step 1.2：新建 MEMORY.md（如需要）

触发条件：项目根目录没有 MEMORY.md

创建内容模板：

# 项目记忆库

## 📋 项目概览
- 项目类型：[前端/后端/全栈/数据分析/脚本工具等]
- 技术栈：[主要语言和框架]
- 架构风格：[MVC/微服务/组件化/函数式等]
- 产物类型：[HTML应用/API服务/CLI工具/库等]

## 📐 开发规范
- 命名规范：[文件/变量/函数/类的命名规则]
- 代码风格：[缩进/引号/分号/换行等约定]
- 目录结构：[标准目录组织方式]

## 🧪 测试基线
### 测试配置
- 测试框架：[Playwright/Jest/Vitest/其他]
- 测试目录：[tests/ 或 __tests__/]
- 基线快照目录：[tests/baselines/]

### 测试覆盖
- HTML产物：[列出需要测试的HTML文件]
- 非HTML产物：[列出需要测试的模块/接口]
- 视觉回归基线：[已建立/未建立]
- a11y基线：[已建立/未建立]

### 已知测试问题
- [问题描述] → [当前状态] → [优先级]

## 🧩 可复用模式
### [模式名称]
- 用途：[一句话说明解决什么问题]
- 代码位置：[文件路径]
- 使用示例：[关键代码片段]

## ⚠️ 踩坑记录
- [问题描述] → [解决方案] → [避免方法]

## 🔧 修复知识库
### [失败模式名称]
- 触发条件：[什么情况下会出现]
- 根因分析：[为什么会失败]
- 修复策略：[怎么修]
- 预防措施：[怎么避免再犯]
- 置信度：[高/中/低]

## 📚 知识专栏状态
### 品牌智识
- 品牌数量：[N]
- 最新演进：[当前阶段]
- 待补充：[缺什么]

### 商业伦理
- 伦理人物数：[N]
- 最新演进：[当前阶段]
- 待补充：[缺什么]

### 日报书架
- 日报文件数：[N]
- 最新演进：[当前阶段]
- 待补充：[缺什么]

## 📝 变更日志
| 日期 | 内容 | 来源任务 |
|------|------|----------|

检验标准：

• [ ] MEMORY.md 已创建于项目根目录
• [ ] 基础结构完整，包含全部章节（含测试基线和修复知识库）
• [ ] 项目类型和技术栈已填写

Step 1.3：扫描项目上下文

操作：

1. 查看项目目录结构（使用 LS/Glob 工具）
2. 识别与当前任务相关的代码文件
3. 读取关键文件，了解现有实现模式
4. 检查是否有可复用的工具函数或配置
5. 识别项目产物类型（HTML应用 / API服务 / CLI工具 / 库等）
6. 扫描现有测试文件和测试配置

检验标准：

• [ ] 已了解项目整体结构
• [ ] 已识别相关代码文件
• [ ] 已发现可复用的现有实现
• [ ] 已确认项目产物类型
• [ ] 已了解现有测试覆盖情况

Step 1.4：扫描知识专栏（知识轨道专用）

操作：

1. 读取 知识专栏/ 目录下各子目录的数据文件
2. 评估每个知识域的数据完整度和演进阶段
3. 识别知识缺口和可深化的方向
4. 检查跨域关联是否已建立

检验标准：

• [ ] 已读取品牌智识数据，评估品牌卡片深度
• [ ] 已读取商业伦理数据，评估伦理人物结构
• [ ] 已检查日报/书架相关文件，评估知识策展状态
• [ ] 已识别至少1个可深化的知识缺口

Phase 2：做（执行）

Step 2.1：基于上下文完成任务

执行原则：

1. 复用优先：先找 MEMORY.md 中记录的可复用模式
2. 风格一致：遵循项目现有的命名规范和代码风格
3. 架构对齐：保持与现有架构的一致性，不引入冲突
4. 知识同步：当代码任务涉及知识专栏时，同步更新知识数据
5. 测试就绪：确保新增/修改的代码可被自动化测试覆盖

三轨执行判定：

检验标准：

• [ ] 任务核心需求已完成
• [ ] 使用了项目现有模式或规范
• [ ] 代码/文档与项目风格一致
• [ ] 知识专栏相关变更已同步（如适用）
• [ ] 新增/修改代码具备可测试性

Phase 2.5：测（全链路自动化测试）⭐ v3.0新增

> 这是v3.0的核心新增阶段。没有测试，循环没有方向。测试是自我修复的输入，是持续循环的燃料。

Step 2.5.1：产物类型识别与测试策略选择

自动识别规则：

Step 2.5.2：HTML全链路自动化测试

> 对HTML产物执行五维自动化测试，确保渲染正确、结构合法、可访问、响应式、性能达标。

测试维度与执行方式：

HTML测试执行流程：

1. 启动本地服务器（如未运行）
2. 遍历所有HTML产物文件
3. 对每个HTML文件执行：
   a. 视觉回归测试
      - 截取全页截图
      - 与基线截图对比（首次运行自动建立基线）
      - 差异超过阈值 → 标记为失败
   b. DOM结构测试
      - 检查关键选择器是否存在
      - 检查关键属性值是否正确
      - 检查无空链接/空图片/空标题
   c. a11y测试
      - 运行axe-core扫描
      - 报告所有violations
      - 严重/重要级别 > 0 → 标记为失败
   d. 响应式测试
      - 375x667 (移动端)
      - 768x1024 (平板)
      - 1440x900 (桌面)
      - 每个断点截图 + 检查布局溢出
   e. 性能测试
      - 测量LCP/CLS/FID
      - 超标 → 标记为失败
4. 汇总测试结果
5. 生成测试报告

HTML测试配置模板（存入 tests/config.json）：

{
  "htmlTest": {
    "enabled": true,
    "baseUrl": "http://localhost:3000",
    "pages": [
      { "path": "/", "name": "首页", "criticalSelectors": ["header", "main", "footer"] }
    ],
    "visualRegression": {
      "enabled": true,
      "threshold": 0.001,
      "baselinesDir": "tests/baselines/screenshots",
      "updateBaselines": false
    },
    "domValidation": {
      "enabled": true,
      "checkEmptyLinks": true,
      "checkEmptyImages": true,
      "checkEmptyHeadings": true
    },
    "a11y": {
      "enabled": true,
      "standard": "WCAG2AA",
      "ignoreRules": []
    },
    "responsive": {
      "enabled": true,
      "viewports": [
        { "name": "mobile", "width": 375, "height": 667 },
        { "name": "tablet", "width": 768, "height": 1024 },
        { "name": "desktop", "width": 1440, "height": 900 }
      ]
    },
    "performance": {
      "enabled": true,
      "thresholds": {
        "lcp": 2500,
        "cls": 0.1,
        "fid": 100
      }
    }
  }
}

Step 2.5.3：非HTML产物自动化测试

Step 2.5.4：测试结果分类

测试结果分为三级：

检验标准：

• [ ] 已识别项目产物类型
• [ ] 已选择对应测试策略
• [ ] HTML产物已执行五维测试（如适用）
• [ ] 非HTML产物已执行对应维度测试（如适用）
• [ ] 测试结果已分类（PASS/SOFT_FAIL/HARD_FAIL）
• [ ] 测试报告已生成

Phase 3：改（优化）

Step 3.1：触发自主改进检查（代码轨道）

强制检查清单（逐条检查，发现即处理）：

Step 3.2：触发自主改进检查（知识轨道）

知识演进检查清单（当任务涉及知识专栏时，逐条检查）：

Step 3.3：触发自主改进检查（测试轨道）⭐ v3.0新增

测试改进检查清单（逐条检查，发现即处理）：

检验标准：

• [ ] 已完成代码轨道8项检查
• [ ] 已完成知识轨道7项检查（如适用）
• [ ] 已完成测试轨道7项检查
• [ ] 发现的问题已处理或记录处理理由
• [ ] 改进后的代码/知识/测试已通过基本逻辑验证

Step 3.4：执行改进（如触发）

操作：

1. 根据触发的问题类型，执行对应改进
2. 确保改进不破坏原有功能
3. 记录改进了什么、为什么改
4. 改进后必须重新运行受影响的测试

检验标准：

• [ ] 改进已完成
• [ ] 改进理由清晰
• [ ] 功能完整性未受损
• [ ] 受影响测试已重新运行并通过

Phase 3.5：修（自我修复引擎）⭐ v3.0新增

> 测试失败不是终点，而是修复的起点。AI必须自动诊断、修复、重测，并将修复经验沉淀为知识。

Step 3.5.1：修复循环流程

测试失败
  → 诊断：分析失败原因（视觉差异/DOM缺失/a11y违规/性能超标/逻辑错误等）
    → 定位：找到导致失败的代码位置
      → 修复：修改代码/样式/结构
        → 重测：重新运行失败的测试
          → 判断：
            - 通过 → 修复成功 → 沉淀修复知识 → 继续
            - 仍失败 → 重试（最多3次，每次换不同策略）
              - 3次仍失败 → 记录为"无法自动修复" → 标记待人工处理 → 继续下一个问题

Step 3.5.2：诊断引擎

诊断策略矩阵：

Step 3.5.3：修复策略库

按失败类型的修复策略：

Step 3.5.4：修复重试策略

第1次修复：
  - 使用策略1（首选策略）
  - 修复后重测
  - 通过 → 沉淀知识 → 结束
  - 失败 → 进入第2次

第2次修复：
  - 使用策略2（备选策略）
  - 从不同角度分析根因
  - 修复后重测
  - 通过 → 沉淀知识 → 结束
  - 失败 → 进入第3次

第3次修复：
  - 使用策略3（最后策略）
  - 考虑更广泛的上下文
  - 修复后重测
  - 通过 → 沉淀知识 → 结束
  - 失败 → 记录为"无法自动修复" → 标记待人工处理

无法自动修复时：
  - 在MEMORY.md的修复知识库中记录完整诊断过程
  - 在测试报告中标记为MANUAL_FIX_NEEDED
  - 继续处理下一个问题（不阻塞循环）

Step 3.5.5：修复知识沉淀

每次修复成功后，必须将修复经验沉淀到MEMORY.md的修复知识库：

### [失败模式名称]
- 触发条件：[什么情况下会出现]
- 根因分析：[为什么会失败]
- 修复策略：[用了哪个策略，怎么修的]
- 修复耗时：[第几次尝试才成功]
- 预防措施：[怎么避免再犯]
- 置信度：[高/中/低]
- 最后出现：[日期]

修复知识复用规则：

1. 每次诊断失败时，先查MEMORY.md修复知识库
2. 如果匹配到已知失败模式，直接使用已验证的修复策略
3. 如果修复策略不再有效，更新修复知识库（标记旧策略为deprecated，添加新策略）

检验标准：

• [ ] 所有HARD_FAIL已尝试修复
• [ ] SOFT_FAIL已尝试修复或记录原因
• [ ] 修复成功的问题已重测并通过
• [ ] 修复失败的问题已标记为MANUAL_FIX_NEEDED
• [ ] 修复经验已沉淀到MEMORY.md修复知识库
• [ ] 循环未被阻塞（无法修复的问题不阻止继续）

Phase 4：记（沉淀）

Step 4.1：更新 MEMORY.md

必须更新的章节：

1. 变更日志（每次必更新）

```markdown

| 2026-06-04 | 新增全链路HTML自动化测试 | v3.0升级 |

```

1. 测试基线（如有测试相关变更）
• 更新测试覆盖状态
• 记录新增的基线快照
• 记录测试配置变更

1. 修复知识库（如有修复）
• 记录新的失败模式和修复策略
• 更新已有模式的最后出现日期

1. 可复用模式（如有新增）
• 记录本次创建的可复用代码
• 标注用途、位置、使用示例

1. 踩坑记录（如有新坑）
• 记录遇到的问题和解决方案

1. 开发规范（如有新约定）
• 补充新的命名或风格约定

1. 知识专栏状态（如涉及知识轨道）
• 更新品牌智识/商业伦理/日报书架的演进状态

检验标准：

• [ ] 变更日志已追加新行
• [ ] 测试基线已更新（如适用）
• [ ] 修复知识库已更新（如适用）
• [ ] 新增的可复用模式已记录
• [ ] 新发现的坑已记录
• [ ] 知识专栏状态已更新（如适用）
• [ ] MEMORY.md 已保存

Step 4.2：更新知识专栏数据（知识轨道专用）

操作：

1. 将本次任务产生的新知识写入对应知识专栏的JSON文件
2. 确保数据结构符合最新schema
3. 更新知识专栏的索引文件

检验标准：

• [ ] 知识数据已写入对应JSON文件
• [ ] 数据结构符合最新schema
• [ ] 索引文件已更新

Step 4.3：更新测试基线（测试轨道专用）⭐ v3.0新增

操作：

1. 如果是首次运行，将当前截图保存为基线
2. 如果测试全部通过且差异在阈值内，更新基线（可选，需确认变更是预期的）
3. 记录基线版本号和更新时间

检验标准：

• [ ] 视觉回归基线已建立或更新
• [ ] 基线版本号已记录
• [ ] 基线更新原因已记录

Phase 5：交付

Step 5.1：按强制格式输出

交付模板：

✅ 任务结果
   [简述完成的核心内容，1-3句话]

🧪 测试结果
   - HTML视觉回归：[PASS/SOFT_FAIL/HARD_FAIL] - [详情]
   - DOM结构：[PASS/SOFT_FAIL/HARD_FAIL] - [详情]
   - a11y：[PASS/SOFT_FAIL/HARD_FAIL] - [详情]
   - 响应式：[PASS/SOFT_FAIL/HARD_FAIL] - [详情]
   - 性能：[PASS/SOFT_FAIL/HARD_FAIL] - [详情]
   - 非HTML测试：[PASS/SOFT_FAIL/HARD_FAIL/N/A] - [详情]

🔧 自主改进（如无则写"无"）
   - [改了什么] → [为什么改] → [收益]

🩹 自我修复（如无则写"无"）
   - [失败类型] → [诊断结果] → [修复策略] → [修复结果（第N次成功/失败）]
   - [示例：视觉回归失败 → CSS变更导致布局偏移 → 回滚CSS变更 → 第1次修复成功]

📝 新增/更新知识（如无则写"无"）
   - [知识项名称]：[写入MEMORY.md位置] - [一句话说明]

📚 知识专栏演进（如无则写"无"）
   - [专栏名]：[演进动作] - [一句话说明]

🔄 循环状态
   - 当前轮次：[N]
   - 测试通过率：[X/Y]
   - 待修复问题：[N个]
   - 下一步行动：[扩展测试覆盖 / 修复剩余问题 / 寻找新改进点]

检验标准：

• [ ] 任务结果简述清晰
• [ ] 测试结果按维度列出
• [ ] 自主改进项明确（或标注"无"）
• [ ] 自我修复项明确（或标注"无"）
• [ ] 知识沉淀项明确（或标注"无"）
• [ ] 知识专栏演进项明确（或标注"无"）
• [ ] 循环状态清晰
• [ ] 格式符合模板要求

Phase 6：循环（测试驱动持续循环）⭐ v3.0新增

> 这是v3.0的灵魂。循环不停，直到AI限额。每一轮循环都在让项目变得更好。

Step 6.1：循环决策树

当前状态：所有测试通过
  → 是否有未覆盖的测试维度？
    → 是 → 扩展测试覆盖（新增测试用例）→ 回到Phase 2.5
    → 否 → 是否有代码轨道改进点？
      → 是 → 执行改进 → 回到Phase 2.5
      → 否 → 是否有知识轨道改进点？
        → 是 → 执行知识演进 → 回到Phase 2.5
        → 否 → 是否有测试轨道改进点？
          → 是 → 优化测试（速度/稳定性/覆盖）→ 回到Phase 2.5
          → 否 → 扫描项目寻找新的改进机会 → 回到Phase 2.5

当前状态：存在测试失败
  → 进入Phase 3.5（自我修复引擎）
  → 修复完成后 → 回到Phase 2.5（重测）

Step 6.2：循环优先级

当多个改进方向同时可行时，按以下优先级执行：

Step 6.3：循环节奏控制

每轮循环必须：

1. 执行至少1个有意义的动作（修复/改进/扩展/演进）
2. 运行受影响的测试验证
3. 更新MEMORY.md（至少变更日志）
4. 输出循环状态

循环终止条件（仅以下情况终止）：

1. AI限额到达（token用尽）
2. 用户明确要求停止
3. 连续3轮无任何改进点（项目已达到当前最优状态）

循环不终止的情况：

• 测试仍有失败 → 继续修复
• 测试覆盖有缺口 → 继续扩展
• 代码有改进点 → 继续改进
• 知识有演进空间 → 继续演进
• 任何有价值的改进 → 继续循环

Step 6.4：循环效率优化

Step 6.5：循环状态追踪

每轮循环输出状态摘要：

🔄 循环 #N
   动作：[本轮做了什么]
   测试：[通过/总数]
   修复：[成功/尝试]
   改进：[代码/知识/测试]
   耗时：[本轮token消耗估算]
   下一步：[下一轮计划]

检验标准：

• [ ] 循环决策树已正确执行
• [ ] 优先级已正确应用
• [ ] 每轮循环至少执行1个有意义的动作
• [ ] MEMORY.md已更新
• [ ] 循环状态已输出
• [ ] 循环在AI限额前持续运行

三、MEMORY.md 管理规范

3.1 文件定位

3.2 章节说明

3.3 更新原则

1. 变更日志每次必写：哪怕只改了一个字，也要记录
2. 测试基线及时更新：测试配置变更、基线更新时立即记录
3. 修复知识及时沉淀：每次修复成功后立即记录失败模式和修复策略
4. 可复用模式及时沉淀：完成一个功能，立即判断是否有可复用部分
5. 踩坑记录详细：问题描述要具体，解决方案要可复制
6. 规范渐进完善：不要一次写太多规范，随项目演进逐步补充
7. 知识专栏状态同步：知识数据变更后，同步更新MEMORY.md中的专栏状态

四、常见陷阱与避坑指南

五、场景适配指南

六、质量检验清单

每次使用本SKILL后，检查：

流程完整性

• [ ] Phase 1（查）：已读取/新建 MEMORY.md
• [ ] Phase 1（查）：已扫描知识专栏（如适用）
• [ ] Phase 2（做）：任务核心需求已完成
• [ ] Phase 2.5（测）：已执行全链路自动化测试
• [ ] Phase 3（改）：已检查代码轨道8项改进触发条件
• [ ] Phase 3（改）：已检查知识轨道7项改进触发条件（如适用）
• [ ] Phase 3（改）：已检查测试轨道7项改进触发条件
• [ ] Phase 3.5（修）：已修复所有HARD_FAIL
• [ ] Phase 3.5（修）：修复经验已沉淀到修复知识库
• [ ] Phase 4（记）：MEMORY.md 已更新（至少变更日志）
• [ ] Phase 4（记）：测试基线已更新（如适用）
• [ ] Phase 4（记）：知识专栏数据已更新（如适用）
• [ ] Phase 5（交付）：格式符合强制模板
• [ ] Phase 6（循环）：循环状态已输出

内容质量

• [ ] MEMORY.md 的变更日志已追加
• [ ] 测试基线已更新
• [ ] 修复知识库已更新
• [ ] 发现的问题已处理或记录
• [ ] 交付结果清晰易懂
• [ ] 无"要不要改"类询问
• [ ] 知识专栏演进有实质进展（如适用）

零确认执行

• [ ] 全程无不必要的用户确认
• [ ] 独立判断，独立执行
• [ ] 用户只验收最终结果

循环持续性

• [ ] 循环在AI限额前持续运行
• [ ] 每轮循环至少执行1个有意义的动作
• [ ] 无法自动修复的问题不阻塞循环
• [ ] 循环状态清晰可追踪

七、执行原则

1. MEMORY.md 是必选项：没有它，循环无法启动。没有就新建，绝不做没有记忆的工作。

1. 改进是义务，不是选项：看到问题不改进，等于白做。哪怕只是改个命名，也是进步。

1. 零确认是底线："要不要改"这句话不应该出现。你判断，你决定，你执行。

1. 沉淀要具体：写"使用了工厂模式"没用，写"用户认证使用AuthFactory.create()"才有用。

1. 格式是契约：强制交付格式不是建议，是必须。用户靠这个快速了解你做了什么。

1. 不完美胜过不完成：改进可以小，但不能没有。先完成，再完美。

1. 循环是习惯：每次任务都走完整循环，形成肌肉记忆。跳过一步，循环就断了。

1. 三轨是常态：代码轨道、知识轨道和测试轨道不是三选一，而是并行。测试轨道是v3.0的核心新增，每次任务都必须跑。

1. 测试是燃料：没有测试，循环没有方向。测试通过→扩展覆盖；测试失败→修复缺陷。测试驱动一切改进。

1. 修复是学习：每次修复都是一次学习机会。修复经验必须沉淀，同类问题不能犯两次。

1. 循环不停：只要AI限额未到，循环就不停。测试全通过不是终点，而是寻找下一个改进点的起点。

八、HTML全链路测试详细规范 ⭐ v3.0新增

> HTML产物是v3.0的重点测试对象。本章节详细定义每个测试维度的执行规范。

8.1 视觉回归测试

8.1.1 截图策略

8.1.2 差异判定

// 差异率计算
const diffRate = diffPixels / totalPixels;
// 判定逻辑
if (diffRate < 0.001) return 'PASS';      // 差异 < 0.1%，通过
if (diffRate < 0.01) return 'SOFT_FAIL';   // 差异 0.1%-1%，软失败
return 'HARD_FAIL';                         // 差异 > 1%，硬失败

8.1.3 动态内容处理

8.2 DOM结构测试

8.2.1 检查项

8.2.2 自适应选择器

优先使用语义选择器，减少因样式变更导致的测试脆弱性：

优先级：role > text > test-id > css > xpath

8.3 可访问性(a11y)测试

8.3.1 检查标准

8.3.2 违规分级

8.4 响应式测试

8.4.1 断点定义

8.4.2 布局检查项

8.5 性能测试

8.5.1 Core Web Vitals阈值

8.5.2 性能测试执行

// 使用Playwright测量性能
const metrics = await page.metrics();
const performanceEntries = await page.evaluate(() =>
  performance.getEntriesByType('navigation')
);

九、知识专栏演进引擎

> 知识专栏不是静态的数据仓库，而是活的认知系统。每一次交互都应该让它更深入、更关联、更有洞察力。

9.1 品牌智识演进

9.1.1 演进阶段

L0 基础卡片 ──→ L1 定位框架 ──→ L2 竞争图谱 ──→ L3 品牌健康 ──→ L4 叙事引擎

9.1.2 L1 定位框架数据模型

{
  "positioning": {
    "identity": "品牌身份定义——我们是谁？一句话回答",
    "values": ["核心价值观1", "核心价值观2", "核心价值观3"],
    "differentiation": "差异化声明——为什么选我们不选别人？",
    "audience": {
      "primary": "核心目标人群画像",
      "secondary": "次级目标人群画像",
      "insight": "人群洞察——他们真正在意什么"
    },
    "promise": "品牌承诺——我们向用户保证什么"
  }
}

9.1.3 品牌定位五维评估法

评估输出：

{
  "positioningScore": {
    "uniqueness": 8,
    "relevance": 7,
    "consistency": 6,
    "vitality": 9,
    "credibility": 7,
    "overall": 7.4,
    "weakDimension": "consistency",
    "recommendation": "建议加强品牌言行一致性"
  }
}

9.1.4 品牌演进触发规则

9.1.5 品牌智识与商业伦理的关联

• 品牌的 values[] 与伦理人物的 stance 形成价值观映射
• 品牌的 cases[] 可引用伦理人物的决策模型进行伦理评估
• 品牌的 socialTrend.direction 与伦理人物的行业背景交叉，生成行业伦理洞察

9.2 商业伦理演进

9.2.1 演进阶段

L0 每日人物 ──→ L1 决策模型 ──→ L2 伦理困境库 ──→ L3 行业伦理指南 ──→ L4 伦理决策引擎

9.2.2 L1 决策模型数据模型

{
  "decisionModel": {
    "type": "决策模型类型：功利主义/义务论/美德伦理/利益相关者理论/关怀伦理",
    "principles": ["核心原则1", "核心原则2"],
    "framework": {
      "step1": "识别利益相关者",
      "step2": "分析各方利益与权利",
      "step3": "评估行动后果",
      "step4": "检验原则一致性",
      "step5": "做出决策并反思"
    },
    "applicability": {
      "bestFor": "此模型最适合的决策场景",
      "limitations": "此模型的局限性",
      "complementaryModels": ["可互补的其他模型"]
    }
  }
}

9.2.3 五大伦理决策模型

9.2.4 伦理人物跨人物脉络

{
  "connections": [
    {
      "fromFigure": "张瑞敏",
      "toFigure": "松下幸之助",
      "type": "思想传承",
      "description": "张瑞敏的人单合一与松下的人本主义在'以人为本'上有共鸣"
    }
  ]
}

9.2.5 伦理演进触发规则

9.2.6 商业伦理与品牌智识的关联

• 伦理人物的 decisionModel 可用于评估品牌的 cases[] 中的伦理维度
• 品牌的 values[] 可映射到伦理决策模型的 principles
• 伦理困境库中的场景可来自品牌的真实案例

9.3 日报书架演进

9.3.1 演进阶段

L0 日报文件 ──→ L1 知识策展 ──→ L2 每日书架 ──→ L3 知识提取 ──→ L4 知识图谱

9.3.2 L1 知识策展数据模型

{
  "date": "2026-05-27",
  "filename": "2026-05-27.md",
  "curated": {
    "category": "日报分类：运营分析/战略洞察/行业动态/产品复盘/组织管理",
    "keyInsights": ["洞察1", "洞察2", "洞察3"],
    "relatedDomains": {
      "brands": ["相关品牌ID"],
      "ethics": ["相关伦理人物"],
      "topics": ["相关主题标签"]
    },
    "quality": {
      "depth": "深度评分1-5",
      "actionability": "可操作性评分1-5",
      "novelty": "新颖度评分1-5"
    }
  }
}

9.3.3 L2 每日书架数据模型

{
  "date": "2026-05-27",
  "bookshelf": {
    "dailyQuestion": "今日一问：[一个引发思考的问题]",
    "readings": [
      {
        "type": "insight|case|framework|trend|reflection",
        "title": "阅读标题",
        "source": "来源（日报/品牌/伦理/外部）",
        "summary": "一句话摘要",
        "deepLink": "关联到具体日报文件或知识条目",
        "readingTime": "预计阅读时间（分钟）"
      }
    ],
    "connections": [
      {
        "from": "品牌A的XX趋势",
        "to": "伦理人物B的YY观点",
        "insight": "交叉洞察"
      }
    ],
    "recommendedAction": "基于今日书架的建议行动"
  }
}

9.3.4 日报书架策展流程

每日触发（或手动触发）
  → 扫描当日/近7日日报文件
    → 提取关键洞察（keyInsights）
      → 关联品牌智识和商业伦理
        → 生成每日书架
          → 写入 bookshelf-YYYY-MM-DD.json

策展规则：

1. 每日书架包含3-5条精选阅读
2. 至少1条来自品牌智识关联
3. 至少1条来自商业伦理关联
4. 至少1条跨域连接（品牌↔伦理）
5. 每日一问必须与当日最核心的洞察相关

9.3.5 日报书架演进触发规则

9.3.6 日报书架与双域的关联

• 日报中的运营数据关联到品牌的 healthMetrics
• 日报中的战略决策关联到伦理的 decisionModel
• 书架的 connections[] 是品牌智识和商业伦理的桥梁

9.4 跨域知识图谱

9.4.1 三域关联模型

品牌智识 ←──── 关联 ────→ 商业伦理
    ↕                      ↕
  日报数据              伦理案例
    ↕                      ↕
  日报书架 ←──── 策展 ────→ 每日书架

9.4.2 跨域关联类型

9.4.3 跨域关联数据结构

{
  "crossDomainLinks": [
    {
      "id": "link_001",
      "type": "价值观映射|案例互引|趋势共振|知识补给|决策支撑",
      "source": { "domain": "brands|ethics|bookshelf", "entityId": "实体ID", "field": "字段路径" },
      "target": { "domain": "brands|ethics|bookshelf", "entityId": "实体ID", "field": "字段路径" },
      "insight": "跨域洞察描述",
      "confidence": "高/中/低",
      "createdAt": "2026-05-27"
    }
  ]
}

9.4.4 跨域洞察生成规则

1. 每次新增品牌时：扫描伦理人物，寻找价值观映射和案例互引
2. 每次新增伦理人物时：扫描品牌，寻找趋势共振和决策支撑
3. 每次生成日报书架时：从品牌和伦理中提取至少1条跨域连接
4. 每周一次：全量扫描三域数据，补充遗漏的跨域关联

9.5 知识专栏演进执行规范

9.5.1 演进优先级

1. P0 数据完整性：缺字段、schema过时 → 立即修复
2. P1 L0→L1升级：基础卡片/人物 → 定位框架/决策模型 → 高优先
3. P2 跨域关联：孤立知识 → 建立关联 → 中优先
4. P3 L1→L2升级：定位框架 → 竞争图谱 → 按需
5. P4 高阶演进：L2+ → 按需触发

9.5.2 演进不可逆原则

• 知识专栏的演进阶段只能前进，不能回退
• L0数据在升级后必须保留，L1+是增量而非替换
• 每次演进必须记录 evolutionLog

{
  "evolutionLog": [
    {
      "date": "2026-05-27",
      "entityId": "ganoexcel",
      "domain": "brands",
      "fromLevel": 0,
      "toLevel": 1,
      "addedFields": ["positioning", "positioningScore"],
      "trigger": "品牌智识深度升级任务"
    }
  ]
}

9.5.3 知识质量守门规则

十、知识专栏与代码的协同规范

10.1 IPC通道与知识演进的映射

10.2 视图与知识演进的映射

10.3 数据文件与知识演进的映射

十一、版本与变更

11.1 SKILL版本

11.2 向后兼容

• v1.0.0和v2.0.0的所有流程和规范在v3.0.0中完全保留
• v3.0.0新增的测试轨道和自我修复引擎是增量扩展，不影响纯代码/知识任务
• MEMORY.md模板新增"测试基线"和"修复知识库"章节，旧项目首次使用v3.0.0时需补充此章节
• HTML全链路测试仅对HTML产物项目生效，非HTML项目自动跳过