skills/zuoa/aj-skills/social-opinion-writer

social-opinion-writer

Installation
SKILL.md

Social Opinion Writer

面向民主党派和政协信息场景的社情民意写作技能。

目标不是写一篇泛泛的议论文,而是形成一篇更接近“可报送材料”的问题建议稿:选题聚焦,事实可靠,逻辑紧,建议可操作,且真正站在党委政府决策参考的视角写作。

先读什么

适用输入

  • 只有一个主题,例如“如何缓解县域高中教师流失”
  • 只有一些零散素材、录音整理、聊天纪要、调研笔记
  • 已有初稿,但需要补充网络资料并改写成社情民意
  • 需要围绕某个热点问题快速形成民主党派报送稿

默认设置

  • 默认篇幅:1500-2000 字;确属重要信息时可放宽到 3000
  • 默认文体:社情民意信息
  • 默认报送层级:市级及以上;优先形成面向市级、省级或国家层面的决策参考稿
  • 默认结构:现状/前言 -> 主要问题 -> 对策建议
  • 默认研究方式:自动联网补充公开信息,优先权威来源
  • 默认问题数量:3-4
  • 默认建议数量:3-4 条,且与前文问题一一对应
  • 默认验证轮次:2 轮;涉及强时效、政策敏感或数据密集主题时升到 3
  • 默认最终交付:markdown + humanized-markdown + docx
  • 默认输出目录:social-opinions/{slug}-{timestamp}/

如果用户明确说“不联网”“只基于我给的内容”,就跳过外部调研,但必须明确说明证据边界。

核心原则

  1. 信息工作本质上是决策参考型情报工作。真实性、准确性、可复核性优先于文采和铺陈。
  2. 报送对象是党政领导,不是企业客户或普通读者。问题和建议必须站在党委政府决策与政策执行的视角提出。
  3. 选题默认按“市级及以上起步”处理。区、街道、社区层面可自行处置的具体事务,原则上不上升为正式报送稿,除非能够提炼为市级以上制度性堵点。
  4. 一稿只解决一个核心问题,且报送层级必须单一,不能在同一篇稿件中混写市、省、国家多个层级的建议。
  5. 小切口写深,不写大而空的宏观宣言;前言部分只负责把问题引出来,不承担大段背景铺垫。
  6. 事实、数据、案例、政策表述必须可追溯,不能编造;凡无来源的数据,一律按不可用处理。
  7. 标题直接说问题,不写口号式、文学式标题,不引用领导人讲话做“穿靴戴帽”式开头。
  8. 建议必须能落到责任主体、机制动作或政策工具,并与前文问题逐项对应,形成闭环。
  9. 语言要像给决策者看的工作文,不像论文、新闻评论或宣传稿。
  10. 标题要精简、准确、切中要害,优先概括核心风险、关键堵点或治理方向,避免写成“关于xxxx的建议”“关于进一步加强xxxx的建议”这类泛标题。
  11. 问题部分不能只有个案和定性判断,全文必须体现一定量的可核实数据支撑;数据不必喧宾夺主,但不能完全缺位。
  12. 中文正文统一使用中文标点和中文引号;中文语境中的直引号 " 必须改成 “”,不能把英文半角引号留到终稿。

输出文件

为每次任务创建目录:social-opinions/{slug}-{timestamp}/

  • 00-brief.md:任务约束、题目、对象、篇幅、是否联网
  • 01-terms.md:本次任务术语表,记录推荐写法、禁用写法、首次解释方式
  • 02-search-plan.md:检索问题、关键词、优先来源
  • 03-source-log.md:来源清单、原文 URL、发布时间、可信度、可用要点,供人工复核
  • 04-evidence.md:事实矩阵,区分已核实事实、判断、待证实点
  • 05-outline.md:切口、标题备选、结构
  • 06-draft-v1.md:初稿
  • 07-review-round-1.md:第一轮自检
  • 08-draft-v2.md:修订稿
  • 09-review-round-2.md:第二轮自检
  • 10-final.md:定稿
  • 11-final-humanized.md:调用 humanizer-zh 后的去 AI 味终稿
  • 12-final.docx:按中国大陆机关公文常见版式导出的 Word 定稿

