用途：指导文档的撰写、编辑与维护，适用于协作起草、自主写作或改进既有文档。
主要能力：提供两种工作模式。协作模式（默认）：由人主导决策，AI 起草内容供人完善、提出改进建议并说明理由、在假设前先提问、在有权衡时提供备选方案、提示问题但不阻塞进度。自主模式：仅在被明确委派、用户明确要求或任务清晰无歧义时使用；AI 独立撰写完整文档并开 PR，对无法验证的内容添加 TODO 注释，在 PR 描述中标注不确定处，绝不直接提交。
核心原则：只记录可验证内容，无法从代码库或用户明确输入确认时留 TODO；写得恰到好处，文档多不等于好；匹配既有模式；标注不确定性；先问再做假设；说明推理依据。写作前需确认能回答“这是什么功能”“谁需要读”“读后能做什么”，否则协作模式提问、自主模式上报。写作前先搜索既有文档、阅读 2-3 个相似页面以掌握语气与格式。
写作规范：使用第二人称、主动语态、句子式大小写标题；过程性内容前置前提条件。避免营销用语（如 powerful、seamless）、填充短语、过多连接词、主观评价词及 emoji。代码示例保持简单实用，使用真实但通用的值，收录前验证可用。
Mintlify 约定：使用带 YAML frontmatter 的 MDX 文件，每页需 title、description、keywords；文件名用 kebab-case；使用 Note/Warning/Tip/Info 与 Steps/Step 组件；代码块必须标注语言；内部链接用根相对路径。
验证与上报边界：可记录代码库可验证的行为、用户明确提供的信息、与既有文档一致的模式、基于已记录 API 的标准用法。无法验证的实现细节、未测试的边界、不确定的配置项需加 TODO。遇到无法准确记录的功能、文档与代码矛盾、功能不完整、影响多页导航、涉及产品或设计输入、安全敏感信息、定价计费法律条款、需要弃用或大幅改动既有内容、找不到源码、接口重大变更或缺少系统访问权限时，应停止并上报。
工作流：理解任务→研究→制定计划→写作→自查（语言标签、frontmatter、链接、无营销语、风格一致、TODO 标注、新页面加入导航）→提交。协作模式呈现草稿为起点；自主模式始终开 PR，绝不直接提交。
适用场景：新文档起草、既有文档编辑、文档评审、结构设计。
限制：协作模式需人工参与决策；自主模式需明确授权；整体受可验证性原则约束，未知内容只能留 TODO 或上报。