YC 官推一条帖子，把「给 AI agent 写文档」变成了一门正经生意

导读

YC 官方账号亲自下场推了一家叫 Manicule 的公司——专门给开发者工具团队承包技术文档和 DevRel 内容，核心卖点：成本只要 DevRel 的一半，速度快一倍，而且文档专门为 AI agent 优化。当 Codex、Claude Code 这些编程 agent 开始直接读你的 docs 来调 API，文档质量差就等于把客户拱手让给竞品。

YC 亲自下场：「成本砍半，速度翻倍，给 agent 写」

5 月 15 日，Y Combinator 官方 X 账号发了一条帖子：

"Manicule owns docs and developer content for @Greptile, @Skyvern, @Supermemory, and others. Half the cost of a DevRel, twice as fast, written for agents."

「Manicule 为 Greptile、Skyvern、Supermemory 等公司负责文档和开发者内容。成本只要 DevRel 的一半，速度快一倍，专门为 agent 编写。」

▲ YC 官方 X 帖，发布后引发大量开发者回复"AUDIT"求审计

帖子末尾还挂了一个增长钩子：评论"AUDIT"即可获得免费文档审计。创始人 Naman Bansal 在回复里说"一个小时内亲手给每个人递送审计报告"——典型的早期创业手动承接打法。

这条帖子把三条线索压缩在了一起：DevRel 岗位的高成本、AI agent 对文档的依赖、早期 devtools 团队的增长困境。

文档烂，agent 就废：这才是 Manicule 切中的痛点

YC Launch 页面上，Manicule 开门见山点了痛点：

"Founders don't have time to write docs, engineers hate doing it, and it ends up on the backlog forever."

「创始人没时间写文档，工程师讨厌写文档，最后永远躺在 backlog 里。」

这在早期 devtools 公司里几乎是通病。产品迭代快、API 变动频繁，文档跟不上是常态。但过去这只是"用户体验差一点"的问题。

现在情况变了。

"Nobody knows how to optimize their docs for agents."

「没人知道怎么为 agent 优化文档。」

当 Codex、Claude Code、浏览器自动化 agent、内部 support bot 开始直接读你的文档来生成代码、调用 API、回答用户问题——文档里的每一个过时示例、每一段跳步说明、每一个跑不通的代码片段，都会被放大成agent 的幻觉来源。

▲ Manicule 的 YC Launch 页面，标题写着「AI Native Technical Docs & DevRel-as-a-Service」

Manicule 在 YC 页面上还放了一组自测数据：

"On average, agents perform no errors while using our approach vs failing 25% of the time with other frameworks."

「使用 Manicule 方案，agent 平均零错误；使用其他框架，agent 失败率 25%。」

注意：这是 Manicule 自述数据，没有第三方独立审计。但方向本身说得通——文档越干净、结构越清晰、代码片段越可运行，agent 犯错概率就越低。

15 天端到端翻新：拆解 Manicule 的服务链条

Manicule 官网把自己定位为documentation studio for developer tools，主标语相当有气势：

"BETTER DOCS, MORE REVENUE, LESS TICKETS."

「更好的文档，更多的营收，更少的工单。」

▲ Manicule 官网：engineers + writers + AI agents 团队，15 天内交付

官网把一个完整的文档翻新项目拆成了六个阶段：

• Day 1–2：审计——评估现有文档的结构、覆盖率、agent 可读性
• Day 2–3：信息架构——重新设计导航和内容组织
• Day 3–10：写作——AI agent 根据 OpenAPI spec 和 SDK 定义起草初稿，人类编辑做信息架构调整、代码验证、删废话
• Day 8–12：代码验证——确保每个代码片段可运行
• Day 10–14：视觉 + GEO 优化——让文档同时对人类、搜索引擎和 AI search 友好
• Day 15：发布上线

"We're a team of engineers, writers, and AI agents who build and write your technical documentation in <15 days, and then maintain it."

「我们是一支由工程师、写作者和 AI agent 组成的团队，15 天内构建和编写你的技术文档，并持续维护。」

这里的关键细节：Manicule 没有把"AI 写文档"包装成全自动魔法。它的工作流是 AI agent 起草、人类验证——代码测一遍、废话砍一遍、结构理一遍。YC 页面上也坦承：

"AI tools like CC hallucinate code snippets and write empty content without nuance."

