AI CLI 开发工作流

一、核心思路

以后开发方式从传统的：

IDE / 桌面端 → 自己写代码 → AI 辅助

逐渐调整为：

需求 → Context Engineering → SDD 设计 → TDD 约束 → CLI → Comet 多 Agent 执行 → 人工 Review → 修正文档 → 再执行

核心变化：

• 人主要负责：需求、上下文、技术方案、验收
• AI 主要负责：编码、测试、修改、重复性执行
• 尽量减少自己手动写大量业务代码
• 从桌面端 AI 工具逐渐迁移到 CLI 开发
• 不追求“一条 Prompt 把项目做完”
• 通过多轮 Prompt → 执行 → 检查 → 修正文档 → 再执行 完成开发

二、整体技术栈

1. 工作流编排

Comet

项目：

rpamis/comet

定位：

多 Agent / 多任务 AI 编码工作流编排。

主要用途：

• 将任务交给 AI Agent 执行
• 同时推进多个开发任务
• 后台执行任务
• 人负责不断准备下一批任务
• 执行完成后统一 Review

理想状态：

我
 ↓
编写需求 / Prompt / Spec
 ↓
Comet
 ↓
Agent A ── 后端开发
Agent B ── 前端开发
Agent C ── 单元测试
Agent D ── Code Review
 ↓
人工检查
 ↓
发现问题
 ↓
修改 Spec / Prompt
 ↓
再次交给 Comet

三、Skills

1. OpenSpec —— SDD

项目：

Fission-AI/openspec

核心思想：

Specification-Driven Development

即：

规格驱动开发（SDD）

不要一上来就让 AI：

“帮我实现这个功能。”

而是先把需求定义清楚。

例如：

需求
 ↓
Specification
 ↓
技术方案
 ↓
任务拆分
 ↓
代码实现
 ↓
验证

需要重点学习：

• 如何写 Spec
• 如何描述需求
• 如何描述边界条件
• 如何定义验收标准
• 如何拆分开发任务
• 如何让 AI 根据 Spec 开发

2. Superpowers —— TDD

项目：

obra/superpowers

重点学习：

Test-Driven Development

即：

测试驱动开发（TDD）

基本流程：

需求
 ↓
先写测试
 ↓
测试失败 Red
 ↓
实现功能
 ↓
测试通过 Green
 ↓
重构 Refactor

对于 AI Coding 来说，TDD 非常重要。

因为不能只让 AI 判断：

“我写完了。”

而应该通过测试判断：

“这个功能到底是不是真的完成了。”

最终形成：

SDD
负责定义：
“应该做什么”

+

TDD
负责验证：
“做得对不对”

3. Matt Pocock Skills

项目：

mattpocock/skills

重点：

grill-me

作用：

让 AI 在开发之前主动追问需求。

例如你说：

做一个订单导出功能。

AI 不应该直接开始写代码，而应该继续确认：

导出格式是什么？

Excel 还是 CSV？

最大数据量多少？

同步导出还是异步导出？

是否需要权限控制？

是否需要记录导出历史？

是否允许导出敏感字段？

数据量超过 10 万怎么办？

通过不断“拷问需求”，减少 AI 自己脑补。

4. 其他 Skills

可以逐渐研究：

browser-harness
show-me
eli5
...

不需要一次全部学习。

优先级：

OpenSpec
   ↓
Superpowers
   ↓
grill-me
   ↓
其他 Skills

四、MCP

计划使用：

Context7

用途：

获取最新技术文档和 Library Context。

例如：

Spring Boot
Vue 3
MyBatis
Redis
第三方 SDK

避免 AI 使用过时 API。

Memory

保存项目长期上下文。

例如：

项目技术栈
代码规范
架构约定
数据库规范
接口规范
历史技术决策

避免每次重新告诉 AI。

Sequential Thinking

用于：

复杂问题分析
技术方案推理
Bug 排查
架构设计
复杂业务拆分

MySQL MCP

让 AI：

查看数据库结构
查看表
查看字段
分析 SQL
验证 SQL
排查数据问题

Redis MCP

让 AI：