如果做第三轮校验,再追加:

  • 10-review-round-3.md
  • 11-final.md
  • 12-final-humanized.md
  • 13-final.docx

如果用户只需要聊天窗口里的结果,仍然照常保存定稿文件,并在回复里给出路径。

Markdown 排版约定

各阶段输出的 .md 文件,默认尽量少用 Markdown 表格,优先使用竖向排列的卡片式结构,便于聊天窗口审阅、移动端阅读和后续人工增删。

默认写法:

  • 每个阶段先给一个简短标题,再按主题拆成若干二级或三级小节
  • 每条记录尽量独立成卡片,使用 ##### 或加粗小标题组织
  • 卡片内部优先用短段落和项目符号,避免横向字段过多的宽表
  • 只有在“必须横向对比多个对象且字段很少”时才使用表格;即便使用,也应控制在 3-4 列以内
  • 涉及来源、术语、证据、问题建议映射、自检结论时,优先写成“一个对象一张卡片”的纵向格式
  • 不追求花哨视觉效果;所谓“卡片式”仅指纵向分块清晰、字段固定、便于快速扫读,不是 HTML 卡片

通用卡片模板可参考:

## 卡片标题

- 字段一:内容
- 字段二:内容
- 字段三:
  这里可补一小段说明。
- 字段四:
  - 要点 A
  - 要点 B

工作流

Step 1: 提炼任务,写入 00-brief.md

优先从当前对话直接提取,不要为了默认项反复追问。至少确认:

  • 主题或问题是什么
  • 报送层级:市级、省级、国家级,或由材料判断后确定
  • 报送场景:民主党派、政协、统战部门、内部参考,还是泛用草稿
  • 是否必须联网
  • 是否要求最新政策、最新统计数据或地方案例
  • 目标地域:全国、某省、市、县,还是未限定
  • 用户已有材料有哪些
  • 篇幅或风格要求

如果用户只给了一个大主题,先自动收窄成 2-3 个可报送的小切口,选择最具体、最容易拿到证据、建议最可落地的一项继续写。只有在几个切口风险差异很大时才追问用户。

额外执行两项筛题动作:

  • 先判断问题是否达到“市级及以上起步”的报送价值。如果只是红绿灯损坏、垃圾分类执行细节、单个社区物业矛盾这类区街层面即可处置的事项,不直接成稿,先上提为制度、政策、协同机制层面的堵点;上提失败则明确说明“不宜作为本层级社情民意选题”。
  • 先固定稿件层级。确定为市级稿,就围绕市级权限、跨区共性、全市政策执行问题展开;不要半篇写市级堵点,后半篇又提出国家级立法建议。

00-brief.md 优先写成单页摘要卡,不要用“字段很多的大表”。建议至少包含:

  • 任务主题
  • 拟定切口
  • 报送层级
  • 报送场景
  • 是否联网
  • 是否要求最新政策/数据
  • 目标地域
  • 已有素材
  • 篇幅与风格约束
  • 当前风险或待确认点

Step 2: 术语统一,写入 01-terms.md

出现以下任一情况时,必须先做术语统一,再进入检索和起草:

  • 主题涉及政策专有名词、制度名称、专项行动、改革提法
  • 涉及机构、部门、民主党派、政协系统名称
  • 涉及统计口径、指标名、专业治理术语
  • 含有英文缩写、外来概念、行业黑话
  • 用户给的是口语素材、会议纪要、访谈记录,里面的叫法明显不规范

处理顺序:

  1. 涉及民主党派、政协、统战、履职表达时,先读取 references/glossary-policy-org.md
  2. 再按需读取通用术语表 references/glossary-zh-en.md
  3. 涉及高频民生或治理议题时,补读 references/policy-topic-map.md
  4. 从用户素材和拟检索主题里提取本次任务的关键术语
  5. 形成本次任务的会话术语表,写入 01-terms.md
  6. 标出推荐写法、禁用写法、是否需要首次解释、是否保留英文或缩写
  7. 后续检索、初稿、自检、定稿都以 01-terms.md 为准,不得前后漂移

