[论文阅读] AI + 软件工程 | 突破LLM上下文瓶颈：上下文内存虚拟化CMV的设计与实践

优质文章学习记录

— 23 min read
[论文阅读] AI + 软件工程 | 突破LLM上下文瓶颈：上下文内存虚拟化CMV的设计与实践

突破LLM上下文瓶颈：上下文内存虚拟化CMV的设计与实践

论文基础信息

  • 原标题：Contextual Memory Virtualisation: DAG-Based State Management and Structurally Lossless Trimming for LLM Agents
  • 主要作者：Cosmo Santoni
  • 研究机构：帝国理工学院（Imperial College London）
  • 发表时间：2026年2月
  • 引文格式（GB/T 7714）：SANTONI C. Contextual memory virtualisation: DAG-based state management and structurally lossless trimming for LLM agents[EB/OL]. [2026-02-25]. arXiv:2602.22402v1 [cs.SE].
  • 开源代码：https://github.com/CosmoNaught/claude-code-cmv

研究背景

大语言模型（LLM）在代码编写、复杂推理等长时工作会话中，会逐步积累大量核心状态——比如代码库的架构映射、技术选型的权衡决策、项目的编码规范等，这些内容构成了LLM对任务的完整心智模型，但构建这一模型需要消耗大量的时间和令牌成本。

当会话积累的内容触达LLM的上下文窗口上限时，平台的原生压缩功能会对已有内容做大幅精简，例如Claude Code的/compact指令曾将132k令牌的会话内容压缩至2.3k令牌，直接丢弃了98%的细节信息，让LLM失去了耗时构建的精细理解。而新的会话只能从头重建上下文，这造成了根本性的效率浪费。

现有解决方案均存在明显短板：检索增强生成（RAG）仅能补充文档，无法保留会话状态；MemGPT仅支持单会话的内存分页，不能跨会话复用；记忆插件只保存摘要，丢失对话细节；而LongLLMLingua等提示压缩技术，仅在模型/嵌入层修改上下文表示，未处理原始对话日志的结构冗余。

简单来说，当前LLM的上下文管理就像没有保存功能的记事本，写满了只能删掉重来，而开发者亟需一种能“保存进度、复用内容、精简冗余”的上下文管理方案，这正是本研究的核心出发点。

一段话总结

这篇2026年2月发表的研究提出了上下文内存虚拟化（CMV） 技术，为LLM智能体解决长会话中上下文窗口受限、状态易丢失的问题，其核心是基于DAG的状态模型 实现会话状态的版本化管理与跨会话复用，搭配三阶段结构无损修剪算法，在完整保留用户与助手对话原文的前提下剥离机械冗余内容，平均减少20%令牌数、最高达86%，混合工具使用会话平均减39%；经76个真实编码会话的单用户案例评估，该技术在提示缓存机制下具备经济可行性，混合工具会话10轮内即可实现成本盈亏平衡，同时CMV通过分支功能避免了从头重建上下文的高额成本，虽存在修剪无语义判断的局限性，但为LLM智能体的上下文管理提供了工具层解决方案，也为未来AIOS架构的持久化上下文子系统设计提供了参考。

思维导图

在这里插入图片描述

详细总结

本文由帝国理工学院的Cosmo Santoni于2026年2月发表，聚焦LLM智能体长会话中上下文窗口受限、累积状态易丢失的核心问题，提出上下文内存虚拟化（CMV） 技术，从模型设计、算法实现、经济验证三方面完成方案落地，并分析了技术局限性与未来研究方向，最终验证了工具层解决LLM上下文短暂性问题的可行性。

