# 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) --- ## 一、 核心背景与铁律约束提示(供顾问审阅对照) 1. **求职画像契合(Senior 全栈/DevOps/AI 架构师)**:严禁流露“做生意的老板/小公司创始人”倾向;一切商业实战均转换为“生产系统架构、高可用交付与自动化运维”视角。 2. **纯洁人设与零禁用词**:绝对禁止 `homelab`, `home lab`, `家用`, `小主机`, `玩具`, `折腾`, `玩票` 等词汇。必须使用 `the infrastructure I manage`, `my self-hosted production nodes`, `production host`。 3. **第一人称单数**:统一使用单数 `I` / `我`,杜绝虚张声势的复数 `we`。 4. **数据绝对保真**:所有数字、性能比率、吞吐提升、故障现象严禁凭空捏造。 5. **OPSEC 安全脱敏**:无内部绝对路径(如 `D:/dev`),无真实私有内网 IP,公网 IP 必须转为文档保留地址。 --- ## 二、 LinkedIn 拟发布动态文案 ```text 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. 优化修改建议(如有优化建议或修改文案,请在此批注)**: