TRAE使用体验

最新推荐文章于 2025-12-15 15:28:35 发布

原创最新推荐文章于 2025-12-15 15:28:35 发布 · 285 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#腾讯云AI代码助手

最近因为工作原因，需要一个简单的分析系统运行日志的程序。按照以前的惯例肯定是自己写代码来实现。网上经常看到TRAE的信息，于是打算尝试用TRAE来试水。

需求为：
扫描日志文件，找出线程名称包含“http-nio-8089-exec”，日志内容包含“merge _Incr”的时间点。

下载、安装、新建工程等基础操作，官网文档的说明清晰明了，此处不再赘述。
官网地址：https://www.trae.cn/

输入提示词：

请用python写一个程序分析日志文件，找出其中线程名称包含“http-nio-8089-exec”，日志内容包含“merge _Incr”的时间点

TRAE生成了3份文件：log_analyzer.py，README.md，sample_log.log
其中sample_log.log为测试文件，部分内容如下：

2023-10-20 14:30:00,000 INFO [main] org.apache.catalina.startup.Catalina - Server startup in [12345] milliseconds
2023-10-20 14:30:10,123 INFO [http-nio-8089-exec-1] com.example.UserController - User login: user123
2023-10-20 14:30:20,234 DEBUG [http-nio-8089-exec-2] com.example.DataService - Fetching data for user
2023-10-20 14:30:30,345 INFO [http-nio-8089-exec-1] com.example.Service - Starting merge _Incr operation
2023-10-20 14:30:40,456 ERROR [http-nio-8090-exec-1] com.example.ErrorHandler - Database connection failed
2023-10-20 14:30:45,567 INFO [http-nio-8089-exec-3] com.example.Service - merge _Incr processing started
2023-10-20 14:31:00,678 DEBUG [http-nio-8089-exec-3] com.example.Service - Processing item 1 for merge _Incr
2023-10-20 14:31:10,789 DEBUG [http-nio-8089-exec-3] com.example.Service - Processing item 2 for merge _Incr

在IDE的终端运行命令，确实输出了正确的时间点

python log_analyzer.py sample_log.log

然后使用该程序扫描我自己的日志文件，结果找到正确的时间点。
经分析，发现sample_log.log中日志内容都是单行的，我的日志内容是多行的。于是输入如下提示词：

请考虑到有些日志记录可能跨越多行的情况

TRAE修改了代码，重新生成了新的测试文件"multiline_sample.log"，部分内容如下：

2023-10-20 14:30:00,000 INFO [main] org.apache.catalina.startup.Catalina - Server startup in [12345] milliseconds
2023-10-20 14:30:30,345 INFO [http-nio-8089-exec-1] com.example.Service - Starting operation
This is a multiline log message
with multiple lines of details
about the merge _Incr process
2023-10-20 14:30:45,567 INFO [http-nio-8089-exec-3] com.example.Service - merge _Incr processing started
2023-10-20 14:31:00,678 DEBUG [http-nio-8089-exec-3] com.example.Service - Processing item 1 for

执行命令扫描该文件能输出正确信息。扫描我自己的日志文件后，依然找不到任何内容。
思路许久不知道问题出在哪里，无赖只能查看生成的代码：log_analyzer.py，其中有一个方法is_new_log_entry：

def is_new_log_entry(line):
    """
    判断一行是否是新的日志条目开始
    通常新的日志条目以时间戳开头
    """
    # 使用与extract_timestamp相同的模式来判断是否是新日志条目
    timestamp_patterns = [
        r'^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},?\d*',  # 2023-10-20 14:30:45 或 2023-10-20 14:30:45,123
        r'^\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}',      # 2023/10/20 14:30:45
        r'^\d{2}-\d{2}-\d{4} \d{2}:\d{2}:\d{2}',      # 20-10-2023 14:30:45
    ]
    
    for pattern in timestamp_patterns:
        if re.match(pattern, line):
            return True
    return False

根据注释可以看出用来判断一行是否是新的日志条目开始，仔细研究发现其中timestamp_patterns，定义了日期的格式，与我日志中的格式有些微差异。于是输入如下提示词：

请注意，日志的格式事例如下：
2025-10-09 at 00:01:51,980

TRAE修改了代码，重新生成了新的测试文件"new_format_sample.log"。经测试新的测试文件和我的日志文件都能输出正确的时间点。

总体感觉TRAE还是比较强大的，是能够理解用户输入的提示词需求的。细节方面是需要用户多次与其交互沟通，最终能实现用户诉求。
另外TRAE也能根据常规知识自动实现相关功能不需要用户额外解释。比如，判断一行是否是新的条目开始，TRAE默认规则是判断该行是否以时间戳开头。这一点确实节约了用户的思考与沟通成本。
但是另一方面，如果TRAE的默认规则如果与实际情况不符合的话，出了问题可能需要阅读TRAE生成的代码才能比较快速的找到原因。算是有利有弊吧。