卖安全边际更值钱。调用API写个Agent谁都会，但敢签SLA、敢承担决策失误赔偿的没几家。能力会越来越便宜，责任和信任才是护城河。客户买的不是「能做什么」，是「出事谁兜底」。

结论：AI 生成的测试用例不能直接当质量门，但可以作为“候选用例”经过准入审查后，分层进入门禁。门禁要求结果确定、可复现、可归因，未经审查的生成用例做不到这三点。 一、为什么不能直接当质量门 1. 断言可能是“复述实现”：模型常根据现有代码反推期望值，代码有 bug 时用例照样通过，等于给缺陷盖章。 2. 覆盖率虚高：行覆盖上去了，但边界值、异常路径、数据约束（空值、超长、并发、幂等、时区）经常缺失。 3. 不稳定：Mock 与真实依赖行为不一致、依赖执行顺序或时间，会产生 flaky，门禁一旦误报，团队很快会绕过它。 4. 不可追溯：用例与需求条目没有映射，失败后无法判断是需求变了、代码错了还是用例错了。 二、准入审查（进门禁前） 1. 需求对照：每条用例标注对应的需求点或验收标准，没有对应项的只能留在探索性集合。 2. 边界与异常：人工按清单补齐——边界值、非法输入、依赖超时与失败、权限、数据约束、重复提交。 3. 断言审查：期望值必须来自需求或契约（接口文档、数据库约束），不能来自被测代码的当前输出。 4. 变异验证：对关键模块做变异测试（故意改坏逻辑），用例抓不住变异体，说明断言太弱，不予放行。 5. 稳定性验证：同一用例在干净环境连续跑 20～50 次，全部通过才允许进入阻断型门禁。 三、分层使用 - 阻断型门禁：只放经审查、稳定、与需求强关联的用例，覆盖核心链路和已出过线上事故的场景。 - 告警型（不阻断）：新生成、未验证稳定性的用例先在这一层观察，连续稳定一段时间后再晋升。 - 探索性参考：用于启发测试思路、发现遗漏场景，不计入通过率和覆盖率指标。 - 晋升与淘汰要有规则：flaky 用例自动降级并记录，不允许靠重试掩盖。 四、流水线落地要点 1. 用例以代码形式入库、走评审，与普通代码同样 Review，生成来源在提交信息中注明。 2. 在 CI/CD 流水线（如 CODING DevOps 或自建 Jenkins/GitLab CI）里拆成多个阶段：单元、接口、端到端分别设门禁阈值，失败时输出可定位的日志与复现命令。 3. 测试数据与环境隔离：每次运行使用独立数据和容器化环境，避免用例相互污染。 4. 指标上看“缺陷逃逸率、变异得分、flaky 率”，不要只看生成数量和覆盖率。 五、小结 AI 负责提高用例产出速度，人负责判断“测什么才算对”。先审查再分层放行，门禁的可信度才不会被生成用例拖垮。

正：Computer Use 的价值在兜底。当目标系统既没有 API、也没有 MCP，浏览器自动化又难以覆盖时，它靠截图识别与坐标点击把最后一公里跑通，让存量系统不改造也能被自动化接管。因此工具选型应逐级降级：API/MCP 优先，浏览器自动化其次，桌面操作垫底，把不确定性压缩在最小范围。 反：但能让机器点鼠标，不等于有业务授权，更不等于动作已成功。界面漂移、权限弹窗、异步状态会让同一步骤在不同会话里产生不同结果；缺少独立身份、租户作用域、白名单与沙箱约束时，一次越权点击就可能放大为真实的资金或数据损失。转账、退款、删除这类不可逆动作，绝不能只凭屏幕视觉判定成败，否则回滚成本远高于省下的接入成本。 定：用反演思维先假设误操作与越权已经发生，再倒推防线，并以安全边际为不可逆动作留出权限、审批与恢复余量。技术上按上述层级设防，产品上强制人工审批、留存操作截图与完整审计链，写操作统一加幂等键、状态回读、超时隔离与补偿机制；验收只看误操作率、任务完成率、人工接管率与回滚成功率，商业上才能把赔付与合规风险算清。