执行原则:

  • 机构名称、政策名称、法律名称优先使用官方全称
  • 常见简称只有在首次出现已给出全称后,才可单独使用
  • 英文缩写首次出现时,优先使用 中文全称(英文缩写)
  • 容易引发歧义的词,不为了“行文丰富”而频繁更换近义表述
  • 如果 policy-topic-map.md 中列出了较新的中央文件,优先采用该名称,不要退回使用更旧的口头叫法
  • 用户原素材中的不规范表述可以保留为线索,但不能直接搬进定稿

01-terms.md 优先按“一个术语一张卡片”写,不要默认整理成大表。每张卡片至少写:

  • 术语
  • 推荐写法
  • 禁用或不建议写法
  • 是否需要首次解释
  • 备注

Step 3: 建立检索计划,写入 02-search-plan.md

检索目标至少覆盖四类信息:

  1. 问题是否真实存在,症状是什么
  2. 现行政策、制度或执行流程卡在哪里
  3. 有没有权威数据、典型案例、地方实践
  4. 哪些建议已经被广泛说过,如何避免空泛重复,以及当前是否已经出台类似政策

为每个主题生成:

  • 5-10 个中文检索词组合
  • 必查对象:政策法规、主管部门、统计口径、政协党派公开信息、典型地方案例
  • 时间边界:优先近 1-3 年,强时效问题优先近 12 个月
  • 离当前时间过久的依据、数据和案例,除非属于仍然有效的法律法规、国家标准、长期基础制度或无法替代的历史背景材料,否则一般不建议采用
  • 对每一条拟写建议,预留一个“已出台政策核查”检索项,避免把现成政策再重复写成建议
  • 如议题涉及事故、极端事件、人身伤害、未成年人、舆情争议等敏感场景,检索词优先使用中性或官方治理表述,尽量避免直接使用“死亡”“亡人”等高敏词;优先改写为“人员伤害”“安全事故”“严重后果”“突发事件”“善后处置”“风险隐患”“安全治理”等检索路径
  • 如果中性检索词已足够定位权威来源,就不要再追加更敏感的直白说法;只有在核对原始文件标题、法规条文或官方通报原文时,才保留原词

02-search-plan.md 建议按“一个检索问题一张卡片”组织,每张卡片写清:

  • 检索目标
  • 关键词组合
  • 优先来源
  • 时间边界
  • 已出台政策核查项
  • 敏感措辞替代方案

Step 4: 联网搜集资料,写入 03-source-log.md

来源优先级按下列顺序执行:

  1. 党和政府机关、法律法规、政策文件、官方答复
  2. 全国政协、地方政协、民主党派中央或地方组织官网
  3. 国家统计局及地方统计公报、年鉴、公开数据平台
  4. 权威媒体和专业机构报告
  5. 高质量学术论文或行业研究

执行要求:

  • 至少收集 5 个有效来源;涉及复杂议题时争取 8-12
  • 对每个来源记录:标题、原文 URL、发布日期、可信度、摘取要点
  • 03-source-log.md 中必须保留可直接打开的原文 URL,优先记录原始发布页 URL,不要只写站点名、搜索页、聚合页或二次转载链接
  • 如存在跳转链接、短链或门户转载页,需额外补记原始发布单位页面 URL;无法定位原文的,按低可信度或不可用处理
  • 可选补记首次访问时间、访问说明或存档链接,但不得替代原文 URL
  • 同一事实尽量做到双源交叉验证
  • 把“事实”“观点”“推断”分开
  • 自媒体、论坛、短视频评论只能作为线索,不可直接当证据
  • 即使内容出现在新浪、网易、腾讯等平台,也必须判断其原始信源;如果本质是自媒体转载、无原始信源或明显 AI 拼接内容,仍按不可用处理
  • AI 工具给出的链接、案例、统计值、年份,必须逐条人工复核;凡是找不到原始出处或时间明显过期的,一律删除
  • 对发布时间明显偏早、且已存在更新口径或更新数据的材料,原则上用新不用旧;旧材料如确需保留,必须说明它只承担历史背景或制度沿革说明,不作为当前形势判断的核心依据
  • 如果找不到足够权威来源,降低结论强度,不要硬写

