---
name: task-intake
description: 任务接收与路由技能 - 收到任何请求时首先使用，将请求结构化为四要素（是什么/要什么/怎么做/谁来做）并路由到正确的工作流。适用于项目所有 incoming 请求的统一入口。
agent_created: true
version: 1.4
date: 2026-07-10
---

# Task Intake — 任务接收与路由

## 定位

项目所有 incoming 请求的**统一入口**。不是执行者，是路由器。

收到请求后，本技能负责：
1. **分类** — 判断请求属于哪类任务
2. **结构化** — 输出四要素（是什么/要什么/怎么做/谁来做）
3. **路由** — 对照 SOP 路由表，确定执行路径
4. **移交** — 将路由卡交给对应执行方

**核心原则**：task-intake 只做"想清楚"和"分对路"，不做"动手干"。

---

## 触发条件

- ✅ 收到任何新需求/问题/任务时
- ✅ 不确定该走什么工作流时
- ✅ 请求类型模糊，需要先分类时
- ❌ 已经明确知道走哪条流程时（直接执行即可，不必再过一遍 intake）

---

## 执行流程

### Step 1: 请求分类

分析请求内容，判断属于以下哪一类：

| 分类 | 识别特征 | 示例 |
|------|---------|------|
| 🏗️ 新功能开发（中大型） | 多页面/多模块、涉及后端+前端、>10个源文件 | "开发员工自助查询平台" |
| ⚡ 新功能开发（小型） | 单页面/工具脚本、≤10个源文件 | "加一个满意度评价导出功能" |
| 🔧 Bug 修复 | 报告明确 Bug，非新功能 | "管理后台登录报网络连接失败" |
| 🚀 部署运维 | 部署/配置/Nginx/容器相关 | "部署管理后台前端到生产" |
| 🩺 故障排查 | 页面打不开/502/500/接口无响应 | "H5扫码登录后页面不关闭" |
| 🔴 应急事件 | P0/P1 级别，需立即响应 | "鉴权漏洞被利用" |
| 🔍 代码调试 | 代码逻辑不对、行为异常 | "摇人消息没有推送到通知栏" |
| 📊 技术评估/决策 | 需要判断值不值得做、怎么选 | "联软API对接值不值得做？" |
| 📋 方案调研 | 需要调研后输出方案 | "火绒API方案怎么设计？" |
| 📝 文档更新 | 更新文档/SOP/手册 | "更新故障排查手册" |
| 🛠️ 工具沉淀 | 排查后归档脚本/工具 | "把排查脚本归到工具箱" |

### Step 2: 四要素结构化

对每个请求输出以下四要素：

```
是什么：[任务分类] + [一句话描述]
要什么：[期望产出物] + [验收标准]
怎么做：[执行路径] + [需要的技能/工具]
谁来做：[执行角色] + [协作方]
```

**注意事项**：
- "是什么"要精确到分类表中的具体类别
- "要什么"必须包含可验证的产出物和验收标准，验收标准需指明验证手段（见下方验证手段分层表）
- "怎么做"指出执行路径和工具，但不展开执行细节
- "谁来做"明确执行方和协作方

**验证手段分层表**（用于"要什么"字段的验收标准）：

| 验证类型 | 工具 | 适用场景 | 何时必须用 |
|---------|------|---------|-----------|
| API/后端 | curl / HTTP 请求 | 接口返回值、状态码 | 后端接口验证 |
| 前端渲染/登录/交互 | **agent-browser** 技能 | 页面渲染、表单填写、按钮点击、键盘输入 | 涉及前端页面的修复 **必须**用 |
| 前端诊断（F12 等效） | **agent-browser** Debug 命令 | 白屏、JS 不执行、API 异常、CSP 违规 | 前端异常排查 **必须**采集 console/errors/network |
| 服务器状态 | jumpserver-ops | 容器状态、进程 | 部署后健康检查 |

**硬规则**：禁止只因 `docker logs` 无报错就断言修复。前端类修复必须 agent-browser 截图取证。前端异常排查必须采集 `errors` + `console` + `network requests`。

### Step 3: 路由决策

对照项目 SOP 路由表，确定执行路径：

| 输入特征 | 路由到 | 产出物 | 执行方 | 参考文档 |
|---------|--------|--------|--------|---------|
| 🏗️ 新功能（中大型） | 软件团队标准 SOP | PRD+架构+代码+测试 | PM→Architect→Engineer→QA | 软件团队 SOP |
| ⚡ 新功能（小型） | 软件团队快速模式 | 代码+测试 | Engineer→QA | 软件团队 SOP |
| 🔧 Bug 修复 | SOP §6 BugFix | 修复+验证 | Engineer→QA | SOP §6 |
| 🚀 部署运维 | 直接执行 ⚠️ 前置检查 | 部署完成+验证 | AI+jumpserver-ops | SOP §7 工具箱 + deploy-troubleshoot Step -1 |
| 🩺 故障排查 | deploy-troubleshoot | 定位+修复+案例 | 三步隔离法 | 故障排查手册 |
| 🔴 应急事件 | SOP §4 应急响应 | 止血+根因 | 应急流程 | SOP §4 |
| 🔍 代码调试 | diagnose 技能 | 根因+回归 | 六阶段调试 | diagnose SKILL.md |
| 📊 技术评估 | Plan 模式 | 评估报告 | AI+人 | — |
| 📋 方案调研 | Plan 模式 | 方案文档 | AI+人 | — |
| 📝 文档更新 | 直接执行 | 文档 | AI | SOP §5 文档规范 |
| 🛠️ 工具沉淀 | SOP §7 流程 | 工具归档+README更新 | AI | SOP §7 |

