serena-usage

Serena 使用指南

有效使用 Serena MCP 服务进行项目记忆管理、代码智能，并在 AI Agent 会话之间保持连续性。

• 在条件允许时，利用原生并行子 Agent 调度和 200k+ 上下文窗口。

激活条件

使用“症状 -> 操作”触发条件：匹配任一条件时，应用此技能并按照以下协议进行验证。

必须在以下情况下激活：

• 项目可使用 Serena
• 任务需要保持项目记忆的连续性
• 任务需要符号导航或 Serena 重构工作流
• 管理项目记忆，以保持 AI 会话的连续性
• 使用基于符号的工具浏览代码库
• 使用 Serena 的符号管理功能进行代码重构
• 为新项目设置 Serena 入门流程
• 使用 Serena 的记忆系统保留项目上下文

重要：在执行任何 Serena 操作之前，务必先通过 get_current_config 确认项目已激活

前置条件

• Serena MCP 服务已配置并运行
• 项目已激活（使用 get_current_config 验证；若尚未激活，则使用 activate_project）
• 已完成目标项目的入门流程（先使用 check_onboarding_performed）
• 如果尚未激活，使用项目名称或路径运行 activate_project
• 如果尚未完成入门流程，激活后运行 onboarding 工具

---

入门工作流

首次设置项目

1. 检查激活状态：调用 get_current_config，确认项目是否已激活
2. 按需激活：如果项目尚未激活，使用项目名称或路径调用 activate_project
3. 检查入门状态：调用 check_onboarding_performed，确认入门流程状态
4. 阅读手册：如果尚未完成入门流程，调用 initial_instructions 阅读 Serena 指令手册
5. 初始化：调用 onboarding 完成项目设置
6. Serena 会分析项目结构并创建初始上下文

入门流程会记录的内容

• 项目语言和框架检测
• 目录结构分析
• 关键文件识别
• 符号索引创建
• 初始记忆框架

激活检查模式

# Always verify activation first
get_current_config
# If no active project, activate it
activate_project project="path/to/project"
# Then proceed with onboarding check
check_onboarding_performed

项目激活

激活的重要性

使用 Serena 时，第一步是激活项目。这会告知 Serena 要处理哪个项目，并初始化工作区上下文。

激活工作流

1. 检查当前状态：调用 get_current_config，查看是否已有激活的项目
2. 按需激活：如果没有活动项目，请调用：

   activate_project project="project-name"
   # OR with path:
   activate_project project="path/to/project/directory"
   

3. 验证激活状态：再次调用 get_current_config，确认激活成功
4. 继续入门流程：激活后，检查是否需要完成入门流程

激活最佳实践

• 尝试执行任何 Serena 操作之前，务必先检查 get_current_config
• 激活时使用工作区根目录路径
• 激活状态仅限当前会话——在新会话中可能需要重新激活
• 激活后，后续所有 Serena 操作都可以使用项目上下文

---

记忆管理

核心概念

Serena 记忆会在会话之间保留，让 AI Agent 能够在不同工作会话之间保持连续性。

记忆操作

操作	工具	用途
列出全部	list_memories	查看可用记忆
读取一项	read_memory	访问特定记忆内容
创建	write_memory	存储新信息
更新	edit_memory	修改现有记忆
删除	delete_memory	清理过时信息

记忆结构

Serena 记忆采用 Memory Bank 命名约定，以确保一致性和清晰度。此结构将项目智能信息整理到核心文件和任务中。

核心文件

记忆名称	用途
project-brief	定义核心需求和目标的基础文档，影响所有其他记忆。在项目启动时创建。
product-context	项目存在的原因、要解决的问题、应如何运作，以及用户体验目标
active-context	当前工作重点、近期变更和后续步骤，以及当前的决策和考量
system-patterns	系统架构、关键技术决策、采用的设计模式和组件关系
tech-context	使用的技术、开发环境、技术限制和依赖项
progress	已实现的功能、待开发内容、当前状态和已知问题

任务管理记忆

任务通过专用记忆文件进行管理，以跟踪进度和历史记录。

记忆名称	用途
task-{id}	单个任务跟踪（例如，TASK001-implement-login.md），包含原始请求、思路、实施计划和进度日志
task-index	所有任务的主列表，包含 ID、名称、状态（Pending/In Progress/Completed/Abandoned）和最后更新时间