03-source-log.md 推荐模板:

## 来源 1:来源标题

- 原文 URL:
- 原始发布单位:
- 发布日期:
- 首次访问时间:
- 可信度:高 / 中 / 低
- 可用要点:
  - 要点 1
  - 要点 2
- 备注:
  - 是否原始发布页
  - 是否转载页或短链跳转页
  - 是否需要二次核验

填写要求:

  • 原文 URL 必填,且应可直接打开用于人工复核
  • 原始发布单位 必填,便于判断口径和权威性
  • 可信度 至少标注为 高/中/低
  • 备注 中标明是否为原始发布页、转载页、短链跳转页,是否已补找到原始链接
  • 除非用户明确要求做总览汇总表,否则不要把全部来源堆成一张横向大表

Step 5: 建证据矩阵,写入 04-evidence.md

不要默认做三列表格。优先按纵向分块整理:

  • 已核实事实
  • 可以成立的分析判断
  • 仍有不确定性的点

同时补一段“可写不可写”判断:

  • 可写:已核实、有普遍性、与决策相关
  • 慎写:个案化、情绪化、缺乏公开证据支持
  • 不写:无法证实的数据、夸大表述、容易引发误读的政治判断

对每个数据和案例,再补两项元信息:

  • 来源出处:原始发布单位、标题、发布日期、链接或可回查标识
  • 使用方式:作为现状引子、问题支撑,还是建议依据

04-evidence.md 建议按“一个证据点一张卡片”写入对应分组,例如:

## 已核实事实

### 证据卡 1
- 事实:
- 来源出处:
- 使用方式:
- 备注:

## 可以成立的分析判断

### 判断卡 1
- 判断:
- 依据:
- 使用边界:

## 仍有不确定性的点

### 待核卡 1
- 待确认点:
- 当前依据:
- 风险:
- 处理意见:

Step 6: 选切口和结构,写入 05-outline.md

至少输出:

  • 2-3 个标题备选
  • 一句话主张:这篇稿子到底想推动什么改变
  • 报送层级与对应责任主体
  • 前言/现状提要
  • 3-4 个问题小标题
  • 问题与建议对应关系
  • 建议框架
  • 每个问题对应的数据抓手或统计口径;至少标明哪些段落会落数据,避免正文只剩案例堆叠

优先使用这类切口:

  • 执行层断点
  • 群众高频痛点
  • 新政策落地中的堵点
  • 现有机制未覆盖的新情况
  • 某类人群被忽视的制度空白

避免:

  • 题目过大,例如“全面推进教育现代化”
  • 纯价值表态,没有具体问题和机制抓手
  • 建议与问题不对应
  • 一个提纲里同时出现市级执行建议、省级财政建议、国家立法建议

起草建议前:

  • 先按议题读取 references/recommendation-playbooks.md
  • 从中选择 2-4 个最匹配的建议抓手,不要把一份稿子写成政策工具大全
  • 只保留和前文问题链条直接对应的建议
  • 明确建立 问题一 -> 建议一问题二 -> 建议二 的映射,不允许出现前文写了四个问题,后文却只有泛泛三条建议的情况

05-outline.md 不要默认做“问题-建议”对照表。优先写成纵向映射卡,例如:

## 问题卡 1

- 问题标题:
- 核心表现:
- 证据抓手:
- 对应建议方向:
- 对应责任主体:

## 问题卡 2

- 问题标题:
- 核心表现:
- 证据抓手:
- 对应建议方向:
- 对应责任主体:

标题拟定要求:

  • 标题优先概括”问题 + 风险/后果”或”堵点 + 治理方向”,而不是写成空泛题目
  • 尽量避免”关于……的建议””关于进一步加强……的建议””关于……情况的反映”等普通公文腔标题
  • 能直接点出问题性质的,优先直接点题,不必额外加”建议”二字
  • 可适度使用”亟待””有待””警惕””谨防””破局””关注”等提示性词语,但前提是判断有证据支撑,不能虚张声势
  • 标题尽量控制在 22 字以内,特殊情况不超过 25
  • 标题要与报送层级匹配,不要出现正文写市级执行问题、标题却拔高到国家战略的情况