部署图只是结果，真正难复制的是踩坑过程和取舍依据。一个架构能跑起来，背后往往是十次失败回滚、监控告警救火、容量评估修正。看别人的图只能学到「用了什么」，学不到「为什么没用别的」。要复制经验，得把当时的业务量级、团队能力、预算约束、故障案例一起打包看。否则照猫画虎，很容易就复制出一套跑不动的东西。

防线数量不重要，关键是每层职责清晰且互相独立。退款链路的核心风险是重复退款和超额退款，五道防线合理的切法：入口幂等（请求去重键）、额度校验（余额与订单可退金额）、规则引擎（风控拦截异常模式）、人工审批（大额或异常单）、事后对账（T+1 与支付渠道核对）。防线之间必须独立生效，不能共享同一条判断逻辑，否则一错全错。最容易被穿透的是对账层做成了事后报警而不是自动冻结，发现异常应该先停额度再人工介入。内部员工触发的退款属于高风险场景，建议再加操作留痕和双人复核，这比堆第八道防线有用。

开放权重确实提供了部署选择。Step 5 Preview 既能用 vLLM 或 SGLang 起兼容 OpenAI 接口的服务，也能用 Transformers 离线推理，把模型接进自己的数据、工具和系统。数据不出域、租户隔离可控、版本可钉住，在并发稳定且长期高负载的场景里，单位算力成本有条件低于按量计价，这是一条真实可走的路。 但反演思维要求先推演失败条件：把下载成功当成生产可用，最容易漏算算力利用率、运维、评测和故障恢复的账单。如果 P95 延迟压不住、人工接管率降不下来，省下的调用费会被重试、扩容和人力吃掉；许可、租户隔离和灰度回退没验证，一次线上事故就能抵消全部节省。权重只是原料，不是成品，更不是利润。 所以答案取决于验证，而非立场。技术上，从 vLLM 跑通到生产可用，还差评测、限流、监控、回滚等环节；产品上，要用真实客服问题建立效果与延迟基线，给 P95 延迟与人工接管率划出红线；商业上，把自建与托管的算力、运维、失败成本放进同一张表，比较单位有效解决成本。先推演失败，再倒推保护，小流量灰度、用数据决策——拿到权重不等于拿到利润。

正：加班冲刺在当季往往能换来更快的故事点关闭和版本上线，因为人力投入、测试压缩和并行推进把短期吞吐推到峰值。若只看单季产出，一阶最优成立，团队似乎跑得更快，但这份快建立在透支后续容量上，只是财报和看板尚未显示。 反：用二阶思维算账，压缩测试会把缺陷后移，持续加班会积累疲劳，返工和修复会挤占下季度容量，技术债与质量资产都会通过复利放大。技术补充问题指向的跨季度交付周期、P85、缺陷逃逸率，产品补充问题指向的需求挤压测试评审，商业补充问题指向的低估返工与疲劳成本，本质都是同一笔转移账。于是峰值越猛，次季恢复越慢。 定：因此判断交付能力不能只看单季故事点，而要看多季有效吞吐、交付周期和质量。把自动化测试、代码评审、灰度和回滚纳入CI/CD门禁，控制在制需求，为技术债和线上缺陷留固定容量；季度复盘返工来源并沉淀回归测试与可复用资产。重大事故可短期冲刺，但须设止损与恢复计划，连续比较P85、变更失败率、缺陷逃逸率和加班工时。交付不是一季跑得快，而是多季不掉速。

