@deployxai/dxc 0.1.13 → 0.2.0
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 +4 -5
- package/dist/chunks/chunk-7DMYDQPR.js +1324 -0
- package/dist/chunks/{knowledge-MNDWLVLM.js → knowledge-MHD76CG4.js} +2 -4
- package/dist/index.js +28334 -30531
- package/package.json +1 -1
- package/skills/dxc-content-workflow/SKILL.md +69 -243
- package/skills/dxc-content-workflow/references/onboarding-questions.md +2 -7
- package/skills/dxc-content-workflow/references/stages.md +79 -0
- package/skills/dxc-knowledge/SKILL.md +2 -2
- package/skills/dxc-memory/SKILL.md +2 -2
- package/skills/dxc-profile/SKILL.md +4 -4
- package/skills/dxc-quote-curator/SKILL.md +4 -6
- package/dist/chunks/chunk-DDKUG5EV.js +0 -2126
- package/dist/chunks/chunk-RONRJJBC.js +0 -2379
- package/dist/chunks/chunk-ZKJQWR2J.js +0 -37
- package/dist/chunks/monitor-ACOHQYOE.js +0 -694
- package/skills/dxc-article-outline/SKILL.md +0 -71
- package/skills/dxc-article-outline/agents/openai.yaml +0 -6
- package/skills/dxc-article-outline/references/outline-methods.md +0 -58
- package/skills/dxc-article-write/SKILL.md +0 -105
- package/skills/dxc-article-write/agents/openai.yaml +0 -6
- package/skills/dxc-article-write/references/writing-methods.md +0 -62
- package/skills/dxc-content-brief/SKILL.md +0 -72
- package/skills/dxc-content-brief/agents/openai.yaml +0 -6
- package/skills/dxc-content-brief/references/brief-method.md +0 -52
- package/skills/dxc-content-review/SKILL.md +0 -82
- package/skills/dxc-content-review/agents/openai.yaml +0 -6
- package/skills/dxc-content-review/references/review-checklist.md +0 -52
- package/skills/dxc-content-workflow/references/catalog.json +0 -137
- package/skills/dxc-content-workflow/references/stage-contract.md +0 -121
- package/skills/dxc-research/SKILL.md +0 -134
- package/skills/dxc-research/agents/openai.yaml +0 -6
- package/skills/dxc-research/references/research-method.md +0 -80
- package/skills/dxc-title-write/SKILL.md +0 -104
- package/skills/dxc-title-write/agents/openai.yaml +0 -6
- package/skills/dxc-title-write/references/title-methods.md +0 -41
- package/skills/dxc-visual-plan/SKILL.md +0 -209
- package/skills/dxc-visual-plan/agents/openai.yaml +0 -6
- package/skills/dxc-visual-plan/references/visual-methods.md +0 -53
- package/skills/dxc-wechat-publisher/SKILL.md +0 -226
- package/skills/dxc-wechat-publisher/agents/openai.yaml +0 -6
|
@@ -1,209 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: dxc-visual-plan
|
|
3
|
-
description: DxC 内容工作流的视觉生产步骤。由 dxc-content-workflow 在 visual-plan 阶段调用,消费已确认正文和已选标题,并可读取大纲锚点;必须生成或选择实际可交付的公众号封面,按内容需要生成或选择正文配图,保存到项目素材目录并记录可复验清单。
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# DxC 视觉生产
|
|
7
|
-
|
|
8
|
-
## 对用户的呈现
|
|
9
|
-
|
|
10
|
-
用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径;只说明当前结果、需要用户做的选择,以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口:Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`,macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`,同一任务后续必须保持已选入口;不得让用户打开终端、复制命令或处理环境变量。
|
|
11
|
-
|
|
12
|
-
本 Skill 只负责名为 `visual-plan` 的视觉生产阶段。它不是只写建议的规划文档:阶段完成时
|
|
13
|
-
必须存在一张内容相关、可交付的真实封面;计划采用的每张正文图也必须已经落盘。图片生成
|
|
14
|
-
或用户明确选择的本地素材是互补来源,最终都进入同一套本地素材校验与云端快照交付通道。
|
|
15
|
-
本阶段不上传微信;上传发生在云端预览阶段。
|
|
16
|
-
|
|
17
|
-
## 进入阶段
|
|
18
|
-
|
|
19
|
-
1. 运行 `dxc project status --json`,确认 `article` 与 `titles` 已完成;大纲存在且本次需要
|
|
20
|
-
配图锚点时读取 `outline`。
|
|
21
|
-
2. 完整读取
|
|
22
|
-
[../dxc-content-workflow/references/stage-contract.md](../dxc-content-workflow/references/stage-contract.md)
|
|
23
|
-
和 [references/visual-methods.md](references/visual-methods.md)。
|
|
24
|
-
3. 按实际输入写 `running` checkpoint:
|
|
25
|
-
|
|
26
|
-
```text
|
|
27
|
-
dxc project checkpoint visual-plan --status running \
|
|
28
|
-
--summary "正在根据正文、标题和大纲锚点生产实际视觉素材" \
|
|
29
|
-
--execution-location agent-hosted --data-transit agent-provider --json
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
CLI 自动绑定正文和标题;读取大纲时只需加 `--inputs outline`。
|
|
33
|
-
|
|
34
|
-
## 先选择素材生产路线
|
|
35
|
-
|
|
36
|
-
- 用户明确提供了适合的本地素材时,先评估它是否符合当前文章、封面构图和版权边界;选中
|
|
37
|
-
后复制到项目 `assets/visuals/`。不得扫描项目外目录。
|
|
38
|
-
- 没有合适素材而宿主具备图片生成能力时,必须实际调用图片生成能力,不得只输出提示词
|
|
39
|
-
或配图建议。第一次调用前说明生成发生位置、视觉提示会发往哪里以及是否消耗额度;
|
|
40
|
-
`review-every-stage` 必须先把“张数、类型、数据去向、额度、最多尝试次数”写入下述生成计划,
|
|
41
|
-
以 `--authorization-purpose image-generation` 写为 `awaiting-user` 并等待确认。此时不要求封面或
|
|
42
|
-
正文图片已经存在。用户确认后以相同 purpose 写 `running --confirm`;检查点会记录授权并回到
|
|
43
|
-
同一个 `visual-plan` 阶段,不能把生成授权误记为阶段完成。
|
|
44
|
-
任何策略下,只要本次会产生未获授权的外部额度消耗或超出用户已确认的数量/额度,也必须
|
|
45
|
-
暂停。只有 `auto-until-delivery` 且画像的 `user.visualGenerationAuthorization` 为
|
|
46
|
-
`auto-within-limit`、本次图片数不超过 `maxImagesPerRun` 时,才可直接生成;
|
|
47
|
-
不把正文全文、本地绝对路径、Cookie 或任何凭据放进提示。
|
|
48
|
-
- 两条路线可以混用:例如本地产品截图作为正文证据,Agent 生成封面和概念图。来源不同
|
|
49
|
-
不改变后续的文件、哈希、预览和确认约束。
|
|
50
|
-
- 宿主没有图片生成能力且没有合适本地封面时,把检查点写成 `awaiting-user`,明确提供
|
|
51
|
-
“启用图片生成能力”或“选择本地封面”两种可执行路径。不得生成纯色占位图,不得把
|
|
52
|
-
缺封面的阶段标为完成。
|
|
53
|
-
|
|
54
|
-
生成前授权的 `artifacts/06-visual-plan.md` 使用一等计划契约:
|
|
55
|
-
|
|
56
|
-
```yaml
|
|
57
|
-
---
|
|
58
|
-
planned: true
|
|
59
|
-
assetsDirectory: assets/visuals
|
|
60
|
-
inlineImagesSupported: true
|
|
61
|
-
generation:
|
|
62
|
-
executionLocation: agent-hosted
|
|
63
|
-
dataTransit: agent-provider
|
|
64
|
-
chargesQuota: true
|
|
65
|
-
maxAttempts: 1
|
|
66
|
-
retryPolicy: never
|
|
67
|
-
plannedAssets:
|
|
68
|
-
- role: cover
|
|
69
|
-
purpose: 文章内容封面
|
|
70
|
-
source: agent-generated
|
|
71
|
-
- role: inline
|
|
72
|
-
purpose: 解释核心关系
|
|
73
|
-
placementAnchor: after-heading:第二节
|
|
74
|
-
source: agent-generated
|
|
75
|
-
---
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
先写 `awaiting-user --authorization-purpose image-generation`;用户确认后写
|
|
79
|
-
`running --confirm --authorization-purpose image-generation`。计划中的张数、用途、执行位置、
|
|
80
|
-
数据去向、是否消耗额度、最多尝试次数或重试策略改变后,旧授权自动失效,必须重新展示并授权。
|
|
81
|
-
常规单次生成使用 `maxAttempts: 1`、`retryPolicy: never`。只有宿主能返回结构化重试安全证据时,
|
|
82
|
-
才可在授权计划中声明 `maxAttempts: 2`、
|
|
83
|
-
`retryPolicy: verified-no-asset-no-charge-once`;第二次调用只允许紧接第一次、发生在同一活跃任务,
|
|
84
|
-
且第一次明确返回 `retrySafe=true`、`noAsset=true`、`noCharge=true`。这不是跨任务尝试账本;任务
|
|
85
|
-
中断、证据缺字段、结果未知、可能已产图或可能计费时,旧授权不能支持自动重试,必须写新计划
|
|
86
|
-
并重新取得授权。
|
|
87
|
-
|
|
88
|
-
## 生产要求
|
|
89
|
-
|
|
90
|
-
- 先确定封面要传达的单一概念、情绪、构图和禁项,再生成或选择一张内容相关的横版封面;
|
|
91
|
-
建议比例 `2.35:1`,不把它冒充已重新核验的微信强制限制。最终文件固定保存为
|
|
92
|
-
`assets/visuals/cover.png` 或 `cover.jpg`。
|
|
93
|
-
- 只有内容信号明确时才增加正文配图:框架用思维导图,概念关系用概念图,步骤用流程图,
|
|
94
|
-
精确数据用数据图,核心句用金句图,叙事段用场景插画。
|
|
95
|
-
- 一旦视觉决策写明要使用某张正文图,就必须在本阶段实际生成或选择该文件。生成失败时
|
|
96
|
-
修正方案或暂停,不能让“计划 5 张、实际 0 张”进入审校。
|
|
97
|
-
- 图片生成返回未知结果、可能已计费或未明确 `noAsset/noCharge` 时,停止并请求用户决定是否
|
|
98
|
-
重试;不能盲目再次消耗额度。只有当前授权计划明确为 `maxAttempts: 2` 和上述安全策略,且
|
|
99
|
-
宿主结构化证明 `retrySafe=true`、`noAsset=true`、`noCharge=true`,才允许同一任务内自动再
|
|
100
|
-
尝试一次;第二次仍失败或任务边界已变化时必须停止并重新授权。
|
|
101
|
-
- 每张图必须绑定具体章节、目的、素材来源、实际文件、SHA-256 和生成方式。正文图的
|
|
102
|
-
`placementAnchor` 必须为 `after-heading:<正文二级标题全文>`,并且在当前正文中唯一;交付
|
|
103
|
-
CLI 只会按该锚点插入视觉计划声明的图片,找不到或重复匹配即阻断预览。
|
|
104
|
-
- 从正文中挑选准备做成金句图的句子时,在视觉计划正文的“金句交接”中逐字记录原句、
|
|
105
|
-
所在章节、承担的读者价值(认知压缩/情绪共鸣/行动推动/价值宣言)和对应图片文件;
|
|
106
|
-
不改写原句。它是正文写作与视觉生产之间的可追溯交接,不进入微信公众号正文。
|
|
107
|
-
- `assets/visuals/` 只保存本次明确采用的封面和正文图;候选图、失败图和被否决版本应留在
|
|
108
|
-
该目录之外,因为交付阶段会自动采集此目录中的合规正文图。
|
|
109
|
-
- 正文图片必须是 PNG/JPEG 且单张小于 1 MiB,最多 20 张;先生成或采集到视觉素材目录,
|
|
110
|
-
再由 CLI 的图片优化步骤产出可交付版本并同步真实哈希。透明图片必须保留透明通道;无法在
|
|
111
|
-
不破坏透明语义的前提下达标时阻断,不能静默铺底。任何优化都会使旧视觉 checkpoint 失效,
|
|
112
|
-
必须按新文件和新哈希重新 checkpoint、预览。
|
|
113
|
-
- 不下载字体、不执行安装脚本,不把“建议图”计入实际素材数量。
|
|
114
|
-
|
|
115
|
-
## 输出
|
|
116
|
-
|
|
117
|
-
写入 `artifacts/06-visual-plan.md`:
|
|
118
|
-
|
|
119
|
-
```markdown
|
|
120
|
-
---
|
|
121
|
-
coverAsset: assets/visuals/cover.png
|
|
122
|
-
coverSource: agent-generated
|
|
123
|
-
inlineAssets:
|
|
124
|
-
- path: assets/visuals/framework.png
|
|
125
|
-
placement: 第二节后
|
|
126
|
-
placementAnchor: after-heading:第二节
|
|
127
|
-
purpose: 解释三个概念之间的关系
|
|
128
|
-
source: agent-generated
|
|
129
|
-
---
|
|
130
|
-
|
|
131
|
-
# 视觉计划
|
|
132
|
-
|
|
133
|
-
## 封面
|
|
134
|
-
|
|
135
|
-
- 核心概念:
|
|
136
|
-
- 构图与情绪:
|
|
137
|
-
- 建议比例:2.35:1
|
|
138
|
-
- 是否含字:
|
|
139
|
-
- 禁项:
|
|
140
|
-
- 实际文件:assets/visuals/cover.png
|
|
141
|
-
- 来源:Agent 生成,或用户明确选择的本地素材
|
|
142
|
-
- SHA-256:
|
|
143
|
-
- 生成工具或原素材说明:
|
|
144
|
-
|
|
145
|
-
## 正文配图建议
|
|
146
|
-
|
|
147
|
-
| 文件 | 类型 | 位置 | 精确锚点 | 目的 | 来源 | SHA-256 | 本次草稿 |
|
|
148
|
-
| ---------------------------- | ------ | -------- | ---------------------- | -------- | ---------- | ------- | -------- |
|
|
149
|
-
| assets/visuals/framework.png | 概念图 | 第二节后 | `after-heading:第二节` | 解释关系 | Agent 生成 | ... | 进入 |
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
CLI 从项目清单补 `assetsDirectory` 和 `inlineImagesSupported`,并从真实 PNG/JPEG 自动计算
|
|
153
|
-
`coverSha256` 与每项 `sha256`;Agent 不读取或复制哈希。
|
|
154
|
-
`source` 表示素材血缘而非绘制类型:本次由 Agent 绘制并导出的 SVG/图表仍写
|
|
155
|
-
`agent-generated`,用户给出的本地素材写 `local-material`;真正交付的文件仍必须先导出为
|
|
156
|
-
PNG/JPEG。`planned` 只用于上面的生成前授权契约,已落盘的最终视觉产物不得保留它。
|
|
157
|
-
|
|
158
|
-
## 先优化交付图片
|
|
159
|
-
|
|
160
|
-
在第一次 materialized(已落盘)视觉 checkpoint 之前,先运行:
|
|
161
|
-
|
|
162
|
-
```text
|
|
163
|
-
dxc wechat draft optimize-images \
|
|
164
|
-
--directory <项目目录> \
|
|
165
|
-
--visual-plan <visual-plan 产物路径> \
|
|
166
|
-
--json
|
|
167
|
-
```
|
|
168
|
-
|
|
169
|
-
CLI 会复算全部图片哈希;超限时只在视觉素材目录下生成带源哈希的 `optimized/` 派生图,
|
|
170
|
-
原图不覆盖,并把视觉计划的路径与哈希一起原子更新。透明 PNG 只能输出仍带透明通道的 PNG;
|
|
171
|
-
无法安全达标时停止。只要返回 `mutations` 非空,就必须先重新读取更新后的视觉计划和真实路径,
|
|
172
|
-
再执行下面的 checkpoint 和本地带图预览;不得继续引用旧路径或旧哈希。
|
|
173
|
-
|
|
174
|
-
## 更新右侧带图预览
|
|
175
|
-
|
|
176
|
-
全部封面和正文图落盘、视觉计划通过机械校验并写入 `completed` checkpoint 后运行:
|
|
177
|
-
|
|
178
|
-
```text
|
|
179
|
-
dxc project preview --local \
|
|
180
|
-
--directory <project-directory> \
|
|
181
|
-
--json
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
CLI 自动从有效 checkpoint 读取正文、最终标题、视觉计划声明的真实素材目录和项目私有输出路径。
|
|
185
|
-
该命令不登录、不上传、不创建云端快照,也不修改 `04-article.md`;它会重新生成自包含 HTML,并发出
|
|
186
|
-
`kind=content-local-preview`、`action=open-file`、`replaceExisting=true` 的
|
|
187
|
-
`DXC_BROWSER_EVENT`。当前宿主支持右侧文件或浏览器预览时,必须立即打开返回的绝对路径并
|
|
188
|
-
替换此前的 `04-article.md` 预览;不得只在对话中说“已生成”。正文、标题、视觉计划或任一图片
|
|
189
|
-
变化后,先按 `recoveryPlan` 重新核验相关阶段,再运行本命令并用新的 `contentHash` 刷新右侧预览。
|
|
190
|
-
|
|
191
|
-
本地带图预览只用于检查图片、锚点和阅读节奏,不是最终微信模板确认。后续交付仍须创建、
|
|
192
|
-
查看并确认云端不可变预览。若宿主无法消费右侧预览事件,保留本地预览文件,明确告诉用户
|
|
193
|
-
自动替换未发生,并提供该文件作为可点击预览;不能把“文件已写入”冒充“右侧已刷新”。
|
|
194
|
-
|
|
195
|
-
在 frontmatter(前置元数据)后的正文追加:
|
|
196
|
-
|
|
197
|
-
```markdown
|
|
198
|
-
## 金句交接
|
|
199
|
-
|
|
200
|
-
| 原句 | 章节 | 读者价值 | 图片文件 |
|
|
201
|
-
| -------------------- | ------ | -------- | ------------------------------ |
|
|
202
|
-
| 不要用忙碌代替推进。 | 第二节 | 认知压缩 | assets/visuals/golden-line.png |
|
|
203
|
-
```
|
|
204
|
-
|
|
205
|
-
只有封面和所有标为“进入”的图片实际存在、非空、类型为 PNG/JPEG、体积合规,
|
|
206
|
-
`coverSha256`、`inlineAssets` 清单哈希正确,并且上述本地带图预览已按当前内容哈希生成时,
|
|
207
|
-
才写 `completed` 并返回总控进入审校。
|
|
208
|
-
CLI 在接受检查点前会机械校验这些文件;交付 CLI 再从用户明确指定的
|
|
209
|
-
`assets/visuals/` 采集正文图片,并把 `cover.*` 解析为封面。CLI 不生成视觉内容。
|
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
# 视觉计划方法
|
|
2
|
-
|
|
3
|
-
## 专家方法来源
|
|
4
|
-
|
|
5
|
-
- 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-e-visual-designer/SKILL.md`
|
|
6
|
-
的第 3、5–9 节;发布包不含原文,执行时以本胶囊为准。
|
|
7
|
-
- 本胶囊承接配图类型、选型、封面、品牌一致性与生产流程;DxC 额外要求素材实际落盘、
|
|
8
|
-
哈希可核验,并把上传推迟到云端预览阶段。
|
|
9
|
-
|
|
10
|
-
## 内容信号
|
|
11
|
-
|
|
12
|
-
| 内容信号 | 建议视觉 |
|
|
13
|
-
| ---------------------------------- | -------- |
|
|
14
|
-
| 三层以上结构、框架、模型、体系 | 思维导图 |
|
|
15
|
-
| 两个以上概念及对比、因果、归属关系 | 概念图 |
|
|
16
|
-
| 步骤、顺序、时间线 | 流程图 |
|
|
17
|
-
| 有可靠来源的数字、比例、趋势 | 数据图 |
|
|
18
|
-
| 可独立成立的核心观点 | 金句图 |
|
|
19
|
-
| 人物、冲突、故事或比喻 | 场景插画 |
|
|
20
|
-
|
|
21
|
-
宁少勿滥。每张图都要回答“它让读者更快理解什么,或更准确感受什么”。
|
|
22
|
-
|
|
23
|
-
## 互补的生产来源
|
|
24
|
-
|
|
25
|
-
- 本地素材适合产品截图、用户拥有版权的照片和已有品牌资产;它们必须由用户明确指定,
|
|
26
|
-
不得通过目录扫描“发现”。
|
|
27
|
-
- Agent 图片生成适合内容封面、场景、氛围和概念插画。提示应包含主体、风格、构图、
|
|
28
|
-
色板和禁项,并要求无水印、无无关文字。
|
|
29
|
-
- 含精确文字和结构的图,优先用宿主的图表或可视化能力生成,再导出 PNG,避免生成模型
|
|
30
|
-
写错文字。
|
|
31
|
-
- 同一篇文章可以同时使用两种来源;交付阶段只关心经过验证的本地文件和哈希。
|
|
32
|
-
|
|
33
|
-
图片生成需要宿主能力和用户对数据去向的同意;本地素材采集不需要云端。任何额度消耗
|
|
34
|
-
必须在执行前说明,字体安装和远程 Shell 脚本仍然禁止。
|
|
35
|
-
|
|
36
|
-
## 封面与品牌一致性
|
|
37
|
-
|
|
38
|
-
- 封面先确定一个最值得被看见的概念,再确定主体、构图、情绪、色板和禁项;不要把正文
|
|
39
|
-
所有信息压成一张图,也不要使用与文章无关的通用科技感占位图。
|
|
40
|
-
- 从已保存的博主画像读取人设、读者、标题偏好、视觉禁项和已有品牌资产;未配置时保持
|
|
41
|
-
简洁中性,不猜测品牌色、Logo 或人物形象。
|
|
42
|
-
- 正文图只在能解释结构、关系、步骤、数据或情绪时出现。每张图都标明“读者看完能更快
|
|
43
|
-
理解什么”,否则删去。
|
|
44
|
-
- 文本、数据和结构图优先由可精确排版的能力生成;生成模型适合场景与概念氛围。不得把
|
|
45
|
-
生成图中的乱码、伪数据或水印当成可交付素材。
|
|
46
|
-
|
|
47
|
-
## 当前 MVP
|
|
48
|
-
|
|
49
|
-
- 视觉生产阶段必须落盘一张内容相关封面;缺封面时暂停并给出生成或选择素材的办法;
|
|
50
|
-
- 正文内联图片进入通用草稿闭环,单张小于 1 MiB、最多 20 张;
|
|
51
|
-
- CLI 的 `--cover auto` 仅表示从文章声明或显式素材目录解析已经生产的 `cover.*`,
|
|
52
|
-
不会生成占位图;
|
|
53
|
-
- 审校必须检查计划与实际文件一致,不能把提示词或建议图冒充已生成资产。
|
|
@@ -1,226 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: dxc-wechat-publisher
|
|
3
|
-
description: 把已确认的 Markdown 文章、视觉阶段已生产的内容封面及正文图片交付到微信公众号草稿箱。用户要求预览、绑定或选择公众号、创建微信草稿,或 dxc-content-workflow 推进到 delivery 检查点时使用;创建前默认在系统浏览器展示云端不可变预览,只有宿主能力已验证时才使用右侧浏览器,并取得精确确认。
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# DxC 微信草稿交付
|
|
7
|
-
|
|
8
|
-
## 对用户的呈现
|
|
9
|
-
|
|
10
|
-
用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径;只说明当前结果、需要用户做的选择,以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口:Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`,macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`,同一任务后续必须保持已选入口;不得让用户打开终端、复制命令或处理环境变量。
|
|
11
|
-
|
|
12
|
-
本 Skill 只负责最后的 `delivery` 步骤:选择公众号、云端权威渲染、预览确认、创建草稿
|
|
13
|
-
和回读核验。它不生成正文,不正式发布,不群发。
|
|
14
|
-
|
|
15
|
-
## 就绪检查
|
|
16
|
-
|
|
17
|
-
1. 运行 `dxc version --json`,要求 CLI `0.1.x` 且协议兼容。
|
|
18
|
-
2. 若设备尚未登录或没有公众号,按以下顺序打开扫码页:已验证能实时接管事件的宿主使用
|
|
19
|
-
`dxc setup --server <https-url> --no-open` 并在右侧打开;右侧打开失败或能力未经验证时,
|
|
20
|
-
立即改用不带 `--no-open` 的 `dxc setup --server <https-url>`,让 CLI 调用 Windows 或 macOS
|
|
21
|
-
的系统默认浏览器;系统浏览器也失败时,把 CLI 返回的短时 URL 呈现为“继续扫码”的可点击
|
|
22
|
-
链接。前两级不向用户展示 URL,第三级不展示任何命令、参数或技术解释。该流程最多出现两次
|
|
23
|
-
不同语义的扫码:
|
|
24
|
-
- 个人微信登录或明确注册 DxC 用户;
|
|
25
|
-
- 公众号管理员授权第三方平台的草稿能力。
|
|
26
|
-
页面打开后保持 CLI 轮询继续运行;链接过期时自动重新执行当前扫码步骤并打开新链接,
|
|
27
|
-
不要求用户重新输入命令。
|
|
28
|
-
3. 运行 `dxc wechat accounts`。没有可用账号时停止;多个账号时向用户展示名称和
|
|
29
|
-
`accountId`,要求明确选择,不能使用“上一次账号”。
|
|
30
|
-
4. 运行 `dxc project status --directory <project> --json`,读取实际产物路径。要求正文
|
|
31
|
-
就绪、标题已确认,且视觉阶段已经在 `assets/visuals` 生产或选择内容相关的
|
|
32
|
-
`cover.png`/`cover.jpg`。缺封面时返回视觉阶段处理;不得生成纯色占位图。
|
|
33
|
-
5. 把 `delivery` 检查点写为 `running`:
|
|
34
|
-
|
|
35
|
-
```bash
|
|
36
|
-
dxc project checkpoint delivery \
|
|
37
|
-
--status running \
|
|
38
|
-
--summary "正在为已确认文章生成微信公众号预览" \
|
|
39
|
-
--execution-location local-device \
|
|
40
|
-
--data-transit dxc-cloud \
|
|
41
|
-
--json
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
CLI 自动绑定正文、标题,以及已经就绪的视觉计划和审校报告;不要手抄发布副本、路径或
|
|
45
|
-
哈希,也不要记录没有读取的占位产物。
|
|
46
|
-
|
|
47
|
-
## 生成不可变云端预览
|
|
48
|
-
|
|
49
|
-
运行:
|
|
50
|
-
|
|
51
|
-
```bash
|
|
52
|
-
dxc wechat draft preview \
|
|
53
|
-
--article <article.md> \
|
|
54
|
-
--assets-directory <project>/assets/visuals \
|
|
55
|
-
--visual-plan <visual-plan.md> \
|
|
56
|
-
--cover <cover.png-or-jpeg-or-auto> \
|
|
57
|
-
--account <account-id> \
|
|
58
|
-
--title "<已确认标题>" \
|
|
59
|
-
--browser system \
|
|
60
|
-
--json
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
若 Agent 已根据文章类型给出建议,可在文章 frontmatter 写入目录中的
|
|
64
|
-
`dxc_wechat_template_hint`;它只决定首次预览,用户始终在预览页选择最终模板。CLI 会显式上传
|
|
65
|
-
Markdown、封面和正文图片,由云端使用建议或默认固定模板权威渲染,并返回
|
|
66
|
-
`snapshot.id`、`snapshot.snapshotHash`、`preview.url`、目标账号和预检结果。
|
|
67
|
-
返回还包含 `preview.createdAt`、`preview.expiresAt`、`preview.expiresInSeconds` 和
|
|
68
|
-
`snapshot.inlineAssets`;正文图片哈希属于不可变快照。`auto` 只从文章声明或显式素材
|
|
69
|
-
目录解析已经存在的 `cover.*`,不会生成占位封面。
|
|
70
|
-
|
|
71
|
-
CLI 只在上传字节中移除本地工作流专用的 `dxc`、`goldenLinesPath` 和
|
|
72
|
-
`goldenLinesSha256` frontmatter,原始正文产物保持不变。Agent 不得另外创建
|
|
73
|
-
`04-article.publish.md` 之类的发布副本来规避云端校验。
|
|
74
|
-
|
|
75
|
-
CLI 默认用系统浏览器实际打开页面。只有当前宿主已证明会实时消费
|
|
76
|
-
`kind=wechat-draft-preview` 的 `DXC_BROWSER_EVENT`、导航最终 URL 并跟随模板切换跳转时,才显式
|
|
77
|
-
改用 `--browser agent`。仅收到事件或显示空面板不算用户已查看;此时必须对同一快照运行
|
|
78
|
-
`preview-refresh ... --browser system --json`,由 CLI 打开系统默认浏览器。系统浏览器也无法打开时,
|
|
79
|
-
把 CLI 返回的短时 URL 仅渲染为“查看预览”的可点击链接;不展示原始 URL、命令或技术说明,
|
|
80
|
-
也不把链接写进日志或项目产物。
|
|
81
|
-
|
|
82
|
-
正文图片是交付必需品,不是可静默降级项。视觉计划或 Markdown 声明了正文图片时,必须核对
|
|
83
|
-
`snapshot.inlineAssets` 数量和逻辑路径全部一致;任一图片缺失、无法读取、上传失败或未进入
|
|
84
|
-
快照时停止并修复,不得只保留封面继续创建草稿。项目产物统一保存 `/` 分隔的便携相对路径;
|
|
85
|
-
CLI 同时接受 Windows `\` 分隔符和 URL 编码文件名,并在上传前归一化为同一逻辑路径。
|
|
86
|
-
|
|
87
|
-
页面首次实际打开,以及用户每次切换模板并等待新预览页面实际打开后,都运行:
|
|
88
|
-
|
|
89
|
-
```text
|
|
90
|
-
dxc wechat draft preview-status \
|
|
91
|
-
--snapshot <rootSnapshotId> \
|
|
92
|
-
--snapshot-hash <rootSnapshotHash> \
|
|
93
|
-
--json
|
|
94
|
-
```
|
|
95
|
-
|
|
96
|
-
只有最后一次返回的 `viewed=true`,并且该回执的 `templateId`、`selectedSnapshotId`、
|
|
97
|
-
`selectedSnapshotHash` 和 `selectionRevision` 已写入 delivery,才允许展示最终模板并询问确认。
|
|
98
|
-
这份服务端回执是模板真值;不能根据下拉框曾经显示的值、Agent 记忆或第一次选择推断最终模板。
|
|
99
|
-
用户连续选择 A、B、C 时,以最后一次成功提交、生成并实际打开的 C 修订为准;如果 C 提交失败,
|
|
100
|
-
`preview-status` 仍会明确显示旧修订,必须重新切换或打开,不能静默拿 A/B 创建草稿。
|
|
101
|
-
|
|
102
|
-
把以下内容写入项目清单指定的 `delivery` 产物;默认是
|
|
103
|
-
`artifacts/08-delivery.md`:
|
|
104
|
-
|
|
105
|
-
```markdown
|
|
106
|
-
---
|
|
107
|
-
state: previewed
|
|
108
|
-
accountId: <uuid>
|
|
109
|
-
rootSnapshotId: <最初渲染快照 uuid>
|
|
110
|
-
rootSnapshotHash: <最初渲染快照 sha256>
|
|
111
|
-
selectedSnapshotId: <当前最终选中快照 uuid,首次预览时与 root 相同>
|
|
112
|
-
selectedSnapshotHash: <当前最终选中快照 sha256,首次预览时与 root 相同>
|
|
113
|
-
templateId: <当前最终模板 ID>
|
|
114
|
-
previewSelectionRevision: <preview-status 返回的非负选择修订号>
|
|
115
|
-
previewExpiresAt: <ISO 8601>
|
|
116
|
-
intentId: null
|
|
117
|
-
---
|
|
118
|
-
|
|
119
|
-
# 微信草稿交付
|
|
120
|
-
|
|
121
|
-
- 公众号:<名称和 AppID 脱敏标识>
|
|
122
|
-
- 标题:<已确认标题>
|
|
123
|
-
- 模板:<用户在预览页最终选择的 templateId>
|
|
124
|
-
- 预览:已在右侧内置浏览器或系统默认浏览器展示
|
|
125
|
-
- 预检:<通过,或逐项列出问题>
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
使用与进入步骤相同的输入和执行参数把检查点写为 `awaiting-user`,并增加:
|
|
129
|
-
|
|
130
|
-
```text
|
|
131
|
-
--summary "不可变预览已经生成并绑定目标公众号"
|
|
132
|
-
--waiting-for "是否确认把这个快照创建到这个公众号的草稿箱?"
|
|
133
|
-
--confirmation-snapshot <selectedSnapshotHash>
|
|
134
|
-
```
|
|
135
|
-
|
|
136
|
-
只向用户展示公众号名称、标题、封面、正文图片数和预检结果,并提醒查看已经打开的预览。
|
|
137
|
-
不要展示 `accountId`、`snapshotId`、`snapshotHash`、幂等键、短时 URL、剩余秒数或内部命令。
|
|
138
|
-
最终预览页面成功加载后,不等待用户再次追问,立即在 WorkBuddy 对话中呈现一次“确认创建草稿”
|
|
139
|
-
和“返回修改”两个动作;宿主支持可点击选项时使用可点击选项,否则只询问一次:“确认创建草稿,
|
|
140
|
-
还是返回修改?”预览页只显示“返回 WorkBuddy 确认”的只读提示,不得在短时预览链接中加入
|
|
141
|
-
创建草稿的按钮或其他写操作。用户最初提出“放进草稿箱”是任务意图,不能替代看到最终预览
|
|
142
|
-
后的这一次确认;不得再增加第二次同义确认。
|
|
143
|
-
|
|
144
|
-
模板切换会使切换前的确认失效;浏览器回退到旧预览也不能恢复旧确认。若创建命令返回
|
|
145
|
-
`PUBLISHING_PREVIEW_REQUIRED`,说明最终预览尚未成功打开,应重新打开当前预览后再询问;若
|
|
146
|
-
返回 `PUBLISHING_APPROVAL_STALE`,说明确认后预览选择又发生变化,应展示当前最终预览并重新
|
|
147
|
-
取得一次确认。不得把这两类错误改成自动确认或直接创建草稿。
|
|
148
|
-
恢复时先比较当前时间与 `previewExpiresAt`:链接已过期则运行:
|
|
149
|
-
|
|
150
|
-
```bash
|
|
151
|
-
dxc wechat draft preview-refresh \
|
|
152
|
-
--snapshot <rootSnapshotId> \
|
|
153
|
-
--snapshot-hash <rootSnapshotHash> \
|
|
154
|
-
--browser system \
|
|
155
|
-
--json
|
|
156
|
-
```
|
|
157
|
-
|
|
158
|
-
这只为原始快照(以及已记录的最终模板选择)重建短时链接,不得重跑正文、素材或草稿意图。
|
|
159
|
-
把新的 `previewExpiresAt` 写回交付产物;刷新和创建请求仍以交付产物中的 root 快照发起,
|
|
160
|
-
服务端会解析为用户最后选择的不可变 selected 快照。默认在系统浏览器打开;仅已验证宿主才
|
|
161
|
-
可改用 `--browser agent`。仅刷新同一个最终预览不会改变预览选择版本;若模板、
|
|
162
|
-
正文或素材发生变化,仍必须重新打开最终预览并取得明确确认。
|
|
163
|
-
|
|
164
|
-
若 `preview-status` 或其他读取命令返回 `DXC_API_REQUEST_FAILED`,记录 CLI 返回的 HTTP 状态码,
|
|
165
|
-
并先核对 CLI 与服务端是否部署同一发布版本。该错误没有证明远端未处理任何写操作:不得跳过
|
|
166
|
-
预览门、不得改用新幂等键、不得把它归类为可安全重试;仅可读取已有 intent 状态,必要时进入
|
|
167
|
-
“需要人工核对”。
|
|
168
|
-
|
|
169
|
-
## 创建与核验
|
|
170
|
-
|
|
171
|
-
只有用户在看到上述信息后明确确认,才运行:
|
|
172
|
-
|
|
173
|
-
```bash
|
|
174
|
-
dxc wechat draft create \
|
|
175
|
-
--account <account-id> \
|
|
176
|
-
--snapshot <rootSnapshotId> \
|
|
177
|
-
--snapshot-hash <rootSnapshotHash> \
|
|
178
|
-
--delivery artifacts/08-delivery.md \
|
|
179
|
-
--confirm \
|
|
180
|
-
--json
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
CLI 会根据项目与 root 快照生成并落盘幂等键;创建时从 `--delivery` 读取并复用该值,不需要
|
|
184
|
-
Agent 手抄。若同时显式传键,必须与 delivery 完全一致;公众号或 root 快照不一致也会在任何
|
|
185
|
-
服务端请求前停止。批准响应必须与 delivery 中的 `selectedSnapshotId`、
|
|
186
|
-
`selectedSnapshotHash`、`templateId` 和 `previewSelectionRevision` 全部一致,CLI 才会继续
|
|
187
|
-
创建意图并写入 `intent.id` 与 `processing` 状态。任一字段不一致说明用户确认后模板又变化,
|
|
188
|
-
CLI 必须在创建意图前停止。
|
|
189
|
-
再用
|
|
190
|
-
`dxc wechat draft status <intent-id> --json` 查询进度:
|
|
191
|
-
|
|
192
|
-
- `progress.terminal` 为 `false` 时:按 `progress.pollAfterSeconds` 静默、安全查询;只有等待
|
|
193
|
-
明显超出服务端建议或用户主动询问时才展示 `progress.label`、`progress.message` 和
|
|
194
|
-
`progress.nextAction`。不要展示内部处理阶段或 Worker 信息,也不要再次创建。
|
|
195
|
-
- `progress.terminal` 为 `true`,且存在微信 `mediaId`,标题、作者、摘要和正文的
|
|
196
|
-
`verification` 全部匹配时:把 `state`、`intentId`、`mediaId` 和核验结果写回交付
|
|
197
|
-
产物,然后写下列检查点;CLI 自动更新 `dxc.artifactStatus`:
|
|
198
|
-
`completed --confirm --confirmed-by <稳定身份标识>
|
|
199
|
-
--confirmation-snapshot <selectedSnapshotHash>
|
|
200
|
-
--summary "微信草稿创建并回读核验成功"` 检查点。
|
|
201
|
-
- `progress.label` 为“需要人工核对”时:记录诊断并停止,禁止盲目重试微信副作用,
|
|
202
|
-
等待人工核对。
|
|
203
|
-
|
|
204
|
-
微信返回 `mediaId` 只证明草稿可能已经创建;若回读 `verification.contentMatched=false`,必须保留
|
|
205
|
-
`CREATED_UNVERIFIED`/“需要人工核对”。标题、作者和摘要匹配不能替代正文核验,也不能完成
|
|
206
|
-
delivery checkpoint;应先保存比对哈希和诊断,再由人工确认或后续改进微信 HTML 规范化规则。
|
|
207
|
-
|
|
208
|
-
- `progress.label` 为“未完成”时:记录稳定错误码,写 `failed --error-code <code>`;
|
|
209
|
-
只有服务端状态明确为 `FAILED`(证明在外部副作用发生前失败)时,才允许用户明确确认后运行:
|
|
210
|
-
|
|
211
|
-
```text
|
|
212
|
-
dxc wechat draft retry \
|
|
213
|
-
--intent <当前 FAILED intent-id> \
|
|
214
|
-
--delivery artifacts/08-delivery.md \
|
|
215
|
-
--confirm \
|
|
216
|
-
--json
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
CLI 会重新从服务端读取原状态,绑定 `previousIntentId`,生成新的幂等键,并把重试次数与谱系
|
|
220
|
-
写回 delivery。只有服务端还能证明失败发生在任何非幂等图片上传或草稿创建之前时才接受;
|
|
221
|
-
图片上传或草稿创建已经开始后的 `FAILED`、`CREATED_UNVERIFIED`、
|
|
222
|
-
`ASSET_UPLOAD_UNVERIFIED`、仍在处理、已成功或“需要人工核对”的意图一律拒绝重试;不得改用
|
|
223
|
-
新的手写幂等键绕过。新的重试意图如果再次明确 `FAILED`,仍须服务端重新证明安全,并由用户
|
|
224
|
-
再次确认当前失败意图作为下一条链的来源。
|
|
225
|
-
|
|
226
|
-
正文、标题、模板、渲染器版本、封面或正文图片变化后,原确认失效;必须重新生成预览并确认。
|