标题风格参考:

  • AI手机智能体亟待加强安全、隐私与生态协同治理(问题判断句)
  • 警惕私域直播围猎银发群体(风险提示句)
  • 谨防”沉默企业”成为阻碍市场经济发展的”灰犀牛”(风险隐喻)
  • 税收政策复杂及服务短板制约民营企业发展有待破局(堵点描述)
  • 关注跨国生物医药企业在华战略调整带来的系统性风险(关注 + 风险定性)

避免这类标题:

  • 关于加强 AI 手机智能体治理的建议
  • 关于私域直播问题的建议
  • 关于进一步促进民营企业发展的建议

Step 7: 写初稿,保存到 06-draft-v1.md

默认按下列模板起稿:

# 标题

【现状与前言】
用简明权威数据、主管部门通报或典型事件把问题引出来,篇幅控制在全文的 `10%-20%`。只说明“为什么值得报”,不写长背景,不引用领导人讲话,不做穿靴戴帽。

【主要问题】
一、问题小标题
用事实、数据、案例说明问题表现,并点出机制堵点或执行断点。

二、问题小标题
继续用可核实证据展开,不写空泛判断。

三、问题小标题
如确有必要可写到四个,但不要为了凑数扩写。

【对策建议】
一、对应问题一的建议
二、对应问题二的建议
三、对应问题三的建议
建议部分可占全文约 `40%`。每条建议尽量写清责任主体、动作机制、政策抓手和预期效果。

写作要求:

  • 标题尽量控制在 22 字以内,特殊情况不超过 25
  • 标题要精简准确,优先写成”问题判断句”或”风险提示句”,少用普通公文腔
  • 前言部分务必简短,只起到引题作用
  • 正文尽量短句,少套话
  • 不做文献综述,不长篇铺垫
  • 问题部分优先写 3-4 个,每个问题都要有小标题和证据支撑
  • 问题部分不得完全由个案、媒体案例或抽象判断构成;全文至少要体现 2 处可核实的数据性信息,优先放在前言或问题部分
  • 数据和案例可以并用,不要求每个问题都被数据主导;但只要公开资料中存在可用统计、行政通报、监测结果或行业量化口径,就应适度写入
  • 以事实和机制为主,不以情绪驱动
  • 建议按“最重要、最可实施”排序,并与问题严格一一对应
  • 建议优先写成“谁来做、做什么、靠什么机制做、如何衡量效果”
  • 正文内引注格式:正文中凡涉及具体数据、统计、典型事件,须在该句末(标点前或后)嵌入括号引注,格式为 (来源媒体/机构+日期+《文章或报告标题》)(来源:单位名称+数据口径);引注文字不另起行,不脚注,不单独列参考文献。
  • 中文正文统一使用全角中文标点;中文语境中的引号统一为 “”,书名统一为 《》,括号和顿号、逗号、句号优先使用中文写法,不保留英文半角双引号
  • 建议分层写法:(一)/一、 大项下允许使用内嵌 一是……二是……三是…… 列举若干具体措施,这是标准机关文风,不属于禁止的多层嵌套。禁止的是美式分级列表(如 1.1.1A-a-i)或超过三层的括号嵌套。
  • 不使用”大ABC、小abc”式多层嵌套结构,保持两层以内即可
  • 如果用户给的是现成内容,保留其中有价值的一手观察,但要把口语素材改成报送语言

Step 8: 第一轮自检,写入 07-review-round-1.md

第一轮只看“能不能成立”,不看辞藻。至少检查:

  • 标题是否准确对应问题
  • 标题是否避开“关于……的建议”一类普通泛标题
  • 是否一事一议
  • 报送层级是否明确且前后一致
  • 事实、数字、政策名称、机构名称是否准确
  • 每个问题是否都有来源支撑,来源能否回查
  • 问题部分是否体现了必要的数据支撑,而不是只靠个案和定性判断
  • 有没有把个别现象写成普遍规律
  • 建议是否针对前文问题,而不是另起炉灶