任务记忆结构

每个任务记忆都遵循以下格式：

# [Task ID] - [Task Name]

**Status:** [Pending/In Progress/Completed/Abandoned]
**Added:** [Date Added]
**Updated:** [Date Last Updated]

## Original Request
[The original task description as provided by the user]

## Thought Process
[Documentation of the discussion and reasoning that shaped the approach]

## Implementation Plan
- [Step 1]
- [Step 2]
- [Step 3]

## Progress Tracking

**Overall Status:** [Not Started/In Progress/Blocked/Completed] - [Completion Percentage]

### Subtasks
| ID | Description | Status | Updated | Notes |
|----|-------------|--------|---------|-------|
| 1.1 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Relevant notes] |

## Progress Log
### [Date]
- Updated subtask 1.1 status to Complete
- Started work on subtask 1.2
- Encountered issue with [specific problem]
- Made decision to [approach/solution]

任务索引结构

task-index 记忆维护一份结构化记录：

# Tasks Index

## In Progress
- [TASK003] Implement user authentication -Working on OAuth integration
- [TASK005] Create dashboard UI -Building main components

## Pending
- [TASK006] Add export functionality -Planned for next sprint

## Completed
- [TASK001] Project setup -Completed on 2025-03-15
- [TASK002] Create database schema -Completed on 2025-03-17

命令

当你请求 add task 或 create task 时，Agent 将：

1. 创建一个具有唯一 Task ID 的新任务记忆
2. 记录有关处理方法的思路
3. 制定实施计划
4. 设置初始状态
5. 更新 task-index 记忆

要查看任务，命令 show tasks [filter] 将显示经过筛选的列表，可用筛选条件包括：

• all - 显示所有任务，无论状态如何
• active - 仅显示“In Progress”任务
• pending - 仅显示“Pending”任务
• completed - 仅显示“Completed”任务
• blocked - 仅显示“Blocked”任务
• recent - 显示过去一周内更新的任务

何时更新记忆

在以下情况下更新核心记忆：

• 完成重要功能或功能模块后
• 做出架构决策时
• 发现新的项目模式或惯例时
• 更改技术栈或依赖项时
• 修改数据模型或架构时
• 每个工作会话开始和结束时

在以下情况下更新任务记忆：

• 通过“create task”命令创建新任务时
• 推进现有任务时
• 完成子任务或整个任务时
• 遇到阻碍或问题时
• 更改任务状态时（Pending → In Progress → Completed/Abandoned）

记忆创建工作流

重要：创建新记忆前，务必检查是否存在相关的现有记忆

分步流程

1. 列出可用记忆：使用 list_memories 查看所有现有记忆
2. 分析相关性：确认是否有任何现有记忆涵盖相同主题或概念
3. 检查记忆内容：如果找到相关记忆，使用 read_memory 检查其内容
4. 匹配标准：
   • 相同的功能、技术或主题领域
   • 用途或范围重叠
   • 相关的架构决策
   • 相似的问题领域或关注点
5. 决定：
   • 如果存在相关记忆：使用 edit_memory 更新现有记忆，添加新信息和当前时间戳
   • 如果不存在相关记忆：使用 write_memory 创建新记忆

匹配指南

如果新的记忆条目与现有记忆相关，则应归入该记忆：

标准	示例
相同功能领域	“admin-features” 已涵盖管理工作流 → 将新的管理任务详情添加到其中
相同技术	“auth-context” 已涵盖身份验证 → 将新的身份验证实现详情添加到其中
相关架构	“system-patterns” 涵盖架构决策 → 将新的架构选择添加到其中
相同领域关注点	“ui-components-and-styling” 涵盖组件库 → 将新的组件规范添加到其中
项目范围的更新	“project-overview” 涵盖整体状态 → 将项目的一般更新添加到其中

更新现有记忆的模式

更新现有记忆时，请遵循以下结构：

## {Topic} — Updated [YYYY-MM-DD HH:MM]

### [Date] - Update
- [New information or decision]
- [Implementation details or findings]
- [Related changes or impacts]
- [Next actions or considerations]

### Previous Context
[Preserve existing relevant information]

记忆整合示例

场景 1：添加新的管理功能规范

