本文引用了45岁老架构师尼恩的技术分享，有修订和重新排版。

1、引言

接上篇《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》，本文主要聚焦分布式IM聊天系统消息可靠性问题，即如何保证消息不丢失。

2、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第 2 篇：
《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》
《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》（☜ 本文）

本篇主要聚焦的是分布式IM聊天系统消息可靠性问题。

3、痛点拆解：聊天消息总是丢？不是网络差，是设计没兜底

产品做着做着，用户开始投诉：“我明明发了消息，对方怎么没收到？”。你查日志发现——消息真丢了。但更可怕的是：你也不知道它什么时候丢的。

这背后，其实是移动场景下的经典三连击：
1）地铁进隧道，网络闪断；
2）App 被系统杀掉，进程没了；
3）对方服务器刚好在发布，接口500……

你以为只是“发一下”，其实要穿越重重险境才能抵达。

结果就是：

• 消息发不出去 → 用户以为被无视；
• 或者重试太多 → 对方收到一堆重复“在吗？”；
• 最后用户体验崩了，客服工单爆了。

所以问题本质不是“快不快”，而是：“宁可慢点，也不能丢；就算重发，也不能重复。”这就是我们常说的可靠消息投递 ——一个看似简单的需求，却是高可用系统的分水岭。

4、解决方案：三层兜底，像保险一样层层防

光靠“发一次”肯定不行。我们要学保险公司，给关键消息上三重保险：1）自己先复印一份存档 → 客户端本地存2）邮局签收后锁进保险柜，并异地备份 → 服务端落盘 + 副本3）如果没收到回执，隔段时间再寄，但对方只认一次 → 超时重试 + 幂等去重每一层都不贵，合起来却能扛住99%的异常。下面看每层怎么落地。

5、第一层：客户端兜底 —— 消息先存本地，解决网络不稳定问题

记住一句话：只要没收到 ACK，就当没发成功。所以第一步不是联网，而是先把消息塞进手机本地数据库（比如 SQLite）。就像下面这样：db.saveLocalMsg(msg); // 先落库，保命boolean sendOk = network.send(msg);if (!sendOk) {    scheduleRetry(msg, 1000); // 发失败？排队重试}再加上客户端scheduleRetry  采用阶梯式重试策略：1）第1次失败 → 1秒后重试2）第2次失败 → 3秒后重试3）第3次失败 → 5秒后重试避免雪崩式刷屏，既保障可靠性，又不压垮服务。只有等到服务端明确说“我收到了”，才把这条消息从本地删掉。就像快递发货单：客户签收了，你才能撕票。这样哪怕 App 崩溃、手机重启，下次打开照样继续发——用户体验无缝衔接。而如果不做这一步？一旦断网或崩溃，消息直接蒸发，用户永远不知道。

6、第二层：服务端兜底 —— 实现 服务端持久化的高可靠

客户端发来了，服务端能不能直接处理完就返回？绝对不行！如果此时机器宕机，消息还在内存里没来得及持久化，那就真的丢了。正确做法是两步走：1）收到消息立刻写入 RocketMQ（支持刷盘、集群同步）；2）同步复制到至少3个副本节点，确保单点故障不丢数据。伪代码如下：rocketMQ.send(msg); // 必须落盘，断电也不怕replicaService.syncTo3Replicas(msg); // 多副本容灾response.sendAck(msg.getUniqueKey()); // 此时才能回 ACK这一步的关键是：ACK 必须在落盘之后发！否则就是“虚假确认”，等于骗客户端“我收到了”，其实自己也没保住。这一层扛住了服务端单机崩溃的风险，是整个链路的数据基石。

7、第三层：幂等性设计 —— 保障exact one

