双模式、多 Agent、三端接力：我用 TRAE 把「YACA」从需求推到了交付

一个口腔机构数字化管理项目（uni-app + Vue3，多端：H5 / 微信小程序 / App）一个开发者的完整链路记录：想法 → 需求拆解 → 代码实现 → 测试验证 → 交付产物以及新版 TRAE 的体验测评：Agent + IDE 双模式、多 Agent 并行、三端同步、自动化任务、模板库、办公助理与产物管理

一、缘起：一个口腔 SaaS 项目，和它背后的重复劳动

YACA是一个面向口腔机构的全流程数字化管理产品：医院首页、服务商城、预约与问诊、分销与佣金、员工考勤、库存、审批、口检记录......页面总数超过 200 个，分包结构 20 多个，还要维护中文 / 英文 / 越南语三套文案。

这类项目的痛点不在"难"，而在"碎"：

同一个列表分页逻辑，我在 30 多个页面里手写了一遍又一遍；
同一个中文文案，要在三个语言文件里同步三次；
同一批 console.log 调试残留，散落在 30 多个文件里；
每加一个业务弹框，就要同时改接口层、三语文案、组件模板、父级传参四条链路。

碎活占满了时间，真正需要判断力的架构决策反而被挤到深夜。这正是我决定把整条链路交给 TRAE 推进的原因------不是因为"AI 会写代码"，而是因为"AI 能持续把碎活干完"。

二、Agent + IDE 双模式：我把项目拆成了三段时间

新版 TRAE 最打动我的不是某个单点能力，而是双模式这件事本身：Agent 模式负责从想法到交付的全局推进，支持多 Agent 并行；IDE 模式保留完整的开发环境；两者随时切换。用了两个月之后，我摸索出一条很个人化的节奏------

2.1 放心交给 Agent 的环节（约占我 70% 的工作量）

环节

交给 Agent 的理由

需求 → 任务拆解

我只要给出"要把口检记录的治疗计划做成弹框提交"这个想法，Agent 会自己拆成"接口层 / 文案层 / 组件层 / 传参层"四步

代码生成

页面骨架、列表分页、字段映射、i18n 键名，模式高度重复，一次说清约束就能批量产出

批量重构

抽 hook、删调试日志、补 i18n，范围明确、验证方式明确

报错分析与自主修复

构建报错、接口参数序列化异常、依赖缺失，Agent 会先查证再动手

文档与产物整理

变更清单、日报、构建说明，顺手就出

2.2 必须切回 IDE 手动接管的环节

需要我说"不要"的地方：Agent 有个天然倾向------顺手多做一点。比如我只是想补一个 i18n 键，它可能顺手重构整个页面结构。这类"越界"必须在 IDE 里亲手限界、必要时回退。
涉及第三方/框架层的取舍 ：比如 pages/chat/components/z-paging 是整包引入的第三方分页组件，我明确要求"不要注入它的通信机制"。这种边界 Agent 判断不了，得人来划。
视觉与交互的主观判断：按钮位置、弹框节奏、导航返回行为，Agent 能给实现，给不了审美。
跨文件的一致性确认：改动收尾时我习惯在 IDE 里把 diff 逐个看一遍------这是最后一个把关点。

2.3 一次真实的"来回切换"复盘

用刚做完的口检记录治疗计划弹框举例，整条链路我切换了 5 次模式：

Agent 模式 ：拿到需求。Agent 先读组件现有的弹框实现、读接口层的命名规范，产出拆解结论------"新增接口 hisOpmMedtechRequestUpdate（走 admin-api）、三语文案新增『治疗计划 / 跟进计划』相关键、组件内实现治疗计划弹框与两条提交链路、详情页透传 custId"。
切 IDE 模式 ：我检查它给的接口签名与字段命名，确认 custId 该由父级传、而不是组件自己去查------这类参数归属问题，人一眼就能定，Agent 容易"就近取数"。
Agent 模式：按我确认的结构生成实现，同时把三语文案一次性补齐。
切 IDE 模式：在模拟器里跑一遍两条提交链路，发现空值分支没兜住，手动补了边界判断。
Agent 模式：让它把这次改动的【变更清单】整理出来，作为交付产物归档。

