上周，一位从瀑布转型敏捷的团队负责人告诉我：”早知道敏捷这么有效，三年前就该转型！我们有个项目用瀑布做了半年，上线时发现用户根本不买账。”这个案例绝非孤例。根据优普丰对上百家企业转型的跟踪，从瀑布转向敏捷的团队，产品上市时间平均缩短40%，用户满意度提升25%以上。今天，我将从本质层面剖析两种方法的差异，用真实案例展示敏捷的压倒性优势。

一、本质差异：预测式与适应式的根本对立

在深入对比前，必须理解两种方法论的哲学根基：

瀑布开发是”预测式”开发

• 基于一个核心假设：需求在项目开始时就能被完整、准确地定义。
• 流程像瀑布一样线性流动：需求→设计→开发→测试→发布。
• 变更成本极高，后期修改需求如同”逆流而上”。

敏捷开发是”适应式”开发

• 承认一个现实：在复杂环境中，需求必然随时间变化。
• 通过短周期迭代、持续反馈来拥抱变化。
• 变更被视为提升产品价值的机会，而非风险。

我曾辅导过一家智能硬件公司，他们用瀑布模式开发智能手表，历时9个月交付后，市场风向已变，首批产品大量积压。这正是预测式开发在变化市场中的典型困境。

二、五大核心优势：为什么敏捷更适合当今时代

优势一：极大降低风险，避免”交付即失败”

瀑布开发的最大风险在于，产品要等到最终阶段才接受真实市场检验。而敏捷通过迭代交付，持续验证假设。

• 每个迭代（通常2-4周）都产生可用的产品增量。
• 及时获取用户反馈，快速调整方向。
• “失败”被控制在迭代层面，而非项目层面。

某金融科技团队在优普丰敏捷教练的辅导下，首个迭代就交付核心功能的MVP，用户反馈直接推翻了原有设计假设，避免了6个月的开发浪费。

优势二：提升投资回报率，优先交付高价值功能

瀑布开发平均只有20%的功能被用户高频使用（Standish Group报告）。敏捷通过价值导向的优先级排序：

• 基于WSJF等模型优先开发高价值需求。
• 随时可发布，不错过市场机会。
• 及时发现低价值功能并停止开发。

在优普丰辅导过的团队实践中，采用敏捷的团队高价值功能交付比例从30%提升至70%以上。

优势三：增强团队能动性，从”被动执行”到”主动创造”

瀑布模式下的团队像是流水线上的工人，而敏捷赋予团队自主权。

• 自组织团队自主决定”如何实现”。
• 每日站会促进问题快速解决。
• 迭代回顾驱动持续改进。

优势四：提高产品质量，质量内建而非事后检验

瀑布模式下，测试集中在最后阶段，缺陷修复成本极高。敏捷通过：

• 持续集成、自动化测试确保代码质量。
• 测试人员全程参与，质量人人有责。
• 每个迭代都包含完整测试周期。

优势五：提升客户满意度，共建而非交付

瀑布模式中，客户直到最后才看到产品。敏捷让客户全程参与。

• 每个迭代评审会展示成果。
• 及时反馈融入下个迭代。
• 共同对产品成功负责。

三、实战对比：三个维度看透本质差异

需求变更处理对比

• 瀑布：变更请求→影响分析→合同变更→计划调整（耗时数周）。
• 敏捷：待办列表调整→迭代规划更新（耗时数小时）。

进度可视化对比

• 瀑布：甘特图展示计划vs实际，但真实进展难以衡量。
• 敏捷：燃尽图、看板直观展示迭代进展，阻塞问题即时暴露。

风险管理对比

• 瀑布：风险登记册，被动应对。
• 敏捷：通过迭代验证假设，主动消除不确定性。

某传统企业在优普丰辅导的数字化转型中，将关键项目从瀑布改为敏捷，需求响应速度提升5倍，项目失败率从40%降至10%。

四、敏捷转型路线图：从瀑布到敏捷的平稳过渡

基于优普丰的上百个成功转型案例，我总结出四步转型法：

第一步：意识唤醒与试点选择

• 管理层共识建立，选择合适团队试点。
• 导入敏捷基础培训，统一认知。

第二步：框架导入与流程搭建

• 选择Scrum等适合的敏捷框架。
• 建立迭代节奏和3355敏捷实践。

第三步：深度实践与工具配套

• 导入工程实践（持续集成、测试自动化）。
• 配套工具链支持。

第四步：规模化推广与文化固化

• 经验复制到更多团队。
• 绩效体系适配，文化固化。

五、常见误区澄清：避开敏捷实施的”坑”

误区一：敏捷等于无文档

• 事实：敏捷反对的是过度文档，而非必要文档。
• 实践：轻量级文档，工作软件高于详尽的文档。

误区二：敏捷不要计划

• 事实：敏捷有更频繁、更灵活的计划。
• 实践：产品路线图、发布计划、迭代计划的多层计划体系。

误区三：敏捷是银弹

• 事实：敏捷提升的是适应能力，而非保证成功。
• 实践：结合具体上下文裁剪实践。

六、立即行动：三个步骤开始敏捷转型

如果你正在考虑从瀑布转向敏捷，我建议：

1. 从小开始：选择一个有代表性的团队作为试点。
2. 专业辅导：引入优普丰等专业机构的教练服务，避免走弯路。
3. 持续学习：建立团队学习机制，在实践反思中成长。

结语：选择敏捷，就是选择与不确定性共舞

在VUCA时代，瀑布开发基于的”可预测性假设”已经崩塌。敏捷不是完美的方法，但它是在当前环境下最有效的产品开发方法。它承认世界的不确定性，并通过迭代、反馈、调整来持续逼近成功。

正如一位在优普丰辅导下成功转型的CTO所说：”敏捷带给我们的不仅是更快的交付速度，更是应对市场变化的从容和自信。”选择敏捷，就是选择与变化共舞，在不确定性中创造确定性。

“为什么我们学了那么多先进的管理方法，公司还是乱糟糟？”

“被寄予厚望的IPD，为何在明星企业理想汽车那里，反而‘水土不服’？”

如果你曾有过这样的困惑，那么这篇文章就是为你准备的。

我们深入研究了华为的成功与理想汽车的“失败”，并结合金融等行业的实践，试图揭开一个被大多数企业所忽视的秘密：学不会IPD，可能不是你的错。

从“打残”到“自宫”：理想汽车的“华为梦”为何破灭？

故事要从2022年说起，同期净亏损20.3亿元。

那一年，华为与赛力斯合作的AITO问界M7大获成功，让理想汽车创始人李想感受到了前所未有的压力，他公开承认被“打残了”。

危机之下，理想做出了一个看似无比正确的决定：全面学习华为。目标是把灵活但松散的“游击队”，升级为纪律严明、战力强悍的“正规军”。

于是，一场轰轰烈烈的“像素级”模仿运动开始了。理想不仅引入了华为的IPD（集成产品开发）流程，甚至连PBC（个人绩效承诺）这样严苛的绩效管理体系也一并照搬。

2023年公司实现营收1238.5亿元，同比增长173.5%，这也让理想成为了国内首家营收突破千亿元的新势力车企。2023年，公司车辆毛利率21.5%，同比增加2.4个百分点，全年净利润118.1亿元，实现扭亏为盈.

然而，良药并未治病，反而成了毒药。

• 官僚主义滋生：曾经引以为傲的敏捷反应速度，被冗长的审批流程所取代。
• 内部摩擦加剧：严苛的KPI考核，导致销售团队为了短期业绩“内卷”，跨区抢单、恶性竞争。
• 创新活力下降：员工疲于应付流程，而非专注于创造客户价值，曾经的创业激情被消磨殆尽。

终于，在2025年，理想汽车壮士断腕，宣布放弃PBC，回归更灵活的OKR，并对组织架构进行重组。

据2025年第二季度财报：总营收为302亿元，同比下滑4.5%，环比增长16.7%。净利润为11亿元，同比下滑0.4%，环比增长69.6%。不按美国通用会计准则，调整后的净利润为15亿元，同比下滑2.3%，环比增长44.7%。

这场价值数千万的转型课，以“失败”告终。

问题出在哪？是IPD错了吗？还是华为的经验有问题？

都不是。是我们对IPD的理解，从一开始就错了。

诊断IPD成败的唯一标准：你的“产品”在第几层？

IPD不是“万灵丹”，它是一个“放大器”。你强，它让你更强；你弱，它会放大你的弱点。

而决定你是“强”是“弱”的，是你对“产品”这个概念的理解，在你公司内部到底处于哪个层次。我们构建了一个“产品定义成熟度模型”来诊断这个问题。

产品定义成熟度模型

第一层：模糊层 (Ambiguous) – 如传统金融

• 特征：“产品”是什么？说不清。它可能是一张信用卡、一份贷款合同、一项服务、一个临时的营销活动，也可能是一个手机App。没有清晰的生命周期，更像是一个个独立的“项目”。
• 适用方法：在这一层，谈论IPD毫无意义。首要任务是建立基础的产品管理职能，开始用“产品思维”取代“项目思维”。

第二层：涌现层 (Emergent) – 如初创公司、理想汽车

• 特征：“产品”是灵活的、可变的，需要通过快速迭代和市场反馈来“发现”和“定义”。商业模式和市场格局都在剧烈变化中。
• 适用方法：敏捷 (Agile) 是这一层的原生方法论。目标是快速试错，找到Product-Market Fit。
• IPD的角色：重量级的IPD流程在这一层是“毒药”。它会扼杀创新所必需的灵活性和速度。理想汽车的悲剧，就是用管理“第三层”的方法来硬套“第二层”的自己。

第三层：具象层 (Concrete) – 如华为、硬件制造业

• 特征：“产品”是明确的、具体的物理实体。它有复杂的供应链、高昂的模具成本和极高的后期修改成本。商业模式稳定，目标是可预测、成规模地交付。
• 适用方法：IPD 是这一层的最佳实践。它提供了管理复杂系统所必需的结构、纪律和跨部门协同能力。

核心洞察： 在引入任何方法论之前，先诊断你的“产品”在哪一层。用第三层的药，去治第一、第二层的病，必然会“水土不服”。

深度剖析：成功与失败的样本

A. 三级产品：华为如何将IPD打造成“印钞机”？

华为的成功，从来不仅仅是IPD的成功。IPD在华为之所以能成为“印钞机”，是因为它生长在一片极其肥沃的土壤上。

我们总结了“启动IPD的3个前提+3项配套”：

✅ 3个前提条件 (地基)

• 坚定不移的最高层支持：IPD是“一把手”工程，需要领导者持续投入近十年的决心和资源。
• 稳定且清晰的业务：IPD是用来“管理和放大成功”的，不是用来“寻找成功”的。
• 雄厚的投资能力：IPD是对流程、工具和人的长期、巨额投资，没有捷径。

✅ 3项配套措施 (生态)

• 客户为中心的文化：确保IPD这台强大的机器，始终朝着正确的方向（市场）开炮。
• 打破部门墙的协作文化：如果你的公司“筒仓林立”，IPD的跨部门团队（PDT）将形同虚设。
• 匹配的激励机制：奖励团队的长期成功，而非个人的短期英雄主义。

B. 一二级产品：为什么IPD是金融业的“毒药”，理想的“紧箍咒”？

• 对于金融业（一级）：最大的挑战是连“产品”都定义不清。在风险、合规、法务等强大“后台”部门面前，一个以市场为导向的“产品经理”往往人微言轻。强行上马IPD，只会是流程空转。
• 对于理想汽车（二级）：最大的问题是“成本曲线错配”。硬件的修改成本是指数级增长的，所以IPD强调前期把事情做对。而软件的修改成本是相对平缓的，敏捷开发鼓励快速迭代。理想汽车用一个为硬件而生的重流程，锁死了自己作为软件密集型企业的最大优势——灵活性。

停止盲目学习！你的“IPD体质”健康自查手册

在决定是否“学习华为”之前，请诚实地回答以下问题：

产品定义：你能否用一句话，让全公司（从CEO到实习生）都明白你的“产品”是什么吗？

• [ ] 1分（完全不能）[ ] 5分（完全可以）

领导力：你的CEO是否愿意，并有能力，为一场为期5-10年、不保证短期回报的组织变革持续投入？

• [ ] 1分（完全不能）[ ] 5分（完全可以）

文化：当一个跨部门项目成功时，你的公司会奖励项目组，还是会奖励在其中“贡献突出”的某个部门领导？

• [ ] 1分（后者）[ ] 5分（前者）

战略：你当前的核心任务是“寻找下一个增长点”，还是“规模化复制已验证的成功”？

• [ ] 1分（前者）[ ] 5分（后者）

诊断结果： 如果你的总分低于15分，请立刻停止“像素级模仿华为”的危险想法。

结论：IPD的终极奥义——抄流程，不如抄思想

所有的方法论都是工具，而所有工具的本质，都是思想的凝结。

理想汽车的失败和华为的成功，共同指向一个朴素的真理：与其在流程的细节里挣扎，不如回到客户的价值里思考。

对于绝大多数非硬件、非巨头的企业而言，学习IPD的真正价值，不在于照搬它的流程、表单和评审点，而在于学习其三大核心思想精髓：

• 市场导向：建立一个真正由市场和客户需求驱动创新的机制。
• 组合管理：像管理投资组合一样，去管理你的研发项目，确保资源投向最能产生回报的地方。
• 跨界协同：建立一个能让业务、技术、市场、财务真正坐在一起，为同一个目标奋斗的协作机制。

先让思想落地，再让流程生根。

这，或许才是这堂价值千万的转型课，教给我们的最宝贵的智慧。

产品为王

银行产品的内涵与外延

虽然在系统建设中，我们总是想办法去建构“产品工厂”或“产品中心”，但实际上，即使是对银行产品下定义都是非常困难的。与手机、电脑等显而易见的有物质实体承载的产品不同，商业银行的“产品”，多数时候实际上是一揽子为客户提供的服务的组合，而服务通常极其复杂。《设计心理学》一书中，作者诺曼不无吐槽地指出，“我们最常见的服务，驾照、护照签发、缴纳所得税…都有庞大的官僚主义规章制度，一大批机构内部的人，经常还有公司里面都会有的很多个部门，声称负责所有非常规性问题。….所有那些在幕后的东西–那些神秘地运作着，形成顺利、高效或者令人困惑的运作效果的东西，被称为’后台’….”

