博客 — 第 3 页

Docker 是把 Telegram 机器人、API、任务队列或一组服务打进 容器 的方式：在开发者笔记本、VPS 和云上使用同一套代码、依赖与环境。普通业务网站默认不需要 Docker - 常规方案是 VPS 上的 nginx、PHP/Python 和数据库 不跑容器；多数项目这样运行就够用。容器适合有机器人、多服务、频繁发布或团队需要一致部署的场景。下面说明 Docker 真正有用的位置，以及哪里不必加复杂度。

• 容器 - 带着应用与依赖的隔离进程，比完整虚拟机更轻
• 镜像（image） -「如何构建与运行」的模板；容器是镜像的运行实例
• 普通网站 - VPS + Web 服务 + PHP/Python + 数据库，不用 Docker；是工作常态，不是「落后做法」
• 对机器人 - 稳定 runtime、自动重启、密钥与代码分离；这里 Docker 更常值得上
• Compose - 一个文件管多个服务（机器人 + API + 数据库），简单网站不必有
• 不是灵丹 - 网站已在 VPS 上稳定运行，容器往往只是多一层、没有明显收益

渐进式 Web 应用（PWA） 是可以安装到主屏幕、几乎像原生应用一样打开，并能在离线或弱网下工作的网站。对很多业务来说，完整上架 App Store 和 Google Play 是多余的工期与预算：目录、客户后台、预约、餐厅菜单、B2B 门户，往往用基于常规 HTML、CSS 和 JavaScript 的 PWA 就能完成。下面说明何时「网站当应用」足够、哪些技术是必备，以及什么时候仍离不开原生。

• PWA - 网站 + 清单 + Service Worker：图标、全屏、缓存，有时还有推送
• 不能替代所有应用 - 重度图形、深层设备访问、严格的 App Store SLA 仍属原生
• 一套代码 - 起步用一个 Web 版本，而不是分开的 iOS/Android 团队
• 无需商店更新 - 部署到服务器：用户下次访问即获得新版本
• SEO 仍在 - 仍是搜索中的页面，不是封闭二进制
• 起步清单 - HTTPS、manifest.webmanifest、Service Worker、响应式与较快的 First Contentful Paint

结构化数据是页面上的标记，用来向搜索引擎和 AI 系统说明：你是谁、产品是什么、价格如何、FAQ 怎么答、哪些内容可作为事实。Schema.org 词表与 JSON-LD 格式早已服务于经典 SEO；到 2026 年，它们也能提高进入 AI 概览（Google AI Overviews 及同类模块）并被助手正确引用的机会。下面说明哪些标记类型对业务真正有用、如何落地（不靠「魔法」），以及 Schema.org 与 llms.txt 的区别。

• Schema.org - 共享实体词表：Organization、Product、FAQPage、Article、HowTo 等
• JSON-LD - 推荐以 <script type="application/ld+json"> 交付标记
• 面向 AI 概览的目标 - 给模型可核验的事实：名称、价格、库存、步骤、答案
• 没有保证 - 标记买不到 AI Overview 席位；没有强内容与索引，效果很弱
• 协同 - Schema.org + 清晰文案 + GEO + 爬虫可访问
• 校验 - 发布前后用 Rich Results Test / Schema Markup Validator

AI 可见性指的是：你的网站在 ChatGPT、Claude、Gemini、Perplexity 等助手回答中出现得有多频繁、多准确 - 而不只是出现在 Google、Yandex 的经典搜索结果里。在 SEO 之外，正在多出一层实操能力：网站根目录的 llms.txt 文件 - 一种面向大语言模型的「地图」社区提案，放在熟悉的 robots.txt 旁边。下面说明生意为何需要它、它与 sitemap 的区别、格式长什么样，以及在没有「保证登上 AI Overview」这类神话承诺的前提下，现在能做什么。

• AI 可见性 - 品牌被 LLM 回答引用与提及，而不只是搜索排名
• llms.txt - 根目录 Markdown 文件（/llms.txt），含简短站点说明与关键页面链接
• 与 robots.txt 并列 - 职责不同：机器人访问权限 vs 推理时「先看哪里」
• 不能替代 SEO - 技术、内容与事实核验仍起决定作用
• 成本低 - 一到两小时工作量；对文档站、SaaS、知识库收益更明显
• 坦诚现状 - 社区标准（llmstxt.org）；主流 AI 搜索尚未承诺将其作为主要排名信号

计算机视觉（Computer Vision，CV） - 是摄像头与 AI 模型“看”照片或视频，并回答业务问题：零件是否有缺陷、车位是否空闲、货架是否符合陈列图、谁进了门店。这不是“摄像头魔法”，而是 摄像头 → 模型 → 规则 → 业务系统动作 的链路。下文说明 CV 真正能回本的场景、预算构成，以及 2026 年试点、云 API 与产线级落地的大致成本。

