验证 Harness：登录系统改造中 AI 润滑验证链路的工程实录（腾讯云开发者）¶

📊 Level ⭐⭐ | 13.1KB

验证 Harness：登录系统改造中 AI 润滑验证链路的工程实录¶

来源：腾讯云开发者，作者贾曼鑫，2026-09-22。腾讯某大型项目两个月倒排完成登录系统替换（Keycloak 沉淀的 Token 能力迁移），业务开发不停——「边开飞机边换引擎」。核心论点：大型系统改造中代码生成不是最后难点，验证才是；AI 的价值不在多写代码，而在润滑「代码完成 → 验证完成」的最后一公里。

摘要¶

登录系统验证的痛点不在功能本身，而在「不敢测、不能测」：Redis/DB 不可用等降级场景在服务数百人的公共环境几乎无法演练；预发路径（合入公共分支 → 审批 → 云端构建 → 流水线部署）从发起到可验证需 30 分钟至 1 小时。团队给出的解法不是让 AI 更强，而是把验证链路重组为五步：Makefile 固化构建入口 → AI Skill 约束调用 → 小 TKE 界面化部署 → 独立 DevCloud 环境做故障注入 → Token 重签发/Session 解密专用排障工具。结果：部署准备时间缩至 约 5 分钟（-83%~-92%），DevCloud 资源利用率达 100%，Token 排查从多轮「改码-部署-登录-猜测」收敛为一次控制变量验证。

背景与问题结构¶

登录系统涉及正常登录、Token 刷新、退出登录主链路，依赖 Redis、数据库；异常降级行为直接关系稳定性，但「主动停 Redis、断 DB」在公共环境会影响数百人协作——这类故障场景在公共环境中几乎无法验证。
开发者侧的两道门槛：K8s 概念门槛（Namespace/Deployment/Pod/ConfigMap 淹没不熟悉的同学）+ 预发反馈周期过长（快速试错期等不起 30min-1h）。登录挂掉时预发环境「成百上千个企微消息轰炸」。
问题重述：不是「让 AI 再多写一点代码」，而是让每位开发者低成本获得可控、隔离的验证环境，并在其中自主完成关键故障场景验证。

第一步：Makefile 固化「代码到镜像」路径 + AI Skill 约束调用¶

最初「让 AI 按需执行 Docker/Helm/kubectl 命令」的思路并不理想：各服务 Dockerfile/构建上下文/镜像标签规则不同、部分涉及多架构、AI 临时拼命令不稳定难审查难复用、K8s 概念门槛仍在。解法：将高频、关键且易错的操作固化为受约束的工作流——给 AI 一个可复用、可审查、边界清晰的操作入口，而不是让它每次从零生成一串命令。

Makefile 统一目标（make login / make idsvc / make keycloak-bridge / make keycloak-clusterless）：每个目标统一完成构建（指定 Dockerfile+固定上下文）、按统一规则生成 Tag、推送到 CSGHub、输出可部署镜像地址；多架构也在 Makefile 统一处理。
AI Skill 的角色：不是「猜应该执行什么命令」，而是触发标准动作、读取构建结果、失败时辅助分析日志定位问题。
刻意不建完整流水线：当前需要的是开发者快速独立构建验证，而非引入共享构建机、维护成本和排队等待——「朴实的 Makefile：本地构建、统一入口、直接推送」不一定最平台化，但足够可靠、贴合开发节奏。

关键教训：AI 误操作暴露 Skill 的边界¶

AI 响应慢、执行不稳定；Skill 描述模糊 + 使用者不熟悉领域知识时，对话式操作不可靠。实测案例：新人用 AI 协助部署时，AI 曾误创建多个 Namespace；多套 K8s 集群并存时新人容易进错集群。由此得到一条关键边界：Skill 适合承载已经收敛、边界明确的标准动作，但不应把所有复杂性暴露给使用者——对高频确定的部署与验证操作，一个简单直观的工具界面往往比模糊的 Skill 和多轮对话更可靠。

第二步：小 TKE —— 界面化部署 + 平台统一入口/资源按人隔离¶

基于已有 Docker/Helm/K8s 资产 + CSGHub + AI 快速搭建轻量化管理平台「小 TKE」：镜像选择与版本管理、Workload 部署更新、Helm Chart 部署、ConfigMap 管理、多集群接入。

