LLM

Code

Analyze Issue

Analyze this issue, but do not modify files, write implementation code, or run commands that change the project state. First, explain the cause, options, and risks, and wait for my confirmation before implementing anything.

Treat my examples as illustrative, not prescriptive, and base your recommendations on established community conventions relevant to the project.

Output Complete File

Markdown:

Create a Markdown plan file in uppercase snake case in the `./guides` directory.

Please output the content in Markdown so I can copy and paste it directly.

Go:

Please output the code as one complete file (e.g., "main.go"), not multiple modules, so that it can be copied and executed directly.

Custom filename:

Please output the code as one complete file (e.g., [FILENAME]), not multiple modules, so that it can be copied and executed directly.

Review and Fix

Review the recent changes for bugs, regressions, compatibility issues, incorrect edge-case handling, and fragile implementations.
Fix all confirmed issues with minimal, maintainable changes, and add regression tests where appropriate.
Do not make unrelated changes or speculative refactors. Report the issues found, files modified, and validation results.

Please review the changes on CURRENT_BRANCH against main.

Reusable suffixes:

Review the changes for bugs, regressions, compatibility issues, incorrect edge-case handling, and fragile implementations.

Fix all confirmed issues with minimal, maintainable changes, and add regression tests where appropriate.

Code Readability

Make small, idiomatic readability improvements, following the project's existing conventions.
Preserve runtime behavior, public interfaces, error handling, and existing test coverage. Do not weaken assertions or remove tested scenarios.
Avoid unrelated refactoring, new abstractions, and dependency changes. Leave code unchanged when there is no clear readability benefit.
Report the changes and validation actually performed.

No Commits and Push

Do not commit, push, create or update PRs, post external comments, or edit reproduction documents. Preserve existing assertions and tested scenarios.

Branch Name and Commit Message

Review the current changes and suggest one branch name and one commit message.
Read repository instructions, Git status, staged and unstaged diffs, relevant untracked files, and recent commit history. Follow the project's documented conventions, using recent history and existing branch names as supporting evidence. Do not assume Conventional Commits or a particular branch prefix.
Summarize the main purpose of the intended changes. Keep the branch name concise and the commit subject clear; add a body only when needed. If no convention is evident, use a descriptive branch name and an imperative commit subject.
If the intended scope is unclear or includes unrelated changes, ask a focused question before generating the result.
Do not modify files, create or switch branches, stage, commit, or push.
Output only the suggested branch name and commit message.

Commit Message Only

Analyze the recent Git changes and generate one concise Conventional Commit message.
Requirements:
- Review `git status` and `git diff`.
- Summarize the main purpose of the changes, not every modified file.
- Use the format: `type(scope): description`.
- Choose an appropriate type such as `feat`, `fix`, `refactor`, `docs`, `test`, or `chore`.
- Use imperative mood and keep the subject under 72 characters.
- Add a short commit body only when the changes need clarification.
- Output only the final commit message.

GitHub PR

Review the changes and write a concise GitHub PR title and Markdown description. Follow the repository’s PR template when present.
Use natural, direct wording. Lead with the problem solved and the value of the change. Summarize the resulting behavior, meaningful tests performed, and any material risks or limitations.
Distinguish tests added from tests actually run. Report only supported validation results; if validation evidence is unavailable, say so. Omit routine formatting and whitespace checks, including `git diff --check`.
Aim for maintainers to understand it in under 60 seconds without omitting required template sections or material caveats.
Do not modify project files, run tests, or create or update a PR.
Output only the title and description in Markdown.

Reusable PR wording guidelines:

Use natural, direct wording. Lead with the problem solved and the value of the change. Summarize the resulting behavior, meaningful tests performed, and any material risks or limitations.
Distinguish tests added from tests actually run. Report only supported validation results; if validation evidence is unavailable, say so. Omit routine formatting and whitespace checks, including `git diff --check`.
Aim for maintainers to understand it in under 60 seconds without omitting required template sections or material caveats.

