G 企网络安全与信息化技术材料的起草、审阅和保真改写 Skill。
A writing, review, and fidelity-preserving rewriting skill for cybersecurity and IT documents in Chinese state-owned enterprises.
当前稳定版本：v1.1.1
v1.1.1 完成阶段感知基础层：在既有七类场景、保护项、证据检查和 H1—H6 质量闸门之上，增加工程建设、科研课题、治理运行三类业务域的生命周期与材料子类型识别，统一材料集关系、写作准备单、项目上下文、正式模板适配和提取缺口阻断。新增能力仍遵守保守证据边界，不以合成案例声称深度支持、联审支持、前向验证或统计稳定性。
yangqi-tech-writing 用于降低 G 企技术材料中的模板感、表演性语言和信息空转，同时保护法规标准、数字参数、技术术语、责任主体、规范性强度和正式结论。
它不是通用“洗稿”工具，也不以口语化替代正式表达。项目不判断作者身份，不保证技术方案正确或法律适用，也不会为增强论证而编造数字、事故、案例、认证和效果。
| 场景 | 典型材料 | 默认策略 |
|---|---|---|
| 可研立项 | 可研、项目建议书、建设必要性、投资效益 | standard / bounded |
| 架构设计 | 初设、详设、总体架构、部署与接口设计 | minimal或standard / in-place |
| 技术规范 | 技术规范书、招标需求、评分条款 | minimal / in-place |
| 投标应答 | 逐条响应、偏离说明、证明材料 | minimal或standard / in-place |
| 安全制度 | 管理制度、操作规程、应急预案 | minimal / in-place |
| 汇报材料 | 领导汇报、PPT 文字稿、一页纸 | standard / structural |
| 评审验收 | 评审意见、验收报告、会议纪要 | minimal / in-place |
核对材料标准化视图与提取缺口
→ 应用正式模板或生成建议提纲
→ 识别场景
→ 锁定保护项
→ 检查证据状态
→ 保持陈述效力
→ 选择两阶段处理或快速通道
→ 识别 T1/T2/T3 风格问题
→ 选择改写档位与 scope
→ 起草、审阅或改写
→ 两遍复读
→ H1—H6 质量闸门
四项硬原则：
- 事实不漂移；
- 术语不替换；
- 责任不模糊；
- 正式度不降低。
H1—H6 分别检查保护项、证据状态、规范强度、场景合同、用户授权和结论追溯。任一硬闸门失败，不输出“可定稿、可签批、完全响应或通过验收”的结论。
从 Releases 下载 yangqi-tech-writing.skill，按所用 Agent 或 Codex 客户端的 Skill 安装方式导入。
git clone https://github.com/w4yne00/yangqi-tech-writing.git
mkdir -p "$CODEX_HOME/skills"
mkdir -p "$CODEX_HOME/skills/yangqi-tech-writing"
cp yangqi-tech-writing/SKILL.md "$CODEX_HOME/skills/yangqi-tech-writing/"
cp -R yangqi-tech-writing/references yangqi-tech-writing/scripts "$CODEX_HOME/skills/yangqi-tech-writing/"重启或重新加载 Skill 列表后，确认 yangqi-tech-writing 可用。
按 G 企可研报告风格改写这段建设必要性。保留政策文号、投资金额、
建设周期和现状事实；没有来源的数据列为待确认项。
审阅这份技术规范。保持条款编号和所有“应、须、不得”，只标出不可验证、
主体不明或缺少验收方法的要求，不要自行补参数。
先别改稿，只列出最主要的五个问题。每项包含定位、问题类型、影响、风险级别、
建议动作和是否建议改写；没有实质问题时明确说明无需调整。
完整执行规则见 SKILL.md，场景边界见 references/scene-packs。
scripts/perception_decision.py 接收“用户任务＋材料标准化视图＋可选正式模板＋可选陈述＋可选材料集”的 JSON 请求，输出统一的业务域、生命周期位置、文种场景、材料子类型、结构适配、任务模式、陈述效力边界、材料关系、提取缺口审查、支持级别、处理模式、加载合同、待确认项和阻断项。schema 对象拒绝未知字段，定位对象允许扩展；任务范围只接受 document 或 local。陈述的证据状态与效力分别记录；有来源的建议不会变成已批复或已实施事实，文种转换也不能在已批复边界、合同承诺、实施事实和验收结论之间替换。
工程建设域识别覆盖立项、设计、采购、实施、试运行、验收和运营位置，并分别保留项目建议书、可研、初设、详设、总体架构、技术规范、投标应答、工程实施方案、实施记录、阶段汇报、试运行报告、验收大纲、验收报告和运行维护报告等材料子类型。明确的局部任务加载既有场景基础合同；整份新建只声明识别覆盖。具体目录和降级边界见工程建设域识别覆盖。
科研课题域识别覆盖申报、任务约定、研究实施、中期检查和结题验收位置，并区分科研申报书、可研论证、任务书、研究实施方案、中期汇报、中期检查与结题验收材料。科研实施方案与工程实施方案保持不同业务域和生命周期；科研中期汇报同时保留 midterm_review 和 presentation；结题验收不会被当作普通工程验收报告。明确的局部任务只加载既有场景基础合同，整份新建只声明识别覆盖。具体目录和降级边界见科研课题域识别覆盖。
治理运行域识别覆盖制度制定、发布执行、检查评估、应急处置和修订位置，并区分管理制度、管理办法、操作规程、应急预案、演练方案、专项处置方案、治理汇报、治理评审和制度修订材料。治理汇报同时保留 governance_operation、inspection_evaluation 和 presentation；制度与预案继续使用既有安全制度场景合同及保护项、陈述效力、H3 约束。信息不足时只使用保守基础合同，不推断组织职责或制度效力。具体目录和降级边界见治理运行域识别覆盖。
初步设计评审汇报和科研课题结题验收汇报通过统一决策保留业务域、生命周期与复合文种关系：顶层 document_scene 为 presentation，composite_routing 中的局部场景为 review_acceptance。整体汇报内容可使用 structural，评审意见、验收结论、问题数量、整改责任和日期等局部内容使用更严格的 in_place。缺少专用材料合同时加载两个既有场景基础合同，支持级别按任务模式保持 recognition_coverage 或 basic_support，不声明深度支持。完整边界见复合文种路由。
材料集关系支持 governs、derives_from、supersedes、implements、verifies、conflicts_with 和 unclear。控制与替代只采用批准、签署、用户指定或明确关系，不按文件日期自动覆盖；范围、数量、参数、责任、时间、结论和陈述效力冲突形成阻断项。单材料或上游缺失时会明确标记无法验证跨阶段一致性，不声称联审完成。该兼容切片不表示任何材料组合已经获得联审支持。
已识别的工程建设、科研课题或治理运行完整方案新建，以及提供 material_set 的多材料整合任务使用 two_stage：第一阶段输出可确认的写作准备单，列出材料、关系、感知维度、控制性材料、事实与判断、假设、冲突、待确认项、追溯摘要和拟加载合同；确认后才进入成稿阶段。文种不明的普通文档新建不会仅因 scope: document 被升级。明确的局部改写、审阅和只标问题任务可以使用 quick_path，但出现待确认项或阻断项时降级为 conservative_audit。快速通道仍执行保护项、证据、陈述效力和 H1—H6。完整合同见写作准备单与快速通道。
材料标准化视图必须保留 source_id、材料状态和至少一个原文定位，并明确标记 is_formal_material: false；需要时可进一步保留文件名、标题条款层级、页码、表号、图号、表格关系、引用位置和提取缺口。它是专业文档工具生成的派生输入，不是新的正式材料。输入不足时，决策保留 unknown、unclear 及带依据的候选分类。
提供正式模板时，模板控制章节、编号、表格和必填项，系统记录显式提供的语义责任映射，不覆盖正式结构，也不另行输出推荐提纲；当前没有专用材料合同责任集时不判断映射完整性，标题不同不自动等于内容缺失。未提供正式模板时，才输出标记为“建议”、非正式且可调整的推荐提纲。OCR 不确定、表格关系丢失或图示无法恢复时，只有显式依赖相应缺口的高风险结论被阻断；低风险或无依赖 Claim 只记录缺口。完整新建或多材料整合即使因此降级为保守审阅，也保留写作准备单承载阻断项。核心不实现 DOCX、PDF、Excel、OCR 或图像解析器，也不新增运行时第三方依赖。完整合同见正式模板适配与提取缺口阻断。
python3 scripts/perception_decision.py request.json持续性工程或课题可以选择维护项目隔离的本地 JSON 上下文包，用于保存材料元数据、已确认关系、范围、术语、已确认事实、假设、决策、冲突和追溯链。单次任务不需要上下文包；省略 --context 时不会落盘。
只有请求明确提供 confirmation.status: confirmed 和 confirmation.actor: user 时才写入。rejected 或 pending 保持本地文件不变；同一上游材料发生版本或内容变化时，关联结论、决策、关系和追溯链进入 pending_review。已有上下文包的 project_id 与请求不一致时阻断，项目受限信息不会自动跨项目合并或复用。
写盘前会拒绝常见密钥、口令、令牌、真实账号和无必要个人信息，错误结果不回显原值。该入口只使用 Python 标准库和用户指定的本地 JSON 文件，不自动调用外部网络、上传服务或外部数据库。完整合同见 项目上下文包。
python3 scripts/project_context.py request.json
python3 scripts/project_context.py request.json --context project-context.jsonSkill 维护者可从 templates/material-contract-evidence-bundle.json 复制材料合同登记包。合同统一记录适用身份、所需输入、内容责任、合理深度、陈述效力、追溯关系、常见失败、缺失信息处理、验证案例和支持级别；样本入口记录来源、授权、脱敏状态、材料版本、评审状态、案例类型、数据分类、用途、evidence_type 和 model_execution。
python3 scripts/material_contract_registry.py material-contract-evidence-bundle.json项目受限样本只能登记为私有审阅，不能进入通用规则、公开评测或能力证据；禁止持久化信息直接阻断。合成案例不会被计为正式要求或真实案例。只有正式要求及所需的脱敏真实正例、失败例、生命周期边界和缺失信息案例全部到位，才能声明 deep_support；joint_review_support 还需追溯缺失、版本冲突、陈述效力不清和明确替代案例。完整规则见材料合同与样本证据登记。
维护者可通过一个统一基准复核三个业务域、七类场景、生命周期近失配、复合材料、陈述效力、处理模式、材料集、项目上下文、正式模板、提取缺口和数据边界：
python3 -m unittest tests.test_foundation_synthetic_benchmark -v基准清单为 evals/foundation-synthetic-benchmark.json。26 个案例全部标记为确定性合成输入、model_execution: false 和非真实工程证据；通过结果只支持识别覆盖和基础支持声明，不构成深度支持、联审支持或前向验证，也不证明统计稳定性。完整边界见基础层确定性合成证据基准。
yangqi-tech-writing/
├── SKILL.md # 运行入口与场景路由
├── references/ # 共性规则和七类场景包
├── templates/ # 材料合同与样本登记模板
├── scripts/ # 感知决策、上下文、合同登记与审计脚本
├── tests/ # 单元测试与烟测样例
├── evals/evals.json # 43 项行为评测
├── evals/foundation-synthetic-benchmark.json # Foundation 12 统一合成基准
├── TESTING.md # 验证记录和局限
├── CHANGELOG.md # 版本变更
├── ROADMAP.md # 后续路线
└── VERSION # 当前版本号
三个既有审计脚本只使用 Python 标准库，输出 JSON，入口和退出码保持不变。
python3 scripts/protected_diff.py before.md after.md0：已编码保护项和规范性词数量未发现差异；1：输入或读取错误；2：保护项缺失或规范性强度发生变化。
python3 scripts/evidence_check.py evidence-ledger.json0：账本通过；1：JSON 或 schema 错误；2：存在高风险UNSUPPORTED、CONTRADICTED或待确认阻断项。
python3 scripts/style_audit.py document.md脚本以 0 返回 T1/T2/T3 软提示。命中不是自动修改指令，更不是 AI 作者检测结果。
python3 -m unittest discover -s tests -v
python3 scripts/style_audit.py tests/fixtures/sample.mdGitHub Actions 在 Python 3.9、3.11 和 3.12 上运行测试。详细结果和已知局限见 TESTING.md。
项目采用 Semantic Versioning：
v1.0.0：七类场景、24 项评测和三个审计脚本；v1.1.0：43 项行为评测、复合文种路由、增强保护项与证据检查，以及因果外推边界；v1.1.1：阶段感知基础层、三类业务域、材料集追溯、写作准备单、项目上下文、正式模板适配和统一合成证据基准；v1.1.x：兼容的规则、评测和脚本增强；v1.2.0：组织级 Style Profile 加载接口；v2.0.0：与独立yangqi-style-distiller建立稳定协议。
具体方向见 ROADMAP.md，已发布变更见 CHANGELOG.md。
欢迎通过 Issue 提供脱敏后的失败案例、误报案例和场景边界问题。Pull Request 应说明修改原因，补充相应测试，并确保原有保护项、证据和质量闸门不被弱化。
请勿提交真实账号、密钥、未脱敏内部材料、受限政策文件或未经授权的客户文档。
- 正则脚本只能发现已编码的表面差异，不能确定技术方案是否正确。
- 本项目不能判断法规、标准或制度对具体项目的法律适用性。
- 风格审计不判断作者身份，也不构成 AI 检测结论。
- 保护项和证据检查不能代替技术评审、法务审查、采购审查和人工签批。
本项目采用 MIT License。