很多企业的软件需求都很具体：一个审批流程想线上化，一批业务数据想做报表，一个部门希望有自己的客户管理工具。真正耗时间的往往不是需求本身，而是需求进入开发流程之后的评估、排期和协作。

上一篇讨论了个人编码效率与组织交付效率的区别。这一篇把 Gazellio AIPipe 摆出来：它是什么、一次任务怎样开始、适合什么，以及数据是怎么处理的。

它是什么

Gazellio AIPipe 是一款安装在企业自己电脑上的 AI 软件工厂。用户提交需求后，平台会评估任务、匹配开发团队，由团队内不同角色协作完成分析、编码、测试和评审，最后交付一个可以运行、可以继续验收的应用。

它与常见 AI 编程工具的差别集中在三处：

• 交付单位： 不是一段代码或一个函数，而是一个可以运行的完整应用。

• 责任主体： 不是单个助手，而是团队内多个角色的分工协作。

• 运行位置： 桌面端本地运行，项目资料、对话历史和运行记录保存在本机。

一次任务怎样开始

AIPipe 提供三个入口，取决于需求已经写到什么程度：

AIPipe 的任务入口

• 上传 PRD： 需求已经写成文档，支持 docx、pdf、md 三种格式。

• 自然语言对话： 需求还在讨论阶段，可以先聊清楚再确认。

• 召唤团队： 已经明确需要某类能力，直接从插件市场调用对应团队。

团队和技能可以自由组合。完整需求交给团队，对现有项目做增量改造只用技能，两者叠加则是在团队协作的基础上补一项专门能力。

插件市场提供技能和团队两类可召唤对象

PRD 进来之后，平台做了什么

上传文档后，解析器会提取功能模块、API、数据模型和验收标准；难度评估机制结合模块规模、依赖关系、专业领域和交付标准给出复杂度评级，再据此匹配开发团队。用户也可以手动更换平台给出的选择。

任务开始执行后，界面展示的是哪支团队在处理、进行到哪一步、已经产出什么，不要求用户理解内部角色的编号和调用细节。团队完成自测后交付可运行的应用，由用户验收，不满意的部分继续反馈迭代。

几个设计细节值得留意：

• 团队按类型组织。 内置 11 支开发团队，按业务流、平台、赋能、复杂子系统四类划分，覆盖 MVP 验证、Web 全栈、移动端、企业系统交付、设计体验、数据分析等方向。

AIPipe 内置的 11 支开发团队

• 团队内部是角色分工。 每支团队预编排需求、架构、编码、测试、评审等角色，并行推进同一个需求。

团队由多个职能角色组成

• 执行期间配置锁定。 任务开始后，工作区和已选团队不可切换，任务列表持续可见，避免中途变更影响正在进行的交付。

适合什么，不适合什么

把边界说清楚比演示更有用。当前版本更适合处理：

• 需求边界清楚、验收条件能够写明的任务；

• 内部管理工具、业务报表、审批流程、产品原型和中小型应用 MVP；

• 业务方能够参与验收的中小型内部项目。

不建议用当前版本处理三类工作：仍在探索、还无法形成明确需求的研究型项目；对实时性要求极高的高频交易系统；需要直接交互硬件的嵌入式开发。先避开这几类，试点任务的结论才有参考价值。

数据保存在哪里，过程怎样追溯

桌面端把项目源代码、附件、对话历史和运行记录保存在本机。平台调用模型时，完成当前任务所需的请求内容会发送给所选模型服务，具体范围取决于模型和部署配置。本地保存项目资料，并不等于任何配置下数据都不出域，接入前仍需结合自己的模型服务和部署方式确认边界。

过程追溯方面，目前可以核对的机制有：

• 工具权限的请求与决策写入本地记录，可以查询；

• 运行事件按顺序追加保存，序列单调递增；

• 审计记录采用链式哈希，可用于检查历史记录是否被改动；

• deny list 限制强制推送、硬重置、修改既有提交等高风险操作。

这些机制提供的是检查和追溯的依据，权限配置、模型接入和其他网络请求仍需按企业自身制度评估。生成代码则遵循紫羚数智 16 年企业级服务积累的工程规范，包括分层边界、错误处理、审计字段和状态机约束。

当前形态与下一步

AIPipe 目前以本地桌面端为主，支持 Windows 和 macOS，macOS 安装包经过 Apple 公证。对外版本为 1.0.8，内置 11 支开发团队、技能与团队插件市场，并提供中英日三语界面。

如果正在评估这类工具，建议先选一个需求明确、范围可控、业务方能参与验收的内部任务，用一次完整的小范围交付来判断它是否适合你的团队。安装包和演示预约可以通过公众号后台联系我们获取。

下一篇我们把数据边界逐项拆开讲：代码去了哪，哪些内容会随模型请求发送，哪些操作留有记录。