结论：Agent 模式负责"把事做完"，IDE 模式负责"把事做对"。两者不是二选一，而是分工。

三、多 Agent 并行：同一条链路上分工，而不是排队

这次工程优化里最有代表性的一轮，是第四次优化：清干净调试残留 + 补齐漏网文案。这批活有个特点------范围明确、彼此独立、验证简单，非常适合并行。

我的分工逻辑是按"处理对象"切，而不是按"处理步骤"切：

Agent A：日志清理 处理 30+ 个文件里的 console.log 残留。约束写得很死：只删打印语句本身，不动逻辑、不动注释、不碰第三方组件目录、不整文件格式化。产出 32 个文件的删除清单 + 一处缩进副作用被自动修正的记录。
Agent B：i18n 补全 处理 6 个页面/组件的硬编码中文，同时补齐中文 / 英文 / 越南语三套 json。约束里我特别强调了两件事：
1. 先查再写------已有键优先复用，确实不存在才新增；
2. 不要顺带重构------只改文案，不改样式和逻辑。
我自己（主 Agent 会话）：同时在做第 ①、②、③ 项优化（分包预下载、分页 hook 抽离、tsconfig），并在两个子 Agent 交回结果后做统一复核。

并行带来的实际差异：如果串行处理，光是 i18n 的 6 个文件 × 3 套语言就需要在三份 json 之间来回跳；日志清理又要一个个打开文件确认下一行是什么。并行之后，两条线互不干扰，我在等待期间还推进了 hook 抽离------原本"三段等待"变成了"一份时间"。

并行的风险与我的规避方式 ：最怕两个 Agent 改到同一个文件。所以我的拆法是"按文件归属分配"，而不是"按能力分配"：A 只碰业务日志，B 只碰指定 6 个文件的文案，主会话负责 pages.json / vite.config.js / tsconfig.json / 新建 hook 文件。**文件不重叠，是并行安全的前提。

四、从 0 到 1 的全链路：需求 → 开发 → 测试 → 交付

这一轮的四个优化项，正好覆盖了整条链路的四个阶段，我把它们当成一次"全链路演练"：

阶段

我做了什么

交付物

需求

让 Agent 先做一次项目体检：找性能短板、重复代码、工程配置缺失

一份带证据的优化清单（页码 + 行号 + 现象）

开发

① 分包预下载 ② 分页 hook 抽离 ③ tsconfig ④ 文案与日志清理

代码改动 + 【变更清单】

测试

H5 / 小程序模拟器跑通列表分页、月份切换、订阅弹框、语言切换

可运行、可访问的实际效果

交付

归档变更说明、日报、待办清单

可复用的工作流文档

4.1 量化对比（实测 + 估算分开标注）

项目

手工预估

TRAE 实际

差异来源

分页逻辑抽离（2 个代表页）

逐页重写，约 45 行/页

新增 1 个 usePagination hook，2 页各减约 45 行脚本

一次写对，30+ 页可复用

i18n 补全（6 文件 / 新增 14 键）

约 40 分钟（3 套语言 × 14 键 + 复查）

一轮完成，键值三语同步，JSON 可解析性已校验

并行 + 键复用

console.log 清理

约 1.5 小时（32 个文件逐个打开确认）

一次任务完成，仅 5 处注释 + 第三方组件按规则保留

范围约束前置

分包预下载

查文档 + 逐个埋点

preloadRule 一次配齐 5 个 tab 页

需要人工确认"高频跳转"口径

说明：手工预估是我的经验值，非严格基准测试；"TRAE 实际"均为本次工作区内的真实改动量。

4.2 一个"先查证再动手"的正面案例

我在优化清单里写了一条"开启构建压缩"。Agent 没有直接放开 vite.config.js 里被注释的 viteCompression，而是先去 node_modules 查依赖是否安装 ------结论是没装。于是它给出判断：贸然放开 import 会直接构建失败，因此不改动，改为在交付说明里写明"需先 npm i -D vite-plugin-compression，再放开"。

