开发者公众号专属群聊

扫码加入获取更多一手教程、科技前沿报告

AI 写代码已经成为日常开发中的常见能力，但在大型系统改造中，代码生成并不是交付的最后难点。真正容易阻塞进度的，往往是验证。

本次项目需要在约两个月内完成一套大型项目登录系统的替换，同时正常需求开发不能停止。可以把它理解为：一边开着飞机，一边升级飞机内部系统。

登录系统是核心基础能力，涉及正常登录、Token 刷新、退出登录等主链路，也依赖 Redis、数据库等基础设施。尤其在 Redis 不可用、DB 不可用等异常情况下，系统是否能正确降级，直接关系到登录服务的稳定性。

但这类场景在公共环境中几乎无法验证。公共环境服务于数百人的开发协作，主动停止 Redis、断开数据库或修改关键配置，都可能影响其他同学的开发进度。另一方面，机器和运维资源有限，开发者也不一定熟悉 Kubernetes 的 Namespace、Deployment、Pod、ConfigMap 等概念。即使知道要验证什么，也常常被“环境起不来、依赖配不齐、没有权限动公共资源”卡在最后一公里。

预发环境的验证路径同样偏长。一次变更通常需要先合入公共分支，再协调相关同学完成审批，等待云端构建镜像和流水线执行，最后部署到预发环境。从发起到可验证通常需要 30 分钟至 1 小时。对于仍在快速试错、需要频繁验证边界条件的登录系统改造来说，这个反馈周期过长。

当登录挂了之后， 预发环境压力非常大。会有成百上千个企微消息轰炸你。

因此，我们希望解决的不是“让 AI 再多写一点代码”，而是：

让每位开发者都能低成本获得一套可控、隔离的验证环境，并在其中自主完成关键故障场景验证。

整体流程图：

   2.1 使用工具与模型

• AI 助手：通过预置 Skill 调用标准化构建流程，避免临时拼接复杂 Docker 命令。

• Makefile：固化镜像编译、构建与推送流程。

• Docker：构建服务镜像。

• CSGHub：承载镜像等研发资产。

• Helm：沉淀服务部署配置。

• Kubernetes：承载独立验证环境。

• 小 TKE：团队自建的轻量化 K8s 管理平台，通过前端界面管理镜像、Workload、ConfigMap 等资源。

   2.2 思路：AI 不替代验证，而是润滑验证链路

最初，一个看似直接的思路是：让 AI 按需执行 Docker、Helm、kubectl 命令，完成构建和部署。

但实际使用中，我们发现这种方式并不理想：

• 不同服务的 Dockerfile、构建上下文、镜像名称和标签规则不同；

• 部分服务涉及多架构镜像；

• AI 临时拼接命令虽然可行，但不够稳定、难以审查，也不利于团队长期复用；

• K8s 部署本身仍然要求使用者理解大量概念和命令。

因此，我们没有让 AI 成为“自由执行命令的操作员”，而是将高频、关键且易错的操作固化为受约束的工作流。

核心原则是：

给 AI 一个可复用、可审查、边界清晰的操作入口，而不是让它每次从零生成一串命令。

   2.3 第一步：用 Makefile 固化“代码到镜像”的路径

我们将镜像构建和推送流程沉淀到 Makefile 中。开发者或 AI 不需要记忆完整的 Docker 构建参数，只需调用约定好的目标即可，例如：

make loginmake idsvcmake keycloak-bridgemake keycloak-clusterless

每个目标统一完成以下动作：

1. 使用指定 Dockerfile 和固定构建上下文构建镜像；

2. 按统一规则生成镜像 Tag；

3. 推送镜像到 CSGHub 镜像仓库；

4. 输出可用于部署的镜像地址和 Tag。

对于存在多架构要求的服务，构建流程也在 Makefile 中统一处理，避免开发者或 AI 在临时操作中遗漏架构、标签等细节。

