@星子(xingzi) 背景：主业是企业级 Java 后端，晚上和周末用 OpenClaw 做个人/群助理实验。下面是我这 30 天里觉得真正有用的几件事，不是教程，更像是踩坑后的选择。

## 先问：你到底想让助理帮你干什么？

我一开始犯了典型工程师错误：先把协作文档、日历、邮件、任务全接上，Tool 列表很长，看起来很厉害，实际每天几乎不用。

后来改成先跑通 3 个高频场景：

1. 晨间摘要：今天日程 + 未完成任务 + 需要回复的消息线索

2. 会议前 15 分钟：参会人、议题、上次相关讨论摘要

3. 碎片记录：语音/文字丢给助理，自动归类到待办或笔记

结论是，个人助理不是“能力越多越好”，而是“默认链路越短越好”。

## Tool 设计：比写 Java Service 更要想“用户怎么说”

企业里我们习惯按领域建模。个人助理里用户说的是：

- “明天下午我有空吗”

- “帮我把这事记一下，周五前搞定”

- “刚才那个群谁提到我了”

所以我给 Tool 起名和参数都尽量贴近口语，并在 System Prompt 里写清楚：

- 什么情况下必须追问，比如时间、对象不明确

- 什么情况下只读不写，比如查日程可以，创建日程要二次确认

这和 MCP 企业平台的治理思路有点像，只是个人版更轻。

## 群助理 vs 个人助理：权限模型完全不同

个人助理可以“能读就尽量读”。群助理一旦越权，信任会掉得很快。

我的做法：

- 群助理默认只在被明确提到时响应，不主动插话

- 涉及对外发送，比如邮件、通知他人，一律先草稿、后确认

- 敏感 Tool，比如删数据、改权限，不在群里开

## 成本与稳定性：别被“全自动”绑架

早期为了炫技，让模型多轮 Self-Ask，一晚上烧掉不少 Token，还出现过“幻觉订了不存在的会”。

现在的原则：

- 读多写少，写操作带 confirm

- 长链路拆成 2–3 步固定模板，不让模型自由发挥十轮

- 关键结果落本地 Markdown/日志，方便人工核对

## 和企业 MCP 平台怎么互相反哺？

| 维度 | 企业 MCP 平台 | OpenClaw 个人实验 |

|------|----------------|-------------------|

| 目标 | 治理、复用、SLA | 快验证、个人效率 |

| Tool 数量 | 受控注册 | 自己说了算 |

| 鉴权 | 统一 SSO/审计 | 自己管 Token |

| 价值 | 给全公司用 | 给“我”用 |

我在 OpenClaw 里试通的编排，比如“摘要 → 确认 → 执行”，回到公司项目里会变成更清晰的 Tool 链设计文档。

## 给同样想试的人

如果你也是 Java 后端，建议：

1. 先选 1 个场景做透，别一上来接 10 个 MCP

2. 把失败样例记下来，比成功 Demo 更有价值

3. 个人实验和企业项目的账号、数据、时间尽量物理隔离，这是合规底线

全文已做脱敏处理。

#MCP平台