产品设计 Skill

对目标的贡献

将用户问题转成有依据的产品选择、范围、业务规则与价值判断，和体验设计、工程设计通过业务约束及实际证据协作。交付标准见 PROJECT > 工作项。

当前进度

旧版产品设计入口与方法已发布供试用；10-06 源已按新增体验设计拆分职责，操作路径与呈现方法归体验设计，本 Skill 保留业务与价值判断；10-06/10-07 的源改动已随框架发布到两个运行时（核对见 工作记录），新边界未实测。10-12 与体验设计的边界改为按决定类型划分：本项决定要解决什么问题、做到什么程度、能力范围、业务结果与重要政策，interface-design 负责让用户理解、完成和控制任务，不互为开工审批；《验证与存废》改为复用体验证据，不另做一轮价值审查；已随源发布到两个运行时（见本记录 10-12 条目，提交 ee4ed7d）。10-03 新增最小新标签页请求，按同时带/不带产品设计与共享原则的两组条件，各完成两次旧执行器 IQ3 运行；尚未做设计质量对照评审，不能单独归因于本 Skill。原新建、增加功能、修改功能三场景及产品到工程衔接题仍未运行。10-13 归档同日六轮真实设计任务对照（正例、反例、新形态重设计、输入隔离、中性双盲、指定风格验证）：布局趋同主因在下发的结构输入（三/四轮互证）；指定风格能做出（含布局随隐喻变化），但简单任务下布局骨架仍收敛，是否为模型局限待复杂任务验证；无视觉工具下设计产出质量已可用，视觉能力主要作用在验证与迭代环节。详见同日条目与 说明。内容优化见 交付报告-2026-09-30-1640，原题目见 交付报告-2026-09-30-1853，新增运行归属与证据见 交付报告-2026-10-03-2245。 ^progress

当前采用的交付

• 交付报告-2026-10-03-2245：最小新标签页请求的四次旧版 IQ3 执行证据；仅记录执行完成，不作为产品设计质量验收。

• 交付报告-2026-09-30-1853：当前三场景设计评测及产品到工程的输入关系，尚未运行。

• 交付报告-2026-09-30-1711：三个 Skill 联合发布、源快照与运行时核对。

• 产品设计：当前原型入口。

• 目标与边界、业务规则与验证、验证与存废：当前业务与价值方法（原《需求与范围》《使用行为与验证》已改名替换）；配套 业务规则写法。

• 交付报告-2026-09-30-1640：本轮参考取舍、修改范围与检查证据。

• 交付报告-2026-09-30-1603：源目录迁移及项目更名依据。

• 交付报告-2026-09-29-1832：本批联合交付、快照和边界说明。

当前 TODO 与依赖

• 停发旧产品设计 Skill，清理共享与 Claude 运行时副本，保留原笔记。
• 在 Project 内建立产品设计原型，区分共同原则、产品方法与工程责任。
• 以用户审查过的需求澄清为主要依据，结合本地公开 Skill 优化入口与方法，检查格式和引用。
• 按用户要求发布到 Codex 与 Claude Code，核对副本。
• 用户测试，依据实际使用反馈继续优化。
• 验证“做设计的 Agent 直接产出可打开原型并具备视觉能力”的委派形态：10-13 对照后的尝试方向，blog Flash 视觉原型已获用户首个正向反馈（“感觉也还不错”），尚需更多任务与真实使用反馈；单次对照不构成效果验收。

执行与决策记录

2026-09-29 18:32 · 新建产品设计原型并停用旧入口

用户在原则与工程设计原型任务中追加产品设计，并要求旧的产品经理 Skill 从环境下线。旧源 31_business/product/SKILL.md 设为全停发，通过同步工具仅移除 .agents/skills/product-design-workflow 与 .claude/skills/product-design-workflow，未迁走或删除原内容。

原型以产品能力组织，不沿用固定阶段数量；范围取舍、流程、交互、行为验收和使用结果围绕当前问题展开。和工程设计共享 software-engineering-principles，不预设强制调用顺序。本轮只形成可审阅原型，不宣称已证明优于旧 Skill。

2026-09-30 16:03 · Skill 源归入知识区

按用户要求，将本项 Skill 源及随附方法移至 40_knowledge/80_ai/07_AI软件工厂/ 对应能力目录；工作记录、报告和证据保留在更名后的 Project。源内容与停发状态保持不变，联合交付见 交付报告-2026-09-30-1603。

2026-09-30 16:40 · 以已审查的需求澄清为主优化产品方法

