208 lines
14 KiB
Markdown
208 lines
14 KiB
Markdown
---
|
|
name: standard
|
|
description: 撰写中国标准文件(国家标准 GB/GB·T、行业标准 JC·T 等、团体标准 T/ 含 T/CSTM)及配套编制说明,按 GB/T 1.1—2020 起草规则。当用户要写标准、起草标准、编标准、做试验方法标准/产品标准、写标准草案/征求意见稿/送审稿/报批稿、写标准编制说明时使用。
|
|
---
|
|
|
|
# Standard (标准起草)
|
|
|
|
把材料/方法/产品信息变成符合 **GB/T 1.1—2020** 的标准草稿 .docx + 配套编制说明。**先定层级与体裁 → 八条对齐 spec → 逐章起草 → 自检渲染** —— 不要一口气出全文。
|
|
|
|
> ⚠️ 与相邻 skill 区分:本 skill 写**标准文件本身**。要写投标技术方案走别处,要写申报书走 `proposal`,要写专利交底书走 `patent`,要审稿润色走 `review`。
|
|
|
|
## 资源
|
|
|
|
下面所有路径都相对 **`<skill_dir>`** —— `load_skill` 返回头里的 `[skill=standard, dir=<绝对路径>]`,用这个绝对路径拼脚本/资源,不要假设 cwd。
|
|
|
|
- `<skill_dir>/references/gbt_1_1_structure.md` —— 要素骨架 + 编排顺序 + 必备/可选 + 规范性/资料性 + 封面/前言固定套话 (always read)
|
|
- `<skill_dir>/references/standard_levels.md` —— 国标/行标/团标选型 + 编号规则 + CSTM 体系与立项程序 + 选型决策树
|
|
- `<skill_dir>/references/drafting_rules.md` —— 能愿动词(应/宜/可/能)+ 不可考核词过滤 + 指标量化闭环 + 术语规则 + 引用真实性 + 起草前自检清单
|
|
- `<skill_dir>/templates/spec.md` —— task 级"宪法"模板(层级/体裁/名称/范围/指标矩阵/引用清单/起草信息)
|
|
- `<skill_dir>/templates/test_method.md` —— **试验方法标准**章节骨架(GB/T 20001.4,建材院+CSTM 主场)
|
|
- `<skill_dir>/templates/product_standard.md` —— **产品标准**章节骨架(分类→技术要求→试验方法→检验规则→标志包装)
|
|
- `<skill_dir>/templates/drafting_note.md` —— **编制说明**骨架(报批必交件)
|
|
- **渲染复用平台层 + proposal 图脚本**:docx 调 `rendering/render.py --profile proposal`(见下);mermaid 图仍用 `<skill_dir>/../proposal/scripts/render_diagrams.py` —— 同样的 markdown + ```mermaid``` + `%% caption:` 约定,不另写
|
|
|
|
## 触发 / 不触发
|
|
|
|
- ✅ "写个标准 / 起草标准 / 编标准 / 这个方法想做成团标 / 报 CSTM / 做成 JC 行标 / 产品标准 / 试验方法标准 / 标准征求意见稿 / 送审稿 / 报批稿 / 标准编制说明"
|
|
- ⚠️ 用户说"标准"但其实指"技术规范文档 / 作业指导书 / 企业内部规程" —— **先反问**是不是要做成对外发布的标准(GB/JC·T/团标),还是内部文件;内部文件不必套 GB/T 1.1。
|
|
- ⛔ "符合 XX 标准写一份报告 / 按标准做检测" —— 那是执行标准,不是写标准,走对应业务 skill。
|
|
|
|
## 阶段零: 摄取素材 (有 PDF/DOCX/XLSX/URL 时才走)
|
|
|
|
用户给已有相近标准 / 检测数据 / 实验报告 / 现状调研 → 用 `markitdown` CLI 转 md 落到 `<task_dir>/source/<name>.md`,后续阶段直接 read:
|
|
|
|
```bash
|
|
markitdown <path>/相近标准.pdf -o <task_dir>/source/ref_std.md
|
|
markitdown <path>/检测报告.docx -o <task_dir>/source/test_report.md
|
|
markitdown <path>/数据.xlsx -o <task_dir>/source/data.md
|
|
markitdown https://example.com/ -o <task_dir>/source/policy.md
|
|
```
|
|
|
|
## 阶段一: 定层级与体裁 + 八条对齐 (spec)
|
|
|
|
产物:**task 级 spec 文件**(标准"宪法",阶段二每章前都要重读)。文件路径按 system prompt 的《task 级「宪法」文件命名约定》:
|
|
|
|
<task_dir>/<today>-<task_short_id>-<task_name>.spec.md
|
|
|
|
**0. 先检测已有 spec**:
|
|
|
|
```
|
|
glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最大者作 current
|
|
```
|
|
|
|
- 若已有 current → 展示给用户,问「**沿用进阶段二** / **重定调**(以 today 为前缀写新版,旧版保留)」,⛔ BLOCKING 等用户决定
|
|
- 仅有其它 task 的(`*-<别的 short_id>-*.spec.md`)→ 不当 current 用,继续走下面
|
|
- 完全没有 → 直接走下面
|
|
|
|
1. **先读 `references/standard_levels.md` 定层级**:国标 GB/T · 行标 JC/T · 团标 T/(默认建议 **T/CSTM** —— 研究院牵头最快最对口,理由见 standard_levels.md §1/§4);用决策树定**体裁**(试验方法 / 产品 / 术语 / 规程)。⛔ **BLOCKING:层级 + 体裁两个维度都要用户确认**(它们决定程序、效力、章节骨架)。
|
|
2. **复制模板**:`read <skill_dir>/templates/spec.md` → `write <task_dir>/<today>-<task_short_id>-<task_name>.spec.md`
|
|
3. **按字段填**:标准名称(引导+主体+补充要素)/ 范围 / 起草信息 / **关键技术指标矩阵**(每条指标+单位+判定方向+试验方法闭环)/ 规范性引用文件(真实标准号)/ 术语清单 / 编制说明要点 / TODO
|
|
4. 给用户预览
|
|
5. ⛔ **BLOCKING:用户确认后才进阶段二**
|
|
|
|
> 指标矩阵是 spec 的心脏 —— 阶段二技术要求章直接展开它,阶段三自检读它。指标定不下来就标 `<TODO>`,不要编数值。
|
|
|
|
## 阶段二: 逐章起草
|
|
|
|
每章两段式:**先列要点 → 用户确认 → 再起草 → 用户确认**。不要直接出正文。
|
|
|
|
按 spec §2 选定的体裁,读对应骨架(`templates/test_method.md` 或 `product_standard.md`)。**每章起草前必读 `references/drafting_rules.md`** —— 能愿动词、不可考核词、量化闭环是逐条硬规则。
|
|
|
|
**A. 起草前列要点**:
|
|
1. 读 **current spec** 与对应体裁骨架,拿本章必备要素
|
|
2. 列 3-6 条要点骨架:本章覆盖的条款/指标/表格,每条标注规范性 or 资料性、对齐 spec 的哪条指标
|
|
3. ⛔ **BLOCKING:用户确认要点后才动正文**
|
|
|
|
**B. 正文起草**:
|
|
4. 从体裁骨架复制对应小节到 `<task_dir>/sections/NN_xxx.md`(NN 控目次顺序)
|
|
5. **核心技术章一段一卡** —— 技术要求 / 试验步骤 / 结果计算 / 精密度 / 检验规则:写一段 → 报字数 + 自查能愿动词与可考核性 + **预告下一段** → 等用户确认 → 写下一段
|
|
普通章节一节一卡:整节写完再报 + **预告下一节要点**
|
|
6. 报告格式(每次卡点都按这个出):
|
|
- **本段(节)**:章节名 / 规范性 or 资料性 / 涉及的指标条 / 能愿动词与可考核性自查结果
|
|
- **下一段(节)预告**:标题 + 3-5 条要点骨架;若已是本章最后一段,改预告**下一章**首段要点
|
|
- 提问:"本段可以了吗?下一段要点要改 / 加 / 删什么?"
|
|
7. ⛔ **BLOCKING:停下来等用户明确反馈**("OK"、"下一段"、"继续")后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但**指标值 / 试验条件 / 引用标准号异常**时必须主动追问。
|
|
8. 用户确认了**实质改动**(改指标值 / 调试验条件 / 换引用标准 / 增删章条)后,追加一行到 `<task_dir>/REVISIONS.md` —— 见 §修订日志。
|
|
|
|
**编制说明同步**:技术要求章每定一条关键指标,把"确定依据"同步记进 spec §9 / 编制说明草稿 —— 报批时编制说明 §4 要逐条解释指标怎么来的,别等最后补。
|
|
|
|
**例外**:用户**主动且明确**说"别问,直接全做"或"一气呵成" —— 才能一次跑完,跑完必须按阶段三自检。"太慢/太碎"之类抱怨**不算**例外指令,继续问。
|
|
|
|
## 阶段三: 自检 + 渲染
|
|
|
|
```bash
|
|
# 1. 自检 (按 drafting_rules.md §8 清单 12 条逐条核 — 无脚本,模型逐条对照 sections/*.md)
|
|
read <skill_dir>/references/drafting_rules.md # 看 §8 自检清单(要素齐全/能愿动词/可考核/指标闭环/术语/引用/单位/无 TODO 残留/无 ASCII 字符画)
|
|
# 不过的项回头 edit 章节
|
|
|
|
# 2. mermaid 图预渲染 (章节有 ```mermaid``` 块才跑)
|
|
python <skill_dir>/../proposal/scripts/render_diagrams.py <task_dir>/sections/
|
|
|
|
# 3. 渲染标准正文 .docx (调平台渲染层,复用 proposal profile;--fund-type 只影响打印文案不影响排版)
|
|
python /sandbox/rendering/render.py --profile proposal --format docx <task_dir>/sections/ --fund-type key_rd -o <task_dir>/<标准名称>.docx
|
|
|
|
# 4. 渲染编制说明 .docx (有 note_sections/ 时)
|
|
python /sandbox/rendering/render.py --profile proposal --format docx <task_dir>/note_sections/ --fund-type key_rd -o <task_dir>/<标准名称>_编制说明.docx
|
|
```
|
|
|
|
> ⚠️ 不要用 proposal 的 `quality_check.py` —— 它按申报书固定章节名(00_basic_info…)查"缺章节",对标准是误报。结构核对走 drafting_rules.md §8 人工清单(对标准更贴),与 `patent` skill 同一思路。
|
|
|
|
> 复用的 proposal 脚本是 standard 的**兄弟 skill**,用 `<skill_dir>/../proposal/scripts/...` 定位(host 与 docker 后端都落到同级 proposal 目录)。**不要**拼 repo 根的宿主绝对路径 —— docker 容器里看不到宿主路径。
|
|
>
|
|
> 产出是**结构规范的草稿**(宋体小四/1.5 倍行距/自动目次)。正式报批前把内容灌入标准发布机构官方模板(国标 TCS 2017 / CSTM 提供的 Word 模板)做版式精修 —— 本 skill 保证要素齐、顺序对、条款合规、措辞合规,版式交官方模板。见 gbt_1_1_structure.md §7。
|
|
|
|
## 工作目录
|
|
|
|
`<task_dir>` = system prompt 给的**绝对路径**。**所有产物都写到 task_dir 下**,不要写到 cwd / `skills/` / repo 根。
|
|
|
|
```
|
|
<task_dir>/
|
|
├── source/ # markitdown 转出的素材(相近标准/检测数据)
|
|
├── <today>-<task_short_id>-<task_name>.spec.md # 阶段一定调,task 级宪法;按 short_id 主锚,重定调写新日期旧版保留
|
|
├── sections/ # 标准正文逐章产物(按体裁骨架切的小节)
|
|
├── note_sections/ # 编制说明逐章产物(drafting_note.md 切的小节)
|
|
├── figures/ # mermaid/matplotlib 预渲染 PNG
|
|
├── REVISIONS.md # 修订日志:每次卡点用户确认的实质改动
|
|
├── <标准名称>.docx # 最终标准草稿(按标准名命名,不要 output.docx)
|
|
└── <标准名称>_编制说明.docx # 配套编制说明
|
|
```
|
|
|
|
## 修订日志 (REVISIONS.md)
|
|
|
|
`<task_dir>/REVISIONS.md` 是产物迭代的紧凑 changelog。**spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加)**。
|
|
|
|
### 何时记 / 何时不记
|
|
|
|
| 情形 | 记? |
|
|
|---|---|
|
|
| 用户确认改**技术指标值 / 试验条件 / 精密度限 / 判定规则** | ✅ 必记 |
|
|
| 用户确认换 / 增 / 删**引用标准 / 术语 / 章条 / 附录** | ✅ 必记 |
|
|
| 用户确认改**层级 / 体裁 / 标准名称 / 范围界定** | ✅ 必记 |
|
|
| 用户对要点骨架的主动修改(改 / 加 / 删) | ✅ 必记 |
|
|
| 自检发现能愿动词/不可考核词/指标不闭环后的统一改 | ✅ 必记(注明触发的自检条,如"自检 §8.5") |
|
|
| 章节首次起草(从 0 写出来) | ❌ 不记 |
|
|
| 错别字 / 标点 / 纯排版调整 | ❌ 不记 |
|
|
|
|
> 拿不准 → 倾向不记。
|
|
|
|
### 格式
|
|
|
|
文件首次创建时写头(只写一次):
|
|
|
|
```markdown
|
|
# 修订日志
|
|
|
|
> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
|
|
```
|
|
|
|
每次记一笔追加在头注释之后、最新一笔的顶部:
|
|
|
|
```
|
|
- `<YYYY-MM-DD HH:MM>` | <文件:章节/条> | <一句话改了什么> — <为什么>
|
|
```
|
|
|
|
### 实例
|
|
|
|
```
|
|
- `2026-06-05 16:20` | sections/05_技术要求.md 表1 | 抗折强度由"≥5.0 MPa"提到"≥6.0 MPa" — 实测15组均值6.4,P5分位6.1,留裕量
|
|
- `2026-06-05 14:05` | sections/10_精密度.md §10.2 | 再现性限 R 由 0.8 改为 1.0 MPa — 三家实验室验证数据离散,0.8 偏严
|
|
- `2026-06-05 11:30` | <today>-<short>-<name>.spec.md §1 层级 | 由 JC/T 行标改为 T/CSTM 团标 — 行标周期长,先做团标快速落地
|
|
```
|
|
|
|
### 操作
|
|
|
|
每次卡点用户确认后,用 `edit` 在头注释之后插入新一行(不要 append 到文件末尾)。文件不存在就 `write` 创建带头注释的新文件。
|
|
|
|
## 硬规则速查 (违反即被审评退回)
|
|
|
|
- **要素齐 + 顺序对**:对照 gbt_1_1_structure.md §1;必备要素(封面/前言/名称/范围)一个不少
|
|
- **规范性 vs 资料性**:资料性要素(前言/引言/参考文献/资料性附录)里**不准写"应/宜"等条款**
|
|
- **能愿动词**:应/不应=要求,宜/不宜=推荐,可/不必=允许,能/不能=能力;⛔ 不用"必须/应该/严禁/不得"
|
|
- **可考核**:删"高/好/适当/尽量/合理"等模糊词;每条要求 = 量+数值+单位+判定方向(≥/≤)+对应试验方法
|
|
- **指标闭环**:每条技术要求在标准内有方可验(要求章 ↔ 试验方法章呼应)
|
|
- **术语规则**:一术一义、替换式定义、引用标来源、不重复已有国标术语
|
|
- **引用真实**:标准号/名称/条款号一字不编,存疑用 research/web 核;固定引导语见 gbt_1_1_structure.md §5
|
|
- **量与单位**:法定计量单位(SI),量符号斜体单位正体,修约按 GB/T 8170
|
|
- **编制说明必交**:报批稿必附,§4 逐条解释关键指标确定依据
|
|
- **命名**:按标准名命名 docx,不要 output.docx / 标准.docx
|
|
|
|
## 反模式
|
|
|
|
- 未定层级/体裁就硬写正文 / 一次性出全文 / 跳过"列要点"段段卡
|
|
- 核心技术章(技术要求/试验步骤/精密度/检验规则)整章一次出 —— 必须段段卡
|
|
- **自己编指标数值 / 试验条件 / 精密度限 / 标准号** —— 不知道就 `<TODO 待用户/检测数据提供>`
|
|
- 资料性要素里写"应/宜"条款;用"必须/严禁/不得"
|
|
- 技术要求写"强度高、耐久性好"这种不可考核措辞
|
|
- 技术要求无对应试验方法(指标不闭环)
|
|
- 把"编制说明"漏掉(报批一定被要)
|
|
- 跳过 drafting_rules.md §8 自检直接交付
|
|
|
|
## 输出
|
|
|
|
完成后给用户:
|
|
- 文件路径(`<标准名称>.docx` + `<标准名称>_编制说明.docx` + sections/*.md)
|
|
- 要素清单核对表(对照 gbt_1_1_structure.md §1:哪些要素已写、哪些可选项省略及理由)
|
|
- 技术指标矩阵(指标 ↔ 试验方法闭环逐项核对)
|
|
- `<TODO>` 待补项清单(待用户/检测数据补的指标值 / 引用标准版本号 / 起草人信息)
|