夜雨聆风性能测试做久了，会发现最费人的往往不是把脚本跑起来，而是把一堆业务描述、监控曲线、日志、数据库现象和历史经验放在一起，判断系统到底卡在哪里。
一、性能测试的难处，不只在工具
很多团队刚开始做性能测试时，会先盯着工具：JMeter 线程组怎么配，Locust 脚本怎么写，Grafana 曲线怎么看，Prometheus 指标怎么查。
这些都要会。但真正进到企业项目里，工具只是起点。
一次响应时间抖动，可能是数据库慢 SQL，也可能是连接池耗尽、JVM GC、网关限流、缓存击穿、下游服务超时，甚至是业务模型本身带来的热点数据。一个 TPS 数字背后，往往连着业务峰值、架构约束、环境差异、容量上限和故障影响面。
7DGroup 长期做性能工程、非功能体系、性能分析优化、容量规划管理、测试开发、智能运维和 AI 工程化实践，接触最多的也正是这类问题。客户不是只想知道“压测有没有跑完”，而是想知道：
当前系统还能撑多久？ 瓶颈到底在应用、数据库、中间件，还是下游依赖？ 这次问题会不会在下个峰值再次出现？ 如果要扩容，扩哪里才有效？ 这次经验下次能不能别重新摸一遍？
金融、电力、互联网等行业场景里，这些问题会更加具体。
金融系统关心核心交易链路、账务一致性、批量窗口、峰值容量和灾备切换影响；电力系统关心采集链路、调度业务、设备接入规模、数据上送周期和长期稳定运行；互联网系统关心活动峰值、高并发访问、缓存与消息队列、弹性扩缩容和用户体验波动。
这几年还有一个更明显的变化：很多企业核心系统都在经历国产化和信创适配。操作系统、CPU、数据库、中间件、容器平台、监控组件都可能换一遍，原来在 x86、MySQL、传统中间件或既有云平台上的性能经验，不能简单平移到新的技术栈上。功能能跑通，只能说明流程可用；非功能能力有没有退化，容量模型有没有变化，灾备和运维操作有没有新的风险，还需要重新验证。
还有一类问题正在变得更近：AI 应用本身也需要性能和非功能保障。一个看起来只是“问答慢”的问题，背后可能牵着模型调用、RAG 检索、Agent 工作流、工具调用、上下文窗口、供应商限流、成本预算、降级策略、稳定性和可观测性。传统系统的压测经验能帮上忙，但不能完全覆盖这类新链路。
所以我们越来越觉得，性能测试不是“压出一个数”，而是要把数字背后的业务含义、瓶颈证据和容量风险讲清楚。
二、真正卡住团队的，是性能分析
写方案、写脚本、整理报告都很花时间，但这些事情大多还能靠模板和熟练度往前推。性能分析不一样。
它吃经验，也吃上下文。
性能需求经常藏在业务语言里
企业需求文档里很少直接列一张“性能需求清单”。更多时候，性能目标藏在业务规则、交易峰值、批量窗口、SLA、用户体验描述和历史故障背景里。
比如“日终批量必须在 2 小时内完成”“活动开始后 10 分钟内订单创建不能明显排队”“采集数据需要按分钟级上送并入库”，这些句子不一定写着 QPS、P99 或资源水位，但都决定了测试目标。
只靠关键词，很容易漏；只靠人工，又很依赖读文档的人有没有做过类似系统。
场景设计不是接口排列组合
很多压测失败，不是脚本写错，而是场景一开始就设计偏了。
场景设计要理解业务流量、关键链路、峰谷分布、数据规模、环境差异、上下游依赖和失败影响范围。金融系统里一条核心交易链路，电力系统里一条采集告警链路，互联网系统里一次大促下单链路，看起来都是接口调用，风险完全不一样。
这些判断很难从一份接口文档里长出来。它需要行业案例、历史项目、架构经验和非功能方法论一起支撑。
国产化改造里的非功能经验更稀缺
国产化和信创适配项目里，非功能测试经常被低估。
很多项目会先把注意力放在功能兼容上：页面能不能打开，接口能不能返回，批量能不能跑完，报表能不能生成。等到压测或试运行阶段，才发现真正麻烦的是另一组问题：
原数据库迁移到国产数据库后，SQL 执行计划、锁行为、索引策略和批量写入能力都变了。 原中间件替换后，连接池、线程池、序列化、超时重试和消息堆积的表现不一样。 原服务器架构切到国产 CPU 或新操作系统后，单核性能、I/O、网络栈、加解密开销都需要重新评估。 原来的监控指标、告警阈值和容量基线不一定还能直接沿用。 原团队熟悉的是旧技术栈，新的瓶颈特征和调优手段还没有形成稳定经验。
这类项目最怕“功能适配完成”被误当成“系统可以稳定承载”。非功能测试经验不足，会直接影响容量评估、上线窗口、回退方案和生产稳定性。
AI 应用的性能和非功能经验也在缺位
AI 应用落地以后，很多团队会先关注效果：回答准不准，流程能不能跑通，工具调用能不能完成。但真要进入企业场景，性能和非功能问题很快就会冒出来。
一次响应慢，可能不是某个接口慢，而是检索召回、重排、模型推理、上下文拼装、Agent 多轮决策和外部工具调用叠在一起变慢。一次成本异常，可能来自上下文过长、重复检索、无效重试或 Agent 循环。一次稳定性问题，也可能不是服务不可用，而是模型限流、输出不稳定、下游工具超时、降级策略缺失或可观测性不够。
这块经验现在还没有像传统 Web、数据库、中间件那样形成足够多的稳定笔记。很多团队知道怎么测 TPS、P99 和资源水位，却缺少 AI 应用链路的延迟拆解、容量估算、异常退化、成本评估和稳定性验证经验。AI-7D-SATS 后续要解决的，也包括这部分新型性能工程和非功能保障问题：先把问题拆清楚，把证据留住，把可复用经验沉淀下来。
瓶颈定位要跨层看证据
同样是 CPU 95%，资深工程师不会只写“CPU 使用率高”。他会继续追：
是用户态计算高，还是内核态、上下文切换异常？ 是业务代码热点、序列化、加解密开销，还是 GC 频繁？ 数据库有没有慢 SQL、锁等待、连接池排队或 I/O 抖动？ 下游依赖有没有把响应时间放大？ 当前瓶颈会不会影响扩容效率和容量上限？
性能分析难，就难在它不是单点指标解释。它要把监控、日志、链路、配置、代码、数据库、基础设施和业务过程串成一条证据链。
经验很容易停在个人脑子里
每个项目结束后，团队都会说“这次经验下次要用上”。但真到下一次，常见情况还是：
报告存在网盘里，找相似案例很慢。 复盘文档写了根因，但关键词、指标口径和瓶颈分类不统一。 调优过程散在聊天记录、会议纪要、SQL 片段和监控截图里。 新人会用工具，却不知道异常指标出现后先看哪里。
经验如果不能被检索、复用和审查，就只能跟着资深工程师走。团队做过很多项目，但下一次遇到类似问题，还是从头找线索。
三、AI-7D-SATS 想接住的，是 7DGroup 这部分经验
我们做 AI-7D-SATS，不是想让 AI 去替人“自动压测”。压测启动、权限判断、生产目标访问、数据库写入、报告发布，这些都必须在受控 Workflow、审批和审计链路里。
我们更想解决的是另一个问题：7DGroup 过去在金融、电力、互联网等行业的项目里沉淀下来的方法论、案例和分析经验，能不能变成性能工程师随手可查、可复用、可追溯的智能工作助手？
这些经验不是只来自项目复盘。7DGroup 还持续输出过《全链路压测实战30讲（落地实操）》《性能测试实战30讲（入门到精通）》《高楼的性能工程实战课（架构级）》等专栏课程体系，也通过公众号和技术博客多年输出几百篇性能工程、安全、压测、分析优化、智能运维相关文章，以及几百到上千次企业内训、公开课、个人培训和咨询辅导，把一线问题反复拆开讲、反复验证。
这里说的专业数据支撑，不是某个单一数据库产品。更准确地说，它是一组知识底座：专家经验、课程体系、文章体系、培训案例、项目复盘、行业案例库、指标知识库、性能分析经验库、容量样本、调优证据、国产化适配记录、AI 应用性能与非功能经验笔记和复盘材料。不同领域、不同技术栈的数据形态、链路模式和瓶颈特征差别很大，系统需要把这些差异保留下来，而不是压成几句泛泛的建议。
7DGroup 的方法论可以给 AI-7D-SATS 提供一条比较稳的骨架。
SATS 非功能体系提醒我们，性能问题往往不只是性能问题。它可能牵动可用性、扩展性、灾备、可靠性、兼容性、安全、可维护性、可操作性和易用性。一个接口慢，不一定只是代码慢，也可能意味着容量风险、灾备窗口风险或运维复杂度上升。
RESAR 性能工程体系则把性能工作拆成更容易治理的阶段：性能需求、性能环境、性能场景、性能分析、性能报告和容量环比。AI-7D-SATS 可以在这些阶段提供草稿和分析线索，但不能替代人做最终判断。
性能分析七步法、性能分析决策树和容量预测模型，则更适合放在“分析助手”的核心位置。它们能让系统在看到指标和日志后，不是直接甩出一个结论，而是提示下一步该查什么、哪些证据支持当前假设、哪些反证还没排除、容量预测建立在哪些前提上。
这才是我们认为 AI 值得介入的地方：把经验组织起来，让判断过程更清楚。
四、第一阶段先做几件实在的事
AI-7D-SATS 不需要一上来就覆盖性能测试全流程。第一阶段更应该盯住几个真正耗时间、又能被方法论约束住的环节。
1. 从材料里捞出性能需求
PRD、接口文档、架构说明和会议纪要里，经常散着性能目标、业务峰值、批量窗口和稳定性约束。
系统先把这些内容整理成待确认清单，性能负责人再补充和校正。这样能减少漏项，也能让需求评审更有依据。
2. 给场景设计一个行业参照
面对金融、电力、互联网等行业不同类型的系统，场景设计不能只靠接口列表。系统可以根据典型链路和历史案例，先给出场景矩阵、流量比例、峰值模型和风险覆盖点。
工程师不必从空白页开始，而是从一份带行业参照的草稿开始判断。
国产化适配项目也一样。系统应该能提醒工程师关注数据库迁移后的 SQL 计划变化、国产 CPU 下的单机容量变化、中间件替换后的连接池和线程池表现，以及监控阈值是否需要重建，而不是只检查功能链路是否跑通。
AI 应用项目也一样。第一阶段不必急着承诺完整治理，可以先沉淀性能分析检查清单、指标解释、容量预测候选和非功能风险提示：一次请求慢在哪里，RAG 检索耗时占多少，Agent 多轮决策有没有放大延迟，模型限流和工具超时有没有降级方案，成本和稳定性有没有被纳入容量讨论。
3. 减少脚本和报告里的重复搬运
脚本草稿、参数化模板、断言规则、报告结构、指标摘要，这些工作很多都是格式转换和信息整理。
AI-7D-SATS 可以先生成可编辑草稿。工程师把时间放在校验逻辑、确认风险和分析问题上，而不是反复搬字段、贴截图、补表格。
4. 把性能分析经验变成团队能力
这是我们最看重的一点。
系统需要把行业知识库、专业案例库和性能分析经验库组织起来。一个新问题进来后，能快速找到相似瓶颈、相似指标模式、相似调优路径和相似容量风险。
它不应该给“唯一答案”，而应该给带证据、反证、置信度和下一步建议的根因假设。工程师沿着这些线索继续验证，而不是从空白开始。
5. 让容量规划有依据可讲
容量规划不是把当前 TPS 乘一个增长倍数。它要看业务增长、峰值形态、环境差异、资源利用率、瓶颈点、扩容效率和风险缓冲。
AI-7D-SATS 可以基于历史压测、容量环比和业务增长假设，生成容量预测候选，并说明适用范围和限制条件。最后怎么承诺容量、怎么扩容、预算怎么排，仍然要由人和组织流程确认。
五、边界一定要写清楚
AI-7D-SATS 的定位，是性能测试工程师、性能工程师、测试开发、运维/SRE、架构师和技术管理者的工作搭档。
它不是替代品。
确定性治理要交给 Workflow Control Plane。身份认证、权限校验、环境准入、目标校验、风险等级、执行审批、任务状态、压测执行控制、监控采集、审计记录和回滚机制，都要由代码、服务、DispatchGate、RBAC、人工检查点和审计流程控制。
专业判断辅助可以交给 Multi-Agent Intelligence Plane。需求解析、场景设计、脚本草稿、执行评审、指标解读、根因假设、容量预测候选、报告草稿和管理摘要，都可以由 AI 给候选结果，但结果里必须保留证据、置信度、限制条件和待确认项。
最终取舍仍然由人来做。风险是否接受，调优先做哪一项，容量能不能承诺，生产动作能不能执行，报告能不能发布，这些事情需要有人负责。
我们更认同的一句话还是：
Workflow 把门，AI 出活，人拍板。
这句话听起来简单，但它能防住很多走偏的设计。AI-7D-SATS 要做的是把专业经验、行业知识和分析方法放到工程师手边，而不是绕过治理链路替人拍板。
六、为什么现在值得做
7DGroup 一直有一句话：
为技术创建标准，为服务树立标杆，为客户实现价值。
放到性能工程里，这句话不是多写几篇文章、多做几次培训就够了。更关键的是，把方法论、项目案例、工程实践和团队能力建设连起来。
过去性能工程能力主要靠人带人、靠项目磨项目。资深工程师做过金融核心、电力交易平台、互联网高并发活动，就能在复杂问题里更快找到方向；新人即使会工具，也常常不知道怎么把指标、日志、业务和架构串起来。
AI-7D-SATS 想往前推一步：把个人脑子里的判断，沉淀成团队可复用的工程能力。
非功能体系不只停留在文档里，要进入需求识别和风险判断；RESAR 不只停留在流程图里，要进入任务流、报告流和复盘流；性能分析七步法和决策树不只停留在培训材料里，要进入每一次指标解读和根因假设；金融、电力、互联网等行业案例不只停留在历史项目里，要进入可检索、可引用、可审查的专业知识库。
国产化和信创适配里的非功能测试经验也应该被沉淀下来。哪些数据库迁移场景容易出现 SQL 计划波动，哪些中间件替换会改变连接池行为，哪些国产化环境需要重新建立容量基线，这些都不该只留在某一次项目复盘里。
AI 应用的性能和非功能经验也一样。模型调用、RAG 检索、Agent 工作流、工具链路、限流退化、成本水位和可观测性问题，都不该只散在几次试点项目、会议记录或个人笔记里，而应该进入可检索、可引用、可审查的专业知识库。
这就是我们做 AI-7D-SATS 的原因。
不是为了省几小时文档整理时间。那当然有价值，但还不够。
更重要的是，性能分析太难，行业经验太宝贵，团队能力不能一直靠口口相传。AI 不能替性能工程师做最终决策，但它可以帮工程师更快看见问题，更完整地组织证据，更稳定地复用经验，把一次次项目实践变成下一次真正用得上的能力。
如果你也做性能测试、性能工程、测试平台、智能运维或 AI 测试工具建设，可以关注这个系列。我们会继续记录 AI-7D-SATS 从 0 到 1 的过程：方法论怎么落进产品，边界怎么取舍，能力怎么验证，以及哪些事情必须继续由人来拍板。