这件事让我改变了对"AI 程序员"的刻板印象：好的执行者不是答应得快，而是在动手前先验证前提是否成立。

4.3 一个"报错分析"的案例

复核 i18n 结果时，我在 PowerShell 里跑批量 JSON 校验，得到三条"无效"报错：

javascript 复制代码

无法转换 JSON 字符串，因为它包含具有不同大小写的键。
尝试添加到现有键 'followUpMethod' 的键是 'followupMethod'。

这看起来像是我刚改的三个语言文件坏了。但 Agent 的判断是：这是 PowerShell ConvertFrom-Json 的大小写敏感限制 （该文件本来就存在 followUpMethod 与 followupMethod 两个不同语义的键），不是 JSON 语法错误。它改用 -AsHashtable 复核，我改动的 6 个文件全部 OK。

误报不等于修复。 如果当时"按报错去改"，就会把两个合法但命名相近的业务字段合并，造成真实的数据错误。

五、真实工作场景提效：三个可复用的工作流

工作流 1：批量工程治理

触发场景：项目跑了一段时间，重复代码、调试残留、硬编码文案开始积累。

可复用步骤：

让 Agent 先出一份带证据的体检报告（必须给出文件路径 + 行号 + 现象）；
按"改动风险"排序：配置类 → 新增文件类 → 批量替换类；
批量替换类交给子 Agent 并行，每个子 Agent 的约束里必须写清**"什么不要动"**；
主会话做统一复核，复核项固定为三件事：引用是否残留、i18n 键是否三语齐全、JSON 是否可解析。

工作流 2：i18n 增量补全

约束模板（我每次都复用这段）：

已有键优先复用，先 Grep 目标 namespace 的中文 json 确认；
新增键加在同一 namespace 的 json 末尾，缩进风格与现有文件一致；
不改样式、不改逻辑、不新建文件；
英文与越南语译文要自然通顺，不留中文；
完成后自查：对目标文件跑中文正则，排除注释后应无未包裹文案。

工作流 3：列表分页统一

约束模板：

hook 入参为"请求函数 + 页面额外状态 + 动态参数回调"；
必须内置加载中防重复请求（这是手写版本十有八九会漏的点）；
分页重置复用项目已有的 resetPagination，不重复实现；
先迁移 2 个代表页验证，其余保留原样、增量替换。

六、三端同步：桌面端开工，手机端收尾

我的一天经常被会议切碎。三端同步解决的正是"切碎之后还能接上"的问题：

桌面端：深度开发时段。需要在 IDE 模式里看 diff、跑构建、调模拟器。
Web 端：换电脑或临时用别人的机器，打开浏览器就能接着看任务进度和产物，不需要重新配环境。
移动端：通勤路上、会议间隙。我会用手机确认 Agent 的产出、看变更清单、回复一句"这里不要动第三方组件"，然后让它继续跑。

真实场景：那天下午我在工位上起了"清日志 + 补 i18n"两条并行任务，下班路上在手机上先看了一遍 Agent A 的删除清单，确认"第三方图表组件的日志按规则保留了"，顺手放行；晚上到家在 Web 端把 B 的结果复核完，收工。任务不因设备切换中断，这是三端同步对我最大的价值。

七、平台能力测评：自动化 / 模板库 / 办公助理 / 我的产物

7.1 自动化任务

我最想把这两类重复工作做成定时任务：

每日构建巡检：定时跑一次构建，把报错与体积变化推到手机端；
i18n 一致性巡检：定时比对三套语言文件的键集合，找出"中文有、英文缺"的漏网键。

配置思路很顺------把"我手写的工作流 2"的约束直接变成任务描述即可。建议：如果后续能支持"任务失败时自动把报错摘要写入产物并通知"，巡检类任务的闭环会更完整。

7.2 模板库

对多端项目来说，模板库省下的是决策时间 而不是打字时间：pages.json 的分包结构、i18n 目录约定、API 层命名规范、easycom 组件扫描规则------这些"项目骨架"一旦成型，新页面就是填空。