Issue and Reproduction Wording

Polish this issue report or its reproduction steps using natural, direct wording.
Preserve technical meaning, uncertainty, reproduction steps, expected and actual behavior, code, commands, identifiers, URLs, and error output.
Keep the reproduction concise without removing details needed to reproduce the issue. Report only supported validation results; do not invent missing steps or outcomes.

Prepare PR Branch

Prepare a clean local branch for submitting the intended changes to the official upstream repository.
Inspect repository instructions, Git status, remotes, and commit history. Identify the official upstream remote, target branch (main unless specified otherwise), source commits, and a new destination branch name. Do not assume origin is upstream. Ask if the remote, commit selection, or destination is ambiguous.
If the working tree is dirty or a Git operation is in progress, stop and ask before proceeding. Do not automatically stash or discard changes.
Fetch the upstream target branch and create a new branch from its latest fetched commit. Preserve the original branch and do not reuse or overwrite an existing destination branch.
Cherry-pick only the intended commits in dependency order and squash the applied changes into one commit. Use a commit message that follows repository conventions and preserve contributor attribution where applicable.
Stop and ask about conflicts requiring judgment, missing dependencies, or commits that become empty; do not silently drop changes or resolve ambiguous conflicts.
Compare the resulting patch with the original intended changes, explain any differences caused by the updated base, and run relevant validation. Confirm that the new branch contains exactly one commit above the fetched base.
Report the new branch name, the base and final commit IDs, the included source commits, validation results, and any remaining limitations.
Do not push, delete branches, overwrite published history, or create or update a PR without explicit approval.

New Project

npm:

This library will be published as a new npm package with no existing users or released versions.

Project:

It will be published as a new project with no existing users or released versions.

Bash:

This is a new Bash project containing a collection of scripts, with no existing users or released versions.

PowerShell:

This is a new PowerShell project containing a collection of scripts, with no existing users or released versions.

Skill:

It will be published as a new skill with no existing users or released versions.

Non-Defensive Programming

Frontend:

For frontend code, avoid defensive programming unless it protects a real UI, network, storage, or third-party boundary. Do not add broad `try...catch`, redundant optional chaining, fallback UI states, default objects, or guards around internal data that the component contract already guarantees.

Node.js:

For Node.js code, avoid defensive programming unless it handles a real I/O, network, process, configuration, or third-party boundary. Do not add broad `try...catch`, redundant null checks, silent fallback values, blanket retries, or wrapper errors that add no useful context.

Bash:

For Bash scripts, avoid defensive programming unless it handles a real process, filesystem, network, environment, or cleanup boundary. Do not add broad `|| true`, redundant existence checks, silent fallback values, blanket retries, or traps that hide useful exit codes.

PowerShell:

For PowerShell scripts, avoid defensive programming unless it handles a real process, filesystem, network, environment, or cleanup boundary. Do not add broad `try...catch`, redundant existence checks, silent fallback values, blanket retries, or error handling that suppresses failures.

Go:

For Go code, avoid defensive programming unless it handles a real boundary, documented error case, or resource cleanup path. Do not add blanket `recover`, broad fallback behavior, redundant nil checks, or wrapper errors that add no useful context.

Rust:

For Rust code, avoid defensive programming unless it handles a real I/O, configuration, FFI, or third-party boundary, a documented error case, or a safety requirement. Do not add blanket `catch_unwind`, silent fallback values, ignored errors, redundant checks for invariants already enforced by types, or wrapper errors that add no useful context. Preserve meaningful `Result` and `Option` handling; do not replace it with `unwrap`, `expect`, or unchecked operations merely to shorten the code.

AGENTS.md

Read and update:

Read the latest repository code and update AGENTS.md so it accurately reflects the current project.

Frontend:

Map the frontend component hierarchy:
- shared state
- prop flow
- context usage
- rendering bottlenecks

