Telegram 采购系统：无代码智能体开发案例

# 技术主管如何零代码在 Telegram 构建采购系统：代理开发案例研究

当团队内部采购陷入混乱——请求丢失、查询杂乱无章时，技术主管决定基于 Telegram 打造一套系统。无需编写一行代码，借助代理式系统和清晰架构，他构建了集成 OCR、审核机制以及安全部署的解决方案。下面分享如何在掌控质量的前提下实现它。

问题：采购流程变成一片混乱

在小团队中，采购往往从非正式约定开始。先是纸条，然后是便签，再到专属的 Telegram 线程。一个流程逐渐成型：丢链接、价格、数量和理由。但实际中，有些请求丢失，有些溜过去，有些缺价格或理由，人们还忘了自己的请求。结果，技术主管花时间对抗混乱，而不是管理采购。关键启示：涉及金钱的流程，不该是自由聊天形式。

基础设施需求：从小机器人到完整系统

最初想法——简单 Telegram 机器人——很快遭遇基础设施难题。由于 Telegram 无 VPN 时不稳定，需要：

• 海外 VPS
• 自定义 VPN 配置
• 可靠自动重启
• 便捷部署
• 发布失败时的回滚机制

这已不再是“晚上快速脚本”，而是完整的工程流水线。经验表明：“简单自动化”往往隐藏复杂基础设施。

代理开发：加速器，而非思考替代品

项目使用 ChatGPT 和代理式系统实现，但技术主管的深度参与至关重要。流程包括：

• 制定任务并分配角色
• 澄清业务逻辑
• 手动测试场景
• 识别矛盾和 bug
• 针对性迭代修复
• 重新测试

代理加速了循环：缩短从发现问题到验证新实现的时间。关键启示：可以委托代码语法，但系统思维和架构仍不可或缺。没有清晰流程模型，代理只会加速实现有缺陷的逻辑。

摒弃“魔法”：转向向导流程

首个假设——自动从链接提取数据——因以下原因不可行：

• 网站多样性
• 页面结构不稳定
• 价格模糊
• 数据渲染复杂
• 敌对的市场逻辑

取而代之的是向导流程：

• 附加截图
• 提供链接
• 填写理由
• 指定数量
• 如需手动输入价格（OCR 失败时）
• 确认前审视最终卡片

这种方式虽少“惊艳”，但确保可控性——运营流程的关键因素。

为什么不把 LLM 作为系统核心

虽诱人用 LLM 处理请求，但选择了简单技术栈：

• Python
• Telegram 机器人框架
• SQLite
• 本地 OCR
• 基于模板的 HTML 报告
• systemd 用于服务和定时器

理由：

• 低配 VPS 即可运行
• 无运行时依赖外部 API
• 无按请求付费推理
• 易调试
• 行为可预测

这一选择凸显关键原则：并非所有任务都受益于 AI。有时严格 FSM 和验证比复杂模型更有价值。

状态机：可靠性的基石

请求是一个带有生命周期的实体，包含状态：

• 草稿
• 等待图片
• 等待链接
• 等待理由
• 等待确认
• 待审核
• 退回修改
• 推迟至下期
• 紧急
• 已发送

使用 FSM 管理此循环。代码示例：

class PurchaseWizard(StatesGroup):
    waiting_for_image = State()
    waiting_for_link = State()
    waiting_for_reason = State()
    waiting_for_qty_lots = State()
    waiting_for_lot_size = State()
    waiting_for_manual_price = State()
    waiting_for_confirmation = State()

以及领域状态：

class PurchaseStatus(str, Enum):
    DRAFT = "draft"
    AWAITING_IMAGE = "awaiting_image"
    AWAITING_LINK = "awaiting_link"
    AWAITING_REASON = "awaiting_reason"
    AWAITING_QTY = "awaiting_qty_lots"
    AWAITING_CONFIRMATION = "awaiting_confirmation"
    COMPLETE = "complete"
    PENDING_MODERATION = "pending_moderation"
    RETURNED_FOR_REVISION = "returned_for_revision"
    APPROVED = "approved"
    CANCELLED = "cancelled"
    SENT = "sent"

当涉及角色、金钱和截止日期时，从消息处理转向状态管理。

架构：简洁是成熟标志

系统图：

Telegram user
    ↓
Bot handlers / FSM
    ↓
Purchase service
    ├── SQLite
    ├── OCR service
    ├── Moderation logic
    ├── HTML report builder
    └── Reminder / maintenance jobs
            ↓
        systemd service + timers

项目结构：

purchase_bot/
├── app/
│   ├── bot/
│   ├── db/
│   ├── services/
│   ├── templates/
│   └── main.py
├── data/
│   ├── uploads/
│   ├── reports/
│   └── bot.db
├── scripts/
├── deploy/
└── README.md

首版跳过 Docker 和重量级数据库，能专注功能。对于内部工具，简单架构是成熟标志，而非弱点。

Telegram 用户体验：界面胜于消息流

使用 Telegram 暴露诸多挑战：

• 旧按钮持久存在
• 卡片重叠
• 旧新请求版本并行
• 通知延迟
• “返回”按钮行为不一致
• 屏幕循环
• 聊天杂乱

解决方案：将机器人设计为基于屏幕的状态系统。核心原则：

• 单一活跃屏幕
• 删除过时消息
• 安全处理旧回调按钮
• 菜单、通知和工作卡片的分开规则

这种方式虽不华丽，但确保日常可用性。

真实流程打破对称性

实现审核、紧急请求和周期推迟显示，真实流程不匹配整齐图表。例如，若首轮审核已全覆盖，二审阶段会增加不必要摩擦。逻辑需为真实需求重构，而非图表。技术主管熟知此模式：方案阻碍流程时，打破方案。

最隐蔽 bug 出现在层间边界

关键错误并非核心功能，而是层间交汇处。例如：

• “确认”按钮卡住，因时区感知与非时区对象比较
• 模块间数据格式不匹配
• 更新时的状态同步问题

这些 bug 强调仔细设计组件接口的重要性。

关键启示

• 架构优先于代理：即使使用代理式系统，清晰架构和系统思维仍是必备。代理加速实现，但不取代设计。
• 可控性胜于“智能”：对于运营流程，可靠性和简洁胜过复杂自动化。向导流程往往优于全自动化尝试。
• 状态，而非消息：涉及角色、金钱和截止日期时，设计为带明确状态的管理生命周期。
• 简洁即策略：内部工具避免架构臃肿。最小栈在适中硬件上确保可靠性和易维护。
• Telegram UX 需要纪律：机器人应设计为屏幕系统，而非消息流。删除过时元素和单一屏幕对用户体验至关重要。

— Editorial Team