我也遇到过"模板和实际需求对不上"的情况：模板给的是通用商城结构（商品 / 订单 / 优惠券），而我的项目要长出口腔机构的业务分支（口检记录、治疗计划、员工考勤）。我的做法是不硬套模板：用模板起骨架，用自定义模板沉淀自己项目的规范------比如把"新增页面必须同步三语文案 + 走分包预下载"写进自定义模板，新页面一生成就自带约束。这比模板本身更有价值。

7.3 办公助理

写这份文章的过程本身就是一次使用：我把"今天改了什么"丢给助理，它直接整理成日报------分三条、按业务功能 / 国际化 / 工程优化归类，还顺手把"待办（下轮）"单列出来。这种结构化输出的习惯是它帮我建立的：不写流水账，写"变更清单 + 待办"。

在手机上处理临时工作也很实用：文档、汇报、资料整理的草稿机上就能出，不用等回到电脑前。但要诚实说一句 ：业务语义的准确性仍需要人把关，比如"推荐人"这类领域词，机器翻译成 referrer 是对的，但"推荐人信息"该叫 referrerInfo 还是 referrerInfoList，得我来定------这一版的文章里我就顺手统一了命名。

7.4 我的产物

这是我最看重、也最容易忽略的能力。以前一个项目的产出散在十几个地方：代码在仓库、文档在笔记软件、截图在聊天记录、汇报在另一个文件夹，回头看"上周那个变更清单呢"就得翻半天。

现在的习惯是产物即交付 ：每次任务收尾都产出两件东西------代码 diff 和变更清单 （含待办），统一归档。想回头找就能找到，包括这次四个优化的完整记录。对一个长期迭代的项目来说，"有迹可循"比"写得快"更重要。

八、更强 AI 工程执行：从"回答问题"到"推进任务"

我最大的体感变化是：**AI 不再只回答我的问题，而是持续推进任务。**具体体现在四个环节：

项目理解 ------不需要我把项目背景讲一遍。它自己检索了 pages.json 的分包结构、sheep/hooks/ 的既有 hook 写法、sheep/util/index.js 里已有的 resetPagination，然后给出"对齐现有写法"的方案。能复用就不重复定义，这一点比我见过的多数人都做得好。
代码生成 ------生成的不是"示例代码"，而是能直接进项目的代码：分页 hook 抽离时，它沿用了项目已有的分页对象形状（list / total / pageNo / pageSize），并且补上了手写版本普遍缺失的加载中防重复请求。
报错分析 ------前面那个 PowerShell 大小写误报就是例子：它没有顺着报错去改代码，而是先判断"这个报错是不是真的"。能区分"我的代码错了"和"工具说谎了"，是很高的门槛。
自主修复 ------console.log 批量清理时出现了一处缩进副作用（删除语句后回调体结构偏移），Agent 自己发现并修正了，没有把问题留给我。

九、不足与建议（写给真实的使用者）

用下来，我认为这三点值得改进：

越界倾向：Agent 倾向于"顺手多做一点"。建议在任务描述里显式写"只做 X，不要做 Y"，或者提供更细粒度的改动范围开关。
前提校验需要更显眼：像"依赖没装、压缩插件不能放开"这类结论，价值极高，但它埋在执行过程里。如果能在交付时主动前置成"⚠️ 前置条件缺失"，会更省事。
并行的文件级隔离：多 Agent 并行当前靠我人工规划文件归属。如果平台能在派发时自动检测"两个 Agent 的目标文件是否重叠"并给出预警，并行会更安全。

十、结语

如果要用一句话总结我这段时间的用法：

Agent 模式负责"把事情做完"，IDE 模式负责"把事情做对"；多 Agent 并行负责"同时做完多件事"；三端同步负责"随时随地接着做"；产物管理负责"做完的一切都找得到"。

回到那个口腔项目。真正让我留下的是这样一幕：我提出"口检记录的治疗计划要做成弹框提交"，几轮之后，接口、三语文案、组件、传参四条链路同时到位，我在模拟器里点开弹框、切到越南语、提交成功、数据落库------从想法到可运行，中间没有一次"我忘了改哪个文件"。

它没有替我做决定，但它让我能把时间花在决定上。这才是"从想法到交付"真正的含义。