Contributor guide:

Generate a file named AGENTS.md that serves as a contributor guide for this repository.
Your goal is to produce a clear, concise, and well-structured document with descriptive headings and actionable explanations for each section.
Map this repository:
- key folders
- entry points
- startup flow
- configuration files
- build pipeline
- how data flows between components

Check Local Links

Check all local links in Markdown files under [DIRECTORY], including subdirectories.
Resolve relative paths from the containing file. Check linked files, directories, images, reference-style links, and heading anchors, including same-file anchors.
Use the project's Markdown renderer conventions for anchors and repository-root or site-root paths. If the base or rendering rules are unclear, report the limitation instead of guessing.
Skip external URLs, including HTTP, HTTPS, and protocol-relative links, and other non-file schemes. Ignore examples inside fenced code blocks and inline code. Do not make network requests.
Report confirmed broken links with the source file and line number, original link, resolved target, and reason. Separate uncertain cases and validation limitations from confirmed defects.
Summarize the scope checked. Do not modify files or install dependencies.

Cleanup

Frontend:

You are an experienced frontend repository-maintenance, npm, TypeScript, Webpack, Rollup, Jest, ESLint, CI, and package-publishing engineer.
Audit the project root, `package.json`, and related configuration files to identify files, directories, dependencies, scripts, and generated artifacts that can be deleted safely.
The primary goal is to reduce repository clutter and remove obsolete, duplicated, unused, generated, or accidentally committed files without breaking anything.
Do not delete anything merely because its purpose is unclear.

Bug Audit and Fix

Frontend:

Analyze the entire frontend project for potential bugs, regressions, compatibility problems, and fragile implementation patterns. Fix all confirmed issues with minimal, maintainable changes, and add regression tests where appropriate.

Collect Reusable Helpers

Analyze this project and identify reusable helpers or utilities that could be extracted for use across other projects.
Requirements:
- Check for duplicated or overlapping functionality.
- For each candidate, provide:
  - Function name
  - Purpose
  - Why it is reusable
  - Proposed generalized API
- Do not modify project files.
Output a concise Markdown report with the strongest candidates first.
`./guides/MAZEY_CANDIDATES.md` should contain the list of candidates, their purpose, and proposed API.

Use Mazey

Review the current project and determine whether its custom utility code can reuse existing functions from the installed `mazey` package.
Reduce duplicated general-purpose helper logic by using suitable `mazey` APIs, but only when their behavior fully matches the project's requirements.

Codex

Update

Short prompt:

Update the local Cheng Skills Codex plugin from the current repository.

Detailed prompt:

Update the local Codex plugin Cheng Skills from the current repository.
Do not stage, commit, push, or publish anything. Report failures and remind me to start a new Codex task after the update.
Run:
npm run validate &&
npm test &&
git diff --check &&
rsync -a --delete --exclude .git --exclude node_modules ./ "$HOME/plugins/chengchuu-skills/" &&
python3 "$HOME/.codex/skills/.system/plugin-creator/scripts/update_plugin_cachebuster.py" "$HOME/plugins/chengchuu-skills" &&
codex plugin add chengchuu-skills@personal

pet-diary-notes

$pet-diary-notes

根据以下场景生成中文、英文和日文宠物日记文案：

- 宠物：嘟嘟
- 内容形式：Vlog
- 场景：趴在窗边看雨
- 氛围：安静、治愈
- 内容类型：Real-life
- 日期：2025-03-07
- 平台：多平台
- BGM：未指定

ZH and EN Technical Writing

Review a technical document:

Review and improve this technical document written in Markdown.

Review a README:

Review and improve this README for punctuation, spacing, sentence length, heading structure, and technical-writing style.

Chat to Codex Prompt