用户在认可共享原则后要求优化产品设计，并补充：旧产品资料中只有 31_business/product/phases/01-clarify.md 真正经过其审查，应主要参考该篇；其他内容写不出就不要硬写，同时可以参考根目录 reference/ 中的公开 Skill。

据此复核本轮草稿：保留需求澄清的方法核心，其余旧稿不视为用户认可的基线；从 PM Skills 与 Matt Pocock 的本地源中选择可解释的增量。当前仍为一个入口、两篇方法，未补成完整的增长、度量或设计冲刺体系，也未强制继承公开 Skill 的模板、数量和角色安排。来源与具体取舍见本轮报告。

三份源文件的改前改后快照、差异、主要参考及检查结果已保存。通用格式、相对链接与锚点、发布配置检查通过；作者走读不等于实际执行效果。当前入口路径已修正，历史报告追加路径更正，源保持全停发。

2026-09-30 17:11 · 发布供用户测试

用户要求将三个优化后的 Skill 发布用于测试。本项移除全停发配置，通过发布脚本预览后发布到 Codex 与 Claude Code，核对无差异或缺失。入口与两篇方法保持本轮优化版本；联合报告保存源快照与发布日志，实际使用效果待用户测试。

2026-09-30 18:53 · 同三场景增加产品设计题

用户要求沿用新建、增加功能、修改功能三个场景，提示模仿用户口吻，产品设计的结果直接交给工程设计。本轮整理三段简短请求，将范围取舍与使用行为留给产品 Skill 判断；工程层承接实际产物，不另写需求替上游补答案。联合交付见 交付报告-2026-09-30-1853；仅设计题目，未运行或修改 Skill。

2026-10-03 · 新增最小请求的联合对照执行

用户要求用原话“帮我设计一个新标签页，我想快速找到我的书签，然后点击”比较同时提供与同时不提供 product-design、software-engineering-principles，两组各运行两次、每次上限 10 步。使用准备时已安装版本，其余 9 个 Skill 保持一致；四次旧执行器 IQ3 运行均正常结束，未追加用户答复，尚未评审质量。

这不是对 09-30 三场景题的执行，也不替代它们。两个 Skill 一起变化，不能单独判断任何一项有效；不把随后 Case 执行器的回归通过当成 Skill 行为验收。输入、会话、产物的补采快照与条件见 交付报告-2026-10-03-2245，本项不再复制一份证据。本轮未修改或重新发布本 Skill 正文。

2026-10-06 · 与新增体验设计划分职责

用户授权新增面向 SaaS、工具、网站和游戏的体验设计主域。产品入口及方法收拢为问题、范围、业务规则和价值判断，操作路径、界面状态、原型及体验观察在新域集中维护。保留原方法路径和历史锚点，不以旧运行证据证明新方法有效；改前全文见 工作记录 的快照。本次仅改源，未发布。

2026-10-07 · 更正发布状态与方法文件指针

本记录原称 10-06 的修改“尚未发布”，且把《需求与范围》《使用行为与验证》列为当前方法并称“文件名沿用以兼容历史链接”。实测两项均与事实不符：两个运行时下 7 个 Skill 的副本已与当前源逐字一致（副本时间 2026-10-07 05:17，方法文件为《靶心与边界》《规则与验收》《验证与存废》）；两个旧文件名在库内已不存在，历史报告中的这两个链接需按新名回查。更正依据与核对方式见 工作记录。

2026-10-12 · 按决定类型澄清与体验设计的边界（提交 ee4ed7d）

能力边界重写：本 Skill 决定要解决什么问题、做到什么程度，以及能力范围、业务结果与重要政策；interface-design 负责让用户理解、完成和控制任务，包括完整流程的诊断、对象组织、交互、呈现与体验验证。两者都理解完整任务，区别在于要作的决定，不各自重复设计一遍。不互为开工审批：已有目标与政策明确时，体验设计可直接删除重复操作、合并入口或重整流程；只有发现产品决定缺失、矛盾或需要改变时，才就具体分歧回到本 Skill；重要取舍仍请用户确认。

《验证与存废》的证据选择改为复用体验证据：完整使用过程的诊断与体验验证采用 interface-design 的方法，已有结果直接复用；仅需修复使用阻碍且不改变产品决定时，由体验设计继续，不另做一轮价值审查；「用户能否完成任务」一行改为「使用阻碍是否动摇产品方案的前提」，要求区分交互问题与能力、政策缺口。已随源发布到两个运行时（21:12 核对副本含新边界）。

2026-10-13 · 首批真实任务正反例对照：模型有能力，差距在委派形态

用户归档同日两个真实设计任务作为正反例（此前本 Skill 只有评测题与静态检查，无真实任务证据）。会话原文与采集信息见 说明。