一、研究背景与现存问题
  1. LLM长会话的核心痛点：LLM编码智能体在长时工作中会累积代码库架构、决策等大量状态，上下文窗口满后，原生压缩（如Claude Code的/compact）会大幅精简令牌（实测132k令牌压缩至2.3k，减少98%），丢失精细理解，新会话需从头重建上下文，存在根本性效率低下。
  2. 现有解决方案的局限
    • 状态保留类：RAG仅增强提示不保留会话状态；MemGPT仅支持单会话内存分页；记忆插件仅保存摘要，丢失对话细节；原生会话工具无命名状态和谱系跟踪。
    • 提示压缩类：LongLLMLingua、RECOMP等技术聚焦模型/嵌入层的上下文表示修改，未处理原始对话日志的结构冗余，与本文方案形成互补。
  3. 核心需求：需要一种在工具层管理原始对话日志，既能减少令牌数，又能完整保留模型合成理解的上下文管理方案。
二、CMV的核心设计与贡献

CMV借鉴操作系统虚拟内存技术，抽象掉LLM上下文窗口的物理令牌限制，支持按需加载保存的状态，核心有三大贡献：基于DAG的状态模型、三阶段结构无损修剪算法、提示缓存下的实证成本分析，且方案与智能体无关，可适配所有存储对话日志并使用工具调用模式的系统，参考实现基于Claude Code。

三、基于DAG的状态模型
  1. 形式定义：将会话历史建模为有向无环图(G=(V, E))，其中节点(v)为不可变快照（会话JSONL日志的副本+元数据），有向边((v_i, v_j))为分支（从快照(v_i)派生的独立工作会话，最终生成(v_j)）。
  2. 四大核心原语操作
    • Snapshot：将当前会话生成为不可变快照节点，原会话不修改；
    • Branch：从快照生成新会话，默认启用修剪，可添加定向消息；
    • Trim：组合快照与分支，一步完成当前会话的修剪并启动新会话；
    • Tree：可视化DAG结构，实现类似git log --graph的对话谱系展示。
  3. 实践意义：实现Git式的LLM上下文工作流，用户可将耗时构建的上下文（如80k令牌的架构理解）生成为根快照，基于此派生多个并行分支完成不同任务，无需重复构建上下文。
四、三阶段结构无损修剪算法

这是CMV的核心技术，在完整保留用户消息、助手响应、工具调用元数据原文的前提下，剥离原始工具输出、Base64图片等机械冗余内容，解决令牌冗余问题，同时保证API调用正确性。

  1. 核心设计：处理JSONL格式的对话日志，分三个顺序阶段，前两阶段为轻量扫描，第三阶段完成实际过滤，核心可配置参数为存根阈值τ（默认500字符，最小50）。
  2. 三阶段流程
    • 阶段1：压缩边界检测，定位最后一次原生压缩的边界，避免重复处理已精简内容；
    • 阶段2：预边界工具ID收集，收集压缩边界前的所有工具使用ID，为处理孤儿工具结果做准备；
    • 阶段3：流式过滤修剪，按规则处理日志，仅将处理后的内容写入新日志。
  3. 关键修剪规则：跳过预压缩内容、移除文件历史/队列操作元数据、删除Base64图片块、移除非可移植的思考块、对超阈值的工具结果/写入工具输入生成存根、剥离孤儿工具结果、删除API使用元数据。
  4. 核心难点解决：处理孤儿工具结果（原生压缩可能导致工具调用与结果分离，直接使用会触发API验证错误），通过阶段2收集ID、阶段3剥离对应结果，无需用户干预即可保证API正确性。
五、经济评估：提示缓存下的可行性验证