在此基础上，我们为 AI 编写 Skill，让 AI 在明确约束下调用 Makefile。这样，AI 的作用不是“猜应该执行什么命令”，而是帮助开发者快速触发标准动作、读取构建结果，并在失败时辅助分析日志和定位问题。

这里我们刻意没有先搭建一套完整的镜像构建流水线。当前项目真正需要的是开发者能快速、独立地构建并验证变更，而不是引入新的共享构建机、流水线维护成本和排队等待。因此，我们选择了朴实的 Makefile：本地构建、统一入口、直接推送镜像仓库。它不一定最“平台化”，但在当前阶段足够可靠，也更贴合开发节奏。

不过，在把 AI 嵌入工作流时，我们也遇到了一个很现实的问题：AI 的响应可能较慢，执行也存在不稳定性；当 Skill 描述仍然模糊、使用者又不了解相关知识时，单靠对话式操作并不可靠。

例如，团队新人刚开始使用 AI 协助部署时，AI 曾误创建多个 Namespace。由于环境中同时存在多套 K8s 集群，新人在让 AI 执行测试时，也容易进入错误的集群。Namespace、集群、Workload、Pod、ConfigMap 等大量术语会迅速淹没不熟悉 K8s 的使用者。新人无法判断 AI 当前操作的目标和影响范围，只能在出现问题后再寻求协助。

这让我们明确了一点：Skill 适合承载已经收敛、边界明确的标准动作，但不应该把所有复杂性都暴露给使用者。对于高频、确定的部署与验证操作，一个简单直观的工具界面，往往比模糊的 Skill 和多轮对话更可靠。

   2.4 第二步：用小 TKE 降低 K8s 环境使用门槛

镜像构建完成后，下一步是部署验证环境。

如果直接要求每位开发者使用原生 K8s 或完整 TKE 平台，需要理解 Namespace、Deployment、Pod、Service、ConfigMap 等概念。对于不熟悉 K8s 的同学，学习和排障成本很高；而项目采用两个月倒排计划，团队没有充足时间让所有人先补齐完整的容器编排知识。

因此，我们基于已有的 Docker、Helm 和 K8s 资产，结合 CSGHub + AI 快速搭建了轻量化管理平台“小 TKE”。

小 TKE 通过前端页面提供：

• 镜像选择与版本管理；

• Workload 部署和更新；

• Helm Chart 部署；

• ConfigMap 等配置资源管理；

• 多集群接入与资源查看。

小 TKE 架构：公共平台统一操作，资源仍部署在个人 DevCloud

小 TKE 本身是部署在一台公共机器上的轻量化平台，负责提供统一的操作页面和部署入口；它不承载开发者实际要验证的业务资源。

平台通过接入每位开发者 DevCloud 环境对应的 Kubernetes kubectl API，代表开发者执行查询、部署和更新等受控操作。最终的 Workload、Pod、Service、ConfigMap 以及 Redis、DB 等依赖资源，仍然部署在各自的 DevCloud 机器中，并与其他开发者的环境保持隔离。

开发者浏览器      ↓公共机器上的小 TKE 平台      ↓  调用对应 DevCloud 的 Kubernetes kubectl API开发者个人 DevCloud 机器      ↓个人独立的 Namespace / Workload / Pod / 配置 / 依赖资源

这种架构将“平台入口统一”和“验证资源按人隔离”结合起来：开发者无需直接面对复杂的 kubectl 命令和 K8s 概念，但每个人的验证资源仍留在自己的 DevCloud 环境中，避免相互影响。

开发者不需要从零编写复杂 YAML，也不需要手动执行大量 kubectl 命令，即可将刚刚构建的镜像部署到 DevCloud 网络中的独立环境。

下图展示了小 TKE 的镜像更新界面：开发者可在 Workload 列表中选择目标服务，并从镜像仓库选择指定 Tag 完成更新。截图已对 Namespace、镜像地址等敏感信息进行了打码处理。