查看 Redis Key
分析缓存
排查缓存问题
验证 Redis 数据

五、Context Engineering

这是整个工作流非常重要的一部分。

传统 Prompt Engineering 更关注：

这一句话怎么问 AI？

Context Engineering 更关注：

AI 在开始工作之前，应该知道哪些信息？

例如开发一个功能，不能只给：

帮我实现订单退款。

应该提供：

项目背景
业务需求
技术栈
代码规范
项目目录
数据库结构
已有代码
接口规范
业务规则
禁止事项
测试要求
验收标准

目标是：

尽可能减少 AI 的猜测。

六、技术方案应该写什么

以后复杂功能不要直接 Coding。

先写技术方案。

1. 功能目标

明确：

要解决什么问题
用户怎么使用
最终实现什么效果

2. 做什么

明确需要实现：

新增什么功能
修改什么功能
新增哪些接口
新增哪些页面
新增哪些数据库字段
新增哪些类

3. 怎么做

必须描述具体技术实现。

例如：

Controller
 ↓
Service
 ↓
Domain Service
 ↓
Mapper
 ↓
MySQL

不要只写：

实现批量保存。

应该写清楚：

数据如何获取

如何拆分批次

每批多少条

是否使用 MyBatis Batch

事务边界在哪里

失败是否回滚

是否允许部分成功

数据量上限是多少

4. 不要做什么

明确禁止事项。

例如：

不要修改现有接口返回结构

不要修改公共组件

不要引入新的第三方依赖

不要直接操作生产数据库

不要改变已有数据库字段含义

不要为了实现功能进行无关重构

这一部分可以有效防止 AI “顺手重构整个项目”。

七、项目代码目录树

技术方案需要告诉 AI 项目结构。

例如：

src/
├── controller/
│   └── OrderController.java
│
├── service/
│   ├── OrderService.java
│   └── impl/
│       └── OrderServiceImpl.java
│
├── mapper/
│   └── OrderMapper.java
│
├── entity/
│   └── Order.java
│
├── dto/
│   └── OrderDTO.java
│
└── vo/
    └── OrderVO.java

并说明每个文件的作用。

例如：

OrderController
负责 HTTP 接口

OrderService
定义订单业务接口

OrderServiceImpl
实现订单业务逻辑

OrderMapper
数据库访问

OrderDTO
接口请求参数

OrderVO
接口响应数据

八、文件之间的关系

不能只告诉 AI 有哪些文件。

还应该告诉它：

OrderController
       ↓
OrderService
       ↓
OrderServiceImpl
       ↓
OrderMapper
       ↓
MySQL

复杂功能还需要描述调用关系：

Controller
 ↓
OrderService
 ↓
InventoryService
 ↓
PaymentService
 ↓
OrderMapper
 ↓
MQ

这样 AI 才不会随意改变项目结构。

九、外部接口

所有第三方接口最好建立：

接口字典

例如：

支付接口

POST /payment/refund

Request:

{
    "orderNo": "xxx",
    "amount": 100
}

Response:

{
    "code": 0,
    "refundNo": "xxx"
}

需要说明：

请求方式
URL
请求参数
返回参数
错误码
超时时间
重试机制
异常处理

十、枚举

业务状态必须明确。

例如：

OrderStatus

WAIT_PAY
PAID
SHIPPED
FINISHED
CANCELLED

不要让 AI 自己猜：

0 = ?
1 = ?
2 = ?

应该在 Context / Spec 中明确。

十一、复杂功能设计

复杂功能需要单独写设计方案。

例如：

批量插入

不能只写：

批量保存订单。

应该明确：

数据量：最大 10 万

每批：
1000 条

实现：
MyBatis Batch

事务：
每批独立事务

失败：
记录失败批次

日志：
记录 batchId

禁止：
逐条 insert

这样 AI 才能按照预期实现。

十二、前端方案

前端不能只告诉 AI：

做个订单管理页面。

需要明确页面组成。

例如：

菜单

订单管理
 ├── 订单列表
 └── 退款记录

搜索条件

订单号

用户手机号

订单状态

创建时间

支付时间

按钮

查询

