一、从一次HTTP请求说起 以下是一个大体过程，不包含DNS缓存等等细节： 上图展示了一个完整的HTTPS请求过程。对于iOS开发者，理解每个环节的工作原理至关重要，这有助于优化网络性能、解决连接问题

Vibe Coding 在代码生成与协作中的实践与思考 - 向邦宇

自我介绍：

• 多年从事研发者工具开发，包括内部 AI Coding 工具和 Web IDE 工具
• 从 2023 年开始，从内部 Copilot 转型到 AI Agent 方向
• 作为产品提供方，接触了大量内部用户，观察他们如何使用工具以及遇到的问题

演讲选题思考：

• Vibe Coding 概念出现几个月，但并非确定性的东西
• 不同人对 Vibe Coding 理解不同，使用的工具也不同
• 从两个视角分享：用户使用场景和问题、产品提供方的思考和解决方案

演讲结构：

1. 简单介绍业界和内部有哪些 Vibe Coding 工具在使用
2. 用户在使用 Vibe Coding 工具过程中遇到的问题
3. 作为 Vibe Coding 工具核心主导者的思考
4. 国产模型适配过程中遇到的问题和解决方案

---

Vibe Coding 产品形态

当前工具分类的模糊性：

• 大家对 Vibe Coding 工具的理解和分类不够清晰
• 每个工具都有人在用，但缺乏明确的定位

不同 Vibe Coding 工具的主要区别

1. Native IDE（原生集成开发环境）

• 代表产品：Cursor、Cline、阿里 Qoder 等
• 特点：以独立 IDE 形式存在
• 优势：灵活性高，功能完整

2. IDE Plugin（IDE 插件）

• 代表产品：内部 A1 Copilot 等
• 基于现有 IDE（主要是 VS Code 或 JetBrains）的插件形式
• 内部用户使用插件是比较主流的习惯
• 灵活性可能没有 Native IDE 那么高

3. Web IDE

• 入口在浏览器上
• 整个执行在远端容器里，可能是沙箱环境
• 优势：
  • 解决信任问题和云端执行的安全问题
  • 更适合协作：多个同学可以在同一个 Web IDE 里进行同步协作和分享
  • 跨平台支持

4. CLI 命令行工具

• 代表产品：Copilot CLI
• 最初没想到会受欢迎，但实际上非常受主流研发欢迎
• 未来可能在被集成的方式（如 CI/CD）中执行一些自动化任务
• 在这种场景下会有更高的可能性

---

内部 Vibe Coding 工具的使用实践

A1 Copilot（依托于 IDE 的Wibe Agent工具）：

• 内部协作多年的产品
• 用户规模：数万用户，每周几千周活
• 主要使用场景：
  • 代码生成
  • Bug 修复
  • 代码分析
• 用户分布：后端场景渗透率较高，前端用户更倾向使用 Native IDE（如 Cursor 或 Qoder）

AI Agent（异步容器执行的 Agent 工具）：

• 以 Web 端发起的容器内运行的异步任务工具
• 核心特点：用户通过自然语言发起任务
• 在异步容器里拉起 Agent，Agent 自己调用工具（搜索工具、文件读写工具、Shell 工具等）
• 用户角色更加多元：
  • 主要用户：后端开发
  • 其他用户：测试、前端、算法、产品、运营、设计、运维等
• 任务类型丰富多元：
  • 代码分析
  • 代码改动
  • 单元测试
  • 代码生成
  • 文案方案调研等

---

工具尤其是 Agent 带来的效率提升

数据观察（从 4 月份开始的 Agent 模式）：

代码提交量的显著提升：

• 蓝色线：高频用户（使用 Agent 模式）
• 橙色线：其他用户
• Agent 模式下，高频用户的每日代码提交行数有非常大的提升
• 到 9 月份，高频用户每天提交 540-560 行代码，其他用户只有 400 多行
• 至少从定量指标看，Agent 模式对提效肯定有帮助

用户分层现象：

• Top 10% 用户的代码提交量是其他人的两倍
• 认为 Agent 对人的提效可能大于两倍，因为大量工作在协同、开会等非编码环节
• Top 10% 用户的 Copilot 消耗占整体消耗的 80%

AI 新的应用场景：

• 单元测试由 AI 生成的提交代码占比越来越高
• JDK 升级、NPM 包升级、SDK 升级等工作已经可以由 AI 完成
  • JDK 11 及以上版本升级场景，内部基本全部交给工具处理
• 数据分析、数据整理工作部分交给 AI
• 传统必须由人完成的任务现在由 Agent 完成：
  • 测试过程中的截图
  • 压测过程中的重复任务
• 过去成本过高无法做的事情现在可以做：
  • 一次发布是否会引起其他相关系统故障
  • 每一行代码对其他系统的影响分析

---

用户使用 Vibe Coding 工具遇到的问题

用户情绪问题

AI 表现不足导致的崩溃：

• 后台日志中大量用户抱怨”AI 太笨了”等激动的话
• 用户反复删除代码、修改代码的行为
• 无论公司内部还是社区，都能看到用户因 Agent 能力不足而崩溃

GitHub 上的”八荣八耻”提示词：

• 用户分享给 Agent 的提示词规范
• 例如：”以不能修改原始代码为荣”等

5.2 代码质量问题

我们看到的 Vibe Coding 的问题是多方面的

1. 代码风格不一致
   • 生成的代码质量和风格差异较大
   • 在存量仓库里写代码时，可能以自己的风格编写，而非遵循项目规范
2. 边界条件处理不完善
   • 对复杂业务逻辑的边界情况处理不够充分
3. 性能缺陷
   • 生成的代码存在性能问题
4. 安全漏洞
   • SQL 注入类漏洞严重
   • 斯坦福研究表明：AI 生成代码中注入类漏洞比例约 45%
   • 其他安全问题：
     • 接口注入
     • XSS 攻击
     • 逻辑错误
     • 边界条件处理错误
     • 异常控制

• 数字越界

代码逻辑自洽问题

• AI 在代码生成过程中会有非常多的”自洽”
• 案例：数据去重函数及其对应的单元测试
  • 测试通过率 100%
  • 针对代码做了单测
  • 但如果让 AI 同时写单测和业务逻辑，无法保证质量
  • 会出现”自己和自己对话”的情况
• 建议：至少有一项（单测或业务逻辑）是人去 review 的

调试和维护困难

调试时间增加：

