用了几天Dots，他居然会主动找活干

邮件可以订阅事件

我给 Dots 安排过一个任务：收到项目的特定故障邮件后，读取告警，结合代码分析原因，再推进处理。

这里有个值得单独说的细节：我配置的 Gmail 链路是订阅新邮件事件。新邮件事件到来后触发任务，不是隔几分钟刷新一次邮箱、看看有没有新邮件。

这让邮件有了新的用途。服务器可以继续发送原有的告警邮件，AI 接到事件后，再判断内容是否符合处理条件。测试邮件、无关消息和重复告警，则要过滤掉。

但订阅制也不代表零延迟。我确实遇到过邮件已经发出，过了几分钟还没看到处理反馈的情况。对使用者来说，“邮件已到”“任务已触发”“排查已开始”是三个不同的状态，最好能清楚地展示出来。

否则，我还是会忍不住问一句：“怎么还没处理？”

最惊喜的是它会主动发现问题

有一次，雷达主动提醒我：项目的安全盘点还缺云主机和数据库的安全组规则，现有的网络互探不足以确认完整开放范围。

它还提醒我，某项修改合并后，独立测试发现了一个未处理的问题，发布前需要留意。

我当时甚至反问它：我没有要求你监测 GitHub，为什么会关注这些工作？

问清楚后，我又补了一句：我不是要取消，而是希望你继续监测，主动发现问题。

这就是我说的“眼里有活”。项目里很多重要信息散落在提交记录、评审评论、验收报告和待办文档中。单看每一条都不复杂，但把它们串起来，判断哪一件还没完成、谁在等什么，确实需要持续留意。

它能把“报告里出现了一个问题”进一步整理成“这件事还需要补什么证据”，对我就有实际价值。

不过，主动提醒也要说明依据。是别人写在报告里的结果，还是它刚刚核实过的状态？是疑似原因，还是已经确认的故障？这些如果混在一起，提醒反而容易增加误解。

能把问题接着往下推进

发现问题以后，我会让它交给 Mac 处理。

用下来，我觉得 Dots 更像一个项目经理。我把一件事交给它，说清目标和边界，它再把具体工作分派给电脑去执行，继续跟进进度和卡点。

这样，我就不用一直盯着各个对话，挨个回复“yes”或“no”，再把结果来回传话。我的注意力可以放在这件事有没有完成，以及哪些关键问题还需要我拍板。

我实际尝试过的流程是：读取告警和代码，定位问题，在独立的工作目录中修改，运行测试，再提交 PR，也就是等待审核合并的代码变更。

有一回同时有三件事要做，我专门要求：分别处理，用新的 worktree，不要混在一起。这样每项修改可以单独看、单独验证，也方便决定哪一项先合并。

这个过程让我觉得，AI 的价值可以延伸到一次问答之后。后面有新的 review 评论、代码发生冲突、测试还没通过，都需要继续跟进。

但这里不能把“提交了 PR”写成“故障解决了”。代码合并、实际部署、上线后的验证，仍然是不同阶段。我也明确要求过只合并、不发布。涉及生产环境，最终动作和风险必须说清楚。

周报应该帮我看见问题

我还让它每周整理过去七天的 GitHub 工作记录。

最初要求是汇总做了什么，后来又加了两个要求：固定用 HTML 展示，并且深入分析亮点与不足。

对我来说，周报如果只是把提交标题换一种说法，意义有限。更有用的是按项目归纳：哪些工作形成了成果，哪些只完成了代码，哪些还缺实际验收；有没有重复投入，下周应该先处理什么。

HTML 也比较适合这种内容。先看总结，再展开具体项目，需要时点进证据链接，手机上也容易查看。

我希望它帮我判断工作是否真正完成，而不是数一数提交次数，再夸一句“本周效率很高”。提交多，不自动代表价值大；一个反复出现的问题，也可能暴露了验证环节的不足。

普通用户能不能用明白

我最近还让它继续推进一个服务 Ozon 店铺运营的项目，优先完成 AI 优化功能。

这里有个很实际的用户背景：目标用户不懂俄文。