重置

导出

查看详情

退款

弹框

退款弹框：

退款金额

退款原因

备注

取消

确认退款

十三、前端样式

需要定义：

使用现有项目 UI 风格

优先复用已有组件

不要自己创建新的设计体系

表格风格跟随现有页面

按钮颜色跟随项目主题

弹窗宽度遵循项目规范

具体 UI 规则可以通过：

Context Rules

统一控制。

十四、后端技术规则

后端同样通过 Context Rules 控制。

例如：

Java 17

Spring Boot 3

MyBatis Plus

MySQL

Redis

RocketMQ

Lombok

同时定义规则：

Controller 不写业务逻辑

Service 控制事务

Mapper 只负责数据库

DTO / VO 分离

禁止 Entity 直接返回前端

统一 Result 返回

统一异常处理

统一日志规范

以后不用每个 Prompt 重复。

十五、推荐开发流程

完整流程：

需求
 ↓
grill-me
 ↓
需求澄清
 ↓
Context Engineering
 ↓
OpenSpec / SDD
 ↓
技术方案
 ↓
任务拆分
 ↓
Superpowers / TDD
 ↓
Comet
 ↓
Codex / Agent 执行
 ↓
测试
 ↓
人工 Review
 ↓
发现问题
 ↓
修改 Spec / Context
 ↓
重新交给 Comet
 ↓
直到验收通过

十六、每天实际工作方式

以后上班之后，不是马上开始写代码。

例如早上：

09:00 - 10:00

分析今天的需求

↓

写 Prompt / Spec

↓

补充 Context

↓

写技术方案

↓

拆分任务

准备好以后：

Prompt / Spec
      ↓
    Comet
      ↓
Agent 开始开发

Agent 工作的时候，不需要一直等。

继续：

准备第二个任务
 ↓
写第二份 Prompt
 ↓
交给 Comet

准备第三个任务
 ↓
写第三份 Prompt
 ↓
交给 Comet

然后回来检查第一个任务：

检查代码
 ↓
运行测试
 ↓
查看 Diff
 ↓
发现问题
 ↓
不要直接手改
 ↓
修改 Spec / Prompt / 文档
 ↓
重新交给 Comet

形成循环：

写需求
   ↓
丢给 Comet
   ↓
写下一个需求
   ↓
丢给 Comet
   ↓
Review 前一个任务
   ↓
发现问题
   ↓
修改文档
   ↓
再次丢给 Comet
   ↓
继续下一个任务

十七、工作习惯调整

以前：

IDE
 ↓
找到文件
 ↓
自己写代码
 ↓
AI 补全
 ↓
Debug

以后逐渐调整：

CLI
 ↓
理解需求
 ↓
准备 Context
 ↓
写 Spec
 ↓
写技术方案
 ↓
Agent Coding
 ↓
测试
 ↓
Review Diff
 ↓
修改 Spec

人的价值逐渐从：

写代码

转向：

描述问题 + 设计方案 + 管理 Context + 验收 AI 代码

十八、学习优先级

第一阶段：

CLI 开发习惯
Context Engineering
Comet

第二阶段：

SDD
OpenSpec

第三阶段：

TDD
Superpowers

第四阶段：

grill-me
Context7
Memory
Sequential Thinking
MySQL MCP
Redis MCP

最后，如果对架构进一步感兴趣：

DDD
Domain-Driven Design
领域驱动设计

DDD 暂时不是最高优先级。

先把：

Context Engineering + SDD + TDD + CLI + Agent 工作流

真正用起来。

十九、一句话总结

这套 AI 开发模式的核心不是：

让 AI 帮我写代码。

而是：

我负责把需求、上下文、技术方案和验收标准定义清楚，再通过 SDD + TDD + Skills + MCP + Comet 驱动多个 AI Agent 完成开发。

最终工作循环：

Think
 ↓
Spec
 ↓
Plan
 ↓
Test
 ↓
Delegate
 ↓
Review
 ↓
Fix Context
 ↓
Delegate Again

也就是：

人负责定义正确的问题和方案，AI 负责高速执行，人再负责验收和纠偏。