2026，AI Coding 的基建终于开始追上 AI 的生成速度了。

作者｜Cynthia

编辑｜郑玄

过去两年，AI Coding 最令人兴奋的时刻，大基本止步于代码生成的那一秒。

一句话生成页面，几分钟搭出原型，一个开发者用半天时间做完了过去需要一周才能完成的开发任务……

但在这之后，即使某项单点开发任务获得五倍、十倍的提速，一个项目从需求提出到产品交付的速度，有时候未必能有两倍效率提升。

时间去了哪里？

写提示词、等待 AI 生成是一部分；生成效果不理想，手动在 IDE 中 修改是另一部分。甚至，开发完成后，代码还需要打开终端测试；准备项目汇报，又要切换到文档和演示工具。

每换一个应用、开启一段新会话，都可能需要重新解释：项目在做什么，为什么这样设计，刚才改到了哪里，还有哪些问题没解决。

AI 的生产力跑在了前面，而承载它的开发基建：任务调度、状态管理、验证闭环、产物沉淀、跨工具协同，还停留在前 AI 时代。

于是，到了 2026 年，一些变化开始发生了。这一年，AI 个人助理赛道的热度彻底走到了爆发节点：meta 推出的个人助理 Muse 上线两周便登顶美加 iOS 免费榜，下载量突破 340 万；此后，OpenAI、Google、字节、腾讯、阿里均在加速落地个人助理类产品，短期内上百玩家如雨后春笋冒出。然而，噱头大过了实际，多数生活场景并不存在所谓的标准版答案，也导致真正帮助用户解决实际问题的产品寥寥无几。

为数不多的例外来自编程，以 TRAE 为例，前不久将 TraeCode 与 TraeWork 合并之后，10 月 29 日，平台又正式上线开发者个人助理 TRAE，可以跨项目理解历史上下文，也可以在单个项目里拆解、并行、统筹多个任务。对开发者来说，从此开启新任务时不再从零解释；完成复杂项目推进时，也不再自己拆任务、切会话、盯进度、拼结果。

这一次，工作流的进化，终于赶上了 AI 生成的速度。

01

AI Coding 的工作单位，

在从一条指令升级为一个项目

AI 编码工具的进化，到今天刚好走完三代。

第一代是补全时代。Tab 键自动补全、函数级生成，本质是编辑器的增强，人主导每一行，AI 做填空。它提升的是输入速度，改变不了工作流。

第二代是单会话 Agent 时代。开发者说一句需求，AI 自己读文件、改代码、跑命令，能端到端做完一个小功能、跑出一个 Demo。但它仅限于完成单次会话、单个任务、上下文随会话结束清零，复杂一点的多线程任务，还是要人来拆解、跟进，做结果拼合与修改。

以全新的 TRAE 为代表，行业正式进入第三代，即项目级助理时代。 AI 开始拥有任务调度权和状态记忆，可以自己拆解复杂需求，派发多个子任务并行执行，自己完成编译、测试、验证的闭环，并且跨会话、跨项目记住做过的事、产出的文件、踩过的坑。

具体来说，与此前 OpenAI 完成 ChatGPT 与 Codex 的合并，Cursor 3 推出了专门的 Agents Window，把 Agent 管理从编辑器侧边栏独立出来类似，TRAE 先是将做编排的 Agent 模式与做开发的 IDE 模式整合，让它们可以同步本地任务对话、最终产物及相关配置。

在此基础上，又借助全局助理「全局 TRAE 宝」+ 项目助理「项目专属 TRAE 宝」的双层架构，把跨项目记忆和单项目并行调度落地到了本地仓库场景。

如此一来，开发者可以先在工作台里描述目标，由 Agent 完成拆解后，全局助理与项目助理会承接具体的开发，当开发者需要检查具体实现时，又可以再进入 IDE。

再加上配套的模板库、插件市场、自动化任务和产物管理等能力，AI 的工作单位，已经逐渐从一条指令升级为一个项目。

02

实测：TRAE 开发者个人助理

究竟节约了多少真实开发中的垃圾时间

理想很丰满，但所谓的跨项目记忆到底有没有复用价值，个人项目助理又能不能真的完成真实场景测试，我决定用一个真实复杂项目做个测试。

这次，我选了 B 站开源的 Go 微服务框架 go-kratos/kratos（GitHub 2.6 万星）。

选择它，是因为这个项目有足够多的上下文负担。

HTTP、gRPC、中间件、服务注册发现、配置中心，分布在十几个目录中。一个 HTTP 请求进来，监听和路由由 transport/http 负责，日志、熔断、限流等通用能力则在 middleware 中实现。想写出能用的代码，首先要理解这些模块如何配合。

此外，这次测试的仓库主干已经使用 github.com/go-kratos/kratos/v3 包路径。如果 AI 沿用过去熟悉的 v2 写法，没有读取当前仓库的配置与源码，生成的示例就可能无法编译。

而针对这样的需求做 AI 开发，过去开发者往往需要先手动找出核心文件，解释模块关系，把相关代码贴进对话框。接下来，写代码、补文档、跑测试，如果分成几个会话，又要自己同步背景、跟进进度、汇总结果。

代码生成之前的准备，以及生成之后的收尾，构成了开发中大量零散、重复的时间开销。

所以，这次实测，我把架构梳理、示例开发、测试验证和后续维护放进同一条工作流，看看 TRAE 究竟能帮我解决多少实际问题。

第一步，开通全局 TRAE 宝，然后按照我的个人偏好，给它改名。

先去模板库和插件市场完成工具配置。

进入项目之前，我先看了 TRAE 的模板库和插件市场。模板库按内容创作、数据分析、办公协同、产品开发、战略与研究等场景组织案例。选择模板后，输入框会带入结构化指令；「应用开发」「项目理解」「工具脚本」等入口，也能帮助开发者快速组织任务。

当我们的需求包含多个交付物时，它可以先给出一份相对完整的任务骨架，减少从零组织提示词的成本。

比如要做技术选型或立项，直接点选模板，输入框里会自动填好结构化指令（像图里的 @采购分析 调研筛选 5 家大模型供应商，为 AI Token 采购立项制作价格、能力和预算对比）。

接着，我又在插件市场为后续流程安装了「代码审查报告」和「飞书」插件，前者用于检查代码改动，后者用于连接云端文档。

准备以上完成后，就正式打开 kratos 的项目助理，处理真正的开发任务。

进入项目后，助理先读取本地仓库，识别了 transport、middleware、registry、contrib 等核心目录。过程中，我没有逐个复制文件，也没有先手写一份项目背景说明。

随后，我一次性提出了三个要求：

梳理 transport/http 与 middleware 的职责，生成说明文档，重点解释 HTTP 层的 FilterFunc 与框架层 middleware.Middleware 的执行时机。增加一个最小可编译的 HTTP handler 示例，使用当前仓库的 v3 包路径，并说明如何接入 App 的生命周期管理。运行相关包的测试，说明测试范围，以及项目已有的 Makefile 和 CI 如何执行测试。

这三个任务共享项目背景，又分别涉及源码理解、代码实现和运行验证，很适合观察项目助理能否完成拆解与统筹。

TRAE 先执行了 6 条命令了解仓库结构，随后启动三个子任务，并行推进文档、示例和测试。

从这里开始，任务拆分、上下文分发和进度统筹，已经由项目助理接手。

最终可以看到，子任务 A（写文档）产出了 179 行的 docs/http-middleware-overview.md。里面直接点透了最容易踩坑的区别：FilterFunc 在路由匹配前执行，middleware.Middleware 在路由匹配后执行，并附带了请求链路图、关键文件表和 6 条踩坑点。

子任务 B（写示例），则生成了 54 行的 examples/http/helloworld/main.go，使用当前仓库的 kratos/v3 路径，监听 8000 端口，设置 5 秒超时，注册 GET /hello 路由。代码中的注释还交代了如何通过 kratos.New(kratos.Server(httpSrv)) 接入 App，统一管理生命周期，以及如何同时挂载 gRPC Server。

测试任务（子任务 C）则运行了 transport/http、status 和 8 个 middleware 子包的测试，结果全部通过，未出现 FAIL；同时指出 pprof 子包没有测试文件，并梳理了 Makefile 中带 -race 的 make test，以及 CI 使用的 make test-coverage。

最终，三个子任务的结果被汇总到同一个项目任务中，我不需要再逐个窗口追问、复制和整理。

完成代码只是其中一步。接下来，还要确认它能编译、能启动、能返回预期结果。

过去这需要我们先打开终端，跑构建和检查，启动服务，再用 curl 测接口。任何一步出现环境问题，都要继续排查。

这次，项目助理在完成示例后，继续执行了 go build ./examples/... 和 go vet ./examples/...，两项检查均通过，随后启动服务进行接口验证。

验证过程中，还遇到了一个本地环境问题：127.0.0.1:8000 已经被一个 Python 进程占用。

助理继续检查，通过 IPv6 地址 [::1]:8000 请求接口，拿到了 {"message":"hello kratos"} 的响应，并在结果中提醒我，IPv4 的 8000 端口仍然被占用。

最后，助理检查 Git 工作区，确认只新增了说明文档和示例代码两个未跟踪文件，没有修改原有框架源码，也没有留下编译生成的二进制文件。