• 使用工具后，调试时间增加 30%-50%

1. 黑盒问题
   • Vibe Coding 更倾向于黑盒代码逻辑生成
   • 虽然最后会让人确认代码 diff 才能提交
   • 但生成过程是黑盒，不会有人认真看每一条
   • AI 生成代码像”黑魔法”，出问题时完全不知道如何下手
   • 技术债务越来越深
2. 上下文理解局限
   • 存量任务的业务逻辑可能积累十几年
   • 有些代码为什么要这么写？有些代码是否能去掉？对 AI 来说都很困难
   • Vibe Coding 工具缺乏全局思维
   • 生成的代码模块化程度不够，代码耦合度很高
   • 解决方案：RepoWiki, DeepWiki 等方案
3. 缺乏可追溯性
   • Vibe Coding 一次性生成大量代码
   • AI 无法知道：是新需求导致代码写错，还是一开始就写错了
     • 缺乏版本管理和版本概念
     • 一次生成代码出错后，不知道从哪个地方回滚
   • 现有方法：
     • 每次改完测试通过后提交一个 commit, 下次可以从这个 commit 回滚
     • 使用 Cursor 等回滚工具
   • 但仍然缺乏可追溯性，用户无法做版本管理，无法回到正确状态，只能重来

Vibe Coding 工具普遍不会使用常用的调试工具

• AI 普遍不会使用人类常用的调试工具
• 传统”古法编程”中，开发者大量使用 Debug、断点等工具
• 浏览器上也可以做调试
• 但让 Vibe Coding 工具使用这些调试工具去找堆栈、找问题非常困难
• 工具能力缺失导致的问题：
  • AI 只能打大量的 console.log, 让用户执行完后，把 log 或控制台的报错、打印信息再粘贴给工具
  • 需要人介入
  • 不是高效的模式
• 大模型的调试手段比较单一，传统调试方法无法被大模型用起来

Vibe Coding 工具本身存在的问题

1. 稳定性和成功率：

• 最大的问题
• Vibe Coding 工具执行时间很长（30 秒到 5 分钟）
• 不是每次都能成功
• 失败原因：
  • 模型问题
  • 工具反馈不对
  • 某些工具出错
  • IDE 本身不稳定
• 用户体验：用过一次发现不稳定，在时间紧、任务重时就不会再使用

2. 交互界面设计问题：

• 大量 Vibe Coding 工具产品频繁改版，功能丢失
• 案例：Devin
  • 改版后用户找不到原来的功能
  • 工具里增加越来越多功能（剧本、MCP 市场、知识引入等）
  • 现在再看又没有了
• 交互界面频繁改版

3. 沟通和交互障碍：

• 理解能力不足：AI 无法完全理解用户意图，需要反复确认
• 不同场景下确认的必要性不同：
  • 复杂任务：需要确认（如 SpecCoding - 先建需求、生成设计稿、再让 AI 做）
  • 简单任务：不需要确认，需要 Agent 自由探索

4. 长链路任务执行能力不足：

• 无法维持长期上下文
• Agent 大模型的 token 有上限
• 上下文过长时，记忆和召回能力不足

5. 工程工作流程中断：

• 大量工具（IDE, CLI, Web Agent 等）各有擅长领域
• 无法让用户在相同流程或上下文窗口里解决问题
• 案例：在 IDE 里做一件事,需要切换CLI, 重新给 Agent介绍诉求和需求
• 导致用户在不同工具间频繁切换

成本问题

成本问题导致各方不满意：

1. Agent 的 Token 消耗巨大：

• 代码补全场景：
  • 调用频次高
  • 单次消耗约 4000 Tokens
• Vibe Coding 任务：
  • 单次消耗百万级甚至千万级 Tokens
  • 原因：
    • 上下文更长
    • 交互轮次多（几十上百次）

2. Vibe Coding 加速带来的技术债务：

• 技术债务反而对 Agent 提出更高要求

3. 成本上升导致产品方频繁调整计费逻辑：

• 产品方（Cursor、Qoder 等）频繁切换计费逻辑
• 没有任何一款产品敢保证包月或无限次使用
• 成本压力导致产品设计不断调整：
  • 压缩上下文
  • 削减能力
• 恶性循环：
  • 成本降低 → 成功率下降 → 用户多试几次 → 成本又上升
• 产品方为了活下去压缩成本，但效果变差，用户要多试几次，成本又上去
• 使用闭源模型（Claude、GPT-4、GPT-5）后成本难以下降

5. 缺乏规模效应：

• 大模型应用有规模效应，但不明显
• 不存在”用户规模越大，成本就越低”的效应
• Token 成本是固定的

---

产品自身也遇到的挑战

产品的演进导致模型成本越来越高

Token 消耗的演进：

1. 代码补全场景：

   • 单个任务：约 4000 Tokens 输入
   • 输出：20-30 Tokens

2. Chat 模式：

   • 单个任务：约 1000+ Tokens 输入
   • 输出：约 4000+ Tokens

3. 单个 Agent 模式（IDE/CLI）：

   • 单个任务：约 10 万级 Tokens

4. 具备独立容器的 Vibe Coding Agent：

   • 能广泛使用各种工具
   • 实现各种内容、各种任务类型
   • 单个任务：百万级 Tokens

5. 未来的架构（Cursor, TRAE 等）：

   • 单个任务：可能上亿 Tokens

产品设计的两个同等重要目标：

1. 用户满意度
2. 成本控制能够匹配用户规模

产品形态的问题

1. 产品界面区分度不够：

• 无论 Chat 产品还是 Vibe Coding 产品，都处于摸索阶段
• 模型能力变化使产品不断变化
• 所有产品都是一个对话框（ChatGPT、DeepSeek、AI 产品）
• 用户难以区分不同产品的区别

2. 用户缺乏引导：

• 给用户一个对话框，但用户不知道应该输入什么
• “Prompt Free”现象
• 不同工具有不同使用场景，但用户往往一刀切
• 用户印象中产品应该能做什么，但试用后发现达不到目标
• 功能学习成本高，使用频次低
• 留存率非常低（Devin 等 Vibe Coding 工具都存在这个问题）

3. 缺乏一站式功能闭环：

• 无法在一个产品里解决所有问题
• 案例：
  • 一个 Vibe Coding Agent 能解决复杂产品问题
  • 但又能解决小白/初学者问题
  • 小白面临的问题不仅是代码能否写完，还有发布、部署、调试等
