研发智能体的价值，不在于它写了多少代码，而在于它能被谁使用。
过去，能调用研发能力的只有研发自己。工具链、代码库、流水线、缺陷记录——这些资产都停在研发的世界里。业务、产品、管理要在协作系统里追一份排期、问一个进度、确认一次交付，中间隔着一道组织断层。
这次我们想验证的，是另一种可能：让织灵 Coda Loom 2.0 带着 ADE Teams 数字研发团队，自己开发一个飞书机器人，把研发能力接进企业已经在用的协作入口。全程约 2 小时，人类写 0 行代码，约 565 行代码一次成型，留下 67 份调研笔记。
关键不在"飞书上多了个机器人"，而在：这个机器人的真正用户，可能不是研发——而是研发之外的人。当研发能力被封装成一个可对话的入口，业务方也能在群里直接触发研发动作、消费研发资产。
如何使用 Loom 把自己开发成一个飞书机器人——完整流程如下：
1 把调研交给 Loom：自己读官方文档
Loom 操作：自动抓取并研读飞书开放平台的 SDK 文档、消息接口文档、长连接接入指南，整理成可用的调研笔记
开发飞书机器人的第一步是搞清楚三件事：飞书 SDK 怎么用、消息接口怎么调、事件怎么接收。这些答案都散落在飞书开放平台的几十篇文档里，以往这一步要人工一篇篇啃，至少半天。这次人类只丢给 Loom 一个文档入口，剩下的全是它自己完成的：
明确要读什么：Loom 先梳理出调研清单——SDK 总览、Python 开发指南（安装准备、调用 API、处理事件三篇）、消息收发接口、长连接接入文档，以及官方示例代码，逐一攻破
遇到障碍自己换路子：飞书文档站是动态渲染的页面，常规抓取拿不到正文——Loom 发现官方提供了 Markdown 版本通道，顺利拿到大部分文档；其中一篇关键的长连接文档该通道失效，它没有卡住，而是转而研究文档站自身的接口，找到了正确的获取方式；官方源码库访问受限时，又改从软件包仓库拿到了 SDK 的完整使用说明
沉淀成自己的知识库：所有成果被整理成 67 份调研笔记，归档在独立的调研目录里——每篇文档讲了什么、关键接口长什么样、示例代码怎么写，一目了然
这一步的价值不只是"省了半天的读文档时间"：这 67 份笔记成了后续方案设计和编码的事实依据，Loom 后面写出的每一行代码，都能追溯到调研阶段读过的官方文档。调研不再是走过场，而是真正驱动了开发。
2 打通 loom-cli：自己完成安装、登录与验证
Loom 操作：安装 loom-cli，熟悉用法，在服务器上完成登录并绑定 ADE，验证 AI Agent 可被命令调起
loom-cli 是驱动 AI Agent 的命令行入口。人类装好工具后，剩下的全是 Loom 自己完成的：
熟悉工具：梳理出 loom-cli 的命令体系——交互式对话、headless 执行（loom exec）、ADE 实例管理等，明确了机器人集成要走 headless 模式
适配服务器环境：服务器没有交互式终端，Loom 采用了非交互登录方式——先查询账号下的 ADE 实例列表，选定目标 ADE，再携带 ADE ID 完成登录绑定，凭证妥善保存在本地
验证链路：用一条最小指令（loom exec "请只回复OK"）验证 AI Agent 能被无人值守地调起并正常返回结果
提前排雷：发现命令输出中混有 token 用量等统计信息，记录下来留待集成时过滤，避免污染机器人的回复内容
"安装 → 登录 → 绑定 ADE → 验证"整条链路全部由 Loom 自主完成，人类只提供了安装命令和登录凭证。
3 先出方案，人类确认后才动手
Loom 操作：产出完整技术方案文档，列出关键决策点和待确认问题，等待人类拍板
Loom 没有上来就写代码，而是先输出了一份完整的技术方案，把整个开发过程拆成了几个关键决策，逐一摆在人类面前：
怎么收消息：对比了"公网回调"和"长连接"两种方式，推荐长连接——不需要公网域名、不用做内网穿透，服务器直接连飞书即可
怎么调 Agent：用 loom-cli 的无人值守模式，一条命令把消息交给 AI Agent，拿到结果再回复
怎么处理"慢"：飞书要求机器人 3 秒内响应，而 Agent 干活可能要几分钟——方案里设计了"先回一条"处理中…"占位消息，干完活再把这条消息更新成结果"的体验
怎么管群聊：私聊全响应，群聊只有 @机器人 才处理
怎么部署：给出了常驻服务方案供选择
方案末尾还列了 3 个待人类确认的问题：是否已有飞书应用凭证、要不要支持群聊、用哪种部署方式。人类逐一回复——"支持群聊、用系统常驻服务部署、密钥稍后发你"——Loom 确认理解无误后才进入编码。这一步保证了方向不跑偏，也让人始终握有决策权。
4 全量编码：分模块推进，边写边验证
Loom 操作：按"配置 → 底层封装 → 事件处理 → 入口"的顺序逐模块开发，每完成一层就自测，全部通过后提交
编码阶段 Loom 不是把代码一口气倒出来，而是像真正的工程师一样分层推进：
第一步，打地基：先写配置模块（加载应用密钥、超时、并发等参数）和两个底层封装——飞书消息接口封装（发消息/回复/更新）、Agent 调用封装（调起 loom-cli、过滤输出里的统计信息、超时保护）。其中 Agent 调用封装写完就单独实测：真的调了一次 AI Agent，确认能拿到干净的结果，才继续往上写
第二步，搭流程：实现事件处理模块（消息去重、私聊/群聊判断、@机器人判断）和异步任务队列（保证机器人 3 秒内先应答，Agent 在后台慢慢干活）
第三步，收口：写入口程序，把所有模块串起来，启动长连接客户端
第四步，交付配套：部署脚本、配置模板、README，一样不少
每一层写完，Loom 都自己跑一遍检查：语法编译、模块导入、配置校验，全部通过才进入下一层。最终约 565 行代码、6 个核心模块一次成型，打包成一次完整的代码提交。人类在对话里看到的只是简洁的进度汇报："底层封装实测通过 → 全部模块验证通过 → 已提交"。
5 上线：机器人"入职"，成为长期在岗的同事
Loom 操作：带人类完成最后的"入职手续"，见证第一次真实对话，并把机器人转成 7×24 长期在岗
代码写完只是造好了"人"，这一步是让它真正"入职"：
办入职手续：只做了一件事——把飞书应用的密钥填进配置文件。Loom 全程指导，密钥写入后不会在任何地方回显，安全细节替想好了
第一次开口说话：启动后，Loom 确认机器人已经"上线在岗"。打开飞书，给它发了第一条消息，几秒后收到"已收到，正在思考中…"，片刻后答案更新在同一条消息里——第一次真实对话，一次通过
从"临时帮忙"到"正式编制"：试运行没问题后，Loom 把机器人转成了长期在岗状态——服务器重启它会自动回来，半夜意外掉线也能自己恢复，不需要人盯着。就像给新员工办了转正，从此它是团队里 7×24 在线的一员
交接文档：Loom 顺手写了一份完整的"上岗说明书"——怎么配置、怎么启动、出问题怎么排查，9 个章节讲得明明白白。以后换任何人来接手维护，照着做就行
到这一步，机器人不再是一个"跑在人类电脑上的脚本"，而是一个真正长期在岗、随叫随到的数字同事。
6 上线不是终点：用户反馈，Loom 及时响应
Loom 操作：接收人类的使用反馈，快速定位问题、修复、重新交付，形成"反馈 → 修复"的持续闭环
再周全的开发也无法预见所有真实使用中的情况——机器人上线后，团队在实际使用中陆续发现了一些边界问题：Agent 有时迟迟不回复、群聊里 @别人它也会插话、发张图片它也抢着回应。
关键在于响应方式：人类不需要自己排查，只需要把现象反馈给 Loom——"群里 @别人它也回复了"、"这条消息它超时没响应"，甚至直接把运行日志丢给它。Loom 每次都能很快给出回应：
快速定位：根据反馈的现象和日志，自己分析出原因，而不是让人类去猜
及时修复：找到原因后立即修改代码，改完自己验证，再重新上线
每次修复都有记录：一个反馈对应一次独立的代码提交，什么时候改的、改了什么，全程可追溯
几轮"反馈 → 修复"下来，机器人越用越稳：现在群里 @别同事不会再误触发，发图片不会再被抢答，Agent 干活也不会再无故卡住。
这正是人机协作最舒服的状态：人负责使用产品、发现问题；AI 负责消化反馈、持续改进。上线不是交付的终点，而是产品持续变好的起点。
结果对比
把这次实践拆开看，差别在每一环：
效率提升只是表层。真正的差别，是研发能力从研发手里，走到了整个组织面前。
机器人入职之后，真正的差别才显现。
过去，业务方想追一个缺陷状态、问一份接口文档、确认一次上线，得切出飞书、找研发、等排期。现在，这些研发动作收敛进同一个聊天框——业务在群里 @织灵，拉起 ADE Teams 查仓库、看构建、做 on-call 排障；研发资产不再躺在工具链里等人翻，而是变成群里能被对话调用的对象。答疑、周报、知识沉淀这类办公能力，织灵顺带就能做——但主角不是这些，而是研发能力本身第一次站在了组织面前。
把视线放远一点：当研发能力可以像 API 一样被组织调用，研发组织会发生微妙的变化。业务部门不再只是提需求、排期、等交付，而是在协作入口里直接触发研发资产——需求、代码、测试、部署的链路，会越来越多地在同一个对话流里闭环。工具链的边界进一步模糊，研发从重复劳动里退出，把精力交还给判断与架构；组织收获的，是一支不随人员流动而流失、可复用可传承的工程能力。这不会是某一家公司的特例，而是工程级 AI 原生研发平台正在重新定义"研发"的趋势。
可达智灵的定位始终是工程级 AI 原生研发平台。
我们想做的，是让研发工程回归创造——把重复交给织灵，把判断留给人和团队。