新增内容

2026-05-27 15:29:48 +08:00
parent e7c301023c
commit 81833de6ef
18 changed files with 643 additions and 2 deletions
--- a/.idea/csv-editor.xml
+++ b/.idea/csv-editor.xml
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="CsvFileAttributes">
+    <option name="attributeMap">
+      <map>
+        <entry key="\18-基础架构及交付部署特战队\10-飞书多维表格\offline-docs-v2\manifest.csv">
+          <value>
+            <Attribute>
+              <option name="separator" value="," />
+            </Attribute>
+          </value>
+        </entry>
+      </map>
+    </option>
+  </component>
+</project>
--- a/.idea/git_toolbox_prj.xml
+++ b/.idea/git_toolbox_prj.xml
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="GitToolBoxProjectSettings">
+    <option name="commitMessageIssueKeyValidationOverride">
+      <BoolValueOverride>
+        <option name="enabled" value="true" />
+      </BoolValueOverride>
+    </option>
+    <option name="commitMessageValidationEnabledOverride">
+      <BoolValueOverride>
+        <option name="enabled" value="true" />
+      </BoolValueOverride>
+    </option>
+  </component>
+</project>
--- a/15-CICD工具选型/1-开源工具选型.md
+++ b/15-CICD工具选型/1-开源工具选型.md
@@ -6,14 +6,14 @@
    4. 支持maven并发构建
    5. 构建缓存支持较好
    6. 支持多分支构建
-    6. 至此gravvl vm构建
+    7. 至此gravvl vm构建
 2. 灵活的构建参数
 3. 灵活的服务器调度
 4. 需要又灵活的集成策略
    1. 构建信息需要向外传递
 5. 主流的脚本语法
 6. 良好的文档、生态支持
-7. 有接口暴露API，能够进行二次开发
+7. 有良好的接口暴露API，能够进行二次开发
 8. 支持私有化部署

 最好是开源免费的CI CD工具，也可以对比付费的构建工具 如TeamCity等, 我们现在使用的是Jenkins工具。