如果 AI 生成了一段看起来很专业的俄文商品描述，用户却看不懂，就很难判断能不能发布。除了生成能力，我更关心它能否把最终内容完整地解释成中文，让用户知道改了哪里、为什么改。

商品资料有冲突怎么办？承重、材质或者规格没有确认，能不能先保存草稿，暂缓同步？手工修改俄文后，中文解释是否仍对应当前版本？

这些问题没有“自动生成”那么显眼，却直接决定功能是否好用。这部分仍在推进，我不会因为代码写出来了，就把它当成已经在真实店铺验证过的效果。

几个卡点也很明显

• 首先是远程服务器管理。我尝试让 Dots 的云端环境直接通过 SSH 连接自己的服务器，这条路没有顺利打通。后来通过 Mac 已有的 SSH 环境，才有了可用的诊断路径。所以，我的实际感受是：它还不能按我最初设想的方式，直接从云端接管这部分工作。具体限制与环境有关，不能据此断言所有 SSH 场景都不支持。
• 第二个卡点是 Slack 机器人消息。我想让服务器向 Slack 发消息，再自动触发 Dots。测试中，人工发送的消息能触发；服务器通过机器人发出的测试消息，虽然已经出现在频道里，却没有自动触发。这段“最后一公里”没有接通，就不能说服务器已经可以随时联系到它。消息能读到和消息能触发任务，是两回事。
• 第三个卡点是等待时缺少确定感。我遇到过安卓端能看到对话，却没有收到测试推送；也多次追问任务为什么还没完成。长任务可以花时间，但应该及时告诉我当前进度、阻碍和下一步。否则，用户很难分清是在工作，还是已经停了。
• 跨环境授权与运行条件。还有，云端、Mac 和外部服务各自有授权与运行条件。一个地方已经能用，不意味着换一个地方就能直接复用。跨环境的衔接，还需要使用者花精力理解和处理。比如连接 Sentry 时，我两次在授权页确认，云端等待进程却中断了，最终没有保存登录。工具显示取消，但具体原因没有查明。
• 多任务上下文核实。还有一次我追问某个 PR 的评审，它先查到了另一个项目，引用消息后才纠正。多项任务同时进行时，上下文仍需要核实。

我会继续用，但会把边界讲清楚

现在让我愿意继续用 Dots 的，是它能持续关注一件事，并在我没发问的时候，找出值得注意的问题。

与此同时，我也越来越明确自己想要怎样的协作：先把事实查清楚，把依据带过来；需要写代码再交给执行环境；涉及发布、权限和真实店铺修改，再明确确认。

我不要求它每次都给出漂亮的答案。发现资料不够，直说缺什么；任务卡住，及时说明原因；事情只完成了一半，就把另一半留下来继续跟。

“眼里有活”让我愿意让它参与更多工作。接下来，我更希望它做到的，是接手的每件事，都有清楚、可信的交代。

JOTO 企业落地观察

• 企业部署智能体时，需区分“事件驱动”与“轮询触发”两种集成模式。Dots 对 Gmail 的订阅式接入表明，现代智能体工程应优先对接 Webhook 或事件总线，而非依赖定时拉取，这对降低延迟、提升响应确定性至关重要。
• “主动发现问题”能力依赖于多源异构数据（邮件、GitHub、周报）的统一知识建模。企业构建 RAG 知识工程时，不能仅做文档切片，而需建立跨系统语义锚点（如项目ID、PR编号、安全组名称），否则主动推理易失焦。
• 文中反复强调的“状态可见性”（邮件已到/任务已触发/排查已开始）揭示：面向生产环境的智能体必须内置可观测性协议。企业 AI 安全治理需将执行链路的状态透出、阻塞归因、人工确认点作为强制设计约束，而非可选体验优化。
• Slack 机器人消息未触发、SSH 权限断裂等卡点，凸显 FDE 驻场共创的关键价值——真实环境中的权限拓扑、网络策略、认证流转，无法被沙箱模拟覆盖，必须由一线工程师与 AI 工程师共同测绘并固化为部署清单。