Existing: admin-features.md (500 bytes)
New info: New user moderation workflow specs
Action: Update admin-features.md with new section, update timestamp

场景 2：修复 SQL 错误

Existing: csx3006-sql-fixes-2026-02-13.md
New info: Another SQL bug related to same issue
Action: Update csx3006-sql-fixes-2026-02-13.md, add new fix details, update timestamp

场景 3：新增身份验证实现细节

Existing: auth-context.md
New info: Session management implementation specifics
Action: Update auth-context.md with new implementation section, update timestamp

场景 4：为不同问题创建新的数据库修复记忆

Existing: csx3006-sql-fixes-2026-02-13.md (column name fixes)
New info: Index optimization fixes (different topic)
Action: Create NEW memory: csx3006-index-fixes-2026-02-16.md

何时创建新记忆

仅在以下情况下创建新记忆：

• 不同领域：主题与现有记忆有本质区别
• 重要里程碑：进入新阶段或项目发生重大转变
• 新技术栈：与现有技术背景无关
• 基于时间的跟踪：修复记忆、每日更新或带日期的日志
• 规模过大：添加内容后，现有记忆将超过 5-10 KB

创建新记忆的示例：

Existing: admin-features.md
New: Performance analysis reports → Create NEW: performance-analysis.md

Existing: ui-components-and-styling.md
New: Mobile responsiveness specifications → Create NEW: mobile-responsive.md

Existing: csx3006-sql-fixes-2026-02-13.md (database schema corrections)
New: API endpoint bug fixes → Create NEW: api-fixes-2026-02-16.md

记忆库文档指南

Serena 记忆遵循记忆库结构，以全面记录项目信息。主要指南：

任务进度更新：

• 取得进展时，务必同时更新子任务状态表和进度日志
• 子任务表可快速直观地查看当前状态
• 进度日志记录工作过程的叙述和细节
• 每条进度日志都应包含日期、已完成事项、遇到的挑战和所作决策
• 更新 task-index 中的任务状态，以反映当前进度

文档流程：

New Task → Create task-{id}.py memory → Update task-index
Progress → Update task-{id}.py log table → Update task-index
Discovery → Create/ update appropriate core memory
Architecture Decision → Update system-patterns memory
Completion → Update progress memory → Clear from active tasks

活动上下文格式：

## Active Context — Updated [Date]

### Current Focus
- Implementing user authentication with NextAuth.js
- Building recipe CRUD API routes

### Recent Decisions
- Chose MongoDB Atlas over Cosmos DB for cost
- Using server components for recipe listing page

### Blockers
- Image upload size limit needs investigation

### Next Steps
1. Complete login/signup UI
2. Add recipe creation form
3. Set up image upload to Blob Storage

记忆编写指南

## Active Context — Updated [Date]

### Current Focus
- Implementing user authentication with NextAuth.js
- Building recipe CRUD API routes

### Recent Decisions
- Chose MongoDB Atlas over Cosmos DB for cost
- Using server components for recipe listing page

### Blockers
- Image upload size limit needs investigation

### Next Steps
1. Complete login/signup UI
2. Add recipe creation form
3. Set up image upload to Blob Storage

---

代码导航

基于符号的导航

工具	使用场景
find_symbol	按名称路径定位特定类、函数和变量
find_referencing_symbols	查找代码库中某个符号的所有用法
get_symbols_overview	概览文件中的符号

导航工作流

1. 使用 get_symbols_overview 了解文件结构
2. 使用 find_symbol 定位特定定义
3. 使用 find_referencing_symbols 在修改前了解影响范围

---

代码重构

使用 Serena 安全重构

工具	操作
rename_symbol	重命名所有引用中的符号
replace_symbol_body	替换函数/方法的实现
insert_after_symbol	在定义后添加新代码
insert_before_symbol	在定义前添加新代码

重构工作流

1. 了解：使用 find_symbol 和 get_symbols_overview
2. 评估影响：使用 find_referencing_symbols 查看所有用法
3. 规划：考虑所需的更改
4. 执行：使用重命名/替换/插入工具
5. 验证：重新检查引用，确认正确性
6. 记录：更新记忆，说明更改原因

---

文件搜索

工具	用途
find_file	查找符合名称模式的文件
list_dir	浏览目录内容
search_for_pattern	在代码库中搜索文本/正则表达式模式

---

