14 KiB

Raw Blame History

name	description
standard	撰写中国标准文件(国家标准 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:

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 用,继续走下面
完全没有 → 直接走下面

先读 references/standard_levels.md 定层级:国标 GB/T · 行标 JC/T · 团标 T/(默认建议 T/CSTM —— 研究院牵头最快最对口,理由见 standard_levels.md §1/§4);用决策树定体裁(试验方法 / 产品 / 术语 / 规程)。⛔ BLOCKING:层级 + 体裁两个维度都要用户确认(它们决定程序、效力、章节骨架)。
复制模板:read <skill_dir>/templates/spec.md → write <task_dir>/<today>-<task_short_id>-<task_name>.spec.md
按字段填:标准名称(引导+主体+补充要素)/ 范围 / 起草信息 / 关键技术指标矩阵(每条指标+单位+判定方向+试验方法闭环)/ 规范性引用文件(真实标准号)/ 术语清单 / 编制说明要点 / TODO
给用户预览
⛔ BLOCKING:用户确认后才进阶段二

指标矩阵是 spec 的心脏 —— 阶段二技术要求章直接展开它,阶段三自检读它。指标定不下来就标 <TODO>,不要编数值。

阶段二: 逐章起草

每章两段式:先列要点 → 用户确认 → 再起草 → 用户确认。不要直接出正文。

按 spec §2 选定的体裁,读对应骨架(templates/test_method.md 或 product_standard.md)。每章起草前必读 references/drafting_rules.md —— 能愿动词、不可考核词、量化闭环是逐条硬规则。

A. 起草前列要点:

读 current spec 与对应体裁骨架,拿本章必备要素
列 3-6 条要点骨架:本章覆盖的条款/指标/表格,每条标注规范性 or 资料性、对齐 spec 的哪条指标
⛔ BLOCKING:用户确认要点后才动正文

B. 正文起草: 4. 从体裁骨架复制对应小节到 <task_dir>/sections/NN_xxx.md(NN 控目次顺序) 5. 核心技术章一段一卡 —— 技术要求 / 试验步骤 / 结果计算 / 精密度 / 检验规则:写一段 → 报字数 + 自查能愿动词与可考核性 + 预告下一段 → 等用户确认 → 写下一段普通章节一节一卡:整节写完再报 + 预告下一节要点 6. 报告格式(每次卡点都按这个出):

本段(节):章节名 / 规范性 or 资料性 / 涉及的指标条 / 能愿动词与可考核性自查结果
下一段(节)预告:标题 + 3-5 条要点骨架;若已是本章最后一段,改预告下一章首段要点
提问:"本段可以了吗?下一段要点要改 / 加 / 删什么?"

⛔ BLOCKING:停下来等用户明确反馈("OK"、"下一段"、"继续")后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但指标值 / 试验条件 / 引用标准号异常时必须主动追问。
用户确认了实质改动(改指标值 / 调试验条件 / 换引用标准 / 增删章条)后,追加一行到 <task_dir>/REVISIONS.md —— 见 §修订日志。

编制说明同步:技术要求章每定一条关键指标,把"确定依据"同步记进 spec §9 / 编制说明草稿 —— 报批时编制说明 §4 要逐条解释指标怎么来的,别等最后补。

例外:用户主动且明确说"别问,直接全做"或"一气呵成" —— 才能一次跑完,跑完必须按阶段三自检。"太慢/太碎"之类抱怨不算例外指令,继续问。

阶段三: 自检 + 渲染

# 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 写出来)	❌ 不记
错别字 / 标点 / 纯排版调整	❌ 不记

拿不准 → 倾向不记。

格式

文件首次创建时写头(只写一次):

# 修订日志

> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。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> 待补项清单(待用户/检测数据补的指标值 / 引用标准版本号 / 起草人信息)

14 KiB Raw Blame History