- 产品派

好生活家 · 2026-06-21T05:05:41.551Z

@星子(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平台