以Claude Opus 4.6为基准，对76个真实编码会话开展单用户案例研究，评估修剪在提示缓存机制下的经济可行性（修剪会修改提示前缀，触发缓存冷启动惩罚）。

  1. 评估基础
    • 成本模型：考虑缓存命中率(h)，区分缓存写成本（冷启动）与缓存读成本（稳态），计算冷启动惩罚(\Delta_{penalty})、每轮节省(\Delta_{savings})与盈亏平衡轮数(n^*)；
    • 会话筛选：3个月的Claude Code会话，排除子代理会话、短会话（<10消息/<5000令牌），最终76个有效会话；
    • 会话分类：按工具结果字节占比分为混合工具型（≥15%）（12个）和会话型（<15%）（64个）；
    • 定价标准（2026年2月）：
      | 模型 | 基础输入(/百万令牌)∣缓存写(/百万令牌) | 缓存写(/百万令牌)∣缓存写(/百万令牌) | 缓存读($/百万令牌) |
      |------------|---------------------|-------------------|-------------------|
      | Opus 4.6 | 5.00 | 6.25 | 0.50 |
    • 假设条件：稳态缓存命中率(h=0.9)，盈亏平衡轮数上限60轮。
  2. 核心评估结果
    • 整体结果：76个会话平均令牌减少20%，中位数12%，最高86%；平均盈亏平衡轮数35轮，混合工具型会话为核心收益场景。
    • 分类型结果：
      | 会话类型 | 数量 | 平均令牌减少 | 中位数令牌减少 | 平均盈亏平衡轮数 | 平均上下文令牌 |
      |----------------|------|--------------|----------------|------------------|----------------|
      | 混合工具型(≥15%) | 12 | 39% | 33% | 10轮 | 97k |
      | 会话型(<15%) | 64 | 17% | - | 40轮 | 82k |
      | 所有会话 | 76 | 20% | 12% | 35轮 | 84k |
    • 关键规律：令牌减少超30%的会话，15轮内即可实现盈亏平衡；最高减少（60%-86%）主要来自预压缩历史跳过，混合工具型主要来自工具输出/元数据剥离。
  3. 隐性价值：未量化的上下文重建成本
    修剪的可量化收益为令牌节省，而CMV的核心价值是避免上下文重建：平均84k令牌的累积状态，从头重建需10-20轮用户交互、15-30分钟，且令牌成本呈二次增长；而从快照分支仅需一次提示加载（84k令牌缓存写成本$0.53，后续缓存读仅$0.04），这一价值在用户体验中占主导。
  4. 订阅用户价值：对按次计费的订阅用户，无直接财务收益，但可减少每轮令牌占用，延长有效会话长度，避免因大上下文快速耗尽速率限制。
六、局限性与未来工作
  1. 核心局限性
    • 修剪的结构无感知性：仅按类型剥离冗余，无语义判断，若剥离的内容被后续推理需要，模型可能产生幻觉或需重新读取；
    • 评估的单用户局限性：仅基于单个用户的编码会话，结果在不同使用模式、代码库下的泛化性待验证；
    • 令牌估算偏差：对图片密集型会话，字节-令牌的估算方法会高估减少效果（API对图片收取固定视觉令牌费）。
  2. 未来研究方向
    • 量化修剪对LLM下游推理准确性的影响，开展修剪与未修剪分支的对照实验；
    • 开展多用户评估，覆盖多样化的使用模式和编程风格；
    • 基于自动修剪日志数据，设计自适应存根阈值；
    • 将CMV的DAG模型和修剪算法，整合到AIOS（LLM智能体操作系统）的持久化上下文子系统中。
七、研究结论
  1. CMV为LLM会话状态提供了原则性的持久化、版本化管理框架，将短暂的会话数据转化为可复用的资源，实现了跨会话的上下文复用模式（分支、链式、团队共享），突破了现有“单任务单会话”的范式；
  2. 三阶段修剪算法在保证对话完整性和API正确性的前提下，实现了显著的令牌减少，且在提示缓存机制下具备经济可行性，混合工具使用场景的收益尤为突出；
  3. 解决LLM上下文短暂性问题无需等待模型层突破或无限扩大上下文窗口，在工具层即可实现有效优化；
  4. CMV为未来AIOS架构的设计提供了实证依据，证明持久化会话状态管理应成为智能体操作系统的一级设计目标。

关键问题

问题1：上下文内存虚拟化（CMV）与现有LLM上下文压缩/管理技术的核心区别是什么？

