从一张机票到一套智慧事故系统
——我和 Trae 走过的五个月，以及它教会我的事
一、我是谁，以及为什么要讲这个故事
我是一名做技术落地的工程师。我的工作日常，是站在一个尴尬的位置上：业务方提需求，开发团队排期排不上，而我夹在中间，既想把事情往前推，又没有完整的开发资源。说白了，我就是那种"懂一点技术、懂数据、但不够格叫自己全栈"的人。以前遇到一个想法，我的选择只有两个——要么等排期，要么自己熬夜从零搭。
三月到八月，五个月时间，我用 Trae 做了六件事：智能体开发、产品清单蒸馏、UI 样式技能沉淀、Jenkins 一键自动化构建 MCP、地图兼容设计、智慧事故处理原型设计。没有一件是惊天动地的大项目，但每一件都真实地改变了我干活的方式。
今天之所以想把这段经历写下来，不是为了夸一个工具有多好用，而是想认真复盘一件事：当一个工具好用到一定程度之后，它改变的就不再是"效率"，而是"你以为自己能做什么"。
二、三月·上海：一次出差，一次相遇
三月，我去上海出差，项目是智能体（Agent）开发。
飞机上我还在啃 Agent 架构文档，脑子里装满了"工具调用"“多轮记忆”"规划-执行循环"这些概念，但落地的时候总有一种隔靴搔痒的感觉——文档写得很清楚，但真要写出一个能跑的 demo，得搭对话框架、接 API、写工具调用的封装、处理异常分支……一想到这些，心里就发虚。
到了酒店，同事丢给我一个链接说"试试 Trae"。我打开它的时候，其实没抱太大期望。这两年我试过不少 AI 编程工具，大多数的体验是：前五分钟很惊艳，五分钟之后你发现它只会写片段、不会搭系统，你得反过来伺候它。
但那天晚上不一样。我没有让它直接写代码，而是把我脑子里的架构完整地描述给它——对话逻辑怎么走、工具调用怎么触发、多轮记忆用什么结构存、异常时怎么兜底。我说完之后，它没有急着甩代码，而是先帮我理了一遍逻辑，指出了两处我没考虑到的边界情况：一个是工具调用超时的处理，一个是多轮对话里上下文截断的时机。
理完之后，它帮我跑通了一个最小可用版本：能对话、能调接口、能记住上下文。我在酒店改到凌晨一点，第二天直接拿去给客户演示。
演示结束后，客户问我："这个准备了多久？"我说一周。其实是一个晚上。
那天晚上我学到的第一件事，后来被我反复验证：AI 工具最大的价值，不是替你写代码，是逼你把模糊的想法变成清楚的描述。 当我被迫把脑子里的架构说清楚的那一刻，问题已经解决了一半。Trae 只是把另一半——从描述到能跑的东西——压缩到了一个晚上。
三、五月：一个"原来还能这样"的月份
如果说三月是相遇，那五月就是密集地发现"原来还能这样"。
整个五月，我做了四件不同的事，看起来毫不相关，但回过头看，它们有一个共同的特征：都是"杂活"，都是以前没人愿意干、自己干又太耗时间的活，而 Trae 让这些活变得可以做。
1. 蒸馏产品清单
手里有一堆零散的产品资料：功能说明、版本记录、竞品对比、客户反馈，散落在七八个文档里。以前处理这种事，我的标准流程是：开五个文档，来回复制粘贴，手动归类，最后拼成一张表，花一个下午，还经常漏。
五月那次，我把所有资料丢给 Trae，跟它说：“帮我蒸馏成一份结构化的产品清单，按功能模块归类，每个模块标注版本、适用场景、已知问题。”
它做了一件让我意外的事：它没有直接生成清单，而是先问我几个问题——“这些版本号是按发布时间还是按大版本？”“竞品对比要保留还是单独拆出来？”"客户反馈里有几条是重复的，要不要去重？"这些问题我自己都没想过。回答完之后，它一次输出了完整的结构化清单，还附了一张模块依赖关系图。
一下午的活，变成了二十分钟的对话。
这件事教会我：把"杂活"交给 AI 的关键，不是把活丢过去就完了，而是你要愿意回答它反问你的那些问题。 它的反问，往往就是你自己做这件事时会忽略的盲点。
2. UI 样式技能
团队前端规范一直不统一。每个人写页面的间距、配色、字体大小都靠"感觉"，导致产品上线后视觉风格飘忽。以前解决这个事的办法是写一份设计规范文档，但文档没人看，看了也记不住。
五月我用 Trae 沉淀了一套可复用的 UI 样式技能——不是一份文档，而是一套真正能被调用的规范组件。以后新页面直接复用，不用每次重新调间距和配色。更妙的是，这套技能可以"记住"我们团队的习惯，新人来了不用读文档，直接用就行。
我突然意识到一件更深的事：知识沉淀的正确形态，不是文档，是"能力"。 文档是被动的，你得去读；而封装成技能之后，能力是主动的，它会在你需要的时候自己出现。这个认知，后来影响了我做后面所有项目的思路。
3. Jenkins 一键自动化构建 MCP
这条是我五月最得意的一件事。
我们的构建流程是：切到 Jenkins 网页，选项目，点构建，等结果，切回来，看日志，再切去部署。一套动作要切三个终端，手动跑，容易漏步骤。
我把这套流程封装成了 MCP，接进 Trae。之后，整个流程变成了一句话："构建并部署项目 X。"它自动触发 Jenkins、等待结果、回传构建状态、出错时把关键日志截出来给我。
一个本来需要人去"执行"的流程，变成了一个可以被"召唤"的能力。 这和 UI 样式技能是同一个道理：把重复的、机械的、容易出错的动作，固化成一种可复用的能力。人只管决策，执行交给工具。
4. 地图兼容设计
业务侧反馈地图在不同环境表现不一致——有的环境渲染正常，有的环境图层错位。以前处理这种兼容性问题，我得自己翻文档、找原因、试方案。
五月那次，我把问题描述给 Trae，它没有直接给答案，而是先帮我梳理"兼容性问题可能出现在哪几个环节"——是底图服务版本差异？是前端框架的渲染时序？还是坐标系转换的精度问题？它列出了每个环节的可能性，并给了对应的排查路径和适配方案，还标注了每种方案的取舍。
它不是在替我解决问题，是在帮我结构化地思考问题。一个人翻文档是线性的、容易钻牛角尖；而它给的视角是网状的，能同时看到多个可能性。
五月过完，我跟同事说了一句话：“我现在不是在用 Trae 写代码，我是在用 Trae 造工具，再用工具去干活。” 这句话成了我这几个月最核心的方法论：先用 Trae 解决一个具体问题，再把解决过程沉淀成一个可复用的能力，最后用这个能力去解决更多问题。形成一个正循环。
四、现在：智慧事故处理原型设计
最近在做的，是一套智慧事故处理的完整原型设计——从事故上报、智能分级、派单调度到处置反馈，一条完整的闭环。
这次我做了一个和以往不同的决定：我没有急着让它出页面。
以前我犯过一个错误——拿到需求就想马上看到东西，于是让 AI 直接生成一堆页面，结果做完发现流程逻辑是断的，页面之间接不上，推倒重来。这次我吸取了教训，第一步只做一件事：让它帮我把业务流程画清楚。
我让它梳理：事故从发生到闭环，一共有多少个节点？每个节点谁参与？数据在哪里流转？哪里是人工决策、哪里可以自动化？
它画完之后，我发现了一个自己之前没意识到的问题：在"事故智能分级"这个节点上，我原来只想到了规则分级（按事故类型和严重程度查表），但它主动提示我——“要不要加一版基于历史数据的模型分级做对比？规则分级快但死板，模型分级灵活但需要数据积累，两者并行可以互相校验。”
这个建议让我愣了一下。因为这不是一个技术建议，是一个业务设计层面的建议。它不是在替我完成，是在跟我一起想问题。
那一刻我有一种很微妙的感觉：我不再是在"使用"一个工具，我是在和一个"伙伴"协作。 工具是被动响应的，你说什么它做什么；而伙伴会主动提出你没想到的角度。Trae 在那个瞬间，越过了工具的边界。
五、五个月，我学到的三件最深刻的事
回头看这五个月，做过的六件事，真正值得拿出来分享的不是"我做了什么"，而是"我学到了什么"。
第一，AI 不会替你想清楚问题，但它会逼你把模糊的感觉变成清楚的描述。
三月上海那个晚上，我被迫把智能体架构说清楚的那一刻，问题已经解决了一半。后来做产品清单、做事故处理，每一次都是同一个感受：当你能把一件事讲清楚到 AI 能听懂的程度，你其实已经想清楚了一大半。 很多人觉得 AI 工具"不好用"，往往不是工具不行，是自己的需求还停留在"我想要一个大概那样"的阶段。Trae 像一面镜子，照出的是你自己思路的清晰度。
第二，不要让它"一把梭"做完整套系统，每次只做一小步。
我中途崩过——不是工具崩了，是我贪多。一口气让它生成完整系统，结果逻辑断、接不上、推倒重来。后来我改了策略：每次只做一小步、能跑、能用，验证完再往下走。做事故处理原型时我尤其克制——先理流程，再一个模块一个模块地搭。慢吗？看起来慢。但总比返工快。
这背后其实是一个很朴素的方法论，叫做"小步快跑"，在工程界喊了二十年。只是以前没有好工具的时候，小步快跑的成本太高，人忍不住想一把梭。Trae 把每一步的成本压到足够低之后，小步快跑才真正变成了本能。
第三，把你真实的工作流喂给它，比喂给它别人的模板有用一万倍。
五月做 UI 样式技能、做 Jenkins MCP，我都是拿自己团队真实的工作流去喂它，而不是找网上的模板套。模板是别人的，只有你自己的工作流才贴合你的真实问题。而当你把自己的工作流沉淀成技能之后，AI 就从一个"通用工具"变成了一个"懂你的工具"。 这是从消费到创造的跨越。
六、希望它未来变成什么样
最后说说期待。
希望它能更"记得住我"。现在每次开新会话，它都要重新认识我——不记得我的项目习惯、不记得我团队的规范、不记得我封装过的那套 MCP。如果能让它把这些沉淀成"长期记忆"，那它就会从一个"每次重新开始"的工具，变成一个"越来越懂我"的伙伴。人跟人之间的默契，是靠相处积累的；人跟工具之间，也该如此。
希望模型生态更开放。Trae 最香的一点就是模型多——复杂推理用一个、写代码切一个、画图用另一个，按场景挑，不将就。这一点是它真正区别于其他工具的地方，希望未来能更极致。
七、最后
三月在酒店的凌晨一点，五月那些"原来还能这样"的瞬间，现在做事故处理时它主动提出的那个分级建议——这些时刻加在一起，构成的不只是"我用了一个好工具"，而是**“我重新定义了自己能做什么”**。
以前我觉得，做东西是开发团队的专利，我能做的只有提需求和等排期。现在我知道，只要我能把问题想清楚，从想法到能跑的东西之间，距离可以短到一个晚上。
这才是 Trae 真正改变的东西——不是怎么写代码，而是"谁有能力做东西"。
对我来说，Trae 不是工具，是让"我以为自己做不到的事"变成"原来我也可以"的那座桥。这条桥上走过的每一步，都是这五个月里最真实的足迹。