• 发展过程中存在各种调整

安全风险问题

案例 1：Cursor 删除本地代码：

• Cursor 把用户本地代码删掉
• 类似的小 case 还有一些

案例 2：Anthropic Claude 被劫持：

• 今年出现好几次
• Claude 被劫持后，让 Vibe Coding 工具在用户网络里探测漏洞
• 写代码把敏感信息暴露出来

内网使用的安全考虑：

• 不能完全相信 Vibe Coding 工具
• 供应链攻击问题
• 开源代码的风险：
  • 很多人在开源社区里种木马
  • 不注意可能拉取到的 SDK 或代码存在漏洞
• Vibe Coding 工具对代码和电脑有基本控制权
• 能够自由探索，找到系统漏洞并攻击

---

Agent 建设过程中一些经验分享

All In One 架构导致成本几句上升

最初的 All In One 架构问题：

• 建设 Vibe Agent 时采用的架构就是一个输入框
• 外围：MCP 工具、knowledge、Playbook 一些剧本
• 最外围：场景图（数据处理、后端开发、前端开发、代码浏览、风险管理等）

All In One 架构的问题：

1. 所有工具都放入沙箱
2. Context 特别长，无法压缩成本
3. 最开始一个任务调用 Claude 模型需要几百块钱成本，非常高
4. 任务成功率低
5. All-in-one 时，所有工具和 knowledge 放在一起：
   • 成本特别高
   • 占用特别长
   • 消耗大量资源
6. 很难针对不同场景进行调优
   • 案例：与 Bolt 等产品对比，发现它们在前端场景有很好实现
   • 但自己的产品在前端场景做得不够让人满意

知识和数据建设

1. 代码数据建设
   • 通过建设 DeepWiki、RepoWiki、Embedding 数据库
   • 增强对整体代码库的搜索、理解和搜索能力
2. 研发行为数据
   • 构建、CI/CR、发布、监控等行为数据
   • 背靠整个集团内部平台（发布平台、代码平台等）
   • 建立代码数据和需求数据与这些行为的组合
3. 文档知识库
   • 问题：文档知识库无法被Agent 直接用起来
   • 原因：
     • 文档可能过时
     • 前后矛盾
     • 图文混杂
     • 存在错误信息
   • 直接把这些信息丢给 Agent 会产生误导
   • 解决方案：
     • 不用传统 RAG 技术解决
     • 建立中间层
     • 面向 Agent 的数据处理协议
4. 开发者知识沉淀
   • 很多知识不在文档里，也不在代码里，在开发者脑子里
   • 需要产品设计帮助用户沉淀这些知识
   • 不是靠任何东西生成，而是靠人来写

Agent 对上下文记忆处理的几个核心

记忆处理机制：

• 写入
• 提取
• 压缩
• 隔离

1. 任务管理和技能交互
2. 文件操作
   • 读写编辑
   • 文件管理
3. 命令行和执行监控
   • Agent 可以执行命令行
   • 有些命令是长耗时的
   • 如何监听命令结果
   • 超时后如何 kill 掉
4. 浏览器自动化工具
   • 执行网页操作
   • 使用 Playwright 等方式点击页面, 帮助登录或解决交互问题
5. 手机相关工具
6. 多媒体工具
7. 开发工具
   • 将用户写的代码部署、调试到指定地方
8. 协作工具
   • 团队协作
   • 任务分享给其他人
   • 基于任务继续协作
9. 高级功能
   • 并行执行优化
   • 网络搜索

成本控制方案

Token 消耗优化历程：

• 最开始：400-1000 万 Tokens/任务
• 意识到这是最严重的问题
• 通过各种设计和操作降低 Token 成本

国产模型适配实践

为什么要拥抱国产开源模型

国外闭源模型的风险：

1. 成本高
       - 复杂问题往往很长
       - 能让 Agent 在复杂任务下跑起来的模型非常贵

2. 隐私问题：
       - 闭源模型存在合规风险

3. 被限流和被降质：
       - 即使用同一个供应商的模型
       - 不同时候表现也不一样
       - 有时会出现格式不对、陷入循环等问题

4. 国外模型的备案问题：
       - C 端用户使用可能存在备案问题

国产模型在短链和长链任务的问题

短链任务表现已经很好
长链任务还存在一些问题

国产模型存在的问题

1. 死循环问题：
       - Agent 有很多选择和路径
       - 执行过程中可能陷入某种循环
       - 反复出不来
       - 案例：反复打开一个文件、反复执行某一项命令
2. 格式遵循能力不足：
       - 常见问题：XML 标签格式不准确
       - 前后无法匹配
       - 导致无法被正确解析
       - 容易失败
3. 指令遵循问题：
       - 在高达百万 Token 的上下文下
       - System Prompt 里给的规则
       - 模型如果没有被训练到，很难使用这些工具
       - 运行过程中会忘记某些指令
4. 全局智能问题：
       - 观察发现模型存在全局任务理解能力缺陷
       - 容易陷入”一步一步看”的情况
       - Token 消耗大
       - 步骤时间长

解决方案

1. 针对稳定性问题：
       - 主流模型的切换和重试
2. 应对速度慢和 Infra 稳定性问题：
       - 当模型输出被截断时
       - 做一些有效输出或续写设计
3. 健康检查和死循环检测：
       - 在 Agent 里做检测
       - 针对重复执行某个指令的死循环场景
       - 相同错误点的无限循环问题
       - 陷入明显错误逻辑时能够检查到
4. 格式检查和修复：
       - 检测到不完整标签时
       - 通过堆栈方式自动补齐缺失的结束标签来修复

重试机制

主备切换

工具的解析与自动修复

成果

• 在内部基本已经把国外模型全部去掉
• 内部全部使用国产模型
• 实时检测任务是否进入死循环
• 进入死循环后进行干预：
  • 把后面任务执行截掉
  • 对任务总体做 summary 压缩
  • 让它继续往下走

模板化设计解决 Prompt Free 问题

Prompt Free 问题

普通用户/小白用户面临的问题：

1. 不知道产品能干什么
2. 知道要干什么，但不知道如何提要求
3. 不知道在产品里使用什么样的工具或知识
4. 导致任务成功率很低
5. Token 消耗也很大

模板化解决方案:

