不要像其他人那样构建 AI 产品
LLM API 让发布“AI 产品”变得很容易，但许多评论者认为，没有独特数据、工作流或领域洞察的 ChatGPT 薄包装层终究是死路一条。他们主张从真实用户问题和传统软件设计出发，只在真正需要 AI 的狭窄环节引入专用模型，同时警惕平台风险、延迟、成本，以及过早过度设计自定义工具链的诱惑。另一些人则反驳说，快速、甚至带有复制性质的原型仍然有价值，因为它们能帮助理解边界、吸引用户，并逐步迭代出真正有用的 AI 增强功能。
AI 作为工具 vs. AI 作为业务本身
- 许多人认为“真正的秘诀”是先拥有一个可行的业务，再用 AI 去改进它（例如：给现有的邮件产品增加摘要功能）。
- 也有人认为某些模型之所以可行，正是因为 AI 带来了成本下降，所以以 AI 为中心的业务是有道理的，但风险更高。
- 几条评论讽刺泛泛的“AI 初创公司”，说这就像宣称“我们是 Python 初创公司”或“web3 初创公司”一样，却没有清晰的问题定义。
平台风险与 OpenAI 包装层
- 强烈担忧围绕 OpenAI 做薄包装层没有护城河，可能被 OpenAI 本身或竞争对手压价或复制。
- 有些人认为早期做“API 包装层”是一个可接受的学习阶段，也是获取经验和用户的方式，即使首个产品之后会被颠覆。
- 重点在于，如果你既不拥有 API，也不拥有客户，你实际上就是在租用，随时可能被“驱逐”。
工具链、微调与模型选择
- 文章建议构建专用模型再配合“普通代码”，整体上很受欢迎，但也有人认为对很多团队来说，去构建编译器/工具链过于夸张。
- 对微调存在分歧：有些人认为它是关键差异化手段；另一些人则因数据杂乱而觉得不现实，更偏好 few-shot 提示、函数调用和 RAG。
- 也有人怀疑小团队能否维护自定义模型，因为前沿模型迭代太快，可能很快让内部工作失去意义。
产品策略：问题优先 vs. 技术优先
- 强烈支持从用户需求、工作流和 UX 出发，而不是把“AI 产品”当作一个类别。
- 反复警告不要做“在寻找问题的解决方案”，这与之前的 blockchain/web3 浪潮相似。
- 也有人认为，大量快速做 MVP（即使是技术驱动的）仍然是技术人员发现真实问题的一种有效方式。
聊天机器人与用户体验
- 许多人不喜欢客服聊天机器人，认为它们像过滤器，阻止用户接触到真正有权限的人。
- 也有人表示某些机器人体验很好（例如电商退款、内部分流），并期待 LLM 能显著改善聊天 UX。
- 普遍认为，机器人只有在真的能做事时才有价值（比如变更套餐、发起退款），而不只是复读 FAQ——但这又与安全和 prompt-injection 问题相冲突。
延迟、性能与 MVP 权衡
- 对于多分钟的 LLM 运行是否可接受存在争论：对于后台流程或交接流程可以，但对于紧密的交互循环来说太慢。
- 有些人认为，前期重工程（自定义编译器、工具链）是一种过早优化，会拖慢从用户那里学习的速度；另一些人则认为这是避免做成普通、无聊的 ChatGPT 包装层所必需的。
数据、隐私与自托管
- 据说有些企业拒绝基于 OpenAI 的产品，但愿意与承诺更强控制或本地部署的初创公司合作。
- 另一些人认为，隐私担忧被夸大了，因为企业早已广泛使用主流云 SaaS，而且只有在非常大规模下，自定义托管才可能在成本上优于 OpenAI。
炒作周期与差异化
- AI 经常被拿来与过去的 Kubernetes 或 blockchain 热潮相比；发帖者对它最终会有多大变革性存在分歧。
- 共识是，差异化必须来自难以复制的东西——深入的工作流洞察、数据、UX 或集成——而不是仅仅“我们用了 LLM”。