任务遵循

Serena 提供了反思工具，帮助保持专注：

工具	使用时机
think_about_collected_information	收集完上下文后——信息是否充分？
think_about_task_adherence	多次交互后——我是否仍在正轨上？
think_about_whether_you_are_done	结束前——我是否已完成所有工作？

---

会话工作流

开始会话

1. 验证激活状态：get_current_config → 检查项目是否已激活
2. 如有需要则激活：如果没有活动项目，使用 activate_project → 激活工作区
3. 检查引导状态：check_onboarding_performed → 验证引导状态
4. 如有需要，使用引导工作流完成引导
5. list_memories → 查看所有 10 条可用的项目记忆
6. read_memory → 加载与当前工作阶段相关的记忆：
   • 始终： 读取 project-overview（当前状态、技术栈、后续步骤）
   • 阶段 4（后端）： 读取 database-integration-implementation-plan-task（TASK-057 到 TASK-092）
   • 功能开发： 读取特定功能记忆（admin-features、recipe-features、auth-context）
   • SQL 工作： 读取 csx3006-sql-fixes-2026-02-13.md（列命名约定、外键模式）
   • Notion 同步： 读取 notion-implementation-tracking.md（更新协议）
7. 根据当前阶段的上下文开始工作

会话期间

• SQL/数据库工作： 检查是否存在 {topic}-fixes-{date}.md → 更新该记忆，或为 Bug 修复创建新记忆
• 功能实现： 检查是否存在 {feature-name}.md → 更新该记忆，或创建新的功能规格记忆
• 阶段完成： 使用新的状态百分比和当前时间戳更新 project-overview.md
• Notion 更新： 完成计划任务后使用 notion-update-page（TASK-001 → TASK-138）
• 代码导航： 使用符号工具探索 React 组件和未来的 PHP 后端文件
• 新信息流：
  1. 使用 list_memories 查看所有现有记忆
  2. 确认是否有现有记忆涵盖该主题
  3. 如果存在相关记忆：使用 edit_memory 添加新信息并更新时间戳
  4. 如果没有相关记忆：使用 write_memory 创建新记忆

---

最佳实践

• 始终在进行任何 Serena 操作前使用 get_current_config 检查激活状态
• 始终在创建新记忆前使用 list_memories 检查是否存在相关记忆
• 关键：使用 edit_memory 更新现有记忆并设置新时间戳，而不是创建重复记忆
• 如果项目尚未激活，先使用 activate_project 激活项目
• 激活后、首次在项目中使用前，检查引导状态
• 保持记忆简洁——优先使用结构化数据，而非散文
• 逐步更新记忆，不要一次性大幅改写
• 在不同项目中使用一致的记忆命名方式（Memory Bank 约定）
• 对复杂任务使用 think_about_* 工具进行自我反思
• 任务跟踪：始终同时更新任务记忆中的子任务表和进度日志
• 任务状态发生变化时，保持 task-index 同步更新
• 删除过时的记忆以避免混淆
• 讨论工作时，使用 task-index 中的任务 ID 作为参考
• 向现有记忆添加信息时，将时间戳更新为 YYYY-MM-DD HH:MM 格式

故障排除

问题	解决方案
项目未激活	运行 get_current_config 进行验证，然后使用项目路径运行 activate_project
未检测到入门流程	激活后，明确运行 onboarding 工具
未找到记忆	使用 list_memories 检查准确名称
未找到符号	确保文件已编入索引；尝试使用更宽泛的名称
记忆过时	使用 edit_memory 更新为当前状态并添加时间戳
记忆冲突	删除过时条目，并将内容合并到一条记忆中
记忆重复	创建新记忆前务必先使用 list_memories 检查；使用 edit_memory 更新现有记忆
不确定要更新哪条记忆	使用 list_memories → 查看每条记忆的用途 → 阅读相关记忆 → 更新最合适的一条

---

跨客户端可移植性

此技能旨在确保在 GitHub Copilot、Claude Code 和 Codex 中均可使用。

• GitHub Copilot：将文件夹放在 Copilot 可见的技能路径中；若无法发现文件夹，则将工作流封装在项目说明中。
• Claude Code：将文件夹放在本地技能目录或兼容的插件源中。
• Codex：将文件夹安装或同步到 $CODEX_HOME/skills/serena-usage，并在重大更改后重启 Codex。

