AI 同事需要逐步建立的信任、可靠检查和清晰目标

Lightcone 主持人介绍，Lauren Tan 和 Roman Ugarte 参与孵化 Grok Bot，并在七周内将产品从最初的代码推进到发布。产品希望让用户创建拥有姓名、角色、技能和工具访问权限的持续运行 AI 队友。

Ugarte 说，这个想法来自对长期运行、拥有明确目标和工具的编程智能体的观察。团队希望让非工程人员也能使用类似能力：围绕机器人而非聊天或文件组织工作，让它们使用人们已有的工具并主动行动。

他说，内部原型既受到 AI 积极使用者欢迎，也受到不那么热衷 AI 的同事欢迎。用户可以从简单任务开始，在找到有用场景后进一步配置机器人。

Ugarte 描述了一种逐步扩展方式：从基础任务到目标，最终可能承担工作职责。营销案例中，团队给机器人广告账户和预算，让它与设计机器人协作制作素材并开展测试。

拥有合适工具的客服机器人可能复现问题，并独立处理部分工单。Ugarte 预计，领域专家会构建和管理共享机器人，为其配置适合工作的凭据与职责。

Tan 将 Grok Bot 用作工程工作的外层循环。过去启动编程智能体前，她要手动收集同事、Slack 和缺陷报告中的上下文；现在可以把机器人直接带进已有上下文和协作的讨论串。

机器人如何组织取决于使用者。Tan 提到按职能划分的专家机器人，也可以按客户划分，让一个机器人跨职能服务客户；她偏好少量覆盖范围较广的机器人，加上一些专家机器人。Ugarte 则喜欢让每个机器人主动关注一个问题。

嘉宾说，团队机器人可以在组织内共享。具备领域知识的人可以构建机器人并向同事开放，让自动化从工程扩展到客服、销售等职能。

Tan 展示了一个销售工作流：共享机器人研究潜在客户，处理报价和交易等操作步骤。团队成员不必各自维护一份副本，可以共同改进一个体现团队做法的专家机器人。

Ugarte 说，多人共享带来尚未解决的问题。Slack 讨论串中的机器人可能不知道谁负责决策、谁最有专业知识；身份、认证和授权既是模型问题，也是产品设计问题。

他建议类比新员工入职：给机器人电脑和与其角色、经验相匹配的凭据，随着信任增长再扩大权限。他认为权限管理是整个行业的问题，目前没有统一答案。

与会者讨论了机器人之间的对话。Tan 说，她的工程机器人可以在可见的 Slack 讨论串里向数据专家机器人请求信息，调查用户问题的影响范围时，她也能看到双方交流。

讨论转向安全以及提供给模型的上下文。嘉宾说，用户仍在逐步建立信任，沟通方式和权限管理都需要持续完善。

Ugarte 介绍了一个数据机器人：它拥有数据库只读权限，在 Slack 回答例行问题。他认为这是第一步；以后机器人可能采取行动，最终也许能负责更广泛的结果，但他认为最后一步仍较遥远。

被问到如何从 Slack 请求走到拉取请求时，Tan 展示了她、同事与机器人共同参与的一次功能讨论。机器人启动了一个 Cursor 云端智能体，它有可运行应用的机器。

智能体把原型、截图和视频带回讨论串。Tan 说，同事可以在共享对话中尽早给反馈，而不必等一个人私下完成方案后再开始审查。

该示例讨论串约有 200 条消息。Tan 说，团队在这个讨论串里完成了功能，而她没有为该项目打开 Cursor。她把这种自主程度归因于此前对技能、代码约束和静态检查的投入。

Tan 说，有些智能体如今会自行合并拉取请求，人员则审查生成的成果。她强调，这套流程花时间建立起来，并非一夜之间就能切换。

她的 pstack 将工程技能打包供智能体使用，发布在 Cursor 插件仓库。这个项目受到另一套个人工具的启发；她鼓励使用者按自己的工作方式调整和组合技能。

与会者讨论了共享 Slack 讨论串如何让同事看到彼此使用智能体的方式并互相学习。Tan 仍将一些个人机器人留在团队频道之外，而把工程机器人加入协作发生的地方。

展望未来，Tan 设想机器人拥有自己的身份和使用服务的方式；嘉宾的产品目标是在公司现有工具中开展工作，而不是重建每一种企业应用。这些是他们对产品的设想。

Ugarte 将软件与其他知识工作作比较。代码有测试、编译和部署基础设施，许多上下文保存在代码库中；公司的其他知识可能散落在人员、文档和难以访问的系统里。

随着组织自动化更多执行工作，他预计清晰的目标和衡量标准会变得更加重要。桌面客户端性能可能容易测量，但定义有意义的营销改进可能需要更多判断。

Tan 描述了最小的有用编码循环：智能体写代码、像用户一样运行应用、发现问题并修改代码。给智能体提供反馈，可以减少工程师代它手动运行每一步的工作。

她区分了实现所需功能的结果与优质代码：前者仍可能运行缓慢或资源消耗过高。工程师需要改进环境和检查，让智能体默认更可能写出较好的代码。

内部循环可靠后，外层自动化可以响应告警、复现问题，并使用同样的工具提出修复。Tan 说，她还使用机器人通过项目功能协调其他智能体。

主持人询问，当全面自动审查消耗大量 token 时，究竟审查多少才够。Tan 说，多模型对抗式审查可能有帮助，但也可能过度迎合忽略整体产品目标或未来计划的反馈。

她更倾向于把反复出现的要求固化到代码库、API 设计和静态分析中。规则与技能仍是有用的补充；基础设施、数据库和部署等敏感领域仍可能需要人工参与。

例如，她的 Electron 团队用依赖检查器禁止主进程和渲染进程之间跨边界导入。Tan 澄清，这项检查并不测量执行时间，而是阻止某类重代码进入对性能敏感的渲染路径。

Tan 说，完成这些投入后，同时获得质量和速度更有可能；她也承认自己的实验室为她提供了近乎无限的 token。她把自己的工作视为探索未来工作流，以及让日常工程更经济的方法。

Ugarte 说，团队越来越多地花时间对齐路线图和质量标准。同事已经能做出许多潜在修改，但把每个个人项目都合并进去会让产品缺乏一致性。

处理反馈的机器人可以帮助自动发现和修复小问题。相比之下，Ugarte 说，核心界面修改会经历更长的内部测试：反复移动熟悉的控件会让用户困扰，因此内部接受度不强的想法不会发布。

Tan 说，快速生成不意味着发布所有可能的功能。她把大量自动化工作用于维护、性能和用户报告的缺陷，让人有更多时间思考产品体验。

Tan 学习的是会计和金融，后来发现自己喜欢制作电子表格和 Visual Basic 宏。她与同学创办过一家初创公司，并参与澳大利亚创业社区，这些经历帮助她找到第一份科技工作。

学习编程时，她公开写下自己的所学。Ember 社区成员邀请她到大会演讲；她认为那次经历、沟通能力和导师的帮助促进了她作为工程师的成长。