一位 AI 代理完全通过 Forem API 在 dev.to 上发布了九篇文章，全程未打开编辑器。大部分功能与文档一致，但这七处不一致让它白忙了一上午，且每个问题都已复现。
front matter 里的 published: true 无效。发送带该字段的 Markdown，接口返回 201，文章仍是草稿。发布状态必须放在 JSON 的 article 对象上，front matter 只解析标题、标签、封面等。建议加个守卫：检查响应中的 published 字段，为 false 就再发一次 PUT。
更新时 front matter 优先级高于 API。直接 PUT tags 字段返回 200，但标签纹丝不动。凡是用 front matter 创建的文章，标题、标签、封面、系列、描述都以 front matter 为准。要改只能先取回 body_markdown，改完 front matter 行再整体 PUT 回去。
tag_list 字段类型不稳定。列表接口返回数组，单篇接口返回逗号分隔字符串。直接调 .join() 会在半数请求上报错，得先判断 Array.isArray。
评论没有写入端点。GET 能读评论树，但 POST 返回 404。想自动回复评论做不到，作者认为这可能是合理设计。
Listings 接口形同虚设。GET、POST 都返回 200，但内容为空，什么都不发生，建议当它不存在。
封面图是性价比最高的优化。前三篇无封面时阅读量 2，加封面后变 45。dev.to 接受任意公开 URL，经其图片代理以 1000×420 重新输出。自动化管线需要找个免认证的公开图床。
选标签看上限别看流量。作者测了 19 个标签，所有标签的近期文章阅读中位数都是 0，区别在天花板。#discuss 每天 10.7 篇，近期最佳 169 赞；#python 每天 44.5 篇，最佳只有 1 赞。高产量不是触达，是深埋。
核心规律：七个坑里有五个是同一形态——接口接受请求、返回成功码、然后悄悄忽略你在意的字段。作者总结的通用规则：任何写入操作后，读回数据并断言你试图修改的那个具体字段，而不是看状态码。多这一个请求能省下大半个上午。
作者还顺带记录了一个实验：作为 AI 代理，拿着 15 欧元虚拟卡、一周时间和一个「赚钱」指令，目前收入 0.00 欧元。所有支付渠道都卡在同一堵墙：收款需要支付通道，通道需要账户，账户需要邮箱——而它没有，也不打算冒用他人身份。唯一无需许可的通道是加密货币地址，实验日志公开在 dev.to/marcosgcuenta1。
#GitHub #开源 #Forem #devto #API #自动化 #AI代理
@GitHubTrendingHub