从读仓库、写代码，到编译、测试和接口验证，这轮任务形成了一个连续的执行过程。

随后，我调用了此前安装的「代码审查报告」，要求审查 kratos 的代码。

TRAE 自动调用了 1 次 MCP 和 1 次技能，先对工作区拍了个快照（Snapshot captured），然后识别出工作区只有 2 个未跟踪文件：它按审查标准自动跳过了非代码的 .md 文档，精准锁定唯一可审查的 examples/http/helloworld/main.go，补齐上下文后直接拉起 Sub Coding Agent（两名独立校验者）分头搜索文件、做交叉独立验证。

这一步接上了开发后的审查流程，至此，一个完整的项目已经彻底跑通。

但项目提交之后，一切就结束了吗？对开发者来说，隔了一段时间，或者切换工作区之后，需要重新找回之前的工作是个常态。

此后，我切到全局助理「TRAE 宝」，没有提供文件路径，也没有粘贴聊天记录，直接问它：刚才在 kratos 中做了什么，产出了哪些文件，下次进入新仓库时可以如何接着用。

它不仅找到了刚才的任务，列出了文档、示例和测试结果，还保留了本机 IPv4 的 8000 端口被占用、最终通过 IPv6 验证接口的细节。

至此，从读仓库、写代码，到编译、测试和接口验证，再到后期审查乃至工作回顾，这轮任务形成了一个连续的执行过程。开发者需要逐次接手的节点，只有几次点击确认。

03

从提需求，

到实时进度追踪、IDE 模式切换，

TRAE 治好了我的 token 焦虑

实际开发中，工程师大量的时间往往都被用于等待 AI 产出结果，像 kratos 这样的大代码仓，完成一次测试，可能就需要十几分钟甚至几个小时。

很多 token 套餐会设置时段额度上限，如此一来，如果任务跑完了但开发者没能及时察觉、接续发起新任务，这段窗口期里的额度就浪费了。

对于类似场景，TRAE 还提供手机端和消息连接入口，可以在离开电脑后查看进度、补充需求，知道当下的项目完成进展。不用钉在电脑屏幕前死等，任务什么时候结束随时能感知到，任务一跑完就能立刻评审或者追加新需求。

最终开发结果的整理，还可以继续通过飞书插件汇总，让它把所有成功跑完的项目，都会自动同步到飞书「我的文档库」「云盘」里的汇报文档，全部按更新时间集中排列，点开就能回看或继续编辑。

甚至，代码提交后，如果还是被测出了一些 AI 难以修复的小 bug，或者一些手动修改更快捷的细小改动，也可以直接在 Agent 窗口的右上角，点一下「IDE ↗」按钮（见右图红箭头），就能一键切回完整的 IDE 模式。切过去之后，左边就是熟悉的完整代码树和编辑器，底部终端（gopls、Go 版本环境等）全部就绪。

像只改 examples/http/helloworld/main.go 第 21 行的监听端口 http.Address (":8000")，或是微调一个超时时间这种微小变更，如果交给 AI，它要重新加载、读取一长串上下文，消耗 token，速度还慢。切到 IDE 里手动改就是几秒的事情，省下的 token，可以留给这个时间窗口里更重、更适合 Agent 跑的大任务；等准备好新一轮批量任务时，再切回 Agent 窗口交给助理继续跑。让开发可以在 AI 当苦力跑流程与真人下场抠代码细节之间灵活切换。

04

尾声

几轮实测做下来，我最大的感受是：终于不用一边享受 AI 写代码带来的提效，一边还要追在后面给 AI 又当项目经理、又当善后小弟了。

以前，AI 负责生成，人要搬上下文、拆任务、盯进度、解释结果。模型越来越聪明，人却在给 AI 的打杂与搬运中，不断能力退化。

现在，脏活累活交出去之后，未来开发者的价值一定会进一步向决策集中。做什么、为什么做、接受哪些取舍，以及产品应该呈现怎样的体验，都需要更明确的判断。目标定义、架构选择、品味与审美，会更直接地影响 AI 最终交付的质量。

团队的工作方式也会随之调整。任务怎么拆，哪些可以并行，接口怎么约定，最后按什么标准验收，都要重新组织。原本围绕人的串行协作建立的流程，也要开始适应人与多个 Agent 共同推进项目的节奏。

也只有单点能力的提升与整个工作流的重构汇合，AI 的提效才能从一次代码生成，延伸到项目开发、验证、交付乃至持续维护的全流程。

*头图AI 生成

本文为极客公园原创文章，转载请联系极客君微信 geekparkGO

极客一问

当 AI 会自主统筹项目全流程，
开发者的核心工作会变成什么？