• 某个垂直任务，有人通过很多探索做成功了（很满意）能否把它抽象成一套模板？
• 针对不同垂直场景不断积累这些模板
• 使成功率变高，Token 消耗变低
• 面对对话框时给用户一些灵感

模板的本质：

• 一套工具的组合
• 一个知识的组合

使用流程：

1. 用户看到对话框
2. 先选一个模板
3. 再执行任务

效果：

• 约 50% 的用户任务现在都用了模板
• 使用模板后任务成功率提升

总结下：

• 固化 Prompt
• 固化工具
• 固化知识
• 形成模板后，用户生成任务时先选模板，再执行

---

架构上的更多创新

长上下文任务的问题

案例：

• 先做深度调研
  • 要先写一个网页
  • 再写一个 PPT

• 单 Agent 的问题：
  • 上下文非常长
  • 需要频繁做 summary、压缩
  • 裁剪工具输出
  • 才能保证任务质量高
• 没有子 Agent 之前的主任务需要频繁做所有琐事
  • 从上到下每个步骤：
    • 调网页
    • 打开网页
    • 把网页内容写下来
    • 做 summary
    • 写 PPT
    • 写网页
  • 项目越来越长, 任务执行完成率非常低, 效果也不好

Agents 拓扑解决方案

灵感来源：

• Manus 1.5, 提出 Agents 拓扑概念
• Agent 本身也是一个工具

实现方式：

• 假设有一个 Deep Research 工具，做得很好
• 可以自己做网页搜索、做 summary
• 主 Agent 只要调用它就够了
• 把这部分工具抽象出来，成为一个工具

演进路径：

• 过去：Function Call
• 后来：LLM Call
• 现在：用 Agent 来做
• 把一个 Agent 当作一个工具去做子任务

一、.visualEffect 是什么？ 一句话概括： 它允许你： 拿到视图在屏幕中的真实几何位置 根据滚动位置 / 距离中心点 / 是否即将离屏 对视图做 缩放、模糊、位移、透明度 等视觉变化 👉

1. 为什么需要 async/await 在移动开发里，“并发/异步”几乎无处不在：网络请求、图片下载、文件读写、数据库操作……它们都有一个共同特点： 耗时（如果你在主线程里死等，会卡 UI） 结果稍

概述 在 Objective-C 开发中，协议（Protocol）是实现接口抽象和多态的重要机制。然而，编译器对协议实现的检查有时存在局限性，特别是在动态运行时和复杂的继承关系中。本文将介绍一个完整的

在 Objective-C 中，字典对象（Dictionary）用于存储键值对（Key-Value Pairs）。它类似于其他语言中的 Map、Hash 或关联数组。

在 Objective-C 中，分类 (Category) 和 协议 (Protocol) 是实现代码解耦、扩展功能和组件化开发的核心工具。

复杂度分析（Complexity Analysis）是计算机科学的核心理论之一，由Donald Knuth在《计算机程序设计艺术》中系统阐述，后经Robert Sedgewick、Thomas H..

前言 1. 为什么需要配置开发环境？ 良好的开发环境是学习数据。根据Stack Overflow 2023年开发者调查和IEEE Software Engineering Standards：....

目前手游 iOS SDK 普遍使用手动集成方案。但随着近几年出海热，SDK 需要集成大量第三方库，改用 CocoaPods 集成会方便很多。

数据结构与算法是计算机科学的基础，是软件工程师的核心技能。本文详解 工业界应用 学习资源与工具 学习建议等知识

前言 配置Podfile时，如果结合一些优化选项，能大大的提升开发效率。本文是为使用cocoapod管理组件库提供一个podfile优化设置的最佳实践。 🚀 一、构建性能优化类 1. disable_

智能体时代的强化学习：AReaL框架与Agent最佳实践

以 RL 打造 Agent

两个核心”暴论”

1. Agent是未来五年AGI时代最重要的事。
2. 强化学习是构建Agent最关键的技术。

强化学习的历史发展与突破

强化学习的早期认知

大多数人对强化学习的认知来源于：

• AlphaGo：DeepMind用强化学习训练围棋智能体，击败李世石和柯洁
• OpenAI打Dota：2019年用强化学习击败两届世界冠军OG
• 其他游戏AI：腾讯打王者荣耀、星际争霸等

当年的强化学习智能体主要都是打游戏的，与大模型驱动的AGI时代似乎没有太大关系。

强化学习与大模型的结合转折点

2020-2022年的关键变化

GPT-3 API的问题：

• 2020年OpenAI推出GPT-3 API时存在严重问题
• 例子：输入”explain the moon landing to a six year old in a few sentences”
• GPT-3会输出重复内容：”explain the serious gravity, explain the serious relative, explain blah blah blah”
• 原因：大模型训练基于next token prediction，但用户给的是指令（instruction following problem）

注: “Next Token Prediction”（下一个 token 预测）是大语言模型（LLM）的核心机制。简单来说，它的意思是：给定一段文本的前面部分，模型预测接下来最可能出现的“token”是什么。

RLHF技术的突破：

• OpenAI花了两年时间解决这个问题
• 2022年推出InstructGPT，采用RLHF（Reinforcement Learning from Human Feedback）技术
• 方法：找人标注数据，判断哪些回答遵从指令，哪些不遵从
• 训练奖励模型，然后用强化学习让模型探索获得最高分数的回答
• 结果：同样的基座模型，有没有强化学习决定了好用还是不好用

注: RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是一种用于对齐大语言模型（LLM）的技术。它的核心目标是：让模型的输出更符合人类的偏好、价值观和意图，而不仅仅是“语法正确”或“统计上常见”。

强化学习推动AGI产品发展的三个阶段

• 第一阶段：2022年ChatGPT
  

  • 由RLHF技术引爆，让大家第一次感受到AGI能力
  • 强化学习捅破了窗户纸，让AGI能力真正可用

• 第二阶段：2024年推理模型（Reasoning Model）
  

  • 也称为思考模型（Thinking Model）
  • 特点：给模型一个问题后，它会先想一会，输出大量thinking token
  • 例子：帮我算个24点，思考模型(比如 deepseek)会先在”草稿纸”上写10分钟(输出thinking token)，然后给答案
  • 技术：也是强化学习驱动，模型自己探索如何思考, 思考什么，自己判断答案对不对, 也就产生了推理模型
  • 训练范式与RLHF类似，但判断标准可能不同

• 第三阶段：2025年Agent模型
  

  • 基于Agent的强化学习技术
  • 代表产品：ChatGPT Deep Research 等

