vivy-yi
vivy-yi/Greater-China-Legal
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/vivy-yi/Greater-China-Legal --skill history-evolution-qcc명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
刑事判决书生成——接收案件事实描述，调用8个原子能力，生成格式规范、论证严密的完整刑事判决书。 适用情形：用户要求"起草判决书"/"生成裁判文书"/"根据案卷写文书"。 核心流程：事实提取→概念理解→争议识别→法条检索→案例检索→演绎推理→格式适用→术语规范。 注意：本skill是刑事一审判决书专用模板，GCL不涉及实际司法文书输出，此skill仅作框架参考。
法律文书格式适用——起草格式规范的民事/刑事判决书，或识别文书类型并套用对应格式。 适用情形：起草判决书/生成裁判文书/写民事判决书/写刑事判决书。 核心：识别民事vs刑事→按七段式顺序起草→在需要处调用对应原子技能。 这是GCL各场景的文书输出层，与judgment-document-generation互补（后者专注刑事+8步流程，前者覆盖民刑+分段落格式规范）。
法律文书摘要——对判决书、裁定书、调解书、仲裁裁决书、行政处罚决定书进行结构化摘要。 适用情形：用户要求做摘要/提炼要点/生成裁判要旨/提取案件信息。 核心：六要素框架（案件信息+事实背景+争议焦点+法律依据+结论结果+说理过程），忠实原文，区分文书类型。 禁用：不得添加原文未载明的事实/观点/结论，不得出现主观评价性措辞。
SOC 직업 분류 기준
SKILL.md 표시 중
| name | history-evolution-qcc |
| description | TODO: 待补充 description（YAML 安全的描述） |
| legal_frame | cn-mainland |
| last_reviewed | 2026-06-24T00:00:00.000Z |
| version | 1.0.0 |
| risk_level | low |
| trigger_phrases | ["history-evolution-qcc"] |
企业历史沿革与发展历程分析 Skill — 企查查MCP驱动的KYB立体叙事报告生成器。 基于企查查 MCP 146 个工具自动生成 11 章 + 附录的 KYB 历史沿革报告。
V1.2 核心特性（schema-driven · 防编造）：
- USCC 校验位：GB 32100-2015 校验位算法，编造的统一社会信用代码会被拦截
- count ≡ rows：股东/历史股东/董监高/对外投资等列表，声明数量必须等于实际行数
- evidence 锚点：每个字段都有
(tool_name, json_path, snapshot_ts, raw_value)四元组溯源- 跨章节一致性：处罚状态禁止"已处置/已闭环"等需 MCP 显式返回的状态词； 专利年度分布加和必等于总数；时间合理性自检
- manifest.json：每份报告产出字段级溯源链，可用于审计回溯
核心功能：
- 11 章结构：§1 公司概况 / §2 发展里程碑 / §3 注册资本 / §4 名称变更 / §5 股权演变 / §6 经营轨迹 / §7 地址变迁 / §8 总结 / §9 发展综览 / §10 附录 / §11 审计留档
- 立体叙事：许可资质矩阵、知识产权布局、业务扩张与员工规模、行业地位与荣誉
- 档位自适应：小微（¥4.5）/ 融资（¥13）/ 上市（¥18）三档自动识别并差异化调用
- 视觉风格：圆点+竖线时间轴 + kyb-opus 风格蓝色章节条 + 斑马纹表格，直接出 PDF
适用场景：投前尽调（PE/VC）、IC Memo 附件生成、银行授信 KYB、供应商主体背调、 管理层背景与发展历程核查。
使用方式：/history-evolution-qcc 企业名称 [统一社会信用代码] 客户体验：一句话指令 → 60 秒自动生成 MD + PDF + manifest.json，零干预、零编造。
风险核查采用「先扫后钻」：先通过企业风险全量扫描一次性分诊 35 项风险维度、快速定位命中项，再对命中维度深入取证——既不漏维度，也避免逐项无效查询。
命令：/history-evolution-qcc · MCP 工具集：QCC MCP (Company/Risk/IPR/Operation/History/Executive)
本 SKILL 凡涉及“一次性排查 ≥ 2 个企业风险维度”（司法风险 / 失信 / 被执行 / 限高 / 经营异常 / 行政处罚 / 破产 / 担保 / 税务 等 qcc-risk 维度），一律按“先扫后钻”执行，禁止逐个原子风险工具散弹枪式调用（慢 / 贵 / 多为无效调用）：
第 1 步 · 分诊（先扫）：先调
mcp__qcc-risk__get_company_risk_scan（企业风险扫描）一次返回企业自身 35 项风险维度的命中计数（脱水版：有 / 无 + 条数，不含明细）。第 2 步 · 下钻（后钻）：仅对
count > 0的维度，调对应原子风险工具取明细（具体工具见本 SKILL 工作流 / 术语对照表）。示例：scan 显示「失信 2、被执行 1、其余 0」→ 只下钻mcp__qcc-risk__get_dishonest_info+mcp__qcc-risk__get_judgment_debtor_info。
count = 0的维度：直接判定“无记录”，不再调用该维度原子工具。明确单一维度问句（仅查某一项，如“有没有失信”）→ 直接调对应原子工具，无需先扫（对应 A 层铁律 5-A 路由 3）。
scan 只分诊、不出明细；要明细必须下钻原子工具。风险结论只陈述“命中维度 + 计数 / 明细”客观事实，不替客户判定“能不能合作 / 可不可开户”。
先扫后钻发生在实体锚定确定唯一主体之后；简称 / 品牌名仍须先
mcp__qcc-company__get_company_by_query锁定主体，再 scan。本轮仅引用已上线的
get_company_risk_scan（企业自身风险扫描）；企业“自身风险”之外的聚合扫描能力尚未上线（Phase 2），本 SKILL 不得引用任何未上线的聚合风险扫描工具。【定性必须有下钻证据】 对任一风险维度给出定性判断（如“多为原告身份 / 属正常维权”“轻微合规瑕疵”“诉讼活跃度正常”等）之前，必须已下钻该维度的明细工具、拿到支撑数据；未下钻则只陈述 scan 计数并标注“（未取明细）”，禁止凭 scan 计数或印象给定性。例：scan 显示「裁判文书 77」但未下钻
mcp__qcc-risk__get_judicial_documents→ 只能写“裁判文书 77 条（未取明细）”，不得写“多为原告身份、属正常维权”；如需该定性，必须先下钻get_judicial_documents（可按role取原告 / 被告分布）再下结论。
加载方式（W1-9 整改 · 2026-05-04）
本 SKILL 支持两种加载方式：
方式 A · 推荐 · 单 SKILL.md 直链 通过
https://agent.qcc.com/skill/v1/financial-services-qcc/history-evolution-qcc/SKILL.md加载本文件后，AI 工具按本文档内的业务规则、MCP 工具清单与档位策略直接执行即可，无需访问任何scripts/或references/文件——本 SKILL.md 自包含全部业务规则与工具调用约束。方式 B · 高级 · GitHub 完整仓库 通过
git clone https://github.com/duhu2000/financial-services-qcc拉取完整仓库后，可使用scripts/mcp_orchestrator.py/scripts/cost_counter.py/references/05_工具调用清单.md等配套 Python 实现做自动化编排（适用于自建产线、批量跑数、想 fork 升级业务规则的高级开发者）。下文中所有
scripts/...与references/...路径仅适用于方式 B。AI 工具用方式 A 加载时按 SKILL.md 描述自行 MCP 调用即可，对应工具列表与成本规则见正文。
🚨 AI 加载本 SKILL 后必须遵守的 5 条防编造硬约束（V1.2 红线） 🚨
历史教训：本 SKILL V1.1.3 版本的示例报告曾出现 13 项数据错误（统一社会信用代码编造、 股东漏列、专利数错位、行政处罚状态编造等）。V1.2 通过以下 5 条绝对硬约束根除这类问题。 AI 在生成报告的每一步、每一个字段，都必须自检以下规则：
- 统一社会信用代码（USCC）禁止任何形式的编造或猜测
- USCC 必须直接来自 MCP 工具
qcc-company.get_company_registration_info的返回字段- 如果 MCP 没返回，就标注「未披露」
- 不允许根据企业名称、注册地推测 USCC
- 18 位 USCC 的最后一位是 GB 32100-2015 校验位，编造的 USCC 大概率过不了校验
- 任何"列表"型字段必须全量展示，禁止省略中间项
- 当前股东、历史股东、历任董监高、对外投资 等
- 如果 MCP 摘要里说"共 X 条"，渲染的表格行数就必须等于 X
- 不允许为"美观"或"重要性"截断中间项
- 如果数据量真的太大，写"完整列表见附录"而非省略
- 行政处罚 / 司法记录的「处置状态」字段，仅当 MCP 显式返回时才能写
- 严禁写"已处置 / 已闭环 / 当期整改 / 整改完毕"等结论性状态
- MCP 没返回的字段（如违法行为类型详情），写"违规细节未公开"
- 处罚日期、处罚机关、决定书文号必须直引 MCP 返回的原文
- 统计字段（年度分布、级别分布、数量统计）必须从原始数据 group-by 算出
- 专利年度分布、荣誉级别分布、资质类别统计
- 不允许凭印象写数字
- 加和必须严格等于总数（如 94 项专利的年度分布加和必须 = 94）
- MCP 没返回的字段，绝不"补全"或"合理化"
- LLM 倾向于让故事完整 — 这是 V1.1.3 编造"递交主板申报稿""2010 年最早专利" 的根本原因
- 严守纪律：MCP 给什么就写什么；没给的就明确标注「未披露」/「数据缺失」
- 严禁基于行业常识、企业规模、发展轨迹"推测"或"补全"
如果你（AI）在生成内容时无法遵守上述 5 条，请明确拒绝并告知用户："本字段缺数据， 不能在不违反防编造规则的前提下生成"。
qcc-company 14 + qcc-risk 34 + qcc-ipr 6 + qcc-operation 14+1 + qcc-history 34 + qcc-executive 35）references/06_V2.0客户自升级指引.md 自行扩展至 V2.0，本 SKILL 作者不提供 V2.0 模板或支持从用户消息中识别：
按 references/04_档位识别规则.md 的决策树：
mcp__qcc-company__get_company_profile（5c）——获取基本信息mcp__qcc-company__get_listing_info（5c）——判断上市状态mcp__qcc-operation__get_financing_records（5c）——判断融资阶段按以下规则判定档位：
按 references/05_工具调用清单.md 中对应档位的工具清单，使用 scripts/mcp_orchestrator.py 的 call_tools_by_tier() 方法批量调用。
成本控制（由 scripts/cost_counter.py 自动强制）：
按 references/02_报告模板.md 的 7 章结构渲染内容：
条件扩展子节（档位达标时自动启用；不达标时整节不输出，不要留空占位）：
| 子节 | 启用条件 |
|---|---|
| §4.4 实控人认定 | get_actual_controller 返回非空 |
| §4.6 申报前 12 月新增股东 | 档位 = 上市档 或 Pre-IPO |
| §5.4 董监高与治理 | 档位 ≥ 融资档 |
| §5.5 关联方网络（公开可查） | 档位 ≥ 融资档 且 get_executive_controlled_companies 返回非空 |
| §5.6 处罚与担保 | get_administrative_penalty / get_guarantee_info / get_equity_pledge_info 任一返回非空 |
| §7 财务摘要 | 档位 = 上市档（A 股 + 发债） 且 get_financial_data 返回非空 |
V1.2 提供两种渲染模式 —— AI 应根据所处运行环境自动选择：
适用：百炼 / Coze / OpenClaw / 任何不能直接跑 Python 的云端 AI 应用
AI 严格遵守上方"5 条防编造硬约束"，按以下模板生成 Markdown 报告：
# 企业历史沿革与发展历程报告
## {企业名称}
**目标企业：** {MCP 直接返回}
**统一社会信用代码：** {MCP 直接返回 — 严禁编造}
**报告版本：** v1.2
**报告生成：** {当前日期}
---
## 执行摘要（决策摘要）
> **一句话结论：** {基于 MCP 真实数据组织的总结，含「N 次注册资本变更、N 次更名、
> N 次办公地迁移、N 位股东退出、当前 N 位股东」等具体数字 — 数字必须与下方各章节
> 一致，不允许"约""大约""若干"等模糊词}
---
## 一、公司概况
> 业务化呈现：单一表格 + 业务化表头「项目 / 内容」，**禁止使用「字段 / 值」等
> 技术化表头**。字段顺序按「主体识别 → 注册信息 → 经营状态」逻辑排列。
| 项目 | 内容 |
| --- | --- |
| 企业名称 | {「工商登记」 → 企业名称} |
| 统一社会信用代码 | {同上 → 统一社会信用代码} |
| 法定代表人 | {同上 → 法定代表人} |
| 企业类型 | {同上 → 企业类型} |
| 所属行业 | {同上 → 国标行业} |
| 成立日期 | {同上 → 成立日期} |
| 注册资本 | {同上 → 注册资本} |
| 实缴资本 | {同上 → 实缴资本} |
| 注册地址 | {同上 → 注册地址} |
| 所属地区 | {同上 → 所属地区} |
| 登记状态 | {同上 → 登记状态} |
| 登记机关 | {同上 → 登记机关} |
| 最近核准日期 | {同上 → 核准日期} |
| 参保人数 | {同上 → 参保人数} 人 |
---
## 二、发展里程碑
按时间排序的关键节点（**仅来自工商登记 + 国家级首次荣誉**，不允许编造未来事件
如"递交主板申报稿"等）：
| 日期 | 里程碑 | 说明 |
| --- | --- | --- |
| {成立日期} | 企业成立 | {设立时名称} |
| {历史名称变更日期} | 名称变更 | {旧名} → {新名} |
| {国家级荣誉首次获得日期} | 获国家级『xxx』认定 | {发布单位} |
---
## 三、注册资本变更轨迹
共 **N 个注册资本节点**（**N 必须等于 历史注册资本列表长度 + 1**）：
| 变更日期 | 注册资本 | 有效期 |
| --- | --- | --- |
| {历史第一项的终止日期} 至今 | {当前注册资本} | 当前 |
| ... | ... | ... |
---
## 四、名称变更时间线
共 **N 个名称节点**（**N = 历史名称列表长度 + 1**）
---
## 五、股权演变
### 5.1 当前股东与出资结构
共 **N 位股东**（**N 必须等于 「股东信息」 摘要里的"共 X 条"**），按持股比例
降序，**全量展示，禁止省略**：
| 股东名称 | 持股比例 | 持股数 |
| --- | --- | --- |
| ... | ... | ... |
### 5.3 股东进出历史
共 **N 位股东已退出**（**N = 摘要里的"共 X 条"**），按退出日期倒序，**全量展示**：
| 退出日期 | 股东名称 | 退出比例 | 认缴 | 类型 |
| --- | --- | --- | --- | --- |
| ... | ... | ... | ... | ... |
### 5.4 实际控制人
| 姓名 | 直接持股 | 总持股 | 表决权 |
| --- | --- | --- | --- |
| ... | ... | ... | ... |
---
## 六、经营轨迹
共 被投资企业（），全量：
| 被投资企业 | 持股比例 | 成立日期 | 状态 |
| --- | --- | --- | --- |
| ... | ... | ... | ... |
共 （）
共 （），全量
---
共
---
| 维度 | 评价 |
| --- | --- |
| 股权清洁度 | ... |
| 经营合规 | {如果有处罚：处罚日期 + 处罚机关 + 决定书文号 + 罚款金额，
| | |
| 成长轨迹 | ... |
---
共 （），有效
（）
共 （）
发明授权 X 项、外观设计 Y 项（）
{从 「专利信息」 → 专利信息 list 里按 申请日期[:4] group-by 算出
— }
共 （）
---
MCP 工商变更总数：（）
| 处罚日期 | 处罚单位 | 决定书文号 | 处罚结果 |
| --- | --- | --- | --- |
| {直引 MCP} | {直引 MCP} | {直引 MCP} | {直引 MCP} |
---
| 项目 | 数据 |
| --- | --- |
| 报告编号 | SKILL-HE-QCC-{YYYYMMDD}-001 |
| 数据源 | 企查查 MCP |
| 防编造规则 | V1.2 5 条硬约束 |
适用：Cursor / Claude Code / 任何能跑本地 Python 的 AI 应用。
在生成 MD 后，AI 自动尝试调用 V1.2 schema 校验 + ReportLab PDF 渲染：
# 第 1 步：把 12 个 MCP 返回组装为 JSON
# AI 把已收集的 MCP 数据写入 data/mcp_responses.json
# 第 2 步：跑 V1.2 校验 + 出高质量 PDF
cd skills/history-evolution-qcc
python -m scripts.v1_2.render_pdf \
--uscc <USCC> \
--mcp-responses-json data/mcp_responses.json \
--report-id SKILL-HE-QCC-<YYYYMMDD>-001 \
--out output/<企业名>_历史沿革.pdf
这一步会自动 enforce 5 条防编造规则：
如果任一规则触发，Python 会直接 raise，这时 AI 应该回看自己生成的 MD，找出问题并重新生成。
1. 当前 AI 应用能不能跑 Python（执行 bash 命令）？
├── 不能（如 百炼 / Coze 云端） → 用模式 A，仅出 MD
│ 告知用户："已生成 MD 报告，遵循 V1.2 防编造规则。
│ 如需高保真 PDF（圆点时间轴），请联系企查查云端服务。"
│
└── 能（如 Cursor / Claude Code / 本地 Cowork）
└── 先用模式 A 生成 MD，再用模式 B 跑 V1.2 校验
├── 校验通过 → 出 PDF + MD + manifest，三件套交付
└── 校验失败 → 回看 MD，找出冲突字段，修正后重新生成
关键原则：无论模式 A 还是 B，5 条防编造规则都必须遵守。 模式 A 靠 AI 自律（prompt enforce），模式 B 多一道代码 enforce 保险。
clean_baseline / recovered / evasive_high_risk（见 references/02_报告模板.md）get_shareholder_info 二级穿透，最多 3 层[来源: qcc-xxx/tool_name · snapshot=YYYY-MM-DD] 标签（build_docx 自动处理）history-evolution-qcc/
├── SKILL.md # 本文件：入口与工作流
├── README.md # GitHub 落地页
├── CHANGELOG.md # 版本记录
├── mcp_config_example.json # MCP 连接示例
├── references/
│ ├── 01_方案文档.md
│ ├── 02_报告模板.md
│ ├── 03_MCP字段映射表.md
│ ├── 04_档位识别规则.md
│ ├── 05_工具调用清单.md
│ ├── 06_V2.0客户自升级指引.md
│ └── 07_升级建议稿.md
├── scripts/
│ ├── tier_detector.py # 档位识别
│ ├── cost_counter.py # 100c 封顶保护
│ ├── mcp_orchestrator.py # MCP 批量调用
│ ├── build_timeline.py # 圆点+竖线时间轴 PNG（DPI 240）
│ ├── build_docx.py # V1.1.3 legacy DOCX/PDF（保留）
│ ├── requirements.txt # pydantic ≥ 2.0 / reportlab ≥ 4.0 ...
│ └── v1_2/ # ★ V1.2 schema-driven 框架（默认入口）
│ ├── uscc_validator.py # GB 32100-2015 USCC 校验位算法
│ ├── evidence.py # MCP 调用 evidence 锚点 + manifest
│ ├── data_contract.py # pydantic schema（count ≡ rows 强约束）
│ ├── data_extractor.py # MCP 返回 → ReportSchema 转换
│ ├── consistency_check.py # 跨章节一致性 + 状态词编造拦截
│ ├── render_md.py # Schema → MD 渲染
│ ├── render_pdf.py # Schema → PDF 渲染（圆点时间轴）
│ ├── build_report_v1_2.py # 主入口（同时出 MD + manifest）
│ ├── test_v1_2.py # 红绿对照测试（7 项 V1.1.3 事故回归）
│ ├── README.md # V1.2 框架文档
│ └── sample_data/
│ └── mcp_responses_qcc.json # 企查查科技完整 12 工具数据快照
└── assets/
├── 示例_上市档_企查查科技_V1.2.md
├── 示例_上市档_企查查科技_V1.2.pdf
└── 示例_上市档_企查查科技_V1.2.manifest.json # 字段级 evidence 溯源
# 1. 拉取 SKILL
git clone https://github.com/<org>/financial-services-qcc.git
cd financial-services-qcc/skills/history-evolution-qcc
# 2. 创建虚拟环境（推荐）
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
# 3. 装依赖
pip install -r scripts/requirements.txt
# 4. 跑一次 V1.2 自检（应该 7 项测试全过）
python -m scripts.v1_2.test_v1_2
客户 → Claude：帮我生成企查查科技股份有限公司的企业历史沿革报告
Claude 会自动：
约 60-90 秒完成，零干预。
# 自己抓 MCP 数据存为 JSON（或先用 sample_data 跑通流程）
python -m scripts.v1_2.render_pdf \
--uscc 91320594088140947F \
--mcp-responses-json scripts/v1_2/sample_data/mcp_responses_qcc.json \
--out output/qcc_history.pdf
| 档位 | 成本 | 触发条件 |
|---|---|---|
| 小微档 | ¥1.5–3 | 无上市、无融资、注册资本 ≤ 1000 万 或 ≤ 50 人 |
| 融资档 | ¥5–8 | 未上市但有融资记录（天使—Pre-IPO 任一轮） |
| 上市档 | 封顶 ¥10 | 已上市 或 发债 |
客户在自己的 Claude 环境跑 SKILL 拿到的报告，与官网示例报告（
mcp_web/apps/web/public/examples/history-evolution-opus.{md,pdf}）质量等同。
原因：
scripts/v1_2/sample_data/mcp_responses_qcc.json 是企查查科技真实数据快照，可直接复现示例客户不需要做的事（这是我们 V1.0 → V1.2 演进过程中踩过的坑，已经在代码层闭合）：
scripts/build_docx.py + build_timeline.py 作为兼容层references/06_V2.0客户自升级指引.mdget_xxx / mcp__qcc-xxx）、server 名（qcc-company 等）、schema / manifest / 字段名等技术词；数据来源统一用业务表述（如"企查查工商登记数据 / 企查查风险信息数据 / 企查查财务数据"）。"企查查 MCP"作为对外产品名仅允许出现在「数据来源」固定句式中。