WritingFlow

我最早在意的，其实不是“AI 会不会写”，而是另一件更实际的事：那些真正要交付的长内容，到底怎样才能被稳定推进。

工作里需要写的内容很多，产品分析、行业研究、方案材料、项目总结，都属于这一类。它们有一个共同点：不是短文本，不是把一句提示词扔进去就能直接交付的东西。它们通常围绕一个明确主题展开，背后连着大量知识材料，包括基础知识、业务知识、科研资料、内部报告、历史文档，以及上级要求的格式和规范。真正的困难，不是把一句话写顺，而是在这些约束之下，把一整篇内容写完整、写连贯、写得前后成立。

这也是我越来越明确的一件事：长内容的问题，本质上不是生成问题，而是结构、知识和上下文一致性问题。

短文本场景里，AI 处理一段话往往已经足够有用。它可以扩写、改写、润色、压缩，效率也很高。但只要进入长报告，问题就会立刻变化。最常见的情况是，写到后面忘了前面，改了中间一段之后上下文断掉，或者明明已经有了大纲，AI 却并没有真正理解大纲，只是在顺着标题往下堆字。结果是局部看着还行，整篇却越来越散。

也正因为如此，我后来不再把写作理解成“输入框里的文本处理”，而更愿意把它看成一条围绕作品持续推进的主链。WritingFlow 是在这个判断下长出来的。

一、为什么现有写作 AI 不够

现有很多写作工具的问题，并不是完全没用，而是它们大多停在段落层。

它们很擅长处理当前这一小段内容，甚至能把当前这段处理得相当漂亮。但报告型写作真正困难的地方，从来都不是某一段怎么润色，而是整篇内容怎么组织。前后章节是否呼应，论证是否重复，中间修改会不会破坏整体结构，这些才是长内容最耗精力的地方。

如果一个系统默认“当前屏幕上的这一段，就是它此刻需要理解的全部内容”，那它天然更适合轻量文本，而不适合复杂写作。因为长报告不是单段文本的堆叠，而是一个不断演化的结构对象。它有大纲，有章节依赖，有知识来源，有历史版本，也有持续变化的判断。系统如果接不住这些层，就只能在局部层面来回修补。

所以 WritingFlow 要解决的，不是“让 AI 再多写一点”，而是让它真正进入长内容的推进过程。

二、为什么主链必须从大纲开始

对长报告来说，大纲不是附属工具，而是主控制面。

真正难写的内容，往往不是语言不流畅，而是结构不稳。写到一半发现两章重复，写到后面发现前面的判断接不上，或者局部越改越顺，整篇重心却慢慢偏掉。这些都说明问题不在句子，而在结构。

我理想中的写作过程很清楚：先搭大纲，再让 AI 按大纲去填充内容，填充之后由人回来看中间哪些地方不合理，然后继续修改。关键在于，修改不能只盯着当前这一段，而要能顾及这次修改对上下文的影响。它应该知道这一段属于哪一章，和前文、后文、全局目标分别是什么关系。

这也是为什么 WritingFlow 必须是大纲驱动的。只有大纲先成立，系统才知道自己到底在推进什么，而不是单纯围绕文本表面做响应。

三、为什么知识库必须进入写作主链

报告型写作不是从空白开始的，而是建立在知识之上的。

很多内容背后都有明确的知识库。可能是科研资料，可能是业务背景，可能是历史报告，也可能是一些内部文件、规范要求和已有结论。真正麻烦的，不是“没有东西可写”，而是这些材料通常散在不同地方，调用成本很高，而且一旦脱离当前主题，AI 很容易生成出看起来通顺、实际上没有根据的内容。

如果知识库只是一个放在旁边的资料区，写作、资料和 AI 仍然是分裂的。用户还是得手动去搬运上下文。这样的系统顶多算是“带资料的编辑器”，还不是一个真正适合长内容工作的写作工作台。

更合理的方式，是让知识库直接进入主链。主题材料可以被整理、检索、引用、继承，系统在填充内容时也要知道当前可以调用什么、应该遵守什么、哪些内容已经在别处写过。只有这样，写作才不是一次性生成，而是和知识沉淀形成真正的循环。

四、为什么 AI 的角色不是代写，而是协助推进

WritingFlow 的目标不是“让 AI 替作者写”，而是“让 AI 帮作者把复杂写作组织起来”。

这条边界非常重要。只要产品目标变成“替代作者”，方向就会自然滑向一次性输出、即时满足和局部效率最大化。这条路并不是错的，但它更适合短平快内容，不适合复杂报告。

长内容真正需要的，是一套能降低结构管理成本、降低资料调度成本、降低上下文切换成本的系统。AI 当然要参与，但参与方式不该只是代写一段，而应该是理解大纲、填充结构、辅助修订、帮助用户在局部修改后维持全文一致性。

也正因为如此，WritingFlow 更适合被理解成创作基础设施，而不是智能代写工具。

五、为什么模型切换和人工修改都必须保留

写作这件事，不能把成败完全交给单一模型状态。

不同模型在大纲理解、内容填充、上下文控制上的表现并不一样。有的时候写得很好，有的时候又会显得很蠢。这当然和模型能力有关，但产品不能把所有问题都推给模型进步来解决。

所以 WritingFlow 必须同时保留两种能力：一是模型接入和切换能力，二是人工直接修改能力。用户要能根据场景选择模型，也要能在文件层面对内容进行修正。而且这种修正不能是一次性破坏，它之后还应该继续回到系统主链里，被重新理解、重新承接。

只有这样，AI 才不会成为一个不可控的黑箱，而是工作流中的可调度能力。

六、为什么它天然会走向 B 端场景

只要内容开始涉及内部资料，WritingFlow 就不再只是一个通用写作工具。

很多报告都不是公开写作。它们会涉及企业内部知识、业务数据、历史材料、制度规范，甚至一些只允许在特定环境里使用的内容。到了这个阶段，模型是不是能自己接入，系统能不能进入企业内部环境，数据隐私和内容安全怎么保证，就都会变成主问题。

所以 WritingFlow 从一开始就不应该只按 C 端工具理解。它当然可以服务个人写作者，但它同样需要支持组织内部的模型接入、知识接入和安全边界。这不是后续附加需求，而是这类产品天然会遇到的真实约束。