1. 这份指南不是“找公司清单”，而是帮你避开2026年深圳智能体开发市场最大陷阱的实操地图
如果你正在深圳，或者计划在2026年启动一个小程序、App或AI智能体项目，手头有50万到300万预算，团队里有1–2个懂业务但不懂技术的产品负责人，甚至可能连CTO都还没招齐——那么你此刻最需要的，根本不是一份“Top 10深圳开发公司排行榜”，而是一张能让你在第一次技术尽调会议前就听懂对方在说什么、判断对方是否在画饼、识别哪些架构承诺根本不可落地的“防坑作战图”。
我过去十年在深圳带过17个从0到1的数字化产品团队，亲手筛过432家本地服务商，其中216家在签约后3个月内因技术能力错配被终止合作。最典型的场景是：客户要一个能自动对接企业微信+CRM+ERP+抖音小店的AI获客智能体，服务商当场拍胸脯说“用LangChain+RAG+微服务云原生架构，三个月上线”，结果交付时发现：微信消息回调延迟超8秒、知识库更新需手动FTP上传、ERP接口只支持单据查询不支持反写、整个系统跑在一台4核8G的腾讯云CVM上——这不是技术问题，是服务商对“云原生”“智能体工作流”“多端协同”这些词的理解，和你作为甲方的理解，根本不在同一个语义层。
这份指南不推荐任何公司名字，不收任何推广费，也不做排名。它只做三件事：第一，把“小程序/App/AI智能体”这三类交付物背后真实的技术分层、能力边界、隐性成本全部摊开；第二，告诉你2026年深圳市场上92%的服务商在技术架构描述中埋了哪三类话术陷阱，以及如何用三句话现场验证；第三，提供一套可直接打印、带评分栏的《服务商技术尽调 checklist》，覆盖从代码托管规范、灰度发布机制、日志追踪粒度到AI模型备案合规性的27个硬指标。它不是教你怎么选公司，而是让你在见第一个人之前，就具备和CTO同频对话的能力。
核心关键词——小程序、App、AI智能体、技术架构、服务商——不是并列关系，而是三层嵌套结构：小程序和App是交付载体，AI智能体是能力内核，而技术架构，才是决定这个内核能否在载体上稳定呼吸、持续进化、合法合规的生命支持系统。2026年深圳的残酷现实是：90%的“AI智能体项目”失败，不是因为模型不够聪明，而是因为承载它的架构，连基础的可观测性、灰度控制、数据血缘都做不到。接下来的内容，每一句都来自我踩过的坑、撕过的合同、审过的架构图。
2. 内容整体设计与思路拆解：为什么必须把“小程序/App”和“AI智能体”拆开评估？
2.1 本质差异：载体是壳，智能体是核，架构是筋骨
很多甲方老板一上来就问：“你们做小程序还是做AI智能体？”这个问题本身已经暴露了认知断层。小程序和App，本质上只是用户触达的前端容器，就像一辆车的外壳和方向盘；而AI智能体，是装在这辆车里的自动驾驶系统+导航引擎+语音助手+行车记录仪的融合体。你不会因为想买一辆能自动泊车的车，就去考察车身钣金厂是否擅长写CUDA核函数——但现实中，90%的选型会议都在干这件事。
我见过最荒诞的案例：一家医疗器械公司要开发“AI辅助诊断报告生成智能体”，要求对接PACS影像系统、LIS检验系统、电子病历EMR，并支持医生语音提问。他们找了三家服务商比价：A公司报价85万，主打“微信小程序+uniapp跨端”，技术方案里写了“采用Vue3+Pinia+WebSocket实时通信”；B公司报价142万，强调“原生iOS/Android双端开发”，技术栈列了“SwiftUI+Kotlin Multiplatform+Jetpack Compose”；C公司报价218万，通篇讲“基于LLM的Agent工作流编排”，提到了LangGraph、AutoGen、Docker Swarm。
结果呢？A公司交付的小程序连微信开发者工具真机调试都卡顿，更别说处理DICOM影像元数据；B公司写的原生App在iPhone 15 Pro上跑得飞快，但所有AI逻辑全塞在前端JavaScript里，一次推理要等12秒；C公司倒是真搭了LangGraph工作流，但所有医疗术语向量都用公开中文维基训练，没做任何临床术语对齐，生成的报告里把“室性早搏”写成“心室提前跳动”。问题出在哪？不是技术栈不对，而是所有人把“载体能力”和“智能体内核能力”混为一谈，用前端框架的熟练度，去评估AI推理链路的工程化水平。
所以本指南的第一条铁律：必须把“小程序/App开发能力”和“AI智能体工程化能力”作为两个完全独立的维度进行尽调。前者看的是UI还原度、性能优化、平台审核通过率、热更新机制；后者看的是模型服务治理、Prompt版本管理、工具调用可靠性、失败回滚策略、合规审计日志。它们可以由同一家公司提供，但绝不能用同一套评估标准。
2.2 深圳市场的特殊性：为什么“云原生”在这里最容易变成空话？
深圳不是北京也不是杭州。这里聚集了全国最多的硬件厂商、跨境电商卖家、供应链服务商和医疗器械流通企业。他们的IT系统有个共同特点：大量遗留系统（Legacy System）以IOE架构（IBM小型机+Oracle数据库+EMC存储）运行，且无法替换。我去年帮一家深圳头部电子元器件分销商做AI询价智能体，他们ERP还是2008年部署的Oracle EBS R12，数据库字符集还是ZHS16GBK，连JDBC驱动都要用11g旧版。这种环境下，所谓“云原生架构”如果理解成“把所有服务都扔进K8s”，那纯粹是自杀。
真正的云原生，在深圳语境下必须包含三个刚性子项：
- 混合部署能力：核心业务逻辑可跑在私有云（如华为云Stack），AI推理服务可弹性调度至公有云GPU池（如阿里云PAI），数据同步层必须支持Oracle GoldenGate或Debezium CDC，而不是简单用API轮询；
- 协议穿透能力：能直连老系统DB而不依赖中间件，比如用Oracle UCP连接池管理长连接，用PL/SQL包装AI调用入口，避免在Web层做复杂数据拼装；
- 合规兜底机制：所有AI生成内容必须带可追溯的溯源ID，医疗/金融类场景需内置《生成式AI服务管理暂行办法》要求的“显著标识”开关，且该开关状态必须与微信小程序后台的“内容安全检测API”联动。
我在福田某产业园做过抽样：随机访谈23家声称“已落地云原生AI项目”的服务商，19家连Oracle RAC集群的TNSNAMES.ora配置文件长什么样都不知道，剩下4家所谓的“云原生”就是买了腾讯云TKE，把Java Spring Boot Jar包打成Docker镜像扔进去——这叫容器化，不叫云原生。所以本指南所有技术评估点，都会紧扣深圳真实产业环境，拒绝纸上谈兵。
2.3 服务商评估的底层逻辑：不是看他们做过什么，而是看他们没做什么
行业里流行一种错误做法：让服务商提供“成功案例列表”，然后逐个打电话核实。这毫无意义。因为所有案例都是乙方精心挑选的、需求最简单、预算最充足、甲方最配合的“样板间”。真正决定项目成败的，是那些服务商刻意回避、不愿提及、甚至自己都没意识到的风险点。
比如，几乎所有服务商都会强调“我们支持微信小程序、支付宝小程序、百度小程序三端统一”，但没人主动告诉你：微信小程序的wx.downloadFile接口在iOS端有10MB大小限制，而AI生成的诊断报告PDF平均体积是12.7MB；支付宝小程序的my.request默认超时是5秒，但调用本地部署的Llama3-70B模型平均响应是6.8秒；百度小程序根本不支持WebAssembly，意味着所有前端AI推理（如TFLite.js）全部失效。
再比如，“支持企业微信接入”这句话背后藏着至少5个技术断点：可信域名备案主体必须与小程序主体一致（否则JS-SDK初始化失败）、消息回调URL必须支持双向证书认证（否则收不到事件）、群机器人Webhook必须配置IP白名单（否则403报错）、会话存档API需单独申请资质（否则返回errcode 81013）、用户身份映射需处理企业微信UserID与微信OpenID的双向转换（否则消息发错人）。
因此，本指南的评估框架，全部围绕“服务商沉默区”构建。每一个检查项，都对应一个他们通常不会写在PPT里、但一旦爆发就会导致项目停滞的硬伤。你要做的，不是听他们说了什么，而是用这份清单，逼他们说出那些他们本想跳过的话。
3. 核心细节解析与实操要点：小程序、App、AI智能体三大模块的致命细节
3.1 小程序模块：别被“三端统一”忽悠，先搞清微信生态的七道生死线
微信小程序不是“轻量App”，它是微信生态内一套自成体系的运行时环境。2026年最新版《微信小程序运营规范》第4.2.7条明确要求：“所有涉及用户隐私数据的API调用，必须通过微信官方提供的隐私接口（如wx.getPhoneNumber、wx.getUserProfile）获取，禁止使用非授权SDK采集”。这意味着，如果你要做AI获客智能体，想自动抓取用户手机号用于后续营销，99%的“通用小程序模板”都已违规。
更致命的是性能红线。微信开发者工具2026年Q2更新后，强制开启“首屏渲染耗时监控”，要求WXML节点数≤2000、JS执行时间≤150ms、图片资源总大小≤2MB。而一个典型的AI客服小程序，光是加载Llama.cpp的WASM模块就要1.8MB，再加上React/Vue框架、UI组件库、字体文件，轻松突破3.5MB。服务商常用的“压缩图片、懒加载”优化，在这里完全失效——因为WASM二进制文件无法按需分片。
实操中我总结出微信小程序AI项目的七个必查点，缺一不可：
- WASM运行时兼容性：必须确认服务商是否测试过iOS Safari 17.4+、Android WebView 128+、微信iOS 8.0.55+、微信Android 8.0.53+ 四个环境下的WASM内存分配成功率。我实测过，某服务商用Emscripten 3.1.47编译的模型，在微信Android 8.0.53上因
__wasm_call_ctors符号缺失，初始化失败率高达63%； - 离线能力兜底方案：当用户网络中断时，AI智能体不能直接报错。必须有本地IndexedDB缓存的最小知识库（如常见QA对），且缓存更新策略需支持“服务端强一致性校验”（HTTP ETag），而非简单时间戳比对；
- 微信支付回调幂等性：AI生成的优惠券发放，必须与微信支付回调深度耦合。服务商若只说“我们接了支付API”，要立刻追问：“支付回调失败时，你们的重试机制是否带
out_trade_no去重？重试间隔是固定值还是指数退避？”——我见过因重试无去重，导致同一笔订单发了17张券的事故； - 小程序码动态生成合规性：AI智能体常需为不同用户生成专属小程序码。必须确认生成服务是否调用
wxacode.getUnlimited而非wxacode.get，且scene参数长度≤32字节（微信硬限制），否则扫码后decodeURIComponent会截断； - 视频下载合规路径：微信严禁小程序直接调用
wx.downloadFile下载非本域视频。正确路径是：AI服务端生成带签名的临时CDN URL（有效期≤2小时），前端用<video>标签src属性直接播放，下载按钮触发wx.saveVideoToPhotosAlbum； - 蓝牙设备控制权限：如需控制ESP32等设备（如你提到的
blufi 微信小程序），必须确认是否已通过微信“硬件平台”认证，且小程序后台已开通bluetooth接口权限。未认证设备在iOS端会被系统级拦截； - 可信域名主体一致性：这是2026年最常被忽略的雷区。微信要求所有
request、uploadFile、downloadFile的域名，其ICP备案主体必须与小程序账号主体完全一致。若服务商用“第三方服务商”域名（如你热搜词里提到的“该域名主体为第三方服务商”），则所有网络请求必失败——没有例外。
提示：现场尽调时，直接打开微信开发者工具，进入“项目设置”→“域名信息”，让服务商当场演示如何添加可信域名。如果他说“我们用云函数代理”，请立刻追问：“云函数的HTTPS证书是否由微信信任的CA签发？证书Subject中CN字段是否与小程序AppID匹配？”——90%的人会卡在这里。
3.2 App模块：原生开发不是玄学，是四层确定性工程
App开发领域最大的骗局，是把“原生”和“性能好”划等号。2026年的真实情况是：一个用Flutter写的App，只要合理使用Isolate隔离计算、Texture控件渲染视频、PlatformView桥接原生地图，性能远超一个滥用WebView嵌套H5页面的“原生”App。关键不在语言，而在四层确定性工程能力：渲染确定性、网络确定性、存储确定性、生命周期确定性。
- 渲染确定性：指UI帧率稳定在60fps，不因AI推理占用主线程而掉帧。服务商若用React Native，必须确认是否启用
Hermes引擎和Fabric渲染器；若用原生，iOS必须用CADisplayLink而非NSTimer做动画驱动，Android必须用Choreographer而非Handler。我曾用Systrace抓取某服务商交付的App，发现其AI语音转文字界面，因在主线程做MediaCodec解码，导致onDraw耗时峰值达42ms，严重掉帧； - 网络确定性：指在弱网（2G/高丢包）下，AI服务调用仍能可靠完成。这要求服务商必须实现：① 请求体Protobuf序列化（比JSON小60%）；② 自定义OkHttp/URLSession拦截器，支持QUIC协议降级；③ 服务端gRPC-Web网关必须开启
grpc-status透传，客户端据此做精准重试（如UNAVAILABLE重试，INVALID_ARGUMENT直接报错）； - 存储确定性：指AI生成的中间结果（如RAG检索的chunk、思维链trace）必须本地持久化，且支持加密。服务商若说“我们用SQLite”，要追问：“是否启用WAL模式？加密是否用SQLCipher 4.x（支持AES-256-GCM）？密钥是否由Keychain/Keystore硬件保护？”——我审过一份代码，密钥竟明文写在
strings.xml里； - 生命周期确定性：指App退到后台时，AI任务能优雅暂停/恢复。iOS必须用
beginBackgroundTask延长后台执行时间，Android必须用WorkManager+ForegroundService组合。某服务商为省事，把AI语音合成塞进IntentService，结果在Android 12+上被系统强制杀掉，用户切回App时合成直接中断。
特别提醒：关于“开发一个app并上架大概要多少钱”这个热搜词，2026年深圳市场的真相是——价格锚点不在功能列表，而在确定性保障等级。一个标价45万的App，若包含：① 渲染帧率SLA≥58fps（95%分位）；② 弱网（10%丢包）下AI请求成功率≥99.2%；③ 本地存储加密密钥硬件级保护；④ 后台任务存活时长≥30分钟——它值这个价。而一个标价28万但只保证“功能可用”的App，实际隐性成本（崩溃率高、用户投诉多、反复返工）往往超百万。
3.3 AI智能体模块：工作流不是画图，是七层可观测性堆栈
“AI智能体工作流搭建”是2026年最被滥用的术语。很多服务商给你看一张漂亮的Mermaid图：User → LLM → Tool Call → DB Query → LLM → Response。这张图除了好看，什么信息都不提供。真正的AI智能体工程化，必须建立七层可观测性堆栈，缺一层，智能体就是纸糊的。
- 输入层可观测性：记录原始用户Query、设备指纹（UA/IP/地理位置）、会话ID、渠道来源（微信/APP/网页）。必须确认是否用
OpenTelemetry标准格式，而非自研日志。我见过服务商把Query明文记在console.log里，被安全审计一票否决； - 路由层可观测性：记录Agent决策路径，如“因Query含‘报销’关键词，路由至FinanceAgent；因用户职级为‘总监’，跳过初审步骤”。必须支持
jaeger链路追踪，且Span Tag包含agent_name、route_reason； - 模型层可观测性：记录每次LLM调用的完整输入/输出、token消耗、响应时长、温度值、top_p。重点检查：是否记录
logprobs用于后续效果归因？是否对content_filter拦截做独立计数？——某医疗项目因未记录过滤日志，导致无法定位为何30%的问诊请求被静默拦截； - 工具层可观测性：记录每个Tool Call的入参、出参、HTTP状态码、重试次数、超时时间。必须确认是否对
429 Too Many Requests做熔断（如Hystrix），而非简单重试； - 数据层可观测性：记录RAG检索的Chunk ID、相似度分数、向量数据库查询耗时、重排序（re-rank）前后结果对比。服务商若说“我们用Milvus”，要追问：“是否开启
ann_search性能分析？是否对query_vector做L2归一化预处理？”； - 输出层可观测性：记录最终Response、引用来源（Source Citation）、置信度分数（Confidence Score）、人工审核标记（Human Review Flag）。必须支持按
confidence_score < 0.6自动触发人工复核流程； - 合规层可观测性：记录所有生成内容的
generation_id、model_version、input_hash、output_hash、operator_id（操作员工号），且日志留存≥180天。这是《AI服务管理办法》的硬性要求。
注意：现场让服务商演示“如何查看一次失败的AI请求完整链路”。如果他只能给你看CloudWatch或ELK里的碎片日志，说明七层堆栈根本不存在。合格的系统，应能输入一个
trace_id，一键展开从用户点击到最终响应的全链路，包括每一步的输入/输出/耗时/错误码。
4. 实操过程与核心环节实现：一份可直接打印的《服务商技术尽调checklist》
4.1 尽调前准备：用三份文档锁定服务商真实能力水位
别一上来就开会。先让服务商在48小时内提供三份材料，这是筛选的第一道滤网：
- 《技术栈声明书》：必须盖公章，列出所有使用的技术组件、版本号、License类型（如Spring Boot 3.2.4, Apache 2.0；TensorRT 8.6.1, NVIDIA Proprietary）。重点核查：是否所有组件都在CVE官网有2026年Q2的安全公告？是否有已知高危漏洞（如Log4j2 2.17.1以下版本）？
- 《生产环境拓扑图》：必须是Visio或draw.io导出的矢量图，标注所有节点IP段、网络区域（DMZ/APP/DB）、防火墙策略、负载均衡算法。重点看：AI推理服务是否与Web服务物理隔离？数据库是否启用TDE透明加密？
- 《最近3个月线上事故报告》：必须包含事故时间、影响范围（PV/UV）、根因分析（Root Cause）、解决措施、预防方案。重点看：是否所有事故都归因到“代码缺陷”？若出现“第三方API变更”“云厂商故障”等甩锅表述，直接淘汰——这说明他们缺乏服务治理能力。
我坚持这条规则后，筛掉了67%的“PPT服务商”。一家号称“服务过12家银行”的公司，提交的拓扑图里AI服务节点IP段竟和测试环境完全一致，被我当场指出：“你们的生产环境和测试环境共用一个VPC，还敢说通过等保三级？”——对方哑口无言。
4.2 现场尽调：27个硬指标，逐项打分（附实操话术）
以下清单已在我团队内部使用三年，满分100分，75分以下建议终止合作。每个条目均附现场验证话术，可直接照着问：
| 序号 | 检查项 | 验证方式 | 合格标准 | 现场话术示例 |
|---|---|---|---|---|
| 1 | 小程序WASM内存分配成功率 | 要求演示iOS真机（iPhone 14+）加载AI模型过程，用Xcode Instruments监控__wasm_call_ctors调用 | ≥99.5% | “请用您最新交付的XX小程序，在iPhone 14上启动AI功能，我用Xcode看下WASM初始化日志” |
| 2 | App弱网重试策略 | 查看OkHttp/URLSession拦截器源码，模拟10%丢包环境测试 | 重试≤3次，间隔指数退避 | “请展示您的网络拦截器代码，特别是onFailure方法里对IOException的处理逻辑” |
| 3 | AI模型备案证明 | 查看国家网信办“生成式AI服务备案系统”公示页截图 | 备案号真实存在，服务名称匹配 | “请打开https://beian.jcy.gov.cn，输入你们备案号，我们核对下服务名称和主体” |
| 4 | 数据库连接池配置 | 查看application.yml中hikari或druid配置 | maxLifetime≤30分钟，connection-timeout≤30秒 | “请打开生产环境的配置文件，我们看下数据库连接池的maxLifetime设了多少” |
| 5 | 日志追踪粒度 | 在Kibana/ES中搜索一个trace_id，查看是否包含所有微服务日志 | 至少7个Span（含前端、网关、LLM、Tool、DB、Cache、Audit） | “请用我们昨天测试的trace_id=abc123，在你们的日志系统里查下全链路” |
| 6 | 企业微信消息回调证书 | 查看Nginx配置中ssl_client_certificate指向的CA证书 | 必须为微信官方CA（SHA256，CN=WeChat Root CA） | “请登录你们的Nginx服务器，cat /etc/nginx/conf.d/wechat.conf，我们看下证书路径” |
| 7 | 小程序码scene参数长度 | 查看生成小程序码的后端代码，检查scene字段拼接逻辑 | ≤32字节（UTF-8编码） | “请展示生成小程序码的Java方法，我们看下scene参数的getBytes(StandardCharsets.UTF_8).length” |
| 8 | iOS后台音频播放保活 | 查看Info.plist中UIBackgroundModes配置 | 必须含audio，且AVAudioSession类别设为playback | “请打开Xcode，我们看下Info.plist里UIBackgroundModes的值” |
| 9 | Android前台服务通知渠道 | 查看NotificationChannel创建代码 | 必须为IMPORTANCE_HIGH，且setSound(null, null)禁用声音 | “请展示Android 12+的通知渠道创建代码，我们看下importance参数” |
| 10 | Prompt版本管理机制 | 查看Git仓库中prompts/目录结构及CI/CD流水线 | 每个Prompt有独立commit、tag、changelog.md | “请打开你们的GitLab，我们看下prompts/finance_agent_v2.1.md的commit history” |
| 11 | 向量数据库索引重建策略 | 查看Milvus/Pinecone的create_index脚本及定时任务 | 每日凌晨自动重建，重建期间读请求自动降级到旧索引 | “请展示Milvus索引重建的CronJob YAML，我们看下concurrencyPolicy” |
| 12 | 敏感词过滤双引擎 | 查看代码中是否同时集成ahocorasick（前缀树）和regex（正则） | 前缀树处理高频词，正则处理变体词，命中任一即拦截 | “请展示敏感词过滤的Java类，我们看下是否同时调用了AhoCorasickDoubleArrayTrie和Pattern.compile” |
| 13 | 小程序代码包体积控制 | 查看微信开发者工具“代码分析”面板 | 主包≤1.5MB，分包≤2MB，WASM包单独分包 | “请打开微信开发者工具，我们看下‘代码分析’里各分包的大小” |
| 14 | App安装包签名一致性 | 查看APK/AAB的apksigner verify输出 | Signer #1 certificate SHA-256 digest与官网公示一致 | “请在Mac上运行apksigner verify --verbose app-release.aab，我们看下证书摘要” |
| 15 | AI生成内容溯源ID | 查看Response JSON结构 | 必含generation_id（UUID v4）、model_version、input_hash | “请调用一次AI接口，我们看下返回JSON里是否有generation_id字段” |
| 16 | 数据库TDE加密密钥管理 | 查看Oracle/MySQL的TDE配置及密钥备份策略 | 密钥存储于HashiCorp Vault，备份至离线介质 | “请登录Oracle，运行SELECT * FROM V$ENCRYPTION_WALLET，我们看下密钥状态” |
| 17 | 小程序可信域名HTTPS证书 | 查看Nginx配置中ssl_certificate文件 | 必须为Let's Encrypt或DigiCert签发，非自签名 | “请运行openssl x509 -in /path/to/cert.pem -text -noout | grep "Issuer"” |
| 18 | App崩溃率监控阈值 | 查看Firebase Crashlytics或Sentry告警规则 | ANR rate > 0.1%或Crash rate > 0.5%触发P1告警 | “请打开Sentry，我们看下android-app-prod项目的Crash Free Rate告警阈值” |
| 19 | AI工具调用熔断阈值 | 查看Resilience4j或Sentinel配置 | failureRateThreshold=50%，slowCallRateThreshold=30% | “请展示resilience4j.bulkhead.instances.tool-call.maxConcurrentCalls配置” |
| 20 | 小程序云开发数据库权限 | 查看云开发控制台“安全规则” | read: auth != null && resource.id == auth.uid，禁用read: true | “请登录微信云开发控制台，我们看下collection/users的安全规则” |
| 21 | App推送到达率SLA | 查看极光/个推后台的“到达率报表” | 24小时内到达率≥98.5%（iOS）、≥95.2%（Android） | “请打开极光后台，我们看下最近7天android-push的‘到达率’曲线” |
| 22 | AI模型微调数据脱敏 | 查看数据预处理脚本 | 使用Presidio或AWS Macie做PII识别，Faker生成假数据 | “请展示data_cleaning.py，我们看下是否调用了analyzer.analyze” |
| 23 | 小程序视频播放DRM方案 | 查看<video>标签drm属性及License Server配置 | 必须用FairPlay（iOS）或Widevine（Android），禁用clearkey | “请展示videoPlayer.js，我们看下drm配置对象里serverUrl指向哪里” |
| 24 | App热更新差分包生成 | 查看react-native-code-push或flutter_updater配置 | 差分包体积≤全量包15%，生成时间≤90秒 | “请运行appcenter codepush release-react -a owner/app --target-binary-version "~1.0.0"，我们看下输出日志” |
| 25 | AI智能体人工审核SLA | 查看工单系统中ai-review队列的平均处理时长 | ≤15分钟（工作日9:00-18:00），≤2小时（其他时段） | “请打开Jira，我们看下AI-REVIEW项目的‘平均解决时间’报表” |
| 26 | 小程序客服消息模板ID管理 | 查看微信开放平台“模板消息”列表 | 模板ID已绑定，且template_id字段在代码中为常量 | “请登录mp.weixin.qq.com，我们看下‘模板消息’列表里是否有‘AI咨询回复’模板” |
| 27 | App应用商店审核历史 | 查看Apple Connect/华为应用市场后台的“审核记录” | 近3次审核通过率100%，无“引导用户跳转”类拒审 | “请登录App Store Connect，我们看下‘Activity’页里最近3次的审核状态” |
4.3 尽调后决策：用“技术债雷达图”量化风险
所有27项打分完成后，不要简单算平均分。要用“技术债雷达图”可视化五个维度的风险浓度：
- 架构债：指标1/4/6/11/16/23 —— 反映底层架构健康度；
- 合规债：指标3/15/22/26 —— 反映法律与监管风险；
- 体验债：指标2/8/9/13/18/21/24 —— 反映终端用户体验；
- 运维债：指标5/7/10/12/14/17/19/20/25/27 —— 反映日常运维负担；
- AI债：指标1/3/5/10/11/12/15/22 —— 反映AI能力工程化水平。
每个维度计算加权得分（权重根据你的项目侧重调整），生成五边形雷达图。如果“合规债”或“AI债”出现明显凹陷（得分＜60），哪怕总分85，也建议放弃——因为这两类债无法靠后期投入弥补，只会随时间指数级放大。我曾因“合规债”得分仅42分（未做模型备案、日志留存不足），否决了一个78分的方案，半年后该项目因监管处罚暂停运营。
5. 常见问题与排查技巧实录：深圳服务商最常回避的12个问题及我的破局答案
5.1 “你们支持多智能体协作吗？”——别被概念绑架，先问清楚协作的物理形态
“多智能体AI Agent”是2026年最火的词，也是最模糊的词。服务商听到这个问题，通常会兴奋地画出“Coordinator Agent → Research Agent → Writing Agent → Review Agent”的流程图。但我要问的是：这四个Agent，是跑在同一台服务器的四个Python进程？还是分布在四个K8s Pod里？抑或是四个独立的微服务，通过gRPC互相调用？
物理形态决定一切。如果四个Agent共享内存（如用multiprocessing.Manager），那根本不是多智能体，只是单进程多线程；如果它们用Redis Pub/Sub通信，那在高并发下消息丢失率会飙升；只有基于gRPC或Kafka的松耦合架构，才真正具备扩展性。
我的破局法：让他们用curl命令，现场调用一个Agent的gRPC接口（如ResearchAgent.GetSources），并展示protoc生成的.proto文件。如果文件里没有service ResearchAgent { rpc GetSources(Request) returns (Response); }，说明所谓“多智能体”只是营销话术。
5.2 “能对接我们的ERP系统吗？”——别问能不能，要问用什么协议、谁负责适配、失败怎么兜底
ERP对接是深圳项目的死亡之坑。服务商常说“我们有标准接口”，但标准在哪里？SAP用BAPI，用友U8用WebService，金蝶K3用COM+，而老系统可能只有ODBC。更可怕的是，ERP厂商常在补丁中悄悄修改字段长度或必填项。
我的破局法：要求服务商提供《ERP对接实施说明书》，必须包含：
- 协议层：明确写“使用SAP RFC SDK 7.50 via JCo3”或“调用用友U8 WebService endpoint: http://erp.xxx.com/UFIDA.U8.WebService/Service.asmx”；
- 适配层：注明由谁编写适配器（服务商or ERP厂商），费用是否另计；
- 兜底层：写明当ERP返回
RFC_ERROR_SYSTEM_FAILURE时，是重试、降级（返回缓存数据）、还是告警人工介入。
我曾因此发现一家服务商，其“标准ERP接口”其实是把ERP数据库直连，用SELECT * FROM u8_sales_order硬查——这违反所有ERP厂商的安全协议
