机器人可以做什么
第一层尽量不使用专业术语。下面列出可以直接交给我们的具体任务类型。
线索与请求
分步流程、自由文本、文件、联系方式，并把请求送入实际业务系统。
通知
来自 CRM、后端、设备或内部系统的事件自动通知正确的人。
流程操作
命令、状态、审批和业务动作无需单独开发一个应用。
聊天中的个人空间
角色、用户数据、历史、设置以及受控功能访问。
你描述问题，我们把它转化为技术方案。
无需提前选择框架、协议或架构模式。先确认实际目标、现有限制以及不能破坏的部分。
谁在使用、现有系统是什么、需要得到什么结果。
第一阶段包含什么，需要与哪些系统集成。
分析后给出工期和工作量，而不是按“页面数量”给出虚假价格。
架构与运行细节
如果你只关心最终结果，可以跳过本节；如果你负责技术部分，这里展示我们如何处理系统内部的复杂性。
01集成比菜单更重要
CRM 与后端
机器人建立在真实业务逻辑之上，而不是变成一个孤立数据库。
Webhook 与 API
从现有系统接收事件，并把用户输入发送回业务系统。
多个平台
Telegram 和 MAX 可以共享服务器端业务逻辑，由不同适配器处理平台差异。
运行可靠性
日志、错误处理和重复保护需要考虑外部 API 的失败。
02作为用户流程的一部分
与网站衔接
请求可以从网站开始，在聊天中继续，并保留上下文。
人工接管
自动化流程可以切换给人工处理，同时保留历史。
事件驱动通知
消息由真实系统事件触发，而不是依赖管理员手动发送。
可扩展性
新的命令和数据源建立在共享业务逻辑上，而不是在每个平台复制一份。
清晰阶段，可验证结果
大型软件项目不应该连续几个月像一个无法观察的黑盒。
- 01
需求分析
任务、用户、限制以及现有系统。
- 02
系统边界
组件、数据、集成关系和关键风险。
- 03
实现
分阶段交付中间结果，并验证关键场景。
- 04
发布
上线、诊断、更新以及后续迭代。
机器人开发成本取决于什么
简单信息机器人和深度连接 CRM/后端的机器人是完全不同的产品。评估重点是业务逻辑、集成、角色和可靠性，而不是按钮数量。
对非标准软件而言，在需求不清楚时给出精确价格，通常意味着预留很大的风险空间，或者后续不断追加费用。我们先明确系统和风险，再评估真正需要完成的工作。
常见实际问题
不做营销式承诺，只说明在项目开始前能够确定的内容。
一个系统可以同时支持 Telegram 和 MAX 吗？+
可以。业务逻辑放在共享服务器层，每个平台只保留适配器，可以减少不同渠道之间的行为差异。
机器人可以连接 CRM 或内部系统吗？+
可以。机器人通常只是现有业务流程的一个入口，通过 API、webhook 或专用集成层访问数据。
可以把对话转给人工吗？+
可以。架构可以从自动流程切换到人工处理，同时保留请求上下文和对话历史。
当项目跨越多种技术
通过相关页面可以直接进入你真正关心的系统部分。
从一段描述开始就够了。
说明什么需要正常工作、目前已有些什么，以及你希望得到什么结果。
Email ↗