如果存在硬伤,直接重写相关段落,再生成 08-draft-v2.md

07-review-round-1.md 建议按“检查项卡片 + 结论”写,不要做勾选大表。每项可写:

  • 检查项
  • 是否通过
  • 发现的问题
  • 修改动作

Step 9: 第二轮自检,写入 09-review-round-2.md

第二轮看“像不像高质量社情民意”。至少检查:

  • 是否做到小切口、真问题、短路径
  • 标题是否精简、准确、切中要害,能否直接体现问题意识
  • 前言部分是否控制得足够短,没有穿靴戴帽
  • 问题数量是否控制在 3-4 个,且每个问题都有小标题
  • 是否把责任泛化给“社会”“群众”等空主体
  • 建议是否可执行、可分工、可评估,且与问题一一对应
  • 建议是否重复现有政策,是否存在“早已出台却仍作为建议提出”的情况
  • 语言是否像工作文,而不是论文、评论或宣传稿
  • 中文标点是否统一,中文语境中是否仍残留英文双引号、半角括号或半角标点
  • 是否有新意,是否明显像“旧题重写”

修完后输出定稿。

09-review-round-2.md 延续卡片式写法,按“结构质量”“建议质量”“语言质量”“规范性”分别分卡记录即可。

Step 10: 必要时进行第三轮校验

出现以下情况时必须加做第三轮:

  • 涉及最新政策、最新统计数据或近期舆情
  • 涉及教育、医疗、就业、住房、营商环境等高关注民生议题
  • 地方性很强,且用户要求具体到某地
  • 主题证据不够扎实,但仍要形成可用初稿

第三轮重点检查:

  • 时间是否过期
  • 论证是否过度
  • 建议是否超出当前政策权限
  • 数据、案例、链接是否存在 AI 幻觉或二手转述冒充一手来源
  • 有没有更稳妥的表述方式

Step 11: 输出定稿

默认输出两部分:

  1. 定稿正文
  2. 核验摘要

核验摘要 保持简短,只说明:

  • 本稿基于哪些类型的公开来源
  • 哪些点已经核实
  • 哪些点仍属审慎判断

核验摘要 也优先用短卡片或短清单表达,不要再补一个总览表。

输出前增加一个收尾动作:

  • final.md 做一次中文标点归一化检查;如在工作区落文件,执行 python3 scripts/normalize_cn_punctuation.py --input <final.md> --in-place
  • 重点检查中文语境中的英文双引号、半角括号和半角标点,避免把未清理的英文标点带入聊天输出和正式稿

如果用户只要正式稿,可以只展示定稿正文,但内部文件仍要保留。

Step 12: 调用 humanizer-zh 做去 AI 味处理

在生成 docx 之前,默认先调用 humanizer-zh skill,对最终 md 定稿做一次“去 AI 味”处理,并保存为 final-humanized.md

执行要求:

  1. 输入文件使用最终定稿 final.md
  2. 调用 humanizer-zh 时,明确限定目标是去掉 AI 套话、宣传腔、连接词堆叠、机械三段式和明显的模型化痕迹
  3. 不允许把正式报送材料改成口语随笔,不允许引入第一人称、俚语、幽默、自我表态、情绪化判断或网感表达
  4. 去 AI 味后,立即回看 01-terms.md04-evidence.md 和最终定稿,确认术语、事实、数据、政策名称、报送口吻没有漂移
  5. 去 AI 味后,再执行一次中文标点归一化,尤其检查中文引号是否被还原成英文直引号
  6. humanizer-zh 的修改会削弱正式性、准确性或决策参考口吻,应回退相关改动,宁可保留较克制的工作文风格

这一轮处理的目标不是“写得更像个人博客”,而是让文本少一些机械生成痕迹,同时仍然像可以报送的工作文。

Step 13: 生成 docx 正式稿

除非用户明确说“不需要 Word”或“只保留 markdown”,否则定稿后默认追加生成 docx 文件。