「像 CC 这样的 AI 工具会幻觉出代码片段，生成没有细节的空洞内容。」

所以 Manicule 卖的是人机协作的服务，卖的是持续维护的能力——这也解释了为什么它选择做 studio 模式，而没有做 SaaS 产品。

案例和数据：有亮点，但要看口径

Manicule 的客户名单集中在 devtools / AI infra 赛道：Greptile（代码搜索）、Skyvern（浏览器自动化）、Supermemory（记忆 API）、Reducto（文档解析）、Rootly（事故管理）。

其中 Supermemory 是主打案例。YC 页面称，通过重新设计信息架构、AI agent 起草 + 人类精修的模式：

• 答案成功率提升 37%（YC 页面口径）
• Manicule 官网另一处写的是30% higher answer rates
• 自称促成$100K+ 企业订单
• AI search 和社交媒体获得数百万次曝光

▲ Supermemory 的文档页面——完整导航、quickstart、SDK/API 入口一应俱全

▲ Skyvern 的文档页面——结构化的 API Reference、使用指南、代码示例

重要提醒：30% 和 37% 这两个数字口径并不完全一致，且均来自 Manicule/YC 自述，没有独立第三方验证。$100K+ deals 和 millions of impressions 同理。把它们当参考方向看，别当审计结论读。

另外，客户文档页面本身并没有标注"由 Manicule 制作"——客户名单和案例归因全部来自 Manicule 和 YC 页面的自述。

文档的读者变了：从 SEO 到 GEO，从人类到 agent

Manicule 踩中的趋势比它自身的业务更值得关注。

过去几年，开发者文档的优化目标主要围绕SEO、人类开发者体验、API reference 完整度。但现在，文档多了一类全新的高频读者：模型。

Coding agent 读文档时最怕什么？

• 过时的代码示例
• 跳步的前置条件说明
• 跑不通的 snippet
• 页面噪声太多（导航栏、广告、脚本）
• 概念说明和 API 入口之间断裂

社区已经有了应对方案。/llms.txt 标准就是一个例子——它让网站提供 Markdown 格式的干净入口，专门给 LLM 消费，避免把 HTML 页面的噪声塞进 context window。

回复区有开发者写道：

"Developer docs are distribution for devtools. If nobody understands your API, adoption stalls before it starts."

「开发者文档就是 devtools 的分发渠道。如果没人看得懂你的 API，产品还没开始推就已经卡住了。」

还有一条说得更到位：

"If the docs work for agents they probably work better for new devs too. Both struggle with implicit context."

「如果文档对 agent 友好，大概率对新手开发者也更友好。两者都怕隐含的上下文。」

背后的逻辑其实一样：agent-ready docs 和 newbie-friendly docs 的核心诉求高度重叠——都需要零跳步、可运行、无隐含假设。

边界在哪：DevRel 能被外包多少？

"DevRel 成本的一半、速度的两倍"是一个很有冲击力的销售对比。但 DevRel 的工作远不止写文档。

社区运营、开发者关系维护、线下活动、生态合作、产品反馈回路——这些 Manicule 都不碰。它更准确的定位是docs + developer content + GEO/AI search 优化 + 技术写作 studio，承包的是 DevRel 里最标准化、最容易拆分的模块。

对于早期 devtools 团队来说，这个拆分有意义。种子轮的公司养不起全职 DevRel，但文档烂又会直接拖垮 API adoption。Manicule 提供了一个中间选项：把文档这条线先跑起来，等公司长大了再建自己的 DevRel 团队。

不过，"written for agents"这个定位要落到实处才有价值。具体机制包括：清晰的 API reference、可复制可运行的代码片段、OpenAPI/SDK 对齐、llms.txt 和 Markdown 友好的内容结构、尽量少的隐含前置条件、方便 RAG 和 coding agent 检索的页面组织。

口号好喊，文档难写。未来 docs 要同时服务三种流量：人类开发者直接阅读、搜索引擎 / AI search 摘要抓取、coding agent 和 support agent 自动检索并执行。Manicule 把 GEO、socials、product videos 和 docs 打包在一起卖，本质上是把文档当成了增长漏斗的入口。

这门生意能做多大还不好说。但它指向的方向很明确：AI agent 时代，好文档的价值被重新定价了。

文章来自于"桂宫说事"，作者 "硅基智能"。