答案：核心区别体现在作用层级和核心目标两方面：1. 作用层级：现有压缩技术（LongLLMLingua、RECOMP等）聚焦模型/嵌入层，修改上下文的表示形式；CMV作用于工具层，直接管理原始JSONL格式的对话日志，不改变上下文的表示。2. 核心目标：现有状态管理方案（RAG、MemGPT、记忆插件）要么不保留会话状态，要么仅保存摘要/支持单会话，丢失对话细节；CMV通过DAG状态模型实现会话状态的版本化、跨会话复用，同时通过结构无损修剪在保留用户/助手对话原文的前提下剥离冗余，兼顾状态复用与令牌精简，而现有方案无法同时实现这两点。

问题2：三阶段结构无损修剪算法的“结构无损”体现在哪里？为何要设计三阶段流程而非单阶段？

答案：1. “结构无损”的核心体现：完整保留所有用户消息、助手响应的原文，以及工具调用的元数据，仅剥离原始工具输出、Base64图片、元数据等机械冗余内容，同时通过处理孤儿工具结果保证API调用的结构正确性，不破坏LLM工具调用的schema规范。2. 三阶段设计的核心原因：为了低成本解决孤儿工具结果的核心难点，单阶段流程无法在过滤的同时完成工具ID的收集与匹配；前两阶段为轻量的线性扫描（几乎无计算成本），分别实现压缩边界检测（避免重复处理已精简内容）和预边界工具ID收集（为识别孤儿工具结果做准备），第三阶段基于前两阶段的结果完成精准过滤，既保证了修剪效果，又避免了全量JSON解析的高额成本，同时确保API正确性。

问题3：从经济和实际使用角度，CMV对LLM API用户和订阅用户的核心价值分别是什么？不同类型的会话（混合工具型/会话型）使用CMV的收益差异为何显著？

答案：1. 不同用户的核心价值：① API按令牌计费用户：核心收益是量化的财务节省，修剪减少每轮令牌消耗，虽有缓存冷启动惩罚，但混合工具型会话10轮内即可盈亏平衡，且分支功能避免了上下文重建的高额令牌/时间成本；② 订阅用户：无直接财务收益，核心价值是优化上下文窗口使用，减少每轮令牌占用，延长有效会话长度，避免因大上下文快速耗尽速率限制。2. 会话类型的收益差异原因：CMV的修剪仅能剥离工具结果、Base64图片、元数据等机械冗余内容，混合工具型会话的工具结果字节占比≥15%，存在大量可修剪的冗余，因此平均令牌减少达39%，盈亏平衡轮数仅10轮；而会话型会话的工具使用少，冗余内容占比<15%，可修剪空间小，平均令牌减少仅17%，盈亏平衡轮数达40轮，收益相对有限。

创新点

  1. 借鉴操作系统虚拟内存的设计思路：首次将OS的虚拟内存理念应用于LLM上下文管理，抽象掉上下文窗口的物理令牌限制，实现上下文的“分页加载/保存”，解耦上下文构建成本与任务执行成本。
  2. DAG基的版本化状态模型：将会话历史建模为有向无环图（DAG），实现了Git式的LLM上下文版本管理，支持跨独立并行会话的上下文复用，打破了传统LLM会话线性、临时的局限。
  3. 三阶段结构无损修剪算法：在完整保留用户消息、助手响应、工具调用元数据原文的前提下，仅剥离机械冗余内容，既实现令牌压缩，又保证LLM工具调用的API正确性，区别于传统的语义压缩/摘要方式。
  4. 兼顾经济可行性的量化分析：针对LLM API的提示缓存机制，设计了完整的成本模型，验证了修剪技术在缓存冷启动惩罚下的经济可行性，明确了不同使用场景的收益边界。

研究方法和思路

本研究的核心方案为上下文内存虚拟化（CMV），由DAG状态模型和三阶段结构无损修剪算法两大核心模块构成，同时通过真实会话的实证分析验证方案的经济价值，整体方法拆解如下：