前面两层解决了“存得住”的问题，但这还不够。现实是：网络可能超时、包可能丢失、ACK 可能没传回来。于是客户端必须重试。但重试带来新问题：“我已经处理过了，再来一遍怎么办？”解决办法是：用唯一键 + 幂等控制。每个消息生成全局唯一的 key（如 sessionID:msgID），服务端通过 Redis 的原子操作判断是否已处理。就像下面的代码这样：String uniqueKey = msg.getUniqueKey();if (redis.setNx(uniqueKey, "processed", 86400)) {    processMsg(msg); // 第一次来，正常处理} else {    log.info("重复消息，忽略：{}", uniqueKey);}setNx 是关键：只有 key 不存在时才设置成功，保证多实例并发下也不会重复消费。

8、IM消息可靠性架构的核心流程总结

上面三层如何联动？一张图讲清楚全链路生命周期：

整条链路形成闭环：任何环节出问题，都有对应兜底机制接管。

9、本文小结

至此，《如何保障分布式IM聊天系统的消息有序性和可靠性》这期文章的上下两篇就完结了（上篇点此查看），上篇涉及到的分布式IM聊天系统架构中关于消息有序性问题，下篇则主要聚焦的是消息可靠性问题。如果你是IM开发新人，想要系统地学习移动端IM开发的话，建议从我整理的这篇《新手入门一篇就够：从零开发移动端IM》开始，这样能保证IM开发知识能从网络到应用层、再从局部设计到整体架构，都有一个系统的学习脉络而不是在信息碎片中苦苦总结。

10、参考资料

[1] 什么是IM聊天系统的可靠性？
[2] 什么是IM聊天系统的消息时序一致性？
[3] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）
[4] 马蜂窝旅游网的IM系统架构演进之路
[5] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[6] 从新手到专家：如何设计一套亿级消息量的分布式IM系统
[7] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
[8] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
[9] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践
[10] 阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计
[11] 基于实践：一套百万消息量小规模IM系统技术要点总结
[12] 一套分布式IM即时通讯系统的技术选型和架构设计
[13] 转转平台IM系统架构设计与实践(一)：整体架构设计
[14] 移动端弱网优化专题(一)：通俗易懂，理解移动网络的“弱”和“慢”
[15] 移动端弱网优化专题(二)：史上最全移动弱网络优化方法总结
[16] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？
[17] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
[18] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递
[19] 移动端IM中大规模群消息的推送如何保证效率、实时性？
[20] 如何保证IM实时消息的“时序性”与“一致性”？
[21] 一个低成本确保IM消息时序的方法探讨

即时通讯技术学习：

• 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
• 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4889-1-1.html）

​

Windows File Recovery Installer是 微软官方的 Windows 文件恢复工具安装包，可以用来找回不小心删掉的文件，比如文档、照片、视频啥的。

它是命令行工具，装好后要在 CMD 里用，不过安装本身很简单，下面一步步说。

一、准备工作

1. 下载安装包​

   安装包下载：https://pan.quark.cn/s/a732e471d107

2. 确认系统版本​

   • 需要 Windows 10 2004 及以上​ 或 Windows 11，不然装不了。
   • 必须是管理员账户，普通用户权限不够。

3. 关闭杀毒软件（可选） ​

   • 个别杀毒软件会误拦，安装时可暂时关掉，装完再开。

二、安装步骤

1. 双击 Windows File Recovery Installer.exe运行。
2. 如果是 Win10/Win11，会弹出“用户账户控制”提示 → 点 “是” （需要管理员权限）。
3. 进入安装界面，一般会自动检测系统并安装，不用手动选路径。
4. 等进度条走完，提示安装成功 → 点 “关闭” 。
5. 装好后，工具不会出现在桌面或开始菜单，它在系统里是以命令行的形式存在，要用就得打开 CMD。

三、验证是否安装成功

1. 按 Win+R输入 cmd→ 回车，打开命令提示符。
2. 输入 winfr回车，如果出现一长串用法说明，就说明装好了。
3. 如果提示“找不到命令”，可能是没装成功或环境变量没识别，重启电脑再试。

四、基本使用方法（简单说两句）

• 恢复文件的基本命令格式：

  winfr 源盘: 目标盘: /n 文件名或路径

例：`winfr C: D: /n \Users\张三\Desktop\test.docx`

• /r表示深度扫描（慢但找得多），/n后面跟要找的文件名或关键字。
• 恢复过程会生成个日志，别中途关 CMD。
• 恢复的文件会放到目标盘的 Recovery文件夹里。

​

随着大模型能力从以内容生成见长，逐步扩展至复杂任务推理与多步骤协同，2026 年被普遍视为企业级 AI 应用形态发生结构性变化的关键节点。在行业实践中，AI 正从独立能力模块，转变为嵌入业务系统内部的基础性认知组件。

这一变化的核心，并非模型参数规模的增长，而是 AI 与工作流（Workflow）的深度融合方式发生了本质转向。

一、应用形态演进：从外置工具到内生系统

早期阶段，AI 多以独立入口存在，用户需要主动切换场景进行调用。这种模式在知识问答和内容生产中有效，但在复杂业务中难以形成持续价值。

当前主流实践更强调 内生型架构，其特征主要体现在两个方面：

嵌入式智能（Embedded Intelligence） AI 能力被拆解为可复用的推理与生成模块，直接嵌入邮件系统、数据分析平台、研发工具链等既有软件环境中。系统可基于上下文自动触发智能响应，交互不再依赖显式指令。

流程级重构（Workflow Re-engineering） 企业不再将既有流程简单交由 AI 执行，而是围绕模型的不确定性处理能力重新设计流程结构。在这种模式下，人类负责目标设定与价值约束，AI 负责在非结构化节点中进行推理与执行。

二、深度融合的工程共识：三项核心支柱

在工程实现层面，工作流与 AI 的深度结合，已逐步形成稳定的技术范式，主要依托以下三项能力。

状态保持与上下文感知 系统需具备跨阶段的任务状态管理能力，能够理解任务所处阶段、前序动作及预期结果。通过持续更新的任务状态视图，AI 可参与长周期项目，而非一次性响应。

领域知识的动态注入 通用预训练模型难以覆盖企业级专业需求。行业实践普遍采用检索增强生成（RAG）架构，将内部文档、业务规则与实时数据作为推理输入，以保证执行结果的准确性与可追溯性。

跨系统工具调用能力 AI 不再局限于生成建议，而是通过标准接口调用外部系统完成实际操作，包括数据写入、流程触发及结果回传。在这一阶段，智能体来了 被视为系统从“辅助认知”迈向“可执行认知”的标志性现象。

三、落地路径：拆解、增强与重组

在实践中，企业通常遵循一条相对稳定的引入路径。

原子化拆解 将复杂流程拆分为最小可执行单元，并区分为规则明确、半结构化与决策导向三类节点，分别由自动化系统、AI 模块与人工负责。

异步协同机制 改变同步指令模式，允许 AI 在后台持续处理数据准备与信息整合，并在关键节点触发人工确认，提高整体流程吞吐效率。

反馈闭环制度化 将人工修正与评价结果系统化沉淀，用于持续优化提示结构或模型微调，使 AI 对特定业务环境的适配能力不断增强。

四、组织价值层面的结构性变化

从系统视角看，工作流与 AI 的深度结合，使企业数字化能力从“流程在线”迈向“认知在线”。

行业共识正在形成：长期竞争力并不取决于模型数量，而取决于企业能否将推理能力系统性编排进核心业务流程中。在这一范式下，AI 已成为流程内部的认知单元，而非外部工具。
(本文章内容和图片由AI辅助生成）

MCP 是 API 和 AI agent 之间的桥梁，许多 AIGW 为此提供了根据 OpenAPI spec，将现存 API 转换成 MCP 的功能。然而大部分 AIGW 在实现该功能时并没有严格检查客户端的输入。某些输入不仅仅会触发网关的 bug，甚至可以直接攻击到后端服务。

MCP to RESTful API：漏洞的温床？

对 MCP 实现中的命令注入问题早已有人研究。

• 今年早些时候 mcp-package-docs 项目就爆过任意命令执行的高危漏洞：CVE-2025-54073。原因是开发者直接将客户端的输入拼接在 shell 命令里。
• 有人也发现许多 MCP server 有 SSRF 的风险。
• OWASP上也有一个 MCP Command injection 的专门页面

不过许多 MCP to RESTful API 的实现，还是难以避免的出现可供注入的漏洞。严格来说，它们并不是完全信任客户端的输入，多多少少有一些检查。但也许是因为 OpenAPI spec 和 HTTP 协议太复杂了，有些地方依然有着无人把守的缺口。接下来，让我带领大家游览一下这些缺口，看看有什么办法绕过高墙。

在评估安全性之前，有个前提：我们认为配置是可信的。毕竟如果用户把 host header 作为 header parameter 发布出去，那么攻击者可以通过它来设置任意 host header 就不是什么超出预期的事情。下面我们评估的漏洞，都严格假定攻击者无法操纵 OpenAPI spec 的内容。

潜在漏洞

MCP to RESTful API 转换通常是这样实现的：

1. 开发者通过 OpenAPI spec 或类似的 spec 定义参数的名称、类型和位置。
2. 网关将 spec 转换成 JSONschema，发布出去。
3. 客户端了解到对应的 schema，结合用户的上下文，生成对应的 JSON，发送给网关。
4. 网关拿到 JSON 后，根据 spec 转换成 HTTP 请求。

其中 HTTP 请求如下：

POST /path/$path_param?query_param=$query_param_value HTTP/1.1\r\n
Host: xxxx\r\n
Header_param: $header_param_value\r\n
Cookie: cookie_x;cookie_param=$cookie_param_value\r\n
\r\n
$body_param

网关在转换的时候，就是将 path_param 之类的参数，用客户端发过来的 JSON 里面对应字段替换。

高风险

这里面最大的风险是，客户端发过来的 param 里面有 \r\n，那么就可以构造出任意请求。比如设置 path_param 的值为 HTTP/1.1\r\n...\r\nDELETE /admin，则得到的请求如下：

POST /path/ HTTP/1.1\r\n
...\r\n
DELETE /admin?query_param=$query_param_value HTTP/1.1\r\n
Host: xxxx\r\n

同样在 header_param_value 里面发送 \r\n 也有类似的危害。

中风险

次一点的风险是，path_param 的值可以被设置成带 ../ 的，这样就可以是任意的路径。虽然没办法构造出不同的 method 和 header，但配合现有的接口（比如一个低权限的 DELETE /{user_id}/db/${db_id}），可以把它变成高权限的操作（比如 DELETE /admin/resources）。

在测试中，我发现有些 AIGW 会接受用户发过来的 JSON 里面所有的字段，哪怕这些字段没有在 spec 里面列出。这种问题会导致攻击者能够指定任意的 header，可以造成后端服务不可用（下文会说明如何操作）。

低风险

最后值得一提的是，不同位置的参数有不同的分隔符。如果 AIGW 没有检测这些分隔符，则攻击者也可以通过这种方式来注入额外的参数。尽管这种注入方式要比 header 位置的注入的危害小一些，但还算得上是一种风险。

• path 参数：/ | ?
• query 参数：&
• cookie 参数：;

实际支持 cookie 参数的 AIGW 很少，而且即使注入了额外的 cookie，也没什么危害，所以我没有测试各个 AIGW 对它的过滤情况。

测试结果

在阐述了 MCP 转 RESTful API 的潜在攻击面后，我们对几个支持此功能的知名开源项目进行了测试，以检验其是否存在上述问题。测试对象包括 Higress、AgentGateway、litellm 和 Unla。选择标准为：高知名度、开源、文档明确提及支持 MCP 转 RESTful API，且在同一技术栈下选取最具代表性的一个。鉴于存在安全风险的项目较为普遍，未测试的商业版产品未必更安全。

Higress

Higress 的技术栈是 Go Wasm （业务代码）+ Envoy （底层框架）。

高风险：

• Higress 调用了 url.Parse 来解析最终的 path，该函数会拒绝 \r\n。
• Envoy 在执行请求时会拒绝 header 里面的 \r\n 字符。

中风险：

• Envoy 在执行请求时会对含 /../ 的请求做 301 跳转，所以无法设置任意路径。
• Higress 的请求参数必须在配置中显式声明，无法插入未声明的 header

低风险：

• 没有检查 path 里面是否含有 / 和 ?。所以可以在 path 里面注入分界符，如把 DELETE /users/{user_id}/orders/{order_id} 变成 DELETE /users/1?c=/orders/2，或 GET /users/{user_id} 变成 GET /users/1/orders/2。当然也可以在里面插入任意的 query 参数。
• 同样没有检查 query 参数里面是否有 &。
• 顺便一提，如果参数值里面有 \0，比如
  curl -X POST http://localhost:8000/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_user","arguments":{"user_id":"ac","include_details":"a\0c"}}}'
  会触发某些 wasm 代码执行路径，导致跳过参数替换，比如 /users/{user_id} 变成 /users/。

结论：Higress 存在低风险。

披露情况：已向 Higress 报告（https://github.com/alibaba/higress/issues/3266），截至报告撰写时，该问题尚未得到修复。

AgentGateway

AgentGateway 的技术栈是 Rust。

高风险：

• AgentGateway 使用的 Rust 库会拒绝 path 里的 \r\n。
• header 里的 \r\n 同样会被拒绝。

中风险：

• 在执行请求时会对含 /../ 的请求做 301 跳转，所以无法设置任意路径。
• AgentGateway 会直接使用 tools/call arguments 里面的 {"header":{...}} 来构造最终发送给后端的请求，导致攻击者可以通过自己的 header 来覆盖由 agentgateway 设置的 header。比如使用自定义的 host 来覆盖 agentgateway 配置的 host。有一种攻击方向是通过设置一个较小的 Content-Type，将 body 从中间截断。如果 client 支持 HTTP1 pipeline，则截断的剩余部分会成为一个新的请求。不过，Rust 认为 HTTP1 pipeline 不安全，没有在 client 中支持，此路径无法利用。当然可以通过设置一个特别大的 Content-Type，迫使后端服务一直尝试读取直到超时为止。用这种方式可以快速消耗后端服务的连接数（通过 http2 可以做到在单条客户端连接不断发起请求，来持续消耗后端服务的连接），如果后端是传统的一个线程一个请求的 IO 模型，而且没有调整默认的单进程的最大线程数，可以打满后端的线程资源，造成后端不可用。

低风险：

• 没有检查 path 里面是否含有 / 和 ?。所以可以在 path 里面注入分界符，如把 DELETE /users/{user_id}/orders/{order_id} 变成 DELETE /users/1?c=/orders/2，或 GET /users/{user_id} 变成 GET /users/1/orders/2。当然也可以在里面插入任意的 query 参数。
• 同样没有检查 query 参数里面是否有 &。

结论：AgentGateway 存在中风险。

披露情况：已向 AgentGateway 报告，然而对方并不积极。截至报告撰写时，对方尚未告知是否修复了此问题。

litellm

litellm 的技术栈是 Python。

高风险：

• litellm 里用到的 Python 库 httpx 会拒绝 path 里的 \r\n：httpx.InvalidURL: Invalid non-printable ASCII character in URL, '\r' at position 26.
• litellm 只支持 path parameters 和 query parameters，tools/call 时不支持 header，所以不能测试这个。需指出的是，litellm 可以正常加载带 header parameters 的 OpenAPI spec，而且文档里也没有说不支持，甚至 tools/list 时也能列出 header parameters 的参数，但是实际上在代码里是没有写关于 header parameters 的实现的。我花了不少时间调试才发现了这一点。另外 litellm 没有做不同种类 parameters 的隔离，如果不同 parameters 间有同名的参数，比如 path var user_id 和 query var user_id，在加载 OpenAPI spec 时会报错。

中风险：

• 在执行请求时不会对含 /../ 做特殊处理，所以可以利用这个漏洞访问任意后端路径，如通过 ../admin 来访问 /admin 接口。
• litellm 会检查入参是否在配置中。它的检查在全部四个测试对象里是最严格的，甚至要求入参类型和配置的类型一致，而不是简单地做一个 to string 的转换。

低风险：

• 没有检查 path 里面是否含有 /。所以可以把 GET /users/{user_id} 变成 GET /users/1/orders/2。不过 litellm 有检查 ?。
• 无法通过 & 在 query 里注入额外参数。

结论：litellm 存在中风险。

披露情况：已向litellm报告，项目方已确认并修复：https://github.com/BerriAI/litellm/pull/18597。

Unla

Unla 的技术栈是 Go。

高风险：

• 会拒绝 path 中的 \r\n。
• 会拒绝 header 里面的 \r\n 字符。
  （注意当输入包含 \r\n 时，输出会是
  HTTP/1.1 202 Accepted
  Content-Type: text/plain; charset=utf-8
  Date: xxx
  Content-Length: 69

Acceptedevent: message
data: {"jsonrpc":"2.0","id":xx,"result":null}
这种混合了 200 和 202 HTTP 状态码的响应。估计触发了什么异常路径）

中风险：

• 在执行请求时不会对含 /../ 做特殊处理，所以可以利用这个漏洞访问任意后端路径，如通过 ../admin 来访问 /admin 接口。
• 请求参数必须在配置中显式声明，无法插入未声明的 header

低风险：

• 没有检查 path 里面是否含有 / 和 ?。所以可以在 path 里面注入分界符，如把 DELETE /users/{user_id}/orders/{order_id} 变成 DELETE /users/1?c=/orders/2，或 GET /users/{user_id} 变成 GET /users/1/orders/2。当然也可以在里面插入任意的 query 参数。
• query 中的 & 会被转义。

结论：Unla 存在中风险。
注意 Unla 如果不设置 responseBody template 则返回的响应为空。这样虽然用起来比较麻烦（不能直接使用返回的 JSON，必须配一个模板），但是避免了不少泄露敏感数据的风险，因为异常的响应无法在模板中渲染出来。不过这不能防治攻击者任意发起写请求（只要用户暴露了一个 DELETE 接口即可）。所以我还是维持中风险的评估。

披露情况：已向Unla报告，项目方已确认并修复。

我以前以为我懂 flexbox，于是给容器加个 display: flex，然后就祈祷布局如我所愿。

有时候确实有效，但大部分时候，我得到了一堆“各自为政”的列，完全不是我想要的样子。

直到我发现了这三个简单模式，一切都变了。

1. 核心问题：为什么布局总是乱？

你创建了 3 个完美的列，宽度相等，间距美观，你感到自己很帅。

然后你添加了一些内容——这里有一段长文字，那里有个短标题。

突然第 2 列变得巨大，第 3 列却瘦得像竹竿。

为什么？

因为 flexbox 默认会让内容决定布局。

但这种做法实际上在破坏你的设计！

2. 模式一：真正的等宽列

你想要实现真正的等宽列，该如何实现？

大多数人一开始会这样写：

/* 看起来很合理，对吧？ */
.column {
  width: 33.33%;
}

但如果你是 2 列、4 列、5 列呢？如果一个项目有内边距呢？

真正有效的解决方案是：

.even-columns {
  display: flex;
}

.even-columns > * {
  flex-basis: 100%;
}

就这么简单，两行代码搞定。

为什么要设置 flex-basis: 100%？

因为你在告诉每一列都保持相同的大小。

由于默认允许收缩，它们会等比例缩小来适应空间。它们会协调分配空间，而不是各自为政。

当你删除一列时，也没问题，剩余列会自动扩展填满空间。添加一列时，也是如此。

我经常用这个模式，导航菜单、功能卡片、团队成员介绍——任何需要列的地方都可以用。

3. 模式二：智能网格（告别媒体查询）

如果你想要一个能根据可用空间自动调整的网格，你该如何实现？

以前我们要写一堆的媒体查询，但我们可没时间搞这个了！

直接上我们的解决方案：

.gridish {
  display: flex;
  flex-wrap: wrap;
}

.gridish > * {
  flex: 1 1 15rem;
}

让我解释下这个设置：

• flex-wrap: wrap 的意思是：“如果空间不够，把项目换到下一行”
• flex: 1 1 15rem 的意思是：“我可以扩大，也允许收缩，理想大小是 15rem”
• 合起来就是：“尽可能保持 15rem 宽，但可以扩展填满空间或换行”

于是当你调整屏幕大小时，项目会自动流动。

三列变成两列，再变成一列，然后又变回三列。无需断点，无需媒体查询，智能布局。

我把这个用在博客布局上，每个文章卡片至少需要 15rem 才能好看。于是在宽屏上，显示四列。在平板上，显示两到三列。在手机上，堆叠显示，布局自动调整。

关键在于选择合适的 flex-basis 值。

太小了，移动端会有尴尬的超窄列。太大了，什么都并排不了。我通常从 15rem 开始，根据实际内容调整。

4. 模式三：内容-侧边栏保持黄金比例

现在我们实现一个典型的博客布局：

主体内容占大头，右边一个固定宽度的侧边栏。

大部分教程会让你用百分比或固定宽度。

但当屏幕变窄时，这两种方法都会失败——要不然内容变得不可读，要不然侧边栏变得非常窄。

其实你应该这样写：

.content-sidebar {
  display: flex;
  flex-wrap: wrap;
}

.main-content {
  flex: 1 1 70%;
  min-width: 25ch;
}

.sidebar {
  flex: 1 1 30%;
  min-width: 15ch;
}

关键在于 min-width。ch 单位代表字符宽度， 25ch 意思是“绝不小于 25 个字符”。

此时会发生什么呢？

• 宽屏幕： 70/30 分割，看起来很专业
• 中等屏幕： 仍然并排，调整比例
• 窄屏幕： 当任何一列达到最小宽度时，它们就堆叠

无需断点，布局会在内容需要时自然断裂。

5. 什么时候用这些模式？

模式一（等宽列）： 导航菜单、功能卡片——任何需要等宽列的地方

模式二（智能网格）： 博客布局、图片画廊、产品网格——任何需要内容自然流动的地方

模式三（内容侧边栏）： 文章布局、仪表板面板——任何需要主要和次要内容的地方

6. 思维转变

写 CSS 的时候，我经历过“改三行 CSS，刷新十次”的抓狂时刻。

后来我慢慢懂了一个道理：布局就像搭积木，你先决定“规则”，然后让它自己长成最合适的样子。

Flexbox 的魅力不在于“精准像素控制”，而在于“给出合理约束，剩下交给它”。

今天和你分享的这三个模式，保你在大多数业务页面里稳稳当当地交付。

等把它们用熟了，再去实现更复杂的响应式细节和组合策略，也会顺手很多。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

枫清科技以链主企业为切入点、以生态合作为抓手，在AI4S的应用与创新上的探索，在推动AI4S重塑科研创新的同时，也为中国AI4S的发展提供了一种新思路。

出品 | 常言道
作者 | 丁常彦

上世纪60年代，科学哲学家托马斯·库恩在其著作《科学革命的结构》中，就提出了具有里程碑意义的“科学范式”概念。如今，随着AI技术在科研中的深度应用，一种全新的科学研究范式——AI4S（AI for Science）正应运而生。

AI4S的崛起，已正式成为继经验、理论、计算和数据密集型之后的“第五范式”。AI4S所带来的不仅仅是数据处理工具的升级，也将重构科学发现的全流程，助力科研人员探索无限可能。2024年以来，美国通过行政令、政策文件及专项报告系统性提升AI4S战略地位；欧盟也在2025年发布了“人工智能大陆行动计划”，推动“科学+AI”交叉创新。

在这一趋势下，2025年8月国务院发布的《关于深入实施“人工智能+”行动的意见》更是将“人工智能+科学技术”列为重点行动之首。随着政策持续加码、技术不断突破以及商业化案例不断涌现，2026年已被行业视为AI4S加速落地之年。在此背景下，深势科技、枫清科技等一批创新企业正积极推动多学科智能协同，加速AI重构科学研究范式。

其中，枫清科技依托在AI4S科研平台建设与智能体技术研发方面的长期积累，不仅构建了以“通用智能体+场景智能体”为核心的双轮驱动科研赋能体系，还联合中化数智与火山引擎打造了覆盖多个科研核心阶段的AI4S解决方案，实现了从技术平台构建到生态合力凝聚的全面布局，走出一条融合创新的AI4S特色发展之路。

开启万亿级新蓝海，AI4S落地仍面临诸多挑战

2024年，谷歌DeepMind团队成员借助AlphaFold系列模型，将蛋白质结构预测周期从数十年缩短至数天，并凭借科研创新的重大突破成功拿下诺贝尔化学奖。这也成为AI4S发展的标志性事件。同样在这一年，英伟达创始人兼CEO黄仁勋也将大语言模型、具身智能、AI4S列为AI的三大关键方向。

当前，AI4S的价值已获得科研人员的充分肯定，随之而来的市场机遇正蓬勃兴起。据国盛证券的分析，AI4S远期将拥抱万亿市场蓝海，并将深入应用到医药、化工、新能源、合金、半导体等多个领域。以医药研发为例，AI4S有望将新药研发周期从平均10年缩短至2-3年，并大幅提升成功率。

中国工程院院士李国杰认为，未来10年内AI4S将不只是“科研辅助工具”，而是会逐步演变为科研的必要模式。AI4S的核心价值是将人类从低效的试错过程中解放出来，专注于创造性思维。未来科学发现将呈现“AI提出候选方案-人类判定科学意义-协同优化”的螺旋上升模式。

尽管AI4S在科研过程中已经展现出巨大潜力，但其规模化落地仍面临诸多难题。首先，高质量科学数据稀缺，制约了模型预测的准确性；其次，模型可解释性与科学可信度不足，导致其辅助科学研究时的结论缺乏可信度；第三，数据标准不统一，让研究成果难以实现规模化复制。

要攻克这些瓶颈，不仅需要技术上的持续创新，更有赖于能够整合数据、算法与行业知识的平台级解决方案。在这一领域，以枫清科技为代表的企业正通过构建新型基础设施，为AI4S的落地铺平道路。枫清科技打造的“云边端一体化” 的智能化架构、企业级知识中台与智能体平台，不仅可以实现云端大模型、行业蒸馏模型和PC端侧小模型的协同，也能实现云边端知识库的融合，以及多级智能体的协同，从而更好地满足科研人员的智能化需求。

在此基础上，枫清科技已经构建起完善的AI产品与应用矩阵，包括AI知识引擎、智能体平台、AI4S、Fabarta个人专属智能体等，可以满足众多行业场景智能化应用需求。如今，枫清科技正在帮助医药、新材料等行业开展科研创新，以及生物医药、先进制造、化工能源、金融保险等行业实现AI智能体的落地应用。

尤其在AI4S领域，枫清科技在帮助中化数智、华润医药等链主企业开展AI应用过程中，逐渐凝练出强大的智能体创新能力。比如，枫清科技通过与中化数智合作，已经在新材料研发的AI4S领域取得了创新突破，为后续向高校、科研机构和行业客户的复制推广奠定了坚实基础。

从科研效率到科研能力，用AI4S重塑科研未来

在传统科研模式下，科研人员主要面临试错成本高、研发周期长、效率低下‌等问题。比如，在新材料研发中，传统方式只能在有限的元素配比、工艺参数中摸索，耗费时间长；在药物研发中，靶点识别和分子筛选阶段，科研人员往往需要从数十万甚至上亿个分子中逐一验证。

而解决上述问题，正是AI4S的核心价值所在。为了加速AI4S的规模化落地，枫清科技决定将图技术与连接主义相融合，为AI4S构建坚实的技术底座。其中，图技术利用结构化且有序的数据关联，让沉默数据得以合理化释放价值，可以大大减少幻觉的产生；而连接主义通过数据训练，可以让模型拟合统计规律，输出近似最优的预测结果。

借助这些创新技术，枫清科技能够轻松从海量数据和文献中，提取出核心知识体系结构。与此同时，枫清科技还创新性地将知识图谱与图计算技术应用到模型蒸馏和后训练过程中，从而改善模型应用的可解释性弱、推理能力不足等问题，提升AI4S的核心能力。

依托在AI4S科研平台建设与智能体技术研发方面的长期积累，枫清科技已经构建起“通用智能体+场景智能体”双轮驱动的科研赋能体系，可覆盖从文献整理、知识挖掘到实验设计与执行的科研全流程，满足科研机构从智能科研辅助到深度研发参与的全链路AI4S需求，有效提升科研效率、降低试错成本，加速科研成果的转化。

其中，AI4S通用智能体主要聚焦科研活动中的高频共性场景，可实现文献智能处理、专利深度解析和科研报告生成，可系统性缓解科研人员在“信息过载”和“处理效率不足”方面的核心痛点，大幅提升论文检索的准确性和专业性，实现对论文内容的翻译、改写、问答等功能，全面提升科研人员的工作效率和使用体验。

AI4S场景智能体则聚焦化工新材料、生物医药等专业领域，通过“行业知识体系+智能体技术”的深度融合，解决复杂实验设计与科研任务执行中的关键难题。其中，在科研任务执行中，自动化高效完成数据分析，降低数据分析门槛、加快分析流程并提高结果准确性；在科研实验设计中，自动生成兼具专业性、可行性与创新性的实验方案，大幅缩短设计周期、提升设计质量；在科研任务执行中，通过串联并自动化执行既定科研步骤，提升任务执行效率、降低时间成本并优化最终成果。

从底层技术的选择到智能体的构建，枫清科技AI4S借助“智能体+工作流”的协同架构，以及大模型的语义理解能力与多模态处理技术，不仅可支持跨学科、跨领域科研文献与数据的深度解析，还能通过集成知识图谱可视化与分析组件，为科研人员提供高效、直观、可持续演进的智能化科研支撑。

凝聚产业生态合力，让AI4S成为科研创新引擎

AI4S的加速落地，既离不开产业链链主企业深厚的数据积累和丰富的业务场景，也离不开强大算力平台和完善工具链平台的有力支撑。因此，枫清科技在全力打造AI4S智能体的同时，也积极与链主企业和生态伙伴展开紧密协作，通过凝聚产业生态合力，为AI4S的创新发展和落地应用注入新动能。

2025年，枫清科技在推进AI4S落地应用上，聚焦新材料研发和生物医药两大热门领域，已取得突破性进展。其中，枫清科技通过与中国中化、中化数智为代表的新材料领域的链主企业，以及华润医药、东阿阿胶、华润三九等生物医药领域的链主企业深入合作，已经沉淀了多个产业与行业模型，以及AI4S智能体，为AI4S的推广奠定了坚实基础。

不久前，枫清科技与中化数智、火山引擎、吉林大学联合打造的“AI+新材料联合实验室”正式揭牌，其中，中化数智拥有丰富的数据积累，以及新材料研发的场景化需求；火山引擎可提供优秀的算力平台和领先的工具链平台；吉林大学则拥有众多国家级课题的研究成果。而枫清科技负责将各类能力沉淀为场景智能化能力，为产业链上的企业赋能。

为了将联合实验室的成果推广到更多企业，枫清科技还与火山引擎一道，共同打造了“北京市石景山区政府-AI for Science平台”及AI4S整体解决方案，并借助平台的力量凝聚更多产业链上的客户与企业，加速AI4S的普及。而AI4S整体解决方案则聚焦基础科研、科学实验辅助、数据挖掘、聚合物领域的智能体与科研蒸馏模型落地等，着力提升科研效率。

除了深度参与新材料研发外，枫清科技也在携手华润医药共同探索AI在创新抗体药物开发场景的应用。在此过程中，枫清科技借助大模型技术和企业知识中台产品，帮助华润医药将离散的数据转化为结构化知识图谱，实现了数据闭环，并实现了药物研发抗体数据的智能问数、智能检索和可视化，可显著提升研发效率、降低研发成本。

通过携手链主企业共建联合实验室，与生态伙伴打造AI4S平台与整体解决方案，枫清科技正在整合起数据、算力、科研成果等多方优势资源，沉淀出行业模型与智能体能力。这些能力的形成，不仅将推动AI4S在科研场景的落地应用与效能提升，也将为AI4S的普及推广营造完善的生态环境，让AI4S真正成为科研创新的核心引擎。

如今，越来越多的企业和科研机构已经意识到，AI对科研的赋能早已不只是提速、增效，而是体系化推动科研范式革命。作为科研领域AI的“杀手级”应用，AI4S的渗透才刚刚开始。随着AI4S成为科研的基础设施，科技创新的大爆发也将成为可以预见的未来。而枫清科技以链主企业为切入点、以生态合作为抓手，在AI4S的应用与创新上的探索，在推动AI4S重塑科研创新的同时，也为中国AI4S的发展提供了一种新思路。

在很多人的认知里，AI 的作用一直很明确：
写点文案、做张图、查点资料、提高一点效率。

它更像一个高级工具，需要人不断地下指令、点按钮、做选择。

在这种模式下，AI 的确改变了一些工作方式，但并没有真正改变行业结构。

近一两年，一个新的变化正在悄悄发生：
AI 不再只是被动等待指令，而是开始自己跑流程。

这类 AI 被称为智能体。

它们具备几个明显特征：

• 有明确目标
• 能把任务拆成步骤
• 能持续执行
• 能记录进度
• 能根据结果调整行为

这意味着，AI 开始“干活”，而不仅是“回答”。

传统行业的工作逻辑是：

人判断 → 人操作 → 系统记录 → 人再判断

而当智能体进入流程后，逻辑变成了：

系统执行 → 系统记录 → 系统反馈 → 人只做决策

变化的核心不在于速度，而在于：
执行权开始从人转移到系统。

一旦执行权发生转移，行业的运行方式就会随之改变。

选题、生成、发布、复盘，正在被整合为自动运行的流程。
人更多负责方向判断，而不是重复创作。

排产、监控、异常预警逐步由系统持续运行，经验正在被算法替代。

统计、汇总、跟进、提醒等工作，正在被自动化代理接管。

软件不再只是“给人用”，而是开始自己运行流程。

很多讨论把智能体理解为“取代人”，这是一个误解。

更准确的说法是：

• 人从执行层退出
• 系统进入执行层
• 人转向判断与决策

行业并不是少了人，而是重新分工。

随着智能体进入真实业务，行业正在出现明显分化：

• 一部分企业已经把智能体嵌入流程
• 另一部分仍停留在人工驱动阶段

差距不再来自努力程度，而是来自系统是否存在。

未来的核心竞争力，正在从：

谁更勤奋、谁更熟练

转向：

谁能设计和使用系统

拥有智能体系统的人，能力会被持续放大；
没有系统的人，只能线性增长。

智能体对传统行业的冲击，不会以“爆炸式”的方式出现。

它更像是一种悄然发生的变化：
当你意识到规则变了，系统已经跑了一段时间。

AI 不再只是工具，
而是正在成为行业运行的一部分。

很多组织并不缺流程，缺的是“能对齐、能验收、能追责”的协作机制。本文以端到端交付为主线，给出一套更适配中国企业的闭环做法，回答“产品、研发、测试怎么协作”这一管理难题。

本文主要内容索引：

• 核心关键词：产品、研发、测试怎么协作｜需求评审｜验收标准｜持续集成（CI）｜测试左移｜发布就绪｜复盘改进
• 相关长尾问题：需求评审会怎么开？DoR/DoD是什么？测试左移怎么落地？缺陷争议怎么裁决？DORA指标怎么看？
• 本文交付物：五道门（Gate）协作框架｜一页纸需求合同模板｜缺陷证据模板｜Release DoD清单｜90天落地路线图
• 工具落地：如果你使用类似 ONES 这类一体化研发管理平台，可将“需求—任务—缺陷—测试—流水线—度量”放在同一事实源中，减少口径不一致带来的摩擦。

你以为在协作，其实在“接力赛式甩锅”

在不少企业里，“产品—研发—测试”的协作看似忙碌，实则像接力赛：每一棒都在努力跑，但交接区混乱，最终成绩不可能好。

• 产品说：我写了 PRD，为什么做出来不是我想要的？
• 研发说：需求边界不清、验收标准模糊，我只能凭经验猜。
• 测试说：版本到我这里已经很晚了，我只能“发现问题”，但来不及“预防问题”。

如果把它仅仅归因于沟通不足，就会走向错误解法：更多会议、更长文档、更强催促。真正的根因往往是治理缺口：

• 契约缺失：需求没有形成“共同可执行合同”；
• 反馈过慢：集成与验证周期太长，错误在后期爆炸；
• 责任边界不清：质量被默认为“测试负责”，研发缺少质量闸门；
• 决策机制薄弱：进度与质量冲突时，缺少可量化的权衡依据。

组织层面的协作问题，通常不是“态度问题”，而是“系统缺口”。你要做的是把协作从“靠默契”升级为“靠机制”。

一个可落地的“端到端协作闭环”框架

我建议用“五道门（Gate）”来组织协作：每道门都要回答三件事——产出是什么、谁负责、如何验收。这种“门”的治理方式，天然适合中国企业的复杂现实：跨部门考核、外包/多供应商、审批链条长、并行项目多。

术语速查：

• DoR（Definition of Ready）：进入迭代的“就绪标准”——不求完美，但要可估、可测、可切片。
• DoD（Definition of Done）：完成的共同标准——不只是“开发做完”，还包括质量与可交付性。
• Release DoD：发布就绪标准——把上线从“拍脑袋”变为“可控发布”。
• CI（Continuous Integration）：频繁把变更集成到共享主线，并用自动化尽早暴露集成问题。

落地实践：如果你希望“门”不仅停留在制度层，而能沉淀为可复用资产，建议把每道门的产出物固化为模板+工作流+关联关系：例如在 ONES Project 里用需求池、迭代、缺陷等工作项承载过程，并把测试用例、流水线信息与迭代关联起来，减少“口头交接”。

本章要点：Gate 不是为了管人，而是为了降低跨角色协作的不确定性，让“产品、研发、测试怎么协作”变成一套可验收的链条。

需求评审：把“需求”变成“可交付的合同”

1.把歧义消灭在源头

很多团队的需求评审，本质是产品宣讲会：研发与测试“听完再说”。但“听懂”不等于“对齐”。Three Amigos 的价值在于：用业务/开发/测试三种视角共同检视同一增量，把歧义留在会上解决，而不是留到上线前爆炸。

30分钟会议模板（短，但必须产出证据）

• 产品讲“为什么”：用户是谁、要解决什么问题、成功标准是什么；
• 研发讲“怎么做”：实现路径、依赖、风险、如何切片；
• 测试讲“怎么证明”：主流程、异常路径、数据准备、回归范围；
• 当场固化三件证据：验收标准（可执行）、范围边界（做/不做）、风险与依赖（专项评审项）。

落地实践：评审会的价值不在“说清楚”，而在“写清楚并可追溯”。实践中，你可以把“一页纸需求合同”沉淀为标准字段与模板：例如 ONES Project 支持建立需求池、编写需求、定义需求状态与属性，并将需求与任务规划到迭代里，便于后续追踪“评审承诺是否兑现”。

2. DoR + 验收标准：让需求“可测试、可估算、可切片”

DoR 不应被做成厚文档，它的任务很明确：把“模糊成本”前置。对中国企业尤其关键——因为人员流动、跨团队依赖，会把口头默契迅速稀释。

DoR 最小清单（建议直接贴到评审模板）

• 业务价值一句话讲清（不清就不急着做）
• 范围边界明确：做什么/不做什么
• 依赖识别：系统、数据、权限、外部团队/外包交付物
• 验收标准可执行：主流程 + 关键异常（至少三条）
• 可切片：单片 1~2 周能交付并演示
• 风险分级：性能/安全/合规是否触发专项评审

验收标准推荐写法：Gherkin（Given-When-Then）：它把自然语言变成结构化约束，让产品能确认、研发能实现、测试能直接转用例。示例：

• Given 用户已登录且具备A权限
• When 提交B类型申请并上传C材料
• Then 系统生成单据进入“待审批”，并通知审批人，且操作记录可追溯

一页纸：需求合同模板（可复制）

• 目标用户/场景：
• 业务价值（量化更好）：
• 范围边界（做/不做）：
• 验收标准（3~7条）：
• 依赖与风险（含触发专项评审项）：
• 切片方案（先交付哪一片价值）：

落地实践（文档与工作项不要分家）：很多组织的“评审资料在文档里、执行在工单里”，时间一长必然脱节。更稳妥的做法是：让文档与工作项天然互相引用——比如用 ONES Wiki 沉淀评审纪要/边界说明，并把文档关联到项目任务；在执行层面直接引用对应需求与验收标准，减少“版本漂移”。

本章要点：需求评审真正的产出不是会议纪要，而是“可执行合同”（验收标准 + 边界 + 风险）。

开发过程：用“小批量 + 持续集成”降低返工

1. 先学会“切片交付”：按用户价值切，不按组织分工切

返工最贵的，不是改代码本身，而是改“已经被多人理解过的错误”。因此切片的原则是：每一片都能被演示、被验证、必要时能被回滚。

• 按用户旅程/业务价值切：先跑通主链路，再补边角；
• 不按职能切：别把风险推到“最后一周再联调/再测试”；
• 每片都带最小验收标准与最小测试点。

管理者一句话抓手：不要问“做了多少功能”，要问“本周能演示哪一片价值？验收标准是什么？”

2. 持续集成（CI）与主干策略：把“集成地狱”变成日常习惯

CI 的核心实践是：频繁把变更集成到共享主线，并用自动化构建与测试尽早发现集成问题，从而降低后期集成成本。

在“长分支+晚合并”的组织里，CI 往往只能发挥一半价值：流水线跑得很勤，但风险仍被积压到后期。

更现实的落地方式（不和审批文化硬碰硬）

• 评审不取消，但要求“小批量合并”：把每次合并当作一次小发布；
• 对“未完成但需要合入”的功能，用特性开关/配置隔离；
• 把“主干可部署”写进 DoD/Release DoD：不满足就不算完成。

落地实践：很多管理者看得到“任务状态”，却看不到“工程信号”（构建是否绿、合并是否频繁、版本是否可交付）。在工具层面，可以把流水线与迭代绑定：例如 ONES Pipeline 支持集成 Jenkins，同步流水线执行状态，并将流水线与项目/迭代关联；同时支持关联代码提交、分支合并与工作项，让研发过程更透明可视。
本章要点：切片解决“看得见”，CI 解决“早发现”。两者合在一起，协作才真正开始变轻。

测试左移：质量不是“测试的阶段”，而是“研发的习惯”

1. 左移的本质：把反馈提前，把成本压低

测试左移（Shift-left testing）的核心思想是：把测试活动尽可能前移，让团队更早获得质量反馈，减少末端返工。在企业里，我更喜欢把它拆成三层，便于推进：

• 需求左移：评审门写清验收标准与关键场景；
• 开发左移：开发自测/单元测试进入 DoD；
• 流水线左移：自动化校验前置到合并请求/构建阶段。

2. 测试金字塔：自动化投入要有结构，不要“倒金字塔”

自动化失败常见原因是结构不对：端到端 UI 脚本堆太多，维护成本高、反馈慢、稳定性差。更稳妥的是测试金字塔：底层更多单元/服务级测试，顶层少量端到端。

落地建议（可直接写进DoD）

• 单元测试覆盖关键规则与边界；
• 服务/API 级自动化覆盖主链路与关键异常；
• 端到端只保留“业务生命线”（下单/审批/支付等）少量用例；
• 合并必须通过流水线（不过不合）。

3. 缺陷闭环：用“证据驱动”替代“情绪对抗”

缺陷争执往往不是技术问题，而是“证据不足 + 风险无人裁决”。要把争议从“声音大小”拉回“标准与证据”。

一页纸：缺陷证据模板（建议固化）

• 环境/版本/时间：
• 复现数据（可脱敏）：
• 复现步骤（1~N）：
• 期望结果 vs 实际结果：
• 日志/截图/链路证据：
• 影响面与可绕过性：

配套机制（建议PMO推动）

• 严重度分级标准（影响面、可绕过性、是否阻断上线）；
• 修复时限承诺（P0/P1 响应时限）；
• 仲裁机制：争议由发布负责人/质量 Owner 在 24 小时内按“证据+发布标准”裁决。

落地实践（让测试真正“左移”，而不是“更早更忙”）：左移落地最怕两件事：一是测试用例散落在表格里，二是缺陷与需求/迭代断链。比如 ONES TestCase 支持用例与需求、任务关联，测试计划与迭代关联；用例不通过时可快速创建缺陷，并在研发与测试之间流转，同时还能自动生成测试报告与质量统计。

本章要点：左移不是让测试更早加班，而是让全链路更早获得可验证反馈；缺陷闭环的关键不是流程，而是证据与裁决。

上线与复盘：让“速度”和“稳定性”在同一张表上对话

1. 发布就绪：把DoD升级为“Release DoD”

很多团队的“完成”不等于“可发布”。真正可发布，必须回答：是否可控、可观测、可回滚。对中高层来说，Release DoD 是你把“交付风险”从个人经验变为组织标准的抓手。

Release DoD（发布就绪清单｜升级版）

• 回归范围明确，关键链路自动化通过；
• 变更影响评估完成（依赖、数据、权限、兼容性）；
• 灰度策略与观察指标明确（看什么、看多久、阈值多少）；
• 回滚方案可执行，并在预发演练过；
• 上线窗口、值守与升级链路明确（谁拍板、谁响应）。

落地实践（把“发布就绪”变成可追溯证据）：发布就绪最怕“口头确认”。实践中可以把发布清单绑定到迭代或版本：例如在 ONES Project 里用迭代承载版本范围，缺陷与测试数据互通；在 ONES Pipeline 里关联迭代流水线执行信息，便于在同一处回看“版本是否达到发布门槛”。

2. 用 DORA 指标衡量闭环，而不是用“加班时长”衡量努力

DORA 指标把“交付吞吐”与“交付稳定性”放在一起讨论，帮助管理层用数据做权衡。对强合规/非互联网组织，我建议先盯两项：

• 变更前置时间（Lead time）：从提交到可用的周期；
• 变更失败率（Change failure rate）：回滚/紧急修复比例。

把“快与稳”放到同一张表上，争论就会明显减少。

落地实践（让指标成为“共同语言”）：指标体系落地的关键不是“选什么指标”，而是“数据是否可信、是否可复用”。如果你希望把交付效率、交付质量、进度与资源效率等数据做成可持续的管理例会输入，可以参考 ONES 的研发效能管理方案：强调对多项目、多团队、多流程效能数据的统一展示与“量化—实施—分析—改进”的闭环。

3. 错误预算：用“规则”平衡创新与可靠性

错误预算（Error Budget）的思路，是用规则管理可靠性投入：当预算消耗过快，就暂停新功能发布，优先还质量债。这个机制能把“冻结发布”从拍脑袋变成有据可依。

本章要点：Release DoD 管住上线风险，DORA 让你看见系统性问题，错误预算让你在冲突时有规则可依。

中高层怎么介入：从“审批者”变成“机制设计者”

让“产品、研发、测试怎么协作”跑起来，PMO 与管理层最有价值的贡献不是替团队做决定，而是把“决策条件”建好——让协作可追踪、可验收、可改进。

建议你们把角色从“监督者”升级为三类机制设计者：

• 标准设计者：统一 DoR/DoD/Release DoD（轻量但刚性）；
• 透明度建设者：需求—任务—缺陷—发布在同一事实源可追溯；
• 例外管理者：进度与质量冲突时，按风险与指标裁决，而不是按情绪裁决。

落地实践（面向管理层的“全局视图”）：当组织进入多项目并行阶段，PMO最需要的是“跨项目的节奏与资源视角”。例如 ONES Plan 提供多项目总览、里程碑/甘特图与资源报表，并与 ONES Project 数据互通；更适合在“产品线—项目—迭代”层面做全局协调，而不是陷入单项目细节。

本章要点：你管的是系统，不是人。系统对了，人才能稳定发挥。

90天落地路线图（务实版）

不大动组织结构也能推进闭环，关键是：试点、固化模板、把闸门变成默认。

0~2周：把“需求评审门”立起来（PMO牵头）

• 固化 Three Amigos 模板与 DoR 最小清单；
• 试点 1 个产品线：进入迭代的需求必须带验收标准；
• 成功标志：评审后口径争议减少、迭代中途返工下降。
• （可选工具动作）在 ONES Project 建立统一的需求模板与字段，并要求需求与迭代/任务建立关联，先把“事实源”立住。

3~6周：把“集成构建门/质量闸门”跑起来（研发负责人牵头）

• CI 闸门上线：构建+单测+最小冒烟不过不合并；
• 推行小批量合并与主干策略（从核心仓库开始）；
• 成功标志：集成问题从“上线前爆发”变为“每天可见可控”。
• （可选工具动作）用 ONES Pipeline 关联迭代与流水线执行状态，形成“迭代推进—工程信号”的同屏视图。

7~12周：把“发布就绪门/复盘门”固化（发布负责人/质量Owner牵头）

• Release DoD 上线；灰度+回滚演练成为默认；
• 建立 DORA 看板，优先盯 Lead time 与 Change failure rate；
• 两周一次复盘：Top3问题必须转为机制改进项（有人负责、有截止日期）。
• （可选工具动作）用 ONES TestCase 把“用例—测试计划—缺陷”与迭代打通，复盘时基于测试报告/缺陷分布更容易做证据化讨论；用 ONES Performance 做跨项目趋势看板，避免复盘停留在个案。

本章要点：90 天的目标不是“变先进”，而是让协作从混乱走向可控，并能持续改进。

协作的本质，是让组织用同一套语言做决策

当组织缺少共同语言时，协作只能靠人品与默契；当组织拥有共同标准时，协作才能靠系统运转。“产品、研发、测试怎么协作”的本质不是多开会，也不是写更多文档，而是把关键节点的契约（验收标准）、反馈（切片+CI）、标准（Release DoD）、改进（指标+复盘）串成闭环。

你最终会得到三种长期收益：

• 交付节奏更稳：不是靠加班堆出来，而是靠小步快跑跑出来；
• 质量更可控：不是测试末端拦截，而是全链路共同负责；
• 决策更有依据：速度与稳定性不再靠争论，而是靠指标与规则对齐。

现实一点说：方法论解决“该怎么做”，工具解决“能不能持续做”。当流程、模板、数据在同一处沉淀（例如 ONES Project/ TestCase / Pipeline / Performance 这类端到端组合），协作往往更容易从“靠人推动”变成“靠系统自运行”。

一、AI 智能体正在从工具走向系统组件

在早期工程实践中，AI 更多以工具形态存在，用于文本生成、代码补全或单点决策。这类应用虽然提升效率，但并未进入业务核心流程。

随着 AI 智能体（AI Agent）概念逐渐清晰，AI 的角色开始发生变化：
​从被调用的工具，转变为可以长期运行的系统组件​。

当 AI 具备目标管理、任务拆解、状态记录和自动执行能力时，它开始真正参与系统运行。

二、为什么多数 Agent 项目停留在 0 阶段

在实际工程中，大量智能体项目无法从 Demo 走向生产，主要原因并不在模型能力，而在系统设计层面。

常见问题包括：

• 将智能体等同于模型调用
• 缺乏明确的可执行任务定义
• 没有状态管理机制
• 无法处理失败与异常
• 系统无法长期运行

如果 AI 只能被人工触发，无法形成闭环运行，那么它本质上仍然是工具，而不是智能体系统。

三、从 0 到 1 的关键起点：定义可执行任务

实现一个可运行的 Agent 系统，第一步不是选择模型，而是​定义任务本身是否可执行​。

可落地的任务通常具备以下特征：

• 触发条件清晰
• 完成标准明确
• 可以拆解为步骤
• 结果可以被系统验证

例如：在固定时间获取数据、生成结果、写入系统并记录状态。这类任务才能支撑智能体持续运行。

四、最小可运行 Agent 系统的工程结构

从工程视角看，一个最小可运行的 AI 智能体系统通常包含五个核心模块：

1. 任务模块

用于定义目标、触发条件和完成标准。

2. 规划模块

将任务拆解为一系列可执行步骤。

3. 执行模块

负责调用接口、工具或业务系统完成操作。

4. 状态模块

用于保存执行进度、上下文信息和历史结果。

5. 反馈模块

根据执行结果判断是否继续、重试或终止。

这五个模块构成一个闭环，决定了 Agent 是否具备持续运行能力。

五、从“调用 AI”到“运行系统”的本质变化

智能体从 0 到 1 的本质变化，并不是模型能力提升，而是系统能力的建立，包括：

• 任务可以自动触发
• 执行流程可以自动推进
• 状态可以被持续保存
• 异常可以被识别并处理

当 AI 可以在无人工干预的情况下完成完整流程时，Agent 系统才真正成立。

六、工程实践中必须重视的稳定性问题

在生产环境中，智能体系统面临的挑战主要集中在稳定性和可控性：

• 状态丢失会导致系统无法恢复
• 缺乏异常处理会导致流程中断
• 没有监控机制会放大风险
• 缺乏边界控制会影响业务安全

因此，AI 智能体必须被视为​长期运行的系统服务​，而不是一次性功能模块。

七、Agent 系统从 0 到 1 的实际价值

当智能体系统真正跑起来后，其价值不仅体现在效率提升上，更体现在：

• 人从重复执行中解放
• 系统可以持续运行
• 业务流程具备可复制性
• 团队和个人能力被系统放大

这也是为什么 AI 智能体更像是系统升级，而非功能增强。

八、结语：智能体是系统能力的体现

AI 智能体并不是概念性的未来技术，而是正在落地的工程实践。

从 0 到 1 的难点，不在模型选择，而在是否具备系统化设计能力。

当 AI 能作为系统的一部分长期运行时，它才真正改变了工程与业务的运行方式。