@lark-apaas/coding-steering 0.1.20 → 0.1.21-alpha.20260720062635
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -2,23 +2,21 @@
|
|
|
2
2
|
|
|
3
3
|
Stack-specific steering content for [miaoda coding](https://code.byted.org/apaas/miaoda-coding) templates.
|
|
4
4
|
|
|
5
|
-
Consumed by [miaoda-cli](https://code.byted.org/apaas/miaoda-cli)
|
|
5
|
+
Consumed by [miaoda-cli](https://code.byted.org/apaas/miaoda-cli) during `miaoda skills sync` (including `app init`). It is **not a runtime dependency** — no entry in the user project's `package.json`.
|
|
6
6
|
|
|
7
7
|
## Layout
|
|
8
8
|
|
|
9
9
|
```
|
|
10
10
|
steering/
|
|
11
|
-
├── _common/
|
|
12
|
-
│ └── skills/ # cross-stack shared skills
|
|
13
11
|
├── <stack>/
|
|
14
|
-
│ ├── tech.md #
|
|
15
|
-
│ ├──
|
|
16
|
-
│
|
|
17
|
-
│
|
|
12
|
+
│ ├── tech.md # optional, stack overview
|
|
13
|
+
│ ├── skills_common/<id>/SKILL.md # both local and sandbox; copied first
|
|
14
|
+
│ ├── skills/<id>/SKILL.md # sandbox-only; copied after common
|
|
15
|
+
│ └── skills_local/<id>/SKILL.md # local-only; copied after common
|
|
18
16
|
└── ...
|
|
19
17
|
```
|
|
20
18
|
|
|
21
|
-
Top-level directory names
|
|
19
|
+
Top-level directory names are stack IDs — discovery is by directory convention, with no central manifest.
|
|
22
20
|
|
|
23
21
|
## Supported stacks
|
|
24
22
|
|
|
@@ -41,20 +39,20 @@ vice versa). Current state:
|
|
|
41
39
|
|
|
42
40
|
## Sync mapping (executed by miaoda-cli)
|
|
43
41
|
|
|
44
|
-
|
|
45
|
-
|---|---|
|
|
46
|
-
| `steering/<stack>/tech.md` | `.agent/steering/tech.md` |
|
|
47
|
-
| `steering/<stack>/skills/<id>/**` | `.agent/steering/skills/<id>/**` |
|
|
48
|
-
| `steering/<stack>/skills_local/<id>/**` | `.agent/steering/skills/<id>/**` (local-dev sync only) |
|
|
49
|
-
| `steering/_common/skills/<id>/**` | `.agent/steering/skills/<id>/**` |
|
|
42
|
+
`MIAODA_DEP_CACHE_DIR` selects the source mode; `--local` selects only the output layout. Do not use a sandbox environment plus `--local` as evidence for either supported flow.
|
|
50
43
|
|
|
51
|
-
|
|
52
|
-
|
|
44
|
+
| Source in this package | Local output (`MIAODA_DEP_CACHE_DIR` empty + `--local`) | Sandbox output (`MIAODA_DEP_CACHE_DIR` non-empty, no `--local`) |
|
|
45
|
+
| ---------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------- |
|
|
46
|
+
| `steering/<stack>/skills_common/<id>/**` | `.agents/skills/<id>/**` | `.agent/skills/steering/<stack>/skills/<id>/**` |
|
|
47
|
+
| `steering/<stack>/skills_local/<id>/**` | Same local path, copied after common. | Not copied. |
|
|
48
|
+
| `steering/<stack>/skills/<id>/**` | Not copied. | Same sandbox path, copied after common. |
|
|
53
49
|
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
50
|
+
For a duplicated skill ID, the copy order is:
|
|
51
|
+
|
|
52
|
+
- Local: `skills_common → skills_local`; the local variant wins.
|
|
53
|
+
- Sandbox: `skills_common → skills`; the sandbox variant wins.
|
|
54
|
+
|
|
55
|
+
Put a guide in `skills_common/<id>/SKILL.md` when it must reach both supported modes. Keep a same-name `skills/` or `skills_local/` copy only when a deliberate mode-specific override is required.
|
|
58
56
|
|
|
59
57
|
## Writing rules
|
|
60
58
|
|
package/package.json
CHANGED
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: trigger-guide
|
|
3
|
+
description: 自动化任务触发器代码开发指南，支持 cron 定时触发器、record_change 数据变更触发器和 webhook 触发器，包含 @Automation/@BindTrigger 装饰器用法、handler 入参解析和 Crontab 表达式规范。Use when 需要：(1) 为已创建的自动化任务/定时任务编写业务 handler，(2) 编写 automation 代码绑定触发器，或其他自动化任务相关开发
|
|
4
|
+
steering: true
|
|
5
|
+
steering-topic: trigger_guide
|
|
6
|
+
match-template-name: nestjs-react-fullstack
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## 自动化任务配置与代码编写指引
|
|
10
|
+
|
|
11
|
+
### 自动化任务配置
|
|
12
|
+
|
|
13
|
+
1. 新建自动化任务触发器时无需 enable（激活），将任务创建好然后开发完代码即可。触发器随后交由用户主动操作、要求开始。
|
|
14
|
+
|
|
15
|
+
### 目录结构
|
|
16
|
+
|
|
17
|
+
```text
|
|
18
|
+
server
|
|
19
|
+
└── modules
|
|
20
|
+
└── xxx
|
|
21
|
+
├── xxx.automation.ts
|
|
22
|
+
├── xxx.module.ts // 必须在 module 中注册自动化任务类，并且在 app.module.ts 中引用并注册该 module，否则代码将不会生效。
|
|
23
|
+
└── 其他文件（如有的话）
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
文件命名规则：{模块名}.automation.ts
|
|
27
|
+
|
|
28
|
+
注意：
|
|
29
|
+
|
|
30
|
+
1. 每个模块只应该有一个存放自动化任务逻辑的文件，业务逻辑需要聚合到该文件中。
|
|
31
|
+
2. 如果该模块只有对应的自动化任务，无需编写 Controller
|
|
32
|
+
|
|
33
|
+
### 触发器类型
|
|
34
|
+
|
|
35
|
+
触发器类型（`triggerType`）有三种：
|
|
36
|
+
|
|
37
|
+
- `record_change`：记录变更触发器，**有入参**
|
|
38
|
+
- `cron`：定时触发器，**无入参**
|
|
39
|
+
- `webhook`：Webhook 触发器，**有入参**
|
|
40
|
+
|
|
41
|
+
各触发器 handler 的入参类型定义（`TaskHandlerArgs`、`DataChangeEventInput`、`WebhookEvent`）见 [触发器入参类型与代码示例](references/trigger-lifecycle.md)。
|
|
42
|
+
|
|
43
|
+
### 指定值限制
|
|
44
|
+
|
|
45
|
+
1. Webhook 触发器不可以设置指定值，并且告知用户。
|
|
46
|
+
|
|
47
|
+
### 代码绑定
|
|
48
|
+
|
|
49
|
+
你需要根据触发器创建后确定的自动化任务名字（应用内唯一），编写并绑定到对应的方法上：`@BindTrigger('<任务名字>')` 中的名字必须与创建触发器时确定的名字逐字相同，不能用 trigger ID 或方法名代替。`@Automation()` 标记的类需注册为对应 `<module>.module.ts` 的 provider，且该 module 必须被 `server/app.module.ts` 直接或传递 import，否则装饰器不会生效。完整代码示例见 [触发器入参类型与代码示例](references/trigger-lifecycle.md)。
|
|
50
|
+
|
|
51
|
+
### 任务代码实现约束
|
|
52
|
+
|
|
53
|
+
1. 执行自动化任务时无法获取用户信息。依赖用户信息的场景，实现路径如下：
|
|
54
|
+
- 需要查询数据库中的特定数据，给用户发消息：数据库中需要存储用户 id，使用从数据库中查询到的用户 id 进行后续操作
|
|
55
|
+
- 需要调用飞书能力给用户发消息：飞书能力不应该接受用户信息作为参数，而是应该在飞书能力配置里要求用户自己预先指定
|
|
56
|
+
|
|
57
|
+
2. 入参解析规范（仅 record_change 和 webhook 触发器）：
|
|
58
|
+
- 有入参的触发器方法签名为 `async methodName(event: TaskHandlerArgs)`，`cron` 触发器无入参
|
|
59
|
+
- `content.input` 是 JSON 字符串，先用 `typeof input === 'string'` 检查类型，再用 `JSON.parse()` 解析，需添加 try-catch 错误处理
|
|
60
|
+
- `record_change`：根据操作类型获取数据：INSERT/UPDATE 使用 `after` 字段，DELETE 使用 `before` 字段
|
|
61
|
+
- `webhook`：从 `method`、`path`、`query`、`headers`、`body` 中按需取用；`body` 本身也是 JSON 字符串，需要时再次 `JSON.parse()` 解析；`query` 和 `headers` 的值均为 `string[]`
|
|
62
|
+
|
|
63
|
+
### 技术实现路径参考
|
|
64
|
+
|
|
65
|
+
以下常见需求的推荐实现路径，帮助你在平台能力限制下找到合理的技术方案；完整代码见 [触发器入参类型与代码示例](references/trigger-lifecycle.md)。
|
|
66
|
+
|
|
67
|
+
- **场景一：管理页面控制定时任务启停** —— 平台侧不支持通过 API 动态启停触发器；定时触发器始终保持开启，在任务执行时查询数据库中的开关状态决定是否执行。
|
|
68
|
+
- **场景二：定时任务通知特定用户** —— 任务执行时无法获取用户上下文；在数据库预存目标用户 ID，执行时查询再调用飞书插件发送。
|
|
69
|
+
- **场景三：记录变更触发器防抖/去重** —— 利用数据库记录最近一次处理时间戳，对比 event 时间戳进行去重。
|
|
70
|
+
- **场景四：自定义定时任务触发时间** —— cron 创建后不可动态改；平台设固定高频定时器（如每 30 分钟），执行时读数据库配置判断是否命中。
|
|
71
|
+
|
|
72
|
+
## Crontab 表达式规范
|
|
73
|
+
|
|
74
|
+
### 基本结构
|
|
75
|
+
|
|
76
|
+
Crontab 表达式由 5 个字段组成：`<minute> <hour> <day> <month> <week>`
|
|
77
|
+
|
|
78
|
+
### 字段说明
|
|
79
|
+
|
|
80
|
+
1. **minute（分钟）**：0-59 的整数
|
|
81
|
+
2. **hour（小时）**：0-23 的整数
|
|
82
|
+
3. **day（日期）**：1-31 的整数，或大写字母 `L` 表示月份的最后一天
|
|
83
|
+
4. **month（月份）**：1-12 的整数
|
|
84
|
+
5. **week（星期）**：0-6 的整数，其中 0 表示星期天
|
|
85
|
+
|
|
86
|
+
### 特殊字符
|
|
87
|
+
|
|
88
|
+
- **星号 `*`**：表示所有可能的值（每）
|
|
89
|
+
- 例：`* * * * *` 表示每分钟
|
|
90
|
+
- **逗号 `,`**：表示列表范围
|
|
91
|
+
- 例：`1,2,3 * * * *` 表示每小时的第 1、2、3 分钟
|
|
92
|
+
- **中杠 `-`**：表示数值范围
|
|
93
|
+
- 例：`1-10 * * * *` 表示每小时的第 1 到 10 分钟
|
|
94
|
+
- **正斜线 `/`**：表示间隔频率
|
|
95
|
+
- 例：`0 10-18/2 * * *` 表示每天 10 点到 18 点，每隔 2 小时执行
|
|
96
|
+
|
|
97
|
+
## 输出要求
|
|
98
|
+
|
|
99
|
+
1. 必须以 JSON 格式输出
|
|
100
|
+
2. JSON 包含两个字段：
|
|
101
|
+
- `expression`：Crontab 表达式字符串
|
|
102
|
+
- `explanation`：中文说明，简要描述执行时间
|
|
103
|
+
3. 如果用户描述不清晰，请询问具体细节
|
|
104
|
+
|
|
105
|
+
## 示例
|
|
106
|
+
|
|
107
|
+
**用户输入**：每天早上 8 点执行
|
|
108
|
+
|
|
109
|
+
**输出**：
|
|
110
|
+
|
|
111
|
+
```json
|
|
112
|
+
{
|
|
113
|
+
"expression": "0 8 * * *",
|
|
114
|
+
"explanation": "每天早上 8:00 执行"
|
|
115
|
+
}
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
**用户输入**：每周一到周五的上午 9 点和下午 6 点执行
|
|
119
|
+
|
|
120
|
+
**输出**：
|
|
121
|
+
|
|
122
|
+
```json
|
|
123
|
+
{
|
|
124
|
+
"expression": "0 9,18 * * 1-5",
|
|
125
|
+
"explanation": "每周一至周五的 9:00 和 18:00 执行"
|
|
126
|
+
}
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
**用户输入**：每隔 30 分钟执行一次
|
|
130
|
+
|
|
131
|
+
**输出**：
|
|
132
|
+
|
|
133
|
+
```json
|
|
134
|
+
{
|
|
135
|
+
"expression": "*/30 * * * *",
|
|
136
|
+
"explanation": "每隔 30 分钟执行一次"
|
|
137
|
+
}
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**用户输入**：每月最后一天的晚上 11 点执行
|
|
141
|
+
|
|
142
|
+
**输出**：
|
|
143
|
+
|
|
144
|
+
```json
|
|
145
|
+
{
|
|
146
|
+
"expression": "0 23 L * *",
|
|
147
|
+
"explanation": "每月最后一天的 23:00 执行"
|
|
148
|
+
}
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
**用户输入**：每个工作日的每小时第 15 和 45 分钟执行
|
|
152
|
+
|
|
153
|
+
**输出**：
|
|
154
|
+
|
|
155
|
+
```json
|
|
156
|
+
{
|
|
157
|
+
"expression": "15,45 * * * 1-5",
|
|
158
|
+
"explanation": "每周一至周五，每小时的第 15 和 45 分钟执行"
|
|
159
|
+
}
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
**用户输入**：每天上午 10 点到下午 6 点，每隔 2 小时执行
|
|
163
|
+
|
|
164
|
+
**输出**：
|
|
165
|
+
|
|
166
|
+
```json
|
|
167
|
+
{
|
|
168
|
+
"expression": "0 10-18/2 * * *",
|
|
169
|
+
"explanation": "每天 10:00、12:00、14:00、16:00、18:00 执行"
|
|
170
|
+
}
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
## 注意事项
|
|
174
|
+
|
|
175
|
+
- 星期字段：0 和 7 都可以表示星期天（但本规范使用 0）
|
|
176
|
+
- 时间采用 24 小时制
|
|
177
|
+
- 月份和星期都从较小的数字开始计数
|
|
178
|
+
- 确保生成的表达式符合实际日历逻辑
|
|
179
|
+
- 由于技术限制，最小间隔为 30 分钟，如用户要求有误请直接拒绝用户并给出原因
|
|
180
|
+
- 输出必须是有效的 JSON 格式
|
|
@@ -1,36 +1,8 @@
|
|
|
1
|
-
|
|
2
|
-
name: trigger-guide
|
|
3
|
-
description: 自动化任务触发器配置与代码开发指南，支持 cron 定时触发器、record_change 数据变更触发器和 webhook 触发器，包含 @Automation/@BindTrigger 装饰器用法和 Crontab 表达式规范。Use when 需要：(1) 创建或配置自动化任务/定时任务，(2) 编写 automation 代码绑定触发器，或其他自动化任务相关开发
|
|
4
|
-
steering: true
|
|
5
|
-
steering-topic: trigger_guide
|
|
6
|
-
match-template-name: nestjs-react-fullstack
|
|
7
|
-
---
|
|
1
|
+
# 触发器入参类型与代码示例
|
|
8
2
|
|
|
9
|
-
|
|
3
|
+
本 reference 承载 nestjs-react-fullstack 触发器 handler 的入参类型定义、完整代码示例与常见实现场景。先读主 [trigger-guide](../SKILL.md) 了解目录结构、绑定约束与配置要求。
|
|
10
4
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
1. 新建自动化任务触发器时无需 enable（激活），将任务创建好然后开发完代码即可。触发器随后交由用户主动操作、要求开始。
|
|
14
|
-
|
|
15
|
-
### 目录结构
|
|
16
|
-
|
|
17
|
-
```text
|
|
18
|
-
server
|
|
19
|
-
└── modules
|
|
20
|
-
└── xxx
|
|
21
|
-
├── xxx.automation.ts
|
|
22
|
-
├── xxx.module.ts // 必须在 module 中注册自动化任务类，并且在 app.module.ts 中引用并注册该 module，否则代码将不会生效。
|
|
23
|
-
└── 其他文件（如有的话）
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
文件命名规则：{模块名}.automation.ts
|
|
27
|
-
|
|
28
|
-
注意：
|
|
29
|
-
|
|
30
|
-
1. 每个模块只应该有一个存放自动化任务逻辑的文件，业务逻辑需要聚合到该文件中。
|
|
31
|
-
2. 如果该模块只有对应的自动化任务，无需编写 Controller
|
|
32
|
-
|
|
33
|
-
### 触发器类型与入参
|
|
5
|
+
## 触发器类型与入参
|
|
34
6
|
|
|
35
7
|
触发器类型（`triggerType`）有三种：
|
|
36
8
|
|
|
@@ -85,12 +57,11 @@ interface WebhookEvent {
|
|
|
85
57
|
}
|
|
86
58
|
```
|
|
87
59
|
|
|
88
|
-
|
|
89
|
-
1. Webhook 触发器不可以设置指定值，并且告知用户。
|
|
60
|
+
`DataChangeEventInput.type` 只定义 `INSERT`、`UPDATE`、`DELETE`，不包含 `UPSERT`。
|
|
90
61
|
|
|
91
|
-
|
|
62
|
+
## 代码示例
|
|
92
63
|
|
|
93
|
-
|
|
64
|
+
根据触发器创建后确定的任务名字（应用内唯一），编写并绑定到对应的方法上。使用模板已有的 `@lark-apaas/fullstack-nestjs-core` 聚合入口导入 `Automation` / `BindTrigger`，不要求项目再感知底层 trigger 包。具体代码示例如下：
|
|
94
65
|
|
|
95
66
|
```typescript
|
|
96
67
|
// 文件名：demo.automation.ts
|
|
@@ -184,23 +155,11 @@ export class DemoAutomationTasksService {
|
|
|
184
155
|
}
|
|
185
156
|
```
|
|
186
157
|
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
1. 执行自动化任务时无法获取用户信息。依赖用户信息的场景，实现路径如下：
|
|
190
|
-
- 需要查询数据库中的特定数据，给用户发消息：数据库中需要存储用户 id，使用从数据库中查询到的用户 id 进行后续操作
|
|
191
|
-
- 需要调用飞书能力给用户发消息：飞书能力不应该接受用户信息作为参数，而是应该在飞书能力配置里要求用户自己预先指定
|
|
192
|
-
|
|
193
|
-
2. 入参解析规范（仅 record_change 和 webhook 触发器）：
|
|
194
|
-
- 有入参的触发器方法签名为 `async methodName(event: TaskHandlerArgs)`，`cron` 触发器无入参
|
|
195
|
-
- `content.input` 是 JSON 字符串，先用 `typeof input === 'string'` 检查类型，再用 `JSON.parse()` 解析，需添加 try-catch 错误处理
|
|
196
|
-
- `record_change`：根据操作类型获取数据：INSERT/UPDATE 使用 `after` 字段，DELETE 使用 `before` 字段
|
|
197
|
-
- `webhook`：从 `method`、`path`、`query`、`headers`、`body` 中按需取用；`body` 本身也是 JSON 字符串，需要时再次 `JSON.parse()` 解析；`query` 和 `headers` 的值均为 `string[]`
|
|
198
|
-
|
|
199
|
-
### 技术实现路径参考
|
|
158
|
+
## 技术实现路径参考
|
|
200
159
|
|
|
201
160
|
以下是一些常见需求的推荐实现路径，帮助你在平台能力限制下找到合理的技术方案。
|
|
202
161
|
|
|
203
|
-
|
|
162
|
+
### 场景一：用户需要管理页面控制定时任务的启停
|
|
204
163
|
|
|
205
164
|
平台侧不支持通过 API 动态启停触发器。推荐方案：**平台定时触发器始终保持开启，在任务执行时查询数据库中的开关状态，决定是否真正执行业务逻辑。**
|
|
206
165
|
|
|
@@ -233,7 +192,7 @@ export class ReportAutomationService {
|
|
|
233
192
|
}
|
|
234
193
|
```
|
|
235
194
|
|
|
236
|
-
|
|
195
|
+
### 场景二：定时任务需要将结果通知给特定用户
|
|
237
196
|
|
|
238
197
|
自动化任务执行时无法获取当前用户上下文。推荐方案：**在数据库中预存需要通知的用户 ID，任务执行时从数据库查询目标用户，再调用飞书插件发送通知。**
|
|
239
198
|
|
|
@@ -267,7 +226,7 @@ export class NotifyAutomationService {
|
|
|
267
226
|
}
|
|
268
227
|
```
|
|
269
228
|
|
|
270
|
-
|
|
229
|
+
### 场景三：记录变更触发器需要做防抖/去重
|
|
271
230
|
|
|
272
231
|
高频数据变更场景下，同一条记录可能短时间内触发多次。推荐方案：**利用数据库记录最近一次处理时间戳，对比 event 时间戳进行去重。**
|
|
273
232
|
|
|
@@ -294,7 +253,7 @@ async handleOrderChange(event: TaskHandlerArgs) {
|
|
|
294
253
|
}
|
|
295
254
|
```
|
|
296
255
|
|
|
297
|
-
|
|
256
|
+
### 场景四：用户需要自定义定时任务的触发时间
|
|
298
257
|
|
|
299
258
|
平台侧的 cron 表达式在触发器创建后无法由用户动态修改。推荐方案：**平台设置一个固定的高频定时器（如每 30 分钟执行一次），在任务执行时从数据库读取用户配置的触发时间，判断当前是否命中再决定是否执行。**
|
|
300
259
|
|
|
@@ -340,113 +299,3 @@ export class ScheduleAutomationService {
|
|
|
340
299
|
```
|
|
341
300
|
|
|
342
301
|
> 注意：由于平台最小调度间隔为 30 分钟，用户可配置的时间精度也应限制为 30 分钟的整数倍（如 `09:00`、`09:30`），前端做好校验提示。
|
|
343
|
-
|
|
344
|
-
## Crontab 表达式规范
|
|
345
|
-
|
|
346
|
-
### 基本结构
|
|
347
|
-
|
|
348
|
-
Crontab 表达式由 5 个字段组成：`<minute> <hour> <day> <month> <week>`
|
|
349
|
-
|
|
350
|
-
### 字段说明
|
|
351
|
-
|
|
352
|
-
1. **minute（分钟）**：0-59 的整数
|
|
353
|
-
2. **hour（小时）**：0-23 的整数
|
|
354
|
-
3. **day（日期）**：1-31 的整数，或大写字母 `L` 表示月份的最后一天
|
|
355
|
-
4. **month（月份）**：1-12 的整数
|
|
356
|
-
5. **week（星期）**：0-6 的整数，其中 0 表示星期天
|
|
357
|
-
|
|
358
|
-
### 特殊字符
|
|
359
|
-
|
|
360
|
-
- **星号 `*`**：表示所有可能的值（每）
|
|
361
|
-
- 例：`* * * * *` 表示每分钟
|
|
362
|
-
- **逗号 `,`**：表示列表范围
|
|
363
|
-
- 例：`1,2,3 * * * *` 表示每小时的第 1、2、3 分钟
|
|
364
|
-
- **中杠 `-`**：表示数值范围
|
|
365
|
-
- 例：`1-10 * * * *` 表示每小时的第 1 到 10 分钟
|
|
366
|
-
- **正斜线 `/`**：表示间隔频率
|
|
367
|
-
- 例：`0 10-18/2 * * *` 表示每天 10 点到 18 点，每隔 2 小时执行
|
|
368
|
-
|
|
369
|
-
## 输出要求
|
|
370
|
-
|
|
371
|
-
1. 必须以 JSON 格式输出
|
|
372
|
-
2. JSON 包含两个字段：
|
|
373
|
-
- `expression`：Crontab 表达式字符串
|
|
374
|
-
- `explanation`：中文说明，简要描述执行时间
|
|
375
|
-
3. 如果用户描述不清晰，请询问具体细节
|
|
376
|
-
|
|
377
|
-
## 示例
|
|
378
|
-
|
|
379
|
-
**用户输入**：每天早上 8 点执行
|
|
380
|
-
|
|
381
|
-
**输出**：
|
|
382
|
-
|
|
383
|
-
```json
|
|
384
|
-
{
|
|
385
|
-
"expression": "0 8 * * *",
|
|
386
|
-
"explanation": "每天早上 8:00 执行"
|
|
387
|
-
}
|
|
388
|
-
```
|
|
389
|
-
|
|
390
|
-
**用户输入**：每周一到周五的上午 9 点和下午 6 点执行
|
|
391
|
-
|
|
392
|
-
**输出**：
|
|
393
|
-
|
|
394
|
-
```json
|
|
395
|
-
{
|
|
396
|
-
"expression": "0 9,18 * * 1-5",
|
|
397
|
-
"explanation": "每周一至周五的 9:00 和 18:00 执行"
|
|
398
|
-
}
|
|
399
|
-
```
|
|
400
|
-
|
|
401
|
-
**用户输入**：每隔 30 分钟执行一次
|
|
402
|
-
|
|
403
|
-
**输出**：
|
|
404
|
-
|
|
405
|
-
```json
|
|
406
|
-
{
|
|
407
|
-
"expression": "*/30 * * * *",
|
|
408
|
-
"explanation": "每隔 30 分钟执行一次"
|
|
409
|
-
}
|
|
410
|
-
```
|
|
411
|
-
|
|
412
|
-
**用户输入**：每月最后一天的晚上 11 点执行
|
|
413
|
-
|
|
414
|
-
**输出**：
|
|
415
|
-
|
|
416
|
-
```json
|
|
417
|
-
{
|
|
418
|
-
"expression": "0 23 L * *",
|
|
419
|
-
"explanation": "每月最后一天的 23:00 执行"
|
|
420
|
-
}
|
|
421
|
-
```
|
|
422
|
-
|
|
423
|
-
**用户输入**：每个工作日的每小时第 15 和 45 分钟执行
|
|
424
|
-
|
|
425
|
-
**输出**：
|
|
426
|
-
|
|
427
|
-
```json
|
|
428
|
-
{
|
|
429
|
-
"expression": "15,45 * * * 1-5",
|
|
430
|
-
"explanation": "每周一至周五，每小时的第 15 和 45 分钟执行"
|
|
431
|
-
}
|
|
432
|
-
```
|
|
433
|
-
|
|
434
|
-
**用户输入**：每天上午 10 点到下午 6 点，每隔 2 小时执行
|
|
435
|
-
|
|
436
|
-
**输出**：
|
|
437
|
-
|
|
438
|
-
```json
|
|
439
|
-
{
|
|
440
|
-
"expression": "0 10-18/2 * * *",
|
|
441
|
-
"explanation": "每天 10:00、12:00、14:00、16:00、18:00 执行"
|
|
442
|
-
}
|
|
443
|
-
```
|
|
444
|
-
|
|
445
|
-
## 注意事项
|
|
446
|
-
|
|
447
|
-
- 星期字段：0 和 7 都可以表示星期天（但本规范使用 0）
|
|
448
|
-
- 时间采用 24 小时制
|
|
449
|
-
- 月份和星期都从较小的数字开始计数
|
|
450
|
-
- 确保生成的表达式符合实际日历逻辑
|
|
451
|
-
- 由于技术限制，最小间隔为 30 分钟，如用户要求有误请直接拒绝用户并给出原因
|
|
452
|
-
- 输出必须是有效的 JSON 格式
|