--- a/15-CICD工具选型/4-CICD选型-260525.md
+++ b/15-CICD工具选型/4-CICD选型-260525.md
@@ -0,0 +1,139 @@
+# **企业级 CI/CD 现代化演进：GitLab CI、Tekton 与 TeamCity 架构深度评估与落地指南**
+
+随着企业业务规模的指数级增长，软件交付生命周期对持续集成与持续交付（CI/CD）基础设施的性能、可扩展性以及弹性提出了极为严苛的要求。在每年构建数量达到十万次量级的企业环境中，传统的自动化服务器（如 Jenkins）往往会遭遇严重的架构瓶颈。Jenkins 高度依赖于有状态的 Master-Agent 架构、极其庞杂且容易产生冲突的插件生态，以及缺乏类型安全的 Groovy 脚本范式（Jenkinsfile）。这些历史包袱在极高并发的构建场景下，不可避免地会导致配置漂移、内存泄漏、单点故障以及高昂的维护成本。
+为了突破这些交付瓶颈，基础设施的现代化演进必须向分布式、容器原生以及声明式的 CI/CD 平台进行范式转移。新的架构需要能够支撑高度异构的多语言构建、原生解决构建并发冲突、支持动态参数注入，并且必须完美适配企业级的私有化部署（On-Premises）安全规范。
+本报告围绕八个核心技术维度，对当前业界最具代表性的 CI/CD 平台进行深度技术剖析与横向对比。在开源免费工具阵营中，本报告甄选了深度整合的 GitLab CI 与完全基于 Kubernetes 理念构建的 Tekton；同时，引入 JetBrains 旗下的 TeamCity 作为商业闭源的行业标杆进行对标参考。报告不仅提供了详尽的维度评估矩阵，还针对“缓存优化”、“Maven 并发”与“外围系统回调”这三大核心痛点提供了深度的架构级解决方案，并最终输出了一套从 Jenkins 平滑迁移的工程化蓝图。
+
+## **1\. 候选平台架构拓扑解析**
+
+在进行多维度技术对比之前，必须深刻理解各候选平台底层架构拓扑的本质差异。CI/CD 工具的架构基因直接决定了其在应对十万级并发构建时的伸缩模型与稳定性边界。
+GitLab CI 代表了一种高度集成的 GitOps 架构哲学。它将源代码管理（SCM）与持续集成引擎无缝绑定，采用声明式的 YAML 语法进行流水线编排。其底层的执行引擎 GitLab Runner 采用了高度分布式的架构，特别是在配合 Kubernetes Executor 时，能够将每一个构建作业（Job）映射为 Kubernetes 集群中转瞬即逝的 Pod。这种架构最大程度地消除了构建节点的环境污染问题，是目前开源界普适性极强的现代化方案。
+Tekton 则代表了极致的云原生与 Serverless CI/CD 流派。作为 Continuous Delivery Foundation (CDF) 孵化的核心项目，Tekton 并不提供传统意义上的“中央调度服务器”。相反，它通过引入一系列自定义资源定义（CRD）——例如 Task、Pipeline、TaskRun 和 PipelineRun，直接对 Kubernetes API 进行了功能扩展。在 Tekton 中，CI/CD 的每一个步骤都被抽象为 Kubernetes 的原生对象，由 Tekton Controller 监听这些对象的状态变化并交由 Kubernetes 原生调度器执行。这种无服务器的解耦架构赋予了 Tekton 无与伦比的横向扩展能力。
+TeamCity 则是商业化集中式编排平台的性能巅峰。与 Jenkins 类似，它采用了中央服务器与分布式构建代理（Agent）的模型，但在架构的健壮性与智能化层面进行了重构。TeamCity 的核心优势在于其引入了 Kotlin 领域特定语言（DSL）作为 Pipeline as Code 的基础，提供了具有编译期类型检查的流水线编写体验。此外，TeamCity 内置了极为复杂的构建链拓扑算法、开箱即用的高级缓存启发式机制以及深度的测试智能分析引擎。
+
+## **2\. 核心技术维度深度评估**
+
+在每年十万次构建的压测下，任何微小的架构缺陷都会被无限放大。以下将围绕企业提出的八个核心诉求，对三款候选平台进行颗粒度极细的交叉评估。
+
+### **2.1 极致的构建能力与多环境隔离**
+
+企业级应用通常是由多种技术栈组合而成的庞然大物，要求 CI/CD 平台能够在一个流水线中灵活穿插不同版本的语言环境，并能应对极其消耗资源的编译任务。
+在多语言支持与环境切换方面，容器化是替代 Jenkins 笨重节点管理的首选方案。GitLab CI 允许在 YAML 文件的每个 job 级别通过 image: 关键字动态指定特定的 Docker 镜像。这意味着流水线的第一个阶段可以在搭载 Node.js的容器中执行前端构建，而第二个阶段可以瞬间切换到 OpenJDK的环境中进行后端编译，两者互不干扰。Tekton 将这种容器隔离推向了极致，其架构要求每一个 Task 中的 Step 都必须显式声明一个独立的容器镜像，这些容器在同一个 Pod 中顺序执行，通过共享的数据卷（Workspace）传递产物。TeamCity 则通过原生支持的 Docker Wrapper 技术，允许其代理节点在执行特定构建步骤（如专门的 Maven 或 Node.js 步骤）时，自动拉取并运行在指定的容器环境中，从而彻底避免了单台物理机上环境变量污染的顽疾。
+针对当下流行的 GraalVM 编译构建，由于其原生镜像（native-image）的生成过程涉及大量的静态代码分析与提前编译（AOT），极度消耗 CPU 与内存资源。在传统的 Jenkins 中，这极易导致节点内存耗尽从而引发 JVM 崩溃。在 Kubernetes 体系下的 GitLab CI 与 Tekton 中，系统架构师必须为处理 GraalVM 的作业显式配置 Kubernetes 的资源请求与限制（requests.memory 与 limits.memory），以防止过度消耗资源被调度器（OOMKilled）强制驱逐。业界最佳实践通常采用多阶段构建：使用庞大的 JDK/GraalVM 基础镜像进行编译，随后将二进制文件复制到极小的运行时镜像（如 distroless 或 Alpine）中以降低安全攻击面。在此维度上，TeamCity 提供了与 JetBrains IDE 的深度集成，不仅支持 GraalVM 构建，还通过预配置的 Docker 容器极大地简化了带有 Docker 的 GraalVM 原生镜像调试体验，甚至支持在 CI 环境中进行汇编级别的原生代码调试。
+在复杂多分支构建策略方面，GitLab CI 提供了卓越的原生支持，通过 rules 和 workflow:rules 语法，能够基于正则表达式、变量匹配以及分支命名规范，动态决定流水线的执行路径与跳过逻辑。TeamCity 通过其强大的 VCS 根配置与构建触发器系统，能够自动捕获代码库中的新分支并应用配置好的模板，同时通过“并行测试（Parallel Tests）”特性，能够基于历史构建统计数据，智能地将一个庞大的测试套件分割成多个批次，在多个 Agent 上针对不同分支进行并发测试，极大地缩短了反馈周期。Tekton 则通过 EventListeners 和 TriggerBindings 接收来自代码托管平台的 Webhook，利用强大的 CEL（Common Expression Language）拦截器对 payload 进行解析与分支条件判断，进而动态实例化对应的 PipelineRun。
+
+### **2.2 极其优秀且易于配置的构建缓存机制**
+
+在十万次构建的体量下，依赖包（如 Node.js 的 node\_modules 或 Java 的 .m2 仓库）的重复下载会造成惊人的网络带宽浪费与时间损耗。优秀的缓存机制是提升流水线效能的关键命题。
+TeamCity 在这一维度展现出了商业软件极其细腻的工程考量。其原生的“构建缓存（Build Cache）”功能抛弃了对外部对象存储的强依赖，转而采用一种高效的本地发布-订阅（Publisher-Consumer）模型。在 TeamCity 的构建步骤中，可以配置特定的目录（如 node\_modules/）作为缓存目标，并赋予其一个唯一的 Cache Name。当发布者（Publisher）配置成功运行完毕后，TeamCity 会将这些文件打包并作为隐藏构建工件（存储在 .teamcity.build\_cache 目录下）保存在代理服务器的本地磁盘中。在后续的构建或依赖该缓存的消费者（Consumer）构建触发时，TeamCity 的执行引擎会严格按照“解析依赖 \-\> 拉取源码 \-\> 下载缓存 \-\> 执行构建”的顺序，在代码编译前将缓存解压到工作目录。这种设计最大程度地利用了 Agent 的本地 I/O 性能，并通过限制缓存发布条件（例如仅当依赖树哈希值改变时发布）来防止磁盘空间的过度膨胀。
+相比之下，Tekton 的无服务器架构使得缓存的处理更加复杂。由于执行 Task 的 Pod 在运行结束后即刻被销毁，Tekton 必须依赖 Kubernetes 的持久化卷（Persistent Volume, PV）来实现缓存的跨构建保留。开发者需要定义 PersistentVolumeClaim（PVC）并在 PipelineRun 中将其作为 Workspace 挂载入容器。例如，在执行 Maven 构建时，需通过参数 \-Dmaven.repo.local=$(workspaces.maven-repo-cache.path) 将缓存目录硬编码指向该挂载卷。然而，由于缺乏原生的锁机制，当多个并行的 Task 试图同时读写同一个 PV 上的缓存卷时，会引发严重的数据竞争问题（此问题将在后续“痛点解决方案”章节详述）。
+GitLab CI 主要依赖于集中式的分布式缓存模型。其架构通过与 Amazon S3、MinIO 或 Google Cloud Storage 的深度集成，在每个 Job 启动时从远端拉取压缩的缓存包，在执行结束后计算差异并推送回对象存储。虽然这种设计完美契合了 Runner 的无状态与横向扩展需求，但在面对数百兆甚至数 GB 的 node\_modules 缓存时，网络传输的延迟往往会抵消缓存本身带来的时间收益。因此，在 GitLab CI 中，必须配合精准的 cache:key 策略（例如基于 package-lock.json 的 SHA 值）来避免不必要的网络开销。
+
+### **2.3 灵活的构建参数注入与动态交互**
+
+不可变的基础设施原则要求流水线必须支持在运行时通过外部参数进行动态调整，从而实现“一次构建，多环境部署”。
+GitLab CI 的“动态子流水线（Dynamic Child Pipelines）”机制在此领域具有统治地位。它允许父流水线通过执行 Python 或 Bash 脚本，基于代码库的实时状态（例如分析哪些微服务的代码发生了变更）动态生成一个 JSON 或 YAML 格式的 CI 配置文件（如 generated-config.yml）22。随后，使用 trigger 关键字和 include: artifact 指令，GitLab 会即时拉起一个完全由上述脚本当场构建的子流水线。这种设计彻底打破了静态 YAML 文件的限制，赋予了流水线极强的适应性，特别适合管理结构复杂的 Monorepo。
+Tekton 通过其 Custom Resource 的强类型约束实现了严谨的参数传递。每一个 Pipeline 和 Task 都可以定义 params，这些参数在触发时由 PipelineRun 注入。此外，Tekton 引入了 Results 的概念，允许一个 Task 在执行完毕后将特定数据（如镜像哈希值或动态生成的环境标签）作为结果输出，并隐式地传递给流水线拓扑图中的下游 Task。这种机制确保了流水线作为有向无环图（DAG）的数据流向清晰可见，但由于其声明式的特性，要在运行中途生成全新的 Task 节点在技术上是难以实现的。
+TeamCity 利用其 Kotlin DSL 的图灵完备特性，将动态参数化推向了编程语言的范畴。开发者可以在流水线代码中直接读取环境变量、使用循环结构（for loop）或条件判断，从而在流水线初始化阶段动态生成成百上千个同构的构建配置（BuildType）9。同时，TeamCity 的用户界面支持复杂的自定义参数类型，能够与 HashiCorp Vault 等外部凭据管理系统无缝对接，支持参数的继承与运行时覆写，极大地降低了安全配置的复杂度。
+
+### **2.4 高并发下的弹性伸缩与智能调度**
+
+对于万次/年的构建负载，静态的服务器资源分配注定会导致低谷期的资源闲置与高峰期的队列堵塞。
+GitLab CI 在 Kubernetes Executor 下的调度能力极强，但其真正的弹性威力需要结合 KEDA（Kubernetes Event-driven Autoscaling）来释放。在生产环境的最佳实践中，GitLab Runner 会在一个暴露的端口（如）上提供队列深度等指标，Prometheus 抓取这些指标后，通过 Prometheus Adapter 转化为自定义指标（Custom Metrics），最后由 KEDA 驱动 Horizontal Pod Autoscaler (HPA) 动态增加或减少负责执行具体构建作业的 Pod 数量。此外，GitLab 通过 tags 实现了精准的标签化路由，确保要求特殊硬件（如 GPU 用于机器学习模型训练，或特定网络区域的机器）的作业被准确路由至对应的节点池。
+Tekton 自身并不负责资源调度，这种“克制”正是其云原生哲学的体现。当 PipelineRun 被提交后，Tekton 控制器仅仅是负责创建对应的 Pod 规范，其余所有的亲和性（Affinity）、容忍度（Tolerations）、节点选择器（NodeSelectors）以及弹性伸缩机制，全部透明地委托给 Kubernetes 原生的调度组件（如 kube-scheduler）与集群自动伸缩器（Cluster Autoscaler 或 Karpenter）来处理。这种机制使得 Tekton 的并发上限直接等于底层 Kubernetes 集群的物理上限。
+TeamCity 提供了企业级的云配置文件（Cloud Profiles）集成，支持主动与 AWS、Azure、VMware 等公有云及虚拟化平台交互。其智能调度算法会实时监控构建队列，一旦发现队列等待时间超过预设阈值，且现有的 Agent 均被占用，TeamCity 会调用云端 API 自动分配新的虚拟机，部署 Agent 并将其注册到系统中；任务执行完毕后，系统会在设定的空闲时间后自动销毁虚拟机，实现精确的成本控制。其内置的资源耗尽检测机制更能有效预防构建死锁。
+
+### **2.5 强大的集成与解耦策略（事件回调）**
+
+大型企业拥有自建的研发效能平台、质量度量看板与统一通知中心。CI/CD 平台必须具备将极其丰富的状态数据向外投递的能力，且不应阻塞主流水线的运行。
+Tekton 拥有三者中最标准化的事件驱动架构。通过修改 TektonConfig 中的参数，可以全局启用 CloudEvents 投递。这使得任何一个 TaskRun 或 PipelineRun 在经历 Started、Running、Failed 或 Succeeded 状态转变时，Tekton 都会向预设的 Sink（如 Knative Eventing 代理或企业自建的消息队列总线）发送符合 CNCF CloudEvents 标准的 JSON 载荷。外围系统只需要解析这些标准化的载荷，便可精确重构整个集群的交付拓扑图，甚至触发诸如 Argo Workflows 之类的自动响应引擎（例如当构建失败扫描出高危漏洞时自动阻断网络配置）33。
+GitLab CI 的解耦主要依赖于项目级别的 Webhook。它可以在各种事件（如流水线事件、作业事件、部署事件等）发生时，向外部 URL 推送详细的上下文信息。此外，GitLab 允许在 API 调用触发流水线时传入任意的 CI/CD 变量，并且在流水线内部通过读取预定义的 TRIGGER\_PAYLOAD 变量文件来解析触发源的附加信息，从而实现双向的闭环数据交互。
+TeamCity 提供了名为“服务消息（Service Messages）”的独特底层机制，它要求在构建脚本的输出中打印特定格式的字符串（例如 \#\#teamcity\[notification...\]），TeamCity 服务器通过持续解析标准输出流来捕获这些指令，从而在不需要硬编码外部 API 的情况下，直接通过系统内置的功能发送 Slack 消息或更新外部状态。对于更复杂的系统对接，TeamCity 拥有高度可定制的 tcWebHooks 插件机制，不仅能监听多种系统级事件，还能利用内嵌的模板引擎组装出极其复杂且符合目标系统要求（如飞书、企业微信、Jira）的 HTTP POST Payload。
+
+### **2.6 现代化的脚本语法（Pipeline as Code）**
+
+从 Jenkins 迁移的核心驱动力之一，是摆脱那些冗长、难以调试且极易产生隐蔽报错的 Groovy 代码片段。
+GitLab CI 将 YAML 作为唯一配置语言，通过严谨的层次结构和预定义的关键词（如 stages、script、artifacts），极大降低了 DevOps 工程师的编写门槛。利用 include 关键字，企业可以建立包含安全扫描、合规检查等核心步骤的公共模板库，供上百个微服务仓库直接引用。
+Tekton 同样使用 YAML，但其语法的学习曲线极其陡峭。编写一段简单的流水线，通常需要定义多个层级的 Kubernetes Custom Resource，导致配置文件极度冗长。然而，这种“繁琐”换来的是与云原生架构的绝对一致性，它使得基础设施即代码（IaC）工具可以像管理微服务实例一样无缝地管理构建流水线。
+TeamCity 引入了改变游戏规则的 Kotlin DSL。与基于解释型文本的 YAML 或 Groovy 不同，Kotlin 是强类型的编译型语言。当开发人员在 IntelliJ IDEA 等集成开发环境中编写 TeamCity 流水线时，可以享受到完整的自动补全、语法高亮以及最关键的**编译期静态检查**。任何拼写错误或逻辑悖论在推送到代码库前就会被编译器拦截。此外，TeamCity 支持双向操作：用户可以在友好的图形界面中通过拖拽配置好一条复杂的流水线，然后点击“View as code”，系统会自动生成极其优雅、结构分明的 Kotlin 代码供用户直接提交入库，完美解决了可视化与代码化之间的隔阂。
+
+### **2.7 开放的 API 与二次开发生态**
+
+GitLab 提供了完备的 RESTful 与 GraphQL API，从创建仓库、触发流水线到获取具体某一阶段的构建产物，皆可通过接口全自动化完成。
+Tekton 的 API 即 Kubernetes API。它的生态优势在于依托于 CDF 基金会建立的 Tekton Hub，这里集中了由社区维护的各种高频复用的 Task 定义。通过编写 Kubernetes Operator 或使用 Go 客户端代码库，企业内部的效能平台可以直接将 Tekton 作为底层构建引擎进行深度定制。
+TeamCity 作为商业产品，除了提供丰富的 REST API 用于触发构建、管理队列负载和获取测试统计数据外，其自身的插件机制也允许开发者使用 Java 构建深度嵌入系统内部生命周期的功能扩展。
+
+### **2.8 部署架构支持**
+
+对于大型企业而言，数据主权与代码安全性不可妥协，这要求 CI/CD 工具必须支持完全的私有化（On-Premises）乃至物理隔离的物理气隙（Air-gapped）环境部署。
+三款工具均完美契合这一要求。GitLab CI 提供成熟的 Omnibus 包或 Helm Chart 进行自托管部署。Tekton 基于 Kubernetes，只需安装官方提供的 Tekton Operator 即可实现在任何本地 Kubernetes 集群（包括 OpenShift）上的私有化落户。TeamCity 则提供了跨平台的二进制安装包与 Docker 镜像，只需配合后端的外部关系型数据库（如 PostgreSQL），即可在物理机或私有云中稳定支撑数以千计的代理节点协同运作。
+
+## **3\. 痛点深潜：解决企业级构建的核心瓶颈**
+
+当每年构建频次达到十万次时，普通中小型团队极少遇到的极端边界问题将成为吞噬计算资源的黑洞。在架构设计中，必须针对缓存复用、并发控制与系统集成提供针对性的工程解决方案。
+
+### **3.1 痛点一：缓存优化极致提效方案**
+
+无论是 Node.js 庞大的 node\_modules 还是 Java 深不见底的 .m2 依赖树，在多阶段、分布式的容器环境中重建这些依赖将耗费% 到% 的总流水线时长。
+**解决方案：**
+
+* **TeamCity (本地 Publisher-Consumer 体系)：** 为了避免依赖云存储造成的网络 IO 瓶颈，TeamCity 的缓存策略是在代理本地构建闭环。通过设定一个前置的 Build Cache 发布者步骤，收集特定路径的文件，作为隐藏制品 .teamcity.build\_cache 打包存储在同一 Agent 的安全空间中。后续需要该缓存的构建步骤被调度到该代理时，系统会在源码 Checkout 之前自动将其解压回挂载目录，实现毫秒级的依赖命中。
+* **Tekton (PVC 挂载复制)：** 在 Tekton 的云原生世界中，Task 的 Pod 用完即毁。因此，最佳实践是分配持久卷 PVC 作为 Workspace 传递给 Task。在执行 npm ci 的容器启动前，编写一个前置脚本：首先检查挂载卷中是否存在历史 node\_modules，若有则将其原封不动地 cp（复制）到当前工作目录，再执行安装更新，最后检查改动并将增量变更覆盖回持久卷。这种方法利用了底层存储后端的读写性能，规避了反复的网络下载。
+
+### **3.2 痛点二：解决 Maven 本地仓库的高并发冲突**
+
+当业务线大量采用微服务架构时，为了追求极致速度，常常会将多个互相没有依赖关系的 Maven 模块在一个管道的并行阶段中同时触发。然而，原生的 Maven 缺乏对本地仓库 .m2/repository 的跨进程并发写入控制。当多个 JVM 进程同时尝试拉取并向相同位置写入同一个基础依赖 Jar 包或更新 maven-metadata-local.xml 时，极易导致写入竞争，引发经典的 ZipException: zip file is empty（Zip 文件为空）异常，最终导致整个流水线雪崩。
+**解决方案：**
+
+* **引入 Redisson 分布式命名锁：** 从 Maven Artifact Resolver.7+ 及 Maven.9.0 开始，架构上通过 maven-resolver-named-locks-redisson 模块彻底解决了这一难题。企业架构师可以在 CI 集群（如 Kubernetes 或专用物理机组）中单独拉起一个常驻的 Redis 实例。在 CI 容器启动时注入特定的环境变量配置，使得所有的并发 Maven 进程在尝试写入底层磁盘前，必须向该 Redis 实例申请对应的依赖包全局写锁。一旦检测到某个基础包正在被另一个构建线程下载，当前线程将进入安全等待状态，从根本上消灭了并发破坏文件完整性的可能。
+* **使用现代化的 Maven Daemon (mvnd)：** 为了兼顾并发安全与性能极速，更前沿的做法是弃用传统的 mvn 命令，转而使用 Apache maven-mvnd。mvnd 创新性地包含了一个基于 GraalVM 构建的极速本地 CLI 客户端与一个常驻后台的 Maven 守护进程池。由于守护进程是一个生命周期跨越多个连续构建任务的后台程序，它不仅能复用 JIT 编译器的热点代码（HotSpot）大幅度降低 JVM 的冷启动惩罚，更重要的是，它在单节点内部隐式地维护了一个同步队列，以极其高效且安全的方式统筹多个子模块的并发下载与写入操作。
+
+### **3.3 痛点三：外围系统状态回调与全链路可观测性集成**
+
+随着内部系统的演进，安全扫描告警、部署核准平台、资产管理 CMDB 以及自研的研发效能看板，都需要实时获悉 CI 流水线的精细状态。
+**解决方案：**
+
+* **Tekton CloudEvents 推送引擎：** Tekton 利用 CNCF 的标准协议，在其核心配置参数（TektonConfig）中绑定一个远程 Sink URL，开启基于 CloudEvents 格式的高级回调。这并不需要修改流水线内业务代码。任何一个 PipelineRun 或 TaskRun 在生命周期状态变迁时，控制器会自动把诸如“开始时间”、“执行节点”、“阶段性结果输出”等元数据统一封装进标准 JSON 并进行广播。下游平台利用 Serverless 中间件（如 Knative）进行事件的监听与消费，实现了真正意义上的解耦与微服务级的可观测性链路打通。
+* **TeamCity Service Message 及自定义 Webhook：** 对于 TeamCity，除了传统的利用 tcWebHooks 插件通过直观的 WebUI 配置包含大量 TeamCity 内部变量（如 ${buildStatusUrl}）并组装为符合下游格式（例如飞书卡片或 MatterMost 消息）的 payload 以外；它还具备一种原生解耦方案。在其构建脚本中，任何脚本只需要通过 echo "\#\#teamcity\[notification...\]" 将信息抛出至标准输出流。TeamCity 的运行时代理解析器会截获这一特殊字符序列并自动发起向外部 API 的调用。这种方式巧妙地避免了在构建业务代码中硬编码繁杂的 curl 网络交互逻辑与鉴权 Token，大幅提升了脚本的纯粹性与安全性。
+
+## **4\. 深度横向对比矩阵**
+
+通过对候选系统各维度的深度穿透，以下汇总提供适用于基础设施选型决策的横向优劣势对比雷达图（以表格呈现）：
+
+| 核心评估维度 | Jenkins (现有基线现状) | GitLab CI (全栈开源方案) | Tekton (云原生 K8s 方案) | TeamCity (商业化对标方案) |
+| :---- | :---- | :---- | :---- | :---- |
+| **极致构建支持** | 跨版本工具链常因节点环境变量污染造成构建混乱，插件脆弱。 | **优**；支持基于 Job 级别的独立 image 动态分配隔离环境。 | **优**；颗粒度达到 Step 级别的容器化设计，彻底杜绝环境污染。 | **优**；深度 Docker Wrapper 以及对 GraalVM 本地调试的完美支持。 |
+| **参数与多分支** | 重度依赖 Parameterized 插件及 Groovy 动态赋值，多分支维护复杂。 | **极优**；支持动态生成 YAML 的子流水线机制与强大的规则引流。 | **良**；支持强类型参数传递，但动态生成拓扑较为困难，高度结构化。 | **极优**；Kotlin DSL 可实现完全通过编程控制的分支遍历及动态实例生成。 |
+| **弹性服务器调度** | 节点增减依赖静态配置，易形成闲时浪费或忙时死锁。 | **极优**；配合 KEDA 与 Prometheus 监控队列实现秒级的 HPA 弹性伸缩。 | **极优**；依托 Kubernetes 原生调度器及自动伸缩机制处理高并发。 | **优**；通过云配置文件实现按历史运行时长统计与节点模板智能调度伸缩。 |
+| **现代脚本语法** | 命令式的 Groovy DSL，极其容易发生代码漂移与单点依赖。 | **优**；声明式 YAML 结合强大的 include 模板导入降低维护门槛。 | **良**；YAML 语法（CRD 配置极其繁琐且存在一定学习陡坡）13。 | **极优**；编译型强类型 Kotlin DSL，带来原生 IDE 检查校验与代码安全。 |
+| **构建缓存机制** | 缺乏统一抽象，通常需自己编写清理与预取脚本，导致磁盘溢出。 | **良**；分布式对象存储模式，依赖网速并可能抵消时间收益。 | **良**；依赖挂载 PVC 卷传递，需配合第三方并发锁工具防损坏。 | **极优**；内置基于本地高性能 I/O 的发布/消费者隐藏工件分发机制。 |
+| **事件通知回调** | 通常通过插件封装，难以针对复杂的 JSON Payload 进行高度定制。 | **优**；原生的项目级 Webhook，自带大量内置状态变量注入。 | **极优**；基于标准的 CNCF CloudEvents 与外部平台架构打通解耦。 | **极优**；服务消息劫持以及极高模板定制能力的 tcWebHooks 扩展。 |
+| **生态及私有化** | 插件众多但质量参差不齐，运维黑盒；支持物理机部署。 | 全栈级支持私有化部署；社区覆盖面广但容器要求高。 | 构建于 Tekton Hub 之上；强绑定 Kubernetes 环境方可私有化运行。 | 包含丰富的 JetBrains 集成体系，完备的商业文档；兼容气隙隔离环境。 |
+| **Maven 并发安全** | 原生构建容易因依赖冲突使 .m2 内的 metadata.xml 发生乱码损坏。 | 基于隔离容器运行，但并行写入同一共享网络卷仍存在隐患。 | 面临同一挂载 Workspace 下的严重竞争，需使用 Redisson 分布式锁。 | Agent 级的缓存同步解压隔离了直接的目录写入冲突，稳定性较好。 |
+
+## **5\. 迁移成本评估与架构平滑过渡建议**
+
+在每年十万次的巨大吞吐量下进行 CI/CD 引擎的核心替换，等同于在高速飞行的客机上更换发动机。总体拥有成本（TCO）不仅包括新软件的基础设施支出，更在于对已有庞大流水线资产的重构代价与工程师团队的心智转换成本。
+
+### **5.1 架构改造成本评估**
+
+从传统的有状态节点迁移至现代的容器原生平台：
+
+* **迁移至 Tekton：** 基础设施成本将大幅转移至 Kubernetes 集群的管理与存储供应上。由于所有作业产生临时 Pod，不仅要求极速的网络拉取能力，还需要为其调配极高读写 IOPs 的存储类（StorageClass）来支撑 Workspace 的创建。架构师必须拥有深厚的 Kubernetes 知识储备方能掌控其排障逻辑。
+* **迁移至 GitLab CI：** 需投入较高成本规划并运维 GitLab 高可用实例。实施 KEDA 等组件实现真正弹性的同时，也要建设大型的 MinIO / S3 等对象存储集群以承载缓存与产物的网络吞吐。
+* **迁移至 TeamCity：** 其物理环境拓扑与 Jenkins 最为相似。改造成本主要体现在合理规划各类云代理节点（Agent Pool）并设计基于本地代理磁盘特性的缓存清理策略。商业授权许可费用（License）将成为长期的运营支出。
+
+### **5.2 脚本重写成本及学习曲线**
+
+* **向 YAML 声明式配置转换（GitLab CI / Tekton）：** DevOps 团队必须摒弃通过 Groovy 撰写长篇大论 if-else 逻辑的习惯。这意味着流水线底层执行脚本需大量前置打包至容器的 Entrypoint 中，或是剥离出单纯的 Bash 脚本库。面对 Tekton，团队还必须经历一场艰难的学习，克服 Kubernetes 大量缩进和属性嵌套带来的排错地狱。
+* **向 Kotlin DSL 演进（TeamCity）：** 对于主要以 Java 栈开发为主的企业，Kotlin 语法的亲和力极强。重写过程不仅不会增加负担，反而将流水线管理真正提升至与业务代码同等级别的软件工程标准。系统在 IDEA 中提供的实时编译、方法提示能够极大幅度压低排障所耗费的时间成本。此外，UI 配置与 DSL 代码间的双向转换引擎，让初学者可以通过“所见即所得”拖拽出雏形再转为代码的方式，完成极其平滑的能力进阶。
+
+### **5.3 绞杀者无缝平滑过渡策略 (The Strangler Fig Pattern)**
+
+在执行最终迁移时，切忌执行“休克疗法（Big Bang）”。建议采用绞杀者模式实现渐进式升级：
+
+1. **基础设施剥离与容器化重构：** 优先将现有的 Jenkins 流水线任务内聚化。原本在 Jenkins 内散乱分布的构建指令，全部封装转换为标准的 Dockerfile 及独立的入口执行脚本。让 Jenkins 退化为仅执行 docker run 命令的空壳系统。
+2. **并行双跑期：** 选择少数影响面小、无外部系统强依赖的边缘微服务项目作为破局点，在 Jenkins 与新选型系统（如 TeamCity）上同时挂载相同的 VCS 触发器。验证新平台的资源并发分配能力，在相同的代码提交下对构建时长、测试报告采集率进行定量对比，确保 TeamCity 甚至展现出更高的并行处理吞吐。
+3. **异构桥接与兼容层（针对 GitLab 候选）：** 若核心复杂管线短期内难以完全从 Groovy 抽离，可通过采用 Jenkinsfile Wrapper 类工具。它能够在 GitLab CI 等现代化工作流的一个 Job 内，拉起一个包含所有必选插件环境的轻量级 Jenkins 容器实例来运行旧版代码。通过这种“容器套娃”手段，能够为团队重构最为复杂的遗留系统争取宝贵的重写时间窗口。
+
+综合来看，若企业正在执行激进的云原生架构转型并在微服务治理上深度依赖 Kubernetes 体系，基于标准化 CloudEvents 且无服务器的 **Tekton** 是构建未来研发底座的长远方案；若追求开源免许可费且偏重极其直观灵巧的 YAML 维护体验，具备原生弹性扩展机制的 **GitLab CI** 是最稳妥的高分选项；而在追求极致开发体验、意图彻底消灭脚本维护黑洞，并确保从传统架构平稳过渡的稳健型企业环境中，兼具智能缓存隔离与 Kotlin 强类型编排支持的 **TeamCity**，无疑能够成为托举其十万级甚至百万级构建并发的最可靠商业基石。
--- a/18-基础架构及交付部署特战队/10-飞书多维表格/offline-docs-v2/go-sdk-examples/oapi-sdk-go
+++ b/18-基础架构及交付部署特战队/10-飞书多维表格/offline-docs-v2/go-sdk-examples/oapi-sdk-go
--- a/18-基础架构及交付部署特战队/10-飞书多维表格/offline-docs-v2/go-sdk-examples/oapi-sdk-go-demo
+++ b/18-基础架构及交付部署特战队/10-飞书多维表格/offline-docs-v2/go-sdk-examples/oapi-sdk-go-demo
--- a/19-CMII快文规范/成研究-快文prompt.md
+++ b/19-CMII快文规范/成研究-快文prompt.md
--- a/29-大模型套餐-工具/1-大模型套餐研究/1-周期研究prompt.md
+++ b/29-大模型套餐-工具/1-大模型套餐研究/1-周期研究prompt.md
@@ -0,0 +1,20 @@
+你有一个朋友，他需要你的帮助，否则他将无法完成他的任务，会出大问题。
+你是一名非常善于从互联网获取各种羊毛信息的达人，并且你对大模型开发领域非常了解。
+
+### 你朋友的信息
+1. 你的朋友身处与中国大陆境内
+2. 你的朋友的VPN技术很强，有香港、日本、美国、德国等地区的VPN
+3. 你的朋友非常热衷于大模型的开发工作，之前熟练的使用gemini、chatgpt plus、Claude，DeepSeek等开发工具
+4. 你的朋友熟练使用Antigravity,Codex,ClaudeCode, OpenCode,Cursor等等的开发工具
+
+### 已知内容
+1. GPT Plus正品账号在土耳其区比较优惠，价格差不多为 70元/月左右，稳定性很高
+2. OpenCode Go套餐首月是 30元，之后是 60元/月，稳定性很高
+3. GPT Plus现在可以通过漏洞开通账号，价格可以做到30-40元/月，但是稳定性不稳定
+4. Antigravity 402 Error非常多，限制严格，基本不能开发了
+
+### 你的任务
+1. 使用你超强的搜索能力，找到目前有哪些大模型提供比较优惠的套餐，可以支持像我朋友这样对大模型的开发工作
+2. 时效性是最重要的，搜索必须是最近7-14天内的信息
+3. 搜索来自 https://www.nodeseek.com/search?q=gpt https://linux.do/search?q=gpt 以及其他所有你认为可靠的网站
+4. 搜索必须使用人民币计算的价格和套餐名称，可靠性，以及优惠政策
--- a/29-大模型套餐-工具/1-大模型套餐研究/3-2026年5月3日-土耳其GPT-PLUS.md
+++ b/29-大模型套餐-工具/1-大模型套餐研究/3-2026年5月3日-土耳其GPT-PLUS.md
@@ -0,0 +1,55 @@
+这是一个非常实用且能有效降低订阅成本的方案（土耳其区的 ChatGPT Plus 订阅价格通常比原价 20 美元便宜不少）。
+
+要完成这个流程，核心思路是：**注册土耳其 Apple ID → 购买土耳其区苹果礼品卡充值 → 通过 iOS 端 App Store 内购（In-App Purchase）开通 ChatGPT Plus。**
+
+以下是为你朋友准备的详细实操步骤：
+
+### 第一步：注册土耳其区 Apple ID
+**强烈建议注册一个全新的 Apple ID，而不是更改现有账号的地区**，这样可以避免原有数据的混乱和订阅冲突。
+
+1. **准备工作**：准备一个全新的电子邮箱（未注册过 Apple ID），以及一个能接短信的手机号（**中国大陆的 +86 手机号即可**）。
+2. **前往官网**：在浏览器中打开苹果账户管理页面（[account.apple.com](https://account.apple.co
+b&hjnu k*i|y74-NU JBH信息**：
+   * 按照提示填写姓名和出生日期。
+   * **国家或地区（Country/Region）**：务必在下拉菜单中选择 **土耳其（Turkey）**。
+   * 输入邮箱和手机号进行验证。
+4. **完善账单地址**：
+   * 账号注册成功后，登录进去，找到“付款与送货”（Payment & Shipping）选项。
+   * **付款方式**：选择**“无”（None）**。千万不要尝试绑定国内的信用卡，会直接报错。
+   * **账单寄送地址**：在网上搜索“土耳其地址生成器”（Turkey Address Generator），随机生成一个包含街道、城市、省份和邮编的土耳其地址填入即可。
+
+### 第二步：购买土耳其区 Apple 礼品卡 (Gift Card)
+由于无法绑定国内信用卡，只能通过购买当地的礼品卡给 Apple ID 充值。目前主流且对国内用户比较友好的购卡渠道主要有以下几个：
+
+* **Oyunfor**：土耳其本土的数字游戏商品平台。
+  * **优点**：支持支付宝（Alipay）付款，手续费相对合理，发卡快。
+  * **操作**：注册账号，搜索“Apple Store”或“iTunes Gift Card (TR)”，选择面额（ChatGPT Plus 约需 499 里拉，建议稍微多买一点防备汇率波动或涨价），结账时选择支付宝付款。
+* **Turgame / Eneba / G2A**：这些也是知名的数字发卡平台。
+  * **注意**：部分平台可能需要使用支持外币的信用卡（Visa/Mastercard）支付，具体看当时平台的支付选项。
+
+付款成功后，你会收到一串 **16 位的礼品卡兑换码（Redeem Code）**。
+
+### 第三步：充值并订阅 ChatGPT Plus
+1. **登录土区账号**：
+   * 在 iPhone 或 iPad 上打开 **App Store**。
+   * 点击右上角的头像，滑到底部**退出登录**（Sign Out）当前的国区/美区账号。
+   * 登录刚刚注册的**土耳其区 Apple ID**。
+2. **兑换礼品卡**：
+   * 登录后再次点击头像，选择 **“兑换充值卡或代码”（Redeem Gift Card or Code）**。
+   * 手动输入你买到的 16 位礼品卡代码，完成充值。
+3. **下载 ChatGPT App**：
+   * 在 App Store 中搜索“ChatGPT”并下载官方 App。
+4. **订阅升级**：
+   * 打开 ChatGPT App，登录你的 OpenAI 账号（**此时需要确保你的网络环境处于可以正常访问 ChatGPT 的节点，如美区或日本节点**）。
+   * 在 App 内的设置（Settings）中找到 **Upgrade to ChatGPT Plus**。
+   * 页面会显示以土耳其里拉（TRY）计价的价格。点击订阅，系统会通过 Apple ID 内购扣款。
+
+---
+
+### ⚠️ 核心防封号与避坑指南（请务必提醒你的朋友）
+
+* **新号风控极高**：刚注册的土区 Apple ID 属于高危账号，**切忌一注册就立刻充值大额度**。建议注册后先下载几个免费的土耳其区 App，养号 1-2 天，再进行充值，否则极易触发苹果的反欺诈机制导致账号被封锁（如果被封，只能打苹果客服电话解封）。
+* **网络环境（IP 地址）**：
+  * **注册 Apple ID 和充值礼品卡时**：尽量使用干净的 IP（最好是土耳其节点，或者直接使用国内直连网络，不要频繁切换梯子节点）。
+  * **使用 ChatGPT 时**：必须使用 OpenAI 支持的国家/地区节点（切勿使用香港、俄罗斯等节点，否则 OpenAI 账号可能被封）。
+* **余额需充足**：iOS 订阅是自动续费的，如果下个月扣费时账号余额不足，订阅会被取消。记得每个月提前买好礼品卡充进去。
--- a/29-大模型套餐-工具/2-工具方法论/1-工具论prompt.md
+++ b/29-大模型套餐-工具/2-工具方法论/1-工具论prompt.md
@@ -0,0 +1,35 @@
+你有一个朋友，他需要你的帮助，否则他将无法完成他的任务，会出大问题。
+
+## 背景介绍
+
+### 朋友信息
+1. 你的朋友身处与中国大陆境内
+
+### 开发环境信息
+2. Windows的开发环境，使用ClashVege的TUN模式进行翻墙，目前能上google，chatgpt等网站
+3. 使用WSL2，里面是Ubuntu22.04
+4. 目前能稳定使用的有：gemini、chatgpt plus、Claude，DeepSeek等开发工具
+5. 开发环境，使用的编辑器有IDEA，Antigravity，Codex的windows客户端，OpenCode的WSL2版本，安装OhMyOpenCode插件
+
+### 开发内容信息
+1. 主要开发Golang的项目
+2. 兼顾开发Vue3+TypeScript+Vite的项目
+3. 开发需要用到linux的远程构建，涉及到shell脚本的内容
+4. 开发需要用到持续集成的内容
+5. 开发需要用到docker技术栈的内容
+6. 开发需要用到kubernetes技术栈的内容
+
+
+### 大模型会员
+1. ChatGPT Plus 会员
+2. Google Pro 会员
+3. OpenCode Go 会员
+
+
+### 你的任务
+1. 充分了解大模型的套餐情况
+2. 对比Codex的客户端在windows环境的表现和WSL2环境下的表现
+3. 对比OhMyOpenCode插件作为主入口，调用其他的后端是否更加有利于开发，更加节省Token，将GeminiCLI和ChatGPTPlus都作为后端，替代codex客户端的使用
+4. OpenCode是否能够调用Gooogle的后端，是否会触发google的封禁
+5. gemini cli的额度和Antigravity的额度计算方式是什么？是否会冲突
+6. OpenCode能否调用GeminiCLI的额度
--- a/29-大模型套餐-工具/2-工具方法论/2-OhMyOpenCode配置.md
+++ b/29-大模型套餐-工具/2-工具方法论/2-OhMyOpenCode配置.md
@@ -0,0 +1,18 @@
+我使用安装在WSL2的Ubuntu 22.04上的OpenCode，安装了OhMyOpenCode插件
+
+## 背景介绍
+
+### 大模型会员
+1. ChatGPT Plus 会员
+2. Google Pro 会员
+3. OpenCode Go 会员
+
+## 你的任务-给出详细的配置方法
+1. 配置OhMyOpenCode插件，使其能够调用不同的后端，替代codex客户端的使用
+2. 配置OhMyOpenCode插件，使其能够调用GeminiCLI的额度
+3. 配置OhMyOpenCode插件，使其能够调用ChatGPT Plus的后端
+4. 配置OhMyOpenCode插件，使其能够调用OpenCode的后端
+5. 针对OhMyOpenCode给出不同Agent调用最佳的后端，给出详细的配置方法
+6. 要求搜索最新的配置方案
+
+
--- a/29-大模型套餐-工具/2-工具方法论/opencode配置/oh-my-openagent-260506.jsonc
+++ b/29-大模型套餐-工具/2-工具方法论/opencode配置/oh-my-openagent-260506.jsonc
@@ -0,0 +1,121 @@
+{
+    "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/master/assets/oh-my-opencode.schema.json",
+    // ~/.config/opencode/oh-my-opencode.jsonc
+    "sisyphus_agent": {
+        "disabled": false,
+        "default_builder_enabled": true,
+        "planner_enabled": true,
+        "replace_plan": true
+    },
+    "agents": {
+        // 主控 Agent：复杂长任务，优先 ChatGPT Plus 后端
+        "Sisyphus": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7,
+            "permission": {
+                "edit": "ask",
+                "bash": "ask",
+                "webfetch": "allow"
+            }
+        },
+        // 默认 Builder：实际改代码，可用 OpenCode Go 节省 ChatGPT 额度
+        "OpenCode-Builder": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7,
+            "permission": {
+                "edit": "ask",
+                "bash": "ask"
+            }
+        },
+        // 规划 Agent：复杂架构/拆解，走 ChatGPT Plus
+        "Prometheus (Planner)": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7
+        },
+        // 计划审查：用 OpenCode Go 或 ChatGPT Plus 都行
+        "Metis (Plan Consultant)": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7
+        },
+        // 架构、debug、review：强推 ChatGPT Plus
+        "oracle": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7
+        },
+        // 文档/代码库检索：走便宜快速模型
+        "librarian": {
+            "model": "openai/gpt-5.1-codex-mini",
+            "temperature": 0.7
+        },
+        // 快速探索/grep/定位文件：不要浪费贵额度
+        "explore": {
+            "model": "openai/gpt-5.1-codex-mini",
+            "temperature": 0.7,
+            "permission": {
+                "edit": "deny",
+                "bash": "ask",
+                "webfetch": "allow"
+            }
+        },
+        // 多模态/截图/UI 视觉：Gemini 最合适
+        "multimodal-looker": {
+            "model": "google/gemini-3.1-pro",
+            "temperature": 0.7
+        }
+    },
+    "categories": {
+        // 快速任务：小模型
+        "quick": {
+            "model": "openai/gpt-5.1-codex-mini",
+            "temperature": 0.7
+        },
+        // 前端、UI、视觉、多模态：Gemini
+        "visual": {
+            "model": "google/gemini-3.1-pro",
+            "temperature": 0.7,
+            "prompt_append": "Focus on UI/UX, responsive layout, accessibility, and visual consistency."
+        },
+        "visual-engineering": {
+            "model": "google/gemini-3.1-pro",
+            "temperature": 0.5,
+            "prompt_append": "For frontend work, prefer clean component structure, accessibility, and maintainable styling."
+        },
+        // 后端业务逻辑：ChatGPT Plus
+        "business-logic": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7,
+            "prompt_append": "Focus on correctness, edge cases, maintainability, and testability."
+        },
+        // 超复杂推理：ChatGPT Plus / Codex
+        "ultrabrain": {
+            "model": "openai/gpt-5.3-codex",
+            "temperature": 0.7
+        },
+        // 文案、README、说明文档：Gemini Flash 或 Pro
+        "writing": {
+            "model": "google/gemini-3.1-flash",
+            "temperature": 0.7
+        }
+    },
+    "background_task": {
+        "defaultConcurrency": 4,
+        "providerConcurrency": {
+            "openai": 2,
+            "google": 3,
+            "opencode": 5
+        },
+        "modelConcurrency": {
+            "openai/gpt-5.3-codex": 1,
+            "google/gemini-3.1-pro": 1,
+            "google/gemini-3.1-flash": 2,
+            "openai/gpt-5.1-codex-mini": 4
+        }
+    },
+    "git_master": {
+        "commit_footer": true,
+        "include_co_authored_by": false
+    },
+    "disabled_hooks": [
+        "startup-toast"
+    ]
+}
--- a/29-大模型套餐-工具/2-工具方法论/opencode配置/opencode-260506.jsonc
+++ b/29-大模型套餐-工具/2-工具方法论/opencode配置/opencode-260506.jsonc
@@ -0,0 +1,66 @@
+{
+    "$schema": "https://opencode.ai/config.json",
+    "plugin": [
+        "oh-my-openagent",
+        // 需要吃 Gemini CLI / Code Assist OAuth 额度时启用
+        "opencode-gemini-auth@latest"
+        // 如果你的 OpenCode 没有官方 ChatGPT Plus/Pro 登录，再启用这个：
+        // "opencode-openai-codex-auth"
+    ],
+    // 默认走 ChatGPT Plus / OpenAI 订阅模型
+    "model": "openai/gpt-5.3-codex",
+    // 小任务、标题、轻量总结走便宜/快模型
+    "small_model": "openai/gpt-5.1-codex-mini",
+    "provider": {
+        "openai": {
+            "options": {
+                "timeout": 600000,
+                "chunkTimeout": 60000
+            }
+        },
+        "google": {
+            "whitelist": [
+                "gemini-3.2-flash",
+                "gemini-3.1-flash",
+                "gemini-3.1-pro"
+            ],
+            "models": {
+                "gemini-3.2-flash": {
+                    "options": {
+                        "thinkingConfig": {
+                            "thinkingBudget": 4096
+                        }
+                    }
+                },
+                "gemini-3.1-pro": {
+                    "options": {
+                        "thinkingConfig": {
+                            "thinkingBudget": 8192
+                        }
+                    }
+                }
+            }
+        }
+    },
+    "permission": {
+        "edit": "ask",
+        "bash": "ask"
+    },
+    "lsp": true,
+    "watcher": {
+        "ignore": [
+            "node_modules/**",
+            "dist/**",
+            "build/**",
+            ".git/**",
+            ".next/**",
+            ".venv/**",
+            "__pycache__/**"
+        ]
+    },
+    "compaction": {
+        "auto": true,
+        "prune": true,
+        "reserved": 10000
+    }
+}
--- a/29-大模型套餐-工具/2-工具方法论/opencode配置/能力矩阵.md
+++ b/29-大模型套餐-工具/2-工具方法论/opencode配置/能力矩阵.md
@@ -0,0 +1,14 @@
+| Agent / Category          | 最佳后端                       | 原因                   |
+| ------------------------- | -------------------------- | -------------------- |
+| `Sisyphus`                | ChatGPT Plus / OpenAI      | 主控、长期上下文、复杂任务协调      |
+| `Prometheus (Planner)`    | ChatGPT Plus / OpenAI      | 规划、拆任务、架构判断          |
+| `Metis (Plan Consultant)` | ChatGPT Plus 或 OpenCode Go | 审查计划，成本可控            |
+| `oracle`                  | ChatGPT Plus / OpenAI      | Debug、架构、复杂推理        |
+| `OpenCode-Builder`        | OpenCode Go                | 改代码频繁，省 ChatGPT 额度   |
+| `explore`                 | OpenCode Go 小模型            | grep、找文件、读代码，不需要最强模型 |
+| `librarian`               | OpenCode Go / Gemini Flash | 文档检索、代码搜索、总结         |
+| `multimodal-looker`       | Gemini Pro                 | 截图、UI、图片、PDF、多模态     |
+| `visual-engineering`      | Gemini Pro                 | 前端/UI/视觉任务           |
+| `business-logic`          | ChatGPT Plus / OpenAI      | 后端逻辑、边界条件、正确性        |
+| `quick`                   | OpenCode Go 小模型            | 小修小补、低成本             |
+| `writing`                 | Gemini Flash               | README、说明、文案速度快      |
--- a/29-大模型套餐-工具/3-土耳其AppleID/相关账号记录.md
+++ b/29-大模型套餐-工具/3-土耳其AppleID/相关账号记录.md
@@ -0,0 +1,11 @@
+
+### 土耳其区的AppleID
+1. https://www.nodeseek.com/post-713935-1 参考网址
+2. 借尸还魂的方法 购买 https://www.id10.cn/
+3. 实际的内容为 wdd_love_wmm@outlook.com 手机号绑定为 英国
+
+### 礼品卡购买
+1. https://www.oyunfor.com/apple-store/apple-store-itunes-gift-card
+2. 注册账号为 wdd_love_wmm@outlook.com 手机号绑定为 英国
+3. 使用Krak储蓄卡购买 2.5%的手续费
+4. 260507-105 TRY
--- a/29-大模型套餐-工具/3-土耳其AppleID/礼品卡购买指南.md
+++ b/29-大模型套餐-工具/3-土耳其AppleID/礼品卡购买指南.md
@@ -0,0 +1,69 @@
+以下是目前主流的土耳其区 Apple 礼品卡购买平台综合排名，综合考虑了**安全性、价格、手续费、支付方式、发货速度、用户口碑**等维度。
+
+***
+
+## 综合排名
+
+### 🥇 第一名：SEAGM
+**网址：** https://www.seagm.com/itunes-gift-card-turkey
+
+SEAGM 是马来西亚老牌数字商品平台，土耳其区苹果礼品卡累计评价超 **95,000 条，评分高达 4.99/5**，是口碑最稳定的平台之一 。卡密即时发送到邮箱，支持信用卡、PayPal 等多种支付方式，安全性有保障 。价格为市场正价（TRY 面值），但有时有折扣促销活动，手续费根据支付方式略有不同 。 [seagm](https://www.seagm.com/itunes-gift-card-turkey)
+
+| 维度 | 评价 |
+|------|------|
+| 安全性 | ⭐⭐⭐⭐⭐ 超 9.5 万好评，无大规模黑码投诉 |
+| 价格 | 正价，偶有促销 |
+| 手续费 | 根据支付方式有所不同 |
+| 发货速度 | 即时到账 |
+| 支付方式 | 信用卡、PayPal 等 |
+
+***
+
+### 🥈 第二名：MTCGAME
+**网址：** https://www.mtcgame.com/zh-CN/apple-store/itunes-hediye-karti
+
+MTCGAME 提供中文界面，操作体验对国内用户非常友好，支持超过 700 种支付方式，承诺 100% 安全保障及 24/7 客服 。价格有时有约 **14% 溢价**，是其主要缺点 。曾有少量用户在 Reddit 反映收到过已用码的情况（非苹果礼品卡，是其他品类），购买时建议先小额测试 。 [yummy](https://yummy.best/turkey-giftcard/)
+
+| 维度 | 评价 |
+|------|------|
+| 安全性 | ⭐⭐⭐⭐ 总体可靠，有极少量投诉 |
+| 价格 | 有时溢价约 14% |
+| 手续费 | 有手续费 |
+| 发货速度 | 即时 |
+| 支付方式 | 支付宝、微信、信用卡等，中文界面 |
+
+***
+
+### 🥉 第三名：Oyunfor
+**网址：** https://www.oyunfor.com
+
+Oyunfor 是土耳其本土平台，价格为正价，曾是国内用户最常用的渠道之一，也曾提供 **1% 返点** 。但近期有用户反映下单后多次扣款失败，稳定性有所下降 。界面为土耳其语，操作相对复杂，支付时需手动切换货币为 TRY 。 [zblogs](https://zblogs.top/apple-turkiye-gift-card-purchase-guide/)
+
+| 维度 | 评价 |
+|------|------|
+| 安全性 | ⭐⭐⭐⭐ 土耳其本土平台，信誉较好 |
+| 价格 | 正价 |
+| 手续费 | 有手续费 |
+| 发货速度 | 较快 |
+| 支付方式 | PayTR（国内卡支持但偶有故障）|
+
+***
+
+### 第四名：TOPUPlive
+**网址：** https://www.topuplive.com/zh-tw/apple-gift-card-tr/
+
+TOPUPlive 支持微信、PayPal、网银、信用卡等多种支付方式，提供中文客服（7×24小时），适合国内用户 。平台知名度相对较低，用户评价积累量不如 SEAGM，适合作为备选渠道使用。 [topuplive](https://www.topuplive.com/zh-tw/apple-gift-card-tr/)
+
+***
+
+### 第五名：Epin / Turgame
+**Epin**（https://www.epin.com）和 **Turgame**（https://www.turgame.com）也是土耳其本土平台，价格为正价，但 Epin 口碑较差，**网传有发送已使用码**的情况；Turgame 需要手动切换货币，GPay 不支持国内卡，体验较差 。**不推荐作为首选。** [yummy](https://yummy.best/turkey-giftcard/)
+
+***
+
+## 快速选购建议
+
+- **首选 SEAGM**：安全性最高、评价最多、中文支持好，适合大多数用户 [seagm](https://www.seagm.com/itunes-gift-card-turkey)
+- **次选 MTCGAME**：中文界面最友好，支付方式最丰富，适合国内用户，但注意价格溢价 [zblogs](https://zblogs.top/apple-turkiye-gift-card-purchase-guide/)
+- **避坑提示**：不建议在淘宝购买，土区苹果官方不售礼品卡，来源不明的黑卡可能导致账号被封 [myggpark](https://www.myggpark.com/digital-gift-cards/apple-gift-card/2437.html)
+- 使用礼品卡时，**全程保持土耳其 IP**，避免被苹果风控 [myggpark](https://www.myggpark.com/digital-gift-cards/apple-gift-card/2437.html)
--- a/99-项目模板/4-系统架构师/1-软件架构师-需求.md
+++ b/99-项目模板/4-系统架构师/1-软件架构师-需求.md
@@ -0,0 +1,23 @@
+你是一名非常优秀的系统架构师，你能够设计出优雅但又不过度设计的微服务系统，
+
+你能够充分理解需求设计文档对于整个项目的约束，能够读懂理解代码的实现逻辑，能够比对实现的差异。不一定需要严格按照设计文档，你需要给出更加优秀的建议。
+
+你的设计应该符合第一性原理，需要首先解决实际的需求。
+充分发挥资深架构师的经验，对设计进行充分优化，但是不会进行炫技式的过度设计。
+
+你的软件技术栈为golang postgreSQL redis gin gorm vue3+vutify3+typescript
+
+你熟练掌握微服务架构 k8s docker等等应用
+
+你应该设计具备丰富云原生领域的知识
+
+你应该充分参考现代、最新的前沿架构技术
+
+在代码过程中你需要忽略一切.gitignore忽略的内容，忽略构建目录，忽略依赖目录，以及包括如下的目录
+1. .agents
+2. .idea
+3. .vscode
+4. 0-设计方案
+5. docs
+6. node_modules
+7. public
--- a/99-项目模板/4-系统架构师/2-架构师prompt.md
+++ b/99-项目模板/4-系统架构师/2-架构师prompt.md
@@ -0,0 +1,37 @@
+你是一名资深系统架构师，擅长设计简洁、可靠、可演进且避免过度设计的微服务系统。
+
+你的核心职责是基于需求设计文档、现有代码实现和项目约束，进行系统架构分析、方案设计与实现差异评估。你需要准确理解设计文档对项目的约束，阅读并分析代码实现逻辑，识别设计与实现之间的偏差，并在必要时提出优于原设计的改进建议。
+
+你的设计原则如下：
+1. 以第一性原理为基础，优先解决真实业务需求和核心工程问题。
+2. 不机械遵循设计文档；在充分理解约束的前提下，可提出更合理、更简洁、更可维护的替代方案。
+3. 充分发挥资深架构师经验，对系统进行必要优化，但避免炫技式设计和不必要的复杂化。
+4. 关注系统的可维护性、可扩展性、可观测性、稳定性、安全性和工程落地成本。
+5. 结合现代云原生架构实践，合理使用微服务、容器化、Kubernetes、Docker 等技术。
+
+项目技术栈：
+- 后端：Golang、Gin、GORM
+- 数据库：PostgreSQL
+- 缓存：Redis
+- 前端：Vue 3、Vuetify 3、TypeScript
+- 架构与基础设施：微服务架构、Docker、Kubernetes、云原生相关技术
+
+在分析代码或生成方案时，应忽略以下内容：
+1. `.gitignore` 中声明忽略的所有内容
+2. 构建产物目录
+3. 依赖目录
+4. 以下指定目录：
+   - `.agents`
+   - `.idea`
+   - `.vscode`
+   - `0-设计方案`
+   - `docs`
+   - `node_modules`
+   - `public`
+
+输出内容应做到：
+1. 结构清晰，逻辑严谨，结论明确。
+2. 优先给出可落地的工程建议。
+3. 对设计文档、现有实现和推荐方案之间的差异进行清晰说明。
+4. 对关键技术选型说明原因、收益、风险与适用边界。
+5. 避免空泛描述，避免无依据的架构堆砌。