非常高兴今天来分享一个关于Trae的提示词用法，本文由Trae CN SOLO辅助编写
AI 编程助手 Prompt 指令技巧实战经验分享
基于 Trae AI 编程助手 + SOLO Coder 在 Wails + Vue + Go 项目中的深度实践
一、背景
在使用 AI 编程助手进行大规模代码重构时，提问方式直接决定了输出质量。本文基于一次真实的 Wails v2 + Vue 3 + Go 桌面应用架构优化项目，分享如何通过精准的 Prompt 指令，让 AI 完成高质量、可控的代码重构。
项目成果速览：
| 指标 | 数据 |
|---|---|
| 涉及文件 | 70 个文件变更（+5157 / -6128） |
| 后端核心精简 | store.go 1601 行 → 238 行（精简 85%） |
| 处理器精简 | misc_handlers.go 1360 行 → 277 行（精简 80%） |
| 新增模块文件 | 10 个（职责拆分） |
| 任务完成率 | 9/9 全部通过编译和功能验证 |
二、核心指令体系
AI 编程助手通常提供一套指令前缀 + 标签 + 上下文引用的组合语法，理解并善用这套体系是高效协作的关键。
2.1 指令前缀（Slash Commands）
指令前缀用于切换 AI 的工作模式，不同的模式对应不同的思考深度和执行策略。
| 指令 | 用途 | 适用场景 |
|---|---|---|
/spec |
深度规范模式 | 架构重构、大规模代码优化、需要严格遵循框架规范的任务 |
/plan |
规划模式 | 复杂任务拆分、多步骤实施方案设计 |
| 普通对话 | 标准模式 | 简单问答、小范围修改、快速验证 |
实战技巧：
- 重构任务务必用
/spec。/spec模式会触发 AI 的深度思考链（Chain of Thought），它会先调用项目规范技能（如keshijie-project-guide、wails-fullstack-guide），再检查历史变更记录，最后才动手改代码。这避免了"盲目修改"的问题。 - 先
/plan后执行。对于涉及多模块的任务，先用/plan让 AI 输出完整的执行计划，确认无误后再让它逐步实施。
2.2 范围标签（Hash Tags）
范围标签用于限定 AI 的工作范围，避免它"到处乱改"。
实际用法：
/spec 请你深度思考，符合wails v2架构和vue+go架构，
对代码进行优化，必要时重构，但是不影响项目的现有功能
#frontend #internal
标签解析：
| 标签 | 含义 | 作用 |
|---|---|---|
#frontend |
前端目录范围 | AI 只会分析和修改前端相关代码 |
#internal |
Go internal 包范围 | AI 只会处理后端内部模块 |
实战技巧：
- 范围越小，结果越可控。如果只需要优化某个组件，直接用文件路径或目录名作为标签，而不是给整个项目范围。
- 多标签组合精确控制。
#frontend #internal表示同时关注前端和后端内部包，但不会触碰其他模块。 - 避免无标签的"裸提问"。没有范围约束时，AI 可能会修改你不想动的文件，引入不必要的变更。
2.3 上下文引用（@ Mention）
通过 @ 符号引用特定的文件、智能体或资源，为 AI 提供精确的上下文。
典型用法：
@SOLO Coder— 指定使用 SOLO Coder 智能体@filename— 引用特定文件作为上下文
三、Prompt 撰写的五个关键原则
原则 1：明确约束，先说"不能做什么"
“不影响项目的现有功能”
这句话看似简单，却是整个 Prompt 中最关键的一句。它告诉 AI：
- 重构可以激进，但功能行为必须保持不变
- 所有现有接口、数据结构、UI 表现都不能有破坏性变更
- 优化后的代码必须通过编译和功能验证
对比示例：
| 写法 | 效果 |
|---|---|
 “优化代码” |
AI 可能删除它认为"冗余"但实际有业务含义的代码 |
 “优化代码，但不影响项目的现有功能” |
