Skip to content
BranchesTags

Repository files navigation

Java 后端开发技能体系

面向 AI 辅助工程的结构化软件开发生命周期（SDLC）技能体系。将软件研发流程拆解为 12 个可组合的技能，每个技能具备清晰的职责边界、阶段管理和路由规则。

设计理念

意图优先分类

每个工程请求在要求任何产物之前先按工作类型分类。支持的工作类型对应真实的开发活动：

工作类型 含义 入口技能
FEATURE 新业务能力 requirements-analysis
REQUIREMENT_CHANGE 已批准需求变更 requirements-change
BUG 缺陷诊断与修复 bug-fix
REFACTOR 行为保持的重构 code-refactor
TEST 测试生成或执行 test-gen / test-run
DOC 文档或报告生成 docs-gen
REVIEW 代码或质量审查 code-review

最轻有效工作流

仅当业务含义发生变化时才使用全生命周期。快速 bug 修复、临时审查或一次性测试运行可以不跟踪（Untracked），无需任务文档即可完成。

单一状态源

规范任务文档（docs/task/{日期}_{模块}_task.md）是当前阶段、任务状态、产物清单、上下文快照、恢复上下文和下一步动作的唯一权威来源。支持跨会话的中断恢复。

关注点分离

每个技能拥有明确定义的生命周期阶段：

  • 需求技能 只负责业务含义，不涉及技术实现。
  • 设计技能 只负责架构，不涉及业务规则。
  • 开发技能 只负责代码，不涉及设计决策。
  • 测试技能 只负责验证，不涉及功能实现。
  • 审查技能 只负责质量门禁，不涉及测试执行。

报告始终生成

无论跟踪模式如何，每个工作流的结果都会作为 markdown 报告持久化到 docs/report/。报告记录决策、风险和证据，确保工程可追溯性。

架构

┌─────────────────────────────────────────────────────────────────┐
│                   workflow-orchestrator                          │
│  意图分类 · 路由 · 模式选择 · 恢复                                │
└───┬──────────┬──────────┬──────────┬──────────┬──────────┬─────┘
    │          │          │          │          │          │
    ▼          ▼          ▼          ▼          ▼          ▼
 ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐
 │ 需求  │  │ 需求  │  │ 方案  │  │ 任务  │  │ 开发  │  │ 代码  │
 │ 分析  │←│ 变更  │→│ 设计  │→│ 编排  │→│ 实现  │←│ 审查  │
 └──────┘  └──────┘  └──────┘  └──────┘  └──────┘  └──────┘
                              │                    │
                              ▼                    ▼
 ┌──────┐  ┌──────┐  ┌──────┐              ┌──────────┐
 │ Bug  │  │ 重构  │  │ 文档  │              │ 测试执行  │
 │ 修复  │  │      │  │ 生成  │              │ (失败路由)│
 └──────┘  └──────┘  └──────┘              └──────────┘
   │          │                                  │
   ▼          ▼                            ┌──────────┐
 ┌──────┐  ┌──────┐                       │ 测试生成  │
 │测试  │←│测试  │                        │(测试修复)│
 │执行  │  │执行  │                        └──────────┘
 └──────┘  └──────┘

两个操作层

层级 角色 示例
编排层（Orchestrator） 分类意图、选择模式、路由到技能、管理阶段转换 workflow-orchestrator
技能层（Skills） 执行领域特定工作，拥有清晰的职责边界 bug-fix、test-run、code-review

报告渲染子系统

所有 12 个技能将报告生成路由到同一个技能（docs-gen），该技能以报告渲染（Report Rendering）模式运行：生成报告文件，更新任务文档的产物清单，但不修改 Current Phase。调用方技能拥有阶段转换的所有权。

调用方技能 (bug-fix / test-run / code-review / code-refactor)
     │
     ├── 准备报告数据
     ├── 路由到 project-docs-gen（报告渲染模式）
     │      ├── 从 templates/ 加载模板
     │      ├── 用数据填充模板
     │      ├── 写入 docs/report/{YYYYMMDD}_{HHmm}_{模块}_{类型}.md
     │      ├── 更新产物清单（不改变阶段）
     │      └── 返回调用方技能
     └── 继续自己的工作流（路由到 test-run、code-review 等）

报告路径约定

docs/report/{YYYYMMDD}_{HHmm}_{模块名}_{类型}.md

类型后缀：bug-fix | refactor | test-execution | code-review | doc-gen

{HHmm} 组件确保同一天多次运行时文件不会覆盖。

12 个技能

规划与定义

