AI生成的文档越写越长，阅读体验却越来越差？问题可能不在提示词，而在模型本身的中文表达能力。本文作者用Grok整理项目文档后，发现翻译腔和机械感严重，并总结出上下文做减法、文档定期精简、全局背景稳定、Skill适合固化流程而非创作、不同任务选不同模型等实用经验。

不讲人话的AI模型，对产品经理及周边的同事们是一种顶级折磨

昨天正好Grok发布了4.6模型，我手上又有一个Cursor账号，听说这个模型很强，于是我就拿它来整理之前项目里的各种文档，让它帮我诊断出一些问题。

用了一段时间之后，我发现自己越来越看不下去它写的东西了。

它不是完全不能用，逻辑也不算差，但读起来真的很难受。同一件事会反复讲，表达里有很重的翻译腔和机械感。为了显得严谨，它总想把所有场景、细节和例外都补充进去，最后文档越写越长，阅读体验却越来越差。

这让我重新意识到一件事：有时候我们觉得AI生成的文档不好读，不一定只是提示词没写好，也可能是模型本身的中文表达能力不适合这个任务。

有些模型擅长推理和补全，却不擅长用自然、简洁的中文把事情讲清楚。它会下意识地兜底，把所有可能发生的情况都写进文档。

但真实团队里的很多事情，并不需要每次都从头解释。

团队成员已经形成了共识，很多默认前提大家都知道。文档真正需要写清楚的，往往只是这次发生了什么变化，哪些规则需要确认，哪些地方和原来的做法不一样。

AI不知道这些默认共识，所以会不断提醒你：这里可能遗漏了，这里还没有对齐，这里需要补充，这里可能存在风险。

这些提醒本身没有错，但如果全部写进正式文档，文档就会变成一份为了“严谨”而牺牲阅读体验的说明书。AI看起来很认真，团队成员却根本不想读。

这次使用AI整理文档，也给了我几个启发。接下来就聊聊这几个比较明显的感受。

一、给AI上下文，不是越多越好

回头看这次体验，我越来越觉得，给AI的上下文要做减法。

我们很容易觉得，给AI的资料越多，它就越了解项目，输出也应该越准确。但实际情况经常相反。一个项目里有很多历史文档、过程记录、废弃方案和重复说明。如果这些内容都在AI可以读取的范围内，它很可能会把它们当成当前仍然有效的背景。

于是，AI会把历史内容、临时讨论和正式规则混在一起，最后生成一篇看起来完整、实际上重点不清楚的文档。

对于不希望AI读取的文件和目录，也要明确写出忽略规则。可以通过AGENTS.md、README或项目指令，告诉AI哪些资料是历史归档，哪些内容已经废弃，当前任务应该优先读取哪些文件。

大家会花很多时间给AI准备资料，却很少告诉AI哪些资料不要读。最后项目目录越来越大，AI的上下文越来越长，输出也越来越复杂。

历史资料、废弃方案和重复说明混在一起，AI也会把它们当成当前背景。

二、文档需要定期精简

上下文做减法只是第一步。文档本身也需要定期整理和精简。

业务会变，项目边界会变，原来的方案会被替换，临时讨论也会失效。这些内容一直留在项目里，AI就很难判断哪些是背景、建议，哪些是当前规则。

更麻烦的是，AI会顺着原有文档继续补充、展开和兜底。原来的文档已经有点长，它会认为这些内容都很重要，下一次再把长文放回上下文，内容只会继续膨胀。

这很容易形成一个恶性循环：

文档越来越长，AI读到的内容越来越多；AI读到的内容越多，输出又会变得越长。

所以，项目文档要定期做减法：合并重复说明，归档废弃方案，标记失效规则。不是所有过程都值得长期留在AI的默认上下文里。

这里还要允许适当留白。

团队已经达成共识时，文档不需要把每个默认前提都重新写一遍。内部文档可以保留一些大家都知道的内容，也可以暂时留下一些不影响当前任务的模糊点。

这不是放弃准确性，而是不要把每个团队共识都写成第一次见面的用户手册。

三、全局业务背景，必须精简而且稳定

除了文件和文档本身，项目的全局背景也很重要。

我在做「沙盘推演」项目时，就明显遇到过这个问题。这个项目涉及强盛科技的发展背景，也涉及进销存和ERP。如果强盛科技到底是一家什么样的公司、项目为什么要做、进销存和ERP分别解决什么问题，没有提前交代清楚，后面AI生成的内容就很容易在项目边界、目标用户和业务场景上混在一起。

它可能把公司的发展史当成每个页面都要引用的背景，也可能把某个进销存模块里的局部规则，扩展成整个ERP项目的通用规则。

所以，全局背景不是写得越多越好，而是要尽量做到精简、准确和稳定。