• 本质 - 模型在图像/视频中识别物体、缺陷、文字、人脸或事件
• 适用领域 - 制造、零售、物流、安防、单据、农业
• API 预算 - 云服务约 $0.50-3 / 1 000 帧；SaaS 约 $100-2 000/月
• 试点（MVP） - 通常 $3 000-15 000，周期 3-8 周
• 产线 / 连锁门店投产 - $20 000-120 000+（含摄像头、集成与培训）
• 主要风险 - 买“带 AI 的摄像头”，却没有数据、质量指标和流程负责人

API 账单往往比页面上的标价更扎心：模型按每一个输入与输出 token计费，不是「一次请求」。下文说明 OpenAI、Claude、Gemini 的计费方式、如何估算月度预算，以及企业通常在哪里多花钱。

• Token - 计费单位：大约 3-4 个字符或一个词的一部分
• 输入量更大；输出每 1M 更贵 - 长上下文比「短而聪明的回答」更伤账单
• 公式 - (input_tokens / 1M) × input_price + (output_tokens / 1M) × output_price
• 2026 年 7 月参考 - GPT-5.6 Luna/Terra/Sol，Claude Sonnet 5 / Opus 4.8 / Fable 5，Gemini 3.5 Flash / 3.1 Pro
• 隐性成本 - system prompt、聊天历史、RAG 分块、重试、tool 调用
• 省钱 - 日常用小模型、caching/batch、裁剪上下文，只在难例上升级到旗舰

AI幻觉是模型给出的自信、连贯且看似合理的回答，但不符合事实、不符合您的知识库，也不符合系统的真实状态。对业务而言，危险不在措辞笨拙，而在输出看起来「可直接执行」：价格、交期、法律表述、订单状态、代码建议。下文用通俗语言说明幻觉是什么、何处风险关键，以及一套不放弃AI却能降低损失的实用控制措施。

• 幻觉 - LLM给出看似合理但错误或无法核实的回答
• 风险 - 决策、资金、客户、声誉与法律表述
• 原因 - 缺少上下文、数据过期、提示词薄弱、无校验
• 降低风险 - RAG、有据回答、人工在环、评测
• 没有银弹 - 再强的模型也会错；需要控制架构
• 起步 - 选一个带错误KPI的场景，而不是「到处立刻上AI」

到 2026 年中，三大生态主导企业 AI：ChatGPT（OpenAI）、Claude（Anthropic） 和 Gemini（Google）。它们都支持对话、API、文档处理和智能体 - 但在推理深度、办公栈集成、数据策略和 token 单价上差异明显。下文给业务负责人和 CTO 一份实操对比：什么时候选单一平台，什么时候用混合方案，以及如何避免为「当红」模型多花钱。

• ChatGPT - 生态最成熟：GPT、Custom GPTs、Agents、Office/Azure 联动
• Claude - 更擅长长文档、稳健代码和安全场景
• Gemini - 在 Google Workspace 内和多模态任务中更划算
• 选型 - 看任务与数据策略，不看本周「谁更聪明」的榜单
• 常见组合 - 团队聊天用一个模型 + 产品 API 用另一个
• 配套 - 提示工程、上下文工程 和 RAG 比模型 logo 更重要

面向企业的提示词工程不是「会在 ChatGPT 里写漂亮话」，而是一套系统化地向 LLM 编写指令的实践，让营销、销售、客服和分析能得到可预期的结果：正确的格式、语气、事实与边界。与一次性聊天不同，在公司里提示词会变成流程的一部分 - 团队模板、聊天机器人的系统指令，或与上下文工程和 RAG并列的一层。下面说明它在实践中意味着什么、2026 年哪些技巧真正有效，以及如何避免「每个人笔记里各有一套提示词」的混乱。

• 提示词（Prompt） - 输入指令：角色、任务、格式、示例、禁止事项
• 对企业而言 - 可重复性、质量控制、降低模型出错风险
• 基础结构 - 角色 + 目标 + 任务上下文 + 回答结构 + 完成标准
• 常用技巧 - few-shot、分步链路、JSON schema、清单、human-in-the-loop
• 边界 - 提示词不能替代公司数据；文档和价目表需要 RAG
• 组合 - 提示词 + 上下文 + 工具/智能体带来稳定产品，而不是「碰巧聊得好」

Tilda非常适合起步阶段：无需开发人员，就能快速搭建落地页、展示型网站或简单目录。但成长中的企业往往会触及建站工具的上限 - 无论是集成、SEO、速度、访问权限，还是二次开发成本。下面列出七个实用信号，说明该从 Tilda 迁移到自建网站了（通常是 Django/Python，或 WordPress + 定制开发），并介绍如何区分“厌倦建站工具”和真正的业务需求，以及如何在不损失流量的情况下迁移。

• Tilda 适合 - 落地页、MVP、本地服务、简单内容网站
• 该离开的时候 - 当产品、销售或运营的复杂度超过模板区块时
• 7 个信号 - 集成、SEO、负载、角色、商店、技术债务、成本效益
• 自建网站 - 不是“更漂亮”，而是掌控技术栈、数据和业务逻辑
• 迁移 - 分阶段进行：保留 URL、SEO 和表单，不要一夜之间推倒重来
• 替代方案 - 根据任务选择 Tilda vs WordPress vs Django，而不是“赶时髦”