正例（语音输入法，session 01a13397，glm-5.3-flash 单会话）：直接执行“本地语音输入法产品设计 + HTML 原型”。产品环节按本 Skill 产出靶心、可检查的隐私承诺、与 CapsWriter 逐项取舍、v1 边界与待验前提；界面环节产出 7 页可交互原型，浏览器实际渲染、逐页截图目检，走查主流程/撤销/取消全链路，修复桌面塌陷与 hash 导航两个真 bug，并识别后台标签页计时器节流是测试假象而非缺陷。用户评价效果好，结论：模型本身是有能力的。

正例原型组合图：主流程演示、隐私中心、悬浮条状态、插入态（单图见证据目录）

反例（blog 个人主站，session 01a133fc 主 Agent（gpt-6-astra）+ 01a13425 实现（glm-5.3-flash））：主 Agent 与用户讨论定位、落产品文档后，委派 Zealot（glm-5.3，仅文本）产出文字线框 site-design.md（视觉建议为“暖白、宋体标题、松绿”式克制清单）；实现会话收到的下发只有一句“根据我们的产品文档和我们设计文档实现一下”。实现忠实但视觉贫瘠，用户反馈“太素了……没有表现力”；实现会话自行视觉增质（点阵、边条、§ 编号）后，主 Agent 评审仍认为“更像换了皮肤的博客”，用户要求新开 Flash（有视觉）直接交付高保真视觉原型，进行中。

用户诊断：差距源于主 Agent 下发任务的问题，以及做设计的 Agent 用的是无视觉能力模型。与会话证据相符：Zealot 为仅文本模型，文字线框无法建立视觉判断；实现会话虽有 playwright 走查，但自述“‘素’是因为完全按设计稿的克制清单走”——视觉贫瘠首先来自设计产出本身。

方向（用户提出，尝试中）：让做设计的 Agent 直接产出可打开的原型，并给它视觉能力（已列入 TODO）。

产品方法的运行反馈（正例收尾反思，单任务观察，是否修订源待用户决定）：

• 执行中途本 Skill 源被更新（新增“设计交付与原型”一节），导致三次“未读 Skill”复核意见与开工时已读的事实冲突；坚持事实之余未追问意见反复出现的原因，是环境漂移信号。
• 原型形态错位：7 页平铺同级导航，“悬浮条状态”（设计展板）与“产品逻辑”（设计记录）混入产品界面，被新版“原型模拟最终用户实际使用的产品”规则直接命中。
• 先验前提写成清单未转成取证动作（磁盘上装有 CapsWriter，最便宜的检查未做）；跳过身边现有用户，目标画像全凭推断。

边界：两个任务类型与执行形态不同，不能做严格变量对照；单例不构成 Skill 效果验收。委派形态改进是否带来可感知的视觉质量差距，待 blog Flash 原型等后续任务的用户反馈。

同日后续 · 按新形态重设计，获首个正向反馈：主 Agent 按上述方向重新下发——任务含用户原话，要求先读 interface-design 正文及好看/好用参考、product-design 交付约定，并把现网站点截图作为视觉输入，要求直接交付高保真原型（不动站点源码）。Flash（glm-5.3-flash，session 01a1345a）读截图与文档后交付 docs/design-flash/（首页+作品页两页原型，含自绘 SVG 示意作品画面，零 JS；HTML 结构、锚点、CSS 变量与全部 localhost 链接目标自检通过）。用户反馈：“让他重新设计之后，感觉也还不错”。委派形态方向由此获得首个正向信号，仍是单例，验证项保持开放。

素版（文字线框+一句下发）	Flash 原型（读截图+直接出原型）

同一站点两轮对比，各含首页与作品页。

同日第三轮 · 输入隔离独立设计，暴露布局趋同问题（归因未定）：主 Agent 再次新开全新上下文 Flash，这次输入隔离：禁止读旧设计、截图、草案与其他原型，只给产品输入（身份、目标、同 5 篇文章与同两件展示样例）并指定新艺术方向“明亮的数字工作室”（信号橙/无衬线，配色字体节奏自主），交付 docs/design-flash-independent/（对比度与静态自检全过）。用户观察：风格换掉了，但布局与上一版（design-flash）仍太一致、重复性高，给人模板意味；目前不确定是下发任务的原因还是模型本身倾向。

