3.9 KiB
3.9 KiB
LinkedIn Draft & Consultant Review: Architecting a 24/7 AI Support & Entitlement Bot Without Human-in-the-Loop
文档性质：从
blog.hoelee.com改写的 LinkedIn 待发布技术动态。 发布状态：待顾问审阅 (未在 LinkedIn 发布)源文章：https://blog.hoelee.com/posts/how-i-built-the-digikedai-telegram-bot/ 系统标识：how-i-built-the-digikedai-telegram-bot| 分类：case-studies字数：2069 chars (LinkedIn 上限 3,000 chars)
一、 核心背景与铁律约束提示（供顾问审阅对照）
- 求职画像契合（Senior 全栈/DevOps/AI 架构师）：严禁流露“做生意的老板/小公司创始人”倾向；一切商业实战均转换为“生产系统架构、高可用交付与自动化运维”视角。
- 纯洁人设与零禁用词：绝对禁止
homelab,home lab,家用,小主机,玩具,折腾,玩票等词汇。必须使用the infrastructure I manage,my self-hosted production nodes,production host。 - 第一人称单数：统一使用单数
I/我，杜绝虚张声势的复数we。 - 数据绝对保真：所有数字、性能比率、吞吐提升、故障现象严禁凭空捏造。
- OPSEC 安全脱敏：无内部绝对路径（如
D:/dev），无真实私有内网 IP，公网 IP 必须转为文档保留地址。
二、 LinkedIn 拟发布动态文案
Deploying an LLM as a customer-facing bot is easy. Building one that autonomously provisions production account entitlements without hallucinating or handing out unauthorized access is an entirely different engineering challenge.
I built a 24/7 customer support and instant trial-provisioning bot across Telegram and WhatsApp. The stack: TypeScript + Node 20, grammY in webhook mode behind a Hono HTTP server, a self-hosted LiteLLM gateway, and PostgreSQL for persistent state.
Three architectural boundaries keep it reliable in production:
1. Three-Tier Retrieval Over Context Stuffing
Dumping an entire product catalog into system prompts guarantees hallucinated specifications and prompt injection risks. Instead, the bot resolves intent through a strict hierarchy:
• Deterministic SKU regex token matching (`/\b[A-Z]{2,}\d{2,}\b/gi`)
• Normalized keyword metadata filtering
• Targeted semantic retrieval with bounded context injection
2. State Machines Over Prompt Engineering
An LLM is fantastic at natural language disambiguation and terrible at transactional state. Actions that touch data — trial provisioning, license issuance, verification — run on deterministic TypeScript state machines. The LLM only parses intent; it never touches the business transaction directly.
3. The Webhook Timeout Trap
Telegram will aggressively re-deliver webhook updates if your server does not respond within a tight timeout. If your LLM generation takes 4 seconds, Telegram re-fires the webhook, spawning duplicate LLM calls and cascading into an infinite reply storm. The fix: immediately acknowledge the incoming payload with HTTP 200, dispatch the generation to an async worker queue, and enforce idempotency locks on the `update_id`.
The system runs autonomously with a suite of ~175 unit tests verifying state transitions, retrieval precision, and payload contracts.
How do you separate deterministic business logic from probabilistic model output in your production agent workflows?
Write-up: https://blog.hoelee.com/posts/how-i-built-the-digikedai-telegram-bot/
三、 外部顾问审阅评估反馈单
- 审阅结论：[ ] 通过 / [ ] 需微调 / [ ] 需重构 / [ ] 建议暂缓
- 1. 职场形象评估（是否符合高级技术雇佣人设，无老板/卖货感）：
- 2. 技术真实性与逻辑推导（因果链条与数据是否严谨）：
- 3. 语言地道度与人设去油（是否纯正地道、零业余玩具感）：
- 4. 优化修改建议（如有优化建议或修改文案，请在此批注）：