循着诺曼对服务的解释，银行产品的定义从狭义上可以做如下概括：“银行产品，是银行基于特定金融需求，面向特定客户群体（个人或企业），设计并提供的、具有明确功能、使用规则、定价机制和服务流程的金融服务方案。它本质上是银行与客户之间围绕资金流动、风险管理、价值增值等核心金融活动所建立的契约化服务载体”。在这一定义中覆盖的产品包括两类，一种是面向规模化长尾客户提供的标准化产品（比如微粒贷、余额宝）；另一种是面向特定行业，甚至个别客户定制的，但又具备可复制、推广的金融服务解决方案/产品，比如面向特定行业，甚至特定核心企业的定制化现金管理、分级账簿、供应链金融解决方案等。

面向客户的银行产品可以做以上定义，但因前、中、后台的存在，银行产品常常在内部管理及部门协同过程中造成困扰，一款产品，你是站在客户视角，还是中台业务，或是后台运营、财务视角，看到的情况是不一样的。银行中对客户来说是后台的部分对业务管理部门来说就是前台，而对业务管理部门来说是后台的部分，对运营或者财务来说，又是前台，每个角色都有自己的前台和后台。举个例子，以最近国内新能源汽车供应商应收账款账期问题为例，在此案例中，供应商可以向商业银行转让对整车厂的应收账款债权而获得现金流。在这个业务中，供应商，即银行的企业客户感受到的产品是“应收账款债权转让融资”，而在银行中台–一般是负责贸易融资管理的中台部门（如交易银行部或贸易金融部、企业金融部之类的），这个产品一般被定义成“保理融资”（并细化成有追索权、无追索权、需要进行债权转让确权的明保理，或者无需确权的按保理等等），而到了财务部门编制会计科目时，这个产品可能就变成了“前收息模式的预支价金”，最后在IT系统中，这本质上与一笔预收息的贷款没有任何区别…

从上述例子中不难看出，正如诺曼所言，“成功的产品必须合并内部和外部成分的所有不同层面，协调地支持所有可见和隐藏的服务和操作。产品存在于一个复杂的交互网络中….”

为什么需要重视产品

其一，做好产品论证与分析，有利于资源的有效投入，获得正向回报。有过银行系统的开发经验的工程师们或许都有过这样的经历：一个被催的十万火急，必须限期完成的项目或者需求，在项目组人员加班加点、蓬头垢面地忙活一圈，上完线后过几个月一统计：新增客户数0，新增收入0，业务价值0。随之而来的解释通常是这样：业务效果未达预期，是因为这是一次“快速试错”，潜台词则是“因为是试错，所以没有业务效果是正常的”。只不过，如此试错的代价是银行的宝贵预算，以及其他更有价值的项目或产品被影响，还有倒霉的程序猿们的加班加点。

当然，这里面，有一部分的确是面对不确定的市场，不得不付出的试错成本（毕竟成功很大程度上是概率事件），又或者是为了营销客户，必须付出的成本，即某个产品或解决方案，你有，客户不一定选择你，但如果你没有，客户连机会都不会给你。有问题的是不经研究和论证，拍脑袋决策、仓促开干的项目和产品，提出者将开发压力交给IT，将客户经营压给分支行，将业务效果交给天意。

其二，银行产品不仅仅是功能工具，更是银行定位战略的载体和品牌形象的关键塑造者，通过产品建立的印象有利于建立正面的客户心智。特劳特在《定位》一书中，提出企业成功的关键，就是“如何在潜在顾客的心智中占据一个有利位置”，而在“信息传播过度的社会里，传播简化的信息是唯一有效的方法。” 产品便是那个能够简化信息传播的关键抓手。“微粒贷”的成功，不仅仅是为webank的资产规模、利润规模作出重要贡献，其形成的客户对微众银行提供的服务便捷、科技、专业、普惠的印象，也被投射到微业贷、微众银行智能存款等产品中，奠定了微众银行在客户心智中的整体印象。

其三，银行产品不仅是满足需求的工具，更是低成本、高效率获客的核心引擎。原因有三：1）、一款具有强吸引力的“钩子”产品，本身就是最低成本的获客广告。2）、产品体验（流畅度、功能满足度、收益/利率竞争力）是用户是否留下的关键。糟糕的产品体验会让辛苦营销来的客户瞬间流失。3）、产品内设计交叉销售路径（如理财用户看到专属贷款优惠、贷款客户引导开通关联还款账户/信用卡）和用户分层运营机制（如VIP等级体系对应专属产品/服务），可以提高客单价，让存量用户产生更多价值。

产品设计需要关注的高阶问题

大多数机构的没有华为那种可以建立IPD（集成产品管理）的能力，也没有腾讯那种刻在基因里的产品文化。有什么办法能够一定程度上做到“谋定而后动”呢。这便是通过一定的流程和机制设计（比如产品审批、产品委员会审核），确保在一个需求或一款产品开始建设前，一定要将如下问题回答清楚，即经典的5W1H分析法：

WHO：产品为谁设计？目标客户是谁？目标客群有什么特点？购买者和使用者是同一个吗？目标客群有多大规模？最乐观与最悲观的情况下，分别的转化率与留存率预计有多少？

WHY：我们的产品有什么差异化竞争优势？客户为什么选择我们？产品有哪些竞品？有可替代产品吗？（比如信用卡与花呗）

WHEN：用户什么时候使用我们的产品？多久用一次？产品有政策窗口期吗？（商业银行产品必须非常关注的，比如票据市场、外汇市场、债券市场的阶段性机会）产品有市场窗口期吗？（比如ETC扣费的短暂窗口期）

WHERE：产品有可能完全线上化？用手机用方便还是电脑用方便？（这在企业银行业务中，尤其是中大型企业中特别需要关注，因为企业员工坐班原因，网银比手机银行更受青睐，再大的企业，则需要银企直连，因为企业员工只想在自己的ERP等内部系统上操作）可以使用H5进行场景投放吗？

WHAT：产品的具体形式，或载体是什么？产品要做成怎么样？产品的定价如何？

HOW：用户怎么交互？交互设计涉及的概念模型、示意符号、功能入口布置等等。（在互联网想方设法投入巨资仅仅是为了客户少点一下手机的当下，商业银行的很多设计还是不惮于打扰客户，有些交互的设计简直就是为了刻意给客户制造麻烦….）

在”5W1H分析法”之外，还要考虑产品建设的“时间成本”、“资金成本”、“风险成本”与“行动成本”等等。一份需求也好，一个产品也罢，事前做好分析论证：判断要不要做，值不值得做，做完了怎么获客，怎么演进，比知道产品和需求怎么去做更重要。如果说IT的能力养成是为了能够“正确的做事”，那么，产品论证分析则指向一个更重要的命题–如何尽可能保证“做正确的事”。一件事不值得做的事，自然就不值得做好。

产品团队责任重大

在传统商业银行的组织架构模式下，以前、中、后台条块化组织的一个机构中，要确保“做正确的事”殊非易事，如果组织不能实现有效的协同，就会出现好像个个部门都在认真履职，而最后什么事都做不成的情况。而要做好这些，除了董事会及经营管理层的决策部署外，在执行层面，需要有人来完成“市场分析、用户研究、收益成本分析”，并对“产品定位、产品设计、产品推出时机、产品营销方案”等进行说明，最后还要想办法协同相关部门，取得配合部门的支持。总之，要向前能够连接起分支行，向后能够协调好风险、财务、法规、营运、IT，为达成一个共同的目标而努力。这在商业银行，从来都是一个不易解决的问题。

在商业银行的机构设置中，处于“中台”位置的总行业务主管部门，比如零售的消费金融、财富管理、汽车金融、信用卡，对公的交易银行、贸易融资、国际业务、商业汇票专营等部门，以及具有全线上产品设计、运营职责的网络金融部门，专注SME经营的小微或普惠金融部门，天然具备深耕本领域业务，知晓领域业务特性，向前可连接并向分支行下达经营指标，横向可以拉通兄弟部门，实现公私联动、存贷联动产品设计，向后可以拉通风险、财务、法规、财务、IT等的能力，作为利润创造中心的特点，这些部门也最有能力和动力通过整合资源达成业务目的。统筹产品设计与经营，中台产品部门责任重大、使命光荣。

要完成如此重要的工作，对产品经理的能力要求自然被显著地放大了。与风险、IT、法律、财务等仅需要专注于某一领域的专业技能不同。一个好的产品经理，除了需要对本领域的银行业务有深入且独到的理解外，通常还需要具备一定的法律基础知识，比如知道《民法典》中关于合同、担保、物权的法律条款。如果产品经理正好对会计知识有所了解，那么在跟财务部门争取更优惠的FTP定价，在思考如何通过非融资性保证业务降低RWA占用方面，就会占有优势；产品经理如果有IT背景，知道一个功能大致的实施难度与实施周期，就能避免“这个需求很简单、怎么实现我不管”的冲突；如果产品经理对设计有基本的了解，就能在产品设计中很好地完成关于等待、推荐、反馈、提示及概念模型的设计；如果产品经理对宏观经济学、货币银行学、监管法规有好的了解，那么就更能敏锐的发现监管政策窗口与市场机会。最后，产品经理还需要有天然的直觉，对人性的洞察，以及卓越的沟通能力。

“With great power comes great responsibility”，这也正是乔布斯、马斯克、马化腾、雷军、余承东、张晓龙等一众大佬，都被认为是大产品经理的原因。

产品思维

产品设计者面临的困境

在“传统”商业银行中，产品部门、产品经理要做成一件事，需要有效协调前、中、后台部门的支持，需要识别市场机会，又要面对监管约束，常会面临三重困境。一是专业深井困境。在商业银行中，一款产品通常涉及的风险、法规、财务、科技等部门，各有各的专业语言，比如风险中的PD、LGD、EAD、M、RAROC、EVA、FPD、DPD、AUC、KS等；法规中关于要约、承诺、无因性、善意取得、质权、债权、留置权、一般保证、连带责任等；财务中的各种资产、负债、收入、支出、费用、未分配利润、表外、FTP定价、利率重定价曲线等等。IT则自不必说，从应用架构到数据模型，知识体系纷繁芜杂。也因此，产品也成为“翻译损耗”的重灾区。所谓对“跨界复合型人才”需求最高的领域，产品类岗位首当其冲。二是创新悖论困境。商业银行因为其经营特点的特殊性及对国民经济的特殊重要性，受到央行、金融管理局等的强监管约束，以巴塞尔协议“资本约束 – 监管干预 – 市场制衡” 为内核的三维监管体系需要商业银行的“创新”活动必须在规定的框架内进行。而与此同时，一些泛金融机构，如商业保理公司、金融租赁、消费金融公司、网贷公司、第三方支付公司等，其监管约束（从监管主体到监管细则）与商业银行不可同日而语。部分机构因此得以进行的“擦边球”创新，对商业银行构成极大的竞争压力，此其一；其二，以互联网，尤其是头部互联网公司为代表的，金融产品获客、交互体验创新，则对商业银行形成了降维打击。因此，对商业银行而言，一方面需要“守正”，一方面又需要“创新”。三是价值量化困境。财务可以通过利润表直接记录收入、支出和利润，风险可以通过五级资产分类和不良率计量损失，IT可以通过刚性费用衡量投入，而产品价值却往往与市场、营销、内部的资源投入及协同等众多因素相关，因此难以剥离归因。产品部门的绩效计量，在缺乏产品基因的机构，向来都不容易。《人人都是产品经理》一书中提出：“产品是解决问题的载体”。而银行问题的复杂性在于——它既是数学问题（定价模型、资本计量）、工程问题（系统架构、流程耦合）、行为问题（用户心理、组织协同），更是哲学问题（风险与效率的永恒博弈）。

五大产品思维

在2015年“互联网+”时代前后，商业银行曾掀起一股向互联网学习的热潮。彼时，”互联网的13种思维”，”互联网独孤九剑”等曾被商业银行奉为圭臬。其中的内容鱼龙混杂，不少指向的不是踏踏实实的价值创造，而更像某种方式的割韭菜指南。当然，其中也不乏值得学习借鉴的，但那并不仅仅是互联网特有，而是各行各业的普遍性真理，也即《腾讯产品法》中提到的五项思维模式，分别是：第一性原理思维、系统性思维、相对思维、抽象思维和演进式思维。在“技术可购买、流程可复制、客群需要争夺”，金融产品同质化加剧的今天，产品设计者这这些方面的思维认知能力，对构建商业银行全局或局部竞争优势十分关键。第一性原理思维。第一性原理思维要求只采用最基本的事实作为依据，在传统的产品设计的前提下重点观察它的前提条件是否发生了变化、是否有优化的空间、是否还有更优的解决办法。通过不断追问的方式，剥离所有表象后，识别产品解决的最原始需求是什么。第一性原理最需要挑战的，是对商业银行“传统”做法的挑战–即“祖宗之法可不可变”的灵魂追问。以笔者曾经历过的一个项目为例，因为历史上票据贴现账务在核心的贷款模块记录的原因，即使在投产了商业汇票系统后，这一“传统”仍然被保留，因而导致客户每次在申请票据贴现时，运营部门都需要先为客户开立一个贴现账号。但实际上，贷款业务首先从本质上就不需要所谓的“账号”，而只需要编列“借据–IOU”，其次，贴现业务与贴现票据强相关，其明细账在票据系统分录，科目账在总账系统反映即可。基于这一原理性分析，后来我们在方案实施过程中，就直接取消了贴现账号，既减少了系统间交互（信贷、票据与核心之间的多次交互），又简化了作业流程。

系统性思维。银行产品的本质是多重复杂系统的耦合体，其跨度涉及用户行为系统（心理学、社会行为学范畴）、金融基础设施系统（如支付清算体系）、监管政策系统（动态变化的合规边界）与商业价值系统（FTP定价、RWA占用、客户LTV等）。以一款高利率存款产品的发行为例，在系统工程视角下，除了存款部门的考虑外，还需要如下的考虑：从资产负债角度，会否在未来导致资产负债期限错配？从流动性角度，会否在产品到期后因赎回导致流动性风险？会否导致全行FTP定价失效？对全行利润的侵蚀度如何？是否会引致监管处罚？总而言之，传统的线性思维模式–要揽存就提高利率，已经越来越需要让位于系统性的思维，即将产品置于生态网络中做整体性思考。相对思维。相对性思维是摒弃掉非黑即白的二元对立思想，不轻易贴标签，不轻易下论断，看到事物之间的内在关系和动态变化，以此来指导产品设计。相对性思维在银行产品设计中的核心运用，是需要把握银行产品的”最优解”只存在于具体约束条件下，在约束条件下需求“整体收益、风险成本、监管合规”的有机统一。监管约束下的相对思维运用，反而会成为机构获得差异化竞争优势的突破口。比如，“宝”类产品在表面上会导致商业银行存款搬家，但如果能够获得货币基金的代付资格，则通过基金公司的托管，活期存款的“流失”则可以得到超额补充，产品竞争力带来的流动资金池（当日购买与赎回的差额），事实上对活期存款的损失可能会非常小，而商业银行则能获得资金托管带来的存款、客户粘性、费用收入等一揽子收益。
抽象思维。抽象思维通常与系统性思维相辅相成，是指在产品设计及实施过程中，需要提取不同事物性质相同的内核;通过功能与能力要素的抽象，支持产品的快速组装。这一思维，不仅是产品经理的契约，更应是IT架构师们的圣经，在分布式微服务架构中经常提及的共享服务抽象，以及前些年被推崇备至的“中台”，本质上都是在产品或者系统实现过程中，需要进行充分抽象，在不同产品、不同功能间寻求最大公约数，将公约数沉淀为稳定的，后续可复用的产品功能。比如在融资业务中，对押品管理、额度管理、核算账务的共性抽象和服务共享，可以实现对消费信贷、汽车金融、小微信贷、对公信贷的普遍支持，避免重复造轮子。
演进思维。演进思维是商业银行在面对不确定的宏观经济环境、快速进步的技术条件、不断变化的产业环境等情况下，结合用户认知和竞争对手情况，依靠快速试错、快速选代、用最小可行性验证产品假设的一种产品思维。这种思维模式下，要求产品经理对产品核心功能有高度的提炼能力，技术能力上能够支持AB测试与灰度流量验证等。以互联网贷款为例，在演进思维指导下，对风险控制指标的预测、验证、反馈、调整需要反复不断地进行，通过A/B测试，选择最优解。

局中人的破壁之道

银行产品创新的最大障碍，往往不是技术瓶颈或资源限制，而是对问题本身的错误锚定。爱因斯坦说，“我们不能用制造问题的同一思维水平来解决问题”。当我们能够新的思维模式重新审视产品，那些曾经的困境，就可能显露出隐藏的破局点。但“you can’t be what you can’t see”，思维模式的建立依赖于认知，而认知的建立需要大量的训练，对身处局中的我们（产品经理、架构师、开发工程师）而言，或者可以在如下方面进行努力：一是尽可能建立跨学科的知识体系。除自身岗位的专业技能外，通过在金融工程、法律法规（比如民法典、人民银行发布的各项法规）、用户体验（交互设计）、技术架构等方面，尽可能地进行积累，形成跨学科的知识体系。突破性创新通常来自跨学科的灵感启发，一专多能不但有利于跨越专业深井，还有可能为产品创新提供火花。二是基于“压力测试”的思维训练。在产品设计或需求分析过程中，通过“三问”不断强化思维练习。包括：本质之问–今天我们讨论的“账户分级”需求，用户想解决的原始问题是什么？系统之问–这个功能上线，关联到哪些系统，有更简单的设计方案吗？抽象之问–这个功能有现成的功能可以复用吗？新建功能能否沉淀为标准组件？三是对成功经验和失败教训进行复盘与解剖。“案例教学”是最直观、最有体感的认知体验。通过问题复盘过程中的五步法：问题定位–根因分析–思维盲区–制度改进–能力沉淀，建立制度化的事后学习机制，让成功的经验得到推广，失败的教训不再重演。

洞见需求

要做成一个项目，或一个产品，通常需要做3段式的准备，即：需求定义–“define what you want”，清楚地知道要解决的问题、痛点是什么； “know how” –有能力进行可行性评估、知道怎么做任务分解、以及有能力完成总体设计和子系统的设计；“enable”–执行、完成实施、达成目标。三项工作可以简单地分别对应为产品经理的工作、架构师的工作与程序员的工作（画外音：要让一家银行的产品/系统好用，服务体验如沐春风，你需要同时拥有优秀的产品经理、架构师、以及程序员）。其中，需求定义是任何复杂工程或产品项目的基石，它直接决定了项目/产品能否成功、做的工作是否具有价值、付出的成本是否值得，以及问题是否真的得到了解决。需求是所有产品设计的起点，“修炼对需求的认知，是所有产品设计者的终身课题”。

需求通识

《人人都是产品经理》一书中，将需求定义为“用户的问题”，产品经理的使命是“发现问题、定义问题”，通过产品“解决问题”，最后为用户“创造价值”。

如雷贯耳的马斯洛需求层次理论，是大家最耳熟能详的“需求”定义，马斯洛将人的需求分为5个层次：生理需求、安全需求、社交需求、尊重需求以及自我实现的需求。汉语中有于此对应的另一句话，“仓廪实而知礼节”。马斯洛定义的需求，是从心理学角度描述的需求。而在经济学意义上，《腾讯产品法》一书对需求做过非常简单精炼的概括：需求，是想要，且要的起的产品或服务。“想要”是需求的起点，“要得起”才构成真正的有效需求。对身处商业组织中的管理者、产品经理、架构师、程序员来说，更重要的是，是“借我一双慧眼”，能够在纷繁芜杂的用户诉求中，判断哪些是“显性需求”，哪些是“隐性需求”，哪些是“刚性需求”，哪些是“弹性需求”，总而言之，在商业机构中，需要产品经理能够“去伪存真”，通过表层用户直接表达的需求，挖掘用户行为背后的真实目标或痛点，最终回归人性的底层动机–本质需求。
那么，在一般性方法论的层面，可以这么做呢？通常涉及到4个步骤，分别是挖掘和识别需求，定义需求，方案设计，以及持续验证。

在需求挖掘和定义阶段，需要回归第一性原理，通过追问“为什么”，挖掘表象背后的真正问题，弄清楚用户真正想要的是什么。当拿到一份需求，通常可以做如下发问：用户为什么会有这样的需求？提出这样的改造，是基于什么样的前提条件？这些条件至今没有变化吗？有其他替代方法吗？随着技术、经济、文化潮流的发展，有引入新的变量吗？….《腾讯产品法》一书中，用微信群的案例举过一个经典的案例：我们知道，在微信群之前，腾讯其实是有QQ群的，QQ群需要由发起人在群功能中创建一个群，让后将群ID分享给需要入群的人，经过群主审核后，才能入群。如果是一般的产品经理，在设计微信群的时候，将不可避免地受到QQ群设计的影响，但是。运用第一性原理的追问：QQ群设计时的目的与微信群一样吗？不一样，QQ群更像是满足某种特定功能或提供特定服务而存在的，微信群则与大家聚在一块聊天没区别；QQ群设计时的情景与微信一样吗？不一样，QQ是“虚拟社交”，微信则是“实名社交”；使用环境变了吗？当然，QQ群时代以PC为主，微信时代则是手机入口为主。于是，情况一目了然，微信群是为了满足熟人社群互动而存在的，他的特点与线下社交一样，需要支持可以随时随地，几个人聚在一块就可以聊天，也不需要有所谓的群ID，于是，微信群的形态就是我们今天见到的这样。

商业银行的“需求”

商业银行的需求，在具备需求的一般通识性特征外，回到第一性原理视角，还带有大量的行业特征。本文试仅就银行零售与对公业务作少许讨论：

零售银行。零售银行中的产品需求，追根溯源后，金融需求是第二位的，其第一推动来自人的需求，即“生、老、病、养”，“衣、食、住、行”，与社交、娱乐等的需求，由这些需求衍生出个人客户需要的资产增值需求、资产保障需求、交易需求、消费信贷需求、信用卡需求、汽车金融需求、住房信贷需求，最后以存款、汇兑、基金、保险、理财、消费贷、汽车贷、信用卡、房贷等产品的形态体现。

这些需求的特点，对商业银行的产品设计和业务拓展而言，最终被归纳为业内常见的一个词–“场景金融”。在零售业务中，需要追求让金融服务无感地嵌入到场景之中。而场景资源通常是宝贵的，在互联网时代，优质的场景入口，几乎都被互联网巨头或垂类的公司所占据，而场景拓展的难度，常被商业银行简化为“开放银行”的建设，甚至是进一步简化为“openAPI”建设。“开放银行”从第一性原理视角，是毫无疑问的本末倒置，是银行中心论在今时今日仍不能放下身段的表现。openAPI在产品设计上，从银行的视角，试图通过封装银行内部的金融服务接口，提供标准化的对外服务暴露来支持任意第三方按需适配。问题在于，是银行需要场景，而不是场景需要某家发布了openAPI的银行，所谓的ApiBanK，在逻辑上并不成立。不信的话，去看看微信、支付宝的绑卡，是按银行的标准来，还是按两个巨头的标准来，联合贷的话语权是在银行还是发起方。因此，在零售银行领域，面向个人客户的场景拓展，以及开发适配具体场景的产品，比搞开放银行重要。而在技术准备上，不要去试图制定标准，而应该通过适配层的抽象，通过sdk / h5等，考虑如何敏捷、快速、低成本地接入场景。

企业金融。与零售金融的需求围绕个人的需求展开不同，企业金融业务的第一驱动来自于企业经营过程中的金融服务需求，它包括企业的“生产制造”、“贸易结算”，以及企业运营过程中的企业并购、补充资本、税费缴交、招投标、采购、销售、发薪、福利报销等等。企业金融服务的需求，根据企业类型、企业规模的不同，体现出明显的产业、行业甚至个性化特点。

也因此，企业金融业务中的需求提炼、挖掘，其实更考验产品经理的能力。以广义的贷款业务为例，假设某个企业提出需要一笔“流动资金贷款”，对客户经理而言，站在客户角度，则需要了解，这笔“流动资金贷款”的用途是什么，如果是用于向上游付款，该产业链上可以接受商票吗？如果可以接受商票，是否可以改为签发银行承兑汇票？对应地，融资品种一换，企业就可以将需要付息的贷款，转变为无需付息的银承，减少有息负债，对优化企业的资产负债表，显然更有价值。又比如，在为客户办理信用证开证时，要求缴纳的保证金，银行是否有能力分户核算到企业自己的账户上，而不是都缴纳到内部户中，不同的缴交方式，虽然对银行都是一样的存款，但对企业而言，保证金存款将仍然体现在企业的流动性中，这显然对企业资产负债表、现金流量表都更有价值。
不同于零售业务，在企业金融业务中，光融资工具就有贷款（可进一步根据具体的场景细分为一般性贷款、贴现、预支价金、押汇）、票（商票、银票）、信用证、保函，以及由此衍生的各种担保承诺类产品。在支付工具中，在普通账户之外，则有票据、信用证；在公私联动中，有代发、代扣的专门解决方案；在存贷联动解决方案中，有法人账户透支等等…也因此，企业金融业务尤其需要回归企业的需求本心，真正深入企业，针对性地提供金融解决方案（内容太多，未来专题讨论）。

需求分析的若干案例

商业银行中，除了上述面向客户的产品化需求外，还有一类面向内部作业的需求，这一类需求提出时，通常从提出者的视角出发，基于其岗位痛点提出需求，是最需要回归第一性原理，进行全局性考虑的一类需求。看几个具体案例：

CASE1：保证金开户同屏授权改异步。

需求背景：在银行承兑汇票业务中，保证金开票时需要开立保证金账户，保证金账户的开立需要同屏授权，由于业务量大，主管需要频繁离开座位，进行同屏授权。因此提出需求：请将保证金授权由同屏授权改为异步授权。根因分析：银承汇票业务保证金开户过程中，因为保证金账户业务业务合同一一对应的关系，当银承合同多的情况下，需要频繁开立保证金分账户，每次分账户开立，不只是需要授权，还需要填写申请表，并经支行行长签字，开立时不仅是需要主管授权，操作人员还需要录入一系列开户信息，并验证支行行长签字。所以，这个需求的根本痛点其实是，在银票业务中“开立保证金账户的操作十分复杂，影响作业效率，最终影响银票的签发效率”。方案设计：完成根因分析后，我们继续追问，保证金账户的开立只是银行承兑汇票签发的其中一个环节，在开户申请前，还做了什么？了解后发现，在开户前，客户经理已经录入了银承业务合同、为客户开立了结算账号，保证金开户的所有要素都已经具备了，银承业务合同在业务审批过程中，本身就需要支行行长及放款中心线上审批。这也即意味着，保证金开户的要素已经全部具备，保证金开户可以随业务合同一起审批。于是，这个需求被调整为“银行承兑汇票签发的流程优化”，将保证金开户、应解汇款户开户，与银承业务合同的审批进行了自动关联。改造完成后，不仅仅是保证金开户不需要同屏授权，是保证金开户的所有操作直接变成了线上化，客户经理不需要再去柜面，运营同事也不需要再操作开户，对应的签字、验签，线下资料存档等所有内容，也都被撤销，银票签发效率大幅提升。

CASE2：帮我做个RPA，支持开户信息录入。
需求背景：某银行开户，采取线上预约机制，客户预约填写的开户信息及开户资料，在完成审核后，需要通过手工重新录入到交易系统，十分繁琐。
根因分析：这看起来是个开发RPA的需求，但RPA是否能够彻底解决问题，是值得怀疑的。问题的根本在于，预约开户信息及资料，为什么不能直接传递给客户信息系统与账户系统，需要反复多步操作的客户信息录入与账户开立，综合签约等，可以通过服务调度，完成自动化处理吗？
方案设计：答案显然是可以的。于是，需求转变为“实现预约开户的全流程线上化”。负责实现的系统，从RPA，改为预约开户系统，通过打通预约开户系统与后台交易系统，实现信息传递的线上化，并通过预约开户系统实现服务接口的编排，将开户变成客户申请、运营检查、自动开立的自动解决方案，大幅提高了开户效率。

复杂系统

简约崇拜天文学家开普勒说，“大自然喜欢简约和统一”，哈代也宣称，“美是首要的试金石，丑陋的数学不可能永存”。数学和物理学中那些充满美感，而又蕴含宇宙普遍真理的方程–如爱因斯坦质能方程、麦克斯韦方程组、欧拉恒等式等等，常常被用来证明–简单的才是美的。（下图为欧拉恒等式，它将数学里最重要的几个数字联系到了一起：两个超越数：自然对数的底e，圆周率π；两个单位：虚数单位i和自然数的单位1；以及被称为人类伟大发现之一的0。在数学分析领域，以及复变函数论中都占有非常重要的地位，被称为“上帝创造的公式”）

“奥卡姆剃刀原理”同样强调“若无必要，勿增实体”，主张剔除冗余，直击事物本质，避免引入不必要的复杂性。在产品设计哲学中，“简约”也经常被作为衡量产品设计成功与否的标准之一，尤其在消费者业务（to C）中，以苹果、腾讯等为代表的产品设计，充满了简约的美感。有如此多的珠玉在前，于是在产品设计中，“简约”常常被作为“产品经理”的追求之一，只是这种“简约”经常被有意或无意的曲解：其一，数学与物理学中的简约，是对本质和原理的解释，其推导、论证过程充满了复杂性，混沌系统的复杂性研究，甚至发展出了一门专门的学科–混沌工程；其二，产品中的简约是对用户而言的，要达到对客户简约呈现的目的，产品设计者需要有效管理和整合后台的复杂；其三，并不所有的产品都可以做到“简约”，比如下图这个：

管理复杂

事实上，工程领域，以及我们生活中的大部分场景，复杂才是常态，无论是操作一台汽车，还是理解一款金融产品，或是管理一个大型项目。唐纳德·诺曼曾一针见血地指出：问题不在于复杂本身——复杂是客观存在的常态——而在于我们如何理解、沟通和驾驭这种复杂。对产品设计而言，复杂并不是问题，令用户困惑，甚至导致用户不会使用，才是问题。关于复杂的一个例子，是男士们的书桌或房间，在一堆乱七八糟中，主人总是可以很容易地找到需要的物品，但经过太太的精心收拾后，很多东西通常神秘地不知所踪。

糟糕的设计，无论是物理产品、数字界面、流程还是组织架构，会将本源的复杂放大成令人望而生畏的困惑，而优秀的设计则能化繁为简，让复杂变得驯服、透明，甚至富有力量感。管理复杂，并非追求绝对的简单，那往往不切实际，而是追求“可理解的复杂”和“可管理的复杂”。诺曼为我们提供了几个至关重要的手段：

建立有效的心智模型。 这是管理复杂性的基石。用户需要一个关于系统如何运作的“模型”。这个模型需要能预测操作的结果。优秀的设计通过界面、反馈、文档甚至隐喻主动提供并强化这种模型。这个最佳的例子是最近华为推出的尊界S800，通过手势可以开关车门，控制车窗的亮度，将操作与大脑的自然反应进行了映射，当然前提是有黑科技支撑。

合理的分层。分层简直是解决复杂问题的不二法门，面对庞大的复杂性，人类认知的天然策略就是分解。比如，以JAVA编程为例，可以分层为：JAVA源码、.class字节码、JVM、操作系统、计算硬件资源；银行应用架构中，我们将系统分层为渠道层、产品层、风控层、账务层及数据层；管理大型项目时，WBS也是典型的层级化应用，将大目标拆解为可执行的小任务。模块化降低了认知负担，使聚焦和掌控成为可能。

设计及时且明确的反馈。在复杂系统中操作，用户需要清晰地知道“发生了什么”以及“我做得对不对”。反馈是建立和修正心智模型的关键。 优秀的反馈是即时的–操作后马上有反应，在银行应用系统的异步响应模式中，通常以“请求已受理作为即时ack的反应”、明确的–清晰地指示状态变化或结果，银行系统如果报错，得给出明确的报错提示、匹配的–反馈的形式和强度与操作本身相称。下载文件时的进度条、提交表单后的成功提示或错误信息框，都是反馈的体现。缺乏反馈（点击后没反应）或反馈模糊（提示不清晰）会极大增加不确定性。让用户感到失控，是导致问题的常见源头。

利用约束引导行为。复杂系统中存在无数可能的操作路径，但并非所有路径都是正确或安全的。优秀的设计通过物理约束，比如特定形状的插头只能插入对应的插座；逻辑约束，如必须先填写A才能填写B，常见于客户填写表单信息时进行关联检查；文化约束–比如通用的红色代表停止/危险，以及语义约束（如旋钮的箭头方向指示旋转效果）来限制可能的操作选项，引导用户走向正确的行为。这些约束像无形的轨道，防止用户误入歧途，减少错误和认知负担。例如，转账提交后，一定时间内将按钮置为“灰色不可点击”，就是运用逻辑约束和文化约束建立心智模型的典型案例，常用于避免重复转账。

善用默认值与预设。面对大量可选项时，用户容易陷入“选择悖论”的焦虑。优秀的设计提供经过深思熟虑的、适合大多数场景的默认值或预设方案。这并非剥夺用户的选择权，而是提供一个安全的、合理的起点。用户可以在此基础上轻松地进行个性化调整，而不是一切从零开始。例如，软件的“推荐安装选项”、银行系统各种产品、核算、费用参数的初始化，都大大简化了初始操作，降低了入门门槛。

标准化与一致性。当不同的系统、不同的界面、不同的流程遵循相似的规则和模式时，学习成本会大大降低。一致性是易用性的核心原则之一。相同的图标代表相同的功能，相似的操作产生相似的结果，术语的使用保持统一。这使得用户可以将在一个系统中习得的经验（心智模型）迁移到另一个系统，形成规模效应，有效管理跨领域的复杂性。想象一下，如果每个网站的“保存”按钮图标和位置都不同，那将是多么混乱。

容错设计。 在复杂环境中，犯错是常态。优秀的设计能预见到可能的错误，并使其可逆或易于纠正。典型的如“撤销”功能、“幂等”设计银行应用系统是容错设计的典范。清晰的错误提示、提供简便的修正方式、以及防止灾难性后果（如删除前的二次确认），都能极大降低用户面对复杂操作时的恐惧和挫败感，鼓励探索和学习。

商行产品缘何复杂

以上是产品设计的一般通识，是需要在产品或方案设计中遵守的常识性守则。而对商业银行而言，因为行业的特殊性，使其产品或方案设计，更加不可避免地具备复杂系统的特点。这些特点体现在：

需求的多元性。不同于一般行业直接面向客户需求，以解决客户痛点为核心诉求的产品设计原则，商业银行的产品设计，需要根据产品特性，同时考虑“客户、合规内控、监管”三方面的需求。其中，客户需求自然是毫无疑问的，满足个人客户在日常生活、工作、学习中面临的支付结算、保值、资产增值需求，满足企业客户在生产经营、贸易结算中的金融需求等等；但在满足这些需求的过程中，因为银行业的特殊性–经营和管理风险，对应标的是“资金”，因此，对应的内控合规、营运安全求，同样非常重要，比如流动性安全、不良率的控制、审贷分离原则等等，均需要在产品需求中得到充分考虑；在内控合规之外，商业银行还面临不同于其他行业的强力监管要求，包括巴塞尔协议中对rwa、ifrs9等相关的刚性约束，以及不同国家、地区监管机构要求的诸如窗口指导、贷存比、mpa考核、信贷行业投向、占比等要求。举个例子，以设计小微企业贷款产品为例，需要统筹考虑3个方面的需求：

• 客户需求包括：目前客群画像、申贷方式（H5、APP、小程序…）、核身方式（五要素核身、活体检测….）、风控批核模型申请评分卡设计（不同指标的权重测算）、选择何种的还本付息方式、客户申请到放款的周期和流程设计、还款方式（是否支持快捷代扣等等）；
• 内控合规需求：贷款合同的条款设计是否合规、事前反欺诈方式、行为评分卡的评分模型设计、贷后预警信号的设计，放款是否需要人工审查等内部流程设计；
• 监管需求：信用贷款的报送口径，企业规模、类型的认定要素，是否符合产业政策等等，相关贷款产品的rwa、ftp、i9的影响以及对应的数据下送等等。

内部流程设计将直接影响客户体验。与一般的物理商品不同，商业银行的产品实际是一揽子服务的集合，在物理产品的世界中，如果一款产品品质极其过硬，后续客户与商家/厂家发生联系的概率不大，但银行产品与此不同，包括开户、大额汇款、贷款申请等在内的服务，都会涉及到流程设计，部分需要与银行的营业网点、反洗钱部门、集中作业部门发生联系，此时，流程设计中，哪些可以由计算机自动化，哪些需要人工进行审核，就不仅仅是银行内部降本增效的问题，而是会直接影响到客户的使用体验，比如一笔开户申请，A银行依靠技术手段，可以实现秒开，而B银行手工操作，需要个几天，客户会选择谁将显而易见；同样的例子是贷款（包括开票、开证）申请，如果一家银行依靠技术手段，可以做到秒批、秒贷（在有效实现风险控制的前提下），其带来的产品竞争力讲师不言而喻的。因此，从客户与银行建立联系开始，针对客户旅程的全生命周期进行有效的流程设计，将是产品设计面临的必然命题，而这通常涉及多个节点的跨系统交互。

差异化竞争优势获取需要跨域联动的设计。高维打低维的降维打击模式从来都是产品创新的灵感来源，微信红包的社交打金融，余额宝通过将货币基金的投资功能叠加支付功能的产品升维，都取得了巨大的成功。这种现象级的产品当然可遇不可求，但是商业银行中存在大量的存贷联动、公私联动的产品却是不争的事实，比如代发薪、担保承诺类业务中，授信业务与保证金存款的联动，法人账户透支产品中负债产品与融资产品的联动等等，这通常会涉及到跨业务形态、跨业务领域的复杂设计。

银行业系统架构分层的必然结果。在商业银行长期的组织架构和IT系统应用架构的演进过程中，逐步形成的“前、中、后”台模式，天然地需要进行跨部门、跨系统的协作以有效支持一款产品的有效实现。商业银行常见应用架构的分层分布，如下图：

从这一分层架构看，负债产品的产品实现，将不可避免地需要统筹考虑渠道层、公共服务层、账务作业层、数据层的功能需求；而融资产品，则在负债业务的基础上，还需要考虑风险控制层的功能实现；跨域联动类产品，则在以上两者之外，还需要考虑产品层的跨域联动，如果涉及支付业务，还需要考虑与外部的适配等等。

应对之道

商业银行的行业特点决定了银行产品不可避免地需要管理复杂，而在可操作性层面上，有什么可行的办法来管理这种复杂性呢，分为组织层面与个人层面。

组织层面。首先仍然是人才先行，针对性地建立一支优秀的跨领域复合型人才队伍（产品经理、体验设计师、流程设计师、业务架构师、开发经理等等），通过轮岗、深度参与大型项目等方式，培养队伍成员一专多能的专业素质；其次是有条件的情况下，建立有渠道、产品、风险、财务、运营、IT、合规人员组成的产品委员会，对新建设产品，充分听取各不同专业委员的意见和建议，对产品差异化竞争优势、预期回报、合规可行性等进行充分讨论和论证，产品建设做到谋定而后动；再次是有效的需求流程设计，比如最简单的，一份需求在签批环节，比如按流程经过风险、合规、相关配合的业务单位、营运、财务等的审阅，并充分发表意见，才可以进入到产品实施环节；最后，需要有充分的需求评审，将需求对应的业务背景、增长预测、功能说明、关联需求等，向相关方进行完整的阐述并取得支持，需求评审时可以要求需求以模版方式呈现，如下图所示需要覆盖的内容：

个人层面。无论是产品经理、业务架构师还是开发负责人（一般也是技术方案设计者），首先是需要具备一些关于产品设计的通识性知识，比如知道基本的关于反馈、约束控制、有效心智模型设计的知识，了解基本的交互设计基础知识；其次是需要养成系统性思维能力，多以全局视角审视和思考问题，强迫自己尽可能“知其然，且知其所以然”；再次是不断学习，在深化本专业知识的基础上，尽可能拓展“多能”的跨领域业务能力，在知识的深度和广度上，都有所精进（毕竟艺多不压身）；最后是要多实践，尽量多地主动请缨，参加一些大型项目或产品研发，如果条件允许，可以考虑在一个领域待够3~5年后，寻求感兴趣的领域转岗锻炼，“纸上得来终觉浅、绝知此事要躬行”，理论无论写的多好，都不如动手来得更有体感。

显性与隐性特征设计

每一个让用户感觉“简单好用”的产品或功能背后，都是产品设计者对产品显性特征和隐性特征的统筹考虑，并通过一体两面的兼顾实现和谐统一的最终结果。

产品经理的双面视角

如何做好用户体验设计

怎么抽象复杂系统交互

持续敏捷

演进思维要求在面向不确定的市场与激励的竞争时，需要快速低成本试错、快速迭代，即用最小的可行性产品验证假设，总之，需要进行敏捷。这一源自互联网行业的方法论，在印象中应该偏稳健、保守的商业银行，也被越来越多地推广及运用。

为什么需要敏捷

商业银行的产品敏捷，最直接的原因大概是“卷”，这大概是中国大陆，或者是带互联网基因的商业银行–比如Shoppee Bank，特有的现象。“卷”是竞争，有竞争才会有进步，物竞天择，面对市场的波动性、不确定性、复杂性和模糊性（VUCA），那些能够比竞争对手更快学习、决策和行动的机构，将获得显著的竞争优势。除了竞争之外，商业银行的一些经营特点，也是对敏捷能力的现实要求：

