本文作者：胡逸涛，TRAE 开发者用户
🚀 AI 开发四步法
在开始具体实践之前，先明确 AI 辅助开发的完整流程：
-
第一步：需求分析与技术文档转换 - 将产品需求转换为 AI 可理解的技术文档，关键是结构化描述，明确输入输出，定义验收标准
-
第二步：接口设计与数据建模 - 定义清晰的 API 协议和数据模型，保持简单，考虑扩展性，遵循设计原则
-
第三步：代码生成与业务逻辑实现 - 利用 AI 生成基础代码，人工实现核心业务，人机分工明确，AI 做重复工作，人工做决策
-
第四步：测试验证与文档同步 - 生成测试代码，及时文档更新
🎯 核心思路
人机分工很关键：
我们负责：
-
架构决策： 决定技术选型、系统设计和数据流向，把控整体方向
-
核心业务逻辑实现： 把最复杂、最重要的那些业务逻辑写好，处理边界情况和性能问题
-
代码 review： 检查代码质量，发现潜在问题，保证团队代码标准一致
TRAE 负责：
-
重复劳动： 处理那些重复性、机械性的编码工作，比如 CRUD、配置文件等
-
文档同步： 代码变更后自动更新相关文档，保持文档和代码同步
-
测试用例： 生成和维护各种测试用例，覆盖主要功能和边界场景
📋 完整工作流
这里我以开发一个简单的审批系统为例
第一步：需求文档二次加工（关键步骤）
原始 PRD 通常是这样的：
"要个审批系统，能多级审批，审批人能同意拒绝，要记录审批意见..."
我的处理方式是用标准化提示词让 TRAE 帮忙转换，你可以使用如下提示词：
这是原始需求文档@审批需求。md，
请帮我将以下产品需求转换为开发可执行的技术文档，按这个格式：
1。 核心实体和关系
2。 主要功能点
3。 数据流转和状态变化
4。 接口协议设计
5。 验收标准
原始需求：[粘贴 PRD 内容]
转换结果示例：
markdown
## 审批系统技术需求 v1.0
### 1. 核心实体
- 审批单(Application)：业务方提交的待审批事项
- 审批流程(Workflow)：定义审批的步骤和规则
- 审批记录(ApprovalRecord)：每次审批操作的记录
### 2. 用户故事
- 作为申请人，我要创建审批单，以便提交业务申请
- 作为审批人，我要处理待审批事项，以便完成审批流程
- 作为申请人，我要查看审批进度，以便了解当前状态
### 3. 状态流转（简化版）
草稿 Draft → 审批中 Pending → 通过 Approved / 拒绝 Rejected
### 4. 验收标准
Given 用户有审批权限
When 用户点击"同意"按钮
Then 审批单状态变更为通过，并通知申请人第二步：固定提示词与配置
每次交互的时候可以携带固定的提示词，以保持 ai 输出内容的一致性：
markdown
xxxxxx(你提的需求)
此外，请你务必遵守以下要求：
1. 格按照现有项目的代码风格和命名规范进行开发
2. 每个函数和复杂逻辑块必须添加清晰的中文注释说明用途
3. 所有错误处理必须包含详细的错误信息和上下文
4. 生成的代码必须通过静态检查工具的验证
5. 接口设计遵循单一职责原则，每个方法只处理一个业务场景
6. 日志记录采用结构化格式，包含请求ID和关键业务参数
7. 生成代码时优先展示核心逻辑变更，避免输出冗余的样板代码
8. 专注于核心功能实现，无需编写测试代码进行验证
9. 使用直接函数调用模式，避免使用Go的面向对象语法糖.TRAE/rules/project_rules.md 配置文件是重点，它能让 AI 自动生成项目总结文档：
markdown
## 基础规约
- 使用 Go 1.21+ 语法，不要改变我的go版本
- rpc 服务使用 kitex 工具链，构建kitex代码使用./gen.sh脚本
- 数据库使用 Grom
## 自动文档生成
每次完成代码修改后，在 docs/summaries/YYYY-MM-DD/ 目录下生成总结文档，包含：
1. 本次修改的功能点
2. 涉及的文件列表
3. 主要代码逻辑说明
4. API 变更记录
文档命名：HH-MM-SS_feature_summary.md
## 代码质量要求
- 每个公开函数必须有注释
- 错误处理要完整
- 所有 SQL 查询要考虑性能第三步：RPC 接口设计
有了设计文档，你可以使用如下提示词指导 AI 帮你生成 RPC 协议：
- 请参考 business_approval_design.md 这个设计文档，帮我设计完整的审批流程 RPC 协议，其中服务接口需要定义在 approval_service.thrift 文件中，
- 协议设计要求包含完整的方法签名和参数结构体定义，所有接口返回值统一使用标准的响应格式包装，
- 枚举类型要涵盖所有可能的业务状态和错误码，结构体字段需要合理的默认值和必填标识，
- 接口设计要考虑扩展性预留足够的保留字段，复杂查询参数封装成独立的请求对象，批量操作接口要限制单次处理的数据量上限。
ini
syntax = "proto3";
package approval.v1;
service ApprovalService {
// 创建审批单
rpc CreateApplication(CreateApplicationRequest) returns (ApplicationResponse);
// 处理审批（同意/拒绝）
rpc ProcessApproval(ProcessApprovalRequest) returns (ApplicationResponse);
// 查询审批单
rpc GetApplication(GetApplicationRequest) returns (ApplicationResponse);
// 查询待处理列表
rpc ListPendingApprovals(ListPendingApprovalsRequest) returns (ListPendingApprovalsResponse);
}
// 状态枚举（保持简单）
enum ApplicationStatus {
STATUS_DRAFT = 0; // 草稿
STATUS_PENDING = 1; // 审批中
STATUS_APPROVED = 2; // 已通过
STATUS_REJECTED = 3; // 已拒绝
}
enum ApprovalAction {
ACTION_APPROVE = 0; // 同意
ACTION_REJECT = 1; // 拒绝
}
message CreateApplicationRequest {
string title = 1; // 标题
string description = 2; // 描述
string workflow_id = 3; // 使用的流程ID
string applicant_id = 4; // 申请人ID
map<string, string> form_data = 5; // 表单数据
}
message ProcessApprovalRequest {
string application_id = 1; // 审批单ID
ApprovalAction action = 2; // 操作类型
string comment = 3; // 审批意见
string approver_id = 4; // 审批人ID
}
message ApplicationResponse {
string id = 1;
string title = 2;
ApplicationStatus status = 3;
string applicant_id = 4;
string current_approver_id = 5;
repeated ApprovalRecord records = 6;
int64 created_at = 7;
int64 updated_at = 8;
}
message ApprovalRecord {
string approver_id = 1;
ApprovalAction action = 2;
string comment = 3;
int64 processed_at = 4;
}第四步：数据库设计
接下来你就是生成数据库表结构了，可以使用如下提示词：
- 请根据 approval_workflow_design.md 设计文档创建完整的数据库表结构，使用 MySQL 8.0 语法定义所有必要的数据表，表设计要包含自增主键、外键约束和合适的索引策略，
- 字段类型选择要考虑数据精度和存储效率，所有时间字段统一使用 DATETIME 类型并设置默认值，状态字段使用 TINYINT 配合注释说明取值含义，
- 软删除字段和审计字段要在每个业务表中保持一致，表间关系通过外键约束保证数据完整性，字符集统一使用 utf8mb4 支持完整的 Unicode 字符，
- 为高频查询场景创建复合索引优化性能，同时生成对应的 DROP 语句以便回滚操作。
sql
-- 审批单表
CREATE TABLE applications (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
title VARCHAR(255) NOT NULL,
description TEXT,
status INTEGER NOT NULL DEFAULT 0, -- 对应proto enum
workflow_id UUID NOT NULL,
applicant_id UUID NOT NULL,
current_approver_id UUID,
form_data JSONB,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- 审批记录表
CREATE TABLE approval_records (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
application_id UUID NOT NULL REFERENCES applications(id),
approver_id UUID NOT NULL,
action INTEGER NOT NULL, -- 0: approve, 1: reject
comment TEXT,
processed_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- 索引优化
CREATE INDEX idx_applications_status ON applications(status);
CREATE INDEX idx_applications_approver ON applications(current_approver_id) WHERE current_approver_id IS NOT NULL;
CREATE INDEX idx_approval_records_app_id ON approval_records(application_id);第五步：确定代码分层
接下来是项目目录按领域分层，你可以指定代码的位置，比如：
需要严格按照以下四层架构来组织代码实现，我有以下目录结构，每个目录的职责如下：
- handler 目录 - 你需要在这里实现 RPC 服务接口，处理外部请求的接收和响应，负责参数校验、数据转换和错误处理
- service 目录 - 你需要在这里实现核心业务逻辑，编排各种业务操作流程，协调 domain 层的领域对象完成复杂业务场景
- domain 目录 - 你需要在这里定义领域模型和业务实体，封装纯粹的业务规则，不能依赖任何外部框架或基础设施
- repository 目录 - 你需要在这里定义数据访问接口，提供数据持久化的抽象层，与具体存储实现解耦
bash
src/
├── handler/ # gRPC服务实现
│ └── approval_handler.go
├── domain/ # 领域模型
│ ├── application.go # 审批单聚合
│ └── workflow.go # 工作流
├── service/ # 业务逻辑
│ └── approval_service.go
└── repository/ # 数据访问
└── application_repo.go领域模型的核心实现：
go
// domain/application.go
type Application struct {
ID string
Title string
Status ApplicationStatus
ApplicantID string
CurrentApprover string
Records []ApprovalRecord
CreatedAt time.Time
}
// 核心业务方法
func (a *Application) Process(approverID string, action ApprovalAction, comment string) error {
if a.Status != StatusPending {
return errors.New("application is not in pending status")
}
if a.CurrentApprover != approverID {
return errors.New("invalid approver")
}
// 记录审批操作
record := ApprovalRecord{
ApproverID: approverID,
Action: action,
Comment: comment,
ProcessedAt: time.Now(),
}
a.Records = append(a.Records, record)
// 更新状态
if action == ActionApprove {
a.Status = StatusApproved
} else {
a.Status = StatusRejected
}
a.CurrentApprover = ""
return nil
}第六步：增量开发
开发分为几个阶段，每个阶段都是可运行的版本：
第一轮：Walking Skeleton（最小可用版本）
实现 CreateApplication + GetApplication，简单的状态管理（Draft -> Pending），基础数据库 CRUD，一个集成测试。
提示词： "请实现最简单的创建和查询审批单功能，只包含必要字段，先跑通流程"
第二轮：完善审批流程
ProcessApproval 实现，状态机完整逻辑，权限校验，审批记录存储。
第三轮：查询功能
ListPendingApprovals，分页和过滤，性能优化。
第七步：测试
单元测试要覆盖各种边界情况，你可以使用如下提示词：
你需要测试正常输入、空值处理、边界值（最大最小零值）、异常输入的错误处理、以及各种业务逻辑分支，确保每个测试用例都有明确的断言验证。
go
func TestApplication_Process(t *testing.T) {
// 设置测试日志
log.SetOutput(os.Stdout)
log.SetFlags(log.LstdFlags | log.Lshortfile)
tests := []struct {
name string
setup func() *Application
approverID string
action ApprovalAction
comment string
expectError bool
expectStatus ApplicationStatus
}{
{
name: "正常审批通过",
setup: func() *Application {
return &Application{
ID: "app-1",
Status: StatusPending,
CurrentApprover: "approver-1",
}
},
approverID: "approver-1",
action: ActionApprove,
comment: "同意",
expectError: false,
expectStatus: StatusApproved,
},
{
name: "非法审批人",
setup: func() *Application {
return &Application{
Status: StatusPending,
CurrentApprover: "approver-1",
}
},
approverID: "approver-2",
action: ActionApprove,
expectError: true,
},
{
name: "审批单状态错误",
setup: func() *Application {
return &Application{
ID: "app-3",
Status: StatusApproved, // 已经是审批通过状态
CurrentApprover: "approver-1",
}
},
approverID: "approver-1",
action: ActionReject,
expectError: true,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
app := tt.setup()
log.Printf("=== 测试用例: %s ===", tt.name)
log.Printf("初始状态: ID=%s, Status=%v, CurrentApprover=%s",
app.ID, app.Status, app.CurrentApprover)
err := app.Process(tt.approverID, tt.action, tt.comment)
if tt.expectError {
assert.Error(t, err)
log.Printf("预期错误: %v", err)
} else {
assert.NoError(t, err)
assert.Equal(t, tt.expectStatus, app.Status)
log.Printf("审批成功: 新状态=%v, 审批记录数=%d",
app.Status, len(app.Records))
}
log.Printf("=== 测试完成 ===\n")
})
}
}集成测试验证完整流程
比如你可以使用如下提示词：
请帮我模拟完整的生命周期测试场景，从审批单创建开始到最终审批完成的全链路验证，包括创建审批单、触发工作流、多级审批节点流转、状态变更通知、异常处理和回滚机制，
测试用例需要覆盖正常审批通过、审批拒绝、超时处理、并发审批等关键场景，
生成详细的测试报告包含每个步骤的输入输出、响应时间和系统状态变化。
less
// 单独的 RPC 接口测试
func TestCreateApplication_RPC(t *testing.T) { ctx := context.Background() req := &pb.CreateApplicationRequest{ Title: "测试审批", ApplicantId: "user-1", }
resp, err := ecom_logistics_reverse_pickup.RawCall.CreateApplication(ctx, req)
assert.NoError(t, err)
assert.NotEmpty(t, resp.Id)
assert.Equal(t, pb.ApplicationStatus_STATUS_PENDING, resp.Status)
}
func TestProcessApproval_RPC(t *testing.T) { ctx := context.Background() req := &pb.ProcessApprovalRequest{ ApplicationId: "test-app-id", Action: pb.ApprovalAction_ACTION_APPROVE, ApproverId: "approver-1", }
resp, err := ecom_logistics_reverse_pickup.RawCall.ProcessApproval(ctx, req)
assert.NoError(t, err)
assert.Equal(t, pb.ApplicationStatus_STATUS_APPROVED, resp.Status)
}
// 功能回归测试 - 完整流程
func TestApprovalWorkflow_EndToEnd(t *testing.T) { ctx := context.Background()
// 1. 创建审批单
createResp, err := ecom_logistics_reverse_pickup.RawCall.CreateApplication(ctx, &pb.CreateApplicationRequest{
Title: "回归测试",
ApplicantId: "user-1",
})
assert.NoError(t, err)
// 2. 处理审批
processResp, err := ecom_logistics_reverse_pickup.RawCall.ProcessApproval(ctx, &pb.ProcessApprovalRequest{
ApplicationId: createResp.Id,
Action: pb.ApprovalAction_ACTION_APPROVE,
ApproverId: "approver-1",
})
assert.NoError(t, err)
assert.Equal(t, pb.ApplicationStatus_STATUS_APPROVED, processResp.Status)
// 3. 查询验证
getResp, err := ecom_logistics_reverse_pickup.RawCall.GetApplication(ctx, &pb.GetApplicationRequest{
ApplicationId: createResp.Id,
})
assert.NoError(t, err)
assert.Equal(t, pb.ApplicationStatus_STATUS_APPROVED, getResp.Status)
}第八步：自动生成文档
按照 .TRAErules 的配置，TRAE 会自动在 docs/summaries/2024-01-15/14-30-22_approval_core.md 生成总结文档：
markdown
# 审批核心功能实现总结
## 本次实现功能
- ✅ 审批单创建和查询
- ✅ 审批处理逻辑
- ✅ 状态机流转
- ✅ 权限校验
## 涉及文件
- `src/domain/application.go` - 新增审批单聚合
- `src/service/approval_service.go` - 新增业务逻辑层
- `src/api/approval_service.go` - 新增gRPC服务实现
- `tests/domain/application_test.go` - 新增单元测试
## 主要逻辑
1. 审批单状态流转：Draft → Pending → Approved/Rejected
2. 权限校验：只有当前审批人能处理审批
3. 审批记录：每次操作都记录到 approval_records 表
## API 变更
- 新增 `CreateApplication` 接口
- 新增 `ProcessApproval` 接口
- 新增 `GetApplication` 接口
## 下一步计划
- [ ] 实现 ListPendingApprovals 接口
- [ ] 添加分页功能
- [ ] 优化数据库查询性能你也可以在每次做完需求之后让他总结该需求或者该模块的设计和实现。
🎨 状态流转图
当你设计好状态机，你可以直接让 ai 帮你画流程图，你可以这样说：
请根据我定义的状态机帮我生成一个详细的流程图描述，包含所有状态节点的形状和颜色、状态转换的箭头和标签、决策点的菱形节点、开始结束的圆形节点，我会用 Draw.io 来绘制，请提供清晰的布局建议和元素说明。
xml
<?xml version="1.0" encoding="UTF-8"?>
<mxfile host="app.diagrams.net" modified="2024-01-01T00:00:00.000Z" agent="5.0" etag="xxx" version="22.1.16" type="device">
<diagram name="审批系统状态流转图" id="approval-status-flow">
<mxGraphModel dx="1422" dy="794" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
<root>
<mxCell id="0" />
<mxCell id="1" parent="0" />
<!-- 标题 -->
<mxCell id="title" value="审批系统状态流转图" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=16;fontStyle=1;" vertex="1" parent="1">
<mxGeometry x="300" y="50" width="200" height="30" as="geometry" />
</mxCell>
<!-- 草稿状态 -->
<mxCell id="draft" value="草稿<br>Draft" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#e1d5e7;strokeColor=#9673a6;fontSize=12;fontStyle=1;" vertex="1" parent="1">
<mxGeometry x="100" y="200" width="120" height="60" as="geometry" />
</mxCell>
<!-- 审批中状态 -->
<mxCell id="pending" value="审批中<br>Pending" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;fontSize=12;fontStyle=1;" vertex="1" parent="1">
<mxGeometry x="340" y="200" width="120" height="60" as="geometry" />
</mxCell>
<!-- 已通过状态 -->
<mxCell id="approved" value="已通过<br>Approved" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;fontSize=12;fontStyle=1;" vertex="1" parent="1">
<mxGeometry x="580" y="120" width="120" height="60" as="geometry" />
</mxCell>
<!-- 已拒绝状态 -->
<mxCell id="rejected" value="已拒绝<br>Rejected" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f8cecc;strokeColor=#b85450;fontSize=12;fontStyle=1;" vertex="1" parent="1">
<mxGeometry x="580" y="280" width="120" height="60" as="geometry" />
</mxCell>
<!-- 状态流转箭头 -->
<!-- 草稿到审批中 -->
<mxCell id="edge1" value="提交审批" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#666666;strokeWidth=2;fontSize=12;" edge="1" parent="1" source="draft" target="pending">
<mxGeometry relative="1" as="geometry" />
</mxCell>
<!-- 审批中到已通过 -->
<mxCell id="edge2" value="同意" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#666666;strokeWidth=2;fontSize=12;" edge="1" parent="1" source="pending" target="approved">
<mxGeometry relative="1" as="geometry" />
</mxCell>
<!-- 审批中到已拒绝 -->
<mxCell id="edge3" value="拒绝" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#666666;strokeWidth=2;fontSize=12;" edge="1" parent="1" source="pending" target="rejected">
<mxGeometry relative="1" as="geometry" />
</mxCell>
<!-- 状态说明 -->
<mxCell id="status_description" value="状态说明：
• 草稿：初始创建状态
• 审批中：已提交待审批
• 已通过：审批完成通过
• 已拒绝：审批被拒绝" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#f5f5f5;strokeColor=#666666;fontSize=12;align=left;" vertex="1" parent="1">
<mxGeometry x="100" y="400" width="200" height="100" as="geometry" />
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>可直接导入飞书的 Draw.io 格式状态流转图：
导入流程如下：
💡 实践心得
做得好的地方
标准化提示词 大幅提高了代码生成质量，自动文档同步 让团队知识沉淀更及时，增量开发 保证每个版本都能跑起来容易调试，测试驱动让 AI 生成的测试用例覆盖面很好。
踩过的坑
提示词太宽泛 会导致生成的代码风格不统一，要具体到框架和规范；没有及时 review，AI 有时会过度设计，要及时纠偏；
给大家的建议
循序渐进 ，先用 AI 做简单重复的工作，逐步扩大范围；保持主导 ，架构决策、业务理解还是要人来做；建立规范 ，一个需求要统一 TRAE 的使用方式和提示词；及时总结，每个项目结束后总结最佳实践。
💎 最大的收益：释放更多时间做有价值的事
用 TRAE 开发最明显的好处不是写代码更快了，而是把我们从重复劳动中解放出来，有更多精力专注在真正重要的事情上。
以前写个 CRUD 接口，光是写样板代码、处理错误、编写测试用例就要大半天。现在这些 AI 几分钟就搞定，我可以把省下来的时间用在：
-
架构设计 - 仔细思考系统的分层结构、模块边界、依赖关系。以前总说没时间做设计，直接上手撸代码，现在有时间真正考虑架构的合理性和可扩展性。
-
流程设计 - 深入分析业务流程，考虑各种边界情况和异常场景。
-
测试质量保证 - 不再是匆忙写几个 happy path 的测试就上线，而是有时间设计完整的测试策略，包括单元测试、集成测试、性能测试。
-
代码质量把控 - 有更多时间做 code review，思考代码的可读性、可维护性。AI 生成的代码质量其实挺不错，但还需要人工审查和优化。
说白了，AI 接管了"体力活"，让我们有更多时间做"脑力活"。这样开发出来的系统不仅效率高，质量也更好。
🛠️ 大模型推荐
Kimi-K2 - 可以处理更复杂的推理任务，适合需要多步骤推理的复杂问题、分析大量数据的场景、需要创造性解决方案的挑战。
GLM-4.5 - 智谱 AI 最新模型，在代码生成和问题解决方面有显著提升，适合快速生成大量代码、解决技术难题、学习新技术栈。
AI 模型能力排行榜 LM Arena Leaderboard: lmarena.ai/leaderboard - 实时更新的 AI 模型能力排行榜，基于真实用户测试数据，包含代码能力、推理能力、创意写作等多个维度，帮你选择最适合开发场景的 AI 模型。
🚀 总结
用好 TRAE 的关键是让它成为你的编程伙伴，而不是替代品。通过标准化的工作流程和合理的人机分工，我们可以显著提升开发效率，同时保证代码质量。