Write-Claw:一个面向长篇 AI 写作的 Claw-Native Runtime Workspace

Write-Claw:一个面向长篇 AI 写作的 Claw-Native Runtime Workspace

GitHub网站:https://github.com/HITSZ-DS/Write-Claw.git(如果可以的话可以给个star吗,刚刚启动)

work模式

一、项目定位

Write-Claw 不是一个普通的 AI 写作网页,也不是把大模型封装成聊天窗口的小说生成器。

如果只用一句话来定义它,我会这样写:

Write-Claw 是一个面向长篇 AI 写作的 Claw-native runtime workspace,它将创意、规划、执行、记忆、checkpoint、修订与可观测轨迹统一组织进一个可持续运行、可被宿主调度、可被作者接管的写作运行时。

这个定义里最重要的不是 “writing workspace”,而是 Claw-native。

因为 Write-Claw 的核心价值,不只是“界面更完整”,而是它的整体组织方式,本身就是典型的Claw模式。

 二、什么叫做 Write-Claw 的 Claw 模式

我这里说的 `Claw`,不是简单的命名风格,也不是把 agent 换个说法。

Write-Claw` 之所以要强调自己是 Claw-native,是因为它符合一种典型的 Claw-style runtime 设计逻辑:

- 它不是单轮 prompt 调用,而是持续运行的 agentic loop。

- 它不是把所有能力折叠进聊天回复,而是把能力显式拆成工作区动作、运行时状态和可调用单元。

- 它不是一次性生成后结束,而是支持规划、暂停、继续、修订、同步和 checkpoint。

- 它不是黑盒返回结果,而是把轨迹、状态、能力栈、记忆面板、会话信息展示给用户。

- 它不是“用户输入一句,系统吐一段”,而是“用户与系统共同维护一个持续运行的写作空间”。

所以,Write-Claw 所体现的不是普通“AI 写作工具模式”,而是更接近下面这种模式:

作者进入的是一个写作 runtime,而不是一个文本生成输入框。

 三、为什么它必须被描述成 Claw,而不是普通写作工具

如果只是普通写作工具,它的描述通常会是:

- 输入故事设定

- 点击生成

- 得到文本结果

而 `Write-Claw` 想表达的逻辑完全不同:

- 用户先进入一个长期运行的创作工作台;

- 系统在这个工作台中持续进行创意收敛、章节推进、状态维护与记忆累积;

- 用户不是等待系统“吐结果”,而是在运行过程中不断观察、打断、修正、确认与接管;

- 故事不是单次产物,而是一个不断被推进、被修订、被校准的长期项目。

这正是 `Claw` 模式和普通生成工具的本质区别:

Claw 关注的不是一次调用,而是持续运行中的任务状态、动作轨迹与人机协作。

Write-Claw 把这种模式完整落到了长篇 AI 写作场景里。

四、Write-Claw 的核心理念

Write-Claw 的核心理念可以概括成一句话:

AI 写作不应只展示结果,更应该展示过程。

大多数写作系统只把最终文本展示出来,而 Write-Claw 更关注:

- 系统当前在做什么;

- 它为什么这样做;

- 它下一步准备做什么;

- 当前章节处于什么状态;

- 角色和世界设定是否被更新;

- 记忆是否发生漂移;

- 作者能否在过程中接管与修改。

换句话说,Write-Claw 想把 AI 写作从“文本生成结果”升级成“可见的创作运行过程”。

 五、Write-Claw 的一句话心智模型

如果你要对外介绍它,我建议这样说:

Write-Claw 不是 prompt in, text out 的写作器,而是一个 Claw-native 的长篇写作运行时。

这句话里面有三个关键信息:

- 它不是一次性生成器;

- 它是围绕长篇写作设计的;

- 它是以 Claw 方式组织整个系统的。

六、Write-Claw 的系统形态:不是页面,而是运行时工作台

`Write-Claw` 最重要的设计,不是“页面做得多”,而是它把多个原本割裂的创作环节统一成了一个运行时工作台。

在这个工作台里,作者面对的不是一个聊天框,而是一个完整的创作空间,其中包括:

- Runtime Loop

- Writing Console

- Memory Surface

- Workspace Tools

- Checkpoint Flow

- Session Center

- Status and Trace

- Capability Control

这意味着 Write-Claw 实际上在做两件事:

1. 把长篇 AI 创作过程结构化。

2. 把这种结构化过程前台化。

前者让系统更稳定,后者让用户更可控。

它的目标不是替作者一次性写完,而是把 AI 写作组织成一个可运行、可观察、可打断、可修订、可持续协作的创作过程。

Write-Claw的核心价值不在于“它能生成小说”,而在于它把长篇 AI 写作真正做成了一个 `Claw-native runtime workspace`。在这个系统中,创意不再是一次性输入,章节不再只是静态结果,记忆不再是模型内部缓存,用户也不再是等待输出的旁观者。相反,创作被组织成一个持续运行的 agentic loop:可规划、可追踪、可检查、可中断、可修订、可接管。也正因为如此,Write-Claw 不是一个普通写作产品,而是一种更接近未来创作基础设施的写作运行时形态。

Write-Claw 是一个面向长篇 AI 写作的 Claw-native runtime workspace。它不再把写作理解为一次性 prompt 调用,而是将创意、规划、章节推进、记忆维护、checkpoint 与执行轨迹统一组织进一个持续运行、可视、可控、可接管的创作 runtime 中,使作者始终处于 loop 内部,而不是站在结果之外等待输出。

Read more

MCP 是什么?为什么它是 AI 落地的 “超级翻译官”?从作用到原理一文吃透

MCP 是什么?为什么它是 AI 落地的 “超级翻译官”?从作用到原理一文吃透

1、什么是MCP? 模型上下文协议(Model Context Protocol,MCP)作为一种开放标准,旨在简化 AI助手与外部数据源、工具及系统的集成流程。该协议由Anthropic公司率先开发,以应对为AI模型提供实时、相关且结构化信息的挑战,同时确保安全性、隐私保护以及模块化设计。 MCP的目标在于成为“ AI集成领域的USB-C”,支持AI应用程序与多种数据存储库、工具或API之间实现一对多的高效连接。通过标准化AI助手查询及与外部资源交互的方式,MCP显著降低了多个定制集成所带来的复杂性。 1.1 MCP 的类比解释 试想一下,你拥有一个通用遥控器,能够操控所有设备——电视机、扬声器、灯光乃至咖啡机——而无需为每台设备配备专用遥控器。同理,我们可以将AI模型(如ChatGPT、Claude或LLaMA等)视作需要从不同渠道(例如数据库、API或公司文档)获取信息或执行任务的智能助手。问题在于,若缺乏一种通用的通信手段,每个AI模型都将不得不为接入每一个数据源而定制专门的集成方案——这无异于为每台设备配备独特的遥控器,显然会增加不必要的复杂性和工作量。 MCP

AI提示词宝典:100+常用提示词,覆盖20+场景,程序员和小白必备,让AI工作更高效!

AI提示词宝典:100+常用提示词,覆盖20+场景,程序员和小白必备,让AI工作更高效!

你是不是也有过这样的经历:打开 AI 工具(ChatGPT、文心一言、豆包等),盯着输入框半天,却只打出 “帮我写点东西”“给点建议”,最后得到的回复要么空泛、要么偏离需求? 其实,AI 的 “智商” 很大程度上取决于你的 “提问方式”——提示词(Prompt)才是解锁 AI 能力的钥匙。好的提示词能让 AI 精准输出你要的内容,反之则会浪费时间。 今天整理了一份「AI 常用提示词大全」,覆盖工作、学习、生活 20 + 高频场景,每类场景都附具体示例。无论是写文案、做方案,还是学技能、处理琐事,直接复制修改就能用,小白也能快速上手! 一、工作效率类:让 AI 成为你的 “隐形同事” 打工人最需要的就是用

Windows 使用 Codex 一直“正在思考”?一招解决 AI 工具代理问题(附一键切换脚本)

📚 目录 一、问题背景:Codex 一直“正在思考”却没有回答 二、第一步:查看本机代理端口 三、第二步:测试代理是否可用 四、第三步:给 Codex App 配置代理 五、让 Codex 代理配置生效 六、验证代理是否生效 七、如何取消代理配置 八、代理配置是否会影响国内软件 九、开发者推荐的代理配置方式 十、完整流程总结 一、问题背景 最近在 Windows 上使用 Codex 时遇到了一个很奇怪的问题: 输入问题后,界面一直显示: 正在思考 但是 没有任何回答。 最开始以为是: * Codex Bug * API Key

开源神器Spec-Kit和OpenSpec:AI开发工作流的双剑合璧指南

开源神器Spec-Kit和OpenSpec:AI开发工作流的双剑合璧指南

文章概要 作为一名在AI开发工具链里摸爬滚打多年的老司机,我曾被Spec-Kit的800行文档吓退,也被OpenSpec的极简主义惊艳。直到发现它们根本不是竞争对手,而是互补神器!本文将用实战经验告诉你:Spec-Kit如何像严谨的架构师构建知识体系,OpenSpec怎样如敏捷的极客快速落地,以及最关键的——如何让它们像咖啡与牛奶般完美融合。 还记得第一次看到Spec-Kit生成的800行文档时,我差点把咖啡喷在显示器上——这哪是开发工具,分明是AI界的百科全书!而当我遇见OpenSpec,它用250行代码就完成了同样任务,那一刻我仿佛看到了极简主义大师在向我微笑。但真正的惊喜是:它们根本不是对手,而是AI开发界的咖啡与牛奶! Spec-Kit就像那个永远穿着西装三件套的严谨架构师,它带着你从宪法制定开始,一步步分解任务,生成详尽到令人发指的用户故事和测试计划。800行的文档不是负担,而是一座精心构建的知识宝库。每个需求都要经过八步验证,就像瑞士军刀的每个小工具都各司其职——从/specify到/archive,它确保你永远不会在深夜三点因为"忘记考虑边界条件"而崩溃。 “工具没