技能 职责 入口阶段 下一阶段
project-requirements-analysis 将模糊的请求转换为完整、可测试的需求和验收标准 REQUIREMENTS_ANALYSIS REQUIREMENTS_APPROVAL
project-requirements-change 以可控、可追溯的方式管理已批准需求的变更 REQUIREMENT_CHANGE REQUIREMENTS_ANALYSIS（决策后）
project-design-analysis 基于已批准需求设计和验证技术方案 TECHNICAL_DESIGN DESIGN_APPROVAL
project-task-arrange 创建、维护、终结和取消任务文档（单一状态源） INIT / TASK_BREAKDOWN / FINAL_ACCEPTANCE 多样化

实现与维护

技能 职责 入口阶段 下一阶段
project-code-dev 按照已批准的产物和项目约定执行实现任务 DEVELOPMENT TEST_GENERATION / TEST_EXECUTION
project-bug-fix 以最小变更范围复现、诊断、修复和验证缺陷 BUG_FIX TEST_EXECUTION
project-code-refactor 在保持业务行为的前提下改进代码结构 REFACTOR TEST_EXECUTION

验证

技能 职责 入口阶段 下一阶段
project-test-gen 从需求或维护来源生成单元、集成和 API 测试 TEST_GENERATION TEST_EXECUTION
project-test-run 执行测试、分析失败、路由修复、生成执行报告 TEST_EXECUTION CODE_REVIEW / FINAL_ACCEPTANCE（跟踪）；结束（不跟踪）

质量与交付

技能 职责 入口阶段 下一阶段
project-code-review 最终质量门禁：可追溯性、设计合规性、架构、代码质量、安全、性能、测试覆盖 CODE_REVIEW FINAL_ACCEPTANCE（跟踪）；结束（不跟踪）
project-docs-gen 生成面向用户的文档（README、API 文档等）和工作流报告 DOC_GENERATION（文档工作流）；保持（报告渲染） FINAL_ACCEPTANCE / 保持

编排

技能 职责
project-workflow-orchestrator 根据意图分类请求、确定跟踪模式、验证所需产物、路由到合适的技能，不执行实现工作

SDLC 工作流

功能交付（跟踪）

task-arrange（初始化任务文档）
  → requirements-analysis
  → 需求审批（人工门禁）
  → design-analysis
  → 方案审批（人工门禁）
  → task-arrange（拆解任务）
  → code-dev
  → test-gen（需要补全覆盖时）
  → test-run
  → code-review
  → 最终验收（人工门禁）
  → task-arrange（终结工作流）
  → COMPLETED

需求变更（跟踪）

requirements-change
  → task-arrange（如缺失则初始化）
  → requirements-analysis
  → 需求审批（人工门禁）
  → design-analysis（设计受影响时）
  → 方案审批（设计变更时）
  → task-arrange（更新任务拆解）
  → code-dev
  → test-gen（需要时）
  → test-run
  → code-review
  → 最终验收
  → task-arrange（终结工作流）
  → COMPLETED

Bug 修复

bug-fix
  → test-run
  → code-review（请求审查或风险较高时）
  → 跟踪：最终验收 → task-arrange 终结 → COMPLETED
  → 不跟踪：输出验证结果和报告，结束

重构

code-refactor
  → test-run
  → code-review（请求审查或风险较高时）
  → 跟踪：最终验收 → task-arrange 终结 → COMPLETED
  → 不跟踪：输出重构结果和报告，结束

测试执行

test-gen（需要增加测试时）
  → test-run
  → 跟踪：最终验收 → task-arrange 终结 → COMPLETED
  → 不跟踪：输出测试报告，结束

文档生成

docs-gen
  → 最终验收（跟踪时）
  → task-arrange（终结跟踪工作流）
  → COMPLETED
  → 不跟踪：输出文档，结束

代码审查

code-review
  → 跟踪：最终验收 → task-arrange 终结 → COMPLETED
  → 不跟踪：输出审查报告，结束

跟踪模式

每个 BUG、TEST 和 REVIEW 请求在分类时确定跟踪模式：

模式 适用条件 任务文档规则 结束规则
跟踪（Tracked） 用户要求跟踪，或现有任务文档明确匹配当前工作项 同步匹配的任务文档，包含阶段转换 使用 Final Acceptance，然后终结为 COMPLETED
不跟踪（Untracked） 一次性审查、单次测试运行或轻量维护操作 不创建或修改任何任务文档 输出报告和结果后结束；无需工作流审批门禁
升级（Escalated） 工作扩展为多步骤的跟踪项目、业务含义变更或实质性架构变更 在继续之前初始化或恢复匹配的任务文档 通过适用的跟踪工作流路由