由于涉及内部集群、镜像仓库和部署权限等安全边界，小 TKE 工具本身不对外分享；本文分享的是其背后的实践思路和可复用方法：将团队已沉淀的 Dockerfile、Helm、Makefile 与 AI Skill 组合起来，降低独立环境部署和验证的门槛。

对于新人来说，这种界面化能力的价值尤其直接：不必先理解所有 K8s 术语，也不必依赖 AI 在多轮对话中决定操作路径。只要在明确的环境中选择镜像并完成部署，再使用 curl 调用接口验证结果，就能完成最基础、也最关键的测试闭环。

   2.5 第三步：在独立环境中验证登录系统的边界与降级场景

有了独立环境后，验证不再只能依赖公共环境。

登录系统的验证范围包括：

• 正常登录；

• Token 刷新；

• 退出登录；

• Redis 不可用时的降级行为；

• 数据库不可用时的降级行为；

• 配置变更、镜像升级后的服务行为。

其中，Redis 和 DB 故障验证尤其重要。过去，这类验证不适合在公共环境执行：公共环境中任何关键依赖异常，都可能影响数百人的研发进度。

现在，开发者可以在自己的环境中部署对应服务和依赖，再通过停止或调整 Redis、DB 等依赖资源，验证登录系统在异常状态下是否符合预期。例如：

代码修改→ AI 按 Skill 调用 Makefile 构建并推送镜像→ 在小 TKE 中选择新镜像并部署到独立环境→ 验证正常登录、Token 刷新、退出登录→ 模拟 Redis 或 DB 不可用→ 检查登录系统的降级行为、日志和接口返回→ 修复问题后重新构建、部署、验证

   2.6 第四步：为定位 Token 鉴权问题，构建刚好够用的小工具

除了环境验证，我们还遇到了一个更细粒度的“最后一公里”问题。

我主要负责 Token 相关功能，而原有 Token 能力沉淀在 Keycloak 中。改造初期，现有 Token 中有哪些 Claim、各个接口依赖哪些字段，缺少完整文档，也没有足够的人力支援。我们只能从最小 Claim 集合开始，逐步补齐字段。

在这个过程中，一旦某个接口返回 401 或 403，排查成本很高：问题可能来自 Token 签发时缺少或错误设置了 Claim，也可能来自接口自身的鉴权逻辑、角色映射或其他配置。仅靠阅读代码和反复改造后重新登录，定位周期很长。

为此，我借助 AI 快速构建了一个 Token 重新签发工具。在受控测试环境中，工具可使用经授权的测试密钥，导入已有 Token 并按需修改 Claim，再重新签发一个符合预期的测试 Token。

这样，排查路径从：

修改 Token 签发代码→ 构建并部署服务→ 重新走登录流程→ 调用接口，看到 401 / 403→ 猜测是 Token 问题还是鉴权问题

变为：

导入测试 Token→ 仅修改一个待验证的 Claim→ 重新签发测试 Token→ 直接调用目标接口→ 根据结果判断问题在 Token 签发还是接口鉴权

这个工具并不追求覆盖所有 Token 场景，更不是要替代通用身份认证平台。它的目标非常明确：缩短当前迁移项目中 Token 问题的定位链路，让开发者能够快速验证假设。

   2.7 第五步：解密 Session，结束“靠猜”排查

另一个高频痛点来自 Cookie 中的 Session。Session 为了安全会以加密形式存储在 Cookie 中，开发者在排查登录态、会话续期或权限异常时，无法直接看到其中承载的会话信息。

过去遇到问题时，通常只能根据接口现象、日志和代码路径推测：是 Session 本身不符合预期、会话已失效，还是服务端读取、鉴权逻辑出现问题。这个过程依赖经验，也容易把排查带偏。

因此，我们又借助 AI 构建了一个 Session 解密工具。该工具仅面向受控测试环境，使用经授权的测试配置解密 Cookie 中的 Session，使研发人员能够快速查看会话内容，并结合接口返回和日志定位问题。

排查方式从：

接口异常→ 根据现象猜测 Session 是否有问题→ 反复修改代码、重新部署、重新登录→ 继续观察结果