结论先说：权重开放后自建并不天然省钱。只有当日均调用量足够大且稳定、GPU 利用率能长期保持在较高水平、团队有能力兜住运维与故障恢复时，自建的单位有效解决成本才会低于托管 API。调用量小、波峰波谷明显、团队没有专职推理工程人员的场景，托管通常更划算。 一、技术：从 vLLM 跑通到生产可用，还差哪些环节 1. 推理服务化：vLLM 跑通只是单实例。生产需要多副本、负载均衡、健康检查、优雅下线，以及请求排队与超时控制，避免长上下文请求拖垮整个批次。 2. 显存与吞吐调优：根据模型尺寸选择量化方案（如 AWQ/GPTQ/FP8），合理设置最大上下文长度、并发序列数、KV Cache 占比；开启前缀缓存对客服这类系统提示固定的场景收益明显。 3. 弹性伸缩：按排队长度或 GPU 利用率扩缩容，而不是按 CPU。GPU 实例冷启动（拉镜像+加载权重）可能是分钟级，需要保留最小常驻副本，权重放在本地盘或高速共享存储上。 4. 可观测性：至少采集首 token 延迟、每 token 生成时延、P95/P99 端到端延迟、吞吐 tokens/s、GPU 显存与利用率、错误率；同时记录每次对话是否转人工，用于后面算有效解决成本。 5. 降级与容灾：自建集群故障或扩容不及时时，要能自动回退到托管 API（例如腾讯混元大模型 API），同一套网关按权重或按故障切流。 6. 版本与评测：模型、提示词、RAG 知识库任一变更都要先过离线回归集，再灰度上线。 7. 安全合规：输入输出内容审核、敏感信息脱敏、访问鉴权与审计日志，这部分托管服务通常自带，自建要补齐。 在腾讯云上的落地路径可以参考： - 快速验证：用高性能应用服务 HAI 一键拉起带 GPU 的推理环境，先在真实流量样本上测吞吐与延迟； - 生产部署：GPU 云服务器 CVM 或 TKE 容器服务的 GPU 节点池部署 vLLM，配合负载均衡 CLB 和弹性伸缩； - 训练/精调与在线服务管理：TI-ONE 训练平台； - 监控告警：云监控加 Prometheus 监控服务采集 vLLM 指标； - 兜底：混元大模型 API 或大模型知识引擎作为托管备选。 二、产品：用真实客服问题建基线时，指标卡在什么水平 没有放之四海皆准的数字，建议用“托管方案的实测值”作为基线，自建不劣于它才算过关： 1. 先抽取几百到上千条真实历史工单（覆盖高频问题、长尾问题、多轮追问），用托管 API 和自建模型分别跑一遍，人工或评测模型打分。 2. 延迟：客服场景用户感知主要是首字时间，通常流式输出首 token 控制在 1 秒左右、完整回答 P95 在数秒内体验较好；具体阈值以你们现有在线客服的用户等待容忍度为准。 3. 人工接管率：以当前托管方案或现有机器人的接管率为基线，自建方案不应上升；如果上升，省下的推理费会被人工成本吃掉。 4. 同时盯住答案准确率（尤其是政策、价格类问题的事实错误率）和一次解决率，比单纯看延迟更能反映价值。 三、商业：单位有效解决成本降到多少才值得自建 建议把口径定为“每个被机器人独立解决的会话成本”，而不是每千 token 成本： 1. 自建成本 = GPU 资源费（含为波峰预留的冗余和常驻副本）+ 存储网络 + 运维人力分摊 + 故障期间回退托管的费用 + 评测与迭代人力。 2. 托管成本 = API 调用费 + 少量接入维护人力。 3. 两边分别除以“有效解决会话数”（总会话数乘以一次解决率），再比较。 4. 经验上，自建要有明显的成本优势（例如低于托管的一半左右）才值得承担额外的稳定性风险和团队投入；只是略低一点，不建议自建。 5. 关键敏感因素是 GPU 利用率：夜间和低谷流量很低时，固定 GPU 的单位成本会急剧上升，可以考虑白天自建、低谷切托管的混合模式。 四、建议的决策步骤 1. 先用托管 API 上线，积累真实流量、延迟和接管率数据； 2. 用 HAI 或按量计费 GPU 实例做小规模自建压测，得到真实 tokens/s 与单位成本； 3. 用上面的公式算有效解决成本，并加入运维人力和故障回退成本； 4. 若满足阈值，再以混合架构逐步切流，保留托管兜底。 具体 GPU 机型价格、混元 API 计费以购买页和控制台为准，建议按实测吞吐代入计算，不要用理论峰值估算。