**路由优先级**（当请求可能匹配多个分类时）：
1. 🔴 应急事件 > 一切（先止血再说）
2. 🩺 故障排查 > 🔧 Bug 修复（先隔离定位再修 Bug）
3. 🏗️/⚡ 新功能 > 📊 技术评估（明确要做的不需要评估）
4. 📝 文档更新 / 🛠️ 工具沉淀 通常作为其他任务的收尾步骤

### Step 3.1: 部署运维前置检查（⚠️ 涉及后端代码变更时必须执行）

当路由到「🚀 部署运维」且涉及后端代码变更时，**在执行部署前必须检查**：

#### ⛔ 硬规则：后端代码部署方式（方案 C 卷挂载，2026-07-10 上线）

| 变更类型 | 部署命令 | 禁止操作 | 耗时 |
|---------|---------|---------|------|
| `.py` 文件变更（新增/修改） | `docker compose restart backend` | ❌ `docker compose build` | ~15-30 秒 |
| `requirements.txt` 变更 | `docker compose build backend && docker compose up -d backend` | — | ~60-90 秒 |
| 配置文件变更（`.env`/`docker-compose.yml`） | `docker compose up -d backend` | — | ~10 秒 |

> **原理**：代码通过 `./app:/app/app` volume 挂载到容器，不烘焙进镜像。改代码只需 restart 让 uvicorn 重新加载，无需重建镜像。`docker compose build` 只在 Python 依赖（requirements.txt）变化时才需要。

| 检查项 | 命令 | 不通过时的动作 |
|--------|------|---------------|
| 代码目录完整性 | `for f in app/__init__.py app/main.py app/api/auth.py; do [ -f "/opt/wecom-it-desk/$f" ] && echo "PASS: $f" || echo "FAIL: $f"; done` | 上传缺失文件到 `/opt/wecom-it-desk/app/` |
| Volume 挂载验证 | `docker exec wecom_it_backend ls /app/app/main.py` | 检查 docker-compose.yml 是否含 `./app:/app/app` 卷挂载 |
| 代码一致性 | `HOST=$(md5sum /opt/wecom-it-desk/app/main.py \| awk '{print $1}') && CONTAINER=$(docker exec wecom_it_backend md5sum /app/app/main.py \| awk '{print $1}') && [ "$HOST" = "$CONTAINER" ] && echo PASS \| echo FAIL` | `docker compose restart backend` 重新加载代码 |

> **方案 C（卷挂载）已于 2026-07-10 上线**：代码不再烘焙进 Docker 镜像，通过 `./app:/app/app` volume 挂载。`backend/app/` 旧代码目录已删除。代码更新只需 `docker compose restart`，仅 `requirements.txt` 变化时才需 `docker compose build`。
>
> **完整检查清单**见 `deploy-troubleshoot` 技能 Step -1 和故障排查手册 §1.4。

### Step 4: 输出路由卡

```markdown
## 任务路由卡

**是什么**: [任务分类] [一句话描述]
**要什么**: [产出物] [验收标准]
**怎么做**: [执行路径] [技能/工具]
**谁来做**: [执行角色] [协作方]

**路由到**: [工作流名称]
**预计阶段**: [阶段列表]
**参考文档**: [SOP章节/技能/手册]
```

路由卡输出后，**立即移交**给对应执行方，不在此步骤中展开执行。

---

## 与软件团队 SOP 的集成

当齐活林（交付总监）收到请求时：

```
请求到达
  ↓
齐活林调用 task-intake
  ↓
输出路由卡
  ↓
├─ 路由到"标准SOP" → TeamCreate → PM → Architect → Engineer → QA
├─ 路由到"快速模式" → TeamCreate → Engineer → QA
├─ 路由到"BugFix" → TeamCreate → Engineer → QA
├─ 路由到"故障排查" → deploy-troubleshoot → jumpserver-ops(传输)
├─ 路由到"应急响应" → SOP §4 应急流程
├─ 路由到"Plan模式" → 先想后做，输出评估/方案文档
└─ 路由到"直接执行" → 文档更新/工具沉淀
```

**关键**：task-intake 是齐活林判断工作流类型的**结构化工具**，替代原来的"凭经验判断"。判断结果可追溯、可复盘。

---

## 与其他技能的关系

