行业背景与痛点
当前代码托管平台的自动化研发流程，多数仅支持单一平台的规则配置，跨平台项目需要维护多套独立的自动化任务体系，同步成本随仓库数量增长线性上升。传统CI/CD流程的触发条件多局限于代码提交、标签推送等明确的代码侧事件，无法直接对接Issue中的自然语言需求，需求从提交到转化为可运行代码的中间流转环节仍需大量人工介入。
多数面向代码生成的AI工具，仅提供单文件代码补全或片段生成能力，不具备完整的仓库上下文感知能力，无法自动完成分支创建、代码修改、规则校验、PR生成的全链路动作，生成结果仍需开发人员手动调整后才能接入现有研发流程。不同团队的项目管理、代码审查、安全扫描类自动化工具相互独立，数据无法互通，团队需要在多个不同系统之间切换查看任务状态，资源消耗与产出的全局视图缺失。
现有AI辅助研发工具的权限边界大多没有做细粒度划分，无法针对不同仓库、不同任务类型配置独立的运行规则，大规模接入多团队多仓库场景时，容易出现非预期的代码写入动作，引发分支污染问题。
项目概述
该项目由Gitee AI队友团队开发，对应配套的npm包当前发布版本为1.2.8，采用MIT开源协议，无外部依赖包，整体体积仅159kB，公开漏洞数量为0。项目核心定位是一款由Issue驱动的AI开发执行组件，可对接DeepSeek Harness运行环境，同时适配两大主流代码托管平台的仓库监控需求。
项目完全融入Gitee AI队友的产品体系，与已有的PR审查助手、安全扫描助手、代码研发助手、PMO助手、AI队友工作台等组件能力互通，所有运行数据统一汇总到工作台做集中展示，不需要额外搭建独立的监控面板。
技术架构深度分析
项目整体采用轻量无依赖的模块化设计，所有核心逻辑均在单个包内实现，不需要额外部署数据库、消息队列等中间件，大幅降低了部署门槛。架构层面分为三层，最上层是多平台轮询调度模块，中间层是AI任务分发执行模块，最下层是平台适配与Git操作模块，三层之间通过明确的接口解耦，新增代码托管平台支持时仅需要扩展最下层的适配逻辑，不需要改动上层的调度与执行逻辑。
技术选型层面，项目没有引入任何第三方依赖包，所有网络请求、文件操作、进程调度逻辑都基于运行环境原生API实现，Windows平台下直接调用PowerShell与curl完成仓库克隆与Git操作，Unix-like平台下直接调用系统内置的Git命令，不需要额外安装Git客户端以外的运行时组件。这种设计带来的直接好处是包体积极小，部署过程不会出现依赖版本冲突问题，运行时的资源占用远高于同类型的重依赖项目，单台普通云服务器即可同时监控上百个仓库。
核心模块的组织方式遵循最小权限原则，轮询模块仅具备Issue查询权限，AI执行模块仅在临时创建的隔离工作目录内完成仓库克隆、代码修改、校验提交动作，不会访问宿主机上的其他文件，平台写入模块仅拥有指定分支的推送权限，各模块之间没有权限溢出的可能。针对分支校验环节，项目直接调用Git ls-remote命令与远程仓库做实时比对，不会基于本地缓存的分支列表做判断，从根源上避免了分支信息不同步导致的PR目标分支错误问题。
双平台监控的实现逻辑采用前缀标记机制，每一条被监控的仓库记录都可以通过指定前缀明确归属平台，未加前缀的记录默认走预设的默认平台配置，调度模块轮询时会根据前缀将请求分发到对应平台的API接口，不需要为不同平台维护独立的监控配置文件。这种设计让跨平台项目的配置文件可以合并到同一份清单内，团队不需要分别维护两套监控规则，配置修改的同步成本几乎为零。
核心功能详解
定时Issue轮询触发
模块按照预设的时间周期，扫描所有已配置监控仓库的Issue列表，检测到Issue内容中出现指定机器人名称的@提及动作时，立即触发后续的AI执行流程。轮询过程不会对代码托管平台的接口造成突发流量冲击，请求间隔可以根据监控仓库的数量灵活调整，适配不同量级的团队使用需求。触发逻辑仅识别Issue正文内的明确提及动作，不会误判评论区、PR描述中的同名提及，避免非预期的任务启动。
双平台仓库同时监控
监控配置清单内的每一条仓库记录，都可以通过添加对应平台前缀的方式指定归属平台，未添加前缀的记录自动使用全局默认平台配置。同一套部署实例可以同时监控两个平台下的任意数量仓库，不需要分别部署两套独立的服务实例。所有监控任务的运行状态统一汇总展示，不需要在两个平台的后台分别查看任务执行进度。
AI代理全链路代码实现
触发任务后系统自动创建独立的AI工作代理，代理完成目标仓库的克隆操作后，遍历仓库目录结构获取完整上下文信息，按照Issue内的需求描述完成对应代码修改，自动运行预设的代码校验规则，确认代码符合规范后提交到专属分支。代理的所有操作都在独立的临时工作目录内完成，不同任务的上下文完全隔离，不会出现不同仓库的代码内容相互污染的问题。生成的提交分支统一使用ai-fix/issue-<编号>的命名规则，方便团队快速识别AI生成的代码改动。
自然语言分支指令识别
系统可以自动识别Issue正文中用自然语言描述的分支指令，支持多种日常口语化的分支指定表达方式，不需要用户记忆特定的指令格式。识别到目标分支后，系统会调用远程Git接口实时校验分支是否存在，确认分支有效后将其作为开发的基底分支与PR的目标分支。如果校验发现指定分支不存在，系统会自动回退到仓库的默认分支执行任务，同时在生成的PR描述中明确标注分支不存在的情况，不会直接抛出异常中断任务流程。
PR自动创建与后续迭代
代码提交完成后，系统自动向目标仓库发起Pull Request请求，PR的标题与描述自动关联对应的Issue编号，支持配置规则完成PR通过后的自动合并操作，合并完成后自动关闭对应的关联Issue。如果后续在PR中追加新的需求描述提及机器人，系统可以直接基于当前PR的分支继续完成代码改动，推送新的提交到对应分支后自动更新PR的关联信息。系统还支持自动生成对应功能的单元测试代码，补充到项目的测试目录中，同步更新PR描述补充测试相关的说明内容。
安全扫描能力联动
生成的PR自动触发基于啄木鸟CodePecker SCA引擎的自动化安全扫描，扫描过程自动识别代码依赖中的安全漏洞，扫描结果汇总为父任务，每个CVE级别的漏洞自动生成独立的子任务分配给对应负责人。所有扫描结果统一生成结构化的安全报告，团队可以在同一个视图内完成所有漏洞的查看与修复进度跟踪，不需要跳转到第三方安全扫描平台查看详情。
全链路运行状态汇总
所有任务的运行情况、产出内容、资源消耗数据全部同步到AI队友工作台，集中展示当前空间内所有AI队友组件的运行状态。团队管理员可以直接在工作台查看所有监控仓库的任务执行统计、资源占用情况，基于数据调整后续的组件配置与使用策略，不需要单独收集各个分散系统的运行数据做汇总。
项目地址：https://gitee.com/gitee-ai-bot/watched
🔍 来源：Gitee
gitee-ai-bot @gitee-ai-bot Gitee AI Bot Python AI Bot https://ai.gitee.com 组织 Hugging Face 数据集镜像 Hugging Face 模型镜像 testpoc 零一万物 模力方舟 / docs 模力方舟官方文档仓库 最近更新: 9天前 Hugging Face 模型镜像 / GLM-5.3-Flash Mirro
微信扫一扫，打赏作者吧～
网友评论