Agent产品的发展与特点

成功的Agent产品案例

• ChatGPT Deep Research
  • 2024年第一个比较成功的Agent产品
  • 功能：给它一个topic，帮你做研究
  • 工作流程：
    • 花很多时间思考
    • 调用工具，在网上搜索很多topic
    • 可能运行20分钟到1小时
    • 最终给出非常详实、有大量引用和reference的报告
• Manus /ChatGPT Agent / Kimi Agent Mode
  • 功能更丰富，可以帮你做PPT
  • 在Sandbox（沙盒）环境中工作：
    • 读取PDF文件
    • 在阅读器中打开PDF
    • 存储PDF文件
    • 编辑和创建文件
    • 在虚拟机中进行各种操作

Agent能力的演进

从Deep Research到Manus的发展体现了Agent能力的进步：

• Deep Research：除了对话，可以调用搜索工具、浏览器工具，将信息放在Context Window中处理
• Manus：更进一步，加上了Sandbox工程AI，相当于有了自己的电脑

AI的能力演进：

1. 有了脑子（大模型）
2. 有了草稿纸和笔（Context Window）
3. 有了一台自己的电脑（Sandbox）

产品发展趋势分析

• 用户交互的变化
  • ChatGPT时代：需要很长的prompt，详细描述要做什么
  • Agent时代：用户说的话越来越抽象，越来越少
• AI能力的变化
  
  • ChatGPT：1秒钟给出文本输出
  • Thinking Model：1-2分钟思考后给出答案
  • Agent Model：1小时处理复杂任务，主动行动
  • 未来: 牛马 AI, AI一直在做事, 主动帮人安排
• 从Reactive到Proactive的转变
  
  • 传统模式：用户告诉AI做什么（Reactive）
  • 未来趋势：AI主动准备，告诉用户要不要（Proactive）
  • 例子：OpenAI的ChatGPT Plus每天主动推送早报等内容

未来愿景

理想的AI助手具体技术化来讲：

• 信息模糊处理：人很难把想做的事讲清楚
• 个性化：每个人的需求不一样
• 主动规划：主动安排和执行任务
• 提前工作：AI不需要休息，可以一直工作

什么是好的 Agent 团队

• 组织 AI 化
• 技术栈完整
• 持续高速0-1 创新, 高效迭代

为什么Agent需要RL(强化学习)

市面上Agent 有各种 framework, 这些框架主要通过拖拉拽的方式构建Agent工作流，但对于复杂的Agent问题存在局限性。

强化学习解决的三大核心问题

问题一：处理不确定性和冲突信息

• 案例：阿里CTO是谁？
  

  • 阿里和蚂蚁有很多子公司，每个公司都有CTO
  • 搜索”蚂蚁CTO”会得到很多不同的结果
  • 需要AI去理解和判断才能做出正确回答

• 案例：退票问题
  

  • 用户说”退票”，但上下文可能很不确定
  • 退什么票？需要AI主动提问澄清

问题二：长期记忆和个性化

• 案例：美团小美推荐
  
  • 我说”要吃晚饭，要清淡点”
  • AI推荐白灼生菜等蔬菜
  • 但我从来不点蔬菜，喜欢吃肉
  • “清淡点”对我可能意味着”清淡点的肉”
  • 需要从很长的记录中挖掘个性化信息

问题三：海量工具和模型选择

• 案例：Reddit上的模型组合使用
  
  • Claude写代码很聪明但Context Window短且贵
  • Gemini写代码不够聪明但Context Window长且便宜
  • 用户发现可以用Claude调用Gemini：让Gemini读代码，然后扔给Claude写
  • 相当于”聪明的人指挥体力无限的傻子干活”
  • 这种最佳实践应该由AI自己探索出来，而不是人工定义规则

强化学习的统一解决方案

强化学习可以用统一的框架解决这些复杂问题：

• 让AI在环境中自己探索
• 涌现出处理复杂任务的能力
• 比规则和Workflow更灵活和强大

搜索智能体案例深度分析-看似简单的问题实际很复杂

问题案例：伦敦奥运会中国金牌数

表面上的简单：

• 问题：伦敦奥运会中国拿多少块金银铜牌？
• 看起来很简单，百度搜索就能找到答案
• 官网显示：中国队拿了38块金牌，是2012年历史第二高的成绩

实际的复杂性：

• 正确答案应该是39枚金牌
• 原因：2012年伦敦奥运会女子田径竞走项目
• 中国派出三位选手，当时拿了第3、4、5名
• 后来第1、2名被查出禁药，被剥夺奖牌资格
• 11年后（2023年），中国选手获得了补发的金牌
• 所以现在问中国奥运会金牌数，答案应该是39枚

现有产品的表现
测试了多个产品：

• DeeSeek：搜出38枚金牌
• ChatGLM：38枚金牌
• ChatGPT：搜到了39枚金牌的信息，说”有一些资料显示数字略有差异，39枚金牌”，但最后结论还是38枚金牌（因为大量信息都是38枚）
• ChatGPT Agent Mode：会答对

传统方法vs强化学习方法

传统Multi-Agent System方法

需要构建复杂的多智能体系统：

• 搜索Agent
• 核查Agent
• 调用知识的Agent
• 检验Agent
• 需要很长很复杂的流程

强化学习方法

极简设计：

• 一个模型
• 两个工具：搜索工具 + 点击网页工具
• 让模型在环境中循环探索

实际效果：

• 第5轮搜到39枚金牌的新闻
• 开始疯狂核查
• 经过60多轮迭代
• 最终确定正确答案是39枚金牌
• 还具有泛化能力，可以添加更强的工具
• 32B模型可以在准确度上超越商用产品

强化学习的两大优势

1. 简单: 简化Agent的workflow, 不需要复杂的多智能体系统设计
2. 涌现: 让AI涌现出复杂的多步推理能力, 通过探索自动获得复杂能力

Agent RL 的核心难点

强化学习面临的三大挑战

要做好强化学习，必须解决三个问题：

1. 缺Infra和算法：强化学习算法运算速度很慢很慢
2. 缺数据：训练数据的获取和质量, 强化学习的数据是很缺很缺德, 预训练数据可以在网上扒, 但强化学习的数据不太能直接网上扒
3. 缺环境：Sandbox等执行环境的构建

如何全栈解决 Agent RL 的难点

Infra(基础设施)和算法优化

