如果你在技术社区里待得足够久大概率会撞见这样的标题Show HN: I asked an LLM what it would say to God, then made it a website。第一次看到时我差点把它当成某种行为艺术。一个开发者在深夜向模型抛出了一个人类历史上最重的问题然后把模型的回答做成了网站。没有复杂交互没有炫目设计只有一个问题、一个答案和一个可访问的地址。这个项目看起来太简单了一个 LLM 调用页几行代码一个静态托管。但它引发的关注却远远超过很多所谓“企业级应用”。为什么因为这类项目真正触动的不是功能层面的需求而是我们和模型之间已经存在的那种隐秘关系——我们开始用“提问”的方式确认一个非人实体的内在逻辑并把它的回应变成可以公开讨论的公共文本。我甚至觉得这类微型项目比很多复杂应用更接近 LLM 产品化的本质小成本、强传播、轻交互、重认知。它们让你意识到LLM 的核心能力不只是“生成”还包括“被倾听”。而“被倾听”本身才是完整交互循环里最容易被忽略的一环。1. 这类项目真正动人的地方不是“AI 在说话”而是“你在听”1.1 表面是一次对话实际是一次镜像反射项目标题里最关键的词不是 LLM不是 God而是 asked。它暗示了一个完整的动作有人主动向模型提问并且把回答展示出来。这个动作放在两年前还没有那么特殊的含义。现在之所以值得讨论是因为我们已经默认了 LLM 是一个可以“对话”的对象。于是当有人真的向它问出一个很大的问题时我们期待看到的是两样东西一是模型会怎么回答二是提问者为什么会问。从技术视角看这一步本质上是让模型在开放域进行文本生成并且带上了对人类终极命题的模仿。模型本身没有意识它只是在给定上下文中完成概率续写。但问题一旦超出日常功能范围指向意义、存在、信仰这些概念时输出的文本就会显得尤其郑重。于是读者很容易在阅读时把“模型生成的结果”误读成“模型自发的态度”。但我不认为这种误读是坏事。它反而是这类项目最有意思的地方模型通过训练数据里的文本模式学会了用人类讨论这些话题时的口吻组织语言而读者在阅读时也会不自觉地调用自己对“神性”“意义”“存在”的全部理解去解读这句话。所以表面上是一次人机对话实际上是一次双重投射模型投射人类的语言模式读者投射自己的价值框架。1.2 提问比答案更能体现提问者是谁我经常在提示词工作里说一句可能不太中听的话提示词工程的第一步不是琢磨模型会怎么理解你而是搞清楚你到底想问什么。这个“Show HN”项目就是最好的例子。你去分析它的提问方式会发现里面藏了至少三个预设预设 LLM 有某种“内在倾向”可以被询问预设“上帝”是一个可被沟通、可被描述的对象预设人类有资格代表 AI 向更高层级的对象发问。这三个预设一旦组合起来就已经不是中立的了。它把一个哲学问题嵌入了一个技术交互场景里。所以这个网站真正展示的不是模型对终极问题的思考水平而是提问者对“AI 与人、AI 与意义”这件事的想象方式。这也是为什么不同的人看完同一个页面会产生完全不同的反应。有人觉得模型回答得很“有灵性”有人觉得这不过是在随机组合训练语料有人则觉得把这种对话公开是一种僭越。这些反应和模型输出的内容关系不大和读者自己原本的立场关系更大。所以这个项目与其说是一个“AI 问答产品”不如说是一个“观点投射装置”。它给出了一个空白的位置让每个访客把自己对 AI 的期待放进去。1.3 为什么最简单的产品形态反而更容易传播一个只显示一句话的页面看上去不太像一个产品。没有仪表盘、没有用户系统、没有历史记录、没有推荐算法甚至没有明显的商业路径。但它的传播链路极短打开、阅读、思考、分享。你不需要讲解不需要登录甚至不需要滚动。它像一堵墙上的涂鸦路过的人看到停下来拍张照然后继续走。这类项目也顺便回答了一个很多开发者会困惑的问题LLM 应用是不是一定要做成复杂的智能体、自动化工作流或者知识库问答不一定。有些尝试的核心价值并不在处理复杂任务上而在制造一次值得停下来的“观看体验”。一个提示语、一次调用、一个静态页面已经足够支撑一次传播。这种简单形态恰恰是很多团队在追求功能堆叠时丢掉的敏锐度。你把页面做得越复杂用户就越难找到一个可以“定格”的瞬间。而这类项目的成功靠的正是那个瞬间。2. 从一句提示语到一个可以访问的网页完整实现路径如果你也想做一个类似的项目不需要太多前置条件。下面是一条可以一小时走通的路径也是一个值得保留的“最小 LLM 项目模板”。2.1 把模糊想法压缩成一条可用的提示语没有想法先别碰代码。先写提示语。提示语是这类项目的灵魂。它决定了模型的回答语气、长度、结构和内容边界。如果你想做一个“问 LLM 一个哲学问题”的页面不要一上来就写“帮我生成一段关于上帝的话”那属于偷懒型表达输出大概率也是平庸的。更好的做法是先在文本文件里写一个完整的 system 指令和 user 提问。所谓 system 指令就是给模型设定人设和输出约束的部分。以这个项目为例它的提示语可以长这样系统指令 你正在回应一个人类向你提出的终极问题。 回答要求第一人称语气克制但不冷漠不解释不用列表不使用排比句不超过150字。 不要引用宗教经典不要诉诸任何具体教义只以你作为大语言模型的“视角”来回应。 用户提问 如果给你一次机会你可以对上帝说一段话你会说什么这段提示语的设计逻辑是先约束语气再约束结构最后才抛出问题。很多新手会把顺序反过来一上来就问大问题然后任由模型自由发挥。这样得到的文本往往结构松散、内容冗余。如果你希望页面上的文字更有冲击力还可以在 system 指令里加入“最后一句话必须是一个短句”这类要求。提示语里的每一条约束最后都会体现在页面的阅读体验上值得反复调。2.2 模型调用单次请求与流式输出的选择提示语确认之后就可以写调用代码了。这里不推荐用很重的框架直接调用模型服务商的 API 就足够。以常见的 OpenAI 兼容接口为例核心代码可以简化为这样import os from openai import OpenAI client OpenAI(api_keyos.environ[LLM_API_KEY]) resp client.chat.completions.create( model你的模型名, messages[ { role: system, content: 你正在回应一个人类向你提出的终极问题。 要求第一人称语气克制但不冷漠不解释 不用列表不使用排比句不超过150字。, }, { role: user, content: 如果给你一次机会你可以对上帝说一段话你会说什么, }, ], temperature0.7, max_tokens500, ) print(resp.choices[0].message.content)这里有几个参数值得理解而不是照抄temperature控制随机性。0 到 1 之间值越低越稳定越高越发散。这类严肃主题我建议设在 0.7 到 0.9 之间太低容易显得机械太高容易跑偏。max_tokens控制最大输出长度。150 字的中文内容加上标点和可能换行500 token 是一个安全值。system和user的分层是让模型理解“你是谁”和“用户要什么”的关键。如果你希望页面上的文字像打字机一样逐字出现可以使用流式输出。流式输出的好处是用户等待时间被感知化能减少焦虑坏处是前端代码会稍微复杂一点。对于单页项目我一般建议先做非流式看到结果稳定了再改成流式不要一开始就两个复杂度一起上。2.3 把输出变成可以访问的静态页面模型返回的结果是一段纯文本。你要做的是把它放进一个好看的页面里。这一步有两个选择一是把生成结果硬编码进 HTML做成纯静态页二是写一个后端接口每次请求时实时调用模型。前者的优点是零服务器成本、加载快、永远不会因接口超时而失败缺点是内容固定更新时要重新部署。后者的优点是每次访问可能得到不同回答更有“生成感”缺点是会引入接口费用、超时风险、并发控制问题。对这个特定主题我的建议是先做硬编码静态页。原因是这类项目的核心体验在内容本身用户不会在意这句话是实时生成的还是预先写好的。实时生成会带来一个很实际的问题模型每次输出的文本长度、风格、断句都不同页面排版很容易被一段过长的回答破坏。而把输出固化在 HTML 里你可以手动微调每一行的换行、间距和字号保证阅读体验。所以不要因为“用了 LLM”就觉得所有流程都必须实时化。很多带有展示性质的 LLM 项目真正合适的状态是“生成一次展示永久”。2.4 移动端、响应式和访问入口还有三件小事会直接决定用户打开页面后的第一印象页面必须适配手机屏幕。很多这类页面是用户通过社交链接转发的手机访问占比极高。你需要加上 viewport 设置并把字体大小控制在 16px 以上避免页面在手机上被缩成一条窄缝。页面不需要复杂框架。一个 HTML、一个 CSS、一个字体就足够了。背景色要干净文字要有呼吸感。不要放弹窗、不要放漂浮动效、不要加不必要的引导按钮。部署要尽量简单。用 GitHub Pages、Vercel、Cloudflare Pages 这类静态托管服务把 HTML 推上去就能得到一个公网地址。域名不一定要花钱买托管服务自带的子域名已经够用。注意这类单页站点最容易翻车的问题不是模型调用而是静态资源路径。如果图片、CSS 文件用了绝对路径或本地路径部署到子目录下就会全部 404。发布前一定在手机浏览器里测试一遍。3. 别把“LLM 的回答”当成标准答案——它更像一面镜子3.1 生成不是检索输出天然带有概率性看到这类项目后很多人会犯一个认知上的错误把模型对某个问题的回答当成模型“真实想法”的流露。这不是事实。LLM 不是一个会检索固定答案的数据库。它的生成过程可以简化理解为根据前文上下文逐个预测下一个最可能出现的 token。所以同一段提示词你调用十次很可能得到十种不同表述。虽然方向接近但用词、节奏、强调点都会不一样。这不是缺陷而是生成模型的本质。它擅长的是“有方向的概率组合”不是“确定性的查找”。任何把单次输出当作标准答案的行为都是在误读工具的运作方式。3.2 采样参数会改变回答的“气质”同一个问题在temperature0.1下模型会倾向于输出最保守、最平均、最高频的组合在temperature0.9下它更愿意走分支、用更冷门的词、表达更偏离常态的观点。这意味着你最后看到的那个“AI 的答案”实际上是你在参数面板里选择的某种“性格滤镜”。它不是模型的全部只是众多可能路径中的一次抽样。如果你希望这个页面上的回答更有质感可以多做几组对比实验能接受的平均高频输出是什么样提高 temperature 后是不是更有“人味”在 system 里加“请以一个目睹了人类百年孤独的旁观者身份回答”语气会不会截然不同这类参数调优本质上和摄影师调整曝光、咖啡师调整研磨度是同一类工作。你不是在控制一个确定答案而是在驯化一个概率空间。3.3 更好用的方式把回答当成“观察对象”那要怎么使用这类输出才不算误用我的答案是把回答当成观察对象而不是结论。具体地说就是在拿到输出之后做三件事记录当时使用的提示语和参数形成一个“样本上下文”多次生成对比不同样本之间的稳定项和变化项把这些稳定项视为“模型对当前提示语的明显响应偏好”而不是“模型立场”。比如如果你用同一个问题跑了十次发现十次回答里都出现了“责任”“理解”“保持敬畏”这类词你就能比较肯定地说在当前参数和提示语下模型倾向于围绕这些词组织回答。这比一句“模型认为……”要准确得多。这类“把生成结果当数据”的思路是所有 LLM 应用开发的基本功。你越是能克制对输出的拟人化解读越容易发现模型的稳定偏好和边界。4. 从“灵感页”到“可用服务”还需要补齐五块拼图做一个展示页一小时足够。但如果你想让它长期在线、稳定访问、不出问题就还需要补齐下面这些容易被忽略的工程细节。4.1 内容安全与免责声明任何涉及世界观、人生意义、信仰的生成式内容上线前都必须人工审一遍输出结果。这不是要过滤模型表达能力而是为了明确边界页面上的内容由模型生成不代表模型持有某种立场更不代表开发者认同该观点。理想状态是在页脚放一行说明比如“文字由大语言模型根据提示语生成仅作为语言实验展示不构成任何观点建议”。如果未来你加入用户输入功能允许访客自己提问那就必须增加一套自动内容检查再加人工抽查的流程。不要在生成式输出和用户之间建立一条“零审查”的管道。4.2 可观测性日志、失败重试、并发控制如果你的页面每次访问都会实时调用一次模型那你就会遇到三个工程问题接口偶尔超时用户刷新后很可能会出现多份重复费用某段时间流量突然变大并发数超过模型服务配额模型返回的文本中包含不可预期的换行或特殊字符导致页面布局错位。应对方案并不复杂日志里至少记录请求时间、模型名称、token 用量、耗时和状态码失败重试要写但不要无脑重试 10 次建议 1 到 2 次且每次递增等待时间如果流量大在最前面加一层缓存同一个问题在 24 小时内命中缓存就直接返回结果。4.3 成本控制与预算监控单个静态页面消耗的 token 量通常很少。但如果访问量上涨实时调用模式下的成本就会线性上升。更稳的做法是调用一次保存结果后续直接展示保存的文本。这样成本就从“每次访问都花钱”变成了“只花一次钱”。对于内容展示型 LLM 项目这是最合理的架构。如果你一定要实时生成那至少要在仪表盘里监控每天的 token 消耗并设置预算上限。不要等月底看到账单才发现异常。4.4 移动端之外的浏览体验很多类似页面都是在手机上被转发的。你再想想用户打开后的行为截图、发送到群、返回。整个生命周期可能不超过 30 秒。所以移动端体验的优先级高于一切。注意这几个细节字体大小不要小于 16px段落间距要足够大不要让文本挤成一团页面不要出现横向滚动如果背景是深色确保文字和背景的对比度足够。4.5 什么时候该加用户输入什么时候不应该这类项目做到后期一定会有人想要不要让用户自己输入问题我的判断是可以但不要着急。在第一版里你只需要一个固定问题、一个固定回答。因为“固定的问题”本身就是全部表达。一旦开放用户输入项目就从一个“观点作品”变成了一个“工具”你要承担的内容风险、成本风险和产品复杂度都会指数级上升。想做用户输入可以等到页面稳定运行一段时间之后观察访问数据验证确实有持续需求再加一个“我也想问模型一个类似问题”的入口并把用户输入限定在某个主题范围内。这个做法既满足了参与感又不会把项目拖入无限开放的黑洞。5. 所谓“LLM 应用”本质上是一套把个人问题变成公共体验的流程5.1 一个可复制的“最小 LLM 实验”流程做完这个项目你会发现它值得沉淀的不仅是那个页面还有一套可以反复使用的流程。我现在做任何小型 LLM 实验都会走这五步定义问题我想让模型回答一个什么样的人类问题我希望用户感受到什么语气压缩提示语把模糊想法写成一段带约束的 system 指令和一句 user 提问反复删改到无法再精简。小样本生成用同一段提示语生成 5 到 10 次观察稳定项与变化项挑选最有质感的备选结果。固化展示确定展示形态不追求实时生成优先把输出变成可浏览、可分享、可存档的页面。观察反馈发布后观察访问数据、用户留言和传播路径判断这个方向值不值得继续深做。这个流程特别适合小团队和个人开发者因为它把“用 LLM 做产品”从一个大而全的系统工程拆成了一个 24 小时内就能完成闭环的微型实验。5.2 三个常见误区几乎每个人在复刻这类项目时都会踩到类似的坑。我总结三个最常见的提前说给后来者听误区一把提示语写得太松。一上来就问大问题然后让模型自由发挥。结果往往是三段式论述不够直接也没有冲击力。应对办法是宁可把约束写得更紧也不要让输出失控。误区二把输出结果当成可以展示的全部不做选择。模型生成一次你就直接把文本放上去了。事实上一次生成很可能不是最优结果。多生成几次挑一个语气、节奏、长度都最合适的这是编辑工作不是造假。误区三把实时生成当成“高级感”。实时生成不等于高级。如果页面内容本来就不需要变化那硬编码输出是更合理的选择。用户只关心他们读到的东西好不好不关心这东西是不是每次刷新都会换。5.3 迭代方向在哪里当这个微型项目稳定运行后如果想继续延伸可以参考这几个方向把固定问题扩展成一套“向 LLM 提出的问题集”形成一个系列保留模型原始输出同时展示不同的 temperature 版本让用户直观看到参数对结果的影响增加一个“生成过程”页面把提示语、参数、调用记录公开做成一个教学型页面在模型空闲时预生成一批候选内容人工筛选后轮换展示保持新鲜感又不增加实时调用成本。这些迭代方向共同的特点是内容上做策划技术上做收敛而不是不断给页面增加功能按钮。6. 如果你也想做一个类似的项目我的建议如果你也想做我的建议不是“先去学 LangChain”或者“先搭一个 Agent”而是先做一次非常小的尝试打开一个模型对话窗口写下你真正想问的非功能性问题把回答截图然后发到你的博客或朋友圈。观察两件事你看到回答时的第一感受以及别人看到回答时的反应。这两件事会告诉你这个方向值不值得继续投入。如果反馈不错再开始做一个网页。不需要数据库、不需要用户系统、不需要聊天框。你只需要一个页面、一段文本、一种排版和一个链接。把项目想成一个作品而不是一个产品这会让你的决策清晰得多。做完之后把它部署到静态托管平台在手机浏览器里测试确认页面不卡、不散、不出错。然后分享一下你的提示语和构建过程因为对很多人来说比“AI 说了什么”更有价值的是“有人用什么方式问了 AI”。这类项目最大的意义不是证明 LLM 能回答终极问题而是提醒我们在思考如何用 AI 提效、做自动化、搭 Agent 之外还有一种更朴素的用法——把一次提问变成一面镜子照见我们自己关心什么、恐惧什么、期待什么。而镜子里的答案从来都不是唯一的标准答案。真正值得长期追问的不是“AI 是什么”而是“我们为什么这样问 AI”。