外观
软件开发 & 工程实践
TraeWork 是字节跳动旗下 AI 办公平台，侧重学习、办公与工程执行场景，无论你是开发者、职场人、学生，都可以用它写方案、做分析、处理文件、推进协作，并完成需要持续执行、检查和产出结果的自动化任务。支持桌面端、网页版和移动端，多端协作，随时发起任务、查看进展、持续推进。
立即下载 TraeWork 桌面端
面向开发、调试和工程协作场景，帮助你更高效地完成代码实现、问题排查和技术方案设计。
适合代码生成、Bug 修复、接口设计、架构梳理、测试用例、性能优化和技术文档等场景。
No.64｜用 TraeWork 把线下机器计算做成桌面软件
作者：u586457696975488 ｜ 仪器工程师（一体机新产品导入与量产维护） ｜ 工具：TraeWork ｜ 阅读约 5 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172307
**用法总结：**用 TraeWork Code 模式完成从需求理解到打包交付的完整软件开发，把手工 Excel 计算变成拖拽 CSV 一键导出合规参数的桌面软件。
**场景：**8 通道移液器 9 档位系统性偏差，需用天平称重数据反算补偿参数 a0/a1。
**效率提升：**半天 → 10 分钟。
成果：「移液补偿计算 V3.1.0」桌面软件，导出含 5 个 sheet 的 Excel，K 列全绿无标黄。
一、个人背景介绍
**个人背景：**负责整机新产品导入与量产维护的仪器工程师，需要为 8 通道移液器的 9 个体积档位反算 a0、a1 补偿参数。
**当前痛点：**手工流程要导入 CSV、分组、枚举参数并逐项验证，一台机器需半天；还容易填错列、漏公式或覆盖 Excel 模板公式。
二、提效前后对比
| 环节 | 手工 Excel 操作 | 桌面软件 |
|---|---|---|
| 单机耗时 | 一台机器折腾半天 | 10 分钟完成 |
| 操作方式 | 导入 CSV、按通道分组、手动枚举参数、逐个验证 | 拖入 CSV 一键计算导出 |
| 易错点 | 填错列、漏公式、覆盖模板公式 | 保留公式与条件格式，K 列全绿 |
三、我用 TraeWork 怎么解决的
**核心方案：**用 Code 模式完成业务规则理解、计算引擎、桌面界面、Excel 模板输出和单文件打包，将手工计算流程封装为产线可直接使用的软件。
实践步骤：
**解析业务规则：**读取需求、Excel 模板、CSV 样例和界面截图，识别每 240 行一轮、跳过首轮预热、K 列合格范围与 S 列枚举逻辑。
**实现计算引擎：**完成 CSV 解析、通道与档位分组、异常值排除、统计计算、a0×a1 全组合枚举、合规筛选和最优参数选择。
**开发桌面界面：**用 Tkinter 提供文件导入、8 通道×9 档参数显示、合规详情、多轮计算和 Excel 导出。
**保真输出模板：**通过 win32com 填入 D/E/P/S 列，保留 Q/R 列公式和按钮，并用 CalculateFull 刷新条件格式。
**打包产线版本：**用 PyInstaller 将程序与模板打包为单文件 exe，确保产线电脑可零依赖运行。
四、成果展示
最终呈现：
支持拖入 CSV 一键计算的“移液补偿计算 V3.1.0”桌面软件
覆盖 8 通道×9 档位的参数显示与合规性校验界面
保留公式、按钮与条件格式的 5-sheet Excel，K 列全绿
五、实践经验总结
1️⃣ 让 AI 先吃透业务规则再写代码
先把需求文档 + Excel 模板截图 + CSV 样例喂给它，让它理解「240 行/轮、首轮预热跳过、K 列合格范围」等约束，再开始写逻辑，能大幅减少返工。
2️⃣ win32com 操作 Excel 模板的三个坑
Worksheets.Add 必须用位置参数 Add(None, sheet)；ws.Calculate() 不刷新条件格式缓存，必须用 excel.CalculateFull()；直接填 Q 列会覆盖公式，应只填 S 列枚举值让 Excel 自动算。
3️⃣ exe 内置模板才能在产线独立运行
用 PyInstaller --add-data 把模板打进 exe，运行时从 sys._MEIPASS 临时目录读取，否则拷到产线机器找不到模板会报错。
六、提示词参考
核心提示词结构
Plain
角色：你是资深 Python 工程师，精通 win32com/openpyxl Excel 自动化和 Tkinter GUI 开发。
任务：开发一款移液补偿参数计算桌面软件。
- 输入：天平称重导出的 CSV（每 240 行为一轮，第一轮为预热数据跳过）
- 输出：基于 Excel 模板填入数据的计算表，保留公式和条件格式
关键业务约束：
1. CSV 每通道 30 行 = 10 档×3 次重复，排除偏离中位数 >20% 的异常值
2. S 列枚举 a0×a1 全组合，计算 K = a1·C + a0 − J + F，K 须满足合格范围
3. 从合规组合中选最优（最小化 |K−C|/C 相对偏差和）
4. 导出只填 S 列枚举值，Q 列保留 INTERCEPT/SLOPE 公式，R 列保留调节按钮
5. 用 excel.CalculateFull() 刷新条件格式
6. PyInstaller --onefile 打包，模板通过 --add-data 内置No.65｜用 TraeWork 给静态网站搭建后台
作者：vitoriga ｜ 独立开发者（CourseCore 大学基础课学习平台） ｜ 工具：TraeWork ｜ 阅读约 5 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172285
**用法总结：**让 TraeWork 先做架构判断再动手，用 Supabase 把纯静态站改造成带认证与管理后台的全栈应用。
**场景：**Vite + 原生 JS 的静态站上线后需要管理用户、课程与题目，但认证已关闭、内容全靠改 Markdown 重构建。
**效率提升：**课程与题目管理从「改 Markdown 再重新构建」升级为后台 CRUD，11 个文件改动完成全链路接入。
**成果：**CourseCore 拥有真正可用的 /admin 管理后台，支持用户、课程、模块、题目、试卷增删改查。
一、个人背景介绍
**个人背景：**CourseCore 大学基础课平台的独立开发者，使用 Vite、原生 JS 和 Tailwind CSS 构建静态站点，并通过 Markdown 与 YAML 维护课程、题目和试卷。
**当前痛点：**上线时关闭了登录、注册和管理员能力；内容更新只能修改 Markdown 后重新构建，无法在线管理用户，也缺少安全可控的后台写入链路。
二、提效前后对比
| 能力 | 改造前 | 改造后 |
|---|---|---|
| 内容管理 | 改 Markdown 再重新构建 | /admin 后台在线 CRUD |
| 用户管理 | 无（纯游客） | Supabase Auth + role 校验 |
| 数据来源 | 纯静态构建产物 | Markdown 兜底 + Supabase 覆盖 |
三、我用 TraeWork 怎么解决的
**核心方案：**先明确“谁有权限”和“数据存哪里”，再用 Supabase Auth、数据库 role 与 RLS 建立管理员权限，把静态内容工作流升级为“Markdown 兜底 + Supabase 覆盖 + 静态预渲染”。
实践步骤：
**接入认证与后台：**恢复 Supabase Auth，为 profiles 增加 role，注册 /admin 预渲染路由，并实现用户、课程、模块、题目和试卷等实体的 CRUD。
**补齐数据库数据：**在 MCP 恢复后导入剩余 seed，修复 exam_sections 主键类型，并通过 Node 脚本与 exec_admin_sql RPC 绕过复杂 JSON 限制。
**验证构建链路：**串联 build:data 与 fetch:data，用 Supabase 数据覆盖本地产物；最终完成 291 题数据构建、268 题远端拉取和 460 条路由预渲染。
四、成果展示
最终呈现：
支持用户、课程、模块、题目和试卷 CRUD 的 /admin 后台
Supabase Auth、profiles.role、ensureAdmin 与 RLS 的双层权限保护
Markdown 兜底、Supabase 覆盖、460 条路由预渲染的稳定构建链路
五、实践经验总结
1️⃣ 先做架构判断，别急着写代码
TraeWork 第一步就点出「谁有权限」和「存哪里」，帮我避开了「本地 localStorage 伪后台」的弯路。
2️⃣ 静态站迁数据库要保留兜底
build:data && fetch:data 的串联很重要，MCP 不可用或表为空时站点还能用本地 Markdown 正常构建。
3️⃣ 管理员判定走数据库 role，不走硬编码
改成 profiles.role === 'admin'，避免源码泄露凭据。
4️⃣ MCP 也会掉链子，准备手动兜底
MCP 宕机导致 seed 中断，恢复后靠临时 RPC + Node 脚本才补齐，分布式工具不是 100% 可控。
5️⃣ 预渲染别忘了新路由
/admin 要加进 getStaticPaths，否则直接访问或刷新会 404。
6️⃣ 不同任务用不同模型
写后端需要大上下文，kimi 上下文不足会频繁压缩，换成 1M 上下文的模型后才把任务做完。
六、提示词参考
核心需求提示词
Plain
帮我做一个管理员后台，要能操作用户、课程内容和所有题目；
入口放在用户中心，只有管理员账号才能看到。
请先判断架构：谁有权限、改完存哪里，再给出实现方案。No.66｜用 TraeWork 审计大型项目代码
作者：u445723754628379 ｜ 金融行业项目技术负责人 ｜ 工具：TraeWork ｜ 阅读约 5 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172273
**用法总结：**用子代理并行 + MCP 代码图谱 + 语义检索 + 长上下文汇总，在 TRAE 内闭环完成全量功能与代码质量审计。
**场景：**4 万行、29 个微服务的金融项目准备推广，需确认功能与代码是否达标。
**效率提升：**3-5 天人工审计 → 大半天完成核心排查；共查出 153 项问题，全程免费版、Token 消耗不到 1000 万。
**成果：**分级问题审计报告（P0 17/P1 37/P2 55/P3 44）+ 代码清理方案，60% 以上是传统方法易漏的深层问题。
一、个人背景介绍
**个人背景：**我是一名金融行业项目技术负责人，日常靠 AI 快速分析迭代项目。近期项目准备推广，需要对 4 万行、29 个微服务的代码库做全量审计。
**当前痛点：**纯人工 review 周期太长；传统 AI 关键词搜索又存在全局视野差、语义问题搜不到、批量审计易遗漏三大痛点，漏检率很高。
二、提效前后对比
| 维度 | 传统 grep + 人工 | TRAE 子代理并行审计 |
|---|---|---|
| 周期 | 3-5 天 | 大半天完成核心排查 |
| 覆盖度 | 全局视野差、易遗漏 | 逐方法排查 + 图谱交叉核验 |
| 成本 | 人力成本高 | 免费版，Token < 1000 万，无云端费用 |
三、我用 TraeWork 怎么解决的
**核心方案：**用 TraeWork 的子代理并行任务能力，结合 MCP 代码图谱、代码库语义检索和长上下文汇总，在 TRAE 内闭环完成 4 万行金融项目的全量审计。
实践步骤：
**分批规划审计范围：**按业务重要性把 29 个服务划分为 P0-P3 四个批次，从核心业务到底层服务依次审计，每批次独立闭环、独立修复，避免信息过载。
**并行启动只读子代理：**每批次启动 6 个只读 search 子代理，每个负责 4-5 个服务，从完整性、显性 BUG、业务逻辑、可用性四个维度逐方法排查；子代理独立上下文互不干扰，主代理只负责汇总。
**用代码图谱交叉核验：**因原生检索缺少代码图谱能力，我扩展安装开源 MCP 工具 codebase-memory-mcp，补齐 AST 级依赖分析与调用链追踪；主代理再验证调用链真实性，并对比前后端接口文件校验签名与类型漂移，降低误报率。
四、成果展示
最终呈现：
**分级问题审计报告：**共查出 153 项问题，其中 P0 严重 17 项、P1 功能 37 项、P2 逻辑 55 项、P3 可用性 44 项。
**代码清理方案：**清理 19 个死文件、14 个冗余函数/字段、2 个未使用依赖，并抽取 1 个公共工具文件。
**架构修复结果：**修复 1 项架构问题，60% 以上问题属于传统方法易漏的深层问题。
五、实践经验总结
1️⃣ 审计与修复权限分离
审计阶段子代理统一用 search 只读类型，仅排查不改代码；修复阶段再切换为可写类型，避免 AI 边查边改引入新问题。
2️⃣ 不要等工具配好再开工
MCP 安装与索引构建需要时间，期间可先用内置检索出第一版报告解决 80% 表层问题，工具就绪后再用图谱做深度复核。
3️⃣ 误报也要重点复核
图谱标记的可疑点即便判定为误报，其位置往往也是风险高发区，顺着排查很容易发现被忽略的真实逻辑问题。
六、提示词参考
核心审计指令
Plain
1. 审计规划：帮我对当前代码库做全量审计规划，按业务重要性分成 P0-P3 四个批次，列出每批次服务范围、方法数量和优先级说明。
2. 子代理审计：作为只读审计子代理，针对指定服务模块，从参数完整性、显性BUG、权限逻辑、可用性四个维度逐方法审计，输出问题清单并标注严重等级。
3. 图谱语义查询：通过代码图谱查询所有数据写操作中缺少权限校验的函数，列出函数名、文件路径和上游调用方列表。No.67｜用 TraeWork 审查并重构 App 代码
作者：u174191737583536 ｜ 独立开发者（Flutter + Drift + Riverpod） ｜ 工具：TraeWork ｜ 阅读约 3 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172057
**用法总结：**用 Code 模式的代码理解、根因分析和批量重构能力，先出分级审查报告再逐项修复，每轮跑 flutter analyze 回归。
**场景：**Flutter 记账应用积累了循环依赖、文件锁、冗余字段、内存泄漏、死代码、组件重复等质量债务。
**效率提升：**让 AI 通读出分级报告，比想到哪改到哪 高效得多，且不漏隐性问题。
**成果：**完成 5 个严重问题 + 8 类低级别问题修复，涉及约 20 个文件，flutter analyze 零警告。
一、个人背景介绍
**个人背景：**我是一名独立开发者，正在用 Flutter + Drift + Riverpod 开发记账应用，项目推进到设置模块阶段。
**当前痛点：**项目出现多账本切换触发循环依赖报错、Windows 删除账本文件被占用、单位表存在冗余字段等问题，同时积累了内存泄漏、死代码、组件重复实现等代码质量债务。
二、我用 TraeWork 怎么解决的
**核心方案：**用 TraeWork Code 模式先完成项目级代码理解和根因分析，再按问题严重程度逐项修复，并在每轮修改后用 flutter analyze 做回归验证。
实践步骤：
**先审查再动手：**让 TraeWork 通读
lib/和docs/，产出按严重程度分级的代码质量审查报告，先建立完整问题清单。**修复核心链路问题：**针对循环依赖，采用“filenameKey 不可变”方案并重构 LedgerNotifier，避免重命名时 invalidate 数据库连接；针对 Windows 文件锁，编写 LedgerService，在切换账本前捕获旧 DB 引用，切换后主动
await oldDb.close()释放句柄；针对表设计，去掉冗余 symbol 字段并新增 decimalPlaces 显式定义金额精度。**批量清理低级别问题：**抽取 PinDots/HintBar 公共组件，统一 const，表定义 max 值引用 AppConstants 常量，修复 TextEditingController 泄漏，并为静默异常补充 debugPrint。
**持续回归验证：**每轮修改后运行 flutter analyze，确认修复没有引入新的警告或回归。
三、成果展示
最终呈现：
**分级代码质量审查报告：**先定位循环依赖、文件锁、冗余字段、内存泄漏、死代码和组件重复实现等问题。
**批量重构修复结果：**完成 5 个严重问题 + 8 类低级别问题修复，涉及约 20 个文件。
**回归验证结果：**flutter analyze 达到零警告，数据库架构更干净，组件复用性更好，后续维护成本降低。
四、实践经验总结
1️⃣ 先诊断后开刀
让 AI 通读项目出分级报告，比想到哪改到哪高效得多，也避免漏掉隐性问题。
2️⃣ 建立验证基线
每轮重构后跑一次 flutter analyze，确保零回归，心里有底。
3️⃣ 抽取组件先问归属
核心层（core/）放纯 UI 组件、共享层（shared/）放业务组件，归属搞清楚再挪，避免层间污染。此外善用夜间无需排队的时间，Work 不怎么排队。
No.68｜用 TraeWork 从零搭建量化交易系统
作者：u1307751422107916 ｜ 个人量化交易爱好者 ｜ 工具：TraeWork ｜ 阅读约 6 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172022
**用法总结：**用 Work + Code 完成量化交易系统从 0 到 1 开发：策略引擎、回测系统、实盘 API、Web 可视化、加密打包部署。
**场景：**个人量化交易爱好者需要可自主迭代策略的完整加密货币自动化交易系统。
**效率提升：**先出架构方案再逐模块实现，效率比自己从头想高 10 倍。
**成果：**完整 LC-TradingBot 系统（实盘机器人 + 回测系统 + 可视化界面）。
一、个人背景介绍
**个人背景：**作者是一名个人量化交易爱好者，需要一套完整的加密货币自动化交易系统，用来支撑自主策略迭代。
**当前痛点：**市面上的量化平台要么策略封闭、无法自定义，要么回测和实盘割裂、数据不透明，难以满足从策略开发到实盘验证的一体化需求。
二、提效前后对比（核心回测数据：60天 ｜ 10,000 USDT ｜ 20x 杠杆）
| 品种-周期 | 策略 | 胜率 | 收益率 | 最大回撤 |
|---|---|---|---|---|
| BTC-15m | Martin LC | 75.8% | +4.20% | -2.21% |
| BTC-15m | 固定 SL/TP | 32.6% | -1.39% | -2.32% |
| ETH-1H | Martin LC | 85.3% | +3.44% | -0.70% |
| ETH-1H | 固定 SL/TP | 50.0% | +2.14% | -1.29% |
对比发现：动态退出机制在 15m 周期上将胜率提升了 40+ 个百分点，证明复杂策略开发的价值。
三、我用 TraeWork 怎么解决的
**核心方案：**用 TraeWork + Code 从 0 到 1 搭建 LC-TradingBot，把策略引擎、回测系统、实盘 API、Web 可视化和加密打包部署串成一套完整量化交易系统。
实践步骤：
**构建策略框架：**用 Lorentzian 分类器 + 多层马丁策略，实现信号生成、压力机制、动态止盈止损等复杂逻辑。
**开发回测引擎：**基于历史 K 线搭建完整回测能力，支持多时间框架（1H/15m/5m）、压力模式切换和参数批量对比。
**集成实盘交易：**对接 OKX API（REST + WebSocket），实现自动开仓、加仓、平仓和飞书实时通知。
**搭建可视化界面：**用 Vue3 + Koa 开发管理界面，支持参数配置、回测结果图表和权益曲线展示。
**完成安全打包部署：**用 PyArmor + PyInstaller 打包成独立可执行文件，并用 AES-256-GCM 加密 API 密钥，安全部署到多台机器。
四、成果展示
最终呈现：
**实盘交易机器人：**支持多品种并行交易、自动风控和压力机制保护。
**回测系统：**支持 60 天历史数据回测、策略参数优化和对照组对比。
**可视化界面：**展示实时持仓、权益曲线、信号标注和 K 线图表。
五、实践经验总结
1️⃣ 用 TRAE 做"架构设计 + 代码实现"的闭环
不要只让 TRAE 写代码，要让它帮你设计整体架构。策略引擎、回测流程、API 接口全是 TRAE 先出方案再逐模块实现，比自己从头想效率高 10 倍。
2️⃣ 回测是策略迭代的核心
每改一个参数都要跑回测验证。TRAE 帮忙搭建自动化回测脚本，对比不同参数组合结果，省去大量手动操作。
3️⃣ 安全打包别忽视
量化系统涉及真实资金，API 密钥必须硬件绑定加密。TRAE 实现了 AES-256-GCM + PyArmor 完整方案，打包后的 exe 可直接复制到其他电脑运行。
六、提示词参考
开发类似项目的指令
Plain
我要开发一个加密货币量化交易机器人，基于 xxxx 生成交易信号，使用 xx 策略加仓，需要包含：1) 回测引擎（支持历史 K 线回测、权益曲线、参数对比）；2) 实盘引擎（API、WebSocket 实时价格、自动风控）；3) WebUI（Vue3 + Koa、实时持仓展示、K 线图表）；4) 加密打包（PyInstaller + PyArmor）。请帮我设计整体架构并逐模块实现。No.69｜用 TraeWork 搭建运动视频分析系统
作者：真沒話講 ｜ 软件技术专业大二学生 / 校排球队主攻手 ｜ 工具：TraeWork ｜ 阅读约 5 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172151
**用法总结：**以 Code 模式为主力写代码、Work 模式辅助读规则文档，从 FIVB 规则 PDF 梳理犯规体系，到数据模型、Schema、路由、前端组件一条龙生成。
**场景：**软件专业学生独立开发 VolleyLab 排球视频分析系统全栈 MVP。
**效率提升：**约 1 周 课余时间从零搭出 8000+ 行代码的全栈原型。
**成果：**后端 30+ 接口、前端 5 页面 15+ 组件、80+ 测试用例，热力图与数据看板均可运行。
一、个人背景介绍
**个人背景：**作者是软件技术专业大二学生，也是校排球队主攻手，球龄 9 年，想把排球视频分析系统作为服务球队和课程设计的全栈项目。
**当前痛点：**赛后复盘需要反复拖动手机进度条找回合，效率低；真正开发时又遇到排球规则难代码化、全栈联调吃力、热力图组件没有现成实现、异步分析逻辑复杂、课余时间紧张等问题。
二、我用 TraeWork 怎么解决的
**核心方案：**以 TraeWork Code 模式为主力完成代码生成、Bug 修复和测试生成，用 Work 模式辅助阅读 FIVB 规则 PDF、整理设计思路，按“规则分类 → 数据模型 → 分析引擎 → API 路由 → 前端组件 → 测试验证”的顺序搭建 VolleyLab MVP。
| 我的痛点 | TraeWork 怎么帮我的 |
|---|---|
| 排球规则搞不清，分类体系改了又改 | 把 FIVB 规则 PDF 扔进去梳理犯规分类，生成的枚举每个都标了规则条款号 |
| 全栈联调对不上，字段名来回改 | 从数据模型到 Schema 到前端类型一条龙生成，字段名自动对齐 |
| 热力图组件写不出来，搜不到现成的 | 分 3 轮迭代生成，从基础框架到交互细节逐步完善 |
| 异步逻辑太绕，多线程不会写 | 帮忙设计状态机架构，代码结构清晰、注释完整 |
| 时间不够用，deadline 快到了 | 代码生成速度快，省去大量重复劳动 |
实践步骤：
**梳理规则分类：**把规则 PDF 拖进项目，让 TraeWork 阅读第 6-14 条核心章节，设计失分类型两级分类枚举（6 个一级、20+ 二级），并为每个值标注规则条款号，产出
enums.py。**搭建后端数据结构：**基于枚举生成 SQLAlchemy 数据模型和 Pydantic Schema，核心表包括 User / Video / AnalysisTask / Rally / BallFrame / PoseFrame，并自动处理外键关系与级联删除。
**生成分析引擎与接口：**先生成 mock 版
analysis_engine.py（300+ 行），覆盖 7 步分析流程、线程池、数据库事务、进度更新和取消支持；再基于引擎数据结构生成analysis.py路由（870+ 行、15+ 个接口），包含任务管理、姿态帧、球轨迹、回合、统计数据、参数校验、错误处理和权限校验。**迭代前端核心组件：**用 3 轮迭代完成球场热力图组件，第 1 轮生成 SVG 底图 + Canvas 热力骨架，第 2 轮加入坐标转换、Tooltip 和颜色渐变，第 3 轮完成 DPR 适配与视图切换，产出
CourtHeatmap.tsx（370+ 行）。**补齐看板和测试：**生成
MatchOverview.tsx数据看板页面（6 个统计卡片 + 多种图表），并生成后端 pytest 测试用例（15 个测试文件、80+ 用例）。
三、成果展示
最终呈现：
**VolleyLab 全栈 MVP 原型：**约一周课余时间完成后端 FastAPI 服务 6 模块、30+ 接口和完整认证权限。
**前端分析界面：**完成 React 应用 5 页面、15+ 组件，包含数据看板、走势/饼图、热力图、视频列表和回合列表管理页面。
**可迭代分析底座：**分析引擎当前使用 mock 数据，但 7 步流程状态机、20+ 种犯规分类体系和数据结构已设计完成，后续可直接替换接入真实 AI 模型。
四、实践经验总结
1️⃣ 专业领域项目先让 AI 读规则再写代码
先把规则文档扔给 TraeWork 输出设计方案，确认无误再生成代码，能省大量返工时间。
2️⃣ 全栈项目从底层往上写
最佳顺序：枚举定义 → 数据模型 → Schema → API 路由 → 前端类型 → 前端组件，字段名和类型自动对齐。
3️⃣ 复杂组件分 3 轮迭代
第 1 轮出能跑的骨架，第 2 轮加交互细节，第 3 轮优化性能，每轮都能验证、易定位问题。
4️⃣ 学生党别怕看不懂 AI 代码，边做边学
AI 生成后一定读一遍搞懂原理，不懂就查资料或直接追问，相当于边做项目边学新知识。
5️⃣ 提示词把约束条件列清楚
把要求一条条列出（用线程池、进度存库、标规则条款号、CSS Module、兼容移动端等），越具体改动越少。
6️⃣ 先跑通 MVP 再说，完成比完美重要
用 mock 数据先把前后端跑通、界面做出来，后续再迭代真实功能；结合爱好做项目更有动力。
五、提示词参考
模板 1：读文档 + 设计方案
Plain
先读一下这个文件：{文件路径/内容}
然后基于里面的{相关内容/第X章}，帮我设计{功能/模块}的方案：
- 要求1：{具体要求}
- 要求2：{具体要求}
- 输出格式：先讲设计思路（用我能听懂的话），再给代码模板 2：全栈接口一条龙
Plain
基于下面的数据模型（贴出模型代码），生成完整的 CRUD 接口：
- 后端：FastAPI 路由 + Pydantic Schema（请求/响应）
- 前端：TypeScript 类型 + Axios 封装函数
- 注意：
1. 前后端字段名必须完全一致
2. 统一用 ResponseModel 格式（code/message/data）
3. 分页用 page 和 page_size
4. 代码加中文注释，我要能看懂模板 5：规则相关的代码
Plain
根据 FIVB 排球规则第{X}条，实现{判罚/检测}的函数：
- 规则内容：{贴出规则原文或摘要}
- 输入：{参数列表}
- 输出：{返回什么，比如布尔值+置信度+原因}
- 要求：
1. 代码里用注释标清楚对应的规则条款
2. 边界情况都要处理到
3. 返回结果要说清楚判罚依据
4. 代码写得易懂一点，我是学生No.70｜用 TraeWork 搭建游戏战绩查询网站
作者：今天锻炼了吗 ｜ 零基础 / 多年没碰代码的爱好者 ｜ 工具：TraeWork ｜ 阅读约 2 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172142
**用法总结：**先用 Code 模式与 AI 一起梳理需求、逐步实现，再计划用 Design 模式优化 UI，从 0 到 1 做出自定义战绩网站。
**场景：**基本忘光代码的非程序员想做一个自己和朋友都能用、可自定义指标的 PUBG 战绩网站。
**价值：**不会写代码的人，也能通过学习、沟通和 AI 工具把想法变成可运行的产品。
**成果：**完成可运行的 PUBG 战绩网站半成品，正在做 UI 视觉优化。
一、个人背景介绍
**个人背景：**作者自称“算不上程序员”，多年没碰代码、基础基本忘得差不多，但重新对“用代码做点有意思的东西”产生兴趣。
**当前痛点：**作者想做一个自己和朋友都能用的 PUBG 战绩网站，并按自己的想法决定指标展示、比较方式和功能设计；但从零开发对非程序员来说门槛高，容易卡在需求拆解、代码报错和产品优化上。
二、我用 TraeWork 怎么解决的
**核心方案：**先用 TraeWork Code 模式把 PUBG 战绩网站的模糊想法拆成可执行开发方案，再通过分步确认、问题定位和持续优化推进实现，后续计划用 Design 模式优化 UI。
实践步骤：
**先梳理需求：**第一步不是写代码，而是花约 1 小时和 AI 一起拆解网站要解决的问题、需要哪些页面、数据怎么展示、朋友之间怎么比较，让模糊想法变成明确开发方案。
**设定 AI 协作规则：**要求 AI 不要一次性生成全部代码；每一步先确认逻辑；遇到问题先定位原因再修改；保持代码结构清晰，方便后续扩展。
**逐步实现与排错：**按“提出想法 → 拆解问题 → 逐步实现 → 不断优化”的节奏推进，把过去“写代码 → 报错 → 看不懂 → 放弃”的体验改成可持续迭代的开发过程。
**继续优化视觉体验：**在网站半成品可运行后，继续寻找 UI 方向，并计划用 Design 模式做设计稿、优化视觉，让网站更像真正上线的产品。
三、成果展示
最终呈现：
**PUBG 战绩网站半成品：**完成一个可运行的网站原型，支持按作者自己的想法组织指标展示、对比方式和功能方向。
**可继续扩展的代码结构：**开发过程中通过分步确认和先定位再修改，保持代码结构清晰，方便后续继续加功能。
**后续 UI 优化方向：**半成品跑通后，正在继续寻找 UI 方向，计划用 Design 模式优化视觉，让网站更接近可上线产品。
四、实践经验总结
1️⃣ 先和 AI 梳理需求再动手
写代码前先花时间把想法拆解成可执行方案，从模糊想法变成明确页面与功能清单。
2️⃣ 给 AI 立"开发规则"
要求不要一次性生成全部代码、每步先确认逻辑、先定位原因再修改、保持结构清晰，体验会显著改善。
3️⃣ 把编程当成迭代对话
用"提出想法 → 拆解问题 → 逐步实现 → 不断优化"的节奏替代"报错就放弃"，零基础也能坚持完成。
No.71｜用 TraeWork 制作在线刷题网站原型
作者：u3235231768518020 ｜ 中学生 CSP 竞赛备赛选手 ｜ 工具：TraeWork ｜ 阅读约 4 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172025
**用法总结：**用 Design + Work 分段描述页面需求，批量生成整套统一风格的移动端 OJ 平台界面原型。
**场景：**为 CSP-J/S 竞赛备赛设计一套轻量化专属在线刷题 OJ 的产品界面原型。
**效率提升：**手绘 + 设计工具预估 4 小时 → 实际 40 分钟完成，约 6 倍提效。
成果：「CodeZone 代码域」完整 8 大核心页面移动端界面原型。
一、个人背景介绍
**个人背景：**作者是一名中学生 CSP 竞赛备赛选手，长期练习 C++ 算法。
**当前痛点：**市面刷题网站布局不符合自己的备赛习惯，作者想做一套轻量化、面向 CSP-J/S 的专属在线 OJ 原型，并内置 AI 助手用于代码复盘和知识点检索；但手绘或用 Figma 搭建多页面原型耗时长，也缺少一站式快速生成页面效果图的方案。
二、提效前后对比
| 环节 | 使用前 | 使用后 |
|---|---|---|
| 整套多页面原型产出 | 手绘 + Figma 预估至少 4 小时 | 连续生成迭代仅 40 分钟 |
| 视觉一致性 | 手工搭建难以统一 | 全套连贯统一的产品界面效果图 |
三、我用 TraeWork 怎么解决的
**核心方案：**用 TraeWork Design + Work 分段描述页面需求，先统一产品视觉规范，再逐页生成移动端 OJ 平台界面，并持续微调竞赛平台所需的数据模块和交互细节。
实践步骤：
**分段生成页面原型：**在 TraeWork Design 内分段描述每个页面需求，批量生成移动端网页 UI 效果图。
**统一视觉规范：**提前约定圆角卡片、浅绿主题色、扁平化简约竞赛网站风格，保证整套页面连贯统一。
**逐页补齐核心功能：**依次生成首页、题库列表、题目详情、代码编辑器、个人中心，以及内置 AI 助手 Lumen 微光助手等页面。
**用 Work 整理和迭代需求：**通过 Work 模块整理全部页面需求文案，迭代调整按钮布局、标签样式和数据展示模块，包括 AC 率、倒计时、刷题统计、成就徽章。
**打磨竞赛平台细节：**持续微调 CSP 考试倒计时、代码模板区域、提交记录面板、打卡热力图等竞赛平台特色模块。
四、成果展示
最终呈现：
**CodeZone 移动端 OJ 原型：**完成一套面向 C++ 算法刷题和 CSP-J/S 备赛的移动端界面方案。
**8 大核心页面：**包含平台首页、Lumen 微光 AI 助手、题库列表页、题目详情页、在线代码编辑器、用户个人主页、成就徽章系统页面和 AI 知识库分类页面。
**统一视觉系统：**形成浅薄荷绿、圆角白色卡片、简约扁平化的移动端竞赛平台风格，并覆盖倒计时、AC 率、提交记录、打卡热力图等数据模块。
五、实践经验总结
1️⃣ 先锁定全局设计规范
批量生成多页面界面时，第一段先锁定全局设计规范（配色、圆角、字体、卡片样式），后续所有页面复用同一套描述，保证视觉统一。
2️⃣ 拆分页面逐个生成
网页类原型生成尽量拆分页面逐个生成，不要一次性塞入太多页面需求，减少画面元素错乱。
3️⃣ 重点标注数据模块
平台类产品重点标注数据模块（倒计时、进度条、表格列表、状态标签 AC/CE/RE），AI 更容易还原 OJ 平台真实观感。
六、提示词参考
风格前缀 + 页面示例指令
Plain
基础风格固定前缀：
移动端网页界面，简约扁平化，大量圆角白色卡片，主色调浅薄荷绿，干净清爽，程序竞赛刷题网站，白底，柔和阴影，现代 UI 设计，手机竖屏截图质感
页面示例指令：
生成 OJ 平台首页，顶部导航栏 CodeZone，中部大卡片放置 CSP 竞赛倒计时模块，下方四个功能按钮：开始刷题、入门赛、月赛、讨论社区，右下角悬浮圆形按钮打开 AI 助手。No.72｜用 TraeWork 自动生成游戏界面
作者：Wayne ｜ 游戏开发 ｜ 工具：TraeWork ｜ 阅读约 4 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/171991
**用法总结：**用 Code 模式 + Funplay MCP for Cocos，让 TraeWork 理解游戏引擎并自动拼装 Cocos Creator 的 UI 界面。
**场景：**游戏开发中逻辑代码已易由 AI 完成，但游戏界面仍需手工拖拽拼装，费时。
**效率提升：**一个转场加载页 UI，TraeWork 拼装仅用 12 分 30 秒，替代原本纯手工操作。
**成果：**根据参考图自动生成的 Cocos 加载页 UI，节点树完整实现需求。
一、个人背景介绍
**个人背景：**作者是一名游戏开发者，已经能借助 AI 更轻松地完成逻辑代码开发。
**当前痛点：**游戏界面仍需要大量手工拖拽拼装，费时且难以交给通用模型处理；Cocos Creator 属于游戏引擎场景，Codex、Claude Code 等通用工具此前都难以正确完成拼 UI，需要专门的 MCP 让 AI 理解引擎操作。
二、我用 TraeWork 怎么解决的
**核心方案：**用 TraeWork Code 模式接入 Funplay MCP for Cocos（github.com/FunplayAI/funplay-cocos-mcp，也可在 Cocos Store 下载），让 TraeWork 能操作 Cocos Creator，并根据参考图自动拼装转场加载页 UI。
实践步骤：
**配置 Cocos MCP：**在 Funplay MCP 中选择 Trae，点击一键配置，完成 TraeWork 与 Cocos Creator 的连接准备。
**启动引擎操作能力：**运行 MCP 服务后，通过 TraeWork 操作 Cocos Creator，让 AI 能理解并修改游戏场景中的 UI 节点。
**输入参考图与提示词：**把要制作的转场界面参考图和提示词发给 TraeWork，明确背景、进度区域、Label、ProcessBar、百分比等组件需求。
**调用 MCP 自动拼装：**TraeWork 根据要求调用 MCP 完成 UI 拼装，并通过节点树检查生成结果。
三、成果展示
最终呈现：
**Cocos 转场加载页 UI：**根据参考图自动生成加载页界面，包含背景、进度区域、进度描述、进度条和进度百分比。
**完整节点树结果：**TraeWork 调用 MCP 完成拼装后，节点树能够对应需求并支撑后续检查。
**可复用的引擎 UI 工作流：**通过 Funplay MCP for Cocos 让 TraeWork 理解 Cocos Creator 操作，替代原本纯手工拖拽拼装流程，本次拼装耗时 12 分 30 秒。
四、实践经验总结
1️⃣ 效果由产品设计决定
最终效果图没有参考图漂亮，是产品故意保持克制，并非 AI 能力不足。
2️⃣ 可自动替换背景图
通过观看 TraeWork 思考过程可发现，如果事先准备好背景图，TraeWork 也能帮忙自动换上去。
3️⃣ 引擎类任务依赖专用 MCP
通用大模型未针对 Cocos Creator 训练，接入专门的 Funplay MCP 后才能让 AI 真正理解引擎、正确拼装 UI。
五、提示词参考
Cocos 加载页 UI 生成指令模板
Plain
在当前 Cocos 场景里创建一个加载页 UI，见参考图。包含背景图片、进度区域背景图片，进度描述 Label，进度条 ProcessBar 和进度百分比 Label。优先使用 execute_javascript，创建后检查层级并截图验证。No.73｜用 TraeWork 批量分析测试 Case
作者：AI 算法方向实习生 ｜ 工具：TraeWork（Work + Code）｜ 阅读约 6 分钟
**用法总结：**把 badcase 的 CSV/Excel 丢给 TraeWork，先整体摸底，再按归因框架逐条分类分析错误原因。
**场景：**多模态分类模型迭代后的 badcase 归类与归因分析。
**效率提升：**人工分析几百条 badcase 要大半天，现在 1 个多小时 就能拿到结构化结论。
**成果：**一份完整 badcase 深度分析报告：错误分布、Top 混淆类别、逐条归因、可优化 vs 合理错误占比、优化建议。
一、我是谁 & 遇到什么问题
我是 AI 算法方向实习生，在做多模态分类模型。每次迭代都会跑出几百条 badcase，需要一条条看、归类、分析原因（模型没学好 / 数据有问题 / 边界模糊），光逐条看整理就要大半天。
二、我怎么用 TraeWork 解决
用批量数据处理 + 智能分类归因 + 多维度统计能力：先做整体摸底——按错误类型分布、按类别统计准确率、找出最易混淆的类别对。
再挑重点类别深挖，逐条读样本，按我给的框架判断原因（模型能力不足 / 数据标注问题 / 信息不足 / 边界模糊），并分析是什么特征导致误判。整个过程像跟同事讨论，随时追问。
三、我做出了什么
最终呈现：
- 一份完整 badcase 深度分析报告：整体错误分布、Top 混淆类别排名、重点类别逐条归因、「可优化」vs「合理错误」占比、误导性特征分析、优化建议。
四、经验 & 技巧总结
**先整体后局部，别上来就一条条看。**先让它做整体统计，找出占比最高的错误类型和最严重的混淆对，再针对性深挖。
**给它一个「归因分类框架」，输出质量会质变。**把关心的分类维度告诉它，再给 2-3 个示例，分类准确率明显提升。
**对话式分析比一次性出报告更好用。**先看整体，发现问题继续往下挖，它会记住上下文。
五、提示词参考
整体统计 + 单类目深度归因两段式指令（节选）：
Plain
【整体统计】我有一个 badcase CSV，字段含 id/true_label/pred_label/content/score。
请做整体分析：总体错误数量占比；按真实标签统计各类别错误率取 Top10；
统计最常见混淆对取 Top20；总结主要问题与优先关注方向。
【单类目深度归因】筛选出 [某类别] 的所有错误样本逐条分析，分类为：
A 模型能力问题 / B 数据问题 / C 边界模糊 / D 信息不足，
每条给出类型、子类和 1-2 句理由（引用原文）；
最后汇总各类型占比、典型例子和针对该类别的优化建议。No.74｜用 TraeWork 生成技术调研报告
作者：taro ｜ 前端开发者 ｜ 工具：TraeWork ｜ 阅读约 4 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/173524
**用法总结：**只说一句话，TraeWork 自动联网检索官方文档与社区文章，整合成结构化 HTML 调研报告，并自动生成架构流程图与对比表格，浏览器直接打开。
**场景：**技术选型 / 新技术调研
**效率提升：**零散搜索东拼西凑 —— 到一份系统报告 10 章 一次成型
**成果：**一份微前端(qiankun)完整调研 HTML，含 10 章、2 张架构流程图、6 张对比表、多段可复用代码与 10 个引用来源
一、个人背景介绍
**身份：**前端开发者，团队要上微前端架构，需要快速系统搞懂 qiankun。
**痛点：**学新技术三条老路都不理想——B 站视频干货密度低、Google 博客东拼西凑靠运气、直接问 AI 得到一大段纯文本看完就忘也存不下来。
二、我用 TraeWork 怎么解决的
**模式：**Work
**用到的能力：**联网检索 + 长上下文整合 + HTML 报告生成 + Mermaid 架构图
**做法：**只说一句话，它自动去搜官方文档、社区技术文章、框架对比资料，整合成结构化 HTML 报告，并自动生成架构流程图与对比表格。
三、成果展示
最终呈现：
**主交付物：**一份微前端(qiankun)完整调研 HTML。
**核心内容：**10 章、2 张架构流程图、6 张对比表、多段可复用代码与 10 个引用来源。
**成果补充：**一份微前端(qiankun)完整调研 HTML，含 10 章、2 张架构流程图、6 张对比表、多段可复用代码与 10 个引用来源。
| 交付物 | 内容 |
|---|---|
| 调研报告 | 10 章：概念、方案对比、qiankun 架构原理、核心 API、子应用生命周期、实战搭建、问题排查、选型建议等 |
| 可视化 | 2 张架构流程图 + 6 张对比表格 + 目录导航 |
| 可复用 | 多段代码示例 + 10 个引用来源，浏览器直接打开 |
四、实践经验总结
1️⃣ 学新技术直接让它出"结构化报告"，而不是聊天式回答
聊天式回复看完就忘、存不下来；一份带目录、图表、来源的 HTML 报告可以反复看、随时查。
2️⃣ 一句话点明"以谁为例"，检索更聚焦
指定"以 qiankun 为例"，让它的联网检索和对比表都围绕一个主线展开，不发散。
3️⃣ 保留引用来源，报告才可信可追溯
报告自带 10 个引用来源，遇到存疑处可回到原文核对，比单篇博客更系统。
五、提示词分享
Plain
讲解一下微前端，以 qiankun 为例，做一份调研报告，让我快速理解并初步掌握No.75｜用 TraeWork 实现研发效能可视化
作者：茉卷 ｜ Team Leader ｜ 工具：TraeWork ｜ 阅读约 6 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/173004
**用法总结：**把研发效能复盘拆成三段流水线——先用 dev-effectiveness-git Skill 抽取 Git 事实，再用飞书多维表格沉淀筛选，最后用 html-report Skill 展开成可视化汇报页面。
**场景：**研发效能复盘 / 团队管理
**效率提升：**把重复、易产生口径争议的管理工作，拆成 可复用、可检查 的流水线
**成果：**基于 openclaw 分析近两月提交（18,834 条提交、764 位作者）的明细排行 + 飞书多维表格 + 可视化 HTML 报告
一、个人背景介绍
**身份：**茉卷，被老板安排分析组内研发效能，要求公正公开、不掺杂个人操作。
**痛点：**数据拿到后很难变成可讨论的结论——口径易漂移（增删行/新增行、按姓名/按邮箱聚合）、"提交多≠效能高"、feature/bugfix 分类费时、CSV/飞书表/汇报图三处交付物彼此断开。
二、我用 TraeWork 怎么解决的
**核心方案：**没有一上来就"分析一下研发效能"，而是先把工作拆成三段，每段有明确输入输出，上一段产物直接喂下一段：
实践步骤：
**第一步 抽取事实：**用自己沉淀的 dev-effectiveness-git Skill 生成提交明细和排行，不让 AI 凭印象下结论。
**第二步 飞书沉淀：**通过飞书工具建立多维表格，沉淀并筛选数据。
**第三步 可视化：**调用 html-report Skill 把数据展开成适合汇报的可视化页面。
三、成果展示
最终呈现：
**主交付物：**基于 openclaw 分析近两月提交（18,834 条提交、764 位作者）的明细排行 + 飞书多维表格 + 可视化 HTML 报告。
**效率表现：**把重复、易产生口径争议的管理工作，拆成 可复用、可检查 的流水线。
四、实践经验总结
1️⃣ 先抽取事实，别让 AI 凭印象下结论
用 Skill 生成客观的提交明细和排行，把"算数"和"下判断"分开。
2️⃣ 把工作拆成有接口的流水线
Git 抽取 → 飞书沉淀 → HTML 报告，每段输入输出明确，数据更新时不用三处重做。
3️⃣ 固定口径，避免争议
统一按邮箱还是姓名聚合、是否排除 Bot、增删行口径，先定标准再统计，结论才服众。
五、提示词分享
第一条指令：先让 Skill 抽取事实
Plain
以开源项目 openclaw 为例，调用 dev-effectiveness-git Skill，
分析近两个月的 Git 提交，生成提交明细和排行；
固定统计口径（按邮箱聚合、排除 Bot 账号、明确增删行口径），
不要凭印象下结论，只输出可核对的事实数据。No.76｜用 TraeWork 审查代码风险
作者：茉卷 ｜ 产品经理 ｜ 工具：TraeWork ｜ 阅读约 6 分钟 ｜ 原帖：https://forum.trae.cn/t/topic/172929
**用法总结：**产品经理把 TraeWork 当"QA 助手"，把定标准、批量审查、生成报告和同步飞书串成一条六步流水线，上线前抽检代码提交。
**场景：**产品质量 QA / 上线前代码抽检
**效率提升：**审 20 个 commit 只投入约 20 分钟，产出 1 个飞书多维表格 + 6 篇重点风险说明
**成果：**每条风险都带变更证据、触发路径、影响判断和验证建议，可直接发给研发确认
一、个人背景介绍
**身份：**AI 原生工具小团队的产品经理，团队没有泾渭分明的岗位边界，人人要当多面手。
**痛点：**产品经理不能只写 PRD、验收页面就交差，还要在上线前抽检代码提交，看需求有没有被错误实现、关键链路有没有被改坏、数据和兼容性风险有没有被遗漏。
二、我用 TraeWork 怎么解决的
**核心方案：**把 TraeWork 当 QA 助手，用一套六步工作流，以 openclaw 的代码 review 为例，审核近期 20 个 commit：
实践步骤：
**情报输入：**先建立本次上线的变更全景，把代码提交映射到需求和用户链路，分清哪些影响登录/支付/数据迁移等核心路径。
**定标准 + 批量审查：**把需求和业务风险翻译成可执行的审查标准，给 AI 设置明确的证据门槛和人工校验点。
**生成报告 + 同步飞书：**每条风险给出变更证据、可行触发路径、影响判断和验证建议，接入团队上线流程推动闭环。
三、成果展示
最终呈现：
**主交付物：**投入约 20 分钟，得到 1 个飞书多维表格和 6 篇重点风险说明文档，每条都能直接发给研发确认。
**成果补充：**每条风险都带变更证据、触发路径、影响判断和验证建议，可直接发给研发确认。
**效率表现：**审 20 个 commit 只投入约 20 分钟，产出 1 个飞书多维表格 + 6 篇重点风险说明。
四、实践经验总结
1️⃣ 先建变更全景，再谈"有没有问题"
一上来就让 AI 看 commit 容易忽略变更规模，先把提交映射到需求和用户链路。
2️⃣ 给 AI 设证据门槛和人工校验点
把业务风险翻译成审查标准，要求每条风险给出变更证据和触发路径，技术结论仍由研发确认。
3️⃣ 明确边界：AI 辅助抽检不替代 Code Review
这是 AI 辅助的静态质量抽检，不替代研发 Code Review、自动化测试、安全审计和上线审批。
No.77｜用 TraeWork 做 iOS 需求调研与代码探索，每个需求省 1-3 小时
背景：多闪 iOS 客户端开发新人 ｜ 工具：TraeWork（Work / Code 模式）｜ 阅读约 4 分钟
**用法总结：**写一套面向 iOS 需求调研场景的 Research Prompt，交给 TraeWork 在本地 Aweme 仓库运行，自动完成读 PRD/Meego、代码检索、调用链路梳理、埋点/Settings/AB 检查，并按团队模板输出结构化技术调研飞书文档。
**场景：**抖音 iOS 主仓 Aweme 是超大规模 Monorepo，新人拿到需求后要理解 PRD、在几十万行代码里定位改动范围、找出上下游调用链路。
**效率提升：**需求进入编码前的准备时间从 1-3 小时压缩到约 20 分钟，且调研更系统、遗漏更少。
**成果：**一套可复用的「iOS 需求技术调研」Research Prompt，以及自动生成的标准调研文档（需求概述、改动链路、可复用模块、埋点/Settings/AB 清单）。
一、个人背景介绍
我是刚入职不久的多闪 iOS 客户端开发新人。抖音 iOS 主仓 Aweme 是一个超大规模的 Monorepo，业务模块、插件、多应用变体交织在一起，新人上手成本非常高。每拿到一个新需求，我都要先做三件事：理解 PRD/Meego、在几十万行代码里定位改动范围、找出上下游的调用链路。如果全靠人工翻代码、翻文档、找负责人，每个需求在「真正开始写代码之前」就要花掉 1-3 小时，而这段时间对交付是没有产出的，非常痛苦。
二、提效前后对比
| 方式 | 编码前的准备耗时 |
|---|---|
| 人工翻代码、翻文档、找负责人梳理链路 | 每个需求 1-3 小时，且容易遗漏 |
| 用 TraeWork 跑 Research Prompt 自动调研 | 约 20 分钟，结果更系统 |
三、我用 TraeWork 怎么解决的
我写了一个专门面向 iOS 需求调研场景的 Research Prompt，把它交给 TraeWork / Trae 在本地 Aweme 仓库中运行，整个工作流分三个阶段。 第一阶段是阅读并理解需求：抓取 Meego/PRD 内容，明确 scope 边界和核心角色（Tech Owner / QA / PM 等）。第二阶段是本地代码库调研（确保在 develop 分支）：识别可复用的 UI/交互模块、已有或需新增的埋点、可远程下发的 Settings 开关，以及对应的 A/B 实验。 第三阶段是明确代码改动范围：对改造类需求列出完整调用链路，精确到源码文件、class/struct、function/property；对新增功能则明确归属模块和周边视图依赖，最后基于团队模板生成一份结构化的飞书调研文档。我只需要在它产出的调研结果上做少量确认和补充，就能直接进入编码阶段，不用再从零开始「人肉 grep」代码库。
四、成果展示
沉淀了一套可复用的「iOS 需求技术调研」Research Prompt，拿到新需求直接丢给 TraeWork 即可；它会按我定义的模板自动生成标准的 iOS 技术调研飞书文档，包含需求概述、改动链路、可复用模块、埋点/Settings/AB 清单等。每个需求进入编码前的准备时间从 1-3 小时压缩到约 20 分钟，配合 TraeWork Remote 还能在午休、下楼散步的间隙让 AI 帮我把调研做完，做好的方案甚至可以继续交给下一个 AI 做代码实现。
五、实践经验总结
1️⃣ 明确给 Agent「边界」
在 Prompt 里强制要求「没有明确 Meego/PRD 时直接停下询问」，避免 AI 在目标模糊时自己脑补方案，产出一堆无效内容。
2️⃣ 调研阶段禁止改代码
让 Agent 只做 read-only 的检索和梳理，输出的是文档不是 patch，既能保证结果可控，也让新人有时间理解方案再动手。
3️⃣ 结果必须落到团队模板
不是让 AI 随便写，而是基于团队已有的调研文档模板填充内容，这样输出能直接在评审中使用，不用二次整理格式。
4️⃣ 仓库上下文要给足
显式告知分支（develop）、代码根目录（~/Aweme/）、目标应用（多闪 iOS），避免 Agent 在其他应用变体或分支里误判。
六、提示词参考
Plain
你是技术调研助手，你要做的是根据代码库 <repo-path> 和指定的需求文档做任务拆解和规划，但不需要做代码的更改，只做多闪 iOS 客户端的技术调研。
在执行计划任务之前，首先明确目标：如果上下文中没有明确的 meego 链接或者 PRD 文档，或者目标不唯一、不明确，直接停下，然后明确询问具体要调研哪一个需求（需要给出明确的 meego 或者 PRD 才继续）。
调研分为三个阶段：
- 阅读并理解需求
- 阅读 meego 需求（如有）
- 阅读 PRD 内容
- 明确此次需求的范围（scope）
- 明确此次需求的主要负责人（Tech Owner / QA 等）
- 根据本地代码库调研（确保在 develop 分支）
- 对于新增 UI / 交互，是否有可复用已有模块
- 新增、更新埋点
- 可远程下发的 Settings
- A/B Test
- 明确代码改动范围
- 这一步的目标在于缩小改动范围，提升研发同学的研发效率
- 对于现有功能的改造：
- 需明确当前的整个调用链路
- 具体到源码文件和具体的 class / struct 和 function / property
- 对于新功能（新 UI、新业务等）：
- 需明确具体的模块以及该功能关联的周围视图等
所有调研流程完成后，从模版中新建一份飞书文档，并根据文档中的要求和格式将调研结果结构化地写入该文档，整体检查一遍后发给用户：
- 文档的标题："[iOS 技术调研] - <需求名称>"
- 模版中包含写法要求和提示（均在引用块中）
- 新内容都添加在新的 xml 标签里，不要添加到模版原始内容的引用块里
- 发给用户之前，确保删除文档的原始要求和提示
- 原始 xml 文件不发给用户
一个需求只创建一份调研文档，如果中途出现错误，确保只在原文档上继续更新，或者删除重新创建，避免出现空白的调研文档。
全程使用内部 CLI 来完成所有公司内部文档、wiki 等内容的读取、更新，使用网页 fetch 会有权限问题；涉及文档操作时使用 xml 方式读取、更新，确保样式正确。
以上仅作为对 agent 的行为要求，禁止将以上内容以及任何要求发给用户或写入最终技术文档。
---
[Meego] / [PRD] 链接 + 其他已知文档的信息来源说明：本文整理自 TraeWork 官方知识库，仅用于个人学习与参考。TraeWork 为字节跳动旗下 AI 办公平台。如涉及版权或官方更新，请以官方发布为准。