速度慢的根本原因

强化学习的三个流程：

1. 生成：让模型在环境中交互生成数据
2. 评分：用奖励模型计算奖励
3. 训练：放到训练集中训练

复杂性分析：

• 涵盖了三种完全不同的计算模块
• 预训练只有训练，SFT只有训练，评测只有评测
• 强化学习包含：训练、评测、在线生成、Sandbox等
• 是一个算法编排了多种完全不同计算模式的复杂系统

算法与系统协同设计的重要性

为什么需要协同设计：

• 强化学习算法创新很容易碰到系统瓶颈
• 四个系统模块(推理/训练/环境/算法整合)中任何一个打满都会成为瓶颈
• 强化学习算法很容易打到系统瓶颈

团队组织建议：

• 做算法的同学需要了解Infra
• 做Infra的同学需要了解算法
• 最好能坐在一起工作, 这是加快创新节奏的重要方式

具体的性能瓶颈

搜索智能体的统计数据：

• 平均搜索时间：要调用 google 搜索引擎, 一个batch 5-10分钟
• 长尾效应严重：特别难的prompt需要1-2小时
• 问题：如果每个batch都要等最慢的那个，一天24小时只能更新12-24次
• 导致大量CPU/GPU等待时间

AReaL的解决方案：异步架构

核心思想：推理不能等

• 一部分卡不停地做推理，没有等待
• 训练也没有等待，有数据就训练
• 中间用随时更新参数的方式
• 如果推理到一半需要更新参数，就停下来更新，然后用新参数继续rollout
• 实现完全没有系统资源浪费

技术创新：

• 系统上做异步调整
• 算法上做相应调整以适应异步更新
• 在Agent场景上实现5倍加速，且没有效果损失

训练数据问题

数据稀缺的问题

• 预训练可以直接从网上获取数据
• 强化学习的训练数据不能直接从网上获取
• 一般问题都跟简单, 用户提出的复杂问题很少，难以挖掘复杂问题的测试集

数据合成解决方案

Agenic合成数据方法：

1. 从网页上获取答案（搜索比较简单，从答案开始）
2. 从答案构造问题
3. 不断让问题变得更加复杂
4. 评估问题，保证问题和答案匹配正确
5. 难度检查：问题不能太难也不能太简单，需要适合强化学习自我提升的难度
6. 构造出适合的训练数据

开源贡献：

• 数据、代码和脚本都已开源
• 帮助社区训练更好的Agent产品

环境构建 - Aworld 项目

• 主要是Sandbox等执行环境的构建
• 未来会开源更多的Sandbox项目
• 帮助大家训练更好的Agent产品

让更多人用 RL 训练更好的 Agent

AReaL团队发展历程与经验总结

团队发展时间线

• 2020年：开始做开源学术项目，多智能体强化学习框架
• 2022年：第一个大规模游戏场景可用的强化学习分布式训练框架
• 2023年：当时最快的RLHF框架
• 2024年：开始做AReaL，专注Agent AI

技术循环的有趣观察

回到原点的循环：

• 2025年的强化学习与当年打游戏很像
• 有个大模型在”玩游戏”（Sandbox可以是浏览器或电脑）
• 遇到的问题与打游戏类似：有黑盒环境，很慢，不能修改游戏规则
• 五年后技术回到了当年的原点
• 系统设计和算法技术都有循环

重要的经验教训

技术需要两个条件才能发挥价值：

1. 技术需要对的时间
   • 强化学习如果在2022年以前，大家很难感知到价值
   • 不是大家的错，而是技术没有在对的时间被感知
2. 技术需要好的产品承载
   • 强化学习技术如果不是因为ChatGPT、RLHF、Agent model，大家可能也感知不到
   • 技术本身可能没有价值，需要好的产品去承载才能发挥更大价值

团队理念：

• 技术一定要产品化, 所有技术同学都应该尽可能把技术产品化
• 希望创造能够实现AGI的Agent产品, 成为支持产品持续进化的平台

总结与展望

核心观点回顾

1. Agent是AGI时代最重要的事情：从产品发展趋势和技术演进可以看出Agent的重要性
2. 强化学习是Agent的最关键技术：能够统一解决Agent面临的复杂问题，让AI涌现出复杂能力

技术发展趋势

• 从简单的对话模型到能够主动行动的Agent
• 从Reactive到Proactive的转变
• 从规则驱动到强化学习驱动的智能涌现
• 算法与系统协同设计的重要性日益凸显

未来展望

• Agent产品将越来越智能和主动
• 强化学习技术将在Agent领域发挥更大作用
• 需要更好的基础设施、数据和环境支持
• 技术产品化是实现价值的关键路径


商汤科技”从炫技到实用：AI 产品价值闭环”演讲大纲及内容整理

AI 企业落地现状分析

MIT 调研数据

• 95% 的企业 AI 落地失败：MIT 调研显示，过去一年多超过 95% 的企业侧 AI 落地项目失败，只有 5% 的企业在 PNL（损益表）上看到了 AI 的价值
• 技术与企业节奏错配：技术发展过快，企业在节奏和决心上存在错配
• 自建效率低下：企业自建 AI 解决方案的成功效率是外部专业供应商的 1/3
• 前台应用效果不佳：虽然期望 AI 在前台工作带来价值，但现在证明有效的主要是后台自动化
• 员工与管理层利益冲突：CEO 希望 AI 降本增效，但员工担心失业，会自己采购 AI 工具而不使用企业内部的 AI 系统

企业 AI 探索历程

• 早期阶段：全参数微调、预训练（算力要求高）
• 中期发展：微调、强化学习
• 当前状态：不再关注模型本身，转向各种 Agent（营销 Agent、客服 Agent、数据 Agent 等）

智能体（Agent）的定义与现状

Gartner 报告对智能体的严格定义

• 智能体洗白现象：许多低代码产品、RPA 产品重新包装为智能体概念
• 非智能体的产品：
  • 模型本身不是智能体
  • RPA 不是智能体
  • 仅结合 RAG 的产品不是智能体
  • 简单的意图分发 chatbot 不是智能体

真正智能体的核心特征

• 完整闭环：感知 → 思考 → 决策 → 行动 → 反思
  • 思考：面向任务主动选择规划路径
  • 反思：过程中发现问题及时修正
• 企业客户不关心技术黑盒，只关心端到端的解决方案和确定性的高精度结果

