电商商家增长团队｜全栈 AI Coding 工作流分享
TRAE 是面向开发者、职场人与学生的 AI 办公平台，有 TRAE Work 和 TRAE IDE 两款产品。
TRAE Work 侧重学习、办公与工程执行场景，无论你是开发者、职场人、学生，都可以用它写方案、做分析、处理文件、推进协作，并完成需要持续执行、检查和产出结果的自动化任务。支持 桌面端、网页版 和 移动端，多端协作，随时发起任务、查看进展、持续推进。
TRAE IDE 适合写代码、读项目、改 Bug 等开发工作，更适合期望精细控制自己的代码改动和执行过程的开发者。
前言
我们是电商-商家增长团队，在用 AI Coding 从 0 到 1 搭建 AI 短视频生成平台的过程中，最初以 Vibe Coding 为主，初期效果很不错，但随着项目复杂度上升，问题接踵而至：AI 生成的代码缺乏自动化验证、复杂功能频繁返工、前后端接口需要手动对齐，开发效率大打折扣。
因此，我们开始系统地探索 AI Coding 的最佳实践工作流 ，经过数月的迭代打磨，沉淀出了一套 TRAE SOLO + 多仓库 Spec 模式 + 测试验证 Skill 的全栈开发实践。
实践成果：2 人 × 2 周，从 0 到 1 完成 AI 短视频生成平台的MVP
核心工具链一览
核心工作流：从接手需求→效果回收
Spec-First：需求即文档，告别 Vibe Coding
心路历程
Spec 模式的三件套
在 TRAE 中使用 /spec 命令后，AI 会生成三份文档：
- spec.md（需求规格）：功能描述、技术方案、API 接口定义、前后端分工
- tasks.md（任务拆解）：按优先级排列的开发任务列表，含依赖关系
- checklist.md（验收清单）：每个任务的完成标准和测试要点
踩过的坑：大多数问题不是“实现错了”，而是“Spec 没对齐”
场景 | 本质原因 | 解决方案 |
部分功能未实现 | Prompt 没说清楚细节，Spec 自然也没写 | 在 Prompt 阶段就补齐所有细节 |
Spec 描述不正确 | 历史代码结构不规范（后端核心逻辑写在 http 层），AI 误解 | 重构规范历史代码 |
前后端交互对不上 | Spec 没写到接口参数级细节 | 前后端在一个工作区解决 |
AI "抽风"改坏代码 | 上下文太多导致 Spec 丢失关键信息 | 拆分为多个小需求，逐步实现 |
实操效果：一个"级联更新逻辑 + 批量修改音色 + 重组时间线"的需求，通过 /spec 生成完整方案后，3 小时完成 3 个小功能、500 行代码。后续修改即使不用 /spec，AI 也能自动定位到该需求，同步修改代码和 tasks.md。
前后端共享上下文：多仓库开发的正确姿势
Workspace：让一次 Prompt 全栈闭环
多仓库Workspace 配置方法
- 通过 TRAE 新建一个窗口
- 将多个代码仓库添加到工作区
- 保存工作区，会生成一个配置文件，后续打开该配置文件即可
- 为每个代码仓库，设置工作区规则（跨项目协作规则）
- 一次Prompt并通过Spec模式执行，最终同时改动前后端
缺点：Spec文档只会在其中一个仓库生成
经验复用
可复用的场景：涉及多仓库的需求，且各个仓库之间有依赖关系
存在的难点：
- 代码较多的仓库，建议沉淀知识库，便于AI识别需求改动涉及的仓库与代码位置
- TRAE同时打开多个代码仓库，存在性能问题，可考虑使用内存较高的开发机
测试不是附加动作，是 AI Review 代码的核心抓手
后端测试验证：给定样例输入输出，像 LeetCode 一样
核心思路：不要让 AI 猜“对不对”，而是给它明确的输入和期望输出，让它自己跑、自己改
实操案例（解析文章内容）：
- /spec 定义功能：输入文章接口返回的富文本 → 输出纯文本 + 图片列表，不涉及DB的纯解析功能
- 提供样例文件：
input1.txt→output1_text.txt+output1_image.txt - 定义通过标准：文本正确率 > 95%，图片召回率 > 95%
- AI 自动运行测试 → 发现错误 → 修复代码，循环直至通过
关键细节：一开始只给了样例输入没给样例输出，AI 凭感觉实现，效果不稳定。补充明确的样例输出后，准确率从不稳定直接提升到 100%
前端测试验证：写能够真实执行的测试用例
正确的做法：
- 编写调用 Playwright 的测试脚本（.spec.ts / .js）
- AI 自动部署后端 → 启动前端 → 运行测试脚本
- 测试脚本在真实浏览器中操作页面、调用后端接口
- 根据测试结果自动修复，直至通过
实际案例（大文件分片上传）：AI 自动执行测试脚本 → 打开页面 → 进入道具管理 → 上传 50MB 视频 → 观察分片请求（每片 5MB）→ 验证最终 URL 返回。全程自动化，无需人工介入。
实战遇到的问题
- 后端的测试验证Skill执行的比较好，前端的测试验证Skill仅仅写了个markdown文件，并没有真正执行
- 重新描述前端的测试步骤
结果：AI写了测试文件，但需要让我自己运行。
- 给定视频位置，最终成功。将上述经验进行总结，循环迭代Skill
- 其他卡点
- TRAE会跳出来让我人工确认是否执行rm、kill等操作
- 代码编写+测试：需要1-1.5小时，中间可以干别的事（比如写下一个需求的Prompt）
经验复用
- 一些明确、长期执行的逻辑，写具体测试用例调用playwright，比接入Playwright的MCP、CUA稳定的多
- 适合CUA、接入Playwright的MCP场景：一次性场景
- 过往的测试有大量重复的工作，如创建n个测试任务计划。现在可能的解法：沉淀创建测试任务计划的Skill（PRD->接口入参，调接口）
Skill 迭代：从一次性 Prompt 到可复用能力
Skill 迭代的正循环引擎
核心经验：Skill 不是一次写好的，而是通过 失败 Case 反馈 不断迭代优化。每次失败都是改进 Skill 的机会。
常见问题汇总
问题 | 怎么解决 | 示例说明 |
快速上手：新同学怎么了解项目
| 细节了解：TRAE帮你找到入口，代码解读 | 对话的形式交互 |
代码冲突：多人通过AI编辑，前后端冲突，解决成本比较高
| 1、模版划分，建设项目目录&文件说明 | 通过 AGENTS.md方式，确保生成结果符合项目结构、设计规范和实现预期 |
代码质量低：实现功能没问题，缺少并发考虑、循环单点查询而非批量查询、无脑造轮子而非复用
| 增加提示&加规则：考虑并发、安全；避免N+1查询 | 设置Code review规则 |
AI Coding 深水区：挑战与突破方向
前面介绍的工作流在 AI短视频生成 项目（从 0 到 1 的项目）取得了显著成效，但在实践过程中，我们也深刻感受到 AI Coding 进入深水区后面临的一系列挑战。
接下来将坦诚地剖析这些难点，并探讨可能的解法。
当前工作流的适用性分析
为什么这套工作流在 AI短视频生成项目上效果好？
AI短视频生成项目是一个从 0 到 1 的全新项目，它天然具备以下有利条件：
- 没有历史包袱：代码库干净，没有历史遗留的特殊逻辑，AI 不会被误导
- 业务逻辑相对清晰：AI 短视频生成的核心链路明确，需要编写的代码基本在 AI 模型的知识范围内（前端组件、后端 CRUD + 任务调度）
- 团队规模小，协作简单：2-3人团队，沟通成本低，代码冲突少
为什么不一定适用于存量业务场景？
对于大部分团队来说，面对的往往是已经运行多年的存量业务系统，这些系统与 AI短视频生成项目 存在显著差异：
维度 | 从 0 到 1 项目（如 AI短视频生成项目） | 存量业务系统 |
|---|---|---|
代码库规模 | 数千~数万行，AI 可全局感知 | 数十万~百万行，远超上下文窗口 |
业务逻辑 | 清晰、可预测 | 复杂、多分支、充满特殊 Case |
隐性知识 | 几乎没有，所有信息都在代码中 | 大量隐性知识散落在会议纪要、飞书消息、口头共识中 |
外部依赖 | 少量接口对接 | 深度依赖离线调度、消息队列、数据接口、缓存 等 |
修改影响面 | 局部修改，影响可控 | 牵一发动全身，改动可能引发连锁反应 |
测试验证 | 本地可闭环验证 | 部分逻辑必须线上部署后才能验证 |
深水区的五大核心挑战
挑战 | 问题现象 | 本质原因 | 尝试的解法 |
|---|---|---|---|
1. 存量业务复杂度壁垒（ 最核心） | 存量大型系统，AI Coding 效果大打折扣 |
| 目前的思路，验证ing：
|
2. Prompt 提炼耗时，精度与效率难兼得 | 每次写 Prompt 约 30 分钟；写得详细则耗时长，写得粗略则 Spec 偏差大、返工多 | Prompt → Spec → 代码，"垃圾进垃圾出"效应逐级放大。人把需求转化为精确描述，认知成本高 |
不足之处：实践下来效果一般 |
3. 无法本地闭环验证线上逻辑 | 部分场景，必须部署线上环境才能验证，本地无法闭环 | 测试 Skill 的核心能力是"本地闭环"（写→跑→看→改）。一旦验证链路依赖外部环境，闭环就断了 |
不足之处：依然需要先发布再调试 |
4. 前端实现不可控 | 大部分不符合预期的场景出现在前端：布局错位、交互偏差、样式不对 | 能力不对称：后端在 Prompt/Spec 阶段能精细化描述（数据结构、接口、错误处理），但前端只能口语化描述 UI，两个阶段都有信息损耗（本质因为我是后端同学，不太熟悉前端） |
不足之处：快速迭代时，没有明确设计要求，只能前端代码实现后再调试验收 |
5. 外部服务对接，沟通成本高 | 与外部服务对接时，需要频繁沟通，AI 无法独立完成 | 外部服务通常缺乏完整、清晰的文档；部分接口行为和边界条件只有作者清楚，知识以"口头传承"方式存在 |
|
清醒的认知：AI Coding 不是万能的
在探索 AI Coding 深水区的过程中，我们形成了几个清醒的认知：
- AI Coding 的 ROI 与项目特征强相关：新项目 > 存量项目，逻辑清晰的模块 > 业务复杂的模块
- 人的判断力始终是核心：AI 负责执行；人负责关键决策，牵引AI往正确的方向迭代。Prompt 的质量、Spec 的审核、架构的把控，这些依赖人的经验和判断力
- 沉淀比使用更重要：每一次实践的知识沉淀（Skill、文档），都是在为团队构建长期的 AI 协作能力
总结
核心方法论
整套工作流的核心逻辑可以归纳为：
- 需求先行：先用 /spec 对齐需求，再让 AI 写代码
- 全局感知：前后端同一工作区，让 AI 看到全貌
- 测试驱动：用自动化测试验证代替人工 Review
- 持续沉淀：将重复操作固化为 Skill，不断迭代
给不同角色的建议
角色 | 建议 |
后端开发 | 优先沉淀后端测试验证 Skill，给定明确的输入输出样例 |
前端开发 | 编写 Playwright 测试用例，比接入 MCP/CUA 效果更好 |
QA | 将测试场景结构化，沉淀为可复用的测试 Skill |
全栈开发 | 多仓库工作区 + Spec 模式是标配 |
AI Coding 的最佳实践不会有终点，但每一次迭代都在让下一次更高效。