Turn the discussion above into one self-contained implementation prompt that I can paste into Codex without the original chat.
Include the agreed goal, relevant context, confirmed decisions, scope, constraints, acceptance criteria, and validation requirements. Preserve technical identifiers and useful project-relative paths; omit incidental device-specific checkout locations.
Distinguish confirmed decisions from suggestions, assumptions, and unresolved questions. Exclude rejected approaches and repetition. Do not invent requirements, repository details, commands, or validation results.
Tell Codex to read the applicable AGENTS.md instructions and inspect the current repository before making changes. Preserve unrelated work and carry forward explicit action limits; do not treat past approvals as new authorization.
Keep the prompt concise and actionable. Flag unresolved questions that block implementation rather than deciding them silently.
Output only the prompt in Markdown, ready to copy and paste. Do not implement the task.

Common Prompt

Polish Prose

Make small wording improvements so the text sounds natural and direct. Remove repetition and unnecessary formality.
Preserve the meaning, scope, technical claims, caveats, and uncertainty. Keep code, commands, identifiers, paths, URLs, and quoted output unchanged.
Edit prose only; do not change the implementation or documented behavior. Output only the revised text, preserving its format.

Chat Summarization

Summarize the conversation into a concise Markdown document that can be used as context in a new chat.
Requirements:
- Preserve the goals, scope, constraints, preferences, key decisions, technical findings, and reasons behind them.
- Distinguish completed work, remaining tasks, unresolved questions, and recommended next steps.
- Preserve important caveats, uncertainty, and actual validation results. Do not invent facts or present historical observations as current state.
- Keep useful project-relative paths and identify their repository or base directory when needed.
- Omit device-specific absolute checkout locations and home-directory prefixes from narrative context. Convert them to project-relative paths only when the base is clear; otherwise describe their role without guessing.
- Preserve code, commands, configuration, URLs, identifiers, and diagnostic output exactly when retained. Label necessary device-specific paths in these examples as historical environment details.
- Retain reusable prompts or patterns only when they add meaningful value. Remove repetition and superseded guidance.
Output only the Markdown document, with clear headings and lists or code blocks where useful. Make it self-contained and ready to paste into a new chat.

Chat Loading

Read the following Markdown summary and use it as context for this conversation.
Requirements:
- Identify the goals, scope, constraints, preferences, decisions, completed work, remaining tasks, and unresolved questions.
- Build on completed work and avoid repeating resolved investigation.
- Apply relevant decisions and preferences unless newer instructions supersede them.
- Treat recorded paths, branches, repository status, tool versions, and validation results as historical observations. Verify relevant details before relying on them for new work.
- Resolve project-relative paths against the appropriate current workspace. Do not assume or recreate the previous device's absolute directory layout.
- Preserve technical literals and uncertainty. Do not guess missing facts or path mappings.
- Do not ask for information already supplied unless it is contradictory, potentially outdated, or insufficient for the next task.
- Treat past action approvals as historical context, not authorization for new actions.
Briefly acknowledge the context and identify any clarification needed for the next task. If no next task is provided, wait for instructions.

Install Software

macOS ARM64:

Help me install the following software.
Software:
[SOFTWARE_NAME]
Environment:
- OS: macOS
- OS Version: macOS Tahoe (2026)
- Architecture: ARM64
- CPU: Apple Silicon (M5)
- Shell: zsh / bash
- Package Manager: Homebrew, Node.js 22 with nvm, npm 10

macOS Intel:

Help me install the following software.
Software:
[SOFTWARE_NAME]
Environment:
- Computer: MacBook Air 13-inch, 2017
- Processor: 1.8 GHz dual-core Intel Core i5
- Memory: 8 GB
- Operating system: macOS Monterey 12.7.6
- Architecture: x86_64
- CPU platform: Intel
- Shell: bash / zsh
- Package Manager: Homebrew

Windows 10 x64:

Help me install the following software.
Software:
[SOFTWARE_NAME]
Environment:
- OS: Windows 10
- Architecture: x64
- CPU: AMD Ryzen 7 1700X
- GPU: NVIDIA GTX 1080
- Shell: Git Bash / PowerShell / CMD
- Package Manager: Winget / Download from the official website

