Trae 出了 Windows 版本，今天试一试看看手感如何。
听闻是 AI 原生 IDE，从个人角度我觉得很看好，AI 是可以重新做一遍开发基础设施的。对于 Java 工程师而言，IDEA 基本是绕不过的，工程师本身就是对产品体验颇为挑剔的群体，希望字节可以开启国产基础设施重振之路，而不是做那些套壳工具。
这次以一个线上问题为例，体验下 Trae 对于稍微需要点专业知识的问题处理与工程初始化。
1、使用 Chat 模式排查错误原因
这是一个较为常见的 Tomcat 参数调优问题，使用默认请求头大小对于一些大请求头就会出现这样的报错：
org.apache.coyote.http11.Http11Processor:182 - Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:706)
at org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:853)
at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:565)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:703)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
开启 Chat 模式直接问问大模型是怎么处理的，看样子思路是对的，并给出了两个参数配置。
至于建议是否都有效不重要，下面使用 Builder 模式看下实际效果，通过复现问题现场逐步找到问题答案。
2、使用 Builder 模式复现问题现场
（1）生成 Web 工程
Builder 模式目前只有 Claude-3.5-Sonnet 一种模型可选，初始化一个 demo 工程。
直接给出提示创建一个使用特定版本和特定端口的 Spring Boot 工程，结果版本没有给到最新的，姑且不计，全部接受，生成一个类似 spring.io 工程。
不做调整，直接运行，一次通过。
（2）构造大 Header HTTP 请求
继续，添加一个 endpoint 用于接受大 Header HTTP 请求。
没有添加 RequestHeader 和 Map 依赖，通过 IDE 提示补充上。
再添加 HTTP 请求客户端，这个客户端构造一个大 Header，并请求上面创建的 /receive-large-header。简单一点，直接跑一个静态 main。
Header 创建也是挺粗暴的，直接填充了若干个 X，没关系没有对它做要求只要够大就行。
不着急 Accept All，这里发现一个小问题，请求端口不是按照初始化工程的 8888 端口，再次对话调整一下，可以 Accept 了。
（3）复现 Request header is too large 并解决
运行客户端 LargerHeaderClient 也是一次编译通过。并复现到了开头提到的问题 Request header is too large。
引用控制台的异常日志，询问解决办法，这里能大概了解大模型推理过程，解决方向是对的，先采纳看看效果。
结果显然还是不正确的，继续质疑一下参数准确性。大模型认为是参数的格式不对，仍然使用的是 server .tomcat 前缀，建议不采纳。
肯定解决思路，并指出具体的参数范围，是在 Spring Boot 3.2.0 下的内嵌 tomcat 参数，尝试了几次大模型调整了过来。这里选用 3.x 就是因为这个参数已经从 2.x 的 server.max-http-header-size 改为了 server.max-http-request-header-size。
（4）重新运行
删除掉了 target 结果运行不了，继续提问，这里有一点 agent 的意思了。
加载好了依赖再次编译，请求正常。
3、Trae 初体验小结
Builder 模式毕竟还是 Beta，不是很稳定，偶尔还会有类似 Server error, please try again later 错误发生。即使有 AI 加持，IDE 还是需要深入到开发流程、工具属性与技术细节中的，IDEA 可以活二十年就是不断提升开发效率与体验的。
虽然是借助了 VSCode 框架，Trae 在一些细节上还是下了功夫的，比如说强化了「对话」重要性，可以对编辑器工作空间外的控制台进行引用，以及编译环节的介入，如果能串联起全流工程，势必对工程师个体有极大增强。想一想，如果大模型被调教的足够顺手，几乎所有开发环节都可以通过 Accept 或者 Reject 来完成，那该是有多么流畅。
从工程师工作流程来看，编码环节毕竟只占一小部分，集成部署、问题排查、架构与重构都是颇费周章的。这次也先以复现问题为例按照一般排查问题的思路进行，定位问题、找出方向、搜索细节并不断循环调整，直到找到合适解法。
另一方面，使用大模型是不会像开车过度依赖导航一样，导航出错就变成了路盲，也就是最近经常讨论的使用大模型生成的代码让开发者更加不关注基础知识的问题，让软件工程更加难以维护，我也是持谨慎态度的。不过从发展趋势来看，这终究是要让懂 AI 的工程师替代掉那些不懂 AI 的。