架构分工：平台入口统一，验证资源按人隔离——小 TKE 本身部署在一台公共机器上，只提供统一操作页面和部署入口，不承载业务资源；通过接入每位开发者 DevCloud 环境对应的 Kubernetes kubectl API 代为执行受控操作；Workload/Pod/Service/ConfigMap 及 Redis/DB 依赖仍部署在各自 DevCloud 机器中互相隔离。链路：开发者浏览器 → 公共机器上的小 TKE → 调用对应 DevCloud 的 kubectl API → 个人独立 Namespace/Workload/Pod/依赖资源。

对新人的价值：不需要从零写 YAML 或手敲 kubectl，在明确环境选择镜像完成部署，再 curl 调用接口验证，即完成最基础的测试闭环。

第三步：独立环境故障注入 —— 把「不敢测」变成可测¶

验证范围：正常登录、Token 刷新、退出登录、Redis 不可用降级、DB 不可用降级、配置变更/镜像升级后行为。开发者在自己环境部署服务和依赖后，主动停止/调整 Redis、DB 验证降级逻辑，不再冒公共环境之险。完整链路：代码修改 → AI 按 Skill 调 Makefile 构建推送 → 小 TKE 选镜像部署独立环境 → 验证主链路 → 模拟 Redis/DB 不可用 → 检查降级行为、日志、接口返回 → 修复后重来。这条链路把原来依赖环境协调、运维支持和公共资源窗口的工作，前移为开发者可自主完成的验证闭环。

第四/五步：两个「刚好够用」的专用排障工具¶

Token 重新签发工具：Token 能力沉淀在 Keycloak，改造初期 Claim 清单缺文档，接口 401/403 时无法区分「Token 签发缺 Claim」vs「接口鉴权/角色映射问题」。工具在受控测试环境用经授权测试密钥导入已有 Token、按需修改 Claim 重新签发。排查从「改码 → 部署 → 重新登录 → 调接口看 401/403 → 猜」收敛为「导入 → 只改一个待验证 Claim → 重签 → 直接调目标接口 → 按结果定位」——控制变量验证。
Session 解密工具：Cookie 中加密 Session 无法直接查看，排查只能靠现象+日志+代码路径推测。工具面向受控测试环境，用经授权测试配置解密 Session，快速判断问题在 Session、Token 还是服务端鉴权逻辑。

两个工具都不是通用身份认证调试平台，只求缩短当前项目定位链路——「够用就好，先让验证顺畅地发生」。

成效（量化）¶

过去「不敢测、不能测」的故障场景真正可测：不只验证「正常功能可用」，还验证「异常情况按预期工作」。
部署准备 30min-1h → 约 5min（-83%~-92%）（本地 Makefile 构建+推送 → 小 TKE 部署独立环境；不含复杂修复后迭代时间），一次开发会话可完成更多轮「修改-构建-部署-验证」。
运维从逐次支撑中释放：日常验证基本不需运维介入，仅跨地域测试等少数场景需要。
K8s 门槛降低：构建由 Makefile 固化（AI 按 Skill 触发）、部署由界面承接，围绕「选择镜像—配置部署—查看资源—开始验证」即可操作。
DevCloud 资源利用率 100%：构建、推送、部署、联调全在网络内闭环，DevCloud 从闲置基础设施变成高频验证/并行联调/故障演练的日常研发资源。
AI 从一次性提效变为团队可复用资产：Makefile + 受约束 Skill + 轻量 K8s 界面 + 验证流程 + 两个排障工具，可服务后续改造/灰度验证/故障演练。
Token 排查从「靠猜」收敛为一次控制变量验证；Session 排查从猜测转为可观察——用可观察、可复现的事实替代猜测。

经验总结¶

AI 的价值不应只停留在写代码：高风险改造中真正决定交付速度的是「快速、低成本地验证代码在真实依赖和异常条件下的行为」。
不要让 AI 每次从零操作，要给它标准入口：人先将流程收敛为 Makefile/脚本/Skill，明确输入输出和执行边界，再让 AI 在约束内调用——既提效又可复用、可审查、可维护。
Skill ≠ 产品界面，确定性操作优先工具化：AI/Skill 适合开放式问题（解释失败日志、生成初步方案）；涉及集群、Namespace 等明确边界的基础设施操作，模糊自然语言指令会带来不稳定和误操作。分工原则：用命令固化构建等标准入口，用 AI 处理解释和辅助排障，用平台界面承接需要稳定、直观、可控的部署操作。
轻量工具不必完美，能缩短关键流程就有价值：等通用平台排期不现实，通用工具也难贴合当前项目部署方式；AI 降低了构建「小而专」工具的成本——「一个好工具不一定功能最全，只要能稳定缩短团队当前最关键的流程，它就是有价值的工具」。

验证 Harness：登录系统改造中 AI 润滑验证链路的工程实录（腾讯云开发者）¶