模块1：DAG-Based状态模型设计

1.1 形式定义

将会话历史建模为有向无环图(G=(V, E))：

  • 节点(v)：代表不可变快照，是某一时刻会话JSONL日志的完整副本，附带名称、时间戳、令牌数等元数据；
  • 有向边((v_i, v_j))：代表分支，从快照(v_i)派生的独立工作会话，最终生成新快照(v_j)，分支会继承原快照的所有上下文理解。
1.2 四大核心操作

为DAG模型设计了4个基础原语，实现完整的版本管理能力：

  1. Snapshot：将当前会话生成不可变快照，原会话不做任何修改；
  2. Branch：从指定快照创建新会话，默认启用修剪，可添加定向任务消息；
  3. Trim：一键完成“快照+分支+修剪”，直接生成精简后的新会话；
  4. Tree：可视化DAG结构，实现类似git log --graph的上下文谱系展示。

模块2：三阶段结构无损修剪算法

针对LLM会话中机械冗余占比高的特点（如原始工具输出、Base64图片、元数据等，非核心对话内容），设计流式三阶段算法，核心目标是只减冗余、不丢关键信息，算法输入为JSONL格式的会话日志，输出为修剪后的日志及量化指标，步骤如下：

  1. 第一阶段：压缩边界检测：扫描日志，定位最后一次原生压缩的边界，避免重复处理已精简的内容，仅解析匹配压缩标记的行，保证扫描低成本；
  2. 第二阶段：预边界工具ID收集：收集压缩边界前的所有工具使用ID，为识别“孤儿工具结果”做准备；
  3. 第三阶段：流式过滤与修剪：按规则处理日志，仅将有效内容写入输出，核心规则包括：跳过预压缩内容、移除元数据/Base64图片、对超阈值工具结果生成存根、剥离孤儿工具结果等。
关键难点解决：孤儿工具结果处理

LLM工具调用API有严格的schema要求，工具结果必须关联前置的工具调用。原生压缩可能导致“调用在边界前、结果在边界后”，直接使用会触发API错误。算法通过第二阶段收集前置工具ID，第三阶段剥离对应的孤儿结果，无需用户干预即可保证API正确性，这也是三阶段设计的核心原因。

模块3：经济评估方法

针对LLM API的提示缓存机制（修剪会修改提示前缀，触发缓存冷启动惩罚），设计量化成本模型验证方案的经济可行性：

  1. 设定成本公式：分别计算稳态每轮成本、冷启动成本、缓存惩罚、每轮节省，并推导盈亏平衡轮数；
  2. 实验数据：选取76个真实的Claude Code编码会话（排除短会话/子代理会话），按工具结果占比分为**混合工具型（≥15%）和会话型（<15%）**两类；
  3. 假设条件：稳态缓存命中率90%，采用Claude Opus 4.6的定价标准，盈亏平衡轮数上限60轮；
  4. 指标量化：统计令牌压缩率、缓存惩罚金额、盈亏平衡轮数等核心指标，分析不同场景的收益差异。

主要成果和贡献

本研究通过CMV方案，从技术实现和实际价值两方面为LLM上下文管理领域带来了实质性突破，核心成果和贡献可分为技术、经济、应用三层，同时量化验证了方案的有效性，具体如下：

一、核心量化成果（基于76个真实编码会话）

评估维度整体结果混合工具型会话（12个）会话型会话（64个）
平均令牌压缩率20%39%17%
峰值令牌压缩率86%--
平均盈亏平衡轮数35轮10轮40轮
平均上下文令牌数84k97k82k
令牌压缩>30%的盈亏平衡15轮内--