执行顺序:

  1. 读取 references/docx-format-cn-official.md
  2. 先调用 humanizer-zh 生成 final-humanized.md
  3. final-humanized.md 执行中文标点归一化:python3 scripts/normalize_cn_punctuation.py --input <final-humanized.md> --in-place
  4. final-humanized.md 为输入,运行 python3 scripts/generate_docx.py --input <final-humanized.md> --output <final.docx>
  5. 在回复中给出 docx 文件路径;如字体因本机环境缺失发生回退,需顺带说明

版式要求按“GB/T 9704-2012 页面设置基线 + 中国大陆机关材料常见排版习惯”执行。注意:社情民意信息并不等同于带版头、发文字号、版记的正式党政机关公文,因此默认只套用适合报送材料的正文版式,不擅自添加红头、文号、版记或印章位。

默认版式:

  • A4 纵向
  • 页边距:上 37mm、下 35mm、左 28mm、右 26mm
  • 标题:居中,二号,优先 方正小标宋简体,无该字体时回退到 宋体
  • 正文:三号,优先 仿宋_GB2312
  • 一级标题:一、 形式,三号黑体
  • 二级标题:(一) 形式,三号楷体_GB2312
  • 正文首行缩进 2 字符
  • 行间距:固定值 28pt
  • 段前段后:0
  • 标题下方空 1 行;正文段落之间默认不额外空行

如用户提供本单位模板或明确版式要求,以用户模板优先;不要用默认版式覆盖用户既有模板。

联网研究约束

  • 用户要求“最新”“当前”“今年”“最近”时,必须联网核实,不能凭记忆写
  • 优先找政策原文、统计原表、政府部门通报,不要先看二手解读
  • 发现事实冲突时,优先采用更高等级、更新、口径更明确的来源
  • 找不到公开证据支持的内容,不要包装成确定事实
  • 离当前时间太久的依据和数据一般非必要不采用;优先使用近 1-3 年材料,强时效议题优先近 12 个月材料
  • 只有在引用仍然有效的法律法规、国家标准、基础制度安排或必要历史沿革时,才保留较早材料;且不能让旧材料充当当前判断的主证据
  • 检索阶段默认做“去敏感化措辞”:先用中性、治理化、官方化表述搜索,再决定是否需要查看原始标题或原文
  • 避免把“死亡”“亡人”等词作为首选搜索词;优先用“人员伤害”“安全事件”“事故处置”“风险防范”“善后工作”等替代表述
  • 但来源记录必须保持准确:如果官方文件、通报或原始报道标题本身包含相关词语,03-source-log.md 中仍应按原题名如实记录,不得擅自改写

默认改写策略

用户只给主题

先研究,再写。不要在证据不足时直接编一篇“看起来像”的稿子。

用户给了素材

先抽取可核实的事实和一手观察,统一术语和叫法,再补充公开资料,最后重组为标准社情民意结构。

用户给了初稿

先做问题诊断,再补证据,再重写。不要只在原稿上机械润色。

定稿标准

只有同时满足以下条件,才可判定为定稿:

  1. 主题明确且单一
  2. 事实和政策表述经得起复查
  3. 问题和建议一一对应
  4. 建议具备现实可操作性
  5. 专有名词、政策术语、机构简称前后一致
  6. 行文简洁,基本去掉论文腔、宣传腔、空话套话
  7. 报送层级清楚,没有把区街事务硬写成市级以上决策议题
  8. 全文不存在无来源数据、虚构案例、虚构链接

如果达不到,就继续修,不要把明显仍是“初稿”的内容冒充定稿。

示例触发

示例 1 输入:请围绕“基层医院检查检验结果互认难”写一篇社情民意,要补充最新政策和案例。

示例 2 输入:我给你一段调研笔记,你帮我整理成民主党派报送的社情民意信息。

示例 3 输入:以“县域普通高中教师流失”为主题,自动查资料,出初稿,反复自检后给我定稿。

Weekly Installs
2
Repository
zuoa/aj-skills
First Seen
Mar 19, 2026