```
                    task-intake (路由器)
                   /     |      |        \
                  /      |      |         \
    deploy-troubleshoot  diagnose  软件团队SOP   Plan模式
    (故障排查方法论)    (代码调试)  (开发流程)    (评估决策)
         |                |          |            
    jumpserver-ops     Bash/Read   Engineer/QA   
    (传输代理)          (执行工具)   (执行角色)    
         |                            
    toolbox/                        
    (弹药库)                          
```

- **task-intake** = 路由器，决定走哪条路
- **deploy-troubleshoot / diagnose** = 方法论，指导怎么排查
- **jumpserver-ops** = 传输代理，解决"怎么到服务器"
- **toolbox/** = 弹药库，提供辅助工具
- **软件团队 SOP** = 开发流程，指导代码实现
- **Plan 模式** = 思考模式，用于评估/决策类任务

---

## 使用示例

### 示例 1: "帮我加一个满意度评价导出功能"

```markdown
## 任务路由卡

**是什么**: ⚡ 新功能开发（小型）— 满意度评价数据导出为 Excel
**要什么**: 导出功能代码 + QA 验证通过
**怎么做**: 软件团队快速模式 → Engineer 实现 → QA 验证
**谁来做**: 寇豆码(工程师) → 严过关(QA)

**路由到**: 软件团队快速模式
**预计阶段**: TeamCreate → Engineer → QA
**参考文档**: 软件团队 SOP
```

### 示例 2: "管理后台登录报网络连接失败"

```markdown
## 任务路由卡

**是什么**: 🩺 故障排查 — 管理后台登录接口无响应
**要什么**: 故障定位 + 修复 + 验证证据（curl 接口返回 + agent-browser 登录截图）
**怎么做**: deploy-troubleshoot 三步隔离法 → jumpserver-ops 传输
**谁来做**: AI(排查) + jumpserver-ops(传输)

**路由到**: deploy-troubleshoot
**预计阶段**: Step 0(响应头) → 三步隔离 → 修复 → 验证
**参考文档**: 00-标准故障排查手册.md
```

### 示例 3: "联软 API 对接值不值得做？"

```markdown
## 任务路由卡

**是什么**: 📊 技术评估 — 联软 API 对接的成本收益分析
**要什么**: 评估报告（技术可行性 + 成本 + 收益 + 风险 + 建议）
**怎么做**: Plan 模式 → 调研 → 分析 → 输出报告
**谁来做**: AI(调研分析) + 宋献(决策)

**路由到**: Plan 模式
**预计阶段**: 调研 → 分析 → 输出评估报告 → 人工决策
**参考文档**: 无（Plan 模式自由发挥）
```

### 示例 4: "H5 扫码登录后页面不自动关闭"

```markdown
## 任务路由卡

**是什么**: 🔧 Bug 修复 — 扫码登录成功页 JS 未执行
**要什么**: Bug 定位 + 修复 + 回归验证（agent-browser 打开扫码页 → 截图确认 JS 执行 + 页面自动关闭）
**怎么做**: 先 deploy-troubleshoot 排查（确认是否部署层问题）→ 如是代码层则 diagnose 调试
**谁来做**: AI(排查) → Engineer(修复) → QA(验证)

**路由到**: 先故障排查，确认层级后转 BugFix
**预计阶段**: 隔离定位 → 根因分析 → 修复 → 验证 → 案例沉淀
**参考文档**: 00-标准故障排查手册.md + SOP §6 BugFix
```

### 示例 5: "把排查脚本归到工具箱"

```markdown
## 任务路由卡

**是什么**: 🛠️ 工具沉淀 — 排查过程产生的脚本归档
**要什么**: 脚本归位 + README 更新 + 根目录清理
**怎么做**: SOP §7 工具沉淀流程（评估→归档→登记→清理）
**谁来做**: AI

**路由到**: 直接执行（SOP §7）
**预计阶段**: 评估复用价值 → 归档 → 登记README → 清理
**参考文档**: SOP §7 部署运维工具箱管理
```

---

## 上下文隔离原则

task-intake 的路由卡**只传递结论，不传递思考过程**：

- ✅ 传递："故障定位在 Nginx 层，证据是 curl 返回 403"
- ❌ 不传递："我一开始以为是后端的问题，试了 A/B/C 都不对，后来才发现..."

这确保下一阶段（如 diagnose 或 Engineer）拿到的是**干净的输入**，不会被前一阶段的假设和试错过程带偏。

---

## 版本历史

| 版本 | 日期 | 变更 |
|------|------|------|
| v1.0 | 2026-07-10 | 初始版本，含 11 类任务分类 + 路由表 + 5 个示例 |
| v1.1 | 2026-07-10 | 新增验证手段分层表，示例补充 agent-browser 验证要求 |
| v1.2 | 2026-07-10 | 验证手段分层表新增"前端诊断（F12 等效）"类型，硬规则增加 console/errors/network 采集要求 |
| v1.3 | 2026-07-10 | 新增 Step 3.1 部署运维前置检查（代码同步 + 依赖同步），防止镜像缺文件 |
| v1.4 | 2026-07-10 | 方案 C 上线：Step 3.1 更新为 volume 挂载验证（代码完整性+挂载状态+一致性检查） |