NextClaw，你的长期个人智能搭档。
NextClaw 以做好用户的长期搭档为根本使命，成为一个主动参与、持续自我改进的长期智能伙伴。
使命回答“为什么存在”：做好用户的搭档是唯一的根本职责。愿景回答“要成为怎样的产品”：理解用户的整体上下文，能够回应请求，也能够主动参与，并持续改进自己以更好地履行这个职责。
这里的职责不随单个任务结束而结束，也不以用户当前下达任务为存在前提。用户的长中短期目标、规划、处境、状态和眼前任务，都属于搭档需要理解和关注的范围。
本文记录产品方向与决策依据，不代表这些能力已经全部实现，也不直接承诺 1.0 的功能范围或发布日期。
NextClaw 关注的是用户这个人，以及持续展开的生活与工作。它需要把眼前的请求放回用户的目标、计划和当前处境中理解，既能完成具体工作，也能参与讨论、规划、跟进与调整。
理想状态下，用户可以请求它完成一件事，也可以与它讨论尚未明确的问题。没有新指令时，它仍能依据已有理解、相关变化和授权，判断是否需要询问、提醒、建议或行动，并判断什么时候应保持安静。
主动参与也包括主动思考：结合用户整体处境分析问题、发现取舍、梳理或提出规划、告知值得知道的信息，并主动发起一段有明确来由的讨论。这不要求先出现新的外部事件或待执行任务；对已有信息形成新的有用认识，同样可以成为参与的理由。帮助用户想清楚一件事、知晓重要信息或进行有价值的交流，本身就是结果，不必最终转化为工具调用和任务执行。
长期搭档关系可以有朋友般的理解、交流与支持，但不能缩减为情感聊天，也不能缩减为任务执行。它的判断和行动应服务用户，并尊重用户对目标、节奏和授权的决定。
NextClaw 应能够主动从经验、执行结果与用户反馈中发现不足、修正理解、改进方法。这种改进不以用户同时成长为前提，也不是为了形成服务自身利益的独立目标；它始终服务于“更好地做好用户的搭档”。
“与用户共同成长”不作为核心定义。用户的目标与处境可能变化，NextClaw 的根本使命保持不变。
个人操作层仍是重要的产品形态与能力方向：通过统一入口连接软件、互联网、系统、服务与云计算，让搭档能采取实际行动。它从上位目标调整为支撑使命的形态，建设价值由它是否帮助 NextClaw 做好用户的搭档来判断。
成为默认入口、增加工具数量或扩大生态规模，都不能单独证明使命得到了更好的履行。原有技术积累继续复用，后续投入围绕长期伙伴关系重新排序。
根本使命是做好用户的长期搭档；主动参与、长期连续性、理解用户整体上下文和持续自我改进，是这一伙伴关系的核心特征；原有能力主线为它们提供支撑。
| 层级 | 内容 | 决策作用 |
|---|---|---|
| 使命 | 做好用户的长期搭档 | 判断为什么建设、最终服务谁 |
| 产品特征 | 主动参与、长期连续性、整体上下文、自我改进 | 判断搭档应如何理解、参与和改善 |
| 支撑形态与能力 | 个人操作层、统一入口、能力编排、自感知与自治、扩展生态、数字基础设施、开箱即用 | 让搭档可以实际工作并被长期依赖 |
| 阶段目标 | 1.0 的范围、验收和后续 roadmap | 按使命推导，另行定义，不由能力清单直接代替 |
“理解整体上下文”不等于无差别收集用户数据；“主动”不等于增加消息频率或自行扩大权限；“长期”不等于仅保存聊天记录；“自我改进”不等于另立自我发展目标。
统一入口帮助用户与搭档保持连续协作，并降低使用不同软件与服务的成本。
- 用户进入数字世界时，应该越来越倾向于先打开 NextClaw
- 软件、服务、渠道、设备与云资源，应该尽量通过 NextClaw 被统一接入与管理
- 它应该逐步成为能承接工作流、沟通流和信息流的默认工作台
- 统一入口不等于只有图形界面；适合结构化操作的本地 NextClaw 实例能力应尽可能通过
nextclawCLI 暴露，让用户、开发者、脚本、CI 和 Agent 都能调用同一套产品能力。独立托管服务有自己的管理入口，底层能力可以复用 NextClaw 的公共合同
入口是否有价值，取决于它是否改善了用户与搭档的协作，而非用户是否把所有操作都留在 NextClaw。
NextClaw 的价值不在于把所有功能都自己重做一遍，而在于更好地连接、调度、组合现有的软件、系统、服务与算力。
- 把用户意图翻译成可执行流程
- 调用工具、连接服务、组织多步任务
- 在多模型、多渠道、多插件、多运行环境之间收敛成统一体验
能力编排让搭档能够执行实际工作。具体任务是履行长期职责的一种方式，规划、理解用户和跟进整体进展同样重要。
自感知与自治让搭档知道自身状态、理解所处情境，并能在授权范围内管理自身运行。主动参与还需要结合用户的目标与状态作判断，不能只由系统自管理能力代替。
NextClaw 不能只是一个收到输入再吐出回答的壳。它应该逐步具备产品意义上的自感知能力，也就是：
- 知道自己是谁：身份、版本、规则、能力边界、工具边界是什么
- 知道自己当前的系统状态：完整配置、运行状态、健康度、服务连接状态是什么
- 知道自己在为谁工作：用户是谁、偏好与习惯是什么、长中短期目标和计划是什么、当前处境和状态有什么变化
- 知道自己处在什么场景：当前会话、项目、渠道、设备、运行环境是什么
- 知道自己做过什么：刚执行了哪些动作、读过哪些上下文、调用过哪些资源
- 知道结果如何：哪些任务成功了、失败了、卡住了、偏离了
- 知道哪里做错了：问题来自模型判断、工具调用、上下文缺失，还是执行链路本身
这些认识应当能够持续更新、被用户纠正，并服务于后续判断。它们支撑跨会话、跨任务的理解，不把用户整体上下文限制在当前会话中。
在具备足够自感知之后，NextClaw 还应该逐步具备自治能力：
- 能通过工具执行系统中的关键管理动作，例如修改配置、启停渠道、管理定时任务、安装或卸载扩展、触发诊断与恢复
- 能在聊天、UI 与系统控制面之间形成一等入口，而不是让“能说话”和“能管理系统”长期割裂
- 对高风险或不可逆操作保留明确确认机制，确保安全可控
目标不是“神化 agent”，而是让用户通过自然语言与统一控制面，就能理解和掌控 NextClaw 自身。
自进化在这里指持续自我改进，其唯一目的就是更好地做好用户的搭档。它应该具备可治理、可积累、可复用的改进能力，也就是：
- 能从错误中学习，而不是反复犯同样的问题
- 能从用户反馈、任务结果、失败回放里做反思和修正
- 能逐步沉淀更好的执行策略、工具使用纪律、上下文组织方式和记忆结构
- 能把一次次经验沉淀为更长期的用户偏好、项目知识、procedural memory 与 skill memory
- 能主动识别自身不足，改善对用户的理解、参与时机和工作方法，而不只依赖用户逐次指出错误
- 改进效果以是否更好地服务用户来判断，不以自主行动次数、记忆数量或自身规模增长来代替
这里说的不是不可控的自动自我改写。我们要的是可观察、可约束、可回退、可治理的自我改进能力。
稳定内核与扩展生态，让搭档能够按用户需要获得能力，控制主产品的复杂度。
- 核心运行时、插件 SDK、渠道协议需要逐步收敛并保持稳定边界
- 复杂能力的长期扩张，应更多通过 plugin、skill、marketplace 来完成
- 用户与开发者应该能形成“使用 -> 开发 -> 分享 -> 发现”的闭环
这条主线的意义，是让 NextClaw 追求“能力可无限扩展”，但又不把所有复杂度都压回主产品本体。
数字世界基础设施让搭档能够访问所需资源、理解相关信息并交付实际结果，主要体现在三个维度：
- 理解和利用操作系统、文件系统、本地服务、硬件资源等宿主环境
- 通过工具调用完成文件管理、进程管理、系统监控、本地应用联动等操作
- 让 AI 成为用户操控本地环境的智能中枢
- 便捷接入搜索、抓取、API 调用、信息聚合等互联网数据源
- 调度和利用云存储、云函数、远程服务等云资源
- 让用户通过自然语言即可触达互联网世界的数据与算力
- 管理用户的本地数据、配置、笔记与个人知识
- 连接散落在邮件、日历、社交、笔记、云盘等各类系统中的数据
- 在尊重隐私与安全的前提下，提供统一的数据视图与操作能力
长期搭档关系需要容易开始，也需要容易维持。开箱即用帮助新用户理解能交给搭档什么、如何提供必要背景，以及如何管理授权和协作方式。
- 首次启动就应让用户知道它能做什么
- 关键场景应支持一键配置与启动，而不是先学习大段配置
- 从了解、安装到第一次真正跑通，应尽可能短、尽可能顺滑
用户应能把精力放在自己的事情上，减少为维持搭档可用而承担的配置和维护负担。
我们希望用户能够长期感受到：
- 它理解我在意的事情，也愿意修正对我的理解
- 它能把眼前的事情与我的目标、计划和处境联系起来
- 它会在合适的时候主动参与，也知道什么时候不打扰
- 它能完成实际工作，让我了解进展并掌握决定权
- 它会从结果与反馈中改进，减少重复错误，越来越胜任搭档的角色
这些是产品方向，具体的可观察验收与实现阶段由 roadmap 和版本定义承接。
这份愿景不是说：
- 要把所有能力都硬塞进一个单体产品
- 要把一切都自己重做一遍
- 要为了看起来全能而持续堆功能
- 要做一个只有聊天外壳、却不能真正调度世界的 AI
- 要把“自感知”写成玄学叙事，却没有真实系统能力支撑
- 要把“自进化”做成不可控的自动自我修改黑盒
- 要替用户设定人生目标，或用产品自己的判断覆盖用户的选择
- 要让自我改进成为服务自身利益的独立目的
- 要用频繁打扰、无限授权或无差别数据收集来证明主动性
每项能力都应能说明：它如何帮助 NextClaw 更好地做好用户的搭档。无法建立这个联系的功能、入口或基础设施投入，应降低优先级。
后续做产品、架构、交互、命名和路线判断时，默认都要回到下面几条原则：
- 使命优先 先说明改动如何帮助 NextClaw 做好用户的长期搭档，再选择入口、功能和技术路径；入口地位服从这个目标。
- 编排优先 优先连接、调度、组合现有软件、服务、系统与云资源，而不是无边界地把所有实现都内置进去。
- 整体上下文优先 同时理解眼前意图、长期目标、中短期计划和当前状态；具体任务放回用户处境中判断，不能将当前任务视为全部职责。
- 自感知优先 系统应该越来越清楚“自己是谁、在什么场景、做了什么、结果如何、错在哪里”，而不是每轮都靠临时 prompt 硬撑连续性。
- 自治优先 用户应该越来越能通过自然语言和统一控制面理解并掌控系统，而不是长期依赖分裂的 UI/CLI/手工配置路径。
- 自进化优先 系统应该越来越能从错误、反馈和长期使用中学习，把经验沉淀成更稳定的能力，而不是把每次失败都当成一次性事故。
- 生态优先 长期扩展能力应优先通过稳定内核和扩展生态承接，而不是让主产品持续膨胀。
- 统一体验优先 不同模型、渠道、插件、服务和运行环境，最终都应尽可能收敛到一致、可理解、可管理的体验。
- 主动参与与长期连续性 根据用户需要、上下文变化和授权判断是否参与；关注、跟进和改进可以跨越单个任务，保持安静也可以是正确选择。
- 可编程入口优先
新增或改造本地 NextClaw 实例的用户可用能力时，默认评估并尽可能提供
nextclawCLI 入口；纯视觉或直接操控等不适合命令行的体验可以例外。独立托管服务的远程运维与验收入口由服务自身提供。CLI 应复用对应 owner 的公共 contract，不复制产品语义。
配置是产品的内部实现。用户与 AI 应通过“添加供应商、选择模型、测试连接、启停渠道”等明确的产品操作管理系统，无需先理解配置文件位置、内部字段路径和原始 JSON 结构。系统仍应提供充分的状态查询和诊断能力，让 AI 能理解当前设置及其生效情况；配置内部化不意味着隐藏产品状态。
配置相关能力优先建设面向业务对象与意图的 nextclaw CLI，并与 UI 和工具复用同一业务 owner 的公共 contract，由系统负责校验、关联状态维护、持久化和生效处理。通用 config get/set/unset 只是过渡入口，不能以“已经能通过命令行写任意字段”作为 CLI 完备的依据。
采用渐进改造：已有直接配置工具暂时保留，但不作为 AI 的推荐操作路径；已有对象级 CLI 覆盖的任务优先走 CLI，尚未覆盖的能力保留必要入口并作为待补缺口。后续开发和改造同步收敛系统提示、自管理指南与示例，避免继续引导 AI 直接编辑配置。
按能力判断退出条件：相应 CLI 已覆盖发现与查询、所需变更、结果验证和生效反馈，典型任务无需读取或修改底层配置即可完成，并有验证证据后，再移除对应的 AI 直接配置写入路径；同时评估通用配置写入命令，避免仅移除工具却保留等价的推荐路径。人工维护与显式故障恢复入口单独界定，不作为 AI 日常管理方式。
NextClaw 的产品愿景，和 NCP 的基础设施愿景不是一回事，但二者强相关：
NextClaw是以做好用户搭档为根本使命的主动式长期智能伙伴NCP是既有通用协议、运行时与积木体系的历史基础设施名
基础设施为长期搭档提供实际执行、组合与扩展能力；个人操作层是这些能力面向用户的支撑形态。新增概念与命名使用 NextClaw，存量名称按兼容需要保留。
基础设施设计继续服务可组合、可扩展、可复用的目标；平台 SDK 化是伴随产品演进的技术方向，其优先级由搭档的实际需要和真实复用场景决定。
任何 AI 在这个仓库里做方案、写文档、改代码时，默认都应把这份愿景当成上位目标，并先回答这些问题：
- 这项改动如何帮助 NextClaw 更好地做好用户的长期搭档？
- 它是否考虑用户的长中短期目标、计划和状态，而不仅是当前任务？
- 它是否改善主动参与的判断与长期连续性，并尊重用户的选择和授权？
- 这项改动是在提升意图到执行的闭环能力，还是让用户自己承担更多工具复杂度？
- 这项改动是在增强系统对用户、项目、环境、历史、结果与错误的感知，还是继续让系统处于“低上下文、低连续性”的状态？
- 这项改动是在增强用户对系统自身的理解与掌控，还是让系统管理能力继续分裂在多个入口里？
- 这项改动是在帮助系统从反馈与错误中持续学习，还是让同类问题只能重复人工兜底？
- 这项改动是在强化统一体验，还是继续制造碎片化入口？
- 这项改动是在增强编排与接入能力，还是把产品推向“什么都往里塞”的方向？
- 这项能力是否适合从命令行、脚本、CI 或 Agent 调用？本地实例能力是否提供了
nextclawCLI 入口；独立托管服务是否提供了自身入口，并复用适用的公共合同？
如果无法说明改动与搭档使命的关系，或引入更多用户负担、割裂和重复，就应该重新审视方案。