百度视频播放器安卓版(百搜视频)
171.93MB · 2025-11-02
在开始具体实践之前，先明确 AI 辅助开发的完整流程：
第一步：需求分析与技术文档转换 - 将产品需求转换为 AI 可理解的技术文档，关键是结构化描述，明确输入输出，定义验收标准
第二步：接口设计与数据建模 - 定义清晰的 API 协议和数据模型，保持简单，考虑扩展性，遵循设计原则
第三步：代码生成与业务逻辑实现 - 利用 AI 生成基础代码，人工实现核心业务，人机分工明确，AI 做重复工作，人工做决策
第四步：测试验证与文档同步 - 生成测试代码，及时文档更新
人机分工很关键：
架构决策： 决定技术选型、系统设计和数据流向，把控整体方向
核心业务逻辑实现： 把最复杂、最重要的那些业务逻辑写好，处理边界情况和性能问题
代码 review： 检查代码质量，发现潜在问题，保证团队代码标准一致
重复劳动： 处理那些重复性、机械性的编码工作，比如 CRUD、配置文件等
文档同步： 代码变更后自动更新相关文档，保持文档和代码同步
测试用例： 生成和维护各种测试用例，覆盖主要功能和边界场景
这里我以开发一个简单的审批系统为例
原始 PRD 通常是这样的：
我的处理方式是用标准化提示词让 TRAE 帮忙转换，你可以使用如下提示词：
转换结果示例：
## 审批系统技术需求 v1.0
### 1. 核心实体
- 审批单(Application)：业务方提交的待审批事项
- 审批流程(Workflow)：定义审批的步骤和规则
- 审批记录(ApprovalRecord)：每次审批操作的记录
### 2. 用户故事
- 作为申请人，我要创建审批单，以便提交业务申请
- 作为审批人，我要处理待审批事项，以便完成审批流程
- 作为申请人，我要查看审批进度，以便了解当前状态
### 3. 状态流转（简化版）
草稿 Draft → 审批中 Pending → 通过 Approved / 拒绝 Rejected
### 4. 验收标准
Given 用户有审批权限
When 用户点击"同意"按钮
Then 审批单状态变更为通过，并通知申请人
每次交互的时候可以携带固定的提示词，以保持 ai 输出内容的一致性：
xxxxxx(你提的需求)
此外，请你务必遵守以下要求：
1. 格按照现有项目的代码风格和命名规范进行开发
2. 每个函数和复杂逻辑块必须添加清晰的中文注释说明用途
3. 所有错误处理必须包含详细的错误信息和上下文
4. 生成的代码必须通过静态检查工具的验证
5. 接口设计遵循单一职责原则，每个方法只处理一个业务场景
6. 日志记录采用结构化格式，包含请求ID和关键业务参数
7. 生成代码时优先展示核心逻辑变更，避免输出冗余的样板代码
8. 专注于核心功能实现，无需编写测试代码进行验证
9. 使用直接函数调用模式，避免使用Go的面向对象语法糖
.TRAE/rules/project_rules.md 配置文件是重点，它能让 AI 自动生成项目总结文档：
## 基础规约
- 使用 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 查询要考虑性能
有了设计文档，你可以使用如下提示词指导 AI 帮你生成 RPC 协议：
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;
}
接下来你就是生成数据库表结构了，可以使用如下提示词：
-- 审批单表
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);
接下来是项目目录按领域分层，你可以指定代码的位置，比如：
需要严格按照以下四层架构来组织代码实现，我有以下目录结构，每个目录的职责如下：
src/
├── handler/ # gRPC服务实现
│ └── approval_handler.go
├── domain/ # 领域模型
│ ├── application.go # 审批单聚合
│ └── workflow.go # 工作流
├── service/ # 业务逻辑
│ └── approval_service.go
└── repository/ # 数据访问
└── application_repo.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，分页和过滤，性能优化。
单元测试要覆盖各种边界情况，你可以使用如下提示词：
你需要测试正常输入、空值处理、边界值（最大最小零值）、异常输入的错误处理、以及各种业务逻辑分支，确保每个测试用例都有明确的断言验证。
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")
})
}
}
集成测试验证完整流程
比如你可以使用如下提示词：
// 单独的 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 生成总结文档：
# 审批核心功能实现总结
## 本次实现功能
- 审批单创建和查询
- 审批处理逻辑
- 状态机流转
- 权限校验
## 涉及文件
- `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 帮你画流程图，你可以这样说：
<?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 的关键是让它成为你的编程伙伴，而不是替代品。通过标准化的工作流程和合理的人机分工，我们可以显著提升开发效率，同时保证代码质量。
2025-11-02
“人工智能教父”辛顿：科技巨头需要裁员才能从 AI 中获利
2025-11-02
小音量低噪问题优化，华为 FreeClip 2 耳夹耳机获 HarmonyOS 5.1.0.158 升级