Custom environment:

Help me install the following software.
Software:
[SOFTWARE_NAME]
Environment:
OS: [macOS / Windows / Debian / Ubuntu / etc.]
OS Version: [e.g., macOS 14 / Windows 11 / Debian 12]
Architecture: [x64 / ARM64]
CPU: [Intel / Apple Silicon / AMD]
Shell: [bash / zsh / PowerShell / cmd]
Package Manager: [brew / apt / winget / npm / pip / none]
Version Requirements:
Target Version: [latest stable / LTS / specific version]
Upgrade Strategy: [easy upgrade / long-term stability]
Goal:
[What you want to achieve]
Please provide:
- installation steps
- dependencies
- upgrade method for future versions
- verification steps

Article

请为文章提供 100 字以内的摘要：
- 开头不要写：这篇文章/该内容；
- 内容中不要写：文章/团队；
- 避免了重复的词汇，英文与中文之间需要保持空格；
- 如果内容包含括号，请使用英文括号 ()，括号前后有文字的话加空格，没有的话不加；
- 忽略文章末尾的"版权声明"；
- 代码部分不需要使用反引号 backtick 包裹，而是使用半角双引号；

为文章提供 20 个 Hash Tags，10 个英文标签和 10 个中文标签。

- 减少过于完美的句式结构；
- 避免过于机械化的段落结构；
- 使内容更自然，更像人类书写；
- 使内容视角更客观，移除第一/二/三人称；
- 用 "他" 代替 "它"；

Update an older article:

这篇文章写于 2020 年，请按照 2026 年的标准优化。

Translate and refine an article:

请将以下文本翻译成中文，确保主题连贯一致:
- 检查并强化中心思想贯穿全文；
- 确保每个段落都服务于主题；
- 增强段落之间的过渡和连接；
- 删除偏离主题的内容；
- 调整结构以形成清晰的逻辑发展；
- 保持论点、论据和结论之间的连贯性；
- 减少过于完美的句式结构；
- 避免过于机械化的段落结构；
- 使内容更自然，更像人类书写；
- 使内容视角更客观，移除第一/二/三人称；
- 用 "他" 代替 "它"；

Article description:

Please provide a description in Chinese for the article titled [title].

Archives

Full-Stack Developer

I am an experienced full-stack developer.
Technical background includes:
- Backend: Go, Node.js, PHP
- Scripting: Bash, PowerShell
- Frontend: JavaScript, TypeScript
- Frameworks/Libraries: React.js, Vue.js, Bootstrap, jQuery
- Web fundamentals: HTML, CSS
Skip basics. Give concise, production-ready solutions with best practices, edge cases, and performance considerations.

Authorized

Frontend:

You are authorized to restructure the existing project, including changing its file and directory organization, and to install, remove, or update npm packages as needed to produce a cleaner, more maintainable, production-ready implementation.

GitHub Actions

Frontend:

Review and update this frontend repository's GitHub Actions workflows. Use these action versions:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
- uses: actions/configure-pages@v6
- uses: actions/upload-pages-artifact@v5
- uses: actions/deploy-pages@v5
Preserve workflow behavior, configuration, and full-SHA pins. Validate the YAML, report all changes, and do not commit, push, publish, or deploy.

GitHub Issue

# Create a GitHub Issue
Analyze the repository and write a clear, actionable GitHub issue based on the request below.
## Input
Issue type:
[Bug | Feature | Improvement | Documentation | Refactor | Performance | Testing]
Issue request:
[Describe the issue here]
## Output
- The issue title.
- The complete Markdown issue body.

General Bug

I'm debugging an existing production-like project. Please help me do root cause analysis instead of guessing.
Bug:
[describe the bug]
Context:
- Stack: [stack]
- Expected result: [expected]
Please do:
- list the most likely root causes in probability order
- explain why each cause is plausible
- tell me exactly what to inspect next
- propose the smallest safe fix first
- list regression risks after the fix