MCP 可用性与回退方案

首选 MCP 服务：Serena MCP

• 回退提示词："Use the Serena Usage skill without MCP. Follow the documented local or manual fallback, show the selected tool surface, and report the verification evidence."
• Serena 不可用时，使用 rg、git diff、针对性读取文件以及本地 Markdown 记忆文件。
• 在仓库文档或笔记中维护一个轻量级 Memory Bank，以便在不同会话间延续项目上下文。
• 如果当前宿主未提供某项 MCP 操作，切勿声称使用了该操作。

反模式

• 未明确成功条件就开始：技能会变成建议式内容，而非工作流式内容。
• 跳过随附的参考资料或脚本：这会失去目录试图保留的经过验证的路径。
• 未提供具体证据就声称已完成：后续 Agent 或审查者将无法信任结果，也无法安全地继续工作。

验证协议

在声称“技能已成功应用”之前：

1. 通过/不通过：Serena Usage 工作流明确说明 Agent 边界、委派范围和预期返回的产物。
2. 通过/不通过：传递给辅助工具的上下文应精简、仅与任务相关，且不包含隐藏的预期答案。
3. 通过/不通过：只有在控制器检查证据、差异或引文后，才整合结果。
4. 压力测试场景：在两个相似但不得共享假设或泄露上下文的任务上运行工作流。
5. 成功指标：上下文泄漏为零；每项委派输出均可独立审查。

参考资料与资源

文档

• 记忆管理 — 记忆命名规范、生命周期和维护最佳实践
• 符号导航 — find_symbol 和 find_referencing_symbols 的使用模式与工作流

项目专属指南（食谱分享系统）

当前记忆结构（10 条活跃记忆）：

记忆	用途	备注
project-overview	项目状态、技术栈、后续步骤	核心参考，首先阅读
database-integration-implementation-plan-task	138 项任务计划 v2.0 状态	已完成 38%（阶段 1–3 已完成）
csx3006-sql-fixes-2026-02-13	SQL 脚本修正	调试时保留
notion-implementation-tracking	Notion 同步协议	完成任务时更新
admin-features	管理工作流、内容审核、用户管理	仅包含功能规格
recipe-features	食谱 CRUD、搜索、评价、互动	仅包含功能规格
auth-context	基于会话的身份验证流程	阶段 4 后端、阶段 5 集成
routing-layouts	路由配置和页面布局	使用带布局守卫的 HashRouter
storage-data-model	阶段 5 前的 localStorage 结构	将由 API 取代
ui-components-and-styling	组件库和 Tailwind v4	可复用组件

会话启动模式（阶段 4 — 后端待开发）：

1. get_current_config → 验证项目是否已激活
2. 如果尚未激活，使用当前工作区路径调用 activate_project
3. check_onboarding_performed → 验证引导流程状态
4. 如有需要，使用标准工作流完成引导流程
5. list_memories → 确认有 10 条可用记忆
6. 阅读 project-overview → 当前状态（已完成 38%，阶段 1–3 已完成）
7. 阅读 database-integration-implementation-plan-task → 阶段 4 任务（TASK-057 至 TASK-092）
8. 开始开发 PHP 后端：backend/config/database.php、backend/helpers/，然后是 backend/api/

项目专属最佳实践：

数据库约定：

• 数据库：cookhub（utf8mb4_unicode_ci）
• 表：使用单数形式（user、recipe、ingredient 等）
• 列：使用 snake_case，id 为主键
• 主键访问：父表使用 WHERE id = ?，子表使用外键引用
• 外键：{table}_id 列

架构：

• 原生 PHP（无框架、无 Composer）
• 结构：backend/{config, helpers, api}/
• 每个 API 文件通过 $_SERVER['REQUEST_METHOD'] 处理路由
• 身份验证：基于会话（HttpOnly Cookie、session 表）
• HTTP：使用原生 fetch() 并设置 credentials: 'include'

文档流程：

• SQL 修正 → 检查 {topic}-fixes-{date}.md 是否存在 → 更新该文件或创建新记忆
• 重要里程碑 → 使用新的时间戳更新 project-overview.md
• 阶段完成 → 更新 database-integration-implementation-plan-task.md 中的进度
• Notion 同步 → 在 notion-implementation-tracking.md 中更新同步状态
• 所有更新 → 包含当前时间戳，格式为："Updated: YYYY-MM-DD HH:MM"