C 端与 B 端的差异
Agent 看上去效果很好, 但是要抽卡, C 端声量高，但企业侧落地率低

• B 端要求：
  • 确定性、高精度场景
  • 不接受”抽卡”式的随机结果
  • 需要在高精度下解决企业问题

大模型解决的核心问题

• 开放式场景：大模型主要解决开放式场景问题
• 确定性场景不适用：规则明确、容错率低的场景不建议使用大模型, AI 无法生成100%正确的答案
• 传统信息化的局限：如果场景非常确定，传统企业信息化建设已能满足需求, 不需要用大模型, 但AI 可以改善交互体验，但会带来精度下降和不确定性, 是不符合企业要求的, 看下来目前 AI 对企业侧还没有完全 ready

市场机遇与政策支持

政策红利

• 人工智能+ 政策：类比 10 年前的”互联网+”政策，催生了 BAT 等头部企业
• 具体目标：2027 年实现 70% 以上的终端智能和智能体应用
• 市场空间：政策落地后将有配套实施政策，市场需求旺盛
• 供给不足：供给侧还无法完全解决市场需求, 有巨大的空间
• 蓝海机遇：怎么为企业和个人提供巨大的商业化价值

不同层级的价值需求

企业 AI 价值价值是什么?

• 企业层面：管理价值，战略部署实施，标准程度低但企业价值高
• 团队层面：协同价值，解决部门间沟通协同、部门墙等问题
• 个人层面：降本增效，包容程度高但企业价值低

从下到上, AI 对企业的价值越高; 从上到下, 标准化程度越高

• 效率瓶颈：企业效率瓶颈不在个人，而在部门间协同
• 沟通策略：与不同层级人员沟通需要针对其关注点

价值实现的挑战

中国开源模型发展迅速,许多企业开始自己部署开源模型（如文心一言、千问等）

• 采购额度低：上半年公开招投标的大模型一体机采购额仅 1400 万
• 热度与实际落地的差距：虽然 AI 热度很高，但企业真正大额采购和使用的比例很低
• 根本原因：企业需要的不是模型本身，而是场景化的价值和可量化的提升

商汤的 AI 原生产品策略

• 能力工程：底层技术能力
• 数据飞轮：数据处理和循环利用
• 交互优化：用户体验提升
• 工作流协作：企业流程整合

合作伙伴策略

• 行业 Know-how：与垂直领域合作伙伴结合
• 专业分工：商汤专注底层 AI 能力，合作伙伴提供行业专业知识
• 创业趋势：越来越多行业专家选择 AI 创业，寻求专业 AI 公司合作

AI 面向个人使用工具的愿景

• PC 时代：Office 套件，基于电脑能力实现专业模板和原子化能力
• 互联网时代：云协同，垂直场景工具（如 figma）
• AI 时代：跨平台、跨数据源，从过程交付到价值交付

AI 时代的特点

• 数据处理能力：处理大量非结构化、结构化数据
• 知识关联：强大的知识关联能力
• 场景适配：复杂场景、多样场景的理解和适配
• 人机协同：结果导向的人机协同工作模式

商汤数据分析智能体产品

产品整体图

• 2024年1月：发布国内第一个数据分析智能体, (那时候还没有智能体这个概念)
• 核心发现：大模型具有强大的工具调用能力
• 技术能力：
  • 调用本地电脑和沙盒
  • 代码编写能力
  • 数据可视化
  • 文件分析

给跟大模型离的不是那么近的用户群体做推广

• 真实用户：老师、学生、医生、制造业管理者、大巴司机等
• 用户特点：日常工作中与 AI 接触不多，但发现产品能实际解决问题
• 产品迭代：从 1.0 对话框产品模式到 2.0 针对简单/复杂场景数据分析能力，计划年底推出 3.0, 仍需要平衡模型与用户体验

产品精度保证

技术路径选择

为什么不选择 ChatBI/Text2SQL：

• SQL 局限性：SQL 主要用于数据库查询，不适合业务数据分析
• 精度问题：SQL 语言数据量有限，模型精度只有 80% 多，企业无法接受
• 数据库依赖：需要成熟数据库，但很多企业数据以表格、文档、图片形式存在, 即使头部公司的数据库建设也不完善

对于企业用户推广:

• 客户验证：头部客户几百个真实用户实测
• 用户角色：运营、商务等业务人员
• 精度要求：95% 以上准确率，保证企业侧可用性

C 端到 B 端的转化路径

• 增量价值：数据分析为员工提供增量价值，不会威胁工作
• 实际案例：销售人员用于商机动态管理和查询
• 采购动机：业务部门主动要求私有化部署或系统对接
• 正向激励：帮助员工更好管理工作，对 KPI 和职业发展有正向作用

突破传统模式

• 自下而上：业务部门主动找到产品方
• 打破壁垒：解决自顶向下和自底向上的矛盾

技术精度突破

• 百分百准确率：大模型做不到 100%, 但是在语义相对清晰的情况下，大模型调用工具可达到 100% 准确率
• 适用场景：
  • 持续计算
  • 数据匹配
  • 数理计算
  • 异常检测
• 前提条件：用户语义相对清晰

企业问题解决

• 系统连接：连接企业系统和本地数据
• 行业知识结合：结合企业和行业 Know-how 进行深度分析
• 数仓集成：与企业数据仓库结合

失败案例分析

金融公司财务部门推广失败：

• 容忍度低：财务数字绝对不能出错, 场景容忍度非常低
• 专业性高：财务人员操作极其专业，10 秒能解决的问题觉得 AI 太慢
• 用户反馈差：导致后续无人使用

成功场景特征

• 增量价值明显：对用户有明显的增量价值
• 容忍度较高：场景容忍度比较高
• 适用场景：
  • 企业运营：趋势分析报告、供应链管理
  • 商务产品：不是非黑即白的工作环节
  • 数据分析能力不强的业务人员

传统 BI 的问题

• 低代码困境：
  • 专业开发人员觉得拖拉拽太复杂，宁可写代码
  • 业务人员觉得拖拉拽太复杂，宁可找人帮忙
• 定位模糊：既要又要还要，导致上不下的产品定位

产品功能优化

二次编辑能力

• 核心需求：AI 生成结果不是 100%，但最终交付必须是 100%
• 支持格式：Excel、PPT、文本等可二次编辑文档
• 表格编辑：针对格式、数字、颜色等的二次编辑功能

