即日起， Nebulaw Ver0.2 正式开启内测。

这个版本中，我们将工作的重心从「更快生成」推进到「更可控的系统」，让法律文档在多轮改动与协作中，依然保持结构清晰、逻辑一致、引用可追溯。

您可进入

https://nebulaw.com.cn 抢先体验，内测期间，我们将提供以下福利：

01      

从 0.1 到 0.2：我们学到的关键事实

2025年11月17日，我们发布了 Nebulaw X Ver0.1，并将其定位为法律AI助理，覆盖文书审查、修改与风险提示等高频需求，希望将用户 80% 的重复性工作交由系统处理。

Ver0.1 采用的是经典的「输入 - 输出式交互」，由用户输入提示词，系统返回处理结果。

在当时，这一形态是务实且有效的。

随着一些知名海外法律插件陆续发布，其交互路径与输出形态与我们的设计思路高度一致。

这也从侧面印证了：在法律场景中，通过对话方式提升单次处理效率已经成为行业共识。

但在与用户沟通的过程中，我们开始思考一个更基础的问题：

Copilot 式的交互，是否已经是人类与 AI 协作的最优形态？

如果 AI 的价值仅停留在「生成更快」，它能否真正进入法律工作的核心流程？

1.1 | 上下文的关键限制

带着这个问题，我们将目光投向在 AI 时代发展最为迅速的 AI Coding 领域，并从中获得重要启发——

代码天然具备结构属性，再结合工程化的编辑环境、依赖关系管理与持续修改支持，使模型不只是生成代码片段，而是参与到完整的工作流程中。

当 AI 被放入一个能够承载上下文、支持长期修改与依赖关系的工作环境中，其能力才更容易被释放。

这一观察也促使我们重新审视法律工作的「上下文」究竟是什么。

结合过往的工作经验，我们意识到这些上下文往往分散在多个层面：

这些信息不会完整地呈现在成稿中，却真实地影响着每一次判断与修改。

问题也正出现在这里。

当法律工作的关键上下文无法被结构化地保存和持续维护时，AI 即便能够生成高质量文本，也只能参与到末端的结果生成，无法介入真实的工作过程。

1.2 | 传统编辑器的边界

以 Word 为代表的传统编辑器本质上是为人工编辑设计的：

它的文本结构由人理解，逻辑关系由人维护，重要语境更多出现在线下讨论和个人记忆中。

在过去，这并不是问题。

但当我们尝试将 AI 引入到更核心的法律工作流中时，这种工具形态的边界逐渐清晰。

传统编辑器的设计目标，并不包含对结构关系、依赖变化和长期一致性的系统性管理，它更适合作为结果载体，而非持续运行的工作环境。

从这个意义上看，单纯基于 Word 的工作方式，已经很难完全适配 AI 时代对协作方式和验证机制的要求。

同时，传统文字编辑环境对深层结构能力的开放程度有限。

对第三方系统而言，结构可视化、关系校验与版本回溯往往只能停留在插件层面，难以形成稳定、可持续的系统能力。

基于这些判断，在 Ver0.2 中，我们在保留对话能力的基础上，将产品形态调整为一种更接近 IDE 思路的法律工作环境：强调结构、验证与协作，不再仅仅围绕文本生成展开。

02      

为什么法律行业，需要集成式工作环境

法律文本不是松散的自然语言结合，更接近一种结构化记录。

术语定义、条款层级与交叉引用共同构成一套明确的约束网络：内容之间存在前提条件、文本之间存在引用指向、前后表述需要保持一致。

因此，文档中的某一处改动很可能影响其他位置的内容有效性——

从语法上看，内容是完整的；但从逻辑而言，其前提条件可能已经发生变化，而现有工具无法提示这一变化。

以并购交易为例，一份200页的并购 SPA 往往由多名律师并行修改：如果 A 律师调整了「违约责任」的定义，B 律师在文档后续对该条款的引用可能立即失效。这种不一致性很难在第一时间被发现。