规则：

  • 任务文档的存在本身不足以触发跟踪。在更新之前，确认其模块、工作项或记录的上下文匹配当前请求。
  • 无论跟踪模式如何，报告始终生成，确保工程可追溯性。
  • 不跟踪的工作若升级为更大规模的工作，通过初始化任务文档转换为跟踪模式。

阶段管理

规范阶段值

阶段码 含义
INIT 任务文档已初始化
REQUIREMENTS_ANALYSIS 需求分析中
REQUIREMENTS_APPROVAL 等待需求审批
REQUIREMENT_CHANGE 已批准需求变更中
TECHNICAL_DESIGN 技术方案设计中
DESIGN_APPROVAL 等待方案审批
TASK_BREAKDOWN 任务拆解中
DEVELOPMENT 代码实现中
TEST_GENERATION 测试生成中
TEST_EXECUTION 测试执行中
BUG_FIX 缺陷诊断/修复中
REFACTOR 重构中
CODE_REVIEW 代码审查中
DOC_GENERATION 文档生成中
FINAL_ACCEPTANCE 等待最终验收
COMPLETED 工作流已完成
CANCELLED 工作流已取消

阶段转换协议

当规范任务文档存在且匹配当前的跟踪工作流时：

  1. 在工作开始前将 Current Phase 设置为技能入口阶段。
  2. 在工作过程中记录任务状态、产物、上下文快照、恢复上下文和下一步动作。
  3. 在将工作移交给其他技能或等待审批门禁之前，将 Current Phase 设置为下一阶段。
  4. 记录阻塞项，不得假装下一阶段已开始。
  5. 在最终验收或显式取消后，通过 task-arrange 路由跟踪工作流以记录终结阶段。

阶段转换表

INIT → 请求的工作流阶段
REQUIREMENTS_ANALYSIS → REQUIREMENTS_APPROVAL
REQUIREMENT_CHANGE → REQUIREMENTS_ANALYSIS（决策后）
TECHNICAL_DESIGN → DESIGN_APPROVAL
TASK_BREAKDOWN → DEVELOPMENT
DEVELOPMENT → TEST_GENERATION 或 TEST_EXECUTION
TEST_GENERATION → TEST_EXECUTION
TEST_EXECUTION → CODE_REVIEW 或 FINAL_ACCEPTANCE（跟踪）；结束（不跟踪）
BUG_FIX → TEST_EXECUTION
REFACTOR → TEST_EXECUTION
CODE_REVIEW → FINAL_ACCEPTANCE（跟踪）；结束（不跟踪）
DOC_GENERATION → FINAL_ACCEPTANCE（文档工作流）；保持（报告渲染）
FINAL_ACCEPTANCE → COMPLETED（通过 task-arrange 终结）
任意非终结阶段 → CANCELLED（通过显式取消）

任务文档

位于 docs/task/{YYYYMMDD}_{模块名}_task.md 的规范任务文档是单一状态源。

必需章节

  1. 项目概览 — 功能名称、当前阶段（来自规范阶段值）
  2. 流程状态总览 — 可追溯性状态：需求分析、需求审批、技术方案设计、设计审批、任务拆分、开发实现、测试生成、测试执行、代码评审、最终验收、流程终结
  3. 流程终结记录 — 终结状态、决策类型、决策人、决策时间、原因
  4. 产物清单 — 所有交付物及其路径和状态
  5. 上下文快照 — 当前需求、设计组件、任务、修改文件、待确认问题、已知限制
  6. 恢复上下文 — 阶段、当前任务、最近操作、下一步动作、恢复指令
  7. 下一步动作 — 明确的下一步操作
  8. 当前任务 — 待处理和进行中的任务及状态标记
  9. 阻塞项 — 编号、描述、状态
  10. 变更记录 — 按时间顺序的事件日志
  11. 可选提交记录
  12. 已完成任务 — 已归档的已完成工作
  13. 历史任务 — 已归档的之前功能

任务状态标记

标记 状态 含义
[ ] 待处理 未开始
[~] 进行中 正在执行
[x] 已完成 已完成
[!] 已阻塞 等待某事
[-] 已取消 不再执行

执行规则

  • 同一时间仅允许一个任务处于进行中。
  • 任务状态必须完成后立即更新。
  • 阻塞任务必须记录阻塞原因。
  • 取消任务必须记录取消原因。

快速开始

第一步：分类请求

用自然语言描述想要做的事情：

用户："分析一下这个新功能的需求"
  → 编排器路由到 project-requirements-analysis

用户："修复这个 NullPointerException"
  → 编排器路由到 project-bug-fix

用户："跑一下单元测试"
  → 编排器路由到 project-test-run