因应监管政策变化的要求。金融行业的强监管特性、央行的货币政策变化，都要求商业银行的业务开展需要迅速适应政策变化的要求。如2013年至2016年期间狂飙突进的影子银行业务中的“产业基金”模式、“票据资管”、“黄金租赁”业务等等，都是只在一定时期内被允许的业务，在一定时期内为开展这类业务的商业银行创造了客观的利润。其他的，诸如央行LPR利率的推出、针对小微的再贷款专项计划、再贴现利率调整对票据市场的调节、国家金融管理局对消金公司杠杆率、同业拆入规模、担保增信的限制及由此影响商业银行联合贷、助贷业务的发展，都需要商业银行进行快速的反应，在资源投放、政策修订、产品调整、系统开发等方面，快速作出反应。

市场时机的的快速把握。包括以下几类，1）、面向特定热点事件、或者特殊时间窗口的产品设计。比较有代表性的，如AlipayHK为香港地区年底缴税专门推出的缴费易产品（包括营销补贴）、银行当港股行情好时为投资者开发的IPO融资产品及专项孖展授信产品、因应黄金行情而开发的积存金产品等等；2）、以快制胜的市场竞争需要。以对公业务领域为例，高价值头部对公客户通常会成为多家商业银行的潜在竞争客户，此时，而他们需要的产品通常都需要定制化，谁能以最快的速度满足从一线客户经理传递上来的客户需求，谁就可能获得先发优势，获得更多的业务机会。

经营特点的客观需要。商业银行生息资产投放的特点及KPI的考核需要，尤其是在信贷投放领域，新产品的建设往往需要在年底前完成，并在来年通过开门红，甚至在上一年年底就产生足够的规模，然后在未来一年中的尽可能长的时间内，带来经营收益。这种情况在贷款产品领域经常发生，常常需要贷款产品的产研团队能够对业务作出敏捷响应。其他因诸如适应季末、月末存款规模等考核要求而进行的产品开发，也在此列。
当然，最终还有一点更现实的，就是强KPI考核下的压力传导。大致有如下几种情形：第一自然是自上而下的压力传导。来自于行长、分管副行长、各业务部门总经理依据全行经营战略，分解落地而需要研发产品，在相当一部分机构中，管理者似乎缺乏耐心，大多按“一万年太久、只争朝夕”进行要求，一旦提出，就希望尽快看到成品；二是产品团队本身，在对产品团队强考核的商业银行，产品团队需要要么通过质量（产品完成的营收、利润数字）、要么通过数量（没有功劳，总要抢个苦劳），作为KPI的关键支撑，由此带来的所谓“敏捷响应”需要；三是业务一线，分支行、客户经理发现的市场机会（或误以为的市场机会），其中一部分除了需要关系营销外，还需要银行中后台以最快的速度为前线提供好的产品、解决方案以满足前线的需要。
总而言之，”持续敏捷”能力建设，对银行产研团队而言，早就不是一个选择题，而是银行产研团队生存与发展的必修课。

敏捷的误区

然而，在实际工作过程中，“敏捷”却常常被玩坏了：将违反科学规律、极致压缩研发周期的蛮干当成敏捷；将缺乏规划的功能堆砌，以战术勤奋替代战略懒惰当成敏捷；将scrum的引入，完成各种敏捷工具的部署，实则不计效果的形式主义当成敏捷；将频繁的变更、碎片化的优化当成敏捷，勤奋地对客户进行打扰。几种在工作过程中常见的敏捷误区包括：

多加资源就能缩短产品研发周期。这一点常见于很多银行业机构，当一个产品、项目研发需要8个人，3个月的周期时，业务方、管理者经常会产生的一种迷思是，加到20个人，能不能将研发周期缩短到2个月？这就好比一个妈妈要怀胎10月，才能生出1个孩子，现在给你两个妈妈，能不能帮忙将生孩子的周期压缩到6个月？这一误区不仅见于银行产品、项目研发，也常见于银行战略中的所谓加大对“金融科技战略”的支持–让科技部门多招人。事实上，团队也好、项目也罢，人都不是越多越好（当然更不能人手不足），维持一个“小而精”的团队，是研发团队或者项目组织的最佳策略。《人月神话》一书中，弗雷德里克・布鲁克斯提出，向进度落后的项目中增加人手，往往会使进度更加落后。这是因为软件开发是一种复杂的创造性工作，随着团队规模的扩大，沟通和协调的复杂性会呈指数增长。团队成员之间的沟通渠道数量可以用公式n(n−1)/2来计算，其中n为团队成员数量。例如，当团队有5名成员时，沟通渠道有5×(5−1)÷2=10条；当团队扩大到10名成员时，沟通渠道则增加到10×(10−1)÷2=45条。如下图示意，曲线处于最低点时的人员规模，才是最佳规模，跨过最低点后，随着人手的增加，效率反而下降：

碎片化需求而非价值交付。敏捷多数时候离不开迭代，迭代最终表现为做了多少次发布，这最终导致很多产研团队有意或无意地误入歧途：将需求拆得稀碎，发布的内容能不能给客户带来闭环的价值不重要，重要的是完成了多少次需求发布。这种本末倒置的做法，本质上是一种”交付的幻觉”——团队沉浸在频繁交付的成就感中，却忽略了每一次交付是否真正解决了用户的问题或带来了业务价值。其典型的症状包括：1）、功能肢解。一个完整的用户旅程被拆分成多个互不关联的迭代，用户需要等待数月才能体验到一个完整可用的功能；2）、指标异化。团队关注的不再是“是否提升了客户满意度”或“是否增加了业务转化”，而是“本期完成了多少个用户故事点（需求点）”；3）、伪敏捷。保持着两周一次的发布节奏，但发布的内容多是 Bug 修复、体验调优或边缘功能，核心痛点始终得不到解决。

形式主义敏捷。形式主义敏捷是许多组织在推行敏捷过程中最容易陷入的误区，通常是在“领导的亲切关怀下”，引入所谓的“敏捷教练”，然后将Scrum的几件套–站会、看板、待办事项清单一一执行到位。笔者的亲身经历，本来运转良好的产研团队，在敏捷教练的一通指导下，搞得怨声载道，开发效率急剧下降。其问题表现包括：1）、晨会是形式主义的重灾区。一群人神经病式的围成一圈本身就挺有喜感的，每个成员再按顺序讲一圈“昨天做了什么、今天要做什么、遇到什么问题…”，这简直是荒谬。第一，这么公开的场合，能听到多少真话？第二，产品负责人或者研发负责人，如果连团队成员的工作进度、项目风险都不掌握，还要通过晨会了解的话，那就要赶紧换人了。如果领导者只是想通过晨会搞服从性测试，那请继续，如果是为了敏捷，赶紧取消才是正道；2）、看板成为额外的负担。除了给领导表演外，谁会真的通过看板去了解项目进度。真实的项目进度只在钉钉、企微的聊天记录中，只在实实在在的文档和代码中，只在团队日积月累的相互信任中。所谓看板，不但增加成员的双重填写压力（他们还得在项目管理工具中再填写一遍），还常常弄成表演者的舞台–代码一般是没有领导看的，看板可不一样，做的花样百出指不定哪天就被表扬了。凡此种种，不一而足…敏捷的本质是适应性和快速响应变化，而不是对特定流程的宗教式恪守。当团队忙于完美执行敏捷仪式而忘记了为什么要这样做时，敏捷就已经失败了。

勤奋的懒惰。在腾讯的产品哲学中，有一条非常令人印象深刻，即“避免勤奋地打扰客户”。我们看到，腾讯系的产品很少会发生那种交互习惯被改的面目全非的情况，这后面一定包含着对产品迭代的严谨论证和产品功能上新、体验改变的充分论证。但与此相对，银行业机构似乎并不如此，笔者自己用过的手机银行app，都经常出现过段时间就改头换面一次的骚操作，一个手机银行app，居然一路从1.0，发布到1x.0…事实上，在产品进入成熟期后，更多的精力应用用在功能细节、交互体验的反复雕琢，对特别成熟、用户早就已经习惯的产品而言，什么都不做，也比瞎折腾要好。在”敏捷”的旗帜下，产品很容易陷入功能主义的误区，堆砌功能（甚至是堆砌产品）本质上是用“战术的勤奋掩盖战略的懒惰”，不仅浪费大量宝贵的开发资源，还会让产品变得臃肿不堪，给用户带来困扰。

实现持续敏捷

事实上，真正的敏捷必须是以价值交付和用户体验优化为中心的。每一次迭代都应回答一个问题：”这次发布为客户或业务带来了什么新价值？”如果答案不明确，那么这次迭代可能就是不必要的。
实现持续敏捷，不能仅仅停留在引入Scrum仪式或部署管理工具上。这些形式若没有内在能力的支撑，终将流于表面。真正的敏捷源于以下核心要素：

建立良性的敏捷评价机制，始终坚持价值驱动下的敏捷。1）、迭代评审机制。每次迭代，都需要向管理者及敏捷小组成员说明这个迭代“可验证的用户价值”是什么，而不仅仅是以提出需求，完成开发任务为目标。哪怕这个价值很小，它也应该是一个完整的、可用的功能切片。2）、建立清晰的价值评估框架。在迭代开始前，要明确“如何验证这个功能成功？”–是通过用户反馈、业务指标还是A/B测试？3）、敢于说不。对那些不能带来明显用户价值或业务价值的需求（如一味的领导偏好、盲目的竞品跟随），产品经理、研发经理要勇于拒绝，保持团队的专注力。4）、用成果而非产出衡量敏捷的成功：团队追求的不应是发布了多少功能，而是通过这些发布获取了多少用户增长、提升了多少客户满意度或降低了多少运营成本。

