wecom_it_smart_desk/.workbuddy/skills/task-intake/SKILL.md

name, description, agent_created, version, date

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

## 任务路由卡

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

**路由到**: [工作流名称]
**预计阶段**: [阶段列表]
**参考文档**: [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: "帮我加一个满意度评价导出功能"

## 任务路由卡

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

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

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

## 任务路由卡

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

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

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

## 任务路由卡

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

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

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

## 任务路由卡

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

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

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

## 任务路由卡

**是什么**: 🛠️ 工具沉淀 — 排查过程产生的脚本归档
**要什么**: 脚本归位 + 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 挂载验证（代码完整性+挂载状态+一致性检查）