摘要
我是一名铁路一线工作人员，不会写代码。去年用 DeepSeek 手搓彩钢棚排查系统失败搁置，今年用 Trae 一条指令修复旧 bug 并完成上线（20+人协同采集 1000+条数据）。带着这份信心启动了更复杂的铁路隐患管理系统开发，中间经历了需求贪多求全导致反复推倒重来的至暗时刻，最终通过 MVP 思维+技能框架让系统基本成型。目前仍在持续迭代中，正在攻克 AI 法规检索的精度问题。
背景
我是一名铁路线路巡检岗位的一线工作人员，日常工作中需要处理大量铁路沿线安全隐患的发现、推送、整改跟踪和销号闭环管理工作。
面临的具体痛点
-
信息分散难查找：隐患数据散落在纸质台账、Excel表格、微信聊天记录中，领导问「某段线路隐患整改到哪了」需要翻找半小时
-
跟踪督办靠记忆：一级隐患整改周期长达数周至数月，全靠个人记忆跟踪复查，忙起来容易遗漏超期
-
知识资料难检索：法规文件和技术标准分散在各文件夹，新员工无处可查
-
数据无法发挥价值：即使录入系统也只是电子台账，无法做趋势分析和智能检索
前置经历（重要背景）
去年我用 DeepSeek 手搓了一个彩钢棚排查系统，核心流程跑通了，但数据看板页面怎么调试都报错，加上工作繁忙项目搁置。这成为我的一块心病。
实践过程
第一阶段：Trae 初体验——修复卡了半年的 bug + 彩钢棚系统上线
今年 Trae 出来后，我做的第一件事不是从零开始，而是打开去年那个废弃的彩钢棚排查系统。
关键操作：把报错的数据看板代码丢给 Trae，只下了一条指令：「帮我看一下这个看板为什么报错」
结果：一条指令修复了我折腾几个礼拜没搞定的问题。
这次体验让我建立了对 Trae 的基本信任，随后我让 Trae 帮我完善了彩钢棚系统的其他功能并正式上线。
彩钢棚系统成果数据：
-
二三十人同时在线录入数据，零故障
-
完成今年彩钢棚排查任务，采集隐患记录 1000+条，每条附带原图
-
以往需要翻微信聊天记录手动匹配照片填 Excel，现在全部在系统中完成
-
UI 简约美观，现场同事反馈操作顺手
意外收获——双系统热更新：
我发现了一个让我特别兴奋的工作流：提前备份系统 → 改端口让备份系统和正式系统同时运行 → 用 Trae 在备份系统上改功能测通 → 把改好的文件直接复制到正在运行的系统文件夹里 → 居然不报错。这种一边运行一边更新的感觉太爽了，有种一线工作人员突然变成软件工程师的既视感。
第二阶段：野心膨胀——企业级系统的滑铁卢
有了彩钢棚的成功经验，我信心满满地启动了更宏大的计划：铁路隐患管理系统。AI 评估后告诉我，这个系统的复杂度已达企业级生产系统级别。
我犯的错误：贪多求全 + 技术细节定死
我把能想到的所有需求一次性写全：
-
隐患录入（位置、类型、描述、照片、状态流转）
-
跟踪督办（周期管理、告警预警、时间线）
-
统一知识库（法规/文档/铁路资料/AI 向量化）
-
地图展示（PostGIS 空间数据）
-
AI 智能问答（本地 Ollama + RAG 检索）
-
数据看板 Dashboard
同时我还用 DeepSeek、GLM-5 等大模型帮我梳理需求，它们给出了非常详细的技术方案，包括数据库表结构、API 接口设计、前端框架选型等。我把这些方案原封不动交给 Trae 执行。
结果：灾难
-
做出来的是残次品，到处 bug，点哪儿哪儿错
-
有的版本界面漂亮但点了保存数据存不进去
-
核心业务流程跑不通
-
桌面上新建的项目文件夹铺了一屏
-
需求文档前前后后改了 十几个版本
-
每个版本都觉得「这次应该行了」，跑起来又是一堆问题
那段时间我真的有点崩溃，甚至想过放弃。
踩坑反思
后来我终于想明白两个问题：
问题一：技术细节定得太死
数据库表结构怎么建、接口怎么设计、前端用什么框架……全都规定好了，Trae 被捆住手脚没有发挥空间。一旦某个技术选型本身有问题，后面怎么做都是错。
问题二：需求太泛，什么都想一步到位
系统复杂度确实超出了 Trae 一次性完成的能力边界。这不是 Trae 的问题，是我在用它。
第三阶段：思路转变——MVP + 放手技术细节
我做了两个关键改变：
改变一：给需求做减法（MVP 思维）
我问自己一个问题：「如果这个系统只能有一个功能，那是什么？」
答案很简单：能录入隐患，能查得到。
就先做这个。其他的事，跑通再说。这就是 MVP（最小可用产品）思维。
改变二：放手技术细节
我只告诉 Trae 我要什么效果，具体用什么技术方案让它自己决定。毕竟它是专业的。数据库怎么建合适、代码怎么组织更好，让它去判断。
转变后的效果
在这个思路下，系统终于有了像样的基础：
-
先跑通核心业务流程（隐患 CRUD + 状态管理）
已完成 -
再加跟踪督办模块
已完成 -
再加统一知识库
已完成 -
再加智能录入和语义检索
已完成 -
再加 AI 智能问答（本地 Ollama + pgvector）
基本可用，精度待优化 -
再加数据看板告警
已完成 -
地图功能
底层已准备，界面待实现
每一步都是在前面的基础上增量添加，而不是推倒重来。每一步都能看到进展，有问题也能及时发现。
第四阶段：引入技能框架——规范化开发
再后来我接触到了一套开发技能框架（OpenSpec 变更驱动开发），把它安装到了项目目录中。这套框架带来了：
-
结构化的变更提案机制（每次大改动先写 proposal）
-
规范化的 spec 文档管理
-
任务拆解与追踪体系
-
开发过程不再是想到哪写到哪的散装模式
这让后续的开发顺利了很多，系统才真正有了像样的样子。
当前正在攻克的难题：AI 法规检索精度
系统主流程已经跑通了，但目前有一个让我头疼的问题还在解决中。
AI 智能问答模块用的是本地部署的 Ollama Qwen3:8b 模型，通过 pgvector 向量数据库做 RAG 检索。普通文档类的语义搜索效果还行，但涉及到法规条款的精准引用时就经常出错。
比如我问「彩钢棚涉及的法规条款？」，它能从知识库里搜到相关内容，但引用的条款却不匹配。
可能是 8B 参数量小模型的固有限制吧，在需要高精度 factual recall 的场景下确实力不从心。目前正在尝试几种优化方向：
-
优化向量化策略（分段粒度/元数据过滤/混合检索）
-
调整 Prompt 引导模型更严谨地引用原文
-
后续考虑升级更大参数的模型（硬件允许的话）
这个问题也让我意识到，AI 不是万能的，在小模型上追求企业级精度需要在架构层面做更多补偿设计，而不是单纯指望模型自己「变聪明」。
开发过程中踩过的典型坑
坑一：前端显示「暂无数据」但后台有数据
Trae 升级完知识库模块后，列表页显示空。查了半天发现后台 API 正常返回 200 和数据，但前端表格少了一列内容展示。教训：改完必须端到端测试，不能只看接口正常就觉得没问题。AI 也会犯漏了一块没做的低级错误。。。
坑二：上传文件后正文内容为空
文件保存成功，AI 也完成了文本提取和分块处理，但 content_text 字段为空。原因是 Trae 写的处理流程中间漏了一步——提取的文字没有写回数据库。教训：自动化流程每个环节都要验证，补写了脚本把历史 6 条数据全部修好。
坑三：数据格式不统一导致接口报错
数据库返回 datetime 对象，但 API 定义期望字符串类型，Pydantic 校验失败导致 500 错误。教训：建立统一的序列化规则，系统变大后这点尤为重要。
成果展示
已完成的系统能力
| 模块 | 功能 | 状态 |
|---|---|---|
| 隐患管理 | 录入/编辑/删除/状态流转/照片上传 | 可用 |
| 跟踪督办 | 跟踪记录时间线/周期管理/红黄蓝三级告警/督办看板 | 可用 |
| 统一知识库 | 多类型知识统一管理/AI 自动提取文本/pgvector 向量化 | 可用 |
| 智能录入 | 输入文本描述自动拆分提取数据填充至表单 | 可用 |
| 智能语义检索 | 输入自然语言检索找到需要的隐患数据 | 可用 |
| AI 问答 | 本地 Ollama Qwen3:8b / 自然语言查询/语义搜索 | 基本可用，法规精度待优化 |
| 数据看板 | 统计概览/跟踪告警卡片/待办列表 | 可用 |
| 地图展示 | PostGIS 空间数据存储/GeoJSON 接口就绪 | 底层完成，界面开发中 |
技术栈（均由 Trae 完成）
-
后端：Python FastAPI + SQLAlchemy
-
数据库：PostgreSQL 15 + PostGIS（空间数据）+ pgvector（向量搜索）
-
AI 引擎：Ollama 本地部署 Qwen3:8b
-
前端：原生 HTML + JS + Bootstrap
-
部署：Docker Compose 一键启动
彩钢棚系统截图（已上线）
铁路隐患管理系统截图（开发中）
效果与总结
提效效果
-
彩钢棚排查系统（已完成）：1000+条隐患记录，20+人协同录入，替代手工翻微信+填Excel的原始方式，完美完成当年排查任务
-
铁路隐患管理系统（开发中）：核心业务流程已跑通，隐患管理和跟踪督办模块可正常使用，AI 问答基础能力已具备
-
开发效率对比：去年用 DeepSeek 手搓 → 数据看板卡住数周无法解决；今年用 Trae → 同类问题一条指令修复
SOLO 在我的流程中的角色
Trae SOLO 承担了以下工作：
-
代码编写：我从零开始不会写代码，所有代码由 Trae 生成
-
Bug 修复：报错信息丢给它，它自己查自己改
-
架构决策：我提需求说效果，定技术大方向，技术细节由它掌握
-
数据迁移：SQLite 到 PostgreSQL 的迁移脚本由 Trae 编写
-
迭代更新：双系统热更新模式下持续完善功能（彩钢棚系统验证过的工作模式）
我的角色是：需求定义者 + 功能验收者 + 方向把控者。我不会写代码，但我最清楚一线工作需要什么。
可复用的经验
经验一：先做减法再做加法
别想着一步到位做出完美系统。先问自己「最小可用版本是什么」，跑通核心流程再说。贪多嚼不烂，一个能跑通的半成品胜过十个漂亮但不能用的东西。
经验二：只管需求，放手技术细节
告诉 AI 你要什么效果就好，具体用什么技术让它自己决定。你定的越死它越难受，一旦某个技术选型有问题后面全是坑。
经验三：MVP 迭代式开发
做一个模块，测通，再加下一个。这样每一步都能用，每一步都有反馈，出了问题也知道是哪里出的。比一口气做完再测试靠谱太多。
经验四：善用双系统热更新
备份一份改端口并行运行，在备份上改好了再合过去。这样不影响正在使用的系统，开发心态也轻松很多。（这个在彩钢棚系统上已经验证过，非常好用）
经验五：引入规范化的开发方法
当系统复杂到一定程度后，散装式的「想到哪写到哪」会越来越乱。一套结构化的开发框架能让整个过程更有序、更可追溯。
经验六：认清 AI 的边界
小模型有它的能力天花板，不是所有场景都能靠 prompt engineering 解决。涉及高精度 factual recall 的场景（如法规精准引用），需要在架构层面做更多补偿设计，比如混合检索、元数据过滤、结果校验等。不要神话 AI，但也别因为一个场景不行就否定整体价值。
最后想说
我不会写代码。一行都不会。
但我知道我的工作哪里痛，知道一线同事需要什么，知道哪些数据是核心的哪些是次要的。这些东西 AI 替不了我。
有了 Trae 之后，我不需要会写代码也能做出一个能用的系统。我要做的就是把自己的业务理解翻译成 AI 能听懂的需求，然后不断测试、反馈、调整。
目前的铁路隐患管理系统虽然还没完全达到我想要的效果，尤其是 AI 法规检索精度这块还在攻坚。但相比几个月前连数据看板都调试不通的日子，现在已经走了很远。