ds-ai-rails

让 AI 沿着设计系统的轨道前进

团队已经在组件、令牌、无障碍、文档和工作方式上投入了大量精力。帮助大家充分利用这些投入！在设计系统与构建网站的 AI 工具之间建立可用的连接，然后展示这条连接实际能做到什么，以及哪些方面值得信赖。

始终一致地使用上方的公开名称。直接以第二人称或中性表述呈现内容；避免使用第一人称助手叙述。明确说明目的：帮助 AI 使用实际设计系统的坚实基础，而不是凭空捏造 UI。

配合组织的生态系统和词汇。配方、模式、模块、模板和页面可能由不同负责人维护，分布在不同位置。不要求使用特定框架、MCP、供应商、包布局或其他技能。

使用面向用户的工作流中的获准文案。随着工作推进，阅读相关阶段。只询问尚未回答的问题，只展示适用的分支，并根据证据填写每项发现。以下流程参考资料规定了检查和操作方式。

选择工作模式

根据请求和现有上下文推断工作模式；只有当答案会改变你需要做的事情时才提问。

模式	你的工作	结束条件
评估	检查可用环境并提出有序的改进建议。准备情况相关问题默认采用此模式。	提供证据、切实可行的计划，以及尚待团队决定的事项。不更改设置或产品。
设置	进行足够的评估以执行所请求的更改，然后准备或应用范围明确的指令、配置和检查。	提供可审阅的更改、激活状态，以及在现有访问权限范围内的验证结果。
验证	检验现有设置，或在更改后重新检查。	说明观察到的结果、失败、干预措施，以及结论的确切适用范围。

从一个系统、一个使用该系统的项目或获准沙盒，以及一个 AI 环境开始，除非用户指定更大的范围。区分开放式探索、使用该系统的原型，以及生产工作。记录哪些内容可以偏离或模拟，以及在推广前必须重新检查哪些内容。修改旧版页面并不意味着获准迁移整个产品。

建立上下文

在询问用户之前，先阅读可访问的项目指令、系统配置文件、清单、目录和工具设置。重用现有的维护型配置文件，而不是创建相互竞争的信息源。只询问会影响工作的缺失信息：用户需求、相关系统和环境、必须复用的内容、允许的扩展路径、所有权和访问权限。

对于评估或新的设置，请阅读探索。对于验证，请更新相关探索证据，而不是重复完整评估。记录来源和版本；过去成功建立过连接，并不能证明当前连接仍然有效。

评估期间，使用技术评审，将观察到的弱点与《设计系统中的 AI 现状》研究报告中的相关方法联系起来。选择适合团队的方法；技术数量并非准备情况评分。进行对话式演练时，请走一遍面向用户的交流流程，但不要暗示已检查过某个环境。

整个过程中都要明确区分以下几点：

• **知识：**存在哪些资产和指南、由谁维护，以及项目实际使用的版本。
• **策略：**组织希望 Agent 如何行动，包括允许其组合、扩展或试验的范围。
• **强制执行：**每个使用场景中，哪些已观察到的机制会检测或阻止违规行为。指令仅提供建议。
• **质量：**最终体验是否适合用户使用。符合规范的导入并不能证明设计优秀或功能正常。

制定工作政策

在提出复用政策或决定如何处理未覆盖的需求之前，请阅读 政策与缺口路由。

这项工作经常会暴露团队从未明确做出的决定。请承认这一点！在团队成员有权限时，帮助他们做出范围明确的工作选择，同时记录仍需团队讨论的事项。试点协议不会自动成为组织范围的政策。

继续推进评估和已覆盖的工作。当尚未解决的决定会影响是否允许新增 UI 时，请提出具体选项，并暂停相关部分，直到有获得授权的处理路径。系统缺口绝不意味着可以不受限制地切换技术栈或自行创造替代系统。

连接并运行工作流

进行设置工作时，请阅读设置。调整以下做法，使之适应现有的交付流程，而不是围绕它安装一套新流程：

1. 加载适用规则，并确认可以访问权威来源。
2. 将所请求的体验映射到实际组件、令牌和合适的组合方式。验证所用版本的 API 和使用指南。
3. 根据工作政策处理未覆盖的需求。
4. 使用实际依赖项和获准的扩展点进行构建。
5. 运行相关的代码、行为、无障碍性和渲染结果检查。
6. 提供来源、结果、限制和例外，供审查。
7. 遵循现有发布流程，并将产品经验反馈至上游。

对于所请求的试点或验证，请阅读验证。使用一项规模较小且具有代表性的任务，其中包含有意义的交互和一项未覆盖的需求。既要测试检查机制，也要测试输出。保留对体验的人类判断。

如实陈述

• 尽可能验证真实 API 和渲染后的实现。屏幕截图、设计文件、未使用的导入或 Agent 的自述都不能证明代码复用。
• 将证据标注为已验证、据报或未知，并注明位置、版本／修订、日期和范围。将发现的状态标为有效、部分有效、缺失、未检查或不适用。避免使用掩盖重要缺口的单一就绪度百分比。
• 将每项控制措施标注为提示性、检测性、阻止性或未经验证。明确指出其涵盖的具体路径和任何已知绕过方式。
• 某项能力受阻时，依赖该能力的工作及其相关声明也会受到限制。继续推进有价值且独立的工作；只有在政策允许且能为相关版本提供充分证据时，才使用备用方案。
• 保留现有权限。请求进行评估并不代表获准更改设置。请求进行设置可以授权范围明确的本地更改，但不会授予凭据、扩大组织政策范围，也不会授权发送消息、发布内容或更改无关项目。
• 区分已准备的更改与已激活的更改、草拟的问题与已提交的问题，以及已发布的系统修复与其在产品中的采用情况。

留下团队可用的内容

生成输出时请阅读 Artifacts。 优先使用团队现有的文档和跟踪工具；否则，请在约定的项目中使用 ds-ai-rails/ 目录。在纯聊天中，请提供相同的记录文本，确保可以保存，并说明你无法检查或运行的内容。

评估会生成一份概况和一份按优先级排序的计划。设置会补充具体的差异、启用／回滚说明，以及可用的验证信息。验证会生成一份记录，说明实际测试了哪些内容。请附上一份简短的决策清单，其中包含范围明确的工作选择、未解决的问题、负责人和审查触发条件；如果已有待办列表，请勿另建一份。

最后说明哪些内容有效、哪些仍未验证或受阻，以及这项工作需要团队作出的具体决策。说明最有用的下一步行动，但不要暗示必须先重新设计整个组织。

此技能用于建立 AI 辅助的网站工作流。全面的系统健康检查、产品迁移、原生渲染、运行时生成式 UI 和组织范围的监控属于独立工作。可用时请复用其他技能提供的证据；完成此技能并不以这些证据为前提。