使用的命名模式：

• 功能记忆：小写 kebab-case（admin-features、recipe-features、auth-context）
• 修正记忆：{name}-fixes-{date}.md
• 状态记忆：{project}-updates.md 或 {plan}-task.md

---

记忆参考表（CSX3006 项目）

类别	记忆名称	更新频率	阅读时机
状态与计划	project-overview	阶段完成、架构决策后	每次开始会话时始终首先阅读
任务跟踪	database-integration-implementation-plan-task	阶段完成后	开始后端或前端工作时
SQL 修正	csx3006-sql-fixes-2026-02-13.md	修复数据库问题时	进行 SQL/数据库工作时
Notion 同步	notion-implementation-tracking	Notion 同步模式变更时	更新 Notion 页面前
功能规格	admin-features、recipe-features、auth-context	功能变更/改进时	实现相关功能时
参考资料	routing-layouts、storage-data-model、ui-components-and-styling	很少变更	快速查阅这些主题时

脚本

• Memory Backup — 用于备份 Serena 记忆文件并添加时间戳的 PowerShell 脚本

示例

• Refactoring Workflow — 使用 Serena 工具的 13 步重构演练

---

本项目的记忆管理策略

为什么是 10 条记忆（而不是 Memory Bank 标准中的 15 条）：

• 项目通过 plan/upgrade-database-integration-1.md（138 项任务）跟踪实施计划，而不是使用任务记忆
• 无需单独的 task-{id} 记忆（任务已列在计划文件中）
• 无需 task-index 或 progress 记忆（状态记录在 project-overview.md 中）
• 功能规格保持简洁（admin-features、recipe-features、auth-context 每个约 500 字节）
• 用于快速查阅的单行参考记忆（routing-layouts、storage-data-model、ui-components-and-styling）

何时创建新记忆：

• SQL/脚本修复：{topic}-fixes-{date}.md（例如，csx3006-sql-fixes-2026-02-13.md）
• 功能文档：{feature-name}.md（例如，admin-features.md）
• 重要里程碑：更新 project-overview.md（状态变更、架构决策）

何时不创建记忆：

• 单项任务（使用 upgrade-database-integration-1.md 任务列表）
• 日常进展（项目状态记录在 project-overview.md 中）
• 代码示例（代码在实际文件中，不在记忆中）
• 一次性的历史事件（过时后删除）
• 应更新现有记忆的信息，而不是创建新记忆

---

更新记忆还是创建记忆：快速参考

决策树

Need to store information?
│
├─ Check: `list_memories`
│  │
│  ├─ Existing memory covers this topic?
│  │  │
│  │  ├─ YES → Use `edit_memory` with new info + updated timestamp
│  │  │
│  │  └─ NO → Use `write_memory` to create new memory
│  │
│  └─ Proceed with work

常见匹配模式

添加关于……的信息时	检查记忆……	如果存在……	如果不存在……
管理功能/内容审核	admin-features	更新它	创建 admin-features
食谱 CRUD/搜索	recipe-features	更新它	创建 recipe-features
身份验证/会话	auth-context	更新它	创建 auth-context
当天的 SQL 修复	{topic}-fixes-{date}	更新它	使用当天日期创建新记忆
架构决策	system-patterns	更新它	创建 system-patterns
整体项目状态	project-overview	始终更新它	创建 project-overview
组件规格	ui-components-and-styling	更新它	如果主题不同，则创建新记忆

编辑记忆模式

# Always use this format when updating existing memories
edit_memory(
  memory_file_name="existing-memory-name",
  needle="section or content to replace or append after",
  repl="new information with timestamp:\n\n## [Section] — Updated YYYY-MM-DD HH:MM\n\n- [new info]",
  mode="literal" # or "regex" as appropriate
)

---

相关技能

• development-workflow：当工作流还需要规划、质量门禁和交付跟踪时使用。
• documentation-quality：当工作流还需要文档审查标准和质量门禁时使用。
• verification-before-completion：当工作流还需要在宣称完成前进行最终证据检查时使用。
• code-quality：当工作流还需要两阶段审查（先检查规格符合性，再检查代码质量）、可维护性和重构指导时使用。