AI 产品实战系列·观点篇。Codex、Claude Code 证明了"人下意图、AI 落键盘"的编程形态成立。我们判断：同一场变革正在逼近大文档编写——但它不会发生在 Word 里。这篇讲清楚为什么，以及"Vibe Docs"要补齐哪四块地基。
先亮观点：Vibe Coding 不是编程工具的一次升级，是"人机分工"的一次重新划界——人负责意图和验收，AI 负责生成和修改。这个分工模式和代码没有必然绑定，它迁移到任何"结构化的长文本工程"上都成立。而世界上最大的一类结构化长文本工程，是大文档：标书、施工方案、法律文书、审计报告、政府公文、学术论文。
我们做了一年"Vibe Coding for Documents"形态的长文档产品，这篇把实践里想明白的逻辑摊开。
为什么 Vibe Coding 先发生在代码上
反过来问更清楚：AI 写作助手比 AI 编程助手出现得更早，为什么"vibe writing"到今天都不成气候，而 vibe coding 已经在重塑行业？
因为代码世界自带四件基础设施，而它们恰好是"放心让 AI 大规模改动"的前提：
- 纯文本格式——代码就是字符流，模型输出即产物，零转换损耗；
- diff 原语——任何改动可以精确到行地呈现、评审、回滚；
- 版本控制——git 让"改错了"永远有退路，试错成本趋近零；
- 验证器——编译器、类型检查、测试套件，AI 改完立刻有客观信号说"行还是不行"。
Vibe coding 的全部魔法都架在这四件套上：AI 敢大改，因为 diff 看得见、版本退得回、测试兜得住。信任不来自模型多聪明，来自基础设施让错误廉价。
再看文档世界：主流载体是 Word——二进制封装、格式与内容纠缠、diff 基本不可用、版本靠文件名里的"最终版V7"、验证靠人眼通读。四件套全缺。AI 不是写不了文档，是文档世界接不住 AI 的大规模改动。这才是 vibe writing 十年难产的真正原因。
大文档的真面目：它是工程，不是文章
第二层论证：大文档配得上这套工程化改造吗？还是说它本质上就是"写作"，套 IDE 是过度设计？
看看一份投标文件的真实构成就有答案了：几十个输入文件（招标正文、清单、图纸）、十几章输出文档、章与章之间的强约束（人员表要和进度计划对齐、报价要和清单严丝合缝、技术承诺不能和评分办法打架）、外部合规规则（资质要求、废标条款）、多人分工、死线交付。
这是不折不扣的软件项目结构：多模块、有依赖、有约束、有测试（评标就是最严酷的验收测试）、要集成交付。用"写文章"的工具去干"做工程"的活，才是真正的错配。Word 之于大文档，就像记事本之于操作系统内核——能写，但没人该这么写。
所以"Vibe Coding for Documents"不是把编程工具的时髦皮套在文档上，而是第一次给大文档配上了与其工程本质相称的工具链。
Vibe Docs 的四件套怎么补
对照代码世界的四件基础设施，文档侧逐一有解，这正是我们这一年实践的主线：
① 纯文本内核：Markdown 做内核、Word/PDF 做导出格式。模型输出即文档内容，diff/版本/检索全部白拿。（形态篇讲过：选富文本内核的团队都在转换层里流干了血。）
② diff 原语 → 审批流：AI 的每处修改生成红删绿增的待审改动，人逐条签字才落库。比代码世界更严——因为文档没有"回滚重来"的宽容度，废标不给第二次机会。
③ 版本控制：改动前快照、软删保留、全程可回溯。用户敢让 AI 放手大改的底气来源。
④ 验证器——这是最关键、也最垂直的一块。 代码有编译器，文档的"编译器"要自己造：格式规则校验（编号、层级、表格完整性）、跨章数值一致性检查（正则全量扫描代替 LLM 抽样）、合规清单比对（资质、工期、废标条款）、直到 AI 模拟评审打分。每造出一个确定性验证器，AI 就多获得一块可以放心自动化的领地。 文档世界没有现成的"测试套件"，但评分办法、合规规范、格式标准就是天然的测试用例来源——垂直产品的护城河恰恰在这里，因为每个行业的验证器都得懂行的人来造。
和另外两种形态的分界
这个判断要立得住，得说清它和两个近邻的区别。
vs. Office Copilot（嵌入式助手）：Copilot 是把 AI 嵌进一个"渲染优先"的旧内核——Word 的文件格式、修订机制、对象模型都是为人手编辑设计的，AI 在里面永远是客人。Vibe Docs 是反过来：AI 原生内核，人机共用一套 diff 语言，渲染放到导出层。短文档、轻编辑，Copilot 够用；大文档工程，内核决定天花板。
vs. 通用 Agent（聊天框里出文档）：聊天框能一次性生成不错的初稿，但大文档的价值密度在第二遍到第 N 遍——打磨、对齐、合规、应对变更。没有文件树、diff、版本、验证器的聊天框，接不住这个长尾。这也是形态篇的结论：Chat 是入口，工作台是产品。
这个形态的终局想象
沿着四件套推到底，大文档编写的未来形态大概率长这样：
文档项目仓库化——一次投标是一个"仓库"，输入、输出、中间产物、参考资料结构化组织；改动全部 diff 化——人和 AI 的每次修改走同一套审查语言；验证流水线化——保存即触发格式 lint、一致性检查、合规比对，像 CI 一样亮红绿灯；Agent 做工头——按任务清单调度生成、修改、检查，人守在 diff 审批和最终签字两个关口。
那时 Word 的角色，就是今天 PDF 的角色：一种交付时才出现的只读格式。 大文档在 IDE 里被"开发"出来，导出成 Word 只是最后一次 build。
会不会太激进？看看编程世界的时间线就不觉得了：从 Copilot 补全到 Agent 接管整个任务，四年。文档世界的四件套一旦补齐，没有理由走得更慢——毕竟大文档行业里被重复劳动困住的人，比程序员多一个数量级。
Vibe Coding 证明了这条路能走通；谁先给一个大文档行业补齐四件套，谁就是那个行业的 Cursor。
AI 产品实战系列·观点篇（本篇为系列第三篇）。姊妹篇：《Chat 是入口，不是产品》《让用户敢在 AI 写的标书上签字》。姊妹系列「AI Agent 上下文缓存九篇」「工程实战」已完结，欢迎翻历史文章。