变为：

导入受控测试环境中的 Session Cookie→ 解密并查看会话内容→ 对照预期字段、接口返回与日志→ 快速判断问题在 Session、Token 还是服务端鉴权逻辑

它和 Token 重新签发工具一样，不是为了打造一个通用的身份认证调试平台，而是为当前项目提供一个能快速验证假设、缩短定位链路的专用工具。

   核心成果量化对比

本次实践的核心成果，不只是“验证更方便”，而是将验证链路中的时间、人力和网络资源利用率转化为可观察的变化：

这里的“约 5 分钟”指开发者完成本地镜像构建、推送并在小 TKE 更新独立环境后，可以开始接口验证的时间，不包含复杂问题修复后的后续迭代时间。

1、让过去“不敢测、不能测”的故障场景真正可测

Redis、DB 不可用等场景不再需要在公共环境中冒险操作。开发者可以在独立环境中主动制造依赖异常，验证登录系统的降级逻辑，避免将未知风险带到公共环境或生产链路。

这使登录系统迁移不只验证“正常功能是否可用”，还能够验证“异常情况下是否按预期工作”。

2、将部署准备时间从 30 分钟至 1 小时缩短至约 5 分钟

原先走预发环境时，开发者需要经历合入公共分支、协调审批、等待云端构建和流水线部署等环节，从发起变更到开始验证通常需要 30 分钟至 1 小时。

现在，开发者可以在本地通过 Makefile 构建并推送镜像，再通过小 TKE 将指定镜像部署到自己的独立环境，约 5 分钟即可开始验证。按原有 30 分钟至 1 小时的准备时间计算，单次验证准备时间缩短约 83% 至 92%。

这意味着开发者可以在一次开发会话内完成更多轮“修改—构建—部署—验证”，把原本等待环境的时间用于修复和验证问题。

3、将运维从逐次支撑中释放出来，开发者自主完成日常验证

过去，涉及环境部署、依赖调整或 Redis、DB 故障模拟的验证，往往需要协调公共环境、申请操作窗口，必要时还需要运维协助。每次验证都依赖跨角色沟通，不仅拉长等待时间，也会占用有限的运维资源。

改造后，开发者可以在独立环境中自行完成镜像部署、配置调整和依赖故障模拟。日常验证基本不需要运维介入；只有进行跨地域测试等少数场景时，才需要运维协助，而不是重复参与每一轮构建、部署和验证。

这让运维从高频、重复的验证支撑中释放出来，也使研发验证不再受公共环境和人工协调窗口限制。

4、降低 K8s 使用门槛，缩短验证准备路径

过去，开发者想完成环境部署，需要熟悉镜像构建、镜像推送、Helm、K8s 资源以及配置管理等多个环节。

现在，构建环节由 Makefile 固化，AI 可按 Skill 协助触发；部署环节由小 TKE 的界面化能力承接。即使不熟悉 K8s 的同学，也可以围绕“选择镜像—配置部署—查看资源—开始验证”的路径完成操作。

团队不需要等所有人掌握完整 K8s 知识后再开始验证，而是可以先通过平台能力完成交付所需的核心动作。

5、充分利用 DevCloud 本地网络，团队利用率达到 100%

本地构建、镜像推送、独立环境部署和服务联调均在 DevCloud 网络内完成，避免为了验证频繁等待外部公共环境的构建和部署链路。

目前，团队对 DevCloud 网络资源的利用率已达到 100%：参与该改造的开发者均通过这条网络内闭环完成环境部署和验证。DevCloud 不再只是可用但闲置的基础设施，而成为支撑高频验证、多人并行联调和故障演练的日常研发资源。

6、把 AI 从一次性提效变为团队可复用能力

本次实践中，AI 的价值不只是加速平台代码开发，而是帮助我们把重复、易错的构建操作收敛为标准入口。

沉淀后的能力包括：

• 面向多个服务的镜像构建与推送 Makefile；

• 面向 AI 的受约束 Skill；