二、技术层面贡献

  1. 提出了首个工具层的LLM上下文虚拟化框架：区别于模型层的压缩技术，直接管理原始对话日志，与现有压缩方案互补，可适配所有支持工具调用、存储会话日志的LLM智能体；
  2. 实现了版本化的上下文复用：DAG模型让LLM上下文具备“保存、分支、复用”能力，一个根快照可派生多个并行会话，彻底解决了“每次会话从头重建上下文”的问题；
  3. 设计了结构无损的令牌压缩算法：在保证对话完整性和API正确性的前提下实现令牌精简，避免了传统语义压缩/摘要导致的信息丢失，压缩规则可配置（存根阈值默认500字符）。

三、经济与应用层面价值

  1. 对按令牌计费用户：混合工具使用（如代码编写、数据分析）的核心场景中，10轮内即可收回缓存冷启动惩罚，后续持续享受令牌成本节省，平均减少20%的每轮令牌消耗；
  2. 对订阅制用户：无直接财务成本，但大幅延长有效会话长度，减少每轮令牌占用，避免因大上下文快速耗尽平台速率限制；
  3. 规避隐性的上下文重建成本：平均84k令牌的上下文，从头重建需10-20轮交互、15-30分钟，且成本呈二次增长；而从CMV快照分支仅需一次提示加载，成本仅$0.53（冷启动）/$0.04（缓存命中）；
  4. 提供可落地的参考实现：开源了Claude Code的CMV实现代码，开发者可直接复用，且DAG模型和修剪算法与智能体无关，具备极强的通用性。

四、领域研究贡献

为未来LLM智能体操作系统（AIOS）的设计提供了实证依据和参考方案：指出当前AIOS框架中缺失“持久化、版本化的会话状态管理”这一核心抽象，CMV的DAG模型和修剪算法可作为AIOS持久化上下文子系统的参考实现，推动LLM智能体从“单任务会话”向“多任务持久化工作流”演进。

总结

本研究针对LLM长会话中上下文窗口受限、状态易丢失、冗余内容占比高的核心问题，提出了上下文内存虚拟化（CMV）系统，该系统借鉴操作系统虚拟内存理念，通过DAG基的版本化状态模型实现了Git式的上下文复用，让单个上下文构建会话可作为多个并行工作流的持久化根节点；搭配三阶段结构无损修剪算法，在完整保留用户与助手核心对话、保证API正确性的前提下，剥离机械冗余内容，实现平均20%、最高86%的令牌压缩。

通过76个真实编码会话的单用户案例评估，验证了CMV在提示缓存机制下的经济可行性，其中混合工具使用的核心场景平均压缩39%，10轮内即可实现成本盈亏平衡。同时，CMV彻底规避了上下文重建的高额隐性成本，且方案与LLM智能体无关，具备极强的通用性。该研究证明，无需等待模型层的技术突破或无限扩大上下文窗口，在工具层即可有效解决LLM的上下文短暂性问题，为LLM智能体的长时、复杂任务落地提供了关键的上下文管理方案，也为未来AIOS的设计补充了核心的状态管理抽象。

Read more

OpenClaw之Memory配置成本地模式，Ubuntu+CUDA+cuDNN+llama.cpp

文章目录 * 背景：Memory不生效的问题 * OpenClaw的Memory配置 * Ubuntu24.04安装CUDA和cuDNN * 编译llama.cpp * 验证方案1： * 验证方案2：下载并运行Llama-2 7B模型 * 安装node-llama-cpp * 验证Memory * sqlite-vec unavailable * 踩过的坑 * 安装node-llama-cpp的一些提示 * 安装node-llama-cpp的前置条件 * Using `node-llama-cpp` With Vulkan 承接上文：Windows11基于WSL2首次运行Openclaw，并对接飞书应用，我已经在电脑上安装了OpenClaw，接下来解决Memory问题。走了很多弯路，下面主要讲我总结的正确的安装过程。 总结来说：针对Memory不生效的问题，又不想用OpenAI或Gemini，或者只想单纯的节省token，可以按照如下的方式，设置为local模式： * 修改openclaw.json配置 * 安装CUDA和cu
【低代码+AI编程】GitHub Copilot各个模型区别，实现高效编程