充分的组织准备，跨职能团队与授权机制建设。传统银行科层制组织结构是敏捷的最大障碍。组建跨职能的特性团队(feature team），将产品经理、体验设计师、运营经理、开发工程师、测试工程师（在融资业务中，通常还会加入风险人员）等凝聚成一个目标明确、被充分授权的小型作战单元，是进行能力闭环，形成团队默契，通向敏捷的重要保证。互联网企业中，除了按矩阵模式进行临时的团队编组外，还常常将一个个跑出来的产品线固化下来，形成有福同享、有难同当的利益共同体。这种”产品+研发+运营”的铁三角团队，在被赋予明确的业务目标和对实现路径的决策权后，需求决策周期、需求澄清周期、研发周期、发布周期都将得到大幅压缩。

服务抽象与架构支撑。后端架构的灵活性是前端业务敏捷的基石。以信贷业务为例，通过共享服务抽象，可以将指标模型、决策引擎、账务记账、额度计算、押品管理、客户评级，分别抽象成独立的共享服务，在零售信贷、小微融资及一般企业级授信业务中，共享这些能力，支持信贷类产品在推陈出新时，只需要改变准入模型、变化还款周期或还款方式、变更担保模式等等，极大压缩产品研发周期，实现有效敏捷。

需求分析与分解。Scrum从来都不是敏捷的核心，需求的分析与拆解，按冰糖葫芦式组织一个一个交付闭环的功能点，才是敏捷的核心与关键。它要求产品经理能够精准捕捉用户和业务痛点，确保解决真正有价值的问题按MVP（最小可行产品）思维，优先被交付；它还要求产品和交付团队，能够将大型需求拆解为独立的、可交付的小用户故事。以下是腾讯8分钟产品课中分享的产品迭代原则，以支付业务为例：

他将产品需求分为“安全可用”、“使用体验”、“扩展兼容”、“生态体系”四级，与马斯洛需求层次理论类似，因为支付涉及到资金安全，支付资金的安全、避免陷入反洗钱的麻烦，就成为支付产品的最基础需求，这个都做不好的话，遑论其他；之后是使用体验，而使用体验的核心便是支付成功率，Lucy（彭蕾）在带支付宝团队的时候，其重要贡献之一，就是大幅提升了支付宝的支付成功率；再之后是能力的扩展，对多类型支付工具的兼容；最后是构建庞大的生态，形成产品的深度护城河，在支付业务中，这包括线上、线下收单场景、商户的推广，用户使用习惯的培养等等。

Devops体系的构建。如果说服务抽象为敏捷提供了可复用的能力积木，那么DevOps体系则是确保这些积木能够被快速、可靠、高质量组装和交付的流水线。如果一次需求上线需要经历冗长的部署文档编写、人工申请、多环境手动部署与测试，那么敏捷必然就会以IT人员的加班、人肉运维为代价。Devops体系的构建需要在至少3个方面完成能力建设：1）、自动化工具链贯穿全过程。从开发人员提交代码开始，通过版本控制工具(如Git）、持续集成（CI）工具自动触发编译、单元测试与代码质量扫描；通过持续交付（CD）工具自动完成测试环境、预生产环境乃至生产环境的自动化部署与回归测试；最终通过自动化监控工具持续观察应用性能。这条工具链将人工从重复、易错的流程中解放出来，使数小时内完成一次高质量发布成为可能。2）、实现基础设施即代码。通过代码来定义和管理基础设施，使得服务器、数据库、负载均衡器等资源的申请、配置与销毁均可通过自动化脚本完成，实现基础环境的版本化、可追溯和快速重建，为业务的快速弹性扩缩容奠定基石；3）、构建完备的可观测性体系。构建包括日志、指标核对与链路追踪的全方位可观测能力。实现从敏捷开发态下，生产运维由“被动救火”到“主动预警”乃至“故障自愈”的演进。

结语

在组织架构设计、文化特点、支撑体系迥异于互联网的传统商业银行，持续敏捷对身处前线的产品经理和开发人员而言，多数时候是一种无奈的奉命行事。但在局部的微观生态中，它仍然应该是产品经理、开发经理、运维经理应该努力追求的目标。因为要达成真正的持续敏捷，它要求我们能够练就一双慧眼，能够洞悉用户真正的问题和关键痛点，对最小可验证需求进行提炼；它还要求我们不断掌握更多的业务知识，在专业能力的牵引下，去规划产品的迭代方向；它还要求我们去理解和驾驭复杂，养成“系统化”、“结构化”思考问题的习惯；它更不断启迪我们不断去思考如何构建能够快速响应的团队、架构与文化。而所有这些方面的历练，终将会千磨百炼出一个更好的自己。

作者：高尔斯基

HeyGen 把视频分成了两类：沟通类视频和电影类视频。沟通类视频包括业务更新、教程、采访、播客、解释性视频，目的是说明、告知或传达信息，最适合基于脚本的编辑。电影类视频是高制作广告、电影、音乐视频、预告片这种，目的是打动、激发或娱乐观众，最适合时间线编辑。

HeyGen 的重点是让沟通类视频对所有人都可用。他们说的”所有人”是真正的所有人，从初学者到专业人士的每一种技能水平。产品足够简单，任何人都能在几分钟内制作出高质量的视频。

整个方法论的核心就一句话：快速行动，成为绝对最佳。乘着 AI 浪潮，接受研究中的不确定性，押注未来六个月，构建随着模型改进而自我升级的灵活产品，同时不牺牲质量。这种快速响应变化、小步快跑的思路，与Scrum培训中迭代交付、拥抱变化的核心原则一致。

传统时代是在稳固基础上构建，为长久性优化，提前规划 12-18 个月，打磨好再发布，按序开发。AI 时代的 HeyGen Way 是乘着科技浪潮，为自动改进而构建，实际规划 2 个月周期（与模型升级周期一致），发布以学习，并行试验。为什么是两个月？这个周期与模型升级周期一致，既能快速调整策略又能保持专注，这也体现了Scrum认证培训中对迭代周期设定的科学逻辑。

他们的节奏包括：两个月路线图规划，与 AI 进展周期同步，与领导层、技术负责人和产品经理深入回顾并制定策略。6-12 个月战略押注，预测并为下一次重大突破做准备。每两周承诺清单，产品和工程共同决定优先级。每日发布，改进、特性或实验每天上线。这种高频同步与快速交付的节奏，可通过敏捷培训中的团队协作技巧进一步优化。

实验流程很快：第 1 天定义假设和成功指标，第 2 天构建真正最小化的 MVP，第 3-5 天向部分用户发布，第 2 周分析学习并决定下一步。好的实验要快（以天为单位不是周），科学化且数据驱动，提供明确信号（继续、转向或停止），做大动作而不是小修小补。大多数实验会失败，这是预期之内的。带着学习的失败等于胜利，没有学习的失败才是真正的失败。

提出五大运营原则

第一，速度至上。

在 AI 时代学习最快的团队获胜，就是这样。几天交付不是几周，有疑问就发布实验，进展的势头比完美更重要，迟缓是唯一不可原谅的罪过。速度不仅仅关乎执行力，更关乎心态。如果你把”正确”放在第一位，那就走得太慢了。不要害怕出错，要怕的是学习得太慢。这种以速度和学习为核心的导向，也是企业管理培训中敏捷转型模块强调的组织效能提升关键。

第二，拥抱技术浪潮。

别再追求技术稳定性，那并不存在。AI 基础每两个月就会变化，要把产品设计成在模型改进时能自动提升，构建预期会变化的抽象层，让产品体验随着 AI 进步而前进。

第三，表达异议并承诺执行。

现在是战争时期不是和平时期，每个人都贡献想法和反馈，但决策必须迅速。一旦做出决定就全力以赴，即便曾经不同意。由于缺乏承诺导致的战略缺陷，比能迅速修正的不完美决策更糟。这种快速决策与高效执行的平衡，可通过Scrum培训中的团队决策机制训练强化。

第四，通过创新实现用户价值。

用户喜欢能解决问题的产品而不是漂亮界面。他们在用 AI 改变人们制作视频的方式，打造以前不可能实现的神奇体验。但不解决真实问题的创新毫无价值。AI 产品的能力因用户技能而有巨大差异，他们的责任是教授用例而不仅仅是功能，衡量视频质量而不仅仅是视频创建。

第五，自建还是购买的规则很简单。

无论哪种方式能提供最佳用户体验就做哪种。比如头像视频模型内部构建，因为没有外部供应商达到他们的质量标准。语音用外部提供商，因为质量足够且资源受限。没有自我，只要结果。

所有团队遵循相同核心结构：产品经理 + 工程 + 设计 + 数据科学。产品经理是决策和优先级设定的主要推动者，与领导层直接合作制定战略，负责每个功能背后的”为什么”，在工程、数据科学、设计之间协调。在 AI 时代，产品经理要构建可用原型跳过传统规格书，将 Figma 设计或 UX 原型作为文档，为尚不存在的能力进行规划，非常熟悉市场上所有 AI 工具并每天使用。

工程师以最快速度制定并执行决策，提供产品经理可能忽视的技术见解，为灵活性和快速迭代进行架构设计。要使用 AI 助手编写代码以提升速度，每个人至少比两年前高效 3 倍。构建可演化为生产系统的原型，专注于构建而不是文档。这种高效协作的团队模式，与Scrum认证培训中跨职能团队的构建理念高度匹配。

设计师的使命是定义简单却卓越的体验。作为面向视频的创意工具，设计需要达到世界级水平。设计的首要原则是简洁，让功能在 AI 中可行不难，但在保持高质量的同时让它易于使用极为困难。设计师是”对所有人（包括奶奶）都极其简单”这一原则的主要守护者，如果奶奶都不会用，设计师要标记并修复它。

构建原型遵循”两人规则”：一名产品/设计人员加上一名工程师总共 2 人构建原型。不会为了保护每个人感受而追求共识，目标是加速流程尽快在市场上验证想法。流程是先做原型快速构建测试，然后证明其可行用真实用户验证概念，接着设计打磨将体验优化使其契合产品框架，最后所有升级到生产的功能都必须经过精心设计。

核心产品 vs 增长产品

核心产品团队专注基础产品体验，构建定义 HeyGen 是什么以及能做什么的功能，以用户体验质量、功能完整性和长期产品愿景为优化目标。标准很简单：在每一个体验上都要绝对做到最好，低于这个标准就是不够好。怎么做到？速度极快地推进，比竞争对手多迭代 5 倍。他们的目标是零缺陷，作为创意工具可靠性是用户信任和工作流程连续性的基石。

增长团队是实验引擎，以速度、学习和影响力为核心构建。他们不仅仅交付代码，而是交付结果。在 AI 时代代码廉价影响有价值，要优化以快速实现影响。安全的实验不是真正的实验，目标是通过承担明智风险、更大胆假设来更快学习，愿意快速承认错误这样下次才能更快做对。这种聚焦结果与快速试错的增长策略，也是企业管理培训中创新管理模块的重要案例。

沟通与反模式

沟通原则是首选异步，在分布式办公环境中尽可能利用异步沟通。如果任何团队成员与超过 5 人的群体有超过 3 次同步会议就要提出警示，时间应花在构建上而不是开会。决策通过 Slack 立即沟通，明确单人负责与执行时点，团队之间完全透明。反馈要直截了当，好工作就是好差工作就是差，关注工作而非个人。

要避免的七宗罪包括：花几周为规模做设计的完美架构（实际问题是还没用户真正喜爱）、几个月面试没有交付的研究瘫痪、等待 AI 成熟的稳定基础幻想、人人都同意等于无人关心的共识陷阱、”还没准备好”的质量借口、6 个月秘密开发的大爆发发布、”我们已经投入了这么多”的沉没成本谬误。这些反模式的规避，也需要团队通过敏捷培训建立正确的工作认知与行为习惯。

在数字化浪潮奔涌而来的今天，敏捷不仅是一种技术方法论，更是一种面向未来的组织能力。2025年5月24-25日，ScrumAlliance冠名赞助、优普丰作为核心组织单位牵头举办的Regional Scrum Gathering™杭州敏捷嘉年华大会（#RSGHZ25）圆满落下帷幕。大会以“敏捷与智能，慧动乾坤（Agility with Intelligence）”为主题，吸引了全国敏捷从业者与企业代表齐聚一堂，分享创新实践、探讨行业未来。

作为大会重磅环节之一，“2025年度优秀敏捷实践”评选结果于大会主论坛正式发布，四大类奖项，涵盖成果、交付、创新及智能实践多个维度，旨在树立敏捷落地标杆，推动行业持续进化。

「最佳敏捷成果奖」

该奖项聚焦敏捷转型中所带来的可量化突破性价值，表彰在提升交付效率与客户满意度方面实现重大跃升的组织与个人。
🏆 获奖名单：

• 宝洁中国数字化产品研发团队
• 富卫信息科技（广州）有限公司
• Frank Li（ABB）

他们通过构建本土化敏捷体系，结合数字化能力的升级，打造了具备行业复制价值的提效降本实践范式，为敏捷转型提供了“可落地、可推广”的生动样本。

「卓越交付实践奖」

本奖项旨在表彰在复杂业务环境中依然能够实现高质量、持续交付的敏捷团队，强调端到端流程优化与质量内建。
🏆 获奖名单：

• 中兴通讯中心研究院 AGS 架构度量团队
• 江苏常熟农村商业银行股份有限公司
• 广州骏伯网络科技有限公司

这些团队构建了灵活稳健的交付体系，以高效协作机制快速响应业务变化，实现了业务连续性与敏捷能力的双重提升。

「敏捷创新应用奖」

该奖项鼓励组织在敏捷实践中突破传统边界，开展跨业务、跨职能的创新融合。
🏆 获奖名单：

• 默克雪兰诺有限公司
• 罗氏诊断产品（上海）有限公司
• 杭州妙盼企业管理有限公司

他们将敏捷思维延展至组织文化、协作模式、技术架构乃至商业模式，打破“部门墙”，构建了融合研发、市场、客户、商务的新型协同范式，展现出极强的行业引领性。

「最佳敏捷与智能实践奖」

此奖项关注敏捷与智能技术的深度融合，表彰在数据驱动、AI自动化等领域的前沿探索。
🏆 获奖名单：

• 清图数据科技（南京）有限公司

他们通过构建智能看板、AI辅助迭代管理等工具链，助力企业在智能制造、智慧金融等场景中实现业务敏捷化与智能化的协同演进，成功树立了“敏捷+AI”融合应用的行业标杆。

关于大会

Regional Scrum Gathering™ 敏捷嘉年华大会是 Scrum Alliance 官方授权的全球敏捷盛会，自2008年起持续推动Scrum和敏捷理念在全球范围落地。2025年杭州站大会由优普丰作为核心组织者牵头来自杭州、北京、天津、上海的敏捷社区志愿者共同举办，，集聚国内外顶尖敏捷实践者、教练与行业专家，以“非盈利、重实践”的理念，为企业与个人打造一个开放、共创的学习交流平台。

本次大会设有1个主会场与5个专业分会场，10余场高质量工作坊，聚焦业务敏捷、AI赋能、制造业转型等多个前沿主题。两天时间，40余位演讲嘉宾倾情分享，近300名参会者互动碰撞，共同见证“敏捷与智能”时代的力量觉醒。

事情的起因是我想快速拿到一个国际认证又不想花太多钱和时间，偶然得知了Scrum.org的PSM II认证，国际认证、没有强制培训要求和前置认证要求，正中我心趴~💓

既然不要求参加培训，只要考试通过就能拿证，原本我是想裸考的，但是考试费一次得$250，且不通过就得重新付款考试，为了避免浪费，我决定先看看有没有类似考试辅导的服务，有把握了争取一次考过。

正好在一个敏捷交流群里看到优普丰小姐姐发的「备考辅导服务」，说可以“帮助学员准备并快速通过 Scrum.org 的 PSM II / PSPO II 英文考试，手把手教你一步步拿下专业Scrum Master证书”，最重要的是只要298元，试试又何妨？

结果就是我通过了考试并且拿到了PSM II认证，真正的“亲测有效”，第一时间来发攻略了~希望能帮到你🌹

首先来看我们为啥要考PSM认证？

大家都知道，敏捷🔥了很久了，被广泛实践证明是行之有效的方法，且在现在这种形势下，越来越多的不确定性，导致更多公司和个人更看重敏捷，因为敏捷就是帮助我们在面对不确定的环境中寻找相对确定的方向和行动，抵抗不确定带来的风险。（我学习敏捷后的理解，是不是更深刻😁）

由此，敏捷教练这个职位也显得尤为重要，很多人会考取敏捷或Scrum Master认证来提高自己的专业性和竞争力。除了大家熟知的Scrum Alliance 颁发的 Certified ScrumMaster (CSM/CSPO) 系列认证以外，国际上也存在其他体系，例如 Scrum.org 机构颁发的 Professional Scrum Master™ (PSM/PSPO) 系列证书。

我还查了一圈儿，想看是否有前辈给到的备考参考书籍和博客清单，结果发现这个系列证书的备考，除了《Scrum 指南》之外，不需要任何其他东西，去官网注册参加考试，通过就可以拿证。这对于我们这种刚接触Scrum 并希望在最短时间内获得认证的人来说，简直正中心趴💓如果是那种经验丰富的Scrum Master，那根据Scrum.org 网站的说法，你可能都不会在考试中遇到困难。

而且很重要的一点是，官网虽然推荐在考PSM II认证之前先学习PSM I，但是，但是来了！这不是强制先决条件，就是说~我们可以直接跳考更高级别的PSM II甚至PSM III！（带大家卡bug来了~）

显而易见，更高级别的认证更能为职业竞争力加分，学习下来我发现，PSM II 涵盖了很多实用的引导技巧，和教练要素，可以帮助我们应对团队挑战，不仅仅是拿个证而已。

Professional Scrum Master II （PSM II ）考试是啥情况？

1. PSM II 考试共有 30 道题，考试时间为 90 分钟。每道题的作答时间是 3 分钟。
2. 考试无需任何先决条件（你并不需要参加任何认证培训）。
3. 考试费用为 $250。
4. 纯英文考试，所有题目都是选择题。有单选也有多选。

考试的难度咋样？

PSM II 认证不要求先参加培训，可以直接去考，本来我打算直接裸考的，但是一看考试费一次得$250，没通过还得重考。为了不浪费💰，我还是决定先找个考前辅导，有把握再去考试。

结果证明我是对的，PSM II考试要说难也不难，但是说不难吧，有的题目是真的有点绕，好在正式考试之前辅导老师带我们做了考前模拟考试，还有易错题的讲解和考点解析，要不还真有点悬~

看个例子你就知道了~

PSM I 和 PSM II 考试题目有一点区别。大部分题目比较长，但意思和 PSM I 考试一样。

• PSM I 是：2+2 是多少？
• PSM II 是：小美有 20 元，小帅有 200 元，两人都从大壮那里拿过 2 元。大壮想从两人那里拿回自己的钱，那么大壮需要从小美和小帅那里一共拿多少钱？

两种情况下的答案都是 4，但阅读 PSM II 问题所需的时间会比阅读 PSM I 考试所需的时间多一点。

（其实我没参加过PSM I 考试，这个例子来自我的备考辅导老师😁）

英文不好咋办？

现在翻译软件和 AI 翻译非常普及了，英文不好已经不是什么障碍了。

Scrum.org 的 PSPO II / PSM II 认证适合谁？

1. 希望较低成本、快速对Scrum理论有基础了解的朋友。
2. 希望获取国际认证，增加自己面试、就业竞争力的朋友。
3. 希望对自己的敏捷知识掌握情况进行自我测验评估的朋友。

如何准备并一次性通过考试？

你要么通过，要么不通过。你要么参加考试，要么不参加，但不要把钱浪费在以下事情上：

1. 考试题库——不要只买题库，证书是个加分项，但最终还是根据你的知识而不是你的证书来测试你。
2. 购买专门为考试设计的书籍。
3. Udemy 等网站上有 1000 多个无意义的问题和考试专用视频节目。
4. 在 Facebook 和 LinkedIn 上随机向用户支付费用。
5. 专为这个认证设置的培训课程——官网明确表示任何人可以不参加培训直接考试。如果想系统学习敏捷，我个人更推荐Certified ScrumMaster（CSM）认证课程，知识覆盖和实操性更强，而且还能再拿一个国际认证~

以上操作对你几乎没有帮助。

不需要参加培训课程就可以参加考试

scrum.org机构英文官网明确表示，任何人可以不参加任何认证培训课程（通常是2天），0经验、0门槛，只需要缴纳考试费用便可去到唯一英文官网 www.scrum.org 网站上注册，参加他们的在线考试，考试通过后就可以获取证书，终身有效。(出处：https://www.scrum.org/assessments/professional-scrum-master-i-certification)

如果你想像我一样有把握地一次通过考试，强烈推荐我的备考老师🔥

前面说了，任何人都可以直接考试，但是没通过的话每次考试费还是很贵的。

我是在一个敏捷交流群里，看到优普丰的小姐姐发了一个海报，介绍了她们的备考辅导服务，说可以“帮助学员准备并快速通过 Scrum.org™ 的 PSM™ II / PSPO™ II 英文考试，手把手教你一步步拿下专业Scrum Master证书”，最重要的是只要298元，试试又何妨？

结果是我亲测有效。备考老师很详细地介绍了报考指引、敏捷关键知识点，易错题解析、模拟考试、一页纸考点等，还送了70多个敏捷相关的视频和电子书，不仅是应对本次考试，还有后续学习敏捷的资料。突然想到这确实也符合优普丰的一贯原则，“玩真的培养人”。（拿到证后，成为迷弟的一天~）

备课辅导服务是怎样的？

以下是小姐姐的广告时间~

「PSM II和PSPO II备课辅导服务」开班！现在报名特惠~~扫描海报二维码直接报名，随报随学。

提供中文翻译指导/考试模拟题，手把手教你全英国际认证+1，轻松考，不求人！可获得丰富的「在线学习大礼包」70+个视频&4本电子书！！！

免责声明：

我们不提供认证培训课程、认证考试或证书，请务必到 www.scrum.org (英文官方网站) 注册、考试和查询证书，不要轻信其他类似网站，谨防诈骗。

PSM / PSPO是 Advanced Development Methods, Inc.（d/b/a Scrum.org）的商标和/或注册商标。

本备考服务 与 Advanced Development Methods d/b/a Scrum.org (ADM) 无关，也不构成 ADM 对任何产品、服务或观点的认可。

阿里AI这次真的杀疯了！

阿里通义万相开源 Wan2.2，全球首个搭载 MoE架构（混合专家） 的视频生成模型。

• 模型开源地址： GitHub：github.com/Wan-Video/Wan2.2 HuggingFace：huggingface.co/Wan-AI 
• 如果你想直接使用，也可以直接上 wan video 的官网。在线试用：wan.video/generate

（官方的提示词构图&运镜提示词整理在文末，供大家参考）

这次开源了三个模型：14B文生视频模型、14B图生视频模型，和一个5B的同时支持文本/图像生成视频的可以在 4090 上跑的模型！

总参数27B，但每次推理仅激活14B，这意味着什么？省电50%的同时还能输出电影质感！

输入关键词文字，秒变大片的视频内容。

Wan2.2这次的开源，意味着普通人用低算力、低成本，也能快速产出电影美学镜头——从此拍视频如发朋友圈般简单。

正如网友们所言：“AI导演不抢盒饭，只帮你圆梦奥斯卡！”

附：提示词构图&运镜提示词（部分生成视频示例在上面的视频号视频中）

提示词1：在高空飞行的喷气式飞机机翼上，一位身着红白体操服的选手正以猫式行走姿态缓慢前进，强风将她的发丝与衣摆向后扬起。突然，她猛地腾空，完成一个凌空侧手翻，稳稳落在金属机翼边缘。紧接着，她在呼啸的气流中连做两个侧空翻接转体，手臂像风车般在风中挥出极限的弧线。最后，她以单脚点地稳住身形，指尖轻触机翼边缘，在轰鸣的引擎声中完成这不可能的一刻。远景镜头拉远，整架飞机穿越层云，仿佛整个世界都为她的专注与平衡屏住呼吸。

提示词2：一个宇航员在火星红色荒原上独自奔跑，脚下扬起细尘，动作因低重力而带有弹跳感。镜头贴地后跟，远处风尘柱缓缓升起。阳光斜照，头盔倒映着两颗升起的火星卫星。每一步都仿佛要飞离地面。镜头最后透过黑色面罩特写宇航员惊慌的脸。

提示词3：黄昏，剪影，混合色调，全景，定场镜头。视频从高空俯拍开始，镜头缓缓靠近一根横跨鳄鱼潭的独木。数十只鳄鱼潜伏水中，鳞甲闪着冷光。独木之上，一位身穿竞技体操服的少女以猫式行走姿态缓慢前进。周围是风声、水声与鳄鱼尾巴拍击水面的低响，空气紧张得仿佛凝固。突然，她腾空而起，下一秒倒立在独木上，动作精准无比，底下的鳄鱼瞬间拍打水面，张开嘴。随着最后平衡的恢复，镜头缓慢上升，俯瞰她伫立在细细独木上的身影与暗流涌动的鳄鱼潭。

提示词4：在土卫六的一片结冰湖面上，一只在滑滑板的橘猫在橙色浓雾中刻画出优美弧线。冰层轻响，滑行时溅起甲烷霜雾。镜头紧贴冰面滑行，跟踪长长的滑痕。滑板小猫缓慢旋转，尾迹微光闪烁。远方天际中透着模糊的土星光环轮廓，一艘巨大的飞船在陨落。

提示词5：巨龟 

• 巨物主体： 远古玄武岩巨龟，体型如连绵山脉，龟壳上覆盖着森林与瀑布，皮肤是布满沟壑的岩石。 
• 尺度参照物： 一架正在飞行的波音747客机，在巨龟面前显得如同蚊蚋。 
• 场景： 晨曦时分的云海之上，阳光穿透云层。 
• 运动与交互： 巨龟极其缓慢地转动它的头部，布满智慧的巨大眼睑缓缓睁开，瞳孔如同一座深湖。客机从它眼前平稳飞过，在瞳孔中留下小小的倒影。巨龟呼出的气息形成了可见的气流，让飞机周围的云雾产生了轻微的扰动。 
• 美学控制： 史诗感，航拍长镜头，焦点从飞机转移到巨龟的眼睛，4K电影画质，突出巨大的尺度感和神圣感。 
• 风格化： 奇幻史诗，自然纪录片质感。

提示词6：克苏鲁

• 巨物主体： 一只像海底山脉一样巨大的、布满藤壶和古老珊瑚的克苏鲁风格章鱼状巨兽，正处于沉睡状态。 
• 尺度参照物： 一艘小小的“蛟龙号”风格的深海科研潜艇。 
• 场景：马里亚纳海沟的绝对黑暗之中，周围有发光的水母和海洋雪。 
• 运动与交互： 潜艇的探照灯光柱缓缓扫过一片看似是山脉的区域，光柱最终停在一处巨大的、紧闭的眼睑上。随着潜艇的靠近，眼睑下的肌肉轻微抽动了一下，搅动的水流让潜艇剧烈摇晃，扬起了海底的尘埃。
• 美学控制： 体积光，悬浮粒子，强烈的明暗对比，通过参照物的摇晃来体现巨物的力量，营造令人窒息的压迫感和深海恐惧。
• 风格化： 克苏鲁神话，科幻惊悚，深海纪录片。

提示词7：沙滩机器人 

• 巨物主体： 一具倒在沙漠中的巨大战争机器人（高达风格）的残骸，锈迹斑斑，身上长出了植物。 
• 尺度参照物： 一位穿着防护服、背着工具包的废土拾荒者。 
• 场景： 后末日时代的广袤沙漠，天空中挂着两个太阳。 
• 运动与交互： 拾荒者用绳索固定好自己，在机器人巨大的头部（如同一座小山）外壳上行走。他用切割枪切下一块装甲，火花四溅。镜头从拾荒者的特写，缓缓穿过机器人空洞的眼眶，展现其体内复杂的、已经熄灭的机械结构。
• 美学控制： 废土美学，强烈的日光和阴影，金属的锈蚀质感，镜头光晕，广角镜头展现荒凉感。
• 风格化： 科幻废土，《沙丘》或《疯狂的麦克斯》风格。

提示词8：沙人 

• 主体与描述： 一个由沙尘和破碎玻璃组成的半透明人形巨灵，在城市中心由龙卷风汇聚成型。 
• 场景与描述： 黄昏时分的迪拜或上海，背景是林立的未来派摩天大楼。天空是沙尘暴来临前的橙黄色。 
• 运动与描述： 巨灵从地面盘旋而起，身体周围环绕着狂风和闪电。它伸出一只巨大的手，缓慢地抚过一座摩天大楼的玻璃幕墙，幕墙像水面一样泛起涟漪，但并未破碎。 
• 美学控制： 动态粒子系统（沙、玻璃碎片），低角度仰拍强调压迫感，手持镜头的轻微晃动，冷暖色调对比，反射和折射效果。 
• 风格化： 现代奇幻，灾难片，视觉特效大片。

提示词9：深海巨物 

• 场景描述： 一架小型深海潜水器正在探索马里亚纳海沟的未知区域，探照灯是唯一的光源。突然，灯光照亮了一片巨大、光滑、如同黑曜石的曲面。这个曲面缓缓眨动，原来是一只巨型未知生物的眼睛。这次眨眼掀起了强烈的海底暗流，将潜水器猛地掀飞出去。
• 运动幅度： 潜水器的漂浮与探索、巨型眼睑的缓慢开合、被暗流猛烈冲击的失控翻滚。
• 美学控制： 水下摄影，幽闭恐怖氛围，仅有来自潜水器的实用光，生物发光细节，悬浮的深海雪，强调黑暗与未知的压迫感。

文章来源：https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders

马特·雷纳 Google Cloud 全球营收总裁；马特·A·V·查班Transform 高级编辑

发布于2024年4月12日；最后更新于2025年4月9日。

人工智能已经到来，人工智能无处不在：顶级公司、政府、研究人员和初创公司已经在利用谷歌的人工智能解决方案来增强他们的工作。

就在一年前，我们在 Google Cloud Next 24 期间首次发布了此列表。其中有 101 个条目。 

当时感觉意义非凡，也展现了谷歌和整个行业在生成式人工智能应用方面所取得的巨大进展。在生成式人工智能广泛应用的短暂时期内，各种规模的组织都开始在自身工作和全球范围内进行实验并将其投入生产，其速度之快在新技术发展中实属罕见。

一年的变化真是惊人。我们的名单增长了6倍。然而，这仅仅是人工智能在企业领域应用的冰山一角。

本周，我们与这些客户、合作伙伴以及拉斯维加斯和全球各地的数千名其他人士齐聚一堂，在Google Cloud Next 25上，许多此类用例都将变为现实。

仅举几例：温迪汉堡、棒约翰披萨和优步都在加快订单管理速度，无论是在免下车取餐通道还是通过搭载预测性人工智能工具的应用程序。梅赛德斯奔驰和通用汽车增强了车载服务，而三星的最新款手机，甚至其家用机器人 Ballie，都得益于人工智能，拥有了更灵敏的功能。花旗银行、德意志银行和联合圣保罗银行等金融机构正在安全地提供新服务，更快地监控市场，并以创新的方式打击欺诈行为。

鉴于我们不断看到的创新和进步的惊人速度，我们相信，随着客户不断挑战我们设计、构建、部署和创造价值，人工智能的发展将超出我们的想象。 

希望您在这里找到一些可以共同推动我们自己的人工智能事业的东西。

该榜单按11个主要行业（汽车与物流；商业和专业服务；金融服务；医疗保健与生命科学；酒店与旅游；制造、工业和电子；媒体、营销和游戏；公共部门和非营利组织；零售；技术；电信）类别划分，涵盖六种代理类型：客户、员工、创意、代码、数据和安全。新增280家机构，在机构名称前标有星号(*)。

（😊温馨提示：为方便阅读和对照，做成了表格和图片格式，可保存，放大查看）

文章转载自公众号：全球南方学术论坛

本文编辑：吴艺凡  

会议主办方：全球南方学术论坛、AI雪鸟会

会议同步视觉记录：优普丰AI敏捷创新咨询/“布说布画” Brenda（小布老师）

人工智能的浪潮，正从科技巨头林立的都市，以前所未有的速度涌向广袤中国的“神经末梢”——县域。这片承载着数亿人口、连接着城乡未来的广阔地带，正成为检验AI技术普惠性与生命力的终极试验场。县域经济与民生场景正悄然成为AI应用的新前沿。

如何让AI不只停留在大企业与大城市之间，而是真正扎根于乡土、赋能基层？如何在数字中国建设的时代浪潮中，把握县域AI的战略窗口？

2025年7月5日，由全球南方学术论坛与AI雪鸟会联合主办的”县域AI战略与应用研讨会”以线上会议形式成功举办，并通过微信视频号同步直播，吸引超过3500人次在线观看。

本次会议由华东师范大学国际传播研究院院长吕新雨致辞，全球南方学术论坛秘书长熊节主持。会议汇聚学界、产业界和企业一线的专家学者，围绕AI技术在县域发展中的战略布局与实践应用展开深入探讨，重点研讨AI推动县域经济数字化转型与高质量发展的实施路径。研讨会设置三个核心议题，与会专家进行了充分交流与分享。

议题一 从“工具”到“范式”：重塑县域发展的认知框架

本次研讨会以对AI在县域发展中定位的根本性反思为起点。与会学者普遍认为，必须超越将AI视为单纯“提效工具”的局限，深刻理解其作为一种“思维范式”的革命性力量。它要求我们重新审视发展的目标、组织的形态乃至个体的生存方式。

杨静 | AI应用赋能县域发展的新质生产力

贵州大学副教授杨静以西部脱贫县榕江为样本，描绘了县域拥抱AI的现实图景。政策与资金的支持是“天时”，技术的发展是“地利”，但基础设施薄弱、本土人才匮乏、企业数字化能力不足构成了“人和”的巨大挑战。他的建议直指根本：需要进行系统性投入，从“输血”式的项目引进，转向“造血”式的人才培养与生态建设。

申健 | AI带人类从“有限游戏”走向“无限游戏”

优普丰首席AI场景科学家申健提供了一个哲学视角。他借用詹姆斯·卡斯的理论，指出传统工作是追求“胜利”的“有限游戏”，规则与边界清晰；而AI时代的未来，则是一场以“存续”为目的、规则与参与者不断演变的“无限游戏AI的价值不在于完美替代重复劳动，而在于将人类从“有限游戏”中解放出来，投身于更具创造性与灵活性的探索。这对于资源相对有限的县域而言，或许意味着一条非对称的、跨越式发展的可能路径。

徐昊 | 数智化战略与建设统筹

汇丰银行首席工程师徐昊则将目光投向组织内部。他运用Cynefin框架，将数字化转型中遇到的问题解构为简单（Obvious）、繁杂（Complicated）、复杂（Complex）和混乱（Chaos）四种情境。他强调，组织的决策者与执行者必须首先清晰诊断自身所处的情境，才能匹配正确的应对策略。避免用“繁杂”的方案去应对“复杂”的系统问题，是县域数智化建设从混乱走向有序的关键。

仝键 | LLM在知识工作中的应用模式思考

独立顾问仝键对大语言模型（LLM）在知识工作中的应用进行了冷静剖析。他坦言，LLM并非万能灵药，其“幻觉”、噪音、过载等问题在信息质量参差不齐的县域场景中可能被放大。然而，随着端侧大模型兴起、模型能力走向差异化，与LLM共存并善用其能，将成为未来知识工作者的核心素养。对县域而言，这意味着需要培养一批既懂业务、又懂AI的“赤脚开发者”。

曾泽华 | 中华传统文化大模型的研究与应用

洲明科技AI大模型负责人曾泽华系统阐述了中华优秀传统文化大模型的研发路径：以哲学思想为灵魂、古典文学为基石，构建”文本-多模态”双轨体系。通过联合高校，整合3D文物扫描、非遗影像等多元数据，重点攻克文言文理解准确性和多模态融合难题。目前已开发出具备情感陪伴和专业问答能力的山隐大模型系列产品，涵盖智能音箱、教育手办等应用场景。

议题二 从“输血”到“造血”：AI驱动的在地产业新生

如果说范式变革是“顶层设计”，那么产业应用则是AI在县域“落地生根”的根本。与会者聚焦文旅、农业等县域特色产业，探讨AI如何从外部赋能转向内生驱动，培育出真正属于地方的可持续发展动能。

王崎 | 智慧农业：植保先行，重塑“靠天吃饭”的古老命题

贵州大学特聘教授王崎指出，智慧农业的核心的一个应用场景是植物保护。通过AI进行病虫害识别、农药分子设计和智能预警，能够精准破解“靠天吃饭”的古老难题。他分享的研究成果，展示了AI如何为县域农业提供从育种到餐桌的全链条智能化方案，这对于保障国家粮食安全和促进农民增收具有双重意义。

许国腾 | “AI+新基建”：解锁县域文旅的沉浸式未来

贵州大学副教授许国腾认为，县域文旅的未来在于“新动能培育”。AI不仅能在供给侧提升产品创意，更能通过满足消费者的个性化、沉浸式体验需求，创造全新的消费场景。同时，AI也是“讲好县域故事”的利器，能够助力本土文化实现高效的国际传播。

张安思 | 村域智能飞行：低空经济如何飞入寻常百姓家

贵州大学副教授张安思将视野拓展到“村域智能飞行”这一新兴领域。无人机在农业植保、物流配送、应急巡检中的应用，正在为县域经济开辟“低空经济”的新赛道。然而，安全、效率与成本仍是横亘在前的三座大山。他的研究致力于攻克飞行控制与数据处理等核心技术，目标是让智能飞行真正“飞入寻常百姓家”。

曾学海 | 个人崛起：AI时代的个人内容创作

思特沃克工程师曾学海对个人创作者的生存状况进行了深入分析，提出了引人深思的问题，并从个人角度阐述了人工智能引发的职业变革以及商业化模式。在就业压力和内容同质化的双重挑战面前，他展示了人工智能为个人创作者在创意构思到作品完成的整个过程中提供全面支持的潜力。

曾磊 | 当AI遇到工作：让机器为你打工

Orris AI独立开发曾磊从自身创业的经验，讲述了AI在工作中的全面应用，并展示了如何利用AI实现从需求到代码的全流程自动化开发，让“机器为你打工”成为可能。对县域而言，最大的红利或许不是盲目招商引入大企业，而是激活无数个被AI赋能的“超级个体”。

议题三 从“黑箱”到“可用”：技术架构的平权与创新

AI在县域的普及，最终依赖于技术本身的进步与架构的创新。如何让高深的技术变得稳定、可信、易用，并能处理县域场景中常见的非结构化、小样本数据，是本场技术专家们关注的焦点。

徐计 | 引领树结构：让大模型在“小数据”场景中更智能

贵州大学特聘教授徐计针对县域数据“多而乱、标注少”的痛点，提出了“基于引领树结构的多粒度大数据智能分析”方法。该技术能更高效地从未标记数据中筛选出最具代表性的样本，极大降低了数据标注成本，提升了模型在长尾分类、图神经网络等复杂任务上的表现，为解决县域数据治理难题提供了新的技术武器。

王洪亮 | 思维链：拆解复杂问题，让AI更“会思考”

大连顺致CEO王洪亮介绍了“思维链”（Chain of Thought）的构建方法。面对常见的复杂业务需求问题，简单的对话得出的结果往往不尽如人意。思维链技术通过将复杂问题拆解-解决-整合，模拟人类的逻辑推理过程，显著提升了AI的分析准确性。这为开发更“懂”复杂需求的智能系统铺平了道路。

朱俊杰 | RAG技术：破解“模型幻觉”，打造落地的AI政策顾问

上海赋立咨CEO朱俊杰则聚焦于RAG（Retrieval-Augmented Generation）技术在政务服务中的应用。政策更新快、咨询问题模糊、模型产生“幻觉”是AI在政务场景落地的核心障碍。他通过智能搜索、数据治理与知识图谱相结合的RAG方案，展示了如何构建一个能提供全方位、精准政策咨询的AI服务系统，让技术真正服务于民。

结语

本次研讨会通过深入的思想碰撞，系统阐释了AI赋能中国县域发展的三大路径：认知上，从工具论转向范式论；产业上，从外部输血转向内生造血；技术上，从模型为王转向架构创新。

将研究扎根于祖国的大地上，不仅是一句口号，而是一种行动的召唤。AI在县域的未来，并非一个纯粹的技术问题，而是一个关乎发展模式、社会公平与文明形态的深刻议题。这场发生在中国“神经末梢”的变革，其经验与挑战，或许也将为全球南方其他致力于数字化转型的国家与地区，提供一份来自中国的独特参照。

作者：Dean Peters，2025 年 6 月 8 日

翻译：优普丰 AI 敏捷创新咨询

原文：https://deanpeters.substack.com/p/vibe-first-validate-fast-verify-fit

💪🏻先活下来，再扩张

欢迎来到许愿式编码（Vibe Coding）时代的产品探索——AI 辅助原型制作看似真实却可能并非如此——AI 智能体工具和利益干系人剧场（译者注：为了给利益相关者留下印象或满足他们的形式主义要求，而进行的一些不必要的、表面化的、甚至带有欺骗性的活动）——错误的原型成本远高于错误的路线图。

[图1：你现在还不需要扩大规模。但你确实需要停止猜测。]

“测试你的想法最昂贵的方式是构建生产级质量的软件。” ~Jeff Patton,Dual Track Development

每个原型都讲述一个故事。有的低声诉说可行性，有的咋呼，“看这个 Figma原型图！”，还有的则撒谎……美丽、自信且频繁。你的高管们相信它们。作为产品经理，你现在还不需要扩大规模……但你确实需要停止猜测什么值得构建。

让我们来解决这个问题。但首先，让我们重新定义 2026 年（这不是打字错误，朋友们）的“原型”意味着什么。

🔍 重启：生命力（Proof of Life）探测器

回到 2015 年，我困于与高管的“功能人质谈判”（译者注：”Feature hostage negotiations 是一个在产品管理领域非常形象的术语，用来描述产品经理在确定产品功能优先级和路线图时，与内部或外部利益相关者之间进行的一种高压、不对等的谈判局面）中，他们无法区分原型和生产级构建。所以我发明了一种新型工件：

PoL 探测器——生命力证明

• 轻量级
• 一次性
• 范围狭窄
• 极其诚实
• 小巧且专注

将它们视为探测任务，而非 MVP。永远不是 MVP！*这些*微小的发现行为（TADs）*旨在降低决策风险……而不是证明 HiPPO （薪水最高的人的意见）最新的想法，或被受到相信许愿式编码的海鸥型经理突然俯冲和排便（译者注：swoop-n-pooped，海鸥的行为，这里指乱拍脑袋）。

🧠 明智（且经济）地选择

不是每个问题都是需要锤子的钉子。也就是说，仅仅因为许愿式编码让它看起来真实，并不意味着它就是真实的。并非一切都值得许愿式编码。

所以，在像万圣节糖果一样分发开发时间之前，问问自己：

我们试图降低什么风险？以及听到最残酷真相的最便宜、最快的方式是什么？

🍦 原型的几种风味（现在带有 AI 配料）

1. 可行性检查我们甚至能构建这个吗？1-2 天的突击和删除测试。想象：GenAI 提示链，LMMs 评估，数据完整性扫描，第三方 API 嗅探测试，或评估工具契合度。这是关于揭示技术风险——而不是为了给人留下印象而构建。
2. 聚焦任务的测试用户能否顺利完成这项工作而无摩擦？验证关键瞬间：一个字段标签，一个决策点，一个流失点。像 Optimal Workshop 和 UsabilityHub 这样的工具使这变得非常简单。
3. 叙事原型这个工作流程是否值得一个“绝对肯定”？考虑 Loom 演示，宣讲视频，或幻灯片故事板。这不是“构建与购买”。这是“讲述与测试”。讲述故事，然后看看谁买账。像 Sora、Synthesia 和 Veo3 这样的文本到视频工具让你快速、低努力地创造叙事——无需编写代码或制作可点击原型。
4. 合成数据模拟我们能否在不消耗生产资源的情况下建模？使用像 Synthea 这样的工具模拟用户。利用像 DataStax LangFlow 这样的系统测试提示逻辑，边缘情况，或揭示未知数。这就像风洞测试——只是比事后分析便宜。
5. 许愿式编码 PoL 探测器（旧称“混合原型”）这个弗兰肯（译者注：怪物）软件能否在与用户接触中生存？通过 Canvas 屏幕连接的 ChatGPT 提示，用一点 Replit 和 Airtable 部署？砰：假前端，半可信后端，48 小时内的用户反馈。这不是产品——这只是足够的幻觉来捕捉真实信号。如果他们使用它，太好了。如果他们忽略它？更好——你刚刚避开了一个六个月的路线图绕道。只是不要将动力与成熟度混淆。“最大的风险是构建没有人想要的东西。这就是为什么在投资构建完整解决方案之前，我们需要验证我们的假设。”~Melissa Perri,Escaping the Build Trap

🧪 头号原则

使用最便宜的原型来揭示最残酷的真相。如果它不刺痛，那可能只是表演。

[图2：为工作选择合适的工具。为你的假设选择合适的测试规模。]

🙌 向前辈OG 致敬

这篇文章借鉴了 Marty Cagan 2014 年的博客文章“原型的几种风味”和他的书中《启示录：如何创造客户喜爱的科技产品》第 43 章。

虽然他的例子在今天的生成式助手和廉价原型工具的世界里可能已经过时…… … 他的观点仍然有用…… ……我们需要有意识的生命力验证，而不是原型剧场。

🎯 轮到你了

当你需要在开发人员投入之前进行风险检查时，你的 PoL 探测器是什么？

在评论中留下你最喜欢的风味——或者你最大的失败。

让我们更聪明地验证，更干净地出原型。并避开下一次俯冲和排便。