dev.to #ai观点
我的产品的第二受众没有眼睛
dev.to作者：LaunchSignal观点AI评分：70/100
作者指出，过去产品落地页是为手机端用户设计的，但如今AI智能体（Agent）成为新的“第一受众”。智能体抓取URL时会剥离CSS和图片，导致导航、Cookie横幅和缺乏图片语境的标语成为主要信息。这改变了产品发现逻辑，要求设计必须适应机器阅读而非仅人类视觉。
我一直误解了自己的落地页。
多年来，我针对的是在手机屏幕上滑动浏览的用户来优化页面：一行主标题、一张截图、一个按钮。最近，我开始像代理（Agent）那样阅读这些页面：抓取 URL，剥离 CSS，看看剩下什么。通常剩下的只有导航菜单、Cookie 横幅文本，以及一条只有在图片旁边才有意义的标语——而那张图片现在已经不存在了。
这改变了我对发现机制的看法。越来越多的情况下，“看到”新产品的第一个主体是一个为某人查找信息的模型，而不是真人。它不会看你的英雄大图。它读取文本并调用接口。
以下是我现在在构建任何网站时都会检查的三个层次，从成本最低到工作量最大排列。
- llms.txt：一个告诉机器它正在查看什么的页面。它只是根目录下的 Markdown 文件。说明这是什么、哪些页面很重要，以及它不是什么。最后这一点让我感到惊讶。像“这与……无关”这样的一行文字，比我所写的任何元标签都能更好地消除歧义。这是一个廉价的文件，它迫使你不用形容词来描述你的产品。
- 一个带有枯燥、可预测错误的 JSON API。代理无法眯着眼睛去辨认表单字段上的红色边框。它需要
{ "ok": false, "error": "invalid_category" }这样的响应，以及在某个可读位置列出的允许值列表。OpenAPI 文件，即使是最小化的版本，也能将“搞清楚这个网站”转化为“阅读合同”。最终，错误代码对我来说比成功响应更重要。
- MCP，适用于代理已经位于编辑器或聊天环境中的情况。MCP 服务器是相同的契约，但工具会显示为模型可以直接调用的对象。它只是配置文件中的一个 URL。读取操作如
list和get是自然的起点。写入操作则需要更加谨慎。
我不断重新认识到的是，机器的发现主要关乎可读性，而非排名。没有算法可供操纵。要么模型能解析出你是什么以及你接受什么，要么它不能，然后转向它能处理的其他事物。
由此产生了一些习惯：
- 我先写一行描述，然后原封不动地粘贴到各处。代理会比对来源，不一致的描述会被视为噪声。
- 分类是封闭列表，而非自由文本。机器可以处理枚举类型，但对模糊的感觉无能为力。
- 任何由机器生成的内容都要经过人工审核。“无需认证且公开”意味着你应该预料到热情的调用者，因此写入操作应进入待处理状态，而非直接生效。
- 我大约每月一次用不带 JavaScript 的方式 curl 自己的页面。这很令人谦卑。
这一切并不能取代人们发现你的作品。但随着越来越多的人是通过先读取你网站的某种实体而来访的，确保那个实体形成了正确的印象是值得的。
我正在一个小众列表网站 LaunchSignal 上尝试这三个层次，该网站的提交通过 JSON API 和 MCP 服务器以及表单进行。我仍在了解代理实际使用了哪些部分。
好奇其他人对此的做法：你们是否已经将机器读者视为真正的受众，还是仍将其视为次要考虑？