即刻App年轻人的同好社区
下载
一直在想现实生活中有那么多丰富多彩的设计，为什么不能将它们迁移到网站UI页面设计上呢
今年年初启动了数字女娲这个项目，目标让大家可以随心改变浏览网站的UI设计风格，鼓励大家将身边发现的好看设计应用到浏览的网站上去，提高日常冲浪体验。
目前已开发几个月了，实现了全部基础功能，大家已可以低门槛将自己的设计想法转换成网站的UI设计并应用到网站上。
图四是我做出来的樱桃小丸子风格的GitHub，好奇大家做出来的风格。。✌︎˶╹ꇴ╹˶✌︎
今年年初启动了数字女娲这个项目，目标让大家可以随心改变浏览网站的UI设计风格，鼓励大家将身边发现的好看设计应用到浏览的网站上去，提高日常冲浪体验。
目前已开发几个月了，实现了全部基础功能，大家已可以低门槛将自己的设计想法转换成网站的UI设计并应用到网站上。
图四是我做出来的樱桃小丸子风格的GitHub，好奇大家做出来的风格。。✌︎˶╹ꇴ╹˶✌︎
1 00
不可否认一些独特性的UI设计确实很棒，不过对于审美每个人的需求都不一样，其实目前很大一部分的UI应该交还给用户定义，比如配色方案、组件样式等等这些，用户来决定想看到的网站风格是什么样的，因此我做了一个插件赋予用户这一权利，让用户一句话可以个性化任何网站风格样式。
玉伯: Yuri 创造者汗青说：审美不等于视觉艺术。大部分人把视觉当成审美，是一个极大误解。审美是你觉得什么不好、什么好，审美是经历，是角度，等等。 比如：宫崎骏的审美里，除了视觉呈现，还有少女、城堡、田野、农作、战争、反思等等。审美是区分，有独特性，不可复制。 产品 UI 也如此。AI Coding 能复制 UI 层的交互呈现，却无法抄走 UI 里的审美、理念、叙事等等。比如：Claude Code 的 UI，复制过去后，还是 Claude Code，而不是你想做的产品。复制 UI，实质上是伪命题，会是东施效颦。 UI 的全称是 User Interface。为人服务的产品，必然需要 UI。Apple 的产品很好用，一致性很强，离不开 Apple 的一整套 HUI 规范。 Agent 也需要 UI。比如 ChatGPT 如果是 Terminal 形态，那么大概率火不了。如果 DeepSeek 没有在 UI 层面放出推理过程，那么当初的热度会少不少。Manus 刚出道时，天才的回放 UI 设计，以及 Task 运行过程中步骤条和虚拟操作的可见性，都是出圈的关键。Lovart 如果没有画布 UI，那么大概率就没人用了。 UI 是 Agent 产品的核心。因为除了 UI，Agent 产品层确实也没剩下什么。 Skill 和 CLI 最终卷的也是 UI。不需要 UI 的，大概率轮不到创业者去做。
1 00
人与 Agent 的协作方法论
整理自与 Claude 的对话 · 2026.04.09
一、层级关系
人
↓ 管理学（组织/激励/沟通）
人（意图/目标层）
↓ 委托工程 / Delegation Engineering
Agent（自主执行层）
↓ harness 工程（Prompt/Chain/Tool）
LLM（原始能力层）
每一层的"驾驭"方式，本质上是上层如何将意图转译为下层能理解的语言。
二、人驾驭 Agent 的方法论：「委托工程」
为什么是"委托"？
管理人用的是激励（人有自己的欲望和利益）
harness LLM 用的是提示（LLM 是无状态的概率机器）
Agent 处于中间地带——有目标感和自主行动能力，但没有真正的"利益"
人与 Agent 的关系，最接近的人类概念就是委托-代理关系。
核心五维度
1. 意图压缩（Intent Compression）
将人的高维、模糊意图，无损压缩成 Agent 可执行的目标。这是比 Prompt Engineering 更高阶的能力——你要先想清楚自己要什么。
2. 边界设定（Boundary Setting）
显式定义 Agent 能做什么、不能做什么、什么情况下需要来询问。这不是技术问题，是授权哲学问题。
3. 可观测性设计（Observability Design）
设计检查点、日志、汇报节奏，让人保持对过程的感知。类似管理学里的"过程控制 vs 结果控制"。
4. 失败模式预设（Failure Mode Anticipation）
Agent 不会"偷懒"，但会"幻觉"、"过度执行"、"误解目标"。需要提前设计兜底机制。
5. 信任校准（Trust Calibration）
随着对 Agent 能力的观察，动态调整授权范围。Agent 不会"成长"，但你对它的理解会加深。
与"管理学"的本质差异
维度 管理人 委托 Agent
动机来源 内在（欲望、价值观） 外在（目标注入）
沟通方式 自然语言 + 情感 结构化意图 + 约束
失败原因 意愿问题居多 理解问题居多
信任建立 时间+情感积累 能力验证+边界测试
扩展性 线性（招人成本高） 指数级（复制部署）
一个有趣的比喻
你是导演，Agent 是演员。 你不需要亲自表演，但你必须把剧本、场景、情绪基调交代清楚。演员再有能力，也演不出导演没想清楚的东西。
这也解释了为什么很多人用了 Agent 反而效率更低——不是 Agent 不够强，而是人没有想清楚自己要什么。
三、在互联网产品研发中用好 Agent
认知前提
多开 Agent 窗口并行，本质上是在做：
把你的"认知带宽"外包出去
单线程的你，变成了一个调度者。调度本身也有成本——并行不是越多越好。
Agent 能接管哪些工作？
按自主程度分层，覆盖产品 + 全栈开发：
高自主（交出去，偶尔 review）
│ 【产品】需求文档初稿、竞品分析、信息聚合
│ 【前端】组件代码生成、样式调整、单元测试生成
│ 【后端】CRUD 接口生成、SQL 编写、数据迁移脚本
│ 【工程】代码注释、变更日志、README 文档
│ 【测试】测试用例生成、边界 case 枚举、Mock 数据生成
│
中自主（你主导，Agent 辅助）
│ 【产品】原型/交互稿讨论、技术方案评审
│ 【前端】复杂交互逻辑、状态管理设计、性能优化建议
│ 【后端】系统设计讨论、接口契约设计、缓存/消息队列方案
│ 【全栈】代码 Review（Agent 找 bug 和隐患）、重构方案
│ 【数据】埋点方案设计、数据分析解读
│
低自主（只做单步辅助）
核心架构决策（微服务拆分、技术选型）
安全敏感设计（鉴权、支付链路）
用户访谈 & 商业判断
上线决策 & 故障处置
规律：越靠近"信息处理与代码生成"，越适合 Agent；越靠近"价值判断与系统全局"，越需要人。
四、多窗口并行的正确姿势
❌ 错误用法
每个窗口随意使用，上下文混乱，每个任务都半生不熟。
✅ 正确用法：角色隔离 × 流水线并行
┌──────────────────────────────────────────────────────────────┐
│ 你（调度者） │
└───┬──────────────┬──────────────┬──────────────┬─────────────┘
│ │ │ │
窗口A： 窗口B： 窗口C： 窗口D：
产品分析师 前端工程师 后端工程师 QA 测试员
（需求/用 （组件/交互/ （接口/数据 （测试用例/
户故事） 样式实现） 库/缓存层） 边界 case）
复杂项目可再加：
窗口E：DevOps 角色 → CI/CD 配置、Docker、部署脚本
窗口F：架构评审角色 → 专门用来质疑和找漏洞
窗口G：主控窗口（你） → 汇聚所有产出，做整合决策
关键原则：每个窗口要有明确"人设"和单一职责，不要混用。
五、以"做一个新功能"为例的并行工作流
Phase 1：发散并行（同时开跑）
窗口A（需求分析）："你是产品经理，分析这个功能的用户场景、边界情况、可能的歧义点"
窗口B（竞品调研）："搜集 X 类产品的同类功能做法，列出差异点"
窗口C（技术预研）："评估实现这个功能的前后端技术路径，列出风险点和依赖"
三个任务互相独立，可以真正并行。
Phase 2：你来整合（人的核心价值所在）
把三个窗口的产出汇聚到你的大脑，做判断。这一步不能 Agent 化。
Phase 3：收敛并行（前后端同步开工）
窗口A（PRD）：
"基于以下结论，生成完整需求文档，包含用户故事和验收标准"
窗口B（前端实现）：
"你是前端工程师，基于以下接口契约，
用 React 实现 XX 组件，要求：响应式、含 loading/error 状态"
窗口C（后端实现）：
"你是后端工程师，用 Node.js/Python 实现以下接口，
包含参数校验、错误处理、数据库操作"
窗口D（测试用例）：
"基于以下需求，生成完整测试用例，
覆盖：正常流程、边界值、异常场景、并发情况"
窗口E（质疑者）：
"扮演挑剔的 Tech Lead，
分别审查前端代码、后端代码、接口设计，找出安全漏洞和性能隐患"
Phase 4：联调整合
前端产出 + 后端产出 → 你来做接口联调决策
将双方代码扔进同一窗口，让 Agent 找不一致的地方
测试用例跑完后，把 bug 描述交给对应窗口修复
六、并行 Agent 的调度技巧
1. 任务切割原则：输出物要具体
❌ "帮我思考一下这个产品"
✅ "输出一份用户故事列表，格式：作为XX用户，我希望XX，以便XX"
2. 上下文隔离 vs 共享
场景 建议
两个任务互相独立 完全隔离，各自开新窗口
B 依赖 A 的产出 把 A 的结果粘贴进 B 的上下文
需要持续迭代的任务 保持单一长对话，别开新窗口
3. 用一个"主控窗口"做汇总
存放关键决策记录，各子窗口产出在此汇聚，输出最终整合文档。
4. 并行数量的经验值
同时 3-5 个窗口是舒适区，超过 7 个调度成本会超过收益。并行的瓶颈不是 Agent，是你的注意力。
七、更深的视角
传统全栈独立开发者：
我 → 写需求 → 写前端 → 写后端 → 写测试 → 部署上线
（串行，一人扛全部，瓶颈是时间）
多 Agent 全栈开发者：
我（意图 + 架构决策）
→ 产品 Agent（需求/PRD）
→ 前端 Agent（组件/页面） ← 并行
→ 后端 Agent（接口/数据库） ← 并行
→ 测试 Agent（用例/验证）
→ 整合 & 上线决策（回到我）
（并行，我只做不可替代的判断）
核心能力从**"全栈执行"转向"全栈架构意图"**——
你不再需要亲手写每一行代码，但你必须对整个系统的边界、契约、数据流了然于胸。否则 Agent 的产出你无法验收，并行只会产出一堆无法整合的碎片。
一句话：Agent 放大了你的执行力，但同时也放大了你认知的天花板。
整理自与 Claude 的对话 · 2026.04.09
一、层级关系
人
↓ 管理学（组织/激励/沟通）
人（意图/目标层）
↓ 委托工程 / Delegation Engineering
Agent（自主执行层）
↓ harness 工程（Prompt/Chain/Tool）
LLM（原始能力层）
每一层的"驾驭"方式，本质上是上层如何将意图转译为下层能理解的语言。
二、人驾驭 Agent 的方法论：「委托工程」
为什么是"委托"？
管理人用的是激励（人有自己的欲望和利益）
harness LLM 用的是提示（LLM 是无状态的概率机器）
Agent 处于中间地带——有目标感和自主行动能力，但没有真正的"利益"
人与 Agent 的关系，最接近的人类概念就是委托-代理关系。
核心五维度
1. 意图压缩（Intent Compression）
将人的高维、模糊意图，无损压缩成 Agent 可执行的目标。这是比 Prompt Engineering 更高阶的能力——你要先想清楚自己要什么。
2. 边界设定（Boundary Setting）
显式定义 Agent 能做什么、不能做什么、什么情况下需要来询问。这不是技术问题，是授权哲学问题。
3. 可观测性设计（Observability Design）
设计检查点、日志、汇报节奏，让人保持对过程的感知。类似管理学里的"过程控制 vs 结果控制"。
4. 失败模式预设（Failure Mode Anticipation）
Agent 不会"偷懒"，但会"幻觉"、"过度执行"、"误解目标"。需要提前设计兜底机制。
5. 信任校准（Trust Calibration）
随着对 Agent 能力的观察，动态调整授权范围。Agent 不会"成长"，但你对它的理解会加深。
与"管理学"的本质差异
维度 管理人 委托 Agent
动机来源 内在（欲望、价值观） 外在（目标注入）
沟通方式 自然语言 + 情感 结构化意图 + 约束
失败原因 意愿问题居多 理解问题居多
信任建立 时间+情感积累 能力验证+边界测试
扩展性 线性（招人成本高） 指数级（复制部署）
一个有趣的比喻
你是导演，Agent 是演员。 你不需要亲自表演，但你必须把剧本、场景、情绪基调交代清楚。演员再有能力，也演不出导演没想清楚的东西。
这也解释了为什么很多人用了 Agent 反而效率更低——不是 Agent 不够强，而是人没有想清楚自己要什么。
三、在互联网产品研发中用好 Agent
认知前提
多开 Agent 窗口并行，本质上是在做：
把你的"认知带宽"外包出去
单线程的你，变成了一个调度者。调度本身也有成本——并行不是越多越好。
Agent 能接管哪些工作？
按自主程度分层，覆盖产品 + 全栈开发：
高自主（交出去，偶尔 review）
│ 【产品】需求文档初稿、竞品分析、信息聚合
│ 【前端】组件代码生成、样式调整、单元测试生成
│ 【后端】CRUD 接口生成、SQL 编写、数据迁移脚本
│ 【工程】代码注释、变更日志、README 文档
│ 【测试】测试用例生成、边界 case 枚举、Mock 数据生成
│
中自主（你主导，Agent 辅助）
│ 【产品】原型/交互稿讨论、技术方案评审
│ 【前端】复杂交互逻辑、状态管理设计、性能优化建议
│ 【后端】系统设计讨论、接口契约设计、缓存/消息队列方案
│ 【全栈】代码 Review（Agent 找 bug 和隐患）、重构方案
│ 【数据】埋点方案设计、数据分析解读
│
低自主（只做单步辅助）
核心架构决策（微服务拆分、技术选型）
安全敏感设计（鉴权、支付链路）
用户访谈 & 商业判断
上线决策 & 故障处置
规律：越靠近"信息处理与代码生成"，越适合 Agent；越靠近"价值判断与系统全局"，越需要人。
四、多窗口并行的正确姿势
❌ 错误用法
每个窗口随意使用，上下文混乱，每个任务都半生不熟。
✅ 正确用法：角色隔离 × 流水线并行
┌──────────────────────────────────────────────────────────────┐
│ 你（调度者） │
└───┬──────────────┬──────────────┬──────────────┬─────────────┘
│ │ │ │
窗口A： 窗口B： 窗口C： 窗口D：
产品分析师 前端工程师 后端工程师 QA 测试员
（需求/用 （组件/交互/ （接口/数据 （测试用例/
户故事） 样式实现） 库/缓存层） 边界 case）
复杂项目可再加：
窗口E：DevOps 角色 → CI/CD 配置、Docker、部署脚本
窗口F：架构评审角色 → 专门用来质疑和找漏洞
窗口G：主控窗口（你） → 汇聚所有产出，做整合决策
关键原则：每个窗口要有明确"人设"和单一职责，不要混用。
五、以"做一个新功能"为例的并行工作流
Phase 1：发散并行（同时开跑）
窗口A（需求分析）："你是产品经理，分析这个功能的用户场景、边界情况、可能的歧义点"
窗口B（竞品调研）："搜集 X 类产品的同类功能做法，列出差异点"
窗口C（技术预研）："评估实现这个功能的前后端技术路径，列出风险点和依赖"
三个任务互相独立，可以真正并行。
Phase 2：你来整合（人的核心价值所在）
把三个窗口的产出汇聚到你的大脑，做判断。这一步不能 Agent 化。
Phase 3：收敛并行（前后端同步开工）
窗口A（PRD）：
"基于以下结论，生成完整需求文档，包含用户故事和验收标准"
窗口B（前端实现）：
"你是前端工程师，基于以下接口契约，
用 React 实现 XX 组件，要求：响应式、含 loading/error 状态"
窗口C（后端实现）：
"你是后端工程师，用 Node.js/Python 实现以下接口，
包含参数校验、错误处理、数据库操作"
窗口D（测试用例）：
"基于以下需求，生成完整测试用例，
覆盖：正常流程、边界值、异常场景、并发情况"
窗口E（质疑者）：
"扮演挑剔的 Tech Lead，
分别审查前端代码、后端代码、接口设计，找出安全漏洞和性能隐患"
Phase 4：联调整合
前端产出 + 后端产出 → 你来做接口联调决策
将双方代码扔进同一窗口，让 Agent 找不一致的地方
测试用例跑完后，把 bug 描述交给对应窗口修复
六、并行 Agent 的调度技巧
1. 任务切割原则：输出物要具体
❌ "帮我思考一下这个产品"
✅ "输出一份用户故事列表，格式：作为XX用户，我希望XX，以便XX"
2. 上下文隔离 vs 共享
场景 建议
两个任务互相独立 完全隔离，各自开新窗口
B 依赖 A 的产出 把 A 的结果粘贴进 B 的上下文
需要持续迭代的任务 保持单一长对话，别开新窗口
3. 用一个"主控窗口"做汇总
存放关键决策记录，各子窗口产出在此汇聚，输出最终整合文档。
4. 并行数量的经验值
同时 3-5 个窗口是舒适区，超过 7 个调度成本会超过收益。并行的瓶颈不是 Agent，是你的注意力。
七、更深的视角
传统全栈独立开发者：
我 → 写需求 → 写前端 → 写后端 → 写测试 → 部署上线
（串行，一人扛全部，瓶颈是时间）
多 Agent 全栈开发者：
我（意图 + 架构决策）
→ 产品 Agent（需求/PRD）
→ 前端 Agent（组件/页面） ← 并行
→ 后端 Agent（接口/数据库） ← 并行
→ 测试 Agent（用例/验证）
→ 整合 & 上线决策（回到我）
（并行，我只做不可替代的判断）
核心能力从**"全栈执行"转向"全栈架构意图"**——
你不再需要亲手写每一行代码，但你必须对整个系统的边界、契约、数据流了然于胸。否则 Agent 的产出你无法验收，并行只会产出一堆无法整合的碎片。
一句话：Agent 放大了你的执行力，但同时也放大了你认知的天花板。
0 00
驾驭LLM的是Agent，人们将这套方法称为harness 工程，那么驾驭Agent的是人，人驾驭Agent的方法论呢？
人与人之间的协作，称为管理。那么人与Agent间的协作呢？
最近一直在思考这个问题，但苦于学疏才浅，目前还没想出答案。
求教诸位
人与人之间的协作，称为管理。那么人与Agent间的协作呢？
最近一直在思考这个问题，但苦于学疏才浅，目前还没想出答案。
求教诸位
1 00
Gemini给我一下爆论的评价：
软件的本质确实正在从“人机交互介质”演变为“Agent 的函数库”。
这个项目一出，趋势就出来了，未来不管多专业的软件工具，都没必要学了，比如说什么3D渲染软件、建筑构图软件、模具编程软件等等，未来就是面向Agent的CLI类产品和面向人类的GUI类产品，而大多数的任务型产品都不需要GUI。
github.com
软件的本质确实正在从“人机交互介质”演变为“Agent 的函数库”。
这个项目一出，趋势就出来了，未来不管多专业的软件工具，都没必要学了，比如说什么3D渲染软件、建筑构图软件、模具编程软件等等，未来就是面向Agent的CLI类产品和面向人类的GUI类产品，而大多数的任务型产品都不需要GUI。
github.com
0 00