我们需要反复确认几件事：

• 公司到底做什么？
• 这个项目到底解决什么问题？
• 项目服务哪些用户？
• 哪些信息是所有模块都要知道的？
• 哪些内容只在某一个模块里有效？

这些问题没有打磨清楚，后面的文档、原型和业务分析都会跟着混乱。

我现在越来越觉得，AI项目里最重要的资料，不一定是最长的那份，而是每次都会被读取、影响后续输出的全局背景。

它应该像一张项目地图，告诉AI我们是谁、正在做什么、边界在哪里。某个页面的临时方案、某次讨论过程和废弃规则，不应该和全局背景混在一起。

四、Skill适合固化流程，不一定适合固化创作

Skill本质上是一套动态提示词、模板和执行套路。如果你希望一件事每次都按同样方式完成，Skill确实很有价值。比如生成字段清单、检查文档结构、执行固定验收流程，这些任务都适合被固化。

但写文章不一定是这样的任务。

我之前以为写文章也可以被固定成一个套路，所以专门整理过一个写作Skill。后来我发现，只要使用它，文章就很容易变成固定结构：先讲背景，再讲问题，然后讲解决方法，最后总结几条心得。

这种结构偶尔使用没有问题，尤其适合供应链、产品方法和系列化文章。但如果每篇文章都这样写，读者很快就会发现，文章虽然完整，却没有什么变化，也没有什么人的气息。

同样的开头、转折和总结用多了，AI味和机械感就会很浓。我自己写着也会觉得别扭。

重复流程可以固化，文章的观点、结构和节奏还得留给人。

我自己现在的做法是，先把真实经历和核心观点写出来，再让AI帮我整理、补充和润色。

我可以用Skill约束具体的表达习惯，比如哪些词我不喜欢，哪些表达方式不符合我的语气，哪些地方需要减少AI腔。但文章的内容、结构和节奏，还是应该由我自己来决定。

所以对我来说，Skill更适合帮助AI稳定完成重复任务，不适合替代人的创作判断。

五、不同任务，应该选择不同的模型

我后来还发现，同样是使用AI，产品经理和研发、技术人员的需求点并不完全一样。研发更关心代码能不能运行，产品经理则经常要让AI生成业务文档、梳理逻辑、解释规则，最后还要把内容发给别人阅读。

所以，产品经理不能只关注模型的推理能力，还要关注它的文字处理能力、遣词造句和中文表达。

有些时候，可以先用逻辑能力较强的模型梳理业务和结构，再用中文表达更自然的模型润色。不要强行要求一个模型同时完成资料理解、业务推理、结构设计和中文加工。

复杂任务可以先交给推理模型，再交给中文表达自然的模型润色。

我自己目前的使用体感大概是这样：

我目前比较放心的还是Claude系列。用它生成和润色文档，中文表达相对自然，读起来比较顺，属于第一梯队。

GPT系列的文字表现有时比较好，有时会有波动。把任务范围、表达方式和篇幅要求交代清楚后，GPT5.6的文字阅读起来也还不错。

Composer2.5是我现在使用比较多的工具。它不一定每个方面都最强，但整体比较均衡，速度、成本和中文表达之间的平衡比较好。输出有一点AI味，但可以继续加工。

至于Grok4.6，我这次使用它整理文档的体感比较差。翻译腔和机械感明显，发给别人看之前需要做很多人工修改。说得直接一点，这一块确实比较拉闸。

国产模型里，很多人觉得DeepSeek很好，但我自己用下来的感觉比较一般，在复杂业务和中文文档表达场景里还没有达到预期。

这些判断都只是个人体感。模型好不好，还是要放进真实任务里试。同一个模型在聊天、写代码、做总结和写公众号文章时，可能完全是不同的表现。

最后

这次经历给我最大的提醒就是：AI不是越严谨越好，输出也不是越完整越好。

在真实工作里，很多内容可以适当留白；在项目资料里，很多文件可以不让AI读取；在文章创作里，也不必把所有结构和表达固化成Skill。

我们应该让AI帮助自己发现问题、梳理逻辑、补充信息和润色文字，但不要把创作全部交给它。

写文章这件事，我越来越觉得，重要的不是AI能不能按模板写出完整文章，而是里面有没有你的经历、判断和表达方式。

AI可以帮我们把话说得更清楚，但不能替我们决定到底想说什么。

所以，我现在更愿意把AI当成写作助手，而不是全权代写的人。先由自己提供真实经历和观点，再让AI整理和打磨。这样留下来的，才不会只是一篇完整的AI文章，而是仍然有一点自己的东西。

如果你也有长期使用的模型，觉得谁写中文比较自然，谁的AI味比较重，也可以在评论区告诉我。模型还是要放进真实工作里多试几次，才知道适不适合自己。