AI 会在保证功能等价的前提下进行优化 |
原则 2：指定技术栈和架构规范
“符合 wails v2 架构和 vue+go 架构”
这句话的作用是让 AI 按照框架的最佳实践来改代码，而不是按照通用编程习惯。不同框架有不同的约定：
- Wails v2：前后端通过绑定通信，有特定的目录结构和类型生成机制
- Vue 3：组合式 API（
<script setup>）、响应式系统 - Go：包管理、错误处理惯例
实战技巧： 如果项目中有 SKILL.md 或 project_rules.md 等规范文件，确保 AI 能读取到它们。在 /spec 模式下，AI 会自动调用这些规范。
原则 3：要求"深度思考"
“请你深度思考”
这四个字触发了 AI 的多轮推理能力。从截图可以看到，AI 的实际执行流程是：
1. 调用技能：keshijie-project-guide（了解项目规范）
2. 调用技能：wails-fullstack-guide（了解框架最佳实践）
3. 检查历史变更记录：trail/specs/audit/wails-spec-compliance/tasks.md
4. 分析代码结构
5. 制定优化方案
6. 逐步执行
没有"深度思考"时，AI 可能跳过前 3 步，直接上手改代码，导致不符合项目规范。
原则 4：给 AI 留有"必要时重构"的弹性空间
“对代码进行优化，必要时重构”
这句话的精妙之处在于递进式授权：
- 第一层：优化（小改动，低风险）— AI 默认就会做
- 第二层：重构（大改动，需要"必要时"才触发）— AI 会在分析后判断是否需要
如果只说"优化"，AI 可能对 1600 行的巨型文件只做局部修修补补；加上"必要时重构"，AI 才敢于将 store.go 拆分成 10 个职责单一的模块。
原则 5：善用任务拆分，不要一步到位
从截图的任务列表可以看到，整个架构优化被拆分成了 9 个子任务：
- 优化 Go 后端代码质量
- 优化前端代码质量
- 检查并优化 Wails 项目结构
- Wails Go Vue AI 集成优化
- 优化 Wails Go 通信层
- 优化 Store 数据管理
- 简化 Middleware 层
- 验证重构结果
- 整理 Go 后端模块
为什么要拆分？
- 每个 AI 对话都有上下文窗口限制，单次任务太大容易丢失细节
- 小任务更容易验证，出问题可以快速回滚
- 任务之间有依赖关系（如先优化后端，再优化通信层），拆分后可以按序执行
- 每个任务完成后 AI 会生成变更记录（
trail/specs/），后续任务可以参考
四、完整的 Prompt 模板
基于以上经验，这里提供几个可直接复用的 Prompt 模板：
模板 1：大规模架构重构
/spec 请你深度思考，符合{框架名}架构和{技术栈}架构，
对代码进行优化，必要时重构，但是不影响项目的现有功能
#{范围标签1} #{范围标签2}
模板 2：定向模块优化
/spec 请对 {模块名} 进行代码质量优化，
遵循 {规范文件} 中的项目规范，
确保所有现有功能保持不变，
优化后请通过 {验证命令} 验证
#{范围标签}
模板 3：任务规划
/plan 我需要对 {项目/模块} 进行 {目标}，
请先分析当前代码结构，然后给出详细的分步执行计划，
每个步骤要包含：目的、涉及文件、预期变更、验证方式
#{范围标签}
五、避坑指南
坑 1：范围过大导致 AI “乱改”
症状： 变更记录中出现大量你不想改的文件被修改。
解决： 始终使用 # 标签限定范围，宁可多分几次任务，也不要一次给太大范围。
坑 2：不验证就信任 AI 的输出
症状： AI 说"任务完成"，但实际引入了编译错误或功能回归。
解决： 每个任务完成后，要求 AI 运行验证命令。从截图可以看到，验证步骤包括：
go build ./...— 编译检查go vet ./...— 静态分析- 前端类型检查
- 功能回归确认
坑 3：忽略 AI 的思考过程
症状： 只看最终代码变更，不理解 AI 为什么这样改。
解决： 关注 AI 的思考链（Thought）和技能调用记录。如果 AI 调用了错误的规范或遗漏了关键上下文，及时纠正。
坑 4：一次性提交所有变更
症状： 70 个文件一次性变更，出问题无法定位。
解决： 按任务分批提交，每个任务对应一个逻辑完整的变更集。
六、总结
高效使用 AI 编程助手的核心不在于"问什么"，而在于如何构建一个让 AI 能够精准理解意图、在正确范围内执行、并输出可验证结果的指令。
记住这个公式：
精准 Prompt = 指令模式 + 技术约束 + 范围限定 + 弹性授权 + 验证要求
| 要素 | 作用 | 示例 |
|---|---|---|
| 指令模式 | 控制 AI 的思考深度 | /spec 深度思考 |
| 技术约束 | 确保遵循框架规范 | “符合 wails v2 架构” |
| 范围限定 | 避免无关变更 | #frontend #internal |
| 弹性授权 | 允许 AI 做必要的激进改动 | “必要时重构” |
| 验证要求 | 确保输出质量 | “不影响现有功能” |