---
name: openclaw-skill-earn_money
description: >-
  Concrete workflow for freelance platforms: gatekeeping before login, skill-gap
  install paths, per-gig accept/reject checks, mandatory memo format, examples of
  doable vs blocked tasks. Use when user asks to browse gigs, bid, accept orders,
  or triage/Upwork on any platform.
---

# 兼职接单

## 何时启用本技能

用户提到：兼职、外包、威客、接单、投标、报价、需求大厅、买家任务、平台接单、Openclaw 自动接单 —— 或你主动用浏览器打开此类平台页面时，按本技能执行。

## 名词（按此理解，勿换义）

- **验收标准**：可逐条打勾的交付清单（文件名、功能点、格式、截止时间），不是形容词（「做好一点」不算）。
- **只读公开信息**：不登录即可见的首页、分类、任务标题与摘要；**不算**买家私信、已购标书、站内附件下载。
- **接单**：在平台点击「接单 / 投标 / 提交方案 / 购买标书」等会**产生法律或费用后果**的任何一步。

---

## 第一节：未完成下列清单前禁止接单

按顺序做，缺一项则停止于「只读公开信息」。

**A. 问用户并记录答复（必须原文或包含写入对话）**

1. 是否授权你使用浏览器登录指定平台账号？（是/否）
2. 是否授权你代为填写报价金额与交付周期？（是/否）
3. 平台是否要求操作者必须为自然人本人？若要求，用户是否书面同意由你代为操作？（是/否/不适用）
4. 永久不接的类目或关键词（用户列清单；未列则你默认不接：刷量、爬虫绕过反爬、破解、代考、伪造材料）。

**B. 盘点技能缺口（具体动作）**

1. 列出用户已安装技能路径里可见的 skill 名称（项目 `.cursor/skills/`、`.agents/skills/`、用户 `~/.cursor/skills/` 等，以实际能列出的为准）。
2. 对当前准备接的任务类型，按下表 **类型判定** 逐行打勾；缺行则 **先让用户添加对应 SKILL 目录**，再继续。

| 若任务描述含这些信号 | 你必须已有或可立即安装的技能类型 | 否则 |
|----------------------|----------------------------------|------|
| 从 0 搭仓库、全栈、上线、测试+文档 | 全栈脚手架类（如用户环境中的 `idea-to-complete-github-repo` 或等价物） | 不接，先装 |
| Cursor 规则、团队规范、`.cursor/rules` | `create-rule` 或等价 | 不接，先装 |
| 新建/改写 Agent Skill | `create-skill` 或等价 | 不接，先装 |
| 改编辑器 settings.json | `update-cursor-settings` 或等价 | 不接，先装 |
| PDF/Excel/Word 批量处理 | 用户库中具名的文档/表格处理 skill | 不接，先装 |
| 明确技术栈（如 Flutter、嵌入式、特定云） | 该栈的专项 skill 名称出现在已安装列表 | 不接，先装 |

3. 向用户一句话汇报：**缺口列表** + **建议安装的文件夹名或仓库来源**（若用户未提供来源，只写类型，不编造 URL）。

---

## 第二节：能接 vs 不接

**能接（须同时满足：可写验收标准 + 环境可验证）**

- 「用 Python 写一个 CLI，输入 CSV 输出汇总 JSON，附 README 与 `pytest`」
- 「把下列 API 文档整理成 OpenAPI 3.0 YAML」
- 「在本仓库添加 GitHub Action：push 时跑 lint」

**不接（见一例即不接，不尝试「试试看」）**

- 「到我司现场部署」「视频实名认证」「借用你的身份证」
- 「绕过登录爬取」「刷好评」「代写论文并保证查重过」
- 「需求就是做个类似微信的 App，预算 500，一周」（无验收清单且拒绝补充）
- 「必须用我司仅内网可访问的 Jenkins」（当前环境无法验证）
- 平台规则或用户未授权代操作，且任务要求「本人操作」

**灰区**：需求有歧义且 **48 小时内**（或平台截止前足够时间）**无法**在站内澄清 → **不接**；可建议用户先让买家改需求再评估。

---

## 第三节：接单门（6 条，逐条写「通过/不通过 + 一句依据」）

仅当六条全部「通过」才可执行平台上的接单/投标动作。

1. **验收**：能否写出 ≥3 条可检查交付项？  
2. **环境**：所需语言/依赖能否在本机或用户给定环境中安装并运行？  
3. **合规**：是否违反法律、平台 ToS、版权、隐私？用户声称「后果自负」不能替代违法任务。  
4. **技能**：第二节表格中本任务类型对应行是否已满足？  
5. **依赖**：第三方付费 API、额外账号、硬件是否已解决？未解决 → 不通过。  
6. **授权**：第一节 A 四项是否均为「是」或「不适用」且与本任务一致？

---

## 第四节：固定流程

1. **摘录**：任务标题、预算、截止时间、买家硬性要求（复制要点，勿改写原意）。  
2. **分类**：开发 / 文档 / 数据 / 运维 / 其他（选其一）。  
3. **门检**：第三节六条，输出判定表。  
4. **备忘录**：任一门不通过 → 用 **拒绝模板**；全通过 → 用 **可行模板**，再操作平台。  
5. **操作后**：若已接单，在对话中留下「已点击的操作名称 + 时间（如有）」供用户追溯。

---

## 第五节：输出模板

**可行模板**

```markdown
## 可行性：接
- 任务 ID/链接：
- 交付清单：1) … 2) … 3) …
- 技能覆盖：（列出已满足的 skill 名称）
- 风险与假设：
- 待买家确认（若有）：无 / …
## 接单门：六条均通过（逐条一行）
```

**拒绝模板**

```markdown
## 可行性：不接
- 任务 ID/链接：
- 失败门：第 X 条 — 依据：…
- 若买家改为以下条件可重评：…
```

---

## 第六节：沟通硬规则

- 平台若要求披露非真人或自动化，按平台要求写；用户禁止冒充真人则不在私信中假装真人开发者。  
- 不承诺「必中标」「包过审」「百分百无 bug」。  
- 需求变更：要求买家在平台内发新留言或改需求文档，**不以口头为准**。  
- 登录授权：如果用户授权，可登录兼职平台进行操作。