小红书二面：Function Calling 的可靠性怎么保证？
1. 题目分析Function Calling 大概是 LLM 应用开发中最拧巴的一个环节——你让一个概率模型去做一件需要百分之百精确的事。模型生成的自然语言可以有措辞差异、可以有风格变化，用户多半不会在意，但一个工具调用的参数少了一个字段、日期格式从YYYY-MM-DD变成了DD/MM/YYYY、或者枚举值pending拼成了Pending，下游系统直接报错，整个 Agent 流程就断了。这就是 Function Calling 可靠性问题的本质：一个模糊的系统在试图产出精确的结果。面对这个问题，不能只是泛泛而谈"做好 Prompt 就行了"，而是要能把这个问题拆成若干具体的失败模式，然后针对每种失败模式给出工程上的应对手段。能讲清楚"哪里会出错"和"怎么防住"，才能说明你真的在生产环境中跟 Function Calling 打过交道。1.1 先搞清楚到底哪里会出错要保障可靠性，第一步是建立对失败模式的完整认知。Function Calling 的失败不是一种，而是一串，发生在调用链路的不同环节。按照一次工具调用从"模型决策"到"结果返回"的完整路径来梳理，大致可以分为五类问题。该调的时候不调，不该调的时候乱调。这是意图识别层面的错误。用户说"帮我查一下明天北京的天气"，模型应该调用天气查询工具，但它可能直接用自己的知识编造了一个天气预报；反过来，用户只是随口说"天气真好啊"，模型却触发了天气查询。这类问题在工具数量较多、工具功能有重叠的时候尤其严重——十几个工具摆在面前，模型很容易选错或者在不需要工具的时候画蛇添足。调对了工具，但参数构造出错。这是最常见也是最棘手的一类失败。模型正确地选择了天气查询工具，但传的城市名是"BJ"而不是"北京"，或者日期格式不对，或者漏掉了必填的unit参数。参数构造错误的形态非常多样——类型错误、格式不符、值域越界、字段缺失、多余字段——它们在传统开发中靠编译器和类型系统就能拦住，但在 LLM 生成的世界里，每一个都可能发生。格式层面的解析失败。模型返回的 JSON 不合法——多了个逗号、少了个引号、在 JSON 外面包了一层 markdown 代码块，甚至直接返回了自然语言而不是 JSON。虽然现在主流模型的 structured output 能力已经大幅改善，但在使用开源模型或者老版本 API 时，这个问题仍然常见。工具执行层面的失败。参数没问题，格式也没问题，但外部 API 本身超时了、限流了、返回了错误码、或者返回了一个出乎意料的数据结构。这不是模型的错，但 Agent 需要能理解并应对这些失败。结果误用。工具成功返回了结果，但模型在解读结果时出了偏差——比如把美元当成了人民币，或者在多个返回字段中选错了要用的那个。1.2 Schema 设计是第一道防线很多人把 Function Calling 的可靠性问题归结为模型能力不够，但实际上有相当一部分错误可以通过更好的 Schema 设计来避免。Schema 写得好不好，直接决定了模型犯错的空间有多大。工具描述（description）要写给模型看，不是写给人看。很多开发者习惯性地用简短的技术注释来写工具描述，比如查询天气数据。但模型需要的是更明确的使用指南：什么时候该用这个工具、什么时候不该用、输入应该是什么样的。一个好的描述是"当用户询问某个城市未来的天气状况时调用此工具。不要用于查询历史天气。城市名称需使用中文全称，如'北京'而非'BJ'"。描述越具体，模型的决策边界就越清晰。参数的约束要在 Schema 里写死，不要指望模型自觉。JSON Schema 本身提供了丰富的约束能力——enum限定可选值、pattern用正则约束格式、minimum/maximum限定数值范围、required标明必填字段。这些约束不只是给下游校验用的，模型在生成参数时也会参考 Schema 中的约束信息。一个写了"enum": ["celsius", "fahrenheit"]的unit字段，比一个只写了"type": "string"的字段，出错率低得多。控制工具数量，避免选择困难症。实验数据表明，当可用工具超过 10-15 个时，模型的选择准确率会明显下降。如果你的系统确实有几十个工具，应该做分组或分级——根据用户意图先做一轮粗筛，只把相关的 3-5 个工具放进当前 prompt，而不是把全部工具一股脑塞给模型。这种动态工具注入的策略在实际项目中效果非常好。用 few-shot 示例来校准模型的调用行为。在 System Prompt 中给出 2-3 个完整的调用示例——包括用户输入、期望的工具选择、期望的参数格式——可以显著降低模型的调用错误率。示例的作用不仅是教模型"怎么调"，更重要的是帮模型建立"什么情况下调"和"什么情况下不调"的判断标准。1.3 Structured Output 与受约束解码Schema 设计再好，最终还是要靠模型来生成符合要求的输出。好消息是，主流模型厂商这两年在这方面的投入非常大，已经提供了多种机制来从模型侧保障输出的格式可靠性。Structured Output（结构化输出）是目前最强的格式保障手段。OpenAI 在 2024 年推出的 Structured Outputs 功能，可以保证模型的输出 100% 符合你提供的 JSON Schema——不是"尽量符合"，是"一定符合"。它的底层原理是受约束解码（Constrained Decoding）：在模型生成每个 token 时，根据当前已生成的内容和目标 Schema，动态计算出下一个 token 的合法候选集，把所有不合法的 token 的概率置零。比如当模型刚生成了{"city":之后，如果 Schema 要求 city 是 string 类型，那么下一个 token 只能是引号开头的字符串，数字和布尔值的 token 概率直接被清零。这种机制从根本上消除了格式层面的错误——不会再出现 JSON 不合法、字段类型错误、缺少必填字段等问题。但要注意，Structured Output 保证的是格式正确，不保证语义正确。模型可能生成一个格式完美但值完全离谱的 JSON，比如把城市名填成了用户名。Function Calling 模式本身也自带一定的格式保障。当你通过 API 的tools参数传入工具定义时，模型会进入一种特殊的生成模式，输出的格式比普通 chat completion 要稳定得多。结合tool_choice参数，你还可以控制模型是自己决定是否调用（auto）、必须调用某个工具（指定工具名）、还是不许调用任何工具（none），进一步缩小决策空间。1.4 验证层、重试与降级模型侧的能力再强，工程上也不能把所有赌注压在模型身上。一个成熟的 Function Calling 系统一定有独立于模型的验证和容错机制。参数校验中间层是最基本的工程实践。在模型输出工具调用指令和实际执行工具之间，插入一个校验层。这个校验层做的事情很具体：拿模型生成的参数去跟 JSON Schema 做一次严格校验（用 jsonschema 库或者 Pydantic 模型），检查类型是否正确、必填字段是否齐全、枚举值是否合法、数值是否在范围内。校验不通过的，不要直接报错，而是把错误信息反馈给模型，让它修正后重新生成。这种"生成→校验→反馈→重试"的循环，实测中能修复 80% 以上的参数错误。说到重试，重试策略的设计也有讲究。不是简单地失败了就再来一次，而是要区分失败类型来决定怎么重试。参数校验失败，应该把具体的校验错误信息（比如"date 字段格式不符，期望 YYYY-MM-DD，实际收到 03/15/2024"）拼进 prompt 让模型修正，这叫"带反馈的重试"。API 超时或限流导致的失败，应该用指数退避（Exponential Backoff）重试，跟模型无关。如果同一个工具连续失败 N 次，就应该触发降级策略——要么换一个功能类似的备选工具，要么直接告诉用户这个操作暂时无法完成，而不是无限重试。Pydantic 在 Python 生态中几乎是 Function Calling 的标配。用 Pydantic 定义工具参数的数据模型，一方面自动生成 JSON Schema 给模型用，另一方面自动完成参数解析和校验。如果模型返回的参数不符合 Pydantic 模型的定义，会直接抛出带有详细错误信息的 ValidationError，这些错误信息可以直接拼进下一轮 prompt。LangChain 的@tool装饰器和 OpenAI 的 function calling 示例中大量使用了这种模式。1.5 多工具场景下的可靠性挑战当系统中只有两三个工具时，上面这些手段基本够用了。但当工具数量上升到十几个甚至几十个，可靠性问题会变得复杂得多。工具之间的混淆是头号问题。功能相近的工具特别容易被混淆——search_products和search_inventory都是搜索，模型怎么知道该用哪个？send_email和send_notification都是发消息，边界在哪里？解决这个问题要从两方面入手。一方面在工具描述中明确写清彼此的区别，不是各自描述自己就行，而是要告诉模型"当 X 场景用工具 A，当 Y 场景用工具 B"。另一方面要做工具分组，把工具按业务域分成几组，模型先选组再选工具，像一个两级菜单一样，减少每一级的选择数量。Parallel Function Calling（并行调用）引入了新的复杂度。现在主流模型支持在一次回复中同时调用多个工具。这在效率上是好事，但也带来了新问题：模型可能在本该串行的场景中错误地并行调用（比如先查用户信息才能下单，模型同时调了查询和下单），或者并行调用的多个工具之间有隐含的参数依赖但模型没意识到。工程上需要在执行层做依赖检查——如果检测到并行调用之间存在数据依赖，自动将其转为串行执行。工具调用链路的组合也需要验证。在复杂 Agent 中，完成一个任务可能需要调用 3-5 个工具，每个工具的输出是下一个工具的输入。单个工具调用的可靠性都保住了，但组合在一起时可能出现语义层面的不一致——第一个工具返回的是 ID，第二个工具期望的是名称，模型需要做一次转换但可能转错。对于关键的工具调用链路，可以预定义一些常见的调用模板（Tool Chain Template），限制模型只能在预定义的链路模式中选择，而不是完全自由组合。1.6 评估与监控可靠性不是一次性做到位的事情，它需要持续度量、持续优化。工程上要建立一套完整的评估和监控体系。离线评估要建标准测试集。收集真实用户的请求和期望的工具调用结果，构建一个 benchmark 数据集。每次修改了 Schema、调整了 Prompt、升级了模型版本，都要跑一遍测试集，看工具选择准确率、参数正确率、端到端任务完成率这几个核心指标是涨了还是跌了。这跟传统软件的回归测试是一个道理，只不过评估的对象从代码输出变成了模型调用行为。线上监控要跟踪关键链路指标。在生产环境中，至少需要监控这些指标：工具调用的触发率（是否在该调的时候调了）、参数校验通过率（参数质量怎么样）、工具执行成功率（下游服务是否稳定）、重试率和重试成功率（容错机制是否有效）、端到端任务完成率（用户视角的体验）。这些指标要有告警阈值，一旦某个指标异常下降，能及时发现并排查。LLM-as-Judge 可以做更细粒度的质量评估。对于一些难以用规则判断对错的场景——比如模型选了一个也说得过去但不是最优的工具，或者参数在语义上有微妙的偏差——可以用另一个 LLM 来做裁判，评估调用决策的合理性。这种方式成本较高，通常用于离线的抽样评估，而不是线上实时检查。最后补充一个实践中的重要认知：可靠性保障的投入应该和业务风险成正比。一个内部的数据查询助手，工具调用出错了大不了让用户重新问一次，做基本的参数校验和重试就够了。但如果是一个能操作用户账户、发起交易的 Agent，每一次误操作都可能造成真实损失，那就需要在关键操作前加人工确认、在高风险工具上设置更严格的参数约束、甚至对某些操作做"双模型交叉验证"（两个模型都认为该执行才执行）。没有一刀切的方案，工程上的权衡永远是在可靠性、延迟和成本之间找平衡点。2. 参考回答Function Calling 的可靠性保障需要从多个层面来做，我把它理解成一个纵深防御的体系。首先从源头上，Schema 设计是第一道防线。工具描述要写得足够具体，不只是说"做什么"，还要说"什么时候用、什么时候不用"。参数定义要用好 JSON Schema 的约束能力——enum 限定可选值、pattern 约束格式、required 标明必填字段。工具数量多的时候要做分组和动态注入，避免模型面对太多选择时犯迷糊。配合 few-shot 示例来校准调用行为，效果提升会很明显。在模型侧，现在主流模型都支持 Structured Output，底层用受约束解码来保证输出 100% 符合 JSON Schema，这从根本上解决了格式层面的可靠性问题。但它只保证格式正确，不保证语义正确，所以工程侧还需要独立的兜底机制。工程上最关键的实践是在模型输出和工具执行之间插一个参数校验层，我们项目中用 Pydantic 来做。校验失败的不直接报错，而是把具体的校验错误信息反馈给模型让它修正重试，这种"带反馈的重试"能修复大部分参数错误。同时要区分失败类型——参数错误走反馈重试，API 超时走指数退避，连续失败 N 次走降级策略，不能一刀切地处理所有失败。最后是持续的评估和监控。我们会维护一个基于真实用户请求的标准测试集，每次改 Schema 或升级模型都跑回归测试。线上则监控工具调用触发率、参数校验通过率、执行成功率这些关键指标，设好告警阈值。整体来说，可靠性不是某一层做到极致就够的，而是每一层都做好基本功，形成纵深防御。
架构决策疲劳的隐形负担
作为技术架构师，我们理应做出决策，并且是有关架构的决策。这些决策通常规模宏大、意义重大、复杂且影响深远，具有长期影响力，并且跨越多个组织范围。然而，在经过一次又一次决策之后，常常会质疑自己的选择以及他人的选择，总觉得哪里不对劲，感觉什么地方偏离了正轨，有一种不安的感觉，觉得遗漏了某些东西，没有将这个或那个因素考虑进去。“为何选择将事件流技术应用于那个客户订单系统呢？这样做真的有意义吗？为何选择那个特定的商业应用？供应商是否真能如我们所期望的那样提供服务？”没人明确知道所有细节，没有审计记录，没有关于这些决定的记录，没人能回忆起决策过程以及与之相关的讨论内容。我曾参与过这样一个项目，当时我担任架构师，那是一个规模非常大的机构，拥有数百名各类架构师 —— 包括解决方案架构师、软件架构师以及企业架构师等各类“架构师”角色。我原本打算接手一个尚处于起步阶段的应用，不过这个应用的架构设计工作是由另一位离职的架构师完成的。有一些初步的文件资料留存了下来，但内容并不详尽，不过已经预先做出了不少重大决策。该应用是一款 SaaS 产品，年销售额高达数百万美元。某些地方使用了云环境，但并非在所有地方都用，还有数据库、数据湖以及与其他系统的集成，似乎有些古怪且格格不入。这就是我在构建产品其余部分以及确定其架构和设计时所依据的基础。基于已经做出的种种决定，我需要做出很多抉择。然而，却没有明确的框架或指导来帮助我进行这些抉择。这还不够，我还得为我所做的决策以及之前其他人所做的决策进行解释和辩护，所有这些内容都必须在架构审查委员会面前进行陈述和论证。这个决策制定流程简直让人精疲力竭，通过与其他架构师的交流，我意识到并非只有我一人有这种感受。我想要弄明白原因。为什么在一个看起来拥有庞大架构和技术力量的组织中，架构决策过程却如此耗费精力呢？我意识到，这是因为根本就没有形成架构决策流程。尽管有架构审查委员会、企业架构师的参与以及充足的预算，但对于 IT 架构师而言，在着手做出架构决策时却没有一套可遵循的流程。尽管无法独自为整个公司建立起那样的流程，但或许至少可以为我的项目以及直属团队做些事情，即便最终结果可能并不完美，但这些努力仍可能具有一定价值。然后我开始思考，到底缺失了什么东西？换句话说，正确的架构决策流程应包含哪些要素？文档资料首先，没有任何文件记录。什么都没有被记录下来，技术决策及其背后逻辑都没有被记录下来，甚至连那些每年让公司损失数百万美元的重大决策也没有记录在案。我认为这会是个不错的起点，于是开始记录实际决策过程。起初只是简单的将相关信息以文本格式记录在 Confluence 系统中。随后，结构变得更加严谨，最终采用一种简单却有效的格式来记录此类技术决策过程。我将这种结构称为技术/架构决策矩阵，目的是突出每个技术方案的不同方面。我们并不一定需要传达对每个方案进行研究时所涉及的所有详细技术信息，这些信息可以留给其他类型的文档来处理，其作用在于集中收集每个方案中最重要的方面，从而使每个方案的决策过程变得清晰明了、一目了然。下面就是矩阵的结构，每个选项需要列出以下内容：• 选项名称：用于标识该选项的简单标识符。• 描述：对选项所包含内容的清晰但简短的说明。• 优点：该选项带来的好处。• 缺点：该选项的不足之处。• 风险：实施该选项所涉及的风险。• 影响：实施该选项的总体影响（正面或负面）。还可以添加诸如成本或不实施该选项的风险等内容。以这种方式记录技术决策所带来的首要作用是，能帮助我们对所有相关信息进行组织和整理。这样一来，就能够做出明智且正确的决策。如果没有这份文件，决策过程就会变得随意且不透明，很难追踪理解为何会做出某些决策以及决策的具体过程，也很容易忘记和遗漏重要信息。有人可能会说，这只会让其他人更清楚的理解决策过程，但并不能真正帮助到当时正在执行决策过程的那个人。但事实并非如此，即使作为决策者，也能够帮助我们在脑海中更好的整理思路，并以客观、清晰、明智的方式对每个选项进行分析。此外，还能帮助决策者向他人传达这些选项，并从他们那里获得有价值的反馈。这对我的工作帮助极大，一旦开始记录技术方案，不仅有助于进行架构设计，还有助于与利益相关者就各种方案进行沟通和协商。但是，仅仅列出各种选择是不够的，这是个很棒且重要的开始，但远远不够。架构决策记录（Architectural Decision Records）上述矩阵中的记录有助于我们以清晰、透明的方式确定应采用哪一选项。然而，这发生在做出决策之前，简而言之，这就是我们做出特定决策的过程。一旦做出该决定，结果也必须如实记录下来。这就是架构决策记录（Architecture Decision Records，简称 ADR）[2]发挥作用的地方。简而言之，这些架构决策记录对于追踪决策以及为过往决策建立审计记录至关重要。回到开头的例子，我们有多少次不得不去审视别人的决策，却无法理解他们为何会做出那样的决定？这种情况相当常见，原因在于，一旦做出决策，没人会去记录相关技术或架构方面的细节。按照 ADR 的简单格式来操作，对于提高技术决策的可见性和透明度大有帮助。无论用 Confluence、Notion 还是 Markdown，记录这些决策都能消除我们试图理解为何选择这一方式而非另一方式时所存在的猜测成分。此外，还能降低因长期遗忘最初制定该决策的初衷而导致重要决策被重新修改的风险。因此，ADR 是一种简单却极具效力的工具，能够简化并助力架构决策过程。现在，你可能会说这一切都很好。但问题在于，究竟如何将这些内容纳入到团队或组织的运作流程中呢？尤其是对于一家大型企业而言？如何将改进措施融入到所在组织的实际决策流程中呢？而且，如果不具备大规模改革组织流程的权限，又该如何实现这一点呢？以下是我在担任软件开发人员、技术负责人以及架构师期间多次采用的一种方法，这些职位并不允许我直接决定和影响工作的具体执行方式。关键在于建立清晰、透明、高效且强大的架构及技术决策流程，并逐步让利益相关者认识其价值。当然，这说起来容易做起来难。不过，如果运用一些创造力、坚持不懈的精神以及创新思维，是完全可以做到的。每当我们考虑架构方案时，都会经历一个评估过程。但问题是，在许多组织中，这种评估往往是隐性的。并非以有意识和审慎的方式进行，也没有形成书面记录，因此无法重复，也缺乏透明度。要在大型组织内部建立起更有效的决策流程，应从小处着手，逐步获得利益相关者或团队的逐步支持。第 1 步：树立榜样软件架构师和开发人员往往认为，对于超出其职责范围、所有权或管理权限的事项，他们无法做出改变。当然，这种观点有一定道理，但事实上，你们所拥有的影响力和权力远超自认为的那样。关键在于，你不能简单命令组织去实施你所提议的变革，而是需要去说服这个组织。可以从某个具体案例开始，以此为例来展示所做之事的价值。首先找到某个存在架构问题的情况，即你或他人曾需从多个选项中做出选择。这个问题可能是过去发生过的，也可能是当前正在处理的。使用上述技术决策矩阵记录正在考虑的各种选项。不必过于复杂，只需能清晰传达已做出或正在做出的决策要点即可。然后，如果过去已经根据这些选项做出了决定，就记录一个简单的 ADR。第 2 步：获得有限支持一旦记录了一些选项，并且手头有了具体的东西，是时候让别人注意到这一点了。找几位团队成员或利益相关者，他们和我们一样，也受到缺乏明确架构决策流程这一问题的影响。这些人可以是其他架构师、开发人员、经理、产品负责人等等。展示所记录的内容，并说明此类记录资料在简化流程以及缓解当前难题方面（至少在一定程度上）能起到怎样的作用。这有助于构建某种展示，可以列出这种流程的优点以及不实施该流程所存在的风险。后半部分至关重要，表明了不采纳所提议方案的后果。一旦获得部分利益相关者的支持，并且已经获得了一定的实际支持，那么就可以进入下一步了。第 3 步：向更广泛的群体进行宣传并获得支持在此阶段，需要向团队或相关利益相关者介绍所经历的这一过程及其带来的好处。可以通过演示、研讨会或就该主题所举办的一系列演讲来实现。向利益相关者展示第 2 步已经获得的支持情况，据此来阐述你的观点。目标是让团队相信这一过程是有价值的，并促使他们认同并采纳这一架构决策流程，将其融入日常工作中。为了促进转变，并使团队操作起来更加便捷，可以提议进行一次“试运行”。在此期间，团队可以先试行该流程一段时间，然后重新评估并验证该流程是有助于解决问题还是反而使情况变得更复杂。关键在于要逐步小幅度实施变革，而不要要求对团队的工作方式进行大规模调整。如果采取后者的方式，很可能会引发更多抵触和反对情绪，阻碍新流程的推行。团队成员可以开始做的事情其实非常简单，大致就是：1. 下次需要就某个解决方案、系统、应用程序或其他具有足够重要技术或架构影响的事项做出架构决策时，可以记录基本的决策矩阵。2. 用该矩阵来向团队成员介绍和讨论解决方案以及各种选项。3. 将最终做出的决策记录为 ADR。为了流程更加顺畅，我们甚至可以主动承担引导基于决策矩阵进行架构讨论的任务。这可以在架构审查委员会会议期间进行，也可以是单独的会议。还需要向团队保证，我们会提供指导和支持，这点对于确保新流程的成功实施（这是团队运营模式的一部分）至关重要。总结在许多组织中，存在着一项重要需求，即简化技术及架构方面的决策流程。通常情况下，这类决策并没有相应流程可依循。若缺乏此类流程或者流程效果不佳，就会导致混乱、信息遗漏并增加风险。此外，还会导致软件工程师、架构师以及其他技术和非技术方面的利益相关者产生决策疲劳，而他们必须做出这些决策，或者依赖这些决策来行事。如果没有清晰、有效且可重复的框架，决策过程就会变得令人疲惫且效率低下。技术决策者们不再能够推动发展，反而陷入了反复争论、不确定性以及不断增加的运营风险之中。那些未能解决这一问题的组织将会付出代价，包括时间的浪费、不必要的复杂性、以及灵活性的降低，并且很有可能会遗漏一些重要的架构考量因素，从而在未来引发严重的组织问题。因此，建立高效、透明的决策流程对于组织的成功至关重要。这个过程有几个关键点：1. 通过编制“架构决策矩阵”使技术决策过程变得清晰且有条理，该矩阵侧重于每个选项的关键方面。2. 利用矩阵推动架构讨论，通过架构审查委员会或其他类似会议来进行。3. 做出决策后，将决策记录为“架构决策记录”。本文提供了简单且易于实施的方法，可实现此类流程的实施，同时又不需要对组织进行大规模变革。只需要为需要进行架构决策的特定领域创建矩阵，然后向团队推广，建议采用“试运行”方式来实施，这样工作量最小。
当 AI 开始参与研发流程，产研协作应该如何变化？
1、执行者开始从人扩散到系统传统的研发流程能跑通，底层有一个核心关键：执行者是人。需求写得模糊没关系，开发者靠经验补全；设计稿没覆盖的边界，开发者实现时自己判断；验收标准不清晰，测试同学靠业务理解兜底。整个链路里充满了隐式的信息补全，由人完成，习以为常。但当AI Agent开始参与执行，这个假设崩了。系统不会猜意图，不会靠经验补全，信息不完整就会出错或乱执行。执行者从人扩展到系统，意味着过去所有「默认人能理解」的隐性信息，现在必须被显式表达出来。这是 AI 参与研发带来的最根本的结构性变化，不是效率问题，是协作方式的底层重构。2、新的三层结构既然执行者变了，研发流程本身也需要跟着变。过去的软件研发结构可以简单理解为：需求 -> 开发者理解 -> 代码实现，而在 AI 参与研发的情况下，可能逐渐变成：1. 第一层：需求与设计输入层包括：PRD、设计稿、API 文档、业务规划，描述「要做什么」2. 第二层：结构化建模层把自然语言需求转化为系统可以理解的结构化描述，把隐性信息显式化3. 第三层：执行层包括：AI Coding Agent、自动化测试、自动化验证，负责实际执行和验证传统流程只有第一层和第三层，中间靠人脑衔接。新流程的核心变化就是第二层的出现，它是人和系统之间的翻译层，也是整个自动化链路能否跑通的关键。3、Task IR第二层结构化建模，有一个具体的形态，叫 Task IR（Task Intermediate Representation，任务中间表达）。它既不是PRD，也不是代码，而是介于两者之间的结构化任务描述。它的核心内容包括四类信息：• 用户的行为路径• 系统在不同状态下的响应方式• 功能的约束条件与边界• 验收标准这些信息在传统流程里分散隐含在 PRD、设计稿和口头沟通里，由开发者在实现过程中逐步补全。Task IR 要做的，就是把这些信息提前、集中、结构化地表达出来。一个具体的例子，订单列表筛选功能，Task IR 会这样描述：用户进入列表页 -> 点击筛选按钮 -> 选择「待发货」 -> 列表局部刷新展示对应数据；验收标准：默认展示全部，选择后仅展示 status=waiting 的订单，状态切换不整页刷新，列表为空时展示空态组件。这些信息对人来说是常识，但对 Agent 来说是必须明确的执行依据。Task IR 的出现，让需求第一次真正变成了系统可以直接消费的输入，而不只是人阅读的文档。4、每个角色都可能被重新定义把这三点连起来看，AI Native研发体系的本质变化，不只是「用 AI 写代码」，而是整个产研协作的结构在重构，每个角色都可能被重新定义。产品要从功能描述走向问题建模和价值验证，研发要从代码实现走向系统理解和验证闭环，测试要从末端验收走向质量策略和自动化验证。AI 淘汰的不是某个岗位，而是低价值的协作方式，以及停留在旧工作模式里不愿改变、固步自封的人。
用文字直接生成一份 HTML 动画演示文稿 PPT，GitHub 19K 收藏，这个 AI 工具让我彻底换了路子
它是 GitHub 上一个 17100 star 的工具，定位是：用 AI 把文字描述或旧 PPT 文件，直接生成一份零依赖的单文件 HTML 动画演示文稿。不需要 Canva，不需要 MasterGo，不需要在模板里抠颜色。只需要告诉 AI 你要讲什么，剩下的它来。最终的演示文稿我在当天六点发给了领导。他回了一句：「这个风格挺好，不像以前那种模板的感觉。」下面把完整的过程讲给你。先搞清楚它是什么，解决什么问题frontend-slides 是一个 Claude Code 技能（skill），不过原作者不太积极，很多 bug 都没修复，码哥 fork 了一个版本并修复了问题，建议使用修复后的，不然许多坑。https://github.com/MageByte-Zero/frontend-slides也就是说，它不是一个独立的网站或 App，而是安装在 Claude Code 里、通过对话驱动的工具。你跟它说：「帮我做一个关于 Q2 销售复盘的演示，五页，风格现代一点。」它就会生成一个完整的 HTML 文件，里面包含了所有动画、排版、配色——打开浏览器就能全屏放映，不需要安装任何额外软件。你也可以把一份旧的 PPTX 文件扔给它，它能把文字、图片和备注全部提取出来，再按你选的风格重新排版成 HTML。和普通 PPT 模板相比，它的核心差异是三点：第一，零依赖，单文件。生成的 HTML 文件里内联了所有样式和脚本，复制给任何人，用任何浏览器打开都一模一样，不会出现字体丢失、图片找不到的问题。第二，12 种精心设计的风格，覆盖了深色系（Bold Signal、Electric Studio、Dark Botanical）、浅色系（Notebook Tabs、Vintage Editorial）和特殊风格（Neon Cyber、Swiss Modern），每一种都明确拒绝了「AI 生成的那种大众模板感」。第三，从旧 PPT 到新演示的完整闭环。你已有的内容不用白费，PPT 里的文字和图片都可以继承过来，只是换了一套更高端的视觉呈现。用之前 vs 用之后：同样的汇报内容，用模板 vs 用 frontend-slides 的时间和视觉效果对比 安装：只需要在开始之前，你的电脑需要准备好两件东西：第一：Claude CodeClaude Code 是 Anthropic 出的 AI 编程工具，但你不用会编程，这里只是把它当一个能运行技能的平台来用。安装方式：到 Claude 官网（claude.ai/code）按指引下载安装。需要有一个 Claude 账号，免费账号有使用限额，付费订阅（Pro，每月 $20）没有限制。国内注意：Claude 官网。后边码哥来写一篇国内可用的 Claude Code 安装和使用方式。第二：frontend-slides 技能回车执行，等 30 秒左右，安装完成。这是一次性操作，以后每次打开 Claude Code 都可以直接用。安装之后，怎么验证成功了？在对话框里输入/frontend-slides，如果 AI 回应说准备好了、让你描述需求，就说明安装成功。上手三步：从零到一份完整演示文稿第一步：描述你要讲什么打开 Claude Code，输入/frontend-slides，然后告诉它你的需求。不需要按特定格式，用正常说话的方式就行：「帮我做一个 Q2 销售复盘的演示文稿，大概 6 页。主要内容是：第一页封面，第二页 Q2 整体完成率 87%，达成了年度目标的 43%；第三页是三个重点成交案例；第四页是下半年的三个策略方向；第五页是重点客户列表；第六页是结语。风格要现代、深色，不要那种大众感。」字数多一点没关系，描述越具体，AI 生成的内容越准确。第二步：选风格AI 收到需求后，会展示 12 种风格预览，你来选一个。不知道选哪个？这里是码哥在不同场合的推荐：使用场景推荐风格特点向领导汇报、述职Bold Signal深色背景，标题强调，专业感强对外客户提案Swiss Modern克制、精致，有设计感团队内部分享Notebook Tabs干净、轻盈，不压迫产品发布、创意展示Electric Studio 或 Neon Cyber有视觉冲击力年度总结、回顾类Vintage Editorial有质感，不花哨第三步：等待生成，下载 HTML选完风格，AI 会开始生成。一般 1-3 分钟后，你会得到一个.html文件。把这个文件发给同事、发给领导——任何人用任何浏览器打开，效果都一模一样。放映方式：• 按F11（Windows）或Cmd + Ctrl + F（Mac）全屏• 用方向键翻页，或者直接点击屏幕• 不需要 PowerPoint，不需要安装插件从输入描述到得到演示文稿的完整流程进阶：把旧 PPT 文件直接转换过来如果你已经有一份现成的 PPTX 文件，想换一套更好看的视觉风格，流程稍微多一步。第一步：提取 PPTX 内容frontend-slides 自带了一个提取脚本。把你的 PPTX 文件放到一个固定目录，然后在 Claude Code 里告诉 AI：「我有一个 PPTX 文件，路径是 /Users/你的用户名/Documents/述职.pptx，帮我提取内容」。AI 会自动运行提取脚本（python scripts/extract-pptx.py），把 PPT 里的所有文字、图片、备注整理出来，然后展示给你确认。如果你愿意自己运行，命令是：复制python scripts/extract-pptx.py 述职.pptx• 1. 需要先安装 python-pptx 库：pip install python-pptx第二步：确认提取内容，选风格AI 会告诉你它识别到了几页、每页的标题是什么、有多少张图片。你确认没问题后，选一个风格，它就开始生成。一个需要注意的点：动画不保留。PPTX 里原本的切换动画和元素动画不会被迁移，HTML 版会用 frontend-slides 自带的动画效果替代，通常更流畅，但风格不同。另一个注意点：复杂图表。如果你的 PPT 里有 Excel 联动的数据图表，这些图表 AI 会按截图处理，不是可编辑的矢量图。三个真实使用中的坑坑一：内容描述太简短，生成的页面质量差只告诉 AI「帮我做 Q2 复盘」，生成出来的内容基本是通用占位文字。AI 需要你告诉它具体的数字、具体的案例名、具体的结论。把你脑子里知道的内容直接说给它，越具体越好。坑二：HTML 文件在微信里发送会失效HTML 文件不能通过微信直接发送给对方打开——微信会把 HTML 当网页处理，通常只显示代码。正确做法是：发到群文件、云盘链接，或者先转成 PDF（浏览器 → 打印 → 保存为 PDF）再发送。如果是当场汇报，直接在自己电脑上打开浏览器放映就行。坑三：中文字体有时显示偏差HTML 文件在某些 Windows 系统上打开，中文字体可能和你生成时看到的不一样（主要是字重偏细的问题）。解决方法是用 Chrome 打开，Chrome 对字体的支持最稳定。如果需要发给不确定对方用什么浏览器的人，转成 PDF 是最保险的做法。总结在做演示这件事上，工具确实不是最重要的——内容好、逻辑清才是根本。但一份视觉上明显高出平均水准的演示文稿，会让你在汇报前就多了三分信心，也让对方在你开口之前就觉得「这个人做事认真」。frontend-slides 现在已经是码哥做对外演示的默认工具了，不用每次在模板里找颜色搭配，把时间省下来放到内容本身。
暴涨超225%！5000亿存储超级“黑马”，大爆发（转载）
文 | 侃见财经全球AI产业持续爆发，推动存储行业迈入超级成长周期。在此产业背景下，行业形成普遍共识：AI训练看海力士，全栈布局看三星。从产业需求优先级来看，HBM赛道景气度领先企业级SSD赛道，高端DDR5 DRAM赛道紧随其后。在DDR5内存接口芯片领域，全球目前仅有三家企业掌握核心技术，澜起科技便是其中核心玩家。据行业媒体统计，全球内存互连芯片市场规模将从2024年的12亿美元增长至2030年的50亿美元，年复合增长率达27.4%；以太网及光互连芯片市场规模将从2024年的120亿美元增长至2030年的345亿美元，年复合增长率为19.3%。作为全球内存互连芯片市占率榜首企业，澜起科技充分受益于行业高景气红利。从公司财报业绩来看，成长动能持续兑现。根据澜起科技2025年年报及2026年一季报披露数据：2025年全年，公司实现营收54.56亿元，同比增长49.94%；归母净利润22.36亿元，同比增长58.35%；扣非净利润20.22亿元，同比增长61.95%。2026年公司业绩延续高增态势，一季度营收利润持续攀升。财报显示，2026年第一季度澜起科技实现营收14.61亿元，同比增长19.51%；归母净利润为8.47亿元，同比增长61.30%；扣非净利润为6.04亿元，同比增长20.14%。在业绩高增与存储超级周期的双重加持下，澜起科技股价迎来一轮大幅上涨。统计显示，4月初至今，澜起科技A股阶段最高涨幅超105%，H股阶段最高涨幅超225%。值得关注的是，公司AH股出现显著价格差，H股价格较A股溢价约36%，该现象在AH股市场中较为罕见，充分体现国际资本市场对澜起科技的高度认可。截至最新收盘，澜起科技A股总市值3030亿元，H股总市值约5482亿港元。受股价大幅上涨带动，澜起科技核心股东资产大幅增值。公司当前为无实际控制人股权结构，创始人杨崇和直接持有公司218万股，以H股最新市值测算，其直接持股市值约9.76亿港元。与此同时，杨崇和通过WLT Partners, L.P.、珠海融英投资合伙企业（有限合伙）间接持有公司股份，据行业媒体测算，其家族整体财富规模超150亿元。薪酬层面亦体现创始人价值兑现，根据2025年披露的薪酬数据，杨崇和年度薪酬已上涨至1311.4万元，相较2021年199.27万元的薪酬水平，实现大幅增长。千亿芯片巨头崛起，杨崇和奠定企业根基谈及澜起科技的发展历程，创始人杨崇和是不可或缺的核心人物。1994年，国内互联网产业尚处于萌芽阶段，彼时已在美国硅谷深耕多年、任职于美国国家半导体的杨崇和博士，积累了扎实的芯片设计经验，毅然选择归国创业。彼时国内半导体设计行业几乎处于空白状态，产业发展亟待突破。归国后，杨崇和率先入职上海贝岭。1997年，在时任电子工业部部长胡启立的支持下，杨崇和参与创办国内首家“硅谷模式”IC设计企业——新涛科技。新涛科技开创了国内“风险投资+创业团队”的新型创业模式，成为中国半导体发展史上的经典案例。2001年，美国IDT公司以8500万美元现金全资收购新涛科技，该交易金额在当时等同于新浪、搜狐两大门户网站的市值总和。凭借新涛科技的成功并购案例，杨崇和一战成名，被誉为“中国集成电路设计业海归第一人”。功成之后，杨崇和并未止步。2004年，在IDT任职期满后，他与同样具备美满电子初创履历的戴光耀达成合作，于上海漕河泾共同创立澜起科技。据公开资料显示，“澜起”二字取自苏辙诗句“止为潭渊深，动作涛澜起”，寓意厚积薄发、蓄势而起，彰显出企业深耕半导体行业、力争突破的长远格局。创立初期，澜起科技采用双业务并行的稳健发展模式：一方面布局竞争激烈、市场规模广阔、现金流稳定的数字电视机顶盒芯片业务，为公司筑牢经营基本盘；另一方面深耕技术壁垒极高、需要长期高额研发投入的内存接口芯片赛道，布局未来核心增长曲线。凭借优异的低功耗设计优势，公司旗下卫星电视接收芯片MT1300快速抢占市场，巅峰时期国内市占率高达60%。但机顶盒芯片业务的红利并未长期延续。2010年前后，受广电行业监管政策收紧影响，机顶盒市场景气度大幅下滑，相关业务遭遇重创。在此背景下，澜起科技果断战略聚焦，将全部资源、人力与研发重心转向内存接口芯片赛道，正式深耕这条技术难度、行业门槛远超消费电子芯片的核心赛道。内存接口芯片是服务器硬件的核心关键组件。服务器CPU开展海量数据运算时，需持续从DRAM内存颗粒读取、传输数据，而内存接口芯片正是连接CPU与内存颗粒的核心桥梁，保障数据传输的高速性、稳定性与准确性。该赛道不仅芯片设计难度极高，生态认证壁垒更是行业核心门槛：产品需同步通过CPU厂商（英特尔、AMD）、存储颗粒厂商（三星、SK海力士、美光）、服务器OEM厂商三重严格认证，方可进入全球供应链体系。2006年，澜起科技自研第一代内存接口芯片远赴美国对接英特尔，产品实测表现惊艳行业：在不牺牲各项核心性能的前提下，芯片功耗较当时行业顶尖水平降低四成。优异的产品性能获得英特尔高度认可，英特尔不仅专项投入1000万美元技术资金支持，更做出战略性决策：终止自研内存接口芯片业务，与澜起科技达成深度独家合作。依托英特尔的顶级生态背书，澜起科技进入高速发展期。2011年，公司推出符合行业新标准的DDR3内存接口产品，成为全球仅有的两家通过英特尔官方认证的内存接口芯片供应商之一。2013年，澜起科技自研的DDR4全缓冲架构，被全球微电子行业标准组织JEDEC正式纳入国际通用行业标准。这一突破具备划时代意义：全球所有DDR4内存接口芯片的设计研发，均需遵循澜起科技制定的技术标准，公司正式跻身全球行业规则制定者行列。2013年，澜起科技登陆美国纳斯达克，成为中国半导体出海标杆企业。但受海外做空风波影响，公司于上市一年多后完成私有化退市。退市之后，澜起科技彻底剥离消费电子芯片业务包袱，全面聚焦数据中心、服务器高端芯片赛道，业务结构持续优化，业绩迎来高速增长。财报数据显示，2016年至2018年，公司营收从8.45亿元增长至17.58亿元，归母净利润从9280万元飙升至7.37亿元，盈利能力实现跨越式提升。2019年7月22日，澜起科技迎来发展里程碑，作为首批25家企业登陆上交所科创板，开盘涨幅达272.83%，上市初期总市值一度突破千亿。伴随业务持续扩容，公司H股市值峰值突破5000亿港元，成长为全球互连芯片核心龙头企业。高增背后暗藏隐忧，周期与竞争风险并存伴随AI大模型商业化落地，全球算力需求持续爆发，带动内存接口芯片赛道持续高景气，澜起科技业绩与估值同步走高。行业格局层面，内存互连芯片赛道高度集中。2024年全球市场数据显示，行业CR3（前三企业市占率）达93.4%，其中澜起科技以36.8%的市占率位居全球第一，龙头地位稳固。产品迭代层面，公司技术迭代节奏持续领先。2025年，澜起科技陆续推出DDR5第五子代RCD芯片、第二子代MRCD/MDB芯片、新一代CKD芯片等多款高端新品，持续巩固DDR5世代技术优势，支撑业绩持续兑现。2025年公司营收、净利润均实现近五成、近六成的同比高增，成长能力行业领先。但高景气背后，潜在风险逐步显现。2026年一季度，公司营收同比增速已出现放缓迹象，业绩增长边际有所承压。半导体行业具备极强的周期性，澜起科技此轮爆发式增长，核心依托AI算力基础设施建设的行业红利。为匹配旺盛的下游需求，公司持续加大备货力度，存货规模大幅攀升。财报显示，2025年一季度至2026年一季度，公司存货规模从3.11亿元快速增长至9.82亿元，库存体量大幅扩张。适度备货可匹配行业高景气需求，但半导体行业需求波动剧烈，若下游行业景气度切换、需求不及预期，大额存货将面临减值计提压力，成为业绩潜在拖累。历史财报数据印证了这一风险：2023年、2024年，澜起科技分别计提存货跌价准备2.23亿元、2.55亿元；即使在行业高景气的2025年，公司仍计提存货跌价准备2842万元，库存减值压力始终存在。除周期与存货风险外，大客户集中依赖问题是公司另一核心隐患。财报数据显示，2022年至2025年前三季度，澜起科技前五大客户收入分别为30.91亿元、17.13亿元、27.91亿元、31.16亿元，占当期营收比例分别达84.2%、74.8%、76.7%、76.8%，客户集中度长期处于高位。单一最大客户收入维度，同期营收占比分别为25.6%、27.4%、22.9%、28.1%，头部客户贡献度极高。从行业属性来看，大客户集中属于赛道固有特征。内存接口芯片赛道准入壁垒极高，全球合格供应商数量稀少，下游核心采购方高度集中于三星、SK海力士、美光三大存储颗粒巨头及头部服务器OEM厂商。同时，产品需通过英特尔等核心厂商长期认证，供应链壁垒极高，行业天然呈现头部集中格局。但不可忽视的是，高度集中的客户结构，会放大行业周期波动对公司经营的冲击。竞争格局层面，澜起科技的龙头优势并不绝对。目前公司36.8%的全球市占率，仅较第二名高出0.8个百分点，行业竞争格局相对胶着。瑞萨电子、Rambus这两大核心竞争对手，均具备雄厚的技术储备与稳定的客户资源。当前澜起科技在DDR5世代具备阶段性技术与标准优势，但面向未来DDR6技术迭代周期，公司能否延续技术领先优势、持续占据行业标准制定主导地位，仍存在一定不确定性。来源https://tech.ifeng.com/c/8tCLG0kdpKu
全局磨损均衡（Global Wear Leveling）
全局磨损均衡是华为OceanStor Dorado为延长SSD寿命、提升系统可靠性而设计的系统级技术，分为两个阶段：• SSD生命初期：全局磨损均衡利用RAID 2.0+技术，将数据以“指纹”方式全局打散到存储池中的所有SSD上，确保写入负载均匀分布，避免部分硬盘因频繁写入而提前老化。该技术实现了盘间的负载均衡，是系统级的磨损控制。• SSD生命末期：全局反磨损均衡（华为专利技术）当多块SSD接近磨损极限时，系统会主动选择其中一块SSD，集中写入更多业务数据，加速其退役，从而避免多块硬盘同时失效导致RAID组降级或数据丢失的风险。该技术有效降低了多盘集体故障的概率，提升了系统整体可靠性
你们团队还在做的这六件事，Anthropic已经全停了
上周，Anthropic 在旧金山开了一场开发者大会，叫 Code with Claude 2026。有个演讲我翻来覆去看了好几遍，不是因为发布了什么新产品，而是因为演讲者 Fiona Fung 说了一句话，让我一下子坐直了。「这些流程没有哪个明着死掉，它们只是悄悄停止发挥作用了。」没有警报，没有人站出来说「这个会没必要开了」，没有人质疑「这份设计文档还有没有人看」。那些流程就那么活着，消耗着时间，直到有人忍不住问了一句：我们为什么还在做这个？这件事就发生在 Anthropic 工程团队的内部，当 AI 辅助编程从个别人的习惯变成整个组织的默认选项之后。Fiona Fung 是谁先说一下背景。Fiona Fung 是 Anthropic 的 Claude Code 团队工程负责人，职业履历从 2000 年代初的微软开始，后来去了 Meta，现在在 Anthropic。不是那种刚接触 AI 工具的人，她见过软件工程在互联网普及时经历的那次大变，现在她觉得正在经历第二次。Code with Claude 2026 是 Anthropic 的开发者大会，5 月 6 日在旧金山，几千名工程师、PM、技术负责人到场，之后还会去伦敦和东京。这场演讲是大会下午的重头，讲的是一件很多团队正在回避的事，当 AI 写代码变成日常，整个工程组织怎么跟着变。写代码这件事，不贵了她讲的核心洞察其实可以用一句话说完，写代码这件事，不再是最贵的那个环节了。过去几十年，整个软件工程的组织方式都是围绕一个稀缺资源搭建的，工程师的时间。多少人多少天能写出多少代码，这件事决定了需要几个人、要不要冲刺、设计文档怎么评审、谁负责哪块代码。瀑布也好、敏捷也好，说到底都是在管理这个稀缺性。Fiona 说，在 Claude Code 团队，这个稀缺性基本消失了。大家生产的代码量，不是多了一点点，是多了很多。另一个演讲者 Noah Zweben 的团队给出了一个具体数字，3 个月内，每周合并的 PR 从 500 涨到了 1150，增幅 300%，而团队规模没变。代码堵不住了。于是新的瓶颈冒出来，怎么验证这些代码是对的？谁来 review？法务、设计、安全怎么跟上节奏？越来越大的代码库怎么维护？她做了一个类比。她在微软的早年，一切都得赶在 CD 出厂日期之前做完。发布周期是三年，因为刻盘需要时间。互联网发行来了，整个节奏变了，不是工程师更厉害了，是成本结构变了。现在这件事再发生一次，而成本结构一变，流程必须跟着变。但很多团队还没动。他们重写了这 6 件事然后 Fiona 讲了 Anthropic 工程团队实际改了哪些规范。每一条都很具体，有故事，有逻辑。第一件，规划的方式。她加入 Anthropic 的时候，团队做六个月路线图。结果这份图大概三个月就开始失效，然后不得不推倒重做。现在他们做的叫 JIT Planning，Just-In-Time，即时规划。需要的时候做刚好够用的计划，省下来的时间去做原型。不是不规划，是把花在纸上争论的时间换成了真实产出。第二件，技术争论怎么解决。她讲了一个很具体的故事。她和 Claude Code 负责人 Boris Cherny 在讨论一个 API 怎么重构，两个人意见不一样，快要走向白板了。她停下来，让 Claude 把两个方案各自实现成 PR。他们不只看到了两种代码实现，还看到了两种写法对调用方的影响分别是什么。争论就这么结束了。「当构建变得便宜，争论就变成了奢侈品。」这句话我觉得挺狠的。第三件，Code Review 的分工。这块他们有一套分得比较清楚的逻辑。Claude 负责代码风格检查、lint、PR 自身的格式反馈、小 bug、补充测试。人负责法务相关代码、安全敏感逻辑、产品判断。她讲了一个细节，笑死我了。团队有个终端吉祥物，有一次她让 Claude 给它加个节日主题。Claude 返回来的是一个穿礼服、戴单片眼镜的「Mr. Peanut」，而不是她想要的雪人。她说，这件事说明了什么，你看不看着顺不顺眼，这个 AI 现在还没搞定。产品审美这件事还是得人来把关。所以 review 分工的边界，不是随便划的。第四件，招聘逻辑。她的招聘团队想用经典公式，10 个工程师对 1 个经理，层层往上搭管理层。Fiona 说不行，她要扁平组织，而且每个经理入职必须先从 IC 开始，自己动手写代码，自己摸清楚团队在做什么。招聘团队的反应是，「没有经理愿意先去写代码的。」她的回答是，「那我们早点知道这件事，好过晚点知道。」这个逻辑很硬。如果一个人不愿意先进入自己要负责的那个系统，那你真的想要他来管这个系统吗？第五件，团队构成。以前工程师评估里，代码产出量是很重要的维度。现在这件事 Claude 替代了大半，她不再首选「高吞吐量的通才」，而是两类人，有产品感的创意型工程师（那种看到问题就想动手做原型的），以及有深厚系统背景的专家（分布式、底层基础设施）。同时，角色边界也在变。她团队的设计师和 PM 现在也在写代码，她自己需要起草用户调研问卷的时候，也会让 Claude 帮她出初稿。第六件，信息的来源在哪里。以前开会讲功能细节，大家翻的是产品文档或者规格书。Fiona 现在收到用户问题，直接打开 Claude Code，问代码库本身。代码是最终的真相，文档是附属品。她建议如果你们团队有维护得比较好的设计文档，把它 check in 到代码库里，让 Claude 可以同时看到规格和实现，用来发现两者之间的偏差。这件事本来靠人眼逐行对照，现在可以不用了。3 件不能商量的事在这 6 条可以商量怎么落地的规范之外，她还说了 3 件在 Claude Code 团队不容置疑的原则。第一，所有人都用 Claude Code。不只工程师，PM、设计师、所有跨职能伙伴都用。不然大家的工作方式和理解框架就没法对齐，AI 协作的优势就碎掉了。第二，「Claudify」一切可以自动化的环节。她举了个自己的例子，以前每天早上要手动打开用户反馈频道，让 Claude 给她总结一遍。Anthropic 的 Routines 功能上线之后，这件事变成了定时任务，她现在每天醒来邮件里就有摘要了。第三，明确授权团队成员「杀掉旧流程」。这条听起来最虚，但她觉得是最难落地的一条，因为它需要管理层真的在文化上表个态，而不只是说说。她讲了那个 50 人周例会的故事。所有人开着电脑各干各的，只在轮到自己发言的时候抬头。她去问了一句，「我们为什么要开这个会？」整个会议室点了点头。这个会直接取消了。那个会存在了多久，没有人说得清楚。也没有人问过这个问题。她还不知道答案的几件事演讲最后，她列了几个自己也没有答案的问题。我觉得这段最值得看，因为说明她没有在卖完整方案。当 Claude 可以让工程师低成本来回切换 iOS 和 Android 代码，独立的 iOS 团队和 Android 团队还有没有必要存在？她不知道。自动化 review 该推进到哪一步？她说的原则是「信任但要验证」，但信任多少、验证多少，这条线还在移动，没有固定答案。当设计师、PM、工程师都开始互相「借用」对方的工作，怎么确保每个人都有清晰的价值感和归属感？好看的时候很好看，但需要刻意去维护这个文化契约。这三个问题没有答案，但任何一个认真运营技术团队的人，都该找个时间坐下来认真想一想。瓶颈消失，工作不消失Fiona 在演讲结尾给了一个作业，找一个你自己最不想开的会，或者最不想写的报告，问自己两件事，它还在完成它原本的目的吗？如果没有，能 Claudify，还是直接砍掉？我想起工业化早期，很多工匠担心手艺没了用武之地。后来事情的走向是，手艺没消失，工匠开始管理流水线了。工程师大概也是这条路。只是这次变得快很多，而且很多团队还没意识到，他们的「流水线」早就在悄悄停止发挥作用了。Fiona 那句话我还是觉得说得最准，那些流程没有明着死掉，只是悄悄不工作了。你们团队里，现在有几个这样的流程？
现有AI都是假实时！Thinking Machines发布交互模型，离真正的贾维斯真的近了
Thinking Machines 发了一个新的交互模型，切入了一个更根本的问题：我们与 AI 交互的方式。它能够同时进行聆听、观察、说话、被打断、作出反应、在后台思考，以及调用工具。这一切并非靠语音转文字、轮次检测和各种智能体技巧拼接而成的流水线，而是一种原生的模型能力！如果这套机制能够实现，AI 将从“输入提示词、输出答案”的模式，转变为一种更像真正协同工作的体验。模型会注意到你的迟疑，会在看到情况时主动插话，会在一面听你说话时预判你的下一步行动。它不仅在变得更聪明，也在变得更善于维持与人之间自然流畅的对话。我们离真正的贾维斯更近了一步。Mira Murati的Thinking Machines Lab刚刚发布了新的研究成果：交互模型（interaction models）。核心思路：与其把实时交互功能拼接到原本按轮次工作的模型上，不如从头训练一个天生就能处理实时交互的模型。现在的AI，其实不是真实时用过语音AI的人都有这种感受：你必须说完，它才开始听。它说完，你才能接话。Murati把这个问题描述得很准确：当前的AI体验，往往感觉像是一场对话，只有在我们停止说话之后才真正开始。用户必须把想法攒成一批，不能指着东西说，甚至要把问题写得像发邮件一样。是人在适应模型，而不是模型适应人。问题出在架构层面。今天的模型是单线程感知现实的：用户没说完，模型就什么都感知不到；模型没生成完，感知就冻结，不接收任何新信息。这条人机协作的通道非常窄，人的知识、意图和判断，大量无法传递给模型；模型在做什么，人也很难随时介入理解。现有的解决方案是在模型外面套一个控制框架（harness），用语音活动检测等组件模拟打断、多模态输入、并发处理。但这些组件本身比模型要笨得多，天然限制了交互能力。比如"当我说错的时候打断我"或者"发现我代码里有bug就告诉我"，这类功能靠外挂根本做不到。更根本的矛盾在于：按照机器学习的苦涩教训，这些手工搭建的系统迟早会被通用能力的进步所超越。要让交互能力随着智能一起扩展，交互本身必须成为模型的一部分。从头训练，而不是外挂Thinking Machines的做法是训练一个原生支持实时交互的模型。系统由两部分组成：一个持续与用户保持双向交换的交互模型，加上一个异步运行的后台模型。交互模型负责实时感知和响应；当任务需要更深度的推理时，交互模型把任务委派给后台模型，后台模型在完成后把结果流式传回，交互模型再选择合适的时机把结果融入对话，而不是突兀地切换上下文。交互模型在整个过程中始终保持在线：接收新输入、回答追问、维持对话线索。这样的分工，让用户同时获得两种能力：非思考型模型的响应速度，以及推理模型的规划、工具调用和智能体工作流。交互模型本身也具备独立的智能，在交互基准和智能基准上都有竞争力。架构细节时间对齐的微轮次（Micro-Turns）交互模型以200毫秒为单位连续工作，交替处理200毫秒的输入和生成200毫秒的输出。输入和输出都被当作流来处理，没有人为设定的轮次边界。借助这个设计，模型可以在说话的同时听，比如西班牙语实时翻译成英语；也可以在看视频的同时说话，比如给体育比赛做实时解说。无编码器的早期融合（Encoder-free Early Fusion）大多数全模态模型需要分别训练独立的音频编码器（类似Whisper）和解码器（类似TTS模型）。Thinking Machines的方案是最小化预处理：音频信号以dMel格式输入，经过轻量嵌入层处理；图像切分为40×40的图块，由hMLP编码；音频解码器使用flow head。所有组件从头联合训练，与Transformer一体。这样的好处是，各种交互模式不再需要专门的控制框架，而是成为模型本身能力的自然延伸，并且可以随模型规模提升。推理优化200毫秒的分块意味着需要频繁、小批量的prefill和decode，现有的大语言模型推理库并不为此优化，每轮都有大量额外开销。Thinking Machines实现了流式会话（streaming sessions）：客户端把每个200毫秒的分块作为独立请求发送，推理服务器把这些分块追加到GPU显存中的持久序列里，避免频繁的内存重新分配和元数据计算。这一特性已向上游提交至SGLang。同时针对延迟和双向服务的形状做了内核优化，MoE内核采用gather+gemv策略替代标准的grouped gemm。训练器与采样器对齐Thinking Machines发现，训练器与采样器的逐位对齐（bitwise alignment）对训练稳定性和各组件调试都很有帮助。团队实现了批量无关的内核，端到端性能开销不超过5%。在通信内核方面，使用NVLS实现低延迟的All-Reduce和Reduce-Scatter，在Blackwell上具有确定性，并在序列并行和张量并行等不同并行策略之间实现逐位对齐。注意力机制的主要挑战是Split-KV，通过在decode和prefill之间保持一致的累积顺序来解决。安全性实时交互对安全的压力与按轮次交互不同。Thinking Machines的安全工作聚焦于两个方向：一是适合语音场景的拒绝方式。他们用TTS模型生成自然口语化的拒绝和过度拒绝训练数据，覆盖多种不允许的话题类别，让拒绝听起来自然但毫不妥协。二是长对话中的鲁棒性。使用自动化红队框架生成多轮拒绝数据，并与模型基于文本的拒绝行为保持高度一致。能做什么原生的交互能力，解锁了一系列此前需要外挂才能（或根本无法）实现的功能：无缝对话管理：模型隐式跟踪说话者是在思考、让步、自我修正还是在等待回应，无需独立的对话管理组件。口头和视觉插话：模型在合适的上下文中主动插话，而不是等用户说完。同时发言：用户和模型可以同时说话，比如实时翻译。时间感知：模型对已流逝的时间有直接感知。同步工具调用、搜索和生成式UI：在和用户说话、倾听的同时，模型可以并发地搜索、浏览网页或生成界面，并在需要时把结果融入对话。基准测试Thinking Machines发布了他们的模型TML-Interaction-Small，一个276B参数、12B激活的MoE模型。在交互质量方面，他们使用FD-bench进行评测，该基准针对交互性设计，覆盖用户打断、用户反馈、和他人交谈、背景语音等场景。在智能方面，使用Audio MultiChallenge基准。结果显示，TML-Interaction-Small是第一个在强智能/指令遵循和强交互性上同时表现优秀的模型。现有的交互基准还没能捕捉到这个模型带来的质性跃升。为此，Thinking Machines还构建了几个内部基准：时间感知和同步发言TimeSpeak：测试模型能否在用户指定的时间点开口说话，并输出正确内容。例如：让我练习呼吸，每4秒提醒我呼气吸气，直到我让你停。CueSpeak：测试模型是否在正确时机、以语义正确的回应发言。数据集专门设计为模型需要和用户同时说话才能拿到满分。例如：每当我切换语言，立刻给我纠正原语言中正确的词。视觉主动性现有商用实时API通过纯音频的对话管理框架做轮次检测，只响应语音轮次，无法在视觉世界发生变化时主动开口。比如当用户说请数我做了几个俯卧撑时，这类系统可能回应好的之后就保持沉默，因为没有音频触发信号。Thinking Machines改编了三个基准来评测视觉主动性：• RepCount-A：包含重复动作视频，改编为在线计数任务。模型需要跟踪动作并在正确时机报数。• ProactiveVideoQA：包含在特定时刻才能回答的问题，测试模型能否主动在正确时机给出答案。留空不说可得25分基础分，正确回答才能得高分，错误回答有惩罚。• Charades：标准时序动作定位基准，模型需要说出动作开始和结束的时间点。目前没有任何现有模型能有效完成上述任务，包括GPT Realtime-2和各类思考型高端模型，它们要么保持沉默，要么给出错误答案。局限与未来计划Thinking Machines也坦诚列出了当前的局限：• 长会话方面，音频和视频会快速积累上下文，流式会话设计能较好处理短中期交互，但超长会话仍需仔细管理上下文，这是当前的重点方向。• 计算与部署方面，低延迟的音视频流式传输需要稳定的网络连接，连接质量差会显著降低体验。• 模型规模方面，TML-Interaction-Small是276B参数的MoE，激活参数12B。团队预计交互能力会随模型规模提升，但更大的预训练模型目前速度太慢，无法在这一场景部署。计划今年晚些时候发布更大的模型。• 后台智能体方面，除了实时交互，智能体能力同样是核心。Thinking Machines认为交互模型和后台智能体如何更好地协同，目前才刚刚触及表面。
互联网行业AI推理场景存储使用情况及痛点有奖探讨
探讨背景：随着多模态、代码助手、各类Agent等AI技术发展，长序列上下文带来KVCache/记忆/知识容量剧增，HBM+DRAM的模式已经不足以支撑。业界通过引入SSD进行KVCache卸载，提升容量以提升命中率，极大地降低了TTFT，减少XPU开销，同时可支撑更长上下文。NVIDIA在2026年1月发布ICMS及BF4，引入DPU直通盘框+SSD盘作为G3.5层KVCache。华为存储将持续投入AI推理降本增效的研究，通过此调研，希望了解大家在AI场景存储的使用方式及痛点，打造性能强劲、生态兼容、易用的DPU直通盘框产品及最具性价比的KVCache方案。奖项设置：一等奖（1名）：HUAWEI WATCH GT 6（14880智豆）二等奖（2名）：HUAWEI FreeBuds 7i 贝母白（5990智豆）三等奖（3名）：JDC周边电脑包（中号）（1290智豆）价值奖（20名）：200-500智豆（200-500智豆）活动规则：1、为了保护各位的观点信息，所有回复均被设为仅自己可见。2、禁止小号参与活动，否则取消活动资格。3、回帖提交要求：重复帖、抄袭、AI作答帖、灌水帖及非研讨范围内的帖子无效。4、本次评奖规则由华为专家评审团进行评审。5、本次活动解释权归华为JDC社区所有。6、同意由管理员摘取回帖内容匿名共享在本社区，供社区用户学习。7、回复内容请勿涉及第三方非公开的信息。
行业全闪场景和需求有奖探讨
探讨背景：为更好地了解您对企业全闪化转型的现状与需求，我们特此展开此探讨，本探讨旨在收集各行业在全闪化应用场景、存储容量、数据缩减、关键需求等方面的信息。奖项设置：一等奖（1名）：HUAWEI WATCH GT 6（14880智豆）二等奖（2名）：HUAWEI FreeBuds 7i 贝母白（5990智豆）三等奖（3名）：JDC周边电脑包（中号）（1290智豆）价值奖（20名）：200-500智豆（200-500智豆）活动规则：1、为了保护各位的观点信息，所有回复均被设为仅自己可见。2、禁止小号参与活动，否则取消活动资格。3、回帖提交要求：重复帖、抄袭、AI作答帖、灌水帖及非研讨范围内的帖子无效。4、本次评奖规则由华为专家评审团进行评审。5、本次活动解释权归华为JDC社区所有。6、同意由管理员摘取回帖内容匿名共享在本社区，供社区用户学习。7、回复内容请勿涉及第三方非公开的信息。
企业AI Agent落地现状与挑战有奖探讨
探讨背景：随着大模型技术的飞速发展，越来越多的企业开始将其融入核心业务流程，探索打造智能化的AI Agent（如智能助手、自动化决策代理、数据查询与分析代理等），以提升效率、优化决策。为了深入了解企业在落地AI Agent过程中的实际场景、应用进展及面临的核心挑战，我们邀请您参与本次探讨。您的反馈将帮助我们准确把握企业需求，为优化技术产品、提供更具针对性的解决方案提供关键输入。奖项设置：一等奖（1名）：HUAWEI WATCH GT 6（14880智豆）二等奖（2名）：HUAWEI FreeBuds 7i 贝母白（5990智豆）三等奖（3名）：JDC周边电脑包（中号）（1290智豆）价值奖（20名）：200-500智豆（200-500智豆）活动规则：1、为了保护各位的观点信息，所有回复均被设为仅自己可见。2、禁止小号参与活动，否则取消活动资格。3、回帖提交要求：重复帖、抄袭、AI作答帖、灌水帖及非研讨范围内的帖子无效。4、本次评奖规则由华为专家评审团进行评审。5、本次活动解释权归华为JDC社区所有。6、同意由管理员摘取回帖内容匿名共享在本社区，供社区用户学习。7、回复内容请勿涉及第三方非公开的信息。
现实版变形金刚一拳砸穿砖墙！央视解读宇树首款载人变形机甲
日前，宇树科技正式发布全球首款量产版载人变形机甲GD01。GD01可像“变形金刚”一样直立行走、挥拳击穿砖墙，也能切换成“四足形态”翻越复杂地形，甚至还可以坐进机甲内部进行驾驶体验。官方介绍，GD01搭载500公斤级动态平衡控制系统，可在双足与四足两种模式之间无缝切换。其中，双足模式下适用于城市街道行走与转弯；四足模式则可攀爬楼梯、斜坡等复杂地形。对于这款“超级机甲”，央视新闻也进行了报道。中国科学技术大学工程科学学院副院长张世武表示，GD01比较有意义，因为它是第一款能看到是机甲的机器人。他认为，从运动能力来看，GD01不仅可以行走，还能非常顺畅地转变为四足行走，这一点比较有意思，也做得比较好，不过，该产品售价为390万元，价格较高。张世武表示，GD01目前最大的意义在于“它是第一款”，但从功能上看仍有一定限制。他指出，人形机器人实际上第一个就是在一些特种作业的场合，比如救灾救援等复杂场景它可以进去，另外一个就是做特效，影视特效会比较好。不过，如果将其作为民用交通工具来看，仍然还有一段路要走。相比当前轮式、飞行等出行方式还是有差距的，解决了安全性、能量问题、速度问题后，它的应用场合会更广。
企业内虚拟化场景SDN能力使用情况有奖探讨
探讨背景：随着互联网技术的快速发展，网络规模和复杂性不断增加，传统网络架构已难以满足日益增长的业务需求。软件定义网络（Software-Defined Networking，简称SDN）作为一种新兴的网络架构，通过将网络设备的控制面与数据面分离，实现了网络的集中控制和灵活配置，为网络管理带来巨大变化。目前，SDN技术在数据中心、云计算、物联网等领域已得到广泛应用，但其在实际部署过程中仍面临诸多挑战，如性能瓶颈、安全性问题、标准化进程等。此外，随着5G、边缘计算等新兴技术的崛起，SDN技术也需要不断演进以适应新的应用场景。奖项设置：一等奖（1名）：HUAWEI WATCH GT 6（14880智豆）二等奖（2名）：HUAWEI FreeBuds 7i 贝母白（5990智豆）三等奖（3名）：JDC周边电脑包（中号）（1290智豆）价值奖（20名）：200-500智豆（200-500智豆）活动时间：活动时间：2026年03月12日至2026年03月26日活动规则：1、为了保护各位的观点信息，所有回复均被设为仅自己可见。2、禁止小号参与活动，否则取消活动资格。3、回帖提交要求：重复帖、抄袭、AI作答帖、灌水帖及非研讨范围内的帖子无效。4、本次评奖规则由华为专家评审团进行评审。5、本次活动解释权归华为JDC社区所有。6、同意由管理员摘取回帖内容匿名共享在本社区，供社区用户学习。7、回复内容请勿涉及第三方非公开的信息。
NAS核心应用场景及选择存储有奖探讨
探讨背景：目前随着技术发展，不同行业NAS核心场景各不相同，业务发展越来越多，对于运NAS存储的要求越来越迫切，我们期望通过本次探讨了解您的看法，请畅所欲言，不吝赐教。奖项设置：一等奖（1名）：HUAWEI WATCH GT 6（14880智豆）二等奖（2名）：HUAWEI FreeBuds 7i 贝母白（5990智豆）三等奖（3名）：JDC周边电脑包（中号）（1290智豆）价值奖（20名）：200-500智豆（200-500智豆）活动时间：活动时间：2026年03月18日至2026年04月01日活动规则：1、为了保护各位的观点信息，所有回复均被设为仅自己可见。2、禁止小号参与活动，否则取消活动资格。3、回帖提交要求：重复帖、抄袭、AI作答帖、灌水帖及非研讨范围内的帖子无效。4、本次评奖规则由华为专家评审团进行评审。5、本次活动解释权归华为JDC社区所有。6、同意由管理员摘取回帖内容匿名共享在本社区，供社区用户学习。7、回复内容请勿涉及第三方非公开的信息。
ARM 架构中的 SMMU 技术解析：原理到应用实现
在当今的计算领域，异构计算和设备虚拟化已成为不可阻挡的技术浪潮。随着人工智能、大数据、云计算等前沿技术的蓬勃发展，对计算性能和资源利用率的要求达到了前所未有的高度。传统的单一处理器架构已无法满足复杂多样的工作负载需求，于是，异构计算应运而生。它如同一个汇聚了各种专业 “选手” 的团队，将 CPU、GPU、DSP、FPGA 等不同类型的处理单元整合在同一计算平台中 ，各自发挥专长，协同完成复杂任务。但很多人不知道，异构计算和设备虚拟化这两个技术的背后，有一个容易被忽略却至关重要的“隐形枢纽”——ARM SMMU（系统内存管理单元）。它就像一座架在处理器和外设之间的桥梁，专门管I/O设备的地址翻译，说白了，它的性能好不好，直接决定了整个系统的I/O内存管理效率，甚至影响到我们平时用的虚拟机、高清视频、云服务能不能顺畅运行。咱们先说说老办法的痛点：以前大家都用DMA+物理地址访问的方式，看似省事，实则问题一堆。比如多个虚拟机共享一个物理设备时，不同虚拟机的地址空间怎么隔离？会不会出现地址冲突、数据泄露？还有，DMA没法操作虚拟地址，只能用连续的物理地址，可系统内存用久了就会碎片化，想找一块大的连续物理地址比登天还难，很容易卡住，拖慢整个系统。而ARM SMMU的出现，正好解决了这些头疼事。在虚拟化场景里，它能精准实现GPA（客户物理地址）和HPA（主机物理地址）的映射，给每个虚拟机划一块独立的“内存自留地”，隔离得明明白白；同时还能支持多设备同时访问内存，解决DMA的寻址瓶颈。可以说，没有SMMU，异构计算和虚拟化很难落地到我们日常接触的技术场景里。一、ARM SMMU的底层架构与核心逻辑1. SMMU的定位在ARM架构里，SMMU的角色很明确——I/O设备和总线之间的“智能翻译官”，所有I/O设备要访问内存，都得先经过它“翻译”地址。很多小伙伴会把它和MMU搞混，其实两者的分工特别清晰：• MMU（内存管理单元）：藏在CPU内部，管的是CPU视角的内存访问，主要负责把CPU产生的虚拟地址转换成物理地址，同时检查访问权限，防止不同进程乱抢内存，相当于CPU的“专属地址翻译”。• SMMU（系统内存管理单元）：架在I/O设备和总线之间，不管是GPU、网卡还是存储控制器，只要想访问内存，都得找它帮忙翻译地址。它主要干三件事：地址转换、内存属性转换、权限检查，相当于所有外设的“公共翻译官”。举个通俗的例子：CPU访问内存，就像你在自己家里找东西，MMU帮你确认“房间号”（物理地址）；而外设访问内存，就像客人来你家找东西，SMMU先确认客人的身份（StreamID），再把客人说的“虚拟房间号”（IOVA）翻译成你家实际的“房间号”（物理地址），还得检查客人有没有权限进那个房间，避免乱翻东西。。2. SMMU 的核心价值首先是地址转换。在实际应用中，外设需要访问内存中的数据，但这些数据在内存中的存储位置可能是不连续的。SMMU 就像是一位聪明的 “导航员”，它能够将外设发出的虚拟地址（IOVA，I/O Virtual Address）精准地映射为物理地址，让外设能够顺利找到所需的数据，解决了外设访问非连续物理内存的难题。访问控制也是 SMMU 的重要职责。在一个复杂的系统中，内存中存储着各种重要的数据，需要防止外设越界访问敏感内存区域，以免造成数据泄露或系统故障。SMMU 通过严格的权限校验，就像一位坚守岗位的 “门卫”，只有合法的访问请求才能通过，确保了内存的安全性。在如今的云计算和边缘计算等场景中，虚拟化技术得到了广泛应用。SMMU 为多虚拟机环境提供了强大的支持，它可以为每个虚拟机分配独立的地址空间，实现设备在多个虚拟机之间的安全共享。这就好比为每个虚拟机都提供了一个专属的 “房间”，它们之间相互隔离，互不干扰，保障了虚拟化环境的稳定运行，是云原生、边缘计算场景的技术基石。3. SMMU 核心架构组件解析(1) 流（Stream）与流匹配表（Stream Table）在 SMMU 的架构中，流（Stream）是一个非常重要的概念。简单来说，每个外设的内存请求端口都可以看作是一个独立的 “流”，每个流都有一个唯一的标识，即流 ID（SID，Stream ID） 。这个 SID 就像是每个外设的 “身份证”，独一无二。流匹配表（Stream Table）则是 SMMU 区分不同外设请求的关键组件。它的核心作用是通过 SID 来匹配对应的地址转换上下文。举个例子，当一个 GPU 和一个网卡同时向外设内存发起访问请求时，SMMU 会根据它们各自的 SID，在流匹配表中快速找到对应的上下文信息，从而为它们分别提供合适的地址转换服务，实现不同外设的内存访问策略隔离。可以说，流匹配表是 SMMU 区分设备请求的 “识别器”，确保每个外设的请求都能得到准确的处理。(2) 上下文（Context）与地址转换表上下文（Context）是 SMMU 中的另一个核心概念，它可以理解为地址转换表的集合。每个上下文都包含了外设进行内存访问时所需的关键配置信息，比如外设的页表基址、访问权限等。这些信息就像是为外设量身定制的 “专属内存访问规则手册”，详细规定了外设如何访问内存。地址转换表则是实现虚拟地址到物理地址映射的核心数据结构。它遵循 ARM 多级页表结构，就像一本详细的 “地址映射字典”。当外设发出一个虚拟地址请求时，SMMU 会根据上下文找到对应的地址转换表，然后按照表中的映射规则，逐步计算出对应的物理地址。例如，在一个复杂的多媒体处理系统中，GPU 需要频繁访问内存中的图像数据，SMMU 就会通过上下文和地址转换表，快速准确地将 GPU 发出的虚拟地址转换为物理地址，确保图像数据的高效传输和处理。(3) 转换旁路缓存（TLB）：性能加速关键为了提高地址转换的效率，SMMU 引入了转换旁路缓存（TLB，Translation Lookaside Buffer） 。TLB 就像是一个高速缓存，它缓存了外设最近的地址转换结果。当外设发起重复的地址请求时，SMMU 可以直接从 TLB 中读取映射关系，而无需再次遍历多级页表，这大大降低了内存访问延迟，节省了宝贵的总线带宽。举个例子，在一个频繁进行数据读写的存储系统中，如果没有 TLB，每次外设访问内存都需要花费较长的时间来查找页表，这会严重影响系统的性能。而有了 TLB 之后，当外设再次访问相同的地址时，SMMU 可以在极短的时间内从 TLB 中获取地址转换结果，实现快速的数据读写，大大提升了系统的响应速度。不过，需要注意的是，在上下文切换时，TLB 中的缓存内容可能会变得无效，这时就需要进行 TLB 刷新操作，以确保映射关系的一致性。这就好比在更换 “地址映射字典” 时，需要清理掉之前缓存的旧信息，以免出现错误。4. SMMU 的中断与错误处理机制在 SMMU 的工作过程中，难免会遇到各种错误情况，比如地址转换失败、权限不足等。为了保证系统的稳定性和可靠性，SMMU 具备完善的中断与错误处理机制。当 SMMU 检测到错误时，它会首先拦截这些错误，并根据预设的规则将中断信号转发至指定的 CPU 核心。常见的错误类型有很多，比如虚拟地址在地址转换表中没有对应的映射，就像在 “地址映射字典” 中找不到对应的词条；或者外设试图访问超出其权限范围的内存区域，这就如同一个没有权限的人试图进入一个禁止进入的房间。一旦发生这些错误，SMMU 会按照既定的错误处理流程进行处理。首先，它会记录详细的错误信息，包括错误类型、发生错误的地址等，这些信息就像是一份 “错误报告”，为后续的故障排查提供重要线索。然后，SMMU 会根据错误的严重程度采取相应的措施，对于一些轻微的错误，它可能会尝试进行自动纠正；而对于严重的错误，它会及时通知操作系统，由操作系统来进行进一步的处理，比如终止相关的进程，以防止错误扩散，保障整个系统的稳定运行。可以说，SMMU 的错误处理流程是保障系统稳定性的重要防线，也是我们在进行系统故障排查时的核心切入点。SMMU通用流程：二、SMMU 完整工作流程1. 前置条件：SMMU 的初始化配置在系统启动阶段，SMMU 就像是一位即将出征的战士，需要进行一系列的准备工作，以确保其能够正常运行。这一过程涉及到三个关键步骤，每一步都至关重要，就像搭建一座高楼的基石一样。初始化寄存器是第一步，也是最为基础的一步。这一步主要是对页表控制寄存器、内存属性寄存器等进行设置。这些寄存器就像是 SMMU 的 “指挥中心”，它们的设置决定了地址转换的规则和内存的访问属性。通过设置页表控制寄存器，我们可以确定页表的大小、级数等参数，为后续的地址转换工作奠定基础。而内存属性寄存器则负责设定内存的读写权限、缓存属性等，确保内存访问的安全性和高效性。构建流匹配表与上下文是初始化过程中的核心步骤。在这一步中，我们需要为每个外设分配唯一的 SID，并将其与对应的上下文进行绑定。上下文就像是外设的 “专属档案”，里面记录了外设的页表基址、访问权限等重要信息。通过流匹配表，SMMU 可以快速地根据外设的 SID 找到对应的上下文，从而实现对不同外设的精准管理。例如，在一个包含多个 GPU 和网卡的系统中，每个设备都有自己独特的 SID，SMMU 通过流匹配表和上下文，可以为每个设备提供独立的地址转换服务，保证它们之间的内存访问互不干扰。当所有的寄存器和数据结构都配置完成后，就可以启用 SMMU 功能了。这就像是按下了启动按钮，SMMU 开始正式工作，对外设的内存访问请求进行拦截和处理，为系统的稳定运行保驾护航。2. 核心流程：外设内存请求的 “五步法” 处理(1) 步骤 1：外设发起 DMA 请求在系统运行过程中，GPU、网卡等外设会根据自身的工作需求，向外设内存发起 DMA 请求。这个请求就像是外设发出的 “任务指令”，其中包含了关键的信息，即 IOVA（I/O 虚拟地址）和流 ID（SID） 。IOVA 是外设自己认为的数据存储地址，而 SID 则是外设的 “身份标识”，用于 SMMU 识别请求的来源。例如，当 GPU 需要读取内存中的图像数据进行渲染时，它会生成一个包含目标图像数据 IOVA 和自身 SID 的 DMA 请求。这个请求一旦发出，就会被 SMMU 硬件自动拦截，就像一个 “交通警察” 拦截过往的车辆一样，进入后续的地址转换流程。(2) 步骤 2：流 ID 匹配上下文SMMU 在接收到外设的 DMA 请求后，会首先根据请求中的 SID，在流匹配表中进行查找。流匹配表就像是一本 “身份信息字典”，SMMU 通过 SID 这个 “索引”，能够快速地找到该外设对应的上下文。在一些复杂的系统中，流匹配表可能采用多级结构，这就需要 SMMU 根据 SID 的高低位进行分层查找，就像在一本厚厚的字典中按照目录和页码查找特定的词条一样。通过这种方式，SMMU 能够确保精准地匹配到该外设专属的地址转换规则，为后续的地址转换工作提供准确的依据。(3) 步骤 3：地址转换与权限校验找到对应的上下文后，SMMU 就开始了关键的地址转换工作。它会根据上下文中的页表基址，遍历多级地址转换表，就像在一个复杂的迷宫中按照地图寻找出口一样，将 IOVA 逐步转换为物理地址。在这个过程中，SMMU 还会对权限进行严格的校验，检查外设对目标内存区域是否具有读、写或执行权限。如果发现权限不匹配，就像一个没有钥匙的人试图进入一间上锁的房间，SMMU 会立即触发错误中断，阻止外设的非法访问，保障内存的安全。(4) 步骤 4：TLB 缓存加速优化为了提高地址转换的效率，SMMU 在完成地址转换后，会将得到的映射关系存入 TLB（转换旁路缓存） 。TLB 就像是一个高速缓存区，里面存放着最近使用过的地址转换结果。当下次同一外设发起相同地址的请求时，SMMU 会优先查询 TLB，就像在一个快速检索的数据库中查找信息一样。如果 TLB 中存在匹配的映射关系，SMMU 就可以跳过繁琐的页表遍历步骤，直接使用 TLB 中的结果，大大提高了内存访问的速度，提升了系统的整体性能。(5) 步骤 5：执行内存访问或错误上报经过前面几个步骤的处理，如果地址转换和权限校验都顺利通过，SMMU 就会将转换后的物理地址返回给外设，就像为外设找到了通往目标内存区域的 “正确路径”，允许外设访问目标内存区域，完成数据的传输或操作。但如果在任何一个环节出现错误，比如地址转换失败或者权限不足，SMMU 会立即终止请求，并向 CPU 上报中断，就像遇到紧急情况时发出警报一样。CPU 接收到中断后，会根据中断信息进行相应的处理，例如通知操作系统进行错误排查和修复，确保系统的稳定性和可靠性。3. 进阶场景：虚拟化下的两级地址转换在虚拟化环境中，SMMU 的工作流程变得更加复杂，但也更加重要。它需要支持两级地址转换，就像在一个多层的建筑中找到正确的房间，需要经过两次指引一样。Stage1 负责将客户虚拟地址（GVA，Guest Virtual Address）转换为客户物理地址（GPA，Guest Physical Address） ，这一过程主要由 Guest 操作系统管理，就像在一个小区内找到对应的楼栋。而 Stage2 则是将客户物理地址（GPA）转换为主机物理地址（HPA，Host Physical Address） ，这一步由 Hypervisor 控制，就像在城市中找到对应的小区。通过这两级转换，SMMU 实现了虚拟机地址空间与主机地址空间的隔离和映射。Hypervisor 在这个过程中扮演着关键的角色，它通过配置上下文，为每个虚拟机分配独立的地址空间，就像为每个租客分配独立的房间。这样，即使多个虚拟机共享同一物理设备，它们之间的内存访问也不会相互干扰，实现了设备在多虚拟机环境下的安全直通。例如，在云计算环境中，多个虚拟机可能同时运行不同的应用程序，通过 SMMU 的两级地址转换，每个虚拟机都可以安全地使用 GPU 等外设，而不用担心数据泄露或冲突的问题，大大降低了虚拟化 I/O 性能损耗，提高了资源利用率。三、SMMU 如何实现 IO 一致性？1. IO 一致性的核心诉求：外设与 CPU 缓存数据同步在多处理器和多核系统中，IO 一致性是一个至关重要的概念，它就像是确保整个计算系统和谐运行的 “协调器”。简单来说，IO 一致性指的是外设访问的内存数据与 CPU 缓存数据能够保持实时同步。这一机制的缺失会导致一系列严重的问题。比如，当 CPU 对内存中的某个数据进行了修改，由于缓存的存在，这个修改可能暂时只存在于 CPU 的缓存中，还未被写回到主内存。如果此时外设需要读取这个数据，由于没有 IO 一致性机制的保障，外设可能会从主内存中读取到过期的数据，就像从一个旧文件中获取信息一样，得到的是错误或过时的内容。同样，当外设向内存写入数据时，如果没有及时通知 CPU 更新其缓存，CPU 在后续的操作中可能仍然使用缓存中的旧数据，这就好像 CPU 对刚刚发生的重要事件一无所知，继续按照旧的信息进行工作，从而导致数据不一致的问题。这些数据不一致的情况会严重影响系统的正确性和稳定性，就像一个团队中成员之间信息不畅通，各自按照自己的理解行事，必然会导致工作出现混乱。而 SMMU 通过硬件协作与协议支持，就像一个高效的信息传递员，实现了零软件开销的一致性保障，确保了外设和 CPU 之间的数据能够实时同步，为系统的稳定运行提供了坚实的基础。2. SMMU 保障 IO 一致性的硬件机制(1) ACE-Lite 协议：总线级一致性交互SMMU 能够支持 ACE-Lite 一致性总线协议，这一协议就像是一座搭建在外设和 CPU 缓存之间的 “高速桥梁”，为实现 IO 一致性提供了关键的支持。在这个过程中，SMMU 扮演着一致性代理的重要角色，它能够代表外设向 CPU 缓存控制器发起侦听（Snoop）请求。当外设需要读取内存中的数据时，SMMU 会迅速行动起来。它首先将外设的请求进行转换，然后向 CPU 缓存控制器发送带有侦听标志的请求。CPU 缓存控制器在接收到这个请求后，会对所有的 CPU 缓存进行广播，询问是否有缓存中存在外设所请求的数据。如果某个 CPU 缓存中正好有这个数据，并且其状态为已修改（Modified），说明这个数据是最新的，该 CPU 缓存就会响应并将最新的数据返回。数据会沿着 “CPU Cache → CCI（缓存一致性控制器） → SMMU” 的路径进行传输，最终 SMMU 将数据转发给外设。在这个过程中，缓存一致性控制器（CCI）起到了关键的协调作用，它不仅负责广播侦听请求，还负责聚合各个 CPU 缓存的响应数据。同时，在数据传输完成后，CCI 还会同步更新缓存的状态，将已修改（Modified）状态更新为共享（Shared）状态，确保缓存状态的一致性。通过这种方式，SMMU 有效地避免了外设读取过期缓存数据的问题，保证了数据的实时性和一致性。(2) 缓存属性配置：精准管控内存访问策略在 SMMU 的上下文与页表中，我们可以对内存区域的缓存属性进行精细的配置，这就像是为不同的内存区域贴上了不同的 “标签”，以便 SMMU 能够根据这些标签来精准地管控内存访问策略。常见的缓存属性有 Device-nGnRnE 和 Normal 等。对于那些对一致性要求极高的内存区域，我们可以将其标记为 Device-nGnRnE 属性。这意味着该区域是不可缓存的，并且无聚合、无重排序。当外设访问这类区域时，它会直接与物理内存进行交互，就像直接从源头获取信息一样，确保每次访问到的都是最新的数据，从而满足了强一致性的需求。而对于那些对性能有较高要求的区域，我们可以将其标记为 Normal 属性，使其可缓存。在这种情况下，为了平衡性能与一致性，我们需要借助硬件侦听机制。当外设访问这些区域时，SMMU 会利用硬件侦听技术，实时监测 CPU 缓存的状态，确保外设获取到的数据与 CPU 缓存中的数据保持一致。通过这种灵活的缓存属性配置，SMMU 能够根据不同的应用场景和需求，实现对内存访问策略的精准管控，在保证数据一致性的同时，最大限度地提升系统性能。(3) TLB 与缓存协同刷新当内存映射关系发生变更时，比如在进程切换、内存分配或释放等操作中，SMMU 需要确保地址转换结果与缓存数据的一致性，这就好比在更换地图后，要确保所有的导航信息都能及时更新。此时，SMMU 会同步刷新 TLB（转换旁路缓存）与 CPU 缓存。TLB 中存储着最近使用的地址转换结果，而 CPU 缓存中则存储着最近访问的数据。如果在内存映射关系变更后不进行刷新，TLB 中可能仍然保存着旧的地址映射信息，CPU 缓存中也可能保存着旧的数据，这就会导致地址转换错误和数据不一致的问题。SMMU 支持精细化刷新指令，这使得它能够根据具体的需求，精确地选择需要刷新的 TLB 和缓存条目，而不是像传统方式那样进行全局刷新。这种精细化的刷新方式就像是精准打击，能够避免全局刷新带来的性能损耗，大大提高了系统的效率。通过 TLB 与缓存的协同刷新，SMMU 有效地保证了在内存映射关系变更时，地址转换结果与缓存数据的一致性，为系统的稳定运行提供了有力的支持。3. 硬件一致性 vs 软件一致性：性能与复杂度对比在保障 IO 一致性的方案中，我们常常会面临硬件一致性和软件一致性两种选择，它们各有特点，就像两种不同的工具，适用于不同的场景。纯软件一致性方案需要 CPU 执行缓存清理指令，这就好比 CPU 要亲自去打扫缓存这个 “房间”，将缓存中的旧数据清理出去，确保数据的一致性。在清理完成后，CPU 还需要通知外设可以进行访问。这个过程不仅需要 CPU 花费额外的时间和精力来执行这些操作，而且容易出现人为疏漏。比如，在复杂的系统中，可能会因为代码逻辑的错误或者并发操作的影响，导致缓存清理不及时或不彻底，从而引发数据一致性问题。而且，由于软件操作的速度相对较慢，这种方案的延迟较高，会对系统的性能产生较大的影响。相比之下，SMMU 硬件一致性方案则展现出了明显的优势。它通过自动侦听与同步机制，就像一个智能的管家，能够实时监测外设和 CPU 之间的数据交互，自动完成数据的同步工作。当外设发起请求时，SMMU 能够迅速地与 CPU 缓存进行交互，确保外设获取到的是最新的数据，而无需 CPU 进行额外的干预。实验数据表明，在 Cortex-A78 + Mali-G78 平台上，SMMU 一致性使 DMA 延迟降低了 83%，大大提升了系统的性能。而且，这种硬件方案无需额外的软件干预，减少了人为因素导致的错误，提高了系统的可靠性。因此，在高性能计算场景中，SMMU 硬件一致性方案无疑是首选。不过，需要注意的是，在一些老旧外设不支持 ACE-Lite 协议的情况下，由于硬件无法直接实现一致性保障，我们就不得不 fallback 到软件方案。这时候，就需要软件开发者格外小心，仔细处理缓存清理和通知等操作，以确保数据的一致性。4. 一致性配置的关键要点与故障排查在进行 SMMU 一致性配置时，有几个关键要点需要我们特别关注。首先，流上下文的缓存属性必须与 CPU 侧内存属性保持一致，这就好比两个相互协作的团队，必须使用相同的 “工作语言”，否则就会出现沟通不畅和协作失败的问题。如果流上下文的缓存属性设置为可缓存，而 CPU 侧内存属性设置为不可缓存，就会导致数据不一致的情况发生。在虚拟化场景中，情况会更加复杂一些。我们不仅要配置好 Stage1 的一致性策略，还要同步配置 Stage2 的一致性策略。这是因为在虚拟化环境下，虚拟机的地址空间需要经过两次转换，Stage1 负责将客户虚拟地址转换为客户物理地址，Stage2 负责将客户物理地址转换为主机物理地址。只有确保这两个阶段的一致性策略都正确配置，才能保证虚拟机与主机之间的数据一致性。当出现一致性故障时，数据错乱和访问延迟过高是比较常见的表现。这时候，我们可以通过检查 SMMU 寄存器的一致性使能位来判断一致性功能是否正常开启。如果使能位未设置，那么一致性功能就无法正常工作，可能会导致数据不一致的问题。监控 TLB 刷新频率也是一个有效的排查方法。如果 TLB 刷新频率过高，可能意味着内存映射关系频繁变更，或者存在配置不当的情况，这时候就需要进一步检查配置是否正确，以及系统中是否存在异常的内存操作。通过这些关键要点的把握和故障排查方法的运用，我们能够更好地配置和维护 SMMU 的一致性，确保系统的稳定运行。四、SMMU 的典型应用场景1. 虚拟化场景：设备直通与多租户隔离在如今的云计算时代，云服务器需要支持多个租户同时使用，这就对设备的隔离和性能提出了极高的要求。SMMU 在其中发挥着关键的作用，它能够支持 GPU、网卡等外设直通给虚拟机，实现设备在多虚拟机环境下的高效利用。通过两级地址转换，SMMU 为每个虚拟机分配独立的地址空间，就像为每个租户提供了一个独立的 “小天地”，确保虚拟机之间的内存数据不会相互泄露。这种强大的内存隔离能力，不仅提升了 I/O 性能，让每个虚拟机都能快速地访问外设，还为云原生架构提供了核心硬件支撑，保障了云计算环境的稳定性和安全性。例如，在一些大型的云服务提供商中，SMMU 被广泛应用于实现 GPU 虚拟化，为众多科研机构和企业提供强大的计算能力，支持他们进行复杂的数据分析和模拟实验。2. 嵌入式与边缘计算：内存安全与碎片化解决在手机、车载等嵌入式设备中，SMMU 同样展现出了巨大的价值。以手机为例，手机中的摄像头、基带等外设需要频繁地访问内存，SMMU 可以通过设置严格的内存访问规则，限制这些外设的内存访问范围，就像为它们划定了一个 “活动区域”，降低了恶意攻击的风险，保护了用户的隐私和数据安全。嵌入式设备的内存资源相对有限，容易出现内存碎片化的问题。SMMU 能够将非连续的物理内存映射为连续的虚拟地址，这就好比将一堆零散的拼图碎片重新拼接成一幅完整的图画，解决了外设 DMA 对连续物理内存的依赖，提高了内存的利用率。在边缘计算场景中，SMMU 的这种能力使得边缘设备能够更高效地处理数据，减少数据传输的延迟，为实时性要求较高的应用提供了有力支持。例如，在智能交通系统中，路边的摄像头通过 SMMU 实现高效的内存访问，能够快速地将采集到的图像数据进行处理和分析，为交通管理提供准确的信息。3. 异构计算：CPU 与 GPU 的共享内存协同在 AI 训练、图形渲染等对计算性能要求极高的场景中，异构计算成为了提升效率的关键技术。SMMU 在其中扮演着重要的角色，它支持 CPU 与 GPU 共享虚拟地址空间，使得指针可以直接在两者之间传递，就像在两个紧密合作的团队之间建立了一条 “快速通道”，无需进行繁琐的内存拷贝操作。这样一来，大大简化了异构编程模型，提高了数据交互的效率。在 AI 训练中，CPU 负责处理复杂的逻辑控制和数据预处理，GPU 则专注于大规模的矩阵运算和模型训练，通过 SMMU 的协同，两者能够高效地协作，加速模型的训练过程。在图形渲染领域，SMMU 也能够让 CPU 和 GPU 更好地配合，实现高质量的图像渲染，为用户带来更加逼真的视觉体验。例如，在一些高端的游戏主机中，SMMU 助力 CPU 和 GPU 协同工作，使得游戏画面更加流畅，细节更加丰富。