Память и интеллект проекта — Практика
Прямая речь: “Всё на этой практической странице построено так, чтобы вы могли повторять за мной строка за строкой. Когда вы видите блок с командой или промптом, можете копировать его прямо в терминал или сессию Claude, если я явно не скажу, что это справочный материал. По ходу дела сравнивайте свой результат с моим на экране, чтобы ловить ошибки рано, а не копить их.”
Продолжительность: ~20 минут Результат: Полная система памяти для ai-coderrank — пользовательские предпочтения, условные правила для K8s и тестирования, конфигурация локального окружения и автоматически выученные соглашения. Пререквизиты: Пройдены Блоки 0-4 (Claude Code установлен, ai-coderrank запущен локально, тёмная тема реализована)
Шаг 1: Создание пользовательского CLAUDE.md (~3 мин)
Этот файл живёт вне проектов — это ВАШИ предпочтения, применяемые повсюду.
Создайте директорию, если её ещё нет, затем создайте файл:
mkdir -p ~/.claude
Теперь создайте ~/.claude/CLAUDE.md с вашими персональными предпочтениями. Вот шаблон — адаптируйте его под свой реальный стиль работы:
# Personal Coding Preferences
## Style
- I prefer functional programming patterns over class-based OOP
- Use TypeScript strict mode whenever possible
- Prefer named exports over default exports
- Use `const` by default, `let` only when reassignment is needed
## Commits
- Follow Conventional Commits format: type(scope): description
- Types: feat, fix, docs, style, refactor, test, chore, ci
- Keep subject line under 72 characters
- Write commit messages in imperative mood ("add feature" not "added feature")
## Communication
- Be concise in explanations — I prefer bullet points over paragraphs
- When showing code changes, always explain WHY not just WHAT
- If something could break production, flag it loudly
## Tools
- I use pnpm as my package manager
- My terminal is zsh with oh-my-zsh
- I use vim keybindings
Важно: Это ВАШ файл. Измените его, чтобы он отражал ваши реальные предпочтения. Используете npm вместо pnpm? Предпочитаете классы? Любите подробные объяснения? Сделайте его своим. Весь смысл в том, что Claude адаптируется к вам, а не наоборот.
Шаг 2: Обзор проектного CLAUDE.md (~2 мин)
Ещё в Блоке 1, когда мы впервые исследовали ai-coderrank, проектный CLAUDE.md уже был на месте. Давайте посмотрим на него снова свежим взглядом, теперь зная, что он делает.
cd ~/ai-coderrank
cat CLAUDE.md
Вы должны увидеть что-то вроде:
# CLAUDE.md
This is a Next.js 14 application that compares AI coding models.
## Tech Stack
- Next.js 14 (App Router)
- TypeScript
- Tailwind CSS
- Recharts for data visualization
- pnpm as package manager
## Commands
- `pnpm dev` — start development server
- `pnpm build` — production build
- `pnpm test` — run tests
- `pnpm lint` — run ESLint
## Project Structure
- `src/app/` — Next.js app router pages and API routes
- `src/components/` — React components
- `src/lib/` — Utility functions and data
- `k8s/` — Kubernetes manifests
- `argocd/` — ArgoCD application config
Этот файл закоммичен в git. Каждый разработчик в команде (и каждая сессия Claude) его видит. Думайте о нём как о представлении проекта: “привет, вот кто я.”
Вопрос для обсуждения: Чего не хватает в этом CLAUDE.md? Какие соглашения вы бы добавили для вашей команды? Запомните это — мы вернёмся к этому.
Шаг 3: Создание условных правил для тестирования (~4 мин)
Теперь самое интересное. Давайте создадим правила, которые активируются только когда Claude работает с тестовыми файлами.
Создайте директорию правил:
mkdir -p ~/ai-coderrank/.claude/rules
Создайте .claude/rules/testing.md:
---
path: "**/*.test.*"
---
# Testing Conventions
## Framework
- We use Vitest as our test runner
- React components are tested with @testing-library/react
- API routes are tested with supertest
## Structure
- Test files live next to the code they test: `Component.tsx` -> `Component.test.tsx`
- Use `describe` blocks to group related tests
- Each `it` block should test exactly ONE behavior
- Name tests as sentences: `it('renders the model comparison chart with data')`
## Patterns
- Prefer `screen.getByRole()` over `getByTestId()` for accessibility
- Use `userEvent` over `fireEvent` for realistic user interactions
- Mock external APIs at the fetch level, not at the module level
- Always clean up: if you add to the DOM, make sure it's removed
## Coverage
- New features require tests — no exceptions
- Bug fixes require a regression test that would have caught the bug
- Minimum meaningful coverage, not chasing percentages
## Example Structure
import { describe, it, expect } from ‘vitest’; import { render, screen } from ‘@testing-library/react’; import { ModelCard } from ‘./ModelCard’;
describe(‘ModelCard’, () => { it(‘displays the model name and provider’, () => { render(<ModelCard model={mockModel} />); expect(screen.getByRole(‘heading’)).toHaveTextContent(‘GPT-4’); expect(screen.getByText(‘OpenAI’)).toBeInTheDocument(); });
it(‘highlights the top-ranked model with a badge’, () => { render(<ModelCard model={mockModel} rank={1} />); expect(screen.getByRole(‘status’)).toHaveTextContent(‘#1’); }); });
Что произошло? Фронтматтер
path: "**/*.test.*"говорит Claude: “Загружай эти инструкции только когда затронуты тестовые файлы.” Когда вы редактируете Kubernetes-манифест, этот файл не мешается. Когда трогаете тест? Он тут как тут.
Шаг 4: Создание условных правил для Kubernetes (~4 мин)
Та же концепция, но для K8s-манифестов. Здесь доменно-специфичные знания по-настоящему раскрываются.
Создайте .claude/rules/k8s.md:
---
path: "k8s/**"
---
# Kubernetes Manifest Conventions
## Labels (Required on All Resources)
Every resource MUST include these labels:
metadata:
labels:
app.kubernetes.io/name: ai-coderrank
app.kubernetes.io/component:
## Resource Limits (Required on All Containers)
Never deploy a container without resource limits. Use these as starting points:
resources: requests: cpu: “100m” memory: “128Mi” limits: cpu: “500m” memory: “512Mi”
## Security
- Never run containers as root — always set `runAsNonRoot: true`
- Always set `readOnlyRootFilesystem: true` where possible
- Drop all capabilities, add back only what's needed:
securityContext: runAsNonRoot: true readOnlyRootFilesystem: true capabilities: drop: [“ALL”]
## Images
- NEVER use the `latest` tag — always pin to a specific version
- Use the project's container registry: `ghcr.io/your-org/ai-coderrank`
- Multi-arch images preferred (amd64 + arm64)
## Naming
- Use kebab-case for resource names
- Prefix with `ai-coderrank-`: e.g., `ai-coderrank-deployment`, `ai-coderrank-service`
- Namespace: `ai-coderrank` (don't use `default`)
## Health Checks
Every Deployment must have:
- `livenessProbe` — is the process alive?
- `readinessProbe` — is it ready to receive traffic?
- `startupProbe` for containers with slow initialization
Это мощно. В следующий раз, когда вы попросите Claude “добавить новый Kubernetes deployment для кэша Redis”, он автоматически включит лимиты ресурсов, контексты безопасности, правильные лейблы и health checks — потому что знает правила вашей команды.
Шаг 5: Создание CLAUDE.local.md (~3 мин)
Этот файл для вещей, которые верны на ВАШЕЙ машине, но не должны быть общими. Локальные пути, детали персонального окружения, URL staging-среды.
Создайте CLAUDE.local.md в корне проекта:
# Local Environment — DO NOT COMMIT
## Environment
- Local K8s cluster: minikube (profile: ai-coderrank)
- Kubeconfig path: ~/.kube/config
- Docker daemon: Docker Desktop on macOS
## Local URLs
- App: http://localhost:3000
- K8s Dashboard: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
## Credentials (for local development only)
- GitHub Container Registry: Use `gh auth token` for authentication
- ArgoCD admin password: see `argocd admin initial-password -n argocd`
## Personal Preferences for This Project
- I'm currently focused on the dark theme feature (Block 4)
- My preferred branch naming: feature/<block-number>-<short-description>
- I review diffs before committing — always show me the diff first
Теперь проверьте, что файл в gitignore:
cd ~/ai-coderrank
cat .gitignore | grep -i claude
Вы должны увидеть CLAUDE.local.md в gitignore. Если его нет, добавьте:
echo "CLAUDE.local.md" >> .gitignore
Почему это важно: CLAUDE.local.md — место для вещей, утечка которых на GitHub была бы инцидентом безопасности. Локальные учётные данные, внутренние URL, пути с вашим именем пользователя. По умолчанию он в gitignore проектов Claude Code, но всегда перепроверяйте.
Шаг 6: Запуск /memory для полной картины (~2 мин)
Теперь посмотрим всё, что Claude загрузил. Запустите сессию Claude Code в проекте ai-coderrank:
cd ~/ai-coderrank
claude
Внутри сессии введите:
/memory
Claude покажет сводку всей загруженной памяти:
- Ваш пользовательский
~/.claude/CLAUDE.md - Проектный
CLAUDE.md - Ваш
CLAUDE.local.md - Все файлы
.claude/rules/и их фильтры путей
Вы должны увидеть оба набора правил — для тестирования и для K8s — с условиями активации.
Попробуйте: Спросите Claude “What do you know about how we write tests in this project?” Он должен сослаться на ваши соглашения по тестированию из файла правил — хотя вы никогда не упоминали их в разговоре.
Шаг 7: Автоматическая память — наблюдайте, как Claude учится (~2 мин)
Это момент “ого”. Давайте научим Claude чему-то, поправив его.
В сессии Claude Code попробуйте:
Show me how to run the linter for this project
Если Claude предложит npm run lint или yarn lint, поправьте его:
Actually, we use pnpm in this project. The command is pnpm lint.
Claude распознает это как запоминаемое соглашение и может предложить его запомнить. Примите предложение.
Теперь выйдите из сессии и начните новую:
/exit
claude
В новой сессии спросите:
How do I run the linter?
Claude теперь должен ответить pnpm lint без подсказок — он выучил из вашей поправки.
За кулисами: Автоматическая память сохраняет поправки в памяти проекта. Со временем эти маленькие поправки накапливаются. После нескольких недель реального использования Claude знает ваш проект так же хорошо, как человек, проработавший в команде несколько месяцев.
Контрольная точка
На данный момент у вас должно быть:
| Файл | Расположение | Назначение |
|---|---|---|
~/.claude/CLAUDE.md |
Домашняя директория | Личные предпочтения для всех проектов |
CLAUDE.md |
Корень проекта | Стандарты команды (уже существовал) |
CLAUDE.local.md |
Корень проекта | Локальное окружение, в gitignore |
.claude/rules/testing.md |
.claude/rules/ |
Соглашения по тестированию (активируется для тестовых файлов) |
.claude/rules/k8s.md |
.claude/rules/ |
Соглашения K8s (активируется для файлов k8s/) |
Пять файлов. Ноль повторений. Каждая сессия начинается с полным контекстом.
Бонусное задание
Создайте ещё один файл правил: .claude/rules/docker.md с фильтром путей для Dockerfile*. Включите соглашения для:
- Multi-stage сборок (отдельные этапы builder и runtime)
- Непривилегированного пользователя в финальном образе
- Порядка инструкций
COPYдля оптимального кэширования слоёв (зависимости сначала, код потом) - Использования
.dockerignoreдля минимизации размера образов
Затем попросите Claude проверить ваш существующий Dockerfile на соответствие этим новым правилам. Посмотрите, что он найдёт.
Далее: В Блоке 6 мы продвинем эту концепцию ещё дальше. Если память — это то, что Claude знает, то навыки — это то, что Claude умеет делать. Вы создадите пользовательские слэш-команды, которые превращают сложные рабочие процессы в однострочники.
Готовы проверить себя?
Пройти квиз →