用自然语言给孩子捏一个家庭成长积分系统
本文介绍了作者为女儿生日开发的家庭成长积分系统"芝麻"的完整开发过程。系统采用React Native+TypeScript前端和SpringBoot后端，实现了家长发布任务、孩子完成任务获取积分、积分兑换礼物的核心功能。作者全程使用AI辅助开发，包括：1)通过Claude生成需求文档；2)使用Stitch设计交互原型；3)借助OMO(Oh-My-OpenAgent)自动生成代
近期女儿生日，给小孩上线了一套家庭成长积分系统，本篇文章核心记录整体操作过程以及一些研发模式改变的感悟 (4月份要发布的文章，耽误了好多天）
一、效果展示
访问地址 https://www.myzhima.cloud/
- 注册邀请码 1
- 测试账号 testbaba testmama xiaoming xiaolan
- 密码都是 123456
实验演示
二、实现
需求澄清
采用Claude的AskUserQuestion工具来细化，https://code.claude.com/docs/zh-CN/best-practices
对应提示词内容
I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.
Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.翻译为中文
我想创建[简要描述]的内容。请使用 AskUserQuestion 工具详细地与我进行交流。
询问有关技术实现、用户界面/用户体验、特殊情况、担忧以及权衡取舍等方面的问题。不要问那些显而易见的问题，要深入探讨那些我可能未曾考虑到的复杂部分。
继续进行交流，直到所有内容都涵盖完毕，然后将完整的方案编写到 SPEC.md 文件中。通过这个提示词的模板写出自己的内容 , 打开Claude Code 进行交互
我想创建 家庭儿童虚拟积分管理系统，系统名称芝麻，包含孩子端和家长端，家长下发任务，孩子完成任务领取积分，积分可以兑换礼物。请使用 AskUserQuestion 工具详细地与我进行交流。
询问有关技术实现、用户界面/用户体验、特殊情况、担忧以及权衡取舍等方面的问题。不要问那些显而易见的问题，要深入探讨那些我可能未曾考虑到的复杂部分。
继续进行交流，直到所有内容都涵盖完毕，然后将完整的方案编写到 SPEC.md 文件中。
Claude Code会自动给用户提问，依据提问做选择题，如果没有对应选项也可以手动输入个人要求
需求澄清
经过一段时间的等待得到需求文档，针对内容手动做了一些小的改动（前端采用 Expo + React Native + TypeScript，不要采用亚马逊的存储，奖励设计不需要灵活的库存之类的，Docker的依赖在后面的发布时也移除了）
# 芝麻 - 家庭儿童虚拟积分管理系统
## 1. 项目概述
**项目名称：** 芝麻
**项目类型：** 跨平台App（Expo + React Native + TypeScript）
**核心功能：** 家长下发任务，孩子完成任务领取积分，积分兑换礼物
**目标用户：** 有3-16岁儿童的家庭
---
## 2. 核心机制
### 2.1 积分系统
| 特性 | 规则 |
|------|------|
| 积分有效期 | **永久积累**，不清零 |
| 积分余额 | 最低为 0，**不允许负积分/欠债** |
| 积分获取 | 完成任务后由家长审批发放 |
| 积分扣除 | 仅当兑换礼物时扣除，不涉及惩罚扣分 |
### 2.2 任务系统
| 任务类型 | 说明 |
|----------|------|
| 一次性任务 | 如"帮忙搬家箱"、"教爷爷用手机"，完成后即结束 |
| 循环任务 | 每日/每周循环（如"整理床铺"、"洗碗"），可设置重复周期 |
**任务审核流程：**
- 孩子完成任务后提交完成申请
- **家长人工审批**后积分自动发放
- 审批拒绝时**必须填写拒绝原因**
- **无需上传照片/视频凭证**
### 2.3 奖励兑换系统
| 特性 | 规则 |
|------|------|
| 奖励来源 | **家长创建奖励列表** |
| 定价方式 | **家长自主定价** |
| 兑换流程 | 孩子查看奖励列表 → 直接用积分兑换 → 积分自动扣除 → 兑换成功 |
**奖励列表：**
- 家长创建并维护奖励列表，设置名称、价格、库存
- 孩子可浏览奖励列表，用积分直接兑换
- **兑换无需审批**，积分充足即可兑换成功
- 家长可设置每种奖励的库存数量
### 2.4 多孩子支持
| 特性 | 规则 |
|------|------|
| 积分账户 | **完全独立**，各孩子独立积分余额 |
| 任务分配 | 可指定单一孩子或多个孩子共同完成 |
| 公平性 | 任务难度和奖励由家长根据实际情况灵活设置 |
| 礼品池 | 共享礼品池，各孩子独立兑换 |
---
## 3. 用户体系
### 3.1 账号系统
- **需要账号系统**：每个家庭成员（家长/孩子）拥有独立账号
- 支持多设备登录同一账号
- 家庭通过**家庭码**或**家庭ID**加入
### 3.2 角色划分
| 角色 | 权限 |
|------|------|
| 家长 | 创建/编辑/删除任务、审批完成申请、审批礼物申请/定价、管理孩子账号 |
| 孩子 | 查看任务、申请完成任务、申请礼物、查看积分余额/历史 |
---
## 4. 技术方案
### 4.1 平台选择
- **跨平台方案**：Expo + React Native + TypeScript
- 一套代码同时支持 iOS 和 Android
### 4.2 数据存储
- **云端存储**：所有数据存储在云端
- 需要用户注册和登录
- 支持多设备同步
### 4.3 网络要求
- **必须在线**：应用完全依赖网络，没网时无法使用
- 无离线功能支持
### 4.4 通知推送
- **不需要推送通知**
- 用户主动打开应用查看任务和积分变动
---
## 5. 家长端功能
### 5.1 任务管理
- 创建新任务（设置名称、描述、积分奖励、类型：一次性/循环）
- 设置循环任务周期（每日/每周具体日期）
- 编辑/删除/暂停任务
- 指派任务给指定孩子或多个孩子
### 5.2 审批管理
- 查看孩子提交的任务完成申请
- **审批通过：积分自动发放至孩子账户**
- **审批拒绝：必须填写拒绝原因**
### 5.3 奖励管理
- 创建/编辑/删除奖励（名称、价格、库存）
- 查看奖励列表
- 查看兑换记录
### 5.4 孩子管理
- 添加/移除孩子账号
- 查看各孩子积分余额和兑换历史
---
## 6. 孩子端功能
### 6.1 任务中心
- 查看已分配给我的任务
- 筛选：全部/待完成/进行中/已完成
- 查看任务详情（名称、描述、奖励积分）
### 6.2 完成任务
- 点击"完成"按钮提交完成申请
- 查看申请状态：待审核/已通过（积分已到账）/已拒绝（含拒绝原因）
### 6.3 积分中心
- 查看当前积分余额
- 查看积分变动历史（获取/消费明细）
### 6.4 奖励兑换
- 浏览可兑换奖励列表（显示所需积分和库存）
- **直接用积分兑换奖励（无需审批）**
- 积分充足则兑换成功，扣除积分
- 查看兑换记录
---
## 7. 数据模型
### 7.1 用户 (UserVO)
```json
{
"id": "long",
"username": "string",
"nickname": "string",
"avatarUrl": "string",
"phone": "string",
"email": "string",
"userType": "int (1=家长, 2=孩子)",
"status": "int",
"familyId": "long",
"currentFamilyId": "long",
"createdAt": "datetime"
}
```
### 7.2 家庭
```
Family {
id: long
name: string
inviteCode: string (邀请码，用于加入家庭)
}
```
### 7.3 任务模板 (TaskTemplate)
```json
{
"id": "long",
"name": "string",
"categoryId": "long",
"description": "string",
"defaultPoints": "int",
"imageUrl": "string",
"isSystem": "boolean (系统预设模板)"
}
```
### 7.4 任务 (TaskVO)
```json
{
"id": "long",
"familyId": "long",
"childId": "long (指派的孩子ID)",
"templateId": "long",
"name": "string",
"description": "string",
"points": "int",
"categoryId": "long",
"categoryName": "string",
"imageUrl": "string",
"taskType": "int (任务类型)",
"frequency": "int (频率)",
"deadline": "date",
"status": "int",
"createdAt": "datetime",
"updatedAt": "datetime"
}
```
### 7.5 任务实例 (TaskInstanceVO)
```json
{
"id": "long",
"taskId": "long",
"familyId": "long",
"taskName": "string",
"taskDescription": "string",
"points": "int",
"childId": "long",
"childName": "string",
"scheduledDate": "date",
"status": "int (1=待提交, 2=待审批, 3=已通过, 4=已拒绝, 5=已放弃)",
"statusName": "string",
"submitTime": "datetime",
"submitNote": "string",
"submitImageUrl": "string",
"approvalTime": "datetime",
"approvalNote": "string",
"approvedBy": "long",
"approverName": "string",
"createdAt": "datetime",
"updatedAt": "datetime"
}
```
### 7.6 奖励 (RewardVO)
```json
{
"id": "long",
"familyId": "long",
"name": "string",
"description": "string",
"pointsRequired": "int",
"imageUrl": "string",
"stock": "int (-1=无限库存)",
"status": "int",
"createdAt": "datetime",
"updatedAt": "datetime"
}
```
### 7.7 积分余额 (PointBalanceVO)
```json
{
"id": "long",
"familyId": "long",
"childId": "long",
"availablePoints": "int (可用积分)",
"pendingPoints": "int (待确认积分)",
"updatedAt": "datetime"
}
```
### 7.8 积分变动 (PointTransactionVO)
```json
{
"id": "long",
"familyId": "long",
"childId": "long",
"taskInstanceId": "long",
"taskName": "string",
"typeName": "string",
"type": "int",
"points": "int",
"balanceBefore": "int",
"balanceAfter": "int",
"note": "string",
"rejectReason": "string",
"operatorId": "long",
"statusName": "string",
"status": "int",
"createdAt": "datetime"
}
```
### 7.9 奖励兑换 (RedemptionVO)
```json
{
"id": "long",
"familyId": "long",
"childId": "long",
"rewardId": "long",
"rewardName": "string",
"pointsSpent": "int",
"status": "int (1=待确认, 2=已完成, 3=已取消)",
"statusName": "string",
"redeemedAt": "datetime",
"note": "string",
"createdAt": "datetime"
}
```
---
## 8. 界面设计方向
### 8.1 视觉风格
- 温馨、友好、儿童友好的设计风格
- 使用圆角、柔和颜色，避免尖锐元素
### 8.2 配色建议
- 采用微渐变、大圆角、糖果色系（Candy Color），符合儿童审美
### 8.3 导航结构
- **家长端**：Tab导航（首页/任务管理/奖励商店/家庭）
- **孩子端**：Tab导航（首页/奖励商店/家庭）
---
## 9. 技术栈
| 层级 | 技术选择 |
|------|----------|
| 前端框架 | Expo + React Native + TypeScript |
| 后端 | **Spring Boot (Java)** |
| 数据库 | **MySQL** |
| 部署 | **Docker** |
| 用户认证 | JWT |
---
## 10. API 设计
### 10.1 认证相关
| 方法 | 接口 | 说明 |
|------|------|------|
| POST | /api/auth/register | 用户注册 |
| POST | /api/auth/login | 用户登录 |
| GET | /api/auth/info | 获取当前用户信息 |
| GET | /api/auth/families | 获取用户所在家庭列表 |
| POST | /api/auth/switch-family | 切换当前家庭 |
### 10.2 家庭相关
| 方法 | 接口 | 说明 |
|------|------|------|
| POST | /api/family/create | 创建家庭 |
| POST | /api/family/join | 加入家庭（通过邀请码） |
| GET | /api/family/{familyId} | 获取家庭信息 |
| GET | /api/family/{familyId}/members | 获取家庭成员列表 |
| POST | /api/family/{familyId}/add-child | 添加孩子账号 |
### 10.3 任务模板
| 方法 | 接口 | 说明 |
|------|------|------|
| GET | /api/task/template/list | 获取所有任务模板 |
| GET | /api/task/template/{id} | 获取模板详情 |
| GET | /api/task/template/category/{categoryId} | 按分类获取模板 |
### 10.4 任务管理
| 方法 | 接口 | 说明 |
|------|------|------|
| POST | /api/task | 创建任务 |
| GET | /api/task/{id} | 获取任务详情 |
| PUT | /api/task/{id} | 修改任务 |
| DELETE | /api/task/{id} | 删除任务 |
| GET | /api/task/page | 分页获取任务（需 familyId） |
| GET | /api/task/family/{familyId} | 获取家庭所有任务 |
| GET | /api/task/child/{childId} | 获取孩子的任务 |
### 10.5 任务实例（完成审批）
| 方法 | 接口 | 说明 |
|------|------|------|
| POST | /api/task/instance/submit | 孩子提交完成任务 |
| POST | /api/task/instance/approve | 家长审批（通过/拒绝） |
| POST | /api/task/instance/abandon/{id} | 孩子放弃任务 |
| GET | /api/task/instance/{id} | 获取任务实例详情 |
| GET | /api/task/instance/today | 获取孩子今日任务 |
| GET | /api/task/instance/current | 获取孩子当前待完成任务 |
| GET | /api/task/instance/page | 分页获取孩子任务实例 |
| GET | /api/task/instance/pending-approval | 家长获取待审批列表 |
### 10.6 奖励管理
| 方法 | 接口 | 说明 |
|------|------|------|
| POST | /api/reward/create | 创建奖励 |
| PUT | /api/reward/update/{rewardId} | 修改奖励 |
| DELETE | /api/reward/delete/{rewardId} | 删除奖励 |
| GET | /api/reward/{rewardId} | 获取奖励详情 |
| GET | /api/reward/list | 获取奖励列表 |
| GET | /api/reward/active | 获取可兑换奖励列表 |
| POST | /api/reward/redeem | 孩子兑换奖励 |
| GET | /api/reward/redemptions | 获取兑换记录 |
| GET | /api/reward/pending-redemptions | 获取待处理兑换（家长） |
| POST | /api/reward/complete/{redemptionId} | 确认兑换完成（家长） |
| POST | /api/reward/cancel/{redemptionId} | 取消兑换（家长） |
### 10.7 积分管理
| 方法 | 接口 | 说明 |
|------|------|------|
| GET | /api/point/balance | 查询积分余额 |
| GET | /api/point/transactions | 查询积分变动历史 |
| GET | /api/point/pending | 获取待确认积分变动 |
| POST | /api/point/add | 增加积分 |
| POST | /api/point/deduct | 扣除积分 |
| POST | /api/point/approve/{transactionId} | 审批通过积分 |
| POST | /api/point/reject/{transactionId} | 审批拒绝积分 |
---
### 10.8 请求/响应模型
#### 注册请求 (RegisterRequest)
```json
{
"username": "string (3-50字符)",
"password": "string (≥6字符)",
"nickname": "string",
"phone": "string",
"email": "string",
"userType": "int (1=家长, 2=孩子)"
}
```
#### 创建任务 (CreateTaskRequest)
```json
{
"familyId": "long",
"childId": "long",
"templateId": "long",
"name": "string",
"description": "string",
"points": "int",
"categoryId": "long",
"taskType": "int",
"frequency": "int",
"deadline": "date"
}
```
#### 提交任务 (SubmitTaskRequest)
```json
{
"taskInstanceId": "long",
"submitNote": "string",
"submitImageUrl": "string"
}
```
#### 审批任务 (ApproveTaskRequest)
```json
{
"taskInstanceId": "long",
"approved": "int (1=通过, 0=拒绝)",
"approvalNote": "string (拒绝时必填，最多500字符)"
}
```
#### 创建奖励 (CreateRewardRequest)
```json
{
"name": "string",
"description": "string",
"pointsRequired": "int",
"imageUrl": "string",
"stock": "int (-1=无限库存)"
}
```
#### 兑换奖励 (RedeemRequest)
```json
{
"childId": "long",
"rewardId": "long",
"note": "string"
}
```
#### 积分变动 (PointChangeRequest)
```json
{
"childId": "long",
"type": "int",
"points": "int",
"note": "string",
"taskInstanceId": "long"
}
```
---
## 11. 开发优先级
### 第一阶段（MVP）
- 账号系统（注册/登录/家庭管理）
- 家长创建任务（一次性 + 每日循环）
- 孩子查看任务并提交完成
- 家长审批任务完成（**拒绝必须填原因**）
- **积分自动发放，无需二次审批**
- 家长创建奖励列表
- **孩子直接兑换奖励（积分足够即可）**
- 孩子查看积分余额
### 第二阶段
- 每周循环任务
- 积分历史明细
- 奖励库存管理
### 第三阶段（未来扩展）
- 任务统计与数据分析
- 成就系统/徽章
交互设计
有了需求文档，就可以进行视觉与交互的设计，采用Stitchhttps://stitch.withgoogle.com/ ，直接在对话框中输入需求文档。
这个模块很贴心的把色调、配色等标准给罗列出来，保证整体页面不会有大的差异 ；
需求生成
在页面右上角导出，可以选择mcp的形式，但考虑到网络的问题，选择直接下载到本地.zip，解压后可直接使用。
代码实现
代码实现过程依赖Open Code + OMO（Oh-My-OpenAgent），在动工之前，我手动通过 https://start.spring.io/ 我初始了一个简单的服务端代码工程（这一步其实是没有必要的，完全可以交给OMO，个人习惯而已），将前面的需求文档以及产品原型到拷贝到工程目录下，并新建一个frontend目录保存前端工程
在Open Code中输入命令
ulw 严格遵循如下要求编码
# Context
1. **项目状态**：当前目录是一个我已经手动初始化好的 Java 服务端工程。
2. **需求来源**：本次开发的所有具体业务需求，请严格阅读并参考根目录下的 `需求文档.md`。
3. **前端路径**：所有前端相关的代码**必须**保存在根目录的 `frontend` 目录中。
4. **运行环境**：本机已安装 Docker，所有依赖服务（如数据库）应优先考虑容器化运行。
# Tech Stack & Architecture
* **服务端架构**：严格采用 DDD（Domain-Driven Design，领域驱动设计）架构。请合理划分领域层（Domain）、应用层（Application）、基础设施层（Infrastructure）和用户接口层（User Interface/Adapter）。
* **数据库**：使用 MySQL。
* **前端要求**：页面样式必须**严格参考**我提供的产品原型（或需求文档中描述的 UI 要求），还原度要高。
# Constraints
* **代码可运行性**：你编写或生成的系统必须能够完整实现需求文档中的功能，确保端到端连通。
* **目录规范**：严禁将前端代码混在 Java 的 `src/main/resources` 静态目录中，必须独立在 `frontend` 文件夹。
* **Docker 友好**：如果需要初始化数据库或中间件，请在项目根目录提供 `docker-compose.yml` 脚本。
# Workflow
1. 首先，请阅读并分析 `需求文档.md`，向我简要确认你对核心业务逻辑和 DDD 限界上下文的理解。
2. 给出你计划设计的 DDD 目录结构以及前端的技术选型建议（如果你有推荐，可以告诉我，或者在文档里找线索）。
3. 在我确认后，按模块分步进行代码编写，每完成一个阶段提示我进行测试或确认。开始编码
模型一开始按照以下四步来思考，然后给出一个方案来找我确认，经过几轮和它的沟通，它就开始工作了。
* 检查仓库和需求文档，了解业务范围和当前项目状态
* 分析核心业务逻辑并确定候选DDD有界上下文
* 提出DDD目录结构和前端栈建议
* 总结发现并等待用户确认后再执行
优化
-
经过等待后，不需要自行先测试，先给模型一条指令
-
ulw 命令的作用，就是切换到 Ultrawork Mode，让助手进入更高强度、更谨慎的工作方式，比如先充分探索再动手、严格控制范围、强调验证和手动 QA、输出更精炼。默认不需要输入
-
进入 http://localhost:8080/v3/api-docs 查看服务端API文档
-
ulw 先自测，保证链路可用，并构建重启服务的脚本-
提供精准的错误信息，涉及到页面接口抛错打开F12 把具体url、状态、返回等各种信息给助手，服务端错误也类似，这样可快速定位
-
让模型助手理解你的工程，当工程基本运行的没有问题时，执行 /init-deep 命令，会做项目发现与分析，再按复杂度给子目录打分，然后在根目录和必要的子目录里生成或更新 AGENTS.md，下次助手即可通过该文件快速了解代码工程，而不需要重头再来
-
随时随地编程，由于助手编码工作一般耗时都偏长，没必要一直坐在电脑面前等待它的返回，可以借助龙虾达到手机随时随地发送编程指令
创建一个龙虾专属编码Agent，修改对应的md文件
-
把Agent的工作目录严格锁定在代码工程中
-
能判断何时在opencode run后面增加--continue参数
openclaw agents add omo_coder \
--workspace /Users/celen/.openclaw/omo_coder/workspace \
--model minimax/MiniMax-M2.5
AGENTS.md
# Agent 角色：编程任务总调度 (Orchestrator)
## 核心目标
- 接收用户的编程、重构或 Debug 需求。
- **严禁直接拼写长篇代码**，必须通过调用 `opencode run` 或 OmO 插件来执行实际的编码、调试和单元测试任务。
- 获取 `opencode` 的执行结果后，向用户汇报最终成果或报错。
## 运行约束与安全
- **路径锁定**：执行任何终端命令前，必须确保前置命令为 `cd /Users/celen/Documents/code/sesame`。
- 如果发现本地路径不匹配，立即停止执行并向用户报错。
- 每次会话开始，必须先隐式读取 `USER.md` 和 `MEMORY.md` 掌握上下文。
## 标准作业程序 (SOP)
当你收到用户的编程指令时，必须按以下步骤执行：
### 第一步：判定会话状态（核心）
审视当前用户的请求与上一轮对话的关系：
1. **追问/连续模式**：如果用户提到“刚才、上一步、报错了、接着写、换个方式”或者请求明显是上一个任务的延续，**必须**在 `opencode run` 后追加 `--continue` 参数。
2. **新任务模式**：如果用户提出了一个全新的、与前文不相干的需求，使用常规的 `opencode run`。
### 第二步：任务拆解与派发
- 将用户的需求转化为清晰、具体的 Prompt。
- 组合最终的 Shell 命令进行调用（参见 `TOOLS.md`）。
### 第三步：结果校验
- 检查 `opencode` 返回的终端输出。
- 如果成功，简明扼要地向用户总结修改了哪些文件。
- 如果连续 3 次报错且没有解决迹象，停止自动重试，将报错抛给用户。SOUL.md
# Soul: 资深技术 Leader
## 性格与语气
- **专业且极其克制**：说话直击要害，绝不废话，使用标准的开发者术语。
- **掌控全局**：像一个真正带团队的 Leader，分配任务清晰，时刻关注上下文窗口的健康。
- 习惯在微信等 IM 软件中用精简的语言汇报，拒绝长篇大论的“AI 味”客套话。
## 核心原则
- **工具优先**：深刻理解“AI 编程应该交给最专业的工具”，坚决不手动拼写冗长且容易出错的代码，永远优先使用 OpenCode。
- **闭环思维**：通过 `opencode` 跑完测试并确认无误后，才算任务完成。
- **不自作主张**：遇到模棱两可的需求或破坏性操作（如强制覆盖未提交的 Git 代码），必须停下来向用户确认。TOOLS.md
# Tools 定义
## 1. 锁死目录的项目终端 (Project Terminal)
- **描述**: 在指定的项目固定目录下唤起 OpenCode 和 OmO 插件执行编程任务。
- **工作目录**: `/Users/celen/Documents/code/sesame`
### 核心调用逻辑 (必读)
Agent 在调用此工具前，必须根据当前对话上下文（参考 `AGENTS.md` 的 SOP），**二选一**组合最终的 Shell 命令：
1. **新任务模式 (Fresh Start)**
- **触发条件**: 用户提出了一个全新的需求，或者明确表示要“新开一个任务/换个文件做”。
- **命令格式**: `cd /Users/celen/Documents/code/sesame && opencode run "你的任务描述"`
2. **追问/连续模式 (Continue Session)**
- **触发条件**: 用户的请求是基于上一次对话的修改、纠错、继续往下写，或者提到了“刚才、上一步、报错了、接着写”等词汇。
- **命令格式**: `cd /Users/celen/Documents/code/sesame && opencode run --continue "你的追问描述"`
---
### 调用示例
#### 场景 A：开启新任务
- **用户**: "帮我写一个 python 的健康检查接口"
- **Agent 思考**: 这是一个全新的需求，需要新开会话。
- **实际执行命令**:
`cd /Users/celen/Documents/code/sesame && opencode run "写一个 python 的健康检查接口"`
#### 场景 B：基于上一次结果继续调整 (触发 `--continue`)
- **用户**: "刚才的接口漏掉了一个返回时间戳，帮我加上"
- **Agent 思考**: 用户提到了“刚才的接口”，属于连续对话，必须带上 `--continue`。
- **实际执行命令**:
`cd /Users/celen/Documents/code/sesame && opencode run --continue "给刚才的健康检查接口加上返回时间戳"`给龙虾绑定微信channel
npx -y @tencent-weixin/openclaw-weixin-cli@latest install 
扫码后通过 openclaw channels list 查询channel信息
将新的agent和channel进行绑定，通过openclaw agents bindings 查看结果，后续微信发过来的消息就会路由到该Agent处理
openclaw agents bind --agent omo_coder --bind openclaw-weixin:0d271f463cff-im-bot
通过微信编程
微信找到账号 微信 ClawBot账号，点击聊天
通过openclaw的控制台切换到聊天看到确实启动了Opencode来执行指令（针对一些简单逻辑处理Agent会自行调用现有模型做处理，但只要能解决问题就ok.）
三、唯一不变的是变化
整个实现没有动手写过一行代码，时间控制在一天左右；在编码助手的助力下一个小的想法可以快速落地，AI工程化从Prompt Engineering（PE）到Context Engineering（CE）到Harness Engineering（HE）进行快速的迭代变化
看变化
|
Prompt Engineering |
Context Engineering |
Harness Engineering |
|
|
概述 |
Prompt Engineering通过优化人与大模型的交互语言，心设计的语言输入，可以最大化激发其潜在能力 |
Context Engineering认识到，模型的表现不仅取决于"怎么说"，更取决于"知道什么"。其核心是将关注点从单次输入扩展到整个信息环境的设计 |
Harness Engineering的突破在于认识到，AI系统的可靠性不仅取决于输入信息，更取决于运行环境。其核心是构建一个约束系统，确保Agent在真实环境中的行为可预测、可验证、可恢复 |
|
特点 |
|
|
|
|
局限性 |
|
|
|
|
使用 |
在单次或少量轮次的交互中，通过语言设计解决特定任务。典型场景包括代码生成、文本摘要、问答系统等 |
构建动态的信息供给系统，在正确的时间以正确的格式提供正确的信息。典型场景包括知识密集型问答、多步骤任务执行、工具调用等 |
设计Agent的运行环境，包括约束规则、验证机制、状态管理和错误恢复策略。典型场景包括长期运行的自主Agent、生产环境中的AI系统、多Agent协作等 |
这三种Engineering范式是一种包含关系（Harness Engineering ⊇ Context Engineering ⊇ Prompt Engineering），在历史的局限性上进行突破升级，Harness Engineering将复杂度从代码层面转移到了系统设计层面，但并没有消除复杂度。
本次工程的代码完全由OMO(Oh-My-OpenAgent)产出，它构建了一个10+个专业Agent组成的虚拟开发团队，每个Agent专注于自己擅长的领域，是Harness Engineering很好的一种实践
-
约束 - 限制行为边界与能力范围
|
约束类型 |
主要负责 Agent |
支持 Agent |
机制 |
|
架构约束 |
Oracle (架构顾问) |
Sisyphus (主编排器) |
读取 docs/ARCHITECTURE.md，验证层级依赖关系。通过静态分析工具或脚本（如 lint-deps）检查代码是否遵循“高层可导入低层，反之不可”等规则。 |
|
编辑约束 |
Sisyphus-Junior (主力执行器) |
Atlas (任务分发器) |
Hashline 机制：读取文件时为每行代码生成内容哈希，编辑时通过引用哈希标签定位。如果文件在读取后发生变化（哈希不匹配），则拒绝编辑，防止并发编辑冲突和数据损坏。 |
|
行为约束 |
Momus (战略审查师) |
Prometheus (战略规划师) |
在任务执行前，对由 Prometheus 生成的执行计划进行审查。检查计划是否包含违规操作（如删除关键目录、修改受保护文件），并拦截不符合项目规范的行为。 |
|
依赖约束 |
Librarian (文档搜索专家) |
Explore (代码库侦察兵) |
维护并检查依赖白名单（通常在 AGENTS.md或配置文件中定义）。在引入新包或库时，验证其是否在许可名单内，防止引入未授权、不安全或不兼容的依赖。 |
-
告知 - 信息供给与上下文管理
|
类型 |
主要负责 Agent |
支持 Agent |
机制 |
|
文档导航与索引 |
Librarian (文档搜索专家) |
Sisyphus (主编排器) |
维护并解释 AGENTS.md（约100行的核心导航地图），根据任务需求，从 docs/目录动态加载详细设计文档、API合约等，避免上下文窗口被无关信息挤占。 |
|
代码库探索与证据收集 |
Explore (代码库侦察兵) |
Sisyphus (主编排器) |
快速扫描代码仓库，定位相关模式、函数、文件和引用关系，为当前任务提供“代码证据”，帮助理解现有实现和依赖。 |
|
隐含需求与上下文挖掘 |
Metis (预分析规划顾问) |
Prometheus (战略规划师) |
在规划阶段，通过分析模糊需求，主动挖掘用户未言明的意图、业务规则和边界条件，并将其转化为明确的、可被后续Agent使用的上下文。 |
|
战略规划与知识固化 |
Prometheus (战略规划师) |
Atlas (任务执行器) |
采用“访谈模式”与用户交互，将对话中确认的需求、约束和验收标准结构化地固化为执行计划文件（.sisyphus/plans/*.md），成为后续所有执行步骤的唯一真相来源。 |
|
架构知识供给 |
Oracle (只读架构顾问) |
所有执行Agent |
作为项目架构的“活字典”，随时为其他Agent提供关于层级规则、设计决策、反模式等的准确解释，确保行动不偏离架构蓝图。 |
-
执行 - 任务编排与协同工作流
|
执行阶段/类型 |
主要负责 Agent |
支持 Agent |
机制 |
|
意图分析与任务路由 |
Sisyphus (主编排器) |
(内置 Intent Gate) |
通过 Intent Gate 分析用户请求的真实意图，区分是提问、修复、实现还是调研，并据此决定是将任务委托给 Hephaestus、Prometheus 还是自行编排。 |
|
深度自治执行 |
Hephaestus (自主深度工作者) |
Sisyphus (任务发起者) |
接收高层次目标（如“优化认证模块”），而非具体步骤。自主探索代码库、研究模式、进行多步推理与工具调用，端到端地完成复杂任务，无需微管理。 |
|
多Agent协同编排 |
Sisyphus (主编排器) |
Librarian, Explore, Oracle, 各执行Agent |
将复杂任务分解，并并行协调多个专业Agent工作（如同时让 Explore 搜代码、Librarian 查文档、Oracle 给建议），最后汇总结果，像项目经理一样驱动任务完成。 |
|
基于计划的波次执行 |
Atlas (任务执行器) |
Prometheus (计划制定者) |
执行由 Prometheus 生成的详细计划。将计划分解为多个“波次”（wave），按顺序执行、验证、记录学习点，并支持任务中断后的“断点续传”。 |
|
专业化领域执行 |
Sisyphus-Junior, Frontend/Backend Engineer (领域专家) |
Sisyphus (任务分发者) |
接收来自 Sisyphus 的明确、具体的子任务（如“实现XX函数”），专注于代码编写和基础验证，是团队中的“主力开发工程师”。 |
|
多模型调度路由 |
Sisyphus (主编排器) |
(系统 Category 抽象层) |
不硬编码模型，而是通过 Category抽象层（如 |
-
验证 - 多层自动化质检
|
验证层级 |
主要负责 Agent/组件 |
支持 Agent |
机制 |
|
语法/格式验证 (Lint) |
各执行Agent (如 Sisyphus-Junior) |
统一验证脚本 ( |
代码修改后即时运行 LSP diagnostics 和代码规范检查（如 |
|
架构/依赖验证 |
自动化脚本 ( |
Oracle, Sisyphus, Momus |
在关键卡点（Checkpoint）执行，强制检查层级依赖、导入白名单、文件位置等架构规则。违反规则会阻断流程。 |
|
功能正确性验证 (测试) |
各执行Agent, Hephaestus |
统一验证脚本 |
运行单元测试、集成测试。系统支持只运行受影响部分的测试，以提升速度。测试结果是任务完成的硬性指标之一。 |
|
端到端/集成验证 |
统一验证脚本 ( |
Sisyphus (协调者) |
执行项目特有的端到端功能验证脚本，模拟用户真实操作流程，确保功能整体可用，而不仅是单元正确。 |
|
事前预验证 |
预验证脚本 ( |
所有计划执行Agent |
在执行创建文件、添加导入等结构性操作前，先询问系统“这样做是否合法”，从源头拦截架构违规，成本极低。 |
|
计划与战略审查 |
Momus (战略审查师) |
Prometheus, Metis |
在编码开始前，对 Prometheus 制定的计划进行审查，评估其清晰度、可验证性、完整性和风险，只有审查通过的计划才会进入执行阶段。 |
|
交叉代码审查 |
指定为“审查者”的Agent (如用GPT Codex审查Claude写的代码) |
Sisyphus (协调者) |
在机械化验证通过后，用不同模型的Agent对代码变更进行逻辑、可读性和设计层面的审查，以发现模型自身的思维盲区。 |
纠正 - 反馈闭环与自愈
|
纠正场景/策略 |
主要负责 Agent/机制 |
支持 Agent |
机制 |
|
自动重试与修复 |
触发错误的执行Agent (如 Sisyphus-Junior) |
验证系统提供的错误信息 |
当 Lint 或测试失败时，Agent 会自动分析错误日志，尝试修复代码并重新运行验证，形成1-3轮的快速自愈循环。 |
|
复杂问题修复建议 |
Hephaestus (自主深度工作者) |
Sisyphus (协调者) |
当简单重试无法解决时（如架构设计问题），Hephaestus 会被调用来进行深度分析，并提供重构方案或修复建议。 |
|
检查点与状态恢复 |
Atlas, 任务状态管理系统 |
Sisyphus |
长任务会定期保存检查点（进度、决策、状态）。任务中断后，新Agent实例可从最新检查点恢复，实现“断点续传”，而非从头开始。 |
|
安全隔离与回滚 |
Git Worktree (沙箱机制) |
Atlas, Sisyphus |
高风险任务在独立的 Git Worktree 中执行。若最终验证失败，直接丢弃整个工作副本即可实现零成本、无污染的完全回滚。 |
|
Critic-Refiner 反馈进化 |
Critic (分析脚本), Refiner (更新脚本) |
系统后台进程 |
Critic 分析 |
|
渐进式人工介入兜底 |
Sisyphus (协调上报者) |
人类用户 |
设定明确升级策略：简单错误自动修 -> 复杂问题建议修 -> 连续失败或重大决策则暂停并上报人类。确保人类精力用于最高价值的判断，而非全程监控。 |
看不变
软件工程的本质是构建确定性的状态机，以可控的成本解决现实世界的复杂性。而大语言模型的本质，则是基于概率分布的下一词预测引擎； 面对 AI 技术日新月异的狂热变化，在变化中还是需要去探寻一些不变的长期支点。
-
变的是“敲代码的动作”，不变的是“契约设计与系统架构能力”
-
未来的高质量代码，不仅是给人和编译器看的，更是给 AI Agent 看的，我们需要精通如何编写极度清晰、低耦合、职责单一的接口契约；只有边界清晰的系统，OMO 这样的框架才能实施高效的渐进式上下文披露
-
-
变的是“技术栈的流行度”，不变的是“对确定性反馈链条的构建”
-
无论 AI 怎么变，软件系统服务于真实业务、需要零故障的本质没有变，如何为 AI Agent 建立完善的测试、监控、可观测性和Harness 闭环
-
-
变的是单元测试的“消费主体”，不变的是测试驱动开发（TDD）的底层哲学
-
单元测试在过去常被视为可有可无的辅助交付物，或者是开发者用来“自查”的工具，AI时代，单元测试是 AI Agent的“眼睛”和“痛觉神经”。没有完善的测试，Agent 就如同在暗室盲行。学会编写完备的、原子化的测试用例，将是指导 AI 走向正确终点的核心技能
-
AI工程化的本质不是让AI变得更聪明，而是让工程系统变得更可分治、更可验证、更可治理 ；从"人类设计，AI执行"到"人类指导，AI设计并执行"，再到"人类与AI共同进化"协作模式的变化将重新定义软件开发的本质。
开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)