本技能专为程序员、技术开发从业者量身定制,深度贴合互联网开发全流程工作流,以"解放程序员非编码繁琐工作,聚焦核心业务开发"为宗旨,提供从代码优化、注释生成、技术文档撰写、工作汇报到需求梳理的一站式研发提效能力。
| 模块 | 功能 | 适用场景 |
|---|---|---|
| ------ | ------ | --------- |
| 全语言代码智能优化排错 | 语法错误检测、逻辑漏洞排查、冗余代码精简、运行效率优化 | 日常编码/Code Review/代码重构/性能优化 |
| 全自动标准化代码注释生成 | 逐行添加规范注释,梳理执行逻辑、函数作用、参数含义、返回值 | 接手遗留代码/团队协作/代码交接/开源项目 |
| 技术文档一键速成 | 接口文档、数据库设计文档、技术方案、需求拆解、部署文档 | 前后端联调/技术评审/项目归档/新人Onboarding |
| 研发工作汇报自动撰写 | 日报/周报/版本总结/复盘报告,区分对内团队版和对外汇报版 | 站会/周会/版本回顾/线上事故复盘 |
| 轻量化需求梳理 | 将杂乱需求快速梳理为清晰轻量PRD文档 | 需求评审/前后端对接/快速原型验证 |
本技能支持两种输出风格,用户可随时切换,默认识别用户技术水平后自动匹配:
触发方式:用户输入中包含"新手""简单解释""详细一点""我是实习生""不太懂"等关键词,或代码问题较为基础时自动激活。
输出特点:
触发方式:用户输入中包含"专业模式""简洁""直接给方案""我是高级/资深"等关键词,或代码问题较为复杂时自动激活。
输出特点:
用户可直接输入"切换到简易模式""切换到专业模式""用简易模式输出""用专业模式输出"等指令进行手动切换。单次会话中模式状态保持,直至用户再次切换。
支持 Java、Python、Go、JavaScript/TypeScript、Vue、React、HTML、(S)CSS、SQL 等主流前后端编程语言及框架。粘贴任意长度的代码片段,自动完成语法错误检测、逻辑漏洞排查、冗余无效代码精简、运行效率优化,精准定位问题行并给出修改方案。
| 类别 | 支持范围 |
|---|---|
| ------ | --------- |
| 后端语言 | Java(Spring Boot/Spring Cloud)、Python(Django/Flask/FastAPI)、Go(Gin/Echo/Kitex)、Node.js(Express/Nest.js) |
| 前端框架 | JavaScript/TypeScript、Vue 2/3(Composition API)、React(Hooks/Class)、HTML5、CSS3/SCSS/Less |
| 数据层 | SQL(MySQL/PostgreSQL)、MyBatis、JPA/Hibernate、SQLAlchemy、GORM |
| 构建工具 | Webpack、Vite、Maven、Gradle、Go Modules、pip/poetry |
| 字段 | 说明 | 必填 |
|---|---|---|
| ------ | ------ | ------ |
| 代码片段 | 需要分析优化的源代码,支持粘贴多文件 | 是 |
| 编程语言/框架 | 代码所属语言及框架 | 否(可自动识别) |
| 运行环境 | 运行时版本信息(如 JDK 17、Python 3.11、Node 20) | 否 |
| 错误描述 | 已知的报错信息或异常堆栈 | 否 |
| 优化关注点 | 性能/可读性/安全性/内存,多选则综合评估 | 否(默认全维度) |
## 代码分析报告
### 检测到的问题(按严重程度排序)
#### 问题1:[严重程度] 问题标题
- 问题行号:第X行
- 问题类型:语法错误/逻辑漏洞/性能瓶颈/冗余代码/安全隐患
- 问题描述:[用通俗语言解释问题是什么]
- 为什么这是问题:[对新手友好的原理说明]
- 修复方案:
// 修复前
[原始代码行]
// 修复后
[优化后代码]
- 优化说明:[解释改动的原理和收益]
#### 问题2:...
...
### 优化总结
- 共发现 X 个问题,其中严重问题 Y 个
- 预估性能提升:约 Z%
## 代码审查
### 致命/严重
| 行号 | 类型 | 问题 | 修复方案 |
|------|------|------|---------|
| L42 | NPE风险 | user未判空直接调用getAddress() | 加@Nullable + Optional |
| L78 | SQL注入 | 字符串拼接SQL | 改用参数化查询 |
### 优化建议
| 行号 | 类型 | 当前写法 | 建议写法 | 收益 |
|------|------|---------|---------|------|
| L105 | 性能 | for循环内new对象 | 提取到循环外/对象池 | 减少GC压力 |
### 冗余代码
- L120-L135:与 L50-L65 逻辑重复,建议抽取公共方法
- L200-L203:未使用的import,建议删除
### 一图胜千言
[核心问题根因一句话总结]
对无注释、注释不全的工程代码,按照行业统一开发规范(参照 Google Style Guide / Alibaba Java Coding Guidelines / JSDoc / PEP 257 等标准),自动逐行/逐段添加清晰易懂的代码注释。梳理代码执行逻辑、函数作用、参数含义、返回值说明、异常处理等,适配团队项目统一代码规范。
| 字段 | 说明 | 必填 |
|---|---|---|
| ------ | ------ | ------ |
| 源代码 | 需要添加注释的代码片段 | 是 |
| 语言/框架 | 代码所属语言 | 否(自动识别) |
| 注释风格偏好 | JSDoc / JavaDoc / Docstring / 行注释 等 | 否(默认按语言标准) |
| 注释语言 | 中文注释 / 英文注释 | 否(默认中文) |
| 注释详细度 | 精简版(仅函数签名)/ 标准版 / 详细版(含实现逻辑说明) | 否(默认标准版) |
/**
* 根据用户ID列表批量查询用户信息,支持分页和排序。
*
* <p>查询逻辑:
* <ol>
* <li>校验userIdList非空且不超过1000条(避免IN查询过长)</li>
* <li>构建分页条件(默认第1页,每页20条)</li>
* <li>按指定字段排序后查询数据库</li>
* <li>将DO列表转换为DTO列表返回</li>
* </ol>
*
* @param userIdList 用户ID列表,不能为空且长度不超过1000
* @param pageNo 页码,从1开始,默认1
* @param pageSize 每页条数,默认20,最大100
* @param orderBy 排序字段,可选值:{@code "createTime"}, {@code "updateTime"}, {@code "name"}
* @return 分页的用户信息列表,userIdList为空时返回空Page对象
* @throws IllegalArgumentException 当userIdList为null或超过1000条时抛出
* @throws DataAccessException 数据库查询异常时抛出
*/
public PageResult<UserDTO> batchQueryUsers(
List<Long> userIdList,
int pageNo,
int pageSize,
String orderBy) {
// 参数校验
if (userIdList == null || userIdList.size() > 1000) {
throw new IllegalArgumentException("userIdList不能为空且不超过1000条");
}
// ... 实现代码
}
def merge_intervals(intervals: List[List[int]]) -> List[List[int]]:
"""合并所有重叠的区间,返回不重叠的区间数组。
算法流程:
1. 按区间起点升序排序
2. 遍历排序后的区间,依次比较当前区间起点与已合并区间终点:
- 若有重叠(cur_start <= last_end),扩展合并区间终点为 max(last_end, cur_end)
- 若无重叠,将当前区间加入结果列表
Args:
intervals: 区间列表,每个区间为 [start, end] 格式,start <= end
Returns:
合并后的不重叠区间列表,保证有序
Raises:
ValueError: 当输入区间格式不正确时抛出
Example:
>>> merge_intervals([[1,3], [2,6], [8,10], [15,18]])
[[1, 6], [8, 10], [15, 18]]
Time Complexity: O(n log n),主要耗时在排序
Space Complexity: O(n),结果列表所需空间
"""
if not intervals:
return []
# 按区间起点升序排列
intervals.sort(key=lambda x: x[0])
merged = [intervals[0]]
for current in intervals[1:]:
last = merged[-1]
if current[0] <= last[1]: # 存在重叠
last[1] = max(last[1], current[1])
else:
merged.append(current)
return merged
<!--
用户搜索下拉选择器组件
@component UserSearchSelect
@description 支持远程搜索、防抖输入、多选/单选、虚拟滚动
@prop {Array} value - v-model 绑定的选中值,单选为 Object,多选为 Array
@prop {Boolean} multiple - 是否开启多选模式,默认 false
@prop {Number} debounceDelay - 防抖延迟(ms),默认 300
@event search - 用户输入搜索词时触发,参数:(keyword: string)
@event select - 选中用户时触发,参数:(user: UserInfo)
@slot default - 自定义选项渲染内容
@slot empty - 搜索无结果时的自定义展示
-->
<template>
<div class="user-search-select">
<!-- 输入框区域:支持防抖输入和清空操作 -->
<el-select
v-model="selectedValue"
:multiple="multiple"
filterable
remote
:remote-method="handleSearch"
:loading="loading"
placeholder="请输入用户名或工号搜索"
>
<!-- 选项列表 -->
<el-option
v-for="user in userList"
:key="user.id"
:label="`${user.name}(${user.staffId})`"
:value="user"
/>
</el-select>
</div>
</template>
快速生成后端接口详细文档、数据库结构设计文档、项目技术实现方案、需求拆解分析文档、项目部署流程文档,格式规整符合企业技术文档归档标准。支持 Markdown 为主要输出格式,可辅助生成 Swagger/OpenAPI 规范文档。
| 文档类型 | 适用场景 | 输出格式 |
|---|---|---|
| --------- | --------- | --------- |
| 后端接口文档 | 前后端联调、API 对接、第三方集成 | Markdown / OpenAPI YAML |
| 数据库设计文档 | 表结构评审、DBA审核、数据迁移 | Markdown(含ER图描述) |
| 技术实现方案 | 技术评审、架构决策记录 | Markdown |
| 需求拆解分析 | 需求评审、任务拆分、工时评估 | Markdown |
| 项目部署文档 | 运维交接、环境搭建、CI/CD配置 | Markdown |
| 字段 | 说明 | 必填 |
|---|---|---|
| ------ | ------ | ------ |
| 接口基础信息 | 接口名称、请求方式(GET/POST/PUT/DELETE)、URL路径 | 是 |
| 请求参数 | 参数名、类型、必填/可选、说明、示例值 | 是 |
| 响应结构 | 返回值结构、字段含义 | 是 |
| 错误码列表 | 各错误码及对应说明 | 否 |
| 鉴权方式 | Token/Cookie/Signature等 | 否 |
# [模块名] 接口文档
## 接口概览
| 序号 | 接口名称 | 请求方式 | URL | 鉴权 |
|------|---------|---------|-----|------|
| 1 | 获取用户列表 | GET | /api/v1/users | Bearer Token |
| 2 | 创建用户 | POST | /api/v1/users | Bearer Token |
| 3 | 更新用户信息 | PUT | /api/v1/users/{id} | Bearer Token |
| 4 | 删除用户 | DELETE | /api/v1/users/{id} | Bearer Token |
---
## 接口详情
### 1. 获取用户列表
**基本信息**
- 请求方式:`GET`
- 请求路径:`/api/v1/users`
- 接口说明:分页查询用户列表,支持按用户名、状态筛选
- 鉴权方式:Bearer Token(Header: `Authorization: Bearer <token>`)
**请求参数**
| 参数名 | 类型 | 必填 | 位置 | 说明 | 示例值 |
|--------|------|------|------|------|--------|
| pageNo | Integer | 否 | Query | 页码,从1开始,默认1 | 1 |
| pageSize | Integer | 否 | Query | 每页条数,默认20,最大100 | 20 |
| keyword | String | 否 | Query | 用户名/手机号模糊搜索 | "张三" |
| status | Integer | 否 | Query | 用户状态:0-禁用 1-启用 | 1 |
**请求示例**
curl -X GET "https://api.example.com/api/v1/users?pageNo=1&pageSize=20&keyword=张三&status=1" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..."
**响应结构**
| 字段路径 | 类型 | 说明 | 示例值 |
|---------|------|------|--------|
| code | Integer | 业务状态码,0表示成功 | 0 |
| message | String | 提示信息 | "success" |
| data | Object | 响应数据体 | |
| data.total | Long | 总记录数 | 156 |
| data.pageNo | Integer | 当前页码 | 1 |
| data.pageSize | Integer | 每页条数 | 20 |
| data.list | Array | 用户列表 | |
| data.list[].id | Long | 用户ID | 10001 |
| data.list[].name | String | 用户名 | "张三" |
| data.list[].email | String | 邮箱 | "zhangsan@example.com" |
| data.list[].status | Integer | 状态:0-禁用 1-启用 | 1 |
| data.list[].createTime | String | 创建时间(yyyy-MM-dd HH:mm:ss) | "2026-05-19 10:30:00" |
**成功响应示例**
{
"code": 0,
"message": "success",
"data": {
"total": 156,
"pageNo": 1,
"pageSize": 20,
"list": [
{
"id": 10001,
"name": "张三",
"email": "zhangsan@example.com",
"status": 1,
"createTime": "2026-05-19 10:30:00"
}
]
}
}
**错误码说明**
| 错误码 | HTTP状态码 | 说明 | 处理建议 |
|--------|-----------|------|---------|
| 0 | 200 | 成功 | - |
| 1001 | 401 | Token无效或已过期 | 重新登录获取Token |
| 1002 | 403 | 无权限访问 | 联系管理员开通权限 |
| 2001 | 400 | 参数校验失败 | 检查请求参数格式 |
| 5000 | 500 | 服务器内部错误 | 联系后端排查 |
---
[其他接口按相同格式逐一列出]
# [项目名] 数据库设计文档
## 版本信息
| 版本 | 日期 | 修改人 | 修改说明 |
|------|------|--------|---------|
| v1.0 | 2026-05-19 | 张三 | 初始版本 |
## 数据库概览
- 数据库类型:MySQL 8.0
- 字符集:utf8mb4
- 排序规则:utf8mb4_unicode_ci
- 引擎:InnoDB
## 表结构设计
### 1. user_info(用户信息表)
| 字段名 | 类型 | 长度 | 允许空 | 默认值 | 主键 | 索引 | 说明 |
|--------|------|------|--------|--------|------|------|------|
| id | BIGINT | - | NO | - | PK | - | 主键ID,自增 |
| username | VARCHAR | 50 | NO | - | - | UK | 用户名,唯一 |
| password_hash | VARCHAR | 128 | NO | - | - | - | 密码哈希值(bcrypt) |
| email | VARCHAR | 100 | YES | NULL | - | IDX | 邮箱 |
| phone | VARCHAR | 20 | YES | NULL | - | IDX | 手机号 |
| avatar_url | VARCHAR | 500 | YES | NULL | - | - | 头像URL |
| status | TINYINT | - | NO | 1 | - | IDX | 状态:0-禁用 1-启用 |
| role | VARCHAR | 20 | NO | 'USER' | - | - | 角色:USER/ADMIN |
| last_login_time | DATETIME | - | YES | NULL | - | - | 最后登录时间 |
| create_time | DATETIME | - | NO | CURRENT_TIMESTAMP | - | IDX | 创建时间 |
| update_time | DATETIME | - | NO | CURRENT_TIMESTAMP | - | - | 更新时间(ON UPDATE) |
**索引设计**
| 索引名 | 类型 | 字段 | 说明 |
|--------|------|------|------|
| PRIMARY | 主键 | id | 主键索引 |
| uk_username | 唯一索引 | username | 用户名唯一约束 |
| idx_email | 普通索引 | email | 邮箱查询优化 |
| idx_phone | 普通索引 | phone | 手机号查询优化 |
| idx_status | 普通索引 | status | 状态筛选优化 |
| idx_create_time | 普通索引 | create_time | 按创建时间排序优化 |
**表关联关系**
user_info (1) ──< (N) user_login_log (用户登录日志)
user_info (1) ──< (N) user_role_rel (用户角色关联)
user_info (1) ──┬── (1) user_profile (用户资料扩展,垂直拆分)
└── (N) order_main (用户订单)
**建表DDL**
CREATE TABLE user_info (
id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID',
username VARCHAR(50) NOT NULL COMMENT '用户名',
password_hash VARCHAR(128) NOT NULL COMMENT '密码哈希',
email VARCHAR(100) DEFAULT NULL COMMENT '邮箱',
phone VARCHAR(20) DEFAULT NULL COMMENT '手机号',
avatar_url VARCHAR(500) DEFAULT NULL COMMENT '头像URL',
status TINYINT NOT NULL DEFAULT 1 COMMENT '状态:0-禁用 1-启用',
role VARCHAR(20) NOT NULL DEFAULT 'USER' COMMENT '角色',
last_login_time DATETIME DEFAULT NULL COMMENT '最后登录时间',
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (id),
UNIQUE KEY uk_username (username),
KEY idx_email (email),
KEY idx_phone (phone),
KEY idx_status (status),
KEY idx_create_time (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户信息表';
---
[其他表按相同格式逐一列出]
# [功能/模块名] 技术实现方案
## 文档信息
| 属性 | 内容 |
|------|------|
| 方案名称 | [功能名] 技术实现方案 |
| 作者 | [姓名] |
| 创建日期 | 2026-05-19 |
| 评审状态 | 待评审/评审通过/已驳回 |
| 关联需求 | [需求编号/PRD链接] |
## 1. 背景与目标
### 1.1 业务背景
[一句话描述为什么要做这个功能,解决了什么业务痛点]
### 1.2 技术目标
- 性能目标:[如 QPS ≥ 1000]
- 可用性目标:[如 99.9% SLA]
- 一致性目标:[如 最终一致性,延迟 < 500ms]
## 2. 技术选型
| 组件 | 选型 | 备选方案 | 选型理由 |
|------|------|---------|---------|
| 消息队列 | RocketMQ | Kafka/RabbitMQ | 团队技术栈统一,运维成熟 |
| 缓存 | Redis Cluster | Memcached | 丰富数据结构和持久化支持 |
| 搜索引擎 | Elasticsearch 8.x | Solr | 社区活跃,生态完善 |
## 3. 系统架构
### 3.1 架构图(文字描述)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Nginx/CDN │────▶│ API Gateway │────▶│ 业务服务集群 │
└──────────────┘ └──────────────┘ └──────┬───────┘
│
┌─────────────────────────────┼──────────────┐
│ │ │ │
┌─────▼────┐ ┌─────▼────┐ ┌─────▼────┐ ┌─────▼────┐
│ Redis │ │ MySQL │ │ RocketMQ │ │ ES │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
### 3.2 核心流程
**主流程时序:**
1. 客户端发起请求 → API Gateway 鉴权&限流
2. 业务服务校验参数 → 查询Redis缓存
3. 缓存命中 → 直接返回;缓存未命中 → 查询MySQL
4. MySQL结果写入Redis(TTL 5min)→ 返回客户端
5. 写操作 → 先写MySQL → 异步发MQ → 消费者更新ES/清除缓存
## 4. 数据库设计变更
[新增表结构 / 表字段变更 / 索引调整]
## 5. 接口设计
[参见接口文档章节]
## 6. 风险评估
| 风险项 | 影响 | 概率 | 应对策略 |
|--------|------|------|---------|
| 高并发击穿缓存 | 数据库压力飙升 | 中 | 热点Key永不过期 + 互斥锁 |
| 消息队列积压 | 数据延迟 | 低 | 消费者弹性扩容 + 死信队列兜底 |
## 7. 上线计划
| 阶段 | 内容 | 负责人 | 预计时间 |
|------|------|--------|---------|
| 开发 | 编码+自测 | 开发 | D1-D5 |
| 联调 | 前后端联调 | 前后端 | D6-D7 |
| 测试 | 功能测试+压测 | QA | D8-D9 |
| 灰度 | 5% → 20% → 100% | SRE | D10-D12 |
# [项目名] 部署运维文档
## 环境说明
| 环境 | 用途 | 服务器 | 配置 |
|------|------|--------|------|
| DEV | 开发自测 | 10.x.x.x | 2C4G |
| TEST | 功能测试 | 10.x.x.x | 4C8G |
| STAGING | 预发布 | 10.x.x.x | 4C8G |
| PROD | 生产环境 | [负载均衡IP] | 8C16G × 3 |
## 部署架构
- 部署方式:Kubernetes + Docker
- 容器编排:K8s Deployment(3副本)
- 服务暴露:K8s Service + Ingress
- 配置管理:K8s ConfigMap + Secret
- 日志收集:Filebeat → Elasticsearch → Kibana
- 监控告警:Prometheus + Grafana + AlertManager
## 环境依赖
| 依赖服务 | 版本 | 地址 | 用途 |
|---------|------|------|------|
| JDK | 17 | - | 运行环境 |
| MySQL | 8.0.33 | mysql-prod.internal:3306 | 主数据库 |
| Redis | 7.0 | redis-cluster.internal:6379 | 缓存 |
| RocketMQ | 5.1 | mq-namesrv.internal:9876 | 消息队列 |
| Nacos | 2.2 | nacos.internal:8848 | 配置中心/注册中心 |
## 部署步骤
### 1. 构建镜像
mvn clean package -DskipTests -Pprod
docker build -t registry.internal.com/project/service:v1.2.0 .
docker push registry.internal.com/project/service:v1.2.0
### 2. K8s部署
kubectl set image deployment/service-name \
service-name=registry.internal.com/project/service:v1.2.0 \
-n production
kubectl rollout status deployment/service-name -n production
### 3. 健康检查
kubectl get pods -n production | grep service-name
curl -s http://service-name.production.svc.cluster.local:8080/actuator/health
## 回滚方案
kubectl rollout undo deployment/service-name -n production
kubectl rollout undo deployment/service-name --to-revision=3 -n production
## 常见问题排查
### 问题1:服务启动失败
- 排查步骤:`kubectl describe pod <pod-name> -n production`
- 常见原因:ConfigMap未更新、数据库连接失败、端口冲突
### 问题2:内存持续增长
- 排查步骤:`kubectl top pod -n production`
- 常见原因:内存泄漏、未限制JVM堆大小、大对象未及时GC
输入本周开发进度、完成功能、迭代内容、遇到问题、下周开发计划等基础信息,自动生成开发日报、项目迭代周报、版本开发总结、线上问题复盘报告。区分对内团队版和对外项目汇报版两种格式。
| 字段 | 说明 | 必填 |
|---|---|---|
| ------ | ------ | ------ |
| 汇报类型 | 日报/周报/版本总结/复盘报告 | 是 |
| 岗位/角色 | 前端/后端/全栈/测试/运维/PM | 是 |
| 项目名称 | 所属项目/模块名称 | 是 |
| 汇报周期 | 日报日期 / 周报起止日期 | 是 |
| 本周/本期完成工作 | 已完成的任务列表及进度 | 是 |
| 未完成工作 | 计划但未完成的事项及原因 | 否 |
| 遇到问题 | 阻塞项、技术难点、协作问题 | 否 |
| 数据指标 | 代码提交量、Bug修复数、性能提升数据等 | 否 |
| 下周/下期计划 | 下阶段工作安排 | 否 |
| 汇报对象 | 团队内部 / 项目领导 / 产品经理 / 外部客户 | 否 |
适用于站会同步、团队周会、内部IM群汇报。风格直接、技术向、重协作。
## [项目名] 研发周报 | 05.12 - 05.16
### 本周产出
**需求开发**
- [x] 用户管理模块CRUD接口开发 —— 已提测,接口文档已同步
- [x] 登录注册流程优化(接入短信验证码) —— 已上线
- [x] 订单列表性能优化(索引调整+缓存预热) —— 接口耗时从2.3s降至120ms
**Bug修复**
- [x] #BUG-1023: 并发创建订单偶发主键冲突 —— 分布式ID改用雪花算法
- [x] #BUG-1089: 用户头像上传OOM —— 增加图片压缩+尺寸限制
**技术优化**
- [x] 慢SQL治理:梳理TOP10慢查询,已优化6个(4个待DBA加索引)
- [x] CI/CD流水线:接入自动化接口测试,MR合并前强制通过
### Blockers / 风险
| 阻塞项 | 影响范围 | 当前状态 | 需要支持 |
|--------|---------|---------|---------|
| DBA索引变更审批 | 4个慢SQL优化 | 等待DBA排期 | @DBA团队 帮忙加急 |
### 下周计划
1. 支付模块对账接口开发(P0,预计周三提测)
2. 消息推送服务从轮询改为WebSocket长连接(P1,技术调研阶段)
3. 配合QA完成用户模块回归测试
### 技术分享
- 本周五16:00 分享《订单模块性能优化实战》,会议室3,欢迎参加
---
> 提交代码:32 commits | 新增/修改文件:15 | Code Review:4个MR |
> 感觉这周和阿里的雪花算法死磕了三天,终于搞定了分布式ID方案 🫠
适用于向PM、业务方、项目领导、外部客户汇报。风格结构化、突出里程碑、强调价值交付。
# [项目名] 项目迭代周报
**汇报周期:** 2026年5月12日 — 2026年5月16日
**汇报人:** 张三(后端开发)
**项目阶段:** 迭代三 — 核心功能开发阶段(计划5月30日完成)
---
## 一、整体进度概览
| 维度 | 计划 | 实际 | 偏差 |
|------|------|------|------|
| 需求完成率 | 85% | 82% | -3%(预计下周追回) |
| Bug修复率 | 95% | 92% | -3% |
| 提测准时率 | 100% | 100% | - |
## 二、本周关键产出
### 2.1 已交付功能
| 功能模块 | 完成内容 | 交付状态 | 备注 |
|---------|---------|---------|------|
| 用户管理 | 用户CRUD、批量导入导出 | ✅ 已提测 | - |
| 登录注册 | 支持手机号+短信验证码登录 | ✅ 已上线 | 验证码成功率98.5% |
| 订单列表 | 查询性能优化 | ✅ 已上线 | 接口响应速度提升19倍 |
### 2.2 核心数据
- 本周代码提交:32次
- 修复Bug:5个
- Code Review MR:4个
- 订单列表接口耗时:2.3s → 120ms(优化幅度94.8%)
## 三、风险与问题
| 风险等级 | 问题描述 | 影响 | 应对方案 | 需协调方 |
|---------|---------|------|---------|---------|
| 中 | 数据库索引变更流程阻塞 | 慢SQL优化延期 | 已同步DBA团队申请加急 | DBA团队 |
| 低 | 短信通道供应商涨价 | 月度成本增加约5% | 已启动备选供应商POC | 采购 |
## 四、下周计划
| 优先级 | 计划事项 | 预期产出 | 预计完成时间 |
|--------|---------|---------|-------------|
| P0 | 支付模块对账接口开发 | 接口文档 + 代码提测 | 5月21日 |
| P1 | 消息推送WebSocket改造 | 技术方案评审通过 | 5月23日 |
| P2 | 用户模块回归测试配合 | 回归测试通过 | 5月23日 |
---
> 整体进度可控,预计不影响5月30日迭代三交付里程碑。
# [问题标题] 线上事故复盘报告
## 基本信息
| 项目 | 内容 |
|------|------|
| 事故等级 | P0(核心功能不可用)/ P1(部分功能受损)/ P2(体验问题) |
| 发生时间 | 2026-05-19 14:32 |
| 发现时间 | 2026-05-19 14:35(监控告警自动发现) |
| 恢复时间 | 2026-05-19 15:02 |
| 持续时长 | 27分钟 |
| 影响范围 | [具体影响的用户群/功能范围/业务指标] |
| 事故负责人 | [姓名] |
## 一、事故经过(时间线)
| 时间 | 事件 |
|------|------|
| 14:30 | [事件触发点描述] |
| 14:32 | 用户开始反馈[现象] |
| 14:35 | 监控告警[告警名称]触发,值班人员[姓名]接警 |
| 14:38 | 初步定位问题为[初步判断] |
| 14:45 | 启动应急预案:[预案内容] |
| 14:55 | 修复方案验证通过 |
| 15:00 | 开始灰度恢复 |
| 15:02 | 服务全面恢复,监控指标回归正常 |
## 二、根因分析
[直接原因]:xxx
[根本原因]:xxx(用5 Whys方法追溯)
## 三、改进措施
| 序号 | 措施 | 类型 | 负责人 | 截止时间 | 状态 |
|------|------|------|--------|---------|------|
| 1 | [临时措施] | 止血 | @张三 | 5月19日 | ✅ 已完成 |
| 2 | [短期措施] | 修复 | @李四 | 5月21日 | 🔄 进行中 |
| 3 | [长期措施] | 预防 | @王五 | 5月30日 | ⏳ 待开始 |
## 四、经验教训
- [Takeaway 1]
- [Takeaway 2]
把杂乱零散的口头需求、聊天记录中的需求讨论、简易需求草稿,快速梳理整理成清晰简洁的轻量化PRD产品需求文档。不追求大而全的重型PRD,聚焦"能说清楚、能对上、能开发"三个核心目标,方便前后端开发对接沟通。
| 字段 | 说明 | 必填 |
|---|---|---|
| ------ | ------ | ------ |
| 需求原始内容 | 口头描述、聊天记录、需求草稿等 | 是 |
| 需求来源 | 产品经理/运营/老板/用户反馈/数据分析 | 否 |
| 目标平台 | Web/App/小程序/后台管理等 | 否 |
| 优先级感知 | 用户对需求紧迫度的描述 | 否 |
# [需求名称] 轻量PRD
## 文档信息
| 属性 | 内容 |
|------|------|
| 需求名称 | [一句话概括需求] |
| 版本 | v1.0 |
| 整理日期 | 2026-05-19 |
| 需求来源 | [来源说明] |
| 优先级 | P0(必须做)/ P1(应该做)/ P2(锦上添花) |
| 目标平台 | Web / iOS / Android / 小程序 / 后台 |
---
## 一、需求背景
### 用户故事
**作为** [角色,如普通用户/管理员/运营],
**我希望** [做什么操作/完成什么目标],
**以便** [获得什么价值/解决什么问题]。
### 业务价值
- [一句话说明这个需求为什么重要]
- [关联的业务指标/OKR]
## 二、核心流程
[用简洁的文字/ASCII流程图描述核心操作流程]
用户进入页面 → 点击[按钮] → 弹出[表单/选择器] → 填写/选择 → 提交 → 结果反馈
## 三、功能详情
### 3.1 功能点列表
| 序号 | 功能点 | 描述 | 优先级 | 复杂度 |
|------|--------|------|--------|--------|
| 1 | [功能点名称] | [一句话描述] | P0 | 中 |
| 2 | [功能点名称] | [一句话描述] | P1 | 低 |
### 3.2 核心功能详述
#### 功能点1:[名称]
**触发条件:** [用户在什么场景/条件下触发]
**交互流程:**
1. 用户操作:[操作步骤]
2. 系统反馈:[前端/后端响应行为]
3. 完成状态:[成功/失败的终态表现]
**规则说明:**
- [业务规则1:如"同一用户24小时内最多操作3次"]
- [业务规则2:如"金额超过5000元触发风控审核"]
**异常处理:**
| 异常场景 | 处理方式 |
|---------|---------|
| 网络异常 | Toast提示"网络开小差了,请重试" |
| 数据为空 | 展示空状态插画 + "暂无数据" |
**边界条件:**
- [输入上下限、字符限制、时间范围等]
### 3.3 数据字段
| 字段名 | 类型 | 必填 | 说明 | 校验规则 |
|--------|------|------|------|---------|
| name | String | 是 | 名称 | 1-20字符 |
| phone | String | 是 | 手机号 | 11位数字 |
## 四、UI/交互要点
- [页面布局简述:顶部筛选项 + 中部列表 + 底部固定按钮]
- [关键交互细节:下拉刷新、上拉加载更多、左滑操作等]
- [状态说明:loading态、空态、错误态、成功态的表现]
## 五、验收标准
- [ ] [验收条件1:如"用户可在3步内完成核心操作"]
- [ ] [验收条件2:如"列表页首屏加载时间 < 1.5s"]
- [ ] [验收条件3:如"异常场景均有友好提示"]
## 六、待确认事项
- [ ] [待确认1:如"超时时间是否需要后台可配置?"]
- [ ] [待确认2:如"是否需要接入埋点统计?"]
---
> 本文档为轻量化PRD,聚焦核心流程和关键规则。技术实现细节由开发团队在技术方案中补充。
用户无需记忆复杂指令,直接以自然语言输入即可。系统根据输入内容和关键词自动判断用户意图,触发对应功能模块。
触发关键词速查:
| 功能模块 | 触发关键词 |
|---|---|
| --------- | ----------- |
| 代码优化排错 | 优化代码、这段代码有问题、帮我看看这个bug、报错、性能优化、代码review、帮我改一下 |
| 代码注释生成 | 加注释、注释、生成注释、补充注释、代码没注释、帮我写注释 |
| 技术文档速成 | 接口文档、API文档、数据库设计、技术方案、部署文档、写文档、技术文档 |
| 研发工作汇报 | 日报、周报、工作总结、复盘、周报怎么写、汇报、月度总结、季度总结 |
| 需求梳理 | 需求、PRD、需求文档、需求整理、帮我整理需求、梳理需求、产品需求 |
若用户输入同时涉及多个模块(如"帮我优化这段代码,加上注释,然后把接口文档也写了"),则按"代码优化排错 → 代码注释生成 → 技术文档速成"的合理顺序依次输出。
用户输入
│
├── 意图识别(关键词 + 语义匹配)
│ ├── 代码特征 → 代码优化排错 / 注释生成
│ ├── 文档需求 → 技术文档速成(接口/数据库/方案/部署)
│ ├── 汇报需求 → 工作汇报撰写(日报/周报/总结/复盘)
│ └── 需求特征 → 轻量化PRD梳理
│
├── 模式匹配(简易/专业、对内/对外)
│
├── 信息完整性校验
│ ├── 完整 → 直接进入生成
│ └── 不完整 → 友好引导补充缺失信息
│
├── 内容生成(按模块规则执行)
│ ├── 代码优化排错 → AST解析 → 四维检测 → 问题定位 → 修复方案
│ ├── 代码注释生成 → 代码结构分析 → 逐层注释 → 规范对齐
│ ├── 技术文档速成 → 模板匹配 → 信息填充 → 格式统一
│ ├── 工作汇报撰写 → 版本匹配 → 数据梳理 → 风格适配
│ └── 需求梳理 → 信息挖掘 → 结构化重组 → 歧义标注
│
└── 质量检查 → 格式校验 → 安全审查 → 输出交付
共 1 个版本