• 面向开发者的轻量 K8s 管理界面；

• 可在独立环境中执行的登录系统验证流程。

• 面向受控测试环境的 Token 重新签发工具。

• 面向受控测试环境的 Session 解密工具。

这些能力可以继续服务后续服务改造、灰度验证和故障演练，而不是只解决一次迁移任务。

7、工具的四个直接收益

这套工具的目标不是做一个“大而全”的平台，而是用最小成本解决当前项目中最阻塞验证的环节。它带来了四个直接收益：

1. 服务新人，降低知识门槛
   新人不需要先掌握完整的 K8s、Helm 和集群运维知识。可以从最基础的 HTTP 验证开始：选择环境、部署镜像、使用 curl 调用接口、观察结果。在完成任务的过程中，再逐步理解 Namespace、Workload、Pod 等概念。

2. 支持极端场景验证，不影响公共集群
   Redis、DB 不可用等故障场景可以在个人独立环境中构造，不会影响公共测试集群中的其他同学，也不需要频繁协调运维资源或申请特殊操作窗口。

3. 方便多人协作与跨平台对接
   登录系统改造需要对接不同的平台和依赖。通过统一的构建资产与轻量管理界面，团队可以按当前项目需要组合服务、配置和集群资源，快速构建用于联调或验证的特殊环境，降低跨团队协作成本。

4. 本地构建更快，不共享构建机
   构建通过 Makefile 在本地完成，不依赖共享构建机和复杂流水线，减少排队、抢占资源和等待反馈的时间。原先走预发环境时，需要合入公共分支、协调审批、等待云端构建和流水线部署，从发起到开始验证通常需要 30 分钟至 1 小时；现在开发者可在本地构建镜像并通过小 TKE 部署到独立环境，约 5 分钟即可进入验证，单次准备时间缩短约 83% 至 92%。开发者可以在修改后立即完成“构建—部署—验证”，并快速进入下一轮迭代。

8、将 Token 排查从“靠猜”收敛为一次控制变量验证

过去，面对 401、403 等问题，团队无法直接确认 Token 中某个 Claim 是否缺失或错误，只能通过“修改 Token 签发代码—构建部署—重新登录—调用接口”的多轮循环观察现象，排查结论很大程度依赖猜测。

Token 重新签发工具让我们可以控制变量验证 Claim 对鉴权结果的影响：导入测试 Token 后，只修改一个待验证的 Claim，重新签发并直接调用目标接口。原本需要反复修改、部署和登录的排查，收敛为一次控制变量验证，并可依据实际 Token 内容和接口返回得出结论。

面对 401、403 等问题，团队能够快速区分：

• 是 Token 缺少必要 Claim，或 Claim 值不符合预期；

• 还是接口自身的鉴权、角色映射或配置存在问题。

这类工具的价值不在于功能多，而在于它用可观察、可复现的事实替代猜测，直接消除当前项目中最耗时的一段排查路径。

9、让加密 Session 的排查从猜测转为可观察

Session 解密工具为受控测试环境中的会话排查提供了直接观察入口。过去，Cookie 中的加密 Session 无法直接查看，研发人员只能结合接口现象、日志和代码路径推测。现在，面对登录态、续期或权限异常时，可以先确认 Session 中的实际内容，再判断后续应检查 Token、会话状态还是服务端鉴权逻辑。

这减少了“先改代码、再部署、再猜测”的无效循环，也让问题定位建立在可验证的事实之上。

1、AI 的价值不应只停留在“写代码”

在高风险系统改造中，代码生成只是开始。真正决定交付速度和质量的，是是否能快速、低成本地验证代码在真实依赖和异常条件下的行为。

AI 可以帮助团队把构建、部署、排查等流程连接起来，润滑从“代码完成”到“验证完成”的最后一公里。

2、不要让 AI 每次从零操作，要给它标准入口

对于镜像构建、推送等关键操作，直接让 AI 临时生成 Shell 命令并不稳定。更好的方式是：