在实践中，法律工作的效率瓶颈并非生成，更多出现在校验、追溯与协同一致性维护。当文档经历多轮修改后，如果只靠人工逐条回溯，整体效率与交付可靠性的提升非常有限。

因此我们判断：法律行业需要的不是更多的单点工具，而是一种类似「数据库约束」的机制——持续识别关键结构，并在修改发生时提示可能的影响范围。

03      

我们想做什么

要将上述能力真正嵌入法律行业工作流，Ver0.2 的升级路径不是新增功能按钮，也不是作为某个编辑器的插件存在，而是从编辑环境本身开始重构。

主流文字编辑器更擅长排版与内容呈现，其内部结构并不是围绕「关系查询」和「约束管理」设计的。对外扩展能力也主要集中在插件层，难以持续识别文本内部变化并提供系统级处理。

这也是不少用户在实际工作中遇到的难题：

即使引入了不同工具，文档修改后，仍需要投入大量人工精力进行复核，例如确认条款编号是否对应、定义是否被覆盖、同一对象在不同位置是否出现不一致表述等。

所以，在 Ver0.2 中，我们将编辑环境视作系统能力的一部分来设计。

Nebulaw 不止承载基本的写作和改写，更能够识别文本结构，在关键变更发生时提示其潜在影响，并辅助完成一致性检查。

作为内测版本，我们也愿意坦诚说明：Nebulaw现在还不是一个足够成熟的产品，部分细节仍在优化中，但已经能够覆盖法律行业的核心文本工作需求。

04      

产品结构与核心能力

在 Ver0.2 中，我们并未简单地做一个新的编辑器，而是将编辑能力视为整个系统的运行界面。

就像 IDE 不只是代码输入框，而是承载结构理解、依赖分析与验证反馈的工作环境一样，Nebulaw 的编辑区承担的是系统能力的呈现与交互。

在这一设计理念下，Nebulaw 由三个核心区域构成：

• 资源区：集中管理输入文档、条款库和第三方信源
• 工作区：实时编辑、逻辑一致性检测与协同作业
• 服务区：提供推理、检索核查、流程驱动等能力模块

通过资源区与服务区对上下文的管理，并结合底层的动态验证机制，Nebulaw 在不改变用户操作习惯的前提下，系统性提升了文档背后的结构可靠性与协同效率。

05      

核心场景

基于上述设计理念，Nebulaw ver0.2 当前已经覆盖多数核心场景，包括：

• 文档逻辑推理与冲突检查
• 文书生成与文本改写
• 信源检索与内容核查
• 风险偏好与工作习惯沉淀

登录后，用户可以上传待处理文档，在服务区提出调整与核查需求。系统会在编辑过程中自动识别文档结构与关键引用关系，并输出可继续编辑的 DOCX 文档，尽量保留原文格式，减少二次排版成本。

随着使用积累，Nebulaw 会逐步理解用户的处理习惯与结果偏好，将其沉淀为可复用的工作方式。用户在新项目中无需反复补充上下文，减少重复核对与返工。

Nebulaw 提供的并非彼此独立的功能模块，而是一组持续运行的系统能力：让结构关系长期可维护，让修改结果保持可验证、可追溯、可延续。

06      

OnGoing

在早期用户的实际使用过程中，我们收到关于文本预测、勾稽关系可视化、交叉引用核查等方向的反馈。相关能力已经进入我们的产品演进路线，并将随着版本迭代逐步向不同层级用户开放。

我们的更新以真实使用场景为驱动，确保每一次升级都聚焦于改善工作体验，而非单纯的功能叠加。

6.1 | 反馈与支持

我们非常期待你的意见和反馈，它将直接影响我们的迭代优先级。

你可以在产品内通过【头像 → 意见反馈】提交；

或发送邮件至 membership@nebulaw.ai

为保障信息安全，请仅通过官方渠道提交反馈，留意回信邮箱，避免向非官方邮箱提供任何个人信息。

我们也期待在正式版本发布后，继续收到来自你的建议与意见。