engineer-expertise-extractor

工程师专业能力提取器

通过分析工程师的 GitHub 贡献，提取并记录其编码专业知识，创建结构化知识库，涵盖其编码风格、模式、最佳实践和架构决策。

此技能的功能

研究工程师的工作，打造一位“数字导师”：

• 分析拉取请求——提取代码模式、审查风格和决策
• 提取编码风格——记录其偏好和惯例
• 识别模式——归纳其常用的解决方案和方法
• 总结最佳实践——记录其质量标准和指导原则
• 整理示例——收录其工作中的实际代码示例
• 记录决策——记录架构选择及其原因

为什么这很重要

知识留存：

• 在专家离开前留存其专业知识
• 记录团队内部知识
• 创建指导材料
• 加快新工程师的入职

保持一致性：

• 统一团队编码标准
• 复用专家的方法
• 维护代码质量
• 在团队内推广专业知识

学习：

• 向资深工程师学习
• 理解决策过程
• 查看实际模式
• 提升代码质量

工作原理

1. 研究阶段

此技能使用 GitHub CLI（gh）来：

• 获取工程师的拉取请求
• 分析代码变更
• 查看其评论和反馈
• 提取模式和惯例
• 识别其专业领域

2. 分析阶段

将发现归入以下类别：

• 编码风格——格式、命名、结构
• 模式——常见解决方案和方法
• 最佳实践——质量指导原则
• 架构——设计决策
• 测试——测试方法
• 代码审查——反馈模式
• 文档——文档风格和实践

3. 整理阶段

创建结构化文件夹：

engineer_profiles/
└── [engineer_name]/
    ├── README.md (overview)
    ├── coding_style/
    │   ├── languages/
    │   ├── naming_conventions.md
    │   ├── code_structure.md
    │   └── formatting_preferences.md
    ├── patterns/
    │   ├── common_solutions.md
    │   ├── design_patterns.md
    │   └── code_examples/
    ├── best_practices/
    │   ├── code_quality.md
    │   ├── testing_approach.md
    │   ├── performance.md
    │   └── security.md
    ├── architecture/
    │   ├── design_decisions.md
    │   ├── tech_choices.md
    │   └── trade_offs.md
    ├── code_review/
    │   ├── feedback_style.md
    │   ├── common_suggestions.md
    │   └── review_examples.md
    └── examples/
        ├── by_language/
        ├── by_pattern/
        └── notable_prs/

输出结构

工程师档案 README

包含：

• 工程师概览
• 专业领域
• 语言和技术
• 重要贡献
• 编码理念
• 如何使用此档案

编码风格文档

记录：

• 命名惯例（变量、函数、类）
• 代码结构偏好
• 文件组织方式
• 注释风格
• 格式偏好
• 特定语言的惯用法

示例：

# Coding Style: [Engineer Name]

## Naming Conventions

### Variables
- Use descriptive names: `userAuthentication` not `ua`
- Boolean variables: `isActive`, `hasPermission`, `canEdit`
- Collections: plural names `users`, `items`, `transactions`

### Functions
- Verb-first: `getUserById`, `validateInput`, `calculateTotal`
- Pure functions preferred
- Single responsibility

### Classes
- PascalCase: `UserService`, `PaymentProcessor`
- Interface prefix: `IUserRepository`
- Concrete implementations: `MongoUserRepository`

## Code Structure

### File Organization
- One class per file
- Related functions grouped together
- Tests alongside implementation
- Clear separation of concerns

### Function Length
- Max 20-30 lines preferred
- Extract helper functions
- Single level of abstraction

模式文档

记录：

• 重复出现的解决方案
• 使用的设计模式
• 架构模式
• 问题解决方法

示例：

# Common Patterns: [Engineer Name]

## Dependency Injection

Used consistently across services:

\`\`\`typescript
// Pattern: Constructor injection
class UserService {
  constructor(
    private readonly userRepo: IUserRepository,
    private readonly logger: ILogger
  ) {}
}
\`\`\`

**Why:** Testability, loose coupling, clear dependencies

## Error Handling

Consistent error handling approach:

\`\`\`typescript
// Pattern: Custom error types + global handler
class ValidationError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ValidationError';
  }
}

// Usage
if (!isValid(input)) {
  throw new ValidationError('Invalid input format');
}
\`\`\`

**Why:** Type-safe errors, centralized handling, clear debugging

最佳实践文档

记录：

• 质量标准
• 测试方法
• 性能指导原则
• 安全实践
• 文档标准

示例：

# Best Practices: [Engineer Name]

## Testing

### Unit Test Structure
- AAA pattern (Arrange, Act, Assert)
- One assertion per test preferred
- Test names describe behavior
- Mock external dependencies

\`\`\`typescript
describe('UserService', () => {
  describe('createUser', () => {
    it('should create user with valid data', async () => {
      // Arrange
      const userData = { email: '[email protected]', name: 'Test' };
      const mockRepo = createMockRepository();

      // Act
      const result = await userService.createUser(userData);

      // Assert
      expect(result.id).toBeDefined();
      expect(result.email).toBe(userData.email);
    });
  });
});
\`\`\`

### Test Coverage
- Aim for 80%+ coverage
- 100% coverage for critical paths
- Integration tests for APIs
- E2E tests for user flows

## Code Review Standards

### What to Check
- [ ] Tests included and passing
- [ ] No console.logs remaining
- [ ] Error handling present
- [ ] Comments explain "why" not "what"
- [ ] No hardcoded values
- [ ] Security considerations addressed

架构文档

记录：

• 设计决策
• 技术选择
• 所做的权衡
• 系统设计方法

示例：

# Architectural Decisions: [Engineer Name]

## Decision: Microservices vs Monolith

**Context:** Scaling user service
**Decision:** Start monolith, extract services when needed
**Reasoning:**
- Team size: 5 engineers
- Product stage: MVP
- Premature optimization risk
- Easier debugging and deployment

**Trade-offs:**
- Monolith pros: Simpler, faster development
- Monolith cons: Harder to scale later
- Decision: Optimize for current needs, refactor when hitting limits

## Decision: REST vs GraphQL

**Context:** API design for mobile app
**Decision:** REST with versioning
**Reasoning:**
- Team familiar with REST
- Simple use cases
- Caching easier
- Over-fetching not a problem yet

**When to reconsider:** If frontend needs complex queries

代码审查文档

记录：

• 反馈模式
• 审查方法
• 常见建议
• 沟通风格

示例：

# Code Review Style: [Engineer Name]

## Review Approach

### Priority Order
1. Security vulnerabilities
2. Logic errors
3. Test coverage
4. Code structure
5. Naming and style

### Feedback Style
- Specific and constructive
- Explains "why" behind suggestions
- Provides examples
- Asks questions to understand reasoning

### Common Suggestions

**Security:**
- "Consider input validation here"
- "This query is vulnerable to SQL injection"
- "Should we rate-limit this endpoint?"

**Performance:**
- "This N+1 query could be optimized with a join"
- "Consider caching this expensive operation"
- "Memoize this pure function"

**Testing:**
- "Can we add a test for the error case?"
- "What happens if the API returns null?"
- "Let's test the boundary conditions"

**Code Quality:**
- "Can we extract this into a helper function?"
- "This function is doing too many things"
- "Consider a more descriptive variable name"

使用此技能

提取工程师档案

./scripts/extract_engineer.sh [github-username]

交互式工作流：

1. 输入 GitHub 用户名
2. 选择仓库范围（全部／特定组织）
3. 选择分析深度（最近 N 个拉取请求）
4. 指定关注领域（语言、主题）
5. 提取并整理发现

**输出：**位于 engineer_profiles/[username]/ 的结构化档案

分析特定仓库

./scripts/analyze_repo.sh [repo-url] [engineer-username]

将分析重点放在特定仓库的贡献上。

更新现有档案

./scripts/update_profile.sh [engineer-username]

添加新的拉取请求并更新现有档案。

研究来源

GitHub CLI 查询

拉取请求：

gh pr list --author [username] --limit 100 --state all
gh pr view [pr-number] --json title,body,files,reviews,comments

代码变更：

gh pr diff [pr-number]
gh api repos/{owner}/{repo}/pulls/{pr}/files

审查：

gh pr view [pr-number] --comments
gh api repos/{owner}/{repo}/pulls/{pr}/reviews

提交：

gh api search/commits --author [username]

分析技术

模式识别：

• 识别重复出现的代码结构
• 提取常见解决方案
• 检测命名模式
• 查找架构选择

风格提取：

• 分析格式的一致性
• 提取命名约定
• 识别注释模式
• 检测结构偏好

最佳实践识别：

• 查找测试模式
• 查找错误处理方法
• 识别安全实践
• 提取性能优化方案

使用场景

1. 新工程师入职

问题： 新工程师需要了解团队标准 解决方案： 提供资深工程师的档案作为参考

优点：

• 代码库中的真实示例
• 了解团队约定
• 查看决策过程
• 学习最佳实践

2. 代码审查培训

问题： 教授良好的代码审查技能 解决方案： 研究经验丰富的审查者的反馈模式

优点：

• 学习审查要点
• 了解反馈风格
• 查看常见问题
• 提高审查质量

3. 知识传递

问题： 资深工程师离职，知识流失 解决方案： 在其离职前提取其专业知识

优点：

• 保留团队隐性知识
• 记录决策
• 维护代码质量
• 降低人员流失风险

4. 制定团队标准

问题： 团队内编码风格不一致 解决方案： 从优秀工程师身上提取模式，制定标准

优点：

• 基于证据制定标准
• 真实示例
• 获得团队认可
• 代码库风格一致

5. AI Agent 训练

问题： Agent 需要按照特定工程师的风格编写代码 解决方案： 将提取出的档案提供给 Agent

优点：

• 匹配专家的风格
• 遵循其模式
• 运用其最佳实践
• 保持一致性

Agent 如何使用档案

当 Agent 可以访问工程师档案时，它可以：

代码生成：

• 遵循提取出的命名约定
• 使用已识别的模式
• 运用记录的最佳实践
• 匹配架构风格

代码审查：

• 以工程师的风格提供反馈
• 检查他们会发现的常见问题
• 运用他们的质量标准
• 符合他们的优先事项

问题解决：

• 使用他们常用的解决方案
• 遵循他们的架构方法
• 运用他们的设计模式
• 考虑他们的权衡取舍

Agent 提示词示例：

"Using the profile at engineer_profiles/senior_dev/, write a user service
following their coding style, patterns, and best practices. Pay special
attention to their error handling approach and testing standards."

最佳实践

研究伦理

应该：

• ✅ 提取前征得许可
• ✅ 关注公开贡献
• ✅ 尊重隐私
• ✅ 将其用于学习和改进

不应该：

• ❌ 未经许可进行提取
• ❌ 向外部分享档案
• ❌ 纳入敏感信息
• ❌ 将其用于绩效评估

档案维护

定期更新：

• 每季度刷新一次
• 添加新的重要 PR
• 更新为最新模式
• 归档过时的实践

质量控制：

• 验证提取出的模式
• 检查示例是否相关
• 更新文档
• 移除已弃用的实践

有效使用

用于学习：

• 结合上下文研究模式
• 理解选择背后的原因
• 练习运用这些技巧
• 有疑问时提出问题

用于复现：

• 从风格指南入手
• 遇到类似问题时参考相关模式
• 根据当前上下文进行调整
• 不要盲目照搬

局限性

可提取的内容：

• ✅ 编码风格和约定
• ✅ 常见模式和方法
• ✅ 最佳实践和指南
• ✅ 架构决策
• ✅ 审查反馈模式

无法捕捉的内容：

• ❌ 实时问题解决过程
• ❌ 口头沟通风格
• ❌ 会议讨论
• ❌ 设计阶段的思考
• ❌ 人际指导

未来增强

可能的新增功能：

• Slack 消息分析（沟通风格）
• 设计文档提取（设计思维）
• 会议记录分析（决策过程）
• 视频分析（结对编程会议）
• 代码指标跟踪（随时间的演变）

输出示例

engineer_profiles/
└── senior_dev/
    ├── README.md
    │   # Senior Dev - Staff Engineer
    │   Expertise: TypeScript, Node.js, System Design
    │   Focus: API design, performance optimization
    │
    ├── coding_style/
    │   ├── typescript_style.md
    │   ├── naming_conventions.md
    │   └── code_structure.md
    │
    ├── patterns/
    │   ├── dependency_injection.md
    │   ├── error_handling.md
    │   └── examples/
    │       ├── service_pattern.ts
    │       └── repository_pattern.ts
    │
    ├── best_practices/
    │   ├── testing_strategy.md
    │   ├── code_quality.md
    │   └── performance.md
    │
    ├── architecture/
    │   ├── api_design.md
    │   ├── database_design.md
    │   └── scaling_approach.md
    │
    ├── code_review/
    │   ├── feedback_examples.md
    │   └── review_checklist.md
    │
    └── examples/
        └── notable_prs/
            ├── pr_1234_auth_refactor.md
            └── pr_5678_performance_fix.md

概述

此技能可将工程师在 GitHub 上的贡献转化为结构化、可复用的知识库。它会以以下形式记录他们的专业知识：

• 供人们学习——包含示例的清晰文档
• 供 Agent 复现——结构化模式和指南
• 供团队采用——基于证据的最佳实践
• 供组织留存——不会随人员变动而流失的知识

目标： 让专业知识具备可扩展性、可学习性和可复现性。

---

“最好的学习方式，是向已经精通的人学习。”