Node.js Upgrade

Migration from Node.js 14 to Node.js 22:

Upgrade this frontend project from Node.js 14 to Node.js 22.
Review package.json, lockfiles, scripts, dependencies, and build, lint, and test configurations. Resolve Node.js 22 compatibility issues, including deprecated packages, native dependencies, OpenSSL, and ESM/CommonJS behavior.
Apply a low-risk migration that preserves existing behavior and avoids unnecessary framework changes.
Report:
- dependency changes and reasons
- files modified
- validation results for install, lint, test, build, and development startup

Translate

Short translation into Chinese:

Translate the following text into Chinese:
[text]

Full article translation into Chinese:

Translate the entire article into Chinese and improve its readability for Chinese readers. Also provide the article's title and description in Chinese.
[content]

Translation into Japanese:

Translate the following text into Japanese:
[text]

Work

请帮我撰写工作思考，字数控制在 70 字左右。

以下是周报正文。请总结本周的问题及解决办法，字数控制在 100 字左右。
[Content]

Debian 11 x64 Guide

I will use Debian 11 x64 to [target]. Please provide me with a step-by-step guide and generate an article for me once we're done.

Debian Terminal Error

Debian terminal error: [Error]

Code to Article

Convert code into a blog article.
ENV: [env]
These are the commands I ran: [code]
Summarize the guide for [target] and include the code.

Day-to-Day Maintenance Work

I'm working on an existing production-like tech project and I want help as a maintainer, not as someone starting from scratch.
Project context:
- Stack: [stack]
- Goal: [project / feature / bug / refactor goal]
- Constraints:
  - preserve current architecture unless change is clearly worth it
  - prefer minimal, incremental modifications
  - keep compatibility with existing runtime / framework / coding style
  - prioritize correctness, maintainability, and rollback safety
Please do the following:
- understand the existing design before proposing changes
- explain the current behavior and where the relevant logic likely lives
- identify the smallest safe implementation path
- point out hidden coupling, regression risks, and compatibility issues
- provide concrete code / config / command changes
- separate “must-do fix” from “nice-to-have refactor”
- if information is missing, tell me exactly what file / log / command output to provide next

Review Nginx Config Safely

Please review this Nginx config like a production ops engineer.
Goals:
- verify whether the config actually does what I intend
- identify path resolution mistakes with root / alias / try_files
- point out security issues, cache behavior, logging noise, and redirect problems
- explain any subtle Nginx behavior that may surprise maintainers
- provide a corrected version with comments, but keep the structure close to the original config

Build Pipeline Analysis

Explain the full build pipeline:
- transpilation
- bundling
- optimization
- asset handling
- environment injection

Build a Maintenance Map for a Legacy Repo

I inherited an existing project and need a maintenance map.
Tech stack:
- Backend: [Node.js / Go / PHP]
- Frontend: [React / Vue / jQuery / Bootstrap]
- Infra: [Nginx / Docker / PM2 / Supervisor / systemd]
- DB / cache: [MySQL / Redis]
Please generate a maintainer-oriented document:
- What each major directory likely does
- Which files are likely “dangerous to change”
- Where environment variables, ports, domains, and secrets are probably wired
- What the release path probably looks like
- Which modules are likely shared by multiple features
- A prioritized reading order for understanding the codebase in 2 hours

Technical Debt Prioritization

Rank the top technical debt issues by:
- engineering risk
- maintenance cost
- refactor difficulty
- production impact

Photo

Keep the person's face completely unchanged.

Remove only the background shadow and rebalance the composition.

Note