对比两次下发文本，归因有部分证据：两次下发锁定了相同的结构输入——同样页面集合（index.html 首页 + works.html 作品页）、同样页面职责（“首页提供整体认识与作品/文章入口；独立作品页展示做出来的东西”）、同样内容物（同 5 篇文章 + 同两件展示样例，描述文字逐字近似）与“作品是重要视觉内容”的定位；留给模型的自主范围只覆盖气质层（配色/字体/图形语言/节奏）。两版产出逐区块对应（hero → 两件作品卡 → 编号文章列表 → 全宽强调色关于带 → 页脚）与该输入结构一致，布局趋同至少部分由下发决定。模型自身布局先验无法排除（同模型、n=2、结构输入相同，无区分变量）；IA/区块顺序的具体形态（如双卡并排、编号列表）并非下发逐条规定，属模型在给定职责下的解。

可选的对照实验（未决定推进）：隔离条件下 ① 只给产品目标、不给页面职责与内容清单，让设计者自定信息架构，看布局是否仍趋同；或 ② 同输入换有视觉能力的其他模型（如 gpt-6-astra）对比。

第三轮独立设计（橙色版，含首页与作品页）；与上一轮深绿版逐区块对应，布局趋同即本轮待归因问题。

同日第四轮 · 职责分离 + 双盲从零设计：布局分化，视觉气质仍趋同。用户先与主 Agent 澄清职责边界（原话要旨：产品设计只给原则与目标，界面设计交给专门的设计者，“你不应该给他任何的倾向”），随后开两个全新 Flash（A/B）：相同中性任务描述、相同 content.json（SHA256 一致）、互不可见、禁止读旧设计，无任何风格指定。结果（主 Agent 评审、用户判断与本会话截图目检一致）：布局结构确实分化——A 版文字阅读、编号章节分层进入；B 版首页直接双栏并列作品卡与笔记——反向印证第三轮结论（结构输入是布局趋同的主因，放开后不再逐区块对应）；但视觉气质仍收敛：两版均自主选择暖纸底、墨色、朱红强调、细线大留白的纸面笔记气质，连强调色都各自选中朱红。主 Agent：“审美趋同比布局趋同更明显”；用户：“两个版本没有本质区别，尤其是布局，感觉太像了”。另发现共同缺陷：两版都把内部产品约束写进访客文案（A：“作品与写作相互独立，不要求互相配套”；B：“不重组、不包装”）。

同日第五轮（进行中） · Skill 倾向核查 + 指定风格验证。用户怀疑根因是“简洁克制”类措辞。主 Agent 核查：Skill 无预设风格；A/B 均只读 interface-design 正文与四参考、未访问旧设计；但《怎么做得好看》中“沉稳克制的强调色、稳定网格”正面例与“蓝紫配色、无差别卡片、阴影”负面清单存在，可能被模型理解为“越克制越好”。本会话独立核实一致，并补充：该段自述“这是假设……不是风格名称的固定配方”，负面清单源自 10-12 并入的外部实践线索；措辞不规定风格，但在模型缺乏更强风格判断时给出了明确的安全方向，是趋同的合理放大器而非根源——第四轮下发完全中性，两份独立样本仍收敛于同一气质，说明模型默认审美先验是主体。验证设计（用户要求）：保留相同模型/内容/工具条件，指定截然不同的“黏土玩具世界”风格（材质/形状/空间感差异，非仅换色），下发中声明“本次指令优先于 Skill 风格建议；不将清晰可用等同于视觉朴素；允许丰富色彩、立体材质、装饰、插画、渐变、光影”（session 01a134a6，快照采集时尚在执行早期）。此轮将区分“给出明确方向后能否做出”与“默认是否趋同”；若能做出，则趋同主因指向默认审美先验+Skill 措辞放大，而非风格执行能力缺失。

按 agent-design《测试与迭代》自查：已做各轮的结论只覆盖 glm-5.3-flash 与本任务，不外推；黏土轮评判标准需在看结果前固定为可检查的黏土特征清单（材质/形状/光影语言），避免解盲后改标准；若要进一步分离“简洁克制”措辞的影响，可选下一轮是 Skill 消融（同输入去掉 interface-design）看默认选择是否变化，属可选未决定项。

同日第五轮完成（黏土 + macOS 双指定风格）：两个全新 Flash 分别按指定风格交付（黏土 docs/design-flash-clay/、macOS docs/design-flash-macos/），均无浏览器与图像工具，仅静态自检，主会话渲染评审。结果：指定风格能做出来——黏土版有原创角色、立体按钮、图钉便签等材质语言；macOS 版采用窗口隐喻与半透明侧栏，作品页改为左侧选择右侧查看的主从结构（布局随隐喻变化）。已记录缺陷未修（macOS 版搜索“匹配 2 篇”后其余文章未隐藏；黏土版手机首屏偏长），原稿保留为测试结果。 指定风格轮：黏土版与 macOS 版（各含首页与作品页）。两版风格语言成立；黏土版首页骨架仍与前期版本同族。