用户："审查一下我刚改的代码"
  → 编排器路由到 project-code-review

用户："重构一下 UserService"
  → 编排器路由到 project-code-refactor

第二步：选择跟踪模式（可选）

对于 BUG、TEST 和 REVIEW 请求：

用户："修复这个NullPointerException，跟踪一下"
  → 跟踪：同步任务文档，走完整工作流

用户："帮我快速看下这段代码"
  → 不跟踪：生成报告，无任务文档，输出后结束

第三步：遵循技能的工作流

每个技能展示一个编号的工作流。按顺序执行步骤。技能会处理：

  • 所需引用文件的加载
  • 任务文档的同步
  • 报告生成（路由到 project-docs-gen）
  • 工作完成后路由到下一技能

第四步：解读结果

技能完成后，你会收到：

  • 对话输出：完成内容的摘要
  • 报告文件：完整详情保存到 docs/report/{日期}_{时间}_{模块}_{类型}.md
  • 下一步动作：接下来应该做什么（路由到下一技能、请求最终验收等）

示例：Bug 修复流程

用户        > "修复登录接口的 NPE"
编排器       > 分类：BUG → 路由到 project-bug-fix
bug-fix     > 1. 记录 bug 信息
            > 2. 复现：堆栈显示 NullPointerException 在 LoginService.authenticate()
            > 3. 定位根因：缺少对用户输入的空值检查
            > 4. 实现修复：添加空值检查
            > 5. 评估回归风险：低，隔离变更
            > 6. 路由到 docs-gen → 报告保存到 docs/report/20260602_1430_login_bug-fix.md
            > 7. 路由到 test-run 进行验证
test-run    > 运行单元测试 → 全部通过
            > 路由到 code-review（跟踪）或输出报告并结束（不跟踪）

文件结构

java-backend-skill/
├── README.md
├── project-workflow-orchestrator/
│   └── SKILL.md
├── project-requirements-analysis/
│   ├── SKILL.md
│   └── templates/
│       └── requirements-doc.md
├── project-requirements-change/
│   └── SKILL.md
├── project-design-analysis/
│   ├── SKILL.md
│   └── templates/
│       └── design-doc.md
├── project-task-arrange/
│   ├── SKILL.md
│   └── templates/
│       └── task-doc.md
├── project-code-dev/
│   ├── SKILL.md
│   └── references/
│       ├── project-principles.md
│       ├── common-code-guidelines.md
│       ├── api-guidelines.md
│       ├── database-guidelines.md
│       ├── testing-guidelines.md
│       ├── security-guidelines.md
│       ├── logging-guidelines.md
│       └── java-spring-guidelines.md
├── project-code-refactor/
│   └── SKILL.md
├── project-bug-fix/
│   └── SKILL.md
├── project-test-gen/
│   ├── SKILL.md
│   └── references/
│       ├── service-unit-test-template.md
│       ├── controller-test-template.md
│       └── integration-test-template.md
├── project-test-run/
│   └── SKILL.md
├── project-code-review/
│   └── SKILL.md
└── project-docs-gen/
    ├── SKILL.md
    └── templates/
        ├── bug-fix-report.md
        ├── refactor-report.md
        ├── test-execution-report.md
        ├── code-review-report.md
        └── doc-gen-report.md

人工审批门禁

以下门禁绝不能绕过：

门禁 前置条件 对应阶段
需求审批 技术方案设计前 REQUIREMENTS_APPROVAL
方案审批 功能实现前 DESIGN_APPROVAL
重构审批 大规模重构前 不适用（范围分类）
最终验收 工作流关闭前 FINAL_ACCEPTANCE

审批门禁仅适用于跟踪工作流。不跟踪的工作流在输出报告后结束，无需审批门禁。

升级路径

当工作超出某个技能的范围时，技能可以升级：

发现内容 路由到
业务期望变更 project-requirements-change
大规模变更缺少架构设计 project-design-analysis
实现缺陷或回归 project-bug-fix
测试覆盖缺失或不足 project-test-gen
测试结果缺失或过期 project-test-run
文档不一致 project-docs-gen

前置依赖

本技能体系专为 Claude Code 环境中的 AI 辅助 Java 后端开发 设计。假设：

  • 使用 Maven 或 Gradle 构建系统的 Java 后端项目
  • Spring Boot（或兼容框架）
  • JUnit 5（或兼容测试框架）
  • 标准项目结构（controller / service / repository / model）
  • 使用 Git 进行版本控制

由 project-docs-gen 生成 — Java 后端开发技能体系概述

About

No description, website, or topics provided.

Resources

Readme
MIT license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors