状态：权威产品规则（authoritative） 适用范围：所有 Cindy 客户端功能、交互、架构和生态能力 读取时机：新增或调整产品功能、判断 Core / Skill / 插件归属、设计人机交互或 多端体验之前
Cindy 的首要目的始终是帮助用户完成真实工作，而不是停留在对话、回答或能力展示。
产品设计应从用户最终要交付的结果出发：获取真实工作上下文，调用合适的 Agent、模型 和工具，允许人类理解与修正过程，并把工作推进到可使用的成果。
判断一个功能是否有价值时，优先问“它帮助用户完成了什么工作”，而不是“它展示了 什么 AI 能力”。
Cindy 首先服务不想研究 Key、CLI、MCP、模型差异和运行环境的用户。配置和连接的 复杂度应由产品承担，不应转嫁给用户。
- 用户不需要先理解 Agent Loop 才能开始工作。
- 常见连接、授权和运行环境应尽可能自动发现、引导和修复。
- 高级配置可以存在，但不能成为完成普通任务的前置条件。
- UI 应使用用户熟悉的工作语言表达状态和动作，不把内部实现直接暴露为产品概念。
Cindy 不以重新实现 Claude Code、Codex 或其他 Agent Loop 为目标，也不把底层模型和 Agent 已经具备的能力包装成自己的“智能”。
Cindy 负责建立可靠连接：
- 连接人与 Agent、模型及 AI 基础能力；
- 连接 Agent 与用户真实的文件、文档、消息、应用、工具和设备；
- 连接工作过程与图片、模型、音频、图表、代码和其他可交付成果；
- 连接个人与组织中可复用、可流动的 AI Native 工作方法；
- 连接不同设备上的同一个任务，使工作可以连续进行。
底层智能可以持续演进和替换，Cindy 应尽可能保留其原生能力，避免在连接层造成能力、 上下文、事件、性能或结果质量的无意损失。
Cindy 将产品能力集中在四个长期方向。它们共同服务“连接真实工作”，不是四套互相 独立的功能集合。
UI 的责任是隐藏系统复杂度，让用户看懂状态、理解结果、表达意图并保持控制，而不只是 让聊天界面更美观。
- 复杂能力应通过渐进式交互呈现，默认路径保持直接。
- 适合结构化、可视化或可操作表达的信息，不应被迫塞进长篇 LLM 文本。
- 用户操作的对象、影响范围、进行状态和最终结果应清楚可见。
- 高风险动作必须有与风险匹配的告知、授权、停止和恢复能力。
Cindy 应让用户方便地接入、选择和使用不同 Agent 与模型，同时保持统一的产品体验。
- 用户不应因更换 Agent 或模型而重新搭建整套工作环境。
- 连接层应忠实传递底层能力、工具、事件、上下文和结果。
- 供应商差异由连接层吸收；确实影响用户决策的差异才进入 UI。
- Cindy 不应被单一模型、供应商或 Agent 实现永久锁定。
多端体验追求同一件工作在设备之间自然继续，不追求每个平台机械地拥有相同页面。
- 桌面端、手机端、远程连接、消息入口和自动任务共享一致的任务语义。
- 每个端承担适合它的查看、输入、审批、控制或执行职责。
- 切换设备或断线重连后，用户不需要重新解释已经存在的上下文。
- 多端状态冲突、权限与操作归属必须有确定规则，不能依赖用户猜测。
插件是运行在 Cindy 中的沙箱小程序，是人类与 Cindy Agent 双向协作的应用界面。
插件可以完整、垂直并拥有丰富交互。它可以展示表格、时间线、图表、画布、表单、Diff、 媒体资产或其他比长文本更适合人脑理解和操作的内容。
典型交互循环是：
- Agent 向插件提供结构化状态、数据或结果；
- 插件把这些内容呈现为友好、可操作的界面；
- 用户点击、编辑、选择、拖拽、标注或确认；
- 插件把结构化的用户意图交还 Agent；
- Agent 继续工作并更新插件状态。
Agent 与插件之间应优先交换有明确契约的结构化数据和事件，不应把解析任意 LLM 文本 作为主要协议。插件不得绕过 Cindy 的权限与安全边界直接取得宿主能力。
Core 是所有用户共同依赖的宿主与运行时。它只负责必须由 Cindy 统一提供的基础能力：
- 通用 UI 外壳与人机交互基础设施；
- Agent / 模型连接与会话、任务生命周期；
- Skill 与插件的运行时、权限、安全和故障隔离；
- 多端连接、状态连续性与用户数据归属；
- SkillHub、插件市场、安装、更新和分发的通用机制。
Agent 提供智能、推理、计划和执行能力。Cindy 负责连接和承载 Agent，不把 Agent 已有 能力重复实现为 Core 功能。
Skill 描述工作如何完成。它使用自然语言、脚本或工具编排已有能力，适合沉淀个人、团队 或组织中反复出现的工作方法，通常不需要专属交互界面。
插件是可运行的小程序，负责承载人类与 Agent 之间的富交互、结构化状态和专用能力。 插件可以与 Skill 配合：Skill 决定工作流程，插件在合适阶段提供查看、编辑、判断和操作 界面。
任何个人、团队、行业或组织特有的工作流程、数据接入和交互界面都不得进入 Cindy Core。
- 工作流程进入 Skill；
- 外部能力、数据接入和富交互界面进入插件；
- 个人、组织和公共只是 Skill / 插件的发布范围，不是 Core 的功能层；
- 官方开发的能力只要可以由插件承载，也优先作为官方插件分发。
Core 可以提供组织身份、可见范围、安装授权、签名、策略、更新和撤销等通用机制，但 不能知道某个组织具体怎样工作。
只有同时满足以下条件的能力才应考虑进入 Core：
- 它是不同用户和场景共同需要的通用基础能力；
- 它必须由宿主掌握，无法由 Skill 或沙箱插件安全、完整地实现；
- 它不编码个人、团队、行业或组织特有的业务流程；
- 它形成稳定、可复用的基础原语，而不是一个固定垂直入口。
边界不明确时，默认先在 Skill 或插件中验证，不直接扩张 Core。
Cindy 不以以下方向为目标：
- 成为只提供问答的聊天客户端；
- 重新发明已经成熟的 Agent Loop；
- 把每个组织需求做成 Core 中的固定功能和常驻面板；
- 通过堆积功能数量证明产品能力；
- 要求用户理解底层技术后才能使用；
- 为追求表面功能一致而在每个设备复制相同界面；
- 用不可交互的长文本替代本可清晰表达的结构化结果。
提出或实现新功能前，至少回答：
- 它帮助用户完成什么真实工作？
- 它是否增加了普通用户的配置或理解门槛？
- 它解决的是通用连接问题，还是个人 / 组织的具体流程？
- 它应该由 Core、Skill 还是插件负责？为什么？
- 如果需要富交互，是否应作为插件小程序实现？
- 它如何在桌面、手机和远程场景中保持任务连续？
- 用户能否清楚理解状态、影响范围和结果，并在需要时停止或修正？
不能清楚回答这些问题时，先完成产品设计，不直接进入实现。
本文描述 Cindy 的目标状态和长期产品约束，不代表当前版本已经完全符合全部原则。 受历史实现、阶段性方案和能力建设进度影响，现有产品可能仍有部分差距；这些差距应被 如实识别、评估优先级，并在后续迭代中持续改进。
发现现状与本文不一致时，应区分它属于原则冲突、尚未完成的建设，还是经过明确决策的 阶段性例外。可以根据用户影响和实施风险分阶段收敛，但不得为了迁就当前实现而默默 削弱、曲解或覆盖产品原则。
修改本文意味着改变 Cindy 的产品边界，必须先获得明确的产品决策，再与相关实现和 开发规则同步更新。