用户体验优化, 相比精度提升 1-2 个点，快速编辑功能用户感知更强, 显著提高用户黏性

任务规划模块（2.0 功能）

开发背景

• 用户调研发现：60% 用户满意，40% 觉得不可用
• 不可用原因：
  • 用户不知道自己的需求
  • 分析数据不全
  • 无法给出更好的分析结果

解决方案

• 意图完善：判断用户意图是否完整，意图不完整的话, 通过引导式方式帮助用户明确需求
  • 数据补充：通过数据调用、联网检索等获取更多专业数据
• 任务拆解：帮助用户做分析思路大纲拆解,用户确认后给出最终结果

任务规划的产品理念

• 像向领导汇报工作一样，先确认需求再执行
• 解决一句话生成复杂结果但需求不清晰的问题
• 避免等待很长时间后发现结果不符合预期

商业模式与合作策略

• 商汤优势：算法、ToB 交付能力
• 商汤劣势：垂直领域行业 Know-how
• 策略选择：专注行业适应性强的通用场景

行业覆盖

• 通用性强：数据分析流程相对通用，类似代码
• 广泛应用：教育、医疗、金融、零售等各行各业
• 合作模式：与合作伙伴结合行业 Know-how，商汤提供技术底层

AI vs 传统 BI 的差异

• 定位差异:
  • AI 不是要代替 BI, AI 主要是做数据库清洗整合、跨系统融合, 在已有数据要素基础上，结合行业 Know-how 做深度分析
• 推动方式差异:
  • 传统 BI：IT 部门牵头
  • AI 方案：业务部门发起，IT 部门配合落地部署

解决的问题:

• 平台与业务部门协调：解决过去平台和业务部门关系不友好的问题
• 双赢结果：帮助平台部门完成 KPI，帮助业务部门找到有用产品

客户案例分析

头部消费电子公司案例

• 时间线：2023年7月接触，年底正式上线
• 业务痛点：
  • SMB 部门大量业务运营数据分散在各系统
  • 业务人员不擅长 Python 数据分析
  • IT 提单需要 2 周到 1 个月才能生成报告, 业务很难快速发展

解决方案与效果

• 实施周期：1 个月系统设计，2 个月内完全上线 POC，月底付费
• 人力投入：仅需 2 人，传统 BI 可能需要 10 人以上
• 效果提升：
  • 分析周期缩短 90% 以上
  • 超过 70% 业务人员明显受益

企业服务方法论

• 头部企业服务流程
  1. 业务部门试用：优先找业务部门
  2. 需求收集：收集业务需求
  3. 内部部署：与 IT 人员共同构建平台
  4. 种子用户测试：内部招募种子用户
  5. 大批量上线：测试成功后大规模推广
• 小企业服务模式
  • 轻量化推广：相对简化的推广流程 saas

时间优化, 从最早的 3 个月缩短到最快 2 个月, 但私有化还是很难

市场推广策略

客户沟通重点

• 不谈技术：不讲模型、不讲 benchmark
• 关注价值：重点讲案例、效率提升、收入增长

客户选择标准

• 有资金实力：有预算支持
• IT 实力：有一定的 IT 实施能力
• 合作意愿：愿意共建和探索
  比如金山

市场推广节奏

• 当前阶段：头部企业和C 端用户为主
• 中腰部市场：预计 2026-2027 年才会完全起来
• 策略重点：与行业最强企业合作，打造标杆案例后向下推广

总结与展望

• 从炫技到实用：AI 产品必须解决实际问题，创造可量化价值
• 场景选择关键：选择合适的应用场景比技术本身更重要
• 价值闭环：从技术能力到用户价值到商业价值的完整闭环

本期聚焦 2025 年 Swift、SwiftUI、SwiftData 的表现，其他内容涵盖 CloudKit 实战、Non-Sendable 设计、依赖加速、2D 照片变 3D 场景等

Lua 5.5.0 已经正式发布。所以，skynet 的 Lua 版本也随之升级。

skynet 维护了一份修改版的 Lua ，允许在多个虚拟机之间共享函数原型。这可以节省初始化 Lua 服务的时间，减少内存占用。

跨虚拟机共享函数原型最困难的部分是函数原型会引用常量字符串，而 Lua 在处理短字符串时，需要在虚拟机内部做 interning 。所以 skynet 的这个 patch 主要解决的是正确处理被 interning 的短字符串和从外部导入的函数原型中包含的字符串共存的问题。具体方法记录在这篇 blog 中。

这个 patch 的副产品是允许在多个 Lua VM 间共享常量表。打了这个 patch 后，就可以使用 skynet.sharetable 这个库共享只读常量表了。

这次 Lua 5.5 的更新引入了 external strings 这个特性，已经大幅度提升了 Lua 加载字节码的速度。我比较倾向于在未来不再依赖额外的 patch 减少维护成本。所以建议新项目避免再使用共享常量表，减少对 patch 过的 Lua 版本的依赖。

---

Lua 5.5 基本上兼容 Lua 5.4 ，我认为绝大多数 skynet 项目都不需要特别改动。但在升级后，还是建议充分测试。注意：更新仓库后，需要用 make cleanall 清除 lua 的编译中间文件，强制 Lua 重新编译。直接 make clean 并不清理它们。

Lua 5.5 有几处更新我认为值得升级：

1. 增加了 global 关键字。对减少拼写错误引起的 bug 很有帮助。skynet 自身代码暂时还没有使用，但后续会逐步添加。

2. 分代 GC 的主流程改为步进式进行。过去版本如果采用分代模式，对于内存占用较大的服务，容易造成停顿。所以这类服务往往需要切换为步进模式。升级到 Lua 5.5 后，应该就不需要了。

3. 新的不定长参数语法 ...args 可以用 table 形式访问不定长参数列表。以后可以简化一部分 skynet 中 Lua 代码的实现。

0️⃣ 🐼 序章：回疆的慢车与急惊风 回疆，赛里木湖畔的数字荒原。 这里是系统资源的边缘地带，网络带宽如同细细的涓流。大熊猫侯佩正蹲在一块虚拟的岩石上，第 10086 次尝试刷新他的“高德地图导航”。

做独立产品这件事，说起来容易，真动手了才知道水有多深。这是一个独立开发者将职场小需求变成主力产品的真实故事。我们将跟随 Zipic 作者十里的视角，一起回顾产品从 0 到 1 的全过程。本篇聚焦产品设计与决策思考。