Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a local text-rewriting skill, but its documentation inconsistently asks for AI API keys and promises remote-model and bulk features that the inspected code does not implement.
Treat this as a Review item rather than confirmed malware. Do not provide AI provider API keys or sensitive documents based on the current documentation; the package should first reconcile whether it is local-only or remote-provider-backed, remove unimplemented claims, and pin or justify dependencies.
The README asserts 'local processing', 'no data collection', and only a numpy dependency, while the skill metadata states support for external AI providers such as OpenAI, Anthropic, and 阿里. This mismatch can mislead users into sending sensitive text to remote services under the false belief that data never leaves the machine, creating privacy, compliance, and trust risks.
The privacy section directly contradicts the stated capability to use external AI providers, yet presents strong assurances such as 'all data processed locally' and 'no logging'. In a text-processing skill, users may input proprietary, regulated, or personal content, so inaccurate privacy claims materially increase the chance of unsafe disclosure to third parties.
该代码的核心功能与“中文 AI 文本优化/去除 AI 痕迹”大体相关，但描述中的关键能力“支持多种 AI 模型（OpenAI/Anthropic/阿里）”在实现中完全不存在。代码没有网络访问、SDK、API 密钥处理、模型路由或供应商适配，仅进行本地字符串替换、句子拆分和随机插入连接词/语气词。此外，描述称“保持专业性”，但实现默认是 casual 风格，且会加入‘啊/呢/吧/嘛/哦’等语气词，使输出可能更口语化而非专业。因此，虽然主题方向相近，声明与实际能力存在实质性不符，应判定为 mismatch。
The code is clearly related to text optimization/humanization, so it is in the same general domain as the description. However, there is a material description-behavior mismatch. The description promises support for multiple AI models/providers, but the code imports no networking/client libraries and implements no model invocation logic at all. Instead, it performs deterministic string replacements, regex-based language/context detection, style recommendation, context carryover, chunking for long text, and synthetic scoring. Additionally, the description says it preserves professionalism, but the code can intentionally transform text into blog or social styles, including replacing punctuation with '～' and adding emojis like ✨/🎯, which is not consistently professional. Therefore the declared description overstates and inaccurately characterizes the actual capabilities.
该描述与代码存在明显不一致。代码的核心功能是本地规则式文本改写：检测语言/风格，按 academic/blog/social 三种风格进行替换、加连接词、加语气词或 emoji，并返回一个伪评分结果。它没有任何网络请求、SDK 导入、密钥处理或模型调用，因此“支持多种 AI 模型（OpenAI/Anthropic/阿里）”这一关键能力未被实现。另一方面，“去除 AI 痕迹，保持专业性”也与实际行为不完全一致，因为博客/社交优化会加入“～”“啦”及 emoji，明显偏口语化，不是稳定的专业化处理。整体来看，代码确实与文本优化相关，但其实际能力比声明更简单，且关键卖点（多模型 AI 支持、去 AI 痕迹）缺失，因此应判定为描述与行为不匹配。
The description claims a Chinese AI text optimization skill with support for multiple external AI providers (OpenAI/Anthropic/Alibaba). The supplied code contains no network/API calls, no SDK usage, no model selection, and no provider integration at all. Instead, it performs deterministic, local string replacements and heuristic style detection for Chinese and English text. While it is broadly related to text optimization/humanization, the primary implementation is materially narrower and different from the declared multi-model AI capability. The claim about removing AI traces is not substantiated by the code beyond simple connector/verb substitutions, and professionalism is not consistently preserved because some modes convert text into more casual or blog-like language.
该描述与代码存在实质不符。代码的主要功能确实与“文本优化/风格调整”相关，因此方向上部分吻合；但关键能力描述明显夸大或不准确。首先，声明中强调支持 OpenAI/Anthropic/阿里等多模型，实际代码没有任何外部模型接入、API 调用、配置或推理逻辑，仅加载本地词表。其次，代码不仅处理中文，也实现了英文优化，与“中文技能”的定位不完全一致。再次，所谓“去除 AI 痕迹，保持专业性”在代码中并无明确检测或消除 AI 特征的算法，只是做诸如连接词、动词、标点的替换，并返回基于文本长度的简化评分。因此应判定为描述与实际行为不匹配。
The skill advertises use of external AI providers and API keys but does not clearly warn that user text, code, or batch-processed files may be transmitted to third-party services. This can lead users to unknowingly send sensitive content, source code, or proprietary documents off-system, creating confidentiality and compliance risk.
The batch-processing documentation encourages recursive or bulk rewriting of files without warning about mass file modification, overwrite, or propagation of unwanted transformations across a large corpus. In practice, users may unintentionally alter many documents or code files at once, causing integrity loss and difficult rollback scenarios.
The module is explicitly labeled as a Chinese AI text optimizer and all transformation templates are hard-coded in Chinese, which constrains output to a specific language. The file does not provide any user opt-in, language selection mechanism, or documented justification for the locale restriction.
The manifest description explicitly labels the skill as a Chinese AI text optimization skill ("中文 AI 文本优化技能") with no indication that users may choose another language. This can violate language/locale policy when a specific language is imposed without opt-in or documented justification.
This code hard-codes the default language parameter to "zh", which makes the skill operate in a specific language by default. Under the policy, forcing a language or locale without explicit user choice or clear justification is a natural-language policy violation.
The initializer sets the default language to "zh", and the script's entrypoint constructs the humanizer with that default, while the file description and examples are entirely Chinese-centric. This creates a natural-language locale preference that is imposed by default rather than explicitly chosen by the user.
The initializer sets the default language to "zh", and the surrounding documentation presents this as the normal behavior rather than an explicit user choice. This is a natural-language locale policy issue because the skill biases output toward a specific language unless the caller overrides it, with no documented opt-in or region-specific justification.
The file defines supported language models only for "zh" and "en", and later branches processing exclusively on those language codes. This creates a built-in language/locale constraint without any natural-language disclosure that users can choose locale support or that the limitation is intentional and justified.
The top-level documentation describes an 'Ultimate Version' with 'Multi-language text optimization with adaptive context awareness', and the initializer docstring lists zh/en/zh-TW/ja/ko as target languages. In code, only Chinese and English models are loaded, language detection returns only 'zh' or 'en', and unsupported languages fall through unchanged, which is narrower than the claimed behavior.
The init docstring says the target language can be 'zh/en/zh-TW/ja/ko'. However, the constructor loads only 'zh' and 'en' models, and later processing routes only those two languages to optimization functions, contradicting the documented supported language set.
The dependency specification for requests is unpinned and allows future versions to be installed without review. This creates supply-chain and reproducibility risk because a vulnerable or breaking release could be pulled into deployments unexpectedly.
# Core dependencies
requests>=2.28.0
numpy>=1.20.0
pyyaml>=6.0
Requests has multiple published advisories, and because the manifest does not pin an exact version, it is not possible to verify whether installed environments will avoid affected releases. This is dangerous because different installations may resolve differently, leaving some deployments exposed to known issues.
The dependency specification for numpy is unpinned and permits arbitrary newer versions that satisfy the minimum constraint. This weakens build reproducibility and can expose the project to newly introduced vulnerable releases or unexpected behavior changes.
# Core dependencies
requests>=2.28.0
numpy>=1.20.0
pyyaml>=6.0
# Optional dependencies
NumPy has known advisories, and the lack of version pinning makes the dependency state unverifiable across environments. That uncertainty can result in some builds pulling vulnerable versions, especially in automated or long-lived deployment pipelines.
The dependency specification for pyyaml is unpinned and allows installations to resolve to different versions over time. Because PyYAML has had security-sensitive issues historically, lack of pinning increases uncertainty about whether safe versions are consistently used.
# Core dependencies
requests>=2.28.0
numpy>=1.20.0
pyyaml>=6.0
# Optional dependencies
# beautifulsoup4>=4.11.0 # HTML parsing
PyYAML has a history of deserialization-related security issues, and without an exact pinned version the manifest cannot guarantee that safe releases are installed. In software that processes user-controlled text or structured content, this raises the chance that a vulnerable parser version could be deployed.
No suspicious patterns detected.