加载失败
原文（Medium 文章）声称通过 F12 网络面板、反编译客户端 JS 与 Playwright 自动化会话，结合响应延迟、token 使用与回退模式等指纹，发现大量初创直接调用外部 LLM API，从而得出“73% 的 AI 初创只是 prompt engineering”的结论。评论区围绕两个层面争论：其一是质疑文章方法学与数据透明度（样本、指纹法误判、文章像 LLM 生成、作者资料不全）；其二是现实讨论——许多团队确实用 RAG、tool‑calling、缓存与 evals 把通用模型垂直化，或仅做界面封装，但这既有合理的快速验证逻辑，也带来无护城河与定价风险。相关技术与项目包括 Claude（Anthropic 的模型）、RAG（检索增强生成）、Playwright（浏览器自动化工具）和 BM25 等检索技术，讨论同时觸及 VC 激励与长期商业可持续性。
大量评论质疑文章的数据采集与推断方法：作者称通过 F12 网络面板、反编译客户端 JS 并用 Playwright 自动化会话来识别是否直接调用外部 AI API（如 api.openai.com、api.anthropic.com），再以响应延迟、token 使用模式和 rate‑limit 回退做指纹识别，但批评者指出 F12 只能看到浏览器到自家后端的流量，后端与模型提供方之间的通信不可见，延迟/回退等模式容易与普通 DB 或其他服务混淆。评论还注意到文章风格像由 LLM 生成、作者资料或方法论未完全公开、样本规模与公开数据不足，因此对“73%”这一统计强烈怀疑。同时也有声音承认少数站点确实可能在前端直接调用模型（例如 realtime/session 场景），但这并不足以支撑大比例结论。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
多条评论反驳把这类公司贬为“只是写 prompt”的说法，详细列出把 LLM 推向生产所需的工程：建立代表性 evals、构建 RAG 流水线、混合 BM25+vector 检索与 rank fusion、query rewriting、reranker、并行化检索、tool‑calling、缓存与容错处理等。有人分享经验称实现稳健的 RAG 系统需数周到数月的迭代，包括自动化质量测试和参数调优以减轻 hallucination。结论是表面上的“写几个 prompt”掩盖了大量数据工程、检索工程和系统工程工作，不能简单地以“不是工程”带过。
不少评论将此现象类比历史上的技术堆栈复用：早期创业常常用现成平台或组件快速做出 UX/工作流以验证市场，LLM 被当作新的底层商品并无不妥。评论指出自行训练与维护大型模型代价极高，多数初创公司更合理的策略是把有限的创新资源投入到领域知识、产品化和工作流上而不是重造底层。有人同时强调，这种“包装”并不等同没有价值——垂直化集成与领域数据仍能创造可付费的产品。
很多评论警告以第三方模型为核心的公司缺乏长期护城河：一旦模型提供方将相同能力原生化、改定价或直接集成到大厂产品中，小公司很容易被替代。讨论提到 token 成本、模型定价和大厂集成功能的风险，并把这种脆弱性比作历史上被平台复制的移动应用案例。结论是包装型产品在短期可能获利，但面对供应方和平台层面的竞争压力时可持续性存疑。
多条评论将大量 wrapper 初创归因于风投资本和生态激励：VC 为了在财报里展示“traction”和多头案例，倾向支持能迅速交付业务指标的包装型产品，导致市场上出现大量表面上“AI”但技术深度有限的项目。评论指出在当前募资环境里，人脉和增长故事往往比长期可行性更重要，这会放大短期投机行为并造成资源错配。有人把这种现象与早期的泡沫类比，提醒社区对过度吹捧保持警惕。
一派观点支持先用通用 LLM 做 MVP 和市场验证，待获得付费/使用信号后再投入训练或微调专用、成本更低的模型以提升利润率和差异化。评论里指出专用模型在高频调用场景下能显著降低成本并提高稳定性，但这种替换需要足够的商业证据支持大规模训练投入。该思路被比作 Lean Startup：快速试错、获得用户数据后再优化底层架构与模型。
许多评论批评当前大量所谓 AI 应用只是把聊天式界面粘到现有产品上，缺乏对后端工作流的自动化與確定性設計。评论认为直接把 LLM 输出嵌入生产流程通常更慢、成本更高且非确定性强，正确的做法是用 LLM 快速迭代原型，然後把稳定逻辑搬回传统架构或用可靠的 tool‑chains 编排。真正有价值的 AI 应用应当实现无人工干预的自动化工作流或显著简化用户操作，而不是单纯的“聊天”壳。
LLM: LLM（大型语言模型）：预训练的生成式语言模型，如 GPT/Claude/Gemini 等，能生成文本、代码与对话，当前很多初创把它当成可租用的底层能力来封装产品。
RAG: RAG（Retrieval‑Augmented Generation，检索增强生成）：将外部检索（如 vector search、BM25）与 LLM 结合以降低 hallucination，常包含 chunking、reranker、query‑rewrite 和并行检索等工程步骤。
Prompt engineering: Prompt engineering（提示工程）：不仅是写自然语言提示，还包括提示模板、上下文构建、工具调用、缓存策略、提示注入防护与与 evals 结合的迭代优化，涉及数据与系统工程。
Evals: Evals（评估/验证流水线）：自动化或人工结合的质量评估体系，用来衡量模型在具体任务的表现、做回归测试并指导参数调优与产品迭代。
Playwright: Playwright（浏览器自动化框架）：用于脚本化浏览器操作与抓取网络请求的工具，文章作者声称用它自动化采集前端流量来推断是否存在直接调用外部模型 API。