【低代码+AI编程】GitHub Copilot各个模型区别，实现高效编程

Copilot AI模型对比说明 模型分类 🏆 高级模型 (需额外付费) 模型名称相对成本特点说明Claude Haiku 4.50.33x性价比最高，速度快，成本低Claude Sonnet 3.51.0x平衡性能与成本的主力模型Claude Sonnet 41.0x升级版本，能力更强Claude Sonnet 4.51.0x最新版本，综合表现优秀GPT-51.0x最强大旗舰，复杂推理能力顶尖Gemini 2.5 Pro1.0x超长上下文，适合处理大量文本 📊 标准模型 (包含在基础套餐内) 模型名称成本特点说明GPT-4.1免费GPT-4优化版本GPT-4o免费多模态专家，视觉语音交互强GPT-5 mini免费GPT-5轻量版，速度快Grok Code Fast 1免费编程专用，代码生成优化 选择指南 根据需求推荐： 🚀 日常使用 * 推荐：GPT-4o 或 GPT-5

OpenAI Codex vs GitHub Copilot：哪个更适合你的开发需求？2025年深度对比

OpenAI Codex 与 GitHub Copilot：2025年开发者如何做出关键选择？ 在2025年的技术栈里，一个高效的AI编程伙伴不再是锦上添花，而是决定项目节奏与质量的核心生产力。面对市场上功能各异的选择，许多开发者，尤其是那些管理着复杂项目或带领团队的技术决策者，常常陷入一个两难的境地：是选择功能全面、能独立处理任务的“AI工程师”，还是选择无缝集成、提供实时灵感的“智能副驾驶”？这不仅仅是工具的选择，更是关于工作流重塑、团队协作模式乃至项目架构未来的战略决策。对于个人开发者、初创团队乃至大型企业的技术负责人而言，理解这两款主流工具——OpenAI Codex与GitHub Copilot——在本质定位、适用场景与成本效益上的深层差异，是避免资源错配、最大化技术投资回报的第一步。本文将深入它们的核心，帮助你根据真实的开发需求，找到那个最契合的“数字搭档”。 1. 核心理念与定位：从“辅助”到“执行”的范式差异 理解Codex和Copilot，首先要跳出“它们都是写代码的AI”这个笼统印象。它们的底层设计哲学决定了完全不同的应用边界。 OpenAI Codex
DeepSeek、Kimi、笔灵谁最好用？5款网文作者亲测的AI写作神器横评

DeepSeek、Kimi、笔灵谁最好用？5款网文作者亲测的AI写作神器横评

作为在网文圈一路摸爬滚打过来的我，面对“AI写小说”这个现象，心情其实挺复杂的。 这有点像工业革命时期的纺织工人看着蒸汽机——恐惧是真的，但效率的碾压也是真的。 不是纯用AI生成，而是用AI搭建了极其高效的“外挂工作流”。 有人用它日更两万字，有人用它把废稿救活。 当然，不是纯用AI生成，而是用AI搭建了极其高效的“外挂工作流”。为了不让大家白给工具交学费，我实测了市面上十几款软件，挑出了这5款真正能嵌入小说创作流的“神器”。 1️⃣ DeepSeek：除了逻辑强，它还很懂中式网文 适合人群： 玄幻、仙侠、古言作者，以及看重文章设定和逻辑的人。 直通车：https://www.deepseek.com/ 很多人吹DeepSeek的逻辑和代码能力，但在写小说上，它有一个小众的用法是做体系。 👉 独家用法： 你可以用它来写“设定集”和“功法体系”。你可以参考图片中我的指令来和它对话： 它吐出来的东西，特有那味，既有传统网文的爽感，又有你指令里要的感觉。所以虽然它的逻辑能力也在线，但你也不要忽略了它在描写和设定生成上的亮点！