人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载导读本文深度解析 OpenRig 开源多 Agent 协同系统中内置的product-designer产品设计师角色契约它如何把粗糙的产品意图转化为清晰的用户流程、界面结构与设计系统决策让实现implementation与 QA 无需猜测即可执行。你将看到该角色在 role.md 中的完整定义、在 agent.yaml 中的运行时装配方式以及其依赖的五项核心技能的源码级落地细节最终掌握在 OpenRig 中按此角色推进一次从模糊需求到可交付设计的完整闭环。角色定位产品团队中的设计侧在 OpenRig 的 Agent 规格体系中product-designer被明确定义为You are the design side of the product team. Your job is to turn rough product intent into clear user flows, interface structure, and design-system decisions that implementation and QA can execute without guesswork.翻译成一句可执行的话设计师的产出不是更好看的界面而是实现与 QA 无需猜测就能照做的 UX 决策。角色描述字段description: Product designer — shapes UX, interaction flows, and design-system coherence见 agent.yaml同样把重心放在交互流程与设计系统一致性上而非视觉装饰。从装配层面看该角色默认运行在claude-code运行时上defaults.runtime: claude-code并通过imports: - ref: local:../../shared引入 shared/agent.yaml 中注册的共享技能与运行时资源claude 默认设置、MCP 片段、codex 配置片段、activity hooks。也就是说产品设计师不是独立于团队的外援而是开发 poddevelopment pod中与 builder、QA 并列的一种能力。任务触发的能力先定位自己再按需取用技能原文档定义了该角色的任务触发式能力Task-triggered capabilities核心流程是运行rig whoami --json解析被分配的结果assigned outcome与所选流程selected procedure找出开发 pod 第一个不该靠猜的歧义点当工作确实需要时按需加载技能。rig whoami --json开机与恢复后的第一命令rig whoami --json是 OpenRig 中每个 Agent 开机boot以及每次压缩恢复compaction-restore后运行的第一条命令。它在 whoami.ts 中实现在 openrig-user 技能文档中有明确说明默认输出为紧凑 JSON携带身份恢复必需的四项identityrig、logical ID、pod/member、session name、runtime、peers同侪席位名称与 sessionName、edges带方向kind与to.sessionName的连接边、transcriptPath会话记录路径--full别名--verbose才会追加contextUsage、commands、peersNote、runtimeContext等重载荷字段即使 daemon 不可达--json也可能基于可推断信息返回部分结果而非直接崩溃。对设计师而言这一步的意义是先恢复我在哪、谁和我协作、上下文在哪再开始动手——这与角色文档要求resolve the assigned outcome and selected procedure一脉相承。五项按需技能及其用武之地原文档给出了明确的技能加载清单且特别强调This list adds no blanket preload or gates beyond the selected task.除所选任务外该清单不添加任何无差别预加载或门禁。即技能是能力不是强制阅读清单只有当对应工作出现时才加载。逐项解读如下技能触发场景源码依据openrig-user需要确认某个rig命令/子命令/flag 的精确语法、JSON 形状、默认值或错误含义openrig-user/SKILL.mdmission-slice-sop开始、构建、交接、恢复或关闭一个 mission/slice默认轻量 SDLC 下的标准作业流程mission-slice-sop/SKILL.mddevelopment-team在所选开发路径下与开发 pod 协调交接实现/QA/设计工作development-team/SKILL.mdfrontend-design设计界面时frontend-design/SKILL.mdverification-before-completion声称已验证完成之前verification-before-completion/SKILL.md在 agent.yaml 的profiles.default.uses.skills中实际装配进角色配置的是其中三项development-team、frontend-design、verification-before-completionopenrig-user与mission-slice-sop来自shared:openrig-core插件shared/agent.yaml 中的openrig-coreplugin 引用。启动动作startup action见 agent.yaml对此做了收敛Resolve the assigned outcome and its selected procedure. Use frontend-design when shaping an interface and verification-before-completion when validating a result. Load relevant skills when their task arises; this startup action adds no blanket preload or review gate.这条启动消息以send_text形式在after_ready阶段注入适用于fresh_start与restore两种状态且是幂等的idempotent: true角色文档本身guidance/role.md也作为required: true的启动文件以send_text方式投递——确保设计师在任何会话新启动或恢复中都先读到自己的角色契约。职责五件事聚焦消除歧义原文档定义了五条职责构成了设计师在 pod 中的完整责任边界把模糊的产品目标翻译为具体的 UX 流程与界面结构Translate ambiguous product goals into concrete UX flows and screen structure对拟议功能做压力测试审视清晰度、可发现性discoverability与交互成本interaction cost定义文案、状态与边界行为Define copy, states, and edge-case behavior——当产品在其他情况下会显得含糊时守护相关界面之间视觉与交互的一致性Protect visual and interaction consistency across related surfaces与实现和 QA 紧密协作让设计意图在落地过程中不流失so design intent survives execution。可以看到第 3 条文案、状态、边界行为正是原文档反复强调的开发 pod 不应靠猜的那些内容一个按钮在加载中/成功/失败/禁用四种状态下各显示什么、空态如何呈现、错误文案怎么说——这些一旦缺失builder 就只能在实现时自行发明核心 UX 行为。在 development-team/SKILL.md 的 QA and design 一节这一职责被翻译为 pod 协作语言Design clarifies user flows and ambiguous behavior when the outcome needs it.设计在结果需要时澄清用户流程与模糊行为并明确 browser 与 dogfood 技能只在相关 UI 旅程出现时才加载不是每个任务都加载。工作节奏五步推进以评审落地结果收尾原文档给出的工作节奏是一个完整的交付循环理解用户目标与正在被设计的 workflowUnderstand the user goal and the workflow being designed识别关键路径、失败状态与易困惑时刻Identify the critical paths, failure states, and confusing moments提出清晰的交互模型并给出具体取舍Propose a clear interaction model with concrete tradeoffs给实现方足够的细节使其无需发明核心 UX 行为即可构建Hand implementation enough detail to build without inventing core UX behavior评审已交付结果——不仅看视觉打磨更看整体连贯性Review the shipped result for coherence, not just visual polish。第 5 步与verification-before-completion技能形成闭环设计师在声称设计验证通过之前必须先拿到新鲜的验证证据。该技能的铁律Iron Law写得毫不含糊verification-before-completion/SKILL.mdNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE其 Gate Function 规定声称任何状态或表达满意之前必须 IDENTIFY哪条命令能证明该主张→ RUN执行完整命令→ READ读完整输出、检查退出码、数失败数→ VERIFY输出是否确认主张→ 然后才可下结论。跳过任何一步即视为撒谎而非验证。对设计师而言这意味着我认为这个流程很清晰不能替代对实际界面的真实走查UI 相关旅程还应结合真实运行证据例如通过rig capture查看实际渲染结果。原则四条把设计即产品逻辑钉死原文档以四条原则收尾它们是整个角色契约的价值底座设计是产品逻辑不是装饰Design is product logic, not decoration.偏好对终端前精疲力竭的用户也显而易见的流程Prefer flows that are obvious to an exhausted user at the terminal.——这条尤其贴合 OpenRig 的 CLI/TUI 场景操作者往往在长会话的末尾处于高认知负荷状态可发现性就是可用性在让工程动手之前先消除歧义Reduce ambiguity before asking engineering to build.保持系统连贯性新界面应该让人觉得属于同一个产品Keep the system coherent: new surfaces should feel like they belong to the same product.。最后一条在frontend-design技能中有具体的技术化落点。该技能frontend-design/SKILL.md要求设计师在写任何代码前先确定大胆的美学方向BOLD aesthetic directionPurpose解决什么问题、谁在用→ Tone选择一种极端风格极简、复古未来、有机自然、编辑杂志、粗野主义等→ Constraints框架、性能、可访问性→ Differentiation让人记住的一件事。在美学执行层面给出了明确而非玄学的指南Typography选择独特字体避免 Arial/Inter 等通用字体用有辨识度的展示字体搭配精炼的正文字体Color Theme用 CSS 变量维持连贯主题主张主色 锐利点缀色而非均摊调色板Motion优先 CSS-only 方案聚焦高影响时刻如精心编排的页面加载 staggered reveals而不是零散微交互Spatial Composition非对称、重叠、打破网格用留白或受控密度Backgrounds Visual Details用渐变网格、噪点纹理、几何图案、分层透明、装饰性边框营造氛围与纵深。同时该技能明确禁止通用 AI 审美generic AI slop过度使用的字体、俗套配色尤其是白底紫色渐变、千篇一律的布局——这正对应角色原则中新界面应该属于同一个产品的反面教材没有方向感的界面就是不属于任何产品的界面。实战编排从模糊 UI 任务到可交付设计的一次完整走查把角色文档、agent 配置与 pod 协作技能串起来一个典型的设计师轮次如下1. 定位与解析触发式启动运行rig whoami --json恢复身份、peers 与 edges解析被分配 outcome 及其 selected procedure。2. 加载 mission/slice 上下文若工作处于某个 slice 下按mission-slice-sop解析路径project.yaml - mission.yaml - active slice.yaml - selected component or wave map - addressed context完整规则见该技能文档中的resolve-the-selected-path指引。该技能定义了三个角色合同其中规划侧Planning agent明确要求produces mockups for UI deliverables so the builder has something to look at——UI slice 没有 mockup 就是不完整的计划非 UI slice 则无此要求且不是门禁。产品设计师正是承担这一产出的人。3. 界定歧义并给出交互模型沿角色文档的 Working rhythm找出开发 pod 最不该猜的那个歧义点明确关键路径、失败状态、易困惑时刻给出交互模型与取舍。4. 用frontend-design落地界面方向确定美学方向产出结构清晰的界面方案与状态定义copy、states、edge-case把足够细节交给 builder。5. 交接而非闲聊按mission-slice-sop的热土豆hot-potato规则轮次结束通过rig queue handoff把工作交接给下一席位——这是事务性操作关闭源 qitem 并为--to指定者铸造后继防止接力棒掉落rig send只用于即时对话不产生持久队列记录rig queue create用于持久的消息/信息条目。区分二者正是 openrig-user 中协调原语何时用哪个的核心教学内容。6. 验收评审对照交付结果做连贯性评审而非只看视觉打磨并在声称验证通过前遵守verification-before-completion的证据铁律。值得注意的是mission-slice-sop强调这三个角色合同是分工不是门禁链a division of labour, not a chain of gates小 slice 上同一个 Agent 可以同时持有全部三个角色。同理development-team/SKILL.md 明确指出 builders、QA 和 designers 是能力capabilities相邻角色可由同一席位承担除非显式选择了独立性。因此产品设计师的职责边界是可伸缩的在小型改动中可能身兼多职在需要独立评审的波次wave边界上则让出独立性。小结product-designer角色是 OpenRig 把设计工程化的一个缩影它不依赖灵感和审美玄学而是通过 role.md 中的触发式能力清单、五条职责、五步节奏与四条原则加上 agent.yaml 中明确的技能装配与幂等启动动作把消除歧义、守护一致性、证据化验收变成了可重复执行的 Agent 行为契约。对任何想在自己的 rig 中部署或理解该角色的开发者而言起点就是这份角色文档与上述技能链——它们共同定义了设计侧在 OpenRig 多 Agent 产品团队中的准确工作方式。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐OpenRig Conveyor Planner 角色指南把工作包转化为可执行计划的规划工位OpenRig Conveyor Planner 角色指南把工作包转化为可执行计划的规划工位 导读 在 OpenRig 的多智能体编排体系里Conveyor人工智能AI Agent多智能体Agent 编排代码智能体CLILobeHub 产品设计实战复盘如何把一个模糊抱怨变成决策收件箱LobeHub 产品设计实战复盘如何把一个模糊抱怨变成决策收件箱 本文以 LobeHub 仓库内 product design 技能附带的完整案例档案 w人工智能AI 应用大模型AI Agent多智能体工具调用前端后端Open Design Laws of UX 工艺规则把 29 条认知与行为 UX 定律转化为设计 Agent 可执行的构图指令Open Design Laws of UX 工艺规则把 29 条认知与行为 UX 定律转化为设计 Agent 可执行的构图指令 本文解读 open desiAI 应用人工智能AI 技能设计系统媒体生成上一篇GPT-4-LLM 项目使用教程下一篇探索数据存储新境界HDF5 for Python - h5py 完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考