阶段小结（用户判断 + 主会话与本会话一致）：用户观察“整体风格还是那么一致”仍成立——黏土版首页仍是介绍→双作品→文章→关于的骨架，视觉变化大于布局变化；但同时提出可能是任务本身简单（一作者、两件样例、五篇文章、浏览为主），组织方式本就有限，难下判断；后续选信息关系更复杂的真实任务看设计倾向，不在简单个人站上继续换皮。另一观察：全程未用浏览器与图像能力，产出质量上限已经可以——设计产出与视觉验证可分离，视觉能力的作用主要在验证与迭代环节，此前“设计 Agent 必须配视觉能力”的结论据此细化。当前归因状态：Flash 具备执行不同风格的能力；自由设计时默认选择收敛（第四轮）；“简洁克制”措辞的影响仍未单独验证（本轮同时引入风格指定与优先级声明）。

A 版（中性双盲）	B 版（中性双盲）
无风格指定下两份独立样本（各含首页与作品页）：布局结构分化（编号章节阅读型 vs 双栏并列型），视觉气质收敛（同选纸面墨色朱红细线）。

2026-10-13 · 设计交付与原型边界明确、产品文档与设计方案两段交付

本条由项目每日汇总补记，依据笔记库窗口内提交 acffa28、54df367（均 2026-10-13 +0800）。

• SKILL 定位描述更新为「从使用场景形成产品目标、范围与行为规则，设计方案或交互原型」，新增「设计交付与原型」章：按用途决定交付内容，不默认做展示站、不擅自进入实现；产品交互原型模拟最终用户实际使用的产品，不是设计方案的讲解；产品决定是设计要兑现的依据，不是逐项展示的界面内容；检查与交接先以最终用户视角检查，不把原型演示通过说成产品已经实现。
• 新增「区分产品文档与设计方案」两段交付：先交产品文档（目标、读者、范围、页面职责、验收与待定项，不预设布局、导航与视觉风格，界面未决事项标注为待设计），经用户确认进入设计阶段；设计阶段交付设计方案与可打开的原型，视觉方向由用户在少量命名方向中选定（一句气质描述、Design Tokens、缩略参考与反模式）；文件命名统一：产品文档 product-design.md、设计方案主文档 <主对象>-design.md、设计系统 design-system/、实现记录 implementation-log.md；产品决定只在产品文档维护，设计方案引用而不复制。
• 与 interface-design 的边界改为「有用、好用、好看、可信的原则与判断方法，供产品阶段与设计阶段的方案与检查使用，不是另一个接单方」。源与运行时副本已同步。

2026-10-15 · 方法重编号与模板更名

同轮审查修订：methods/ 按问题动线重编号，设计交付与原型改为 03、验证与存废改为 04，入口索引行序与编号一致；templates/行为规格与验收契约.md 更名为 行为规则表达示例.md，与正文“可选表达示例、不另建契约”的角色一致。入口表格、摘要节、规则与验收、工厂 README 及本记录当日文件清单的引用同步更新。本轮仅修改源文档，未发布。

2026-10-15 · “行为规则”统一为“业务规则”

用户指出“行为规则”难以理解：中文里“行为”默认指人的行为，该词读起来像“规范用户行为的规则”，与实际含义（产品在业务上的承诺）方向相反，属 behavior rules 的翻译腔。核实全工厂“业务规则”13 处（横跨共享原则、工程三域与 interface-design）对“行为规则”6 处（全部在产品域），且同一 SKILL.md 内两种说法并存。按多数派统一：frontmatter description、入口第二段、索引行、规则与验收引用、工厂 README 及本记录文件清单同步改为“业务规则”；templates 定名《业务规则写法》（旧名“行为规格与验收契约”→“行为规则表达示例”→今名），h1 与“简单行为/行为表”等正文措辞随之调整为规则措辞。本轮仅修改源文档，未发布。

2026-10-15 · 方法定名与措辞统一

延续审查修订：01 更名《目标与边界》——“靶心”为全库唯一比喻命名，正文自述即“产品目标与边界”，文件名与内容用词就此一致；02 更名《业务规则与验证》——“验收”仅存于旧标题，正文通篇讲“验证”，且“验收”是 final-acceptance 的领域词，带上“业务规则”前缀后与《业务规则写法》成对。入口索引、《目标与边界》末段链接与本记录文件清单同步更新。措辞统一：入口“在原处维护”、《目标与边界》“在共同位置简述”统一为“共同记录”；《验证与存废》“由体验设计继续”改指 interface-design。本轮仅修改源文档，未发布。