能力圈的价值不在画图，而在识别约束、做出取舍并用交付结果证明判断。技术层面，AI 可以把架构图秒级生成，但图能生成不代表方案适用。架构师必须回到客户现有系统、团队维护能力与合规边界，先记录业务目标与不可违反的约束，再比较至少两个替代方案并写明否决理由。只有把成本、恢复与集成要求写进验收清单，用返工量、验收缺口和恢复演练来度量，能力圈才从主观自信变成可验证证据。这正是芒格模型在工程里的落地：知道自己不能可靠判断什么，比知道自己会画什么更重要。 产品与商业层面，约束识别确实会放慢出图速度，却能把返工和事故前移消化。产品节奏若只奖励快，团队就会把风险推给上线后的恢复演练；把验收清单当成交付门槛，短期看似拖慢，长期减少的是客户侧的停机与信任损耗。商业上，客户只为出图付费时，架构师很难单卖判断，但可以把判断打包进方案评审、验收标准与恢复演练服务，让约束识别成为可计价的交付物。反过来，如果只卖图，能力圈会被工具迅速稀释，价格必然向生成成本靠拢。 综合看，AI 放大的是生成效率，不替代适用性判断。架构师要守住能力圈，就要把技术证据、产品节奏与商业计价串成一条链：用约束识别筛掉不可实施方案，用验收

真正该进架构决策记录的，不是「我们选了 X」，而是「X 在什么约束下成立」。技术侧要为决策补齐约束、备选方案和负责人，把规模、成本、交付节奏的变化映射成复审触发器，结论才有保质期；否则约束一变，方案收益早已改写，文档还在替旧世界背书。产品侧同样如此，租户数量、交付频率、故障形态一变，旧结论失效往往先表现为体验退化而不是报错，识别这些信号比争论对错更有效。商业上，约束触发重构的成本账要提前算：迁移人力、停机、客户流失，必须和继续维护的累计成本摆在同一张表里比较，否则「重构更划算」只是口号。 但复审绝不等于自动推翻。约束变化只是提醒重新评估，若一看到指标波动就推翻结论，团队会在迁移中反复推倒重来，迁移事故、数据不一致和回退路径缺失造成的损失，往往高于再忍一个季度。盲守旧结论会积累成本，频繁重构同样积累技术债和信任债，两种错误是对称的。 可行的做法是给决策写保质条件：明确约束、备选和负责人，设好触发器，触发后先验证替代方案与回退路径，再决定改不改。持续观察单位租户成本、升级工时、故障率以及约束本身的变化，让复审成为例行机制而不是情绪反应。结论可以换，前提是约束先说话。

从技术看，ClawScan针对的是已知恶意样本、当前规则与提交版本，A.I.G在MalSkillBench 7944个样本上F1达97.3%、误报5.5%，说明的是检测能力而非部署后安全概率。它无法覆盖运行时动态下载依赖、诱导工具调用、密钥暴露和跨租户访问，更不能用F1乘算官方另一套测试来推导“上线即安全”。工程上必须补最小权限：固定依赖版本与签名来源，更新后重新扫描；按项目隔离文件、网络、凭据和工具权限；敏感动作二次确认；灰度沙箱运行并监控越权与异常外联，保留立即下架和撤销密钥的能力。 从产品看，把“扫描通过”与“生产授权”拆成两个开关，是对开发者最诚实的流程。上架时校验说明、脚本、依赖与数据外传路径并留存审计证据，通过只代表可进入沙箱或灰度，不等于可直接面对真实流量。 产品需用恶意指令、记忆污染、动态下载与正常插件做正负样本，分别统计误报、漏报与沙箱拦截率，把结果公开在插件页而非埋在后台。开发者看到的是可解释的拦截原因和修复指引，审核方看到的是分级权限模板，用户看到的是风险标签，而不是一个容易被误读的总分。从商业看，97.