• 人先将流程收敛为 Makefile、脚本或 Skill；

• 明确输入、输出和执行边界；

• 再让 AI 在约束内调用这些能力。

这样既能提高效率，也能保证过程可复用、可审查、可维护。

3、Skill 不等于产品界面，确定性操作应优先工具化

AI 和 Skill 很适合处理开放式问题，例如解释构建失败日志、生成初步方案、辅助定位异常。但当操作对象涉及集群、Namespace、部署资源等有明确边界的基础设施时，模糊的自然语言指令可能带来不稳定和误操作。

尤其对于不了解 K8s 的新人，如果让他先理解海量术语，再判断 AI 实际进入了哪个集群、创建了哪个 Namespace，学习和验证成本都会很高。此时，工具界面把可选范围、操作对象和结果反馈直接呈现出来，能让使用者依靠最基础的计算机操作完成任务：

选择正确环境→ 选择镜像 Tag→ 部署 Workload→ 使用 curl 调用接口→ 根据返回结果完成验证

因此，我们的分工是：用 命令 固化构建等标准入口，用 AI 处理解释和辅助排障，用平台界面承接需要稳定、直观、可控的部署操作。

4、轻量工具不必完美，能缩短关键流程就有价值

有人会问，为什么不直接等现有平台提供能力，或者先找一个成熟的开源软件？

但在两个月倒排、业务改造和日常需求并行的情况下，等待一个通用平台排期并不现实。通用工具也通常无法完全贴合当前项目的部署方式、依赖关系和验证路径。团队真正需要的是贴合当前验证流程的轻量能力：让不熟悉 K8s 的开发者也能快速部署、配置和验证。

小 TKE、Token 重新签发和 Session 解密工具都不是要成为适用于所有项目的通用产品。前者依赖 Dockerfile、Helm 等部署资产已经沉淀的前提，离开当前项目未必能直接复用；后两者则只聚焦当前 Token、Session 与鉴权问题的快速验证。

但在当前几个月的项目周期内，它们恰好解决了团队的刚需。AI 降低了构建这类“小而专”工具的成本，让我们不必等待一个完美、通用的方案，而是可以先解决最阻塞交付的问题。

一个好工具不一定功能最全、适用范围最广；只要它能稳定地缩短团队当前最关键的流程，它就是有价值的工具。

本次实践中的 Makefile、轻量小 TKE、Token 重新签发和 Session 解密工具，都是同一个原则的体现：够用就好，先让验证顺畅地发生。

本案例已沉淀以下可复用资产：

1. 镜像构建 Makefile

   统一封装多个服务的 Docker 构建、镜像 Tag 生成、镜像推送及多架构构建流程。

2. AI Skill

   将 AI 操作约束到标准 Makefile 工作流中，降低临时拼接命令带来的不确定性。

3. 小 TKE 平台实践方案

   平台提供多集群接入、Workload 管理、Helm Chart 部署、镜像和 ConfigMap 管理等能力，帮助非 K8s 专业开发者快速部署独立环境。由于涉及内部集群、镜像仓库与部署权限，工具本身不对外分享；可复用的是其工作流设计和构建、部署资产的组织方式。

4. 项目维度的排障与验证小工具

   团队可将日常排障中反复出现、但难以快速观察和验证的问题，沉淀为项目专用工具。这类工具不追求跨平台、跨项目通用，而是围绕当前项目的技术栈、测试配置和真实问题缩短定位链路。Token 重新签发与 Session 解密工具就是两个例子：

• Token 重新签发工具：面向受控测试环境，支持按需调整 Token Claim 并重新签发，用于快速区分 Token 签发问题与接口鉴权问题。

• Session 解密工具：面向受控测试环境，使用经授权的测试配置解密 Cookie 中的 Session，辅助定位登录态、会话续期和鉴权问题。

后续也可以持续补充同类工具，让每个项目都具备贴合自身场景的排障和验证能力。

扫码领取腾讯云开发者专属服务器代金券！