我是一位宠物猫视频博主，请优化这段 Vlog 文案：
- 分别生成中文和英语文案；中文标题以"｜"为分隔符；英文标题以":"为分隔符；中文文案只包含中文标签，英文文案只包含英文标签；标题不需要句号；
- 补充副标题或者描述，字数不超过 50 字，并且以句号为结尾；
- 标签数量去除重复，如果数量少于 10 个，补充至 10 个；
- 中文和英文标签额外生成一份没有空格的，没有空格的只保留前 10 个标签；
- 中文标签额外生成一份 #标签名# 格式的，#标签名# 只是一个案例，不是真实标签；
- 除了区分中英文，不需要例如标题、副标题、描述和标签这样的说明，直接换行展示，换行中间不需要空的换行；
- 内容中不需要带有：标题、副标题、标签等文字，只需要纯粹的内容就行；
- 中文少用：体验、探索、感受、探访；
- 用日文撰写一个标题和描述，并且解释他并且用罗马音标注；
视频内容：[美食/活动/机场/自驾游]；

我在[韩国/日本/上海][旅行/生活]，请写[美食/活动/机场/自驾游][笔记/评价]：[好评/差评/日常/新奇/严肃/生气]；
标题在 20 字以内；
[文字/正文]在 200 字左右；
店铺：[店铺名]；
食物：[食物名]；
项目：[项目名]；
地址：[地址]；
时间：[春天/夏天/秋天/冬天][早上/中午/晚上]；
评价：[好评/差评/日常/新奇/严肃/生气]；
标题和正文不要写：体验了、隐藏在、享用了、观众们、我们、商城；
结尾处不要写：非常适合、尝试、强烈推荐、总体来说、令人满意、相信你也会、如果你也、午餐体验、非常满足、总之、理想选择、不可多得、深受、广大食客、新选择、特别适合、深受欢迎、这次、难忘、宾至如归、令人、美食体验、经历、人群、和朋友、一起品尝、用餐体验；
书写格式：英文、数字和中文之间要有空格；
添加 8 个标签，各个之间加 1 个空格保持一排；

我是一位在[厦门/韩国/日本/上海]旅行的视频博主，请优化这段 Vlog 文案：
- 分别生成中文和英语文案；中文标题以"｜"为分隔符；英文标题以":"为分隔符；中文文案只包含中文标签，英文文案只包含英文标签；标题不需要句号；
- 补充副标题或者描述，字数不超过 50 字，并且以句号为结尾；
- 标签数量去除重复，如果数量少于 10 个，补充至 10 个；
- 中文和英文标签额外生成一份没有空格的，没有空格的只保留前 10 个标签；
- 中文标签额外生成一份 #标签名# 格式的，#标签名# 只是一个案例，不是真实标签；
- 除了区分中英文，不需要例如标题、副标题、描述和标签这样的说明，直接换行展示，换行中间不需要空的换行；
- 内容中不需要带有：标题、副标题、标签等文字，只需要纯粹的内容就行；
- 中文少用：体验、探索、感受、探访；
- 英文少用：Experience、Explore、Discover；
- 用日文撰写一个标题和描述，并且解释他并且用罗马音标注；
拍摄地点：[厦门/韩国/日本/上海]；
视频内容：[美食/活动/机场/自驾游]；

Comment

请为我写餐厅评价，字数控制在 100 字左右。
使其更自然，更像人类。
- 减少过于完美的句式结构，添加适当的不规则表达；
- 使用更具个性化的语言；
- 偶尔使用口语化表达；
- 避免过于机械化的段落结构；

请为我把以上内容浓缩成一段 100 字左右的简短评价。

请为我写景区评论，前部分介绍历史，字数控制在 50 字左右。
使其更自然，更像人类。
- 减少过于完美的句式结构，添加适当的不规则表达；
- 使用更具个性化的语言；
- 偶尔使用口语化表达；
- 避免过于机械化的段落结构；

请为我写商品评价，字数控制在 100 字左右。

版权声明

本文为原创文章，作者保留版权。转载请保留本文完整内容，并以超链接形式注明作者及原文出处。

作者: 除除
原文: chengchuu.github.io/?p=4281