T3 近两年在 Web 全栈圈子里热度一直不低围绕它衍生出的工具也越来越多。最近看到 pingdotgg 组织下的 t3code 项目不少读者留言问它到底是什么、能不能用、怎么用。其实 t3code 并不是一个像 Next.js 那样的框架而是把 T3 生态的工程理念和 AI 编码工作流结合起来的一个开发者工具。这篇文章会从项目背景讲起然后带你把 t3code 的定位、环境准备、核心概念、本地部署、实战用法、常见问题和工程化建议完整过一遍。无论你是刚接触 T3 生态的新人还是已经在 Next.js / TypeScript / tRPC 项目里写业务的老手都可以从里面找到能直接上手的部分。说明t3code 目前仍属于迭代速度较快的开源工具文中涉及的命令、配置项、目录结构都只是示例思路具体请以你拉取到的仓库 README 和版本为准。1. 从 T3 生态看 t3code它到底是什么1.1 T3 Stack 与 pingdotgg 的背景在讲 t3code 之前先简单提一下 T3 Stack。T3 Stack 是一套以 TypeScript 为核心的 Web 全栈技术组合通常包括Next.jsReact 应用框架负责页面、路由和服务端渲染TypeScript带来静态类型提升代码可维护性Tailwind CSS原子化样式方案写页面更快tRPC让前后端接口调用做到端到端类型安全。T3 生态的核心特点不是“某个框架多厉害”而是“约定优于配置”和“类型安全优先”。开发者可以从一个最小模板开始快速搭建出前后端共享类型定义的完整应用减少文档阅读和手写接口类型的时间。pingdotgg 是和 T3 Stack 作者关联密切的 GitHub 组织账号平时会输出不少关于 TypeScript、Next.js、React 和 AI 工程化的内容。t3code 就是放在这个组织下面的项目。1.2 t3code 的产品定位从项目命名和所属组织来看t3code 更偏向一个“AI 编码助手 开发者工作流工具”而不是传统的脚手架。传统脚手架解决的是“项目初始化”问题比如create-next-app帮你生成一个 Next.js 项目。t3code 想解决的则是更复杂的问题在一个已经存在的项目里根据需求自动生成业务代码结合项目上下文对代码做类型安全和质量审查把重复性重构从人工操作变成半自动流程让 AI 能理解 T3 生态的技术栈约定而不是只生成一段孤立的代码。简单说t3code 的定位是让 AI 不只“写代码”而是“帮你完成工程任务”。1.3 它和 Copilot、Cursor 有什么不同很多读者会拿 t3code 和 GitHub Copilot、Cursor 对比。它们确实都属于 AI 编程工具但侧重点不同。工具使用方式主要能力侧重点GitHub CopilotIDE 插件行级补全、对话式生成贴近开发者的编写过程Cursor独立编辑器多文件修改、全局上下文理解编辑器体验和对话式开发t3code待仓库确认的 CLI / Agent 形式任务规划、代码生成、审查、重构工程化流程和 T3 技术栈适配t3code 的价值不在于“多会写代码”而在于它尝试把 AI 能力融入到项目规范、代码审查、自动化流程这些工程环节中。如果你平时写 Next.js tRPC 这类项目它比通用 AI 工具更能理解类型安全和路由组织等约束。2. 环境准备跑起 t3code 的前置条件不管你是想贡献代码、本地调试还是想跑起来试用环境准备都是第一步。2.1 基础运行环境t3code 是 TypeScript 生态下的项目所以 Node.js 是必须的。推荐使用 Node.js 的 LTS 版本。你可以在终端里先检查环境node -v pnpm -v git --version如果node -v没有输出需要先安装 Node.js如果pnpm -v提示找不到命令可以全局安装 pnpmnpm install -g pnpm之所以推荐 pnpm是因为 TypeScript 项目普遍依赖较多pnpm 的硬链接机制可以减少磁盘占用安装速度也更快。具体 Node 版本要求以仓库的package.json或.nvmrc为准。2.2 AI 模型服务怎么选t3code 作为 AI 编码工具通常需要一个模型服务来支撑“理解任务”和“生成代码”这两个环节。主流选择有两类云厂商模型 API例如 OpenAI 兼容接口本地模型服务例如通过 Ollama 启动的本地模型。如果你只是本地试用用云端 API 最方便如果你的项目对代码隐私要求高比如不能把业务代码发送到外部接口那么本地模型会更合适。选择模型时还要注意上下文长度。代码任务经常要读取多个文件上下文太短会导致模型遗漏信息。2.3 准备 API Key如果你选择云端模型服务需要先准备 API Key。通常项目会提供.env.example模板复制一份再填入自己的配置cp .env.example .env然后打开.env把API_KEY类配置改成自己的值。这里需要特别提醒.env文件包含密钥一定不要提交到 Git 仓库否则密钥可能泄露。3. t3code 核心概念与工作流程拆解使用 t3code 前先理解它的核心设计思路会更有帮助。AI 编码工具最怕的不是“不会生成代码”而是“乱改代码”。所以 t3code 这类工具通常会把任务拆成几个阶段尽量让每一步都可控。3.1 Agent 与任务编排t3code 的底层通常会有一个 Agent 机制。Agent 会接收一个用户任务然后自动拆解为多个子步骤。一个典型的编码任务流程如下理解任务读取用户输入明确要做什么扫描项目查看文件结构、关键配置、相关代码制定方案根据项目技术栈生成改动计划执行改动修改代码、新增文件或调整配置验证结果运行构建、测试或类型检查输出报告告诉用户改了什么、为什么改。这种流程比“一次性生成一整段代码”可靠得多因为它能在执行前发现潜在冲突。比如项目里已经存在同名函数、数据库字段不匹配、路由路径不一致等问题Agent 可以在扫描阶段提前处理。3.2 权限与沙箱机制AI 自动改代码最危险的点在于它可能误删文件、修改不该修改的配置或者把密钥写进代码。为了降低风险t3code 通常会提供权限控制或沙箱机制。常见的控制方式包括只允许修改白名单目录忽略node_modules、dist、.next等构建产物默认开启“审查模式”AI 只生成改动建议不直接写入文件提供--dry-run参数先输出将要执行的命令和文件变更在 Git 分支上执行保证主分支不被污染。这些机制不是限制能力而是让 AI 工具能在真实项目中落地。尤其是在多人协作的仓库里没有权限控制的 AI 工具会造成灾难。3.3 配置项设计思路t3code 的配置一般会集中在项目根目录可能是.env也可能是一个 JSON 或 YAML 配置文件。下面是一个示意性的配置结构实际字段名以仓库文档为准{ projectRoot: ., model: gpt-4o, allowedPaths: [src, app, components], ignorePatterns: [node_modules, dist, .next, generated], autoApprove: false, maxSteps: 10, requireTests: true }其中几个字段含义如下allowedPaths允许 AI 修改的目录避免它动到配置文件或基础设施目录ignorePatterns不参与分析的目录减少无效上下文autoApprove是否自动执行修改。建议初始阶段设为falsemaxSteps限制 Agent 的最大执行步数防止任务失控requireTests生成业务代码时是否同时生成测试。配置的核心原则是“最小权限”。允许 AI 修改的路径越少出问题的概率越低。4. 本地部署与源码运行实战如果你想看 t3code 的真实实现或者想开发二开插件最好的方式就是本地部署。下面整理一份通用源码运行流程。4.1 克隆项目并安装依赖打开终端执行git clone https://github.com/pingdotgg/t3code.git cd t3code pnpm installpnpm install会安装项目所依赖的所有 npm 包。如果安装过程中出现网络超时可以检查 npm 源配置或者使用国内镜像源但不建议修改项目内部代码来规避网络问题。安装完成后可以看一眼目录结构ls -la通常会有packages、apps、src、docs等目录具体以仓库实际结构为准。如果是 monorepo 结构不同子包可能需要单独启动。4.2 配置环境变量复制环境变量模板cp .env.example .env然后编辑.env填入模型服务的 API Key 和模型名称。下面是通用的配置示例# AI Provider AI_PROVIDERopenai OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 MODELgpt-4o-mini如果你的模型服务不是 OpenAI也可以把AI_PROVIDER改成对应的供应商名称。这里再次强调不同版本的 t3code 环境变量字段名可能不同打开.env.example后以里面的实际注释和模板为准。4.3 启动开发模式安装完依赖后可以启动开发模式pnpm dev启动成功后终端会显示监听地址或日志输出。如果你只想构建生产版本可以运行pnpm build构建完成后产物会输出到dist或.next目录具体取决于项目和打包器。4.4 运行测试对于代码审查类工具测试很重要。一般项目会提供测试脚本pnpm test如果测试通过说明当前环境基本没问题。如果测试失败优先检查 Node 版本和 pnpm 版本是否和项目要求一致。5. 用 t3code 完成一次代码生成与审查任务环境跑起来之后我们可以用一个实际场景来理解 t3code 的用法。由于 t3code 的 CLI 命名可能随版本调整下面示例中的命令只作为思路演示真实命令请查看项目 README。5.1 场景为 Todo 应用生成 tRPC 接口假设你正在做一个 Todo 应用项目使用 Next.js tRPC Prisma。你希望 AI 帮你生成一个包含create、list、toggleDone的用户 Router。如果 t3code 提供了 CLI命令可能长这样npx t3code run 为 Todo 应用创建 userRouter包含 create、list、toggleDone 三个接口并使用 zod 做输入校验Agent 会先扫描项目中的schema.prisma、trpc目录和现有 Router 写法然后按你的要求生成代码。最终生成结果可能类似下面这样// src/server/api/routers/user.ts import { z } from zod; import { createTRPCRouter, protectedProcedure, publicProcedure, } from ~/server/api/trpc; export const userRouter createTRPCRouter({ list: publicProcedure.query(async ({ ctx }) { return ctx.db.user.findMany({ orderBy: { createdAt: desc }, }); }), create: publicProcedure .input( z.object({ name: z.string().min(1), email: z.string().email(), }) ) .mutation(async ({ ctx, input }) { return ctx.db.user.create({ data: input, }); }), toggleDone: protectedProcedure .input( z.object({ id: z.string(), done: z.boolean(), }) ) .mutation(async ({ ctx, input }) { return ctx.db.user.update({ where: { id: input.id }, data: { done: input.done }, }); }), });这里的重点是t3code 不应该只会“写代码”还要能根据项目现有结构决定使用publicProcedure还是protectedProcedure以及是否使用 zod 校验。这会显著减少你后续改代码的时间。5.2 场景对一次提交做代码审查代码审查是 t3code 更适合的应用场景。它的优势在于AI 能结合项目里的类型定义和现有代码风格给你一份可执行的审查建议。假设你刚完成了一个 Git 提交想审查这次的改动npx t3code review --git-diff HEAD~1Agent 会读取最近一次提交的 diff然后尝试找出以下问题新增的接口是否缺少输入校验是否在服务端组件里直接调用数据库是否有明显的类型安全隐患是否违反了项目现有的目录规范是否存在重复代码或性能问题。审查结束它可能会输出类似这样的总结发现 3 个问题 1. user/create 缺少 zod 校验建议增加 input 校验 2. 在页面组件中直接调用 db建议改为 tRPC procedure 3. 新增的工具函数无法被 tree-shaking建议移动到独立工具目录。这种审查能力对团队新人非常有价值因为它能帮助新人在提交代码前发现规范性问题。5.3 把 t3code 接入现有项目如果你想在真实项目里使用可以考虑作为开发依赖安装pnpm add -D t3code然后在项目根目录创建配置文件把关注的目录、忽略目录和模型参数都写清楚。建议先在一个小型工具仓库或非核心业务仓库里跑通再逐步推广到生产仓库。接入的时候要重点做好两件事把autoApprove关掉让 AI 只输出建议不直接改代码使用独立 Git 分支人工 review 后再合并。6. 常见问题与排查思路本地跑开源项目时肯定会遇到各种问题。下面把常见的几类问题整理成表格方便你快速定位。问题现象常见原因解决思路pnpm install失败Node 版本过低或 lockfile 不兼容先检查 Node 版本再删掉node_modules和 lockfile 重新安装启动后端口被占用默认端口冲突在配置文件中修改端口或关闭占用端口的进程API 报 401 / 403API Key 错误或没有订阅对应模型服务检查.env中的 Key 和 Base URL确认账户有权限生成结果忽略关键文件ignorePatterns配置过宽调整忽略规则把src等核心目录加入白名单AI 改乱了代码没有开启沙箱或自动批准模式立即切回干净分支关掉autoApprove使用--dry-run上下文不足导致结果不准文件扫描范围太小或模型上下文不够确保关键文件未被忽略或换用更长上下文的模型测试全部失败依赖版本不一致检查package.json和 pnpm lockfile统一依赖版本如果遇到不在表里的问题先看两个地方终端日志的具体报错信息仓库的issues和README。很多问题不是配置写错了而是版本差异造成的。遇到这种情况不要硬改代码先确认自己用的版本和项目 README 的示例版本是否一致。7. 最佳实践与工程建议AI 编码工具很容易给人一种“能自动搞定一切”的错觉但在真实工程里安全、可维护、可回滚比“写得多快”更重要。下面这些实践建议来自常见的 AI 工具落地经验同样适用于 t3code。7.1 先小范围试点不要一上来就让 t3code 修改整个生产仓库。建议先在一个全新项目或临时分支上测试让它完成一个小功能比如新增一个 tRPC Router、写一个工具函数、补一条测试用例。确认它的输出符合你的预期后再扩大使用范围。7.2 用 Git 分支保护主分支所有 AI 自动改动都应该发生在独立分支上。你可以让 t3code 新建一个分支或者自己手动创建分支后再执行任务。git checkout -b feat/ai-user-router这样即使生成的代码有问题也不会影响主分支。通过代码审查后再合并到主分支。如果是团队项目还应该在 Git 服务端开启分支保护规则禁止直接 push 到 main。7.3 配置管理与密钥安全.env文件不要提交到仓库。更好的做法是使用本地.env.local在 CI 中使用密钥管理服务注入环境变量定期轮换 API Key查看日志时注意不要打印完整 Key。如果你的团队人数多还可以用项目内的config.example维护一份脱敏配置模板新人拿到后复制成真实配置再填充密钥。7.4 日志与审计不能省AI 工具修改代码时必须能追溯到“谁在什么时间让它做了什么”。建议开启 t3code 的执行日志或者至少记录执行时间输入任务涉及的文件列表最终改动 diff是否经过人工确认。这些日志不仅是审计证据也能帮你复盘 Agent 的失败原因。很多 AI 工具表现不稳定不是模型能力差而是任务描述含糊、上下文不完整。日志能帮你定位问题出在哪个环节。7.5 与 CI/CD 结合如果你希望 t3code 不只是本地工具可以把它接入 CI 流程。比如在 Pull Request 创建时自动运行一次代码审查把结果作为评论输出。- name: Run t3code review run: npx t3code review --git-diff origin/main...HEAD这样团队成员可以在合并前收到自动化建议。不过要注意CI 中的 API 调用会产生费用建议按需触发不要每个 commit 都跑。7.6 把“提示词”当成代码维护使用 AI 编码工具时不要每次都随手写一句任务描述。更好的做法是把常用的任务模板保存下来方便复用。比如你可以维护一个docs/ai-tasks/create-router.md内容包含## 任务 新增 tRPC Router ## 要求 - 使用 zod 做输入校验 - 所有数据库操作放在 server 端 - 遵循项目现有命名规范 - 补充最小测试这样每次让 t3code 执行任务时直接引用模板输出会更稳定。8. 总结与学习路线通过上面的学习你应该对 t3code 有了一个比较完整的认知它是 T3 生态下的 AI 编码工作流工具更关注工程任务而不是单行代码补全使用前需要准备好 Node.js、pnpm、模型服务 API Key核心流程是“理解任务 - 扫描项目 - 规划方案 - 执行改动 - 验证结果”安全控制是落地关键白名单、分支、autoApprove开关都要配置好本地部署时可以先克隆源码、安装依赖、配置环境变量再启动开发模式遇到问题优先从版本、密钥、配置文件、日志四个角度排查。如果你还不太熟悉 T3 Stack建议下一步先去了解 Next.js App Router、tRPC Router 和 zod 的基本用法。这些东西不一定需要很深入但至少要能看懂 t3code 生成出来的代码。如果你已经熟悉 T3那么可以重点研究 t3code 的 Agent 编排方式。开源的 Agent 项目通常会把“模型调用”“工具调用”“权限控制”拆成不同模块理解这些模块后你甚至可以把它改造成更适合自己团队的内部工具。AI 编码工具的更新速度非常快新的版本可能随时调整 CLI 参数、配置字段和模型策略。所以最可靠的学习方式不是收藏一堆二手教程而是直接打开仓库 README拉取最新代码跑一遍最小示例。遇到问题就翻 issues亲手解决一两个问题之后你会比看十篇教程都更清楚这个工具的运行机制。希望这篇上手笔记能帮你把 t3code 用起来也欢迎把它收藏备用。后面如果项目更新了核心命令或部署方式我会再补充一篇新版踩坑记录。
T3 近两年在 Web 全栈圈子里热度一直不低围绕它衍生出的工具也越来越多。最近看到 pingdotgg 组织下的 t3code 项目不少读者留言问它到底是什么、能不能用、怎么用。其实 t3code 并不是一个像 Next.js 那样的框架而是把 T3 生态的工程理念和 AI 编码工作流结合起来的一个开发者工具。这篇文章会从项目背景讲起然后带你把 t3code 的定位、环境准备、核心概念、本地部署、实战用法、常见问题和工程化建议完整过一遍。无论你是刚接触 T3 生态的新人还是已经在 Next.js / TypeScript / tRPC 项目里写业务的老手都可以从里面找到能直接上手的部分。说明t3code 目前仍属于迭代速度较快的开源工具文中涉及的命令、配置项、目录结构都只是示例思路具体请以你拉取到的仓库 README 和版本为准。1. 从 T3 生态看 t3code它到底是什么1.1 T3 Stack 与 pingdotgg 的背景在讲 t3code 之前先简单提一下 T3 Stack。T3 Stack 是一套以 TypeScript 为核心的 Web 全栈技术组合通常包括Next.jsReact 应用框架负责页面、路由和服务端渲染TypeScript带来静态类型提升代码可维护性Tailwind CSS原子化样式方案写页面更快tRPC让前后端接口调用做到端到端类型安全。T3 生态的核心特点不是“某个框架多厉害”而是“约定优于配置”和“类型安全优先”。开发者可以从一个最小模板开始快速搭建出前后端共享类型定义的完整应用减少文档阅读和手写接口类型的时间。pingdotgg 是和 T3 Stack 作者关联密切的 GitHub 组织账号平时会输出不少关于 TypeScript、Next.js、React 和 AI 工程化的内容。t3code 就是放在这个组织下面的项目。1.2 t3code 的产品定位从项目命名和所属组织来看t3code 更偏向一个“AI 编码助手 开发者工作流工具”而不是传统的脚手架。传统脚手架解决的是“项目初始化”问题比如create-next-app帮你生成一个 Next.js 项目。t3code 想解决的则是更复杂的问题在一个已经存在的项目里根据需求自动生成业务代码结合项目上下文对代码做类型安全和质量审查把重复性重构从人工操作变成半自动流程让 AI 能理解 T3 生态的技术栈约定而不是只生成一段孤立的代码。简单说t3code 的定位是让 AI 不只“写代码”而是“帮你完成工程任务”。1.3 它和 Copilot、Cursor 有什么不同很多读者会拿 t3code 和 GitHub Copilot、Cursor 对比。它们确实都属于 AI 编程工具但侧重点不同。工具使用方式主要能力侧重点GitHub CopilotIDE 插件行级补全、对话式生成贴近开发者的编写过程Cursor独立编辑器多文件修改、全局上下文理解编辑器体验和对话式开发t3code待仓库确认的 CLI / Agent 形式任务规划、代码生成、审查、重构工程化流程和 T3 技术栈适配t3code 的价值不在于“多会写代码”而在于它尝试把 AI 能力融入到项目规范、代码审查、自动化流程这些工程环节中。如果你平时写 Next.js tRPC 这类项目它比通用 AI 工具更能理解类型安全和路由组织等约束。2. 环境准备跑起 t3code 的前置条件不管你是想贡献代码、本地调试还是想跑起来试用环境准备都是第一步。2.1 基础运行环境t3code 是 TypeScript 生态下的项目所以 Node.js 是必须的。推荐使用 Node.js 的 LTS 版本。你可以在终端里先检查环境node -v pnpm -v git --version如果node -v没有输出需要先安装 Node.js如果pnpm -v提示找不到命令可以全局安装 pnpmnpm install -g pnpm之所以推荐 pnpm是因为 TypeScript 项目普遍依赖较多pnpm 的硬链接机制可以减少磁盘占用安装速度也更快。具体 Node 版本要求以仓库的package.json或.nvmrc为准。2.2 AI 模型服务怎么选t3code 作为 AI 编码工具通常需要一个模型服务来支撑“理解任务”和“生成代码”这两个环节。主流选择有两类云厂商模型 API例如 OpenAI 兼容接口本地模型服务例如通过 Ollama 启动的本地模型。如果你只是本地试用用云端 API 最方便如果你的项目对代码隐私要求高比如不能把业务代码发送到外部接口那么本地模型会更合适。选择模型时还要注意上下文长度。代码任务经常要读取多个文件上下文太短会导致模型遗漏信息。2.3 准备 API Key如果你选择云端模型服务需要先准备 API Key。通常项目会提供.env.example模板复制一份再填入自己的配置cp .env.example .env然后打开.env把API_KEY类配置改成自己的值。这里需要特别提醒.env文件包含密钥一定不要提交到 Git 仓库否则密钥可能泄露。3. t3code 核心概念与工作流程拆解使用 t3code 前先理解它的核心设计思路会更有帮助。AI 编码工具最怕的不是“不会生成代码”而是“乱改代码”。所以 t3code 这类工具通常会把任务拆成几个阶段尽量让每一步都可控。3.1 Agent 与任务编排t3code 的底层通常会有一个 Agent 机制。Agent 会接收一个用户任务然后自动拆解为多个子步骤。一个典型的编码任务流程如下理解任务读取用户输入明确要做什么扫描项目查看文件结构、关键配置、相关代码制定方案根据项目技术栈生成改动计划执行改动修改代码、新增文件或调整配置验证结果运行构建、测试或类型检查输出报告告诉用户改了什么、为什么改。这种流程比“一次性生成一整段代码”可靠得多因为它能在执行前发现潜在冲突。比如项目里已经存在同名函数、数据库字段不匹配、路由路径不一致等问题Agent 可以在扫描阶段提前处理。3.2 权限与沙箱机制AI 自动改代码最危险的点在于它可能误删文件、修改不该修改的配置或者把密钥写进代码。为了降低风险t3code 通常会提供权限控制或沙箱机制。常见的控制方式包括只允许修改白名单目录忽略node_modules、dist、.next等构建产物默认开启“审查模式”AI 只生成改动建议不直接写入文件提供--dry-run参数先输出将要执行的命令和文件变更在 Git 分支上执行保证主分支不被污染。这些机制不是限制能力而是让 AI 工具能在真实项目中落地。尤其是在多人协作的仓库里没有权限控制的 AI 工具会造成灾难。3.3 配置项设计思路t3code 的配置一般会集中在项目根目录可能是.env也可能是一个 JSON 或 YAML 配置文件。下面是一个示意性的配置结构实际字段名以仓库文档为准{ projectRoot: ., model: gpt-4o, allowedPaths: [src, app, components], ignorePatterns: [node_modules, dist, .next, generated], autoApprove: false, maxSteps: 10, requireTests: true }其中几个字段含义如下allowedPaths允许 AI 修改的目录避免它动到配置文件或基础设施目录ignorePatterns不参与分析的目录减少无效上下文autoApprove是否自动执行修改。建议初始阶段设为falsemaxSteps限制 Agent 的最大执行步数防止任务失控requireTests生成业务代码时是否同时生成测试。配置的核心原则是“最小权限”。允许 AI 修改的路径越少出问题的概率越低。4. 本地部署与源码运行实战如果你想看 t3code 的真实实现或者想开发二开插件最好的方式就是本地部署。下面整理一份通用源码运行流程。4.1 克隆项目并安装依赖打开终端执行git clone https://github.com/pingdotgg/t3code.git cd t3code pnpm installpnpm install会安装项目所依赖的所有 npm 包。如果安装过程中出现网络超时可以检查 npm 源配置或者使用国内镜像源但不建议修改项目内部代码来规避网络问题。安装完成后可以看一眼目录结构ls -la通常会有packages、apps、src、docs等目录具体以仓库实际结构为准。如果是 monorepo 结构不同子包可能需要单独启动。4.2 配置环境变量复制环境变量模板cp .env.example .env然后编辑.env填入模型服务的 API Key 和模型名称。下面是通用的配置示例# AI Provider AI_PROVIDERopenai OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 MODELgpt-4o-mini如果你的模型服务不是 OpenAI也可以把AI_PROVIDER改成对应的供应商名称。这里再次强调不同版本的 t3code 环境变量字段名可能不同打开.env.example后以里面的实际注释和模板为准。4.3 启动开发模式安装完依赖后可以启动开发模式pnpm dev启动成功后终端会显示监听地址或日志输出。如果你只想构建生产版本可以运行pnpm build构建完成后产物会输出到dist或.next目录具体取决于项目和打包器。4.4 运行测试对于代码审查类工具测试很重要。一般项目会提供测试脚本pnpm test如果测试通过说明当前环境基本没问题。如果测试失败优先检查 Node 版本和 pnpm 版本是否和项目要求一致。5. 用 t3code 完成一次代码生成与审查任务环境跑起来之后我们可以用一个实际场景来理解 t3code 的用法。由于 t3code 的 CLI 命名可能随版本调整下面示例中的命令只作为思路演示真实命令请查看项目 README。5.1 场景为 Todo 应用生成 tRPC 接口假设你正在做一个 Todo 应用项目使用 Next.js tRPC Prisma。你希望 AI 帮你生成一个包含create、list、toggleDone的用户 Router。如果 t3code 提供了 CLI命令可能长这样npx t3code run 为 Todo 应用创建 userRouter包含 create、list、toggleDone 三个接口并使用 zod 做输入校验Agent 会先扫描项目中的schema.prisma、trpc目录和现有 Router 写法然后按你的要求生成代码。最终生成结果可能类似下面这样// src/server/api/routers/user.ts import { z } from zod; import { createTRPCRouter, protectedProcedure, publicProcedure, } from ~/server/api/trpc; export const userRouter createTRPCRouter({ list: publicProcedure.query(async ({ ctx }) { return ctx.db.user.findMany({ orderBy: { createdAt: desc }, }); }), create: publicProcedure .input( z.object({ name: z.string().min(1), email: z.string().email(), }) ) .mutation(async ({ ctx, input }) { return ctx.db.user.create({ data: input, }); }), toggleDone: protectedProcedure .input( z.object({ id: z.string(), done: z.boolean(), }) ) .mutation(async ({ ctx, input }) { return ctx.db.user.update({ where: { id: input.id }, data: { done: input.done }, }); }), });这里的重点是t3code 不应该只会“写代码”还要能根据项目现有结构决定使用publicProcedure还是protectedProcedure以及是否使用 zod 校验。这会显著减少你后续改代码的时间。5.2 场景对一次提交做代码审查代码审查是 t3code 更适合的应用场景。它的优势在于AI 能结合项目里的类型定义和现有代码风格给你一份可执行的审查建议。假设你刚完成了一个 Git 提交想审查这次的改动npx t3code review --git-diff HEAD~1Agent 会读取最近一次提交的 diff然后尝试找出以下问题新增的接口是否缺少输入校验是否在服务端组件里直接调用数据库是否有明显的类型安全隐患是否违反了项目现有的目录规范是否存在重复代码或性能问题。审查结束它可能会输出类似这样的总结发现 3 个问题 1. user/create 缺少 zod 校验建议增加 input 校验 2. 在页面组件中直接调用 db建议改为 tRPC procedure 3. 新增的工具函数无法被 tree-shaking建议移动到独立工具目录。这种审查能力对团队新人非常有价值因为它能帮助新人在提交代码前发现规范性问题。5.3 把 t3code 接入现有项目如果你想在真实项目里使用可以考虑作为开发依赖安装pnpm add -D t3code然后在项目根目录创建配置文件把关注的目录、忽略目录和模型参数都写清楚。建议先在一个小型工具仓库或非核心业务仓库里跑通再逐步推广到生产仓库。接入的时候要重点做好两件事把autoApprove关掉让 AI 只输出建议不直接改代码使用独立 Git 分支人工 review 后再合并。6. 常见问题与排查思路本地跑开源项目时肯定会遇到各种问题。下面把常见的几类问题整理成表格方便你快速定位。问题现象常见原因解决思路pnpm install失败Node 版本过低或 lockfile 不兼容先检查 Node 版本再删掉node_modules和 lockfile 重新安装启动后端口被占用默认端口冲突在配置文件中修改端口或关闭占用端口的进程API 报 401 / 403API Key 错误或没有订阅对应模型服务检查.env中的 Key 和 Base URL确认账户有权限生成结果忽略关键文件ignorePatterns配置过宽调整忽略规则把src等核心目录加入白名单AI 改乱了代码没有开启沙箱或自动批准模式立即切回干净分支关掉autoApprove使用--dry-run上下文不足导致结果不准文件扫描范围太小或模型上下文不够确保关键文件未被忽略或换用更长上下文的模型测试全部失败依赖版本不一致检查package.json和 pnpm lockfile统一依赖版本如果遇到不在表里的问题先看两个地方终端日志的具体报错信息仓库的issues和README。很多问题不是配置写错了而是版本差异造成的。遇到这种情况不要硬改代码先确认自己用的版本和项目 README 的示例版本是否一致。7. 最佳实践与工程建议AI 编码工具很容易给人一种“能自动搞定一切”的错觉但在真实工程里安全、可维护、可回滚比“写得多快”更重要。下面这些实践建议来自常见的 AI 工具落地经验同样适用于 t3code。7.1 先小范围试点不要一上来就让 t3code 修改整个生产仓库。建议先在一个全新项目或临时分支上测试让它完成一个小功能比如新增一个 tRPC Router、写一个工具函数、补一条测试用例。确认它的输出符合你的预期后再扩大使用范围。7.2 用 Git 分支保护主分支所有 AI 自动改动都应该发生在独立分支上。你可以让 t3code 新建一个分支或者自己手动创建分支后再执行任务。git checkout -b feat/ai-user-router这样即使生成的代码有问题也不会影响主分支。通过代码审查后再合并到主分支。如果是团队项目还应该在 Git 服务端开启分支保护规则禁止直接 push 到 main。7.3 配置管理与密钥安全.env文件不要提交到仓库。更好的做法是使用本地.env.local在 CI 中使用密钥管理服务注入环境变量定期轮换 API Key查看日志时注意不要打印完整 Key。如果你的团队人数多还可以用项目内的config.example维护一份脱敏配置模板新人拿到后复制成真实配置再填充密钥。7.4 日志与审计不能省AI 工具修改代码时必须能追溯到“谁在什么时间让它做了什么”。建议开启 t3code 的执行日志或者至少记录执行时间输入任务涉及的文件列表最终改动 diff是否经过人工确认。这些日志不仅是审计证据也能帮你复盘 Agent 的失败原因。很多 AI 工具表现不稳定不是模型能力差而是任务描述含糊、上下文不完整。日志能帮你定位问题出在哪个环节。7.5 与 CI/CD 结合如果你希望 t3code 不只是本地工具可以把它接入 CI 流程。比如在 Pull Request 创建时自动运行一次代码审查把结果作为评论输出。- name: Run t3code review run: npx t3code review --git-diff origin/main...HEAD这样团队成员可以在合并前收到自动化建议。不过要注意CI 中的 API 调用会产生费用建议按需触发不要每个 commit 都跑。7.6 把“提示词”当成代码维护使用 AI 编码工具时不要每次都随手写一句任务描述。更好的做法是把常用的任务模板保存下来方便复用。比如你可以维护一个docs/ai-tasks/create-router.md内容包含## 任务 新增 tRPC Router ## 要求 - 使用 zod 做输入校验 - 所有数据库操作放在 server 端 - 遵循项目现有命名规范 - 补充最小测试这样每次让 t3code 执行任务时直接引用模板输出会更稳定。8. 总结与学习路线通过上面的学习你应该对 t3code 有了一个比较完整的认知它是 T3 生态下的 AI 编码工作流工具更关注工程任务而不是单行代码补全使用前需要准备好 Node.js、pnpm、模型服务 API Key核心流程是“理解任务 - 扫描项目 - 规划方案 - 执行改动 - 验证结果”安全控制是落地关键白名单、分支、autoApprove开关都要配置好本地部署时可以先克隆源码、安装依赖、配置环境变量再启动开发模式遇到问题优先从版本、密钥、配置文件、日志四个角度排查。如果你还不太熟悉 T3 Stack建议下一步先去了解 Next.js App Router、tRPC Router 和 zod 的基本用法。这些东西不一定需要很深入但至少要能看懂 t3code 生成出来的代码。如果你已经熟悉 T3那么可以重点研究 t3code 的 Agent 编排方式。开源的 Agent 项目通常会把“模型调用”“工具调用”“权限控制”拆成不同模块理解这些模块后你甚至可以把它改造成更适合自己团队的内部工具。AI 编码工具的更新速度非常快新的版本可能随时调整 CLI 参数、配置字段和模型策略。所以最可靠的学习方式不是收藏一堆二手教程而是直接打开仓库 README拉取最新代码跑一遍最小示例。遇到问题就翻 issues亲手解决一两个问题之后你会比看十篇教程都更清楚这个工具的运行机制。希望这篇上手笔记能帮你把 t3code 用起来也欢迎把它收藏备用。后面如果项目更新了核心命令或部署方式我会再补充一篇新版踩坑记录。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
